JPEG XLは、非可逆圧縮と可逆圧縮の両方をサポートするロイヤリティフリーのラスター画像ファイルフォーマットである。既存のラスター形式よりも優れた性能になるように設計されているので、それらの普遍的な代替品となる。

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

 作者 
この形式の仕様の主な作者は、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の技術公募を公表した。提案は2018年9月までに提出され、2019年7月の委員会草案に繋がった。この提案は主にGoogleが提出したPIKと呼ばれる提案と、が提出したFUIFと呼ばれる提案を統合したものに基づいていた。

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

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

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

 特徴 
主な特徴は以下の通りである:

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

 技術的な詳細 

JPEG XLはGoogleのPIK形式とのFUIF形式のアイデアに基づく。

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

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

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

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

JPEG XLはデフォルトで設定になっており、それでも良好な圧縮率を実現している。

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

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

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

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

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

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

 産業界のサポートと採用 
に加えて、JPEG XLのウェブブラウザでの試験的実装を通じてFacebook、アドビ、インテルとVESA、ガーディアン、Flickrと、Shopify、Krita財団、Serif Ltd.などの著名な産業界ブランドの様々な代表者が、好ましい選択肢としてJPEG XLを支持することを公に表明した。

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

 ソフトウェア 

 コーデック実装 

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

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

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

 実験的なウェブブラウザでのサポート 
 Mozilla Firefox - Firefox Nightly buildでのテストのために導入された

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

 標準化状況 
 一般名 部 初公開日（初版） ISO/IEC規格番号 正式題名 JPEG XL 第1部 2022年3月30日 ISO/IEC 18181-1 JPEG XL Image Coding System — Part 1: Core coding system（）第2部 2021年10月13日 ISO/IEC 18181-2 JPEG XL Image Coding System — Part 2: File format（）第3部 2022年10月3日 ISO/IEC 18181-3 JPEG XL Image Coding System — Part 3: Conformance testing（）第4部 2022年8月5日 ISO/IEC 18181-4 JPEG XL Image Coding System — Part 4: Reference software（）

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