【发布时间】：2014-07-19 18:00:16
【问题描述】：
我在一家工程设计公司工作，我们以 TIFF 格式存储黑白设计图纸，并使用 CCITT Group 4 压缩。
我正在开展一个项目，以改进我们处理这些绘图的软件。我显然需要能够将原始数据加载到我的程序中，所以我必须解压缩它。
我尝试使用 LibTiff，但很快就放弃了。它不会构建，产生超过 2000 个错误。我在库中发现了许多明显的语法错误，并得出结论它是垃圾。我花了大约 3 个小时试图找到实现 CCITT Group 4 编解码器的库部分，但没有运气，该代码是一个难以理解的混乱。
所以我正在为程序编写自己的编解码器。我的大部分工作都很好，但我遇到了一个问题。我找不到关于这种格式的好的文档。有很多很好的概述描述了 2D Modified Huffman 压缩是如何工作的，但我找不到任何具有特定实现级别细节的概述。所以我试图通过使用一些绘图文件作为示例来解决它。
我的垂直和传递模式运行良好，我的算法在图像转到向导并产生垃圾之前正确解压缩了大约三分之一的图像。
我将问题追溯到水平模式。我的水平模式算法期望看到水平模式代码 001 后跟一组化妆代码（可选）和当前笔颜色的终止代码，然后是另一组化妆代码（可选）和终止代码相反的颜色。
该算法在图像的三分之一处运行良好，但突然我遇到了水平模式运行，其中相反的颜色出现在当前笔颜色之前。
图像的一部分是 12 个黑色像素，然后是 22 个白色像素。
该部分的代码位是 00100000110000111 ，它解码为水平 (001) 22 白色 (0000011) 12 黑色 (0000111 )，如您所见，这与像素在图像中出现的顺序相反。
由于我的算法需要图像订单列表，因此它会崩溃。但是同一个图像文件中之前的 307 个水平模式实例都是按图像顺序排列的。这是我发现的唯一一个反转的（到目前为止）。
其他成像程序可以正常显示此文件。我尝试手动编辑图像文件中的位，只是为了测试图像顺序，这会导致其他成像程序在解码图像时崩溃。这让我相信他们有某种方式知道在那种情况下它是相反的。
任何人都知道有关此 TIFF CCITT G4 编码的具体实现级别的详细信息，这可以帮助我了解运行代码有时如何以及为什么会被反转？
谢谢 乔什
【问题讨论】：
标签： tiff codec compression