libavif: возможности, форматы, установка и практическое применение AVIF-инструментов

libavif — не фоторедактор и не конвертер с графическим окном, а открытая переносимая библиотека на C для чтения и записи AV1 Image File Format, дополненная консольными утилитами. Она нужна прежде всего разработчикам, инженерам медиапайплайнов и пользователям командной строки, которым требуется контролируемое кодирование и декодирование AVIF без отправки изображений в облачный сервис. Актуальный стабильный выпуск — 1.4.2 от 26 мая 2026 года. В обзоре разобраны именно libavif и поставляемые с проектом avifenc, avifdec и avifgainmaputil; их не следует путать ни с самим стандартом AVIF, ни с универсальными графическими конвертерами.

Задать вопрос фотографу

Андрей Фёдоров

Как вы могли заметить, здесь есть ТОП-ы на все случаи жизни, причём, их список постоянно пополняется. Кроме того, каждый год они обновляются, ведь я включаю в рейтинги реально лучшие аппараты из всех имеющихся в текущий момент на рынке. Именно мой опыт и знания помогли создать ресурс ТОП Фотограф, который, я надеюсь, приносит вам что-то полезное.

Задать вопрос

Что такое libavif и кто развивает проект

Официальное имя проекта пишется строчными буквами — libavif. Исходный код размещён в организации AOMediaCodec, а Alliance for Open Media указывает этот репозиторий как исходный код для работы с AVIF. Первоначальный copyright основного проекта относится к Joe Drago и 2019 году; современная кодовая база развивается участниками открытого проекта. На дату подготовки материала стабильная ветка не заброшена: версия 1.4.2 вышла 26 мая 2026 года, после мартовских выпусков 1.4.0 и 1.4.1, а в репозитории продолжается работа над исправлениями и развитием.

Главная задача библиотеки — дать приложению C API для разбора, декодирования, создания и кодирования файлов AVIF. AVIF использует AV1 для изображения и контейнерную структуру, поэтому libavif не содержит один единственный встроенный AV1-кодек на все случаи. При сборке выбираются внешние кодековые реализации. Проект умеет работать со всеми поддерживаемыми AV1 вариантами YUV и глубиной цвета, а также с альфа-каналом. Отдельно присутствуют функции преобразования между YUV и RGB, работа с цветовыми характеристиками, метаданными, последовательностями, сетками изображений, слоями и HDR gain map.

Консольные приложения — это прикладная оболочка над библиотекой, а не отдельные продукты. avifenc принимает изображения и создаёт AVIF, avifdec делает обратное преобразование или выводит диагностическую информацию, avifgainmaputil работает с AVIF, содержащими HDR gain map. Важно именно это разделение: библиотека предназначена для интеграции в программу, а CLI — для ручных операций, скриптов, тестирования параметров и автоматизации в командной строке.

Краткие параметры

Платформы, распространение и требования

libavif рассчитана на переносимую сборку и не привязана к одному рабочему столу. Для Windows документированы установка через vcpkg и официальные готовые бинарные файлы релизов; отдельно поддерживается пакет MSYS2 для среды UCRT64. На macOS проект доступен через Homebrew и MacPorts. Для Linux в официальной документации приведены пакеты Debian-подобных и Red Hat-подобных дистрибутивов. Такой способ распространения важен для разработчика: в одном случае libavif приходит как системная библиотека, в другом — как зависимость проекта, а в третьем можно использовать готовые avifenc.exe и avifdec.exe.

Сборка версии 1.4.2 требует CMake 3.22. Начиная с этого выпуска исходный код компилируется как C11, при этом публичные заголовочные файлы сохраняют совместимость с C99. Если включаются приложения, CMake активирует C++17, поскольку часть набора, в частности avifgainmaputil, использует C++. Это не означает, что прикладной код пользователя обязан быть написан на C++: основной публичный API остаётся C API.

Ключевая особенность сборки — отсутствие включённого по умолчанию AV1-кодека. Конфигурация должна подключить хотя бы подходящий бэкенд. libaom умеет и кодировать, и декодировать; dav1d и libgav1 используются как декодеры; rav1e и SVT-AV1 — как кодировщики. Поэтому две установки libavif одной версии могут различаться по реальным возможностям. avifenc и avifdec показывают доступные кодеки в справке или информации о версии, а параметр выбора кодека работает только с теми вариантами, которые были собраны.

Для консольных приложений требуются библиотеки JPEG и PNG: при AVIF_BUILD_APPS их нельзя отключить. В системном режиме CMake также требует libpng не ниже 1.6.32. libyuv не является обязательной зависимостью, но проект прямо рекомендует её для ускорения преобразований цветовых пространств. Для переноса JPEG с gain map в AVIF важен libxml2: если он отсутствует, сборка avifenc выполняется, но gain map из JPEG игнорируется. Такая зависимость легко объясняет ситуацию, когда одинаковая команда на двух компьютерах даёт разный по возможностям результат.

