Palette quantization notes: reducing colors without making an image muddy

qingwancong — Thu, 09 Jul 2026 18:10:35 +0000

I’ve been thinking about a small image-processing problem lately: how to reduce an image to a limited palette without making it look muddy.

This comes up in a lot of places:

pixel art tools
printable pattern generators
low-color previews
LED matrix displays
icons and small thumbnails
craft or grid-based workflows

The easy version is: pick the nearest color for every pixel.

The hard version is: keep the important shapes readable after the palette gets much smaller.

Nearest color is only the baseline

A simple nearest-color pass usually works like this:

Take each pixel.
Compare it with every color in the target palette.
Pick the closest one.
Replace the pixel.

That gives you a valid output, but not always a good one.

The problem is that closest is local. It does not know whether the whole image still reads well.

A face can lose warm midtones. A shadow can turn into a flat dark blob. A small highlight can disappear. Skin, fur, fabric, and background colors can collapse into the same bucket.

So palette reduction is not just a color problem. It is also a structure problem.

RGB distance can be misleading

A common first attempt is Euclidean distance in RGB:

function rgbDistance(a, b) {
  return Math.sqrt(
    (a.r - b.r) ** 2 +
    (a.g - b.g) ** 2 +
    (a.b - b.b) ** 2
  );
}

This is easy to implement, but it does not match human perception very well.

Two colors can be numerically close in RGB and still feel different. Other colors can be farther apart numerically but visually acceptable.

A better approach is to compare colors in a more perceptual color space, such as Lab or OKLab. You still have to be careful, but the distance metric starts closer to what the eye notices.

Dithering helps, but it changes the style

Error diffusion, like Floyd-Steinberg dithering, can preserve gradients and perceived detail with fewer colors.

That is useful when the output is meant to look like a low-color image.

But dithering is not always desirable. In grid-based outputs, it can create scattered single-pixel noise. That may preserve tone, but it can make the result harder to read or harder to build.

So the question is not: should I dither?

Is texture more important here, or are clean shapes more important?

For a tiny icon, clean shapes often win. For a photograph-like preview, dithering may win.

Palette size is a UX control, not just a parameter

A 24-color image and a 6-color image are not just different compression levels. They can feel like different art directions.

When users control palette size, they are really controlling tradeoffs:

realism vs simplicity
smoothness vs readability
detail vs editability
texture vs clean regions

This is why I like showing a preview before committing to the palette. A numeric color count alone does not tell the user what the image will feel like.

Preserve important regions differently

One useful trick is to treat the whole image less uniformly.

For example:

preserve contrast around eyes and facial features
simplify background colors more aggressively
keep outlines cleaner than texture regions
protect small high-salience details from being averaged away

This does not require a huge ML pipeline. Even simple masks, edge detection, or manually marked regions can help.

The main idea: not every part of the image deserves the same color budget.

A practical pipeline

A basic but workable pipeline might look like this:

resize image
-> optional subject/background separation
-> smooth tiny noise
-> choose or load target palette
-> map pixels using perceptual distance
-> optionally apply controlled dithering
-> clean isolated pixels
-> preview multiple color counts
-> let the user pick the best tradeoff

The cleanup step matters more than it sounds.

After quantization, isolated pixels often appear because the algorithm is optimizing locally. A small post-pass that removes lonely pixels or merges tiny regions can make the result feel much more intentional.

What I watch for

When reviewing a reduced-palette result, I usually check:

Do the main shapes still read at a glance?
Did skin or fur become too gray?
Did important contrast disappear?
Are there noisy single pixels everywhere?
Did the background steal colors from the subject?
Would a human understand why each color exists?

That last question is fuzzy, but useful.

If a color appears only a few times and does not clarify the image, it may be adding complexity without adding meaning.

Closing thought

Palette quantization looks simple because the first version is easy to code.

But the useful version is more about choosing what to preserve.

The algorithm can map colors. The product decision is deciding which details are worth keeping.

Building Toonbead: turning photos into bead art you can actually make

qingwancong — Thu, 09 Jul 2026 17:49:55 +0000

I’m building a small craft tool called Toonbead.

The idea is simple: upload a pet, portrait, or gift photo and turn it into a fuse bead pattern that someone can actually make at a craft table.

The tricky part is that “photo to pixel art” is not the same thing as “photo to bead pattern.”

A pixelated image can look fine on screen and still be painful to build:

too many colors
noisy one-off pixels
no real bead color matching
no bead counts
no board layout
no printable instructions
no sense of whether the project is beginner-friendly

So Toonbead is focused on the practical craft constraints, not just the image result.

The workflow I’m aiming for:

Upload a meaningful photo.
Keep the subject recognizable.
Convert it into a cleaner bead-friendly design.
Match it to real bead colors.
Show size, bead count, color count, and difficulty.
Export a printable pattern that is ready to build.

I’m starting with pet portraits, personal gifts, and beginner-friendly fuse bead projects because those are the situations where the result needs to feel personal and still be realistic to finish.

What I’m still thinking through:

Should users choose board size first, or difficulty first?
How many colors is “too many” for a beginner pattern?
Should the first export be a PDF, an on-screen grid, or both?
How much editing should happen before the pattern is considered final?

If you make fuse bead art, pixel art, printable craft patterns, or tools for creative workflows, I’d love feedback.

Try the early version here: Toonbead

DEV Community: qingwancong