ChromiumがJpegXLをマージ

 (chromium-review.googlesource.com)
2 ポイント 投稿者 GN⁺ 2026-01-14 | 1件のコメント | WhatsAppで共有
  • ChromiumコードベースにJpegXLデコーダーが統合され、ブラウザがJXL形式の画像を処理できるようになった
  • 変更内容はGerritコードレビューページで 「Wire up JXL decoder」 というタイトルで確認できる
  • このマージは JpegXL形式のサポートに向けた中核的なステップ であり、デコーダー接続作業が含まれている
  • コードレビューはChromiumの srcリポジトリ内の変更(7184969) として登録されている
  • Webブラウザにおける 次世代画像フォーマット対応の拡大 という点で意味がある

ChromiumのJpegXLデコーダー統合

  • Gerritコードレビュー項目 「Wire up JXL decoder (7184969)」 は、ChromiumプロジェクトにJpegXLデコーダーを接続する変更である
    • この変更はChromiumの srcリポジトリ 内で行われた
    • コードレビュープラットフォームには chromium-review.googlesource.com が使われている
  • タイトルどおり、JXL(JpegXL)デコーダーを ブラウザ内部に接続する(wire up) 作業を意味する
  • ページには 追加説明やコードの詳細は表示されておらず、変更タイトルのみ確認できる

技術的背景

  • JpegXLは 次世代画像圧縮フォーマット であり、既存のJPEGと比べて効率向上を目指すものとされる（原文での直接言及はなく、技術名のみ存在）
  • Chromiumにデコーダーがマージされたことで、JXL画像処理機能をコードレベルで有効化するための基盤 が整った
  • この変更は ブラウザエンジンのメディアデコード体系の拡張 に関する技術的進展である

文書の状態

  • ページは Gerritコードレビューのキャッシュされたスナップショット として表示されている
  • 「shadow DOMが隠されている」という警告文が含まれているが、実際のコード内容は表示されていない
  • したがって、この文書で確認できる情報は 変更タイトルとレビュー識別子(7184969) のみである

関連記事

1件のコメント

 
GN⁺ 2026-01-14
Hacker News の意見

  • Cloudinary のブログ記事を見たが、webp、jpegxl、avif、jpeg などを比較した古典的な名記事だった。
    チャートがよく整理されていて、AVIF は非常に遅い。

    • JPEG を最低品質に設定したときが、ここではむしろかなり見栄えが良かった。
      関連セクションへのリンク
    • このサイトが正確に何をしようとしているのか分からない。
      スクリーンショット参照
    • 引用文のとおり、JPEG XL が現在非可逆/可逆の両方で最高のコーデックという地位を固めたのなら、JPEG と PNG を一つに置き換えられる大きな進歩だ。
    • ただしこのテストではハードウェアアクセラレーション対応のエンコーダ/デコーダは使っていない。

  • jxl-rs ライブラリは JPEG XL の Rust 実装だ。
    比較的新しいプロジェクトだが、Rust なので安全性の面では安心感がある。
    以前の Chromium の議論時には、このライブラリは存在していなかった。

    • Google が JPEG XL を拒否した理由は「関心不足」だったと記憶している。セキュリティ問題ではなかったはずだ。
    • 「Rust がセキュリティの心配を減らしてくれる」という意見には同意しない。メモリ安全性はセキュリティそのものではない。
      Rust は過信を招くことがあり、脅威モデリングを省略してしまう場合もある。
      むしろ注意深い C プログラマのほうが安全なこともあり得る。
    • 実際に unsafe コードがどれくらいあるか確認してみた。
      検索結果へのリンク

  • 最近 WebP と AVIF を比較してみたが、WebP はほぼ即座にエンコードされる一方で、AVIF は 1MP の画像に 20 秒以上かかった。
    JXL はまだサポートが少ないので実運用では使えないが、WebP 並みの速度でより良い品質を期待している。

    • rav1e は何年も更新が止まっている状態なので、aom や svt-av1 のようなエンコーダを使うほうがよいらしい。
    • AVIF は CPU 使用パラメータを調整する必要がある。デフォルト設定が高すぎる CPU レベルを使うので遅い。
      私の環境では 2MP の AVIF を 100ms 程度で生成している。

  • JPEG XL の**公開仕様書(spec)**に自由にアクセスできないのが残念だ。

    • 非公開標準を維持するのは恥ずべきことだと思う。
    • ISO や IEC のような機関の多くの文書が**有料の壁(paywall)**の向こう側にある現実が問題だ。

  • また新しい画像フォーマットが増えたが、結局は変換なしでは使えない状況の繰り返しになるのではと心配している。

    • それでも Microsoft でさえ JPEG XL アドオンを出しているし、Google が引いた今こそ本当のチャンスがあると思う。
      Microsoft Store リンク
    • 実際にはすでに多くのアプリが対応している — Affinity、Photoshop、Microsoft Photos、Gimp、そして iOS 17+/macOS 12+ のシステム全体でのサポートまである。
      Chromium のほうがむしろ遅い。
    • もちろん新しいフォーマットには常に10年程度の導入期間が必要だ。

  • Wikipedia で見た JPEG XL の機能一覧を読むと、マルチチャネル画像やマルチページ文書のような興味深い機能がある。
    良い点もあるが、だんだん TIFF のように複雑になってきている感じもする。

  • JPEG と JPEG-XL の間には、今でも多くの共通点がある。
    新しい実装が既存の JPEG サポートまで統合すれば、コードサイズ削減が可能なのではないかと気になる。

    • 実際、その機能のための issue が JPEG-XL の Rust リポジトリに立っている。
      issue #513 リンク

  • 個人的には、WEBP のような新しいフォーマットより既存の JPEGを使い続けたい。
    ほとんどのプログラムが対応しており、一般ユーザーには JPEG + PNG で十分だ。
    簡単なアニメーションは GIF、複雑なものは動画で処理すればよい。

    • 「JPEG XL」は名前と違って、単なる JPEG の拡張版ではない。
      PNG より小さい容量で可逆エンコードが可能で、既存 JPEG を 20% さらに圧縮しつつ復元可能なトランスコーディングにも対応する。
      HDR、ワイドガマット、プログレッシブ読み込みなど多様な機能があり、Web 配信にも理想的だ。
      jpegxl.info 参照
    • WebP は今や事実上の標準フォーマットと見なしてよい。
      Safari 14 以降、すべての主要ブラウザが対応し、Windows 10・macOS Big Sur 以降では標準搭載されている。
      対応状況、ソフトウェア一覧を参照。
    • GIF は今や非効率だ。動画に置き換えるほうが 5～10 倍効率的だ。
      関連文章

  • JPEG XL、WebP、AVIF の論争は長く見聞きしてきたが、よく分かっていなかった。
    ベンチマークを見ると JpegXL は WebP より圧縮速度とサイズの両方で優れているのに、なぜ Chromium が採用をためらっていたのか気になる。

    • WebP と AVIF は VP8/AV1 とコードを共有しているためブラウザ統合が容易だが、JPEG-XL は別個のコードベースなので実装負担が大きい。
      また libjxl は C++ で 10 万行を超えるコードがあり、セキュリティ脆弱性のリスクがあった。
      Rust 実装が成熟するにつれて、Chrome は再検討しているようだ。
    • JPEG XL はプログレッシブデコードをサポートしている。
      デモ動画
    • Google は「似たようなフォーマットが複数あるとセキュリティリスクが増えるだけで、AVIF 一つで十分だ」と主張していた。
    • AVIF は低 bpp（低品質）では良いが可逆には弱く、一方 JXL は高品質・可逆で強い。
    • 過去には JPEGXL の C++ ライブラリがメンテナンス中断状態だったが、Rust 版が登場したことでブラウザ採用が可能になった。

  • JPEG XL がアニメーションをサポートするのか気になっていた。

    • サポートはしているが、フレーム間圧縮がないため非効率で、通常の動画より容量が大きい。
    • Chrome Platform Status ページによると、アニメーション、HDR、プログレッシブデコードのすべてに対応している。
      詳細リンク
    • 実際に Canary ブラウザで試したところ、アニメーションは問題なく動作した。
    • 冗談半分に、WebP は事実上「動画フォーマットな画像」で、JPEG XL は「画像フォーマットな動画」なので、逆説的な対称構造が生まれたという人もいた 😄