Android — библиотечная интеграция, а не мобильное приложение

В репозитории есть Android JNI bindings для использования декодера libavif внутри Android-приложений. Документирована сборка AAR, содержащего libavif и JNI-обёртку; в примерах используется dav1d, а в качестве альтернативы предусмотрен libgav1. Для сборки нужны Android SDK с target API 30, Android NDK, Gradle, CMake и Ninja. Также опубликован Maven-вариант Android-библиотеки. Это именно компонент для разработчиков: отдельного мобильного редактора libavif с галереей, кнопкой импорта и экраном экспорта проект не предлагает.

Как устроен интерфейс

У libavif нет окон, меню, миниатюр и панелей коррекции. Пользователь взаимодействует либо с консольными приложениями, либо с функциями C API. Поэтому под интерфейсом здесь разумно понимать три уровня: команды оболочки, набор аргументов CLI и программный API. Для фотографа, ожидающего визуальный предпросмотр качества, это принципиальное ограничение; для автоматизированного пайплайна отсутствие GUI, наоборот, снимает зависимость от ручных действий.

avifenc: область кодирования

avifenc строится вокруг одного результата AVIF. В простом случае пользователь указывает входной JPEG, PNG или Y4M и имя выходного файла. Основные параметры отвечают за качество цвета, качество альфа-канала и скорость кодера. Качество задаётся в шкале 0–100, где 100 соответствует lossless-режиму для соответствующей компоненты. Скорость лежит в диапазоне 0–10: 0 — самый медленный режим, 10 — самый быстрый, а стандартное значение CLI равно 6. Количество рабочих потоков задаётся через jobs; значение по умолчанию в консольной утилите — all, то есть разрешено использовать столько ядер, сколько сочтёт возможным реализация.

Расширенные параметры управляют глубиной, YUV-представлением, цветовым диапазоном, CICP, ICC, Exif, XMP, gain map, сетками и слоями. Для JPEG и PNG можно выбрать 8, 10 или 12 бит вывода. Режим YUV поддерживает auto, 4:4:4, 4:2:2, 4:2:0 и 4:0:0. Автоматический выбор учитывает внутренний формат JPEG, для серого PNG выбирает 4:0:0, а в остальных обычных случаях приходит к 4:4:4. Для Y4M исходная схема сохраняется.

Флаг lossless задаёт набор настроек без потерь и выводит предупреждение, если выбранные параметры или сам путь преобразования не позволяют получить заявленный режим. Это полезнее, чем механически считать любое значение качества 100 гарантией побитового совпадения с RGB-оригиналом. При конвертации RGB в YUV на итог влияют цветовое преобразование и субдискретизация, поэтому контроль результата должен учитывать не только параметр кодера.

avifdec: декодирование и диагностика

avifdec принимает AVIF и сохраняет JPEG, PNG или Y4M. Для PNG доступен вывод 8 или 16 бит, Y4M сохраняет глубину исходного AVIF, а JPEG всегда получается 8-битным. Для JPEG можно задать качество сохранения, стандартное значение — 90. Для PNG есть уровень сжатия 0–9. При декодировании 4:2:0 или 4:2:2 можно выбирать стратегию chroma upsampling: automatic, fastest, best, nearest или bilinear.

Особенно полезен режим info. Он декодирует все кадры и печатает сведения об изображении вместо записи файла. Это штатный инструмент для первичной проверки результата после кодирования: можно убедиться, что контейнер читается, увидеть параметры изображения и обнаружить ошибки до передачи файла в другой продукт. Для последовательностей и progressive AVIF предусмотрен выбор индекса кадра; значение all позволяет декодировать все кадры.

Декодер по умолчанию применяет ограничения безопасности на размер: максимум 268 435 456 пикселей суммарно и 32 768 пикселей по одной стороне. Эти пределы существуют для защиты от чрезмерного потребления памяти и переполнений. Их наличие важно при обработке внешних файлов: ошибка на очень большом изображении может означать срабатывание лимита, а не повреждение AVIF.

avifgainmaputil: HDR gain map как отдельная рабочая зона

Третья утилита предназначена для AVIF с HDR gain map. В ней есть отдельные команды combine, convert, tonemap, swapbase, extractgainmap и printmetadata. Gain map хранит данные, с помощью которых базовое изображение адаптируется к дисплеям с различным HDR headroom; просмотрщик без поддержки gain map показывает базовое изображение. Утилита позволяет собрать файл из базового и альтернативного изображения, преобразовать представление, выполнить тональное отображение, поменять базовую и альтернативную стороны местами, извлечь карту усиления и распечатать её метаданные.

