Guetzli: сжатие JPEG с перцептивной оптимизацией

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

Что именно делает Guetzli

Guetzli — перцептивный JPEG-энкодер. На вход он принимает PNG или JPEG, а на выходе создаёт JPEG. Термин «перцептивный» здесь означает, что программа не просто применяет заранее заданную таблицу квантования и не ограничивается оптимизацией энтропийного кодирования. Она многократно создаёт кандидаты JPEG, сравнивает их с исходником с помощью модели визуального восприятия Butteraugli и пытается приблизиться к заданному порогу качества с меньшим объёмом данных.

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

Это принципиально отличает Guetzli от утилит, которые занимаются только без потерь перепаковкой готового JPEG. Если взять уже существующий файл и пропустить его через обычный lossless-оптимизатор, пиксельное содержимое после декодирования не меняется: экономия получается за счёт таблиц Хаффмана, служебных сегментов, структуры сканов и других деталей представления. Guetzli, напротив, является кодировщиком с потерями. Он сознательно меняет коэффициенты изображения в допустимых для JPEG пределах, но делает это с обратной связью по перцептивной метрике.

Практическое следствие простое: сравнивать Guetzli только по числу «качество 90» с другим энкодером некорректно. Одинаковое числовое значение quality не гарантирует одинаковый размер, одинаковую степень искажений или одинаковое визуальное впечатление. Параметр в Guetzli выражен в единицах, сопоставимых с привычной шкалой libjpeg, но сам алгоритм выбирает представление иначе. Для рабочего решения нужно смотреть как минимум на два результата: размер файла и изображение после декодирования. Для критичных материалов полезно дополнительно проверять цвет, мелкие фактуры, границы объектов и участки с плавными градиентами.

Guetzli создаёт последовательные, то есть non-progressive JPEG. Это сознательное ограничение: разработчики оценивали progressive JPEG как потенциально более компактный, но выбрали последовательное представление из-за меньших затрат на декодирование. Поэтому Guetzli не следует рассматривать как способ одновременно получить перцептивную оптимизацию и прогрессивную загрузку: такой режим штатно не предусмотрен.

Как устроено сжатие и почему оно занимает много времени

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

Глобальная настройка квантования

На первом этапе Guetzli перебирает заранее подготовленные варианты глобальных таблиц квантования. В JPEG такие таблицы действуют на всё изображение, поэтому изменение одного параметра может по-разному сказаться на небе, траве, коже, тексте, тонких линиях и шумных фактурах. Энкодер генерирует кандидаты и измеряет их перцептивную дистанцию до исходника. Цель — не просто получить минимальный размер, а приблизить искажения к заданной границе.

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

Локальное зануление DCT-коэффициентов

Самая сильная часть Guetzli — выбор коэффициентов DCT, которые можно заменить нулями. Для JPEG нулевые коэффициенты выгодны: последовательности нулей кодируются очень компактно. Если убрать коэффициент там, где человеческое зрение почти не заметит потерю, размер уменьшается, а субъективная картинка остаётся близкой к исходнику.

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

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

Butteraugli — метрика перцептивного различия, на которой построена обратная связь Guetzli. Она учитывает не только простую численную разницу пикселей. В модели отражены особенности цветового восприятия и визуального маскирования: например, человеческий глаз менее чувствителен к некоторым изменениям синего канала, а сложная текстура может скрывать мелкие ошибки лучше, чем ровная область неба. За счёт этого энкодер пытается распределять потери неравномерно, а там, где они визуально менее заметны.

Важно не превращать это в обещание «без потерь». Guetzli остаётся lossy-энкодером. Формулировка «визуально близко» означает, что алгоритм оптимизирован на ограничение заметности искажений по выбранной модели, а не что декодированные пиксели совпадут с исходником. Для архивов, научных данных, медицинских изображений, технических схем с обязательным пиксельным совпадением и других задач, где нужна математическая идентичность, такой подход не подходит.

Выбор между YUV444 и YUV420

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

Из этого следует практический вывод: не нужно заранее пересжимать исходник в низкокачественный 4:2:0 JPEG только ради того, чтобы «помочь» Guetzli. Официальные рекомендации прямо советуют подавать максимально качественный источник и по возможности не давать уже многократно пережатые файлы. Чем больше необратимых артефактов накопилось до Guetzli, тем меньше у него пространства для полезной оптимизации.

Какие исходники подходят лучше всего

Лучший сценарий для Guetzli — изображение, которое уже приведено к конечным размерам, цветовой модели и содержанию, но ещё не было агрессивно сжато JPEG. Например, фотография подготовлена в редакторе, уменьшена до 1600 или 2400 пикселей по длинной стороне, переведена в sRGB, отретуширована и сохранена в PNG либо в очень качественный JPEG. После этого Guetzli используется как последняя операция перед публикацией.

PNG на входе Guetzli не означает, что программа «оптимизирует PNG». Она декодирует PNG и создаёт JPEG. Такой путь уместен для фотографического материала, где прозрачность не нужна и где характер изображения хорошо соответствует JPEG. Для скриншотов интерфейса, пиксельной графики, схем, текста на ровном фоне и логотипов преобразование PNG в JPEG часто ухудшает вид: появляются ореолы, блочные артефакты и грязь вокруг контрастных линий. В таких случаях нужно сначала выбрать правильный формат, а уже потом энкодер.

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

JPEG на входе поддерживается, но повторное lossy-кодирование всегда требует осторожности. Официальная документация рекомендует высококачественный источник; если JPEG уже пережат, результат обычно хуже. Guetzli не восстанавливает детали, потерянные раньше. Он декодирует существующий JPEG до пикселей и снова создаёт JPEG, поэтому прежние блоки, ringing и цветовые искажения могут остаться или получить новый слой потерь.

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

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

Guetzli не требует графического интерфейса: основной рабочий объект — исполняемый файл и командная строка. Для практической работы удобнее всего добиться, чтобы команда guetzli находилась через переменную PATH. Тогда сценарии, приведённые ниже, одинаково легко использовать вручную, в shell-скрипте, Makefile или CI-задаче.

Windows

На Windows можно использовать готовый исполняемый файл либо собирать проект из исходного кода. Для ручного запуска достаточно поместить EXE в отдельную папку, открыть PowerShell или командную строку в этой папке и вызвать программу с двумя путями: входным и выходным. Переименовывать официальный бинарник не обязательно; если имя длинное, его можно либо добавить в PATH как есть, либо создать более короткое имя для локального рабочего окружения.

Сборка из исходников требует Visual Studio и libpng. В документации проекта для Windows описана установка libpng через vcpkg и подключение пакетов к среде разработки. Это полезно, если нужен собственный билд, отладка или изменение исходного кода, но для обычного кодирования фотографий сборка не даёт функционального преимущества сама по себе.

Linux и другие POSIX-системы

