Questions and postings pertaining to the usage of ImageMagick regardless of the interface. This includes the command-line utilities, as well as the C and C++ APIs. Usage questions are like "How do I use ImageMagick to create drop shadows?".
I'm trying to batch trim a number of PNG files that have extra transparent space. These PNGs have a custom chunk (grAb) described here: http://zdoom.org/wiki/GrAb
This is the command I am entering; it successfully trims the image but loses the grAb chunk. I know the grAb chunk determines an offset from the top left of the image and even if it was kept it would be wrong after a trim but, after I get over this obstacle, I'm hoping to be able to modify the grAb chunk to adjust for the trimmed space as a second step (any ideas on how to do this would also be appreciated).
I'll look into it. The PNG spec says chunks with the last byte of the chunkname lower-case are safe to copy, so the grAb chunk should have been preserved.
But as you note, the chunk contents depend on the contents of IHDR (width and height) so it isn't really safe-to-copy and should have been called grAB.
ImageMagick deliberately ignores all unknown chunks because typical operations (such as -trim, -crop, etc.) will likely render them invalid despite their
being "safe-to-copy" according to the PNG spec.
One solution would be to add grAb to the chunks known by IM and handle it like vpAg or oFFs. Another would be for the application to extract the grAb chunk
data with another application before mogrifying and then adjust and reinsert it afterwards.
BTW why not use oFFs which conveys the same information? Hmm, by the same logic as above, oFFs should really have been oFFS, but that's water
under the bridge now. ImageMaqick recognizes oFFs and does adjust it (using image->page data) when writing.
I think grAb is being used for historical reasons; switching to oFFs would break a lot of existing resources (something the maintainers of the engine are very much against even if a better implementation exists).
One solution would be to add grAb to the chunks known by IM and handle it like vpAg or oFFs. Another would be for the application to extract the grAb chunk
data with another application before mogrifying and then adjust and reinsert it afterwards.
This looks like the best way to do it at the moment; thanks! I'm going to have to see if the command line programs available for modifying the grAb chunk can help me do this otherwise I may have to write something up myself.
Last edited by exwizard on 2011-01-29T09:07:43-07:00, edited 2 times in total.
Ignore my comment about oFFs and gRAb having the same content. As I understand it now, oFFs conveys the offset of the image, while grAb conveys an offset within the image.
I've written a program that extracts the grAb chunk and then uses the oFFs chunk of a processed file in conjunction with the previously extracted grAb chunk to write a new grAb chunk (in the form of grAb xxxx - oFFs xxxx).
Thanks glennrp, pointing me at oFFs let me develop this workaround. Too bad imagemagick doesn't follow the PNG specification for ancillary chunks; would save me a number of steps.
Just to be clear, ImageMagick does follow the PNG spec. A spec-compliant PNG decoder is allowed to delete any or all ancillary chunks, whether it recognizes them or not, and according to the rules it must delete all copy-unsafe chunks. A spec-compliant PNG editor is supposed to preserve unknown chunks when it can, but ImageMagick does not claim to be a PNG editor, only a general-purpose image editor. I think that with a modest amount of work, ImageMagick could be made into a spec-compliant PNG editor, but it would never preserve copy-unsafe chunks because we can't guarantee that it writes the same IDAT chunks that it found in the input. Any difference in the input IDAT and output IDAT means that it would only be allowed to preserve the copy-safe chunks.
Also, the grAb chunk happens to be mis-named as though it were copy-safe although it isn't, because changing the image dimensions in the IHDR chunk invalidates its contents.
