Почему это актуально?
JPEG XL — технически впечатляющий кодек, определённо превосходящий JPEG, более универсальный, чем WebP, и хорошо оснащённый для применения за пределами веба. Однако в 2023 году он был отклонён Chrome. Поскольку это случилось с лицензионно-свободным, гибким и эффективным кодеком от комитета JPEG, привлекавшим внимание крупных компаний, решение вызвало негативную реакцию.
Недавно JPEG XL декодер на Rust сделал свой путь в Firefox и Chrome. Возможно, крупные игроки веб-платформы пересматривают позицию на JPEG XL, так как новый декодер может защитить веб от повторения уязвимости WebP 2023 года. Достаточно ли этого, чтобы оправдать JPEG XL для веба?
Исторически автор был сторонником JPEG XL для всех применений. Он поддержал JPEG XL для Interop 2024 и неоднократно взаимодействовал с Джоном Снейерсом и Йиркки Алакуйялой — двумя из основных авторов формата. Их публичное поведение, уравновешенность, техническое мастерство и увлечённость работой постоянно вызывают уважение.
Эта статья не стремится дискредитировать авторов формата или их работу, ни претендовать на какую-либо политическую позицию относительно символики кодека в свободном ПО. Дух материала образователен; целью является эмпирический взгляд на современное состояние сжатия изображений и веб-платформы в 2026 году. Некоторое вдохновение почерпнуто из статьи RISC-V: They Should Have Known Better Дмитрия Гринберга.
Веб-платформа
Профессиональный интерес к сжатию изображений пришёл из видеокодирования. Во время работы над AV1-энкодером с Хулио Барба удалось добиться значительных улучшений в AVIF, и многому научиться в этом процессе. При начале разработки собственного энкодера пришлось тщательно обдумать, какие форматы имеют наивысший потенциал, могут быть эффективно оптимизированы и обладают наиболее реальной и потенциальной полезностью. Решение было не работать с JPEG XL.
По объёму использование очень немногих случаев на веб не решается универсальным сжатием с потерями. Среднестатистический веб-потребитель не нуждается в бесстратном сжатии; ему нужен кодек с потерями, достаточно универсальный, чтобы избежать ужасных артефактов (например, JPEG на нефотографическом контенте). Это исключает преимущество JPEG XL в бесстратном сжатии, которое на практике составляет лишь примерно 11,9% экономии по сравнению с WebP без потерь — и то на нереалистичном наборе данных для веба (157 МП фото, 10 МП иллюстрации и 27 МП книги). Неоправданно было бы добавлять новый кодек изображений в браузеры ради экономии 12% на малом объёме контента с потребностями, изначально менее чувствительными к ограничениям пропускной способности. Это уточнение важно, так как JPEG XL не конкурентен в режиме с потерями, поэтому бесстратное сжатие было бы его единственным реальным преимуществом.
Эффективность сжатия с потерями
Один из первоначальных аргументов за JPEG XL заключался в том, что его референсный энкодер был более перцептивно оптимизирован чем конкурирующие энкодеры. Сегодня по скорости и точности на бит другие энкодеры сильнее.
AV1 референсный энкодер получил специализированную перцептивную настройку на основе контролируемых субъективных человеческих испытаний для усиления эффективности при сохранении режима настройки, оптимизированного для перцептивных метрик. SVT-AV1 имеет похожие режимы настройки. Нет убедительного аргумента, что современные энкодеры не настроены на человеческий глаз.
Метрики несовершенны, но рисуют мрачную картину для JPEG XL:
aperture-alpha — предстоящий энкодер Halide Compression с кодовым именем Aperture. Он включён, чтобы показать, насколько много работы libjxl нужно проделать, чтобы конкурировать на границе возможного.
Некоторый анализ утверждает, что JPEG XL работает хуже метрик относительно своей перцептивной силы, но недостаточно доказательств, что это настолько значительно, чтобы графики, которыми поделились, были полностью развёрнуты в противоположном направлении. CVVDP и SSIMULACRA2 — очень сильные перцептивные метрики, и они точно告诉 нас что-то когда различия настолько велики. Для AVIF перцептивно-оптимизированная настройка libaom (tune IQ) всего на несколько пунктов ниже, чем настройка с оптимизацией под перцептивные метрики (tune SSIMULACRA2). К тому же, референсный энкодер JPEG XL исторически страдал от перцептивных проблем, остающихся в основном нерешёнными.
Не существует такой вещи, как эталонное тестирование кодека — только тестирование энкодера; в теории потолок JPEG XL как формата выше, чем показывает libjxl. Но насколько трудно было бы закрыть разрыв? Как инженер сжатия, убеждён, что формат находится в невыгодном положении. Вот некоторые причины:
- JPEG XL не имеет режимов прямой предсказания. Сжатые изображения разбиты на блоки VarDCT (от 2x2 до 256x256) и преобразованы в частотные представления их пикселей. Другие блочные кодеки изображений, такие как WebP, позволяют предсказывать пиксели блока, используя окружающие данные, вычитать это предсказание из действительных пикселей, а затем выполнить частотное преобразование. Режимы прямой предсказания могут привести к размытию, если энкодер не перцептивно оптимизирован, но мощные конвейеры выбора режима могут подобрать нужный режим и сэкономить много бит. Например, сохранение краёв сильнее в кодеках с направленным предсказанием, тогда как JXL слабее здесь.
- Предложенное решение для закрытия разрыва в сохранении краёв — сплайны, которые намного сложнее использовать. Сложная часть — на стороне энкодера: нужен эффективный алгоритм, чтобы понять, какие пиксели вообще можно представить как сплайн, затем пропустить каждого кандидата через RDO для решения, стоит ли это кодировать. Нет существующего PoC для использования сплайнов для сохранения краёв, и нет причин верить, что они были бы лучше чем направленное предсказание в любом случае.
- JPEG XL не имеет фильтра деблокирования в цикле (DLF), или вообще никакого фильтра деблокирования. Имеются два встроенных инструмента, которые иногда предлагаются как частичные эквиваленты: gaborish, самое близкое, что JXL имеет к AV1-фильтру восстановления цикла, и EPF (фильтр сохранения краёв), чей ближайший аналог — AV1-CDEF. Ни один из них не является фильтром деблокирования, и оба вместе не могут полностью заменить надлежащий DLF. DLF может сгладить изображения, но если энкодер умный, это поможет только избежать артефактов мошкары, которые JPEG XL всё ещё страдает.
- Перцептивное цветовое пространство JPEG XL "XYB" основано на большом количестве интуиции и не всегда приводит к выигрышам в других форматах (например, в JPEG) даже когда метрики вроде SSIMULACRA2 работают в точно таком же цветовом пространстве. Заявленная экономия эффективности от использования XYB также не такая большая, как первоначально рекламировалось, потому что libjxl в настоящее время полагается на агрессивное квантование канала B. Это привело к субоптимальному сохранению цвета, которое новые разработчики JXL-энкодера должны явно исправить.
- JXL плохо работает с нефотографическими изображениями. Предложенное решение — использование патчей, но они более сложны в использовании, чем AV1-Intra Block Copy.
- Чтобы получить схожий диапазон выразительности с IntraBC, энкодер должен иметь дело с дополнительными концепциями, такими как слои и смешивание, которые не дёшевы для представления на уровне битового потока.
- Остаточное кодирование неудобно. С AV1 вы предсказываете блок, вычитаете предсказание из источника, и коэффициенты преобразования естественно представляют остаток. При конструкции JXL вы декодируете остаточный кадр, а затем смешиваете ссылочный патч, поэтому вам нужен актуальный кадр или слой, чьи декодированные пиксели представляют остаток. Вероятно, это будет модульный кадр, что интересно, потому что Modular не ограничен обычными беззнаковыми значениями изображения, как итоговое отрендеренное изображение.
- Блок IntraBC по сути стоит вектора движения плюс остаточные коэффициенты, тогда как конструкция JXL потенциально стоит ссылочного кадра, заголовка кадра, кропа, информации о смешивании, записи словаря патчей, координат патча и остаточного кадра. Эта служебная нагрузка может подавить сбережения, если только повторяемый регион не довольно большой или переиспользуется много раз.
- Патчи должны быть явно включены в libjxl ниже effort 7, так как в настоящее время они имеют проблемы с производительностью.
Для нефотографических изображений аргумент, что "они должны быть векторными", не выдерживает критики, потому что много изображений могли бы быть векторными, но их нет, и они не могут быть векторизованы идеально. "Мир должен быть другим" — не оправданная защита от оптимизации для того способа, которым мир на самом деле устроен.
Заманчиво думать, что эти пункты означают потолок выше, чем позволяет libjxl, и что можно сделать лучше, но нет уверенности, что он может быстро затмить хорошо оптимизированные AVIF-энкодеры, учитывая его менее интуитивные (и потенциально более слабые) инструменты кодирования.
Время декодирования
JPEG XL имеет впечатляюще гибкую спецификацию. В дополнение к инструментам кодирования, поддерживает до 4096 каналов, произвольную глубину цвета, прогрессивное декодирование, повторное сжатие JPEG и многое другое. Многие из этих функций не являются широко полезными на веб; нужны 4 канала (RGB/YUV + альфа), разумная глубина цвета для поддержки HDR (10-бит достаточно), и возможность загружаться быстро.
Прогрессивный рендеринг (который AVIF поддерживает) декодирует низкокачественное отображение до прибытия полного изображения. AVIF долго не поддерживал прогрессивный рендеринг, и в то время считается, что это было глубоко переоценено. Теперь, когда libavif это реализовал (это всегда было возможно), разговор похоже окончен. Думается, это потому, что результаты говорят сами за себя:
Это с сайта JPEG-XL info, где AVIF показывает используемое изображение намного раньше чем JXL, всего при ~2-3% размера полного изображения. В сочетании с фактом, что AVIF в целом меньше, это лёгкая победа. Сделан скриншот страницы, потому что прогрессивное декодирование AVIF работает только в Chrome, так как использует встроенный декодер браузера; JPEG XL использует полифилл потому что даже в Safari, где он поддерживается, прогрессивное декодирование отсутствует.
Повторное сжатие JPEG — это возможность бесстратного повторного кодирования JPEG в JXL изображения при экономии бит; часто упоминаемое число — 20% экономии. Однако пользователь платит за это во времени декодирования, так как повторно сжатые JPEG требуют ~33% больше времени для декодирования. Современные потребительские устройства мощные, но аргумент, что сбережения приходят "бесплатно" — вводящий в заблуждение.
По этой теме, время декодирования не конкурентно с лучшими:
В общественном дискурсе AVIF считается медленным для декодирования; что это делает с JXL? Это также 10-бит AVIF, и все изображения были кодирования с подогнанным размером одного источника. JPEG был 2 478 828 байт, JPEG XL был 2 599 428, AVIF 2 649 949, и WebP 2 693 794. WebP на 90kb больше и всё ещё управляется декодированием более чем в 10 раз быстрее чем jxl-rs с wpd.
Из-за выразительности кодека, возможно создавать изображения, которые требуют безумно долго для декодирования. Возьмём этот пример (открывать с осторожностью), который вычисляет простые числа вплоть до 33 599 и требует 17.43s пользовательского времени для декодирования на M5 Pro с Rust-декодером. Дополнительно помните, что это декодер, который попадает в Chrome, Firefox и т.д – изображение с простыми числами всего 1 918 байт, поэтому вот-вот станет тривиально легко провести JXL-бомбардировку низкопроизводительных устройств. Можно уже отправить пару десятков этих на веб-страницу и замедлить Apple устройства, так как они нативно поддерживают JPEG XL в Safari.
Заключение и мнение
Считается, что веб-кодеки должны быть целенаправленными, эффективными и узко ориентированы на потребности веба. Думается, WebP был немного слишком узко ориентирован, но идея была; контейнер AVIF мог бы быть лучше, и спецификация AV1 могла бы быть немного более конкретна в обработке некоторых свойств изображений (например, нормативное повышение дискретизации 4:2:0), но AVIF был всегда гарантированным дополнением к веб благодаря AV1 и выигрывает от очень зрелой экосистемы.
Нужен ли нам тогда JPEG XL? Он вообще не узко ориентирован; он предназначен для всего для всех, по замыслу. Думается, много других применений нуждаются в этом, но веб нуждается в экономии пропускной способности, быстром декодировании и предотвращении самоподстрелов; не видно, как JPEG XL даже лучше подходит, чем WebP. Не говоря уже о дополнительных проблемах совместимости, которые теперь существуют для того, кто просто пытается загрузить изображение из интернета и использовать его где-то — достаточно сложно добиться широкого принятия WebP, и не думается, что стоит удваивать боль, имея лезть на ту же гору для AVIF и JPEG XL. Особенно когда JPEG XL не видится добавляющим ничего на веб-платформу.
3½ года назад говорилось:
Желается веб, где и AVIF, и JPEG XL могут существовать, и разработчики решают, какой формат использовать по его достоинствам. [...] По мнению автора, JPEG XL и AVIF имеют принципиально различные сильные стороны, которые подходят им для разных применений.
В то время JPEG XL был намного более сильным претендентом на сжатие изображений средне-высокой точности с потерями. AVIF сейчас доминирует по всему диапазону точности, поэтому единственное реальное преимущество JPEG XL исчезло.
JPEG XL пришёл от Cloudinary и Google, но кажется, кодек обсуждается способом, который это не делает ясным. Также стоит упомянуть, что и JPEG XL, и AVIF лицензионно-свободны. Из-за политики вокруг доминирования Google на рынке браузеров, AV1 из Google и спорам вокруг WebP Google, это мнение, что большинство аргументов за JPEG XL исходит из желания веба с большим выбором разработчика в противоположность желанию технологически превосходящего кодека изображений. Это понимается, и думается, JPEG XL всё ещё может процветать вне веба в местах, где AVIF никогда не мог. В той же статье:
Мой текущий оптимистичный надеюсь, что JXL взлетит вне веба среди профессионалов, работающих с инструментами вроде Adobe suite или альтернативами, и производители камер, OEM смартфонов и другие обратят внимание и начнут серьезнее думать о JXL.
JPEG XL не бесполезен; это действительно убедительная технология для применений за пределами веба. Просто не убеждённость в том, что нам его нужно в браузерах уже в ближайшее время.