La calidad perceptual y cómo elegirla sin ojo

El parámetro de calidad de un codificador no mide calidad: mide cuánto va a cuantizar, y cada codificador lo interpreta a su manera. Fijar un número global para todo el catálogo produce imágenes con artefactos visibles y otras con el triple de bytes de los necesarios, a la vez. La alternativa no es mirar cada imagen: es medirla con una métrica que correlacione con lo que ve una persona.

Calidad 80 no es una unidad

El parámetro de calidad es un mando que controla la agresividad de la cuantización, y la relación entre ese mando y el resultado perceptual la define cada implementación. No hay ninguna norma que la fije.

El propio proyecto que mantiene la métrica de referencia publica las equivalencias, y son ilustrativas: una puntuación de 70, descrita como “calidad alta, artefactos perceptibles pero no molestos”, corresponde a la salida típica de un JPEG con crominancia reducida a calidad 70. Una puntuación de 90, “visualmente sin pérdida”, corresponde a un JPEG con crominancia completa a calidad 95. El mismo salto perceptual, de 70 a 90, se recorre en el mando de calidad de 70 a 95, y solo si además cambias el submuestreo de crominancia.

Cruza eso con tres codificadores distintos y con imágenes de contenido distinto y el resultado es el que se ve en cualquier catálogo real: la foto de producto sobre fondo blanco queda perfecta a calidad 50 y estás sirviéndola a 85, mientras que la fotografía con follaje y textura tiene bloques visibles a esa misma calidad 85.

El parámetro correcto no es global, es por imagen, y no se elige a ojo.

Por qué el ojo es mal instrumento

Cuatro razones, y todas empujan a comprimir menos de lo necesario.

Sabes dónde mirar. Has visto el original. Tu atención va directa a la zona que has tocado, que es precisamente donde el usuario nunca mira.

Comparas en paralelo. Poner las dos versiones una al lado de la otra es la prueba más dura que existe, y no es la que vive nadie. El usuario ve una imagen, sin referencia. La escala de la métrica distingue explícitamente esos escenarios: hay una puntuación para “indistinguible en comparación lado a lado” y otra, más alta, para “indistinguible en un test de parpadeo”.

Tu pantalla no es la suya. Un portátil calibrado a 400 nits en una habitación oscura muestra artefactos que un móvil al sol no puede mostrar.

Te adaptas. Después de veinte imágenes tu umbral se ha movido, y el criterio de la imagen veinte no es el de la primera.

Las métricas y su correlación medida

Aquí no hay que opinar: existen conjuntos de datos con decenas de miles de valoraciones humanas y cada métrica tiene su correlación medida contra ellos. Estos son los coeficientes de correlación de rango de Spearman sobre el conjunto de validación de CID22, que son 4.292 valoraciones subjetivas no usadas para ajustar ninguna métrica:

Las cifras están en valor absoluto; las métricas donde menos es mejor dan correlación negativa en la publicación original.

Qué es cada una, en una frase.

PSNR compara píxeles y nada más. Es la que sale por defecto en muchas herramientas y la que peor correlaciona: penaliza igual un error invisible en una zona texturada que un error obvio en un cielo liso.

SSIM y MS-SSIM comparan estructura local en varias escalas. Fueron un salto enorme sobre PSNR y no están diseñadas para artefactos de compresión concretos como el zumbido alrededor de los bordes.

Butteraugli estima la distancia psicovisual entre dos imágenes y está pensada para localizar el umbral de diferencia apenas perceptible. Es la que usan internamente varios codificadores como modo de ajuste.

DSSIM es una variante multiescala de SSIM, muy fácil de instalar y con una correlación notable.

SSIMULACRA 2 trabaja en un espacio de color perceptual, hace el escalado en luz lineal, y suma a la comparación estructural dos mapas de error asimétricos: uno que detecta que la imagen comprimida tiene bordes donde el original era liso, que es el zumbido y el bloqueo, y otro que detecta que es lisa donde el original tenía detalle, que es el emborronamiento. Calcula esos tres mapas en seis escalas y sobre tres componentes de color, y combina 108 valores en una puntuación. Es la que mejor correlaciona y la que conviene usar por defecto.

