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)上询问了这位https://groups.google.com/g/libjpeg-turbo-users/c/Aeacg_cq5ms维护人员。以下是答复的一部分：

据我所知，libjpeg API和算法遵循CCIR 601 (现在的ITU建议BT.601)中指定的RGB到YCbCr转换公式。libjpeg API中的"CCIR601_sampling“字段是为了允许将来支持共同放置的Cb和Cr样品--也就是说，允许在MPEG-2中使用样本安排。该样品排列是非平面的，指定一排Y样品，然后是一排包装Cb/Cr样品，然后是另一排Y样品，等等。

..。因此，雷克。601采样不是在libjpeg v6b中实现的，这意味着带有这种采样安排的JPEG文件基本上不存在“在野外”。JPEG规范支持其他功能，包括无损模式，但最终，"JPEG格式“的实际定义收敛到libjpeg v6b实现的功能子集(根据Tom的最初目标)。直到今天，同样的“鸡与蛋”现象意味着网络浏览器不支持算术编码的JPEG文件，尽管算术编码的专利早已过期，libjpeg-turbo支持这些文件。

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

总之：CCIR601_sampling是作为JPEG 压缩的用户可设置参数，它将产生一个包含“共置”CbCr组件(两个组件作为一个“组件”存储在一起，而不是剩下的两个单独的Cb和Cr平面)的CbCr文件。在解压缩时，jpeg_read_header()应该在结构中设置字段以指示这个JPEG是CCIR601格式的(它不是一个用户可设置的解压缩参数，而是一个指示符)。

当然，libjpeg不支持这种模式，因此不存在使用它的JPEG，因此不需要支持这种模式。