This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20591 - Better description of 'color-interpolation-filters'
Summary: Better description of 'color-interpolation-filters'
Status: RESOLVED FIXED
Alias: None
Product: CSS
Classification: Unclassified
Component: Filter Effects (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dean Jackson
QA Contact: public-css-bugzilla
URL: http://lists.w3.org/Archives/Public/w...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-08 00:17 UTC by Dirk Schulze
Modified: 2013-12-06 14:02 UTC (History)
4 users (show)

See Also:


Attachments

Description Dirk Schulze 2013-01-08 00:17:09 UTC
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.
Comment 1 tavmjong 2013-01-09 10:00:09 UTC
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.
Comment 2 Dirk Schulze 2013-11-04 06:17:03 UTC
(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.
Comment 3 Dirk Schulze 2013-12-06 14:02:01 UTC
fixed.