Legacy ImageMagick Discussions Archive

I'm wondering why when using -colors to run Color Reduction I'm always ending up with way less colors than I request.

My goal is as follows: Currently I'm working from a single large TextureAtlas png that was converted from RGBA8888 down to RGBA4444 using TexturePacker. I want to up quality by splitting the assets up into individual pngs so that each image can use more colors. My understanding is that the RGBA4444 format should support 4096 colors. I'd like to achieve the highest quality possible within the color limitation. In my head I'm thinking more colors should allow for better quality.

Here's what I'm running... A sample image is starting at 26,363 colors and afterwards is ending up at 1,092. But that's nearly a quarter or the colors it should be able to use? Is there any way to force the Color Reduction to use more colors? What am I missing here? Is it just an unavoidable detail of the algorithm?

I'm checking colors count with this: I'm using ImageMagick 6.9.8-4

Thanks for the help!

Yes, three channels each of 4 bits will support 4096 colours. But not any arbitrary combination of colours, merely one particular set of colours, the full range from black to white. IM's "-colors 4096" chooses the best 4096 colours that represent the image, and this almost certainly isn't that particular set.

You might get a better result from "-posterize 16". But even this is unlikely to use all possible 4096 colours.

-colors produce no more than your requested number of colors but can be less due to the color quantization algorithm being uses. See
https://www.imagemagick.org/script/comm ... php#colors
https://www.imagemagick.org/script/quantize.php

Thanks for the replies!

snibgo wrote: ↑2018-02-12T17:09:33-07:00 You might get a better result from "-posterize 16". But even this is unlikely to use all possible 4096 colours.

So using "-posterize 16" did get me a few more colors (up over 1,800 now). But what exactly does the value here correspond to? It looks like I can ramp this number up and gain a few colors so curious what that value really means.

The only other thing I was gonna try was creating a color table image that uses more of the colors from the original (based on appearance count) and piping that into -remap. Is there any way I could use that idea to force more colors into the color reduction? Perhaps in the form of guaranteeing colors in the final image? Although it seems like that wouldn't work well with the color reduction algorithm.

Otherwise is there anyway I can adjust variables inside of the color reduction algorithm? All I found was -treedepth which didn't seem to do much for me.

On "-posterize" see http://www.imagemagick.org/script/comma ... #posterize . "-posterize 16" reduces the image to 16 levels per channel, but these levels are evenly spread between 0 and QuantumRange. So the total number of colours available is 16*16*16 = 4096.

You want 4 bits per channel, which is 16 values per channel, and IM can give you this. Any particular image is unlikely to use all available 4096 colours. In the same way, an 8-bit/channel image is unlikely to use all available 16.7 million colours.

Thanks for clarifying -posterize!

I get that in a typical image you're not likely to use all colors but I am coming from an image that assuredly has used more than 4096 colors so I know there are colors to be used. Am I just not picturing this correctly? I've been assuming that my resulting RGBA4444 image can contain any combination of 4096 colors. You alluded to this not being the case previously. What's the reason? For discussion's sake, could I not pull the most common 4095 colors from the original image's 26k, add white, then create a resulting RGBA4444 image with these 4096 colors that has forced any pixel whose color is no longer present to white? Is there something about the colors definition that prevents this?

evolbert103 wrote:I've been assuming that my resulting RGBA4444 image can contain any combination of 4096 colors.

That assumption isn't correct. This is because the colours are explicitly defined by the bits.

Look at it this way. An image with 3 channels of 8 bits can have up to 16.7 million colours. But this isn't any combination of 16.7 million. It is only one particular combination.

Similarly, suppose we have three channels each of 1 bits ("-posterize 2"). Then we can record 8 different colours. Not any arbitrary combination, but only one particular combination, which is: black, white, red, green, blue, magenta, yellow and cyan. An image can be mapped to those colours, of course. The results will have 8 colours, or fewer.

The situation would be different if you wanted a palette image, with 12 bits in each pixel, each indexing into a 4096-entry palette. Then you could have 4096 arbitrary colours. (But IM palettes are limited to 8 bits.)

Ahhh that's been my issue. Clearly wasn't visualizing that correctly and that clears things up for me a lot, thanks!