При сборке на POSIX-системах нужен пакет разработки libpng и обычный make. После успешной сборки бинарник появляется в каталоге bin/Release/guetzli. В дистрибутивах, где Guetzli присутствует в репозитории пакетов, проще пользоваться пакетным менеджером: это избавляет от ручного размещения бинарника и обычно автоматически добавляет страницу man.

Альтернативный вариант сборки — Bazel. Проект содержит конфигурацию, позволяющую выполнить оптимизированную сборку командой bazel build -c opt //:guetzli. Этот путь полезен разработчикам, у которых Bazel уже является частью инфраструктуры.

macOS

На macOS наиболее короткий путь — пакетный менеджер Homebrew: команда brew install guetzli устанавливает бинарник и зависимости. При сборке из репозитория нужен libpng; при Homebrew достаточно обычного make, а при MacPorts документация проекта показывает передачу путей к заголовочным файлам и библиотекам через CFLAGS и LDFLAGS.

Проверка запуска

Если вызвать Guetzli без входного и выходного файла, программа печатает краткую справку со схемой аргументов и доступными флагами. Это удобная проверка того, что бинарник запускается и находится через PATH. Рабочий синтаксис выглядит так:

guetzli [flags] input_filename output_filename

Если оболочка сообщает, что команда не найдена, проблема находится до Guetzli: текущая папка не входит в PATH, исполняемый файл называется иначе либо отсутствует право на исполнение. На Linux и macOS для локального бинарника часто нужно явно писать ./guetzli. В Windows PowerShell для файла из текущего каталога может потребоваться .guetzli.exe.

Командная строка и параметры

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

Базовый запуск

guetzli input.png output.jpg
guetzli input.jpg output.jpg

Первый путь — источник, второй — новый JPEG. Расширение выходного файла лучше всегда указывать .jpg или .jpeg, чтобы имя соответствовало фактическому формату. При работе из каталога с пробелами пути нужно заключать в кавычки:

guetzli "D:PhotosHero source.png" "D:PhotosHero optimized.jpg"

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

--quality Q

Флаг --quality задаёт целевое визуальное качество в единицах, сопоставимых со шкалой JPEG quality. Значение по умолчанию — 95. Обычная сборка Guetzli не принимает значения ниже 84: программа выводит сообщение о заметных артефактах и завершает обработку. Это не случайная рекомендация документации, а встроенная защитная граница.

guetzli --quality 95 input.png output-q95.jpg
guetzli --quality 90 input.png output-q90.jpg
guetzli --quality 84 input.png output-q84.jpg

Значение 95 удобно как исходная точка для задач, где качество важнее времени и размера. 90 часто даёт заметно меньший файл и остаётся в целевом высококачественном диапазоне. 84 — нижняя штатная граница, которую стоит воспринимать не как универсальный «лучший веб-параметр», а как минимальное значение, при котором разработчики разрешили запуск без изменения исходного кода. На конкретной фотографии 84 может выглядеть хорошо, а на тонких линиях, мелком тексте или искусственной графике — неприемлемо.

--verbose

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

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

--memlimit M

--memlimit задаёт верхний предел памяти в мегабайтах. Документированное значение по умолчанию — 6000 МБ. Если Guetzli понимает, что не сможет уложиться в предел, он завершает работу с ошибкой вместо продолжения с неконтролируемым потреблением памяти.

guetzli --memlimit 4000 --quality 90 input.png output.jpg

Этот флаг не превращает алгоритм в малопамятный режим. Если изображению по внутренней оценке нужно больше памяти, Guetzli не обязан «ужаться» и продолжить медленнее; он может отказать. Поэтому --memlimit — предохранитель процесса, а не инструмент оптимизации RAM.

--nomemlimit

--nomemlimit отключает внутренний лимит. Использовать его на рабочей станции или сервере без внешних ограничений опасно: Guetzli известен очень высоким расходом памяти, а операционная система при нехватке RAM может начать активно использовать swap либо завершить процесс. Этот флаг уместен только тогда, когда лимит уже контролируется на другом уровне и вы точно понимаете доступный бюджет.

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

У JPEG нет единой международной шкалы, где «90» означает одинаковую физическую величину у всех энкодеров. Число quality преобразуется в таблицы и внутренние цели, а Guetzli дополнительно использует перцептивную оптимизацию. Поэтому не стоит писать в рабочей инструкции «ставьте 90, потому что это 90 процентов качества». Правильная трактовка: это управляющий параметр, который позволяет двигаться по компромиссу между размером и искажениями.

Практичный способ настройки — взять небольшой, но представительный набор изображений. В него стоит включить портрет, пейзаж с листвой, гладкое небо, ночную фотографию с шумом, архитектуру с тонкими линиями и, если такие файлы реально публикуются, кадр с текстом или интерфейсными элементами. Для каждого исходника создайте версии 95, 90, 86 и 84, после чего сравните их в масштабе 100% и на типичном размере просмотра.

При сравнении смотрите не только на общий «вид». JPEG-дефекты хорошо прячутся при fit-to-window. Проверяйте края контрастных объектов, мелкие ветви, волосы, текстуры ткани, тёмные градиенты, области вокруг насыщенных цветов. Для веба полезно дополнительно открыть результат в браузере на устройстве с обычным масштабированием, потому что ресэмплинг браузера может как скрыть, так и подчеркнуть некоторые артефакты.

Если визуальной разницы между 95 и 90 нет, а размер 90 заметно меньше, для этого класса изображений 90 практичнее. Если 84 даёт небольшой дополнительный выигрыш, но портит мелкие детали, удерживаться на минимальном разрешённом значении бессмысленно. Guetzli экономит байты не ради самой цифры, а ради передачи приемлемого визуального результата.

Отдельно стоит помнить о качестве исходного JPEG. Если подать файл, уже экспортированный с quality 75 в другом редакторе, а затем выбрать Guetzli 95, итог не вернёт потерянные детали. Более высокое число в последующей перекодировке не повышает качество исходных пикселей; оно только ограничивает новые потери.

Память: как заранее оценить, выдержит ли система

Для Guetzli объём оперативной памяти — не второстепенная характеристика, а один из основных ограничителей. В официальной документации приведён ориентир около 300 МБ RAM на один мегапиксель входного изображения. Это не гарантия точного пикового потребления и не формула для всех кадров, но достаточно хороший порядок величины для планирования.

Чтобы оценить масштаб, сначала посчитайте число мегапикселей по разрешению, а не по размеру файла на диске. JPEG 6000×4000 — это 24 мегапикселя независимо от того, занимает он 3 МБ или 15 МБ. При ориентире 300 МБ на мегапиксель теоретический бюджет уже приближается к 7,2 ГБ. Для фотографии 3000×2000, то есть 6 мегапикселей, ориентир около 1,8 ГБ. Именно поэтому небольшой по байтам исходник может оказаться тяжёлым для Guetzli.

Размер JPEG на диске плохо предсказывает RAM, потому что энкодер работает не с архивированным потоком байтов как с чёрным ящиком. Он декодирует изображение и хранит промежуточные представления, необходимые для оценки кандидатов и Butteraugli. Снимок с ровным небом может весить на диске мало, но по разрешению оставаться большим.

На сервере с несколькими параллельными задачами нужно умножать бюджет на число одновременно работающих процессов. Четыре изображения по 12 Мп, запущенные одновременно, потенциально требуют уже совершенно другой класс памяти, чем один процесс. Поэтому на практике Guetzli обычно лучше ставить в ограниченную очередь: один или несколько workers в зависимости от объёма RAM, а не запускать по процессу на каждый файл без контроля.

Если используется --memlimit, задавайте его исходя из реального свободного объёма, оставляя запас операционной системе, веб-серверу, базе данных и другим задачам. На машине с 8 ГБ памяти установка лимита 8000 МБ для Guetzli не означает, что система безопасно выдержит такой процесс: часть RAM уже занята, а превышение физической памяти может привести к swap и резкому падению производительности.

Сообщение Memory limit would be exceeded. Failing. следует трактовать буквально: задача не укладывается в заданный внутренний предел. Правильные варианты — увеличить доступный бюджет, уменьшить разрешение исходника до фактически нужного размера, запускать обработку на машине с большим объёмом RAM или выбрать другой энкодер. Бесполезно просто повторять ту же команду, ожидая случайно меньшего потребления.

Производительность: почему Guetzli не подходит для обработки «на лету»

Официальный ориентир по CPU — примерно одна минута процессорного времени на один мегапиксель входного изображения. Реальное время зависит от процессора, содержимого кадра, параметров, компиляции и фоновой нагрузки, поэтому эту цифру нельзя переносить как измеренный SLA. Но порядок величины показывает главное: Guetzli на несколько классов медленнее обычного JPEG-экспорта.

Причина не в медленном чтении файла и не в диске. Энкодер выполняет поисковую оптимизацию с многократными оценками кандидатов. Поэтому NVMe вместо SATA обычно не превращает минутный расчёт в секунды. Узкое место — вычисления и память. На рабочей станции это заметно по длительной загрузке одного ядра или небольшого числа потоков, а на сервере — по продолжительному CPU-time на каждый файл.

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

Ещё лучше подходит офлайн-сценарий: изображения сайта известны заранее и меняются редко. Тогда высокая стоимость кодирования платится один раз, а уменьшенный JPEG отдается много раз. Чем чаще файл скачивается и чем реже меняется, тем логичнее тратить дополнительное CPU-время на оптимизацию. Для превью, которые генерируются тысячами каждый час и живут недолго, баланс обычно обратный.

При пакетной обработке не стоит бездумно запускать десятки процессов в параллель только потому, что процессор имеет много ядер. RAM у Guetzli заканчивается быстрее, чем вычислительные ядра. Сначала определите пиковое потребление одного типичного изображения, затем выберите число workers с запасом. На практике стабильная очередь из двух процессов может быть быстрее всей партии, чем восемь процессов, которые начинают бороться за память и уходят в swap.

Для замера времени используйте внешние средства оболочки. В Linux и macOS можно писать time guetzli .... В PowerShell удобно измерять вызов через Measure-Command. Такие цифры отражают именно вашу машину и ваш класс изображений, в отличие от чужих тестов, проведённых на другом железе.

Цветовой профиль и sRGB

Guetzli предполагает, что входное изображение находится в sRGB с гаммой 2,2, и игнорирует информацию цветового профиля при принятии решений кодирования. Это означает, что энкодер не является системой управления цветом. Если исходник закодирован в Adobe RGB, Display P3, ProPhoto RGB или другом пространстве, наличие ICC-профиля само по себе не заставит Guetzli корректно преобразовать пиксели в sRGB.

Практический рабочий процесс должен включать явное преобразование цвета до Guetzli. Откройте исходник в редакторе или конвертере, который умеет colour management, выполните корректное преобразование в sRGB, проверьте внешний вид, а уже затем передавайте результат энкодеру. Простое удаление ICC-профиля без изменения числовых значений пикселей — не то же самое, что преобразование пространства.

Это особенно важно для насыщенных цветов. Файл, подготовленный в широком цветовом охвате, может выглядеть приемлемо в приложении, которое чтит профиль, но после некорректной интерпретации как sRGB оттенки и насыщенность меняются ещё до того, как обсуждается качество JPEG. В такой ситуации бессмысленно подбирать --quality: проблема не в степени сжатия, а в неверной цветовой предпосылке.

Если в рабочем процессе важно сохранить EXIF, IPTC, XMP или ICC как служебные данные, относитесь к Guetzli как к стадии формирования пиксельного JPEG, а не как к инструменту управления метаданными. После кодирования отдельно проверяйте необходимые поля специализированной утилитой. Для публикационного pipeline разумно сделать тест: взять файл с заведомо известными метаданными, прогнать его через текущую сборку и проверить, что именно осталось в результате. Так вы не будете зависеть от предположений о поведении конкретной версии или обёртки.

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

PNG с прозрачностью: самый опасный простой сценарий

JPEG не поддерживает альфа-канал. Когда Guetzli получает PNG с прозрачностью, прозрачные области накладываются на чёрный фон. В результате логотип с полупрозрачной тенью, вырезанный объект, иконка или фотография с маской могут превратиться в JPEG с чёрным фоном и тёмными ореолами.

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

Особенно неприятны полупрозрачные края после удаления фона. Даже если основная область полностью прозрачна, антиалиасинг по контуру содержит пиксели с частичной прозрачностью. При наложении на чёрный они темнеют. Поэтому просто «заменить прозрачность на белую» нужно операцией корректного композитинга, а не изменением значения alpha без пересчёта RGB.

Если исходник — скриншот приложения с альфа-каналом, сохранение PNG часто и по качеству, и по размеру логичнее JPEG. Guetzli предназначен прежде всего для высококачественных фотографических изображений. Чёткий текст на однотонном фоне — тип материала, где JPEG-артефакты заметны раньше, чем на естественной текстуре.

Практический сценарий: фотография из PNG в финальный JPEG

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

1. Создайте отдельный рабочий каталог и поместите туда исходный PNG.
2. Проверьте разрешение. Если для сайта нужен кадр 1920×1280, не отправляйте в Guetzli исходник 8000×5333 только затем, чтобы потом уменьшить JPEG: энкодер зря потратит огромный объём RAM и CPU.
3. Сначала создайте вариант с качеством 95: guetzli --quality 95 photo.png photo-q95.jpg.
4. Создайте второй вариант с качеством 90: guetzli --quality 90 photo.png photo-q90.jpg.
5. Сравните размеры и визуально проверьте обе версии рядом с PNG.
6. Если экономия 90 существенна и дефекты не видны на критичных участках, используйте 90 как кандидат. Если 90 портит детали, вернитесь к 95 либо выберите промежуточное значение.

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

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

Практический сценарий: повторное сжатие качественного JPEG

