*** Bug 683716 has been marked as a duplicate of this bug. ***

Bug 683716 sounds like a different, but possibly related, problem than this one. The other report states that indexed BMP files are being saved in RGB format.

*** Bug 688158 has been marked as a duplicate of this bug. ***

*** Bug 688868 has been marked as a duplicate of this bug. ***

It seems to me that GIMP saves BMP files with indexed colors properly. You can check that with ImageMagik (identify --verbose file.bmp, it will print the color map, if there is). Nevertheless, please check, I may be wrong.

But, it seems that GIMP is not able to reopen it as indexed. By looking into plug-ins/file-bmp/bmp-read.c, opening the previously saved BMP falls into :

      GdkPixbuf* pixbuf = gdk_pixbuf_new_from_file(filename, NULL);

      if (pixbuf)
        {
          gint32 layer_ID;

          image_ID = gimp_image_new (gdk_pixbuf_get_width (pixbuf),
                                     gdk_pixbuf_get_height (pixbuf),
                                     GIMP_RGB);

This is a bit sad since io-bmp.c from gdk_pixbuf do all the bmp-reading neatly. I suspect that there is also overlaps between gimp's bmp-reading implementation and that of gdk-pixbuf.

Limit the use of gdk_pixbuf to RGB cases and implement indexed and greyscale cases directly inside bmp-read.c is the right thing to do isn't it ?

Note that the problem occur also with greyscale images...

IIRC the GdkPixbuf fallback was done because the plug-in sucks :)

Feel free to fix or improve it using your own judgement.

Created attachment 239112 [details]
Starts of 2 files showing GIMP indexed bitmap problem

Téo,

You say that GIMP saves indexed bitmap files correctly but they are not read correctly by other applications once saved (for instance the Microchip Graphics Resource Converter).

Certainly the colour palette is still present in the edited file and contains the same values but it is at a different offset within the file. In my original file the pixel data starts at 0x76 but in the edited file saved by GIMP the pixel data starts at offset 0xBA - what does GIMP store in the extra 0x44 bytes?

If I make the edit using PSP9 the pixel data and the colour palette remain in the same positions that they occupied in the original file.

I have attached a file showing the start of the original file and the start of the file saved by GIMP. Perhaps losing the extra header information inserted by GIMP would fix the problem.

(Sorry this should have had the attachment in comment 7 attached to it but I clicked the commit too soon)

Hello everybody,

I tried to used the last official version of Gimp last week (2.8.4). I desired to know if the indexed colors were now fixed but it is not the case.

I generated the same bmp file with the same palet of colors between the 2.6.12 version and this last one, but I saw a difference between the generated bmp files. They are not the same.

Maybe it is a possible way to find the bug.

Regards,

Julien Cordier

PS: I am using a table of 256 colors...

identify -verbose shows that the color map is indeed present the exported BMP file.

The additional bytes could be the larger Bitmap V5 header.

Looking at an 16-colour indexed bmp output by GIMP it seems to me that the bV5CSType field (set to 0x73524742 = "sRGB" = LCS_sRGB) is in the position that should be occupied by bV5RedMask based on the specification at http://msdn.microsoft.com/en-us/library/dd183381.aspx

The fields bV5RedMask, bV5GreenMask, bV5BlueMask and bV5AlphaMask should all appear before bV5CSType field.

Well, actually it seems that GIMP's default export use BMP V4 header... I will work on it.

Please talk to Mukund first, this plugin has seen so many fixes and bugs,
I totally lost track.

Looking at the source code last night I realised that if, when I export the 16-colour indexed bitmap, I select "Compatibility Options" and select "Do not write color space information" the extra header bytes aren't written (the pixel data starts at offset 0x76) and the resulting file is recognised correctly (so far as I can tell) as a 16-colour indexed bitmap by GIMP and the other programs I have tried so far. This provides a work-around for my current needs and may help others.

@Julien:

To help me to figure out what is the problem here, I need you to answer the following questions :

Are you using another software to read your indexed bitmap or this is juste reopening the file with GIMP? What let you think that your file is not saved as indexed? This is just to confirm or refute the comment 5.

If you think your bmp saved as indexed is not indexed, please attach here a small file showing the bug.

Thanks for your help!


Also, good advice from programmer_ceds, saving your file using "Compatibility Options" and "Do not write color space information" will let you reopen your file as indexed in GIMP. Others software will probably have better support too. You should try.


