La respuesta corta
Un GIF es un lienzo, una lista de rectángulos que se pintan encima, y una tabla de color que dice qué significan los números de esos rectángulos. Cada rectángulo lleva tres cosas: cuánto tiempo dejarlo puesto, qué hacer con él después, y opcionalmente una tabla de color propia.
Casi todo lo que a la gente le sorprende del formato sale de esa lista. Si tu GIF es enorme, es porque los rectángulos son el lienzo entero cada vez, o porque lleva dentro trescientas tablas de color. Si va demasiado lento, es porque los retardos están por debajo de un suelo que ningún navegador va a cruzar. Si deja rastro, es el campo que se llama descarte.
Para ver cuál de esas cosas es en un archivo concreto, abre el Analizador de GIF y suéltalo dentro. El resto de esta página es qué significan los números.
Los fotogramas son rectángulos, no imágenes
Esta es la parte que sorprende a quien solo ha visto GIF reproducidos. Un fotograma no es una imagen de la animación en ese momento. Es un rectángulo, con su propia posición y su propio tamaño, pintado encima de lo que dejaron los fotogramas anteriores.
Ese rectángulo puede ser el lienzo entero, y en un archivo mal hecho lo es siempre. Pero un GIF tiene permiso para guardar solo la parte de la imagen que cambió desde el fotograma anterior — y donde la mayor parte de la imagen está quieta, esa es la diferencia entre un archivo de 12 MB y uno de 900 KB. Es por lo que la grabación de una ventana casi estática puede ser pequeña, y por lo que esa misma grabación salida de un conversor descuidado no lo es.
Mirando la animación no puedes saber cuál tienes. Las dos se ven idénticas. La única forma de verlo es mirar qué guarda cada fotograma, que es una vista que el analizador tiene justo por esto: ponlo en solo lo que guarda cada fotograma y verás, o bien una fila de formas pequeñas sobre fondo transparente, lo que significa que el codificador hizo su trabajo, o bien la imagen entera una y otra vez, lo que significa que no.
En este formato no hay compensación de movimiento por ninguna parte. Nada se guarda nunca como «igual que antes pero cuatro píxeles a la izquierda», como haría un códec de vídeo. El truco del rectángulo que cambia es el único ahorro que tiene el GIF, y vale muchísimo.
Los retardos, y el suelo que impone cualquier navegador
Cada fotograma guarda cuánto hay que mantenerlo, en centésimas de segundo. Es la única unidad que tiene el formato, así que lo más rápido que un archivo puede pedir es 0,01 segundos — cien fotogramas por segundo — y lo más largo son unos 655 segundos.
No va a conseguir cien fotogramas por segundo. Todos los navegadores redondean un retardo por debajo de 0,02 segundos hasta 0,10. La regla se escribió en Netscape Navigator en 1996, para los globos terráqueos giratorios y los carteles de «en obras» animados de la época, y todos los navegadores desde entonces la han copiado. Nunca la ha quitado nadie, y nadie la va a quitar.
Así que un GIF cuyos fotogramas dicen todos 0,01 s se reproduce a diez fotogramas por segundo, no a cien. Va diez veces más lento de lo que pretendía lo que lo creó, y el archivo no da ninguna pista: los retardos que lleva dentro son exactamente los que se pidieron. Es la sorpresa más común del formato, y por eso el analizador informa de dos duraciones — la que dice el archivo y la que un navegador va a hacer de verdad con él.
El arreglo, en el programa donde se haya hecho el archivo, es escribir 0,02 en vez de 0,01. Eso da 50 fotogramas por segundo, que es el techo real, y es más rápido de lo que necesita ser cualquier cosa. En la práctica 0,05 s — veinte fotogramas por segundo — es lo más ágil que merece la pena pedir.
Una cosa más que te cuentan los retardos. Si son todos idénticos, el archivo se hizo a partir de un juego de fotogramas a una tasa fija. Si están dispersos — 0,04 aquí, 0,11 allá —, algo convirtió un vídeo y tiró fotogramas, estirando a los vecinos para cubrir los huecos. Y si el último es mucho más largo que el resto, eso es a propósito: así se hace que una animación se detenga antes de volver a empezar.
El descarte: el campo que decide si deja rastro
Cada fotograma dice qué debe quedar en pantalla cuando se acaba su tiempo. Hay cuatro respuestas posibles y conviene conocerlas, porque tres de las cuatro maneras en que una animación puede verse mal son este campo mal puesto.
- Dejarlo donde está. El siguiente fotograma pinta directamente encima. Correcto cuando los fotogramas son opacos y se tapan del todo entre sí, y la opción más barata, porque no hay que borrar nada.
- Limpiar hasta el fondo. El rectángulo del fotograma se borra antes de que dibuje el siguiente. Es lo que necesita la transparencia: sin ello, las partes que se ven a través del siguiente fotograma enseñan el anterior por debajo, y una animación de imágenes sueltas se convierte en un montón de ellas.
- Restaurar lo que había debajo. Vuelve a ponerse lo que había en el lienzo antes de que este fotograma dibujara. Así se guarda un objeto pequeño moviéndose sobre un fondo quieto — cada fotograma pinta el objeto, luego vuelve el fondo, y solo se escribe el rectángulo del objeto.
- Sin especificar. El archivo no dijo nada. Todos los visores lo tratan como «dejarlo donde está», que suele ser lo correcto y de vez en cuando es la razón de que un GIF transparente deje rastro.
Un detalle donde la especificación y la realidad se separan. «Limpiar hasta el fondo» nombra un color de fondo en la cabecera del archivo, y todos los navegadores lo ignoran y limpian a transparente. Llevan veinticinco años haciéndolo. Un archivo que cuenta con que aparezca ese color de fondo se verá bien para quien lo hizo, en el programa con el que lo hizo, y mal en todas partes.
Las tablas de color, y los 768 bytes que cuestan
Un píxel de GIF no es un color. Es un número que apunta a una tabla de como mucho 256 colores, cada uno guardado en tres bytes. Una tabla completa son por tanto 768 bytes, y un archivo puede tener una compartida por todo, o una por fotograma, o las dos cosas.
Las dos disposiciones son legítimas y hacen tratos distintos:
- Una tabla compartida son 768 bytes para todo el archivo, y mantiene los colores estables entre fotogramas. El parpadeo del GIF — ese brillo desagradable en un archivo hecho a partir de vídeo — muchas veces no es más que la paleta dando bandazos de un fotograma a otro.
- Una tabla por fotograma deja que cada uno use colores que la compartida no tiene, lo que importa cuando la escena cambia por completo. Cuesta 768 bytes cada vez. En una animación de 300 fotogramas son 230 KB de tablas de color antes de guardar un solo píxel.
Hay un segundo coste, más callado. La longitud de una tabla de color tiene que ser una potencia de dos, así que un fotograma que usa nueve colores se lleva igualmente una tabla de dieciséis, y uno que usa 130 se lleva 256. Algo de redondeo hacia arriba es inevitable. Un archivo cuyas tablas declaran cinco mil colores a los que sus píxeles no se refieren nunca es otra cosa: paletas construidas para una imagen distinta de la que acabó en el fotograma. El analizador marca las entradas sin usar para que la forma de eso se vea de un vistazo.
Adónde van los bytes de verdad
Cada byte de un GIF está en uno de unos pocos sitios, y conviene saber cuáles son antes de decidir que un archivo es demasiado grande.
- Píxeles comprimidos. En un archivo sano, casi todo. La imagen en sí, pasada por LZW — un método de compresión de 1984 pensado para capturas de hojas de cálculo, que es por lo que se porta bien con el color plano y mal con las fotografías.
- Tablas de color. 768 bytes por tabla completa, como arriba.
- Cabeceras por fotograma. Ocho bytes de tiempo y once de descriptor por cada fotograma. Nada en un archivo normal; en una animación de dos mil fotogramas diminutos, 38 KB.
- El troceado en bloques. Los datos comprimidos se cortan en tramos de como mucho 255 bytes, cada uno con un byte de longitud delante. Alrededor de un byte de cada 256, inevitable, y digno de verse porque de otro modo es invisible.
- Metadatos. Comentarios, perfiles de color y paquetes XMP. Este es el que produce los resultados verdaderamente absurdos: un editor de imagen puede dejar 40 KB de XML describiendo una edición hecha hace años, y en un GIF pequeño eso es casi todo el archivo. Ningún visor dibuja nada de ello.
La razón para mirar esto como una tabla en vez de adivinar es que la respuesta cambia según el archivo, y el arreglo sale de la respuesta. Un archivo que es 95 % píxeles comprimidos es sencillamente mucha imagen, y solo van a ayudar menos fotogramas, un tamaño menor o menos colores. Un archivo que es 30 % tablas de color o 40 % XMP tiene un problema mucho más barato.
El bucle no forma parte del formato
En la especificación del GIF no hay ningún campo que diga que una animación se repite. El bucle viene de un bloque que Netscape se inventó en 1995 — una «extensión de aplicación» con la cadena NETSCAPE2.0 dentro — que todo el mundo implementó de todas formas y que hoy está en todos los GIF animados de internet.
Lo que significa que un archivo sin ese bloque se reproduce exactamente una vez y para, en todos los navegadores, y le parece roto a quien lo hizo. Si una animación solo se reproduce una vez, es que falta ese bloque; es de las primeras cosas que merece la pena comprobar y es invisible en cualquier visor.
El bloque también puede indicar una cuenta — reproducir cinco veces y parar. Cero significa para siempre, y es lo que dicen casi todos los archivos.
Las otras cosas que puede llevar un GIF
Tres bloques que no contienen imagen y que todos los visores se saltan:
- Comentarios. Texto libre, normalmente el nombre de lo que escribió el archivo, de vez en cuando algo que el autor no habría elegido publicar. No lo enseña nada, y cada copia del archivo lo lleva encima.
- XMP. Los metadatos XML de Adobe: qué editó el archivo, cuándo, a veces quién. Llega con una cola mágica de 258 bytes al final, un truco para que las longitudes de bloque cuadren, que es por lo que leer uno de forma ingenua te llena la pantalla de binario.
- Texto plano. Un bloque de la especificación de 1989 que pide al visor que dibuje texto sobre la imagen en una rejilla de celdas. No lo implementó nunca nada. Si un archivo lleva uno, lo que ponga no va a aparecer.
Conviene saber de los tres antes de mandar un archivo a algún sitio: son las partes de un GIF que pueden decir algo sobre ti, y sobreviven a cada copia y a cada nueva subida salvo que algo los quite a propósito.
Leer un archivo dañado
Los GIF se truncan — una descarga que se paró, un archivo recuperado de un disco que fallaba, algo de lo que una aplicación escribió la mitad. Como el formato es un flujo de bloques y no una estructura indexada, un GIF truncado suele seguir siendo legible hasta el punto en que se corta: todos los fotogramas anteriores a la rotura están enteros y completos.
Conviene saberlo porque casi todo el software se limita a rechazar el archivo. Un analizador que lee todo lo que puede y dice dónde se paró al menos te cuenta cuánto ha sobrevivido, y si lo que falta es un fotograma o los últimos doscientos.
También existe el problema contrario: bytes que están después de la marca de fin del archivo. Todos los decodificadores paran en esa marca, así que no se leen nunca ni se dibujan nunca, y suelen ser un segundo archivo pegado al primero por algo que salió mal. Son peso puro y cortarlos no pierde nada.
Nada de esto necesita subir nada
Leer la estructura de un GIF no es un trabajo exigente — es un paseo por una lista de bloques y un descompresor pequeño — y nunca ha habido una razón técnica para mandar el archivo a un servidor para hacerlo. El Analizador de GIF de aquí hace todo en la página: el paseo por los bloques, el LZW, los fotogramas dibujados en pantalla y las cuentas de los bytes.
Aquí importa más que en casi cualquier otro trabajo, porque los archivos que más ganas se tienen de desmontar suelen ser aquellos sobre los que menos seguridad se tiene a la hora de compartirlos — algo recuperado, algo que te ha mandado alguien, algo con un bloque de comentario que todavía no has leído. El argumento largo sobre subir archivos vale aquí tanto como en cualquier otra parte de este sitio.