W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2013

Re: [filter-effects] hue-rotate() and saturate() filters

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 14 Oct 2013 12:13:31 -0700
Message-ID: <CAGN7qDDCXFhDzvuHZ=knp5NKvK3qPy-BrtcExFvY+iaZTeKGBw@mail.gmail.com>
To: Michael Mullany <michael@sencha.com>
Cc: "public-fx@w3.org" <public-fx@w3.org>
On Mon, Oct 14, 2013 at 12:00 PM, Michael Mullany <michael@sencha.com>wrote:

> On Mon, Oct 14, 2013 at 11:42 AM, Rik Cabanier <cabanier@gmail.com> wrote:
>> On Sat, Oct 12, 2013 at 8:53 PM, Michael Mullany <michael@sencha.com>wrote:
>>> If this has already been discussed and resolved at some stage, I
>>> apologize for the duplication + noise in advance.
>>> Prompted by a stack-overflow question on css filters, I did an
>>> experiment comparing the results of CSS hue-rotate() and saturate() filters
>>> with their manual equivalent (explicitly changing hsl() colors).
>>> Hue-rotate experiment here: http://codepen.io/mullany/pen/fxsuE
>>> Saturate experiment here: http://codepen.io/mullany/pen/rpgHu
>>> As you can see, the hue-rotate does a poor job of conserving saturation
>>> and lightness, and the saturate does a poor job of conserving lightness.
>>> These are extreme examples using fully saturated colors - less saturated
>>> and lighter colors don't seem to diverge quite so much as these do.
>>> I do understand that because these filters are a linear matrix
>>> approximation and remain in RGB space, there will be inaccuracies when
>>> trying to do HSL ops, but these seem very extreme to me, and very
>>> unexpected. But they seem to be consistent between Firefox and Webkit/Blink
>>> - (when converted to SVG equivalents) - so I do not think this is a bug.
>> It's debatable if this is a bug.
>> The issue is that the output of the color matrix is clamped to 0-1 before
>> feeding into the next color matrix. This will lose information, regardless
>> of what colorspace you're working in.
>> There was a discussion on this:
>> http://lists.w3.org/Archives/Public/public-fx/2013JulSep/0011.html
> Both the hue-rotate and saturate ops are single feColorMatrix multiplies,
> so this is not a problem with clamping of intermediate outputs. As Chris
> says, I think this seems to be a problem with approximating an HSL op in
> RGB.

That's true. There is still a question when the clamping happens.
You can define RGB values outside of [0...1] but afaik it's unclear when
they should be clamped.

>>> Has there been any thought of converting content to HSL before applying
>>> these filter shorthands? Or adding true HSL primitives to the filter
>>> toolbox? (Something like an feFuncH or feFuncS).
>> As Chris mentions, being able to switch the working colorspace to Lab
>> (not sure what CIELCHab is though)
>> However, doing so would require a whole new set of formulas in the
>> filters specification and a lot of work in the browsers...
>> I don't know what the right answer is here. All I can say is that this
> has the potential to burn a lot of author hours as they try to figure out
> why a deceptively simple CSS rule doesn't actually do what it advertises.
> If they're using HSL color definitions, this will be doubly surprising. One
> option is to remove these specific shorthands. Could another be to default
> to polar-coordinates when applying these specific shorthands?

How much more math would that introduce? If it is a lot, can it be
implemented in hardware on limited devices?
Are you aware of any user complaints (apart from yourself :-))
Received on Monday, 14 October 2013 19:14:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:47 UTC