The OpenNET Project / Index page

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

Разработчики кодека x264 резко критикуют формат WebP, предложенный Google

01.10.2010 19:58

Основной разработчик проекта x264, в рамках которого ведется разработка высокопроизводительного H.264-кодировщика, представил в своем блоге технический анализ открытого сегодня компанией Google формата для хранения изображений WebP. Перевод данной заметки:

JPEG является очень старым форматом сжатия изображения с потерями качества. По сегодняшним меркам он ужасен с точки зрения силы сжатия: практически любой формат, предложенный с момента появления кодека MPEG-2, идёт на равных, а то и выигрывает у JPEG в его собственной игре. Причина, по которой люди не перешли на что-то более современное, обычно сводится к одному простому факту — переход не стоит затраченных усилий. Даже если бы появился формат, который сжимает изображение лучше JPEG в два раза, убедить весь мир перейти на него после двадцати лет использования последнего практически невозможно. Более того, сжатие по алгоритму JPEG быстрое, простое и практически гарантированно не содержит никаких патентов, о которых можно было бы беспокоиться. Свергнуть JPEG уже пытались неоднократно: сначала это был JPEG-2000, потом Microsoft JPEG XR. Ни один из них далеко не продвинулся.

Сейчас Google пытается заставить нас пользоваться ещё одним новым форматом - WebP. Но на самом деле WebP является частью межкадрового сжатия видеокодека VP8. С практической точки зрения у "нового" формата существуют несколько проблем, в сравнении со старым добрым JPEG: он не поддерживает все возможности JPEG, также не содержит тех возможностей, которых от JPEG все хотели, например, сжатия без потерь (сохранение неизменного качества). WebP поддерживает только выборку насыщенности цвета 4:2:0, тогда как JPEG поддерживает 4:2:2 и 4:4:4. Google, похоже, не заинтересована в этих возможностях.

Но давайте вернёмся к вопросу о том, насколько хорошо известные кодеки сжимают неподвижное изображение. В моём первом анализе VP8 я показал, что он поддерживает межкадровое предсказание, как и H.264, что является одной из причин эффективности сжатия. VP8 поддерживает матрицы только i4x4 и i16x16, что является недостатком по сравнению с H.264, который также поддерживает матрицы i8x8, однако VP8 близок по этому параметру.

Все результирующие файлы в нашем тестировании имеют размер приблизительно 155 Кб. Для всех трёх файлов я выполнил бинарный поиск уровней качества, чтобы сжать изображения до примерно одинакового размера. Например, для x264 я выбрал следующие параметры: "--tune stillimage --preset placebo". Для libvpx я использовал опцию "--best". JPEG изображение я получил с помощью ffmpeg, затем изображение было обработано утилитой jpgcrush для уменьшения размера файла (эта утилита перепаковывает JPEG для уменьшения размера без потерь в качестве). Я подозреваю, что в природе есть упаковщики лучше чем ffmpeg, тогда сами попробуйте провести этот тест и сообщите о ваших результатах. Исходное изображение (PNG) является двухсотым кадром видеоряда сцены Parkjoy, загрузить которое можно здесь.

Вот результаты сжатия x264, vp8 и jpg, сохранённые в PNG.

Нужно отметить, что результаты VP8 смущают — лично я думаю, что он показал себя хуже всех, даже несмотря на блочность изображения JPEG. Что же здесь происходит на самом деле? Кодирование энтропии у VP8 несомненно значительно лучше, чем у JPEG. VP8 содержит лучшее внутреннее предсказание (у JPEG есть только предсказание вида DC). Как так получилось, что VP выглядит хуже? Давайте это выясним.

VP8 использует трансформацию 4x4, которая приводит к замыливанию и потере в деталях по сравнению с преобразованием 8x8 у JPEG. Но этого недостатка самого по себе недостаточно, чтобы разница в качестве была столь существенной. Давайте проанализируем следующую гипотезу – что проблема кроется в том, что libvpx оптимизирует для PSNR и игнорирует психовизуальные критерии, когда кодирует изображение. Я закодирую изображение с параметром "--tune psnr --preset placebo" в x264, выключив все психовизуальные оптимизации.

Вот что получилось: x264, оптимизированный для PSNR, размер 154KB.

Какое размытие изображения! Слегка лучше, чем VP8, но всё равно хуже JPEG. И это используя тот же кодек и тот же уровень анализа, единственное что мы сделали иначе – это отказались от применения психовизуальных оптимизаций. Поэтому мы пришли к выводу, который я снова и снова повторяю в своём блоге – кодировщик значит больше, чем формат сжатия, и что хорошие психовизуальные оптимизации важны больше, чем что-либо ещё. Libvpx, гораздо более сильный кодировщик, чем JPEG в составе ffmpeg, проигрывает, потому что пытается слишком сильно оптимизировать для PSNR.

Эти результаты поднимают законный вопрос – сошли ли с ума представители Google? Я бы мог понять продвижение WebP, если бы он был лучше JPEG. И, конечно, учитывая достоинства оригинального кодека VP8, он мог бы быть лучше JPEG. Но заметьте, что я использую выражение "мог бы". Зачем анонсировать его сейчас, когда libvpx является таким отвратительным упаковщиком? Надо быть сумасшедшим, чтобы заменять JPEG на этот размытый шум. Я не говорю о том, чтобы libvpx пытался на равных конкурировать с x264, лучшим кодеком формата H.264 в мире, но, несомненно, он должен был бы победить кодек почти двадцатилетней давности, коим является JPEG, появившийся в 1992 году.

