JPEG XL лучше всех, но Google против

Оригинальный формат JPEG разработан в далёком 1992 году и уже устарел. Вопрос в том, кто придёт ему на смену. Идеальной заменой казался JPEG XL ^[3], в сравнительных тестах он показывает ^[4] превосходство над AVIF, WebP и другими форматами. Можно было бы сказать, что будущее за JPEG XL, если бы не один нюанс: в 2022 году корпорация Google почему-то удалила его поддержку из браузера Chrome. И не хочет возвращать обратно.

Система кодирования изображений JPEG XL ^[3] (ISO/IEC 18181) включает бесплатный (свободный от роялти) кодек, который сжимает изображения примерно на 60% лучше, чем оригинальный JPEG.

JPEG XL основан на Google PIK ^[5] и Cloudinary FLIF (Free Lossless Image Format). Формат заморожен (завершён) в 2021 году, спецификация прошла стандартизацию в ISO ^[6] в 2022 году.

JPEG XL включает в себя следующие функции:

• Перекодирование старых изображений JPEG без потерь (точное побайтовое перекодирование с экономией около 20%) с возможностью восстановления оригинального файла для выдачи клиентам, которые не поддерживают JPEG XL.
• Режимы сжатия без потерь и с потерями.
• Анимация.
• Альфа-каналы, слои.
• Прогрессивное декодирование.
• HDR.
• Многопоточное и SIMD-оптимизированное декодирование.

Из стандартов ISO основной кодовый поток ^[7] определён в стандарте 18181-1, формат файла ^[8] — в 18181-2. Параметры декодера ^[9] определены в 18181-3, а эталонное программное обеспечение ^[10] (libjxl) — в 18181-4.

▍ Сравнительные тесты

Обширное сравнительное тестирование форматов ^[11] в 2022 году провела компания Cloudinary в ответ на заявление ^[12] Google о том, что AVIF является самым быстрым при декодировании.

JPEG XL действительно немного уступает по скорости декодирования, но нужно учитывать, что здесь декодирование начинается ещё во время скачивания, поэтому с учётом прогрессивного рендеринга изображения JPEG XL по факту загружаются быстрее AVIF:

Скорость декодирования:

В современных версиях браузеров на своей системе тест можно повторить здесь ^[13]. Например, в последней версии Chrome на тестовой машине результаты следующие:

JPEG: 351.21 MP/s | Fetch: 8.40ms | 100 decodes: 93.30ms
JPEG XL: 341.69 MP/s | Fetch: 240.00ms | 100 decodes: 95.90ms
8-bit AVIF: 82.25 MP/s | Fetch: 5.70ms | 100 decodes: 398.40ms
10-bit AVIF: 67.26 MP/s | Fetch: 5.80ms | 100 decodes: 487.20ms
12-bit AVIF: 60.45 MP/s | Fetch: 237.30ms | 100 decodes: 542.10ms
WebP: 140.94 MP/s | Fetch: 177.90ms | 100 decodes: 232.50ms

Но как мы уже говорили, с точки зрения пользователя важнее не чистая скорость декодирования, а скорость рендеринга:

Скорость кодирования зависит от соответствующих настроек скорости:

И от настроек качества (кодек libjxl):

На низком качестве AVIF быстрее, но на практике такой режим кодирования редко используется. Для иллюстрации, вот как выглядит фотография, обработанная кодеком с настройками низкого качества:

А с настройками высокого качества JPEG XL выигрывает в тестах ^[14]:

Вот ^[14] сравнение уровня сжатия при визуальном восприятии SSIMULACRA2 от 60 (medium quality) до 90 (visually lossless):

Сжатие без потерь тестового изображения ^[15] с разными настройками кодеков:

В релевантном диапазоне качества для веба JPEG XL показывает уровень сжатия в среднем на 10−15% лучше ^[16], чем AVIF:

Альтернативные тесты качества сжатия на большом корпусе фотографий показывают серьёзное преимущество JPEG XL ^[4]:

Наконец, сравнение поддерживаемых функций:

В целом, JPEG XL представляет существенные улучшения перед существующими форматами по следующим показателям:

• Перекодирование JPEG без потерь.
• Прогрессивное декодирование.
• Производительность сжатия без потерь.
• Производительность сжатия с потерями.
• Развёртывание кодера в продакшне.
• Применение на всех этапах рабочего процесса.

▍ Jpegli: улучшенный JPEG-кодек

Как уже говорилось, JPEG XL поддерживает пережатие JPEG без потерь. Таким образом, выгодно использовать его в качестве исходного или базового формата, из которого можно создать «стандартный JPEG» при необходимости. Этот подход обеспечивает лучшее визуальное качество и коэффициент сжатия, чем кодирование изначально в JPEG.

Именно так работает продвинутая библиотека кодирования Jpegli ^[17], полностью совместимая с существующими декодерами JPEG. Библиотека создана группой разработчиков JPEG XL с применением психовизуальной модели libjxl и по описанию ^[18] превосходит по производительности WebP (WebP с потерями).

Из архитектуры и дизайна всей системы JPEG XL следует, что даже если не использовать этот формат для выдачи конечных изображений, а сохранить в качестве «исходного» базового формата на сервере, то можно получить массу преимуществ на всём конвейере кодирования и доставки изображений.

▍ Война Google против JPEG XL

