Giving the file a fair reading before anything else runs

The file is not the same thing as the drawing

It is tempting to think of a PNG or a JPEG as simply "the picture" — open it, trace what is there. But a raster file is one snapshot of a drawing, at one size, saved by one program, and any of those three facts can quietly work against the tracer.

Someone with a small logo who wants a large one often resizes the file first, with the crudest possible method, before it ever reaches this tool. A photo-style compressed file adds faint ripples of colour near edges that were never part of the original artwork. And a file with a transparent background hands the tracer a problem it has no way to solve directly — the maths behind reading an edge (stage 2) needs two solid colours to measure a boundary against, not one colour and a see-through hole.

Intake is where all of that gets sorted out, before the palette, the boundaries, or anything downstream ever looks at a pixel.

Reading the file the way a viewer shows it

The first job is simply to read the file, and to read it the way an image viewer would, because the picture a person drops on the tool is the picture they saw.

• The file's own bytes decide what kind of file it is, not its name. Every image format starts with a short signature, and the tool reads that. A JPEG saved with a .png name, or a PNG renamed to .jpg — common after a browser's "save image as" — used to be refused; it is now read as what it is, pixel for pixel the same as the correctly named file. Only when the bytes carry no signature at all does the name choose how to read them.
• A phone photo is turned upright. Cameras store the picture as the sensor saw it and add a small note saying which way up to show it. Every viewer follows the note; the tracer used to ignore it and traced such photos on their side. It now turns the picture the way the note says before anything is traced, and reports the size the right way round too.
• A colour profile is converted to ordinary screen colours. Some files carry a profile saying their numbers belong to a different colour space — a Mac screenshot in Display P3, a photo in Adobe RGB, an old print file with a different brightness curve. A viewer converts those to the colours the screen shows, and now the tracer does the same, converting to sRGB. On six test images with such a profile the colour error fell from 0.85 to 0.12 on average, measured before and after the change on the same run. A profile that already describes sRGB leaves the file exactly as it was.
• An empty image is refused. A damaged file can decode to a picture that is zero pixels wide or zero pixels tall. There is nothing to trace in it, and it used to crash a later step; it is now turned away at once with a plain error saying it has no pixels.
• A very large file that will be shrunk anyway is allowed more room while it is read. A file over the size limit is reduced as it is read, so the tool lets such a decode use up to 1.25 GiB rather than refusing a large but genuine picture. A file that only pretends to be enormous, a few kilobytes claiming billions of pixels, is still refused before any memory is spent on it.

Undoing an accidental zoom

Resize a small image with the simplest method a computer offers — "nearest neighbour" — and every pixel becomes a solid square block, four, eight, sixteen times its original size. Nothing new was drawn; the same handful of pixels was just repeated. A tracer that does not know this happened will faithfully draw the staircase of block edges, because as far as it can tell, that staircase is the artwork.

This check is deliberately strict — every pixel in every block has to match exactly, with no wiggle room. A looser test would also catch a logo that genuinely contains large flat squares, and undoing those would throw away real artwork. On a 96-pixel logo blown up to 768 pixels, skipping this step means the tracer describes the staircase directly: thirteen colours instead of three, and over fifteen hundred straight little lines walking around pixel corners instead of the handful of smooth curves the artist actually drew.

The zoom need not be a whole number. A browser at 350 % turns each pixel into a block three or four pixels wide, alternating, and until October 2026 the tool only recognised whole-number blow-ups, so such a picture was traced block by block: on 28 test images, thirteen times the artist's number of points and a colour error three times what the original pixels give. The check now looks at where the colour changes from one column (and one row) of pixels to the next. In a blow-up, every change sits at the start of a block, and the block starts follow the zoom factor to within one pixel; the tool finds the one factor, whole or not, whose block starts include every change, keeps one pixel per block, and checks that repeating those pixels rebuilds the picture exactly before it trusts the answer. On ordinary artwork two neighbouring columns both change somewhere within the first few rows of the drawing, which no blow-up of two or more can do, and the check ends there. All 28 of the 3.5× images came back as their originals, and on all the benchmark's ordinary images the check never fired.

It also stopped giving up early on wide, short logos. A wordmark 128 pixels wide and 50 tall, blown up four times, used to be undone only halfway, because the original rule refused to leave fewer than 64 pixels on either side; now only the long side keeps that floor.

Images that were enlarged smoothly

Most image editors enlarge with a smooth filter instead, and then there are no blocks to find: every edge of the drawing is simply spread over several pixels. That is just as misleading to a tracer built for crisp one-pixel edges — the in-between colours of each smeared edge look like extra inks, and the extra pixels look like extra detail to describe. When every strong edge in the picture is wider than a crisp drawing can make one, and the spread says it was enlarged three times or more, the tool shrinks the picture back by that factor first (keeping the thinnest strokes at least three pixels wide), traces the smaller version, and writes the SVG at the original size. On images enlarged four times this way, the colour error fell by about 30 % and the number of points by two thirds.

