Porque comprimir duas vezes não reduz duas vezes para metade

A compressão remove redundância, não volume

A imagem mental que a maioria das pessoas carrega é mecânica: o ficheiro é uma esponja, a ferramenta espreme-a, e espremer com mais força ou duas vezes tira mais. Essa imagem prevê que uma segunda passagem deveria ajudar, e engana-se sobre o que a máquina faz. Um compressor procura padrões — uma sequência de bytes já aparecida, uma cor repetida numa zona, uma entrada de dicionário que substitua uma palavra longa — e substitui cada ocorrência por uma referência mais curta. O que sai não são os mesmos dados espremidos. É uma descrição diferente, mais breve, dos mesmos dados.

Feita essa reescrita, as repetições são referências e as referências não se repetem. Um segundo compressor chega a um ficheiro que parece, estatisticamente, ruído — que é exatamente o aspeto de dados bem comprimidos — e não encontra nada para encurtar. Ainda assim tem de escrever o seu próprio cabeçalho e enquadramento, pelo que a saída é por vezes um fio maior do que a entrada. Uma ferramenta que anuncia poupança nula ou negativa na segunda passagem não está a falhar: está a dizer a verdade sobre um ficheiro já tratado.

Há um piso, e tem nome

Em 1948 Claude Shannon mostrou que qualquer corpo de dados tem um tamanho mínimo abaixo do qual nenhum método sem perdas o consegue levar. Esse mínimo é a sua entropia: uma medida de quanto dos dados é genuinamente imprevisível. Uma página de texto português é altamente previsível — depois de «qu» um «e» é muito provável — por isso comprime bem. Um fluxo de números aleatórios não é nada previsível, por isso não comprime, e nenhum algoritmo futuro mudará isso. As ferramentas de compressão não competem por espremer com mais força; competem por modelar melhor os dados e chegar mais perto de um limite já fixado.

É por isso que a experiência familiar de pôr um PDF num zip não ganha nada que valha. Os fluxos internos do PDF já estão comprimidos em deflate e as suas imagens já são JPEG; o ficheiro está perto da sua entropia, e o zip não tem com que trabalhar. O mesmo vale para um MP4, um MP3 e um PNG. Se um tipo de ficheiro acaba num formato desenhado para ser pequeno, assuma que a compressão já foi feita e que um arquivador genérico acrescentará embalagem em vez de tirar volume.

Com perdas é outra máquina com outra falha

A compressão com perdas não está limitada pela entropia, porque não tem de reproduzir o original. Decide o que uma pessoa não notará — variações finas de cor, detalhe de alta frequência, sons mascarados por sons mais fortes — e descarta-o. É por isso que um JPEG é um décimo da imagem bruta de onde veio, e por isso a segunda passagem se comporta tão diferentemente: há sempre mais para descartar, por isso o ficheiro encolhe sempre, e a pergunta passa de «é possível?» para «a que custo?».

O custo é a perda de geração, e acumula-se de um modo que surpreende. Cada recodificação começa por descodificar o resultado anterior, que já contém os artefactos introduzidos pela passagem anterior. A nova passagem trata esses artefactos como detalhe real digno de ser preservado, gasta bits neles, e acrescenta os seus. Cinco gravações com boa qualidade produzem uma saída visivelmente pior — blocos nos contornos, manchas de cor, um empastamento geral — do que uma única gravação com qualidade muito mais baixa que atinge o mesmo tamanho. A regra que daí decorre é a única que conta na prática: comprima sempre a partir do original, nunca de uma cópia comprimida.

Qual dos dois faz uma dada ferramenta?

O comportamento diz-lho. Uma ferramenta sem perdas dá uma poupança modesta e repetível na primeira passagem e praticamente nula na segunda, e a sua saída é idêntica píxel a píxel à entrada. Uma ferramenta com perdas oferece um cursor de qualidade ou predefinições — leve, médio, forte — e continua a produzir ficheiros mais pequenos à medida que aperta. Se uma ferramenta leva um PDF digitalizado de 20 MB para 3 MB, está a recodificar as imagens e é com perdas, diga o que disser o botão. O compressor deste site é do primeiro tipo: reescreve a estrutura de objetos do PDF e deixa cada byte de imagem intacto, por isso nunca lhe dará um número espetacular numa digitalização, e nunca degradará em silêncio um documento que vai entregar em sítio oficial.

O único caso em que uma segunda passagem ajuda mesmo

