Dra. Jyrki Alakuijala Google, Inc.
Vincent Rabaud, Ph.D., Google, Inc.
Última actualización: 1 de agosto de 2017
Resumen: Comparamos el uso de recursos del codificador o decodificador WebP con el de PNG en modos sin pérdida y con pérdida. Usamos un corpus de 12,000 imágenes PNG translúcidas elegidas al azar de la Web y mediciones más simples para mostrar variaciones en el rendimiento. Recomprimimos los PNG en nuestro corpus para comparar imágenes WebP con PNG optimizados en tamaño. En nuestros resultados, mostramos que WebP es un buen reemplazo de PNG para su uso en la Web con respecto al tamaño y a la velocidad de procesamiento.
Introducción
WebP admite imágenes sin pérdida y translúcidas, lo que la convierte en una alternativa al formato PNG. Muchas de las técnicas fundamentales que se usan en la compresión de PNG, como la codificación de diccionario, la codificación de Huffman y la transformación de la indexación de colores, también se admiten en WebP, lo que da como resultado una velocidad y densidad de compresión similares en el peor de los casos. Al mismo tiempo, varias funciones nuevas, como códigos de entropía independientes para diferentes canales de color, localidad 2D de distancias de referencia anteriores y caché de color de colores utilizados recientemente, permiten una densidad de compresión mejorada con la mayoría de las imágenes.
En este trabajo, comparamos el rendimiento de WebP con los PNG que están altamente comprimidos mediante pngcrush y ZopfliPNG. Recomprimemos nuestro corpus de referencia de imágenes web mediante las prácticas recomendadas y comparamos la compresión WebP con y sin pérdida con este corpus. Además del corpus de referencia, elegimos dos imágenes más grandes, una fotográfica y otra gráfica, para comparar el rendimiento y la velocidad.
Se demostró que la velocidad de decodificación es más rápida que la PNG, así como una compresión un 23% más alta que lo que se puede lograr con el formato PNG actual. Concluimos que WebP es un reemplazo más eficiente del formato de imagen PNG de hoy. Además, la compresión de imágenes con pérdida con compatibilidad Alfa sin pérdida ofrece más posibilidades para acelerar los sitios web.
Métodos
Herramientas de línea de comandos
Usamos las siguientes herramientas de línea de comandos para medir el rendimiento:
cwebp y dwebp. Estas herramientas forman parte de la biblioteca libwebp (compilada a partir de la cabeza).
conversión. Esta es una herramienta de línea de comandos que forma parte del software ImageMagick (6.7.7-10 2017-07-21).
pngcrush 1.8.12 (30 de julio de 2017)
ZopfliPNG (17 de julio de 2017)
Usamos las herramientas de línea de comandos con sus respectivas marcas de control. Por ejemplo, si nos referimos a cwebp -q 1 -m 0, significa que la herramienta cwebp se evocó con las marcas -q 1 y -m 0.
Imagen Corpora
Se eligieron tres empresas:
Una sola imagen fotográfica (Figura 1),
Una sola imagen gráfica con translucidez (Figura 2)
Un corpus web: 12,000 imágenes PNG elegidas al azar con o no transparencia, rastreadas desde Internet Estas imágenes PNG se optimizan a través de la conversión, pngcrush, ZopfliPNG y se considera la versión más pequeña de cada imagen para el estudio.
Figura 1 Imagen fotográfica, 1024 x 752 píxeles Fuego respiratorio “Jaipur Maharaja Brass Band” Chassepierre Bélgica, autor: Luc Viatour, foto con licencia Creative Commons Atribución-CompartirIgual 3.0 Licencia sin portabilidad. El sitio web del autor está aquí.
Figura 2: Imagen gráfica de 1024 x 752 píxeles. Collage de imágenes de Google Chart Tools
Para medir la capacidad total del formato existente, PNG, comprimimos todas estas imágenes PNG originales mediante varios métodos:
Sujeta a 8 bits por componente: convierte input.png -depth 8 output.png
ImageMagick(1) sin predictores: conversion input.png -quality 90 output-candidate.png
ImageMagick con predictores adaptables: convierten input.png -quality 95 output-candidate.png
Pngcrush(2): pngcrush -brute -rem tEXt -rem tIME -rem iTXt -rem zTXt -rem gAMA -rem cHRM -rem iCCP -rem sRGB -rem alla -rem text input.png output-candidate.png
ZopfliPNG(3): zopflipng --lossy_transparent input.png output-candidate.png
ZopfliPNG con todos los filtros: zopflipng --iterations=500 --filters=01234mepb --lossy_8bit --lossy_transparent input.png output-candidate.png
Resultados
Calculamos la densidad de compresión para cada una de las imágenes del corpus web, en relación con los tamaños de imagen PNG optimizados para tres métodos:
WebP sin pérdida (configuración predeterminada)
WebP sin pérdida con el tamaño más pequeño (m-6-q 100)
lo mejor de WebP sin pérdida y WebP con pérdida con alfa (configuración predeterminada).
Ordenamos estos factores de compresión y los trazamos en la figura 3.
Figura 3: La densidad de compresión PNG se utiliza como referencia, en 1.0. Las mismas imágenes se comprimen mediante métodos con y sin pérdida. Para cada imagen, se calcula la proporción de tamaño en comparación con el formato PNG comprimido, y las proporciones se ordenan y se muestran para la compresión con y sin pérdida. Para la curva de compresión con pérdida, la compresión sin pérdida se elige en los casos en los que produce una imagen WebP más pequeña.
WebP va más allá de la densidad de compresión PNG para libpng en calidad máxima (convertir) y ZopfliPNG (Tabla 1), con velocidades de codificación (Tabla 2) y decodificación (Tabla 3) que son similares a las de PNG.
Tabla 1: Promedio de bits por píxel para las tres empresas que usan diferentes métodos de compresión.
| Conjunto de imágenes | convertir -calidad 95 | ZopfliPNG | WebP sin pérdida -q 0 -m 1 | WebP sin pérdida (configuración predeterminada) | WebP sin pérdida -m 6 -q 100 | WebP con pérdida con alfa |
|---|---|---|---|---|---|---|
| foto | 12.3 | 12.2 | 10.5 | 10.1 | 9.83 | 0.81 |
| gráfico | 1.36 | 1.05 | 0.88 | 0.71 | 0.70 | 0.51 |
| web | 6,85 | 5.05 | 4,42 | 4.04 | 3,96 | 1,92 |
Tabla 2: Tiempo de codificación promedio para el cuerpo de compresión y para diferentes métodos de compresión.
| Conjunto de imágenes | convertir -calidad 95 | ZopfliPNG | WebP sin pérdida -q 0 -m 1 | WebP sin pérdida (configuración predeterminada) | WebP sin pérdida -m 6 -q 100 | WebP con pérdida con alfa |
|---|---|---|---|---|---|---|
| foto | 0.500 s | 8.7 s | 0.293 s | 0.780 s | 8.440 s | 0.111 s |
| gráfico | 0.179 s | 14 s | 0.065 s | 0.140 s | 3.510 s | 0.184 s |
| web | 0.040 s | 1.55 s | 0.017 s | 0.072 s | 2.454 s | 0.020 s |
Tabla 3: Tiempo de decodificación promedio para los tres elementos de los archivos de imagen que se comprimen con diferentes métodos y configuraciones.
| Conjunto de imágenes | convertir -calidad 95 | ZopfliPNG | WebP sin pérdida -q 0 -m 1 | WebP sin pérdida (configuración predeterminada) | WebP sin pérdida -m 6 -q 100 | WebP con pérdida con alfa |
|---|---|---|---|---|---|---|
| foto | 0.027 s | 0.026 s | 0.027 s | 0.026 s | 0,027 | 0.012 s |
| gráficos | 0.049 s | 0.015 s | 0.005 s | 0.005 s | 0.003 | 0.010 s |
| web | 0.007 s | 0.005 s | 0.003 s | 0.003 s | 0.003 | 0.003 s |
Creación de perfiles de memoria
Para la generación de perfiles de memoria, registramos el tamaño máximo del conjunto residente según lo informado por /usr/bin/time -v
Para el corpus web, el tamaño de la imagen más grande por sí solo define el uso máximo de la memoria. Para mantener mejor la medición de la memoria, usamos una sola imagen fotográfica (Figura 1) a fin de brindar una descripción general del uso de la memoria. La imagen muestra resultados similares.
Medimos 10 a 19 MiB para libpng y ZopfliPNG, y 25 MiB y 32 MiB para codificación WebP sin pérdida en la configuración -q 0 -m 1 y -q 95 (con un valor predeterminado de -m), respectivamente.
En un experimento de decodificación, la conversión de 1 x 1 usa 10 MiB para los archivos PNG generados por libpng y ZopfliPNG. Con cwebp, la decodificación sin pérdida de WebP usa 7 MiB y la decodificación con pérdida de 3 MiB.
Conclusiones
Hemos demostrado que las velocidades de codificación y decodificación están en el mismo dominio de las de PNG. Hay un aumento en el uso de la memoria durante la fase de codificación, pero la fase de decodificación muestra una disminución saludable, al menos cuando se compara el comportamiento del cwebp con el de la conversión de ImageMagick.
La densidad de compresión es mejor para más del 99% de las imágenes web, lo que sugiere que una puede cambiar con facilidad de PNG a WebP.
Cuando WebP se ejecuta con la configuración predeterminada, comprime un 42% mejor que libpng y un 23% mejor que ZopfliPNG. Esto sugiere que WebP promete prometer la aceleración de sitios web con muchas imágenes.
Referencias
Vínculos externos
Los siguientes son estudios independientes no patrocinados por Google y Google no necesariamente respalda la corrección de todo su contenido.