Re: Filter Templates

>
>
>> Off the top of my head, here is the vague shortlist I was considering (I'm
>> sure I've left out some and I do not expect that they would all be accepted
>> by the WG):
>>
>> - controls(brightness, saturation, contrast, exposure, gamma)
>> - halftone(this might have too many parameters)
>> - hue-rotate(angle)
>> - gaussian-blur(radius)
>> - motion-blur(radius, angle)
>> - box-blur(radius)
>> - invert
>> - sepia
>> - color-matrix(lots)
>> - monochrome
>> - posterize(levels)
>> - bump(x, y, radius, intensity)
>> - sharpen(sharpness)
>> - unsharpen(sharpness)
>> - generator, which would take options like ("solid", rgba),
>> ("checkerboard", w, h, color1, color2) ("random")
>> - circle-crop[(x, y, radius)
>> - affine-transform(some matrix)
>> - crop(x, y, w, h)
>> - bloom(radius, intensity)
>> - gloom(radius, intensity)
>> - mosaic(w,h)
>> - displace(url, intensity)
>> - edge-detect(intensity)
>> - pinch(x, y, radius, scale)
>> - twirl(x, y, radius, angle)
>>
>> I'm worried that some of these would be too unwieldy due to the number and
>> complexity of parameters. Also, not all of them are exposed by SVG, so we'd
>> have to come up with new fe* elements.
>> I expect that we'll come up with some way for the community (users +
>> vendors) to decide what should or should not be included.
>>
>
> This is quite an extensive list of filters.
> I thought the idea was to have a small set of filters that are highly
> configurable and that have reasonable defaults instead of a large set of
> basic filters that you have to combine to make something useful.
>
>
> This was the shortlist. Like I said, I doubt any WG would agree to the
> complete list. We should start small.
> Also, we could combine some of the above so it doesn't look like there are
> as many choices. The issue there is that you move to a situation where there
> are lots of parameters.
>
> For instance, there is no drop shadow filter in your list.
>
> Drop shadows are tricky because there are already a couple of ways to do it
> in CSS. We'd have to find a way to add yet-another method without confusing
> authors. It might be the case that it is better to improve CSS drop shadows
> than add them as a filter. For example, your original use case was to shadow
> only the opaque parts of an image (whether raster or SVG). That seems like a
> pretty easy tweak to CSS.
>
>
I agree that it would be easy to amend the spec. However, it becomes a very
different operation since the browser would have to apply the effect to the
pixels of the element and all its children instead of just to its bounds.
Not sure what the W3C people would think about that...

>
>> Also note that I expect compositing modes (add, subtract, difference,
>> lighten, dodge, etc) to be a separate property.
>>
>>
> Agreed. Blending is a more complicated operation to spec out and implement
> so that can be added later.
>
> If you're really interested in having a large set of filters, you should
> take a look at a framework that we created specifically for this problem:
> http://www.adobe.com/devnet/pixelbender.html
>
>
> Yes, I'm very familiar with Pixel Bender.
>
> It is a highly configurable language that can be implemented in assembly or
> OpenGL.
>
>
> Right. The list I gave required that the effect could be accelerated where
> possible.
>
> We give away the creation tools so users can write their own set of filters
> and experiment. They can also download them from public repositories or use
> the predefined ones that we provide. PixelBender is supported in PhotoShop,
> After Effects and the Flash player.
> I'm sure we would be willing to open source the spec as well as provide a
> reference implementation.
>
>
> This basically exposes a shader language to CSS. This was considered back
> in the 1.0 days of SVG for filters. Meanwhile, WebGL provides something
> similar (although much more powerful).
>

You would have to implement a lot of JavaScript code to make that happen and
require a platform that has hardware acceleration.
Also I'm unsure if you could do it on a HTML tree and have it keep its HTML
behaviors. Filters would be of little use if you end up with a static raster
and all of the click/rollover effects are gone...


>
> I like the idea, but it's interesting to note that Adobe's PixelBender
> repository has only about 25 submissions over 3 years, with no new ones in
> more than a year. Please understand I'm not criticising the technology at
> all, I'm just wondering if there is a market for open shaders right now. As
> you show below, it would be pretty easy to extend for this later.
>

I don't know why there are so few custom shaders.
Possible reasons might be that people are happy with the built-in ones from
Flash or that PixelBender requires any ActionScript 3.
They are definitely used extensively by Photoshop and After Effects.

Rik


>
> In the meantime, people could use a combination of SVG filters and <canvas>
> (either using JS pixel manipulation or WebGL) to get fancy effects.
>
>
> the CSS could look like:
>    filter: url(dropshadow.pbk) param1 param2;
> For transitions or animations, the parameters would be allowed to change.
>
> Rik
>
>
>