我的一个工程设计公司工作，我们存储与CCITT Group 4压缩压缩的TIFF格式黑色和白色的设计图纸。
我工作的一个项目，以改善我们与这些图中工作的软件。 我需要能够将原始数据加载到我的计划很明显，所以我必须解压缩。
我尝试使用的libtiff而是迅速上放弃了。 它不会建立，产生超过2000个错误。 我发现许多明显的语法错误在库中，得出的结论是垃圾。 我花了大约3个小时试图找到一个实现CCITT组4编解码器，但没有运气，该代码是不可理解的混乱库的一部分。
因此，它是我写我自己的编解码器程序。 我有它主要是运作良好，但我坚持的一个问题。 我无法找到这种格式良好的文档。 有很多通常描述2D如何改进的霍夫曼压缩的作品很好的概述的，但我不能找到任何有具体的，执行层面的细节。 所以，我想通过一些图形文件为例来解决它。
我有垂直并通过运作良好的模式和我的解压缩算法对图像正常的三分之一它熄灭的向导之前，产生的垃圾。
我跟踪这个问题的水平模式。 我给水平模式算法期望看到水平模式代码001随后通过一组化妆码（可选）和在当前的笔的颜色的终止代码，接着另一组的化妆码（可选）和在一个终止代码相反的颜色。
该算法工作的很好的通过图像的方式第三，但突然我遇到了一个水平模式运行，其中对颜色来自当前的画笔颜色之前。
图像的部分是12个黑象素，接着的22个白色像素运行运行。
从该部分的码位是00100000110000111其进行解码，以水平（001）22白色（0000011）12黑色（0000111），其作为可以看到的是，其中的像素出现在图像中的顺序相反。
由于我的算法预期影像为了上市，它崩溃。 但在这同一个图像文件的水平模式之前的307个实例都在图像顺序。 这是唯一一个相反我发现（到目前为止）。
其他成像方案显示此文件就好了。 我试图手动编辑图像文件中的比特只是作为测试把顺序图象的顺序与使其他成像程序崩溃的图像进行解码时。 这使我相信他们已经知道它是在那种情况下逆转的一些方法。
任何人都知道这个TIFF CCITT G4编码，可以帮助我了解如何以及为什么运行代码有时逆转具体执行层面的细节？
由于乔希
