Converter GIF para BMP

Esses dois formatos têm quase a mesma idade — 1987 e 1990 — e resolvem o mesmo problema em direções opostas. Um GIF guarda um índice numa paleta de no máximo 256 entradas, ou seja, um byte por pixel antes da compressão LZW apertar ainda mais. O bitmap escrito aqui guarda um trio completo de azul, verde e vermelho para cada pixel, sem compressão nenhuma.

Então o crescimento não é um fator, são dois multiplicados. Três bytes onde o GIF usava um, e nenhuma da economia de LZW que tornou o GIF pequeno em primeiro lugar. Um GIF de 40 KB rotineiramente vira um bitmap dez vezes maior, e numa arte plana com longas sequências de cor idêntica — o material que o GIF comprime melhor — a proporção fica ainda pior.

A conta é curta e não tem estimativa nenhuma nela. Multiplique a largura por três para ter os bytes de uma linha, arredonde para o próximo múltiplo de quatro, multiplique pela altura e some 54 bytes de cabeçalho. Um GIF de 480 por 270 dá 1.440 bytes por linha, sem precisar arredondar, 388.800 bytes de pixels e 388.854 no total.

Nada na origem muda esse número. O mesmo bitmap de 480 por 270 sai de uma fotografia bastante dithered e sai de um retângulo vermelho sólido, porque o formato guarda cada pixel literalmente nos dois casos. Essa previsibilidade é o motivo de hardware pedir bitmap: um firmware que lê um consegue alocar o buffer só a partir do cabeçalho.

Duas convenções no bitmap escrito aqui parecem erro e não são. As linhas são guardadas de baixo para cima na imagem, e os canais dentro de cada pixel são ordenados azul, verde, vermelho em vez do contrário. As duas coisas estão na especificação original e são o que um leitor de arquivos BMP espera encontrar.

A terceira é o preenchimento. Toda linha é completada até um múltiplo de quatro bytes, então uma imagem de 101 pixels de largura escreve 303 bytes de pixel seguidos de um byte de nada, 304 bytes por linha. Código que lê um bitmap assumindo largura vezes três por linha produz uma imagem que desliza na diagonal, o bug mais comum num leitor de BMP escrito à mão.

O BMP guarda uma imagem só. Não tem conceito de sequência, atraso ou repetição, então um GIF animado chegando aqui vira o quadro em que ele abre e o resto é descartado — o registro declara isso como a ressalva do par em vez de deixar para ser descoberto.

Para os destinos que pedem bitmap isso raramente é problema, porque um aparelho que quer um BMP quer uma imagem estática por definição. Vale conferir se o primeiro quadro é o que você quer: muitos GIFs abrem numa tela em branco ou num cartão de título antes do conteúdo começar.

É razoável esperar que uma imagem com só 256 cores distintas produza um arquivo pequeno, e para um formato com paleta produziria. A especificação de bitmap até permite exatamente isso — um BMP de 8 bits com uma tabela de cor, que mapearia num GIF quase perfeitamente.

Este conversor não escreve um assim. Todo bitmap que ele produz é 24 bits, então um GIF usando seis cores custa os mesmos bytes que uma fotografia das mesmas dimensões. Se o aparelho que você está alimentando exige especificamente um bitmap de 8 bits com paleta em vez de só aceitar um BMP, este arquivo não vai servir, e vale estabelecer isso antes da conversão, não depois de o aparelho recusar.

Um GIF pode indicar uma entrada da paleta como transparente. O bitmap escrito aqui não tem canal alfa nenhum — 24 bits, três canais, nada sobrando — então esses pixels precisam receber um valor antes de codificar.

A opção de cor de fundo decide qual é esse valor, e o padrão é branco. Escolher de propósito importa em hardware: um ícone destinado a uma tela com interface preta deveria ser achatado sobre preto, não sobre branco e invertido depois. Onde um sistema espera uma chroma key, ajuste a opção para essa cor exata em vez de confiar num passo posterior.

Não há controle de qualidade nesta conversão e não poderia haver: sem compressão significa sem compressão, e não há nada para trocar. A única alavanca é a largura máxima, que redimensiona a imagem antes de os pixels serem escritos e portanto muda o tamanho do arquivo de forma quadrática.

Reduzir a largura pela metade divide o bitmap por quatro. Costuma ser o movimento certo quando o alvo é uma tela pequena de qualquer jeito — um painel de 128 pixels de largura não ganha nada com uma origem de 640 pixels, e reduzir aqui em vez de no firmware significa que o aparelho nem precisa manter o buffer maior.

Toda conversão raster deste site remove metadado no caminho, sem exceção, e nesta dupla essa regra tem pouco o que fazer. Um GIF não tem bloco EXIF, não tem modelo de câmera, não tem coordenada de GPS; o máximo que costuma carregar é uma extensão de comentário e uma extensão de aplicação deixadas por quem o escreveu.

O formato bitmap não tem onde colocar nada disso de qualquer jeito. O cabeçalho dele descreve dimensões, profundidade de bits e pouco mais, então o que sai são pixels e geometria. Se o GIF veio de um gravador de tela que carimbou o próprio nome num bloco de comentário, esse nome não viaja.

O GIF é decodificado pelo próprio suporte de imagem do navegador, e o cabeçalho e as linhas de pixel do bitmap são escritos em JavaScript na mesma aba. Não há servidor no caminho, sem envio e sem conta, e o arquivo some quando a aba fecha.

Isso importa mais do que parece nesta dupla, porque o que as pessoas convertem para BMP costuma ser interno: um gráfico de painel de controle, uma etiqueta de produto, a tela de abertura de um instrumento. Nada disso precisa passar pela infraestrutura de outra pessoa para virar um bitmap.