{"course":{"slug":"image-editing","title":"Editing an Image","url":"https://addaly.com/learn/image-editing","level":"beginner","track":"create"},"lesson":{"slug":"resampling-algorithms","title":"Nearest, bicubic, Lanczos: what the resize dialogue is computing","url":"https://addaly.com/learn/image-editing/resampling-algorithms","position":68,"of":78,"minutes":10,"answer":"A resize invents pixel values between the ones you have: point sampling aliases fine detail into moiré, Lanczos is sharp but rings at hard edges.","keyIdea":"A resize invents pixel values between the ones you have: point sampling aliases fine detail into moiré, Lanczos is sharp but rings at hard edges, and averaging gamma-encoded numbers rather than light makes downscaled bright detail on dark backgrounds come out roughly half as bright as it should be."},"body":{"format":"markdown","text":"## A resize is a question about pixels that do not exist\n\nReduce 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.\n\nThe 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.\n\n## The five you will meet\n\n- **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.\n- **Bilinear** takes the weighted average of the four surrounding pixels. Cheap, soft, and never produces a value outside the range it started from.\n- **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.\n- **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.\n- **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.\n\n## Reducing is where the damage happens\n\nMost people worry about enlarging. Reducing is where images are quietly ruined.\n\nA 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.\n\nThe 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:\n\n```bash\nmagick in.jpg -sample 1600x out-bad.jpg    # point sampling, will alias\nmagick in.jpg -filter Lanczos -resize 1600x out-good.jpg\n```\n\n`-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.\n\n## The gamma mistake almost every tool makes\n\nThis one is worth the lesson on its own, because it is invisible until you know the pattern, and then you see it constantly.\n\nThe 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.\n\nTake 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.\n\n> Figure: A checkerboard of 0 and 255, reduced until one pixel covers two squares. Bars (per cent of full scale): Average the light, then encode: 188 74; Average the stored numbers: 128 50; Point sample: whichever square it lands on 100. Half the light is gone, so the honest answer is about 188. Averaging the stored numbers gives 128, which emits roughly 22 per cent of the light, less than half of what it should. Point sampling does not average at all, which is where the moiré on a striped shirt comes from. GIMP and Krita reduce in linear light by default; Photoshop and every web browser do not.\n\nSo 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.\n\nResizing in linear light fixes it:\n\n```bash\nmagick in.png -colorspace RGB -filter Lanczos -resize 800x -colorspace sRGB out.png\n```\n\n`-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.\n\nThe 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.\n\n## Two things that are not true\n\n**\"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.\n\n**\"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.\n\n## What to choose\n\n- Photographs, any direction: **Lanczos** or bicubic. Check hard edges for rings.\n- Screenshots, diagrams, logos: re-export from source. If you cannot, **bilinear** or Mitchell, never Lanczos.\n- Pixel art and ID or index masks: **nearest neighbour**, and only at whole-number multiples for pixel art.\n- Anything with fine bright detail on dark: resize in **linear light**.\n- Big enlargements you have decided to accept: a model-based upscaler, with the disclosure that goes with it.\n\nToday: 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."},"check":{"question":"A photograph of a night skyline is reduced from 4000 to 800 pixels wide in Photoshop with Bicubic Sharper. The small version looks distinctly darker and the lit windows have lost their punch, although the exposure was never touched. What is the mechanism?","options":[{"text":"The averaging happened on encoded numbers rather than on light, so mixed pixels land below the right luminance.","correct":true},{"text":"Bicubic Sharper adds an overshoot at edges, and the dark side of each overshoot has dragged the overall brightness down.","correct":false,"tempting":"Reads the sharpening overshoot as a global tone change, when it is symmetrical about each edge and does not shift the average level."},{"text":"Reducing an image discards pixels, and the discarded ones happened to be the bright ones.","correct":false,"tempting":"Treats resampling as selection rather than averaging, which would make the result random rather than reliably too dark."},{"text":"The image needed to be converted to sRGB before resizing so the numbers would be interpreted correctly.","correct":false,"tempting":"Confuses a profile conversion, which preserves appearance, with the arithmetic used during the resize itself."}]},"prev":{"slug":"when-not-to-use-any-of-it","title":"The decision, and the parts nobody has settled","url":"https://addaly.com/learn/image-editing/when-not-to-use-any-of-it"},"next":{"slug":"sizing-for-a-screen","title":"The width to export, and why the browser will not fix it for you","url":"https://addaly.com/learn/image-editing/sizing-for-a-screen"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Nearest, bicubic, Lanczos: what the resize dialogue is computing', in Editing an Image. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/image-editing/resampling-algorithms (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Nearest, bicubic, Lanczos: what the resize dialogue is computing","courseTitle":"Editing an Image","module":{"index":8,"slug":"out-of-the-editor","title":"Out of the editor: size, sharpness and the delivered file"},"answer":null,"keyIdea":"A resize invents pixel values between the ones you have: point sampling aliases fine detail into moiré, Lanczos is sharp but rings at hard edges, and averaging gamma-encoded numbers rather than light makes downscaled bright detail on dark backgrounds come out roughly half as bright as it should be.","hero":{"kind":"figure","figure":{"t":"figure","label":"Figure 8.1","figure":{"type":"bars","unit":"per cent of full scale","title":"A checkerboard of 0 and 255, reduced until one pixel covers two squares","series":[{"label":"Average the light, then encode: 188","value":74,"highlight":true},{"label":"Average the stored numbers: 128","value":50},{"label":"Point sample: whichever square it lands on","value":100}],"caption":"Half the light is gone, so the honest answer is about 188. Averaging the stored numbers gives 128, which emits roughly 22 per cent of the light, less than half of what it should. Point sampling does not average at all, which is where the moiré on a striped shirt comes from. GIMP and Krita reduce in linear light by default; Photoshop and every web browser do not."},"alt":"Figure: A checkerboard of 0 and 255, reduced until one pixel covers two squares. Bars (per cent of full scale): Average the light, then encode: 188 74; Average the stored numbers: 128 50; Point sample: whichever square it lands on 100. Half the light is gone, so the honest answer is about 188. Averaging the stored numbers gives 128, which emits roughly 22 per cent of the light, less than half of what it should. Point sampling does not average at all, which is where the moiré on a striped shirt comes from. GIMP and Krita reduce in linear light by default; Photoshop and every web browser do not."}},"blocks":[{"t":"h2","id":"a-resize-is-a-question-about-pixels-that-do-not-exist","runs":[{"text":"A resize is a question about pixels that do not exist"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-five-you-will-meet","runs":[{"text":"The five you will meet"}]},{"t":"ul","items":[[{"text":"Nearest neighbour","b":true},{"text":" 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 "},{"text":"sleeve","i":true},{"text":" and 2 means "},{"text":"collar","i":true},{"text":" and an averaged value of 1.5 would be meaningless."}],[{"text":"Bilinear","b":true},{"text":" takes the weighted average of the four surrounding pixels. Cheap, soft, and never produces a value outside the range it started from."}],[{"text":"Bicubic","b":true},{"text":" uses sixteen pixels and fits a cubic curve through them. The curve overshoots slightly at an edge, which reads as mild sharpening. Photoshop’s "},{"text":"Bicubic Smoother","i":true},{"text":" and "},{"text":"Bicubic Sharper","i":true},{"text":" are the same algorithm with the overshoot dialled down for enlargement and up for reduction."}],[{"text":"Lanczos","b":true},{"text":" 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."}],[{"text":"Model-based enlargement","b":true},{"text":" (Photoshop’s "},{"text":"Preserve Details 2.0","i":true},{"text":", 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."}]]},{"t":"h2","id":"reducing-is-where-the-damage-happens","runs":[{"text":"Reducing is where the damage happens"}]},{"t":"p","runs":[{"text":"Most people worry about enlarging. Reducing is where images are quietly ruined."}]},{"t":"p","runs":[{"text":"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 "},{"text":"moiré","b":true},{"text":": broad wavy bands of colour that were never in the scene. The same thing produces the shimmering brickwork in a downscaled architectural shot."}]},{"t":"p","runs":[{"text":"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:"}]},{"t":"code","lang":"bash","label":"Bash","text":"magick in.jpg -sample 1600x out-bad.jpg    # point sampling, will alias\nmagick in.jpg -filter Lanczos -resize 1600x out-good.jpg"},{"t":"p","runs":[{"text":"-thumbnail","code":true},{"text":" is "},{"text":"-resize","code":true},{"text":" 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."}]},{"t":"h2","id":"the-gamma-mistake-almost-every-tool-makes","runs":[{"text":"The gamma mistake almost every tool makes"}]},{"t":"p","runs":[{"text":"This one is worth the lesson on its own, because it is invisible until you know the pattern, and then you see it constantly."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"Resizing in linear light fixes it:"}]},{"t":"code","lang":"bash","label":"Bash","text":"magick in.png -colorspace RGB -filter Lanczos -resize 800x -colorspace sRGB out.png"},{"t":"p","runs":[{"text":"-colorspace RGB","code":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"two-things-that-are-not-true","runs":[{"text":"Two things that are not true"}]},{"t":"p","runs":[{"text":"”Resize in 10 per cent steps for quality.”","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"”Always use Lanczos.”","b":true},{"text":" 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."}]},{"t":"h2","id":"what-to-choose","runs":[{"text":"What to choose"}]},{"t":"ul","items":[[{"text":"Photographs, any direction: "},{"text":"Lanczos","b":true},{"text":" or bicubic. Check hard edges for rings."}],[{"text":"Screenshots, diagrams, logos: re-export from source. If you cannot, "},{"text":"bilinear","b":true},{"text":" or Mitchell, never Lanczos."}],[{"text":"Pixel art and ID or index masks: "},{"text":"nearest neighbour","b":true},{"text":", and only at whole-number multiples for pixel art."}],[{"text":"Anything with fine bright detail on dark: resize in "},{"text":"linear light","b":true},{"text":"."}],[{"text":"Big enlargements you have decided to accept: a model-based upscaler, with the disclosure that goes with it."}]]},{"t":"p","runs":[{"text":"Today: downscale one photograph of a fence or a striped fabric to 600 pixels twice, once with "},{"text":"-sample","code":true},{"text":" and once with "},{"text":"-filter Lanczos -resize","code":true},{"text":". The moiré in the first one is the entire argument."}]}],"check":{"question":[{"text":"A photograph of a night skyline is reduced from 4000 to 800 pixels wide in Photoshop with Bicubic Sharper. The small version looks distinctly darker and the lit windows have lost their punch, although the exposure was never touched. What is the mechanism?"}],"options":[{"text":[{"text":"The averaging happened on encoded numbers rather than on light, so mixed pixels land below the right luminance."}],"correct":true,"tempting":null},{"text":[{"text":"Bicubic Sharper adds an overshoot at edges, and the dark side of each overshoot has dragged the overall brightness down."}],"correct":false,"tempting":[{"text":"Reads the sharpening overshoot as a global tone change, when it is symmetrical about each edge and does not shift the average level."}]},{"text":[{"text":"Reducing an image discards pixels, and the discarded ones happened to be the bright ones."}],"correct":false,"tempting":[{"text":"Treats resampling as selection rather than averaging, which would make the result random rather than reliably too dark."}]},{"text":[{"text":"The image needed to be converted to sRGB before resizing so the numbers would be interpreted correctly."}],"correct":false,"tempting":[{"text":"Confuses a profile conversion, which preserves appearance, with the arithmetic used during the resize itself."}]}],"order":[3,2,0,1],"why":null},"prev":{"slug":"when-not-to-use-any-of-it","title":"The decision, and the parts nobody has settled","minutes":9},"next":{"slug":"sizing-for-a-screen","title":"The width to export, and why the browser will not fix it for you","minutes":9}}}