Bug: BMP are 32 bit should be 24 bit NOT TrueColorMatte

[codeslinger]

Hi,
This is my first post and I am a new user of Image Magick. I have done a lot of thrashing around and at this point am pretty sure it is a bug in IM/MagicWand rather than an error in my code. I was going to file this under the PHP section but in my search for answers I found that someone using TCL had a similar problem.

Summary: MagicWand_PHP produces invalid BMP files
Despite any settings that I make when saving the image, the ImageType is always "TrueColorMatte", which is not valid. The ImageType should be "TrueColor".

Version:

• ImageMagick-6.3.2-6-Q16-windows-dll.exe
• php5.2_magickwand_dyn.dll
• php 5.2

Code: Select all

Example: PHP

$x_resolution = $y_resolution = 300;
$im_cols = 4 * $x_resolution; 
$im_rows = 3 * $y_resolution;

$MagickWand = NewMagickWand();
$status = MagickSetImageType($MagickWand, MW_TrueColorType);
$status = MagickSetImageColorspace($MagickWand, MW_RGBColorspace); 
$status = MagickSetImageDepth($MagickWand , 8, MW_AllChannels);
$status = MagickSetImageFormat($MagickWand, "bmp"); 
$status = MagickSetResolution($MagickWand, $x_resolution, $y_resolution );

$status = MagickNewImage($MagickWand, $im_cols, $im_rows, "#ffffe0");

//draw some text.... "DrawAnnotation"

//set the properties again
$status = MagickSetImageDepth($MagickWand, 8);
$status = MagickSetImageType($MagickWand, MW_TrueColorType);
$status = MagickSetImageFormat($MagickWand, "BMP"); 

$status = MagickWriteImage($MagickWand, "c:/tmp/bad.bmp");

Even after all of that the result is:

Code: Select all

identify -verbose bad.bmp

Image: bad.bmp
  Format: BMP (Microsoft Windows bitmap image)
  Class: DirectClass
  Geometry: 2976x3876+0+0     (Note: the example above uses different dimensions)
  Type: TrueColorMatte
  Endianess: Undefined
  Colorspace: RGB
  Channel depth:
    Red: 8-bit
    Green: 8-bit
    Blue: 8-bit
    Alpha: 1-bit

This bug is important because it prevents you from being able to create printable images.

Eventually I found this article by Phillip Perkins which uses the same technique of printing a BMP that I was trying to use, and it obviously worked for him -- see listing "A" in His Article It's because of his article that I am certain this is a bug. I also found a TCL article discussing a similar problem with MagicWand creating 32 bit BMP.

As far as I know, Windows does not support transparent BMP, this is not a valid format. What I find is that on XP, mspaint.exe will open the file without complaint. However, GIMP complains of an invalid header and php printer_draw_bmp() rejects the BMP.

After much much thrashing around I find no way at all using MagicWand to create a 24 bit BMP. But from the command line, this works fine.

Code: Select all

convert infile.bmp +matte outfile.bmp

I found that command in an email thread where someone was saying they were unable to convert a gif into a 24 bit BMP. So, even from the command line it appears that there is a problem, but at least there is a way to fix/work-around it at that level.


Expected:

• TrueColor and other settings such as Grey should work
• Even if TrueColor is not specified the default behavior for BMP should be TrueColor
• Only under exceptional circuimstances should a TrueColorMatte BMP be created.

Thank You for creating such a Wonderful Program!
-- Erik

~

[codeslinger]

RLE does not work either, I get the same size file regardless.

Example:

convert infile.miff -compression RLE +matte outfile.bmp

[magick]

Try specifying your BMP image filename as BMP3:image.bmp. The BMP3 specifier forces the old-style BMP image format.

[codeslinger]

Try specifying your BMP image filename as BMP3:image.bmp. The BMP3 specifier forces the old-style BMP image format.

Wow!!! Thank You!!!!!! It Works!!!!

