Re: Comments on SVG Compositing

Hi Tab and Rik,

	Well since you asked, it's time for a trip down
memory lane...

	Once upon a time there was this idea of improving
the rendering capabilities of SVG to include stuff that is
and was in common use. That was way back before 2002 in fact.
The fruits of that endeavour resulted in the Last Call Working
Draft of SVG 1.2 dated 27th Oct 2004. You can read it here:

http://www.w3.org/TR/2004/WD-SVG12-20041027/rendering.html#compositing

	I think you'll find it's remarkably similar to the
current Last Call draft as a module including the unfortunate
use of 'effect' instead of 'affect' all over the place, but I digress.

	Later the WHATWG shamelessly ripped off all this work
to put it into Canvas so some fruit company could implement
fancy graphics for their music application and the reasoning was
lost since no attribution of the SVG Working Groups work ever
happened - after all imitation is the sincerest form of flattery:-)

	So why is it so strange you ask?

	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.

	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.

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

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

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.

Alex

>~TJ
>
>
>

Received on Thursday, 14 April 2011 02:04:22 UTC