GIF -GIF

GIF
Terra girando (grande).gif
Extensão de nome de arquivo
.gif
Tipo de mídia da Internet
image/gif
Código do tipo GIFf
Identificador de tipo uniforme (UTI) com.compuserve.gif
número mágico GIF87a/GIF89a
Desenvolvido por CompuServe
lançamento inicial 15 de junho de 1987 ; 35 anos atrás ( 1987-06-15 )
Último lançamento
89a
1989 ; 33 anos atrás ( 1989 )
Tipo de formato formato de imagem bitmap sem perdas
Local na rede Internet www .w3 .org /Graphics /GIF /spec-gif89a .txt

O Graphics Interchange Format ( GIF ; / ɪ f / JIF ou / ɡ ɪ f / GHIF , veja a pronúncia ) é um formato de imagem bitmap que foi desenvolvido por uma equipe do provedor de serviços online CompuServe liderado pelo cientista da computação americano Steve Wilhite e lançado em 15 de junho de 1987. Desde então, entrou em uso generalizado 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 cor , mas adequado para imagens mais simples, como gráficos ou logotipos com áreas sólidas de cor.

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. Esta técnica de compressão foi patenteada em 1985. A controvérsia sobre o acordo de licenciamento entre o detentor da patente do software , Unisys , e a CompuServe em 1994 estimulou o desenvolvimento do padrão Portable Network Graphics (PNG). Em 2004, todas as patentes relevantes haviam expirado.

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 preto e branco. O GIF tornou-se popular porque usava a compressão de dados Lempel–Ziv–Welch . Como isso era mais eficiente do que a codificação de comprimento de execução usada por PCX e MacPaint , imagens razoavelmente 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 aprimorada , chamada 89a , Esta versão adicionou:

  • suporte para atrasos de animação ,
  • cores de fundo transparentes ,
  • armazenamento de metadados específicos do aplicativo e
  • incorporando rótulos de texto como texto (não os incorporando nos dados gráficos),
    mas como há pouco controle sobre as fontes de exibição, esse recurso não é amplamente utilizado.

As duas versões podem ser distinguidas observando os primeiros seis bytes do arquivo (o " número mágico " ou assinatura), que, quando interpretados como ASCII , lêem "GIF87a" e "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 fotos criadas em um Atari ST ou Commodore 64 . 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 fazer loops de GIFs animados .

O recurso de armazenar várias imagens em um arquivo, acompanhado 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 tal forma que mesmo uma imagem parcialmente baixada era um pouco reconhecível, também ajudou a popularidade do GIF, pois um usuário poderia abortar o download se não fosse o necessário.

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 também como um verbo , que significa "criar um arquivo GIF", como em "GIFing foi o meio perfeito para compartilhar cenas dos Jogos Olímpicos de Verão ". Os lexicógrafos da imprensa votaram nele 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 bem-humorada anunciando o lançamento de uma conta no Tumblr para a Casa Branca sugere a pronúncia de GIF com um g duro .

A pronúncia da primeira letra do GIF é contestada desde a década de 1990. As pronúncias mais comuns em inglês são / ɪ f / ( listen ) (com um g suave como em gin ) e / ɡ ɪ f / ( listen ) (com um g duro como em gift ), diferindo no fonema representado pelo letra G. _ Os criadores do formato pronunciaram o acrônimo GIF como / ɪ f / , 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 como / ɡ ɪ f / , com um g duro , e as pesquisas geralmente mostraram que essa pronúncia do g duro é mais prevalente.

O Dictionary.com cita ambas as pronúncias, indicando / ɪ f / como a pronúncia primária, enquanto o Cambridge Dictionary of American English oferece apenas a pronúnciahard- g . Merriam-Webster's Collegiate Dictionary e Oxford Dictionaries citam ambas as pronúncias, mas colocam o g duro primeiro: / ɡ ɪ f , ɪ f / . O New Oxford American Dictionary deu apenas / ɪ f / em sua segunda edição, mas atualizou para / ɪ f , ɡ ɪ f / na terceira edição.

O desacordo sobre a pronúncia levou a um debate acalorado na Internet. Na ocasião de receber um prêmio pelo conjunto da obra na cerimônia do Webby Awards de 2013 , Wilhite rejeitou publicamente a pronúncia g -hard; seu discurso levou a 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 entrou no debate em 2013. Em fevereiro de 2020, a The JM Smucker Company , proprietária da marca Jif, fez uma 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" ( hashtag como #JIFvsGIF ) pote de manteiga de amendoim que tinha um rótulo que declarava com humor a pronúncia do g suave para se referir exclusivamente à manteiga de amendoim, e o GIF para ser pronunciado exclusivamente com a pronúncia do g duro.

Uso

GIFs são adequados para arte de linha de bordas 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 sprite 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 têm 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, elas não precisam preencher toda a tela lógica.

Os arquivos GIF começam com um cabeçalho de tamanho fixo ("GIF87a" ou "GIF89a") que fornece a versão, seguido por um Descritor de Tela Lógica de tamanho fixo que fornece 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 Global de Cores (GCT), que segue a seguir, se presente.

A partir daí, o arquivo é dividido em segmentos, cada um introduzido por um 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 trailer (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 houver). Os dados da imagem seguem: um byte fornecendo a largura de bits dos símbolos não codificados (que deve ter pelo menos 2 bits de largura, mesmo para imagens bicolores), seguido por uma lista vinculada 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 no sentinela, um byte adicional especificando o tipo de extensão e uma lista vinculada de subblocos com os dados de extensão. Blocos de extensão que modificam uma imagem (como a Extensão de Controle Gráfico que especifica o tempo de atraso de animação opcional 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 subsequentes no sub-bloco (1 a 255). A série de sub-blocos é terminada por um sub-bloco vazio (um byte 0).

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

Os detalhes completos do formato do arquivo são abordados na especificação GIF.

Paletas

Um exemplo de uma imagem GIF salva com uma paleta segura para a Web e pontilhada 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 usadas em uma imagem (um quadro) no arquivo têm seus valores RGB definidos em uma tabela de paleta 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 extraídas de um espaço de cores de milhões de tons (2 24 tons, 8 bits para cada primário), mas o número máximo de cores que um quadro pode usar é 256. Essa limitação parecia razoável quando o GIF foi desenvolvido porque poucas pessoas podiam pagar o hardware para exibir mais cores simultaneamente. Gráficos simples, desenhos de linha, desenhos animados e fotografias em escala de cinza normalmente precisam de menos de 256 cores.

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

Muitas técnicas, chamadas coletivamente de dithering , 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 profunda. 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, tanto porque a perda de resolução espacial normalmente faz uma imagem parecer confusa na tela, quanto porque os padrões de pontilhamento geralmente interferem na compressibilidade dos dados da imagem, trabalhando contra o objetivo principal do GIF.

Nos primeiros dias dos navegadores gráficos, placas gráficas com buffers de 8 bits (permitindo apenas 256 cores) eram comuns e era bastante comum fazer imagens GIF usando a paleta websafe . Isso garantiu uma exibição previsível, mas limitou severamente a escolha de cores. Quando as cores de 24 bits se tornaram 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 arquivo seja baixado mais rapidamente. As especificações 87a e 89a permitem tabelas de cores de 2 n cores para qualquer n de 1 a 8. A maioria dos aplicativos gráficos lê e exibe imagens GIF 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 dos quais pode ter sua própria paleta de 256 cores, e os blocos podem ser lado a lado para criar uma imagem completa. Alternativamente, a especificação GIF89a introduziu a ideia de uma cor "transparente" 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 que ilustra 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 no máximo 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 (por ladrilhamento ou por camadas de blocos de imagem parcialmente transparentes), a imagem completa e colorida aparece. Por exemplo, dividir uma imagem em blocos de 16 por 16 pixels (256 pixels no total) garante que nenhum bloco tenha mais do que o limite da paleta local de 256 cores, embora blocos maiores possam ser usados ​​e cores semelhantes mescladas, resultando em alguma perda de cor em formaçã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 segundo ou mais.

Exemplo de arquivo GIF

O Microsoft Paint salva uma pequena imagem em preto e branco como o arquivo GIF a seguir (ilustrado ampliado).

Imagem de amostra (ampliada), tamanho real 3 pixels de largura por 5 de altura
Bytes D h a 30C h no exemplo definem uma paleta de 256 cores.

O Paint não faz o uso ideal do GIF; devido à tabela de cores desnecessariamente grande (armazenando 256 cores completas em vez das 2 usadas) e à largura do símbolo, este arquivo GIF não é uma representação eficiente da imagem de 15 pixels.

Embora o bloco Graphic Control Extension declare o índice de cor 16 (hexadecimal 10) transparente, esse índice não é usado na imagem. Os únicos índices de cores que aparecem nos dados da imagem são os decimais 40 e 255, que a Global Color Table mapeia para preto e branco, respectivamente.

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

Tabela de valores de imagem GIF de exemplo
Byte # (hex) Hexadecimal Texto ou valor Significado
0 47 49 46 38 39 61 GIF89a Cabeçalho
6 03 00 3 Largura lógica da tela
8 05 00 5 Altura lógica da tela
UMA F7 GCT segue para 256 cores com resolução 3  ×  8 bits/primário, os 3 bits mais baixos representam a profundidade de bits menos 1, o bit verdadeiro mais alto significa que o GCT está presente
B 00 0 Cor de fundo: índice #0; #000000 preto
C 00 0 Proporção de pixel padrão, 0:0
D 00 00 00
R (vermelho) G (verde) B (azul)
0 0 0
Tabela de cores global, cor #0: #000000, preto
10 80 00 00
R (vermelho) G (verde) B (azul)
128 0 0
Global Color Table, cor #1: bit transparente, não usado na imagem
... ... ... Tabela de cores global se estende até 30A
30A FF FF FF
R (vermelho) G (verde) B (azul)
255 255 255
Tabela de cores global, cor nº 255: #ffffff, branco
30D 21 F9 Extensão de controle gráfico (campos de comentário precedem isso na maioria dos arquivos)
30F 04 4 Quantidade de dados GCE, 4 bytes
310 01 Cor de fundo transparente; este é um campo de bits, o bit mais baixo significa transparência
311 00 00 Atraso para animação em centésimos de segundo; não usado
313 10 16 Número de cor do pixel transparente no GCT
314 00 Fim do bloco GCE
315 2C Descritor de imagem
316 00 00 00 00 (0, 0) Posição do canto noroeste da imagem na tela lógica
31A 03 00 05 00 (3, 5) Largura e altura da imagem em pixels
31E 00 0 Bit da tabela de cores local, 0 significa nenhum
31F 08 8 Início da imagem, tamanho mínimo do código LZW
320 0B 11 Quantidade de sequência de imagem codificada em LZW, 11 bytes
321 00 51 FC 1B 28 70 A0 C1 83 01 01 <dados da imagem> 11 bytes de dados de imagem, consulte o campo 320
32C 00 0 Fim do bloco de dados de imagem
32D 3B Encerramento 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, então os códigos são empacotados em bytes por um esquema "little-Endian": 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 subsequente é armazenado a partir do 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 que indica 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 exemplo acima, o mapeamento reversível entre códigos de 9 bits e bytes é mostrado abaixo.

Mapeamento reversível
código de 9 bits Byte
Hexadecimal Binário Binário Hexadecimal
100 1 00000000 00000000 00
028 00 0101000 0101000 1 51
0FF 011 111111 111111 00 FC
103 1000 00011 00011 011 1B
102 10000 0010 0010 1000 28
103 100000 011 011 10000 70
106 1000001 10 10 100000 A0
107 10000011 1 1 1000001 C1
10000011 83
101 1 00000001 00000001 01
0000000 1 01

Uma leve compressão é evidente: as cores dos pixels definidas inicialmente por 15 bytes são representadas exatamente 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 dos dois primeiros pixels que chegam antes que a tabela cresça de seu tamanho inicial por acréscimos 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).

                          Table           9-bit
                     string --> code      code    Action
                          #0 | 000h               Initialize root table of 9-bit codes
                    palette  |  :
                     colors  |  :
                        #255 | 0FFh
                         clr | 100h
                         end | 101h
                             |            100h     Clear
Pixel          Local         |
color Palette  string        |
BLACK  #40     28            |            028h     1st pixel always to output
WHITE  #255    FF            |                     String found in table
                  28 FF      | 102h                Always add 1st string to table
               FF            |                     Initialize local string
WHITE  #255    FF FF         |                     String not found in table
                             |            0FFh     - output code for previous string
                  FF FF      | 103h                - add latest string to table
               FF            |                     - initialize local string
WHITE  #255    FF FF         |                     String found in table
BLACK  #40     FF FF 28      |                     String not found in table
                             |            103h     - output code for previous string
                  FF FF 28   | 104h                - add latest string to table
               28            |                     - initialize local string
WHITE  #255    28 FF         |                     String found in table
WHITE  #255    28 FF FF      |                     String not found in table
                             |            102h     - output code for previous string
                  28 FF FF   | 105h                - add latest string to table
               FF            |                     - initialize local string
WHITE  #255    FF FF         |                     String found in table
WHITE  #255    FF FF FF      |                     String not found in table
                             |            103h     - output code for previous string
                  FF FF FF   | 106h                - add latest string to table
               FF            |                     - initialize local string
WHITE  #255    FF FF         |                     String found in table
WHITE  #255    FF FF FF      |                     String found in table
WHITE  #255    FF FF FF FF   |                     String not found in table
                             |            106h     - output code for previous string
                  FF FF FF FF| 107h                - add latest string to table
               FF            |                     - initialize local string
WHITE  #255    FF FF         |                     String found in table
WHITE  #255    FF FF FF      |                     String found in table
WHITE  #255    FF FF FF FF   |                     String found in table
                                                   No more pixels
                                          107h     - output code for last string
                                          101h     End

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 salva na prática observando que cada nova string a ser armazenada consiste em uma string armazenada anteriormente aumentada em 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 pesquisa linear em até 4096 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 (Registro de Aproximação Sucessiva, 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 acontece a uma taxa muito menor do que o pixel.

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:

O código de entrada é encontrado na tabela?
Sim adicionar string para código local seguido pelo primeiro byte de string para código de entrada
Não adicionar string para código local seguido por cópia de seu próprio primeiro byte
      shift
9-bit ----> Local      Table                 Pixel
code        code   code --> string   Palette color  Action
100h               000h  | #0                       Initialize root table of 9-bit codes
                    :    | palette
                    :    | colors
                   0FFh  | #255
                   100h  | clr
                   101h  | end
028h                     |             #40   BLACK  Decode 1st pixel
0FFh        028h         |                           Incoming code found in table
                         |             #255  WHITE   - output string from table
                   102h  | 28 FF                     - add to table
103h        0FFh         |                           Incoming code not found in table
                   103h  | FF FF                     - add to table
                         |                           - output string from table
                         |             #255  WHITE
                         |             #255  WHITE
102h        103h         |                           Incoming code found in table
                         |                           - output string from table
                         |             #40   BLACK
                         |             #255  WHITE
                   104h  | FF FF 28                  - add to table
103h        102h         |                           Incoming code found in table
                         |                           - output string from table
                         |             #255  WHITE
                         |             #255  WHITE
                   105h  | 28 FF FF                  - add to table
106h        103h         |                           Incoming code not found in table
                   106h  | FF FF FF                  - add to table
                         |                           - output string from table
                         |             #255  WHITE
                         |             #255  WHITE
                         |             #255  WHITE
107h        106h         |                           Incoming code not found in table
                   107h  | FF FF FF FF               - add to table
                         |                           - output string from table
                         |             #255  WHITE
                         |             #255  WHITE
                         |             #255  WHITE
                         |             #255  WHITE
101h                     |                           End

Comprimentos de código LZW

Comprimentos de código mais curtos podem ser usados ​​para paletas menores que as 256 cores no exemplo. Se a paleta tiver apenas 64 cores (portanto, 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 considerada 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: desde 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 ter 2 bits de largura com códigos começando em 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 faça sentido codificar o arquivo dessa maneira, algo semelhante normalmente acontece para imagens bicolores: a largura mínima do símbolo é 2, mesmo que sejam usados ​​apenas os valores 0 e 1.

A tabela de códigos contém inicialmente códigos que são um bit 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 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 descompactado

Um GIF descompactado 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 possa ser visualizado como uma imagem GIF. Esta técnica foi introduzida originalmente como forma de evitar a violação de patentes. O GIF descompactado também pode ser um formato intermediário útil para um programador gráfico, pois 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 de 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 para 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 n códigos para codificar símbolos simples e o bloco superior de 2 n códigos que serão usados ​​pelo decodificador para sequências de comprimento maior que um. Desse bloco superior, já são tomados os dois primeiros códigos: 2 n para CLEAR e 2 n + 1 para STOP. O decodificador também deve ser impedido de usar o último código do bloco superior, 2 n +1 − 1 , pois quando o decodificador preencher esse slot, aumentará a largura do código. Assim, no bloco superior há 2 n − 3 códigos disponíveis para o decodificador que não acionarão 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 gerará uma para cada código seguinte. Assim, o codificador pode gerar 2 n − 2 códigos sem disparar um aumento na largura do código. Portanto, o codificador deve emitir códigos CLEAR extras em intervalos de 2 n − 2 códigos ou menos para fazer o decodificador redefinir 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, cada um com 1 a 255 bytes.

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

100 028 0FF 0FF 0FF 028 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 101

Depois que os códigos acima são mapeados para bytes, o arquivo descompactado difere do arquivo compactado assim:

Byte # (hex) Hexadecimal Texto ou valor Significado
320 14 20 Dados de imagem não compactados de 20 bytes seguem
321 00 51 FC FB F7 0F C5 BF 7F FF FE FD FB F7 EF DF BF 7F 01 01
335 00 0 Dados de fim de imagem

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.

Amostra de compactação de um arquivo GIF
Código Píxeis Notas
Não.
N i
Valor
N i + 256
Comprimento
(bits)
Este código
N i
Acumulado
N i (N i + 1)/2
As relações usando N i só se aplicam a pixels da mesma cor até que a tabela de codificação esteja cheia.
0 100h 9 Limpar tabela de códigos
1 FF 1 1 Cor do pixel superior esquerdo escolhido como o índice mais alto de uma paleta de 256 cores
2 102h 2 3
3
255
103h
1FFh
3
255
6
32640
Último código de 9 bits
256
767
200h
3FFh
10 256
767
32896
294528
Último código de 10 bits
768
1791
400h
7FFh
11 768
1791
295296
1604736
Último código de 11 bits
1792
3839
800h
FFFh
12 1792
3839
1606528
7370880
Tabela de códigos cheia
FFFh 3839 O código máximo pode se repetir para mais pixels da mesma cor.
A compactação geral de dados se aproxima assintoticamente de 3839 ×8/12= 2559+1/3
101h Dados de fim de imagem

Os valores de código mostrados são empacotados em bytes que são empacotados 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 de 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; isto é, que a ordem das linhas raster em seu bloco de dados não seja 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 tira.
  • Passe 2: Linha 4 de cada tira.
  • Passe 3: Linhas 2 e 6 de cada tira.
  • Passe 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 Descritor de Imagem 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 se transformando na outra

Embora o GIF não tenha sido projetado como um meio de animação, sua capacidade de armazenar várias imagens em um arquivo naturalmente sugeriu o uso do formato para armazenar os quadros de uma sequência de animação. Para facilitar a exibição de animações, a especificação GIF89a adicionou a Graphic Control Extension (GCE), que permite que as imagens (frames) 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 em 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 permitir o loop de uma animação, a 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 quadros de animação, especifica o número de vezes que a sequência de quadros deve ser reproduzida (1 a 65535 vezes) ou que deve ser repetida continuamente (zero indica loop para sempre). 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 miniatura) na infobox do artigo.

Estrutura do GIF
Byte # (hex) Hexadecimal Texto ou valor Significado
0 47 49 46 38 39 61 GIF89a Descritor de tela lógica
6 90 01 400 Largura em pixels
8 90 01 400 Altura em pixels
UMA F7 GCT segue para 256 cores com resolução 3  ×  8 bits/primário
B 00 0 Cor de fundo: #000000, preto
C 00 0 Proporção de pixel padrão, 0:0
D 00 Tabela Global de Cores
30D 21 FF Extensão de aplicativo
30F 0B 11 Tamanho do bloco incluindo nome do aplicativo e bytes de verificação (sempre 11)
310 4E 45 54 53 43 41 50 45 32 2E 30 NETSCAPE 2.0 Nome do aplicativo de 8 bytes mais 3 bytes de verificação
31B 03 3 Número de bytes no seguinte sub-bloco
31C 01 1 Índice do sub-bloco de dados atual (sempre 1 para o bloco NETSCAPE)
31D FF FF 65535 Número não sinalizado de repetições
31F 00 Fim da cadeia de subblocos para o bloco de extensão de aplicativo
320 21 F9 Extensão de controle gráfico para o quadro nº 1
322 04 4 Número de bytes (4) no sub-bloco atual
323 04
000.....
...001..
......0.
.......0
(dividido em seções para facilitar a leitura)
Reservado, 5 bits inferiores são campos de bits
Método de descarte 1: não descartar
Nenhuma entrada do usuário
Cor transparente, 0 significa não fornecido
324 09 00 9 Atraso do quadro: atraso de 0,09 segundo antes de pintar o próximo quadro
326 FF Índice de cores transparentes (não usado neste quadro)
327 00 Fim da cadeia de subblocos para o bloco de extensão de controle gráfico
328 2C Descritor de imagem do quadro #1
329 00 00 00 00 (0, 0) Posição do canto noroeste da imagem na tela lógica: (0, 0)
32D 90 01 90 01 (400, 400) Largura e altura do quadro: 400  ×  400 pixels
331 00 0 Tabela de cores local: 0 significa nenhum e nenhum entrelaçamento
332 08 8 Tamanho mínimo do código LZW para dados de imagem do quadro nº 1
333 FF 255 Número de bytes de dados de imagem LZW no seguinte sub-bloco: 255 bytes
334 ... <dados da imagem> Dados de imagem, 255 bytes
433 FF 255 Número de bytes de dados de imagem LZW no seguinte sub-bloco, 255 bytes
434 ... <dados da imagem> Dados de imagem, 255 bytes
Repita para os próximos blocos
92C0 00 Fim da cadeia de subblocos para este quadro
92C1 21 F9 Extensão de controle gráfico para o quadro nº 2
Repita para os próximos quadros
EDABD 21 F9 Extensão de controle gráfico para o quadro nº 44
Informações e dados da imagem para o quadro nº 44
F48F5 3B Trailer: Último byte do arquivo, sinalizando EOF

O atraso de animação para cada quadro é especificado no GCE em centésimos de segundo. Alguma economia de dados é possível quando um quadro precisa reescrever apenas uma parte dos pixels da exibição, porque o Descritor de Imagem pode definir um retângulo menor para ser redigitalizado em vez de toda a imagem. Navegadores ou outros monitores que não suportam 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 usar uma tabela de cores global comum para todos os quadros (em vez de uma tabela de cores local completa para cada quadro) e minimizar o número de pixels cobertos em quadros sucessivos (de modo que apenas os pixels que mudam de um quadro para o 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 gerar 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ários, 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 aplicativo 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 sub-blocos para que os aplicativos possam navegar no bloco de metadados sem conhecer sua estrutura interna.

O padrão de metadados da Extensible Metadata Platform (XMP) introduziu um bloco de extensão de aplicativo "XMP Data" não oficial, mas agora amplamente difundido, 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 "reboque mágico" que roteia qualquer aplicativo que trate os dados como sub-blocos para um byte 0 final que encerra a cadeia de sub-blocos.

Aplicação de patentes Unisys e LZW

Em 1977 e 1978, Jacob Ziv e Abraham Lempel publicaram um par de 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 denominada Lempel–Ziv–Welch (LZW).

Welch apresentou 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 posteriormente 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 1983 de Welch também inclui citações de várias outras patentes que a influenciaram, incluindo:

Em junho de 1984, um artigo de Welch foi publicado na revista IEEE que descreveu publicamente a técnica LZW pela primeira vez. A LZW tornou-se uma técnica popular de compactação de dados e, quando a patente foi concedida, a Unisys celebrou acordos de licenciamento com mais de uma centena de empresas.

A popularidade do LZW levou a CompuServe a escolhê-lo como 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. Patente 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 nos 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 GIF. O formato PNG (veja abaixo) foi desenvolvido em 1995 como uma substituição pretendida. No entanto, obter suporte dos fabricantes de navegadores da Web e outros softwares para o formato PNG provou ser difícil e não foi possível substituir o GIF, embora o PNG tenha aumentado gradualmente em popularidade. Portanto, foram desenvolvidas variações de GIF sem compressão LZW. Por exemplo, a biblioteca libungif, baseada no giflib de Eric S. Raymond , permite a criação de GIFs que seguem o formato de dados, mas evitam os recursos de compactação, evitando assim o uso da patente Unisys LZW. Um artigo de 2001 do Dr. Dobb descreveu outra alternativa à compressão LZW, baseada em raízes quadradas.

Em agosto de 1999, a Unisys mudou os detalhes de sua prática de licenciamento, anunciando a opção para os proprietários de determinados sites não comerciais e privados obterem licenças mediante o pagamento de uma taxa única de licença de US$ 5.000 ou US$ 7.500. Essas licenças não eram exigidas 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 acreditando que seriam cobrados US$ 5.000 ou processados ​​por usar GIFs em seus sites. Apesar de conceder licenças gratuitas a 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 a campanha "Burn All GIFs" em 1999.

A patente LZW dos Estados Unidos expirou em 20 de junho de 2003. As patentes de contrapartida 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 de 2004. Consequentemente , enquanto a Unisys tem mais patentes e pedidos de patentes relacionados a melhorias na técnica LZW, a própria LZW (e consequentemente o GIF) está livre para uso desde julho de 2004.

Alternativas

PNG

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

Embora o suporte para o formato PNG tenha sido lento, os 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 de canal alfa sem usar extensões HTML específicas da Microsoft. A correção de 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 inferiores), os arquivos PNG geralmente são 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 estrutura de tela complexa que ele permite, embora seja isso que habilita os recursos de animação compactos.

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 virtualmente 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 atingiu 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 do formato PNG como alternativa ao formato MNG. O APNG é suportado pela maioria dos navegadores a partir de 2019. O APNG fornece a capacidade de animar arquivos PNG, mantendo a compatibilidade com versões anteriores em decodificadores que não conseguem entender o bloco de animação (ao contrário do MNG). Os decodificadores mais antigos simplesmente renderizarão o primeiro quadro da animação.
O grupo PNG rejeitou oficialmente o APNG como uma extensão oficial em 20 de abril de 2007.
Houve várias propostas subsequentes para um formato gráfico animado simples baseado em PNG usando várias abordagens diferentes. No entanto, o APNG ainda está em desenvolvimento pela Mozilla e é suportado no Firefox 3.0 , enquanto o suporte ao MNG foi descartado. Atualmente, o APNG é 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ídeos simples, mas exigiam o uso de um plug-in 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 da web incluem servir quadros individuais usando AJAX ou
  • animar imagens SVG ("Gráficos vetoriais escaláveis") usando JavaScript ou SMIL ("Linguagem de Integração Multimídia Sincronizada").
  • Com a introdução do amplo suporte da tag de vídeo HTML5 ( <video>) 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 as vantagens de tamanho e velocidade do vídeo compactado.
Exemplos notáveis ​​são Gfycat e Imgur e seu metaformato GIFV, que é realmente uma tag de vídeo reproduzindo um vídeo compactado MP4 ou WebM em loop.
Comparado ao formato GIF, que não possui compactação DCT, o HEIF permite uma compactação significativamente mais eficiente. O HEIF armazena mais informações e produz imagens animadas de alta qualidade em uma pequena fração do tamanho de um GIF equivalente.
  • O codec AV1 também pode ser usado como vídeo ou 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 player HTML aparência de um arquivo real com uma .gifvextensão.

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

Veja também

Referências

links externos