Compressão com Perda vs Sem Perda: Por Que os Formatos de Imagem Esquecem de Propósito

Pegue a mesma foto de 12 MP (4000 × 3000 pixels) e salve duas vezes. Uma vez como PNG: 24 MB. Outra como JPEG na qualidade 90: 3,4 MB. Coloque as duas lado a lado na tela e você não distingue uma da outra. Dê um zoom de 400% e as diferenças finalmente aparecem: uma leve suavização no cabelo e na grama, halos sutis ao longo das bordas mais nítidas.

Dois arquivos, uma imagem, 7× de diferença no tamanho. Nenhum dos dois está corrompido. Eles só assumiram compromissos diferentes: o PNG se comprometeu a preservar cada bit; o JPEG, a preservar tudo o que você notaria. Quase tudo o que há para entender sobre formatos de imagem deriva de qual desses dois compromissos cada formato escolhe.

Por que a compressão se dividiu em dois campos

Em 1948, Claude Shannon publicou "A Mathematical Theory of Communication" e deu à compressão um piso inegociável. Seu teorema da codificação de fonte diz que é impossível representar dados sem perda abaixo da sua entropia, o conteúdo médio de informação por símbolo. Uma imagem perfeitamente aleatória não comprime nada. Uma imagem toda branca comprime até quase nada. Toda imagem real fica em algum ponto dessa escala, e nenhum algoritmo sem perda consegue furar esse piso.

A compressão com perda existe por causa de uma brecha. O piso da entropia vale para os dados que você tem, não para os dados que você guarda. Se antes você trocar a imagem por uma versão ligeiramente diferente, com entropia menor, o piso desce junto. O truque inteiro é esse: mude os dados, depois empacote. A pergunta de engenharia é quais mudanças são aceitáveis.

A resposta depende de duas coisas. Primeiro, o conteúdo. Uma captura de tela de um painel de configurações é quase só cor chapada e formas repetidas: baixa entropia, fácil de prever. Uma foto de floresta, no nível do pixel, é ruído de fótons e ruído de leitura do sensor: alta entropia, difícil de prever. Segundo, o consumidor. Um programa que lê o arquivo precisa dos bits exatos. Uma pessoa que olha a imagem já traz de fábrica uma tolerância a erro: acuidade espacial limitada para cor, pouca sensibilidade a texturas finas de alta frequência e uma percepção de brilho que funciona por proporções, não por valores absolutos (lei de Weber, degraus de luminância de cerca de 1 a 2%).

Foi assim que os formatos se dividiram. Se o seu conteúdo é previsível e quem consome é uma máquina, ou alguém de lupa em cima dos pixels, vá de sem perda. Se o seu conteúdo é ruidoso e quem consome é uma pessoa a um braço de distância, você pode se dar ao luxo de esquecer.

Como funciona a compressão com perda

É comum descrever codec com perda como algo que "joga dados fora". Não está errado, mas é impreciso. O que se joga fora são dados específicos, escolhidos por um modelo da visão humana. O pipeline:

1. Converter RGB para um espaço de cor luma-croma (YCbCr no JPEG, divisões parecidas nos outros). O olho resolve detalhe de brilho muito melhor do que detalhe de cor, então os canais de croma podem ser guardados em um quarto da resolução (subamostragem 4:2:0). Só essa etapa já corta os dados brutos em cerca de 50%, e é invisível na maioria das fotos.

2. Transformar cada bloco em frequências. O JPEG usa a transformada discreta de cosseno em blocos de 8 × 8. O JPEG 2000 usa wavelets. AV1 e HEVC usam transformadas maiores, de tamanho variável. O resultado é sempre o mesmo desenho: poucos coeficientes grandes descrevendo as formas gerais, muitos coeficientes pequenos descrevendo a textura fina.

3. Quantizar. Cada coeficiente é dividido por um tamanho de passo e arredondado para inteiro. Os coeficientes pequenos viram zero. É a única etapa com perda do pipeline inteiro, e a configuração de qualidade do seu codificador é só um multiplicador sobre esses passos. Qualidade 95 usa passos pequenos e preserva quase tudo. Qualidade 30 usa passos grandes e zera a maior parte da textura fina.

