Оптимизация изображений с WebP. Webp поддержка браузерами
Устройство WebP / Блог компании .io / Хабрахабр
WebP — сравнительно новый формат от Google. Картинки в этом формате занимают на 30% меньше места на странице благодаря особому сжатию, построенному на кодировании ключевых кадров в видеокодеке VP8.
WebP поддерживает сжатие с потерями и без, разные степени прозрачности, метаданные и может содержать встроенный ICC-профиль. Но пока не все браузеры и приложения поддерживают формат.
Как устроено сжатие в WebP
Сжатие с потерями основано на утверждении, что яркость и цвет соседних пикселей мало отличаются друг от друга.
Изображение делится на макроблоки. Внутри каждого макроблока декодер предсказывает яркость и цвет следующего пикселя на основе ранее полученных блоков. Он использует уже декодированные пиксели в непосредственной близости от каждого из макроблоков, и пытается закрасить неизвестные фрагменты в них. Таким образом данные о фрагментах, которые можно предсказать могут считаться лишними и удаляются из кода, что обеспечивает более эффективное сжатие.
После математически обратимого преобразования (с помощью ДКП) результат подвергается квантованию и энтропийному кодированию.
Lossy WebP
В lossy WebP используется арифметическое кодирование — один из алгоритмов энтропийного сжатия. В WebP используется блочное квантование и биты распределяются адаптивно между различными фрагментами изображения: меньшее количество бит для фрагментов с низкой энтропией и большее — для фрагментов с высокой. Такое кодирование считается более гибким, чем код Хаффмана (который использует JPEG).
JPEG делит изображение на одинаковые блоки, а технологии кодирования WebP использует умное деление. В тех частях картинки, где есть много мелких и быстро изменяющихся деталей блоки имеют размер 4 х 4 пикселя, а в монотонных областях — 16 х 16.
Как происходит прогнозирование
Декодер VP8 имеет 2 класса прогнозирования:
Intra — внутрикадровое пространственное предсказание блока на основе значений пикселей из соседних, уже закодированных блоков, слева и сверху.
Inter — межкадровое временное предсказание (оценка векторов движения).
Intra имеет четыре алгоритма прогнозирования для блоков 16х16 и 8 для детализирующих блоков 4 х 4:
H_PRED горизонтальное прогнозирование. Заливает следующую колонку на основе той, что находится слева от нее.
V_PRED вертикальное прогнозирование. Заливает следующий ряд на основе предыдущего верхнего.
DC_PRED заполняет блок, используя усредненные значения цвета и яркости пикселей строки
TM_PRED заполняет блок, используя не только усредненные значения строки A и колонки L, но и пиксель P, который находится сверху и слева от блока. Каждая строка начинается с пикселя в колонке L и заполняется в соответствии с различиями пикселей в колонке, начиная от пикселя P.
Изображение разбивается на сегменты, которые имеют явно схожие характеристики. Для каждого такого сегмента параметры сжатия и способы прогнозирования настраиваются независимо. Таким образом биты перераспределяются туда, где они наиболее полезны.
Сжатие без потерь
При сжатии без потерь используется вариант алгоритма LZ77 — кода Хаффмана. А также пространственное прогнозирование и преобразование цветового пространства.
Не только прогнозирование
Сжатие с альфа-каналом
Формат WebP позволяет получить сжатую картинку с альфа-каналом без потерь. Раньше, чтобы получить прозрачность все изображение должно было быть lossless. А в WebP можно уменьшить вес картинки с прозрачными областями.
Цветовое преобразование
Также в WebP используется методы адаптивного квантования цветовой составляющей, чтобы предотвратить влияние цветовых каналов друг на друга. Изображение делится на блоки и для каждого блока применяется свой режим трансформации green_to_red, green_to_blue или red_to_blue. Цветовое преобразование сохраняет неизменным значение зеленого канала G, преобразует красный R в зависимости от зеленого, и синий В в зависимости от зеленого, а затем в зависимости от красного.
Цветовое кеширование
Сжатие lossless WebP использует уже обработанные фрагменты изображения для работы с новыми пикселями. В случае если подходящие совпадения не найдены, используется локально созданная палитра. Эта палитра постоянно обновляется цветами, найденными при сканировании картинки.
Индексирование палитры
Если в картинке используется менее 256 цветов, алгоритм создает отдельный массив индексов цветов и сохраняет его отдельно, чтобы подменить значение цвета на индекс для каждого пикселя.
Для картинок с небольшим количеством мелких деталей используется технология апскейлинга. Прежде чем кодироваться — изображение ресайзится.
Статья написана на основе этого материала. А попробовать webp сжатие можно тут.
Конспект
В WebP картинка делится на макроблоки. Блоки размером 4х4 px для мелких деталей и 16х16 для монотонных областей.
Внутри каждого макроблока декодер предсказывает яркость и цвет каждого следующего пикселя на основе ранее полученных.
В lossy WebP используется арифметическое кодирование, а в lossless — код Хаффмана.
WebP позволяет получить сжатую картинку с альфа-каналом без потерь.
habrahabr.ru
Оптимизация изображений с WebP
Минификация и сжатие уже давно стали вполне стандартными вещами для оптимизации кода веб-страниц. Все популярные веб-ресурсы оптимизируют изображения, используют все тот же CSS, когда это возможно, и выбирают правильные форматы картинок.
Но и этого недостаточно. Статистика HTTP Archive показывает, что изображения занимают около 64 % размера веб-страницы. На помощь приходит новый стандарт WebP, способный заменить JPEG и PNG.
Кратко о WebP
Формат появился еще в 2010 году и с тех пор разрабатывается Google. WebP основан на алгоритме сжатия ключевых кадров видеокодека VP8 как с потерями, так и без, и упаковывается в контейнер на основе RIFF. Изображения WebP loseless в среднем на 26 % меньше по сравнению с PNG, а WebP lossy на 25-34 % меньше по сравнению с JPEG с тем же индексом SSIM. Новый формат также поддерживает прозрачность (известна как alpha channel).
Принцип работы
При сжатии с потерями в WebP применяется предиктивное кодирование, при котором значения соседних пиксельных блоков используются для предсказания значения нужного пиксельного блока, а затем кодируется разница.
Lossless-сжатие использует уже известные фрагменты изображения для точной реконструкции пикселей. Также может использоваться локальная палитра, если нет интересующих алгоритм совпадений.
Плюсы и минусы
За:
меньший размер изображения;
продвинутый алгоритм компрессии;
высокое качество изображения;
поддержка прозрачности.
Против:
плохая распространенность;
“пластиковость” при сжатии с потерями;
могут теряться цвета в пиксельной и другой компьютерной графике.
WebP уже поддерживается в Chrome, Opera и стандартным браузером Android, а при помощи библиотеки WebPJS может отображаться во всех популярных браузерах (в IE 6 и выше при помощи Flash).
Кроме того разработаны легкая библиотека кодирования и декодирования libwebp, утилиты командной строки для кодирования и декодирования WebP, а также инструменты для просмотра, мультиплексирования и анимирования изображений в этом формате.
Установка утилит и конвертация в WebP
Все инструменты можно скачать на странице для разработчиков Google. Они существуют для Windows, Linux и MacOS X в скомпилированном виде, но также можно загрузить исходный код для разработки (opensource все же) или самостоятельной компиляции.
Для конвертации из JPEG, PNG и TIFF используется утилита cwebp, а для декодирования — dwebp.
Конвертация запускается простой командой (из директории с утилитами):
cwebp input.png -q 80 -o output.webp
По тому же принципу запускается декодирование. Присутствует множество опций и дополнительных параметров, в том числе для проверки кодирования.
Развертывание WebP
Итак, вас заинтересовал новый формат, вы провели все тесты, еще раз просмотрели статистические данные и убедились, что Chrome все еще самый популярный веб-браузер. Что же дальше?
Дальше нужно сделать копию всех изображений в WebP (можно написать простенький скрипт для конвертации всех файлов), а затем проверять пользователей сайта и подсовывать им компактные изображения, если их браузер поддерживает WebP.
То есть можно создать свой скрипт, который будет проверять браузер клиента на поддержку формата, который затем будет подсовывать веб-сервер, или полностью возложить эту задачу на веб-сервер. Второй вариант кажется нам более логичным.
Согласование при помощи заголовка Accept
Браузеры передают заголовок Accept в виде:
# в Opera
Accept: text/html, application/xml;q=0.9, application/xhtml+xml,
image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept: image/webp, */*;q=0.8
Зная это, можно сконфигурировать веб-сервер, чтобы он автоматически передавал WebP. В качестве примера используем Nginx, в файл конфигурации которого необходимо добавить подобное:
location / {
if ($http_accept ~* "webp") { set $webp_accept "true"; }
if (-f $request_filename.webp) { set $webp_local "true"; }
if ($webp_local = "true") {
add_header Vary Accept;
}
if ($webp_accept = "true") {
rewrite (.*) $1.webp break;
}
}
То есть, если в Accept не обнаружена поддержка WebP, то передаются обычные файлы.
Ну а если Nginx используется в качестве прокси для кэширования статики, то и конфигурация будет отличаться:
server {
location / {
if ($http_accept ~* "webp") { set $webp T; }
proxy_cache_key $scheme$proxy_host$request_uri$webp;
proxy_pass http://backend;
proxy_cache my-cache;
}
}
Самое главное
Формат изображений WebP позволит существенно уменьшить размер веб-страницы, но учитывая его ограниченную поддержку необходимо дополнительно настраивать веб-сервер и содержать копии всех изображений в нескольких форматах.
ruhighload.com
Готовим WebP правильно / СоХабр
Хабр уже насыщен статьями на тему «нового» формата изображений WebP (описание, сравнение с JPEG2000, сравнение с BPG, использование, подключение на сайте). К сожалению, открытыми остаются вопросы: как правильно подключить WebP на сайте, чтобы «все работало», и насколько он лучше (меньше) PNG/JPEG. В этой заметке я буду отвечать на оба вопроса.
Предполагаю, что вы уже в курсе оптимизации изображений, умеете конвертировать изображения в WebP, понимаете разницу между использованием JPEG и PNG на сайте, знаете инструменты ExifTool, jpegtran, mozjpeg, JPEGrescan, optipng, pngcrush, pngwolf, zopflipng и TruePNG, а также различаете пастеризацию молока и постеризацию изображений.
Если все так — то переходим к сути.
Плюсы WebP
Во всех источниках упоминается существенное уменьшение размера изображений, что PNG, что JPEG, если их перекодировать в WebP. При этом перекодирование должно выполняться с сохранением качества. В Айри.рф уже три года используется автоматическая оптимизация изображений без потерь и с незначительными потерями (2 режима). Это позволяет достаточно точно сравнить, когда WebP выигрывает в сравнении с уже оптимизированными PNG (прогоняется через TruePNG, pngwolf и zopflipng) и JPEG (ExifTool, mozjpeg, перевод в png), а когда нет.
На тестовой выборке из 13 тысяч изображений WebP показал выигрыш относительно уже оптимизированных PNG и JPEG файлов на 31% (580 Мб против 837 Мб). WebP-файлы примерно на треть меньше уже оптимизированных аналогов JPEG и PNG. Здесь нужно оговориться, что перевод PNG в WebP выполняется без потерь (lossless), а перевод в JPEG выполняется с минимальными потерями (качество 100), это позволяет в автоматическом режиме отгружать WebP для всех браузеров, которые его понимают, без опасений что-то «поломать» у клиентов.
В подавляющем большинстве случаев выигрыш WebP относительно уже оптимизированных JPEG (mozjpeg) составлял не более 10%. Исключения были в тех случаях, когда из JPEG-файлов нельзя было безопасно вырезать EXIF-данные (в частности, палитру), и перевод их в WebP давал существенный выигрыш. Поэтому если вы создаете JPEG сразу по «нормальному» сценарию, то в большинстве случаев существенного выигрыша не предвидится. PNG-файлы даже после оптимизации относительно неплохо (30%) «теряют в весе», если перевести их в WebP.
Что важнее, относительно всех оптимизированных изображений только в 10% случаев (да, выборка из 13000 изображений — это было только 10% всех оптимизированных изображений) WebP «без потерь» давал выигрыш в размере. Для остальных 90% выигрыша не было (из них 75% — это JPEG файлы). Цифры еще могут быть обусловлены жестким подходом к оптимизации изображений без потерь: возможно, тонкая настройка WebP с «небольшими» потерями качества даст визуально «тот же результат», но будет меньше по размеру. К сожалению, в автоматическом режиме оценить все 130 тысяч изображений, чтобы понять, насколько в каждом конкретном случае сжатие с потерями может быть лучше, не представляется возможным. Сами изображения не представляют какой-либо закономерности: это фоновые картинки и галереи сотен сайтов.
Для справки, перевод PNG в WebP
cwebp -quiet -pass 10 -alpha_method 1 -alpha_filter best -m 6 -mt -lossless -q 100 Перевод JPEG в WebPcwebp -quiet -pass 10 -alpha_method 1 -alpha_filter best -m 6 -mt -q 100 Отличной иллюстрацией является изображение к статье. Исходный PNG занимал 15,6 Кб. После оптимизации и постеризации — 12,5 Кб. lossless webp из него — 8 Кб.
Реальное использование WebP
Если вы уже научились правильно конвертировать или сохранять изображения в WebP (тема для отдельной статьи), то остается проблема подключения WebP на сайте, которая уже поднималась здесь (игра стоит свеч, ибо Chrome браузеры уже составляют более 2/3 рынка). На стороне браузера возможны варианты с JavaScript (использование тега noscript, ymatuhin):<script async src="simple-webp.min.js"> <noscript data-webp> <img src="example.png" alt=""> </noscript> И HTML5 (использование picture, pepelsbey):<picture> <source srcset="opera.webp" type="image/webp"> <img src="opera.jpg" alt="The Oslo Opera House"> </picture> Второй вариант, в целом, надежнее (хотя может покрывать меньше браузеров).
Также возможен «пуленепробиваемый» серверный вариант, который читает заголовок Accept браузера и отгружает соответствующее изображение (все WebP изображения нужно сохранить с расширением .webp к аналогам) браузеру, который их поддерживает (изменения в клиентском коде не нужно). Самый простой вариант для nginx выглядит примерно так:
map $http_accept $x_airee_webp { ~*webp '.webp'; default ''; } ... try_files $uri$x_airee_webp @404 Более точные варианты (с правильной поддержкой Vary и Cache-Control) поддерживает в актуальном состоянии Ilya Grigorik в проекте webp-detect (для всех основных веб-серверов).
Мысли к обсуждению
Резюмируя практический опыт использования WebP: это имеет смысл делать, особенно для мобильных браузеров (для них можно отгружать изображения в «плохом» качестве и реально выиграть во времени загрузки страницы). Но для начала нужно настроить весь стек оптимизации изображений «обычными» способами: это даст существенный выигрыш для всех пользователей. После этого поддержка WebP в ваших проектах может быть реализована буквально «в два клика» (конфигурация nginx + конвертация в процессе оптимизации).
Также, на мой взгляд, использование WebP способно «творить чудеса» при точечной оптимизации некоторых типов изображений (с которыми плохо справляются как JPEG, так и PNG) — например, большое количество мелких деталей на фоне больших однородных областей. И если подбирать параметры оптимизации в автоматическом режиме для таких типов изображений — это будет весьма здорово.
Соображения по поводу «удвоения» размера изображений на диске я считая несущественными: если записывать WebP только в тех случаях, когда файл меньше по размеру, и провести оптимизацию всех изображений, то они будут занимать еще меньше места. И перевод PNG изображений в WebP существенно (минимум, на порядок) менее ресурсоемкий, чем оптимизация PNG (с перебором вариантов сжатия).
Буду рад увидеть ваши соображения и прикладной опыт использования изображений в формате WebP.
sohabr.net
WebP, новый формат изображений для интернета / Geektimes
В рамках инициативы компании Google, заключающейся в том, чтобы сделать интернет более быстрым, в течении прошедших месяцев мы выпустили целый набор инструментов, призванных помочь владельцам сайтов их ускорить. Мы запустили расширение для Firefox под названием Page Speed, позволяющее изучать производительность веб страниц, а также получать предложения о том, как её увеличить. Мы представили Speed Tracer, расширение для Chrome, позволяющее найти и исправить проблемы с производительностью в веб приложениях. Кроме того, мы выпустили набор инструментов для завершающей стадии разработки (closure tools), призванный помочь создавать сложные веб приложения с польностью оптимизированным javascript-кодом. В то время, как эти инструменты были невероятно успешны, помогая разработчикам оптимизировать их сайты, мы продолжали работу, и нам удалось обнаружить единственный компонент веб страниц, который полностью ответственнен за большинство задержек на страницах: изображения.
Большая часть распространенных форматов изображений, используемых в сети, были созданы более 10 лет назад и основаны на технологиях того времени. Инженеры из Google решили проверить: нет ли способа увеличить степень сжатия алгоритмов сжатия с потерями (как JPEG), чтобы позволить изображениям загружаться быстрее, при этом полностью сохраняя их разрешение и визуальное качество. В результате работы на этим проектом мы выпускаем новый формат изображений, WebP, в предварительной версии для разработчиков. Этот формат обещает существенно уменьшить бинарный размер фотографий в сети, позволяя сайтам загружаться быстрее, чем раньше.
На сегодняшний день, изображения и фотографии составляют около 65% всех данных, составляющих веб страницу. Они могут существенно замедлить работу в сети, особенно в сетях с ограниченным трафиком, таких как мобильные сети. Большую часть изображений в сети составляют форматы сжатия с потерями (такие как JPEG), меньшую — форматы с сжатием без потерь (такие как GIF и PNG). Наша команда сконцентрировалась на улучшении сжатия с потерями, так как на сегодняшний день именно изображения в таких форматах составляют большую часть всех изображений в сети.
Чтобы улучшить степень сжатия, которую предлагает формат JPEG, мы использовали алгоритм, основанный на используемом в кодеке VP8, исходные коды которого были открыты компанией Google в мае 2010 года. Мы применили технологии, используемые в VP8 для сжатия промежуточных кадров, для сжатия статичных изображений. Кроме того, мы использовали очень компактный формат файла-контейнера, основанный на формате RIFF: несмотря на то, что этот формат добавляет всего 20 байт к каждому изображению, он является расширяемым, что позволяет авторам сохранять в файле любые необходимые метаданные.
Хотя преимущества формата изображений, основанного на VP8, теоретически очевидны, нужно было проверить их в условиях реального мира. Чтобы оценить эффективность наших усилий, мы выбрали около миллиона случайных изображений из сети (преимущественно JPEG, а также немного PNG и GIF) и перекодировали их в WebP, сохраняя их визуальное качество. Такое перекодирование привело к сокращению размера файлов на 39% (видимо, имелось в виду, в среднем. прим. перев). Мы рассчитываем, что разработчики добьются с форматом WebP еще большего сжатия, сжимая изображения, которые изначально не были сжатыми.
Чтобы помочь вам оценить эффективность WebP в сравнении с другими форматами, мы подготовили набор известных свободных изображений в разных форматах, указав также размер изображений, так что вы можете сравнить их визуально. Кроме того, мы выпускаем программу-конвертер, которую вы можете использовать, чтобы преобразовать изображения в формат WebP. Мы рассчитываем на совместную работу, как с производителями браузеров, так и с сообществом веб разработчиков, над спецификацией WebP и над добавлением поддержки этого формата в браузеры. Несмотря на то, что изображения в формате WebP не могут быть отображены, пока браузеры не начнут поддерживать этот формат, мы работаем над патчем для Webkit, который обеспечит поддержку WebP в следующей версии Google Chrome. Кроме того, мы планируем в будущем добавить поддержку слоя прозрачности, также известного как альфа канал, в виде обновления (обновления Chrome или спецификации формата? Не ясно. прим. перев).
Мы очень ждем обратной связи от сообщества разработчиков в нашей группе, так что скачайте конвертер, попробуйте его на вашем любимом наборе изображений, и сообщите нам, что вы думаете.
Ричард Рэббэт (Richard Rabbat), менеджер продукта.