Legacy ImageMagick Discussions Archive

EDIT: I changed the thread title to better reflect the issue. Please refer to my latest posts; the OP is kind of a digression.

PREAMBLE: This needs to be addressed, otherwise Visual Studio C++ developers cannot use transparent bitmaps into their .rc files. Like at all. Period. Zero. Hours of frustrated Googling and experimentation have proven that enough for me.

So, I need to be able to convert images of various formats into a very specific BMP format. To be very specific, I have run "identify -verbose my.bmp", where "my.bmp" has the correct format (which btw came with VS), and you can view that here: http://pastebin.com/2uWLSydd

So, it is a 32-bit RGBA BMP. Simple enough it would seem, right? Not at all.

Let's start with this PNG: https://cdn1.iconfinder.com/data/icons/ ... ngs-32.png

Download it, view it with your browser or whatever, and you'll see that it is a black image with a transparent background. Let's "identify" this PNG, which you can view here: http://pastebin.com/4FisQ7zn

Because it only has a black color, it only has 1 gray channel and an 8-bit alpha channel.

So now all we have to do is "convert" this guy, because ImageMagick is such a convenient and great program, right? Hopefully yes, but I haven't had any luck so far, even with these following commands:

convert a.png a.bmp
convert a.png -depth 32 -type truecolor config.bmp

even though I specify -type, I still get output along these lines: http://pastebin.com/RmFSdjds

<rant>
Also as a side note, GIMP cannot export to this format, neither can mspaint.exe, neither can Paint.NET, neither can the Visual Studio image editor. and no, I'm not going to risk my computer getting rootkitted into a botnet by pirating PhotoShop, so that's not an option either.

So, hopefully an ImageMagick guru can come along and prove me wrong that ImageMagick can in fact convert to this format, which will relieve some of the stress even though this issue shouldn't even been there in the first place, because I feel like an idiot Googling all over for the place for something so damn simple, yet Google comes up with absolutely nothing. For something so simple. Generally speaking when something doesnt appear on Google it means everybody else already knew how to do it, being that simple, YET NOTHING *** WORKED.

But I don't give up, I'm way too proud for that. I'm not going to settle for a non-transparent 24bit, just because it _should_ be really simple to get transparent bitmaps in 2016. So I hope the person still reading isn't too provoked by this type of language or it results in me getting banned or whatever, but my I don't give a *** meter has surpassed the limit by now. So, there you have it.

Also if I do get banned I'll probably just register again with a proxy tomorrow when I'm less ticked off.

[MOD note: two words removed.]

In general, IM will automatically down convert depth to the minimum for the pixel data. In otherwords, if there is only one channel and it is expanded to 3, the IM will know that all 3 are the same and classify it as bilevel or grayscale. I presume you need it to be SRGB.

I have no experience with this, but see going through PNM. http://www.imagemagick.org/Usage/formats/#bmp. You may have to download the NetPBM tools.

I tried the simpler of the two methods shown there. I do not have ppm2bmp.
But no luck.

Also see -define colorspace:auto-grayscale=on|off http://www.imagemagick.org/script/comma ... php#define. However, it does not seem to work with BMP or BMP3. This should be made into an enhancement so that it covers both PNM and BMP.

Perhaps one of the Windows users can comment further.

I'm unclear what the OP wants. A BMP with 3 colour channels plus alpha, each channel being 8 bits, so a total of 32 bits per pixel? Is that correct? If so, he has done that.
For me, IM 6.9.2-5 on Windows 8.1, x.bmp is 32 bits/pixel.

When IM reads an image from a file, it determines whether the image contains any pixels with colour. If it doesn't, then IM reports that it is grayscale. So IM can't be used directly to determine whether a file contains 3 colour channels.

To determine what a file contains, exiftool is more useful.

The OP has an identify verbose http://pastebin.com/RmFSdjds on file "config.bmp". We can make some deductions.
32*32 = 1024, so the number of pixels is okay. If the file contained gray + alpha channel, it would have 2048 bytes plus a header. If the file contained R+G+B+alpha channels, it would be 4096 bytes plus header. IM tells us there is no colortable. I forget how large a BMP header is, but it's quite small, when there is no colortable.

So my guess is that config.bmp has 3 colour channels plus alpha, which is what I think the OP wants.

Did you try to force IM to write the image in the BMP3 format?

By the way, "-depth 32" means RGBA with 32 bits per channel (128 bits per pixel) which isn't what you want.

@fmw42:

I will look into PNM later if I have to, though I do not see why an intermediate format has to be used for something apparently so simple.

