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

On Mon, Oct 14, 2013 at 12:13 PM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
>
> On Mon, Oct 14, 2013 at 12:00 PM, Michael Mullany <michael@sencha.com>wrote:
>
>> 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.
>>
>
> That's true. There is still a question when the clamping happens.
> You can define RGB values outside of [0...1] but afaik it's unclear when
> they should be clamped.
>
>
>>
>>>
>>>>
>>>> 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?
>>
>
> How much more math would that introduce? If it is a lot, can it be
> implemented in hardware on limited devices?
> Are you aware of any user complaints (apart from yourself :-))
>
>
Only 2 so far, but I can blog about this and see how many people think it's
a big deal.

http://stackoverflow.com/questions/19187905/why-doesnt-hue-rotation-by-180deg-and-180deg-yield-the-original-color
https://code.google.com/p/chromium/issues/detail?id=237524


-- 
www.sencha.com
"Amazing Apps with Web Technologies"