Colortable generated from indexed color image goes wrong.

[paul.verschoor]

I need to have a colortable of some images with reduced colors, and came across the following bug.

The following code result in a 64x1 colortable strip, with only 22 unique colors.

Code: Select all

convert rose: -colors 64 -unique-colors rose_ct.bmp

But when exported to a text file, there are 64 unique color values

Code: Select all

convert rose: -colors 64 -unique-colors txt:- > rose_ct.txt

At least it means that '-colors 64' works fine.

indexing and creating colortable in two seperate steps -> bug depends on the file extension
png goes wrong, probably because it can handle indexed colortables

Code: Select all

convert rose: -colors 64 rose_64.png
convert rose_64.png -unique-colors rose_64_ct.png

gives buggy 22 unique colors in colortable (64x1)


bmp goes oke when done in two single steps, probably because bmp can NOT handle indexed colortables

Code: Select all

convert rose: -colors 64 rose_64.bmp
convert rose_64.bmp -unique-colors rose_64_ct.bmp

gives correct 64 unique colors in colortable (64x1)


Also strange, when scaling is applied IN ONE SINGLE STEP, there is no buggy behaviour .

Code: Select all

convert rose: -colors 64 -unique-colors -scale 1000% rose_64_ct_scaled.bmp

It will give an image of 64 unique colors. (640x10)

I tried different extensions (.png, .bmp, .tiff) in the output file, and if you do the conversion in one step (see first code example), they all give the same buggy results.
I Also tried different source images. It seems that when a file has a index colortable, it will result in a buggy colortable. Some source files (indexed) generated only 1 unique color in the colortable, while the where more then one unique colors in the source (and in the txt:- generated file), used different values for the '-colors' parameter, all give the save bug.

I checked the buggy images with several image viewers and with 'Gimp Filters Colors Colorcube Analysis', so it's not a viewer problem on my side.

I also tried different Windows Binaries (static/dynamic and Q8/Q16)
but all gave same error.

I'm using.
ImageMagick (32 bits version)
Version: ImageMagick 6.4.3 2008-08-28 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2008 ImageMagick Studio LLC

Operating system:
Windows XP Home edition Service Pack 2

[magick]

The problem you reported is fixed in the Subversion trunk available sometime tomorrow. The patch will also be available in the next point release. Thanks.