В релизе 1.4.2 для avifgainmaputil добавлен параметр jobs и включена автоматическая разбивка на тайлы. Это важно для актуальности обзора: в более старых описаниях утилита могла выглядеть менее пригодной для многопоточной обработки. Gain map API перестал быть экспериментальным ещё в ветке 1.2.x, поэтому его можно рассматривать как штатную часть современной libavif, отдельно от других опций, которые в исходниках всё ещё помечены как experimental.

Основные функции libavif

Кодирование и декодирование AVIF

Библиотека создаёт и разбирает AVIF, передавая собственно AV1-сжатие выбранному кодековому бэкенду. Это архитектурно отличает libavif от монолитной программы: приложение может собраться, например, с libaom для полного цикла, с dav1d только для быстрого декодирования или с отдельным кодером для нужного сценария. В API предусмотрен выбор кодека, а также автоматический режим, который использует доступную реализацию.

Данные изображения представлены структурами libavif: размеры, глубина, YUV-плоскости, диапазон, альфа-канал, цветовые характеристики и сопутствующие свойства хранятся отдельно от файлового интерфейса JPEG или PNG. Благодаря этому ядро библиотеки пригодно не только для дисковых конвертаций: декодер может читать файл, блок памяти или пользовательский I/O. Для потоковой интеграции предусмотрена модель, в которой источник данных может временно сообщить, что нужный диапазон ещё не доступен.

RGB, YUV и альфа-канал

libavif поддерживает YUV 4:4:4, 4:2:2, 4:2:0 и монохромный 4:0:0, а также отдельную альфа-плоскость. API включает преобразование RGB в YUV и обратно. При наличии libyuv часть таких преобразований может выполняться ускоренным путём; без него остаётся собственная реализация. Для пользователя CLI это проявляется не как отдельная кнопка, а как качество и скорость цветового преобразования, особенно при больших изображениях и массовом запуске.

Наличие альфа-канала не означает, что любой выходной формат сохранит прозрачность. PNG способен сохранить её, JPEG — нет. avifdec поэтому имеет отдельное поведение для записи в непрозрачный формат, а avifenc позволяет отдельно задавать качество alpha. Для веб-графики с прозрачным фоном это существенно: выбор JPEG для контрольного декодирования автоматически исключает полноценную проверку альфа-канала.

Цветовые профили и метаданные

В структуре изображения предусмотрены ICC profile, CICP, Exif и XMP. avifenc имеет параметры, позволяющие игнорировать Exif, XMP или профиль, а также передать собственные payload-файлы для этих данных. Аналогично можно явно задавать CICP — color primaries, transfer characteristics и matrix coefficients — и диапазон YUV. Для HDR доступны характеристики PQ и HLG на уровне перечислений API, а также сведения CLLI.

Начиная с 1.4.0 при чтении PNG учитывается cICP chunk. Если в PNG одновременно присутствуют cICP и другие цветовые информационные chunks, приоритет обработки следует правилу спецификации PNG, из-за чего простое ожидание «всегда использовать ICC» может быть неверным. Тот же релиз изменил обработку ориентации при преобразовании в PNG или JPEG: clean aperture crop, rotation и mirror применяются при декодировании, а ориентационная запись Exif удаляется, чтобы не применять поворот повторно.

Сетки, последовательности и слои

avifenc умеет создавать grid AVIF. Пользователь задаёт M столбцов и N строк, после чего либо передаёт соответствующее количество одинаковых по геометрии изображений, либо одно изображение, которое можно корректно разделить на сетку в рамках ограничений формата. Сетка нужна не для визуального коллажа: это способ представить большое изображение как набор плиток внутри AVIF.

Последовательности изображений поддерживаются через несколько входных кадров и параметры времени. timescale или fps задаёт временную шкалу, стандартное значение CLI — 30, а duration позволяет менять длительность конкретных кадров. Есть максимальный интервал ключевых кадров и число повторов, по умолчанию бесконечное. Для Y4M avifenc может использовать частоту кадров из заголовка, если пользователь не установил свою.

Layered AVIF использует несколько слоёв, которые могут участвовать в progressive rendering. avifenc разрешает до четырёх слоёв, а флаг progressive автоматически выставляет параметры простого многослойного изображения из одного исходного кадра. Начиная с версии 1.4.1 progressive, layered и scaling-mode больше не обозначаются проектом как экспериментальные параметры. Однако практическая ценность прогрессивного режима всё равно зависит от поддержки такого файла конечным просмотрщиком или декодером, поэтому совместимость нужно проверять в целевой среде.

Глубина цвета и Sample Transform

Обычный параметр depth в avifenc для JPEG и PNG принимает 8, 10 или 12. В ветке 1.4 добавлена поддержка отдельных Sample Transform schemes из AVIF 1.2 и возможность включить дополнительное скрытое изображение с другой глубиной, чтобы при декодировании получить 16-битный результат. Это специализированная функция, а не универсальное обещание «любое 16-битное изображение кодируется как обычный AV1 16-bit». Комбинации ограничены поддерживаемыми рецептами, а avifdec включает обработку таких данных в соответствующем режиме 16-битного вывода.

