W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2012

Re: [css-filters] linearRGB vs sRGB

From: Dirk Schulze <dschulze@adobe.com>
Date: Mon, 10 Sep 2012 08:53:21 -0700
To: Rik Cabanier <cabanier@gmail.com>, Erik Dahlstrom <ed@opera.com>
CC: Dean Jackson <dino@apple.com>, "public-fx@w3.org" <public-fx@w3.org>
Message-ID: <6D3602E1-C317-4DDD-BD4C-30317C36765C@adobe.com>
Hi Erik,

I know that we discussed 'color-interpolation-filters' on short hand filter during one of our FXTF meetings. Did we resolve that this property applies to the full filter chain? If so, we need to redefine the property to apply to all elements, instead to just filter primitives.

I at least could live with just applying it to SVG Filter primitives. Otherwise we need to define what happens, if one of the filter chain primitives is a reference:

<div style="filter: blur(4px), url(#filter); color-interpolation-filters: sRGB"></div>

    <feGaussianBlur stdDeviation="3" color-interpolation-filters="linearRGB" />


On Sep 9, 2012, at 9:36 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> I just realized that the 'opacity' filter is not affected by this setting.
> However, we had a meeting a couple of months ago where we agreed that the shorthands would use sRGB (= don't change the color logic behind people's back) but this is not reflected in the CSS filters spec.
> Sent from my iPad
> On Sep 8, 2012, at 12:30 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>> On Fri, Sep 7, 2012 at 7:23 PM, Dean Jackson <dino@apple.com> wrote:
>> Apologies that this will not be threaded correctly.
>> On Tuesday, February 7, 2012, Dirk wrote:
>> > On Feb 6, 2012, at 9:03 PM, Chris Lilley wrote:
>> >
>> > > On Tuesday, February 7, 2012, 12:29:07 AM, Dirk wrote:
>> > >
>> > > DS> Hi Rik,
>> > >
>> > > DS> if it would be supported at all, you could just specify one color
>> > > DS> interpolation for the complete filter chain, not for single filter
>> > > DS> effects. But the default 'color-interpolation-filters' value of
>> > > DS> 'linearRGB' is indeed a problem.
>> > >
>> > > Why is it a problem?
>> > >
>> > > DS> IIRC WebKits CSS short hand
>> > > DS> filters use either sRGB or DeviceRGB, but not linearRGB.
>> > >
>> >
>> > > Ah okay, its a problem because you don't support it yet. Don't worry, the
>> > > coding is trivial. I can send you the equations if you don't already have them.
>> >
>> > Haha, the problem is the definition. 'color-interpolation-filters' is used by
>> > filter effect elements. But where do you apply the property if you use short
>> > hand filters? I assume the filtered element, but this is different to the
>> > current definition. Or it needs to get specified how you can apply different
>> > property values to different effects of the filter chain. So actually it is not
>> > important if you use 'linearRGB' or 'sRGB', but that there are two values :).
>> >
>> > To the trivial equations: The problem is not applying equations, but do it
>> > fast enough. :) But that is of course an implementation detail and should still
>> > get considered by specifications.
>> One of the things that annoys us is that the conversion from sRGB -> linear ->
>> sRGB can be slightly lossy (if you use 8-bit components in the filter stage).
>> This means a no-op filter, such as an feMerge of SourceGraphic, can actually
>> change the image :( In practice, this makes it difficult to match a filtered
>> element to a surrounding colour.
>> Using linearRGB also introduces some difficulties in our hardware acceleration
>> path, which is a shame. For example, in Safari 6 on OS X Mountain Lion you may
>> notice a shift in colours when the animation of a CSS filter starts or stops.
>> This is a bug in our implementation, but fixing it will incur a performance
>> penalty. With these things is hard to tell whether people prefer results to be
>> perfect or fast.
>> The filter shorthands all operate in sRGB, right?
>> It would be strange if for instance the opacity filter give different results than using opacity in CSS. 
Received on Monday, 10 September 2012 15:54:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:48 UTC