GNOME Bugzilla – Bug 303864
Palette color order changes when indexed palette PNG is saved
Last modified: 2008-01-15 12:53:59 UTC
Version details: From Debian Sarge Distribution/Version: Debian Sarge Steps to reproduce: 1. Open test.png from here: http://pandora.iu-bremen.de/~rvincent/misc/test.png 2. Note the order of colors in the palette (Color map) 3. Save and close the file 4. Reopen the file 5. Order of colors in the palette have changed, the first color has become the last, and the rest have moved up (indexes have changed) 6. Successive saves and opens continue the shifting of color order Another test: 1. Open a fresh test.png from the above url 2. Note the order of colors in the palette (Color map) 3. Scale the image to 50% of height and width 4. Save and close 5. Open the file 6. Colors maintain their order in the palette 7. Successive saves and opens do not change the order of colors What is expected: Colors in the paletted maintain their order in both cases.
Confirmed.
The original contains 23 colors, but in the GIMP only 22 colors show up. This is a dump of the original PLTE chunk: PLTE-Chunk: 69 bytes 23 colors (255, 0, 0) (255, 0, 255) (0, 0, 255) (0, 255, 255) (0, 255, 0) (255, 255, 0) (127, 0, 0) (127, 0, 127) (0, 0, 127) (0, 127, 127) (0, 127, 0) (130, 127, 0) (0, 0, 0) (25, 25, 25) (51, 51, 51) (76, 76, 76) (102, 102, 102) (127, 127, 127) (153, 153, 153) (178, 178, 178) (204, 204, 204) (229, 229, 229) (255, 255, 255) the first color (pure red) does not appear in the colormap dialog. When scaled down and saved again, the PLTE chunk only contains 22 colors: PLTE-Chunk: 66 bytes 22 colors (255, 0, 255) (0, 0, 255) (0, 255, 255) (0, 255, 0) (255, 255, 0) (127, 0, 0) (127, 0, 127) (0, 0, 127) (0, 127, 127) (0, 127, 0) (130, 127, 0) (0, 0, 0) (25, 25, 25) (51, 51, 51) (76, 76, 76) (102, 102, 102) (127, 127, 127) (153, 153, 153) (178, 178, 178) (204, 204, 204) (229, 229, 229) (255, 255, 255) Something is weird here.
Probably also important: The original image has a tRNS chunk: tRNS-Chunk: 1 bytes Index 0: alpha: 0 i.e. the first color is transparent. Subsequent savings keep the tRNS-Chunk and keep 23 colors in the palette, but the first color changes randomly, which seems to indicate to a memory corruption: first resaving of the original image: PLTE-Chunk: 69 bytes 23 colors (0, 0, 25) (0, 0, 255) (0, 255, 255) (0, 255, 0) (255, 255, 0) [...] second saving: PLTE-Chunk: 69 bytes 23 colors (0, 0, 17) (0, 255, 255) (0, 255, 0) (255, 255, 0) (127, 0, 0) [...]
Here's a little more information obtained with pnginfo. Nothing new but I include it here anyway to avoid duplicated efforts. Image Width: 668 Image Length: 910 Bitdepth (Bits/Sample): 8 Channels (Samples/Pixel): 1 Pixel depth (Pixel Depth): 8 Colour Type (Photometric Interpretation): PALETTED COLOUR with alpha (23 colours, 1 transparent) Image filter: Single row per byte filter Interlacing: No interlacing Compression Scheme: Deflate method 8, 32k window Resolution: 2835, 2835 (pixels per meter) FillOrder: msb-to-lsb Byte Order: Network (Big Endian) Number of text strings: 0 of 0 Offsets: 0, 0
Created attachment 50613 [details] test image Same image as the one mentioned in the report. Just uploading it to bugzilla since it might disappear from my server.
The root problem here is that indexed png files with transparency always have the transparent indices at the front of the palette, whereas gimp colormaps do not include a concept of transparency at all. This means that colormaps must be remapped when saving a file as png. The remapping was not being done in a way that preserved the order of palette entries. I think I have fixed it, but the logic is tricky and there are several cases that could arise, so this should get some testing. (There should not be changes for anything except IndexedA images.) Accordingly, I am only committing the fix to HEAD for the moment. Things to test are (1) that the plugin can save an image without crashing or generating error messages, (2) that the saved file when reopned gives rise to an identical image, and (3) that the colormap does not change when you do this. 2006-05-212 Bill Skaggs <weskaggs@primate.ucdavis.edu> * plug-ins/common/png.c: fix remapping of colors when saving IndexedA images; fixes bug #303864.
If anyone is interested in seeing this change backported to GIMP 2.2, he/she should check all the cases that Bill mentioned in comment #6. Otherwise it will stay unfixed in the stable series and at some point we will close the report as FIXED.
Closing as FIXED then. Obviously there is no interest in seeing this backported to 2.2.