JPEG хорошо известен, хорошо используется и хорошо понимается. Конечно, не может быть ничего, что можно было бы выжать из этого старого алгоритма сжатия? Mozilla, похоже, считает, что мы можем получить больше, если будем осторожны.
Новый проект Mozilla под названием «mozjpeg» пытается создать лучший JPEG.
Фотографии обычно занимают много байтов для хранения, и в большинстве случаев объем необходимых данных может быть уменьшен с помощью сжатия с потерями. JPEG-самый известный метод сжатия фотографий с потерями, и он используется не только на веб-сайтах, но и в цифровых камерах и других устройствах.
Лучшее сжатие сократит время загрузки большинства веб-сайтов, поскольку изображения представляют большую часть размера веб-сайта.
Google изобрел совершенно новый алгоритм сжатия WebP, который, как утверждается, на 40% лучше, чем JPEG, без какой-либо дополнительной потери качества. Большая проблема заключается в том, что не все веб-браузеры поддерживают WebP, и, следовательно, у нас есть проблема с курицей и яйцом, когда пользователи не хотят использовать его до тех пор, пока веб-браузеры не поддержат его.
Команда Mozilla задалась вопросом, можно ли сделать лучший кодер сжатия, используя существующий алгоритм. Это не кажется очень вероятным после более чем 20 лет. Однако, проведя некоторые исследования, команда пришла к выводу, что все еще есть возможности для улучшения. Кодер все еще может быть изменен, чтобы обеспечить такое же качество с более низкими требованиями к хранению без каких-либо изменений в декодере.
Первая версия нового mozjpeg основана на существующей библиотеке libjpeg-turbo, которая использует аппаратное ускорение для ускорения кодирования.
Первое улучшение, которое было включено, действительно зависит от высокой скорости кодирования для его успешной работы, поскольку оно существенно оптимизирует сжатие, пробуя множество различных настроек. Он основан на скрипте Perl jpgcrush, который настраивает параметры прогрессивного кодирования методом проб и ошибок, чтобы получить наименьший файл. Как правило, он создает файлы, которые на 3-6% меньше для PNG в формате JPEG и на 10% меньше для выборки из 1500 JPEG, хранящихся на Викимедиа.
Интересно, что Google уже пошел по этому пути оптимизации сжатия, но в форме проекта Zopfli, который искал оптимальные настройки параметров в сжатии ZIP. Большая проблема заключается в том, что требуется время, чтобы опробовать все возможные значения. Однако сжатие выполняется только один раз (в отличие от распаковки, которая происходит снова и снова), и это не меняет время, необходимое для распаковки файла.
Уменьшение размера на 3-10% может показаться незначительным, но следующим шагом является изучение других улучшений, таких как реализация квантования шпалер. Это оптимизирует способ квантования коэффициентов DCT, используемых в JPEG, таким образом, чтобы обеспечить наименьшее соотношение искажений.
Также следует отметить, что все эти оптимизации применимы к кодеру libjpeg с открытым исходным кодом. Вполне возможно, что другие кодеры, например Adobe, уже используют такие методы, как квантование шпалеры, для создания файлов меньшего размера.
Более важным моментом является то, что увеличение размера файла на 10% может быть хорошей вещью, но пользователи, как правило, не применяют максимальное сжатие, которое им могло бы сойти с рук. Большинство из них просто сохраняют JPEG, используя любое заданное процентное сжатие — часто предыдущим пользователем. В результате часто вообще отсутствует сжатие. Даже выбор PNG v JPEG или lossy v lossless и так Далее игнорируется пользователями.
Более эффективным способом уменьшения размеров файлов на практике было бы предоставить более интеллектуальный способ установки параметров сжатия для компромисса между размером и качеством. Некоторые графические пакеты, например GIMP, действительно показывают пользователю изображение с возможностью изменения сжатия, но более интеллектуальный подход, который сделал бы эту работу для них, был бы намного лучше.