Images & photos · Social Image Resizer
Resampling Filters Explained: Nearest, Bilinear, Bicubic and Lanczos
· Background
image-resizing resampling canvas
Every resize has to decide what colour a new pixel should be from the old ones: nearest-neighbour copies, bilinear averages four, bicubic weighs sixteen, and Lanczos uses a windowed sinc. This post explains each, the trade-off between blur, ringing and aliasing, and what browsers give you.
Same photo, three tools, three results — the concrete puzzle of resized images that differ in sharpness and shimmer
Two resizing tools can produce files with identical dimensions and visibly different edges. The geometry may match while sampling differs: each output pixel needs a colour derived from source information, and that derivation can favour sharpness, smoothness or resistance to aliasing. File dimensions alone cannot identify the method.
Social Image Resizer deliberately makes a narrower promise. Before drawImage it enables image smoothing and requests high smoothing quality. The Canvas 2D API does not tell the app which named kernel the browser selects, so the product cannot label its output nearest, bilinear, bicubic or Lanczos with source-level certainty.
The sampling problem — why shrinking an image without filtering produces moiré and jagged edges, in plain terms
Shrinking removes samples. If high-frequency stripes, hair or mesh are mapped without adequate filtering, they can become jagged, shimmer or form false patterns. Enlargement creates new sample positions between existing ones. In both directions, a resampler estimates the output from a finite source rather than revealing hidden detail.
A useful test image combines diagonals, one-pixel lines, repeated grids and smooth gradients. Export it at several scales and inspect one-to-one pixels plus normal display size. The observations show how the tested browser handles difficult content without pretending to reverse-engineer its internal implementation.
Nearest and bilinear are useful concepts, but ToolAcre does not expose them as choices
Nearest-neighbour conceptually chooses the closest source sample and tends to preserve hard pixel blocks. Bilinear interpolation conceptually blends nearby samples and generally smooths transitions. Those descriptions help explain visible extremes, but ToolAcre offers no switch labelled with either method and its tests do not identify the engine’s kernel.
Do not infer a named filter solely from one edge. A browser implementation can optimise or vary behavior with scale. The only reliable product statement is that smoothing is enabled and the quality property is set to high. Any deeper classification requires browser-specific evidence outside this module.
Bicubic behavior is not promised by this canvas implementation
Bicubic methods use a broader neighbourhood and cubic weighting, with variants that trade softness against edge overshoot. That is valuable background for comparing dedicated image applications. It is not a contract for Canvas 2D output, because render.js neither selects cubic coefficients nor imports a bicubic library.
If a production workflow requires a particular cubic kernel, use a tool that names and tests it. Social Image Resizer prioritises native browser availability and local operation. Its result should be judged as browser-resampled output under the recorded engine and version, not represented as a controlled scientific implementation of one variant.
Lanczos is outside the tool contract and is not claimed as a default
Lanczos uses a windowed sinc idea to preserve detail while controlling aliasing, and hard edges can show ringing under some settings. The workbook says it is a default in many photo tools, but that prevalence is not sourced here. More importantly, nothing in ToolAcre requests Lanczos by name.
This omission matters when diagnosing halos. Seeing one does not prove a Lanczos kernel, and not seeing one does not prove another algorithm. Compare source and output, document scale and browser, and avoid assigning causes that the application cannot observe. A visual symptom can guide testing without certifying hidden code.
What browsers offer — smoothing toggles and quality hints rather than named filters, and why output varies between browsers and versions
Browser canvas exposes imageSmoothingEnabled and imageSmoothingQuality rather than a filter catalogue. ToolAcre sets the first true and the second high immediately before drawing the scaled source. Engines may interpret a hint differently or evolve between versions, which is why identical JavaScript can yield small cross-browser differences.
The geometry stays explicit even when sampling is not. computeFrame returns exact scale and draw dimensions; drawRect centres and offsets the result; the output canvas has integer target dimensions. Separate those known facts from the hidden sampling choice when reviewing a difference between browsers.
What this does not cover — sharpening after resizing, and content-aware or machine-learning scalers
Sharpening after resize, content-aware methods and machine-learning reconstruction are not present. There is no unsharp-mask control, edge detector or generated-detail model. Output quality controls affect encoding for lossy formats, not a post-resize sharpening stage. Treat those as distinct operations.
A browser-native workflow remains useful precisely because it is simple and available. For routine social crops, inspect the actual result. For scientific imaging, typography masters or pixel-art preservation, choose tooling with explicit filter controls and validation suited to that content.
Takeaway: the filter explains the look — the Social Image Resizer uses the browser's own resampling, so knowing these terms tells you what to expect and what to check
Resampling explains why size is not the whole story, but the evidence must match the tool. Social Image Resizer requests smoothed, high-quality canvas drawing and leaves the exact kernel to the browser. That is enough to produce useful crops without marketing a filter the code never selects.
Keep a difficult test image, record browser details and compare exports when quality matters. The terminology helps describe what you see; the implementation tells you what you can honestly claim. Named algorithms belong only where the code or authoritative browser evidence demonstrates them.