The OpenNET Project / Index page

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



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

Исходное сообщение
"Разработчики кодека x264 резко критикуют формат WebP, предло..."
Отправлено User294, 07-Окт-10 03:16 
> Есть и по круче LZMA - FreeArc например.

LZMA хорош в этом плане тем что у него довольно быстрая и не слишком ресурсожоркая распаковка (LZ быстр в декомпрессии и оперативы надо по размеру словаря), так что при просмотре картинки не будет особых тормозов. А тормознутость упаковки менее критична т.к. единоразовая операция да и регулируется (ускорение - ценой потери степени сжатия ессно). А за счет больших словарей, специфичных оптимизаций и прочая - LZMA довольно неплохо жмет, как правило обставляя по степени сжатия тот же RAR например. У PAQ и PPM* всяких, извините, распаковка жрет столько же ресурсов как и упаковка (и RAM и CPU). И если аффтар полчаса давил картинку PAQом на своем серванте с ксеонами и 64 гигз оперативы - вы как, будете ее потом неделю декомпрессовать на вашем десктопчике, натужно тарахтя свопом? Или такой же сервачок докупите специально под распаковку картинок из веба? :)

> А ждать пак не надо - уже сейчас есть довольно быстрые реализации.

У PAQов есть довольно большая проблема - их декомпрессия по ресурсам как правило такая же как компрессия. См. выше. Да и LZMA с большим словарем не настолько уж и сильно от них отстает чтобы так заморачиваться. PAQи хороши если хочется мировой рекорд поставить, но для практического юзежа как-то не доставляют ни разу :P.

>  paqpf помоему.

Про оного гугл ничего такого осмысленного не нашел.

> Возмите да и проверьте а, не наводите тень на плетень - PAQ
> да же JPG прилично жмет.

А в жпегах есть некоторая *небольшая* избыточность. Ну да, сколько-то там процентов можно отвоевать, дополнительно тиснув жпег чем-то еще. Но это, простите, не в разы разница как правило, а на какие-то проценты. Что и убивает какой-то особый смысл в этом начинании. Пыжиться с еще одной стадией упаковки ради нескольких процентов - дурная затея. В принципе можно было бы на уровне формата пооптимальнее кодить наверное. А так - ну возьмите RAW да попробуйте его зажать PAQом во столько же раз во сколько без особой разницы на вид жпег может. Посмотрим как оно у вас получится. К слову, сие сильно зависит от картинки и ее природы.

> скрин из игры, и JPG с демо из дравера - 6751х3798 bmp
> 73,3МБ png 11,9МБ оригинальный JPG 2,56МБ http://s42.radikal.ru/i095/1010/45/cee690968614.jpg

Основной FAIL тут в том что это все-таки аккуратненький computer-generated image. Он не фотоподобный и PNG с ним на удивление хорошо справился. Поиграйтесь, блин, на настоящей фотографии. Взятой с реалистичной камеры. И порассуждайте как там пнг зарулит жпега, ага. Всякие там шумы матрицы и прочая очень быстро посадят эффективность zlib-а до досадных величин. Сжатие в почти 7 раз - это очень здорово. Для многих real-world фоток все куда менее прикольно. А так поздравляю - png вы в общем то для вашей картинки довольно удачно выбрали. В семь раз сжать картинку - в любом случае весьма недурно.

А я вот например помучал взятый от балды RAW c моего n900. Обычное фото открытого пейзажа с удачной экспозицией (== почти нет пересвеченных или перетемненных областей). Весил в оригинале нежатого RAW 10.6Мб (11 126 703 байта). PNG удавил сие на 9-м уровне гимпа аж до 9 025 757 байтов. После оптимизации этого пнг тулсой optipng -o7 (полный перебор, как видите я не халтурил и приложил достойные усилия к оптимизации результата) - получил PNG весом в 8 915 646 байтов. Калькулятор информирует что это сжатие вышло чуть менее чем 1.25 к 1 :). Если даже сохранить RAW как 24bpp BMP, будет картинка весом около ~14 мегов. И даже если посчитать в удобном для вас допущении что нежатый оригинал был 14 меговым 24bpp BMP - все-равно, даже в 2 раза оно не сжалось опосля полного перебора всех вариантов компрессии, фильтров и т.п.. Ничего общего с вашим семикратным сжатием, не так ли? :) Как-то не сильно то дофига сжатия. С другой стороны, жпегом оно без особых искажений видимых на глаз удавливается до ~2.5-3Mb, что как-то более оптимистично. Я даже не пыжился с разными параметрами, epic win жпега в плане размер-качетво мне и так очевиден :)

> Слабо варьируется так как выставляется качество а не степень сжатия.

Во первых, будет и достаточно заметное. Скриншоты с четкими линиями станут очень мерзко смотреться в жпеге даже с качеством 90% а то и выше. При этом у них будет большой размер. И вот тут PNG сделает жпега с отрывом. А на фотках - ровно наоборот. Фотки можно сжать JPGом без видимых глазу изъянов намного сильнее. А вот PNG на них как раз подавится, сжать в 2 раза real world фотку - уже типа достижение.

>> Скорее он дает "квадратики".
> Теоретиг хренов! Найди не сжатую картинку и подсчитай цвета и подсчитай после
> сжатия, количество цветов может вырасти на порядок.

Все правильно - жпег со своими блоками засирает картинку. И может из 2-цветной черно-белой схемы легко сделать месиво разноцветных блоков при сильном сжатии :). Поэтому периодически очень хочется расстрелять бакланов которые схемы и простые скрины окон сохраняют в жпег вместо PNG. Цвета портятся и их становится больше. Выглядит на глаз сие крайне мерзко в случае line art и т.п. а размер жпега еще и крупнее чем вышел бы PNG (line art жмется zlib'ом на ура, разумеется).

 

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



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

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