Часто мастер хранится не в PNG, а в JPEG максимального или почти максимального качества. Такой файл можно передать Guetzli напрямую. Смысл есть, если исходная JPEG-компрессия была мягкой и детали ещё не разрушены.

Начните с копии. Команда может выглядеть так:

guetzli --quality 95 original-high.jpg optimized.jpg

Затем проверьте не только итоговый размер, но и характер исходника. Если original-high.jpg — файл из камеры или редактора с высоким качеством и 4:4:4, Guetzli получает хороший материал. Если это картинка, скачанная с социальной сети, в ней уже могут быть ringing, блоки, подавленный цвет и ресайз. Повторная обработка не отменит этих дефектов.

Плохая практика — цепочка «редактор quality 70 → CDN quality 75 → Guetzli quality 90». В ней каждая стадия делает новое lossy-преобразование. Лучше перестроить pipeline так, чтобы Guetzli работал непосредственно с мастер-версией нужного разрешения, а дальнейшие системы доставки не перекодировали файл повторно без необходимости.

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

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

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

Правильный порядок операций:

1. взять мастер в корректном цветовом пространстве;
2. создать нужные геометрические размеры качественным ресэмплером;
3. при необходимости выполнить лёгкую пост-резкость для каждого размера;
4. сохранить промежуточные версии без JPEG-потерь или с минимальными потерями;
5. запустить Guetzli для каждого конечного размера;
6. проверить размеры файлов и сформировать разметку srcset уже на готовых ассетах.

Неэффективно сначала прогонять 24-мегапиксельный мастер через Guetzli, а потом делать из полученного JPEG четыре уменьшенные копии. Вы заплатите большой вычислительный счёт за пиксели, которые позже выбросите, и добавите повторное кодирование. Геометрические преобразования должны предшествовать финальному энкодингу.

Для каждого размера необязательно выбирать одинаковое quality. Маленький превью-файл часто сильнее скрывает мелкие артефакты из-за уменьшения при просмотре, но на нём выше относительная доля служебных данных. Большой hero-кадр заметнее показывает ringing и градиенты. Если проект критичен к байтам, пресеты можно калибровать раздельно.

Пакетная обработка в Bash

В Guetzli нет встроенной очереди файлов. Пакетность организуется оболочкой. Самый простой Bash-цикл можно написать так:

mkdir -p out
for f in *.png; do
  base="${f%.*}"
  guetzli --quality 90 "$f" "out/${base}.jpg"
done

Такой цикл запускает файлы последовательно, что безопасно по памяти. Для production-сценария добавьте проверку кода возврата и существования результата:

mkdir -p out failed
for f in *.png; do
  base="${f%.*}"
  if guetzli --quality 90 --memlimit 6000 "$f" "out/${base}.jpg"; then
    echo "OK: $f"
  else
    echo "FAIL: $f" >&2
    printf '%sn' "$f" >> failed/list.txt
  fi
done

Параллелить можно через xargs -P, GNU Parallel или собственный worker pool, но значение параллелизма нужно выбирать по памяти. Если типичный файл требует 3 ГБ, четыре процесса на машине с 8 ГБ заранее выглядят как плохая идея. Для Guetzli управление конкурентностью важнее красивой загрузки всех CPU-ядер.

Имя выходного файла лучше формировать отдельно, не используя исходное расширение. Если превратить photo.png в поток JPEG и сохранить его как photo.png, некоторые системы определят формат по содержимому, а другие — по расширению. Такая неоднозначность создаёт трудно диагностируемые ошибки MIME-типа и кеширования.

Пакетная обработка в PowerShell

В PowerShell последовательный сценарий для JPEG может выглядеть так:

$out = Join-Path $PWD "out"
New-Item -ItemType Directory -Force $out | Out-Null
Get-ChildItem -Filter *.jpg | ForEach-Object {
    $target = Join-Path $out ($_.BaseName + "-guetzli.jpg")
    & guetzli.exe --quality 90 $_.FullName $target
    if ($LASTEXITCODE -ne 0) {
        Write-Error "Guetzli failed: $($_.FullName)"
    }
}

Синтаксис & запускает исполняемый файл, а использование FullName защищает от зависимости от текущего каталога. Важно проверять $LASTEXITCODE, а не считать наличие строки в консоли признаком успеха.

Для измерения конкретного файла можно обернуть вызов:

Measure-Command {
    & guetzli.exe --quality 90 input.jpg output.jpg
}

Если требуется журнал, перенаправляйте stdout и stderr в отдельный файл. Особенно это полезно с --verbose, потому что длинный вывод иначе теряется в истории терминала.

Как безопасно встроить Guetzli в CI или сборку сайта

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

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

Вторая мера — отделить быструю проверочную сборку от релизной. На pull request можно генерировать обычный JPEG быстрым энкодером либо брать кэш, а Guetzli запускать только при подготовке production-ассетов. Это сокращает время обратной связи разработчикам, не меняя итоговую публикационную схему.

Третья мера — устанавливать жёсткий лимит параллелизма. CI-runner часто делит машину с другими задачами; если запустить по Guetzli на каждое ядро, runner может завершить процессы по OOM. Лучше ограничить очередь и дать каждому процессу предсказуемый memory budget.

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

Как читать подробный вывод --verbose

Verbose-режим показывает внутренний характер Guetzli лучше любого графического прогресс-бара. В логе встречаются строки с номером итерации, обозначением кандидата, размером Out, перцептивной дистанцией D, оценкой Score и распечатками quantization matrix. По ним видно, что энкодер строит несколько вариантов и не просто один раз вызывает фиксированную JPEG-функцию.

Значение Out полезно воспринимать как размер текущего кандидата, но не как обещание финального результата. Лучшим может оказаться кандидат не из последней строки. Аналогично, рост или падение Score внутри процесса не является линейным индикатором «готово на 60%». Оптимизатор исследует варианты.

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

Если цель — понять, зависла ли команда, verbose полезен: новые итерации подтверждают работу. Если цель — измерить процент завершения, штатного надёжного процента Guetzli не предоставляет. В автоматизации лучше ставить внешние лимиты времени на основе ваших измерений и размера входа, а не пытаться вычислить ETA из номера текущей итерации.

Типичные ошибки запуска и их исправление

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

Сообщение оболочки о неизвестной команде означает, что исполняемый файл Guetzli не найден. Проверьте имя файла, PATH и текущий каталог. На Linux и macOS локальный файл запускается через ./guetzli, если его каталог не добавлен в PATH. Также проверьте право выполнения.

Guetzli processing failed после слишком низкого quality

Штатная сборка не принимает --quality ниже 84. Поднимите значение до 84 или выше. Редактировать исходный код ради quality 60 обычно не имеет практического смысла: Guetzli создавался для диапазона высокого качества, а для агрессивного сжатия есть более быстрые и гибкие энкодеры.

Invalid input JPEG file

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

Процесс завершён системой с сообщением Killed

