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

Re: [css-filters] linearRGB vs sRGB

From: Rik Cabanier <cabanier@gmail.com>
Date: Sat, 8 Sep 2012 12:30:33 -0700
Message-ID: <CAGN7qDDic-uTPS_N1HM4gdGGET8_c032WWBjzbdYGL+eqijD7g@mail.gmail.com>
To: Dean Jackson <dino@apple.com>
Cc: public-fx@w3.org
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 Saturday, 8 September 2012 19:31:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 8 September 2012 19:31:02 GMT