Кодек-специфические параметры

Для опытных пользователей avifenc предоставляет advanced key/value options. Они передаются непосредственно выбранному кодеку; неиспользованный параметр вызывает предупреждение. Это даёт доступ к настройкам, которые не унифицированы на уровне libavif, но одновременно уменьшает переносимость команд: набор допустимых ключей зависит от кодера и его версии. Для воспроизводимого production-пайплайна поэтому недостаточно сохранить только строку avifenc — нужно фиксировать версию libavif и фактический AV1-бэкенд.

Что libavif не делает

libavif не предназначена для полноценного редактирования фотографий. У avifenc нет встроенного рабочего процесса с ресайзом, фильтрами, ретушью, управлением слоями в редакторском смысле или интерактивным сравнением до/после. В обсуждениях проекта avifenc прямо характеризуется как сравнительно простая утилита, отображающая возможности API в параметры командной строки, а для масштабирования и расширенного преобразования предлагаются более универсальные инструменты.

Параметр crop в avifenc нельзя трактовать как привычную обрезку пикселей. Он добавляет свойство clean aperture, вычисленное по прямоугольнику. Это контейнерная трансформация, а не редакторская операция с пересчётом растра. Аналогично irot и imir задают свойства вращения и отражения. Если задача требует физически изменить размер изображения, выполнить цветокоррекцию или подготовить несколько производных размеров, это нужно делать другим компонентом до или после libavif.

CLI также не является универсальным файловым конвертером. avifenc документирует JPEG, PNG и Y4M, а avifdec — JPEG, PNG и Y4M на выходе. RAW-файлы камер, TIFF, GIF, WebP и HEIC не входят в штатный перечень входа avifenc. Несколько входных файлов имеют специальный смысл для последовательностей, сеток или слоёв; отдельного режима «взять каталог разнородных фотографий и сделать независимый AVIF для каждой» нет. Для такой пакетной задачи используют цикл оболочки или внешний инструмент, вызывающий libavif для каждого файла.

Типичный рабочий сценарий

Для воспроизводимого примера возьмём обычный JPEG, который нужно преобразовать в AVIF для веб-публикации, а затем проверить. Такой сценарий показывает логику libavif, но не превращает библиотеку в фоторедактор: подготовка размера и цвета изображения должна быть выполнена заранее в другом инструменте.

1. Сначала подтверждают, что установленный avifenc относится к ожидаемой версии и содержит нужный кодек. В разных сборках набор AOM, rav1e или SVT-AV1 может отличаться, поэтому проверка версии и доступных codecs важнее предположения по имени пакета.
2. Исходный JPEG заранее приводят к нужным пиксельным размерам. libavif не берёт на себя ресайз фотографии.
3. Для базового кодирования можно использовать команду avifenc -q 75 input.jpg output.avif. Значение 75 — пример управляемого quality setting, а не универсально оптимальное число: фактический компромисс следует оценивать на своих изображениях.
4. Если требуется другой YUV-формат, глубина, скорость или конкретный кодек, параметры добавляют явно. В production полезно фиксировать их в скрипте, чтобы повторный запуск не зависел от ручного ввода.
5. Полученный файл проверяют командой avifdec –info output.avif. Она читает все кадры и показывает информацию без записи изображения.
6. Для визуальной проверки можно выполнить avifdec output.avif decoded.png. PNG удобен как контрольный формат, потому что не добавляет JPEG-потери при повторном сохранении.
7. После проверки файл открывают именно в целевом браузере, приложении или библиотеке, где он будет использоваться. Успешное чтение самим libavif подтверждает корректность для libavif, но не заменяет проверку совместимости конечного потребителя.

Этот цикл хорошо масштабируется в автоматизацию. Скрипт может отдельно подготовить исходники, вызвать avifenc, проверить код возврата, запустить avifdec –info и только затем публиковать результат. В отличие от браузерного сервиса, обработка не требует загрузки фотографий во внешнюю систему и может выполняться в CI, серверном процессе или локальном пайплайне.

Импорт, экспорт и форматы подробнее

JPEG

JPEG поддерживается avifenc как обычный вход и avifdec как выход. При автоматическом выборе YUV avifenc старается учитывать внутренний формат JPEG. В JPEG нет альфа-канала, поэтому этот путь не подходит для проверки прозрачности. При декодировании в JPEG выход всегда 8 бит на компоненту, а quality по умолчанию равен 90. Если исходный AVIF содержит большее цветовое разрешение или прозрачность, JPEG неизбежно не способен сохранить все свойства контейнера.

В современных версиях есть поддержка преобразования JPEG с Apple-style gain maps в AVIF с gain map, но она зависит от libxml2 в сборке приложений. Без libxml2 avifenc прямо сообщает при конфигурации, что будет игнорировать gain map в JPEG. Поэтому обработка HDR-JPEG должна начинаться с проверки сборки, а не только с проверки расширения файла.

