Comments 47
То есть они наконец воспользовались заложенной в стандарт возможностью хранить кастомную таблицу квантования, а не просто «стандарт × коэффициент»? Похвально. Я, помнится, пытался подобрать таблицы для хорошего сжатия линий (чтобы не обрастали «звоном»), в ущерб градиентам. Фигня получилась, конечно :) Но я и не Гугль :)
А ещё можно, при повторном сжатии уже некогда сжатого изображения, пытаться угадать его «тогдашнюю» таблицу квантования. Ну, и сами квантованные значения в тех местах, где не было редактирования. Это не только предотвратит «цифровой износ», но ещё и «здесь и сейчас» улучшит соотношение «качество/размер».
MozJPEG делали то же самое, подбирали оптимальную таблицу квантования.
Я очень давно пытался сделать свой "самый лучший" архиватор, который подбирал кодирование Хаффмана для каждого файла индивидуально, а не использовал бы стандартную статистическую таблицу. Он даже работал. Но никому он оказался не нужен. Дежавю.
Вы проводили сравнению с другими решениями?
И на сколько подбор кодирования замедлял архивирование?
Вы что-то путаете. Статический хаффман использовался сто лет назад и только в случае если нужно было сжать быстро - например, в драйвере прозрачного сжатия диска. Везде применяется динамический
Лет в 16-17 я тоже пытался сделать более эффективный формат GIF, чтобы и TrueColor и лучшее сжатие, более умный поиск изменений в кадрах (короче почти повторил оказавшийся никому не нужным APNG, за исключением того, что про APNG хотя бы кто-то слышал)) Но на тот момент, я еще не понимал как устроен мир и когда я закончил пару месяцев ощущал себя мини Стивом Джобсом, кем-то кто изобрел что-то новое, чего не было раньше. Какое-то время даже пытался убедить друзей использовать это и размещать в бесплатных каталогах софта. А потом пришло осознание, что ничего я не изобрел, то, что сделал я, может сделать любой хороший программист, но не делает не потому, что не может, а потому, что это никому не надо) Точнее не так, это надо всем, но ты не заставишь всех этим пользоваться, пока этим не пользуются все) А это про большие деньги, а не про то, что ты на коленке что-то слепил, чуть более эффективное, чем текущий стандарт (в основном за счет того, что стандарту дохрена лет и с тех пор появились алгоритмы получше) и кричишь "Я сделаль!".
Но здесь не та ситуация, тут есть обратная совместимость, а значит, скорее всего взлетит со временем.
Прошу заметить: судя по вашему комментарию, вы не просто "пытались" сделать формат более эффективным, чем существующие, но и в этом вполне преуспели. Вопрос лишь в том, что этот результат вряд ли кто-то увидит, кроме вас и ваших друзей.
А вот как сделать, чтобы заметили — интересный вопрос. У тех же MLщиков есть небезызвестный Kaggle, где они меряются крутостью своих моделек, минимизируя лоссы на датасете. Применительно к архиваторам, есть, например, вот такой рейтинг архиваторов по качеству сжатия ими дампа англоязычной Википедии. Рейтинг открытый и обновляется, если у вас есть архиватор, который сжимает лучше, его можно попробовать туда отправить. Для сжатия картинок я сходу аналогичной таблицы не нашёл, но, возможно, она тоже существует.
В целом, если преимущества "поделки на коленке" перед аналогами можно представить численно — это нужно сделать, и выяснить, кто всё-таки царь горы. А разработчики, которым нужна эта технология, пусть сами решают, что им важнее — стандартность или качество. Обычный tradeoff.
Там надо внимательно смотреть на цифры.
Например, WinRAR (на 76-й строке рейтинга) жмёт на 40% хуже топового nncp, но тратит в 470 раз меньше времени на сжатие/распаковку (колонка ns/byte) и почти в 60 раз меньше памяти. И тут вопрос - стоит ли оно того?
Но да, есть и приличные архиваторы которые жмут лучше условного rar - по таблице какойнить mcm со сравнимыми характеристиками времени (но опять же ценой потребления памяти), но на 28% лучше rar. И опять же вопрос - стоит ли оно того?
Вероятно зависит от применения. Если это долговременные архивы, то на архивацию/разархивацию можно потратить побольше времени, чтобы получить максимальную степень сжатия. Если это архивы для скачивания, которые используются только один раз для распаковки, а потом удаляются, то скорость приоритетней (хотя это тоже обсуждаемо).
Вы шутите? Я вообще не помню, чтобы в современных архиваторах использовались готовые статистические таблицы. Да собствено лабораторная работа в институте по кодированию Хаффмана хрен знает сколько лет назад, состояла как раз в том, чтобы проанализировать файл, создать персональную таблицу статистики и зашифровать файл с сохранением этой таблицы.
Это, конечно, хорошо, но лучше переходить на более совершенные форматы типа WebP, чем пытаться выжать максимум из легаси.
Если можно улучшить "легаси", не жертвуя совместимостью и ресурсами - почему нет? А JPEG XL по всем тестам лучше WEBP, но совместимости нет и поддерживается вяло. Как IPv6 супротив IPv4.
Надо будет мне собраться с яйцами, добить исследование и выдать на-гора статью о сжатии жпегом в 3D (то есть не квадрат 8х8, а куб 8х8х8). Там получился (не у меня первого, но у меня тоже получился, кек) неплохой видеокодек, в котором корреляция «между кадрами» не требует отдельно никакие области движений, смещений (и так далее) высчитывать — они там получаются нативно, «просто потому, что». И жмёт он — держите меня семеро.
Я это рассматривал как расширение (внезапно) стандарта GIF — новый тип кадра для анимации, в котором вместо одного кадра лежат сразу 8. Все остальные опции, типа заголовка с длительностью — оставляем стандартные анигифовские. Ну, и пара новых служебных форматов чанка потребуется — таблицы Хаффмана и квантования сами себя не загрузят.
А главную проблему, связанную с тем, что количество умножений там не квадратичное, а кубичное, я разрешил очень просто, без всяких группировок «бабочкой» и как там вообще обычно это до меня пытались делать: поскольку 95% величин квантуются в ноль (а иначе зачем бы было вообще такое сжатие, как не ради его эффективности?), я просто в 95% случаев перехожу в continue; :-)
И всё у меня в реалтайме на одном ядре сразу стало летать… ларчик просто откр оптимизировался :-D
А по патентам у JPEG что сейчас? Открыли, или по прежнему теоретически всем, кто им пользуется, могут приказать отбашлять?
Пока это легаси поддерживается всем, чем только можно, а совершенный WebP примерно ничем, то пусть пытаются.
Моя версия Фотошопа не поддерживает. И про неё не написано на caniuse.
WebP пока почти исключительно только в вебе. И это хорошо, биороботам сложнее тырить картинки методом копипасты.
Power point , word?
К остальным комментариям добавлю, что кроме вялой поддержки в софте у WEBP еще и вялая поддержка в сервисах. Залить WEBP можно не везде. На habrastorage, например, нельзя:
Доступные расширения: jpg, gif, png; ширина до 5000px; максимальный размер до 8 Мбайт
Таких сайтов все еще большинство. WEBP хорош отдавать статику на сайтах. Для личного использования он неудобен, посему у меня стоит "Don't "Accept" image/webp" :)
Два месяца назад купил пару новых МФУ, Epson и Canon, сканируют только в то, во что сканировали все 15 лет назад, а печатают только JPG из своего софта.
Он далеко не совершенный. По всем параметрам и списку возможностей проигрывает JPEG XL, который Google упрямо не хочет реализовывать в Chrome.
Знаете, если я на каком то сайте не напрягаясь вижу артефакты JPEG, то почти в 100% случаях это означает, что на картинка в формате WEBP.
Так что либо это формат используют неверно, либо не такой уж он и хороший.
Прошлый раз гугл пытался улучшить deflate сжатие при помощи zopfli, получилось немного улучшить ценой огромных затрат cpu, в итоге brotli победил, а потом пришел zstd и ещё раз победил, причем zstd уже в канареечном хроме завезли и скоро его можно будет в интернете использовать
причем zstd уже в канареечном хроме завезли и скоро его можно будет в интернете использовать
Ну то есть пользователей Safari и Firefox можно не учитывать, вы считаете?
У них отработает brotli или gzip
Алгоритмы сжатия опциональны. То есть браузер передает серверу список поддерживаемых алгоритмов а сервер, просмотрев этот список, может использовать один из этих алгоритмов и отдать браузеру сжатый контент вместе с заголовком, который указывает на использованный алгоритм. Таким образом если на стороне сервера какой-то новый модный алгоритм уже применяется а на стороне браузера еще нет, то ничего не сломается.
zopfli
brotli
jpegli
Цюрихский офис гугла пошёл вразнос
в итоге brotli победил, а потом пришел zstd и ещё раз победил
А есть тесты сравнительные про победу? Я не смог у себя (.net framework) сделать zstd одновременно быстрее и лучше чем brotli (и то и другое из коробки). По-видимому zstd надо сначала обучить, чего мне делать совсем не хотелось.
линия zstd выше и шире чем бротли. Мы применяем уже много где zstd в серверах (и сжатие в клике и сжатие логов), и по нашим сравнениям zstd нормально так выигрывает бротли, но мы сравнивали только нативные реализации, что в .net происходит с этим я не знаю. Может ещё конечно от данных зависеть, но чёрт его знает, пока везде я видел победу zstd.
https://news.ycombinator.com/item?id=27163981
Я примерно аналогичное видел. Сейчас ситуация, возможно, изменилась. Но по факту получалось, что либо маленькие данные на бротли, либо большие (но там уже надо фигачить какой-нибудь бинарный протокол вместо джысона) на zstd с его многопоточным кодированием. Хотя многопоточное кодирование тоже палка о СPUcount концах - при массовой нагрузке на сервер ничего никто не выиграет от него.
Попытался найти хоть какие-то примеры, скачал mucped23.zip, там зачем-то png файлы лежат вместо jpeg. И нет нигде размеров того что получилось (цифры q55 и q95 ничего не значат, размер может любой). Как-то всё очень мутно пока. Если все так круто, то почему нет примеров?
Если что, способ существенно сократить размер jpeg без потери обратной совместимости действительно есть, работает только для retina-изображений.
Помнится в свое время Мелкий Софт тоже предлагал улучшенное сжатие картинок, но там бвл новый формат.Даже этому гиганту не удалось подвинуть популярный формат. Здесь же вроде все на мази...
Улучшение на 35%, говорите? Надеюсь, это не снизит качество моих селфи до уровня пиксель-арта. Но если благодаря этому страницы будут загружаться быстрее, то я готов принять этот вызов. Быстрый интернет превыше всего, даже если ради этого придется увидеть себя немного... 'оптимизированным'!"
Google пытается оптимизировать формат JPEG, увеличив компрессию на 35%. Что это за технология?