Мир компании Google: сначала сделайте хороший кодировщик, затем пытайтесь его пропагандировать как замену существующим форматам. В обратную сторону это не работает.

  1. Главная ссылка к новости (http://x264dev.multimedia.cx/?...)
  2. OpenNews: Компания Google представила новый открытый формат изображений WebP
  3. OpenNews: Компания Google перевела видеокодек VP8 в разряд свободных технологий
  4. OpenNews: Анализ эффективности работы видеокодека VP8
  5. OpenNews: Альтернативная реализация декодера VP8 обогнала по производительности код Google
Автор новости: Artem S. Tashkinov
Тип: Обобщение
Ключевые слова: webp, google, image
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (134) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, birdie (?), 20:09, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Если заметили неточности или проблемы со знаками препинания, пожалуйста, не поленитесь нажать на кнопку "исправить".

    Спасибо.

     
     
  • 2.2, vi (?), 21:01, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Захватывает!
     
     
  • 3.3, Аноним (-), 21:02, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Война, где война?
     
  • 2.61, filosofem (ok), 21:19, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Предлагаю в заголовке заменить слово "резко" на "эмоционально".
     

  • 1.4, Аноним (-), 21:05, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    отличная заметка ) читал как детектив
     
  • 1.5, mitiok (??), 21:08, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    гугль не знает утилиту jpgcrush  из текста
     
     
  • 2.13, Fcuku (ok), 22:19, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    http://akuvian.org/src/jpgcrush.tar.gz
     

  • 1.6, аноним (?), 21:09, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –16 +/
    Молодцы, по носу этим задротам-теоретикам из google. Там все поголовно в топкодерах и прочей ерунде участвуют, а как до практики доходит - получается какашка, но проталкивают её как революцию. "От великого google же!", а что google хорошего сделал? Только pagerank, хотя на самом деле это pagerank сделал google. Остальное - посредственный мусор, крутящийся на огромных вычислительных мощностях.
     
     
  • 2.28, szh (ok), 00:08, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Только pagerank, хотя на самом деле это pagerank сделал google.

    подтасовка детектед. Во второй половине предложения отрицается достижение гугл из первой.

    > а что google хорошего сделал?

    много чего.
    - лучший поисковик google.com
    - лучший онлайн мейлер gmail
    - chromium - а это
      a) новый ускоренный открытый движок js
      b) разработка улучшенного дезайна который бросились копировать остальные браузеры.
      с) новая концепция безопасных плагинов в браузере
      d) лучшая среди современных браузеров модель безопасности за счет изоляции
    - патчи в большое кол-во free open source software
    - google summer of code - миллионы долларов очень эффективно потрачены в развитие сотен свободных проектов.
    - купил за 100 миллионов долларов vp8 открыл его для свободного применения.
    - то что я сразу не вспомнил ...

     
     
  • 3.41, fr0ster (ok), 08:54, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Согласен с последними тремя пунктами, насчет первых сомнения.
    Лучший движок возможно, но вот некоторые вещи было проще найти в других поисковиках, теперь я стал проверять результаты поиска поиском в альтернативных искателях.
    Насчет онлайн мейлера ничего не скажу, практически не пользуюсь.
    Ну а хромиум, некоторые его вещи раздражают, а причин перейти на него с фокса у меня пока нет.
     
     
  • 4.49, szh (ok), 12:46, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну а хромиум, некоторые его вещи раздражают, а причин перейти на него с фокса у меня пока нет.

    перечисленные фичи хромиума теперь пилят и в фоксе, a) задает конкурентный темп, b) и c) вроде сделали в FF4, зачатки d) начиная с FF 3.6.6.

     
  • 3.53, vit1251 (ok), 13:58, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вы подождите Google наберет нормальных программистов или вырастит этих студентов и через 10-20 лет вы будете пользовать Chromium OS. А сейчас это просто первые попытки что-то сделать полезное и хорошее...

    P.S. Google достаточно молодая - не стоит ждать от нее слишком много...

     
     
  • 4.64, аноним (?), 01:20, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Вы подождите Google наберет нормальных программистов

    Хотите сказать, еще не набрал?

    > или вырастит этих студентов и через 10-20 лет вы будете пользовать Chromium OS.

    Гуглу уже 13 лет. С тех пор они только набирали теоретиков и ничего ценного так и не сделали.

    > А сейчас это просто первые попытки что-то сделать полезное и хорошее...

    Через 13 лет-то? Ну да.

    > P.S. Google достаточно молодая - не стоит ждать от нее слишком много...

    Ага. Подрастет - с их контролем над информацией станет на порядки хуже M$ и apple вместе взятых.

     
  • 3.63, аноним (?), 01:16, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Сейчас он ничем не лучше того же яндекса Только спама больше Ага, еще скажите ... текст свёрнут, показать
     
     
  • 4.74, GordiO (?), 09:08, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Вы так говорите того же яндекса будто бы он худший и представителей поиска А ... текст свёрнут, показать
     
     
  • 5.99, аноним (?), 22:27, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    того же потому что он ближе всего Есть другие региональные поисховики которые в... текст свёрнут, показать
     
  • 5.129, nuclight (ok), 19:07, 08/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ага, еще скажите "google сделал лучший поиск от google". Как и все онлайн мейлеры, gmail убог.
    > "Если не можешь сделать лучше - заткнись"

    Возражение говно. См. http://lurkmore.ru/Сперва_добейся

    Тем более, что Opera таки сделала свой M2, и сделала лучше, и сделала за 2 года до Gmail (еще и слизать умудрились в кастрированном виде).

     
  • 5.130, sgsgsgs (?), 19:14, 09/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >д) Хаха. Хахаха - я смеюсь Вам в лицо! Вы ошибаетесь. Что бы лучше увидеть скорости работы програм используйте слабое железо.

    С боьшинством коммента согласен, но с этим таки нет. На моем древнем Pentium 4 3.0 ghz Chromium нагружает процессор на 100% при загрузке любой более-менее наполненной страницы (Opennet к примеру), а вот Firefox грузит проц гораздо менее интенсивно, причем работая с такой же скоростью. GPU-ускорение у фокса лучше, видимо. Но я пока вынужден использовать Chromium, так как в фоксе ужасный рендеринг шрифтов с GPU-ускорением.

     
  • 4.92, Гентушник (ok), 07:33, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Вставив палки в колеса более продвинутому H.264.

    Вы так говорите как-будто это что-то плохое.

     
  • 3.114, User294 (ok), 00:13, 07/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >   d) лучшая среди современных браузеров модель безопасности за счет изоляции

    Угу. Только ресурсов жрет если 50 табов открыть что звиздец.

     
  • 3.128, nuclight (ok), 19:05, 08/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Да ну Яндекс по русскоязычным текстам до сих пор ищет лучше Среди веб-морд к п... текст свёрнут, показать
     

  • 1.7, Аноним (-), 21:11, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну всё понятно: пропиретарщики обсирают открытое. Не существует ничего, что лучше "везде", где-то будет лучше один формат, где-то другой.
     
     
  • 2.15, аноним (?), 22:28, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • –11 +/
    x264 - открытое ПО. libjpeg - открытое ПО. libvpx - открытое ПО. Где вам привидились проприетарщики?
     
     
  • 3.26, аноним (?), 23:54, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > x264 - открытое ПО. libjpeg - открытое ПО. libvpx - открытое ПО.
    > Где вам привидились проприетарщики?

    а плата за использование патентованных технологий, не?

     
     
  • 4.65, аноним (?), 01:20, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • –5 +/
    > а плата за использование патентованных технологий, не?

    Не.

     
  • 3.39, User294 (ok), 05:41, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > x264 - открытое ПО.

    Оно то открытое, но есть еще патенты и MPEG LA, к сожалению. Которые накладывают свои условия, крайне нехарактерные для свободного ПО. Поэтому по факту, свободой x264 можно пользоваться с уймой оговорок и потенциальных грабель. Вот и получается что свободное, но сильно избирательно. Не для всех, и не для любых применений. То есть, типичные цели свободного ПО в общем то и не достигнуты особо.

     
     
  • 4.100, аноним (?), 22:27, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Оно то открытое, но есть еще патенты и MPEG LA, к сожалению.

    Нету.

     
     
  • 5.115, User294 (ok), 00:16, 07/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Нету.

    Да щаз. Производители девайсов роялти за эти патенты только так платят. За весь мир, заметьте. Ну и ессно в цену их включили. Забыв у вас спросить вообще.

     
  • 5.131, sgsgsgs (?), 19:19, 09/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> Оно то открытое, но есть еще патенты и MPEG LA, к сожалению.
    > Нету.

    Кстати, вы мне, как юристу, хорошую мысль подкинули.

    Патенты на ПО действуют только в США. В России и других нормальных странах Европы (британские ученые не в счет) патентов на ПО нет. Следовательно, если я беру h.264, выпускаю на его основе продукт (называю его "r.264") под той же GPL, то, выходит, этот продукт живет самостоятельной жизнью отдельно от h.264 и его производители железа вполне могут его использовать в своих устройствах. А так как продукт произошел в России, где не действуют американские законы, то и в суд (в российский же суд) MPEG LA о нарушении патентов обратиться не сможет. Логично ведь получается? Интересно, насколько такая схема возможна на практике.

     

  • 1.8, oO (?), 21:29, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ну если по чесноку, то jpeg действительно давно пора выбросить.
     
     
  • 2.42, АнонимМ (?), 09:15, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    jpeg многих переживет.
     
     
  • 3.46, gkv311 (ok), 10:46, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Как и отвратительный mp3, увы...
     
     
  • 4.51, terr0rist (ok), 13:01, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сравнили ...
    МР3 - проприетарный лицензируемый формат, и да - кривой.
    JPEG - открытый нелицензируемый, и ничего кривого в нём нет. Ну да, нет поддержки альфа-канала, но - если бы она была (подумайте, как это технически реализовать) - это уже был бы не жпег, а кривой ПНГ с потерей качества.
    Так что не надо.
     
     
  • 5.80, Zenitur (?), 11:39, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    В первых предложениях текста, о том, что появись что-то хоть в 20 раз лучше jpeg, его использовать не будут, я увидел то, почему ogg и aac не подхватывают с энтузиазмом, а flac подхватывают. Платные сайты с легальной музыкой позволяют скачать песню в любом качестве в любимом формате, они flac конвертируют. Жду того же от бесплатных.
     

  • 1.9, mma (?), 21:47, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +12 +/
    а x264-devs хоть когонить хвалили? Вот когда похвалят вот тогда и будет новость. А пока выглядит что они дартаньяны а все остальные вокруг сами понимаете кто.
     
  • 1.10, User294 (ok), 21:49, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Было бы еще замечетельно, если бы эти крутые перцы придерживались принципа "критикуя - предлагай". Миру нужен формат, который:
    - Не обложен патентами как собака блохами и доступен для всех на одинаковых либеральных условиях.
    - Жмет лучше жпега при разумных затратах ресурсов.

    Они не хотят что-то такое предложить? А то критика конечно круто но пока они критикуют, по факту есть древний (но бесплатный) жпег, возможно-проблемный жпег2к, да обложенный патентами H.264 с массой ограничений.

     
     
  • 2.14, lava (?), 22:22, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    принцип критикуя - предлагай удачная зацепка для апологетов сначала добейся ... текст свёрнут, показать
     
     
  • 3.30, User294 (ok), 00:24, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > принцип "критикуя - предлагай" удачная зацепка для апологетов "сначала добейся".

    В принципе все так, если чисто формально. По факту - жпег уже не первый десяток лет юзается IIRC. Мпег4 не сильно моложе. И без конкуренции и наступания на пятки поперла откровенная такая стагнация. А всякие там MPEG LA в случае мпегов еще и наглеть нереально начали, пользуясь отсутствием конкуренции. Должен же кто-то был взорвать это унылое болото?

    > факты важней личностей.

    А, гм, где я личности обсуждал? Кстати факты могут подаваться под разным соусом, в зависимости от личностей. И почему-то разработчики x264 традиционно предпочитают выставлять факты под удобным для себя углом. По крайней мере, при сравнении VP8 vs H.264 они факты как-то очень так удачно подогнали под себя. Выпятив фичи уникальные для H.264 и задвинув фичи уникальные для VP8. Поэтому я бы не стал от них ожидать ровно 100% нейтральности и ну совсем уж непредвзятых фактов. У них есть свои проекты и поэтому им в лучшем случае досадно что фокус не на них. В хучшем - могут быть и шкурные интересы.

    > в статье подчёркнуто: jpeg не обложен патентами, в нём  есть штуки,
    > требования к которым формировались годами,

    Да, только половиной этих штук никто не пользуется. А самому жпегу лет так уже много и в общем то давно пора улучшить достигнутый результат, не? Или предлагается пару столетий не улучшать алгоритмы и даже не пытаться? :)

    > его реализации открыты, он лучше по качеству.

    Знаете, насчет "лучше по качеству" и ФАКТОВ - очень тонкий такой вопрос. Когда заходит вопрос о качестве lossy кодека - при попытке формализовать оценку оперируют весьма сомнительными моделями которые по большому счету показывают погоду на Марсе. Особенности работы человеческого мозга не очень сильно изучены, поэтому вы можете себе представить точность моделирования особенностей человеческого зрения и восприятия картинок имеющимися моделями. В итоге - используемые формальные пузомерки не очень сильно коррелируют с тем как оно будет увидено и воспринято живым человеком, для которого все это и затевается. Или же, при субъективной оценке на глаз - суждения очень субъективны. Например с фига ли фрукты из x264 считают размазывание хуже квадратиков? Квадратики лично я вижу сразу. А размытие... что размытие? Фотки сами по себе например зачастую не идеально резкие (за счет тряски или из-за особенностей фокусировки). На них вообще размытие никто не увидит толком. А вот квадратики - увидят запросто. Поэтому бряцая фактами не стоит забывать еще и о том откуда и как они взяты и какова их аккуратность. Ах да, стоит отдельно упомянуть как перцы из x264 сравнивали уже жатое мпегом видео в роли исходного материала. Ессно за счет одинаковых искажений мпег при втором сжатии себе подыгрывает, отличия от оригинала меньше получаются т.к. в оригинале уже были мпеговские искажения. А в тестах на compression.ru на не сжатом исходно материале VP8 почему-то выступил весьма и весьма: сырая реализация которой без году неделя взяла да и показала себя где-то на уровне mainline профиля H.264 по соотношению битрейт-качество. С фактами надо быть поаккуратнее. Особенно когда их предоставляют производители, разработчики и прочие заинтересованные лица.

    > этих фактов достаточно для критики,

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


    > исходи он хоть от слепого

    Слепой вообще не сможет сравнить картинки. Поэтому для него самый лучший кодек это /dev/null в который спущена картинка. Эффективность 100%ная, занимаемое место минимально.

     
     
  • 4.109, lava (?), 01:56, 05/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    давайте без демагогии, ок да это гипербола критикуя - предлагай - превый шаг... текст свёрнут, показать
     
  • 3.38, maximnik0 (?), 02:39, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >принцип "критикуя - предлагай" удачная зацепка для апологетов "сначала добейся". факты >важней личностей. в статье подчёркнуто: jpeg не обложен патентами, в нём есть штуки, >требования к которым формировались годами, его реализации открыты, он лучше по качеству. >этих фактов достаточно для критики, исходи он хоть от слепого

    Не совсем верная информация ,с jpeg тоже доили денежку только немного 3 года .Срок действия патентов где истек а где владельцы отказались  от патентов .

     
  • 3.95, Mikula (?), 13:37, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >принцип "критикуя - предлагай" удачная зацепка для апологетов "сначала добейся".

    "Критикуя предлагай"-конструктивный подход
    >"сначала добейся"

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

     
     
  • 4.108, lava (?), 01:33, 05/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >"Критикуя предлагай"-конструктивный подход

    нет, не конструктивный
    >Обыкновенное нытьё, так что сдемагожили Вы гражданин, сравнили ж.пу с пальцем.

    обыкновенный безграмотно изложенный выхлоп
    (и так можно до бесконечности продолжать, чувствуете, насколько эффективно необоснованное набрасывание?)

     
  • 2.17, аноним (?), 22:30, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • –6 +/
    > - Жмет лучше жпега при разумных затратах ресурсов.

    А смысл? Изображения уже можно и несжатые хранить, ни карточки ни винты ими уже не забъёшь.

     
     
  • 3.20, User294 (ok), 23:34, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Представляете себе сколько у вас будет грузиться опеннет если баннеры и лого сделать в нежатой графике? Особенно если канал не 100 мегабитный случайно оказался :). Записывать на диск или читать с него, слать по сети и хранить раз так в N больше при почти отсутствующей для глаза разнице - не прикольно. При том для жипега N порядка 5 запросто бывает без особых потерь качества. Я вижу некоторую разницу между отсылкой фоток 5 минут или получасом, если что. Так что нежатое (или lossless) изображение имеет смысл только когда надо идеальное качество любой ценой или предполагается активное редактирование например. Например к типичным фотографиям это не относится.
     
     
  • 4.43, АнонимМ (?), 09:23, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Представляете себе сколько у вас будет грузиться опеннет если баннеры и лого
    > сделать в нежатой графике? Особенно если канал не 100 мегабитный случайно

    Столько же сколько и сейчас. Посмотрите ресурсы данной страницы - на ней только один jpg, остальное gif & png. Даже банеры в гифе.

    jpeg нормальный формат его устарелость сильно преувеличена. Появится чего-нить real трехмерное, для real 3d мониторов тогда и нужна будет замена. А сейчас цепочка jpg, gif, png удовлетворяет на 99.99%.

     
     
  • 5.59, User294 (ok), 19:24, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы же предлагали несжатые форматы Ну, gif и png тоже сжатые Хотя и иным методо... текст свёрнут, показать
     
  • 4.67, аноним (?), 01:24, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Представляете себе сколько у вас будет грузиться опеннет если баннеры и лого
    > сделать в нежатой графике?

    Столько же, баннеры у меня заблокированы. Дальше.


    > оказался :). Записывать на диск или читать с него, слать по
    > сети и хранить раз так в N больше при почти отсутствующей
    > для глаза разнице - не прикольно.

    Отсутствует для глаза разница во времени передачи. Одна минута или две - в любом случае копейки.

    > что нежатое (или lossless) изображение имеет смысл только когда надо идеальное
    > качество любой ценой или предполагается активное редактирование например

    А сжатое нигде смысла не имеет.

     
     
  • 5.88, User294 (ok), 00:20, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Столько же, баннеры у меня заблокированы. Дальше.

    Ага. А фотки которые вы хотели послать - тоже блокировать? :)

    > Отсутствует для глаза разница во времени передачи. Одна минута или две -
    > в любом случае копейки.

    А как насчет разницей между 30 и 60 минут? А по факту скорее ближе к 10 vs 60 минут будет ;).

    > А сжатое нигде смысла не имеет.

    Звучит как разновидность "вы все пи...сы, а я - Д'Артаньян", уж извините. Аргументация примерно на том же уровне :)

     
     
  • 6.101, аноним (?), 22:30, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Ага. А фотки которые вы хотели послать - тоже блокировать? :)

    А про фотки я уже напиал - у меня даже raw'ки сливаются меньше минуты, крохоборствовать на компрессии смысла ноль.

    > А как насчет разницей между 30 и 60 минут? А по факту
    > скорее ближе к 10 vs 60 минут будет ;)

    У вас модем? Так проблема в модеме, а не в JPEG.

    > Звучит как разновидность "вы все пи...сы, а я - Д'Артаньян", уж извините.
    > Аргументация примерно на том же уровне :)

    Ну вы-то аргументировать даже не пытаетесь, так что пропущу это.

     
     
  • 7.116, User294 (ok), 00:39, 07/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Да ладно вам Сколько равок у вас за минуту сливается И по какому такому интерф... текст свёрнут, показать
     
  • 5.110, ig0r (??), 10:28, 05/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Сразу видно что вы не участвовали в разработке сайтов с загруженностью около 1 Гбит., тогда бы вы по другому заговорили.
     
  • 3.84, unscrubber (?), 20:59, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> - Жмет лучше жпега при разумных затратах ресурсов.
    > А смысл? Изображения уже можно и несжатые хранить, ни карточки ни винты
    > ими уже не забъёшь.

    какая дикая чушь, вы попробуйте хотя бы 15 мин несжатого 720p HD видео покрутите на своих сказочно-бездонных винтах а потом пишите что настало время хранить несжатое.

    да и к слову 720p уже не мейнстрим а так backward-compability имхо.
    FullHD кадр 1920x1080x24bit - 6075 килобайт как бы.

     
     
  • 4.86, Иван Иванович Иванов (?), 21:55, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Кино в полтора часа несжатое будет весить всего ничего ... 839 808 000 000 байт, т.е. почти 1TB.

    Подумаешь, на каждый фильм по новому винчестеру, зато качество идеальное и без потерь. :))))))))))

     
     
  • 5.89, User294 (ok), 00:23, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Подумаешь, на каждый фильм по новому винчестеру, зато качество идеальное и без
    > потерь. :))))))))))

    А еще, если по 6Мб на кадр, при 30 FPS мы получаем нужду читать какие-то жалкие 180 мегов в секунду с диска. Большая часть существующих в данный момент дисков попросту стушуется на таком потоке. Подумаешь, суперкачество будет дергаться когда винч не осилит столько выжать :).Ну хотя страйп из 3-4 дисков даже может попытаться. Если его другими задачами не занимать.Многозадачность же не нужна - доказано Эпплом ;)

     
     
  • 6.111, аноним (?), 03:38, 06/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Современные диски по одному все равно только дебилы используют, потому что они сыплются на раз, а зеркало 200 метров выдаст. Мой ZFS raid6 выдает 450 метров не напрягаясь.
     
     
  • 7.117, User294 (ok), 01:18, 07/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Да ничего они не сыпятся Где-то на том же уровне что и всегда Ну разве что есл... текст свёрнут, показать
     
  • 4.102, аноним (?), 22:31, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > какая дикая чушь, вы попробуйте хотя бы 15 мин несжатого 720p HD
    > видео покрутите на своих сказочно-бездонных винтах а потом пишите что настало
    > время хранить несжатое.

    Совсем допился, фотки от видео отличить не можешь?

     

  • 1.11, Аноним (-), 22:05, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    автору x264 прежде чем что то критиковать, следует сначала свой проект довести до ума
     
     
  • 2.12, lava (?), 22:17, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    нет, не следует. фактами важней авторитетов.
     
     
  • 3.23, Аноним (-), 23:43, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > нет, не следует. фактами важней авторитетов.

    доводить до стабильно рабочего состояния x264 не следует? а критиковать что то можно?

     
     
  • 4.27, lava (?), 23:56, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • –4 +/
    >> нет, не следует. фактами важней авторитетов.
    > доводить до стабильно рабочего состояния x264 не следует? а критиковать что то
    > можно?

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

     
  • 2.16, emg81 (?), 22:29, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    x264 недостаточно хорош? знаете что-то лучше?
     
     
  • 3.24, Аноним (-), 23:46, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > x264 недостаточно хорош? знаете что-то лучше?

    h264 достаточно хорош
    а вот реализация x264 на грани фантастики
    разве что одно только названия - "открытая реализация"
    а нормально ее даже поюзать нельзя, глюк на глюке, либо падает где то в ней
    либо хреново кодит/декодит

    скажем спасибо Intel IPP
    а то бы воип так и жил на глючных открытых реализациях

     
     
  • 4.32, User294 (ok), 00:40, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А в чем глючность реализации открытого Speex например Или там iLBC Нельзя ли п... текст свёрнут, показать
     
  • 2.18, аноним (?), 22:31, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > автору x264 прежде чем что то критиковать, следует сначала свой проект довести
    > до ума

    Что довести? И H.264 как кодек и x264 как реализация на голову обгоняют аналоги, в том числе убогие теору и webm.

     
     
  • 3.21, Аноним (-), 23:41, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    вы его активно пользуете?
    мне достаточно от x264 библиотеки нестабильности, автор никак ее до стабильно рабочего состояния довести не может

    ps я не против h264 как такового

     
     
  • 4.68, аноним (?), 01:25, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > вы его активно пользуете?

    Да.

    > мне достаточно от x264 библиотеки нестабильности, автор никак ее до стабильно рабочего
    > состояния довести не может

    Факты в студию.

     
  • 4.103, аноним (?), 22:33, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > вы его активно пользуете?

    Да.

    > мне достаточно от x264 библиотеки нестабильности, автор никак ее до стабильно рабочего
    > состояния довести не может

    Давайте список ваших багрепортов. Я лично что-то никаких проблем не замечал.

    > ps я не против h264 как такового

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

     
  • 3.22, User294 (ok), 23:41, 01/10/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Обгонять можно по разным параметрам Лицензии на патенты H 264 однозначно обгоня... текст свёрнут, показать
     
  • 3.36, Аноним123321 (ok), 01:15, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Что довести? И H.264 как кодек и x264 как реализация на голову
    > обгоняют аналоги, в том числе убогие теору и webm.

    если даже по 20 раз это повторять -- то это не обозначает что сказанное тобой окончательно правда..

    H.264 тормазит. так как формат сложен в проигрывании. Theora воспроизводит всё гладко не напрягая комп.

    другими словами:
    H.264-фильм (в не маленьком разрешении) посмотреть НЕ удаётся. а Theora-тотже-самый-фильм (в таком же разрешении) -- РАБОТАЕТ.
    теперь вопрос -- нахрена мне нужен H.264 в таком виде?

    предлагаешь мне купить новый комп? (да я бы с радостью... но боюсь что через время разрешения увеличатся опять вдвое, и H.264 как всегда будет сосать)

     
  • 3.73, Sergey (??), 08:50, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    числе убогие теору и webm. WEBM не убог, он просто не допилен. Кроме того он для веба а не для сжатия фильмов.
     
     
  • 4.104, аноним (?), 22:35, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > WEBM не убог, он просто не допилен.

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

    > Кроме того он для веба а не для сжатия фильмов.

    Что значит "для веба"? Какие критерии вебности он обеспечивает лучше H.264? Битрейт, качество, скорость? Никаких.

     
     
  • 5.118, User294 (ok), 01:22, 07/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Почитайте тех же небят из x264, если сами не понимаете как оно работает.

    Ну я почитал. Только ребята из х264 очень любят выставлять себя белыми и пушистыми, трактовать сомнительные ситуации в свою пользу и прочая. А если посмотреть на тесты нежатого исходного материала - так сырая версия VP8 почему-то оказалась на одном уровне с майнлайн профайлом x264. При том сколько *лет* писали x264, а сколько этому VP8 в открытом виде?

    >  Нечего там допиливать, лучше он уже не будет.

    После таких заяв возникает ощущение что вы сами то не читали даже парней из x264.

     

  • 1.19, аноним (?), 22:49, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Всем добро пожаловать в официальную группу WebP: https://groups.google.com/a/webmproject.org/group/webp-discuss/topics
     
  • 1.25, svchost (ok), 23:51, 01/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Кстати, замечаю, как в последнее время таки прекрасный PNG постепенно убивает флеш, тьфу, jpeg.
     
     
  • 2.29, Аноним (-), 00:23, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • –5 +/
    чем он лучше? в каких местах?
    каким образом он убивает?

    вы хотя бы раз конвертацией картинок(фото) занимались?

    я бы сказал что JPEG самый замечательный формат
    остальные нервно курят в сторонке

     
     
  • 3.35, Аноним123321 (ok), 01:09, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > чем он лучше? в каких местах?

    ясноже -- что реч идёт о Www!!

    (а не о фотоаппаратах)

    тут вся тема про Www... давайте не будем через-сообщение постоянно уточнять контекст, когда он очевидин :-)

     
  • 2.31, User294 (ok), 00:29, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Кстати, замечаю, как в последнее время таки прекрасный PNG постепенно убивает флеш, тьфу, jpeg.

    Только не в фотографиях. Фотографии zlib-овским сжатием жмутся никаковски, выигрыш в 2 раза - уже просто пипец какое счастье. Обычно все хуже. Повторяющихся пикселов там немного, да. Жпег с другой стороны может легко и гарантированно сжать раз чуть ли не в пять без особых отличий для глаза (придется долго колупаться с лупой чтобы при пристальном разглядывании изъяны узреть). В общем каждому свое. Жпег для фотоподобных картинок, png для строгой компьютерной графики. А вот скриншот окна программы в JPEG или фотка в PNG в общем то изврат. В общем не убьет микроскоп молотки, равно как и молотки не убьют микроскопы. Разные форматы для разных целей и с разными свойствами.

     
     
  • 3.75, Sergey (??), 09:16, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Можно сделать PNG PAQ сжатие - размер будет как у jpg оптимизация хаффмана 1 ... текст свёрнут, показать
     
     
  • 4.87, User294 (ok), 22:24, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ждать позеленеете с PAQ Реалистичнее было бы засунуть LZMA в PNG, имхо Но это ... текст свёрнут, показать
     
     
  • 5.113, Sergey (??), 20:12, 06/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Есть и по круче LZMA - FreeArc например А ждать пак не надо - уже сейчас есть д... текст свёрнут, показать
     
     
  • 6.119, User294 (ok), 03:16, 07/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    LZMA хорош в этом плане тем что у него довольно быстрая и не слишком ресурсожорк... текст свёрнут, показать
     
     
  • 7.125, Sergey (??), 08:10, 07/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Хватит гнать пургу с умным видом. свои слова о:

    "Только не в фотографиях. Фотографии zlib-овским сжатием жмутся никаковски, выигрыш в 2 раза - уже просто пипец какое счастье."

    Подтвердить можем?

     
  • 2.34, ЭМъ (?), 01:08, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Та он бы хоть окончательно победил GIF, не говоря уже о AnimatedGIF ... где APNG и MNG ?

    Первая версия спецификации MNG вышла 31 января 2001...Флеш оказался интереснее
    Потом мозиловцы придумали APNG в результате кое-кто не признал его форматом...поддерживает только Опера и ФФ .

    Я Вам так скажу все эти манипуляции с форматами, спецификациями

     
  • 2.60, Аноним (-), 20:19, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Где он его убивает? Разве что JPG стали жать не настолько, чтобы было явно видно артефакты.
     

  • 1.33, Аноним123321 (ok), 01:06, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Вот результаты сжатия [x264](ссылка), [vp8](ссылка) и [jpg](ссылка), сохранённые в PNG.

    опять они со своей унылой травой...

    но простите КАК я определю что x254 якобы _действительно_хорошо_ сжал картинку с травой, если я (как обычный человек) немогу отличить "траву" от "random-шума" ??!!!

     
     
  • 2.76, Sergey (??), 10:15, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> Вот результаты сжатия [x264](ссылка), [vp8](ссылка) и [jpg](ссылка), сохранённые в PNG.
    > опять они со своей унылой травой...

    Визуально VP8 лучше, незнаю чего они там гонят у x264 одни квадратики. Помоему они в своем фанатизме зашли слишком далеко.

     
     
  • 3.77, Sergey (??), 10:21, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Вот результаты сжатия [x264](ссылка), [vp8](ссылка) и [jpg](ссылка), сохранённые в PNG.
    >> опять они со своей унылой травой...
    > Визуально VP8 лучше, незнаю чего они там гонят у x264 одни квадратики.
    > Помоему они в своем фанатизме зашли слишком далеко.

    Просто перераспределен битрейд - с листвы там где квадраты на траву, а оптимизация по пснр - так это вообще не трагедия - поменять то.

     

  • 1.40, enot52 (ok), 06:03, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чем не устраивают существующие форматы? jpeg с минимальным сжатием для качественных фото, png для схем, текстов, скриншотов и еще более качественных фото.Все логично и удобно.


     
     
  • 2.105, аноним (?), 22:37, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Чем не устраивают существующие форматы? jpeg с минимальным сжатием для качественных фото,
    > png для схем, текстов, скриншотов и еще более качественных фото.Все логично
    > и удобно.

    Да всем всех устраивают. Google просто пукнул и сделал вид, что все парфюмеры мира теперь должны на него молиться. А ему просто по носу щёлкнули.

     

  • 1.44, аноним (?), 09:47, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Когда такое пишет человек из x264, к такому подходу нельзя относиться непредвзято. Ну в самом деле, почему именно разработчик x264 вдруг решил рассмотреть WebP? Что, из кучи других всем неинтересно? Ни на что не намекая, ИМХО.
     
     
  • 2.45, ram_scan (?), 10:34, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Разработчик x264 как минимум компетентен в вопросе. То есть акценты он может быть расставил и неправильно, как минимум расставил их опираясь на факты, а не просто так лужу газифицировал.
     
     
  • 3.85, unscrubber (?), 21:06, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > а не просто так лужу газифицировал.

    а вот и наоборот.

    ибо сравнивал бы лучше свой h.264 с тем же div-x например или прочим коммерческим кодеком.  
    просто почуяли угрозу и решили тут же нагадить конкурентам пока пипл не успел заинтересоватся.

     
     
  • 4.106, аноним (?), 22:39, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Divx давно стух, с чем его можно сравнивать? Разве что с теорой - там одна низшая лига. А про гугловские поделки все сказано по делу и правильно.
     
     
  • 5.120, User294 (ok), 03:18, 07/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Divx давно стух, с чем его можно сравнивать?

    Они обиделись на стухание и назвали своим форматом DivX plus. Который по факту внутрях matroska с H.264 и AAC :). Такая вот у них теперь тухлятина, давно известная и без них :)  

     

  • 1.47, StreSS.t (ok), 11:11, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Хм... а почему картинки указанные в новости с vp8 и jpeg примерно одинаковые а с x264 больше примерно на 20%. Это честное сравнение?
     
     
  • 2.48, Иван Иванович Иванов (?), 12:12, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У вас галюники?

    http://x264.nl/developers/Dark_Shikari/imagecoding/output.h264 = 157 446 bytes
    http://x264.nl/developers/Dark_Shikari/imagecoding/output.ivf  = 158 175 bytes
    http://x264.nl/developers/Dark_Shikari/imagecoding/output.jpg  = 159 674 bytes

     

  • 1.50, filosofem (ok), 12:53, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Just another Holywar Theme!

    Не понял, что эти комики доказать хотели. Точнее не понял как они хотят этими картинками доказать то, что у них в выводах написано.

    Без зума ни на jpeg ни на x264 смотреть невозможно, ибо выворачивает от обилия артефактов. На WebP вся лажа сглажена. Ну сделают возможность отключить сглаживание и будет выглядеть приблизительно как jpeg, только меньше по весу.

    Даже со всеми их ухищрениями и пережиманиями вывод напрашивается один: x264 не нужен, jpeg пускай пока живет, WebP выглядит перспективно.

     
     
  • 2.107, аноним (?), 23:36, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Just another Holywar Theme!

    Topic, а не Theme. Не знаете языка - не пишите, клоуном выглядите.

    > Без зума ни на jpeg ни на x264 смотреть невозможно, ибо выворачивает
    > от обилия артефактов. На WebP вся лажа сглажена. Ну сделают возможность
    > отключить сглаживание и будет выглядеть приблизительно как jpeg, только меньше по
    > весу

    Знаете, вы можете с тем же успехом заблюрить картинку на 4-8 пикселей, или в соответствующее к-во раз уменьшить разрешение - будет такая же "приятная для глаз" замыленность, и такая же кошмарная потеря качества, поэтому x264 рвет всех наголову - и в движении выглядит на порядок лучше члем webm'ское было, а на статчиной картинке делает даже незыблемый jpeg. А вам если приятно - используйте постпроцессинг.

     
     
  • 3.124, User294 (ok), 03:44, 07/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >а на статчиной картинке делает даже незыблемый jpeg.

    По-моему, на этих картинках жпег показал себя хуже всех...

    А так этот разработчик что-то привязался к одной сцене. Он на ней кодек оптимизировал? :)


     

  • 1.52, StreSS.t (ok), 13:06, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    http://x264.nl/developers/Dark_Shikari/imagecoding/x264.png - 3376686
    http://x264.nl/developers/Dark_Shikari/imagecoding/vp8.png - 2755332
    http://x264.nl/developers/Dark_Shikari/imagecoding/jpeg.png - 2657982

    Я про это

     
     
  • 2.54, Alex (??), 14:45, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Невооруженным глазом видно, что картинка в VP8 выглядит лучше.
     
     
  • 3.55, alfox (?), 17:10, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    а чтобы увидеть размерчик оденьте очки!
     
     
  • 4.56, alfox (?), 17:12, 02/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > а чтобы увидеть размерчик оденьте очки!

    сорри...
    /me пошел за очками


     
  • 3.123, User294 (ok), 03:35, 07/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Невооруженным глазом видно, что картинка в VP8 выглядит лучше.

    Там видно что:
    JPEG обосрался на листве и воде по полной. И зонты мерзко получились. По-моему, это самая хреновая из трех картинок (по заметности дефектов в разных частях картинки).
    VP8 как-то неубедительно показал себя на воде, не сильно обыграв там JPEG. Зато зонты удались и листва не сильно мерзкая. ИМХО лучше чем у других.  
    x264 в отместку отлично проработал воду (win!). Зато нагадил на листву и ну совсем слился на зонтах, там кошмар не лучше JPEG-а.

    Кто из них хуже? Выбирайте из трех отстоев тот который вам больше нравится, хаха :)

     
  • 2.78, Sergey (??), 10:50, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > http://x264.nl/developers/Dark_Shikari/imagecoding/x264.png - 3376686
    > http://x264.nl/developers/Dark_Shikari/imagecoding/vp8.png - 2755332
    > http://x264.nl/developers/Dark_Shikari/imagecoding/jpeg.png - 2657982
    > Я про это

    Это не важно так как пнг безпотерьный формат

     
  • 2.81, Иван Иванович Иванов (?), 12:46, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    как ты откроешь изображение в браузере в форматах VP8 и H264?

    Разработчик сохранил результат в PNG, чтобы ты мог сравнить картинки не выходя из браузера.

    Размеры PNG картинок абсолютно ничего не значат.

     

  • 1.57, Аноним (-), 17:35, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >>WebP поддерживает только выборку насыщенности цвета 4:2:0, тогда как JPEG поддерживает 4:2:2 и 4:4:4

    какое это имеет значение для www?

     
  • 1.58, iCat (ok), 17:40, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Непонятно.
    Появление jpeg - понятно.
    Появление WebP - понятно.
    Замена jpeg на WebP - непонятно.
    Поиски альтернативы ради альтернативы - спорт.
    Вот когда "уделают" JPEG "на голову" - тогда и будем менять.
     
     
  • 2.62, gogo (?), 00:39, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Все верно. Жизнь расставит все по местам.
    Будет новый формат удачный - будут использовать. Но никто никого никак не сможет заставить.
    Это не FAT, от которой хрен отвертишься...
     
     
  • 3.72, iCat (ok), 07:15, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Это не FAT, от которой хрен отвертишься...

    С чего бы это "хрен"?
    FS - прорва бездонная, и подходящих на смену FAT среди них не счесть.
    Ну, хотя бы ext2, udf,


     
     
  • 4.79, Sergey (??), 10:53, 03/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> Это не FAT, от которой хрен отвертишься...
    > С чего бы это "хрен"?
    > FS - прорва бездонная, и подходящих на смену FAT среди них не
    > счесть.
    > Ну, хотя бы ext2, udf,

    С того что все флешки на фат, а в удф винда не форматирует.

     
     
  • 5.91, iCat (ok), 05:49, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >все флешки на фат

    легко исправимо
    >в удф винда не форматирует

    в удф _только_ винда не форматирует
    И вообще были времена, когда считалось, что "640kB хватит всем и на всё", и FS было "по пальцам перечесть". А теперь-то - огогого! - прогесс! Одних "жипегов" нынче: JPEG, JPEG2000, PNG, GIF, теперь вот WebP добавится ;)

     
     
  • 6.112, Sergey (??), 19:45, 06/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>в удф винда не форматирует
    > в удф _только_ винда не форматирует

    винда держит 91% рынка пользовательских ОС - комментарии излишни.

    > И вообще были времена, когда считалось, что "640kB хватит всем и на
    > всё", и FS было "по пальцам перечесть". А теперь-то - огогого!
    > - прогесс! Одних "жипегов" нынче: JPEG, JPEG2000, PNG, GIF, теперь вот
    > WebP добавится ;)

    потерьный формат только 1 JPG в вебе.

     

  • 1.82, Ветоль Дычь (?), 17:12, 03/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    из трех вариантов vp8.png визуально воспринимается получше чем остальные...
     
  • 1.83, northbear (ok), 19:43, 03/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Аргументированный щелчок по носу Google. Мне тоже кажется, что у них по-тихоньку начинается мания величия. Ну, предложили и предложили новый формат изображений для Веба. Нет же, надо было обязательно выпендриться. Мол, замена JPEG. Ну и нарвались.
    Абсолютно согласен с Джейсоном в том, что кодировщик значит куда больше чем формат. vp8-кодер еще пилить и пилить. Думаю когда количество альтернативных кодировщиков VP8 станет сравнимо с количеством кодировщиков h.264. И они поконкурируют с друг другом годик-другой, тогда можно будет более-менее понять чего стоит VP8. А пока...

    Интересно было бы сравнить качество vp8-кодера с качеством первых релизов кодера x264. И с удовольствием бы выслушал комментарии команды x264. Уверен, что результаты были бы не в пользу x264.

     
  • 1.93, Аноним (-), 11:13, 04/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    изображение vp8 смотрится, на мой взгляд, лучше всех
     
     
  • 2.96, ызусефещк (?), 15:20, 04/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Сравните людей - у  вп8 все детали потеряны
     
     
  • 3.122, User294 (ok), 03:22, 07/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Сравните людей - у  вп8 все детали потеряны

    А жпег засрал все квадратиками на деревьях. И? Общий вывод знакомых юзеров: "обе картинки полное УГ!" :-)

     

  • 1.94, Аноним (-), 13:02, 04/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    да давайте webp, если людям понравится, как он работает, его будут пользовать, если нет то нет, зачем воздух то сотрясать?
     
  • 1.97, maxst (?), 15:39, 04/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Нашел фотку хорошего качества (не в jpeg, без артефактов), и сжал в WebP и Jpeg довольно сильно, примерно 40:1 чтобы явно было видно артефакты и там и там.

    Вот результат (вырезал из большой фотки кусочек и увеличил 300% чтобы лучше видно было):

    http://img155.imageshack.us/img155/2476/webpjpeg.png

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

     
     
  • 2.121, User294 (ok), 03:21, 07/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > http://img155.imageshack.us/img155/2476/webpjpeg.png
    > Видно, что алгоритмы разные, и артефакты разные. В одной части картинки лучше
    > webp, в другой jpeg...

    Во. Это уже похоже на правду :-). Вы видимо в отличие от разработчиков x264 не были заинтересованы в выигрыше той или иной кандидатуры :D

     
     
  • 3.126, maxst (?), 08:51, 07/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Оказывается, из h.264 тоже сделали отдельный формат для изображений, называется hipix:
    http://www.vizworld.com/2010/10/hipix-image-format-challenge-google-webp/
    Уже есть симпатичный конвертер. Тоже хочет конкурировать с JPEG.

    Попробовал на той же картинке, вот тот же кусок (вырезанный и увеличенный):
    http://img534.imageshack.us/img534/9370/hipix.png

    Видно, что страдает от тех же проблем, что и webp.
    Слабо-контрастные текстуры так же размывает в гладкий "пластик".
    Красные области - такой же ужас, как будто разрешение в 2 раза меньше стало.

    Чтобы скинуть JPEG с трона, надо быть на голову выше по всем параметрам,
    а так менять одни артефакты на другие - шило на мыло...

     
  • 2.133, Sergey (??), 22:47, 19/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати да - не честно сравнивать 8-bit WebP с 24-bit Jpeg, к тому же давно уже требуется 32-bit формат

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

     
     
  • 3.134, maxst (?), 11:59, 20/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Кстати да - не честно сравнивать 8-bit WebP с 24-bit Jpeg

    Ну во-первых не понимаю с чего вы взяли что этот WebP 8-битный.
    Насколько я знаю, 8-битных WebP вообще в природе не существует.
    А во-вторых, проблему с красными квадратиками гугловцы признали,
    когда я им пример послал. Пообещали исправить.

    > И пусть кто нибудь объяснит этим из x264 что раз они свой
    > формат не выкатили, то смысла размахивать x264 нет ни какого

    Выкатили. Формат называется Hipix.
    Но проблема с красными квадратиками там точно такая же.

     
     
  • 4.135, Sergey (??), 07:23, 21/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> Кстати да - не честно сравнивать 8-bit WebP с 24-bit Jpeg
    > Ну во-первых не понимаю с чего вы взяли что этот WebP 8-битный.

    Наверно я перепутал с 8-бит на канал?

    "WebP не работает в цветовом пространстве RGB, перед кодированием изображение переводится в YUV с глубиной 8 бит и форматом 4:2:0. Перевод осуществляется согласно стандарту ITU-R BT.601."

    Красные квадраты будут и в jpg если вы сохраните в 4:2:0 YV12 - это проблема не кодека как такового а цветового пространства.

     
     
  • 5.136, maxst (?), 09:19, 21/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Красные квадраты будут и в jpg если вы сохраните в 4:2:0 YV12
    > - это проблема не кодека как такового а цветового пространства.

    Пробовал, JPEG в 4:2:0 выглядит более размытым, не более того:
    http://img710.imageshack.us/img710/2196/santacompare2.png

    4:2:0 значит всего лишь, что кодер сохраняет цветовые компоненты с разрешением в 2 раза меньшим. Следовательно, декодер должен увеличить разрешение в два раза. Но каждый, кто увеличивал картинки знает, что интерполяция бывает разная: выберешь "по соседним пикселам" получишь квадратики, выберешь "билинейную" получишь размытие. И чаще всего размытие куда лучше квадратиков.

    То есть в данном случае явно наблюдаем, что JPEG'овский декодер интерполирует билинейно, а WebP'овский "по соседним пикселам".

    Вот читайте, сами гугловцы признают, что проблема именно в декодере:
    http://code.google.com/p/webp/issues/detail?id=14

     
     
  • 6.137, Sergey (??), 19:24, 21/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > 4:2:0 значит всего лишь, что кодер сохраняет цветовые компоненты с разрешением в
    > 2 раза меньшим. Следовательно, декодер должен увеличить разрешение в два раза.
    > Но каждый, кто увеличивал картинки знает, что интерполяция бывает разная: выберешь
    > "по соседним пикселам" получишь квадратики, выберешь "билинейную" получишь размытие.
    > И чаще всего размытие куда лучше квадратиков.
    > То есть в данном случае явно наблюдаем, что JPEG'овский декодер интерполирует билинейно,
    > а WebP'овский "по соседним пикселам".
    > Вот читайте, сами гугловцы признают, что проблема именно в декодере:
    > http://code.google.com/p/webp/issues/detail?id=14

    Чтож вы правы, я почему то всегда думал что это из-за то го что пишет: цветовое пространство RGB.

     
     
  • 7.138, maxst (?), 11:15, 22/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Гугловцы исправили декодер, больше нет квадратиков. WebP до и после:
    http://img833.imageshack.us/img833/4313/comparewebp.png

    Долго говорил с разработчиками Hipix насчет тех же самых квадратиков, убедить не удалось. Упорно отказываются видеть проблему.

    Итог: WebP в выигрыше.

     

  • 1.127, maxst (?), 10:19, 08/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот тут особенно заметны красные квадратики (оригинал и webp):

    http://img408.imageshack.us/img408/6503/santaorig.png
    http://img405.imageshack.us/img405/6784/santawebp90.png

    Гугловцы ответили, что из-за режима YUV420 цветовые компоненты кодируются с разрешением в два раза меньшим. Но chroma upsampling в декодере обещали улучшить.

     
  • 1.132, Stas (??), 14:44, 11/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сижу и откровенно смеюсь над тугими и жалкими попытками некоторых здешних "товарищей" всеми силами старающихся оклеветать "Google". Даже из самого названия "WebP" - любому здравомыслящему человеку становится сразу понятно, на что нацелен данный формат. Никто не претендует на технологию, которая перевернёт всё с ног на голову в формате изображений или заменит его в персональных устройствах! На профессиональном рынке фотографии царит чистый RAW-формат без сжатия и будет всегда там царить, в печатном деле и различных издательствах всегда будет главенствовать векторный формат и различные TIFF вариации, в 3D моделировании всегда будет свой собственный.

    Все без исключения согласны, что JPEG'у давно уже пора отправиться в мусорку, но всегда найдётся обделённый умом человек, который попытается всё обосрать и будет всеми силами стараться вставлять палки в колёса чужой колесницы! Если "Google" для начала хотя бы переведёт свой собственный "Google Earth" на новый уровень и на новый формат, то от этого только все выиграют. Лично я уже устал наблюдать одну и туже картину, каждый раз заходя на этот сервис - как у меня улетают по 200-300мб на морально устаревший по всем пунктам "jpg".

    Всем ребятам из Google - мега респектище и поддержка! За то, что не смотря ни на что - продолжают идти на встречу всему современному мировому обществу и обычным, развитым пользователям! Если кто-то, чем-то не доволен то, Вас - никто не заставляет этим пользоваться! Поэтому все завистники и недоброжелатели пускай молча истекают слюной и молча идут лесом, чтобы никого случаем не забрызгать!

     
  • 1.139, Аноним (139), 23:15, 23/10/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Старая статейка однако, он уже поддерживает сжатие без потерь. А википедия сюда ещё ссылается.
     
     
  • 2.140, Аноним (-), 11:52, 01/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Старая статейка однако, он уже поддерживает сжатие без потерь. А википедия сюда
    > ещё ссылается.

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

     

  • 1.141, 123581238512399124581249912488 (?), 15:11, 26/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот только что-то эти разработчики ничего не говорят про webp lossless. А он сжимает на 25-35% лучше PNG и практически так же как JPEG с максимальным качеством.
    Ну и плюс webp - это конечно же прозрачность и анимация. У JPEG просто нет этого.
    Webp заменяет сразу JPEG, GIF и PNG.
    Единственный его минус - это цвет 4:2:0 при сжатии с потерями.
     

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



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

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