Re: SVG Compositing

On Sun, Aug 5, 2012 at 4:25 PM, Bob Holmes <rangsynth@gmail.com> wrote:

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

Correct. This was done intentionally.
The document shows how you can derive the full formula at the end of
https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#blending

Not all implementations may want to combine the formula either (ie
gpu acceleration will most likely not do so)


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

Since a user never has access to the pixels, I don't think this is
necessary.
How this is implemented is up the browser or SVG viewer.


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

Where is that?
The document doesn't say how to implement this so it's again up to browser.


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

premultiplied vs unpremultiplied is just:

cs = αs x Cs



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

Correct.


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

Thank you!
I think we need to work a bit on the language that combines the blending
and compositing to make it less confusing.

Rik


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