W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2013

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Tue, 23 Jul 2013 10:00:57 -0700
Message-ID: <CAGN7qDCBkhCPZ_rbLdBVUpVEGrLOK1K7+yDVfCq0nY4p+QnKcQ@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: "robert@ocallahan.org" <robert@ocallahan.org>, "public-fx@w3.org" <public-fx@w3.org>
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.
Received on Tuesday, 23 July 2013 17:01:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:46 UTC