Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 78

Молодцы. Давно уже пора было.
Жалко только, что очень долго будут те самые 15-30%, которые не дадут нормально использовать этот формат, как html5 сейчас, а к моменту доступности на рынке уже сможет появится альтернатива получше, но все-равно — полезное начинание.

пс. перевод хороший
Всего голосов 12: ↑9 и ↓3+6
Да, давно уже мечтал о JPEG'е с прозрачностью. Google не перестает радовать.
Комментарий пока не оценивали0
JPEG XR? Помимо альфы есть поддержка 16-битных каналов, lossy/lossless режимов, лучшее качество сжатия и пр… Помимо стандартизации самим ISO/JPEG, рекомендован еще и ITU-T
Всего голосов 6: ↑6 и ↓0+6
Согласен. Зачем нужно продвигать новый формат если уже есть отличный Jpeg XR от Microsoft
Всего голосов 8: ↑4 и ↓40
Кстати, кто-нибудь разбирался в лицензии на Jpeg XR? Я так понял, эта собственная лицензия Майкрософта под названием Open Specification Promise, являющаяся разновидностью GPL, но с какими-то ограничениями (например, что права на патенты остаются за самой компанией). Мне неясно, например, можно ли ее использовать в коммерческих разработках.

Кстати, так и не нашел ссылку на лицензию WebP, кроме упоминания, что это open-source.
Всего голосов 3: ↑3 и ↓0+3
На саму спецификацию никаких лицензий быть не может. Есть патенты, но они прикрыты MS-овским Open Specification Promise. Собственно не вижу причин по которым это должно волновать больше, чем членство MS в MPEG LA, к примеру. Да и патенты гугла, покрывающие WebM/WebP тоже никто не отменял
Всего голосов 1: ↑1 и ↓0+1
Насчет коммерческого использования — да конечно. OSP не имеет отношения к GPL — это просто обещание MS не преследовать никого, кто реализует технологии, описанные в патентах, покрытых OSP/Community Promise.

Лицензии на код, распространяющийся в составе «HD Photo Device Porting Kit» — это совершенно другое дело. Его придется перереализовывать (возможно использую reference implementation из ISO-шного стандарта)
Всего голосов 1: ↑1 и ↓0+1
А есть ещё расово опенсорсный PGF. Там и поддержка альфа канала, и lossy/lossless режимы и качество сжатия выше чем у jpg/png.
Всего голосов 1: ↑1 и ↓0+1
О, тем более. Есть как минимум одна вовсю стандартизированная и одна вовсю опенсорсная замена JPEG.
Не знает ли кто тулзы для высчитывания PSNR (не хочется самому писать) — очень уж интересно сравнить JPEG@85% (или JPEG-XR) с этим самым WebP
Комментарий пока не оценивали0
image
Комментарий пока не оценивали0
фатальный недостаток?
Комментарий пока не оценивали0
JPEG-2000 поддерживает сжатие с потерями и без, поддерживает прозрачность, поддерживает маски качества; и всё это с очень продуманным дата-стримом для потоковой передачи, и даже с защитой от помех/потерь. Короче говоря, зачем Гуглю было изобретать велосипед, да еще и с квадратными колесами — не ясно.

У JPEG-2000 единственная проблема — это возможные лицензионные вопросы, но кто мешает разработать формат лишенный этого (возможного!) недостатка и при этом задействовать проверенные технологии, которые уже много лучше обычного JPEG. WebP базирован на VP8, используется древний DCT + новый постпроцессинг. Но эта схема хорошо отрабатывает только в видео, в статике она не добирается до уровня вейвлет-сжатия.

К примеру, вот сравнение Jpeg-2000 и Jpeg-XR:
www.compression.ru/video/codec_comparison/wmp_codecs_comparison.html
Отсюда видно, что JPEG-XR — середнячок с бедными возможностями (по сравнению с JPEG-2000). А между тем, даже он проигрывает WebP.

Другими словами, гуглевцам следовало бы опубликовать сравнение не JPEG-vs-WebP (сравнение с заведомо устаревшей технологией!), а JPEG2000-vs-WebP — вот тогда бы мы увидели, чего стоит их разработка.

