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

Что такое 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)
    • 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», указывающий, какие форматы контента они готовы принимать в ответ. Если браузер заранее указывает, что он «примет» формат image/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 )

Linux/macOS:

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

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

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

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

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

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

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

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

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

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

Почему мой файл WebP без потерь отличается от оригинала?

Функции API простого кодирования ( WebPEncodeLosslessRGB() , WebPEncodeLosslessBGR() , WebPEncodeLosslessRGBA() , WebPEncodeLosslessBGRA() ) используют настройки библиотеки по умолчанию. Для сжатия без потерь это означает, что параметр «exact» отключен. Значения RGB в полностью прозрачных областях (то есть областях со значениями альфа, равными 0 ) будут изменены для улучшения сжатия. Чтобы избежать этого, используйте WebPEncode() и установите WebPConfig::exact значение 1 См. документацию по API расширенного кодирования .

Может ли изображение 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 Advanced Decoding .

Как использовать привязки Java libwebp в моем 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++» > «Поведение» . Добавьте 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-битным альфа-каналом, в то время как GIF поддерживает 8-битный цвет и 1-битный альфа-канал.

  2. WebP поддерживает сжатие как с потерями, так и без потерь; фактически, одна анимация может сочетать кадры как с потерями, так и без потерь. GIF поддерживает только сжатие без потерь. Методы сжатия с потерями в WebP хорошо подходят для анимированных изображений, созданных на основе реальных видеороликов, которые становятся всё более популярным источником анимированных изображений.

  3. Формат WebP требует меньше байтов, чем GIF 1 . Анимированные 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, для хранения минимального количества предыдущих кадров 3 .

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

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

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

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

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

3 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+.