Oxipng: оптимизация и сжатие PNG из командной строки

Oxipng нужен тогда, когда готовые PNG- и APNG-файлы требуется сделать компактнее без обычного для JPEG или WebP снижения визуального качества. Утилита перебирает варианты PNG-фильтрации и DEFLATE-сжатия, умеет безопасно сокращать представление цвета и глубины, удалять выбранные служебные блоки, обрабатывать целые каталоги и работать в автоматических сборках. Это практичный инструмент для веб-разработчиков, авторов документации, разработчиков приложений и игр, инженеров CI/CD и всех, у кого уже есть готовая растровая графика и важно оставить итог именно в PNG. При этом Oxipng не является фоторедактором: он не ретуширует снимки, не меняет композицию, не кадрирует и не рисует поверх изображения.

Что именно делает Oxipng с PNG-файлом

PNG хранит изображение не как один непрерывный «сжатый кадр», а как набор структурированных блоков. В критических блоках находятся параметры изображения и собственно сжатые данные пикселей, в дополнительных — цветовые профили, физическое разрешение, текстовые поля, данные анимации и другая служебная информация. Один и тот же визуальный результат может быть записан разными способами: с различной глубиной цвета, разным типом цветового представления, разными строковыми фильтрами и разными параметрами DEFLATE. Поэтому два PNG с одинаковыми пикселями способны заметно отличаться по размеру.

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

Oxipng ищет более компактное представление. В обычном режиме программа сначала анализирует структуру изображения, затем при необходимости пробует безопасные преобразования, после чего оценивает несколько вариантов фильтрации строк и повторно сжимает IDAT. Если новый файл не выигрывает по размеру, утилита по умолчанию не обязана переписывать исходник более крупным результатом. Это отличает оптимизацию от конвертации: формат остаётся PNG, а основная цель — уменьшить служебный и сжатый объём без изменения того, что пользователь видит на экране.

Термин «lossless» для Oxipng нужно понимать точно. Базовые операции — подбор фильтров, повторное DEFLATE-сжатие и те сокращения цветового представления, которые доказуемо не меняют значения отображаемых пикселей, — без потерь. Но в программе есть отдельные опции, которые сознательно выходят за эту границу. --alpha может менять RGB-компоненты полностью прозрачных пикселей: внешний вид не меняется, однако байтовые значения невидимой части изображения уже не идентичны исходным. --scale16 принудительно переводит 16-битные на канал данные в 8-битные и является обычным lossy-преобразованием. Поэтому безопасный производственный профиль строят не вокруг лозунга «всё всегда без потерь», а вокруг понимания конкретных флагов.

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

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

Oxipng — консольная утилита. После установки команда oxipng должна быть доступна из терминала. На Windows это обычно означает, что исполняемый файл находится в каталоге, указанном в PATH, либо команда запускается из папки с самим файлом. На macOS и Linux программу обычно устанавливают через доступный пакетный менеджер дистрибутива; альтернативный путь — установка из Cargo. Для разработки или сборки под нестандартную платформу можно собрать проект из исходного кода на Rust. Отдельный графический запуск с главным окном не предусмотрен.

Первую проверку стоит делать не на рабочей папке, а на копии одного PNG. Команда oxipng test.png запускает стандартный профиль оптимизации. Если имя содержит пробелы, путь заключают в кавычки: oxipng "screen shot.png". Для контроля установленной версии используется oxipng --version, а для просмотра полного набора параметров — oxipng --help. Важность встроенной справки выше обычного: у Oxipng несколько раз менялись имена ключей, поэтому старые инструкции из интернета могут не совпадать с актуальной командной строкой.

Самый безопасный первый эксперимент — oxipng --dry-run test.png. В этом режиме программа выполняет оценку, но не записывает файл. Так можно увидеть потенциальную экономию и одновременно убедиться, что путь, права доступа и само изображение обрабатываются корректно. После этого имеет смысл запускать обычный режим либо задавать отдельный выходной файл через --out. Для критичных оригиналов, которые нельзя перезаписывать, отдельный путь выхода предпочтительнее работы «на месте».

Если используется Cargo, команда установки выглядит как cargo install oxipng. Этот вариант удобен разработчикам, у которых Rust уже установлен и обновляется вместе с остальным инструментарием. Если Rust нужен только ради одной утилиты, готовый бинарный пакет обычно проще: не требуется держать компилятор и зависимости. Для контейнерных сборок существует официальный образ, поэтому Oxipng можно запускать в изолированной среде и монтировать каталог с ассетами внутрь контейнера. В рабочем проекте важно зафиксировать способ установки, чтобы локальная машина и CI не использовали случайно разные поколения CLI.

Синтаксис команды и выбор входных файлов

Базовая форма команды — oxipng [OPTIONS] <files>.... После параметров передают один или несколько файлов. Несколько путей можно перечислить подряд, а оболочка терминала может раскрывать шаблоны вроде *.png. Здесь есть платформенное отличие: в Unix-подобных оболочках звёздочку обычно разворачивает shell до запуска программы, тогда как на Windows обработка шаблона может зависеть от того, как именно запущена команда. Если пакетная операция должна быть воспроизводимой, лучше не полагаться на сложные неочевидные шаблоны, а использовать понятный список файлов или рекурсивный режим.

Аргумент - обозначает стандартный ввод. Это позволяет встроить Oxipng в конвейер, где PNG поступает не с диска, а от другой программы. В таком сценарии нужно заранее определить и выход: например, отправить результат в стандартный вывод через --stdout и перенаправить поток в новый файл. Потоковая схема удобна в Unix-конвейерах, но менее наглядна для ручной работы, поэтому для обычной пакетной оптимизации проще оперировать файлами и каталогами.

Если передаётся каталог, сам по себе он не означает автоматический обход дерева. Для рекурсивной обработки используется -r или --recursive. В этом режиме Oxipng проходит по каталогам и выбирает файлы с расширением .png или .apng. Это полезно для репозитория с ассетами, но перед запуском на большом дереве надо решить, куда писать результат и нужно ли сохранять исходники. Рекурсивный режим не является системой резервного копирования.

Отдельный нюанс — набор файлов, который реально увидит команда. Если shell разворачивает шаблон, в аргументы могут попасть только файлы текущего каталога. Если требуется поддерево, добавляют --recursive. Если в каталоге есть очень много крупных изображений, одновременная обработка может заметно расходовать память: Oxipng параллелит и файлы, и часть внутренних испытаний. В таком случае вместо изменения уровня оптимизации в первую очередь полезно ограничить --threads или включить --sequential.

Куда записывается результат

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

Отдельный файл через —out

--out <file> задаёт конкретное имя результата. Режим удобен для одиночного PNG, когда нужно сравнить исходник и оптимизированную версию. Например: oxipng -o 4 --out optimized.png source.png. Так проще проверить размер, метаданные, цвет и корректность отображения несколькими просмотрщиками. Для массовой обработки один фиксированный --out не заменяет каталог назначения.

Каталог назначения через —dir

--dir <directory> направляет результаты в указанный каталог; если его нет, Oxipng может создать его. Но есть существенное ограничение: при сочетании --dir с --recursive структура исходных подкаталогов не сохраняется. Иными словами, дерево assets/icons/a.png и assets/screens/a.png может привести к конфликту имён, если оба результата складываются в один плоский каталог. Поэтому такой режим безопасен только тогда, когда имена уникальны или вывод организован внешним скриптом по подкаталогам.

Стандартный вывод

--stdout отправляет итоговый PNG в стандартный вывод. Важное правило: служебный текст и бинарные данные нельзя бездумно смешивать в одном канале. Если команда используется в конвейере, лучше подавить лишние сообщения через --quiet и корректно перенаправить поток. В обычной работе --stdout нужен главным образом для автоматизации, когда промежуточный файл создавать нежелательно.

Сохранение атрибутов

