libjpeg 中的“CCIR601_sampling”是什么？

Question

正如标题所述：libjpeg 中的jpeg_compress_struct 和jpeg_decompress_struct 都有一个如下定义的字段：

boolean CCIR601_sampling;     /* TRUE=first samples are cosited */

我很难弄清楚这意味着什么，或者应该如何使用它。如果您尝试将此标志设置为true，用于压缩或解压缩，libjpeg 将简单地触发致命错误并显示此消息：

JMESSAGE(JERR_CCIR601_NOTIMPL, "CCIR601 sampling not implemented yet")

“还”很有趣，因为这种情况已经有 20 多年了，至少可以追溯到 libjpeg62。

那么，CCIR601_sampling 应该做什么？它是作为用户可设置的压缩、解压缩参数，还是两者兼而有之？它是否存储为文件格式的一部分？为什么它从未真正实施过？

Answer 1

我已经在邮件列表 (https://groups.google.com/g/libjpeg-turbo-users/c/Aeacg_cq5ms) 上向 libjpeg-turbo 维护者询问了这个问题。以下是部分回复：

据我所知，libjpeg API 和算法遵循 CCIR 601（现为 ITU-R Recommendation BT.601）中指定的 RGB 到 YCbCr 转换公式。 libjpeg API 中的“CCIR601_sampling”字段旨在允许将来支持共址 Cb 和 Cr 样本——也就是说，允许 MPEG-2 中使用的样本排列。该样本排列是非平面的，它指定一行 Y 样本，然后是一行压缩 Cb/Cr 样本，然后是另一行 Y 样本，等等。

...因此，Rec。 libjpeg v6b 中未实现 601 采样意味着具有该采样排列的 JPEG 文件基本上不存在“在野外”。 JPEG 规范支持其他功能，包括无损模式，但最终，“JPEG 格式”的实际定义收敛到 libjpeg v6b 实现的功能子集（根据 Tom Lane 的最初目标）。 -and-egg 现象意味着 Web 浏览器不支持算术编码的 JPEG 文件，尽管算术编码的专利早已过期并且 libjpeg-turbo 支持这些文件。

...“CCIR601_sampling”字段保留在 API 中，因为 API 结构已公开。因此，删除该字段会破坏向后 ABI 兼容性，而向后 ABI 兼容性是 libjpeg-turbo 成为首选开源 JPEG 库的主要原因之一（性能是另一个）。

总结：CCIR601_sampling 旨在作为用户可设置的 JPEG 参数压缩，会生成一个包含“共同定位”CbCr 组件的 JPEG 文件（两种成分作为一个“成分”存储在一起，而不是剩余的两个单独的 Cb 和 Cr 平面）。解压时，jpeg_read_header() 应在结构体中设置字段以指示此 JPEG 为 CCIR601 格式（它不是用户可设置的解压参数，而是一个指示符）

当然libjpeg 不支持这种模式，因此没有使用它的JPEG，所以没有必要支持这种模式。