Como os Algoritmos de Compressão de Imagem Funcionam: DCT, LZW e AVIF

Última atualização: July 26, 2026

A compressão de imagens encolhe um arquivo removendo informações que o seu olho tem dificuldade em notar. Os algoritmos por trás do JPEG, PNG, GIF, WebP e AVIF não são mágica — eles são uma pilha de etapas mecânicas específicas. Entender isso diz por que um JPEG com qualidade 80 parece bom, por que o PNG incha em uma fotografia e por que o AVIF codifica tão lentamente. Este é um guia prático sobre a matemática real, e não um concurso de popularidade de formatos.

Resposta rápida: como funcionam os algoritmos de compressão de imagens?

Todo formato executa as mesmas três tarefas em sequência. Primeiro, ele transforma os pixels para que as informações importantes se concentrem em alguns números. Segundo, ele quantiza — arredonda os números que contribuem menos (esta é a parte com perdas, e formatos sem perdas pulam isso). Terceiro, ele codifica a entropia os valores restantes para que os valores frequentes ocupem menos bits do que os raros.

A divisão entre os formatos ocorre principalmente na primeira etapa. JPEG e AVIF usam uma transformada de frequência (DCT). PNG e WebP-lossless usam filtragem preditiva. GIF usa codificação de dicionário (LZW). As taxas de compressão que você vê no campo são determinadas pela inteligência com que cada formato descarta ou empacota os dados.

Qual é a diferença entre compressão com perdas (lossy) e sem perdas (lossless)?

A distinção mais importante na compressão de imagens é se os dados são descartados.

Compressão sem perdas reconstrói o pixel original por pixel. Ela só pode remover redundância — bytes repetidos, gradientes previsíveis, sequências de cores idênticas. Seu limite é a entropia da imagem: ruído aleatório puro mal se comprime. PNG, GIF e WebP-lossless vivem aqui.

Compressão com perdas descarta informações permanentemente, apostando que o que remove está abaixo do seu limiar perceptivo. A aposta geralmente recai sobre detalhes de alta frequência (textura fina, bordas) e sobre resolução de cor (seus olhos leem o brilho muito mais nitidamente do que a tonalidade). JPEG, WebP-lossy, AVIF e HEIC vivem aqui.

O retorno é dramático. Para uma fotografia típica, a saída com perdas é frequentemente 5 a 10 vezes menor do que o equivalente sem perdas em um nível de qualidade que a maioria dos visualizadores não consegue distinguir do original. O custo é a irreversibilidade: cada recodificação com perdas acumula artefatos, razão pela qual você deve manter um arquivo mestre limpo.

Como funciona realmente a compressão DCT do JPEG?

JPEG é o pipeline clássico com perdas. Ele opera em cinco estágios, e a Discrete Cosine Transform (DCT) é o coração dele. Os cinco estágios são:

Aqui está um exemplo concreto do passo DCT. Pegue um bloco de 8x8 onde cada pixel tem o mesmo valor de luminância de 200. O codificador primeiro faz um level-shift subtraindo 128, deixando um bloco plano de 72. A 2D DCT então produz 64 coeficientes — mas porque a entrada é perfeitamente plana, apenas o coeficiente superior esquerdo (o termo DC) não é zero, e ele é igual a 8 vezes 72, ou 576. Os outros 63 coeficientes são exatamente zero.

Agora o passo com perdas. A matriz de quantização de luminância padrão do JPEG divide o coeficiente DC por 16, resultando em 36, e divide cada coeficiente AC de alta frequência por um número maior. Como os coeficientes AC já são zero, a quantização não muda nada aqui. Após a ordenação zigzag, todo o bloco de 64 valores é armazenado como um único valor DC de 36 seguido por um marcador de fim de bloco. Sessenta e quatro pixels se tornaram aproximadamente dois números.

É por isso que regiões planas de um JPEG se comprimem tão bem. O modo de falha é o oposto: um bloco com uma borda vertical nítida espalha energia em muitos coeficientes AC. A quantização zera os de alta frequência, a borda suaviza e, em baixa qualidade, você vê os clássicos artefatos de blocos 8x8. Para o detalhamento completo estágio por estágio, incluindo matemática de chroma subsampling, veja o artigo relacionado image compression deep dive.

