Converter BMP para WebP

Um bitmap de 1920 por 1080 pesa 6,2 MB, e pesa isso seja uma fotografia ou um banner de cor lisa, porque o formato escreve três bytes por pixel e não comprime nenhum. Coloque isso numa página e ele vira a página inteira: HTML, CSS, fontes e scripts somados não chegam perto.

O WebP foi pensado exatamente para esse lugar dentro de uma página. Ele gasta bits onde há detalhe e nada onde não há, e é por isso que a mesma imagem chega em dezenas ou centenas de kilobytes em vez de milhões. Não é uma otimização de margem: é a diferença entre uma página que carrega no celular e uma que não carrega, e entre uma medição de maior renderização de conteúdo que passa e uma que não passa, já que numa página com imagem no topo é essa imagem que a métrica cronometra.

WebP pode ser sem perdas — o formato carrega os dois modos, e é uma das razões de ele existir. O codificador desta página escreve a variante com perdas, na qualidade 82 por padrão, porque é isso que uma imagem publicada deve ser.

Vale deixar claro, porque significa que esta conversão não é reversível. Se o que você queria era uma cópia exata do bitmap num contêiner menor, esta é a página errada e PNG é a certa. Se a imagem vai para um site, perdas é a resposta correta, e o único número que importa pensar é a qualidade — 82 já é alto o suficiente para a maioria não notar diferença no tamanho normal de exibição. O lugar para prestar atenção não é esse ajuste, é a dimensão da imagem, que aparece adiante e pesa muito mais.

WebP carrega canal alfa mesmo no modo com perdas, o que é incomum, e é o argumento mais forte para escolher WebP em vez de JPEG nesta origem. Nada nesta conversão achata a imagem nem pede uma cor de fundo, porque não precisa.

A maioria dos arquivos BMP é de 24 bits e não tem alfa nenhum a preservar, então para eles a questão nem se coloca. Mas as variantes de 32 bits carregam um, e um logotipo ou elemento de interface exportado por uma ferramenta antiga do Windows é exatamente o tipo de arquivo que tem isso. Enviado para JPEG, essa transparência vira branco. Enviado para WebP, continua transparência, em 256 níveis em vez do único valor ligado ou desligado que o GIF daria, então uma borda suavizada continua esmaecendo de forma correta contra o que a página colocar atrás.

Este é um limite do formato, não deste conversor, e é a única coisa que pode tornar a conversão impossível em vez de apenas gerar perdas. Nenhuma dimensão de um WebP pode passar de 16.383 pixels.

Imagem comum não chega nem perto — uma fotografia de 4000 por 3000 tem folga de sobra. O que alcança esse limite é justamente o que costuma chegar como BMP: um documento grande digitalizado em alta resolução, um panorama montado, a saída de um instrumento científico que produz uma faixa bem larga. Se o seu bitmap é um desses casos, reduza a largura antes ou use PNG, cujo teto próprio passa de dois bilhões de pixels de lado. Vale conferir as dimensões antes de converter um lote inteiro, porque um único arquivo que não vira WebP é uma confusão maior do que um que sai maior do que o esperado.

O WebP saiu do Google em 2010 e passou a primeira década com um asterisco ao lado do nome. Isso acabou: está em todo navegador atual, tem especificação própria, e ferramentas de design e edição de conteúdo o leem sem problema.

Isso muda o que a decisão nesta página é sobre. Não é mais se o público consegue ver a imagem, é só se perdas são aceitáveis para essa imagem em particular. É uma pergunta bem mais fácil, e para quase tudo que vai ser publicado a resposta é sim. O AVIF, a alternativa mais recente, ainda é classificado como suporte moderno — não universal —, e essa diferença de uma palavra é o que importa na hora de escolher o que publicar sem uma opção reserva.

O erro mais comum nesta direção é converter um bitmap nas dimensões originais e colocar numa coluna de 600 pixels. O navegador baixa várias vezes mais dados do que consegue mostrar e descarta o resto na tela, e nenhum ajuste de codificação recupera isso.

Defina a largura máxima como a maior largura em que a imagem vai realmente ser exibida, dobrada se precisar ficar nítida numa tela de alta densidade. O redimensionamento acontece na mesma etapa de tudo o mais aqui, então a imagem é escalada uma única vez, e a economia é proporcional à quantidade de pixels, não à largura — cortar a largura pela metade remove três quartos dos dados.

Boa parte dos arquivos BMP são capturas de tela, e codificadores com perdas lidam mal com texto — as bordas duras das letras são exatamente o tipo de detalhe que eles são feitos para descartar. Isso é um argumento forte contra JPEG para esse material, e um argumento mais fraco contra WebP, que lida melhor com bordas afiadas no mesmo ajuste, mas não faz isso de graça.

Para um print que precisa continuar legível, a ordem honesta é PNG primeiro, depois WebP com qualidade elevada, e JPEG bem atrás. O PNG costuma sair menor também, já que regiões planas e bordas duras são exatamente o que a compressão sem perdas faz melhor e a com perdas faz pior — então nesse material a troca de sempre nem se aplica. Para uma fotografia, WebP em 82 sem ajuste é a resposta certa e a ordem deixa de importar.

O formato BMP não registra nenhum contêiner de metadado: sem EXIF, sem XMP, sem perfil ICC embutido. O WebP consegue carregar os três, e não há nada na origem para preencher.

Para uma imagem web isso costuma ser conveniente — o arquivo fica do tamanho que os pixels permitem e não carrega nada que identifique a origem. Isso importa se o bitmap saiu de um fluxo de trabalho com gestão de cor e precisava ser interpretado num espaço específico, porque o WebP será lido como sRGB e nada neste caminho diz o contrário.

Solte a pasta inteira. Cada bitmap é decodificado e recodificado em sequência na sua própria máquina, mantém o nome com a extensão trocada, e o conjunto todo volta como um único ZIP. Não há fila, conta ou limite diário, e o teto por arquivo é de 100 MB.

Fazer isso localmente pesa mais aqui do que a velocidade. Imagens de um site que ainda não foi lançado, fotos de produto sob embargo, print de uma ferramenta interna — tudo isso seria entregue a terceiros em troca de uma compressão que você mesmo consegue rodar.

Cada arquivo convertido mantém o nome original com a extensão trocada, o que é o que torna um lote útil, mas também é onde o trabalho ainda não terminou. Toda referência ao arquivo antigo — num template, numa folha de estilo, num registro de conteúdo — continua apontando para um nome terminado em .bmp, e uma imagem quebrada é uma falha bem mais visível do que uma pesada.

A outra metade é lembrar de remover os bitmaps do que for de fato publicado. Um build que copia uma pasta de assets inteira sem filtro vai enviar as duas cópias, e os megabytes que esta conversão deveria eliminar continuam sendo transferidos em algum lugar. Converta, atualize as referências, apague os originais do projeto, e mantenha os bitmaps fora dele se forem seus únicos arquivos mestres.