# Should you upscale before vectorizing?

Start with the original or a genuinely higher-resolution source. If a small trace loses gaps or dots, compare one enlarged copy too. Keep it only if the SVG improves: enlargement can also add stepped edges, unwanted contours and wrong colors.

Text of <https://pic2svg.com/upscale-before-vectorizing/>.

## A gap can return—and still be wrong

Every image below is shown on the same 384 × 384 canvas. Compare the white gap, the dot’s color and the navy corners. The first tile is the reference; the other four are actual SVG renders.

- **Reference artwork · 384 px:** The original artwork has a coral dot, a narrow white gap and rounded navy corners. It was drawn from original geometry, not enlarged from 96 px. [Reference PNG](https://pic2svg.com/examples/upscale-before-vectorizing/tiny_features/native-reference.png).
- **Trace: Original 96 px:** The gap and dot disappear. Rounded corners become angled corners. [Input PNG](https://pic2svg.com/examples/upscale-before-vectorizing/tiny_features/original_96/input.png) · [SVG](https://pic2svg.com/examples/upscale-before-vectorizing/tiny_features/original_96/output.svg) · [384 px render](https://pic2svg.com/examples/upscale-before-vectorizing/tiny_features/original_96/render384.png).
- **Trace: Nearest-neighbor 4×:** The gap and a dot return, but the dot is misshapen and blue-green. Outer edges show steps. [Input PNG](https://pic2svg.com/examples/upscale-before-vectorizing/tiny_features/nearest4x_384/input.png) · [SVG](https://pic2svg.com/examples/upscale-before-vectorizing/tiny_features/nearest4x_384/output.svg) · [384 px render](https://pic2svg.com/examples/upscale-before-vectorizing/tiny_features/nearest4x_384/render384.png).
- **Trace: Lanczos 4×:** The gap returns, but the dot is still the wrong color. Extra contours appear along the edges. [Input PNG](https://pic2svg.com/examples/upscale-before-vectorizing/tiny_features/lanczos4x_384/input.png) · [SVG](https://pic2svg.com/examples/upscale-before-vectorizing/tiny_features/lanczos4x_384/output.svg) · [384 px render](https://pic2svg.com/examples/upscale-before-vectorizing/tiny_features/lanczos4x_384/render384.png).
- **Trace: Native 384 px:** Corners are smoother and the gap survives. Even this trace changes the coral dot to blue-green. [Input PNG](https://pic2svg.com/examples/upscale-before-vectorizing/tiny_features/native_reference_384/input.png) · [SVG](https://pic2svg.com/examples/upscale-before-vectorizing/tiny_features/native_reference_384/output.svg) · [384 px render](https://pic2svg.com/examples/upscale-before-vectorizing/tiny_features/native_reference_384/render384.png).

## What the extra pixels cost

The 96 px original lost the sampled gap; both enlargements retained all 435 checked white pixels inside it. That did not restore the dot’s coral color. Paths count separate SVG path elements, including the background. Bytes are the downloadable SVG file size.

Source: <https://pic2svg.com/examples/upscale-before-vectorizing/results.json>

| Input | Paths | SVG bytes |
| --- | --- | --- |
| Original 96 px | 3 | 544 |
| Nearest-neighbor 4× | 5 | 2,021 |
| Lanczos 4× | 13 | 22,048 |
| Native 384 px | 5 | 3,197 |

## A simple logo may not benefit

We repeated the same four variants without the small dot and narrow gap. Enlarging this control added complexity without a clear improvement. It keeps the test from depending only on details that a small trace loses.

- **Reference artwork · 384 px:** The same two large shapes, with the small dot and narrow gap removed. This control does not favor recovering tiny details. [Reference PNG](https://pic2svg.com/examples/upscale-before-vectorizing/simple_control/native-reference.png).
- **Trace: Original 96 px:** Two large shapes, with no tiny dot or gap to recover. The rounded corners become angled corners. [Input PNG](https://pic2svg.com/examples/upscale-before-vectorizing/simple_control/original_96/input.png) · [SVG](https://pic2svg.com/examples/upscale-before-vectorizing/simple_control/original_96/output.svg) · [384 px render](https://pic2svg.com/examples/upscale-before-vectorizing/simple_control/original_96/render384.png).
- **Trace: Nearest-neighbor 4×:** The enlarged trace adds steps and more nodes. There is no clear visual improvement over the original here. [Input PNG](https://pic2svg.com/examples/upscale-before-vectorizing/simple_control/nearest4x_384/input.png) · [SVG](https://pic2svg.com/examples/upscale-before-vectorizing/simple_control/nearest4x_384/output.svg) · [384 px render](https://pic2svg.com/examples/upscale-before-vectorizing/simple_control/nearest4x_384/render384.png).
- **Trace: Lanczos 4×:** Extra edge contours make a much larger file. A larger input did not guarantee a cleaner result. [Input PNG](https://pic2svg.com/examples/upscale-before-vectorizing/simple_control/lanczos4x_384/input.png) · [SVG](https://pic2svg.com/examples/upscale-before-vectorizing/simple_control/lanczos4x_384/output.svg) · [384 px render](https://pic2svg.com/examples/upscale-before-vectorizing/simple_control/lanczos4x_384/render384.png).
- **Trace: Native 384 px:** A trace from the genuinely higher-resolution source. Compare the corners, not just the file size. [Input PNG](https://pic2svg.com/examples/upscale-before-vectorizing/simple_control/native_reference_384/input.png) · [SVG](https://pic2svg.com/examples/upscale-before-vectorizing/simple_control/native_reference_384/output.svg) · [384 px render](https://pic2svg.com/examples/upscale-before-vectorizing/simple_control/native_reference_384/render384.png).

## More pixels, more file

Without tiny details to recover, nearest-neighbor added nodes without improving the measured RGB error. Lanczos added edge contours and a much larger SVG. File size alone does not tell you which trace looks better.

Source: <https://pic2svg.com/examples/upscale-before-vectorizing/results.json>

| Input | Paths | SVG bytes |
| --- | --- | --- |
| Original 96 px | 3 | 544 |
| Nearest-neighbor 4× | 3 | 781 |
| Lanczos 4× | 11 | 20,947 |
| Native 384 px | 3 | 650 |

## What these examples do—and do not—show

- **A recovered shape can still be inaccurate:** The original small trace loses the dot. The other three return a dot, but none preserves its coral color—not even the trace of the native 384 px source. Check color and shape, not just whether something is present.
- **Automatic tracing changed too:** On the detailed example, the 96 px input used polygon tracing; all three larger inputs used spline tracing. On the simple control, only Lanczos switched to splines. The difference belongs to the whole pipeline; this test does not isolate resampling as its cause.
- **This is a local experiment:** These eight traces came from a local command-line run with the same settings. It bypassed the website’s browser preprocessing and hosted API. Two synthetic designs are not a representative sample of customer artwork. Hosted results may differ.
- **This was not an AI-upscaler test:** Nearest-neighbor and Lanczos resized existing pixels. The native reference was drawn from the original geometry. No AI upscaler was used or evaluated.

## Is ordinary resizing the same as AI upscaling?

No. [Ordinary resizing](https://docs.opencv.org/4.13.0/da/d54/group__imgproc__transform.html), including nearest-neighbor and Lanczos, calculates enlarged pixels from the existing image. [Learned restoration methods such as Real-ESRGAN](https://arxiv.org/abs/2107.10833) use a trained model instead.

- **Keep the evidence separate:** The comparisons here test only ordinary resizing, so they cannot establish whether an AI upscaler would improve your trace. If you test one, compare its traced output against trusted artwork for thin lines, gaps, shapes and colors; sharper appearance alone is not an acceptance test.

## A small comparison beats a fixed 4× rule

1. **Look for the original first:** Ask for the original vector or a genuinely higher-resolution export. An enlarged copy of the same small image is not that source.
2. **Trace the untouched image:** Keep it as your baseline. Check thin gaps, small marks, rounded corners and intended colors at the size you will use.
3. **Test one enlargement if a feature is missing:** Keep a separate copy and compare its SVG with the baseline. Our examples used 4× nearest-neighbor and 4× Lanczos; that is a test setup, not a recommended factor for every image.
4. **Keep the result that preserves the artwork:** Reject an apparent improvement if it changes colors, adds unwanted outlines or makes edges worse. If neither trace is usable, obtain a better source or redraw the affected parts. [Reducing SVG nodes](https://pic2svg.com/reduce-svg-nodes/) is a separate cleanup decision.

## How we made the comparison

- **Research date:** 30 October 2026
- **Environment:** The native artwork was drawn at 1536 px and reduced to 384 px for antialiasing. The small input was reduced to 96 px. Nearest-neighbor and Lanczos copies were enlarged from that 96 px input to 384 px. Each opaque PNG was traced locally with Balanced, automatic mode, a 600,000-pixel area limit, a 3072-pixel width limit and color precision 8. None reached the area or width limit.
- **Sample size:** Two self-authored synthetic designs; four inputs per design. Eight SVG traces, each rendered at 384 × 384 for comparison.
- **Tool versions:** Pillow 12.3.0; installed vtracer package 0.6.15; CairoSVG 2.9.1. Generated SVG comments say ‘visioncortex VTracer 0.6.12’. We retain that output metadata and report the installed package separately.
- **Metrics defined:** Paths: SVG path elements. Bytes: UTF-8 SVG size with LF line endings. The audit also records node counts, RGB error, foreground overlap and fixed dot/gap pixel checks. These diagnostics are not perceptual-quality rankings; inspect the pictures alongside them.
- **Not tested by this run:** Hosted uploads, browser preprocessing, AI upscalers, typical customer artwork, physical cutting and downstream design-software import behavior.
- **Known variance:** The automatic polygon/spline choice changes across some inputs, so the effects of interpolation and tracing mode are not separated. Different software versions or hosted preprocessing may change outputs.

## Download the evidence

- **Check the pictures and numbers:** The [audit ZIP](https://pic2svg.com/examples/upscale-before-vectorizing/upscale-before-vectorizing-audit.zip) contains both reference images, all eight input PNGs, generated SVGs, renders, [recorded results](https://pic2svg.com/examples/upscale-before-vectorizing/results.json) and a portable [audit script](https://pic2svg.com/examples/upscale-before-vectorizing/audit.py). Every figure above also links its individual files.
- **What the audit reproduces:** The [README](https://pic2svg.com/examples/upscale-before-vectorizing/README.md) explains how to regenerate the synthetic references, recount paths and bytes, recompute the saved-render measurements and optionally render the SVGs again. It audits the measured table; it does not reproduce the private tracing pipeline. No private engine source or original tracing logs are included.

## Start with your original image

- **Make your own comparison:** Use the [PNG to SVG converter](https://pic2svg.com/png-to-svg/) with your original first. Check its result before making an enlarged copy. The website’s output is not promised to match this local experiment. For preparing a logo source, see [logo to vector](https://pic2svg.com/logo-to-vector/).