En 2007, escribí un artículo sobre el uso de PNGOUT para generar imágenes PNG muy pequeñas. Todavía menciono este tema a menudo, porque hoy, 8 años después, es probable que las imágenes PNG que veo casualmente en Internet no estén optimizadas.
Por ejemplo, eche un vistazo a esta imagen de dibujos animados publicada recientemente en pbfcomics.com:
Guarde la imagen directamente desde el sitio web, encontramos que esta caricatura es una imagen PNG de 800 x 1412, 32 bits, y el tamaño del archivo es 671012 bytes. Guardémoslo en varios formatos diferentes (sin pérdida) para ver cuánto espacio ocupa esta imagen:
- BMP, 24 bits 3.388.854
- BMP, 8 bits 1,130,678
- GIF, 8 bits, sin jitter 147,290
- GIF, 8 bits, jitter máximo 283,162
- PNG, 32 bits 671,012
PNG funciona bien porque utiliza un algoritmo de compresión como GIF; a diferencia de GIF, la profundidad de bits de la imagen no se limitará a los desagradables 8 bits (256 colores). Ahora, usemos PNGOUT (haga clic aquí para descargar) para solucionarlo y ver qué sucede.
- Original PNG 671,012
- PNG alrededor de 623,859 7%
Obtenga un PNG desde cualquier lugar y proceselo con PNGOUT. Es probable que obtenga una reducción del tamaño del archivo de aproximadamente un 10%, tal vez más. Recuerde, ¡esto es compresión sin pérdidas! La calidad de la imagen de salida es exactamente la misma. Los archivos transferidos en línea serán más pequeños y cuanto más pequeño sea el archivo, más rápida será la descompresión. Estudiantes, ¡esto es ancho de banda gratis! ¿Hay algo mejor que esto?
Bueno, realmente lo hay ...
En 2013, Google introdujo un nuevo algoritmo que es totalmente compatible con versiones anteriores, al que llamaron Zopfli:
La salida producida por Zopfli suele ser un 3 ~ 8% menor que zlib en la relación de compresión máxima . Creemos que Zopfli representa el estado actual del arte del algoritmo de compresión Deflate. Para la portabilidad, Zopfli está escrito en lenguaje C. Esta biblioteca solo admite compresión; el software existente puede descomprimirla. Zopfli con gzip , Zip , PNG , la compresión HTTP se utiliza para solicitar otro flujo de bits compatible.
Lo siento mucho, ¡me enteré de esta situación demasiado tarde! Verifiquemos sus palabras en negrita. Experimente con la imagen de arriba ¿Qué pasará?
- Original PNG 671,012
- PNG alrededor de 623,859 7%
- ZopfliPNG 585,117 13%
¡Se ve genial! Sin embargo, eso es solo una imagen. En speech.org, a todos nos gusta usar emoticonos. Probemos la primera versión de Emoji One: es un conjunto de 842 archivos PNG de 64 x 64, 32 bits:
- Original PNG 2,328,243
- PNG alrededor de 1,969,973 15%
- ZopfliPNG 1,698,322 27%
¡Vaya, cómo puedo perderme algo tan bueno!
En mis pruebas, las imágenes PNG procesadas por Zopfli son siempre un 3 ~ 8% más pequeñas que PNGOUT, aunque PNGOUT ya es muy poderoso, ¡este es un logro increíble! Además, cualquier recurso que utilice compresión gzip estándar puede beneficiarse de Zopfli, como jQuery:
Echemos un vistazo a varias pruebas de compresión estándar:
Material de exámen |
gzip -9 |
kzip |
Zopfli |
Alexa 10k |
128 MB |
125 MB |
124 MB |
1017 KB |
979 KB |
975 KB |
|
731 KB |
674 KB |
670 KB |
|
36 MB |
35 MB |
35 MB |
(Es extraño, no había oído hablar de kzip antes. Resultó que era una obra maestra de nuestro viejo amigo Ken Silverman. Es posible que haya usado la misma técnica de compresión que la herramienta PNGOUT).
Sin embargo, hay un problema, porque el problema siempre está ahí, también es 80 veces más lento . No, no me equivoqué. ¡Lo leíste bien!
- gzip -9 5,6 s
- 7zip mm = desinflar mx = 9 128s
- Kzip 336s
- Zopfli 454s
La compresión Gzip es generalmente más rápida que la tabla anterior, porque el noveno nivel es más lento:
|
hora |
Talla |
gzip -1 |
11,5 s |
40,6% |
gzip -2 |
12,0 s |
39,9% |
gzip -3 |
13,7 s |
39,3% |
gzip -4 |
15,1 s |
38,2% |
gzip -5 |
18,4 s |
37,5% |
gzip -6 |
24,5 s |
37,2% |
gzip -7 |
29,4 s |
37,1% |
gzip -8 |
45,5 s |
37,1% |
gzip -9 |
66,9 s |
37,0% |
Verá, ¿vale la pena el doble de tiempo de CPU para obtener la diferencia de 0.1% en la relación de compresión entre gzip -7 y gzip -9? Comencemos un poco, es por eso que los niveles o modos de compresión "extremos" de casi todas las herramientas de compresión generalmente no son confiables. Se cae rápidamente por el borde del acantilado del algoritmo, por lo que debe permanecer en el medio de la curva o en la posición más ideal, que suele ser el nivel de compresión predeterminado. Siempre eligen esos parámetros predeterminados por una razón.
PNGOUT tampoco es rápido, no se apresure a usarlo; imagine que comprimir una imagen o un archivo será 80 veces más lento (¡esta es una buena situación!), Esto definitivamente es prohibitivo. Si solo está trabajando con imágenes pequeñas, es posible que no note este problema. Pero si el PNG es relativamente grande, básicamente puedes salir y comer un sándwich; o si tienes una CPU de varios núcleos, el tiempo de procesamiento del PNG es suficiente para que puedas comer de 4 a 16 sándwiches. Es por eso que puede que no sea prudente usar Zopfli para procesar imágenes cargadas por el usuario, porque el primer servidor que intente procesar imágenes PNG de 10k x 10k con Zopfli caerá en el abismo de la desesperación.
Sin embargo, recuerde que la velocidad de descompresión es la misma y absolutamente segura. Esto significa que es posible que solo desee usar Zopfli para procesar algunos recursos que se pueden preprocesar, es decir, comprimir una vez y luego usarse para descargar escenas millones de veces; esto es cuando sus usuarios cargan algunas imágenes PNG, sin importar lo que piense sobre ellas Cuán optimizada está la imagen, los escenarios de la aplicación solo se pueden ver cientos o miles de veces como máximo.
Dar un ejemplo. En speech.org, tenemos un renderizador de avatar predeterminado que puede generar un bonito avatar en formato PNG para los usuarios en función de la primera letra de su nombre de usuario y elegir un color según el valor hash del nombre de usuario. . Oh, sí, también usamos Roboto, una hermosa fuente de código abierto de Google.
Pasamos mucho tiempo optimizando la salida de imágenes de avatar, porque estos avatares se usarán millones de veces. Basado en estas limitaciones:
- 10 números
- 26 letras
- Cerca de 256 colores
- 5 tamaños
No es descabellado generar estos avatares de antemano para que sean 45.000 archivos. También tenemos un https CDN central al que pueden acceder todas las instancias de discurso.org, y también se puede usar para implementar estas imágenes de avatar si es necesario, lo que puede reducir aún más la carga y aumentar la tasa de aciertos del caché.
Debido a que estas imágenes son todas monocromas, para ahorrar espacio, reduje la paleta a 8 bits (en realidad se usaron 128 colores). Por supuesto, optimicé estos archivos con PNGOUT. Son casi tan pequeños como el límite. Cuando ejecuté Zopfli en estos archivos de avatar, estaba muy emocionado porque esperaba ver una reducción del 3 ~ 8% en el tamaño del archivo. Sin embargo, después de ejecutar el comando de procesamiento, lo que veo es ... 1 byte, 5 bytes y 2 bytes se guardan respectivamente ... ¡Estoy un poco triste!
(Sí, es técnicamente factible generar imágenes PNG "con pérdida". Aunque es un poco extraño, creo que va en contra del espíritu de PNG: ¡está hecho para imágenes sin pérdida! Imagen, luego use JPEG u otros formatos).
La característica más importante de Zopfli es que, asumiendo que no le importan los requisitos de CPU extremadamente altos, es un paso de optimización de una sola vez de "usarlo y perderlo", puede aplicarlo en cualquier lugar sin ningún daño. Bueno, excepto que puede quemar muchos ciclos inactivos de CPU.
Si está involucrado en un proyecto que requiere material comprimido, eche un vistazo más de cerca a Zopfli. No es una solución milagrosa, después de escuchar las sugerencias anteriores, puede probarlo con sus propios archivos, pero para aquellos en nuestro negocio, ¡realmente nos brinda ancho de banda gratis!