Choosing a resampling kernel

Every kernel answers one question — what colour belongs at a place the source never sampled — and each answers it with a different trade between sharpness, ringing and invented colour.

The kernels, in one table

A kernel is a weighting curve. For each output pixel it looks at a small window of source pixels around the matching position and blends them in proportions the curve sets. The width of that window and the shape of the curve are the whole difference.

What each kernel reads and what it does to an edge
Kernel	Source pixels read per axis	At a hard edge	New colours
Nearest	1	Stays hard; steps at fractional factors	None, ever
Area average (box)	The block it covers	Exact block mean at a whole-number reduction; hard going up	Means of blocks only
Bilinear	2	Soft ramp	Yes, between neighbours
Bicubic (Catmull-Rom)	4	Crisp, slight overshoot	Yes
Mitchell (B = C = 1/3)	4	Softer, little ringing	Yes
Lanczos (a = 3)	6	Crispest, visible halo on high contrast	Yes, including overshoot

The panel's automatic choice is Lanczos going down and bicubic going up: acuity is the scarce thing on a reduction, and ringing is the risk on an enlargement. The kernel strip under the stage renders the same patch through every kernel at once, with a count of the distinct colours each one produced, so the choice can be made by looking.

Pixel art: nearest, at a whole-number factor

Sprites, icons and pixel-exact screenshots are the case where interpolation is simply wrong. The artist placed every pixel; a blend between two of them is a colour that was never in the palette. Nearest-neighbour copies each source pixel into the output unchanged, so the palette survives exactly — the lab's own acceptance test checks that a nearest render contains no colour absent from the source.

The factor matters as much as the kernel. At ×2, ×3 or ×4 every source pixel becomes a square of the same size. At ×2.5 some become two pixels wide and some three, and the unevenness is visible on any regular pattern. The panel flags a fractional factor under nearest and offers the whole numbers either side. It also detects art that was already enlarged — a picture built from 4 × 4 blocks — and offers its native grid.

Open the lab set to nearest at ×4.

Linear light, and why averages come out dark

The numbers in an 8-bit file are gamma-encoded: 128 is not half the light of 255, it is about a fifth. Average a white pixel with a black one on the encoded values and the result is 128 — a mid grey that is far darker than the true half-way brightness, which encodes to about 188. Every kernel does this averaging, so every resample on encoded values darkens fine bright detail against a dark ground.

One white and one black pixel, averaged
Arithmetic	Result (8-bit)	Light emitted
On encoded sRGB values	128	about 22 % of white
In linear light, re-encoded	188	50 % of white

With linear light on, the lab decodes each sample to linear intensity before filtering and re-encodes the result, so the average is an average of light. Open the lab at ×0.5 through Lanczos in linear light.

Transparency and the dark fringe

A transparent pixel still stores a colour, and it is usually black. Filter colour and opacity as four independent channels and that black leaks into every anti-aliased edge beside it. The resampler here multiplies colour by opacity before any pass and divides it back out only at the end, and the optional downscale sharpening weights its neighbourhood by opacity for the same reason. The acceptance test for this puts a white shape on a transparent ground, scales it through every kernel, and requires that no visible pixel comes out darker than white.

Questions people bring to this

Why does my pixel art look blurry after scaling, even at exactly 2x?

Because the kernel averaged neighbouring pixels. Bilinear, bicubic and Lanczos all compute new values between samples, so a hard edge between two colours becomes a ramp of in-between colours. Nearest-neighbour copies one source pixel into each output pixel, so at a whole-number factor every original pixel becomes an identical square and no new colour appears.

Is linear light always better?

For photographs with fine bright detail on a dark ground — stars, text, window lights — it is visibly more faithful, because averaging encoded sRGB values darkens every mix of bright and dark. For flat graphics and smooth gradients the difference is small, and some people prefer the slightly darker transitions the encoded arithmetic gives. It is a switch because both answers are defensible.

What does premultiplied alpha actually prevent?

A dark fringe. Fully transparent pixels are usually stored as black with zero opacity. A kernel that averages colour without regard to opacity pulls that black into the visible pixels beside it, so a logo on a transparent ground comes out with a grey outline. Multiplying colour by opacity before filtering, and dividing it back out afterwards, gives transparent pixels no weight in the colour of their neighbours.

Should I sharpen after a downscale?

Often, lightly. A reduction averages many source pixels into each output pixel, and a little edge contrast goes with them. A small unsharp mask restores it. On an enlargement the same operation sharpens pixels the kernel computed, which exaggerates the kernel rather than the picture — that is why the control here is labelled for downscales.

Take it back to the panel

Upload a photo

One photograph printed at three sizes, 100, 62 and 44 percent, laid on a desk with a ruler under each — One photo, three sizes: the pixels decide how big it can go.