JPEG XL

この名前はJPEG（この形式を設計したグループのJoint Photographic Experts Group）、X（JPEG XT（英語版）、JPEG XR、JPEG XS（英語版）など2000年以降のいくつかのJPEG標準の名前に含まれる）、L（長期）の組み合わせからなる。Lが含まれているのは、作者がこの形式が従来のJPEGを置き換え、これと同様に長期間存続することを意図しているためである^[6]。

作者

この形式の仕様の主な作者は、Jyrki Alakuijala、Jon Sneyers、Luca Versariである。その他の協力者はSami Boukortt、Alex Deymo、Moritz Firsching、Thomas Fischbacher、Eugene Kliuchnikov、Robert Obryk、Alexander Rhatushnyak、Zoltan Szabadka、Lode Vandevenne、Jan Wassenbergである。

2017年8月、ISO/IEC JTC 1/SC 29/WG 1（JPEG）は次世代画像符号化標準であるJPEG XLの技術公募を公表した^[7]。提案は2018年9月までに提出され、2019年7月の委員会草案に繋がった^[8]。この提案は主にGoogleが提出したPIK^[9]と呼ばれる提案と、Cloudinary（英語版）が提出したFUIF^{[注釈 1][10]}と呼ばれる提案を統合したものに基づいていた。

ビットストリームはリファレンス実装のlibjxlのバージョン0.2のリリースに伴い2020年12月24日に非公式に凍結された^[11]。ファイルフォーマットは2021年10月13日に、コア符号化システムは2022年3月30日に正式に標準化された^[4][12]。

JPEG XLの技術公募^[7]ではJPEGと比較して大幅に優れた圧縮率（60%向上）を備えた次世代画像圧縮標準の要件について述べている^[13]。この標準はHEIC、AVIF、WebP、JPEG 2000によって示される静止画圧縮性能よりも優れた性能であることが期待される。また従来のJPEG形式の画像に対して効率的な可逆再圧縮オプションも提供する。

JPEG XLは超高解像度画像（最大1テラピクセル）、コンポーネントあたり最大32ビット、最大4099コンポーネント（アルファ透明度を含む）、アニメーション画像、組み込みプレビューの非可逆圧縮と可逆圧縮をサポートしている。JPEG XLは高度なプログレッシブデコード^[14]や最小限のヘッダーオーバーヘッドなどのウェブ配信を目的とした機能に加えて、複数レイヤー、CMYK、特色などの画像編集やデジタル印刷を目的とした機能を備えている。JPEG XLは知覚量子化器またはハイブリッド・ログ＝ガンマ伝達関数を備えたRec. 2100などのハイダイナミックレンジを持つ広色域の色空間をシームレスに処理できるように特別に設計されている。

主な特徴は以下の通りである^[15][16][17]:

• 画像サイズは各辺で10億（2³⁰−1）ピクセルを超える^[18]。
• 最大4099チャンネル。メインチャンネルはグレースケールの1チャンネル、RGBの3チャンネル、CMYKの4チャンネル。残りのチャンネルはオプションで、アルファ（「ストレート」または「乗算済み」のいずれか）、深度（英語版）、熱のデータを保存するために使用できる^[18]。
• 持続時間がゼロでない（アニメーション）かゼロである（グラフィックソフトウェアのレイヤーのように動作する）複数のフレームが存在する場合がある。フレームは画像キャンバスより小さくも大きくもでき、様々な方法で統合できる。しかし、現実的なコンテンツをエンコードするには通常のビデオコーデック（英語版）が依然として推奨される。
• 独立したタイル: 画像をタイルに保存できるようにすることで大きな画像の断片をデコードする。
• プログレッシブデコード: 表示デバイスの解像度に応じて大きな画像をレスポンシブに読み込むために特別に設計されたモード。
• 可逆JPEGトランスコード: サイズの最大20%削減を実現できる。
• アルファを含むあらゆるチャンネルの可逆エンコード。
• 写真と人工的な画像の両方をサポート: この形式は画像の内容に応じて使用できる2つの補完的なモードを持つ。
• 広範囲のビットレートにわたる上品な品質低下: 品質低下は古い形式ほど突然ではない。
• 知覚的色空間、適応性のある量子化、保守的なデフォルト設定を使用する知覚的に最適化されたリファレンスエンコーダー。
• 広色域とHDRのサポート: JPEG XLには様々な色空間、伝達曲線、高い画面輝度のサポートが組み込まれている。
• 専門のハードウェアを必要としない効率的なエンコードとデコード: JPEG XLは従来のJPEGでlibjpeg-turboを使用したときと同じくらい高速にエンコードとデコードができ、HEICでx265（英語版）を使用したときと比較すると桁違いに高速にエンコードとデコードができる^[18]。また、並列化もできる。
• ロイヤリティフリーのファイルフォーマットで、オープンソースのリファレンス実装が三条項BSDライセンスでライセンスされておりGitHubから利用できる^[19]。

