Google ressuscitou o suporte ao JPEG XL?

 (tonisagrista.com)
5 pontos por GN⁺ 2025-12-03 | 2 comentários | Compartilhar no WhatsApp
  • Com a restauração do suporte ao JPEG XL pelo motor Chromium, um formato de imagem que já havia sido descontinuado voltou a chamar atenção
  • Em 2022, a Google removeu o JPEG XL alegando "falta de interesse suficiente do ecossistema", mas a pressão contínua da comunidade e de empresas importantes permaneceu
  • Organizações como Meta, Intel, Adobe, Cloudinary, Krita declararam publicamente o apoio à necessidade de manter o formato
  • Recentemente, o movimento ganhou força após o PDF Association anunciar a intenção de adotar o JPEG XL como formato base para conteúdo HDR
  • A decisão de reintrodução no Chrome é vista como um ponto de virada que aumenta a chance do JPEG XL se tornar um padrão amplamente adotado

Histórico do retorno do JPEG XL

  • Em 2022, a equipe do Chromium removeu o JPEG XL por "falta de interesse suficiente no ecossistema" e "falta de vantagem em relação aos formatos existentes"
    • Naquela época, a comunidade manifestou apoio de organizações importantes como Meta, Intel, Cloudinary, Adobe, ffmpeg, libvips, Krita
    • Em seguida, surgiram reações em blogs, vídeos e redes sociais apontando a inadequação da decisão de remoção
  • No final de 2025, a equipe do Chromium mudou a issue do JPEG XL, que estava no estado Obsolete, para Assigned, iniciando oficialmente o processo de restauração
    • No grupo de desenvolvedores do Blink, Rick Byers afirmou que "recebe com entusiasmo um decodificador JPEG XL com bom desempenho e seguro em relação à memória"
    • Essa decisão se baseia em sinais positivos como suporte da Safari, mudança de posição do Firefox e movimento de adoção da PDF Association

Firefox e o desenvolvimento do decodificador baseado em Rust

  • A equipe do Firefox levantou a necessidade de uma versão em Rust, "memory-safe", por recear riscos de segurança no decodificador libjxl baseado em C++
    • Em resposta, o Google Research iniciou o desenvolvimento da implementação em Rust jxl-rs
    • Esse projeto foi um marco para aumentar a possibilidade de integração segura do JPEG XL em navegadores

Movimento de adoção do PDF Association

  • O CTO do PDF Association, Peter Wyatt, anunciou a intenção de incluir o JPEG XL como o formato padrão de imagem HDR na especificação de PDF
    • Isso atua como um fator que fortalece a possibilidade de padronização do JPEG XL no campo de documentos e publicação

Principais características técnicas do JPEG XL

  • Suporta recompressão sem perdas de JPEGs existentes, o que pode economizar cerca de 30% do espaço sem perder qualidade
  • Suporta gama de cores ampla e HDR, até 32 bits por canal e processamento de 4,099 canais
  • Suporta imagens de até 1,073,741,823×1,073,741,824 , permitindo o processamento de imagens gigantescas
  • Suporta decodificação progressiva para melhorar a eficiência de entrega na web
  • Inclui animação, transparência alpha e mapa de profundidade (depth map)
  • Estrutura com baixa degradação por geração, minimizando perda de qualidade em recodificações repetidas

Conclusão

  • O JPEG XL atende aos requisitos de um formato de imagem de próxima geração, e o retorno do Chrome é um marco decisivo para a adoção em massa
  • A restauração, obtida após pressão prolongada da comunidade, impulsiona o JPEG XL como novo candidato a padrão no ecossistema de imagens da web
  • O autor celebra a reavaliação da Chromium, mas também observa que essa decisão foi tomada tarde demais

Leituras relacionadas

