Кодирование без потерь и прозрачности в WebP

Юрки Алакуйяла, доктор философии, Google, Inc.
Винсент Рабо, доктор философии, Google, Inc.
Последнее обновление: 2017-08-01

Аннотация . Мы сравниваем использование ресурсов кодером/декодером WebP с использованием PNG как в режиме без потерь, так и в режиме с потерями. Мы используем набор из 12 000 случайно выбранных полупрозрачных изображений в формате PNG из Интернета и более простые измерения, чтобы показать различия в производительности. Мы повторно сжали файлы PNG в нашем корпусе, чтобы сравнить изображения WebP с изображениями PNG, оптимизированными по размеру. Наши результаты показывают, что WebP является хорошей заменой PNG для использования в Интернете как с точки зрения размера, так и скорости обработки.

Введение

WebP поддерживает полупрозрачные изображения без потерь, что делает его альтернативой формату PNG. Многие из основных методов, используемых в сжатии PNG, такие как кодирование по словарю, кодирование Хаффмана и преобразование индексации цветов, также поддерживаются в WebP, что приводит к аналогичной скорости и плотности сжатия в худшем случае. В то же время ряд новых функций, таких как отдельные коды энтропии для разных цветовых каналов, 2D-локальность обратных эталонных расстояний и цветовой кэш недавно использованных цветов, позволяют повысить плотность сжатия большинства изображений.

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

Были продемонстрированы более высокие скорости декодирования, чем PNG, а также сжатие на 23% более плотное, чем то, что может быть достигнуто с использованием современного формата PNG. Мы пришли к выводу, что WebP является более эффективной заменой сегодняшнему формату изображений PNG. Кроме того, сжатие изображений с потерями с поддержкой альфа-канала без потерь дает дополнительные возможности для ускорения веб-сайтов.

Методы

Инструменты командной строки

Мы используем следующие инструменты командной строки для измерения производительности:

  1. cwebp и dwebp. Эти инструменты являются частью библиотеки libwebp (собраны из заголовка).

  2. конвертировать. Это часть инструмента командной строки программного обеспечения ImageMagick (6.7.7-10 2017-07-21).

  3. pngcrush 1.8.12 (30 июля 2017 г.)

  4. ZopfliPNG (17 июля 2017 г.)

Мы используем инструменты командной строки с соответствующими флагами управления. Например, если мы ссылаемся на cwebp -q 1 -m 0, это означает, что инструмент cwebp был вызван с флагами -q 1 и -m 0.

Корпуса изображений

Были выбраны три корпуса:

  1. Одно фотографическое изображение (рис. 1),

  2. Одно графическое изображение с полупрозрачностью (рис. 2) и

  3. Веб-корпус: 12000 случайно выбранных изображений в формате PNG с полупрозрачностью или без нее, взятых из Интернета. Эти PNG-изображения оптимизированы с помощью convert, pngcrush, ZopfliPNG, и для исследования рассматривается самая маленькая версия каждого изображения.

Рисунок 1. Фотографическое изображение, 1024 x 752 пикселей. Огнедышащее дыхание "Jaipur Maharaja Brass Band" Chassepierre Belgium, Автор: Люк Виатур, Фото лицензировано в соответствии с лицензией Creative Commons Attribution-Share Alike 3.0 Unported. Сайт автора здесь .

Рисунок 2. Графическое изображение, 1024 x 752 пикселей. Коллаж изображений из Google Chart Tools

Чтобы измерить все возможности существующего формата PNG, мы повторно сжали все эти исходные изображения PNG, используя несколько методов:

  1. Зажать до 8 бит на компонент: convert input.png -depth 8 output.png

  2. ImageMagick(1) без предикторов: convert input.png -quality 90 output-candidate.png

  3. ImageMagick с адаптивными предикторами: convert input.png -quality 95 output-candidate.png

  4. Pngcrush(2): pngcrush -brute -rem TXT -rem TIME -rem iTXt -rem zTXt -rem GAMA -rem cHRM -rem iCCP -rem sRGB -rem alla -rem text input.png output-candidate.png

  5. ZopfliPNG(3): zopflipng --lossy_transparent input.png output-candidate.png

  6. ZopfliPNG со всеми фильтрами: zopflipng --iterations=500 --filters=01234mepb --lossy_8bit --lossy_transparent input.png output-candidate.png

Полученные результаты

Мы рассчитали плотность сжатия для каждого изображения в веб-корпусе по отношению к оптимизированным размерам изображений PNG для трех методов:

  1. WebP без потерь (настройки по умолчанию)

  2. WebP без потерь с наименьшим размером (-m 6 -q 100)

  3. лучшее из WebP без потерь и WebP с потерями с альфа-каналом (настройки по умолчанию).