O que são codificação Huffman e compressão de entropia?

Depois que o DCT e a quantização transformam um bloco em um fluxo de inteiros majoritariamente pequenos (com longas sequências de zeros), o estágio final empacota esses inteiros no mínimo de bits possível. Isso é codificação de entropia, e a codificação Huffman é o motor principal.

A codificação Huffman atribui códigos binários curtos a valores frequentes e códigos longos a valores raros. Se o valor zero aparecer 60 por cento das vezes em seus dados quantizados, ele pode receber um código de 2 bits, enquanto um coeficiente grande raro recebe 12 bits. O formato armazena uma tabela de códigos no início para que o decodificador possa reverter isso. Este passo é totalmente reversível — não introduz perdas — mas é onde aparece a maior parte da economia de bytes, porque a quantização produz exatamente a distribuição enviesada que a codificação Huffman explora.

As camadas JPEG usam run-length encoding em cima: uma sequência de quinze coeficientes zero idênticos é codificada como um único símbolo de pulo em vez de quinze valores separados. O artigo Wikipedia sobre JPEG documenta a ordem exata de varredura zigzag e a estrutura da tabela Huffman se você quiser implementar por conta própria.

Formatos modernos vão além. WebP e AVIF podem usar codificação aritmética, que extrai aproximadamente 5 a 10 por cento a mais do que o Huffman ao custo de uma decodificação mais lenta. Brotli, usado em outro lugar no transporte web, combina um modelo de contexto maior com Huffman; a especificação Brotli (RFC 7932) vale a pena ler para ver como é construído um codificador de entropia moderno.

Como PNG e GIF usam LZW e Deflate?

Formatos sem perdas não podem quantizar, então dependem inteiramente de encontrar e remover redundância. PNG e GIF seguem rotas diferentes.

PNG executa duas etapas. Primeiro, filtragem por linha: cada linha de varredura é transformada usando um dos cinco preditores (None, Sub, Up, Average, Paeth), armazenando a diferença entre cada pixel e um palpite baseado em vizinhos em vez do valor bruto. Em um gradiente suave, essas diferenças são pequenas, agrupadas perto de zero e muito mais fáceis de comprimir. Segundo, Deflate: os bytes filtrados passam pelo LZ77, que substitui sequências de bytes repetidos por referências retroativas, seguidos pela codificação Huffman. Deflate é o mesmo algoritmo usado pelo ZIP.

GIF segue um caminho mais simples com LZW (Lempel-Ziv-Welch). LZW constrói um dicionário de padrões em tempo real: ele começa com todos os valores de byte únicos e, à medida que lê os dados, adiciona sequências cada vez mais longas que já viu. Quando uma sequência se repete, ela é emitida como um único índice de dicionário. LZW é rápido e não precisa de tabela de código armazenada, razão pela qual o GIF podia decodificar em hardware dos anos 90.

A verdadeira limitação do GIF não é a compressão. É a paleta de cores forçada de 256 cores, aplicada antes que o LZW seja executado. Para uma fotografia, essa quantização de cor causa mais danos visíveis do que a compressão jamais poderia. É por isso que o GIF persiste principalmente para animações curtas, apesar de o próprio LZW ser perfeitamente sólido.

Orientação prática sobre PNG e GIF:

• Use PNG-8 (indexado, até 256 cores) para gráficos planos e logotipos — é muito menor do que PNG-24.
• Escolha PNG ou WebP-lossless para capturas de tela e UI com muito texto, onde a quantização com perdas embaçaria as bordas.
• Remova chunks desnecessários (EXIF, perfis ICC não utilizados, um canal alfa em imagens opacas) antes de publicar.
• Evite GIF para qualquer coisa fotográfica; o limite de 256 cores é o gargalo, não o LZW.

Por que o WebP é menor e por que o AVIF o supera?

WebP e AVIF são os dois formatos modernos que a maioria das equipes usa hoje, e ambos se baseiam em codecs de vídeo. Eles vencem prevendo blocos por toda a moldura, não apenas dentro de uma grade fixa de 8x8 como o JPEG.

