FAQ по WebP от Google

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 5,00 из 5)
Загрузка...

Что такое WebP? Зачем его использовать?

WebP — это метод сжатия изображений с потерями и без потерь, который можно использовать для изображений в Интернете. Степень сжатия с потерями регулируется, поэтому пользователь может выбрать компромисс между размером файла и качеством изображения. Как правило, WebP обеспечивает сжатие в среднем на 30% больше, чем JPEG и JPEG 2000, без потери качества изображения.

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

Какие веб-браузеры изначально поддерживают WebP?

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

  • WebP с потерями поддерживают:
    • Google Chrome (для ПК) 17+
    • Google Chrome для Android версии 25+
    • Microsoft Edge 18+
    • Firefox 65+
    • Опера 11.10+
    • Собственный веб-браузер, Android 4.0+ (ICS)
  • WebP с потерями, без потерь и альфа-поддержка:
    • Google Chrome (для ПК) 23+
    • Google Chrome для Android версии 25+
    • Microsoft Edge 18+
    • Firefox 65+
    • Опера 12.10+
    • Собственный веб-браузер, Android 4.2+ (JB-MR1)
    • Бледная Луна 26+
  • Поддержка WebP Animation:
    • Google Chrome (для ПК и Android) 32+
    • Microsoft Edge 18+
    • Firefox 65+
    • Опера 19+

Как определить поддержку браузера для WebP?

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

Согласование содержимого на стороне сервера через заголовки Accept

Веб-клиенты все чаще отправляют заголовок запроса «Accept», указывающий, какие форматы контента они готовы принять в ответ. Если браузер заранее указывает, что он «примет» формат изображения / webp , веб-сервер знает, что он может безопасно отправлять изображения WebP, что значительно упрощает согласование содержимого. 

Modernizr

Modernizr — это библиотека JavaScript для удобного определения поддержки функций HTML5 и CSS3 в веб-браузерах. Ищите свойства Modernizr.webp , Modernizr.webp.lossless , Modernizr.webp.alpha иModernizr.webp.animation .

Элемент HTML5 <picture>

HTML5 поддерживает элемент  <picture>, который позволяет вам перечислить несколько альтернативных целей изображения в порядке приоритета, так что клиент запросит первое изображение-кандидат, которое он может правильно отобразить. 

В вашем собственном JavaScript

Другой метод обнаружения — попытка декодировать очень маленькое изображение WebP, которое использует определенную функцию, и проверить его на успешность. Пример:

// check_webp_feature:
//   'feature' can be one of 'lossy', 'lossless', 'alpha' or 'animation'.
//   'callback(feature, result)' will be passed back the detection result (in an asynchronous way!)
function check_webp_feature(feature, callback) {
    var kTestImages = {
        lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA",
        lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==",
        alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==",
        animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA"
    };
    var img = new Image();
    img.onload = function () {
        var result = (img.width > 0) && (img.height > 0);
        callback(feature, result);
    };
    img.onerror = function () {
        callback(feature, false);
    };
    img.src = "data:image/webp;base64," + kTestImages[feature];
}

Обратите внимание, что загрузка изображения неблокируемая и асинхронная. Это означает, что любой код, который зависит от поддержки WebP, предпочтительно должен быть помещен в функцию обратного вызова.

Как преобразовать файлы изображений в WebP?

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

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

Windows:

> for /R . %I in (*.jpg) do ( cwebp.exe %I -o %~fnI.webp )

Linux / Mac:

$ for F in *.jpg; do cwebp $F -o `basename ${F%.jpg}`.webp; done

Как оценить качество изображения WebP?

В настоящее время вы можете просматривать файлы WebP, конвертируя их в общий формат, использующий сжатие без потерь, например PNG, а затем просматривать файлы PNG в любом браузере или программе просмотра изображений. Чтобы быстро получить представление о качестве WebP, см. Галерею на этом сайте для сравнения фотографий.

Как получить исходный код?

Код конвертера доступен в разделе загрузок на странице проекта с открытым исходным кодом WebP. Код для облегченного декодера и спецификация VP8 находятся на сайте WebM . Смотрите страницу Контейнер RIFF для спецификации контейнера.

Каков максимальный размер изображения WebP?

WebP совместим с потоком битов с VP8 и использует 14 бит для ширины и высоты. Максимальные размеры в пикселях изображения WebP составляют 16383 x 16383.

Какие цветовые пространства поддерживает формат WebP?

В соответствии с битовым потоком VP8 Web-протокол с потерями работает исключительно с 8-битным форматом изображения Y’CbCr 4: 2: 0 (часто называемым YUV420). 

Lossless WebP работает исключительно с форматом RGBA. См. Спецификацию WebP Lossless Bitstream .

Может ли изображение WebP стать больше, чем его исходное изображение?

Да, обычно при преобразовании из формата с потерями в WebP без потерь или наоборот. Это происходит главным образом из-за разницы в цветовом пространстве (YUV420 против ARGB) и конверсии между ними.

