Re: Margins for filters?

Dirk Schulze wrote:
>> I would suggest grouping and then clipping if the order is the wrong way 
>> around by default.
> But what if you want to filter just a part of the target object, lets
> say you want to make a shadow behind a part of an image?

BackgroundImage? You draw an object which has the required shape, then 
use BackgroundImage masked by the filtered object. If you wanted to do 
it "in-place" you could even blur and then combine the blurred and 
unblurred images using a mask (all in one filter).

More fundamentally, the filter effects region is not MEANT to be a 
general clipping facility, and is frankly a pretty poor substitute. For 
example, if you do want to blur (for example) part of the image you 
would be WAY better off (in most cases) blurring the image first (at 
least in the appropriate region) and THEN masking. And what if you don't 
want a rectangular region? Or one that is rectangular, but rotated 
w.r.t. the local user space coordinates?

Obviously there are some cases where it would be pretty complex for a 
user agent to determine the optimal buffer sizes (and locations), but 
even in the case I suggested above, where you'd have something like this 
(omitting some details):
------------------------------------------------------
<filter>
   <feImage xlink:href="maskingImage" result="mask" />
   <feComposite operator="out" in="SourceImage" in2="mask" result="a" />
   <feGaussianBlur result="blurred" />
   <feComposite operator="in" in="blurred" in2="mask" result="b" />
   <feComposite operator="arithmetic" in="a" in2="b" k2="1" k3="1" />
</filter>
------------------------------------------------------
The renderer could relatively easily do something like:
------------------------------------------------------
SourceImage: bbox of filtered object
mask: bbox of maskingImage
a: SourceImage
blurred: SourceImage + margin of 3*stddev
b: intersection of mask and blurred
output: union of a and b
------------------------------------------------------
If the renderer doesn't want to be smart it can always try to be a bit 
on the conservative side and still be reasonably efficient most of the time.

As it is now Inkscape basically still has to implement most of the logic 
for doing it right automatically AND has to support clipping to the 
filter effects region... In view of backwards compatibility it might be 
problematic to completely ignore the filter effects region in a new SVG 
standard, and the new margin properties are a definite improvement, but 
it might not be a bad idea to simply skip adding the new margin 
properties and add some option that allows a renderer to simply "do the 
right thing".

Received on Sunday, 18 April 2010 11:42:11 UTC