Re: Filter Templates

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 
<http://weblog.bocoup.com/css-svg-filters-unaccessible-from-elem-style-xlink-href>

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 22:10:03 UTC