1

ITU T.81 声明如下：

B.1.1.2 标记 标记用于识别压缩数据格式的各种结构部分。大多数标记开始包含一组相关参数的标记段；一些标记是独立的。所有标记都分配有两个字节的代码：一个 X'FF' 字节后跟一个不等于 0 或 X'FF' 的字节（见表 B.1）。任何标记之前都可以有任意数量的填充字节，这些填充字节是分配代码 X'FF' 的字节。注 – 由于这种特殊的代码分配结构，标记使解码器能够解析压缩数据并定位其各个部分，而无需解码图像数据的其他段。"

B.1.1.5 熵编码数据段熵编码数据段包含熵编码过程的输出。它由整数个字节组成，无论使用的熵编码过程是霍夫曼还是算术。

笔记

(1)使熵编码的段成为整数字节的执行如下：对于霍夫曼编码，如果需要，使用 1 位来填充压缩数据的末尾以完成段的最后一个字节。对于算术编码，字节对齐在终止熵编码段的过程中执行（见 D.1.8）。

(2)为了确保标记不会出现在熵编码段中，由 Huffman 或算术编码器生成的任何 X'FF' 字节，或由填充 1 生成的 X'FF' 字节上面注 1 中描述的位，后面是“填充的”零字节（见 D.1.6 和 F.1.2.3）。

并且在许多其他地方，众所周知的Stuff_0 () 函数也被命名。

不确定标准 ITU T.87 相对于标准 ITU T.81 指定的编码转义序列 0xFF 0x00 的位置：

  • 标准 ITU T.87 本身没有指定但期望它。在标准测试样本格式不正确的情况下，编码流中显然没有编码转义序列 0xFF 0x00。例如 0xFF 0x7F、0xFF 0x2F 和其他序列可以在 .jsl 测试样本的编码流中找到：即“T8C0E3.JLS”。这些年来没有人看到它；
  • 或者，如果标准 ITU T.87 实际上覆盖了关于编码流的这条规则的 ITU T.81，并且不允许转义序列的编码；

在解码器中，当 0xFF 和 !0x00 实际使用该字节并且如果组件未完全解码时不跳过它时，我们可以制定逻辑来检测解码器错误。但是如果 jls 文件没有转义序列并且我们遇到 0xFF 0x00 序列，我们应该跳过 0x00 字节吗？

希望对标准 ITU T.87 JPEG-LS 编码的主题进行一些澄清，以及正确的程序是什么。我们应该或不应该在编码流中编码转义序列 0xFF 0x00 吗？

4

1 回答 1

1

答案：ITU T.87 - 附件 A - 点 A1 编码参数和压缩图像数据 - 通过 3

标记段按照附件 D 的规定插入到数据流中。为了便于标记段的检测，编码图像数据段中的值为 X'FF' 的单个字节后应插入单个位'0'。该插入位应占据下一个字节的最高有效位。如果 X'FF' 字节后跟单个位“1”，则解码器应将其后的字节视为标记的第二个字节，并根据附件 C 对其进行处理。如果是“0”位由编码器插入，解码器应丢弃插入的位，该位不构成要解码的数据流的一部分。

注 2 — 该标记段检测程序不同于 CCITT Rec. 中规定的程序。T.81 | ISO/IEC 10918-1。

JPEG-LS T.87 覆盖 T.81 JPEG 标准，用于编码数据流具有字节 0xFF，后跟值介于 0x00 和 0x7F（含）之间的字节。

于 2021-06-09T23:32:19.083 回答