Difference between revisions of "Filter Effects"

From Inkscape Wiki
Jump to: navigation, search
(Status of the filter primitives)
(Status of the filter primitives: added link to feImage report email)
Line 62: Line 62:
 
|-
 
|-
 
! [http://www.w3.org/TR/SVG11/filters.html#feImageElement feImage]
 
! [http://www.w3.org/TR/SVG11/filters.html#feImageElement feImage]
|style="background-color:#ffffbb;"| '''Work in progress''' - see [http://article.gmane.org/gmane.comp.graphics.inkscape.devel/21524]
+
|style="background-color:#ffffbb;"| '''Work in progress''' - see [http://article.gmane.org/gmane.comp.graphics.inkscape.devel/21524], [http://article.gmane.org/gmane.comp.graphics.inkscape.devel/24328]
 
|style="background-color:#ffbbbb;"| '''Not implemented'''
 
|style="background-color:#ffbbbb;"| '''Not implemented'''
 
|-
 
|-

Revision as of 21:09, 22 January 2008

Filter effects is a part of SVG specification. It has been worked on in Inkscape as part of Googles_Summer_Of_Code 2006 and 2007 and COSS's Kesäkoodi 2007

For more info on this Kesäkoodi project, see the project blog or the project plan.

User interface for filter effects was developed in GSoC 2007.

For information about internal workings of filter effects renderer, please see page Filter effects internals.

What works in Inkscape 0.45

Basic support for filter effects is included in 0.45 release. At the moment only gaussian blur is implemented, so while specifications define a bunch of other effects and some other programs can handle them, Inkscape cannot render them yet. Also, tools for editing other types of filters do not exist yet.

Gaussian blur can be applied to an object by using Blur slider in Fill and stroke dialog.

In Inkscape preferences dialog there is a setting controlling the filter rendering quality. Even low quality often produces good enough rendering quality, but it takes a lot less time to render. When exporting an image from Inkscape, the best quality is always used, regardless of this setting.

Filter Effect support in trunk

Status of the filter primitives

primitive renderer user interface
feBlend Implemented Implemented
feColorMatrix Implemented Implemented
feComponentTransfer Not implemented Partially Implemented
feComposite Implemented Implemented
feConvolveMatrix Partial implementation

TODO:

  • edgeMode behaviour
  • produce resolution-independent results
Implemented
feDiffuseLighting Implemented Implemented
feDisplacementMap Implemented Implemented
feFlood Implemented Implemented
feGaussianBlur Implemented Implemented
feImage Work in progress - see [1], [2] Not implemented
feMerge Implemented Implemented
feMorphology Implemented Implemented
feOffset Implemented Implemented
feSpecularLighting Implemented Implemented
feTile Partly Implemented Needs some analysis
feTurbulence Implemented Implemented

general bugs

UI

  • Connecting a Filter with itself, connect it to one of the reserved keywords.[3]

Renderer

  • StrokePaint and FillPaint input images are not supported. [4]
  • Result from filter is not cut to the shape of filter effects area. Note that filter effects area can be a rotated rectangle or parallelogram when viewed in display coordinates.
  • There are many parts in filtering code marked with TODO. Many of these mark unhandled corner cases and places, where the filters generate almost but not quite correct results.

What next?

Now that this one filter works, most of the basic framework needed for filtering exists.

These are the basic steps to create a new filter primitive:

  • Write a new document model level class for this filter primitive (see src/sp-gaussian-blur.cpp) - note that while there are basic implementations for many filter primitives, they do need plenty of changes.
  • Write a renderer for this filter primitive (see src/display/nr-filter-gaussian.cpp)
  • Add a pointer to a function returning an instance of the renderer class to function Filter::_create_constructor_table in file src/display/nr-filter.cpp

(this is likely not an exhaustive list)

Before new filter primitives can be useful, there has to be an user interface for applying them to shapes. A really good thing would also be an UI for creating filters out of filter primitives.

See [1628343] for my filter UI suggestion - Mauve 01:44, 7 February 2007 (UTC)

Mockups of Filter editing and related dialogs

Presentation of new Fill and Stroke dialog where user can easily access most frequent actions like changing Blend modes, Blurring and Opacity of an object and select filter for an object or group of objects WITHOUT ability of accessing editing of the same.

Fill and stroke.png

Changing of effect parameters and building sets of same can be done in specialized editor. Maybe next step in pushing ease of effect use further could be loading of contributed sets of effects and their parameters from file user had made himself or downloaded according to his preference from Effect library hosted somewhere on net (inkscape.org?!).

Filter edit dialog.png

Possible benefits of this approach:

- Speed-ups - no need to redraw canvas for every single effect parameter tweaking

- Effect library - like noted above; SVG effects can be very hard to deal with for a designer/illustrator without technical background. This way developers can make a small set of commonly used effects like drop shadow, outer/inner glow, etc. Learning curve for such (I think targeted) user will be shorter because he/she will eventually catch up with internal way of dealing with effects by doing simple changes on occasion.

Another possible mock-up of the filters dialogue: http://wiki.inkscape.org/wiki/images/INKSCAPE_filters_dialogue.svg

-using extra windows to tweak effect parameters (its good for effects with 1 parameter, but most have at least 2. hmm)