Issue with SVG Compositing Specification (re: the "plus" mode)

www-svg list,

I was recently looking at the SVG Compositing Specification draft dated March 15, 2011 at:

  http://www.w3.org/TR/2011/WD-SVGCompositing-20110315/

and found what appears to be a bug in the math for the "plus" compositing operator.  It is documented as follows:
plus
The source is added to the destination and replaces the destination. This operator is useful for animating a dissolve between two images.
f(Sc,Dc) = Sc + Dc
X        = 1
Y        = 1
Z        = 1

Dca' = Sca × Da + Dca × Sa + Sca × (1 - Da) + Dca × (1 - Sa)
     = Sca + Dca
Da'  = Sa × Da + Da × Sa + Sa × (1 - Da) + Da × (1 - Sa)
     = Sa + Da

The Dca' and Da' result values are consistent with what one would expect from the Porter-Duff "plus" operator, where my understanding is that the most common usage would be to fade from one image to the other

  weight * image1 + (1-weight) * image2
However, the Da' value derived above is NOT consistent with the documented f/X/Y/Z parameterization.  The general math for deriving Dca' and Da' is:

The operation used to place objects onto the background is as follows:

    Dca' = f(Sc, Dc) × Sa × Da  + Y × Sca × (1-Da)  + Z × Dca × (1-Sa)

    Da'  =         X × Sa × Da  + Y × Sa × (1-Da)   + Z × Da × (1-Sa)


The math for Da' in the "plus" documentation above contains an extra "Da x Sa" term not called for by the general math.  Without this extra term, the Da' is the same as in all the other modes with X/Y/Z set to 1/1/1, namely:

  Da' = Sa * Da + Sa * (1-Da) + Da * (1-Sa)

The desired results for Da' can be accounted for by setting X to 2.  However, having non-0/1 values for these coefficients is sort of strange.

I had passed this feedback along to Anthony, who requested that I forward it to the list.  My expectation is that implementers of the standard are most likely to perform compositing using the reduced forms of the equation rather than the f/X/Y/Z parameterization.  To the extent that this expectation is correct, this could simply be viewed as a spec inconsistency needing resolution, with little practical implication on users of the standard.

If you want additional feedback from me, please be sure to include me explicitly on any such emails.  I am not subscribed to the www-svg mailing list.

Thanks,
Pat


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------