Наследие и переход: создание нового универсального кодека изображений

Когда в конце 1980-х годов разрабатывался кодек JPEG, не существовало стандартизированных форматов сжатия изображений с потерями. JPEG был готов как раз в нужное время в 1992 году, когда всемирная паутина и цифровые фотокамеры собирались стать новой реальностью. Введение <img>тега HTML в 1995 году обеспечило признание JPEG в качестве веб-формата - по крайней мере, для фотографий. В 1990-х годах цифровые камеры заменили аналоговые, и, учитывая ограниченный объем памяти того времени, JPEG стал стандартным форматом для фотографии, особенно для фотокамер потребительского уровня.

С тех пор было несколько попыток «заменить JPEG» новым улучшенным кодеком:

- JPEG 2000 , который, найдя свою нишу в медицинских изображениях, цифровом кино и, в некоторой степени, в экосистеме Apple, не получил широкого распространения.

- JPEG XR (он же WDP) , который никогда не выходил за пределы экосистемы Microsoft.

- Google WebP , который был разработан для веб-изображений и которому, к сожалению, потребовалось 10 лет, чтобы получить поддержку всех основных браузеров. Его распространение все еще намного ниже, чем у JPEG.

- Обремененный патентами HEIC , который вряд ли будет с энтузиазмом воспринят за пределами экосистемы Apple.

- WebP 2, AVIF и JPEG XL – существуют не так давно. Только время покажет, заменит ли какой-либо из них JPEG.

Помимо более сильного сжатия, чем у JPEG, вышеуказанные кодеки предлагают новые технические функции, такие как поддержка альфа-прозрачности. Но заменить JPEG никому из них не удалось. Важно понимать, почему они потерпели неудачу и, что нужно для достижения успеха.

В своё время JPEG кардинально изменил ситуацию, переходя от несжатого или слабо сжатого без потерь изображения - по меркам начала 1980х годов - к изображению с потерями, значительно уменьшая размеры файлов.  Это сделало JPEG очевидным для принятия решением. Представляя ситуацию в перспективе, это означало ожидание загрузки изображения в течение пяти секунд вместо одной минуты  и сохранение от 20 до 50 изображений вместо одного или двух на флеш-карте. По сути, JPEG позволяет использовать веб-изображения и цифровые камеры, что было бы невозможно без JPEG.

Ни один новый кодек никогда не сможет сравниться с JPEG в такой степени. Чуть более сильного сжатия недостаточно, чтобы оправдать сложности и трудозатраты, необходимые для обновления всего программного обеспечения и платформ, связанных с изображениями, а это почти все программное обеспечение и все платформы. Вероятно, отчасти, JPEG 2000 и JPEG XR так и не стали популярными. Несмотря на то, что они сжимают изображения более эффективно, чем JPEG, и предлагают такие функции, как альфа-прозрачность и высокая битовая глубина, значительные затраты на переход перекрывают все преимущества.

Соображения по поводу принятия

Даже если новый кодек дает значительные технические преимущества по сравнению со старым, переходу препятствуют следующие факторы:

Новый кодек может быть обременен патентом и не свободен от лицензионных отчислений. Примерами являются HEIC и BPG. Сами по себе патентные ограничения являются серьезным сдерживающим фактором для всеобщего принятия. Хотя срок действия всех патентов JPEG уже истек, используется только бесплатная часть исходной спецификации JPEG.

Решения бесплатного программного обеспечения с открытым исходным кодом (FOSS) либо не существуют, либо уступают платному программному обеспечению, что долгое время было препятствием для принятия JPEG 2000. То же самое для JPEG XR, программное обеспечение которого хоть и обладает открытым исходным кодом, плохо поддерживается и не интегрировано в другие FOSS, возможно, из-за проблем с лицензированием.

Даже если новый кодек дает лучшие результаты, старый все же в некоторых отношениях обходит его. Три примера:

- PNG из- за отсутствия анимации не смог полностью заменить GIF, как предполагалось изначально.

- WebP принудительно использует субдискретизацию цветности 4: 2: 0, не поддерживает прогрессивное декодирование и ограничивает размеры изображения.

- JPEG 2000 сложен и часто медленнее, чем JPEG.

