Что такое "CCIR601_sampling" в libjpeg?
Как говорится в названии: Оба 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? Означает ли это параметр, устанавливаемый пользователем для сжатия, распаковки или того и другого? Сохраняется ли он как часть формата файла? И почему его так и не реализовали?
0 ответов
Я спросил
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, которые его используют, поэтому нет необходимости поддерживать этот режим.