The OpenNET Project / Index page

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

Компания Google выпустила вторую версию библиотеки с реализацией формата WebP

31.08.2012 14:55

Представлен релиз библиотеки libwebp 0.2 с реализацией функций кодирования и декодирования изображений в формате 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.

При создании формата WebP использованы технологии, задействованные в видеокодеке VP8 для сжатия ключевых кадров. Высокая плотность упаковки достигается благодаря использованию предсказательной техники кодирования, учитывающей содержимое соседних пиксельных блоков для предсказания содержимого текущего блока, что позволяет ограничиться хранением только различий между фактическими и предсказанными данными. В качестве контейнера для хранения изображений, сжатых методом WebP, используется стандартный RIFF. Код открыт под лицензией Apache 2.0, которая дополнена пунктом о безвозмездной передаче прав на использование связанных с WebP патентов Google.

  1. Главная ссылка к новости (http://googledevelopers.blogsp...)
  2. OpenNews: В новой версии WebP появилась поддержка прозрачности и кодирования без потерь
  3. OpenNews: Google начинает продвижение формата WebP в своих сервисах. Mozilla отказывается от поддержки WebP
  4. OpenNews: Для формата WebP представлен декодер на языке Java
  5. OpenNews: Разработчики кодека x264 резко критикуют формат WebP, предложенный Google
  6. OpenNews: Компания Google представила новый открытый формат изображений WebP
Лицензия: CC-BY
Тип: Программы
Ключевые слова: webp, image, png, jpeg
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (21) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 15:40, 31/08/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –9 +/
    > Таким образом, в настоящее время WebP может выступать в качестве полноценной замены форматам JPEG, GIF и PNG
    > GIF

    Конечно же, WebP поддерживает анимацию картинок?

     
     
  • 2.2, Аноним (-), 15:44, 31/08/2012 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > В обоих режимах возможно определение прозрачных областей, создание анимации, использование цветовых профилей ICC, тайлинга и метаданных XMP.
     
  • 2.3, Аноним (-), 15:47, 31/08/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    еще в прошлом году поддержку анимации и метаданных добавили.
     

  • 1.4, Аноним (-), 16:24, 31/08/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Теперь походу гугл пилит альтернативу кодеку Opus, раз не добавляют его поддержку
     
     
  • 2.5, Аноним (-), 16:32, 31/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Пусть пилят. Если их кодек будет так же хорош как WebP (судя по рекламе, в живую его не пробовал), почему нет?
     
  • 2.10, Аноним (-), 17:52, 31/08/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    vobris
     
     
  • 3.20, Аноним (-), 18:20, 02/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > vobris

    Так он и так всеми браузерами нынче поддерживается вроде. Opus просто лучше жмет на битрейтах порядка 64Кбит и на совсем низких скоростях.

     

  • 1.6, Аноним (-), 16:42, 31/08/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    > в процессе работы библиотека теперь расходует ресурсы CPU и потребляет память не хуже, чем реализации формата PNG

    Неоднозначно получилось. У меня срабатывает цепочка "потребляет не хуже" -> "потребляет лучше" -> "потребляет больше"

     
     
  • 2.13, Hety (??), 19:44, 31/08/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не только у вас срабатывает.
     
     
  • 3.17, Аноним (-), 13:11, 01/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    вас двое
     

  • 1.9, Аноним (-), 17:50, 31/08/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >алгоритм Хаффмана

    Но ведь арифметическое сжатие лучше

     
     
  • 2.11, Crazy Alex (ok), 18:17, 31/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Угу. Только патентованное и медленное.
     
     
  • 3.12, Аноним (-), 18:56, 31/08/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а что гуглу мешает выкупить патент? копейки. Зато сколько бы сделали для OpenSource.
     
     
  • 4.16, arisu (ok), 09:03, 01/09/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > а что гуглу мешает выкупить патент? копейки. Зато сколько бы сделали для
    > OpenSource.

    наверное, они просто забыли спросить у тебя совета.

     
  • 4.18, Тот_Самый_Анонимус (?), 21:28, 01/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Зато сколько бы сделали для OpenSource.

    Им плевать на OpenSource. Просто в некоторых случаях он им выгоден, и они используют его до тех пор, пока он им нужен. Становится не нужен - забивают, и мнение «сообщества» не учитывается.

     
     
  • 5.21, Аноним (-), 18:21, 02/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Просто в некоторых случаях он им выгоден,

    Как ни странно, это одна из основных причин интереса к опенсорсу. И да, глупо плевать на то что тебя поддерживает на плаву.

     
  • 3.14, Ytch (?), 20:18, 31/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    rangecoder существенно шустрее, а в степени сжатия проигрывает не сильно. Что с патентами - не в курсе.
    Хотя на http://en.wikipedia.org/wiki/Range_encoding пишут, что "range encoding appeared to clearly be free of patent encumbrances".
     
     
  • 4.15, arisu (ok), 09:03, 01/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > rangecoder существенно шустрее, а в степени сжатия проигрывает не сильно. Что с
    > патентами - не в курсе.

    его и придумывали как непатентованую замену арифметике.

     

  • 1.19, gkv311 (ok), 22:19, 01/09/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кто-нибудь пробовал lossless кодек на этой версии?
    Оно вышло из разряда "сжимаю файл 6 часов, а потом Oooops, assert!", как было с прошлой версией, из-за чего сравнение с альтернативными кодеками было попросту невозможно?
     
     
  • 2.22, Аноним (-), 18:22, 02/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Оно вышло из разряда "сжимаю файл 6 часов, а потом Oooops, assert!",

    Это что за файл оно жало 6 часов? Это точно была картинка? oO

     
     
  • 3.23, gkv311 (ok), 22:43, 02/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Оно вышло из разряда "сжимаю файл 6 часов, а потом Oooops, assert!",
    > Это что за файл оно жало 6 часов? Это точно была картинка?
    > oO

    Самые обычные фото, вот здесь человек описывал подобную проблему:
    https://extrememoderate.wordpress.com/2011/11/20/webp-lossless-first-impressio

    Пару месяцев назад я решил прикрутить webp/webpll к своему вьюверу и тоже пытался сжать пару картинок с разными параметрами. Часами я не ждал, но 20-40 минут сжатия и регулярные обломы были в порядке вещей.

    Время декодирования было также много больше того же файла, сжатого в PNG. Конечно степень сжатия в webpll была повыше, но от "убийцы" PNG (для которого большое время декодирования файлов высокого разрешения остаётся существенной проблемой) я ожидал большего.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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