Zopflipng (ZopfliPNG): возможности, ограничения и сценарии применения

Zopflipng — это не графический редактор и не онлайн-компрессор, а консольная утилита для повторного кодирования и оптимизации PNG. В исходном проекте Google программа называет себя ZopfliPNG, а запускаемый файл называется zopflipng. Она подбирает параметры PNG-кодирования, использует медленный алгоритм Zopfli для потока Deflate, может менять тип цвета без изменения видимых пикселей, удаляет часть дополнительных PNG-блоков и сохраняет результат только тогда, когда он действительно меньше исходника. Главный нюанс в 2026 году — состояние проекта: репозиторий google/zopfli был переведён владельцем в архив 14 октября 2025 года и теперь доступен только для чтения. Поэтому Zopflipng стоит рассматривать как законченную специализированную утилиту с зафиксированным upstream-кодом, а не как активно развиваемый современный продукт.

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

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

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

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

Что именно называется Zopflipng

Название легко перепутать с более широким проектом Zopfli. Zopfli — это библиотека и алгоритм сжатия, ориентированный на создание Deflate, zlib и gzip-потоков. ZopfliPNG — отдельный компонент того же репозитория, предназначенный именно для файлов Portable Network Graphics. Его исполняемый файл называется zopflipng, поэтому в пакетных менеджерах, скриптах и командах чаще встречается написание в нижнем регистре.

Проект Zopfli создан Lode Vandevenne и Jyrki Alakuijala; исходники размещались в репозитории Google. Сам zopflipng использует библиотеку libzopflipng и код LodePNG для чтения и повторного кодирования PNG. Это важно для правильной идентификации: программа не является графическим интерфейсом к стороннему веб-сервису, не относится к одноимённым мобильным приложениям и не является отдельным коммерческим продуктом с подпиской.

Текущий статус и доступность в 2026 году

На дату подготовки обзора upstream-репозиторий уже не принимает изменения: GitHub помечает google/zopfli как Public archive и прямо указывает дату архивирования 14 октября 2025 года. В CMake-файле проекта по-прежнему задана версия 1.0.3, а список тегов заканчивается zopfli-1.0.3 от 27 ноября 2019 года. Отдельной более новой версии ZopfliPNG в этом репозитории нет.

Старый файл README.zopflipng сохранил формулировку об alpha-release. Её нельзя трактовать как обещание будущих обновлений: после архивирования upstream такой цикл разработки фактически прекращён. Практический вывод простой: использовать утилиту можно, но ждать исправления нового бага, поддержки нового варианта формата или официального ответа через pull request уже не следует.

Исходники остаются доступными по Apache License 2.0. Это не freeware с закрытым кодом и не продукт с ограниченной бесплатной редакцией. Нет учётной записи, активации, тарифа, оплаты, рекламного режима или ограничения по количеству файлов. Ограничения определяются кодом утилиты, вычислительной стоимостью Zopfli и свойствами PNG.

При этом распространение не закончилось одновременно с архивированием upstream. Сторонние экосистемы продолжают собирать версию 1.0.3. В 2026 году пакет MSYS2 для Windows содержит zopflipng.exe и libzopflipng, Debian продолжает публиковать пакет zopfli версии 1.0.3 с дистрибутивными ревизиями, а Homebrew предлагает формулу zopfli с бинарниками zopfli и zopflipng для macOS и Linux. Homebrew уже пометил эту формулу как deprecated с датой отключения 13 ноября 2026 года, что дополнительно подчёркивает устаревающий статус upstream.

Платформы и способ установки

У Zopflipng нет единственного официального установщика для Windows или macOS. Основная форма распространения upstream — исходный код. В проекте есть Makefile, который исходная документация описывает как ориентированный на Linux, а также CMake-конфигурация. CMake создаёт исполняемый файл zopflipng, библиотеку libzopflipng и содержит отдельные настройки для MSVC, поэтому код можно собирать и в Windows-среде с совместимым компилятором.