Несмотря на явное преимущество стандарта кодирования JPEG XL, компания Google в октябре 2022 года приняла решение удалить его экспериментальную поддержку из браузера Chrome ^[19], включая программный код и флаг для включения/отключения поддержки JPEG XL.

Это решение получило широкий резонанс, но компания Google его не изменила, выбрав AVIF и WebP в качестве преемников для устаревших форматов JPEG и PNG.

В 2023 году в баг-трекере Chromium был поднят вопрос ^[20] по поводу возвращения поддержки JPEG XL. Среди прочего, в качестве аргументов пользователи привели сравнительные результаты PNG, WebP и AVIF ^[21] в сжатии без потерь. Там видно, что тот же AVIF уступает конкурентам по данному параметру. Хотя бы по этой причине нельзя принимать его в качестве универсального стандарта:

В то же время JPEG XL обеспечивает уровень сжатия без потерь примерно на 40% лучше, чем PNG.

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

Никакие аргументы не помогли. 16 мая 2024 года администрация без объяснения причин присвоила ^[22] данному тикету статус Won't Fix (Obsolete), что может означать окончательное и бесповоротное закрытие вопроса. Формулировка Obsolete для обсуждения нового и перспективного формата выглядит спорной, хотя указывает на решительность Google в отстаивании своей позиции.

Интересно, что тикет был закрыт через 12 минут после публикации в нём комментария ^[22], в котором анонимный пользователь обвиняет в саботаже формата JPEG XL персонально сотрудника Google Джеймса Зерна (James Zern), соавтора конкурентного формата WebP.

Каковы же причины на самом деле? Вот официальная формулировка ^[19] из первого отказа отменить удаление о JPEG XL в октябре 2022 года:

«Спасибо всем за ваши комментарии и отзывы о JPEG XL. Мы удалим код и флаг JPEG XL из Chromium по следующим причинам:

• Экспериментальные флаги и код не должны оставаться бесконечно.
• Вся экосистема недостаточно заинтересована в продолжении экспериментов с JPEG XL.
• Новый формат изображений не даёт достаточных преимуществ по сравнению с существующими форматами, чтобы включать его по умолчанию.
• Удаление флага и кода в M110 снижает нагрузку на поддержку и позволяет нам сосредоточиться на улучшении существующих форматов в Chrome».

Кроме того, упоминались дополнительные накладные расходы ^[23] у партнёров и проблемы с производительностью ^[24] (последний довод был вскоре оспорен ^[11]).

Некоторые из указанных «причин» вызвали искреннее недоумение у сообщества, особенно странно выглядит фраза «не даёт достаточных преимуществ по сравнению с существующими форматами».

Но складывается впечатление, что компания Google просто решила сделать ставку на другой формат AVIF, хотят тот и уступает JPEG XL во многих тестах. Выше упомянуто, что JPEG XL основан в том числе на разработке Google PIK ^[5], так что Google можно считать одним из соавторов JPEG XL. Проблема в том, что созданием формата занималось подразделение Google Research, а разработкой браузера занимается другое подразделение, далёкое от исследовательского.

В качестве юмора в списке причин можно указать ещё и глупое название ^[25]. В размерах одежды аббревиатура XL (X-tra Large) ассоциируется с чем-то большим. Как будто формат предназначен для кодирования гигантских фотографий. Конечно, это не так. На самом деле JPEG XL довольно универсален и показывает превосходство в кодировании изображений разных типов и размеров. Может, название просто не понравилось кому-то из топ-менеджеров Google?

▍ Борьба не закончена

Хотя Google является практически монополистом на рынке браузеров, но её монополия не абсолютная. Поэтому она не может единолично принимать решение по данному вопросу. Практически все остальные игроки в IT-индустрии поддержали JPEG XL и продолжают его поддерживать. Safari добавил его ^[26] с версии Safari 17 (сентябрь 2023-го) под всеми операционными системами, Firefox работает над этим ^[27] (флаг image.jxl.enabled в about:config).

Многие инструменты Apple генерируют файлы JXL по умолчанию. Компания Adobe добавила JPEG XL в популярный фоторедактор Photoshop. Более того, она рекомендовала JPEG XL ^[28] вместе с AVIF как оптимальные кодеки HDR Output (сжатие фотографий с большим динамическим диапазоном цветовых значений) в режиме Camera Raw (необработанные данные с сенсора камеры).

Samsung добавила ^[29] поддержку JPEG XL в новые телефоны, а Microsoft — в операционную систему Windows.

В целом, индустрия отлично приняла новый формат. В 2024 году JPEG XL является самой востребованной ^[30] функцией среди веб-разработчиков.

С другой стороны, без поддержки Chromium новому кодеку действительно трудно (или невозможно) будет стать общепризнанным форматом. Qualcomm тоже недавно выпустила чипы Snapdragon X ^[31] с поддержкой аппаратного кодирования AV1 (AVIF), но не JPEG XL. Так что будем следить за развитием ситуации.

Для поддержки JXL в браузере можно установить расширение JPEG XL Viewer (для Chrome ^[32] и Firefox ^[33]).

А в более широком смысле эта история ещё раз демонстрирует деструктивную сущность любой монополии. Как точно прокомментировал ^[34] представитель Фонда свободных рубежей, Google пытается контролировать каждый аспект интернета, чтобы неизменно извлекать выгоду для собственных бизнес-интересов.