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

On Tue, Jul 23, 2013 at 4: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.
>

In SVG, I've been pre-multiplying color matrices together in order to make
this happen already and it's a royal pain. It would be exceedingly good if
this was an automatic optimization.

However, it might start confusing people if they start getting different
results depending on the order of the CSS filters (aka if they put the drop
shadow at the end vs. the middle of a series.)  I don't think order
dependency is something that's found anywhere else in CSS (although I could
be wrong.)

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


-- 
www.sencha.com
"Amazing Apps with Web Technologies"