Re: [filter-effects] color-interpolation-filters

I haven't tested feDisplacementMap but the spec seems to be clear about its
behavior.

It only makes sense, to me, that the conversion between color spaces
happens on un-premultiplied colors. This is what I assumed in adding
linearRGB support in Inkscape and my tests seem to confirm that this is
what all renderers are doing.

I assumed that feFlood would be like feTurbulence in that the values are
defined in the color space of the filter primitive. This is what Webkit is
doing now... but not Firefox and Opera (or Batik) which assume sRGB.
Whatever is done for feFlood should be also done for  feSpecularLighting
and feDiffuseLighting. For feDiffuseLighting, both Firefox and Chrome use
the color space of the filter primitive while Opera assumes sRGB. There is
no consistency at all for feSpecularLighting.

I've attached a test file. For each filter primitive tested, there is a
test with sRGB (left) and with linearRGB (right). A test fails if the inner
square does not match the outer square. Tests for feBlend, feMerge, and
feComposite depend on feFlood. I am not 100% sure the test for
feSpecularLighting is correct. The two vertical lines in the
feConvolveMatrix test are expected.

Tav



On Tue, Jan 8, 2013 at 1:18 AM, Dirk Schulze <dschulze@adobe.com> wrote:

> Hi,
>
> I filed a bug report on
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20591
>
> Thanks for bringing this up.
>
> Greetings,
> Dirk
>
> On Jan 7, 2013, at 6:09 AM, Stephen Chenney <schenney@chromium.org> wrote:
>
> > You read my mind. I'm working in this area in WebKit right now and am
> also confused about the expected behavior. My plan is to try to match Opera
> and Mozilla, as they seem to agree on feDisplacementMap behavior. It would
> be nice if I did not have to reverse engineer the spec.
> >
> > Another question: Does the color-interpolation-filter property get
> applied before or after premultiplied/un-premultipled color conversion?
> Because color space conversions are non-linear, the results vary depending
> on the order of operations.
> >
> > When you talk about feFlood, I would expect the color is defined in sRGB
> space, but then it could be converted to linearRGB for the fill if the
> color-interpolation-filters indicates to do so. What happens next depends
> on how the flood is used, but if you just display it I'm guessing that the
> results are converted back to sRGB for display, leaving you with the
> appearance of ignoring the color-interpolation-filter (i.e. Opera and
> Mozilla are right).
> >
> > Stephen.
> >
> >
> > On Mon, Jan 7, 2013 at 8:54 AM, Tavmjong Bah <tav.w3c@gmail.com> wrote:
> >
> > Hi,
> >
> > I've recently added support for the value 'linearRGB' for the property
> > 'color-interpolation-filters' to Inkscape (previously, Inkscape assumed
> > a value of 'sRGB'). I found the SVG 1.1 specification to be not very
> > clear as to how this property is suppose to be implemented in all cases.
> > The Filter Effects draft seems to just have copied the SVG 1.1 text so
> > there has been no improvement. The effect of the property is only
> > specifically defined for feDisplacementMap and feTurbulence. My best
> > guess as to how things should be implement (dividing the filters into
> > three classes) is:
> >
> > Assuming a value of 'linearRGB':
> >
> > Composite like:
> >
> >   Input(s) transformed to linearRGB if not already in linearRGB
> >   Output linearRGB
> >
> >   feBlend, feColorMatrix, feComponentTransfer, feComposite,
> > feConvolveMatrix, feGaussianBlur, feImage(?), feMerge,
> >
> > Source like:
> >
> >   Output in linearRGB (following spec for feTurbulence)
> >
> >   feFlood, feTurbulence, feDisffuseLighting, feSpecularLighting
> >
> > Copy like:
> >
> >   Output is same as input (following spec for feDisplacementMap)
> >
> >   feDisplacementMap, feMorphology, feOffset, feTile
> >
> >
> > Note: Firefox and Opera currently interpret feFlood color as being
> > defined in sRGB while Chrome follows the value of
> > color-interpolation-filters.
> >
> >
> > Tav
> >
> >
> >
> >
> >
>
>

Received on Tuesday, 8 January 2013 11:27:22 UTC