gpt4 book ai didi

compression - 为什么忽略 PNG 放气 block 长度?

转载 作者:行者123 更新时间:2023-12-04 03:15:01 25 4
gpt4 key购买 nike

总结:我需要一个 PNG 编写器,出于各种原因我不得不从头开始。我不需要压缩图像数据,所以我使用无压缩 deflate 算法实现了 PNG。需要多个压缩 block 的图像渲染失败,似乎是因为它忽略了 block 长度。

问题:当我用单个放气 block 写入一个小图像时,生成的图像正是它应该的样子(所有像素正确,使用 pngcheck 检查时没有错误) .但是,一旦我使用多个 deflate block ,结果图像就会出错,因为 deflate block 被读取超过了它们的长度(尽管 pngcheck 仍然没有显示错误)。在十六进制编辑器中查看原始数据似乎表明一切都符合规范(根据 libpng、RFC 1950 和 RFC 1951)。

示例数据:我生成了一个 3x1 RGBA 图像,其中像素颜色从左到右为 (fb,02,03,fa) (01,fc,03,fa), (01,02,fd,fa)。然后我将它们写入具有 8 字节或 64 字节最大压缩 block 长度的文件。 64 字节 block 长度图像完全正确并正确呈现。

后面是完整的图像内容,如十六进制,其中粗体是 block 长度,斜体是 block 数据。

8 字节 block 图像(呈现不正确):
89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 00 00 00 03 00 00 00 01 08 06 00 00 00 1b e0 14 b4 00 00 00 1d 49 44 41 5c 70 >00 08ff f700 fb 02 03 fa 01 fc 030100 05ff fafa 01 02 fd fa05 ee ac ee a1 e1 2d b9 00 00 00 00 49 45 4e 44 ae 42 60 82

64 字节 block 图像(正确呈现):
89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 00 00 00 03 00 00 00 01 08 06 00 00 00 1b e0 14 b4 00 00 00 18 49 44 41 9 5c 718 >00 0dff f200 fb 02 03 fa 01 fc 03 fa 01 02 fd fa05 ee ac ee f8 dc a0 6c 00 00 00 00 49 45 4e 44 ae 42 60 82

每个 deflate block 的开头由 5 个字节组成:0 或 1(取决于它是否是最终 block )后跟 2 字节长度(上面的粗体)及其 2 字节的补码。在 8 字节的 block 图像中,第一个 block 的长度是 8,这是应该的。长度补码后的 8 个字节(上面的斜体)确实是它们应该是的值,第 9 个字节等于 1(并开始最后一个 block )。然而,1 被解释为颜色值(第二个像素的 alpha)而不是下一个 block 的开始!

关于 deflate block 的结构,大概有一些我遗漏的东西。是我太笨而犯了错误,还是我误解了规范?

最佳答案

两个 PNG 文件都是无效的,即使其中一个文件恰好渲染正确(即使 pngcheck 没有捕捉到它)。它们都没有正确终止嵌入式压缩流。

查看 deflate 流之一,存储的长度和补码是大端而不是小端。例如。而不是 00 0d ff f2 它需要是 0d 00 f2 ff

关于compression - 为什么忽略 PNG 放气 block 长度?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/32633486/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com