Re: [css-filters] linearRGB vs sRGB

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.