As discussões sobre formatos costumam começar no codec e trabalhar de dentro para fora. Está ao contrário. O formato certo decide-se pelo que está na imagem e só depois pelo que o sistema que a recebe aceita.
Fotografias: JPEG ou WebP
As imagens de tom contínuo — rostos, paisagens, tudo o que tenha gradientes e ruído — comprimem-se bem com codecs com perdas, porque o olho tolera pequenos erros nas zonas com muita informação. O JPEG é a predefinição segura porque toda a gente o aceita. O WebP com perdas atinge a mesma qualidade percecionada com bastante menos bytes, por isso ganha sempre que o destino o permita.
Uma ressalva, se estiveres a usar o ToolZool para isto: o nosso compressor escreve WebP apenas no modo sem perdas, o que numa fotografia produz um ficheiro várias vezes maior do que o JPEG seria. Para uma fotografia com um limite de tamanho, escolhe aqui o JPEG. A razão desta diferença está na página do próprio compressor — não há nenhum codificador de WebP com perdas que possamos distribuir sem esbarrar numa licença incompatível ou numa cadeia de compilação em C.
Gráficos planos e texto: PNG
Logótipos, ícones, diagramas e capturas de ecrã de interfaces são feitos de arestas duras e de grandes áreas de cor idêntica. Os codecs com perdas lidam mal com arestas duras: aparecem halos visíveis à volta do texto e, como o ruído que introduzem é ele próprio caro de codificar, o ficheiro acaba muitas vezes maior do que um PNG sem perdas da mesma imagem.
A transparência decide por ti
O JPEG não tem canal alfa. Converte um PNG transparente para JPEG e as zonas transparentes ficam opacas — normalmente a preto, às vezes a branco, raramente como querias. O PNG e o WebP suportam ambos canal alfa, por isso, se a imagem tem transparência, a lista fica reduzida a esses dois.
Onde é que o AVIF encaixa
O AVIF bate o WebP em tamanho de ficheiro para a mesma qualidade, sobretudo em taxas de bits baixas, e todos os navegadores atuais o conseguem mostrar. O problema é a codificação: é dramaticamente mais lenta e muito mais pesada de correr do que a do JPEG ou a do WebP, o que conta quando a codificação acontece num telemóvel e não num servidor de compilação.
Hoje, o ToolZool não lê nem escreve AVIF. Os dois sentidos precisam de um codec AV1, e todos os que são mantidos são bibliotecas em C que não compilam para WebAssembly — por isso um ficheiro AVIF tem de ser convertido noutro sítio primeiro. O mesmo se aplica ao HEIC, que a maioria dos iPhones produz por predefinição.
A pergunta que se sobrepõe a tudo isto
O que é que o formulário aceita? Um formato melhor que acaba rejeitado não é melhor. Lê primeiro a lista de formatos aceites e otimiza dentro dela — e se um ficheiro que parece cumprir tudo continuar a ser recusado, porque é que um formulário rejeita o teu ficheiro percorre as quatro verificações que um formulário faz de facto. Se precisares de andar entre formatos, o compressor de imagem lê JPG, PNG e WebP e escreve JPEG, PNG ou WebP sem perdas, por isso também serve de conversor dentro desse conjunto.
