Enviando JPEG XL no Chrome

Artigo original ↗ Discussão no Hacker News ↗

A decisão do Google de (re)ativar o JPEG XL no Chrome é vista como um grande ponto de virada para o formato de imagem, que promete melhor compressão, suporte a alta profundidade de bits e HDR, carregamento progressivo e até transcodificação sem perdas de JPEGs legados. Os comentaristas debatem como o JPEG XL se compara ao AVIF e ao WebP, ponderando eficiência de compressão, desempenho sem perdas, velocidade de decodificação e ferramentas no mundo real, ao mesmo tempo em que destacam preocupações de segurança do passado e a política por trás de o Google primeiro ter removido e agora restaurado o suporte. Muitos esperam que, com o apoio de grandes navegadores, fornecedores de sistemas operacionais e até do ecossistema PDF, o JPEG XL possa se tornar um sucessor de longo prazo e de propósito geral para a mistura fragmentada de JPEG, PNG, WebP, AVIF e HEIC de hoje.

História e motivação para JPEG XL no Chrome

  • O suporte a JPEG XL foi adicionado ao Chrome, removido por volta de 2023 e agora está sendo adicionado novamente.
  • A remoção anterior foi oficialmente atribuída à baixa demanda e à redundância com AVIF/WebP; alguns comentaristas acham que o custo de segurança, a política interna ou a política de consórcios (AVIF/AOM) também desempenharam papéis.
  • A reversão é atribuída de várias formas a: um decoder em Rust mais seguro (jxl‑rs), maior tração no ecossistema, suporte da Apple/Safari (incluindo JXL no ProRAW do iPhone) e atualizações na especificação de PDF adotando JXL, o que efetivamente força suporte de navegador para renderização de PDF.

Propriedades técnicas e comparações (AVIF, WebP, PNG, JPEG)

  • Muitos veem JPEG XL como um “sucessor de propósito geral” de JPEG/PNG/WebP/AVIF:
    • Com e sem perdas, alta profundidade de bits (HDR), ampla gama de cores, canais extras, camadas, páginas, animação, mapas de profundidade.
    • Recompressão sem perdas de JPEGs existentes com tamanho menor e sem perda geracional.
  • Vários relatam que JPEG XL supera AVIF/WebP/PNG para fotos de alta qualidade e uso sem perdas, incluindo grandes conjuntos de arquivos e conjuntos de dados de visão de máquina.
  • Outros argumentam que AVIF é mais eficiente para bitrates muito baixos e “hero images” da web, e que os encoders modernos de AVIF fecharam grande parte da vantagem percebida do JXL.
  • Um “caso contra o JXL” detalhado argumenta:
    • AVIF é melhor para o uso típico com perdas na web.
    • Os ganhos sem perdas do JXL sobre WebP (~10–13%) não justificam o maior custo de decodificação.
    • Os ganhos na transcodificação de JPEG podem ser compensados por uma decodificação mais lenta nos clientes.
  • Contrapontos: muitos benchmarks e testes práticos no tópico mostram o JXL vencendo em qualidade/tamanho para fotos e sem perdas, com jxl‑rs agora competitivo ou mais rápido que o libjxl em C++.

Segurança e implementação

  • O libjxl original em C/C++ tinha várias vulnerabilidades e era considerado uma superfície de ataque grande demais.
  • Chrome e Firefox estão adotando um decoder em Rust para satisfazer diretrizes internas de segurança “rule of two” (segurança de memória vs sandboxing vs entrada confiável).
  • Alguns debatem se Rust sozinho é suficiente sem sandboxing.

Ecossistema, UX e compatibilidade

  • Navegadores: Safari já oferece JXL (sem alguns recursos avançados como animação progressiva); Chrome estável agora; Firefox ativando por padrão em uma versão futura. O Android WebView deve seguir o Chrome.
  • SOs/apps: visualizadores do sistema no macOS/iOS, algumas ferramentas de edição e stacks de PDF suportam JXL; a qualidade das ferramentas é desigual (alguns encoders são vistos como ruins).
  • Muitos reclamam da dor de compatibilidade do WebP/HEIC no passado (LMSes, Telegram, Instagram, apps de desktop) e temem outra rodada de fragmentação; outros observam que a adoção do JXL fora dos navegadores já é mais rápida do que foi a do WebP.
  • A renderização progressiva é elogiada por eliminar a necessidade de muitos thumbnails, mas alguns se preocupam com a UX (não fica claro quando o carregamento “termina”) e com possível uso indevido se os thumbnails divergirem das imagens finais.

Adoção e preocupações de implantação

  • Desenvolvedores web acompanham as porcentagens do caniuse; vários não usarão JXL até cerca de 80–90% de suporte ou pelo menos o próximo Firefox ESR.
  • O custo de codificação é uma preocupação importante para pipelines dinâmicos ou sob demanda; experimentos anteriores com AVIF causaram grandes aumentos de CPU e custo.
  • Padrões recomendados incluem servir JXL via <picture> com fallbacks para JPEG/PNG/WebP/AVIF, e aguardar alguns ciclos de lançamentos do navegador antes de uso amplo em produção.

Filosofia mais ampla

  • Alguns querem um único formato de imagem moderno de “é só usar isso”; outros preferem um conjunto pequeno e orientado a propósitos específicos (por exemplo, AVIF para perdas na web, PNG/WebP para sem perdas).
  • Céticos argumentam que JPEG/PNG continuam “bons o suficiente” e universalmente compatíveis; defensores destacam economia de dados móveis, armazenamento, melhor qualidade, necessidades de HDR/profundidade de bits e valor de arquivamento de longo prazo.