Chromium integra o JpegXL

• O decodificador JpegXL foi integrado à base de código do Chromium, permitindo que o navegador processe imagens no formato JXL
• A mudança pode ser vista na página de revisão de código do Gerrit com o título “Wire up JXL decoder”
• Esta mesclagem é um passo central para o suporte ao formato JpegXL, incluindo o trabalho de ligação do decodificador
• A revisão de código foi registrada como uma mudança no repositório src do Chromium (7184969)
• Isso é relevante por ampliar o suporte do navegador a formatos de imagem de nova geração

---

Integração do decodificador JpegXL no Chromium

• O item de revisão de código do Gerrit “Wire up JXL decoder (7184969)” é uma mudança que conecta o decodificador JpegXL ao projeto Chromium
  • Essa mudança foi feita no repositório src do Chromium
  • A plataforma de revisão de código usada é chromium-review.googlesource.com
• Como o título indica, trata-se de conectar (wire up) o decodificador JXL (JpegXL) dentro do navegador
• A página não exibe explicações adicionais nem detalhes do código, sendo possível confirmar apenas o título da mudança

Contexto técnico

• JpegXL é um formato de compressão de imagem de nova geração, com o objetivo de melhorar a eficiência em relação ao JPEG existente (não mencionado diretamente no texto original, apenas o nome técnico)
• Com a mesclagem do decodificador no Chromium, fica estabelecida a base para ativar, em nível de código, o processamento de imagens JXL
• Essa mudança representa um avanço técnico relacionado à expansão do sistema de decodificação de mídia do motor do navegador

Estado do documento

• A página é exibida como um snapshot em cache da revisão de código do Gerrit
• Há um aviso informando que o shadow DOM está oculto, mas o conteúdo real do código não é mostrado
• Portanto, as informações que podem ser confirmadas neste documento são apenas o título da mudança e o identificador da revisão (7184969)

[GN⁺]

Comentários do Hacker News

• Vi o post do blog da Cloudinary, um clássico antigo comparando webp, jpegxl, avif, jpeg etc.
  Os gráficos estão bem organizados, e o AVIF é muito lento.

  • Quando o JPEG foi configurado na menor qualidade, ele pareceu muito melhor aqui.
    Link para a seção relacionada
  • Não entendi exatamente o que este site está tentando fazer.
    Ver captura de tela
  • Se, como diz a frase citada, o JPEG XL consolidou sua posição como o melhor codec tanto com perdas quanto sem perdas, isso seria um grande avanço por poder substituir JPEG e PNG por um só formato.
  • Mas este teste não usa codificadores/decodificadores com aceleração por hardware.

• A biblioteca jxl-rs é uma implementação de JPEG XL em Rust.
  É um projeto relativamente novo, mas o uso de Rust traz tranquilidade em termos de robustez de segurança.
  Ela não existia nas discussões anteriores do Chromium.

  • Pelo que me lembro, o motivo de o Google ter rejeitado o JPEG XL foi “falta de interesse”. Não parecia ter sido por questões de segurança.
  • Não concordo com a ideia de que “Rust elimina preocupações de segurança”. Segurança de memória não é segurança em si.
    Rust pode levar a excesso de confiança, e em alguns casos isso faz com que a modelagem de ameaças seja ignorada.
    Um programador cuidadoso em C pode acabar sendo mais seguro.
  • Fui verificar quanto código unsafe existe de fato.
    Link para os resultados da busca

• Comparei WebP e AVIF recentemente, e o WebP codifica quase instantaneamente, enquanto o AVIF leva mais de 20 segundos para uma imagem de 1 MP.
  O JXL ainda tem pouco suporte, então na prática não posso usá-lo, mas espero uma velocidade no nível do WebP com qualidade melhor.

  • Dizem que o rav1e está sem atualizações há anos, então é melhor usar codificadores como aom ou svt-av1.
  • No AVIF, é preciso ajustar os parâmetros de uso de CPU. A configuração padrão usa um nível de CPU alto demais, então fica lento.
    No meu ambiente, gero um AVIF de 2 MP em cerca de 100 ms.

• É uma pena que a especificação pública (spec) do JPEG XL não seja de livre acesso.

  • Acho vergonhoso manter padrões privados.
  • O problema é a realidade de que muitos documentos de órgãos como ISO e IEC ficam atrás de paywall.

