ИИтог

JPEG XL проигрывает AVIF: разбор инженера по сжатию

инфраструктураРедакция ИИтогHacker News🔥60Рейтинг ИИтог60Влияние45Новизна35Релевантность70Неожиданность45Участники50Достоверность75

Инженер по сжатию изображений и видео, ранее вместе с Хулио Барбой (Julio Barba) он занимался энкодером AV1 и, по собственным словам, внёс значимый вклад в развитие AVIF, а затем начал строить собственный кодировщик и сознательно решил не ориентировать его на JPEG XL, публикует развёрнутый разбор о том, стоит ли добавлять JPEG XL в веб-браузеры; в подписи поста указано его имя, Джанни Розато (Gianni Rosato). Формальный повод, декодер JPEG XL на языке Rust (jxl-rs), который недавно в каком-то виде попал в Firefox и Chrome. Отсюда разговоры о том, что крупные браузеры могут пересматривать отказ, который Chrome, как известно, вынес JPEG XL в 2023 году: новый декодер может защитить веб от повторения истории 2023 года с уязвимостью в WebP. Автор оговаривается: раньше он сам активно продвигал JPEG XL для любых задач и поддержал его включение в программу Interop 2024, лично знаком с двумя ключевыми авторами формата, Джоном Снейерсом (Jon Sneyers) и Юрки Алакуйялой (Jyrki Alakuijala), и высоко ценит их работу; цель текста, по его словам, не в том, чтобы дискредитировать авторов формата или примешать сюда политику вокруг свободного ПО, а в том, чтобы трезво и эмпирически оценить состояние сжатия изображений и веб-платформы в 2026 году. Часть вдохновения он называет впрямую, эссе «RISC-V: могли бы быть умнее» Дмитрия Гринберга (Dmitry Grinberg).

Первый довод, про сжатие без потерь. По объёму подавляющему большинству изображений в вебе достаточно качественного сжатия с потерями: обычному пользователю не нужно сжатие без потерь, ему хватает кодека, который не даёт заметных артефактов вроде тех, что JPEG оставляет на нефотографических изображениях. А это лишает JPEG XL его козыря: на практике его файлы без потерь лишь примерно на 11,9% (сам автор округляет до 12%) меньше файлов WebP без потерь, да ещё и на нереалистичном для веба наборе изображений, фотографиях по 157 мегапикселей, иллюстрациях по 10 мегапикселей и книгах по 27 мегапикселей. По мнению автора, тащить в браузеры целый новый кодек ради такой экономии на небольшом объёме контента, для которого экономия трафика и так не критична, не стоит; а поскольку для сжатия с потерями JPEG XL, как он утверждает, неконкурентоспособен, сжатие без потерь остаётся его единственным реальным преимуществом.

Второй довод, про само сжатие с потерями. Раньше одним из аргументов за JPEG XL было то, что его эталонный энкодер лучше учитывает восприятие человека, чем конкуренты; сейчас, пишет автор, конкурирующие энкодеры обгоняют libjxl и по скорости, и по качеству на бит. Эталонный энкодер AV1 получил отдельную перцептивную настройку по итогам контролируемых испытаний с участием людей, похожие профили есть у SVT-AV1, и по сильным метрикам восприятия CVVDP и SSIMULACRA2 картина для JPEG XL безрадостная, в том числе на фоне готовящегося энкодера Aperture компании Halide Compression (в графиках автора обозначен как aperture-alpha). На случай возражения «метрики не отражают реальное восприятие» автор приводит контрпример: у AVIF-энкодера libaom профиль, настроенный под восприятие человека (tune IQ), отличается от профиля, настроенного под саму метрику SSIMULACRA2, всего на пару баллов, то есть для этого кодека метрика и реальное восприятие расходятся не настолько, чтобы объяснить пропасть в результатах JPEG XL.

