001

В марте 2014 года Mozilla анонсировала новый проект Mozjpeg, целью которого было улучшить сжатие изображений при сохранении совместимости с существующими декодерами. Тогда же вышла базовая версия , просто форк популярной программы libjpeg-turbo с добавлением функциональности скрипта jpgcrush.

Фактически, это была только сырая заготовка с приглашением независимым разработчикам поучаствовать в проекте. Но Mozilla не забросила инициативу и сдержала обещание, выпустив 15 июля 2014 года вторую версию Mozjpeg с треллис-квантованием.

«С сегодняшним релизом Mozjpeg 2.0 оптимизирует как последовательные, так и прогрессивные JPEG, в среднем, на 5% лучше, чем libjpeg-turbo, — пишет Mozilla. — На многих изображениях разница ещё больше».

Сравнение пяти кодеров по соотношению бит на пиксел (ось X) при одинаковом качестве изображения (ось Y), на тестовой подборке изображений из Википедии. Левее — лучше.
Сравнение пяти кодеров по соотношению бит на пиксел (ось X) при одинаковом качестве изображения (ось Y), на тестовой подборке изображений из Википедии. Левее — лучше.

О тестировании Mozjpeg на своих серверах объявил Facebook. В масштабах такой компании сокращение размера файлов на несколько процентов означает экономию в миллионы долларов. Facebook даже пожертвовал $60 000 на оплату труда разработчиков Mozjpeg, чего вполне достаточно на ближайшие месяцы работы и выпуск Mozjpeg 3.0.

Кроме треллис-квантования, во второй версии добавлена поддержка утилиты cjpeg для более простого управления процессом рекомпрессии. Добавлены опции настройки параметров PSNR, PSNR-HVS-M, SSIM и MS-SSIM.

Хотя существует несколько алгоритмов сжатия с потерями, которые эффективнее обычного JPEG (например, HEVC), но Mozilla разумно полагает, что популярность JPEG слишком велика, чтобы отказаться от его оптимизации. Переход на новый формат займёт много лет, поскольку он не совместим с имеющимся программным обеспечением. «Мы (в Mozilla) не сомневаемся, что алгоритмические улучшения когда-нибудь подтолкнут к такому переходу, возможно, скоро. Но даже в этом случае JPEG ещё долго будет с нами», — говорили они в марте, анонсируя Mozjpeg. Эти слова актуальны и сейчас.



6 комментариев

  1. 17.07.2014 at 12:30

    «при одинаковом качестве изображения (ось Y),»

    — при разном, Y же меняется.

    • 17.07.2014 at 12:54

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

    • 18.07.2014 at 13:21

      Ошибки нет.
      1. Вариант 1 — Вы смотрите одинаковое качество для кодеков, но хотите лучшего сжатия при фиксированном качестве. Выбираете точку качества на У и проводите прямую параллельную X, назовем ее Х1, тогда по Х1 в точках пересечения с кривыми кодеков у вас будет различаться колво-битпиксель. Тот, кто меньше «битпиксель» потребил — тот лучше, график этого кодека пересечет X1 левее.
      2. Вариант 2 — у нас строго задан объем информации (скажем, ограничения трафика), т.е. фиксируем точку на Х, и проводим прямую параллельно У — Y1. Высшая точка пересечения кривых кодеков с Y1 — покажет наилучшее качество при фиксированном объеме.

Оставить мнение