Обзор Jpegoptim: сжатие JPEG без графического интерфейса

Jpegoptim — узкоспециализированная консольная утилита для оптимизации файлов JPEG и JFIF. Она не редактирует композицию кадра, не меняет размер изображения и не предлагает визуальный предпросмотр: пользователь задаёт режим обработки параметрами командной строки, а программа перезаписывает исходный файл, сохраняет результат в другой каталог или передаёт его в стандартный вывод. Главная ценность Jpegoptim заключается в двух режимах: оптимизации таблиц Хаффмана без изменения пикселей и повторном кодировании с ограничением качества либо размера. Такой набор делает программу подходящей для серверных сценариев, сборочных процессов и массовой подготовки уже готовых JPEG, но требует аккуратного обращения с исходниками, метаданными и параметрами потерь.

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

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

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

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

Что представляет собой Jpegoptim

Jpegoptim разработан Тимо Кокконеном и существует как отдельная программа командной строки, написанная на C и использующая библиотеку libjpeg либо совместимую реализацию. Это не веб-сервис, не мобильное приложение, не плагин для графического редактора и не графическая оболочка. Программа принимает JPEG-файлы, анализирует их структуру, заново формирует поток данных и сохраняет результат только в JPEG.

Стабильным выпуском на 6 августа 2026 года остаётся Jpegoptim 1.5.6, опубликованный в сентябре 2025 года. В основной ветке репозитория уже обозначена версия 1.5.7beta, где исправлено зацикливание, которое иногда возникает у параметра –auto-mode в 1.5.6. Это означает, что проект не закрыт, однако текущую стабильную сборку нельзя автоматически считать идентичной состоянию основной ветки. Для производственного окружения версию исполняемого файла следует фиксировать и проверять командой jpegoptim –version.

Название программы иногда смешивают с графическими оптимизаторами и сайтами, содержащими похожее слово. Оригинальный Jpegoptim определяется сочетанием признаков: автор Тимо Кокконен, консольный исполняемый файл jpegoptim, исходный код в репозитории tjko/jpegoptim, поддержка JPEG/JFIF и параметры вида –max, –size, –strip-all. Он не связан с коммерческими онлайн-компрессорами и не содержит встроенной загрузки фотографий на удалённый сервер.

Основные параметры

Распространение, платформы и установка

Готовые архивы

Для выпуска 1.5.6 опубликованы готовые архивы x64 для Linux, macOS и Windows, а также исходный код. Архивная поставка не равна обычному мастеру установки: в ней находится исполняемый файл и сопутствующие материалы, поэтому пользователю приходится самостоятельно разместить программу в каталоге, доступном через переменную PATH, либо вызывать её по полному пути.

Наличие готовой x64-сборки не означает, что программа ограничена только этой архитектурой. Jpegoptim компилируется из исходного кода, а пакетные менеджеры могут предоставлять собственные сборки для других архитектур. Например, актуальная формула Homebrew включает варианты для Apple Silicon, Intel macOS, Linux ARM64 и Linux x86_64. Версия в системном репозитории при этом может отставать от стабильного выпуска проекта, поэтому номер установленного пакета нужно проверять отдельно.

Установка через пакетный менеджер

На macOS и Linux с Homebrew используется команда brew install jpegoptim. В дистрибутивах Linux программа также встречается в штатных репозиториях, но конкретная команда и номер пакета зависят от дистрибутива. Это важно при переносе сценариев между серверами: набор параметров 1.5.6 шире, чем у старых выпусков, а неизвестная опция приводит к немедленному завершению команды.

Сборка из исходного кода

Базовая последовательность сборки использует ./configure, make и make install. Требуется libjpeg версии 6b или новее; вместо неё поддерживаются libjpeg-turbo и mozjpeg. В проекте также присутствует конфигурация CMake. Итоговое поведение зависит не только от версии Jpegoptim, но и от подключённой JPEG-библиотеки: она участвует в кодировании, формировании JFIF и Adobe-маркеров, а также определяет доступность отдельных экспериментальных возможностей.

Windows и различия сборок

Windows входит в перечень протестированных платформ, а для 1.5.6 опубликован отдельный x64-архив. При этом параметр –workers компилируется только при наличии системных функций fork и wait. Поэтому его нельзя считать универсальной возможностью каждой Windows-сборки. Проверять доступные параметры следует локальной командой jpegoptim –help, а не перечнем из документации другой платформы.

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

