Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 78
Молодцы. Давно уже пора было.
Жалко только, что очень долго будут те самые 15-30%, которые не дадут нормально использовать этот формат, как html5 сейчас, а к моменту доступности на рынке уже сможет появится альтернатива получше, но все-равно — полезное начинание.
пс. перевод хороший
Жалко только, что очень долго будут те самые 15-30%, которые не дадут нормально использовать этот формат, как html5 сейчас, а к моменту доступности на рынке уже сможет появится альтернатива получше, но все-равно — полезное начинание.
пс. перевод хороший
Да, давно уже мечтал о JPEG'е с прозрачностью. Google не перестает радовать.
Согласен. Зачем нужно продвигать новый формат если уже есть отличный Jpeg XR от Microsoft
Кстати, кто-нибудь разбирался в лицензии на Jpeg XR? Я так понял, эта собственная лицензия Майкрософта под названием Open Specification Promise, являющаяся разновидностью GPL, но с какими-то ограничениями (например, что права на патенты остаются за самой компанией). Мне неясно, например, можно ли ее использовать в коммерческих разработках.
Кстати, так и не нашел ссылку на лицензию WebP, кроме упоминания, что это open-source.
Кстати, так и не нашел ссылку на лицензию WebP, кроме упоминания, что это open-source.
На саму спецификацию никаких лицензий быть не может. Есть патенты, но они прикрыты MS-овским Open Specification Promise. Собственно не вижу причин по которым это должно волновать больше, чем членство MS в MPEG LA, к примеру. Да и патенты гугла, покрывающие WebM/WebP тоже никто не отменял
Насчет коммерческого использования — да конечно. OSP не имеет отношения к GPL — это просто обещание MS не преследовать никого, кто реализует технологии, описанные в патентах, покрытых OSP/Community Promise.
Лицензии на код, распространяющийся в составе «HD Photo Device Porting Kit» — это совершенно другое дело. Его придется перереализовывать (возможно использую reference implementation из ISO-шного стандарта)
Лицензии на код, распространяющийся в составе «HD Photo Device Porting Kit» — это совершенно другое дело. Его придется перереализовывать (возможно использую reference implementation из ISO-шного стандарта)
А есть ещё расово опенсорсный PGF. Там и поддержка альфа канала, и lossy/lossless режимы и качество сжатия выше чем у jpg/png.
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
У 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
habrahabr.ru/blogs/google/105331/#comment_3299807
habrahabr.ru/blogs/google/105331/#comment_3300141
// Эх, наплодили однотипных топиков, теперь на два фронта обсуждение что ли вести?
habrahabr.ru/blogs/google/105331/#comment_3300141
// Эх, наплодили однотипных топиков, теперь на два фронта обсуждение что ли вести?
О попадании этого за компанию с WebM, в Firefox 4, наверно, вряд ли имеет смысл мечтать?
Подозреваю, что они уже общались с производителями браузеров — ещё до анонса формата. Но насчет конкретно 4-ки, конечно, трудно сказать наверняка. Подождем реакции мозиллы.
Следим @ голосуем https://bugzilla.mozilla.org/show_bug.cgi?id=600919
Учись подсвечивать https-ссылки, хабр!
https://bugzilla.mozilla.org/show_bug.cgi?id=600919
https://bugzilla.mozilla.org/show_bug.cgi?id=600919
Ого, вы посмотрите, какая разница:
В целых 4 раза.
Но давайте приведем jpeg к токому-же размеру, как webp (164 кб) и посмотрим на результат:
Как говорится, на лицо. На больших версиях лучше видно, что на самом деле качество jpeg даже немного лучше в этом месте, в остальных местах разницы на глаз не видно. Это при том, что в jpeg я сохранил из другого jpeg, в котором уже были искажения. А в WebP, скорее всего, сохраняли из лучшего качества.
Это называется честным сравнением?
В целых 4 раза.
Но давайте приведем jpeg к токому-же размеру, как webp (164 кб) и посмотрим на результат:
Как говорится, на лицо. На больших версиях лучше видно, что на самом деле качество jpeg даже немного лучше в этом месте, в остальных местах разницы на глаз не видно. Это при том, что в jpeg я сохранил из другого jpeg, в котором уже были искажения. А в WebP, скорее всего, сохраняли из лучшего качества.
Это называется честным сравнением?
Ссылку забыл: code.google.com/speed/webp/gallery.html
Наверное, это было бы правильно продублировать в комментариях к оригиналу статьи. Я-то не автор формата, всё же.
Но могу предположить, что качество jpeg при равном размере очень зависит от кодировщика. С WebP, вероятно, будет так же, а кодировщик только-только вышел в предварительной версии. Посмотрим, что будет дальше. Даже один факт наличия lossy-формата с альфа каналом уже радует.
Но могу предположить, что качество jpeg при равном размере очень зависит от кодировщика. С WebP, вероятно, будет так же, а кодировщик только-только вышел в предварительной версии. Посмотрим, что будет дальше. Даже один факт наличия lossy-формата с альфа каналом уже радует.
Там же, в комментариях:
> the «WebP images» are really the JPEG files as re-encoded with the WebP coder, then converted to PNG files
Т.е. юзер Troy (предполагает?), что то, что приводится в качестве примеров WebP, изначально взято из JPEG. Следовательно, лучше оригинала выглядеть не может.
> the «WebP images» are really the JPEG files as re-encoded with the WebP coder, then converted to PNG files
Т.е. юзер Troy (предполагает?), что то, что приводится в качестве примеров WebP, изначально взято из JPEG. Следовательно, лучше оригинала выглядеть не может.
Т.е. они просто нашли в википедии несколько картинок, пожатых в jpeg в неизвестном качестве неизвестным компрессором и пережали их в свой WebP, с таким качетсвом, чтобы не появлялись искажения. Ай, молодцы Гугл. А то, что эти же картинки можно было и самим jpeg пожать до тех же размеров, они не догадались?
Для верности пожал кораблик до тех же размеров, что у них получился WebP — визуальных различий нет.
Для верности пожал кораблик до тех же размеров, что у них получился WebP — визуальных различий нет.
Ну я в paint.net наложил самую большую картинку (которая 7.jpg) на пожатую WebP с типом слоя Difference — там явно видно небольшие искажения. Пожал ту же картинку JPEG-XR-ом с качеством 85% (размер чуть меньше 2 мегабайт против чуть более трех для WebP) — в результате наложения невооруженным глазом увидеть ничего не могу.
Я не понял, в чем смысл этих действий и какие выводы вы хотите сделать?
Вы же не думаете, что восприятие глазом происходит попиксельно и если 2 два пикселя поменять местами, то вся картинка пропала?
Вы же не думаете, что восприятие глазом происходит попиксельно и если 2 два пикселя поменять местами, то вся картинка пропала?
Я к тому, что даже если искажения не заметны глазу, они все равно есть. Вот дифф спортсмена (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
Я сделал подобные манипуляции еще с несколькими картинками: везде один и тот же результат. WebP лучше JPEG, но хуже JPEG-XR
Различия есть — это бесспорно. Таков принцип сжатия с потерями — перестроить изображение так, чтобы его было легче хранить. А вот искажения — это как раз то, что заметно глазу. Так что фраза «искажения есть, хотя они и не заметны глазу», ложна уже из определения.
Про JPEG-XR я бы предпочел не говорить, ибо с этим форматом я не знаком и это не относится к теме подлога фактов на странице галереи.
Про JPEG-XR я бы предпочел не говорить, ибо с этим форматом я не знаком и это не относится к теме подлога фактов на странице галереи.
Я не пытался спорить с подлогом (хотя исходя из того, что я увидел WebP все таки получше старичка JPEG). Я просто предложил (вернее это был не я — этот метод используется повсеместно в сравнении качества lossy кодеков) более «научный» метод. Для полного счастья надо бы пройтись по всем пикселям и посчитать PSNR, но городить собственный велосипед мне не хочется, а готового я не нашел.
Про JPEG XR можно почитать здесь. Ну еще пару линков я приводил выше. Отношение к теме имеет в том плане, что не стоит гуглю изобретать никому не нужный, да еще и менее качественный велосипед, при том, что уже все давно придумано.
Про JPEG XR можно почитать здесь. Ну еще пару линков я приводил выше. Отношение к теме имеет в том плане, что не стоит гуглю изобретать никому не нужный, да еще и менее качественный велосипед, при том, что уже все давно придумано.
Т.е. они просто нашли в википедии несколько картинок, пожатых в jpeg в неизвестном качестве неизвестным компрессором и пережали их в свой WebP, с таким качетсвом, чтобы не появлялись искажения.С чего вы взяли?
Может они взяли в качестве исходника качественный JPEG с высоким разрешением и пережали его в два формата: в «низкобитрейтный» JPEG, и в «низкобитрейтный» WebP, которые потом и сравнили.
Сжатие jpeg тоже бывает разным, хотелось бы увидеть какие параметры были заданы при сжатии
Какой странный вопрос. Параметр один — качество сжатия, оно каждым компрессором понимается по своему. Качество было выбрано таким, чтобы размер совпадал.
>каждым компрессором понимается по своему
именно! можно сжать разными компрессорами при лучшем качестве(на глаз) и размер будет одинаковый
а параметры обычно включают и то чем сжимают, или не? )))
именно! можно сжать разными компрессорами при лучшем качестве(на глаз) и размер будет одинаковый
а параметры обычно включают и то чем сжимают, или не? )))
Программа «Просмотр», ползунок между 6-м и 7-м столбиком. Удовлетворены?
Удовлетворены?
нет!
1) открыл фотошоп CS3 -> 2_webp.png -> save for web -> jpeg -> качество 100% размер = 105,2 кб
2)…
3) PROFIT!!!
Качество на глаз не отличишь, хотя как известно глаз у всех разный :D
Помнится у Штирлица вобще глаз-алмаз был))))
нет!
1) открыл фотошоп CS3 -> 2_webp.png -> save for web -> jpeg -> качество 100% размер = 105,2 кб
2)…
3) PROFIT!!!
Качество на глаз не отличишь, хотя как известно глаз у всех разный :D
Помнится у Штирлица вобще глаз-алмаз был))))
У меня для вам плохие новости: по тем ссылкам сейчас совсем другие файлы. Сравните со ссылкой «результат» из моего исходного сообщения. Теперь оригиналы нужно качать отдельным архивом. Я так понимаю, это сделано для удобства пользователей: теперь проверить результаты менее удобно, меньше людей это сделают, Гугл будет спать спокойнее.
Интересна эффективность этого алгоритма в сравнении с вейвлетными, например JPEG2000.
А JPEG2000 браузерами до сих пор не поддерживается?
Если так, то надеюсь, что WebP хоть в этом его обгонит, даже если его эффективность хуже (в чём, собственно, не сомниваюсь)
Если так, то надеюсь, что WebP хоть в этом его обгонит, даже если его эффективность хуже (в чём, собственно, не сомниваюсь)
Не извольте беспокоится — то, что вы видите на этой странице — всего лишь превьюшки. Сами картинки можно скачать выше одним архивом. Правда, в маркетинговых целях превьюшки формата jpg сохранены в формате jpg, а превьюшки формата WebP — в формате png, отчего последние выглядят лучше, что накладывает дополнительные положительные ассоциации на формат. Microsoft-way, так сказать.
А каким образом превьюшки формата WebP, из-за отсутствия поддержки этого формата браузерами выложенные в png, могут выглядеть лучше?
Вы всерьез задаете это вопрос, или так, поржать? Для вас не очевидно, что превьюшки должны быть в одном формате (без разницы, png или jpg), чтобы между ними не было разницы?
У вас есть нарекания к встроенным в браузеры декодерам jpg?
Никаких. А что вас привело к этой мысли?
Я просто пытаюсь понять, почему вас не устраивает jpg. Как я понимаю, единственным отличием png от jpg на экране могут быть лишь различия в алгоритмах раскодировки jpg — теми, что встроены в браузеры и тем, что будет использоваться для преобразования jpg → png (как предлагаете вы). Если претензий к декодерам нет, почему есть претензии к выбору формата для показа?
Давайте я тогда диаграмму нарисую, раз у вас с логикой туго:
Оригинальное изображение → Размер уменьшен (качество улучшилось) → сохранена в jpeg (качество ухудшилось) ↓ Закодированное WebP → Размер уменьшен (качество улучшилось) → сохранена в png (качество не ухудшилось)
А, теперь понятно. У вас претензии к потерям при сохранении в jpeg уменьшенного изображения.
Ну, кстати, второй шаг мог быть и таким: Оригинальное изображение (jpg) → Размер уменьшен → закодирована в WebP → сохранена в png.
Ну, кстати, второй шаг мог быть и таким: Оригинальное изображение (jpg) → Размер уменьшен → закодирована в WebP → сохранена в png.
Знаете, я полный идиот. Мой первый комментарий в этой ветке был к комментарию bazzzman. И я все время был уверен, что разговор идет оттуда. Теперь понятно, почему вы сразу про превьюшку не поняли. Срам то какой.
Не может png сделаный из webp выглядеть лучше чем webp. Сделано это для того, что бы в браузере было видно.
Давно пора. Надеюсь приживется
Что-то я не понял. Если они брали за оригинал jpeg и перекодировали его в webp, то почему на последней фотографии резкость у webp лучше, чем у jpeg? Их конвектер умеет вытягивать резкость? о_О
Да, я тоже заметил.
На 4-ой фотографии это хорошо видно (надо смотреть на кривые линии, на стрелках).
На 4-ой фотографии это хорошо видно (надо смотреть на кривые линии, на стрелках).
Этот комментарий должен был быть здесь.
интересно, Progressive Mode будет? хотелось бы…
А для анимации так и остаётся только формат gif. ((
Есть еще APNG, но он совсем совсем нестандартизирован.
Есть APNG, поддерживается Оперой и Фаерфоксом. Ну и тег видео никуда не делся.
До появления упомянутого APNG пытались MNG внедрить, но он к счастью благополучно не прижился.
Ещё не стоит забывать об SVG, который также неплохо справляется с анимацией.
Ещё не стоит забывать об SVG, который также неплохо справляется с анимацией.
Я в форматах изображения мало чего понимаю. Но как можно судить о качестве картинки, выкладывая ее на сайт, при условии, что браузер такой формат вообще не знает?
Зайдя на сайт и просмотрев свойства картинок увидел что слева jpeg размером в 10 раз меньше чем справа png, как вообще по такой ерунде можно судить?
Зайдя на сайт и просмотрев свойства картинок увидел что слева jpeg размером в 10 раз меньше чем справа png, как вообще по такой ерунде можно судить?
Ждем теста с тремя кадрами — оригинал, jpeg, webp.
Вот здесь я провел небольшое сравнение. Похоже, WebP действительно лучше JPEG, но в то же время свежеиспеченый формат хуже JPEG-XR, которому сто лет в обед и который стандартизирован везде где только можно
JPEG-XR, которому сто лет в обед и который стандартизирован везде где только можноСто лет в обед?
Спецификация JPEG-XR была окончательно подготовлена, утверждена и стандартизирована только в 2009 году. (напоминаю, сейчас 2010)
Везде, где только можно?
Поддержка его есть только в последних MS-продуктах, и в частности в бета версиях IE9. Ни один релизный браузер этот формат не поддерживает.
Take it easy, bro :-)
В данном случае я не настроен на холиворы, прошу прощения, если ненароком дал понять обратное.
Я имел в виду, что самому формату уже пять лет. Даже если WebP будет когда либо стандартизирован ISO/IEC и ITU-T, это займет те же пять лет. Мой посыл в том, что миру не нужен еще один формат, который к тому же хуже всего, что уже давно придумано и стандартизировано (но не используется).
Если JPEG 2000 лучше JPEG XR — пусть будет JPEG 2000, но зачем нужен WebP?
В данном случае я не настроен на холиворы, прошу прощения, если ненароком дал понять обратное.
Я имел в виду, что самому формату уже пять лет. Даже если WebP будет когда либо стандартизирован ISO/IEC и ITU-T, это займет те же пять лет. Мой посыл в том, что миру не нужен еще один формат, который к тому же хуже всего, что уже давно придумано и стандартизировано (но не используется).
Если JPEG 2000 лучше JPEG XR — пусть будет JPEG 2000, но зачем нужен WebP?
Что-то в галлерее у меня жипег загрузился моменталььно, а webp — раза в четыре дольше загружался
Давай Google, бери контроль над всей технологической базой Интернет. Спасибо что ты — не Microsoft! А если серьезно, что там еще осталось за чем не стоит наш Самый Большой Брат (СББ)?
Этих форматов как грязи, но из-за браузеров всё равно будем как идиоты сидеть на JPEG для фотографий и PNG 8/24 для дизайна с полупрозрачными элементами. Форматы новые и так есть, но где их поддержка...?
Правильно, тем более без поддержки в ie9(а уж если и в ie8, эх мечты, мечты) ждать широкого распространения формата не приходится.
Есть Google Chrome Frame. Можно не обращать внимания на IE, если заставить большинство таких юзеров использовать сей плагин.
Была бы поддержка — давно бы фотками в формате DJVU обменивались, который их жмёт раз в пять по сравнению с JPEG — а не на жалкие 40%.
Как обычно, комментарии от разработчика x264. Вкратце: формат неплохой, а вот кодировщик (в текущем виде) никуда не годится, ещё пилить и пилить.
А те jpeg-изображения, которые они (google) находили в сети, точно были сжаты с правильными параметрами?
А то может быть в этих файлах куча мета-информации осталась?
Не слишком ли поспешные выводы тогда?
Согласен с вышеотписавшимися, что ждем сравнение оригинал — jpeg — webP. При чем jpeg по всем правилам из оригинала компетентными в оптимизации изображений людьми…
А то может быть в этих файлах куча мета-информации осталась?
Не слишком ли поспешные выводы тогда?
Согласен с вышеотписавшимися, что ждем сравнение оригинал — jpeg — webP. При чем jpeg по всем правилам из оригинала компетентными в оптимизации изображений людьми…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
WebP, новый формат изображений для интернета