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

It depends on your criteria. If your criteria include preserving perceived
luminance, then it's better than an HSL rotation, which performs much more
poorly on this metric. If your criteria are to mimic HSL (which has no
basis in human vision), then yes, the current spec performs worse.

That said, I wasn't around when the SVG spec was written, so this is mostly
speculation on my part.

http://www.w3.org/TR/filter-effects/#feColorMatrixTypeAttribute

Stephen


On Mon, Oct 14, 2013 at 6:02 PM, Michael Mullany <michael@sencha.com> wrote:

>
>
>
> On Mon, Oct 14, 2013 at 2:55 PM, Stephen White <senorblanco@chromium.org>wrote:
>
>> 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).
>>
>
> I dunno Stephen. Hue rotate of a saturated green seems almost as bad.
>
> http://codepen.io/mullany/pen/syDlF
>
>>
>> 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
>>>
>>
>>
>
>
> --
> www.sencha.com
> "Amazing Apps with Web Technologies"
>
>