问TIFF CCITT Group 4解压缩(T.6)的算法问题

EN

我在一家工程设计公司工作，我们以TIFF格式存储黑白设计图，用CCITT Group 4压缩。

我正在从事一个项目，以改善我们的软件与这些图纸的工作。显然，我需要能够将原始数据加载到我的程序中，所以我必须对其进行解压缩。

我试过使用LibTiff，但很快就放弃了。它不会构建，生成了超过2000个错误。我在库中发现了许多明显的语法错误，并得出结论说它是垃圾。我花了大约3个小时试图找到实现CCITT Group 4编解码器的库的一部分，但没有运气，代码是一堆令人费解的东西。

因此，我正在为该程序编写自己的编解码器。我让它基本上工作得很好，但我被一个问题卡住了。我找不到关于这种格式的好文档。有很多很好的概述，大致描述了2D修改后的Huffman压缩是如何工作的，但我找不到任何具体的，实现级别的细节。因此，我试图通过使用一些绘图文件作为示例来解决这个问题。

我的垂直模式和pass模式工作得很好，并且我的算法可以在图像进入向导并产生垃圾之前正确地解压缩大约三分之一的图像。

我将问题追溯到水平模式。我的水平模式算法期望看到水平模式代码001，然后是一组补充代码(可选)和当前笔颜色的终止代码，然后是另一组补充代码(可选)和相反颜色的终止代码。

这个算法在图像的三分之一处工作得很好，但突然我遇到了一个水平模式运行，其中相反的颜色出现在当前笔的颜色之前。

图像的这一部分是12个黑色像素的游程，后面是22个白像素的游程。

该部分的码位是00100000110000111，它解码为水平(001) 22白色(0000011) 12黑色(0000111 )，如您所见，这与像素在图像中出现的顺序相反。

因为我的算法需要图像顺序列表，所以它崩溃了。但同一图像文件中之前的307个水平模式实例都是按图像顺序排列的。到目前为止，这是我找到的唯一一个反向的。

其他图像处理程序可以很好地显示此文件。我尝试手动编辑图像文件中的位，只是为了测试图像的顺序，这会导致其他图像程序在解码图像时崩溃。这让我相信他们有某种方法可以知道在这种情况下情况是相反的。

有谁知道这个TIFF CCITT G4编码的具体实现层细节，它可以帮助我理解运行代码有时是如何以及为什么被颠倒的？

谢谢Josh