Analizar un GIF — fotogramas, duraciones, paleta y tamaño

Q: ¿Cuál es la diferencia entre las dos vistas de fotograma?

El lienzo después de cada fotograma es lo que enseña un visor en ese momento: este fotograma dibujado encima de lo que dejaron los anteriores. Solo lo que guarda cada fotograma es el rectángulo que el archivo tiene de verdad para ese fotograma, por sí solo y sin nada debajo. La segunda es la interesante. Un GIF puede guardar un fotograma como solo la parte de la imagen que cambió, y por eso una grabación de pantalla de una ventana casi quieta puede ser pequeña. Si todos los fotogramas de tu archivo son el lienzo completo, nadie hizo ese trabajo, y mirando la animación no te enteras: solo mirando lo que hay guardado.

Elige un GIF

Suelta aquí un GIF o haz clic para buscarlo — animado o fijo, del tamaño que sea

Adónde fueron los bytes

Cada byte del archivo está en exactamente una fila, y las filas suman el archivo. Si no sumaran, lo diría la última fila en vez de estirarse la barra en silencio hasta encajar.

Adónde fueron los bytes de este archivo
Parte	Bytes	Porcentaje
El archivo entero	—	100%

Dibujando {name}: {done} de {total} fotogramas… Análisis cancelado. La lectura nativa del archivo aún puede terminar. El lienzo o un fotograma no tiene un tamaño dibujable. Dibujar superaría el límite estimado de búferes de 512 MiB de esta página. El dibujo alcanzó el límite de 300 millones de píxeles decodificados. Se canceló el dibujo. El dibujo se detuvo: {detail} Se dibujaron {drawn} de {total} fotogramas. {why} El análisis de cabeceras, tiempos y bytes sigue disponible; el uso de píxeles no dibujados es desconocido. La reproducción del navegador está desactivada porque el dibujo está incompleto. El análisis leído sigue disponible. No medido por completo Las tablas declaran {declared} entradas de color. El uso total de píxeles no está disponible mientras haya fotogramas sin dibujar. {entries}, {size}, compartida por {frames}. No se marca ninguna entrada como sin usar porque no se dibujaron todos los píxeles. {index}: {colour} — nunca usado Dibujo Se dibujaron {drawn} de {total} fotogramas. {why} Los no dibujados se describen desde sus cabeceras; el uso total de píxeles no está disponible. El decodificador de tu propio navegador, reproduciendo el archivo tal cual. Leyendo {name}… {name} no es un GIF: {why}. Esta herramienta lee el formato GIF en sí, así que no tiene nada que decir sobre otros archivos. {name} no se ha podido leer: {why} el archivo acaba a los {available} bytes y en {at} hacían falta {wanted} más este archivo empieza por {what}, no por «GIF» un JPEG un PNG un archivo RIFF — un WebP o un WAV un PDF un archivo zip los bytes {bytes} el tamaño de código es {size}, y el formato permite de 2 a 8 {n} fotograma {n} fotogramas {n} color {n} colores {n} entrada {n} entradas {n} tabla por fotograma {n} tablas por fotograma {n} vez {n} veces {n} bytes {minutes} min {seconds} s {n} s {time} ({fps} fps) {n} fotogramas piden menos de 0,02 s, y todos los navegadores los mantienen 0,10 s en su lugar. una vez — sin bloque de bucle sin parar {n} veces Problema Conviene saberlo Nota {frames}. Aquí se dibujaron {drawn}; el resto se describe solo desde sus cabeceras. {frames}, ninguno de ellos cubre todo el lienzo. {frames}, todos cubren todo el lienzo. {frames}, {n} de ellos cubren todo el lienzo. Mostrar los otros {frames} Lo que el fotograma {n} guarda por su cuenta El lienzo después del fotograma {n} Fotograma {n} sin dibujar Retardo {delay} → 0,10 s Rectángulo ⁦{width} × {height}⁩ en ⁦{left}, {top}⁩ Paleta {n} propios la global ninguna en absoluto Transparencia índice {n} no Tamaño {size} — {share} Entrelazado sí Comprimido {ratio}× Problema los datos acaban antes de tiempo Las tablas de este archivo declaran {declared} entre todas, los píxeles se refieren a {referenced} de esos, y {different} de esos son distintos entre sí. {entries}, {size}, compartida por {frames}. Las entradas apagadas son aquellas a las que ningún píxel se refiere nunca. {tables} ({size} en total) Fotograma {n} — {colours} Se muestran las 24 primeras de {n}. El resto está en el informe descargable. Comentario Texto sin formato Extensión {code} Un comentario. Ningún visor lo muestra, y todas las copias del archivo lo llevan. El bloque de bucle, que dice que se reproduzca sin parar. No forma parte de la especificación GIF: Netscape se lo inventó en 1995 y todo el mundo lo implementó igualmente. El bloque de bucle, que dice que se reproduzca {times}. Un paquete XMP: el XML que un editor de imágenes escribe para dejar constancia de lo que hizo. No lo dibuja nada. Un perfil de color ICC, que dice qué significan como colores los números de la paleta. Casi nada lee uno de dentro de un GIF. Un bloque de texto plano, que pide al visor que dibuje texto sobre la imagen. Estaba en la especificación de 1989 y no lo implementó nunca nada. Un bloque de aplicación. Los visores se saltan los que no reconocen. Dura {time} según lo escrito Se reproduce en {time} - {n} fotograma(s) por debajo de 0,02 s los sube a 0,10 s todo navegador Cadencia {fps} fotogramas por segundo Bucles sin bloque de bucle - se reproduce una vez Paleta global {n} colores ninguna Colores dibujados Índice de fondo Copiado. Es texto plano, y ha ido solo a tu portapapeles. Este navegador no ha dejado que la página escriba en el portapapeles. Usa «Descargarlo» en su lugar. Cabecera y descriptor de pantalla La firma, el tamaño del lienzo y las banderas. Trece bytes, en todos los GIF que se han hecho. Tabla de colores global {colours} colores a tres bytes cada uno, compartidos por cada fotograma que no trae la suya. Este archivo no tiene: cada fotograma lleva su propia paleta. Tablas de colores por fotograma Una paleta propia para un fotograma que necesitaba otros colores. Tres bytes por color, cada vez. Bloques de tiempo Ocho bytes por fotograma: el retardo, el método de borrado y qué color es transparente. Descriptores de fotograma Once bytes por fotograma: dónde se pone el rectángulo, cómo de grande es y con qué tamaño de código empieza el compresor. Píxeles comprimidos La imagen en sí, comprimida con LZW. En un GIF sano esto es casi todo el archivo. Marcado de bloques Un byte de longitud por cada 255 bytes de datos, más un cero para cerrar cada tanda. Inevitable, y conviene verlo. Comentarios y metadatos Bloques de bucle, comentarios, perfiles de color y cualquier XMP que un editor haya dejado ahí. Cierre Un byte que dice que el archivo se ha acabado. Bytes después del final Datos puestos más allá del cierre. Ningún decodificador los lee, y son peso puro. Sin contabilizar Bytes dentro de bloques donde este lector se paró. Un archivo que acaba a mitad de bloque deja algunos. Contado dos veces Los bloques se solapan, o sea que este archivo se contradice sobre dónde empiezan. Sin especificar Dejarlo donde está Volver al fondo Restaurar lo que había debajo Reservado ({n}) Borrado Análisis de GIF — {name} Leído enteramente en un navegador por abox.tools/gif-analyzer/. El archivo no se subió. El archivo Versión Lienzo ⁦{width} x {height}⁩ píxeles Tamaño {rounded} ({exact}) Fotogramas Adónde se fueron los bytes Total Lo que llama la atención Los fotogramas Texto que lleva el archivo La paleta global {colours} propios global lienzo entero n.º en tamaño retardo borrado paleta bytes El archivo termina sin byte de cierre, así que está incompleto — una descarga que se cortó, o un archivo truncado. El byte {at} vale 0x{marker}, que no empieza ningún bloque que este formato tenga. Todo lo que venía después se ignoró. Dos bloques de control gráfico seguidos, en {first} y {second}. El primero no describe ninguna imagen y no hace nada. El archivo termina en mitad de un bloque que empieza en {at}. {detail}. El código {code} llegó primero, antes de que el diccionario tuviera nada. Un visor dibujará lo que pueda y dejará en blanco el resto del rectángulo. El código {code} apunta a la entrada {code} del diccionario, y solo existen {entries}. Un visor dibujará lo que pueda y dejará en blanco el resto del rectángulo. No hay fotogramas en este archivo. La cabecera se leyó, pero no venía detrás ningún bloque de imagen. Sea lo que sea, ningún visor dibujará nada de aquí. El archivo no termina limpiamente. {bytes} están después del final del archivo. Todo decodificador se detiene en el byte de cierre, así que estos no se leen ni se dibujan nunca. Suelen ser un segundo archivo pegado al primero, o un programa que escribió más allá de sí mismo. Cortar el archivo en el byte de cierre no pierde nada. Un fotograma pide mantenerse menos de 0,02 segundos, y ningún navegador lo hará. {count} fotogramas piden mantenerse menos de 0,02 segundos, y ningún navegador lo hará. Todo navegador desde Netscape redondea a diez cualquier retardo menor de dos centésimas de segundo — una regla escrita en 1996 para los globos giratorios de entonces y nunca retirada. Así que esta animación dice durar {nominal} y en realidad dura {real}, unas {factor} veces más lenta. Escribir 0,02 en lugar de 0,01 le da la velocidad que pide. Todos los fotogramas tienen retardo cero. El archivo no da ninguna indicación de tiempo, así que a qué velocidad va depende enteramente del visor — normalmente diez fotogramas por segundo, pero nada lo garantiza. Dos navegadores pueden reproducir esto a dos velocidades distintas y tener razón los dos. Los fotogramas no llevan un ritmo parejo: {delays} retardos distintos, de {shortest} a {longest}. Un último fotograma sostenido es deliberado y común. Un puñado de retardos dispersos por el medio suele venir de un conversor que dejó caer fotogramas de un vídeo y estiró los vecinos para tapar el hueco. No hay bloque de bucle, así que esto se reproduce una vez y para. El bucle no forma parte de la especificación GIF. Es un bloque que Netscape inventó en 1995 y que todo el mundo implementó igualmente; un archivo sin él es un archivo que todo navegador muestra exactamente una vez. Si esto debía repetirse, el programa que lo escribió se dejó el bloque fuera. Esto se reproduce una vez y luego para. Esto se reproduce {count} veces y luego para. El bloque de bucle nombra una cuenta en lugar del cero habitual, que significa para siempre. Algunos visores antiguos ignoran la cuenta y repiten igualmente. Todos los fotogramas redibujan el lienzo entero. Un GIF puede guardar de un fotograma solo el rectángulo que cambió desde el anterior, y por eso la grabación de una ventana casi quieta puede ser pequeña. Aquí no lo hace ninguno: cada fotograma es el lienzo entero, ⁦{width}×{height}⁩. Eso es correcto para imágenes sin relación entre sí, y es espacio regalado en cualquier cosa filmada o grabada, donde la mayor parte de la imagen no se mueve. Un fotograma de {total} redibuja el lienzo entero; el resto guarda solo la parte que cambió. {count} fotogramas de {total} redibujan el lienzo entero; el resto guarda solo la parte que cambió. Así se ve un GIF optimizado. Los de lienzo entero suelen ser el primer fotograma y cualquier punto donde la imagen cambió por completo. Ningún fotograma redibuja el lienzo entero. Cada fotograma después del primero guarda solo el rectángulo que cambió, que es el formato bien usado y la razón de que este archivo sea tan pequeño como es. Un fotograma se sale del lienzo. {count} fotogramas se salen del lienzo. El lienzo es ⁦{width}×{height}⁩ y un fotograma reclama un rectángulo que se sale del borde. Los decodificadores no se ponen de acuerdo sobre qué hacer con lo que sobresale: unos lo recortan, otros rechazan el archivo. El lienzo es ⁦{width}×{height}⁩ y algunos fotogramas reclaman un rectángulo que se sale del borde. Los decodificadores no se ponen de acuerdo sobre qué hacer con lo que sobresale: unos lo recortan, otros rechazan el archivo. Un fotograma lleva su propia tabla de colores, que cuesta {bytes} — el {share} del archivo. {count} fotogramas llevan su propia tabla de colores, que cuesta {bytes} — el {share} del archivo. Una paleta propia le permite a un fotograma usar colores que la tabla compartida no tiene, y cuesta tres bytes por entrada cada vez que se escribe. Cuando los fotogramas son de la misma escena, una sola tabla para todos es a la vez más pequeña y más estable de ver: una paleta que da tumbos entre fotogramas es exactamente lo que es el parpadeo del GIF. No hay tabla de colores global. Nada malo hay en eso — aquí cada fotograma trae la suya — pero significa que un visor no tiene con qué pintar el lienzo antes de que llegue el primer fotograma. {entries} entradas de las tablas de colores no se usan nunca, y eso son {bytes}. Las tablas de este archivo declaran {declared} colores y los píxeles se refieren a {referenced} de ellos. Una tabla de colores mide siempre una potencia de dos, sea lo que sea que lleve dentro, así que un fotograma que usa nueve colores igualmente recibe dieciséis; algo de redondeo es inevitable. Mucho más que eso significa que las paletas se hicieron para una imagen distinta de la que acabó dentro. Toda la animación se dibuja con un solo color. Toda la animación se dibuja con {count} colores. Eso es dibujo plano, y es para lo que se diseñó el GIF. Un archivo así comprime bien y tramea mal, así que si se ve moteado el tramado es lo que hay que apagar. Una fotografía, o algo salido de una. El GIF le da a un fotograma como mucho 256 colores, así que cualquier cosa con un degradado se está aproximando — y de ahí vienen el tramado y el ruido que hacen grande un archivo. Hay un bloque de comentario de {bytes} en este archivo. Los comentarios no los muestra ningún visor y los lleva cada copia del archivo. Suelen ser el nombre de lo que lo escribió, y de vez en cuando algo que su autor no habría elegido publicar. Un paquete de metadatos XMP ocupa {bytes} — el {share} del archivo. XMP es el bloque XML que un editor de imágenes escribe para dejar constancia de lo que hizo, y puede llevar el historial de ediciones, el programa y a veces al autor. Ningún visor dibuja nada de eso. Quitarlo no le cuesta nada a la imagen. Un perfil de color ICC ocupa {bytes}. El perfil dice qué significan como colores los números de la paleta. Casi nada lee uno dentro de un GIF, así que suele ser peso a cambio de nada — pero quitarlo puede desplazar los colores en los visores que sí lo leen. Hay una extensión de texto plano en este archivo. Un bloque que le pide al visor dibujar texto sobre la imagen en una rejilla de celdas. Estaba en la especificación de 1989, no lo implementó nunca nada, y todo decodificador se lo salta. Diga lo que diga, no va a aparecer. Hay un bloque de aplicación llamado «{name}», de {bytes}. Los bloques de aplicación son la vía por la que entra en un GIF todo lo que queda fuera de la especificación. Los visores se saltan los que no reconocen, así que este es peso salvo que algo concreto lo esté leyendo. Un fotograma está entrelazado. {count} fotogramas están entrelazados. Las filas se guardan en cuatro pasadas para que una imagen que llegaba por una línea lenta mostrara pronto una versión tosca de sí misma. Tenía sentido en 1993, comprime algo peor que guardar las filas en orden, y hoy ningún visor sale ganando. Este archivo dice ser GIF{version} y no GIF89a. GIF87a vino primero y no tiene bloques de tiempo, ni transparencia, ni bloque de bucle. Un archivo que se declara 87a llevando cualquiera de esas cosas es común — los decodificadores no lo comprueban — pero es señal de que la cabecera se copió en vez de escribirse. El color de fondo es el índice {index}, y la tabla global solo tiene {entries} entradas. No va a fallar nada — los visores usan transparente en su lugar — pero significa que el campo nunca se puso, o se puso para una paleta que ya no es la del archivo. La relación de aspecto de píxel está puesta en {ratio}. Un campo para pantallas que no tenían píxeles cuadrados. Todo visor moderno lo ignora y dibuja el fotograma a su tamaño guardado, así que un archivo que se apoye en él se verá estirado para quien lo hizo y normal para todos los demás. El compresor reinició su diccionario {count} veces. LZW va construyendo un diccionario sobre la marcha y le caben 4096 entradas; cuando se llena, el codificador empieza de nuevo. Una vez por fotograma es normal — así empieza un fotograma. Más que eso significa que la imagen era lo bastante variada como para agotar el diccionario a medio camino, que es lo que hacen una fotografía o un tramado fuerte, y por eso esos archivos son grandes. Un fotograma es idéntico al anterior. {count} fotogramas son idénticos al anterior. Cuestan todo su tamaño comprimido y no cambian nada en pantalla. Sumar su retardo al fotograma anterior se vería exactamente igual y ocuparía menos. Un fotograma no se decodifica por completo. {count} fotogramas no se decodifican por completo. Los datos comprimidos se acaban antes de que el fotograma esté lleno. Un visor dibujará lo que pueda y dejará en blanco el resto del rectángulo. tu GIF no ha ido a ninguna parte. {total} archivos cargados. {platform} algo ha contactado con {hosts}, cosa que esta herramienta no hace nunca. {platform} Los scripts propios de la página para publicidad, medición y el botón de donación se han cargado desde {hosts} host; a ninguno se le ha dado un archivo. Los scripts propios de la página para publicidad, medición y el botón de donación se han cargado desde {hosts} hosts; a ninguno se le ha dado un archivo.

