Профиль: Аноним (вход | регистрация) неRU opennet.me  
OpenNET

[ новости /+++ | форум | теги |    ]

Разработчик Firefox провёл сравнительное тестирование форматов JPEG XL и AVIF

16.10.2026 23:52 (MSK)

Джейк Арчибальд (Jake Archibald), участвующий в разработке Firefox, провёл исследование, в котором сравнил форматы JPEG XL и AVIF, используя стандартный кодек libavif, стандартный кодек libjxl и новый кодек jixel, написанный на Rust и задействованный в Firefox и Chrome. Форматы тестировались в одинаковых условиях, которые включали кодирование с потерями, а для анализа результатов использовались показатели SSIMULACRA2, определяющие степень отличия от исходного изображения без потерь. В большинстве тестов формат AVIF показал лучшие результаты и при аналогичном уровне качества позволял создавать файлы меньшего размера, которые требовали меньше процессорного времени для сжатия и распаковки.

При сжатии фотографий с потерями для веб-ресурсов с настройками эффективности сжатия (баланс между временем кодирования и уровнем сжатия) по умолчанию файлы JPEG XL получались обычно на 15-25% больше аналогичных файлов AVIF. При максимальных уровнях сжатия разрыв сокращался до 6-20%. В отдельных тестах JPEG XL приближался к AVIF или даже превосходил его. При этом на результат JPEG XL виляет выбор кодировщика: новый кодировщик jixel, как правило, создаёт файлы меньшего размера, чем 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 происходит быстрее. Для JPEG XL декодирование обычно требует в 2-3 раза больше времени при среднем качестве, однако при очень высоком качестве разрыв сокращается - в таких случаях браузер Chrome иногда декодирует JPEG XL даже быстрее.

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

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

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

В JPEG XL при выборе высоких уровней сжатия использование прогрессивного вывода практически не требует дополнительных затрат. В jixel недавно появилась поддержка предварительного прогрессивного отображения: при максимальной интенсивности сжатия это почти не влияет на результат, однако при настройках по умолчанию размер файла увеличивается на 12%. Браузеры Firefox и Chrome поддерживают прогрессивный JPEG XL. Safari отображает финальное изображение, но не показывает промежуточные прогрессивные стадии.

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

Что касается HDR, то в JPEG XL отсутствуют "карты усиления" (gain maps), что является существенным недостатком по сравнению с AVIF. Формат JPEG XL поддерживает такие карты, но браузерные декодеры их пока не распознают, а процесс кодирования остаётся непроработанным или экспериментальным. При сравнении HDR-контента без использования карт усиления два применённых в тестах показателя качества дают противоречивые результаты, однако оба сходятся в том, что JPEG XL позволяет получить файлы меньшего размера, чем AVIF. JPEG XL даёт возможность уменьшить размер существующих JPEG-файлов на 9-20% без дополнительной потери качества. Скорость декодирования у него такая же или даже выше (за исключением изображений небольшого размера).

В режиме сжатия без потерь (lossless) лидирует JPEG XL. Формат WebP (без потерь) позволяет получить файлы на 9-17% больше, а AVIF (без потерь) - на 30-120% больше. При настройках максимального сжатия без потерь в jixel зачастую создаются файлы, которые декодируются слишком медленно.

  1. Главная ссылка к новости (https://jakearchibald.com/2026...)
  2. OpenNews: Представлен формат изображений AVIF 1.2
  3. OpenNews: Опубликованы libavif 1.0 и SVT-AV1 1.7, библиотеки для форматов изображений AVIF и видео AV1
  4. OpenNews: Представлен формат сжатия изображений Spectral JPEG XL
  5. OpenNews: В спецификацию PDF добавлена поддержка формата изображений JPEG XL
  6. OpenNews: Google готов вернуть в Chrome поддержку формата JPEG-XL
Автор новости: Artem S. Tashkinov
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/66493-jpegxl
Ключевые слова: jpegxl, avif
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (6) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Bottle (?), 00:59, 17/10/2026 [ответить]  
  • +1 +/–
    Ну то есть JXL за счёт обратной совместимости и поддержки в PDF выигрывает все равно.
     
     
  • 2.3, Ivan_83 (ok), 01:09, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Для AVIF/av1 будет только прирастать колличество аппаратных платформ которые могут кодить/декодить.
    Я бы сказал что это винрарное комбо: единый свободный кодек для фоток и видео да ещё и в железе, единственное что там AV2 вышел и не понятно насколько оно сможет переиспользовать эти блоки и формат.

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

     
     
  • 3.6, Смузихеб забывший пароль (?), 02:15, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    гугол свои поделия запросто выкидывает на мороз и без всякого сожаления
    ввиду этого то, что упомянутое - гугловое поделие, едва ли аргумент
     

  • 1.4, Аноним (4), 01:18, 17/10/2026 [ответить]  
  • +1 +/–
    Все лучше, чем недоразумение WebP и обвешанный патентами HEIF.

    JPEG в свое время стал значительно лучше с развитием кодировщиков и без нарушения совместимости. И вот интересно, насколько и JXL и AVIF есть потенциал для усовершенствования кодировщиков без изменения формата?

     
  • 1.5, Аноним (5), 01:44, 17/10/2026 Скрыто ботом-модератором     [к модератору]
  • +1 +/–
     
  • 1.7, Аноним (7), 02:34, 17/10/2026 [ответить]  
  • +/–
    > Как правило, AVIF быстрее производит кодирование и потребляет меньше памяти с учётом размера итогового файла. Кодировщик jixel работает быстрее AVIF и требует меньше памяти...

    Так я не понял, кто быстрее-то?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    XSQUARE
    Inferno Solutions
    Hosting by Hoster.ru
    Хоcтинг: