¿Por qué pesa tanto un GIF? 256 colores, LZW y estructura de fotogramas

El GIF es un formato diseñado en 1987 y desde entonces apenas ha cambiado. Hoy se sigue usando mucho, pero al lado de las alternativas modernas es dramáticamente ineficiente. En este artículo examinamos su estructura interna y explicamos por qué produce archivos tan grandes y dónde sigue teniendo sentido.

Modelo de color basado en paleta

La característica más determinante del GIF es su forma de almacenar el color.

En los formatos de imagen modernos, cada píxel lleva su propio valor de color: 8 bits de rojo, 8 de verde y 8 de azul, unos 16,7 millones de colores posibles.

El GIF funciona de otra manera. Mantiene una tabla de colores (paleta) y cada píxel guarda un índice dentro de esa tabla. La paleta puede contener como máximo 256 entradas.

Paleta:
  0 → #000000 (negro)
  1 → #FF0000 (rojo)
  2 → #00FF00 (verde)
  ...
  255 → #FFFFFF (blanco)

Datos de píxel: 0, 0, 1, 1, 2, 0, 255, ...

La ventaja: cada píxel ocupa 8 bits en vez de 24. En las condiciones de memoria de 1987 eso era un ahorro considerable.

La desventaja: la imagen puede tener como máximo 256 colores distintos.

El precio visual de los 256 colores

Un fotograma de vídeo suele contener decenas de miles de colores distintos. Reducirlos a 256 exige una cuantización de color: el algoritmo analiza los colores de la imagen, elige los 256 más representativos y asigna a cada píxel la entrada de paleta más cercana.

Sus consecuencias visibles:

Bandas (banding). Un degradado suave —un cielo, una transición de luz, una sombra— se convierte en franjas de color plano. La continuidad se pierde y aparece un aspecto escalonado.

Deterioro de los tonos de piel. Los rostros contienen muchos tonos próximos entre sí y la paleta tiene dificultades para distinguirlos. El resultado es un aspecto manchado y enfermizo.

Desviación de color. Los colores que no tienen equivalente exacto en la paleta se redondean al vecino más cercano; el azul corporativo de tu marca puede desplazarse a un azul ligeramente distinto.

Resultado según el tipo de contenido:

| Contenido | Resultado con 256 colores | |---|---| | Grabación de pantalla, interfaz | Normalmente bueno (ya hay pocos colores) | | Dibujos animados, ilustración | Bueno | | Texto y gráficos | Muy bueno | | Imagen de naturaleza | Bandas evidentes | | Rostro humano, piel | Manchado | | Escena nocturna, degradado | Malo |

Tramado: un truco visual

Para suavizar las bandas se usa el tramado (dithering). La idea es intercalar dos colores de la paleta en píxeles vecinos para que, visto de lejos, dé la impresión de que se ve el tono intermedio.

Es el mismo principio por el que las fotos de periódico crean tonos de gris con puntos negros.

El tramado mejora notablemente la calidad visual: las bandas desaparecen y los degradados se suavizan. Pero tiene un precio, y ese precio se refleja directamente en el tamaño del archivo.

La contradicción entre la compresión LZW y el tramado

El GIF usa una compresión sin pérdidas llamada LZW (Lempel-Ziv-Welch). LZW busca patrones repetidos en los datos y los sustituye por códigos cortos. Por ejemplo, una secuencia como "0,0,0,0,0,0" se codifica de forma muy breve.

Esto funciona muy bien en imágenes con zonas de color plano: logotipos, gráficos, capturas de interfaz.

Ahora piensa en el efecto del tramado: el tramado vuelve ruidosas a propósito las zonas planas. En lugar de "0,0,0,0,0,0" aparece un patrón como "0,1,0,1,1,0".

LZW no encuentra repeticiones en ese ruido. La eficiencia de compresión cae y el archivo crece.

Es decir: el tramado mejora la calidad visual pero también aumenta el tamaño del archivo. Al producir un GIF tienes que buscar el equilibrio entre ambos.

Optimización entre fotogramas: un mecanismo limitado

El GIF guarda la animación como una sucesión de fotogramas. Cada fotograma puede tener su propia duración (valor de retardo) y su propia paleta.

El formato ofrece cierta optimización:

Fotograma parcial. Un fotograma puede contener no toda la imagen, sino solo una zona rectangular que cambia. En una animación con fondo fijo eso supone un ahorro considerable.

Píxel transparente. Los píxeles que no cambian se pueden marcar como transparentes para que se vea el fotograma anterior.

Método de descarte (disposal method). Indica qué pasa con el fotograma actual antes del siguiente: que se quede, que vuelva al fondo o que vuelva al estado anterior.

Todo esto sirve, pero se queda primitivo al lado de los códecs de vídeo modernos. La razón: el GIF no conoce el concepto de movimiento.

Un códec de vídeo puede detectar que un objeto se ha desplazado 12 píxeles a la derecha y decir "coge ese bloque del fotograma anterior y muévelo 12 píxeles a la derecha": unos pocos bytes. El GIF solo puede decir "esta zona rectangular ha cambiado, aquí van sus nuevos píxeles": miles de bytes.

