- libjxl 0.10 reduce el cuello de botella del encoding de JPEG XL que procesaba imágenes grandes de una sola vez mediante una API de encoding por streaming, mejorando mucho el uso de memoria y la velocidad en la compresión sin pérdida
- El encoding sin pérdida de una imagen nocturna de la Tierra de la NASA de 13500×6750 pasó de unos 8 GB de RAM y más de 2 minutos con libjxl 0.9 a 0.7 GB de RAM, 30 segundos con un solo hilo y 5 segundos con 8 hilos en libjxl 0.10
- Comparar métodos de compresión solo por tamaño de archivo no alcanza; el frente de Pareto, que considera velocidad de encoding y densidad de compresión, se vuelve el criterio para elegir la configuración óptima según el presupuesto de tiempo
- En compresión con pérdida hay que mirar al mismo tiempo la tasa de compresión, la velocidad y la calidad visual; en el rango SSIMULACRA2 60~90, JPEG XL muestra resultados especialmente fuertes en la zona de alta calidad a visualmente sin pérdida
- Nuevos encoders JPEG como jpegli siguen siendo competitivos en rangos de encoding muy rápido, pero JPEG XL se posiciona como una opción clave tanto para compresión sin pérdida como con pérdida en un amplio rango de velocidades
Cambios clave en libjxl 0.10
- libjxl 0.10 es la nueva versión de la implementación de referencia de JPEG XL, y su cambio más importante es la implementación completa de la API de encoding por streaming
- Esta API no procesa imágenes grandes de una sola vez, sino que las codifica por chunks
- Reduce la carga de RAM que aparece al cargar toda la imagen en memoria
- También mejora la velocidad de encoding
- El efecto es especialmente notable en la compresión sin pérdida de imágenes grandes
Menos memoria y tiempo en compresión sin pérdida
- Antes de libjxl 0.10, el encoding JPEG XL sin pérdida podía requerir mucha memoria y largos tiempos de procesamiento
- La imagen de ejemplo es la imagen nocturna de la Tierra de la NASA de 13500×6750
- El archivo TIFF pesa 64 MB
- El tamaño antes de comprimir es de 273 MB
- Resultado al comprimir la misma imagen con la configuración effort predeterminada e7:
- libjxl 0.9 usó unos 8 GB de RAM y tardó más de 2 minutos; el archivo resultante fue de 33.7 MB
- Con un solo hilo tardó 2 minutos 40 segundos, y con 8 hilos 2 minutos 6 segundos, por lo que el aumento de hilos no tuvo gran efecto
- El entorno de medición fue una MacBook Pro de noviembre de 2023 con CPU Apple M3 Pro de 12 núcleos y 36 GB de RAM
- En libjxl 0.10, comprimir la misma imagen requiere solo 0.7 GB de RAM
- 30 segundos con un solo hilo
- 5 segundos con 8 hilos
- El archivo resultante fue de 33.2 MB
- Al subir el valor de effort mejora la tasa de compresión, pero la mejora por tiempo de CPU disminuye cada vez más
- De e1 a e2, usar 1 segundo en vez de 0.1 segundos permitió reducir 22 MB
- De e2 a e7, usar 5 segundos en vez de 1 segundo redujo otros 11 MB
- De e7 a e9, reducir 1 MB más requería esperar casi 2 minutos
Compromisos prácticos en la configuración effort
- La configuración de compresión es un compromiso entre tiempo y tamaño de archivo
- En flujos de trabajo de autoría donde se guarda localmente durante la edición de imágenes, no siempre hace falta una compresión fuerte, por lo que un encoding con effort bajo puede ser razonable
- En escenarios de distribución de uno a muchos o de almacenamiento a largo plazo, puede valer la pena gastar más tiempo de CPU para ahorrar algunos MB
Comparar métodos de compresión con el frente de Pareto
- Al comparar técnicas de compresión, mirar solo el tamaño de archivo puede dejar afuera información necesaria para elegir en la práctica
-
Ejes de comparación e interpretación del gráfico
- Los ejes clave son densidad de compresión y velocidad de encoding
- Que un método sea óptimo de Pareto significa que no hay otro método que logre la misma o mejor densidad de compresión en menos tiempo
- El conjunto de métodos óptimos de Pareto es el frente de Pareto
- En el gráfico, el eje vertical es la velocidad de encoding y el eje horizontal son los bits por píxel promedio de la imagen comprimida
- El eje vertical usa megapixels per second y una escala logarítmica para cubrir un rango amplio de velocidades
- Un RGB de 8 bits sin comprimir es 24 bpp
- Más arriba significa más rápido, y más a la izquierda significa mejor tasa de compresión
Resultados de la comparación de compresión sin pérdida
- La versión anterior de libjxl ya producía resultados óptimos de Pareto en todos los rangos de velocidad y generaba archivos más pequeños que PNG, AVIF sin pérdida y WebP sin pérdida
- libjxl 0.10 muestra resultados mejores por una diferencia considerable frente a la versión anterior
- QOI no aparece en el gráfico, pero registró 17 bpp a 154 Mpx/s
- La configuración effort más baja de libjxl comprime hasta 11.5 bpp a 427 Mpx/s
- libjxl fue 2.7 veces más rápido y el archivo resultante fue 32.5% más pequeño
Compresión sin pérdida en imágenes no fotográficas
- Las fotos suelen tener mucho ruido natural, lo que dificulta la compresión sin pérdida; en imágenes no fotográficas los resultados cambian
- En una prueba con 41 imágenes de manga de distintos estilos, el tamaño promedio fue de 7.3 megapíxeles
- Estas imágenes se comprimieron hasta alrededor de 4 bpp, mucho mejor que los cerca de 10 bpp de las imágenes fotográficas
- AVIF sin pérdida no fue útil para este tipo de imagen
- Tuvo una tasa de compresión menor que PNG
- Alcanzó una densidad similar a QOI, pero fue mucho más lento
- WebP sin pérdida mostró una tasa de compresión muy buena en estas imágenes
- QOI es aceptable considerando velocidad y simplicidad, pero está lejos de ser óptimo de Pareto
- El encoding JPEG XL con effort bajo fue 2 veces más rápido que QOI y 31% más pequeño
- libjxl 0.10 también mejora mucho frente a 0.9 en imágenes no fotográficas
- WebP con effort predeterminado: 4.30 bpp, 2.3 Mpx/s
- libjxl 0.9 effort 5: 4.27 bpp, 2.6 Mpx/s
- libjxl 0.10 effort 5: 4.25 bpp, 12.2 Mpx/s
- libjxl 0.10 effort 7: 4.04 bpp, 5.9 Mpx/s
La compresión con pérdida agrega el eje de calidad
- En compresión sin pérdida solo hay que mirar tamaño comprimido y velocidad, pero en compresión con pérdida se suma la calidad visual
- Los códecs y encoders de imagen con pérdida pueden rendir distinto según el punto de calidad
- Que un encoder sea bueno en alta calidad no implica que también lo sea en baja calidad
- Lo contrario también aplica
- Los gráficos bitrate-distortion, que solo muestran tasa de compresión y calidad, dificultan evaluar el compromiso entre effort de encoding y rendimiento de compresión
- Para ver el frente de Pareto de la compresión con pérdida, hay que cortar el espacio tridimensional de compresión, velocidad y calidad en varios puntos de calidad
Medición de calidad y forma de agregación
- La calidad de imagen es subjetiva y puede variar de persona a persona
- La mejor forma de medirla es un experimento donde decenas de personas o más comparen o puntúen imágenes siguiendo un protocolo de prueba estricto
- Como estos experimentos requieren mucho tiempo y costo, y es difícil probar todas las configuraciones de encoders, se usan métricas objetivas
- Entre las métricas públicas consideradas buenas están SSIMULACRA2, Butteraugli y DSSIM
- Intentan modelar el sistema visual humano y se correlacionan bien con evaluaciones subjetivas
- Métricas simples más antiguas como PSNR o SSIM no coinciden bien con el juicio humano de calidad visual
- Si se evalúa con la métrica que el encoder optimiza internamente, los resultados pueden sesgarse a favor de ese encoder
- libjxl con effort alto optimiza Butteraugli
- libavif puede optimizar PSNR o SSIM
- SSIMULACRA2 se trata como una métrica segura porque los encoders probados no la usan para optimización interna
- En la prueba se eligieron configuraciones de encoder para que, al aplicarlas al conjunto completo de imágenes, el puntaje promedio de SSIMULACRA2 quedara cerca de un valor específico
- Alinear por puntaje promedio favorece a WebP y AVIF
- En estudios previos, AVIF y WebP fueron menos consistentes que JPEG y HEIC, mientras que JPEG XL fue el encoder más consistente
- En uso real, quizás convenga alinear según el peor puntaje o la peor calidad visual real
Rango de calidad cercano al uso real
- La compresión con pérdida permite tasas altas como 50:1 o 200:1, pero aparecen artefactos de compresión
- El rango más relevante en uso real es SSIMULACRA2 60~90
- Características por punto de calidad:
- SSIMULACRA2 90: calidad visualmente sin pérdida; códecs modernos como AVIF y JPEG XL pueden alcanzarla con una compresión de alrededor de 8:1, es decir, 3 bpp
- SSIMULACRA2 80: alta calidad; se puede alcanzar con una compresión de alrededor de 16:1, es decir, 1.5 bpp
- SSIMULACRA2 70: calidad media-alta; se puede alcanzar con una compresión de alrededor de 30:1, es decir, 0.8 bpp
- SSIMULACRA2 60: calidad media; se puede alcanzar con una compresión de alrededor de 40:1, es decir, 0.6 bpp
- Una calidad menor que SSIMULACRA2 60 puede reducir más el ancho de banda, pero existe el riesgo de arruinar la imagen
- En la web de 2024, el rango de calidad media a alta es muy relevante
- Según HTTP Archive, la mediana de AVIF en la web es 1 bpp, lo que corresponde a calidad media-alta
- La mediana de JPEG es 2.1 bpp, lo que corresponde a alta calidad
- En casos de uso no web, como cámaras, el rango de alta calidad a visualmente sin pérdida es más relevante
Resultados del frente de Pareto en compresión con pérdida
- Las pruebas de compresión con pérdida se realizaron con las versiones más recientes de cada encoder a fines de febrero de 2024
- La velocidad de encoding se midió con 8 hilos en una MacBook Pro de noviembre de 2023 con Apple M3 Pro
- AVIF se probó tanto con configuración con tiles como sin tiles
- La configuración con tiles aprovecha mejor el multithreading y es más rápida
- A cambio, pierde densidad de compresión
Calidad media: SSIMULACRA2 60
- Incluso dentro del mismo formato hubo grandes diferencias según el encoder y la configuración effort
- La configuración predeterminada de libjpeg-turbo, un encoder JPEG históricamente muy usado, aparece en el gráfico como la más rápida, pero con baja densidad de compresión
- WebP tuvo mejor densidad de compresión que libjpeg-turbo
- mozjpeg es más lento que libjpeg-turbo, pero ofrece mejores resultados de compresión, y en este conjunto de imágenes y punto de calidad fue más eficiente de Pareto que WebP
- jpegli, creado por el equipo de JPEG XL de Google, fue más rápido que mozjpeg y comprimió mejor
- Se basa en lecciones aprendidas de guetzli y libjxl
- Comprime mejor que WebP y AVIF rápido, aunque genera archivos JPEG existentes
- AVIF y HEIC pueden lograr mejor densidad de compresión que JPEG y WebP, pero el encoding es más lento
- JPEG XL alcanza densidades de compresión similares con un encoding mucho más rápido
- El frente de Pareto en este punto de calidad está formado por JPEG XL y varios encoders JPEG en rangos de velocidad razonables, y por AVIF en los rangos más lentos
Resultados en calidad media-alta y alta
- En calidad media-alta SSIMULACRA2 70, el resultado general fue similar al de calidad media
- Como punto de calidad más alto relevante para la web se usó un SSIMULACRA2 promedio de 85, con la configuración ajustada para que la mayoría de las imágenes alcanzaran 80 o más
- En este punto de alta calidad, las diferencias se vuelven más claras
- mozjpeg ya no logró superar a WebP
- jpegli siguió superando a WebP
- El frente de Pareto quedó ocupado en su mayor parte por JPEG XL
- En encoding muy rápido, JPEG tradicional siguió siendo bueno
- En este punto de calidad, AVIF no apareció en el frente de Pareto
- En su configuración más lenta, a menos de 0.5 Mpx/s, igualó la densidad de compresión de la segunda configuración más rápida de libjxl
- Esa configuración de libjxl alcanzó 52 Mpx/s, más de 100 veces más rápido
Velocidad de decodificación
- Hasta ahora, la comparación se centró en densidad de compresión y velocidad de encoding
- En computadoras modernas, la velocidad de decodificación no suele ser un gran problema, pero también se compararon mediciones
- JPEG secuencial es el más fuerte en velocidad de decodificación
- Los JPEG progresivos generados por mozjpeg y jpegli por defecto son más lentos, pero lo bastante rápidos para cargar imágenes de tamaño razonable muy rápidamente
- JPEG XL se ubica entre JPEG secuencial y JPEG progresivo
- La velocidad de decodificación de AVIF depende del método de encoding
- Si se usa encoding multitile, más rápido pero ligeramente peor, la decodificación también es más rápida
- El encoding single-tile predeterminado es más lento
- Incluso la velocidad de decodificación más lenta medida es bastante rápida comparada con la velocidad de encoding
Visualmente sin pérdida e imágenes grandes
- WebP no se incluyó en el gráfico de calidad visualmente sin pérdida
- No podía alcanzar este punto de calidad en modo con pérdida
- Esto se debe a que WebP exige submuestreo de croma 4:2:0
- mozjpeg tampoco está diseñado para este punto de calidad, por lo que fue peor que libjpeg-turbo tanto en compresión como en velocidad
- Con la configuración de velocidad predeterminada, libavif fue 20% más pequeño que libjpeg-turbo, pero el encoding tardó un orden de magnitud más
- En el mismo punto de calidad, libjxl fue 20% más pequeño que libavif y 2.5 veces más rápido
- El frente de Pareto de calidad visualmente sin pérdida estuvo ocupado en su mayor parte por JPEG XL, y en los rangos de mayor velocidad también incluyó JPEG
- A diferencia de la prueba con imágenes de tamaño web, de aproximadamente 1 megapíxel, en una prueba con imágenes más grandes los resultados cambiaron mucho
- En el punto de alta calidad, WebP, mozjpeg y AVIF fueron peores que libjpeg-turbo
- HEIC ofreció ahorros considerables frente a libjpeg-turbo
- jpegli también ofreció ahorros considerables con mejor velocidad
- JPEG XL comprimió las imágenes por debajo de 1.3 bpp, mientras que AVIF, libjpeg-turbo y WebP necesitaron 2 bpp o más
Posición final de libjxl 0.10
- libjxl 0.10 reduce el uso de memoria en compresión sin pérdida y con pérdida en un orden de magnitud
- La velocidad también mejoró, y en particular la configuración effort predeterminada para encoding sin pérdida multihilo se volvió un orden de magnitud más rápida
- JPEG XL se perfila como un códec de imagen fuerte tanto en compresión sin pérdida como con pérdida, especialmente en el rango de calidad de alta calidad a visualmente sin pérdida
- En un amplio rango de configuraciones de velocidad, JPEG XL sigue siendo una opción cercana al óptimo de Pareto
- JPEG tradicional también sigue siendo atractivo gracias a nuevos encoders
- jpegli mejora mucho frente a mozjpeg tanto en velocidad como en compresión
- Cuando se necesita encoding extremadamente rápido, JPEG tradicional todavía puede ser la mejor opción
2 comentarios
Parece que el codificador jpegli está volviendo a alargarle la vida al JPG, después de mozjpeg...
Aunque fue creado por el bando de JXL, irónicamente podría terminar frenando la adopción de JXL...
Opiniones de Hacker News
También hay que destacar lo bueno que es WebP sin pérdida.
Aunque queda bastante tapado por la idea de que WebP no tiene ventajas claras frente al encoding con MozJPEG, o incluso es peor, WebP sin pérdida es realmente excelente en rendimiento y velocidad.
Es mucho mejor que PNG u OptiPNG, ya tiene suficiente soporte en línea y, por supuesto, supera por mucho al pésimo AVIF sin pérdida.
Para imágenes SDR está bien, pero para HDR se vuelve una limitación fundamental, como que GIF esté limitado a 256 colores.
Si vas a comprimir un cómic completo, PNG sigue siendo lo correcto, y en ese caso conviene usar oxipng en lugar del prácticamente abandonado optipng.
Otro punto que falta aquí: JPEG2000 sin pérdida puede ser sorprendentemente bueno y rápido con contenido fotográfico.
Para la mayoría de los usos puede ser preferible al sin pérdida real y, además, muchas veces reduce el tamaño a la mitad sin pérdidas visibles.
En configuraciones de calidad muy baja, aunque JPEG se vea hecho un desastre de cerca, casi como una pintura cubista por sus artefactos visibles, sorprende que conserve una aproximación de detalles nítidos que preserva mejor la calidad general de la imagen.
En la práctica convierte la imagen en una especie de estilo de arte abstracto, mientras que JXL y AVIF simplemente se vuelven borrosos.
Estas imágenes no buscan la misma tasa de compresión, sino el mismo nivel de distorsión, y los bits por píxel se muestran junto a cada imagen.
En internet real, usar calidad 65 es raro y se ve más bien en sitios de calidad mínima; calidad 75 es una baja calidad común, y calidad 85 está más cerca del promedio.
Cuando hace falta compresión, se usa calidad 94 yuv444 o superior.
El bitrate está en la columna izquierda, y el JPG de baja calidad tiene el mismo tamaño que el 0.4bpp de calidad media-baja de JXL/AVIF, así que hay que comparar la imagen de abajo a la izquierda con la de arriba al centro y la de la derecha.
No hay que dejarse llevar por una comparación incorrecta; JXL y AVIF también se ven mucho mejor si se les da el doble de tamaño de archivo.
SSIMULACRA2 parece castigar mucho los artefactos de bloque, pero no le presta demasiada atención al desenfoque, y coincido en que, con el mismo puntaje SSIMULACRA2, la versión JPEG se ve mejor.
No entiendo por qué este artículo se enfoca tanto en la velocidad de encoding, pero trata por encima el decoding, que en entornos de conexión web diría que representa el 99% del uso.
Lo despacha con algo como: “la velocidad de decoding no es un gran problema en computadoras modernas, pero es interesante ver los números rápidamente”.
A partir de ese punto, el cuello de botella ya no es el decoding.
La mayoría de los algoritmos modernos de compresión son asimétricos, así que aunque dediquen mucho más tiempo a comprimir, eso no afecta demasiado el rendimiento de descompresión; una vez alcanzado el rendimiento básico, se vuelve menos importante.
Si fuera posible, eso sería una razón poderosa para preferirlos sobre JPEG XL, que hoy tendría que decodificarse por software en todo el hardware actual.
La decodificación de H264 está en todas partes, y la de AV1 también se está convirtiendo de forma constante en una función estándar.
Basta con que el cliente pueda decodificar las pocas imágenes de una página lo bastante rápido como para que una persona no lo note; en cambio, cualquier mejora de algunos puntos porcentuales en encoding puede reducir costos reales.
De hecho, gastan millones de dólares en encoding de imágenes.
Me dio risa ver QOI incluido en el benchmark sin pérdida.
Es un formato básicamente irrelevante, sin soporte nativo en software de uso general y cuyo objetivo es ser simplemente aceptable más que bueno, pero aun así es interesante que haya ocupado un lugar en la gráfica de encoding no fotográfico.
Por eso GameMaker Studio y los juegos creados más o menos en los últimos dos años sí usan QOI internamente.
No es algo que el consumidor use conscientemente, pero tampoco es justo decir que sea completamente irrelevante.
En retrospectiva es obvio: la decodificación de QOI es inherentemente secuencial, así que no se puede paralelizar fácilmente.
Me pregunto si lo excelente de JXL se debe al formato en sí o al encoder.
Su capacidad de crear imágenes pequeñas y de alta calidad con solo
-d 1.0es casi extraña; con otros códecs, para obtener resultados similares había que ajustar la calidad de forma distinta según el tipo de imagen.A este ritmo de desarrollo, no me sorprendería que libjxl se convierta en el x264 de los encoders de imágenes.
En cambio, libvpx siempre fue un encoder más bien común, y creo que eso podría explicar el rendimiento decepcionante del formato vp8/vp9, no solo en velocidad sino en desempeño general.
Eso inevitablemente también afectó el rendimiento de WebP con pérdida, y Dark Shikari llegó a comparar el rendimiento de imágenes estáticas de x264 y vp8 [0].
[0] https://web.archive.org/web/20150419071902/http://x264dev.mu...
Se mantuvo mucho enfoque en lo visualmente sin pérdida, y no queríamos incluir funciones de formato que solo aumentaran la complejidad sin ayudar en configuraciones de alta calidad.
Además de las funciones de modelado, el modelado de contexto y la eficiencia de la codificación entrópica son muy importantes en alta calidad.
Creo que la codificación entrópica de AVIF no encaja bien con fotos de alta calidad o sin pérdida.
-d 1.0.Vale la pena mencionar que del trabajo en JPEG XL también salió una excelente nueva biblioteca de paralelización llamada Highway.
Esta biblioteca se usa no solo en JPEG XL, sino también en los modelos de IA Gemma más recientes de Google.
También se trata en [1], que empieza así: “Hoy compartimos código open source que ordena arreglos de números aproximadamente 10 veces más rápido que
std::sortde C++, y que, manteniendo la portabilidad en todas las arquitecturas modernas de CPU, supera incluso a algoritmos recientes específicos por arquitectura. A continuación discutimos cómo logramos esto”.[0] https://github.com/google/highway
[1] https://opensource.googleblog.com/2022/06/Vectorized%20and%2..., el paper relacionado está en https://arxiv.org/pdf/2205.05982.pdf
Parece la mejor forma de obtener SIMD portable en C++.
Más allá de cuánto brille JPEG XL por sí mismo, ya es sin duda impresionante que pueda hacer lo siguiente.
a.jpgtiene 615504 bytes y su SHA-1 es716744d950ecf9e5757c565041143775a810e10f.Al ejecutar
cjxl a.jpg a.jxl, lee el JPEG de 615504 bytes y lo comprime a 537339 bytes, incluyendo el contenedor.Pero al ejecutar
djxl a.jxl b.jpg, lee los 537339 bytes de datos comprimidos y reconstruye el JPEG;b.jpgtambién tiene 615504 bytes y el SHA-1 es exactamente el mismo.Si pensamos que hay miles de millones de archivos JPEG en el mundo que querríamos conservar, recomprimir un JPEG existente en un formato con pérdida reduce la calidad.
Pero JPEG XL permite ahorrar entre 15 y 30% y, si uno quiere, recuperar el JPG original 100% idéntico bit a bit.
Es realmente genial.
Lamentablemente uso Debian stable 12 Bookworm con ImageMagick 6.9, y entiendo que Emacs probablemente usa ImageMagick para mostrar imágenes.
El soporte para JPEG XL recién se agregó en ImageMagick 7, y todavía no investigué más.
Creo que ayudará a preservar intacto el patrimonio digital sin recodificación con pérdida.
Es muy impresionante que la nueva versión de libjxl haya reducido el uso de memoria en un orden de magnitud tanto en compresión con pérdida como sin pérdida, y que además haya mejorado la velocidad.
Me gusta especialmente la parte en que la configuración de esfuerzo predeterminada para codificación sin pérdida multihilo ahora es un orden de magnitud más rápida, y el artículo también está muy bien escrito.
Me pregunto si hay algún sitio web que explique en detalle cada etapa del formato JPEG XL.
A diferencia del JPEG tradicional, me costó encontrar documentación que guiara claramente por las etapas relacionadas, y es una lástima porque este formato claramente reúne muchas innovaciones interesantes.
Incluso los componentes individuales parecen útiles por sí mismos.
La clave es una DCT de tamaño variable de hasta 128x128, predicción entrópica ANS y predicción de crominancia basada en luminancia.
https://github.com/libjxl/libjxl/blob/main/doc/encode_effort... también muestra bien la separación de funciones por nivel de esfuerzo.
Al artículo le falta rav1e, que codifica AV1 y por lo tanto AVIF.
rav1e es mucho más rápido que aom, la implementación de referencia, y hubo casos en los que aom no terminaba de convertir una imagen ni esperando 1 minuto, mientras que rav1e tardaba menos de 10 segundos.
También me pregunto si el rápido rav1e se ve mejor que jpegli a velocidades altas de codificación.
A velocidades similares, no he visto grandes diferencias de rendimiento de compresión entre ambos.