JPEG, PNG, WebP ou AVIF: que formato e porquê

Duas perguntas, e o formato sai delas

Pergunta um: a imagem é fotográfica ou de tons chapados? Fotográfica significa tom contínuo — pele, céu, folhagem, ruído de sensor, nenhuma zona onde o valor salte de um píxel para o seguinte. De tons chapados significa o contrário: capturas de ecrã, logótipos, gráficos, esquemas, traço, texto, tudo o que tenha grandes áreas uniformes e arestas duras entre elas. Não é um rótulo estilístico. É uma descrição estatística dos píxeis, e as duas famílias de compressão foram construídas para estatísticas opostas.

Pergunta dois: a imagem precisa de canal alfa ou de animação? O JPEG não tem nenhum dos dois e nunca terá. O PNG tem alfa e só anima através de APNG, uma extensão ausente da especificação original. WebP e AVIF têm ambos alfa e ambos animam. Se for preciso pousar um logótipo sobre um fundo desconhecido, o JPEG fica de fora antes de começar a conversa sobre tamanho — um logótipo JPEG chega com um retângulo de fundo incrustado.

O que a DCT e o DEFLATE fazem realmente aos píxeis

O JPEG corta a imagem em blocos de 8 × 8 e reescreve cada bloco como uma soma de ondas cosseno, depois divide esses coeficientes por uma tabela de quantização e arredonda. O detalhe fino vive nos coeficientes de alta frequência, precisamente os que a tabela divide com mais força: arredondam para zero e desaparecem. Uma fotografia tolera-o porque as suas altas frequências são em grande parte ruído. Uma aresta dura não: um degrau abrupto exige muitos termos de alta frequência, e ao apagá-los a reconstrução ultrapassa e fica aquém de cada lado da aresta. É o halo, e é por isso que o texto num JPEG parece desfocado nos bordos mesmo em alta qualidade.

O efeito é mensurável e estritamente local às arestas. Na nossa imagem de teste chapada tomámos uma banda de 1040 píxeis de largura por 70 de altura em torno do título. No original, 56 119 píxeis dessa banda valem exatamente 255,255,255. Após uma única passagem JPEG em qualidade 75, 6 352 deles — 11,3 % — já não são branco puro, com um desvio até 14 níveis. Numa banda branca vazia de 86 400 píxeis longe de qualquer aresta, nem um píxel mudou. O JPEG não degrada a imagem de forma uniforme: degrada-a exatamente onde vive o desenho chapado.

O PNG funciona ao contrário. Prevê cada píxel a partir dos vizinhos, subtrai a previsão e entrega os resíduos ao DEFLATE — o mesmo algoritmo de um ficheiro zip. Uma sequência de píxeis idênticos comprime-se a quase nada, e por isso uma captura de ecrã encolhe tão bem. Uma fotografia não tem sequências: cada píxel difere ligeiramente do vizinho, os resíduos são ruído e o DEFLATE não tem onde agarrar. É toda a explicação dos 2 021 576 bytes que a nossa fotografia exigiu em PNG contra 311 380 em JPEG.

As mesmas duas imagens, quatro codificadores, medidos

Na fotografia a ordem é a que toda a gente espera. PNG 2 021 576 bytes, JPEG em qualidade 75 311 380, AVIF na qualidade 75 do codificador 174 774, WebP com perdas em qualidade 75 105 608. Mas leia esse último par com cuidado antes de concluir: a qualidade 75 de um codec não é a qualidade 75 de outro. Esse número é um índice no quantizador próprio desse codificador, nada mais. Estes valores dizem apenas que estes dois codificadores, com ajustes nominalmente idênticos, caíram em pontos diferentes da curva tamanho-qualidade — não que o WebP vença o AVIF. Qualquer comparação honesta entre dois codecs fixa primeiro uma métrica de qualidade e só depois compara bytes, e é um exercício bem mais longo do que o desta página.

