pdf - 当长度未知时，是否可以使用 libtiff 解码 CCITT 编码的数据？

Question

在这个问题的答案中:c++ decode CCITT encoded images in pdfs

指出libtiff可用于解码CCITT编码的图像。当然，我们必须预先添加一个 TIFF header 才能将 CCITT 流转换为有效的 TIFF 文件。

但是，PDF 文件中的某些图像是内嵌图像，并且没有给出它们的长度，尽管给出了它们的宽度、高度和位深。读取 PDF 的程序应该对 CCITT 流进行解码，读取(宽 * 高 * 深)位的解码数据，并且在读取数据后的任何位置，都是内嵌图像的结尾。然后它应该继续执行下一页标记命令，依此类推。

这带来了一个问题。一个 TIFF 图像文件目录必须指定图像数据的每个 strip 中有多少字节，但在解码之前我们不知道编码数据中有多少字节实际上属于图像，但我们不能在不使用 libtiff 的情况下解码图像...

有没有办法在这里使用 libtiff 或者我们是否需要自定义 CCITT 过滤器代码？

Answer 1

严格来说(是否可以使用 libtiff...？)，是 .它涉及一些黑客行为，但不会太多。

事实:数据将由一个 strip 组成，因为没有任何偏移量信息，所以我们唯一的偏移量为零。我们只需要读取 strip 。

事实:这个数据是一个 W*H 1-bit 深像素矩阵的压缩。

步骤1:估计压缩流的最大可能长度。这大约是 W*H 的 15%，即 W=1000 和 H=1000，你得到 150000 字节。该值将始终大于实际值。如果我们因为找到了正确的 EI 最终图像标签而有更好的估计，那就更好了，但不是必需的。

第 2 步:构建“虚拟”TIF 文件。这将由 49 49 2a 00 AA BB CC DD 形式的标题组成, 其中 0xDDCCBBAA 是估计长度加 8；其次是我们估计的数据流；后跟一个 TIFF 目录。

第3步:TIFF目录将始终具有相同的结构；其中的一些值是偏移量，并且与 IFD 位置 0xDDCCBBAA 无关。引用 TIFF6 规范(注意字节顺序是颠倒的 - 摩托罗拉，而不是 Intel 字节序):

TIFF 6.0 Specification Final—June 3, 1992                         20

Putting it all together (along with a couple of less-important fields that are discussed
later), a sample bilevel image file might contain the following fields

A Sample Bilevel TIFF File

Offset Description Value
(hex) (numeric values are expressed in hexadecimal notation)
Header:
0000 Byte Order     4D4D 
0002 42             002A
0004 1st IFD offset 00000014
IFD:
0014 Number of Directory Entries 000C
0016 NewSubfileType              00FE 0004 00000001 00000000
0022 ImageWidth                  0100 0004 00000001 000007D0
002E ImageLength                 0101 0004 00000001 00000BB8
003A Compression                 0103 0003 00000001 8005 0000
0046 PhotometricInterpretation   0106 0003 00000001 0001 0000
0052 StripOffsets                0111 0004 000000BC 000000B6(*1)
005E RowsPerStrip                0116 0004 00000001 00000010
006A StripByteCounts             0117 0003 000000BC 000003A6(*2)
0076 XResolution                 011A 0005 00000001 00000696(*3)
0082 YResolution                 011B 0005 00000001 0000069E(*4)
008E Software                    0131 0002 0000000E 000006A6(*5)
009A DateTime                    0132 0002 00000014 000006B6(*6)
00A6 Next IFD offset             00000000
Values longer than 4 bytes:
(*1) StripOffsets Offset0        00000008
(*2) StripByteCounts Count0
(*3) XResolution 0000012C 00000001
(*4) YResolution 0000012C 00000001
(*5) Software “PageMaker 4.0”
(*6) DateTime “1988:02:18 13:59:59”

在上面，0xDDCCBBAA 实际上是 0014，所有其他偏移量都在后面。

我使用我用 ImageMagick 和 tiffcp 生成的单条 TIFFG4 图像做了一些测试。 'ed 为 1-strip CCITT 格式。那里的标题略有不同(我没有看到规范所说的软件和日期时间标签)。否则它会检查。

我们现在有一个 损坏 带有一个超长 strip 的 TIFF 图像，它在内存中。

使用 TIFFClientOpen ，我们可以 access it as if it was a disk image .

尝试读取第一个 strip 现在将导致错误并且程序中止:

TIFFFillStrip: Read error on strip 0; got 143151 bytes, expected 762826.

通过使用 TIFFSetErrorHandler和 TIFFSetErrorHandlerExt我们设置自己拦截这个错误，并解析它，从而恢复 143151信息，而不是中止。

我们需要提供对 TIFFClientOpen 的回调，但它们都非常简单:

TIFFReadWriteProc readproc(h, *ptr, n) // copy n bytes from FakeBuffer+pos into ptr, update pos to pos + n, ignore h.
TIFFReadWriteProc writeproc            // Throw an error. We don't write
TIFFSeekProc seekproc                  // update pos appropriately
TIFFCloseProc closeproc                // do nothing
TIFFSizeProc sizeproc                  // return total buffer size
TIFFMapFileProc mapproc                // Set to NULL
TIFFUnmapFileProc unmapproc            // Set to NULL

处理过程确实很别扭，很复杂，但至于可行性，它
可以做到。

我已经用 C 语言运行了测试，从我在网上找到的内联图像 BI/ID/EI PDF 中手动提取 CCITT 流，并如上所述阅读它。

如果我有一种可靠的方法来识别正确的 EI - 我已经挖掘了 a message by Tilman Hausherr解释一个 hack 以识别遵循 EI 的有效 PDF 运算符以便这样做，这让我认为可能没有太多更好的方法 - 我总是可以估计正确的偏移量，并直接从 PDF 生成正确且可读的 TIFF 文件甚至根本不涉及 libtiff。