Комментарии 16
Попробуйте pngout сжать и сравните размер с вашим
Спасибо! Добавил в таблицы и pngout для сравнения.
Сравните с lossless режимом WebP2 и JPEG XL, тогда и поговорим. PNG ни о чём, только ленивый его не обойдёт. С PNG вообще сравнивать странно, он плохо подходит для сжатия фото. Иначе, для не знакомых с темой людей, всё выглядит будто вы сделали что-то многообещающее, раз PNG обошли.
В массе своей выбирается PNG не потому что он лучший для фото, а потому что почти все инструменты если и умеют во что-то сжимать без потерь, то это и есть PNG, то есть на самом деле им пользуются не потому что он жмёт хорошо, а потому что нет альтернативы. А так как PNG сжимает без потерь, то и сравнивать нужно с PNG.
с абсолютно тем же успехом можно raw/bmp просто пожать zipом, что можно сказать, внутри png и происходит. Для схем/чертежей с кучей одинаковых сгруппированых пикселей вполне работает, как и QOI впрочем, а для реальных фотографий - не особо.
Ох и отхвачу я минусов. Я проверил. WebP жмет лучше. Даже почитал как он устроен. Еще рассказал друзьям, они сказали, так вот что это за хрень, которую сохраняет гугл хром, и никто не открывает эту картинку. Если почитать историю png, они взяли доступный алгоритм без лицензий. Мне кажется за webp будущее. Если будет поддерживаться аппаратно кодек VP8 где он кодирует ключевые кадры, то во всех машинах мира, он будет лучшим. Но как я понимаю, если он до сих пор не популярен, хотя его двигает Google, значит есть какие то интеллектуальные, лицензионные проблемы. С Уважением.
ко мне часто попадают картинки HEIC и WEBP, приходится специально запускать FAR, лезть в папку и запускать скрипт который прогоняет CONVERT в JPG и только потом начинать работать с этими изображениеми. Проблема не в форматах или степенях сжатия, а в том - насколько широко эти форматы поддерживаются софтом.
Вот мало кто помнит, но еще в 2007 году никто не обменивался PDF, слали или JPG или TIFF. И только когда все утюги мира стали сканировать в PDF - формат стал практически стандартом для многостраничных сканов.
и как много программ умеет открывать на редактирование raw пожатый zipом? Или вы мне предлагаете вместо оперативной работы с изображением гонять туда-сюда файлики?
надо выписывать на С или Rust и сравнивать скорость с какой скоростью такой формат можно будет выводить, если интегрировать в браузеры или любые другие UI.
Разница в величине компрессии, пожалуй, играет роль если она в районе 30% и выше (очень субъективное суждение).
Теперь осталось взять арифметическое кодирование (которое позволяет приблизится к теоретическому n*log(n) и иметь дробное количество битов/символ, в отличии от Хаффмана, где меньше 1 бита/символ не бывает). А вместо простого дельта кодирования брать сумму/разность двух пикселей, потом сумму/разность от "суммарных" пикселей с предыдущего шага и так N раз пока не пиксели не закончатся ну или пока не надоест. В результате получится почти jpeg2000.
Да, но только какой нибудь rANS, например, или FSE. Range Encoder (арифметический кодер) медленный. Для изображений имеет смысл применить несколько заранее подготовленных линейных фильтров (4 например) и выбирать наилучший. Соответственно, индексы фильтров группировать отдельно и также кодировать FSE.
Для решения этой проблемы используют кодирование числа переменной длины
Дельта-код Элиаса не хотите попробовать?
Delta-Rle-Huffman (DRH) Texture Format