Пользователь
1,2
рейтинг
1 октября 2010 в 03:53

WebP, новый формат изображений для интернета перевод

В рамках инициативы компании Google, заключающейся в том, чтобы сделать интернет более быстрым, в течении прошедших месяцев мы выпустили целый набор инструментов, призванных помочь владельцам сайтов их ускорить. Мы запустили расширение для Firefox под названием Page Speed, позволяющее изучать производительность веб страниц, а также получать предложения о том, как её увеличить. Мы представили Speed Tracer, расширение для Chrome, позволяющее найти и исправить проблемы с производительностью в веб приложениях. Кроме того, мы выпустили набор инструментов для завершающей стадии разработки (closure tools), призванный помочь создавать сложные веб приложения с польностью оптимизированным javascript-кодом. В то время, как эти инструменты были невероятно успешны, помогая разработчикам оптимизировать их сайты, мы продолжали работу, и нам удалось обнаружить единственный компонент веб страниц, который полностью ответственнен за большинство задержек на страницах: изображения.

Большая часть распространенных форматов изображений, используемых в сети, были созданы более 10 лет назад и основаны на технологиях того времени. Инженеры из Google решили проверить: нет ли способа увеличить степень сжатия алгоритмов сжатия с потерями (как JPEG), чтобы позволить изображениям загружаться быстрее, при этом полностью сохраняя их разрешение и визуальное качество. В результате работы на этим проектом мы выпускаем новый формат изображений, WebP, в предварительной версии для разработчиков. Этот формат обещает существенно уменьшить бинарный размер фотографий в сети, позволяя сайтам загружаться быстрее, чем раньше.

На сегодняшний день, изображения и фотографии составляют около 65% всех данных, составляющих веб страницу. Они могут существенно замедлить работу в сети, особенно в сетях с ограниченным трафиком, таких как мобильные сети. Большую часть изображений в сети составляют форматы сжатия с потерями (такие как JPEG), меньшую — форматы с сжатием без потерь (такие как GIF и PNG). Наша команда сконцентрировалась на улучшении сжатия с потерями, так как на сегодняшний день именно изображения в таких форматах составляют большую часть всех изображений в сети.

Чтобы улучшить степень сжатия, которую предлагает формат JPEG, мы использовали алгоритм, основанный на используемом в кодеке VP8, исходные коды которого были открыты компанией Google в мае 2010 года. Мы применили технологии, используемые в VP8 для сжатия промежуточных кадров, для сжатия статичных изображений. Кроме того, мы использовали очень компактный формат файла-контейнера, основанный на формате RIFF: несмотря на то, что этот формат добавляет всего 20 байт к каждому изображению, он является расширяемым, что позволяет авторам сохранять в файле любые необходимые метаданные.

Хотя преимущества формата изображений, основанного на VP8, теоретически очевидны, нужно было проверить их в условиях реального мира. Чтобы оценить эффективность наших усилий, мы выбрали около миллиона случайных изображений из сети (преимущественно JPEG, а также немного PNG и GIF) и перекодировали их в WebP, сохраняя их визуальное качество. Такое перекодирование привело к сокращению размера файлов на 39% (видимо, имелось в виду, в среднем. прим. перев). Мы рассчитываем, что разработчики добьются с форматом WebP еще большего сжатия, сжимая изображения, которые изначально не были сжатыми.

Чтобы помочь вам оценить эффективность WebP в сравнении с другими форматами, мы подготовили набор известных свободных изображений в разных форматах, указав также размер изображений, так что вы можете сравнить их визуально. Кроме того, мы выпускаем программу-конвертер, которую вы можете использовать, чтобы преобразовать изображения в формат WebP. Мы рассчитываем на совместную работу, как с производителями браузеров, так и с сообществом веб разработчиков, над спецификацией WebP и над добавлением поддержки этого формата в браузеры. Несмотря на то, что изображения в формате WebP не могут быть отображены, пока браузеры не начнут поддерживать этот формат, мы работаем над патчем для Webkit, который обеспечит поддержку WebP в следующей версии Google Chrome. Кроме того, мы планируем в будущем добавить поддержку слоя прозрачности, также известного как альфа канал, в виде обновления (обновления Chrome или спецификации формата? Не ясно. прим. перев).

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

Ричард Рэббэт (Richard Rabbat), менеджер продукта.
Перевод: Ричард Рэббэт (Richard Rabbat)
Иван Сорокин @unxed
карма
110,1
рейтинг 1,2
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

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

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

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

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

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

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

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

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

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


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

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


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

    Это называется честным сравнением?
    • 0
      Ссылку забыл: code.google.com/speed/webp/gallery.html
    • +5
      Наверное, это было бы правильно продублировать в комментариях к оригиналу статьи. Я-то не автор формата, всё же.

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.