[Closed] Cocooner creates 2 Kilobytes of seemingly unnecessary padding data

Having tech problems? Post them here and do not worry, there is always a solution for you.
Post Reply
porg
Posts: 554
Joined: Tue Apr 05, 2022 1:04 pm
Country: Austria

[Closed] Cocooner creates 2 Kilobytes of seemingly unnecessary padding data

Post by porg »

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:

Cocooner creates 2 Kilobytes unnecessary padding data.png
Cocooner creates 2 Kilobytes unnecessary padding data.png (497.63 KiB) Viewed 583 times
User avatar
forum_adm
Site Admin
Posts: 1814
Joined: Fri Dec 23, 2016 9:41 am
Location: Germany
Country: Germany
Contact:

Re: Cocooner creates 2 Kilobytes of seemingly unnecessary padding data

Post by forum_adm »

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.
porg
Posts: 554
Joined: Tue Apr 05, 2022 1:04 pm
Country: Austria

Re: [Closed] Cocooner creates 2 Kilobytes of seemingly unnecessary padding data

Post by porg »

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!
Post Reply