GNOME Bugzilla – Bug 632288
When saving in PNG format, ancillary safe-to-copy chunks are not copied to the new file
Last modified: 2018-05-24 12:52:47 UTC
Created attachment 172486 [details] Test image precocnfigured to have a aaAa chunk. According to the PNG specification, chunks that are marked as ancillary and safe-to-copy should be saved into the new file. Is there a reason why a chunk with (aaAa) doesn't get transferred to a new PNG file? This is ancillary and safe-to-copy. Reference: http://www.libpng.org/pub/png/spec/1.1/PNG-Structure.html#Chunk-naming-conventions STR: # Create some image in GIMP and save it in PNG format. # Open the PNG in a binary editor. # Go to the end of the file and back 12 bytes (the start of the IEND chunk. It should be 4 zero bytes, IEND then a CRC32. # Insert the following binary string: #* 0000 0000 6161 4161 381C C1E7 (this equates to a zero length chunk with name aaAa and checksum). # Open the file in GIMP. # Select Save As. # Save the file as something other than the original file name. # Compare the two binary files. # Notice that the files are the same except the aaAa chunk we added in a hex editor has now been removed. I've attached a preconfigured PNG file that contains the aaAa chunk.
If you really need this feature, you could add code to the file-png-load procedure that attaches such a chunk as a parasite to the image. And add code to the file-png-save procedure that recognizes this parasite and saves it back to the PNG file.
After talking about .ORA format on LGM 2016 BoF it became patent that this is a nice feature: we agreed, without knowledge of the PNG specification in mind, that Open Raster images themselves should have a feature just like this.
-- 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/346.