Для других систем документация предлагает обычную сборку C/C++ исходников. Отдельные современные пакеты упрощают установку: в MSYS2 готовый Windows-пакет включает zopflipng.exe; Homebrew устанавливает zopflipng на поддерживаемых macOS и Linux; дистрибутивы Linux могут поставлять его в пакете zopfli. Эти пакеты обслуживаются не архивированным репозиторием Google, а соответствующими менеджерами пакетов.

Upstream не задаёт современную таблицу системных требований с минимальной версией Windows, macOS, объёмом оперативной памяти или моделью процессора. Поэтому при оценке совместимости корректнее ориентироваться на доступность конкретной сборки либо на возможность собрать C/C++ код. На практике ограничение чаще связано не с объёмом диска, а со временем процессора: Zopfli сознательно тратит значительно больше вычислений на поиск более компактного Deflate-представления.

Мобильной версии для Android или iOS у этого проекта нет. Браузерного интерфейса тоже нет. Утилита не требует постоянного доступа к интернету для обработки изображений: ей передаются локальные входные и выходные файлы, а вычисления выполняются на компьютере.

Интерфейс: терминал вместо окон и панелей

У Zopflipng нет главного окна, меню, панели предпросмотра, перетаскивания файлов или визуального сравнения до и после. Интерфейс состоит из строки запуска, набора параметров и текстового отчёта. Поэтому привычные для фоторедактора понятия «рабочая область», «панель инструментов» и «экспорт» здесь заменяются аргументами командной строки.

Два основных режима запуска

Для одного файла используется схема с двумя путями: сначала входной PNG, затем выходной PNG. Базовая команда выглядит так: zopflipng input.png output.png. Без режима префикса утилита ожидает именно один входной и один выходной файл. Если передать другое количество имён, она выводит справку с сообщением о необходимости указать input и output.

Для нескольких файлов предусмотрен параметр –prefix. Он добавляет префикс к выходным именам и позволяет передать сразу несколько PNG. Если значение префикса не задано, используется zopfli_. Префикс может включать путь к каталогу. Механизм также пропускает файлы, имя которых уже начинается с выбранного префикса, чтобы повторный запуск с маской не создавал цепочки вида zopfli_zopfli_.

Текстовая обратная связь

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

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

Как Zopflipng уменьшает PNG

PNG хранит строки изображения после обратимого фильтрования, а затем сжимает получившийся поток методом zlib/Deflate. Стандарт PNG определяет пять базовых типов фильтра для строк: None, Sub, Up, Average и Paeth. Выбор фильтра не меняет пиксели, но меняет последовательность байтов перед компрессией и поэтому способен заметно влиять на размер.

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

У Zopfli нет нового формата распаковки: итог остаётся обычным PNG с совместимым Deflate-потоком. Декодеру не нужен Zopfli. Это принципиальное отличие от конвертации в WebP или AVIF: Zopflipng не меняет контейнер и не создаёт формат, который потребует новой поддержки у браузера или просмотрщика.

Автоматический выбор фильтра

Без параметра –filters программа сначала оценивает несколько фильтров более быстрым сжатием и выбирает стратегию, которая выглядит наиболее перспективной для конкретного изображения. Это компромисс между качеством оптимизации и временем. Пользователь может вместо автоматики явно перечислить фильтры, которые нужно проверить медленным режимом.

Стратегии –filters

Параметр принимает символы 0, 1, 2, 3 и 4 для соответствующих пяти PNG-фильтров, а также дополнительные стратегии m, e, p и b. В справке m обозначает minimum sum, e — entropy, p — сохранение предопределённых фильтров из входного файла, b — экспериментальный brute force. Если пользователь передал список, программа проверяет указанные варианты медленным сжатием и сохраняет лучший результат. В встроенной справке в качестве разумного набора приводится 0me.

Выбор типа цвета

PNG допускает grayscale, grayscale с alpha, RGB, RGBA и индексированную палитру. Zopflipng может перекодировать картинку в более подходящий тип, когда это сохраняет пиксели. Например, файл, технически записанный как RGBA, но содержащий только серые значения с прозрачностью, может не нуждаться в четырёхканальном представлении. Для случаев, когда тип цвета важен внешнему декодеру или производственному процессу, существует –keepcolortype. Он фиксирует исходный тип цвета и битовую глубину ценой части потенциальной экономии.

