Re: [SVG11] filter subregion

T Rowley wrote:

> Working on implementing feFlood for mozilla SVG, I created a simple 
> testcase and tried it on a number of SVG viewers.  Five implementations 
> gave three different results.  Two of these appear only to differentiate 
> due to a bug in subregion calculation.

ASV3, Batik 1.6 and Opera 9.1 all displayed your example below exactly the  
same.
Firefox 3.0 (GranParadiso) looked the same except that it showed the green  
circle.
What implementations did you test?

> My implementation appeared to interpret the filter subregion portion of 
> the specification differently than all the others.  I read section15.7.3  
> to say that filter element only modifies the indicated portion ofthe  
> input image, leaving the rest of the image alone.  Thus in thefollowing  
> example I'd expect to see a green circle with a translucentred rectangle  
> punched out.  Other implementations seem to read thesection as the  
> element only outputs in the subregion, so they only givea translucent  
> rectangle.

The 'filter' element has the hard clipping rect for the filter, and in  
your example uses the default values which are -10% for 'x' and 'y' and  
120% for 'width' and 'height'. There is a 'filter effects region' and a  
'filter primitive subregion'. Both of these terms have a section in the  
filter chapter.

In the example the filter covers outside of the circle graphics element,  
and the filter primitive 'feFlood' does its processing on a subregion of  
that.
The expected result is that since the output of the 'feFlood' filter  
primitive gives the result of the filter as a whole in this example the  
red rect which is the 'feFlood' subregion will be what's visible of the  
filtered element (the circle). Pixels outside of the filter primitive  
subregion are set to transparent black, from reading the intro section [1]  
which says:
"Sometimes filter primitives result in undefined pixels. For example,  
filter primitive 'feOffset' can shift an image down and to the right,  
leaving undefined pixels at the top and left. In these cases, the  
undefined pixels are set to transparent black."

 From reading section 15.7.3: "All filter primitives have attributes x, y,  
width and height which identify a subregion which restricts calculation  
and rendering of the given filter primitive."

Explain then how it's possible to get anything outside of the filter  
primitive subregion as the result of the filter. Yes the filter primitive  
can "leave the rest of the image alone", but that doesn't mean that the  
"SourceGraphic" (the default value for 'in' to the filter primitive) isn't  
clipped by the filter primitive subregion, according to 15.7.3: "x, y,  
width and height act as a hard clip clipping rectangle."

Compare with this similar testcase where the feFlood element has been  
replaced by a feBlend element:

<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">

<filter id="flood">
    <feBlend x="25%" y="25%" width="50%" height="50%"
             in2="SourceGraphic" mode="multiply"/>
</filter>

<g fill="none" stroke="blue" stroke-width="4">
    <rect width="200" height="200"/>
    <line x2="200" y2="200"/>
    <line x1="200" y2="200"/>
</g>

<circle fill="green" filter="url(#flood)" cx="100" cy="100" r="90"/>

</svg>

Batik 1.6 shows this one correctly, there should be no circle visible only  
a dark rect. Opera 9.1 and ASV3 don't clip the filter primitive correctly  
in this case, but filters the given filter primitive subregion only.  
Firefox 3.0 calculated the filter result outside of the filter primitive  
subregion.

There is work being done on getting a new filter specification out, which  
will essentially be what was in SVG 1.1. For this publication there will  
be some new testcases to cover this case among others.

> Which interpretation is intended, and can the language be clarified inan  
> errata?

Given the explanation I've made here, do you still think it needs  
clarification? Would having the examples in this mail along with section  
15.7.3 in the svg 1.1 errata be enough to satisfy you or would it be  
sufficient to add the same to the new filter specification?

> The testcase:
><svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">
><filter id="flood">
>    <feFlood x="25%" y="25%" width="50%" height="50%"
>             flood-color="#ff0000" flood-opacity="0.75"/>
> </filter>
><g fill="none" stroke="blue" stroke-width="4">
>    <rect width="200" height="200"/>
>    <line x2="200" y2="200"/>
>    <line x1="200" y2="200"/>
> </g>
><circle fill="green" filter="url(#flood)" cx="100" cy="100" r="90"/>
></svg>

Best regards
/Erik, on behalf of the SVG WG

[1] http://www.w3.org/TR/SVG11/filters.html#Introduction

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Received on Monday, 12 February 2007 13:53:25 UTC