Libavif: кодирование и декодирование изображений AVIF

Libavif решает две практические задачи: кодирует изображения в AVIF и декодирует AVIF обратно в привычные растровые форматы, а также даёт разработчикам C-библиотеку для встраивания этой поддержки в приложения и серверные конвейеры. Программа особенно полезна тем, кто готовит графику для сайтов, автоматизирует обработку изображений, тестирует параметры AV1-кодирования, работает с HDR, альфа-каналом и последовательностями кадров или добавляет AVIF в собственное ПО. В комплекте нет графического редактора: основная пользовательская работа ведётся через утилиты avifenc, avifdec и avifgainmaputil, поэтому сильная сторона Libavif — точный контроль формата и воспроизводимые команды, а не ручная ретушь.

Что входит в Libavif и как распределены задачи

Название Libavif часто используют сразу для двух уровней продукта. Первый — сама библиотека libavif, которую приложение вызывает через C API. Второй — набор консольных программ, собираемых вместе с библиотекой. Для повседневной конвертации важнее именно утилиты: avifenc создаёт AVIF, avifdec читает AVIF и сохраняет результат в JPEG, PNG или Y4M, а avifgainmaputil выполняет операции с HDR gain map. Такое разделение полезно учитывать заранее: если требуется изменить экспозицию, удалить объект или дорисовать фон, Libavif не заменяет фоторедактор; если требуется однозначно задать глубину, субдискретизацию, CICP, качество альфа-канала, число потоков или структуру последовательности, консольные инструменты дают именно этот уровень контроля.

Другие инструменты: ФотоМАСТЕР.

Библиотека реализует контейнер AVIF и связывается с кодеками AV1, которые реально выполняют сжатие и декодирование. Поэтому набор доступных кодеков зависит от того, как собран конкретный пакет. Для кодирования avifenc может использовать AOM, rav1e или SVT-AV1, если соответствующая поддержка присутствует в сборке. Для декодирования avifdec может работать через AOM, dav1d или libgav1. Команда --version важна не только для номера выпуска: она помогает увидеть, какие кодеки и дополнительные компоненты действительно доступны в установленном варианте.

Libavif поддерживает AV1-совместимые YUV-представления и глубины цвета, альфа-канал, метаданные, профили цвета, сеточные изображения, прогрессивные слои и последовательности. При этом формат входа у avifenc намеренно ограничен: для обычной файловой конвертации он принимает JPEG, PNG и Y4M. TIFF, WebP, RAW и десятки других форматов напрямую не являются входом avifenc; в таких цепочках исходник сначала приводят к поддерживаемому формату другим инструментом либо используют библиотеку в собственном приложении. Это одно из ключевых отличий Libavif от универсальных графических пакетов.

Установка и начало работы

Windows

На Windows удобно начинать с готовой сборки, в которой присутствуют как минимум avifenc.exe и avifdec.exe. После распаковки можно либо запускать команды из каталога с исполняемыми файлами, либо добавить этот каталог в переменную PATH. Второй вариант удобнее для сценариев автоматизации: команды будут доступны из PowerShell, командной строки, CI-скриптов и сторонних программ без абсолютного пути. Если используется пакетный менеджер разработчика, библиотеку также можно получить через vcpkg; такой путь полезен прежде всего при сборке собственного C/C++ проекта.

Первый тест стоит провести не на фотографии, а на самой программе. В PowerShell выполните:

avifenc --version
avifenc --help
avifdec --version
avifdec --help

Если оболочка сообщает, что команда не найдена, проблема находится не в AVIF и не в кодеке: система просто не видит исполняемый файл. Перейдите в каталог программы и запустите .avifenc.exe --version либо исправьте PATH. Если версия выводится, но среди кодеков нет нужного энкодера, это уже свойство конкретной сборки. В таком случае параметр --codec не сможет включить компонент, который не был собран.

macOS

На macOS Libavif обычно устанавливают через Homebrew или MacPorts. После установки проверка ничем не отличается от других систем: avifenc --version показывает версию и доступные компоненты, а avifenc --help — фактический набор параметров именно вашей сборки. Это особенно полезно после обновлений: у Libavif появлялись новые режимы последовательностей, gain map и Sample Transform, поэтому чужая команда из старой инструкции может не совпадать с локальной версией.

brew install libavif
avifenc --version
avifdec --version

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

Linux

В Linux пакеты распределяются по правилам конкретного дистрибутива. В Debian-подобных системах библиотека и утилиты могут поставляться раздельно как разработческий пакет и пакет с бинарными инструментами; в других дистрибутивах названия отличаются. После установки ориентируйтесь не на название пакета, а на наличие avifenc и avifdec в PATH. Для разработки дополнительно нужны заголовки и файл конфигурации для системы сборки.

При самостоятельной сборке минимальный практический набор обычно включает CMake, один кодек AV1 для кодирования, декодер, JPEG- и PNG-зависимости, а для отдельных операций с gain map — дополнительные библиотеки. Опция сборки приложений должна быть включена, иначе библиотека соберётся, а команд avifenc и avifdec не появится. Этот момент важен на серверах, где пакет собирают с минимальным набором компонентов.

Как проверить, что установлена именно нужная сборка

Проверка состоит из трёх шагов. Сначала вызовите avifenc --version и зафиксируйте версию. Затем вызовите avifenc --help и убедитесь, что присутствуют параметры, которые вы собираетесь использовать. Наконец, выполните простое кодирование тестового PNG и обратное декодирование. Такой тест обнаруживает больше проблем, чем одно только наличие файла: ошибка может быть связана с отсутствующим кодеком, неработающей динамической библиотекой или несовместимой сборкой.

avifenc -q 75 input.png test.avif
avifdec test.avif test-decoded.png

Если обе команды завершились без ошибки, базовый путь «растровый вход → AVIF → растровый выход» работает. Далее уже имеет смысл настраивать качество, цвет, альфа-канал, потоки и дополнительные свойства контейнера.

Интерфейс командной строки

У Libavif нет главного окна, панели инструментов и диалогов экспорта. Его интерфейс — синтаксис команд, справка и диагностический вывод. Это не формальность: именно --help показывает, какие значения понимает установленная версия, а --version раскрывает доступные кодеки. Для воспроизводимого процесса полезно хранить команду рядом с исходниками или в скрипте, а не вводить параметры вручную по памяти.

Базовый синтаксис avifenc прост: параметры, затем входной файл и имя выходного AVIF. В свою очередь avifdec принимает AVIF и имя результата. Позиционные аргументы лучше размещать в конце команды, особенно когда используются обновляемые параметры с суффиксом :u, потому что часть настроек может применяться только к последующим входным кадрам.

avifenc [параметры] input.png output.avif
avifdec [параметры] input.avif output.png

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

Первое кодирование: avifenc без лишних параметров

Самая короткая рабочая команда выглядит так:

avifenc input.png output.avif

Если качество явно не указано, Libavif использует собственные значения по умолчанию. Для производственного процесса лучше задавать параметры явно: так результат не меняется неожиданно при переносе скрипта между версиями или сборками. В современной ветке качества -q и --qcolor используют шкалу от 0 до 100, где 100 означает без потерь на уровне кодирования цвета. Для обычной фотографии разумнее не искать «универсальную цифру», а прогнать несколько значений на типичных исходниках и сравнить артефакты на целевом размере.

avifenc -q 70 input.jpg output.avif
avifenc -q 85 input.png output-high.avif

Встроенная краткая справка самого avifenc приводит диапазон 60–80 как типичный ориентир, но это не эквивалент JPEG quality и не гарантия одинакового визуального качества на разных изображениях. Фотография с шумом, скриншот интерфейса, иллюстрация с тонкими линиями и полупрозрачная иконка требуют разных компромиссов. Поэтому число качества следует воспринимать как управляющий параметр энкодера, а не как абсолютную шкалу.

Поддерживаемые входные форматы

Файловый вход avifenc рассчитан на JPEG, PNG и YUV4MPEG2. JPEG удобен для уже сжатых фотографий, PNG — для RGB/RGBA, прозрачности и высокобитных исходников, Y4M — для подготовленных YUV-данных и последовательностей. Наличие AVIF в системе или поддержка WebP в браузере не означает, что avifenc автоматически начнёт читать эти форматы. Если исходник — TIFF, WebP или RAW, используйте отдельный этап преобразования или другой инструмент, умеющий подать в Libavif поддерживаемые пиксельные данные.