Как устроен интерфейс

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

Структура команды

Общая форма выглядит как jpegoptim параметры имена_файлов. Параметры могут записываться в коротком POSIX-виде с одним дефисом или в длинном GNU-виде с двумя дефисами. Например, -m80 и –max=80 задают один режим. Длинная запись понятнее в сценариях, короткая сокращает ручной ввод.

Зона выбора входных данных

Файлы перечисляются после параметров. Для больших наборов предусмотрены –files-from=имя_файла и –files-stdin; в обоих случаях ожидается по одному имени на строку. Отдельный параметр –stdin предназначен не для списка, а для чтения одного JPEG-потока. Одновременно использовать –stdin и –files-stdin нельзя.

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

Зона параметров обработки

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

Текстовый отчёт

Для каждого файла программа выводит имя, размеры в пикселях, глубину, обозначение прогрессивного или обычного режима, найденные маркеры, состояние чтения, исходный и итоговый размер, процент уменьшения и финальный статус optimized либо skipped. При ошибке появляется диагностическое сообщение. Параметр –csv меняет отчёт на CSV, –totals добавляет среднее сжатие и суммарную экономию, –quiet подавляет обычный вывод, а –verbose показывает дополнительные детали.

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

Как работает оптимизация без потерь

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

Термин «без потерь» здесь относится к изображению, а не к полной идентичности файла. Байты на выходе меняются, порядок и набор маркеров могут отличаться, неизвестные маркеры по умолчанию отбрасываются, данные после маркера конца изображения удаляются, а JFIF и Adobe-маркеры могут быть сформированы библиотекой заново. Поэтому контрольная сумма файла изменится даже при неизменных пикселях.

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

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

Сжатие с потерями: ограничение качества

Параметр –max переводит программу в режим с потерями. Значение находится в диапазоне от 0 до 100 и задаёт верхний предел качества. Если исходный JPEG оценён как сохранённый с более высоким качеством, он декодируется и кодируется заново с указанным пределом. Если исходная оценка уже ниже, применяется оптимизация без изменения пикселей.

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

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

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

Подбор целевого размера

Параметр –size пытается приблизить выходной JPEG к заданному объёму. Значение задаётся в килобайтах либо в процентах от исходного файла. Для подбора программа начинает с качества 100 и выполняет двоичный поиск подходящего значения качества.

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

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

Если требование платформы сформулировано как «не более 500 КБ», разумно выбирать цель с небольшим запасом, а затем проверять фактический размер средствами файловой системы. Jpegoptim сообщает итоговый объём в отчёте, но внешняя проверка остаётся необходимой частью автоматического конвейера.

Обычный и прогрессивный JPEG

Стабильная версия 1.5.6 по умолчанию сохраняет исходный тип: обычный JPEG остаётся обычным, прогрессивный — прогрессивным. Параметр –all-progressive заставляет формировать прогрессивный поток, а –all-normal — обычный. Для гарантированной конвертации уже оптимального файла может потребоваться –force, поскольку без него более крупный результат будет пропущен.

Параметр –auto-mode сравнивает оба варианта и оставляет меньший. В 1.5.6 у него есть известная проблема: в отдельных случаях обработка может зациклиться. В ветке 1.5.7beta указано исправление именно этого поведения. До выхода стабильной версии с исправлением –auto-mode не следует без контроля времени использовать в серверной задаче, где зависший процесс блокирует очередь. Для предсказуемого конвейера безопаснее явно сохранить исходный режим или выбрать –all-progressive после проверки на тестовом наборе.

Экспериментальные параметры –all-arith и –all-huffman появляются только в сборках с включённой поддержкой арифметического кодирования. Их наличие нельзя определять по номеру версии: требуется проверка локальной справки и конфигурации сборки.

Метаданные и приватность

Jpegoptim не является автоматическим очистителем приватных данных. По умолчанию он сохраняет распространённые маркеры EXIF, IPTC, ICC, XMP и комментарии COM. Следовательно, координаты съёмки, дата, модель камеры, подписи, рейтинги и другие сведения могут остаться в оптимизированном файле, если они записаны в этих блоках.

Для полного удаления доступен –strip-all. Он отключает сохранение известных метаданных, хотя выходной JPEG всё равно может содержать JFIF или Adobe APP14, сформированные JPEG-библиотекой. Более точный подход состоит в сочетании –strip-all с параметрами –keep-exif, –keep-iptc, –keep-icc, –keep-xmp, –keep-com, –keep-jfif, –keep-jfxx или –keep-adobe.

Обратная схема строится на –keep-all либо –strip-none и точечном удалении через –strip-exif, –strip-iptc, –strip-icc, –strip-xmp, –strip-com, –strip-jfif, –strip-jfxx и –strip-adobe. Параметр –keep-all имеет приоритет над остальными правилами сохранения и удаления, поэтому смешивать его с точечными флагами бессмысленно.

Удаление ICC-профиля способно изменить отображение цвета в программах с управлением цветом. Для публикации фотографий безопаснее очищать персональные EXIF и XMP, но сохранять ICC, если профиль нужен для корректной интерпретации цвета. Универсальная команда –strip-all уменьшает файл и удаляет больше служебных данных, однако одновременно убирает сведения, полезные для архива, печати и профессионального рабочего процесса.

Неизвестные маркеры по умолчанию отбрасываются. Если JPEG содержит нестандартное расширение, важное для другой программы, требуется –keep-all и отдельная проверка совместимости. Данные после формального конца JPEG также удаляются по умолчанию. Параметр –save-extra сохраняет этот хвост, но не работает для изображения, читаемого через стандартный ввод.

Обработка выполняется локально. В программе нет учётной записи, облачного хранилища, сетевой отправки изображений или ИИ-модуля. Риск приватности связан не с передачей файла разработчику, а с тем, какие метаданные пользователь оставляет в готовом JPEG и кому затем передаёт результат.

Поддерживаемые форматы, импорт и экспорт

Jpegoptim принимает и создаёт JPEG/JFIF. Он не открывает RAW-файлы камер, PNG, TIFF, HEIC, AVIF, WebP, GIF, SVG или PDF. Если исходник находится в другом формате, его сначала преобразуют отдельным конвертером или экспортируют из фоторедактора в JPEG.

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

Входные способы включают имена файлов в командной строке, список из текстового файла, список через стандартный ввод и один JPEG через –stdin. Выход записывается поверх исходника, в каталог, заданный –dest, либо в стандартный вывод через –stdout.

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

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

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

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

Несколько JPEG можно передать одной команде. Каждый файл обрабатывается независимо, а итоговый код завершения становится ненулевым, если возникли ошибки декодирования или кодирования. Для сценария это важнее текста optimized: автоматизация должна проверять код возврата и сохранять журнал.

Параметр –files-from удобен для больших списков, сформированных системой управления контентом, сборочным процессом или файловым поиском. Формат прост: одно имя на строку. Параметр –files-stdin читает такой список из конвейера. Имена с переводом строки внутри самого имени файла таким способом представить нельзя, поэтому в среде, где допустимы необычные имена, список требует предварительной нормализации.

–workers запускает несколько рабочих процессов параллельно в поддерживающих это сборках. Исходный код ограничивает максимальное значение числом 256, однако устанавливать его равным максимуму нецелесообразно. Сжатие с потерями хранит декодированное изображение в памяти; крупные фотографии при большом числе работников способны резко увеличить потребление ОЗУ. Практическое значение выбирают по числу ядер, размеру файлов и доступной памяти.

Без –workers файлы идут последовательно. Этот режим проще диагностировать, даёт упорядоченный журнал и подходит для небольших наборов. Параллельная обработка нужна при регулярной работе с тысячами JPEG, но только после проверки, что конкретная сборка действительно показывает параметр в справке.

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

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

Ниже приведён воспроизводимый пример подготовки каталога JPEG для сайта с сохранением исходников. Он показывает логику работы, но не заменяет выбор параметров под конкретные фотографии.

