The OpenNET Project / Index page

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

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

01.10.2010 07:20

Компания Google открыла наработки проекта WebP, в рамках которого подготовлен новый формат для хранения изображений. При создании формата WebP использованы технологии, задействованные в видеокодеке VP8 для сжатия ключевых кадров. Отличительной чертой нового формата является значительная степень сжатия без заметной на глаз потери качества. Тестовая перепаковка миллиона случайных JPEG-изображений из web, продемонстрировала сокращение общего размера на 39%. С учетом того, что по оценке Google 65% web-трафика расходуется на передачу изображений, это существенное достижение.

Дополнительно повысить степень сжатия можно при упаковке методом WebP не сжатых ранее изображений, также доступна возможность выбора режима экстремального сжатия в ущерб качеству. Алгоритм лучше сжимает визуально насыщенные изображения, такие как фотографии. Высокая плотность упаковки достигается благодаря использованию предсказательной техники кодирования, учитывающей содержимое соседних пиксельных блоков для предсказания содержимого текущего блока, что позволяет ограничиться хранением только различий между фактическими и предсказанными данными. В качестве контейнера для хранения изображений, сжатых методом WebP, используется стандартный RIFF.

Для загрузки доступны исходные тексты легковесного декодера WebP-файлов (библиотека libvpx), утилита webpconv для преобразования изображений из командной строки и патч к web-движку WebKit для обеспечения поддержки нового формата в браузере Google Chrome. Код открыт под лицензией, основанной на Apache 2.0 и дополнительно указывающей на безвозмездную передачу прав на использование патентов Google, связанных с данной технологией.

Дополнение 1: разработчики проекта x264 опубликовали анализ эффективности нового формата изображений, подчеркнув, что не все так гладко и радужно, как описано в анонсе Google. Например, в WebP не реализованы некоторые расширенные возможности формата JPEG: отсутствует поддержка альфа-канала (прозрачность в WebP планируется реализовать в одном из обновлений) и режима работы без потери качества (lossless). WebP поддерживает только субдискретизацию насыщенности 4:2:0, в то время как JPEG может обрабатывать 4:2:2 и 4:4:4. По степени сжатия, выигрыш WebP ощущается не всегда, например, при упаковке фотографии леса, насыщенной мелкими деталями, при кодировании WebP появилась заметная на глаз размытость (оригинал, webp, jpeg).

Тем не менее, основные недостатки WebP устранимы и главным образом связаны с незаконченностью и недостаточной отточенностью кода кодировщика, который в настоящий момент написан в соответствии с принципом "лишь бы работало" и не поддерживает психовизуальную оптимизацию, манипулируя лишь пиковым отношением сигнала к шуму (PSNR). Google следовало бы вначале создать качественный кодировщик, а потом продвигать новый формат в роли альтернативы существующим решениям. Другой проблемой WebP является абстрактный подход к организации хранения мета-данных, который приведет к неразберихе при необходимости хранения большого числа мета-тэгов.