Дальше автор перечисляет инженерные причины отставания. JPEG XL делит изображение на блоки VarDCT размером от 2×2 до 256×256 пикселей и переводит их в частотное представление, но, в отличие от WebP, не умеет предсказывать содержимое блока по соседним пикселям (нет направленного предсказания), а без этого хуже сохраняются резкие границы; предложенная замена, сплайны, на порядок сложнее в реализации, работающего прототипа для этой задачи пока не существует, и автор не видит причин считать, что сплайны обгонят направленное предсказание. У формата нет и полноценного деблокинг-фильтра: два его внутренних инструмента, gaborish и EPF, лишь отчасти играют эту роль и вдвоём не заменяют его, поэтому JPEG XL по-прежнему страдает от «москитного шума». Перцептивное цветовое пространство XYB построено во многом на интуиции и не всегда даёт выигрыш в других форматах даже при использовании тех же метрик, а заявленную экономию от XYB на практике режет агрессивное квантование синего канала в libjxl, это портит сохранение цвета, и новым разработчикам энкодеров под JPEG XL приходится специально это компенсировать. С нефотографическими изображениями формат тоже справляется плохо: предложенная замена, «патчи», сложнее в использовании, чем Intra Block Copy (IntraBC) у AV1, требует дополнительных сущностей вроде слоёв и блендинга и обходится дороже по битам, блок IntraBC стоит примерно вектор движения плюс остаточные коэффициенты, тогда как конструкция JXL может стоить опорный кадр, заголовок кадра, обрезку, информацию о блендинге, запись в словаре патчей, координаты патча и остаточный кадр; в libjxl патчи вдобавок приходится включать вручную на уровнях кодирования ниже седьмого (параметр effort) из-за проблем с производительностью. Общий вывод автора: он не уверен, что даже хорошо оптимизированный энкодер JPEG XL сможет быстро превзойти лучшие энкодеры AVIF.

Третий довод, про декодирование. Спецификация JPEG XL исключительно гибкая: она поддерживает до 4096 каналов, произвольную глубину цвета, прогрессивную загрузку и перекодирование обычных JPEG без потерь, но вебу из этого богатства почти ничего не нужно, хватает 4 каналов (RGB/YUV плюс альфа-канал) и 10-битного цвета, которого достаточно для HDR. С прогрессивной загрузкой (когда сначала показывается грубое приближение картинки, а потом она дотягивается до полного качества) у JPEG XL проблема: по сравнению, которое автор приводит с сайта JPEG-XL info, AVIF показывает пригодную для просмотра картинку уже примерно на 2, 3% от размера полного файла, тогда как JPEG XL для этого нужно заметно больше данных, а сам AVIF-файл в этом примере ещё и меньше по размеру. При этом в браузерах прогрессивная загрузка AVIF реализована нативно, но пока только в Chrome, а у JPEG XL прогрессивная загрузка везде идёт через полифилл, даже в Safari, где сам формат JPEG XL поддерживается нативно, прогрессивное декодирование нативно не реализовано. Ещё один разрекламированный сценарий, перекодирование обычных JPEG в JPEG XL без потерь, для которого часто называют экономию в 20%; но эта экономия не бесплатна: перекодированные JPEG декодируются примерно на 33% дольше, и тезис «экономия достаётся бесплатно» автор прямо называет вводящим в заблуждение. На близких по размеру тестовых файлах одного и того же исходного изображения (JPEG, 2 478 828 байт, JPEG XL, 2 599 428 байт, AVIF, 2 649 949 байт, 10-битный, WebP, 2 693 794 байт) WebP, хотя и тяжелее JPEG XL больше чем на 90 КБ, декодируется больше чем в 10 раз быстрее декодера jxl-rs. А из-за гибкости формата можно собрать и откровенно вредоносный файл: автор сделал тестовую картинку весом 1918 байт, которая при декодировании вычисляет простые числа до 33 599, и на его собственном компьютере с чипом M5 Pro Rust-декодер расшифровывает её 17,43 секунды процессорного времени. Отсюда его предупреждение: как только этот декодер получит более широкое распространение в Chrome и Firefox, устроить простую перегрузку слабых устройств такими картинками станет тривиально просто, а против устройств Apple, где Safari уже поддерживает JPEG XL нативно, это работает уже сегодня, парой десятков таких файлов на одной странице можно ощутимо их затормозить.

В заключении автор формулирует общий принцип: веб-кодеки должны быть узкоспециализированными, эффективными и рассчитанными именно на нужды веба. По его оценке, так (пусть и слишком узко) был задуман WebP; у AVIF тоже есть недостатки, контейнер мог бы быть лучше, а спецификация AV1 могла бы точнее описывать ряд свойств изображений, например нормативный апсемплинг 4:2:0, но благодаря AV1 его появление в вебе было предрешено, а сам он опирается на зрелую экосистему. JPEG XL, по контрасту, по замыслу должен быть «всем для всех» и совсем не узкоспециализирован; а поскольку и без него было тяжело добиться повсеместной поддержки WebP, добавление ещё одного формата означает лишний слой проблем совместимости для всех, кто просто хочет скачать картинку из интернета и где-то её использовать. Итоговая формулировка автора: он не видит, чем JPEG XL подходит вебу хотя бы так же хорошо, как WebP.