1. Создаётся отдельный пустой каталог для результатов. Исходные JPEG остаются в рабочем архиве без изменений.
2. Проверяется версия: jpegoptim –version. Для функций –retry, –save-extra и –auto-mode нужна версия 1.5.6, но последний параметр в этой версии имеет известный риск зацикливания.
3. Выполняется пробный расчёт без записи: jpegoptim –noaction –max=82 –strip-all –keep-icc photo.jpg. Отчёт показывает предполагаемый размер и статус.
4. После визуальной оценки тестового набора запускается запись в отдельный каталог: jpegoptim –max=82 –strip-all –keep-icc –dest=output photo1.jpg photo2.jpg.
5. Проверяется, какие файлы реально появились в output. Пропущенные изображения не копируются автоматически, если оптимизированный вариант не меньше.
6. Сравниваются размеры, разрешение, ориентация, цвет и детали на увеличении. Отдельно проверяется наличие или отсутствие EXIF, XMP и ICC.
7. Только после успешной проверки тот же профиль применяется к большому списку. Для автоматизации добавляется журнал и контроль кода завершения.

Значение 82 в примере не является универсальной рекомендацией. Оно выбрано только для демонстрации синтаксиса. Реальный предел определяют по визуальному сравнению изображений, требованиям площадки и допустимому размеру.

Для оптимизации без изменения пикселей команда короче: jpegoptim –dest=output photo.jpg. Если нужно сохранить все известные и неизвестные маркеры, добавляется –keep-all. Если задача состоит только в оценке возможной экономии, используется –noaction.

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

Проверка режима без потерь

Одинаковый внешний вид недостаточен для доказательства неизменности пикселей, а одинаковая контрольная сумма невозможна из-за перестройки файла. Надёжная проверка состоит в декодировании исходного и итогового JPEG в одинаковый несжатый формат и поканальном сравнении пикселей. Для такого контроля подходит специализированный инструмент сравнения изображений. При штатной оптимизации без –max и –size декодированные пиксели должны совпадать.

Проверка режима с потерями

После –max или –size пиксели отличаются по определению. Проверка включает просмотр при масштабе 100 процентов и выше, сравнение контрастных границ, мелкого текста, волос, листвы, теней, участков с цветовым шумом и плавных градиентов. Оценивать только миниатюру нельзя: блоки, ореолы и потеря мелкой фактуры часто проявляются при увеличении.

Проверка структуры файла

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

Проверка метаданных

После очистки сравнивается список EXIF, IPTC, XMP, ICC и комментариев. Отсутствие EXIF не означает отсутствие всех служебных блоков: JFIF и Adobe APP14 могут быть созданы библиотекой. Если требуется сохранить цвет, отдельно проверяется ICC-профиль. Для конфиденциальной публикации контролируются координаты, серийный номер камеры, имя автора и пользовательские поля XMP.

Проверка файловой операции

В режиме –dest проверяется не только качество, но и полнота каталога. Файл со статусом skipped может отсутствовать в папке результата. При перезаписи исходников контролируются права доступа, владелец, временные метки и наличие резервной копии вне рабочего каталога.

Ограничения и риски

• По умолчанию программа заменяет исходный файл, если получает меньший результат.
• Режимы –max и –size необратимо меняют изображение.
• Каталог назначения не получает неизменённые файлы, поэтому не является полной копией набора.
• Поддерживается только JPEG/JFIF; конвертация других форматов отсутствует.
• Нет изменения размера, кадрирования, поворота, цветокоррекции, повышения резкости и водяных знаков.
• Нет графического предпросмотра и сравнения до и после.
• Метаданные по умолчанию сохраняются, поэтому приватная информация не удаляется автоматически.
• –strip-all удаляет ICC вместе с другими блоками, если профиль не оставить отдельным параметром.
• Неизвестные маркеры и данные после конца изображения отбрасываются по умолчанию.
• –size не гарантирует точное совпадение с целевым размером.
• –auto-mode в стабильной версии 1.5.6 имеет известный риск зацикливания.
• –workers зависит от возможностей платформы и сборки.
• Символические ссылки, специальные файлы и каталоги пропускаются.
• Другие жёсткие ссылки на заменяемый файл не обновляются, потому что оптимизированный файл записывается как новый объект и переименовывается поверх исходного.
• Английская командная справка требует понимания терминов JPEG и поведения оболочки.

Работа с файлами, правами и временем изменения

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

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

–preserve-perms использует другой механизм: исходник перезаписывается с временной резервной копией .jpegoptim.bak, которая удаляется после успешной замены. Руководство называет этот режим немного менее безопасным, чем стандартная запись во временный файл с последующим переименованием. При запуске от root он обычно не нужен, поскольку стандартный режим способен восстановить владельца и права.

