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

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

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

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

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

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

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

Смотрите также:

• Статья в Википедии о WebP
• Могу ли я использовать

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

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

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

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

• Развертывание новых форматов изображений в Интернете
• Предоставление изображений WebP посетителям с использованием элементов HTML

Модернизр

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) и преобразованием между ними.

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

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 предлагает инкрементное декодирование, при котором все доступные входящие байты битового потока используются для попытки как можно скорее создать отображаемую строку выборки. Это экономит память, ЦП и усилия по перерисовке на клиенте, предоставляя визуальные подсказки о статусе загрузки. Функция инкрементного декодирования доступна через Advanced Decoding API .

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

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

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

1. Убедитесь, что у вас установлен плагин ADT вместе с инструментами NDK, и ваш путь к NDK указан правильно ( Preferences > Android > NDK ).
2. Создайте новый проект: File > New > Project > Android Application Project .
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/ project.

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 ¹ . Анимированные GIF-файлы, преобразованные в файлы WebP с потерями, на 64% меньше, а файлы WebP без потерь — на 19%. Это особенно важно в мобильных сетях.

4. WebP требует меньше времени для декодирования при наличии поиска. В Blink прокрутка или изменение вкладок может скрывать и отображать изображения, в результате чего анимация приостанавливается, а затем пропускается к другому моменту. Чрезмерное использование ЦП, которое приводит к пропуску кадров анимации, также может потребовать от декодера поиска вперед в анимации. В этих сценариях анимированный WebP занимает в 0,57 раза больше общего времени декодирования ^{2 ,} чем GIF, что приводит к меньшему количеству рывков во время прокрутки и более быстрому восстановлению после скачков загрузки ЦП. Это связано с двумя преимуществами WebP по сравнению с GIF:

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

   • Подобно современному кодировщику видео, кодировщик WebP эвристически добавляет ключевые кадры через равные промежутки времени (чего не делает большинство кодировщиков GIF). Это значительно улучшает поиск в длинных анимациях. Чтобы облегчить вставку таких кадров без значительного увеличения размера изображения, WebP добавляет флаг «метода наложения» для каждого кадра в дополнение к методу удаления кадров, который использует GIF. Это позволяет отрисовывать ключевой кадр так, как если бы все изображение было очищено до фонового цвета, не заставляя предыдущий кадр быть полноразмерным.

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

1. При отсутствии поиска прямолинейное декодирование WebP требует больше ресурсов ЦП, чем GIF. WebP с потерями требует в 2,2 раза больше времени на декодирование, чем GIF, а WebP без потерь — в 1,5 раза больше.

2. Поддержка WebP не так широко распространена, как поддержка GIF, которая фактически универсальна.

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

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

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

1. При декодировании кадра, основанного на предыдущих кадрах, WebM требуется на 50 % больше памяти, чем анимированному WebP, для хранения минимального количества предыдущих кадров ³ .

2. Поддержка видеокодеков и контейнеров сильно зависит от браузеров и устройств. Для облегчения автоматического перекодирования контента (например, для прокси-серверов, экономящих полосу пропускания) браузеры должны добавлять заголовки accept, указывающие, какие форматы поддерживают их теги изображений. Даже этого может быть недостаточно, поскольку типы MIME, такие как «video/webm» или «video/mpeg», по-прежнему не указывают на поддержку кодека (например, VP8 против VP9). С другой стороны, формат WebP фактически заморожен, и если поставщики, поставляющие его, соглашаются поставлять анимированный WebP, поведение WebP во всех ПА должно быть согласованным; и поскольку заголовок принятия "image/webp" уже используется для указания поддержки WebP, никаких новых изменений заголовка принятия не требуется.

3. Видеостек Chromium оптимизирован для плавного воспроизведения и предполагает, что одновременно воспроизводятся только одно или два видео. В результате реализация агрессивно потребляет системные ресурсы (потоки, память и т. д.) для максимального качества воспроизведения. Такая реализация плохо масштабируется для большого количества одновременных видео и должна быть переработана, чтобы ее можно было использовать на веб-страницах с большим количеством изображений.

4. WebM в настоящее время не включает все методы сжатия из WebP. В результате это изображение значительно лучше сжимается с помощью WebP, чем альтернативы:

   • GIF (85 КБ)
   • WebM с альфа-версией (32 КБ)
   • Анимированный WebP без потерь (5 КБ) ⁴

---

¹ Для всех сравнений между анимированным 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 байта памяти.

⁴ Для визуализации анимированного WebP требуется Google Chrome версии 32+.