Ключевые факты

  • Повод для разбора, декодер JPEG XL на Rust (jxl-rs), который недавно в каком-то виде попал в Firefox и Chrome; это оживило разговоры о пересмотре отказа, который Chrome вынес формату в 2023 году. Автор, инженер по сжатию, ранее работавший над AVIF вместе с Хулио Барбой и в прошлом сам поддерживавший JPEG XL, включая Interop 2024; в подписи поста указано его имя, Джанни Розато (Gianni Rosato).
  • Единственный реальный плюс JPEG XL, сжатие без потерь, но на практике оно даёт лишь около 11,9% (у автора округлено до 12%) выигрыша перед файлами WebP без потерь, да ещё на нереалистичном для веба наборе изображений (фото по 157 МП, иллюстрации по 10 МП, книги по 27 МП); в сжатии с потерями формат, по словам автора, неконкурентоспособен.
  • У JPEG XL, в отличие от WebP, нет направленного предсказания блоков и полноценного деблокинг-фильтра, а его цветовое пространство XYB страдает от агрессивного квантования синего канала в libjxl, автор не уверен, что оптимизированный энкодер JPEG XL быстро превзойдёт лучшие энкодеры AVIF.
  • На близких по размеру файлах одного изображения (JPEG 2 478 828 байт, JPEG XL 2 599 428 байт, AVIF 2 649 949 байт, WebP 2 693 794 байт) WebP декодируется больше чем в 10 раз быстрее декодера jxl-rs, хотя и тяжелее JPEG XL больше чем на 90 КБ; перекодирование обычного JPEG в JPEG XL экономит около 20% веса, но декодируется примерно на 33% дольше.
  • Гибкость формата позволяет собрать вредоносную картинку весом 1918 байт, которая вычисляет простые числа до 33 599 и декодируется 17,43 секунды на M5 Pro автора; он предупреждает, что парой десятков таких картинок уже сегодня можно замедлить устройства Apple, где Safari поддерживает JPEG XL нативно. Итог автора: он не видит, чем JPEG XL подходит вебу хотя бы так же хорошо, как WebP.

Почему это важно

Спор о месте JPEG XL в вебе разгорелся заново не на пустом месте: недавно в Firefox и Chrome в каком-то виде появился декодер формата на Rust (jxl-rs), и это дало повод думать, что крупные браузеры могут пересматривать отказ, который Chrome, как известно, вынес JPEG XL в 2023 году, тем более что новый декодер может уберечь веб от повторения уязвимости WebP 2023 года. Вопрос стоит не абстрактно: ради экономии в 12% на небольшом объёме контента новый кодек в браузеры тащить не стоит, а лишний формат добавляет проблемы совместимости тем, кто просто хочет скачать картинку и где-то её использовать. Автор, инженер по сжатию, работавший над AVIF и когда-то сам активно поддерживавший JPEG XL, эмпирически проверяет, оправдывает ли новый декодер такое решение, и приходит к выводу, что нет: ни выигрыш в сжатии без потерь, ни компромиссы по скорости и безопасности декодирования не тянут на аргумент в пользу ещё одного кодека рядом с уже устоявшимися JPEG, WebP и AVIF.

Кому это важно

В первую очередь, инженерам браузеров, которые решают, добавлять ли поддержку нового кодека, и инженерам по сжатию, которые проектируют и настраивают энкодеры для AVIF, WebP и самого JPEG XL: разбор даёт им конкретные технические доводы и цифры, а не только мнение. Дальше, веб-разработчикам и владельцам сайтов, которые выбирают формат для своих изображений: аргументы автора говорят в пользу AVIF и против ставки на JPEG XL. Наконец, разбор касается и рядовых пользователей, особенно на слабых и старых устройствах: именно на них ложится цена долгого и потенциально уязвимого декодирования, а пользователи Safari, где JPEG XL уже поддерживается нативно, конкретная аудитория, для которой риск из последнего раздела разбора актуален уже сегодня, а не гипотетически.

Как это применить