A captura chapada é onde ocorre a inversão interessante. PNG 88 693 bytes. JPEG com o mesmo ajuste de qualidade 75: 152 065 bytes — 1,71 vezes o PNG, e ainda a deitar píxeis fora. WebP com perdas: 40 060 bytes. WebP sem perdas: 36 074 bytes, ao mesmo tempo mais pequeno do que a versão com perdas e exato ao píxel. Não é uma anomalia. O WebP com perdas subamostra sempre a crominância para 4:2:0: o texto colorido e os filetes finos coloridos perdem metade da resolução de cor horizontal e vertical, e o codificador gasta depois bits a reconstruir arestas que ele próprio acabou de desfocar. Em desenho chapado, o sem perdas é frequentemente ao mesmo tempo mais pequeno e melhor.

A porta de sentido único — e o mito de voltar a guardar

A perda é realmente de sentido único. Convertemos o nosso original PNG para JPEG qualidade 75 e de volta a PNG: o PNG devolvido pesa 1 470 130 bytes, contra 2 021 576 do original. É mais pequeno porque a passagem JPEG alisou detalhe para fora da imagem, e nenhum codificador PNG o pode repor. A partir daí o ficheiro é sem perdas, mas guarda sem perdas uma imagem danificada. PNG → JPEG → PNG nunca devolve o original, e o tamanho menor é a prova, não um bónus.

A versão popular — que cada novo guardar agrava os estragos — revela-se falsa tal como é habitualmente enunciada, e medimo-lo. Recodificar dez vezes o mesmo JPEG com o ajuste de qualidade idêntico, sem recorte, sem redimensionamento e sem retoque entre passagens, moveu o erro absoluto médio de 1,7591 para 1,7670 níveis. É uma deriva de oito milésimos de nível em dez gerações: a requantização JPEG está perto de um ponto fixo enquanto a grelha 8 × 8 se mantiver alinhada e a tabela de quantização não mudar.

Mude o que quer que seja entre gravações e a acumulação é imediata. Repetimos a cadeia com um pequeno recorte centrado antes de cada gravação, o que desloca a imagem em relação à grelha 8 × 8. Ao fim de seis ciclos, o erro absoluto médio face a uma codificação de passagem única do mesmo recorte tinha subido de 1,76 para 2,32 níveis — mais 32 % de erro — enquanto codificar esse mesmo recorte uma só vez a partir do original intacto ficava plano em cerca de 1,77, fosse qual fosse o ciclo comparado. A regra prática não é, portanto, «nunca voltar a gravar»: guarde o original sem perdas, edite sempre a partir dele e exporte para JPEG ou WebP como último passo, não como ficheiro de trabalho.

Alfa, profundidade de bits e os tetos que ninguém menciona

O PNG guarda até 16 bits por canal; o JPEG, tal como os navegadores o implementam, 8. O WebP é de 8 bits em ambos os modos, e o seu modo com perdas é sempre 4:2:0. O AVIF chega a 10 e 12 bits e pode codificar em 4:4:4, e por isso é o único dos quatro que lida com um degradê largo e suave sem bandas, e o único com uma resposta real para HDR. Se a sua imagem é um céu de fim de tarde ou um fundo de produto muito suave, essa profundidade vale mais do que qualquer tamanho da tabela acima.

O WebP tem um teto duro que surpreende à primeira vez: o contentor codifica largura e altura em 14 bits, pelo que nenhum WebP pode passar de 16 383 píxeis de lado. Irrelevante para uma fotografia web, fatal para um mapa digitalizado ou um panorama longo costurado. O AVIF e o PNG não têm limite comparável nos tamanhos que irá produzir. Vale a pena saber antes de montar um pipeline que converta tudo para WebP por omissão.

Suporte e custo de codificação, e a regra que daí resulta

O suporte já não é o fator decisivo que era há cinco anos. O WebP chegou ao Chrome há muito, ao Firefox 65 em janeiro de 2019 e ao Safari 14 em setembro de 2020. O AVIF chegou ao Chrome 85 em agosto de 2020, ao Firefox 93 em outubro de 2021, ao Safari 16 em setembro de 2022 e por fim ao Edge 121 em janeiro de 2024 — o Edge foi o último grande navegador a aderir. Qualquer versão atual de qualquer navegador principal descodifica os dois. Resta uma cauda longa de sistemas antigos que já não podem atualizar o navegador: é exatamente para isso que existe o elemento picture com várias fontes e um recurso JPEG.

