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

On Tue, Oct 15, 2013 at 9:19 AM, Chris Lilley <chris@w3.org> wrote:

> 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.


How is a new filter going to help with Michael's problem?
The issue is that the output of the filter is clamped, composited and then
fed into the second filter.