Жёсткие ссылки требуют отдельного решения. После замены пути новый файл получает новый объект файловой системы, а другие жёсткие ссылки продолжают указывать на прежние данные. В коллекции, где дедупликация построена на hard link, Jpegoptim способен нарушить ожидаемую связь между копиями. Перед массовой обработкой такие файлы нужно выявить и определить, какой вариант должен остаться общим.

Обработка повреждённых JPEG

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

–nofix заставляет пропускать входные JPEG при любых ошибках или предупреждениях декодирования. Для архивной коллекции это более консервативный режим: подозрительный файл не переписывается и попадает в журнал для отдельного анализа.

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

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

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

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

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

Параметр не распознаётся

Установлена старая версия либо сборка без нужной функции. Сначала сверяется –version, затем локальная справка –help. Особенно это относится к –workers, экспериментальному арифметическому кодированию и параметрам, добавленным в линейке 1.5.x.

Файл исчез из ожидаемого каталога результата

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

Целевой файл уже существует

Без –overwrite программа не заменяет одноимённый файл в каталоге назначения. Проверяются путь, имя и содержимое папки. Автоматическое включение перезаписи оправдано только тогда, когда каталог действительно является расходным результатом.

Размер почти не уменьшился

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

После очистки изменился цвет

Вероятная причина — удалённый ICC-профиль. Проверяется набор параметров и наличие –keep-icc. Если изображение было подготовлено в нестандартном цветовом пространстве, сохранение профиля особенно важно.

Изображение повернулось неправильно

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

Процесс с –auto-mode не заканчивается

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

Параллельная обработка недоступна

Сборка не содержит поддержки fork и wait, поэтому параметр отсутствует. Это не исправляется изменением командной строки: нужна другая сборка или последовательный запуск.

Память быстро заканчивается

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

Поток JPEG повреждается в конвейере

Бинарный вывод должен направляться в файл или следующую программу без примеси текста. Jpegoptim отправляет журнал в stderr при –stdout, но оболочка может объединять потоки. Проверяется перенаправление и исключается запись диагностических сообщений в JPEG.

Стоимость, редакции и лицензирование

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

Репозиторий помечает проект как GPL-3.0, а заголовки актуального исходного кода используют формулировку GPL-3.0-or-later. В руководстве версии 1.5.6 при этом сохраняется более старая формулировка GPL версии 2 или любой последующей. Для обычного запуска программы эта разница не создаёт тарифа или функционального ограничения. При распространении изменённой сборки либо включении исходного кода в продукт нужно ориентироваться на файл LICENSE и уведомления конкретного исходного пакета, а не на краткое описание в магазине пакетов.

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

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

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

• Веб-разработчикам, которым нужна локальная оптимизация готовых JPEG перед публикацией.
• Системным администраторам, автоматизирующим обработку изображений на сервере.
• Владельцам статических сайтов, включающим оптимизацию в сборочный процесс.
• Фотографам с техническим опытом, которым требуется пакетная очистка метаданных и сохранение ICC.
• Архивным специалистам, если используется только режим без потерь, отдельный каталог и строгая проверка метаданных.
• Разработчикам конвейеров, которым нужны stdin, stdout, списки файлов, CSV и код возврата.
• Пользователям слабых серверов, если достаточно последовательной обработки без графической среды.

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

• Новичкам, ожидающим окно с предпросмотром: все действия задаются текстовыми параметрами.
• Тем, кому нужно уменьшить разрешение: Jpegoptim не меняет ширину и высоту.
• Пользователям RAW, PNG, HEIC, WebP и AVIF: эти форматы не поддерживаются.
• Для художественной обработки: нет экспозиции, цвета, ретуши, резкости и фильтров.
• Для мобильной работы: официального мобильного приложения нет.
• Для разовой фотографии без терминала: графический оптимизатор будет проще.
• Для гарантированного попадания в точный размер: –size даёт приближение, а не строгий предел.
• Для полного резервного копирования через –dest: пропущенные файлы не копируются.
• Для автоматического выбора progressive в 1.5.6 без контроля: известное зацикливание делает такой процесс ненадёжным.

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

