Re: Filter Effects: Filter primitive subregion clarification

Hi Stephen,

The spec currently says:

""
The filter primitive subregion act as a hard clip clipping rectangle on both the filter primitive's input image(s) and the filter primitive result.
""

Which means the input and the output is clipped.

As you noticed, implementations have different behavior. With slightly different tests you'll see that some implementations are not consistent with them self. I would very much prefer to remove the requirement of input AND output clipping. Reading the spec, it sounds like the original text intended just output clipping. I think this is more preferable then clipping both, input and output.

On Aug 9, 2013, at 6:52 PM, Stephen White <senorblanco@chromium.org> wrote:

> If the filter primitive subregion is set, should filters access pixels from the input image from outside the subregion? Here's a fiddle to show what I mean: http://jsfiddle.net/VFccX/.  It contains a 100x100 green box inset within a 200x200 red box. It is blurred by an feGaussianBlur with a filter primitive subregion set to the 100x100 interior box.
> 
> On Chrome, the result contains no red. On Firefox, Safari and IE10, the result contains red bleeding at the corners.
> 
> According to my reading of the spec:
> ‘x’, ‘y’, ‘width’ and ‘height’ act as a hard clip clipping rectangle on both the filter primitive's input image(s) and the filter primitive result.
> 
> it sounds like the input image should be (semantically) clipped, so that none of the pixels outside the image should be accessed.
> 
> On a related note, the subsequent paragraph is a bit confusing:
> All intermediate offscreens are defined to not exceed the intersection of ‘x’, ‘y’, ‘width’ and ‘height’ with the filter region. The filter region and any of the ‘x’, ‘y’, ‘width’and ‘height’ subregions are to be set up such that all offscreens are made big enough to accommodate any pixels which even partly intersect with either the filter region or the x,y,width,height subregions.
> 
> The last sentence here seems to contradict the first: if the offscreen is not to exceed the intersection of the subregion and filter region, how can it accommodate pixels which "intersect with either the filter region or the subregion" (sounds more like a union)?

First, the easiest behavior is if you have x, y, width, height defined by the author:

""
All filter primitives have attributes ‘x’, ‘y’, ‘width’ and ‘height’ which together identify a subregion which restricts calculation and rendering of the given filter primitive.
""

I think it should be clear what the subregion is in this case.

Now to your question above if the subregion is not completely defined by the author. You actually can not just copy paste one sentence:

""
‘x’, ‘y’, ‘width’ and ‘height’ default to the union (i.e., tightest fitting bounding box) of the subregions defined for all referenced nodes. If there are no referenced nodes (e.g., for <feImage> or <feTurbulence>), or one or more of the referenced nodes is a standard input (one of SourceGraphic, SourceAlpha, BackgroundImage,BackgroundAlpha, FillPaint or StrokePaint), or for <feTile> (which is special because its principal function is to replicate the referenced node in X and Y and thereby produce a usually larger result), the default subregion is 0%, 0%, 100%, 100%, where as a special-case the percentages are relative to the dimensions of the filter region, thus making the default filter primitive subregion equal to the filter region.
""

If the subregion is not specified, then there are two conditions:
1) filter primitive has input filter primitives
2) filter primitive does not have inputs.

To 1) If there are input filter primitives, then the sub regions is the union of all subregions of each input filter primitive. This union is clipped with the filter region.
To 2) If there is no input filter primitive (like for the pseudo filter primitives), then you use 0%, 0%, 100% and 100% of the filter region.

I hope that clarified your question.

Greetings,
Dirk

Received on Friday, 9 August 2013 17:41:32 UTC