JPEG XL превосходит все форматы по уровню сжатия и визуальному восприятию (DSSIM), источник
Оригинальный формат JPEG разработан в далёком 1992 году и уже устарел. Вопрос в том, кто придёт ему на смену. Идеальной заменой казался JPEG XL, в сравнительных тестах он показывает превосходство над AVIF, WebP и другими форматами. Можно было бы сказать, что будущее за JPEG XL, если бы не один нюанс: в 2022 году корпорация Google почему-то удалила его поддержку из браузера Chrome. И не хочет возвращать обратно.
Система кодирования изображений JPEG XL (ISO/IEC 18181) включает бесплатный (свободный от роялти) кодек, который сжимает изображения примерно на 60% лучше, чем оригинальный JPEG. JPEG XL основан на Google PIK и Cloudinary FLIF (Free Lossless Image Format). Формат заморожен (завершён) в 2021 году, спецификация прошла стандартизацию в ISO в 2022 году.
JPEG XL включает в себя следующие функции:
- Перекодирование старых изображений JPEG без потерь (точное побайтовое перекодирование с экономией около 20%) с возможностью восстановления оригинального файла для выдачи клиентам, которые не поддерживают JPEG XL.
- Режимы сжатия без потерь и с потерями.
- Анимация.
- Альфа-каналы, слои.
- Прогрессивное декодирование.
- HDR.
- Многопоточное и SIMD-оптимизированное декодирование.
Из стандартов ISO основной кодовый поток определён в стандарте 18181-1, формат файла — в 18181-2. Параметры декодера определены в 18181-3, а эталонное программное обеспечение (libjxl) — в 18181-4.
▍ Сравнительные тесты
Обширное сравнительное тестирование форматов в 2022 году провела компания Cloudinary в ответ на заявление Google о том, что AVIF является самым быстрым при декодировании.
JPEG XL действительно немного уступает по скорости декодирования, но нужно учитывать, что здесь декодирование начинается ещё во время скачивания, поэтому с учётом прогрессивного рендеринга изображения JPEG XL по факту загружаются быстрее AVIF:
Скорость декодирования:
В современных версиях браузеров на своей системе тест можно повторить здесь. Например, в последней версии 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 выигрывает в тестах:
Вот сравнение уровня сжатия при визуальном восприятии SSIMULACRA2 от 60 (medium quality) до 90 (visually lossless):
Сжатие без потерь тестового изображения с разными настройками кодеков:
В релевантном диапазоне качества для веба JPEG XL показывает уровень сжатия в среднем на 10−15% лучше, чем AVIF:
Альтернативные тесты качества сжатия на большом корпусе фотографий показывают серьёзное преимущество JPEG XL:
Наконец, сравнение поддерживаемых функций:
В целом, JPEG XL представляет существенные улучшения перед существующими форматами по следующим показателям:
- Перекодирование JPEG без потерь.
- Прогрессивное декодирование.
- Производительность сжатия без потерь.
- Производительность сжатия с потерями.
- Развёртывание кодера в продакшне.
- Применение на всех этапах рабочего процесса.
▍ Jpegli: улучшенный JPEG-кодек
Как уже говорилось, JPEG XL поддерживает пережатие JPEG без потерь. Таким образом, выгодно использовать его в качестве исходного или базового формата, из которого можно создать «стандартный JPEG» при необходимости. Этот подход обеспечивает лучшее визуальное качество и коэффициент сжатия, чем кодирование изначально в JPEG.
Именно так работает продвинутая библиотека кодирования Jpegli, полностью совместимая с существующими декодерами JPEG. Библиотека создана группой разработчиков JPEG XL с применением психовизуальной модели libjxl и по описанию превосходит по производительности WebP (WebP с потерями).
Из архитектуры и дизайна всей системы JPEG XL следует, что даже если не использовать этот формат для выдачи конечных изображений, а сохранить в качестве «исходного» базового формата на сервере, то можно получить массу преимуществ на всём конвейере кодирования и доставки изображений.
▍ Война Google против JPEG XL
Несмотря на явное преимущество стандарта кодирования JPEG XL, компания Google в октябре 2022 года приняла решение удалить его экспериментальную поддержку из браузера Chrome, включая программный код и флаг для включения/отключения поддержки JPEG XL.
Это решение получило широкий резонанс, но компания Google его не изменила, выбрав AVIF и WebP в качестве преемников для устаревших форматов JPEG и PNG.
В 2023 году в баг-трекере Chromium был поднят вопрос по поводу возвращения поддержки JPEG XL. Среди прочего, в качестве аргументов пользователи привели сравнительные результаты PNG, WebP и AVIF в сжатии без потерь. Там видно, что тот же AVIF уступает конкурентам по данному параметру. Хотя бы по этой причине нельзя принимать его в качестве универсального стандарта:
В то же время JPEG XL обеспечивает уровень сжатия без потерь примерно на 40% лучше, чем PNG.
На самом деле, никакой кодек не может заменить JPEG XL в одиночку. Некоторые выигрывают в отдельных тестах, но по степени универсализма с JPEG XL никто не сравнится.
Никакие аргументы не помогли. 16 мая 2024 года администрация без объяснения причин присвоила данному тикету статус Won't Fix (Obsolete), что может означать окончательное и бесповоротное закрытие вопроса. Формулировка Obsolete для обсуждения нового и перспективного формата выглядит спорной, хотя указывает на решительность Google в отстаивании своей позиции.
Интересно, что тикет был закрыт через 12 минут после публикации в нём комментария, в котором анонимный пользователь обвиняет в саботаже формата JPEG XL персонально сотрудника Google Джеймса Зерна (James Zern), соавтора конкурентного формата WebP.
Каковы же причины на самом деле? Вот официальная формулировка из первого отказа отменить удаление о JPEG XL в октябре 2022 года:
«Спасибо всем за ваши комментарии и отзывы о JPEG XL. Мы удалим код и флаг JPEG XL из Chromium по следующим причинам:
- Экспериментальные флаги и код не должны оставаться бесконечно.
- Вся экосистема недостаточно заинтересована в продолжении экспериментов с JPEG XL.
- Новый формат изображений не даёт достаточных преимуществ по сравнению с существующими форматами, чтобы включать его по умолчанию.
- Удаление флага и кода в M110 снижает нагрузку на поддержку и позволяет нам сосредоточиться на улучшении существующих форматов в Chrome».
Кроме того, упоминались дополнительные накладные расходы у партнёров и проблемы с производительностью (последний довод был вскоре оспорен).
Некоторые из указанных «причин» вызвали искреннее недоумение у сообщества, особенно странно выглядит фраза «не даёт достаточных преимуществ по сравнению с существующими форматами».
Но складывается впечатление, что компания Google просто решила сделать ставку на другой формат AVIF, хотят тот и уступает JPEG XL во многих тестах. Выше упомянуто, что JPEG XL основан в том числе на разработке Google PIK, так что Google можно считать одним из соавторов JPEG XL. Проблема в том, что созданием формата занималось подразделение Google Research, а разработкой браузера занимается другое подразделение, далёкое от исследовательского.
В качестве юмора в списке причин можно указать ещё и глупое название. В размерах одежды аббревиатура XL (X-tra Large) ассоциируется с чем-то большим. Как будто формат предназначен для кодирования гигантских фотографий. Конечно, это не так. На самом деле JPEG XL довольно универсален и показывает превосходство в кодировании изображений разных типов и размеров. Может, название просто не понравилось кому-то из топ-менеджеров Google?
▍ Борьба не закончена
Хотя Google является практически монополистом на рынке браузеров, но её монополия не абсолютная. Поэтому она не может единолично принимать решение по данному вопросу. Практически все остальные игроки в IT-индустрии поддержали JPEG XL и продолжают его поддерживать. Safari добавил его с версии Safari 17 (сентябрь 2023-го) под всеми операционными системами, Firefox работает над этим (флаг
image.jxl.enabled в about:config). Многие инструменты Apple генерируют файлы JXL по умолчанию. Компания Adobe добавила JPEG XL в популярный фоторедактор Photoshop. Более того, она рекомендовала JPEG XL вместе с AVIF как оптимальные кодеки HDR Output (сжатие фотографий с большим динамическим диапазоном цветовых значений) в режиме Camera Raw (необработанные данные с сенсора камеры).
Samsung добавила поддержку JPEG XL в новые телефоны, а Microsoft — в операционную систему Windows.
В целом, индустрия отлично приняла новый формат. В 2024 году JPEG XL является самой востребованной функцией среди веб-разработчиков.
С другой стороны, без поддержки Chromium новому кодеку действительно трудно (или невозможно) будет стать общепризнанным форматом. Qualcomm тоже недавно выпустила чипы Snapdragon X с поддержкой аппаратного кодирования AV1 (AVIF), но не JPEG XL. Так что будем следить за развитием ситуации.
Для поддержки JXL в браузере можно установить расширение JPEG XL Viewer (для Chrome и Firefox).
А в более широком смысле эта история ещё раз демонстрирует деструктивную сущность любой монополии. Как точно прокомментировал представитель Фонда свободных рубежей, Google пытается контролировать каждый аспект интернета, чтобы неизменно извлекать выгоду для собственных бизнес-интересов.
Telegram-канал со скидками, розыгрышами призов и новостями IT ?
Комментарии (40)
akabrr
19.08.2024 09:07Первый шаг к закату хрома?
ahabreader
19.08.2024 09:07+3Закату?
Mozilla тоже против. Точнее, они заявили "we are neutral on JPEG-XL", но поддержку не включили даже после Safari. "We might find it necessary to support the format if usage becomes more widespread" звучит как "мы будет повторять за гуглом".
upd1: если ничего не изменилось, флаг
image.jxl.enabledесть во всех версиях браузера, но действует только в Nightly.upd2: гугл с "having fewer formats is better for the Web" не согласен и собирается использовать AV2 для картинок.
Burtanshy
19.08.2024 09:07FF 129.0.1 флаг стоит в положение false xD
ahabreader
19.08.2024 09:07Я про "действует" в буквальном смысле - что его включение добавляет поддержку только в ночных сборках, а в релизных это заглушка (если ничего не изменилось).
dartraiden
19.08.2024 09:07Потому что релизные версии собраны без libjxl
Нет ножек - нет мультиковНет библиотеки - нет поддержки формата
ky0
19.08.2024 09:07+3Пол-интернета ещё нормально показывать/скачивать WebP (особенно анимированные) не научилось - а вы предлагаете ещё виток сделать :)
Имхо, разница с WebP гомеопатическая и важнее пушить отказ от jpeg/png/gif, чем выигрывать два процента на XL.
ahabreader
19.08.2024 09:07+19От VP8 в видео все отказались, а в картинках кодек уровня ~2000 года надо начать лучше поддерживать? Нет, здесь его тоже надо забыть как первую неудачную попытку гугла.
разница с WebP гомеопатическая
Только не у нового JPEG (JXL), а у старого. По статье WebP уступает новому кодеку оригинального JPEG.
График из статьи с пояснением
(v2) Именно поэтому стоит перейти на JXL - чтобы не менять один компромиссный зоопарк форматов на другой. У WebP нет lossy 4:4:4-режима, у AVIF lossless сделан для галочки (хуже, чем в WebP), впереди AV2 в контейнере от AVIF. Пережатие JPEG без потерь никто из них не предложит.
чем выигрывать два процента на XL.
Даже в lossless не 2%, а 15%.
ky0
19.08.2024 09:07Видео и анимированные картинки - это разные вещи, используемые в разных случаях.
ahabreader
19.08.2024 09:07VP8 == lossy WebP.
VP8 используют в lossy WebP как AV1 используют в AVIF (или я не понял комментарий).
----
Добавлю к списку отсутствие прогрессивного режима в WebP.
Self_Perfection
19.08.2024 09:07Lossless перекодирование jpeg изображений в JXL с уменьшением размера - весьма полезная фича, у WebP такого нет
gudvinr
19.08.2024 09:07+1Qualcomm тоже недавно выпустила чипы Snapdragon X с поддержкой аппаратного кодирования AV1 (AVIF), но не JPEG XL.
А аппаратное кодирование webp, png, jpeg и gif давно в процессорах есть?
kenomimi
19.08.2024 09:07+2jpeg есть везде вообще, даже на микроконтроллерах пожирнее. Остальное - нет.
gudvinr
19.08.2024 09:07+3Во-первых, "везде" есть только декодирование. А во-вторых, в Qualcomm Hexagon (который во всех Snapdragon используется) его нет.
В NVDEC и кажется в процессорах AMLOGIC тоже нет.Мысль была в том, что отсутствие аппаратного кодирования изображений абсолютно ни о чём не говорит, потому что оно не нужно практически никому.
vanxant
19.08.2024 09:07+1Внутре webp по своей сути то же самое дискретное косинус-преобразование (DCT), что и внутре классического jpeg. Но только если у jpeg блоки всегда имеют размер 8х8, то у webp есть 4х4 и 16x16. Другими словами, поддержка сжатия jpeg скорее всего ускоряет и webp тоже (причём libwebp от гугла хорошо затюнена под соответствующие инструкции).
В принципе, webp неплохой формат именно для доставки конечного контента. Но его нужно уметь готовить. По умолчанию гугл ради циферок сжатия выставляет шакалистость 8/10 и совсем лютый ужас с цветом. Поэтому приходится вручную пробрасывать кодировщику нормальное качество и включать режим sharp_yuv. Из коробки не каждая либа это умеет, поэтому бывает что приходится тащить с собой пакет webp и вызывать cwebp через командную строку.
kenomimi
19.08.2024 09:07+15Но складывается впечатление, что компания Google просто решила сделать ставку на другой формат AVIF, хотят тот и уступает JPEG XL во многих тестах.
Какой-нибудь топ-смузихлеб пробивал внедрение "своего" кодека, чтобы дать работу своему отделу, а вы тут принесли опенсорсную поделку, которая не обеспечит ему годовых бонусов на новую яхту и куртизанок. Понятно, что была дана команда отказать всем и не дергаться.
Плюс поддержа всех новомодных форматов (взять тот же webp) реализована через одно место на большинстве сайтов. Просто попробуйте загрузить webp картинку где-нибудь... Добавлять еще больше стандартов - добавлять головняк поддержке и пользователю.
ganzmavag
19.08.2024 09:07+2Как уже говорилось, JPEG XL поддерживает пережатие JPEG без потерь. Таким образом, выгодно использовать его в качестве исходного или базового формата, из которого можно создать «стандартный JPEG» при необходимости. Этот подход обеспечивает лучшее визуальное качество и коэффициент сжатия, чем кодирование изначально в JPEG. Именно так работает продвинутая библиотека кодирования Jpegli, полностью совместимая с существующими декодерами JPEG.
Несколько раз перечитал и не понял, в чем связь библиотеки для кодирования базового JPEG и формата JPEG XL.
По поводу самого формата: честно говоря, мне и преимущества WEBP не особенно очевидны. Когда делаешь качество действительно как у оригинала, то размер толком не отличается. А на сайтах, где WEBP используют в проде, очень бросается в глаза мыльность картинок.
Revertis
19.08.2024 09:07+1Вся экосистема недостаточно заинтересована в продолжении экспериментов с JPEG XL.
Это они про какую экосистему? Гугловую?
blind_oracle
19.08.2024 09:07+1Именно так работает продвинутая библиотека кодирования Jpegli, полностью совместимая с существующими декодерами JPEG. Библиотека создана группой разработчиков JPEG XL с применением психовизуальной модели libjxl и по описанию превосходит по производительности WebP (WebP с потерями).
Ну, так, к слову -
jpegliсделал тоже гугл (по вашей же ссылке). Это же не пчёлы против мёда?Что, в общем, неплохой компромисс между включением Jpeg XL, который по факту и так никто не использовал нигде. Другое дело, что сжимать с помощью
jpegliвряд-ли всех заставишь и будет опять каша.ahabreader
19.08.2024 09:07+1Это же не пчёлы против мёда?
Это пасека. Один улей делает jpegli и участвует в разработке JXL, а другой убирает поддержку JXL из хрома.
blind_oracle
19.08.2024 09:07Возможно.
Судя по названию, оно было выковано в швейцарском офисе гугла, как и прочие
-li(brotli,zopfli...)А Хром, наверное, пилят в Америке в основном. Битва миров :)
ifap
19.08.2024 09:07+1Google почему-то удалила его поддержку из браузера Chrome
Потому, что может. Более точное объяснение - лишь частный случай этого множества.
Fahrain
19.08.2024 09:07+4Вы сначала хотя бы gif закопайте, прежде чем за jpeg браться)
Напомню, что до JpegXL был "тоже лучший" Jpeg2000 - который за 24 года так и не смог с jpeg хоть как-то заметно конкурировать. Так же как и WebP сегодня - он вроде как есть, но по факту им пользуются исключительно на сайтах и исключительно чтобы пройти проверку на скорость сайта от Гугла, а не потому, что он картинку лучше/меньше делает.
По факту, единственное место, где я хоть когда-то встречал JpegXL - это HDR фотографии. Причем выкладывают их в таком формате полторы калеки - в отличие от jpeg/png, которые буквально на каждом шагу. Да и смотреть их не на чем - hdr-экраны так толком и не поддерживаются ни виндой, ни играми, ни другим софтом. А там где такая поддержка есть - лучше её отключить, чем использовать, картинка лучше становится. В итоге получается, что и для этих целей нам JpegXL тоже сегодня не нужен...
funny_falcon
19.08.2024 09:07+1ЕМНИП, у jpeg2000 были серьезные проблемы с лицензией. Т.е. он (был?) далеко не «бесплатный» и не «свободный».
Если я правильно понимаю статью, jpegxl лишён этого фатального недостатка. Но могу ошибаться.
Fahrain
19.08.2024 09:07Наличие лицензии вообще не помешало взлёту divx, например. Мне кажется, что проблема всё-таки в другом: все эти новые кодеки просто не дают таких преимуществ, ради которых на них стоило бы перейти, ломая сложившиеся за десятилетия привычки. Да, даже 20% улучшения просто не достаточно - нужно именно на порядки. Как переход с mpeg2->divx, divx->h264, h264->h265/avc1.
И даже это не гарантия: пример формата gif это наглядно показывает. Нужны еще и удобные инструменты. Которые под эти новые форматы просто отсутствуют. Или сделаны так, что ими вообще неудобно пользоваться. Именно поэтому gif всё ещё жив, а webp годами где-то на грани "еще чуть-чуть и умер".
Loco2k
19.08.2024 09:07Потому что ставка на av1, который уже имеет аппаратное декодирование. Гугл часть ассоциации, которая пилит свои кодеки, супротив mpeg и jpeg, т.к. там с ними могут быть коммерческие и юридические вопросы.
IgnisNoir
19.08.2024 09:07Я выдвину свое предположение, так что поправьте меня если я не прав, так как это просто предположение.
Так может потому и не делают потому что это опасность для аппаратного кодирования на процессорах? Ведь место на кристале не бесконечное, а если каждый новый формат который лучше впихивать на кристал то это будет очень плохо. А тут есть AV1 который и так стандарт и на кристалах появляется и нужен еще и для видео которое используется уже. Так что это просто тупо выгоднее
blind_oracle
19.08.2024 09:07Картинки - не видео, особо смысла декодировать их хардварно нет как мне кажется. Не тот поток данных.
Разве что да, для мобильных устройств, чтобы батарейку сэкономить.
IgnisNoir
19.08.2024 09:07Ну сейчас мобильные это основной инструмент просмотра интернета. так что да. Да и браузер сейчас в котором картинок слишком много также стал основным и главным окном в ОС
mikegordan
19.08.2024 09:07Очень странная таблица с сравнением. На ней у webp отмечен что не умеет в "прогрессив jpeg" это когда загружаются размеры сначала чтобы не скакала разметка, потом пиксельный вид, а потом уже полноценная картинка.
или статья супер старая или ошибка или тут надо статьи фейкчекап делать.
А так я согласен будущие за av1, надеюсь компании усилят влияние на апдейт железо с физическими декодерами и енкодерами av1.
Tomasina
19.08.2024 09:07Не нашел сравнение WebP и JPEG XL.
Ибо начинать статью с "... который сжимает изображения примерно на 60% лучше, чем оригинальный JPEG" - моветон ради больших циферок. Может там разница 0,14% - чего тогда дергаться?
Fasterpast
19.08.2024 09:07В свое время, я очень ждал avif, так как что у jpeg, что у webp не лады с красным. А конкретно - jpeg артифачит, а wepb размывает, причем практически при любом качестве с любыми профилям и настройками, в итоге фотки с красной графикой у нас на сайте (такой уж дизайн) долгое время были исключительно в жпеге с 98% качеством. Avif эту проблему решил ) не нравится только, что уж очень медленно он работает на сжатие. Касательно сабжа, надо бы тоже попробовать на наших фотках, ради интереса...
Conung_ViC
Ссылка на расширение - ведет на 404. Реп удалили или ссылка изначально была битая?
alizar Автор
Действительно, реп удалили, странно... https://web.archive.org/web/20240807174630/https://github.com/zamfofex/jxl-crx
Conung_ViC
причем удалили не только реп, но и профиль целиком...