Analisar GIF — quadros, tempos, paleta e tamanho do arquivo

Q: Qual é a diferença entre as duas visões de quadro?

A tela depois de cada quadro é o que um visualizador mostra naquele momento: este quadro desenhado por cima do que os anteriores deixaram. Só o que cada quadro guarda é o retângulo que o arquivo realmente tem para aquele quadro, sozinho, sem nada embaixo. A segunda é a interessante. Um GIF pode guardar de um quadro só a parte da imagem que mudou, e é por isso que a gravação de tela de uma janela quase parada pode ser pequena. Se todo quadro do seu arquivo é a tela inteira, ninguém fez esse trabalho, e olhando a animação você não descobre: só olhando o que está guardado.

Escolha um GIF

Arraste um GIF para cá ou clique para procurar — animado ou parado, de qualquer tamanho

Para onde foram os bytes

Cada byte do arquivo está em exatamente uma linha, e as linhas somam o arquivo. Se não somassem, a última linha diria isso, em vez de a barra se esticar caladinha até caber.

Para onde foram os bytes deste arquivo
Parte	Bytes	Fatia
O arquivo inteiro	—	100%

Desenhando {name}: {done} de {total} quadros… Análise cancelada. A leitura nativa do arquivo ainda pode terminar. A tela ou um quadro não tem tamanho desenhável. Desenhar ultrapassaria o limite estimado de buffers de 512 MiB desta página. O desenho atingiu o limite de 300 milhões de pixels decodificados. O desenho foi cancelado. O desenho parou: {detail} {drawn} de {total} quadros desenhados. {why} A análise de cabeçalhos, tempos e bytes continua disponível; o uso de pixels não desenhados é desconhecido. A reprodução do navegador está desativada porque o desenho está incompleto. A análise lida continua disponível. Não medido por completo As tabelas declaram {declared} entradas de cor. O uso total de pixels fica indisponível enquanto houver quadros não desenhados. {entries}, {size}, compartilhada por {frames}. Nenhuma entrada é marcada como não usada porque nem todos os pixels foram desenhados. {index}: {colour} — nunca usado Desenho {drawn} de {total} quadros desenhados. {why} Quadros não desenhados são descritos pelos cabeçalhos; o uso total de pixels fica indisponível. O decodificador do seu próprio navegador, tocando o arquivo do jeito que ele está. Lendo {name}… {name} não é um GIF: {why}. Esta ferramenta lê o próprio formato GIF, então não tem nada a dizer sobre outros arquivos. {name} não pôde ser lido: {why} o arquivo termina em {available} bytes e em {at} faltavam {wanted} este arquivo começa com {what}, não com “GIF” um JPEG um PNG um arquivo RIFF — um WebP ou um WAV um PDF um arquivo zip os bytes {bytes} o tamanho de código é {size}, e o formato permite de 2 a 8 {n} quadro {n} quadros {n} cor {n} cores {n} entrada {n} entradas {n} tabela por quadro {n} tabelas por quadro {n} vez {n} vezes {n} bytes {minutes} min {seconds} s {n} s {time} ({fps} fps) {n} quadros pedem menos de 0,02 s, e todo navegador os segura por 0,10 s em vez disso. uma vez — sem bloco de repetição para sempre {n} vezes Problema Vale saber Nota {frames}. {drawn} foram desenhados aqui; o restante é descrito apenas pelos cabeçalhos. {frames}, nenhum deles cobrindo a tela inteira. {frames}, todos cobrindo a tela inteira. {frames}, {n} deles cobrindo a tela inteira. Mostrar os outros {frames} O que o quadro {n} guarda sozinho A tela depois do quadro {n} Quadro {n} não desenhado Atraso {delay} → 0,10 s Retângulo ⁦{width} × {height}⁩ em ⁦{left}, {top}⁩ Paleta {n} próprias a global nenhuma Transparência índice {n} não Tamanho {size} — {share} Entrelaçado sim Compressão {ratio}× Problema os dados terminam cedo demais As tabelas deste arquivo declaram {declared} entre elas, os pixels se referem a {referenced} dessas, e {different} dessas são diferentes umas das outras. {entries}, {size}, compartilhada por {frames}. As entradas apagadas são aquelas a que nenhum pixel se refere. {tables} ({size} no total) Quadro {n} — {colours} As 24 primeiras de {n} são mostradas. O resto está no relatório para baixar. Comentário Texto simples Extensão {code} Um comentário. Nenhum visualizador o mostra, e toda cópia do arquivo o carrega. O bloco de repetição, dizendo para tocar para sempre. Não faz parte da especificação do GIF: a Netscape o inventou em 1995 e todo mundo implementou assim mesmo. O bloco de repetição, dizendo para tocar {times}. Um pacote XMP: o XML que um editor de imagens escreve para registrar o que fez. Nada o desenha. Um perfil de cor ICC, dizendo o que os números da paleta significam como cores. Quase nada lê um de dentro de um GIF. Um bloco de texto simples, que pede ao visualizador para desenhar texto sobre a imagem. Estava na especificação de 1989 e nunca foi implementado por nada. Um bloco de aplicativo. Os visualizadores pulam os que não reconhecem. Dura {time} conforme escrito Na prática toca {time} - {n} quadro(s) abaixo de 0,02 s sobem para 0,10 s em todo navegador Cadência {fps} quadros por segundo Repetições sem bloco de repetição - toca uma vez Paleta global {n} cores nenhuma Cores desenhadas Índice de fundo Copiado. É texto puro, e foi só para a sua área de transferência. Este navegador não deixou a página escrever na área de transferência. Use “Baixar” em vez disso. Cabeçalho e descritor de tela A assinatura, o tamanho da tela e as bandeiras. Treze bytes, em todo GIF que já se fez. Tabela de cores global {colours} cores de três bytes cada, compartilhadas por todo quadro que não traz a sua. Este arquivo não tem: cada quadro carrega a própria paleta. Tabelas de cores por quadro Uma paleta só dele para um quadro que precisava de outras cores. Três bytes por cor, toda vez. Blocos de tempo Oito bytes por quadro: o atraso, o método de limpeza e qual cor é transparente. Descritores de quadro Onze bytes por quadro: onde o retângulo fica, de que tamanho ele é, e com que tamanho de código o compressor começa. Pixels comprimidos A imagem em si, comprimida em LZW. Num GIF saudável isso é quase o arquivo inteiro. Emolduramento de blocos Um byte de comprimento a cada 255 bytes de dados, mais um zero para fechar cada série. Inevitável, e vale ver. Comentários e metadados Blocos de repetição, comentários, perfis de cor e qualquer XMP que um editor tenha deixado para trás. Fecho Um byte dizendo que o arquivo acabou. Bytes depois do fim Dados parados depois do fecho. Nenhum decodificador lê, e é peso puro. Sem contabilizar Bytes dentro de blocos onde este leitor parou. Um arquivo que termina no meio de um bloco deixa alguns. Contado duas vezes Os blocos se sobrepõem, ou seja, este arquivo se contradiz sobre onde eles começam. Não especificado Deixar onde está Voltar para o fundo Restaurar o que havia embaixo Reservado ({n}) Limpeza Análise de GIF — {name} Lido inteiramente no navegador por abox.tools/gif-analyzer/. O arquivo não foi enviado. O arquivo Versão Tela ⁦{width} x {height}⁩ pixels Tamanho {rounded} ({exact}) Quadros Para onde foram os bytes Total O que salta aos olhos Os quadros Texto que o arquivo carrega A paleta global {colours} próprias global tela inteira n.º em tam. atraso limpeza paleta bytes O arquivo termina sem o byte de encerramento, então está incompleto — um download que parou cedo, ou um arquivo cortado. O byte {at} vale 0x{marker}, que não começa nenhum bloco que este formato tenha. Tudo depois dele foi ignorado. Dois blocos de controle gráfico em sequência, em {first} e {second}. O primeiro não descreve imagem nenhuma e não faz nada. O arquivo termina no meio de um bloco que começa em {at}. {detail}. O código {code} veio primeiro, antes de o dicionário ter qualquer coisa. Um visualizador desenha o que consegue e deixa o resto do retângulo em branco. O código {code} aponta para a entrada {code} do dicionário, e só existem {entries}. Um visualizador desenha o que consegue e deixa o resto do retângulo em branco. Não há quadros neste arquivo. O cabeçalho foi lido, mas não veio nenhum bloco de imagem depois. Seja o que for, nenhum visualizador vai desenhar nada daqui. O arquivo não termina de forma limpa. {bytes} ficam depois do fim do arquivo. Todo decodificador para no byte de encerramento, então esses nunca são lidos nem desenhados. Costumam ser um segundo arquivo colado no primeiro, ou um programa que escreveu além de si mesmo. Cortar o arquivo no byte de encerramento não perde nada. Um quadro pede para ficar menos de 0,02 segundo, e nenhum navegador vai fazer isso. {count} quadros pedem para ficar menos de 0,02 segundo, e nenhum navegador vai fazer isso. Todo navegador desde o Netscape arredonda para dez qualquer atraso abaixo de dois centésimos de segundo — uma regra escrita em 1996 para os globos girando da época e nunca removida. Então esta animação diz durar {nominal} e na verdade dura {real}, cerca de {factor} vezes mais devagar. Escrever 0,02 em vez de 0,01 dá a ela a velocidade que está pedindo. Todo quadro tem atraso zero. O arquivo não dá tempo nenhum, então a velocidade fica inteiramente com o visualizador — normalmente dez quadros por segundo, mas nada garante. Dois navegadores podem tocar isto em duas velocidades diferentes e os dois estarem certos. Os quadros não têm ritmo parelho: {delays} atrasos diferentes, de {shortest} a {longest}. Um último quadro segurado por mais tempo é proposital e comum. Atrasos espalhados pelo meio costumam vir de um conversor que descartou quadros de um vídeo e esticou os vizinhos para cobrir o buraco. Não há bloco de repetição, então isto toca uma vez e para. Repetir não faz parte da especificação do GIF. É um bloco que a Netscape inventou em 1995 e que todo mundo implementou assim mesmo; um arquivo sem ele é um arquivo que todo navegador mostra exatamente uma vez. Se a ideia era repetir, quem escreveu deixou o bloco de fora. Isto toca uma vez e então para. Isto toca {count} vezes e então para. O bloco de repetição nomeia uma contagem em vez do zero de sempre, que quer dizer para sempre. Alguns visualizadores antigos ignoram a contagem e repetem assim mesmo. Todo quadro redesenha a tela inteira. Um GIF pode guardar de um quadro só o retângulo que mudou desde o anterior, e é por isso que a gravação de uma janela quase parada pode ser pequena. Aqui nenhum faz isso: cada quadro é a tela inteira, ⁦{width}×{height}⁩. Isso está certo para imagens sem relação entre si, e é espaço jogado fora em qualquer coisa filmada ou gravada, onde a maior parte da imagem não se mexe. Um quadro de {total} redesenha a tela inteira; o resto guarda só a parte que mudou. {count} quadros de {total} redesenham a tela inteira; o resto guarda só a parte que mudou. É assim que um GIF otimizado se parece. Os de tela inteira costumam ser o primeiro quadro e cada ponto em que a imagem mudou por completo. Nenhum quadro redesenha a tela inteira. Cada quadro depois do primeiro guarda só o retângulo que mudou, que é o formato usado direito e a razão de este arquivo ser tão pequeno quanto é. Um quadro passa da tela. {count} quadros passam da tela. A tela é ⁦{width}×{height}⁩ e um quadro reivindica um retângulo que sai da borda. Os decodificadores discordam sobre o que fazer com a sobra: uns cortam, outros recusam o arquivo. A tela é ⁦{width}×{height}⁩ e alguns quadros reivindicam um retângulo que sai da borda. Os decodificadores discordam sobre o que fazer com a sobra: uns cortam, outros recusam o arquivo. Um quadro carrega uma tabela de cores própria, que custa {bytes} — {share} do arquivo. {count} quadros carregam uma tabela de cores própria, que custa {bytes} — {share} do arquivo. Uma paleta própria deixa um quadro usar cores que a tabela compartilhada não tem, e custa três bytes por entrada toda vez que é escrita. Onde os quadros são da mesma cena, uma tabela para todos é ao mesmo tempo menor e mais estável de assistir: uma paleta que sacode de um quadro para o outro é exatamente o que é a tremeliqueira do GIF. Não há tabela de cores global. Não há nada de errado nisso — aqui cada quadro traz a sua — mas quer dizer que um visualizador não tem com o que pintar a tela antes de o primeiro quadro chegar. {entries} entradas das tabelas de cores nunca são usadas, o que dá {bytes}. As tabelas deste arquivo declaram {declared} cores e os pixels usam {referenced} delas. Uma tabela de cores tem sempre uma potência de dois entradas, seja lá o que houver nela, então um quadro que usa nove cores ganha dezesseis mesmo assim; algum arredondamento é inevitável. Muito mais que isso quer dizer que as paletas foram feitas para outra imagem, não a que acabou dentro. A animação inteira desenha com uma cor só. A animação inteira desenha com {count} cores. Isso é arte chapada, e é para isso que o GIF foi feito. Um arquivo assim comprime bem e pontilha mal, então se está parecendo salpicado o pontilhado é o que se deve desligar. Uma fotografia, ou algo saído de uma. O GIF dá a um quadro no máximo 256 cores, então qualquer coisa com um degradê está sendo aproximada — e é daí que vêm o pontilhado e o ruído que deixam um arquivo grande. Há um bloco de comentário de {bytes} neste arquivo. Comentários não são mostrados por visualizador nenhum e vão junto em toda cópia do arquivo. Costumam ser o nome do que o escreveu, e vez ou outra algo que o autor não teria escolhido publicar. Um pacote de metadados XMP ocupa {bytes} — {share} do arquivo. XMP é o bloco XML que um editor de imagens escreve para registrar o que fez, e pode carregar o histórico de edições, o programa e às vezes o autor. Nenhum visualizador desenha nada disso. Tirar não custa nada à imagem. Um perfil de cor ICC ocupa {bytes}. O perfil diz o que os números da paleta significam como cores. Quase nada lê um desses de dentro de um GIF, então costuma ser peso à toa — mas tirar pode deslocar as cores nos visualizadores que leem. Há uma extensão de texto simples neste arquivo. Um bloco que pede ao visualizador para desenhar texto por cima da imagem, numa grade de células. Estava na especificação de 1989, nunca foi implementado por nada, e todo decodificador pula. O que quer que diga, não vai aparecer. Há um bloco de aplicativo chamado “{name}”, de {bytes}. Blocos de aplicativo são o jeito pelo qual tudo que está fora da especificação entra num GIF. Visualizadores pulam os que não reconhecem, então este é peso a menos que algo específico esteja lendo. Um quadro é entrelaçado. {count} quadros são entrelaçados. As linhas ficam guardadas em quatro passadas para que uma imagem chegando por uma linha lenta mostrasse cedo uma versão grosseira de si mesma. Fazia sentido em 1993, comprime um pouco pior que guardar as linhas em ordem, e hoje nenhum visualizador ganha com isso. Este arquivo diz ser GIF{version} e não GIF89a. O GIF87a veio primeiro e não tem blocos de tempo, nem transparência, nem bloco de repetição. Um arquivo que se declara 87a carregando qualquer uma dessas coisas é comum — decodificadores não conferem — mas é sinal de que o cabeçalho foi copiado em vez de escrito. A cor de fundo é o índice {index}, e a tabela global só tem {entries} entradas. Nada vai quebrar — visualizadores usam transparente no lugar — mas quer dizer que o campo nunca foi preenchido, ou foi preenchido para uma paleta que já não é a do arquivo. A proporção de pixel está definida como {ratio}. Um campo para telas que não tinham pixels quadrados. Todo visualizador moderno ignora e desenha o quadro no tamanho guardado, então um arquivo que conta com isso vai parecer esticado para quem o fez e normal para todo mundo. O compressor zerou o dicionário {count} vezes. O LZW monta um dicionário conforme anda e cabem 4.096 entradas; quando enche, o codificador recomeça. Uma vez por quadro é normal — é assim que um quadro começa. Mais que isso quer dizer que a imagem era variada o bastante para esgotar o dicionário no meio do caminho, que é o que uma fotografia ou um pontilhado pesado fazem, e é por isso que esses arquivos são grandes. Um quadro é idêntico ao anterior. {count} quadros são idênticos ao anterior. Eles custam todo o seu tamanho comprimido e não mudam nada na tela. Somar o atraso deles ao quadro anterior ficaria exatamente igual e seria menor. Um quadro não decodifica por completo. {count} quadros não decodificam por completo. Os dados comprimidos acabam antes de o quadro encher. Um visualizador desenha o que consegue e deixa o resto do retângulo em branco. O seu GIF não foi a lugar nenhum. {total} arquivos carregados. {platform} Alguma coisa contatou {hosts}, e esta ferramenta nunca faz isso. {platform} Os scripts do próprio site para publicidade, medição e o botão de doação vieram de {hosts} host; nenhum deles recebeu um arquivo. Os scripts do próprio site para publicidade, medição e o botão de doação vieram de {hosts} hosts; nenhum deles recebeu um arquivo.

