AI Line Art to Vector: A 39-Product Postmortem and Rejection-Proofing Playbook

Why AI-generated line art always fights you

When you generate line art with an AI image model, what you get is usually a 1024×1024 PNG bitmap with anti-aliased edges. And anti-aliasing is the natural enemy of clean vector tracing. What looks like a confident three-pixel-thick line in the preview is actually a band of grayscale pixels running from pure black to near-white.

Every tracing tool I've tried, including the default settings most people use, interprets that gradient as multiple nested paths. The result: a single thick stroke ends up traced as two or three hair-thin concentric outlines. You can't see it on screen at 100% zoom, but at print size—or when a reviewer zooms in to check—the problem is exposed immediately.

The first rejection email I got was from Adobe Stock, rejecting 11 line-art vector files in one go, all for the same reason: line weight doesn't match the preview. That batch took me six hours to produce. The rejection took about four minutes.

The most effective fix costs nothing: threshold the image before tracing. I convert to grayscale, then binarize around 128 so every pixel is either black or white. No gradient, no nested paths. This one step alone took my line-art rejection rate from most batches down to nearly zero.

Anti-aliasing is a smoothing technique that rendering engines deliberately introduce to reduce jagged edges: at shape boundaries, they blend foreground and background colors by coverage ratio, producing intermediate grayscale transition bands. This makes curves look more natural on screen, but it creates structural difficulties for vector tracing.

The fundamental difference between bitmaps and vectors is this: bitmaps record color on a pixel grid, so when you zoom in, the pixels scale up—and so do the edge gradient bands, becoming visible blur. Vectors describe shapes with mathematical paths and scale infinitely. Tracing algorithms try to reverse-engineer mathematical paths from bitmap pixels. When they hit the grayscale gradients created by anti-aliasing, the common approach is to extract contours by iso-value—different grayscale thresholds cut contours at different positions. So a thick line with a gradient gets read as multiple layers of nested paths.

Thresholding is exactly the targeted preprocessing for this: force all pixels into one of two classes, pure black or pure white, eliminating intermediate grays so the tracing algorithm faces only one unambiguous boundary and outputs a single, clean path. A threshold of 128 is a common starting point because it's the midpoint of the 8-bit grayscale range (0–255).

Resolution matters more than tracing parameters

The second mistake I made was tracing directly from 1024-pixel output. Convert a 1024-pixel image to vector and any curve shows obvious corner artifacts. What I do now is upsample to 2048 pixels first, then binarize—this smooths the jaggies without inventing detail the model never drew. Beyond 2048 pixels I see no further improvement, just longer tracing time.

On a 1-core CPU, 2GB RAM server, this matters. Upsampling and tracing a 2048-pixel image peaks at roughly 400–600MB of memory depending on path count. That just fits. Two in parallel does not fit—the OOM Killer randomly kills one of the processes. So the pipeline processes one image at a time, calls gc.collect() after each asset, and monitors the real memory ceiling via resource.getrusage(RUSAGE_SELF).ru_maxrss rather than guessing. Heavy rendering steps run in a separate subprocess per file, ensuring memory is actually returned to the OS.

Upsampling means increasing image pixel resolution through interpolation—for example, from 1024 pixels to 2048 pixels. It doesn't create new real detail, but it changes how the pixel grid aligns with curve boundaries, so the originally coarse jaggies get resampled into smoother transitions at higher density, making it easier for the tracing algorithm to fit continuous curves rather than polylines.

The OOM Killer is the Linux kernel's out-of-memory protection mechanism: when physical memory and swap space are exhausted, the kernel selects and force-kills a process based on oom_score to save the system. Which process it kills is somewhat random, so "two parallel tasks just barely blow out memory" leads to unpredictable production interruptions.

ru_maxrss is the peak resident set size field returned by resource.getrusage(RUSAGE_SELF), in KB on Linux. Using it to monitor process peak memory is more reliable than watching instantaneous values in top, which miss short spikes. Python's gc.collect() can only reclaim circular reference objects and return memory to the allocator—the OS doesn't necessarily reclaim it immediately. That's why heavy steps go in separate subprocesses: only when the process exits does the OS fully reclaim the memory.

Stroke width is a deliberate decision, not an accident

