cOMp chunk [was: EXIF support in PNG]

I changed the subject line for cOMp (etc) discussion, EXIF is independent
of 'comp' and vice versa.

On Sun, Jan 1, 2017 at 6:37 AM, Glenn Randers-Pehrson <[email protected]>
wrote:

>     The cOMp chunk may appear multiple times, however, it must
>      obey the numbering and positioning rules for the chunk that it
> contains
>

Yes.  In fact an encoder can safely compress a chunk it does not recognize
so long as it preserves the order wrt IDAT.

PNG editors that do not decode the cOMp chunk
>      are not expected to enforce any special ordering rules but may
>      handle the chunk as any other safe-to-copy public chunk.
>

There is a caveat due to a problem that is unrelated to cOMp;  editors
cannot treat known chunks as completely unknown, the ordering rules with
respect to PLTE in the original ISO PNG specification have to be obeyed.
This doesn't happen automatically with, for example, libpng (prior to 1.7)

As a result cOMp can only be used on *known* chunks if they have no
ordering requirement with respect to PLTE.  This excludes any chunk in
Table 5.3 "Chunk ordering rules" that has a before or after PLTE
constraint, specifically:

cHRM, gAMA, iCCP, sBIT, sRGB, bKGD, hIST, tRNS

Neither can IHDR, IDAT or IEND be compressed.  This list of chunks is a
complete list of all the chunks except sTER and PLTE that are required for
correct display of an image.  It includes hIST, which could benefit from
compression, but I see no way round that.

In fact it may be better to do the simple thing and say no chunk given in
the original spec can be compressed, or maybe that only sPLT can be
compressed.

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.

-- 
John Bowler <[email protected]>
+1 (541) 450-9885
PO BOX 3151
KERBY OR 97531-3151
USA

------------------------------------------------------------------------------
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