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

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"