1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@hiranuma(Shingo Hiranuma)

Chromeが2022年に外したJPEG XLに、なぜ4年後に対応し直したのか

1
Posted at

2026年10月6日に公開されたChrome 155で、JPEG XLという画像形式の表示に対応しました。GoogleはChromeでこの形式を一度試したうえで、2022年に「既存の形式に対して利点が足りない」としてコードごと外しています。同じ形式に、4年たって対応し直したことになります。

主要なブラウザでも、JPEG XLが表示できる環境が揃いつつあります。Safariは2023年から対応していて、Firefoxも10月13日に公開された158で、JPEG XLを初期設定で表示するようになりました。

読み終える頃には、JPEG XLが何を得意とする形式なのか、Googleが一度外した理由と対応し直した理由、AVIFやWebPとどう使い分ければよいのかを、自分のサイトや手元の画像に当てはめて考えられるようになると思います。

JPEG XLは、手元のJPEGを画質を落とさずに約20%小さくできる

JPEG XLは、JPEGを策定してきた委員会が作った新しい画像形式で、国際規格ISO/IEC 18181として2021年から2022年にかけて発行されました。委員会は2018年4月に提案を公募し、2019年1月にGoogleのPIKとCloudinaryのFUIFという2つの提案を統合して1つの形式にすることを決めています。目標は、JPEGより60%以上効率よく圧縮することでした。

JPEG XLの特徴のうち、AVIFやWebPにないのは、今あるJPEGファイルを画質を一切落とさずに作り直せることです。平均で約20%小さくなり、必要なら元のJPEGとまったく同じファイルに戻すこともできます。ウェブにはこれまで撮りためたJPEGの写真が大量にあります。AVIFやWebPに変えるには一度画像を展開して圧縮し直す必要があり、そのたびに少しずつ画質が落ちますが、JPEG XLならその心配がありません。

ほかにも、1つの形式で次のことに対応しています。

  • 画質を落とさない可逆圧縮と、ファイルを小さくする非可逆圧縮の両方
  • 読み込みの途中から粗い画像を表示し、徐々に細かくしていくプログレッシブ表示
  • HDR（PQとHLGの両方式）と広い色域
  • 透明度（アルファチャンネル）、アニメーション、レイヤー
  • 画像の配信向けのLevel 5で、最大2億6843万画素、1辺26万2144ピクセル、1チャンネル16ビットまで。上位のLevel 10では、1辺が約10億ピクセル、1チャンネル32ビットまで扱える

2022年のChromeは、利点が足りず関心も広がっていないとして対応を外した

ChromeがJPEG XLを試し始めたのは2021年です。3月にGoogleの開発者が、初期設定では無効にした実験用のフラグの中でJPEG XLを表示できるようにすると表明し、Chrome 91前後から、フラグを有効にすればJPEG XLを表示できるようになりました。

ところが2022年10月末、Chromiumの課題管理システムに、このフラグとコードを外すという方針が書き込まれました。報道で引用された理由は、次の4つです。

  • 実験用のフラグとコードを、いつまでも残しておくべきではない
  • エコシステム全体に、JPEG XLの実験を続けるだけの関心がない
  • 既存の形式に対して、初期設定で有効にするほどの利点がない
  • Chrome 110でフラグとコードを外せば、保守の手間が減り、既存の形式の改良に集中できる

この方針には、開発者向けのメーリングリストで反論が相次ぎました。投稿の中では、Facebook、Adobe、Intel、Shopify、The Guardian、Cloudinaryなどが、すでにJPEG XLを使う準備を進めていると挙げられています。それでも判断は変わらず、2022年12月にChrome 110に向けてコードが削除されました。Googleの担当者は、判断の材料として圧縮の性能、表示の速度、作るときの計算コスト、既存の形式を改良すれば足りるかどうか、ほかのブラウザやOSが対応しているかを挙げ、どうしても使いたい場合はWebAssemblyで表示する方法を勧めていました。

ほかのブラウザとPDFが先に動き、条件だった安全性にも答えが出た

Chromeが外した翌年の2023年9月、AppleはSafari 17でJPEG XLに対応しました。iOS 17、iPadOS 17、macOS Sonomaなどに加え、アプリの中でウェブページを表示する部品でもJPEG XLを表示できます。ただしcaniuseの記録では、アニメーションとプログレッシブ表示には今も対応していません。

