This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The 'color-interpolations-filter' needs a better description how and in which order (on pre or unpremultiplied colors) it applies to the input and output of a filter primitive.
In implementing support for 'color-interpolation-filters' in Inkscape, I assumed converting between color spaces is done on unpremultiplied colors. I checked the color space of the input and then converted it if the input differed from the value of 'color-interpolation-filters' on the current primitive. The output was tagged with the value of 'color-interpolation-filters', leaving it up to the next primitive in a chain to convert if necessary (for efficiency). I converted the final output to sRGB (when necessary) at the point of compositing it with the rest of the SVG (Inkscape doesn't support a value of linearRGB for 'color-interpolation'). The end result appears to agree with what browsers are doing.
(In reply to tavmjong from comment #1) > In implementing support for 'color-interpolation-filters' in Inkscape, I > assumed converting between color spaces is done on unpremultiplied colors. I > checked the color space of the input and then converted it if the input > differed from the value of 'color-interpolation-filters' on the current > primitive. The output was tagged with the value of > 'color-interpolation-filters', leaving it up to the next primitive in a > chain to convert if necessary (for efficiency). I converted the final output > to sRGB (when necessary) at the point of compositing it with the rest of the > SVG (Inkscape doesn't support a value of linearRGB for > 'color-interpolation'). The end result appears to agree with what browsers > are doing. I think that is what we do in WebKit as well. Do you think there is a clarification needed in the Filter Effects specification? Sounds more like an implementation detail.
fixed.