Google traz JPEG XL de volta ao Chrome

O que este vídeo aborda

• O anúncio do Chrome foi publicado em 6 de outubro de 2026 e menciona o Chrome 155. Ele não estabelece que todo visitante do site já use uma versão suportada.
• O Google atribui o mérito ao feedback persistente dos desenvolvedores e ao processo Interop. O decodificador jxl-rs usa Rust e operações vetoriais otimizadas, enquanto pequenas áreas inseguras verificadas e a "sandbox" do navegador permanecem.
• A melhoria de compressão anunciada pelo Google, de 30-50%, usa JPEG como base. As economias reais dependem das imagens, configurações do codificador e qualidade visual.
• A comparação de codificadores de setembro de Gianni Rosato favorece o AVIF em sua faixa de fidelidade "lossy" testada. Ele desenvolve ferramentas AVIF concorrentes; seu resultado e a afirmação de base JPEG do Google medem comparações diferentes.
• Compare os formatos em imagens representativas e mantenha "fallbacks" compatíveis. JPEG XL também suporta transcodificação reversível e sem perdas de arquivos JPEG existentes.
• A OpenAI lançou 722 manuscritos agrupados em 372 famílias, com verificação variada e muitas formalizações Lean. O modelo permanece inédito, e os números de computação equivalentes ao Pro não são um preço de varejo nem uma garantia de tempo decorrido.
• O criador do ESP32-C3 relata aproximadamente 50 KB de uso de RAM ao armazenar hashes de domínio ordenados na "flash". O bloqueio em nível de DNS tem limitações de mesmo domínio e "resolvers" alternativos; colisões de "hash" podem bloquear excessivamente. Os resultados de hardware não foram medidos independentemente para este episódio.

Transcrição traduzida

Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.

Por que o Chrome está trazendo o JPEG XL de volta?

0:00 Você provavelmente pensa que o Google enterrou o JPEG XL. O Chrome está trazendo-o de volta, depois de remover o suporte experimental, e o Rust ajudou-o a entrar pela porta. Neste vídeo, por que o Google reverteu o curso? E você deve mudar seu "pipeline" de imagens? É quarta-feira, sete de outubro, e este é o The Daily Diff. Mantenha um detalhe em mente. Seus JPEGs existentes têm um caminho para este retorno.

0:20 Na terça-feira, o Google anunciou a decodificação de JPEG XL a partir do Chrome cento e cinquenta e cinco. Hoje, o anúncio subiu no Hacker News, junto com o despejo de provas matemáticas da OpenAI e uma placa de dois dólares que bloqueia domínios de publicidade. O experimento anterior do Chrome terminou em vinte e vinte e três.

Por que o formato rejeitado teve outra chance?

0:35 A explicação do Google incluiu interesse insuficiente do ecossistema, o que é estranho quando o maior navegador controla se o ecossistema pode realmente usar sua coisa. A nova postagem credita o feedback persistente dos desenvolvedores, incluindo o processo Interop. As pessoas que pediam por isso continuaram pedindo, e o Google agora aponta para testes de navegador destinados a fazer com que o formato se comporte de forma consistente. O anúncio credita colaboradores incluindo Helmut Januschka.

0:57 Às vezes, o "roadmap" mais eficaz é recusar-se a fechar a questão.

O que mudou dentro do decodificador?

1:01 A maior mudança de implementação é um decodificador chamado jay ex ell R S, escrito em Rust. Decodificadores de imagem ingerem arquivos complicados fornecidos por estranhos, o que os torna um lugar espetacular para acidentalmente confiar na internet. O Rust ajuda a prevenir classes de erros de memória antes que se tornem vulnerabilidades do navegador. O Google ainda mantém a "sandbox", e a implementação ainda contém pequenas áreas inseguras cuidadosamente revisadas. A segurança tem camadas, porque a realidade continua encontrando as brechas.

1:27 O Google diz que "fuzzing" e revisão de código por IA não encontraram bugs de segurança de memória na história deste decodificador. Isso é um relatório útil da equipe que o está enviando. Futuros atacantes são improváveis de aceitar a postagem do blog como um contrato vinculativo. Primeira pergunta respondida. A pressão dos desenvolvedores e um decodificador Rust otimizado reabriram a porta. O Google reverteu uma decisão com engenharia por trás dela, o que é permitido até na internet. Agora, os benchmarks da apresentação.

Os arquivos menores superam o AVIF?

1:48 O Google anuncia trinta a cinquenta por cento melhor compressão que o JPEG. Downloads menores podem ajudar seus usuários e sua conta de largura de banda, mas essa faixa depende do que você codifica e como você compara a qualidade. O engenheiro de compressão Gianni Rosato publicou uma comparação em setembro onde os "encoders" modernos avif superaram o JPEG XL em sua faixa de fidelidade testada. Ele trabalha em ferramentas avif concorrentes, então mantenha esse incentivo ao lado dos gráficos. Essas comparações usam "baselines" diferentes.

