Ferramenta de Compressão de Imagens

A compressão de imagens online reduz o tamanho dos arquivos para acelerar páginas, respeitar limites de upload e diminuir o consumo de banda ao compartilhar. Os arquivos são enviados para o serviço de conversão do ToolAct, processados por bibliotecas no servidor (libvips / mozjpeg / libwebp), e o resultado comprimido é baixado de volta. Os originais são excluídos do servidor imediatamente após a conversão — não são arquivados nem usados para treinamento. Dependendo do formato, a compressão ajusta qualidade, metadados, informações de cor e detalhes de codificação; uma foto pode ficar muito menor sem perda visível em tamanho normal. A ferramenta é útil para imagens de blog, fotos de produto, posts sociais, anexos de suporte e rascunhos que não precisam preservar cada pixel original. Para impressão, arquivo permanente ou inspeção de detalhes finos, o resultado comprimido deve ser conferido com cuidado. Evite enviar fotos com informações pessoais, documentos internos ou outros materiais sensíveis.

A compressão de imagens se divide claramente na fronteira com perda/sem perda. Formatos com perda (JPEG, WebP com perda) exploram os limites perceptivos humanos: o olho é muito menos sensível à crominância de alta frequência do que à luminância, então os codificadores descartam detalhes de cor minúsculos em blocos de 8x8 ou 16x16 sem que a maioria dos espectadores perceba. JPEG usa esse caminho baseado em DCT desde 1992; as alternativas modernas são mozjpeg (~5-10% menor que libjpeg no mesmo SSIM, codificador mais lento), libwebp (codec de imagem VP8/VP8L do Google, 2010) e AVIF (Alliance for Open Media, AV1 intra, 2019). Formatos sem perda (PNG, GIF, WebP sem perda) reduzem os bytes por meio de codificação de entropia — dicionário de janela deslizante LZ77 mais codificação Huffman ou aritmética — e nunca alteram um único pixel. O pipeline usado por esta página é totalmente no servidor. O navegador empacota cada imagem em um upload multipart assinado para o endpoint de compressão do ToolAct (/image/compress). O servidor valida a requisição, entrega os bytes ao libvips — uma biblioteca de processamento de imagens de alto desempenho e baixo consumo de memória —, que decodifica a fonte, opcionalmente redimensiona o lado mais longo para limitar as dimensões de saída, e recodifica via mozjpeg para JPEG, libwebp para WebP ou libpng/oxipng para PNG. Os bytes codificados são transmitidos diretamente de volta ao navegador como resposta de download, e o arquivo de upload temporário é excluído do disco assim que a resposta é finalizada. Não há arquivamento, não há pipeline de treinamento e não há revisão humana do conteúdo. A quantização JPEG é o coração do formato: qualidade 90 mantém quase todos os coeficientes DCT, 75 começa a descartar os de frequência média (visível em texto vermelho sobre amarelo), 50 é a zona de JPEG óbvio onde artefatos de bloco aparecem em gradientes suaves, e 25 produz posterização visível em rostos. A compressão PNG usa zlib (DEFLATE) níveis 0-9; o nível 1 é rápido mas gera arquivos maiores, o nível 9 comprime os últimos bytes de banners de cor uniforme ao custo de CPU. Metadados EXIF, perfis ICC, XMP e IPTC são descartados por padrão porque o codificador reconstrói o cabeçalho do arquivo do zero — uma razão real pela qual uma foto de câmera de 200 KB pode se tornar um upload de 60 KB mesmo na mesma resolução, e uma razão pela qual a procedência da imagem e metadados de gerenciamento de cor devem ser preservados separadamente se forem importantes.

