Google traz JPEG XL de volta ao Chrome

O que este vídeo aborda

• O anúncio do Chrome foi publicado a 6 de outubro de 2026 e menciona o Chrome 155. Não estabelece que todos os visitantes do website já estejam a executar uma versão suportada.
• A Google atribui o mérito ao feedback persistente dos programadores e ao processo Interop. O descodificador jxl-rs utiliza Rust e operações vetoriais otimizadas, enquanto pequenas áreas inseguras verificadas e a "sandbox" do navegador permanecem.
• A melhoria de compressão de 30 a 50% anunciada pela Google utiliza JPEG como sua referência. As poupanças reais dependem das imagens, das configurações do codificador e da qualidade visual.
• A comparação de codificadores de Gianni Rosato, em setembro, favorece o AVIF em toda a sua gama de fidelidade com perdas testada. Ele desenvolve ferramentas AVIF concorrentes; o seu resultado e a afirmação de base JPEG da Google medem comparações diferentes.
• Compare formatos em imagens representativas e mantenha "fallbacks" compatíveis. O JPEG XL também suporta transcodificação reversível e sem perdas de ficheiros 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 não lançado, e os valores de computação equivalentes a Pro não são um preço de retalho 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 ao nível do DNS tem limitações de mesmo domínio e "resolver" alternativo; colisões de "hash" podem sobrebloquear. 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.

Porque é que o Chrome está a trazer o JPEG XL de volta?

0:00 Provavelmente pensa que a Google enterrou o JPEG XL. O Chrome está a trazê-lo de volta, depois de remover o suporte experimental, e o Rust ajudou-o a entrar pela porta. Neste vídeo, por que é que a Google inverteu o curso? E deveria mudar o seu "pipeline" de imagens? É quarta-feira, sete de outubro, e este é o The Daily Diff. Tenha um detalhe em mente. Os seus JPEGs existentes têm uma forma de entrar neste regresso.

0:20 Na terça-feira, a Google anunciou a descodificação de JPEG XL a partir do Chrome 155. Hoje, o anúncio subiu no Hacker News, juntamente com o "dump" de provas matemáticas da OpenAI e uma placa de dois dólares que bloqueia domínios de publicidade. A experiência anterior do Chrome terminou em 2023.

Porque é que o formato rejeitado teve outra oportunidade?

0:35 A explicação da Google incluía interesse insuficiente do ecossistema, o que é estranho quando o maior navegador controla se o ecossistema pode realmente usar a sua coisa. A nova publicação atribui o mérito ao feedback persistente dos programadores, incluindo o processo Interop. As pessoas que pediram isto continuaram a pedir, e a Google agora aponta para testes de navegador destinados a fazer com que o formato se comporte de forma consistente. O anúncio atribui o mérito a contribuidores, incluindo Helmut Januschka.

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

O que mudou dentro do descodificador?

1:01 A maior alteração na implementação é um descodificador chamado "jay ex ell R S", escrito em Rust. Os descodificadores de imagem ingerem ficheiros 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. A Google ainda mantém a "sandbox", e a implementação ainda contém pequenas áreas inseguras cuidadosamente revistas. A segurança tem camadas, porque a realidade continua a encontrar as falhas.

1:27 A Google diz que "fuzzing" e revisão de código por IA não encontraram erros de segurança de memória na história deste descodificador. Esse é um relatório útil da equipa que o está a enviar. É improvável que futuros atacantes aceitem a publicação do blogue como um contrato vinculativo. Primeira pergunta respondida. A pressão dos programadores e um descodificador Rust otimizado reabriram a porta. A Google inverteu uma decisão com engenharia por trás, o que é permitido mesmo na internet. Agora os "benchmarks" da apresentação.

Os ficheiros mais pequenos vencem o AVIF?

1:48 A Google anuncia uma compressão trinta a cinquenta por cento melhor do que o JPEG. Transferências menores podem ajudar os seus utilizadores e a fatura de largura de banda, mas essa gama depende do que você codifica e de como você compara a qualidade. O engenheiro de compressão Gianni Rosato publicou uma comparação de setembro onde codificadores avif modernos superaram o JPEG XL em toda a sua gama 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 Vencer o antigo JPEG deixa espaço para o avif ganhar uma carga de trabalho. A própria Google recomenda experimentar ambos os formatos, o que é um conselho invulgarmente prático para um anúncio de lançamento. Outras atrações do JPEG XL incluem alta gama dinâmica, imagens sem perdas e descodificação progressiva granular. A comunidade publica "demos" interativos para explorar o formato. O seu público pode ver uma imagem útil enquanto o resto chega. Para a implementação, mantenha uma imagem de "fallback", e verifique o suporte nos navegadores que os seus

2:37 clientes realmente usam. O anúncio menciona o Chrome 155. Isso dá-lhe uma versão-alvo, e os seus dados de análise dizem-lhe quando o seu público chega lá. Segunda pergunta respondida. Teste as suas imagens reais antes de alterar o "pipeline", e preserve o caminho de compatibilidade. Um formato de imagem que economiza bytes é útil. Uma migração que esconde o seu botão de "checkout" é uma interpretação cara do minimalismo. Enquanto isso, a OpenAI publicou manuscritos matemáticos e "proof artifacts"

O que é que a OpenAI publicou realmente?

3:00 de apoio 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 podem inspecionar e desafiar. O modelo permanece não lançado. A OpenAI diz que cada resultado usou, em média, cerca de três horas de computação equivalente a ChatGPT Pro para pensar. Isso descreve o esforço computacional. Não lhe dá uma garantia de tempo decorrido nem um preço de retalho para produzir um

3:40 teorema. O lançamento segue consulta com um grupo consultivo independente de matemática, e inclui um processo de revisão e citação. A academia recebe uma nova pilha de trabalho de casa, mais a 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 de cada vez. Mesmo uma descoberta matemática acaba por encontrar o inimigo ancestral do "software", fazer com que a compilação termine.

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

4:03 Finalmente, um bloqueador de anúncios DNS de código aberto funciona num pequeno "microcontroller" de dois dólares A manobra do criador é armazenar "hashes" de domínio ordenados na "flash", para que a lista de bloqueio não precise de residir na escassa memória de trabalho. O projeto reporta aproximadamente cinquenta kilobytes de uso de RAM. Ele procura um domínio solicitado na tabela "flash", bloqueia uma correspondência e encaminha outras consultas para "upstream". O seu "router" pode adquirir um pequeno segurança com uma lista de convidados muito específica. A filtragem de DNS funciona ao nível do domínio.

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

Os seus JPEGs existentes podem juntar-se ao regresso?

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

Porque é que eu enviaria o descodificador e testaria a migração?

4:58 Então, o veredicto de hoje, SHIP IT. Eu enviaria o descodificador adicional porque o suporte do navegador dá aos programadores uma escolha real, e testaria a migração nas nossas próprias imagens. Subscreva, carregue no sino e diga-me nos comentários se o teria carimbado de forma diferente. E essa é a "diff" de hoje. Sou o 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