• Recebemos mais um novo formato de imagem, e fico preocupado se vamos repetir a situação em que ele acaba não sendo usável sem conversão.

  • Ainda assim, até a Microsoft lançou um add-on para JPEG XL, e agora que o Google recuou, vejo uma oportunidade real.
    Link da Microsoft Store
  • Na prática, muitos apps já oferecem suporte — Affinity, Photoshop, Microsoft Photos, Gimp e até suporte em todo o sistema no iOS 17+/macOS 12+.
    O Chromium é que está atrasado.
  • Claro, um novo formato sempre precisa de uns 10 anos de adoção.

• Lendo no wiki a lista de recursos do JPEG XL, vi funções interessantes como imagens multicanal e documentos com várias páginas.
  Tem seus pontos positivos, mas dá uma sensação de estar ficando tão complexo quanto o TIFF.

• Ainda há muita coisa em comum entre JPEG e JPEG-XL.
  Fico pensando se uma nova implementação que também integre o suporte ao JPEG antigo não poderia reduzir o tamanho do código.

  • Na verdade, já existe uma issue aberta para esse recurso no repositório Rust do JPEG-XL.
    Link para a issue #513

• Pessoalmente, prefiro continuar usando o JPEG tradicional em vez de um novo formato como WEBP.
  A maioria dos programas oferece suporte, e para o usuário comum JPEG + PNG já basta.
  Animações simples podem ficar em GIF, e as complexas podem ser tratadas como vídeo.

  • “JPEG XL”, apesar do nome, não é simplesmente uma extensão do JPEG.
    Ele permite codificação sem perdas com tamanho menor que PNG e também suporta transcodificação reversível ao comprimir JPEGs existentes em mais 20%.
    Tem HDR, gama ampla, carregamento progressivo e vários outros recursos, então também é ideal para transmissão na web.
    Veja jpegxl.info
  • O WebP agora pode ser visto como um formato padrão de fato.
    Todos os principais navegadores oferecem suporte desde o Safari 14, e ele vem incluído por padrão desde o Windows 10 e o macOS Big Sur.
    Veja estado de suporte e lista de softwares.
  • GIF agora é ineficiente. Substituí-lo por vídeo é de 5 a 10 vezes mais eficiente.
    Post relacionado

• Já ouço há muito tempo o debate entre JPEG XL, WebP e AVIF, mas nunca entendi bem.
  Pelos benchmarks, o JpegXL é superior ao WebP tanto em velocidade de compressão quanto em tamanho, então me pergunto por que o Chromium hesitou em adotá-lo.

  • WebP e AVIF compartilham código com VP8/AV1, então a integração no navegador é mais fácil, enquanto o JPEG-XL tem uma base de código separada, o que aumenta o peso da implementação.
    Além disso, a libjxl tem mais de 100 mil linhas de C++, o que trazia risco de vulnerabilidades de segurança.
    Com a implementação em Rust amadurecendo, parece que o Chrome está reconsiderando.
  • O JPEG XL suporta decodificação progressiva.
    Vídeo de demonstração
  • O Google dizia que “ter vários formatos parecidos só aumenta o risco de segurança” e que só o AVIF já bastava.
  • O AVIF é bom em bpp baixo (baixa qualidade), mas é fraco em modo sem perdas, enquanto o JXL é forte em alta qualidade e sem perdas.
  • No passado, a biblioteca C++ do JPEGXL estava em estado de manutenção interrompida, mas com o surgimento da versão em Rust, a adoção pelos navegadores passou a ser possível.

• Fiquei curioso se o JPEG XL suporta animação.

  • Suporta, mas não tem compressão entre quadros, então é ineficiente e fica maior do que um vídeo comum.
  • Segundo a página de status da plataforma Chrome, há suporte a animação, HDR e decodificação progressiva.
    Link com detalhes
  • Testei de fato no Canary, e a animação funcionou bem.
  • Alguém brincou dizendo que o WebP é, na prática, uma “imagem que é formato de vídeo”, enquanto o JPEG XL seria um “vídeo que é formato de imagem”, criando uma estrutura simétrica paradoxal 😄