RE: Comments on SVG Compositing

Hi Tab,

Thanks for the feedback. Please see my initial comments below.

(Alex, feel free to jump in and correct if you think it is inaccurate)

> -----Original Message-----
> From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
> Of Tab Atkins Jr.
> Sent: Saturday, 9 April 2011 10:46 AM
> To: Rik Cabanier
> Cc: www-svg
> Subject: Re: Comments on SVG Compositing
>
> On Fri, Apr 8, 2011 at 4:41 PM, Rik Cabanier <cabanier@gmail.com>
> wrote:
> > I'm not familiar with the "clip-to-self" concept so it's better if
> > someone else responds to this.
>
> 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.
>
>
> >> >> 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?
> >> >>
> >> > knock-out = how objects within the container blend with each other
> >> > enable-background = how objects within the container blend with
> the
> >> > background The programming logic between the 2 modes is very
> >> > different so I think that this is enough for a separate attribute.
> >>
> >> Your description makes them seem even more similar.  ^_^  From the
> >> POV of an author with relatively little graphics experience, there's
> >> no important difference between these two for me.  The fact that
> >> implementations might implement the two in different fashions is
> >> irrelevant to me, because I'm not an implementor.
> >>
> >>
> >> > If you unify them into 1 property, it would also result in many
> states:
> >> > knock-out (= 3 states) * enable-background (= 3 states) = 9
> >> > different names which is more confusing.
> >>
> >> I'm not sure I understand.  'knock-out' and 'enable-background' have
> >> only two states each.
> >
> > They also have separate 'inherit' states.
>
> Ah, yeah, I naturally ignore that, since *all* properties have an
> 'inherit' value (and 'initial', too).
>
>
> >> Further, the syntax seems like it can be very simple; something
> like:
> >>
> >> comp-over: none | [ group || [ background | rect(x,y,w,h)] ]
> >>
> >> ...with 'comp-over: group background;' being the default.
> >>
> >
> > Does 'group' correspond with 'knockout = false'?
>
> Yes.
>
>
> >> The only thing that would let me justify this being split into two
> >> property would be if it seems like it's useful to have these cascade
> >> separately.  I don't have enough experience with using these to
> >> understand if that's something important or not.
> >
> > Adobe applications have the ability to control the 2 properties
> > independently including the 'inherit' state.
> > I believe this was done because they are conceptually different for
> > designers.
> > ie see these articles:
> > http://layersmagazine.com/the-joys-of-isolation-blending.html

> > (enable-background is the same property as isolate)
> > http://www.creativepro.com/article/illustrator-how-this-technique-a-

> re
> > al-knockout In our apps, the default state of 'knockout' is 'inherit'
> > while 'enable-background'/'isolate' is 'true'/'false' by default.
> > (In our imaging model, the 2 values are simple booleans. The
> > application is expected to resolve the 'inherit' value before
> > exporting to PDF)
>
> Hm, okay.  If that's a reasonable default, then it does make sense to
> keep them split.  (By the way, thanks for the links!  I now understand
> the use of knock-out really well - it lets you paint with transparent
> colors the same way you do with opaque, where you can fill a big area
> with color and then draw the details on top of it.)  I can definitely
> see how inheriting 'knock-out' by default is a good idea.  This also
> means that 'knock-out' should probably be an inherited property.
>
> In that case, try this on for size:
>
> 1. Rename the property/values of clip-to-self in the way I suggested.
> Change the lacuna value to 'src', as this se
>

To clarify, the 'clip-to-self' property:
 - controls the output region affected by the 'comp-op' property.
 - is NOT a compositing operator
 - is NOT a clipping operator

The first compositing example given in the 'clip-to-self' property is an example of what the different 'comp-op' output looks like when different 'clip-to-self' values are used. The 'clip-to-self' property controls the canvas (background) region affected by compositing operator, it does not affect the clipping properties of the operator specifically. The reason various results are clipped is due to the combination of the compositing operator (defined by 'comp-op') and the canvas region affected (defined by 'clip-to-self').

