Re: painting-render-02-b.svg

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

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

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.

- Osmo

Received on Thursday, 10 February 2011 06:14:50 UTC