2 comentários

 
GN⁺ 2025-12-03
Comentários no Hacker News

  • Um dos recursos menos conhecidos e mais legais do JPEG XL é um modo que transcodifica sem perdas a partir de JPEG e ainda economiza cerca de 20% de espaço de armazenamento
    Como preserva o bitstream de entropia original, é totalmente reversível
    O GCP está aplicando isso à DICOM Store API, então dá para aproveitar a economia de espaço do JXL e ainda entregar os arquivos convertendo para JPEG em tempo real
    Nossa empresa armazena dezenas de PB de dados no GCP DICOM Store, então esperamos que esse recurso reduza bastante a fatura anual
    Também temos esperança de suporte nativo no navegador, e ouvi dizer que a equipe do Chrome deve acabar dando suporte

    • Fico curioso sobre a diferença em relação a um encoder JPEG comum ou ao mozjpeg
    • Nunca tive tempo de testar o GCP DICOM Store no passado, então queria saber como ele é na prática
      Queria entender se é um PACS completo, uma implementação de WADO ou só uma API customizada simples
    • Se é reversível, então não bastaria armazenar em JPEG XL e reconverter na hora de servir?
      Pergunta se o processamento é pesado
    • Se de qualquer forma é preciso armazenar o DICOM original, fico na dúvida sobre o sentido da transcodificação
      Parece que a maior parte do custo de armazenamento viria do próprio DICOM
    • No fim, como os grandes clientes do GCP ganham muito com esse recurso, dá a impressão de que o motivo para empurrar JXL no Chrome vem de clientes internos

  • O concorrente do JPEG XL não é o AVIF
    O AVIF já se estabeleceu como padrão de fato, quase todos os navegadores dão suporte e ele também é usado como formato de imagem padrão da Apple
    O JXL ainda tem pouco suporte em navegadores, mas está encontrando espaço em nichos como arquivamento, fotografia profissional e uso médico
    Daqui a uns 10 anos, pode ficar tão difundido que as pessoas simplesmente o chamem de “JPEG”
    O AVIF é um padrão aberto e livre de royalties, tem eficiência de compressão muito maior que JPEG/WebP e em nível parecido com o JXL
    O JXL tem tamanho máximo de imagem maior, mas em adoção o AVIF está muito à frente
    Quando o AV2 sair, a diferença de qualidade quase deve desaparecer, e os dois formatos provavelmente continuarão evoluindo mantendo níveis de qualidade parecidos

    • É óbvio que o AVIF é mais eficiente que JPEG ou WebP em compressão, mas com JXL ele não compete
      Em configurações de qualidade realistas, o JXL mostra compressão melhor e codificação/decodificação mais rápida
      Além disso, também suporta progressive decoding
      Quando o AV2 sair ele talvez alcance, mas por enquanto acho que o JXL está bem à frente
    • Um dos motivos pelos quais a equipe do Chrome interrompeu o suporte a JXL foi que o AVIF já era bom o suficiente
      Parece que esta reavaliação está ligada àquela decisão
    • A afirmação de que “o formato de imagem padrão da Apple é AVIF” parece errada
      O iPhone usa HEIF
    • Já usei o libjxl diretamente e ele tinha uso de memória alto e pouca estabilidade
      Para codificar imagens de altíssima resolução, chegava a parecer que precisava de RAM na casa dos terabytes
      Fiquei surpreso com a bagunça do codebase, e várias opções não funcionavam direito
      É positivo tentar de novo com jxl-rs, mas como os mesmos desenvolvedores estão envolvidos, estou acompanhando com cautela

  • É bem provável que o Chromium use a crate jxl-rs para o recurso de JPEG XL
    Talvez esteja esperando ela amadurecer o suficiente antes de integrar
    O issue relacionado pode ser visto aqui

    • A Mozilla tinha uma posição parecida, mas o Google por um tempo mostrou uma postura hostil
      Fechou o issue apesar da oposição dos usuários, e só recentemente o reabriu
      Talvez tenha sido por questões de PR ou descontentamento interno
    • Houve um período de mais de um ano e meio sem commits no jxl-rs
      O fato de estar andando bem agora pode ser só resultado de sorte

  • Vi a implementação de referência (C++) do JPEG XL, e até 2 anos atrás a qualidade do código não era boa
    Dava a sensação de que surgiriam problemas de segurança

    • Por isso tanto Mozilla quanto Google estão considerando suporte a JXL com a condição de haver uma implementação memory-safe
      Uma versão em Rust está em desenvolvimento, e o Google tem planos de gradualmente substituir todos os decodificadores do Chromium por Rust
    • Na verdade, neste momento (2025), um grande código de processamento de imagem escrito em C++ já é por si só um risco de segurança
      Não é um problema exclusivo do JPEG XL

  • A resolução máxima do JPEG XL é 1.073.741.823 × 1.073.741.824, o que permite representar imagens ultra-altas de resolução na casa de centenas de petabytes
    Na prática, mesmo comprimidas ainda ficariam em dezenas a centenas de PB

    • Em 600 DPI, um dos lados equivale à distância de uma maratona
      Se fosse possível definir uma imagem tão gigantesca em poucos bytes, isso também poderia virar um vetor de ataque de DOS
      Ao tentar converter para folhas A4, a calculadora Gemini confundiu as unidades e deu um resultado sem sentido
    • A única forma prática de lidar com imagens tão gigantes é com tiling e estrutura piramidal
    • Deve ser algo do tamanho de uma imagem da Terra inteira com resolução de cerca de 4 cm
    • Tirar uma selfie nessa resolução seria algo no nível de um microscópio de super-resolução
    • Diferentemente do AVIF, o JPEG XL suporta progressive decoding eficiente, então dá para ver rapidamente uma prévia de baixa qualidade enquanto o download ainda está acontecendo

  • Coletânea de discussões antigas no HN
    Chromium Team Re-Opens JPEG XL Feature Ticket
    FSF Slams Google over Dropping JPEG-XL in Chrome
    Google set to deprecate JPEG XL support in Chrome 110
    Chromium jpegxl issue closed as won't fix

  • Já uso .avif há alguns anos
    Não é perfeito, mas acho muito melhor que .jpg ou .png
    Também considerei .webp e jpeg-xl, mas no fim fiquei satisfeito com .avif
    Ainda assim, me incomoda que o Google praticamente dite as regras dos padrões da web
    Não é desejável que uma empresa comercial controle o ecossistema digital

    • A frase “.avif é melhor que .jpg” confunde porque repete .avif duas vezes
    • Se você quer deixar JPEGs de alta qualidade menores, recomendo usar jpegli
      jpegli GitHub
      Se você ajustar bem a configuração visualmente sem perdas do AVIF, ele pode ficar menor que o jpegli, mas em média o jpegli é mais eficiente
    • Só como observação, em inglês “for several years” soa mais natural que “since some years”
    • O JPEG XL perde menos qualidade em salvamentos repetidos, então é vantajoso para a web
      Vídeo relacionado: link do YouTube

  • Quem removeu o JXL não foi “o Google inteiro”, e sim a equipe do Chrome
    O JXL foi projetado por Jyrki Alakuijala, do laboratório do Google em Zurique, e ele pertence ao Google Research, não à equipe do Chrome
    A equipe do Chrome tem uma cultura fechada centrada em Mountain View

    • Jyrki é um engenheiro brilhante que também criou Brotli, WebP lossless, WOFF2 e jpegli
      O fato de ele ter criado o jpegli depois do descarte do JpegXL também foi, em certo sentido, uma reação
    • Esta situação talvez possa ser explicada pela Lei de Conway

  • Parece que o JXL foi atrasado por causa da grande quantidade de dependências multithread baseadas em C++, o que pode ampliar a superfície de ataque
    Tanto Mozilla quanto Google preferem uma implementação em Rust para evitar isso
    O padrão em si é claramente um formato melhor que os anteriores

    • Falar em 100 milhões de linhas parece um número exagerado demais
    • Na prática, são cerca de 30 mil linhas, e a versão single-thread tem algo perto de 10 mil
      O binário também é muito menor que o do AVIF, e a especificação é muito mais concisa
    • Como o Google participou do desenvolvimento do JXL, não ter feito rapidamente um decodificador memory-safe é responsabilidade dele próprio
    • Será que você não quis dizer algo como 100 mil linhas? Uma parte considerável disso provavelmente é código de teste
    • O libjxl real tem cerca de 112 mil linhas, o que deixa a alegação de 100 milhões com diferença de três ordens de grandeza

  • Dizem que os arquivos RAW do iPhone 17 Pro são comprimidos com JPEG XL