Комментарии 70
Ссылка на расширение - ведет на 404. Реп удалили или ссылка изначально была битая?
Первый шаг к закату хрома?
Первый?
Закату?
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 для картинок.
Пол-интернета ещё нормально показывать/скачивать WebP (особенно анимированные) не научилось - а вы предлагаете ещё виток сделать :)
Имхо, разница с WebP гомеопатическая и важнее пушить отказ от jpeg/png/gif, чем выигрывать два процента на XL.
От VP8 в видео все отказались, а в картинках кодек уровня ~2000 года надо начать лучше поддерживать? Нет, здесь его тоже надо забыть как первую неудачную попытку гугла.
разница с WebP гомеопатическая
Только не у нового JPEG (JXL), а у старого. По статье WebP уступает новому кодеку оригинального JPEG.
График из статьи с пояснением
Именно поэтому стоит перейти на JXL - чтобы не менять один компромиссный зоопарк форматов на другой. У WebP нет lossy 4:4:4-режима, у AVIF lossless сделан для галочки (хуже, чем в WebP), впереди AV2 в контейнере от AVIF. Пережатие JPEG без потерь никто из них не предложит.
чем выигрывать два процента на XL.
Даже в lossless не 2%, а 15%.
Lossless перекодирование jpeg изображений в JXL с уменьшением размера - весьма полезная фича, у WebP такого нет
Мне из-за кривой поддержки WEBP на устройствах пришлось пилить конвертер изображений в парсере одного сайта ибо WEBP в условной галере на бюджетном смартфоне тупа не откроет.
Можно использовать <picture> + батарею <source> с разными форматами + <img> фоллбэк. Браузеры, которые умеют, загрузят WebP, которые не умеют, откатятся к JPEG/PNG.
Либл можно на сервере читать заголовок Accept, там будет список поддерживаемых форматов. И отдавать разные форматы в зависимости от заголовка.
А для старых устройств можно под картинкой ссылку на скачивание старого доброго JPEG сделать.
Не, тут о другом речь. Как раз браузеры уже хорошо поддерживают и webp, и avif, сильно обгоняя в этом отношении остальной софт. И нередко бывает, что сохранил юзер картинку на телефон, а галерея её не показывает. И неспециалисту вообще непонятно, что же не так.
И не очень понятно, как выходить из этого положения. Браузер поддержку формата серверу заявил, сервер отдал. А что там извне происходит, им фиолетово.
Qualcomm тоже недавно выпустила чипы Snapdragon X с поддержкой аппаратного кодирования AV1 (AVIF), но не JPEG XL.
А аппаратное кодирование webp, png, jpeg и gif давно в процессорах есть?
jpeg есть везде вообще, даже на микроконтроллерах пожирнее. Остальное - нет.
Во-первых, "везде" есть только декодирование. А во-вторых, в Qualcomm Hexagon (который во всех Snapdragon используется) его нет.
В NVDEC и кажется в процессорах AMLOGIC тоже нет.
Мысль была в том, что отсутствие аппаратного кодирования изображений абсолютно ни о чём не говорит, потому что оно не нужно практически никому.
Аппаратное кодирование может быть полезно, чтобы телефончик сразу в jxl фоточки сохранял.
Если их можно будет смотреть в чем угодно, то формат получит популярность.
Аппаратные кодеки для изображений бесполезны, когда в кармане лежит железка с производительностью мейнфрейма и напичканы SIMD инструкциями. В современных реалиях скорее всего копирование в/из DSP будет занимать времени примерно столько же, сколько софтверное де/кодирование. А то, что фотка кодироваться будет на 0.0005 секунд быстрее - это вообще не важно.
Это ведь не видео, требования другие совсем
На телефонах многим интересно не как долго, а сколько энергии сожрёт сжатие. И тут уже могут быть варианты
Это важно для экономии заряда батареи. Именно поэтому видео на ютуб может проигрываться сильно дольше по времени, чем фильм с вашего телефона.
В современных реалиях скорее всего копирование в/из DSP будет занимать времени
Но есди dsp имеет доступ к памяти, то и копировать не надо.
Внутре webp по своей сути то же самое дискретное косинус-преобразование (DCT), что и внутре классического jpeg. Но только если у jpeg блоки всегда имеют размер 8х8, то у webp есть 4х4 и 16x16. Другими словами, поддержка сжатия jpeg скорее всего ускоряет и webp тоже (причём libwebp от гугла хорошо затюнена под соответствующие инструкции).
В принципе, webp неплохой формат именно для доставки конечного контента. Но его нужно уметь готовить. По умолчанию гугл ради циферок сжатия выставляет шакалистость 8/10 и совсем лютый ужас с цветом. Поэтому приходится вручную пробрасывать кодировщику нормальное качество и включать режим sharp_yuv. Из коробки не каждая либа это умеет, поэтому бывает что приходится тащить с собой пакет webp и вызывать cwebp через командную строку.
Но складывается впечатление, что компания Google просто решила сделать ставку на другой формат AVIF, хотят тот и уступает JPEG XL во многих тестах.
Какой-нибудь топ-смузихлеб пробивал внедрение "своего" кодека, чтобы дать работу своему отделу, а вы тут принесли опенсорсную поделку, которая не обеспечит ему годовых бонусов на новую яхту и куртизанок. Понятно, что была дана команда отказать всем и не дергаться.
Плюс поддержа всех новомодных форматов (взять тот же webp) реализована через одно место на большинстве сайтов. Просто попробуйте загрузить webp картинку где-нибудь... Добавлять еще больше стандартов - добавлять головняк поддержке и пользователю.
Как уже говорилось, JPEG XL поддерживает пережатие JPEG без потерь. Таким образом, выгодно использовать его в качестве исходного или базового формата, из которого можно создать «стандартный JPEG» при необходимости. Этот подход обеспечивает лучшее визуальное качество и коэффициент сжатия, чем кодирование изначально в JPEG. Именно так работает продвинутая библиотека кодирования Jpegli, полностью совместимая с существующими декодерами JPEG.
Несколько раз перечитал и не понял, в чем связь библиотеки для кодирования базового JPEG и формата JPEG XL.
По поводу самого формата: честно говоря, мне и преимущества WEBP не особенно очевидны. Когда делаешь качество действительно как у оригинала, то размер толком не отличается. А на сайтах, где WEBP используют в проде, очень бросается в глаза мыльность картинок.
Вся экосистема недостаточно заинтересована в продолжении экспериментов с JPEG XL.
Это они про какую экосистему? Гугловую?
Именно так работает продвинутая библиотека кодирования Jpegli, полностью совместимая с существующими декодерами JPEG. Библиотека создана группой разработчиков JPEG XL с применением психовизуальной модели libjxl и по описанию превосходит по производительности WebP (WebP с потерями).
Ну, так, к слову - jpegli сделал тоже гугл (по вашей же ссылке). Это же не пчёлы против мёда?
Что, в общем, неплохой компромисс между включением Jpeg XL, который по факту и так никто не использовал нигде. Другое дело, что сжимать с помощью jpegli вряд-ли всех заставишь и будет опять каша.
Google почему-то удалила его поддержку из браузера Chrome
Потому, что может. Более точное объяснение - лишь частный случай этого множества.
Еще бы понять, какие такие недостатки есть у JPEG XL, что Google не желает с ним иметь дела.
Вы сначала хотя бы gif закопайте, прежде чем за jpeg браться)
Напомню, что до JpegXL был "тоже лучший" Jpeg2000 - который за 24 года так и не смог с jpeg хоть как-то заметно конкурировать. Так же как и WebP сегодня - он вроде как есть, но по факту им пользуются исключительно на сайтах и исключительно чтобы пройти проверку на скорость сайта от Гугла, а не потому, что он картинку лучше/меньше делает.
По факту, единственное место, где я хоть когда-то встречал JpegXL - это HDR фотографии. Причем выкладывают их в таком формате полторы калеки - в отличие от jpeg/png, которые буквально на каждом шагу. Да и смотреть их не на чем - hdr-экраны так толком и не поддерживаются ни виндой, ни играми, ни другим софтом. А там где такая поддержка есть - лучше её отключить, чем использовать, картинка лучше становится. В итоге получается, что и для этих целей нам JpegXL тоже сегодня не нужен...
ЕМНИП, у jpeg2000 были серьезные проблемы с лицензией. Т.е. он (был?) далеко не «бесплатный» и не «свободный».
Если я правильно понимаю статью, jpegxl лишён этого фатального недостатка. Но могу ошибаться.
Наличие лицензии вообще не помешало взлёту divx, например. Мне кажется, что проблема всё-таки в другом: все эти новые кодеки просто не дают таких преимуществ, ради которых на них стоило бы перейти, ломая сложившиеся за десятилетия привычки. Да, даже 20% улучшения просто не достаточно - нужно именно на порядки. Как переход с mpeg2->divx, divx->h264, h264->h265/avc1.
И даже это не гарантия: пример формата gif это наглядно показывает. Нужны еще и удобные инструменты. Которые под эти новые форматы просто отсутствуют. Или сделаны так, что ими вообще неудобно пользоваться. Именно поэтому gif всё ещё жив, а webp годами где-то на грани "еще чуть-чуть и умер".
Да, даже 20% улучшения просто не достаточно - нужно именно на порядки. Как переход с mpeg2->divx, divx->h264, h264->h265/avc1.
А эти самые порядки в двоичной системе подразумеваются, что ли?
Потому что разница м/у AVC и HEVC что-то около 2 раз, а не 10, емнип.
Я недаром h265 (HEVC) и AVC1 через дробь написал. У них примерно одинаковый результат выходит по соотношению размерфайла-качество. Но если сравнивать с предыдущим поколением - h264 - то разница уже кратная. Т.е. при тех же самых параметрах кодирования итоговый файл получается в 3-10 раз меньше. В отдельных случаях может вообще ужаться до каких-то невообразимых величин, типа 2-5 мб на 5 минут hd-видео (но это надо чтобы было очень много однотонного фона в картинке).
Единственное, что сдерживает сегодня массовый переход на эти кодеки - необходимость в новых процессорах уровня хотя бы Ryzen1 (с AVX512), а многие до сих пор сидят на технике пятнадцатилетней давности и более.
H.264 - это AVC, тащемта
https://ru.m.wikipedia.org/wiki/H.264
Странно. Я почему-то считал, что есть только один AVC - https://ru.m.wikipedia.org/wiki/AV1 Ну, будем считать, что там, где я упоминал AVC - речь шла о новом кодеке, а не про h264. Я лично предпочитаю всё-таки h265.
Я почему-то считал, что есть только один AVC
Но он на самом деле один (а avc1 - это его FourCC).
H.264 (AVC) -> H.265 (HEVC) / AV1 (других названий не имеет).
при тех же самых параметрах кодирования
Только и качество будет разным (шкала crf не совпадает). Grey83 прав, там нет такой разницы, а есть что-то вроде "от 20% до 2 раз". Сколько именно - не так интересно, потому что H.264 не используют для 4K, H.265 отсутствует в вебе (то самое лицензирование)...
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 мб уже как-то не выглядит как то, ради чего стоило бы использовать новый формат.
H.265 и AV1 - разные кодеки, они работают по-разному ...
Но смысл черты... Три часа назад... Ещё как даром!
разница в размерах иногда и 10 раз превышает.
Я не знаю, где именно надо ошибиться, чтобы получить такую разницу, но ошибка здесь как минимум в приписывании этой разницы стандартам. H.264 и H.265 как технологии не дают такой разницы. Когда мир получил H.265, он не получил улучшений "на порядки". Он получил процентов свои, ну, минус 30%* (как между PNG и JXL). Все дальнейшие рассуждения сыпятся из-за этого.
* со слов "можно увидеть, что H.265", если хабру не нравится ссылка на текст.
PS: AVX-512 - не с первых Ryzen, а только с Ryzen 7000 (Zen 4).
h265 очень-очень хорошо жмет равномерный фон. Если такого фона много, а кадр в целом статичен - то эффективность в размере файла в сравнении с h264 просто зашкаливает при визуально незаметной разнице в качестве картинки. Ну т.е. если у вас говорящая голова на фоне стены этот кодек будет просто идеальным выбором.
И именно с этим же проблема если жать ролики с травой/листьями - много мелких деталей, кодек просто неэффективен. Ну как неэффективен? Где-то плюс-минус наравне с h264.
Т.е. разница в 10 раз в размерах файлов - это не преувеличение, по ощущениям, процентов 20 роликов у меня именно такие. Остальные же обычно в пределах 3 раз разницы в размере файла.
Причем иногда мне попадается что-то такое, где эффективность улетает вообще куда-то в бесконечность и я получаю ролик 640*480 пикселей длительностью в час и размером в 10-30 мб, например (без звука, только видео). При том, что такой же в h264 весил 600-1000 Мб. Я сначала не верил, что такое вообще возможно и думал, что там какая-то ошибка, но нет - даже по кол-ву кадров всё ок, ничего не сломано и не повреждено. Просто вот так вот эффективно ужало.
P.S.: Это, повторюсь, на моих видео - а я жму в разрешения иногда даже меньше 1024768 пикселей (задачи специфические, даже столько не всегда и нужно - 640480 хватает). Возможно, если брать что-то другое или жать в 4к, то там иная ситуация - я не проверял, мне не требуется.
Потому что ставка на av1, который уже имеет аппаратное декодирование. Гугл часть ассоциации, которая пилит свои кодеки, супротив mpeg и jpeg, т.к. там с ними могут быть коммерческие и юридические вопросы.
Я выдвину свое предположение, так что поправьте меня если я не прав, так как это просто предположение.
Так может потому и не делают потому что это опасность для аппаратного кодирования на процессорах? Ведь место на кристале не бесконечное, а если каждый новый формат который лучше впихивать на кристал то это будет очень плохо. А тут есть AV1 который и так стандарт и на кристалах появляется и нужен еще и для видео которое используется уже. Так что это просто тупо выгоднее
Очень странная таблица с сравнением. На ней у webp отмечен что не умеет в "прогрессив jpeg" это когда загружаются размеры сначала чтобы не скакала разметка, потом пиксельный вид, а потом уже полноценная картинка.
или статья супер старая или ошибка или тут надо статьи фейкчекап делать.
А так я согласен будущие за av1, надеюсь компании усилят влияние на апдейт железо с физическими декодерами и енкодерами av1.
Не нашел сравнение WebP и JPEG XL.
Ибо начинать статью с "... который сжимает изображения примерно на 60% лучше, чем оригинальный JPEG" - моветон ради больших циферок. Может там разница 0,14% - чего тогда дергаться?
Еще бы в статье первый рисунок был читаемый
В свое время, я очень ждал avif, так как что у jpeg, что у webp не лады с красным. А конкретно - jpeg артифачит, а wepb размывает, причем практически при любом качестве с любыми профилям и настройками, в итоге фотки с красной графикой у нас на сайте (такой уж дизайн) долгое время были исключительно в жпеге с 98% качеством. Avif эту проблему решил ) не нравится только, что уж очень медленно он работает на сжатие. Касательно сабжа, надо бы тоже попробовать на наших фотках, ради интереса...
А вы не в курсе с чем это связано, почему именно красный? Тоже замечал, что мелкий красный текст в любых видеоформатах со сжатием размывается сильнее всего.
Вообще размытие происходит из-за понижения разрешения цветности (в 2 раза по обеим сторонам, "4:2:0").
А красный выглядит наиболее размыто из-за каких-то особенностей протекания цветности и восприятия того, что получилось. Там магия слишком много факторов.
Берём объект (текст) с заливкой одного цвета и фон оттенка серого. Переводим в YUV 4:2:0 и получаем, что цветность как бы вытекает за границы объекта (точнее, они смешиваются, нулевая цветность фона тоже втекает в объект).
А дальше... Надо учесть, что зелёный (0,255,0) ярче (светлее) красного (255,0,0), а тот ярче синего (0,0,255). Учесть, что смешение идёт в YUV. Что слишком тёмный или слишком яркий фон при подмешивании цветности объекта изменит ещё и яркость в сторону серого. Что действия производятся без отмены гаммы (не в линейном пространстве), это важный фактор.
Но почему всё-таки красный?.. На тёмном фоне зелёный (0,255,0) будет выглядеть не самым размытым, потому что он самый яркий, то есть самый контрастный. Наверное. А что касается синего на тёмном фоне и объектов на светлом фоне
***На этом комментарий обрывается, потому что больше ему сказать было нечего***
Картинка
JPEG XL представляет существенные улучшения перед существующими форматами по следующим показателям:
Развёртывание кодера в продакшне.
Применение на всех этапах рабочего процесса.
Простите, что?..
А есть JS-библиотека для перекодирования, чтобы загружать с сайта JPEG XL, а в броузере, если надо, перекодировать в JPEG?
Для галерей фотографий наверное было бы полезно.
Это я видел. Но расширение ставит пользователь и это не слишком способствует распространению формата.
Какой формат изображений использовать решает владелец сайта. Если он видит, что у него куча пользователей хрома, он не сможет иcпользовать JPEG XL, т.к. не может рассчитывать что у всех будет стоять нужное расширение.
Но он может добавить на страницы сайта скрипт, который обеспечит правильное отображение JPEG XL фотографий, в случае если отсутствует или выключена нативная поддержка браузером.
Я спрашиваю именно о такой библиотеке - которую просто добавил в код страницы, и она поддержку добавит.
Upd: Нашел, что есть такое: https://github.com/niutech/jxl.js
мб запрещенная в России соц. сеть (и другие основные поставщики картиночного контента) отказалась перекодировать свои изображения в новый формат?
Такое чувство, что запретили поддержку потому, что его название напоминало, что у них самих XS. (Извините).
А ведь старый джипег можно еще как-то посложнее распаковать, чем просто раскрыть ДКП, тем более, что новые форматы как раз больше требуют усилий.
Забавно, что исторически в джипеге всегда была предусмотрена поддержка 12-бит, но в силу редкой надобности мало когда реализовывалась, а сейчас когда хотят 12-бит, все забывают про это.
AVIF имеет будущее, а JPEG XL нет. AVIF использует алгоритмы сжатия AV1, который активно развивается большим консорциумом. В 2020г. для AV1 не было ни аппаратных кодеров/декодеров, в 2022 декодирование стало доступно в ТВ-боксах за 3000р., сейчас аппаратное декодирование есть/появляется во всех новых мобильных и десктопных процессорах, а кодирование - в самых продвинутых, по через 2-3 года будет во всех.
Любопытно, что в новом iPhone 16 обещают поддержку JPEG-XL.
JPEG XL лучше всех, но Google против