- From: Alistair MacDonald <al@bocoup.com>
- Date: Thu, 24 Feb 2011 17:01:51 -0500
- To: Dean Jackson <dino@apple.com>
- CC: Rik Cabanier <cabanier@gmail.com>, Rik Cabanier <cabanier@adobe.com>, Cameron McCormack <cam@mcc.id.au>, Brad Kemper <brad.kemper@gmail.com>, www-style list <www-style@w3.org>, "public-fx@w3.org" <public-fx@w3.org>
- Message-ID: <4D66D54F.3010900@bocoup.com>
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