piroJOKE
Всего голосов 4: ↑4 и ↓0+4
О попадании этого за компанию с WebM, в Firefox 4, наверно, вряд ли имеет смысл мечтать?
Комментарий пока не оценивали0
Подозреваю, что они уже общались с производителями браузеров — ещё до анонса формата. Но насчет конкретно 4-ки, конечно, трудно сказать наверняка. Подождем реакции мозиллы.
Комментарий пока не оценивали0
Следим @ голосуем https://bugzilla.mozilla.org/show_bug.cgi?id=600919
Всего голосов 1: ↑1 и ↓0+1
Ого, вы посмотрите, какая разница:


В целых 4 раза.

Но давайте приведем jpeg к токому-же размеру, как webp (164 кб) и посмотрим на результат:


Как говорится, на лицо. На больших версиях лучше видно, что на самом деле качество jpeg даже немного лучше в этом месте, в остальных местах разницы на глаз не видно. Это при том, что в jpeg я сохранил из другого jpeg, в котором уже были искажения. А в WebP, скорее всего, сохраняли из лучшего качества.

Это называется честным сравнением?
Всего голосов 18: ↑17 и ↓1+16
Наверное, это было бы правильно продублировать в комментариях к оригиналу статьи. Я-то не автор формата, всё же.

Но могу предположить, что качество jpeg при равном размере очень зависит от кодировщика. С WebP, вероятно, будет так же, а кодировщик только-только вышел в предварительной версии. Посмотрим, что будет дальше. Даже один факт наличия lossy-формата с альфа каналом уже радует.
Всего голосов 7: ↑6 и ↓1+5
Там же, в комментариях:
> the «WebP images» are really the JPEG files as re-encoded with the WebP coder, then converted to PNG files

Т.е. юзер Troy (предполагает?), что то, что приводится в качестве примеров WebP, изначально взято из JPEG. Следовательно, лучше оригинала выглядеть не может.
Всего голосов 4: ↑4 и ↓0+4
Т.е. они просто нашли в википедии несколько картинок, пожатых в jpeg в неизвестном качестве неизвестным компрессором и пережали их в свой WebP, с таким качетсвом, чтобы не появлялись искажения. Ай, молодцы Гугл. А то, что эти же картинки можно было и самим jpeg пожать до тех же размеров, они не догадались?

Для верности пожал кораблик до тех же размеров, что у них получился WebP — визуальных различий нет.
Всего голосов 3: ↑2 и ↓1+1
Ну я в paint.net наложил самую большую картинку (которая 7.jpg) на пожатую WebP с типом слоя Difference — там явно видно небольшие искажения. Пожал ту же картинку JPEG-XR-ом с качеством 85% (размер чуть меньше 2 мегабайт против чуть более трех для WebP) — в результате наложения невооруженным глазом увидеть ничего не могу.
Всего голосов 2: ↑2 и ↓0+2
Я не понял, в чем смысл этих действий и какие выводы вы хотите сделать?

Вы же не думаете, что восприятие глазом происходит попиксельно и если 2 два пикселя поменять местами, то вся картинка пропала?
Комментарий пока не оценивали0
Я к тому, что даже если искажения не заметны глазу, они все равно есть. Вот дифф спортсмена (2.jpg) перепакованного в JPEG-XR@85% (157,352 bytes против 164910 bytes у WebP). А вот дифф оригинала и WebP. JPEG-XR обеспечил бОльшее качество картинки при сохранении бОльшего количества деталей. Для чистоты эксперимента (вдруг за счет близости алгоритмов у JPEG-XR «фора»), перепаковал оригинал обычным JPEG на 85% (171,070 bytes — файл даже немного больше, чем WebP) и вот здесь дифф. Потеряно даже больше деталей, чем у WebP при бОльшем размере файла.

Я сделал подобные манипуляции еще с несколькими картинками: везде один и тот же результат. WebP лучше JPEG, но хуже JPEG-XR
Всего голосов 5: ↑5 и ↓0+5
Различия есть — это бесспорно. Таков принцип сжатия с потерями — перестроить изображение так, чтобы его было легче хранить. А вот искажения — это как раз то, что заметно глазу. Так что фраза «искажения есть, хотя они и не заметны глазу», ложна уже из определения.

