Re: [css-filters] linearRGB vs sRGB

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. 
>