Otimizar GIF

Remova a redundância entre os quadros de um GIF animado sem mudar o tamanho, a velocidade nem as cores.

1. 1

   Adicione o seu GIF

   Arraste um GIF animado para a área de envio ou clique para procurar. WebP animado e APNG também funcionam. O arquivo é lido no seu dispositivo e nunca enviado.

2. 2

   Deixe os padrões para uma passagem sem perdas

   A diferença entre quadros está ligada e só são removidos os duplicados idênticos byte a byte. Com estes ajustes nada muda na imagem: o arquivo simplesmente deixa de guardar o que já guardava.

3. 3

   Use um controle deslizante só se precisar de mais

   A tolerância de diferença perdoa pixels quase idênticos entre quadros. As sequências com perdas juntam pixels quase idênticos dentro de um quadro. Ambas trocam um pouco de precisão por tamanho e mostram exatamente quanto isso custa.

4. 4

   Leia o relatório e baixe

   O painel de resultado indica os quadros mantidos, a fração da tela que cada quadro guardado cobre e a duração de entrada e de saída. Toque em Baixar quando os números disserem o que você queria.

Quase todo GIF em circulação é maior do que precisa por um motivo que nada tem a ver com qualidade. O formato permite desde 1989 que um quadro cubra apenas o retângulo que mudou e marque o resto dos seus pixels como «o que já está na tela aqui continua correto», e a maioria dos codificadores nunca usa nenhuma das duas coisas. Assim, uma gravação de vinte quadros de uma página estática com um cursor em movimento guarda essa página estática vinte vezes. Otimizar remove a repetição e não toca em mais nada.

Guarde só os pixels que mudam entre quadros, apague os quadros que se repetem somando o tempo deles ao que fica, e use uma tabela de cores em toda a animação.

Lê GIF, WebP animado e APNG. Escreve um GIF89a padrão com as mesmas dimensões, a mesma duração e — quando a paleta cabe — as mesmas cores.

Quanto isso vale, medido

• Diferença entre quadros. Na nossa animação de referência, 196.091 bytes guardados inteiros viram 48.131 guardados como diferenças. Na versão de cem quadros, 4.776.638 viram 1.172.755. Ambos são 4,07x e ambos são exatos em cor.
• Quadros duplicados. Uma animação de doze quadros com quatro desenhos distintos sai com quatro quadros carregando o tempo dos doze. Uma de seis quadros de um único desenho sai com um que segura os 600 ms.
• Recorte de um quadro transparente. Um adesivo cujo conteúdo opaco ocupa um quinto da tela é guardado como um quinto da tela: 191 bytes a partir de 19.473, com a transparência intacta.
• Nada que você não pediu. Sem redimensionar, sem baixar a taxa de quadros, sem reduzir a paleta a menos que você mova um controle. Se recodificar não vencer o seu arquivo, você recebe o seu de volta e é avisado.

Um GIF não é uma pilha de imagens. É uma tela mais uma lista de instruções, e cada instrução pode pintar um retângulo em qualquer lugar dessa tela, em qualquer tamanho, com quaisquer pixels marcados como transparentes para que apareça o que está por baixo. Um quadro que muda uma área de 30 pixels pode ser guardado como uma área de 30 pixels. Tão poucos arquivos fazem isso porque escrevê-lo é bem mais difícil: o codificador precisa manter um modelo do que um decodificador estaria mostrando e comparar com isso, e não com o quadro de origem anterior.

O que acontece com cada quadro

• Compor. Cada quadro é desenhado sobre uma tela do tamanho lógico da animação, respeitando o seu deslocamento, o seu método de descarte e a sua transparência, de modo que o que se compara é a imagem que um espectador realmente veria.
• Varrer uma vez. Uma única passagem responde a tudo de que a codificação precisa: quais quadros são repetições, se há transparência em algum lugar, quantas cores distintas existem e a amostra a partir da qual a paleta é construída.
• Mapear para uma tabela compartilhada. Se as cores da origem cabem numa tabela, essa lista exata vira a paleta. Se não cabem, uma é derivada sobre toda a animação e não a partir do primeiro quadro, para que as cores não mudem durante a reprodução.
• Diferenciar e depois comprimir sequências. Cada quadro é comparado com um modelo da tela decodificada, reduzido ao retângulo que mudou, e os pixels sem mudança ali dentro são marcados como transparentes. Só então a passagem com perdas roda, para que ela nunca danifique a diferença.

A invariante que quase toda implementação erra

Quando um quadro duplicado é removido, o tempo dele precisa ir para algum lugar. Apague dez quadros de uma animação de vinte a 100 ms e esqueça de somar os tempos, e sobram dez quadros de 100 ms: uma animação de dois segundos que roda em um, no dobro da velocidade. A saída é um GIF válido. Nada falha. Só não é mais a animação que entrou. Aqui a duração de entrada e a de saída são comparadas a cada execução e uma divergência é lançada como erro, não devolvida como arquivo menor.

