Intentando entender zlib / deflate en archivos PNG
Actualmente estoy escribiendo una pequeña biblioteca de E / S de imágenes PNG para fines de aprendizaje. Mi problema es el siguiente:
Creé un pequeño PNG de solo 2 por 2 píxeles de dimensión y lo abrí en un editor hexadecimal para estudiar su contenido. Esta es la imagen que creé usando GIMP y la almacené con una compresión de "9".
(Tenga en cuenta que esta es una imagen ampliada de la imagen original de 2 por 2 píxeles;))
Así que supongo que sin comprimir, esto se vería así en la memoria:
00 00 00 FF 00 00 00 00 FF 00 FF 00
cuando se almacena sin un canal alfa.
(Solo dije esto aquí para mayor claridad. Sé de compresión y no esperaba ver este patrón de bytes en el archivo).
Extraje el fragmento de IDAT y eliminé el ID de fragmento ("IDAT") y el valor CRC de cola y obtuve esta secuencia de bytes:
08 D7 05 C1 01 01 00 00 00 80 10 FF 4F 17 10 48 06 0F FE 02 FE
Ahora los dos primeros bytes08 D7 contener información sobre el bloque codificado. Y los últimos cuatro bytes0F FE 02 FE debe ser la suma de comprobación ADLER32.
Esto finalmente me deja con los siguientes bytes:
05 C1 01 01 00 00 00 80 10 FF 4F 17 10 48 06
Escritos en representación binaria, estos bytes son:
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
Para entender mejor DESINFLAR intenté "desempaquetar" esta secuencia a mano al menos antes de entenderla lo suficientemente bien como para escribir una pequeña herramienta. Pero me quedé atrapado muy rápido.
RFC 1951 ("DEFLATE Especificación de formato de datos comprimidos") establece que cada bloque codificado comienza con un encabezado de tres bits. Un bit que indica si este es o no el último bloque y dos bloques más que indican el método de compresión. Como supongo que el codificador usó solo un bloque aquí (lo que significa que el primer bloque automáticamente es el último) y usó un árbol de Huffmann no estático, estoy buscando la secuencia de bits "101" pero no puedo encontrarla (ni encuentro otro probable encabezados "100" o "110").
Además, el RFC dice que debe haber dos valores de dos bytes LEN y NLEN que almacenan la longitud del bloque donde NLEN es el complemento de LEN, pero nuevamente no puedo encontrar cuatro bytes que satisfagan esta condición. Ni siquiera comenzaré con mi suerte de encontrar algo que pueda representar a los dos árboles Huffmann.
Leí RFC 1951 y 1950 ("Especificación de formato de datos comprimidos ZLIB" así como los artículos de Wikipedia sobre codificación zlib, DEFLATE, LZ77 y Huffman, así como varios artículos pequeños y poco útiles en la web y algunas respuestas sobre Stack Overflow, pero ninguno me pudo ayudar con mi falta de comprensión.
¡Estaría realmente agradecido por cualquier ayuda o sugerencia!