Legacy ImageMagick Discussions Archive

32bit RGB Files can use ARGB or XRGB format. You can use GIMP to load a 32bit PNG file (with alpha channel) and save it as a 32bit BMP image using one of the two options.

It looks like ImageMagick is not able to differentiate between the two formats and that it is not able to generare ARGB BMP files.

Why is this so important? ... Because Windows API is not able to load XRGB but is able to load ARGB files.

I've made some tests using GIMP and make a diff between the results of "identify --verbose" on the two formats. It looks like the only difference seen by ImageMagick is that XRGB contains Gamma information.

Solving this bug would solve this old issue viewtopic.php?f=6&t=8518

Example files:
http://nusunt.eu/download/mfc/test_gimp_argb.bmp - the one that is supported by Windows API
http://nusunt.eu/download/mfc/test_gimp_xrgb.bmp - the one that doesn't work with Windows API

Additional remark: Photoshop is able to load correctly the alpha channel from ARGB sample but not from the XRGB.

Due to this, I think the default 32 bit BMP output format for ImageMagick should be ARGB.

I don't know much about BMP format, but have you read http://www.imagemagick.org/Usage/formats/#bmp
and tried

convert image.png BMP3:image.bmp

Sure, It was the first thing I checked but didn't helped. Information from this page is incomplete. It's true that Windows doesn't support BMP4 - Depth 32 aka TrueColorMatte but it does support ARGB a BMP3 (24bit) that does keep the alpha channel information separate (i suppose it's a chunk or something similar).

ImageMagick is loosing alpha channel when loading BMP/ARGB files and is not able to save them.

Gimp is able to save ARGB but loading the file back in Gimp doesn't load the Alpha channel inside.
But if you load the ARGB file in Photoshop it will load the Alpha channel as a separate channel but not "active" by default.

Look for a patch in ImageMagick 6.5.1-8 available sometime tomorrow. ImageMagick writes RGBA which Windows programs can grok (mspaint, Firefox, etc) without complaint but gimp chokes.

Thanks, this is great!

Maybe we'll be able to document the BMP format a little bit more as I am still a little bit confused about the BMP versions defined in different sources like:
http://en.wikipedia.org/wiki/BMP_file_format
http://www.imagemagick.org/Usage/formats/#bmp
http://wvnvaxa.wvnet.edu/vmswww/bmp.html
http://msdn.microsoft.com/en-us/library ... 85%29.aspx -BITMAPV5HEADER
http://msdn.microsoft.com/en-us/library ... 85%29.aspx BITMAPV4HEADER

If I manage to figure it out them I would like to update the Wikipedia page and the ImageMagick documentation regarding this - I'm sure I'm not the first one having this issue.

I would like to be able to build an application compatibility matrix for most important of them (24 and 32 bit ones).

I tried with the new build and no luck.

In order to narrow down the issue I did create a table with the compatibility between different applications.

Please take a look at https://spreadsheets.google.com/ccc?key ... C2gw&hl=en
New additions to the spreadsheet are welcome

We assume compatibility if the BMP images ImageMagick creates can be read / displayed without complaint by Windows (i.e. mspaint, etc.). If you can identify a BMP image, ImageMagick creates that is not read / displayed properly under Windows, let us know. If Gimp fails to grok an image that ImageMagick creates that Windows has no problems with, we assume a bug in Gimp.

magick wrote:We assume compatibility if the BMP images ImageMagick creates can be read / displayed without complaint by Windows (i.e. mspaint, etc.). If you can identify a BMP image, ImageMagick creates that is not read / displayed properly under Windows, let us know. If Gimp fails to grok an image that ImageMagick creates that Windows has no problems with, we assume a bug in Gimp.

I agree with you about ImageMagick: BMP generated must be Windows-friendly - this being mostly a Windows format.

But there is a catch here: support for BMP under Windows is not consistent across OS.

I identified at least these areas to test:
* LoadBitmap (Windows API) - essential to be compatible because BMP are mostly used as UI resources.
* Visual Studio Resource Editor (this is not very important - MS can fix their own bugs on this).
* MS Paint
* Windows Picture and Fax Viewer
* Internet Explorer (different versions!)
Also we should consider XP and Vista.

We try to fix all bugs posted in this discussion forum once we agree there is indeed a bug. Given that, let us know if you find particular instances of BMP images that is proven to be correct with the Window applications you listed that ImageMagick cannot read or BMP images ImageMagick creates that the Window applications you listed cannot read. Post a URL to the image here and we will investigate and apply a patch to ImageMagick if warranted.

I made some additional tests and included the results inside the spreadsheet.

My personal conclusion is that the Gimps has the advantage of being able to save much more windows-compatible 32bit BMP files (using ARGB option)

Comparing ARGB from Gimp with default BMP option from ImageMagick there is no case where ImageMagick would be better.

This looks like the BMP generated by ImageMagick are buggy and that we should look at Gimps code for saving BMP files.

On the spreadsheet there are links to all types of BMP files.

If you like I could write a simple win32 application you can use for testings if the LoadBitmap (Windows API) is accepting the BMP file or not.

The only way to test if Windows (XP) is accepting a transparent BMP file (32bit) is by using the LoadBitmap - all other Microsoft applications are not able to show if the transparency information was recognized or not.

If you like I could write a simple win32 application you can use for testings if the LoadBitmap (Windows API) is accepting the BMP file or not.

Yes please. We're Linux developers and whenever we develop under Windows we find ourselves excessively washing our hands.

magick wrote:Yes please. We're Linux developers and whenever we develop under Windows we find ourselves excessively washing our hands.

I tried to make a test app but I wasn't able to do it becase the only Windows API function that does load 32bit BMP without loosing the alpha channel is from ImageList - an that is loading only from the resources.... this would require you to embed the test.bmp image in the resources and I think you don't want to recompile the app for this.

I tried another aproach, take a look at this archive
http://nusunt.eu/download/mfc/sample_bmp.zip

It does contain a very simple BMP file that works and it's IM version of it. Archive contains also a diff-image of the file (hex) (the entire sample BMP file is only 118 bytes)

Does this help?

We anticipate testing your application in 3-4 days. Will report back then.

I managed to create a test application, it is here: http://nusunt.eu/download/mfc/bmp_test_win32.zip

if it does give you an error at launch, install the vc redist package included in the archive.

Your hex dump reveals that Gimp produces a version 3 BMP image whereas ImageMagick produces version 4. For a description see http://www.fileformat.info/format/bmp/egff.htm. ImageMagick is creating improper BMP images only if it violates the specification. We will investigate further but so far our hex dumps suggests the resulting BMP image format is proper. Stand by for further analysis.