Bug 113174 - Composing a filter with the identity function shouldn't change its effect.
Summary: Composing a filter with the identity function shouldn't change its effect.
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 68469
  Show dependency treegraph
 
Reported: 2013-03-25 01:35 PDT by Dominic Mazzoni
Modified: 2014-03-02 09:18 PST (History)
4 users (show)

See Also:


Attachments
Repro (5.45 KB, text/html)
2013-03-25 01:35 PDT, Dominic Mazzoni
no flags Details
Firefox-compatible repro (6.17 KB, text/html)
2013-03-25 07:42 PDT, Stephen White
no flags Details
SVG-only version of same code - cannot reproduce problem (2.66 KB, image/svg+xml)
2013-03-25 19:38 PDT, Dominic Mazzoni
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dominic Mazzoni 2013-03-25 01:35:10 PDT
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.
Comment 1 Dominic Mazzoni 2013-03-25 01:35:48 PDT
Created attachment 194799 [details]
Repro
Comment 2 Dominic Mazzoni 2013-03-25 01:38:49 PDT
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
Comment 3 Stephen White 2013-03-25 07:41:26 PDT
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.
Comment 4 Stephen White 2013-03-25 07:42:28 PDT
Created attachment 194853 [details]
Firefox-compatible repro
Comment 5 Dominic Mazzoni 2013-03-25 09:31:18 PDT
> 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?
Comment 6 Stephen White 2013-03-25 10:06:06 PDT
(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).
Comment 7 Stephen Chenney 2013-03-25 10:40:14 PDT
(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).
Comment 8 Dominic Mazzoni 2013-03-25 19:38:29 PDT
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.
Comment 9 Stephen White 2013-06-07 11:12:00 PDT
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.