-p или --preserve старается сохранить разрешения файла и временные метки. Это важно в сборках, где лишнее изменение времени модификации вызывает повторную публикацию или ненужный diff. При этом сохранение атрибутов не означает сохранение всех PNG-метаданных: за внутренние chunks отвечают --strip и --keep. Файловая система и содержимое PNG — два разных уровня.

Уровни оптимизации -o 0…6 и max

Параметр -o задаёт готовый профиль. Диапазон — от 0 до 6; max является стабильным псевдонимом максимального уровня. Стандартный профиль — -o 2. Низкие уровни делают меньше попыток и подходят для частых запусков, высокие пробуют больше фильтров и более тяжёлые настройки. Важно, что шкала не является линейным процентом качества или степени сжатия: -o 6 не означает «в три раза сильнее», чем -o 2.

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

Если вручную указать низкоуровневую настройку сжатия — например, список фильтров через -f или уровень --zc — она переопределяет соответствующую часть пресета независимо от порядка аргументов. Поэтому команда oxipng -o 4 --zc 10 file.png уже не является «чистым уровнем 4». Это важно при отладке: если сравниваются пресеты, убирают все ручные параметры, иначе результаты относятся к разным конфигурациям.

Для веб-ассетов практичным исходным вариантом остаётся -o 4 --strip safe, если метаданные не нужны, а прозрачность не требует специального обращения. Для очень частого pre-commit запуска разумнее -o 2 или даже более быстрый профиль, чтобы оптимизация не раздражала разработчиков задержкой. Финальный релизный пайплайн может позволить себе более тяжёлый уровень. Такой двухступенчатый подход даёт больше пользы, чем постоянный запуск максимума на каждом сохранении файла.

PNG-фильтры и параметр —filters

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

Oxipng нумерует стратегии от 0 до 9. Значения 0–4 соответствуют базовым PNG delta-фильтрам: None, Sub, Up, Average и Paeth. Стратегии 5–9 — эвристики, которые выбирают фильтр по строкам: MinSum, Entropy, Bigrams, BigEnt и Brute. Последняя ориентируется на минимальный сжатый размер и поэтому заметно тяжелее. В обычной работе пользователю не нужно вручную перечислять их: пресеты -o уже задают подходящий набор.

Ручной список задаётся через -f или --filters. Можно перечислить номера через запятую или диапазон, например -f 0-3. Нулевой фильтр разработчики рекомендуют обычно оставлять среди вариантов, поскольку на некоторых изображениях отсутствие предобработки оказывается лучшим. Если пользователь вручную исключил удачную стратегию, более высокий -o не вернёт её автоматически: явный список фильтров переопределяет пресет.

Флаг --fast меняет способ оценки фильтров. Программа делает быструю оценку каждого включённого варианта, затем проводит один основной прогон для победителя. На низких и средних уровнях такой режим входит в пресеты; на уровне 5 и выше он по умолчанию не используется. Это объясняет, почему переход к высоким уровням может резко увеличивать время: программа перестаёт ограничиваться дешёвой предварительной оценкой и делает больше полных испытаний.

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

DEFLATE, —zc и Zopfli

После фильтрации данные PNG сжимаются алгоритмом DEFLATE. В стандартных испытаниях Oxipng использует libdeflate и позволяет задавать уровень через --zc в диапазоне 0–12. Чем выше число, тем больше вычислительная работа, но выигрыш быстро уменьшается. Пресеты уже выбирают свои значения --zc, поэтому ручная настройка нужна в основном для специализированных тестов и для сохранения совместимости с внутренними профилями команды.

Отдельный режим -z или --zopfli переключает основные испытания на Zopfli. Zopfli значительно медленнее, потому что тратит намного больше времени на поиск эффективного DEFLATE-представления. Он полезен, когда один раз оптимизируется небольшой набор часто раздаваемых статических файлов, а время сборки не критично. Для локального цикла редактирования, большого каталога скриншотов или обработки пользовательских загрузок такой режим обычно слишком дорог.

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

Количество итераций Zopfli задаёт --zi; стандартное значение — 15. Уменьшение числа итераций ускоряет крупные файлы. --ziwi позволяет прекратить Zopfli после заданного числа итераций без улучшения и полезен вместе с высоким --zi: вместо жёсткого фиксированного перебора компрессор останавливается, когда прогресс исчезает. Это способ ограничить худший случай, не отказываясь от более глубокого поиска на файлах, где он действительно приносит пользу.

Для стратегии Brute имеются --brute-level и --brute-lines. Первый задаёт уровень libdeflate для оценки, второй — сколько строк сжимать вместе при поиске. Разработчики отмечают разумные диапазоны и отдельно предупреждают, что «больше» не обязательно означает «лучше». Эти флаги относятся к лабораторной тонкой настройке. В статье команды или в build-скрипте их стоит оставлять только тогда, когда есть задокументированный бенчмарк именно на своих ассетах.

Сокращение глубины цвета и типа изображения

Сильная сторона PNG-оптимизаторов — возможность уменьшить не только поток DEFLATE, но и само представление пикселей без визуальных потерь. Если картинка формально хранится как 24-битный RGB, но фактически содержит только оттенки серого, её можно представить компактнее. Если канал альфа везде полностью непрозрачен, его можно убрать. Если значения 16-битного канала фактически укладываются в представление меньшей глубины без потери информации, глубину можно сократить. Oxipng выполняет такие reductions, когда они доказуемо безопасны.

Для контроля существуют флаги запрета. --nb запрещает менять bit depth, --nc — color type, --np — перевод в индексированное представление и изменение существующей палитры, --ng — переход к grayscale или из него. Они нужны, когда потребитель PNG предъявляет нестандартные требования к внутренней структуре. Например, старый движок может ожидать RGBA, даже если формально alpha не нужен, либо тесты проекта сравнивают тип цвета, а не только визуальный результат.

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

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

Прозрачность и параметр —alpha

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

Но операция технически lossy, и это не формальность. Невидимый RGB может быть нужен дальнейшему редактору, шейдеру или инструменту, который позже изменит alpha и «проявит» скрытый цвет. Также такие данные могут использоваться как маска или неочевидный контейнер служебной информации. Если PNG является промежуточным исходником, который продолжат редактировать, --alpha лучше не включать автоматически. Если это финальный ассет для браузера или UI, риск значительно ниже.

На границах полупрозрачных объектов --alpha не должен рассматриваться как инструмент против ореолов. Он не исправляет неправильный premultiplied alpha, не лечит белые контуры и не меняет полупрозрачные пиксели ради красоты. Если после оптимизации появилась кайма, следует проверить способ экспорта из редактора, цвет профиля, режим композитинга и сам исходник. Oxipng занимается представлением PNG, а не художественной коррекцией краёв.

Практический профиль для готовых иконок может выглядеть как oxipng -o 4 --strip safe --alpha icon.png. Для исходников дизайна безопаснее оставить --alpha выключенным и ограничиться обычной lossless-оптимизацией. Разница в политике должна быть зафиксирована в проекте: одни и те же PNG не стоит сегодня считать финальными ассетами, а завтра использовать как редактируемый источник.

Метаданные: —strip и —keep

Дополнительные PNG chunks могут занимать от нескольких десятков байт до заметной доли файла. Там встречаются текстовые комментарии, данные EXIF, цветовые профили, физический размер, сведения об анимации и другие поля. Удаление метаданных иногда даёт больший эффект, чем дополнительная ступень DEFLATE, но требует понимания, что именно теряется. Oxipng предлагает три основных подхода: сохранить всё допустимое по умолчанию, удалить безопасно удаляемое через --strip safe или задать собственную политику.

—strip safe