O que aperta agora é o custo de codificação. Na mesma máquina e na mesma fotografia de 1600 × 900, melhor de cinco execuções: WebP 287 ms, AVIF 1 163 ms, JPEG 119 ms. O AVIF demorou quatro vezes mais do que o WebP, e quase dez vezes mais do que o JPEG produzido pela mesma ferramenta. Estão envolvidos codificadores diferentes — cwebp para WebP, a estrutura de imagem do sistema para AVIF e JPEG — pelo que trate a razão exata como indicativa, não universal. A direção, essa, não está em dúvida: o AVIF é codificação intra AV1, explora um espaço muito maior e é lento por construção. Num lote de cem mil imagens isso é uma verba real, e é por isso que muitas equipas ficam pelo WebP.

A regra que decorre de tudo isto cabe em três linhas. Fotografia sem transparência: WebP ou AVIF, com o JPEG atrás para clientes antigos. Captura de ecrã, logótipo, gráfico, tudo o que seja chapado: WebP sem perdas primeiro, PNG como recurso seguro, e nunca JPEG. Tudo o que precise de alfa ou animação: WebP ou AVIF, ou PNG se a paleta for pequena e o sem perdas contar mais do que os bytes.

Perguntas frequentes

O WebP é sempre mais pequeno do que o JPEG?

Não. Costuma sê-lo em fotografias, e na nossa foi 66 % mais pequeno com um ajuste nominalmente igual — mas esses ajustes não são comparáveis entre codecs, e um JPEG já muito comprimido pode crescer ao passar a WebP, porque o codificador tem agora de reproduzir os blocos do JPEG como se fossem detalhe. Meça sempre nas suas próprias imagens em vez de confiar numa percentagem de manchete.

Converter um JPEG antigo para WebP ou AVIF restaura a qualidade?

Não pode. O detalhe que o JPEG descartou não está no ficheiro, pelo que nada a jusante o pode recuperar. Converter continua a valer a pena para poupar largura de banda, e um bom codificador não acrescentará muitos estragos novos, mas o teto é fixado pelo JPEG de partida. Se o raw ou o PNG original ainda existir, reexporte a partir daí — não custa nada mais e o resultado é realmente melhor.

Devo continuar a publicar JPEG?

Como recurso dentro de um elemento picture, sim — custa um ficheiro extra e cobre qualquer aparelho alguma vez construído. Como formato principal para trabalho novo, já não há caso fotográfico em que o JPEG ganhe em tamanho a qualidade igual, nem caso chapado em que ganhe de todo. Continua também a ser o mais seguro para entregar a alguém que o abrirá em software desconhecido, e por isso os anexos de e-mail e as gráficas ainda o preferem.

PNG-8 ou PNG-24 para um logótipo?

O PNG-8 guarda uma paleta indexada de no máximo 256 cores e fica bastante mais pequeno quando o desenho tem mesmo poucas cores — a maioria dos logótipos chapados. O PNG-24 guarda cor completa e só é preciso para degradês ou sombras suaves. Verifique o resultado em vez do rótulo: se a versão com paleta for visualmente idêntica, fique com ela. E compare ambas com o WebP sem perdas, que bateu o PNG em 59 % na nossa imagem chapada de teste.

O AVIF compensa o tempo extra de codificação?

Depende inteiramente de quantas vezes cada ficheiro é codificado face a quantas é servido. Uma imagem de destaque codificada uma vez e entregue um milhão de vezes: codifique-a em AVIF e aceite o segundo extra. Conteúdo enviado por utilizadores e codificado a pedido: quatro vezes o CPU por imagem é um custo operacional sério, e o WebP é a escolha pragmática. O AVIF também ganha o seu lugar em degradês largos e suaves, onde os seus modos de 10 e 12 bits evitam bandas que os formatos de 8 bits não conseguem.

Porque é que o WebP sem perdas bateu o WebP com perdas na captura?

Porque a codificação com perdas é a ferramenta errada para esses dados. A captura é feita sobretudo de longas sequências de píxeis idênticos, que o modo sem perdas codifica quase de graça, enquanto o modo com perdas primeiro subamostra a cor e depois gasta bits a descrever as arestas que desfocou. Medimos 36 074 bytes sem perdas contra 40 060 com perdas — mais pequeno e exato ao píxel. Se a sua imagem for chapada, experimente o sem perdas antes de mexer no cursor de qualidade.