Re: Filter Templates

On Feb 23, 2011, at 3:07 PM, Rik Cabanier wrote:

> Did you make any progress on the proposal?

No, sorry, I have not.

You list 4 effects below. Do you have others in mind? 

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.

Also note that I expect compositing modes (add, subtract, difference, lighten, dodge, etc) to be a separate property.

Dean

>  
> Rik
>  
> From: Dean Jackson [mailto:dino@apple.com] 
> Sent: Monday, February 07, 2011 10:11 AM
> To: Rik Cabanier
> Cc: Cameron McCormack; Brad Kemper; www-style list; public-fx@w3.org
> Subject: Re: Filter Templates
>  
> If you read the minutes of the public-fx telecon, which you are welcome to attend btw, you'll see that we did agree to move forward on a set of canned filters. I volunteered to write up a proposal.
>  
> I agree with Rob's followup about complexity as well. 
>  
> Dean
>  
> On Feb 6, 2011, at 2:06 PM, Rik Cabanier wrote:
> 
> 
> All,
>  
> I never heard back on my proposal.
> Is it because it’s too limited or doesn’t rely on SVG?
>  
> I believe the CSS filters need to be very simple so
> -          They can be accelerated on the GPU
> -          The can be implemented by browsers that choose not to implement SVG filters.
>  
> rik
>  
> From: Rik Cabanier 
> Sent: Wednesday, January 26, 2011 2:57 PM
> To: 'Cameron McCormack'; Brad Kemper
> Cc: www-style list; public-fx@w3.org
> Subject: RE: Filter Templates
>  
> Instead of embedding or referring to SVG filters, could we instead implement a small subset of filters in CSS syntax?
> Part of the spec would describe how they will map to SVG.
>  
> This would make it very easy for the user to apply simple effects and it would also limit the number of filters that a browser vendor would need to implement.
> In addition, since it's CSS with established rules, it could be used in transitions and animations.
> Here's a set of canned filters:
> 1.       blur(X, Y, Q) with
> a.       X = width of the blur box
> b.      Y = height of the blur box
> c.       Q = number of passes
> 2.       dropshadow(X, Y, Q, C, A, D, S, I, K) with
> a.       X = width of the blur box
> b.      Y = height of the blur box
> c.       Q = number of passes
> d.      C = color
> e.      A = angle of the dropshadow
> f.        D = distance vector of the dropshadow
> g.       S = strength (Color of the dropshadow is multiplied by this)
> h.      I = inner shadow
> i.         K = knockout (just display the shadow, not the original artwork)
> 3.       gradientglow/bevel
> 4.       colormatrix
>  
> A user could define an animation with the following syntax:
> -keyframes animatedblur
> {
> from{
> -transform: translate(-100px, 50px);
> -filter: blur(5);
> }
> to{
> -transform: translate(200px, 50px);
> -filter: blur(0);
> }}
>  
> Or he could use a list of filters:
> -filter: blur, dropshadow
>  
> Rik
> > -----Original Message-----
> > From: public-fx-request@w3.org [mailto:public-fx-request@w3.org] On
> > Behalf Of Cameron McCormack
> > Sent: Tuesday, January 11, 2011 12:23 PM
> > To: Brad Kemper
> > Cc: www-style list; public-fx@w3.org
> > Subject: Re: Filter Templates
> > 
> > Brad Kemper:
> > > Given the above "feTemplate" values, it could be used in a declaration
> > > like this:
> > >
> > > filter: url(#bradsDropShadow) 4px 5px;
> > >
> > > ...and the two lengths would be mapped to the "dx" and "dy" of
> > > feOffset.dx, and the omitted values would take their default values
> > > from the regular filter values ("black" for flood-color and "2" for
> > > stdDeviation in the above example), as long as the order and so forth
> > > of the feTemplate values were satisfied.
> > >
> > > Could that work?
> > 
> > I like this idea too – it could be a good solution to the problem that filters are
> > often very specific to the content they’re going to be applied to.
> > 
> > As with Tab, I’m not sure about the feTemplate syntax, but I like the idea in
> > general.  I think we need to carefully think about what parameters the filters
> > are allowed to expose; we obviously don’t want this to turn into a general
> > templating solution.
> > 
> > There’s some overlap here with Doug’s SVG Parameters proposal, too, at
> > least conceptually:
> > 
> >   http://www.w3.org/TR/2009/WD-SVGParam-20090616/
> > 
> > --
> > Cameron McCormack ≝ http://mcc.id.au/
>  
>