The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Разработчики кодека x264 резко критикуют формат WebP, предло..."
Отправлено User294, 03-Окт-10 22:24 
> Можно сделать PNG+PAQ сжатие

Ждать позеленеете с PAQ. Реалистичнее было бы засунуть LZMA в PNG, имхо. Но это не изменит сферу применения PNG.

> - размер будет как у jpg.

Не будет. Дело в том что у фотографии избыточность невелика, в силу того что все пикселы разные. Вы ж не белый лист бумаги фоткаете обычно?! И к тому же шумы матрицы еще есть. И все алгоритмы кодирующие идентично бит в бит устраняя тем или иным методом избыточность не очень много чего выиграют. Ну будет у вас сжатие не в 1.3 раза как у злиба с его куцым словарем, а скажем в 1.6 раза при приближении к теоретическому пределу. Вам сильно полегчает? При том что жпег жмет раз в ~5 без особых потерь для глаза и кушает зело меньше проца и оперативы чем PAQ? Алгоритмы сжатия с потерями отбрасывают довольно много информации которая однако глазу не очень то и видна. Потому и могут сжать в несколько раз. Это иной класс алгоритмов чем техники кодирования позволяющие декодировать бит в бит. Они используют особенности человеческого восприятия чтобы выбросить довольно много "лишней" информации так что человек не заметит особой разницы, а вот размер файла уменьшится в РАЗЫ.

> оптимизация хаффмана + 1:1:1 + переменное DCT + качество 95% разница между
> bmp и jpg в 14 раз.
> png сжатие 9 разница с bmp в 7 раз.

Извините, а что было на картинке? :)

Ничего что все эти соотношения очень сильно варьируются и зависят от ТОГО ЧТО НА КОНКРЕТНОЙ КАРТИНКЕ ИЗОБРАЖЕНО? В частности, для жпега четкие контрастные линии характерные для картинок типа скриншотов десктопа и прочая - большая проблема. Жпег грубо говоря пытается представить картинку как отдельные блоки, а потом огрубляет представление этих блоков. Откуда и неслабая экономия места, и характерные квадратики при пережатии, когда границы блоков перестают стыковываться нормально. Представляете себе что получается когда таким манером представляется скажем четкая граница типа кнопки на окне? Дерьмо там получается вместо четких линий, если качество чуть ниже максимального. Линии получаются размазанные и засранные, что очень видно глазу. Зато если это был не скриншот а real-world фотография - ну в природе почти не бывает однопиксельных контрастных четких линий. Поэтому фотоподобные изображения таким подходом давятся в несколько раз на ура и глядя на картинку глаз вообще не замечает подвоха. Поэтому жпег для фотографий и градиентных картинок вполне себе катит на ура. А если скриншот делать то чтобы он не выглядел как полное Г - жпегом надо чуть ли не максимальное качество фигарить и жпег при этом как правило намного больше PNG при более поганом качестве. Исключение только очень сложные скриншоты, где скажем часть фото в бэкграунде или много градиентов.

PNG по сути берет ту самую битмапу и ... просто давит ее без потерь злибой. Можете сами bmp в ZIP сжать. Тот же inflate/deflate будет поюзан, пардон. В png конечно еще фенечки типа фильтров есть но в целом идея вот такая вот - по сути этакий удобный zip для картинок :). В случае фотографии повторяющихся пикселов на ней в общем случае не густо, если не фоткать белый лист бумаги. Да еще матрица шумит, усугубляя это. Поэтому там где жпег почти гарантированно сожмет раз в пять без особой разницы на глаз - zlib может и в полтора не осилить. И *теоретический* предел lossless сжатия для такой картинки может не сильно отличаться, скажем быть в районе двух. Ну может чуть побольше с препроцессингом и злостными оптимизациями типа попыток попилить битмапу на несколько независимых потоков, предполагая что так больше совпадений наловится. Тем не менее, давить фотки "зипом" в целом занятие не очень перспективное. Вот скриншоты с большими одноцветными площадями и линиями так ессно давятся на ура - массив одноцветных пикселей ессно злибу самое что надо.


> то есть реально jpg без видимых искажений всего в 2 раза превосходит png.

Ха-ха, это соотношение очень варьируется в зависимости от того что у вас там на картинке. На однотонных скриншотах EPIC WIN будет у PNG, а на фотках - JPEG порвет PNG как тузик грелку.

> С ростом скорости актуальность jpg будет падать. Разумеется не стоит перекодировать jpg
> в png так как jpg дает серьезный шум.

Скорее он дает "квадратики". Которые сильно гадят lossless кодекам, разумеется. Поэтому даже какую-нить схему (line art вообще) сжатую в JPG просто так уже в PNG нормально не сожмешь.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
  Введите код, изображенный на картинке: КОД
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру