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

Chris,

the topic on the FX call is not about the merits of the color-interpolation
attribute. That is a different discussion.

It is about if that attribute applies to the filter shorthands and if so,
what is the default and how can you change it.

Rik

On Mon, Mar 5, 2012 at 11:21 AM, Chris Lilley <chris@w3.org> wrote:

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