Re: [filter-effects] Color clamping of intermediate filter primitive results

On Mon, Jul 22, 2013 at 11:51 PM, Dirk Schulze <dschulze@adobe.com> wrote:

>
> On Jul 23, 2013, at 8:30 AM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
>
> > On Tue, Jul 23, 2013 at 5:58 PM, Dirk Schulze <dschulze@adobe.com>
> wrote:
> > On Jul 23, 2013, at 7:41 AM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
> > > I'm afraid that your proposed change may be rather complex though. I'd
> like to see the details.
> >
> > grayscale, sepia, saturate, hue-rotate, invert, opacity, brightness and
> contrast are all filter operations that can be represented by a color
> matrix. Lets take a look at the following example:
> >
> > I understand all that. I'm just saying that you'll have to define
> exactly how filter primitives are combined into groups for clamping, and
> you'll be forcing implementations to do it that way.
> >
> > Also, note that in your example it seems no clamping is actually
> necessary, since the primitives you chose should not send any values out of
> the 0-255 range. (Except huerotate maybe?)
>
> As long as values are between 0% and 100% for most of the shorthand they
> should be fine. However, this is not always the case for filters like
> brightness, saturate or contrast. Here you often want to go beyond 100%. To
> find the ranges for hue-rotate is a bit more math. I did not do the math
> yet, but checking the matrix multiplication (and especially summation) that
> is involved, I expect smaller ranges where you can assume that you don't
> need to clamp.
>
> It would indeed require more detailed description in the spec and as you
> described require a definition of grouping of filter primitives. On the
> other hand, the spec requires clamping at the moment which is also forcing
> implementations to do it one certain way and in this case a less efficient
> way.


Not necessarily. As you mentioned, certain filer operation always produce
clamped values so it would be OK for the implementation to optimize those.
I think you should remove the note and leave it up to the implementors if
they want to optimize certain code paths.