Re: CALL for DISCUSSION: cOMp/cOMP/coMp/coMP: compression wrapper chunks

The terms used in the proposal are the same as are used in the
referenced sections of ISO PNG:

On Sun, Jan 29, 2017 at 12:42 PM, Glenn Randers-Pehrson
<[email protected]> wrote:
> On Sun, Jan 29, 2017 at 3:10 PM, John Bowler
> <[email protected]> wrote:
>>    Thus the chunks have the following layout, following the description
>>    given in section 5.3 and using cOMp as an example:

ISO PNG Section 5.3 defines "length", "chunk type", "chunk data" and
"crc", so in the description:

>>
>>       length [4 bytes, length of the cOMp data]
>>       cOMp [4 bytes, 99, 79, 77, 112]
>>          original chunk length
>>          original chunk type
>>          compressed original chunk data
>>      crc

The "original" fields are those fields from the original chunk and the
other fields are the fields of the comp chunk.

I don't think further explanation is necessary.

> Without it, the decoder has
> to construct one, so leaving it out doesn't really reduce the burden on
> decoders.

I think it is the other way round, isn't it?  Adding a third CRC
(which duplicates the Adler32 since it CRCs the original data, like
the Adler32) obliges the decoder to calculate *three* separate CRCs to
validate the data, and creates seven possible different failure
conditions.    Without it the decoder just ends up calculating two
CRCs (Adler32 and the PNG CRC32).

It's bad enough having the Adler32 in there; readers of this list
probably wouldn't believe the mess that resulted from one influential
company complaining that libpng failed to process a PNG because the
Adler32 failed (the company had disabled processing of the CRC).  One
option is to not use RFC-1950 (zlib compressed format) but just use
RFC-1951; the deflate compressed format that the zlib format encloses
in a 6 byte wrapper.  It saves 6 bytes and removes the Adler32.

> Also specify whether the "original chunk length" includes the
> compression method byte (I don't think it does).

The "original chunk length" is the length of the original
*uncompressed* chunk data; the comp chunk length is the length of the
comp chunk - the compressed data plus the 8 byte originial chunk
header.  Surely this is obvious?  The apparently spurious extra length
is required for a streaming decoder to work; without it the decoder
has to decompress the whole stream before it can emit the original
chunk header.

The compression byte is part of the compressed data; it tells the
decoder what the compression method is.

John Bowler

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