[Compositing] Some comments

I just read through the Compositing module.  Below are some comments.  I
don’t think any of these need to hold up publication.


Over the whole document
-----------------------

The second headings for 4.1.1, 4.2.1, 4.3.1 and 5.1.1 can probably be
dropped, since they seems repetitive with their parent section.  That,
or maybe rename the parent section to be something more descriptive,
such as:

  4.1 Clipping compositing operations
    4.1.1 The ‘clip-to-self’ property
  4.2 Accessing the background image
    4.2.1 The ‘enable-background’ property
  4.3 Removing the background image before compositing
    4.3.1 The ‘knock-out’ property

  5.1 Selecting a compositing operation
    5.1.1 The ‘comp-op’ property


s/Porter Duff/Porter-Duff/g (or s/Porter-Duff/Porter Duff/g) in the
whole document.


s/This section in normative/This section is normative/g in the whole
document.


s/nitialis/nitializ/g in the whole document.


Introduction
------------

  This document contains explicit conformance criteria that overlap with
  some RNG definitions in requirements. If there is any conflict between
  the two, the explicit conformance criteria are the definitive
  reference. 

There isn’t any RNG for the properties defined in the spec, yet.  Is
this going to be added?


  By defintion compositing is the process by which the colors of objects
  (and their surrounding regions) are combined together.

s/defintion/definition/


  Compositing involving the alpha channel is referred to alpha
  compositing.

s/to/to as/


  * clipping paths, which use any combination of ‘path’, ‘text’ and
    basic shapes to serve as the outline of a 1-bit mask (in the absence
    of anti-aliasing), where everything on the “inside” of the outline
    is allowed to show through but everything on the outside is masked
    out
  * masks, which are container elements which can contain graphics
    elements or other container elements which define a set of graphics
    that is to be used as a semi-transparent mask for compositing
    foreground objects into the current background. 

Clipping paths and masks don’t seem to be defined in this module.  Are
they going to be?


2 Terms Used in This Specification
----------------------------------

  Initialisation of a group image buffer is controlled by the
  ‘enable-background’ property. Elements nested within the container
  element are rendered into the group image buffer.

s/Initialisation/Initialization/, for pubrules.


3 Alpha Compositing
-------------------

  As out lined in their paper Compositing Digital Images, Thomas Porter
  and Tom Duff defined algebra expression for compositing.

s/out lined/outlined/
s/expression/expressions/

  The opacity value should be clamped between zero and one inclusive,
  and the pre-multiplied color value should be clamped between zero and
  the opacity value inclusive.

Later, it is said that the UA MUST clamp them, so s/should/must/g or
s/should be/are/g.

  Da(d)
    Group alpha buffer containing the percentage of the background
    channel in the group buffer.

What does percentage mean here?  Is this buffer just the alpha channel
of the background channel?


3.1 Alpha Compositing Syntax
----------------------------

In this section it says the UA must clamp colour, opacity and
premultiplied colour values, but it doesn’t say when this clamping
should occur. Is it just when the final image is sent to the rendered on
the output device?


4.1 The ‘clip-to-self’ property
-------------------------------

  Container elements where the ‘clip-to-self’ property is set to object
  only effect the pixels within the extent of the container element. For
  example, if a container element contains two circles, and the
  container element has the ‘clip-to-self’ property set to object, then
  nothing outside the circles is effected.

s/effect/affect/g

  For images and filters, the bounds of the object are converted to a
  clipping region. 
  
What exactly is the bounds of an image?  For example, if
preserveAspectRatio has been used to shrink the image within its x/y/
width/height box, is the bounds just where the image has been rendered,
or is it the x/y/width/height box?

  For some container elements where the ‘clip-to-self’ property is set
  to canvas, the container element might effect the background outside
  bounds of the container element.

s/effect/affect/


4.1.1 The ‘clip-to-self’ property
---------------------------------

s/effect/affect/ in the whole section.

It would be good to link “container elements” and “graphics elements” to
their definitions.

  Compositing an object only effects the pixels covered by the object

Missing a full stop.

  Compositing an object effects all pixels on the canvas by compositing
  completely transparent source onto the destination for areas not
  covered by the object.

s/completely/a completely/ ?

   This property was changed from a boolean value. Where a value of
   ‘object’ was equivalent ‘true’ and a value of ‘canvas’ was equivalent
   to ‘false’. Is this an acceptable change?

Yes I think they’re reasonable names.  Note that the example files still
use clip-to-self="true".


4.2 The ‘enable-background’ property
------------------------------------

  This group image is treated as the canvas for the containers’s
  children.

s/containers/container/

  This buffer Da(d) stores the percentage of the background in the group
  image and is initially opaque.

Does this mean the buffer just contains 1s?

  1. The canvas color is removed from the group image color. 

What exactly does removing mean, here?

In this section I don’t think it’s clear where the
enable-background="accumulate"-specific parts end, and the common parts
(which also apply to enable-background="new") resume.


4.2.1 The ‘enable-background’ property
--------------------------------------

What’s the reason ‘enable-background’ is not animatable?  Is it just
because it isn’t in SVG 1.1?

  If not all the <x>, <y>, <width> and <height> values are specified,
  or if either <width> or <height> are specified as a value less than
  1, then the objects are composited as if the ‘enable-background’
  property was set to accumulate.

Why not say if they are specified as ≤ 0 that the objects are composited
as if enable-background="accumulate"?

I think you should define what syntax <x>, <y>, <width> and <height>
have.  Are they <length>s or <number>s?

  Elements containing a ‘comp-op’ property value of clear, src, dst,
  dst-over, src-in, dst-in, src-out, dst-out, src-atop, dst-atop, xor
  can potentially reduce the opacity of the destination and are only
  valid where one of the element’s ancestorial container element has the
  ‘enable-background’ property set to new.

s/ancestorial container element/ancestor container elements/

  For elements without an ancestor with the ‘enable-background’ property
  set to new these operations are technically an error.

Is this worth an “in error” condition?  The pink box below that defines
what compositing operation must be used instead in this case, so I don’t
know that it’s worth stating that it’s an error.


4.3 The ‘knock-out’ property
----------------------------

  For each object within the container element, the object color and
  opacity replaces that of other objects, rather than overlaying it.

Is this only the case when knock-out="replace"?  If so, then state that,
otherwise it sounds like it is the case all the time.

  An element in a knockout group that does not have the ‘clip-to-self’
  property set, in effect clears all prior elements in the group. 

‘clip-to-self’ set to what?

This section mentions “complex groups”, but it doesn’t define what that
means.  Is it a group with more than one child?  Is <g><circle/><g/></g>
a complex group?

  This property was changed from a boolean value. Where a value of
  ‘replace’ was equivalent ‘true’ and a value of ‘preserve’ was
  equivalent to ‘false’. Is this an acceptable change? 

Those names are fine with me.

  A User Agent MUST effect the color and opactiy of the objects within
  the container element as specified by the ‘knock-out’ property.

s/effect/affect/
s/opactiy/opacity/


5.1 The ‘comp-op’ property
--------------------------

Is it possible to reduce the size of the image that shows the sub-pixel
regions used by each of the compositing operations?

Also, the underscores in the names need to be replaced with hyphens to
match the values you can give the ‘comp-op’ property.  This applies to
the example SVGs too, where the operator appearing in the black bars at
the top and bottom have underscores.

It’d be good also if there were a legend explaining that yellow means
the source colours are passed through without modification, blue means
destination colours are passed through without modification, and rainbow
means some combination of the source and destination colours results.

  overlay
    The destination color is used to determine if the resultant is
    either a multiplication or screening of the colors.

Missing a word after “resultant”?  Maybe “color”?

  exclusion
    The resultant color is similar to that of the difference
    operation. However, the exclusion resultant color appears as a
    lower contrast than that of of the difference resultant color.

s/of of/of/

   These equations are approximations which are under review. Final
   equations may differ from those presented here.

Is this still true?

   A User Agent MUST effect the color and opacity of the objects within
   the container element as specified by the ‘comp-op’ property. 

s/effect/affect/


6 References
------------

There aren’t in-text references to the three entries in this section.  I
suggest you change the link in section 3 to:

  As outlined in their paper <cite>Compositing Digial Images</cite>
  [<a href='#ref-PorterDuff'>PorterDuff</a>], …

The SVG 1.2 Full WD and SVG12Reqs entries aren’t referred to, so I guess
they can be removed unless you want to refer to them somewhere
explicitly.  There are links to some properties, elements and sections
in SVG Tiny 1.2, so you should add an entry for that.  Similarly for the
SVG Filters module.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Monday, 27 April 2009 02:49:42 UTC