При чтении JPEG avifenc в режиме -y auto старается сохранить внутреннюю схему дискретизации JPEG, если это возможно. Для оттенков серого в PNG автоматический режим выбирает монохромный вариант YUV400, а для прочих случаев по умолчанию используется 4:4:4. Это важно для скриншотов и текста: если без необходимости перейти к 4:2:0, цветовые границы могут стать менее чёткими.

Явное имя выходного файла

Обычно выходной путь — последний позиционный аргумент. Ключ -o или --output позволяет задать его явно. Такой синтаксис удобен в генераторах команд, где входных кадров несколько и последний аргумент иначе легко перепутать с очередным входом.

avifenc -q 75 --output result.avif source.png

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

Качество цвета, альфа-канала и скорость

-q и —qalpha

-q управляет качеством цветовых плоскостей, а --qalpha — альфа-канала. Раздельный контроль полезен для графики с прозрачностью: можно сильнее сжать цвет, но оставить границы прозрачности чистыми. Если альфа важна для композитинга поверх контрастного фона, её качество следует оценивать отдельно — артефакт, почти незаметный на цвете, может проявиться светлой или тёмной каймой после наложения.

avifenc -q 70 --qalpha 95 icon.png icon.avif

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

-s: компромисс между временем и эффективностью

Ключ -s или --speed принимает значения от 0 до 10. Ноль — самый медленный режим, десять — самый быстрый; также можно передать default или сокращение d, чтобы использовать внутреннее значение кодека. Скорость влияет не на разрешение изображения, а на глубину поиска энкодера: более медленный режим обычно тратит больше вычислений ради лучшего решения при заданном качестве или размере, но величина выигрыша зависит от содержимого и кодека.

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

-j: число рабочих потоков

-j или --jobs задаёт количество рабочих задач. Значение all разрешает использовать доступные ядра; в современных сборках это значение является типичным поведением по умолчанию. Большее число потоков не гарантирует линейного ускорения: небольшие изображения, выбранный кодек, схема тайлинга и накладные расходы могут ограничить масштабирование. На общем сервере полезно ограничивать --jobs, чтобы один процесс не забирал все CPU у остальных задач.

avifenc -j 4 -s 6 -q 75 input.png output.avif

Если вы запускаете параллельно несколько процессов avifenc, внутренний и внешний параллелизм складываются. Например, восемь одновременных процессов с -j all способны создать чрезмерную конкуренцию за CPU и память. Для пакетной очереди чаще лучше выбрать либо несколько процессов с ограниченным числом потоков, либо меньше процессов с большим внутренним параллелизмом и измерить реальную пропускную способность на типичных файлах.

Глубина цвета и YUV-субдискретизация

Параметр —depth

-d или --depth задаёт 8, 10 или 12 бит на канал для выходного AVIF при входе JPEG/PNG. Для Y4M глубина должна соответствовать входу. Выбор большей глубины сам по себе не создаёт дополнительной информации в восьмибитном JPEG, но может быть нужен в HDR-процессе или при работе с высокобитным PNG, чтобы не потерять исходную точность. При публикации в среде с ограниченной поддержкой декодирования следует отдельно проверять совместимость целевых клиентов.

В Libavif 1.4.x у --depth есть расширенная форма D,EXTENSION, связанная с Sample Transform: дополнительное скрытое изображение может использоваться для восстановления 16-битного результата при декодировании. Это уже не обычная «поставить 16 бит» операция: схема имеет определённые поддерживаемые сочетания и требует совместимого декодера. Для стандартной веб-графики чаще остаются обычные 8/10/12-битные AVIF.

Параметр —yuv

-y или --yuv выбирает формат 4:4:4, 4:2:2, 4:2:0, 4:0:0 либо auto. Смысл параметра — не «качество» в общем виде, а количество цветовой информации относительно яркостной. 4:2:0 экономит место и часто подходит фотографии, но на цветном тексте, UI-скриншотах, диаграммах и тонких контрастных линиях может давать заметное размывание цвета. 4:4:4 сохраняет цветовое разрешение и потому предпочтительнее там, где важны резкие границы цветовых каналов.

avifenc -q 75 -y 420 photo.png photo.avif
avifenc -q 75 -y 444 screenshot.png screenshot.avif

Для монохромного изображения доступен YUV400. Использовать его для цветного исходника как способ «сжать сильнее» нельзя: это уже намеренное удаление цветовой составляющей. Кроме того, некоторые комбинации матрицы цвета и монохромного режима ограничены спецификацией AV1; современные версии avifenc отклоняют несовместимые сочетания вместо создания сомнительного файла.

SharpYUV при 4:2:0

Флаг --sharpyuv включает более аккуратное преобразование RGB в YUV420, если сборка поддерживает соответствующую библиотеку. Он применяется только к 4:2:0 и игнорируется, когда вход уже Y4M либо выбран другой выходной формат. Практический смысл — лучше сохранить визуальную чёткость цветовых границ при неизбежном уменьшении цветового разрешения, но это всё равно не превращает 4:2:0 в 4:4:4. Для критичной интерфейсной графики правильнее сначала сравнить оба варианта.

Режим без потерь: что реально делает —lossless

-l или --lossless переводит набор настроек в режим без потерь и проверяет, допускают ли остальные параметры такое кодирование. Это удобнее, чем вручную выставлять качество 100 и надеяться, что преобразование RGB→YUV не внесло изменений. Если конфигурация несовместима с lossless, программа предупреждает или прекращает работу в зависимости от причины.

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

avifenc --lossless input.png output-lossless.avif

Lossless AVIF не обязан быть меньше PNG на каждом типе данных. На простых логотипах, индексированных изображениях и синтетической графике специализированное PNG-сжатие иногда оказывается эффективнее; на других данных картина меняется. Правильный критерий — размер и время на собственном наборе, а не предположение, что современный формат всегда выигрывает. Если задача состоит в абсолютной идентичности пикселей, после кодирования стоит декодировать файл и сравнить результаты побитно или средствами анализа изображений.

Цветовой профиль, CICP и диапазон

ICC-профиль и параметры CICP решают разные задачи

В AVIF цвет можно описывать через ICC-профиль и через CICP-поля контейнера. В avifenc ключ --icc позволяет явно подложить профиль из отдельного файла, а --cicp или эквивалентный --nclx задаёт три числовых значения: primaries, transfer characteristics и matrix coefficients. Пример записи выглядит как 1/13/6. Это не «пресет sRGB» в бытовом смысле, а прямое управление полями стандарта, поэтому числа нельзя подбирать наугад. Если цветовой конвейер не знает требуемых кодов, безопаснее сохранить корректный профиль источника, чем поставить случайную комбинацию.

Ключ -r или --range отдельно задаёт полный либо ограниченный диапазон YUV. Для JPEG и PNG по умолчанию используется полный диапазон, а для Y4M сохраняется диапазон входа. Ошибка здесь может визуально проявиться как выцветание теней, потеря деталей в светах или общий сдвиг контраста. При расследовании «AVIF выглядит светлее/темнее исходника» нужно проверять не только качество, но и полный набор: CICP, ICC, диапазон и поведение конкретного просмотрщика.

avifenc --cicp 1/13/6 --range full input.png output.avif

Не следует механически копировать CICP из чужой команды для HDR или широкого цветового охвата. Например, параметры BT.2020 и PQ имеют смысл только тогда, когда сами пиксели действительно представлены в соответствующем цветовом пространстве и передаточной функции. Запись метки не преобразует изображение из sRGB в HDR; она лишь сообщает декодеру, как трактовать значения.

Когда использовать —ignore-profile

--ignore-profile и его синоним --ignore-icc отбрасывают встроенный цветовой профиль входного файла. Это полезно в строго контролируемом конвейере, где цвет уже нормализован внешним инструментом и профиль намеренно не должен попасть в AVIF. Но применять флаг как способ «исправить странный цвет» без понимания причины рискованно: если исходник действительно не sRGB, отбрасывание профиля лишит декодер важной информации.

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

Exif и XMP

При обычной конвертации Libavif способен переносить метаданные из поддерживаемых входов. Ключи --ignore-exif и --ignore-xmp отключают соответствующие блоки. Обратные варианты --exif filename и --xmp filename позволяют подставить внешнюю полезную нагрузку; при этом они подразумевают игнорирование одноимённых данных из исходника, чтобы не создавать конфликт.

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