Всегда присутствует проблема курицы и яйца, чтобы убедить браузеры и другое программное обеспечение поддерживать новые кодеки. Если никто еще не использует новый кодек, почему они должны его поддерживать? И если они его не поддерживают, зачем кому-то это использовать?

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

Переходный процесс

Предположим, новый кодек X может сэкономить 50 процентов байтов, в результате чего альбом JPEG размером 1 ГБ с такой же точностью займет всего 500 МБ. Отлично, правда? Совершенно верно, если предположить, что вы начинаете кодировать цифровые изображения с нуля, но в реальности это не совсем так.

Пример этого альбома JPEG размером 1 ГБ является вашей базовой линией, однако исходные изображения давно исчезли и недоступны для выполнения альтернативного кодирования с использованием кодека X. Конечно, вы можете декодировать существующие файлы JPEG в пиксели, которые затем можно обработать, используя новый кодек - это типичный процесс перекодирования. Но это рискованный подход, потому что он приводит к потере генерации с артефактами кодека X поверх существующих артефактов JPEG.

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

Таким образом,  сохранить качество, уменьшить объем памяти и автоматизировать задачу, преобразовывая серию изображений с потерями в новый кодек с потерями, является сложной задачей. Существуют бесчисленное количество изображений в формате JPEG—за последние пять лет их было создано более триллиона,—однако большинство новых кодеков не могут справиться с ними удовлетворительно. Самое безопасное, что можно сделать, - это просто сохранить их такими, какие они есть, и кодировать с помощью нового кодека только новые изображения. Однако, если ваша цель - заменить JPEG, это далеко не идеальное решение.

Проблемы совместимости

Изменение формата изображений занимает длительный период времени, в течение которого только часть пользователей обновит свое программное обеспечение для поддержки нового формата. Преодоление этого переходного периода является основной проблемой при внедрении новых кодеков.

Во время перехода потребуются файлы как формата JPEG, так и нового формата X - первый для тех, кто еще не обновился, а второй для тех, кто уже использует новый формат и может извлечь выгоду из уменьшенной полосы пропускания. В глобальном масштабе это означает, что к серии изображений JPEG размером 1 ГБ необходимо будет добавить 500 МБ изображений  в формате X. Таким образом, несмотря на экономию полосы пропускания из-за предоставления некоторым пользователям изображений меньшего размера, более сильное сжатие парадоксальным образом приводит к увеличению объема хранилища: 1,5 ГБ вместо 1 ГБ!

И это при условии, что кодек X действительно может уменьшить размер файла на 50 процентов. Последнее поколение кодеков (AVIF, HEIC, WebP2 и JPEG XL) действительно может это сделать, но не предыдущие поколения (JPEG 2000, JPEG XR, WebP), которые могут обеспечить экономию всего 20-30 процентов. В последнем случае, если взять тот же 1 ГБ, это означает увеличение хранилища до 1.7–1.8 ГБ.

Универсальный  JPEG XL

С самого начала проект JPEG XL принимает во внимание эти проблемы перехода и пытается преодолеть их, настолько насколько это возможно.

JPEG XL - это подмножество JPEG. Что наиболее важно, разработчики JPEG XL сохранили все инструменты кодирования JPEG, несмотря на наличие новых скрытых инструментов кодирования, обеспечивающих превосходное сжатие. Следовательно, все данные изображения JPEG также могут быть представлены как данные изображения JPEG XL благодаря следующему:

- JPEG основан на дискретном косинусном преобразовании 8x8 (DCT) с фиксированными таблицами квантования. В отличие от этого, JPEG XL может похвастаться гораздо более мощным подходом, который включает переменные размеры DCT от 2x2 до 256x256 и адаптивное квантование, из которых простой JPEG DCT является просто частным случаем.

- JPEG XL использует новое внутреннее цветовое пространство (называемое XYB) для высокоточного, оптимизированного для восприятия кодирования изображений, но он также может обрабатывать простое преобразование цвета YCbCr, применяемое JPEG.

