Confirming.

IMO, this file plug-in has seen to many changes because of these "whaaaaaa! my (broken) app doesn't support your bitmaps (because they're V5) GIMP is borken!!!11!"

Can't we just revert all those changes and switch back to the V5-exclusive version which worked fine?

Duplicate of bug #573090?

I can confirm this issue. Exporting to 32-bit 32-bit Windows BMP files using RGBA channels causes pixels with the RGBA values 0,0,0,0 to turn into 0,0,0,255 - the alpha channel is ignored. Exporting to Windows BMP using RGBX causes pixels with the RGBA values 0,0,0,0 to turn into 0,255,255,255. See this attachment:

http://rvzt.net/Temp/Test%20Image.tar.gz

I can confirm this too, tested with the attached image as well as another, on Windows 7 Home Premium

Bastian, If you have an attachment to add to this report, please add it as an attachment instead of providing a link to an external site. The file could get lost if the external site ever went away.

I checked the online source code to track down this issue and I noticed glitches both in exporter and importer...
(I guess it's not the best place for such a report BTW, but at least it'll be done... please point me to a better place if needed)

- In the file "http://git.gnome.org/browse/gimp/tree/plug-ins/file-bmp/bmp-write.c" inside WriteBMP(), inside the "switch (BMPSaveData.rgb_format)" the "mask_info_size" is not set for case "RGBA_8888". This is later preventing the writing of the Mask info "if (mask_info_size > 0)", thus breaking the BITMAPV5HEADER structure in case the color_space_data are also written.

So we should likely have:
        case RGBA_8888:
          BitsPerPixel = 32;
          mask_info_size = 16;
          break;
instead of:
        case RGBA_8888:
          BitsPerPixel = 32;
          break;

(Maybe this bad structure format could be a reason some apps fails reading a BMP image with color space information saved from Gimp BTW...)


- In the file "http://git.gnome.org/browse/gimp/tree/plug-ins/file-bmp/bmp-read.c" inside ReadBMP(), if "Bitmap_File_Head.biSize" is greater than 64 (which is always the case if the "do not write color space information" option is not ticked when exporting a BMP), it seems that the image is always created using GIMP_RGB format, there's no check for the GIMP_ARGB format, so the alpha layer is obviously lost.
Here's the incriminated code:
          image_ID = gimp_image_new (gdk_pixbuf_get_width (pixbuf),
                                     gdk_pixbuf_get_height (pixbuf),
                                     GIMP_RGB);

On the other hand if I try in Gimp 2.8.0 the layer is not labelled "Background" as in the source code, so I'm not sure this is the exact same code...

(In reply to comment #5)
> Bastian, If you have an attachment to add to this report, please add it as an
> attachment instead of providing a link to an external site. The file could get
> lost if the external site ever went away.

Kevin, I was told by bugzilla to upload the tarball to an external site because the tarball exceeded the allowed file size of 1,000 kilobytes.


(In reply to comment #6)
> So we should likely have:
>         case RGBA_8888:
>           BitsPerPixel = 32;
>           mask_info_size = 16;
>           break;
> instead of:
>         case RGBA_8888:
>           BitsPerPixel = 32;
>           break;

Tested this, and GIMP now imports the alpha channel - the results looks funny though, my attachment should show a screenshot of the results.


> - In the file
> "http://git.gnome.org/browse/gimp/tree/plug-ins/file-bmp/bmp-read.c" inside
> ReadBMP(), if "Bitmap_File_Head.biSize" is greater than 64 (which is always the
> case if the "do not write color space information" option is not ticked when
> exporting a BMP), it seems that the image is always created using GIMP_RGB
> format, there's no check for the GIMP_ARGB format, so the alpha layer is
> obviously lost.
> Here's the incriminated code:
>           image_ID = gimp_image_new (gdk_pixbuf_get_width (pixbuf),
>                                      gdk_pixbuf_get_height (pixbuf),
>                                      GIMP_RGB);

There appears to be no such thing as GIMP_ARGB (nor GIMP_RGBA) - I have been told that the alpha channel is in the layer and not in the image.


> On the other hand if I try in Gimp 2.8.0 the layer is not labelled "Background"
> as in the source code, so I'm not sure this is the exact same code...
Well, the development version of Gimp is called 2.9, while 2.8 is the stable branch (AFAIK).

PS: Thanks for chiming in, Jigebren. :)

Created attachment 216544 [details]
Result of Jigebren's proposed changes to bmp-write.c

(In reply to comment #7)
> There appears to be no such thing as GIMP_ARGB (nor GIMP_RGBA) - I have been
> told that the alpha channel is in the layer and not in the image.

Of course! I guess I've mixed image GIMP_ARGB with layer GIMP_RGBA_IMAGE... Sorry, it was my first contact with Gimp source code, you can forget the part about "bmp-read.c".

I think I may have nailed down the source of the reading issue.

Gimp just can't import the alpha channel of a 32bit BMP v5 file. I checked by manually fixing a 32bit BMP v5 file using an hexa editor.
For this BMP type, data are imported using gimp_layer_new_from_pixbuf() which seems to properly detect the image as a 4 channels one. The BMP file is then read using GDK.
I quickly tried loading 32 bit BMP using GDK functions in the Python console but I could never get any transparency...

After a bunch of investigations I finally came to the GDK module used to load BMP files:
http://git.gnome.org/browse/gdk-pixbuf/tree/gdk-pixbuf/io-bmp.c

In OneLine32(), we can see that the alpha component is simply overwritten with 0xff:
		for (i = 0; i < context->Header.width; i++) {
			*pixels++ = src[2];
			*pixels++ = src[1];
			*pixels++ = src[0];
			*pixels++ = 0xff;

			src += 4;
		}

Not to lose the alpha channel it should be:
			*pixels++ = src[2];
			*pixels++ = src[1];
			*pixels++ = src[0];
			*pixels++ = src[3];

I don't know whether or not GDK is supposed to support alpha in BMP files. But as far as Gimp is concerned it sounds inconsistent not to be able to properly read again a file it has written itself...

I see 2 solutions:
- Fix the GDK module as suggested above to add support for alpha in BMP (seems the better way, unless GDK is not supposed to read the alpha layer).
- Stop using GDK to import BMP v5 files in Gimp (as it's done for other BMP variants)

I have

Excuse my previous reply. What I wanted to say was that I have filed a new bug report against gdk-pixbuf with Jigebren's discoverings. I have also tested his solution which seems to fix the issues with reading 32-bit v5 RGBA Bitmaps. The patch has been attached to the new bug report I have filed:
https://bugzilla.gnome.org/show_bug.cgi?id=678248

However, Jigebren's solution does not fix the issues regarding 32-bit v5 RGBX Bitmaps. So I have created yet another bug report with focus on this issue, since they appear to be two different kinds of bugs:
https://bugzilla.gnome.org/show_bug.cgi?id=678250

I was told that the best solution probably would be to stop using GDK and write new read code for importing 32-bit v5 Bitmap files inside bmp-read.c so it is probably a good idea to keep this bug report open.

I have also attached a patch for bmp-write.c containing the changes Jigebren suggested in comment 6.

Instead of attaching a patch for bmp-write.c, I have created yet another new bug report with focus on the glitch on bmp-write.c - this is due to the fact that the problems with loading BMP files is because of an issue in both GIMP and gdk-pixbuf and therefore adding only part of the solution as a patch to this bug report, wouldn't make sense IMO. I consider this the parent-bug to bug 678252, bug 678248 and bug 678250.

Resolving as duplicate of bug #678252. Please see that bug for details and fix.

*** This bug has been marked as a duplicate of bug 678252 ***