Remover quadros por conteúdo é diferente de descartar um a cada dois, e essa diferença é o ponto todo. Descartar um a cada N é cego: tira quadros que mostravam algo novo junto com os que não mostravam, e o resultado engasga na hora. Remover duplicados só apaga quadros que um espectador não teria distinguido do anterior e soma o tempo deles. Se o que você quer é menos quadros por segundo, essa alavanca está no compressor, junto das outras decisões de qualidade.

Dois modos e o limiar que os separa

• Só idênticos. Repetições byte a byte e nada mais. É o padrão porque não pode mudar o que ninguém vê: os quadros removidos já estavam na tela, pixel por pixel.
• Quase idênticos. Um limiar de semelhança de 80% a 100%. A 98%, um quadro que coincide com pelo menos 98% do último mantido é tratado como repetição. Útil em material com ruído leve.
• Desligado. Todos os quadros são mantidos. Vale escolher quando a contagem de quadros importa: alguns editores e fluxos de sprites os indexam por número.

Por que a comparação é com o último quadro mantido

Compare cada quadro com o imediatamente anterior e um esmaecimento lento passa do limiar em cada passo, então toda a animação encolhe até o primeiro quadro enquanto cada comparação isolada parecia razoável. Comparar com o último quadro MANTIDO limita o erro: seja qual for o limiar, é o máximo que se pode mostrar a alguém que a gravação não continha, e não se acumula. São menos quadros removidos em material com deriva, e é a troca certa, porque a falha evitada é silenciosa.

Todos os números abaixo vêm do conjunto de testes desta ferramenta, sobre arquivos gerados por um script em vez de guardados como binários misteriosos. Cada saída é relida por três implementações independentes: libvips para a animação renderizada, gifsicle para a estrutura dos quadros e um leitor estrutural escrito para os testes que percorre os blocos do arquivo e nunca roda a descompressão.

As alavancas, pelo que valem

• Diferença entre quadros 4,07x na animação de referência tanto com 20 quanto com 100 quadros, com um erro médio de cor medido de 0,000 em 255.
• Remoção de duplicados De 12 quadros para 4, e de 6 para 1, nos dois arquivos dedicados — com 1.200 ms de entrada e 1.200 de saída, e 600 ms de entrada e 600 de saída.
• Tolerância de diferença em 40 De 1.172.755 bytes para 487.196 na referência de cem quadros. Mais 2,41x sobre a passagem sem perdas.
• Sequências com perdas em 60 De 1.172.755 bytes para 478.644 no mesmo arquivo. Comparável ao outro controle e visível de outra forma: dentro de um quadro em vez de entre quadros.
• Velocidade Cem quadros em 480x270, decodificados, varridos, diferenciados e escritos, em 252 a 380 ms no dispositivo de referência.

Contra o gifsicle, o motor da maioria dos otimizadores on-line

Os retângulos de quadro que esta ferramenta produz são idênticos aos do gifsicle -O3 em todos os arquivos medidos — mesmos deslocamentos, mesmos tamanhos, mesmas tabelas de cores — o que diz que as decisões estruturais coincidem. No tamanho total igualamos ou superamos o gifsicle -O3 em oito de dez casos e perdemos em dois, por 0,03% e 3,1%, inteiramente dentro da carga comprimida e não da estrutura. Duas coisas fazemos que ele não faz: remover quadros quase idênticos e avisar quando recodificar aumentou o arquivo.

São dois trabalhos diferentes e escolher o errado gasta qualidade que não precisava ser gasta. Otimizar remove redundância: o arquivo diminui e a animação não muda, então não há motivo para não fazer. Comprimir remove informação: menos pixels, menos cores, menos quadros por segundo, até chegar a um tamanho que você nomeia. Comece aqui. Se o resultado ainda for grande demais, o compressor continua de onde isto parou.

Uma lista curta de decisões

• Comece sempre pelo otimizador. Não custa nada visualmente e muitas vezes basta. Não faz sentido jogar cores fora antes de parar de guardar pixels duas vezes.
• Use o compressor quando o requisito for um número. «Abaixo de 8 MB para o Discord», «abaixo de 256 KB para um emoji». Ele busca em resolução, paleta e taxa de quadros até acertar.
• Use o redimensionador quando as dimensões estiverem erradas. Esta ferramenta nunca as muda. Se a animação tem 1920 de largura e a coluna tem 700, isso é um redimensionamento, e fazê-lo antes barateia todo o resto.
• Volte aqui depois. Otimizar a saída de um redimensionamento ou de uma compressão costuma achar mais, porque essas ferramentas reconstroem os quadros e esta é a que tira a repetição deles.

Compressor de GIF · Redimensionar GIF

Os ajustes padrão foram escolhidos para que ninguém precise pensar neles: diferença entre quadros ligada, duplicados removidos só quando idênticos byte a byte, os dois controles com perdas em zero, sem pontilhado. Essa combinação não pode mudar o que ninguém vê, e é por isso que é o padrão: um otimizador que alterasse a imagem em silêncio seria um compressor com um nome enganoso.

Por material

