2

I am in the middle of writing a TIFF decoder. The LZW decoder I am using works fine with all the LZW compressed GIF and TIFF images except one which will overflow the buffer of the decoded code string. I tested it with TIFFLZWDecompressor from com.sun.media.imageioimpl.plugins.tiff package and it throws the following exception "java.lang.UnsupportedOperationException: TIFF 5.0-style LZW codes are not supported".

I have been trying to find what is special about the 5.0-style LZW without success. Does anyone have any idea about this?

Note: from TIFFLZWDecompressor source code, the indicator for a TIFF 5.0-style LZW compression is the first two bytes {0x00, 0x01} of the compressed data.

4

2 回答 2

4

我最近在编写 TIFF LZW 编码器时遇到了同样的问题。TIFF 检查工具在正确解码图像时抱怨“旧式 LZW 代码”。经过一番研究，我发现 LZW 压缩机的实现发生了变化。原始（“旧式”）格式使用与 GIF LZW 压缩器完全相同的操作模式。实际上，您可以使用有效的 GIF 压缩器并将其轻松嵌入 TIFF 实现中，并且它会生成大多数 TIFF 阅读器都接受的文件。（我发现一个值得注意的例外是 Corel PaintShop Pro X7。）

“旧式”和“新式”之间的区别适用于两个编码细节：

  • LZW 代码以相反的位顺序写入流。
  • “New-style”比“old-style”提前一个符号增加代码大小（所谓的“Early Change”）。

聪明的 TIFF 解码器检查比特流的前一个或两个字节以检测“旧式”编码。这是可能的，因为发出的第一个符号始终是明码 0x100。如果第一个字节是 0x00，那么显然是前 1 位之后的 8 个零位，所以它是“旧式”。“新式”比特流从 1 位开始，所以第一个字节是 0x01。

于 2017-08-04T13:05:51.143 回答
2

TIFF 6.0 规范说：

还可以实现 LZW 的一个版本，其中 LZW 字符深度等于 BitsPerSample，如修订版 5.0 的草案 2 中所述。但是这种方法存在一个主要问题。如果 BitsPerSample 大于 11，我们就不能使用 12 位最大代码，并且生成的 LZW 表大到无法接受。

（TIFF6.pdf，第 58-59 页）

这可能就是他们所指的。

另一方面......在我自己的读者中，我发现：

注意：这是违反规范的。但是，libTiff 会读取此类文件。TIFF 6.0 规范，第 13 节：“LZW 压缩”/“算法”，第 61 页，说：LZW 压缩代码以从高到低的顺序存储到字节中，即假定 FillOrder 为 1。代码以字节（而不是字）形式写入，因此无论是“II”还是“MM”文件，压缩数据都是相同的。”

关于 0x00, 0x01 实际上是“反向”中的“清晰代码”（即，按照字节顺序，而不是像规范所说的那样忽略它）。

于 2014-10-14T17:40:31.630 回答