ITU T.87 JPEG LS 标准和示例 .jls SOS 编码流没有转义序列 0xFF 0x00

如何解决ITU T.87 JPEG LS 标准和示例 .jls SOS 编码流没有转义序列 0xFF 0x00

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) 为了确保一个标记 不会出现在熵编码段内，任何 X'FF' 字节 由霍夫曼或算术编码器或 X'FF' 字节生成 由上述注释 1 中描述的 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 进行编码？

解决方法

答案： ITU T.87 - 附件 A - A1 点 - 通过 3

标记段插入到附件中指定的数据流中 D. 为了便于检测标记片段，单个 编码图像数据段中值为 X'FF' 的字节应为 随后插入一个位“0”。这个插入的位 应占用下一个字节的最高有效位。如果 X'FF' 字节后跟单个位“1”，则解码器应处理 字节作为标记的第二个字节，并在 与附件 C 一致。如果编码器插入了“0”位，则 解码器应丢弃插入的位，该位不构成 要解码的数据流。

注意 2 – 此标记段检测 程序与 CCITT Rec. 中规定的程序不同。 T.81 |国际标准化组织/国际电工委员会 10918-1。

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