avifenc --ignore-exif --ignore-xmp -q 72 photo.jpg photo.avif

Поворот, отражение и clean aperture

Некоторые преобразования AVIF можно хранить как свойства контейнера вместо физического пересчёта пикселей. --irot добавляет поворот кратно 90 градусам, а --imir — отражение. Значение угла для --irot задаётся числом 0–3 и означает поворот против часовой стрелки на 90 × значение градусов. Для отражения 0 означает верх-низ, 1 — лево-право.

--crop и --clap работают с clean aperture. Первый ключ удобнее, когда исходная область известна в пиксельных координатах: X, Y, ширина, высота. Второй предоставляет низкоуровневое описание через числители и знаменатели ширины, высоты и смещений. Эти свойства не равны обычному необратимому кадрированию в фоторедакторе: они описывают область отображения внутри контейнера. Поддержку таких трансформаций нужно проверять на целевых декодерах.

avifenc --irot 1 input.png rotated.avif
avifenc --imir 1 input.png mirrored.avif
avifenc --crop 100,50,1200,800 input.png cropped-view.avif

Pixel aspect ratio и CLLI

--pasp H,V добавляет соотношение шага пикселей по горизонтали и вертикали. Для обычной современной веб-графики пиксели почти всегда квадратные, и такой параметр не нужен; он становится важен при переносе материала из видеоцепочек или специализированных источников с неквадратным пиксельным аспектом. Не стоит использовать pasp как замену изменению размеров изображения.

--clli MaxCLL,MaxPALL записывает сведения об уровне яркости контента. Эти числа относятся к HDR-метаданным и должны соответствовать реальному содержимому. Они не «делают картинку HDR» сами по себе. Если пайплайн не умеет вычислять или гарантировать корректные значения, лучше не сочинять их вручную ради наличия поля.

Прозрачность и премультиплицированный альфа-канал

Libavif умеет кодировать альфа-канал отдельно от цветовых данных. Для обычного RGBA PNG достаточно передать файл в avifenc; при наличии альфы программа создаёт соответствующую auxiliary image. Параметр --qalpha регулирует её качество. Это позволяет, например, хранить фотографический цвет со средним качеством, но границу маски — почти без потерь.

Флаг --premultiply предназначен для данных, где цветовые компоненты должны быть предварительно умножены на альфа-канал, и сигнализирует это в AVIF. Нельзя включать его просто «для лучшей прозрачности»: премультиплицированный и straight alpha — разные модели представления. Если источник straight alpha, а конвейер ошибочно считает его premultiplied, по краям полупрозрачных объектов могут появиться тёмные ореолы или измениться цвет.

Проверять прозрачность нужно не только на шахматной подложке. Полезно декодировать AVIF в PNG и наложить результат на белый, чёрный и насыщенный фон. Так видны дефекты края, которые маскируются на нейтральном фоне. Для UI-иконок, логотипов и теней часто оказывается рационально ставить --qalpha выше, чем -q.

Выбор AV1-кодека

AOM, rav1e и SVT-AV1

Ключ -c или --codec выбирает кодировщик AV1 из тех, что присутствуют в сборке. Типовые значения — aom, rav1e и svt. Если параметр не указан, Libavif выбирает доступный кодек автоматически. Важно понимать, что два кодека при одинаковом -q и -s не обязаны выдавать одинаковый размер или визуальное качество: шкалы и внутренние эвристики отличаются.

avifenc --codec aom -q 75 -s 6 input.png aom.avif
avifenc --codec svt -q 75 -s 6 input.png svt.avif

Сравнивать кодеки корректнее не «на одной цифре quality», а при одинаковом практическом ограничении: например, подобрать параметры под близкий размер и затем оценить изображение, либо под близкое визуальное качество сравнить размер и время. Иначе тест измеряет различие шкал параметров, а не реальную эффективность.

Поддержка конкретного кодека определяется сборкой. Если avifenc --help перечисляет только один вариант, ключ --codec svt не скачает SVT-AV1 и не подключит его автоматически. Нужен другой пакет либо новая сборка Libavif с соответствующей зависимостью.

Продвинутые параметры -a/—advanced

-a или --advanced KEY[=VALUE] передаёт настройку напрямую выбранному кодеку. Это уровень для пользователей, которым недостаточно стандартных -q, -s и тайлинга. Для AOM поддерживаются пары ключ-значение, известные самому libaom; часть параметров можно направлять только на цвет или только на альфа-плоскость префиксами color:/c: и alpha:/a:.

avifenc -c aom -a tune=ssim -q 75 input.png output.avif

Опции кодека следует применять только после проверки документации конкретной версии. Если ключ не используется выбранным кодеком, avifenc предупреждает об этом. Такой сигнал нельзя игнорировать в автоматическом пайплайне: иначе скрипт формально завершится, но предполагаемая настройка качества не будет действовать.

В старых инструкциях можно встретить прямое управление quantizer через --min, --max, --minalpha и --maxalpha. В современных версиях эти параметры считаются устаревшим способом и заменены шкалой качества. Для нового скрипта разумнее использовать -q и --qalpha, а низкоуровневые quantizer-параметры оставлять только там, где нужно воспроизвести существующий технологический процесс.

Целевой размер файла

--target-size S просит энкодер приблизиться к заданному размеру в байтах. Это удобно, когда ограничение продиктовано не качеством как таковым, а лимитом системы публикации. Однако поиск нужного размера требует дополнительных проходов и может работать значительно медленнее обычного кодирования. В справке Libavif прямо отмечено, что такой режим способен увеличивать время до нескольких раз.

avifenc --target-size 200000 input.png output.avif

Целевой размер не гарантирует визуальную приемлемость. На сложном шумном изображении 200 КБ могут быть явно недостаточны, а на простой иллюстрации — избыточны. Поэтому лимит размера стоит сочетать с визуальной проверкой и разумными ограничениями пайплайна. Если платформа допускает несколько вариантов изображения, чаще полезнее генерировать разные разрешения, чем пытаться любой исходник втиснуть в один жёсткий размер.

Тайлинг и сеточные изображения

Внутренние тайлы энкодера

Параметры --tilerowslog2 и --tilecolslog2 управляют разбиением AV1-кадра на тайлы. Значение задаётся как логарифм по основанию два от количества строк или столбцов. Ручное указание переключает avifenc из автоматического режима тайлинга в ручной. Ключ --autotiling возвращает автоматический подбор.

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

AVIF grid через —grid

-g или --grid MxN создаёт AVIF grid: логически одно изображение состоит из нескольких клеток. Можно передать M×N отдельных изображений одинаковых размеров, глубины и других ключевых характеристик либо один файл, который можно равномерно разрезать на указанную сетку. Профиль цвета сетки берётся из первого входа.

avifenc --grid 2x2 large.png large-grid.avif

Grid не следует путать с внутренними AV1-тайлами. В первом случае структура существует на уровне AVIF как производное изображение из нескольких items; во втором один AV1-кодированный кадр делится для работы кодека. Grid используют, в частности, для очень больших изображений и сценариев, где ограничения профиля применяются к отдельным элементам сетки. У целевого декодера должна быть корректная поддержка grid.

Если вход содержит gain map, современные версии Libavif умеют учитывать её при работе с grid. Но это уже сложный HDR-сценарий: нужно проверять как базовое изображение, так и карту усиления после декодирования. Простой факт, что команда успешно создала файл, ещё не подтверждает корректность отображения во всех клиентах.

Прогрессивные и многослойные AVIF

—progressive

Флаг --progressive автоматически подбирает параметры для простого многослойного изображения из одного входного кадра. Идея похожа на прогрессивное отображение: совместимый декодер может получить грубую версию раньше, а затем уточнить её следующими слоями. Это не отдельный «уровень JPEG progressive», а механизм layered AVIF.

Поддержка прогрессивных слоёв на стороне просмотра критична. Если целевая программа игнорирует промежуточные слои или понимает только основной результат, преимущество постепенной отрисовки исчезнет, хотя финальное изображение может оставаться корректным. Для веб-проекта такой режим следует тестировать именно в поддерживаемых браузерах и CDN, а не только через avifdec.

—layered и —scaling-mode

