Why four hundred large files will not finish
This is the arithmetic behind the refusal, written out in full, because a limit that is asserted is an excuse and a limit that is calculated is a fact.
One photograph, counted
Take a 4,000 × 3,000 photograph — twelve megapixels, which is what a phone from five years ago produces and what a modern one produces on its default setting.
Step one: the stride
Real-ESRGAN is handed a 128-pixel square at a time, with 8 pixels of context carried on every side so the convolutions near a tile boundary see real neighbouring pixels rather than the edge of a buffer. The part of each tile that is actually kept is therefore 128 − 16 = 112 pixels square. That is the stride.
Step two: the count
Across: ceil(4000 ÷ 112) = 36. Down: ceil(3000 ÷ 112) = 27. Multiply: 972 passes for one photograph.
Step three: the clock
One pass of that network measures 1,200 milliseconds on single-threaded WebAssembly. 972 × 1.2 is 1,166 seconds: nineteen and a half minutes, for one file.
Step four: the folder
Four hundred of them is 466,560 seconds. That is 129 hours 36 minutes — five and a half days of a tab that must stay open, on a laptop that must stay awake, on a battery that will not.
Where the wall actually is
| Source | Passes a file | Seconds a file | Four hundred files |
|---|---|---|---|
| 400 × 400 | 16 | 19 | 2 h 8 min |
| 600 × 600 | 36 | 43 | 4 h 48 min |
| 1,000 × 1,000 | 81 | 97 | 10 h 48 min |
| 2,000 × 1,500 | 252 | 302 | 33 h 36 min |
| 4,000 × 3,000 | 972 | 1,166 | 129 h 36 min |
The published envelope draws its Real-ESRGAN line at 600 pixels and fifty files for exactly this reason, and that is already a warned band rather than a comfortable one. Everything below the second row of that table is a job somebody would abandon.
What a graphics card changes
Everything, and it is worth being specific rather than gesturing at it. The passes above are dense convolutions over small tensors, which is the workload a GPU exists for: a mid-range consumer card runs the same network somewhere between fifty and two hundred times faster than one WebAssembly thread, and it does several tiles at once. The five-and-a-half-day job becomes an hour or two.
None of that is available here today. WebGPU would close part of the gap, but the runtime build that carries it is larger than this host serves as one file. Pages here are now cross-origin isolated where the browser supports it, so the runtime may use up to four CPU threads; that helps on a many-core laptop and changes nothing about the order of magnitude above. The figures this site publishes stay the single-thread ones until a multi-thread figure has been measured, and the queue times your own machine before it starts either way.
- There is no GPU in this path, and no setting anywhere on this domain turns one on. CPU threads are capped at four.
- The refusal is set at four hours for a queue and five minutes for a file. Those are policy lines rather than limits of the machine, and they are set so a refused job is obviously refused rather than marginally so.
- A refused file is not dropped. It goes through Lanczos3, finishes in well under half a second, and appears in the archive with everything else.
Questions this raises
Would a faster laptop fix this?
Would splitting the folder into ten queues fix it?
So what is the honest advice?
Next
- Runs, warns, refusedThree bands, two thresholds, the halved iOS envelope and the arithmetic floor beneath all of it.
- Small sources, better resultsWhy a 500 px source beats a 4,000 px one on both quality and wall-clock time.
- Where the minutes come fromTile geometry read off both graphs, the per-pass figures, and the calibration that replaces them.
- Photos upscalerUpscale one photo in the review studio, or a whole folder in the queue, on this device.