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

On Oct 14, 2013, at 9:47 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> 
> 
> 
> On Mon, Oct 14, 2013 at 12:33 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> 
> On Oct 14, 2013, at 9: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.
> 
> What do you mean with it is unclear when clamping happens? From the spec[1]:
> 
> ""
> The RGBA result from each filter primitive will be clamped into the allowable ranges for colors and opacity values.
> ""
> 
> RGB is allowed to go negative and greater than 1: http://www.w3.org/TR/CSS21/syndata.html#value-def-color
> I argued against this here: http://lists.w3.org/Archives/Public/www-style/2012Jun/0381.html
> 
> Maybe the filters spec should be clarified and say that values should be clamped to the used ranges?

At least CSS Colors 4 clamps between 0 and 1 for rob().

Greetings,
Dirk


>  
> 
> [1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterPrimitivesOverviewIntro
> 
> >
> >
> >
> > 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 :-))
> >
> 
>

Received on Monday, 14 October 2013 20:37:20 UTC