libjpeg 中的 "CCIR601_sampling" 是什么？
What is "CCIR601_sampling" in libjpeg?
如标题所述：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 应该做什么？它是作为压缩、解压缩或两者的 user-settable 参数吗？它是否作为文件格式的一部分存储？为什么它从未真正实施过？
我已经在邮件列表 (https://groups.google.com/g/libjpeg-turbo-users/c/Aeacg_cq5ms) 上询问了 libjpeg-turbo 维护者。以下是部分回复：
To the best of my understanding, the libjpeg API and algorithms adhere to the RGB-to-YCbCr conversion formulae specified in CCIR 601 (now ITU-R Recommendation BT.601). The "CCIR601_sampling" field in the libjpeg API is meant to allow for future support of co-sited Cb and Cr samples-- that is, to allow for the sample arrangement used in MPEG-2. That sample arrangement is non-planar and specifies a row of Y samples, then a row of packed Cb/Cr samples, then another row of Y samples, etc.
... Thus, the fact that Rec. 601 sampling isn't implemented in libjpeg v6b means that JPEG files with that sampling arrangement are basically non-existent "in the wild." The JPEG specification supports other features, including a lossless mode, but ultimately, the de facto definition of the "JPEG format" converged to the subset of features implemented by libjpeg v6b (per Tom Lane's original goal.) To this day, that same chicken-and-egg phenomenon means that web browsers don't support arithmetic-coded JPEG files, even though the patent on arithmetic coding expired long ago and libjpeg-turbo supports those files.
... The "CCIR601_sampling" field remains in the API because the API structures are exposed. Thus, removing the field would break backward ABI compatibility, and backward ABI compatibility is one of the primary reasons (performance is the other) why libjpeg-turbo became the preferred open source JPEG library.
结论：CCIR601_sampling 旨在作为 JPEG compression 的 user-settable 参数， 会 生成了一个包含“co-sited”CbCr 组件的 JPEG 文件（两个组件存储在一起作为一个“组件”，而不是保留两个单独的 Cb 和 Cr 平面）。在解压时，jpeg_read_header() 应该在结构中设置字段以指示此 JPEG 是 CCIR601 格式（它不是 user-settable 解压参数，而是一个指示符）
当然libjpeg不支持这种模式，因此没有使用它的JPEG，所以没有必要支持这种模式。
如标题所述：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 应该做什么？它是作为压缩、解压缩或两者的 user-settable 参数吗？它是否作为文件格式的一部分存储？为什么它从未真正实施过？
我已经在邮件列表 (https://groups.google.com/g/libjpeg-turbo-users/c/Aeacg_cq5ms) 上询问了 libjpeg-turbo 维护者。以下是部分回复：
To the best of my understanding, the libjpeg API and algorithms adhere to the RGB-to-YCbCr conversion formulae specified in CCIR 601 (now ITU-R Recommendation BT.601). The "CCIR601_sampling" field in the libjpeg API is meant to allow for future support of co-sited Cb and Cr samples-- that is, to allow for the sample arrangement used in MPEG-2. That sample arrangement is non-planar and specifies a row of Y samples, then a row of packed Cb/Cr samples, then another row of Y samples, etc.
... Thus, the fact that Rec. 601 sampling isn't implemented in libjpeg v6b means that JPEG files with that sampling arrangement are basically non-existent "in the wild." The JPEG specification supports other features, including a lossless mode, but ultimately, the de facto definition of the "JPEG format" converged to the subset of features implemented by libjpeg v6b (per Tom Lane's original goal.) To this day, that same chicken-and-egg phenomenon means that web browsers don't support arithmetic-coded JPEG files, even though the patent on arithmetic coding expired long ago and libjpeg-turbo supports those files.
... The "CCIR601_sampling" field remains in the API because the API structures are exposed. Thus, removing the field would break backward ABI compatibility, and backward ABI compatibility is one of the primary reasons (performance is the other) why libjpeg-turbo became the preferred open source JPEG library.
结论：CCIR601_sampling 旨在作为 JPEG compression 的 user-settable 参数， 会 生成了一个包含“co-sited”CbCr 组件的 JPEG 文件（两个组件存储在一起作为一个“组件”，而不是保留两个单独的 Cb 和 Cr 平面）。在解压时，jpeg_read_header() 应该在结构中设置字段以指示此 JPEG 是 CCIR601 格式（它不是 user-settable 解压参数，而是一个指示符）
当然libjpeg不支持这种模式，因此没有使用它的JPEG，所以没有必要支持这种模式。