Converter WebP para JXL

Este site mantém três cenas de amostra e as codifica pelo mesmo pipeline que esta página usa, então os números são o que este conversor de fato produz. Em 480 por 320 e na qualidade padrão: a fotografia pesa 14.700 bytes como WebP e 7.240 como JXL — o menor número de todo o conjunto de amostra, abaixo até do AVIF. O gráfico plano pesa 4.428 como WebP contra 5.016 como JXL. A cena parecida com print de tela pesa 10.830 como WebP contra 13.252 como JXL.

Então a reputação é merecida em tom contínuo e não em geral. Os modos do JPEG XL foram construídos pensando firmemente em material fotográfico, e numa fotografia em qualidade moderada ele é o mais forte dos quatro codecs que este site consegue escrever. Em conteúdo plano, de borda dura, com texto, não é, e o AVIF é a resposta melhor ali. Uma biblioteca de fotografias é boa candidata para esta conversão; uma pasta de recursos de interface não é.

Este é o mal-entendido mais comum sobre JPEG XL, e vale resolver antes de qualquer outra coisa. O JXL consegue pegar um arquivo JPEG existente e reembalá-lo sem perdas, economizando cerca de vinte por cento e permitindo que o JPEG original seja reconstruído byte a byte depois. É um recurso genuinamente inteligente e é específico dos coeficientes do JPEG.

Não tem equivalente para WebP, cuja codificação não tem relação nenhuma. E não é o que acontece neste site de qualquer forma: toda conversão de imagem aqui decodifica em pixels e recodifica, em todo par incluindo JPG para JXL. Então o arquivo que você recebe de volta é uma codificação nova, não um reembalamento, e não pode ser transformado de volta no WebP com que você começou.

O controle de qualidade vai até 100, e o codificador se comporta diferente no topo da faixa, então vale medir. Medido através do próprio codificador deste site numa imagem de teste de 256 por 256: na qualidade padrão de 82, um gradiente voltou com 73.647 das 262.144 amostras mudadas, a pior por 21 níveis. A 100, 334 amostras diferiram e nenhuma por mais de um nível, e arte plana a 100 voltou idêntica bit a bit.

Isso é quase sem perdas, não sem perdas de verdade. O modo dedicado sem perdas do codificador existe na biblioteca e não é exposto aqui, então dizer que o JXL é uma cópia sem perdas seria errado. Na prática: 82 para qualquer coisa que só vai ser vista, 100 se o arquivo vai entrar num fluxo que vai recodificar de novo, e nenhum dos dois se o que você precisava era uma cópia de arquivamento bit a bit — WebP para PNG é isso.

O WebP é lido por todo navegador atual sem opção reserva, e é por isso que ele existe e por que a maioria desses arquivos já é WebP para começar. O JPEG XL é lido só por alguns, uma situação materialmente diferente: uma imagem que não pode ser decodificada não é uma imagem degradada, é absolutamente nada.

Isso torna esta conversão uma decisão de arquivamento, não de entrega, e vale manter essa distinção. Guardar uma biblioteca de fotografias como JXL e gerar WebP ou AVIF para as páginas que a servem é um plano coerente. Substituir os arquivos WebP que um site já serve por arquivos JXL não é, e nenhuma opção reserva no elemento de imagem te salva se a opção reserva é o arquivo que você acabou de apagar.

A maioria dos arquivos WebP que chegam aqui foi produzida em modo com perdas — o padrão para qualquer coisa que um CMS ou uma esteira de build gera para entrega. O codificador já suavizou regiões planas e deixou contorno ao redor de bordas duras, e esses artefatos agora são simplesmente a imagem.

O codificador JXL reproduz isso fielmente e acrescenta uma camada própria. Na qualidade 82 o resultado é modesto e na 60 não é. O jeito de evitar isso inteiramente é voltar um passo: se o PNG ou JPG original ainda existir num repositório, codificar o JXL a partir dele produz um arquivo mais limpo e geralmente menor do que codificar a partir do WebP.

Os dois formatos carregam canal alfa completo de 8 bits, então uma imagem recortada atravessa com a transparência intacta e as bordas suaves ainda suaves. Nada precisa ser achatado e nenhuma cor de fundo entra na jogada, uma das razões dessa combinação ser mais limpa que converter um WebP para JPG ou BMP.

Metadado não viaja. EXIF, XMP e qualquer perfil ICC são descartados, porque a conversão decodifica em pixels crus e recodifica, e isso simplesmente acontece em vez de ser uma escolha que a página oferece. O próprio JPEG XL consegue carregar os três, então isso é uma limitação do pipeline, não do formato.

O WebP guarda uma imagem parada ou uma animação, e o decodificador usado aqui só lê o primeiro tipo. Um arquivo animado produz um erro legível em vez de um primeiro quadro — a melhor das duas falhas, e o mesmo comportamento em todo par de WebP deste site.

O JPEG XL consegue guardar animação, então em princípio os quadros teriam para onde ir; nada neste pipeline os extrai, então o caso não surge. Para uma pasta que mistura imagens paradas e animações, o lote converte as paradas e reporta o resto como erro, o resultado desejável.

O GIMP e o ImageMagick leem e escrevem JPEG XL diretamente, o que cobre fluxo de trabalho com script, processamento em lote e a maior parte do uso técnico. O Photoshop precisa de um plugin. Visualizadores do Windows e do macOS são inconsistentes, e boa parte do software comum mostra um ícone de arquivo desconhecido e nada mais.

Essa estreiteza é o argumento prático inteiro, e é por isso que o formato é marcado como nicho em vez de atual apesar de ser tecnicamente o mais forte aqui. Os dois usos honestos são um fluxo de trabalho fechado que você controla, e experimentação deliberada com os originais guardados em segurança em outro lugar. Qualquer coisa que precisa ser aberta por alguém com quem você não conversou deveria continuar WebP, ou virar PNG ou JPG.

Um decodificador WebAssembly lê e outro codifica, os dois compilados para WebAssembly e baixados só quando um arquivo desse tipo é solto, então um lote baixa cada codec uma vez. Nada de nenhum arquivo atravessa a rede, e não existe conta nem cota diária no caminho.

O limite gratuito é 100 MB por arquivo, bem além de qualquer recurso web. Solte uma pasta e cada arquivo converte com sua própria linha de progresso, com um ZIP no fim. A codificação de JPEG XL é mais lenta que a de WebP e mais rápida que a de AVIF, então algumas centenas de arquivos é uma caminhada em vez de uma tarde. Converta alguns primeiro e compare o tamanho contra os originais — no conteúdo errado esta conversão deixa os arquivos maiores.