After tracing, you have paths—but stroke width depends entirely on what the tracing algorithm outputs. Reviewers compare the vector against the preview one by one: if the preview shows a bold three-pixel stroke and the vector renders as a hairline, that's a mismatch and an instant rejection. The reverse is also true—vector too thick while the preview is too thin, also rejected.

So I made stroke weight an explicit parameter per product line. One weight for the floral series, another for the mandala series, consistent across every file in a series. I set strokes by points in the post-trace SVG, and render the preview from that same SVG. Preview and product come from the same source of truth. Before that, I rendered previews from the original PNG but submitted vectors with different weights—which is exactly the failure mode described in that rejection email.

Another rule I learned the hard way: expand strokes before export. Adobe and Vecteezy handle stroked paths differently, depending on how their preview pipelines rasterize. Once expanded to outlines, the render is identical on any platform. Files get bigger—my SVGs went from about 40KB to 90KB on average—but none of the expanded files were rejected for rendering differences.

Stroke vs. Outline are two different ways of representing vector graphics: a stroke is a line of some width applied along a path's centerline, with width independent of path geometry; an outline (also called expanded stroke) converts that width into a filled path, freezing the geometric boundary into an actual shape.

The difference is rendering consistency. The final appearance of a stroked path is decided by the rendering engine—different butt caps, round joins, miter limits, even half-pixel rasterization rules can cause the same stroke to appear with different widths or endpoint shapes on different platforms. When a platform's preview pipeline differs from the author's export environment, the reviewer's rendered result may not match the preview.

Once expanded to outlines, line width becomes part of the geometry, and any engine rendering the same filled path gets the same result. The cost is more path nodes and larger file size, because the boundary on each side of the stroke must be explicitly recorded—which explains the SVG bloating from about 40KB to about 90KB.

Metadata and upload ledger

Getting vector files accepted is only half the work; the other half is not dropping the ball during upload. All three channels I use will instantly reject a bad CSV header: Adobe wants 5 columns, Vecteezy wants 4, Dreamstime wants 15. I wrote make_metadata.py to generate the right header format directly from the folder's file listing, so I never again waste upload attempts on format errors.

The more dangerous failure source is me. Duplicate submission of a batch is the fastest way to get your account flagged, and running a re-run script on a groggy morning is far too easy. upload_tracker.py is a plain ledger that records what I've already published. On re-run it automatically skips completed items instead of re-uploading. It's a boring tool, but its contribution to protecting my account may be bigger than all the tracing fixes combined.

Stock platforms enforce strict CSV metadata header validation because upload systems typically parse by column index, not column name. Adobe Stock requires 5 columns (e.g., Filename, Title, Keywords), Vecteezy requires 4, and Dreamstime requires 15 in a fixed order. Once column names, count, or order don't match, the entire batch is instantly rejected—often without a detailed error—and all it consumes is your upload quota.

An upload tracker is an idempotency design: by persistently recording successfully published content (usually keyed by file hash or product ID), it lets re-run scripts skip completed items and process only the delta. It solves the classic "at-least-once" vs. "exactly-once" problem in distributed submission—network timeouts or manual retries can cause duplicate submissions, and stock platforms typically treat duplicates as spam behavior and trigger account risk controls.

md2pdf involves a Markdown-to-PDF conversion pipeline, commonly implemented by first parsing Markdown into HTML, then rendering to PDF via a headless browser or layout engine (such as WeasyPrint), so documents can be packaged as sellable digital products.

Data and tooling takeaways

39 finished products, about 856MB of packaged output, the tracing step down to roughly two minutes per image on the same 1-core CPU machine, single process, no GPU. The line-art batch rejection rate dropped from mostly rejected to just a few per hundred files. The master pipeline behind all this is about 19,000 lines of Python code, and the rules mentioned in this article are all enforced at the code level—not something I keep in my head.

The whole system runs on Python 3.9 with only two third-party packages total. No cloud accounts, no GPU, no frameworks.

I never intended to write a toolkit. I just wanted to ship 39 products, and these scripts are what's left over: make_metadata.py handles three CSV formats, upload_tracker.py handles the ledger, md2pdf.py converts documents into sellable PDFs, and pack_product.py packages files with a 1280×720 cover and 600×600 thumbnail. They're the tools I still use today.