W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2013

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

From: Stephen White <senorblanco@chromium.org>
Date: Tue, 15 Oct 2013 10:11:00 -0400
Message-ID: <CAPeKFThEdS4tj1CR4ftpV99eHYZANJV1A9JDOi-CC2wpAvOL4g@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: Chris Lilley <chris@w3.org>, Michael Mullany <michael@sencha.com>, "public-fx@w3.org" <public-fx@w3.org>
On Tue, Oct 15, 2013 at 5:37 AM, Dirk Schulze <dschulze@adobe.com> wrote:

>
> On Oct 14, 2013, at 11:28 AM, Chris Lilley <chris@w3.org> wrote:
>
> > Hello Michael,
> >
> > Sunday, October 13, 2013, 5:53:20 AM, you wrote:
> >
> > Thanks for carefully demonstrating the problem with examples.
> >
> >> 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,
> >
> > Your analysis is correct as to the reason
> >
> >> 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.
> >
> > Yes, this is not a bug (the implementations are following the
> > specification), from SVG1
> >
> >> 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).
> >
> > Also correct that changing the colourspace used for computations to
> > one using polar coordinates would give more intuitive results.
>
> Shouldn't the conversion between RGB and HSL be bijective? So if both
> color spaces are bijective, the algorithm described by feColorMatrix must
> be wrong[1]. Polar coordinates or not, every color in HSL should be
> describable in RGB. And we still do the animation on the hue value and not
> on the RGB values. It also depends of course if the definition of hue in
> Filter Effects is equivalent to the definition of hue in HSL. Same (and
> probably more dramatic) for saturate. SVG 1.1 is not very clear about that.
>

feColorMatrix does not use HSL, AFAICT it uses what appears to be HSY'. So
the issue is that some fully-saturated colours go out-of-gamut when rotated
to the far side of the HSY' colour space. So when rotated, they must clip.

E.g., when fully-saturated green is rotated into blue, in HSY' space it is
actually over-saturated, but clips to fully-saturated blue (since the
colour is now out-of-gamut). If fully-saturated blue is rotated into green,
it is under-saturated, and stays that way (since it's in-gamut), so that
the perceived luminance is preserved. So it's not a matter of clipping
between two filter stages; it's actually clipping caused by the rotation.
Imagine a horizontal slice on the Y' axis of the HSY' space:
fully-saturated blue rotated by 180 degrees ends up as a partly-saturated
yellow, such as in the lower right image here:
http://en.wikipedia.org/wiki/File:Hsl-hsv_chroma-lightness_slices.svg

This is due to the CCIR 601 luma computation built into feColorMatrix
hueRotate (Y = 0.213 R + 0.715 G + 0.072 B).

Stephen


>
> Greetings,
> Dirk
>
> [1]
> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feColorMatrixElement
>
> >
> > SVG has a color-interpolation property which is used for
> > non-filter operations; in SVG2 this is updated to add two polar spaces
> > (HSL and CIELCHab). The same addition could be made to
> > color-interpolation-filters.
> >
> > --
> > Best regards,
> > Chris                            mailto:chris@w3.org
> >
> >
>
>
>
Received on Tuesday, 15 October 2013 14:11:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:47 UTC