GNOME Bugzilla – Bug 697431
32bit BMP file of αlpha channel is not recognized
Last modified: 2018-05-24 13:39:33 UTC
Alpha channel does not recognize it and to read BMP files of 32bit In addition, even if the export by selecting the 32bit BMP (A8 R8 G8 B8) α is not stored. Portable, Linux, both.
*** Bug 697430 has been marked as a duplicate of this bug. ***
Please, can you attach here an XCF file and the resulting BMP export showing the bug. Also, how do you know that the alpha channel is not stored? I mean, what software do you use? Thanks!
Created attachment 240846 [details] (Image in the center is transparent circle) read in GIMP28
Created attachment 240847 [details] (Image in the center is transparent circle) created in GIMP26
Created attachment 240849 [details] (Image in the center is transparent circle) created in GIMP28
Created attachment 240850 [details] (Image in the center is transparent circle) created in GIMP26
report in detail There is a clear circle in the center of all images GIMP26.bmp create GIMP2.6 > GIMP2.6 read OK / GIMP2.8 read NG(alpha channel loss) GIMP28.bmp create GIMP2.8 > GIMP2.8 read OK GIMP28-create.xcf create GIMP2.8 GIMP28-READ.xcf read GIMP26.bmp Adding read the images created in other tools bmp(RGBA) GIMP26 > alpha is not lost GIMP28 > alpha is lost
Thanks. First, among all three bmp files attached here, only 240849 is a "real" 32bpp-RGBA file. It's a BITMAPV5HEADER BMP file. The two others files are ambiguous since BMP specification (BITMAPINFOHEADER) is not clear about the alpha channel in 32bpp files. There is no way to know if 4th channel bits must be read or ignored. Thus it's best to ignore the extra bytes and this is what GIMP 2.8 does. Unfortunatly, it seems that previous versions of GIMP were only saving BMP using BITMAPINFOHEADER, so in a file format that doesn't explicitly support 32bpp RGBA. I am not sure about what should be done here, if something should be. PS : It seems that Firefox doesn't handle BITMAPV5HEADER's ChannelsMasks correctly...
Created attachment 267483 [details] a valide bmp that GIMP can't read.
Hi, I can't read this file TestImTyrfiomokifavuigapipaumipau50Std.bmp with GIMP 2.8.10 under Windows.
@Lesbros: Thanks for reporting this :) It was not related to the handling of the alpha channel though. Fixed in 2.8 and master. commit 76ee47eff95e8dfad303d473c8a54b15720c83c0 Author: Téo Mazars <teomazars@gmail.com> Date: Thu Jan 30 20:31:26 2014 +0100 plug-ins: don't check biClrUsed if bpp > 8 (in bug 697431) (cherry picked from commit 54f83a5ba273e45a9184f13d1f4b0f5697d56555)
Reopening. Please handle unrelated issues in new bug reports.
Why reopening? I thought Téo fixed the bug (comment 11)?
Lesbros' comment and Téo's patch were unrelated to the original bug report, apparently.
My Gimp 2.8.2 Linux works fine, but my Windows 2.8.4 ignore the alpha channel. Regression?
2.8.4 is old. Please try the latest stable release and report back if you still think there is something wrong.
Still applies to a freshly downloaded and installed 2.8.10 Windows.
So, I guess Comment 8 applies to your issue too? You can paste a small image showing the bug if you want to make sure.
OK, the image wih which I can reproduce the problem has a BITMAPINFOHEADER (40 bytes), so case closed. But the best course of action should not be to discard bytes... may be the user could be asked what to do?
This is feasible, but then all users would be asked each time they open a BITMAPINFOHEADER-32bpp image (95% of bmp images in the wild) if they want or not to discard the 4th channel... Does it worth the cluttering? It doesn't in my opinion, but that's just an opinion.
Why is this bug NEEDINFO?
I don't know, isn't you that put the NEEDINFO status? Otherwise the right status "What do we do with that issue".
Argh, "... the right status would be ..."
Indeed :)
Given Comment 20, I'd think the correct course of action would be to simply always load the alpha channel from a BITMAPINFOHEADER if present, but save properly as a V5 upon export. Ignoring bytes is obviously the wrong answer if it cuts off data for 95% of BMPs in the wild. What I've read is that GIMP is supposed to be tolerant on import but exact on save/export. What reason is there to expect that there would be data that is intended to be discarded? If there is any such reason, is there not some way to tell if it would make sense as an alpha channel instead?
The problem is not the data to be discarded, but an ambiguity between ARGB and XRGB formats. Which uplimately leading to image corruption, if mishandled.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/461.