• libvips (John Cupitt, LGPL) é o motor de processamento de imagens no servidor: um pipeline em streaming, orientado por demanda, que mantém o uso de memória baixo mesmo em entradas de 100 MP e está por trás do Sharp, do delegado vips do IM7 do ImageMagick e dos endpoints de conversão por trás desta ferramenta.
• mozjpeg (Mozilla, fork de libjpeg-turbo com melhores modelos psicovisuais) produz arquivos 5-10% menores que o libjpeg padrão no mesmo SSIM, mas é aproximadamente 3-5x mais lento para codificar — o trade-off por trás dos padrões web de qualidade JPEG 80-85 desde 2017.
• PNG é LZ77 + Huffman: o codificador encontra sequências de bytes repetidas até 32 KB atrás (janela deslizante), emite pares (distância, comprimento) e depois codifica o resultado com Huffman. WebP sem perda (VP8L) usa uma ideia semelhante além de patches de paleta local, tipicamente superando PNG em 20-26% nos mesmos pixels RGBA.
• libwebp é o codificador/decodificador WebP de referência do Google; no servidor, ele é usado para gravar VP8 com perda (qualidade 0-100, crominância 4:2:0 por padrão) ou VP8L sem perda (a qualidade controla o esforço de compressão, nunca a fidelidade dos pixels). A decodificação WebP está amplamente disponível (Chrome 32+ 2014, Firefox 65+ 2019, Safari 14+ 2020), portanto um WebP convertido é seguro para quase todos os navegadores modernos.
• A subamostragem de crominância 4:2:0 padrão no JPEG (duas amostras de crominância para cada 4 de luminância) é o que faz texto vermelho em fundo amarelo parecer borrado na qualidade 60 — o detalhe de crominância é descartado antes do detalhe de luminância. Mude para 4:4:4 (sem subamostragem) para capturas de tela e UI onde bordas de texto importam.
• EXIF (Exchangeable image file format, JEITA CP-3451) e perfis de cor ICC são removidos na recodificação por padrão, então um JPEG de iPhone de 6,3 MB frequentemente chega a 1,8 MB após o servidor processá-lo. Essa é a razão pela qual fotógrafos veem os tamanhos de arquivo diminuírem após cada passagem por uma ferramenta web. Uma armadilha prática em lote: quando uma pasta mistura ícones pequenos (abaixo de 200x200 px, PNG com alfa), capturas de UI de cor uniforme (PNG, alta compressibilidade) e fotos de celular (JPEG, conteúdo predominantemente ruidoso), um único controle deslizante de qualidade é inadequado para os três. Ícones querem PNG sem perda ou WebP sem perda; capturas querem JPEG 4:4:4 na qualidade 85-90; fotos querem WebP com perda na qualidade 75-80. Comprimir tudo na qualidade 60 economiza bytes mas introduz bordas avermelhadas em ícones, artefatos de anel em capturas e bandas nas fotos. O pipeline mais inteligente executa cada categoria por um caminho de codificador diferente, que é o motivo pelo qual a interface permite substituir o formato de destino para cada arquivo mesmo quando o usuário escolhe um padrão. Olhando para o futuro, JPEG XL (ISO/IEC 18181, 2022) é o formato que Google e Cloudflare têm promovido desde 2020 como sucessor do JPEG: ~20% menor na mesma qualidade, modo sem perda completo, sem subamostragem de crominância e decodificação progressiva amigável para redes lentas. O suporte dos navegadores é parcial (Chrome desativou JPEG XL no Chrome 110), então o caminho de migração prático por enquanto é WebP na qualidade 80, AVIF para recursos principais que precisam dos bytes extras, e manter um fallback JPEG para Safari antigo ou clientes de e-mail mais antigos. A página expõe qualidade, dimensão máxima e formato de destino como as três alavancas que importam; todo o resto é detalhe de implementação.
• Ciclo de vida da conversão no servidor: cada arquivo enviado é mantido apenas pelo tempo necessário para executar a decodificação libvips e a recodificação e transmitir o resultado de volta. O arquivo temporário é excluído ao fechamento da resposta, independentemente de a conversão ter sido bem-sucedida ou não. Um JPEG de 24 MP que travaria a thread principal do renderizador por 200-500 ms é processado completamente fora do dispositivo do usuário.
• Migração: AVIF é o alvo de próxima geração (Alliance for Open Media, AV1 intra, suporta 10/12 bits, alfa, animação). A codificação AVIF no servidor via libavif/aom ainda é 10-30x mais lenta que WebP, então a maioria das páginas fica com WebP na qualidade 80 e reserva AVIF para fotos principais que se beneficiam da economia extra de 15-20% em bytes.