На Linux это часто признак OOM killer: процесс потребил больше памяти, чем доступно системе или контейнеру. Проверьте журнал ядра и лимиты cgroup, а не только параметр --memlimit. Даже --nomemlimit не создаёт дополнительную физическую память; наоборот, он снимает внутренний предохранитель.

Итоговый файл больше исходного

Сравните происхождение исходника. Если он уже оптимизирован или сильно сжат, Guetzli может сформировать более крупный JPEG, чтобы выдержать свою цель качества. Для pipeline это повод оставить исходник, а не считать процесс аварийным. Условие «использовать результат только при уменьшении» решает проблему.

После PNG появился чёрный фон

Причина — альфа-канал. Guetzli создаёт JPEG и композитит прозрачность на чёрный. Вернитесь к PNG и заранее сведите прозрачность с нужным фоном либо сохраните PNG, если прозрачность необходима конечному интерфейсу.

Цвета изменились

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

Что означает заявление о файлах на 20–30% меньше

В описании проекта говорится, что Guetzli обычно создаёт файлы примерно на 20–30% меньше, чем libjpeg при сопоставимом визуальном качестве. Эту фразу нельзя превращать в гарантию для любого входного JPEG. Сравнение относится к определённой методике оценки качества, набору изображений и конкретным настройкам конкурирующего энкодера. На вашем материале выигрыш может быть выше, ниже или отсутствовать.

В техническом отчёте авторы сравнивали Guetzli с libjpeg и MozJPEG, подбирая для Guetzli такой режим, чтобы получить близкую перцептивную дистанцию Butteraugli к результату другого энкодера. В зависимости от варианта конкурирующего JPEG суммарная экономия на тестовом корпусе лежала примерно в диапазоне 29–45%. Но сами авторы отдельно отмечали важное ограничение: Butteraugli — та же метрика, под которую Guetzli оптимизируется, поэтому такое сравнение хорошо показывает эффективность оптимизатора по собственной целевой метрике, но не заменяет независимую субъективную оценку людьми.

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

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

Почему Guetzli всегда создаёт sequential JPEG

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

В работе Guetzli авторы отказались от progressive-кодирования. Они ссылались на то, что прогрессивные JPEG могли давать несколько процентов экономии, но при этом декодироваться заметно медленнее на части реализаций. Поэтому итог Guetzli — стандартный sequential JPEG. Это архитектурное решение нельзя изменить флагом командной строки.

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

При этом sequential не означает «плохой» или «старый» JPEG. Файл остаётся стандартным и широко декодируемым. Вопрос только в том, какая структура лучше соответствует вашей системе доставки.

Почему нельзя оценивать Guetzli по одному тестовому изображению

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

Для редакционного сайта полезно собрать мини-корпус из 20–50 реальных изображений. Не обязательно брать сотни файлов: важнее разнообразие. Включите типичные камеры, размеры и стили обработки. Если сайт публикует предметную съёмку на белом фоне, такие кадры должны занимать значимую часть теста; если это новостной ресурс — добавьте фотографии с шумом, скриншоты, кадры с текстом на плакатах.

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

Сравнивать полезно не средний процент экономии, а распределение. Например, если 80% файлов становятся меньше, 15% почти не меняются, а 5% растут, pipeline может автоматически сохранять старый файл для последней группы. Такая стратегия лучше, чем пытаться подобрать единственный quality, который никогда не даст неудачного результата.

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

Guetzli не имеет встроенного режима «принять только если меньше». Поэтому надёжный pipeline должен самостоятельно решить, что делать с результатом. Минимальный алгоритм выглядит так: кодировать во временный файл, проверить успешный код возврата, проверить возможность декодирования, сравнить геометрию, затем сравнить размер с текущим production-файлом.

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

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

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

Безопасная схема с временными файлами

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

Схема может быть такой:

1. создать имя image.jpg.guetzli.tmp;
2. запустить Guetzli с этим выходом;
3. проверить код возврата;
4. декодировать временный файл для валидации;
5. сравнить размер с действующим image.jpg;
6. если новый файл прошёл правила — заменить старый через rename;
7. иначе удалить временный.

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

Если директория синхронизируется в CDN или объектное хранилище, лучше загружать только проверенный финальный файл. Иначе пользователь может получить промежуточный объект в момент, когда Guetzli ещё пишет данные.

Когда стоит уменьшить разрешение до Guetzli

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

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

Если нужны несколько размеров, каждый размер следует кодировать отдельно из хорошего мастер-источника. Не делайте цепочку 2400 JPEG → 1600 JPEG → 1024 JPEG. Каждое звено добавляет потери. Гораздо чище: мастер → 2400 raster → Guetzli; мастер → 1600 raster → Guetzli; мастер → 1024 raster → Guetzli.

Шум, зерно и мелкие фактуры

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

Не следует автоматически размывать фотографии перед Guetzli только ради меньшего файла. Это уже творческое изменение изображения. Однако если шум является дефектом и всё равно должен быть подавлен, корректнее выполнить denoise в фоторедакторе до финального ресайза и энкодинга. Тогда Guetzli работает с окончательным визуальным содержимым.

Аналогично с резкостью: чрезмерный oversharpening создаёт светлые и тёмные ореолы, которые JPEG приходится кодировать как реальные детали. Умеренная резкость, рассчитанная под конечный размер, обычно лучше и визуально, и по компрессии. Но Guetzli не исправляет плохой sharpening — это задача подготовки изображения.

Текст, скриншоты и искусственная графика

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

Скриншоты программ с большим количеством текста обычно разумнее оставить в PNG либо перейти на другой формат, подходящий для lossless или near-lossless графики. Если скриншот фотографический и PNG получается огромным, можно протестировать JPEG, но решение должно приниматься после увеличенного просмотра текста и тонких линий.

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

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

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

Он также не является конвертером «в любой формат». Выход — JPEG. Нет WebP, AVIF, JPEG XL, PNG-оптимизации или GIF. Если проект строит modern-image pipeline с несколькими форматами, Guetzli может быть только одной веткой — legacy JPEG.

Guetzli не предоставляет встроенной пакетной очереди, наблюдения за папкой, GUI, сравнения before/after, графика размеров или автоматического подбора quality для вашего бизнес-правила. Всё это можно построить вокруг CLI, но важно не приписывать функции самой программе.

Нет и режима lossless JPEG-оптимизации в смысле «перепаковать готовое изображение, сохранив декодированные пиксели один в один». Для этого лучше jpegoptim или jpegtran/MozJPEG в соответствующем режиме. Guetzli создаёт новое lossy-представление.

Как построить простой A/B-процесс для редакции

Если изображения публикуют редакторы, а не инженеры, не стоит заставлять каждого подбирать командную строку. Можно подготовить служебный скрипт, который принимает один мастер-файл и сам создаёт кандидаты q95, q90 и q84 в отдельной папке. Редактор открывает три результата рядом, выбирает приемлемый, а скрипт сохраняет его под production-именем.