Режим --strip safe удаляет некритичные chunks, которые не должны менять отображение, но сохраняет набор, влияющий на представление или необходимый для APNG. В актуальной справке в исключениях перечислены cICP, iCCP, sRGB, pHYs, acTL, fcTL и fdAT. Короткая форма -s эквивалентна --strip safe. Для веб-публикации это разумная отправная точка, когда текстовые и редакционные метаданные не требуются, но цвет и анимация должны остаться корректными.

—strip all

--strip all удаляет все некритичные chunks. Это более агрессивная политика. Она может убрать ICC-профиль, параметры физического размера и другую информацию, которая не нужна декодеру для получения массива пикселей, но влияет на интерпретацию. Особенно важно: для APNG этот режим удаляет анимационные chunks и тем самым превращает анимированный файл в обычный PNG. Поэтому запуск --strip all по смешанной папке PNG/APNG без проверки — типичная опасная ошибка.

Удаление конкретных chunks

Вместо режимов safe/all параметр принимает список chunks через запятую, например можно адресно удалить ненужные текстовые поля. Такой подход полезен в издательском или архивном процессе, где часть метаданных нужна, а часть запрещена политикой публикации. Важно не копировать списки из чужих гайдов механически: значение каждого chunk зависит от типа данных и требований потребителя.

—keep

--keep работает от обратного: программа удаляет метаданные, кроме перечисленных. Специальное значение display включает chunks, влияющие на отображение, и по смыслу соответствует безопасной политике. Можно сочетать его с конкретным полем, например оставить EXIF вместе с display-набором. Такой белый список удобнее, когда политика проекта формулируется как «разрешено только…».

Некоторые chunks становятся недействительными после изменения типа цвета или глубины. bKGD, sBIT и hIST могут быть удалены, если reduction меняет их смысл. Если пользователь явно требует сохранить их через --keep, Oxipng вместо удаления отключает соответствующие reductions. Другие специфические chunks, такие как caBX и iDOT, по умолчанию удаляются; явное требование сохранить их может привести к отказу от оптимизации. Это пример того, почему метаданные и структурные преобразования нельзя рассматривать независимо.

Если цвет после оптимизации кажется другим, первым делом сравнивают не фильтры DEFLATE, а политику метаданных. Удаление или замена ICC/sRGB/cICP способно изменить интерпретацию цвета приложением, даже если числовые значения пикселей не изменились. Поэтому для материала, где цвет критичен, безопаснее начинать с сохранением метаданных, затем отдельно проверять --strip safe в целевых браузерах и просмотрщиках.

Interlacing и Adam7

PNG поддерживает Adam7 interlacing: изображение можно загружать и показывать прогрессивными проходами. В современных веб-сценариях эта возможность требуется редко и увеличивает размер. В Oxipng параметр -i или --interlace принимает off, on или keep. Текущий стандартный режим — off, то есть оптимизатор убирает interlacing у обрабатываемых файлов.

По справке interlacing способен добавить примерно 25–50% к размеру уже оптимизированного PNG. Это не универсальная цифра для каждого изображения, а предупреждение о существенной цене. Включать --interlace on следует только если потребитель действительно выигрывает от прогрессивной загрузки или формат требует такого представления. Для обычных статических веб-ассетов deinterlace часто является рациональной частью оптимизации.

--interlace keep нужен, когда структурное свойство файла важнее максимальной экономии. Например, набор ассетов проходит проверку, ожидающую исходный режим, либо PNG используется в системе с заранее определёнными требованиями. Если задача — только повторно сжать данные, не трогая interlace, можно дополнительно рассмотреть --nx, но это отключает и другие transformations, поэтому выбор зависит от того, какие изменения допустимы.

Старые инструкции могут показывать -i 0 и -i 1. В актуальном CLI поколения 10 используются слова off и on. Если скрипт после обновления перестал запускаться с ошибкой разбора аргумента, именно этот переход стоит проверить одним из первых.

Работа с APNG

Oxipng умеет обрабатывать анимированные PNG, но поддержка намеренно ограничена. Для APNG доступны alpha-оптимизация, повторная фильтрация и повторное сжатие кадров; обычные transformations, которые меняют представление статического PNG, отключаются. Причина практическая: анимационные chunks связывают кадры и области обновления, поэтому агрессивные преобразования требуют отдельной логики и легко нарушают воспроизведение.

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

Самая опасная опция для APNG — --strip all. Анимация хранится в некритичных с точки зрения базового PNG chunks, и их удаление превращает файл в статический. Для смешанной папки безопаснее --strip safe либо отсутствие stripping. Если пайплайн принимает и PNG, и APNG, полезно разделить их правила и явно контролировать расширения.

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

Пакетная обработка и рекурсивный режим

Для нескольких файлов можно передать список: oxipng -o 4 a.png b.png c.png. Для текущего каталога часто используют шаблон *.png. Для дерева — --recursive. Внутри сборочного проекта лучше выбрать один способ и использовать его последовательно: смешивание shell-glob, рекурсии и внешнего find без необходимости усложняет понимание того, какие файлы реально были обработаны.

При рекурсии Oxipng оптимизирует PNG/APNG, но не предоставляет полноценную систему исключений по аналогии с .gitignore. Если нужно пропустить каталоги build, vendor, snapshots или тестовые фикстуры, список входов удобнее формировать внешним инструментом. Это даёт более явную политику и предотвращает случайную перезапись файлов, которые должны оставаться эталонными.

Сочетание --recursive и --dir требует особого внимания из-за плоского выхода. Если структура папок должна сохраниться, надёжнее запускать Oxipng по каждой папке отдельно или оставить запись на месте под контролем системы версий. В CI можно сначала копировать дерево в временный каталог, а затем оптимизировать его там. Так сохраняется относительная структура и исключается риск повредить исходные артефакты.

Массовый запуск стоит начинать с --dry-run. На большом репозитории это показывает, сколько файлов вообще выиграют. Если большинство уже оптимизировано, максимальный уровень на каждом коммите только расходует процессор. Можно изменить стратегию: оптимизировать новые и изменённые PNG в pre-commit, а полный проход выполнять перед релизом.

Для deterministic-порядка обработки нескольких файлов есть --sequential. Он не делает сам алгоритм «более правильным», а отключает параллельную обработку файлов. Это бывает важно для логов, тестов времени, последовательного доступа к медленному диску или систем, где внешний наблюдатель ожидает конкретный порядок. Если --threads 1, отдельный --sequential уже не обязателен.

Многопоточность, память и ограничение ресурсов

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

-t или --threads <num> устанавливает верхнюю границу потоков. Если сборка конкурирует с компилятором, тестами и линтером, ограничение до 2–4 потоков часто делает весь pipeline предсказуемее, даже если отдельно Oxipng завершится чуть позже. Для очень больших изображений снижение потоков помогает уменьшить пиковое потребление памяти.

Реальные сообщения об ошибках памяти часто появляются не из-за одного PNG, а из-за сочетания большого уровня, нескольких тяжёлых файлов и параллелизма. Первые действия: уменьшить --threads, включить --sequential, отказаться от -o max и Zopfli, затем повторить обработку. Увеличивать swap — последний шаг, а не основной способ «лечения» профиля, который одновременно держит слишком много данных.

--max-raw-size позволяет пропускать изображения, чьи распакованные данные или размер файла превышают заданный предел. Значение принимает суффиксы единиц. Это полезно в сервисе, куда поступают пользовательские файлы: маленький на диске PNG может разворачиваться в огромный буфер. Приблизительный сырой объём можно оценить по ширине, высоте и количеству бит на пиксель, однако программа сама выполняет проверку перед дорогой работой.

--timeout задаёт максимальное время, отводимое на оптимизационные попытки. Ограничение проверяется перед трансформациями и compression trials, но уже запущенную тяжёлую операцию не прерывает немедленно. Поэтому timeout — мягкий предохранитель, а не гарантированная «стенка» времени. Для строгого SLA дополнительно нужен внешний контроль процесса.

Dry run, подробный вывод, quiet и JSON

-d или --dry-run не записывает файлы и показывает результат оценки. Этот режим полезен перед любой новой политикой: stripping, alpha, сменой уровня, рекурсией. Он позволяет сравнить потенциальную экономию без риска. В автоматизации dry run также удобен как диагностический шаг, но сам по себе не является «check mode» с заранее оговорённым кодом выхода для политики размера; логику допуска/запрета обычно строят внешним скриптом.

-v или --verbose показывает информацию по файлам; флаг можно повторять для большей детализации. Подробный режим нужен при отладке reduction, выборе фильтров и выяснении, почему файл не изменился. Для обычного CI слишком подробный лог мешает искать реальные ошибки, поэтому после настройки уровень уменьшают.

-q или --quiet подавляет сообщения. Он полезен, если stdout используется как бинарный канал, либо внешний скрипт сам формирует отчёт. Но постоянный quiet без перехвата exit status и stderr усложняет диагностику. В продуктивном pipeline лучше сохранять ошибки и краткую статистику, а не выбрасывать весь вывод.

-j или --json печатает результаты в машиночитаемом JSON. Эта опция появилась в ветке 10.1 и удобна для CI, где нужно собирать статистику без разбора человекочитаемых строк. Структуру JSON разумно воспринимать как контракт конкретной установленной версии: скрипт должен проверять обязательные поля и не ломаться из-за добавления новых. Если проект фиксирует Oxipng по версии, формат отчёта тестируют вместе с обновлением зависимости.

Не стоит строить автоматизацию на распознавании цветных фрагментов обычного help/output. В новых версиях справка получила цветной вывод, а формат стандартного резюме менялся. Для программного потребителя предназначен JSON, а для стабильного бинарного результата — --stdout. Человекочитаемый текст оставляют человеку.

Контроль ошибок: —fix, —force, —nx и —nz

--fix предназначен для случаев, когда PNG содержит проблемы с контрольными суммами или некоторыми структурными ошибками. В актуальной справке этот режим отключает строгую проверку checksum на входе, что может позволить обработать файл, который иначе отвергается; выходные chunks получают корректные контрольные суммы. Использовать флаг автоматически на всём архиве не стоит: сначала полезно выяснить, почему источник повреждён и не скрывает ли ошибка реальные данные.

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

--nz запрещает повторно сжимать IDAT, если это не требуется из-за transformations, и отключает повторное сжатие других compressed chunks вроде iCCP. Флаг помогает изолировать влияние структурных reductions от DEFLATE. --nx отключает transformations. Вместе --nx --nz полностью выключают оптимизацию, что может быть полезно только как контрольный тест или часть диагностического сценария.

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

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