Ver como Markdown

# Analizador de GIF — qué hay de verdad dentro de un GIF

Fotogramas, duraciones, paletas y adónde fue cada byte.

> Desmonta un GIF en el navegador: cada fotograma con su duración y su descarte, las tablas de color, las repeticiones y un desglose byte a byte de adónde se fue el tamaño del archivo. No se sube nada.

Esta es una herramienta interactiva de navegador en https://abox.tools/es/analizar-gif/. Los archivos se procesan en el dispositivo donde se ejecuta ese navegador. La página explica las funciones opcionales de red y los envíos deliberados. Lo que sigue es su explicación escrita; abre la dirección para usarla.

## Tus GIF se **procesan en tu navegador**. No se suben para procesarlos.

El archivo lo abre y lo desmonta tu propio navegador: la estructura de bloques, la descompresión LZW y cada fotograma dibujado en esta página se hacen en este dispositivo. Al otro lado de esta página no hay ningún servidor al que mandar un archivo, aunque algo de aquí quisiera hacerlo.

- ✗ Sin subidas
- ✗ Sin cuenta
- ✓ Funciona sin conexión
- ✓ Código abierto
- ✓ Los archivos no salen de tu dispositivo

## Cómo analizar un GIF

1. **Elige un GIF.** Suéltalo sobre el selector o búscalo a mano. El navegador lo lee directamente de tu disco, y mientras tanto no sale nada a ninguna parte.
2. **Lee primero el resumen.** El tamaño del lienzo, el número de fotogramas, cuánto dice la animación que dura y cuánto dura de verdad. Esas dos últimas cifras se separan más a menudo de lo que la gente espera, y el motivo está en la sección siguiente.
3. **Mira lo que llama la atención.** Cada línea de ahí está medida sobre tu archivo: duraciones que ningún navegador va a respetar, un bloque de repetición que falta, tablas de color a las que no apunta nada, metadatos más grandes que algunos de los fotogramas. Nada es una suposición sobre lo que pretendías hacer.
4. **Mira adónde fueron los bytes.** Cada byte del archivo está en exactamente una fila, y las filas suman el archivo. Si la mayor parte no está en «píxeles comprimidos», el resto de la tabla dice dónde está en su lugar.
5. **Repasa los fotogramas.** Cada uno muestra su duración, su rectángulo, su método de descarte y su tamaño. Cambia entre «el lienzo después de cada fotograma» y «solo lo que guarda cada fotograma»: con lo segundo ves si el archivo está optimizado, porque un GIF bien hecho guarda rectángulos diminutos y uno mal hecho guarda la imagen entera cada vez.
6. **Llévate el informe si lo necesitas.** El análisis completo en texto plano, para pegarlo en un mensaje o guardarlo junto al archivo. Se construye en la página a partir de lo que ya está en tu pantalla.

