Converter BMP para AVIF

Um arquivo AVIF é, na estrutura, um quadro parado de vídeo AV1 dentro de um contêiner especificado em 2019. Ele herda o trabalho de compressão de um codec de vídeo moderno, e é por isso que costuma superar WebP e JPEG em fotografia na mesma qualidade visível.

Herda também o custo. A codificação lenta é o ponto fraco conhecido do formato, e o comportamento aqui confirma isso: numa foto grande, decodificar é a etapa mais demorada em qualquer outra conversão, mas nesta é codificar. Um bitmap de doze megapixels — uma imagem de 4000 por 3000, 36 MB como BMP — demora o suficiente para a barra de progresso estar fazendo trabalho de verdade. É o inverso do que se espera: o bitmap é o arquivo enorme e barato de ler; o AVIF é o arquivo minúsculo e caro de escrever.

AVIF guarda até doze bits por canal e descreve espaços de cor amplos. Essas duas capacidades explicam boa parte da razão de o formato existir, e são o motivo de ele ser usado para entregar fotografia em HDR.

Um BMP guarda oito bits por canal em RGB simples. Não há gama de cor mais ampla na origem, não há alcance dinâmico extra, não há perfil de cor — o formato não carrega nenhum contêiner de metadado. A folga do AVIF fica vazia, e o único ganho real desta conversão é a compressão. É um ganho de verdade, só vale saber que é o único, porque boa parte do que se escreve sobre AVIF fala de recursos que um bitmap não alcança. Um formato nunca adiciona informação: só descreve o que chegou, e o que chega aqui é sRGB de oito bits de um formato que a Microsoft publicou em 1987.

Ela roda como WebAssembly dentro da aba do navegador, no processador que a máquina tem. Não existe servidor fazendo esse trabalho, motivo pelo qual nada é enviado e também motivo pelo qual um lote de bitmaps grandes é algo que se inicia e volta a conferir depois.

Na prática: uma imagem média já é uma espera perceptível, e uma pasta com quarenta digitalizações de scanner é hora de café. Se isso for inaceitável e o público for amplo mesmo assim, o WebP fica a uma página de distância e codifica numa fração do tempo, para um arquivo que costuma ficar próximo do AVIF em tamanho. Nada aqui é defeito da conversão — a mesma codificação num servidor levaria trabalho equivalente, só que seria o processador de outra pessoa, e o seu arquivo teria que viajar até lá. O tempo é o preço honesto de a imagem nunca sair da máquina.

AVIF é classificado como suportado por navegadores modernos, e essa palavra pesa bastante ao lado do "todos" que WebP e JPEG recebem. Navegadores atuais de desktop e celular leem AVIF; aparelhos mais antigos, alguns navegadores embutidos em aplicativos e boa parte dos programas de e-mail não.

Isso torna o AVIF um formato para servir num site, não para enviar por anexo. Como anexo ou arquivo entregue a outra pessoa é uma escolha ruim, e o fato de abrir na sua máquina não diz nada sobre a dela. A mesma cautela vale para programas de design: o suporte chegou de forma desigual, e um AVIF que o navegador exibe perfeitamente pode ser um arquivo que um colega não consegue nem colar num documento.

O mecanismo que torna essa lacuna administrável é o elemento `picture`: várias fontes listadas em ordem, cada uma com seu tipo, e o navegador usa a primeira que consegue decodificar. Coloque o AVIF primeiro, um WebP depois e um JPEG por último, e cada visitante recebe o menor arquivo que o navegador dele realmente consegue abrir, sem código de detecção nenhum.

Isso significa converter o mesmo bitmap duas vezes, e é por isso que o lote nesta página costuma rodar junto do lote para WebP. Vale fazer nessa ordem em vez de gerar o AVIF a partir do WebP: cada codificador com perdas toma suas próprias decisões sobre o que descartar, e empilhar dois deles produz um arquivo carregando as duas perdas sem economizar nada. Sempre gere cada formato de entrega a partir do bitmap original.

AVIF carrega canal alfa, e nada neste caminho achata a imagem ou pede uma cor de fundo, então um bitmap de 32 bits mantém suas áreas transparentes. Os arquivos de 24 bits, que são a maioria do que chega aqui, não têm nada a manter.

O controle de qualidade parte de 82, o mesmo número que todo destino com perdas deste site oferece, e vale lembrar que essa escala pertence ao codificador, não à imagem. Oitenta e dois no AVIF e oitenta e dois no JPEG não representam a mesma perda nem o mesmo tamanho de arquivo, então comparar dois formatos é comparar as saídas, não os ajustes. O AVIF também falha de um jeito diferente: onde o JPEG quebra em blocos e cria contorno ao redor das bordas, o AVIF suaviza a textura fina, o que é menos óbvio e mais fácil de passar despercebido até colocar a imagem ao lado do original.

Quando o público inclui aparelhos antigos. Quando a imagem é pequena o suficiente para a diferença ser de poucos kilobytes. Quando o material é arte plana com bordas duras, onde a vantagem do AVIF encolhe e pode até inverter. E quando você está convertendo centenas de arquivos e o tempo de codificação é o que realmente pesa.

O AVIF compensa o custo em imagens fotográficas grandes servidas a um público moderno através do elemento `picture`. Isso é um caso específico, não um padrão automático. O teste que resolve a dúvida custa um minuto: converta um bitmap representativo para os dois formatos, compare o tamanho e decida se a diferença justifica codificar cada arquivo duas vezes e manter uma opção reserva no HTML. Às vezes claramente vale a pena; muitas vezes claramente não.

É o único ajuste que melhora o tamanho do arquivo e o tempo de codificação ao mesmo tempo, e é proporcional à contagem de pixels, não à largura — cortar a largura de um bitmap pela metade remove três quartos dos pixels que o codificador precisa processar.

Defina a largura máxima como a maior largura em que a imagem vai realmente ser exibida, dobrada para telas de alta densidade. Uma digitalização de 4000 por 3000 reduzida para 2000 por 1500 ainda é maior do que quase todo lugar onde vai aparecer, e a codificação AVIF dela termina em aproximadamente um quarto do tempo.

Solte a pasta toda e cada arquivo converte em sequência na sua própria máquina, mantendo o nome com a extensão trocada, com o conjunto devolvido num único ZIP. O teto é 100 MB por arquivo, o que dá cerca de 33 megapixels de bitmap sem compressão.

Planeje o lote pensando na codificação, não no download. Os arquivos são processados um após o outro, então o tempo total é aproximadamente a soma das codificações individuais, e as imagens maiores dominam esse total — um único bitmap de 33 megapixels pode demorar mais que trinta pequenos juntos. Separar os arquivos claramente grandes demais e redimensioná-los antes vale mais do que qualquer outro ajuste possível num lote como este.

AVIF é um formato de entrega e esta conversão tem perdas. O que sai é dimensionado e codificado para o lugar onde vai ser exibido, e não existe caminho de volta dele até os pixels que o bitmap tinha.

Se o BMP é sua única cópia, guarde-o ou converta-o para PNG primeiro — essa direção é exata e custa uma fração do espaço em disco. Depois produza o AVIF a partir do arquivo mestre sempre que o destino mudar, em vez de converter um arquivo de entrega em outro arquivo de entrega e empilhar as perdas de um codificador sobre as de outro.