libjpeg中的“ CCIR601_sampling”是什么？

问题描述

如标题所述：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应该做什么？它是作为用户可设置的压缩，解压缩参数还是两者一起使用？是否将其存储为文件格式的一部分？为何从未真正实施呢？

解决方法

我已在邮件列表（https://groups.google.com/g/libjpeg-turbo-users/c/Aeacg_cq5ms）上询问libjpeg-turbo维护者。这是响应的一部分：

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

...因此，事实libjpeg v6b中未实现601采样，这意味着具有这种采样方式的JPEG文件基本上“不存在”。 JPEG规范支持其他功能，包括无损模式，但最终，“ JPEG格式”的实际定义已收敛到libjpeg v6b实现的功能子集（按照汤姆·莱恩的最初目标。）直到今天，这只鸡还是一样-eg-egg现象表示，即使算术编码专利很早就过期并且libjpeg-turbo支持这些文件，Web浏览器也不支持算术编码JPEG文件。

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

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

当然libjpeg不支持此模式，因此不存在使用该模式的JPEG，因此无需支持此模式。