How to decode an IDAT block of a PNG file without compression

I created several 4x4 pixels, 16-bit grayscale images in Photoshop and saved them as uncompressed, without interlacing PNG files. I am trying to write a program to extract image data from these files, but I am a bit confused with the IDAT block. This is for self-education purposes, so I do not use the library.

Here is the hex code for the IDAT block of one of the images, where each pixel is white.

hex code

I have a color coding, in my opinion, I understand.

Red = Ignore because it is part of the IEND block and is not related to IDAT. Yellow = Fragment information. The first 4 yellow bytes are the length of the data. The second 4 bytes of yellow is the fragment identifier. The last 4 yellow bytes at the end of the image is a cyclic redundancy check.

Blue = zlib compression format information. Where the first blue byte is the compression method and compression information. The second blue byte is the Flag information. The last four blue bytes at the bottom of the image are the ADLER-32 checksum. I assume that in this case there is no DICTID.
Gray = Information for the Deflate compression algorithm. In the first gray byte, the bit is the last block marker, and the bits two and three are the encoding method. The rest of the first gray byte is ignored. Since this method is uncompressed, the second and third gray bytes represent the length of the data bytes in the block, and the fourth and fifth gray bytes are one compliment of the second and third gray bytes.
Without boxing = Image data compressed using the LZ77 algorithm (without the Huffman code due to the uncompressed method) with an algorithm that uses 8 bits for the potential length of duplicates and 15 bits for the backward search distance.

Either I understand something wrong, or I don’t understand how to decode bytes in a borderless image using the LZ77 algorithm correctly. If someone can correct me or show that I do not understand, I would really appreciate it. Thanks.

+5
source share
1 answer

Top line: 01 ff fd 00 00 00 00 00 00 (under filter, the first pixel is fffd, subsequent pixels appear the same as the pixel on the left (difference = 0)

The remaining 3 lines: 02 00 00 00 00 00 00 00 00 00 (filter "up", everything as described above)

Last block: 01 00 00 ff ff (last byte marker 01, len 0000, ~ len ffff)

Thus, the image is 4x4, all pixels are 16 bits fffd, which is almost white.

If you used filter type 0 for all bytes, it could be clearer; each line will be equal to ff fd ff fd ff fd ff fd

By the way, the IEND block should have 4 more bytes (CRC); either something is wrong with your encoder, or you edited them from a hex dump image.

+5
source

All Articles