JPEG XL против AVIF для веб-контента

Выводы

Полный анализ с примерами и бенчмарками дан ниже, но для тех, кто спешит:

Для сжатых фотографий в вебе AVIF почти всегда даёт меньше файлы, чем JPEG XL. При стандартных настройках усилия лучший вариант JPEG XL обычно на 15–25% больше, чем эквивалентный AVIF. При максимальных настройках разрыв сужается до 6–20%. Встречаются выбросы, где JPEG XL близок или даже побеждает AVIF, поэтому если нужен абсолютно лучший результат для конкретного изображения — стоит попробовать оба. См. пример с F1 как типичный случай и ласку как исключение.

Кодер JPEG XL имеет большое значение. jixel, более новый кодер JPEG XL, обычно даёт меньше файлы, чем libjxl, за исключением изображений с детальной прозрачностью. Изображение с людьми — один из примеров.

Для скриншотов и иллюстраций AVIF намного лучше JPEG XL. Эквивалентный JPEG XL на 30–90% больше при стандартных настройках и на 20–70% при максимальных. Сжатый AVIF хорошо справляется с этим — не нужны без потерь форматы, если только не требуются результаты без потерь. См. примеры со скриншотом и иллюстрацией.

Для изображений с прозрачностью AVIF намного лучше JPEG XL. Версия libjxl на 31–44% больше при стандартных настройках и на 61–70% при максимальных. jixel всегда кодирует прозрачность без потерь, что делает его файлы в 2–3 раза больше, чем у AVIF. См. данные.

AVIF обычно кодируется быстрее и использует меньше памяти с учётом размера файла. jixel быстрее AVIF и использует меньше памяти, но его файлы обычно значительно больше, поэтому AVIF выигрывает в целом. См. пример с F1.

AVIF быстрее декодируется. JPEG XL обычно требует в 2–3 раза больше времени на декодирование при средней качества, но разрыв сужается при очень высоких качествах, где Chrome иногда может декодировать JPEG XL быстрее. Изображение с людьми — один из примеров.

Повышенные настройки усилия стоят того для AVIF и jixel, но не для libjxl. Повышенные усилия libjxl намного медленнее, используют намного больше памяти и едва улучшают результат. Иногда они дают файлы больше, чем при стандартном усилии. Скриншот — пример этого.

Режим 4:2:0 AVIF (половина разрешения цвета) не должен быть вашим умолчанием. Редко сокращает размер файла и затрудняет достижение более высоких качеств. Хотя кодируется и декодируется быстрее. Придерживайтесь 4:4:4, если нет времени проверить оба режима. F1 — один пример, скриншот — исключение.

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

Progressive JPEG XL по сути бесплатен при высоком усилии. jixel недавно добавил поддержку ранних progressive превью, и при его самой медленной настройке они практически ничего не стоят, но при стандартной настройке файлы на 12% больше. Firefox и Chrome поддерживают progressive JPEG XL. Safari все ещё рендерит финальное изображение, но не показывает progressive превью. Однако, является ли такой прогрессивный рендеринг хорошим пользовательским опытом? См. примеры и данные.

AVIF поддерживает progressive рендеринг! Пока только для Chrome, но для Firefox идёт работа. Это сложнее, чем progressive JPEG XL, но даёт больше контроля над тем, как выглядит превью, файлы обычно меньше и декодируются намного быстрее. Посмотрите сами.

Для HDR в JPEG XL отсутствуют gain maps, что является значительным ограничением по сравнению с AVIF. Формат JPEG XL поддерживает gain maps, но они не поддерживаются декодерами браузеров, и история кодирования беспорядочная/экспериментальная. При сравнении содержимого HDR без gain maps две использованные метрики качества сильно не согласны, но согласны, что JPEG XL даёт меньше файлы, чем AVIF. См. примеры.

JPEG XL может сделать существующие JPEG на 9–20% меньше без дополнительных потерь. Это также быстрее или такая же скорость декодирования, кроме как для маленьких изображений. См. данные.

Для без потерь JPEG XL — явный победитель. Без потерь WebP на 9–17% больше для фотографий, и без потерь AVIF на 30–120% больше. Но без потерь изображения почти никогда не нужны в вебе. Если вы используете их в вебе (как я на этой странице), остерегайтесь повышенных усилий jixel — часто они дают файлы, которые слишком медленно декодируются. См. данные.

Анимированные форматы изображений остаются плохой идеей. Пожалуйста, не используйте их. Узнайте больше, если вам нужно.

Для веб-контента я бы сейчас использовал AVIF 4:4:4 с максимальным усилием, которым я готов пожертвовать. Если бы я почувствовал, что AVIF создаёт необычно большой файл, я бы посмотрел на JPEG XL через jixel и посмотрел, может ли он сделать лучше.

И AVIF, и JPEG XL (через jixel) недавно претерпели массивные улучшения, поэтому возможно, что эта рекомендация может измениться в будущем. Вокруг этого было много дезинформации, и ваш AI с удовольствием передаст вам эту дезинформацию. Вместо этого тестируйте с вашими изображениями.

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

