Re: Clarifying the behavior of SVG arithmetic feComposite filters

Yes, I did not wish to imply that there was agreement among Webkit
folks, just that there was an open discussion.

The data in question are not "undefined" pixels. The spec clearly
defines how to compute arithmetic pixels, but not what to do with the
invalid results. Existing implementations do not set invalid pixels to
(0, 0, 0, 0); they continue to process them throughout the filter
stack (it seems). At what point should they be set to (0, 0, 0, 0)? It
makes a difference in the result.

What do we do with a pre-multiplied pixel that is (1.0, 1.0, 1.0,
0.5)? The most sensible thing seems to be (0.5, 0.5, 0.5, 0.5), but
it's not defined in the spec.

I'm guessing you like option 3 below. Is that right?

Stephen.

On Tue, Feb 7, 2012 at 11:33 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> Hello Stephen,
>
> Not the whole WebKit team is concerned about that behavior ;). I think the
> spec is clear about that:
>
> "Sometimes filter primitives result in undefined pixels. For example, filter
> primitive ‘feOffset’ can shift an image down and to the right, leaving
> undefined pixels at the top and left. In these cases, the undefined pixels
> are set to transparent black." [1]
>
> A premultiplied color with alpha 0 should just be transparent black.
>
> Greetings
> Dirk
>
> [1] http://www.w3.org/TR/SVG/filters.html#Introduction
>
> On Feb 7, 2012, at 7:31 AM, Stephen Chenney wrote:
>
> The SVG 1.1 (Second Edition) – 16 August 2011 feComposite filter
> operation (http://www.w3.org/TR/SVG/filters.html#feCompositeElement)
> currently defines arithmetic composite to act on pre-multiplied rgba
> pixels, just as the other feComposite operations do. Combined with the
> per-component nature of the filter, this allows the filter to generate
> invalid pre-multiplied rgba values both as intermediate results and
> the final output. For example, this filter sequence:
>
> <!-- This filter produces intermediate results that are invalid
> pre-multiplied rgba pixels. -->
> <!-- Specifically, after the 4th step an interior pixel will contain
> (0, 0.8, 0, 0.5) which -->
> <!-- is invalid because g > a. When used in other operations, this may
> generate bad results. -->
> <filter id="arithmetic">
>  <feComposite operator="arithmetic" in="SourceGraphic"
> in2="SourceGraphic" k1="0" k2="0.2" k3="0" k4="0" result="rgba02" />
>  <feComposite operator="arithmetic" in="SourceAlpha"
> in2="SourceAlpha" k1="0" k2="0.3" k3="0" k4="0" result="alpha05" />
>  <feComposite operator="arithmetic" in="rgba02" in2="alpha05" k1="0"
> k2="1" k3="1" k4="0" result="tmp" />
>  <feComposite operator="arithmetic" in="SourceGraphic" in2="tmp"
> k1="0" k2="1" k3="-1" k4="0" />
>  <feComposite operator="arithmetic" in="tmp" k1="0" k2="1" k3="1" k4="0" />
> </filter>
>
> An invalid pixel is anything with color component greater than alpha.
> The easiest way to produce invalid pixels is in a subtraction
> operation (k1=0, k2=1, k3=-1, k4=0), when one opaque image subtracted
> from a different opaque image will generate an entire image of alpha =
> 0 pixels that have non-zero color components.
>
> The Webkit team is concerned with this behavior because the invalid
> pixels may feed into other operations and pollute the entire image. We
> would like to tighten the spec on arithmetic filter operations to
> preclude this behavior.
>
> Option 1 is to define arthimetic feComposite to act on regular rgba
> pixels. This prevents any issue of invalid data and is probably easier
> for content authors to reason about. On the downside, it may be costly
> to convert between pre-multiplied and regular pixel representations.
>
> Option 2 is to modify the spec section 15.12 from this statement "with
> the result clamped between [0..1]" to this statement "with alpha
> clamped to [0..1] and color components clamped to [0..alpha]". This is
> the simplest change that ensures valid pixels everywhere.
>
> Option 3 is to modify the spec to require that arithmetic results be
> clamped to valid pre-multiplied pixels before use in any other filter
> operation, while intermediate arithmetic results must clamp only to
> [0..1] per component. This seems to match current behavior in Opera,
> Firefox and Webkit, although I have not extensively tested. I think
> the behavior just falls out of current pixel conversion methods for
> pre-multiplied to regular pixels, although Webkit catches the problem
> in debug builds.
>
> Personally I support Option 2 as it is least disruptive and simplest
> to implement, although I am also satisfied with Option 1.
>
> Regardless of which clarification is chosen, in the interests of
> cross-browser consistency we would like the spec tightened.
>
> Stephen.
>
>

Received on Tuesday, 7 February 2012 16:54:48 UTC