Попытка понять zlib / deflate в файлах PNG

В настоящее время я нахожусь в процессе написания небольшой библиотеки ввода / вывода изображений PNG для учебных целей. Моя проблема заключается в следующем:

Я создал небольшой PNG размером всего 2 на 2 пикселя и открыл его в шестнадцатеричном редакторе, чтобы изучить его содержимое. Это изображение, которое я создал с помощью GIMP и хранит со сжатием «9».

(Обратите внимание, что это увеличенное изображение исходного изображения размером 2 на 2 пикселя;))

Так что я думаю, что несжатый, это будет выглядеть примерно так в памяти:

00 00 00 FF 00 00 00 00 FF 00 FF 00

при хранении без альфа-канала.

(Я только сказал это здесь для ясности. Я знаю о сжатии и не ожидал увидеть этот шаблон байта в файле).

Я извлек чанк IDAT, извлек идентификатор чанка («IDAT») и значение CRC хвостовой части и получил следующую последовательность байтов:

08 D7 05 C1 01 01 00 00 00 80 10 FF 4F 17 10 48 06 0F FE 02 FE

Теперь первые два байта08 D7 содержать информацию о кодированном блоке. И последние четыре байта0F FE 02 FE должна быть контрольная сумма ADLER32.

Это в конечном итоге оставляет мне следующие байты:

05 C1 01 01 00 00 00 80 10 FF 4F 17 10 48 06

Записанные в двоичном представлении эти байты:

0000 0101  1100 0001  0000 0001  0000 0001
0000 0000  0000 0000  0000 0000  1000 0000
0001 0000  1111 1111  0100 1111  0001 0111
0001 0000  0100 1000  0000 0110

Чтобы лучше понять DEFLATE, я попытался «распаковать» эту последовательность вручную, по крайней мере, до того, как понял ее достаточно хорошо, чтобы написать небольшой инструмент. Но я застрял очень быстро.

RFC 1951 («Спецификация формата сжатых данных DEFLATE») утверждает, что каждый кодированный блок начинается с трехбитового заголовка. Один бит, указывающий, является ли это последним блоком, и еще два блока, указывающие метод сжатия. Поскольку я предполагаю, что кодер использовал здесь только один блок (то есть первый блок автоматически является последним) и использовал нестатическое дерево Хаффмана, я ищу битовую последовательность «101», но не могу найти ее (и при этом я не нахожу другую вероятную последовательность). заголовки "100" или "110").

Также RFC говорит, что должно быть два двухбайтовых значения LEN и NLEN, хранящих длину блока, где NLEN - это дополнение к LEN, но опять же я не могу найти четыре таких байта, которые удовлетворяют этому условию. Я даже не начну с удачи в поиске чего-либо, что могло бы представлять два дерева Хаффмана.

Я читаю RFC 1951 и 1950 («Спецификация формата сжатых данных ZLIB» а также статьи из Википедии о кодировании zlib, DEFLATE, LZ77 и Huffman, а также несколько небольших и довольно бесполезных статей в Интернете и несколько ответов о переполнении стека, но ни одна из них не помогла мне с моим отсутствием понимания.

Буду очень признателен за любую помощь или подсказку!

Ответы на вопрос(2)

Ваш ответ на вопрос