Про JPEG-XR я бы предпочел не говорить, ибо с этим форматом я не знаком и это не относится к теме подлога фактов на странице галереи.
Комментарий пока не оценивали0
Я не пытался спорить с подлогом (хотя исходя из того, что я увидел WebP все таки получше старичка JPEG). Я просто предложил (вернее это был не я — этот метод используется повсеместно в сравнении качества lossy кодеков) более «научный» метод. Для полного счастья надо бы пройтись по всем пикселям и посчитать PSNR, но городить собственный велосипед мне не хочется, а готового я не нашел.

Про JPEG XR можно почитать здесь. Ну еще пару линков я приводил выше. Отношение к теме имеет в том плане, что не стоит гуглю изобретать никому не нужный, да еще и менее качественный велосипед, при том, что уже все давно придумано.
Комментарий пока не оценивали0
Т.е. они просто нашли в википедии несколько картинок, пожатых в jpeg в неизвестном качестве неизвестным компрессором и пережали их в свой WebP, с таким качетсвом, чтобы не появлялись искажения.
С чего вы взяли?
Может они взяли в качестве исходника качественный JPEG с высоким разрешением и пережали его в два формата: в «низкобитрейтный» JPEG, и в «низкобитрейтный» WebP, которые потом и сравнили.
Комментарий пока не оценивали0
The tables on this page contain some sample images from Wikipedia.
Beneath each JPEG image is the file size of the original source image.


Честно говоря, даже читать противно. Размер написан оригиналов, качество предлагают посмотреть на пережатых превьюшках, одни в jpg, другие в png.
Комментарий пока не оценивали0
Сжатие jpeg тоже бывает разным, хотелось бы увидеть какие параметры были заданы при сжатии
Комментарий пока не оценивали0
Какой странный вопрос. Параметр один — качество сжатия, оно каждым компрессором понимается по своему. Качество было выбрано таким, чтобы размер совпадал.
Всего голосов 2: ↑1 и ↓10
>каждым компрессором понимается по своему
именно! можно сжать разными компрессорами при лучшем качестве(на глаз) и размер будет одинаковый
а параметры обычно включают и то чем сжимают, или не? )))
Комментарий пока не оценивали0
Программа «Просмотр», ползунок между 6-м и 7-м столбиком. Удовлетворены?
Всего голосов 1: ↑0 и ↓1-1
Удовлетворены?
нет!
1) открыл фотошоп CS3 -> 2_webp.png -> save for web -> jpeg -> качество 100% размер = 105,2 кб
2)…
3) PROFIT!!!

Качество на глаз не отличишь, хотя как известно глаз у всех разный :D
Помнится у Штирлица вобще глаз-алмаз был))))
Комментарий пока не оценивали0
У меня для вам плохие новости: по тем ссылкам сейчас совсем другие файлы. Сравните со ссылкой «результат» из моего исходного сообщения. Теперь оригиналы нужно качать отдельным архивом. Я так понимаю, это сделано для удобства пользователей: теперь проверить результаты менее удобно, меньше людей это сделают, Гугл будет спать спокойнее.
Всего голосов 3: ↑2 и ↓1+1
Интересна эффективность этого алгоритма в сравнении с вейвлетными, например JPEG2000.
Всего голосов 4: ↑4 и ↓0+4
А JPEG2000 браузерами до сих пор не поддерживается?
Если так, то надеюсь, что WebP хоть в этом его обгонит, даже если его эффективность хуже (в чём, собственно, не сомниваюсь)
Всего голосов 1: ↑1 и ↓0+1
Не извольте беспокоится — то, что вы видите на этой странице — всего лишь превьюшки. Сами картинки можно скачать выше одним архивом. Правда, в маркетинговых целях превьюшки формата jpg сохранены в формате jpg, а превьюшки формата WebP — в формате png, отчего последние выглядят лучше, что накладывает дополнительные положительные ассоциации на формат. Microsoft-way, так сказать.
Всего голосов 9: ↑4 и ↓5-1
А каким образом превьюшки формата WebP, из-за отсутствия поддержки этого формата браузерами выложенные в png, могут выглядеть лучше?
Всего голосов 5: ↑3 и ↓2+1
Вы всерьез задаете это вопрос, или так, поржать? Для вас не очевидно, что превьюшки должны быть в одном формате (без разницы, png или jpg), чтобы между ними не было разницы?
Всего голосов 6: ↑3 и ↓30
У вас есть нарекания к встроенным в браузеры декодерам jpg?
Всего голосов 3: ↑2 и ↓1+1
Никаких. А что вас привело к этой мысли?
Всего голосов 2: ↑1 и ↓10
Я просто пытаюсь понять, почему вас не устраивает jpg. Как я понимаю, единственным отличием png от jpg на экране могут быть лишь различия в алгоритмах раскодировки jpg — теми, что встроены в браузеры и тем, что будет использоваться для преобразования jpg → png (как предлагаете вы). Если претензий к декодерам нет, почему есть претензии к выбору формата для показа?
Всего голосов 2: ↑2 и ↓0+2
Давайте я тогда диаграмму нарисую, раз у вас с логикой туго:
Оригинальное изображение → Размер уменьшен (качество улучшилось) → сохранена в jpeg (качество ухудшилось)
↓
Закодированное WebP → Размер уменьшен (качество улучшилось) → сохранена в png (качество не ухудшилось)
Комментарий пока не оценивали0
А, теперь понятно. У вас претензии к потерям при сохранении в jpeg уменьшенного изображения.

