Where a trained model beats arithmetic, and where it doesn’t

Every comparison you have read was written by somebody selling one of the two. Here is the version written by somebody who had to implement the losing side properly.

What each one actually is

A resampling kernel is a weighted average with a good set of weights. Lanczos 3 takes seven source pixels along each axis and combines them along a windowed sinc curve, which is the closest a finite filter gets to the ideal reconstruction of a sampled signal. It has no knowledge of photographs, faces, letters or bricks. It has a curve.

A trained upscaling network is a stack of convolutions whose weights were fitted by showing it millions of pairs — a sharp picture, and the same picture made small. It has learned what usually sits under a particular kind of blur. It has no curve. It has an enormous amount of experience and no idea whether it is right.

The kernel produces the best available description of the pixels you have. The network produces the most likely picture given the pixels you have. Those are different jobs, and almost every disagreement about upscaling is people comparing them as though they were the same one.

Where each one wins

The network wins on soft, ordinary, low-quality sources

A phone snapshot from 2012, a photo pulled off a social feed, a scan at 96 dots per inch — sources with real subject matter and very little recorded detail. Here a kernel can only spread what it has, and a network can supply texture that is consistent with what it sees. At 4× the difference is not subtle and it is not close. Anybody telling you otherwise is defending a position.

The kernel wins on anything with a right answer

Screenshots, diagrams, logos, scanned documents, technical photographs, and any picture where a person may later read something off it. A kernel enlarges a blurred word into a bigger blurred word, which is useless and honest. A network enlarges it into a sharp word, which is useful right up until the word is wrong.

It also wins on pixel art outright, where the correct enlargement is no interpolation at all, and on flat vector-ish artwork, where an edge-directed method keeps boundaries clean without inventing grain in the flat areas.

At 2× on a sharp source, it is close to a coin toss

This is the case the marketing never mentions. When the source is genuinely sharp and the factor is small, there is not much for a network to add: the neighbourhood around each new pixel is dense and informative, and a good kernel lands very near the right answer. We have not put a number on that gap. Both engines are on this site now, so you can run the comparison on your own picture in about ten seconds — but a figure we publish would have to come from an experiment we have not run, and one invented to sound rigorous is worth less than the admission.

Which to reach for, by what you are holding
Your source	Better served by	Why
Soft phone photo, 4×	A trained model	Nothing left to interpolate from
Sharp photo, 2×	Either	The gap is smaller than the file size
Screenshot or diagram	Edge-guided or nearest	A right answer exists and invention breaks it
Anything with small text	A kernel	A wrong sharp letter is worse than a blurred one
Pixel art	Nearest	The squares are the artwork

Where the model lives, and why it never loads by itself

It has its own route — /ai-upscale-image — and on every other tool page it is the Enhanced view, off until you choose it, rather than a fifth entry in the method list, because it is a different bargain rather than a fifth method. Two models run: ESPCN at 3×, 240,078 bytes, Apache-2.0; and Real-ESRGAN general x4 v3 at 4×, 4,866,396 bytes, BSD-3-Clause. Both are executed by a WebAssembly runtime of 13,986,063 bytes served from this domain, which is sixty times the smaller model and the figure most pages describing an in-browser model leave out.

The picture still does not travel. What travels is the model, in the other direction, once, after a press on a button that names the size — the same shape as the HEIC decoder this site has always fetched when somebody drops a photo straight off an iPhone. Loading it with the page would mean a visitor who wanted 4× of a screenshot paid fourteen megabytes for a prediction engine they had no use for, so nothing about it is fetched until that button is pressed.

A half-built model path would still be worse than none: an engine switch that downloads something, runs slowly, falls back silently and produces a result nobody can characterise is a button that makes a site look complete. So wherever it appears it discloses every byte before fetching one, keeps the smooth enlargement beside it at the same size, caps its input where the wait stops being reasonable, and gives you a control that deletes the weights again.

Getting the most out of the side we did ship

Use Lanczos as the default and step down to Mitchell the moment you see a bright rim along a dark-to-light boundary at 1:1. Use edge-guided when the picture is made of lines rather than texture, and expect it to take a few seconds longer for a result that looks identical on a photograph of a hedge. Run the clean-up pass before the enlargement on anything that has been through a messaging app, and keep it low.

And check at 1:1, always. Everything above about Lanczos, Mitchell, edge-guided and nearest is settled in about thirty seconds with your own picture and the 1:1 strip, which is rather the point of putting the loupe where it is. What is said about trained networks can be settled the same way now, on the same picture, on the AI upscaling page — and if your result disagrees with this guide, your result is the one with evidence behind it.

Back to the picture

Photographic visual for Model Vs Lanczos — Model Vs Lanczos