PNG

PNG используется как вход avifenc и как выход avifdec. При кодировании можно сохранить прозрачность через alpha, выбрать глубину AVIF и цветовые параметры. При декодировании PNG поддерживает выход 8 или 16 бит. Уровень PNG-compress влияет на размер и скорость записи контрольного файла, но не меняет уже декодированные пиксели так, как JPEG quality.

Для PNG имеет значение метаинформация о цвете. Начиная с 1.4.0 libavif понимает cICP chunk. Если он присутствует одновременно с другими цветовыми chunks, правила приоритета могут изменить то, какие данные будут использованы. При расследовании цветового расхождения полезно проверять не только AVIF, но и цветовые теги исходного PNG.

Y4M

YUV4MPEG2 нужен главным образом для низкоуровневых и последовательностных сценариев. avifenc сохраняет YUV-формат и требует согласования глубины с входом; версия 1.4.2 отдельно исправила поведение так, чтобы несоответствующий depth для Y4M отклонялся. Через stdin без явного input-format avifenc по умолчанию ожидает именно Y4M, что важно для пайпинга из другого медиапроцесса.

Потоки и память

В CLI стандартный ввод может принимать JPEG, PNG или Y4M, если формат задан соответствующим параметром; auto для stdin не используется. В C API возможности шире: декодер может работать с именем файла, блоком памяти или пользовательским I/O. Это позволяет встроить libavif в сетевой, архивный или собственный контейнерный слой без обязательного временного файла на диске.

Автоматизация, многопоточность, облако и ИИ

Автоматизация — одна из естественных областей применения libavif. Команды не требуют интерактивных диалогов, а параметры можно фиксировать в shell, PowerShell, CI job или вызывающем приложении. avifenc и avifdec по умолчанию разрешают jobs=all, то есть консольные программы могут использовать несколько рабочих потоков. В API значение maxThreads имеет собственную настройку; приложение должно управлять ей осознанно, поэтому нельзя переносить поведение CLI «все ядра автоматически» на библиотечный вызов без проверки конфигурации.

Пакетная обработка реализуется внешней автоматизацией. Утилита не сканирует папку как отдельный batch-конвертер, зато её легко вызывать многократно. Это даёт точный контроль над именами файлов, ошибками и журналом, но требует навыков командной строки. Если несколько файлов передаются одной команде avifenc, они могут представлять кадры последовательности или слои, то есть это не равно независимой пакетной конвертации.

Облачного режима у libavif нет. Нет аккаунта, проекта в веб-интерфейсе, серверного лимита на мегабайты или механизма отправки фотографии на внешний сервис. После установки runtime может полностью работать с локальными данными. Интернет может понадобиться на этапе получения пакета или зависимостей: например, режим LOCAL в CMake в ряде случаев скачивает и собирает библиотеку зависимости. Это эксплуатационная деталь сборки, а не облачная обработка пользовательских фотографий.

ИИ-функций для генеративной обработки, повышения резкости, удаления шума, дорисовки или апскейла в libavif нет. Кодеки AV1 используют алгоритмы сжатия, но это не делает libavif «AI-фоторедактором». Если исходная задача связана с восстановлением снимка или нейросетевым увеличением, libavif может быть последним этапом экспорта в AVIF, но не выполняет творческую обработку.

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

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

Однако локальная обработка не означает отсутствие рисков. Декодирование непроверенных медиаданных — парсинг сложного бинарного контейнера и работа с внешним AV1-бэкендом. Поэтому актуальность версии и защитные лимиты имеют практическое значение. В 1.4.2 исправлялись, среди прочего, ошибки, связанные с памятью, null pointer и обработкой gain map. Если libavif встроена в публичный сервис загрузки изображений, обновление библиотеки и кодека является частью обычной эксплуатации.

Ограничения avifdec по числу пикселей и максимальной стороне не стоит отключать автоматически при первой ошибке. Для доверенного огромного файла лимиты можно пересматривать в контролируемой среде, но для внешнего контента они служат защитой от чрезмерного выделения памяти. Аналогично параметр no-strict отключает строгие проверки декодирования и полезен для диагностики совместимости, но успешное чтение в таком режиме не делает исходный файл автоматически корректным по строгим правилам.

Лицензия, стоимость и редакции

Основной код libavif распространяется по BSD-2-Clause. Лицензия разрешает использование, модификацию и перераспределение исходной и бинарной формы при сохранении требуемых уведомлений. В дереве проекта присутствуют сторонние компоненты со своими лицензионными текстами, поэтому разработчику дистрибутива нужно учитывать полный LICENSE, а не только одну строку SPDX у libavif.