@programmer_ceds:

Thanks for your founds. Using compatibility mode, GIMP save the BMP with a Windows V3.x Header, this can explain the two different offset. But it doesn't mean that GIMP is wrong here.

Téo,

My reasoning for saying that there is a fault in GIMP is that when an indexed file is saved with the colour space information not only is it not recognised as an indexed file by other programs it is not recognised as an indexed file by GIMP - instead GIMP "Image/Image Properties" shows it as an RGB file rather than indexed color (16 colors) as it does if the colour space information isn't saved. If GIMP is saving the file with the colour space information correctly it isn't reading it correctly - I suspect the save operation.

I will attach a file containing two crops from a 16-colour indexed bitmap file; one with the colour space and one without. Both contain the same palette which is the same as the palette of the file from which they were cropped. The one without the colour space is recognised as indexed by GIMP and other programs that I have tried.

I hope this is of some help.

Created attachment 239416 [details]
Two identical crops - one with and one without colour space info

I have just had my son, who uses PhotoShop 5.5, make the same crop - he doesn't get the option of saving colour space information. I have looked on the net but can't find a definitive answer - can indexed bitmaps contain colour space information?

I was hoping the PS would include colour space information in a form that worked - then we could compare this with the GIMP file that doesn't. This doesn't seem to be an option unless anyone knows of a way to force PS to include the information.

(Exporting the file in GIMP with colour space information seems to include a BITMAPV4HEADER (108. bytes long) not a BITMAPV5HEADER at 124. bytes)

Created attachment 240808 [details] [review]
Work in Progress, do not apply

This is the way I think we should go.


This patch parses Bitmap V4/5 header and use GIMP's implementation instead of gdk_pixbuf.

It's already functional, but it remains some unknowns and it's not sufficiently tested anyway...

The main unknown is :

- How to interpret the mandatory "AlphaMask" when "Compression" is not BI_BITFIELDS. Because this mask can't be set arbitrarly since the three others are only valid with BI_BITFIELDS compression...

I will think more about it. Also, Bitmap V4/5 features are still not implemented : embedded/linked icc profiles, gamma corrections, ...

Created attachment 240867 [details] [review]
patch v0.2, still WIP

* Fix a wrong buffer size
* Remove an old hack from the "RGBA-BMPV3" ages, solving #352262

I have to explain the second point :
   - In current master and 2.8 git trees, this code is a noop since opacity is enforced with masks.
   - This code was a way to guess if the algorithm should read or ignore extra bytes of a Bitmap V3.x image.
   - A valid bitmap v4/5 may be fully transparent. In that case, this code ignore the transparency.

Perhaps we will reintroduce this kind of stuff later, to solve bugs like : #697431. It should be discussed though.



This patch still needs some deeper testing, but it could be the right patch. If someone haves some weird bmp files, please feel free to email them to me. Google is full of bitmap V3.x images, later versions are harder to find...

Oh, and for the question in the comment #19, the answer is that there is an alpha component only and only if compression is BI_BITFIELDS. At least, this what I understand.

Also, sorry for my english.

Created attachment 241455 [details] [review]
Ready for review, submitted against master

I consider the patch ready for review and inclusion.

Since the last version of the patch :

- Don't set any error message in case of Bitmap header v3.x + BI_RLE4 or BI_RLE8, even if it is not visible.
- minor format fixes.

As I already said, there is no feature addition. BI_PNG, BI_JPEG, endPoints, color spaces, gammas, are still not supported and are just ignored (BI_PNG and BI_JPEG compressions will fail properly).

Also, I hope it's clear that this patch doesn't adress any exporting issue, but importing ones. Since I have no confirmation about the reporter, I consider that I am right :-)

@programmer_ceds: The fact that some others program doesn't read GIMP's exported BMPs could mean that they don't support bitmap v4 or v5. If you want to save your BMP as v3, the compatibility option is the right thing to use. And if you still think that GIMP is doing something wrong, just let me know. Finaly, if the patch is applied and there is no feedback from the reporter, this bug report will be closed.

@Téo,

As a test of what you said above I have tried reading a file containing colour space information (a V4 file) output by GIMP into Paint (V6.1) and PS/CS6 - both programs correctly recognise the file as an indexed BMP file.

Both programs save the file in V3 format (and appear not to offer any alternative).

