Bug in reading of BMP V4 and V5 files

Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
Post Reply
Drarakel
Posts: 547
Joined: 2010-04-07T12:36:59-07:00
Authentication code: 8675308

Bug in reading of BMP V4 and V5 files

Post by Drarakel »

When ImageMagick has to read Bitmaps with a Windows V4 or V5 header, these get handled wrongly. IM always assumes an alpha layer - even if there is none.

Example:
convert rose: -profile sRGB.icm rose.bmp
(The color profile is there, because it will trigger the creation of a V5 BMP.)
'identify -verbose rose.bmp' says:
Type: TrueColorMatte
Colorspace: RGB
Depth: 8/16-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
alpha: 16-bit
...
Alpha:
min: 0 (0)
max: 1 (0.00303655)
mean: 0.000240472 (9.43027e-007)
...
The problem here aren't the strange alpha values (I mostly get a fully opaque alpha layer), but the appearance of an alpha layer itself. 'rose.bmp' shouldn't have and actually doesn't have any transparency. (I checked the filesizes, the header values etc. - it's 3x8bit=24bit per pixel.) So, the writing of V4 and V5 BMPs is ok. But the reading of those files is not. After another convert in this example (convert rose.bmp rose2.bmp), the alpha layer gets real and a BMP (V4) file with 4x8bit per pixel gets written.
You can find another example in this thread.

This is with IM v6.6.1-5 Q16, Windows XP.

Besides:
The BMP part in the documentation is probably not up-to-date?
http://www.imagemagick.org/Usage/formats/#bmp
What I got in my tests:
The default in ImageMagick is the writing of BMPs with a V3 header. An alpha layer/transparency in the input or e.g. a gAMA chunk in a PNG 'triggers' the writing of BMP V4 files. When there's a color profile involved or one has a PNG with a sRGB chunk, a BMP V5 gets written. (A PNG with only a cHRM chunk still gets written as BMP V3. I first thought, that with gAMA, a V5 file is written - but here it's indeed V4.)
The format 'BMP3:' always forces the use of Windows V3 headers. 'BMP2:' will always write a file with an OS/2 V1 header. (I'm not an expert in the BMP format. You may correct me.) With 'BMP:file.bmp', one gets usually the same output as just with 'file.bmp'. (It's probably a bit more complicated. For example, when one has a BMP V5 file, and there's something 'valuable' in the additional V5 fields - e.g. a rendering intent value - and one does another "convert input.bmp output.bmp", the output.bmp is again V5. But with "convert input.bmp BMP:output.bmp", this value is omitted and a V4 file gets created.)

Anyway.. Whenever a BMP V4 or V5 file gets written, these extra alpha layers 'pop up'. :-|
User avatar
magick
Site Admin
Posts: 11064
Joined: 2003-05-31T11:32:55-07:00

Re: Bug in reading of BMP V4 and V5 files

Post by magick »

We can reproduce the problem you posted and will have a patch in the next ImageMagick point release. Thanks.
Drarakel
Posts: 547
Joined: 2010-04-07T12:36:59-07:00
Authentication code: 8675308

Re: Bug in reading of BMP V4 and V5 files

Post by Drarakel »

Thank you!
Post Reply