Эта страница переведена с помощью Cloud Translation API.

Часто задаваемые вопросы

Что такое ВебП? Почему я должен его использовать?

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

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

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

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

Поддержка WebP с потерями
- Google Chrome (компьютерный компьютер) 17+
- Google Chrome для Android версии 25+
- Майкрософт Край 18+
- Фаерфокс 65+
- Опера 11.10+
- Родной веб-браузер, Android 4.0+ (ICS)
- Safari 14+ (iOS 14+, macOS Big Sur+)
Поддержка WebP с потерями, без потерь и альфа-версии
- Google Chrome (компьютерный компьютер) 23+
- Google Chrome для Android версии 25+
- Майкрософт Край 18+
- Фаерфокс 65+
- Опера 12.10+
- Родной веб-браузер, Android 4.2+ (JB-MR1)
- Бледная Луна 26+
- Safari 14+ (iOS 14+, macOS Big Sur+)
Поддержка WebP-анимации
- Google Chrome (компьютерный компьютер и Android) 32+
- Майкрософт Край 18+
- Фаерфокс 65+
- Опера 19+
- Safari 14+ (iOS 14+, macOS Big Sur+)

См. также:

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

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

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

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

Модернизр

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

HTML5-элемент `<picture>`

HTML5 поддерживает элемент <picture> , который позволяет перечислять несколько альтернативных целевых изображений в порядке приоритета, так что клиент будет запрашивать первое изображение-кандидат, которое он сможет отобразить правильно. См. это обсуждение на HTML5 Rocks . Элемент <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, желательно помещать в функцию обратного вызова.

Почему Google выпустил WebP с открытым исходным кодом?

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

Как я могу преобразовать файлы моих личных изображений в WebP?

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

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

Окна:

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

Линукс/МакОС:

$ 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, WebP с потерями работает исключительно с 8-битным форматом изображения Y'CbCr 4:2:0 (часто называемым YUV420). Для получения более подробной информации обратитесь к разделу 2 « Обзор формата » RFC 6386, « Руководство по формату данных и декодированию VP8» .

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

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

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

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

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

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

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

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

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

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

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

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

Создание библиотеки в Eclipse :

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

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

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

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

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

Добавьте 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

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

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

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

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

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

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

¹ Для всех сравнений между анимированным GIF и анимированным WebP мы использовали корпус из около 7000 анимированных изображений GIF, случайно взятых из Интернета. Эти изображения были преобразованы в анимированный WebP с помощью инструмента «gif2webp» с настройками по умолчанию (созданными на основе последнего исходного дерева libwebp по состоянию на 08.10.2013). Сравнительные числа представляют собой средние значения по этим изображениям.

² Время декодирования было рассчитано с использованием последней версии libwebp + ToT Blink от 08.10.2013 с использованием инструмента тестирования . «Время декодирования с поиском» рассчитывается как «Декодировать первые пять кадров, очистить кэш буфера кадров, декодировать следующие пять кадров и т. д.».

³ WebM хранит в памяти 4 опорных кадра YUV, причем каждый кадр хранит (ширина+96)*(высота+96) пикселей. Для YUV 4:2:0 нам нужно 4 байта на 6 пикселей (или 3/2 байта на пиксель). Итак, эти опорные кадры используют 4*3/2*(width+96)*(height+96) байт памяти. WebP, с другой стороны, необходимо, чтобы был доступен только предыдущий кадр (в RGBA), что составляет 4*width*height байтов памяти.

^4. Для рендеринга анимации WebP требуется Google Chrome версии 32+.