jpegtran из libjpeg-turbo

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

MozJPEG

MozJPEG — форк libjpeg-turbo, ориентированный на более эффективное JPEG-кодирование для веба. Его инструменты используют оптимизированные таблицы, прогрессивное энтропийное кодирование и дополнительные методы вроде trellis-квантизации. Выбор оправдан, когда приоритетом является максимальная эффективность нового кодирования и допустим более сложный набор инструментов. Jpegoptim удобнее как компактная команда для уже существующих JPEG и может быть собран с MozJPEG в качестве библиотеки.

ImageMagick

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

ImageOptim

ImageOptim — бесплатное приложение для macOS с графическим перетаскиванием файлов. Оно объединяет несколько оптимизаторов, включая Jpegoptim и jpegtran, и ориентировано на пользователей, которым не нужен терминал. Для ручной работы на Mac интерфейс удобнее, но серверная автоматизация, потоковый ввод и точное управление параметрами Jpegoptim остаются преимуществами оригинальной CLI-утилиты.

Когда альтернативу выбирать разумнее

Для поворота JPEG без потерь предпочтителен jpegtran. Для нового кодирования с максимальным вниманием к эффективности — MozJPEG. Для изменения размеров и конвертации форматов — ImageMagick. Для ручной оптимизации на macOS — ImageOptim. Jpegoptim остаётся рациональным выбором, когда вход уже является JPEG, требуется локальная пакетная обработка и важен простой интерфейс командной строки.

FAQ

Jpegoptim действительно не меняет качество по умолчанию?

Да. Без –max и –size программа оптимизирует кодирование коэффициентов JPEG без изменения декодированных пикселей. При этом метаданные и структура файла могут измениться.

Почему контрольная сумма отличается после режима без потерь?

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

Можно ли получить PNG или WebP?

Нет. Вход и выход Jpegoptim ограничены JPEG/JFIF. Для других форматов требуется отдельный конвертер.

Удаляет ли программа GPS автоматически?

Нет. EXIF сохраняется по умолчанию. Для удаления используется –strip-exif либо –strip-all с явным сохранением нужных блоков, например ICC.

Почему после –strip-all остались маркеры?

JFIF и Adobe APP14 могут быть сгенерированы JPEG-библиотекой при записи. –strip-all удаляет сохраняемые блоки, но не гарантирует файл без любого APP-маркера.

Можно ли сохранить исходники?

Да. Используется –dest с отдельным каталогом. Нужно учитывать, что неизменённые файлы в этот каталог не копируются.

Есть ли рекурсивная обработка папок?

Встроенного обхода дерева нет. Список файлов формирует оболочка или внешний инструмент, после чего он передаётся как аргументы, через –files-from или –files-stdin.

Что означает –retry?

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

Можно ли использовать –auto-mode в автоматизации?

В стабильной версии 1.5.6 этот режим иногда зацикливается. В ветке 1.5.7beta проблема исправлена, но до стабильного выпуска безопаснее выбрать явный режим или ограничивать время процесса.

Почему –workers отсутствует в справке?

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

Русский интерфейс существует?

Отдельной локализации нет. Названия параметров, справка и диагностические сообщения написаны на английском.

Нужен ли интернет после установки?

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

Можно ли использовать Jpegoptim как средство восстановления JPEG?

Нет. Программа способна повторно записать некоторые файлы с предупреждениями, но не является восстановителем повреждённых фотографий. Для консервативной обработки используется –nofix.

Почему размер после –size не совпадает с целью?

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

Итог по сценариям использования

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

Для уменьшения файлов с потерями Jpegoptim подходит только после визуального подбора –max на репрезентативных изображениях. –size решает задачу приблизительного ограничения объёма, но не заменяет контроль фактического размера и качества. –retry оправдан лишь там, где несколько дополнительных байтов важнее времени обработки.

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

Для массовой автоматизации сильными сторонами являются списки файлов, stdin, stdout, CSV и код возврата. Ограничениями остаются отсутствие рекурсивного обхода, зависимость –workers от сборки и известное зацикливание –auto-mode в стабильной 1.5.6. При фиксированной версии, отдельном каталоге и внешнем контроле результата Jpegoptim выполняет свою узкую задачу без облака, подписки и лишних функций.