Формат изображений JPEG появился ещё в конце прошлого века, причём актуальность он не теряет, а, наоборот, набирает. Казалось бы, что можно изменить в технологии, которой столько лет? В Google посчитали, что сейчас самое время для оптимизации формата, а именно повышения эффективности компрессии. Что предложили в Google и как работает новая технология?
JPEG и разработка корпорации
В Google предложили новую библиотеку для кодирования изображений в формате JPEG, о чём компания и сообщила в своём блоге. Называется новинка Jpegli, и, по словам её создателей, она обеспечивает до 35% более высокую степень сжатия относительно традиционных кодеков. При этом качество изображений будет хорошим, плюс сохраняется обратная совместимость с технологиями, которые использовались ранее.
По мнению корпорации, если файлы JPEG облегчить, то это даст лишь плюсы — как пользователям, так и компаниям. Что касается первых, то они получат более быструю загрузку веб-страниц, насыщенных графикой. Ну а вторые смогут оптимальнее использовать объём файловых хранилищ, также, возможно, снизится объём передаваемых по сети данных. Конечно, это будет возможно лишь при условии массового применения библиотеки.
Стоит напомнить, что у JPEG несколько преимуществ, которые и дали возможность формату существовать и быть актуальным много лет подряд. Дело в том, что при сжатии файла можно управлять уровнем качества, что даёт возможность гибко реагировать на решение разных задач. Кроме того, JPEG поддерживает и технологию EXIF, позволяющую хранить важные метаданные. Ну а совместимы с этим форматом практически все графические редакторы — как известные, так и пет-проекты с единицами пользователей.
Новый проект Google, по словам авторов, даёт возможность снизить шумы и в целом улучшить качество изображения. Одна из задействованных технологий — эвристика квантования, которая применяется JPEG XL. А ещё применялись оптимизированные алгоритмы выбора матриц квантования и вычисления промежуточных результатов. Также авторы библиотеки добавили более совершенные цветовые пространства.
Работа с Jpegli не создаёт никаких проблем, поскольку изображения, отредактированные или созданные с использованием этой библиотеки, совместимы с любыми технологиями, с которыми имеет совместимость и формат JPEG. Соответственно, такие «картинки» можно отображать на веб-страницах, работать с ними в графических редакторах, просматривать в любых других программах.
Что ещё?
По словам представителей Google, с библиотекой поставляются как кодер, так и декодер. Они соответствуют всем стандартам JPEG, а также обратно совместимы с libjpeg-turbo и MozJPEG.
libjpeg-turbo — высокопроизводительная библиотека для кодирования и декодирования изображений в формате JPEG. Libjpeg-turbo представляет собой совместимый на уровне API/ABI форк классической библиотеки libjpeg, нацеленный на обеспечение максимальной скорости обработки изображений.
MozJPEG — проект Mozilla, стартовавший в 2014 году. Его цель — создание качественного кодера JPEG, который улучшит сжатие изображений при сохранении совместимости с существующими декодерами.
По мнению Google, новая библиотека даёт возможность получать более качественные изображения на выходе после сжатия по сравнению с подавляющим большинством существующих решений. Результат выглядит более чётким и визуально: на картинке сложно обнаружить видимые проблемы. Всё это возможно благодаря задействованию целого комплекса современных технологий.
Кроме качества, ещё одно достоинство библиотеки — более быстрое выполнение операций кодирования и декодирования. По этому параметру новое решение идёт вровень или обгоняет существующие технологии. Соответственно, веб-разработчики могут без проблем интегрировать Jpegli в свои существующие рабочие процессы, не жертвуя производительностью кодирования или использованием памяти.
Jpegli может быть закодирован с использованием более 10 бит на компонент. Традиционные решения для кодирования JPEG предлагают только 8-битную кодировку на компонент, что приводит к видимым артефактам полос в медленных градиентах. 10-битное кодирование и кодирование с большей битностью в Jpegli происходит в исходном 8-битном формализме, и полученные изображения полностью совместимы с 8-битными программами просмотра. 10-битная динамика доступна в виде расширения API, и для её использования необходимо внести изменения в код приложения.
Немного тестов
Для того чтобы не быть голословными, разработчики из Google провели несколько тестов. Так, они упаковали в JPEG-файлы датасет изображений компании Cloudinary с использованием Jpegli, libjpeg-turbo и MozJPEG. При этом изображения представлены несколькими копиями с разным битрейтом.
Группу пользователей (не из Google, их привлекли при помощи различных сервисов) просили сравнивать пары изображений, полученные посредством работы с разными кодеками (Jpegli, libjpeg-turbo и MozJPEG), с тем чтобы выбирать самые качественные.
На диаграмме выше показаны результаты тестирования. Для их выведения применялся метод Эло.
Библиотека jpegli написана на языке C++ и распространяется под лицензией BSD, обеспечивая свободное использование и модификацию кода. Она полностью совместима на уровне API и ABI с libjpeg62. Вот ссылка на саму библиотеку.
Комментарии (45)
KvanTTT
08.04.2024 15:04Это, конечно, хорошо, но лучше переходить на более совершенные форматы типа WebP, чем пытаться выжать максимум из легаси.
wmlab
08.04.2024 15:04+14Если можно улучшить "легаси", не жертвуя совместимостью и ресурсами - почему нет? А JPEG XL по всем тестам лучше WEBP, но совместимости нет и поддерживается вяло. Как IPv6 супротив IPv4.
NickDoom
08.04.2024 15:04+29Надо будет мне собраться с яйцами, добить исследование и выдать на-гора статью о сжатии жпегом в 3D (то есть не квадрат 8х8, а куб 8х8х8). Там получился (не у меня первого, но у меня тоже получился, кек) неплохой видеокодек, в котором корреляция «между кадрами» не требует отдельно никакие области движений, смещений (и так далее) высчитывать — они там получаются нативно, «просто потому, что». И жмёт он — держите меня семеро.
Я это рассматривал как расширение (внезапно) стандарта GIF — новый тип кадра для анимации, в котором вместо одного кадра лежат сразу 8. Все остальные опции, типа заголовка с длительностью — оставляем стандартные анигифовские. Ну, и пара новых служебных форматов чанка потребуется — таблицы Хаффмана и квантования сами себя не загрузят.
А главную проблему, связанную с тем, что количество умножений там не квадратичное, а кубичное, я разрешил очень просто, без всяких группировок «бабочкой» и как там вообще обычно это до меня пытались делать: поскольку 95% величин квантуются в ноль (а иначе зачем бы было вообще такое сжатие, как не ради его эффективности?), я просто в 95% случаев перехожу в continue; :-)
И всё у меня в реалтайме на одном ядре сразу стало летать… ларчик просто
откроптимизировался :-D
ZirakZigil
08.04.2024 15:04+4Такое мы ждём. А какие-нибудь предварительные результаты где-нибудь есть? Хотя бы на уровне пары картинок и словестного описания "жалось за столько-то времени, сжалось во столько-то раз."
MountainGoat
08.04.2024 15:04+1А по патентам у JPEG что сейчас? Открыли, или по прежнему теоретически всем, кто им пользуется, могут приказать отбашлять?
ExternalWayfarer
08.04.2024 15:04+3Пока это легаси поддерживается всем, чем только можно, а совершенный WebP примерно ничем, то пусть пытаются.
pae174
08.04.2024 15:04+5
ImagineTables
08.04.2024 15:04+1Моя версия Фотошопа не поддерживает. И про неё не написано на caniuse.
nidalee
08.04.2024 15:04+1К остальным комментариям добавлю, что кроме вялой поддержки в софте у WEBP еще и вялая поддержка в сервисах. Залить WEBP можно не везде. На habrastorage, например, нельзя:
Доступные расширения: jpg, gif, png; ширина до 5000px; максимальный размер до 8 Мбайт
Таких сайтов все еще большинство. WEBP хорош отдавать статику на сайтах. Для личного использования он неудобен, посему у меня стоит "Don't "Accept" image/webp" :)
Zara6502
08.04.2024 15:04Два месяца назад купил пару новых МФУ, Epson и Canon, сканируют только в то, во что сканировали все 15 лет назад, а печатают только JPG из своего софта.
masai
08.04.2024 15:04+4Он далеко не совершенный. По всем параметрам и списку возможностей проигрывает JPEG XL, который Google упрямо не хочет реализовывать в Chrome.
moscowman
08.04.2024 15:04Знаете, если я на каком то сайте не напрягаясь вижу артефакты JPEG, то почти в 100% случаях это означает, что на картинка в формате WEBP.
Так что либо это формат используют неверно, либо не такой уж он и хороший.
Aquahawk
08.04.2024 15:04+2Прошлый раз гугл пытался улучшить deflate сжатие при помощи zopfli, получилось немного улучшить ценой огромных затрат cpu, в итоге brotli победил, а потом пришел zstd и ещё раз победил, причем zstd уже в канареечном хроме завезли и скоро его можно будет в интернете использовать
pae174
08.04.2024 15:04причем zstd уже в канареечном хроме завезли и скоро его можно будет в интернете использовать
A4E
08.04.2024 15:04+1Ну то есть пользователей Safari и Firefox можно не учитывать, вы считаете?
pae174
08.04.2024 15:04Алгоритмы сжатия опциональны. То есть браузер передает серверу список поддерживаемых алгоритмов а сервер, просмотрев этот список, может использовать один из этих алгоритмов и отдать браузеру сжатый контент вместе с заголовком, который указывает на использованный алгоритм. Таким образом если на стороне сервера какой-то новый модный алгоритм уже применяется а на стороне браузера еще нет, то ничего не сломается.
ornic
08.04.2024 15:04в итоге brotli победил, а потом пришел zstd и ещё раз победил
А есть тесты сравнительные про победу? Я не смог у себя (.net framework) сделать zstd одновременно быстрее и лучше чем brotli (и то и другое из коробки). По-видимому zstd надо сначала обучить, чего мне делать совсем не хотелось.
Aquahawk
08.04.2024 15:04линия zstd выше и шире чем бротли. Мы применяем уже много где zstd в серверах (и сжатие в клике и сжатие логов), и по нашим сравнениям zstd нормально так выигрывает бротли, но мы сравнивали только нативные реализации, что в .net происходит с этим я не знаю. Может ещё конечно от данных зависеть, но чёрт его знает, пока везде я видел победу zstd.
ornic
08.04.2024 15:04https://news.ycombinator.com/item?id=27163981
Я примерно аналогичное видел. Сейчас ситуация, возможно, изменилась. Но по факту получалось, что либо маленькие данные на бротли, либо большие (но там уже надо фигачить какой-нибудь бинарный протокол вместо джысона) на zstd с его многопоточным кодированием. Хотя многопоточное кодирование тоже палка о СPUcount концах - при массовой нагрузке на сервер ничего никто не выиграет от него.
homm
08.04.2024 15:04Попытался найти хоть какие-то примеры, скачал mucped23.zip, там зачем-то png файлы лежат вместо jpeg. И нет нигде размеров того что получилось (цифры q55 и q95 ничего не значат, размер может любой). Как-то всё очень мутно пока. Если все так круто, то почему нет примеров?
homm
08.04.2024 15:04Если что, способ существенно сократить размер jpeg без потери обратной совместимости действительно есть, работает только для retina-изображений.
novoku
08.04.2024 15:04Помнится в свое время Мелкий Софт тоже предлагал улучшенное сжатие картинок, но там бвл новый формат.Даже этому гиганту не удалось подвинуть популярный формат. Здесь же вроде все на мази...
NickDoom
То есть они наконец воспользовались заложенной в стандарт возможностью хранить кастомную таблицу квантования, а не просто «стандарт × коэффициент»? Похвально. Я, помнится, пытался подобрать таблицы для хорошего сжатия линий (чтобы не обрастали «звоном»), в ущерб градиентам. Фигня получилась, конечно :) Но я и не Гугль :)
А ещё можно, при повторном сжатии уже некогда сжатого изображения, пытаться угадать его «тогдашнюю» таблицу квантования. Ну, и сами квантованные значения в тех местах, где не было редактирования. Это не только предотвратит «цифровой износ», но ещё и «здесь и сейчас» улучшит соотношение «качество/размер».
jpegqs
MozJPEG делали то же самое, подбирали оптимальную таблицу квантования.
wmlab
Я очень давно пытался сделать свой "самый лучший" архиватор, который подбирал кодирование Хаффмана для каждого файла индивидуально, а не использовал бы стандартную статистическую таблицу. Он даже работал. Но никому он оказался не нужен. Дежавю.
Porohovnik
Вы проводили сравнению с другими решениями?
И на сколько подбор кодирования замедлял архивирование?
ef_end_y
Вы что-то путаете. Статический хаффман использовался сто лет назад и только в случае если нужно было сжать быстро - например, в драйвере прозрачного сжатия диска. Везде применяется динамический
wmlab
Это было в начале девяностых. DOS, зоопарк архиваторов (помню ARJ). Я только прочитал про Хаффмана и LZW, и написал свою реализацию двухпроходного сжатия на плюсах. Уже и забыл про это. Вспомнил потому, что упомянули динамическое квантование в JPEG.
CodeName33
Лет в 16-17 я тоже пытался сделать более эффективный формат GIF, чтобы и TrueColor и лучшее сжатие, более умный поиск изменений в кадрах (короче почти повторил оказавшийся никому не нужным APNG, за исключением того, что про APNG хотя бы кто-то слышал)) Но на тот момент, я еще не понимал как устроен мир и когда я закончил пару месяцев ощущал себя мини Стивом Джобсом, кем-то кто изобрел что-то новое, чего не было раньше. Какое-то время даже пытался убедить друзей использовать это и размещать в бесплатных каталогах софта. А потом пришло осознание, что ничего я не изобрел, то, что сделал я, может сделать любой хороший программист, но не делает не потому, что не может, а потому, что это никому не надо) Точнее не так, это надо всем, но ты не заставишь всех этим пользоваться, пока этим не пользуются все) А это про большие деньги, а не про то, что ты на коленке что-то слепил, чуть более эффективное, чем текущий стандарт (в основном за счет того, что стандарту дохрена лет и с тех пор появились алгоритмы получше) и кричишь "Я сделаль!".
Но здесь не та ситуация, тут есть обратная совместимость, а значит, скорее всего взлетит со временем.
sleirsgoevy
Прошу заметить: судя по вашему комментарию, вы не просто "пытались" сделать формат более эффективным, чем существующие, но и в этом вполне преуспели. Вопрос лишь в том, что этот результат вряд ли кто-то увидит, кроме вас и ваших друзей.
А вот как сделать, чтобы заметили — интересный вопрос. У тех же MLщиков есть небезызвестный Kaggle, где они меряются крутостью своих моделек, минимизируя лоссы на датасете. Применительно к архиваторам, есть, например, вот такой рейтинг архиваторов по качеству сжатия ими дампа англоязычной Википедии. Рейтинг открытый и обновляется, если у вас есть архиватор, который сжимает лучше, его можно попробовать туда отправить. Для сжатия картинок я сходу аналогичной таблицы не нашёл, но, возможно, она тоже существует.
В целом, если преимущества "поделки на коленке" перед аналогами можно представить численно — это нужно сделать, и выяснить, кто всё-таки царь горы. А разработчики, которым нужна эта технология, пусть сами решают, что им важнее — стандартность или качество. Обычный tradeoff.
DBalashov
Там надо внимательно смотреть на цифры.
Например, WinRAR (на 76-й строке рейтинга) жмёт на 40% хуже топового nncp, но тратит в 470 раз меньше времени на сжатие/распаковку (колонка ns/byte) и почти в 60 раз меньше памяти. И тут вопрос - стоит ли оно того?
Но да, есть и приличные архиваторы которые жмут лучше условного rar - по таблице какойнить mcm со сравнимыми характеристиками времени (но опять же ценой потребления памяти), но на 28% лучше rar. И опять же вопрос - стоит ли оно того?
KvanTTT
Вероятно зависит от применения. Если это долговременные архивы, то на архивацию/разархивацию можно потратить побольше времени, чтобы получить максимальную степень сжатия. Если это архивы для скачивания, которые используются только один раз для распаковки, а потом удаляются, то скорость приоритетней (хотя это тоже обсуждаемо).
UncleSam27
Вы шутите? Я вообще не помню, чтобы в современных архиваторах использовались готовые статистические таблицы. Да собствено лабораторная работа в институте по кодированию Хаффмана хрен знает сколько лет назад, состояла как раз в том, чтобы проанализировать файл, создать персональную таблицу статистики и зашифровать файл с сохранением этой таблицы.
ef_end_y
Это тоже не очень вариант, средняя температура по больнице. Динамический алгоритм позволяет на ходу менять дерево