Основные параметры и что они реально меняют

-m: больше итераций

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

–iterations: ручное управление поиском

–iterations=число задаёт количество итераций. В справке зафиксированы значения по умолчанию: 15 для небольших файлов и 5 для больших. Большее число делает вычисление медленнее и способно дать немного лучшее сжатие. Минимальное принимаемое значение фактически приводится к 1.

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

-q: быстрый режим

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

-d: сухой запуск

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

–always_zopflify: режим сравнения, а не обычной оптимизации

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

-y: без вопроса о перезаписи

-y отключает интерактивное подтверждение перезаписи. Для ручной разовой работы это небольшое удобство, а для скрипта — важное условие: процесс не должен останавливаться в ожидании ответа пользователя.

–splitting: совместимость со старыми командами

–splitting=0-3 в текущем коде игнорируется и оставлен только ради обратной совместимости. Его наличие в старых примерах не означает, что параметр управляет современным поведением версии 1.0.3.

Метаданные и PNG chunks: самая важная зона риска

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

Zopflipng по умолчанию агрессивно очищает дополнительные chunks. В справке перечислено, что он сохраняет основные IHDR, PLTE, tRNS, IDAT и IEND, а другие данные удаляет, если их явно не оставить. Именно поэтому характеристика «lossless PNG optimizer» требует уточнения: пиксельное изображение в стандартном режиме проверяется на совпадение, но файл как носитель метаданных не сохраняется полностью.

–keepchunks

–keepchunks=nAME,nAME,… позволяет перечислить четырёхсимвольные имена chunks, которые нужно перенести. В документации приводится пример с gAMA и pHYs, то есть с гаммой и физическими размерами/плотностью. Для файлов, где важен встроенный ICC-профиль, нужно учитывать iCCP. Перед массовой оптимизацией архивных, печатных или цветокритичных изображений перечень сохраняемых chunks следует определить заранее.

Сохранение дополнительных данных увеличивает итоговый размер и иногда ограничивает другие преобразования. В коде отдельно отмечено, что bKGD и sBIT могут вынудить оставить исходный тип цвета, из-за чего степень сжатия станет хуже. Это нормальный компромисс между минимальным весом и сохранением семантики исходного PNG.

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

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

Два опционально потерянных режима

Основная логика Zopflipng направлена на оптимизацию без изменения видимого изображения, однако два параметра прямо допускают изменение данных ради размера.

–lossy_transparent

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

–lossy_8bit

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

Проверка результата встроена в саму утилиту

После оптимизации zopflipng не ограничивается сравнением размера. Код повторно декодирует получившийся PNG и декодирует исходник, затем сопоставляет размеры изображения и RGBA-данные. В обычном режиме несовпадение считается ошибкой проверки. При –lossy_transparent различие RGB допускается только у полностью прозрачного пикселя, что соответствует назначению флага.

Если внутренняя проверка результата не проходит, программа печатает сообщение о verification failed и возвращает выход к исходному PNG вместо сохранения повреждённого варианта. Это сильная сторона инструмента: дорогое повторное кодирование сопровождается контрольным декодированием.

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

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

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

1. Сохранить исходный PNG отдельно и решить, какие метаданные должны пережить оптимизацию. Для обычной веб-графики это может быть минимальный набор; для цветокритичного материала нужно заранее определить профиль, гамму и другие обязательные chunks.
2. Открыть терминал в каталоге с изображением или использовать абсолютные пути.
3. Выполнить базовый прогон: zopflipng input.png output.png. Этот вариант позволяет оценить реальную экономию без экстремальных итераций.
4. Сравнить размер файлов и прочитать консольный отчёт. Если результат не меньше, стандартное поведение сохранит исходные байты вместо более тяжёлой версии.
5. Открыть output.png в целевом просмотрщике, браузере или приложении. Для интерфейсных ассетов желательно проверить именно тот движок, где файл будет использоваться.
6. Если важны дополнительные PNG chunks, повторить обработку с –keepchunks, перечислив необходимые имена. Сравнить не только размер, но и служебные данные.
7. Если базовый результат устраивает, для финальной сборки можно проверить -m либо увеличить –iterations. Выигрыш нужно оценивать относительно времени обработки, а не предполагать, что большее число всегда оправдано.
8. Только после сравнения заменить рабочий ассет оптимизированной копией. Исходник с полными метаданными разумно хранить отдельно от публикуемой версии.