--layered кодирует отдельный вход как слой; в стабильной ветке поддерживается до четырёх слоёв. Параметр --scaling-mode N/D задаёт масштаб слоя дробью. Это позволяет строить структуру, где ранний слой меньше основного и быстрее доступен для предварительного отображения. Начиная с выпуска 1.4.1 прогрессивный, layered и scaling mode больше не считаются экспериментальными параметрами командной строки.

avifenc --layered 
  --scaling-mode 1/4 layer1.png 
  --scaling-mode 1/2 layer2.png 
  --scaling-mode 1/1 layer3.png output.avif

Все слои должны быть согласованы по смыслу и параметрам. Это не стек слоёв как в PSD: Libavif не хранит отдельные редактируемые объекты, режимы наложения или маски фоторедактора. Layered AVIF — механизм кодирования представлений одного изображения с разной детализацией.

Последовательности и анимированный AVIF

Несколько входов

Чтобы создать последовательность, avifenc принимает несколько входных изображений. В таком режиме важны --timescale, --duration, --keyframe и --repetition-count. Если все кадры имеют длительность одну единицу timescale, значение --timescale численно соответствует кадрам в секунду. Для Y4M при отсутствии явных параметров программа может взять частоту из заголовка входа.

avifenc --timescale 30 frame01.png frame02.png frame03.png animation.avif

Формирование анимации из произвольных PNG требует, чтобы кадры имели совместимые размеры и характеристики. Если требуется разная длительность, --duration действует на последующие входы и может использоваться вместе с обновляемыми параметрами. Это даёт точный контроль тайминга, но одновременно повышает риск ошибиться в порядке аргументов; для длинных последовательностей команду лучше генерировать скриптом.

—duration и обновляемые параметры :u

Некоторые настройки допускают суффикс :u или :update. Он означает «применять это значение к входам, указанным после параметра», а не глобально ко всей команде. Такой механизм используется для качества, альфы, gain map, тайлинга, scaling mode, длительности и codec-specific параметров. Например, можно уменьшить качество первых слоёв или изменить длительность отдельных кадров без запуска отдельного процесса.

avifenc --timescale 100 
  --duration 10 frame1.png 
  --duration 25 frame2.png 
  --duration 10 frame3.png out.avif

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

Ключевые кадры и число повторов

-k или --keyframe INTERVAL задаёт максимальный интервал между ключевыми кадрами последовательности. Ноль отключает принудительный интервал. Чаще ставить ключевые кадры полезно для случайного доступа и устойчивости к потерям, но это может ухудшить степень сжатия, потому что межкадровые зависимости используются меньше.

--repetition-count управляет количеством повторов анимации; значение infinite задаёт бесконечный цикл и является типичным значением по умолчанию. Если анимация должна проиграться один раз, задайте конкретное число в соответствии с ожидаемой семантикой клиента и обязательно проверьте результат в целевой программе: интерпретация счётчика повторов в разных форматах исторически бывает неодинаковой.

Декодирование через avifdec

Базовый вывод в PNG, JPEG и Y4M

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

avifdec input.avif decoded.png
avifdec input.avif decoded.jpg
avifdec input.avif decoded.y4m

JPEG всегда сохраняется с восьмибитной глубиной. Для PNG ключ -d выбирает 8 или 16 бит. Для Y4M глубина сохраняется. Поэтому при проверке 10- или 12-битного AVIF нельзя судить о точности по JPEG: само сохранение в JPEG уже понижает глубину.

—info как диагностический инструмент

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

avifdec --info input.avif

Если файл «открывается не так» в сторонней программе, сначала сравните его свойства через --info с ожидаемыми. Часто причина обнаруживается без перекодирования: неожиданная 4:4:4-субдискретизация, 10-битная глубина, нестандартный профиль, поворот в контейнере или последовательность вместо обычного still image.

Выбор декодера

-c или --codec у avifdec выбирает доступный декодер: AOM, dav1d или libgav1. Как и при кодировании, реальный список зависит от сборки. Если нужно воспроизвести проблему конкретного декодера, явный выбор помогает отделить дефект файла от различий реализации.

При повседневном использовании автоматический выбор обычно достаточен. Смена декодера не исправляет некорректную цветовую метку или повреждённый контейнер; она лишь позволяет проверить, связано ли поведение с конкретной реализацией AV1-декодирования.

Качество JPEG и сжатие PNG

Для JPEG ключ -q у avifdec означает качество уже выходного JPEG, а не качество исходного AVIF. Это другой параметр, несмотря на одинаковую букву. Значение по умолчанию — 90. Если цель — оценить AVIF, лучше декодировать в PNG, чтобы новый этап JPEG-сжатия не добавлял собственные артефакты.

Для PNG доступен --png-compress с уровнем 0–9. Он влияет на время и размер PNG, но не на пиксели. Поэтому при массовой диагностике можно выбрать более быстрый уровень, а для хранения результата — более высокий, если это оправдано.

Апсемплинг цветности

-u или --upsampling выбирает способ восстановления цветовых данных для 4:2:0/4:2:2. Варианты включают automatic, fastest, best, nearest и bilinear. Если вы сравниваете качество AVIF по декодированному PNG, метод апсемплинга становится частью эксперимента: разные методы могут по-разному выглядеть на цветных границах.

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

Последовательности: —index и —progressive

--index I выбирает кадр последовательности или слой прогрессивного изображения. Индексация начинается с нуля. Значение all декодирует все кадры; для PNG программа формирует набор имён с нулевым дополнением индекса. Это удобный способ разложить анимированный AVIF на отдельные изображения для проверки.

avifdec --index all animation.avif frame.png

Флаг --progressive включает обработку прогрессивного AVIF так, чтобы --index выбирал слой в прогрессивном порядке. Без этого режима декодирование может ориентироваться на обычную семантику последовательности. При тестировании layered AVIF полезно отдельно декодировать каждый слой и убедиться, что качество действительно возрастает так, как задумано.

Строгая проверка и лимиты безопасности

По умолчанию avifdec выполняет строгие проверки структуры. --no-strict отключает часть валидации и может помочь исследовать файл, который программа считает несоответствующим требованиям. Это диагностический режим, а не универсальное «починить AVIF»: если сторонний файл проходит только с --no-strict, его не стоит автоматически считать корректным для публикации.

--size-limit ограничивает суммарное число пикселей, а --dimension-limit — максимальную ширину или высоту. Эти ограничения защищают от файлов, которые способны вызвать чрезмерное потребление памяти. Увеличивать или отключать их следует только для доверенных входов и после оценки доступной памяти. На сервере, принимающем пользовательские загрузки, ослабление лимитов без дополнительной защиты ухудшает устойчивость.

HDR gain map и avifgainmaputil

Начиная со стабильной поддержки gain map в современных ветках Libavif, вместе с основными утилитами устанавливается avifgainmaputil. Карта усиления позволяет хранить базовое изображение и данные, необходимые для адаптации отображения к HDR-возможностям дисплея. Это более сложная схема, чем обычный 10-битный AVIF: она включает базу, alternate representation и метаданные карты.

Утилита предоставляет команды combine, convert, tonemap, swapbase, extractgainmap и printmetadata. В 1.4.2 она также умеет использовать несколько рабочих потоков через --jobs. Набор опций лучше смотреть через встроенную справку конкретной подкоманды, потому что параметры сильно отличаются от обычного avifenc.

combine

combine создаёт AVIF с gain map из базового и альтернативного изображения. Типичный сценарий — отдельные SDR и HDR-представления одной сцены. Критически важно, чтобы изображения были пространственно согласованы: одинаковое кадрирование, геометрия и соответствующая цветовая интерпретация. Если взять два похожих, но не идентичных кадра, карта будет кодировать не только динамический диапазон, но и реальные различия изображения.

Параметры качества базы и карты можно настраивать отдельно. Это разумно, потому что артефакты gain map способны проявляться только на HDR-дисплее и оставаться незаметными при SDR-проверке. Поэтому тестирование должно охватывать оба режима отображения.

convert

convert предназначен, в частности, для преобразования JPEG с совместимой gain map в AVIF с gain map. Поддержка такого входа зависит от сборки и дополнительных библиотек: при сборке без нужного XML-компонента avifenc и связанные инструменты не смогут полноценно разобрать определённые gain map из JPEG. Это хороший пример того, почему версия программы сама по себе не описывает все возможности — нужно знать конфигурацию сборки.

