Por qué un GIF de tres segundos pesa más que el vídeo del que salió

Un formato de 1989 que nunca aprendió el movimiento

La especificación GIF89a describe una animación como una secuencia de imágenes con un retardo entre ellas. Ese es todo el modelo. No hay noción de una escena que persista, ni vector que le diga al decodificador que este bloque de píxeles es el del fotograma anterior desplazado once píxeles a la izquierda. Los códecs de vídeo modernos dedican casi toda su astucia a esa idea exacta, y de ahí sale casi toda su compresión: en un plano de alguien hablando, la pared detrás de la cabeza se transmite una vez y luego se referencia durante trescientos fotogramas. Un GIF no tiene manera de referenciar nada.

Hay una excepción rudimentaria, y conviene conocerla porque explica por qué algunos GIF se portan mucho mejor de lo que predice la aritmética. Un fotograma puede escribirse como un rectángulo más pequeño colocado en un desplazamiento, y los píxeles que no cambiaron desde el fotograma anterior pueden marcarse transparentes en lugar de guardarse. FFmpeg — el motor que usa esta herramienta — activa ambas cosas por defecto. En una grabación de pantalla donde un cursor cruza una ventana quieta, esto es enorme: casi todo el fotograma se desploma a nada. En imágenes de cámara, donde el ruido del sensor hace que prácticamente cada píxel difiera un poco del anterior, no ahorra casi nada. Esa sola distinción explica por qué los mismos ajustes producen un GIF de 300 kB desde una captura de pantalla y uno de 5 MB desde un clip grabado a pulso.

La aritmética, y dónde vive la única cifra blanda

Bytes ≈ ancho × alto × fotogramas × b ÷ 8. Todo lo de la derecha es exacto salvo b, el número de bits que cuesta cada píxel después de que LZW haya hecho su trabajo. Antes de comprimir, cada píxel es un índice en una tabla de hasta 256 colores, así que parte de 8 bits. Sobre contenido fotográfico tramado, LZW suele bajarlo a algo entre 2 y 5, y por eso lo honesto es tomar b = 3 para una primera estimación y aceptar que la respuesta es buena con un margen de un factor de dos. Suena descuidado hasta que uno nota que es el mismo factor de dos que saldría de adivinar una tasa de bits de vídeo, y que basta para saber si estás a un ajuste de tu límite o a cuatro.

Una cosa que la herramienta no hace es medir los colores de tu clip. Una cadena GIF de calidad hace dos pasadas: una para construir una paleta a partir de los píxeles realmente presentes y otra para proyectar los fotogramas sobre ella. Esta herramienta hace una sola pasada, así que las 256 casillas se llenan desde una tabla genérica y no desde tus imágenes. La consecuencia visible son bandas en cielos, degradados y tonos de piel, y una ligera aspereza en las zonas oscuras. La consecuencia invisible es sobre el tamaño, y corta en los dos sentidos: una paleta genérica tramea más, y el tramado añade ruido de alta frecuencia que LZW detesta, lo que empuja b hacia arriba. Si tu clip tiene pocos colores de partida — una animación de logotipo, un gráfico, una ventana de terminal — nada de esto muerde y el archivo saldrá muy por debajo de la estimación.

La casilla de ancho no es una casilla de tamaño

Escribes un ancho; la herramienta calcula el alto a partir de la forma del clip. Para un clip apaisado 16:9, 480 te da 480 × 270: 129 600 píxeles por fotograma. Para un vídeo de móvil grabado en vertical, ese mismo 480 te da 480 × 853, o sea 409 440 píxeles por fotograma: más del triple, con la misma cifra escrita en la misma casilla. Es el motivo más común de que un GIF salga inesperadamente enorme, y es invisible en la interfaz, que solo te enseña una de las dos dimensiones.