Two kinds of picture look soft but are left alone. A crisp logo with a soft glow or drop shadow has smeared edges too — the glow's — but its own edges are still sharp, and the tool checks for that before it shrinks anything; an earlier version did not, and blurred such logos down to a fraction of their size. And an image enlarged only twice is traced as it is, because shrinking it measured slightly worse than leaving it.

Telling a compressed file from a clean one

Photo-style compression (the kind JPEG uses) does not blur an edge — it leaves the edge itself mostly alone and instead adds a faint ripple of colour in the flat areas just beside it, an artefact of how the compressor represents smooth regions cheaply. Two different checks were tried to catch this automatically, and both were fooled, for related reasons worth stating honestly rather than glossing over:

• Measuring how wide an edge is does not see it, because the ripple does not widen the edge — it sits beside it, in territory the width measurement is not looking at.
• Measuring random noise in flat areas does not see it either, because the ripple only occupies a thin band next to each edge; an icon is mostly empty, so the "typical" noise level across the whole image stays at its floor, exactly as it would on a perfectly clean file.

This was not a hypothetical risk. A real compressed logo measured a native 1.15-pixel edge width against a 1.75-pixel threshold meant to catch resizing damage — comfortably under it — so the safeguard that should have caught the damage stayed off, and the tracer dutifully treated the compression ripple as real ink. The result was 243 separate paths across 1301 separate regions, 89% of which together covered only 5% of the drawing — noise, not artwork, each ripple minted as its own tiny shape.

A third pixel-level idea was also tried and also refuted: measuring how jagged the colour is in supposedly flat areas. It separated clean files from compressed ones cleanly — until it met a genuinely clean smooth gradient, which scored as more "damaged" than the compressed flat icon, because ordinary 8-bit colour ramps produce the same kind of small jumps a lossy codec does. None of those three checks could separate the two. So the fix did not try to get cleverer about pixels — it reads the file's own container format, which states the fact exactly rather than estimating it. A JPEG is lossy. A PNG is not. A WebP says which of its two internal codecs it used, right there in its header.

The container has one blind spot: a JPEG re-saved as a PNG no longer admits what was done to it. A later, more targeted pixel check covers that case. Instead of asking how much ripple there is, it asks where the ripple sits — in a band a few pixels out from each edge, where clean artwork is perfectly flat — and whether it flips up and down from one pixel to the next, as compression ripple does and a smooth gradient does not. It now switches on the same safeguard; the palette stage describes it in full.

This matters for a reason beyond one file type. Turning this safeguard on unconditionally, for every file whether it needs it or not, was tried and measured: it costs 10.9% on the tool's own quality benchmark, because on a genuinely clean file, two very similar colours really are two different inks the artist chose, and merging them throws real artwork away. The safeguard has to stay off until there is real evidence — a wide edge, a compressed file format, or that ripple pattern — that it is needed.

Same logo, four times the pixels, wildly different results

Export the same logo as a 128-pixel PNG and as a 512-pixel PNG. It is the same drawing. It should cost the same number of points and curves to describe in an SVG. For a long time, it did not — and the reason is worth walking through carefully, because it is one of the more surprising things about how this tool was tuned.

Every measurement this tool takes is stated in pixels: how confidently an edge is located, how precisely a coordinate is written down, how big a stray speck has to be before it is worth ignoring. All of those numbers were chosen by testing against images around 128 pixels on a side. Hand the same logo in at 512 pixels and nothing about those numbers changes automatically — but the boundary itself is now drawn with four times as many points, each one sitting four times as far (in raw pixels) from where a simplified curve would put it, for exactly the same shape. The book-keeping that is supposed to discourage adding unnecessary detail barely reacted — it only grew by a small, slow amount, nowhere near enough to offset how much more "wrong" a simplified curve now looks in raw-pixel terms. Faced with that imbalance, the tool kept buying more and more detail it did not actually need, one cheap-looking segment at a time.

Measured directly, on real brand logos, the effect was severe and got worse with size: 3.54 times the artist's own number of points at 128 pixels, 6.02 times at 256, 11.62 times at 512 — for a mark whose actual complexity had not changed at all.

The fix is to stop pricing everything in raw pixels and start pricing it per unit of the drawing's own content. The question is not how big the raster is — a crisp 1024-pixel drawing can be full of genuine detail — but how many pixels it spends on each unit of detail. The tool measures that two ways: how wide an edge is (a resize, a blur or a photograph smears it over several pixels), and how far the picture can be shrunk and blown back up without losing anything (a simple drawing exported larger than it needs survives that round trip untouched, even with razor-sharp edges).

