正如标题所述：libjpeg 中的 thejpeg_compress_struct和 the jpeg_decompress_structin 都有一个如下定义的字段：
boolean CCIR601_sampling; /* TRUE=first samples are cosited */
我很难弄清楚这意味着什么，或者应该如何使用它。如果您尝试将此标志设置为true，用于压缩或解压缩，libjpeg 将简单地触发致命错误并显示此消息：
JMESSAGE(JERR_CCIR601_NOTIMPL, "CCIR601 sampling not implemented yet")
“还”很有趣，因为这种方式已经有 20 多年了，至少回到 libjpeg62。
那么，CCIR601_sampling 应该做什么呢？它是作为用户可设置的压缩、解压缩参数，还是两者兼而有之？它是否存储为文件格式的一部分？为什么它从未真正实施过？
我已经在邮件列表（ 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。601 采样未在 libjpeg v6b 中实现，这意味着具有该采样排列的 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，所以没有必要支持这种模式。