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

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.

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