tonemap

tonemap формирует изображение под заданный HDR headroom, то есть под отношение доступной яркости дисплея к SDR-уровню. Практически это позволяет получить представление, соответствующее конкретному диапазону отображения. Тонмаппинг не является универсальным «HDR в SDR» фильтром: результат зависит от метаданных и выбранного headroom, поэтому его оценивают на содержимом с яркими бликами и сложными переходами.

swapbase, extractgainmap и printmetadata

swapbase меняет местами базовое и альтернативное представления. Это полезно, когда нужно изменить то, какое изображение считается основным для декодеров без поддержки gain map. extractgainmap сохраняет саму карту как изображение для анализа, а printmetadata выводит её параметры. Последняя команда особенно удобна при отладке чужих файлов: она позволяет сначала понять структуру, не выполняя перекодирование.

В HDR-процессе нельзя ограничиваться фактом, что файл открывается. Проверяйте базовое представление в обычном SDR-декодере, результат на HDR-клиенте, наличие и смысл метаданных gain map, а также поведение после трансформаций и grid. Ошибки цветовой маркировки в таком контейнере часто выглядят как «неправильная яркость», хотя само AV1-сжатие работает корректно.

Чтение из stdin и конвейеры без временных файлов

avifenc умеет читать вход из стандартного потока. Это полезно, когда предыдущая стадия уже выдаёт JPEG, PNG или Y4M и нет смысла сохранять промежуточный файл. Ключ --stdin включает чтение из stdin, а --input-format задаёт формат потока. Для stdin по умолчанию предполагается Y4M; автоматическое определение в этом режиме не используется, поэтому для PNG и JPEG формат лучше указывать явно.

producer-command | avifenc --stdin --input-format png -q 75 output.avif

В потоковом режиме нельзя одновременно перечислять обычные входные файлы: stdin становится единственным источником. Имя выходного файла всё равно требуется. Такое ограничение упрощает семантику команды и предотвращает неоднозначность, какой набор параметров относится к потоку и к файлам.

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

Пакетная обработка файлов

PowerShell

Libavif не содержит собственного менеджера очереди или диалога «Batch». На Windows эту задачу удобно решать PowerShell. Ниже пример, который берёт PNG из каталога и создаёт AVIF с тем же базовым именем. Кавычки вокруг путей обязательны, если возможны пробелы.

Get-ChildItem -Filter *.png | ForEach-Object {
    $out = Join-Path $_.DirectoryName ($_.BaseName + '.avif')
    & avifenc -q 75 -s 6 --no-overwrite $_.FullName $out
}

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

Shell в Linux и macOS

В POSIX-оболочке лучше избегать конструкции for f in *.png, если имена могут содержать переносы строк или требуется рекурсивный обход. Для простого контролируемого каталога она допустима; для общей автоматизации удобнее find с нулевыми разделителями.

find ./src -type f -name '*.png' -print0 | while IFS= read -r -d '' f; do
    out="${f%.png}.avif"
    avifenc -q 75 -s 6 --no-overwrite "$f" "$out" || exit 1
done

Если каталог содержит тысячи файлов, не стоит сразу добавлять внешний xargs -P с большим числом процессов и одновременно оставлять каждому avifenc -j all. Сначала выберите модель параллелизма. Например, четыре процесса по четыре потока часто предсказуемее, чем четыре процесса, каждый из которых пытается занять все ядра.

Разные профили для фотографий и интерфейсной графики

Одинаковая команда для всех изображений удобна, но редко оптимальна. Для фотографий обычно допустима 4:2:0-субдискретизация и умеренное качество; для скриншотов, схем и UI чаще важнее 4:4:4. Для прозрачных ресурсов отдельно контролируют --qalpha. Поэтому практический пайплайн нередко классифицирует входы по назначению или каталогу и применяет несколько заранее протестированных пресетов.

# Фотография
avifenc -q 72 -y 420 -s 6 photo.png photo.avif

# Скриншот
avifenc -q 82 -y 444 -s 6 screen.png screen.avif

# Прозрачный ресурс
avifenc -q 75 --qalpha 95 -y 444 icon.png icon.avif

Эти числа — не универсальная рекомендация, а пример разделения параметров по типу контента. Рабочие значения выбирают на собственной выборке и фиксируют в проекте вместе с версией инструмента.

Как оценивать качество без самообмана

Сравнение «AVIF 80 против JPEG 80» методологически неверно: шкалы качества разных кодеков не совпадают. Более полезны два типа теста. Первый — одинаковый размер файла: подбирают параметры, чтобы результаты были близки по байтам, и сравнивают визуальные дефекты. Второй — одинаковый критерий качества: ищут настройки, при которых изображения визуально или по выбранной метрике сопоставимы, и затем сравнивают размер и время.

Для фотографии проверяйте мелкую текстуру, волосы, листву, шум, градиенты неба, цветные края и тёмные области. Для интерфейса — тонкие линии, мелкий шрифт, цветные пиксельные границы и полупрозрачные тени. Артефакт AV1 может быть менее привычным, чем блоки JPEG, поэтому одного взгляда на уменьшенную картинку недостаточно.

Если используется объективная метрика, декодируйте все варианты одним и тем же декодером в одинаковое цветовое пространство и глубину. Иначе метрика начинает измерять различия конвертации. Для 4:2:0 отдельно фиксируйте способ chroma upsampling. При HDR ещё важнее согласовать тонмаппинг и дисплейный диапазон, иначе сравнение чисел теряет смысл.

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

Производительность: какие параметры действительно влияют

Время кодирования определяется не одним --speed. На него влияют разрешение, глубина, выбранный кодек, количество потоков, схема тайлинга, наличие альфы, target-size, количество слоёв и особенности содержимого. Поэтому чужие цифры «столько-то мегапикселей в секунду» без описания всех условий почти бесполезны.

Самый заметный рычаг — --speed. Следом идут кодек и число потоков. Режим --target-size может требовать нескольких проходов. Lossless и высокие значения качества также меняют профиль нагрузки. На больших изображениях автоматический тайлинг помогает использовать параллелизм, но слишком мелкое разбиение ухудшает компрессию.

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

Для CDN или системы загрузок разумно иметь два режима: быстрый предварительный вариант и более медленный финальный. Первый даёт пользователю быстрый ответ, второй может выполняться позже в очереди. Libavif хорошо подходит для такой архитектуры, потому что команда полностью описывается параметрами и легко воспроизводится.

Интеграция Libavif в приложение через C API

Когда библиотека лучше командной строки

CLI удобен для скриптов, но собственному приложению не обязательно запускать отдельный процесс. C API позволяет передавать данные в памяти, управлять декодером и энкодером программно, получать диагностические коды и избегать временных файлов. Это особенно важно для серверов изображений, мобильных приложений, плагинов и медиаконвейеров с большим числом операций.

Типичный путь декодирования состоит из создания avifDecoder, настройки лимитов и желаемого содержимого, передачи данных через IO, разбора контейнера, получения кадра и преобразования YUV в RGB через avifRGBImage. После использования объекты и буферы освобождаются функциями Libavif. У кодирования обратная логика: создаётся avifImage, заполняются плоскости и метаданные, настраивается avifEncoder, после чего получается закодированный AVIF.

Не следует строить интеграцию вокруг внутренних структур из src/. Публичный API объявлен в устанавливаемых заголовках, а внутренние функции могут меняться без совместимости. Если требуется возможность, которой нет в публичном API, безопаснее сначала проверить актуальную версию и историю изменений, чем подключать приватный символ.

avifImage и представление пикселей

avifImage хранит ключевые свойства изображения: размеры, глубину, YUV-формат, диапазон, CICP, ICC, Exif, XMP, альфа-плоскость и дополнительные свойства контейнера. Для RGB-приложения обычно используется промежуточная структура avifRGBImage, которая описывает формат RGBA/BGRA и буфер. Функции преобразования переводят между RGB и YUV.

Точка, где RGB превращается в YUV, критична для качества. Здесь выбираются субдискретизация, матрица, глубина и способ chroma downsampling. Если приложение получает уже готовый YUV-поток, лишнее преобразование через RGB может дать ненужную потерю и нагрузку. Именно поэтому avifenc сохраняет Y4M-параметры, а библиотека позволяет работать ближе к исходному представлению.

avifEncoder

