Ir para o conteúdo
AZ Tools

Inspetor de estrutura GIF

Percorre um GIF como um decodificador precisa fazer: bloco a bloco, do cabeçalho de 13 bytes até o terminador 0x3B, sem pular nada no olho. O cabeçalho traz a versão (GIF87a não conhece extensão alguma; GIF89a é a que anima), a tela lógica sobre a qual os quadros são compostos, o índice da cor de fundo, o byte de proporção do pixel que nenhum navegador respeita há trinta anos, e se existe tabela de cores global, com quantas entradas e de quantos bits. Em seguida cada quadro é listado com os dois números que decidem como ele toca: seu atraso e seu método de descarte. Os atrasos são o motivo habitual de um GIF parecer lento, pois são guardados em centésimos de segundo e os navegadores trocam em silêncio qualquer valor abaixo de cerca de 20 ms por 100 ms; um arquivo escrito a 5 ms por quadro roda cinco vezes mais devagar do que o autor pretendia. Por isso os dois totais aparecem: o que os atrasos somam e o que você vai ver de fato. O descarte explica rastros e piscadas: restaurar o fundo apaga o retângulo do quadro antes do próximo, restaurar o anterior rebobina a área de desenho, e deixar como está é o que permite a um otimizador guardar apenas os pixels que mudaram. Essa otimização também aparece aqui: um quadro menor que a tela lógica é marcado junto com sua posição, sua tabela de cores local quando existe, sua marca de entrelaçamento e seu índice transparente. Como as cadeias de subblocos são seguidas com exatidão em vez de procuradas às cegas, o custo em bytes de cada quadro é exato, e a tabela os ordena, de modo que o quadro que fez o arquivo chegar a 20 MB fica no topo. O restante é dividido entre tabelas de cores, dados de imagem LZW e custo dos blocos, e todo bloco de extensão — controle gráfico, comentário, texto simples e aplicação, inclusive o contador de repetição NETSCAPE e qualquer um desconhecido — é listado com deslocamento, tamanho e texto. O que ele não faz é decodificar pixels: os fluxos LZW são medidos, nunca descomprimidos, então nada é dito sobre fidelidade de cor, pontilhado ou semelhança entre quadros. Um arquivo truncado, ou cujos tamanhos de bloco passem do fim, é recusado com um erro nomeado em vez de lido pela metade, porque dali em diante qualquer deslocamento seria chute.

Como usar

  1. Solte um .gif na caixa ou clique para escolher um. Os bytes são lidos na própria página; nada é enviado.
  2. Comece pela visão geral: versão do cabeçalho, tela lógica, número de quadros, a duração que um navegador realmente vai reproduzir e o comportamento da repetição.
  3. Se aparecer o aviso de reprodução, os atrasos estão abaixo do piso do navegador: suba para 20 ms ou mais, ou o arquivo sempre vai rodar mais devagar do que promete.
  4. Leve as dúvidas de tamanho para a tabela de quadros: a coluna de bytes e sua barra mostram quais custam mais, e um tamanho marcado com * indica que aquele quadro repinta só parte da área.
  5. Confira a lista de extensões atrás do bloco de repetição NETSCAPE, de comentários do codificador e de qualquer bloco de aplicação inesperado.

Perguntas frequentes

Por que meu GIF roda mais devagar do que os atrasos que defini?
Porque os navegadores recusam atrasos muito curtos. O atraso fica na extensão de controle gráfico de cada quadro, em centésimos de segundo, então o menor valor diferente de zero é 10 ms; mas Blink e WebKit trocam qualquer coisa abaixo de 11 ms por 100 ms, e o Gecko faz o mesmo abaixo de 20 ms. Um arquivo exportado a "50 fps" roda então a 10 fps, dez vezes mais devagar, e não existe marca que anule isso: o limite vem das páginas cheias de GIFs de um quadro usados como espaçadores, e todos os motores continuam aplicando. Esta ferramenta mostra os dois números, a soma dos atrasos e o tempo que o navegador vai levar, para separar um arquivo limitado de um realmente longo. Se você precisa de movimento rápido, a resposta é um codec de vídeo.
O que o contador de repetição significa de fato?
A repetição não está na especificação do GIF. É uma extensão de aplicação que a Netscape acrescentou em 1995: o identificador de 11 bytes NETSCAPE2.0 seguido de um subbloco com um contador de 16 bits. Zero quer dizer repetir para sempre, que é o que quase todo codificador grava. Um valor diferente de zero é o número de exibições extras depois da primeira, então 1 mostra a animação duas vezes no Chrome e no Firefox, embora alguns leitores antigos tratassem o número como o total. Se o bloco não existe, a animação toca exatamente uma vez e para no último quadro — surpresa comum depois que o arquivo passa por uma ferramenta que descarta extensões desconhecidas.
Por que meu GIF é tão grande?
Quase sempre porque cada quadro guarda a tela inteira em vez da parte que mudou. A coluna de bytes cobra de cada quadro tudo o que ele custa — sua extensão de controle gráfico, seu descritor, sua tabela de cores local e seus dados LZW —, então o ranking é exato, não uma estimativa. Três coisas dominam: reescritas de quadro inteiro, com cada quadro do tamanho da tela lógica; tabelas de cores locais, 768 bytes cada uma para 256 entradas, o que dá 45 KB em sessenta quadros antes de guardar um único pixel; e o próprio LZW, que vai mal com fotografia ou pontilhado e pode ficar maior que os índices crus. O resumo de bytes separa os três.
O que são métodos de descarte e por que meus quadros deixam fantasmas?
Um quadro de GIF é pintado sobre a área que o anterior deixou; o método de descarte diz o que acontece com ele antes do próximo ser desenhado. 0 (não especificado) e 1 (não descartar) mantêm o que está lá, e é isso que torna possíveis os quadros diferenciais: só os pixels alterados precisam ser guardados. 2 limpa o retângulo do quadro de volta para o fundo, o que você quer quando pixels transparentes não podem se acumular, e o que provoca um piscar quando a tela inteira é limpa toda vez. 3 restaura o que havia antes de o quadro ser desenhado; é caro e raramente implementado do mesmo jeito em todo lugar. Rastros e fantasmas quase sempre significam descarte 1 onde se queria 2, ou pixels transparentes desenhados sobre quadros que nunca foram limpos.
Por que as bordas transparentes ficam serrilhadas?
A transparência do GIF é um único índice da paleta, não um canal alfa. Um quadro pode indicar uma entrada como transparente, e todo pixel com aquele índice é pulado na composição; não há nada entre totalmente opaco e totalmente invisível. As bordas suavizadas de um PNG não têm para onde ir: os pixels semitransparentes acabam misturados ao fundo que o exportador supôs — o conhecido halo branco ou cinza — ou forçados ao índice transparente, deixando a escadinha. E custa uma cor: uma imagem com transparência tem 255 entradas úteis, não 256. Além disso o índice transparente é por quadro, então um decodificador só informa o do quadro atual.
Qual a diferença entre GIF87a e GIF89a, e o entrelaçamento ainda ajuda?
GIF87a é o formato original de 1987 e não tem nenhum bloco de extensão, ou seja, nada de atrasos, transparência, contador de repetição ou comentários. O GIF89a acrescentou o mecanismo de extensões, e tudo o que as pessoas consideram próprio do GIF mora ali. Os dois continuam sendo lidos em qualquer lugar, e é razoável um codificador gravar 87a quando nada específico do 89a é necessário, como costuma acontecer com uma imagem estática. O entrelaçamento é uma marca separada, por quadro: as linhas são guardadas em quatro passadas para que uma imagem baixada pela metade já mostre uma versão grosseira do desenho todo. Numa conexão moderna isso não rende nada e ainda aumenta um pouco o fluxo LZW ao quebrar a correlação entre linhas vizinhas, então um quadro entrelaçado perdido geralmente indica que o arquivo passou por uma ferramenta antiga.

Ferramentas relacionadas