Pngwolf нужен тогда, когда PNG уже получен и требуется выжать из его IDAT-потока ещё немного размера без изменения видимых пикселей: программа перебирает варианты построчных PNG-фильтров, оценивает их через Deflate и ищет более удачную комбинацию генетическим алгоритмом. Это инструмент не для ретуши и не для конвертации форматов, а для разработчиков, веб-мастеров, авторов интерфейсной графики и тех, кто собирает цепочку глубокой оптимизации PNG и готов обменять время процессора на потенциально меньший файл.
- Ретушь портретов и удаление объектов
- Замена и размытие фона
- 200+ эффектов и 3D-LUT
- Не поддерживает interlaced PNG
- Не уменьшает палитру и битность
- Нет GUI и пакетного режима
Что именно оптимизирует Pngwolf
PNG хранит изображение не как простой массив уже сжатых пикселей. Перед Deflate-сжатием каждая строка может быть преобразована одним из пяти стандартных фильтров: None, Sub, Up, Average или Paeth. Фильтр не меняет изображение после декодирования: он лишь меняет представление байтов перед компрессором. Удачный фильтр превращает последовательности пиксельных данных в более предсказуемые разности и повторяющиеся значения, которые Deflate кодирует компактнее. Неудачный фильтр, наоборот, может сделать поток менее удобным для сжатия.
В обычных PNG-кодировщиках выбор фильтра выполняется эвристикой: для каждой строки оценивается один или несколько вариантов, после чего выбирается предположительно хороший. Pngwolf идёт дальше. Он рассматривает всю последовательность фильтров для изображения как решение, которое можно изменять, скрещивать и оценивать. Для изображения высотой 1200 строк это фактически последовательность из 1200 значений, каждое из которых может быть одним из пяти фильтров. Полный перебор невозможен, поэтому программа строит стартовую популяцию из нескольких осмысленных вариантов и случайных комбинаций, а затем постепенно ищет варианты с меньшим сжатым IDAT.
Важно понимать границу задачи. Pngwolf не меняет цветовой тип PNG ради экономии, не переводит RGB в палитровый режим, не уменьшает битность, не вычищает текстовые, цветовые и прочие дополнительные chunks как специализированный «санитар» PNG. Он сосредоточен прежде всего на комбинации scanline-фильтров и повторном Deflate-сжатии. Именно поэтому на практике его разумно ставить ближе к концу цепочки, после инструментов, которые умеют сокращать палитру, нормализовать структуру и удалять ненужные дополнительные данные.
Почему Pngwolf может уменьшить уже сжатый PNG
Два PNG с абсолютно одинаковыми пикселями могут иметь разный размер. Причина не только в настройке Deflate, но и в том, какие фильтры были выбраны для строк. Если на одной части картинки лучше работает Sub, на другой Paeth, а на третьей None, единая стратегия или локальная эвристика кодировщика не обязана найти глобально удачную последовательность. Pngwolf рассматривает последовательность целиком и пытается находить улучшения, которые становятся видны только после полного сжатия IDAT.
Оценка кандидатов выполняется более быстрым компрессором zlib. Программа многократно рефильтрует данные и сжимает полученный поток, получая число байтов как целевую функцию: меньше — лучше. После завершения поиска найденный вариант пересжимается реализацией Deflate из 7-Zip, ориентированной на степень сжатия. В исходном коде дополнительно предусмотрена проверка: если быстрый zlib с выбранными параметрами неожиданно даёт меньший результат, программа может оставить именно его поток вместо 7-Zip.
Эта архитектура объясняет и сильную сторону, и главный минус Pngwolf. Качество решения привязано к реальному размеру Deflate-потока, а не к упрощённой локальной оценке строки. Но каждый кандидат требует полного прохода компрессора по данным. На крупном изображении или при длинном поиске число таких проходов быстро становится большим, поэтому Pngwolf не относится к утилитам, которые бездумно запускают на тысячи файлов с максимальными параметрами.
Какие PNG подходят лучше всего
На официальной странице автор отдельно отмечает, что Pngwolf особенно хорошо подходит для RGB и RGBA. Это логично: полноцветные изображения дают длинные строки данных и богатое пространство для выбора фильтров. На скриншотах интерфейсов, текстурах, картах, крупных элементах веб-графики и другом содержимом с закономерностями по строкам выбор фильтра действительно может заметно влиять на конечный IDAT.
Палитровые изображения Pngwolf тоже способен читать при допустимом PNG-устройстве, но он не перестраивает саму палитру и не меняет её размер. Если выигрыш скрывается именно в сокращении числа цветов, переупорядочивании палитры, снижении битности или переходе к другому цветовому типу, эту работу должен выполнить другой оптимизатор. Pngwolf полезен уже после того, как структурные преобразования сделаны.
Изображения с Adam7 interlace исходная программа не поддерживает. При таком входе она завершает работу с сообщением о том, что interlaced images are not supported. Это не косметическое ограничение интерфейса, а реальное ограничение алгоритма чтения строк: код ожидает обычную последовательность строк изображения. Если файл интерлейсный, сначала его нужно преобразовать внешним PNG-инструментом в non-interlaced вид, а затем уже запускать Pngwolf.
Установка и начало работы
Pngwolf — консольная утилита. После получения готового исполняемого файла её обычно помещают в отдельную рабочую папку или каталог, присутствующий в переменной PATH, после чего запускают из терминала. Графического окна с drag-and-drop, очередью файлов и ползунком качества у исходного Pngwolf нет, поэтому вся логика задаётся параметрами командной строки.
Минимальная команда состоит из входного и выходного пути:
pngwolf --in=input.png --out=output.png
Параметры передаются в форме --name=value, а переключатели без значения — отдельными флагами. Для путей с пробелами их нужно заключать в кавычки средствами командной оболочки. На Windows это, например, выглядит так:
pngwolf --in="C:Imagessource file.png" --out="C:Imagessource file.optimized.png"
У параметра --out есть важная особенность: без него Pngwolf не создаёт итоговый PNG. Программа может проанализировать вход, провести поиск и вывести статистику, но сохранение основного PNG выполняется только когда указан выходной путь. Поэтому для обычного рабочего сценария всегда задавайте отдельный файл результата и лишь после проверки решайте, заменять ли оригинал.
Сборка исходного Pngwolf из кода требует GAlib, исходников 7-Zip и zlib. В официальном README описан вариант с CMake и ручной компоновкой. Это имеет смысл в первую очередь для разработчиков и исследователей, которые хотят воспроизвести исходную реализацию или изменить алгоритм; обычному пользователю проще работать с уже собранным бинарником.
Первый безопасный запуск
Для первого знакомства лучше не начинать с агрессивных параметров 7-Zip и не отключать ограничители. Возьмите копию PNG, задайте отдельный выход и небольшой лимит стагнации:
pngwolf --in=source.png --out=source.pw.png --max-stagnate-time=5 --verbose-summary
Такой запуск делает три полезные вещи. Во-первых, оригинал остаётся нетронутым. Во-вторых, поиск останавливается, если несколько секунд не удаётся улучшить найденный результат. В-третьих, расширенная сводка показывает последовательность лучшего решения, время оптимизации, число оценённых геномов и разницу размера IDAT. Для практической настройки это информативнее, чем ориентироваться только на общий размер файлов в проводнике.
Как читать базовый вывод
Даже без расширенной подробности Pngwolf печатает краткую информацию об изображении: размеры, глубину, цветовой режим, размер распакованного IDAT и исходный размер Deflate-потока. Во время поиска каждая найденная лучшая комбинация отражается строкой с новым размером IDAT по оценке zlib. В конце программа сообщает, сколько байтов получилось выиграть или, если улучшения не вышло, насколько кандидат был бы больше исходного.
Размер IDAT и размер всего PNG — не одно и то же. Файл содержит сигнатуру, IHDR и может содержать PLTE, tRNS, gAMA, iCCP, текстовые данные и другие chunks. Pngwolf меняет именно набор IDAT chunks, собирая новый IDAT с найденными данными, а прочие chunks переносит. Поэтому сообщение о сокращении IDAT на 500 байт не обязательно означает, что весь файл уменьшится ровно на 500 байт: может немного измениться и служебный накладной размер, особенно если несколько старых IDAT заменяются одним.
Если задача — понять, из чего вообще состоит файл, полезен режим --info. Он включает подробный анализ и завершает работу до генетического поиска. Это быстрый способ посмотреть размеры, цветовой режим, битность, интерлейс, ширину строки и список chunks, не тратя время на оптимизацию.
pngwolf --in=source.png --info
Режимы подробного вывода
Pngwolf разделяет подробность на три группы. --verbose-analysis расширяет стартовый анализ файла. --verbose-summary даёт подробную итоговую сводку. --verbose-genomes печатает больше данных при каждом улучшении, включая последовательность фильтров и счётчики поиска. Флаг --verbose включает все три режима сразу.
Для единичной ручной оптимизации обычно достаточно --verbose-summary. Полный --verbose полезнее при исследовании того, почему один файл оптимизируется долго, а другой почти мгновенно, или при подборе эвристик. На высоких изображениях подробная печать генома может быть очень длинной: по сути это последовательность чисел 0–4 по одной цифре на строку изображения.
Формат отчёта построен так, чтобы его можно было машинно разбирать; автор прямо указывает на YAML-подобную структуру прогресса. Это удобно при экспериментах, когда требуется собирать статистику по сериям запусков. Но не стоит трактовать вывод как полностью строгий универсальный YAML для произвольного повреждённого PNG: в исходном коде есть замечание, что имена chunks выводятся без сложной защиты от некорректных типов.
Пять фильтров PNG, с которыми работает программа
Каждая строка PNG перед Deflate начинается с байта типа фильтра. Значение 0 означает None: байты строки идут без преобразования. Такой вариант нередко неожиданно хорош для уже структурированных данных или для участков, где соседние значения не дают полезной корреляции.
Фильтр Sub, значение 1, хранит разницу текущего байта с соответствующим байтом предыдущего пикселя в той же строке. На горизонтальных градиентах и повторяющихся цветах разности часто становятся малыми и хорошо сжимаются.
Up, значение 2, сравнивает байт с байтом над ним. Он полезен, когда соседние строки похожи друг на друга, что типично для больших ровных областей, вертикальных градиентов и интерфейсных элементов.
Average, значение 3, использует среднее между левым и верхним соседями. Paeth, значение 4, применяет предиктор, выбирающий одно из соседних значений по оценке близости. На сложных изображениях они иногда дают лучший поток, но универсального победителя нет. Именно отсутствие универсального фильтра и делает задачу выбора комбинации интересной.
Pngwolf формирует стартовые кандидаты, где все строки принудительно используют один фильтр, сохраняет вариант с фильтрами исходного изображения и добавляет несколько эвристических последовательностей. Затем генетический поиск может смешивать удачные участки этих решений. Поэтому программа не просто перебирает пять глобальных режимов, а ищет собственный фильтр для каждой строки.
Стартовые эвристики Pngwolf
Перед генетическим циклом Pngwolf не начинает с чистого случайного набора. В исходном коде создаются несколько именованных решений. Помимо исходной последовательности и пяти вариантов «все строки одним фильтром», есть базовая эвристика PNG, вариант deflate scanline, эвристики distinct bytes и distinct bigrams, а также incremental. Каждая из этих последовательностей оценивается тем же способом — по размеру сжатого IDAT, — а затем при отсутствии исключающих флагов попадает в стартовую популяцию.
Базовая эвристика следует классической идее: для каждой строки оценивается сумма абсолютных значений отфильтрованных байтов и выбирается вариант с меньшей суммой. Это дешёвая оценка, но она не знает, как вся последовательность будет вести себя внутри Deflate. Поэтому Pngwolf рассматривает её лишь как одну из точек старта, а не как окончательное решение.
Эвристика distinct bytes смотрит на число различных байтов после фильтрации строки, а distinct bigrams — на разнообразие двухбайтовых последовательностей. Меньшее разнообразие потенциально создаёт более удобный материал для словаря и кодирования Deflate. Эти идеи появились именно как попытка лучше приблизить будущую сжимаемость, не выполняя дорогой полноценный поиск для каждой возможной последовательности.
Incremental-подход ещё ближе к реальному компрессору. Для очередной строки код копирует текущее состояние zlib, пробует каждый доступный фильтр, завершает тестовое сжатие и сравнивает полученный размер. Победивший фильтр добавляется в основной поток, после чего процесс переходит к следующей строке. Эта эвристика дороже простых счётчиков, но она учитывает контекст предыдущих строк.
Наконец, deflate scanline оценивает строки через сжатие и также стремится выбирать вариант, который лучше выглядит с точки зрения Deflate. Важно, что эти эвристики не являются отдельными режимами конечного файла. Они создают кандидатов, от которых затем отталкивается генетический алгоритм.
Как устроен генетический поиск
В терминах Pngwolf один «геном» — это последовательность фильтров для всех строк. Целевая функция — размер данных после zlib-сжатия. Чем меньше число байтов, тем лучше кандидат. Исходный код использует инкрементальную генетическую схему GAlib, турнирный селектор, отсутствие fitness scaling и двухточечный crossover. Это значит, что при скрещивании два решения могут обмениваться крупными непрерывными участками последовательности фильтров.
Именно двухточечное скрещивание хорошо соответствует интуиции автора: один кандидат может быть особенно удачным для верхней части изображения, другой — для нижней. Если вырезать средний или крайний участок и совместить удачные области, иногда получается комбинация, которая сжимается лучше обоих родителей. Затем алгоритм повторяет шаги и фиксирует новый лучший результат только когда целевая функция действительно улучшается.
Результат недетерминирован. В стартовой популяции присутствуют случайные кандидаты, а сам генетический алгоритм использует случайность при эволюции. Поэтому два запуска на одном файле с одинаковыми лимитами не обязаны пройти один и тот же путь и закончиться идентичным IDAT. Это не ошибка программы. Если требуется воспроизводимая сборка байт-в-байт, Pngwolf следует применять осознанно: либо фиксировать полученный артефакт, либо исключать его из стадий, где точное совпадение файла важнее нескольких потенциально выигранных байтов.
Почему «дольше» не означает гарантированно «меньше»
Увеличение времени повышает число проверенных комбинаций, но не даёт математической гарантии глобального минимума. Пространство последовательностей растёт экспоненциально с высотой изображения. Генетический поиск может долго исследовать локально удачную область и не встретить другой, более сильный вариант. Поэтому параметры времени нужно воспринимать как бюджет поиска, а не как шкалу качества с гарантированным результатом.
На практике полезнее искать точку убывающей отдачи. Если типовые иконки перестают улучшаться после одной-двух секунд стагнации, ждать минуту на каждом файле обычно неразумно. Если же речь о нескольких крупных ресурсах, которые будут распространяться миллионы раз, более длинный поиск может быть оправдан. Решение должно исходить из стоимости CPU на этапе подготовки и ценности каждого сэкономленного байта на этапе доставки.
Ограничение поиска через —max-stagnate-time
--max-stagnate-time=<seconds> завершает генетический цикл, если в течение заданного числа секунд не появилось улучшение. В исходной реализации значение по умолчанию равно 5. Это один из самых практичных параметров Pngwolf, потому что он привязывает время не к общей длительности процесса, а к отсутствию прогресса.
Например:
pngwolf --in=ui.png --out=ui.pw.png --max-stagnate-time=10
Такой запуск продолжится, пока алгоритм время от времени находит более компактный вариант. Если улучшений нет десять секунд, поиск прекращается и программа переходит к финальному пересжатию. На файлах, где стартовые эвристики уже дали почти оптимальную последовательность, это не заставляет ждать установленный срок с момента запуска: отсчёт связан с последним улучшением.
Нулевое значение отключает этот ограничитель. Делать так стоит только вместе с другим лимитом — например, --max-time или --max-evaluations. Иначе поиск может продолжаться очень долго, особенно на больших изображениях.
Общий лимит —max-time
--max-time=<seconds> задаёт максимальное время от запуска программы до прекращения генетического поиска. Значение 0 означает отсутствие такого лимита. Этот параметр удобен в автоматизированных сборках, где для каждой картинки нужно заранее ограничить бюджет времени.
pngwolf --in=hero.png --out=hero.pw.png --max-time=30 --max-stagnate-time=5
Комбинация двух лимитов обычно разумнее одного. Первый не позволяет единичному сложному файлу задержать весь процесс, второй быстро завершает поиск, когда улучшения прекратились. Обратите внимание: финальный Deflate-проход выполняется после генетического цикла, поэтому стеночное время процесса может быть немного больше заданного --max-time. Сам лимит проверяется внутри поискового цикла, а не вокруг всего процесса как внешний таймер.
Лимит числа оценок —max-evaluations
Параметр --max-evaluations=<int> останавливает поиск после заданного числа оценённых геномов. Он полезен там, где хочется нормировать не секунды, а объём алгоритмической работы. На разных процессорах одинаковое число оценок занимает разное время, зато сравнительные эксперименты становятся проще: можно запускать набор файлов с одинаковым числом проверок.
pngwolf --in=test.png --out=test.pw.png --max-stagnate-time=0 --max-evaluations=1000
Если используется именно такой режим, отключение лимита стагнации делает результат эксперимента понятнее: каждая картинка получает примерно одинаковый потолок числа оценок. Но для повседневной оптимизации число 1000 нельзя считать универсальной рекомендацией. Стоимость одной оценки зависит от объёма распакованных IDAT-данных, поэтому тысяча геномов для маленькой пиктограммы и для многомегапиксельной текстуры — совершенно разные по времени задачи.
Лимит объёма Deflate через —max-deflate
--max-deflate=<megabytes> ограничивает приблизительный объём данных, прогнанных через оценочный Deflate. В коде счётчик строится как число оценённых геномов, умноженное на размер распакованного IDAT, затем переводится в мегабайты. Это не объём записанных временных файлов и не размер оперативной памяти, а внутренний бюджет работы компрессора.
Такой лимит полезен, если входные картинки сильно различаются по размеру и хочется, чтобы большой PNG не получил столько же оценок, сколько маленький. Значение 0 отключает проверку. Как и с другими ограничителями, для производственной цепочки лучше сначала измерить поведение на собственной выборке и выбрать бюджет из реальных временных требований.
Размер популяции —population-size
По умолчанию размер популяции равен 19. Параметр --population-size=<int> позволяет изменить его. Слишком маленькая популяция уменьшает генетическое разнообразие и может затруднить поиск новых удачных комбинаций; слишком большая делает каждый этап эволюции тяжелее и требует больше времени.
Сам автор в комментариях исходного кода подчёркивает, что значение подобрано эмпирически и нет убедительных доказательств, что тонкая настройка этого параметра даёт большой выигрыш. Поэтому --population-size — скорее исследовательский рычаг, чем настройка, которую стоит трогать в каждом рабочем профиле.
Если вы экспериментируете, сравнивайте не единичные запуски, а серию на одной выборке PNG и фиксированном бюджете времени или оценок. Из-за случайности генетического поиска один удачный прогон с большой популяцией ещё не доказывает, что параметр стабильно лучше.
Параметры zlib как оценочного компрессора
Pngwolf использует zlib во время оценки кандидатов. Доступны четыре настройки: --zlib-level, --zlib-strategy, --zlib-window и --zlib-memlevel. По умолчанию в исходном коде используются level 5, strategy 0, window 15 и memlevel 8.
| Параметр | Допустимые значения | Назначение |
|---|---|---|
--zlib-level |
0–9 | Уровень сжатия оценочного zlib |
--zlib-memlevel |
1–9 | Объём внутренних структур zlib |
--zlib-window |
8–15 | Размер окна Deflate в битах |
--zlib-strategy |
допустимые стратегии zlib | Стратегия поиска и кодирования совпадений |
Здесь есть важная тонкость: оценочный компрессор не просто формирует временный поток, он ранжирует геномы. Изменение zlib-настроек может поменять то, какие последовательности алгоритм считает хорошими. Более высокий level не гарантирует, что найденная последовательность окажется лучше после финального 7-Zip-сжатия. Авторские тесты на официальной странице как раз показывали, что настройка оценщика может заметно менять результаты, причём не всегда в ожидаемую сторону.
Для обычной работы разумно сначала оставить zlib-параметры по умолчанию и управлять только бюджетом поиска. Тонкая настройка имеет смысл, если у вас большая однородная выборка — например, тысячи UI-ресурсов одного происхождения — и есть время провести контролируемый тест разных профилей.
Что означает —zlib-strategy
Исходная версия принимает стратегии, которые zlib обозначает как DEFAULT, FILTERED, HUFFMAN_ONLY и RLE. Числовое значение передаётся напрямую. Это не «качество картинки» и не выбор PNG-фильтра; речь о поведении самого Deflate-компрессора. Менять параметр без понимания zlib обычно не стоит, потому что он влияет на оценку всех геномов и может существенно изменить скорость.
Финальное сжатие через 7-Zip
После того как генетический поиск выбрал лучшую последовательность фильтров по оценке zlib, Pngwolf заново формирует отфильтрованный поток и сжимает его Deflate-реализацией 7-Zip. Для неё доступны --7zip-mfb, --7zip-mpass и --7zip-mmc.
| Параметр | Смысл | Исходное значение |
|---|---|---|
--7zip-mfb |
Fast bytes, диапазон 3–258 | 258 |
--7zip-mpass |
Число проходов 1–15 или auto | 2 |
--7zip-mmc |
Циклы match finder | 258 |
Большее число проходов обычно означает более медленное финальное сжатие и потенциально меньший поток, но это не строгая монотонная шкала. Deflate-оптимизация имеет сложное поведение, и экстремальная настройка иногда проигрывает более умеренной. Поэтому максимальные значения стоит применять после тестов, а не как безусловный «режим качества 100%».
Для --7zip-mpass доступно значение auto. В этом режиме Pngwolf снижает число проходов для крупных распакованных данных: код оценивает размер относительно блоков по 64 КБ и выбирает меньше проходов по мере роста входа. Идея практическая — не тратить чрезмерное время 7-Zip на большие изображения, где дополнительные проходы могут дать мало экономии.
Почему итог иногда берётся не из 7-Zip
Хотя архитектура программы рассчитана на финальный 7-Zip, исходный код после такого сжатия сравнивает размер с оценкой лучшего генома. Если поток 7-Zip оказался больше, Pngwolf повторно сжимает отфильтрованные данные быстрым zlib и может использовать его результат. Это защищает от ситуации, когда выбранная комбинация фильтров действительно удачна, но конкретные параметры финального компрессора дали менее компактный поток.
После этого выполняется ещё одна защита: если лучший новый IDAT всё равно больше исходного и не указан --even-if-bigger, программа возвращает исходные IDAT-данные. Иными словами, в стандартном режиме Pngwolf не должен сознательно увеличивать IDAT только ради завершения алгоритма.
Флаг —normalize-alpha и прозрачные пиксели
Для 8-битного RGBA Pngwolf умеет находить полностью прозрачные пиксели, у которых alpha равна нулю, но RGB-каналы содержат ненулевые значения. На экране такие цвета не видны, однако их байты всё равно попадают в IDAT и могут мешать Deflate находить повторяющиеся шаблоны. Флаг --normalize-alpha заменяет такие пиксели на полностью прозрачный чёрный, то есть обнуляет четыре байта RGBA.
pngwolf --in=icon.png --out=icon.alpha.png --normalize-alpha --max-stagnate-time=5
На официальной странице приведён показательный пример, где такая нормализация уменьшила IDAT заметно сильнее обычного рефильтрования. Но этот режим намеренно выключен по умолчанию: преобразование не является строго lossless на уровне исходных каналов. Визуальный результат при обычном альфа-композитинге не меняется, а скрытые RGB-значения меняются.
Это различие критично для игровых и технических ресурсов. Полностью прозрачные пиксели могут хранить цвет для последующей фильтрации текстуры, предотвращения цветных ореолов на краях, пользовательских шейдеров, генерации mipmap или просто как контейнер данных. В таких файлах автоматически обнулять RGB нельзя. Для веб-иконок и обычных UI-изображений режим часто безопасен, но решение всё равно должно приниматься после понимания назначения ресурса.
Как проверить, есть ли смысл в нормализации
Запустите сначала только анализ:
pngwolf --in=icon.png --info
Для 8-битного RGBA подробный вывод содержит раздел invisible colors с количеством полностью прозрачных пикселей и их скрытыми цветами. Если все прозрачные пиксели уже чёрные, --normalize-alpha практически не даст дополнительной пользы. Если невидимых цветов много, режим потенциально улучшит сжимаемость, но сначала нужно решить, допустимо ли менять эти данные.
Полезная схема проверки — создать два результата: обычный и с нормализацией, сравнить размеры и затем прогнать оба через тест отображения в целевом приложении. Для ресурсов движка дополнительно проверьте масштабирование, линейную фильтрацию и генерацию mipmap, потому что именно там скрытые цвета способны проявиться на границе прозрачности.
Что делает —even-if-bigger
Стандартное поведение Pngwolf защищает от ухудшения: если после финального сжатия новый IDAT больше исходного, программа выбирает исходные IDAT-данные. Флаг --even-if-bigger отключает эту защиту и позволяет сохранить найденный вариант даже при увеличении.
В обычной оптимизации применять его незачем. Он нужен для экспериментов, сравнений компрессоров и исследования фильтров, когда важна сама найденная последовательность, а не размер готового файла. Например, исследователь может намеренно сохранить поток, который лучше выглядел по оценке zlib, но хуже сжался 7-Zip, чтобы изучить расхождение между оценщиком и финальным компрессором.
Если задача практическая — уменьшить PNG для сайта или приложения, этот флаг лучше не включать. Защитное поведение как раз делает Pngwolf удобнее для автоматической цепочки: неудачный файл не должен вырасти только потому, что оптимизатор обязан что-то записать.
Для чего существует —bigger-is-better
--bigger-is-better переворачивает порядок целевой функции: генетический алгоритм начинает искать последовательности, которые сжимаются хуже, то есть дают больший IDAT. Это исследовательская опция, а не режим оптимизации.
Она может быть полезна при изучении чувствительности Deflate к фильтрам, тестировании эвристик и построении противоположных примеров. Для нормальной подготовки изображений флаг противоречит цели Pngwolf и использовать его не нужно. Его наличие хорошо показывает исследовательский характер программы: исходный инструмент создавался не только как утилита «нажать и уменьшить», но и как площадка для изучения выбора PNG-фильтров.
Исключение стартовых кандидатов
Четыре флага позволяют управлять тем, какие решения попадут в начальную популяцию: --exclude-singles, --exclude-original, --exclude-heuristic и --exclude-experiments. Они предназначены прежде всего для экспериментов с алгоритмом.
--exclude-singlesубирает пять последовательностей, где все строки используют один и тот же фильтр.--exclude-originalне добавляет в стартовую популяцию последовательность из исходного PNG.--exclude-heuristicисключает базовую эвристику PNG.--exclude-experimentsотключает несколько экспериментальных эвристик, включая deflate scanline, distinct bytes, distinct bigrams и incremental.
Если исключить слишком много кандидатов, стартовая популяция станет беднее. Исходный код предусмотрительно создаёт случайный геном, если после всех исключений популяция оказалась пустой. Но это не означает, что такой профиль будет эффективнее. Для рабочего уменьшения файлов лучше оставить стартовые решения включёнными: они дают алгоритму несколько уже осмысленных точек вместо чисто случайного старта.
Экспорт исходного и лучшего IDAT
Pngwolf может сохранять IDAT-данные отдельно от PNG. Параметр --original-idat-to=<path.gz> записывает исходный поток, а --best-idat-to=<path.gz> — лучший итоговый поток. Оба помещаются в gzip-контейнер.
pngwolf --in=sample.png
--out=sample.pw.png
--original-idat-to=original.gz
--best-idat-to=best.gz
Эта возможность не нужна обычному веб-мастеру, зато полезна при исследовании Deflate. Можно извлечь потоки, повторно прогнать их через другой совместимый компрессор, сравнить эффективность на одной и той же фильтрации или анализировать отличие исходной и найденной последовательности без повторного разбора всего PNG-контейнера.
Не следует путать эти gzip-файлы с готовыми изображениями. Внутри находится поток данных IDAT в удобной оболочке для экспериментов, а не PNG с IHDR, палитрой и остальными chunks. Для просмотра картинки нужен обычный файл, указанный через --out.
Как Pngwolf обращается с остальными chunks
При сохранении Pngwolf читает исходные chunks в список, удаляет старые IDAT, создаёт один новый IDAT с лучшим сжатым потоком и вставляет его перед IEND. Остальные chunks переносятся. Это означает, что программа не предназначена для систематического удаления комментариев, профилей, временных метаданных и прочих ancillary chunks.
Практическое следствие: если PNG раздут не столько пикселями, сколько большим iCCP-профилем, XMP-подобными данными или текстовыми chunks, Pngwolf почти не поможет. В таком случае сначала нужен инструмент, который умеет безопасно удалить или нормализовать ненужные дополнительные данные, и только потом имеет смысл заниматься фильтрацией IDAT.
Обратная сторона — Pngwolf не пытается агрессивно вычищать то, что может иметь значение. Если в вашем процессе важно сохранить цветовой профиль или текстовую информацию, стандартный проход Pngwolf не ориентирован на их удаление. Но сохранение chunk не следует считать полноценной валидацией: исходный код специально не реализует строгую проверку всей структуры PNG и допускает, что некорректный файл может быть переписан в столь же некорректном виде.
Проверка структуры входного PNG
Перед оптимизацией программа проверяет сигнатуру PNG, наличие IDAT, количество IEND, размеры изображения, метод фильтрации и сжатия, базовые свойства битности и цветового типа. Она также распаковывает IDAT через zlib и проверяет ожидаемый размер строк. Если поток не соответствует ожиданиям, чтение завершается ошибкой.
При этом Pngwolf не позиционируется как строгий валидатор спецификации. В исходном коде есть явные замечания, что не проверяется, является ли IHDR первым и единственным, а также не полностью проверяются все допустимые сочетания цветового типа и битности. Поэтому для контроля качества входного массива лучше использовать специализированный PNG-checker или современный оптимизатор с полноценной диагностикой, а Pngwolf оставлять задачей компрессии.
Поддерживаемые цветовые типы и битность
Внутренний mapping исходного Pngwolf допускает стандартные типы 0, 2, 3, 4 и 6: grayscale, truecolor RGB, indexed-color, grayscale with alpha и truecolor with alpha. Зарезервированные значения 1 и 5 отклоняются. Битность должна быть степенью двойки в диапазоне от 1 до 16, но код отдельно предупреждает, что не проверяет полностью соответствие каждой битности каждому цветовому типу по спецификации.
Для собственно фильтрации вычисляется число байтов на пиксель с учётом количества каналов и битности. На суббайтовых палитровых и grayscale-данных это особенно важно: PNG-фильтры работают по байтам сформированной scanline, а не по логическим цветам. Pngwolf не распаковывает палитровый PNG в RGB ради поиска — он работает с формой данных, соответствующей входному типу.
Дополнительный анализ невидимых цветов и --normalize-alpha реализован только для 8-битного RGBA, то есть color type 6 и depth 8. Не стоит ожидать, что тот же флаг аналогично обработает 16-битный RGBA или grayscale+alpha: соответствующий участок исходной реализации явно ограничен этим случаем.
Почему interlaced PNG не работает
Adam7 разбивает изображение на семь проходов с разреженным расположением пикселей. У такого файла «строка» внутри распакованного IDAT уже не соответствует простой строке конечного изображения, как в non-interlaced PNG. Алгоритм Pngwolf построен вокруг последовательности строк и одного значения фильтра для каждой строки, поэтому реализация Adam7 потребовала бы отдельной логики для проходов и их размеров.
Автор прямо решил не реализовывать это, поскольку основная цель — минимизация размера, а interlace часто выбирают ради прогрессивного отображения, а не максимальной компактности. Если сохранение Adam7 важно по функциональным причинам, исходный Pngwolf не подходит для такого файла. Если interlace не нужен, предварительно переведите картинку в обычный PNG и только потом оптимизируйте.
Прерывание Ctrl+C и сохранение найденного результата
Одна из полезных особенностей Pngwolf — обработка пользовательского прерывания во время генетического поиска. На Windows устанавливается обработчик консольных событий, на Unix-подобных системах — SIGINT. Первое прерывание устанавливает флаг завершения, после чего цикл выходит и программа переходит к финальному пересжатию уже найденного лучшего генома.
Это означает, что если вы запустили слишком длинный поиск и решили остановить его, не обязательно терять весь прогресс. Нажатие Ctrl+C в фазе поиска должно привести к корректному завершению и сохранению результата, если задан --out. Именно поэтому Pngwolf удобнее экспериментальных утилит, которые при прерывании просто теряют вычисления.
Есть важная деталь: перед финальной тяжёлой рекомпрессией обработчик SIGINT снимается. Автор сделал это намеренно, чтобы пользователь мог прервать сам финальный 7-Zip-проход. Поэтому повторное Ctrl+C уже на стадии конечного компрессора способно завершить процесс без сохранения нового PNG. На практике после первого прерывания имеет смысл дождаться итоговой сводки, а не нажимать комбинацию несколько раз подряд.
Что сохраняется при отсутствии улучшения
Если найденная последовательность после финального сжатия не превосходит исходный IDAT и не задан --even-if-bigger, Pngwolf возвращается к исходным сжатым данным. При указанном --out будет записан новый PNG-контейнер с прежним IDAT и перенесёнными chunks.
Поэтому общий размер выходного файла в редких случаях может не совпасть с исходным байт-в-байт, даже если IDAT выбран исходный. Причина — пересборка контейнера и объединение IDAT. В практической проверке нужно смотреть не только на финальную фразу программы, но и на реальный размер выходного файла.
Если сохранение полностью неизменного файла при отсутствии выигрыша важно, удобнее делать эту политику внешним скриптом: писать результат во временный путь, сравнивать размер всего файла и заменять оригинал только при фактическом уменьшении. Так можно учесть не только IDAT, но и все накладные байты контейнера.
Пакетная обработка: чего в Pngwolf нет
Исходный интерфейс принимает один --in и один --out. Встроенной очереди каталогов, масок *.png, рекурсивного обхода и многопоточной диспетчеризации набора файлов нет. Если нужно обработать папку, цикл организует командная оболочка или система сборки.
В PowerShell подход может выглядеть так:
Get-ChildItem .src -Filter *.png | ForEach-Object {
$out = Join-Path .optimized $_.Name
& .pngwolf.exe --in=$_.FullName --out=$out --max-stagnate-time=3
}
В POSIX-оболочке аналогичная идея:
for f in src/*.png; do
pngwolf --in="$f" --out="optimized/$(basename "$f")" --max-stagnate-time=3
done
Такие циклы — внешняя автоматизация, а не функция Pngwolf. При параллельном запуске нескольких процессов учитывайте нагрузку: каждый процесс многократно сжимает полный IDAT. Запуск по числу логических ядер не всегда оптимален, особенно если изображения крупные и финальный компрессор уже интенсивно использует CPU и память.
Практический профиль для единичного PNG
Для одного важного файла лучше двигаться от простого к сложному. Сначала сохраните исходник отдельно и выполните короткий запуск с подробной сводкой:
pngwolf --in=asset.png --out=asset.pw.png --max-stagnate-time=5 --verbose-summary
Если выигрыш получился заметным и время приемлемо, можно проверить более длинный бюджет:
pngwolf --in=asset.png --out=asset.pw10.png --max-stagnate-time=10 --max-time=60 --verbose-summary
Сравнивайте именно итоговые файлы, а не только промежуточные zlib-оценки. Если разница между 5 и 10 секундами стагнации составляет несколько байтов, профиль на 10 секунд может быть невыгоден для массовой обработки. Если же один крупный ресурс уменьшается ещё на несколько килобайт и потом будет многократно распространяться, более длинный проход может иметь смысл.
Сценарий: веб-иконки и элементы интерфейса
PNG-иконки часто имеют большие прозрачные поля, резкие границы и повторяющиеся цвета. Сначала стоит убедиться, что цветовой тип и палитра уже выбраны рационально: если иконка использует десяток цветов, палитровый PNG способен быть значительно меньше RGBA, а Pngwolf сам такой переход не выполняет.
После структурной оптимизации Pngwolf можно поставить последним проходом. Для набора статических иконок разумно дать короткий бюджет на файл — например, несколько секунд стагнации. Если --info показывает много ненулевых цветов под полностью прозрачной альфой, отдельно протестируйте --normalize-alpha. Для обычной веб-иконки это часто безопасно, но после изменения всё равно проверьте края на светлом и тёмном фоне.
Не нужно автоматически применять режим прозрачности к исходникам дизайнера, если они затем будут масштабироваться, перерабатываться или импортироваться в игровой движок. Лучше держать мастер-файлы нетронутыми, а нормализацию использовать только на финальных артефактах доставки.
Сценарий: скриншоты приложений
Скриншоты содержат большие области ровного цвета, текст, границы окон и повторяющиеся панели. Такое содержимое часто хорошо сжимается в PNG и чувствительно к выбору фильтров. Перед Pngwolf полезно проверить, не может ли изображение без потерь перейти в палитровый режим: для интерфейса с ограниченным количеством цветов это иногда даёт куда больший эффект, чем любые игры с Deflate.
Если скриншот остаётся RGB или RGBA, Pngwolf становится логичным финальным оптимизатором. На больших снимках не снимайте все лимиты: высота 2000–4000 пикселей означает такую же длину генома и многократную обработку больших строк. Начинайте с --max-stagnate-time=2 или 3, смотрите на выигрыш, а затем решайте, стоит ли повышать бюджет.
Для публикации на сайте дополнительно сравните PNG с современными форматами доставки. Pngwolf уменьшает именно PNG; он не отвечает на вопрос, будет ли WebP или AVIF компактнее при приемлемой совместимости. Если PNG обязателен из-за прозрачности, точного lossless-представления или требований системы, тогда глубина его оптимизации действительно становится важной.
Сценарий: спрайты и UI-атласы
Большой UI-атлас — характерный случай, когда потенциальный выигрыш умножается на частоту загрузки, но и вычислительная цена Pngwolf становится высокой. Сначала выполните короткий тест на копии, чтобы понять, реагирует ли конкретная структура на генетический подбор. Если стартовые эвристики уже дают почти тот же размер, длинный поиск может не окупиться.
Особое внимание уделяйте --normalize-alpha. В атласах скрытые цвета прозрачных пикселей могут использоваться для корректной фильтрации по краям спрайтов. Обнуление способно породить тёмный контур при билинейной фильтрации, хотя при просмотре исходного PNG в обычном просмотрщике никакой разницы видно не будет. Для таких ресурсов стандартный lossless-проход без нормализации безопаснее.
Если атлас собирается автоматически, Pngwolf удобно запускать уже после упаковщика и других преобразований. Любая последующая операция, заново сохраняющая PNG, может заменить найденную последовательность фильтров своей эвристикой и тем самым уничтожить часть выигрыша. Поэтому позиция ближе к концу пайплайна принципиальна.
Сценарий: PNG-фотографии
Полноцветная фотография в PNG обычно велика по сравнению с форматами, рассчитанными на фото. Но бывают задачи, где нужен именно lossless PNG: эталонные изображения, тестовые наборы, графика с последующим пиксельным анализом, материалы без права на потери. В таких случаях Pngwolf может работать с RGB/RGBA и подбирать фильтры для длинных строк.
Не ожидайте, что подбор фильтров компенсирует сам выбор формата. Если можно использовать lossless WebP, AVIF lossless или другой формат, сравнение должно происходить отдельно. Pngwolf не меняет семантику PNG и не превращает его в более современный кодек. Его задача узкая: сделать конкретный PNG настолько компактным, насколько позволяет его подход.
На фотографиях особенно заметна вычислительная цена: IDAT большой, каждая оценка генома дорого стоит. Поэтому фиксированный лимит времени или стагнации практически обязателен. Для массового фотоархива Pngwolf обычно менее удобен, чем быстрый многопоточный оптимизатор.
Сценарий: ресурсы в репозитории
Если PNG хранятся в Git и проходят оптимизацию перед коммитом, учитывайте недетерминированность. Два разработчика могут получить разные, но визуально эквивалентные байтовые файлы из-за случайности поиска. Это создаёт лишние diff и затрудняет воспроизводимость сборки.
Один из практичных вариантов — запускать Pngwolf только централизованно при подготовке релиза, а не на каждом рабочем месте. Другой — после удачной оптимизации считать полученный PNG финальным артефактом и не пересохранять его без необходимости. Если строгая воспроизводимость важнее предельной экономии, современный детерминированный оптимизатор с фиксированными алгоритмами может лучше подходить для pre-commit.
Сценарий: статические ресурсы для CDN
Для редко меняющихся, но часто запрашиваемых PNG стоимость офлайн-оптимизации можно позволить себе один раз. Здесь Pngwolf наиболее логичен: вычисления происходят до публикации, а сэкономленные байты затем многократно экономятся на передаче.
Однако эффект нужно считать по реальному набору. Если после предварительной оптимизации файлы уменьшаются в среднем на доли процента, а сборка становится дольше на часы, возможно, выгоднее ограничить Pngwolf только крупными или самыми популярными ресурсами. Можно заранее отфильтровать файлы по размеру, а для мелких иконок применять быстрый профиль.
Не забудьте, что HTTP-сжатие не применяется к уже сжатому PNG так же эффективно, как к тексту. Поэтому уменьшение IDAT напрямую уменьшает передаваемый объект. Но экономию всё равно нужно сравнивать с альтернативными форматами и политикой кэширования.
Как построить цепочку из нескольких PNG-оптимизаторов
Pngwolf не пытается быть универсальным. Лучший порядок обычно такой: сначала структурные без потерь преобразования, затем удаление ненужных chunks, затем инструменты, которые пробуют разные методы Deflate и фильтрации, и ближе к концу — Pngwolf. Точный порядок зависит от того, какие инструменты способны переписать фильтры после него.
Если программа, запущенная после Pngwolf, полностью декодирует и заново кодирует PNG с собственным выбором фильтров, генетически найденная последовательность будет потеряна. Инструмент, который лишь оптимизирует контейнер без перекодирования IDAT, может быть безопаснее. Поэтому в цепочке важно понимать не название утилиты, а её фактическое действие.
Автор Pngwolf прямо рекомендовал использовать его последним или предпоследним. Это не рекламное утверждение, а следствие архитектуры: программа не делает многие структурные оптимизации, зато тратит время именно на финальную последовательность фильтров. Нет смысла искать её, а потом передавать изображение кодировщику, который выберет фильтры заново.
Как проверять результат после оптимизации
Минимальная проверка состоит из четырёх пунктов: файл открывается, размеры и цветовой тип ожидаемые, декодированные пиксели совпадают, размер действительно уменьшился. Последний пункт особенно важен, потому что Pngwolf сообщает разницу IDAT, а вам обычно важен весь файл.
Для строгой проверки lossless-режима декодируйте оба PNG внешним инструментом в одинаковое сырое представление и сравните хэш или пиксели. Сравнение файлов побайтно бессмысленно: фильтры и Deflate по определению меняют байты, сохраняя изображение. При использовании --normalize-alpha сравнение RGBA побайтно уже должно показать разницу в полностью прозрачных пикселях — это ожидаемо.
Для веб-графики дополнительно проверяйте открытие в нескольких браузерных движках, если PNG необычный по битности или цветовым chunks. Pngwolf не должен менять их семантику, но строгая эксплуатационная проверка полезна всякий раз, когда оптимизируется большой массив статических ресурсов.
Проверка размера в автоматическом скрипте
Надёжная автоматизация пишет результат во временный путь и сравнивает размеры:
pngwolf --in=asset.png --out=asset.tmp.png --max-stagnate-time=3
# внешний скрипт сравнивает asset.png и asset.tmp.png
# меньший валидный файл заменяет исходный
Такой подход проще, чем пытаться интерпретировать текстовый вывод. Скрипт может одновременно проверить код завершения, наличие результата, декодируемость и условие «выход меньше входа».
Производительность без мифических цифр
У Pngwolf нельзя корректно назвать «скорость X файлов в секунду» без привязки к изображению и параметрам. Время зависит от размера распакованного IDAT, высоты, структуры данных, числа геномов, лимитов, zlib-настроек и параметров 7-Zip. Разные картинки одинакового размера на диске могут вести себя по-разному, потому что размер файла не равен объёму данных, которые многократно проходит оценщик.
Официальное описание честно предупреждает, что оптимизация может занимать минуты. Исторические авторские измерения показывали дополнительный выигрыш порядка процента на подходящих изображениях, уже прошедших другие оптимизаторы, но это не универсальная гарантия и тем более не прогноз для современных наборов. С тех пор изменились альтернативные инструменты, аппаратное обеспечение и типичные форматы контента.
Практически Pngwolf стоит оценивать как «дорогой финальный проход». Если нужен быстрый ежедневный pipeline, используйте короткую стагнацию или применяйте утилиту только к файлам выше порога размера. Если цель — один раз выжать максимум из нескольких критичных PNG, можно позволить более длинный бюджет.
Почему высота особенно важна
Геном содержит один фильтр на строку. Увеличение высоты увеличивает длину решения и объём данных, который надо рефильтровать. Ширина тоже влияет, потому что строка становится длиннее и каждый Deflate-проход обрабатывает больше байтов. Но высокая узкая картинка дополнительно создаёт длинную комбинацию фильтров и больше возможностей для скрещивания.
Поэтому профиль, хорошо работающий на иконках 256×256, нельзя автоматически переносить на скриншоты 3840×2160. Для больших изображений сначала уменьшайте бюджет и наблюдайте за отдачей.
Типичные ошибки запуска
Если команда выполнена без --in или с некорректным параметром, Pngwolf печатает справку и завершает работу. Параметры со значением должны содержать знак =. Запись вида --max-time 10 для исходной реализации неверна; нужна форма --max-time=10.
Если вход не является PNG, не читается, имеет неподдерживаемую структуру или распакованный IDAT не соответствует ожиданиям, программа выдаёт общее сообщение о проблеме чтения. Для interlaced PNG предусмотрено отдельное сообщение. Диагностика не столь подробна, как у современных CLI-утилит, поэтому при непонятной ошибке сначала проверьте файл сторонним валидатором.
Если выходной путь недоступен для записи, итоговая ошибка относится к записи файла. Проверьте существование каталога, права, блокировку другим приложением и корректность кавычек вокруг пути.
Ошибка «Interlaced images are not supported»
Это означает, что в IHDR установлен Adam7 interlace. Увеличение лимита времени, смена zlib level или отключение эвристик не поможет — формат строк не поддерживается на уровне чтения.
Решение: создать non-interlaced копию внешним PNG-кодировщиком, убедиться, что она отображается идентично, и уже её передать Pngwolf. Если interlace нужен в конечном файле, обратное преобразование после Pngwolf почти наверняка заново закодирует строки и сведёт смысл работы Pngwolf к минимуму. В таком сценарии лучше использовать оптимизатор, который непосредственно умеет работать с Adam7.
Файл не уменьшается
Это нормальный результат. Исходный PNG может уже иметь удачную последовательность фильтров и сильный Deflate-поток. Кроме того, если основная часть размера приходится на chunks вне IDAT, рефильтрование почти ничего не изменит.
Сначала посмотрите --info и подробный анализ. Сравните исходный filter sequence с размерами простых и экспериментальных эвристик. Если все варианты дают почти одинаковый IDAT, длинный генетический поиск вряд ли принесёт много. Попробуйте предварительно структурный оптимизатор, особенно для палитры и битности.
Не включайте --normalize-alpha только ради цифры, если скрытые RGB важны. Экономия размера не оправдывает изменение данных в ресурсе, где эти каналы имеют функциональное назначение.
Поиск занимает слишком много времени
Самая частая причина — отключённый или слишком большой --max-stagnate-time. Верните короткий предел в несколько секунд. Если единичный файл всё равно выходит за бюджет, добавьте --max-time или ограничение оценок.
Также не завышайте --population-size без причины и не ставьте максимальное число проходов 7-Zip на весь каталог. В больших пайплайнах выгоднее сделать два профиля: быстрый для большинства файлов и глубокий для нескольких крупных ресурсов, где экономия действительно важна.
Выходной файл больше исходного
В стандартном режиме Pngwolf старается не заменять исходный IDAT более крупным. Но размер всего PNG может вести себя иначе из-за пересборки chunks. Кроме того, --even-if-bigger прямо отключает защиту.
Проверьте, не используется ли этот флаг, сравните общий размер и смотрите итоговую сводку. Если автоматизация требует строгого правила «только уменьшать», реализуйте его внешним сравнением. Это полезно и при смене версии бинарника или библиотеки, потому что политика pipeline не должна зависеть от внутренних деталей одной утилиты.
Повреждённый или нестандартный PNG
Pngwolf умеет обнаруживать ряд проблем, но не является инструментом ремонта. Если файл вызывает общую ошибку чтения, сначала прогоните его через валидатор или декодируйте и пересохраните доверенным PNG-кодировщиком. После нормализации структуры повторите оптимизацию.
Не стоит пытаться «лечить» файл перебором параметров Pngwolf: параметры генетического поиска не меняют правила разбора контейнера. Если ошибка возникает до старта анализа, причина почти наверняка во входе, доступе к файлу или неподдерживаемой особенности.
Сравнение с аналогами
Pngwolf стоит сравнивать не по числу кнопок, а по типу задачи. Он оптимизирует уже существующий PNG на уровне scanline-фильтров и Deflate. ФотоМАСТЕР решает другую задачу — редактирование содержимого фотографии. OptiPNG, pngcrush и OxiPNG ближе к Pngwolf, но они охватывают более широкий набор преобразований PNG и по-другому балансируют скорость, полноту и удобство автоматизации.
| Инструмент | Основная задача | Что отличает | Когда уместнее Pngwolf |
|---|---|---|---|
| Pngwolf | Глубокий поиск фильтров PNG | Генетический алгоритм, лимиты поиска, отдельный IDAT | Когда нужен финальный дорогой проход по конкретному PNG |
| ФотоМАСТЕР | Редактирование фото | Ретушь, удаление объектов, замена фона, эффекты | Когда пиксели уже готовы и редактировать изображение не требуется |
| OptiPNG | Lossless-оптимизация PNG | Редукции цветового типа/битности, проверка, конвертация | Когда структурная оптимизация уже выполнена и нужен дополнительный поиск фильтров |
| pngcrush | Оптимизация и управление chunks | Перебор методов, удаление/добавление chunks | Когда нужны генетические комбинации, а не фиксированный набор проб |
| OxiPNG | Современная lossless-оптимизация PNG/APNG | Многопоточность, уровни оптимизации, metadata strip, Zopfli | Когда готовы заплатить временем за отдельный исследовательский финальный проход |
Pngwolf и ФотоМАСТЕР
ФотоМАСТЕР — полноценный фоторедактор. В актуальном описании разработчика заявлены замена и размытие фона, удаление объектов, автоматическая ретушь портретов, коррекция света и цвета, кадрирование, геометрические исправления, эффекты и работа с RAW. Это операции над содержимым изображения: пользователь принимает художественные и технические решения, а пиксели могут заметно меняться.
Pngwolf, напротив, не знает понятий «лицо», «фон», «объект», «экспозиция» или «небо». Он получает уже готовый PNG и пытается упаковать его IDAT компактнее. Поэтому эти программы не заменяют друг друга. Если нужно улучшить фотографию, убрать лишний предмет или заменить фон, работа выполняется в ФотоМАСТЕР или другом редакторе. Если после экспорта получен PNG и требуется минимизировать его без визуальной переработки, тогда появляется задача Pngwolf.
У ФотоМАСТЕР есть пакетная обработка в старших вариантах продукта, а также пользовательский GUI. Pngwolf работает из командной строки и не имеет встроенной пакетной очереди. Зато Pngwolf предоставляет низкоуровневые параметры, которые фоторедактору не нужны: лимиты генетического поиска, настройки zlib и 7-Zip, экспорт IDAT и управление стартовыми эвристиками.
Нельзя сравнивать их по принципу «у кого больше функций». Они находятся на разных уровнях workflow. Содержимое удобнее довести до готовности в редакторе, а оптимизацию контейнера и Deflate выполнять после финального экспорта. Если после Pngwolf снова открыть PNG и сохранить его в редакторе, редактор может перекодировать IDAT и удалить достигнутый выигрыш.
Pngwolf и OptiPNG
OptiPNG — более универсальный lossless-оптимизатор PNG. Он умеет не только перепробовать параметры IDAT, но и выполнять без потерь reductions: уменьшать битность, цветовой тип и палитру, если это возможно. Кроме того, он поддерживает проверку и коррекцию PNG и может конвертировать BMP, GIF, PNM и TIFF в оптимизированный PNG.
Именно эти возможности закрывают то, чего Pngwolf намеренно не делает. Например, если RGB-изображение содержит 64 уникальных цвета, Pngwolf будет оптимизировать его текущую структуру, а OptiPNG способен найти более компактное представление через палитру при сохранении визуальной семантики. Поэтому в комбинированной цепочке OptiPNG логично запускать раньше.
OptiPNG позволяет задавать уровень оптимизации и набор проб zlib-параметров. Его стратегия более детерминирована и привычна для пакетных задач. Pngwolf отличается тем, что рассматривает строковые фильтры как длинный геном и ищет комбинации эволюционным методом. Это способно дать дополнительный выигрыш на отдельных файлах, но требует больше времени и не заменяет reductions.
Если нужен один понятный инструмент для регулярной без потерь оптимизации каталога, OptiPNG обычно проще. Если структурная часть уже приведена в порядок и есть смысл тратить CPU на финальный поиск по строкам, Pngwolf можно добавить после него.
Pngwolf и pngcrush
pngcrush ориентирован на уменьшение IDAT через перебор комбинаций compression level, filter method и zlib strategy, а также умеет удалять и добавлять ancillary chunks. В режиме brute он может пробовать большой фиксированный набор методов. Это отличается от Pngwolf: pngcrush перебирает заранее определённые режимы кодирования, а Pngwolf эволюционирует индивидуальную последовательность фильтров по строкам.
Для очистки метаданных pngcrush функционально богаче. Он позволяет удалить ненужные chunks, управлять gAMA, tRNS и текстовыми chunks. Pngwolf такие задачи не ставит и сохраняет большинство исходной структуры. Поэтому файл с большим количеством служебных данных логичнее сначала обработать pngcrush или другим инструментом очистки.
С другой стороны, фиксированный brute-force не исследует пространство фильтров тем же способом, что генетический поиск. Если после pngcrush файл остаётся важным кандидатом на дальнейшее уменьшение, Pngwolf может найти другую построчную комбинацию. Но запуск в обратном порядке менее логичен, если pngcrush затем заново перекодирует IDAT со своей фильтрацией.
Pngwolf и OxiPNG
OxiPNG — современный многопоточный оптимизатор на Rust. Он поддерживает уровни оптимизации, transformations/reductions, удаление metadata через --strip, оптимизацию прозрачности, опциональный Zopfli и ограниченную работу с APNG. Для типичной современной автоматизации это более широкий и удобный набор возможностей, чем у исходного Pngwolf.
Главное практическое отличие — производственная направленность. OxiPNG умеет обрабатывать множество файлов, использует параллелизм и предлагает уровни от быстрых до более глубоких. Pngwolf исходно однопроцессный на файл и предназначен для дорогого исследовательского поиска. Его сильная сторона — именно генетическая модель последовательности фильтров и прозрачные ограничители поиска.
У OxiPNG есть собственные современные стратегии фильтрации и возможность Zopfli, поэтому нельзя заранее утверждать, что Pngwolf даст меньший файл. На конкретной выборке победитель определяется только измерением. Если нужен устойчивый ежедневный pipeline, начать разумнее с OxiPNG. Pngwolf имеет смысл как дополнительный экспериментальный финальный проход для небольшого числа важных статических PNG.
Pngwolf и pngwolf-zopfli — это не одно и то же
Отдельно нужно различать исходный Pngwolf Бьёрна Хёрмана и стороннюю ветку pngwolf-zopfli. Последняя меняет финальный компрессор на Zopfli, позднее получила дополнительные изменения вроде libdeflate. Параметры такой сборки могут отличаться: встречаются --zopfli-iter, --estimator и другие ключи, которых нет в исходной версии.
В этой статье команды --7zip-mpass, --7zip-mfb, --7zip-mmc и описанная логика финального сжатия относятся именно к исходному Pngwolf. Если ваш бинарник по справке показывает Zopfli-параметры, значит перед вами другая ветка, и копировать команды без проверки --help нельзя.
Такое различие особенно важно для старых архивов программ: имя исполняемого файла может оставаться pngwolf.exe, хотя внутренний код уже основан на форке. Первый шаг после получения бинарника — открыть --help и сопоставить список параметров с тем вариантом, который вы собираетесь использовать.
Как определить, какая сборка Pngwolf у вас
Не опирайтесь только на имя файла. Запустите:
pngwolf --help
Для исходной реализации характерны параметры 7-Zip: --7zip-mfb, --7zip-mpass, --7zip-mmc, а также zlib-настройки и флаги генетического поиска. Если в справке вместо них фигурируют настройки Zopfli или выбор estimator, это модифицированная ветка.
Статья намеренно не переносит возможности форка в исходный Pngwolf. Например, многопоточная оценка или libdeflate встречались в производных версиях, но не должны автоматически приписываться оригиналу. Такой подход важен и при анализе старых форумных команд: сначала смотрите, к какой реализации относится пример.
Когда Pngwolf действительно стоит добавлять в workflow
Есть четыре характерных условия. Первое — конечный формат обязан остаться PNG. Второе — файл уже прошёл более широкую lossless-оптимизацию. Третье — ресурс меняется редко, поэтому дорогой офлайн-проход допустим. Четвёртое — даже небольшое дополнительное уменьшение имеет ценность из-за масштаба распространения или жёсткого лимита размера.
Если хотя бы два из этих условий не выполняются, Pngwolf может оказаться избыточным. Например, для ежедневно генерируемых превью разумнее быстрый оптимизатор. Для фотографий на сайте правильнее сначала решить вопрос формата. Для изображения, которое завтра снова откроют и пересохранят в редакторе, глубокий финальный проход сегодня мало полезен.
Когда лучше выбрать другой инструмент
Если нужен GUI, встроенная очередь, drag-and-drop и понятный прогресс по папке, исходный Pngwolf неудобен. Если нужно удалить метаданные, уменьшить палитру, исправить цветовой тип или оптимизировать APNG, более широкий инструмент решит задачу за один этап. Если важна воспроизводимая сборка, недетерминированный генетический поиск тоже может быть нежелателен.
Наконец, если обработка должна выполняться в реальном времени на сервере, Pngwolf почти всегда неправильный выбор. Алгоритм специально расходует много CPU ради небольшого потенциального выигрыша. Его место — офлайн-подготовка статических ресурсов, а не путь запроса пользователя.
Диагностика через —info перед длинным запуском
Короткий анализ часто экономит больше времени, чем подбор десятка параметров вслепую. Запустив --info, можно увидеть цветовой режим, глубину, interlace, размеры IDAT, chunks и оценку нескольких встроенных последовательностей.
Если, например, «original filter», «none», «paeth», «distinct bigrams» и «incremental» отличаются на считанные байты, пространство очевидных решений уже плоское. Генетический алгоритм всё ещё может найти улучшение, но ожидать крупного скачка не стоит. Если же встроенные эвристики разнесены на килобайты, конкретный PNG чувствителен к фильтрам и более длинный поиск выглядит перспективнее.
Для RGBA анализ дополнительно показывает invisible colors. Это позволяет принять решение о --normalize-alpha осознанно, а не включать флаг во всех задачах.
Разбор итоговой подробной сводки
При --verbose-summary программа выводит best filter sequence found, best zlib deflated IDAT size, total time spent optimizing, number of genomes evaluated, size of 7zip deflated data и size difference to original. Эти строки отвечают на разные вопросы.
Best zlib deflated IDAT size — оценка лучшей найденной последовательности тем zlib, который использовался во время поиска. Size of 7zip deflated data — уже размер финального потока после более тяжёлого компрессора. Они не обязаны совпадать и не должны сравниваться как «до и после» одного и того же алгоритма.
Number of genomes evaluated помогает понять, сколько вариантов было реально проверено. В сочетании со временем можно сравнивать профили. Size difference to original относится к IDAT. Для публикации отдельно измеряйте полный файл.
Последовательность фильтров — длинная строка цифр 0–4. Она полезна исследователю, но обычному пользователю не нужно вручную её редактировать. Pngwolf не предоставляет параметр, чтобы потом «вставить» произвольный готовый геном; вывод предназначен прежде всего для анализа.
Почему нельзя оценивать результат только процентом
Процент уменьшения зависит от исходного состояния файла. Сокращение на 0,7% после OptiPNG, pngcrush и другого сильного оптимизатора может быть хорошим результатом, тогда как 5% на плохо сохранённом PNG может означать, что основную работу сделал бы любой современный encoder.
Для реального решения лучше учитывать абсолютные байты, частоту загрузки и стоимость вычислений. Экономия 20 КБ на файле, который скачивается миллионы раз, важнее 30% на иконке размером 800 байт. Pngwolf особенно уместен в первой ситуации.
Автоматический отбор файлов для глубокого прохода
В большой коллекции не обязательно запускать Pngwolf на всё. Внешний скрипт может отбирать только PNG выше заданного размера, только RGB/RGBA или только ресурсы из критичного каталога. Затем каждый выбранный файл получает короткий поисковый бюджет, а второй, более глубокий проход выполняется лишь для тех, где первый запуск дал заметный выигрыш.
Такая двухступенчатая стратегия полезнее единого «максимального» профиля. Например, первый этап с короткой стагнацией выявляет чувствительные к фильтрам файлы. Второй этап увеличивает лимит только на них. В результате большая часть каталога обрабатывается быстро, а CPU тратится там, где есть доказанная отдача.
Почему Pngwolf лучше запускать после генератора спрайтов
Сборщик спрайтов или атласов полностью меняет геометрию изображения, порядок пикселей и часто сам PNG-кодировщик. Любая оптимизация исходных маленьких картинок может оказаться бесполезной после их объединения: новый атлас получит другой IDAT и новую последовательность фильтров.
Поэтому сначала создайте окончательный спрайт, затем выполните структурную PNG-оптимизацию и лишь после этого Pngwolf. То же правило относится к инструментам, которые добавляют рамки, масштабируют изображения или генерируют mipmap-атласы. Глубокое Deflate-сжатие должно происходить после последней операции, меняющей пиксели.
Почему Pngwolf не заменяет квантование
Квантование уменьшает число цветов и часто переводит truecolor PNG в палитровый. Даже без визуально заметной потери такой шаг может резко сократить объём исходных пиксельных данных. Pngwolf этого не делает. Он оставляет цветовую модель и битность в том виде, в каком получил их.
Если допустимо строго lossless palette reduction, используйте инструмент, который умеет доказуемо сохранить цвета. Если допустимо визуально близкое lossy-квантование, потенциальный выигрыш будет ещё больше, но это уже другой класс преобразования. Pngwolf можно использовать после квантования, если получившийся PNG совместим, но его вклад будет только в фильтрацию и Deflate.
Почему Pngwolf не удаляет метаданные автоматически
Удаление chunks может нарушить цветопередачу, лицензирование или бизнес-метаданные, поэтому универсальный оптимизатор должен иметь политику того, что считать безопасным. Pngwolf такой политики не реализует: он просто переносит chunks, не являющиеся IDAT.
Для веб-публикации часто удаляют текстовые комментарии, данные редактора и некоторые профили, но это решение должно приниматься отдельно. Современные инструменты предлагают режимы вроде safe strip и all strip. В Pngwolf соответствующей кнопки нет, поэтому подготовка метаданных — отдельный этап.
Воспроизводимость и контроль версий
Генетический алгоритм даёт шанс на разные результаты. Если артефакты подписываются хэшем, входят в reproducible build или сравниваются в CI побайтно, это нужно учитывать. Нельзя предполагать, что повторный запуск через год на другой сборке библиотек даст тот же файл, даже если изображение будет эквивалентным.
Для релизной системы есть два безопасных подхода. Первый — хранить уже оптимизированные PNG как входные артефакты и не генерировать их заново. Второй — считать Pngwolf необязательной постобработкой, которая не участвует в проверке воспроизводимости основной сборки. Выбор зависит от требований проекта.
Практические рецепты команд
Быстрый финальный проход
Когда Pngwolf запускается после другого оптимизатора и нужен небольшой дополнительный шанс на выигрыш без долгого ожидания, достаточно короткой стагнации:
pngwolf --in=asset.png --out=asset.pw.png --max-stagnate-time=2
Такой профиль не «облегчает» отдельные эвристики и не ослабляет финальный Deflate; он лишь раньше завершает генетический поиск, если улучшения перестали появляться.
Ограниченный запуск для CI
Для сборочной машины лучше иметь и лимит стагнации, и абсолютный потолок:
pngwolf --in=asset.png --out=asset.pw.png
--max-stagnate-time=3 --max-time=20 --verbose-summary
Так один необычный PNG не блокирует job на неопределённое время. Внешний скрипт после команды должен решить, использовать ли получившийся файл, на основании кода завершения и реального размера.
Исследование файла без записи
pngwolf --in=asset.png --info
Это наиболее безопасная команда для первичной диагностики. Она не требует выходного PNG и не запускает эволюцию. По её результату видно, interlaced ли файл, какие chunks присутствуют и насколько различаются встроенные эвристики.
Проверка прозрачности
Сначала анализ, затем отдельный экспериментальный выход:
pngwolf --in=icon.png --info
pngwolf --in=icon.png --out=icon.normalized.png
--normalize-alpha --max-stagnate-time=3
Не заменяйте исходник до проверки декодированных пикселей и поведения прозрачных границ в целевой среде.
Эксперимент с числом оценок
pngwolf --in=test.png --out=test.e500.png
--max-stagnate-time=0 --max-evaluations=500 --verbose-summary
Такой профиль удобен для сравнительного исследования, когда несколько вариантов запуска должны получить одинаковый верхний предел по числу оценок, а не по секундам.
Как не испортить рабочий процесс
Первое правило — не оптимизировать единственную копию. Хотя у Pngwolf отдельные входной и выходной пути, ничто не мешает пользователю указать один и тот же файл. Для критичных данных лучше всегда писать в новый путь и заменять оригинал после внешней проверки.
Второе правило — не смешивать lossless-оптимизацию с изменениями содержимого. Если в pipeline есть resize, watermark, color conversion или экспорт из редактора, они должны выполняться раньше. Иначе результат Pngwolf будет перекодирован.
Третье правило — не делать параметр --normalize-alpha глобальным по умолчанию. Он полезен, но меняет скрытые RGB. Четвёртое — не отключать все ограничители поиска в массовой задаче. Пятое — хранить лог версии или хотя бы справку используемого бинарника, потому что у форков Pngwolf набор параметров отличается.
Как оценить пользу Pngwolf на собственном проекте
Возьмите репрезентативную выборку, а не один удачный PNG. Хороший тестовый набор включает маленькие иконки, средние UI-элементы, крупные скриншоты, прозрачные и непрозрачные файлы, палитровые и truecolor варианты. Сначала оптимизируйте их основным инструментом проекта, затем запускайте Pngwolf с фиксированным коротким профилем.
Для каждого файла сохраните исходный размер, размер после основного оптимизатора, размер после Pngwolf и время дополнительного прохода. Полезная метрика — не только процент, но и суммарные сэкономленные байты на минуту CPU. Если несколько крупных файлов дают основную экономию, можно применять Pngwolf только к ним.
Потом повторите тест с более длинной стагнацией. Если прирост относительно короткого профиля минимален, оставьте быстрый. Если он заметен на определённом типе ресурсов, создайте отдельное правило именно для этого класса.
Частые вопросы о Pngwolf
Меняет ли Pngwolf качество изображения?
В обычном режиме алгоритм меняет фильтры и Deflate-представление, а после декодирования пиксели должны оставаться теми же. Исключение — --normalize-alpha, который обнуляет RGB у полностью прозрачных пикселей 8-битного RGBA. Визуально эти пиксели не видны, но их исходные данные меняются.
Почему программа называется PNG-оптимизатором, если не удаляет метаданные?
Оптимизация PNG состоит из нескольких независимых направлений: выбор цветового типа и битности, палитра, фильтры, Deflate и ancillary chunks. Pngwolf реализует узкий, но технически значимый участок — поиск фильтров и финальное сжатие. Универсальным очистителем контейнера он не является.
Можно ли использовать Pngwolf для JPEG, WebP или AVIF?
Нет. Алгоритм опирается на структуру PNG, стандартные scanline-фильтры и IDAT. Параметр --in ожидает PNG с корректной сигнатурой.
Есть ли у Pngwolf графический интерфейс?
У исходной программы нет собственного GUI. Она запускается из командной строки. Сторонние оболочки и программы-комбайны могли включать Pngwolf как внутренний компонент, но их интерфейс нельзя считать интерфейсом самого Pngwolf.
Можно ли передать сразу папку?
В исходной CLI-модели — нет. Один запуск получает один входной путь. Обход каталога организует PowerShell, shell-скрипт, make, CI-система или другое внешнее средство.
Стоит ли ставить —7zip-mpass=15?
Не автоматически. Большое число проходов увеличивает время финального Deflate и иногда даёт меньший поток, но выигрыш не гарантирован. Проверьте несколько файлов и сравните реальный результат с профилем по умолчанию. Для больших PNG можно использовать auto.
Стоит ли ставить —zlib-level=9?
Тоже не как универсальное правило. zlib здесь участвует в ранжировании геномов. Более тяжёлый уровень меняет и скорость, и оценку вариантов. Исторические тесты автора показывали, что другой уровень не всегда ведёт к лучшему финалу. Сначала оставьте значение по умолчанию.
Почему два запуска дали файлы разного размера?
Генетический поиск включает случайные элементы, поэтому путь эволюции может отличаться. При небольшом лимите это особенно заметно: один запуск успел найти удачное скрещивание, другой — нет. Для статистического сравнения параметров делайте несколько повторов или используйте достаточно большой набор файлов.
Можно ли остановить длительный запуск?
Да. Во время поисковой фазы Pngwolf перехватывает Ctrl+C/SIGINT, завершает эволюцию и должен перейти к сохранению лучшего найденного результата. Повторное прерывание на финальном сжатии уже может оборвать процесс, поэтому после первого Ctrl+C лучше дождаться завершения.
Что такое IDAT?
IDAT — один или несколько chunks PNG, в которых находится сжатый поток пиксельных scanline-данных. Pngwolf объединяет данные старых IDAT, распаковывает их, меняет фильтры строк, заново сжимает и при сохранении формирует новый IDAT.
Почему размер IDAT и файла различается?
PNG содержит служебную сигнатуру и другие chunks. Палитра, прозрачность, цветовой профиль, гамма, текстовые поля и прочие данные находятся вне IDAT. Поэтому экономия на потоке пикселей — только часть общего размера.
Можно ли использовать —normalize-alpha для логотипа?
Можно только если скрытые цвета прозрачных пикселей не имеют значения. Для обычного веб-логотипа это часто так, но для мастер-исходника, текстуры или файла, который потом будет масштабироваться особым способом, сначала нужен тест. Сохраняйте обычный и нормализованный варианты отдельно.
Что делать с interlaced PNG?
Исходный Pngwolf его не обработает. Если Adam7 не нужен, сделайте non-interlaced копию другим PNG-инструментом и оптимизируйте её. Если Adam7 обязателен на выходе, выбирайте оптимизатор с нативной поддержкой interlace.
Нужно ли сначала запускать OptiPNG или pngcrush?
Не обязательно именно эти программы, но широкую структурную оптимизацию разумно выполнить раньше Pngwolf. Иначе вы тратите время на идеальную последовательность фильтров для структуры, которую следующий инструмент потом изменит.
Может ли Pngwolf сделать палитру меньше?
Нет. Он не оптимизирует число цветов и не занимается переупорядочиванием палитры как завершённой функцией. Если палитровый PNG можно структурно сократить, это работа другого инструмента.
Сохраняет ли Pngwolf ICC-профиль?
Он переносит chunks, не являющиеся IDAT, а не занимается их массовым удалением. Но Pngwolf не следует считать валидатором или менеджером цветовых данных. Если профиль критичен, сравните chunks и проверьте целевой файл внешним средством.
Есть ли смысл запускать программу повторно на своём же результате?
Иногда новый случайный поиск может найти ещё одну комбинацию, но это не гарантировано. Повторный запуск также снова тратит много CPU. Если вы хотите оценить пользу повторов, делайте это на выборке и сравнивайте абсолютную экономию, а не превращайте цикл «до бесконечности» в стандартный pipeline.
Подходит ли Pngwolf для серверной обработки загрузок пользователей?
Обычно нет. Время работы плохо предсказуемо без жёстких лимитов, а алгоритм CPU-интенсивен. Для онлайн-загрузок предпочтительнее быстрый контролируемый оптимизатор, а Pngwolf оставить офлайн-проходом по статическим ресурсам.
Почему в интернете встречаются параметры —zopfli-iter?
Они относятся к pngwolf-zopfli и производным сборкам, а не к исходной реализации с 7-Zip. Всегда сверяйте --help вашего бинарника. Команда из форума может быть технически корректной для другой ветки и полностью неизвестной вашему Pngwolf.
Проверка сборки перед использованием
Перед включением старой консольной утилиты в рабочий pipeline полезно сделать маленький smoke test. Возьмите заведомо корректный non-interlaced RGB PNG, запустите --info, затем обычную оптимизацию с отдельным выходом и коротким лимитом. Убедитесь, что команда создаёт читаемый файл и печатает ожидаемые параметры 7-Zip.
Далее проверьте RGBA-файл с прозрачностью и палитровый PNG. Не обязательно ждать крупной экономии; цель — убедиться, что конкретная сборка корректно читает ваши типовые ресурсы. Если бинарник неизвестного происхождения ведёт себя иначе, чем описанная справка, сначала выясните, не основан ли он на форке.
Работа с путями и именами файлов
Pngwolf сам не интерпретирует шаблоны оболочки. Кавычки, wildcard и перенаправление обрабатывает терминал. В Windows-скрипте пути с пробелами нужно заключать в кавычки; в PowerShell при передаче значений после = удобнее формировать аргументы так, чтобы полный путь оставался единым аргументом.
Для автоматизации полезно писать результаты в отдельный каталог с теми же именами. Это исключает случайную перезапись и упрощает откат. Если выходной каталог не существует, Pngwolf не создаёт его автоматически — подготовьте структуру заранее.
Что означает «lossless» в контексте Pngwolf
Стандартная фильтрация PNG обратима: декодер знает номер фильтра каждой строки и восстанавливает исходные байты. Deflate также является без потерь. Поэтому смена фильтров и параметров компрессора не должна менять декодированное изображение.
Однако «без потерь» нужно уточнять по уровню сравнения. Файл почти всегда будет отличаться побайтно. Порядок и упаковка IDAT меняются. При --normalize-alpha могут измениться и декодированные RGBA-значения прозрачных пикселей. Поэтому корректная формулировка: обычный режим стремится сохранить пиксельные данные, а нормализация альфы сохраняет видимое изображение, но не все скрытые каналы.
Параметры, которые лучше не трогать без эксперимента
В эту группу входят --population-size, низкоуровневые zlib-параметры, --7zip-mfb, --7zip-mmc, исключение эвристик и тем более --bigger-is-better. Они полезны для исследования и специализированной настройки, но не являются обязательными ступенями «продвинутого качества».
Для большинства практических задач достаточно четырёх вещей: корректный --in, отдельный --out, разумный --max-stagnate-time и при необходимости --max-time. Остальные параметры подключаются только после измерения на собственных данных.
Рекомендуемый порядок действий
- Подготовьте финальные пиксели и не планируйте последующее пересохранение.
- Выполните структурную lossless-оптимизацию PNG другим подходящим инструментом.
- Запустите
pngwolf --infoна нескольких типовых файлах. - Проверьте, что изображения non-interlaced и поддерживаются вашей сборкой.
- Сделайте короткий проход с отдельным выходом и
--verbose-summary. - Сравните полный размер, а для критичных файлов — декодированные пиксели.
- Увеличивайте бюджет только на тех типах PNG, где короткий запуск показал отдачу.
--normalize-alphaиспользуйте только после проверки назначения скрытых RGB.- В пакетной задаче заменяйте оригинал внешним скриптом лишь при успешной проверке.
- Зафиксируйте используемую сборку и параметры в документации проекта.
Итог
Pngwolf — специализированный инструмент для тех случаев, когда обычная PNG-оптимизация уже сделана, но хочется исследовать ещё один источник экономии: последовательность фильтров каждой строки. Он строит несколько сильных стартовых кандидатов, дополняет их случайными решениями, оценивает через zlib, развивает генетическим алгоритмом и финально пересжимает найденный поток Deflate-кодировщиком 7-Zip. Пользователь может ограничивать время, стагнацию, число оценок и объём работы, а при необходимости выгружать исходный и лучший IDAT.
Сильная сторона Pngwolf — контролируемый глубокий поиск, а не универсальность. Он не заменяет редактор фотографий, не сокращает палитру, не чистит metadata, не поддерживает Adam7 и не предлагает графическую пакетную оболочку. Поэтому лучший сценарий — финальная офлайн-стадия для отдельных важных PNG после более широких преобразований. Начинайте с короткого лимита, измеряйте выигрыш на своём наборе и увеличивайте бюджет только там, где дополнительные байты действительно стоят затраченного времени.