Хороший интерфейс такого скрипта должен показывать исходный размер и размеры кандидатов, но не скрывать файлы. Пользователь должен иметь возможность увеличить кадр до 100% и увидеть реальные артефакты. «Экономия 35%» без картинки провоцирует неверный выбор.

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

Guetzli и серверная очередь задач

В бекенде лучше моделировать Guetzli как ресурсозатратную job, а не как обычную функцию преобразования. У задачи должны быть входной URI или путь, параметры, состояние, лог, лимит времени и результат. Worker берёт ограниченное число заданий, выполняет энкодинг и сообщает успех или конкретную ошибку.

Очередь позволяет реализовать backpressure: если приходит сто новых изображений, система не стартует сто процессов одновременно. Задачи ожидают свободного worker. Это особенно важно из-за RAM. Стабильная очередь с предсказуемым временем лучше кратковременного ускорения, после которого сервер уходит в swap.

Полезно хранить статистику отдельно по разрешению: медианное время для 1–2 Мп, 4–8 Мп, 12–24 Мп. Тогда можно планировать capacity на собственных данных. Не переносите в SLA чужое «минута на мегапиксель» как точную величину; используйте его только как первоначальный ориентир.

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

Контейнеры и лимиты cgroup

При запуске Guetzli в Docker или другой контейнерной среде важно различать внутренний --memlimit и внешний лимит контейнера. Если контейнеру разрешено 2 ГБ, а Guetzli запущен с --memlimit 6000, реальный потолок всё равно 2 ГБ. Процесс может быть завершён контейнерной системой раньше, чем достигнет своего внутреннего лимита.

Поэтому конфигурацию нужно согласовывать. Внешний лимит обязан быть выше рабочего пика Guetzli плюс небольшой запас на оболочку и библиотеки. Внутренний --memlimit можно установить чуть ниже контейнерного лимита, чтобы программа успела завершиться контролируемой ошибкой, а не была убита OOM killer.

Для Kubernetes запросы и лимиты памяти должны отражать реальные измерения, иначе scheduler разместит слишком много тяжёлых pods на одном узле. Guetzli редко подходит для горизонтального масштабирования «по одному pod на изображение» без строгого квотирования памяти.

Подбор параметров через тестовую матрицу

Вместо спора о «правильном» quality удобно составить простую матрицу теста. Столбцы — 95, 92, 90, 88, 86, 84. Строки — типы изображений. Для каждой ячейки фиксируются размер и отметка визуального контроля: «без различий», «различия только при 200%», «видимые дефекты при 100%», «неприемлемо».

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

Работа с исходниками из RAW-конвертера

Guetzli не читает RAW-файлы камер и не выполняет проявку. Если мастер находится в CR2, NEF, ARW, RAF, DNG или другом RAW-формате, сначала завершите работу в RAW-конвертере: баланс белого, экспозицию, профиль камеры, локальные коррекции, шумоподавление, резкость и геометрию. После этого экспортируйте промежуточный растр в sRGB.

Для передачи в Guetzli логичен PNG без прозрачности или очень качественный JPEG. PNG исключает дополнительный слой JPEG-потерь перед финальным энкодингом, но может занимать много места на диске. Высококачественный JPEG экономит I/O и место, однако уже содержит квантование. Выбор зависит от workflow; если изображений немного и качество максимально важно, PNG — более чистая промежуточная ступень.

Не экспортируйте из RAW-конвертера в Adobe RGB только потому, что это «шире», если следующим шагом будет Guetzli. Утилита предполагает sRGB и не интерпретирует ICC-профиль как указание выполнить преобразование. Подготовьте sRGB ещё в цветоуправляемой программе.

Почему повторный Guetzli поверх Guetzli обычно бессмыслен

Если файл уже был создан Guetzli, повторный запуск с тем же или близким quality не является «вторым проходом оптимизации» в привычном смысле. Новый процесс сначала декодирует JPEG в пиксели, а затем заново выполняет lossy-энкодинг. Он не продолжает внутренний поиск предыдущего запуска.

Повторная перекодировка может изменить размер в обе стороны и накопить искажения. Если нужен другой quality, лучше вернуться к мастер-источнику и создать новую версию. Это правило относится к любому lossy JPEG-процессу, но для Guetzli особенно важно из-за высокой стоимости запуска: тратить минуты на мегапиксель ради перекодировки производного файла обычно нерационально.

Исключение — диагностический эксперимент, когда вы сознательно изучаете поведение повторного кодирования. В production такой сценарий следует считать ошибкой pipeline и предотвращать по происхождению файла или хэшу стадии обработки.

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

Удобная структура проекта отделяет неизменяемые мастера от производных JPEG. Например, каталог masters/ содержит PNG или исходные высококачественные файлы, renders/ — ресайзы до конечного разрешения, а public/ — Guetzli JPEG. Тогда случайный повторный запуск не начинает кодировать уже сжатый production-файл.

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

Если проект использует content-addressed filenames, сначала кодируйте, затем вычисляйте хэш итогового JPEG. Тогда имя соответствует реальным байтам. Вычислять хэш до Guetzli и использовать его как идентификатор результата можно только как ключ стадии, но не как content hash самого output.

Диагностика неожиданно большого файла

Когда Guetzli выдаёт JPEG больше исходника, сначала ответьте на четыре вопроса. Был ли исходник уже оптимизирован? Насколько высоко задан quality? Не сравниваете ли вы PNG и JPEG только по байтам без учёта характера изображения? Не содержит ли PNG графику, которую JPEG в принципе хранит неэффективно?

Высокий quality, особенно близкий к 100, может резко увеличить размер. При таких настройках энкодер старается сохранить очень малую визуальную дистанцию и вынужден оставлять больше коэффициентов. Значение 100 не означает «без потерь», но часто делает JPEG значительно тяжелее, чем 90–95.

Если вход — уже компактный JPEG, Guetzli может создать более крупный файл, потому что текущий исходник достиг малого размера ценой более сильных искажений. Энкодер не знает, что ваша цель — победить исходник по размеру любой ценой; он следует указанной цели качества.

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

Диагностика артефактов

У JPEG есть несколько характерных дефектов, и Guetzli не отменяет физику формата. Ringing выглядит как светлые или тёмные ореолы рядом с резкой границей. Блоковость проявляется сеткой или ступенчатостью в областях с недостаточным количеством коэффициентов. Потеря высоких частот ощущается как смазывание мелкой фактуры. Цветовая субдискретизация может размывать цветные границы.

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

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

Проверка в браузере и на дисплеях разной плотности

Финальная оценка веб-изображения должна происходить не только в графическом редакторе. Браузер может масштабировать картинку до CSS-размера, устройство может иметь DPR 2 или 3, а цветовой тракт — отличаться. Поэтому после выбора quality откройте страницу в реальном layout.