Для нескольких файлов вместо ручного повтора используется режим префикса. Пример структуры команды: zopflipng –prefix=opt_ a.png b.png c.png. Она создаёт выходные имена с opt_ и позволяет сохранить оригиналы рядом. Такой режим безопаснее безусловной перезаписи при первом массовом прогоне.

Форматы, импорт и экспорт

Подтверждённый рабочий формат у ZopfliPNG один: PNG на входе и PNG на выходе. Утилита не является конвертером JPEG, TIFF, WebP, AVIF или RAW. Она также не принимает проектные форматы графических редакторов. Если исходник находится в другом формате, конвертацию нужно выполнять отдельным инструментом до запуска zopflipng.

Импорт означает чтение файла по пути из командной строки. Нет встроенного файлового браузера, медиатеки, буфера обмена, URL-загрузки или импорта из облачного хранилища. Экспорт — запись нового PNG по указанному пути либо генерация имени через –prefix.

При работе без –prefix требуется ровно одна пара вход/выход. В пакетном режиме можно передавать несколько PNG. Маски вроде *.png разворачиваются оболочкой командной строки, а сама программа получает уже список имён файлов.

Пакетная работа и автоматизация

Zopflipng хорошо вписывается в автоматизацию именно потому, что у него нет GUI. Команда имеет детерминированные параметры, умеет обрабатывать несколько файлов через –prefix и может работать без подтверждения с -y. Её можно вызывать из shell-скриптов, Makefile, npm-скриптов, CI/CD или собственного процесса сборки, если окружение содержит бинарник.

При этом встроенного многопоточного планировщика пакетных задач документация ZopfliPNG не предлагает. Один процесс занимается своей операцией и расходует CPU на тяжёлый поиск. Если проект хочет распараллеливать множество независимых изображений, это обычно делает внешний инструмент или система сборки. Здесь современный OxiPNG имеет более явное преимущество: он проектировался как многопоточный оптимизатор.

Автоматизации через облако, API-сервис Google или веб-кабинет у Zopflipng нет. Нет синхронизации проектов, командных аккаунтов, истории заданий, мобильного клиента или ИИ-функций. Для приватности это означает простую модель: файлы остаются локальными, если пользователь сам не помещает их в облачную среду исполнения.

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

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

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

Производительность: почему программа медленная

Смысл Zopfli — тратить значительно больше процессорного времени на поиск более удачного Deflate-представления. В исторической документации ZopfliPNG авторы сравнивали его с libpng и указывали разницу в два-три порядка по CPU-времени для компрессии. Эти старые цифры не следует превращать в современный универсальный бенчмарк, но архитектурный вывод остаётся актуальным: программа сознательно оптимизирует размер за счёт скорости кодирования.

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

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

Цена, лицензирование и редакции

Zopflipng не имеет тарифной сетки. Код Zopfli распространяется по Apache License 2.0. Нет Pro, Free, Enterprise или Premium-редакции, нет подписки и встроенных покупок. Пользователь не получает отдельный пробный режим, потому что функциональность исходного проекта не разблокируется оплатой.

Стоимость может появиться только вокруг инструмента: время разработчика, ресурсы CI, поддержка стороннего пакета или собственная сборка. Это организационные расходы, а не лицензия Zopflipng.

После архивирования репозитория особенно важно разделять лицензию и поддержку. Apache 2.0 продолжает разрешать использование и распространение кода на своих условиях, но наличие открытой лицензии не означает активного сопровождения Google.

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

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

