- From: Chris Lilley <chris@w3.org>
- Date: Mon, 5 Mar 2012 20:21:10 +0100
- 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> 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 and for further reading Frequently Asked Questions about Gamma 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 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