Linear RBG and feComposite "arithmetic"

>>>>> "JM" == Jim Mork <jmork@jasc.com> writes:

JM> Several months ago, I ran into some problems achieving the proper
JM> results with filter effects.  The problem stemmed from not using
JM> "linearRGB" as the default for "color-interpolation-filters" (see
JM> spec 11.7.1).  That correction seemed to take care of most of the
JM> problems, but there's another problem now related to the use of
JM> feComposite with the "arithmetic" option (actually, it appears
JM> this problem is affecting our implementation of feComposite
JM> generally.)

JM> An SVG sample is included at the end of this message.  The sample
JM> is the result of reducing the composite example in the test suite
JM> down to elements essential to demonstrating the problem.  The
JM> example consists of two overlapping rectangles--one solid cyan
JM> (R=0,G=255,B=255,A=255) and one solid magenta
JM> (R=255,G=0,B=255,A=255).  The feComposite "arithmetic" filter
JM> effect is applied using "SourceGraphic" (magenta rectangle) and
JM> "BackgroundImage" (part of cyan rectangle) as inputs.  Each image
JM> is multiplied by the coefficent 0.5--add half of each together.

JM> Normalizing colors to range of 0 to 1 (for clarity):
    
    [...]

JM> I'm not sure which is the correct result.  Adobe's plug-in returns
JM> (128, 128, 255, 255) but if that result is converted back to sRGB
JM> from linearRGB, the result is (186, 186, 255, 255).  Perhaps I've
JM> missed something in the spec and/or I doing something wrong, but
JM> that is the result I get when my effect processing is consisted in
JM> its use of linear RGB.

JM> Any help or suggestions will be much appreciated!

    Once I add a 'g' element with 'enable-background="new"' (you did
not have any thing turning on the background image) around the
rectangles, Batik give's (188, 188, 255) for the middle rectangle, I
assume the 2 code value difference is due to Batik using the more
complete Gamma calculation.  It's possible that part of the problem is
the lack of enable-background, but I don't think so...

    I will point out that unless you specify
color-rendering="optimizeQuality" it is conceivable that the composite
will happen in sRGB vs the correct linear-sRGB (Sec 11.7.2).

    I personally would not read the SVG specification that way (the
specification specifically states that in the 'auto' case quality
should be given more importance than speed - i.e. do the composite in
linear), but it's possible Adobe decided to favor speed anyway, it's
also possible you found a bug in the way they handle linear sRGB.

    Aside from the color-rendering issue, given that Batik generates
what you suggest above 'out of the box' and it looks right to me
anyway, it would tend to give a lot of weight to your expected results
being the right one.

JM> Sincerely,

JM> James Mork Principal Software Engineer Jasc Software Inc.

JM> ---snip-- <?xml version="1.0" standalone="no"?> <!DOCTYPE svg
JM> PUBLIC "-//W3C//DTD SVG 1.0//EN"
JM> "http://www.w3.org/TR/2001/PR-SVG-20010719/DTD/svg10.dtd"> <svg
JM> width="100" height="100"> <defs> <filter id="xfilter"
JM> filterUnits="objectBoundingBox" x="-5%" y="-5%" width="110%"
JM> height="110%"> <feComposite in="SourceGraphic"
JM> in2="BackgroundImage" result="comp" operator="arithmetic" k1="0"
JM> k2="0.5" k3="0.5" k4="0"/> </filter> </defs> <rect x="20" y="10"
JM> width="40" height="82"
JM> style="fill:rgb(0,255,255);stroke-width:1"/> <rect x="42" y="10"
JM> width="38" height="82"
JM> style="fill:rgb(255,0,255);stroke-width:1;filter:url(#xfilter)"/>
JM> </svg> ---snip---

Received on Monday, 10 September 2001 08:11:15 UTC