GoogleがJPEG XLをChromeに再導入

この動画の要点

• Chromeの発表は2026年10月6日に公開され、Chrome 155を対象としています。すべてのウェブサイト訪問者がすでにサポートされているバージョンを実行していることを確立するものではありません。
• Googleは、開発者からの根強いフィードバックとInteropプロセスを高く評価しています。jxl-rsデコーダーはRustと最適化されたベクトル演算を使用しており、小さな検証済みのunsafe領域とブラウザサンドボックスは残っています。
• Googleが宣伝している30～50%の圧縮改善は、JPEGを基準としています。実際の節約は、画像、エンコーダー設定、視覚的品質によって異なります。
• Gianni Rosato氏による9月のエンコーダー比較では、テストされたロッシー忠実度の範囲全体でAVIFが有利でした。彼は競合するAVIFツールを開発しており、彼の結果とGoogleのJPEGベースラインの主張は異なる比較を測定しています。
• 代表的な画像でフォーマットを比較し、互換性のあるフォールバックを維持してください。JPEG XLは、既存のJPEGファイルを可逆でロスレスにトランスコードすることもサポートしています。
• OpenAIは、722の原稿を372のファミリーに分類してリリースし、検証は様々で、多くのLean形式化が含まれています。モデルは未公開のままであり、Pro相当の計算能力の数値は、小売価格でも経過時間の保証でもありません。
• ESP32-C3の作成者は、ソートされたドメインハッシュをフラッシュに保存することで、約50KBの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の数学的証明の大量公開と、広告ドメインをブロックする2ドルのボードと一緒に。 Chromeの以前の実験は2023年に終了しました。

なぜ一度却下されたフォーマットが再びチャンスを得たのか？

0:35 Googleの説明には、エコシステムの関心が不十分であると記載されていました。 最大のブラウザが、エコシステムがあなたのものを実際に使えるかどうかを制御していることを考えると、これは厄介です。 はい。 新しい投稿は、開発者からの根強いフィードバックを高く評価しています。 Interopプロセスも含まれています。 これを求めていた人々は問い続け、Googleは現在、フォーマットが一貫して動作することを目的にしたブラウザテストを指摘しています。 はい。 発表は、Helmut Januschkaを含む貢献者を高く評価しています。

0:57 時には、最も効果的なロードマップは、課題を閉じないことです。

デコーダの内部で何が変わったのか？

1:01 最大の変更点は、Rustで書かれたjay ex ell R Sと呼ばれるデコーダーです。 はい。 画像デコーダーは、見知らぬ人から提供された複雑なファイルを取り込みます。 そのため、誤ってインターネットを信頼してしまう絶好の場所になります。 Rustは、メモリエラーのクラスがブラウザの脆弱性になる前に防ぐのに役立ちます。 Googleは依然としてサンドボックスを維持しており、実装には依然として小さく、注意深くレビューされたunsafe領域が含まれています。 はい。 セキュリティは層を重ねます。なぜなら、現実は常に継ぎ目を見つけてしまうからです。

1:27 Googleは、ファジングとAIコードレビューがこのデコーダーの歴史においてメモリ安全性のバグを見つけられなかったと述べています。 それは、それを開発しているチームからの有用な報告です。 将来の攻撃者がブログ記事を拘束力のある契約として受け入れる可能性は低いでしょう。 最初の質問が解決しました。 開発者の圧力と最適化されたRustデコーダーが、その扉を再び開きました。 Googleは、その背後にエンジニアリングのある決定を覆しました。 これはインターネット上でも許されることです。 さて、スライドデッキのベンチマークです。

小さなファイルはAVIFを上回るのか？

1:48 Googleは、JPEGよりも30～50%優れた圧縮率を宣伝しています。 ダウンロードサイズが小さくなることで、ユーザーと帯域幅の料金が削減される可能性があります。 しかし、その範囲は、何をエンコードするか、どのように品質を比較するかによって異なります。 圧縮エンジニアのGianni Rosato氏は、9月に比較を公開しました。 彼のテストした忠実度範囲全体で、最新のAVIFエンコーダーがJPEG XLを上回ることを示しています。 はい。 彼は競合するAVIFツールに取り組んでいるため、グラフとともにその動機も考慮してください。 これらの比較は異なるベースラインを使用しています。

