7.0.3-1, Fedora 24, convert -quantize Lab results in wrong number of colors

[fiendish]

Code: Select all

#!/bin/bash
convert -version
for s in Luv Lab YIQ RGB; do 
convert $1 -resize 640 -median 3 -quantize $s -colors 16 +dither imagemagick-16c-$s-nodith.png
identify -format "%k colors\n" imagemagick-16c-$s-nodith.png
done

prints the following:

Version: ImageMagick 7.0.3-1 Q16 x86_64 2016-09-20 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2016 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules OpenMP
Delegates (built-in): bzlib cairo djvu fftw fontconfig fpx freetype gslib jng jpeg lcms ltdl lzma pangocairo png ps tiff webp wmf x xml zlib
16 colors
14 colors
16 colors
16 colors

[fiendish]

Same with ImageMagick-7.0.3-2~beta20160921.x86_64.rpm

[fmw42]

From the documentation -colors does not guarantee you will get exactly the number of colors specified. It could be less, but not more. See http://www.imagemagick.org/script/comma ... php#colors

Code: Select all

-colors value
Set the preferred number of colors in the image.

The actual number of colors in the image may be less than your request, but never more

[fiendish]

From the documentation -colors does not guarantee you will get exactly the number of colors specified. It could be less, but not more.

That documentation is a bad excuse for wrong behavior. If asking for 18 colors can give 16, then asking for 16 colors should give 16.

[snibgo]

A colour reduction algorithm cannot guarantee to result in exactly N different colours because the input may not contain N different colours.

If the input does contain N or more different colours, the algorithm could probably be written to result in exactly N different colours. But this would add complexity and time cost. (For example: it might run once, realise the result has less than N colours, so it runs again being less aggressive about the colour reduction.)

[fiendish]

A colour reduction algorithm cannot guarantee to result in exactly N different colours because the input may not contain N different colours.

That's not relevant here. My input contains 431703 of colors and I'm only asking for 16.

If the input does contain N or more different colours, the algorithm could probably be written to result in exactly N different colours. But this would add complexity and time cost.

Sure, and it could always just return N random colors regardless of what the image contains, which would entirely satisfy the request for color palette change and be also wrong. Correctness usually has complexity costs.

[snibgo]

Feel free to suggest improvements, either to the current code or as a new operator.

[fiendish]

Feel free to suggest improvements, either to the current code or as a new operator.

I don't understand. I thought I was suggesting an improvement? I suggest using a quantizer that gives either the requested number of colors or the number of colors in the original image, whichever is less, but not a different third option because any third option is ignoring what the user needs.

[snibgo]

Sure, but that's a vague "it would be nice if...". And it would be nice, I agree. But if that's all it is, I doubt it will be implemented any time soon.

[fmw42]

There are some simple quantizers that can give you exactly what you want, but I doubt you would like the results.

If you are on a Unix system (Linux, Mac OSX, Windows with Cygwin or Windows 10), you can try my script kmeans and specify seed colors for the number of colors you want (assuming that the image has at least that many colors). If you specify just the number of colors, then it will use IM -colors to get the seed colors and you may not get the number you want.

That may produce good results. See my link below.

[fiendish]

Sure, but that's a vague "it would be nice if...". And it would be nice, I agree. But if that's all it is, I doubt it will be implemented any time soon.

You're right. Let me try again.

I suggest that the quantizer returning a number of colors that is different than what the user asked for should be seen as a bug so that it can eventually be fixed by someone.

There are some simple quantizers that can give you exactly what you want, but I doubt you would like the results.

Why not? GraphicsMagick looks like it does it for every supported colorspace and the results are both very fast and also look fine?

The fact is that right now ImageMagick cannot produce a 37 color YUV quantization for an image I have. Asking for 37 gives 35. Asking for 38 gives 36. Asking for 39 gives 38.

Now you could of course say "But maybe you only need 35?" And my response is "If I needed 35 wouldn't I have asked ImageMagick for 35 instead of 37? Under what circumstances do you think that returning fewer colors than requested is an ideal result if the image can support it?"

GraphicsMagick does it both very quickly and with a pleasing result (maybe because it has two more colors to play with).

Then your question could be "So why not use GraphicsMagick?" And my answer is "Now I am. I figured the ImageMagick developers might like to know that not conforming to the user requested number of colors caused a problem for at least one user."

you can try my script kmeans and specify seed colors for the number of colors you want (assuming that the image has at least that many colors). If you specify just the number of colors, then it will use IM -colors to get the seed colors and you may not get the number you want.

Does your kmeans script run in more time or less time than convert takes? Because convert is already not super fast. And I should manually preselect K starting colors? I think I'll stick with gm convert for now.

[fmw42]

It iterates, so likely will take substantial time. But if you provide a set of seed colors, then it does not have to use -colors (color quatization) first, which would of course make it take even longer and not give you your desired number colors. To get your desired number of colors, you would have to provide the exact number of seed colors.

So I suppose that is not for you, though it does a very good job in terms of quality in its own way.

Since GraphicsMagick was a spin off of Imagemagick, I would have expected that they were using nearly the same quantization algorithm. But perhaps it was an older one that IM used or it could be something simpler and different.

However, knowing how little time the developers have right now apart from fixing bugs, I would not hold your breath on it.

But I will leave that to the developers. Perhaps they will add a simpler and faster quantizer as an alternate.