Re: Filter Templates

On Feb 24, 2011, at 12:43 PM, Rik Cabanier wrote:

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

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

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

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.

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

Received on Thursday, 24 February 2011 21:27:18 UTC