• Веб-разработчику, который хочет финально уменьшить статические PNG и готов оплачивать компрессию временем сборки.
• Инженеру сборочного процесса, которому нужен простой локальный CLI без учётной записи и внешнего API.
• Пользователю, который сравнивает несколько lossless-оптимизаторов и хочет добавить ZopfliPNG как один из финальных проходов.
• Проекту с небольшим числом редко меняющихся PNG, где выигрыш в размере важнее скорости генерации.
• Тем, кому нужно сохранить совместимость именно с PNG и нельзя переводить ресурс в WebP или AVIF.

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

• Новичку, которому нужен визуальный интерфейс с перетаскиванием и предпросмотром.
• Команде, которая требует активно поддерживаемый upstream и регулярные официальные релизы.
• Пайплайну с тысячами часто меняющихся ассетов, где длительность компрессии критична.
• Пользователю, которому нужно одновременно обрабатывать JPEG, WebP, AVIF, GIF, TIFF или RAW.
• Цветокритичному процессу, если команда не готова явно контролировать iCCP, gAMA, cHRM и другие дополнительные chunks.
• Задачам, где необходимо сохранить 16-битную точность, если планируется использовать –lossy_8bit.
• Мобильной работе без терминального окружения и собственного способа сборки.

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

OxiPNG

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

OptiPNG

OptiPNG — классический lossless-оптимизатор, который уменьшает битовую глубину и тип цвета, перебирает методы и стратегии сжатия и сохраняет лучший вариант. Он полезен, когда нужен давно известный CLI с более традиционным балансом скорости и оптимизации. Zopflipng отличается тем, что делает ставку на гораздо более дорогой Zopfli Deflate.

pngcrush

pngcrush также является консольным PNG-оптимизатором и умеет экспериментировать с уровнями сжатия и фильтрами, а также удалять или добавлять отдельные ancillary chunks. Его сильная сторона — явная работа со структурой PNG. Однако сам pngcrush тоже относится к старому поколению инструментов, поэтому для нового автоматизированного процесса стоит сравнить его с OxiPNG.

ImageOptim

ImageOptim подходит пользователю macOS, которому нужен графический интерфейс. Приложение объединяет несколько оптимизаторов, включая Zopfli, OxiPNG, PNGCrush и другие инструменты, и скрывает необходимость вручную писать команды. Это более удобный выбор для дизайнера или редактора, тогда как чистый zopflipng лучше в скриптах и воспроизводимых сборках.

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

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

Сообщение оболочки о неизвестной команде означает, что бинарник zopflipng не установлен или каталог с ним отсутствует в PATH. Нужно проверить, какой пакет был установлен, содержит ли он именно исполняемый файл zopflipng и откуда запускается оболочка. В Windows-пакетах MSYS2 бинарник находится в соответствующей среде mingw/ucrt, поэтому запуск из другой оболочки без настроенного PATH может его не видеть.

Please provide one input and output filename

Без –prefix программа требует ровно два файловых аргумента: вход и выход. Ошибка появляется, когда передан только один файл, три и более файлов или часть пути была неверно разбита оболочкой. Для путей с пробелами нужно использовать правила quoting своей командной оболочки.

Decoding error

Утилита выводит decoding error, когда LodePNG не может разобрать вход. Сначала следует убедиться, что файл действительно является PNG, а не переименованным изображением другого формата, и что он открывается в независимом валидаторе или просмотрщике. Если файл повреждён, оптимизация не является способом его ремонта.

Result size оказался равен исходнику или больше

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

Существующий output не перезаписывается

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

После оптимизации изменился цвет или поведение в печати

Первое, что нужно проверить, — удалённые chunks. Цветовые данные могут находиться в iCCP, gAMA, cHRM или sRGB, а физическая плотность — в pHYs. Следующий прогон следует выполнять с –keepchunks для тех блоков, которые необходимы конкретной цепочке отображения или печати. После этого сравниваются и размер, и поведение в целевом приложении.

После –lossy_8bit исчезла часть градаций

Такое изменение соответствует назначению флага: 16-битные каналы переводятся в 8-битные. Для 16-битного рабочего процесса нужно вернуться к исходнику и запускать оптимизацию без –lossy_8bit.

Обработка занимает слишком много времени

