Reflexionar cuidadosamente sobre las comparaciones de códecs

Cuando llegó la noticia de que Chrome dejaría de experimentar con JPEG XL (https://es.news.hada.io/topic?id=7709), el issue tracker se llenó de preguntas sobre por qué lo estaban eliminando. En respuesta, del lado de AVIF llegaron a publicar material de benchmarks que ellos mismos compararon para defender su postura (https://storage.googleapis.com/avif-comparison/index.html). Este artículo es un análisis de ese material y la refutación desde el lado de JPEG XL.

Más allá de estar simplemente a favor o en contra de JPEG XL, vale la pena leerlo porque señala puntos importantes sobre cómo comparar formatos de imagen. Si resumimos solo algunas ideas clave:

• La velocidad de decodificación del lado de AVIF se basaba en Chrome y en una versión antigua de libjxl, por lo que está exagerada. Tomando como referencia versiones recientes, JPEG XL (configuración predeterminada) ~= AVIF de 12 bits < JPEG XL (configuración de decodificación rápida) ~= AVIF de 8 bits < JPEG XL recompreso desde JPEG, y cada desigualdad representa apenas una diferencia de alrededor del 10%.

• Más importante que la velocidad total de decodificación es en qué momento aparece una imagen utilizable, y JPEG XL tiene una gran ventaja aquí porque soporta decodificación progresiva (progressive). (Es el mismo contexto en el que en la web se habla de cosas como Largest Contentful Paint).

• Se están comparando por separado el rendimiento de codificación y la calidad de la imagen codificada, pero libjxl permite ajustar de manera completamente independiente el rendimiento de codificación y la calidad de codificación, mientras que la mayoría de los otros codificadores, incluido AVIF, no pueden hacer eso, por lo que no es posible compararlos de esa manera.

• El rango de calidad objetivo presentado para la codificación es demasiado amplio y no considera la distribución de probabilidad. La calidad más baja, etiquetada como "On the fly", es tan mala que nadie podría usarla para ningún propósito. Además, AVIF tiende a ser fuerte en imágenes de baja calidad en promedio, pero en muchos casos JPEG XL toma una gran ventaja apenas aumenta un poco el tamaño del archivo; al promediarlo con un método inadecuado, eso terminó diluyendo las fortalezas de JPEG XL.

• El conjunto de datos usado en las pruebas es inapropiado. Para compresión sin pérdida se usa el conjunto Kodak, que consiste en escaneos de imágenes de revista, y para compresión con pérdida se incluye el conjunto Noto Emoji, que normalmente se usa como gráficos vectoriales o con compresión sin pérdida; en ambos casos no son ejemplos típicos de uso general de compresión sin pérdida y con pérdida.

• Si el rendimiento de compresión de imágenes es una discusión sobre el presente, las funciones que soporta un formato de imagen son para el futuro. Si no se puede quitar de un navegador un formato de imagen una vez que entra, entonces con mayor razón debería evaluarse poniendo el foco en sus capacidades.

[lifthrasiir]

Como lo escribí apurado antes de ir al trabajo, hay algunos errores menores (...): estrictamente hablando, "on the fly" no es la calidad más baja sino la mayor velocidad (aunque, salvo en JPEG XL, en la mayoría de los codificadores tiene una correlación inversa con la calidad). Además, sobre el conjunto de datos Kodak, no sé en qué estaba pensando cuando escribí que era una revista; en realidad fue escaneado a partir de película.

[xguru]

Pensar cuidadosamente en la comparación de códecs