- From: Stephen White <senorblanco@chromium.org>
- Date: Tue, 15 Oct 2013 10:11:00 -0400
- 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>
- Message-ID: <CAPeKFThEdS4tj1CR4ftpV99eHYZANJV1A9JDOi-CC2wpAvOL4g@mail.gmail.com>
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