W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2012

Linear-light RGB calculation (was: Agenda, 5 March 2012 FXTF telcon)

From: Chris Lilley <chris@w3.org>
Date: Mon, 5 Mar 2012 20:21:10 +0100
Message-ID: <1848624132.20120305202110@w3.org>
To: "Erik Dahlstrom" <ed@opera.com>
CC: public-fx@w3.org
On Friday, March 2, 2012, 5:11:03 PM, Erik wrote:

ED> * linearRGB vs sRGB for filter effects
ED> http://www.w3.org/mid/CAGN7qDDh_yJX_EzWNtuvW3N_eywgvB3MioMn6FoP_p8kHTwh-A@mail.gmail.com

I may be helpful for people who are not familiar with gamma correction, luminance calculation, or color management to read through some introductory material before this agenda item.

In particular I find people are commonly confused between the color space used to *specify* a color (srGB as the default, but also other RGB spaces), which are gamma corrected to give approximate perceptual uniformity and to optimise the number of bits required, and linear light spaces which are used for computation (including interpolation, anti-aliasing, luminance and other linear calculations, exposure adjustment and other multiplicative calculations, and filter effects).

This is a good introduction, also covers effect on anti-aliasing

Gamma Correction in Computer Graphics

RGB working spaces
(pertinent quote:
"Another relevant fact is that these weightings must be made in a linear RGB space, that is, after the gamma companding function has been removed. It is very common to see the weightings applied bluntly to the companded RGB values, which is wrong.")


RGB/XYZ Matrices
(pertinent quote:
"In order to properly use this matrix, the RGB values must be linear and in the nominal range [0.0, 1.0]. In many cases, RGB values may first need conversion (for example, dividing by 255 and then raising them to a power).")

and for further reading

Frequently Asked Questions about Gamma

Optimal gamma factor for specifying color (or storing color in space-efficient ways,such as in raster images)

some examples showing rendering in linear-light vs gamma corrected spaces (3D but the same principle applies)

The Importance of Being Linear

Gamma-Correct Rendering

Be gamma correct!

In conclusion, SVG 1.0 and 1.1 had this correct for the past 10+ years. Doing it the wrong way is a classic beginners mistake which I a happy to say that SVG does not do. There have been suggestions of implementation complexity (the math is trivial), loss of accuracy (intermediate calculations require higher accuracy than the original data, as usual, and the inaccuracy produced by the wrong method is significant) or performance problems (again, the math is trivial and GPU acceleration allows an entire image to be loaded and converted to higher bit depth linear space in one operation).

So can we *please* lay this topic to rest, resolve to continue to do things the correct way and be backwards compatible with SVG 1.1, so that I can stop fighting rearguard actions against misguided attempts to break SVG 1.1 and focus instead on making SVG2 something useful now and in the future.

 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups
Received on Monday, 5 March 2012 19:21:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:46 UTC