Ceci est une ancienne révision du document !
Filters are an important topic for making the most out of Inkscape – at least for artistic endeavours. There's always a danger with vector graphics that they can end up looking too precise and sterile for some uses, and filters offer a way to add back in some of the subtle (and not so subtle) variations in texture and color that are often a hallmark of bitmap graphics. At least that's my justification for having spent the previous nine instalments of this series discussing filters but, having described each primitive in some detail and shown a few filter chains along the way, this article is the last on the topic, and I'll move on to something else next month. Way back in part 48, I briefly mentioned the source input columns at the right of the filter dialog (outlined in red). We've spent a little time with “Source Alpha”, and a lot more with “Source Graphic”, but that still leaves four other options that have, so far, been completely ignored. There's a good reason for that: quoting from part 48, I wrote “of the six inputs shown in the UI, two of them require special treatment… and another two don’t work at all!” Let's first of all rule out the two that don't work. “Fill Paint” and “Stroke Paint”, according to the SVG specification, should do exactly what their names suggest. They should act in a similar way to the Flood primitive, by filling the filter area with a color, but rather than specifying the value within the filter primitive itself, it is taken from the selected object's Fill or Stroke color. This sounds like a great way of pulling a couple of colors into your filter chain, and allowing you to create filters that can adapt to the colors of the objects they're applied to. Except it doesn't work at all in Inkscape.
Les filtres sont un sujet important pour tirer le meilleur parti d'Inkscape - au moins, pour des activités artistiques. Il y a toujours un danger avec le dessin vectoriel qu'il puisse paraître, au final, trop précis et stérile pour certains usages et les filtres sont souvent une façon de rajouter de fines variations (et pas si subtiles) dans la texture et la couleur qui sont souvent la marque de fabrique des dessins bitmap. Au minimum, ça justifie à mes yeux que j'ai passé les neuf derniers articles de la série à vous présenter les filtres ; mais, ayant décrit chaque primitive dans le détail et montré quelques chaînes de filtrage pendant ce temps, cet article est le dernier sur ce sujet, et je passerai à autre chose le mois prochain.
Dans la partie 48, j'ai mentionné rapidement les colonnes d'entrée sources sur la droite du dialogue des filtres (soulignées en rouge). Nous avons passé un peu de temps avec l'« Opacité de la source » et un beaucoup plus avec la « Source image » ; mais, il reste quatre autres options qui ont complètement ignorées jusqu'à maintenant. Il y a une bonne raison à cela : tiré de la partie 48, j'avais écrit ceci : « des six entrées visibles dans l'interface utilisateur, deux d'entre elles réclamant un traitement spécial - et deux autres ne fonctionnent pas du tout ! »
Tout d'abord, réglons le sort des deux qui ne fonctionnent pas. « Remplissage » et « Remplissage du contour » d'après la spécification SVG, devraient faire exactement ce que suggèrent leurs noms. Elles devraient agir comme pour la primitive Remplissage, en remplissant la zone de filtrage avec une couleur, mais, plutôt que de spécifier la couleur dans la primitive de filtrage elle-même, elle est prise à partir de la couleur de remplissage ou de contour de l'objet sélectionné. Ceci semble être un brillante façon d'introduire une paire de couleurs dans votre chaîne de filtrage, vous permettant de créer des filtres qui s'adaptent aux couleurs des objets auxquelles elles sont appliquées. Sauf que ça ne fonctionne pas du tout dans Inkscape.
There's one obvious technical issue with these input sources: a fill or stroke in SVG can be more than a simple flat color. This doesn't really affect their use in a filter chain – a pattern can be repeated to fill the filter region, as can a gradient if the definition allows it – but it does significantly complicate the rendering process for Inkscape, and has not (yet) been tackled by the developers. Nevertheless, even just being able to use solid colored fills and strokes would be a useful addition. If there are no plans to add even that much, it's long past the time when these couple of columns should be removed from the UI to avoid further confusion. The remaining source inputs, “Background Image” and “Background Alpha” can be used within Inkscape, but only after a little preparation. These inputs represent an “image snapshot of the canvas under the filter region at the time that the 'filter' element is invoked” (according to the SVG spec). In other words, they pull in a flattened bitmap version of the drawing behind the filter region (or just the alpha channel of the same area), and make it available inside the filter chain, much like a bitmap pulled in via the Image primitive. The spec also points out, however, that holding a copy of the background image in memory “can take up significant system resources”, so the SVG content must “explicitly indicate” to the application that the document needs access to the background before these two input sources will have any effect. It then goes on to define how a document should specify that it needs access to the background by putting an attribute called “enable-background” onto an ancestor container element, giving it a value of “new”. You can fiddle around with the XML editor, or even modify your file's source code in a text editor, to achieve this, but there is a much easier way.
Before explaining the simpler method, I'll use a very basic test file to clarify exactly what I'm talking about. Here I have a pair of green circles as my background objects. The background consists of any content below the filtered object in the z-order, so could just as easily have been a single shape or an entire drawing. In front of the circles is a red square, the object I'll be applying the filter to. The filter itself is quite simple – just a Color Matrix primitive set to Hue Rotate mode, using Background Image as the source. The result, at this point, is rather disappointing. The square simply becomes transparent, with no effect on the background circles at all. Now to add the “enable-background” attribute. Just open the Layers dialog and change the blend mode for one of the layers to something other than “Normal” (see Part 9 of this series if necessary). Don't panic if it has an unexpected effect on your image, as you can immediately change it back to “Normal” once again. The magic will already have been done. My test image now looks like this, with the background colors rotated within the area covered by the square's filter region. By default the filter region extends beyond the selected object, which is why the color shift is present outside the dotted outline of the selection box. The square itself has disappeared, because there's nothing in the filter chain that pulls in the “Source Graphic” input. So what happened? What was the black arts and voodoo that made the filter work just by changing a blend mode, then immediately changing it back again? It's actually quite simple: the blend mode popup in the layers dialog is just a shorthand way to add a filter with a Blend primitive to the document. You can even see it appear in the filter editor.
Although it appears in the dialog, the filter isn't attached to any objects that you can select on the canvas. Rather it is linked to the layer itself. Remember that layers are just a group with some Inkscape-specific attributes added, so it's not really any different to having a filter applied to a group of objects. When the filter is created, Inkscape automatically connects the inputs of the Blend primitive to the Source Graphic (i.e. the layer that's actually a group), and to the Background Image. At the same time, it adds the “enable-background” attribute to the root node of the SVG document, visible here in Inkscape's XML editor. The key thing is that switching the Blend Mode back to “Normal” leaves this attribute intact, although it does remove the filter. From that point on, however, you are free to use the Background Image and Background Alpha inputs in your own filter chains. That concludes our detailed examination of the mysterious art of creating your own filter chain. But, if you've been experimenting, you've doubtlessly noticed that Inkscape already supplies an extensive list of ready-made filters, grouped by type, that make up the bulk of the Filters menu. Whilst there are those gallant masochists who dare to brave the shortcomings of Inkscape's UI to create their own complex filters from scratch, many more users simply work with the default set provided. But with the knowledge you've gained over the past few months you can do better than that: you can start with a standard filter, but then dive into its guts to edit and tweak it to suit your needs. I shan't spend any time going exhaustively through the list of default filters, but instead encourage you to explore them on your own. Try creating a test sheet with some different objects and groups to work on: some of the filters work best on small objects, others on large ones; some require colorful content, others work just as well with a monochrome shape; some are wasted on intricate outlines, whilst others fail just as easily on featureless blocks of color.
A useful ability of Inkscape is that, when you copy and paste an object from one document to another any attached filters are copied with it. Why not start a “filter library” – a document into which you copy any particularly useful or impressive filters? Each time you create or find a great filter, just apply it to a suitable object, then copy and paste it into your library file. Similarly, when you want to use a filter from the library, just copy the object from the library file and paste it into your current creation. The filter will appear in the filters dialog, and, once you've applied it to something else in your image, you can safely delete the object you pasted in. Other users have already posted their own filter collections online – search for “Inkscape filter pack”, for example – so you might find that someone else has already created just the filter you need, and it's only a copy and paste away from being used in your drawings. When constructing your own filter chains from scratch, there's never really a question about what happens when you combine two primitives. You want a blurring and desaturating filter? No problem, just chain a Gaussian Blur primitive with a Color Matrix primitive (in Saturate mode). But what happens when you want to do the same with the default filters? There's an ABCs > Simple Blur (which consists of just a Gaussian Blur primitive) and also a Color > Desaturate filter in the menu (which provides a single Color Matrix primitive). What happens when you add both of them to an object? If you try it, you'll see that you get a blurred, desaturated result, so it is possible to combine the default filters in this way. But there's something odd going on in the filter chain. We don't have just the two primitives we might anticipate, but also a third one: an additional Color Matrix between the two primitives we expected. If you look closely you'll see that it's not even connected to the last primitive, so plays no active role in this chain. You can delete it entirely and it won't have any effect. So why is it there?
It turns out that this is actually a rather nice addition on the part of the Inkscape developers. Let's suppose you want to add another filter to this chain, but it's one that would normally use Source Alpha as an input. To prevent any unexpected results, you need it to use the alpha from the previous filter output, which will usually not be the same as the Source Alpha at all. These extra Color Matrix primitives act as intermediate alpha outputs within the chain. So with the addition of these, you can not only link any new primitives into the image output of each filter, but also to its alpha output as well. It's impressive that you can combine filters in this way and have them work as expected, but it can quickly lead to long, complex and hard to manage filter chains. Often a better approach is to apply one filter, then group your object before applying the next filter to the group. You can repeat this as often as necessary, creating ever deeper nesting of groups, each with its own filter applied. This certainly makes it easier to manage them in the filters dialog, as there's far less confusion about which filter you're modifying, especially if you name them well. One final thing to note is that, in 0.91 (and the just released 0.92!), many of the default filters now have an ellipsis (three dots, “…”) after their name. Choosing one of these opens a dialog which lets you enter parameters for the filter, and even see a live preview. Of course this is just a shortcut to setting parameters in the individual filter primitives, but is a welcome addition that can expose the most important parameters from across a number of primitives, whilst hiding all the other options and settings that aren't relevant in most cases. Unfortunately, there's no way to get this simplified UI back once you've dismissed it, so any subsequent tweaks will mean diving into all the gory details of the individual primitives again. Some of the separate filters from 0.48 have also been dropped, since the new parameterized filters can achieve the same effects and more. If you can't find an old favourite filter in the newer releases, look for a similar name with an ellipsis, and start tweaking the parameters!