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.
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.
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).
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.
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):
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/