I think that this is definitely a bug as there is other associated buggy behavior whenever this error occurs.
What happens is that the output files created from a monochrome conversion are sometimes abnormally bloated in size whenever you hit this error and a compressed output file is produced and sometimes a zero length file also appears.
Logically an all white image should compress very small but instead, the compressed file is actually larger than it would be if there were no compression at all indicating that something is going seriously wrong under the covers and that the all-white image isn't by design of the color quantizing methods. At other times, depending on what image format is used as the source image the compressed file is zero length and therefore invalid.
Let me demonstrate - if you take the two sample images I uploaded before:http://drop.io/ImageMagickBugSampleImages
-> ImageMagickBugSampleImages.zip -> pic1.bmphttp://drop.io/ImageMagickBugSampleImages
-> ImageMagickBugSampleImages.zip -> pic2.bmp
and run these commands:
convert pic1.bmp pic1.tif
convert pic2.bmp pic2.tif
convert pic1.tif -compress Group4 pic1a.tif
convert pic2.tif -compress Group4 pic2a.tif
You will find that the after doing a straight uncompressed BMP to uncompressed TIF convert you will have four files all of about 11mb as expected (pic1.tif, pic1.bmp, pic2.tif & pic2.bmp)
Once you convert the new uncompressed TIFF files to monochrome Group4 TIFF files pic1a.tif becomes zero length while pic2a.tif is valid 400kb file. No TIFF file should be Zero length as this isn't valid even for an all-white image.
This result isn't always found when I run this on several machines so it may be likely you can reproduce this exact problem.
As I stated earlier, at other times with other images all-white images are made massive when they should be 1kb and also, curiously, sometimes when the conversion is going OK and there is a valid B&W image, the compressed file is many times larger than it should be and requires re-compression.
What is more reproducible is the bloating bug - for example take this image I've just posted online:http://drop.io/ImageMagickBugSampleImages
Now try this command:
convert pic3.tif -compress Group4 pic3a.tif
You will end up with a 654KB file - a funny co-incidence as I find many files convert to this strange size (strange given that the file is all white and always 654kb on the images I'm testing with).
identify -verbose pic3a.tif
Shows this is a Group4 file.
identify -format "%k" pic3a.tif
Shows a unique color count of 1.
Re-saving the file with Irfanview as a 2248x1625 Group4 TIFF creates a 440 byte file as expected.
Saving the file as an uncompressed mono BMP yeilds a 450kb file making the 654kb file seem bloated even for an uncompressed format.
I look forward to hearing you comments on these findings, along with any ideas on good primers on how the ImageMagick source code is structured so that I might be able to look at this myself.
Maybe there's something going wrong between the rendering pipeline and the save routine? Just a thought.