A pixel art resizer that shows you what it threw away

The ones that divide the file's own width. A 64-pixel sprite taken to 32 gives every cell exactly two source pixels by two; taken to 40 it gives some cells two and others one, because 64 does not divide by 40. On artwork built out of one-pixel lines the consequence is not subtle: the same outline is kept where the cells happened to land on two pixels and thinned away where they landed on one, so a straight line appears to wander. Both candidates report the fewest and most source pixels standing behind a cell, and the nearest widths that do divide are offered as buttons.

Because nothing landed nearer to it than to something else, which is settled by where a color sits among its neighbors rather than by how much of the picture it covered. A mid-tone wedged between two similar shades can hold a quarter of the artwork and still lose every cell at a smaller size, while an isolated accent holding forty pixels comes through untouched. That is why the panel lists each dropped color with the source pixels it was carrying: one that disappeared holding four pixels is a highlight nobody will miss, and one that disappeared holding eight hundred means the size is wrong.

Usually not, and the reason is specific to this direction of work. Error diffusion restores the average color of a region by scattering the rounding error into neighboring cells, which is the right trade for a photograph and the wrong one here: it fills flat areas with speckle, and flat areas are how pixel art stays legible at small sizes. It also raises the color count at exactly the moment you were trying to lower it, and if the cells are about to become beads or stitches every extra color is another bag or another skein. Switch it on to compare, then check what it did to the color count before you keep it.

It is the artwork meeting a real limit, and the loss map shows you which cells hit it. A face needs somewhere around 30 to 40 cells across before its features stop being a compromise between two colors, and a piece built out of one-pixel detail — text, a thin outline, a highlight in an eye — reaches that wall long before a piece built out of broad shapes does. When most of the map is shading three and four, no amount of dithering or palette work rescues the size, and the honest fix is more cells.

How many different original colors each cell had to swallow. A cell at the palest end covered one color and therefore lost nothing; a cell at the darkest end covered four or more, which means the single color it now carries is an average of things that did not agree. Read it against the picture rather than on its own — crowding along an outline is normal and usually fine, whereas a solid patch of dark cells sitting across the subject's face is the size telling you plainly that it cannot hold that part of the image.

Because the decision is always comparative and the cost is rarely where people expect it. Dropping from 48 cells to 32 removes 55% of the units to place on a square piece, and it might cost two colors or twenty depending entirely on where those colors sat in the range; no rule of thumb predicts which for a given picture. Putting both sets of figures in one table turns 'is the smaller one good enough' into an arithmetic question with an answer, which is the only form of that question anybody can act on.

You can, and the second step is lossless while the first is not. Once the smaller chart exists, taking it back up by any whole multiple returns every cell as a perfect square with nothing blended, so a 32-cell reduction at 8x is a clean 256 px picture of exactly 32 cells. What no enlargement can do is return the detail the reduction discarded — it reproduces the reduction faithfully, including everything the reduction threw out. Reduce once from the original, keep that chart, and enlarge from it rather than from an enlargement of an enlargement.