У проекта нет Free, Pro, Team или Enterprise в коммерческом смысле, нет подписки, кредитов и пробного срока. Функциональные различия возникают из сборочной конфигурации: один пакет может включать только декодер, другой — несколько кодеров, третий — приложения, libyuv и поддержку преобразования JPEG gain map. Поэтому вместо сравнения тарифов здесь нужно сравнивать состав конкретной сборки.

Готовые Windows-бинарники avifenc.exe и avifdec.exe публикуются вместе с релизами. В системных пакетах состав и версия зависят от сопровождающего дистрибутива. Для критичной воспроизводимости предпочтительно фиксировать точную версию libavif и зависимостей в собственном окружении, а не исходить из того, что пакет с одинаковым именем на разных ОС идентичен по кодековым возможностям.

Плюсы и минусы

Кому подойдёт

• Разработчикам приложений. C API подходит, когда AVIF нужно встроить непосредственно в продукт, а не запускать внешний онлайн-сервис.
• Инженерам веб- и медиапайплайнов. avifenc и avifdec удобно использовать в CI, контейнере, серверной задаче и воспроизводимом скрипте.
• Пользователям, которым важна локальная обработка. Для кодирования не нужно отправлять фотографии на сторонний сервер.
• Исследователям формата AVIF. Управление YUV, CICP, depth, sequence, grid, layered и gain map даёт больше низкоуровневого контроля, чем большинство упрощённых GUI-конвертеров.
• Разработчикам Android. В проекте есть JNI/AAR путь для встраивания декодера в Android-приложение.

Кому не подойдёт

• Фотографу, которому нужен визуальный конвертер. Нет миниатюр, ползунка с интерактивным preview и пакетной очереди в окне.
• Пользователю, который хочет одновременно менять размер, резкость, цвет и формат. libavif решает AVIF-задачу, а не заменяет графический процессор общего назначения.
• Тому, кто конвертирует RAW или HEIC напрямую. Эти форматы не входят в стандартный вход avifenc.
• Команде без возможности управлять нативными зависимостями. Нужный кодек и часть возможностей определяются сборкой.
• Тем, кому нужен облачный совместный интерфейс. Нет аккаунтов, ролей, общей медиатеки и браузерной истории задач.

Альтернативы

libheif

libheif ближе всего по классу продукта, но охват контейнеров шире. Она декодирует и кодирует HEIF и AVIF, поддерживает HEIC, несколько дополнительных вариантов кодирования внутри HEIF, C API и систему codec plugins. Для AVIF она также может использовать libaom, dav1d, rav1e и SVT-AV1. libheif разумнее выбирать, когда одному приложению нужен общий API для HEIC и AVIF, thumbnails, дополнительных изображений и более широкого набора HEIF-возможностей. libavif логичнее там, где нужен сфокусированный AVIF API из экосистемы AOMediaCodec и не требуется HEIC.

ImageMagick

ImageMagick — универсальный движок обработки изображений и командная строка для большого числа форматов и операций. Он лучше подходит, когда преобразование в AVIF — только один этап среди resize, crop, colorspace, watermark или массовой обработки папки. libavif, напротив, даёт более прямой доступ к параметрам AVIF и может выступать библиотекой под ImageMagick-подобным верхним уровнем. Если задача начинается словами «сначала уменьшить, затем обработать, затем экспортировать», универсальный процессор обычно удобнее одного avifenc.

Squoosh

Squoosh подходит пользователю, которому нужен визуальный браузерный интерфейс и сравнение сжатия без установки нативной библиотеки. Проект выполняет компрессию локально в браузере, поэтому изображение не требуется отправлять на сервер для самого кодирования. Его сильная сторона — интерактивный просмотр и выбор параметров, тогда как libavif выигрывает в серверной автоматизации, C API и интеграции в собственное ПО.

sharp

sharp — библиотека для Node.js, построенная вокруг libvips и ориентированная на практические преобразования изображений в серверных приложениях. Она умеет выводить AVIF и одновременно решать задачи ресайза и других преобразований через JavaScript API. Это удобнее для Node-проекта, где AVIF является одним из форматов результата. libavif предпочтительнее, если нужен нативный C API, детальный контроль AVIF-контейнера, sequences/layers/gain map или собственная кодековая конфигурация.

Частые проблемы и диагностика

avifenc или API сообщает, что кодек недоступен

Наиболее типичная причина — сборка без подходящего AV1-бэкенда. libavif сама по себе не включает кодек по умолчанию. Проверяют информацию о версии и список доступных codecs, затем сопоставляют его с требуемой операцией: для кодирования нужен encoder, для декодирования — decoder. Наличие пакета libavif в системе ещё не доказывает наличие конкретного AOM, rav1e, SVT-AV1, dav1d или libgav1.

Сборка приложений останавливается на JPEG или PNG

При AVIF_BUILD_APPS JPEG и ZLIB/PNG обязательны. В системном режиме CMake должен найти соответствующие библиотеки; для PNG требуется версия не ниже 1.6.32. Если нужна только библиотека без avifenc/avifdec, конфигурация зависимостей может быть другой. Ошибку сборки поэтому диагностируют от выбранной цели, а не пытаются механически установить все известные пакеты.

