Представлен (http://googledevelopers.blogspot.com/2012/08/lossless-and-tr... релиз библиотеки libwebp 0.2 (http://code.google.com/p/webp/) с реализацией функций кодирования и декодирования изображений в формате WebP (https://developers.google.com/speed/webp/), продвигаемом компанией Google. Используемые в WebP технологии сжатия с потерями позволяют добиться сокращения размера файла на 25%-34%, по сравнению с файлами JPEG аналогичного качества, и на 26% в режиме кодирования без потерь по сравнению с максимальным уровнем сжатия PNG.
Новая версия библиотеки примечательна обеспечением поддержки прозрачности (альфа-канал) и режима сжатия без потерь. Указанные возможности были предложены для внесения в спецификацию в конце прошлого года, сейчас же в спецификацию внесён финальный вариант новых возможностей и представлена их стабильная реализация, готовая для повсеместного внедрения. Поддержка сжатия без потерь и прозрачности WebP также добавлена в последнюю бета-версию браузера Chrome. Из других улучшений в новой версии библиотеки также отмечается проведение оптимизации производительности и потребления памяти - в процессе работы библиотека теперь расходует ресурсы CPU и потребляет память не хуже, чем реализации формата PNG.
При кодировании без потери данных для обеспечения высокой степени сжатия (средняя степень сжатия 1000 случайных изображений их сети составила 45%) задействовано несколько продвинутых технологий, таких как отдельные коды энтропии для разных цветовых каналов, учет отдалённости типовых 2D-областей при формировании обратных ссылок и кэширование недавно используемых цветов. Указанные технологии сочетаются с классическими методами, такими как словарное кодирование, алгоритм Хаффмана и трансформация цветовых индексов. В реализации поддержки прозрачности в WebP удалось добиться сведения к минимуму дополнительной информации, определяющей параметры альфа-канала, что позволило существенно снизить размер итоговых изображений. При кодировании без потери качества, использование альфа-канала добавляет всего на 22% больше данных по сравнению с кодированием с потерей качества (уровень качества 90).Таким образом, в настоящее время WebP может выступать в качестве полноценной замены форматам JPEG, GIF и PNG, обеспечивая при этом более высокую степени сжатия и скорость декодирования. При распространении фотографий WebP позволяет обеспечить максмальное сжатие с незаметной для глаза потерей качества, а при необходимости сохранения изображений в неизменном виде, например, при распространении пиктограмм или скриншотов, теперь поддерживается режим с полным попиксельным сохранением целостности изображения. В обоих режимах возможно определение прозрачных областей, создание анимации, использование цветовых профилей ICC, тайлинга и метаданных XMP (http://en.wikipedia.org/wiki/Extensible_Metadata_Platform).
При создании формата WebP использованы технологии, задействованные в видеокодеке VP8 для сжатия ключевых кадров. Высокая плотность упаковки достигается благодаря использованию предсказательной техники кодирования, учитывающей содержимое соседних пиксельных блоков для предсказания содержимого текущего блока, что позволяет ограничиться хранением только различий между фактическими и предсказанными данными. В качестве контейнера для хранения изображений, сжатых методом WebP, используется стандартный RIFF (http://code.google.com/speed/webp/docs/riff_container.html). Код открыт под лицензией Apache 2.0, которая дополнена пунктом о безвозмездной передаче прав на использование связанных с WebP патентов Google.
URL: http://googledevelopers.blogspot.com/2012/08/lossless-and-tr...
Новость: http://www.opennet.ru/opennews/art.shtml?num=34709
> Таким образом, в настоящее время WebP может выступать в качестве полноценной замены форматам JPEG, GIF и PNG
> GIFКонечно же, WebP поддерживает анимацию картинок?
> В обоих режимах возможно определение прозрачных областей, создание анимации, использование цветовых профилей ICC, тайлинга и метаданных XMP.
еще в прошлом году поддержку анимации и метаданных добавили.
Теперь походу гугл пилит альтернативу кодеку Opus, раз не добавляют его поддержку
Пусть пилят. Если их кодек будет так же хорош как WebP (судя по рекламе, в живую его не пробовал), почему нет?
vobris
> vobrisТак он и так всеми браузерами нынче поддерживается вроде. Opus просто лучше жмет на битрейтах порядка 64Кбит и на совсем низких скоростях.
> в процессе работы библиотека теперь расходует ресурсы CPU и потребляет память не хуже, чем реализации формата PNGНеоднозначно получилось. У меня срабатывает цепочка "потребляет не хуже" -> "потребляет лучше" -> "потребляет больше"
Не только у вас срабатывает.
вас двое
>алгоритм ХаффманаНо ведь арифметическое сжатие лучше
Угу. Только патентованное и медленное.
а что гуглу мешает выкупить патент? копейки. Зато сколько бы сделали для OpenSource.
> а что гуглу мешает выкупить патент? копейки. Зато сколько бы сделали для
> OpenSource.наверное, они просто забыли спросить у тебя совета.
>Зато сколько бы сделали для OpenSource.Им плевать на OpenSource. Просто в некоторых случаях он им выгоден, и они используют его до тех пор, пока он им нужен. Становится не нужен - забивают, и мнение «сообщества» не учитывается.
> Просто в некоторых случаях он им выгоден,Как ни странно, это одна из основных причин интереса к опенсорсу. И да, глупо плевать на то что тебя поддерживает на плаву.
rangecoder существенно шустрее, а в степени сжатия проигрывает не сильно. Что с патентами - не в курсе.
Хотя на http://en.wikipedia.org/wiki/Range_encoding пишут, что "range encoding appeared to clearly be free of patent encumbrances".
> rangecoder существенно шустрее, а в степени сжатия проигрывает не сильно. Что с
> патентами - не в курсе.его и придумывали как непатентованую замену арифметике.
Кто-нибудь пробовал lossless кодек на этой версии?
Оно вышло из разряда "сжимаю файл 6 часов, а потом Oooops, assert!", как было с прошлой версией, из-за чего сравнение с альтернативными кодеками было попросту невозможно?
> Оно вышло из разряда "сжимаю файл 6 часов, а потом Oooops, assert!",Это что за файл оно жало 6 часов? Это точно была картинка? oO
>> Оно вышло из разряда "сжимаю файл 6 часов, а потом Oooops, assert!",
> Это что за файл оно жало 6 часов? Это точно была картинка?
> oOСамые обычные фото, вот здесь человек описывал подобную проблему:
https://extrememoderate.wordpress.com/2011/11/20/webp-lossle.../Пару месяцев назад я решил прикрутить webp/webpll к своему вьюверу и тоже пытался сжать пару картинок с разными параметрами. Часами я не ждал, но 20-40 минут сжатия и регулярные обломы были в порядке вещей.
Время декодирования было также много больше того же файла, сжатого в PNG. Конечно степень сжатия в webpll была повыше, но от "убийцы" PNG (для которого большое время декодирования файлов высокого разрешения остаётся существенной проблемой) я ожидал большего.