From: Mike Reed <reed@google.com>

Date: Tue, 7 Feb 2012 13:08:22 -0500

Message-ID: <CAERTzqysUgCFxuvro4RhxMtt6Qr_NPB_o0Npr=MOG9VrL-gNtQ@mail.gmail.com>

To: Rik Cabanier <cabanier@gmail.com>

Cc: Stephen Chenney <schenney@chromium.org>, www-svg@w3.org, Nikolas Zimmermann <nzimmermann@rim.com>

Date: Tue, 7 Feb 2012 13:08:22 -0500

Message-ID: <CAERTzqysUgCFxuvro4RhxMtt6Qr_NPB_o0Npr=MOG9VrL-gNtQ@mail.gmail.com>

To: Rik Cabanier <cabanier@gmail.com>

Cc: Stephen Chenney <schenney@chromium.org>, www-svg@w3.org, Nikolas Zimmermann <nzimmermann@rim.com>

I also think #1 is the best solution. On Tue, Feb 7, 2012 at 12:36 PM, Rik Cabanier <cabanier@gmail.com> wrote: > I think it was a mistake to have the filters work on premultiplied alpha. > Premultiplied alpha is a trick to make calculations easier, but it should > not be the default. > > So, option 1 is the 'correct' one. > However, I agree that 2 is much simpler since it doesn't break existing > behavior. > > Rik > > On Tue, Feb 7, 2012 at 7:31 AM, Stephen Chenney <schenney@chromium.org>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 Wednesday, 8 February 2012 22:11:08 UTC

*
This archive was generated by hypermail 2.4.0
: Friday, 17 January 2020 22:54:34 UTC
*