2:12 古いJPEGを上回ることは、AVIFがワークロードで勝利する余地を残します。 Google自身が両方のフォーマットを試すことを推奨しており、これはリリース発表としては異例に実用的なアドバイスです。 はい。 JPEG XLの他の魅力には、ハイダイナミックレンジ、ロスレス画像、きめ細かいプログレッシブデコードが含まれます。 はい。 コミュニティは、フォーマットを探索するためのインタラクティブなデモを公開しています。 残りの部分が届く間も、視聴者は役立つ画像を見ることができます。 展開のために、フォールバック画像を保持し、顧客が実際に使用しているブラウザでサポートを確認してください。

2:37 はい。 発表ではChrome 155を挙げています。 これによりターゲットバージョンが示され、アナリティクスによって視聴者がそこに到達した時期がわかります。 2番目の質問が解決しました。 パイプラインを変更する前に実際の画像をテストし、互換性パスを維持してください。 バイト数を節約する画像フォーマットは有用です。 チェックアウトボタンを隠す移行は、ミニマリズムの高価な解釈です。 一方、OpenAIは火曜日に数学の原稿とサポートする証明成果物を公開しました。

OpenAIが実際に公開したものは何か？

3:00 はい。 リポジトリには722の原稿が含まれており、関連するファミリーにグループ化されています。 はい。 見出しの数には、付随する議論や代替の証明が含まれているため、各論文が実際に何を主張しているかを読んでください。 はい。 多くはLeanで形式化された証明を持っており、これによりコンピュータが数学的推論をチェックできます。 その他はまだ形式化を待っています。 そしてOpenAIは、いくつかの非形式化された結果に問題がある可能性があると明示的に警告しています。

3:21 はい。 このリポジトリは、研究者が検査し、異議を唱えることができる資料を提供します。 モデルは未公開のままです。 OpenAIによると、各結果は平均して約3時間のChatGPT Pro相当の思考計算を使用しました。 はい。 これは計算上の労力を記述しています。 定理を作成するためのウォールクロック保証も、小売価格も提供していません。 はい。

3:40 このリリースは、独立した数学諮問グループとの協議を経ており、改訂および引用プロセスが含まれています。 はい。 学術界は、新しい宿題の山と、修正が必要な正確なページを指摘できるはるかに有用な能力を得ます。 はい。 Leanのメンテナーは、一度に少しずつコンパイルすることを推奨しています。 数学的なブレークスルーでさえ、最終的にはソフトウェアの古くからの敵に遭遇します。 はい。 ビルドを完了させることです。

2ドルのボードがどのようにドメインをブロックするのか？

4:03 最後に、オープンソースのDNS広告ブロッカーが、2ドルの小さなマイクロコントローラーボードで動作します。 開発者の秘訣は、ソートされたドメインハッシュをフラッシュに保存することです。 これにより、ブロックリストが希少なワーキングメモリに常駐する必要がなくなります。 このプロジェクトは、およそ50キロバイトのRAM使用量を報告しています。 要求されたドメインをフラッシュテーブルで検索し、一致した場合はブロックし、その他のクエリは上流に転送します。 はい。 あなたのルーターは、特定のゲストリストを持つ小さな用心棒を手に入れることができます。 DNSフィルタリングはドメインレベルで機能します。

4:28 有用なコンテンツと同じドメインから配信される広告はすり抜けることがあり、別のリゾルバーを使用するクライアントはそれを回避できます。 はい。 ボードよりも期待値を小さくしてください。これは要求の厳しいサイズ目標です。 そして、既存のJPEGに関する詳細については？

既存のJPEGも復活に参加できるのか？

4:40 JPEG XLはロスレスJPEGトランスコーディングをサポートしており、元のJPEGを再構築するパスも提供しています。 はい。 これにより、古い画像アーカイブに、別の世代の品質損失なしに移行オプションが与えられます。 はい。 ストレージと配信のトレードオフをテストしてください。 私が話すよりも読みたい場合は、The Daily Diff.devで毎日無料であなたの受信箱に差分が届きます。 リンクは以下にあります。

なぜデコーダーを導入し、移行をテストするのか？

4:58 というわけで、今日の評決はSHIP ITです。 私は追加のデコーダーを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