Porque é que um GIF de três segundos pesa mais do que o vídeo de onde saiu

Um formato de 1989 que nunca aprendeu o movimento

A especificação GIF89a descreve uma animação como uma sequência de imagens com um atraso entre elas. É todo o modelo. Não há noção de cena que persista, nem vetor que diga ao descodificador que este bloco de píxeis é o do fotograma anterior deslocado onze píxeis para a esquerda. Os codecs de vídeo modernos gastam quase toda a sua esperteza nessa ideia exata, e é daí que vem quase toda a sua compressão: num plano de alguém a falar, a parede atrás da cabeça é transmitida uma vez e depois referenciada durante trezentos fotogramas. Um GIF não tem forma de referenciar coisa nenhuma.

Há uma exceção rudimentar, e vale a pena conhecê-la porque explica porque é que alguns GIF se portam muito melhor do que a aritmética prevê. Um fotograma pode ser escrito como um retângulo mais pequeno colocado num desvio, e os píxeis que não mudaram desde o fotograma anterior podem ser marcados transparentes em vez de guardados. O FFmpeg — o motor que esta ferramenta usa — ativa os dois por omissão. Numa gravação de ecrã em que um cursor atravessa uma janela parada, isto é enorme: quase todo o fotograma se desfaz em nada. Em imagens de câmara, onde o ruído do sensor faz com que praticamente cada píxel difira ligeiramente do anterior, não poupa quase nada. Só essa distinção explica porque é que as mesmas definições produzem um GIF de 300 kB a partir de uma captura de ecrã e um de 5 MB a partir de um clipe filmado à mão.

A aritmética, e onde vive o único número mole

Bytes ≈ largura × altura × fotogramas × b ÷ 8. Tudo o que está à direita é exato exceto b, o número de bits que cada píxel custa depois de o LZW ter feito o seu trabalho. Antes de comprimir, cada píxel é um índice numa tabela de até 256 cores, portanto parte de 8 bits. Em conteúdo fotográfico pontilhado, o LZW costuma baixar isso para algo entre 2 e 5, e por isso o honesto é tomar b = 3 para uma primeira estimativa e aceitar que a resposta é boa dentro de um fator de dois. Soa desleixado até se reparar que é o mesmo fator de dois que sairia de adivinhar um débito de vídeo, e que chega para saber se está a uma definição do seu limite ou a quatro.

Uma coisa que a ferramenta não faz é medir as cores do seu clipe. Uma cadeia GIF de qualidade faz duas passagens: uma para construir uma paleta a partir dos píxeis realmente presentes e outra para projetar os fotogramas sobre ela. Esta ferramenta faz uma só passagem, por isso as 256 posições são preenchidas a partir de uma tabela genérica e não das suas imagens. A consequência visível são bandas nos céus, nos gradientes e nos tons de pele, e uma ligeira aspereza nas zonas escuras. A consequência invisível é no tamanho, e corta nos dois sentidos: uma paleta genérica pontilha mais, e o pontilhado acrescenta ruído de alta frequência que o LZW detesta, o que empurra b para cima. Se o seu clipe tem poucas cores à partida — uma animação de logótipo, um gráfico, uma janela de terminal — nada disto morde e o ficheiro sairá muito abaixo da estimativa.

A caixa da largura não é uma caixa do tamanho

Escreve uma largura; a ferramenta calcula a altura a partir da forma do clipe. Para um clipe horizontal 16:9, 480 dá-lhe 480 × 270: 129 600 píxeis por fotograma. Para um vídeo de telemóvel filmado na vertical, esse mesmo 480 dá-lhe 480 × 853, ou seja 409 440 píxeis por fotograma: mais do triplo, com o mesmo número escrito na mesma caixa. É a razão mais frequente para um GIF sair inesperadamente enorme, e é invisível na interface, que só mostra uma das duas dimensões.

