Lemke Software GmbH Forum

I compared the original versus the cocooned version of a JPEG file with the help of the binary diff feature of HexFiend and realized the XMP part in the Cocooned file contains a section of 2048 bytes only consisting of whitespace. This has no purpose that I would know of. Just increases the file size.

This doesn't really concern me anymore in the age of TB SSD's. But still at least I wanted to report it:

I write the XMP metadata with the Adobe XMP SDK.

It adds the padding. Also, this is done by design. Please check the official XMP docs. The idea is: an additional change of the XMP metadata has to write only that small part of the file.

Thanks for the clarification!

I now learned that the performance benefits certainly far outweigh the negligible storage increase!

Makes sense from an I/O perspective!

The filesystem allocation stays the same, only some minor block overwrite (the 2K align perfectly as a multiple with the filesystem geometry), and no need to allocate new blocks.

For GraphicConverter's batch capabilities this is certainly very meaningful to scale well, e.g. rewriting XMP of 10k files in a jiffy!