Профиль: Аноним (вход | регистрация) не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 обязательно


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

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

     
     
  • 3.6, Смузихеб забывший пароль (?), 02:15, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    гугол свои поделия запросто выкидывает на мороз и без всякого сожаления
    ввиду этого то, что упомянутое - гугловое поделие, едва ли аргумент
     
     
  • 4.8, Аноним (8), 03:20, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/–
    Все эти форматы какие то нонеймы
    Базарю через лет 10 уже нечем это открывать будет. А jpg/png/bmp вечны.
     
     
  • 5.10, Ivan_83 (ok), 03:37, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    ffmpeg открывает такие кодеки о которых вы поди и не слышали :)
    У меня в асусовском кодеке видосы есть, его походу забросили все давно уже и оно открывается.
     
  • 5.12, Аноним (12), 03:52, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    qoi
     
  • 4.16, Аноним (16), 05:45, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/–
    > гугол свои поделия запросто выкидывает на мороз и без всякого сожаления

    Что такое "выкидывание на мороз" относительно открытого стандарта и опенсорсной либы?

     
     
  • 5.19, Смузихеб забывший пароль (?), 06:56, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/–
    самый простой вариант - просто выпуск очередной версии браузера, где поддержка формата по умолчанию убрана с перспективой полного выпиливания "для упрощения поддержки" и "избавления от старого ненужного функционала"

    формат вроде бы остался, не осталось лишь возможности его реального применения т.к нафиг никому не нужен даже даром

     

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

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

     
     
  • 2.25, Аноним (25), 08:55, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Ты хотел сказать HEIC, потому что AVIF это тоже HEIF. Видимо, опенсорсные кодировщики использовали не патентованные алгоритмы в libx265, и качество картинки по удивительному совпадению проигрывало проприетарным реализациям. В этом отношении av1 лучше, и что с того, что он такое убожество. Но реально, надо им покормить халявщиков и накидать не урезанный формат изображений с h266, почему то уверен, что результаты разом смоют гугл в унитаз.
     

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

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

     
     
  • 2.17, Аноним (16), 05:48, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    JPEG 👍
     

  • 1.9, Аноним (5), 03:33, 17/10/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/–
    Обычного jpeg вполне достаточно.
     
     
  • 2.11, Аноним (11), 03:43, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    комуто и лопухов в лесу достаточно чтобы подтираться, но нормальные люди предпочитают иные маретиалы.
     
     
  • 3.14, Норм (?), 04:32, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/–
    Газетку Правда пожамканую поди.
     
     
  • 4.21, Мохнонос (?), 08:07, 17/10/2026 Скрыто ботом-модератором     [к модератору]
  • +/–
     
  • 2.22, St (??), 08:20, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Он давно устарел, а я хочу фотки HDR рассматривать и показывать.
     

  • 1.13, Аноним (13), 03:57, 17/10/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/–
    А чего с webp не сравнил, или что то что это одного сорта +\- 20% и всё на этом?
     
     
  • 2.15, Норм (?), 04:35, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Вебп такое дно что даже сравнивать не с чем. Стремная фигея шакалящая то что жпен не смог зашакалить.
    Типо как энтот самый, vp9 на ютубе.
    Трафик оно экономит канечно, в том плане что смотреть на это невозможно.
     
     
  • 3.24, Аноним (25), 08:46, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    У вебп из основных минусов только лесницы на градиентах из-за вп8, у вп9 с бандингом лучше. Главное, что он позволяет лосслесс, да и с потерями качество с sharpyuv будет повыше жпег на одинаковом размере. Местами. В целом, я достаточно основательно сравнивал и не нашёл преимуществ у авиф по сравнению с вебп, кроме возможности сжать ещё сильнее и сохранить удобоваримое качество.
     

  • 1.18, Аноним (18), 06:24, 17/10/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/–
    Во всех трех современных форматах (Jpeg XL, AVIF, WebP) упаковка сторонних данных не требует искажения пикселей (стеганографии). А значит там можно спокойно прятать код SkyNet'а.
     
  • 1.20, Аноним (20), 07:55, 17/10/2026 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +/–
     
  • 1.23, Аноним (25), 08:36, 17/10/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/–
    Какие-то удивительные результаты, у avif сильное выцветание и размыливание деталей, дефекты краёв. Причём, на любом качестве. И тут чувак заявляет, что для графики и снимков экрана лучше всего. Одно это заставляет усомниться, видимо, нейронка всё делала, а метрики прямо скажем булшит -- считают видимые дефекты лучшим качеством. Мне больше интересно, как он получил "AVIF (без потерь)" потому что PAE=0 с ним не получить, а значит, исходное изображение навсегда утеряно.
     

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



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