Re: SVG Filters 2

Hans Schmucker wrote:
> ...
> ===Value attributes===
> There are currently quite a few filter primitives that perform the
> same function, but one time with constant values and one time with
> input from a second channel... wouldn't it nice to unify them?
> ...

Very nice idea, also very doable. Could also reduce the need for feFlood 
in some cases.

> ===Stop interpreting input data===
> You may have noticed that I wrote [0] above and not .red:
> The point is that limiting channel 0 to Redis an unnecessary
> restriction. Why should channel 0 have to be red? Couldn't it contain
> intensity or alpha? Don't think of [0] as red, [1] as green and so on.
> Just think of them as data.

Very good point (I've in fact done some work on converting to HSV/HSL 
and back in SVG filters). And frankly I wouldn't mind support for 
arbitrary numbers of (named?) channels. The latter might be a bit much 
for some applications, but at least some movement towards more general 
channels would be great (basically more like current graphics cards 
operate).

> ...
> Doing this would also mean getting rid of pre-multiplied colors (or at
> least the implicit conversions and the default setting of using
> pre-multiplied RGBA input), since these link RGB to A and make
> independent working impossible.

I'm not sure this is a good idea. Occasionally I have struggled with 
this, but I think it might be better to handle this differently. If you 
have more control over which channels are used you can ignore the alpha 
channel in some filters for example. Also, if you can specify the kind 
of channels you have you would be able to create images without an alpha 
channel.

Also, in many cases you don't need to do an explicit conversion step, it 
is just used to describe the meaning of the filter. For example, 
Inkscape can apply feConvolveMatrix to a non-premultiplied image and 
produce a non-premultiplied image without losing any quality by having 
put the conversion directly into the convolution code.

Convolution is also a good example of a filter that you would probably 
NEVER want to perform on non-premultiplied colors as such (it doesn't 
make sense). You may want to perform it on four channels that aren't 
linked in any way though. So I guess the question would be whether you 
want SVG or the filter designer to be smart (should SVG know what kind 
of channels you have).

> ...
> ===Inline SVG===
> ...
> This also would keep SVG filters from duplicating parts of SVG: Often
> in a filter you have to move something around, rotate it or scale it.
> Or you need a gradient as input data. You could either do that by
> adding special transformation, gradient, ... filter primitives (much
> like feOffset) or allow inline SVG. If you give inline SVG the power
> to reference the results that the filter has created so far, you get
> very powerful functionality without duplicating work that has already
> been done on SVG.
 >
> A transformation of a blurred image may then look something like this:
> <feGaussianBlur result="foo" />
> <feViewport result="bar">
>    <image xlink:href="result(foo)" transform="..." />
> </feViewport>
> ...

I'd love something like this, but it would be interesting to see if we 
could get the syntax to become a bit more unified. As you've suggested 
it now you would keep jumping back and forth between the two domains. 
Perhaps something like this could be used (the first child is in, the 
second in2):

<feGaussianBlur result="foo" transform="...">
   <!-- Some SVG/filters. -->
</feGaussianBlur>

So basically you could more or less mix and match the graph-based and 
hierarchy based styles. (For example, a group is not much more than 
feMerge.)

> ===Add basic math===
> No filter system can ever capture all eventualities, but it's possible
> to add a fallback: mathematical filters. Many of these are needed
> anyway (like + for blending and brightness adjustment or * for
> contrast), but something like division, modulo and so on is not
> available in the current SVG filters spec. Adding them would be
> trivial and the benefit would be enormous, especially if coupled with
> good feature-testing (so that a SVG file could use the fallback only
> if a newer, faster extension is not available). Basically, you could
> provide endless backwards compatibility for your filters by simply
> specifying a fallback made of mathematical filters.

Note that there are currently some ways to deal with this, but it would 
be great to have a bit more native support. As an example of what you 
can currently already do:
http://wiki.inkscape.org/wiki/index.php/Advanced_Gradients
(You may want to include conical gradients directly in SVG, but there is 
of course always something else that you'd love to be able to do.)

> ===Precise mode===
> Usually the range 0-255 is fine, but especially if you allow
> mathematical filters, then it will sometimes be useful to keep the
> results with maximum precision and unclamped as floats. It shouldn't
> be enabled by default (since memory usage would explode), but its
> availability would add tremendous value to the math filter primitives.
> For math filter chains you'll usually end up with a direct chain where
> only one or two buffers get reused over and over again, so memory
> usage should not increase dramatically if this option is used
> properly.

I'd love it, not sure about others :)

Received on Monday, 31 May 2010 14:30:37 UTC