One correction is always on in the full-quality mode. When the round trip says the raster carries the drawing on, say, four times the pixels it needs, and the raster is larger than the 128-pixel size the tool was tuned at, the smallest speck worth keeping is raised sixteen-fold (it is an area) and every point and curve is made four times as expensive to add. Positional precision is relaxed by the same factor only when the edges are wide as well, because a smooth drawing can survive the round trip without being oversized at all. At the 128-pixel size the tool was tuned at, and on any raster whose every pixel carries detail, none of this changes anything. One case had to be fixed along the way: a single small dot on an almost empty canvas used to pass the round trip at every size, because the empty canvas made the loss look tiny on average — the speck limit then rose high enough to erase the dot. The test now also asks that at most half of the picture's detail is lost, and the dot is drawn.

The second correction is an option. It widens the wobble a boundary point is allowed by the measured factor, so a curve that would have been accepted on a natively sized drawing is accepted again at 512 pixels from the same relative position, and it raises the price of each point to match, as its design says both halves must. It is off by default. Its help text still warns that it can mistake a small rotated square for a circle and break a thin ring, though the code's own notes trace those failures to an older version that judged by image size instead of measuring; the technical reference lists that as an open question.

When there is nothing solid to measure against

Stage 2's whole method for reading an edge depends on knowing the two colours a boundary sits between — a shape's own colour, and whatever is behind it. A transparent background is not a colour at all, so before tracing starts, every see-through pixel is written down over something solid.

By default the tool keeps the transparency itself. The picture is written down over white, but how see-through each pixel was travels alongside it into every step that reads an edge, and each ink the palette finds carries an opacity of its own. Holes stay holes and soft shadows stay soft in the finished file, so no backing colour has to be chosen at all.

That native handling can be switched off, and then the old approach applies: the picture is painted onto one solid colour before tracing. The obvious choice is white, and white is exactly wrong for a lot of real artwork. A white logo on a transparent background, painted onto white, disappears completely — there is nothing left to trace. A softly translucent panel painted onto white loses its identity and merges into the background it was meant to sit over.

So the colour used to fill in the transparency is chosen by testing what it would hide: for each of a short list of candidate colours (white first, then black, then a few saturated colours real artwork rarely uses), the tool checks how much of the image's meaningfully-drawn content — the outline of the shape, and any softly translucent area — would become indistinguishable from that candidate once painted onto it. The first candidate that would not swallow too much of the real content wins. A soft glow (opacity that fades gradually, like a light source) gets no vote either way, because no single flat colour can honestly stand in for something that was never one flat opacity to begin with.

Even in that mode this choice usually changes nothing visible in the output — the image is still painted onto plain white — because without an extra flag turned on, transparency has nowhere to go in the final file anyway: a see-through region gets painted solid rather than cut out as a hole. The smarter colour choice takes effect once that flag is on, so the file can be produced for use on a background other than white. There is one exception: when white would make more than half of the shape's outline vanish — a white logo on a transparent background — the tool turns that flag on by itself for that image, because otherwise there would be nothing left to trace.

Artwork that runs off the edge of the picture

Tightly cropped logos and stickers often touch the very edge of their canvas. The tracer used to draw those badly: where a shape met the edge it was cut into pieces that ended on the border, and those pieces were fitted one by one instead of as the closed outline the artist drew. A rounded square filling its whole canvas came back with one corner replaced by a curve stretching halfway along a side.

So when a picture with a transparent background has artwork on its outermost row or column of pixels, the tool now traces it on a canvas two pixels larger on every side, the extra pixels left transparent. The artwork then ends inside the canvas, on a closed outline, and the rounded square comes back as one rounded rectangle. Every coordinate of the finished file is then moved back by those two pixels, exactly, so the file has the size and the coordinates of the picture that arrived. The settings that depend on the picture's size are still worked out from the original size, so a picture that does not touch its edge traces exactly as before. On the test icons that touch the edge, the traces came out a fifth closer to the artist's originals at 128 pixels and a tenth closer at 512, with fewer numbers in the file.

Cleaning up genuine damage

Some input is not merely resized or slightly compressed — it is a screenshot, a heavily compressed export, or a genuine photograph of a printed logo. For that kind of damage, there is an optional cleanup step: run the image through a small model that guesses at extra detail, shrink the result back down, and repaint the flat areas with the original file's own colours so the tracer is not trusting the model's colour judgement, only its judgement about where edges should sit.

This step is expensive and not always worth it, so the tool can be told to decide for itself. In that mode, it traces the file once as it arrived, renders that trace back into a picture, and compares the two everywhere the trace claims the drawing is flat. A flat trace that disagrees with the input in supposedly flat territory is a sign of real damage rather than an honest simplification — a shape that is flat by construction should not need to argue with a clean input. Below a measured disagreement threshold, the file is traced as-is. Above it, the cleanup step runs and the file is traced again. On genuinely clean input, running this cleanup step anyway makes results roughly three times worse — which is exactly why the tool checks first rather than always cleaning up "just in case."

The cleanup itself is a separate program that ships beside the tool. If it is not installed, the deciding mode no longer fails: it keeps the trace it already made, exactly as it would for a clean file, and says in its report that no cleanup tool was available. Only asking for the cleanup outright, every time, still stops with an error when there is nothing to run it with.