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

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?


>
> [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 :-))
> >
>
>