JPEG XLはGoogleのPIK形式とCloudinary（英語版）のFUIF形式^{[注釈 1]}のアイデアに基づく^[20]。

この形式は主に2つのエンコードモードに基づいている:

• VarDCTモード（可変ブロックサイズDCT） - これは従来のJPEGと同じDCTアルゴリズムに基づいているが、ブロックは8×8に制限されず、様々なサイズ（2×2から最大で256×256まで）や非正方形の形状^{[注釈 2]}になったり、別の変換を使用したりできる。これは3つのカラーチャンネルでだけ使用され、通常はXYB色空間を使用する^{[注釈 3]}。VarDCTモードは非可逆PIKに基づいている。非可逆モードは通常はLMS色空間から派生したXYB色空間を使用する^[21] 。
• Modularモードは特に可逆圧縮を担当し、非可逆圧縮とニアロスレス圧縮も担当する。ModularをVarDCTの内部で使用して2次元データ、つまりDC画像^{[注釈 4]}、適応性のある量子化の重み、フィルター強度を含むAC（高周波） DCT係数以外の全てを保存できる。

あらゆる追加または余分なチャンネル（透明度（英語版）、深度（英語版）、熱、特色など）は常にmodularモードでエンコードされる。これはFUIFに基づいており、可逆PIK、可逆WebP、標準化過程の共同作業中に開発された新しいアイデアの要素が統合されている^[22]。Modularモードではプログレッシブ特性を持つ「squeeze」呼ばれる修正されたハール変換を使用して非可逆圧縮ができ、読み込まれるデータ量に応じて画像の品質が向上する。

VarDCTを基にした画像をよりプログレッシブに読み込める方法の1つはmodular squeezeを使用する個別の「DCフレーム」にDC係数を保存することである。これにより1:16、1:32などのサブサンプルされた画像に対応するプレビューが可能になる。squeeze変換を使用してVarDCTでエンコードされたカラーチャンネルと共にアルファチャンネルをプログレッシブにエンコードして、両方のモードを連携して動作させることもできる。

JPEG XLはデフォルトで視覚的ニアロスレス（英語版）設定になっており、それでも良好な圧縮率を実現している^[18]。

これらのモードは以下の特定の画像の特徴の個別のモデリングによって援助できる:

• 符号化用のスプライン（英語版）、毛などをエンコードするのに使用される^{[注釈 5]}。
• 文字列、点、スプライトなどの「パッチ」の繰り返し。
• ノイズ合成: ノイズは圧縮が難しいので分離してからデコーダーで再生成する方が良い場合がある。これはAV1などのモダンなビデオコーデックの粒状性合成に似ているが、JPEG XLのノイズ合成はアナログ写真フィルムの粒度の模倣が目的ではなく、高ISO設定時のデジタルカメラで得られるものと同様にピクセルレベルでフォトンノイズ（英語版）をモデリングすることを目的としている。

