Ceci est une ancienne révision du document !
This month, I’ll be concluding my look at the Trace Bitmap dialog by examining the new tracing modes that have been introduced with Inkscape v1.0, including one that has been much requested on the forum over the years. Autotrace Inkscape has long offered tracing of bitmaps using the Potrace library. While this does a fine job of vectorising raster graphics, it’s not the only open source tool that performs this trick. Autotrace is a command-line tool of similar vintage, which has now been integrated into the Trace Bitmap dialog. It’s available in the mode selection pop-up, in both single-scan and multiple-scan varieties. The latter is labelled as “Autotrace (slower)”, suggesting that it probably shouldn’t be your first choice for a multiple-scan conversion – a suggestion that I’ll come back to later. For now, however, we’ll start by looking at the single-scan variant.
Ce mois-ci, je conclurai mon étude de la boîte de dialogue Trace Bitmap en examinant les nouveaux modes de traçage qui ont été introduits avec Inkscape v1.0, dont un qui a été très demandé sur le forum au fil des ans.
Autotrace
Inkscape propose depuis longtemps le traçage des bitmaps à l'aide de la bibliothèque Potrace. Bien que cette dernière fasse un excellent travail de vectorisation des graphiques matriciels, ce n'est pas le seul outil Open Source qui réalise cette opération. Autotrace est un outil en ligne de commande du même type, qui a été intégré dans la boîte de dialogue Trace Bitmap. Il est disponible dans la fenêtre pop-up de sélection du mode, à la fois en version simple et multiple. Cette dernière est étiquetée « Autotrace (slower) », ce qui suggère qu'elle ne devrait probablement pas être votre premier choix pour une conversion à balayage multiple - une suggestion sur laquelle je reviendrai plus tard. Pour l'instant, cependant, nous allons commencer par examiner la variante à un seul balayage.
Once selected, it offers two spinboxes and an “Invert image” checkbox. The latter, as the name suggests, inverts the image colors before tracing, making it easier to trace a light-on-dark design without having to manually process it first. The effect of the two spinboxes is somewhat harder to guess at. The scant documentation for Autotrace – basically an online copy of the man page for the command-line tool – describes the “Filter iterations” option thus: Smooth the curve the specified number of times prior to fitting. Without knowing what is meant by “fitting” in this algorithm, it’s hard to infer what this actually does. Trial-and-error suggests that it reduces the fidelity of the trace somewhat, smoothing out the generated vectors and tending to result in a trace with fewer nodes. Here’s what the most extreme values look like when applied to dear old Frankie. The original bitmap is on the left, with clipped versions of the traced head to the right. For the top trace, the filter iterations was set to 1; for the bottom it was set to 20.
Une fois sélectionné, il propose deux boîtes à compteur et une case à cocher « Inverser l'image ». Cette dernière, comme son nom l'indique, inverse les couleurs de l'image avant le traçage, ce qui permet de tracer plus facilement un dessin clair sur foncé sans avoir à le traiter manuellement au préalable. L'effet des deux boîtes à compteur est un peu plus difficile à deviner.
La maigre documentation d'Autotrace - qui est en fait une copie en ligne de la page de manuel de l'outil en ligne de commande - décrit l'option « Filter iterations » comme suit : Lisser la courbe le nombre d'itérations spécifié avant l'ajustement. Sans savoir ce que l'on entend par « ajustement » dans cet algorithme, il est difficile d'en déduire ce que cela fait réellement. Les essais et erreurs suggèrent qu'il réduit quelque peu la fidélité de la trace, en lissant les vecteurs générés et en tendant à produire une trace avec moins de nœuds. Voici à quoi ressemblent les valeurs les plus extrêmes appliquées à ce bon vieux Frankie. Le bitmap d'origine est à gauche, avec des versions rognées de la tête tracée à droite. Pour la trace du haut, le nombre d'itérations du filtre a été fixé à 1 ; pour celle du bas, il a été fixé à 20.
Note that the higher iterations have reduced or wiped out the whites of the eyes, while the veins on the brain are a mere shadow of the original. The shape of the ear and of the brain’s outline are also significantly smoother. The total node count for the traced head is 485 for the top image and 410 for the bottom one. The second spinbox, for setting the “Error threshold”, is described like this in the man page: Subdivide fitted curves that are offset by a number of pixels exceeding the specified real number. This one I can at least have a guess at. The process of tracing a bitmap consists of generating paths that approximate the shape of the original pixels. The paths will most likely be a close match in some areas, but not as accurate in others. This parameter allows you to set the threshold before which a path segment will be considered too far away, and will be subdivided into two paths to make it easier to adjust them to fit. Setting a small value here allows only slight deviation from the pixel positions, at the expense of a lot more subdivisions and, therefore, more nodes in the result. Let’s take a look at how Frankie fares with values of 1.0 (top) and 10.0 (bottom).
Notez que les itérations plus nombreuses ont réduit ou supprimé le blanc des yeux, tandis que les veines du cerveau ne sont qu'une ombre de l'original. La forme de l'oreille et le contour du cerveau sont également beaucoup plus lisses. Le nombre total de nœuds dans le tracé de la tête est de 485 pour l'image du haut et de 410 pour celle du bas.
La deuxième boîte à compteur, pour le réglage du « seuil d'erreur », est décrite comme suit dans la page de manuel : Subdivise les courbes ajustées qui sont décalées d'un nombre de pixels dépassant le nombre réel spécifié. Cette fois-ci, je peux au moins deviner. Le processus de traçage d'un bitmap consiste à générer des chemins qui se rapprochent de la forme des pixels d'origine. Les chemins seront probablement très proches dans certaines zones, mais moins précis dans d'autres. Ce paramètre vous permet de définir le seuil avant lequel un segment de trajectoire sera considéré comme trop éloigné, et sera subdivisé en deux trajectoires pour faciliter leur ajustement. Si vous définissez une petite valeur, vous ne pourrez vous écarter que légèrement de la position des pixels, au prix d'un nombre beaucoup plus important de subdivisions et, par conséquent, de nœuds dans le résultat. Voyons comment Frankie s'en sort avec des valeurs de 1,0 (en haut) et 10,0 (en bas).
It’s pretty clear that the higher value results in a trace that is so smoothed out as to lose many of the original shapes completely. The top image, where the paths were much more heavily subdivided, consists of 587 nodes; the bottom one has only 327. As is often my advice in this column, I suggest most users should at least start with the default values for both spinboxes, and start tweaking them only if you need to improve the fidelity of the trace, or want to take the counter-approach of reducing the number of nodes. Even in the latter case, I would probably be more inclined to trace with the defaults and then use Path > Simplify afterwards. Perhaps the biggest question is how the Autotrace results compare with the Potrace equivalents. Here’s another pair of traced Frankies created using the default settings: The Potrace-based “Brightness cutoff” at the top; the Autotrace version at the bottom. Again, the full head on the left is the original raster image. The first thing to note is that the Autotrace version has maintained the grey color of the original image – though that’s such a trivial thing to change that it shouldn’t be used as a reason to select one over the other. The Potrace result is a lot crisper, with the paths more accurately maintaining the sharp corners of the head, and thinner lines of the eyebrows. This accuracy is reflected in the node count: 1090 for Potrace but only 440 for Autotrace.
Il est assez clair que la valeur la plus élevée donne un tracé tellement lissé qu'il perd complètement la plupart des formes originales. L'image du haut, où les chemins ont été beaucoup plus fortement subdivisés, comporte 587 nœuds ; celle du bas n'en comporte que 327.
Comme je le conseille souvent dans cette rubrique, je suggère à la plupart des utilisateurs de commencer avec les valeurs par défaut pour les deux boîtes à compteur, et de ne commencer à les modifier que si vous avez besoin d'améliorer la fidélité du tracé, ou si vous voulez adopter la contre-approche consistant à réduire le nombre de nœuds. Même dans ce dernier cas, je serais probablement plus enclin à tracer avec les valeurs par défaut et à utiliser ensuite Path > Simplify.
La question la plus importante est peut-être de savoir comment les résultats d'Autotrace se comparent aux équivalents de Potrace. Voici une autre paire de Frankies tracés, créés avec les paramètres par défaut : En haut, le « Brightness cutoff » de Potrace ; en bas, la version d'Autotrace. Encore une fois, la tête complète à gauche est l'image raster originale.
La première chose à noter est que la version d'Autotrace a conservé la couleur grise de l'image originale - bien que ce soit une chose si triviale à changer que cela ne devrait pas être utilisé comme une raison pour choisir l'une plutôt que l'autre. Le résultat de Potrace est beaucoup plus net, les trajectoires conservant plus précisément les angles aigus de la tête et les lignes plus fines des sourcils. Cette précision se reflète dans le nombre de nœuds : 1090 pour Potrace mais seulement 440 pour Autotrace.
But it’s not that clearcut. The extremely thin lines on the brain are actually better preserved by the Autotrace algorithm. On the whole, I think the old Potrace code works best, at least in this case. But I also wouldn’t rule out creating a hybrid result by using node editing or Boolean operations to paste together the best parts from each result. Autotrace (multiple scans) What about using the “Autotrace (slower)” mode for scanning color images? My advice is to avoid it completely and stick to the Potrace-based modes. I tried scanning the same images that I used for part 19 of this series: the Full Circle Magazine logo, and a Wikimedia Commons copy of “La Giaconda” (The Mona Lisa). In both cases I used the default settings. The logo, which takes less than a second to trace with Potrace, took several minutes to complete. With such an amount of effort involved you might expect something impressive, but this is what the result looks like (original bitmap on the left, Autotrace in the middle, Potrace on the right):
Mais ce n'est pas aussi clair. Les lignes extrêmement fines sur le cerveau sont en fait mieux préservées par l'algorithme d'Autotrace. Dans l'ensemble, je pense que le vieux code de Potrace fonctionne mieux, du moins dans ce cas. Mais je n'exclurais pas non plus de créer un résultat hybride en utilisant l'édition de nœuds ou des opérations booléennes pour coller ensemble les meilleures parties de chaque résultat.
Autotrace (balayages multiples)
Qu'en est-il de l'utilisation du mode “Autotrace (plus lent)” pour la numérisation d'images en couleur ? Je vous conseille de l'éviter complètement et de vous en tenir aux modes basés sur Potrace. J'ai essayé de numériser les mêmes images que celles que j'ai utilisées pour la partie 19 de cette série : le logo de Full Circle Magazine, et une copie Wikimedia Commons de “La Giaconda” (La Joconde). Dans les deux cas, j'ai utilisé les paramètres par défaut. Le logo, dont le traçage avec Potrace prend moins d'une seconde, a nécessité plusieurs minutes de travail. Avec un tel effort, on pourrait s'attendre à quelque chose d'impressionnant, mais voici à quoi ressemble le résultat (bitmap original à gauche, Autotrace au milieu, Potrace à droite) :
To you and I it may appear as though Autotrace spent several minutes producing a salmon-colored circle. But no: what you’re actually looking at is a group of 4180 objects! For comparison the Potrace version contains 8 objects – one for each color set via the “Scans” spinbox. Switching to the outline view does suggest that the shapes have been traced, and are hidden somewhere in the salmon fillet before us, but the thicker outlines definitely hint at complex paths compared with the simplicity of the Potrace version. And what of La Giaconda? After many minutes of processing my memory, swap and CPU were all maxed out, then Inkscape disappeared off my screen entirely. There was no appearance of the usual crash dialog I see when it dies, leading me to suspect that its demise was perhaps the fault of the Linux kernel killing it due to lack of available resources.
Even with a “successful” trace, the sheer number of objects created is practically unmanageable. There may, perhaps, be some image types for which this mode offers an advantage, but I would try it only if the Potrace methods aren’t yielding acceptable results – and make sure to save your file first! Center Line Trace If Autotrace offers little or no improvement over Potrace, and in some cases is far too resource hungry, why bother adding it to Inkscape at all? The reason is that it offers one type of frequently requested tracing mode that Potrace does not – center line tracing. In fact the menu entries described previously are there only as a side-effect of including this mode. After all, if you’re adding the library anyway, why not also expose the standard tracing mode as well, to give your users more options.
Center line tracing is really applicable to only line art in which the shapes are made up of individual pen or pencil strokes. Using other tracing modes, each stroke is converted into a closed, filled path that reflects the thickness and shape of the original artwork. With this new mode, however, the tracing algorithm attempts to determine a single path that traces out a line following the middle of the original stroke. For the most simple real-world example, consider a single pen stroke on paper, scanned and imported into Inkscape. The top line in this image is the original scanned raster graphic. The second shows the result of a normal trace – note that the bulbous ends of the line are reproduced in this mode. The third line is the result of a center line trace – no thickening of the line at the ends of this version. The real difference becomes clear when we take a closer look at the nodes used to make up the two traced paths. The first is a closed, filled path, so you can see that the nodes make up the outer shape of the stroke. The center line trace, on the other hand, results in an open path made up of a simple line of nodes: any suggestion of line thickness is purely down to the value set for the stroke width.
What happens when you try this mode with a more complex example? How about a few handwritten letters? As you can see, the trace doesn’t really reflect the shapes and writing style of the original scanned image. The fairly straight left leg of the A becomes kinked in the middle, as the algorithm struggles to work out where the center line actually is. The sharply angled line where the top and bottom bowls of the B meet is lost entirely, and replaced with a horizontal crossbar. You may also have realised that such shapes can’t be made up of a single path segment. In this instance we’ve ended up with a single complex path consisting of all the different segments that make up the letters combined into one object. Path > Break Apart allows us to reduce the complex path down to its constituent parts, which we can then give different colors to demonstrate the paths that the algorithm settled on.
The A, not unreasonably, is made up of three separate paths. But the complexity of the B is captured in only two paths: one complex curving line that encompasses most of the shape of the letter, and a small straight segment to fill in the remaining gap. Wrangling such shapes into something more befitting the original outlines could quickly become tedious on larger projects. You may think I’m being unfair on the algorithm here. My scanned text was from a thick Sharpie, rather than the thin strokes of a pencil or ballpoint pen. But based on my testing, you’ll likely face similar issues, even when starting with thinner lines in the source material. That’s not to say that the new mode is useless or unwelcome. For many images it will prove to be far more effective than the existing tracing methods, especially if you’re interested in only the core shapes of the elements rather than the exact details of the stroke outlines. Just remember that it’s working only with pixels, and has no concept of the order in which lines were laid down, or the difference between two lines that meet at an angle compared with a single line that has a sharp corner in it.
As is so often the case with the Trace Bitmap dialog, I can only recommend that you give it a try on your image, but don’t expect miracles. Even if the results aren’t perfect, it may save you some manual tracing time on part of your design, or at least give you a starting framework to build upon. Next month, we’ll take a look at the new “Selectors and CSS” dialog, which promises to make Inkscape a little more useful as a web development tool.
Links Potrace: http://potrace.sourceforge.net Autotrace: http://autotrace.sourceforge.net/ https://github.com/autotrace/autotrace Autotrace man page: https://linux.die.net/man/1/autotrace “Frankie” and other images: http://www.peppertop.com/fc/
Liens
Potrace : http://potrace.sourceforge.net
Autotrace : http://autotrace.sourceforge.net/ https://github.com/autotrace/autotrace
Page du manuel d'Autotrace : https://linux.die.net/man/1/autotrace
« Frankie » et les autres images : http://www.peppertop.com/fc/