# 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>

```On Friday, March 2, 2012, 5:11:03 PM, Erik wrote:

ED> * linearRGB vs sRGB for filter effects
ED>
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
http://www.teamten.com/lawrence/graphics/gamma/

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.")

http://brucelindbloom.com/index.html?WorkingSpaceInfo.html

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).")
http://brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html

http://www.poynton.com/PDFs/GammaFAQ.pdf

Optimal gamma factor for specifying color (or storing color in space-efficient ways,such as in raster images)
http://brucelindbloom.com/index.html?CompandCalcHelp.html#BestGammaForLab

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

The Importance of Being Linear
http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html

Gamma-Correct Rendering
http://www.sjbrown.co.uk/2004/05/14/gamma-correct-rendering/

Be gamma correct!
http://scripts.breidt.net/gamma_correct_v12.pdf

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