Zopflipng: где скачать и как пользоваться

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

Что делает Zopflipng и для каких задач он подходит

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

Что меняется внутри PNG

В стандартном режиме Zopflipng может выбрать более подходящий тип цвета, проверить несколько стратегий PNG-фильтров и удалить вспомогательные чанки, которые не считаются необходимыми для типичного веб-отображения. В справке upstream перечислены сохраняемые по умолчанию структурные чанки IHDR, PLTE, tRNS, IDAT и IEND. Это важно понимать заранее: видимые пиксели и метаданные — не одно и то же. Файл может выглядеть идентично, но лишиться текстового комментария, физического разрешения или цветовой информации, если их не попросить сохранить явно.

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

Когда медленное сжатие оправдано

Zopfli изначально проектировался как более затратный по процессору способ получить плотный Deflate-поток. Google приводил для самого алгоритма ориентир 3–8% относительно максимального zlib при существенно большем времени сжатия; это не обещание для конкретного PNG, потому что итоговый файл зависит также от фильтров, цветового типа и исходной структуры. Практический смысл простой: Zopflipng рационален в релизной или публикационной сборке, где каждый файл обрабатывается редко, а скачивается много раз.

Показательный пример такого использования есть у команды Android: при подготовке Santa Tracker PNG-ассеты прогонялись через Zopflipng, и в отчёте Google большинство изображений уменьшилось примерно на 10%, отдельные — до 30%, а суммарная экономия составила около 5 МБ. Эти цифры относятся к конкретному набору файлов и не являются универсальной нормой. Они хорошо показывают сценарий, в котором медленный офлайн-проход окупается: статических ресурсов много, а результат затем распространяется массово.

Интерфейс Zopflipng: командная строка без графических панелей

У Zopflipng нет окна с меню Open, Save, ползунком качества или предпросмотром. Рабочая область — терминал: имя исполняемого файла, параметры, путь к исходному PNG и путь к результату. Поэтому навигацию здесь заменяет синтаксис команды, а состояние операции видно по текстовому выводу. Это не недостаток интерфейса как такового, а сознательная модель CLI, удобная для автоматизации и повторяемых сборок.

Как устроена команда

Базовая форма состоит из двух файлов: zopflipng [параметры] infile.png outfile.png. Исходник и результат лучше задавать разными именами, чтобы можно было проверить итог до замены оригинала. Вторая форма использует --prefix и принимает несколько входных PNG. Для справки предусмотрены --help и -h; в исходном коде также разбирается --verbose, который выводит дополнительные сведения о ходе оптимизации.

Порядок чтения команды удобнее держать постоянным: сначала режим скорости и качества, затем параметры структуры PNG, после них вход и выход. Например, zopflipng -m --lossy_transparent icon.png icon.min.png означает более тщательный прогон и разрешение изменить скрытые RGB-значения пикселей с нулевой альфой. Само имя параметра следует читать буквально: это не общий режим с потерями, а очень конкретное преобразование прозрачных пикселей.

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

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

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

Как оптимизировать один PNG без лишнего риска

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

Базовый запуск с отдельным выходным файлом

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

Шаг 2. Выполните команду zopflipng source.png result.png. Первый аргумент после параметров — входной файл, второй — новый файл. Не начинайте с перезаписи единственной копии исходника: отдельный result.png позволяет спокойно сравнить результаты и вернуться назад без восстановления из резервной копии.

Шаг 3. Прочитайте консольный отчёт. Сравните Input size и Result size, затем процент от оригинала. Если файл стал меньше, переходите к проверке отображения. Если выигрыша нет, это не ошибка: повторная рекомпрессия хорошо подготовленного PNG может ничего не дать.

Шаг 4. Откройте result.png тем же приложением, которым проверяли source.png, либо прогоните через декодер в сборке проекта. Сопоставьте ширину и высоту, прозрачные края, резкие цветовые переходы и области с полупрозрачностью. Для интерфейсной графики полезно проверить файл и на светлом, и на тёмном фоне.

