Re: cOMp chunk [was: EXIF support in PNG]

On Sun, Jan 1, 2017 at 12:08 PM, John Bowler <
[email protected]> wrote:

> [glenn wrote]
>
>> I might change the order a bit (putting compression method
>> before original length):
>>
>> <chunk-length>: compressed length + 9
>> 'comp': chunk tag (case matches case of the embedded chunk)
>> <compression-method>: 1 byte, typically 0 for deflate
>> <original-length>: 4 bytes
>> 'data': original chunk tag (see below)
>> <compressed-chunk-data>
>> <crc32>
>>
>> With this order, the original_length+data+compressed_chunk_data
>> are an exact copy of the original chunk, minus its CRC.
>>
>
> I thought about that and I wasn't sure.  It seems to me that the
> compression method is part of the compressed data but I don't really care.
>
> There's a slight advantage for some decoders to have four-byte fields at
> the start of the chunk; this gives 4x4-byte fields which are correctly
> aligned when read into a malloc or heap buffer.
>
>
On the other hand, a "0" compression method terminates the 4-byte "data" in
case a decoder tries
to read it as a string.

We could waste 3 bytes and use a 4-byte compression method for alignment.

compression method is not part of the compressed data (of course one might
comp a zTXt | iTXt | iCCP or similar chunk that has its own compression
byte).

Glenn

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

_______________________________________________
png-mng-misc mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/png-mng-misc