Bug 113174 – Composing a filter with the identity function shouldn't change its effect.

• Component: CSS
• Status: RESOLVED CONFIGURATION CHANGED

[Dominic Mazzoni]

Adding an additional identify to the end of a chain of filter primitives, like this, shouldn't change the effect:

   <filter>
     ...other primitives
     <feComponentTransfer>
        <feFuncR type="linear" slope="1" intercept="0"/>
        <feFuncG type="linear" slope="1" intercept="0"/>
        <feFuncB type="linear" slope="1" intercept="0"/>
      </feComponentTransfer>
    </filter>

Repro that demonstrates the problem is attached. Repros in Chromium 25 through 27.

[Dominic Mazzoni]

Created attachment 194799 [details]
Repro

[Dominic Mazzoni]

identify -> identity in the first description, of course.

Adding an additional *identity* to the end of a chain of filter primitives, shouldn't change the effect

[Stephen White]

Interesting.  I think the version with the invert-plus-identity filter is actually correct, and the one with the invert filter alone is actually wrong.  I'll attach a modified version which works in Firefox, and you'll see that the Firefox result for "Invert" and "Invert plus identity" both match the "Invert plus identity" result from Chrome.

I suspect that something's wrong in the application of color-interpolation-filters.  If you apply color-interpolation-filters="sRGB" to the filter elements, Firefox renders both results as Chrome does for "Invert" alone.  Chrome is unchanged.

At any rate, It would be helpful if you could come up with an SVG-only test case, which would rule out the SVG-on-HTML elements code.

[Stephen White]

Created attachment 194853 [details]
Firefox-compatible repro

[Dominic Mazzoni]

> I think the version with the invert-plus-identity filter is actually correct

Not unless I'm misunderstanding the spec. I did a screenshot and measured the color values, and Chrome's invert is doing exactly what I'd expect in linearRGB space, i.e. each color value x maps to exactly 1.0 - x.

It does appear that adding a second filter is causing it to switch to sRGB.

The spec says that filters should be linearRGB unless otherwise specified - or am I reading it wrong?

[Stephen White]

(In reply to comment #5)
> > I think the version with the invert-plus-identity filter is actually correct
> 
> Not unless I'm misunderstanding the spec. I did a screenshot and measured the color values, and Chrome's invert is doing exactly what I'd expect in linearRGB space, i.e. each color value x maps to exactly 1.0 - x.
> 
> It does appear that adding a second filter is causing it to switch to sRGB.
> 
> The spec says that filters should be linearRGB unless otherwise specified - or am I reading it wrong?

Yes, color-interpolation-filters defaults to linearRGB.  However, my understanding is that input images and the output device are assumed to be in sRGB space (unless specified otherwise), so filters being applied in linearRGB means that the code must apply a conversion from sRGB to linear, do the filter math in linear space, then convert back to sRGB (or whatever the device color space is).

By specifying sRGB for color-interpolation-filters, you're actually requesting the filter math to be performed in sRGB color space, so no conversions are necessary (although the math is technically wrong).

[Stephen Chenney]

(In reply to comment #6)
> (In reply to comment #5)
> > > I think the version with the invert-plus-identity filter is actually correct
> > 
> > Not unless I'm misunderstanding the spec. I did a screenshot and measured the color values, and Chrome's invert is doing exactly what I'd expect in linearRGB space, i.e. each color value x maps to exactly 1.0 - x.
> > 
> > It does appear that adding a second filter is causing it to switch to sRGB.
> > 
> > The spec says that filters should be linearRGB unless otherwise specified - or am I reading it wrong?
> 
> Yes, color-interpolation-filters defaults to linearRGB.  However, my understanding is that input images and the output device are assumed to be in sRGB space (unless specified otherwise), so filters being applied in linearRGB means that the code must apply a conversion from sRGB to linear, do the filter math in linear space, then convert back to sRGB (or whatever the device color space is).
> 
> By specifying sRGB for color-interpolation-filters, you're actually requesting the filter math to be performed in sRGB color space, so no conversions are necessary (although the math is technically wrong).

Stephen is right. I put a lot of effort recently into getting the color spaces right, and his explanation matches the way things are implemented now (or should be implemented).

[Dominic Mazzoni]

Created attachment 194983 [details]
SVG-only version of same code - cannot reproduce problem

You're correct, color-interpolation-filters="sRGB" was what I wanted.

I've attached an SVG-only version of the same effect, and I can't reproduce the bug there. So I think the bug has to do with CSS filter effects specifically, not the SVG filter effect code.

As far as I can tell, color-interpolation-filters is ignored in CSS filter effects.

[Stephen White]

This is fixed in Blink as of http://src.chromium.org/viewvc/blink?view=revision&revision=151966.

I'll leave this bug open in case anyone wants to back-port the blink fix.

[Brent Fulgham]

Safari and Chrome handle this similarly. Firefox doesn't seem to handle the Identity case properly.