Ver como Markdown

# Analisador de GIF — o que tem de verdade dentro de um GIF

Quadros, tempos, paletas e para onde foi cada byte.

> Desmonte um GIF no navegador: cada quadro com o tempo e o descarte dele, as tabelas de cor, as repetições e um detalhamento byte a byte de para onde foi o tamanho do arquivo. Nada é enviado.

Esta é uma ferramenta interativa de navegador em https://abox.tools/pt/analisar-gif/. Os arquivos são processados no dispositivo que executa esse navegador. Compartilhamento deliberado e funções opcionais de rede são explicados na página. A seguir está sua explicação escrita; abra o endereço para usá-la.

## Seus GIFs são **processados no navegador**. Sem envio para processamento.

O arquivo é aberto e desmontado pelo seu próprio navegador: a estrutura de blocos, a descompactação LZW e cada quadro desenhado nesta página acontecem neste computador. Do outro lado desta página não existe servidor nenhum para receber um arquivo, mesmo que algo aqui quisesse mandar.

- ✗ Sem envio
- ✗ Sem conta
- ✓ Funciona offline
- ✓ Código aberto
- ✓ Os arquivos ficam no seu aparelho

## Como analisar um GIF

1. **Escolha um GIF.** Arraste até o seletor ou procure na mão. O navegador lê direto do seu disco, e nesse meio-tempo nada sai daqui.
2. **Leia primeiro o resumo.** O tamanho da tela, a quantidade de quadros, quanto tempo a animação diz que dura e quanto ela toca de verdade. Esses dois últimos divergem mais do que as pessoas esperam, e o motivo está na seção seguinte.
3. **Veja o que chama atenção.** Cada linha ali é medida no seu arquivo: tempos que navegador nenhum vai respeitar, um bloco de repetição faltando, tabelas de cor que ninguém referencia, metadados maiores do que alguns quadros. Nada é um chute sobre o que você pretendia fazer.
4. **Veja para onde foram os bytes.** Cada byte do arquivo está em exatamente uma linha, e as linhas somam o arquivo. Se a maior parte não estiver em “pixels compactados”, o resto da tabela diz onde ela está.
5. **Passe pelos quadros.** Cada um mostra o tempo, o retângulo, o método de descarte e o tamanho dele. Alterne entre “a tela depois de cada quadro” e “só o que cada quadro guarda”: é no segundo que você vê se o arquivo está otimizado, porque um GIF bem feito guarda retângulos minúsculos e um mal feito guarda a imagem inteira toda vez.
6. **Leve o relatório se precisar.** A análise inteira em texto puro, para colar numa mensagem ou guardar ao lado do arquivo. Ele é montado na própria página a partir do que já está na sua tela.