Энкодер содержит параметры качества, скорости, числа потоков, интервала ключевых кадров, тайлинга и выбора кодека. Программная интеграция позволяет задавать эти значения на каждый запрос, но в сервисе лучше ограничить допустимые диапазоны. Если клиент API сможет попросить speed 0, гигантское разрешение и много кадров, один запрос способен занять значительный CPU.

Для последовательностей кадры добавляются с длительностью и флагами. В layered-сценариях учитываются дополнительные слои. Финализация контейнера выполняется после добавления данных. Ошибки необходимо преобразовывать в понятные сообщения приложения: общий «encode failed» скрывает полезную диагностику о несовместимом формате, отсутствии кодека или нарушении ограничений.

avifDecoder

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

При работе с последовательностью приложение вызывает переход к следующему изображению и отслеживает тайминг. Для still image этот цикл обычно содержит один кадр. Если файл может быть прогрессивным или содержать gain map, приложение должно решить, какие дополнительные элементы ему нужны, а какие можно не декодировать ради производительности.

Потоковый ввод и собственный avifIO

API не ограничен файлом на диске. Интерфейс IO позволяет приложению читать данные из памяти или через собственный источник. Это полезно для HTTP, архивов, виртуальных файловых систем и баз данных. Но «потоковый» доступ не означает, что любой AVIF можно полностью отобразить до получения конца файла: возможность частичного чтения зависит от структуры контейнера и порядка данных.

При реализации собственного IO нужно строго соблюдать требования к сроку жизни буферов и обработке смещений. Ошибки в этом слое выглядят как повреждённый AVIF, хотя проблема фактически находится в callback приложения. Для отладки полезно сначала декодировать тот же набор байтов через стандартный file/memory путь.

Сборка Libavif из исходников

Базовая схема CMake

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

cmake -S libavif -B libavif/build 
  -DAVIF_CODEC_AOM=SYSTEM 
  -DAVIF_BUILD_APPS=ON
cmake --build libavif/build --config Release --parallel

Конкретные имена флагов зависят от ветки, поэтому перед автоматизацией сверяйте CMakeLists текущего выпуска. Не копируйте команду сборки из старого README без проверки: Libavif менял минимальные требования к CMake и языковому стандарту, а некоторые экспериментальные флаги со временем исчезали после стабилизации функции.

SYSTEM и LOCAL зависимости

Режим SYSTEM использует библиотеку, установленную в системе. Это удобно для дистрибутивов, где обновления безопасности и ABI управляются пакетным менеджером. Режим LOCAL подтягивает или собирает версию, закреплённую проектом, что повышает воспроизводимость и упрощает сборку на CI, но увеличивает время и размер дерева зависимостей.

Смешанный подход тоже нормален: например, системный libjpeg/libpng и локальный libaom. Главное — фиксировать конфигурацию. Два файла avifenc с одинаковым номером Libavif могут вести себя по-разному, если один собран с dav1d и SVT-AV1, а другой — только с AOM.

Почему приложения могут не собраться

Сама библиотека может быть собрана в минимальной конфигурации, а консольные утилиты требуют дополнительных компонентов для чтения PNG/JPEG и вспомогательных операций. Если AVIF_BUILD_APPS выключен, отсутствие avifenc — ожидаемый результат. Если приложения включены, но отключены обязательные JPEG/PNG-зависимости, конфигурация CMake завершится ошибкой.

Для gain map преобразования из некоторых JPEG требуется XML-библиотека. Без неё основной AVIF-кодек продолжит работать, но конкретная функция с gain map будет недоступна или игнорироваться. Это следует отражать в сборочной документации продукта, чтобы операционная команда не считала такую разницу «случайным багом сервера».

Статическая и динамическая линковка

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

После сборки не ограничивайтесь запуском --version. Прогоните тесты проекта и несколько реальных файлов: RGB, RGBA, 10/12-бит, 4:2:0/4:4:4, последовательность, если она нужна. Такой smoke test обнаруживает проблемы, которые компоновщик не видит.

Типичные ошибки avifenc и способы их устранения

«unrecognized option»

Сообщение о неизвестном параметре почти всегда означает несовпадение инструкции и установленной версии. Сначала выполните avifenc --version, затем avifenc --help. Если ключ отсутствует в справке, не пытайтесь менять порядок аргументов — этой функции в сборке нет. Особенно часто так происходит с относительно новыми режимами gain map, layered AVIF и Sample Transform.

Запрошенный codec не доступен

Если команда с --codec svt, --codec rav1e или другим вариантом не запускается, проверьте список в --help/--version. Решение — установить пакет с нужной поддержкой либо пересобрать Libavif. Переименование кодека в команде не поможет, потому что библиотека должна быть реально слинкована с соответствующей реализацией.

Файл уже существует

При использовании --no-overwrite существующий результат считается ошибкой. Это нормальная защита. В пакетном сценарии решите, чего вы хотите: пропустить файл, удалить старый результат после проверки либо сохранить новую версию под другим именем. Не убирайте флаг автоматически, если каталог содержит ценные результаты предыдущего прогона.

Неподдерживаемый входной формат

TIFF, WebP, BMP и RAW нельзя передать в avifenc как обычный файловый вход. Приведите исходник к PNG/JPEG/Y4M или используйте другой конвертер/собственную интеграцию. Если важны 16-битные данные, не переходите через восьмибитный JPEG: выбирайте промежуточный формат, сохраняющий нужную точность и цветовой профиль.

Lossless выдаёт предупреждение или отказывается работать

Проверьте YUV-схему, диапазон, глубину и выбранный кодек. Для RGB без потерь обычно нужен 4:4:4 и полный диапазон; 4:2:0 уже означает потерю цветовой информации. Rav1e в некоторых конфигурациях не поддерживает lossless режим так, как ожидает avifenc, и программа может отклонить такую комбинацию. Используйте поддерживаемый кодек и не смешивайте --lossless с противоречащими ему quality/quantizer-настройками.

Y4M и —depth не совпадают

Для Y4M глубина берётся из входа. В актуальной стабильной ветке avifenc отклоняет несовпадающий --depth вместо тихого преобразования. Если нужно изменить глубину, сделайте это на стадии подготовки Y4M и передайте в Libavif уже согласованный поток.

Цвет после конвертации отличается

Проверьте ICC, CICP, range и chroma subsampling. Затем сравните декодирование разными клиентами. Если avifdec и один браузер показывают одинаково, а системный просмотрщик — иначе, возможно, проблема находится в поддержке конкретного профиля или YUV-режима клиентом. Не исправляйте цвет только изменением -q: качество кодирования не задаёт цветовое пространство.

Если исходник содержит ICC, убедитесь, что вы не использовали --ignore-profile. Если CICP задан вручную, проверьте правильность чисел. Для sRGB-пайплайна полезно сначала привести все входы к одному известному профилю внешним цветоуправляемым инструментом, а затем кодировать AVIF.

На краях прозрачности появился ореол

Сначала увеличьте качество альфы и проверьте 4:4:4. Затем выясните, straight или premultiplied alpha ожидает ваш конвейер. Не включайте --premultiply как случайный эксперимент без понимания источника. Для диагностики декодируйте в PNG и сравните наложение на разные фоны.

Анимация идёт слишком быстро или слишком медленно

Проверьте --timescale и --duration. Duration измеряется в единицах timescale, поэтому изменение одного параметра меняет реальное время кадра. Если команда использует обновляемые параметры, убедитесь, что --duration расположен перед теми входами, к которым должен применяться.

avifdec отказывается декодировать файл

Сначала запустите avifdec --info. Если срабатывает строгая проверка, --no-strict можно использовать только для диагностики. Если ошибка связана с лимитом размеров, оцените доверенность файла и память перед изменением --size-limit или --dimension-limit. Если не доступен нужный AV1-декодер, выберите другой из списка сборки.

Большой файл кодируется медленно и плохо масштабируется по потокам

Проверьте --jobs, --speed и тайлинг. Автоматический тайлинг обычно является хорошей отправной точкой. Если процесс запускается внутри уже параллельной очереди, уменьшите число внутренних потоков. Также исключите --target-size, если он не нужен: дополнительные проходы могут доминировать во времени.

Gain map из JPEG не переносится