Шаг 5. Только после проверки заменяйте файл в каталоге публикации или сборки. Исходник удобнее хранить отдельно от оптимизированного ассета: Zopflipng — финальный оптимизатор, а не место для дальнейшего редактирования изображения.

Усиленное сжатие с параметром -m

Шаг 1. Возьмите тот же исходный PNG и сначала сохраните результат базового прогона. Это даст точку сравнения: без неё нельзя понять, насколько -m помогает именно вашему изображению.

Шаг 2. Запустите zopflipng -m source.png result-more.png. В upstream-коде -m увеличивает два значения числа итераций в четыре раза относительно текущих настроек. При стандартных значениях это означает более долгий поиск, поэтому режим уместнее для финальной сборки, а не для каждого сохранения во время дизайна.

Шаг 3. Сравните result-more.png не только с исходником, но и с result.png из базового прогона. На одном файле дополнительная экономия может быть заметной, на другом — составлять считанные байты. Решение о применении -m должно опираться на реальный размер набора ассетов и время сборки, а не на ожидание фиксированного процента.

Шаг 4. Если -m используется в релизном конвейере, отделите его от быстрого локального цикла. Например, разработчик сохраняет обычный PNG без тяжёлой рекомпрессии, а более тщательный проход выполняется перед публикацией. Так высокая стоимость Zopfli не тормозит повседневную работу.

Быстрый режим -q и сухой прогон -d

Шаг 1. Для быстрой оценки структуры PNG используйте zopflipng -q source.png quick.png. В исходном коде -q отключает Zopfli-сжатие и оставляет более быстрый, но менее плотный путь. Такой результат полезен как черновая проверка фильтров и цветового представления, а не как замена более тщательному релизному проходу.

Шаг 2. Когда нужно увидеть расчёт без записи файла, добавьте -d: zopflipng -d -m source.png result.png. Dry run выводит сведения в консоль, но не сохраняет результат. Это удобно для сравнения времени и оценки команд в автоматизации, где сначала требуется убедиться, что набор параметров корректен.

Шаг 3. Не переносите результат -q в публикацию автоматически только потому, что он посчитан быстрее. Сначала сравните его с обычным режимом на репрезентативных PNG. Если разница в размере для проекта несущественна, быстрый режим можно оставить в промежуточных сборках, а финальный — выполнять отдельно.

Шаг 4. В сценариях измерения не добавляйте --always_zopflify к обычному процессу. Этот параметр специально заставляет сохранить Zopfli-вариант даже тогда, когда он больше исходника, и потому полезен для экспериментов, но противоречит задаче реального уменьшения файла.

Как настроить фильтры, глубину цвета и метаданные

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

Когда включать --lossy_transparent

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

Шаг 2. Сначала получите строгий результат командой zopflipng source.png lossless.png. Затем выполните zopflipng --lossy_transparent source.png transparent.png. Этот параметр разрешает менять скрытые цвета там, где альфа равна нулю, чтобы такие области лучше сжимались.

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

Шаг 4. Не называйте этот режим строгим побайтовым lossless. Он не должен менять видимое изображение, однако данные RGB в невидимых пикселях изменяются. Такое различие важно для тестов, которые сравнивают исходный и выходной RGBA-массив целиком.

Что делает --lossy_8bit

Шаг 1. Определите глубину исходного PNG. Если изображение хранит 16 бит на канал, обычный запуск сохраняет эту точность. Для научных данных, карт высот, градиентов с дальнейшей коррекцией и печатных процессов это может быть принципиально.

Шаг 2. Для файла, где 16-битная точность не требуется, выполните zopflipng --lossy_8bit source16.png result8.png. Параметр переводит 16-битные каналы в 8-битные и тем самым сознательно уменьшает точность представления.

Шаг 3. После обработки проверьте IHDR или свойства файла декодером и убедитесь, что глубина действительно стала 8 бит. Затем оцените плавные градиенты и области, где возможен бэндинг. Для обычных веб-иконок такой режим нередко избыточен, потому что исходник уже 8-битный; для 16-битного технического файла он может быть недопустим.

