DEV Community: hashem alharhashi

I benchmarked my own vectorizer against potrace. It lost two rows out of four.

hashem alharhashi — Mon, 07 Sep 2026 13:12:00 +0000

I build a browser-based image-to-SVG vectorizer. Every tool in this category publishes a comparison table where it wins every row, which is why nobody believes any of them.

So I published the opposite: a reproducible benchmark, scripts and raw data included, where my own tool loses on speed, loses on file size, and loses outright on monochrome work.

Repository: raster-to-vector-benchmark — MIT, re-runnable.

The setup

One real logo, 1535x621 RGBA, 11,697 distinct colours. Two tracers:

potrace 1.16 — the standard, and the engine behind a lot of things you have used
12pixa — my tool. VTracer compiled from Rust to WebAssembly, running client-side in a Web Worker

The numbers

	potrace 1.16	12pixa (colour)	12pixa (B&W)
time	0.10 s	7.21 s	not measured
SVG bytes	3,331	24,119	6,503
colours	1	224	1
MAE vs original (lower is better)	10.34	3.47	13.31

potrace is roughly 70x faster and produces a file 7x smaller. That is not a rounding difference, it is two orders of magnitude on time.

And the row that hurts: my own black-and-white preset is the worst result in the table. MAE 13.31 against potrace's 10.34 on the same monochrome job. potrace beats me at the thing potrace is for.

Where my tool wins is colour — MAE 3.47, the most accurate reproduction of the three, and the only one that produces a palette at all. But "wins the row it was built for" is a much smaller claim than the marketing table usually makes.

The methodology mistake I made first — and why it matters

My first attempt compared each output against a thresholded version of the original. potrace scored 97%. My tool scored 21%.

That result was garbage, and the reason is worth internalising: potrace only accepts bitonal input, so prepare.py thresholds the image before handing it over. Comparing potrace's output to the thresholded reference compares it to its own input. It cannot lose. The benchmark was measuring "did potrace faithfully reproduce the file we gave it", which is a question with a known answer.

The fix is to score every candidate against the original colour raster — the thing a user actually had before they started. That single change flipped the outcome and produced the table above.

If you write a benchmark, the first question to ask is: does one contestant get to be measured against a reference derived from its own preprocessing? If yes, throw the numbers away.

A detail that costs people an hour

potrace 1.16 reads PBM/PGM/PPM and BMP. It cannot open a PNG. Every "potrace failed on my file" thread reduces to this. scripts/prepare.py converts first:

# 1. prepare the input (potrace cannot read PNG)
python scripts/prepare.py corpus/logo-1535x621.png

# 2. trace
potrace --svg -o results/potrace--logo.svg out/logo-1535x621.gray.pgm

Timing a browser tool has its own problem: there is no binary to wrap in time. The page is reloaded per run and measured in-page, so the number includes WASM instantiation. That is the honest way to report it — it is what the user waits through.

What I would actually tell you to use

Monochrome art, logos, line work, laser or vinyl cutting → potrace. Faster, smaller, and more accurate than my own B&W preset. Use it.
Anything with colour → potrace is not a candidate; it has no mechanism for colour at all.
7.2 seconds is slow, and I am not going to describe it as "instant".

Why publish a benchmark you lose

Two reasons.

The first is that an unfalsifiable claim is worth nothing. "Best vectorizer" is not a testable statement. "MAE 3.47 versus 10.34 on this file, here is the script" is, and you can prove me wrong in ten minutes.

The second is that this is how I would want to be sold to. When a tool tells me where it is weak, I trust the rest of the page.

The corpus, the scripts, the raw JSON and the SVG outputs are all in the repo. If you re-run it and get different numbers, open an issue — I would rather fix the benchmark than defend it.

The tool is 12pixa — free, no upload, no account, runs entirely in the browser through WebAssembly. Built by AiJoLabs in Amman, Jordan.

I shipped 65 tools. Then I deleted 64 of them.

hashem alharhashi — Wed, 12 Aug 2026 12:44:56 +0000

A year ago I shipped a site with 65 small image tools. Resize, crop, compress, convert, rotate — the usual grid of utilities. It looked productive. It wasn't.

Analytics said something uncomfortable: almost nobody used 64 of them. One tool had returning users, real session time, and people coming back with different files. It was the image-to-SVG vectorizer.

So I deleted the other 64.

Here's what I learned rebuilding around the one thing that worked.

Grouping traced paths by exact hex is useless on real images

The vectorizer has a colour/layer editor — pick a colour, hide it or recolour it. The obvious implementation groups SVG paths by their exact fill value.

That works beautifully on the synthetic test logo I built it against. Then a user sent me a real file: a gold emblem, photographed.

The trace produced 3,428 paths across 3,122 distinct hex values. Almost every path had its own colour. The palette showed the top 24 by frequency, which together covered 83 paths — 2% of the image. Clicking a swatch did nothing you could see. The feature was technically working and practically broken.

The fix was to stop treating colours as identities and start treating them as positions in a space. Seed from the heaviest colours, reject seeds that are too close to an existing one, then assign every colour to its nearest seed using a weighted-RGB distance:

function dist(a, b) {
  const rm = (a[0] + b[0]) / 2;
  const dr = a[0] - b[0], dg = a[1] - b[1], db = a[2] - b[2];
  return Math.sqrt(
    (2 + rm / 256) * dr * dr +
    4 * dg * dg +
    (2 + (255 - rm) / 256) * db * db
  );
}

That weighting is a cheap approximation of human colour perception — green gets the heaviest coefficient because we discriminate green far better than blue.

Result: 3,122 colours collapsed to 18 layers covering 100% of paths. Hiding the top layer now removes 610 paths and you watch the background disappear.

One detail that mattered more than expected: when recolouring, don't flatten the layer to a single value. Store each path's original colour, compute its offset from the cluster centre, and re-apply that offset to the new colour. Otherwise every gradient and shadow in that layer turns into a flat blob.

I shipped a 26MB WASM model and had to rip it out

Small inputs trace badly, so I added an ONNX upscaling model to pre-enlarge them. Locally it was great.

In production, the WASM binary ran 13–26MB depending on the build, and on some machines its compilation — not inference, compilation — locked the main thread for minutes. On my machine, and in a clean browser profile, it was fine. That's the worst kind of bug: it only exists for other people.

I removed it entirely. The site went from 18MB to 1.4MB, and the quality difference on real inputs was smaller than I'd told myself it was.

If you're shipping a model to the browser, budget for compile time on cold, weak, extension-loaded machines — not just inference time on yours.

The architecture that made deleting 64 tools worth it

Everything runs client-side. VTracer (Rust) compiled to WebAssembly, executed in a Web Worker with OffscreenCanvas so the UI stays responsive during a multi-second trace.

That's not a purity thing, it's what makes the product viable:

No upload — files never leave the machine, which matters when the file is a client's unreleased logo
No rate limit — there's no server cost to ration, so there's no reason to cap anyone
Works offline after the page loads
No account, because there's nothing to store

One parameter tuning note, since it cost me real time to measure: colorPrecision at 8 produced 3,590 paths / 1,577KB. At 6 it produced 2,856 paths / 1,139KB — 28% smaller files and 32% faster, with output I genuinely could not tell apart on logos. Default it lower than you think.

The actual lesson

Shipping 65 things felt like 65 chances to win. It was really one diluted product with 65 half-maintained surfaces, no clear reason to return, and nothing anyone would describe to a friend.

The surviving tool is here if you want to break it: https://12pixa.com

Thin script fonts and scanned line drawings are where tracers fall apart — if you find a file it handles badly, I'd genuinely rather hear that than a compliment.