GNOME Bugzilla – Bug 352262
32bit bitmaps (*.bmp) appear blank
Last modified: 2007-01-05 19:55:21 UTC
I've opened simple 32 bit window icon without alpha channel. Image appears all blank (all pixels transparent).
Created attachment 71312 [details] Bitmap to recreate the bug. This is a simple 32 bit windows bitmap. It can be opened correctly with any windows/linux image viewer. However, it appears blank after opening in gimp.
There might be a bug in the BMP plug-in when it comes to interpreting the alpha channel, but I would first like to have evidence that this file is correct and does indeed have a fully opaque alpha channel. The other image viewers might just ignore the alpha channel. At least the viewers that I tried seem to ignore it.
identify lists only three channels.
I guess (and that's really just a guess), that the image data is written correctly but that there is a field in the header which isn't written correctly.
I was creating various test cases using PS to recently update bmp plugin. If I didn't mess up it should be in X8R8G8B8 format. So my guess is that x channel, which is actually unused, is interpreted as alpha.
Having bothered you, I had to remake the tests with PS. I created new image, did some drawing, ensured that there is no alpha channed. When saving PS didn't allow to export Alpha Channel as it doesn't exist. I chose 32 bit bitmap. Then I opened the same image using the same PS and guess what. Alpha channel magically appeared. So sorry for bothering you with this "not bug".
GIMP 2.2 does load this image without an alpha channel and non-empty RGB channels. GIMP 2.3 does load this image with RGBA channels being empty. So there is a difference. I'm not sure if I understand comment #6 correctly, but IMO this isn't NOTABUG. Please provide a detailed description of what you expect to be in the image and how it should be shown.
I wanted to say, that the image most likely had an alpha channel. I believed it didn't because I didn't create one while exporting the image (I created the image with PS). It's really hard to find out for sure because of complete ignorance of alpha channel in many windows (and Linux) apps. On Win (and Linux too) it appeared as I expected. I saw all pixels because alpha channel didn't mask them out. But ignorance of alpha channel in other apps isn't correct behaviour. So I thing Gimp handles alpha channel correctly. Maybe the question is: should Gimp be right, or deal with traditional ignorance of many applications (see comment #2).
Perhaps we should have a look at the BMP file format specification (assuming that there is such a beast).
http://wvnvaxa.wvnet.edu/vmswww/bmp.html has a number of example images that might be worth to check out.
The BMP test suite at http://entropymine.com/jason/bmpsuite/ has two 32 bit BMP files. One seems to load correctly (g32bf.bmp), the other appears blank even though it doesn't have an alpha channel (g32def.bmp). Only BMP version 4 (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmaps_2k1e.asp) and version 5 (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmaps_7c36.asp) define an alpha channel. Images saved in version 3 and below should never be interpreted as having transparency.
I am afraid we need to put this on the 2.4 milestone. We should make sure that we ship GIMP 2.4 with a BMP file plug-in that correctly loads BMP files and, even more important, writes correct BMP files. If this can't be achieved, we will have to ship GIMP 2.4 with the old BMP plug-in.
> Images saved in version 3 and below should never be > interpreted as having transparency. It is possible to use to use version 3 bitmaps with alpha channel as textures in game development. I don't know if someone does. If so, it would be nice to show a dialog before opening an image. We should find out if someone uses this feature. I have tested many other formats with the new bmp plugin. They all worked as expected, except the one in the attachment. All other bitmaps with alpha work correctly. Maybe just fixing this case will be better than falling back to the old plugin? I have noticed, that whenever pixel's alpha value becomes 0, the pixel becomes black (color is lost). This happens while opening an image or just working with alpha channel. Is this the intended behaviour? If so, can anyone explain why?
As far as I understand the specification, there are no version 3 bitmaps with alpha channel. If someone is abusing the extra bits as an alpha channel, that doesn't mean that GIMP should interpret them as such. Or worse, that GIMP should create such files. I don't understand your last comment. GIMP doesn't dismiss the color information of transparent pixels.
> I don't understand your last comment. GIMP doesn't dismiss the color > information of transparent pixels. > I open bitmap with alpha and all the pixels which had alpha value = 0 were black in channel list, although they had colors. I hacked bmp loading plugin and forced alpha = 1 (nearly transparent) and all the channels (RGB) contained correct colors. Similar behaviour was caused when I erased transparency with Color to Alpha. Gimp version: current cvs.
That's a misinterpretation. Try to anti-erase (that's an option in the eraser tool).
Created attachment 71618 [details] [review] Disable alpha when reading version 3.x 32bit bitmaps This patch disables alpha while reading 3.x version 32bit bitmaps. Other versions which do not cause trouble can still load transparent images (like 1A5R5G5B). It also add the ability to load version 4 and 5 bitmaps. Transparency is ignored, like most web browsers do.
Hmm, but the alpha channel is still written to the file and the plug-in still claims that it could write an alpha channel and also offers the format "A8 R8 G8 B8" which pretty much looks as if it had an alpha channel. Perhaps we should try to clarify what behaviour we actually want to implement before the code is changed and patches are written.
I made this patch to read all the bitmaps that were mentioned in this discussion correctly. I tested and it seems it works well on all of them. According to recommendations, 3.x bitmaps are loaded without transparency. Version 4.x and 5.x might have alpha channel but it is ignored. As I understand from microsoft forums, this is a legal fallback support (to read only 3.x header). It would be nice to open them with alpha, gamma, etc., but we can leave that for the future. Saving code is separate from loading code.
There is a little problem with my patch: the whole version 4.x and 5.x header should be read, so that palette could be read directly after it. I'll try to create some testcases and fix that tomorrow. While looking for documentation I've found Programming Windows, 5th Edition (Charles Petzold - MS Press) useful. > Perhaps we should try to clarify what behaviour we actually want to implement > before the code is changed and patches are written. Possible behaviour: * [no alpha] Open any of the available formats, ignoring alpha channel. Save without displaying any dialog, automatically choosing either 24 bit or 8bit depth. * [with alpha] Open bitmap with alpha if it exists. If we have the problem case (32bit 3.x), display a dialog with thumbnails of 2 images for a user to choose: with alpha and without. We could possible use some deduction by testing if there is at least one alpha value non-zero. Saving image with color palette should offer to choose 1, 4, 8 bits/pixel, and whether to use RLE compression. Saving RGB image should offer 16, 24, and 32 bits/pixel. Allow advanced saving modes (maybe hidden first from users who could get confused.) Do we need support for flipping row order? Saving in 4.x and 5.x bmp formats?
I think someone needs to summarize the situation, without going into implementation details, and bring the issue up on the gimp-developer mailing-list. Such a summary should include pointers to the spec or other information about the file format.
Aurimas, you could help us a lot by trying to do what I suggested in comment #21. We need to settle this so that we can release 2.4.
In regards to part of comment #21, the BMP specifications can be found at http://www.fileformat.info/format/bmp/. I'm not sure how up-to-date it is but it does go up to version 4 in the BMP formats it covers.
Created attachment 79476 [details] [review] Bmp alpha fix Implements solution to use the alpha channel if and only if a bitmap contains at least one non-zero value as suggested by Raphaël Quinet.
2007-01-05 Sven Neumann <sven@gimp.org> * plug-ins/bmp/bmpread.c (ReadImage): applied patch from Aurimas Juška. Use the alpha channel if and only if a bitmap contains at least one non-zero value. Fixes bug #352262.