Сначала нужно убрать чрезмерное значение –iterations и не использовать -m на каждом промежуточном файле. Для первичной оценки можно применить -q или стандартные параметры. Если время сборки остаётся критичным, логичнее перенести Zopflipng на финальную стадию либо заменить его многопоточным OxiPNG.

Verification of result failed

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

Как проверять результат после оптимизации

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

1. Проверить, что выходной файл существует и открывается независимым декодером.
2. Сравнить ширину, высоту, альфа-канал и видимое изображение.
3. Сравнить размер в байтах; процент из консольного отчёта удобен, но финальный критерий — фактический файл.
4. Для производственного ассета открыть PNG именно в приложении, где он будет показываться пользователю.
5. Если важны метаданные, сравнить перечень PNG chunks и отдельно проверить iCCP, gAMA, cHRM, sRGB, pHYs и текстовые блоки, которые были нужны исходнику.
6. Не считать режимы –lossy_transparent и –lossy_8bit полностью обратимыми: их результат оценивается по назначению файла, а исходник хранится отдельно.
7. Для пакетной обработки выборочно проверить несколько разных типов изображений, а не только один образец.

FAQ

Zopflipng и Zopfli — это одно и то же?

Нет. Zopfli — общая библиотека и компрессор для Deflate/zlib/gzip. ZopfliPNG — PNG-оптимизатор в том же проекте, а zopflipng — имя его командного исполняемого файла.

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

Нет. Официальный компонент работает из командной строки. Для GUI на macOS можно использовать отдельные программы вроде ImageOptim, которые способны подключать несколько движков оптимизации, включая Zopfli.

Нужен ли интернет для сжатия PNG?

Нет. После установки или сборки изображения обрабатываются локально. Учётная запись и облачная загрузка не входят в рабочий процесс Zopflipng.

Всегда ли оптимизация без потерь?

Пиксельный результат стандартного режима проверяется на совпадение, но программа по умолчанию удаляет многие ancillary chunks. Поэтому метаданные и некоторые сведения о цвете или физическом размере файла могут исчезнуть. Кроме того, –lossy_transparent и –lossy_8bit специально изменяют данные.

Почему программа иногда оставляет исходный размер?

Если оптимизированный вариант не меньше, Zopflipng по умолчанию сохраняет исходный PNG. Это защита от бессмысленного увеличения файла. Принудительно записать Zopfli-вариант можно через –always_zopflify, но этот режим предназначен прежде всего для сравнения.

Можно ли обрабатывать много PNG одной командой?

Да. Режим –prefix принимает несколько входных файлов и создаёт выходные имена с заданным префиксом. Для автоматического подтверждения перезаписи предусмотрен -y.

Что делает –keepcolortype?

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

Стоит ли ставить –iterations=500 для каждого файла?

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

Подходит ли Zopflipng для JPEG или WebP?

Нет. Его подтверждённый интерфейс предназначен для PNG на входе и PNG на выходе. Для других форматов нужен отдельный кодек или конвертер.

Получает ли Zopflipng обновления от Google в 2026 году?

Нет активного upstream-развития: репозиторий google/zopfli архивирован 14 октября 2025 года и доступен только для чтения. Сторонние менеджеры пакетов ещё могут пересобирать версию 1.0.3 или поддерживать собственные патчи.

Итог: когда Zopflipng остаётся разумным выбором

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

Для нового проекта с регулярной массовой оптимизацией приоритет обычно смещается к OxiPNG: активная разработка и многопоточность лучше отвечают современному пайплайну. Пользователю macOS без желания работать в терминале проще взять ImageOptim. Для старой инфраструктуры, где zopflipng уже встроен и даёт измеримый выигрыш, срочной технической причины отказываться от него нет, но архивный статус upstream нужно зафиксировать в документации проекта.

Главное условие безопасного применения — не путать «без изменения видимых пикселей» с «сохранением всех данных PNG». Перед публикацией следует решить судьбу цветовых и служебных chunks, не включать lossy-флаги автоматически и проверять результат в целевом декодере. При таком подходе Zopflipng остаётся понятным специализированным инструментом, а не универсальной программой для обработки изображений.