Correr o mesmo algoritmo duas vezes não serve. Correr um diferente sobre o mesmo original, sim. Um método mais forte, com melhor modelo dos dados — um arquivador moderno em vez de um clássico, ou um formato de imagem mais recente em vez de um antigo — pode bater o primeiro resultado, porque é uma melhor tentativa contra o mesmo limite e não uma segunda tentativa contra um problema já resolvido. Recodificar um JPEG para AVIF ou WebP a partir do ficheiro original costuma ficar mais pequeno a igual qualidade; voltar a zipar um zip, não.

Duas consequências práticas. Guarde os originais: assim que só tiver a cópia comprimida, qualquer melhoria futura de formatos fica-lhe fechada, porque já não pode comprimir a partir de algo intacto. E quando um ficheiro continua teimosamente grande demais após uma passagem honesta, pare de agarrar o compressor e mude antes algo estrutural — menos páginas, resolução mais baixa, um excerto mais curto, uma divisão em dois ficheiros. São decisões sobre o conteúdo, e é no conteúdo que estão realmente os bytes que sobram.

O que fazer em vez de carregar no botão outra vez

Faça a passagem sem perdas uma vez e tome o número que ela dá como a verdade sobre esse ficheiro. Se não chegar, identifique onde estão os bytes antes de mais: num PDF, divida o tamanho pelas páginas; num vídeo, multiplique a duração pela taxa de bits; numa imagem, veja as dimensões em píxeis. Depois atue sobre essa coisa concreta, uma vez, a partir do original. Duas decisões tomadas deliberadamente valem mais do que cinco passagens feitas na esperança, e deixam-lhe um ficheiro mais pequeno que não passou cinco vezes pelo moinho.

Perguntas frequentes

O meu ficheiro ficou maior depois de comprimido. Como é possível?

Porque o compressor ainda tem de escrever a sua própria contabilidade — um cabeçalho, um dicionário, um enquadramento à volta dos dados — e se não encontrar redundância para tirar, essa contabilidade é pura adição. É o resultado normal com dados já comprimidos ou genuinamente aleatórios, e é um sinal mais do que uma falha: o ficheiro já estava no seu piso ou perto. Guarde o original e passe a uma mudança estrutural.

Isto quer dizer que a compressão sem perdas é fraca?

Não — quer dizer que é honesta. Em dados com redundância real é muito eficaz: uma exportação de base de dados, um ficheiro de registo ou um PDF com muito texto podem perder uma grande parte do tamanho sem que um único bit de informação mude. O que não fará é inventar espaço onde não há, nem degradará o seu documento para produzir um número mais bonito. Em tudo o que possa ter de defender mais tarde — uma entrega, um contrato assinado, uma digitalização original — é essa a propriedade que quer.

A perda de geração vê-se logo com uma só regravação?

Raramente, com um ajuste de qualidade razoável e se mais nada mudou. Torna-se visível quando as regravações se acumulam, quando o ajuste de qualidade é baixo, ou quando a imagem é também redimensionada entre gravações — redimensionar força uma recodificação completa e interage mal com os artefactos de bloco existentes. O hábito seguro não é contar passagens mas evitar a situação: guarde o original, e produza cada saída de que precisa diretamente a partir dele e não da última que exportou.

Porque é que a mesma ferramenta poupa 40 % num PDF e 2 % noutro?

Porque a poupança depende inteiramente da redundância que o ficheiro trazia, e isso varia enormemente conforme foi feito. Um PDF exportado várias vezes de um editor, ou gerado por um sistema de modelos que repete uma definição em cada página, está cheio de duplicação removível. Um PDF escrito uma vez por uma biblioteca bem comportada, ou que é essencialmente uma pilha de fotografias, quase não tem. A percentagem é um facto sobre a história do ficheiro, não uma nota atribuída à ferramenta.

Devo pôr por cima um arquivador mais forte, como o 7-Zip?

Só em dados que ainda não foram comprimidos. Um arquivador mais forte tem melhor modelo e baterá um mais fraco em texto, código-fonte, bases de dados e exportações em bruto — por vezes bastante. Num PDF, JPEG, MP3 ou MP4 está a trabalhar sobre dados já perto do seu piso, e o ganho será de um ou dois por cento ao preço de um contentor que o destinatário tem de descompactar. Use o arquivador forte onde a redundância vive, não em ficheiros a que já a tiraram.