Dra. Jyrki Alakuijala, Google, Inc.
Dr. Vincent Rabaud, Google Inc.
Última actualización: 1/8/2017
Resumen: Comparamos el uso de recursos del codificador o decodificador WebP con el de PNG en los modos con y sin pérdida. Usamos un corpus de 12,000 imágenes PNG translúcidas y translúcidas de la Web elegidas al azar, y mediciones más simples para mostrar las variaciones en el rendimiento. Volvimos a comprimir los PNG en nuestro corpus para comparar las imágenes WebP con los PNG con optimización de tamaño. En nuestros resultados, mostramos que WebP es un buen reemplazo del PNG para usar en la Web en términos de tamaño y velocidad de procesamiento.
Introducción
WebP admite imágenes sin pérdida y translúcidas, lo que lo 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 Huffman y la transformación de indexación de colores, también son compatibles con WebP, lo que da como resultado una velocidad y una 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 inversas y una caché de colores de colores utilizados recientemente) permiten mejorar la densidad de compresión en la mayoría de las imágenes.
En este trabajo, comparamos el rendimiento de WebP con los PNG que están altamente comprimidos con pngcrush y ZopfliPNG. Recomprimimos nuestro corpus de imágenes web siguiendo 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 la otra gráfica, para realizar comparativas de velocidad y uso de memoria.
Se demostraron velocidades de decodificación más rápidas que PNG y una compresión un 23% más densa que la que se puede lograr con el formato PNG actual. Concluimos que WebP es un reemplazo más eficiente del formato de imagen PNG actual. Además, la compresión de imagen con pérdida y compatibilidad con alfa sin pérdidas brinda 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 que forman parte de la biblioteca libwebp (compilada desde la cabeza)
generar conversiones. Esta es una herramienta de línea de comandos que forma parte del software de 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.
Corpus de imágenes
Se eligieron tres corpus:
Una sola imagen fotográfica (Figura 1),
Una sola imagen gráfica con translucencia (Figura 2)
Un corpus web: 12,000 imágenes PNG elegidas al azar con translucencia o no, rastreadas desde Internet. Estas imágenes en formato PNG se optimizan mediante 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 de 1024 x 752 píxeles. Respiración de fuego "Jaipur Maharaja Brass Band" Chassepierre Bélgica, autor: Luc Viatour, foto con licencia de Creative Commons Attribution-Share Alike 3.0 Unported License. Aquí encontrarás el sitio web del autor.
Figura 2: Imagen gráfica de 1024 × 752 píxeles Imágenes de collage de Herramientas de gráficos de Google
Para medir la capacidad completa del formato existente, PNG, volvimos a comprimir todas estas imágenes PNG originales usando varios métodos:
Sujeto a 8 bits por componente: Convierte input.png -depth 8 output.png.
ImageMagick(1) sin predictores: convierte input.png -quality 90 output-candidate.png.
ImageMagick con predictores adaptables: convierte 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 en el 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 representamos en la Figura 3.
Figura 3: La densidad de compresión de PNG se usa 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 relación de tamaño con respecto al archivo PNG comprimido, las relaciones de tamaño se ordenan y se muestran para la compresión con y sin pérdida. Para la curva de compresión con pérdida, se elige la compresión sin pérdida 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 de PNG para libpng a calidad máxima (conversión) y ZopfliPNG (Tabla 1), con velocidades de codificación (Tabla 2) y de decodificación (Tabla 3) que son más o menos comparables con las de PNG.
Tabla 1: Promedio de bits por píxel para los tres corpus mediante los 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 corpus de compresión y para los 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.0 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 de los tres corpus para 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 |
| graphics | 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, tal como lo informa /usr/bin/time -v.
Para el corpus web, solo el tamaño de la imagen más grande define el uso máximo de memoria. Para mantener mejor definida la medición de la memoria, usamos una sola imagen fotográfica (Figura 1) que brinda una descripción general del uso de la memoria. La imagen gráfica arroja resultados similares.
Medimos 10 a 19 MiB para libpng y ZopfliPNG, y 25 MiB y 32 MiB para la codificación sin pérdida de WebP 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 -resize 1x1 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
Demostramos que las velocidades de codificación y decodificación están en el mismo dominio que las de PNG. Hay un aumento en el uso de memoria durante la fase de codificación, pero la de decodificación muestra una disminución saludable, al menos cuando se compara el comportamiento de 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 es posible cambiar de PNG a WebP con facilidad.
Cuando se ejecuta WebP con la configuración predeterminada, se comprime un 42% mejor que libpng y un 23% mejor que ZopfliPNG. Esto sugiere que WebP promete acelerar los sitios web con muchas imágenes.
Referencias
Vínculos externos
Los siguientes son estudios independientes que no patrocina Google, y Google no necesariamente respalda la exactitud de todos sus contenidos.