Для сайта обычно важны три вещи: уменьшить передачу байтов, не изменить внешний вид и убрать ненужные редакционные метаданные. Рабочий процесс начинается с копии или ветки в системе контроля версий. Затем выполняют oxipng --dry-run -o 4 --strip safe assets/*.png. Если потенциальная экономия разумна и изображения статические, запускают ту же команду без dry run. Для иконок с полностью прозрачными областями после отдельной проверки можно добавить --alpha.

После оптимизации полезно не ограничиваться открытием одного файла. Проверяют страницы, где PNG используются как фон, img, CSS-mask, иконка с alpha и элемент интерфейса на разных фонах. Для ресурсов с цветовым профилем сравнивают хотя бы два браузера. Если stripping влияет на цвет, возвращают профиль или отказываются от удаления соответствующего chunk. Экономия нескольких килобайт не должна ломать воспроизведение фирменного цвета.

Для большого фронтенд-проекта Oxipng логично ставить после генератора изображений, но до хэширования имён файлов. Если сначала вычислить content hash, а потом изменить байты PNG, имя перестанет соответствовать содержимому. Поэтому типичный порядок: экспорт/генерация → Oxipng → финальный хэш/копирование → упаковка приложения. Если CDN выполняет собственную оптимизацию, сравнивают итоговый контент, чтобы не тратить время на дублирующий этап.

Не стоит запускать -o max --zopfli на каждом hot-reload. Разработчику важнее короткий цикл. В локальном режиме достаточно -o 1 или -o 2, а тяжёлый профиль можно оставить релизной сборке. Отдельный cache по хэшу входного PNG предотвращает повторную оптимизацию неизменившихся файлов.

Практический сценарий: скриншоты и документация

Скриншоты часто хорошо сжимаются без потерь: в них много однотонных областей, повторяющихся цветов, текста и простых границ. Для документации разумно использовать -o 4 и --strip safe. Однако EXIF и pHYs иногда участвуют в издательском процессе, поэтому перед удалением метаданных проверяют требования платформы. В статическом сайте физическое разрешение обычно не определяет CSS-размер, но в печатном workflow оно может быть значимым.

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

Для набора из тысяч кадров не обязательно гнаться за максимумом. Сначала измеряют выборку на -o 2, -o 4 и -o 6. Если разница между 4 и 6 минимальна, время лучше потратить на уменьшение размеров самих скриншотов, удаление дублей или переход части фотографического контента в другой формат. Oxipng оптимизирует кодирование, но не исправляет избыточное разрешение изображения.

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

Практический сценарий: иконки, спрайты и UI-графика

Иконки нередко экспортируются в RGBA даже когда большая часть пикселей непрозрачна, а прозрачное поле содержит случайные RGB-значения. Oxipng может выиграть на palette reduction, удалении лишнего alpha и --alpha. Для финального интерфейсного набора полезен тест на всех масштабах и фонах. Особенно внимательно проверяют пиксель-арт и элементы, где движок использует nearest-neighbor: визуально любое изменение видимой части должно быть исключено.

Игровые движки и UI-фреймворки иногда предъявляют требования к типу цвета, палитре или pre-multiplied alpha. Если после оптимизации ресурс не проходит импорт, сначала отключают reductions через --nc, --nb, --np или --ng, а не делают вывод, что DEFLATE «сломал PNG». Декодер может корректно поддерживать формат PNG в целом, но иметь ограничения на конкретный цветовой тип.

Для спрайтов, где прозрачные пиксели используют как источник цвета при постобработке, --alpha запрещают. Например, шейдер может расширять контур объекта за пределы alpha и брать RGB из невидимой зоны для сглаживания. После изменения скрытого RGB результат будет отличаться, хотя обычный PNG-просмотрщик не заметит разницы. Это классический случай, когда «visually lossless» не равно «семантически без потерь».

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

Практический сценарий: CI, pre-commit и релизная сборка

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

В CI лучше работать с фиксированной версией, а не всегда брать «последнюю». В поколении 10 уже менялись имена флагов, и без фиксации обновление способно сломать скрипт. Версию обновляют отдельным pull request, запускают тестовый набор PNG и проверяют как размер, так и метаданные. Это особенно важно, если оптимизированные файлы коммитятся обратно в репозиторий: массовый бинарный diff без объяснения неудобен для ревью.

Контейнерный запуск полезен, когда локальные ОС команды различаются. Каталог монтируют внутрь официального образа, команда получает те же аргументы. Следует помнить о владельце файлов и правах на Linux-хосте: контейнер может создать результат с неожиданным UID. Если запись идёт на месте, это проверяют в CI до внедрения в основной workflow.

Для отчётов подходит --json. Внешний скрипт может суммировать исходный и итоговый объём, перечислять файлы без выигрыша и сохранять статистику как артефакт сборки. При этом не стоит вводить фиктивный «минимальный процент экономии» как универсальный критерий качества. Маленькая иконка может выигрывать всего несколько байт, а большой скриншот — десятки процентов; решение зависит от стоимости CPU и характера продукта.

Если pipeline параллельно выполняет тесты и компиляцию, --threads ограничивают. «Использовать все ядра» полезно только если Oxipng — единственная тяжёлая задача. В CI общая длительность определяется конкуренцией за CPU и память, поэтому 2–4 потока часто дают более стабильный итог, чем максимальный автопараллелизм.

Как выбирать уровень оптимизации без выдуманных бенчмарков

У Oxipng нет одного процента экономии, который можно честно обещать для всех PNG. Результат зависит от того, чем создан файл, использовался ли другой оптимизатор, сколько в нём метаданных, насколько удачны фильтры, есть ли палитра и прозрачность. Поэтому производительность оценивают на собственном корпусе. Минимальный полезный тест — несколько десятков файлов разных типов: скриншоты, иконки, изображения с alpha, палитровые PNG и большие полноцветные кадры.

Для каждого профиля фиксируют три величины: суммарный исходный размер, суммарный результат и время на одной и той же машине. Лучше запускать несколько раз и отделять холодный дисковый кэш от CPU-времени. Затем сравнивают -o 2, -o 4 и -o 6. Zopfli тестируют отдельно, потому что его временной масштаб может быть совсем другим. Цель — увидеть кривую отдачи, а не найти «самое большое число» в параметре.

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

Нельзя сравнивать Oxipng с lossy-конвертером только по размеру, не фиксируя условие качества. pngquant, WebP lossy или AVIF могут дать намного меньший файл потому, что меняют пиксели или палитру с потерями. Такое сравнение отвечает на другой вопрос. Для честной оценки lossless PNG-оптимизаторов нужно сохранять формат и визуальные данные, а для выбора веб-формата — уже сравнивать итоговое качество и совместимость всего набора.

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

Команда oxipng не найдена

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

Файл не найден или шаблон ничего не выбрал

Проверяют текущий каталог, кавычки и то, кто разворачивает *. На Windows и Unix поведение shell отличается. Для пути с квадратными скобками и другими специальными символами шаблоны могут интерпретироваться неожиданно. Надёжный диагностический шаг — передать один полный путь без wildcard. Если он работает, проблема не в PNG и не в компрессии, а в выборе входных файлов.

После запуска размер не изменился

Это нормальная ситуация для уже оптимизированного PNG. Запускают -v и смотрят, какие попытки делались. Можно сравнить более высокий уровень, но не следует ожидать обязательного выигрыша. Если исходник уже прошёл сильный оптимизатор, несколько дополнительных байт экономии могут стоить непропорционально много CPU.

Результат отличается по цвету

Первым подозреваемым является stripping цветовых метаданных. Повторяют обработку без --strip, затем с --strip safe. Если проблема исчезла, определяют нужный ICC/sRGB/cICP и фиксируют политику через --keep. DEFLATE и строковые фильтры сами по себе не должны менять декодированные пиксели.

APNG стал статичным

Проверяют, не использовался ли --strip all. Этот режим удаляет анимационные некритичные chunks. Восстановить анимацию из уже перезаписанного статического результата без исходника нельзя, поэтому для APNG требуется резервная копия или система версий. Для сохранения анимации применяют --strip safe либо не удаляют chunks.

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

Снижают --threads, включают --sequential, уменьшают -o, убирают Zopfli. Для сервиса добавляют --max-raw-size. Если один файл всё равно слишком тяжёлый, проверяют его реальное разрешение и bit depth: сжатый PNG может быть небольшим, а распакованный буфер — огромным. При необходимости такой вход обрабатывают отдельно.

Высокий уровень работает слишком долго

Это ожидаемо: дополнительные фильтры и полные trials стоят времени. Используют более низкий пресет, --fast, ограничение потоков и --timeout. Для Zopfli уменьшают --zi или задают --ziwi. Если экономия измеряется десятками байт, имеет смысл отказаться от дорогого режима.

Рекурсивный вывод перезаписывает одноимённые файлы

Причина — --dir не сохраняет структуру дерева при рекурсии. Не отправляют разные подкаталоги с одинаковыми именами в один плоский output. Либо оптимизируют на месте под контролем Git, либо внешний скрипт создаёт зеркальные подкаталоги и запускает Oxipng по каждому файлу с индивидуальным --out.

Старая инструкция использует неизвестный флаг

Сверяют oxipng --help. В версии 10 короткий флаг Zopfli изменился с заглавного -Z на -z, старый --pretend переименован в --dry-run, а interlace принимает on/off вместо 1/0. Ещё раньше был удалён режим автоматического backup. Скрипты миграции нужно обновлять осознанно, а не добавлять случайные синонимы.

Переход со старых версий и чужих примеров команд

Oxipng развивается, и командная строка не застыла навсегда. В поколении 10 произошли несовместимые изменения: Zopfli получил короткий -z, dry run — -d/--dry-run, interlace — значения on/off. Если корпоративный скрипт создавался по старому блогу, обновление бинарника без теста способно остановить pipeline. Поэтому версия инструмента должна быть частью конфигурации проекта так же, как версия компилятора или пакетного менеджера.

В поколении 9 был удалён --backup. Сохранение исходника теперь организуют через --out, --dir, отдельную рабочую копию или VCS. Это более явная модель: пользователь сам определяет, где находится оригинал. Автоматический backup внутри оптимизатора кажется удобным, но усложняет пакетную структуру и правила очистки.

Также важно не считать Oxipng drop-in replacement для OptiPNG. Проект начинался как переписывание идей OptiPNG, но архитектура и набор ключей разошлись. Некоторые похожие короткие параметры имеют иной смысл, а часть возможностей существует только в одном инструменте. При миграции пересобирают команду по текущей справке, а не заменяют имя исполняемого файла в старом скрипте.

Хороший upgrade-процесс содержит небольшую папку тестовых PNG: RGB, RGBA, palette, grayscale, 16-bit, interlaced и APNG. После обновления запускают рабочий профиль, проверяют декодированные пиксели, метаданные, анимацию и размер. Такой набор быстрее обнаружит несовместимость, чем чтение changelog без проверки собственного сценария.

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

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

Программа не является универсальным конвертером форматов. Она не превращает библиотеку в JPEG, WebP или AVIF. Если главная цель — минимальный вес сайта при допустимом изменении формата, Oxipng — лишь один участник сравнения. Выбор формата зависит от типа контента, поддержки браузеров, прозрачности, анимации и требований к lossless.

Oxipng не гарантирует фиксированный процент уменьшения. Он не может сделать уже оптимальный PNG намного меньше, не меняя данные. Нельзя требовать «сжать каждый файл минимум на 30%» и одновременно запрещать потери, уменьшение разрешения и смену формата. Если бизнес-требование сформулировано как целевой размер, нужны дополнительные техники: resize, quantization или другой кодек.

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

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

Oxipng логично сравнивать с другими PNG-оптимизаторами по способу работы, автоматизации и ограничениям. ФотоМАСТЕР стоит в другой категории: это визуальный фоторедактор. Он включён в сравнение, потому что пользователь может решать задачу «подготовить изображение к публикации», но роль у программ различна. ФотоМАСТЕР меняет само изображение — позволяет выполнять ретушь, заменять фон, удалять объекты, применять эффекты, добавлять оформление и сохранять результат в нужном формате. Oxipng начинает работу после такого редактирования, когда пиксели уже утверждены и требуется компактнее упаковать PNG.

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

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

Для начинающего пользователя ФотоМАСТЕР понятнее именно в редактировании: есть визуальные инструменты и предварительный просмотр. Oxipng требует командной строки и понимания параметров. Но в автоматизации ситуация обратная: CLI позволяет встроить Oxipng в скрипт, прогнать тысячи файлов одинаковой политикой и не открывать окна. Поэтому критерий выбора — не «какая программа сильнее», а нужна ли работа с содержанием изображения или с его PNG-представлением.

Oxipng и OptiPNG

OptiPNG — прямой классический аналог. Он без потерь уменьшает PNG, умеет проверять и исправлять структуру, а также преобразовывать некоторые внешние растровые форматы в оптимизированный PNG. Oxipng сосредоточен на PNG/APNG, использует многопоточность, имеет JSON-вывод и современную систему пресетов. Исторически Oxipng начинался как переписывание идей OptiPNG, но сегодня не является совместимой заменой по ключам.

Если старый pipeline уже стабильно построен вокруг OptiPNG и использует его конвертацию из BMP/GIF/PNM/TIFF, миграция требует дополнительного инструмента для этих форматов. Если задача — большой набор готовых PNG и важен параллелизм, Oxipng предоставляет соответствующие средства напрямую. Сравнивать результат лучше на собственном наборе: алгоритмы и пресеты различаются, поэтому абсолютного правила по каждому файлу нет.

Oxipng и pngcrush

pngcrush тоже оптимизирует PNG перебором уровней zlib и фильтров, но даёт развитые операции с ancillary chunks: может удалять и добавлять отдельные типы данных, включая gamma, transparency и текстовые поля. У него есть brute-force режим с большим числом методов. Такой контроль полезен в технической обработке PNG-структуры, но командная строка более низкоуровневая.

Oxipng предлагает более компактный путь для типовой задачи: пресет -o, safe stripping, alpha, interlace, рекурсия и контроль потоков. Если pipeline должен не только уменьшить файл, но и специально вставить/переписать metadata chunks, возможности pngcrush могут соответствовать задаче лучше. Если нужна стандартизованная массовая оптимизация, набор флагов Oxipng проще формализовать.

Oxipng и Efficient Compression Tool

ECT работает не только с PNG, но и с JPEG, GZIP и ZIP. Это удобно, когда один CLI должен оптимизировать разные типы ресурсов. Oxipng, напротив, глубже сфокусирован на PNG/APNG и предоставляет специфичные флаги для reductions, alpha, interlace, chunks и JSON-отчёта. В сборке можно использовать оба подхода: универсальный инструмент ради единого pipeline либо специализированный PNG-этап рядом с отдельными оптимизаторами других форматов.

Набор проверенных команд для повседневной работы

Базовая оптимизация одного файла:

oxipng image.png

Проверка без записи:

oxipng --dry-run image.png

Практичный профиль для статического веб-PNG:

oxipng -o 4 --strip safe image.png

То же для финального PNG с прозрачностью, где допустимо менять полностью прозрачные RGB:

oxipng -o 4 --strip safe --alpha image.png

Максимальный встроенный пресет без Zopfli:

oxipng -o max image.png

Тяжёлый финальный прогон с Zopfli и быстрой оценкой фильтров:

oxipng -o max --zopfli --fast image.png

Выход в отдельный файл:

oxipng -o 4 --out optimized.png source.png

Рекурсивная обработка дерева на месте:

oxipng -o 3 --strip safe --recursive assets

Ограничение CPU и более предсказуемое потребление памяти:

oxipng -o 4 --threads 2 assets/*.png

Последовательная обработка файлов:

oxipng -o 4 --sequential assets/*.png

Сохранение текущего interlace:

oxipng -o 4 --interlace keep image.png

Отказ от изменения палитры:

oxipng -o 4 --np image.png

Машиночитаемый отчёт:

oxipng --json -o 4 image.png

Эти команды не нужно складывать в один «суперпрофиль». Каждая отвечает на конкретное требование. Чем больше флагов добавлено, тем важнее документировать, почему они нужны и какие свойства файла сохраняются.

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

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

Второй уровень — структура. Проверяют, остались ли нужные ICC/cICP/sRGB, EXIF и pHYs. Для APNG проверяют acTL/fcTL/fdAT и воспроизведение всех кадров. Если применялся --strip safe, результат должен сохранять данные, влияющие на отображение, но корпоративная политика всё равно может требовать дополнительные chunks.

Третий уровень — целевая среда. PNG открывают там, где он реально будет использоваться: браузер, приложение, игровой движок, генератор PDF, мобильный клиент. Валидный файл может встретить баг или ограничение конкретного декодера. Проблема особенно вероятна после изменения color type или palette; в этом случае запрет конкретного reduction является разумным workaround.

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

Практические ограничения, которые важно учитывать

Главное ограничение — отсутствие GUI. Пользователь не видит превью, ползунки и «до/после» внутри программы. Это не проблема для автоматизации, но повышает требования к аккуратности команд. Перед рекурсивным запуском нужно понимать текущий каталог, политику выхода и stripping.

Второе — фокус только на PNG/APNG. Если каталог смешанный, потребуется оркестратор или другие оптимизаторы. Oxipng не заменяет jpegoptim, MozJPEG, libwebp или AVIF-кодек. Универсальные оболочки могут вызывать разные инструменты под капотом, но это уже другой уровень системы.

Третье — ограниченная оптимизация APNG. Программа не выполняет все структурные преобразования кадров, и агрессивное удаление chunks способно уничтожить анимацию. Для сложных APNG нужен отдельный этап.

Четвёртое — отсутствие гарантии «самого маленького PNG». Пресеты эффективны, но не являются полным математическим перебором. Zopfli тоже не гарантирует выигрыш на каждом файле. Если требуется абсолютный минимум для нескольких конкретных ассетов, используют сравнительный pipeline из нескольких оптимизаторов и выбирают меньший валидный результат.

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

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

Для большинства проектов полезно сформулировать профиль как набор гарантий. Например: «формат остаётся PNG; видимые пиксели не меняются; цветовые данные сохраняются; текстовые метаданные удаляются; interlace отключается; исходники доступны в Git». Из этих требований напрямую следуют флаги. Такой подход надёжнее, чем копирование команды из чужой статьи.

Для обычной веб-статики профиль может быть: -o 4 --strip safe, без --alpha на первом этапе. После теста прозрачных ассетов alpha включают только для финальных файлов. Для архивных исходников stripping не используют. Для APNG запрещают --strip all. Для больших пользовательских входов добавляют --max-raw-size, ограничивают threads и задают внешний timeout.

Если внутренний потребитель требует строго RGBA8, запрещают reductions, которые меняют тип и глубину. Размер будет больше, но совместимость важнее. Если наоборот допустима palette reduction, оставляют её включённой. Oxipng полезен именно тем, что не навязывает одну политику: пользователь может выбрать между максимальной компактностью и сохранением структурных свойств.

Профиль фиксируют в одном месте — make target, package script, CI job или отдельный shell/PowerShell-скрипт. Не стоит хранить пять чуть разных команд в README, wiki и локальных инструкциях. Вместе с профилем фиксируют версию Oxipng и тестовую папку. Тогда обновление можно провести как управляемое изменение, а не как случайный сдвиг поведения.

Что находится внутри пресетов оптимизации

Пресет -o — не абстрактная «сила сжатия», а конкретная комбинация фильтров, уровня libdeflate и режима оценки. Понимание состава полезно в двух случаях: когда нужно объяснить резкий рост времени между уровнями и когда пользователь вручную добавляет -f, --zc или параметры Brute. В актуальной справке уровни устроены следующим образом.

Уровни 3–6 дополнительно используют параметры Brute. На уровне 3 это --brute-level 1 --brute-lines 3, на уровне 4 — lines 4, на уровне 5 — lines 8, а на уровне 6 Brute поднимается до level 5 при восьми строках. Эта деталь объясняет, почему «6» может быть намного тяжелее «4», хотя численно разница кажется небольшой. Программа не просто увеличивает один коэффициент, а меняет стратегию поиска.

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

С другой стороны, знание состава помогает быстро диагностировать неожиданность. Если пользователь запускает -o 6 --fast, он сознательно возвращает быструю схему оценки, которой в чистом шестом профиле нет. Если задаёт -f 0,1, большая часть дорогих фильтров пресета исчезает. Если ставит --zc 8, основной DEFLATE уже не соответствует выбранному уровню. Поэтому в отчёте о производительности нужно указывать всю команду, а не только значение -o.

Как читать PNG-структуру при выборе политики

Для уверенной работы с Oxipng полезно различать критические и дополнительные chunks. Критические блоки требуются для базового декодирования PNG; дополнительные могут хранить цвет, текст, физические параметры и расширения вроде анимации. --strip работает именно с некритичной частью и не превращает валидный PNG в набор без обязательных данных. Но «некритичный» в терминологии формата не означает «ненужный для проекта»: ICC-профиль или APNG-control формально дополнительны, а практически могут быть необходимы.

Цветовой профиль — типичный пример. Один просмотрщик может уважать iCCP, другой — использовать sRGB или cICP, третий — вести себя иначе при отсутствии всех профилей. Если команда сравнивает два файла только в одном приложении, можно не заметить изменение. Поэтому stripping лучше считать не косметической очисткой, а управляемым преобразованием метаданных с тестом целевой среды.

pHYs задаёт физическую плотность пикселей. Для обычной веб-вёрстки CSS размеры определяются отдельно, поэтому поле часто не влияет на экранное представление. Но при помещении PNG в офисный документ, DTP или печать pHYs может менять размер на странице. --strip safe сохраняет этот chunk, что снижает риск неожиданного поведения в смешанном web/print workflow.

EXIF может хранить данные камеры и другую информацию, которая для скриншота не нужна, но для фотоархива ценна. Если задача — публичная публикация, удаление EXIF иногда соответствует требованиям приватности. Если задача — мастер-архив, наоборот, удалять его нельзя. Oxipng не знает смысл проекта и не может выбрать за пользователя; он лишь предоставляет --strip и --keep.

Текстовые chunks могут содержать комментарии, авторство, параметры генератора и произвольные поля. Их удаление удобно для уменьшения файла и очистки публикации, но некоторые системы используют текстовые поля как метки. Если PNG проходит через pipeline с кастомными chunks, перед --strip safe полезно инвентаризировать структуру хотя бы на выборке.

Для APNG контрольные chunks acTL, fcTL и fdAT составляют анимационное расширение. Именно поэтому safe-режим их сохраняет, а all — нет. Если после оптимизации файл «стал обычным PNG», проблема не в фильтрах или Zopfli, а в удалённой структуре анимации. Это простая, но критичная диагностическая развилка.

Сценарии с сохранением исходника

До версии 9 в Oxipng существовала отдельная backup-опция, но современный подход строится на явном управлении выходом. Для одиночного файла лучший способ — --out. Для проекта под Git — отдельная ветка или чистое рабочее дерево. Для большого архива — копия каталога или snapshot файловой системы. Такой подход надёжнее автоматического суффикса .bak, потому что владелец проекта сам определяет жизненный цикл оригиналов.

Если исходник хранится в Git, перед массовой оптимизацией проверяют git status. После прогона видно, какие PNG действительно изменились. Не следует смешивать оптимизацию с художественными правками в одном commit: бинарный diff не показывает пиксельные отличия, и ревьюеру сложнее понять причину. Отдельный commit «optimize PNG assets» делает историю прозрачнее.

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

Для производственного пайплайна полезна стратегия immutable inputs: Oxipng читает исходный каталог и пишет в build-каталог через индивидуальный --out или внешний скрипт. Это исключает риск, что повторный build начнёт работать уже с оптимизированным входом и усложнит диагностику. Такой подход особенно удобен, если pipeline параллельно генерирует WebP/AVIF из тех же исходников.

Разница между «не менять пиксели» и «не менять байты»

После обычной оптимизации файл почти всегда отличается побитово от исходного: меняется DEFLATE-поток, порядок или набор допустимых chunks, иногда color type и bit depth. Но при lossless-преобразовании декодированное изображение остаётся эквивалентным. Поэтому checksum всего PNG не подходит для проверки «качество не изменилось». Он неизбежно будет другим.

Для статического изображения корректный тест — декодировать оба PNG в одинаковое каноническое представление и сравнить пиксели. Если --alpha выключен и не применялся --scale16, видимые значения должны совпадать. Если alpha включён, допускаются различия RGB там, где alpha строго нулевой. Если reductions изменили palette на RGB или наоборот, сравнение индексов бессмысленно: сравнивают конечные RGBA.

Метаданные проверяют отдельным тестом. Например, можно требовать сохранение ICC, pHYs и EXIF, но разрешать удаление text chunks. Тогда валидатор сравнивает именно эти поля. Такой подход даёт точное определение «безопасности» для проекта вместо расплывчатого утверждения «файл выглядит нормально».

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

Интеграция в Bash и PowerShell без сложной обвязки

Oxipng не требует собственного языка конфигурации, поэтому его легко вызывать из shell. В Bash для контролируемой выборки удобно сначала получить список изменённых PNG из системы версий, затем передать каждый путь отдельным аргументом с корректным quoting. Главная задача — не разбивать имена по пробелам и не смешивать результаты нескольких параллельных процессов без необходимости.

В PowerShell пути естественно передаются объектами, а для рекурсивной выборки можно использовать встроенный обход файловой системы и вызывать Oxipng только для .png/.apng. Такой внешний фильтр удобен, если нужно исключить каталоги snapshots, vendor или build. Сам Oxipng умеет рекурсию, но внешний язык даёт более сложные правила включения и исключения.

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

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

Для логов shell-скрипт может сохранять JSON каждого запуска, объединять статистику и отдельно выводить stderr. Не следует разбирать цветной текст help или verbose регулярными выражениями, если доступен --json. Такой парсер хрупок к обновлениям и локальным особенностям терминала.

Когда использовать —keep вместо —strip

Если требования формулируются как «удалить всё лишнее, но не трогать то, что влияет на показ», удобен --strip safe. Если же политика безопасности говорит «в публикации разрешены только конкретные поля», лучше --keep. Разница методологическая: blacklist удаляет известное ненужное, whitelist оставляет только явно разрешённое.

Например, издатель может хотеть сохранить цвет и физический размер, но удалить EXIF и текст. Тогда --strip safe уже близок к цели. Фотоархив, напротив, может требовать EXIF: к display-набору добавляют eXIf. В специализированном научном workflow список будет другим. Важно использовать точные четырёхсимвольные имена chunks и проверять результат после изменения color type.

Явный --keep способен повлиять на reductions. Если сохраняемый chunk становится недействительным при смене color type или bit depth, Oxipng отключит соответствующее преобразование. Это может увеличить итоговый файл, но сохраняет заданное свойство. Поэтому сравнивать размер двух команд с разными keep-правилами без учёта структуры некорректно: они решают разные задачи.

Для публикационного профиля список keep лучше хранить рядом с документацией о причине каждого поля. Через год команда иначе не вспомнит, почему сохраняется редкий chunk. Если причина исчезла, его можно убрать и повторно измерить результат.

Когда отключать отдельные reductions

--nb, --nc, --np и --ng часто воспринимаются как параметры «для экспертов», но они полезны при проблемах совместимости. Если один конкретный декодер не принимает оптимизированный PNG, первым делом выясняют, какое структурное свойство изменилось. Затем запрещают только соответствующий класс transformations, сохраняя остальную оптимизацию.

--nb нужен, если downstream ожидает фиксированную bit depth. Это встречается в тестовых наборах, некоторых движках и научных данных. --nc удерживает color type, полезно при строгом формате интерфейсных ресурсов. --np не позволяет перевести изображение в indexed и не изменяет существующую palette. --ng запрещает переход к grayscale или из него.

Отключать все transformations через --nx проще, но обычно слишком грубо. Если проблема только в палитре, --np сохраняет возможность других безопасных сокращений. Такой «минимально необходимый запрет» даёт более компактный результат и лучше объясняется в конфигурации.

При расследовании полезна матрица: обычный профиль; затем --np; затем --nc; затем --nb; затем --nx. Сравнение показывает, на каком уровне исчезает несовместимость. Это быстрее, чем случайно менять фильтры и Zopfli, которые не связаны с типом пикселей.

Особенности больших PNG и серверной обработки

Большой PNG на диске не обязательно означает большой буфер, и наоборот. Снимок с огромными однотонными областями может сжиматься до нескольких мегабайт, но после декодирования занимать сотни мегабайт. Именно raw-размер определяет память для transformations и фильтров. Поэтому сервису нельзя ограничиваться HTTP Content-Length.

--max-raw-size служит встроенным первым барьером. Его выбирают по доступной памяти, числу параллельных задач и допустимому разрешению продукта. Если сервер допускает четыре одновременных jobs, лимит одного изображения должен оставлять запас для операционной системы, самого процесса и нескольких compression buffers. Устанавливать предел равным всей свободной RAM опасно.

Второй барьер — threads. Пользовательский файл не должен автоматически занимать все логические ядра общего сервера. Для очереди изображений задают небольшое число threads на job и контролируют общий concurrency внешним планировщиком. Так один тяжёлый PNG не вытеснит остальные запросы.

Третий барьер — время. --timeout полезен, но не прерывает уже выполняющийся trial мгновенно, поэтому внешний supervisor должен уметь завершить процесс целиком. Для сервиса также не используют Zopfli без сильной причины: его непредсказуемая длительность плохо сочетается с интерактивным SLA.

Четвёртый барьер — место записи. Веб-сервису безопаснее писать в отдельный временный файл, проверять успешность и только потом атомарно заменять целевой объект. Прямой in-place режим на пользовательском оригинале создаёт риск при аварийном завершении процесса или ошибке инфраструктуры.

Повторные запуски и идемпотентность

Хороший оптимизатор должен нормально вести себя при повторном прогоне уже обработанного файла. Oxipng старается не писать результат, если улучшения нет, а современные reductions ориентированы на стабильность повторных запусков. Тем не менее build-система не должна бесконечно прогонять неизменившиеся PNG: даже отсутствие изменений требует чтения, декодирования и испытаний.

Проще всего кэшировать по хэшу входного файла и профилю. Ключ кэша должен включать версию Oxipng и набор аргументов, потому что изменение -o, stripping или версии может дать другой результат. Если ключ совпал, ранее оптимизированный артефакт можно переиспользовать.

В репозитории полезно не смешивать генерацию и повторную оптимизацию. Если дизайнерский экспорт каждый раз выдаёт одинаковые байты, кэш работает идеально. Если редактор записывает случайные timestamps или другие метаданные, хэш меняется даже без визуальной правки. Тогда --strip safe после экспорта может, наоборот, стабилизировать результат, удаляя шумовые поля.

Для reproducible builds также фиксируют locale, версию инструмента и окружение, если внешняя логика формирует список файлов. Сам PNG-результат не должен зависеть от порядка логов, но build-архив или manifest может зависеть от порядка обработки. В таких случаях используют --sequential или сортируют список заранее.

Как оценивать пользу удаления метаданных

Иногда пользователи включают --strip all, видят заметную экономию и приписывают её «лучшему компрессору». На самом деле значительная часть выигрыша может быть просто удалённым ICC, EXIF или текстом. Чтобы понимать причину, сравнивают минимум три прогона: без stripping, с --strip safe и с требуемой пользовательской политикой. Тогда видно, сколько даёт DEFLATE, а сколько — метаданные.

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

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

Выбор между Oxipng, lossy PNG и сменой формата

Oxipng сохраняет PNG и ориентирован на lossless. Если после него файл всё ещё слишком велик, есть три принципиально разных пути. Первый — уменьшить разрешение: это меняет количество пикселей. Второй — применить lossy quantization, например сократить палитру: пиксели меняются, но файл остаётся PNG. Третий — сменить кодек на WebP, AVIF или другой формат. Эти шаги нельзя смешивать с lossless-оптимизацией в одном понятии «сжать сильнее».

Для иконок и UI PNG часто остаётся уместным из-за прозрачности, резких границ и простой совместимости. Для фотографий современный lossy-кодек обычно эффективнее по размеру при сопоставимом визуальном качестве. Для архивных данных, где каждый пиксель важен и нужна широкая поддержка, lossless PNG остаётся рациональным. Oxipng полезен именно в последнем и первом случаях.

Если product manager задаёт только лимит «не больше 100 КБ», один Oxipng не может гарантировать его. Pipeline должен иметь fallback: сначала lossless, затем при необходимости resize/quantization/format conversion по согласованным правилам. В противном случае разработчик окажется перед невозможным требованием уменьшить любой файл без потерь до произвольного размера.

Контрольный список перед массовым запуском

• Определить, какие каталоги и расширения являются входом.
• Проверить, есть ли APNG и можно ли удалять анимационные chunks.
• Решить, какие метаданные обязательны: цвет, EXIF, pHYs, текст.
• Выбрать, допустим ли --alpha для полностью прозрачных пикселей.
• Запретить --scale16, если 16-битная точность имеет смысл.
• Проверить требования downstream к color type, palette и bit depth.
• Сделать --dry-run на представительной выборке.
• Выбрать уровень -o по измерениям времени и размера.
• Ограничить --threads для общей сборочной машины.
• Для пользовательских входов задать --max-raw-size и внешний timeout.
• Определить стратегию резервной копии или отдельного output.
• Зафиксировать версию Oxipng в CI и документировать профиль.

Этот список нужен не из-за сложности самой команды, а потому что PNG используется в очень разных ролях. Для финальной иконки допустимы одни изменения, для архивного снимка — другие, для научной маски — третьи. Oxipng предоставляет флаги для каждого класса требований, и качественный результат зависит от корректной политики.

Когда нужен стандартный вывод вместо файла

--stdout полезен, когда Oxipng является одним звеном конвейера и промежуточный PNG не должен появляться на диске. Например, предыдущая программа генерирует изображение в поток, Oxipng его оптимизирует, а следующий этап сразу отправляет байты в архив или объектное хранилище. Такая схема сокращает временные файлы и упрощает очистку, но требует строгого разделения бинарного stdout и диагностических сообщений.

В потоковом сценарии нельзя относиться к терминалу как к обычному интерактивному окну. Любая случайная текстовая строка в том же канале повредит PNG. Поэтому stdout резервируют под изображение, а журнал направляют отдельно; при необходимости включают --quiet. Внешний процесс обязан проверять успешность завершения, прежде чем считать полученные байты валидным артефактом.

Для ручной работы поток обычно менее удобен, чем --out: отдельный файл проще открыть, сравнить и удалить. --stdout имеет смысл именно тогда, когда следующий потребитель уже умеет читать бинарные данные из stdin. Если pipeline всё равно немедленно сохраняет результат в именованный файл, явный --out делает команду понятнее.

Итог

Oxipng решает узкую, но важную задачу: делает готовые PNG компактнее за счёт более удачной фильтрации, DEFLATE-сжатия, безопасных reductions и управляемой работы с metadata chunks. Его сильная сторона — не визуальное редактирование, а воспроизводимый CLI-процесс, который подходит и для одного файла, и для большого репозитория. Базовый -o 2 даёт быстрый повседневный режим, более высокие уровни увеличивают число попыток, а Zopfli оставляют для случаев, где время вторично.

Безопасная работа строится вокруг нескольких правил: сначала --dry-run, затем понятный выход; --strip safe вместо бездумного --strip all; осторожность с --alpha и --scale16; отдельная проверка APNG; ограничение потоков и размера для крупных входов; фиксация версии CLI в CI. Если требуется ретушь, фон, текст или цветокоррекция, до Oxipng нужен редактор вроде ФотоМАСТЕР. Если требуется другой конечный формат, нужен соответствующий кодек. Когда же формат должен остаться PNG, Oxipng предоставляет детальный контроль над тем, как именно получить более компактный файл без ненужных изменений.