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

On Mon, Jul 22, 2013 at 10:38 PM, Dirk Schulze <dschulze@adobe.com> wrote:

>
> On Jul 23, 2013, at 7:32 AM, Rik Cabanier <cabanier@gmail.com> wrote:
>
> >
> >
> > On Mon, Jul 22, 2013 at 10:16 PM, Dirk Schulze <dschulze@adobe.com>
> wrote:
> > Hi,
> >
> > Currently Filter Effect require to clamp all resulting pixel color
> values of filter primitives to the range 0..255. This was done to have
> specified color values for each filter primitive output at any time.
> >
> > However, this approach prevents implementations from further
> improvements. The specification currently has the following note for
> shorthand filters[1]:
> >
> > ""
> > Note: The grayscale, sepia, saturate, hue-rotate, invert, opacity,
> brightness and contrast filter functions can be represented by color
> matrices. If the former named filter functions are chained together, UAs
> can optimize the performance by multiplying these filter functions to one
> color matrix and apply the resulting color matrix instead of each filter
> function separately.
> > ""
> >
> > I think you should remove that sentence or make it clear that clamping
> needs to be done when you collapse the matrices.
>
> It should be clarified, indeed. But first I would like to get to an
> agreement that we just clamp a sub-chain with combined filter operations
> instead of each single operation. Multiplying color matrices together and
> apply them to the content and clamp once is a lot more efficient than doing
> each filter operation individually and clamp each single time.


They should be clamped otherwise you'd get weird results if there's a blur
or dropshadow in the middle.
If you pipeline the cpu instructions or do it in a shader, it's probably
not that expensive since the pixels are in memory anyway (and memory access
is expensive on mobile hardware).


> >
> >
> > Since the shorthand filter build on top of SVG Filters, this is actually
> not correct. Implementations need to apply each shorthand filter on the
> content first to clamp the result after each filter operation.
> >
> > "saturate(200%) saturate(50%)" would look different depending if you
> clamp color values for each primitive or don't.
> >
> > I wonder if we can relax the requirement of clamping in some cases and
> would suggest that we do not force clamping if two following filter
> primitives can be collapsed to one filter primitive. We would need to
> clarify which primitives can be combined together of course.
> >
> > Greetings,
> > Dirk
> >
> > [1] http://dev.w3.org/fxtf/filters/#FilterProperty
> >
> >
> >
> >
> >
>
>