The OpenNET Project / Index page

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

В новой версии WebP появилась поддержка прозрачности и кодирования без потерь

18.11.2011 12:37

Компания Google представила обновлённый вариант формата для распространения изображений WebP. Используемые в WebP технологии сжатия с потерями позволяют добиться сокращения размера файла на 25%-34%, по сравнению с файлами JPEG аналогичного качества (по индексу SSIM). За год существования формата WebP разработчикам удалось устранить множество высказанных в процессе обсуждений замечаний. Например, в прошлом месяце была добавлена поддержка анимации, цветовых профилей ICC, тайлинга и метаданных XMP. Сегодня отмечено преодоление ещё двух важных рубежей: в WebP добавлена поддержка прозрачности (альфа-канал) и режима сжатия без потерь.

Отныне WebP может выступать полноценным аналогом не только формата JPEG, но и форматов PNG и GIF. Когда необходимо распространение фотографий WebP позволяет обеспечить максмальное сжатие с незаметной для глаза потерей качества. При необходимости сохранения изображений в неизменном виде, например, при распространении пиктограмм или скриншотов, теперь поддерживается режим с полным попиксельным сохранением целостности изображения. В обоих режимах возможно определение прозрачных областей и создание анимации.

По сравнению с максиамальным режимом сжатия формата PNG, WebP при сжатии без потери качества позволяет добиться сокращения размера на 28%. Средняя степень сжатия составляет 45%. Измерение проведено на основе перекодирования 1000 случайных PNG-файлов, найденных на просторах сети. Кроме высокой степени сжатия WebP в режиме без потери качества также обеспечивает более высокую скорость декодирования.

Что касается поддержки прозрачности, то в WebP удалось добиться минимизации добавления определяющей параметры альфа-канала дополнительной информации, что позволило существенно снизить размер итоговых изображений. При кодировании без потери качества, использование альфа-канала добавляет всего на 22% больше данных по сравнению с кодированием с потерей качества (уровень качества 90).