Ну, кстати, второй шаг мог быть и таким: Оригинальное изображение (jpg) → Размер уменьшен → закодирована в WebP → сохранена в png.
Всего голосов 2: ↑2 и ↓0+2
Знаете, я полный идиот. Мой первый комментарий в этой ветке был к комментарию bazzzman. И я все время был уверен, что разговор идет оттуда. Теперь понятно, почему вы сразу про превьюшку не поняли. Срам то какой.
Всего голосов 2: ↑2 и ↓0+2
Думаю, даже перенеся эту ветку на место, я бы всё равно не понял :) Меня слишком смутила фраза, что png, сделанные из WebP, выглядят лучше jpg.
Всего голосов 1: ↑1 и ↓0+1
Не может png сделаный из webp выглядеть лучше чем webp. Сделано это для того, что бы в браузере было видно.
Комментарий пока не оценивали0
Не может png сделаный из webp выглядеть лучше чем webp.
Браво! А вот jpeg, сделанный из jpeg, может.
А точнее даже, сделаны они не из jpeg, а из сильно уменьшенных в размерах jpeg и webp, отчего искажения от первоначального jpeg или webp практически исчезают.
Всего голосов 1: ↑1 и ↓0+1
> А вот jpeg, сделанный из jpeg, может.

Так WebP сравнивают с тем, что используется в вебе сейчас.
А сейчас это очень часто и есть «jpeg, сделанный из jpeg», т.е. любительская JPEG-фотка высокого разрешения переживается в JPEG малого разрешения для веб-страниц. Поэтому тут никакого подлога нет.
Комментарий пока не оценивали0
Давно пора. Надеюсь приживется
Всего голосов 5: ↑1 и ↓4-3
Что-то я не понял. Если они брали за оригинал jpeg и перекодировали его в webp, то почему на последней фотографии резкость у webp лучше, чем у jpeg? Их конвектер умеет вытягивать резкость? о_О
Всего голосов 2: ↑2 и ↓0+2
Да, я тоже заметил.
На 4-ой фотографии это хорошо видно (надо смотреть на кривые линии, на стрелках).
Комментарий пока не оценивали0
Этот комментарий должен был быть здесь.
Комментарий пока не оценивали0
интересно, Progressive Mode будет? хотелось бы…
Комментарий пока не оценивали0
А для анимации так и остаётся только формат gif. ((
Всего голосов 2: ↑1 и ↓10
Есть еще APNG, но он совсем совсем нестандартизирован.
Всего голосов 1: ↑1 и ↓0+1
Есть APNG, поддерживается Оперой и Фаерфоксом. Ну и тег видео никуда не делся.
Всего голосов 1: ↑1 и ↓0+1
До появления упомянутого APNG пытались MNG внедрить, но он к счастью благополучно не прижился.

Ещё не стоит забывать об SVG, который также неплохо справляется с анимацией.
Всего голосов 1: ↑1 и ↓0+1
Я в форматах изображения мало чего понимаю. Но как можно судить о качестве картинки, выкладывая ее на сайт, при условии, что браузер такой формат вообще не знает?
Зайдя на сайт и просмотрев свойства картинок увидел что слева jpeg размером в 10 раз меньше чем справа png, как вообще по такой ерунде можно судить?
Всего голосов 4: ↑1 и ↓3-2
Очень просто. Берем картинку, зажимаем в тестируемый формат, после переводим в несжатый(bmp) или сжатый одним из методов сжатия без потерь (png). Сравниваем.

Всегда ваш, К.О.
Всего голосов 7: ↑7 и ↓0+7
Ждем теста с тремя кадрами — оригинал, jpeg, webp.
Всего голосов 3: ↑3 и ↓0+3
Вот здесь я провел небольшое сравнение. Похоже, WebP действительно лучше JPEG, но в то же время свежеиспеченый формат хуже JPEG-XR, которому сто лет в обед и который стандартизирован везде где только можно
Всего голосов 1: ↑1 и ↓0+1
JPEG-XR, которому сто лет в обед и который стандартизирован везде где только можно
Сто лет в обед?
Спецификация JPEG-XR была окончательно подготовлена, утверждена и стандартизирована только в 2009 году. (напоминаю, сейчас 2010)
Везде, где только можно?
Поддержка его есть только в последних MS-продуктах, и в частности в бета версиях IE9. Ни один релизный браузер этот формат не поддерживает.
Всего голосов 3: ↑2 и ↓1+1
Take it easy, bro :-)
В данном случае я не настроен на холиворы, прошу прощения, если ненароком дал понять обратное.

Я имел в виду, что самому формату уже пять лет. Даже если WebP будет когда либо стандартизирован ISO/IEC и ITU-T, это займет те же пять лет. Мой посыл в том, что миру не нужен еще один формат, который к тому же хуже всего, что уже давно придумано и стандартизировано (но не используется).
Если JPEG 2000 лучше JPEG XR — пусть будет JPEG 2000, но зачем нужен WebP?
Всего голосов 2: ↑2 и ↓0+2
>> но зачем нужен WebP?

Ну как это зачем? У Майкрософта есть свой формат, у AT&T — тоже, у AOL'a — и то есть, а чем Гугл хуже? Мода :)
Комментарий пока не оценивали0
Что-то в галлерее у меня жипег загрузился моменталььно, а webp — раза в четыре дольше загружался
Комментарий пока не оценивали0
Там не webp, там png, полученная из webp. png на фотографиях показывает ОЧЕНЬ плохие результаты по качеству сжатия.
Всего голосов 1: ↑1 и ↓0+1
Давай Google, бери контроль над всей технологической базой Интернет. Спасибо что ты — не Microsoft! А если серьезно, что там еще осталось за чем не стоит наш Самый Большой Брат (СББ)?
Всего голосов 7: ↑2 и ↓5-3
Этих форматов как грязи, но из-за браузеров всё равно будем как идиоты сидеть на JPEG для фотографий и PNG 8/24 для дизайна с полупрозрачными элементами. Форматы новые и так есть, но где их поддержка...?
Комментарий пока не оценивали0
Правильно, тем более без поддержки в ie9(а уж если и в ie8, эх мечты, мечты) ждать широкого распространения формата не приходится.
Всего голосов 1: ↑1 и ↓0+1
Есть Google Chrome Frame. Можно не обращать внимания на IE, если заставить большинство таких юзеров использовать сей плагин.
Всего голосов 1: ↑1 и ↓0+1
если заставить большинство таких юзеров использовать сей плагин
LOL
Всего голосов 2: ↑2 и ↓0+2
Была бы поддержка — давно бы фотками в формате DJVU обменивались, который их жмёт раз в пять по сравнению с JPEG — а не на жалкие 40%.
Комментарий пока не оценивали0
НЛО прилетело и опубликовало эту надпись здесь
В DJVU несколько алгоритмов используется, один из них очень хорошо жмёт jpeg растр — насчёт в пять раз я не пошутил. И распаковывается достаточно быстро. По крайней мере если вспомнить, что на мобильном устройстве закаать картинку стоит и денег и времени…
Комментарий пока не оценивали0
А те jpeg-изображения, которые они (google) находили в сети, точно были сжаты с правильными параметрами?
А то может быть в этих файлах куча мета-информации осталась?
Не слишком ли поспешные выводы тогда?
Согласен с вышеотписавшимися, что ждем сравнение оригинал — jpeg — webP. При чем jpeg по всем правилам из оригинала компетентными в оптимизации изображений людьми…
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr