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
| Source long edge | Passes a file | At the published 230 ms | Two hundred files |
|---|---|---|---|
| 500 px | 9 | 2.1 s | about 7 minutes |
| 800 px | 16 | 3.7 s | about 12 minutes |
| 1,200 px | 36 | 8.3 s | about 28 minutes |
| 1,500 px | 64 | 14.7 s | about 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
- Two hundred supplier thumbnailsFactor, format, naming and the expectation to set before a twenty-minute queue starts.
- Listing minimumsWhat five marketplaces require in pixels, and the same queue set to clear it.
- 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.