Мы отсортировали эти коэффициенты сжатия и отобразили их на рисунке 3.

Рисунок 3. В качестве эталона используется плотность сжатия PNG, равная 1,0. Одни и те же изображения сжимаются как без потерь, так и с потерями. Для каждого изображения вычисляется отношение размера к сжатому PNG, соотношение размеров сортируется и отображается как для сжатия без потерь, так и для сжатия с потерями. Для кривой сжатия с потерями сжатие без потерь выбирается в тех случаях, когда оно создает изображение WebP меньшего размера.

WebP выходит за рамки плотности сжатия PNG как для libpng с максимальным качеством (конвертация), так и для ZopfliPNG (таблица 1), при этом скорости кодирования (таблица 2) и декодирования (таблица 3) примерно сопоставимы со скоростями PNG.

Таблица 1. Среднее количество битов на пиксель для трех корпусов с использованием различных методов сжатия.

Набор изображений конвертировать -качество 95 ЦопфлиPNG WebP без потерь -q 0 -m 1 WebP без потерь (настройки по умолчанию) WebP без потерь -m 6 -q 100 WebP с потерями с альфа-каналом
Фото 12.3 12.2 10,5 10.1 9,83 0,81
графика 1,36 1,05 0,88 0,71 0,70 0,51
сеть 6,85 5.05 4,42 4.04 3,96 1,92

Таблица 2. Среднее время кодирования для корпусов сжатия и для различных методов сжатия.

Набор изображений конвертировать -качество 95 ЦопфлиPNG WebP без потерь -q 0 -m 1 WebP без потерь (настройки по умолчанию) WebP без потерь -m 6 -q 100 WebP с потерями с альфа-каналом
Фото 0,500 с 8,7 с 0,293 с 0,780 с 8.440 с 0,111 с
графика 0,179 с 14,0 с 0,065 с 0,140 с 3,510 с 0,184 с
сеть 0,040 с 1,55 с 0,017 с 0,072 с 2,454 с 0,020 с

Таблица 3. Среднее время декодирования для трех корпусов файлов изображений, сжатых с использованием различных методов и настроек.

Набор изображений конвертировать -качество 95 ЦопфлиPNG WebP без потерь -q 0 -m 1 WebP без потерь (настройки по умолчанию) WebP без потерь -m 6 -q 100 WebP с потерями с альфа-каналом
Фото 0,027 с 0,026 с 0,027 с 0,026 с 0,027 0,012 с
графика 0,049 с 0,015 с 0,005 с 0,005 с 0,003 0,010 с
сеть 0,007 с 0,005 с 0,003 с 0,003 с 0,003 0,003 с

Профилирование памяти

Для профилирования памяти мы записали максимальный размер набора резидентов, указанный в /usr/bin/time -v.

Для веб-корпуса только размер самого большого изображения определяет максимальное использование памяти. Чтобы лучше определить измерение памяти, мы используем одно фотографическое изображение (рис. 1), чтобы дать обзор использования памяти. Графическое изображение дает аналогичные результаты.

Мы измерили от 10 до 19 МБ для libpng и ZopfliPNG и 25 МБ и 32 МБ для кодирования без потерь WebP при настройках -q 0 -m 1 и -q 95 (со значением по умолчанию -m) соответственно.

В эксперименте по декодированию convert -resize 1x1 использует 10 МБ для PNG-файлов, сгенерированных libpng и ZopfliPNG. Используя cwebp, декодирование WebP без потерь использует 7 МБ, а декодирование с потерями - 3 МБ.

Выводы

Мы показали, что скорости кодирования и декодирования находятся в той же области, что и PNG. На этапе кодирования наблюдается увеличение использования памяти, но на этапе декодирования наблюдается здоровое снижение, по крайней мере, если сравнивать поведение cwebp с поведением Convert ImageMagick.

Плотность сжатия лучше для более чем 99% веб-изображений, что говорит о том, что можно относительно легко перейти с PNG на WebP.

Когда WebP запускается с настройками по умолчанию, он сжимает на 42% лучше, чем libpng, и на 23% лучше, чем ZopfliPNG. Это говорит о том, что WebP перспективен для ускорения веб-сайтов с большим количеством изображений.

использованная литература

  1. ImageMagick

  2. Pngcrush

  3. ЦопфлиPNG

Ниже приведены независимые исследования, не спонсируемые Google, и Google не обязательно поддерживает правильность всего их содержания.

  1. Блог Йоава Вайса