• Gravações de tela e demonstrações de interface. O melhor caso possível. O fundo é estático, as diferenças são minúsculas, e as pausas produzem quadros idênticos que não custam nada para remover. Deixe os padrões.
• Material vindo de vídeo. Nada é idêntico byte a byte por causa do ruído de compressão, então mude a remoção de duplicados para quase idênticos a 98% e suba a tolerância de diferença.
• Adesivos e logotipos com fundo transparente. A diferença entre quadros não fica disponível, mas os quadros ainda são recortados ao seu conteúdo opaco, o que aqui costuma valer mais.
• GIFs fotográficos ou muito pontilhados. Pode não haver nada a remover, e a ferramenta vai dizer isso em vez de devolver um arquivo maior. Reduza o número de cores, ou use o compressor.

A lista de entrada é fechada e é aplicada na própria caixa de diálogo de arquivos, não no motor, então um arquivo que esta ferramenta não consegue abrir é recusado em milissegundos com um caminho para a ferramenta que consegue — em vez de ser aceito e falhar depois atrás de um indicador de carregamento.

• GIF de entrada. Animado ou de um único quadro, entrelaçado ou não, com paleta global ou com uma paleta local diferente em cada quadro. Quadros parciais com deslocamento são compostos sobre a tela inteira antes de qualquer comparação.
• WebP animado e APNG de entrada. Ambos são lidos pelos nossos próprios demultiplexadores em todos os navegadores, então a contagem de quadros e o ritmo são idênticos em toda parte. Ambos carregam muito mais de 256 cores.
• GIF de saída, sempre. Um GIF89a padrão com uma tabela de cores global, tempos por quadro, quadros parciais, métodos de descarte e a extensão de repetição Netscape.
• Qualquer outra coisa é recusada com um caminho. Um vídeo vai para Vídeo para GIF; uma imagem parada, para o Criador de GIF.

O que a ferramenta lê

O GIF é decodificado nativamente onde o navegador tem um decodificador e pelo nosso próprio leitor em todo o resto, então uma animação abre igual em toda parte em vez de chegar como o seu primeiro quadro sem aviso nenhum. WebP animado e APNG passam sempre pelo nosso leitor, o que mantém a contagem de quadros e o ritmo idênticos entre motores. O que um arquivo alega ser pelo nome é ignorado: quem decide são os primeiros dezesseis bytes.

Limites de tamanho e de lote

• Gratuito. Um arquivo de até 50 MB e até 300 quadros. Todas as alavancas estruturais estão incluídas, porque são o que a ferramenta é. A tabela de cores é limitada a 128 entradas.
• Pro. Até 50 arquivos de uma vez, baixados num único ZIP, sem limite de tamanho nem de quadros além do que o seu dispositivo aguenta, e a tabela completa de 256 cores.
• Sem limite de dimensões em nenhum plano. O otimizador nunca muda as dimensões, então um teto sobre elas limitaria algo que não acontece. Os dois planos devolvem a animação exatamente no tamanho em que ela chegou.
• O limite que os dois planos compartilham. Cada quadro é expandido para cor completa enquanto é trabalhado, então um orçamento de memória limita o trabalho antes de ele começar em vez de deixar a aba parar de responder.

Nada é enviado. O arquivo é decodificado quadro a quadro na sua máquina, varrido uma vez à procura de repetições, transparência e contagem de cores, mapeado para uma única paleta compartilhada, diferenciado contra um modelo do que um decodificador estaria mostrando, e escrito como um GIF89a padrão. Tudo roda numa thread em segundo plano para a página continuar desenhando, e o mapeamento de paleta — a parte por pixel, a cara — roda no seu hardware gráfico quando ele está disponível.

Por que o mesmo arquivo é otimizado igual todas as vezes

• Um quantizador determinístico. Corte pela mediana, não o quantizador neural aleatório que a maioria das bibliotecas usa — e nenhum quantizador quando as cores da origem cabem. A mesma entrada com os mesmos ajustes sempre produz os mesmos bytes.
• Resultados idênticos em todos os caminhos. Os caminhos acelerado por hardware e por processador precisam produzir os mesmos bytes, não apenas parecidos. Um caminho que escolhesse outra entrada da paleta apareceria como cintilação de cor entre os quadros.
• Verificado por implementações sem código em comum. A animação renderizada é lida pelo libvips, a estrutura dos quadros pelo gifsicle e os blocos do arquivo por um leitor escrito para os testes. Um arquivo que o nosso próprio código escreve e lê não prova nada.
• Otimizar duas vezes não muda nada. Rodar a ferramenta sobre a própria saída devolve o mesmo arquivo e o declara já otimizado, que é a propriedade que diz que a primeira passagem terminou o serviço.

O mapeamento de paleta é acelerado por hardware onde o seu dispositivo permite, e os caminhos acelerado e de reserva são verificados como produzindo bytes idênticos. A estrutura dos quadros é conferida com o gifsicle e a animação renderizada com o libvips, e nenhum dos dois compartilha código com esta ferramenta. Medido no dispositivo de referência: 100 quadros em 480x270 otimizados em 252 ms, 4,07x menores, com um erro médio de cor de 0,000 em 255. Tudo roda no seu dispositivo, não nos nossos servidores.

• Compressor de GIF
• Redimensionar GIF
• Criador de GIF
• Vídeo para GIF
• GIF para MP4
• Editor de GIF