4. Aplicar codificação entrópica ao que sobrou. Varredura em zigue-zague, codificação por comprimento de corrida (run-length), Huffman ou codificação aritmética. Esse estágio é sem perda: ele só empacota os números já quantizados.

Leia essa lista de novo. As etapas 1, 2 e 4 são só reorganização reversível dos dados. A etapa 3 é onde a imagem é de fato destruída, de propósito, um erro de arredondamento por vez.

A destruição deixa uma assinatura reconhecível. Aperte a qualidade demais e você vê blocagem (a grade de 8 × 8 aparecendo em céus e paredes), ringing (halos em volta de texto e de bordas de alto contraste) e banding (gradientes suaves que colapsam em degraus). Salve de novo um arquivo com perda e o pipeline roda outra vez sobre dados já danificados; é por isso que a perda de geração (generation loss) se acumula: na décima vez que um JPEG é salvo, ele parece uma aquarela do primeiro.

Como funciona a compressão sem perda

Codecs sem perda não se dão essas liberdades. O arquivo decodificado precisa bater com o original bit a bit, então só resta a eles modelar e empacotar. A receita básica tem duas etapas.

Primeira etapa: tirar a correlação. O PNG filtra cada linha de pixels antes de comprimi-la. Para cada linha, o codificador escolhe um de cinco preditores (None, Sub, Up, Average, Paeth) e guarda a diferença entre o pixel real e a previsão. Uma linha toda branca vira um pixel branco seguido de milhares de zeros. Um gradiente suave vira resíduos pequenos, que variam devagar. Nos dois casos, os números ficam pequenos e concentrados perto de zero, que é exatamente o que a etapa seguinte quer.

Segunda etapa: codificação entrópica. O PNG usa DEFLATE, o mesmo algoritmo do gzip e do zip, montado a partir de duas ideias dos anos 1970. O LZ77 procura sequências de bytes repetidas e troca cada repetição por um ponteiro (distância, comprimento) para os 32 KB anteriores de dados. A codificação de Huffman então dá códigos curtos aos valores frequentes e códigos longos aos raros. Nenhuma das duas perde nada: a partir do fluxo empacotado, dá sempre para refazer os bytes originais.

É por isso que o PNG é ótimo para capturas de tela e péssimo para fotos. Gráfico de interface vive de repetição: linhas idênticas, ícones repetidos, longas sequências de cor chapada. O LZ77 acha repetição em todo canto, e os filtros transformam o que sobra em resíduos quase zero. Uma fotografia não repete nada. O ruído faz cada pixel ser um pouco diferente do vizinho; os preditores erram, os resíduos continuam grandes e aleatórios, e o LZ77 não acha nada para apontar. Em uma foto de 12 MP, o PNG normalmente consegue 1,3:1 a 1,6:1 sobre os pixels brutos. O JPEG, com qualidade visualmente semelhante, chega a 10:1.

Em troca desses arquivos maiores, você ganha uma garantia absoluta: decodifique um PNG, calcule o hash dos pixels, e ele bate com o da fonte todas as vezes. Para capturas de tela que vão passar por OCR, digitalizações que serão re-editadas, imagens médicas e científicas que podem acabar num artigo ou num tribunal, essa garantia é exatamente o que se busca.

Por que o JPEG apostou na compressão com perda em 1992

O Joint Photographic Experts Group começou a trabalhar em 1986, e as restrições daquela época explicam cada decisão de design. Um disco rígido de 20 MB custava centenas de dólares. Um disquete de 1,44 MB era o meio padrão de mover arquivos. Modems rodavam a 14,4 kbps, com sorte; nessa velocidade, baixar uma única foto VGA descomprimida de 921 KB levava uns nove minutos. Uma versão com perda a 10:1 chega em menos de um minuto. Uma versão sem perda a 2:1 ainda leva mais de quatro.

