GNOME Bugzilla – Bug 771185
Indexed images default to lowest numbered same-color palette entry upon export
Last modified: 2018-05-24 16:53:16 UTC
Created attachment 335249 [details] Simple color palette with repeat entries When exporting an indexed image, and having some of the same colors in the palette to be exported with the image, GIMP will default to picking the indexed number that is lowest in the palette count. For instance, in the attached image there is a palette of 16 colors. Black is at index 0, 4, 8 and 12. White is at index 3 and 9. Gray is at index 7 and 9. If I use index 9 for white, when exporting it will default to using index 3 for every instance of white. When switching the image mode from RGB to indexed, and unchecking the "Remove unused colors from colormap," so that all the palette colors are preserved in the file upon export, it would make sense that the proper indexes should be used, or an option upon export to force the proper indexes rather than a lower numbered index.
We IIRC have a bug about being able to export indexed images without changing the palette, this bug would be a duplicate.
Same here, I can confirm that. I thought that at this point this bug would be resolved. :(
(In reply to David from comment #2) > Same here, I can confirm that. I thought that at this point this bug would > be resolved. :( I will add more information. I'm modifying (for translation) some images of Space Quest 6 (CD English version). This images are bitmap 256 color images, some with embedded indexed palette and anothers without. If one of this images (it does not matter that it has the palette or not embedded) has the same color indexed, you can edit in GIMP the image and the pixels changed are correct depending of the indexed palette, but when you want to Export the BMP, it writes the first indexed color of the palette. This causes a problem, because if the game is using index 255 as transparency (which this technique is commonly used in images of older games), and whe have the same color in index 37, the Export BMP saves the image with a false value and the game do not displays well the image. The more odd thing of GIMP is that you can load the image as BMP, NOT TOUCH ANYTHING, and Export it as BMP writes more or less the same file as the original. But if you modify the image the problem appears.
Created attachment 356549 [details] Sample Image for Space Quest 6 with Export BMP index palette problem Transparency is index 255 for the bitmap (embedded index). In index 144 you have the same color. Modify something (let's say, erase all the text with index 255), do the export, and you will see (if you open this new exported file) that the index of the file is 144.
Sorry about #637413 bug, but it is a totally different bug. In this case I think the problem is the BMP export, in the #637413 bug it happens in the same gimp graphical tool and with images with alpha channel. I have not talked never about alpha channels or used them either doing the tests.
In GIMP-2.8 operations like anti-alised text, smudging, anti-aliased painting, blurring and more were not available for indexed images, in 2.9.x/3.x such limitations have been dropped, instead of dropping indexed support and focus GIMP only for editing of images with photo fidelity. As a workaround, and part of future fix for someone with such indexed mode needs, is to run a de-duplicator on the palette, making sure that all entries are unique. For example duplicate whites be encoded as rgb(255,255,255) rgb(254,255,255) rgb(255,254,255) etc, and for a fuller implementation also keeping track of which entries were duplicates of each other.
As a workaround it should work, but it is not as .bmp works. You can use the palette as you want and if you want to use the same palette color in 15 indexes, you should do it. When GIMP exports to BMP is breaking the rules and it is not exporting the pixels of the bitmap with its indexed color. This is a bug, not a working function. Apart of that, the problem when editing is not using text, smudging, antialiased painting... in this case, if I must draw only 1 pixel or change the color of pixels, the problem persists. I want to repeat... this is not a GIMP BUG it is a EXPORT BMP funcion BUG. GIMP is doing the things as it should do, the problem is ONLY when EXPORTING BMP.
-- 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/961.