W3C home > Mailing lists > Public > www-svg@w3.org > February 2011

Re: painting-render-02-b.svg

From: Osmo Jaakkola <orbik@iki.fi>
Date: Thu, 10 Feb 2011 12:22:45 +0200
To: www-svg@w3.org
Message-ID: <op.vqom37dao6uym8@rbi.kyla.fi>
>> The color-interpolation property affects just the alpha compositing  
>> process (in this example). Both the canvas and the element to be  
>> rendered are still defined in sRGB.
>> See the alpha compositing specification: [  
>> http://www.w3.org/TR/SVG/masking.html#SimpleAlphaBlending ]. If an  
>> object's color-interpolation is "LinearRGB", all RGB values in the  
>> formula (Er, Eg, Eb, Cr, Cg, Cb, Cr', Cg', Cb') refer to linear RGB  
>> values. This means the inputs must be converted sRGB->linRGB, and the  
>> result converted back linRGB->sRGB.
> Ok, maybe the step before Result confused me on your example. Taking  
> four values (last one is alpha) it would be (1.0, 1.0, 1.0, 0.5) in  
> linearRGB, after masks and opacity got applied (both can influence the  
> color values). This needs to get transformed to sRGB -> (1.0, 1.0, 1.0,  
> 0.735) and is drawn to the canvas. The visual result on the canvas would  
> indeed be (0.735, 0.735, 0.735). Would make sense and the test is  
> correct.

Actually, the alpha channel is always linear, even in sRGB, so such  
transformation ( (1.0, 1.0, 1.0, 0.5) to (1.0, 1.0, 1.0, 0.735) )  
shouldn't occur. The result is correct thought, but that's because only  
extreme color values were used.
If the foreground color was say, sRGB(0.1, 0.5, 0.9) instead of sRGB(1.0,  
1.0, 1.0), the resulting color after blending should be ca. sRGB(0.061,  
0.361, 0.660). The method you suggested would get sRGB(0.074, 0.3675,  
0.662) instead. Might be actually acceptable as a speed optimization hack,  
but the error is noticeable.

>> You could visualize the process as an "alpha blender object" that  
>> always takes in and outputs sRGB values, but has two internal modes -  
>> direct sRGB mixing (default), and physically correct linear mixing,  
>> activated by changing the color-interpolation property. And all the  
>> color space conversions take place inside this object. Same goes for  
>> the "color gradient renderer object" and "color animator object".
> Hm. Short example:
>  <rect fill="rgb(127, 127, 127)" color-interpolation="linearRGB" .../>
> Would I interpret the color as linearRGB  or sRGB value (that needs to  
> get transformed to linearRGB)? It the value gets interpreted as sRGB,   
> the result wouldn't look different to color-interpolation="sRGB", right?

Colors are always given in sRGB as per CSS2, either as integers (0-255) or  
percentages. See:
The integer notation wouldn't be very useful for expressing linearRGB  
values anyway. As I tried to explain, the color space conversions only  
happen inside the component responsible for compositing (blending,  
drawing...) an image onto another. Implementation details need not be  
specified. Ideally, linear RGB arithmetic would be done in 32-bit floating  
point, or at least 16-bit fixed point to avoid visible color banding at  
low intensities.

And yes, it should look the same as color-interpolation="sRGB" as long as  
there's no alpha-blending or color gradients involved.

- Osmo
Received on Thursday, 10 February 2011 10:24:12 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:47 GMT