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


On Tue, Jul 23, 2013 at 7:41 PM, Dirk Schulze <> wrote:

> On Jul 23, 2013, at 7:00 PM, Rik Cabanier <> wrote:
> >
> >
> > On Mon, Jul 22, 2013 at 11:51 PM, Dirk Schulze <>
> wrote:
> >
> > On Jul 23, 2013, at 8:30 AM, Robert O'Callahan <>
> wrote:
> >
> > > On Tue, Jul 23, 2013 at 5:58 PM, Dirk Schulze <>
> wrote:
> > > On Jul 23, 2013, at 7:41 AM, Robert O'Callahan <>
> 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

Received on Thursday, 25 July 2013 14:33:25 UTC