На дисплее высокой плотности файл 1600 пикселей может отображаться физически меньше, и часть JPEG-артефактов визуально усредняется. На дешёвом дисплее с грубой гаммой, наоборот, градиенты могут выглядеть хуже. Это ещё одна причина не объявлять конкретный quality «визуально без потерь» для всех пользователей.

Если сайт использует CSS-фильтры, масштабирование, обрезку через object-fit или фоновые изображения, проверьте именно эти режимы. Сжатие оценивается в конечном контексте потребления.

Метрики качества: что можно автоматизировать

Guetzli внутри использует Butteraugli, но внешнему pipeline необязательно ограничиваться той же метрикой. Можно рассчитывать SSIM, MS-SSIM, PSNR-HVS или современную перцептивную метрику как дополнительный сигнал. Однако ни одна цифра не заменяет калибровку на реальном контенте.

Если автоматическая метрика используется как gate, сначала определите порог на наборе изображений, который просмотрели люди. Иначе вы просто замените ручной выбор произвольным числом. Хороший процесс: оценить несколько сотен пар, сопоставить человеческие решения с метрикой, выбрать консервативный порог и продолжать выборочный аудит.

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

Порог минимальной экономии

На практике замена JPEG ради 100 байт редко оправдана. Новый файл нужно прогнать через pipeline, инвалидировать кэш, пересобрать манифест и снова проверить. Поэтому можно установить минимальный порог экономии, например в процентах или килобайтах. Это уже бизнес-правило проекта, а не функция Guetzli.

Для больших hero-фотографий порог удобно задавать процентом. Для маленьких thumbnail относительная экономия может выглядеть большой, но абсолютная составлять несколько килобайт. Если CDN хорошо сжимает HTML и CSS, но JPEG уже сам по себе сжат, каждый килобайт картинки действительно передаётся, однако цена вычислений тоже должна учитываться.

Порог помогает избежать бессмысленных замен и уменьшает churn в репозитории бинарных ассетов.

Guetzli в современном наборе форматов

Даже если сайт отдаёт WebP или AVIF современным браузерам, JPEG часто остаётся fallback, источником для сторонних систем, электронной почты, CMS-экспорта или архивного API. Guetzli можно использовать именно на этой ветке. Он не конкурирует напрямую с AVIF как форматом: он улучшает эффективность внутри ограничений JPEG.

Для нового проекта полезно сравнить общий pipeline. Современный формат может дать большую экономию, но требовать дополнительного энкодера, переговоров Content-Type и fallback. Guetzli оставляет самый совместимый JPEG, но платит за это огромным временем кодирования и не использует преимущества новых кодеков.

Если нужен один универсальный файл для максимальной совместимости и он будет раздаваться миллионы раз, Guetzli может быть рациональным. Если инфраструктура уже умеет динамически выбирать AVIF/WebP/JPEG и быстро перекодировать изображения, роль Guetzli становится более узкой — высококачественный заранее вычисленный JPEG fallback.

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

Guetzli имеет смысл сравнивать не только с программами «для фотографий», но и с инструментами, которые решают соседние задачи. ФотоМАСТЕР — полноценный редактор, поэтому его сильная сторона находится до стадии Guetzli: визуальная правка изображения. MozJPEG — прямой JPEG-энкодер с оптимизациями размера и качества. jpegoptim — оптимизатор существующих JPEG, способный работать без потерь или с ограниченным lossy-пересжатием. Эти инструменты не взаимоисключающие: в реальном workflow они могут стоять на разных этапах.

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

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

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

Guetzli и MozJPEG

MozJPEG — наиболее прямой конкурент по задаче эффективного JPEG. Он расширяет libjpeg-turbo и включает trellis quantization, оптимизированные таблицы квантования, прогрессивное кодирование и оптимизацию сканов. Его можно использовать как библиотеку или через утилиты cjpeg/jpegtran. В отличие от Guetzli, MozJPEG широко ориентирован на интеграцию в приложения через стандартный libjpeg API.

Guetzli строит более тяжёлый closed-loop поиск с Butteraugli и локальным занулением DCT-коэффициентов. Это даёт интересные результаты в диапазоне высокого качества, но цена — существенно более длительное кодирование. MozJPEG обычно разумнее там, где изображения генерируются часто, latency важен или нужен progressive JPEG. Guetzli уместнее как офлайн-энкодер для статичных файлов, когда можно потратить время один раз.

Сравнивать оба энкодера нужно на одинаковой визуальной цели. Значение 90 у Guetzli не обязано соответствовать 90 у cjpeg. Создайте несколько кандидатов каждого и выберите пару с сопоставимой приемлемостью картинки.

Guetzli и jpegoptim

jpegoptim особенно полезен, когда уже есть готовые JPEG и хочется оптимизировать их структуру, метаданные или выполнить контролируемое lossy-сжатие. Он умеет оптимизировать Huffman-кодирование, работать с progressive/normal режимами, задавать максимальное качество и целевой размер, а также управлять сохранением или удалением Exif, ICC, XMP и других маркеров.

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

Комбинированный workflow

Реальный pipeline может выглядеть так: ФотоМАСТЕР или другой редактор подготавливает фотографию; ресайзер создаёт целевые размеры; Guetzli или MozJPEG формирует финальный JPEG; затем отдельная проверка управляет метаданными и размером. jpegoptim может пригодиться для уже существующего архива JPEG, который нельзя заново пересобрать из мастеров.

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

Когда Guetzli оправдан

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

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

Третий случай — исследовательский или инженерный: нужно сравнить перцептивные стратегии JPEG, изучить качество DCT-оптимизации или проверить, насколько далеко можно продвинуть стандартный JPEG без изменения декодеров. Guetzli полезен как прозрачный CLI с открытым алгоритмом.

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

Guetzli плохо подходит для интерактивной обработки пользовательских загрузок, где ответ должен появиться за секунды. Он также неудобен для больших RAW-архивов без предварительного ресайза, для PNG с прозрачностью, для скриншотов и графики, где нужен lossless, и для pipeline, где обязателен progressive JPEG.

Если нужна быстрая массовая компрессия миллионов JPEG, начните с MozJPEG, libjpeg-turbo или jpegoptim и измерьте результат. Если нужна художественная правка — используйте фоторедактор. Если нужны WebP/AVIF, выберите соответствующий кодек. Guetzli не следует насильно ставить туда, где его сильная сторона не используется.

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

• Изображение уже имеет конечное разрешение.
• Цветовое пространство корректно преобразовано в sRGB.
• PNG не содержит нужной прозрачности либо она заранее сведена с фоном.
• Есть мастер-копия, которую Guetzli не перезапишет.
• На машине достаточно RAM с запасом.
• Quality выбран по тестам на реальном контенте.
• Pipeline проверяет код возврата и корректность JPEG.
• Результат сравнивается с исходником по размеру и визуально.
• Параллелизм ограничен по памяти, а не только по числу CPU-ядер.
• Для повторных сборок настроен кэш.

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

Краткая карта параметров

