avif

Есть такой относительно новый хороший формат графики для веба — AVIF (появился всего семь лет назад). Формат правда хороший, но есть недостаток — очень уж алгоритмически сложный. Из-за этого кодировать в него получается довольно медленно. Декодировать, кстати, тоже не сахар — на медленных компьютера сотня картинок может сильно нагружать процессор.

И декодеры и кодеры стараются программно ускорить, но всё равно получается довольно медленно. Я давно предсказывал появление аппаратных ускорителей, но пропустил момент, когда они появились. Мой «Макбук» на чипе «М3 Макс», значит у меня есть по меньшей мере декодер.

На картинке он обозначен как «AV1 decode», AV1 — это название кодека, которым сжата графика в формате AVIF.

У «Интела» аппаратный декодер тоже есть, думаю у других производителей тоже, я не смотрел. А это, по сути, значит, что формат уже победил всех конкурентов и постепенно начнёт выходить на первые позиции. Разве что появится что-то легковесное, но при этом обладающее лучшим коэффициентом сжатия, но в это верится с трудом.

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

Поступают иначе — в браузер и сервер вносят реализацию сжатия и распаковки и те же самые текстовые данные начинают передаваться чуточку быстрее.

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

Например, в PNG это DEFLATE, в GIF — LZW.

В принципе, никто не мешает наложить встроенный в браузер алгоритм сжатия на формат графики, — протокол передачи это позволяет. Я уже экспериментировал подобным образом с форматом GIF, так как оказалось, что этот формат позволяет выключить встроенное сжатие. То есть я как бы выкидывал используемый в GIF древний LZW и заменял его на более современный DEFLATE, реализованный в браузере.

Тогда этот эксперимент ничего не дал, но недавно я его повторил. Только вместо DEFLATE использовал brotli, ещё более свежий алгоритм. GIF, в этом случае, стал меньше PNG. Это, кстати, не всегда так происходит, но в этом случае повезло. Я попробовал ещё и zstd, он ещё новее, но он жмёт хуже brotli, его достоинство в скорости.

Любопытно ещё, что когда я сжал через brotli картинку, сконвертированную в формат AVIF, она стала ещё меньше. Я такого не ожидал, мне казалось, что современные бинарные форматы делаются максимально экономно.

В общем, схема со сжатием графики в браузере, как будто бы, имеет право на существование.

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

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

Пока примотал реализацию на соплях, как концепт. Результаты, кстати, хорошие, можно посмотреть на скриншоте разницу:

Разница в размере файлов в двух форматах — JPEG и AVIF

Но пока мотал, наткнулся на прекрасное. 🤦🏻‍♂️

В ПХП есть несколько модулей для работы с картинками, но самых распространённых два — GD и Imagick. Я начал с GD, так как на виртуалке он собран с поддержкой AVIF (а Imagick — нет), по крайней мере сам модуль так утверждает:

var_dump(gd_info()['AVIF Support']); // true
var_dump(imagetypes() & IMG_AVIF); // 256

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

Но при попытке сконвертировать картинку из JPEG в AVIF создавался файл нулевой длины, хотя функция возвращала true:

var_dump(imageavif(imagecreatefromjpeg('0.jpg'), '0.jpg.avif')); // true

GD это очень старый модуль, он родился, когда в PHP главенствовал процедурный модуль, поэтому его суть — функции; в PHP, если мы вызываем функции и что-то идёт не так, мы можем узнать что именно при помощи функции error_get_last. Помогла она и на этот раз:

array(4) {
  ["type"]=>
  int(2)
  ["message"]=>
  string(50) "imageavif(): AVIF image support has been disabled
"
  ["file"]=>
  string(17) "Command line code"
  ["line"]=>
  int(1)
}

Я погуглил ошибку, но не смог быстро разобраться что с ней сделать, поэтому переключился на Imagick. Там всё завелось без особых проблем — заменил шестую версию на седьмую и поставил недостающие пакеты:

yum shell
> remove php-pecl-imagick-im6
> install php-pecl-imagick-im7
> install ImageMagick7-heic
> install libheif
> run

В этом модуле, кстати, проверка на поддержку AVIF делается вот таким немного неочевидным способом:

$isAVIFSupported = Imagick::queryformats("AVIF") !== [];

Как говорится, если нельзя, но очень хочется, то можно. «Эгея», как я писал не понимает формат AVIF, но мне его удалось всё-таки в неё вставить, причём даже малой кровью.

Изображение ниже я взял из своей заметки про Красную площадь в коронавирусный период. В оригинале оно весит 1,1 мегабайт в формате JPEG, в этой заметке используется сконвертированное изображение размером в 179 килобайт. Почувствуйте разницу.

Добавлено позднее: в небе, кстати, я отчётливо вижу артефакты сжатия, надо играть с параметром качества, прежде чем использовать. Но в остальном картинка как будто бы не попортилась.

Конечно, если ваш браузер не поддерживает AVIF, это будет не та разница, на которую я надеялся. Напишите мне, кстати, если картинка у вас не отображается — я хотел бы узнать что у вас за браузер и насколько он современный.

Моя фотография храма Василия Блаженного (1555—1561 гг.) из заметки «Красная площадь без людей»

