inconsistency in comparing bmp files

[Antosha]

When i run:

Code: Select all

convert rose: -type GrayScale rose.bmp
convert rose: -type GrayScale -colors 256 rose2.bmp
compare -metric mse rose.bmp rose2.bmp qq.bmp

i get
207193 dB
70,46,BMP

(*)So, these images apparently don't match.

If i do:

Code: Select all

compare -metric mse rose: -type GrayScale rose.bmp qq.bmp
compare -metric mse rose: -type GrayScale rose2.bmp qq.bmp

Then i get:
0 dB
compare: image colorspace differs `ROSE'.

So, grayscaled rose does match rose.bmp and rose2.bmp,
but they don't match between each other, as shown in (*)

[fmw42]

you left off the ending "p" in qq.bmp -- you wrote qq.bm

[Antosha]

This probably has to do with the incorrect reduction of colours.
(The compare uses the same algorithm as convert, therefore it returns 0db, but the images are actually different)

BTW, this is true not only for bmp, but for other image formats:

Code: Select all

convert rose: -type GrayScale -colors 256 rose.tiff
convert rose: -type GrayScale rose2.tiff
compare -metric mse rose2.tiff rose.tiff qq.tiff

I get:

Code: Select all

207193 dB
70,46,TIFF

[Antosha]

So, what's with the found bug? Will you fix it?
Do you confirm it?

[Antosha]

Am i the only one who encounters this problem?

[Antosha]

Am i the only one who encounters this problem?

[fmw42]

I am not sure what your problem is? What is qq.tiff?

If I do

convert rose: -type GrayScale -colors 256 rose.tiff
convert rose: -type GrayScale rose2.tiff
compare -metric rmse rose.tiff rose2.tiff null:
374.619 (0.00571632)

I don't expect the two image to be the same. When you add -colors 256, you are changing the image to force it to have at most 256 colors (or in this case 256 graylevels). You may get less. Nevertheless the selection of colors or graylevels is decided by a complex algorithm and is not likely to match your original rose: image when converted simply to grayscale.

See -colors
and
http://www.imagemagick.org/script/quantize.php

[Antosha]

When you add -colors 256, you are changing the image to force it to have at most 256 colors (or in this case 256 graylevels). You may get less.

Exactly.
Lets say that some image has less then or equal to 256 colours, then after i 'reduce' the number of colors with -colors 256, what should be the result?
I think that the image should not change a bit. Do you agree?
Why should it change, if the requirement "-colors 256" is met by the original image?
Why reduce the number of colours even more? Why change their value?

Nevertheless the selection of colors or graylevels is decided by a complex algorithm

No matter how complex it is, it should meet the identity law. That is, if an image has less then or equal to 256 colours, then the appliance of the transform "-colors 256" should have no effect.

The original rose: image is 8-bit, therefore, the number of grey levels is no more than 256, therefore if i apply -colors 256 the grey level values should not change.

[fmw42]

I don't think that is the way -colors works. It maps the colors onto a tree and traverses the tree is some fashion that may end up with 256 different assignments to the same number of colors - regrouping them in some different manner. It makes a tree an traverses it no matter if the number of colors meets your number or not. I do not understand this algorithm, but I can see that it could end up with a different color assignment even for the same number of colors. Or it could end up with fewer colors than 256, just not more.

You will need to discuss this with the IM developers on the Developers forum if you want it to do something else, such as preserve your exact same colors if the number of colors in the image is the same as you specify.

Make a post to Developers forum and see what they say. But I suspect it will be treated as an enhancement and not a bug.

[Antosha]

I don't think that is the way -colors works. It maps the colors onto a tree and travers

Well, i don't really care how it works -- most importantly is that it should be intuitive.

For instance, if the number of colours is already met by the constraint, then it should not change anything. I suspect, that this difference has to do with some quantization/rounding error.

BTW, talking about intuition, what do you think will happen if i run:

Code: Select all

convert rose: -type GrayScale rose.tiff
convert rose.tiff -colors 256 rose2.tiff
convert rose2.tiff -colors 256 rose3.tiff
compare -metric mse rose2.tiff rose3.tiff null:

What would be your guess?
Well, they differ.

Code: Select all

12266.2 dB
70,46,TIFF

I think this is odd.
If the "complex" algorithm reduced(and i suppose optimized) the number of colours,
then why does the second application of the same transform change the image?
Isn't it supposed to be already optimized?
I wonder, how would the image look on the 10000 iteration?



The reason that i need -colors 256, in the first place, is that i need to transform a TrueColor Grayscale bmp image to a pellete based bmp. In the tutorial it is suggested to use "-colors 256", the last discussion shows, that "-colors 256" command also destroys the grayscale values of the original image.

But, i think this is a bug in the realization of the algorithm, some error in rounding, ...

[magick]

We're using ImageMagick 6.4.0-10 under Linux. Your commands return 0 noise, as expected:

• -> convert rose: -type GrayScale rose.tiff
  -> convert rose.tiff -colors 256 rose2.tiff
  -> convert rose2.tiff -colors 256 rose3.tiff
  -> compare -metric mse rose2.tiff rose3.tiff null:
  0

[Antosha]

OK. Sorry, for not using the latest version. Now i have the latest.

But my question (the first one) remains.
How do i transform a Truecolor Grayscale BMP to a palette bmp?
If i use "-colors 256" it will destroy the grayscale values.

And do you think that if an image has less then 256 colours, then the transform "-colors 256" should not change a thing? Or not? Considering the magnitude(very small) of the error, it seems to be a bug.

[Antosha]

In the tutorial it is written, that

ImageMagick supports 8, 24, and 32-bit BMP images.

Add -colors 256 to the end your command line (before the output image
filename) to create a 8 bit colormapped BMP image rather than a 24 bit BMP
format. Extra colors can be added to images after performing operations
like rotates, and resize. See Color Quantization for more info on -color.

But if i do this, i loose colors, the result would be different if i do it with gimp.
Is there another way to tell image magick that i want a palette based bmp?

[Antosha]

I found the bug. It has to do with the dithering.
The color reduction algorithm is correct -- it finds the correct number of colors.
After it is run, dithering is run (i don't know why), that ruins the colors. I don't know what is it doing (i did not have enough time to search down the code snippet), but it is doing it incorrectly. I guess some of the colors get incorrectly mapped:

A fix is obviously is needed.

[magick]

What you want is this:

• -> convert rose: -type GrayScale rose.bmp
  -> convert rose: -type GrayScale +dither -treedepth 8 -colors 256 rose2.bmp
  -> compare -metric mse rose.bmp rose2.bmp qq.bmp
  0