Re: SVG Filters 2

> 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.
This is entirely off-topic, but is the code available somewhere? I've
been trying to get HSI working, but the saturation needs a few
operations that I'm just unable to emulate.

>> 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.

Good point. But still, I wonder how else you can handle general
"channels" and RGBA:
A prerequisite of using channels is that each channel works
independently: I'd be pretty
confused if I found inside a spec "channels are handled independently,
but RGB is
always interpreted in relation to A". Of course, we could add an
implicit conversion
just for those filters that need it, but that would again mean
limiting the use of that filter.
A perfect example right now is feColorMatry[type=matrix]: This thing
is equally valuable
with and without pre-multiplied colors, but since the current spec
demands that it first
undoes premultiplication, you can not feed the full range of colors into it.


> 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).

I'd much rather have a clean logic, even if it means that what is now a single
feConvolveMatrix would turn into a convert, feConvolveMatrix, convert sequence.
While it would mean more work for the designer, it would be easier for him
to understand what he is doing exactly and wouldn't lead to the unexpected
results you often get with SVG filters as they are defined now.

That reminds me of something I forgot to mention in the initial mail.
There should be something akin to "USE" for SVG filters. Since we
would mainly provide atomic operations, people would frequently
define filter sequences that they want once and reuse them across
different filters much like we use filter primitives now.


>> ===Inline SVG===
>> This also would keep SVG filters from duplicating parts of 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.)

I think you just cooked up a proposal that's for something entirely different:
hierarchical filter notation. But I like it :)

The important thing here is that we can make filters self-contained (unlike
feImage) and use SVG operations to process intermediate results without
the hassle of splitting it into separate filters and stacking them ontop of
each other.




-- 
Hans Schmucker
Mannheim
Germany
hansschmucker@gmail.com
http://www.tapper-ware.net

Received on Monday, 31 May 2010 15:44:22 UTC