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

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

Received on Tuesday, 23 July 2013 23:41:45 UTC