Методология

Я 'создал' сценарий бенчмарка, который кодирует изображения различными кодеками с различными настройками и записывает различные детали.

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

• avifenc 1.4.2
• libjxl 0.12.0 (использующий его кодер cjxl)
• jixel 0.4.2 (git f487299), второй кодер JPEG XL
• cwebp 1.6.0 (без потерь WebP используется далее в статье)

Я выбрал подборку изображений и кодировал большинство из них на ширину 1598 пикселей — это 2x максимальная ширина, на которой изображения появляются в этом блоге. Это означает, что они выглядят чёткими на дисплеях с высокой плотностью, которые есть у большинства пользователей. В результате, если вы просматриваете это на маленьком или низкой плотностью экране, вы не получаете полный опыт.

Я запустил эти бенчмарки на моем 2024 MacBook Pro (M4 Pro).

Сжато - изображение F1

Когда я первый раз писал об AVIF, я использовал болид F1 как первое изображение, поэтому решил повторить!

Кодировал изображение при различных качествах кодеков и выбирал версии, которые были ближе всего к конкретным оценкам SSIMULACRA2 — метрика перцептивного качества изображения от авторов JPEG XL. 50 считается средним качеством, 70 — высоким, 80 — очень высоким, и 90 — визуально без потерь. Хотя я не уверен, учитывают ли эти оценки дисплеи с высокой плотностью.

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

Для архивирования я бы склонился к качествам, близким к без потерь, но если я просто выкладываю иллюстрацию в свой блог, производительность важнее для меня. Лично я доволен результатом 70 выше. Если увеличить масштаб, вы можете увидеть потерю качества, но если бы я действительно беспокоился о случае с увеличением масштаба, я бы использовал что-то вроде VisualViewport API, чтобы загрузить изображение с более высоким разрешением в этом случае, вместо того чтобы сделать загрузку больше для всех.

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

Также я чувствую, что при среднем качестве (50) AVIF и libjxl выглядят лучше, чем версия jixel. Версия jixel имеет много видимого шума вокруг логотипа BWT, и текст Microsoft на переднем крыле намного менее разборчив. Это заставляет меня задаться вопросом о метрике.

Так или иначе, вот моё толкование результатов:

• Размер файла: AVIF побеждает. При стандартных усилиях лучшее изображение JPEG XL на 14–17% больше, чем изображение AVIF той же качества. jixel — лучший кодер JPEG XL при среднем/высоком качестве, а libjxl немного лучше при очень высоком качестве. При максимальных усилиях лучшее изображение JPEG XL (jixel 'extraslow') на 6–15% больше, чем AVIF (s0).
• jixel при его самой медленной настройке немного побеждает стандартное усилие AVIF, с файлами на 1–10% меньше. Самый большой выигрыш при очень высоком качестве.
• Время кодирования: AVIF побеждает. При стандартных усилиях jixel на 12–36% быстрее, чем AVIF, но его файлы на 14–18% больше. Чтобы соответствовать размеру файла стандартного AVIF, jixel нуждается в его настройке 'extraslow', которая требует в 18–27 раз больше времени, чем AVIF. Стандартное libjxl требует в 1.5–2 раза больше времени, чем стандартное AVIF, и всё равно создаёт файлы больше.
• Память кодирования: AVIF побеждает. При стандартных усилиях jixel использует около половины памяти AVIF, но опять же, его файлы на 14–18% больше. Чтобы соответствовать размеру файла стандартного AVIF, jixel 'extraslow' использует ~10x памяти. Стандартное libjxl использует в 2–3 раза больше памяти AVIF, а его повышенные усилия используют ~7x.
• Время декодирования: AVIF побеждает. JPEG XL требует в 2–3 раза больше времени на декодирование при среднем качестве, сужаясь к ~1.5–1.8x при очень высоком качестве. Декодер JPEG XL Safari — самый медленный.
• Повышенное усилие стоит того для AVIF. AVIF s5 даёт вам ~10% меньше файлы в 3x раза больше времени кодирования.
• Повышенное усилие стоит того и для jixel, вплоть до 'slow'. 'slow' даёт вам 9–13% меньше файлы, чем его стандартное 'fast', для 3.7x раза больше времени кодирования. 'extraslow' сохраняет ещё 3–8%, но требует ~8x дольше, чем 'slow' и использует ~9x памяти. Даже так, AVIF побеждает при том же времени кодирования: AVIF s5 требует примерно столько же времени, как jixel 'slow', и его файлы ~13% меньше.
• Повышенное усилие не стоит того для libjxl. Максимальное усилие libjxl едва ли лучше, чем его стандартное, но требует ~18x дольше.
• Режим AVIF 4:2:0 не помогает много. Это немного быстрее кодировать/декодировать и использует меньше памяти, но файлы не намного меньше, и ему сложнее достичь более высоких качеств.

Вот полные данные, чтобы вы могли составить своё мнение: