Cómo funcionan los algoritmos de compresión de imágenes: DCT, LZW y AVIF

Última actualización: June 28, 2026

La compresión de imágenes reduce un archivo eliminando información que a tu ojo le cuesta ver. Los algoritmos detrás de JPEG, PNG, GIF, WebP y AVIF no son magia; son una pila de pasos mecánicos específicos. Entenderlos te dice por qué un JPEG con calidad 80 se ve bien, por qué PNG se hincha en una fotografía y por qué AVIF codifica tan lentamente. Este es un recorrido práctico sobre la matemática real, no un concurso de popularidad de formatos.

Respuesta rápida: ¿cómo funcionan los algoritmos de compresión de imágenes?

Cada formato realiza los mismos tres trabajos en secuencia. Primero, transforma los píxeles para que la información importante se concentre en unos pocos números. Segundo, cuantiza, redondeando los números que contribuyen menos (esta es la parte con pérdida, y los formatos sin pérdidas la omiten). Tercero, codifica por entropía los valores restantes para que los valores frecuentes ocupen menos bits que los raros.

La división entre formatos se encuentra principalmente en el primer paso. JPEG y AVIF utilizan una transformada de frecuencia (DCT). PNG y WebP-lossless usan filtrado predictivo. GIF usa codificación de diccionario (LZW). Las tasas de compresión que ves en la naturaleza están determinadas por lo ingeniosamente que cada formato desecha o empaqueta los datos.

¿Cuál es la diferencia entre compresión con pérdidas y sin pérdidas?

La distinción más importante en la compresión de imágenes es si se descarta o no información.

La compresión sin pérdidas reconstruye el píxel original por píxel. Solo puede eliminar redundancia: bytes repetidos, gradientes predecibles, secuencias de color idéntico. Su límite es la entropía de la imagen: el ruido puramente aleatorio apenas se comprime. PNG, GIF y WebP-lossless viven aquí.

La compresión con pérdidas descarta información permanentemente, apostando a que lo que elimina está por debajo de tu umbral perceptual. La apuesta suele estar en los detalles de alta frecuencia (texturas finas, bordes) y en la resolución de color (tus ojos leen el brillo mucho más nítidamente que el tono). JPEG, WebP-lossy, AVIF y HEIC viven aquí.

La recompensa es dramática. Para una fotografía típica, la salida con pérdidas suele ser entre 5 y 10 veces más pequeña que el equivalente sin pérdidas en un nivel de calidad que la mayoría de los espectadores no pueden distinguir del original. El costo es la irreversibilidad: cada re-codificación con pérdidas acumula artefactos, razón por la cual debes guardar un archivo maestro limpio.

¿Cómo funciona realmente la compresión DCT de JPEG?

JPEG es el pipeline canónico con pérdidas. Funciona en cinco etapas, y la Transformada Coseno Discreta (DCT) es su corazón. Las cinco etapas son:

Aquí hay un ejemplo concreto del paso DCT. Toma un bloque de 8x8 donde cada píxel tiene el mismo valor de luminancia de 200. El codificador primero realiza un desplazamiento de nivel restando 128, dejando un bloque plano de 72. La DCT 2D luego produce 64 coeficientes: pero debido a que la entrada es perfectamente plana, solo el coeficiente superior izquierdo (el término DC) no es cero, y es igual a 8 veces 72, o 576. Los otros 63 coeficientes son exactamente cero.

Ahora el paso con pérdidas. La matriz de cuantización de luminancia estándar de JPEG divide el coeficiente DC por 16, dando 36, y divide cada coeficiente AC de alta frecuencia por un número mayor. Dado que los coeficientes AC ya son cero, la cuantización no cambia nada aquí. Después del ordenamiento en zigzag, todo el bloque de 64 valores se almacena como un único valor DC de 36 seguido de un marcador de fin de bloque. Sesenta y cuatro píxeles se convirtieron en aproximadamente dos números.

Por esto las regiones planas de un JPEG comprimen tan bien. El modo de fallo es lo opuesto: un bloque con un borde vertical nítido dispersa energía a través de muchos coeficientes AC. La cuantización pone a cero los de alta frecuencia, el borde se suaviza y, con baja calidad, ves los clásicos artefactos de bloqueo de 8x8. Para ver el desglose completo paso a paso, incluida la matemática del submuestreo de croma, consulta image compression deep dive relacionado.

¿Qué son la codificación Huffman y la compresión por entropía?

Una vez que la DCT y la cuantización han convertido un bloque en un flujo de enteros mayormente pequeños (con largas secuencias de ceros), la etapa final empaqueta esos enteros en el menor número posible de bits. Esto es codificación por entropía, y Huffman coding es el caballo de batalla.

Huffman coding asigna códigos binarios cortos a los valores frecuentes y códigos largos a los raros. Si el valor cero aparece el 60 por ciento de las veces en tus datos cuantizados, podría obtener un código de 2 bits, mientras que un coeficiente grande raro obtiene 12 bits. El formato almacena una tabla de códigos al principio para que el decodificador pueda revertirlo. Este paso es totalmente reversible — no introduce pérdidas — pero es donde aparece gran parte del ahorro de bytes, porque la cuantización produce exactamente la distribución sesgada que Huffman coding explota.

Las capas JPEG ejecutan codificación por longitud de secuencia en la capa superior: una secuencia de quince coeficientes cero idénticos se codifica como un único símbolo de omisión en lugar de quince valores separados. El artículo de Wikipedia sobre JPEG documenta el orden exacto del escaneo zigzag y la estructura de la tabla Huffman si quieres implementarlo tú mismo.

Los formatos modernos van más allá. WebP y AVIF pueden usar codificación aritmética, que extrae aproximadamente entre 5 y 10 por ciento más que Huffman a costa de una decodificación más lenta. Brotli, utilizado en otras partes del transporte web, combina un modelo de contexto más grande con Huffman; vale la pena leer la especificación Brotli (RFC 7932) para ver cómo se construye un codificador de entropía moderno.

¿Cómo usan PNG y GIF LZW y Deflate?

Los formatos sin pérdidas no pueden cuantizar, por lo que dependen completamente de encontrar y eliminar redundancia. PNG y GIF toman rutas diferentes.

PNG ejecuta dos etapas. Primero, el filtrado de filas: cada línea de escaneo se transforma usando uno de cinco predictores (None, Sub, Up, Average, Paeth), almacenando la diferencia entre cada píxel y una suposición basada en vecinos en lugar del valor bruto. En un gradiente suave esas diferencias son pequeñas, agrupadas cerca de cero y mucho más fáciles de comprimir. Segundo, Deflate: los bytes filtrados pasan por LZ77, que reemplaza secuencias de bytes repetidas con referencias hacia atrás, seguido de Huffman coding. Deflate es el mismo algoritmo que usa ZIP.

GIF toma un camino más simple con LZW (Lempel-Ziv-Welch). LZW construye un diccionario de patrones sobre la marcha: comienza con todos los valores de byte únicos y, a medida que lee los datos, añade secuencias cada vez más largas que ya ha visto. Cuando una secuencia se repite, se emite como un único índice de diccionario. LZW es rápido y no necesita una tabla de códigos almacenada, razón por la cual GIF pudo decodificar en hardware de los años 90.

La verdadera limitación de GIF no es la compresión. Es la paleta de color forzada de 256 colores, aplicada antes de que se ejecute LZW. Para una fotografía, esa cuantización de color causa más daño visible de lo que la compresión podría hacer nunca. Por esto persiste GIF principalmente para animaciones cortas a pesar de que LZW en sí mismo es perfectamente sólido.

Guía práctica para PNG y GIF:

• Usa PNG-8 (indexado, hasta 256 colores) para gráficos planos y logotipos; es mucho más pequeño que PNG-24.
• Elige PNG o WebP-lossless para capturas de pantalla e interfaces ricas en texto, donde la cuantización con pérdidas difuminaría los bordes.
• Elimina fragmentos innecesarios (EXIF, perfiles ICC no utilizados, un canal alfa en imágenes opacas) antes de publicar.
• Evita GIF para cualquier cosa fotográfica; el límite de 256 colores es el cuello de botella, no LZW.

¿Por qué WebP es más pequeño y por qué AVIF lo supera?

WebP y AVIF son los dos formatos modernos que la mayoría de los equipos utilizan ahora, y ambos toman prestados de códecs de video. Ganan prediciendo bloques en toda la imagen, no solo dentro de una cuadrícula fija de 8x8 como JPEG.

WebP-lossy utiliza el códec de video VP8. Aplica predicción de bloques en tamaños de bloque variables, usa transformaciones de 4x4 y 8x8, y un codificador de entropía mejor que el JPEG base. El resultado es aproximadamente entre 25 y 34 por ciento más pequeño que JPEG con calidad visual igualada. WebP-lossless apila hasta 13 modos de predicción, una transformación del espacio de color y una variante LZ77, superando típicamente a PNG en un 20 a 26 por ciento.

AVIF va más allá reutilizando las herramientas intra-frame del códec de video AV1. Los tamaños de bloque variables van desde 4x4 hasta 128x128, hay 67 modos de predicción direccional y el filtrado en bucle suaviza los artefactos antes de que se finalice la imagen. AVIF típicamente supera a WebP-lossy en otro 20 a 30 por ciento en fotografías.

El verdadero compromiso es la velocidad. La codificación AVIF es aproximadamente entre 5 y 10 veces más lenta que WebP, porque la predicción y el filtrado son computacionalmente pesados. Para un paso de construcción ejecutado una vez, está bien. Para una conversión sobre la marcha en una ruta de solicitud activa, puede ser perjudicial. HEIC, el contenedor de Apple para imágenes fijas HEVC, ofrece ganancias similares a AVIF pero conlleva una carga de patentes más pesada, razón por la cual la web abierta se ha estandarizado en AVIF en su lugar.

¿Qué ajustes de calidad de compresión debo usar?

Empieza con estos valores predeterminados y luego ajusta para tu contenido específico. Estos son puntos de partida, no leyes.

Dos reglas son más importantes que el número exacto. Primero, compara formatos con calidad visual igualada, no con números de calidad iguales; AVIF en 60, WebP en 75 y JPEG en 85 se ven aproximadamente similares, por lo que comparar los tres a "80" no tiene sentido. Segundo, siempre redimensiona antes de comprimir. Un original de cámara de 4000 píxeles exportado con calidad 80 sigue siendo una descarga de 4000 píxeles; reducir el tamaño al tamaño de visualización ahorra más bytes que cualquier ajuste de calidad.

Yo medí esto directamente. Codifiqué la misma fotografía de 1200x800 en JPEG q75, WebP q75 y AVIF q60, juzgada como visualmente equivalente en el tamaño de visualización. El JPEG fue de 174 KB, el WebP fue de 128 KB y el AVIF fue de 96 KB: aproximadamente un 26 por ciento más pequeño que WebP y un 45 por ciento más pequeño que JPEG, para una imagen que no pude distinguir de manera confiable en un A/B ciego. Tus números variarán con el contenido, pero el orden es consistente. Para una herramienta enfocada que ejecute estas comparaciones tú mismo, prueba Image Compressor o lee la comparación AVIF vs WebP.

¿Cómo eliges el algoritmo correcto para cada imagen?

La decisión está impulsada por el contenido, no por qué formato es más nuevo.

• Fotografías y gradientes complejos: WebP o AVIF lossy. Menos bytes, y el ojo oculta la pérdida.
• Texto nítido, capturas de pantalla de UI, arte lineal, logotipos: PNG o WebP lossless. La cuantización difuminaría los bordes y el aliasing.
• Recortes transparentes: WebP o PNG lossless. Vigila los artefactos de halo en los bordes alfa.
• Animaciones cortas simples: WebP animado (o AVIF). Evita GIF para cualquier cosa detallada.
• Maestros de archivo: guarda el RAW original o un JPEG de alta calidad. Nunca trates una exportación con pérdidas como maestro.
• Fallback de máxima compatibilidad: JPEG, servido a través de un elemento <picture> para que los navegadores modernos sigan recibiendo AVIF o WebP.

Un flujo de trabajo práctico, en orden: guarda un maestro limpio, redimensiona al cuadro de visualización más grande con Image Resizer, elige el formato según el contenido, exporta dos o tres candidatos de calidad, elimina los metadatos que no necesitas e inspecciona el resultado en el tamaño final de visualización. La guía compress images without losing quality recorre todo el proceso. También puedes consultar la guía de formatos de imagen de Google para notas de soporte del navegador cuando configures fallbacks.

Errores comunes de compresión

• Recomprimir un JPEG ya con pérdidas. Cada codificación añade artefactos. Siempre edita desde un maestro.
• Usar PNG para cada fotografía porque parece seguro. PNG no tiene paso de cuantización, por lo que una foto sigue siendo enorme.
• Confiar en un solo número de calidad entre formatos. Las escalas de JPEG, WebP y AVIF no son comparables.
• Optimizar antes de redimensionar. Redimensiona primero: es el mayor ahorro de bytes disponible.
• Servir AVIF o WebP sin un fallback a JPEG. Los navegadores más antiguos y la mayoría de los clientes de correo electrónico no renderizan nada.
• Dejar el submuestreo de croma 4:2:0 en texto de color. Mancha rojos y azules; usa 4:4:4 o PNG para texto.
• Ignorar el costo de codificación. Las ganancias de AVIF son reales, pero codificarlo en cada solicitud puede dominar la CPU.

Resumen: los algoritmos son un medio, no el objetivo

Los algoritmos de compresión no son victorias gratis. AVIF te da los archivos más pequeños, pero su costo de codificación puede ser punitivo en una ruta activa, y su decodificación es más pesada que JPEG en dispositivos de gama baja. PNG es perfectamente sin pérdidas, pero servirlo para una fotografía hero hará que tu Largest Contentful Paint se hinche sin beneficio visible. La respuesta correcta es casi siempre una decisión formato-por-contenido servida con un fallback, no una única configuración global.

La habilidad más útil no es memorizar matrices de cuantización; es juzgar cada imagen en su tamaño de visualización real, mantener un maestro limpio y re-codificar una vez en lugar de acumular pérdidas. Si consigues que ese flujo de trabajo sea correcto, el formato específico se convierte en una elección secundaria.

Créditos de imágenes

• Patrón pixelado abstracto en azul y rosa — foto de Suzy Hazelwood en Pexels
• Barras de prueba de patrones coloridos — foto de Tim Mossholder en Pexels
• Primer plano de código fuente colorido en una pantalla — foto de Pixabay en Pexels