Аргументы в защиту формата в лонгриде под катом — к старту курса по Fullstack-разработке на Python.

Разработчики Chrome недавно анонсировали своё решение о прекращении поддержки формата JPEG XL, который ранее был «убран за флажок». Это решение объясняется так:

• Экспериментальные флаги и код не могут существовать неограниченный срок
• Сообщество в целом не проявило достаточного интереса, который оправдал бы продолжение экспериментов с JPEG XL.
• У нового формата изображений недостаточно дополнительных преимуществ по сравнению с существующими форматами, которые могли бы гарантировать его использование по умолчанию 
• Удаление флага и кода в M110 снижает бремя обслуживания и позволит сосредоточить усилия на улучшении существующих в Chrome форматов.

Первое утверждение звучит разумно, но многие ожидали, что вопрос разрешится активацией по умолчанию, а не полным удалением этого свойства. Это вовсе не оправдывает такие меры.

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

Основная часть стандарта JPEG XL (ISO/IEC 18181-1) опубликована в марте 2022 года, и с тех пор до момента написания этой статьи прошло около полугода. Часть, посвящённая описанию базовой реализации (ISO/IEC 18181-4), опубликована в августе 2022 года, приблизительно три месяца назад. На столь раннем этапе делать какие-либо выводы об «интересе сообщества» довольно преждевременно.

Однако если энтузиасты из Adobe, Intel & VESA, Krita, libvips, Cloudinary и Shopify поддержали Chromium в баг-трекере, то вывод о недостаточной заинтересованности сообщества кажется странным.

Так мы приходим к третьму и, возможно, самому интересному пункту: «Имеет недостаточно дополнительных преимуществ по сравнению с существующими форматами».

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

Относительно четвёртого пункта очевидно, что каждая новая строка кода создаёт «бремя обслуживания», но это достаточно общий аргумент, и он применим к любой новой функции. Но в данном конкретном случае это бремя, наверное, довольно скромное.

Фактическая реализация JPEG XL в Chrome основана на интеграции libjxl, которая сама по себе не поддерживается Chrome, хотя им приходится оценивать и, возможно, даже устранять — если разработчики libjxl не предоставят своевременный ответ — потенциальные ошибки безопасности, которые могут быть обнаружены в ней, как и в любой «сторонней» библиотеке, интегрированной в Chrome. Вся работа по интеграции уже проделана, включая работу, необходимую для предоставления альфа-прозрачности, анимации, управления цветом, включая расширенный динамический диапазон, и прогрессивное декодирование. Всё остальное «бремя», о котором идёт речь, по сути, сводится к периодическому повышению номера версии в сценарии сборки на случай, если появится новая версия libjxl, которая привнесёт полезные для Chrome улучшения. Команда Chrome не работала над улучшением libjxl в прошлом (и вряд ли будет это делать в будущем), поэтому неясно, как удаление флага связано с их способностью сосредоточить усилия на других вещах.

Повторное сжатие JPEG без потерь

Уникальной особенностью JPEG XL является возможность повторного сжатия существующих JPEG (которых существует очень много!) в файл JPEG XL, который в среднем на 20% меньше, без потерь. Фактически из файла JPEG XL можно восстановить точно такой же файл JPEG.

Такого свойства нет ни у одного другого формата изображений, то есть удовлетворительного решения для переноса изображений из JPEG у них просто нет: существующие файлы JPEG должны либо храниться в JPEG — с использованием нового форматов только для новых изображений, либо перекодироваться в новый формат. Однако перекодирование — операция довольно проблемная. В любом случае она добавляет потери и артефакты сжатия к файлу JPEG, который формировался уже с потерями. Перекодирование может быть даже контрпродуктивной: при выборе высокого качества можно свести к минимуму дополнительные потери, но итоговый файл может стать больше начального JPEG (то же произошло бы при конверсии из JPEG в PNG). Если же при перекодировке выбрано достаточно низкое качество, уменьшить размер файла удастся, но ценой внесения новых артефактов сжатия. Такое преобразование плохо поддаётся автоматизации с точки зрения описанных проблем.

Прогрессивное декодирование

Старый формат JPEG поддерживает прогрессивное декодирование: после передачи всего 15% данных изображения возможен его предварительный просмотр в низком качестве, которое улучшается по мере получения данных. Это свойство появилось уже во времена «колёсного» интернета по телефонной линии, но осталось полезным и в наши дни, когда возросли не только скорость соединения, но и разрешение изображений и вариативность сетевых условий. При быстром кабельном соединении или 5G прогрессивное декодирование лишь создаёт ощущение загрузки «шустрее», а вот на более слабом 3G-соединении, которым все мы нередко пользуемся вне дома, разница состоит уже в том, увидите ли вы что-то или не увидите ничего.