Из доводов автора для тех, кто сегодня выбирает формат изображений для веба, следует практический вывод: делать ставку на AVIF для сжатия с потерями, а JPEG XL не рассматривать как замену или дополнение, заявленная экономия на сжатии без потерь слишком мала и получена на нереалистичных для веба изображениях, а в сжатии с потерями формат и вовсе проигрывает AVIF. Про перекодирование обычных JPEG в JPEG XL без потерь (часто называемая экономия, 20%) автор отдельно уточняет: она не бесплатна, перекодированный файл декодируется примерно на 33% дольше, то есть выгоду в байтах нужно сопоставлять с ценой в процессорном времени на стороне читателя. Наконец, для тех, кто уже сегодня отдаёт JPEG XL пользователям Safari, где формат поддерживается нативно, автор показывает на собственном примере: из файла весом всего 1918 байт можно собрать картинку, декодирование которой займёт больше 17 секунд процессорного времени, и предупреждает, что с более широким распространением Rust-декодера в браузерах устраивать такую перегрузку слабых устройств станет тривиально просто.

Можно ли доверять

Это открыто личное мнение инженера, а не редакционная позиция какого-либо издания и не официальное решение разработчиков браузеров: сам текст заканчивается разделом, который называется «Заключение и мнение», и в спорных местах опирается на прямые оговорки, «может быть», «я не вижу», «я считаю». У автора есть профильная квалификация: он инженер по сжатию, работавший над энкодером AV1 и, по собственным словам, внёсший значимый вклад в развитие AVIF вместе с Хулио Барбой (Julio Barba), и одновременно есть потенциальный конфликт интересов: он сам строит собственный кодировщик изображений и сознательно решил не ориентировать его на JPEG XL, то есть выступает не сторонним наблюдателем, а участником рынка кодеков. В защиту своей непредвзятости он прямо оговаривает, что раньше сам был сторонником JPEG XL «для любых задач» и поддержал его для Interop 2024, лично знаком с двумя ключевыми авторами формата, Джоном Снейерсом (Jon Sneyers) и Юрки Алакуйялой (Jyrki Alakuijala), и подчёркивает, что не намерен ни дискредитировать их работу, ни делать политическое заявление о свободном ПО. Часть доводов подкреплена проверяемыми числами, байтами, секундами, процентами, и конкретными метриками (CVVDP, SSIMULACRA2), а на возможное возражение «метрики не отражают реальное восприятие» автор отвечает контрпримером: для AVIF-энкодера libaom профиль, настроенный под восприятие человека, и профиль, настроенный под саму метрику SSIMULACRA2, расходятся всего на пару баллов. Слабое место, источник один-единственный и независимой проверки его цифр и тестов нет.

Риски и подводные камни

Главный конкретный риск, декодирование как вектор перегрузки устройства: из-за гибкости формата автор собрал файл весом всего 1918 байт, который при расшифровке вычисляет простые числа до 33 599 и занимает 17,43 секунды процессорного времени на его M5 Pro; по его предупреждению, с более широким распространением Rust-декодера в Chrome и Firefox устраивать такую перегрузку слабых устройств станет тривиально просто, а против пользователей Safari, где JPEG XL уже поддерживается нативно, это работает уже сегодня. Второй риск, принимать разрекламированные цифры за чистую монету: 20% экономии от перекодирования JPEG в JPEG XL без потерь реальны, но покупаются ростом времени декодирования примерно на 33%, и расхожий тезис «эта экономия достаётся бесплатно» автор прямо называет вводящим в заблуждение. Третий риск, для самой веб-платформы: по мнению автора, ещё один гибкий, «всеядный» формат поверх JPEG, WebP и AVIF умножает и без того непростую историю с совместимостью, он напоминает, как тяжело давалось повсеместное распространение самого WebP, а для любого, кто просто хочет скачать картинку из интернета и где-то её использовать, лишний формат означает лишнюю головную боль. И риск для читателя самого этого разбора: текст, мнение одного инженера с профессиональным интересом в исходе спора (он сам разрабатывает конкурирующий кодировщик), а самый тревожный сценарий, перегрузка слабых устройств через декодер, пока предполагает, что уязвимый Rust-декодер получит по-настоящему широкое распространение в браузерах, чего на момент публикации ещё не произошло, сам автор говорит лишь, что декодер попал в Chrome и Firefox «в каком-то виде».

«Бенчмарков кодека не бывает, бывают только бенчмарки энкодера.»

— Джанни Розато (Gianni Rosato), инженер по сжатию, автор поста о JPEG XL