Если задача связана не со сжатием, а с количеством пикселей и геометрическим размером, это другой процесс. Разобраться в нём помогает материал о том, как менять разрешение PNG и не путать его с весом файла. Zopflipng сам по себе не масштабирует изображение.

Как сохранять нужные PNG-чанки

Шаг 1. До оптимизации определите, какие вспомогательные данные нужны после публикации. Частые примеры — iCCP для ICC-профиля, sRGB и gAMA для цветовой интерпретации, pHYs для физического разрешения, tEXt, zTXt или iTXt для текстовых метаданных. Не сохраняйте всё автоматически: каждый дополнительный чанк увеличивает итоговый файл и иногда ограничивает другие оптимизации.

Шаг 2. Передайте четырёхсимвольные имена через запятую: zopflipng --keepchunks=iCCP,sRGB,gAMA,pHYs source.png result.png. Синтаксис чувствителен к регистру символов, потому что имена PNG-чанков сами по себе регистрозависимы. Для текстовых данных можно отдельно добавить tEXt, zTXt или iTXt, когда они действительно нужны.

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

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

Как использовать --keepcolortype, --iterations и --filters

Шаг 1. Применяйте --keepcolortype, когда декодер или последующая обработка ожидают исходный тип цвета и битовую глубину. Команда zopflipng --keepcolortype source.png result.png запрещает полезные преобразования вроде перехода RGBA в gray+alpha для фактически серого изображения, поэтому итог может быть крупнее, зато структура предсказуемее.

Шаг 2. Для ручного контроля числа итераций используйте --iterations=N. Значение не должно быть меньше 1. Увеличение N повышает время работы и обычно даёт всё меньшую добавочную экономию, поэтому сравнивайте несколько разумных значений на реальном наборе файлов, а не ставьте максимальное число по привычке.

Шаг 3. Параметр --filters задаёт стратегии PNG-фильтрации: 0–4 означают фиксированные типы фильтра для строк, m — minimum sum, e — entropy, p — сохранение предопределённой стратегии из входа, b — экспериментальный brute force. В upstream-справке как практичный набор указан --filters=0me.

Шаг 4. Если --filters не задан, Zopflipng автоматически выбирает перспективную стратегию, предварительно пробуя варианты более быстрым сжатием. При явном списке каждый указанный вариант проверяется с более медленным сжатием, после чего сохраняется лучший. Это объясняет, почему длинный перечень фильтров заметно увеличивает время обработки.

Шаг 5. Не используйте старый --splitting как способ настройки качества: в текущем CLI он разбирается, но игнорируется и оставлен ради обратной совместимости. В старом скрипте такой параметр можно удалить после проверки, что никакой другой компонент сборки от него не зависит.

Как обрабатывать набор PNG и встроить Zopflipng в сборку

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

Пакетный запуск через --prefix

Шаг 1. Сложите исходные PNG в понятный каталог и решите, как отличать оптимизированные файлы. Для простого случая достаточно префикса opt_. Команда zopflipng --prefix=opt_ a.png b.png c.png создаёт отдельные выходные имена на основе входных.

Шаг 2. На оболочках, которые разворачивают маски файлов, можно использовать zopflipng --prefix=opt_ *.png. Сам шаблон обрабатывает командная оболочка, поэтому в переносимом скрипте надёжнее явно контролировать, какие пути попадают в список, особенно на разных операционных системах.

Шаг 3. Если --prefix задан без значения, upstream использует zopfli_. Имена, уже начинающиеся с выбранного префикса, пропускаются как предполагаемые результаты предыдущих прогонов. Это помогает не получать цепочку zopfli_zopfli_ при повторном запуске по тому же каталогу.

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

Как управлять перезаписью и выходными каталогами

Шаг 1. Для каталога сборки включите путь в префикс, например --prefix=dist/opt_. Upstream допускает путь внутри префикса. Каталог dist следует создать заранее, а исходники держать отдельно: так ошибка в параметрах не затронет мастер-файлы.

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

Шаг 3. Не направляйте массовую обработку в каталог оригиналов, пока команда не проверена на копии. Удобная схема — assets-src для мастер-файлов и dist/images для результатов. Сборка сайта читает dist/images, а дизайнер продолжает работать с assets-src без накопления повторно оптимизированных версий.

