GIF

O Graphics Interchange Format (GIF; GHIF ou JIF, veja a pronúncia) é um formato de imagem bitmap que foi desenvolvido por uma equipe do provedor de serviços online CompuServe liderado por Cientista da computação americano Steve Wilhite e lançado em 15 de junho de 1987. É amplamente utilizado na World Wide Web devido ao seu amplo suporte e portabilidade entre aplicativos e sistemas operacionais.

O formato suporta até 8 bits por pixel para cada imagem, permitindo que uma única imagem faça referência à sua própria paleta de até 256 cores diferentes escolhidas no espaço de cores RGB de 24 bits. Ele também suporta animações e permite uma paleta separada de até 256 cores para cada quadro. Essas limitações de paleta tornam o GIF menos adequado para reproduzir fotografias coloridas e outras imagens com gradientes de cores, mas adequado para imagens mais simples, como gráficos ou logotipos com áreas de cores sólidas.

As imagens GIF são compactadas usando a técnica de compactação de dados sem perdas Lempel–Ziv–Welch (LZW) para reduzir o tamanho do arquivo sem degradar a qualidade visual.

História

A CompuServe introduziu o GIF em 15 de junho de 1987 para fornecer um formato de imagem colorida para suas áreas de download de arquivos. Isso substituiu o formato de codificação de comprimento de execução anterior, que era apenas em preto e branco. O GIF tornou-se popular porque usava a compactação de dados Lempel-Ziv-Welch. Como isso era mais eficiente do que a codificação run-length usada por PCX e MacPaint, imagens bastante grandes podiam ser baixadas razoavelmente rapidamente, mesmo com modems lentos.

A versão original do GIF chamava-se 87a. Esta versão já suportava várias imagens em um stream.

Em 1989, a CompuServe lançou uma versão melhorada, chamada 89a, Esta versão adicionou:

• suporte para atrasos de animação
• cores de fundo transparentes
• armazenamento de metadados específicos do aplicativo
• permitindo etiquetas de texto como texto (não incorporando-os nos dados gráficos). Como há pouco controle sobre fontes de exibição, no entanto, este recurso raramente é usado.

As duas versões podem ser distinguidas observando os primeiros seis bytes do arquivo (o "número mágico" ou assinatura), que, quando interpretado como ASCII, lê-se "GIF87a" ou "GIF89a", respectivamente.

A CompuServe incentivou a adoção do GIF fornecendo utilitários de conversão para download para muitos computadores. Em dezembro de 1987, por exemplo, um usuário do Apple IIGS podia ver imagens criadas em um Atari ST ou Commodore 64. O GIF foi um dos dois primeiros formatos de imagem comumente usados em sites da Web, sendo o outro o XBM em preto e branco.

Em setembro de 1995, o Netscape Navigator 2.0 adicionou a capacidade de loop de GIFs animados.

Embora o GIF tenha sido desenvolvido pela CompuServe, ele usou o algoritmo de compactação de dados sem perdas Lempel–Ziv–Welch (LZW) patenteado pela Unisys em 1985. A controvérsia sobre o acordo de licenciamento entre a Unisys e a CompuServe em 1994 estimulou o desenvolvimento do Portable Network Graphics (PNG) padrão. Em 2004, todas as patentes relacionadas à compressão proprietária usada para GIF expiraram.

O recurso de armazenar várias imagens em um arquivo, acompanhadas de dados de controle, é amplamente utilizado na Web para produzir animações simples.

O recurso de entrelaçamento opcional, que armazena linhas de varredura de imagem fora de ordem de forma que mesmo uma imagem parcialmente baixada seja reconhecível, também ajudou a popularidade do GIF, pois um usuário poderia interromper o download se não fosse o que foi exigido.

Em maio de 2015, o Facebook adicionou suporte para GIF. Em janeiro de 2018, o Instagram também adicionou adesivos GIF ao modo história.

Terminologia

Como substantivo, a palavra GIF é encontrada nas edições mais recentes de muitos dicionários. Em 2012, a ala americana da Oxford University Press reconheceu GIF como um verbo também, significando "criar um arquivo GIF", como em "GIFing foi o perfeito meio para compartilhar cenas dos Jogos Olímpicos de Verão". Os lexicógrafos da imprensa votaram nela a palavra do ano, dizendo que os GIFs evoluíram para "uma ferramenta com aplicações sérias, incluindo pesquisa e jornalismo".

Pronúncia

Uma imagem humorística anunciando o lançamento de uma conta Tumblr para a Casa Branca sugere pronunciá-la GIF com um duro g.

A pronúncia da primeira letra de GIF é contestada desde a década de 1990. As pronúncias mais comuns em inglês são (com um g suave como em gin) e (com um g forte como em gift), diferindo no fonema representado pela letra G. Os criadores do formato pronunciaram o acrônimo GIF como com um g suave, com Wilhite afirmando que pretendia que a pronúncia ecoasse deliberadamente a marca americana de manteiga de amendoim Jif, e os funcionários da CompuServe costumavam brincar "desenvolvedores exigentes escolhem GIF', uma paródia dos comerciais de televisão de Jif. No entanto, a palavra é amplamente pronunciada com um g forte, e as pesquisas geralmente mostram que essa pronúncia g forte é mais prevalente.

Dictionary.com cita ambas as pronúncias, indicando como a pronúncia principal, enquanto o Cambridge Dictionary of American English oferece apenas a pronúncia g difícil. Merriam-Webster's Collegiate Dictionary e Oxford Dictionaries citam ambas as pronúncias, mas coloque o g difícil primeiro:. O New Oxford American Dictionary deu apenas em sua segunda edição, mas o atualizou na terceira edição.