Cuando hay una cámara en movimiento o una transición de escena, la optimización por fotogramas parciales queda completamente inservible; en cada fotograma cambia cada píxel.

Comparación en cifras

Para un mismo contenido de 5 segundos, 480×270 píxeles y 15 fps, a grandes rasgos:

| Formato | Tamaño típico | Color | |---|---|---| | GIF | 3-8 MB | 256 | | WEBP animado | 800 KB - 2 MB | Color completo | | APNG | 2-5 MB | Color completo + alfa | | MP4 (H.264) | 200-500 KB | Color completo | | WEBM (VP9) | 150-400 KB | Color completo |

El MP4 transporta el mismo contenido en aproximadamente la décima parte del tamaño de un GIF y con mucha mejor calidad de color. Esta diferencia no es una pequeña optimización, es una superioridad categórica.

Los tres factores que determinan el tamaño del archivo

El tamaño de un GIF crece con el producto de tres variables:

Duración × velocidad de fotogramas = número total de fotogramas. 10 segundos × 20 fps = 200 fotogramas. 5 segundos × 12 fps = 60 fotogramas. Un tercio.

Resolución = píxeles por fotograma. Reducir el ancho a la mitad deja el total de píxeles en la cuarta parte.

Cuando los multiplicas:

• 10 s, 20 fps, 800×450: 200 fotogramas × 360.000 píxeles = 72 millones de píxeles
• 5 s, 12 fps, 400×225: 60 fotogramas × 90.000 píxeles = 5,4 millones de píxeles

Unas 13 veces de diferencia. Por eso, al reducir el tamaño de un GIF hay que tocar no un solo ajuste sino los tres a la vez.

Cuarto factor: la cantidad de movimiento. Una escena estática aprovecha la optimización por fotogramas parciales y sale muy pequeña. Una escena con cámara en movimiento sale muchísimo más grande con los mismos ajustes.

Por qué no se generalizan las alternativas modernas

El WEBP animado y el APNG son superiores al GIF en todos los aspectos: color completo, transparencia alfa y una compresión mucho mejor. Todos los navegadores modernos los admiten.

Lo que impide que se generalicen no es técnico, sino la inercia del ecosistema:

• Las apps de mensajería tratan el GIF como un tipo especial y ofrecen bibliotecas de búsqueda.
• Los programas de foro y los sistemas wiki conocen las etiquetas de GIF.
• Los clientes de correo muestran animaciones GIF (no reproducen vídeo).
• La gente dice "mándame un GIF", no "mándame un WEBP animado".

Hay una situación irónica: muchas plataformas convierten en segundo plano a MP4 el GIF que subes y te lo sirven como GIF. Es decir, cuando dices "estoy compartiendo un GIF" en realidad estás compartiendo un vídeo.

El enfoque correcto en la web

Si quieres mostrar una animación en tu propia web, no hay ninguna razón para usar GIF:

<video autoplay muted loop playsinline>
  <source src="animacion.webm" type="video/webm">
  <source src="animacion.mp4" type="video/mp4">
</video>

Esto da exactamente el mismo comportamiento que un GIF —sin sonido, reproducción automática, bucle infinito—, pero a la décima parte del tamaño y con calidad de color completa.

El atributo playsinline impide que el vídeo pase a pantalla completa en los navegadores móviles; es necesario para conseguir un comportamiento tipo GIF.

En cuanto a velocidad de página, la diferencia es dramática: un vídeo de 400 KB en lugar de un GIF de 5 MB acorta notablemente el tiempo de carga.

Dónde el GIF sigue siendo la opción correcta

• Entornos que no admiten vídeo: algunos programas de foro, sistemas wiki antiguos.
• Correo electrónico: la mayoría de los clientes no reproducen vídeo pero sí muestran GIF (algunos solo el primer fotograma).
• Las bibliotecas de GIF de las apps de mensajería.
• Animaciones sencillas con pocos colores: indicadores de carga, pequeñas animaciones de iconos. Ahí el límite de 256 colores no es un problema y el GIF sale con un tamaño razonable.

En resumen

El GIF funciona con un modelo basado en paleta de 256 colores, y eso provoca bandas y manchas en el contenido fotográfico; el tramado lo suaviza visualmente pero reduce la eficiencia de la compresión LZW y agranda el archivo. El formato aprovecha la redundancia entre fotogramas solo de forma primitiva: no tiene el concepto de movimiento, solo puede guardar zonas rectangulares que cambian. El resultado es que ocupa unas diez veces más que los códecs de vídeo modernos para el mismo contenido. Como el tamaño crece con el producto de duración, velocidad de fotogramas y resolución, cualquier intento de reducirlo debe atacar los tres a la vez. Y en la web ya no queda nada técnicamente defendible en el GIF: un vídeo con autoplay muted loop hace el mismo trabajo mucho mejor.