谷歌将JPEG XL带回Chrome

本视频涵盖的内容

• Chrome的公告发布于2026年10月6日，并提到了Chrome 155。它没有证实每个网站访问者都已运行支持的版本。
• 谷歌归功于持续的开发者反馈和互操作过程。jxl-rs解码器使用Rust和优化的矢量操作，同时保留了经过审查的小型不安全区域和浏览器沙盒。
• 谷歌宣称的30–50%压缩改进以JPEG为基准。实际节省取决于图像、编码器设置和视觉质量。
• Gianni Rosato在9月的编码器比较中，在其测试的有损保真范围内偏爱AVIF。他开发了竞争的AVIF工具；他的结果和谷歌的JPEG基准声明衡量的是不同的比较。
• 在代表性图像上比较格式，并保留兼容的回退方案。JPEG XL还支持现有JPEG文件的可逆、无损转码。
• OpenAI发布了722份手稿，分为372个系列，验证程度各不相同，并且有许多Lean形式化。模型仍未发布，Pro等效计算数据既不是零售价格，也不是经过时间保证。
• ESP32-C3的创建者报告称，通过在闪存中存储排序的域哈希，RAM使用量约为50 KB。DNS级别的阻塞存在同域和替代解析器限制；哈希冲突可能导致过度阻塞。本期节目未独立测量硬件结果。

翻译的文字记录

译自英文原版旁白。可用音频和字幕由 YouTube 控制。

为什么Chrome要带回JPEG XL？

0:00 你可能认为谷歌已经把JPEG XL埋葬了。 Chrome正在将其带回，在移除了实验性支持之后， 而Rust帮助它重新进入了视野。 在这段视频中，谷歌为什么会改变主意？ 你是否应该改变你的图像处理流程？ 今天是10月7日星期三，这里是The Daily Diff。 记住一个细节。 你现有的JPEG文件可以通过某种方式加入这次回归。

0:20 周二，谷歌宣布从Chrome 155开始支持JPEG XL解码。 今天，这一公告登上了Hacker News头条， 同时还有OpenAI的数学证明大放送，以及一块两美元的板子，可以阻止 广告域名。Chrome早期的实验于2023年结束。

为什么这个被拒绝的格式又获得了机会？

0:35 谷歌的解释包括生态系统兴趣不足， 当最大的浏览器控制着生态系统能否实际使用你的东西时，这很尴尬。 是的。 新帖子归功于持续的开发者反馈， 包括互操作过程。 那些要求这个功能的人一直在要求，谷歌现在指出浏览器测试 旨在使格式行为一致。 公告归功于包括Helmut Januschka在内的贡献者。

0:57 有时最有效的路线图就是拒绝关闭问题。

解码器内部发生了什么变化？

1:01 最大的实现变化是一个名为jay ex ell R S的解码器， 用Rust编写。 图像解码器接收陌生人提供的复杂文件， 这使得它们成为一个容易不小心信任互联网的绝佳场所。 Rust有助于在内存错误成为浏览器漏洞之前，防止此类错误。 谷歌仍然保留沙盒，并且实现仍然 包含小的、经过仔细审查的不安全区域。 安全性需要分层，因为现实总能找到漏洞。

1:27 谷歌表示，模糊测试和AI代码审查在该解码器的历史中没有发现内存安全错误。 这是发布团队提供的有用报告。 未来的攻击者不太可能接受这篇博客文章作为具有约束力的合同。 第一个问题回答完毕。 开发者的压力和优化的Rust解码器重新打开了大门。 谷歌推翻了一个有工程支持的决定， 即使在互联网上也是允许的。 现在是幻灯片基准测试。

这些更小的文件能打败AVIF吗？

1:48 谷歌宣传比JPEG有30%到50%的更好压缩。 更小的下载量可以帮助你的用户和带宽费用， 但这个范围取决于你编码的内容和比较质量的方式。 压缩工程师Gianni Rosato发表了 9月份的比较，其中现代 AVIF编码器在他的测试保真度范围内击败了JPEG XL。 他从事竞争性的AVIF工具开发，所以请将这个动机与图表放在一起考虑。 这些比较使用了不同的基准。

2:12 击败旧的JPEG为AVIF赢得工作负载留下了空间。 谷歌自己建议尝试两种格式，这对于发布公告来说是非常实用的建议。 是的。 JPEG XL的其他吸引力包括高动态范围， 无损图像和细粒度渐进式解码。 社区发布了交互式演示以探索该格式。 当其余部分到达时，您的受众可以看到一张有用的图片。 对于部署，请保留一个备用图像，并在您的客户实际使用的浏览器中验证支持。

2:37 是的。 公告中提到了Chrome 155。 这为您提供了一个目标版本，您的分析会告诉您您的受众何时达到该版本。 第二个问题回答完毕。 在改变流水线之前测试您的实际图像，并保留 兼容性路径。节省字节的图像格式很有用。 隐藏结账按钮的迁移是对极简主义的昂贵解读。 与此同时，OpenAI于周二发布了数学手稿和支持

OpenAI到底发布了什么？

3:00 的证明工件。 该存储库包含722份手稿， 按相关家族分组。 标题计数包括伴随论证和替代证明， 所以请阅读每篇论文实际主张的内容。 许多都有Lean中的形式证明，这让计算机可以检查数学 推导。其他仍在等待形式化， OpenAI明确警告说

3:21 一些非形式化的结果可能存在问题。 该存储库为研究人员提供了可以检查和挑战的材料。 该模型仍未发布。 OpenAI表示，每个结果平均使用了大约三小时的等效ChatGPT Pro 思考计算。 这描述了计算工作。 它既不提供挂钟时间 保证，也不提供生成定理的零售价格。

3:40 该发布是在咨询一个独立的数学咨询小组后进行的， 并包括修订和引用流程。 学术界获得了一堆新作业，以及更有用的能力，可以指出 需要修复的确切页面。 Lean维护者建议一次只编译少量部分。 即使是数学上的突破最终也 会遇到软件的古老敌人， 就是让构建完成。

一块两美元的板子如何阻止域名？

4:03 最后，一个开源的DNS广告拦截器运行在一个微小的两美元微控制器 板上。创建者的诀窍是将排序后的域名哈希存储在闪存中， 这样黑名单就不必存储在稀缺的工作内存中。 该项目报告大约50 KB的RAM使用量。 它在闪存表中查找请求的域名， 匹配则阻止，并将其他查询转发到上游。 您的路由器可以拥有一个带有非常特定宾客名单的微型保镖。 DNS过滤在域名级别工作。

4:28 与有用内容来自同一域名的广告可能会溜走， 使用其他解析器的客户端可以绕过它。 保持您的期望小于电路板，这是一个要求很高的尺寸目标。 关于您现有JPEG的细节呢？

你现有的JPEG能加入这次回归吗？

4:40 JPEG XL支持无损JPEG转码， 并提供重建原始JPEG的路径。 这为旧图像档案提供了一个迁移选项，而不会造成 另一代质量损失。 测试存储和交付的权衡。 如果您宁愿阅读这些内容而不是听我讲，那么每日摘要每天早上都会免费发送到您的收件箱， 网址是daily diff dot dev，链接在下方。

我为什么要部署解码器并测试迁移？

4:58 所以今天的裁决是，SHIP IT。 我会部署额外的解码器，因为浏览器支持给了开发者真正的选择， 我也会在我们的图片上测试迁移。 订阅，点击铃铛，并在评论中告诉我你是否会有不同的看法。 这就是今天的差异。 我是来自Axrisi的Niko。 负责任地合并。

来源

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