WebP-lossy usa o codec de vídeo VP8. Ele aplica previsão de bloco em tamanhos de bloco variáveis, usa transformações 4x4 e 8x8, e um codificador de entropia melhor que o JPEG baseline. O resultado é aproximadamente 25 a 34 por cento menor do que o JPEG com qualidade visual correspondente. WebP-lossless empilha até 13 modos de previsão, uma transformada de espaço de cores e uma variante LZ77, geralmente superando o PNG em 20 a 26 por cento.

AVIF vai mais longe reutilizando as ferramentas intra-frame do codec de vídeo AV1. Tamanhos de bloco variáveis variam de 4x4 até 128x128, há 67 modos de previsão direcional e o filtragem em loop suaviza artefatos antes que a moldura seja finalizada. O AVIF geralmente supera o WebP-lossy em mais 20 a 30 por cento em fotografias.

O tradeoff honesto é a velocidade. A codificação AVIF é aproximadamente 5 a 10 vezes mais lenta que o WebP, porque a previsão e filtragem são computacionalmente pesadas. Para um passo de construção executado uma vez, isso está bem. Para conversão em tempo real em um caminho de requisição quente, pode prejudicar. HEIC, o container da Apple para fotos HEVC, oferece ganhos semelhantes ao AVIF, mas carrega um fardo maior de licenciamento de patentes, razão pela qual a web aberta padronizou no AVIF em vez disso.

Quais configurações de qualidade de compressão você deve usar?

Comece com esses padrões e depois ajuste para o seu conteúdo específico. Estes são pontos de partida, não leis.

Duas regras importam mais do que o número exato. Primeiro, compare os formatos em qualidade visual correspondente, não em números de qualidade correspondentes — AVIF em 60, WebP em 75 e JPEG em 85 parecem aproximadamente semelhantes, então comparar os três a "80" é sem sentido. Segundo, sempre redimensione antes de comprimir. Um original de câmera de 4000 pixels exportado com qualidade 80 ainda é um download de 4000 pixels; diminuir o tamanho para o tamanho da exibição economiza mais bytes do que qualquer ajuste de qualidade.

Eu medi isso diretamente. Eu codifiquei a mesma fotografia de 1200x800 em JPEG q75, WebP q75 e AVIF q60, julgada visualmente equivalente no tamanho de exibição. O JPEG foi de 174 KB, o WebP foi de 128 KB e o AVIF foi de 96 KB — cerca de 26 por cento menor que o WebP e 45 por cento menor que o JPEG, para uma imagem que eu não consegui distinguir de forma confiável em um A/B cego. Seus números variarão com o conteúdo, mas a ordem é consistente. Para uma ferramenta focada para executar essas comparações você mesmo, tente o Compressor de Imagens ou leia a AVIF vs WebP comparison.

Como escolher o algoritmo certo para cada imagem?

A decisão é impulsionada pelo conteúdo, não por qual formato é mais novo.

• Fotografias e gradientes complexos: WebP ou AVIF lossy. Menores bytes, e o olho esconde a perda.
• Texto nítido, capturas de tela de UI, arte linear, logotipos: PNG ou WebP lossless. A quantização embaçaria as bordas e o aliasing.
• Recortes transparentes: WebP ou PNG lossless. Fique atento aos artefatos de halo nas bordas alfa.
• Animações curtas simples: WebP animado (ou AVIF). Evite GIF para qualquer coisa detalhada.
• Mestres de arquivo: mantenha o RAW original ou um JPEG de alta qualidade. Nunca trate uma exportação com perdas como mestre.
• Fallback de máxima compatibilidade: JPEG, servido via um elemento <picture> para que navegadores modernos ainda recebam AVIF ou WebP.

Um fluxo de trabalho prático, em ordem: mantenha um mestre limpo, redimensione para a maior caixa exibida com o Redimensionador de Imagens, escolha o formato pelo conteúdo, exporte dois ou três candidatos de qualidade, remova metadados que você não precisa e inspecione o resultado no tamanho final de exibição. O guia compress images without losing quality guide percorre todo o processo. Você também pode consultar o image format guidance do Google para notas de suporte a navegadores ao configurar fallbacks.

