¿Qué cambia técnicamente al convertir un GIF a vídeo?

Cuando conviertes un GIF a MP4, el archivo se reduce diez veces pero la imagen se queda casi igual. ¿Cómo es posible y qué cambia realmente durante la conversión? En este artículo explicamos las diferencias estructurales entre los dos formatos y lo que ocurre en cada paso de la conversión.

Dos modelos de animación distintos

En el GIF, la animación es una sucesión de fotogramas independientes. Cada fotograma:

• Puede tener su propia paleta de colores (máximo 256 entradas)
• Tiene su propio tiempo de retardo (en centésimas de segundo)
• Puede tener su propia posición y tamaño (no un fotograma completo, sino un rectángulo parcial)
• Tiene su propio método de descarte (qué ocurre antes del fotograma siguiente)

En el vídeo, la animación son fotogramas alineados sobre una rejilla temporal fija. La velocidad suele ser constante (25, 30, 60 fps) y cada fotograma se muestra el mismo tiempo.

Esta diferencia básica de modelo genera la primera dificultad de la conversión.

Temporización: del retardo variable a la velocidad constante

Los retardos de los fotogramas de un GIF pueden ser así:

Fotograma 1: 10 (0,10 s)
Fotograma 2: 10 (0,10 s)
Fotograma 3: 25 (0,25 s)  ← pausa
Fotograma 4: 10 (0,10 s)
Fotograma 5:  5 (0,05 s)  ← transición rápida

El vídeo, en cambio, espera una velocidad constante. Las opciones del conversor:

1. Elegir una velocidad suficientemente alta y repetir fotogramas. En el ejemplo anterior, si se elige 20 fps (0,05 s por fotograma), el fotograma de 0,25 segundos se repite cinco veces. La temporización se conserva exactamente y el número de fotogramas aumenta, pero eso no crea un problema de tamaño porque los códecs de vídeo comprimen los fotogramas repetidos con enorme eficiencia.

2. Elegir una velocidad media y aproximar. Es más simple, pero aparecen diferencias de temporización.

La mayoría de los conversores usan la primera vía. Aun así, si los retardos de tu GIF son muy irregulares, puede notarse una ligera diferencia de ritmo.

Un detalle: algunos GIF muy antiguos llevan un retardo de valor 0 (lo más rápido posible). Los navegadores suelen elevarlo a un mínimo, y cada navegador usa un mínimo distinto. Si conviertes a vídeo un GIF así, la velocidad puede ser distinta de la que veías en el navegador.

La composición de los fotogramas parciales

En un GIF, un fotograma puede ser un pequeño rectángulo que solo dibuja la zona que cambia sobre el fotograma anterior. En una animación con fondo fijo eso ahorra bastante espacio.

En el vídeo no existe ese concepto; cada fotograma es de tamaño completo.

El conversor tiene que ir componiendo los fotogramas del GIF en orden para producir la imagen completa de cada uno. Para ello necesita interpretar correctamente el método de descarte:

| Método | Significado | |---|---| | Sin especificar | Que el fotograma se quede tal cual | | Conservar (Do not dispose) | Que el fotograma se quede y el siguiente se dibuje encima | | Volver al fondo | Que la zona del fotograma se limpie con el color de fondo | | Volver al anterior | Que la zona del fotograma vuelva a su estado previo |

Una interpretación errónea se manifiesta en la conversión como rastros "fantasma" o residuos acumulados. Es un problema raro en conversores bien escritos, pero puede aparecer con GIF muy antiguos o no estándar.

Color: de la paleta al color completo (pero sin vuelta atrás)

En el GIF, cada píxel es un índice de paleta. En la conversión, esos índices se resuelven a valores RGB reales.

El formato de vídeo admite color completo (16,7 millones), así que no hay ningún límite técnico.

Pero la fuente ya está reducida a 256 colores. La información de color perdida no vuelve. El vídeo guarda esos 256 colores con su capacidad de color completo y el resultado se ve visualmente igual que el GIF.

Un efecto secundario curioso: si al GIF se le aplicó tramado (ese patrón de puntos que se usa para disimular el límite de color), ese patrón se traslada también al vídeo. Para el códec de vídeo ese ruido es exigente: el códec lo toma por detalle real y gasta bits en él. Si no le das bitrate suficiente, el patrón de tramado se emborrona o provoca bloques.

Transparencia: la característica que se pierde

El GIF admite transparencia binaria: un píxel o es totalmente transparente o es totalmente opaco. No hay valores intermedios, y por eso los bordes de los GIF transparentes se ven dentados.

Los códecs de vídeo habituales (perfiles estándar de H.264 y VP9) no transportan canal alfa. Se da por supuesto que cada píxel es opaco.