El arreglo cabe en una línea de aritmética. Si quieres que un clip vertical pese lo que pesa uno apaisado de 480 de ancho, pide 270 de ancho: 270 × 480 son exactamente 129 600 píxeles otra vez. Más en general, decide un presupuesto de píxeles por fotograma en lugar de un ancho. Algo entre 120 000 y 150 000 píxeles por fotograma va cómodo en una ventana de chat sea cual sea la forma — eso es 480 × 270 apaisado, 270 × 480 vertical o 360 × 360 cuadrado — y entonces solo te quedan por discutir la cadencia y la duración.

La cadencia que pediste probablemente no es la que obtuviste

Esto es arqueología de formato pura y pilla a todo el mundo. La especificación GIF89a guarda la pausa antes del siguiente fotograma en centésimas de segundo — el campo, en sus propias palabras, «indica el número de centésimas (1/100) de segundo que hay que esperar». No hay unidad más fina ni fraccionaria. Así que una cadencia solo es reproducible si 100 se divide exactamente entre ella. Dentro del rango que ofrece esta herramienta, eso significa 2, 4, 5, 10, 20 y 25 fotogramas por segundo, y nada más.

El valor por defecto de 12 no está entre ellos. Un doceavo de segundo son 8,33 centésimas, y el archivo solo puede guardar 8 o 9 — es decir 12,5 u 11,1 fotogramas por segundo en reproducción, con lo que tu clip de ocho segundos dura 7,68 u 8,64 segundos. Nadie que mire un GIF de gatos lo notará. Alguien que mire una cuenta atrás, un metrónomo, un cronómetro de vuelta o una grabación de pantalla donde demuestras un fallo de temporización, desde luego que sí. Treinta es peor: un treintavo de segundo son 3,33 centésimas, el archivo guarda 3, y la reproducción sale a 33,3 fotogramas por segundo, un once por ciento rápida. Si el tiempo importa, elige 10, 20 o 25 y el archivo se reproducirá al ritmo que pediste.

Cuando la respuesta correcta no es un GIF

El tamaño del vídeo obedece a otra fórmula, mucho más amable: bytes = tasa de bits × segundos ÷ 8. Ocho segundos a 800 kbit/s son 800 kB, y 800 kbit/s compran un clip perfectamente mirable a resolución completa y treinta fotogramas por segundo. Eso es casi seis veces menos que el GIF construido con esos mismos ocho segundos a un quinto de la resolución y un tercio de la cadencia — y el vídeo tiene sonido, si lo quieres. Toda app de mensajería, todo foro moderno, todo gestor de incidencias y toda red social reproducen MP4 y WebM en línea y los repiten a demanda. El bucle en reproducción automática que hoy la gente llama «un GIF» en la web es, nueve de cada diez veces, un MP4 mudo.

Así que reserva el GIF para los casos en que no se acepta otra cosa, y los hay de verdad: un wiki o un gestor de incidencias que solo admite imágenes adjuntas, un cliente de correo que no incrusta vídeo, un foro viejo cuyo editor tiene un botón de imagen y nada más, un README renderizado en algún sitio que elimina las etiquetas de vídeo. En esos lugares el GIF no es una elección nostálgica: es la única imagen en movimiento que sobrevivirá al viaje. En todos los demás, convertir a GIF es pagar de cinco a diez veces los bytes para perder el sonido, la mayoría de los colores y la mitad de los fotogramas.

Dos detalles pequeños sobre esta herramienta concreta

Siempre empieza en el segundo cero. La casilla de duración es un techo sobre la salida, no una ventana que puedas deslizar: los ocho segundos que obtienes son los ocho primeros del archivo. Si el momento que quieres está en el 0:42, corta el clip antes con la herramienta de recorte y dale el trozo cortado. No es una limitación que se sortee con una duración mayor: poner el máximo en 30 te da los primeros treinta segundos y un GIF que nadie puede publicar en ninguna parte.