@anibgo:

You are correct that "convert a.png a.bmp" will indeed produce a 32-bit BMP with transparency (GIMP displays the transparency just fine), however (our beloved) Visual Studio complains with exactly this:

Cannot load file.
Unknown bitmap format.

So there is something ImageMagick outputs in its BMP format (not just ImageMagick, but almost all image manipulation software) that Visual Studio does not like. For reference I will temporarily post the sacred "working" BMP here: https://drive.google.com/open?id=0B5A6n ... Ghid0FkWUE

(I would post it onto an image hosting site so the link does not become dead, but they might alter the data within their servers. If someone in the future is facing the same problem, they can obtain the sacred BMP from Visual Studio anyway.)

I downloaded and tried "exiftool", and it has brought to my attention that ImageMagick for whatever reason sets "Compression" in the BMP header to the value 3 (which means BitField compression), while the sacred BMP has Compression set to 0.

sacred BMP: http://pastebin.com/gxBSrDtn
IM output: http://pastebin.com/mWHvPbmJ

Looking back at the "identify -verbose" logs I posted earlier, "identify" says:

Compression: Undefined

even for the default output of ImageMagick's own "convert" program. And judging by the file size as you say, there indeed does not seem to be any compression going on at all.

Perhaps this is a bug? I would greatly appreciate if one of the IM developers can look into this.

@glennrp:

I tried "convert a.png bmp3:config.bmp", but it seems to be very obstinate about not creating an alpha channel. For instance, when I use the "bmp3" option, the resulting output file size is 3,126, where it should be over 4000. "-type TrueColorAlpha" does not work, "-alpha set" does not work.

ironically, the bmp3 correctly sets Compression to 0, which is what I want. Now only if I can both get an Alpha channel and compression=0, that would be very nice.

In either case, if this does not get resolved I will write my own C utility to do the damn conversion if I have to.

The most confusing issue out of all of this is how any Windows developer ever imported a transparent bitmap directly into their resource scripts. Like ever. Even in 2016. I guess they all pirated Photoshop. Or the corporate slaves all moved onto Windows Runtime and nobody gives a crap anymore.

Okay, I was able to solve my problem by creating my own C program to do some of the conversion manually.

TL;DR: ImageMagick developers, please provide a way to add an alpha channel for the BMP3 format.

Until that happens, I will provide my temporary solution.

First off, let's go over what happens when we do this:
According to the documentation, this will output a "version 4" BMP. However, some programs (such as our beloved Visual Studio) will choke on "version 4" BMP's. Visual Studio seems to be compatible with "version 3" BMP's (and it also happens to be the earliest version that supports alpha channels), so let's try converting to "version 3" instead:
However this is not enough, as ImageMagick does not preserve the alpha channel across the conversion. The ImageMagick "identify" command is kind of obscure, so let's get actual values from the BMP file headers for "dest.bmp" (which I got from a self-made program, more on this in a bit):
The important thing to note is that "bitcount" is set to 24, which means there is no alpha channel.

The original alpha data is not stored in "dest.bmp", so we convert a second time to a raw RGBA file to contain the actual RGBA pixel data:
Now, we use my self-made program to edit the "Bitcount" header field in "dest.bmp" (among other fields), then just copy in the pixel data from "dest.rgba", and we now have a working BMP3 file with an alpha channel.

Here is the code for the program: http://pastebin.com/CLkfWYLq (EDIT: fixed a bug, again)

It should compile with any reasonable version of Visual Studio or MinGW. It is not by any means error-prone, but gets the job done. It expects the filenames to be "in.bmp" and "in.rgba", and outputs "out.bmp".

see viewtopic.php?f=3&t=30068&p=135446#p135446. I am not sure that BMP3 formally allows transparency.

https://en.wikipedia.org/wiki/BMP_file_format

Ctrl+F for "BITMAPV3INFOHEADER" and it says:
It also says:
So in either case, ImageMagick is already supporting a format that is not "formally" documented, yet supports it anyway. The more important issue is supporting formats which other programs operate with, in this case Visual Studio 2015 (note the year), so it is very far from being obsolete or obscure.

OK. So it is now back to the IM developers to comment further.

First and last bump of this topic, which I think is well deserved. Though unfortunately it appears that they won't really take action, unless they are provided some kind of source code patch, I presume.

I responded in that bug report that Fred created here: viewtopic.php?f=3&t=30068&p=135446#p135516. The feature to add an alpha channel to a BMP3 image has been available for a while.