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

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


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