Bitmaps produced with 7.0.7 have no compression and have incorrect bit-depth in the header (Worked as expected in 7.0.6)

[Jools]

I've been using imagemagick to create 8-bit bmp icon strips from pngs. After updating to 7.0.7 I found that the application using the strips began asserting that the strips were actually 24-bit.

Here's the command I'm using to create the strips. I use 7.0.6 to create old.bmp and 7.0.7 to create new.bmp

Code: Select all

"C:\Program Files\ImageMagick-7.0.6-Q16\magick.exe" icon1.png icon2.png +append -mosaic -type Palette -depth 8 -chop x15+0+15 BMP3:old.bmp

"C:\Program Files\ImageMagick-7.0.7-Q16\magick.exe" icon1.png icon2.png +append -mosaic -type Palette -depth 8 -chop x15+0+15 BMP3:new.bmp

"C:\Program Files\ImageMagick-7.0.7-Q16\magick.exe" identify old.bmp
old.bmp BMP3 32x15 32x15+0+0 8-bit sRGB 256c 1588B 0.000u 0:00.000

"C:\Program Files\ImageMagick-7.0.7-Q16\magick.exe" identify new.bmp
new.bmp BMP3 32x15 32x15+0+0 8-bit sRGB 1494B 0.000u 0:00.000

Both strips claim to be 8-bit when using "magick identify". However the bitmap header of new.bmp seems to contradict this. If I open the images in a hex editor, you can see that that the 28th byte is 0x18 (24) rather than 08. Windows details also list the bit depth as 24 for the new.bmp, though I don't trust that as it lists a bit depth of 32 for old.bmp event though it's visibly 08 (endiannness or bitmap format issue?)

One odd (possibly unrelated) difference between the old and new images is that the new images use no compression, whereas the old ones used RLE. Even explicitly adding the option "-compress RLE" seems to have no effect on new images. That said, I'm not too bothered by the increase in some file sizes, as they were tiny to begin with. It's more the weird header that I'm worried about.

[magick]

We tried your command and it returned a paletted image as expected:

Code: Select all

$ convert logo: rose: wizard: +append -mosaic -type Palette -depth 8 -chop x15+0+15 bmp3:test.bmp
$ identify test.bmp
test.bmp BMP3 1190x625 1190x625+0+0 8-bit sRGB 256c 233642B 0.040u 0:00.040

Perhaps the problem is specific to your images. Can you post a URL to your images and we will download them and attempt to reproduce the problem you reported.

[Jools]

As requested, input:
https://www.cyberscience.com/icon1.png
https://www.cyberscience.com/icon2.png
output:
https://www.cyberscience.com/old.bmp (7.0.6)
https://www.cyberscience.com/new.bmp (7.0.7)

[magick]

Thanks for the problem report. We can reproduce it and will have a patch to fix it in GIT master branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ https://www.imagemagick.org/download/beta/ by sometime tomorrow.

[Jools]

I've just installed the latest beta (ImageMagick-7.0.7-22_beta20180113-Q16-x64-static.exe) and I'm seeing the same (wrong bit depth) behaviour with the aforementioned test case. Am I missing something?

[magick]

We get

Code: Select all

$ magick icon1.png icon2.png +append -mosaic -type Palette -depth 8 -chop x15+0+15 BMP3:old.bmp
$ identify old.bmp 
old.bmp BMP3 32x15 32x15+0+0 8-bit sRGB 256c 1588B 0.000u 0:00.000

Is that not expected results?

[Jools]

If you take a look at my original post, the issue with bit depth never showed up in the output for "magick identify". The problem only appears in other applications (e.g. Windows explorer), which identify it as 24-bit, because that's what bitmap header says. I don't know where "magick identify" gets its info from, but if you opened the output file in a hex editor, the 28th byte said 24. ( You can test this with https://www.cyberscience.com/new.bmp )

That said, I'm still getting the old "magick identify" output (without compression). Has the fix maybe not made it into the beta yet?

Code: Select all

"C:\Program Files\ImageMagick-7.0.7-Q16\magick.exe" icon1.png icon2.png +append -mosaic -type Palette -depth 8 -chop x15+0+15 BMP3:new.bmp
magick identify new.bmp
new.bmp BMP3 32x15 32x15+0+0 8-bit sRGB 1494B 0.000u 0:00.000

If the date in the "version" output is correct, I guess not.

Code: Select all

"C:\Program Files\ImageMagick-7.0.7-Q16\magick.exe" -version
Version: ImageMagick 7.0.7-22 Q16 x64 2018-01-07 http://www.imagemagick.org

[Jools]

I just tried ImageMagick-7.0.7-22_beta20180114-Q16-x64-static.exe and I'm getting the same old output.
I was wondering if I should be using the dll version, but I couldn't find one on the beta list:
https://www.imagemagick.org/download/be ... 64-dll.exe

[Jools]

Ah, it looks like the Windows build is broken. That'll be why I'm not seeing the changes.
https://ci.appveyor.com/project/dlemstr ... ws/history

[Jools]

The master Windows build is now fixed and I can confirm that this issue is resolved and working as expected with the following version:

Version: ImageMagick 7.0.7-22 Q16 x64 2018-01-21