Re: [Inkscape-devel] [Inkscape-user] Filter Effects example in SVN
Aaron Spike wrote:
heathenx wrote:
A fellow Inkscape user sent me a link from the SVN repo regarding a filter effect svg example file. There are quite a few different effects inside of this file which I think many of us users would appreciate having. Is it possible to get this file posted on openclipart? I'm not sure who authored the svg file but WOW!, what a nice gift. This person should be lifted up on our shoulders and paraded down main street. :)
That person is mauve. (http://mauve.mauvespace.com/) He also did a nice tutorial.
http://blog.mauveweb.co.uk/2008/04/19/svg-filters-with-inkscape-046/
I had seen him on IRC a couple mornings ago when he posted his tutorial. I asked if he'd create a bunch of stock filters for us to provide, as bulia mentioned a desire a while back for "easy filters". So, it's definitely a phenomenal start. But we also need to figure out how to implement the UI for easy filters. Just via menu options with no params? An "easy" dialog which hides the advanced bits? Or filter specific dialogs like the effects? Any other ideas?
Unfortunately, the problem is that we now have figure out where some filter related issues lie. I tried opening up the file in Batik, but it sees it as invalid. Are we producing invalid svg, or is batik just really picky? Also, some filters render differently in Firefox 3 & Opera 9.5.
So at this point, we shouldn't get overly excited until A) we're producing files batik likes (or we file a bug report with them if the problem is on their end) and B) we figure out who really has the most accurate filter implementation and either match it, or inform them if ours is "better".
-Josh
Josh Andler wrote:
I had seen him on IRC a couple mornings ago when he posted his tutorial. I asked if he'd create a bunch of stock filters for us to provide, as bulia mentioned a desire a while back for "easy filters". So, it's definitely a phenomenal start. But we also need to figure out how to implement the UI for easy filters. Just via menu options with no params? An "easy" dialog which hides the advanced bits? Or filter specific dialogs like the effects? Any other ideas?
I think it would be pretty easy to add some effects that apply a parameterized preset filter to the current selection. But it wouldn't have a fancy image preview, etc.
Aaron
On Mon, Apr 21, 2008 at 1:51 PM, Josh Andler <scislac@...400...> wrote:
I had seen him on IRC a couple mornings ago when he posted his tutorial. I asked if he'd create a bunch of stock filters for us to provide, as bulia mentioned a desire a while back for "easy filters". So, it's definitely a phenomenal start. But we also need to figure out how to implement the UI for easy filters. Just via menu options with no params?
Yes. This is what I proposed long ago. Instant-action commands with no dialogs. So they can be collected in a submenu and assigned shortcuts. In cases where some parameter really needs to be variable, do one or both of the following:
- make filter presets smart so they take into account the size of the object they're applied to and adjust their parameters accordingly
- provide several commands for the same filter, e.g. "Weak Fancy Blur", "Meium Fancy Blur", "Strong Fancy Blur".
Ideally adding a new preset filter must not involve any change in the code, but just adding it to share/filters/filters.svg from where it will be picked automatically.
I don't think it would be too difficult to implement. Any takers?
So at this point, we shouldn't get overly excited until A) we're producing files batik likes (or we file a bug report with them if the problem is on their end) and B) we figure out who really has the most accurate filter implementation and either match it, or inform them if ours is "better".
This needs to be done, but it's all pretty orthogonal to the presets implementation as outlined above.
On Mon, Apr 21, 2008 at 09:51:26AM -0700, Josh Andler wrote:
Unfortunately, the problem is that we now have figure out where some filter related issues lie. I tried opening up the file in Batik, but it sees it as invalid. Are we producing invalid svg, or is batik just really picky? Also, some filters render differently in Firefox 3 & Opera 9.5.
We are producing an invalid SVG. The 'in2' input is a required attribute in the spec. It isn't defined to default to the previous filter result like 'in'. Firefox 3 applies the same logic as Inkscape, but they have different priorities.
I've got a load of bugs to file about filters, but I'll just list them here for reference because writing them all up will be more work than I've got time for at the moment.
* Displacement mapping: input 0.5 doesn't give identity * Result identifiers can become conflicted (with undo?) * in2 attribute is required by the SVG spec * Blur of background sources shows artifacts * feFlood doesn't apply until you touch the opacity slider * feTurbulence doesn't apply until you touch the octaves slider * feMorphology radius operates as an integer (should be increments of 0.5) * feMorphology result is offset by 1px down and right * filters aren't redrawn on svg:image when settings change * sometimes settings are shown for the wrong instance of an effect * bbox for filter update on settings change isn't the filter region * spurious inputs/wires for feFlood, feTurbulence, feImage * stroke/fill paint inputs don't work? * matrix values aren't applied on blurring the matrix widget
Maybe some wishlist items too:
* Comments for documenting filters * user labels for identifing effects * preview the result of each effect * adjust values in matrix inputs with cursor up/down keys * opacity effect (implemented with feColorMatrix or feComponentTransfer) * usable defaults for specular/diffuse lighting
Dan
also, today I noticed that feMorphology is resoluton dependent. It shouldnt be.
On Mon, Apr 21, 2008 at 6:21 PM, Daniel Pope <mauve@...1559...> wrote:
On Mon, Apr 21, 2008 at 09:51:26AM -0700, Josh Andler wrote:
Unfortunately, the problem is that we now have figure out where some filter related issues lie. I tried opening up the file in Batik, but it sees it as invalid. Are we producing invalid svg, or is batik just really picky? Also, some filters render differently in Firefox 3 & Opera 9.5.
We are producing an invalid SVG. The 'in2' input is a required attribute in the spec. It isn't defined to default to the previous filter result like 'in'. Firefox 3 applies the same logic as Inkscape, but they have different priorities.
I've got a load of bugs to file about filters, but I'll just list them here for reference because writing them all up will be more work than I've got time for at the moment.
- Displacement mapping: input 0.5 doesn't give identity
- Result identifiers can become conflicted (with undo?)
- in2 attribute is required by the SVG spec
- Blur of background sources shows artifacts
- feFlood doesn't apply until you touch the opacity slider
- feTurbulence doesn't apply until you touch the octaves slider
- feMorphology radius operates as an integer (should be increments of 0.5)
- feMorphology result is offset by 1px down and right
- filters aren't redrawn on svg:image when settings change
- sometimes settings are shown for the wrong instance of an effect
- bbox for filter update on settings change isn't the filter region
- spurious inputs/wires for feFlood, feTurbulence, feImage
- stroke/fill paint inputs don't work?
- matrix values aren't applied on blurring the matrix widget
Maybe some wishlist items too:
- Comments for documenting filters
- user labels for identifing effects
- preview the result of each effect
- adjust values in matrix inputs with cursor up/down keys
- opacity effect (implemented with feColorMatrix or feComponentTransfer)
- usable defaults for specular/diffuse lighting
Dan
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, Apr 21, 2008 at 06:44:30PM -0300, Felipe Sanches wrote:
also, today I noticed that feMorphology is resoluton dependent. It shouldnt be.
Yes! I'd noticed that but forgotten about it again.
I was wrong before - it's only 0.5 pixel increments at 1:1. When zoomed in you can render more accuate feMorphology radii. Of course, when zoomed out you can only render less accurate radii.
It's still going to be quirky though - it's not defined in such a way as to be a properly scalable effect, as you can't take a maximum of a fraction of a pixel. There are ways to generalise it to fractional radii (eg. supersampling), but they would be outside of spec.
Dan
participants (5)
-
Aaron Spike -
bulia byak -
Daniel Pope -
Felipe Sanches -
Josh Andler