Что такое "CCIR601_sampling" в libjpeg?

Question

Как говорится в названии: Оба jpeg_compress_struct и jpeg_decompress_struct в libjpeg есть поле, определенное следующим образом:

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

Я спросил libjpeg-turboоб этом в списке рассылки (https://groups.google.com/g/libjpeg-turbo-users/c/Aeacg_cq5ms). Вот часть ответа:

Насколько я понимаю, API и алгоритмы libjpeg соответствуют формулам преобразования RGB-в-YCbCr, указанным в CCIR 601 (теперь Рекомендация ITU-R BT.601). Поле "CCIR601_sampling" в libjpeg API предназначено для обеспечения будущей поддержки совмещенных сэмплов Cb и Cr, то есть для того, чтобы учесть расположение сэмплов, используемое в MPEG-2. Это расположение выборок не является планарным и задает строку из выборок Y, затем строку упакованных выборок Cb/Cr, затем другую строку из выборок Y и т. Д.

... Таким образом, тот факт, что Рек. Выборка 601 не реализована в libjpeg v6b, что означает, что файлы JPEG с такой схемой выборки практически не существуют "в дикой природе". Спецификация JPEG поддерживает другие функции, включая режим без потерь, но в конечном итоге определение де-факто "формата JPEG" сошлось с подмножеством функций, реализованных libjpeg v6b (согласно первоначальной цели Тома Лейна). По сей день та же курица Феномен -and-egg означает, что веб-браузеры не поддерживают файлы JPEG с арифметическим кодированием, хотя патент на арифметическое кодирование давно истек, а libjpeg-turbo поддерживает эти файлы.

... Поле "CCIR601_sampling" остается в API, потому что структуры API доступны. Таким образом, удаление поля нарушит обратную совместимость с ABI, а обратная совместимость с ABI является одной из основных причин (производительность - другая), почему libjpeg-turbo стала предпочтительной библиотекой JPEG с открытым исходным кодом.

В заключении: CCIR601_samplingбыл задуман как настраиваемый пользователем параметр для сжатия JPEG, что привело бы к созданию файла JPEG, содержащего "совместно размещенные" компоненты CbCr (оба компонента хранятся упакованными вместе как один "компонент", а не остаются двумя отдельными плоскостями Cb и Cr). При декомпрессии jpeg_read_header() должен установить поле в структуре, чтобы указать, что этот JPEG отформатирован CCIR601 (это не настраиваемый пользователем параметр декомпрессии, а индикатор)

Конечно libjpeg не поддерживает этот режим, поэтому не существует файлов JPEG, которые его используют, поэтому нет необходимости поддерживать этот режим.