Re: Comments on SVG Compositing

Hi Alex and Anthony,

thanks for the replies. They give us more insight into how this spec was
drafted.

       The initial motivation was to include Porter-Duff
> operators and the blend modes (comp-op) only. The reasons were
> that Porter-Duff is used all over the place in film rendering
> etc. with applications like 'Shake' that have since been
> swallowed into large companies, etc. Canon had a lot of
> products shipping in the millions (still do) that require
> Porter-Duff operators, etc. including authoring tools
> and so on. The requirement for Porter-Duff was to allow
> SVG to be used as an exchange format for these sorts of
> tools. To do so, you need all the operators in their basic
> form.
>
>        Importantly, the blend modes - hard-light and so
> on are colour blending operations that only affect the
> mixture of src and destination which is the top multi-
> coloured triangle in the spec section 10.1.2. The blend
> modes are all Porter-Duff 'over' or simple alpha compositing
> as first described by Alvy Ray Smith. The Porter-Duff
> operators are orthogonal to the blend modes.
>

I have this feeling too. Porter-Duff and the Adobe blending modes are very
different.
PD is a mathematical description of compositing, while AIM describes
artistic effects that are easily understandable for a designer.

Because of this, I believe we should split up the SVG compositing proposal
into 2 sections:
1. Porter-Duff + clip-to-self
2. Blending modes + knockout

'enable-background' would apply to both compositing operations.
This will create less confusion and each section can describe how the
compositing is actually supposed to happen.

The link to http://www.svgopen.org/2005/papers/abstractsvgopen/ is very
interesting since it describes the effect of groups on blend modes.
It is an important idiom that the PDF spec devotes an entire chapter
to. This should also become part of the SVG compositing spec.


>        The blend modes in the spec. were defined to support
> the most widely used desktop applications of the day, namely
> Illustrator and Photoshop.
>
>        So, that's where it began. There was no clip-to-self
> or knock-out.
>
>        The group was (understandably) concerned that the
> introduction of some of the Porter-Duff operators could
> affect pixels outside of the geometry of the object and
> that would not be possible to implement on top of existing
> rendering libraries. Notably ASV3 just sits on top of the
> standard core libraries used in other products, whilst Batik
> sits on top of Java2D. True Porter-Duff implementations
> can blast the entire canvas if you do something like 'clear'
> and so this was considered to be a bad precedent.
>
>        More importantly, Java2D as a library:
>
> http://download.oracle.com/javase/1.4.2/docs/guide/2d/new_features.html
>
>        introduced Porter-Duff operators but restricted the
> effect of the operator to the geometry of the object being
> composited. I have no idea why they did that, perhaps for
> efficiency reasons. What happens in Java2D is that they have
> in effect a 'shape' channel and an alpha channel. They are
> different. Compositing happens using the alpha channel and
> it is restricted to the area covered by the shape channel.
> So if you have a completely transparent object with alpha
> of 0, you will still do things with the pixels where the
> transparent object exists.
>
>        So the name 'clip-to-self' was chosen (not by me)
> to make it clear we are talking about geometry of the object
> not the src alpha value. Some implementations use a clipping
> path to restrict the operators, others may use a shape channel
> in addition to the alpha channel, but those are implementation
> details. Note, this property only matters for Porter-Duff
> operators.
>
>        Anyway, sometime around Feb 2002, Adobe people asked
> us to add the knock-out feature and try to align the model
> so that it was compatible with the Adobe imaging model used
> in PDF. That's the motivator for knock-out. If what it does
> is unreadable it's because no-one at Adobe bothered to fix
> our description - since effectively we provided free work
> to stick their stuff in the spec. and they never made any
> effort to correct errors if there were any. There were
> mumblings that our description of knock-out was wrong but
> no attempt to correct it was ever made. I have no idea if
> it does what PDF does since it's not of relevance for any
> workflows I'm interested in.
>

If it's wrong, we should fix it.
The language in the latest PDF spec is pretty clear so we could simply move
it into SVG.


>
>        More inline:
>
> --Original Message--:
> >I *really* don't like the current names of the clip-to-self property
> >or values.  One or both has to be changed; right now the property name
> >is nonsensical with the values, in my opinion.  As a not-very-good
> >suggestion, maybe "clip-to: src | canvas"?
>
> clip-to-self mirrors the initial name given to the property back in 2002:
>
> http://www.w3.org/TR/2002/WD-SVG12-20021115/#compositing
>
> and the 'self' part is meant to highlight that it's a geometric not alpha
> operation. 'src' to me feels like alpha compositing. It's just a name,
> and I don't have any investment in it, nor does the WG I expect but
> do you *really* think it's that bad?
>
> >I don't quite understand the usage of the 'knock-out' property.  I
> >understand what it does, but it seems to apply to rendered elements,
> >while the property is defined to apply to grouping elements.  In the
> >examples given, is 'knock-out' specified on either of the components
> >(the squiggly line or the blue disc), or is it on a container that
> >contains both of the components?
>
> The example is very hard to visualize - we should really refer to
> the PDF spec for improved detail on how it works. But to
> answer your question you just need to click through to the
> SVG source for the example and look at it - knock-out is
> specified on the group with id="f".
>

