Обзор MozJPEG: сжатие JPEG через библиотеку и командную строку

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

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

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

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

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

Специфика продукта определяет и подход к обзору. У MozJPEG нет привычных панелей инструментов, миниатюр, истории правок или кнопки «Экспорт». Пользователь взаимодействует либо с библиотечным API, совместимым с libjpeg, либо с консольными утилитами, среди которых демонстрационный кодировщик cjpeg и инструмент jpegtran. При этом итоговые файлы остаются обычными JPEG: для просмотра на сайте не требуется специальный декодер или плагин.

На 7 августа 2026 года последний опубликованный тег проекта — v4.1.5 от 12 октября 2023 года. Репозиторий при этом не заморожен: ветка master содержит изменения 2025 года, а ее CMake-конфигурация уже обозначает версию 5.0.0. Отдельного тега v5.0.0 в списке выпусков нет, поэтому для воспроизводимой рабочей среды разумно различать стабильный тег 4.1.5 и текущее состояние ветки разработки.

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

Что именно представляет собой MozJPEG

MozJPEG — не фоторедактор и не самостоятельный настольный компрессор. Это форк libjpeg-turbo с дополнительными методами JPEG-кодирования. Проект сохраняет libjpeg API и ABI и задуман как drop-in replacement: приложение, уже использующее libjpeg, может подключить MozJPEG без перехода на новый формат файла.

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

Чем MozJPEG отличается от libjpeg-turbo

libjpeg-turbo делает акцент на высокой скорости кодирования и декодирования, в том числе за счет SIMD. MozJPEG использует эту технологическую базу, но стандартный профиль включает более затратные методы: оптимизацию Хаффмана, прогрессивное кодирование, оптимизацию последовательности сканов и trellis-квантизацию. Улучшения MozJPEG можно отключить во время выполнения, приблизив поведение к libjpeg-turbo.

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

Текущий статус и версии

Последний опубликованный тег проекта — v4.1.5 от 12 октября 2023 года; CMakeLists.txt этого тега содержит номер 4.1.5. На странице GitHub Releases отметка Latest относится к более ранней карточке v4.1.1 от 15 августа 2022 года, поскольку последующие версии опубликованы как теги, а не как аналогично оформленные Release-записи.

Ветка master развивалась и после 4.1.5: в ней есть изменения 2025 года, а текущий CMakeLists.txt содержит номер 5.0.0. Отдельного тега v5.0.0 нет, поэтому master следует считать веткой разработки, а не опубликованным стабильным выпуском 5.0. Для воспроизводимой сборки разумно фиксировать конкретный тег или commit.

Платформы, распространение и системные требования

MozJPEG распространяется прежде всего как исходный код. Для v4.1.5 доступны исходные архивы, а сборка основана на CMake. Документация охватывает Windows, Linux, macOS, FreeBSD, Solaris и Cygwin; для iOS и Android приведены отдельные рецепты. Это библиотека и набор консольных утилит, а не приложение с универсальным графическим установщиком.

Для ветки 4.1.5 документирован CMake 2.8.12 или новее. На x86/x86-64 для SIMD-сборок применяются NASM 2.13+ либо Yasm 1.2.0+; в Unix-среде рекомендованы GCC 4.1+ или Clang, а на Windows описаны Microsoft Visual C++ 2005+ и MinGW. Эти значения — нижние документированные границы старой сборочной базы, а не рекомендация использовать устаревшие компиляторы сегодня.

Настольные системы

На Unix-подобных системах CMake обычно запускают в отдельном build-каталоге, что позволяет держать несколько конфигураций одной копии исходников. На Windows библиотеку можно собирать средствами Visual C++ или MinGW; документация также приводит установку через vcpkg. При интеграции важнее всего не смешивать заголовки и бинарные файлы разных libjpeg-реализаций и учитывать ABI выбранной сборки.

Для динамической линковки на Windows нужно учитывать C runtime, с которым собрана DLL. Простая замена случайно найденного файла с подходящим именем не гарантирует загрузку. В проекте лучше закрепить один способ доставки зависимости и одну версию MozJPEG.

iOS и Android

Для Android документирована сборка через Android NDK, включая ABI arm64-v8a, armeabi-v7a, x86 и x86_64; для iOS приведена Armv8-сборка через Xcode и Clang. Это подтверждает пригодность библиотеки для встраивания в мобильное приложение, но не наличие самостоятельного приложения MozJPEG для Android или iPhone. Интерфейс, доступ к медиатеке, фоновые задачи и сохранение файлов реализует уже программа, в которую встроен кодек.

