- 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:16 UTC