La escala, con su significado

El proyecto documenta la escala punto por punto, y merece la pena tenerla a mano porque convierte una puntuación en una decisión:

Los objetivos que funcionan en la práctica:

• 80 para la imagen del hero y para cualquier cosa grande que el usuario mire de frente.
• 70 para imágenes de contenido por debajo del pliegue y miniaturas grandes.
• 90 para imágenes que el usuario va a ampliar: fotografía de producto con zoom, obra gráfica, documentación técnica.
• Sin pérdida para capturas de interfaz con texto pequeño, donde cualquier artefacto se lee como un fallo de renderizado.

El guion que busca la calidad mínima

La idea es una búsqueda binaria sobre el mando de calidad: la puntuación crece de forma monótona con él, así que se puede encontrar el valor mínimo que alcanza tu objetivo en unas siete iteraciones.

#!/usr/bin/env bash
# Calidad AVIF minima que alcanza una puntuacion objetivo.
# Uso: ./calidad.sh original.png 80
set -euo pipefail

origen="$1"
objetivo="${2:-80}"
tmp=$(mktemp -d)
trap 'rm -rf "$tmp"' EXIT

bajo=20
alto=90
mejor=90

while [ "$bajo" -le "$alto" ]; do
  medio=$(( (bajo + alto) / 2 ))
  avifenc -q "$medio" -s 6 "$origen" "$tmp/p.avif" >/dev/null 2>&1
  avifdec "$tmp/p.avif" "$tmp/p.png"  >/dev/null 2>&1
  nota=$(ssimulacra2 "$origen" "$tmp/p.png")
  bytes=$(wc -c < "$tmp/p.avif")
  printf 'q=%-3s nota=%-8s %s bytes\n' "$medio" "$nota" "$bytes"

  if [ "$(echo "$nota >= $objetivo" | bc -l)" -eq 1 ]; then
    mejor=$medio
    alto=$(( medio - 1 ))
  else
    bajo=$(( medio + 1 ))
  fi
done

echo "Calidad minima para alcanzar $objetivo: $mejor"
# Codificacion final con mas esfuerzo: mismo resultado, menos bytes.
avifenc -q "$mejor" -s 2 "$origen" "${origen%.*}.avif"

La última línea contiene una optimización que se suele pasar por alto. El parámetro de esfuerzo, que va de 0 a 10 con 6 por defecto y donde números más bajos significan más trabajo, no cambia la calidad perceptual del resultado: cambia cuánto busca el codificador antes de decidir. Usar esfuerzo bajo durante la búsqueda binaria, que hace siete codificaciones, y esfuerzo alto solo en la definitiva, da el mismo aspecto con menos bytes y sin multiplicar el tiempo total.

En una canalización de compilación en Node, el mismo criterio con la librería habitual de procesamiento de imágenes:

import sharp from 'sharp';

// La calidad viene de la busqueda previa, no de una constante global.
await sharp('hero.png')
  .resize({ width: 1600 })
  .avif({ quality: 58, effort: 8, chromaSubsampling: '4:4:4' })
  .toFile('hero-1600.avif');

Ponerlo en la canalización

Tres reglas que convierten esto en algo mantenible.

Guarda la calidad calculada junto a la imagen, no la recalcules en cada compilación. La búsqueda binaria son siete codificaciones; en un catálogo grande eso es tiempo de CPU que solo hay que gastar una vez por imagen original.

Falla la compilación si una imagen no alcanza el objetivo ni siquiera a calidad máxima. Suele significar que el original ya venía comprimido con pérdida y estás recomprimiendo, que es la forma más eficaz de acumular artefactos. La solución es conseguir el original, no subir la calidad.

Mide también el resultado en bytes y ponle un techo. Una imagen que necesita calidad 90 para llegar a 80 de puntuación y acaba pesando 900 KB no es un problema de compresión: es un problema de contenido, y probablemente haya que reducir sus dimensiones antes de codificarla.