RE: Filter Templates

Just adding to what Alex said (see below)...


> -----Original Message-----
> From: public-fx-request@w3.org [mailto:public-fx-request@w3.org] On
> Behalf Of Alex Danilo
> Sent: Friday, 25 February 2011 10:04 AM
> To: Dean Jackson
> Cc: Alistair MacDonald; Rik Cabanier; Rik Cabanier; Cameron McCormack;
> Brad Kemper; www-style list; public-fx@w3.org
> Subject: Re: Filter Templates
>
> And of course we have the SVG comp-op property that defines exactly
> those blend modes which is part of SVG 1.2.
>
> http://dev.w3.org/SVG/modules/compositing/master/SVGCompositingPrimer.h
> tml
>
> That has been implemented by us and also exists as an Adobe namespaced
> property 'adobe:blending-mode' in ASV3 from years ago. Illustrator will
> natively export those modes in it's SVG export output.
>
> Perhaps that should serve as something to look at. This was researched
> extensively at the time, and a property works far better than the SVG
> filter mechanism when combining a lot of objects for blending.
>

This is because the background is included twice when using filters to perform compositing. This leads to incorrect results - the output tends to be darker than expected.


> Alex
>
> --Original Message--:
> >This is what we meant be compositing modes as a separate property. So
> it's definitely under consideration.
> >
> >They are very useful in a filter graph, where you are combining
> multiple image inputs (such as SVG filters, or Photoshop layers). For a
> shorthand CSS filter property, the general idea is a single image input
> that undergoes some processing. That's just my thinking, not an
> official position of the WG.
> >
> >Dean
> >
> >On Feb 24, 2011, at 2:01 PM, Alistair MacDonald wrote:
> >
> >
> >Hi FX,
> >
> >I would think it would be quite important to cover the basic overlay
> primitives offered in most graphics packages, such as:
> >
> >Screen
> >Blend
> >Add
> >Multiply
> >Exclusion
> >Dodge
> >Hard-light
> >Soft-light
> >Burn
> >Difference (difference is also great for getting visual test results
> >when comparing builds) Etc
> >
> >( I am aware we have some of these filter already available to SVG )
> >
> >Could anyone tell me if there has been an update to the way sources
> >work for filters on individual DOM elements yet? Last time I checked
> >there was no way to execute the following kind of behavior: (Using
> >multiple DOM elements as separate sources)
> >
> >
> ><svg version="1.1" xmlns="http://www.w3.org/2000/svg">
> >  <defs>
> >    <filter id="srcLoadedOverlay">
> >      <feImage xlink:href="url(#canvas0)" result="img1" />
> >      <feImage xlink:href="url(#canvas1)" result="img2" />
> >      <feImage xlink:href="url(#canvas2)" result="img3" />
> >      <feBlend in="img1" in2="img2" result="blend1" mode="multiply" />
> >      <feBlend in="blend1" in2="img3" mode="lighten" />
> >    </filter>
> >  </defs>
> ></svg>
> >
> >
> >(Using multiple DOM elements as separate sources)
> >
> >Where as this does work if using images:
> >
> ><svg version="1.1" xmlns="http://www.w3.org/2000/svg">
> >  <defs>
> >    <filter id="srcLoadedOverlay">
> >      <feImage xlink:href="no1.png" result="img1" />
> >      <feImage xlink:href="no2.png" result="img2" />
> >      <feImage xlink:href="no3.png" result="img3" />
> >      <feBlend in="img1" in2="img2" result="blend1" mode="multiply" />
> >      <feBlend in="blend1" in2="img3" mode="lighten" />
> >    </filter>
> >  </defs>
> ></svg>
> >
> >
> >I did find a work around, but it was VERY computationally expensive.
> >The test case here: (Have only tested this in Firefox4 Beta)
> >http://code.bocoup.com/svg/SVG-DOM-feBlend-issue/index.xhtml
> >
> >Any thoughts?
> >
> >Al
> >
> >
> >
> >
> >On 02/24/2011 04:25 PM, Dean Jackson wrote:
> >
> >
> >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: 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).
> >
> >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.
> >
> >Dean
> >
> >
> >
> >the CSS could look like:
> >  filter: url(dropshadow.pbk) param1 param2; For transitions or
> >animations, the parameters would be allowed to change.
> >
> >Rik
> >
> >
> >
> >
> >--
> >Alistair MacDonald
> >Bocoup, LLC
> >http://bocoup.com
> >+1-617-379-2752
> >+1-617-584-1420
> >319 A Street
> >Boston MA
> >02210
> >
> >
> >On 02/24/2011 04:25 PM, Dean Jackson wrote:
> >
> >
> >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: 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).
> >
> >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.
> >
> >Dean
> >
> >
> >
> >the CSS could look like:
> >  filter: url(dropshadow.pbk) param1 param2; For transitions or
> >animations, the parameters would be allowed to change.
> >
> >Rik
> >
> >
> >
> >
> >--
> >Alistair MacDonald
> >Bocoup, LLC
> >http://bocoup.com
> >+1-617-379-2752
> >+1-617-584-1420
> >319 A Street
> >Boston MA
> >02210
> >
> >
> >
> >
> >
>

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Received on Thursday, 24 February 2011 23:32:08 UTC