Os testes do próprio comitê mostravam que o sem perda não iria muito além. Conteúdo fotográfico, o alvo declarado ("imagens de tom contínuo"), simplesmente não tem redundância suficiente. Com esses números na mesa, restava explorar a única folga disponível: o espectador.

Menos conhecido é o fato de que o padrão publicado em 1992 (ISO/IEC 10918-1) inclui um modo sem perda. Ele dispensa a DCT por completo, prevê cada pixel a partir de até três vizinhos usando um de sete preditores fixos e aplica codificação entrópica aos resíduos: conceitualmente, o mesmo truque que o PNG usaria três anos depois. Quase ninguém implementou. Decodificadores ignoraram, codificadores ignoraram e, quando a medicina de fato precisou de um JPEG sem perda, ela ganhou um padrão só dela (JPEG-LS, ISO/IEC 14495, 1999).

O comitê também precisou contornar patentes. A opção de codificação aritmética do JPEG estava presa às patentes do Q-coder da IBM, então o baseline livre de royalties ficou com a codificação de Huffman, e a maioria das implementações nunca chegou perto da rota aritmética. Patente ditar o design de codec não era novidade em 1992. E estava prestes a piorar muito.

O JPEG foi, no fundo, uma aposta psicovisual: os últimos 5× de compressão não são matemática, são biologia.

Por que o PNG apostou na compressão sem perda em 1995

O PNG não começou como um projeto de engenharia. Começou como uma emergência jurídica.

Em dezembro de 1994, a Unisys anunciou que cobraria licença de qualquer software que usasse GIF, porque a compressão do GIF dependia do algoritmo LZW, coberto por uma patente de 1985 que a Unisys havia herdado. A CompuServe, criadora do GIF, fechou um acordo e repassou o custo aos desenvolvedores. As comunidades de gráficos da Usenet ficaram furiosas: o GIF era gratuito havia sete anos e, de uma hora para outra, todo um acervo de imagens e ferramentas da web da época estava pisando em terreno patenteado.

Em questão de semanas, no início de janeiro de 1995, Thomas Boutell postou o primeiro rascunho de um substituto. Voluntários fecharam o design em listas de discussão em poucos meses. O PNG 1.0 chegou em outubro de 1996 como recomendação do W3C, e depois como RFC 2083 em março de 1997.

Duas exigências nunca estiveram em discussão. Todo algoritmo precisava ser livre de patentes, o que apontava para o DEFLATE (a combinação de LZ77 com Huffman do PKZIP de Phil Katz, implementada em zlib por Jean-loup Gailly e Mark Adler). E o formato tinha que ser sem perda, ponto final. A comunidade estava ali para substituir o GIF; um substituto que degradasse imagens nasceria morto. E a exigência de patentes limpas já eliminava, de saída, os truques perceptuais que faziam o JPEG funcionar.

O conteúdo pesava tanto quanto. O PNG foi feito para o que o GIF de fato carregava: logotipos, diagramas, arte em linha, ícones, capturas de tela. Bordas nítidas e cor chapada, justamente o tipo de conteúdo em que os artefatos de ringing do JPEG mais aparecem. Correr atrás de fotos significaria reinventar a DCT e competir com um JPEG já estabelecido e livre de royalties. O PNG comprou a briga que podia vencer, e ganhou de lavada. A patente do GIF expirou em 2003 (2004 fora dos EUA), mas, a essa altura, o PNG já tinha tomado o lugar dele.

Por que a compressão com perda venceu o mercado mesmo assim

O PNG ficou com o seu nicho. O JPEG ficou com o mundo.

A razão é volume. A imensa maioria das imagens da web é fotografia, e, para fotografia, compressão com perda não é concessão: é a ferramenta certa. O Web Almanac de 2025 coloca o JPEG em cerca de 57% de todas as imagens servidas, três décadas depois de criado. Feeds sociais, fotografia de notícias, fotos de produto, anúncios imobiliários: tudo conteúdo de tom contínuo, em que um arquivo com perda na qualidade 75 é visualmente idêntico à fonte nas telas que as pessoas de fato usam.

