A folder in, an archive out

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.

1. 1Enumerate. 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.
2. 2Settle one rule. A factor, an engine, an output format and a two-token naming pattern. That is the whole configuration, and it applies to every file in the set.
3. 3Calibrate. 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.
4. 4Run. 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.
5. 5Take the archive. Outputs are written into the ZIP as they are encoded, and the run report names every file that failed and why.

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 no second thread. 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.
• There is no preview, no comparison view and no per-image control. Five hundred per-file decisions is not a feature, it is a second product.

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?

The settings, the file list, each file's state and the measurement are kept, so picking the run up again does not re-measure your processor. No picture data is kept at all — not a source byte and not a finished output — so your browser asks for the folder again and the files that had already finished are done a second time. Staging outputs to disk so a resumed run keeps them is the next thing this needs, and until it exists this page says so rather than implying otherwise.

Is anything uploaded?

One request leaves this device and it is for a model file, from cdn.pictureeditor.com, only after you press the control that prints its byte count. Nothing else does: there is no server behind this domain, no API route, and nowhere for a pixel buffer to be sent even by accident.

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.