JPEG с HDR gain map превратился в обычный AVIF

Проверяют наличие libxml2 в сборке приложений. При его отсутствии CMake прямо сообщает, что avifenc будет игнорировать gain map в JPEG. Далее проверяют, не был ли задан параметр ignore-gain-map и действительно ли исходный JPEG содержит поддерживаемую gain map. После кодирования полезно применять специализированные команды avifgainmaputil для печати метаданных и проверки структуры.

avifenc не принимает TIFF, WebP, GIF, HEIC или RAW

Это не ошибка определения расширения, а граница штатного CLI. avifenc документирует JPEG, PNG и Y4M. Неподдерживаемый исходник сначала декодируют или конвертируют подходящим инструментом в контролируемый промежуточный формат, а затем передают libavif. Для фотографии лучше избегать лишнего промежуточного lossy JPEG, если можно сохранить данные без дополнительной потери.

Нужно уменьшить изображение, но параметра resize нет

avifenc не предназначен для полноценного ресайза. Размер меняют до вызова кодера либо используют библиотеку более высокого уровня. Параметр crop в avifenc не решает эту задачу: он добавляет clean aperture property. Проверить это особенно важно в автоматизации, где неверное ожидание может привести к публикации AVIF с исходным большим растром.

Файл с quality 100 не совпадает с исходным RGB побитово

Проверяют весь путь данных: YUV-формат, субдискретизацию, преобразование RGB/YUV, alpha и цветовую информацию. Значение 100 относится к качеству кодирования соответствующей AV1-компоненты, а флаг lossless дополнительно выставляет согласованный набор настроек и предупреждает, если вход или конфигурация не позволяют режим без потерь. Для проверки декодируют в PNG и сравнивают данные с учётом цветового преобразования, а не только расширение и размер файла.

avifdec отклоняет очень большое изображение

Сначала сопоставляют геометрию с защитными пределами: 268 435 456 пикселей суммарно и 32 768 по стороне по умолчанию. Для внешнего файла это полезная защита. Если изображение доверенное и размер ожидаем, лимит можно настраивать осознанно, оценивая доступную память; для непроверенного контента автоматическое снятие ограничений ухудшает защиту.

Строгое декодирование не принимает файл, а другой просмотрщик открывает

Режим strict выполняет дополнительные проверки. avifdec имеет no-strict для диагностики, но его следует воспринимать как способ выяснить характер несовместимости, а не как доказательство корректности файла. Для production-потока лучше установить, какой именно constraint нарушен, и по возможности исправить источник или кодер.

Цвет после декодирования выглядит иначе

Проверяют ICC, CICP, диапазон YUV, matrix coefficients и исходные цветовые теги. Для PNG отдельно учитывают cICP, поддержку которого добавили в ветке 1.4. Если при кодировании использовались ignore-profile или собственный cicp, различие может быть следствием явной конфигурации. Контрольный просмотр следует выполнять в программе с предсказуемым color management.

Progressive или layered AVIF не даёт ожидаемого эффекта

Сначала подтверждают, что файл действительно создан как layered/progressive и что конечный декодер поддерживает соответствующий способ показа. avifdec умеет работать с progressive-изображением и выбирать слой через index, но сторонняя программа может реализовать другой набор возможностей. Для совместимости полезно иметь обычный контрольный AVIF и сравнить поведение на целевых клиентах.

Как проверить результат перед публикацией

1. Проверить декодируемость. Запустить avifdec –info и убедиться, что контейнер читается без ошибки.
2. Проверить геометрию. Сверить ширину, высоту и ожидаемое число кадров или слоёв.
3. Проверить глубину и YUV. Убедиться, что выбранный depth и subsampling соответствуют задаче, особенно для градиентов, HDR и графики с тонкими цветными деталями.
4. Проверить alpha. Для прозрачного контента декодировать в PNG, а не в JPEG.
5. Проверить цвет. Сверить ICC/CICP и визуально открыть результат в целевой color-managed среде.
6. Проверить метаданные. Если Exif, XMP, ICC или gain map должны сохраняться, убедиться, что их не отключили ignore-параметрами и что сборка поддерживает нужный путь.
7. Проверить целевую совместимость. Открыть AVIF в реальном браузере, приложении или SDK, куда файл будет передан.
8. Проверить производительность. На типичном наборе изображений зафиксировать время и загрузку CPU с выбранными speed/jobs; быстрый preset и максимальное качество решают разные задачи.
9. Проверить воспроизводимость. Записать версию libavif, используемый codec backend и ключевые параметры. Без этого результат трудно повторить после обновления окружения.

Размер файла следует оценивать только вместе с визуальным качеством и требованиями совместимости. Сам по себе самый маленький AVIF не является лучшим результатом, так же как максимальное качество не всегда оправдано для миниатюры. libavif предоставляет параметры, но выбор порога остаётся частью конкретного медиапайплайна.