Итак, «Эгея» не поддерживает AVIF, но я её в «Эгею» вставил. Как же мне это удалось?

Дело в том, что «Эгея» поддерживает формат SVG, а SVG поддерживает внутри себя растровую графику, в том числе вставленную через протокол «data». Протокол «data» — это картинка, закодированная в текстовую строку, вида data:mime/type;encoding,encoded_data.

Вообще, SVG поддерживает и внешние ресурсы (то есть в теории способен подгрузить картинку снаружи), но при вставке через тег img (как в «Эгее») в нём это запрещено по соображениям безопасности.

Поэтому мысль такая — переводим графику в AVIF, кодируем в base64 («data» так умеет, а иначе бинарные данные не вставить), из-за кодирования они увеличатся на 33%, но даже при этом овчинка выделки стоит, а потом получившееся запихиваем в SVG.

Для конвертации я написал вот такой небольшой bash-скрипт (для работы требуется пакет ImageMagick):

#!/bin/bash

if [ -z "$1" ]; then
    echo "Usage: $0 <picturename>"
    exit 1
fi

NAME="$1"
NEWNAME="${NAME%.*}.svg"
WH=( $(identify -ping -format '%w %h' "$NAME") )

if [[ "$NAME" == *@2x* ]]; then
    WH=( $(( ${WH[0]} / 2 )) $(( ${WH[1]} / 2 )) )
fi

cat<<XML > "$NEWNAME"
<?xml version="1.0" encoding="utf-8"?>
<svg version="1.1" xmlns="http://www.w3.org/2000/svg"
viewBox="0 0 ${WH[*]}" width="${WH[0]}" height="${WH[1]}">
<image width="${WH[0]}" height="${WH[1]}"
href="data:image/avif;base64,$(convert "$NAME" "avif:-" | base64)"/>
</svg>
XML

echo "$NAME" to "$NEWNAME" was converted.

Последовательность теперь у меня такая — готовлю графику в более привычном формате, запускаю скрипт, получаю файл SVG, вставляю его драг-н-дропом в редактор «Эгеи». Не знаю насколько у меня такой способ приживётся, буду пока считать эту запись тестовой.

Дополнение: уже сообщают, что в 15-й и ниже Айос ничего не видно.

Есть такой современный формат графики — AVIF, который родился из видеоформата AV1. Интересен он тем, что даёт иногда существенную выгоду от использования — в моём непоказательном эксперименте на первой попавшейся картинке он уделал формат JPEG на порядок).

Вместе с тем он неплохо поддерживается современными браузерами — 79% по данным сайта CanIUse. Это ещё без учёта полифилов.

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

Уровень поддержки браузерами формата графики AVIF

У меня возникла хорошая, на первый взгляд, идея чуть упростить себе жизнь через модуль mod_rewrite веб-сервера «Апач» («Эгея» его требует, у меня на хостинге он тоже используется) при помощи примерно такого правила:

<IfModule mod_rewrite.c>
AddType image/avif .avif

RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/avif
RewriteCond %{REQUEST_FILENAME} \.jpg$
RewriteCond "%{REQUEST_FILENAME}.avif" -s
RewriteRule ^.*$ $0.avif [END,T=image/avif]
</IfModule>

Что тут написано? Если браузер поддерживает формат AVIF (смотрим в заголовке), и запрашивает JPEG (определяется по расширению), и существует файл ненулевой длины с расширением .avif (то есть image.jpg.avif, например), то отдаём ему AVIF.

Хорошо работает, пока в папке с картинками лежит только image.jpg.avif, как только кладёшь ещё и image.jpg — перестаёт, отдаётся только она. Вчера час наверное думал что не так, пока наконец не понял — поверх «Апача» на хостинге стоит nginx, а ему мои правила по барабану.

Если картинки по урлу нет, то nginx отдаёт запрос дальше в «Апач», срабатывает правило, отдаётся AVIF, как только кладёшь JPEG, nginx его видит, отдаёт по урлу, не спрашивая «Апач» ни о чём.

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

Переложил на хостинг «Гитхаба» свой проект семилетней давности — «Какие графические форматы поддерживает ваш браузер?». Я его иногда обновляю и мне было бы проще это делать через репозиторий.

Из всего, что я там проверяю, сразу не сработала только проверка на AVIF — это новейший формат, у меня на компьютере его поддерживает пока только «Файерфокс», ему важно указание типа содержимого, а «Гитхаб» передаёт неправильное значение.

Браузеры (сверху вниз): «Сафари» 13, «Файерфокс» 78 и «Опера» 69

Я подумал, что наверняка есть какой-то способ указать правильный тип в файле конфигурации сайта, но нет, так это не работает, такой настройки в нём нет. В принципе, известно откуда «Гитхаб» берёт свою базу типов содержимого — из проекта mime-db. Но этот путь тоже не сработал — я добавил туда тип для AVIF больше недели назад, но ничего не изменилось. Видимо синхронизация изменений происходит нечасто.

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

Ссылка на проект: https://bolknote.github.io/detect-browser-graphics-formats/
Ссылка не репозиторий проекта: https://github.com/bolknote/detect-browser-graphics-formats