Профиль: Аноним (вход | регистрация) не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 (libavif). При максимальных уровнях сжатия разрыв сокращался до 6-20%. В отдельных тестах JPEG XL приближался к AVIF (libavif) или даже превосходил его. При этом на результат 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, созданные libavif.

Как правило, AVIF (libavif) быстрее производит кодирование и потребляет меньше памяти с учётом размера итогового файла. Кодировщик jixel работает быстрее libavif и требует меньше памяти, однако создаваемые им файлы обычно значительно крупнее.

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

Использование более высоких уровней сжатия оправдано для libavif и 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 обязательно


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

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

     
     
  • 3.6, Смузихеб забывший пароль (?), 02:15, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    гугол свои поделия запросто выкидывает на мороз и без всякого сожаления
    ввиду этого то, что упомянутое - гугловое поделие, едва ли аргумент
     
     
  • 4.8, Аноним (8), 03:20, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/–
    Все эти форматы какие то нонеймы
    Базарю через лет 10 уже нечем это открывать будет. А jpg/png/bmp вечны.
     
     
  • 5.10, Ivan_83 (ok), 03:37, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    ffmpeg открывает такие кодеки о которых вы поди и не слышали :)
    У меня в асусовском кодеке видосы есть, его походу забросили все давно уже и оно открывается.
     
     
  • 6.28, Bottle (?), 09:21, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Вот поэтому он их и открывает, что эти кодеки мертвы и пользуются ими изредка.
     
  • 6.37, Аноним (37), 10:00, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    А встроенный в Файрфокс Ффмпег тоже открывает всякие редкие штуки? Или, как обычно, нужно под каждый конкретный формат обвязку делать?
    Если чего-то нет в распространенной общедоступной реализации, то, можно считать, что этого нет.
     
  • 6.41, IdeaFix (ok), 11:26, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Эхх... а вот matrox avi...
     
  • 5.12, Аноним (12), 03:52, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    qoi
     
  • 5.52, черпало (?), 14:53, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    pcx, tiff, tga...
     
  • 4.16, Аноним (16), 05:45, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/–
    > гугол свои поделия запросто выкидывает на мороз и без всякого сожаления

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

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

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

     
     
  • 6.60, Bottle (?), 16:48, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    У нас есть великолепный пример с Паскалем и стандартом ISO на его спецификацию. Стандарт есть, но де-факто его нет, и та небольшая часть пользователей, что пишет на Паскале, применяет Дельфи.
     
  • 6.63, Аноним (16), 17:30, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > гугол свои поделия запросто выкидывает на мороз
    > самый простой вариант - просто выпуск очередной версии браузера

    И как это относится к твоему изначальному утверждению о "гугол свои поделия запросто выкидывает на мороз".

    Он может точно так же "выкинуть" из Хрома PNG с JPEG. И что дальше?

     

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

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

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

    Недостаточно мыльный.

     
  • 3.31, Аноним (31), 09:50, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Цвета шакалит.
     
     
  • 4.36, Аноним (25), 09:58, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • –2 +/–
    > Цвета шакалит.

    sharpyuv не шакалит, ты не отличишь от стандартного жпег

     
     
  • 5.64, Аноним (16), 17:31, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    Отличишь, потому что там субдескритизация цвета сугубо 4:2:0.
     
     
  • 6.66, Аноним (25), 17:43, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    У типичного жпег тоже, дальше что?
     
  • 2.55, Cykooz (ok), 15:36, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Сам HEIF не обвешан патентами. Это просто контейнер на базе формата BMFF (MP4 на его же базе) для хранения медиаданных.

    Патенты есть на кодеки типа H264+. Но с HEIF можно любые кодеки использовать, тот же AV1 или JPEG.

    Но есть конечно и "подлянка" у этого контейнера. Его спецификация находится за ISO-шным пейволом с довольно не гумманым прайсом для "Васянов", которые хотят написать свою реализацию.

     

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

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

     
     
  • 2.17, Аноним (16), 05:48, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    JPEG 👍
     
  • 2.53, черпало (?), 14:55, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/–
    avif -- второй, jixel -- предпоследний
     

  • 1.9, Аноним (5), 03:33, 17/10/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/–
    Обычного jpeg вполне достаточно.
     
     
  • 2.11, Аноним (11), 03:43, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/–
    комуто и лопухов в лесу достаточно чтобы подтираться, но нормальные люди предпочитают иные маретиалы.
     
     
  • 3.47, Аноним (47), 13:10, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > предпочитают иные маретиалы

    Мухоморы, например :)

     
  • 2.22, St (??), 08:20, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    Он давно устарел, а я хочу фотки HDR рассматривать и показывать.
     
     
  • 3.48, Аноним (47), 13:11, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    На чём? На 6-битной матрице, аппроксимированной ШИМом до 8 бит?
     
     
  • 4.61, Bottle (?), 16:49, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Товарищ, не все живут в нулевых, ох, трудно будет тебе рассказать, что произошло за всё это время...
     
     
  • 5.67, Аноним (25), 17:51, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Емнип такие матрицы и сегодня сертифицируют на какой-то из hdr10, хоть это и редкость. Большинство 12 битных на деле 8 битные тоже.
     

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

  • 1.18, Аноним (18), 06:24, 17/10/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/–
    Во всех трех современных форматах (Jpeg XL, AVIF, WebP) упаковка сторонних данных не требует искажения пикселей (стеганографии). А значит там можно спокойно прятать код SkyNet'а.
     
     
  • 2.50, Аноним (50), 13:30, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Есть способ и приложения санитарии?
     

  • 1.23, Аноним (25), 08:36, 17/10/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/–
    Какие-то удивительные результаты, у avif сильное выцветание и размыливание деталей, дефекты краёв. Причём, на любом качестве. И тут чувак заявляет, что для графики и снимков экрана лучше всего. Одно это заставляет усомниться, видимо, нейронка всё делала, а метрики прямо скажем булшит -- считают видимые дефекты лучшим качеством. Мне больше интересно, как он получил "AVIF (без потерь)" потому что PAE=0 с ним не получить, а значит, исходное изображение навсегда утеряно.
     
     
  • 2.65, Аноним (16), 17:37, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > Какие-то удивительные результаты, у avif сильное выцветание и размыливание деталей, дефекты краёв.

    В оригинальной статье есть сравнения изображений, где невооруженным глазом видно, что, наоборот, у JPEG XL мыло несоизмеримо больше, чем у AVIF - да еще и при большем размере файла.

     
     
  • 3.68, Аноним (25), 18:10, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Зависит от размера. Jpegxl немного плывёт с увеличением DCT (во всяком случае так было лет 7 назад), меньше 1 это практически visually lossless (можно безопасно задействовать ~0.460 и ниже, оно и быстрее в 15 раз) и у avif на таком битрейте это уже мыло при близком рассмотрении и с каждым обновлением кодеков всё больше мыла и артефактов.

    У jpegxl есть хороше преимущество, он замазывает типичные артефакты кодирования (актуально, когда исходник не совсем исходник), и avif рассыпается на артефакты, которые забрают себе бюджет.

     
     
  • 4.69, Аноним (16), 18:54, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > Зависит от размера

    Ну так я же говорю: большее мыло при большем же размере. Визуальная разница огромна. Но это если судить сугубо по картинкам из статьи - хз, может автор не шарит в параметрах кодирования.

     

  • 1.30, Метрика (?), 09:43, 17/10/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/–
    Меряли как известно теплое с мягким и пофиг на отсутствие сжатие без потерь в AVIF, и пофиг на отсутствие RAW-данных в AVIF, а самое интересное как меряли и кто мерял, если я померяю то AVIF мылит сильно, вопрос как они определяют сопоставимое качество, на основании своих субьетивных ощущений и цветопередачи с резкостью конкректного разработчика мазилы
     
     
  • 2.42, Karl Richter (ok), 12:08, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    Там есть сжатие без потерь и что оно там мылит? Как вы определили?
     
     
  • 3.56, Метрика (?), 15:47, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Определил я субьективно на глаз по гайду мозиллы

    AVIF не справляется с сжатием без потерь, файлы получаются больше чем в PNG которому уже лет 30 если не больше, это регресс в стиле битмапа, в тоже время JXL жмет без потерь лучше PNG

     
  • 3.57, Метрика (?), 15:49, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Видеокодеками сжимать изображения идея достаточно очевидная, но увы не удачная, так же как и растровым кодеком сжимать видео, можно конечно но результат будет хуже чем у профильного кодека
     

  • 1.32, Аноним (32), 09:50, 17/10/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/–
    AV1 кодировались только на CPU? Или GPU тоже подключался?
     
  • 1.33, Аноним (31), 09:51, 17/10/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/–
    Хорошая реклама, Джейк, но AVIF мы использовать всё равно не будем.
     
     
  • 2.43, Karl Richter (ok), 12:09, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    Я использую, так как мне место дорого.
     

  • 1.34, Mik Foxi (ok), 09:52, 17/10/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/–
    Почему не сравнить с WebP, который для веба по прежнему выглядит сильно адекватнее по всем параметрам.
     
     
  • 2.49, Аноним (47), 13:14, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > WebP

    Недостаточно много ресурсов потребляет. Вот AV1 - это да! Сжирает всё и ещё просит.

     
     
  • 3.54, черпало (?), 14:57, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    доброму коню всё впрок!
    большому куску и рот радуется!
     

  • 1.35, Аноним (35), 09:58, 17/10/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/–
    А че они APNG так и не реализовали? Мне больше PNG нравится, т.к. он без потерь.
     
     
  • 2.38, Аноним (31), 10:07, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    В смысле не реализовали? Реализовали же.
     
  • 2.39, Аноним (37), 10:09, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/–
    Слишком хорош и прост, недостаточно поверхность атаки увеличивает. Нужно чтобы и avx, и gpu задействованы были.
     
     
  • 3.59, dimasafonis (?), 16:39, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    А вы думаете ваш PNG декодер не использует AVX?.. Смело конечно, особенно с учётом того, что его используют и zlib-ng и libdeflate, и даже нн igzip - все они используют AVX, и даже AVX512, и все они быстрее zlib, который не использует даже SSE.
     
  • 2.44, Метрика (?), 12:09, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/–
    JXL совмещает в себе JPEG, PNG, GIF в этом его универсальность и весит меньше чем вышеперечисленные
     
  • 2.58, уп (?), 16:29, 17/10/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Почти ровно 10 лет назад реализовали. https://groups.google.com/a/chromium.org/g/blink-dev/c/KcMjmFOgG2w
     

  • 1.40, LaunchWiskey (ok), 11:01, 17/10/2026 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +5 +/–
     
  • 1.46, вах (ok), 12:47, 17/10/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/–
    Steam выбрал AVIF для сохранение скриншотов в HDR, значит наверное он лучше.
     
  • 1.51, Аноним (51), 14:37, 17/10/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/–
    под винду есть wic кодек jpegxl, который работает везде и все время. а с avif проблемы там постоянные. wic кодака нет совмем. а микрософтовсктй костыль из магазина не работает.  у меня к примеру на 10 iot фотографии этот формат не показывают, и превьюшки не работают тоже.
     
  • 1.62, Bob (??), 17:04, 17/10/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/–
    Чёт как-то специфически тестил.
    Вот за лохматый 2023 сравнение https://tonisagrista.com/blog/2023/jpegxl-vs-avif/ 6.9 Mb в 146 Kb сжимают. Avif шакалит, JXL поближе к оригиналу, но чуть мылит.

    Киллер фича can shrink existing JPEGs with no quality loss at all

     

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



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