19.08.2024 09:00
alizar 65 20000 Источник

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 ?

Комментарии (65)


  1. Conung_ViC
    19.08.2024 09:07
    #27181706
    +3

    Ссылка на расширение - ведет на 404. Реп удалили или ссылка изначально была битая?


    1. alizar Автор
      19.08.2024 09:07
      #27181750
      +1

      Действительно, реп удалили, странно... https://web.archive.org/web/20240807174630/https://github.com/zamfofex/jxl-crx


      1. Conung_ViC
        19.08.2024 09:07
        #27181896
        +8

        причем удалили не только реп, но и профиль целиком...


  1. akabrr
    19.08.2024 09:07
    #27181800

    Первый шаг к закату хрома?


    1. artptr86
      19.08.2024 09:07
      #27181816
      +10

      Первый?


    1. ahabreader
      19.08.2024 09:07
      #27181838
      +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 для картинок.


      1. Burtanshy
        19.08.2024 09:07
        #27182110

        FF 129.0.1 флаг стоит в положение false xD


        1. ahabreader
          19.08.2024 09:07
          #27182182

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


          1. dartraiden
            19.08.2024 09:07
            #27182338

            Потому что релизные версии собраны без libjxl

            Нет ножек - нет мультиков Нет библиотеки - нет поддержки формата


      1. CptAFK
        19.08.2024 09:07
        #27189414

        Вопрос денег. Firefox живёт за счёт денег Google. Им сказали не лаять, они не лаят.


  1. ky0
    19.08.2024 09:07
    #27181892
    +7

    Пол-интернета ещё нормально показывать/скачивать WebP (особенно анимированные) не научилось - а вы предлагаете ещё виток сделать :)

    Имхо, разница с WebP гомеопатическая и важнее пушить отказ от jpeg/png/gif, чем выигрывать два процента на XL.


    1. ahabreader
      19.08.2024 09:07
      #27182158
      +30

      От VP8 в видео все отказались, а в картинках кодек уровня ~2000 года надо начать лучше поддерживать? Нет, здесь его тоже надо забыть как первую неудачную попытку гугла.

      разница с WebP гомеопатическая

      Только не у нового JPEG (JXL), а у старого. По статье WebP уступает новому кодеку оригинального JPEG.

      График из статьи с пояснением
      (v2)
      (v2)

      Именно поэтому стоит перейти на JXL - чтобы не менять один компромиссный зоопарк форматов на другой. У WebP нет lossy 4:4:4-режима, у AVIF lossless сделан для галочки (хуже, чем в WebP), впереди AV2 в контейнере от AVIF. Пережатие JPEG без потерь никто из них не предложит.

      чем выигрывать два процента на XL.

      Даже в lossless не 2%, а 15%.


      1. ky0
        19.08.2024 09:07
        #27182256

        Видео и анимированные картинки - это разные вещи, используемые в разных случаях.


        1. ahabreader
          19.08.2024 09:07
          #27182308
          +1

          VP8 == lossy WebP.

          VP8 используют в lossy WebP как AV1 используют в AVIF (или я не понял комментарий).

          ----

          Добавлю к списку отсутствие прогрессивного режима в WebP.


    1. Self_Perfection
      19.08.2024 09:07
      #27184546
      +2

      Lossless перекодирование jpeg изображений в JXL с уменьшением размера - весьма полезная фича, у WebP такого нет


    1. NyakoNya
      19.08.2024 09:07
      #27189768

      Мне из-за кривой поддержки WEBP на устройствах пришлось пилить конвертер изображений в парсере одного сайта ибо WEBP в условной галере на бюджетном смартфоне тупа не откроет.


  1. gudvinr
    19.08.2024 09:07
    #27181928
    +2

    Qualcomm тоже недавно выпустила чипы Snapdragon X с поддержкой аппаратного кодирования AV1 (AVIF), но не JPEG XL.

    А аппаратное кодирование webp, png, jpeg и gif давно в процессорах есть?


    1. kenomimi
      19.08.2024 09:07
      #27182188
      +3

      jpeg есть везде вообще, даже на микроконтроллерах пожирнее. Остальное - нет.


      1. gudvinr
        19.08.2024 09:07
        #27182266
        +4

        Во-первых, "везде" есть только декодирование. А во-вторых, в Qualcomm Hexagon (который во всех Snapdragon используется) его нет.
        В NVDEC и кажется в процессорах AMLOGIC тоже нет.

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


        1. pash7ka
          19.08.2024 09:07
          #27187092

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


          1. gudvinr
            19.08.2024 09:07
            #27188408
            +2

            Аппаратные кодеки для изображений бесполезны, когда в кармане лежит железка с производительностью мейнфрейма и напичканы SIMD инструкциями. В современных реалиях скорее всего копирование в/из DSP будет занимать времени примерно столько же, сколько софтверное де/кодирование. А то, что фотка кодироваться будет на 0.0005 секунд быстрее - это вообще не важно.

            Это ведь не видео, требования другие совсем


            1. Ritan
              19.08.2024 09:07
              #27188786

              На телефонах многим интересно не как долго, а сколько энергии сожрёт сжатие. И тут уже могут быть варианты


            1. CptAFK
              19.08.2024 09:07
              #27189418
              +1

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


              1. gudvinr
                19.08.2024 09:07
                #27192060

                Это ведь не видео, требования другие совсем


    1. vanxant
      19.08.2024 09:07
      #27183248
      +3

      Внутре webp по своей сути то же самое дискретное косинус-преобразование (DCT), что и внутре классического jpeg. Но только если у jpeg блоки всегда имеют размер 8х8, то у webp есть 4х4 и 16x16. Другими словами, поддержка сжатия jpeg скорее всего ускоряет и webp тоже (причём libwebp от гугла хорошо затюнена под соответствующие инструкции).

      В принципе, webp неплохой формат именно для доставки конечного контента. Но его нужно уметь готовить. По умолчанию гугл ради циферок сжатия выставляет шакалистость 8/10 и совсем лютый ужас с цветом. Поэтому приходится вручную пробрасывать кодировщику нормальное качество и включать режим sharp_yuv. Из коробки не каждая либа это умеет, поэтому бывает что приходится тащить с собой пакет webp и вызывать cwebp через командную строку.


  1. kenomimi
    19.08.2024 09:07
    #27182184
    +24

    Но складывается впечатление, что компания Google просто решила сделать ставку на другой формат AVIF, хотят тот и уступает JPEG XL во многих тестах.

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

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


  1. ganzmavag
    19.08.2024 09:07
    #27182300
    +3

    Как уже говорилось, JPEG XL поддерживает пережатие JPEG без потерь. Таким образом, выгодно использовать его в качестве исходного или базового формата, из которого можно создать «стандартный JPEG» при необходимости. Этот подход обеспечивает лучшее визуальное качество и коэффициент сжатия, чем кодирование изначально в JPEG. Именно так работает продвинутая библиотека кодирования Jpegli, полностью совместимая с существующими декодерами JPEG. 

    Несколько раз перечитал и не понял, в чем связь библиотеки для кодирования базового JPEG и формата JPEG XL.

    По поводу самого формата: честно говоря, мне и преимущества WEBP не особенно очевидны. Когда делаешь качество действительно как у оригинала, то размер толком не отличается. А на сайтах, где WEBP используют в проде, очень бросается в глаза мыльность картинок.


  1. Revertis
    19.08.2024 09:07
    #27182366
    +1

    Вся экосистема недостаточно заинтересована в продолжении экспериментов с JPEG XL.

    Это они про какую экосистему? Гугловую?


  1. blind_oracle
    19.08.2024 09:07
    #27183278
    +1

    Именно так работает продвинутая библиотека кодирования Jpegli, полностью совместимая с существующими декодерами JPEG. Библиотека создана группой разработчиков JPEG XL с применением психовизуальной модели libjxl и по описанию превосходит по производительности WebP (WebP с потерями).

    Ну, так, к слову - jpegli сделал тоже гугл (по вашей же ссылке). Это же не пчёлы против мёда?

    Что, в общем, неплохой компромисс между включением Jpeg XL, который по факту и так никто не использовал нигде. Другое дело, что сжимать с помощью jpegli вряд-ли всех заставишь и будет опять каша.


    1. ahabreader
      19.08.2024 09:07
      #27183868
      +2

      Это же не пчёлы против мёда?

      Это пасека. Один улей делает jpegli и участвует в разработке JXL, а другой убирает поддержку JXL из хрома.


      1. blind_oracle
        19.08.2024 09:07
        #27184042

        Возможно.

        Судя по названию, оно было выковано в швейцарском офисе гугла, как и прочие -li ( brotli, zopfli ...)

        А Хром, наверное, пилят в Америке в основном. Битва миров :)


  1. ifap
    19.08.2024 09:07
    #27183406
    +2

    Google почему-то удалила его поддержку из браузера Chrome

    Потому, что может. Более точное объяснение - лишь частный случай этого множества.


  1. wmlab
    19.08.2024 09:07
    #27183466

    Еще бы понять, какие такие недостатки есть у JPEG XL, что Google не желает с ним иметь дела.


    1. evtomax
      19.08.2024 09:07
      #27183480
      +3

      Ну один фатальный точно есть...


    1. astenix
      19.08.2024 09:07
      #27183576

      Название.

      Сегодня будет JPEG XL, завтра кто-то придет с JPEG XXL, потом придумают JPEG 6XL и понеслось, будет не формат изображений, а вещевой рынок…


    1. Tomasina
      19.08.2024 09:07
      #27183976
      +3

      Наличие в команде автора WebP.


  1. Fahrain
    19.08.2024 09:07
    #27183590
    +7

    Вы сначала хотя бы gif закопайте, прежде чем за jpeg браться)

    Напомню, что до JpegXL был "тоже лучший" Jpeg2000 - который за 24 года так и не смог с jpeg хоть как-то заметно конкурировать. Так же как и WebP сегодня - он вроде как есть, но по факту им пользуются исключительно на сайтах и исключительно чтобы пройти проверку на скорость сайта от Гугла, а не потому, что он картинку лучше/меньше делает.

    По факту, единственное место, где я хоть когда-то встречал JpegXL - это HDR фотографии. Причем выкладывают их в таком формате полторы калеки - в отличие от jpeg/png, которые буквально на каждом шагу. Да и смотреть их не на чем - hdr-экраны так толком и не поддерживаются ни виндой, ни играми, ни другим софтом. А там где такая поддержка есть - лучше её отключить, чем использовать, картинка лучше становится. В итоге получается, что и для этих целей нам JpegXL тоже сегодня не нужен...


    1. funny_falcon
      19.08.2024 09:07
      #27183740
      +2

      ЕМНИП, у jpeg2000 были серьезные проблемы с лицензией. Т.е. он (был?) далеко не «бесплатный» и не «свободный».

      Если я правильно понимаю статью, jpegxl лишён этого фатального недостатка. Но могу ошибаться.


      1. Fahrain
        19.08.2024 09:07
        #27184086
        +3

        Наличие лицензии вообще не помешало взлёту divx, например. Мне кажется, что проблема всё-таки в другом: все эти новые кодеки просто не дают таких преимуществ, ради которых на них стоило бы перейти, ломая сложившиеся за десятилетия привычки. Да, даже 20% улучшения просто не достаточно - нужно именно на порядки. Как переход с mpeg2->divx, divx->h264, h264->h265/avc1.

        И даже это не гарантия: пример формата gif это наглядно показывает. Нужны еще и удобные инструменты. Которые под эти новые форматы просто отсутствуют. Или сделаны так, что ими вообще неудобно пользоваться. Именно поэтому gif всё ещё жив, а webp годами где-то на грани "еще чуть-чуть и умер".


        1. Grey83
          19.08.2024 09:07
          #27185166
          +2

          Да, даже 20% улучшения просто не достаточно - нужно именно на порядки. Как переход с mpeg2->divx, divx->h264, h264->h265/avc1.

          А эти самые порядки в двоичной системе подразумеваются, что ли?
          Потому что разница м/у AVC и HEVC что-то около 2 раз, а не 10, емнип.


          1. Fahrain
            19.08.2024 09:07
            #27187168

            Я недаром h265 (HEVC) и AVC1 через дробь написал. У них примерно одинаковый результат выходит по соотношению размерфайла-качество. Но если сравнивать с предыдущим поколением - h264 - то разница уже кратная. Т.е. при тех же самых параметрах кодирования итоговый файл получается в 3-10 раз меньше. В отдельных случаях может вообще ужаться до каких-то невообразимых величин, типа 2-5 мб на 5 минут hd-видео (но это надо чтобы было очень много однотонного фона в картинке).

            Единственное, что сдерживает сегодня массовый переход на эти кодеки - необходимость в новых процессорах уровня хотя бы Ryzen1 (с AVX512), а многие до сих пор сидят на технике пятнадцатилетней давности и более.


            1. Grey83
              19.08.2024 09:07
              #27187238

              H.264 - это AVC, тащемта
              https://ru.m.wikipedia.org/wiki/H.264


              1. Fahrain
                19.08.2024 09:07
                #27187452

                Странно. Я почему-то считал, что есть только один AVC - https://ru.m.wikipedia.org/wiki/AV1 Ну, будем считать, что там, где я упоминал AVC - речь шла о новом кодеке, а не про h264. Я лично предпочитаю всё-таки h265.


                1. ahabreader
                  19.08.2024 09:07
                  #27187664

                  Я почему-то считал, что есть только один AVC

                  Но он на самом деле один (а avc1 - это его FourCC).

                  H.264 (AVC) -> H.265 (HEVC) / AV1 (других названий не имеет).

                  при тех же самых параметрах кодирования

                  Только и качество будет разным (шкала crf не совпадает). Grey83 прав, там нет такой разницы, а есть что-то вроде "от 20% до 2 раз". Сколько именно - не так интересно, потому что H.264 не используют для 4K, H.265 отсутствует в вебе (то самое лицензирование)...


                  1. Fahrain
                    19.08.2024 09:07
                    #27187770

                    H.265 и AV1 - разные кодеки, они работают по-разному, имеют разные исполняемые файлы, разные настройки и даже скорость работы (и утилизация CPU) у них отличаются. В большинстве программ кодирования H.265 и AV1 даются на выбор отдельно, со своим пакетом настроек.

                    Ну и еще у них лицензии сильно различаются.

                    А! И главное, у AV1 проблемы с аппаратной поддержкой кодирования - долгое время время она вообще была только в картах от Интела, сейчас вроде бы получше стало. Это всё сильно повлияло на общую популярность кодека - из-за чего h265, имхо, пока немного выигрывает.

                    Ну и лично мне не понравилось, что у софтварного кодека AV1 очень уж низкая утилизация CPU. h265 этим тоже похвастаться не может, но на AV1 это намного заметнее. Т.е. приходится запускать по 4-5 копий кодирования (разных файлов параллельно) просто чтобы загрузить Ryzen 7950x хотя бы на 80%.

                    Grey83 прав, там нет такой разницы, а есть что-то вроде "от 20% до 2 раз". Сколько именно - не так интересно

                    Ну так-то да, алгоритмы ж разные. Но я уже много разных файлов пережал и в целом у меня сейчас получается так, что у h265 преимущество в размере файла (при визуально неразличимой разнице в качестве картинки) перед h264 в 3-10 раз в среднем. При этом преимущество в размере практически исчезает, если сжимать ролики где фоном очень много природы (трава, деревья, листья). Зато на ровном фоне (равномерно-белый или окрашенная стена + простая мебель) разница в размерах иногда и 10 раз превышает.

                    Если же сравнивать AV1 против h265 - то разницы на глаз не видно, а разница в итоговых размерах файлов или незначительна или скорее в пользу h265 (не всегда, но на моих роликах - чаще именно так).

                    Т.е. я это всё к тому, что после более-менее массового перехода на новые процессоры с AVX512 какой-то из этих двух кодеков в ближайшем будущем гарантированно заменяет популярный сегодня h264. Потому что эффективность видна наглядно.

                    Для JpegXL польза перехода наглядно не видна. Там где я его встречал - обычно были файлы в 50-100 мб размером с огромным разрешением. И, в общем, в этих условиях разница в размере файла с jpeg даже в 10-20 мб уже как-то не выглядит как то, ради чего стоило бы использовать новый формат.


                    1. ahabreader
                      19.08.2024 09:07
                      #27187962

                      H.265 и AV1 - разные кодеки, они работают по-разному ...

                      Но смысл черты... Три часа назад... Ещё как даром!

                      разница в размерах иногда и 10 раз превышает.

                      Я не знаю, где именно надо ошибиться, чтобы получить такую разницу, но ошибка здесь как минимум в приписывании этой разницы стандартам. H.264 и H.265 как технологии не дают такой разницы. Когда мир получил H.265, он не получил улучшений "на порядки". Он получил процентов свои, ну, минус 30%* (как между PNG и JXL). Все дальнейшие рассуждения сыпятся из-за этого.

                      * со слов "можно увидеть, что H.265", если хабру не нравится ссылка на текст.

                      PS: AVX-512 - не с первых Ryzen, а только с Ryzen 7000 (Zen 4).


                      1. Fahrain
                        19.08.2024 09:07
                        #27188168

                        h265 очень-очень хорошо жмет равномерный фон. Если такого фона много, а кадр в целом статичен - то эффективность в размере файла в сравнении с h264 просто зашкаливает при визуально незаметной разнице в качестве картинки. Ну т.е. если у вас говорящая голова на фоне стены этот кодек будет просто идеальным выбором.

                        И именно с этим же проблема если жать ролики с травой/листьями - много мелких деталей, кодек просто неэффективен. Ну как неэффективен? Где-то плюс-минус наравне с h264.

                        Т.е. разница в 10 раз в размерах файлов - это не преувеличение, по ощущениям, процентов 20 роликов у меня именно такие. Остальные же обычно в пределах 3 раз разницы в размере файла.

                        Причем иногда мне попадается что-то такое, где эффективность улетает вообще куда-то в бесконечность и я получаю ролик 640*480 пикселей длительностью в час и размером в 10-30 мб, например (без звука, только видео). При том, что такой же в h264 весил 600-1000 Мб. Я сначала не верил, что такое вообще возможно и думал, что там какая-то ошибка, но нет - даже по кол-ву кадров всё ок, ничего не сломано и не повреждено. Просто вот так вот эффективно ужало.

                        P.S.: Это, повторюсь, на моих видео - а я жму в разрешения иногда даже меньше 1024768 пикселей (задачи специфические, даже столько не всегда и нужно - 640480 хватает). Возможно, если брать что-то другое или жать в 4к, то там иная ситуация - я не проверял, мне не требуется.


                      1. ahabreader
                        19.08.2024 09:07
                        #27188298

                        Это хорошо, но достаточно странно, чтобы искать причину не в H.264 и H.265, а в выбранных реализациях H.264 и H.265 (если это не свежие x264 и x265) или в их дефолтных настройках.


  1. Loco2k
    19.08.2024 09:07
    #27183634

    Потому что ставка на av1, который уже имеет аппаратное декодирование. Гугл часть ассоциации, которая пилит свои кодеки, супротив mpeg и jpeg, т.к. там с ними могут быть коммерческие и юридические вопросы.


  1. IgnisNoir
    19.08.2024 09:07
    #27183924
    +1

    Я выдвину свое предположение, так что поправьте меня если я не прав, так как это просто предположение.

    Так может потому и не делают потому что это опасность для аппаратного кодирования на процессорах? Ведь место на кристале не бесконечное, а если каждый новый формат который лучше впихивать на кристал то это будет очень плохо. А тут есть AV1 который и так стандарт и на кристалах появляется и нужен еще и для видео которое используется уже. Так что это просто тупо выгоднее


    1. blind_oracle
      19.08.2024 09:07
      #27184032
      +1

      Картинки - не видео, особо смысла декодировать их хардварно нет как мне кажется. Не тот поток данных.

      Разве что да, для мобильных устройств, чтобы батарейку сэкономить.


      1. IgnisNoir
        19.08.2024 09:07
        #27184114

        Ну сейчас мобильные это основной инструмент просмотра интернета. так что да. Да и браузер сейчас в котором картинок слишком много также стал основным и главным окном в ОС


  1. mikegordan
    19.08.2024 09:07
    #27183926
    +1

    Очень странная таблица с сравнением. На ней у webp отмечен что не умеет в "прогрессив jpeg" это когда загружаются размеры сначала чтобы не скакала разметка, потом пиксельный вид, а потом уже полноценная картинка.

    или статья супер старая или ошибка или тут надо статьи фейкчекап делать.

    А так я согласен будущие за av1, надеюсь компании усилят влияние на апдейт железо с физическими декодерами и енкодерами av1.


  1. Tomasina
    19.08.2024 09:07
    #27183986
    +1

    Не нашел сравнение WebP и JPEG XL.

    Ибо начинать статью с "... который сжимает изображения примерно на 60% лучше, чем оригинальный JPEG" - моветон ради больших циферок. Может там разница 0,14% - чего тогда дергаться?


  1. php7
    19.08.2024 09:07
    #27184066

    Еще бы в статье первый рисунок был читаемый


  1. Fasterpast
    19.08.2024 09:07
    #27184160
    +1

    В свое время, я очень ждал avif, так как что у jpeg, что у webp не лады с красным. А конкретно - jpeg артифачит, а wepb размывает, причем практически при любом качестве с любыми профилям и настройками, в итоге фотки с красной графикой у нас на сайте (такой уж дизайн) долгое время были исключительно в жпеге с 98% качеством. Avif эту проблему решил ) не нравится только, что уж очень медленно он работает на сжатие. Касательно сабжа, надо бы тоже попробовать на наших фотках, ради интереса...


    1. Quarc
      19.08.2024 09:07
      #27185052
      +3

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


      1. ahabreader
        19.08.2024 09:07
        #27186586
        +4

        Вообще размытие происходит из-за понижения разрешения цветности (в 2 раза по обеим сторонам, "4:2:0").

        А красный выглядит наиболее размыто из-за каких-то особенностей протекания цветности и восприятия того, что получилось. Там магия слишком много факторов.

        Берём объект (текст) с заливкой одного цвета и фон оттенка серого. Переводим в YUV 4:2:0 и получаем, что цветность как бы вытекает за границы объекта (точнее, они смешиваются, нулевая цветность фона тоже втекает в объект).

        А дальше... Надо учесть, что зелёный (0,255,0) ярче (светлее) красного (255,0,0), а тот ярче синего (0,0,255). Учесть, что смешение идёт в YUV. Что слишком тёмный или слишком яркий фон при подмешивании цветности объекта изменит ещё и яркость в сторону серого. Что действия производятся без отмены гаммы (не в линейном пространстве), это важный фактор.

        Но почему всё-таки красный?.. На тёмном фоне зелёный (0,255,0) будет выглядеть не самым размытым, потому что он самый яркий, то есть самый контрастный. Наверное. А что касается синего на тёмном фоне и объектов на светлом фоне

        ***На этом комментарий обрывается, потому что больше ему сказать было нечего***

        Картинка
        Увеличение x8
        Увеличение x8


        1. ahabreader
          19.08.2024 09:07
          #27187192
          +2

          Ещё одна

          Вытекший зелёный казался слишком тёмным, а красный - слишком светлым? Цветовое пространство - ещё один фактор. Выше был YUV с коэффициентами из BT.709 (HD), а ниже - из BT.601 (JPEG, WebP, SD-видео).

          Под grayscale тоже имелась в виду luma (в предыдущий раз по BT.709).

          Исходник
          Исходник


  1. Nachahmer
    19.08.2024 09:07
    #27185248
    +1

    JPEG XL представляет существенные улучшения перед существующими форматами по следующим показателям:

    Развёртывание кодера в продакшне.

    Применение на всех этапах рабочего процесса.

    Простите, что?..


  1. pash7ka
    19.08.2024 09:07
    #27187114

    А есть JS-библиотека для перекодирования, чтобы загружать с сайта JPEG XL, а в броузере, если надо, перекодировать в JPEG?
    Для галерей фотографий наверное было бы полезно.


    1. Dimava
      19.08.2024 09:07
      #27189276

      Есть расширение. https://chromewebstore.google.com/detail/jpeg-xl-viewer/bkhdlfmkaenamnlbpdfplekldlnghchp?pli=1


      1. pash7ka
        19.08.2024 09:07
        #27190912

        Это я видел. Но расширение ставит пользователь и это не слишком способствует распространению формата.
        Какой формат изображений использовать решает владелец сайта. Если он видит, что у него куча пользователей хрома, он не сможет иcпользовать JPEG XL, т.к. не может рассчитывать что у всех будет стоять нужное расширение.
        Но он может добавить на страницы сайта скрипт, который обеспечит правильное отображение JPEG XL фотографий, в случае если отсутствует или выключена нативная поддержка браузером.
        Я спрашиваю именно о такой библиотеке - которую просто добавил в код страницы, и она поддержку добавит.

        Upd: Нашел, что есть такое: https://github.com/niutech/jxl.js


  1. enrupt
    19.08.2024 09:07
    #27187348

    мб запрещенная в России соц. сеть (и другие основные поставщики картиночного контента) отказалась перекодировать свои изображения в новый формат?


  1. alliumnsk
    19.08.2024 09:07
    #27188482

    Такое чувство, что запретили поддержку потому, что его название напоминало, что у них самих XS. (Извините).

    А ведь старый джипег можно еще как-то посложнее распаковать, чем просто раскрыть ДКП, тем более, что новые форматы как раз больше требуют усилий.

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