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

In the Chromium implementation, we apply this optimization (concatenating
matrices) where possible, but it's fairly common that clamping prevents its
use, e.g., http://crbug.com/233101. IIRC, Translation of any amount in the
matrix requires clamping, as does a scale <0 or >1. Sadly, hue rotation
also requires clamping, since it clips the saturated part of the colour
gamut as it rotates.

We could apply two or more matrices in a single pass with clamping in
between (and have plans to do so on the GPU side), but doing it on the CPU
side in a single pass would require JITing the filters or some pre-compiled
number of combinations (2 matrices, 3 matrices, etc).

Removing the requirement for colour clamping would make our lives easier,
but it would also require that all implementations perform this
optimization, AFAICT.

Stephen


On Tue, Jul 23, 2013 at 7:41 PM, Dirk Schulze <dschulze@adobe.com> wrote:

>
> On Jul 23, 2013, at 7:00 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
> >
> >
> > 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.
>
> I am not talking about rare use cases. Values over 100% for the most
> filter primitives is very likely to happen. Same for using more than one
> filter primitives in a chain. Again, we are about a complexity from linear
> to a constant in many cases. I think that this fact is worth it to
> questioning the "always-clamp". Even with better hardware and GPU
> acceleration in the future, this would still be a win.
>
> To your previous argument about the cache: Quite often the images are big
> enough to cause cache misses. And even if not, the speedup of one run in
> comparison to n runs over each pixel is huge.
>
> Greetings,
> Dirk
>
>
>