Дополнение 2: доступен полный перевод заметки с критикой WebP.

  1. Главная ссылка к новости (http://googlecode.blogspot.com...)
Лицензия: CC-BY
Тип: Интересно / К сведению
Ключевые слова: web, image, webp
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (73) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.3, Vitto74 (ok), 08:55, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Высокая плотность упаковки достигается благодаря использованию
    >предсказательной техники кодирования

    Они дописали telepathy.h !!!!!!!!

     
     
  • 2.19, Карбофос (ok), 11:32, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +8 +/
    казалось бы, при чём здесь хедерфайл?
     
  • 2.55, User294 (ok), 20:13, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Нокия уже давно засунула Telepathy в свои устройства :) а вы только сейчас проснулись...
     

  • 1.4, Аноним (-), 09:09, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Ну и замечательно. Давно уже в мяслях было это. Ведь плотность сжатия кадров в видео(не берем в учет старые форматы) очень высокая (не учитывая конечно движения векторов, только новый кадр) по сравнению с древним jpeg. Будет новый хороший формат для сжатия картинки с потерями, и конечно же открытый формат.
     
     
  • 2.7, rm_ (ok), 09:29, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ну и замечательно. Давно уже в мяслях было это. Ведь плотность сжатия
    > кадров в видео(не берем в учет старые форматы) очень высокая (не
    > учитывая конечно движения векторов, только новый кадр) по сравнению с древним
    > jpeg. Будет новый хороший формат для сжатия картинки с потерями, и
    > конечно же открытый формат.

    Вообще-то сжатие видео и сжатие одиночных картинок - весьма разные задачи. В видео такая плотность сжатия достигается благодаря тому, что используется очень много информации из предыдущего кадра, и каждый следующий, за исключением "ключевых кадров", может передавать только изменения.
    WebP сделали из кодека для видео, и в связи с этим очень любопытен вопрос, а будет ли он уметь анимацию, или в 21-м веке люди и дальше будут продолжать использовать анимированный GIF.

     
     
  • 3.9, Аноним (-), 09:53, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Там ясно написано:
    > не учитывая конечно движения векторов, только новый кадр

    соответственно имелось ввиду keyframe.
    Про анимацию отдельная тема - в целом её вырубаю в браузере чтоб глаза не мозолила, про флеш лучше промолчу. Кстати тоже интересно - анимация на основе видео кодека - зачем gif? =)

     
  • 3.12, Аноним (-), 10:18, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для анимации есть apng, но не все его признают.
     
     
  • 4.13, rm_ (ok), 10:24, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Для анимации есть apng, но не все его признают.

    APNG/MNG не взлетели, и "не все" можно заменить на "никто".
    И если формат не поддерживается ни в одном браузере, он вовсё даже не "есть".
    С промо от гугла (имеющего в том числе собственный популярный браузер), у WebP есть гораздо большие шансы пойти в народ.

     
     
  • 5.57, User294 (ok), 20:17, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > С промо от гугла (имеющего в том числе собственный популярный браузер), у
    > WebP есть гораздо большие шансы пойти в народ.

    Ну, APNG сделала мозилла. У нее тоже свой популярный браузер есть, если что.


     
  • 4.14, gkv311 (ok), 10:40, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    APNG как минимум имеет один существенный изъян для интернета - он ужасно толстый (из-за того что используется сжатие БЕЗ потерь).
     
     
  • 5.22, upyx (ok), 12:07, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Сжатие без потерь - изъян? :) Хорошая шутка.

    Картинка картинке рознь. Бывают фотографии, а бывают скриншоты, последние лучше жмутся png, а при малом количестве цветов - gif. jpeg, при одинаковом размере с png, на скриншоты добавляет видимые артефакты. Но в целом jpeg сжимает сильнее. Хотя лучше всего скриншоты сжимает 7zip =)

     
     
  • 6.25, gkv311 (ok), 12:45, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Сжатие без потерь - изъян? :) Хорошая шутка.

    Для интернета - очень даже.

    > Картинка картинке рознь. Бывают фотографии, а бывают скриншоты, последние лучше жмутся
    > png, а при малом количестве цветов - gif. jpeg, при одинаковом
    > размере с png, на скриншоты добавляет видимые артефакты. Но в целом
    > jpeg сжимает сильнее. Хотя лучше всего скриншоты сжимает 7zip =)

    APNG сжимает каждый кадр независимо (по всей видимости), если размер неанимированной насыщенной картинки (не псевдографики) ещё можно на сайт выложить в качестве элементов интерфейса, то примитивная анимация этих элементов весит неприлично много (при размерах картинки больше 64x64).

     
     
  • 7.62, Ананимуз (?), 17:00, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >APNG сжимает каждый кадр независимо (по всей видимости)

    И что должно помешать APNG кодировать только разницу между кадрами? От него отломали  прозрачность?

     
  • 6.75, User294 (ok), 00:34, 11/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Сжатие без потерь - изъян? :)

    А попробуйте отгружать страничку, хотя-бы статичную, несколько тыщам юзеров одновременно. Вскоре вы обнаружите что готовы удавиться за каждый килобайт, чтобы не покупать дополнительные весьма дорогие сервера на ровном месте :)))

     
     
  • 7.78, upyx (ok), 07:01, 11/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Да кто спорит? Чем меньше файл, тем лучше. Но сжатие с потерями - не фича :) Это побочный эффект, от сжатия "как можно сильнее". И потому сжатие без потерь - не изъян :) А вот относительно низкая степень сжатия - это плохо. Вы же, если покупаете сушилку для посуды, не называете изъяном то, что она металлическая, а не из дешевого китайского пластика? :) Нет? Ну так она же металлическая и потому дороже! Изъян! :D
     
  • 5.44, аноним (?), 16:57, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Как можно такой бред писать? apng - альтернатива animated gif, сжимает намного лучше, и идеально подходит для малоцветной анимации, пиксельарта, рендеренного cellshading и т.д. Для "гладкого" видео его разумеется никто не будет использовать.
     
     
  • 6.50, gkv311 (ok), 17:41, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Как можно такой бред писать? apng - альтернатива animated gif, сжимает намного
    > лучше, и идеально подходит для малоцветной анимации, пиксельарта, рендеренного cellshading
    > и т.д. Для "гладкого" видео его разумеется никто не будет использовать.

    Это ВЫ говорите пургу, или хотите в неё верить. Использовать APNG вместо анимированного GIF'a? Туфта.

    > и идеально подходит для малоцветной анимации, пиксельарта, рендеренного cellshading

    То что можно сгенерировать, надо генерировать, на то есть и SVG и javascript. А толкать это в анимированный PNG имеет мало смысла. Ну разве если использовать индексированный цвет.

     
     
  • 7.58, maxst (?), 23:30, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Использовать APNG вместо анимированного GIF'a? Туфта.

    Ну почему же туфта. Вот хороший пример:

    http://animatedpng.com/index.php/samples/8bit-gif-vs-8bit-apng/

     
  • 7.76, User294 (ok), 00:39, 11/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Это ВЫ говорите пургу, или хотите в неё верить. Использовать APNG вместо
    > анимированного GIF'a? Туфта.

    Все он правильно говорит. Zlib жмет лучше ископаемого LZW, но как и LZW предпочтет большие одноцветные массивы. То есть то что пипл и перечислил.

    >> и идеально подходит для малоцветной анимации, пиксельарта, рендеренного cellshading
    > То что можно сгенерировать, надо генерировать, на то есть и SVG и javascript.

    Да, конечно, давайте превратим браузер юзера в render farm. Нехай юзеры sintel какойнить сами себе рендерят, нефиг качать уже отрендереное. Лучше мы им сцены загрузим, а дальше они будут их рендерить. Подумаешь, какие-то три часа на мощной машине. :)

    > А толкать это в анимированный PNG имеет мало смысла. Ну разве если использовать индексированный цвет.

    Можно и 24bpp, если осторожно :)


     
  • 3.48, Lepricon (?), 17:23, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Не обязательно GIF, есть еще APNG, который предлагает передачу изображения без потери качества.
     
     
  • 4.49, rm_ (ok), 17:38, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Не обязательно GIF, есть еще APNG, который предлагает передачу изображения без потери
    > качества.

    "Есть". You keep using that word. I do not think it means what you guys think it means.
    НИ В ОДНОМ распространённом браузере на сегодня нету поддержки вашего замечательного APNG. Это "есть"?

    А ВебПэ будет абсолютно точно в двух (десктопный Хром, и браузер сотен тыщ мульёнов наладонников и телефонов на Андроиде), и вероятнее всего ещё Мозилла подтянется. Это как минимум.

     
     
  • 5.51, gkv311 (ok), 17:42, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Не обязательно GIF, есть еще APNG, который предлагает передачу изображения без потери
    >> качества.
    > "Есть". You keep using that word. I do not think it means
    > what you guys think it means.
    > НИ В ОДНОМ распространённом браузере на сегодня нету поддержки вашего замечательного APNG.
    > Это "есть"?
    > А ВебПэ будет абсолютно точно в двух (десктопный Хром, и браузер сотен
    > тыщ мульёнов наладонников и телефонов на Андроиде), и вероятнее всего ещё
    > Мозилла подтянется. Это как минимум.

    APNG есть в Firefox, и уже значительное время. Есть даже расширение, позволяющее такие картинки создавать.

     
     
  • 6.52, rm_ (ok), 18:01, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > APNG есть в Firefox, и уже значительное время. Есть даже расширение, позволяющее
    > такие картинки создавать.

    Оукей, значит перепутал, это не APNG, а MNG оттуда выпилили.
    Тем не менее в виндовом файрфоксе анимашки с http://animatedpng.com/index.php/category/samples/ играют, а в дебиановском - нет. Подозреваю, что здесь он пользуется системной libpng, а там поддержки APNG нет.

     
     
  • 7.53, KOL (ok), 19:19, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    FreeBSD - Opera, Firefox работают. Но по весу действительно перебор.
     
  • 7.63, User294 (ok), 04:01, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Оукей, значит перепутал, это не APNG, а MNG оттуда выпилили.

    Именно так. MNG весьма навернутый формат который был зачем-то изрядно загеморроен. Мозиллой он до некоторого момента поддерживался. Но вы видели как эта "поддержка" работала на практике? Я вот видел. При попытке посмотреть MNG анимацию браузер крешился с вероятностью под 50%! Видали мы такую "поддержку формата" ака "remote DoS attack" знаете где? :)

    > Тем не менее в виндовом файрфоксе анимашки с http://animatedpng.com/index.php/category/samples/
    > играют, а в дебиановском - нет.

    У дебианщиков как обычно - "все на благо юзера", только очень уж по своему. И древние версии файрфокса, и его переименование, и что там еще. В итоге в целом неплохую систему при десктопном юзеже портит 100500 вот таких вот мелочей. А если взять все-таки что-то десктопное, например, хоть ту же текущую убунту - там все это работает почему-то. Сразу. В совершенно дефолтовой бубунте часы - крутятся.

    > Подозреваю, что здесь он пользуется системной libpng, а там поддержки APNG нет.

    По идее, у мозиллы вроде как свой декодер юзается. Если дебианщики это перепилили зачем-то или просто таскают ископаемую версию браузера в которой фичи вообще нет - ну извините. Я могу себе представить когда они webm начнут понимать такими темпами. oO

     
     
  • 8.64, maxst (?), 11:54, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Мозилла использует встроенную libpng, но они ее чуть-чуть подправили строк ... текст свёрнут, показать
     
     
  • 9.65, rm_ (ok), 12:00, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    И это правильно, пусть осиливают отправку патчей и интеграцию их в апстрим libpn... текст свёрнут, показать
     
     
  • 10.66, maxst (?), 14:37, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Изобретать как раз очень полезно Иначе прогресса не будет Я не против Конкуре... текст свёрнут, показать
     
  • 10.68, User294 (ok), 15:34, 05/10/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А там что-то не срослось и апстрим не захотел интегрять фич, IIRC А если апстр... текст свёрнут, показать
     
     
  • 11.69, rm_ (ok), 17:12, 05/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Да, сделать libpng-ng Или там libapng Отдельным проектом с чётким описанием ... текст свёрнут, показать
     
     
  • 12.71, maxst (?), 23:51, 05/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Теоретически звучит неплохо Но практически кто должен этим заниматься Наверное... текст свёрнут, показать
     
  • 12.73, User294 (ok), 00:30, 11/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ага Давайте в систему поставим N одинаковых либ еще официально Хотя нет, N мал... текст свёрнут, показать
     
  • 9.67, User294 (ok), 15:20, 05/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот поэтому юзеры дебиана и оказываются в пролете То у них браузеры ископаем... текст свёрнут, показать
     
     
  • 10.72, maxst (?), 00:02, 06/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Убунтовских юзеров разбаловали, они теперь требуют поддержки APNG во вьювере EoG... текст свёрнут, показать
     
     
  • 11.74, User294 (ok), 00:32, 11/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну а чего, правильно в общем то требуют GIF давно закопать пора За 256 цветов ... текст свёрнут, показать
     
  • 5.59, maxst (?), 23:34, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > НИ В ОДНОМ распространённом браузере на сегодня нету поддержки вашего замечательного APNG.

    Судя по статистике браузеров, в рунете APNG видят два юзера из трех.

     
  • 3.54, User294 (ok), 20:10, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Вообще-то сжатие видео и сжатие одиночных картинок - весьма разные задачи.

    Кроме случая когда сжимается "key frame" (aka I-frame в мпег). "Ключевой" кадр является опорным, от него далее ведется отсчет, последующие кадры являются по сути попыткой кодировать отличия от опорного кадра, как можно компактнее. Поэтому желательно чтобы опорный кадр как можно лучше передавал сцену в начальном состоянии. По большому счету, ключевой кадр можно рассматривать как статичную картинку со сценой от которой ведется отсчет изменений. В общем то глобальных отличий от жпега в этом плане там немного.

    > или в 21-м веке люди и дальше будут продолжать использовать анимированный GIF.

    Lossy сжатие типа жпега/vp8...  и lossless сжатие типа GIF(LZW) и PNG(zlib) ориентировано на разный класс задач. Lossy хорошо жмут "фотоподобные" изображения, потому что на таких изображениях не видно их артефактов сжатия. А вот "компьютерная графика" типа скриншотов, кнопок/окон и что там еще - выглядит крайне мерзко. Такие кодеки плохо кодируют большие области с одинаковым цветом или тем паче, контрастные линии в большом количестве (они для этого никогда не создавались). Чтобы не было видно артефактов на резких линиях (типа юзер интерфейсов и прочая) - размер файла должен быть невкусным (JPEG скриншота с качеством сравнимым с PNG весит как правило весьма дико). Lossless кодеки хорошо жмут компьютерную графику и подобное - за счет повторяющихся данных типа больших одноцветных областей или линий. Но напрочь спасуют на фотоподобных материалах, которые спасибо если сожмутся так в ~пару раз. Потому что на фотографиях не так уж и много пикселов точно повторяется. В итоге - GIF это анимация. А VP8 и что-то иное на основе jpeg-like и подобных по смыслу техник с DCT - это видеоклипы. Делать анимацию в lossy или видеоклипы в lossless - не эффективно. Хотя бывают и чудики уталкивающие в гиф откровенные видеосцены (только весит оно потом дико) или бойко скриншотящие в JPG :).

     

  • 1.5, anonymous (??), 09:22, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    ждём нового аудиокодека от Google.
     
     
  • 2.6, rm_ (ok), 09:26, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нету необходимости, Vorbis, FLAC и Speex перекрывают все три основных ниши.
    И гугл изобретением велосипедов заниматься не стал:

    > In the WebM container format, the VP8 video is used with Vorbis audio

     

  • 1.10, prokoudine (??), 10:11, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    http://x264dev.multimedia.cx/?p=541

    <тесты и картинки пропущены>

    "This leads us to an obvious question — is Google crazy?  I could understand the push for “WebP” if it was better than JPEG.  And sure, technically as a file format it is, and an encoder could be made for it that’s better than JPEG.  But note the word “could”.  Why announce it now when libvpx is still such an awful encoder?  You’d have to be nuts to try to replace JPEG with this blurry mess as-is."

     
  • 1.11, freelove (?), 10:15, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Молодца! что еще скажешь.

    осталось договориться с производителями фотиков, чтоб они сразу в этом формате сливали фотки.

     
     
  • 2.41, fl (?), 15:03, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > осталось договориться с производителями фотиков, чтоб они сразу в этом формате сливали
    > фотки.

    tiff уже слили, а это уэбпэ и так сливает.

    Мелкий hint: формат для оригинала и для сети всё-таки немного разные вещи.

     

  • 1.15, Аноним (-), 10:42, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Круче гугля только Эппл умеет любое барахло подавать так, что все визжат и радуются. В VP8 используется то же самое старое доброе DCT, только не 8x8, как в жпеге, а 4x4, что хуже. Смысл-то менять шило на мыло. Есть туча кодеков и получше, которыми никто не пользуется, тот же JPEG 2000 на вейвлетах.
     
     
  • 2.26, rm_ (ok), 12:45, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть туча кодеков и получше, которыми никто
    > не пользуется, тот же JPEG 2000 на вейвлетах.

    Там с патентами нехорошая ситуация, вот и не пользуются:
    http://en.wikipedia.org/wiki/JPEG2000#Legal_issues

     
     
  • 3.28, Аноним (-), 13:01, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот раз гугль такой хороший, и там работают лучшие инженеры планеты, как они утверждают, то им уж точно ничего не стоит придумать свой вейвлетный кодек изображений и передать все патенты в public domain.

    Просто в последнее время они только и могут скупать чужие залежавшиеся разработки, а потом препоносить как великий прорыв. Сабж тому явная иллюстрация.

     
  • 3.30, Аноним (-), 13:05, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Да и у VP8 с патентами не всё чисто - это тот же самый H.264 с отличиями на уровне "у них перламутровые пуговицы, а у нас - костяные". Просто MPEG LA понимает, что гугль со всех сторон её задавит, вот и рвётся судиться.
     
  • 3.32, Аноним (-), 13:20, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    За стандартом JPEG2000 стоит около 20 организаций, которые подписали соглашение ... текст свёрнут, показать
     
     
  • 4.77, User294 (ok), 00:42, 11/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > А за кодеком VP8 стоит один гугль, который сегодня добрый, а завтра
    > неизвестно, куда у них ветер подует.

    Фарш невозможно провернуть назад. И лицензии обратного хода не имеют. Если вы кому-то что-то отдали под некоторой лицензией, назад забрать у них это уже не получится, извините.

     
  • 3.56, User294 (ok), 20:16, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > http://en.wikipedia.org/wiki/JPEG2000#Legal_issues

    Патенты - двигатель^W тормоз прогресса. В итоге неплохой формат все боятся использовать. Разве не заметно как стимулируется прогресс? Мы все еще пользуемся жпегом ...цатилетней давности :)

     

  • 1.16, KERNEL_PANIC (ok), 10:56, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Эм, ИМХО лучше б они выпустили не формат хранения изображений, а новый и эффективный алгоритм сжатия для png/tiff и тому подобного. А так, чувствую, он повторит судьбу выше описаных apng и mng
     
     
  • 2.46, hizel (ok), 17:10, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    tiff расширяемый формат, почти контейнер как avi
     

  • 1.17, stimpack (?), 11:12, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ага, еще бы лицезреть воочию эту самую штатную поддержку прозрачности в JPEG
     
  • 1.18, x0r (??), 11:18, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Отсутствует поддержка альфа-канала (прозрачности) и режима работы без потери качества (lossless)" - помоему это НЕ штатные возможности jpeg.
    И правда новый свободный формат нужен, но плюшек можно туда побольше. (а это похоже создавалось за один вечер)
     
     
  • 2.21, Аноним (-), 12:05, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >но плюшек можно туда побольше

    Не unix-way же.... Лучше пусть он делает одно дело, но делает это хорошо (с)

     
     
  • 3.24, x0r (??), 12:44, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ну да для lossless можно png сжатие использовать
     
  • 2.38, gkv311 (ok), 14:32, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >We plan to add support for a transparency layer, also known as alpha  channel in a future update.

    Хотя если честно страшилище jpeg + alpha я ни разу не видел...

     
  • 2.39, fl (?), 14:56, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > И правда новый свободный формат нужен

    Зачем? Ещё старый не докурен.

     

  • 1.20, Codir (?), 11:44, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > визуально насыщенные изображения, такие как фотографии

    Или я что-то в этой жизни не понял, или это написана ахинея. Нельзя "научно-популярный слог" перевести на нормальный?

    Вообще, гугл опять обделался лёгким форматом - тянет на себя одеяло. ЖЫПЕГ не просто лучше "по мнению разработчиков х264", а вообще на голову превосходит этот гуглопродукт. Просто веб-дизайнерам лень поднять зад и сконвертировать ОПТИМАЛЬНО пикчи (Adv.JPEG Compressor) - там запаса хватает, причём можно оптимизировать как по цветовой составляющей, так и по контрастной - параметров море.

     
     
  • 2.23, Аноним (-), 12:10, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >..."по мнению разработчиков х264"

    У них слишком предвзятое мнение, все лишь бы под себя подмять. Много чего им не нравится, но это как говорится только их проблемы.

     
     
  • 3.29, Lain_13 (?), 13:02, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если бы вы и тот, кому вы отвечали, внимательно прочитали статью, то вы бы поняли, что главная проблема заключается в том, что у гугла хреновый энкодер. Он просто сделан через анус и потому результат выдаёт жутчайшего качества. В VP8 и, соответственно, в WebP _можно_ сжимать с качеством близким к h.264 и, вероятно, превосходящим JPEG, но вот беда - в гугловском энкодере нет психовизуально оптимизации которая позволила бы это сделать и потому на нём этого результата достичь нельзя.
    Вот об этом и говорит автор статьи. Он даже привёл пример какой кусок навоза выдаёт его x264 если его заставить работать без психовизуальной оптимизации, а лишь с PSNR, как работает VP8. Качество там лишь чуть-чуть лучше, чем у VP8, что многое говорит о качестве энкодера.

    А теперь представьте как можно пытаться пропихнуть формат картинок основанный на таком навозном энкодере? А ведь гугл будет его именно на основе своей реализации пропихивать!

    А ещё он говорит о том, что JPEG гуглу всё равно не спихнуть с трона. Во-первых все патенты на него уже давно истекли, а во-вторых - его уже несколько раз пытались спихнут даже более эффективными и насыщенными возможностями форматами чем WebP и попытки провалились.

    Но нет, вы всё это пропустили и хрен пойми о чём говорите.

     
     
  • 4.31, Аноним (-), 13:15, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Но нет, вы всё это пропустили и хрен пойми о чём говорите.

    Не то. Речь вообще про их высказывания, а не по этому отдельному случаю. Они только себя хвалят - вроде как это известный факт. Формат только вышел, а вы от него хотите сразу и всего - такого не бывает, оптимизируют и энкодер еще, всему своё время.

     
     
  • 5.36, Lain_13 (?), 13:57, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > - такого не бывает, оптимизируют и энкодер еще, всему своё время.

    Вот пусть сначала оптимизируют энкодер, а потом уже на его основе WebP продвигают, а то сейчас оно страшнее атомной войны.

     
     
  • 6.37, rm_ (ok), 14:15, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вот пусть сначала оптимизируют энкодер, а потом уже на его основе WebP
    > продвигают, а то сейчас оно страшнее атомной войны.

    Хватит Вам кипятиться, никто никого пока не продвигает, выпущен лишь "developer preview", новость об этом в каком-то лесном блоге, и конвертор командной строки только под GNU/Linux.
    С помпой, которую сопровождало публичное объявление WebM (сразу поддержка во многих популярных плеерах и браузерах, куча логотипов компаний-спонсоров стандарта, хаутушки для простых домашних юзеров, и т.д.) это не сравнить.

     

  • 1.27, pro100master (ok), 12:53, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Как-то они промахнулись - прозрачности нет
     
  • 1.33, grayich (ok), 13:32, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Это только мне заметны более-явные артефакты по сравнению с jpg ?

    так тот-же размер с тем-же качеством наверно можно получить в jpg, если качество до 60% понизить

     
  • 1.34, mik (??), 13:45, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    http://abbra.livejournal.com/167068.html
     
  • 1.35, xxx (??), 13:53, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >при этом при кодировании WebP появилась заметная на глаз размытость (оригинал, webp, jpeg).

    Да по сравнению с оригиналом, что jpeg, что webp лажа, оба неприятны глазу.

     
     
  • 2.70, Aquarius (ok), 20:12, 05/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    а по-моему, размытость лучше, чем размытость в клетку
     

  • 1.40, h31 (ok), 14:57, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Буду продолжать пользоваться PNG и JPEG. А гугль пусть пилит, если так хочется. Может и вправду что-нибудь нормальное сделает.
     
     
  • 2.60, Аноним123321 (ok), 04:43, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    буду пользоваться PNG

    :-)

     

  • 1.45, аноним (?), 17:00, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Блин, хорошую идею google как обычно реализовал через жопу. Еще надо же бы назвать riff стандартным...
     
     
  • 2.61, User294 (ok), 05:57, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Блин, хорошую идею google как обычно реализовал через жопу. Еще надо же
    > бы назвать riff стандартным...

    А чем riff плох? Простой как топор формат, прост и быстр в парсинге, расширяем до упора, а  видоизменения этой идеи юзают и многие иные форматы. Я даже не помню кто у кого попер эту идею формата, но в мире есть с полдюжины общих по идее но разных в деталях реализации подвидов такого структурирования файлов. Вот то что фичи явно недоделаны и много чего оставлено на потом - это да, спорный вопрос. Равно как не очень понятно почему именно RIFF контейнер все-таки. Благо для webm они субсет матрешки уже взяли - есть некая разноперость форматов. Нафига бы?

     

  • 1.47, Карбофос (ok), 17:16, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    помнится, такая же инициатива была по поводу LuraWave и Jpeg2000 форматов. посмотрим, что получится с открытым форматом.
     

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



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

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