Что такое WebP? Зачем мне его использовать?
WebP — это метод сжатия с потерями и без потерь, который можно использовать для самых разных фотографических, полупрозрачных и графических изображений, встречающихся в интернете. Степень сжатия с потерями регулируется, поэтому пользователь может выбрать оптимальный баланс между размером файла и качеством изображения. WebP обычно обеспечивает в среднем на 30% большее сжатие, чем JPEG и JPEG 2000, без потери качества изображения (см. исследование WebP с потерями и исследование WebP без потерь и с альфа-каналом ).
Формат WebP, по сути, направлен на создание меньших по размеру и более качественных изображений, которые могут способствовать ускорению работы интернета.
Какие веб-браузеры изначально поддерживают WebP?
Веб-мастера, заинтересованные в улучшении производительности сайта, могут легко создать оптимизированные альтернативы WebP для своих текущих изображений и показывать их целенаправленно браузерам, поддерживающим WebP.
- Поддержка WebP с потерями
- Google Chrome (для настольных компьютеров) 17+
- Google Chrome для Android версии 25+
- Microsoft Edge 18+
- Firefox 65+
- Opera 11.10+
- Встроенный веб-браузер, Android 4.0+ (ICS)
- Safari 14+ (iOS 14+, macOS Big Sur+)
- Поддержка форматов WebP с потерями, без потерь и альфа-версии.
- Google Chrome (для настольных компьютеров) 23+
- Google Chrome для Android версии 25+
- Microsoft Edge 18+
- Firefox 65+
- Опера 12.10+
- Встроенный веб-браузер, Android 4.2+ (JB-MR1)
- Бледная Луна 26+
- Safari 14+ (iOS 14+, macOS Big Sur+)
- Поддержка анимации WebP
- Google Chrome (для настольных компьютеров и Android) 32+
- Microsoft Edge 18+
- Firefox 65+
- Опера 19+
- Safari 14+ (iOS 14+, macOS Big Sur+)
См. также:
Как определить, поддерживает ли браузер формат WebP?
Вам следует предоставлять изображения в формате WebP только тем клиентам, которые могут их корректно отображать, и использовать устаревшие форматы для тех клиентов, которые не могут. К счастью, существует несколько методов определения поддержки WebP как на стороне клиента, так и на стороне сервера. Некоторые CDN-провайдеры предлагают определение поддержки WebP в рамках своих услуг.
Согласование содержимого на стороне сервера с помощью заголовков Accept.
Веб-клиенты обычно отправляют заголовок запроса "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 )
Linux / macOS:
$ 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 без потерь отличается от оригинала?
Функции API простого кодирования ( WebPEncodeLosslessRGB() , WebPEncodeLosslessBGR() , WebPEncodeLosslessRGBA() , WebPEncodeLosslessBGRA() ) используют настройки библиотеки по умолчанию. Для кодирования без потерь это означает, что параметр «точное» отключен. Значения RGB в полностью прозрачных областях (то есть областях со значениями альфа-канала, равными 0 ) будут изменены для улучшения сжатия. Чтобы избежать этого, используйте WebPEncode() и установите WebPConfig::exact в значение 1 См. документацию по API расширенного кодирования .
Может ли изображение в формате 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 с прогрессивной разверткой эквивалентно трехкратному декодированию изображения в базовом формате .
В качестве альтернативы WebP предлагает инкрементальное декодирование, при котором все доступные входящие байты битового потока используются для того, чтобы как можно быстрее создать отображаемую строку образца. Это позволяет экономить память, ресурсы процессора и ресурсы перерисовки на стороне клиента, а также предоставляет визуальные подсказки о состоянии загрузки. Функция инкрементального декодирования доступна через 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 > Behaviour . Добавьте
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-битным альфа-каналом, в отличие от GIF, который поддерживает 8-битный цвет и 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, для хранения минимального количества предыдущих кадров³ .
Поддержка видеокодеков и контейнеров сильно различается в разных браузерах и устройствах. Для обеспечения автоматического перекодирования контента (например, для прокси-серверов, экономящих трафик) браузерам потребуется добавить заголовки accept, указывающие, какие форматы поддерживают их теги изображений. Даже этого может быть недостаточно, поскольку типы MIME, такие как "video/webm" или "video/mpeg", по-прежнему не указывают на поддержку кодеков (например, VP8 против VP9). С другой стороны, формат WebP фактически зафиксирован, и если поставщики, распространяющие его, согласятся распространять анимированный WebP, поведение WebP во всех пользовательских агентах должно быть согласованным; а поскольку заголовок accept "image/webp" уже используется для указания поддержки WebP, никаких новых изменений в заголовке accept не требуется.
Видеоредактор Chromium оптимизирован для плавного воспроизведения и предполагает, что одновременно воспроизводится только один или два видеоролика. В результате реализация активно использует системные ресурсы (потоки, память и т. д.) для обеспечения максимального качества воспроизведения. Такая реализация плохо масштабируется для множества одновременно воспроизводимых видеороликов и потребует переработки для использования на веб-страницах с большим количеством изображений.
В настоящее время WebM не поддерживает все методы сжатия WebP. В результате это изображение сжимается значительно лучше с помощью WebP, чем альтернативные варианты:
1. Для всех сравнений между анимированными GIF-изображениями и анимированными WebP-изображениями мы использовали корпус из примерно 7000 анимированных GIF-изображений, случайно выбранных из интернета. Эти изображения были преобразованы в анимированные WebP с помощью инструмента 'gif2webp' с настройками по умолчанию (собранного из последней версии исходного кода libwebp по состоянию на 10.08.2013). Приведенные значения представляют собой средние значения по этим изображениям.
2. Время декодирования было рассчитано с использованием последней версии libwebp + ToT Blink по состоянию на 10.08.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 и выше.