Invented, not recovered
An arithmetic enlarger answers a narrow question: given these pixels, what belongs between them? A trained upscaler answers a much broader one: given millions of photographs and this small blurry patch, what did the world probably look like there? The second question produces a sharper picture. It also produces an answer even when there is nothing to answer from.
Super-resolution invents plausible detail. It does not recover detail that was never captured, and nothing ever will. A brick wall comes back with bricks because brick walls have bricks, not because your file remembered them.
That is not a reason to avoid it. Most of the time the invented version is closer to what the scene looked like than a blur is, and for a photograph you are going to look at rather than read, it is the better picture. It is a reason to know which of the two you are holding, which is why the third card on this page runs the arithmetic path at the same factor and the compare control holds the plain stretch underneath both.
We have not measured the gap between the two engines and we do not publish a figure for it. There is no PSNR number on this page, no percentage, and no claim about how much sharper anything is. A number invented to sound rigorous is worth less than the admission that nobody here has run the experiment.
The two models, with the numbers that were measured
Both are small by the standards of this field, both have a licence that permits commercial use, and both were timed in a real browser on single-threaded WebAssembly — which is the slowest path and therefore the one worth quoting. Neither figure comes from a model card.
| Fast enlarge | Detail enlarge | |
|---|---|---|
| Architecture | ESPCN, sub-pixel CNN | Real-ESRGAN general x4 v3 |
| Magnification | 3×, fixed | 4×, fixed |
| Weights | 240,078 bytes | 4,866,396 bytes |
| Licence | Apache-2.0 | BSD-3-Clause |
| One pass, WASM | 230 ms | 1,200 ms |
| Works on | Brightness only | All three channels |
| Tile handed to it | 224 px, and it cannot be changed | 128 px, to bound memory |
The fast one only enlarges brightness. Its graph takes one channel and returns one channel, because that is what it was trained on, and the two colour-difference channels are enlarged by ordinary interpolation alongside it. That sounds like a shortcut and is not: the eye takes almost all of its detail from luminance, which is the same reason JPEG has been throwing away colour resolution since 1992.
The detail one is the model people mean when they say AI upscaling. It runs on all three channels, it is nineteen times the download, and its measured pass is five times longer. On a soft, small, ordinary snapshot the difference is obvious. On a picture that was already sharp it is much less obvious, and it costs you a wait either way.
Neither model can be talked into a different factor. Each one magnifies by exactly the amount it was trained to magnify by; a control that offered 2× or 8× here would be a resample wearing a model’s name, which is precisely the thing this site exists to refuse. For other factors, use the arithmetic pages.
What the download actually is
The weights are the small part. The thing that executes them — 13,961,845 bytes of WebAssembly plus a 24,218-byte loader, 13.3 MB together — is sixty times the size of the fast model, and any page that discloses only the model size is telling you a true number that leaves out most of the cost.
| What arrives | From | Bytes |
|---|---|---|
| WebAssembly runtime | this domain | 13,961,845 |
| Runtime loader | this domain | 24,218 |
| Fast enlarge weights | cdn.pictureeditor.com | 240,078 |
| Detail enlarge weights | cdn.pictureeditor.com | 4,866,396 |
None of it is fetched when you open this page. It is fetched when you press a button that names the size, and it is kept in this browser’s cache afterwards under a versioned key, so the second visit starts instantly and works offline. The control that deletes those files again sits next to the tool, because something that quietly wrote to your disk deserves an undo.
The runtime is served from this domain rather than from a content network, which keeps the number of other places this site talks to at exactly one: the weights come from cdn.pictureeditor.com and nothing else does. That is a request for a file, not a report about you — the same bytes go to everyone who asks, and it carries nothing about the picture you opened. The privacy page says so in those words.
Where it falls down
- Text comes back sharp and wrong.A network trained on photographs will render a blurred word as a crisp word, and it has no way to know which word. A kernel enlarges a blurred word into a bigger blurred word. If anyone is going to read something off the result, the honest blur is the right answer and the sharp invention is the dangerous one.
- Small faces become somebody else.Give either model a face forty pixels across and it will return a plausible person. The eyes will be well-formed, the skin will have pores, and none of it corresponds to the human being who was standing there. This is not a bug being worked on; it is what the technique is.
- It is slow, and the cap says how slow.The picture is cut into tiles and each tile is a separate pass through the network. The detail model's measured pass is 1,200 ms, so a picture of any size is a wait you can watch tick past on the progress line. The input cap here is function(){throw Error("Attempted to call MODEL_MAX_INPUT_PIXELS() from the server but MODEL_MAX_INPUT_PIXELS is on the client. It's not possible to invoke a client function from the server, it can only be rendered as a Component or passed to props of a Client Component.")} pixels for that reason and no other.
- It is not a repair tool and not a sharpener.Scratches, dust, motion blur and out-of-focus are different problems with different answers, and a super-resolver pointed at them will enlarge the damage along with everything else. Making the picture bigger is the only job on this page.
When to use the arithmetic instead
More often than the marketing for either technique suggests. Pixel art, screenshots, diagrams, logos and anything with lettering all have a correct enlargement, and invention breaks it. A source that is already sharp at 2× has enough information in it that a good kernel lands close to the right answer. And a large photograph is simply not going through the model path at all, because of the cap.
The third card on the tool above runs Lanczos 3 at the same factor as the model beside it, so the comparison takes about ten seconds with your own picture and the hold-to- compare control. That is the only comparison worth trusting, because it is yours.
- EnlargePicturePick 2×, 4× or 8× and watch the result at 1:1 before you save a thing.
- Double the sizeThe factor with the least to apologise for. Opens at 2× on a sharp source.
- Four times overThe usual answer when a picture is close but not close enough. Opens at 4×.
- Where a trained model beats arithmetic, and where it doesn'tThe case for the classical path, made fairly, including the cases it loses.
- What enlarging can and cannot get backWorked through at 2×, 4× and 8×, with the part that is a guess named as one.
The questions we get
- Does AI upscaling actually recover lost detail?
- No, and the distinction is the whole thing. A trained upscaler has never seen your photograph. What it has seen is millions of others, and from that it produces detail that is plausible where your file has none. On a soft snapshot that is usually a better-looking picture than any amount of arithmetic can give you. It is not the detail your camera failed to record, it cannot be checked against anything, and on small text or a distant face it will confidently produce the wrong letters and a person who does not exist.
- Is my picture uploaded to a server?
- It is not. The traffic runs the other way: the model file comes down to your browser from the network's own store, once, and the arithmetic happens on your own processor. Nothing about the picture is in that request — the same bytes are sent to every visitor who asks for that model, whatever they are enlarging. There is no account, no queue and nothing on our side that ever holds a file.
- Which of the two should I pick?
- Start with the fast one. It is 240,078 bytes, enlarges by 3×, and works only on brightness — which is where nearly all the detail the eye notices lives — so it is quick and it rarely does anything alarming to colour. Move to the detail model when the fast one leaves the result mushy and you are willing to wait: it is nineteen times the download, works on all three channels at 4×, and its measured figure is 1,200 ms for a single pass against 230 ms.
- Why is there a size limit on this page and not on the rest of the site?
- Because the models are slow and honest about it. A picture goes through the network in tiles, and the detail model's measured time is 1,200 ms for each one, so a large photograph would be several minutes of a browser tab doing arithmetic. The cap is 640,000 source pixels — about 900 by 700. The arithmetic enlarger on every other page has no such limit, because a kernel is thousands of times faster than a network.
- What does it cost to download, exactly?
- Three numbers, and all three are on screen before anything is fetched. The runtime that executes either model is 13,961,845 bytes of WebAssembly plus a 24,218-byte loader, served from this domain. The fast model is 240,078 bytes and the detail model is 4,866,396 bytes, served from cdn.pictureeditor.com. All of it is kept in your browser's cache afterwards, so a second visit downloads nothing, and there is a button on the page that deletes the model files again.
- Can I use the result as evidence?
- No. Every pixel either model adds is a guess that looks like a fact, which is the most dangerous property a picture can have. If the question is what a number plate said, who that was, or what the sign read, a sharper enlargement is a more convincing wrong answer, not a better one. Use the arithmetic path for anything somebody may later read something off: it produces a bigger blur, which is useless and honest.