Есть три типичные ситуации:

  1. Если исходное изображение имеет формат ARGB без потерь, пространственная понижающая дискретизация до YUV420 представит новые цвета, которые сложнее сжимать, чем исходные. Такая ситуация обычно может возникнуть, когда источник имеет формат PNG с несколькими цветами: преобразование в WebP с потерями (или, аналогично JPEG с потерями) потенциально приведет к увеличению размера файла.
  2. Если источник имеет формат с потерями, использование сжатия WebP без потерь для захвата природы источника с потерями обычно приводит к увеличению размера файла. Это не относится к WebP и может происходить, например, при преобразовании источника JPEG в форматы WebP или PNG без потерь.
  3. Если источник в формате с потерями, и вы пытаетесь сжать его как WebP с потерями с более высоким качеством настройки. Например, попытка преобразовать файл JPEG, сохраненный с качеством 80, в файл WebP с качеством 95 обычно приводит к увеличению размера файла, даже если оба формата имеют потери. Оценка качества источника часто невозможна, поэтому рекомендуется снизить целевое качество WebP, если размер файла постоянно увеличивается. Другая возможность состоит в том, чтобы избегать использования параметра качества и вместо этого задавать размер файла с помощью -sizeпараметра в cwebpинструменте или эквивалентного API. Например, ориентация на 80% исходного размера файла может оказаться более надежной.

Обратите внимание, что преобразование источника JPEG в WebP с потерями или источника PNG в WebP без потерь не приводит к неожиданности такого размера файла.

Поддерживает ли WebP прогрессивный или чересстрочный дисплей?

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

В среднем декодирование прогрессивного изображения JPEG эквивалентно декодированию базовой линии 3 раза.

В качестве альтернативы, WebP предлагает инкрементное декодирование, где все доступные входящие байты битового потока используются, чтобы попытаться создать отображаемую строку выборки как можно скорее. Это позволяет сэкономить память, ЦП и перерисовать данные на клиенте, одновременно обеспечивая визуальные подсказки о состоянии загрузки. Функция инкрементного декодирования доступна через API расширенного декодирования .

Как использовать привязки libwebp Java в Android?

WebP включает поддержку привязок JNI к простым интерфейсам кодировщика и декодера в swig/каталоге.

Сборка библиотеки в Eclipse :

  1. Убедитесь, что у вас установлен плагин ADT вместе с инструментами NDK, и ваш путь к NDK задан правильно ( Настройки > Android > NDK ).
  2. Создайте новый проект: Файл > Создать > Проект > Проект приложения Android .
  3. Клонировать или распаковать libwebp в папку с именем jniв новом проекте.
  4. Добавить swig/libwebp_java_wrap.cв LOCAL_SRC_FILESсписок.
  5. Щелкните правой кнопкой мыши новый проект и выберите « Инструменты Android» > « Добавитьвстроенную поддержку» …, чтобы включить библиотеку в сборку.
  6. Откройте свойства проекта и перейдите в C / C ++ Build > Behavior . Добавьте ENABLE_SHARED=1в Build (Incremental build)раздел, чтобы собрать libwebp как общую библиотеку.Примечание. Настройка NDK_TOOLCHAIN_VERSION=4.8в целом улучшит производительность 32-битной сборки.
  7. Добавьте swig/libwebp.jarв libs/папку проекта.
  8. Создайте свой проект. Это создаст libs/<target-arch>/libwebp.so.
  9. Используйте System.loadLibrary("webp")для загрузки библиотеки во время выполнения.

Обратите внимание, что библиотека может быть собрана вручную с помощью ndk-buildи включеннойAndroid.mk. Некоторые из шагов, описанных выше, могут быть повторно использованы в этом случае.

Как использовать libwebp с C #?

WebP может быть построен как DLL, которая экспортирует API libwebp. Эти функции затем могут быть импортированы в C #.

  1. Сборка libwebp.dll. Это установит WEBP_EXTERN правильно для экспорта функций API.
libwebp> nmake /f Makefile.vc CFG=release-dynamic

2. Добавьте libwebp.dll в ваш проект и импортируйте нужные функции. Обратите внимание, что если вы используете простой API, вы должны вызывать, WebPFree()чтобы освободить все возвращенные буферы.

[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPEncodeBGRA(IntPtr rgba, int width, int height, int stride,
                                 float quality_factor, out IntPtr output);
[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPFree(IntPtr p);

void Encode() {
  Bitmap source = new Bitmap("input.png");
  BitmapData data = source.LockBits(
      new Rectangle(0, 0, source.Width, source.Height),
      ImageLockMode.ReadOnly,
      PixelFormat.Format32bppArgb);
  IntPtr webp_data;
  const int size = WebPEncodeBGRA(data.Scan0,
                                  source.Width, source.Height, data.Stride,
                                  80, out webp_data);
  // ...
  WebPFree(webp_data);
}

Зачем использовать анимированный WebP?

Преимущества анимированного WebP по сравнению с анимированным GIF

  1. WebP поддерживает 24-битный цвет RGB с 8-битным альфа-каналом по сравнению с 8-битным цветом GIF и 1-битным альфа-каналом.
  2. WebP поддерживает сжатие с потерями и без потерь; фактически, одна анимация может комбинировать кадры с потерями и без потерь. GIF поддерживает только сжатие без потерь. Методы сжатия с потерями в WebP хорошо подходят для анимированных изображений, созданных из реальных видео, которые становятся все более популярным источником анимированных изображений.
  3. WebP требует меньше байтов, чем GIF 1 . Анимированные GIF, конвертированные в WebP с потерями, на 64% меньше, а WebP без потерь на 19%. Это особенно важно в мобильных сетях.
  4. WebP занимает меньше времени для декодирования при наличии поиска. В режиме Blink прокрутка или изменение вкладок могут скрывать и отображать изображения, в результате чего анимация приостанавливается, а затем пропускается вперед в другую точку. Чрезмерное использование ЦП, приводящее к отбрасыванию кадров анимации, также может потребовать от декодера поиска вперед в анимации. В этих сценариях анимированный WebP занимает в 0,57 раза больше общего времени декодирования, чем GIF, что приводит к уменьшению задержки при прокрутке и более быстрому восстановлению после скачков загрузки ЦП. Это связано с двумя преимуществами WebP над GIF:
    • Изображения WebP хранят метаданные о том, содержит ли каждый кадр альфа, что устраняет необходимость в декодировании кадра для такого определения. Это приводит к более точному выводу, от которого зависят предыдущие кадры, от которого зависит данный кадр, тем самым уменьшая ненужное декодирование предыдущих кадров.
    • Как и современный видеокодер, кодер WebP эвристически добавляет ключевые кадры через равные промежутки времени (чего не делает большинство кодеров GIF). Это значительно улучшает поиск в длинных анимациях. Чтобы упростить вставку таких кадров без значительного увеличения размера изображения, WebP добавляет флаг «метод наложения» для каждого кадра в дополнение к методу удаления кадров, который использует GIF. Это позволяет рисовать ключевой кадр так, как если бы все изображение было очищено до цвета фона, не заставляя предыдущий кадр быть полноразмерным.

Недостатки анимированного WebP по сравнению с анимированным GIF

  1. В отсутствие поиска прямолинейное декодирование WebP требует больше ресурсов процессора, чем GIF. Lossy WebP занимает в 2,2 раза больше времени декодирования, чем GIF, а без потерь WebP — в 1,5 раза больше.
  2. Поддержка WebP не так широко распространена, как поддержка GIF, которая является универсальной.
  3. Добавление поддержки WebP в браузеры увеличивает площадь кода и поверхность атаки. В Blink это примерно 1500 дополнительных строк кода (включая библиотеку демпфирования WebP и декодер изображений на стороне Blink). Обратите внимание, что эта проблема может быть уменьшена в будущем, если WebP и WebM совместно используют более общий код декодирования или если возможности WebP включены в WebM.

Почему бы просто не поддерживать WebM в <img>?

Возможно, в долгосрочной перспективе имеет смысл поддерживать форматы видео внутри <img> тега. Однако сделать это сейчас с намерением, чтобы WebM <img>мог выполнять предложенную роль анимированного WebP, проблематично:

  1. При декодировании кадра, основанного на предыдущих кадрах, для WebM требуется на 50% больше памяти, чем для анимированного WebP, для хранения минимального количества предыдущих кадров.
  2. Поддержка видеокодеков и контейнеров широко варьируется в зависимости от браузера и устройства. Чтобы упростить автоматическое транскодирование контента (например, для прокси-серверов, экономящих полосу пропускания), браузерам необходимо добавить заголовки подтверждения, указывающие, какие форматы поддерживают их теги изображений. Даже этого может быть недостаточно, поскольку типы MIME, такие как «video / webm» или «video / mpeg», по-прежнему не указывают на поддержку кодека (например, VP8 против VP9). С другой стороны, формат WebP фактически заморожен, и если поставщики, которые его отправляют, соглашаются поставлять анимированный WebP, поведение WebP во всех UA должно быть согласованным; и поскольку заголовок принятия «image / webp» уже используется для указания поддержки WebP, новые изменения в заголовке принятия не требуются.
  3. Хром стек видео оптимизировано для плавного воспроизведения, и предполагает , что есть только один или два видео , играющее одновременно. В результате реализация агрессивно использует системные ресурсы (потоки, память и т. Д.), Чтобы максимизировать качество воспроизведения. Такая реализация плохо масштабируется для множества одновременных видео и должна быть переработана, чтобы она подходила для использования с веб-страницами с большим количеством изображений.
  4. WebM в настоящее время не включает в себя все методы сжатия из WebP. В результате это изображение сжимается значительно лучше с WebP, чем альтернативы

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Scroll to top