c - PNG文件格式的IDAT block

Question

我目前正在开发一种基于 png 文件格式的专有文件格式。到目前为止我已经完成了，除了它不起作用:-p 我实现的 deflate 解压缩器就像一个魅力，但 png 解码器不想表现得很好，所以我查看了原始的 png 文件。

标准规定，在 IDAT header 之后，压缩数据紧随其后。因此，由于数据是放气流，IDAT 之后的第一个字符是 0x78 == 01111000，这意味着模式一 block (未压缩)并且它不是最终 block 。

不过很奇怪——我很难想象 PNG 编码器不使用动态霍夫曼编码来压缩过滤后的原始图像数据。 deflate 标准表示在模式一中跳过当前字节的其余部分。

因此接下来的四个字节表示未压缩 block 的大小及其一个补码。但是 0x59FD 不是 0xECDA 的一个补码。即使我搞砸了字节顺序:0xFD59 也不是 0xDAEC 的唯一补码。

好吧，淘汰字节就在后面。 0x97 被认为是未压缩但仍过滤的原始 png 图像数据的第一个字节，因此必须是过滤器类型。但是 0x97 == 10010111 不是有效的过滤器类型。如果我搞砸了位打包顺序 11101001 == 0xe9 的事件仍然没有有效的过滤器类型。

我不再关注 RFC 1951，因为到目前为止我能够使用我的 deflate 解压缩器实现来扩充所有类型的文件，所以我怀疑我对 PNG 标准存在一些误解。

我一遍又一遍地阅读 RFC 2083，但我在这里看到的数据与 RFC 不符，这对我来说没有意义，一定有一个缺失的部分!

当我查看以下字节时，我实际上在附近的任何地方都看不到有效的过滤器类型字节，这让我认为过滤后的 png 数据流毕竟还是被压缩了。

如果 0x78(IDAT 之后的第一个字节)从 MSB 读取到 LSB 是有意义的，但 RFC 1951 另有规定。另一个想法(对我来说更可能)是在 IDAT 字符串和压缩的 deflate 流的开始之间有一些数据，但 RFC 2083 另有说明。布局清晰

4字节大小4Bytes ChunkName (IDAT)[大小] 字节(压缩的 deflate 流)4字节CRC校验和

所以 IDAT 之后的第一个字节必须是压缩的 deflate 流的第一个字节 - 这表示模式 1 未压缩的数据 block 。这意味着 0x97 必须是未压缩但已过滤的 png 图像数据的第一个字节 - 这意味着 0x97 是第一行的过滤器类型 - 这是无效的...

我只是不明白，我是愚蠢还是什么？

总结:可能性一:在 IDAT 和压缩的 deflate 流的有效开始之间还有一些其他数据，如果呈现为真，则在 RFC2083 和我读过的任何有关图像压缩的书中都没有提及。

可能性 2:数字 0x78 被解释为 MSB -> LSB，表示模式 3 block (动态霍夫曼编码)，但这与 RF1951 相矛盾，RF1951 对位打包非常清楚:(LSB -> MSB)

我已经知道，丢失的部分一定是非常愚蠢的，如果 Stack Overflow 中只有一个删除按钮，我会感到迫切需要出卖我的灵魂:-p

Answer 1

两个更正可以帮助您顺利上路:

1. 标志中的 zlib 字节数是 2，而不是 1 -- 见 RFC 1950 .第一个是CMF，下一个是FLG。

在您的数据中:

78 DA

---CMF---  ---FLG---
0111.1000  1101.0101
CINF -CM-  +-||
           | |+- FCHECK
           | +-- FDICT
           +---- FLEVEL

CINF为7，表示标准32Kb压缩窗口。
CM为8，表示压缩算法确实是DEFLATE。
FCHECK 只是一个校验和；我没有检查它是否正确(但我敢打赌)。
FDICT 明确，表示没有预置字典存储。
FLEVEL为3，表示最大压缩。

另见 Trying to understand zlib/deflate in PNG files ，特别是。博士。阿德勒的回答。

1. LEN 和 NLEN 只为未压缩的 block 设置；这就是为什么你没有找到他们。 (另外，部分原因是您查看了错误的字节。)

流中的下一个字节是EC；按位，这是 1110 1100 但记得从低位到高位读取位。所以读取的下一位是0，意思是not FINAL，接下来读取的2位是10(按这个顺序!)，表示一个常规动态霍夫曼编码数据 block 。