Y el tamaño que informa se mide en unidades de 1 048 576 bytes mientras las llama MB. Es un mebibyte con la etiqueta de un megabyte, una dejadez muy vieja y muy extendida. Aquí importa en un solo punto: un límite expresado como 10 000 000 bytes son 9,54 de los «MB» de la herramienta, así que un archivo que la herramienta anuncia orgullosa como 10,0 MB rebasa ese límite en casi medio megabyte. Cuando apuntes a un techo estricto, apunta un cinco por ciento por debajo y deja de pensar en las unidades.

Preguntas frecuentes

¿Se pueden meter más de 256 colores en un GIF?

En todo el archivo, sí; dentro de un fotograma, no. La especificación permite que cada bloque de imagen lleve su propia tabla de colores local, así que una animación de veinte fotogramas podría en principio usar veinte paletas y tocar varios miles de colores distintos en total. Pero cada fotograma sigue limitado a 256, y una tabla local cuesta hasta 768 bytes cada vez que cambia. En la práctica esto aporta muy poco en vídeo, porque el ojo compara fotogramas vecinos y una paleta que cambia entre ellos produce parpadeo visible. La ganancia mayor al alcance de un codificador GIF no son más colores sino colores mejor elegidos: una paleta medida sobre tus imágenes reales en vez de una tabla genérica.

Mi GIF sigue pesando demasiado y ya he reducido el ancho. ¿Y ahora?

Recorta después la duración y luego la cadencia, en ese orden. Duración y cadencia son ambas lineales respecto al número de fotogramas, así que rinden lo mismo por unidad — pero un clip más corto casi siempre es un clip mejor, mientras que bajar la cadencia es una degradación visible por debajo de unos 8 fotogramas por segundo, donde el movimiento empieza a leerse como un pase de diapositivas. Dos segundos a 10 fotogramas por segundo son veinte fotogramas, y veinte fotogramas de 320 × 180 a 3 bits son 432 kB. Si ni así entra, la conclusión honesta es que el contenido no comprime: mira si son imágenes de cámara con fondo en movimiento y, si lo son, recorta ceñido a lo que importa o acepta que esto pide un vídeo.

¿El GIF conserva el sonido?

No, y nunca podrá: el formato no tiene pista de audio ni sitio donde ponerla. Vale la pena decirlo en voz alta porque es un fallo silencioso — nada te avisa, la conversión funciona, y lo descubres al publicar un clip cuyo sentido entero era una frase de diálogo. Si lo que querías compartir era el sonido, la respuesta es un vídeo, o el audio por su cuenta: este sitio tiene una herramienta que extrae la banda sonora de un archivo de vídeo en MP3, AAC o WAV sin tocar la imagen.

¿Por qué mi GIF se ve granuloso en las zonas oscuras si el vídeo se veía bien?

Porque 256 colores tienen que cubrir todo el recorrido del negro al blanco, y en una escena oscura la mayor parte de tu imagen se apretuja en un puñado de ellos. El codificador tapa el hueco trameando — dispersando píxeles de dos colores disponibles para fingir un tercero — y en zonas oscuras planas esa dispersión se lee como grano. También te cuesta tamaño, porque el tramado es ruido de alta frecuencia y el ruido de alta frecuencia es justo lo que LZW no sabe comprimir. Dos cosas ayudan: aclarar o recortar el clip antes de convertir para que menos parte viva en la zona aplastada, y preferir contenido de colores planos y bien diferenciados. Nada lo arregla del todo dentro del formato, lo que es una razón más para que la respuesta sea a menudo un vídeo.

¿El vídeo sale de mi ordenador mientras esto se ejecuta?

No. La conversión se ejecuta en la página, en una compilación de FFmpeg a WebAssembly, y el motor mismo se sirve desde este sitio y no desde una red ajena, así que ni siquiera su descarga única entrega tu dirección a nadie. Hay una consecuencia visible que conviene esperar: la primera conversión de una sesión descarga unos 32 MB de motor y tarda un rato, y todas las siguientes arrancan al instante. Y hay una prueba que zanja la cuestión sin necesidad de creernos: carga la página, apaga la red y convierte un clip. Si sigue funcionando, no se subió nada.