Лицензирование, цена и регистрация

У MozJPEG нет тарифов, платной редакции, пробного периода или ограниченной бесплатной версии. Исходный код открыт, оплата за количество обработанных файлов не предусмотрена, учетная запись для локального кодирования не нужна. Финансовая модель здесь принципиально отличается от SaaS-компрессоров: расходы появляются не из-за лицензии на каждый JPEG, а из-за разработки интеграции и вычислительного времени инфраструктуры.

Лицензирование наследуется от libjpeg-turbo и не сводится к одной короткой строке «BSD». В LICENSE.md перечислены три совместимые открытые лицензии: IJG License для кода libjpeg API и связанных программ, Modified BSD 3-Clause для TurboJPEG API и сборочной системы, а также zlib License для SIMD-расширений. При распространении бинарников и при статической линковке действуют требования к уведомлениям и атрибуции, поэтому коммерческому разработчику нужно сохранить лицензионные тексты в составе своей документации в соответствии с условиями пакета.

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

Интерфейс: почему у MozJPEG нет привычного окна

Графического интерфейса у проекта нет, поэтому описывать «левую панель», «холст» и «окно экспорта» было бы выдумкой. Фактических способов взаимодействия два: командная строка и библиотечный API. Консольные утилиты подходят для изучения параметров, скриптов и отдельных задач; API — основной путь интеграции в графические программы и серверные сервисы.

Командная строка cjpeg

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

Условно интерфейс cjpeg можно разделить на четыре части. Первая — вход: имя файла либо стандартный поток stdin. Вторая — параметры компрессии: quality, цветовое пространство, прогрессивность, выбор таблицы квантизации, trellis и режимы оптимизации сканов. Третья — выход: по умолчанию JPEG отправляется в stdout, а параметр -outfile задает файл. Четвертая — диагностический канал stderr, куда выводятся ошибки, версия и отчет о ходе работы при соответствующем режиме.

Базовый параметр -quality принимает значение от 0 до 100, значение по умолчанию — 75. Документация cjpeg указывает диапазон примерно 50–95 как наиболее полезный для обычных фотографий. При значениях выше примерно 95 размер файла растет заметно быстрее, чем видимая прибавка качества. Это не универсальный закон для каждой фотографии, поэтому выбор качества лучше привязывать к своему набору изображений, а не переносить одно число на все типы контента.

Библиотечный API

Для встраивания MozJPEG предпочтительнее libjpeg C API. Совместимость API и ABI позволяет программам, уже использующим libjpeg, перейти на MozJPEG без отдельного «MozJPEG SDK» со своей моделью объектов. Дополнительные параметры проекта реализованы через механизм расширения, позволяющий читать и задавать логические, целочисленные и вещественные опции компрессора без изменения публичных структур так, чтобы не ломать обратную ABI-совместимость.

Такой дизайн особенно полезен для серверных приложений. UI, очередь задач, чтение файлов, контроль памяти и политика качества остаются на стороне вызывающей программы, а библиотека получает пиксельные данные и параметры компрессии. Поэтому «интерфейс MozJPEG» в реальном продукте может выглядеть как ползунок качества в CMS, диалог экспорта в редакторе или вообще не быть видимым пользователю.

jpegtran, djpeg и вспомогательные утилиты

Сборочная система также создает инструменты, унаследованные от семейства libjpeg. djpeg декодирует JPEG в растровые форматы. jpegtran выполняет операции над JPEG без полного обычного перекодирования пикселей и используется MozJPEG, в частности, для прогрессивной оптимизации существующего JPEG. В описании проекта отдельно отмечено, что jpegrescan-оптимизацию можно применить через jpegtran к JPEG-файлу с уменьшением размера без потери изображения.

Это важно отличать от запуска cjpeg на уже существующем JPEG. cjpeg умеет распознавать JPEG как вход, но такой путь относится к повторному кодированию и может изменить изображение из-за новой квантизации. Когда задача заключается именно в структурной оптимизации готового JPEG без дополнительной потери, предпочтителен jpegtran и соответствующие lossless-операции.

Основные алгоритмы и функции сжатия

