Inspector de estructura GIF

Cómo usar

1. Suelta un .gif en la caja o haz clic para elegir uno. Los bytes se leen en la página; no se sube nada.
2. Empieza por el resumen: versión de la cabecera, pantalla lógica, número de fotogramas, la duración que un navegador reproducirá de verdad y el comportamiento del bucle.
3. Si aparece el aviso de reproducción, los retardos están por debajo del mínimo del navegador: súbelos a 20 ms o más o el archivo siempre irá más lento de lo que declara.
4. Lleva las dudas de tamaño a la tabla de fotogramas: la columna de bytes y su barra muestran cuáles cuestan más, y un tamaño con * significa que ese fotograma solo repinta parte del lienzo.
5. Revisa la lista de extensiones en busca del bloque de bucle NETSCAPE, comentarios del codificador y cualquier bloque de aplicación que no esperabas.

Preguntas frecuentes

¿Por qué mi GIF va más lento que los retardos que puse?

Porque los navegadores rechazan los retardos muy cortos. El retardo vive en la extensión de control gráfico de cada fotograma en centésimas de segundo, así que el menor valor distinto de cero es 10 ms; pero Blink y WebKit sustituyen todo lo que baje de 11 ms por 100 ms, y Gecko hace lo mismo por debajo de 20 ms. Un archivo exportado a «50 fps» se reproduce entonces a 10 fps, diez veces más lento, y no hay ninguna marca que lo evite: el límite viene de las páginas llenas de GIF de un solo fotograma usados como separadores, y todos los motores lo siguen aplicando. Esta herramienta muestra las dos cifras, lo que suman los retardos y lo que tardará el navegador, para distinguir un archivo recortado por el límite de uno realmente largo. Si necesitas movimiento rápido, la respuesta es un códec de vídeo.

¿Qué significa exactamente el contador de bucle?

El bucle no está en la especificación GIF. Es una extensión de aplicación que Netscape añadió en 1995: el identificador de 11 bytes NETSCAPE2.0 seguido de un subbloque con un contador de 16 bits. Cero significa repetir para siempre, que es lo que escribe casi cualquier codificador. Un valor distinto de cero es el número de pases adicionales tras el primero, así que 1 muestra la animación dos veces en Chrome y Firefox, aunque algunos lectores antiguos lo interpretaban como el total. Si el bloque falta por completo, la animación se reproduce exactamente una vez y se queda en el último fotograma: una sorpresa frecuente después de pasar el archivo por una herramienta que descarta las extensiones que no reconoce.

¿Por qué pesa tanto mi GIF?

Casi siempre porque cada fotograma guarda el lienzo entero en lugar de la parte que cambió. La columna de bytes carga a cada fotograma con todo lo que cuesta —su extensión de control gráfico, su descriptor, su tabla de color local y sus datos LZW—, así que la clasificación es exacta y no una estimación. Mandan tres cosas: las reescrituras a pantalla completa, con cada fotograma del tamaño de la pantalla lógica; las tablas de color locales, 768 bytes cada una para 256 entradas, que son 45 KB en sesenta fotogramas antes de guardar un solo píxel; y el propio LZW, que rinde mal con fotografías o tramados y puede acabar ocupando más que los índices en bruto. El resumen de bytes separa las tres.

¿Qué son los métodos de descarte y por qué mis fotogramas dejan fantasmas?

Un fotograma GIF se pinta sobre el lienzo que dejó el anterior; el método de descarte dice qué pasa con él antes de dibujar el siguiente. 0 (sin especificar) y 1 (no descartar) lo conservan, y eso es lo que hace posibles los fotogramas diferenciales: solo hay que guardar los píxeles que cambian. 2 borra el rectángulo del fotograma al fondo, que es lo que quieres cuando los píxeles transparentes no deben acumularse, y lo que provoca un destello si se limpia toda la pantalla cada vez. 3 restaura lo que hubiera antes de dibujar el fotograma; es caro y rara vez se implementa igual en todas partes. Los rastros y fantasmas casi siempre significan descarte 1 donde se pretendía 2, o píxeles transparentes dibujados sobre fotogramas que nunca se limpiaron.

¿Por qué se ven dentados los bordes transparentes?

La transparencia del GIF es un único índice de la paleta, no un canal alfa. Un fotograma puede designar una entrada como transparente y todo píxel con ese índice se omite al componer; no hay nada entre opaco del todo e invisible del todo. Los bordes suavizados de un PNG no tienen dónde ir: los píxeles semitransparentes acaban mezclados con el fondo que supuso el exportador —el clásico halo blanco o gris— o forzados al índice transparente, que deja la escalera. Además cuesta un color: una imagen con transparencia tiene 255 entradas útiles, no 256. Y el índice transparente es por fotograma, así que un descodificador solo informa del que tiene el fotograma actual.

¿En qué se diferencian GIF87a y GIF89a, y sirve aún el entrelazado?

GIF87a es el formato original de 1987 y no tiene ningún bloque de extensión, lo que significa ni retardos, ni transparencia, ni contador de bucle, ni comentarios. GIF89a añadió el mecanismo de extensiones, y todo lo que la gente considera propio del GIF vive ahí. Los dos se siguen leyendo en todas partes, y es razonable que un codificador escriba 87a cuando no hace falta nada específico de 89a, como suele ocurrir con una sola imagen fija. El entrelazado es una bandera aparte, por fotograma: las filas se guardan en cuatro pasadas para que una imagen a medio descargar ya muestre una versión gruesa de todo el dibujo. Con una conexión moderna no aporta nada y agranda un poco el flujo LZW al romper la correlación entre filas vecinas, así que un fotograma entrelazado suelto suele indicar que el archivo pasó por una herramienta antigua.

Herramientas relacionadas