There are some important points that you may have missed about Porter-Duff operators:
1. After an object is composited to the canvas the object becomes part of the canvas. Hence, there is no way to get back an object that has been previously composited on to the canvas according to Porter-Duff operators. There is no notion of retaining the geometry of previously composited shapes in Porter-Duff even though an implementation may retain the geometry for other purposes.
2. The opacity values for regions on canvas (destination - dst) and for the object (source - src) can make a big difference to the result of a compositing operation. Porter-Duff compositing is about combining the colour and opacity of the canvas and an object using different mathematical operations. In the Porter-Duff model the "over" operation (default graphics rendering operation) is just one of the mathematical operation for combining colour and opacity values.

By default, when an object is composited to the canvas it affects the entire canvas regardless of whether it overlaps an object or not. Hence the 'clip-to-self' value name "canvas". The property states: "Compositing an object effects all the pixels on the canvas...". By default when the 'comp-op' property is used on a graphics element, the object will affect the entire canvas.

When the 'clip-to-self' value is set to "object", only the canvas covered by the object to be composited is affected. Hence, the value name "object". The property states: "Compositing an object only effects the pixels covered by the object...". If you look closely at the first example given when 'clip-to-self' is set to "object", you will notice that the region of the canvas ("dst") that is affected by the compositing operator is the region covered by the "src" object. In all cases ('clear' excluded) the "dst" still remains a perfect circle with a modified quarter in some cases.

So to clarify, what you are suggesting seems to be applying a clip around the object after compositing? This is different to what the 'clip-to-self' property actually does. If property name were to change, the only sensible name I can think of would be 'comp-op-region'. In any case, its behaviour and its values are defined clearly and make sense.

The cool idea you are suggesting is better achieved by making a new property that clips the result. The reason is clipping is a secondary operation. If an object is composited, on to the canvas it will affect the entire canvas, and in some cases it may be difficult to determine what the resultant colour for a specific object will be until the compositing operation is performed. Hence, what should happen in this case is:
 1. Perform compositing operation as per 'comp-op' and 'clip-to-self'
 2. Perform the clipping operation.

The property could be called 'comp-op-clip' with values: "none" and "object". Due to the fact that once an object is composited to the canvas it becomes the canvas, having clip values of "dst" and "intersection" are nonsensical in this case. This however, raises an interesting question about what happens to the canvas when clipping to the source object. From my experience, I think it would mean that all the of the canvas is cleared except for the area inside the clipping region.

All that said, I think to achieve the results you want, it is probably better to just use regular SVG clipping rather than feature creep the compositing module ;-)

> 2. Keep knock-out's current name and values.  Make it an inherited
> property.
>

Good idea about making the property inherit!

> 3. Rename 'enable-background' to 'comp-children-over', with values of
> "transparent | background | rect(x,y,w,h)".  This matches my mental
> model a bit better, where the property affects what I composite the
> children of the group over.
>

I disagree. The idea of the property is to control how the background of a group is initialised and managed. The property is unrelated to the actions carried out with the group after objects are placed into it. If anything, the property should be named 'initialise-background'. However, renaming is out of the question because the bigger issue is 'enable-background' exists in SVG 1.1 filters and the SVG Filters specification. SVG 1.1 'enable-background' contains the same values "accumulate" and "new". I think it would be a bad idea for Compositing to define something completely different given that parts of the Compositing specification are to be back ported to Filters at a later date.

> It would also be *awesome* to use that post as an example for enable-
> background/comp-children-over, and put in some note about why knock-out
> is useful.
>

No worries. I'll see what I can do up as far as examples go. I agree it will be useful to add a note about why knock-out is useful.

Something that may be of interest to you is this paper: http://www.svgopen.org/2005/papers/abstractsvgopen/


Cheers,
Anthony

> ~TJ

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Received on Thursday, 14 April 2011 04:37:51 UTC