Возможны две основные причины: формат gain map не распознаётся или сборка не содержит зависимости, необходимой для чтения соответствующих метаданных. Проверьте вывод версии, конфигурацию сборки и отдельные команды avifgainmaputil printmetadata/convert. Не пытайтесь «починить» такой файл простым --ignore-gain-map, если цель как раз состоит в сохранении HDR-представления: этот ключ намеренно отбрасывает карту.

Ошибки процесса, которые не являются багами Libavif

Первая типичная ошибка — кодировать уже низкокачественный JPEG в AVIF и затем оценивать артефакты как недостаток AVIF. Новый кодек не восстанавливает детали, потерянные в исходнике. Если возможно, начинайте с мастер-файла или PNG/RAW-конвертации высокого качества.

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

Третья — тестировать только один просмотрщик. AVIF имеет богатую цветовую и контейнерную семантику, а поддержка клиентов развивается неравномерно. Для веба минимум нужен реальный набор браузеров и устройств проекта; для архивов — декодер, которым файлы будут извлекаться позже.

Четвёртая — использовать новый параметр из main-ветки с последним стабильным бинарником. Документация репозитория по умолчанию может описывать ещё не выпущенные изменения. Для воспроизводимого процесса открывайте документацию по тегу используемой версии.

Практический сценарий: подготовка фотографий для сайта

Начните с корректно обработанного мастер-файла: кадрирование, экспозиция и цвет должны быть завершены до Libavif. Если мастер — TIFF или RAW, экспортируйте промежуточный PNG/JPEG подходящей глубины и профиля. Затем создайте несколько AVIF с разными -q при фиксированных -s и -y 420. Сравните их при целевом CSS-размере и при 100% масштабе.

После выбора качества проверьте цвет в браузерах, удалите ненужные Exif/XMP, если это соответствует политике сайта, и измерьте итоговый размер. Для responsive images лучше повторить процесс на нескольких разрешениях, чем кодировать огромный исходник и заставлять браузер масштабировать его на клиенте.

avifenc -q 70 -s 6 -y 420 --ignore-exif --ignore-xmp hero-1600.png hero-1600.avif

На следующем этапе декодируйте один файл через avifdec и сравните с исходником. Это отделяет проблему кодирования от проблемы отображения в браузере. Если результат декодирования корректен, а браузер отличается, исследуйте поддержку профиля и параметры HTTP/HTML, а не энкодер.

Практический сценарий: скриншоты и интерфейсная графика

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

avifenc -q 82 -s 6 -y 444 screenshot.png screenshot.avif

Если скриншот содержит прозрачность, отдельно увеличьте --qalpha. Если он состоит преимущественно из плоских цветов, сравните AVIF не только с JPEG, но и с оптимизированным PNG/WebP: для некоторых синтетических изображений преимущество форматов меняется.

Практический сценарий: прозрачные PNG-ресурсы

Для иконок и декоративных элементов важны три вещи: 4:4:4, качество альфа-канала и корректная модель premultiplication. Начните со straight alpha без --premultiply, если исходный PNG обычный. Подберите качество цвета отдельно от альфы и проверяйте результат на нескольких фонах.

avifenc -q 75 --qalpha 100 -y 444 asset.png asset.avif

Если размер получается слишком большим, уменьшайте --qalpha постепенно и смотрите именно на края, а не на центр объекта. Иногда небольшой дефект маски визуально неприятнее, чем заметное снижение качества внутри текстуры.

Практический сценарий: автоматизация в CI

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

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

Практический сценарий: архивный lossless

Если цель — долговременное хранение без потерь, сначала определите, что именно должно быть сохранено: пиксели, цветовой профиль, Exif/XMP, ориентация и прозрачность. Затем используйте --lossless и после кодирования декодируйте в формат, способный представить исходную глубину. Сравнение только визуально недостаточно — для критичных данных нужен программный контроль пикселей и метаданных.

Также учитывайте экосистему декодирования. Формат может быть технически корректен, но архив ценен только при наличии надёжных декодеров и документированной процедуры восстановления. Хранение исходного мастер-файла вместе с AVIF часто рациональнее, чем замена единственного архива на новый контейнер ради экономии места.

Практический сценарий: создание анимированного AVIF

Подготовьте кадры одинакового размера и цветового пространства. Решите, нужна ли постоянная частота. Если да, задайте timescale и одинаковую duration. Если нет, для каждого участка меняйте duration перед соответствующими входами. После кодирования извлеките все кадры через avifdec --index all и проверьте порядок, качество и число кадров.

Далее протестируйте повторение и поддержку в целевых клиентах. Анимированный AVIF поддерживается не тем же набором программ, что одиночный still AVIF. Если аудитория включает устаревшие приложения, понадобится fallback.

Практический сценарий: HDR с gain map

Начните с пары согласованных SDR/HDR изображений или поддерживаемого JPEG gain map. Проверьте профили и CICP ещё до combine. Создайте AVIF, затем отдельно извлеките метаданные карты и визуализируйте её. После этого проверьте базовое SDR-представление на клиенте без gain map и HDR-результат на совместимом дисплее.

Если различия выглядят как изменение оттенка, а не только яркости, исследуйте цветовые пространства base/alternate. Если появляются локальные ореолы, оцените качество карты и пространственное совпадение двух исходников. Такой сценарий требует больше контроля, чем обычное -q 75, и его не следует внедрять без набора HDR-регрессионных файлов.

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

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

Утилита также не является универсальным входным конвертером. Прямой файловый вход ограничен JPEG, PNG и Y4M. Если процесс начинается с RAW, TIFF, PSD или WebP, нужен дополнительный этап. Это ограничение иногда воспринимают как недостаток, но оно одновременно делает назначение avifenc ясным: инструмент сосредоточен на AVIF и не дублирует большой набор декодеров общего назначения.

Наконец, Libavif не гарантирует одинаковое отображение любого сложного AVIF во всех приложениях. Контейнер позволяет хранить 10/12-битный цвет, 4:4:4, HDR, gain map, grid, последовательности и трансформации, а поддержка этих возможностей у клиентов различается. Ответственность за матрицу совместимости остаётся у автора контента.

Совместимость и проверка целевой среды

Для обычных восьмибитных still AVIF с распространённой цветовой разметкой поддержка сегодня широка, но это не означает, что можно игнорировать конкретный набор клиентов проекта. Чем дальше файл уходит от базового сценария — 12 бит, 4:4:4, сложный ICC, animation, grid, layered или gain map, — тем важнее реальное тестирование.

Для веб-проекта проверяйте браузеры и устройства, которые действительно встречаются в аналитике, а не абстрактный список «поддерживает AVIF». Для приложения фиксируйте версию декодирующей библиотеки. Для серверной инфраструктуры держите тесты чтения после каждого обновления зависимости. Если AVIF отдаётся через CDN или оптимизатор, отдельно убедитесь, что промежуточный сервис не перекодирует файл с другими параметрами.

В диагностике полезно сохранить эталонный набор: обычный RGB, прозрачный RGBA, 4:2:0, 4:4:4, 10-битный файл, анимированную последовательность и HDR-файл, если эти функции используются. После обновления Libavif или клиентского декодера такой набор быстро показывает регрессию.

Безопасность при обработке чужих AVIF

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

На сервере запускайте декодирование с ограничениями CPU, памяти и времени, особенно если разрешены последовательности. Один файл может содержать много кадров и быть существенно дороже обычной фотографии. Для публичной загрузки полезна изоляция процесса и обновление Libavif и AV1-декодеров при выходе исправлений безопасности.

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

Сравнение с аналогами

Libavif логично сравнивать не только с фоторедакторами, но и с инструментами того же технологического уровня. ФотоМАСТЕР решает задачу подготовки и художественной правки фотографии, тогда как Libavif занимается кодированием, декодированием и интеграцией AVIF. Более прямые альтернативы — libheif с утилитами heif-enc/heif-dec и ImageMagick, который умеет читать и писать AVIF при наличии соответствующего delegate. Поэтому выбор зависит от того, где именно находится задача: до кодирования, в самом AVIF-контейнере или в универсальной цепочке преобразований.

Libavif и ФотоМАСТЕР

ФотоМАСТЕР полезен на стадии, когда изображение ещё нужно улучшить глазами: скорректировать тон и цвет, ретушировать портрет, удалить лишний объект, заменить фон, добавить текст или подготовить фотографию из RAW. Libavif начинается там, где визуальная редактура уже закончена. Он не знает, что на снимке лицо или небо, зато позволяет явно выбрать глубину, YUV-схему, альфу, codec, metadata и структуру AVIF.

