[Magick-bugs] quantize introduces black areas (confirmation ofalready posted bug)

[Till Oliver Knoll]

Peter Pimley schrieb:
> ...
> I was quite lucky, because all of the images in my data set that
> exhibited the problem ALREADY had less than my requried number of colors
> (256).  With "identify -verbose" and a bit of sed, I was able to only
> execute the "convert" if the images were over 256 colors.

Thanks for providing this info. The thing is I indeed see this "black 
area" with certain images, and AFAICT only in bright blueish areas, but 
also a greyscale image shows this behaviour (where the correct colour 
would be close to white). I'm afraid I cannot attach the images I've 
used, but if someone needs them to investigate I'd be glad to send them.

I have not yet investigated how many colours are actually used in the 
input image (I will do so after this mail ;): I've written an icon 
composer (that is supposed to write the *.ico format) which converts the 
images automatically to the correct number of colours after 
drag'n'dropping the image on the corresponding field. Most images are 
converted correctly, some are not, among them a colour image with a 
light blueish background and even two greyscale images.

The images (QImage from the Qt toolkit) are first converted to 32bit 
before scaling to the proper size (128x128, 96x96, 64x64, ...), saved to 
memory as PNG, put into a Magick Blob and read into a Magick++ Image (I 
am using the C++ interface). Then the colour quantization is done.

I am only mentioning this in such detail because

a) It seems that the image size plays a role: the greyscale image is 
quantized correctly when first scaled to 128x128, but not with smaller 
sizes (96x96, 64x64, ...)

b) When scaling the original input image with "The GIMP" and then 
feeding it into "convert -colors 16" then the output is okay. Same when 
doing a "convert -rescale 96x96! -colors 16" which is also okay.

So the result seems at least somewhat depend on the size and how the 
image was scaled.

Or the "PNG" format as produced by Qt stores some weird information 
(colour space information?). But then again, as also already mentioned 
when saving the scaled Blob to disk in "PNG" the resulting image also 
produces the same wrong output when fed into "convert".

I hope these observations are of some use to anyone :)

> 
> That's a second bug, by the way; sometimes "convert" carries out the
> color quantization even if the image already has less than the required
> number of colors.

In my case I already do an explicit check for the number of colours 
before quantizing.

> With the help of a few other posters, we found that earlier versions did
> not show the problem.  

Me too succesfully converted the same input image with some very old 
"convert" (as shipped with some old SuSE 9.2 or something), 6.0.x, and 
it worked as expected, whereas the 6.3.5 produced the "black areas" with 
the same input image.

> It was only very recently introduced.  6.3.4
> seems to be OK, whereas 6.3.5 is not.  Secondly, there were no reports
> (either way) from linux users.  

I will try to get the 6.3.4 sources - thanks for the hint! Save me some 
wasted time doing "binary version search" (6.3.5 BAD, 6.0.4 GOOD, take 
the "middle version"... ;)


Good to know that it is an already known bug, so there's chances it will 
get fixed in one of the next versions

Cheers, Oliver