I assumed that the fault lay in the output of the files by GIMP as the programs that I had tried before (including GIMP) didn't recognise the file as being indexed.

Thanks for looking at the problem.

Richard

Let's not have bugs with patches in the unconfirmed state.

Hello everybody,

I am at the origin of this bug report and I tried to use the new version in french of Gimp yesterday (v2.8.6) (on windows XP SP3).

For me, the bug is still present. 

In my job, I need to generate some .bmp files with a customized palette to introduce them in an embedded software.

With Gimp 2.6.11, the .bmp files are properly generated and I can use them in my embedded software.
But with the Gimp v.2.8.0, the generated .bmp files are different, and I use the same indexed palette than in the version 2.6.11.

The method in Gimp v2.8.6 (to index the file with the good palette) is the same than in version 2.6.11 (in french): 
"Image" > "Mode" > "Couleurs indexées"
In the new window, I do:
"Utiliser une palette personnalisée"
I choose my customized palette and click on "Convertir".

Next I export my .bmp file. When I compare the .bmp files generated by Gimp v2.6.12 and Gimp v.2.8.6, the files are different and I can't use the new one with my embedded software because the panel is not good. When I compare the file, apparently the header seem to be different.

For more details, download the file I uploaded on : 
http://dl.free.fr/nsM0YHHcl
The password is : Gimp20130719

You will download a zip file. In this zip file, you will have:
- "Customized palette.pal.gpl" (it is the palette I used for the test).
- "test gimp.xcf" (a picture I did to test this bug).
- "Gimp2.6.11.bmp" (the bitmap generated from "test gimp.xcf" with the version 2.6.11).
- "Gimp2.8.6.bmp" (the bitmap generated from "test gimp.xcf" with the version 2.6.8).

I think normally we should get the same file between the both versions of gimp.

@cordier.julien.alten@gmail.com - when you export your file try selecting "Compatibility Options" and select "Do not write color space information" - you will then get a V3 BMP file (as I believe the earlier version of GIMP produced).

Was the test in comment #23 done with or without applying the patch of comment #22?

The test in comment 23 was done using the published version of GIMP V2.8 that was current at the time (2.8.4?) so it was not done with the patch included.

I tested to save the file with "Compatibility options". 
It works in my embedded software. 

I compared the both files (the file from gimp 2.6.11 and the one I just generated with the "Compatibility options") and they are exactly the same.

Sorry, I didn't understand we had to uncheck the "Compatibility options".

Best regards.

Fixed in 2.8 and master

commit d59a31867ab9cde8eff81ad5f68968ba08b4f07c
Author: Téo Mazars <teo.mazars@ensimag.fr>
Date:   Sat Apr 13 17:16:56 2013 +0200

    Bug 674391 - Indexed colours not exported when save a .bmp
    
    It's about importing in fact.
    
    Parse BITMAPV4HEADER / BITMAPV5HEADER and use GIMP's BMP
    implementation instead of using gdk_pixbuf.
    
    Also, remove an old hack about 32bits bmp v3 + alpha. The alpha
    channel is already ignored in that case.
    
    (cherry picked from commit 56f065321ce42f907879dfa4a76e57de18b058eb)

*** Bug 701777 has been marked as a duplicate of this bug. ***

This bug has been reported several times as a problem with GIMP exporting indexed bitmaps incorrectly, when it is really a combination of two other problems - the inability of GIMP (2.8.6) to import V5 bitmaps and the inability of a number of other applications to import V5 bitmaps.

Once a version of GIMP that addresses the import issue has been released it will prevent further bug reports in respect of GIMP but there will still be reports that blame GIMP's export of indexed bitmaps because they are not read correctly by other applications.

My understanding is that by selecting the "Do not write color space information" option in the "Compatibility Options" section of the "Export Image as BMP" dialog causes GIMP to save an indexed bitmap in V3 format, leaving the item unselected gives a V5 format file.

In order to prevent spurious GIMP bug reports caused by trying to import V5 bitmaps into other applications that do not support them I would suggest getting rid of the "Compatibility Options" entry in the dialog (as there is currently only one option anyway) and replace it by a pair of radio buttons - one (selected by default) saying "V3 bitmap - no color space information" and the other saying "V5 bitmap - color space information saved". Having the dialog set in this way would have prevented most of the reports for this 'bug' (including mine).