Поэтому эти продукты чаще дополняют, чем заменяют друг друга. Фотограф может обработать кадр в ФотоМАСТЕР, экспортировать мастер в подходящий растровый формат, а затем автоматизированный скрипт создаст AVIF для сайта. Обратный порядок не имеет смысла: перекодирование в AVIF не выполняет ретушь и не улучшает исходную композицию.

Libavif и libheif

libheif — наиболее близкая по уровню альтернатива. Она работает не только с AVIF, но и с широким семейством HEIF-вариантов: HEIC/HEVC, AVIF/AV1, VVC, AVC, JPEG/JPEG 2000 и несжатым представлением в зависимости от сборки. Её heif-enc принимает больше типов входов, включая TIFF, WebP и raw pixel data, а heif-info умеет показывать структуру HEIF-контейнера.

Libavif, напротив, сфокусирован на AVIF и предоставляет очень прямое соответствие между спецификой AVIF и параметрами avifenc/avifdec. Если приложение должно поддерживать только AVIF и нужен небольшой специализированный API, такая специализация удобна. Если один и тот же проект работает одновременно с HEIC, AVIF и другими HEIF-кодеками, libheif может сократить число зависимостей и дать единый контейнерный API.

Обе библиотеки используют внешние реализации кодеков и могут отличаться возможностями в зависимости от конфигурации сборки. Поэтому сравнивать их только по названию пакета неправильно: нужно смотреть, какие encoder/decoder plugins реально включены и какие функции требуются проекту.

Libavif и ImageMagick

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

Преимущество Libavif — более прямой доступ к специфике AVIF: layered/progressive, параметры последовательности, grid, отдельная работа с gain map, низкоуровневые свойства и C API, ориентированный именно на формат. Преимущество ImageMagick — универсальность графического конвейера. В реальной автоматизации они часто стоят рядом: ImageMagick подготавливает пиксели, Libavif выполняет финальное AVIF-кодирование.

Как выбирать между вариантами

• Нужна ручная коррекция и ретушь — сначала используйте фоторедактор вроде ФотоМАСТЕР.
• Нужно встроить именно AVIF-кодирование/декодирование в C/C++ — Libavif естественно соответствует задаче.
• Нужны одновременно HEIC, AVIF и другие HEIF-варианты — стоит рассмотреть libheif.
• Нужно читать множество форматов и выполнять сложные пакетные растровые операции — удобнее ImageMagick, при необходимости с Libavif на финальном этапе.
• Нужны точные эксперименты с AVIF-параметрами, sequence, grid или gain map — Libavif даёт наиболее предметный CLI.

Как составить собственный профиль avifenc

Начните не с двадцати ключей, а с трёх: -q, -s и -y. На репрезентативной выборке найдите качество, которое устраивает визуально, затем выберите скорость с учётом CPU, затем решите, допустима ли 4:2:0. После этого добавляйте остальные параметры только при наличии конкретной причины: --qalpha для прозрачности, --ignore-exif для политики приватности, CICP для управляемого цветового процесса, target-size для жёсткого лимита.

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

Не перегружайте команду codec-specific параметрами без измеримого эффекта. Чем больше скрытых настроек, тем сложнее обновлять кодек и объяснять поведение. Стандартные -q, -s, -j, -y и автоматический тайлинг покрывают большинство задач.

Частые вопросы

Можно ли пользоваться Libavif без программирования?

Да. avifenc, avifdec и avifgainmaputil работают как самостоятельные консольные программы. Программирование требуется только для собственной интеграции через C API или для сложной автоматизации, хотя простые пакетные сценарии решаются PowerShell или shell.

Есть ли у Libavif графическое окно?

Нет. Официальные пользовательские инструменты — командные. Если нужен визуальный редактор, изображение готовят в отдельной программе, а Libavif используют как кодировщик/декодировщик. Графические оболочки третьих сторон нельзя считать частью Libavif.

Какое значение -q лучше для сайта?

Универсального числа нет. Типичный диапазон в справке — примерно 60–80, но фотография, текстовый скриншот и прозрачная графика ведут себя по-разному. Выберите 3–5 значений на реальной выборке, сравните при одинаковом разрешении и зафиксируйте отдельные профили хотя бы для фотографий и UI.

Нужно ли всегда ставить 10 или 12 бит?

Нет. Большая глубина полезна, когда исходник и последующий процесс действительно содержат дополнительную точность или HDR. Перекодирование обычного восьмибитного JPEG в 12 бит не возвращает потерянные уровни. Кроме того, высокобитные режимы нужно проверять на целевых декодерах.

Что выбрать: 4:2:0 или 4:4:4?

Для фотографий 4:2:0 часто даёт хорошую экономию. Для скриншотов, цветного текста, схем и мелкой графики безопаснее начинать с 4:4:4. 4:2:2 занимает промежуточное положение. Решение принимают по реальному содержимому и совместимости клиентов.

Чем —lossless отличается от -q 100?

-q 100 делает цветовую часть lossless на уровне соответствующего параметра, но другие преобразования всё ещё могут терять информацию. --lossless согласует набор настроек и предупреждает о несовместимых условиях — например, о субдискретизации или диапазоне. Для проверки истинной идентичности всё равно полезно выполнить обратное декодирование и сравнить пиксели.

Можно ли открыть WebP напрямую через avifenc?

Нет, стандартный файловый вход avifenc — JPEG, PNG и Y4M. WebP сначала преобразуют в подходящий промежуточный формат или используют универсальный инструмент/библиотеку, которая поддерживает оба формата.

Как удалить метаданные при публикации?

Для Exif и XMP используйте --ignore-exif и --ignore-xmp. Цветовой профиль не следует удалять автоматически: --ignore-profile влияет на корректность цветопередачи и нужен только в контролируемом цветовом процессе.

Можно ли сделать анимированный AVIF?

Да. Передайте несколько входных кадров и настройте timescale, duration, keyframe и repetition count. После кодирования проверьте все кадры через avifdec --index all и обязательно протестируйте целевые клиенты, потому что поддержка анимации отличается от поддержки обычного AVIF.

Зачем нужен —target-size, если есть -q?

-q задаёт качество, а итоговый размер зависит от изображения. --target-size решает обратную задачу: пытается приблизиться к заданному числу байтов, выполняя дополнительный поиск. Режим заметно медленнее и не гарантирует визуально приемлемый результат при слишком жёстком лимите.

Как понять, какой AV1-кодек используется?

Посмотрите avifenc --version и --help. Если кодек не указан явно, Libavif выбирает доступный вариант автоматически. Для воспроизводимого сравнения задавайте --codec и фиксируйте сборку.

Почему команда из интернета не работает?

Чаще всего она написана для другой версии. Документация main-ветки может содержать ещё не выпущенные ключи, а старые статьи — уже изменившиеся параметры. Проверяйте справку именно установленной версии и документацию соответствующего тега.

Нужно ли включать —no-strict для совместимости?

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

Подходит ли Libavif для очень больших изображений?

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

Что использовать для HDR: просто 10 бит или gain map?

Это разные подходы. Высокобитный HDR хранит HDR-сигнал непосредственно, а gain map позволяет совместить базовое представление и дополнительную информацию для адаптации яркости. Выбор зависит от источника, целевых клиентов и требований к обратной совместимости. Libavif поддерживает оба уровня, но gain map требует более сложной проверки.

Итоговая схема работы

Для обычного пользователя Libavif сводится к понятной последовательности: подготовить исходное изображение в редакторе, проверить цветовой профиль и глубину, выбрать -q/-s/-y, закодировать через avifenc, проверить свойства и декодированный результат через avifdec, затем протестировать целевые клиенты. Для прозрачности добавляется отдельный контроль --qalpha; для анимации — тайминг и кадры; для HDR — цветовая разметка и gain map.

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

Если нужна ретушь, RAW-проявка или замена фона, сначала выбирают графический редактор. Если требуется универсальная конвертация десятков форматов — ImageMagick или libheif могут быть удобнее на входе. Если же задача состоит именно в создании, чтении, исследовании или программной поддержке AVIF, Libavif даёт наиболее прямой набор инструментов для работы с форматом без лишнего интерфейсного слоя.