JPEG XLコーデックはJPEGのDCTブロック係数を8×8VarDCTブロックに直接コピーすることで広くサポートされているJPEGファイルのサブセットを可逆トランスコードでき、JPEG XLの優れたエントロピーエンコードによりファイルサイズを小さくできる。この処理は可逆的であり、元のJPEGファイルをビット単位で再構築できるが、制約により一部のファイルのサポートは制限される^[23]。

予測はパラメータ化された自己修復重みの予測子のアンサンブルを含むサイド情報なしでピクセルごとの非相関器（英語版）を使用して実行される。文脈モデリング（英語版）には特殊化された静的モデルとローカルエラーを考慮し、文脈ごとの合図された木構造と予測子の選択を備えた強力なメタ適応モデルが含まれている。エントロピー符号化はLZ77対応であり非対称数系（英語版）またはプレフィックス符号^{[注釈 6]}のいずれかを使用できる^[16]。

アニメーション（複数フレーム）画像は高度なフレーム間予測を実行しないが、いくつかの基本的なフレーム間符号化ツールが利用できる:

• フレームはキャンバス全体のサイズより小さくてよく、他のピクセルはそのまま残る。
• フレームは加算や乗算などで前のフレームを置き換えるのに加えて、いくつかの混合モードをサポートしている^[24]。
• 最大4つのフレームを記憶でき、「パッチ」符号化ツールを使用して後のフレームから参照できる。

Cloudinary（英語版）に加えて、JPEG XLのウェブブラウザでの試験的実装を通じてFacebook^[25][26]、アドビ^[27][28]、インテルとVESA^[29][30]、ガーディアン^[31][32]、FlickrとSmugMug（英語版）^[33]、Shopify^[34]、Krita財団^[35]、Serif Ltd.^[36]などの著名な産業界ブランドの様々な代表者が、好ましい選択肢としてJPEG XLを支持することを公に表明した。

GoogleはJPEG XLに貢献しているが、ChromiumとGoogle ChromeにJPEG XLを実装して公開することを控えているのでJPEG XLに対する態度は曖昧である。2024年1月にChrome^[37]とFirefox^[38]でJPEG XLサポートを有効にする拡張機能が利用可能となった。

コーデック実装

JPEG XL Reference Software（libjxl）

初版	2019年12月27日 (4年前) (2019-12-27)[39]
最新版	0.10.1 / 2024年2月28日 (43日前) (2024-02-28)
リポジトリ	https://github.com/libjxl/libjxl[40]
プログラミング 言語	C++
対応OS	Unix系 Windows Haiku
ライセンス	修正BSDライセンス[注釈 7]
公式サイト	jpeg.org/jpegxl
テンプレートを表示

• JPEG XL Reference Software（libjxl）
  • ライセンス: 修正BSDライセンス^{[注釈 7]}
  • 内容（一部）:
    • エンコード/デコードライブラリ libjxl
    • エンコーダー cjxl
    • デコーダー djxl
    • 高速な可逆圧縮だけのエンコーダー fjxl
    • 画像コーデックの速度と品質をベンチマークするツール benchmark_xl
    • GIMPとGtk pixbufのプラグイン file-jxl
• J40: 独立した依存関係のないJPEG XLデコーダー^[41]
  • ライセンス: MIT License No Attribution
  • C99のシングルヘッダーライブラリ（依存関係なし）
  • 名前はローマ数字の「XL」（40）に由来する
• libjxl-tiny: JPEG XLの単純なエンコーダー実装で、アルファチャンネルのない写真を目的としている^[42]。
  • ライセンス: 修正BSDライセンス
• jxlatte: Javaで書かれたJPEG XLデコーダー^[43]
  • ライセンス: MIT License
• jxl_decode: Pythonで書かれたJPEG XLデコーダー^[44]。
  • ライセンス: MIT License
• jpeg-xl-encode: a PHPで書かれたJPEG XLエンコーダーのラッパー^[45]。
  • ライセンス: MIT License
