convert png -color incorrect amount of output color

[SimonVonSchmude]

ImageMagick version

7.1.1-32

Operating system, version and so on

macOS 14.4.1

Description

When i use magick input.png -colors 3 out.png in terminal, i get an out.png file that is indeed converted to an indexed .png. However, this .png will always have one more color (#ffffff) in its palette than specified, even when #ffffff wasn't int the file to begin with. I guess it has something to do with the alpha channel being converted to that white... how can i disable that to get exactly the amount of colors specified?

[fmw42]

-colors does not guarantee the exact number of colors. You can use -kmeans 3 to get the correct number of colors, but you may need to turn alpha off before -kmeans and then turn alpha on after -kmeans. I do not know how alpha is treated, but it may be included when doing the kmeans. Is your alpha channel 100% opaque. If so, just turn it off.

[SimonVonSchmude]

sadly neither of these make a difference:
magick input.png -kmeans 3 out.png
magick input.png -alpha off -kmeans 3 out.png
magick input.png -alpha off -kmeans 3 -alpha on out.png

I am still getting 4 colors

[fmw42]

Post your image

[fmw42]

I get your same result 4 colors. But it is something in the exif data. So try stripping all that data, but auto-orient before.

magick image.png -auto-orient -strip -kmeans 3 x.png

Does that work the way you want? I get 3 colors, now.

[SimonVonSchmude]

Works for me too!

This feels somewhat as a hack so not marking as answer for now tho

[snibgo]

However, this .png will always have one more color (#ffffff) in its palette than specified ...

IM will add the background colour to the palette, unless it is already there. The default background colour is white. You can make the bacground colour anything you want. For example, if you know your palette will contain black, use -background Black before saving the PNG.

[fmw42]

I have never seen that adding the background color in -kmeans. Why did the -strip remove the extra color? I do not think the default background color should have been stripped. And the image did not have transparency that I could see. There was not alpha channel in the verbose information.

[fmw42]

When I do -colors 3 on your image, it only has 3 colors according to the histogram. The color map has 4, but one is apparently unused. That color in the color map looks like your background color. I think you may have been looking at the colormap not the histogram, which shows the colors in the image.

 Histogram:
       5020213: (72,86,58) #48563A srgb(72,86,58)
       3606748: (133,151,100) #859764 srgb(133,151,100)
       3565807: (196,198,180) #C4C6B4 srgb(196,198,180)
  Colormap entries: 4
  Colormap:
    0: (72,86,58) #48563A srgb(72,86,58)
    1: (133,151,100) #859764 srgb(133,151,100)
    2: (196,198,180) #C4C6B4 srgb(196,198,180)
    3: (255,255,255) #FFFFFF white

[snibgo]

I have never seen that adding the background color in -kmeans.

The background colour is added to the palette when a PNG file is written. It doesn't matter what has happened before then.

Why did the -strip remove the extra color?

-strip removes the "background colour" metadata, so IM won't add it to the palette.

-background none can also be used to stop the background colour being added to the palette. Perhaps this is the best general solution to the OP problem, having the least side-effect.

EDIT: another way to stop the background colour being added to the palette is by inserting -define png:exclude-chunk=bKGD before writing the PNG file.

[SimonVonSchmude]

magick input.png -kmeans 3 -strip x.png works well, while magick input.png -kmeans 3 -background none x.png leaves a black color in the palette.