Google 將 JPEG XL 帶回 Chrome

本影片重點

• Chrome 的公告於 2026 年 10 月 6 日發布，並提及 Chrome 155。它並未表明所有網站訪客都已運行支援的版本。
• Google 歸功於開發者持續的回饋和 Interop 流程。jxl-rs 解碼器使用 Rust 和優化的向量操作，同時保留了小範圍經過審核的不安全區域和瀏覽器沙盒。
• Google 宣稱的 30–50% 壓縮改進是以 JPEG 作為基準。實際節省取決於圖像、編碼器設定和視覺品質。
• Gianni Rosato 9 月的編碼器比較顯示 AVIF 在其測試的有損保真度範圍內佔優。他開發相互競爭的 AVIF 工具；他的結果和 Google 的 JPEG 基準聲明衡量的是不同的比較。
• 在代表性圖像上比較格式並保留相容的備援。JPEG XL 還支援現有 JPEG 檔案的可逆、無損轉碼。
• OpenAI 發布了 722 份手稿，分為 372 個系列，經過不同程度的驗證和許多 Lean 形式化。該模型仍未發布，Pro 等效計算數據既不是零售價格，也不是經過時間的保證。
• ESP32-C3 的開發者報告，透過將排序的域名雜湊儲存在快閃記憶體中，大約使用了 50 KB 的 RAM。DNS 級別的阻擋具有同域名和替代解析器限制；雜湊衝突可能導致過度阻擋。本集未獨立測量硬體結果。

翻譯文字稿

譯自英文原版旁白。可用的音訊和字幕由 YouTube 控制。

為什麼 Chrome 要帶回 JPEG XL？

0:00 你可能認為 Google 已經埋葬了 JPEG XL。 Chrome 正在將它帶回來，在移除了實驗性支援之後， 而 Rust 幫助它成功回歸。 在這段影片中，Google 為何會逆轉決定？ 你應該改變你的圖像處理流程嗎？ 今天是 10 月 7 日星期三，這是 The Daily Diff。 請記住一個細節。 你現有的 JPEG 有辦法參與這次回歸。

0:20 週二，Google 宣布 Chrome 155 開始支援 JPEG XL 解碼。 今天，這項公告登上了 Hacker News 的熱門， 與此同時還有 OpenAI 的數學證明傾倒以及一塊兩美元能阻擋廣告域名的電路板。 Chrome 先前的實驗於 2023 年結束。

為什麼被拒絕的格式會得到另一次機會？

0:35 Google 的解釋包括生態系統興趣不足， 當最大的瀏覽器控制著生態系統能否 實際使用你的東西時，這就顯得有些尷尬。 新的發文歸功於開發者持續的回饋， 包括 Interop 流程。 那些要求這項功能的人不斷提出要求，Google 現在指出瀏覽器測試 旨在使該格式表現一致。 這項公告歸功於包括 Helmut Januschka 在內的貢獻者。

0:57 有時候，最有效的路線圖就是拒絕關閉問題。

解碼器內部發生了什麼變化？

1:01 最大的實作變更是一個名為 jay ex ell R S 的解碼器， 以 Rust 編寫。 圖像解碼器會讀取陌生人提供的複雜檔案， 這使得它們成為一個極容易意外信任網路的地方。 Rust 有助於在記憶體錯誤成為瀏覽器 漏洞之前預防它們。Google 仍然保留沙盒，實作中也仍然 包含少量、經過仔細審查的不安全區域。 安全性有多層保護，因為現實總是能找到漏洞。

1:27 Google 表示，模糊測試和 AI 程式碼審查在此解碼器的歷史中未發現任何記憶體安全漏洞。 這是開發團隊提供的有用報告。 未來的攻擊者不太可能將部落格文章視為具有約束力的合約。 第一個問題已回答。 開發者壓力加上優化的 Rust 解碼器重新開啟了大門。 Google 撤銷了一個有工程依據的決定， 這即使在網路上也是允許的。 現在是幻燈片基準測試。

較小的檔案能擊敗 AVIF 嗎？

1:48 Google 宣稱比 JPEG 壓縮效果好 30% 到 50%。 更小的下載量可以幫助你的使用者和頻寬費用， 但這個範圍取決於你編碼的內容以及你如何比較品質。 壓縮工程師 Gianni Rosato 於 九月發布了一項比較，其中現代 avif 編碼器在他的測試保真度範圍內擊敗了 JPEG XL。 他從事競爭性的 avif 工具開發，因此請在圖表旁邊記下這一動機。 這些比較使用了不同的基準。

2:12 擊敗舊的 JPEG 為 avif 贏得工作量留下了空間。 Google 本身建議嘗試兩種格式，這對於發布公告來說是異常實用的 建議。 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 的路徑。 這讓舊的圖像檔案庫有了遷移選項，而不會造成 另一代的品質損失。 測試儲存和傳輸的權衡。 如果你寧願閱讀而不是聽我說，The Daily Diff 每天早上都會免費寄到你的收件匣，網址是 the daily diff dot dev，連結在下方。 每天早上都會免費寄到你的收件匣，網址是 the daily diff dot dev，連結在下方。

為什麼我要部署解碼器並測試遷移？

4:58 所以今天的判決是，SHIP IT。 我會部署額外的解碼器，因為瀏覽器支援給了開發者一個真正的 選擇，我會測試我們自己圖像的遷移。 訂閱、點擊鈴鐺，並在評論中告訴我你是否會蓋上 不同的戳記。今天的 Daily Diff 就是這些。 我是來自 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