I am currently writing a C program that builds a PNG image from a data file generated by another. The image is a palette type.
Is the Adler-32 checksum calculated on the uncompressed data for...
a) each compressed block within an IDAT data chunk?
b) all compressed blocks within an IDAT data chunk?
c) all compressed blocks spanning all IDAT data chunks?
From the documents at http://www.w3.org/TR/PNG/, http://tools.ietf.org/html/rfc1950 and rfc1951 (at the same address as previuos) I am of the opinion that it is case 'c' above, allowing one's deflate implementation to chop and change how the data are compressed for each block and disregard how the compressed blocks are split between consecutive IDAT chunks.
Is this correct?
There can be only one compressed image data stream in a PNG file, and that is a single zlib stream with a single Adler-32 check at the end that is the Adler-32 of all of the uncompressed data (as pre-processed by the filters and interlacing). That zlib stream may or may not be broken up into multiple IDAT chunks. Each IDAT chunk has its own CRC-32, which is the CRC-32 of the chunk type code "IDAT" and the compressed data within.
I'm not sure what you mean by "allowing one's deflate implementation to chop and change how the data are compressed for each block". The deflate implementation for a valid PNG file must compress all of the filtered image data as a single zlib stream.
After you've compressed it as a single zlib stream, you can break up that stream however you like into a series of IDAT chunks, or as a single IDAT chunk.
PNG IDAT chunks are independent from the compressed blocks. The Adler-32 checksum is part of the zlib compression only and has nothing to do with the PNG's overall meta-structure.
From the PNG Specification:
There can be multiple IDAT chunks; if so, they must appear consecutively with no other intervening chunks. The compressed datastream is then the concatenation of the contents of all the IDAT chunks. The encoder can divide the compressed datastream into IDAT chunks however it wishes. (Multiple IDAT chunks are allowed so that encoders can work in a fixed amount of memory; typically the chunk size will correspond to the encoder's buffer size.) It is important to emphasize that IDAT chunk boundaries have no semantic significance and can occur at any point in the compressed datastream.
(emphasis mine)
来源：https://stackoverflow.com/questions/33914640/adler-32-checksums-in-a-png-file