Now if we could just get this info added to the docs, that would be a big help. I have spent about 3 days just trying to understand/solve this one issue (you can't do windows printing without it).

Thank You!!!!

Code: Select all

//Here is the PHP MagicWand code for those who may not understand how to translate the above note:

$Result = MagickSetImageFormat($mw_Image, "BMP3");
$Result = MagickWriteImage($mw_Image, $FileName);

//And to print the file that you just created
$Result = printer_draw_bmp($hPrn, $FileName, 0, 0); //see the www.php.net/printer docs for details

P.S. I still maintain the position that the "Old-Style" format SHOULD be the default. Windows is pretty much the only place that the bitmap BMP format is used; and Windows XP does not accept this "New Style" BMP as being a valid file (and neither does gimp).

[anthony]

I have added (actually updated as it was present) note to the IM examples BMP image format section (still in rough draft).
http://www.imagemagick.org/Usage/formats/#bmp

I am not a windows user, so many of these formats could use examples, contributions and feedback from window users.

[steve0]

Very good! Glad to see it!

[el_supremo]

http://www.imagemagick.org/Usage/formats/#bmp

Anthony,
The paragraph that begins:
"However, the PNG file contains"
seems to imply that there is a previous mention of a PNG file in the #bmp section when there isn't.
I'd suggest changing "However" to something like "When converting PNG format to BMP,"

Pete

[sorin]

You'll find more information about 32BPP BMP files here: viewtopic.php?f=3&t=13633&p=46137#p46137

[mfulton]

It's perfectly valid to have 32-bit data in a BMP file. I'm not saying all Windows-based applications will support it, but it's a legal format.

The problem may lie in the expectation that having 32-bit data means that you have 24-bits of RGB and 8-bits of alpha channel. That may not be an unreasonable expectation, but it's not correct in this case. For 32-bit BMP files, the additional 8-bits per pixel are officially UNUSED. It's possible that some applications may use the extra 8-bits as an alpha channel, but that's not officially part of the specification. Any application that sees "32-bit" in the header of a BMP when it's expecting 24-bit should simply throw out the extra data.

So, if it's not an alpha-channel, why have the extra 8-bits per pixel? My guess would be that it's because a lot of early true-color capable video cards had 32-bit modes for true-color, rather than 24-bit. Probably because having pixels lie on 32-bit boundaries was convenient and fast from a programming standpoint. With 32-bit data, you could avoid a crapload of bitshifting when manipulating bitmaps.

By the way, I've read messages here that referred to the fileformat.info website as a source of information on the BMP format. Please be aware that the information on BMP given at that site is various times either misleading or just plain wrong, not to mention drastically overcomplicated. It's not surprising that someone would be confused if they were relying on that site. The original book it's based on came out in 1994, and the 2nd edition in early 1996, so it's likely this information was based on beta code and/or documentation, or just plain guesswork.

There are two big problems with the information on the BMP file format provided by the fileformat.info website. First is the way they confuse the fact that particular versions of Windows introduced extensions to the original BITMAPINFOHEADER structure with the incorrect idea that you were REQUIRED to use those extensions under those versions of Windows. For example, they seem to think that the WIN3XBITMAPHEADER structure is only used with Windows 3.x, and that programs running under later versions of Windows should use the newer versions of the structure.

This is absolutely not the case. Almost all BMP files use (or SHOULD use) the 40-byte BITMAPINFOHEADER structure, regardless of which version of Windows is involved. The longer BITMAPV4HEADER and BITMAPV5HEADER structures are VERY RARELY used and anybody writing code to create BMP files should probably avoid using them if at all possible.

The other big thing that adds to the confusion is the fact that their definition of the "BMP Version 3" and "BMP Version 4" formats, including especially the definition of the WIN4XBITMAPHEADER and WINNTBITMAPHEADER structures, seems to be a bastardized reference to Microsoft's BITMAPV4HEADER and BITMAPV5HEADER structures, and is simply not correct.

If anybody has been creating BMP files based on the WIN4XBITMAPHEADER and WINNTBITMAPHEADER structures defined on the fileformat.info website, they're certainly not VALID BMP files, even if they may open in some applications that are smart enough to simply ignore the extra fields that aren't part of the BITMAPINFOHEADER structure.

The definition of the BITMAPINFOHEADER structure that is used by the BMP format is given here:

http://msdn.microsoft.com/en-us/library ... S.85).aspx

The bottom of the page has links to the CORRECT definitions for the BITMAPV4HEADER and BITMAPV5HEADER structures.