В настоящий момент поддержка WebP уже включена в состав браузеров Chrome и Opera. Представители Google работают над согласованием процесса интеграции поддержки WebP и в другие web-браузеры. Тем не менее, отмечается, что работа над спецификацией битового потока WebP ещё не завершена. С одной стороны, это позволяет продолжить работу по оптимизации и внесению улучшений, но с другой стороны сдерживает широкое распространение формата. Кроме того, реализация кодировщика и декодировщика ещё недостаточна оптимизирована с точки зрения производительности.

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

  1. Главная ссылка к новости (http://googlecode.blogspot.com...)
  2. OpenNews: Google начинает продвижение формата WebP в своих сервисах. Mozilla отказывается от поддержки WebP
  3. OpenNews: Для формата WebP представлен декодер на языке Java
  4. OpenNews: Разработчики кодека x264 резко критикуют формат WebP, предложенный Google
  5. OpenNews: Компания Google представила новый открытый формат изображений WebP
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/32342
Ключевые слова: , webp, image, png, jpeg
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (56) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, gegMOPO4 (ok), 13:57, 18/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как насчёт EXIF?
     
     
  • 2.4, letsmac (ok), 14:27, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • –2 +/
    XMP круче exif.
     
     
  • 3.19, Аноним (-), 16:28, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > XMP круче exif.

    Угу, XML-ное месиво в бинарном формате это круто: "ни два, ни полтора".

    Файл с таким тегом нельзя отредактировать текстовым редактором из-за бинарной части, но xml сложен и тормознут в парсинге "как обычно", в отличие от остальной части формата файла которая проста в парсинге как топор.

    Итого: предлагаю переименовать в Google Frankenstein File Format.

     
  • 2.5, Анончик (?), 14:32, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Поддержу предыдущего оратора:
    http://en.wikipedia.org/wiki/Extensible_Metadata_Platform
     
  • 2.6, lmgtfy (?), 14:44, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    зачем, если есть XMP
    http://en.wikipedia.org/wiki/Extensible_Metadata_Platform
    http://fototips.ru/digest/nemnogo-o-formate-xmp/
     
     
  • 3.21, Аноним (-), 16:39, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ага, мизерная libjpeg будет тащить монстра libxml.

    Круче этого, наверное, только если в файл встроить программу для виртуальной машины, которая будет возвращать метаданные. Хотя и то есть риск, что проще получится (и компактнее, кстати, компрессия статических данных на основе минимизации DFA зело хороша).

     
     
  • 4.24, Аноним (-), 17:29, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +7 +/
    MS уже допер впихивать в WMF/EMF машинный код для ускорения рендеринга в эпоху палеолита GDI. И забыли о фиче. А когда хакеры нашли фичу - срали кирпичами от счастья: прислал лоху картинку - троян сам запускается.
     
  • 4.35, R (?), 23:14, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ага, мизерная 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)

     
     
  • 5.57, Анон (?), 13:37, 21/11/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А дальше?

    >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]

     
  • 3.54, arisu (ok), 23:32, 20/11/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    xml? всю жизнь мечтали, ага. уносите, неоперабельно.
     

  • 1.2, Ваня (?), 14:12, 18/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    > Высокая плотность упаковки достигается благодаря использованию предсказательной техники кодирования ... что позволяет ограничиться хранением только различий между фактическими и предсказанными данными

    Дожили...

     
     
  • 2.11, total anon (?), 15:58, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А что в этом плохого? Например flac так же работает
     
     
  • 3.28, Ваня (?), 18:07, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Да не, просто представил как победителя битвы экстрасенсов приглашают в налоговую потому что компании ограничились передачей "только различий между фактическими и предсказанными данными" :)
     
  • 2.14, Аноним (-), 16:23, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Между опорными кадрами/сэмплами необходимо ещё проводить расчёт и промежуточных. Лучший, на данный момент, способ - та самая "предсказательная" техника. Не нравится - welcome to Dirac (http://ru.wikipedia.org/wiki/Dirac)! Даже при наличии малого количества опорных кадров все современные видекодеки не страдают "фантазией" при создании промежуточных, многочисленные тесты это подтвердили. Не бойтесь получить информацию, не существующую в реальности, отклонения от эталона настолько незначительны, что по сравнению с ними предвыборные речи политиков Вам покажутся фантастическим бредом...
     
  • 2.15, Аноним (-), 16:23, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Дожили...

    Если вы вдруг не знали, какое-то подобие дельта-кодирования кадров даже GIF-ом можно изобразить.

     
  • 2.38, XoRe (ok), 02:32, 19/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Высокая плотность упаковки достигается благодаря использованию предсказательной техники кодирования ... что позволяет ограничиться хранением только различий между фактическими и предсказанными данными
    > Дожили...

    А вы в курсе, что в многопользовательских игрушках (стрелялки, mmorpg) используется предсказательный подход в отношении перемещений.
    Т.е. если человек в текущие 10 мс бежит вперед, то предполагается, что в следующие 10 мс он будет так же бежать вперед.
    Это позволяет минимизировать сетевой трафик.

    P.S.
    мс - миллисекунды.

     
     
  • 3.40, Аноним (-), 05:48, 19/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Это позволяет минимизировать сетевой трафик.

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

     
  • 3.43, гамер (?), 08:41, 19/11/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Т.е. если человек в текущие 10 мс бежит вперед, то предполагается, что
    > в следующие 10 мс он будет так же бежать вперед.
    > Это позволяет минимизировать сетевой трафик.

    И красиво делать селффраг ракетницей о дверной проем, а также падать в обрыв с узких тропинок.

     
     
  • 4.47, Аноним (-), 14:43, 20/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > И красиво делать селффраг ракетницей о дверной проем, а также падать в
    > обрыв с узких тропинок.

    Лучше #@нуть ракетницей на узкой тропинке. Так чтобы сразу не убиться, но слететь в обрыв. Два в одном! Сразу получаете приз в номинации EPIC FAIL под гомерический гогот противников.

     

  • 1.3, gkv311 (ok), 14:21, 18/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > WebP в режиме без потери качества также обеспечивает
    > более высокую скорость декодирования

    Если правда - то действительно может стать вкуснее PNG.
    Текущая скорость декодирования PNG меня не слишком впечатляет...

     
     
  • 2.17, Аноним (-), 16:24, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Текущая скорость декодирования PNG меня не слишком впечатляет...

    Там простой zlib, чему там тормозить то? А вот в webp используется алгоритм сжатия I-кадров из vp8, т.е. куча DCT преобразований. Сомнительно что он так уж проще и быстрее нежели обычный zlib.

     

  • 1.7, FSA (ok), 15:17, 18/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Internet Explorer будет поддерживать?
     
     
  • 2.8, Аноним (-), 15:29, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Это вопрос к Microsoft.
     
     
  • 3.22, FSA (ok), 16:39, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Это вопрос к Microsoft.

    Хреновый ответ для тех, у кого есть ынтерпрайз проекты. У нас на работе корпоративный портал работает нормально только под IE8. На все претензии отвечают жёстко - сказали никаких других браузеров, значит никаких. Так что всё корпоративное можно открыть только строго в IE.

     
     
  • 4.23, Тот_Самый_Анонимус (?), 16:58, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >У нас на работе корпоративный портал работает нормально только под IE8

    Ну криворуки создатели портала, и что Вы этим хотели сказать?

    >На все претензии отвечают жёстко - сказали никаких других браузеров, значит никаких.

    Т.е. прямо признаются в криворукости.

     
     
  • 5.44, Square (ok), 11:40, 19/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Мне кажется что с пряморукостью у них все хорошо. А вот у вас - очень хреново с знанием матчасти и пониманием существа проблемы.

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

     
     
  • 6.45, Ищавин (?), 17:07, 19/11/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Иногда хорошее и правильное решение для программного архитектора это застрелиться.
     
     
  • 7.48, Аноним (-), 14:46, 20/11/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Иногда хорошее и правильное решение для программного архитектора это застрелиться.

    При том если он работает в MS это пожалуй единственное решение позволяющее сохранить свою репутацию как компетентного профессионала. Потому что лично я бы под тем булшитом который выпускает MS постеснялся бы светить свое имя. Все компетентные специалисты в отрасли будут показывать пальцами и говорить "смотрите, это ОН выпустил дерьмо кладущее на стандарты и состоящее из г0внокода чуть более чем полностью!"

     
  • 4.25, Аноним (-), 17:38, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Это вопрос к Microsoft.
    > Хреновый ответ для тех, у кого есть ынтерпрайз проекты.

    А ынтырпрайзы - тормозные, пусть сидят на своем ие6 если хотят, но вне интранетиков с некрофильчиками его доля будет 0.

     
  • 3.26, PereresusNeVlezaetBuggy (ok), 17:58, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Это вопрос к Microsoft.

    Можно и (открытый) плагин написать, в принципе.

     
     
  • 4.33, Xasd (ok), 19:03, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Это вопрос к Microsoft.
    > Можно и (открытый) плагин написать, в принципе.

    нуээээ плугин к IE -- уже написали ДАВНО :-) :-):

    http://google.com/chromeframe/

     
     
  • 5.34, PereresusNeVlezaetBuggy (ok), 19:04, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Это вопрос к Microsoft.
    >> Можно и (открытый) плагин написать, в принципе.
    > нуээээ плугин к IE -- уже написали ДАВНО :-) :-):
    > http://google.com/chromeframe/

    Ну или так, да :)))

     
  • 2.9, Аноним (-), 15:38, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Internet Explorer будет поддерживать?

    Проблемы негров шерифа не интересуют ©

     
  • 2.32, Xasd (ok), 19:02, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > 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 уже давно постарался на эту тему :-)

     

  • 1.10, Аноним (10), 15:41, 18/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Какие цветовые модели поддерживаются?
     
     
  • 2.16, Lain_13 (?), 16:24, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Если я правильно понял, то:
    VP8 works exclusively with an 8-bit YUV 4:2:0 image format.
     
     
  • 3.49, Аноним (-), 14:46, 20/11/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > VP8 works exclusively with an 8-bit YUV 4:2:0 image format.

    ...и это печально...

     

  • 1.12, Аноним (12), 16:10, 18/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В FF пока не поддерживается. Так что пока его использовать в Web невозможно.
     
     
  • 2.18, Lain_13 (?), 16:27, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Работа над спецификацией битового потока WebP ещё не завершена.

    О каком реальном использовании может вообще идти речь если они на битовом уровне могут поломать совместимось в следующей же версии спеки? В FF не принимают именно потому, что ещё слишком сыро.

     

  • 1.13, Аноним (-), 16:21, 18/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Остается вопрос как у него со скоростью кодирования-декодирования. А то png это обычный zlib и простой набор тегов похожий по смыслу на fourcc-чанки. Парсить просто и быстро, декомпрессить тоже. А тут и сжатие более сложное, и XML в тегах, etc.
     
     
  • 2.27, PereresusNeVlezaetBuggy (ok), 18:03, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Остается вопрос как у него со скоростью кодирования-декодирования. А то png это
    > обычный zlib и простой набор тегов похожий по смыслу на fourcc-чанки.
    > Парсить просто и быстро, декомпрессить тоже. А тут и сжатие более
    > сложное, и XML в тегах, etc.

    Ну, сложность алгоритма ещё не означает тормознутости. memcpy(3) только в образовательных целях реализуют через классическое:


    for (i=0; i<len; i++)
            dst[i] = src[i];


    А вот XML - это таки да, перебор. Хотя спасибо, что не модный JSON, конечно...

     
     
  • 3.29, красноглазик (?), 18:20, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А вот XML - это таки да, перебор. Хотя спасибо, что не модный JSON, конечно...

    А чем JSON хуже XML'а? Вроде меньше места занимает и легче парсится. Конечно, лучше было бы использовать какой-нибудь бинарный формат, но уже поздно :)

     
     
  • 4.31, PereresusNeVlezaetBuggy (ok), 19:00, 18/11/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> А вот XML - это таки да, перебор. Хотя спасибо, что не модный JSON, конечно...
    > А чем JSON хуже XML'а? Вроде меньше места занимает и легче парсится.
    > Конечно, лучше было бы использовать какой-нибудь бинарный формат, но уже поздно
    > :)

    Парсится он нифига не легче (если говорить про лексику и корректность и неоднозначность парсинга), возможностей на порядок меньше. Они оба неуместны здесь, ИМХО. binary encoding, использующийся в BitTorrent, ещё куда ни шло как хранилище, но возможностей ещё меньше, чем у JSON. Возможно, binary XML был бы хорош, файл-то всё равно бинарный... Правда, тогда grep'ать будет неудобно. :(

     
     
  • 5.46, Аноним (-), 14:38, 20/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > binary encoding, использующийся в BitTorrent, ещё куда ни шло как хранилище,
    > но возможностей ещё меньше, чем у JSON.

    1) В принципе, торрентовый кодинг может кодировать что угодно. Как и json. Ему пофиг.
    2) Но он еще более извратен - он полутекст и полубинарь. Тип данных и длина указаны как текст (не компактно) а сами данные могут быть свалены как попало, от текста до массива бинарных хешей. В результате это и не читаемо для человека и не очень удобно для парсинга машине. Еще один подвид кодирования данных в стиле "ни два, ни полтора".

     
     
  • 6.51, PereresusNeVlezaetBuggy (ok), 18:03, 20/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> binary encoding, использующийся в BitTorrent, ещё куда ни шло как хранилище,
    >> но возможностей ещё меньше, чем у JSON.
    > 1) В принципе, торрентовый кодинг может кодировать что угодно. Как и json.
    > Ему пофиг.
    > 2) Но он еще более извратен - он полутекст и полубинарь. Тип
    > данных и длина указаны как текст (не компактно) а сами данные
    > могут быть свалены как попало, от текста до массива бинарных хешей.
    > В результате это и не читаемо для человека и не очень
    > удобно для парсинга машине. Еще один подвид кодирования данных в стиле
    > "ни два, ни полтора".

    Он хотя бы длину каждого кодируемого объекта заранее указывает, и его можно эффектино проходить по нескольку раз вместо полного парсинга или построения дополнительного дерева, как в случае с XML и JSON.

    Насчёт длины данных: для наиболее актуальной ситуации вроде обсуждаемой в теме, BE даёт более компактное представление длины: большинство строк не превышают 9999 байт. ;) Числа менее 10^7 также представляются эффективно с точки зрения хранения, хотя тут возможны оговорки.

    Насчёт типа - опять же, для самого распространённого типа объектов ("строка"), если вспомните, он там специально не указывается вообще. ;)

    Насчёт же "как попало" - не совсем понятна претензия: а "не как попало" - это как? Данные идут последовательно, объекты не перекрываются. Нет индексации - это да. Но ведь мы и говорим о метаданных, которые сравнительно невелики по количеству полей. Потери CPU на перебор в памяти вполне окупается более компактной, эффективно проходимой повторно записью.

     
  • 5.52, Аноним (-), 19:49, 20/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Парсится он нифига не легче

    Лол што?

     
  • 4.41, Аноним (-), 05:51, 19/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Конечно, лучше было бы использовать какой-нибудь бинарный формат, но уже поздно :)

    Учтя что остальной кус формата бинарный - от XMLника в нем ни холодно ни жарко человекам, а машинам только лишние тормоза в парсинге да зависимость от еще пары жирных либ. Тогда как в бинарном формате слепить бесконечно расширяемый список параметров в стиле key=value ну совершенно не проблема, если уж свои велосипеды затеяли. Перегнать в него xml/exif/iptc тоже не проблема, опять же.

     
  • 4.58, VoDA (ok), 00:57, 22/11/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> А вот XML - это таки да, перебор. Хотя спасибо, что не модный JSON, конечно...
    > А чем JSON хуже XML'а? Вроде меньше места занимает и легче парсится.
    > Конечно, лучше было бы использовать какой-нибудь бинарный формат, но уже поздно
    > :)

    Отсутствуют стандартны типа контракта на описание что же внутри файла (XSL), способа выбора данных (XPath). Неймспейсы не очень удобно сделаны, но тоже нужны.

    Бинарный формат совсем зло - нет даже формального варианта (машинного теста) проверить очередную порцию данных на валидность.

    Пришел XML от другой подсистемы, запустил XSL. Если развалилось - все знают кто нарушил контракт. А с JSON?

    XML это формат обмена данными между системами/департаментами/компаниями с формальными описаниями правильных данных на уровне ТЗ.


    Как вы в ТЗ впишете в каком виде вы обязаны обработать JSON?

     
     
  • 5.59, VoDA (ok), 01:11, 22/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > 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: Я в тебя верю - смотри не подведи команду ;) *хлопая по плечу - лучше на малом обделаться, чем по крупному команду подставить*

     

  • 1.30, lucentcode (ok), 18:36, 18/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Надеюсь, через год-два данный формат станет стандартом индустрии. А то и JPG, и PNG имеют существенные недостатки. JPG - это плохое качество, отсутствие анимации и прозрачности. У PNG тоже своих проблем хватает, а GIF хоть и имеет прозрачность и анимацию, но как формат лет 30 как устарел. 256 цветов - это для Windows 3.x, а не для нормального ПО двадцать первого века. Удачи проекту. Я с удовольствием буду использовать данный формат.
     
  • 1.37, Аноним (-), 02:14, 19/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Получается вкусняшка... Но пока огнелисовцы ее не включат в свой браузер смысла юзать ее особого нет.
     
     
  • 2.42, Аноним (-), 05:53, 19/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Получается вкусняшка...

    Франкенштейн какой-то получается. Потому что сначала подумали ж-й, потом получив вагон критики кой-как донавесили костылей (по прежнему думая ж-й). И в результате получилось нечто. Не сильно лучше всех остальных, но геморнее в парсинге и требующее минимум 2 далеко не тривиальных алгоритма, как то декодек DCT из VP8 и здоровенный парсер XML если хочется читать теги.

     

  • 1.39, Аноним (-), 03:27, 19/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    В тоже время Google до сих пор поддержку APNG (анимированный PNG) так и не реализовал в своём браузере. Тьфу.
     
     
  • 2.50, Аноним (-), 14:48, 20/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > В тоже время Google до сих пор поддержку APNG (анимированный PNG) так
    > и не реализовал в своём браузере. Тьфу.

    А это еще один франкенштейн, только в чуть иной нише :). На самом деле идея не так уж плоха, но вот авторы стандарта на png уперлись рогом. Потому что у них есть свой MNG для анимации...

     

  • 1.53, arisu (ok), 23:29, 20/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    полноценный аналог png и gif, ага. lossy. полноценный. это переводчик настолько пылкую странную любовь к вебм, или автор оригинала?

    (задумчиво) а vorbis — полноценный аналог flac, ага.

    упс. протупил, не заметил там lossless.

     
     
  • 2.55, PereresusNeVlezaetBuggy (ok), 23:32, 20/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > полноценный аналог png и gif, ага. lossy. полноценный. это переводчик настолько пылкую
    > странную любовь к вебм, или автор оригинала?
    > (задумчиво) а vorbis — полноценный аналог flac, ага.

    А если новость читать полностью?

    "... в WebP добавлена поддержка прозрачности (альфа-канал) и режима сжатия без потерь"

     

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



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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