• hydrium: 移植性のあるC言語で書かれた高速でメモリ使用量が極めて少ないストリーミングJPEG XLエンコーダー^[46]。
  • ライセンス: BSDライセンス
• jxl-oxide: 完全にRustで書かれた小さなJPEG XLデコーダー^[47]。
  • デュアルライセンス: MIT LicenseとApache License 2.0

公式サポート

• Apple^[48]
  • iOS/iPadOS 17以降 - ファイル（英語版）と写真を含むシステム全体の読み取り
  • macOS Sonoma（バージョン14）以降 - Finderとプレビュー^[49]
  • visionOS（推定）
  • watchOS 10以降
  • Safari 17以降^[50][51]（WebKitエンジン経由^[52]）
• Pale Moon v31.4.0以降^{[注釈 8][53]}
• Epiphany 45^[54]（WebKitGTKエンジン経由^[55]）
• ImageMagick - JPEG XL画像の読み取りと書き込み
• KDEアプリケーションはネイティブにJPEG XLをサポートしているKImageFormatsプラグインを使用してビルドできる^[56]。これにより殆どのKDEアプリでJPEG XLの読み取りと書き込みがネイティブにサポートされ、Dolphin、Gwenview、Krita、digiKam全てで動作する。
• XnView - JPEG XL画像の読み取りと書き込み^[57]

非公式または間接的サポート

• Microsoft Windows - サードパーティーのWindows Imaging Component（WIC）プラグインによりFile Explorer、フォト（英語版）、Windows フォト ビューアー、サムネイル、対応アプリでJPEG XL画像を表示できるようになる。これはWindows 7/10でのみ利用できる^[58]。
• 別のWindows Imaging Componentプラグインとしてjxl-winthumbがある^[59]。
• macOS（14.0 Sonoma以前） - スタンドアロンアプリとQuick Lookのプラグイン経由^[60]
• JPEG XLプロジェクトによって提供されているGDK（英語版） pixbufプラグインを経由したGTKとEye of GNOMEやファイルなどのGNOMEの画像表示アプリ^[61]
• QtにJPEG XLサポートを追加するにはqt-jpegxl-image-pluginが利用できる^[62]

実験的なウェブブラウザでのサポート

• Mozilla Firefox - Firefox Nightly buildでのテストのために導入された^[63]

ChromiumとChromeでのJPEG XLサポートは2021年4月1日にテストのために導入され^[64]、2022年12月10日の変更で関連するソースコードが削除され^[65]、バージョン110でサポートが削除された^[66][67]。Chromeの開発チームはJPEG XLサポートを削除する理由としてエコシステムからの関心の欠如、不十分な改善、既存の画像ファイルフォーマットの改善に注力したいことを言及している^{[64][68][66][69]}。この決定にはコミュニティーからの反対があり、Chromiumのバグ管理システムにはJPEG XLを支持する多くの声が寄せられた^[64][70][68]。JPEG XL仕様の共著者であるJon SneyersはChromeの開発チームの出した結論に疑問を呈し、「データの不運な誤解があったと思います ... 残念なことにそれが誤った〔ママ〕決定に繋がりました。」と述べている^[71]。この決定はフリーソフトウェア財団のGreg Faroughも批判し、ウェブとウェブブラウザにわたるGoogleの「不穏な量のコントロール」を証明していると述べた^[72]。

• AVIF - AV1ビデオコーデックをHEIFコンテナに入れている。
• HEIC - HEVCビデオコーデックをHEIFコンテナに入れている。
• WebP - VP8ビデオコーデックをRIFFコンテナに入れている。

注釈

出典

ウィキメディア・コモンズには、JPEG XLに関連するカテゴリがあります。

• 公式ウェブサイト
• リファレンス実装 - GitHub
  • ナイトリー開発版ビルド（ビルド）
• コミュニティウェブサイト
• J40 - 独立した依存関係のないJPEG XLデコーダー