- From: Osmo Jaakkola <orbik@iki.fi>
- Date: Thu, 10 Feb 2011 08:13:24 +0200
- To: "www-svg@w3.org" <www-svg@w3.org>
>>> 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