CODEWITHSUNDEEP
algorithmgraphicspngdeflateinflate
stat
stat

Reputation: 669

IDAT PNG chunk, first byte unexpected, where am I wrong?

I created a png 3x3 with 3 different colours and 1 2x2 black and white for testing purpose.

Basically I've been able to allocate all the bits of the bytes to their specific role in their respective Chunk but the IDAT one (not unexpected).

the first byte after the IDAT type declaration is the following in binary 8 format:

00011000

where basically, following the online documentation:

0001 should be the CM =1 1000 should be the CINFO =8

But I expected to find a 1000 (=8) as CM (standard compression method for pngs).

Where am I wrong? Here the complete datastream.

After understood this part I'm going to implement the INFLATE/DEFLATE algorithm in a software on which it still is not build.

Here the complete datastream for the IDAT Chunk DataStream:

000110000101011101100011111110000000111100000100000011000000110000100000111010101111111101111111
0000000000111000110101000000100011111000

Upvotes: 0

Views: 238

Answers (1)

Mark Adler
Mark Adler

Reputation: 112339

Already answered in a comment, but as stated in the document you are reading (it helps to read the whole thing):

  In the diagrams below, we number the
  bits of a byte so that bit 0 is the least-significant bit, i.e.,
  the bits are numbered:

     +--------+
     |76543210|
     +--------+

You do not need to "implement the INFLATE/DEFLATE algorithm in a software", since that has already been done for you with zlib.

Upvotes: 1

Related Questions