Re: Filter Templates

Hi Dean,

any news on the filter front?
Maybe we can start by defining 1 simple filter like "box-blur(radius)" and
go from there.

I read the notes from the SVG meeting in Auckland where this exchange was
discussed and it sounded very encouraging.

Rik

On Wed, Feb 23, 2011 at 6:42 PM, Dean Jackson <dino@apple.com> wrote:

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