JPEG XL e a Fronteira de Pareto
JPEG XL é apresentado como um codec de imagem de próxima geração altamente eficiente, que supera JPEG, WebP, AVIF e PNG tanto em taxa de compressão quanto em velocidade, com recursos como recompressão sem perda de JPEG, decodificação progressiva, suporte a HDR e forte desempenho em modo sem perda. Os comentaristas elogiam as melhorias recentes no encoder e no uso de memória, mas observam que o impacto no mundo real é limitado pelo suporte inconsistente dos navegadores, por receios de patentes e pelo domínio do Chromium na definição de padrões web de facto. Há amplo consenso de que o JPEG XL é tecnicamente impressionante e atraente para fotografia, arquivos e fluxos de trabalho profissionais, mas seu futuro na web depende das decisões de adoção dos grandes fornecedores, e não apenas de mérito técnico.
Suporte de navegador e “gatekeeping”
- Muitos comentários focam no fato de o Chrome ter removido JPEG XL por trás de uma flag e se recusado a lançá-lo, apesar dos pedidos da comunidade.
- Alguns argumentam que derivados do Chrome (Edge, Brave, Opera) poderiam se diferenciar ativando JXL, mas em geral não o fazem, sugerindo que a divergência real em relação ao Chromium é cara.
- O Safari já oferece JPEG XL; o Firefox é descrito como “neutro” e com recursos limitados, com o trabalho estagnado no nightly.
- Há preocupações de que o domínio do Chromium o torne um gatekeeper de facto; outros respondem que participação de mercado não é um mandato para implementar todos os formatos.
Patentes, risco legal e segurança
- Debate sobre se uma patente da Microsoft relacionada a ANS assustou os fabricantes de navegadores; outros contrapõem que ela não se aplica ao JXL e que isso é especulativo.
- O fato de Apple e Adobe oferecerem JXL é citado como evidência de que o risco de patentes é administrável.
- Esclarecimento de que Cloudinary e Google oferecem licenças livres de royalties para suas patentes relacionadas ao JXL; o risco restante é genérico para qualquer formato recente.
- Preocupação separada: libjxl é C++, já teve bugs de segurança de memória; alguns argumentam que codecs novos e complexos, que serão ubíquos, deveriam ser escritos em linguagens seguras.
Existe um decodificador em Rust e ele foi validado.
Qualidade e velocidade de compressão
- Sem perda: JXL e WebP sem perda são fortes; AVIF sem perda é amplamente criticado e muitas vezes pior que PNG. WebP sem perda é elogiado, mas limitado a 8 bits e dimensões menores.
- Com perda: em qualidades típicas da web, JXL muitas vezes supera JPEG e WebP; AVIF pode ser melhor em bitrates baixos. Alguns acham JPEG de baixa qualidade mais detalhado, mas observam que ele usa mais bits.
- As melhorias no encoder JXL na v0.10 reduziram significativamente o uso de memória e aumentaram a velocidade, especialmente para o modo sem perda multithread.
- Discussão sobre como traçar a fronteira de Pareto e se alguns pontos foram mal classificados.
Desempenho de decodificação e UX
- Muitos veem a velocidade de codificação como economicamente crítica para serviços (codificação em massa); a velocidade de decodificação é “boa o suficiente” em dispositivos modernos.
- Decodificação progressiva/streaming é vista como mais impactante para a UX do que a taxa bruta de decodificação; JXL oferece decodificação progressiva forte, ao contrário do AVIF.
Funcionalidades e ecossistema
- Um grande atrativo: JXL pode recomprimir JPEGs existentes sem perda e reconstruir JPEGs bit a bit idênticos, permitindo economia de armazenamento sem perda de qualidade.
- O encoder compatível com JPEG “jpegli” entrega ganhos impressionantes permanecendo dentro do JPEG, reforçando que “o velho JPEG ainda tem vida”.
- Ferramentas: desejo de melhor integração do JXL (por exemplo, versões de libvips e ImageMagick), e menção à biblioteca SIMD Highway, derivada do trabalho em JXL.
- Ainda existe ceticismo de que, apesar dos méritos técnicos, a adoção do JXL é lenta e o uso no mundo real continua limitado em comparação com o hype.