GNOME Bugzilla – Bug 573090
GIMP assumes 32-bit BI_RGB bmp files have alpha in the undocumented byte
Last modified: 2012-10-08 03:51:14 UTC
Please describe the problem: Hello all, This is an old and unresolved problem, may be because nobody submits to you this bug. I use VirtualdubMod to export some snapshot image from some videos, I export them in BPM format. When i open this files with gimp some times, doesn't open correctly Steps to reproduce: 1. use virtualdubmod to export some snapshot image frames from any video 2. 3. Actual results: Expected results: Does this happen every time? not every time Other information:
Hi, please attach a file that is as small as possible but still can be used to reproduce the problem.
Created attachment 129495 [details] there are two image files
I can confirm this with GIMP 2.6.5 on Windows. Seems to be different from the usual "application writes alpha channel to BMP because it does expect this to not be supported" - or maybe Virtualdub uses this to encode some information?.
so it's possible to resolve this problem on gimp? I actually use paint to export a tif and than i open it with gimp. paint loads correctly that bmp file.
The case here is that the file-bmp plugin assumes that the bmp file, which is of the kind with biBitCount=32 but biCompression=BI_RGB, has alpha in the "extra" byte of each pixel. In fact the bmp has something random (or virtualdub-specific, as Michael said) in the "extra" byte. It's hard to say which one is the correct interpretation of the "extra" byte in 32 bit per pixel BMPs biBitCount=32, biCompression=BI_RGB bmp files. Presumably it is common to use it for alpha, why otherwise would the file-bmp plugin's code make such an assumption? Or is this assumption unfounded? (As a comparison, the gdk-pixbuf loader for bmp does not make any such assumption.) Anyway, it is simple to "fix" the image in GIMP: Select only the Alpha channel in the Channels dialog, select all of the image, fill with white.
My personal opinion is that 32-bit BI_RGB BMPs should be avoided at all cost, exactly because the format is so underspecified. Does VirtualDub not offer PNG? Or 24-bit BMPs?
Toni, please do open a bug report in Virtualdub's bugs forum, too.
As there are BMP files that actually make use of the alpha channel, it seems like the best choice to support this when loading. It is simple enough to discard the alpha channel. We could add a dialog asking the user what to do whenever a 32bit BMP file is encountered. But I'd vote for closing as NOTABUG.
Here is a link to some bitmap files to test: http://wvnvaxa.wvnet.edu/vmswww/bmp.html The transparent image uses bitfields to indicate that it make use of the alpha channel. Because the plug-in currently writes bitmaps wrong assuming the same as when reading bitmaps, fixing this bug will make the plug-in unable to read some files from older versions. The solution is to use bitfields when writing/reading 32-bit images if they use the alpha channel. Also, provide a batch converting utility to convert files from older versions. I found another intresting detail about indexed files. It is possible to interpret colors not in the palette as transparant without breaking compatibility with other files. However, this assumes that every other application does check bounderies when looking for colors in the palette. Another way to implement it is to use all four values in each color together with the masks. Conclusion: use the masks when dealing with transparancy. The current plug-in is unable to read BITMAPV5HEADER. The transparent image at http://wvnvaxa.wvnet.edu/vmswww/bmp.html uses BITMAPV4HEADER, which is 108 bytes. This is not a bug but a feature request but implementing this makes it possible to test all cases listed at this page. Currently, I am working on a bitmap file reader for another project. I will submit the source here when I am satisfied with it. I will also copyleft it so you may use it if you want to. Should I try to fix the plug-in also?
BTW. I think it is quite important to fix this bug before we have a lot of wrong files.
A patch for the GIMP BMP plug-in would very much increase the likelihood that this issue will be addressed.
*** Bug 619843 has been marked as a duplicate of this bug. ***
*** Bug 674398 has been marked as a duplicate of this bug. ***
Fixed in master: commit 610aac1dacdebe4e6bf52d669ce060585f010454 Author: Mukund Sivaraman <muks@banu.com> Date: Mon Oct 8 09:12:17 2012 +0530 file-bmp: Don't use alpha channel with BI_RGB compression type Don't use alpha channel with BI_RGB compression type in BITMAPINFOHEADER images (bug #573090, bug #674398). commit a19bbee5cb093c85f4da4f091836dabb11424aa8 Author: Mukund Sivaraman <muks@banu.com> Date: Mon Oct 8 08:47:17 2012 +0530 file-bmp: Reject compression type BI_ALPHABITFIELDS as unsupported These were erroneously parsed before. Now we reject them. It is trivial to implement support for them, but we can't test it unless someone comes up with a sample BMP file. They don't seem to be available in the wild. Fixed in gimp-2-8: Author: Mukund Sivaraman <muks@banu.com> Date: Mon Oct 8 09:12:17 2012 +0530 file-bmp: Don't use alpha channel with BI_RGB compression type Don't use alpha channel with BI_RGB compression type in BITMAPINFOHEADER images (bug #573090, bug #674398). commit 49debcafdc38e8b14e4a8ca890cfe193fdf1fa99 Author: Mukund Sivaraman <muks@banu.com> Date: Mon Oct 8 08:47:17 2012 +0530 file-bmp: Reject compression type BI_ALPHABITFIELDS as unsupported These were erroneously parsed before. Now we reject them. It is trivial to implement support for them, but we can't test it unless someone comes up with a sample BMP file. They don't seem to be available in the wild.
Resolving as FIXED, milestone 2.8.