## La versión larga

[Qué hay de verdad dentro de un GIF](https://abox.tools/es/guias/que-hay-dentro-de-un-gif/): Fotogramas, retardos, métodos de descarte y tablas de color explicados, por qué los navegadores rechazan los retardos más rápidos, y cómo averiguar adónde se ha ido el tamaño de un GIF.

## También en la caja

- [Compresor de vídeo](https://abox.tools/es/comprimir-video/): Indica el tamaño máximo. La herramienta calcula los ajustes y mide el resultado antes de entregarlo.
- [Conversor a MP4](https://abox.tools/es/convertir-a-mp4/): La grabación de pantalla, el MKV o el vídeo de cámara, en H.264 y AAC dentro de un MP4. Copia lo compatible y recodifica solo lo necesario.
- [Girar vídeo](https://abox.tools/es/girar-video/): Un cuarto de vuelta o media vuelta. Al girar mediante la cabecera, los fotogramas quedan intactos.
- [Imágenes a vídeo](https://abox.tools/es/imagenes-a-video/): Convierte una carpeta de imágenes en un vídeo.

## Preguntas

### ¿Se sube mi GIF a alguna parte?

No. El archivo lo lee, lo descomprime y lo dibuja tu propio navegador en tu propio equipo. Esta herramienta no tiene lado servidor, y la `Content-Security-Policy` de la página nombra todas las direcciones que puede contactar: ninguna es nuestra. Desconéctate de la red y verás que sigue analizando GIF.

### ¿Por qué mi GIF va más lento de lo que dicen las duraciones?

Porque todos los navegadores se niegan a respetar una duración menor de dos centésimas de segundo y mantienen el fotograma una décima en su lugar. La regla se escribió en Netscape en 1996, para los globos giratorios y los carteles de «en obras» de la época, y se ha copiado a todos los navegadores desde entonces; nadie la ha quitado nunca. \
\
Así que un GIF cuyos fotogramas dicen todos 0,01 s no se reproduce a 100 fotogramas por segundo. Va a 10, que es entre cinco y diez veces más lento de lo que pretendía el programa que lo hizo. Esta página enseña las dos cifras, lo que dice el archivo y lo que va a hacer de verdad, y marca los fotogramas afectados. El arreglo, en el programa que hizo el archivo, es escribir 0,02 en vez de 0,01.

### ¿Qué significa «descarte»?

Qué dejar en pantalla cuando se acaba el tiempo de un fotograma, y es el campo que decide si una animación se ve bien o se emborrona. \
\
**Dejarlo donde está** significa que el siguiente fotograma pinta encima de este, que es lo que quieres cuando los fotogramas son opacos y se tapan unos a otros. **Volver al fondo** borra primero el rectángulo del fotograma, que es lo que necesita la transparencia: sin eso, las partes transparentes del siguiente fotograma enseñan el anterior por debajo. **Restaurar lo que había debajo** devuelve lo que estuviera ahí antes de que este fotograma pintara, que es como se guarda un objeto pequeño en movimiento sobre un fondo quieto. Y **sin especificar** quiere decir que el archivo no dijo nada, y todos los visores lo tratan como «dejarlo donde está».

### ¿Por qué es tan grande mi GIF?

La tabla «Adónde fueron los bytes» responde a eso para tu archivo concreto en vez de en general, y solo hay unas pocas respuestas posibles. \
\
Si casi todo está en **píxeles comprimidos**, el archivo es sencillamente mucha imagen: un GIF guarda cada fotograma como píxeles enteros, sin compensación de movimiento y sin mando de calidad, así que el tamaño es más o menos el área por el número de fotogramas. Menos fotogramas, un tamaño menor o menos colores son las únicas palancas. \
\
Si una parte grande está en **tablas de color**, el archivo escribe una paleta por fotograma a 768 bytes cada una. Si una parte grande está en **metadatos**, un editor se dejó ahí un paquete XMP y se puede quitar sin tocar la imagen. Y si todos los fotogramas cubren el lienzo entero, el codificador nunca averiguó qué parte cambió de verdad, y en cualquier cosa filmada o grabada eso es casi todo el archivo.

### ¿Cuál es la diferencia entre las dos vistas de fotograma?

**El lienzo después de cada fotograma** es lo que enseña un visor en ese momento: este fotograma dibujado encima de lo que dejaron los anteriores. **Solo lo que guarda cada fotograma** es el rectángulo que el archivo tiene de verdad para ese fotograma, por sí solo y sin nada debajo. \
\
La segunda es la interesante. Un GIF puede guardar un fotograma como solo la parte de la imagen que cambió, y por eso una grabación de pantalla de una ventana casi quieta puede ser pequeña. Si todos los fotogramas de tu archivo son el lienzo completo, nadie hizo ese trabajo, y mirando la animación no te enteras: solo mirando lo que hay guardado.

### Dice que mi archivo tiene un comentario o XMP. ¿Qué es eso?

Texto que viaja junto a la imagen y que ningún visor dibuja. Un bloque de comentario suele ser el nombre del programa que escribió el archivo. Un paquete XMP es el XML que un editor de imágenes escribe para dejar constancia de lo que hizo, y puede llevar el historial de ediciones, la versión del programa y a veces el nombre del autor. \
\
Esta página imprime los dos enteros, porque la pregunta interesante sobre los metadatos es qué dicen, no que existan. Se te enseñan a ti y a nadie más: nada en este repositorio se los lee a nadie.

### ¿Puede abrir un GIF roto?

Lo intenta, y te dice dónde se rindió. Un archivo que acaba a mitad de un bloque, que tiene un byte donde debería ir un marcador o que lleva un fotograma cuyos datos comprimidos se acaban antes de tiempo seguirá enseñando todo lo que era legible hasta ese punto, con el problema nombrado arriba. Ese es justo el caso en el que más se quiere un analizador, así que tirar el archivo entero por un byte malo sería equivocarse.

### ¿Cambia mi archivo?

No. Esta herramienta solo lee. No hay archivo de salida, ni recodificación, ni ningún botón aquí que escriba un GIF: lo único que puedes descargar es una copia en texto plano del análisis. Tu original sigue intacto en tu disco, que es también la respuesta honesta a qué pasa si cierras la pestaña.

### ¿Es gratis? ¿Necesito una cuenta?

Es gratis, sin cuenta, inicio de sesión ni periodo de prueba. Leer el archivo sigue dependiendo de la memoria de tu dispositivo. El dibujo se detiene al alcanzar 300 millones de píxeles decodificados o unos 512 MiB estimados de búferes de esta página; no es un límite de memoria total del navegador. Después de detener o cancelar el dibujo, siguen disponibles las cabeceras, el recuento de bytes y los tiempos. Los fotogramas no dibujados se describen desde sus cabeceras; no están disponibles los totales completos de uso de píxeles ni la vista previa nativa. El análisis inicial y las operaciones nativas de memoria o lienzo no se pueden interrumpir durante una llamada. El sitio incluye publicidad; los anuncios no reciben información sobre tu archivo.

### ¿Funciona sin conexión?

Sí. Carga la página una vez, desconéctate de internet y verás que sigue funcionando. Esa es además la forma más sencilla de demostrar que no se sube nada: una herramienta que mandara tu GIF fuera a analizar se pararía en cuanto desenchufaras.

## Cómo se comprueba la promesa de privacidad

- **El procesamiento se hace en este navegador.** La herramienta procesa entradas y resultados en el navegador. Su código no los sube para procesarlos. Content-Security-Policy limita recursos y destinos, pero los hosts permitidos pueden recibir solicitudes: no inspecciona sus datos ni prueba por sí sola que nada se envíe. Compara código y solicitudes de la operación concreta o complétala desconectado.
- **El lector son cuatro archivos de este repositorio.** Aquí nada usa el decodificador de GIF del navegador para averiguar qué hay en el archivo, porque ese decodificador no dice adónde fue un byte. Así que el formato se lee a mano: `src/gif.js` recorre los bloques, `src/lzw.js` expande los píxeles, `src/frames.js` los apila y `src/budget.js` vuelve a sumar las partes y comprueba que dan el tamaño del archivo.
- **Los comentarios y los metadatos se te enseñan a ti, y a nadie más.** Un GIF puede llevar un bloque de comentario, un paquete XMP que describe una edición o un perfil de color, y esta página los imprime todos. Se ponen en la pantalla delante de ti y no van a ninguna otra parte: en este repositorio no hay ningún evento de analítica que lleve nada de eso. Los comentarios opcionales solo envían herramienta, voto y motivo fijos, nunca metadatos del archivo.
- **Qué carga Google, y qué no llega a ver.** Los scripts de publicidad y de medición vienen de Google. A ninguno se le entrega nada sobre tu archivo: ni el archivo, ni una miniatura, ni un nombre, un tamaño, un recuento de fotogramas o un comentario. Cada línea que lee, descomprime o dibuja un GIF se sirve desde este origen y está en el repositorio.
- **Qué carga el botón de donación, y qué no llega a ver.** El botón «Buy me a coffee» de la cabecera lo dibuja un script de cdnjs.buymeacoffee.com y coge su tipografía de Google Fonts. No es más que un enlace: no informa de tu visita y no se le entrega nada sobre ti ni sobre tus archivos. No pasa nada mientras no lo pulses, y lo que abrirías entonces es el sitio de otra persona.
- **Funciona sin conexión.** Desconéctate de la red y todo lo de esta página sigue funcionando. Es la prueba más sencilla de todas: una herramienta que mandara tu GIF fuera para analizarlo se pararía en cuanto desenchufaras.

**Compruébalo tú.** Nada de lo anterior hay que aceptarlo por fe. Esta página se genera a partir de las plantillas y la configuración del repositorio, con un script de compilación que puedes leer y ejecutar por tu cuenta, y el resultado se publica en la rama `dist`. Así puedes comparar lo que se sirve con lo que sale de compilar las fuentes: https://github.com/A-Box-of-Tools/website

Los archivos por los que conviene empezar son `config/site.toml`, donde está la Content-Security-Policy, `src/gif.js` para el lector de bloques que recorre el archivo, `src/lzw.js` para el descompresor y `src/budget.js` para la contabilidad de bytes. En ninguno de ellos hay una línea capaz de llegar a la red.

Cómo analizar un GIF

Elige un GIF. Suéltalo sobre el selector o búscalo a mano. El navegador lo lee directamente de tu disco, y mientras tanto no sale nada a ninguna parte.
Lee primero el resumen. El tamaño del lienzo, el número de fotogramas, cuánto dice la animación que dura y cuánto dura de verdad. Esas dos últimas cifras se separan más a menudo de lo que la gente espera, y el motivo está en la sección siguiente.
Mira lo que llama la atención. Cada línea de ahí está medida sobre tu archivo: duraciones que ningún navegador va a respetar, un bloque de repetición que falta, tablas de color a las que no apunta nada, metadatos más grandes que algunos de los fotogramas. Nada es una suposición sobre lo que pretendías hacer.
Mira adónde fueron los bytes. Cada byte del archivo está en exactamente una fila, y las filas suman el archivo. Si la mayor parte no está en «píxeles comprimidos», el resto de la tabla dice dónde está en su lugar.
Repasa los fotogramas. Cada uno muestra su duración, su rectángulo, su método de descarte y su tamaño. Cambia entre «el lienzo después de cada fotograma» y «solo lo que guarda cada fotograma»: con lo segundo ves si el archivo está optimizado, porque un GIF bien hecho guarda rectángulos diminutos y uno mal hecho guarda la imagen entera cada vez.
Llévate el informe si lo necesitas. El análisis completo en texto plano, para pegarlo en un mensaje o guardarlo junto al archivo. Se construye en la página a partir de lo que ya está en tu pantalla.

La versión larga

Qué hay de verdad dentro de un GIF Fotogramas, retardos, métodos de descarte y tablas de color explicados, por qué los navegadores rechazan los retardos más rápidos, y cómo averiguar adónde se ha ido el tamaño de un GIF.

Preguntas

¿Se sube mi GIF a alguna parte?

No. El archivo lo lee, lo descomprime y lo dibuja tu propio navegador en tu propio equipo. Esta herramienta no tiene lado servidor, y la Content-Security-Policy de la página nombra todas las direcciones que puede contactar: ninguna es nuestra. Desconéctate de la red y verás que sigue analizando GIF.

¿Por qué mi GIF va más lento de lo que dicen las duraciones?

Porque todos los navegadores se niegan a respetar una duración menor de dos centésimas de segundo y mantienen el fotograma una décima en su lugar. La regla se escribió en Netscape en 1996, para los globos giratorios y los carteles de «en obras» de la época, y se ha copiado a todos los navegadores desde entonces; nadie la ha quitado nunca.

Así que un GIF cuyos fotogramas dicen todos 0,01 s no se reproduce a 100 fotogramas por segundo. Va a 10, que es entre cinco y diez veces más lento de lo que pretendía el programa que lo hizo. Esta página enseña las dos cifras, lo que dice el archivo y lo que va a hacer de verdad, y marca los fotogramas afectados. El arreglo, en el programa que hizo el archivo, es escribir 0,02 en vez de 0,01.

¿Qué significa «descarte»?

Qué dejar en pantalla cuando se acaba el tiempo de un fotograma, y es el campo que decide si una animación se ve bien o se emborrona.

Dejarlo donde está significa que el siguiente fotograma pinta encima de este, que es lo que quieres cuando los fotogramas son opacos y se tapan unos a otros. Volver al fondo borra primero el rectángulo del fotograma, que es lo que necesita la transparencia: sin eso, las partes transparentes del siguiente fotograma enseñan el anterior por debajo. Restaurar lo que había debajo devuelve lo que estuviera ahí antes de que este fotograma pintara, que es como se guarda un objeto pequeño en movimiento sobre un fondo quieto. Y sin especificar quiere decir que el archivo no dijo nada, y todos los visores lo tratan como «dejarlo donde está».

¿Por qué es tan grande mi GIF?

La tabla «Adónde fueron los bytes» responde a eso para tu archivo concreto en vez de en general, y solo hay unas pocas respuestas posibles.

Si casi todo está en píxeles comprimidos, el archivo es sencillamente mucha imagen: un GIF guarda cada fotograma como píxeles enteros, sin compensación de movimiento y sin mando de calidad, así que el tamaño es más o menos el área por el número de fotogramas. Menos fotogramas, un tamaño menor o menos colores son las únicas palancas.

Si una parte grande está en tablas de color, el archivo escribe una paleta por fotograma a 768 bytes cada una. Si una parte grande está en metadatos, un editor se dejó ahí un paquete XMP y se puede quitar sin tocar la imagen. Y si todos los fotogramas cubren el lienzo entero, el codificador nunca averiguó qué parte cambió de verdad, y en cualquier cosa filmada o grabada eso es casi todo el archivo.

¿Cuál es la diferencia entre las dos vistas de fotograma?

El lienzo después de cada fotograma es lo que enseña un visor en ese momento: este fotograma dibujado encima de lo que dejaron los anteriores. Solo lo que guarda cada fotograma es el rectángulo que el archivo tiene de verdad para ese fotograma, por sí solo y sin nada debajo.

La segunda es la interesante. Un GIF puede guardar un fotograma como solo la parte de la imagen que cambió, y por eso una grabación de pantalla de una ventana casi quieta puede ser pequeña. Si todos los fotogramas de tu archivo son el lienzo completo, nadie hizo ese trabajo, y mirando la animación no te enteras: solo mirando lo que hay guardado.

Dice que mi archivo tiene un comentario o XMP. ¿Qué es eso?

Texto que viaja junto a la imagen y que ningún visor dibuja. Un bloque de comentario suele ser el nombre del programa que escribió el archivo. Un paquete XMP es el XML que un editor de imágenes escribe para dejar constancia de lo que hizo, y puede llevar el historial de ediciones, la versión del programa y a veces el nombre del autor.

Esta página imprime los dos enteros, porque la pregunta interesante sobre los metadatos es qué dicen, no que existan. Se te enseñan a ti y a nadie más: nada en este repositorio se los lee a nadie.

¿Puede abrir un GIF roto?

¿Cambia mi archivo?

¿Es gratis? ¿Necesito una cuenta?

¿Funciona sin conexión?

Analizador de GIF — qué hay de verdad dentro de un GIF

Cómo se comprueba la promesa de privacidad

Elige un GIF

Lo que llama la atención

Adónde fueron los bytes

Los colores

La tabla global

Qué más hay ahí dentro

Cómo analizar un GIF

La versión larga

Preguntas

Cómo se comprueba la promesa de privacidad

Elige un GIF

—

Lo que llama la atención

Adónde fueron los bytes

Fotograma a fotograma

Los colores

La tabla global

Qué más hay ahí dentro

Cómo analizar un GIF

La versión larga

También en la caja

Preguntas