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

I may be totally off-base, but my guess is that this is because
hue-rotate() doesn't use the HSL definition of "lightness" (the average of
the RGB components, I believe), but rather the CCIR 601 definition of
luminance, which puts an unequal weighting on RGB in the computation, in
order to reflect the perceived luminance of the human eye. Note that the
colours in the hue-rotate() ring of your example are much closer to equal
in perceived luminance than the HSL ring. Note also that the
fully-saturated green in the HSL ring appears much brighter than the
fully-saturated blue, for example, simply due to the way the human eye
works.

If you modify your example to start with green, you'll see there's much
less difference between the two examples (because the blue gets pushed up
and clipped to try to match the green).

Stephen


On Sat, Oct 12, 2013 at 11: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.
>
> 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).
>
> -- michael
>