Re: SVG Compositing

THIS IS A RESEND. I DO NOT THINK IT WENT TO EVERYBODY ON THE CC...

The only confusion remaining is just the difference between formulas.

 The formulas in the new spec are all there for the basic porter duff
 operators but are partial for the other pdf style blend modes like
 colorburn.

 But in the SVG document http://www.w3.org/TR/SVGCompositing/ the
 formulas are all complete.

 Also it is nice that the formulas in
http://www.w3.org/TR/SVGCompositing/ are guaranteeing a premultipled
 output, but there are cases for use in a canvas where it is beneficial
 to have either premultipled or non-premultipled input and output.

 I assume that for most imps it is enough to just describe the
 premultiplied cases, like for the old
http://www.w3.org/TR/SVGCompositing/ document.

 To try and straighten out the confusion I experienced, it is between
 how you draw once onto some pixels and then draw again onto the same
 pixels.

 The formulas in the new document describe using unpremultipled stuff
 but they return a premultiplied value. If you plonk the result into
 the pixel and then draw into the same pixel again you would need to
 unpremultiply to run the formula again if reading it naively.

 So the formulas in http://www.w3.org/TR/SVGCompositing/ are easier to
 read as far as understanding the process for drawing like multiple
 times onto the same place. It is just confusing to kind of loop the
 result pixel back into the next formula as described in the new
 document, and again the new document does not describe full formulas
 like the other older document.

 In addition, there is a place in the
http://www.w3.org/TR/SVGCompositing/ document that describes the
 difference between "Dca" and "Dc" but that is a long way from where
 the formulas are stated nicely using the Dca approach.

 So to try and communicate what my confusion was I guess it was the
 notation and also the lack of full formulas for both premultipled and
 unpremultipled cases.

 And lastly how does a premutliplied result pixel get written into a 24
 bit bitmap or a 1 byte bitmap for example. I read you say to matte it
 with white like before displaying on a screen.

 So what I did for a premultiplied case is to just assume that when
 writing premultiplied results to 24 bit bitmaps is...

   24Bit.Red = 32PM.Red + (255 - 32PM.Alpha)
   24Bit.Blue = 32PM.Blue + (255 - 32PM.Alpha)
   24Bit.Green = 32PM.Green + (255 - 32PM.Alpha)

 This is same effect as matte it with white? Thus the color can then be
 sent to the output with Bitblt or whatever the display requires.

 So again. The confusion in the documents for me is a kind of lack of
 description about how the model of drawing and then drawing again
 works, and how it relates to underlying pixel formats such as taking a
 premultiplied result to screen or to 24 bit bitmap goes.

 But I understand it all now. Just maybe this info will help with your
 work. Thanks very much.

On 8/6/12, Rik Cabanier <cabanier@gmail.com> wrote:
> Yes, please let us know if you find something in the latest spec confusing
> or if you find a bug.
> Also, if you spot differences (apart from combining blending and
> compositing) let us know as well.
>
> Rik
>
> On Sun, Aug 5, 2012 at 3:30 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>
>> On Sun, Aug 5, 2012 at 2:46 AM, Bob Holmes <rangsynth@gmail.com> wrote:
>> > There is an SVG document called "Compositing and Blending 1.0" dated
>> > "25 July 2012" somewhere around and it splits the compositing and the
>> > blending into two steps. That made for sense to me but now in the
>> > other SVG spec with the "comp op" properties it puts the blenders and
>> > the compositors into the single property, so therefore the result of a
>> > multplication or overlay is not then subject to any further
>> > compositing operator.
>>
>> The "Compositing and Blending" spec you mention
>> <http://dvcs.w3.org/hg/FXTF/raw-file/tip/compositing/index.html> is
>> the one you should be paying attention to.  Anything else is an old
>> draft that has been superceded by the new one I just linked to.
>>
>> If there's anything confusing in the C&B draft, let us know, but you
>> can safely ignore any confusion stemming from the old drafts.  ^_^
>>
>> ~TJ
>>
>>
>

Received on Sunday, 5 August 2012 23:26:16 UTC