What this queue is for
Three photographs enlarged by hand is not a problem. Eighty is a different problem, and it is the one this page is built around: a directory of supplier thumbnails, a shoebox of scans, a folder of screenshots that all need to clear the same minimum, with one setting applied to every one of them and no decision to make per file.
The thing that makes it usable is not the model. It is the number the page prints before the first file is touched. Super resolution in a browser tab is arithmetic that does not scale, and a queue built on it either says how long it will take or it is a trap. So the tool measures the chosen network on your own processor — real tiles cut from your own photographs, timed a moment ago — and quotes a range before it will start.
Running a folder
- Enumerate. Drop a directory or select files. Entries stream into the list as the walk proceeds, non-pictures are counted and dismissed on one line, and anything past this browser's bitmap ceiling is excluded here rather than discovered at file 300.
- Settle one rule. State what every picture has to clear — a pixel floor, a print size at a DPI, or a megapixel count — then an output format and a two-token naming pattern. That is the whole configuration. The factor is not one of the fields and neither is the graph: the first is solved per file from its own dimensions, the second is chosen from the shape of the set and named on screen with the reason it was chosen.
- Calibrate. Press the control that names the byte count. The model comes down once, eight real tiles from three of your files are timed, and the median becomes the estimate.
- Run. One worker, one session, one file at a time. Pause lands on the next tile boundary rather than the next file, so pausing a long photograph still takes under two seconds.
- Take the archive. Each output is kept on this device as its file finishes, and the ZIP is assembled from those kept files at the end. The run report names every file that failed and why, and every file that came back soft — measured on its own pixels rather than inferred from the factor it took, because clearing a pixel floor and carrying detail are two different things.
What it opens, what it refuses
Decoding covers JPG, PNG, WebP, AVIF, GIF, BMP, TIFF and ICO natively, with the HEIC codec fetched on the first HEIC magic number in a set and reused for the rest of it. Orientation is settled once per browser by a two-pixel probe decode, which is what stops half the photographs in a folder arriving on their side.
- There is no GPU in this path, and model passes use up to four CPU threads where the browser isolates the page (one where it cannot, as in Safari). A desktop application with CUDA behind it will beat this by two orders of magnitude, and on twelve-megapixel photographs it is the only sensible answer.
- Animated GIF and WebP are refused per file with the reason logged. Keeping the first frame of an animation and calling it done is not a behaviour this queue has.
- Alpha never reaches either network. It is enlarged arithmetically and recombined, which is what stops a cutout acquiring a halo.
- Nothing here shrinks a picture. This queue only enlarges, and the factor control has no value below one.
- The queue has no preview and no per-image control: five hundred per-file decisions is not a feature. A single photograph opens the review studio instead, with Split, Before and a 100% loupe, and that is where per-image judgement lives.
- A soft source is named, not fixed. Nothing here can put back detail a file never had, and a row that measures as soft is a row telling you to replace the original rather than enlarge it.
| Band | Condition | What happens |
|---|---|---|
| Runs | ESPCN, long edge ≤ 1,500 px, up to 500 files | Starts once the estimate is accepted |
| Warns | ESPCN to 2,400 px, or Real-ESRGAN at ≤ 600 px and ≤ 50 files | Estimate in red, second confirmation |
| Refused | Any file over 5 minutes, or a queue over 4 hours | Excluded by name; Lanczos3 finishes it instead |
Asked mid-run
How many files can one queue hold?
Five hundred, on a desktop browser, with every source under 1,500 pixels on its long edge. Past that edge the estimate turns red and asks a second time; past the published envelope the model path is refused and the arithmetic one takes the set. On an iPhone or iPad every number in that sentence halves, and five hundred is not offered at all.
Why does the factor not change the estimate?
Because neither network takes a factor. ESPCN magnifies by three and Real-ESRGAN by four, and both work on a tile of the source, so the number of passes depends on how big your originals are and not on how big you asked the results to be. The factor is applied to the network's output afterwards, arithmetically, which costs a fraction of a second a file.
What happens to a file that fails halfway?
It gets one retry, and the shape of that retry depends on the engine. Real-ESRGAN's input dimensions are free, so the file is tried again at half the tile edge, which is the fix for an allocation failure on a large photograph. ESPCN hard-codes its input size, so halving is not available and the retry runs on the arithmetic path instead. A second failure marks the file with its reason and the queue moves on; the end screen then offers a queue built from the failed set alone.
Can I close the tab and come back?
Yes. As each file finishes, its output is written to this browser's private file system on this device, and the settings, the file list and the measurement are kept beside it. Come back, grant the folder again, and only the files without a kept output run — matched by path, size and dimensions, so a file that changed in the meantime is done again rather than reused. Your source photographs are never stored, which is why the folder has to be granted again. Where a browser offers no private file system, the run works in memory and says so.
How do I know which files came back usable?
Each row says so, and it is measured rather than deduced from the factor. After a file is worked, the sharpest windows in its source are halved and put back: if putting them back changes almost nothing, the source was carrying nothing at that level and its real detail is coarser than its pixel count suggests. The output is then weighed against the same source interpolated to the same size, which is the definition of bigger pixels, so anything measurably above that line is detail the engine added. A crisp 400 px scan at 4x and a soft 1,200 px JPEG at 1.33x both clear a 1,600 px floor and only one of them is a usable listing image — the row with the smaller factor is the bad one, and the run report names it with the pixel width of the detail actually in it.
What does the review studio's risk reading measure?
It compares the result with the same photograph enlarged by Lanczos3 to the same size — bigger pixels and nothing else — in 16-pixel cells. Sharpening what the source already had roughly doubles a cell's edge energy; a network growing texture the source never had goes well past that, fastest where the source was flat. Cells past that line are lit on the risk map, the strongest are numbered, and N sends the loupe to each in turn. It flags where to look; it cannot know whether a leaf or a pore the model drew was really there.
Is anything uploaded?
Requests leave this device only for model files, from our model file server, and each only after you press the control that prints its size: the upscaler the run needs and, if you ask the review studio to find faces, a 229,738-byte detector. Every file is checked against its SHA-256 before it runs. Nothing else leaves: there is no server behind this domain, no API route, and nowhere for a pixel buffer to be sent even by accident.
Reference: the numbers
Two pages carry the arithmetic rather than a tooltip, because a refusal needs somewhere to point and a minute count needs to be checkable.
- Where the minutes come fromTile geometry read off both graphs, the per-pass figures, and the calibration that replaces them.
- Runs, warns, refusedThree bands, two thresholds, the halved iOS envelope and the arithmetic floor beneath all of it.
- Catalogue intakeSupplier thumbnails against a marketplace floor: opens at 2×, WebP out, named for a shop.
- Three long answersA catalogue worked end to end, the calculation that refuses a job, and why small sources win.