2026-11-09 ChatGPTの纏めリライト
JPEGというと、一般には「画像を非可逆圧縮する形式」と認識されている。しかし、実は1992年に制定された最初のJPEG規格には、既に可逆圧縮方式が含まれていた。
近年、FirefoxのJPEG XL対応が話題になったことをきっかけに、初代JPEGから現在までの可逆圧縮方式と、その実装状況を振り返ってみた。
1992年のITU-T T.81（ISO/IEC 10918-1）には、DCTを使用する非可逆圧縮だけでなく、予測符号化を使用する可逆圧縮方式が規定されている。
この可逆方式は一般にLossless JPEGと呼ばれ、Huffman符号化を使用する場合、SOF3（FF C3）というフレーム開始マーカーで識別できる。 ただし、可逆圧縮はBaseline JPEGの必須機能ではなく、一般的な画像表示ソフトウェアにはほとんど普及しなかった。
現在でも実装は存在する。
| ソフトウェア | 対応状況 |
|---|---|
| Thomas Richter's libjpeg | 可逆JPEGのエンコード・デコード |
| DCMTK | DICOM画像の可逆JPEG圧縮・展開 |
| GDCM | 医療画像向けの可逆JPEG処理 |
| pylibjpeg-libjpeg | 可逆JPEGのデコード |
特にThomas Richter's libjpegは、初代JPEG規格の可逆圧縮を一般的な画像ファイルとして試すのに適している。
2000年に登場したJPEG 2000は、ウェーブレット変換を採用し、可逆・非可逆圧縮の両方に対応した。
しかし、一般的な画像形式としては普及しなかった。 その背景には、当時のPCにとって比較的重い処理負荷、既存JPEGとの互換性の欠如、ソフトウェア対応の不足、特許・ライセンスに関する懸念などがあった。
もっとも、JPEG 2000が消滅したわけではない。デジタルシネマのDCP、医療画像、衛星画像、デジタルアーカイブなど、業務用途では採用されている。 特に映画館のデジタル上映では、JPEG 2000が長年利用されてきた。
一般利用者には存在感が薄い一方、業務機器の内部では活躍していたのである。
なお、JPEG 2000を使用しているからといって、必ず可逆圧縮というわけではない。
JPEG XLは、2022年に主要部分が国際規格化された新しい画像圧縮方式である。
主な特徴は次のとおり。
JPEG XLは単なるJPEGの高圧縮版ではなく、現代の画像利用環境に合わせて設計された新しい形式である。
なお、既存JPEGファイルの再構築機能と、元画像の画素値を完全保存する可逆画像圧縮は別の機能である。
JPEG XLでは、主に2つの圧縮モードが用意されている。
VarDCTは「JPEGを現代的に進化させた非可逆寄り」、Modularは「真の可逆や高ビット深度に強い」という役割分担になっている。用途に応じてエンコーダが自動的に選択したり、指定したりできる。
JPEG 2000の普及を語る際には、特許・ライセンス問題への懸念がしばしば挙げられる。
ただし、JPEG 2000の基本規格そのものが一律に有料だったわけではない。Part 1はロイヤリティフリーでの利用を目指していた。
JPEG XLもロイヤリティフリーでの利用を前提としており、公式実装libjxlはBSD 3-Clauseライセンスで公開されている。
libjxlにはエンコーダのcjxlとデコーダのdjxlが含まれており、どちらも無償で利用できる。 Googleによる対象特許の無償許諾も用意されている。
したがって、「デコードは無料だが、エンコードには高額なライセンス料が必要」という仕組みではない。
ただし、ソフトウェアの利用許諾と特許の利用許諾は別の問題であり、第三者特許を含めたあらゆる法的リスクが完全に排除されるわけではない。
JPEG XLの開発にはGoogleも関わっている。
ところが、Googleが開発に貢献したJPEG XLの実験的サポートを、Chromium側は2022年に削除した。
Chromium側は、エコシステムからの需要、既存形式と比較した利益、保守負担などを理由として挙げていた。
一方、GoogleはWebPやAV1にも深く関わっており、AV1を利用するAVIFも存在する。
そのため、JPEG XLよりWebPやAVIFを優先したのではないかという見方もある。
ただし、これを意図的な競合規格の排除と断定できる根拠はない。
画像形式の普及には、圧縮性能だけでなく、ブラウザやOSによる標準対応が大きく影響する。
その後、ブラウザの対応状況は大きく変化した。
AppleのSafariは2023年のSafari 17からJPEG XLに対応した。
Mozillaは2026年10月13日に公開したFirefox 158で、JPEG XLのデコードを標準で有効化した。当初はFirefox 157での有効化が予定されていたが、開発上の事情から158へ延期された。
さらにGoogleも方針を変更し、2026年10月6日、Chrome 155からJPEG XLのデコードに対応することを発表した。デコーダにはメモリ安全性を重視したRust製のjxl-rsを採用している。
つまり、かつてJPEG XLのサポートを削除したGoogle自身が、再び採用する方針へ転換したのである。
この変化によって、JPEG XLは主要ブラウザでの対応が進む段階に入った。ただし、ブラウザが画像を表示できることと、Webサイトが実際にJPEG XL形式で画像を配信することは別問題である。
画像形式の普及には、引き続きWebサイトや画像処理ソフトウェア側の対応が重要となる。
可逆圧縮に対応した画像形式では、圧縮ファイルが非常に小さくても、展開後のデータが巨大になる可能性がある。
JPEG XLも例外ではない。
例えば、10,000×10,000ピクセルの16ビットRGBA画像は、画素バッファだけで約763MiBを必要とする。
JPEG XLの公式実装libjxlには、完全展開する前に画像の寸法やビット深度などを取得できるAPIが存在する。
これにより、アプリケーション側で画像サイズや必要メモリ量を検査し、危険な入力を拒否することが可能である。
しかし、規格自体が展開爆弾を完全に防止するわけではない。
デコーダ内部の作業領域、アニメーション、メタデータ、処理時間なども考慮する必要がある。
不特定多数の画像を処理する場合は、事前検査に加えて、プロセス単位のメモリ・CPU時間制限などを設けることが望ましい。
| 規格 | 登場時期 | 可逆圧縮 | 主な普及状況 |
|---|---|---|---|
| JPEG | 1992年 | 対応 | 非可逆方式が一般普及 |
| JPEG-LS | 1999年 | 対応 | 医療・専門用途 |
| JPEG 2000 | 2000年 | 対応 | 映画・医療・アーカイブ |
| JPEG XL | 2022年 | 対応 | 対応環境の拡大途上 |
JPEGの可逆圧縮は、JPEG XLで初めて実現した技術ではない。
初代JPEGの時点で規格化され、その後も複数の方式が開発されてきた。
しかし、規格に機能が存在することと、それが一般に普及することは別問題である。
30年以上にわたり、画像形式の歴史はそのことを繰り返し示している。
そして最後に、日本人にとってJPEG XLという名称は少々紛らわしい。
「XL」と聞けば、どうしても特大サイズを連想してしまうからだ。
JPEG XL：圧縮するとSサイズ、展開するとXLサイズ。
※展開後のサイズには個人差があります。
……いや、セキュリティ担当者としては笑ってばかりもいられないのである。