Компания Google представила (http://googlecode.blogspot.com/2011/11/lossless-and-transpar...) обновлённый вариант формата для распространения изображений WebP (http://code.google.com/speed/webp/). Используемые в WebP технологии сжатия с потерями позволяют добиться сокращения размера файла на 25%-34% (http://code.google.com/speed/webp/docs/webp_study.html), по сравнению с файлами JPEG аналогичного качества (по индексу SSIM). За год существования формата WebP разработчиком удалось устранить множество высказанных в процессе обсуждений замечаний (http://www.opennet.me/opennews/art.shtml?num=28138). Например, в прошлом месяце была добавлена поддержка анимации, цветовых профилей ICC, тайлинга и XMP-метаданных. Сегодня отмечено преодоление ещё двух важных рубежей: в WebP добавлена поддержка прозрачности (альфа-канал) и режима сжатия без потерь.Отныне WebP может выступать полноценным аналогом не только формата JPEG, но и форматов PNG и GIF. Когда необходимо распростр...
URL: http://googlecode.blogspot.com/2011/11/lossless-and-transpar...
Новость: http://www.opennet.me/opennews/art.shtml?num=32342
Как насчёт EXIF?
XMP круче exif.
> XMP круче exif.Угу, XML-ное месиво в бинарном формате это круто: "ни два, ни полтора".
Файл с таким тегом нельзя отредактировать текстовым редактором из-за бинарной части, но xml сложен и тормознут в парсинге "как обычно", в отличие от остальной части формата файла которая проста в парсинге как топор.
Итого: предлагаю переименовать в Google Frankenstein File Format.
Поддержу предыдущего оратора:
http://en.wikipedia.org/wiki/Extensible_Metadata_Platform
зачем, если есть XMP
http://en.wikipedia.org/wiki/Extensible_Metadata_Platform
http://fototips.ru/digest/nemnogo-o-formate-xmp/
Ага, мизерная libjpeg будет тащить монстра libxml.Круче этого, наверное, только если в файл встроить программу для виртуальной машины, которая будет возвращать метаданные. Хотя и то есть риск, что проще получится (и компактнее, кстати, компрессия статических данных на основе минимизации DFA зело хороша).
MS уже допер впихивать в WMF/EMF машинный код для ускорения рендеринга в эпоху палеолита GDI. И забыли о фиче. А когда хакеры нашли фичу - срали кирпичами от счастья: прислал лоху картинку - троян сам запускается.
> Ага, мизерная libjpeg будет тащить монстра libxml.
> Круче этого, наверное, только если в файл...Круче этого только вот это:
[cite]
Adobe has a trademark on XMP, and retains control over the specification.Initially, Adobe released source code for the XMP SDK under a license called the ADOBE SYSTEMS INCORPORATED — OPEN SOURCE LICENSE. The compatibility of this license with the GNU General Public License has been questioned. The license is not listed on the list maintained by the Open Source Initiative and is different from the licenses for most of their open source software.[/cite](http://en.wikipedia.org/wiki/Extensible_Metadata_Platform)
А дальше?>On May 14, 2007, Adobe released the XMP Toolkit SDK under a standard BSD license.[3]
>On August 28, 2008, Adobe posted a public patent license for the XMP specification.[4]
xml? всю жизнь мечтали, ага. уносите, неоперабельно.
> Высокая плотность упаковки достигается благодаря использованию предсказательной техники кодирования ... что позволяет ограничиться хранением только различий между фактическими и предсказанными даннымиДожили...
А что в этом плохого? Например flac так же работает
Да не, просто представил как победителя битвы экстрасенсов приглашают в налоговую потому что компании ограничились передачей "только различий между фактическими и предсказанными данными" :)
Между опорными кадрами/сэмплами необходимо ещё проводить расчёт и промежуточных. Лучший, на данный момент, способ - та самая "предсказательная" техника. Не нравится - welcome to Dirac (http://ru.wikipedia.org/wiki/Dirac)! Даже при наличии малого количества опорных кадров все современные видекодеки не страдают "фантазией" при создании промежуточных, многочисленные тесты это подтвердили. Не бойтесь получить информацию, не существующую в реальности, отклонения от эталона настолько незначительны, что по сравнению с ними предвыборные речи политиков Вам покажутся фантастическим бредом...
> Дожили...Если вы вдруг не знали, какое-то подобие дельта-кодирования кадров даже GIF-ом можно изобразить.
>> Высокая плотность упаковки достигается благодаря использованию предсказательной техники кодирования ... что позволяет ограничиться хранением только различий между фактическими и предсказанными данными
> Дожили...А вы в курсе, что в многопользовательских игрушках (стрелялки, mmorpg) используется предсказательный подход в отношении перемещений.
Т.е. если человек в текущие 10 мс бежит вперед, то предполагается, что в следующие 10 мс он будет так же бежать вперед.
Это позволяет минимизировать сетевой трафик.P.S.
мс - миллисекунды.
> Это позволяет минимизировать сетевой трафик.А в случае картинок передача только дельты между кадрами и размер файла уменьшает и меньше насилует декодер, т.к. надо раскодировать данные. В общем то сплошные плюсы. Из минусов разве что небольшое усложнение кодера который должен отлавливать различия между кадрами и кодировать только их.
> Т.е. если человек в текущие 10 мс бежит вперед, то предполагается, что
> в следующие 10 мс он будет так же бежать вперед.
> Это позволяет минимизировать сетевой трафик.И красиво делать селффраг ракетницей о дверной проем, а также падать в обрыв с узких тропинок.
> И красиво делать селффраг ракетницей о дверной проем, а также падать в
> обрыв с узких тропинок.Лучше #@нуть ракетницей на узкой тропинке. Так чтобы сразу не убиться, но слететь в обрыв. Два в одном! Сразу получаете приз в номинации EPIC FAIL под гомерический гогот противников.
> WebP в режиме без потери качества также обеспечивает
> более высокую скорость декодированияЕсли правда - то действительно может стать вкуснее PNG.
Текущая скорость декодирования PNG меня не слишком впечатляет...
> Текущая скорость декодирования PNG меня не слишком впечатляет...Там простой zlib, чему там тормозить то? А вот в webp используется алгоритм сжатия I-кадров из vp8, т.е. куча DCT преобразований. Сомнительно что он так уж проще и быстрее нежели обычный zlib.
Internet Explorer будет поддерживать?
Это вопрос к Microsoft.
> Это вопрос к Microsoft.Хреновый ответ для тех, у кого есть ынтерпрайз проекты. У нас на работе корпоративный портал работает нормально только под IE8. На все претензии отвечают жёстко - сказали никаких других браузеров, значит никаких. Так что всё корпоративное можно открыть только строго в IE.
>У нас на работе корпоративный портал работает нормально только под IE8Ну криворуки создатели портала, и что Вы этим хотели сказать?
>На все претензии отвечают жёстко - сказали никаких других браузеров, значит никаких.
Т.е. прямо признаются в криворукости.
Мне кажется что с пряморукостью у них все хорошо. А вот у вас - очень хреново с знанием матчасти и пониманием существа проблемы.решение для корпоративной среды - должно обладать рядом характеристик, к которым поддержка
зоопарка из множества браузеров не относится.
И это хорошее и правильное решение.
Иногда хорошее и правильное решение для программного архитектора это застрелиться.
> Иногда хорошее и правильное решение для программного архитектора это застрелиться.При том если он работает в MS это пожалуй единственное решение позволяющее сохранить свою репутацию как компетентного профессионала. Потому что лично я бы под тем булшитом который выпускает MS постеснялся бы светить свое имя. Все компетентные специалисты в отрасли будут показывать пальцами и говорить "смотрите, это ОН выпустил дерьмо кладущее на стандарты и состоящее из г0внокода чуть более чем полностью!"
>> Это вопрос к Microsoft.
> Хреновый ответ для тех, у кого есть ынтерпрайз проекты.А ынтырпрайзы - тормозные, пусть сидят на своем ие6 если хотят, но вне интранетиков с некрофильчиками его доля будет 0.
> Это вопрос к Microsoft.Можно и (открытый) плагин написать, в принципе.
>> Это вопрос к Microsoft.
> Можно и (открытый) плагин написать, в принципе.нуээээ плугин к IE -- уже написали ДАВНО :-) :-):
>>> Это вопрос к Microsoft.
>> Можно и (открытый) плагин написать, в принципе.
> нуээээ плугин к IE -- уже написали ДАВНО :-) :-):
> http://google.com/chromeframe/Ну или так, да :)))
> Internet Explorer будет поддерживать?Проблемы негров шерифа не интересуют ©
> Internet Explorer будет поддерживать?как обычно ДА -- начиная с версии 6.0 :-) ...
...достаточно только сделать два действия:
1.
прописать HTTP-заголовок в www-сайт:
X-UA-Compatible: chrome=1
(<meta http-equiv="X-UA-Compatible" content="chrome=1"> -- если внутрь <head>)2.
попросить IE-пользовтеля установить требуещиеся плугины (точно также как это просит Adobe Flash Player) в слуае если обнаруживается что на сайт защёл IE-пользователь :-D...
вобщем Google уже давно постарался на эту тему :-)
Какие цветовые модели поддерживаются?
Если я правильно понял, то:
VP8 works exclusively with an 8-bit YUV 4:2:0 image format.
> VP8 works exclusively with an 8-bit YUV 4:2:0 image format....и это печально...
В FF пока не поддерживается. Так что пока его использовать в Web невозможно.
> Работа над спецификацией битового потока WebP ещё не завершена.О каком реальном использовании может вообще идти речь если они на битовом уровне могут поломать совместимось в следующей же версии спеки? В FF не принимают именно потому, что ещё слишком сыро.
Остается вопрос как у него со скоростью кодирования-декодирования. А то png это обычный zlib и простой набор тегов похожий по смыслу на fourcc-чанки. Парсить просто и быстро, декомпрессить тоже. А тут и сжатие более сложное, и XML в тегах, etc.
> Остается вопрос как у него со скоростью кодирования-декодирования. А то png это
> обычный zlib и простой набор тегов похожий по смыслу на fourcc-чанки.
> Парсить просто и быстро, декомпрессить тоже. А тут и сжатие более
> сложное, и XML в тегах, etc.Ну, сложность алгоритма ещё не означает тормознутости. memcpy(3) только в образовательных целях реализуют через классическое:
for (i=0; i<len; i++)
dst[i] = src[i];
А вот XML - это таки да, перебор. Хотя спасибо, что не модный JSON, конечно...
> А вот XML - это таки да, перебор. Хотя спасибо, что не модный JSON, конечно...А чем JSON хуже XML'а? Вроде меньше места занимает и легче парсится. Конечно, лучше было бы использовать какой-нибудь бинарный формат, но уже поздно :)
>> А вот XML - это таки да, перебор. Хотя спасибо, что не модный JSON, конечно...
> А чем JSON хуже XML'а? Вроде меньше места занимает и легче парсится.
> Конечно, лучше было бы использовать какой-нибудь бинарный формат, но уже поздно
> :)Парсится он нифига не легче (если говорить про лексику и корректность и неоднозначность парсинга), возможностей на порядок меньше. Они оба неуместны здесь, ИМХО. binary encoding, использующийся в BitTorrent, ещё куда ни шло как хранилище, но возможностей ещё меньше, чем у JSON. Возможно, binary XML был бы хорош, файл-то всё равно бинарный... Правда, тогда grep'ать будет неудобно. :(
> binary encoding, использующийся в BitTorrent, ещё куда ни шло как хранилище,
> но возможностей ещё меньше, чем у JSON.1) В принципе, торрентовый кодинг может кодировать что угодно. Как и json. Ему пофиг.
2) Но он еще более извратен - он полутекст и полубинарь. Тип данных и длина указаны как текст (не компактно) а сами данные могут быть свалены как попало, от текста до массива бинарных хешей. В результате это и не читаемо для человека и не очень удобно для парсинга машине. Еще один подвид кодирования данных в стиле "ни два, ни полтора".
>> binary encoding, использующийся в BitTorrent, ещё куда ни шло как хранилище,
>> но возможностей ещё меньше, чем у JSON.
> 1) В принципе, торрентовый кодинг может кодировать что угодно. Как и json.
> Ему пофиг.
> 2) Но он еще более извратен - он полутекст и полубинарь. Тип
> данных и длина указаны как текст (не компактно) а сами данные
> могут быть свалены как попало, от текста до массива бинарных хешей.
> В результате это и не читаемо для человека и не очень
> удобно для парсинга машине. Еще один подвид кодирования данных в стиле
> "ни два, ни полтора".Он хотя бы длину каждого кодируемого объекта заранее указывает, и его можно эффектино проходить по нескольку раз вместо полного парсинга или построения дополнительного дерева, как в случае с XML и JSON.
Насчёт длины данных: для наиболее актуальной ситуации вроде обсуждаемой в теме, BE даёт более компактное представление длины: большинство строк не превышают 9999 байт. ;) Числа менее 10^7 также представляются эффективно с точки зрения хранения, хотя тут возможны оговорки.
Насчёт типа - опять же, для самого распространённого типа объектов ("строка"), если вспомните, он там специально не указывается вообще. ;)
Насчёт же "как попало" - не совсем понятна претензия: а "не как попало" - это как? Данные идут последовательно, объекты не перекрываются. Нет индексации - это да. Но ведь мы и говорим о метаданных, которые сравнительно невелики по количеству полей. Потери CPU на перебор в памяти вполне окупается более компактной, эффективно проходимой повторно записью.
>Парсится он нифига не легчеЛол што?
> Конечно, лучше было бы использовать какой-нибудь бинарный формат, но уже поздно :)Учтя что остальной кус формата бинарный - от XMLника в нем ни холодно ни жарко человекам, а машинам только лишние тормоза в парсинге да зависимость от еще пары жирных либ. Тогда как в бинарном формате слепить бесконечно расширяемый список параметров в стиле key=value ну совершенно не проблема, если уж свои велосипеды затеяли. Перегнать в него xml/exif/iptc тоже не проблема, опять же.
>> А вот XML - это таки да, перебор. Хотя спасибо, что не модный JSON, конечно...
> А чем JSON хуже XML'а? Вроде меньше места занимает и легче парсится.
> Конечно, лучше было бы использовать какой-нибудь бинарный формат, но уже поздно
> :)Отсутствуют стандартны типа контракта на описание что же внутри файла (XSL), способа выбора данных (XPath). Неймспейсы не очень удобно сделаны, но тоже нужны.
Бинарный формат совсем зло - нет даже формального варианта (машинного теста) проверить очередную порцию данных на валидность.
Пришел XML от другой подсистемы, запустил XSL. Если развалилось - все знают кто нарушил контракт. А с JSON?
XML это формат обмена данными между системами/департаментами/компаниями с формальными описаниями правильных данных на уровне ТЗ.
Как вы в ТЗ впишете в каком виде вы обязаны обработать JSON?
> XML это формат обмена данными между системами/департаментами/компаниями с формальными
> описаниями правильных данных на уровне ТЗ.
> Как вы в ТЗ впишете в каком виде вы обязаны обработать JSON?отсутствие подобия XSL приложенного к JSON в ТЗ может вылести в феерию:
Заказчик (з): Вот мы подправили новый формат, ловите [date:"22 11 2011 +3",birthday:[day:22,month:11,year:2011,city:Moskov]],[date:"22 11 2011 MSK",birthday:"2011 11 22 00:00 GMT+5"]]
Менеджер проекта (PM): ну кто клялся и божился, что JSON лучший формат обмена данными?
Есть ли формальный повод проверить этот JSON и признать его не подходящим по ТЗ... нет... у...
Значит в качестве первого предупреждения умный последователь JSON остается без квартальной премии и пишет систему взаимодействия с заказчиками самостоятельно УКЛАДЫВАЯСЬ в собственный график эстимаций.колуарно
PM: Я же предупреждал
Dev: Да :(
PM: Я в тебя верю - смотри не подведи команду ;) *хлопая по плечу - лучше на малом обделаться, чем по крупному команду подставить*
Надеюсь, через год-два данный формат станет стандартом индустрии. А то и JPG, и PNG имеют существенные недостатки. JPG - это плохое качество, отсутствие анимации и прозрачности. У PNG тоже своих проблем хватает, а GIF хоть и имеет прозрачность и анимацию, но как формат лет 30 как устарел. 256 цветов - это для Windows 3.x, а не для нормального ПО двадцать первого века. Удачи проекту. Я с удовольствием буду использовать данный формат.
Получается вкусняшка... Но пока огнелисовцы ее не включат в свой браузер смысла юзать ее особого нет.
> Получается вкусняшка...Франкенштейн какой-то получается. Потому что сначала подумали ж-й, потом получив вагон критики кой-как донавесили костылей (по прежнему думая ж-й). И в результате получилось нечто. Не сильно лучше всех остальных, но геморнее в парсинге и требующее минимум 2 далеко не тривиальных алгоритма, как то декодек DCT из VP8 и здоровенный парсер XML если хочется читать теги.
В тоже время Google до сих пор поддержку APNG (анимированный PNG) так и не реализовал в своём браузере. Тьфу.
> В тоже время Google до сих пор поддержку APNG (анимированный PNG) так
> и не реализовал в своём браузере. Тьфу.А это еще один франкенштейн, только в чуть иной нише :). На самом деле идея не так уж плоха, но вот авторы стандарта на png уперлись рогом. Потому что у них есть свой MNG для анимации...
полноценный аналог png и gif, ага. lossy. полноценный. это переводчик настолько пылкую странную любовь к вебм, или автор оригинала?(задумчиво) а vorbis — полноценный аналог flac, ага.
упс. протупил, не заметил там lossless.
> полноценный аналог png и gif, ага. lossy. полноценный. это переводчик настолько пылкую
> странную любовь к вебм, или автор оригинала?
> (задумчиво) а vorbis — полноценный аналог flac, ага.А если новость читать полностью?
"... в WebP добавлена поддержка прозрачности (альфа-канал) и режима сжатия без потерь"