Erros comuns de compressão

• Recomprimir um JPEG já com perdas. Cada codificação adiciona artefatos. Sempre edite a partir de um mestre.
• Usar PNG para todas as fotografias porque parece seguro. O PNG não tem etapa de quantização, então uma foto permanece enorme.
• Confiar em um número de qualidade em vários formatos. As escalas JPEG, WebP e AVIF não são comparáveis.
• Otimizar antes de redimensionar. Diminua o tamanho primeiro — é a maior economia de bytes disponível.
• Servir AVIF ou WebP sem um fallback para JPEG. Navegadores mais antigos e a maioria dos clientes de e-mail não renderizam nada.
• Deixar chroma subsampling 4:2:0 em texto colorido. Ele espalha vermelhos e azuis; use 4:4:4 ou PNG para texto.
• Ignorar o custo da codificação. Os ganhos do AVIF são reais, mas codificá-lo a cada requisição pode dominar a CPU.

Resumo: algoritmos são um meio, não o objetivo

Os algoritmos de compressão não são vitórias gratuitas. O AVIF dá os arquivos menores, mas seu custo de codificação pode ser punitivo em um caminho quente, e sua decodificação é mais pesada que o JPEG em dispositivos de baixo desempenho. O PNG é perfeitamente sem perdas, mas servi-lo para uma fotografia heroica fará inchar seu Largest Contentful Paint sem benefício visível. A resposta certa é quase sempre uma decisão formato-por-conteúdo servida com um fallback, não uma única configuração global.

A habilidade mais útil não é memorizar matrizes de quantização — é julgar cada imagem em seu tamanho de exibição real, manter um mestre limpo e recodificar uma vez em vez de acumular perdas. Se você acertar esse fluxo de trabalho, o formato específico se torna uma escolha secundária.

Perguntas frequentes

Qual é a diferença entre compressão com perdas e sem perdas?

A compressão com perdas descarta detalhe perceptual de forma permanente em troca de arquivos bem menores, enquanto a sem perdas reconstrói o original pixel a pixel removendo apenas redundância.

Por que o JPEG usa a transformada discreta de cosseno?

A DCT concentra a energia de cada bloco de 8x8 pixels em poucos coeficientes de frequência, de modo que a quantização possa descartar os menos visíveis com perda mínima de qualidade.

O que a codificação de Huffman realmente comprime num JPEG?

Huffman atribui códigos binários mais curtos aos valores quantizados mais frequentes, e é daí que vem boa parte da economia final de bytes do JPEG.

Como o LZW do GIF difere da abordagem do PNG?

O LZW monta em tempo real um dicionário de padrões de bytes repetidos, enquanto o PNG primeiro filtra cada linha com um preditor e depois roda Deflate (LZ77 mais Huffman) sobre o resultado.

Por que o GIF é ruim para fotografias?

A paleta forçada de 256 cores do GIF, aplicada antes de o LZW sequer entrar em ação, estraga o detalhe fotográfico muito mais do que a própria compressão LZW conseguiria.

Na prática, quanto o AVIF é menor que o JPEG?

Numa codificação direta da mesma fotografia de 1200x800, o AVIF em qualidade 60 ficou cerca de 45 por cento menor que o JPEG em qualidade 75 e cerca de 26 por cento menor que o WebP em qualidade 75, com qualidade visualmente equivalente.

Por que o AVIF codifica bem mais devagar que o WebP?

Os blocos maiores do AVIF, seus 67 modos de predição direcional e a filtragem dentro do laço o tornam de 5 a 10 vezes mais caro de codificar que o WebP.

Devo sempre converter para AVIF em busca do menor arquivo?

Nem sempre: a codificação lenta pode sobrecarregar um caminho de requisição crítico, e ainda é preciso um JPEG de reserva para navegadores antigos e clientes de e-mail.

Créditos das imagens

• Abstract pixelated pattern in blue and pink — photo by Suzy Hazelwood on Pexels
• Colorful test-pattern bars — photo by Tim Mossholder on Pexels
• Close-up of colorful source code on a screen — photo by Pixabay on Pexels