Converter ICO para BMP

Os dois vêm da Microsoft e foram desenhados juntos. O formato de ícone original nem embrulhava uma imagem separada: cada entrada guardava um cabeçalho de bitmap seguido de dados de cor e uma máscara de um bit dizendo quais pixels deixar intactos. Um ICO era, literalmente, bitmaps num diretório com um estêncil grudado.

Depois os dois se separaram. Ícones ganharam um canal alfa de oito bits de verdade com o Windows XP e a capacidade de carregar um PNG a partir do Vista, que é o que arquivos de ícone modernos usam nas entradas grandes. O bitmap gerado por este conversor é a linha de base de 24 bits, que nunca ganhou nenhum dos dois. Converter um no outro é, portanto, um passo atrás em capacidade, feito porque algo do outro lado precisa disso.

O codificador escreve 24 bits por pixel: oito de azul, oito de verde, oito de vermelho, e nada além disso. Existe uma variante de cabeçalho BMP que define canal alfa, e arquivos usando ela existem, mas quase nada lê isso de forma confiável — exatamente o problema de confiabilidade que o BMP costuma ser escolhido para evitar.

Então a transparência precisa ir para algum lugar antes do codificador rodar, e o ajuste de cor de fundo decide para onde. Branco é o padrão. Escolha a cor da superfície onde o bitmap vai ser desenhado: o fundo de um banner de instalador, a cor do painel numa tela embarcada. Num ícone de teste com cantos transparentes, o resultado registrou 255,255,255 no canto, o que está correto e também é a resposta errada se o painel é cinza-escuro.

Isso não é defeito, é o motivo inteiro do BMP existir. Cada pixel ocupa três bytes independentemente do que contém, então o tamanho do arquivo é aritmética, não resultado: largura vezes três, arredondado para cima até múltiplo de quatro, vezes altura, mais 54 bytes de cabeçalho.

Para um quadrado de 256 pixels isso dá 768 bytes por linha e 196.608 bytes de pixel, totalizando 196.662. Medido contra um ícone de teste de 8.471 bytes de origem, o bitmap ficou mais de vinte e três vezes maior. Se o destino tem limite de tamanho, faça essa conta antes de converter, não depois.

O maior do arquivo. A decodificação é feita pelo leitor de ícone do seu navegador, que retorna a maior entrada do diretório — verificado montando um arquivo com desenhos de 16, 32, 48 e 256 pixels em quatro cores diferentes e convertendo com o diretório escrito em três ordens distintas. O desenho de 256 pixels saiu sempre.

As entradas menores não vão para lugar nenhum e não existe ajuste que alcance elas. Se o software que você está alimentando quer um bitmap de 32 pixels e o ícone tem uma entrada de 32 pixels, um editor de ícone como o GIMP exporta essa camada diretamente, o que dá um resultado melhor do que reduzir a versão de 256 pixels.

Dois detalhes que valem saber se você está lendo os bytes em vez de abrir o arquivo. O BMP guarda as linhas de baixo para cima, e guarda cada pixel como azul, depois verde, depois vermelho. Os dois estão na especificação e os dois costumam surpreender quem está analisando um pela primeira vez.

Cada linha também é preenchida até virar múltiplo de quatro bytes, o que importa em larguras ímpares: um bitmap de 33 pixels de largura tem 99 bytes de cor por linha e um byte de preenchimento, deixando a linha armazenada com 100. Em 256 pixels a linha tem 768 bytes e não precisa de preenchimento nenhum, um dos motivos de bitmaps do tamanho de ícone serem fáceis de trabalhar à mão.

Porque ler um não exige decodificador nenhum. Um microcontrolador ligado a uma tela pequena consegue copiar bytes de um arquivo para um framebuffer com um laço e um deslocamento de cabeçalho; adicionar um decodificador de PNG a esse firmware significa adicionar um descompressor, um alocador de memória e um analisador de blocos a um dispositivo que talvez tenha 32 KB de RAM.

O mesmo raciocínio vale para recurso de instalador, para controle antigo do Windows que carrega recurso pelas próprias funções de bitmap da plataforma, e para teste automatizado que quer comparar imagem byte a byte sem um codec no meio do caminho. Em todos esses casos, previsibilidade vale muito mais que tamanho.

Os dois formatos são sem perdas, e este caminho não tem ajuste de qualidade porque não há nada para negociar. Todo pixel que sobrevive ao achatamento é exatamente o que o ícone guardava, então converter o mesmo arquivo duas vezes dá o mesmo resultado, e não há perda de geração para se preocupar se passar pela etapa de novo depois.

As duas coisas que de fato se perdem são o canal alfa, substituído pela cor de fundo, e as outras entradas do contêiner. Nenhuma das duas é recuperável a partir do bitmap depois, o que é o argumento para guardar o arquivo de ícone original em vez de substituir ele.

Se o destino é software moderno com uma preferência declarada em vez de uma exigência dura, um PNG é menor em duas ordens de grandeza e mantém a transparência. O mesmo ícone de teste ficou em 1.737 bytes como PNG contra 196.662 como bitmap — uma diferença grande o bastante para valer um e-mail perguntando se o BMP é mesmo obrigatório.

Onde a resposta é sim — firmware, um script de instalador, um teste com comparação byte a byte — o bitmap está certo e o tamanho é o preço de ser legível sem decodificador. Diga isso na mensagem do commit, porque um arquivo de 200 KB para um ícone pequeno parece um erro para quem revisar depois.

Solte o conjunto inteiro. Cada arquivo é decodificado, achatado sobre a mesma cor de fundo e gravado separadamente, com tudo retornando num ZIP. Um fundo compartilhado no lote costuma ser o que esses destinos precisam, já que as imagens estão sendo compostas sobre uma mesma superfície.

Confira as dimensões no resultado em vez de supor que batem. Um conjunto de ícones montado ao longo dos anos mistura entrada que chega a 256 pixels com entrada que para em 32, e os bitmaps herdam essa dispersão — com um fator de sessenta e quatro entre os tamanhos de arquivo nos dois extremos.