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

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

From: Chris Lilley <chris@w3.org>
Date: Tue, 15 Oct 2013 18:19:13 +0200
Message-ID: <245260580.20131015181913@w3.org>
To: Stephen White <senorblanco@chromium.org>
CC: Dirk Schulze <dschulze@adobe.com>, Michael Mullany <michael@sencha.com>, "public-fx@w3.org" <public-fx@w3.org>
Hello Stephen,

Tuesday, October 15, 2013, 5:50:40 PM, you wrote:

> I actually think color-interpolation-filters has a related problem,
> which is that in all current implementations, the conversions
> implied by linearRGB introduce some ugly banding, due again to
> limited precision.

Yes. 8 bits per component is barely sufficient for gamma-companded
small-gamut (such as sRGB) spaces. As soon as you go to linear-light
or wider-gamut spaces, 16bits per component (or fixed point, or float)
is needed to avoid visible roundoff errors.

>  One solution to both problems might be floating
> point (or better, half float) intermediate buffers, which in the
> hueRotate case would allow for out-of-gamut colours, at least
> internally. Of course that would introduce a heavier computational and memory burden.

Agreed (better, and heavier).

>>  a better option offered (especially as a
>>  shorthand) which gives the more expected results without gross
>>  roundoff error.

> An additional shorthand seems like a good idea. I would be
> interested to know the rationale for the current spec of hueRotate,
> since there's not much in the current SVG spec besides the math.
> Perhaps there's something in the archives of the SVG mailing list(s).

I wonder if the math was developed before it was decided that
filters would use early clamping. However, I think the solution is to
add an explicit HSL-manipulating filter element.

Best regards,
 Chris                            mailto:chris@w3.org
Received on Tuesday, 15 October 2013 16:19:18 UTC

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