PhotosUpscalerA PictureEditor.com tool

A supplier folder, sized for a shop

Every pass runs on this machine; only the model travels.

Small inputs are the case a browser can actually finish, and product photography is the one that arrives small: 500-pixel supplier files, a marketplace floor of a thousand, and one setting for the lot.

Drop the supplier folder, or select the files.

One photograph, not a folder? enlargepicture.com does that one properly, with the comparison view this queue has deliberately no room for.

Model weights come from cdn.pictureeditor.com only when you press the control that names their size. Everything else — the runtime, the decoding, the inference, the archive — is served from this domain and executed here.

What this queue is for

A seller with two hundred supplier thumbnails at 500 pixels and a marketplace that will not list anything under a thousand has a problem that is measured in files rather than in quality. Every input is small, which is the case a WebAssembly upscaler can genuinely finish — the demand and the capability agree here, which they rarely do.

So this entry is the same queue with three decisions already made: 2× because it clears the common floor exactly, WebP because a shop front pays for page weight, and the factor appended to every filename because a folder containing both versions of every SKU is a folder somebody uploads the wrong half of.

Running a folder

Two hundred files, measured against the figure this site publishes
Source long edgePasses a fileAt the published 230 msTwo hundred files
500 px92.1 sabout 7 minutes
800 px163.7 sabout 12 minutes
1,200 px368.3 sabout 28 minutes
1,500 px6414.7 sabout 49 minutes

Those are the published figures, not your figures. The tool measures the same network on your own processor before it starts and replaces every number above with what it actually saw — a five-year-old laptop and a current desktop are a factor of four apart, and a table on a web page cannot know which one you are sitting at.

What it opens, what it refuses

  • A supplier who sent you 4,000-pixel photographs has given you a different job. Those are excluded from the model pass by name and enlarged arithmetically instead, which finishes them in well under half a second each.
  • There is no per-image control here and there will not be one. A catalogue that needs two hundred individual decisions is not a catalogue job.
  • Nothing on this domain crops, pads or changes an aspect ratio to fit a listing template. This queue changes one number about a photograph and that number is its size.
  • Upscaling does not rescue a photograph that was soft to begin with. It makes a small sharp picture into a larger sharp picture, and a small blurry one into a larger blurry one.

Asked mid-run

Why does this entry open at 2× rather than 4×?
Because a 500-pixel supplier thumbnail at 2× clears a 1,000-pixel shop minimum exactly, and every step past the minimum costs wall-clock time without buying a listing anything. A catalogue is a throughput problem before it is a quality problem.
Why WebP by default here and not on the front page?
A shop front pays for every kilobyte in page weight, and WebP at quality 82 is roughly a third the size of the equivalent JPEG at a difference nobody reports. If your platform will not take WebP — a few older marketplace importers still will not — switch the format control to JPEG before you start.
Can I keep the supplier's filenames?
Set the pattern to {name} alone and the outputs keep the stems they arrived with. The default appends the factor because a folder holding both the original and the enlarged version of every SKU is a folder somebody eventually uploads the wrong half of.
What if two suppliers both sent me 1.jpg?
The second one is written with a numeric suffix and the run report names it. Overwriting silently inside an archive is the failure mode that loses a photograph without anybody noticing until the listing is live.

Reference: the numbers