2:12 Superar o JPEG antigo deixa espaço para o avif vencer uma carga de trabalho. O próprio Google recomenda experimentar ambos os formatos, o que é um conselho incomumente prático para um anúncio de lançamento. Outras atrações do JPEG XL incluem alta faixa dinâmica, imagens sem perdas e decodificação progressiva granular. A comunidade publica demos interativas para explorar o formato. Sua audiência pode ver uma imagem útil enquanto o restante chega. Para implantação, mantenha uma imagem "fallback" e verifique o suporte nos navegadores que seus

2:37 clientes realmente usam. O anúncio menciona o Chrome cento e cinquenta e cinco. Isso lhe dá uma versão alvo, e sua análise informa quando sua audiência chega lá. Segunda pergunta respondida. Teste suas imagens reais antes de mudar o "pipeline" e preserve o caminho de compatibilidade. Um formato de imagem que economiza bytes é útil. Uma migração que oculta seu botão de finalização de compra é uma interpretação cara do minimalismo. Enquanto isso, a OpenAI publicou manuscritos matemáticos e artefatos de prova

O que a OpenAI realmente publicou?

3:00 de suporte na terça-feira. O repositório contém setecentos e vinte e dois manuscritos, agrupados em famílias relacionadas. A contagem principal inclui argumentos complementares e provas alternativas, então leia o que cada artigo realmente afirma. Muitos têm provas formais em Lean, o que permite que um computador verifique deduções matemáticas. Outros ainda aguardam formalização, e a OpenAI avisa explicitamente que

3:21 alguns resultados não formalizados podem ter problemas. O repositório entrega aos pesquisadores material que eles podem inspecionar e desafiar. O modelo permanece inédito. A OpenAI diz que cada resultado usou aproximadamente três horas de computação de "thinking" equivalente ao ChatGPT Pro em média. Isso descreve o esforço computacional. Isso não lhe dá uma garantia de "wall clock" nem um preço de varejo para produzir um

3:40 teorema. O lançamento segue consulta com um grupo consultivo de matemática independente, e inclui um processo de revisão e citação. A academia recebe uma nova pilha de lição de casa, além da capacidade muito mais útil de apontar para a página exata que precisa de correção. Os mantenedores do Lean recomendam compilar pequenas porções por vez. Mesmo uma descoberta matemática eventualmente encontra o antigo inimigo do software, fazer a construção terminar.

Como uma placa de dois dólares bloqueia domínios?

4:03 Finalmente, um bloqueador de anúncios DNS de código aberto roda em uma minúscula placa de microcontrolador de dois dólares. O truque do criador é armazenar "hashes" de domínio classificados na "flash", para que a "blacklist" não precise viver na escassa memória de trabalho. O projeto relata aproximadamente cinquenta kilobytes de uso de RAM. Ele procura um domínio solicitado na tabela "flash", bloqueia uma correspondência e encaminha outras consultas "upstream". Seu roteador pode adquirir um pequeno "bouncer" com uma lista de convidados muito específica. A filtragem de DNS funciona no nível do domínio.

4:28 Anúncios veiculados do mesmo domínio que conteúdo útil podem passar, e clientes que usam outro "resolver" podem ignorá-lo. Mantenha suas expectativas menores que a placa, que é um alvo de tamanho exigente. E o detalhe sobre seus JPEGs existentes?

Seus JPEGs existentes podem participar do retorno?

4:40 JPEG XL suporta transcodificação JPEG sem perdas, com um caminho para reconstruir o JPEG original. Isso oferece a um arquivo de imagem antigo uma opção de migração sem outra geração de perda de qualidade. Teste as "tradeoffs" de armazenamento e entrega. Se você preferir ler isso a me ouvir dizer, o "diff" chega na sua caixa de entrada todas as manhãs, gratuitamente em the daily diff dot dev, link abaixo.

Por que eu enviaria o decodificador e testaria a migração?

4:58 Então o veredito de hoje, SHIP IT. Eu enviaria o decodificador adicional porque o suporte do navegador oferece aos desenvolvedores uma escolha real, e eu testaria a migração em nossas próprias imagens. Inscreva-se, clique no sino e me diga nos comentários se você teria carimbado diferente. E esse é o "diff" de hoje. Sou Niko da Axrisi. Mescle com responsabilidade.

Fontes

1. Shipping JPEG XL in ChromeChrome for Developers
2. JPEG XL prototype and November 2022 removal discussionChromium Blink developers
3. Contemporaneous JPEG XL deprecation commentaryFree Software Foundation
4. The case against JPEG XL — competing-encoder benchmarkGianni Rosato
5. JPEG XL FAQ and reversible JPEG transcodingJPEG XL community
6. HTML picture element and fallback selectionMDN Web Docs
7. Progressive loading demoJPEG XL community
8. Distance versus effort visualizerJPEG XL community
9. Sharing AI progress in mathematicsOpenAI
10. Mathematical manuscripts and proof artifactsOpenAI on GitHub
11. Lean formalization library build notesOpenAI on GitHub
12. ESP32-C3 hash-in-flash DNS ad blockerM-Abozaid on GitHub