请澄清gif图像格式的预期行为

Question

如果我有一个gif89a，它有多个相同的图像块（并且很小，比如说大小为40x40或1600像素），那么它们是否应该继续增加gif文件的最终大小（假设一个合理的编码器）？

我试图了解LZW压缩的工作原理。根据W3C规范，我认为整个数据流本身（由多个图像块组成）应该被压缩，因此多次重复相同的图像帧会产生非常小的开销（只是重复的符号大小）图像块）。这似乎并非如此，我已经使用多种编码器（Gimp，Photoshop）进行了测试。

这对所有编码器来说都是预料之中，还是这两个编码器做得不好？

使用gimp，我的测试gif大小为23k，当时它有240个相同的图像块，58k大小有500个图像块，这看起来不像我的直觉告诉我那么令人印象深刻（我的直觉很愚蠢，所以当有人告诉我这是非常错误的时候，我会感到震惊。

[编辑]

我需要扩展我的目标，我认为，得到一个正确的答案。我想手工制作一个gif图像（并且可能会编写一个编码器，如果我可以写它），这将利用一些怪癖来比其他情况更好地压缩它。

我想在gif中包含多个子图像，这些子图像以平铺方式重复使用。如果图像很大（在这种情况下，1700x2200），gif不能很好地压缩瓷砖，因为它不会将它们视为瓷砖，它从左上角到右下角是光栅，最多是任何给定图块的30像素水平切片将被赋予符号并被压缩，而不是30x35图块本身。

在这种情况下，瓷砖本身只是字母表和一些标点符号，来自杂志的扫描。当然在原始扫描中，每个＆＃34; a＆＃34;与其他所有内容略有不同，这对压缩没有帮助，扫描中也有很多噪音，这无济于事。

由于每个图块将在图像中的某个位置重复几十到几百次，并且每个图块的大小是图块的任何给定切片的30或40倍，所以看起来有一些收益（假设gif文件格式可以向我的目标倾斜。）

我在gimp手工创建了另一个gif，它重复使用了25个子图像（大约700次，但我丢失了数）。它的解压缩尺寸为90k，但是拉链将其降低至11k。即使每个子图像具有不同的顶部/左侧坐标（但仅在子图像的标题中为4个字节），情况也是如此。

相比之下，具有单个帧的视觉上相同的图像是75k。这张图片不会被压缩。

还有其他问题我还没有找到文件（它的gif89a，并将其视为动画，即使我已经将每个帧设置为0ms的长度，所以你不能马上看到这一切）。我甚至无法开始考虑如何构建编码器来执行此操作...它必须选择任何字形的最佳外观（或至少一个更好看的版本），然后才能尽管它并不总是很好地排列，但最好的x，y才能覆盖它。

它的主要用途（我相信）将用于以cbr / cbz电子书扫描的杂志。

我也要嵌入我的手工制作的GIF，当我偶然发现这个解释时，我更容易看到我所看到的东西而不是阅读我的作品：

Answer 1

LZW（和GIF）压缩是一维的。图像被视为符号流，其中不使用任何区域到区域（术语中的块）对称。动画GIF图像只是一系列独立压缩的图像，可以通过各种合并选项应用于“主”图像。动画GIF更像是一个黑客而不是一个标准，并没有考虑到图像大小的效率。

有一个很好的解释，为什么在用重复的块压缩你的GIF之后你会看到较小的文件。 ZIP文件使用几种技术，其中包括“重复块”类型的压缩，这种技术可以很好地处理相同LZW数据的小（<32K）块（或小距离）。

GIF生成软件无法克服在不编写新标准的情况下压缩GIF图像的基本限制。 PNG使用稍微好一些的方法，它使用简单的二维滤波器来利用水平和垂直对称，然后使用FLATE压缩压缩结果。听起来你正在寻找的是一种更多的分形或视频方法，它可以具有一组压缩基元的概念，这些基元可以在最终图像中的不同位置重复。 GIF和PNG无法做到这一点。

Answer 2

GIF压缩是基于流的。这意味着要最大化压缩，您需要最大化流的可重复性。我不是使用方形图块，而是使用窄条来最小化在开始重复之前经过的数据量，然后将重复保留在同一个流中。

LZW代码大小的上限为12位，这意味着压缩表填充速度相对较快。当发生这种情况时，典型的编码器将输出清晰的代码，以便压缩可以重新开始，从而对新鲜内容提供良好的适应性。如果您使用自己的自定义编码器，则可以跳过清除代码并继续重用现有表以获得更高的压缩结果。

当给出延迟时间0时，GIF规范没有指定行为，因此您将受解码器实现的支配。为了获得一致的结果，您应该使用1的延迟并接受整个图像不会立即显示。