Colortable generated from indexed color image goes wrong.
Posted: 2008-09-15T05:30:06-07:00
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.
But when exported to a text file, there are 64 unique color values 
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
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
gives correct 64 unique colors in colortable (64x1)
Also strange, when scaling is applied IN ONE SINGLE STEP, there is no buggy behaviour
.
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
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.bmpCode: Select all
convert rose: -colors 64 -unique-colors txt:- > rose_ct.txt
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
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
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.bmpI 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