En la conversión, los píxeles transparentes tienen que rellenarse con un color, normalmente negro o blanco. El resultado es que las zonas donde en el GIF se veía el fondo aparecen en el vídeo como color plano.

Si necesitas transparencia, el vídeo no es el destino correcto. Alternativas:

• WEBP animado: alfa de 8 bits, buena compresión.
• APNG: alfa de 8 bits, archivo más grande pero soporte amplio.

Los dos son mejores que la transparencia binaria del GIF: con 256 niveles de transparencia consiguen bordes suaves.

Submuestreo de croma

Es uno de los efectos más técnicos de la conversión, pero también uno de los más visibles.

El ojo humano es mucho más sensible a los cambios de luminosidad (luma) que a los de color (croma). Los códecs de vídeo lo aprovechan: guardan la información de luminosidad a resolución completa y la de color a media resolución.

Este esquema se llama 4:2:0 y es el valor por defecto de la codificación de vídeo habitual. La información de color se reduce a la mitad tanto en horizontal como en vertical, es decir, se guarda la cuarta parte de los datos de color.

En contenido fotográfico esto es prácticamente invisible. Pero en los contenidos típicos de un GIF sí puede notarse:

• Bordes de color nítidos: texto rojo sobre fondo blanco, con una leve borrosidad en los bordes.
• Líneas finas: los elementos de interfaz en color se suavizan.
• Texto pequeño: puede perder legibilidad.

Algunos códecs admiten el perfil 4:4:4 (la información de color se guarda a resolución completa). En grabaciones de pantalla y animaciones con texto esto marca una diferencia notable, pero el archivo crece y la compatibilidad se estrecha.

La restricción de números pares

Como el submuestreo 4:2:0 guarda la información de color en bloques de 2×2 píxeles, exige que el ancho y el alto sean números pares.

Los GIF no tienen esa restricción; medidas como 401×267 son frecuentes.

El conversor lo resuelve de dos maneras:

• Recorte: se descarta una columna o fila de píxeles (401 → 400).
• Relleno: se añade un píxel (401 → 402), normalmente negro.

Ninguna de las dos se aprecia visualmente, pero el cambio de tamaño sí se ve en los metadatos.

Eficiencia de compresión: la ganancia de verdad

Llegamos ahora al motivo de esa diferencia dramática de tamaño de archivo.

Las herramientas del GIF:

• Compresión sin pérdidas LZW (busca patrones repetidos)
• Fotogramas parciales (la zona rectangular que cambia)
• Píxeles transparentes (saltarse los píxeles que no cambian)

Las herramientas de un códec de vídeo:

• Estimación de movimiento (averigua adónde se ha desplazado un bloque)
• Predicción intra (predicción a partir de los píxeles vecinos)
• Predicción bidireccional (mirar los fotogramas anterior y siguiente)
• Transformada de frecuencia y cuantización (descartar el detalle visualmente irrelevante)
• Tamaños de bloque variables
• Codificación entrópica

La diferencia es categórica. El GIF dice "esta zona ha cambiado, aquí van los nuevos píxeles"; el códec de vídeo dice "este bloque del fotograma anterior se ha desplazado 12 píxeles a la derecha y se ha oscurecido un poco".

A eso se suma el trabajo con pérdidas: el códec de vídeo puede descartar detalles que no se van a apreciar. La LZW del GIF es sin pérdidas y no tiene esa flexibilidad.

Resultado: para un mismo contenido, una diferencia típica de 5 a 10 veces en tamaño.

Qué se pierde y qué se gana

| Aspecto | GIF | Tras pasar a vídeo | |---|---|---| | Tamaño de archivo | Grande | 5-10 veces menor | | Variedad de color | 256 (límite) | Color completo (pero la fuente tiene 256) | | Transparencia | Binaria | No hay | | Soporte en correo | Sí | No | | Reproducción automática | Nativa | Requiere atributo | | Bordes de color nítidos | Intactos | Ligero suavizado (4:2:0) | | Flexibilidad de temporización | Por fotograma | Velocidad constante |

En resumen

GIF y vídeo abordan la animación con modelos distintos: en el GIF cada fotograma tiene su propio retardo, su paleta y su zona parcial; en el vídeo hay fotogramas completos sobre una rejilla temporal fija. La conversión compone los fotogramas y normaliza la temporización a una velocidad constante. En cuanto al color no hay pérdida, pero tampoco ganancia: el límite de 256 colores ya está aplicado. La transparencia sí se pierde, porque los códecs de vídeo habituales no transportan canal alfa. El submuestreo de croma provoca un ligero suavizado en los bordes de color nítidos y la restricción de números pares puede exigir un recorte de un píxel. A cambio, la ganancia es grande: la estimación de movimiento y la capacidad de trabajar con pérdidas de los códecs de vídeo guardan el mismo contenido en un tamaño típicamente entre cinco y diez veces menor.