У Guetzli нет штатных флагов для ресайза, вращения, выбора progressive JPEG, массового поиска файлов, сохранения в WebP или управления EXIF по полям. Если в найденной инструкции встречается большой набор таких опций, скорее всего, речь идёт об оболочке, форке или другой программе. Для воспроизводимого материала важно отделять возможности оригинального Guetzli от возможностей сторонней обвязки.

Сценарий для главной фотографии лендинга

Hero-изображение обычно крупное, заметное и часто загружается каждым посетителем. Это один из случаев, где дополнительные минуты офлайн-кодирования могут окупаться трафиком. Сначала подготовьте кадр в редакторе: окончательная композиция, цвет, шумоподавление, резкость и точный размер. Затем экспортируйте sRGB без прозрачности.

Создайте как минимум два кандидата Guetzli, например 95 и 90. Откройте их в браузере в реальном блоке лендинга и отдельно при 100%. Если 90 визуально проходит проверку и заметно меньше, используйте его. Если фон содержит плавный градиент или мелкие детали на контрастном крае и 90 даёт дефекты, 95 может быть оправдан, потому что изображение является визуальным центром страницы.

После выбора положите JPEG в CDN как неизменяемый ассет и используйте долгий cache-control с content hash. Тогда дорогое кодирование действительно выполняется один раз.

Сценарий для карточек товаров

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

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

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

Сценарий для большой фотогалереи

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

Разделите процесс на этапы. Сначала создайте thumbnails и полноразмерные web-версии быстрым ресайзером. Затем добавьте задания Guetzli в очередь. Публикация статьи может использовать исходный качественный JPEG, а оптимизированный файл заменит его после готовности, если инфраструктура допускает такую схему. Для статической генерации можно наоборот дождаться всей очереди перед деплоем.

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

Сценарий для старого архива JPEG

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

Если главная цель — убрать лишние метаданные и оптимизировать Huffman-кодирование без новых визуальных потерь, начните с jpegoptim. Guetzli уместен, когда допустима новая lossy-перекодировка и вы готовы визуально проверить результат.

Для архива с неизвестным цветовым профилем особенно важна предварительная классификация. Если часть файлов в Adobe RGB, слепая обработка Guetzli может привести к цветовому несоответствию. Сначала нормализуйте цветовой pipeline.

Сценарий для статического генератора сайта

В SSG-проекте изображения обычно известны на момент сборки, поэтому Guetzli можно вынести в отдельный production-step. Локальная разработка не должна ждать тяжёлого энкодинга. При добавлении изображения сборочная система создаёт оптимизированную версию один раз и кладёт её в кэш.

Хорошая зависимость задачи выглядит так: мастер + параметры ресайза + quality + идентификатор энкодера → готовый JPEG. Если ни один вход не изменился, задача считается актуальной. Если изменился только HTML, изображения не пересчитываются.

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

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

Guetzli уменьшает разрешение изображения?

Нет. Утилита кодирует тот же растр в JPEG и не является ресайзером. Если нужно уменьшить ширину и высоту, сделайте это до Guetzli. Это одновременно снизит будущий размер файла, время кодирования и расход памяти.

Можно ли получить PNG на выходе?

Нет. PNG разрешён как вход, но результат — JPEG. Если нужен оптимизированный PNG, требуется PNG-ориентированный инструмент.

Поддерживается ли прозрачность?

JPEG не поддерживает alpha, а прозрачный PNG при кодировании Guetzli композитится на чёрный фон. Сведите прозрачность заранее либо оставьте формат с alpha.

Что произойдёт без --quality?

Используется значение 95. Это удобная исходная настройка высокого качества, но не универсально оптимальная для каждого проекта.

Почему нельзя указать quality 70?

Штатный Guetzli ограничивает нижнюю границу значением 84 и прямо сообщает, что ниже ожидаются заметные артефакты. Алгоритм проектировался для высокого качества, поэтому для более агрессивного диапазона лучше выбрать другой JPEG-энкодер.

Quality 100 означает lossless?

Нет. Guetzli не становится lossless-кодеком. Значение 100 задаёт очень высокую цель качества, но JPEG-процесс и внутренняя оптимизация остаются lossy. Кроме того, размер при 100 может резко вырасти.

Можно ли использовать Guetzli для изображений из камеры?

Да, если камера уже дала JPEG, либо после проявки RAW в другом ПО. Но большой 24–50-мегапиксельный файл потребует очень много RAM и времени. Для веба сначала создайте конечный размер.

Нужно ли включать --verbose всегда?

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

Поможет ли --nomemlimit, если не хватает RAM?

Нет. Он лишь снимает внутренний предел Guetzli. Если физической памяти мало, операционная система всё равно начнёт swap или завершит процесс. Решение — уменьшить изображение, увеличить RAM, снизить параллелизм или сменить энкодер.

Можно ли ускорить работу большим числом параллельных процессов?

Только если хватает памяти. Параллельность ускоряет партию, но умножает пиковый RAM. Для Guetzli число workers выбирают прежде всего по памяти, а затем по CPU.

Стоит ли запускать Guetzli после jpegoptim?

Обычно нет смысла оптимизировать старый JPEG lossless-утилитой, а затем сразу декодировать и заново lossy-кодировать его Guetzli: часть предыдущей оптимизации структуры будет отброшена. Если Guetzli является финальным энкодером, ставьте его до чисто метаданных или контейнерных операций, а лучше формируйте файл напрямую из качественного мастера.

Стоит ли запускать jpegoptim после Guetzli?

Это допустимо как отдельный эксперимент без изменения пикселей, если jpegoptim используется в lossless-режиме для оптимизации структуры или управления маркерами. Но экономия может быть небольшой, и каждую дополнительную стадию следует оправдать измерениями. Не используйте lossy-режим jpegoptim после Guetzli без необходимости: это добавит ещё одну потерю.

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

Наиболее предсказуемый процесс с Guetzli выглядит так: сначала изображение полностью редактируется и приводится к нужному размеру, затем корректно преобразуется в sRGB и лишается ненужной прозрачности, после чего Guetzli создаёт финальный JPEG с заранее протестированным quality. Результат сохраняется отдельно, валидируется, сравнивается по размеру и только после этого становится production-файлом.

Сильная сторона Guetzli — способность очень глубоко искать компактное JPEG-представление в диапазоне высокого визуального качества, используя Butteraugli и локальную оптимизацию коэффициентов. Ограничения столь же конкретны: чрезвычайно медленное кодирование, большой расход памяти, только JPEG на выходе, отсутствие progressive-режима, зависимость от корректного sRGB-входа и отсутствие встроенных функций редактирования.

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

Пробный прогон перед большой партией

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

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

Затем повторите команду на самом крупном по разрешению изображении из партии. Именно разрешение важнее размера на диске при оценке RAM. Если тяжёлый файл упирается в лимит, уменьшите число параллельных workers или вынесите крупные кадры в отдельную очередь. Не стоит обнаруживать это после запуска восьми процессов одновременно.

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