GoogleはJPEG XLのサポートを復活させたのか？

 (tonisagrista.com)
5 ポイント 投稿者 GN⁺ 2025-12-03 | 2件のコメント | WhatsAppで共有
  • ChromiumエンジンがJPEG XLのサポートを復元したことで、一度は廃止された画像フォーマットが再び注目を集めている
  • 2022年、GoogleはJPEG XLを「エコシステムの関心不足」を理由に削除したが、コミュニティと主要企業の継続的な圧力が続いている
  • Meta、Intel、Adobe、Cloudinary、Kritaなど複数の組織が、フォーマット維持の必要性を公に支持した
  • 最近PDF AssociationがHDR向けのデフォルトフォーマットとしてJPEG XLを採用する意向を示し、流れが強まった
  • Chromeの再導入決定は、JPEG XLの大衆的標準化の可能性を高める転換点として評価されている

JPEG XLの復活の背景

  • 2022年、Chromiumチームは、JPEG XLを「十分なエコシステムの関心不足」と「既存フォーマットに対する優位性不足」を理由にコードとフラグを削除
    • 当時、コミュニティはMeta、Intel、Cloudinary、Adobe、ffmpeg、libvips、Kritaなど主要組織の支持を表明
    • その後、ブログ、動画、SNSを通じて削除決定の不当性を指摘する反応が続いた
  • 2025年末、Chromiumチームは、Obsolete状態だったJPEG XLのissueを**Assignedへ変更**し、公式に復元手続きを開始
    • Blink開発者グループでRick Byersが「性能が高くメモリ安全なJPEG XLデコーダーを歓迎する」と述べた
    • この決定はSafariのサポート、Firefoxの立場変更、PDF Associationの採用への動きなどの前向きなシグナルに基づいている

FirefoxとRustベースのデコーダー開発

  • Firefoxチームは、JPEG XLのC++ベースのlibjxlデコーダーのセキュリティリスクを懸念し、「メモリ安全な」Rust版の必要性を提起
    • これにより、Google ResearchがRust実装jxl-rsの開発を開始
    • このプロジェクトは、JPEG XLをブラウザ内で安全に統合する可能性を高める契機となる

PDF Associationの採用の動き

  • PDF AssociationのCTO Peter Wyattは、JPEG XLをPDF仕様のHDR画像デフォルトフォーマットとして含める意向を表明
    • これは文書・出版分野におけるJPEG XLの標準化可能性を強化する要素として機能する

JPEG XLの主な技術的特徴

  • 既存のJPEGの可逆再圧縮をサポートし、品質低下なしで約30%の容量削減が可能
  • 広色域およびHDR対応、最大32ビットチャンネルと4,099チャンネルの処理が可能
  • 最大画像サイズ 1,073,741,823×1,073,741,824をサポートし、超大型画像の処理に対応
  • **プログレッシブデコード(progressive decoding)**対応で、Web配信効率を改善
  • **アニメーション、アルファ透明度、デプスマップ(depth map)**機能を含む
  • 世代ごとの再エンコードで劣化が出にくい構造を持ち、反復エンコード時の画質低下を最小限に抑える

結論

  • JPEG XLは次世代画像フォーマットとしての要件を満たし、Chromeエンジンの復帰は大衆的普及の決定的契機となる
  • コミュニティの長期的圧力の末に実施された復活により、Web画像エコシステムの新しい標準候補として浮上
  • 筆者はChromiumの再評価を歓迎しつつ、この決定が非常に遅すぎたことを指摘している

関連記事