The PDF spec (while technically correct) will not help you to visualize the
effect of 'knock-out'.
There are multiple websites and books that describe what it does visually
(ie
http://www.creativepro.com/article/illustrator-how-this-technique-a-real-knockout
)


>
> >It appears that all of the first three properties are simply shortcuts
> >for more complex series of compositing operations.  Is this correct?
>
> No.
>
> >For example, in the "knockout:replace" example, it appears that one
> >could achieve the same result with "d over (d dst_out e)".  Similarly,
>
> Not sure - PDF's model is a lot weirder than Porter-Duff from what I've
> been led to believe. But if it's possible to do that it doesn't really
> matter
> as you'll see below where I describe the round-tripping goals.
>
> >the "clip-to-self:canvas" example seems equivalent to "((e xor f) in
> >g) over ((e xor f) dst_out g)".  It might be useful to define these
> >properties explicitly in terms of virtually transforming the comp-op
> >sequence.  'enable-background' is the same, down to the insertion of a
> >dst_out operation.
> >
> >I don't have strong graphics experience, so there may be something I'm
> >missing here, but 'enable-background' and 'knock-out' appear to be
> >*exactly* identical in operation, just applying to different things:
> >'knock-out' transforms "A op B" to "A op (A dst_out B)", while
> >enable-background transforms "[group image] over [background]" to
> >"[group image] over ([group image] dst_out [background]".  Can these
> >two properties be unified in some way?
>
> Adobe people keep telling us that knock-out is different, and they wanted
> the property in the first place for PDF compatibility. I don't think the
> group would have the resources to unify them. More likely is that
> no-one will do 2 implements of the knock-out property and it will go away
> all by itself;-)
>

Tab is correct that you can morph a group with 'knock-out' into a bunch of
PD operations.
The problem here is round-tripping. By decomposing 'knock-out' this way, the
property is lost so programs like Illustrator would no longer be able to
reimport it.
Another problem is that the generated SVG code will get progressively more
complicated the more elements interact with each other.


>
> One of later your mails said:
> > I believe clip-to-self:object (or comp-clip-to:src) is the default
> >behavior in Photoshop.  I suspect that this is the most intuitive
> >behavior for most people, so it would probably be good to just make
> >that the default.
>
> No, the default is to render to the canvas. When using a Porter-Duff
> of 'over' it naturally only affects the pixels in its geometry, but you
> can bet that no restriction or clipping is performed in Photoshop.
> Perhaps we need to point out that 'clip-to-self' only affects the
> Porter-Duff operators. Photoshop has no implementation
> whatsoever for Porter-Duff operators.
>
> This feedback is great and your examples in follow-up mails
> are useful as a math exercise.
>
> But one of the prime motivators in the way this is all structured is
> to provide clean round-trip capability for other graphics formats
> into/out of SVG.
>
> So we have the plain Porter-Duff operators for applications that
> require that. We have the geometry restricted ones via 'clip-to-self'
> for people that want to round-trip Java2D stuff. We also have the
> blend modes and knock-out for people that want to attempt to
> serialize PDF into SVG (albeit with colour model issues that
> can't be expressed in SVG yet).
>
> I'm sure there's lots of detail about the convoluted development
> story behind all this that I haven't described but hopefully this
> makes a bit more sense.
>
> Also Rik asked: "Personally, I think the PorterDuff blending modes are very
> confusing.
> Can't we strip them from the spec and replace them with more descriptive
> one?"
>
> I don't think that's a good idea since they are consistent with
> Java2D's naming,  the original naming in the 1984 paper
> describing them and people that use Porter-Duff are likely to
> scoff at the idea we change them to something else.
>

That is a fair statement. PD definitely is useful.

So, my proposal is to split up the current draft into PorterDuff and
blending modes.
We'll amend the knock-out section to fix potential errors and make it more
descriptive.

As an aside, we probably also want to extend the list of blending modes.
For instance, the current list is missing the following PDF blendmodes: hue
| saturation | color | luminosity
Flash also defines some useful basic blendmodes (such as 'erase') that could
be of interest.

Rik