Reducing in One Jump Skips Detail That Stepping Averages

How it works

This page runs the browser-side resizer set up for folder work. Each file is decoded on your device, drawn into a canvas at the requested size, and encoded back out. The results are collected into a zip.

Reductions are done in steps. Rather than drawing a 6000-pixel image straight into a 600-pixel canvas, it halves repeatedly until one more halving would overshoot, then makes the final adjustment. Each halving averages four pixels into one, so nothing is skipped on the way down.

A failure on one file does not abort the batch. Forty holiday photographs containing one file the browser cannot decode produce thirty-nine results and one clear message.

Aliasing, in one paragraph

The reason a single-step reduction misbehaves is the same reason a scanned magazine page produces moiré.

Reducing an image means sampling it on a coarser grid. Detail finer than that grid cannot be represented, and rather than politely disappearing, it folds down into a lower frequency — which appears as a pattern that was not in the original. A striped shirt is the classic case, because its stripes are regular and fine, and the false pattern that appears is large and obvious.

Averaging before sampling removes the detail that would have folded. That is what each halving step does, and it is why the stepped result looks correct where the single jump looks strange.

Choosing the constraint

For a batch, the constraint you pick matters more than the number.

A maximum width suits web publishing, where the layout column has a width and the height can be whatever the photograph is.

A fit box suits mixed orientations, because both portrait and landscape images end up with their longest side at the limit and neither is cropped.

A percentage suits a set that is already consistent and simply needs to be smaller.

A fixed width and height together suits only a set whose proportions already match. Applied to a mixed folder it either distorts or crops every file whose shape differs, and which of those it does is the difference between a bad batch and a very bad one.

Order of operations

Where resizing sits in a workflow decides how much quality survives it.

Edit first, at full resolution. Retouching, color, and cropping all have more information to work with before the reduction.

Resize second, to the size the destination actually needs.

Compress third, because compression quality is judged against the final pixel dimensions — a quality setting that looks fine at 6000 pixels is often wasteful at 1200.

Rename last, or at any point, since it does not touch the pixels at all.

Doing it in that order means every step operates on the best available input, and the only irreversible loss happens once.

What has been tested

The resizer this page uses is already in production, and it was exercised directly before this page went up.

Two files at once — a 2400×1600 JPEG and a 1200×1800 one — produced per-file results and a single zip. In width mode at 1200, the first came back 1200×800, 87 percent smaller, with its proportions intact. The second was left at 1200×1800 because "Never enlarge" is ticked by default and it was already at the target width, which is the correct behavior rather than a failure.

All six modes named in this page exist in the tool: width, height, fit inside box, fill box with a crop, percentage, and exact size with distortion.

Still to check on a later pass: a batch containing a finely striped subject inspected at full size for aliasing, and a batch large enough to stress the zip.