O desacordo sobre a pronúncia levou a um acalorado debate na Internet. Por ocasião de receber um prêmio pelo conjunto de sua obra na cerimônia do Webby Awards de 2013, Wilhite rejeitou publicamente a pronúncia g difícil; seu discurso gerou mais de 17.000 postagens no Twitter e dezenas de artigos de notícias. A Casa Branca e o programa de TV Jeopardy! também entraram no debate em 2013. Em fevereiro de 2020, The J.M. Smucker Company, proprietários da marca Jif, fez parceria com o banco de dados de imagens animadas e o mecanismo de busca Giphy para lançar uma edição limitada "Jif vs. GIF" (hashtagged como #JIFvsGIF) pote de manteiga de amendoim que tinha um rótulo declarando humoristicamente a pronúncia soft-g para se referir exclusivamente à manteiga de amendoim e GIF para ser pronunciado exclusivamente com a pronúncia g difícil.

Uso

GIFs são adequados para arte de linhas nítidas com um número limitado de cores, como logotipos. Isso aproveita a compactação sem perdas do formato, que favorece áreas planas de cor uniforme com bordas bem definidas. Eles também podem ser usados para armazenar dados de sprites de baixa cor para jogos. Os GIFs podem ser usados para pequenas animações e videoclipes de baixa resolução, ou como reações em mensagens online usadas para transmitir emoções e sentimentos em vez de usar palavras. Eles são populares em plataformas de mídia social como Tumblr, Facebook e Twitter.

Formato de arquivo

Conceitualmente, um arquivo GIF descreve uma área gráfica de tamanho fixo (a "tela lógica") preenchida com zero ou mais "imagens". Muitos arquivos GIF possuem uma única imagem que preenche toda a tela lógica. Outros dividem a tela lógica em sub-imagens separadas. As imagens também podem funcionar como quadros de animação em um arquivo GIF animado, mas, novamente, não precisam preencher toda a tela lógica.

Arquivos GIF começam com um cabeçalho de tamanho fixo ("GIF87a" ou "GIF89a") fornecendo a versão, seguido por um descritor lógico de tela de comprimento fixo fornecendo as dimensões em pixels e outras características da tela lógica. O descritor de tela também pode especificar a presença e o tamanho de uma tabela de cores global (GCT), que segue a seguir, se presente.

Depois disso, o arquivo é dividido em segmentos, cada um introduzido por uma sentinela de 1 byte:

• Uma imagem (introduzida por 0x2C, uma vírgula ASCII ',')
• Um bloco de extensão (introduzido por 0x21, um ponto de exclamação ASCII '!')
• O reboque (um único byte de valor 0x3B, um ponto-e-vírgula ASCII ';'), que deve ser o último byte do arquivo.

Uma imagem começa com um descritor de imagem de comprimento fixo, que pode especificar a presença e o tamanho de uma tabela de cores local (que segue a seguir, se presente). Os dados da imagem são os seguintes: um byte dando a largura em bits dos símbolos não codificados (que deve ter pelo menos 2 bits de largura, mesmo para imagens bicolores), seguido por uma lista encadeada de sub-blocos contendo os dados codificados em LZW.

Blocos de extensão (blocos que "estendem" a definição 87a por meio de um mecanismo já definido na especificação 87a) consistem na sentinela, um byte adicional especificando o tipo de extensão e uma lista vinculada de sub- blocos com os dados de extensão. Os blocos de extensão que modificam uma imagem (como a Extensão de controle gráfico que especifica o tempo de atraso opcional da animação e a cor de fundo transparente opcional) devem preceder imediatamente o segmento com a imagem a que se referem.

As listas encadeadas usadas pelos dados de imagem e os blocos de extensão consistem em séries de sub-blocos, cada sub-bloco começando com um byte dando o número de bytes de dados subseqüentes no sub-bloco (1 a 255). A série de sub-blocos é terminada por um sub-bloco vazio (um byte 0).

Esta estrutura permite que o arquivo seja analisado mesmo que nem todas as partes sejam compreendidas. Um GIF marcado como 87a pode conter blocos de extensão; a intenção é que um decodificador possa ler e exibir o arquivo sem os recursos abordados nas extensões que ele não entende.

Todos os detalhes do formato de arquivo são abordados na especificação GIF.

Paletas

Um exemplo de uma imagem GIF salva com uma paleta web-safe e dithered usando o método Floyd-Steinberg. Devido ao número reduzido de cores na imagem, há problemas de exibição.

O GIF é baseado em paleta: as cores utilizadas em uma imagem (um quadro) no arquivo têm seus valores RGB definidos em uma tabela de paletas que pode conter até 256 entradas, e os dados da imagem referem-se às cores por seus índices (0–255) na tabela de paletas. As definições de cores na paleta podem ser desenhadas a partir de um espaço de cores de milhões de tons (2²⁴ tons, 8 bits para cada primário), mas o número máximo de cores que um quadro pode usar é 256. Isso A limitação parecia razoável quando o GIF foi desenvolvido porque poucas pessoas podiam pagar pelo hardware para exibir mais cores simultaneamente. Gráficos simples, desenhos de linha, desenhos animados e fotografias em escala de cinza geralmente precisam de menos de 256 cores.

Cada quadro pode designar um índice como uma "cor de fundo transparente": qualquer pixel atribuído a este índice assume a cor do pixel na mesma posição do fundo, que pode ter sido determinado por um anterior quadro de animação.

Muitas técnicas, chamadas coletivamente de pontilhamento, foram desenvolvidas para aproximar uma gama mais ampla de cores com uma pequena paleta de cores usando pixels de duas ou mais cores para aproximar as cores intermediárias. Essas técnicas sacrificam a resolução espacial para aproximar a resolução de cores mais profundas. Embora não faça parte da especificação GIF, o pontilhamento pode ser usado em imagens posteriormente codificadas como imagens GIF. Isso geralmente não é uma solução ideal para imagens GIF, porque a perda de resolução espacial normalmente faz com que uma imagem pareça confusa na tela e porque os padrões de pontilhamento geralmente interferem na compressibilidade dos dados da imagem, trabalhando contra os GIFs. Propósito principal.

Nos primórdios dos navegadores gráficos da web, placas gráficas com buffers de 8 bits (permitindo apenas 256 cores) eram comuns e era bastante comum criar imagens GIF usando a paleta websafe. Isso garantiu uma exibição previsível, mas limitou severamente a escolha das cores. Quando a cor de 24 bits se tornou a norma, as paletas puderam ser preenchidas com as cores ideais para imagens individuais.

Uma pequena tabela de cores pode ser suficiente para imagens pequenas, e manter a tabela de cores pequena permite que o download do arquivo seja mais rápido. As especificações 87a e 89a permitem tabelas de cores de 2ⁿ cores para qualquer n de 1 a 8. A maioria dos aplicativos gráficos lê e exibe GIF imagens com qualquer um desses tamanhos de tabela; mas alguns não suportam todos os tamanhos ao criar imagens. Tabelas de 2, 16 e 256 cores são amplamente suportadas.

Cor verdadeira

Embora o GIF quase nunca seja usado para imagens em cores verdadeiras, é possível fazê-lo. Uma imagem GIF pode incluir vários blocos de imagem, cada um com sua própria paleta de 256 cores, e os blocos podem ser colocados lado a lado para criar uma imagem completa. Alternativamente, a especificação GIF89a introduziu a ideia de uma imagem "transparente" color onde cada bloco de imagem pode incluir sua própria paleta de 255 cores visíveis mais uma cor transparente. Uma imagem completa pode ser criada colocando blocos de imagem em camadas com a parte visível de cada camada aparecendo através das partes transparentes das camadas acima.

Um GIF animado ilustrando uma técnica para exibir mais do que o limite típico de 256 cores

Para renderizar uma imagem colorida como um GIF, a imagem original deve ser dividida em regiões menores com não mais que 255 ou 256 cores diferentes. Cada uma dessas regiões é então armazenada como um bloco de imagem separado com sua própria paleta local e quando os blocos de imagem são exibidos juntos (seja lado a lado ou sobrepondo blocos de imagem parcialmente transparentes), a imagem colorida completa aparece. Por exemplo, dividir uma imagem em ladrilhos de 16 por 16 pixels (256 pixels no total) garante que nenhum ladrilho tenha mais do que o limite da paleta local de 256 cores, embora ladrilhos maiores possam ser usados e cores semelhantes mescladas, resultando em alguma perda de cor Informação.

Como cada bloco de imagem pode ter sua própria tabela de cores local, um arquivo GIF com muitos blocos de imagem pode ser muito grande, limitando a utilidade de GIFs coloridos. Além disso, nem todos os programas de renderização de GIF lidam com imagens lado a lado ou em camadas corretamente. Muitos programas de renderização interpretam blocos ou camadas como quadros de animação e os exibem em sequência como uma animação com a maioria dos navegadores da Web exibindo automaticamente os quadros com um tempo de atraso de 0,1 segundos ou mais.

Exemplo de arquivo GIF

Microsoft Paint salva uma pequena imagem em preto e branco como o seguinte arquivo GIF (ilustrado ampliado). A pintura não faz o uso ideal de GIF; devido à tabela de cores desnecessariamente grande (armazenamento de 256 cores em vez do usado 2) e largura de símbolo, este arquivo GIF não é uma representação eficiente da imagem de 15 pixels. Embora o bloco de extensão de controle gráfico declare o índice de cor 16 (hexadecimal 10) para ser transparente, esse índice não é usado na imagem. Os únicos índices de cores que aparecem nos dados da imagem são decimais 40 e 255, que a Tabela de Cores Global mapeia para preto e branco, respectivamente.

Imagem da amostra (aumento), tamanho real 3 pixels de largura por 5 alto

Observe que os números hexadecimais nas tabelas a seguir estão em ordem de bytes little-endian, conforme prescreve a especificação de formato.

Tabela de exemplo valores de imagem GIF

Byte # (hex)	Hexadecimal	Texto ou valor	Significado
0	47 49 46 38 39 61	GRATUITO	Cabeçalho
6	03 00:00	3	largura de tela lógica
8	05 00:00	5	Altura de tela lógica
A	F7		GCT segue para 256 cores com resolução 3×8 bits/primário, os mais baixos 3 bits representam a profundidade de bit menos 1, o mais alto verdadeiro bit significa que o GCT está presente
B	00:00	0	Cor de fundo: índice #0; #000000 preto
C	00:00	0	Razão de aspecto de pixel padrão, 0:0
D	00:00	R (vermelho) G (verde) B (azul) 0 0 0	Tabela de cores global, cor #0: #000000, preto	Bytes Dh a 30Ch no exemplo define uma paleta de 256 cores.
10.	80 00:00	R (vermelho) G (verde) B (azul) 128 0 0	Tabela de cores global, cor #1: bit transparente, não usado na imagem
...	...	...	Tabela de cores global estende-se a 30A
30A	FF FF FF	R (vermelho) G (verde) B (azul) 255 255 255	Global Color Table, cor #255: #ffffff, branco
30D	21 F9		Extensão de controle gráfico (os campos de composição precedem isso na maioria dos arquivos)
30F	04	4	Quantidade de dados GCE, 4 bytes
310	01:01		Cor de fundo transparente; este é um pouco de campo, o menor bit significa transparência
311	00:00		Atraso para animação em centésimos de segundo; não utilizado
313	10.	16.	Número de cores de pixel transparente no GCT
314	00:00		Fim do bloco GCE
315	2C		Descritor de imagem
316	00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00	(0, 0)	Posição de canto noroeste da imagem na tela lógica
31A	03 00:00 00:00	(3,5)	Largura e altura da imagem em pixels
31.	00:00	0	Tabela de cor local bit, 0 significa nenhum
31F	08	8	Início da imagem, LZW tamanho de código mínimo
320	0B	11	Montante da imagem codificada LZW segue, 11 bytes
321	00 51 FC 1B 28 70 A0 C1 83 01		11 bytes de dados de imagem, ver campo 320
32C	00:00	0	Fim do bloco de dados de imagem
32D	3B		Terminação do arquivo

Codificação de imagem

Os dados de pixel da imagem, digitalizados horizontalmente a partir do canto superior esquerdo, são convertidos pela codificação LZW em códigos que são então mapeados em bytes para armazenamento no arquivo. Os códigos de pixel normalmente não correspondem ao tamanho de 8 bits dos bytes, portanto, os códigos são compactados em bytes por um "little-Endian" esquema: o bit menos significativo do primeiro código é armazenado no bit menos significativo do primeiro byte, bits de ordem superior do código em bits de ordem superior do byte, transbordando para os bits de ordem inferior do próximo byte conforme necessário. Cada código subseqüente é armazenado começando no bit menos significativo ainda não usado.

Este fluxo de bytes é armazenado no arquivo como uma série de "sub-blocos". Cada sub-bloco tem um comprimento máximo de 255 bytes e é prefixado com um byte indicando o número de bytes de dados no sub-bloco. A série de sub-blocos é terminada por um sub-bloco vazio (um único byte 0, indicando um sub-bloco com 0 bytes de dados).

Para a imagem de amostra acima, o mapeamento reversível entre códigos de 9 bits e bytes é mostrado abaixo.

Uma leve compressão é evidente: cores de pixel definidas inicialmente por 15 bytes são exatamente representadas por 12 bytes de código, incluindo códigos de controle. O processo de codificação que produz os códigos de 9 bits é mostrado abaixo. Uma string local acumula números de cores de pixel da paleta, sem ação de saída, desde que a string local possa ser encontrada em uma tabela de códigos. Há um tratamento especial para os dois primeiros pixels que chegam antes que a tabela cresça de seu tamanho inicial por meio da adição de strings. Após cada código de saída, a string local é inicializada com a cor de pixel mais recente (que não pôde ser incluída no código de saída).

 Tabela 9 bits string --> código Ação#0 | 000h Inicializar tabela raiz de códigos de 9 bits
|:
|:
#255 | 0FFh
| 100h
end | 101h
| 100h Clear
Pixel Local |
colorir Palette string |
BLACK #40 28 | 028h 1st pixel sempre para saída
WHITE #255 FF | String found in table
28 FF | 102h Sempre adicione 1st string à tabela
FF | Inicializar string local
WHITE #255 FF FF | String not found in table
| 0FFh - código de saída para string anterior
FF FF | 103h - adicione a última string à tabela
FF | - inicialize local string
WHITE #255 FF FF | String found in table
BLACK #40 FF FF 28 | String not found in table
| 103h - código de saída para string anterior
FF FF 28 | 104h - adicione a última string à tabela
28 | - initialize local string
WHITE #255 28 FF | String found in table
WHITE #255 28 FF FF | String not found in table
| 102h - código de saída para string anterior
28 FF FF | 105h - adicione a última string à tabela
FF | - inicialize local string
WHITE #255 FF FF | String found in table
WHITE #255 FF FF FF FF | String not found in table
| 103h - código de saída para string anterior
FF FF FF | 106h - adicione a última string à tabela
FF | - inicialize local string
WHITE #255 FF FF | String found in table
WHITE #255 FF FF FF FF | String found in table
WHITE #255 FF FF FF FF FF | String not found in table
| 106h - código de saída para string anterior
FF FF FF FF| 107h - adicione a última string à tabela
FF | - inicialize local string
WHITE #255 FF FF | String found in table
WHITE #255 FF FF FF FF | String found in table
WHITE #255 FF FF FF FF FF | String found in table
Sem mais pixels
107h - código de saída para última string
101h Fim

Para maior clareza, a tabela é mostrada acima como sendo construída com strings de comprimento crescente. Esse esquema pode funcionar, mas a tabela consome uma quantidade imprevisível de memória. A memória pode ser economizada na prática observando que cada nova string a ser armazenada consiste em uma string armazenada anteriormente aumentada por um caractere. É econômico armazenar em cada endereço apenas duas palavras: um endereço existente e um caractere.

O algoritmo LZW requer uma busca na tabela para cada pixel. Uma busca linear em até 4.096 endereços tornaria a codificação lenta. Na prática os códigos podem ser armazenados em ordem de valor numérico; isso permite que cada busca seja feita por um SAR (Successive Approximation Register, como é usado em alguns ADCs), com apenas 12 comparações de magnitude. Para esta eficiência é necessária uma tabela extra para converter entre códigos e endereços de memória reais; a manutenção extra da tabela é necessária apenas quando um novo código é armazenado, o que ocorre em muito menos do que a taxa de pixels.

Decodificação de imagem

A decodificação começa mapeando os bytes armazenados de volta para códigos de 9 bits. Estes são decodificados para recuperar as cores dos pixels, conforme mostrado abaixo. Uma tabela idêntica à usada no codificador é construída adicionando strings por esta regra:

 turno9-bit ----> Tabela local Pixelcódigo código código --> string Cor da paleta Ação100h 000h | #0 Inicializar tabela raiz de códigos de 9 bits
: | palette
: | cores
0FFh | #255
100h | clr
101h | fim
028h | #40 BLACK Decodificar 1o pixel
0FFh 028h | Código de entrada encontrado na tabela
| #255 BRANCO - string de saída da tabela
102h | 28 FF - adicionar à tabela
103h 0FFh | Código de entrada não encontrado na tabela
103h | FF FF - adicionar à tabela
| - string de saída da tabela
| #255 BRANCO| #255 BRANCO102h 103h | Código de entrada encontrado na tabela
| - string de saída da tabela
| #40 BLACK| #255 BRANCO104h | FF FF 28 - adicionar à tabela
103h 102h | Código de entrada encontrado na tabela
| - string de saída da tabela
| #255 BRANCO| #255 BRANCO105h | 28 FF FF - adicionar à tabela
106h 103h | Código de entrada não encontrado na tabela
106h | FF FF FF - adicionar à tabela
| - string de saída da tabela
| #255 BRANCO| #255 BRANCO| #255 BRANCO107h 106h | Código de entrada não encontrado na tabela
107h | FF FF FF FF - adicionar à tabela
| - string de saída da tabela
| #255 BRANCO| #255 BRANCO| #255 BRANCO| #255 BRANCO101h | Final

Tamanhos de código LZW

Comprimentos de código menores podem ser usados para paletas menores que as 256 cores do exemplo. Se a paleta tiver apenas 64 cores (então os índices de cores têm 6 bits de largura), os símbolos podem variar de 0 a 63, e a largura do símbolo pode ser de 6 bits, com códigos começando em 7 bits. Na verdade, a largura do símbolo não precisa corresponder ao tamanho da paleta: contanto que os valores decodificados sejam sempre menores que o número de cores na paleta, os símbolos podem ter qualquer largura de 2 a 8 e o tamanho da paleta qualquer potência de 2 de 2 a 256. Por exemplo, se forem usadas apenas as quatro primeiras cores (valores de 0 a 3) da paleta, os símbolos podem ser considerados com 2 bits de largura com códigos a partir de 3 bits.

Por outro lado, a largura do símbolo pode ser definida em 8, mesmo se apenas os valores 0 e 1 forem usados; esses dados exigiriam apenas uma tabela de duas cores. Embora não haja sentido em codificar o arquivo dessa maneira, algo semelhante normalmente acontece para imagens bicolores: a largura mínima do símbolo é 2, mesmo que apenas os valores 0 e 1 sejam usados.

A tabela de códigos inicialmente contém códigos que são um pouco mais longos que o tamanho do símbolo para acomodar os dois códigos especiais clr e end e códigos para strings que são adicionados durante o processo. Quando a tabela está cheia, o comprimento do código aumenta para dar espaço para mais strings, até um código máximo de 4095 = FFF(hex). À medida que o decodificador constrói sua tabela, ele rastreia esses aumentos no comprimento do código e é capaz de descompactar os bytes recebidos de acordo.

GIF não compactado

Um GIF sem compressão de 46×46 com símbolos de 7 bits (128 cores, códigos de 8 bits). Clique na imagem para uma explicação do código.

O processo de codificação GIF pode ser modificado para criar um arquivo sem compactação LZW que ainda pode ser visualizado como uma imagem GIF. Esta técnica foi introduzida originalmente como uma forma de evitar a violação de patente. O GIF não compactado também pode ser um formato intermediário útil para um programador gráfico porque os pixels individuais são acessíveis para leitura ou pintura. Um arquivo GIF descompactado pode ser convertido em um arquivo GIF comum simplesmente passando-o por um editor de imagens.

O método de codificação modificado ignora a construção da tabela LZW e emite apenas os códigos da paleta raiz e os códigos para CLEAR e STOP. Isso produz uma codificação mais simples (uma correspondência de 1 para 1 entre valores de código e códigos de paleta), mas sacrifica toda a compactação: cada pixel na imagem gera um código de saída indicando seu índice de cores. Ao processar um GIF descompactado, um decodificador GIF padrão não será impedido de gravar strings em sua tabela de dicionário, mas a largura do código nunca deve aumentar, pois isso aciona um empacotamento diferente de bits em bytes.

Se a largura do símbolo for n, os códigos de largura n+1 caem naturalmente em dois blocos: o bloco inferior de 2ⁿ códigos para codificação símbolos únicos e o bloco superior de 2ⁿ códigos que serão usados pelo decodificador para sequências de comprimento maior que um. Desse bloco superior, os dois primeiros códigos já foram obtidos: 2ⁿ para CLEAR e 2ⁿ + 1 para STOP. O decodificador também deve ser impedido de usar o último código no bloco superior, 2ⁿ⁺¹ − 1, porque quando o decodificador preencher esse slot, ele aumentará a largura do código. Assim, no bloco superior existem 2ⁿ − 3 códigos disponíveis para o decodificador que não acionará um aumento na largura do código. Como o decodificador está sempre um passo atrás na manutenção da tabela, ele não gera uma entrada na tabela ao receber o primeiro código do codificador, mas gera uma para cada código subsequente. Assim, o codificador pode gerar 2ⁿ − 2 códigos sem acionar um aumento na largura do código. Portanto, o codificador deve emitir códigos CLEAR extras em intervalos de 2ⁿ − 2 códigos ou menos para reiniciar o decodificador o dicionário de codificação. O padrão GIF permite que esses códigos CLEAR extras sejam inseridos nos dados da imagem a qualquer momento. O fluxo de dados composto é particionado em sub-blocos que carregam cada um de 1 a 255 bytes.

Para a amostra de imagem 3×5 acima, os seguintes códigos de 9 bits representam "limpar" (100) seguido por pixels de imagem em ordem de varredura e "parar" (101).

0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0

Após os códigos acima serem mapeados para bytes, o arquivo descompactado difere do arquivo compactado assim:

Exemplo de compactação

O exemplo trivial de uma imagem grande de cor sólida demonstra a compactação LZW de comprimento variável usada em arquivos GIF.

Os valores de código mostrados são compactados em bytes, que são compactados em blocos de até 255 bytes. Um bloco de dados de imagem começa com um byte que declara o número de bytes a seguir. O último bloco de dados para uma imagem é marcado por um byte de comprimento de bloco zero.

Entrelaçamento

A Especificação GIF permite que cada imagem dentro da tela lógica de um arquivo GIF especifique que está entrelaçada; ou seja, que a ordem das linhas do raster em seu bloco de dados não é sequencial. Isso permite uma exibição parcial da imagem que pode ser reconhecida antes que a imagem completa seja pintada.

Uma imagem entrelaçada é dividida de cima para baixo em tiras de 8 pixels de altura, e as linhas da imagem são apresentadas na seguinte ordem:

• Passe 1: Linha 0 (a linha mais alta) de cada faixa.
• Passe 2: Linha 4 de cada tira.
• Passo 3: Linhas 2 e 6 de cada tira.
• Passo 4: Linhas 1, 3, 5 e 7 de cada tira.

Os pixels dentro de cada linha não são entrelaçados, mas apresentados consecutivamente da esquerda para a direita. Assim como nas imagens não entrelaçadas, não há quebra entre os dados de uma linha e os dados da próxima. O indicador de que uma imagem está entrelaçada é um bit definido no bloco Image Descriptor correspondente.

GIF animado

GIF pode ser usado para exibir animação, como nesta imagem do berço de Newton.

Uma animação GIF feita de duas fotos, uma morfação no outro

Embora o GIF não tenha sido projetado como um meio de animação, sua capacidade de armazenar várias imagens em um arquivo sugere naturalmente o uso do formato para armazenar os quadros de uma sequência de animação. Para facilitar a exibição das animações, a especificação GIF89a adicionou a Graphic Control Extension (GCE), que permite que as imagens (quadros) no arquivo sejam pintadas com atrasos de tempo, formando um videoclipe. Cada quadro em um GIF de animação é introduzido por seu próprio GCE, especificando o tempo de espera após o desenho do quadro. As informações globais no início do arquivo se aplicam por padrão a todos os quadros. Os dados são orientados ao fluxo, portanto, o deslocamento do arquivo do início de cada GCE depende do comprimento dos dados anteriores. Dentro de cada quadro, os dados de imagem codificados com LZW são organizados em sub-blocos de até 255 bytes; o tamanho de cada sub-bloco é declarado pelo byte que o precede.

Por padrão, uma animação exibe a sequência de quadros apenas uma vez, parando quando o último quadro é exibido. Para habilitar um loop de animação, o Netscape na década de 1990 usou o bloco Application Extension (destinado a permitir que os fornecedores adicionassem informações específicas do aplicativo ao arquivo GIF) para implementar o Netscape Application Block (NAB). Este bloco, colocado imediatamente antes da sequência de frames da animação, especifica o número de vezes que a sequência de frames deve ser reproduzida (1 a 65535 vezes) ou que deve ser repetida continuamente (zero indica loop infinito). O suporte para essas animações repetidas apareceu pela primeira vez no Netscape Navigator versão 2.0 e depois se espalhou para outros navegadores. A maioria dos navegadores agora reconhece e suporta NAB, embora não seja estritamente parte da especificação GIF89a.

O exemplo a seguir mostra a estrutura do arquivo de animação Rotating earth (large).gif mostrado (como uma miniatura) na caixa de informações do artigo.

000...
...001.
...0.
....0

O atraso da animação para cada quadro é especificado no GCE em centésimos de segundo. Alguma economia de dados é possível quando um quadro precisa apenas reescrever uma parte dos pixels da exibição, porque o descritor de imagem pode definir um retângulo menor a ser redigitalizado em vez de toda a imagem. Navegadores ou outros monitores que não oferecem suporte a GIFs animados geralmente mostram apenas o primeiro quadro.

O tamanho e a qualidade da cor dos arquivos GIF animados podem variar significativamente, dependendo do aplicativo usado para criá-los. As estratégias para minimizar o tamanho do arquivo incluem o uso de uma tabela de cores global comum para todos os quadros (em vez de uma tabela de cores local completa para cada quadro) e a minimização do número de pixels cobertos em quadros sucessivos (de modo que apenas os pixels que mudam de um quadro para o outro os próximos estão incluídos no último quadro). Técnicas mais avançadas envolvem a modificação de sequências de cores para melhor corresponder ao dicionário LZW existente, uma forma de compactação com perdas. O simples empacotamento de uma série de imagens de quadros independentes em uma animação composta tende a produzir tamanhos de arquivo grandes. As ferramentas estão disponíveis para minimizar o tamanho do arquivo dado um GIF existente.

Metadados

Os metadados podem ser armazenados em arquivos GIF como um bloco de comentário, um bloco de texto simples ou um bloco de extensão de aplicativo específico do aplicativo. Vários editores gráficos usam blocos de extensão de aplicativos não oficiais para incluir os dados usados para gerar a imagem, para que ela possa ser recuperada para edição posterior.

Todos esses métodos exigem tecnicamente que os metadados sejam divididos em subblocos para que os aplicativos possam navegar no bloco de metadados sem conhecer sua estrutura interna.

O padrão de metadados Extensible Metadata Platform (XMP) introduziu um padrão de "Dados XMP" bloco de extensão de aplicativo para incluir dados XMP em arquivos GIF. Como os dados XMP são codificados usando UTF-8 sem caracteres NUL, não há 0 bytes nos dados. Em vez de dividir os dados em sub-blocos formais, o bloco de extensão termina com um "trailer mágico" que roteia qualquer aplicativo tratando os dados como sub-blocos para um byte 0 final que encerra a cadeia de sub-blocos.

Aplicação de patentes da Unisys e LZW

Em 1977 e 1978, Jacob Ziv e Abraham Lempel publicaram dois artigos sobre uma nova classe de algoritmos de compressão de dados sem perdas, agora referidos coletivamente como LZ77 e LZ78. Em 1983, Terry Welch desenvolveu uma variante rápida do LZ78 que foi nomeada Lempel–Ziv–Welch (LZW).

Welch entrou com um pedido de patente para o método LZW em junho de 1983. A patente resultante, US4558302, concedida em dezembro de 1985, foi atribuída à Sperry Corporation, que subsequentemente se fundiu com a Burroughs Corporation em 1986 e formou a Unisys. Outras patentes foram obtidas no Reino Unido, França, Alemanha, Itália, Japão e Canadá.

Além das patentes acima, a patente de Welch de 1983 também inclui citações de várias outras patentes que a influenciaram, incluindo:

• duas patentes japonesas de 1980 de Jun Kanatsu da NEC,
• EUA Patente 4,021,782 (1974) de John S. Hoerning,
• EUA Patente 4,366,551 (1977) de Klaus E. Holtz, e
• um 1981 Patente alemã de Karl Eckhart Heinz.

Em junho de 1984, um artigo de Welch foi publicado na revista IEEE, descrevendo publicamente a técnica LZW pela primeira vez. O LZW tornou-se uma técnica popular de compactação de dados e, quando a patente foi concedida, a Unisys firmou contratos de licenciamento com mais de cem empresas.

A popularidade do LZW levou a CompuServe a escolhê-lo como a técnica de compressão para sua versão do GIF, desenvolvida em 1987. Na época, a CompuServe não tinha conhecimento da patente. A Unisys tomou conhecimento de que a versão do GIF usava a técnica de compressão LZW e entrou em negociações de licenciamento com a CompuServe em janeiro de 1993. O acordo subsequente foi anunciado em 24 de dezembro de 1994. A Unisys declarou que esperava que todas as principais empresas comerciais de serviços de informação on-line que empregassem a LZW para licenciar a tecnologia da Unisys a uma taxa razoável, mas que não exigiria licenciamento ou taxas a serem pagas para aplicativos baseados em GIF não comerciais e sem fins lucrativos, incluindo aqueles para uso em serviços on-line.

Após este anúncio, houve uma condenação generalizada da CompuServe e da Unisys, e muitos desenvolvedores de software ameaçaram parar de usar o GIF. O formato PNG (veja abaixo) foi desenvolvido em 1995 como um substituto pretendido. No entanto, obter suporte dos fabricantes de navegadores da Web e outros softwares para o formato PNG foi difícil e não foi possível substituir o GIF, embora a popularidade do PNG tenha aumentado gradualmente. Portanto, variações GIF sem compressão LZW foram desenvolvidas. Por exemplo, a biblioteca libungif, baseada no giflib de Eric S. Raymond, permite a criação de GIFs que seguiam o formato de dados, mas evitavam os recursos de compactação, evitando assim o uso da patente Unisys LZW. A 2001 Dr. O artigo de Dobb descreveu uma maneira de obter codificação compatível com LZW sem infringir suas patentes.

Em agosto de 1999, a Unisys mudou os detalhes de sua prática de licenciamento, anunciando a opção para proprietários de determinados sites privados e não comerciais de obter licenças mediante o pagamento de uma taxa de licença única de US$ 5.000 ou US$ 7.500. Essas licenças não eram necessárias para proprietários de sites ou outros usuários de GIF que usaram software licenciado para gerar GIFs. No entanto, a Unisys foi submetida a milhares de ataques online e e-mails abusivos de usuários que acreditavam que seriam cobrados US$ 5.000 ou processados por usar GIFs em seus sites. Apesar de fornecer licenças gratuitas para centenas de organizações sem fins lucrativos, escolas e governos, a Unisys foi completamente incapaz de gerar qualquer boa publicidade e continuou a ser condenada por indivíduos e organizações como a League for Programming Freedom, que iniciou o "Burn All GIFs" campanha em 1999.

A patente LZW dos Estados Unidos expirou em 20 de junho de 2003. As patentes equivalentes no Reino Unido, França, Alemanha e Itália expiraram em 18 de junho de 2004, as patentes japonesas expiraram em 20 de junho de 2004 e a patente canadense expirou em 7 de julho 2004. Conseqüentemente, embora a Unisys tenha outras patentes e pedidos de patente relacionados a melhorias na técnica LZW, o próprio LZW (e, consequentemente, o GIF) pode ser usado gratuitamente desde julho de 2004.

Alternativas

PNG

O Portable Network Graphics (PNG) foi projetado para substituir o GIF, a fim de evitar a violação dos direitos autorais da Unisys' patente na técnica de compressão LZW. O PNG oferece melhor compactação e mais recursos do que o GIF, sendo a animação a única exceção significativa. O PNG é mais adequado do que o GIF em casos em que são necessárias imagens em cores verdadeiras e transparência alfa.

Embora o suporte para o formato PNG tenha surgido lentamente, novos navegadores da Web suportam PNG. Versões mais antigas do Internet Explorer não oferecem suporte a todos os recursos do PNG. As versões 6 e anteriores não oferecem suporte à transparência do canal alfa sem usar extensões HTML específicas da Microsoft. A correção gama de imagens PNG não era suportada antes da versão 8, e a exibição dessas imagens em versões anteriores pode ter a tonalidade errada.

Para dados de imagem idênticos de 8 bits (ou inferior), os arquivos PNG são normalmente menores que os GIFs equivalentes, devido às técnicas de compactação mais eficientes usadas na codificação PNG. O suporte completo para GIF é complicado principalmente pela complexa estrutura de tela que ele permite, embora seja isso que permite os recursos de animação compacta.

Formatos de animação

Os vídeos resolvem muitos problemas que os GIFs apresentam por meio do uso comum na web. Eles incluem tamanhos de arquivo drasticamente menores, a capacidade de superar a restrição de cores de 8 bits e melhor manipulação de quadros e compactação por meio de codecs. O suporte praticamente universal para o formato GIF em navegadores da Web e a falta de suporte oficial para vídeo no padrão HTML fizeram com que o GIF ganhasse destaque com o objetivo de exibir arquivos curtos semelhantes a vídeos na Web.

• MNG ("Multiple-image Network Graphics") foi originalmente desenvolvido como uma solução baseada em PNG para animações. O MNG alcançou a versão 1.0 em 2001, mas poucos aplicativos o suportam.

• APNG ("Animated Portable Network Graphics") foi proposto pela Mozilla em 2006. APNG é uma extensão para o formato PNG como alternativa ao formato MNG. APNG é suportado pela maioria dos navegadores a partir de 2019. APNG fornece a capacidade de animar arquivos PNG, mantendo a compatibilidade retroativa em decodificadores que não podem entender o pedaço de animação (ao contrário de MNG). Os decodificadores mais velhos simplesmente renderizarão o primeiro quadro da animação.

O grupo PNG rejeitou oficialmente a APNG como uma extensão oficial em 20 de abril de 2007.

Houve várias propostas subseqüentes para um formato gráfico animado simples com base em PNG usando várias abordagens diferentes. No entanto, APNG ainda está em desenvolvimento pela Mozilla e é suportado no Firefox 3.0 enquanto o suporte MNG foi descartado. APNG é atualmente suportado por todos os principais navegadores da web, incluindo Chrome (desde a versão 59.0), Opera, Firefox e Edge.

• Objetos Adobe Flash incorporados e
• Arquivos MPEG foram usados em alguns sites para exibir vídeo simples, mas exigiu o uso de um plugin de navegador adicional.

• WebM e
• WebP estão em desenvolvimento e são suportados por alguns navegadores da web.

• Outras opções para animação web incluem servir quadros individuais usando AJAX, ou
• animando imagens SVG ("Gráficos gráficos vetoriais escaláveis") usando JavaScript ou SMIL ("Integração Multimédia Sincronizada").

• Com a introdução do suporte generalizado do vídeo HTML5 () tag na maioria dos navegadores da web, alguns sites usam uma versão em loop da tag de vídeo gerada por funções JavaScript. Isso dá a aparência de um GIF, mas com o tamanho e velocidade vantagens de vídeo comprimido.

Exemplos notáveis são Gfycat e Imgur e seu metaformato GIFV, que é realmente uma tag de vídeo jogando um vídeo em loop MP4 ou WebM compactado.

• HEIF ("High Efficiency Image File Format") é um formato de arquivo de imagem, finalizado em 2015, que usa um algoritmo de compressão com perda de transformada de cosseina discreta (DCT) baseado no formato de vídeo HEVC e relacionado ao formato de imagem JPEG. Em contraste com JPEG, HEIF suporta animação.

Em comparação com o formato GIF, que não tem compressão DCT, HEIF permite compressão significativamente mais eficiente. HEIF armazena mais informações e produz imagens animadas de alta qualidade em uma pequena fração do tamanho de um GIF equivalente.

• O VP9 suporta apenas a composição alfa com 4:2:0 subamostragem de croma no formato de pixel YUVA420, que pode ser inadequado para GIFs que combinam transparência com gráficos vetoriais rasterizados com detalhes de cor fina.

• O codec de vídeo AV1 ou o AVIF também podem ser usados como um vídeo ou uma imagem sequenciada.

Usos

Em abril de 2014, o 4chan adicionou suporte para vídeos WebM silenciosos com menos de 3 MB de tamanho e 2 minutos de duração e, em outubro de 2014, o Imgur começou a converter qualquer arquivo GIF carregado no site em vídeo e fornecer o link para o Reprodutor HTML a aparência de um arquivo real com uma extensão .gifv.

Em janeiro de 2016, o Telegram começou a recodificar todos os GIFs para vídeos MPEG-4 que "requer até 95% menos espaço em disco para a mesma qualidade de imagem"