Отчасти благодаря популярности MozJPEG в качестве JPEG-кодера «progressive JPEG» стал развиваться быстрее других форматов онлайн-изображений в минувшее десятилетие, если рассматривать его отдельно от базового последовательного режима JPEG.

Ни один из форматов изображений, возникших из видеоформатов (WebP, HEIC, AVIF) не поддерживает прогрессивное декодирование на уровне кодека, так как это свойство характерно именно для неподвижных изображений. В видеоформатах предварительный просмотр одного кадра малополезен — если не хватает пропускной способности для буферизации видеоданных на много кадров, воспроизвести видео бесполезно даже пытаться. Видеоформаты имеют собственные решения для работы с различными сетевыми условиями (например, HLS).

Чтобы преодолеть этот недостаток «новых» форматов изображений (WebP и AVIF), web-разработчики прибегают к различным уловкам для создания прогрессивной загрузки, например, используют «заглушки» низкого качества.

Для сравнения: JPEG XL не только поддерживает прогрессивное декодирование, но и выходит за рамки возможностей старого JPEG, например, предоставляет прогрессирование по значимости (saliency-based progression). Это довольно интересно и полезно как для разработчика (отпадает необходимость в сложных «ритуалах с заглушками»), так и для конечного пользователя.

Параметры сжатия без потерь

JPEG XL позволяет сжимать изображения без потерь лучше, чем это умеют существующие форматы (в частности PNG). Причём лучше по всем параметрам: он быстрее кодируется, создаёт меньшие по размеру файлы и даёт больше возможностей (например, CMYK, слои и 32-битные образцы с плавающей точкой). Поскольку это в основном относится к рабочим процессам авторов, а не к случаю передачи через сеть, я не буду останавливаться на этой теме слишком подробно, но это, конечно, довольно важное преимущество JPEG XL как формата в целом.

Но и для передачи через сеть сжатие без потерь во многом очень желательно. Для некоторых типов изображений (например, скриншотов или пиксельной графики) сжатие без потерь может, как это ни парадоксально, уменьшать размер файла сильнее, чем сжатие с потерями. PNG и WebP без потерь действительно имеют своё применение в сети — но не для фотографий, а для некоторых видов графики.

Параметры сжатия с потерями

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

Сложно ответить, насколько хорошо изображение сожмётся с потерями. В отличие от сжатия без потерь (когда можно просто посмотреть на размер файла), сжатие с потерями — это всегда компромисс между сжатием и качеством. С появлением последних, более сложных и многогранных кодеков к этому компромиссу следует добавить скорость кодирования — затрачивая больше времени на кодирование, можно получить лучший результат, но то, какое время кодирования будет приемлемым, зависит от конкретного применения: для изображения главного героя на целевой странице, которая получит миллионы просмотров, можно потратить несколько минут на кодирование, а вот для изображения в социальных сетях требования к задержке и затратам процессора будут гораздо более жёсткими.

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

Есть два подхода к оценке качества изображения: субъективный эксперимент и объективные метрики. Субъективные эксперименты, при условии их правильного проведения, остаются единственным надёжным способом оценки качества изображения, но они требуют участия людей для оценки или сравнения изображений, поэтому это не самый удобный и дешёвый способ оценки работы кодеров изображений. По этой причине на практике часто используют объективные метрики: это алгоритмы, которые на входе получают исходное несжатое изображение и изображение со сжатием с потерями, а затем подсчитывают балл, который предположительно указывает на качество изображения.

«Объективные» метрики всегда следует воспринимать критически, ведь их связь с человеческим мнением не идеальна и даже может быть довольно низкой для ряда старых метрик. Метрика со временем становится не столь полезной, поскольку, когда она используется широко, кодеры стремятся «обмануть» её, а не повышать качество изображения. В качестве примера того, как метрики могут ошибаться, я сделал галерею изображений «Зал позора», показывающую три изображения в ряд (сжатое A, оригинал, сжатое B), где многие метрики (все, кроме одной, которую я недавно разработал) говорят, что изображение B справа обладает качеством выше, чем изображение A слева, хотя люди, оценивающие качество изображений, вероятнее всего, скажут обратное.