A correção cabe numa linha de aritmética. Se quer que um clipe vertical pese o que pesa um horizontal de 480 de largura, peça 270 de largura: 270 × 480 são exatamente 129 600 píxeis outra vez. Mais em geral, decida um orçamento de píxeis por fotograma em vez de uma largura. Algo entre 120 000 e 150 000 píxeis por fotograma fica confortável numa janela de conversa seja qual for a forma — isso é 480 × 270 horizontal, 270 × 480 vertical ou 360 × 360 quadrado — e depois só lhe sobram a cadência e a duração para discutir.

A cadência que pediu provavelmente não é a que obteve

Isto é arqueologia de formato pura e apanha toda a gente. A especificação GIF89a guarda a pausa antes do fotograma seguinte em centésimos de segundo — o campo, nas suas próprias palavras, «indica o número de centésimos (1/100) de segundo a esperar». Não há unidade mais fina nem fracionária. Portanto uma cadência só é reproduzível se 100 se dividir exatamente por ela. Dentro do intervalo que esta ferramenta oferece, isso quer dizer 2, 4, 5, 10, 20 e 25 fotogramas por segundo, e mais nada.

O valor por omissão de 12 não é um deles. Um doze avos de segundo são 8,33 centésimos, e o ficheiro só pode guardar 8 ou 9 — ou seja 12,5 ou 11,1 fotogramas por segundo na reprodução, pelo que o seu clipe de oito segundos dura 7,68 ou 8,64 segundos. Ninguém que veja um GIF de gatos vai reparar. Alguém que veja uma contagem decrescente, um metrónomo, um cronómetro de volta ou uma gravação de ecrã em que demonstra um erro de temporização, de certeza que sim. Trinta é pior: um trinta avos de segundo são 3,33 centésimos, o ficheiro guarda 3, e a reprodução sai a 33,3 fotogramas por segundo — onze por cento depressa de mais. Se o tempo importa, escolha 10, 20 ou 25 e o ficheiro toca à cadência que pediu.

Quando a resposta certa não é um GIF

O tamanho do vídeo obedece a outra fórmula, muito mais amável: bytes = débito × segundos ÷ 8. Oito segundos a 800 kbit/s são 800 kB, e 800 kbit/s compram um clipe perfeitamente visível em resolução completa e a trinta fotogramas por segundo. É quase seis vezes menos do que o GIF construído com esses mesmos oito segundos a um quinto da resolução e a um terço da cadência — e o vídeo tem som, se o quiser. Todas as aplicações de mensagens, todos os fóruns modernos, todos os gestores de incidências e todas as redes sociais reproduzem MP4 e WebM em linha e repetem-nos a pedido. O ciclo em reprodução automática a que hoje se chama «um GIF» na web é, nove em cada dez vezes, um MP4 mudo.

Guarde então o GIF para os casos em que mais nada é aceite, e há-os a sério: um wiki ou um gestor de incidências que só aceita imagens em anexo, um cliente de correio que não incorpora vídeo, um fórum antigo cujo editor tem um botão de imagem e mais nada, um README renderizado algures que remove as etiquetas de vídeo. Nesses sítios o GIF não é uma escolha nostálgica: é a única imagem em movimento que sobrevive à viagem. Em todos os outros, converter para GIF é pagar cinco a dez vezes os bytes para perder o som, a maioria das cores e metade dos fotogramas.

Duas pequenas coisas sobre esta ferramenta em concreto

Começa sempre no segundo zero. A caixa da duração é um teto sobre a saída, não uma janela que possa deslizar: os oito segundos que obtém são os oito primeiros do ficheiro. Se o momento que quer está aos 0:42, corte o clipe primeiro com a ferramenta de corte e dê-lhe o pedaço cortado. Não é uma limitação que se contorne com uma duração maior: pôr o máximo em 30 dá-lhe os primeiros trinta segundos e um GIF que ninguém consegue publicar em lado nenhum.