Os custos empurram para o mesmo lado. Armazenamento e banda são cobrados por byte, e 10:1 contra 2:1 não é uma margem, é uma diferença de 5× no custo de entrega com qualidade aceitável. A velocidade da página segue o tamanho do arquivo, e o tamanho do arquivo segue a compressão. Toda câmera e todo telefone já sai de fábrica salvando em formato com perda (JPEG ou HEIC). Todo CMS gera miniaturas com perda. As redes sociais re-codificam cada upload, em parte pelo tamanho, em parte para remover metadados e qualquer coisa maliciosa escondida neles. Um fotógrafo pode enviar um TIFF impecável; o que a timeline serve é um JPEG de qualidade 85.

A compressão sem perda não perdeu; recuou para os lugares onde a garantia dela importa: capturas de tela e ativos de UI, onde artefatos saltam aos olhos na hora e o conteúdo comprime bem de qualquer jeito; masters em pipelines de edição, onde cada geração com perda se acumula; imagens médicas, jurídicas e científicas, onde "quase igual" não é prova. Nesses nichos, PNG e TIFF reinam absolutos. Só não é neles que está o tráfego.

Onde os formatos foram parar

Duas tendências saltam aos olhos. Codec novo não escolhe mais um lado: WebP, HEIC, AVIF e JPEG XL trazem modos com perda e sem perda numa única especificação, e o JPEG 2000 já fazia isso em 2000. A pergunta "com perda ou sem perda" mudou de "qual formato" para "qual modo". E os casos limítrofes continuam aparecendo. O JPEG XL consegue recomprimir um JPEG existente sem perda para cerca de 80% do tamanho, um truque que só é possível porque os dois campos passaram trinta anos aprendendo a matemática um do outro.

Escolhendo na prática

A árvore de decisão é curta:

• Publicando uma foto? Com perda. JPEG quando a compatibilidade importa, WebP ou AVIF quando o tamanho importa.
• Salvando uma captura de tela, um logotipo ou qualquer coisa com texto e cor chapada? Sem perda. PNG.
• Editando? Mantenha o master sem perda, exporte cópias com perda e nunca re-salve um arquivo com perda no mesmo formato. Cada geração acumula o dano.
• Convertendo? Adapte a saída ao destino, não à origem. Uma captura de tela em PNG que vai para uma galeria de fotos vira JPEG ou WebP. Um JPEG que entra num arquivo de design vira PNG, não porque ganha qualidade (não ganha), mas porque para de perder.

É nesse último ponto que muita gente se atrapalha com as fotos do iPhone. HEIC já é compressão HEVC com perda. Converter HEIC para PNG não restaura nada; congela o estado atual e garante que não haverá mais perda, o que ainda é útil se você pretende editar. Para compartilhar, converter direto para JPEG é a saída mais sensata. Nossos conversores de HEIC para JPG, HEIC para PNG e HEIC para WebP fazem a conversão localmente, no seu navegador: o arquivo nunca sai do seu dispositivo.

A mesma lógica cobre o resto da matriz. Para levar um JPEG a um fluxo de edição sem perda: JPG para PNG. Para encolher uma captura de tela PNG para a web: PNG para JPG, ou PNG para WebP se você quer arquivos menores mantendo a transparência. No caminho contrário, WebP para PNG e WebP para JPG restauram a compatibilidade com software antigo. Se você está preso com digitalizações BMP descomprimidas, BMP para JPG, BMP para PNG e BMP para WebP dão a mesma escolha entre com perda e sem perda em um passo. Até renderizar documento esbarra na mesma bifurcação: exportar uma página de PDF como imagem significa escolher entre PDF para JPG para páginas fotográficas e PDF para PNG quando o texto precisa continuar nítido.

Trinta anos depois, os formatos que sobreviveram são os que entenderam exatamente o que seus usuários podiam se dar ao luxo de esquecer, e o que não podiam.