Шаг 4. Если задача должна завершиться ошибкой при проблеме с одним PNG, проверьте код возврата процесса в оболочке или CI. Так повреждённый файл не затеряется среди успешных сообщений, а публикация не продолжится с неполным набором ассетов.

Как запускать Zopflipng из shell-скрипта

Шаг 1. Создайте скрипт с остановкой при ошибке и подготовьте выходной каталог. На POSIX-системе практичная основа выглядит так: set -euo pipefail, затем mkdir -p dist и вызов zopflipng с нужными входами. Сам Zopflipng остаётся обычным отдельным процессом, поэтому его легко вставить между экспортом графики и упаковкой релиза.

Шаг 2. Для релизного шага используйте подтверждённый профиль, например zopflipng -m --prefix=dist/opt_ assets/*.png. Для промежуточного шага допустим -q, когда важнее скорость. Не смешивайте профили незаметно: название задачи сборки должно показывать, выполняется быстрый или финальный проход.

Шаг 3. Сохраняйте консольный вывод в журнал CI. В нём остаются входной и выходной размеры, поэтому по истории сборок можно заметить резкое увеличение ассета после изменения дизайна. Это полезнее, чем просто проверять факт существования result.png.

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

Как вызывать утилиту из Python

Шаг 1. Для существующего Python-конвейера проще всего вызвать исполняемый файл через subprocess, не переписывая алгоритм. Передайте параметры отдельными элементами списка: ["zopflipng", "-m", src, dst]. Такой способ не зависит от экранирования пробелов оболочкой и позволяет получить код возврата процесса.

Шаг 2. Запустите subprocess.run с capture_output=True и text=True, если журнал нужен программе. Проверяйте returncode до публикации результата. Успешный код не отменяет проверки размера и декодирования; он лишь говорит, что утилита завершила свою часть работы без сообщённой ошибки.

Шаг 3. После успешного процесса проверьте существование dst и его размер. Затем откройте PNG декодером, который уже используется в проекте. Такой двухступенчатый контроль ловит и технические ошибки процесса, и повреждение результата, которое проявилось бы только при чтении изображения.

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

Как проверять результат и разбирать ошибки

Оптимизация заканчивается не на строке Result is smaller, а на валидации. Минимальный контроль состоит из трёх частей: файл действительно уменьшился или как минимум не стал больше, PNG корректно декодируется, важные для проекта данные сохранились. Отдельно проверяются цвет, альфа, метаданные и анимация, потому что эти свойства связаны с разными механизмами PNG.

Как сравнить размер и декодирование

Шаг 1. Запишите байтовый размер исходника и результата. Для оценки набора используйте сумму по каталогу, но сохраняйте и данные по отдельным крупным файлам. Если один PNG вырос, общий выигрыш способен это скрыть.

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

Шаг 3. Для прозрачной графики сравните альфа-канал. Если использован --lossy_transparent, не требуйте полного равенства скрытых RGB при альфе 0; проверяйте видимые и полупрозрачные пиксели. Без этого параметра требования к данным могут быть строже.

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

Что делать при изменении цвета или метаданных

Шаг 1. Если изображение после оптимизации выглядит иначе, сравните список чанков исходника и результата. Upstream README предупреждает, что удаление вспомогательных чанков в отдельных случаях влияет на отображение в конкретных программах. Частый кандидат — iCCP, а также sRGB и gAMA.

Шаг 2. Повторите обработку с явным сохранением нужных данных, например --keepchunks=iCCP,sRGB,gAMA. Для файла, где важно физическое разрешение, добавьте pHYs. Не вставляйте все имена из памятки механически: сохранение ненужных чанков уменьшает выгоду и может ограничивать выбор цветового типа.

Шаг 3. Снова откройте результат в целевой программе, а не только в одном универсальном просмотрщике. Цветовое управление у приложений различается, поэтому проверка должна соответствовать месту реального использования: браузеру, движку, системе печати или внутреннему анализатору.

Шаг 4. Если потребитель чувствителен к цветовому типу, добавьте --keepcolortype и сравните размер. Это сознательный обмен части потенциала сжатия на предсказуемую структуру PNG.

Почему файл не становится меньше

Шаг 1. Проверьте, не был ли PNG уже обработан сильным оптимизатором. Повторный проход над удачным IDAT часто даёт нулевой или минимальный выигрыш. Это нормальный результат, а не признак повреждения программы.

Шаг 2. Сравните базовый режим, -m и один аккуратный набор фильтров. Не переходите сразу к сотням итераций: сначала убедитесь, что направление вообще даёт экономию. Для маленьких иконок разница в несколько байт может не оправдывать существенное увеличение времени сборки.

Шаг 3. Если результат больше исходника, не включайте --always_zopflify в релизной команде. Этот параметр предназначен для сравнения алгоритма и заставляет сохранить Zopfli-вариант даже при проигрыше по размеру.

Шаг 4. Оцените сам выбор формата. Zopflipng оптимизирует PNG, но не делает PNG лучшим контейнером для любого изображения. Фотографический контент или анимация могут требовать другого решения; в таком случае правильный итог — сменить инструмент или формат, а не бесконечно увеличивать число итераций.

Почему APNG нельзя пропускать через обычный сценарий

Шаг 1. Перед пакетной обработкой определите, есть ли среди файлов APNG. Расширение .png не гарантирует, что внутри только один кадр. Считайте число кадров декодером или проверьте наличие анимационных чанков acTL, fcTL и fdAT.

Шаг 2. Не отправляйте APNG в обычный pipeline Zopflipng как статический PNG. В открытом upstream issue документировано, что Zopflipng превращает APNG в обычный PNG, то есть анимация теряется. Наш отдельный контроль числа кадров должен выполняться до и после любого инструмента, который не заявляет полноценную поддержку APNG.

Шаг 3. Исключите APNG из списка входов или направьте его в оптимизатор с поддержкой анимации. Современный OxiPNG, например, заявляет ограниченную оптимизацию APNG всех кадров, хотя часть преобразований для анимации отключает. Для проекта это важнее потенциальной разницы в процентах сжатия: потерянная анимация означает функционально неверный файл.

Шаг 4. Добавьте тест в сборку: если вход содержит несколько кадров, выход тоже должен содержать ожидаемое число кадров. Такой тест предотвращает повторение проблемы при смене скриптов и расширении набора ассетов.

Плюсы, минусы и границы применения

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

Плюсы

1. Сильное Deflate-сжатие на базе Zopfli для финальной подготовки статических PNG.
2. Стандартный PNG остаётся совместимым с обычными декодерами; особого формата результата нет.
3. Есть управление фильтрами, числом итераций, цветовым типом и сохранением выбранных PNG-чанков.
4. CLI легко включить в shell-скрипт, сборку, CI или внешний процесс из другого языка.
5. Пакетный режим с --prefix создаёт отдельные результаты и помогает не трогать мастер-файлы.

Минусы

1. Сжатие заметно медленнее обычных Deflate-реализаций, особенно с -m, множеством фильтров и большим числом итераций.
2. Графического интерфейса и встроенного визуального сравнения нет.
3. По умолчанию удаляются многие вспомогательные PNG-чанки, поэтому цвет и метаданные требуют осознанной настройки.
4. --lossy_transparent и --lossy_8bit меняют данные и не подходят для сценариев со строгим сохранением исходного массива.
5. Обычная обработка APNG не сохраняет анимацию.
6. Основной репозиторий Google переведён в режим read-only 14 октября 2025 года; обычная разработка в этом upstream-репозитории прекращена.

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

1. Веб-разработчикам и инженерам сборки, которые оптимизируют статические иконки, схемы и интерфейсные ассеты перед релизом.
2. Разработчикам приложений и игр, когда PNG остаётся обязательным форматом, а процессорное время сборки дешевле трафика и размера пакета.
3. Авторам технических pipeline, которым нужен воспроизводимый CLI с явными параметрами и машинно проверяемым результатом.

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

1. Тем, кому нужен фоторедактор, изменение размеров, ретушь или визуальная настройка качества в окне программы.
2. Проектам с большим количеством APNG, если анимацию требуется сохранить.
3. Процессам, где PNG нужно сжимать на лету с минимальной задержкой.
4. Сценариям, где неизвестно назначение цветовых профилей, служебных чанков или скрытых данных прозрачных пикселей и нет возможности проверить результат.

Zopflipng и альтернативы: что выбрать для PNG

Сравнивать PNG-оптимизаторы полезнее по рабочему процессу, чем по одной цифре размера. Zopflipng делает ставку на более дорогой поиск Deflate-представления. OxiPNG — современный многопоточный CLI на Rust с уровнями оптимизации, управлением удалением метаданных и ограниченной поддержкой APNG. Для больших каталогов его модель обычно удобнее, а режим Zopfli в OxiPNG оставляет возможность более тяжёлого финального прохода.

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

Pngcrush даёт детальный контроль над методами сжатия и PNG-чанками, умеет удалять и добавлять вспомогательные данные и имеет brute-force режим. Это делает его удобным диагностическим инструментом для структуры PNG. Zopflipng проще по идее: подобрать выгодные фильтры и цветовое представление, затем потратить больше CPU на Deflate.

Практические профили для разных сценариев

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

Веб-иконки, логотипы и интерфейсная графика

Шаг 1. Начните с zopflipng -m icon.png icon.min.png. Для прозрачной графики, где скрытые RGB не используются как данные, сравните второй вариант: zopflipng -m --lossy_transparent icon.png icon.min.png. Выберите его только после проверки прозрачных краёв на светлом и тёмном фоне.

Шаг 2. Если цветовой профиль логотипа важен, добавьте только нужные чанки, например --keepchunks=iCCP,sRGB. Проверьте результат в целевых браузерах или рендерере. Если PNG получен из редактора с большим количеством служебной информации, выигрыш от удаления лишнего может оказаться значительнее, чем от увеличения числа итераций.

Шаг 3. Для десятков иконок перенесите профиль в пакетный --prefix и измеряйте сумму размеров всего набора. Так становится ясно, оправдывает ли -m дополнительное время в масштабе релиза.

Технические PNG, скриншоты и файлы для печати

Шаг 1. Для технического PNG начните со строгого режима без lossy-параметров. Если downstream зависит от исходного типа цвета, добавьте --keepcolortype. Для DPI сохраните pHYs, для профиля — iCCP и при необходимости sRGB/gAMA. Пример: zopflipng -m --keepcolortype --keepchunks=iCCP,pHYs source.png result.png.

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

Шаг 3. Не используйте --lossy_8bit для 16-битного технического изображения без отдельного решения о снижении точности. Оптимизация размера и изменение глубины данных — разные задачи, и их лучше фиксировать раздельно.

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

Шаг 1. Исключите APNG из стандартного списка Zopflipng. Для анимации выберите оптимизатор, который сохраняет все кадры и понимает соответствующие чанки. В каталоге XeonLive отдельно разобран PNGGauntlet как другой подход к lossless-оптимизации, а для современных CLI уместно сравнить OxiPNG.

Шаг 2. Для фотографии сначала решите вопрос формата. Если PNG выбран только по привычке, рассмотрите более подходящий контейнер и только затем оптимизацию. Для конвертации форматов есть отдельное руководство по преобразованию JPG, PNG, WebP, HEIC и TIFF.

Шаг 3. Для очень частых сборок измерьте полный бюджет времени. Если Zopflipng заметно задерживает каждый коммит, оставьте быстрый оптимизатор в повседневном цикле, а Zopflipng запускайте только на релизном наборе или откажитесь от него там, где экономия несущественна.

Шаг 4. Считайте успешным не самый маленький файл любой ценой, а тот, который проходит все требования: корректно декодируется, сохраняет нужный цвет и метаданные, не теряет функциональность и даёт оправданную экономию. Именно такой критерий превращает Zopflipng из экспериментальной утилиты в предсказуемый этап подготовки ассетов.