FAQ

libavif и AVIF — это одно и то же?

Нет. AVIF — формат AV1 Image File Format и соответствующая спецификация. libavif — конкретная программная библиотека с API и утилитами, реализующая чтение и запись этого формата. Файл AVIF может быть создан и другими библиотеками.

Нужен ли интернет для кодирования фотографии?

После установки — нет. avifenc, avifdec и библиотечный API работают локально. Сеть может понадобиться для скачивания пакета или зависимостей на этапе установки и сборки, особенно если CMake настроен на LOCAL-зависимости.

Нужно ли создавать аккаунт?

Нет. В libavif нет пользовательской регистрации, облачного профиля и кредитной системы. Это нативная библиотека и исполняемые CLI-файлы.

Можно ли открыть AVIF как фотографию внутри libavif?

Отдельного просмотрщика с окном нет. avifdec может декодировать AVIF в PNG или JPEG и вывести техническую информацию, а отображение выполняет другая программа. Если нужен визуальный viewer, выбирают приложение, которое использует AVIF-декодер или другой движок.

Поддерживает ли avifenc HEIC?

Нет в штатном наборе входов. Для HEIC нужен отдельный декодер или более широкий HEIF-инструмент, после чего пиксельные данные можно передать libavif. Если одному приложению одновременно нужны HEIC и AVIF через общий API, практичной альтернативой является libheif.

Можно ли использовать libavif в Android-приложении?

Да, для декодирования проект содержит Android JNI bindings и процесс сборки AAR; опубликован и Maven-вариант библиотеки. Это SDK-компонент, а не готовое пользовательское Android-приложение.

Как выбрать AV1-кодек в libavif?

Сначала смотрят, какие backends включены в конкретную сборку. libaom способен кодировать и декодировать, dav1d и libgav1 предназначены для декодирования, rav1e и SVT-AV1 — для кодирования. После этого codec выбирают исходя из доступности, производительности и требований проекта; универсального выбора вне контекста сборки нет.

Есть ли аппаратное ускорение?

libavif абстрагирует AV1-кодек через подключаемые backend-реализации и сама не обещает единый аппаратный encoder/decoder для всех платформ. Реальные возможности зависят от выбранного codec backend и конкретной интеграции. Поэтому наличие аппаратного AV1 на устройстве нельзя автоматически приравнивать к аппаратному пути в данной сборке libavif.

Поддерживает ли libavif AV2?

В CMake версии 1.4.2 присутствует AVM-вариант с предупреждением, что поддержка AV2 экспериментальная и предназначена только для тестирования. Для обычного production-использования libavif в этом обзоре рассматривается как AVIF/AV1-библиотека, а не как стабильный AV2-инструмент.

Почему команда, работающая на одном компьютере, не работает на другом?

Чаще всего различается состав сборки: доступные AV1-кодеки, libyuv, libxml2, версия JPEG/PNG-библиотек или сама версия libavif. Сравнивают вывод версии, список codecs и конфигурацию зависимостей. Имя пакета без этих данных недостаточно для полной воспроизводимости.

Подходит ли libavif для массовой фотогалереи?

Да как низкоуровневый кодирующий компонент, если вокруг него есть система подготовки размеров, выбора качества, именования, кеширования и проверки. Как самостоятельный менеджер галереи libavif не подходит: она не каталогизирует фотографии, не строит превью-интерфейс и не управляет публикацией.

Итог по сценариям

Для разработчика, которому нужен нативный AVIF в собственном приложении, libavif — прямой и хорошо контролируемый вариант: есть C API, выбор AV1-бэкендов, метаданные, alpha, sequences, grids, layered AVIF и gain map. Для серверного пайплайна консольные avifenc и avifdec дают воспроизводимый локальный путь без регистрации и облачной загрузки.

Для фотографа, который хочет глазами подобрать степень сжатия, одновременно уменьшить снимок и быстро обработать папку, libavif сама по себе слишком низкоуровневая. В таком сценарии разумнее использовать GUI или универсальный image processor, а libavif оставить в роли кодирующего слоя. Для Node.js-проекта с ресайзом удобнее библиотека уровня sharp; для общего HEIC/AVIF API — libheif; для интерактивной разовой конвертации — браузерный инструмент вроде Squoosh.

Наиболее сильный сценарий libavif — когда формат AVIF является частью инженерного процесса, а не конечным пользовательским интерфейсом. Здесь ценятся точные параметры, локальная обработка, открытая лицензия и возможность фиксировать версию и codec backend. Главные ограничения столь же ясны: нет визуального редактора, нет встроенного ресайза и состав возможностей зависит от сборки. Если эти границы соответствуют задаче, libavif даёт именно низкоуровневый контроль, ради которого её и имеет смысл выбирать.