В Cloudinary мы недавно провели масштабный эксперимент по субъективной оценке изображений, в котором приняли участие более 40000 человек. Было проведено 1,4 миллиона оценок. В настоящее время мы всё ещё готовим публикацию о подробных результатах, но в качестве общего резюме: в диапазоне качества, актуальном для интернета, JPEG XL позволяет получить на 10–15% лучшее сжатие, чем AVIF, при настройках скорости кодера, при том, что JPEG XL кодирует примерно в три раза быстрее, чем AVIF. Конечно, выигрыш в сжатии выше при сравнении с WebP (около 20–25%) и MozJPEG (около 30–35% — обратите внимание, что сам MozJPEG имеет на 10–15% лучшее сжатие в диапазоне качества для сети, чем типичные кодеры JPEG, такие как libjpeg-turbo или кодеры, используемые камерами).

На следующей диаграмме с обобщенными результатами по 250 изображениям показан рейтинг 10-го худшего перцентиля для каждой настройки кодирования — оценивать по наихудшим показателям, пожалуй, логичнее, чем по усреднённым.

Если рассматривать отдельные типы изображений, например фотопортреты, разрыв между JPEG XL и существующими форматами может быть ещё больше:

На уровне отдельных изображений есть случаи, когда разница между JPEG XL и следующим по качеству форматом достигает 30% и даже больше:

При оценке качества с помощью объективных метрик результат в значительной степени зависит от используемой метрики, настроек кодера и способа обобщения данных по нескольким изображениям. В настоящее время лучшими доступными метриками для оценки восприятия — в соответствии с результатами их статистической корреляции с субъективными результатами — являются Butteraugli, DSSIM и SSIMULACRA 2. Они в основном согласуются друг с другом и с субъективными результатами: JPEG XL превосходит существующие форматы достаточно явно, с разницей в 10–15%. Кодерам AVIF требуется приблизительно в 100 раз больше времени для достижения сжатия, сопоставимого с JPEG XL; при более практичной скорости кодирования (скажем, в 2–3 раза медленнее, чем JPEG XL при усилиях по умолчанию) AVIF обеспечивает сжатие на 10–15% хуже, чем JPEG XL; при той же скорости кодирования AVIF не лучше или даже несколько хуже MozJPEG, в то время как JPEG XL лучше на 20–40%.

Можно ли назвать это «достаточными дополнительными преимуществами»? Здесь всё очень субъективно. На сколько процентов нужно улучшить сжатие, чтобы это оправдывало добавление нового формата в браузеры? С какого момента экономия на пропускной способности (а также хранении и стоимости процессора) начинает оправдывать увеличение двоичного файла, риска ошибок, а также бремени безопасности и обслуживания, вносимого дополнительным кодом? Это не тривиальное решение.

В любом случае, если рассматривать конкретно улучшение сжатия: с доступными в настоящее время кодерами — в случае JPEG XL и AVIF кодеры продолжают совершенствоваться, поэтому ситуация может измениться — и при разумных и более или менее сравнимых скоростях кодирования общее улучшение при переходе от (Moz)JPEG к WebP приблизительно такое же, как улучшение при переходе от WebP к AVIF, а улучшение при переходе от AVIF к JPEG XL больше этого и приблизительно сравнимо с улучшением при переходе от JPEG к AVIF.

Развёртываемый кодер

Эталонная реализация JPEG XL, libjxl, содержит кодер, который можно использовать как есть в производственных средах: он относительно быстр и даёт стабильное графическое качество при заданной точности. Понять и измерить скорость кодирования относительно просто, а вот «стабильность» (consistency) требует разъяснений.

Кодеры изображений (и видео) обычно можно настроить с помощью параметра «качество» (quality), например, по шкале от 0 до 100, который управляет точностью кодирования. Тем не менее одна из настроек качества, применяемая к разным изображениям, не обязательно приведёт к одинаковому качеству изображения. Хотя алгоритм кодека может выполнять аналогичные действия, реально воспринимаемое качество изображения зависит от характера конкретного изображения. Это явление — результат относительной нестабильности кодеков — является причиной, по которой мы ввели метод автоматизированного выбора качества в Cloudinary ("q_auto") ещё в 2016 году.

Один из способов оценить стабильность кодера — сравнить средний показатель визуального результата при заданных настройках качества с наихудшим результатом — скажем, с оценкой в 1 или 10 перцентиле. В нашем теоретическом эксперименте мы оценили мнения о множестве разных изображений (225 фотографий и 25 образцов графики). Таким образом, можно посмотреть на разброс между наихудшим случаем и среднестатистической оценкой:

Например, чтобы достичь средней оценки качества изображения 60 (умеренно высокое качество/medium-high quality) в 99% случаев, при использовании JPEG XL необходимо использовать настройки, которые нацелены на значение чуть менее 70 (высокое качество/high quality), в то время как при использовании существующих форматов (JPEG, WebP, AVIF) необходимо нацелиться на значение 72 или более.

На практике это значит, что фактический результат сжатия JPEG XL выше, чем предполагаемое при рассмотрении средних показателей. Это объясняется тем, что настройки кодера обычно выбираются с таким расчётом, чтобы 99% (или даже 99,9%), а не 50% изображений имели приемлемое визуальное качество. Лучшее качество кодера подразумевает более прогнозируемые, надёжные результаты — поэтому нет причин «целиться слишком высоко», чтобы учесть вариации, которые зависят от характера изображения.

Работа со всей последовательностью выполняемых действий

И последнее значимое преимущество JPEG XL — широкая сфера применения: формат отлично подходит для доставки по сети, но он разработан не только для этого. JPEG XL можно использовать как исходный формат захвата изображений, где он может играть роль, аналогичную современным raw-форматам для камер. Для этого у него есть всё: высокое разрешение, расширенный динамический диапазон, сжатие без потерь или с минимальными потерями. JPEG XL также мог бы сталь форматом для создания изображений благодаря поддержке слоёв с разными именами, масок выделения и множества альфа-каналов. Благодаря поддержке CMYK и специальных цветов формат во многих случаях можно использовать для печати. Его можно также использовать для медицинских и научных целей благодаря поддержке компрессии без потерь и с высоким разрешением и мультиспектрального отображения. И так далее. Таким образом, это универсальный формат, подходящий для самых разных задач по работе с цифровыми изображениями.

Разумеется, передача изображений через сеть всегда была основным вариантом применения при разработке JPEG XL. Но это был не единственный вариант. Мы не предполагали, что он будет использоваться только в сети — в отличие, например, от WebP, который, как видно из названия, разрабатывался исключительно для сети. WebP разрабатывался как специальный формат изображений специально для интернета, поэтому он имеет разные ограничения, например в отношении качества (принудительная субдискретизация цветности в ТВ-диапазоне 4:2:0, что не позволяет осуществлять сжатие с потерями с высокой точностью), размера изображения (не более 16383 пикселей в любом измерении, что подходит для интернета, но недостаточно для многих других вариантов применения), битовой глубины (только 8 бит) и цветового пространства (только RGB). Все эти ограничения разумны для сети, но не для формата изображений общего назначения.

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

Заключение

В прошлом появилось много «новых» форматов изображений. Одни характеристики в них были улучшены за счёт других. Например, PNG намного превосходит GIF, но не поддерживает анимацию. WebP показывает себя лучше JPEG при сжатии в диапазоне низкой и средней точности (low to medium fidelity), но достигается это ценой потери прогрессивного декодирования и кодирования 4:4:4 с высокой точностью (high fidelity). AVIF ещё больше увеличил качество сжатия, но ценой утраты прогрессивного декодирования и развёртываемых кодеров.

Мы рассмотрели 6 аспектов, в которых JPEG XL показывает себя значительно лучше других форматов:

• Повторное сжатие JPEG без потерь.
• Прогрессивное декодирование.
• Параметры сжатия без потерь.
• Параметры сжатия с потерями.
• Развёртываемый кодер.
• Работа со всей последовательностью выполняемых действий.

Насколько эти преимущества «достаточны», пусть каждый рассудит сам. На мой взгляд, уже одного из них было бы достаточно. Но самое главное — JPEG XL вносит эти дополнительные преимущества не в ущерб другим характеристикам, по крайней мере не в ущерб основным техническим преимуществам. Разумеется, с точки зрения совместимости и признания каждый формат должен пройти долгий путь, чтобы догнать JPEG и PNG, существующие дольше. Нам же остаётся лишь надеяться, что разработчики Chrome пересмотрят своё решение и помогут JPEG XL догнать старые форматы в плане программной поддержки, чтобы мы все могли снова порадоваться преимуществам этого формата.

Научим вас аккуратно работать с данными, чтобы вы прокачали карьеру и стали востребованным IT-специалистом. Если вы не найдёте работу, мы просто вернём деньги (возврат — акция в рамках «Чёрной пятницы»).

• Профессия Fullstack-разработчик на Python (16 месяцев)
• Профессия Data Scientist (24 месяца)