Nearest, bicubic, Lanczos: what the resize dialogue is computing

A resize is a question about pixels that do not exist

Reduce a 4000-pixel image to 1600 and you are asking for a new grid whose samples fall between the old ones. Nothing in the file sits at the new positions. The algorithm decides what each new pixel should be, and the different algorithms are different answers to that question.

The dropdown in the resize dialogue is not decoration. On a photograph the difference is small; on a striped shirt, a wire fence, a mask or a screenshot it decides whether the result is usable.

The five you will meet

• Nearest neighbour copies the value of the closest old pixel. No averaging, no new values. It produces hard blocks when enlarging and drops information brutally when reducing. It is correct for exactly two jobs: pixel art, where the blocks are the point, and index maps: a mask where 1 means sleeve and 2 means collar and an averaged value of 1.5 would be meaningless.
• Bilinear takes the weighted average of the four surrounding pixels. Cheap, soft, and never produces a value outside the range it started from.
• Bicubic uses sixteen pixels and fits a cubic curve through them. The curve overshoots slightly at an edge, which reads as mild sharpening. Photoshop’s Bicubic Smoother and Bicubic Sharper are the same algorithm with the overshoot dialled down for enlargement and up for reduction.
• Lanczos is a windowed sinc function, usually over 36 or 64 samples. It is the sharpest of the classical filters and it rings: a bright rim on the light side of a hard edge and a dark rim on the dark side, exactly the shape of an over-sharpening halo. On photographs this is usually welcome. On a logo against flat colour it is a defect.
• Model-based enlargement (Photoshop’s Preserve Details 2.0, the upscalers in module seven) does not interpolate. It predicts. That is a different operation with a different honesty problem, and it is covered there.

Reducing is where the damage happens

Most people worry about enlarging. Reducing is where images are quietly ruined.

A photograph of a striped shirt contains detail finer than the grid you are reducing to. If the algorithm samples the nearest pixel, those stripes land on the new grid at a beat frequency and you get moiré: broad wavy bands of colour that were never in the scene. The same thing produces the shimmering brickwork in a downscaled architectural shot.

The fix is a low-pass filter: average a wide enough neighbourhood that detail too fine to survive is removed before it can alias. That is what a proper resize filter does and what point sampling does not. In ImageMagick the distinction is explicit:

magick in.jpg -sample 1600x out-bad.jpg    # point sampling, will alias
magick in.jpg -filter Lanczos -resize 1600x out-good.jpg

-thumbnail is -resize with the metadata stripped and a fast pre-reduction for very large files; it is fine for contact sheets and slightly less careful for delivery.

The gamma mistake almost every tool makes

This one is worth the lesson on its own, because it is invisible until you know the pattern, and then you see it constantly.

The numbers in an sRGB file are gamma-encoded: roughly the 1/2.2 power of the light they represent, for the reasons in the gamma lesson. Averaging encoded numbers is not averaging light.

Take a fine black-and-white checkerboard, half the pixels at 0 and half at 255, and reduce it so that each new pixel covers one black and one white. Average the encoded values and you get 128, which displays as about 22 per cent of the light. Average the actual light and you get 50 per cent, which encodes to about 188. The correct result is more than twice as bright as the one most software gives you.

So downscaled images with fine bright detail on dark backgrounds come out too dark: starfields, white text on black, city lights, backlit foliage, a lace edge against shadow. The image does not look wrong in isolation: it looks like the photograph was underexposed.

Resizing in linear light fixes it:

magick in.png -colorspace RGB -filter Lanczos -resize 800x -colorspace sRGB out.png

-colorspace RGB in ImageMagick means linear RGB, which is a confusing name for the right thing. GIMP 2.10 and later resize in linear light by default. Krita does. Photoshop does not, and neither do web browsers when they scale an oversized image to fit a layout.

The honest qualification: linear downscaling is measurably closer to the physics, and some editors dislike it on skin and foliage because the encoded-space result is slightly contrastier in a way people are used to. It is not a universal improvement in taste. It is a large improvement wherever fine bright detail sits on a dark field.

Two things that are not true

”Resize in 10 per cent steps for quality.” This was real advice for the bicubic implementation in Photoshop 6 in 2001. With modern Lanczos or the current bicubic, repeated small steps compound interpolation error and give a softer result than one pass. Measure it yourself if you doubt it: one image, two routes, compare at 100 per cent.

”Always use Lanczos.” Its ringing is a genuine artefact. On flat graphics, screenshots and logos it draws grey rims around everything. Use a smoother filter, or better, re-export the graphic from its source at the size you need.

What to choose

• Photographs, any direction: Lanczos or bicubic. Check hard edges for rings.
• Screenshots, diagrams, logos: re-export from source. If you cannot, bilinear or Mitchell, never Lanczos.
• Pixel art and ID or index masks: nearest neighbour, and only at whole-number multiples for pixel art.
• Anything with fine bright detail on dark: resize in linear light.
• Big enlargements you have decided to accept: a model-based upscaler, with the disclosure that goes with it.

Today: downscale one photograph of a fence or a striped fabric to 600 pixels twice, once with -sample and once with -filter Lanczos -resize. The moiré in the first one is the entire argument.