Итоговый размер JPEG зависит не только от quality. На него влияют таблицы квантизации, субдискретизация цветности, DCT, порядок прогрессивных сканов и энтропийное кодирование. MozJPEG оптимизирует несколько стадий одновременно, поэтому его профиль обычно требует больше CPU, чем стандартный libjpeg-turbo.

Оптимизированное энтропийное кодирование

Оптимизация Хаффмана в стандартном профиле включена. В cjpeg параметр -optimize уменьшает поток за счет подбора таблиц энтропийного кодирования, увеличивая время работы и расход памяти, но не добавляя новой потери качества. Это типичная для MozJPEG сделка: больше вычислений при подготовке файла ради меньшего объема передачи.

Прогрессивное кодирование и сканы

Прогрессивный JPEG используется по умолчанию. MozJPEG не ограничивается самим progressive-флагом: он разделяет DCT-коэффициенты по сканам и оптимизирует их последовательность. Параметр -fastcrush отключает оптимизацию прогрессивных сканов, а -dc-scan-opt управляет организацией DC-сканов. Эти настройки полезны при профилировании кодировочного конвейера, но для обычного пользователя слишком низкоуровневые.

Trellis-квантизация и метрики

Trellis quantization ищет более выгодное сочетание квантованных коэффициентов с учетом стоимости потока и искажения. В стандартном профиле она включена; -notrellis отключает ее, а отдельные параметры управляют DC-компонентой. cjpeg также содержит варианты настройки trellis под PSNR, PSNR-HVS, SSIM и MS-SSIM, причем стандартной метрикой является PSNR-HVS.

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

Таблицы квантизации и quality

MozJPEG содержит несколько наборов таблиц квантизации. В cjpeg 4.1.5 значением по умолчанию для -quant-table является таблица 3, связанная с настройками ImageMagick Н. Робиду; доступны и другие предустановки, включая JPEG Annex K, а также собственные qtables. Таблица и quality работают совместно, поэтому одинаковое число quality в двух кодеках не гарантирует одинакового визуального результата.

Параметр -quality принимает значения от 0 до 100, значение по умолчанию — 75. Документация cjpeg описывает 50–95 как обычно полезный диапазон для фотографий и предупреждает, что значения выше 95 резко увеличивают размер при небольшом визуальном выигрыше. Для публикации лучше сравнивать несколько профилей на одних исходниках, а не переносить число quality из другого энкодера как эквивалент.

Яркость, цветность и субдискретизация

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

Overshoot deringing и профили

В 4.1.5 присутствует overshoot-механизм для снижения ringing около контрастных переходов; параметр -noovershoot его отключает. В API предусмотрены профили JCP_MAX_COMPRESSION и JCP_FASTEST: первый включает MozJPEG-оптимизации ценой времени, второй ориентирован на быстрые стандартные настройки. В cjpeg для возврата к более обычному поведению есть -revert. Это позволяет сравнивать профили внутри одной кодовой базы и измерять, окупается ли дополнительное время конкретным уменьшением файлов.

Форматы входа и экспорта

Основной формат MozJPEG — JPEG. Библиотека принимает пиксельные буферы через API и создает JPEG-данные, поэтому реальный набор исходных форматов в интегрированном приложении определяется не только MozJPEG, а всей программой. Например, редактор может декодировать RAW или TIFF своим модулем, передать готовый RGB-буфер в MozJPEG и сохранить JPEG, хотя сам демонстрационный cjpeg не является RAW-конвертером.

У cjpeg 4.1.5 встроены читатели JPEG, BMP, GIF, PPM/PGM и Targa. Поддержка PNG является опцией сборки PNG_SUPPORTED и включена в CMake по умолчанию; для нее нужна libpng. Поэтому фактический cjpeg, собранный без PNG, не прочитает PNG, хотя исходный код проекта такую поддержку содержит.

На выходе cjpeg создает JPEG/JFIF и может писать его в stdout или в файл через -outfile. Формат не требует специального расширения MozJPEG и остается совместимым с обычными браузерами. Для встраивания ICC-профиля предусмотрена опция -icc с файлом профиля. Это важно для управляемого цветом конвейера, но сама библиотека не превращается в полноценную систему управления цветом: источник профиля и политика преобразований остаются ответственностью приложения.

Возможность читать JPEG через cjpeg следует использовать осознанно. Повторное потерное кодирование уже сжатой фотографии может усиливать артефакты. Если нужно лишь оптимизировать структуру существующего JPEG без изменения пиксельной информации, следует рассматривать jpegtran; если нужно изменить качество, размер изображения или цвет, требуется обычное декодирование и новое кодирование с контролем результата.

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

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

1. Фиксируется версия библиотеки: например, тег 4.1.5, чтобы сборка была воспроизводимой.
2. MozJPEG собирается из исходников или подключается через менеджер зависимостей, например vcpkg на Windows.
3. Входное изображение поступает в cjpeg либо декодируется приложением в пиксельный буфер для libjpeg API.
4. Задаются quality, субдискретизация и другие параметры; MozJPEG-оптимизации стандартного профиля применяются автоматически, если их не отключать.
5. Кодировщик формирует обычный JPEG, который сохраняется локально или передается следующему компоненту системы.
6. Результат проверяется: декодируемость, размеры в пикселях, цвет, наличие нужного ICC-профиля, размер файла и артефакты на характерных участках изображения.

Воспроизводимый пример с cjpeg

Для демонстрации достаточно cjpeg из сборки с поддержкой PNG. Команда cjpeg -quality 75 -outfile result.jpg source.png берет source.png, применяет качество 75 и сохраняет result.jpg. В стандартном MozJPEG-профиле оптимизация Хаффмана и прогрессивное кодирование уже включены, поэтому добавлять -optimize и -progressive ради включения стандартного поведения не требуется.

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

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

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

В MozJPEG нет отдельного окна «Batch», но сама архитектура хорошо подходит для пакетной работы. Консольный cjpeg принимает один вход за запуск, поэтому множество файлов обычно обрабатывается внешним shell-, PowerShell- или build-скриптом. В серверной программе эффективнее вызывать библиотеку непосредственно, избегая запуска отдельного процесса для каждого изображения.

Пакетный конвейер может разделять пресеты по типам контента. Фотографии допускают одну комбинацию quality и chroma subsampling, изображения интерфейса — другую, а очень маленькие превью — третью. MozJPEG не содержит искусственного интеллекта, который сам классифицирует эти файлы и выбирает идеальные настройки; такая логика должна быть реализована в вызывающей системе или задана правилами.

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

Автоматические, облачные, мобильные и ИИ-функции

Автоматизация в MozJPEG относится к алгоритмам кодека: оптимизация сканов, таблиц Хаффмана и trellis выполняется программно после выбора профиля. Это не автоматическая ретушь и не интеллектуальное распознавание сцены. Нет удаления объектов, повышения разрешения нейросетью, генерации изображения, семантического анализа или автоматической коррекции лица.

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

Мобильная поддержка существует на уровне сборки библиотеки под iOS и Android. Готового мобильного приложения Mozilla для ручного выбора фотографий в галерее в составе MozJPEG нет. Поэтому фотографу на смартфоне рациональнее использовать приложение или браузерный инструмент, который предоставляет UI и при необходимости внутри использует подходящий кодек.

Производительность и потребление ресурсов

Скорость — принципиальное ограничение MozJPEG. README проекта прямо подчеркивает асимметрию: сжатие значительно тяжелее декодирования, а стандартные настройки кодируют заметно медленнее libjpeg-turbo и даже обычного libjpeg. Это сознательный компромисс, а не дефект реализации. Проект ориентирован на ситуации, где более долгий экспорт окупается меньшим файлом.

Ускорение SIMD, унаследованное от libjpeg-turbo, остается полезным, но не отменяет вычислительную стоимость trellis и оптимизации прогрессивных сканов. На многоядерном сервере общую пропускную способность обычно повышают параллельной обработкой разных изображений на уровне приложения или очереди задач. Один вызов cjpeg не следует воспринимать как готовый планировщик пакетной многопоточной обработки всей папки.

Опция -optimize сама по себе требует больше памяти, чем стандартные энтропийные параметры. cjpeg также позволяет ограничивать память через -maxmemory. При очень больших изображениях, параллельных заданиях и контейнерах с жестким лимитом RAM это нужно учитывать: исчерпание памяти может проявляться не как ухудшение качества, а как ошибка процесса или интенсивное использование временного хранилища в зависимости от конфигурации библиотеки.

Для реального времени MozJPEG обычно не подходит. Камера, live-preview, видеострим или интерактивный удаленный экран требуют низкой задержки каждого кадра, тогда как MozJPEG создан для офлайн-подготовки. В таких задачах выгоднее быстрый профиль, libjpeg-turbo или другой кодек, оптимизированный под задержку.

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

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

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

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

Нужно также контролировать технические свойства: ориентацию, цветовое пространство, ICC, размеры в пикселях и метаданные, которые требуются вашему процессу. MozJPEG отвечает за JPEG-кодирование, но не заменяет общий контракт хранения фотоархива. Если EXIF, GPS или авторские поля важны, их сохранение должно быть отдельным проверяемым условием интеграции.

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

Сам MozJPEG работает локально. cjpeg читает файл или stdin и пишет JPEG в файл/stdout; библиотека принимает данные от приложения и возвращает сжатый поток. Обязательной сетевой передачи, аккаунта или облачного API в этой архитектуре нет. Это выгодно для конфиденциальных изображений: их не требуется отправлять третьей стороне только ради сжатия.

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

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

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

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

• Веб-разработчикам и DevOps-инженерам, которые заранее оптимизируют изображения для сайта и могут позволить более тяжелое кодирование на этапе сборки или публикации.
• Разработчикам CMS и DAM, которым нужен JPEG-энкодер внутри серверного конвейера, а UI и правила обработки уже реализованы в своей системе.
• Авторам настольных графических программ, использующих libjpeg API и желающих получить MozJPEG-оптимизации без создания отдельного формата.
• Разработчикам командных конвейеров, которым удобны stdin/stdout, скрипты и воспроизводимые параметры вместо ручного экспорта.
• Командам, работающим офлайн, когда изображения нельзя отправлять на внешний сервис, а обработку нужно выполнять в локальной инфраструктуре.
• Проектам с большим количеством показов одного изображения, где дополнительное время однократного кодирования может окупиться экономией трафика на последующих загрузках.

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

• Фотографу, который хочет готовое приложение с галереей, визуальным ползунком качества, сравнением до/после и экспортом без командной строки.
• Пользователю смартфона, которому нужен самостоятельный Android- или iOS-компрессор: проект предоставляет библиотечную сборку, а не готовое мобильное приложение.
• Системам реального времени, где задержка кодирования важнее максимальной эффективности JPEG.
• Задачам, где требуется PNG, WebP, AVIF, TIFF и множество других выходных форматов из одного инструмента: MozJPEG специализируется на JPEG.
• Редактированию фотографий со слоями, масками, ретушью, RAW-проявкой, локальными коррекциями и каталогом: этих функций в кодеке нет.
• Сценариям, где JPEG как потерный формат принципиально не подходит, например для хранения мастер-копии графики с альфа-каналом или точной пиксельной структуры.

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

libjpeg-turbo — когда важнее скорость

libjpeg-turbo — технологическая база MozJPEG и самостоятельный JPEG-кодек с SIMD-ускорением, libjpeg API и TurboJPEG API. Он лучше соответствует интерактивным и близким к реальному времени задачам, где задержка кодирования важнее дополнительной экономии размера. Формат результата остается тем же JPEG, поэтому сравнивать решения следует на одинаковых исходниках по времени, размеру и качеству.

jpegoptim — для готовых JPEG и пакетной консольной обработки

jpegoptim оптимизирует существующие JPEG из командной строки, работает на Linux, macOS и Windows, поддерживает списки файлов и параллельные workers. Он может использовать MozJPEG как библиотечную основу. Это удобнее чистого cjpeg, когда задача состоит в массовой обработке уже созданного JPEG-архива, а не во встраивании кодека в собственное приложение.

ImageMagick — когда кроме сжатия нужны преобразования

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

Squoosh — когда нужен визуальный интерфейс

Squoosh — открытое браузерное приложение с визуальным сравнением вариантов сжатия. Изображение обрабатывается локально в браузере и не отправляется на сервер; проект отдельно описывает сбор базовой аналитики и размеров до/после. Для разовой ручной оптимизации такой интерфейс заметно проще. MozJPEG предпочтительнее как библиотека автоматического C/C++-конвейера, где ручной просмотр каждого файла не нужен.

Частые проблемы при установке и сборке

CMake не находит NASM или SIMD отключается

На x86/x86-64 SIMD-сборка требует NASM либо Yasm. Если ассемблер не найден, конфигурация может перейти на вариант без SIMD, если REQUIRE_SIMD не заставляет считать это ошибкой. Проверять следует вывод CMake: архитектуру процессора, обнаруженный assembler и итоговые опции. Установка NASM в PATH либо явное указание CMAKE_ASM_NASM_COMPILER устраняет типичную причину.

Сборка cjpeg не поддерживает PNG

PNG в 4.1.5 — условная функция, зависящая от libpng. В CMake опция PNG_SUPPORTED по умолчанию включена, но библиотека libpng должна быть доступна. Если cjpeg сообщает неизвестный формат для PNG, нужно проверить CMake-отчет о PNG reading support и наличие libpng в той конфигурации, из которой запущен бинарник. Для проверки самой компрессии можно использовать BMP или PPM, которые не требуют libpng.

На Windows приложение не загружает DLL

Имя jpeg DLL зависит от выбранной ABI-эмуляции, а сама DLL зависит от C runtime компилятора. Нужно проверить архитектуру 32/64 бит, конфигурацию Release/Debug, доступность runtime и то, что приложение загружает библиотеку из ожидаемого каталога. Смешивание DLL, собранных разными поколениями Visual C++, может давать ошибки еще до первого вызова кодека.

Программа использует системную libjpeg вместо MozJPEG

На Unix-подобной системе одновременно могут существовать несколько libjpeg. Успешная компиляция еще не гарантирует, что при запуске динамический загрузчик выбрал MozJPEG. Проверять нужно link-команду, pkg-config/CMake-конфигурацию и фактически загруженную shared library. Если это невозможно контролировать, статическая линковка или изолированный контейнер могут сделать окружение предсказуемее, но при статической поставке нужно выполнить лицензионные требования.

Попытка включить проект через CMake add_subdirectory завершается ошибкой

Сборочная система libjpeg-turbo/MozJPEG 4.1.5 прямо не поддерживает включение верхнего проекта через add_subdirectory. Документация и CMakeLists.txt предлагают использовать ExternalProject_Add либо адаптировать downstream-сборку. Это не случайный сбой конкретной версии CMake, а намеренное ограничение архитектуры сборочного проекта.

Проблемы при импорте и обработке

cjpeg не распознает входной файл

cjpeg определяет формат по сигнатуре и набору включенных readers. Расширение имени само по себе не гарантирует поддержку. Нужно проверить, что это действительно JPEG, BMP, GIF, PPM/PGM, Targa либо PNG в сборке с libpng. Targa с нестандартным identification field иногда требует явного -targa. RAW, PSD, HEIC и другие форматы необходимо декодировать внешним инструментом или приложением до передачи пикселей в библиотеку.

После повторного кодирования JPEG качество стало хуже

JPEG уже содержит квантованные данные. Запуск нового lossy-кодирования создает еще одно поколение потерь. Если исходный JPEG не требует изменения качества, используйте lossless-возможности jpegtran. Если повторное кодирование неизбежно, оцените, не лучше ли вернуться к исходному PNG, TIFF или RAW-мастеру, чтобы создавать веб-JPEG только один раз.

На цветных границах появились ореолы

Частая причина — chroma subsampling, а не только значение quality. Для фотографий субдискретизация обычно эффективна, но на диаграммах, скриншотах, логотипах и цветном тексте она может быть видимой. Сравните вариант с меньшей субдискретизацией или без нее. Если исходная задача допускает другой формат, PNG, WebP или AVIF могут лучше соответствовать графике с резкими границами, но это уже выбор вне MozJPEG.

На контрастном тексте заметен ringing

MozJPEG включает overshoot-deringing, но JPEG не гарантирует отсутствие ringing при низком битрейте. Проверьте качество, таблицу квантизации и отсутствие чрезмерной повторной компрессии. Не следует автоматически отключать overshoot: сначала сравните оба варианта на конкретном типе графики, поскольку опция как раз предназначена для уменьшения заметности таких артефактов.

Проблемы при экспорте и проверке файла

Файл не появился, хотя cjpeg отработал

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

JPEG стал прогрессивным, хотя ожидался baseline

В MozJPEG прогрессивное кодирование включено стандартным профилем. Для baseline JPEG предусмотрен параметр -baseline. Если требуется поведение, близкое к обычным настройкам libjpeg, существует -revert. Это особенно важно для устаревших систем, которые предъявляют собственные ограничения к структуре JPEG, хотя современные браузеры прогрессивные JPEG поддерживают.

Слишком маленький выигрыш по размеру

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

Сжатие занимает неприемлемо много времени

Это ожидаемое поведение стандартного профиля. Для диагностики можно сравнить -revert, отключить trellis через -notrellis или оптимизацию сканов через -fastcrush и определить наиболее дорогую стадию. Если проект требует постоянного real-time кодирования, переход на libjpeg-turbo обычно рациональнее, чем последовательное отключение всех особенностей, ради которых выбран MozJPEG.

Как построить корректный тест MozJPEG в своем проекте

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

Отдельно измеряется производительность всего конвейера, а не одного запуска cjpeg: параллельная обработка увеличивает throughput, но одновременно нагружает CPU и память. Последний контроль — декодирование полученных JPEG теми браузерами, приложениями или downstream-компонентами, в которых они действительно будут использоваться.

FAQ о MozJPEG

MozJPEG уменьшает уже готовый JPEG без потери качества?

Да, для структурной оптимизации. jpegtran может применить progressive/jpegrescan-оптимизацию lossless-способом без повторной квантизации. Изменение quality через новое кодирование уже является потерным, поэтому эти два сценария нужно разделять.

Можно ли заменить libjpeg на MozJPEG в существующей программе?

Проект сохраняет libjpeg API и ABI и предназначен для такой замены. После подключения все равно нужно проверить ожидаемую ABI, динамическую линковку и отсутствие другой системной libjpeg в пути загрузчика.

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

cjpeg — демонстрационная CLI-утилита для кодировщика. Она дает доступ к низкоуровневым параметрам, но не содержит каталога фотографий, визуального сравнения, очереди, пресетов проекта и других частей готового графического продукта.

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

Нет. После сборки или установки кодирование выполняется локально. MozJPEG не является облачным API и не отправляет фотографии в сервис Mozilla.

Поддерживает ли cjpeg PNG?

PNG может быть входом, если сборка выполнена с libpng; опция PNG_SUPPORTED в CMake 4.1.5 включена по умолчанию. Выход cjpeg — JPEG. При библиотечной интеграции приложение также может самостоятельно декодировать исходный формат и передать пиксели энкодеру.

Можно ли сжимать RAW-фотографии напрямую?

Нет. MozJPEG не является RAW-конвертером. RAW сначала нужно проявить и декодировать другим компонентом, после чего пиксели передаются JPEG-энкодеру.

Какой quality выбрать для сайта?

Одного универсального числа нет. cjpeg использует 75 по умолчанию и описывает 50–95 как обычно полезный диапазон для фотографий, но результат зависит также от subsampling, таблицы квантизации и контента. Рабочий пресет выбирают на репрезентативной выборке, сравнивая размер и артефакты.

Почему GitHub может показывать Latest 4.1.1, хотя есть тег 4.1.5?

GitHub отдельно показывает Release-записи и теги. v4.1.1 имеет оформленную Release-карточку, а v4.1.5 от 12 октября 2023 года опубликован как более новый тег. Для версии исходников нужно ориентироваться на выбранный тег и его CMakeLists.txt.

Можно ли считать master версией 5.0.0?

В CMakeLists.txt master указан номер 5.0.0, но отдельного тега v5.0.0 нет. Для экспериментов допустима фиксация конкретного commit ветки разработки; для воспроизводимой поставки проще закрепить опубликованный тег или явно выбранный commit.

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

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

Для разработчика графической программы главная ценность — совместимость с libjpeg API/ABI. Если приложение уже экспортирует JPEG через libjpeg, MozJPEG можно оценивать как замену кодековой библиотеки без создания отдельного формата и без переписывания пользовательского интерфейса. Перед выпуском нужно проверить линковку, лицензии и реальную скорость.

Для ручной обработки нескольких фотографий чистый MozJPEG неудобен. cjpeg дает все необходимые технические переключатели, но не предоставляет визуального сравнения и управления коллекцией. Здесь проще Squoosh или другое приложение с UI, если его политика приватности и формат работы подходят задаче.

Для существующего архива JPEG сначала следует отделить lossless-оптимизацию от нового lossy-поколения. jpegtran позволяет оптимизировать структуру без повторной потери; повторное cjpeg-кодирование оправдано только тогда, когда сознательно меняется компромисс качества и размера.

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

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