Mozillaも、2024年9月にFirefoxとしての見解を書き換えました。評価そのものは賛成でも反対でもない中立のままですが、メモリ安全なデコーダ（画像ファイルを読み解いて表示できる状態に戻すプログラム）であれば、Firefoxに組み込むことを受け入れるとしています。そのデコーダを、Google ResearchがプログラミングのRust言語で作ることにも合意しました。

2025年11月には、PDFの規格を扱う業界団体のPDF Associationが、同団体のカンファレンスで、HDRに対応する画像形式としてJPEG XLを第一候補に選んだと報じられました。ブラウザの互換性をそろえるために各社が毎年取り組む項目を決めるInterop 2026でも、JPEG XLは本格的に取り組む分野ではなく、調査を進める項目として入りました。

こうした動きを受けて、2025年11月、GoogleのRick Byersが、Chromeの技術責任者たちを代表して、2021年に始まった元のスレッドに投稿しました。Safariが対応したこと、Firefoxが見解を改めたこと、PDFが採用を表明したことに加え、バグへの投票やInteropの提案に開発者の要望が出ていることを挙げ、性能がよくメモリ安全なJPEG XLのデコーダをChromiumに組み込む提案を歓迎すると書いています。初期設定で有効にするには、通常の出荷基準を満たしたうえで、長く保守し続けることの約束が要る、という条件付きです。

その後の流れは次のとおりです。

  • 2025年12月: Rustで書かれたデコーダjxl-rsを使う形で、Chromeの新機能として登録された
  • 2026年2月10日: Chrome 145で、実験用のフラグを有効にすれば表示できるようになった
  • 2026年8月24日: 出荷の提案が開発者向けのメーリングリストに出され、同じ日に承認に必要な3人の賛成がそろった
  • 2026年10月6日: Chrome 155で出荷。Android版と、アプリの中でウェブページを表示するWebViewも同じバージョンで対応した

Firefoxも同じ8月24日に出荷を提案しています。デコーダはChromeと同じjxl-rsで、アニメーションとプログレッシブ表示に対応し、HDRの画像は通常の明るさの範囲で表示します。Firefox 152から試験機能の設定画面で有効にできるようになり、当初は157で出荷する予定でしたが、9月に158へ延期されました。

画像デコーダをRustで書き直したのは、画像ファイルが攻撃の入り口になるから

GoogleもMozillaも、対応の条件としてメモリ安全なデコーダを求めました。画像のデコーダは、ウェブ上の誰かが作ったファイルをそのまま読み込んで解析するプログラムです。細工されたファイルを読み込ませると、プログラムが想定していないメモリの範囲を書き換えてしまうことがあります。

2023年9月に公開されたCVE-2023-4863がその例です。WebP画像を表示するライブラリlibwebpのバージョン1.3.2より前のものと、Chrome 116.0.5845.187より前のものには、ヒープバッファオーバーフローという欠陥がありました。細工したHTMLページを開かせるだけで、メモリの範囲外に書き込みができる欠陥です。Chromeのブログはこの件に触れていませんが、新しい画像形式を加えることは、同じ種類の欠陥が入り込む場所を1つ増やすことでもあります。

Chromeのブログでは、画像のデコーダは最も狙われやすい攻撃対象の一つで、C++で書いたものには脆弱性が出やすいので、Rustで書くことでこの種類の欠陥をそもそも起きないようにする、と説明しています。Chromeが別に持っているサンドボックス（プログラムを隔離して動かす仕組み）は、二段目の防御という位置付けです。ファジング（大量の壊れたファイルを自動で読み込ませて欠陥を探す試験）とAIによるコードレビューを重ねた結果、メモリ安全性に関わるバグはこれまで見つかっていないとしています。

jxl-rsの開発は2021年5月に始まっています。Rustでも安全性の検査を外して書く部分（unsafeなコード）は避けられませんが、jxl-rsではその部分を、書いた本人とは別のunsafe Rustに詳しい開発者がレビューする決まりにしています。最新版は2026年9月17日の0.7.4です。規格の参照実装は今もC++のlibjxlで、こちらは7月1日に0.12.0が出ています。

画像処理の分野では、速さを優先してC++で書かれたライブラリが長く使われてきました。新しい形式に対応するたびにC++のコードを増やすのではなく、ブラウザに入れる段階でRustで書き直すという順番は、ほかの画像形式や動画形式のデコーダにも広がっていくと思います。

AVIFとの比較では、画質の高さで有利な形式が入れ替わる

新しい画像形式として先に普及したのは、動画形式AV1をもとにしたAVIFです。どちらを使うかは、画像の種類と画質の目標で決まります。ここで紹介する比較は、どれもJPEG XLの開発者が出したものなので、その前提で読む必要があります。

