Re: painting-render-02-b.svg

Am 10.02.2011 um 07:13 schrieb Osmo Jaakkola:

> 
>>>> All white rects have the same transparency level and are drawn onto asolid black background. Just the rects on the first row are filled witheither #7F7F7F or #BBBBBB but don't test color-interpolationat all.
>>>>> Yes. On both the source and the background.
>>>> Ok, this is maybe the point where I have the understanding problems. Istill read the Spec this way: At first we have the canvas, whereeverything is drawn on by the compositing algorithm mentioned on thelink you posted.
>>>> Now we want to draw a shape onto this canvas in the color spacelinearRGB while the canvas itself is in sRGB.
>>>> For a better understanding I'll take a surface/buffer where I draw theshape onto. This surface with the shape gets transformed to linearRGB.Now I draw this surface on the canvas by compositing it with thealgorithm of the spec respecting the transparence that is set by theproperty 'fill-opacity'.
>>>> For the example on the test suite, it means we would draw the rect ontothe canvas with the fill color white. Now we transform this surface tolinearRGB. But because we filled the shape with white: rgb(255,255,255)the linearRGB transformation doesn't influence the surface. According tothe sRGB to linearRGB algorithm of the Spec, the resulting color valuesare rgb(255,255,255).
>>>> At the end we draw the surface on the canvas with the 'fill-opcity:0.5'by compositing it to the canvas.
>>>> The background is black, so we see the same gray independent if we drawthe rect with linearRGB or sRGB.
>>>> We might of course see a difference if we'd use another fill color thanwhite. But I don't get it why we should see a difference on this test.
>>> 
>>> Because the alpha blending is done in linear RGB, and needs to be converted back to the parent's (canvas') color space.
>>> 
>>> Background = sRGB(0, 0, 0) => linRGB(0, 0, 0)
>>> Foreground = sRGB(1.0, 1.0, 1.0) => linRGB(1.0, 1.0, 1.0)
>>> Opacity = 0.5
>>> Result = linRGB(0.5, 0.5, 0.5) => sRGB(0.735, 0.735, 0.735)
>> 
>> That would mean, we draw the content to the canvas ad transform the relevant parts afterwards to linearRGB ?!?
>> If I take your example. I'd see it like this:
>> 
>> Background = sRGB(0, 0, 0) => linRGB(0, 0, 0)
>> Foreground = linearRGB(1.0, 1.0, 1.0) => sRGB(1.0, 1.0, 1.0)
>> Opacity = 0.5
>> Result = sRGB(0.5, 0.5, 0.5)
>> 
>> The color space of the shape with color-interpolation="linearRGB" should be transformed, not the canvas after the compositing operation. Of course I could be wrong. It's just not clear to me, why we should transform the resulting image instead of your foreground.
>> 
>> Cheers
>> Dirk
> 
> 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.

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

> 
> However there might be confusion as to which object's color-interpolation property should be used - the parent or the child object's? Logically, either could make sense, since the compositing happens at the interface of the two. But only respecting the child object's property allows different elements be composited with different methods, which is demonstrated in test in question, so I believe that's what is implied in the SVG specification. Besides it's probably technically somewhat simpler to implement.
The spec: "When a child element is blended into a background, the value of the ‘color-interpolation’ property on the child determines the type of blending, not the value of the ‘color-interpolation’ on the parent."[1]
Even if the following sentence is talking about a gradient that references another gradient with different color-interpolation, I'd interpret the sentence the same way you did.

Dirk

[1]  http://www.w3.org/TR/SVG/painting.html#ColorInterpolationProperty