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

Re: painting-render-02-b.svg

From: Dirk Schulze <vbs85@gmx.de>
Date: Thu, 10 Feb 2011 11:56:36 +0100
Cc: www-svg@w3.org
Message-Id: <128CC8A6-4666-4468-B4B1-F88FA6FFD4E1@gmx.de>
To: Osmo Jaakkola <orbik@iki.fi>

Am 10.02.2011 um 11:22 schrieb Osmo Jaakkola:

>>> 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.
Yes, the transformation just applies to the color values, sorry.

> 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:
> http://www.w3.org/TR/SVG/types.html#DataTypeColor
> 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
Thanks for the clarification!

Received on Thursday, 10 February 2011 11:04:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:24 UTC