Cloudinaryが2024年2月に公開した比較では、libavif 1.0.3とlibjxl 0.10.0を既定の速度設定と8スレッドで動かし、SSIMULACRA2という、人の見た目に近い画質の指標で同じ点数になるように圧縮して、ファイルの大きさを比べています。

  • 60点（中程度の画質）: JPEG XLとAVIFのファイルの大きさは同じくらいで、圧縮にかかる時間はJPEG XLのほうが大幅に短い
  • 90点（元画像と見分けがつかない画質）: AVIFは従来のJPEG（libjpeg-turbo）より20%小さく、JPEG XLはそのAVIFよりさらに20%小さい。圧縮の速さはJPEG XLが2.5倍

2025年6月にJPEG XLの開発者を中心とする12人が公開した論文では、49枚の画像をCVVDPという別の画質指標で比べています。低い画質ではAVIFとJPEG XLはほぼ同じで、高い画質ではJPEG XLが10〜25%効率よく圧縮できました。HDR画像を集めた別のセットでも、同じ指標で、ごく低い画質ではAVIFが有利、中程度から高い画質ではJPEG XLが約20%有利でした。一方、人が見比べた主観評価の傾向では、イラストや図表、文字のような写真以外の画像でAVIFのほうが20〜30%効率がよく、室内の写真でもAVIFがわずかに上回っています。

形式の仕様にも違いがあります。AVIFの基本のプロファイル（Baseline Profile）では、1枚の画像として圧縮できるのは約890万画素（4K相当）まで、幅は8192ピクセル、高さは4352ピクセルまでで、それより大きい画像は複数のタイルに分けて作ります。プログレッシブ表示は任意の機能です。WebPは1辺16384ピクセル（非可逆圧縮では16383ピクセル）が上限です。

この結果からは、使い分けの方法が見えてきます。写真を高い画質のまま配信したいサイトや、既存のJPEGを大量に抱えているサイトでは、JPEG XLを試す価値があります。図やイラスト、画質を落としてでも小さくしたいサムネイルは、AVIFのままにしておく方法があります。どちらが有利かは画像によって変わるので、自分のサイトの代表的な画像を何枚か両方の形式で圧縮して、大きさと見た目を比べるのが確実です。

今のところ、JPEG XLだけで配信できるわけではない

Chrome 155とFirefox 158がそろっても、JPEG XLを表示できない環境はしばらく残ります。caniuseのデータでは、Chromeと同じChromiumをもとにしたMicrosoft Edgeは154まで非対応で、155以降の対応はまだ記録されていません。Safariはアニメーションとプログレッシブ表示に対応していません。ブラウザの利用率で見ると、10月13日時点では完全に対応している環境が0.02%、一部対応が16.93%で、Chrome 155の利用者はまだこの数字に反映されていません。

そのため当面は、HTMLのpicture要素で複数の形式を並べ、ブラウザが表示できる最初の形式を選ばせる方法が現実的です。

<picture>
  <source srcset="photo.jxl" type="image/jxl">
  <source srcset="photo.avif" type="image/avif">
  <img src="photo.jpg" alt="商品の写真" width="1200" height="800">
</picture>

JPEG XLに対応したブラウザはphoto.jxlを、対応していないブラウザはAVIFかJPEGを読み込みます。同じ画像を3つの形式で用意する手間はかかりますが、libjxlのcjxlを既定の設定で使ってJPEGから変換したファイルなら元のJPEGに戻せるので、JPEG XLを原本として保管しておくこともできます。

画像を作る道具も揃ってきました。ImageMagickはJPEG XLの読み書きに対応し、GIMP 3でも読み込みと書き出しができます。ffmpegは8.0でアニメーションのJPEG XLを書き出せるようになり、libvipsでも読み書きできます。libjxlの0.12.0では、djxlにJPEGへ戻すことを指定する --reconstruct_jpeg が加わり、これを付けると、元に戻せない場合はエラーで止まります。

まとめ

2022年にChromeがJPEG XLを外したときの理由は、既存の形式に対する利点が足りないことと、エコシステムの関心が広がっていないことでした。その後の4年で、Safari、Firefox、PDFが先に対応を表明し、GoogleとMozillaが求めたメモリ安全なデコーダもRustで用意されました。既存のJPEGを画質を落とさずに小さくできるという点は、当時から変わっていません。手元に大量のJPEGがあるなら、まずは自分の画像で、どれだけ小さくなるのかを試してみてもよいのではないでしょうか。

参考文献

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?