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

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.

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

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