Следовательно, чтобы преобразовать файлы в  JPEG XL, вам не нужно декодировать файлы JPEG в пиксели. Вместо этого просто переводите JPEG (коэффициенты DCT) непосредственно в JPEG XL. Несмотря на то, что в этом случае используется только подмножество JPEG XL, которое соответствует JPEG, преобразованные изображения будут на 20 процентов меньше. Важно отметить, что файлы JPEG XL представляют собой точно такие же изображения, что и исходные файлы JPEG. Кроме того, преобразование является обратимым: вы можете восстановить файлы JPEG XL в файлы JPEG с минимальными вычислениями -  т.е вы можете сделать это на лету.

Устаревшая функция JPEG XL меняет правила игры для решения проблем перехода, описанных выше. Помимо экономии памяти и пропускной способности с самого начала, вы также можете без потерь сохранить устаревшие изображения, получая при этом большее сжатие. Другими словами, JPEG XL с самого начала предлагает только преимущества, тогда как другие подходы требуют жертвовать объёмом хранилища для уменьшения пропускной способности.

Методы перехода

JPEG XL является первым кандидатом на “замену JPEG” с реально выполнимыми этапами перехода. Первоначально сервер использует JPEG XL только для экономии места, что, однако, является нетривиальным стимулом. Поскольку все или большинство клиентов еще не поддерживают JPEG XL, это только формат хранения, который транскодируется обратно в JPEG на лету на сервере и доставляется как JPEG.

Затем сервер напрямую отправляет изображения в формате JPEG XL тем клиентам, которые поддерживают новый формат, экономя полосу пропускания для обеих сторон и ненавязчиво мотивируя клиентов на обновление.

При наличии достаточного количества клиентов, перешедших на новый формат,  сервер начинает кодировать новые изображения непосредственно в JPEG XL гибридным способом, то есть по-прежнему кодирует только JPEG-совместимое подмножество JPEG XL, но также использует преимущества некоторых функций JPEG XL, таких как адаптивный фильтр, сохраняющий края изображения и прогрессия значимости. Впоследствии вы можете перекодировать полученный JPEG XL в JPEG, который выглядит похожим, но JPEG XL будет иметь еще меньше артефактов сжатия и будет загружаться быстрее. Это еще один стимул для клиентов перейти на JPEG XL.

Наконец, когда (почти) все клиенты начнут использовать JPEG XL, вы переходите к полноценному кодированию с помощью JPEG XL, получая существенные улучшения в точности воспроизведения, пропускной способности, хранении и удобстве работы с пользователем.

Текущее состояние JPEG XL

Комитет JPEG - это рабочая группа Международной организации по стандартизации (ISO) и Международной электротехнической комиссии (IEC). Процесс стандартизации требует времени и включает несколько этапов голосования, в ходе которого проект спецификации изучается различными национальными органами по стандартизации, включая Американский национальный институт стандартов (ANSI) в США, Deutsches Institut für Normung eV (DIN) в Германии, Японский комитет по промышленным стандартам (JISC) в Японии и т. д.

Основными этапами процесса стандартизации являются новый проект (NP), рабочий проект (WD), проект комитета (CD), проект международного стандарта (DIS), окончательный DIS (FDIS) и международный стандарт (IS).

Стандарт JPEG XL состоит из четырех частей:

•  Часть 1 (основная часть) , которая описывает кодовый поток (фактический кодек изображения)

• Часть 2 , в которой описывается формат файла (контейнер, который обертывает кодовый поток и дополнительные метаданные или расширения)

• Часть 3 , в которой описывается процедура проверки совместимости декодеров JPEG XL.

• Часть 4 , являющаяся эталонной реализацией 

Если все пойдет по плану, международный стандарт для части 1 будет доступен в начале 2021 года; по остальным частям - в конце 2021 года.

На практике, как только процесс достигает стадии FDIS, спецификация «замораживается», и вы можете использовать JPEG XL по-настоящему. Тем не менее, для получения программной поддержки JPEG XL в приложениях и на платформах потребуется время и усилия. Избавление от старого JPEG будет нетривиальной задачей, о чем свидетельствуют несколько неудачных попыток в прошлом. Стоит надеяться, что на этот раз всё получится и создан достойный преемник JPEG - 30-летнего формата изображений, такого же старого, как Всемирная паутина, который старше Google и вдвое старше Facebook и Twitter. 

Источник: Сloudinary