2件のコメント

 
GN⁺ 2025-12-03
Hacker Newsの意見

  • JPEG XLのあまり知られていない優れた機能の1つは、JPEGから可逆でトランスコードしつつ約20%の保存容量削減を得られるモードがあること
    元のエントロピービットストリームをそのまま保持するため、完全に可逆である
    GCPがこれをDICOM Store APIに適用中で、JXLの容量削減効果を享受しながらもJPEGへリアルタイム変換して提供できる
    うちの会社は数十PB規模のデータをGCP DICOM Storeに保存しているので、この機能で年間料金を大きく削減できると期待している
    ブラウザのネイティブサポートにも期待しており、Chromeチームが最終的には対応するという話を聞いた

    • 平均的なJPEGエンコーダやmozjpegと比べてどんな違いがあるのか気になる
    • 以前GCP DICOM Storeを試す時間がなかったので、実際に使ってみるとどうなのか気になる
      完全なPACSなのか、WADO実装なのか、それとも単なるカスタムAPIなのか知りたい
    • 可逆なら、単にJPEG XLで保存して配信時に再変換すればいいのではないかと思う
      もしかして処理時間がかなりかかるのだろうか
    • どうせ元のDICOMを保存しなければならないなら、トランスコードに意味があるのか疑問
      保存コストの大半はDICOM自体だと思う
    • 結局GCPの大口顧客がこの機能で大きな利益を得るので、ChromeでJXLを推している理由が社内顧客のためなのではと思えてくる

  • JPEG XLの競合相手はAVIFではない
    AVIFはすでに事実上の標準として定着しており、ほぼすべてのブラウザが対応し、Appleの標準的な画像フォーマットとしても使われている
    JXLはまだブラウザ対応が弱いが、アーカイブ用途・プロ向け写真・医療用途などのニッチ市場で地位を築きつつある
    10年ほど後には、人々が単に「JPEG」と呼ぶほど普及しているかもしれない
    AVIFはオープンでロイヤルティフリーの標準で、JPEG/WebPより圧縮効率がはるかに高く、JXLとも近い水準である
    JXLの最大画像サイズのほうが大きいとはいえ、実際の採用はAVIFがはるかに先行している
    AV2が出れば品質差はほぼなくなり、両フォーマットとも進化しながら似た品質水準を維持するだろう

    • AVIFがJPEGやWebPより圧縮効率に優れるのは当然だが、JXLとは勝負にならない
      現実的な品質設定ではJXLのほうが高い圧縮率と速いエンコード・デコード速度を示す
      しかもprogressive decodingにも対応している
      AV2が出れば追いつくかもしれないが、今のところJXLがはるかに先を行っていると思う
    • ChromeチームがJXL対応を打ち切った理由の1つは、すでにAVIFで十分によかったからだった
      今回の再検討はそのときの判断とつながっているように見える
    • 「Appleの標準画像フォーマットがAVIF」というのは誤りだと思う
      iPhoneはHEIFを使っている
    • libjxlを直接使ってみたが、メモリ使用量が多く不安定だった
      高解像度画像をエンコードするにはテラバイト級のRAMが必要なほどだった
      コードベースがひどくて驚いたし、多くのオプションがまともに動かなかった
      jxl-rsで再挑戦するのは前向きだが、同じ開発者たちが関わっているので慎重に見ている

  • ChromiumはJPEG XL機能のためにjxl-rs crateを使う可能性が高い
    おそらく十分に安定するまで待ってから統合するつもりなのだろう
    関連イシューはこちらで確認できる

    • Mozillaも似た立場だったが、Googleはしばらく敵対的な態度を取っていた
      ユーザーの反対にもかかわらずイシューを閉じ、最近になってようやく再オープンした
      おそらくPR上の問題や社内の不満が理由かもしれない
    • jxl-rsは1年半以上コミットがない時期があった
      今うまく進んでいるのは運が良かった結果かもしれない

  • JPEG XLの**参照実装（C++）**を見たが、2年前の時点でもコード品質はよくなかった
    セキュリティ問題が起きそうな感じだった

    • そのためMozillaもGoogleも、メモリ安全な実装を条件にJXL対応を検討している
      Rust版が開発中で、GoogleはChromiumのすべてのデコーダを徐々にRustに置き換えていく計画を持っている
    • 実際、現時点（2025年）でC++で書かれた大規模な画像処理コードは、それ自体がセキュリティリスクである
      JPEG XL固有の問題ではない

  • JPEG XLの最大解像度は1,073,741,823 × 1,073,741,824で、数百ペタバイト級の超高解像度画像を表現できる
    現実的には圧縮後でも数十〜数百PB規模である

    • 600DPI基準では、一辺がマラソンの距離に相当する
      こうした巨大画像を小さなバイト空間で定義できるなら、DoS攻撃ベクターにもなり得そうだ
      A4用紙換算をしようとしたところ、Geminiの計算機が単位を取り違えて妙な結果を出した
    • こうした超巨大画像は、タイル化とピラミッド構造で扱うのが唯一の現実的な方法だ
    • 地球全体を約4cm解像度で撮影した画像くらいの大きさだと思う
    • その解像度でセルフィーを撮ったら、超解像顕微鏡レベルになりそうだ
    • JPEG XLはAVIFと違って効率的な progressive decodingに対応しているので、ダウンロード中でも低画質プレビューをすばやく見られる

  • 過去のHN議論まとめ
    Chromium Team Re-Opens JPEG XL Feature Ticket
    FSF Slams Google over Dropping JPEG-XL in Chrome
    Google set to deprecate JPEG XL support in Chrome 110
    Chromium jpegxl issue closed as won't fix

  • 私は何年も**.avifを使っている
    完璧ではないが、.jpgや.pngよりずっとよいと感じる
    .webpやjpeg-xlも検討したが、結果的に.avifに満足している
    ただ、Googleがウェブ標準を事実上    左右している**のは不満だ
    営利企業がデジタル生態系を支配するのは望ましくない

    • 「.jpgより.avifがよい」という文で**.avifを2回繰り返して**いて紛らわしい
    • 高品質JPEGを小さくしたいならjpegliを試してみることを勧める
      jpegli GitHub
      AVIFの視覚的ロスレス設定をうまく選べばjpegliより小さくなることもあるが、平均的にはjpegliのほうが効率的だ
    • ちなみに英語では “since some years” より “for several years” のほうが自然だ
    • JPEG XLは何度再保存しても品質劣化が少ないので、ウェブ環境に向いている
      関連動画: YouTubeリンク

  • JXLを削除したのは「Google全体」ではなくChromeチームである
    JXLはGoogle Zurich研究所のJyrki Alakuijalaが設計したが、彼はChromeチームではなくGoogle Research所属だ
    ChromeチームはMountain View中心の閉鎖的な文化を持っている

    • JyrkiはBrotli, WebP lossless, WOFF2, jpegliなども作った優れたエンジニアだ
      JpegXLが破棄された後にjpegliを作ったのも、一種の反応だった
    • この状況はConway’s Lawで説明できそうだ

  • C++ベースのマルチスレッド依存が多く、セキュリティ上の攻撃面が広がり得るという理由でJXLは遅れているようだ
    MozillaもGoogleもこれを避けるためRust実装を好んでいる
    標準そのものは確かに従来より改善されたフォーマットである

    • 1億行というのはあまりにも誇張された数字に思える
    • 実際には約3万行ほどで、シングルスレッド版は1万行前後である
      AVIFよりバイナリサイズもはるかに小さく、仕様書もずっと簡潔だ
    • GoogleがJXL開発に参加していたのだから、メモリ安全なデコーダを早く作らなかったのは自分たちの責任だ
    • もしかすると10万行くらいのことを言っていたのではないか？ そのうちかなりの部分はテストコードだと思う
    • 実際のlibjxlは約11万2千行ほどで、1億行という主張とは3桁違う

  • iPhone 17 ProのRAWファイルはJPEG XLで圧縮されるという