E o tamanho que mostra é medido em unidades de 1 048 576 bytes chamando-lhes MB. É um mebibyte com o rótulo de um megabyte, um desleixo muito antigo e muito difundido. Aqui importa num único ponto: um limite expresso como 10 000 000 bytes são 9,54 dos «MB» da ferramenta, por isso um ficheiro que a ferramenta anuncia orgulhosa como 10,0 MB ultrapassa esse limite em quase meio megabyte. Quando apontar a um teto rígido, aponte cinco por cento abaixo e deixe de pensar nas unidades.

Perguntas frequentes

É possível meter mais de 256 cores num GIF?

No conjunto do ficheiro, sim; dentro de um fotograma, não. A especificação permite que cada bloco de imagem carregue a sua própria tabela de cores local, por isso uma animação de vinte fotogramas poderia em princípio usar vinte paletas e tocar vários milhares de cores distintas no total. Mas cada fotograma continua limitado a 256, e uma tabela local custa até 768 bytes de cada vez que muda. Na prática isto rende muito pouco em vídeo, porque o olho compara fotogramas vizinhos e uma paleta que muda entre eles produz cintilação visível. O ganho maior ao alcance de um codificador GIF não são mais cores mas cores melhor escolhidas: uma paleta medida nas suas imagens reais em vez de uma tabela genérica.

O meu GIF continua pesado de mais e já reduzi a largura. E agora?

Corte a seguir a duração e depois a cadência, por esta ordem. Duração e cadência são ambas lineares em relação ao número de fotogramas, por isso rendem o mesmo por unidade — mas um clipe mais curto é quase sempre um clipe melhor, ao passo que baixar a cadência é uma degradação visível abaixo de cerca de 8 fotogramas por segundo, onde o movimento começa a ler-se como uma apresentação de diapositivos. Dois segundos a 10 fotogramas por segundo são vinte fotogramas, e vinte fotogramas de 320 × 180 a 3 bits são 432 kB. Se nem assim couber, a conclusão honesta é que o conteúdo não comprime: veja se são imagens de câmara com fundo em movimento e, se forem, recorte justo ao que interessa ou aceite que isto pede um vídeo.

O GIF fica com o som?

Não, e nunca poderá: o formato não tem faixa de áudio nem sítio onde pôr uma. Vale a pena dizê-lo em voz alta porque é uma falha silenciosa — nada o avisa, a conversão funciona, e descobre-o ao publicar um clipe cujo sentido inteiro era uma fala. Se era o som que queria partilhar, a resposta é um vídeo, ou o áudio por si só: este sítio tem uma ferramenta que extrai a banda sonora de um ficheiro de vídeo em MP3, AAC ou WAV sem tocar na imagem.

Porque é que o meu GIF fica granulado nas zonas escuras se o vídeo estava bem?

Porque 256 cores têm de cobrir todo o percurso do preto ao branco, e numa cena escura a maior parte da sua imagem aperta-se num punhado delas. O codificador tapa a falha pontilhando — espalhando píxeis de duas cores disponíveis para fingir uma terceira — e em zonas escuras planas esse espalhamento lê-se como grão. Também lhe custa tamanho, porque o pontilhado é ruído de alta frequência e o ruído de alta frequência é exatamente o que o LZW não sabe comprimir. Duas coisas ajudam: aclarar ou recortar o clipe antes de converter para que menos parte viva na zona esmagada, e preferir conteúdo de cores planas e bem distintas. Nada corrige isto por completo dentro do formato, o que é mais uma razão para a resposta ser muitas vezes um vídeo.

O vídeo sai do meu computador enquanto isto corre?

Não. A conversão corre na página, numa compilação do FFmpeg para WebAssembly, e o próprio motor é servido a partir deste sítio e não de uma rede de terceiros — pelo que nem sequer o descarregamento único do motor entrega o seu endereço a alguém. Há uma consequência visível que deve esperar: a primeira conversão de uma sessão descarrega cerca de 32 MB de motor e demora um bocado, e todas as seguintes arrancam de imediato. E há um teste que resolve a questão sem ter de acreditar em nós: carregue a página, desligue a rede e converta um clipe. Se continuar a funcionar, nada foi enviado.