## A versão longa

[O que tem de verdade dentro de um GIF](https://abox.tools/pt/guias/o-que-tem-dentro-de-um-gif/): Quadros, atrasos, métodos de descarte e tabelas de cor explicados, por que os navegadores recusam os atrasos mais rápidos, e como descobrir para onde foi mesmo o tamanho de um GIF.

## Também na caixa

- [Compressor de vídeo](https://abox.tools/pt/comprimir-video/): Diga o tamanho máximo. A ferramenta calcula os ajustes e mede o resultado antes de entregar.
- [Conversor para MP4](https://abox.tools/pt/converter-para-mp4/): Da gravação de tela, do arquivo extraído ou da câmera para um MP4 com H.264 e AAC. Copia o que pode e só recodifica o necessário.
- [Rotacionar vídeo](https://abox.tools/pt/girar-video/): Um quarto de volta, meia volta ou para o outro lado. Na rotação pelo cabeçalho, os quadros da imagem ficam intactos.
- [Imagens para vídeo](https://abox.tools/pt/imagens-para-video/): Transforme uma pasta de imagens em um vídeo.

## Perguntas

### O meu GIF é enviado para algum lugar?

Não. O arquivo é lido, descompactado e desenhado pelo seu próprio navegador, no seu próprio hardware. Esta ferramenta não tem lado servidor, e a `Content-Security-Policy` da página lista todo endereço que ela pode contatar: nenhum é nosso. Tire da tomada e ela continua analisando GIFs.

### Por que meu GIF toca mais devagar do que os tempos dizem?

Porque todo navegador se recusa a respeitar um tempo abaixo de dois centésimos de segundo e segura o quadro por um décimo no lugar. A regra foi escrita dentro do Netscape em 1996, para os globos giratórios e as placas de “em construção” da época, e foi copiada para todo navegador desde então; ninguém nunca tirou. \
\
Então um GIF cujos quadros dizem todos 0,01 s não toca a 100 quadros por segundo. Toca a 10, de cinco a dez vezes mais devagar do que o programa que o fez pretendia. Esta página mostra os dois números, o que o arquivo diz e o que ele vai fazer de verdade, e marca os quadros afetados. O conserto, no programa que escreveu o arquivo, é escrever 0,02 em vez de 0,01.

### O que quer dizer “descarte”?

O que deixar na tela quando o tempo de um quadro acaba, e é o campo que decide se uma animação fica certa ou borra. \
\
**Deixar como está** quer dizer que o próximo quadro pinta por cima deste, que é o que você quer quando os quadros são opacos e se cobrem. **Voltar ao fundo** limpa antes o retângulo do quadro, que é do que a transparência precisa: sem isso, as partes vazadas do próximo quadro mostram o anterior por baixo. **Restaurar o que estava embaixo** devolve o que havia ali antes deste quadro desenhar, que é como se guarda um objeto pequeno se mexendo sobre um fundo parado. E **não especificado** quer dizer que o arquivo não falou nada, e todo visualizador trata isso como “deixar como está”.

### Por que o meu GIF é tão grande?

A tabela “Para onde foram os bytes” responde isso para o seu arquivo específico em vez de responder em geral, e só existem algumas respostas possíveis. \
\
Se quase tudo estiver em **pixels compactados**, o arquivo é simplesmente muita imagem: o GIF guarda cada quadro como pixels inteiros, sem compensação de movimento e sem botão de qualidade, então o tamanho é aproximadamente a área vezes a quantidade de quadros. Menos quadros, um tamanho menor ou menos cores são as únicas alavancas. \
\
Se uma fatia grande estiver em **tabelas de cor**, o arquivo está escrevendo uma paleta por quadro, a 768 bytes cada. Se uma fatia grande estiver em **metadados**, algum editor deixou um pacote XMP para trás, e ele pode sair sem encostar na imagem. E se todos os quadros cobrem a tela inteira, o codificador nunca descobriu qual parte mudou de verdade, e em qualquer coisa filmada ou gravada isso é quase o arquivo todo.

### Qual é a diferença entre as duas visões de quadro?

**A tela depois de cada quadro** é o que um visualizador mostra naquele momento: este quadro desenhado por cima do que os anteriores deixaram. **Só o que cada quadro guarda** é o retângulo que o arquivo realmente tem para aquele quadro, sozinho, sem nada embaixo. \
\
A segunda é a interessante. Um GIF pode guardar de um quadro só a parte da imagem que mudou, e é por isso que a gravação de tela de uma janela quase parada pode ser pequena. Se todo quadro do seu arquivo é a tela inteira, ninguém fez esse trabalho, e olhando a animação você não descobre: só olhando o que está guardado.

### Diz que o meu arquivo tem um comentário ou XMP. O que é isso?

Texto que viaja junto com a imagem e que visualizador nenhum desenha. Um bloco de comentário costuma ser o nome do programa que escreveu o arquivo. Um pacote XMP é o XML que um editor de imagens escreve para registrar o que fez, e pode levar o histórico de edições, a versão do programa e às vezes o nome do autor. \
\
Esta página imprime os dois por inteiro, porque a pergunta interessante sobre metadados é o que eles dizem, não o fato de existirem. São mostrados a você e a mais ninguém: nada neste repositório lê nada disso para alguém.

### Ele abre um GIF quebrado?

Ele tenta, e avisa onde desistiu. Um arquivo que termina no meio de um bloco, que tem um byte onde deveria haver um marcador, ou que carrega um quadro cujos dados compactados acabam cedo demais ainda vai mostrar tudo o que dava para ler até ali, com o problema nomeado no topo. Esse é justamente o caso em que mais se quer um analisador, então jogar o arquivo inteiro fora por causa de um byte ruim seria o comportamento errado.

### Ele altera o meu arquivo?

Não. Esta ferramenta só lê. Não existe arquivo de saída, nem recodificação, nem botão aqui que escreva um GIF: a única coisa que dá para baixar é uma cópia da análise em texto puro. O seu original continua intocado no seu disco, que é também a resposta honesta para o que acontece se você fechar a aba.

### É grátis, e preciso de conta?

É grátis, sem conta, início de sessão ou período de teste. A leitura do arquivo ainda depende da memória do seu dispositivo. O desenho para ao atingir 300 milhões de pixels decodificados ou uma estimativa de 512 MiB de buffers desta página; não é um limite de memória total do navegador. Após a parada ou o cancelamento, os cabeçalhos, a contagem de bytes e os tempos continuam disponíveis. Os quadros não desenhados são descritos pelos cabeçalhos; os totais completos de uso de pixels e a prévia nativa não ficam disponíveis. A análise inicial e as operações nativas de memória ou canvas não podem ser interrompidas durante uma chamada. O site tem publicidade; os anúncios não recebem informações sobre seu arquivo.

### Funciona offline?

Funciona. Carregue a página uma vez, depois desligue a internet e ela continua funcionando. Esse é também o jeito mais simples de provar que nada está sendo enviado: uma ferramenta que mandasse o seu GIF embora para ser analisado pararia no instante em que você tirasse da tomada.

## Como dá para conferir a promessa de privacidade

- **O processamento acontece neste navegador.** A ferramenta processa entradas e resultados no navegador. Seu código não os envia para processamento. Content-Security-Policy limita recursos e destinos, mas hosts permitidos podem receber solicitações: ela não inspeciona o conteúdo nem prova sozinha que nada é enviado. Compare código e solicitações da operação ou conclua a operação local desconectado.
- **O leitor são quatro arquivos deste repositório.** Nada aqui usa o decodificador de GIF do navegador para descobrir o que tem no arquivo, porque esse decodificador não diz para onde foi um byte. Então o formato é lido na mão: `src/gif.js` percorre os blocos, `src/lzw.js` expande os pixels, `src/frames.js` empilha tudo e `src/budget.js` soma as partes de volta e confere se elas dão o tamanho do arquivo.
- **Comentários e metadados são mostrados a você, e a mais ninguém.** Um GIF pode carregar um bloco de comentário, um pacote XMP descrevendo uma edição ou um perfil de cor, e esta página imprime todos eles. Eles vão parar na tela na sua frente e em lugar nenhum além disso: não existe neste repositório um evento de medição que leve nada disso. O feedback opcional envia somente ferramenta, voto e motivo fixos, nunca metadados lidos do arquivo.
- **O que o Google carrega, e o que não chega até ele.** Os scripts de publicidade e de medição vêm do Google. Nenhum dos dois recebe coisa alguma sobre o seu arquivo: nem o arquivo, nem uma miniatura, nem um nome, um tamanho, uma contagem de quadros ou um comentário. Toda linha que lê, descompacta ou desenha um GIF é servida desta origem e está listada no repositório.
- **O que o botão de doação carrega, e o que não chega até ele.** O botão “Buy me a coffee” do cabeçalho é desenhado por um script de cdnjs.buymeacoffee.com e pega as letras no Google Fonts. Ele não é mais do que um link: não avisa ninguém da sua visita e não recebe nada sobre você nem sobre os seus arquivos. Nada acontece enquanto você não clicar, e o que você abriria ao clicar é o site de outra pessoa.
- **Funciona offline.** Desligue a rede e tudo nesta página continua funcionando. Essa é a prova mais simples de todas: uma ferramenta que mandasse o seu GIF embora para ser analisado pararia no instante em que você tirasse da tomada.

**Confira você mesmo.** Nada do que está acima precisa ser aceito na fé. Esta página é gerada a partir dos modelos e da configuração do repositório por um script de compilação que você pode ler e rodar por conta própria, e o resultado vai para a branch `dist`. Ou seja, dá para comparar o que é servido com o que uma compilação das fontes produz: https://github.com/A-Box-of-Tools/website

Os primeiros arquivos que valem a leitura são `config/site.toml` para a Content-Security-Policy, `src/gif.js` para o leitor de blocos que percorre o arquivo, `src/lzw.js` para o descompactador e `src/budget.js` para a contabilidade dos bytes. Em nenhum deles existe uma linha capaz de alcançar a rede.

Como analisar um GIF

Escolha um GIF. Arraste até o seletor ou procure na mão. O navegador lê direto do seu disco, e nesse meio-tempo nada sai daqui.
Leia primeiro o resumo. O tamanho da tela, a quantidade de quadros, quanto tempo a animação diz que dura e quanto ela toca de verdade. Esses dois últimos divergem mais do que as pessoas esperam, e o motivo está na seção seguinte.
Veja o que chama atenção. Cada linha ali é medida no seu arquivo: tempos que navegador nenhum vai respeitar, um bloco de repetição faltando, tabelas de cor que ninguém referencia, metadados maiores do que alguns quadros. Nada é um chute sobre o que você pretendia fazer.
Veja para onde foram os bytes. Cada byte do arquivo está em exatamente uma linha, e as linhas somam o arquivo. Se a maior parte não estiver em “pixels compactados”, o resto da tabela diz onde ela está.
Passe pelos quadros. Cada um mostra o tempo, o retângulo, o método de descarte e o tamanho dele. Alterne entre “a tela depois de cada quadro” e “só o que cada quadro guarda”: é no segundo que você vê se o arquivo está otimizado, porque um GIF bem feito guarda retângulos minúsculos e um mal feito guarda a imagem inteira toda vez.
Leve o relatório se precisar. A análise inteira em texto puro, para colar numa mensagem ou guardar ao lado do arquivo. Ele é montado na própria página a partir do que já está na sua tela.

A versão longa

O que tem de verdade dentro de um GIF Quadros, atrasos, métodos de descarte e tabelas de cor explicados, por que os navegadores recusam os atrasos mais rápidos, e como descobrir para onde foi mesmo o tamanho de um GIF.

Perguntas

O meu GIF é enviado para algum lugar?

Não. O arquivo é lido, descompactado e desenhado pelo seu próprio navegador, no seu próprio hardware. Esta ferramenta não tem lado servidor, e a Content-Security-Policy da página lista todo endereço que ela pode contatar: nenhum é nosso. Tire da tomada e ela continua analisando GIFs.

Por que meu GIF toca mais devagar do que os tempos dizem?

Porque todo navegador se recusa a respeitar um tempo abaixo de dois centésimos de segundo e segura o quadro por um décimo no lugar. A regra foi escrita dentro do Netscape em 1996, para os globos giratórios e as placas de “em construção” da época, e foi copiada para todo navegador desde então; ninguém nunca tirou.

Então um GIF cujos quadros dizem todos 0,01 s não toca a 100 quadros por segundo. Toca a 10, de cinco a dez vezes mais devagar do que o programa que o fez pretendia. Esta página mostra os dois números, o que o arquivo diz e o que ele vai fazer de verdade, e marca os quadros afetados. O conserto, no programa que escreveu o arquivo, é escrever 0,02 em vez de 0,01.

O que quer dizer “descarte”?

O que deixar na tela quando o tempo de um quadro acaba, e é o campo que decide se uma animação fica certa ou borra.

Deixar como está quer dizer que o próximo quadro pinta por cima deste, que é o que você quer quando os quadros são opacos e se cobrem. Voltar ao fundo limpa antes o retângulo do quadro, que é do que a transparência precisa: sem isso, as partes vazadas do próximo quadro mostram o anterior por baixo. Restaurar o que estava embaixo devolve o que havia ali antes deste quadro desenhar, que é como se guarda um objeto pequeno se mexendo sobre um fundo parado. E não especificado quer dizer que o arquivo não falou nada, e todo visualizador trata isso como “deixar como está”.

Por que o meu GIF é tão grande?

A tabela “Para onde foram os bytes” responde isso para o seu arquivo específico em vez de responder em geral, e só existem algumas respostas possíveis.

Se quase tudo estiver em pixels compactados, o arquivo é simplesmente muita imagem: o GIF guarda cada quadro como pixels inteiros, sem compensação de movimento e sem botão de qualidade, então o tamanho é aproximadamente a área vezes a quantidade de quadros. Menos quadros, um tamanho menor ou menos cores são as únicas alavancas.

Se uma fatia grande estiver em tabelas de cor, o arquivo está escrevendo uma paleta por quadro, a 768 bytes cada. Se uma fatia grande estiver em metadados, algum editor deixou um pacote XMP para trás, e ele pode sair sem encostar na imagem. E se todos os quadros cobrem a tela inteira, o codificador nunca descobriu qual parte mudou de verdade, e em qualquer coisa filmada ou gravada isso é quase o arquivo todo.

Qual é a diferença entre as duas visões de quadro?

A tela depois de cada quadro é o que um visualizador mostra naquele momento: este quadro desenhado por cima do que os anteriores deixaram. Só o que cada quadro guarda é o retângulo que o arquivo realmente tem para aquele quadro, sozinho, sem nada embaixo.

A segunda é a interessante. Um GIF pode guardar de um quadro só a parte da imagem que mudou, e é por isso que a gravação de tela de uma janela quase parada pode ser pequena. Se todo quadro do seu arquivo é a tela inteira, ninguém fez esse trabalho, e olhando a animação você não descobre: só olhando o que está guardado.

Diz que o meu arquivo tem um comentário ou XMP. O que é isso?

Texto que viaja junto com a imagem e que visualizador nenhum desenha. Um bloco de comentário costuma ser o nome do programa que escreveu o arquivo. Um pacote XMP é o XML que um editor de imagens escreve para registrar o que fez, e pode levar o histórico de edições, a versão do programa e às vezes o nome do autor.

Esta página imprime os dois por inteiro, porque a pergunta interessante sobre metadados é o que eles dizem, não o fato de existirem. São mostrados a você e a mais ninguém: nada neste repositório lê nada disso para alguém.

Ele abre um GIF quebrado?

Ele altera o meu arquivo?

É grátis, e preciso de conta?

Funciona offline?

Analisador de GIF — o que tem de verdade dentro de um GIF

Como dá para conferir a promessa de privacidade

Escolha um GIF

O que chama atenção

Para onde foram os bytes

As cores

A tabela global

O que mais tem aí dentro

Como analisar um GIF

A versão longa

Perguntas

Como dá para conferir a promessa de privacidade

Escolha um GIF

—

O que chama atenção

Para onde foram os bytes

Quadro a quadro

As cores

A tabela global

O que mais tem aí dentro

Como analisar um GIF

A versão longa

Também na caixa

Perguntas