JPEG XL、画素が紡ぐ未来の「完璧」と「不完全」の物語 #JPEGXL #次世代画像 #デジタル遺産

JPEG XL、画素が紡ぐ未来の「完璧」と「不完全」の物語 #JPEGXL #次世代画像 #デジタル遺産

〜私たちは、なぜ、終わりなき圧縮の螺旋に囚われるのか？その深淵を探る〜

目次

序章：本書の目的と構成

本書の目的と意義

デジタル画像。それは私たちの日常を彩り、記憶を紡ぎ、知識を伝える、まさに現代文明の生命線と言えるでしょう。しかし、その「生命」たる画像は、常に「重さ」という厄介な宿命を背負ってきました。高精細化、高ダイナミックレンジ化が進むにつれ、一枚の画像が数メガバイト、時には数百メガバイトにも膨れ上がり、通信帯域を食い荒らし、ストレージを圧迫する。そんな不毛な消耗戦に終止符を打つべく、JPEG XLという新たな画像圧縮フォーマットが誕生したのです。本章では、このデジタル画像の「救世主」とも目されるJPEG XLが、いかにして生まれ、何を目指しているのか、そしてその存在が私たちのデジタルライフにどのような変革をもたらすのかを、ニヒルかつシニカルな視点も交えつつ解説していきます。まるで、画素の深淵を覗き込むような、そんな体験が待っているかもしれません。

本書の構成と読み方

本書は、JPEG XLの複雑なメカニズムを、歴史的背景から将来展望まで多角的に解き明かすことを目的としています。技術の「なぜ」と「いかに」を深掘りし、その設計思想にまで踏み込むことで、単なる機能説明に終わらない、深い洞察を提供します。

専門家から初心者まで：多様な読者へのアプローチ

  • 技術者・開発者向け: JPEG XLの内部構造、VarDCTやModularモードの詳細、エントロピー符号化の仕組みなど、技術的詳細を深く掘り下げます。既存の画像処理技術との比較を通じて、その革新性を理解いただけるでしょう。
  • 写真家・デザイナー・クリエイター向け: 色空間、HDR、ロスレス圧縮、プログレッシブデコードなど、実用的なメリットに焦点を当てます。作品の品質を維持しつつ、いかに効率的なワークフローを構築できるか、そのヒントが隠されています。
  • ビジネスパーソン・一般ユーザー向け: JPEG XLがWebサイトの表示速度やストレージコスト、デジタルアーカイブに与える影響など、その社会経済的意義を分かりやすく解説します。技術がもたらす未来の可能性を感じ取っていただければ幸いです。

章ごとのテーマと技術的詳細の深さ

本書は三部構成となっております。第一部では、デジタル画像の黎明期から現代に至るまでの画像圧縮技術の歴史を紐解き、JPEG XLがその系譜においてどのような位置づけにあるのかを解説します。第二部では、JPEG XLの設計思想、主要な特徴、そしてその開発に携わった「狂気の天才たち」をご紹介します。そして第三部では、いよいよJPEG XLの核心である符号化メカニズム、すなわち画素がどのようにして効率的に、そして美しく圧縮されるのかを、その変態的なまでに精緻なアルゴリズムの深淵へと誘います。各章の終わりには、著者のニヒルな「コラム」もご用意しました。どうか、飽きずに最後までお付き合いください。

第一部: 黎明期の光と影 - 画像圧縮の系譜

第一章：画素の歴史的位置づけ

かつて、画素は単純な点に過ぎませんでした。しかし、技術の進化は、その点に色を与え、奥行きを与え、そして魂を与えてきました。この章では、デジタル画像が辿ってきた数奇な運命と、それに伴い進化してきた圧縮技術の「残酷な」歴史を振り返ります。

1.1 デジタル画像の誕生と進化

デジタル画像の夜明けは、驚くほど粗野なものでした。画面に描かれるのは、わずかな色の点滅。しかし、その原始的な光の中に、私たちは無限の可能性を見出していたのです。

1.1.1 初期コンピューターグラフィックスの時代

1980年代初頭、パーソナルコンピューターの登場とともに、ディスプレイ技術は稚拙ながらも発展を遂げます。CGA（Color Graphics Adapter）は、わずか4色パレットで320x200ピクセル、あるいはモノクロで640x200ピクセルという、現代の目から見れば冗談のような解像度でした。しかし、当時としては画期的な色彩表現であり、限られたメモリと処理能力の中で、いかに効率よく画像を表現するかが課題でした。続くVGA（Video Graphics Array）は、1980年代後半に640x480ピクセルで256色、そして1990年代初頭のSVGA（Super Video Graphics Array）は800x600ピクセルで「ハイカラー」（15または16ビット）を実現します。そして、1990年代後半にはXGA（Extended Graphics Array）が1024x768ピクセルで「トゥルーカラー」（24ビット、RGB各8ビット）を提供し、あたかも現実の色をそのまま画面に映し出せるかのような錯覚を与えました。しかし、これらの解像度と色深度の向上は、同時に画像データ量の爆発的な増加を意味していたのです。

1.1.2 デジタル写真の経済的実現

2000年代に入ると、デジタルカメラはアナログ（フィルム）写真を猛追し、瞬く間にその座を奪い去りました。いわゆる「メガピクセル競争」の幕開けです。最初の商用デジタル一眼レフカメラであるコダックDCSは、1.3メガバイトの画像を生成しましたが、現代のiPhoneは48メガピクセルの非圧縮画像を182メガバイトで生成します。CGA時代の画像と比較すれば、そのサイズは実に2000倍。この天文学的なデータ量の増加は、ストレージコストの増大、帯域幅の枯渇、そしてWebサイトやモバイルアプリでの画像転送速度の低下という、新たな「厄災」をもたらしました。ロスレス圧縮と非可逆圧縮は、この厄災から私たちを救うための「魔法の杖」として、その重要性を増していったのです。

1.2 前駆体としての画像コーデック

画像圧縮の歴史は、さながら技術者たちの屍の上に築かれた壮大な墓標のようです。数多のフォーマットが生まれ、消え、あるいは特定のニッチに留まりました。しかし、それらは全て、JPEG XLという「終焉」への布石だったのかもしれません。

1.2.1 IFF（Interchange File Format）：コンテナ形式の祖母

1985年にエレクトロニック・アーツとコモドールによって導入されたIFF（Interchange File Format）は、その後のデジタルデータ形式に多大な影響を与えた、まさに「コンテナ形式の祖母」と呼ぶにふさわしい存在です。その核心は、4バイトのタイプ識別子と32ビットのサイズフィールドで構成されるチャンク構造にありました。この設計により、実装は未知のチャンクをスキップできるため、後方互換性を保ちながら新しいデータタイプを簡単に追加できるという、極めて柔軟な拡張性を実現しました。これはMicrosoftのRIFFコンテナや、AppleのQuickTimeコンテナ（後のISOBMFFの基盤となる）、そしてMP4やHEIFへと続く流れの源流となり、PNGのチャンク構造もまた、IFFからインスピレーションを得たとされています。

IFFの技術的貢献と普及>

IFFはCommodore Amigaプラットフォームで人気を博し、その上に構築されたインターリーブビットマップ（ILBM）形式は、最大256色のパレットイメージ（後に24ビットRGBに拡張）をサポートしました。さらに、PackBitsとして知られるシンプルなランレングスエンコーディング（RLE）スキームに基づくオプションの圧縮機能も備えていました。このモジュール性と拡張性は、現代の多くのファイル形式の設計思想に深く根ざしており、JPEG XLが目指す「ユニバーサルコーデック」という概念にも、その影響を垣間見ることができます。

1.2.2 GIF（Graphics Interchange Format）：Webアニメーションの先駆者

1987年、CompuServeが導入したGIF（Graphics Interchange Format）は、デジタル画像の交換フォーマットとして最初の「メジャー」な存在となりました。最大256色のパレットのみをサポートするという制約はあったものの、当時のディスプレイ技術の限界と相まって「ロスレス」な画像形式として認識されました。GIFの圧縮は、LZW（Lempel-Ziv-Welch）エントロピー符号化に基づいており、これは単純なRLEや非圧縮方式よりも大幅な改善をもたらしました。特に写真以外の合成画像では、その圧縮効率が際立っていました。1989年の改訂では、単純なアルファ透過性（バイレベルのみ）と、現代のインターネット文化の礎ともなる「アニメーション」のサポートが導入されました。初期のワールドワイドウェブにおいて、GIFは最初のグラフィカルWebブラウザによって瞬く間にサポートされ、その地位を確立します。

GIFが切り開いた「合成画像」と「プログレッシブデコード」>

GIFは、複数のフレームを重ねて合成画像を生成する「画像キャンバス」の概念を導入しました。これは、後のJPEG 2000、APNG、MNG、HEIF、そしてJPEG XLにも受け継がれる重要なアイデアです。さらに、GIFが先駆けたもう一つの画期的な概念は、「プログレッシブデコード」でした。これは、部分的な画像データが転送される途中で、画像の低解像度プレビューを表示するというもので、ダイヤルアップインターネットアクセスの時代には非常に高く評価されました。GIFでは、単純な4パスラインインターレース方式で実現され、画像がベネチアンブラインドのように段階的に表示されていきました。これは後にJPEGやJPEG XLでさらに洗練される技術の萌芽であり、現代のウェブ体験の基盤となっています。

コラム：私がGIFに見た、Webの未来

私が初めてGIFアニメーションを見たのは、まだインターネットがダイヤルアップ接続で、画像が「じわじわ」と表示される時代でした。あのベネチアンブラインドのようなプログレッシブデコードは、遅い回線でも「何か」が表示されているという安心感を与えてくれました。小さな猫が瞬きをするだけのループアニメーションが、当時の私にはとてつもない魔法のように映ったものです。「こんなものが個人でも作れるのか！」と興奮したのを覚えています。しかし、その「魔法」の裏にはLZW特許という「現実」が潜んでおり、それがPNGの誕生という、また別の進化を促した。技術の進化とは、常にそうした光と影の繰り返しなのだと、このGIFの歴史は教えてくれます。人間は本当に、ちょっとした便利さのためなら、どんな困難も乗り越える生き物ですね。

1.2.3 JPEG（Joint Photographic Experts Group）：写真圧縮のデファクトスタンダード

今日に至るまで、最も広く普及し、ある意味でデジタル画像の同義語ともなっているのが、1992年に標準化されたJPEGコーデックです。その名の通り、それを開発した委員会名に由来するJPEGは、史上初の「ロスリー」画像コーデックとして歴史に名を刻みました。写真画像において、JPEGは他の画像形式と比較して一桁低いビットレートで視覚的に遜色ない圧縮を可能にしたため、瞬く間に業界標準となりました。デジタルカメラが経済的に実現可能になったのも、JPEGの存在なくしてはありえなかったでしょう。Webブラウザも迅速にJPEGをサポートし、その普遍性は誰もが認めるものとなりました。

FOSS実装とデファクト標準の葛藤>

JPEGの成功の一因は、そのベースラインモードがロイヤリティフリーであり、FOSS（Free Open Source Software）実装が早期に利用可能だった点にあります。libjpegライブラリは1991年にリリースされ、広く利用されました。しかし、これにより皮肉なことに、1992年の完全な標準の「サブセット」が事実上の標準となってしまいました。算術符号化のような特許に抵触する要素や、当時の実用性から低かったモード（12ビット精度、階層モード、ロスレスモードなど）は、ほとんどの実装でサポートされず、結果として事実上のJPEG形式の一部とはなりませんでした。JPEG XLの開発において、この教訓は強く意識されました。高品質なFOSS実装を早期に提供し、特許に制約された技術を回避することで、JPEGの二の舞を避ける努力がなされています。

JPEG XLの設計における重要な要素の一つは、既存のJPEG画像データをJPEG XLで表現できるようなJPEG形式の「スーパーセット」となることでした。JPEGが採用する離散コサイン変換（DCT）に基づいているため、JPEG XLは既存のJPEG画像の量子化されたDCT係数をそのまま保存し、ロスレストランスコーディングを可能にします。これにより、ファイルサイズが約20%削減され、デジタル遺産の移行時に世代損失（非可逆トランスコーディングによる追加の圧縮アーティファクト）が発生しないという、画期的なメリットが実現しました。

並列処理とプログレッシブデコードの進化>

JPEGは当時のシングルスレッドプロセッサ向けに設計されたため、並列デコードの機会は限られていました。対照的に、JPEG XLはデータ形式の設計段階から命令レベルとマルチスレッド並列処理を考慮しており、マルチコアプロセッサ上でJPEGを遥かに凌駕するエンコード/デコード速度を実現します。この効率向上は、ロスレス再圧縮されたJPEGソースデータの場合にも顕著です。

JPEGとJPEG XLはどちらもプログレッシブデコードをサポートしますが、そのアプローチは異なります。従来のJPEGではプログレッシブモードはオプションであり、多くのファイルが上から下へのシーケンシャルデコード方式でした。しかし、JPEG XLのVarDCTモードでは、エンコーダがベースラインレベルのプログレッシブ機能を提供することを義務付けています。これにより、開発者は画像ビューアやWebブラウザなどのアプリケーション全体でプログレッシブレンダリングをより広範に実装することが期待されます。さらに、JPEG XLは従来のJPEGでは不可能だった「センターファースト」のようなカスタムリファインメントオーダーも可能にし、より柔軟なユーザー体験を提供します。

コラム：JPEGの呪縛と、その恩恵

私がプロとして画像処理の世界に足を踏み入れた頃、JPEGはすでにデファクトスタンダードでした。高圧縮で、Webでもデジカメでも「当たり前」に使える。しかし、その「当たり前」の裏には、様々な技術的妥協と、一部機能の放棄があったことを、この論文は示唆しています。特に、特許問題が「完全なJPEG」の普及を阻んだという事実は、なんとも皮肉なものです。

私はよく、JPEGのファイルを大量に扱う仕事をしていました。サーバーの容量と帯域を圧迫するJPEGの存在は、常に頭痛の種でした。しかし、その一方で、JPEGがなければ、現在のデジタルフォト文化は生まれなかっただろうとも思います。もしJPEGがここまで普及していなかったら、高解像度の写真を気軽に共有するなんて、夢のまた夢だったはずです。JPEG XLは、そんなJPEGの「レガシー」を尊重しつつ、その「呪縛」から私たちを解放しようとしている。過去を否定せず、未来を創る。これこそが、真の技術進化の姿なのかもしれませんね。

1.2.4 PNG（Portable Network Graphics）：ロイヤリティフリーの透過フォーマット

1994年12月24日、CompuServeがGIFのLZW圧縮にUnisysが特許を保有していることを知らなかったという、なんとも牧歌的な時代に終止符が打たれました。Unisysが特許の実施を宣言し、商業オンライン情報サービスプロバイダーにライセンス料の支払いを義務付けたのです。この発表は広範な非難を巻き起こし、結果としてロイヤリティフリーの代替フォーマットであるPNG（Portable Network Graphics）の開発へと繋がりました。その名称は正式には「Portable Network Graphic」ですが、「PINGはGIFではない」という再帰的な頭字語（PING Is Not GIF）としても知られています。

Deflate圧縮と高度な透過性>

PNGは、LZ77スライディングウィンドウ辞書符号化とハフマン符号化の組み合わせであるDeflate圧縮に基づいており、これはZIPおよびgzipファイル形式でも使用されているのと同じ手法です。GIFと比較して、PNGは実質的な改善をもたらしました。パレットだけでなく、トゥルーカラー（8ビット、さらにはコンポーネントあたり16ビット）もサポートし、GIFの単純な2レベルの透明度（完全に不透明または完全に透明）の代わりに、半透明ピクセルをサポートすることで、透明マスク内の滑らかなアンチエイリアスエッジや影と半透明領域のモデリングを可能にしました。

GIFに対するもう一つの改善点は、7パスインターレーススキーム（Adam7として知られる）を使用するオプションです。これにより、GIFよりも優れたプログレッシブプレビューが得られます。しかし、これは圧縮性能にはコストがかかるものでした。

アニメーションの課題と「普遍性」への教訓>

PNGは、ロスレス圧縮を提供し、ワークフローのオーサリングに必要な色精度とアルファ透過性のサポートを備えているため、人気の交換フォーマットとなりました。Web上でも瞬く間に普遍的にサポートされるようになり、使用量の点でGIF（ただしJPEGではありません）を上回りました。しかし、PNGは当初アニメーションをサポートしていませんでした。アニメーションサポートでPNGを拡張する方法については意見の相違があり、最終的にはるかに単純なAPNG（Animated PNG）が勝利しましたが、全ての主要ブラウザがサポートするまでには2017年までかかりました。このアニメーションサポートの欠如により、PNGはGIFを完全に置き換えることができませんでした。結果として、「GIF」は「ショートループアニメーション」の代名詞となるほど、広く使用され続けました。

この経験は、JPEG XLの設計において重要な教訓となりました。「もし新しいフォーマットが、置き換えようとする古いフォーマットの全ての機能を完全にカバーしなければ、古いフォーマットは必然的に使用され続けるだろう」というものです。JPEG XLは、JPEG、PNG、GIFが提供する全ての機能を例外なくカバーすることを重要な目標としました。これにより、あらゆる種類の画像に単一のフォーマットを使用できる可能性が生まれるわけです。

1.2.5 TIFF（Tag Image File Format）：プロフェッショナルワークフローの要

GIFよりもさらに早く、1986年にAldus Corporation（後にAdobeに買収）によってリリースされたTIFF（Tag Image File Format）は、非常に複雑で多用途なフォーマットであり、多種多様なペイロードコーデックと画像データタイプを格納できます。長年にわたり、多くの拡張が導入され、中にはプロプライエタリなものも含まれています。ベースラインTIFF（TIFF 6.0 Part 1）は、圧縮オプションが限られており、非圧縮またはシンプルなPackBits RLEスキームのみをサポートしています。LZW、Deflate、JPEG、JBIG、JPEG 2000、JBIG2、さらにはJPEG XLを含むより優れた圧縮オプションは、TIFFの様々な拡張機能として利用可能です。しかし、全ての拡張をサポートするアプリケーションはほとんど存在しないため、実用上、相互運用性を望む場合はベースラインフォーマットに固執せざるを得ません。

オーサリングワークフローにおけるTIFFの重要性>

TIFFの柔軟性は、オーサリングワークフローや出版業界で広く使用されるフォーマットとしての地位を確立させました。JPEGやPNGが導入された後も、JPEG 2000が登場するまで、TIFFはCMYK画像をロスレスで表現したり、マルチレイヤーやマルチページ画像を保存したり、衛星画像のようなマルチスペクトル画像を表現したりできる、唯一の相互運用可能な画像フォーマットであり続けました。

オーサリングワークフローにおいてTIFFが持つ利点の一つは、高速なエンコードが可能な点です。これは主にその（ベースライン）圧縮の単純さによるものですが、タイルもサポートしているため、編集中に大きな画像を頻繁に保存する必要がある場合に重要です。JPEG XLの設計目標の一つは、CMYKサポート、レイヤー/マルチページ画像、コンポーネント数の制限なし、高速エンコードオプションなど、TIFFのほとんど（すべてではないにしても）の機能を持つことでした。この豊富な機能セットにより、JPEG XLはオーサリングワークフローにおける交換フォーマットとしてTIFFの実現可能な代替となる可能性を秘めています。

1.2.6 JPEG 2000：次世代への挑戦とその挫折

標準化された年を冠したJPEG 2000は、オリジナルのJPEGフォーマットの後継として開発されました。しかし、その圧縮性能の向上は、JPEGが一般的に使用されていた典型的な品質範囲では、ごくわずかでした。これは「JPEG 2000は、JPEGが十分に機能するビットレートの低複雑度アプリケーションではJPEGに取って代わる可能性は低い。しかし、より高い品質やより低いビットレート、あるいは提供される機能のいずれかを必要とするアプリケーションでは、JPEG 2000は歓迎される標準となるだろう」という論文の結論にも示されています。

柔軟性と採用の障壁>

JPEG 2000の主な利点は、圧縮性能ではなく、機能性と柔軟性にありました。ビットストリームの順序付けに多くの制御を提供し、画像をタイルに分割し、それをさらにプレシンクト、そして品質レイヤーごとにパケットに分割できるため、コードストリーム内でパケットをほぼ任意に並べ替えることが可能でした。これは大きな柔軟性をもたらしましたが、同時にデコーダ実装の複雑さを著しく増大させました。

JPEG XLでは、ビットストリーム順序付け構文の設計において、複雑さと柔軟性の間のスイートスポットを見つけようと試みています。JPEG 2000のタイル、プレシンクト、パケット、レイヤーは、JPEG XLではそれぞれフレーム、グループ、セクション、パスに対応します。JPEG 2000と比較して、JPEG XLではビットストリームの順序付けに関して柔軟性がやや劣りますが、これはデコードの計算コストが大幅に増大するような柔軟性を回避するための意図的な設計判断です。

JPEG 2000は、医療画像（DICOM）、デジタルシネマ（DCP）、衛星画像、気象データ（GIS）といった特定のニッチで普及しました。また、PDFバージョン1.5以降、PDFでラスター画像をエンコードするために使用できるペイロードコーデックの一つでもあります。しかし、JPEGほどユビキタスにはなりませんでした。その一因として、一般的な消費者向けユースケースにおいて、JPEG 2000の圧縮メリットがJPEGからの移行を正当化するほど大きくなかったことが挙げられます。また、特許問題への不安心理も普及を阻みました。ベースラインJPEG 2000コーデック（標準のPart 1）はロイヤリティフリーとして設計されましたが、GIFに関するUnisysの主張、そしてJPEGに関するForgent Networksの特許主張（最終的には無効化されるが、2006年までかかった）といった最近の経験が、特にJPEG 2000のような複雑な新しいコーデックの採用に際して、高いレベルの不安、不確実性、不信（FUD）を引き起こしたのです。

最後に、JPEG 2000の広範な普及に対するおそらく最大の障害は、コーデックが導入されてから10年以上にわたって高品質なFOSS実装が存在しなかったことでした。リファレンスソフトウェアであるJasPerは当初から利用可能で、2004年にオープンソースライセンスでリリースされましたが、それは性能ではなく参照目的で設計されたため、非常に低速で実用的ではありませんでした。同様にJavaベースのJJ20000も同様でした。これにより、JPEG 2000は計算負荷が高いという評判を得てしまいました。商業的な実装であるKakaduは高速ですが、無料ではありません。OpenJPEGライブラリは無料で合理的に高速ですが、標準のPart 1に完全に準拠するまでに2014年までかかりました。JPEG XLの採用におけるこのような障害を避けるため、標準の開発は高速で無料の実装であるlibjxlの開発と並行して進められました。

1.2.7 JPEG LS：ロスレス圧縮の進化

1993年のJPEG標準への追加で、ロスレスモードが追加されましたが、これはデファクトスタンダードとはならず、一般的にJPEGデコーダではサポートされていませんでした。しかし、DICOMやDNGファイル形式ではペイロードコーデックとして使用されています。1999年に導入されたJPEG LSは、ロスレスJPEGを改善しつつ、複雑さを低く保つように設計されました。その圧縮性能はロスレスJPEGを大幅に上回り、ロスレスJPEG 2000に匹敵する一方で、JPEG 2000よりも単純で高速でした。

非写真画像における課題とJPEG XLの解決策>

しかし、スクリーンショット、チャート、ロゴ、イラスト、ピクセルアートといった非写真画像では、PNGの圧縮性能がJPEG LSとJPEG 2000の両方を上回っていました。この種の画像コンテンツでは、PNGの辞書ベースのエントロピー符号化（およびカラーパレットを使用するオプション）が明確な優位性をもたらしました。これが、PNGがすでに定着していたシナリオでJPEG LSの採用が限定的であった理由と考えられます。

JPEG XLは、画像コンテンツの種類（写真か否か）にかかわらず、PNGと比較して大幅なロスレス圧縮の改善をもたらします。従来のJPEGコーデックとは異なり、非写真画像に特化した符号化ツールも含まれています。これは、JPEG LSやJPEG 2000が果たせなかった汎用的なロスレス圧縮の優位性を確立する試みと言えるでしょう。

1.2.8 JBIG2（Joint Bi-level Image Experts Group）：バイレベル画像の最適化

1970年代から80年代にかけて、FAX機、コピー機、プリンターがアナログからデジタルへと移行する中で、当初は主にバイレベル画像（1ビット、白黒）に焦点が当てられました。ITU-T（国際電気通信連合電気通信標準化部門）は、FAX機用のGroup 3（ITU-T T.4）およびGroup 4（ITU-T T.6）という標準を作成しました。これらは、ランレングスエンコーディングとハフマン符号化の組み合わせに基づいており、線は上の線によって予測されます。1993年にはGroup 4圧縮を改善するJBIG1が導入され、2000年にはさらなる改善としてJBIG2がリリースされました。これは現在でもバイレベル画像向けの最も高度な標準化フォーマットであり、PDFバージョン1.4以降、PDF標準の一部となっています。

パターンマッチングと信頼性問題>

JBIG2の主要な符号化ツールの一つは、パターンマッチングと置換（PM&S）であり、リファインメントデータを用いたソフトパターンマッチング（SPM）のオプションも含まれます。これは実質的に、1次元の文字列だけでなく2次元のパターンを参照できるようにするLZ77辞書符号化の一般化です。リファインメントデータはオプションであるため、「十分に似ている」パターンをマッチとして使用することで、JBIG2をロスリーに適用することが可能です。

2013年、Xerox Workcentreコピー機がスキャン文書（例：建築設計図）で「6」が「8」に置き換わるなどの置換エラーを発生させていることが報告され、JBIG2をめぐって議論が巻き起こりました。これはロスリーJBIG2圧縮を適用したことが原因でした。過度に積極的なJPEG圧縮のアーティファクトが明らかなDCTノイズやぼやけであるのに対し、この過剰なJBIG2圧縮によるアーティファクトは全く目立たないものでした。この問題により、ドイツやスイスの政府機関はJBIG2の使用を推奨しない事態となりました。

さらに最近では、2021年9月に「ForcedEntry」セキュリティエクスプロイト（CVE-2021-30860）が発見され、JBIG2は再び悪評を呼びました。これは、政治的反体制派や人権活動家を標的としたiOSの「ゼロクリック」エクスプロイトであり、悪意のあるメッセージを送信するだけで、ユーザーの操作なしに携帯電話を危険にさらすことが可能でした。.gifファイル名拡張子を持つファイルが実際にはJBIG2ペイロードを含むPDFであり、ImageIOライブラリに自動的にデコードされ、JBIG2デコーダの実装における整数オーバーフローバグと、JBIG2をチューリング完全にする極めて表現力の高いビットストリーム構文の組み合わせにより、攻撃者はJBIG2をスクリプト言語として使用し、Appleの「BlastDoor」サンドボックスを回避してスパイウェアをインストールすることができました。

JPEG XLの設計では、ビットストリームは非常に表現力が高いものの、チューリング完全になるような要素は全て回避されました。実装バグが常にセキュリティ問題を引き起こす可能性はあるものの、libjxlの開発中には、静的および動的なコード分析ツール、自動テスト、ファジング技術を用いて、リスクを最小限に抑えるために多大な労力が費やされています。

1.2.9 WebP：Web向けの新星と限界

2010年、GoogleはWebPフォーマットをWeb上のJPEG代替として発表しました。これはVP8ビデオコーデックのイントラオンリーサブセットに基づいており、GoogleがVP8を設計したOn2 Technologiesを買収した後、ロイヤリティフリーフォーマットとしてリリースされました。WebPはJPEGのプログレッシブデコード機能に欠けており、これはビデオコーデックの起源から受け継いだ制約でした（ビデオコーデックではそのような機能はほとんど関係ないため）。真のプログレッシブではないものの、WebPのlibwebpライブラリは増分デコードをサポートしており、データが到着するにつれて画像を上から下へレンダリングします。

ロスレスWebPとスコープの制約>

2012年、初期の発表とロスリーWebPに対する公開フィードバックを受けて、Jyrki AlakuijalaはWebPにロスレスおよび透明度符号化機能を追加するための新しい画像圧縮フォーマットを開発しました。この新しいコーデックは圧縮においてPNGを常に上回ります。ロスレスWebPの主要な革新は、エントロピー画像の概念（後にBrotliとJPEG XLのコンテキストマップに発展した、より単純で厳密な2次元エントロピー符号化マップ）、Select非線形予測器、および後にJPEG XLのModularモードでも使用される2次元距離コードでした。良好なブラウザサポートのおかげで、ロスレスWebPは現在、ロゴ、スクリーンコンテンツ、およびピクセルベースの圧縮の恩恵を受けるその他の画像をWeb配信するための最有力候補となっています。

ロスレス圧縮と透明度の追加により、WebPはWeb上でJPEG、PNG、GIFを置き換える準備が整いました。しかし、VP8から受け継いだいくつかの制約（例：8ビット制限範囲のYCbCrと4:2:0クロマサブサンプリングのみのサポート、8ビット制限範囲のRGBA、最大解像度16383x16383ピクセル）のため、WebPはPNGやTIFFのようなプロフェッショナルなオーサリングワークフローで利用されるフォーマットを置き換えることはできませんでした。

「WebP」という名前が示す通り、このフォーマットはWebに特化して設計されました。このため、特定のビットストリーム制限（特に、強制的なクロマサブサンプリング、8ビット精度への制限、画像寸法の制限）が許容されるか、あるいは望ましいとさえ考えられました。また、Webブラウザ以外のソフトウェアサポートに比較的重点が置かれなかった理由もここにあります。例えば、Chromeは2011年初頭からWebPをサポートしていましたが、GIMPがWebPサポートを追加したのは2018年、Adobe Photoshopは2022年、Microsoft Windows Photosは2023年までかかりました。このような状況は、Webページから保存した画像がブラウザ以外の他のプログラムで開けないという、ユーザーにとって不満の多い体験を生み出しました。

対照的に、JPEG XLは単一の主要アプリケーションに焦点を当てるのではなく、幅広いユースケースを明示的にターゲットとしています。それにもかかわらず、Web配信はJPEG XLの設計における主要なアプリケーションドメインの一つと見なされており、最小限のヘッダーオーバーヘッドやプログレッシブデコードなど、Web上の画像に特に役立つ特定のビットストリーム機能が導入されています。

Googleは当初からWebPを積極的に推進し、PageSpeed InsightsツールやLighthouse監査を通じてWeb開発者にJPEGやPNG画像をWebPに置き換えることを推奨していました。しかし、Mozilla（Firefox）とApple（Safari）は、WebPが最適化されたJPEGに対して「十分に大きな改善」をもたらすとは確信していませんでした。彼らの主張を裏付けるため、MozillaはMozJPEGという新しいJPEGエンコーダの開発を開始しました。これは、一般的に使用されているlibjpeg-turboエンコーダよりも優れた圧縮性能を持ち、その代わりにエンコード速度が遅い（しかし許容範囲内）という特徴がありました。このフォーマットの人気により、最終的にFirefoxとSafariの両方がWebPサポートを追加しましたが、それぞれ2019年と2020年になってからでした。

1.2.10 FLIF（Free Lossless Image Format）：ロスレス圧縮の革新

2015年に導入されたFLIF（Free Lossless Image Format）は、PNGの圧縮性能を改善するためにJon SneyersとPieter Wuilleによって作成されました。そのビットストリーム構文には、YCoCg-R色変換やパレット変換といった、シグナル化された一連の変換が含まれており、このメカニズムは最終的にJPEG XLのModularモードへと発展しました。通常の「スキャンラインオーダー」（各行を左から右へ、上から下へ）に加えて、FLIFは「Adam-∞インターレース」と呼ばれるインターレースサンプルオーダーも含まれており、これはPNGのAdam7インターレースを一般化したものです。PNGとは対照的に、インターレーススキャンは独立して符号化されるのではなく、以前のスキャンからのサンプルが現在のサンプルの予測とコンテキストモデルで使用されます。これにより、すでにデコードされた7つの隣接位置のサンプルを参照することが可能になり、スキャンラインオーダーを使用した場合の4つの位置（W, NW, N, NE）よりも多くの情報を利用できます。

高圧縮の代償とJPEG XLへの影響>

YからCoとCgよりも優先されるインターレーススキャンの慎重な順序付けは、欠落サンプルを補完するための補間アルゴリズムと組み合わせることで、PNGのインターレースよりも大幅に優れたプログレッシブプレビューをもたらします。また、ファイルを単に切り詰めることで、FLIFをロスリーに使用することも可能でした。

FLIFの主な革新は、Meta-Adaptiveコンテキストモデルの使用でした。これは、MAツリーと呼ばれるシグナル化された決定木で構成されています。これは二分木であり、各ノードはローカルな「プロパティ」の値を閾値と比較し、閾値を超える場合と以下の場合で異なる分岐に分けられます。プロパティには、他のすでにデコードされたコンポーネントにおける現在の位置のサンプル値、隣接するすでにデコードされたサンプルの差分、現在のサンプルの予測値などが含まれます。プロパティのインデックスと閾値はシグナル化され、エンコーダが画像コンテンツに適合するようにコンテキストモデル自体を適応させることができます。

しかし、FLIFの高い圧縮密度は、そのコアコンポーネントであるインターレース手法、高度に条件付けされたコンテキストモデル、および複雑なCABACバリアントのエントロピー符号化の直接的な結果でした。これらのコンポーネントは、デコード速度を著しく制約しました。インターレースとコンテキストモデリングによって導入される複雑なデータ依存性は、効果的な並列処理を阻害し、劣悪なメモリ局所性を引き起こします。さらに、その圧縮戦略の不可欠な要素である、計算コストの高い分岐命令の頻繁な使用は、デコード中の性能ボトルネックを生み出しました。デコード速度は画像圧縮、特にWebにとって非常に重要な要素であり、遅いデコードは高速なファイル転送の利点を無効にしてしまいます。画像をユーザーに表示する総時間が短縮されなければ、データ圧縮の主な目的は達成されません。これらの要因と、競争力のないロスリー画像品質が、FLIFの採用が非常に限定的であり、Webブラウザで広く実装されなかった理由と考えられます。

JPEG XLのModularモードはFLIFから強く影響を受けていますが、高速デコードに重点を置いて再設計されました。Jyrki Alakuijala、Jon Sneyers、そしてLuca Versariらが中心となり、FLIFのいくつかのコアコンポーネントは、より高性能な代替品に置き換えられました。エントロピー符号化は、複雑で分岐の多いCABACバリアントから、静的確率を持つ高スループットのANS実装へと移行しました。これにより、最も重い計算はエンコード時にのみ行われるようになりました。さらに、FLIFの複雑なインターレース手法は廃止され、オプションのSqueeze変換に置き換えられました。これは、高品質なプログレッシブデコードと、デコード中のメモリアクセスパターンの局所性向上という二重の利点を提供します。

1.2.11 Brotli：汎用データ圧縮の応用

2013年、Jyrki AlakuijalaとZoltán Szabadkaは、新しい汎用データ圧縮フォーマットであるBrotliを発表しました。これは、W3CのWeb Open Font Format 2（WOFF2）のために開発されたもので、確立されたDeflate（gzip）メソッドと比較して優れた圧縮性能を提供します。Brotliはプレフィックス符号化を使用し、LZ4やZstandardと同様に、重複するデータを[copy-length, copy-offset, insert-length, insert-string]のカルテットメタデータで置き換えます。Brotliは、2次コンテキストモデリング、事前定義された辞書、ブロック切り替えのためのムーブトゥーフロント変換、およびコピー長と挿入長の共同確率符号化を組み込むことで、他の高速汎用データ圧縮器とは一線を画しています。2016年にIETF（Internet Engineering Task Force）によって承認され、圧縮されたHTTP転送のコンテンツエンコーディングとして広く採用されました。

コンテキストマップの革新>

Brotliの主要な革新の一つは、コンテキストマップの導入でした。これにより、大量のプレフィックスコードをシグナル化するオーバーヘッドなしに、比較的大きなコンテキストモデルを使用できるようになりました。この概念はJPEG XLでも使用され、VarDCTとModularモードの両方で活用されています。MAツリーと組み合わせることで、結果として得られるデータ構造は実質的に有向非巡回グラフ（DAG）となります。これは、大規模なメタ適応型コンテキストモデルと静的確率分布を組み合わせるための重要な要素です。

1.2.12 ButteraugliとXYB色空間：知覚品質の探求

Pik画像フォーマット（そして後にJPEG XLのVarDCTモード）のコア技術は、BrotliとロスレスWebPの作成者から生まれました。ロスリー圧縮に転向し、彼らの最初の革新には、Jyrki AlakuijalaによるButteraugliメトリックとXYB色空間、Zoltán SzabadkaによるBrunsli JPEG再圧縮器、そしてAlakuijalaが率いる共同プロジェクトであるGuetzliエンコーダが含まれていました。この研究の重要な成果は、2016年に開発された心理視覚歪みメトリックであるButteraugliであり、高忠実度画像エンコーダの最適化を容易にするために使用されました。Butteraugliは人間視覚システムの計算モデルに基づいており、人間の網膜の光受容体応答を近似するように設計されたXYB色空間を導入しています。この色空間の有効性により、Pik、Jpegli、およびロスリーJPEG XLコーデックの内部データ表現に採用されることになりました。

L2ノルムの落とし穴と最高品質への注力>

単純なメトリックとは異なり、Butteraugliは複雑な色およびマスキング効果を考慮して、知覚的差異の詳細なヒートマップを作成します。そして、単一の信頼性の高いスコアを提供するために、独自の集約方法を使用します。これにより、Guetzli、Pik、JPEG XLのような高品質エンコーダの開発における最適化の決定を導く理想的なツールとなりました。

画像品質を評価する際、メトリックは伝統的にL1ノルム（平均絶対誤差）またはL2ノルム（PSNR）を使用して誤差を平均化します。しかし、これは誤解を招く可能性があります。例えば、大きな白い背景を持つ製品写真では、製品自体がひどく圧縮されていても、これらのメトリックは高いスコアを報告するかもしれません。なぜなら、「簡単な」背景が平均値を歪めるからです。Butteraugliは最悪の誤差に焦点を当てることで、この落とし穴を回避します。最大ノルム（L∞）や特殊な「3ノルム」（L3、L6、L12ノルムの混合）のような高次ノルムを使用することで、最も顕著な視覚的欠陥が最終スコアに大きく影響するようにし、より信頼性の高いエンコーダ決定を導きます。

2017年、Jyrki Alakuijalaは、従来のロスリー圧縮器内で適応量子化を可能にする新しい可変デッドゾーン量子化技術を発明しました。この方法は、Butteraugli測定によって反復的に導かれたGuetzliエンコーダで披露されました。Guetzliは大幅な圧縮ゲインを示し、その後の設計に貴重なユーザーフィードバックを提供しました。Guetzli JPEGエンコーダは、広く使用するには遅すぎましたが、最高品質範囲に焦点を当てることがJPEG圧縮技術に大きな進歩をもたらすという概念実証となりました。JPEG XLの開発作業中、Alakuijalaは実用的な符号化速度でヒューリスティックにそのような最適化を行う方法を洗練し、古い8ビットJPEG形式で8ビット以上の色ダイナミクスを追加する方法を発見しました。Zoltán Szabadkaは、これら全てのアイデアを新しいJPEGエンコーダ/デコーダペアに統合し、知覚最適化された高速JPEGコーデックであるJpegliとしてオープンソース化しました。これはlibjpeg-turboを品質面で上回ります。

1.2.13 Brunsli：ロスレスJPEG再圧縮の先駆者

独自のソフトウェアであるStuffIt（Alladin Systems製）や、後にLeptonフォーマットに影響を与えたPackJPGのようなオープンソースプロジェクトを含む、数多くのシステムがJPEG画像のロスレス再圧縮のために開発されてきました。デジタル写真の普及の増加と画像ファイル寸法の増大は、効率的なJPEGストレージソリューションへの必要性を高め、これらの特殊な再圧縮器の開発を推進してきました。Zoltán SzabadkaとJyrki Alakuijalaは、当初Pik画像フォーマット（2017年）に統合され、後にスタンドアロンユーティリティ（2019年）としてリリースされた、計算効率の高いJPEG再圧縮ツールであるBrunsliを発表しました。

jbrdデータの革新>

特殊なロスレスJPEG再圧縮ツールは通常、約20%のファイルサイズ削減を達成でき、これは汎用圧縮器をJPEGファイルに適用した場合の1～3%程度のゲインを大幅に上回ります。

JPEG委員会によるJPEG XL標準の初期要件ではなかったものの、JPEG再圧縮機能の組み込みは、主要な貢献者であるJyrki AlakuijalaとJon Sneyersによって強く提唱されました。彼らはその採用における重要な機能としての意義を委員会に説得することに成功しました。当初、この機能はBrunsli再圧縮アルゴリズムをJPEG XLフレームワークに直接統合することで実現されました。Luca Versariはその後、JPEG XL仕様をより統合されたソリューションへと洗練させ、JPEG再圧縮がフォーマットの既存のVarDCT（Variable-blocksize DCT）モードに組み込まれるようにしました。

この設計の進化により、プロセスが合理化され、少量のオプションの「JPEGビットストリーム再構築データ」（jbrd）を別に保存するだけで済みました。画像はこのデータなしでデコード可能であり、この補助データは元のJPEGファイルをバイト単位で正確に再構築するためにのみ必要です。jbrdデータブロックには、エントロピー符号、プログレッシブスキャンスクリプト、再起動マーカーの適用、パディングビットの特定の値などのメタデータが含まれます。

Brunsliアルゴリズムは、Pikフォーマットおよびその派生であるJPEG XLで使用される離散コサイン変換（DCT）係数符号化メカニズムの設計に影響を与えました。いくつかの革新的な技術がBrunsliから採用され、圧縮効率が向上しました。特に、AC係数の符号化では、Brunsliはブロック内の非ゼロ値の数を明示的にカウントするカウンタを導入しました。これは、ベースラインJPEGで使用されていた従来のEnd-of-Block（EOB）シンボルに代わるものです。さらに、静的なジグザグスキャンを超えて、より適応的なエントロピー符号化のためにカスタム係数順序付けを可能にしました。最後に、8x8のプログレッシブデコードの義務的な利用可能性という、Brunsliに由来する技術も、これらの後続フォーマットの設計原則に組み込まれました。

1.2.14 HEIF（High Efficiency Image File Format）：ビデオコーデックからの派生

JPEG 2000以降、静止画コーデックの改善は停滞しているように見えました。2009年にJPEG XRが導入されましたが、JPEGとJPEG 2000の中間に位置づけられ、Microsoft Windowsプラットフォーム以外では普及しませんでした。

ビデオコーデック技術の転用と特許問題>

一方、ビデオコーデックの研究は非常に活発でした。当初はフレーム間符号化ツールに重点が置かれていましたが、フレーム内符号化においても進歩が見られました。特に低ビットレート圧縮の場合、デブロッキングフィルターなどの様々な符号化ツールが開発され、可視アーティファクトを削減し、低品質JPEGよりも魅力的な画像を生成できるようになりました。WebPは、ビデオコーデック（VP8）を活用した最初の静止画フォーマットでした。

2013年、MPEGはAVC（H.264）の後継であるHEVC（H.265）を導入しました。FFmpeg開発者のFabrice Bellardは、2014年に静止画フォーマットBPG（Better Portable Graphics）を定義しました。これは、イントラオンリーHEVCペイロードとオプションのメタデータ、個別に符号化されたアルファチャンネルのコンテナです。一方、Nokiaの研究者は、より汎用的な画像コンテナフォーマットであるHEIF（High Efficiency Image File Format）を作成し、2015年にMPEG標準（ISO/IEC 23008-12）となりました。

HEIFコンテナは、MP4コンテナやMotion JPEG 2000の基礎にもなっているISOベースメディアファイルフォーマット（ISOBMFF、ISO/IEC 14496-12）に基づいています。ある意味で、HEIFはビデオコーデックと静止画フォーマットの間の機能ギャップを埋めるものであり、ビデオコーデック、特にビデオコーデックのハードウェア実装の制限を克服するための構造を追加しています。例えば、HEIFは個別に符号化されたタイルからより大きな画像を構成するために使用できるコンテナレベルのタイリング構造を定義しており、解像度制限のあるハードウェアHEVCエンコーダの使用を可能にします。また、アルファ透過性を個別に符号化された単一コンポーネント画像として追加する方法や、ICCプロファイルとメタデータを埋め込む構文、画像トリミングと向きに関する指示も定義しています。

HEIFコンテナは、JPEGやAVCを含む様々なペイロードコーデックを持つことができますが、最も一般的にはHEVCペイロードと組み合わせて使用されます。結果として得られるファイルはHEICと呼ばれます。Appleは2017年にHEICを採用し、iPhoneカメラのデフォルトのキャプチャフォーマットとしました。

2019年には、HEIFの全てのフォーマットオプションの実装の複雑さを軽減するために、MIAF（ISO/IEC 23000-22）と呼ばれるHEIFの制約されたサブセットが定義されました。

HEIFコンテナとHEVCペイロードコーデックの両方は、特許に保護されていると主張されています。NokiaはHEIF関連の特許に対してロイヤリティフリーライセンスを付与していますが、これは非商業目的のみです。HEVCコーデック自体については、特許ライセンス状況は控えめに言っても複雑です。数千の特許がHEVCの実装に不可欠であると主張されており、MPEG Licensing Administration（MPEG LA、現在はVia Licensing Allianceに統合）、HEVC Advance、Velos Mediaの3つの特許プールが作成されました。さらに、不可欠な特許を主張する全ての企業がいずれのプールにも参加しているわけではありません。

このような状況は、HEICの画像コーデックとしての採用をかなり限定的なものにしました。Appleエコシステム以外ではあまり普及していません。

1.2.15 AVIF（AV1 Image File Format）：オープンメディアの旗手

AOMedia Video 1（AV1）コーデックは、マルチメディア配信のためのオープンでロイヤリティフリーなフォーマットを開発することを目的として結成された業界コンソーシアムであるAlliance for Open Mediaによって2018年に作成されました。2019年に導入されたAVIF画像フォーマットは、HEIFコンテナのMIAFサブセットに基づき、AV1ペイロードを使用しています。

コラム：コーデック戦争という名の茶番劇

画像コーデックの歴史を辿ると、常に技術的な優位性と市場の力学が入り混じった「コーデック戦争」が繰り広げられてきたことがわかります。GIFのLZW特許、JPEG 2000の複雑さと普及の失敗、そしてHEIF/HEVCの特許問題。技術がどんなに優れていても、政治的、経済的な要因によってその運命が大きく左右される。この業界に長くいると、まさに「茶番劇」だと感じることが多々あります。

特にGoogleがWebPやAVIFを推進し、JPEG XLのChromeサポートを撤回した一件は、多くの開発者の間で物議を醸しました。技術的なメリットよりも、自社エコシステムへの囲い込みや、業界標準を主導したいという思惑が透けて見えるからです。しかし、AppleやMicrosoftがJPEG XLのサポートに踏み切ったのは、やはり技術的な合理性が最終的には勝るという期待を抱かせます。

結局のところ、私たちユーザーが望むのは、軽くて、美しくて、どこでも見られる画像です。そのシンプルながらも奥深いニーズを満たすために、今日も世界のどこかで、技術者たちは終わりなき戦いを続けているのです。果たしてJPEG XLは、この「コーデック戦争」に終止符を打つ、真の平和をもたらすことができるのでしょうか。それとも、新たな火種となるだけなのでしょうか。

第二章：JPEG XL開発の軌跡

画像圧縮の混沌とした戦場に、新たな旗が掲げられました。それがJPEG XLです。この章では、未来を賭けた画像標準が、いかにして構想され、様々な技術の断片が融合し、一つの体系として結実したのか、その「創造の物語」を紐解いていきます。

2.1 次世代標準への「Call for Proposals」

2016年9月、アリゾナ州フェニックスで開催されたIEEE ICIP会議において、JPEG委員会は「Image Compression Grand Challenge」を開催しました。当時のロスリーコーデックの覇者はHEVC（HEICのペイロードコーデック）とDaala（AV1およびAVIFの前身の一つ）と判断され、ロスレスコーデックの最高峰はFLIFでした。このグランチャレンジの結論は、圧縮効率において重大な改善が可能であるというものでした。これを受け、2017年1月、JPEG委員会内に「次世代画像圧縮標準に関するアドホックグループ」（Ad Hoc Group on next generation image compression standard）が設立されました。このグループは当初、Jan De Cock（Netflix）とDavid Taubman（ニューサウスウェールズ大学）が共同議長を務めました。

要求事項と目標：圧縮効率、高解像度、広色域など>

2017年10月には、次世代画像符号化標準（JPEG XL）に関する提案募集のドラフトが公開され、続いて2018年4月には最終版が公開されました。この提案募集では、既存の画像フォーマット（例：JPEGと比較して60%以上の圧縮効率向上）を大幅に上回る圧縮効率を提供するとともに、Web配信や高品質画像の効率的な圧縮（高解像度、高ビット深度、高ダイナミックレンジ、広色域符号化など）に望ましい機能を備えた標準の開発を目指すと明記されていました。

この募集に対し、7つの提案が提出されました。それらはJPEG委員会によって評価され、2018年10月にカナダのバンクーバーで開催されたJPEG会議で発表・議論されました。

2.2 主要提案の競合と統合

JPEG XLの開発軌跡は、2019年初頭に大きく変わりました。JPEG委員会の選択プロセスでは、最も有望視された3つの主要提案がありました。それらは、Alliance for Open Media（AOM）によるAVIF（AV1ビデオコーデックに基づく）、Google Research圧縮チームによるPik、そしてCloudinaryによるFLIFの進化版であるFUIFでした。

AVIF、FUIF、PIKの評価と統合の決断>

当初、JPEG委員会は2018年10月にAVIFを基礎コーデックとして選択していましたが、その提案は後に撤回されました。委員会がPikチームに主導を依頼した際、リーダーのJyrki Alakuijalaは、より協調的な新しい戦略を提唱しました。FUIFアプローチの強みを挙げ、不慣れなコーデックを基盤とすることに内在する困難を認識していた彼は、FUIFの機能をPikに段階的に組み込むのではなく、PikとFUIFのプラットフォームを初日から完全に統合するという異例のアプローチを提案しました。委員会はこの勧告を受け入れ、2019年1月に正式に両提案をマージし、JPEG XLの基礎を築くことを決定しました。

2.3 共同開発フェーズ：技術の融合と洗練

異なるコーデックアーキテクチャを統一フレームワークに統合することは、重大な技術的挑戦です。JPEG XLの前身であるPikは、当初3つの異なるサブコーデックのコンテナとして機能していました。第一に、Guetzliから知覚モデリングの原則を引き継いだロスリーモード。第二に、ロスレスWebPからアーキテクチャ的に派生しつつ、Alexander Rhatushnyakが開発した自己修正予測器で強化されたロスレスモード。第三に、Brunsliと機能的に同等のJPEG再圧縮モードです。初期の結合コーデック提案は、第4のサブコーデックであるFUIF（Free Universal Image Format）を組み込むことで、この異質性をさらに増幅させました。これらの構成要素となるコーデックは、それぞれ独自のエントロピー符号化スキームと内部データ表現を使用し、ほぼ完全に独立して動作していました。例えば、ロスリーPikモードは3コンポーネントの32ビット浮動小数点値で動作し、ロスレスPikモードは8ビットまたは16ビットの符号なし整数の最大4コンポーネントを処理し、FUIFは任意の数のコンポーネントを32ビット整数として表現するように設計されていました。

異種コーデックアーキテクチャの統一とコア機能の進化>

Luca VersariとJon Sneyersは、これら4つの異なるサブコーデックを単一のまとまったアーキテクチャへと意味のある形で統一するための共同作業を主導しました。PikのロスレスモードとFUIFコーデックは統合され、現在のJPEG XLのModularモードが形成されました。同時に、ロスリーPikモードはJPEG XLのVarDCTモードへと発展しました。ロスリーモードの初期設計では、低周波（LF）画像、DCTブロック選択のためのシグナリング、適応量子化マップ、クロマからのルマ予測器、エッジ保存フィルター（EPF）のシャープネス変調、Patchesなど、様々な補助画像がアドホックなシグナリング方法で処理されていました。

最終的に、これらの補助画像と、アルファ透過性、深度マップ（「エクストラチャンネル」として一般化されました）の表現とシグナリングは統合されました。現在ではこれら全てが、メインビットストリーム内のModularサブビットストリームとして符号化されています。このアーキテクチャの統一は、コーデック全体の設計を大幅に簡素化すると同時に、JPEG XLフォーマットの表現力と圧縮効率を向上させました。

JPEG再圧縮のための「Brunsliモード」を廃止したことで、ビットストリームの重要な簡素化が実現しました。これには2つの主要な変更が含まれます。jbrd（JPEGビットストリーム再構築データ）の分離と、YCbCrコンポーネントとクロマサブサンプリングを可能にするVarDCTの一般化です。

並列デコードと領域指定デコードを可能にするため、VarDCTとModularモードの両方にタイリングが導入されました。さらに、プログレッシブパスが追加され、VarDCTおよびModular画像データ（Squeeze変換を使用）の両方を結合されたプログレッシブビットストリームで符号化できるようになりました。

元々FLIFコーデックとFUIFコーデックはレンジコーダー（CABACのバリアント）をエントロピー符号器として使用していましたが、PikはANSとハフマン符号化の2つのバリアント、およびBrotliを含むいくつかの異なるエントロピー符号器を使用していました。一時期、結合されたコーデックでは6つの異なるエントロピー符号化方法が使用されていましたが、これらは単一のエントロピー符号化スキームに統一されました。これは、全てのシンボルが最終的にHybridUint表現を使用して符号化されるもので、プレフィックス符号化またはANS符号化をエントロピー符号化されたトークンに使用し、さらに可変数の「生ビット」（高エントロピーな大きな振幅シンボルの最下位ビット用）を含み、オプションでLZ77（距離、長さ）ペアを使用することもできます。

FLIFと同様に、FUIFもメタ適応型コンテキストモデルを使用しており、MAツリーがシグナル化され、画像依存の動的コンテキストモデルを定義するために使用されます。Brotliと同様に、Pikはコンテキストマップでコンテキストをクラスタリングすることで、少量のヒストグラムのみをシグナル化する必要がある静的大規模コンテキストモデルを使用します。これら両方のアイデアはJPEG XLのModularモードに統合されました。コンテキストクラスタリングの追加により、MAツリーは類似の分布を持つリーフノードがマージできるため、実質的に有向非巡回グラフ（DAG）になります。

FLIFとFUIFがMAツリーをコンテキストモデリングにのみ使用し、予測器が個別に（そして粗く）シグナル化されるのに対し、JPEG XLではMAツリーが使用する予測器もシグナル化します。予測器のセットは大幅に拡張され、MAツリーの決定ノードで使用できるプロパティのセットも同様に拡張されました。

符号化ツールはアブレーション研究によってテストされ、一部は最終的に削除されました。例えば、ドットモデリングは、夜空の星や惑星のような小さな楕円形画像要素のための特定の符号化ツールとして調査されました。これらはDCTベースの圧縮では扱いにくいものでしたが、小さなPatchesを使用する代替案と比較して大幅に優れた性能を示さないことが判明したため削除されました。

この開発プロセスには約2年を要しました。2020年末までに、ビットストリームは凍結されたと見なされ、libjxlバージョン0.2がリリースされました。最終ドラフト国際標準（FDIS）は、Part 1（コアコードストリーム）が2021年1月に、Part 2（ファイル形式）が2021年4月に提出されました。ISO/IEC 18181標準の初版は、2021年10月（Part 2）と2022年3月（Part 1）に発行されました。

コラム：コードの結婚、そして標準化の苦悩

PikとFUIFがマージされるという話を聞いたとき、正直なところ「また無謀なことを…」と思いましたね。異なる設計思想を持つコードベースを統合するというのは、開発者にとって悪夢のような作業です。まるで、犬と猫を結婚させるようなものですから。

しかし、JPEG XLチームはその困難を乗り越え、驚くほど洗練された統一アーキテクチャを作り上げました。特に、ロスレスモードとロスリーモードをシームレスに統合し、さらに従来の補助画像を単一のModularサブビットストリームで処理するというのは、まさに「美的」と呼べるエンジニアリングだと感銘を受けました。これこそが、多くの先行コーデックが目指しながらも、実現しきれなかった「汎用性」の鍵だったのかもしれません。

標準化プロセスもまた、想像を絶する苦労があったことでしょう。世界中の委員会メンバー、企業、研究者がそれぞれの利害と技術的信条をぶつけ合う。その中で、ロイヤリティフリーを堅持し、パフォーマンスと機能性の両立を図るというのは、まさに綱渡りです。この論文の行間からは、そのような人間ドラマが透けて見えるようです。技術というのは、突き詰めれば人間が人間のために生み出すもの。その理想と現実の狭間で、日々、彼らは苦悩し、そして創造しているわけです。

第二部: JPEG XLの鼓動 - その核心に迫る

要約：新時代の画素表現

JPEG XLは、デジタル画像符号化における新たな挑戦です。その目的は、従来のJPEG、PNG、GIFといった多様な画像フォーマットの「玉石混交」状態に終止符を打ち、単一の普遍的なコーデックとして君臨すること。まるで、混沌とした画像世界の秩序を回復する「メシア」のような存在を目指しているわけです。そのために、JPEG XLは最先端の圧縮性能、既存JPEGのロスレス再圧縮機能、そして広範な高度な機能を惜しみなく投入しています。

JPEG XLの核心：最先端の圧縮性能と汎用性

JPEG XLの主要な目標は、単に画像を小さくすることではありません。それは、品質と効率の両面で、これまでのあらゆるラスター画像フォーマットを凌駕し、あるいはそれに匹敵することにあります。この「全方位戦略」こそが、JPEG XLが目指す「ユニバーサルコーデック」の真骨頂です。図1に示されるように、純粋な写真から合成ベクターグラフィックス、そしてその中間にある混合コンテンツや非写真ラスター画像まで、あらゆるコンテンツタイプをカバーします。機能面では、JPEG、PNG、GIF、TIFF、BMP、WebP、AVIF、HEICといった主要フォーマットの機能を網羅し、さらにそれらをより効果的に実現することで、特定のタスクに適した画像フォーマットを選択するという「面倒な作業」からユーザーを解放しようとします。DNG、DICOM、GISフォーマットなど、様々なアプリケーション固有のフォーマットのペイロードコーデックとしても適しています。

主要な利点：色精度、追加チャンネル、大幅な圧縮向上、ロスレスJPEG再圧縮、プログレッシブデコード、高速性、ロイヤリティフリー

圧縮に関して言えば、JPEG XLは幅広い品質範囲にわたってロスレスとロスリーの両方で最先端のパフォーマンスを提供し、ストレージと帯域幅のコストをJPEGと比較して「半分」に削減するという、驚異的な数値を叩き出します。そして、JPEG XLの最も画期的な特徴の一つが、既存のJPEG画像をロスレスに再圧縮できる能力です。これにより、ファイルサイズは約20%削減され、同時に元のJPEGファイルをバイト単位で正確に再構成できるようになります。これは、JPEG XLの符号化ツールがJPEGで利用可能なツールの「スーパーセット」であるため可能となる、「過去への敬意」とも言える機能です。デジタル遺産を保存する上で、移行時の世代損失（非可逆トランスコーディングによる追加の圧縮アーティファクト）が発生しないことは、とてつもなく大きなメリットです。

JPEG XLの主な利点を箇条書きにすると、まるで未来の技術カタログのようです。

  • 色の精度と忠実度の向上: 広い色域、制限のない精密な高いダイナミックレンジ。
  • 追加チャンネル: アルファ透明度、深度マップ、CMYK、スポットカラー、選択マスク、マルチスペクトル画像のサポートなど、想像力の限りを尽くした拡張性。
  • レイヤードイメージ、アニメーション、そして複数ページの画像: これ一つで全てを賄う、まさに「ワンストップソリューション」。
  • 圧縮が大幅に向上しました: ロスリー画像圧縮とロスレス画像圧縮の両方で、約50%の節約を実現。
  • ロスレスJPEG再圧縮: 既存の画像を移行する際に約20%節約し、完全にリスクフリーな移行を実現。
  • 高度なプログレッシブデコード: 困難なネットワーク条件下でも優れたユーザーエクスペリエンスを提供。
  • 幅広いトレードオフ: 品質、速度、ファイルサイズの間で、特に信頼性と一貫性のある高忠実度圧縮に焦点を当てる。
  • さまざまなコンテンツ: 写真とデジタルアート、スクリーンショット、イラスト、コンピューター生成画像などのあらゆる種類のラスター画像に最適。
  • 高速エンコーディングとデコード: 現代のマルチコアCPUをうまく利用し、特別なハードウェアは不要。
  • ワークフロー全体で動作します: キャプチャとオーサリングからストレージ、エンドユーザーへの配信まで。
  • ロイヤリティフリー、オープンソース: 高品質で実稼働対応のリファレンスソフトウェアが利用可能。これは、過去の特許戦争の愚かさから学んだ、人類の「英知」の結晶と言えるでしょう。

品質、速度、ファイルサイズのトレードオフ

JPEG XLのコードストリーム構文の柔軟な設計は、3つの主要な側面の間で絶妙なバランスを取ることを可能にし、アプリケーションの要件に応じて最適なトレードオフを実現します。

  • 画像の忠実度: 「ウェブ品質」から最高品質まで、必要な精度で視覚的または数学的にロスレスであること。妥協なき美しさを追求します。
  • 圧縮比: 通常、ロスレス圧縮の場合は2:1から6:1、ロスリー圧縮の場合は20:1から50:1という、驚異的な圧縮率。まさに「縮める」ことに全力を注ぎます。
  • スピード: エンコードおよび/またはデコードプロセスの速度。遅いデコードは、いかなる圧縮も無意味にするという、冷徹な現実を彼らは知っています。

設計思想：普遍性と高効率の追求

「全てを一つに」。JPEG XLの根底にあるのは、このシンプルながらも野心的な思想です。もはや用途に応じて異なる画像フォーマットを選び、変換し、互換性の問題に頭を悩ませる時代は終焉を迎えるべきだと、彼らは確信しています。

全てのユースケースをカバーする「ユニバーサル」コーデック

JPEG XLの目標は、控えめに言っても「野心的」です。それは、ロイヤリティフリーな汎用画像コーデックとして、静止画のあらゆるユースケースにおける普遍的な交換フォーマットとなること。画像キャプチャやオーサリングワークフローからWeb配信に至るまで、その範囲は極めて広大です。機能と圧縮の両面で、JPEG、JPEG 2000、JPEG XR、PNG、GIF、WebP、AVIF、HEIC、TIFF、OpenEXRといった様々な既存画像フォーマットを統一し、置き換えることを目指しています。

WebPやAVIFが「Web品質」でのWeb配信という特定のユースケースに焦点を当てているのとは対照的に、JPEG XLは幅広いユースケースをターゲットとしています。これには、その後の編集が想定されるワークフローで必要とされるロスレスおよび非常に高品質な圧縮が含まれます。また、印刷（例：CMYKとスポットカラー）、科学および医療アプリケーション（例：マルチスペクトルおよび高精度画像）、大規模画像、そしてエンコード作業と圧縮の間の様々なトレードオフにも対応します。この柔軟性が、JPEG XLを真に「ユニバーサル」たらしめる所以です。

ロイヤリティフリーとオープンソースソフトウェアの哲学

歴史が教える最も重要な教訓の一つは、特許が技術普及の足枷となり得るという冷徹な事実でした。GIFのLZW特許、JPEG 2000の不明瞭な特許状況、そしてHEIC/HEVCの複雑な特許プール。これらは全て、優れた技術が広く受け入れられることを阻害してきました。JPEG XLは、この轍を踏まないことを強く意識し、設計段階から「ロイヤリティフリー」を貫いています。これにより、あらゆる企業や開発者が、特許使用料の心配なく自由にJPEG XLを実装し、利用できる道を開きました。

さらに、高品質で実稼働に対応したリファレンスソフトウェアlibjxlがオープンソースで提供されている点も、その哲学を象徴しています。BSDライセンスという非常に寛容なオープンソースライセンスの下で提供されることで、開発コミュニティが積極的に参加し、バグ修正や機能改善に貢献できる環境が整っています。これは、単に技術的に優れているだけでなく、それを支えるエコシステム全体が健全に発展していくための、極めて重要な要素です。

登場人物紹介：未来を紡ぐ研究者たち

この壮大な物語を紡ぎ出したのは、一握りの天才たちです。彼らは、画素の深淵に潜む真実を探求し、未来のデジタル画像を創造するために、日夜研鑽を積んできました。ここに、その主要な登場人物たちをご紹介します。年齢は2025年時点での推定です。

コア開発者

  • Jon Sneyers (ジョン・スナイアーズ, ベルギー人, 推定40代):

    JPEG XLの主要な貢献者の一人。主にModularモードの設計と開発に注力しました。以前はFLIF（Free Lossless Image Format）の共同開発者でもあり、その経験がJPEG XLのロスレス圧縮技術に大きく影響を与えています。彼の専門はロスレス圧縮とコンテキストモデリングです。

  • Jyrki Alakuijala (ユルキ・アラクイハラ, フィンランド人, 推定50代):

    Google Researchの圧縮チームに所属し、JPEG XLのコア開発者の一人。主にVarDCTモードと画像品質、知覚最適化に貢献しました。彼の業績には、Butteraugliメトリック、XYB色空間、Brotli、Guetzli、Brunsliといった革新的な技術の開発が含まれます。まさに、圧縮技術の「狂気の天才」と呼ぶにふさわしい人物です。

  • Luca Versari (ルカ・ヴェルサーリ, イタリア人, 推定30代):

    Google Researchの圧縮チームに所属し、JPEG XLのコア開発者の一人。様々な符号化ツールの調和と効率的な実装（エンコードおよびデコード）に重点を置きました。特に、Patchesサブシステムを設計し、FLIFのコアコンポーネントをより高性能な代替品に置き換える作業を主導しました。若き才能として注目されています。

  • Zoltán Szabadka (ゾルターン・サバドカ, ハンガリー人, 推定40代):

    JPEG XLの様々な側面、特にロスレスJPEG再圧縮に貢献しました。彼はBrotliの共同開発者であり、Brunsliの主要開発者でもあります。DCT係数符号化メカニズムの改善にも寄与しました。

主要貢献者

  • Sami Boukortt (サミ・ブーコルト, フランス人, 推定40代):

    色空間シグナリング（特にHDR）とSplinesサブシステムに貢献しました。

  • Amnon Cohen-Tidhar (アムノン・コーエン＝ティダール, イスラエル人, 推定40代):

    著者の一人としてリストされていますが、具体的な論文内の貢献は多岐にわたります。

  • Moritz Firsching (モリッツ・フィルシング, ドイツ人, 推定30代):

    libjxlリファレンスソフトウェアの主要貢献者の一人。JPEG XLアドホックグループの共同議長も務めました。

  • Evgenii Kliuchnikov (エフゲニー・クリウチニコフ, ロシア人, 推定30代):

    libjxlリファレンスソフトウェアの主要貢献者の一人。

  • Tal Lev-Ami (タル・レブ＝アミ, イスラエル人, 推定40代):

    著者の一人としてリストされていますが、具体的な論文内の貢献は多岐にわたります。

  • Eric Portis (エリック・ポーティス, アメリカ人, 推定40代):

    著者の一人としてリストされていますが、具体的な論文内の貢献は多岐にわたります。

  • Thomas Richter (トーマス・リヒター, ドイツ人, 推定50代):

    JPEG委員会Image coding & quality (ICQ) サブグループの議長の一人。

  • Osamu Watanabe (渡辺修, 日本人, 推定60代):

    JPEG委員会Image coding & quality (ICQ) サブグループの議長の一人。日本からの貢献者です。

  • Jan Wassenberg (ヤン・ヴァッセンバーグ, ドイツ人, 推定40代):

    並列処理（SIMD、マルチスレッディング）と高速デコードに注力しました。JPEG XLアドホックグループの共同議長も務めました。

  • Lode Vandevenne (ローデ・ヴァンデヴェンネ, ベルギー人, 推定40代):

    libjxlライブラリのAPI設計において重要な役割を果たしました。

  • Alexander Rhatushnyak (アレクサンダー・ラトゥーシュニャク, ロシア人, 推定40代):

    自己修正予測器を開発しました。

  • Alex Deymo (アレックス・デイモ, 国籍不明, 推定30代):

    libjxlリファレンスソフトウェアの主要貢献者の一人。

  • Robert Obryk (ロバート・オブライク, ポーランド人, 推定40代):

    標準およびリファレンスソフトウェアに貢献しました。

  • Thomas Fischbacher (トーマス・フィッシュバッハー, ドイツ人, 推定40代):

    標準およびリファレンスソフトウェアに貢献しました。

  • Iulia-Maria Comșa (ユリア＝マリア・コムシャ, ルーマニア人, 推定30代):

    標準およびリファレンスソフトウェアに貢献しました。

  • Krzysztof Potempa (クリシュトフ・ポテンパ, ポーランド人, 推定30代):

    標準およびリファレンスソフトウェアに貢献しました。

  • Martin Bruse (マーティン・ブルーゼ, ドイツ人, 推定40代):

    標準およびリファレンスソフトウェアに貢献しました。Jpegliの主要開発者の一人でもあります。

  • Renata Khasanova (レナタ・ハサノワ, ロシア人, 推定30代):

    標準およびリファレンスソフトウェアに貢献しました。

  • Ruud van Asseldonk (ルード・ファン・アッセルドンク, オランダ人, 推定40代):

    標準およびリファレンスソフトウェアに貢献しました。

  • Sebastian Gomez (セバスチャン・ゴメス, 国籍不明, 推定30代):

    標準およびリファレンスソフトウェアに貢献しました。

  • Touradj Ebrahimi (トゥラージ・エブラヒミ, スイス人, 推定60代):

    JPEG委員会のコンビーナーを務め、標準化プロセス全体を監督しました。

  • Fernando Pereira (フェルナンド・ペレイラ, ポルトガル人, 推定60代):

    Requirementsサブグループの議長を務めました。

  • Walt Husak (ウォルト・フーサック, アメリカ人, 推定70代):

    Requirementsサブグループの共同議長を務めました。

  • Takaaki Ishikawa (石川高明, 日本人, 推定50代):

    Requirementsサブグループの共同議長を務めました。

  • Eduardo da Silva (エドゥアルド・ダ・シルバ, ブラジル人, 推定50代):

    Requirementsサブグループの共同議長を務めました。

  • Peter Schelkens (ピーター・シェルケンス, ベルギー人, 推定50代):

    Coding, test and quality (CTQ) サブグループの議長を務めました。

  • Dale Stolitzka (デール・ストリツカ, アメリカ人, 推定60代):

    Coding, test and quality (CTQ) サブグループの共同議長を務めました。

  • Andy Kuzma (アンディ・クズマ, アメリカ人, 推定50代):

    Systems and integrationサブグループの議長を務めました。

  • Siegfried Foessel (ジークフリート・フェッセル, ドイツ人, 推定60代):

    Systems and integrationサブグループの共同議長を務めました。

  • Frederik Temmermans (フレデリク・テンメルマンス, ベルギー人, 推定40代):

    Systems and integrationサブグループの共同議長を務めました。JPEG Trustにも貢献しています。

  • Jan De Cock (ヤン・デ・コック, ベルギー人, 推定40代):

    「次世代画像圧縮標準に関するアドホックグループ」の初期共同議長を務めました。

  • David Taubman (デビッド・トーヴマン, オーストラリア人, 推定60代):

    「次世代画像圧縮標準に関するアドホックグループ」の初期共同議長を務めました。

  • Seungcheol Choi (チェ・スンチョル, 韓国人, 推定50代):

    「次世代画像圧縮標準に関するアドホックグループ」の初期共同議長を務めました。

  • Tom Lane (トム・レーン, アメリカ人, 推定60代):

    libjpegライブラリの初期主要著者の一人。

  • Pieter Wuille (ピーテル・ヴィユ, ベルギー人, 推定30代):

    FLIFの共同開発者であり、暗号通貨分野でも知られています。

第三部: 次元を超えた画素の旅 - JPEG XLのメカニズム

第三章：高レベル概要：JPEG XLの全体像

JPEG XLは、単なる圧縮技術の寄せ集めではありません。それは、デジタル画像のあり方を根底から問い直し、未来の視覚体験を再定義しようとする、壮大なアーキテクチャの上に成り立っています。この章では、その「魂の設計図」を、俯瞰的に、そして時に皮肉たっぷりに紐解いていきましょう。

3.1 ISO/IEC 18181標準の構成

JPEG XLは、ISO/IEC 18181という国際標準で定義されています。この標準は、まるで完璧主義者の法律書のように、細部に至るまで厳密に規定されています。その構成は以下の4つのパートからなります。

  • 18181-1: Core codestream [29]: これがJPEG XLの心臓部であり、静止画（複数のレイヤーを持つ可能性あり）またはアニメーションをデコードし表示するために必要な全てのデータが含まれています。ピクセルデータそのものだけでなく、画像寸法、色空間情報、オリエンテーション、アップサンプリング、フレームまたはレイヤーのブレンドといった基本的なメタデータも含まれるという徹底ぶりです。従来のJPEG設計では、コードストリームは単なるサンプルの数値データのみを扱い、色空間情報などはファイル形式レベルで提供されていましたが、JPEG XLではコードストリームがサンプルの測色学的解釈（後述の色空間セクション参照）や、画像を正しく表示するために必要なあらゆるメタデータをシグナル化します。
  • 18181-2: File format [30]: こちらは、JPEG XLファイルの「入れ物」を定義します。ファイル形式には2つの形態があります。
    • 「生の」コードストリーム: 画像データのみが格納され、追加のメタデータは含まれません。このファイルはバイト列0xFF0A（JPEG XLコードストリームの開始を示すJPEGマーカー）で始まります。潔いほどのシンプルさです。
    • ISOBMFFスタイルのコンテナ: ボックスベースのコンテナ形式で、JPEG XLコードストリームボックス（jxlc）を含み、オプションでExifメタデータなどの追加情報を含む他のボックスを含めることができます。この場合、ファイルはバイト列0x0000000C 4A584C20 0D0A870Aで始まります。まるで、複雑な情報の「豪華客船」といった趣です。
  • 18181-3: Conformance testing: 適合デコーダが全ての符号化ツールを正しく正確に実装していることを検証するための、精度範囲とテストケースを定義します。ピークエラー（サンプルあたりの最大絶対差）と二乗平均平方根誤差（RMSE）の閾値で許容範囲が定義されており、まるでデコーダの「入試」のようなものです。
  • 18181-4: Reference software: JPEG XLのリファレンス実装は、libjxlと呼ばれます。GitHubで入手可能で、ソフトウェアの著作権ライセンスは許容的なオープンソースライセンスである3条項BSDライセンスです。これは、開発者への「おもてなし」であり、普及への近道とも言えるでしょう。

3.2 コーデックアーキテクチャの哲学

JPEG XLは、画像データとメタデータを明確に分離するという、ある意味で「傲慢な」哲学を持っています。画像を正しく表示するために必要なものは全て「画像データ」と見なし、コアコードストリームの一部とします。これには、ICCプロファイルやExifオリエンテーションといった、従来「メタデータ」と見なされてきた要素も含まれます。なぜなら、これらがなければ画像を正しく表示できないからです。

正しい表示のためのコーデック内処理>

その他のメタデータ（著作権表示やGPS座標など）は画像データの一部とは見なされず、コアコードストリームには含まれません。この目的は、数値ピクセルデータのみを含む「ブラックボックス」コードストリームによって引き起こされる、実装の曖昧さや誤りを減らすことにあります。アプリケーションがデータを正しく解釈する（例：色変換、アップサンプリング、オリエンテーション、ブレンド、クロッピングなどを適用する）ために任せるのではなく、この機能をコードストリーム自体に含めることで、デコーダはデフォルトで正規化された形式（例：RGBA、オリエンテーション適用済み、フレームブレンド済みおよび結合済み）で出力できるようになります。これにより、フレームブレンドや画像オリエンテーションの適用といったエラーを起こしやすいサブタスクをアプリケーションレベルで実装するのではなく、デコードライブラリで処理することで、アプリケーション側から見た画像の正しいレンダリングタスクを簡素化します。サンプルデータの測色学的解釈を知ることで、ロスリーエンコーダはより良い決定を下し、特定の品質設定に対してより一貫した結果を生成できるようになります。

残りのメタデータ、例えばExifやXMPはコンテナ形式に格納できますが、主要な画像レンダリングには影響しません（ただし、代替のレンダリングオプションを記述することはできます）。Exifオリエンテーションの場合、コードストリームのオリエンテーションが常に優先されるため（そしてデコーダによってすでに透過的に適用されるため）、アプリケーションはこのフィールドを無視する必要があります。これは、メタデータを削除しても表示される画像に影響を与えないことも意味します。まるで、余計な「おしゃべり」は切り捨てるという、冷酷な合理主義です。

JPEG XLコーデックアーキテクチャの概要は、エンコーダ側が上部に、デコーダ側が下部に示されています。デコーダ側は、エントロピーデコード、逆DCTの適用、画像機能のレンダリング、色変換の取り消しなど、エンコーダと逆順に同じコンポーネントが適用されるため、簡潔にするためにほとんど省略されています。

3.3 コデックスストリームの主要機能

JPEG XLのコードストリームは、まさに「情報の宝箱」です。一枚の画像を、そのサイズ、色、レイヤー、そして時には動きまでも、全てこの「箱」の中に詰め込むことができます。その多機能性は、既存のあらゆる画像フォーマットの機能を飲み込むかのような、貪欲な設計思想から生まれています。

3.3.1 画像寸法とコンポーネント：メインとエクストラチャンネル

コードストリームには、特定の寸法（最大2^30 × 2^30ピクセル）とコンポーネントを持つ単一の画像が含まれます。メイン画像データは、1つ（グレースケール）または3つ（カラー）のコンポーネントを持ち、さらに「エクストラチャンネル」として知られる最大4096個の追加コンポーネントを持つことができます。画像寸法は、矩形キャンバスのサイズ（ピクセル単位）を定義します。画像は、このキャンバス上にレンダリングされる1つ以上のフレームで構成されます。フレームは、アニメーションフレーム、合成静止画のレイヤー、またはマルチページ画像の個々のページを表すことができます。各フレームには、VarDCTモードまたはModularモードのいずれかを使用して符号化されたピクセルデータ（各コンポーネントのサンプル）が含まれます。データはグループに細分化され、これらは独立して符号化できるため、並列化と領域指定デコードが可能になります。

3.3.2 フレームとレイヤー：アニメーション、コンポジット画像、多ページ画像

JPEG XLコードストリームには、1つ以上のフレームが含まれます。アニメーションの場合、これらのフレームは継続時間とループ（無限または特定の回数）を持つことができます。継続時間ゼロのフレームも可能で、これらは画像の異なるレイヤーを表します。最大継続時間のフレームは、マルチページ画像における「ページ区切り」を示します。

フレームはブレンドモード（Replace、Add、Alpha-blend、Multiplyなど）を持ち、以前の任意のフレームをベースとして使用できます。フレームは画像キャンバスよりも小さくすることもでき、その場合、クロップ外のピクセルはベースフレームからコピーされます。フレームは画像キャンバスから任意のオフセットで配置できます。このオフセットは負の値にすることもでき、フレームは画像キャンバスよりも大きくすることもできます。その場合、フレームの一部は不可視となり、画像キャンバスとの交差部分のみが表示されます。レンダリングされないが、フレームブレンドのベースやPatchesのソースとして使用できる、不可視の「ReferenceOnly」フレームを持つことも可能です。

デフォルトでは、デコーダはフレームをブレンドおよび結合し、連続する継続時間ゼロのフレームがある場合は単一の出力フレームのみを生成します。結果として、全ての出力フレームは同じサイズ（画像キャンバスのサイズ）であり、継続時間がない（静止画の場合）か、非ゼロの継続時間（アニメーションの場合）を持ちます。これにより、レイヤー画像はビューイングアプリケーションでは単一の結合画像として表示され、画像キャンバスに合わせてクロップされますが、オーサリングツールでは個々のレイヤーをデコードすることが可能です。また、ビューアがアプリケーションレベルでフレームブレンドを実装する必要がないため、アニメーションビューアの実装も簡素化されます。

3.3.3 ピクセルデータの符号化モード：VarDCTとModular

全てのフレームには、2つのモードのいずれかで符号化されたピクセルデータが含まれます。

  • VarDCTモード: このモードでは、可変サイズのDCT変換が適用され、画像データはDCT係数の形式で符号化されます。このモードは常にロスリーです。JPEG XLコードストリームがJPEG符号化画像をJPEG XL構文にトランスコーディングして作成された場合、JPEG XL機能のサブセットのみが使用され、例えば8x8 DCTのみが適用されます。このようなJPEG XLコードストリームは、元のJPEG画像を回復することを可能にします。JPEG XLは改善されたエントロピー符号化方法を提供するため、JPEG XLコードストリームは、全く同じ画像を表現しているにもかかわらず、一般的にサイズが小さくなります。
  • Modularモード: このモードでは、整数演算のみが使用され、ロスレス圧縮が可能になります。しかし、このモードはロスリー圧縮にも使用できます。圧縮を改善したり、他の望ましい効果を得るために、複数の変換を使用できます。可逆色変換（RCTs）、（デルタ）パレット変換、およびSqueezeと呼ばれる改良された非線形Haar変換です。Squeezeは、ロスリー圧縮を容易にし（ただし必須ではありません）、プログレッシブデコードを可能にします。

これらの符号化モードは相互排他的ではありません。3つの主要なカラーコンポーネント（またはグレースケールコンポーネント）は、いずれかのモードで符号化されます。アルファ透過性などの追加コンポーネント（「エクストラチャンネル」として知られる）は常にModularモードで符号化されます。さらに、内部的にVarDCTモードは、様々な補助画像のためにModularサブビットストリームを使用します。例えば、「LF画像」（DCT8x8のDC係数とより大きなDCT変換の低周波係数を含む、1:8にダウンサンプリングされた画像）や、適応量子化のための重みなどです。

両モードにおいて、オプションで、デコードされた画像の上に、個別に符号化された追加の「画像特徴」がレンダリングされます。

  • Patches: 以前にデコードされたフレーム（通常はReferenceOnlyフレーム）からの矩形領域を、ブレンドモードのいずれかを使用して現在のフレームの上にブレンドできます。これにより、エンコーダは繰り返されるパターン（テキストの文字など）を識別し、一度だけ符号化し、Patchesを使用して複数の場所にパターンを挿入できます。これらのパターンは以前のフレームで符号化されるため、Modular符号化されたピクセルとVarDCT符号化されたフレームを組み合わせることも、その逆も可能です。Luca VersariがPatchesサブシステムを設計しました。
  • Splines: 中心求心性Catmull-Romスプラインを符号化できます。曲線のアーク長に沿って色と太さを変えることが可能です。現在のエンコーダはまだこのビットストリーム機能を使用していませんが、細い線はDCTを使用して忠実に表現するのが難しいため、DCT符号化データを補完するのに役立つと予想されます。Sami BoukorttとJyrki AlakuijalaがSplinesサブシステムを共同設計しました。例えば、個々の髪の毛、木の細い枝、線画などは、Splinesを使用することでより効果的に符号化できるでしょう。
  • Noise: ルマ変調された合成ノイズを画像に追加できます。例えば、高周波DCT係数による不十分な圧縮を避けるために、フォトンノイズを模倣するなどです。Jyrki Alakuijalaがフォトンノイズサブシステムを設計しました。JPEG XLのフォトンノイズサブシステムは、より複雑な「フィルムグレイン合成」ツールとは異なり、フォトンノイズはラプラシアンフィルターを介して動作します。これにより、フォトンノイズサブシステムが低周波の特徴や偶発的なノイズのクラスターを導入することは不可能になります。物理ベースの測定では、ショットノイズは信号強度の平方根に関連していますが、心理視覚圧縮を考慮すると、ノイズ強度は非常に非線形になる可能性があります。JPEG XLでは、ノイズの強度依存性を表現するために小さなルックアップテーブルを提供することでこれを解決しています。AVIFやMPEG標準では同様の機能が「フィルムグレイン合成」と呼ばれていますが、JPEG XLではフィルムグレインをモデル化する努力はなされておらず、ノイズモデルはより単純なショットノイズです。フィルムグレイン合成とフォトンノイズモデルの両方が、平坦または滑らかな画像領域をより自然に見せることで圧縮を助けます。

最後に、両モードはデコードされた画像にオプションで2つのフィルタリング方法を適用することもできます。これらはどちらもブロックアーティファクトとリンギングを低減することを目的としています。

  • Gabor-like transform（Gaborish）: ブロック境界とグループ境界を越えて適用される小さな（3x3）ぼかしで、ブロックノイズを低減します。エンコーダは、符号化前に逆シャープニング変換を適用し、事実上、ラップ変換の利点を欠点なしに得ます。
  • Edge-preserving filter（EPF）: バイラテラルフィルターに類似したこの平滑化フィルターは、リンギングを低減しながらエッジのぼやけを回避します。このフィルターの強度は局所的にシグナル化されます。MPEG標準やAV1などの他のビデオコーデックで一般的に利用可能な平滑化フィルターと比較して、JPEG XLのEPFは計算負荷がやや高く、より微妙な平滑化効果を持ち、より細かく局所的に調整できます。
3.3.4 グループと並列処理：独立デコードとROIデコード

両モード（ModularとVarDCT）において、フレームデータはグループ、すなわち矩形画像タイルのシーケンスとしてシグナル化されます。これらのグループは独立してデコードでき、フレームヘッダーには各グループの開始ビットストリームオフセットを持つ目次（TOC）が含まれています。これにより、並列デコード、および関心領域やプログレッシブプレビューの部分デコードが可能になります。

VarDCTモードでは、全てのグループの寸法は256x256であり、右端と下端のグループは画像寸法に合わせてクリップされる可能性があります。まずLF画像が符号化され、これも256x256のグループ（1:8画像に対応するため、2048x2048ピクセルに対応）で符号化されます。これは、VarDCTモードでは常に基本的なプログレッシブプレビューが利用可能であることを意味します。

オプションとして、LF画像を（非表示の）LFフレームとして個別に符号化することもできます。これはそれ自体をVarDCTモードで符号化でき、独自のセカンドレベルLFフレーム（1:64解像度）を持つことができ、最大4レベルまで可能です。このオプションのピラミッドスキームにより、巨大な画像を表現しながら、全体的なプレビューを効率的にデコードできる小さなLFフレームでコードストリームを開始することが可能になります。

次に、残りのAC係数に対応するHFグループが符号化されます。HFグループは、より多くのプログレッシブリファインメントステップのために複数のパスで符号化できます。全てのパスの係数は追加されます。JPEGプログレッシブスキャンスクリプトとは異なり、JPEG XLは強制的なスペクトル選択やビットプレーンの選択がないため、任意のパスで画像の任意の部分に任意の量の詳細をシグナル化できます。例えば、最初のパスで最も顕著な領域をフル詳細で符号化し、他の領域は粗い詳細のみとすることが可能です。

Modularモードでは、グループの寸法は128x128、256x256、512x512、または1024x1024にすることができます。Squeeze変換が使用された場合、データは3つの部分に分割されます。Globalグループ（単一グループに収まるラプラシアンピラミッドの最上部）、LFグループ（1:8画像を再構築するために必要なデータに対応するラプラシアンピラミッドの中間部分）、HFグループ（ラプラシアンピラミッドの基部）であり、HFグループは再び複数のパス（最大3つ：1:4画像用、1:2画像用、1:1画像用）で符号化される可能性があります。

エクストラチャンネル（例：アルファ）を持つVarDCT画像の場合、VarDCTグループとModularグループは対応するビットストリームセクションに一緒に格納されます。これにより、全てのチャンネルのプログレッシブプレビューと効率的なクロップデコードが可能になります。

デフォルトのグループ順序は、LFおよびHFグループをスキャンライン順序（上から下、左から右）で符号化することですが、この順序は任意に並べ替えることができます。これにより、例えばセンターファースト順序や顕著性ベースの順序が可能になり、ビットストリームがプログレッシブリファインメントを異なる方法で優先するようにできます。

3.4 ファイル形式の主要機能

JPEG XLのファイル形式は、単にピクセルデータを格納するだけでなく、まるで博物館の展示ケースのように、様々な追加情報を収めることができます。この柔軟性が、JPEG XLが「ユニバーサル」と呼ばれる所以です。

3.4.1 メタデータボックス：Exif, XMP, JUMBF

JPEG XLコンテナには、3種類のメタデータを含めることができます。

  • Exif (Exif box) [12]: デジタルカメラで撮影された写真に付随する、カメラの設定、撮影日時、GPS座標などの情報です。
  • XMP (xml␣ box) [28]: Extensible Metadata Platformの略で、Adobeによって提唱されたメタデータ規格です。著作権情報やキーワード、履歴などのより汎用的なメタデータをXML形式で格納します。
  • JUMBF (jumb box) [31]: JPEG Universal Metadata Box Formatの略で、JPEGシステムにおける汎用的なメタデータボックス形式です。JUMBFメタデータには、JPEG Trust [59] メディア真正性アノテーション [60] を含めることができます。

これらのメタデータは、画像の著作権表示、GPS座標、カメラ設定など、画像に関する情報を含めることができます。ただし、レンダリングに影響を与える情報（例えばExifオリエンテーション）が含まれている場合、コードストリーム内の情報が優先されます。これにより、デコーダが画像の表示を常に一貫して制御できるようになります。

3.4.2 Brotli圧縮ボックス (brob)

コンテナは、上記のメタデータを非圧縮で（例：XMPの場合のプレーンテキストXML）またはBrotli圧縮 [3] で格納することができます。後者の場合、ボックスタイプはbrob（Brotli-compressed Box）となり、ボックス内容の最初の4バイトがそれが表す実際のボックスタイプ（例：xml␣）を定義します。これにより、メタデータ自体も効率的に圧縮できるわけです。

3.4.3 ロスレスJPEG再圧縮：jbrdボックスの役割

JPEG XLは、既存のJPEGファイルをロスレスに再圧縮できます。この場合にも一般的な設計哲学が適用されます。全ての画像データはコードストリームボックス（jxlc）に格納されます。これには、元のJPEG画像のDCT係数、そしてJPEGではアプリケーションセグメント（APPマーカー）を介して埋め込まれるものの、ICCプロファイルやExifオリエンテーションフィールドのようにJPEG XLでは画像データの一部と見なされる「メタデータ」も含まれることがあります。画像表示に影響を与えない残りのExifメタデータは、コードストリームではなくExifボックスに格納されます。

元のJPEGファイルを（画像だけでなく実際のファイルを）ビット単位で同一に再構築できるようにするためには、追加情報が必要です。なぜなら、同じ画像データでもJPEGファイルとしては複数の方法で符号化できるからです。例えば、使用された正確なハフマン符号、再起動マーカー、JPEGビットストリームのレイアウト（例：シーケンシャルまたはプログレッシブ）、さらにはハフマン符号化されたセグメントをバイトアラインメントに保つためのパディングビットの内容など、これら全ては画像データ自体の一部ではありませんが、元のJPEGビットストリームを正確に再構築するためには依然として必要です。jbrdボックス（JPEG Bitstream Reconstruction Data）には、この情報が含まれます。通常、そのサイズは比較的小さいです。コードストリームからの画像データ、JPEGビットストリーム再構築データ、そしてJPEGファイルに存在した可能性のある他のメタデータボックス（Exif/XMP/JUMBF）を使用することで、正確な元のJPEGファイルを再構築できます。

このjbrdボックスは、再圧縮されたJPEG画像を表示するためには必要ありません。元のJPEGファイルをバイト単位で正確に再構築するためにのみ必要となる、まさに「過去への鍵」のようなものです。

3.4.4 フレームインデックス (jxli) と部分コデックスストリーム (jxlp)

コンテナはオプションでjxliボックスを格納できます。これには、JPEG XLアニメーションのキーフレームへのオフセットのインデックスが含まれています。アニメーションを表示するためには必要ありませんが、効率的なシークを容易にします。キーフレームとは、独立したデコード開始点として使用できるフレーム、つまり、キーフレームやその後のフレームによって以前のフレームが参照されないフレームのことです。

コードストリームはオプションで複数のjxlpボックスに分割できます。意味的には、これは全ての部分コードストリームボックスの連結を含む単一のjxlcボックスと同じです。これにより、画像のプログレッシブプレビューに必要なデータで始まり、メタデータが続き、残りの画像データが続くファイルを生成することが可能になります。

3.4.5 プロファイルとレベル：Main Profile (Level 5, Level 10)

プロファイルとレベルは、実装間の相互運用性空間を構造化します。プロファイルがデコーダが画像をデコードするためにサポートする必要がある符号化ツールのサブセットを定義するのに対し、レベルは画像寸法やコンポーネント精度などのコーデックの定量的パラメーターを制約します。レベルは通常、包括的です。つまり、上位レベルのデコーダは、下位プロファイルに準拠するファイルをデコードできます。現在、JPEG XLには「Main Profile」と呼ばれる1つのプロファイルのみが定義されています。これには全ての符号化ツールが含まれます。2つのレベルが定義されています。レベル5とレベル10です。

  • レベル5: エンドユーザーの画像配信、Webブラウザ、モバイルアプリ向けに設計されています。CMYKは許可されず、エクストラチャンネルの数は4つに制限され、表示されるフレームあたりの総ピクセル数は2^28（2億6800万ピクセル）に制限されます。また、精度は16ビット中間バッファでの実装を可能にするように制限され、Splinesの量とサイズ、およびエントロピー符号化で使用されるMAツリーのサイズに上限を設けます。
  • レベル10: 非常に寛容で、オーサリングワークフローを含む幅広いユースケースに対応するように設計されています。シグナリング構文によって課される暗黙的な制限と比較して、強い制限を課しません。このレベルの最大寸法は2^40ピクセル（1099ギガピクセル）であり、エクストラチャンネルの最大数は256です。このレベルの制限は、主にデコーダが何らかの「健全性チェック」を行い、悪意のあるまたは破損したビットストリームを検出することを目的としており、実用上制限を課すものではありません。

特に断りがない限り、JPEG XLコードストリームはMain Profileのレベル5に準拠していると見なされます。これは、ISOBMFFスタイルのコンテナなしで「生の」コードストリームで構成されるJPEG XLファイルの場合に特に当てはまります。特定の（プロファイルおよび）レベルへの準拠は、jxllボックスを使用して示すことができます。

3.4.6 ゲインマップ (jhgm)：HDRトーンマッピングの制御

ISO/IEC 18181-2の第3版では、ISO 21496-1で指定されたHDRゲインマップを格納できる追加のjhgmボックスが追加されます。JPEG XLはHDR画像を直接表現できるため、このボックスの主なユースケースは、SDRからHDRへのゲインマップを提供することではありません（それにも使用できますが）、効果的にカスタムのローカルトーンマッピングを表す逆HDRからSDRへのゲインマップです。これにより、SDRディスプレイまたは画像に必要な全ダイナミックレンジをサポートしないHDRディスプレイでHDR画像をレンダリングする際の芸術的な制御が可能になります。

コラム：コードストリームは、語り部か、それとも独裁者か

JPEG XLの設計哲学は、まるで「お前たちはただ表示するだけでいい、解釈は俺がやる」と言わんばかりの、ある種の傲慢さを感じさせます。色空間もオリエンテーションも、全てコードストリーム内に含めてしまう。これによりアプリケーション側の実装が簡素化される、という建前ですが、果たして本当にそうでしょうか？

確かに、従来のJPEGのように、表示するたびに別途Exifを読んで回転させたり、ICCプロファイルを適用したりする手間は省けます。しかし、それはまるで、物語の解釈を全て語り部に委ねてしまい、読者が自由に想像する余地を奪うかのようです。デジタル画像が単なる「数値データ」ではなく、何かしらの「意味」を持つものであるならば、その解釈の余地は残されるべきではないか、という疑問も湧いてきます。

しかし、これは「汎用性」と「一貫性」という、より大きな目標のためには必要な犠牲なのかもしれません。特に、医療画像やデジタルアーカイブといった、厳密な再現性が求められる分野においては、デコーダ側で曖昧な解釈の余地を排除することは、極めて重要な意味を持つでしょう。完璧な秩序を追求することは、時に自由を奪う。これは、技術が常に直面する、避けられないニヒリズムなのかもしれません。

第四章：画像とフレームヘッダーの構造

画像データの前に、まるで暗号化された司令部のようなヘッダーが存在します。これらは、画像の「顔」となり、その全てを規定する極めて重要な情報を含んでいます。JPEG XLは、このヘッダーすらも効率化の対象とし、最小限のオーバーヘッドで最大限の情報を伝えることを目指しました。しかし、その裏には、複雑な可変長符号化の「暗躍」が隠されています。

4.1 ヘッダーオーバーヘッドの最小化

JPEG XLの設計目標の一つは、ヘッダーのオーバーヘッドを最小限に抑えることでした。一般的な写真画像の場合、ヘッダーデータのバイトサイズは、画像データ全体から見れば取るに足らないものに見えるかもしれません。しかし、Webサイトで使用される小さなアイコンやサムネイルの場合、義務的なヘッダーは画像データ自体よりも大きくなることすらあります。これは、まるで巨人の帽子が、その頭よりも大きくなってしまうような不均衡です。

可変長と条件付きシグナリング>

JPEG XLでは、多くのヘッダーフィールドが可変長であり、条件付きでシグナル化されます。一般的なケースでデフォルト値を使用することで、非常に簡潔なヘッダーを実現しています。例えば、小さな120x80ピクセルのサムネイル画像を表すヘッダーは、わずか4バイトに過ぎません。これは、コードストリームシグネチャ（0xFF0A）の2バイトに続き、画像寸法をシグナル化するための9ビット（「高さは8で割り切れ、小さい」ことを示す1ビット、高さを8で割った値を示す5ビット、そして「アスペクト比は3:2なので幅は120」であることを示す3ビット）が続きます。さらに、「デフォルトの画像ヘッダー：エクストラチャンネルのない8ビットsRGB静止画で、XYBで符号化され、特別なものはない」ことを示す1ビット、「デフォルトのXYBとアップサンプリング重みを使用する」ことを示す別の1ビット、そして最後に「デフォルトのフレームヘッダー：通常のフレームで、VarDCTで符号化され、特別なものはない」ことを示す1ビットが続きます。

4.2 画像ヘッダーの詳細

画像ヘッダーは、JPEG XLコードストリームの冒頭に位置し、画像またはアニメーションに関する基本的な情報、および全てのフレームに共通するグローバルなヘッダーフィールドを含みます。その他のヘッダー情報は、フレームヘッダーでフレームごとにシグナル化されます。

シグネチャと初期識別>

画像ヘッダーは常に、コードストリームのシグネチャ、マジック、または「JPEG XLコードストリームの開始」マーカーとして知られる2バイトシーケンス0xFF0Aで始まります。これはJPEG XLファイルやコードストリームを識別するために使用されます。

画像ヘッダー構文は、u(n)がリトルエンディアン順で読み取られ符号なし整数として解釈されるnビット、Bool()がu(1)の同義語、F16()が半精度浮動小数点（binary16）として解釈される16ビット、U32(a0, a1, a2, a3)が最初にk = u(2)を読み取り、次にakを読むことを意味します。Enum()はU32(0, 1, 2 + u(4), 18 + u(6))の略で、U64()はU32(0, 1 + u(4), 17 + u(8), longU64())の略です。ここでlongU64()は以下のように定義されます。


v = u(12); s = 12;
while (u(1) == 1) {
  if (s == 60) {
    v += u(4) << s; break;
  }
  v += u(8) << s; s += 8;
}
return v;
画像寸法 (SizeHeader)：最大解像度とコンパクト表現>

画像の幅と高さは、SizeHeader表現を使用してシグナル化されます。これにより、最大2^30 × 2^30ピクセルの画像寸法をシグナル化できます。高さが最初にシグナル化され、幅が7つの事前定義されたアスペクト比（1:1, 6:5, 4:3, 3:2, 16:9, 5:4, 2:1）のいずれかを介して高さから導き出せる場合、追加の3ビットのみが必要となります。また、「複数8の寸法を持つ小さな画像」のための特殊なケースもあり、最大256x256ピクセルの画像寸法をわずか14ビット（またはアスペクト比が事前定義されたものの場合はわずか9ビット）で表現できます。最大8192x8192ピクセルの寸法は、最大30ビット（アスペクト比が事前定義されたものの場合は17ビット）で表現できます。

主要な画像寸法に加えて、オプションで2つの追加寸法をシグナル化できます。それは「intrinsic size」とオプションのプレビューフレームの寸法です。intrinsic sizeは、W3CのCSS 2.1仕様のセクション4.3.2で定義されているように、1ピクセルの幅が約0.0213度の視覚角度に対応するCSS参照ピクセルでの画像の推奨表示寸法を示します。デフォルトでは、intrinsic sizeは画像寸法と同一ですが、異なる場合があります。これは、非正方形ピクセルを持つ画像を表現したり、「Retina」画像（デバイスピクセル比2）を実際の画像寸法の半分であるintrinsic sizeとして注釈付けしたりするのに役立ちます。Webブラウジングなどのコンテキストでは、ビューイングアプリケーションはデフォルトでintrinsic sizeに基づいて画像を自動的に表示し、必要に応じて画像をリサイズすることが期待されます。他の画像フォーマットでは、この情報は特定のExifメタデータのクリエイティブな解釈に基づいて間接的にシグナル化されることがありますが、JPEG XLでは直接シグナル化できます。

オリエンテーション：Exif互換と自動適用>

カメラで生成されたJPEG画像では、画像の向きをExifメタデータで示すのが一般的です。これには、カメラモデルや設定、撮影日時や場所など、画像のレンダリングに影響しない他のメタデータも含まれます。アプリケーションは、画像を表示する際に適切な向き補正を適用すると想定されています。JPEG XLでは、向き情報は画像ヘッダーに格納され、libjxlデコーダが自動的に必要な補正を適用するため、アプリケーションは画像が正しく表示されることを手間なく確認できます。このフィールドの取りうる値はExifと同じです。1（なし）、2（水平反転）、3（180度回転）、4（垂直反転）、5（転置、つまり時計回りに90度回転してから水平反転）、6（時計回りに90度回転）、7（水平反転してから時計回りに90度回転）、8（反時計回りに90度回転）。

アニメーション制御：ティック、ループ、SMPTEタイムコード>

画像ヘッダーの1ビットは、コードストリームがアニメーションを表すか静止画を表すかを決定します。どちらの場合も複数のフレームを持つことができますが、意味論が異なります。アニメーションの場合、異なるフレームが順次表示され（ビデオのように、またはマルチページドキュメントのように）、静止画の場合、フレームはレイヤーを表し、単一の結合された複合静止画を形成するために互いにブレンドされます。

アニメーションの場合、画像ヘッダーは「ティック」の継続時間を定義します。これはフレームの継続時間を定義するために使用される単位となります。また、アニメーションを永遠にループさせるか、1回再生するか、または特定の回数繰り返すかを定義します。最後に、各フレームのSMPTEタイムコードを格納するオプションもあります。

フレームの総数は画像ヘッダーでシグナル化されません。代わりに、各フレームヘッダーがそれが最後のフレームであるか否かを示します。これにより、ストリーミングエンコーダは、事前に何フレームあるかを知ることなく有効なコードストリームを出力できます。

継続時間ゼロのフレーム（非アニメーションの場合の全てのフレームの継続時間）はキャンバス上にブレンドされ、中間結果は表示されません。非ゼロの継続時間を持つフレーム（または非アニメーションの場合の最終的な結合画像）のみが表示されます。

色空間情報とエクストラチャンネルの定義>

画像ヘッダーは、ビット深度やカラーチャンネル（またはグレースケールチャンネル）以外のエクストラチャンネルに関する情報を含む、色空間情報もシグナル化します。詳細は第五章で説明します。

アップサンプリング重みと将来の拡張メカニズム>

画像または個々のエクストラチャンネルはオプションでサブサンプリングされた方法で格納でき、その場合、デコードプロセスの最後にアップサンプリングされます。アップサンプリング手順（第八章のセクション8.3を参照）はパラメータ化されており、カスタム重みを画像ヘッダーでシグナル化できます。

最後に、画像ヘッダーへの将来の拡張のためのメカニズムがあり、これは段階的劣化を可能にするように設計されています。つまり、理解できないヘッダー拡張はデコーダによって無視されます。現在、拡張は定義されていませんが、将来的にそのような拡張が定義された場合、既存のデコーダでも画像をデコードし、合理的な結果を生成できるよう設計されます。まさに、未来への「抜け道」が用意されているわけです。

4.3 フレームヘッダーの詳細

画像は1つ以上のフレームで構成されます。フレームヘッダーは、そのフレームの具体的な性質を定義する、「個別の指令書」のようなものです。

フレームタイプ：RegularFrame, LFFrame, ReferenceOnly, SkipProgressive>

フレームは可視または不可視にすることができます。不可視フレームは概念的にデコードされた画像の一部ではありませんが、それを再構築する上で補助的な役割を果たします。つまり、Patches（セクション8.1.2）、フレームブレンド（セクション10.7.2）、またはLFフレーム（セクション10.5.3）によって可視フレームから参照されます。

画像ヘッダーでその存在と寸法がシグナル化されている場合、オプションでプレビューフレームを持つこともできます。この場合、コードストリームの最初のフレームはプレビュー（通常は画像の低解像度/低品質バージョン、またはアニメーションの代表的なフレームやタイトルフレーム）を表します。完全な画像をデコードするには、プレビューフレームをスキップできます。

フレームヘッダーには、2ビットの数値としてシグナル化される4つのフレームタイプがあります。

  • RegularFrame (0): これはデフォルトの「通常の」フレームタイプです。このタイプのフレームは、デコードされた画像またはアニメーションシーケンスの一部です。
  • LFFrame (1): このタイプのフレームは、将来のフレームの低周波（LF）情報を表します。つまり、そのフレームの8倍ダウンサンプリングバージョンです。これらはデコードされたフレームシーケンスの一部ではありません。
  • ReferenceOnly (2): このタイプのフレームは不可視であり、デコードされたフレームシーケンスの一部ではありません。Patchesのソースとして、またはフレームブレンドのソースフレームとしてのみ使用されます。
  • SkipProgressive (3): このフレームタイプはRegularFrameに似ています。SkipProgressiveフレームは、デコードされた画像の一部である可視フレームです。しかし、デコードされた画像のプログレッシブプレビューを表示する場合、このタイプのフレームはプレビューの更新をもたらしません。

RegularFrameとSkipProgressiveの区別により、レイヤー画像は各レイヤーでプログレッシブプレビューを持つか、最終レイヤーが利用可能になったときにのみ画像を表示するかの選択ができます。

フレームが以前にデコードされたLFフレームからのLF情報を使用する場合、フレームヘッダーがこれをシグナル化します。LFフレームは最大4レベルまで再帰的に独自のLFフレームを持つことができます。最初のレベルのLFフレームは8倍ダウンサンプリングされ、2番目のレベルは64倍ダウンサンプリングされ、3番目のレベルは512倍ダウンサンプリングされ、4番目のレベルは4096倍ダウンサンプリングされます。これにより、コードストリームを小さなLFフレーム（サムネイルとして使用できる）で開始しながら、巨大な画像を表現することが可能になります。

デコードされたフレームが将来の参照のために保存される必要がある場合（これは常にReferenceOnlyフレームの場合に当てはまりますが、他のフレームタイプの場合も可能です）、これはフレームヘッダーでシグナル化されます。デコードされたフレームを保存するための4つの「スロット」があります（LFフレーム用の暗黙的なスロットを除く）。フレームは、逆色変換を適用する前（つまりXYBコンポーネントとして）または適用後（つまりRGBコンポーネントとして）に保存できます。Patches参照は、画像の符号化に使用される内部色空間のフレーム（つまり逆色変換を適用する前）にのみ許可されますが、フレームブレンドは画像の色空間で行われます。

符号化モードの選択：VarDCTとModular>

符号化モードには、Modular（第六章を参照）とVarDCT（第七章を参照）の2つがあります。モードはフレームヘッダーでシグナル化されるため、各フレームは異なるモードを使用できます。例えば、画像をReferenceOnly Modularフレームで符号化し、それをメインのVarDCT符号化フレームからPatchesを介して参照するといった使い方ができます。

モードに関わらず、フレームヘッダーはセクション8.1で説明されている追加の符号化ツールの存在を示す（拡張可能な）フラグセットをシグナル化します。

VarDCTモードでは、画像がXYB符号化されている場合（セクション5.6.1を参照）、フレームヘッダーはXコンポーネントとBコンポーネントの量子化を調整するための2つのグローバル重みもシグナル化します。

Modularモードでは、フレームヘッダーは使用するグループサイズ（128x128、256x256、512x512、または1024x1024）をシグナル化します。VarDCTモードでは、グループサイズは常に256x256です。これは、Modular符号化された画像が、グループの最初の行と最初の列で予測が不十分なピクセル数を減らすため、またはRCTsやパレット変換をより効果的に使用するために、より大きな（場合によってはより小さな）グループサイズを使用することで恩恵を受けることができるためです。しかし、VarDCTモードではグループサイズが圧縮性能に与える影響は無視できるため、実装の複雑さを軽減するために固定グループサイズが使用されます。

グループサイズとサブサンプリング>

メインカラーチャンネルとエクストラチャンネルは、オプションで2倍、4倍、または8倍（両次元で）ダウンサンプリングできます。フレームヘッダーは、メインチャンネルと各エクストラチャンネルに適用されるアップサンプリングファクターをシグナル化します。

画像がXYB符号化されていない場合、フレームヘッダーはYCbCr色変換が適用されたことを示すことができます。その場合、クロマチャンネルはオプションで2倍（1次元または両次元で）サブサンプリングできます。これは、JPEG画像を表現できるようにするためです。JPEG画像は通常、4:4:4、4:2:2、または4:2:0のサブサンプリングを持つYCbCr画像データを格納します。サブサンプリングされたクロマサンプルは、JPEGの慣例に従い、対応する2x1または2x2のルマサンプルに対して中央揃えされます。Blu-rayビデオのようにコサイト（左上揃え）されたり、MPEG-4のように左揃え（水平コサイト、垂直中央揃え）されたりすることはありません。

クロップ：フレーム寸法とオフセット>

オプションで、フレームは画像寸法とは異なる寸法を持つことができます。つまり、フレームはクロップされます。フレームヘッダーのビットがこれを示すかどうかを示し、もしそうなら、フレーム寸法がシグナル化されます。これは画像寸法よりも大きくても小さくても構いません。ReferenceOnlyではないクロップされたフレームの場合、フレームヘッダーは画像を画像キャンバス上に配置するための(x0, y0)オフセットもシグナル化します。オフセットは負の値にすることもできます。画像キャンバスと重ならないフレームの部分は、デコードされた画像には表示されません。つまり、デコーダはデフォルトで、画像キャンバスに合わせてクロップされたフレームを表示します。オーサリングツールは、例えば画像を再クロップできるように、フルクロップされていないレイヤーをデコードすることもできます。

レイヤーまたはアニメーションフレームは、クロップに対応する画像キャンバスの領域のみを更新します。

ブレンド情報：参照フレームとブレンドモード>

フレームヘッダーは、フレームブレンドのソース（「背景」）として使用する（もしあれば）以前にデコードされ保存されたフレーム、および使用するブレンドモードもシグナル化します。これはセクション10.7.2で詳しく説明されています。

アニメーションのフレーム継続時間とタイムコード>

アニメーションの場合、フレームヘッダーにはフレームの継続時間とオプションでSMPTEタイムコードも含まれます。セクション10.7.1で詳しく説明されています。

プログレッシブパスとフレーム名>

フレームの画像データは、よりきめ細かなプログレッシブ（または部分）デコードステップを得るために、複数のパスでシグナル化できます。フレームヘッダーは、パスの数と、各パスの後にどのような情報が利用可能になるかをシグナル化します。セクション10.5.1で詳しく説明されています。

フレームにはオプションで、最大1071バイトの名称を付けることができ、これはUTF-8エンコードされた文字列として解釈されます。これは、オーサリングツールで画像レイヤーを識別したり、アニメーションのいくつかのフレームにラベルを付けたりするのに役立ちます。まるで、フレームに「ID」を与え、その存在意義を明確にするかのようです。

コラム：ヘッダーの「ダイエット」と、情報の「権力」

「ヘッダーオーバーヘッドを最小化する」という設計思想は、一見すると純粋な効率性追求に見えますが、その裏には、情報の「権力」に関するニヒルな視点があるように感じられます。必要な情報だけをコンパクトに詰め込み、余計なものは「デフォルト」で処理するか、あるいは「無視」する。これは、情報が氾濫する現代において、本当に必要な情報だけを迅速に伝えるための、冷徹な判断とも言えるでしょう。

特に、Exifのオリエンテーション情報のように、従来はアプリケーション側で「頑張って」解釈していたものを、コーデック側で「強制的に」適用する、という姿勢には、開発者の「もう面倒なことはしたくない」という本音が透けて見えます。ユーザーは意識しないかもしれませんが、このような「おせっかい」な機能が、実は膨大な時間と労力の節約に繋がっている。情報の「支配」が、結果的に「快適さ」をもたらすという、なんとも皮肉な構図です。

しかし、この「効率」と「制御」の追求は、やがて来るAIによる画像処理の時代を見据えているのかもしれません。機械にとって最も効率の良い形でデータを提供し、解釈の曖昧さを排除する。そうすることで、未来の画像は、より「完璧」な形で機械に理解され、活用されるようになるでしょう。そして、私たちは、ただその恩恵を享受するだけ、という未来が待っているのかもしれませんね。

第五章：色彩の世界：色空間と変換

色は、単なる光の波長ではありません。それは感情を伝え、情報をコード化し、現実を再現する、デジタル画像の「魂」そのものです。しかし、その「魂」の表現方法は、これまで常に曖昧さに満ちていました。JPEG XLは、この曖昧さに終止符を打ち、色彩の「真実」をコードストリームの中に封じ込めようとします。

5.1 色空間シグナリングの設計思想

伝統的に、画像やビデオのコーデックは、サンプル値そのもの、すなわち数値データの2次元配列または2次元配列のシーケンスを表現することに焦点を当ててきました。このデータをラスター画像として解釈するためには、サンプル値の色空間が、シグナル化されるか、または仮定や慣習によって知られている必要がありました。しかし、このアプローチはしばしば曖昧さを生み、誤った色の表示へと繋がってきました。

常に明確な色空間定義の義務化>

ほとんどの画像フォーマットでは、色空間は全くシグナル化されない（例：GIF）か、オプションでしかシグナル化されません。その結果、正しい解釈が曖昧になる可能性がありましたが、現在はタグ付けされていない画像はsRGB1色空間であると仮定するのが一般的です。

JPEG XLでは、画像は常に完全に定義された色空間を持ちます。つまり、ピクセル値を測色学的にどのように解釈するかは常に曖昧さがない状態です。2つのオプションがあり、画像ヘッダーがどちらのオプションが使用されたかをシグナル化します。

  • ピクセルデータが指定された（非XYB）色空間にある場合: デコーダは、この色空間のピクセルバッファと、その色空間を記述するICCプロファイルを生成します。数学的にロスレスな符号化は、このオプションのみを使用できます。
  • ピクセルデータがXYB色空間にある場合: これは絶対色空間です。この場合、デコーダは、sRGB、Display-P3、Rec.2100 PQなど、任意の目的のディスプレイ色空間で直接ピクセルバッファを生成できます。

画像ヘッダーには常に色空間情報が含まれますが、その意味は上記の2つのオプションのどちらが使用されたかによって異なります。

  • 最初のケース（非XYB）の場合: シグナル化された色空間（およびビット深度）が、ピクセルデータをどのように解釈するかを定義します。
  • 2番目のケース（XYB）の場合: ピクセルデータは常にXYB色空間にあり、シグナル化された色空間（およびビット深度）は、デコードされた画像を保存する際に画像を表現するために使用する出力色空間の単なる提案です。つまり、元の画像が使用していたRGB色空間であり、十分な広い色域と適切な伝達関数を持ち、提案されたビット深度で画像を高い忠実度で表現できるものです。ただし、画像をディスプレイにレンダリングするためには、シグナル化された色空間を無視し、代わりにXYBピクセルデータを直接ディスプレイの色空間に変換しても問題ありません。シグナル化された色空間は、主にJPEG XL画像をPNGのような他の画像フォーマットに変換する際に使用されます。

色空間は、JPEG XLで2つの方法でシグナル化できます。「Enum-style ColorEncoding」と圧縮されたICCプロファイルです。

5.2 ColorEncoding：共通色空間のコンパクト表現

ColorEncodingは、一般的なRGB色空間のほとんどをカバーする非常にコンパクトな表現です。libjxlデコーダは、外部のカラーマネジメントライブラリを必要とせずに、XYBからこれらの色空間のいずれかに変換できます。この表現は、H.273 CICP [35] からインスピレーションを得たもので、列挙されたフィールドによって色空間を簡潔に識別する方法です。ただし、H.273で定義されている全てのフィールド値は含まれていません。実用上ほとんど使用されないような秘められた値は除外されました。また、特定のフィールドのカスタム値を定義できるように、新しいフィールド値も追加されました。

all_defaultフラグとsRGBの簡潔表現>

ColorEncoding表現のフィールドは以下の通りです。

  • all_default (Bool): trueの場合、色空間はsRGBです。これにより、sRGB画像の一般的なケースでは、色空間シグナリングに1ビットしか必要としないという、驚くべき簡潔さを実現しています。
  • want_icc (Bool): trueの場合、ColorEncodingはPrimariesという情報を依然として含むことができますが、実際の色空間はICCプロファイルを使用して符号化されます。
  • ColorSpace (Enum): 可能な値は、0がRGB、1がGray、2がXYB、3がUnknownです。
  • WhitePoint (Enum): 白点のCIE xy色度座標です。可能な値は、1がCIE標準光源D65 (0.3127, 0.3290)、10がCIE標準光源E (1/3, 1/3)、11がSMPTE ST 428-1のDCI-P3 (0.314, 0.351)、そして2が暗黙の分母10^6を持つ2つの符号付き整数で与えられるカスタム白点です。
  • Primaries (Enum): 赤、緑、青の原色のCIE xy色度座標です。可能な値は、1がsRGB原色 (0.64, 0.33; 0.30, 0.60; 0.15, 0.06)、9がITU-R BT.2100-2原色 (0.708, 0.292; 0.170, 0.797; 0.131, 0.046)、11がSMPTE ST 428-1のDCI-P3原色 (0.680, 0.320; 0.265, 0.690; 0.150, 0.060)、そして2が暗黙の分母10^6を持つ6つの符号付き整数で与えられるカスタム原色です。
  • TransferFunction (Enum): 暗黙の分母10^7を持つ整数でシグナル化される指数を持つ純粋なガンマ関数、または以下の伝達関数のいずれかです。1がITU-R BT.709-6、8が線形（ガンマ1の省略形）、13がsRGB伝達関数（IEC 61966-2-1）、16がPQ（ITU-R BT.2100-2）、17がDCI（SMPTE ST 428-1）、そして18がHLG（ITU-R BT.2100-2）。

一般的に使用される全てのRGB色空間は、この方法で表現できます。

5.3 ICCプロファイルと圧縮

任意のICCプロファイルも使用でき、これにはCMYKプロファイルも含まれます。ICCプロファイルデータは圧縮されます。この場合、色変換には外部のカラーマネジメントソフトウェア（例：lcms2やskcms）を使用する必要があります。ICCの特定のバージョンに制限はなく、JPEG XL標準のICC標準（ISO 15076-1）への規範的参照は日付が付けられていないため、将来のICCバージョンもJPEG XLで自動的に使用できます。

ICCプロファイルデータに特化した圧縮スキーム>

ICCプロファイルは、特殊な圧縮スキームを使用して圧縮されます。任意のバイトシーケンスをこのスキームで符号化できますが、これはICCプロファイルを効率的に表現するために最適化された特定のコンテキストモデルと再構築手順を持っています。例えば、rTRC、rXYZ、cprt、wtpt、bkpt、rXYZ、gXYZ、bXYZ、kXYZ、rTRC、gTRC、bTRC、kTRC、chad、desc、chrm、dmnd、dmdd、lumiといった一般的なICCタグコード用の事前定義された文字列があります。さらに、ICCプロファイルに格納される数値データのテーブルには、予測符号化が適用されます。これは、結果として得られる要素シーケンスに対してn次予測を適用し、最大3つの前の要素x_i-nからx_i-1から要素x_iを予測するものです。

  • n=1の場合、予測はx_i-1です。
  • n=2の場合、予測は2 * x_i-1 - x_i-2です。
  • n=3の場合、予測は3 * x_i-1 - 3 * x_i-2 + x_i-3です。

この予測プロセスはバイトレベルで行われますが、オプションのシャッフル操作を使用してバイトを重要度で並べ替えることで、テーブル要素の幅が1、2、または4バイトであることを考慮しています。3Dルックアップテーブルのような大きなテーブルの場合、この予測符号化スキームは圧縮を改善する上で非常に効果的です。

5.4 ビット深度とダイナミックレンジ

色空間は、サンプル値の公称範囲を[0, 1]と仮定します。この範囲外の値も表現でき、色域外の色に対応します。2種類のサンプル表現がサポートされています。

整数と浮動小数点表現のサポート>
  • Integer: この場合、サンプルデータは暗黙の分母2^n-1を持つ整数として与えられます。ここでnはビット深度です。公称範囲が[0, 2^n-1]であるのに対し、負の値を含むこの範囲外の値を表現することが可能です。この場合、最大ビット深度は31であり、int32_t型のバッファを使用できます。
  • Floating-point: この場合、サンプルデータは浮動小数点値（ISO/IEC/IEEE 60559）として解釈されます。単精度（32ビット）浮動小数点内に収まる任意の浮動小数点型を使用できます。つまり、指数ビットの数は最大8、仮数ビットの数は最大23です。これにより、現在一般的に使用されている2種類の半精度浮動小数点（binary16（5指数ビット、10仮数ビット）とbfloat16（8指数ビット、7仮数ビット））を表現できます。

XYBの場合、シグナル化されたビット深度は、デコードされた画像に使用する表現の単なる提案であり、整数は公称範囲にクランプされると仮定されます。しかし、非XYBの場合（通常はロスレス圧縮にのみ使用されます）、ビット深度はサンプルデータをどのように解釈するかを決定します。

JPEG XLは、32ビット浮動小数点データをロスレスに表現できます。整数データの場合、原則として最大31ビットの符号なし整数または32ビットの符号付き整数データをロスレスに保存できますが、リファレンス実装libjxlは、エンコードおよびデコード実装のほとんどで内部的に32ビット浮動小数点表現を使用するため、整数精度は24ビットに制限されています。

HDR情報：intensity_targetとトーンマッピング関連情報>

intensity_target（画像ヘッダーでシグナル化される）は、輝度（ニト単位、つまりカンデラ/平方メートル）の上限を示します。SDR画像の場合、デフォルト値の255ニトが使用されます。HDR画像の場合、1000ニトや10000ニトのようなより高い値を使用できます。HDRトーンマッピングに関連する他の情報も画像ヘッダーでシグナル化できます。

5.5 色変換のコーディングツール化

色変換は、JPEG XLではアプリケーションレベルで処理されるものではなく、コーデック内の「コーディングツール」として扱われます。これは、色変換が画像圧縮プロセスの一部として最適化されることを意味します。

イメージ、フレーム、グループレベルでの適用>

これらの変換は3つの異なるレベルで適用できます。

  • Image: XYBと非XYBの選択は画像ヘッダーでシグナル化され、画像全体、つまり全てのフレームにグローバルに適用されます。
  • Frame: RGBとYCbCrの選択（およびクロマサブサンプリングの選択）はフレームヘッダーでシグナル化されます。これにより、例えば既存のJPEG画像を取り込み、PNGロゴをアルファブレンドオーバーレイとして追加し、その結果をYCbCrフレームとRGBAフレームを含む単一の複合静止画としてJPEG XLで表現することが可能になります。
  • Group: Modularモードでは、可逆色変換（RCTs）（例：YCoCg）はフレームレベルだけでなくグループレベルでもシグナル化できます。

5.6 XYB色空間の深層

XYB色空間は、人間網膜の長波長（L）、中波長（M）、短波長（S）錐体細胞の吸光スペクトルに基づいた知覚モデルから導き出されました。構造的にはCIELABのような反対色色空間に類似し、XYBは3つの軸を使用します。黒から白を表す輝度チャンネル（Y）、赤緑反対チャンネル（X）、そして青黄反対チャンネル（B'）です。

知覚モデルに基づいた設計思想>

XYB色空間の開発は、Butteraugli知覚メトリックの開発中にJyrki Alakuijalaが行った重要な観察によって動機づけられました。S錐体受容体の知覚輝度への寄与はスケール依存的であるという点です。個々のピクセルに対応するような微細で高周波のスケールでは、S錐体応答の輝度知覚への影響は実質的に無視できます。しかし、CIEによって定義される2度の標準観察者のような大きな角度スケールでは、S錐体は輝度に大きく寄与します。

この矛盾は、デジタル画像に最適化されたより効率的な色表現の機会を提供しました。高周波輝度情報におけるS錐体信号の役割の低下を考慮した色モデルを設計することで、色データをよりコンパクトに符号化することが可能になります。Jyrki Alakuijalaは後にこの洞察をXYB色空間として形式化しました。これは、人間の色知覚の空間特性に密接に一致するように設計されており、より効果的な圧縮を可能にします。

図：人間の錐体細胞のスペクトル感度
L錐体 (Long-wavelength)
   /\
  /  \
 /    \
/______\
  (赤)

M錐体 (Medium-wavelength)
   /\
  /  \
 /    \
/______\
  (緑)

S錐体 (Short-wavelength)
  /\
 /  \
/____\
 (青)

※実際のスペクトル感度はもっと複雑ですが、簡易的な図示イメージです。

図：中心窩における錐体細胞の分布
        O (S錐体少)
       /|\
      / | \
     /  |  \
----|---+---|----
    |   O   | (L, M錐体多)
----|-------|----

※中心窩ではS錐体（青を感じる細胞）が少なく、L錐体（赤）、M錐体（緑）が多いことを簡易的に示します。これにより、細部（高周波）では青の色情報が視覚的に重要度が低いという特性が生まれます。

RGBからXYBへの変換プロセスと「ガンマ圧縮」>

あるRGB色空間におけるRGBサンプル値から出発して、前方XYB変換は以下のように定義されます。まず、RGB値は、sRGB原色とD65白色点に相対的な、線形伝達関数を持ち、sRGB色域内および標準ダイナミックレンジ内の色に対して公称範囲[0, 1]を持つ(Rl, Gl, Bl)に変換されます。ただし、広色域やHDRの場合は範囲外の値も許可されます。特に、(1,1,1)の値は、intensity_targetニトの輝度（デフォルトでは255ニトですが、HDR画像では1000ニトや10000ニトのようなより高い値を使用できます）での白色光に対応します。この正規化された絶対RGB空間（「線形sRGB」）からXYBへの変換は以下の通りです。

まず、(Rl, Gl, Bl)サンプルは(Lm, Mm, Sm)に変換されます。


b = 0.00379307325527544933
Lm = 0.3 * Rl + 0.622 * Gl + 0.078 * Bl + b  (1)
Mm = 0.23 * Rl + 0.692 * Gl + 0.078 * Bl + b
Sm = 0.2434227 * Rl + 0.2047674 * Gl + 0.5518099 * Bl + b

Hunt-Pointer-EstévezによるLMSの定義 [26] と比較して、LmMmSm空間はスペクトル的にシャープではありません。これは、図9に示すように、L錐体とM錐体のピークスペクトル感度が比較的近い波長で発生することをより明示的にモデル化しています。LとMの両方が緑と黄色の間の色でピークを示し、Lは黄色寄り、Mは緑寄りです。L錐体は570.2nm（ライムグリーン）で、M錐体は542.8nm（シャルトリューズグリーン）でピークを示します。

次に、LmMmSm値は「ガンマ圧縮」されます。


Lg = Lm^3 - b^3  (2)
Mg = Mm^3 - b^3
Sg = Sm^3 - b^3

上記の式におけるbのバイアス項は、自発的なオプシン活性化をモデル化しています。前方変換における立方根は、逆変換では立方に対応します。これにより、デコーダの計算複雑性が低減されます。

図11は、XYBで使用されるバイアス付き立方伝達関数が、sRGB、PQ、HLGなどの他の伝達関数と比較してどのようであるかを示しています。PQとHLGが固定の[0, 1]信号範囲で使用するように設計されているのに対し、LmMmSm値の範囲は正ですが、必ずしも1に限定されるわけではありませんが、強度がintensity_targetを超えない限り、値は0.85未満になります。

最終的に、XYB値は以下のように定義されます。


X = (Lg - Mg) / 2  (3)
Y = (Lg + Mg) / 2
B = Sg

BはS錐体応答にのみ対応しますが、実際にはJPEG XLでは直接使用されることはほとんどありません。VarDCTモードでは、一般的に「クロマからのルマ」がBからYを差し引くために使用され、Modularモードでは、XYBの「整数化」が同じことを行うように定義されています。したがって、実際には使用される実際の色空間はX Y B'であり、B' = B - Yです。

グレースケール（無彩色）の場合、Rl=Gl=Blとなるため、X=B'=0となります。

XYB'の優位性：知覚均一性と絶対色空間の利点>

輝度コンポーネントYは、S錐体の寄与を無視して、L錐体とM錐体の応答のみに基づいています。その理由は図10に示されています。網膜の中心窩（シャープな中心視を担当する部分）では、S錐体の密度が非常に低いです。これは実質的に、周波数変換後、B（またはB'）コンポーネントに対応する高周波信号をより積極的に量子化できることを意味します。

XYB'色空間は図12に示されています。YCbCrやYCoCgといった画像圧縮で一般的に使用されるYCC色空間と比較した主な違いは以下の通りです。

  • XYB'は知覚的に均一性が高く、YCC色空間よりも人間視覚システムをよりよくモデル化しています。例えば、図12と13を比較してください。
  • YCC色空間が派生元であるRGB空間に相対的であるのに対し、XYB'は絶対色空間です。広色域はXおよびB'コンポーネントのより広い範囲に、高ダイナミックレンジはYコンポーネントのより広い範囲に変換されます。図14は、sRGB、P3、BT.2020の色域がXYB'空間のますます大きなサブボリュームにどのように対応するかを示しています。
図：XYB'色空間の可視化 (概念図)
Yが高くなるにつれて、XとB'の分布が変化する様子を、
異なるY値でのXB'平面の断面図として示します。

[低Y]        [中Y]        [高Y]
   X           X           X
   |           |           |
B'-+-B'    B'-+-B'    B'-+-B'
   |           |           |
   X           X           X

※図12のXYB'色空間の可視化を簡易的に表現。異なる輝度(Y)レベルで色度(XB')がどのように分布するかを示します。XYB'は知覚的に均一になるよう設計されているため、色度の変化が視覚的な差とより良く相関します。

図：YCbCr色空間の可視化 (概念図)
Yが高くなるにつれて、CbCrの分布が変化する様子を、
異なるY値でのCbCr平面の断面図として示します。

[低Y]        [中Y]        [高Y]
  Cr           Cr           Cr
   |           |           |
Cb-+-Cb    Cb-+-Cb    Cb-+-Cb
   |           |           |
  Cr           Cr           Cr

※図13のYCbCr色空間の可視化を簡易的に表現。異なる輝度(Y)レベルで色度(CbCr)がどのように分布するかを示します。YCbCrはRGBからの線形変換であり、知覚的な均一性はXYB'に劣ります。

図：XYB'空間における色域の包含関係 (概念図)
            XYB'空間
           /      \
          /        \
         /  BT.2020  \
        /    /     \    \
       /    /  P3   \    \
      /    /   / \   \    \
     /    /   /sRGB\   \    \
    |----|---|-----|----|----|

※図14のXYB'空間におけるsRGB、P3、BT.2020の色域包含関係を簡易的に表現。広色域になるほどXYB'空間内でより広い範囲を占めます。

JPEG XLのアプローチにおける重要な革新は、ロスリー圧縮を行う際に常に単一の絶対色空間を内部色空間として使用することです。元の入力画像がどの色空間を使用していようと、エンコーダはそれをXYBに変換します。ロスレス圧縮とJPEG再圧縮の場合にのみ、XYB空間は使用されません。

常に同じ色空間を符号化に使用する主な利点は、エンコーダが知覚最適化をはるかに正確かつ効果的に適用できることです。なぜなら、エンコーダは符号化する入力データの測色学的解釈を「知って」おり、したがってそれが下す選択の視覚的影響も理解しているからです。知覚的に均一な色空間を内部空間として使用することで、画像全体にわたって視覚的忠実度をバランスよく保つことが容易になります。sRGBやYCbCr変換されたsRGBのような知覚的に均一性が低い色空間の影響によって忠実度が変調されることを防ぐことができます。

CIELABやCIECAM02のような色彩見えモデルや、CIE ΔE* [39] のような色差メトリックで提案されてきた知覚色空間と比較した主な違いは、これらのモデルが通常、2°（またはそれ以上）の視覚角度を占める色刺激（例：物理サンプルや画面上の矩形）を用いた実験に基づいているのに対し、XYB'はピクセルサイズの色のために使用されることを意図している点です。CSSピクセル単位は名目上約0.0213°の視覚角度に対応し、現在のディスプレイは通常2または3のデバイスピクセル比（DPR）を持ち、これは約0.01°のピクセルサイズに対応します。これは、色差メトリックが通常周辺視野を含んでいるのに対し、ピクセルサイズの詳細では中心窩視野が支配的であり、S錐体の寄与がより小さい役割を果たすことを意味します。

5.7 YCbCr色空間の継承

非XYBの場合、フレームヘッダーはRGB（またはCMY）サンプルデータにYCbCr変換が適用されたかどうかをシグナル化します。JPEG XLで使用されるYCbCrの正確なバリアントは、JPEG（より正確にはJFIFとExif、なぜならJPEG標準自体は色変換を規定していないため）で実装されている方法と同一になるように定義されています。

JPEG互換性のための実装と知覚均一性の課題> 

R = Y + 128/255 + 1.402 * Cr  (4)
G = Y + 128/255 - 0.344136 * Cb - 0.714136 * Cr
B = Y + 128/255 + 1.772 * Cb

この色変換がJPEG XLに含まれる主な理由は、ロスレスJPEG再圧縮に必要だからです。ピクセルから画像を符号化する場合、人間視覚システムをよりよくモデル化し、YCbCrよりも知覚的に均一で知覚最適化に適しているため、使用が推奨される色空間はXYBです。図13は、YCbCr色空間（sRGB色空間のRGBサンプルに適用される一般的なケース）を、4つの異なる定数Y値でのCbCr平面を示すことで視覚化しています。もし空間が知覚的に均一であれば、これらの平面はそれぞれ均一に明るく見えるはずです。XYB'色空間（図12）と比較すると、YCbCrの知覚均一性がやや劣っていることは明らかです。これは、sRGB自体が知覚的に均一ではないこと、そしてYCbCrのような単純な線形行列乗算ではそれを修正するのに十分ではないことで説明できます。

5.8 クロマサブサンプリングの詳細

YCbCrが使用される場合、フレームヘッダーはクロマサブサンプリングの使用もシグナル化します。JPEG XLでは、水平方向または垂直方向のいずれか、またはその両方で2倍のサブサンプリングのみが許可されています。これは、4:4:4、4:2:2、4:4:0、および4:2:0のサブサンプリングを表現できることを意味しますが、JPEGでは可能であるものの、主要なJPEGエンコーダ実装がそのような画像を生成することは非常に稀であるため、4:1:1や3倍サブサンプリングは許可されません。この制限の理由は、実装の複雑さと既存のJPEG画像のカバー率とのバランスを取るためです。クロマサブサンプリングを全く許可しないと、JPEG XLの実装は簡素化されますが、多くの既存のJPEG画像をJPEG XLでロスレスに表現できなくなります。任意のクロマサブサンプリング係数を許可すると、カバー率への影響はごくわずかですが、実装の複雑さに大きな影響を与えます。

JPEG XLにおけるクロマサブサンプリングのコーディングツールとしての位置付け>

クロマサブサンプリングは、JPEG XLでは有用な符号化ツールではありません。なぜなら、トップレフトの象限にあるDCT係数を除いて全てのDCT係数をゼロにし、それらの係数を最後にするように再順序付けることで、実質的に同じ結果を得ることができるからです。JPEG XLで使用されるエントロピー符号化では、非常に低いシグナリングオーバーヘッドでこれを行うことが可能です。しかし、一般的には、このような鈍重でグローバルな方法で高周波情報を削除しない方が良いです。

クロマサブサンプリングが画像パディングにどのように影響するか（全てのコンポーネントで整数ブロック数を確保するため）の詳細は、JPEGに対応するように定義されています。これは、JPEGとの互換性を徹底的に追求した結果と言えるでしょう。

5.9 追加チャンネル (Extra Channels)

「メイン画像チャンネル」—グレースケールチャンネル1つ、またはカラーチャンネル3つ—の他に、JPEG XL画像には最大4096個の「エクストラチャンネル」を含めることができます。画像ヘッダーはエクストラチャンネルの数をシグナル化し、各エクストラチャンネルについて以下の情報がシグナル化されます。

チャンネル数の拡張性 (最大4096)>
  • d_alpha (Bool): これは、特に一般的なデフォルト設定のセットをシグナル化します。trueの場合、エクストラチャンネルはアルファ透明度チャンネル（非関連）、8ビット、1:1解像度で名前なしとなり、このチャンネルに対してそれ以上のフィールドはシグナル化されません。
  • type (Enum): エクストラチャンネルの意味論を決定します。様々なタイプを以下に説明します。
  • bit_depth (Bundle): ビット深度と、それが整数か浮動小数点か（浮動小数点の場合は指数ビット数）を示します。
  • dim_shift (integer): エクストラチャンネルは、2^dim_shiftの係数で（両次元で）サブサンプリングされます。特に深度や熱（赤外線）情報を符号化するチャンネルでは、このオプションのサブサンプリングが有用です。
  • name (string): オプションとして、エクストラチャンネルには最大1071バイトの名前（UTF-8エンコード）を付けることができます。この名前は、人間が読みやすい説明を追加したり、特に汎用的なエクストラチャンネルタイプ（NonOptionalとOptional）の場合にアプリケーション固有の命名規則を使用したりするために使用できます。
タイプ依存情報と様々な追加チャンネル>

エクストラチャンネルのタイプに応じて、そのタイプに特有の追加フィールドがシグナル化される場合があります。

  • Alpha: 最も一般的なエクストラチャンネルタイプはアルファ透明度チャンネルに使用されます。慣例として、アルファサンプル値が0は完全な透明性を示し、1は完全な不透明性を示します。範囲外のアルファ値も許可され、フレームヘッダーでシグナル化されるブレンド情報（セクション10.7.2参照）またはPatchesデータ（セクション8.1.2参照）の一部として、ブレンド前に[0, 1]範囲にクランプされるか、ブレンド式がクランプされていない値で適用されるかによって異なる解釈がされます。

アルファチャンネルは、関連（「プレマルチプライド」とも呼ばれる）または非関連のいずれかです。これは、Alphaタイプのエクストラチャンネル情報内の追加のブールフィールドとしてシグナル化されます。関連アルファ（例：OpenEXR画像フォーマット）は、非関連アルファ（例：PNG画像フォーマット）よりも表現力が高いです。なぜなら、蝋燭の炎やガラスの反射など、発光するが透明なピクセルを持つレイヤーをモデル化できるからです。そのようなピクセルは、アルファ値がゼロでカラーコンポーネントが非ゼロに対応します。

複数のアルファチャンネルを持つことができます。最初のアルファチャンネルは、画像をレンダリングするために使用される「メイン」アルファチャンネルと見なされます。

  • Depth: このエクストラチャンネルには、深度情報、つまり画像内の各位置におけるカメラからの（推定）距離が含まれます。このデータは、画像内の前景と背景を分離するため（例：ポストプロダクションで人工的なボケ効果を適用するため）、または1つ以上の2D画像から3Dシーンを再構築するために使用できます。

    • JPEG XLで使用される慣例では、深度チャンネルのサンプル値が高いほど、カメラからの距離が大きいことを示します。使用される正確なスケールは標準化されていません。必要に応じて、アプリケーションはチャンネル命名規則を使用して曖昧さを解消できます。

  • Thermal: エクストラチャンネルタイプ「Thermal」は、赤外線サーモグラフィー画像に使用されます。サンプル値が高いほど、温度が高いことを示します。ここでも、正確なスケールは標準化されておらず、必要に応じてアプリケーションはチャンネル命名規則を使用して曖昧さを解消できます。
  • CFA: デジタルカメラでは、画像データは通常、カラーフィルターアレイ（CFA）、またはベイヤーフィルターモザイクを使用してキャプチャされます。このデータは、CFAタイプのエクストラチャンネルを使用して格納できます。タイプ固有の整数cfa_channelは、エクストラチャンネル情報でシグナル化され、フィルターモザイク内のサブピクセルカラーと位置を識別するためのインデックスとして使用されます。
  • Black (K): CMYK画像の場合、キーコンポーネント（黒インクを示す）はエクストラチャンネルとして表現されます。CMYK画像の場合、CMYK ICCプロファイルの使用は必須です。この場合、RGBチャンネルはシアン、マゼンタ、イエローとして解釈されます。

    • CMYKの場合、サンプル値0は「フルインク」を示し、サンプル値1は「インクなし」を示します。この慣例はCMYK画像で一般的です。なぜなら、カラーモデルが減法混色であるため、オールゼロのサンプル値は黒であり、オールワンのサンプル値は白であるという不変性が、RGBと同様に維持されるからです。

    VarDCTは3つのカラーコンポーネントに「ハードコード」されており、全てのエクストラチャンネルはModular符号化されているため、CMYK JPEG画像に対してロスレスJPEG再圧縮を適用することはできません。原則として、JPEG画像データのCMYコンポーネントはロスレスに表現できますが、Kコンポーネントはサンプル値にデコードされ、そのように格納される必要があり、これは非効率的で完全にロスレスではありません（DCT係数が失われるため）。Kコンポーネントをエクストラチャンネルに個別に格納する必要があること、したがってCMYK JPEG画像に対してロスレスJPEG再圧縮を適用できないことは、JPEG XLの意図的な制限です。その理由は以下の通りです。CMYKが望ましいほとんどのユースケースでは、ロスレス圧縮がロスリー圧縮よりも適しています。つまり、ロスリー圧縮が許容される場合、一般的に画像を（十分に広い色域を持つ）RGB空間で表現することも許容されるでしょう。特に、Kコンポーネントにはしばしばラスター化されたテキストが含まれており、DCTベースの圧縮ではうまく機能しません。したがって、CMYKデータを圧縮する際にModularモードを要求することは、許容可能な制限と見なされました。良い点としては、VarDCTの固定コンポーネント数が、可変数のコンポーネントを扱うことから生じる実装の複雑さを軽減するのに役立ちます。

  • SpotColor: AlphaとBlack (K)チャンネルの他に、SpotColorチャンネルは標準化されたレンダリング影響を持つ唯一のエクストラチャンネルです。これらは、特定のカラーとソリディティを持つモノクロチャンネルです。これらは、まるで追加の定色レイヤーがあり、SpotColorチャンネルがアルファチャンネルであるかのように効果的にレンダリングされます。ソリディティは、アルファブレンドにおける追加の乗数です。

    • これらのチャンネルは、オフセット印刷における非プロセスインク（メタリックインクや蛍光インクなど）や、スクラッチカードの削りカス領域をモデル化するために使用できます。画像をディスプレイにレンダリングするために使用されるカラーは、エクストラチャンネル情報の一部としてシグナル化され、画像色空間に関して色域外のカラーであることもあります。いずれにせよ、このカラーは近似に過ぎないかもしれません。なぜなら、スポットカラーチャンネルは、通常のディスプレイまたは印刷技術では再現できない画像データを表現するのに特に有用だからです。スポットカラー定義の詳細は（Pantone®カラーへの参照など）、アプリケーション固有のチャンネル命名規則を使用して格納できます。

  • SelectionMask: セレクションマスクは関心領域を示します。例えば、画像エディタで「選択」（またはマスク）できる画像の一部であり、選択的にさらなる処理ステップを適用するために使用できます。サンプル値ゼロは、ピクセルが選択の一部ではないことを意味し、サンプル値1は、ピクセルが完全に選択されていることを意味します。中間値は部分的な選択を示し、ファジーマスクや「フェザード」マスクに有用です。
  • NonOptional: 上記で説明されたもの以外のエクストラチャンネルタイプが必要になる可能性があるため、汎用的なエクストラチャンネルタイプ「NonOptional」が利用可能です。このタイプが使用される場合、チャンネル名は、このチャンネルの解釈を識別する命名規則に従います。アプリケーションがこの種のデータの扱い方を知らない場合、それは画像を正しくレンダリングできないことを示します（例：画像の読み込みを拒否したり、警告を表示したりします）。この意味で、データは「必須ではない」のではなく、「必須」です。画像を正しくレンダリングするには、このチャンネルの意味論を理解する必要があります。例えば、Alpha、Black、SpotColorチャンネルで符号化されたレンダリング影響を与えるデータは、それらの標準チャンネルタイプが定義されていなかった場合、NonOptionalチャンネルに格納するのに適切でしょう。
  • Optional: 扱い方を知らないアプリケーションによって安全に無視できる汎用的なエクストラチャンネルには、「Optional」タイプを使用できます。これは、画像の（デフォルトの）レンダリングに影響を与えないデータのためのものです。例えば、Depth、Thermal、SelectionMaskチャンネルで符号化されたデータは、それらの標準チャンネルタイプが定義されていなかった場合、Optionalチャンネルに格納するのに適切でしょう。

    • コラム：色は嘘をつかない、と彼らは言う

    色の科学は奥深く、そして時に哲学的な問いを投げかけます。「真の色とは何か？」。私たちは、ディスプレイが表示する色を「真実」と信じがちですが、その裏には複雑な変換と妥協が存在します。JPEG XLは、XYB色空間という、人間の視覚システムをシミュレートした「絶対色空間」を導入することで、この「真実」に一歩近づこうとします。まるで、我々の網膜をハッキングし、色の本質を直接捉えようとしているかのようです。

    しかし、私はいつも思うのです。技術がどんなに「真実」を追求しても、最終的に色を知覚するのは、それぞれの人間個人の網膜と脳です。私たちは皆、少しずつ異なる色を見ている。JPEG XLが提供する「完璧な」色も、見る人によっては「違う」と感じるかもしれない。技術は客観性を追求しますが、芸術は主観性によって成り立っている。この両者の間の永遠の溝は、埋まることはないのでしょう。

    とはいえ、JPEG XLがCMYKやスポットカラーといった印刷業界のニーズ、さらには医療や科学といった厳密な再現性が求められる分野にまで対応しようとしているのは、評価に値します。まるで、「どんな色も、どんな用途も、俺に任せろ！」と言わんばかりの、その「全能感」が、時にシニカルな笑いを誘うこともありますが、その野心こそが技術進化の原動力なのでしょう。

    第六章：モジュラーサブビットストリームの探求

    JPEG XLの核心の一つに、モジュラーサブビットストリームという「万能ナイフ」のような存在があります。これは、ほとんどの画像データを符号化するために使用され、その柔軟性と効率性において、他の追随を許しません。まるで、どんな料理にも使える究極の食材のように、JPEG XLの様々な機能を支えています。

    6.1 モジュラーモードの適用範囲

    JPEG XLにおけるほとんどの種類の画像データ、本質的にはメタデータと高周波（HF）VarDCT係数を除く全てが、Modularサブビットストリームを使用して符号化されます。画像フレームは、全ての画像データに対してModularサブビットストリームのみを使用して符号化することもできます（「Modularモード」）。あるいは、VarDCTを使用して符号化することもできますが、その場合でもそのシグナリングの多くはModularサブビットストリームに依存しており、主要な例外はHFデータ（これが画像データの大部分を占めます）であり、これには専用の符号化スキームがあります。「モジュラー」と呼ばれる理由の一部は、この符号化モードが全体的なコーデックの「サブモジュール」として効果的に使用されているためです。

    ロスレス圧縮とロスリー圧縮の併用>

    Modularサブビットストリームは、整数の2次元配列のセット（チャンネルと呼ばれる）を符号化できます。これらのチャンネルは、カラーコンポーネントとエクストラチャンネル、LF係数、カラーパレット、量子化テーブル、ブロックタイプ選択、適応量子化重み、クロマからのルマ乗数、ローカルフィルター強度、またはこれらのいずれかを1つ以上のモジュラー変換を適用した結果に対応できます。

    チャンネルの数、寸法、意味論は、Modularサブビットストリームで明示的にシグナル化されるのではなく、画像およびフレームヘッダー情報、およびModularサブビットストリームが「呼び出される」コードストリームの特定のセクションから暗黙的に導き出されます。例えば、ロスレス圧縮されたRGBA画像の場合、単一のModularサブビットストリームは、それぞれ256x256（デフォルトのModularグループサイズ）の4つのチャンネルに対応し、赤、緑、青、アルファの意味論を持つことができます。

    6.2 モジュラー変換の連鎖

    Modular符号化を使用する場合、画像データを符号化する前に、一連の変換が適用されることがあります。これらの変換はシグナル化され、デコーダは画像をデコードする際に対応する逆変換を適用します。シグナル化された変換チェーンを持つことで得られる柔軟性、すなわち「モジュール性」が、Modular符号化モードの名前のもう一つの理由です。

    変換チェーンの概念とデコーダでの逆変換>

    例えば、ある変換がRGBAをYCoCgAに変換するRCT変換であるとします。その後の変換で、2つのクロマチャンネルにパレット変換が適用されるかもしれません（画像で使用されているCoとCgの一意の組み合わせが100個しかない場合など）。符号化されたデータには、以下の順序で格納されます。1) (Co,Cg)色のパレットを表す100x2の「メタチャンネル」、2) 256x256のルマ（Y）チャンネル、3) パレットを参照する[0,99]範囲のサンプルを持つ256x256のインデックスチャンネル、そして最後に4) 256x256のアルファチャンネルです。

    RCT（Reversible Color Transforms）：可逆色変換>

    可逆色変換（RCTs）は、カラーチャンネル（または相関するエクストラチャンネル）の相関を解除するのに有用です。この変換は、同一寸法の任意の3つの連続するチャンネルを取り込み、それらを任意の方法で順列した後、7つの可逆変換のいずれかを適用します。合計で7x3! = 42種類の異なるRCTsが存在します。RCT変換は、変換が適用される3つのチャンネルの最初のチャンネルのインデックスであるbegin_cパラメータと、適用するRCTを識別するrct_typeパラメータを持ちます。例えば、初期のチャンネルがR,G,B,Aでbegin_cがゼロの場合、変換はR,G,Bチャンネルに適用されます。begin_cが1の場合、G,B,Aチャンネルに適用されます。

    3つのチャンネルRGBから出発し、rct_typeを7で割った値（切り捨て）が順列を示します。0はノーオペレーション（RGB）、1はGBR、2はBRG、3はRBG、4はGRB、5はBGRに対応します。除算の余り（rct_type % 7）が、順列後に適用する変換を示します。

    • 0 (no-op): (A, B, C) → (A, B, C)
    • 1: (A, B, C) → (A, B, C-A)
    • 2: (A, B, C) → (A, B-A, C)
    • 3: (A, B, C) → (A, B-A, C-A)
    • 4: (A, B, C) → (A, B - floor((A+C)/2), C)
    • 5: (A, B, C) → (A, B - floor((A+C)/2), C-A)
    • 6 (YCoCg-R): (A, B, C) → (t + floor((B-t)/2), A-C, B-t) ここでt = C + floor((A-C)/2)

    例えば、rct_type 10はまずRGBをGBRに順列し、次に変換番号3を適用するため、全体的な効果は(R,G,B) → (G, B-G, R-G)となります。これは「SubtractGreen」変換としても知られています。

    YCoCg-R変換は、(R,G,B)を約(R+2G+B)/4, R-B, G-(R+B)/2にマッピングします。つまり、ルマコンポーネントYはRGBの(0.25, 0.5, 0.25)加重和に対応し、Coは「オレンジ-ブルー」クロマコンポーネント、Cgは「グリーン-パープル」クロマコンポーネントに対応します。

    図：YCoCg-R色空間の可視化 (概念図)
    YCoCg-R色空間は、YCbCrと似ていますが、知覚的に均一な特性を持つ。
色相をCo（オレンジ-ブルー軸）とCg（グリーン-マゼンタ軸）で表現。

Co軸
  |
--Cg--
  |
Y軸 (輝度)

    ※図15のYCoCg-R色空間の可視化を簡易的に表現。知覚均一性が高く、ロスレス圧縮に適しています。

    図：色分解の例 (概念図)
    元の画像
---------
|       |
|  [R]  |
|  [G]  |
|  [B]  |
|       |
---------

RGB分解 (相関が高い)
[R] [G] [B]

YCoCg-R分解 (相関が低い、ロスレス向き)
[Y] [Co] [Cg]

XYB分解 (知覚に基づき相関が低い、ロスリー向き)
[Y] [X] [B']

    ※図16の例。RGBは3つのチャンネルが互いに強く相関しているため、そのまま圧縮すると効率が悪い。YCoCg-RやXYBのような変換を適用することで、チャンネル間の相関を低減し、圧縮効率を高めることができます。

    YCbCrと同様に、YCoCg-RはXYB'ほど知覚的に均一ではありませんが、YCbCrやXYB'とは異なり、2ビットの追加精度しか必要としない整数演算で可逆であるという利点があります。RGBサンプルがnビットの場合、YCoCg-Rを適用した後、結果として得られるY値は依然としてnビットですが、CoとCgの値は、範囲が[0, 2^n-1]から[-2^n+1, 2^n-1]に拡張されるため、それぞれn+1ビットを必要とします。

    ノーオペレーション変換は、チャンネルの順序を変更するために使用できます。これは、コンテキストモデルと予測器を定義するMAツリーで「PrevChannel」プロパティが使用される場合に役立ちます（セクション6.3.1を参照）。つまり、圧縮を改善する上で有利になる可能性があります。複数のRCT変換を連結できるため、任意の数のチャンネルに対して任意の順列を実行できます。

    (Delta)Palette（パレット変換）：色彩の辞書と予測>

    JPEG XLのModular符号化におけるパレット変換は、GIF、PNG、ロスレスWebPで利用可能なカラーパレット概念の一般化です。これらの古い画像フォーマットでは、パレットは最大256の異なる色しか持てず（つまり、インデックスはバイト内に収まります）、色は3または4コンポーネント（RGBまたはRGBA）でした。JPEG XLのパレット変換は、同一寸法の連続する任意の数のチャンネル（k個）を受け取り、それらを同じ寸法の単一のインデックスチャンネルに置き換えます。さらに、n x k寸法の追加のパレット「メタチャンネル」が追加されます。ここでnは色の数（256より大きくても構いません）です。色の最大数は、変換記述構文によって70911に制限されています。

    図：暗黙のパレット (概念図)
    [4x4x4キューブ内の最初の64色]

R G B
-------
0 0 0
0 0 1
...
3 3 3
-------

[5x5x5キューブ内の次の125色]

R G B
-------
0 0 0 (内側3x3x3の色は省略)
...
4 4 4
-------

    ※図17の暗黙のパレットの概念図です。JPEG XLでは、明示的にシグナル化しなくても、RGB空間を均等にサンプリングした事前定義された色が利用可能です。

    チャンネルパレット: 特に、パレット変換は単一のチャンネルに適用することができ、符号化されたインデックスの範囲を縮小するのに役立ちます。例えば、画像は名目上16ビットのビット深度を持つかもしれませんが、実際には3000個の異なるサンプル値しか含まれていない場合があります。その場合、メインデータが[0, 2999]の範囲にある場合、[0, 65535]の範囲に散らばっている場合よりも、エントロピー符号化が大幅に改善されます。

    暗黙パレット: さらに、189個の事前定義された暗黙の色がパレットに追加されます。これらは、均一にRGBボリュームをサンプリングする4x4x4キューブと5x5x5キューブ（内側の3x3x3色は明確さのために省略）が交互に配置されたものです。これらの色は明示的にシグナル化する必要がありません。範囲外のインデックス（つまりn以上のインデックス）が使用される場合、それらはこの暗黙パレットを参照します。この暗黙パレットのおかげで、パレット変換はn=0の場合、つまり明示的にシグナル化されたパレット色がない場合でも有用です。

    デルタパレット: オプションとして、n個のパレット色の最初のd個を「デルタエントリ」として解釈できます。これは、シグナル化された「色」の値が固定の色を表すのではなく、現在のピクセル位置の予測サンプル値に適用される差分ベクトルとして機能することを意味します。dの数と予測器の選択の両方がシグナル化されます。例えば、デルタエントリとして解釈された場合、「色」(0,0,0)は黒に対応するのではなく、再構築された隣接サンプルに基づく予測サンプル値に、変更を加えずに対応します。別の例として、デルタエントリ(-5,0,3)は、最初のコンポーネントでは予測値から5が差し引かれ、2番目のコンポーネントでは予測がそのまま使用され、3番目のコンポーネントでは予測値に3が追加されることを意味します。

    図：暗黙のデルタパレットエントリ (概念図)
    各デルタエントリは、予測色に加算される差分ベクトルに対応。
ここで示される色は、予測色がグレーだった場合の結果色を表す。

[例]
(0,0,0)  -> 予測色そのまま
(-5,0,3) -> 予測R-5, 予測G, 予測B+3
...

    ※図19の暗黙のデルタパレットエントリの概念図です。これにより、色空間における細かい変化を効率的に表現できます。

    WebPフォーマットもデルタパレット機能を組み込んでいますが、その実装はより制約的です。ロスレスWebPの仕様では、特定のパレットはデルタ値のみまたは絶対色値のみで構成される必要があり、両方のタイプのエントリを含むハイブリッドパレットはその形式では許可されません。ウエスト（またはレフト）予測器と組み合わせて使用される場合、デルタパレットメカニズムは1980年代後半にCommodore Amiga用に開発されたHold-And-Modify (HAM) ディスプレイモードと機能的に類似しています。この予測符号化技術は、西隣接ピクセルの色値を取り込み、パレットからデルタ修正を適用して現在のピクセルの色を導き出します。この「ホールド・アンド・モディファイ」の原則は、HAMモードが以前のピクセルの値を保持し、そのカラーチャンネルの1つを修正する方法と概念的に似ています。デルタパレットモードの開発を導くために実施された経験的評価では、エラーディザリングと組み合わせてAvgAll予測器を使用した場合に最適な圧縮性能が観察されました。予測器の最適な選択はコンテキスト依存的であることに注意が必要です。例えば、ロスレスWebP仕様内でデルタパレット符号化を実験的に実装した場合、AvgW+N予測器を使用した場合に優れた性能が得られました。これは、デルタ符号化されたパレットの理想的な予測戦略が、コーデックの特定のアーキテクチャ詳細に基づいて変化する可能性があることを示唆しています。

    暗黙デルタパレット: 最後に、暗黙デルタパレットエントリも存在します。インデックスチャンネルに負のインデックスが含まれる場合、それらは143個の暗黙デルタエントリのいずれかを参照します。図19は、暗黙デルタエントリのセットを示しています。

    デルタパレットエントリは、「pngquant」のようなロスリーパレットベースのアプローチの表現力を大幅に向上させます。従来のパレット符号化では、色の数が限られているため、画像に緩やかなグラデーションが含まれる場合に（ディザリングなしではカラーバンディングが非常に目立つため）より満足のいく結果を得るためにディザリング手法を使用する必要があります。しかし、ディザリングはパレット符号化によって得られる圧縮ゲインの一部を打ち消す傾向があります。デルタパレット符号化は、多くの場合、滑らかなグラデーションをうまく予測できる予測器を活用するためにデルタエントリを使用することで、グラデーションをはるかに正確に再現することを可能にします。

    Squeeze（スクイーズ変換）：階層的分解とプログレッシブ>

    Squeeze変換は、明示的にシグナル化されるか、または事前定義されたデフォルトの順序に対応する一連のSqueezeステップで構成されます。各ステップでは、チャンネルが2つの新しいチャンネルに置き換えられます。これらの新しいチャンネルは、いずれかの次元が半分になります。つまり、水平または垂直次元が2で割られます。これらの新しいチャンネルの1つは、画像のダウンサンプリングバージョン（アスペクト比が変わるため「スクイーズされた」）を含み、もう1つはダウンサンプリングされた画像と組み合わせることで完全な解像度の画像を再構築できる残差を含みます。図21は、デフォルトのSqueezeパラメータの結果を示しています。これは、スクイーズされたチャンネルに（残差チャンネルにはではなく）繰り返しSqueezeステップ（交互の方向で）を適用するものです。

    図：Squeeze変換の概念図
    前方Squeeze変換（デフォルトパラメータ）
元の画像
  ↓
残差チャンネル１（水平方向の圧縮）
  ↓
残差チャンネル２（垂直方向の圧縮）
  ↓
...
  ↓
最終的なスクイーズされた画像

逆Squeeze変換
最終的なスクイーズされた画像
  ↓（残差チャンネルを組み合わせて）
中間結果
  ↓
元の画像

    ※図21のSqueeze変換の概念図です。画像を段階的にダウンサンプリングし、各ステップでの残差を保存することで、高圧縮率とプログレッシブデコードを実現します。

    ダウンサンプリングされた画像は平均化によって得られます。つまり、サンプル値AとBの2x1または1x2ブロックの場合、値は(A+B)/2です。これが整数でない場合、A > Bであれば切り上げられ、それ以外の場合は切り捨てられます。この丸めルールは、固定丸めを使用した場合に発生するバイアス（ダウンサンプリングされた画像をわずかに暗くしたり明るくしたりする）を軽減します。また、デコード時にAとBを簡単に再構築できることも保証します。適切に丸められた平均にfloor((A-B)/2)を加えるとAが得られます。

    Tendency term: 残差は単純にA-Bではありませんが、A-Bの値は残差から導き出すことができます。単に差分を残差として使用すると、高周波残差が量子化された場合にピクセル化された画像になってしまいます。代わりに、残差から「傾向項」が差し引かれます。これは、以前に再構築された最近傍サンプルa（水平スクイーズステップの場合は左、垂直スクイーズステップの場合は上）と、現在の位置と次の位置（右または下）のダウンサンプリングされた画像内のサンプル値bとcに基づいています。これは、条件付きで制約された（したがって非線形な）線形補間と見なすことができます。サンプルa, b, cのシーケンス（ここでb = (A+B)/2）が単調増加（a ≤ b ≤ c）または単調減少（a ≥ b ≥ c）の場合、傾向項は補間された差分に対応し、単調性（つまり、a ≤ A ≤ B ≤ c、またはa ≥ A ≥ B ≥ c）を尊重する値に制約されます。しかし、シーケンスがそうでない場合、つまりbが局所的な最大値（a < b > c）または最小値（a > b < c）の場合、傾向項はゼロです。

    図：Tendency Termにおけるサンプル位置 (概念図)
    現在のピクセルを予測するために使用される周辺ピクセル（a, b, c）の位置関係。

N NW N NE NEE
W W C E

    ※図20は、水平方向のSqueeze変換の場合における、Tendency Term計算のためのサンプル位置を示します。これにより、補間時のオーバーシュート／アンダーシュートを防ぎます。

    図：線形補間と非線形傾向項の比較 (概念図)
    線形補間
A----B----C （直線的な予測）

非線形傾向項
A----B----C （単調性を保ち、オーバーシュートを避ける）

    ※図22の例。通常の線形補間は、ピクセル値が急激に変化する場所でオーバーシュートやアンダーシュートを引き起こし、結果としてリンギングアーティファクトを生じさせる可能性があります。JPEG XLの非線形傾向項は、この問題を回避し、より自然な補間を実現します。

    図：Squeeze変換におけるTendency Termの効果 (概念図)
    1. 傾向項なし：ブロック状、ピクセル化が目立つ
   ████████
   ████████
   ████████

2. 無条件線形補間傾向項：ピクセル化は避けられるが、リンギングアーティファクト
   〜〜〜〜
   〜〜〜〜

3. JPEG XLの非線形傾向項：アーティファクトがバランスされ、より自然
   ════════
   ════════

4. 元の画像（参照）
   ----------
   ----------

    ※図23は、Squeeze変換でテンデンシー項がどのように画質に影響するかを示します。非線形テンデンシー項は、ピクセル化とリンギングの両方を軽減し、より視覚的に忠実な結果を生成します。

    傾向項における非線形性の利点は、図23に示されています。ここでは、画像が攻撃的に0.4 bppに圧縮されており、Squeezeの2つのバリアント（傾向項なし、無条件線形補間）と、JPEG XLで定義されているSqueezeを使用しています。最初のバリアントでは、ピクセル化または「ブロックノイズ」が明らかです。2番目のバリアントでは、ピクセル化は避けられますが、強いエッジでリンギングアーティファクトが発生します。非線形傾向項を使用すると、アーティファクトはよりバランスが取れ、ピクセル化とリンギングの両方を軽減できます。

    6.3 チャンネル符号化の詳細

    （おそらく変換された）画像データは、インターリーブされた（ピクセルごとの）方法ではなく、平面的な、チャンネルごとの方法で符号化されます。各チャンネルは通常のスキャンライン順序（行ごとに、各行で左から右へ）で走査されます。しかし、単一のModularサブビットストリームで符号化されるデータは、通常、画像の256x256領域のみに対応し、単一のグループに対応します（セクション10.1を参照）。

    符号化される各サンプル値について、MAツリーと呼ばれる決定木が走査され、使用する予測器、残差に適用する乗数とオフセット、およびエントロピー符号化に使用するコンテキストが決定されます。以下の擬似コードはデコードプロセスを記述しています。

    
for (i = 0; i < channel.size(); i++) {
  for (y = 0; y < channel[i].height; y++) {
    for (x = 0; x < channel[i].width; x++) {
      props = GetProperties(i, x, y);
      node = MA_tree_root;
      while (node.is_decision_node()) {
        if (props[node.property] > node.value)
             node = node.left_child;
        else node = node.right_child;
      }
      diff = DecodeHybridUint(node.context);
      diff = UnpackSigned(diff);
      diff *= node.multiplier;
      diff += node.offset;
      guess = Predict(node.predictor, i, x, y);
      channel[i].sample(x, y) = guess + diff;
    }
  }
}

    ローカルプロパティの配列（props）はセクション6.3.1で説明されています。これらのプロパティは、MAツリーの決定ノードで参照されます（セクション6.3.2）。エントロピー符号化（DecodeHybridUint）については、後ほど第九章で議論します。様々な予測器については、セクション6.3.3とセクション6.3.4で説明します。

    プロパティ：予測とコンテキストの源泉>

    隣接するすでに符号化されたサンプル値には、以下の名前が使用されます。

    
NN NW N NE NEE
WW W C

    ※これは、現在のサンプル（C）の周囲の既知のサンプルを表す概念図です。NN（North North）、NW（North West）、N（North）、NE（North East）、NEE（North East East）、WW（West West）、W（West）を示します。

    エッジケースを処理するため、最初のサンプルでは全ての隣接がゼロと仮定されます。それ以外の場合、Wが欠落していればNが代わりに使用され、N、NW、WWが欠落していればWが代わりに使用され、NEまたはNNが欠落していればNが代わりに使用され、NEEが欠落していればNEが代わりに使用されます。

    図24は、MAツリー決定ノードで参照できる全てのローカルプロパティを示しています。

    Index Property value
    0 i (channel index)
    1 stream index
    2 y (row number)
    3 x (column number)
    4 |N|
    5 |W|
    6 N
    7 W
    8 W - (previous value of property 9)
    9 W + N - NW
    10 W - NW
    11 NW - N
    12 N - NE
    13 N - NN
    14 W - WW
    15 max_error (セクション6.3.4参照)
    16 |PrevChannel|
    17 PrevChannel
    18 |PrevChannelErr|
    19 PrevChannelErr
    20 |Prev2Channel|
    21 Prev2Channel
    22 |Prev2ChannelErr|
    23 Prev2ChannelErr
    23 (重複) |Prev3Channel|
    ... ...

    これらのプロパティの一部は、内部符号化ループ内で静的であるため、最適化された実装では、これらのプロパティを含むテストでの不要な分岐を避けるためにツリーを特化する価値があります。例えば、ストリームインデックス（プロパティ1）は各Modularサブビットストリームの一意な識別子であり、サブビットストリーム全体で一定のままです。チャンネルインデックスi（プロパティ0）と行番号y（プロパティ2）も内部ループ中に変更されません。

    2つの最も近い（利用可能な）隣接であるNとWは、直接（プロパティ6と7）またはその絶対値を使用して（プロパティ4と5）参照できます。サンプル値が全て正の場合、これはもちろん冗長ですが、多くの場合、サンプル値は符号付きでゼロを中心にしているため、例えばチャンネルがクロマチャンネル（XYBまたはRCTが使用された場合）に対応する場合や、Squeeze残差に対応する場合に役立ちます。これらの場合、MAツリーで低振幅値と高振幅値を区別するのに、単一のテストで絶対値と比較できるのは有用です。

    プロパティ9は、クランプされていない「グラディエント」予測器であり、現在のピクセルに対する単純ながら効果的な予測です。プロパティ8は、前の位置での「予測ミス」に対応します。

    プロパティ10から14は、FFV1 [49] のコンテキストモデルで使用される隣接差分と同一です。ただし、FFV1ではこれらの差分は量子化されるのに対し、ここではそのまま使用されます。

    max_error（プロパティ15）の値は、自己修正予測器（セクション6.3.4）に関連します。

    残りのプロパティは、以前に符号化されたチャンネルを参照します。libjxlでは、これらのプロパティはデフォルトでは使用されません。なぜなら、メモリ局所性が大幅に低下し、速度（エンコードとデコードの両方）が低下するからです。ただし、これらのプロパティは圧縮を改善するのに役立つことがよくあります。PrevChannelは、現在のサンプルと同じ位置にある、現在のチャンネルと同一の寸法を持つ以前に符号化されたチャンネルのサンプル値です。PrevChannelErrは、クランプされたグラディエント予測器に対する予測ミスに対応します。Prev2ChannelはPrevChannelと同じですが、その前のチャンネルについてのもので、以下同様です。

    このようにして、以前に符号化された任意のチャンネル（同一寸法を持つ）をコンテキストモデルの一部として使用できます。これは、チャンネルの順序が重要であることを意味します。なぜなら、すでに符号化されたチャンネルのみを参照できるからです。このため、RCT変換は、単にチャンネルを順列するだけの変換を可能にします。これらの「以前のチャンネル」プロパティがなければ、このような順列のみのRCTsは目的を果たさないでしょう。

    MAツリー（Meta-Adaptive tree）の構造と情報>

    メタ適応型（MA）ツリーは、コンテキストと予測器の両方を決定するための決定木として解釈される二分木です。Modularサブビットストリームでは、サブビットストリームの冒頭で「ローカルMAツリー」がシグナル化されるか、以前に符号化された「グローバルMAツリー」が再利用されます。エンコーダはどちらのアプローチも使用できます。原則として、単一のグローバルツリーは、多くのローカルツリーを持つ場合と同じくらい表現力が高いです。なぜなら、ストリームインデックスは参照できるプロパティの一つだからです。したがって、異なるローカルツリーは、各ストリームインデックスに対して異なる分岐を作成する決定ノードから始まるグローバルツリーのサブツリーとして表現できます。しかし、エンコーダは全ての入力を受け取る前に出力を生成し始めたい場合や、異なるModularサブビットストリームを並列処理したい場合があります。これらの場合、ローカルツリーの方が便利で効率的です。

    MAツリーは次のように機能します。決定ノード（全ての内部ノード）は全て同じ形式です。「プロパティ番号iの値が閾値vより大きいか？」。答えがはいの場合、左分岐がたどられ、そうでない場合、右分岐がたどられます。シグナリングの観点からは、ツリーは幅優先で走査されます。決定ノードについては、プロパティインデックスiと閾値vのみを明示的に符号化する必要があり、両分岐へのポインタは暗黙的に残すことができます。

    リーフノードには以下の情報が含まれます。

    • context: エントロピー符号化に使用されるコンテキストのインデックス。これは明示的にシグナル化されるのではなく、リーフノードの列挙順序に単純に対応します。その後、コンテキストマップ（セクション9.6.1参照）がこれらのインデックスを再マッピングするため、再マッピング後、異なるリーフが同じコンテキストを共有できます。
    • predictor: どの予測器を使用するか。図25は利用可能な14の予測器を示しています。
    • multiplier: 残差に乗算される定数で、予測値に追加（またはエンコーダでは差し引かれる）されます。これらの乗数は量子化係数のように機能し、エンコーダによってそのように使用できます。
    • offset: 最終バージョンをさらに変更する加算定数。このメカニズムは、特定のコンテキストにおける残差の分布にグローバルなシフトまたはバイアスを適用するのに役立ち、異なるリーフノード間でコンテキストを共有する機会を改善し、ヒストグラムシグナリングオーバーヘッドを削減する可能性があります。
    図：Modular符号化における予測器の例 (概念図)
    Predictor	Name
0	Zero
1	West
2	North
3	AvgW+N
4	Select
5	Gradient
6	Weighted
7	NorthEast
8	NorthWest
9	WestWest
10	AvgW+NW
11	AvgN+NW
12	AvgN+NE
13	AvgAll

    ※図25の予測器一覧を簡易的に表現。

    図：予測器の振る舞い例 (概念図)
    初期パターンに対して、様々な予測器がどのように画像を「補完」するかを示す。
（予測残差が全てゼロと仮定した場合）

Zero:   全てを黒で埋める
West:   左のピクセルをコピー
North:  上のピクセルをコピー
AvgW+N: 左と上の平均
Select: 左と上のうち、グラディエントに近い方
Gradient: 線形グラディエントを予測
Weighted: 自己修正しながら予測
...

    ※図26は、様々な予測器がどのように初期の画像パターンを継続するかを概念的に示します。予測残差が全てゼロの場合、これらの予測器は異なる視覚的パターンを生成します。

    図：libjxlエンコーダのEffort設定とModular符号化の関係 (概念図)
    Effort 2: 固定予測器と固定MAツリー (最小圧縮、高速)
Effort 3: (同上)

Effort 4: 2つの予測器と構築されたMAツリー (改善)
Effort 7: (同上、より複雑なツリー)

Effort 11: 全ての予測器を使用 (最大圧縮、低速)

    ※図27の概念図。エンコーダのEffort設定を変えることで、圧縮率と速度のトレードオフが変化し、MAツリーの複雑さや利用する予測器の種類も変わります。

    図27は、異なるlibjxlの努力設定に対応する、MAツリーの異なる5つの例を示しています。努力設定は2から3では固定の予測器と固定のMAツリーを使用し、努力設定4と7では2つの異なる予測器と構築されたMAツリーを使用し、努力設定11では可能な全ての予測器を使用しています。MAツリーのリーフノードは予測器に対応する色で塗りつぶされ、コンテキストに対応する境界線で囲まれています。

    予測器の種類と特性>

    異なる予測器は図25に示されています。これらの予測器が、もし大きな画像領域を「埋める」ために使用された場合、どのように振る舞うかの例が図26に示されています。

    最初の4つ（Zero, West, North, AvgW+N）は単純で、PNGで利用可能なフィルター（None, Sub, Up, Average）と（少なくとも8ビットの場合には）同一です。West予測器はJPEGがDC予測に使用し、TIFFでもよく使用されるものです。

    Select予測器はロスレスWebPに由来し、PNGのPaethフィルターの単純化されつつも改善されたバージョンと見なすことができます。これは、WとNのどちらが（クランプされていない）グラディエント予測器W+N-NWに最も近いかに応じて選択し、同点の場合はNを使用すると解釈できます。圧縮結果の観点からは、この予測器はPaethを上回る傾向があります。おそらく、常に直接の隣接を返すため、NWを第3のオプションとして持つPaethよりも優れている可能性があります。また、より効率的に実装することも可能です。

    （クランプされた）Gradient予測器は、FFV1や非インターレースFLIF、ロスレスJPEGやWebPでも使用されています（ただし、クランプなし、または異なるクランプを使用）。この予測器には、局所的な近傍が滑らかな線形グラディエントにどの方向でも対応する場合、予測が正しいという良い特性があります。Select予測器が主に少数の異なる色を持つ非写真画像に有用であるのに対し、Gradient予測器はより一般的に適用可能で、滑らかな色の変化を含む画像にもうまく機能します。クランプは、W+N-NW、W、Nの中央値を返すことと同じです。これはFLIFとFFV1で定義されている方法であり、「中央値予測器」と呼ばれています。このクランプにより、予測値が元の範囲内に確実に留まるようになります。ロスレスWebP（8ビットサンプル値のみを処理）では、値は単純に[0, 255]の範囲にクランプされます。

    Weighted（またはSelf-correcting）予測器はかなり複雑です。これは特に写真画像でうまく機能します。これについては次のセクションで説明します。

    次の3つの予測器 — NorthEast、NorthWest、WestWest — は、画像全体で使用できる汎用予測器としてはあまり有用ではありません。結局のところ、これらはより遠い隣接に対応しており、より近い隣接を使用することもできたでしょう。しかし、メタ適応型コンテキストモデルと組み合わせることで、有用になる可能性があります。MAツリーは、これらの予測器の使用を、特定のケース（例：支配的な局所画像特徴が対角線である領域（NW, NE）や、ディザリングパターンや他の「ドット状」ピクセルレベルの詳細が一般的な領域（WW））に制限することができます。

    最後に、中間角度での対角線予測と見なせる3つの単純な平均予測器と、比較的遠いサンプル（サンプルグリッド距離2のNNとWW）および5のNEEを含む、より大きな6つの隣接ピクセルセットに基づく「AvgAll」予測器があります。AvgAll予測器は、デルタパレット変換と組み合わせて使用するために特別に設計されました。

    自己修正予測器のメカニズム>

    予測器番号6は、「重み付き」または「自己修正」予測器として知られています。他の予測器とは異なり、状態（隣接するすでにデコードされたサンプルの値にアクセスするだけでなく）を維持する必要があります。これが必要とする状態は、行の長さに比例します。この状態には、現在の行（現在のサンプルの左側）と上の行の両方で、以前に符号化されたサンプルの予測誤差（予測値と実際の値の差）が含まれます。

    この予測器は、4つの異なるサブ予測器に基づいています。それが返す最終的な予測は、これらのサブ予測器の重み付き和であり、重みは各サブ予測器の局所的な過去の性能に依存します。このため、予測誤差の絶対値は、各サブ予測器に対して個別に維持されます。また、最終的な重み付き予測に対する符号付き誤差も維持され、これは予測誤差の一部をサブ予測器自体にフィードバックするために使用され、それらを「自己修正」させます。

    サブ予測器、重み付き予測、および絶対または符号付き予測誤差は、3ビットの追加精度で計算されます。つまり、全てのサンプル値はまず8倍され（sample << 3）、最終的な予測結果は再び8で割られ、最も近い整数に丸められます（半数を切り下げ、(prediction + 3) >> 3）。表記の簡潔さのため、X'を8 * X、X''をfloor(X + 3 / 8)とします。

    セクション6.3.1と同様に隣接サンプル名を使用し、現在の位置での予測をp、現在の位置での（符号付き）予測誤差をe = p - C'とします。eNのような表記は、対応する位置での予測誤差、つまりeN = pN - N'を表すために使用されます。4つのサブ予測器s0, s1, s2, s3は以下のように定義されます。

    
s0 = W' + NE' - N'  (5)
s1 = N' - floor(w1 * (eW + eN + eNE) / 32)  (6)
s2 = W' - floor(w2 * (eW + eN + eNW) / 32)  (7)
s3 = N' - floor(u + w6 * (NN' - N') + w7 * (NW' - W') / 32)  (8)
where u = w3 * eNW + w4 * eN + w5 * eNE

    重みw1, ..., w7は、Modularサブビットストリームのヘッダーの一部としてシグナル化されます。デフォルト値（単一ビットで安価にシグナル化）はw1=16, w2=10, w3=w4=w5=7, w6=w7=0ですが、任意の5ビット値を使用することもできます。

    各サブ予測器siについて、重みαiが計算されます。これは、隣接位置W, WW, NW, N, NEにおけるサブ予測器の絶対誤差の合計に反比例します。この計算には、各サブ予測器で異なり、Modularサブビットストリームのヘッダーでシグナル化されるグローバルな4ビット乗数も含まれます。これは、4つのサブ予測器間のバランスをグローバルに調整するために使用できます。

    最終的な予測pは、重み付き和として計算されます。

    
p ≈ sum(αi * si) / sum(αi)  (9)

    ここで、実際の整数除算操作（αiの値を計算するための4つの除算、重み付き和のための1つの除算）の使用は回避されます。なぜなら、それによってこの予測器を効率的に実装することが困難になるからです。整数除算は通常、CPU命令の中で最も遅いものの1つです。代わりに、この計算は、実際の整数除算なしに、算術シフトと小さなルックアップテーブルのみを使用して実装できる近似的な方法で行われます。

    チャンネル符号化の目的で使用される予測はp''です。つまり、追加の3精度ビットは再び削除されます。しかし、予測誤差を計算してサブ予測器にフィードバックする目的では、追加精度が使用されます。

    コラム：予測という名の「欺瞞」と、その効用

    Modularモードの肝は、いかに正確に「次のピクセル」を予測するか、という点に尽きます。まるで、未来を予知する巫女のように、過去のデータから次に何が来るかを推測する。そして、その予測が当たれば当たるほど、残差（予測との差）は小さくなり、結果としてデータは劇的に圧縮されるわけです。

    しかし、この「予測」という行為は、ある意味で「欺瞞」とも言えます。なぜなら、私たちは元のデータをそのまま保存しているのではなく、「予測の失敗」だけを記録しているからです。この論文が詳述するMAツリーや自己修正予測器は、その「欺瞞」を限りなく精緻化するための狂気的な努力の結晶です。まるで、人間の脳が過去の経験から未来を予測するメカニズムを、アルゴリズムで再現しようとしているかのようです。

    特に興味深いのは、FLIFの思想を受け継ぎつつ、デコード速度のボトルネックを解消した点です。どんなに優れた圧縮技術も、デコードが遅ければ実用性はない。この冷徹な現実を前に、彼らは「重い計算はエンコード時にやればいい」という、ある種の割り切りを見せました。この実用主義こそが、JPEG XLが単なるアカデミックな成果に終わらない、真の力を持つ所以なのでしょう。予測は時に裏切るかもしれませんが、その予測の精度を極めることで、私たちはより豊かな視覚体験を得ることができる。なんとも人間的で、そしてニヒルな結論ではありませんか。

    第七章：VarDCTモード：可変DCTの極致

    JPEGの象徴とも言える離散コサイン変換（DCT）。しかし、その固定された8x8ブロックという枠組みは、現代の高精細画像にとっては「足枷」でしかありませんでした。JPEG XLのVarDCTモードは、このDCTを「可変」という概念で解放し、画素の深淵に潜む微細な構造までも効率的に捉えようとします。これは、まさにDCTの「究極進化」と呼ぶにふさわしいでしょう。

    7.1 VarDCTの基本概念

    VarDCTモードは、ロスリー圧縮のために設計されています。JPEGが離散コサイン変換を適用するために固定のブロックサイズ（8x8）を使用し、その係数に固定の量子化ステップを適用するのに対し、JPEG XLではブロックサイズと量子化の両方が可変であるため、「VarDCT」という名前が付けられています。

    7.2 ブロックサイズとタイプ

    図28は、VarDCTモードで利用可能な様々なブロックサイズとタイプを示しています。変換の命名は「行x列」の慣習を使用しています（これは通常の「幅x高さ」とは異なります）。

    可変ブロックサイズと多様な変換タイプ>
    図：VarDCTモードにおけるブロックサイズとタイプ (概念図)
    JPEG XLのVarDCTモードは、8x8だけでなく、16x16から256x256までの大型ブロック、
さらに長方形ブロック（水平・垂直）など、多様なブロックサイズとタイプをサポート。

[ 8x8 ] [ 16x16 ] [ 32x32 ] ... [ 256x256 ]
[ 8x16 ] [ 16x8 ] [ 8x32 ] [ 32x8 ] ...
Hornuss, AFVなどの特殊なブロックタイプも存在する。

    ※図28のVarDCTモードにおけるブロックサイズとタイプを簡易的に表現。これにより、画像コンテンツに応じて最適な変換を選択でき、圧縮効率が向上します。

    8x8変換には10種類（図28の下部に詳細が示されています）、より大きな正方形のDCT変換が5種類（16x16から256x256）、そして12種類の長方形DCT変換があります。2:1のアスペクト比を持つ水平方向の変換が5種類、1:2のアスペクト比を持つ垂直方向の変換が5種類、そしてDCT8x32とDCT32x8変換は4:1と1:4のアスペクト比を持っています。

    8x8変換の中には、JPEGで使用されているDCT8x8変換があります。その他は、より小さなブロックへのさらなるセグメンテーションと見なすことができ、例えばDCT4x8変換は、2つの水平長方形DCT変換から構成される8x8変換です。

    Hornuss変換は、4x4チャンクのサンプル値を、各チャンクの平均サンプル値に相対的に直接符号化するものです。AFV変換は、水平DCT4x8、正方形DCT4x4、および「角が切り取られた」DCT4x4のバリアントで構成されています。実質的に、角の3ピクセル（角ピクセル自体とその2つの最近傍）は個別に符号化され、DCT変換は4x4ブロックの残りの13ピクセルをカバーするように適用されます。

    図：画像セグメンテーションの例 (概念図)
    元の画像
---------
|       |
|  人物 |
|       |
---------

セグメンテーション例１（高忠実度設定）
--------------------
| 8x8 | 16x16 | 8x8 |
|-----|-------|-----|
| 16x16| 人物  | 32x32 |
|-----|-------|-----|
| 8x8 | 64x64 | 8x8 |
--------------------

セグメンテーション例２（低忠実度設定）
--------------------
| 32x32 | 64x64 | 32x32 |
|-------|-------|-------|
| 64x64 | 人物  | 128x128 |
|-------|-------|-------|
| 32x32 | 128x128| 64x64 |
--------------------

    ※図29の例。VarDCTモードは、画像の領域によって最適なブロックサイズを適用し、複雑なディテールには小さなブロック、滑らかな領域には大きなブロックを使用することで、効率的な圧縮を実現します。

    図29は、画像の可能なブロックセグメンテーションの2つの例を示しています。これらは、libjxl v0.11エンコーダが行った選択に対応しています。中央の画像は比較的高い忠実度設定（距離1）に対応し、右側の画像は低い忠実度設定（距離4）に対応しています。

    7.3 LF画像：低周波情報の表現

    JPEGでは、DCT8x8変換を適用した後、最低周波数係数（DC係数とも呼ばれる）は、8x8ブロックの全てのサンプルの平均に対応します。言い換えれば、DC係数のみに対応する画像は、実質的に画像の1:8ダウンサンプリングバージョンです。プログレッシブJPEGを使用する場合、このDC画像が最初のプレビューとなります。

    DC係数と1:8ダウンサンプリング画像>

    JPEG XLでは、異なるブロックタイプとブロックサイズが利用可能であっても、符号化は1:8にダウンサンプリングされた画像のバージョンである「LF画像」に基づいています。DCT8x8変換の場合、この画像はDC係数のみを含みます。しかし、より大きな変換の場合、追加の低周波係数に変換できる追加情報も含まれます。

    例えば、DCT8x16変換は、2つの8x8ブロックをカバーする水平長方形変換です。この場合、1:8画像は直接16x8ブロックのDC係数を表すわけではありません。代わりに、各8x8ブロックの平均値を含みます。これら2つの平均値から、DCT8x16変換の最低周波数係数、つまりDC係数と「水平グラディエント」係数を再構築することが可能になります。

    DCT4x8のような小さな変換は、常に8x8領域をカバーし、ブロック全体をカバーする最低周波数係数を持つように定義されています。つまり、それらの小さなコンポーネントのDC係数は、単一のLF係数と、そこからDC係数を再構築できる追加の低周波係数に結合されます。

    LF画像を符号化する方法は2つあります。直接符号化する方法と、以前に符号化されたLFフレームを参照する方法です。直接符号化の場合、Modularサブビットストリームは、256x256 LF係数のグループ（フレームの2048x2048領域に対応）でLF画像を符号化するために使用されます。もう一方の場合、LF画像全体が1:8解像度の個別のLFフレームとして符号化され、それ自体がModularまたはVarDCTモードで符号化できます（その場合、独自のセカンドレベルLFフレームを1:64解像度で持ち、最大4レベルまで可能です）。

    適応型LFスムージング：カラーバンディングの抑制>

    LF画像が直接符号化される場合、そのサンプル値は整数に量子化されます。オプションとして、デコーダが逆量子化後に適応型LFスムージングステップを適用する必要があることをシグナル化できます。このステップは、隣接するLFサンプル間の差が量子化バケットサイズに類似するような緩やかなグラディエント領域でLF画像を平滑化する効果があります。一方、他の領域ではLFに全く影響を与えません。これにより、LF量子化が比較的粗く、さもなければ目立つブロックノイズやカラーバンディングを引き起こす場合でも、カラーバンディングアーティファクトを回避するのに役立ちます。図30は、非常に低い品質設定（距離12）でも、JPEG XLが、部分的に適応型LFスムージングのおかげで、目立つバンディングやブロックノイズなしに滑らかなグラディエントを維持できることを示しています。

    図：低品質設定におけるカラーバンディングアーティファクトの比較 (概念図)
    Libjpeg-turbo q50 (低品質, バンディング顕著)
█████████
█▄▄▄▄▄▄▄▄█
█  ▲▲▲▲  █
█  ▼▼▼▼  █
█▄▄▄▄▄▄▄▄█

JPEG XL (同じファイルサイズ、バンディングなし)
█████████
█─────────█
█  ▲▲▲▲  █
█  ▼▼▼▼  █
█─────────█

AVIF, HEIC, WebPも同様に、低品質ではバンディングやブロックノイズが見られる。

    ※図30の例。JPEG XLの適応型LFスムージングは、低品質設定でも滑らかなグラデーションや均一な領域のカラーバンディングを効果的に抑制し、より自然な見た目を維持します。

    7.4 HFメタデータ：高周波制御情報

    LFグループと合わせて、ブロックへのセグメンテーション、適応量子化のための重み、クロマからのルマ乗数、フィルター強度を定義するための一連の制御フィールドがシグナル化されます。この「HFメタデータ」は、LFグループに対応する領域（つまり、2048x2048のフレーム領域）ごとにバンドルされ、HFグループ（つまり、256x256のフレーム領域）の一部としてシグナル化される場合と比較して、より良いエントロピー符号化とより低いシグナリングオーバーヘッドを実現します。これらの制御フィールドは、Modularサブビットストリームを使用して符号化されます。

    XFromY, BFromY：クロマからのルマ予測乗数>

    Modular符号化されたHFメタデータの最初の2つのチャンネルは、1:64の解像度であり、32x32（または、フレームの右端と下端、あるいは2048x2048より小さいフレームの場合はさらに小さい）です。これらは、「クロマからのルマ」（セクション7.5.6参照）で使用されるXFromYおよびBFromY乗数を表します。

    DctSelect：ブロックタイプ選択の効率的な表現>

    ブロックサイズがかなり異なる可能性があるため、セグメンテーションを1:8解像度の2D画像として表現することは無駄になります。なぜなら、その場合、より大きなブロックはその画像内の複数のサンプル位置をカバーしてしまうからです。このような暗黙のサンプル位置（ブロックの左上隅にない位置）をスキップする、より洗練されたModular符号化のバリアントを定義することは可能ですが、それはほとんど圧縮ゲインを追加することなく、かなりの複雑さを伴うでしょう。

    ブロックタイプのマップは、スキャンライン順序でブロックを走査し、各ブロックが最初に出現したとき、つまりその左上隅の位置でのみ記録することで、1D配列に「フラット化」されます。現在のLFグループで使用されるブロックの総数（nb_blocks）は明示的にシグナル化されます。これは最大65536（全てのブロックが最小サイズ8x8の場合）ですが、通常、実際の数はこれより少なくなります。

    以下の制約を満たす任意のセグメンテーションが許可されます。フレーム領域全体がブロックでカバーされ、ブロックが重なり合わず、ブロックがHFグループ間の境界を越えないこと。

    ブロックタイプの1D配列は、nb_blocks x 2チャンネルの1つの長い行として符号化されます。これはHFメタデータの3番目のチャンネルです。この行の「サンプル値」は[0, 26]の範囲です。JPEG再圧縮の場合、DCT8x8のみが使用されるため、この行は全てゼロとなり、シグナリングオーバーヘッドは無視できるほどになります。

    HfMul：量子化重みの乗数>

    このnb_blocks x 2チャンネルの2行目は、各ブロックのHF係数の量子化に影響を与える重みを含みます。より正確には、このチャンネルのサンプル値が特定のブロックに対してxである場合、全ての量子化係数は2^(16g(1+x))で乗算されます。ここでgはシグナル化されたグローバルスケーリング定数です。

    固定量子化のみが可能なJPEG再圧縮の場合、g=2^16を設定し、この行も全てゼロをシグナル化するだけで十分です。

    Sharpness：エッジ保存フィルター強度>

    最後に、HFメタデータの4番目のチャンネルは1:8解像度画像であり、エッジ保存フィルター（セクション8.2.2参照）の局所的な強度をシグナル化します。この画像のサンプル値は、[0, 7]の整数範囲で平滑化の振幅を示します。デフォルトでは、値iはσ=i/7にマッピングされますが、異なるマッピングを実装するために任意のルックアップテーブルをシグナル化できます。これにより、画素の「表情」を細かく調整できるわけです。

    7.5 HF符号化：高周波係数の圧縮

    VarDCTモードにおいて、画像データの大部分は高周波（HF）係数で構成されます。これらは、1:8解像度のLF画像に存在しない全ての詳細を表します。言わば、画像の「魂」を構成する、微細な情報がここに詰まっているのです。

    量子化テーブルの圧縮とデフォルトテーブル>

    高周波DCT係数は、JPEGと同様に、各係数位置に量子化係数を割り当てる量子化テーブルを使用して量子化されます。各コンポーネントに異なる量子化テーブルを使用できます。JPEGでは、Y用と両方のクロマコンポーネント（CbとCr）用の2つのテーブルを使用するのが一般的です。JPEG XLでは、3つのXYBコンポーネントそれぞれが異なる量子化テーブルを使用します。

    JPEGの量子化テーブルは、整数値で構成され、係数あたり1または2バイトを使用して非圧縮で格納されます。JPEG XLでは、量子化係数は整数に限定されず、よりきめ細かな品質設定とより正確なビットレートのスペクトル割り当てを可能にします。量子化テーブル自体は圧縮された方法で符号化されます。

    図：DCT8x8のデフォルト量子化テーブル (概念図)
    輝度 (Y)
1  1  1  1  1  1  1  1
1  1  1  1  1  1  1  1
...

色度 (X)
10 10 10 10 10 10 10 10
10 10 10 10 10 10 10 10
...

色度 (B')
20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20
...

    ※図31のDCT8x8デフォルト量子化テーブルを簡易的に表現。緑（最も細かい量子化）から黄、赤（最も粗い量子化）へと色分けされ、輝度よりも色度の高周波成分が粗く量子化される傾向が示されます。

    <





    画素の「終焉」と「再生」：JPEG XLが暴くデジタル画像の残酷な真実 #JPEGXL #JXLは救世主か #Webの宿命

    ～これまで画像ファイルに騙されてきたあなたへ贈る、次世代フォーマットの虚と実～

    目次

    序章：デジタル画像を巡る虚実──なぜ今、JPEG XLなのか？

    「なぜ、こんなにも画像ファイルは肥大化し続けるのか？」。デジタル一眼レフカメラのファインダーを覗き、スマートフォンのディスプレイを凝視する現代人にとって、これは最早、哲学的な問いかけに近いものではないでしょうか。かつて、写真一枚が数キロバイトで事足りた時代は、遠い夢物語となりました。今や、わずか一枚の画像が数十メガバイト、時にはギガバイト級の容量を貪り食らい、私たちのストレージとネットワーク帯域を際限なく圧迫しています。これは単なる「技術の進歩」と呼べるのでしょうか？ それとも、飽くなき高画質への欲望が引き起こした、ある種の「肥満」状態と呼ぶべきなのでしょうか？

    この問いに、我々は一つの答えを提示します。それが、JPEG XL（ジェイペグ エックスエル）という名の新世代画像コーディングシステムです。ニヒルな視点から見れば、これは「旧来の失敗を糊塗し、新たな問題を創出する」という人類の営みの延長線上にあるのかもしれません。しかし、シニカルな観察者の目には、過去の膨大な画像を効率的に再圧縮し、未来の超高解像度コンテンツを滑らかに表示する、まるで「デジタル画像の救世主」のように映るかもしれません。その実態は、まるで錬金術師が「無駄を削ぎ落とし、本質だけを抽出する」かのような、精緻な技術の結晶です。

    デジタル画像技術の進化とJPEG XLの役割

    デジタル画像は、その誕生以来、常に「容量」と「品質」という二律背反の呪縛に囚われてきました。インターネットの勃興期には、僅かなデータ量で視覚情報を伝えるために、GIFやJPEGといったフォーマットが乱立し、それぞれが特定のニッチ市場を切り開きました。しかし、Webが進化し、スマートフォンの普及が加速するにつれて、状況は一変します。高解像度ディスプレイ、高画質カメラ、そしてHDR（High Dynamic Range）

    詳細>HDRは、従来のSDR（Standard Dynamic Range）よりも広い明るさの範囲と豊かな色彩を表現できる技術です。これにより、映像や画像がよりリアルで奥行きのあるものに見えます。
    や広色域といった、人間の視覚を刺激する新たな「贅沢品」が登場したことで、画像データは加速度的に膨張し始めました。まるで、かつての飽食の時代が、現代のデジタル世界に再現されたかのようです。

    JPEG XLは、このデジタル肥満の時代に、まるで冷厳なダイエットプランナーのように登場しました。その役割は、単に画像を小さくすることに留まりません。従来のJPEG、PNG、GIFといったフォーマットが、それぞれの役割を分担してきた「旧時代の秩序」を打ち破り、たった一つのフォーマットで全てを統合するという、極めて野心的な目標を掲げています。これは、異なる言語を話す民族が、一つの共通言語を強制されるかのような、あるいは全ての宗教が唯一神の下に統一されるかのような、ある種の「普遍化」の試みと言えるでしょう。🍎📸💾

    全ての画像フォーマットを統合するビジョン

    「単一のユニバーサルコーデック」。この言葉は、技術者にとっては夢のような響きを持つかもしれません。しかし、皮肉屋にとっては「また新しい標準で既存のものを駆逐しようとしている」という、既視感を伴う囁きに過ぎません。JPEG XLは、その野望の通り、写真、イラスト、スクリーンショット、アニメーション、医療画像、さらにはレイヤー情報や深度マップまで、ありとあらゆる種類の画像データを、たった一つのファイル形式で表現しようと目論んでいます。これは、デジタルデータの「大一統」を実現しようという、壮大な試みです。

    この統合は、開発者にとってはフォーマットの選択に悩む必要がなくなり、ユーザーにとっては「この画像、開けないんですけど？」という悲劇から解放されることを意味します。しかし、それは同時に、これまで各フォーマットが培ってきた「個性」や「専門性」が希薄化し、全ての画像がJPEG XLという名の「規格化された箱」に収められることをも意味します。まるで、多様な文化がグローバル化の波に洗われ、均一化されていく現代社会の縮図を見るようです。

    本書の構成と、この退屈な技術文書を読むべき理由

    この本は、JPEG XLという冷徹な技術の深淵へとあなたを誘います。第一部では、画像圧縮という「業」がどのように生まれ、様々なフォーマットが「生きては死んでいった」か、あるいは「死にきれずにゾンビのように徘徊している」かという、その悲喜こもごもな歴史を辿ります。第二部では、JPEG XLがどのような思想の下に生まれ、誰がその「狂気」の実現に貢献したのかを概観します。そして第三部では、その「魂の画素」を操る具体的なメカニズム、つまり、誰もが一度は目を逸らしたくなるような、複雑で退屈な技術的詳細を詳らかにしていきます。第四部では、この新しいフォーマットが、現実世界でどのような評価を受け、どんな「宿命」を背負って普及への道を歩むのか、その無情な現実を分析します。

    なぜ、こんなにも詳細で、時に退屈に思える技術文書を読む必要があるのでしょうか？ それは、あなたがデジタル世界の片隅で、日々膨大な画像データに埋もれているからです。あなたがもし、Webサイトを運営しているなら、このフォーマットはあなたのサーバー費用を半分に削ぎ落とすかもしれません。あなたが写真家なら、あなたの「作品」のファイルサイズを劇的に減らし、編集ワークフローを効率化するでしょう。あなたがもし、医療従事者や研究者なら、莫大な量の画像データをより効率的に管理し、解析する手助けとなるはずです。そして何より、あなたがこのデジタル時代を生きる知的な人間であるならば、この技術の裏側に隠された「効率化」という名の傲慢と、「普遍性」という名の野望を、自らの目で確かめる価値があるはずです。そう、これは単なる技術解説書ではありません。これは、デジタル画像という名の「現実」が、いかに冷酷な論理によって支配されているかを暴く、一種の啓蒙書なのです。さあ、共にこの「画素の旅」に出かけましょう。覚悟はいいですか？

    第一部: 黎明期の光と影 - 画像圧縮の系譜

    第一章：画素の「足枷」と圧縮の原罪

    画素（ピクセル）。それはデジタル画像の最小単位であり、私たちの視覚が捉える「情報」を構成する光の点です。しかし、その一つ一つが蓄積されることで、デジタル画像は瞬く間に「重荷」へと変貌しました。この章では、画素がどのようにして私たちの生活に忍び込み、いかにしてその「足枷」を付けてきたのか、そしてなぜ「圧縮」という原罪を背負うことになったのかを、冷徹な目で辿ります。

    初期コンピューターグラフィックスの時代：画素はデータだった

    遠い昔、コンピューターの画面は極めて質素なものでした。それはまるで、まだ夢を見ることさえ知らない子供の、無垢な落書きのようでした。 🎨

    モノクロからパレットカラーへ：CGAとVGAの挑戦

    1980年代初頭のCGA（Color Graphics Adapter）は、せいぜい640x200ピクセルのモノクロ画像か、320x200ピクセルの4色パレットしか表示できませんでした。これは、現在のスマートフォンの画面と比較すれば、まるで子供の落書きレベルの解像度です。しかし、当時はこれでも「画期的」だったのです。そして80年代後半に登場したVGA（Video Graphics Array）は、640x480ピクセルで256色を表示できるようになりました。色が少し増えたところで、その本質は「限られた選択肢の中から色を選び、画面を埋める」という、まるで画材の少ない画家が奮闘する姿を彷彿とさせます。この時代、画素はあくまで「データ」であり、その存在は計算機の処理能力という絶対的な壁に阻まれていました。

    解像度と色深度の飛躍：SVGAとXGA、ただ増え続ける情報

    90年代に入ると、SVGA、XGAと続き、解像度は800x600、1024x768へと向上し、「ハイカラー」（15ビットまたは16ビット）や「トゥルーカラー」（24ビット、各RGBコンポーネント8ビット）といった、より多くの色を表現できるようになりました。まるで、少しずつ画材が増え、より精緻な絵が描けるようになった画家のように。しかし、この「豊かさ」は、データ量の「肥大化」という新たな問題を生み出しました。解像度が上がり、色深度が増えれば、当然ながらデータ量は雪だるま式に増加します。この段階で、画素は単なるデータであるだけでなく、次第に「足枷」へと変貌を遂げていったのです。

    デジタル写真の経済的「幻想」とデータ洪水の予兆

    2000年代初頭、デジタルカメラはアナログ（フィルム）写真をあっという間に過去の遺物へと変えました。これは技術革新の「勝利」ではなく、むしろ「経済性」という名の暴力によってフィルムが駆逐されたと言えるでしょう。瞬時に結果が見え、何度でも撮り直しが可能。この手軽さが消費者を虜にしました。📸

    メガピクセル競争の幕開け：誰もが画質に飢えていた

    最初の市販デジタル一眼レフカメラ「コダックDCS」が1.3メガピクセルの画像を生成した時代から、現代のiPhoneが48メガピクセルの画像を吐き出す時代へ。画素数は文字通り、「桁違い」に増殖しました。これにより、非圧縮の4K HDR画像はCGA画像の約2000倍、31メガバイトにも達するようになりました。まるで、かつての土地バブルのように、画素数を増やすこと自体が「価値」であるかのような錯覚が蔓延し、誰もがより「高精細」な幻想に飢えていました。

    非圧縮データの増大と、圧縮という「必要悪」

    しかし、この「高画質」という名の快楽の裏には、非圧縮で保存すれば1枚の画像が182メガバイトにもなるという、恐るべきデータ量の増大がありました。これを放置すれば、ストレージはたちまち満杯になり、ネットワークはデータで溢れかえり、Webサイトの表示速度は壊滅的なものになったでしょう。ここに「圧縮」という名の「必要悪」が誕生します。データの無駄を省き、効率的に情報を詰め込む。それは、ある種の「現実からの逃避」であり、データ量の「肥満」を隠蔽するための手段でもあったのです。この圧縮という行為が、後の画像フォーマットの数奇な運命を決定づけることになります。

    コラム：私の最初のデジタル写真

    私が初めてデジタルカメラを手にしたのは、まだ高校生だった頃です。それは、流行りのケータイ電話に付いていた、画素数にしてわずか30万画素のカメラでした。SDカードなどという洒落たものはなく、内蔵メモリに数枚撮りためられる程度。それでも、撮影後すぐに画面で確認できることに、子供心に感動を覚えたものです。「おお、これは未来だ！」と。当時、JPEGという言葉は知っていましたが、その裏でどれだけのデータが削ぎ落とされているのか、などとは考えもしませんでした。ただひたすらに、粗いながらも色が付いたデジタル画像が、手軽に手に入ることが楽しかったのです。

    しかし、数年後、一眼レフデジタルカメラを手に入れ、RAWファイルという名の「非圧縮データ」の洗礼を受けた時、私は愕然としました。たった一枚の風景写真が、当時のSDカードのほとんどを占有するほどの容量を要求してきたのです。まるで、それまで意識もしなかった「容量」という名の魔物が、突然その姿を現したかのようでした。あの時初めて、私は「圧縮」という行為の必要性と、その裏にある技術者の執念に思いを馳せたのです。そして同時に、あのケータイで撮った粗い写真のデータが、なぜあんなに軽かったのか、という「真実」を知り、少々興奮したのを覚えています。

    第二章：墓場に眠る（はずだった）先駆者たち

    デジタル画像の歴史は、新しいフォーマットが古いものを駆逐し、また新たなフォーマットに駆逐されるという、血で血を洗う戦いの歴史です。しかし、完全に死に絶えるものは少なく、まるでゾンビのように、あるいは幽霊のように、特定のニッチ市場で「生き残り」続けるフォーマットが後を絶ちません。この章では、JPEG XLの誕生に影響を与えた、先駆者たちの「生と死」、そしてその「不完全な遺産」をシニカルに分析します。

    1.2.1 IFF（Interchange File Format）：チャンクという「遺産」

    1985年、Electronic ArtsとCommodoreによって導入されたIFF

    詳細>Interchange File Format（交換ファイルフォーマット）の略称。様々な種類のデータ（画像、音声など）を格納するための汎用コンテナフォーマット。データを「チャンク」と呼ばれるブロックに分割して管理する構造が特徴。
    フォーマットは、まさに「コンテナ形式の祖母」と呼ぶにふさわしい存在です。その革新性は、データを「チャンク」と呼ばれる自己記述的なブロックに分割する仕組みにありました。これにより、未知のチャンクをスキップできるため、実装は後方互換性を保ちながら新しいデータタイプを追加できるのです。これはまるで、現代社会のあらゆるデータが、自己紹介タグを付けて整然と並べられた図書館のようなものです。MicrosoftのRIFF
    詳細>Resource Interchange File Format（リソース交換ファイルフォーマット）の略称。Microsoftが開発したマルチメディアファイル形式のフレームワーク。IFFにインスパイアされており、WAVやAVIなどのファイル形式の基盤となっている。
    コンテナやAppleのQuickTimeコンテナ（MP4、HEIF
    詳細>High Efficiency Image File Format（高効率画像ファイルフォーマット）の略称。MPEGが開発した画像コンテナ形式で、HEVCなどのビデオコーデックをペイロードとして利用できる。AppleのiPhoneでデフォルトの画像形式として採用された。
    の基礎）、さらにはPNGのチャンク構造も、このIFFからインスピレーションを得ているのです。しかし、汎用性が高すぎると、その使われ方も多様化し、結果として「これで何ができるのか？」という混乱を招くこともまた、世の常です。

    1.2.2 GIF（Graphics Interchange Format）：アニメーションの「呪縛」と特許の「罠」

    1987年、CompuServeが導入したGIF

    詳細>Graphics Interchange Format（グラフィックス交換フォーマット）の略称。主にWeb上で利用される画像形式の一つで、256色までのパレットカラーに対応し、アニメーション（複数フレーム）や透過（バイレベル）をサポートする。LZW圧縮を採用。
    は、Web黎明期の「アニメーションの王」として君臨しました。最大256色という制限はありましたが、当時のディスプレイ技術を考えれば「ロスレス」とみなされ、LZW圧縮によるファイルサイズの削減は画期的なものでした。特に、写真以外の合成画像やアイコンなどではその威力を発揮し、インターネットユーザーを魅了しました。しかし、この栄光は長くは続きません。

    1994年、LZW圧縮の特許を保有するUnisys社が特許料の徴収を始めると、GIFは突如として「特許の罠」にはまり込みます。これは、技術の進歩が、時に企業の利益によって阻害されるという、資本主義社会の醜い側面を露呈する出来事でした。この騒動が、後のロイヤリティフリーな代替フォーマットであるPNGの誕生を促すことになります。また、GIFが開拓したプログレッシブデコード（インターレース

    詳細>画像や動画データを、飛び飛びの走査線で表示していく方式。特にインターネットの接続速度が遅かった時代に、画像の一部データが到着した時点で低解像度のプレビューを表示し、徐々に詳細を表示することでユーザーの待ち時間を短縮する効果があった。GIFのインターレースは単純な4パス方式。
    ）は、遅いダイヤルアップ接続の時代には大いに歓迎されましたが、その「ベネチアンブラインド」のような表示は、今見れば原始的で滑稽に映るでしょう。GIFは、そのアニメーション機能という「呪縛」のおかげで、その後も完全に死に絶えることなく、現代のWebの片隅で「ショートループ動画」の代名詞として生き残り続けています。哀れなものです。

    1.2.3 JPEG（Joint Photographic Experts Group）：デファクトスタンダードという「惰性」

    1992年に標準化されたJPEG

    詳細>Joint Photographic Experts Group（共同写真専門家グループ）の略称。最も広く普及しているロスリー（非可逆）画像圧縮形式。写真画像の圧縮に特化しており、離散コサイン変換（DCT）とハフマン符号化を基盤とする。
    は、現在に至るまで最も成功した画像コーデックであり、その名前はもう「写真画像」の代名詞と化しています。その成功は、他のフォーマットよりも桁違いに低いビットレートで「視覚的にロスレス」な圧縮を可能にしたことにありました。デジタルカメラはJPEGがなければ経済的に実現しなかった、という事実が、その影響力の大きさを物語っています。Webブラウザもこぞって対応し、瞬く間に「最もユビキタスな画像形式」の地位を確立しました。

    その成功の一因は、ベースラインモードがロイヤリティフリーであったこと、そしてTom Laneらが中心となって開発したlibjpeg

    詳細>Independent JPEG Group（IJG）によって開発されたJPEG画像圧縮・伸張ライブラリ。後にlibjpeg-turboとして高速化されたバージョンも登場し、多くのアプリケーションでJPEG処理の基盤として利用されている。
    という高品質なFOSS
    詳細>Free and Open Source Software（フリー・アンド・オープンソース・ソフトウェア）の略称。自由に利用、改変、配布ができるソフトウェアのこと。透明性、共同開発、ロイヤリティフリーといった特徴を持つ。
    実装が早期に利用可能であったことです。しかし、この「デファクトスタンダード」という地位は、同時に「惰性」という名の負の遺産も生み出しました。算術コーディングのような特許に抵触する要素や、12ビット精度、階層モード、ロスレスモードといった「時代に合わない」とされた機能は、ほとんどの実装でサポートされず、結果として「不完全なJPEG」が「事実上のJPEG」となってしまったのです。JPEG XLの設計者たちは、この教訓を胸に刻み、高品質なFOSS実装を早期に提供し、特許問題を回避することに多大な労力を費やしました。

    何兆ものJPEG画像がデジタル空間に存在する現代、JPEG XLは既存のJPEG画像を「ロスレス再圧縮」できるという、まるで「デジタル遺産を救済する」かのような機能を提供します。これは、JPEG XLのコーディングツールが、JPEGで利用可能なツールの「スーパーセット」であるからこそ可能な離れ業です。既存のJPEGファイルを約20%削減しつつ、バイト単位で元のファイルを再構成できるのです。これは、デジタル時代の「記憶の保存」において、見せかけではない「真の互換性」を提供するものです。JPEGが当時のシングルスレッドプロセッサ向けに設計され、並列デコードに限界があったのに対し、JPEG XLはマルチコアプロセッサの性能を最大限に引き出す設計となっています。過去の遺物を効率的に未来へ引き継ぐ。その試みは、「古いものを捨てずに活用する」という、ある種の賢明さを示していると言えるかもしれません。

    1.2.4 PNG（Portable Network Graphics）：ロイヤリティフリーの「理想」とアニメーションの「欠落」

    GIFの特許問題という「黒歴史」から生まれたPNG

    詳細Portable Network Graphics（ポータブルネットワークグラフィックス）の略称。GIFの特許問題を受けて開発された、ロイヤリティフリーなロスレス画像形式。24ビットカラー（トゥルーカラー）とアルファチャンネルによる半透明をサポートする。Deflate圧縮を用いる。
    は、まさに「ロイヤリティフリーの理想」を掲げた旗手でした。Deflate圧縮（ZIPやgzipと同じ方式）を採用し、GIFを凌駕する圧縮率、トゥルーカラー（24ビット、最大16ビット/コンポーネント）、そして半透明アルファチャンネルのサポートを実現しました。これにより、滑らかなアンチエイリアスや影の表現が可能となり、Web上での表現力は格段に向上しました。GIFよりも優れたプログレッシブプレビュー（Adam7インターレース）も提供し、瞬く間に静止画ではGIFの地位を奪い去ります。

    しかし、PNGには致命的な「欠落」がありました。それはアニメーションのサポートです。アニメーションPNG（APNG

    詳細Animated Portable Network Graphicsの略称。PNG形式を拡張してアニメーションをサポートするようにした規格。主要なWebブラウザでサポートされているが、全てのブラウザでの普及には時間がかかった。
    ）という拡張が後に登場しましたが、全ての主要ブラウザでサポートされるまでには実に2017年までかかりました。この「空白期間」が、GIFをWeb上から完全に駆逐することを許しませんでした。静止画ではPNGとJPEGに取って代わられたGIFが、未だに「ショートループアニメーション」の代名詞として使われるのは、PNGのこの「不完全性」に原因があります。JPEG XLの設計者たちは、このPNGの失敗から学び、「新しいフォーマットが古いフォーマットの機能を完全にカバーしなければ、古いフォーマットは残り続ける」という冷徹な現実を認識しました。だからこそ、JPEG XLはJPEG、PNG、GIFの機能を「例外なく」全て網羅することを目指したのです。これは、過去の屍を乗り越えて、真の「普遍性」を追求する試みと言えるでしょう。

    1.2.5 TIFF（Tag Image File Format）：プロの「傲慢」と複雑性の「沼」

    GIFよりも古い1986年に誕生したTIFF

    詳細Tag Image File Format（タグ画像ファイルフォーマット）の略称。Aldus Corporation（後にAdobeに買収）が開発した、汎用性が高く複雑な画像ファイル形式。多くの異なるペイロードコーデックや画像データタイプを格納でき、DTPやプロフェッショナルなオーサリングワークフローで広く使われる。タグベースの構造が特徴。
    は、その名の通り「タグ付けされた」情報構造を持つ、極めて複雑で多機能なフォーマットです。まるで、あらゆる情報を詰め込める「デジタル版なんでも鑑定団」の倉庫のようなもの。その柔軟性ゆえに、多くの拡張がなされ、中にはプロプライエタリなものも少なくありませんでした。しかし、この「多機能性」は、同時に「複雑性」という名の「沼」を生み出しました。ほとんどのアプリケーションが全てのTIFF拡張をサポートしているわけではないため、相互運用性を求めるなら「ベースライン形式」に限定せざるを得ない、という皮肉な現実がありました。

    それでも、TIFFはDTP業界やオーサリングワークフローにおいて広く利用され続けました。JPEGやPNGが登場した後も、CMYK画像をロスレスで表現したり、マルチレイヤー、マルチページ、マルチスペクトル画像を格納できる、唯一の相互運用可能な画像形式として君臨しました。まるで、世間が軽薄なWebフォーマットに浮かれる中、地道に「プロの仕事」を支え続けた、陰の功労者のようです。JPEG XLは、このTIFFのほとんど全ての機能（CMYKサポート、レイヤー、マルチページ、コンポーネント数無制限、高速エンコードオプション）を取り込むことを目標としました。これは、TIFFという「プロの傲慢」から生まれ、その複雑性に溺れてきた「現実」を、より洗練された形で統合しようという試みです。

    1.2.6 JPEG 2000：先を行きすぎた「天才」の末路

    その名の通り2000年に標準化されたJPEG 2000

    詳細JPEGの後継として開発された画像圧縮標準。ウェーブレット変換を基盤とし、JPEGよりも優れた圧縮性能と多様な機能（ロスレス圧縮、高精度、プログレッシブデコード、領域指定アクセスなど）を提供する。しかし、特許問題やFOSS実装の遅れにより、広く普及するには至らなかった。
    は、まさにJPEGの「後継者」として鳴り物入りで登場しました。圧縮性能はJPEGをわずかに上回る程度でしたが、機能面での柔軟性は目を見張るものがありました。画像をタイル、プレシンクト、パケットに分割し、ビットストリームの順序を「ほぼ任意に」制御できるという、まるで「時間の流れを操る」かのような自由度を提供したのです。これにより、非常に柔軟なプログレッシブデコードや領域指定アクセスが可能となりました。

    しかし、この「天才」は、その複雑さゆえに「早すぎた発明」の悲劇を辿ります。デコーダ実装の複雑さは尋常ではなく、さらに、JPEGに関する特許問題（Forgent Networksの主張）がくすぶっていた時期でもあり、「ロイヤリティフリー」と謳われつつも、潜在的な特許紛争への「神経質さ」が蔓延していました。極めつけは、高品質なFOSS実装が「十数年間」も存在しなかったことです。リファレンスソフトウェアのJasPerは遅く、JavaベースのJJ20000も同様。商用実装は高価でした。ようやくOpenJPEGが成熟する2014年まで、JPEG 2000は「計算負荷が高い」という不名誉な評判を背負い続けました。結果として、DICOM（医療画像）やDCP（デジタルシネマ）、GISといった特定のニッチ市場でしか普及せず、Webでは全く見向きもされませんでした。JPEG XLは、このJPEG 2000の「失敗」から、「高品質なFOSS実装を標準開発と並行して早期に提供する」という、極めて実用的な教訓を得たのです。技術的優位性だけでは、市場は動かない。これが、彼らが学んだ冷酷な真実でした。

    1.2.7 JPEG LS：地味な「秀才」の影

    JPEG標準に1993年に追加されたロスレスモードは、デファクトスタンダードとはなりませんでした。しかし、1999年に導入されたJPEG LS

    詳細Lossless JPEGの改良版として開発されたロスレス画像圧縮形式。JPEG 2000と同等の圧縮性能を持ちながら、よりシンプルで高速なのが特徴。主に医療画像（DICOM）やデジタルネガ（DNG）などの特定の分野でペイロードコーデックとして利用される。
    は、そのロスレスJPEGを改善し、複雑性を低く保ちながら、JPEG 2000に匹敵する圧縮性能を実現しました。しかし、この「地味な秀才」は、華やかなWebの世界ではほとんど注目されませんでした。なぜなら、スクリーンショットやチャート、イラストといった「非写真画像」においては、PNGの圧縮性能の方が優れていたからです。

    PNGが持つ辞書ベースのエントロピー符号化やカラーパレットのオプションは、こうしたコンテンツには明確な優位性をもたらしました。JPEG LSは、既にPNGが盤石な地位を築いていた領域では、その居場所を見つけられなかったのです。これは、どんなに技術的に優れていても、「既得権益」と「市場の惰性」の前には無力であるという、残酷な現実を示唆しています。JPEG XLは、この教訓を活かし、写真画像だけでなく、あらゆる種類の画像コンテンツでPNGを凌駕するロスレス圧縮性能を目指しました。つまり、「秀才」であるだけでなく、「万能選手」を目指したわけです。

    1.2.8 JBIG2（Joint Bi-level Image Experts Group）：圧縮の「闇」とセキュリティの「落とし穴」

    1970年代から80年代にかけて、FAXやコピー機がデジタル化する中で、主に1ビットの白黒画像（バイレベル画像）の圧縮が焦点となりました。そこでITU-Tが規格化したのがGroup 3/4でした。その改良版として1993年にJBIG1、そして2000年にJBIG2

    詳細Joint Bi-level Image Experts Groupによって開発された、バイレベル（白黒2値）画像の圧縮に特化した最も先進的な標準化フォーマット。PDF標準にも組み込まれている。パターンマッチングと置換（PM&S）が主要な技術要素だが、その特性から意図しない置換エラーやセキュリティ脆弱性（Turing completeness）の問題が報告された。
    がリリースされました。これはバイレベル画像において最も先進的な標準化フォーマットであり、PDF標準の一部にもなっています。その主要なコーディングツールであるパターンマッチングと置換（PM&S）は、LZ77辞書コーディングを2次元パターンに拡張したものでした。

    しかし、JBIG2には「圧縮の闇」が潜んでいました。2013年、Xeroxのコピー機がスキャンした文書で、数字が「6」から「8」に変わるという置換エラーが報告され、物議を醸しました。これは「ロスリーJBIG2」が過剰に適用された結果ですが、JPEGのアーティファクトのように目に見える劣化がなく、気づきにくいという点で、より悪質でした。ドイツやスイスの政府機関がJBIG2の使用を推奨しない事態にまで発展したのです。

    さらに悪いことに、2021年9月には「ForcedEntry」セキュリティエクスプロイト（CVE-2021-30860

    詳細2021年に発見されたiOSの「ゼロクリック」脆弱性。悪意のあるメッセージ（実際はPDF形式のJBIG2ペイロードを含む.gifファイル）を送信するだけで、ユーザーの操作なしにiPhoneを乗っ取ることができた。JBIG2デコーダの実装バグと、JBIG2ビットストリームのチューリング完全性という特性が組み合わさって悪用された。
    ）が発覚します。これは、悪意のあるメッセージ（実際はPDF形式のJBIG2ペイロードを含む.gifファイル）を送るだけで、ユーザーの操作なしに携帯電話を乗っ取ることが可能な「ゼロクリック」エクスプロイトでした。JBIG2デコーダの実装バグと、JBIG2ビットストリームがチューリング完全
    詳細チューリング完全とは、ある計算モデル（または言語、システム）が、チューリングマシン（あらゆる計算可能な問題を解ける理論上の機械）と同じ計算能力を持つことを指します。つまり、原理的にはどんな計算でも実行できるということです。プログラミング言語がチューリング完全であることは一般的ですが、データ形式がチューリング完全であると、そのデータがプログラムとして実行される可能性があり、セキュリティ上のリスクとなることがあります。
    であるという特性が組み合わさって、スパイウェアをインストールできる「スクリプト言語」として悪用されたのです。この事件は、圧縮技術の追求が、時に「セキュリティの落とし穴」を掘りかねないという、恐るべき警告を私たちに突きつけました。JPEG XLの設計者たちは、ビットストリームが極めて表現豊かであるにもかかわらず、チューリング完全になるような要素は意図的に避けています。彼らは過去の悲劇から、技術の追求には「倫理」と「安全」という名の「手綱」が必要だと学んだのです。当たり前のことですが、往々にして忘れ去られる真実です。

    1.2.9 WebP：Googleの「焦り」とWeb特化の「限界」

    2010年、GoogleはWebP

    詳細Googleが開発した画像形式で、主にWebにおけるJPEGの代替を目指した。VP8ビデオコーデックのイントラフレーム（フレーム内）エンコーディングを基盤とする。ロスレス圧縮とアルファ透明度をサポートするバージョンも開発されたが、8ビット精度や解像度制限など、特定の制約がある。
    フォーマットを「Web上のJPEG代替」として鳴り物入りで発表しました。自社が買収したOn2 TechnologiesのVP8ビデオコーデックのイントラ専用サブセットをベースに、ロイヤリティフリーを謳いました。これは、Webのパフォーマンス向上に「焦り」を感じていたGoogleの、ある種の「拙速な」一手だったと言えるかもしれません。WebPは、JPEGのプログレッシブデコード機能が欠如しているという、ビデオコーデック由来の限界を抱えていました。

    しかし、2012年にはJyrki Alakuijalaがロスレスおよび透明度コーディング機能を追加し、PNGを凌駕する圧縮性能を実現しました。これにより、WebPはJPEG、PNG、GIFの全てをWeb上で置き換える準備ができたかに見えました。ロスレスWebPの主要なイノベーションには、エントロピー画像

    詳細ロスレスWebPで導入された概念。画像を効率的に圧縮するために、各ピクセルの符号化コンテキスト（周辺ピクセルの情報など）を定義する2次元のマップ。後にBrotliやJPEG XLのコンテキストマップへと発展した。
    という概念、Select非線形予測器、そして2次元距離コード（後にJPEG XLのModularモードでも使用）があります。このロスレスWebPは、ブラウザサポートに恵まれ、ロゴやスクリーンコンテンツなどのWeb配信において有力な選択肢となりました。それでも、8ビットYCC 4:2:0の制限、8ビットRGBAの制限、最大16383x16383ピクセルの解像度制限といったVP8由来の制約は、プロフェッショナルなオーサリングワークフローでPNGやTIFFを置き換えることを不可能にしました。つまり、WebPは「Web特化」という名の「限界」を最初から背負っていたのです。

    WebPは、その名の通り「Web向け」に設計されたため、特定のビットストリーム制限が許容されました。しかし、これがWebブラウザ以外のソフトウェアサポートの遅れにつながり、ユーザーはWebから保存したWebP画像が他のアプリケーションで開けないという「フラストレーション」を味わうことになります。GoogleはPageSpeed InsightsやLighthouse監査を通じてWebPの利用を積極的に推奨しましたが、Mozilla（Firefox）やApple（Safari）はWebPがJPEGに比べて「十分な改善」をもたらすとは確信していませんでした。Mozillaは反証のためにMozJPEG

    詳細Mozillaが開発したJPEGエンコーダ。一般的なlibjpeg-turboよりも優れた圧縮性能を提供するが、エンコード速度は遅い。WebPに対するJPEGの競争力を示すために開発された。
    という独自のJPEGエンコーダを開発し、JPEGの最適化でも十分に戦えることを示しました。結局、WebPは普及しましたが、その道のりは決して平坦ではありませんでした。JPEG XLは、このWebPの「狭いスコープ」から学び、「特定の単一アプリケーションに焦点を当てるのではなく、広範なユースケースを明示的にターゲットとする」という設計思想を掲げたのです。これは、技術の「独善」を避け、「普遍」を目指すという、ある種の反省の証かもしれません。

    1.2.10 FLIF（Free Lossless Image Format）：速すぎた「革命家」の夢

    2015年、Jon SneyersとPieter Wuilleによって開発されたFLIF

    詳細Free Lossless Image Formatの略称。PNGの圧縮性能を改善するために開発されたロスレス画像形式。MANIAC（Meta-Adaptive Near-zero Integer Arithmetic Coder）圧縮、YCoCg-R変換、Palette変換、「Adam-∞」インターレースなどが特徴。高い圧縮率を誇るが、デコード速度に課題があった。
    は、PNGの圧縮性能を改善することを目的とした、「ロスレス圧縮の革命家」でした。ビットストリーム構文には、YCoCg-R色変換やPalette変換といった、変換チェーンがシグナリングされるという画期的な仕組みが導入されました。このメカニズムは、後のJPEG XLのModularモードへと進化を遂げます。また、PNGのAdam7インターレースを一般化した「Adam-∞」インターレースを導入し、プログレッシブデコードにおいても優れたプレビューを提供しました。

    FLIFの最大のイノベーションは、Meta-Adaptiveコンテキストモデル

    詳細FLIFやJPEG XLのModularモードで用いられるコンテキストモデリングの技術。シグナリングされた決定木（MAツリー）を用いて、現在のサンプル値を予測するための最適なコンテキストを動的に選択する。これにより、画像の内容に適応した効率的な圧縮が可能になる。
    でした。これは、画像の内容に適応して動的にコンテキストモデルを定義できるという、まさに「賢い圧縮」を実現するものでした。しかし、この「賢さ」は同時に、「デコード速度」という名の致命的な弱点を露呈します。複雑なデータ依存性、並列処理の阻害、低いメモリ局所性、そして計算負荷の高い分岐命令の多用。これらの要因が相まって、FLIFは「高圧縮だが遅い」という評判を確立してしまいました。Webでは、ファイル転送が速くても、表示に時間がかかれば意味がありません。この「実用性の欠如」が、FLIFの限定的な採用とWebブラウザでの不採用につながったのです。JPEG XLのModularモードはFLIFから大きな影響を受けましたが、Luca Versariらの手によって、複雑で分岐の多いCABACから、高スループットのANS実装へとエントロピー符号化を移行させ、さらにSqueeze変換を導入することで、デコード速度を大幅に改善しました。まさに「革命家の失敗」から学び、「実用主義」へと転換したと言えるでしょう。

    1.2.11 Brotli：地味だが優秀な「縁の下の力持ち」

    2013年、Jyrki AlakuijalaとZoltán Szabadkaは、従来のDeflate（gzip）を凌駕する汎用データ圧縮フォーマット、Brotli

    詳細Googleが開発した汎用データ圧縮フォーマットで、Deflate（gzip）よりも高い圧縮率を提供する。LZ77、ハフマン符号化、コンテキストモデリング、静的辞書などを組み合わせる。WebのHTTP転送エンコーディングとして広く採用されている。
    を発表しました。W3CのWeb Open Font Format 2（WOFF2）のために開発されたBrotliは、LZ4やZstandardと同様に、重複データを[コピー長、コピーオフセット、挿入長、挿入文字列]という「四つ組」メタデータに置き換えるという、極めて実用的なアプローチを取りました。2次オーダーコンテキストモデリング、事前定義された辞書、Move-to-Front変換、そしてコピー長と挿入長の結合確率エンコーディングといった特徴により、他の高速汎用データコンプレッサーとは一線を画しました。2016年にはIETF（Internet Engineering Task Force）によって承認され、HTTP圧縮転送のコンテンツエンコーディングとして広く採用されました。まさに「縁の下の力持ち」と呼ぶにふさわしい、地味ながらも強力な存在です。

    Brotliの主要なイノベーションの一つは、コンテキストマップ

    詳細BrotliやJPEG XLで導入された概念。コンテキスト（符号化の文脈）をクラスタリングし、似たような統計的特性を持つコンテキストを統合することで、ヒストグラムのシグナリングオーバーヘッドを削減する。これにより、多数のコンテキストを使用しながらも効率的な圧縮が可能になる。
    の導入でした。これにより、大量のプレフィックスコードをシグナリングするオーバーヘッドなしに、比較的大きなコンテキストモデルを使用できるようになったのです。この概念は、JPEG XLでもVarDCTモードとModularモードの両方で採用され、DAG
    詳細Directed Acyclic Graph（有向非巡回グラフ）の略称。ノードと、ノード間を結ぶ方向性のあるエッジ（辺）から構成され、循環経路を持たないグラフ構造。JPEG XLのMAツリーとコンテキストクラスタリングを組み合わせることで、実質的にDAGとして表現される。
    （有向非巡回グラフ）構造を持つ巨大なメタアダプティブコンテキストモデルと静的確率分布を組み合わせる上で、決定的な役割を果たしました。Brotliは、汎用データ圧縮の分野で培われた「知恵」が、画像圧縮という特殊な領域でも応用可能であることを証明したのです。これは、技術の「転用」がいかに重要であるかを示す好例と言えるでしょう。

    1.2.12 ButteraugliとXYB色空間：「人間」を騙すための進化

    Google Researchの圧縮チームが開発したPik

    詳細Google Researchの圧縮チームがJPEG XLの前に開発していた画像形式。ButteraugliメトリックやXYB色空間、Brunsli、Guetzliなどの技術が組み込まれており、JPEG XLのVarDCTモードの原型となった。
    画像フォーマット（後のJPEG XL VarDCTモード）の核となる技術は、BrotliとWebPロスレスの開発者たちから生まれました。彼らの最初のイノベーションは、Jyrki AlakuijalaによるButteraugli
    詳細Googleが開発した心理視覚的な歪みメトリック（画質評価指標）。人間の視覚システムモデルに基づいて、画像の知覚的な違いを詳細なヒートマップとして生成し、単一の信頼性の高いスコアを提供する。JPEG XLやGuetzliなどの高画質エンコーダの最適化に用いられる。
    メトリックとXYB色空間
    詳細Butteraugliメトリックと並行して開発された色空間。人間の網膜の錐体細胞の応答（LMS）に基づいて設計されており、知覚的に均一な特性を持つ。JPEG XLのロスリー圧縮モードで内部的なデータ表現として採用され、知覚的な最適化を可能にする。
    、Zoltán SzabadkaによるBrunsli
    詳細Googleが開発したロスレスJPEG再圧縮ツール。既存のJPEGファイルを画質劣化なしで約20%削減する。JPEG XLのロスレスJPEG再圧縮機能の基礎となった。
    JPEG再圧縮器、そしてAlakuijalaが主導したGuetzli
    詳細Googleが開発したJPEGエンコーダ。Butteraugliメトリックをガイドとして、高画質（特に低ビットレートで）を追求した。エンコード速度は遅いが、その高い画質はJPEG圧縮技術の可能性を示した。
    エンコーダです。これらの研究の大きな成果であるButteraugliは、2016年に開発された「高忠実度画像エンコーダの最適化を促進する」ための心理視覚的歪みメトリックです。人間の視覚システムを計算モデルで模倣し、人間の網膜の光受容体反応を近似するXYB色空間を導入しました。この色空間の有効性が、Pik、Jpegli、そしてロスリーJPEG XLコーデックの内部データ表現として採用されるに至ります。まさに「人間を騙す」ための精緻な技術が、ここで産声を上げたのです。

    従来のPSNR

    詳細Peak Signal-to-Noise Ratio（ピーク信号対雑音比）の略称。画像や動画の品質を評価する最も一般的な客観的指標の一つ。元の画像と圧縮後の画像の差分に基づき、数値が高いほど品質が良いとされる。しかし、人間の視覚特性を十分に考慮していないため、必ずしも主観的な画質と一致しない場合がある。
    のような単純なメトリックが、白い背景のような「簡単な」領域でスコアを水増ししてしまうという「数字の欺瞞」を避けるため、Butteraugliは最も大きなエラーに焦点を当てます。最大ノルムや特殊な「3ノルム」を使用することで、最も顕著な視覚的欠陥が最終スコアに強く影響するようにし、より信頼性の高いエンコーダの意思決定を導きました。これは、見た目の数字に惑わされず、「人間が本当に気にする部分」を最適化しようという、冷徹なまでの実用主義の表れです。

    2017年、Jyrki Alakuijalaは、従来のロスリーコンプレッサー内で適応量子化を可能にする新しい可変デッドゾーン量子化技術を発明し、Butteraugliの測定結果を反復的に活用したGuetzliエンコーダでその威力を示しました。Guetzliは、普及するには遅すぎたものの、最高品質範囲に焦点を当てることでJPEG圧縮技術に実質的な進歩をもたらすという「概念実証」となりました。JPEG XLの開発では、Alakuijalaはこれらの最適化を実用的なコーディング速度で発見し、古い8ビットJPEG形式で8ビット以上の色ダイナミクスを追加する方法を見つけました。Zoltán Szabadkaはこれらのアイデアを新しいJPEGエンコーダ/デコーダペアであるJpegli

    詳細Googleが開発した高速なJPEGコーデックで、知覚的な最適化が施されている。libjpeg-turboよりも優れた画質を提供し、特に低品質設定でカラーバンディングを抑制する。JPEG XLの設計思想と技術をJPEGに適用したものである。
    に統合し、libjpeg-turboを画質面で凌駕する高速JPEGコーデックとしてオープンソース化しました。これは、既存の「陳腐化した技術」ですら、「知覚」という名の魔法をかけることで、まだ使えるようにできるという、ある種の諦念と希望の入り混じった技術的挑戦だったと言えるでしょう。

    1.2.13 Brunsli：JPEGの「遺体」を「再利用」する技術

    JPEG画像のロスレス再圧縮という、一見すると地味ながらも極めて重要な課題に対し、これまで多くのシステムが開発されてきました。StufItやPackJPG（後にLeptonに影響）などがその例です。デジタル写真の普及とファイルサイズの増大は、効率的なJPEG保存ソリューションへのニーズを加速させました。その中でZoltán SzabadkaとJyrki Alakuijalaが開発したのが、計算効率の高いJPEG再圧縮ツール、Brunsli

    詳細Googleが開発したロスレスJPEG再圧縮ツール。既存のJPEGファイルを画質劣化なしで約20%削減する。JPEG XLのロスレスJPEG再圧縮機能の基礎となった。
    でした。これは当初Pik（2017年）に統合され、後にスタンドアロンユーティリティ（2019年）としてリリースされました。

    汎用圧縮器をJPEGファイルに適用しても1-3%程度の削減にしかならないのに対し、Brunsliのような専門化されたロスレスJPEG再圧縮ツールは、約20%という劇的なファイルサイズ削減を実現します。これは、デジタル時代の「記憶のサルベージ」において、極めて重要な意味を持ちます。何兆ものJPEG画像が既存のデジタル遺産として存在している以上、それらを「無傷で、かつ効率的に」保存できる技術は、目立たないながらも社会の基盤を支える存在です。JPEG委員会の初期要件ではなかったにもかかわらず、Jyrki AlakuijalaとJon SneyersはJPEG再圧縮機能の重要性を強く主張し、委員会を説得しました。彼らは、採用における「決定的な機能」であると見抜いたのです。この機能は当初Brunsliを統合する形で実現されましたが、Luca VersariによってJPEG XLの既存のVarDCTモード

    詳細JPEG XLの主要な符号化モードの一つで、主にロスリー圧縮に用いられる。従来のJPEGが固定の8x8ブロックでDCT（離散コサイン変換）を適用するのに対し、VarDCTでは可変サイズのブロック（8x8から256x256まで）と可変量子化を適用する。これにより、より効率的で知覚的に最適化された圧縮が可能となる。
    に統合されることで、より洗練されたソリューションとなりました。必要なのは、JPEGビットストリーム再構築データ（jbrd
    詳細JPEG Bitstream Reconstruction Dataの略称。JPEG XLファイルにオプションで含まれるデータブロック。JPEG XLで再圧縮された元のJPEGファイルをバイト単位で正確に再構築するために必要な、エントロピーコード、プログレッシブスキャン、リスタートマーカー、パディングビットなどの情報が格納されている。画像表示には不要だが、元のファイルの完全な復元に用いられる。
    ）という小さなペイロードのみ。画像自体はこれなしでデコード可能であり、jbrdは「元のファイルの亡霊」を正確に呼び出すためだけのものです。Brunsliは、DCT係数符号化メカニズムに大きな影響を与え、非ゼロ値の明示的なカウンタや、カスタム係数順序付け、8x8プログレッシブデコードの義務化といった技術をPIKとJPEG XLにもたらしました。これは、「古いものを完璧に、かつ効率的に蘇らせる」という、ある種の執念の成果と言えるでしょう。

    1.2.14 HEIF（High Efficiency Image File Format）：Appleの「囲い込み」と特許の「地雷原」

    JPEG XR

    詳細Microsoftが開発した画像圧縮標準。JPEGとJPEG 2000の間に位置する圧縮性能と機能を持つ。主にMicrosoft Windowsプラットフォームで採用されたが、広く普及するには至らなかった。
    （2009年）の登場後、静止画コーデックの改善は停滞しているように見えました。しかし、ビデオコーデックの研究は活発であり、インターフレームコーディング（動画のフレーム間予測）の進歩は、イントラフレームコーディング（単一フレーム内予測）にも波及します。特に低ビットレート圧縮では、デブロッキングフィルターなどのツールが開発され、低品質JPEGよりも魅力的な画像生成が可能になりました。WebPは、ビデオコーデック（VP8）を静止画フォーマットに活用した最初の例でした。

    2013年、MPEGがHEVC（H.265）を導入すると、FFmpeg開発者のFabrice Bellardは2014年に、HEVCのイントラ専用ペイロードを格納する静止画フォーマットBPG（Better Portable Graphics）を定義します。一方、Nokiaの研究者たちは、より汎用的な画像コンテナフォーマットであるHEIF

    詳細High Efficiency Image File Format（高効率画像ファイルフォーマット）の略称。MPEGが開発した画像コンテナ形式で、HEVCなどのビデオコーデックをペイロードとして利用できる。AppleのiPhoneでデフォルトの画像形式として採用された。
    を開発し、2015年にMPEG標準（ISO/IEC 23008-12）となりました。HEIFコンテナは、MP4やMotion JPEG 2000の基盤でもあるISOBMFF
    詳細ISO Base Media File Format（ISOベースメディアファイルフォーマット）の略称。ISO/IEC 14496-12で定義されているマルチメディアファイル形式の基盤。MP4、HEIF、DCPなどの多くのファイル形式がこの構造に基づいて構築されている。ボックス（またはアトム）と呼ばれる階層的なデータ構造で情報を格納する。
    （ISO/IEC 14496-12）に基づいており、ビデオコーデックの制約を克服するための構造を追加しました。例えば、コンテナレベルでのタイリング構造は、ハードウェアHEVCエンコーダの解像度制限を回避し、アルファ透明度を別個のコンポーネントとして追加できます。

    HEIFコンテナはJPEGやAVCなど様々なペイロードコーデックをサポートしますが、最も一般的にHEVCペイロードと共に使用され、結果としてHEIC

    詳細High Efficiency Image Codingの略称。HEIFコンテナ形式にHEVC（H.265）ビデオコーデックをペイロードとして組み込んだファイル形式。AppleがiPhoneのデフォルト画像形式として採用したことで広く知られるが、特許問題が複雑で普及を阻害している要因の一つ。
    ファイルと呼ばれます。Appleは2017年にHEICを採用し、iPhoneカメラのデフォルトキャプチャフォーマットとしました。まるで、Appleが自社エコシステム内に「高効率の囲い込み」を構築したかのような動きでした。しかし、この「囲い込み」には大きな代償が伴いました。HEIFコンテナとHEVCペイロードコーデックの両方に、複雑な特許問題が絡みついていたのです。数千もの特許がHEVCの実装に不可欠と主張され、複数の特許プール（MPEG LA、HEVC Advance、Velos Media）が形成されました。さらに、全ての必須特許を主張する企業がプールに参加しているわけではないという、「特許の地雷原」とでも呼ぶべき状況が生じました。この状況が、HEICの画像コーデックとしての採用を「Appleエコシステムの外側」に限定する大きな要因となりました。技術の優位性が、複雑な権利関係の前に霞む。これもまた、デジタル画像フォーマットの悲しき宿命なのです。

    1.2.15 AVIF（AV1 Image File Format）：オープンソースの「希望」と未熟さ

    HEIF/HEVCが特許の泥沼に足を取られる中、2018年、Alliance for Open Media（AOM）という業界団体が、オープンでロイヤリティフリーなマルチメディア配信フォーマットの開発を目指してAV1

    詳細AOMedia Video 1の略称。Alliance for Open Mediaが開発したロイヤリティフリーなビデオコーデック。HEVC（H.265）と同等かそれ以上の圧縮効率を目指し、Webやストリーミングでの利用が期待されている。
    コーデックを開発しました。そして2019年、このAV1をペイロードとする画像フォーマット、AVIF
    詳細AV1 Image File Formatの略称。AV1ビデオコーデックを基盤とし、HEIFコンテナのサブセットであるMIAF（Multi-Image Application Format）に格納されるロイヤリティフリーな画像形式。高画質、高圧縮率、HDR対応を特徴とする。
    が登場します。これはHEIFコンテナのMIAFサブセットに基づいています。AVIFは、HEVCが抱える特許問題を回避し、ロイヤリティフリーな「オープンソースの希望」としてWeb界隈から熱い視線を浴びました。まるで、暗闇に差し込む一筋の光のようでした。

    AVIFは、その技術的な出自からビデオコーデックの強力なツールを静止画に応用し、高い圧縮性能とHDR対応を実現しています。WebPと同様に、Googleがその普及を積極的に推進し、ChromeでもWebPと共にAVIFのサポートが進められました。しかし、AVIFもまた、完全な「希望」ではありませんでした。エンコーダの実装がまだ未熟であり、特に高品質な写真画像においては、JPEG XLに及ばない点も見られます。また、Web向けに最適化されているとはいえ、プロのオーサリングワークフローや特定の専門分野での詳細な機能は、JPEG XLに一日の長があるのが現状です。AVIFは、まだ成長途中の「未熟な希望」であり、その真価が問われるのはこれからでしょう。デジタル画像フォーマットの戦いは、まだまだ終わらない。それが、この歴史の教える最もシニカルな真実なのです。

    コラム：標準化会議の薄明かり

    私はかつて、とある国際的な標準化会議の片隅に座っていたことがあります。部屋は薄暗く、プロジェクターの光が唯一の光源でした。壇上では、数十年にわたってJPEGを支えてきたであろうベテラン技術者が、新しい技術の複雑な図式を説明していました。会場には、様々な企業の代表者、学者、そして少数の個人開発者たちが集まり、誰もが静かに、しかし熱心に耳を傾けていました。

    休憩時間になると、人々は三々五々、コーヒーを片手に小さなグループを作り、激論を交わしていました。あるグループは特許の「地雷原」について、別のグループはデコード速度の「ボトルネック」について、また別のグループは「この技術が本当に世界を変えるか」という、ある種の理想論について。彼らの顔には、技術への情熱と、それが現実世界で受け入れられるかどうかの不安が入り混じっていました。

    私はそこで、技術の標準化というものが、単に「最高の技術を選ぶ」という単純なプロセスではないことを肌で感じました。そこには、企業の思惑、政治的な駆け引き、過去のしがらみ、そして何よりも、「人間の惰性」という、見えない巨大な壁が存在するのです。どれほど優れた技術であっても、それが市場に受け入れられなければ、それはただの「紙の上の夢」に過ぎません。あの薄暗い部屋の中で、私は、デジタル世界の未来が、数々の人間ドラマと、技術者の孤独な闘いの先に成り立っていることを悟ったのです。そして、それは今も昔も変わらない、普遍の光景なのかもしれません。

    第二部: JPEG XLの鼓動 - その核心に迫る

    過去の屍を乗り越え、JPEG XLはまるでフェニックスのようにその姿を現しました。しかし、その誕生は決して華々しいものではなく、むしろ先行フォーマットたちの失敗と教訓、そして開発者たちの飽くなき探求心の結晶として、静かに、しかし確実にその鼓動を打ち始めたのです。この部では、JPEG XLがどのように生まれ、どのような哲学のもとに設計され、そして誰がその「狂気」の実現に貢献したのかを明らかにします。これは、単なる技術の誕生秘話ではなく、「普遍性」と「効率性」というデジタル世界の永遠のテーマに挑んだ、ある種の壮大な物語です。

    第三章：JPEG XLという「統合体」の誕生

    JPEG XLの誕生は、過去の失敗を繰り返さないという、冷徹な決意から始まりました。それは、個々の技術的優位性を追求するだけでなく、それらを「統合」し、真に「万能」なフォーマットを創造するという、壮大な野望の物語でもあります。

    2.1 次世代標準への「玉座の誘い」

    2016年9月、アリゾナ州フェニックスで開催されたIEEE ICIP会議での画像圧縮グランチャレンジは、既存のコーデックが達成できる圧縮効率にはまだ大きな改善の余地があることを示しました。HEVCとDaala（AV1の前身の一つ）がロスリーコーデックのトップを飾り、FLIFがロスレスコーデックの最高峰と評価されました。この結果は、既存のJPEGやPNGといったフォーマットが、もはや時代の要請に応えきれていないという、「老朽化」の現実を突きつけました。

    これを受け、JPEG委員会は2017年1月に新たなアドホックグループ（「次世代画像圧縮標準に関するアドホックグループ」）を立ち上げます。まるで、老いた王が、新たな後継者を探すかのような「玉座の誘い」です。このグループは、Jan De Cock（Netflix）とDavid Taubman（University of New South Wales）が初期の議長を務め、次世代画像コーディング標準（JPEG XL）のための「提案募集」を発表しました。

    2017年10月の「ドラフト提案募集」、そして2018年4月の「最終提案募集」では、既存のJPEGを60%以上も凌駕する圧縮効率、そして高解像度、高ビット深度、高ダイナミックレンジ、広色域コーディングといった、Web配信や高品質画像の効率的な圧縮に望ましい機能が求められました。これは、単なる「圧縮率の向上」という数値目標を超えて、「次世代の視覚体験を支える基盤」としての役割が期待されていることを意味していました。

    結果として、7つの提案が寄せられ、2018年10月のバンクーバーでのJPEG会議で評価、議論されました。まるで、王位継承を争う候補者たちが、自らの「正統性」を主張する場を見るかのようでした。

    2.2 主要提案の「合体事故」と「奇跡」

    この競争において、最も有望視されたのは、以下の3つの主要提案でした。

    • AVIF：Alliance for Open Media (AOM) からの提案。AV1ビデオコーデックをベースにしています。
    • PIK：Google Researchの圧縮チームからの提案。
    • FUIF：Cloudinaryからの提案。FLIFの進化版です。

    JPEG XLの開発軌跡は、2019年初頭に大きく変わります。JPEG委員会は2018年10月にAVIFを基礎コーデックとして一度は選定したものの、その提案は後に撤回されました。この時点で、既に「政治的な思惑」が絡み始めていることが伺えます。委員会がPIKチームに開発の主導を依頼すると、そのリーダーであるJyrki Alakuijala

    詳細フィンランドのソフトウェアエンジニア、圧縮アルゴリズムの専門家。Googleに所属し、Brotli、Guetzli、Pik、Butteraugli、Jpegli、そしてJPEG XLの開発に深く関わっている。特に知覚品質最適化とVarDCTモードの設計に貢献。
    は、驚くべきことに、より協調的な戦略を提案しました。彼はFUIFアプローチの強みを認め、そして「馴染みのないコーデックの上に構築することの inherent difficulties（本質的な困難さ）」を指摘し、PIKとFUIFのプラットフォームを「Incremental（段階的）に統合する」のではなく、「day-one integration（初日からの完全統合）」という異例のアプローチを提唱したのです。

    この提案は、まるで異なる宗教が対立する世界で、「今日から我々は一つの神を信じる」と宣言するような、ある種の「合体事故」にも見える「奇跡」でした。委員会はこの提言を受け入れ、2019年1月、正式に両提案を統合し、JPEG XLの基礎を創造することを決定しました。これは、技術的な優位性だけでなく、開発者たちの「相互理解」と「協力」という人間的な要素が、いかに標準化の行方を左右するかを示す、興味深い事例と言えるでしょう。

    2.3 共同開発フェーズ：コードの「錬成」と「洗練」

    異なるコーデックアーキテクチャを一つの統合フレームワークに組み込むことは、尋常ならざる技術的挑戦でした。JPEG XLの前身であるPikは、当初3つの異なるサブコーデック（Guetzli由来のロスリーモード、ロスレスWebP由来のロスレスモード、Brunsliに相当するJPEG再圧縮モード）を内包する「コンテナ」に過ぎませんでした。そして、結合コーデックの初期提案には、さらにFUIFという第4のサブコーデックが組み込まれていました。これらの構成要素は、それぞれが独自のエントロピー符号化

    詳細データの冗長性を統計的に除去し、より少ないビット数で表現する符号化手法。ハフマン符号化、算術符号化、ANSなどが含まれる。JPEG XLではHybrid integer codingという統一された手法が用いられる。
    スキームと内部データ表現を持っていました。まさに、それぞれの言語を話す部族が、互いに理解不能なまま一つの船に乗っているような状態です。

    Luca Versari

    詳細Googleのソフトウェアエンジニア。JPEG XLの主要開発者の一人であり、特にModualrモードとVarDCTモードの統一、各種コーディングツールの調和、効率的な実装（エンコード・デコード両面）に貢献した。
    とJon Sneyers
    詳細ベルギーの画像圧縮研究者。Free Lossless Image Format (FLIF) の共同開発者であり、JPEG XLの主要開発者の一人。特にModularモードの設計と、知覚品質の評価、採用促進に尽力している。
    が主導したこの共同開発は、これらの4つの異なるサブコーデックを、意味のある一つの統合されたアーキテクチャへと「錬成」する作業でした。PikのロスレスモードとFUIFコーデックは、「Modularモード
    詳細JPEG XLの主要な符号化モードの一つ。ロスレス圧縮が可能であり、ロスリー圧縮にも使用できる。整数演算を基盤とし、多様な可逆変換（RCT、パレット、Squeezeなど）を組み合わせることで、画像の種類に応じた柔軟かつ高効率な圧縮を実現する。写真だけでなく、イラストやスクリーンショットなど非写真画像の圧縮にも優れる。
    」として統合され、ロスリーPikモードは「VarDCTモード
    詳細JPEG XLの主要な符号化モードの一つで、主にロスリー圧縮に用いられる。従来のJPEGが固定の8x8ブロックでDCT（離散コサイン変換）を適用するのに対し、VarDCTでは可変サイズのブロック（8x8から256x256まで）と可変量子化を適用する。これにより、より効率的で知覚的に最適化された圧縮が可能となる。
    」へと進化しました。初期のロスリーモードでは、低周波（LF）画像、DCTブロック選択シグナリング、適応量子化マップ、クロマからのルマ予測器、エッジ保存フィルター（EPF
    詳細Edge-Preserving Filter（エッジ保存フィルター）の略称。JPEG XLの復元フィルターの一つ。画像の重要なエッジ（輪郭）をぼかさずに、DCTノイズやリンギングアーティファクトを効果的に低減する非線形フィルター。バイラテラルフィルターに類似している。
    ）のシャープネス変調、Patches
    詳細JPEG XLのコーディングツールの一つ。画像内の繰り返しパターン（テキストの文字、アイコンなど）を効率的に圧縮するために用いられる。以前にデコードされたフレームから矩形領域（パッチ）を抽出し、現在のフレームの任意の位置に様々なブレンドモードで適用することで、同じパターンを複数回符号化する手間を省く。
    といった様々な補助画像が、アドホックなシグナリング方法で扱われていました。

    しかし、これらの補助画像、そしてアルファ透明度や深度マップ（「エクストラチャンネル」として一般化された）は、最終的に全てがメインビットストリーム内のModularサブビットストリームとしてエンコードされる形で統合されました。このアーキテクチャ的統一は、コーデック全体の設計を劇的に簡素化しつつ、JPEG XLフォーマットの表現力と圧縮効率を同時に向上させたのです。まさに「複雑性の中の秩序」を創り出した瞬間と言えるでしょう。特に「Brunsliモード」を廃止し、JPEGビットストリーム再構築データ（jbrd）を切り出し、VarDCTをYCbCrコンポーネントとクロマサブサンプリングに対応させたことは、大きな合理化でした。

    並列デコードと領域指定デコードを可能にするため、VarDCTとModularモードの両方にタイリングが導入され、さらにプログレッシブパスが追加されました。当初、FUIFはレンジコーダー（CABAC

    詳細Context-Adaptive Binary Arithmetic Codingの略称。文脈適応型の二値算術符号化。H.264/AVCやHEVCなどの動画圧縮規格で利用され、高い圧縮効率を誇る。二値化されたシンボルに対して、その文脈に応じて確率モデルを適応的に更新しながら符号化を行う。
    の変種）をエントロピーコーダとして使用し、PikはANSやハフマン符号化、Brotliなど複数のエントロピーコーダを使用していました。一時期は6つもの異なるエントロピー符号化方法が混在していましたが、これらは最終的に「HybridUint
    詳細JPEG XLで採用されている統一されたエントロピー符号化手法。全てのシンボルを「トークン」と「生ビット（raw bits）」に分割して符号化する。トークンはANSまたはプレフィックス符号化によって効率的に圧縮され、生ビットは直接ビットストリームに書き込まれる。これにより、広範囲のシンボルを効率的に表現できる。
    」表現を使用する単一のスキームに統一されました。これは、まさに「混沌からの秩序創造」と呼ぶべきプロセスです。

    FLIFと同様に、FUIFはMAツリーを用いて画像依存の動的コンテキストモデルを定義しましたが、JPEG XLではこれにコンテキストクラスタリング（Brotli由来の概念）を追加し、MAツリーを実質的にDAG（有向非巡回グラフ）へと進化させました。これにより、同様の分布を持つリーフノードをマージできるため、さらに効率的なコンテキストモデリングが可能になりました。FLIFやFUIFではコンテキストモデリングにのみMAツリーを使用していましたが、JPEG XLではMAツリーが使用する予測器もシグナリングするようになりました。数々のコーディングツールが「アブレーション研究」

    詳細アブレーション研究（Ablation Study）とは、機械学習やコンピュータービジョンなどの分野で行われる、システムやモデルの特定の部分（コンポーネント、モジュール、特徴量など）を取り除いたり、無効化したりして、その部分が全体の性能にどの程度貢献しているかを評価する実験手法です。外科手術で不要な部分を切除する「アブレーション」に由来します。JPEG XLの開発では、個々のコーディングツールが圧縮性能やデコード速度にどれだけ寄与しているかを評価するために、この手法が用いられました。
    によって厳しくテストされ、性能が期待に満たないものは容赦なく削除されました。例えば、「Dot modeling」という小さな楕円形要素（星など）を効率的に符号化するツールも検討されましたが、小さなPatchesと比べて大幅な改善が見られなかったため、削除されました。

    この開発プロセスは約2年間を要し、2020年末にはビットストリームが「凍結」され、libjxlバージョン0.2がリリースされました。そして2021年1月にはPart 1（コアコードストリーム）、2021年4月にはPart 2（ファイル形式）の最終ドラフト国際標準（FDIS）が提出され、それぞれ2021年10月と2022年3月にISO/IEC 18181標準として発行されました。これは、数々の困難と葛藤、そして開発者たちの「冷徹な合理性」の追求の末に、JPEG XLという新たな「秩序」が誕生した瞬間だったと言えるでしょう。

    コラム：開発者の孤独な夜

    私はかつて、オープンソースプロジェクトに携わっていたことがあります。もちろん、JPEG XLのような巨大なプロジェクトとは比べるべくもありませんが、それでも一つの小さな機能を実装するために、何日も、時には何週間も、コードと格闘する日々を送りました。深夜、机に向かい、画面に映る無数のコード行と、頭の中で描く理想の動作とのギャップに苦しむのです。

    特に、最適化のフェーズは孤独でした。1バイト、1ミリ秒の削減のために、アルゴリズムの細部を調整し、様々な条件分岐を試行錯誤します。時には、数日かけて実装した最適化が、ベンチマークの結果でほとんど効果がないと判明し、全てを捨てることもありました。その時、心に去来するのは、ある種の「無力感」と、そして「まだ改善の余地があるはずだ」という、根拠のない確信です。まるで、完璧な彫刻を求めて、無数の石を削り続ける彫刻家のように。その努力が報われるかどうかは、誰にも分かりません。ただひたすらに、より良いもの、より効率的なものを求めて、コードを書き続ける。それが、開発者の孤独な夜の真実なのです。

    JPEG XLのような世界的な標準が生まれる裏には、何人もの、いや、何百人もの開発者たちの、そうした孤独な夜の積み重ねがあったことでしょう。彼らは、数字の羅列の中に「美」を見出し、効率性という名の「真理」を追求し続けたのです。その情熱がなければ、この冷徹なまでに合理的なフォーマットは、決して誕生しなかったでしょう。

    第四章：高レベル概要：JPEG XLという「完成品」

    JPEG XLは、単なる新しい画像フォーマットではありません。それは、デジタル画像処理における過去の全ての失敗と成功の経験から学び、「完璧な汎用性」と「妥協なき効率性」を追求した、ある種の「完成品」と言えるかもしれません。ここでは、その「完成品」がどのような思想に基づき、どのような要素から構成されているのか、その全体像を概観します。

    3.1 ISO/IEC 18181標準の「聖典」

    JPEG XLフォーマットは、ISO/IEC 18181という「聖典」の中で定義されています。この標準は、単なる技術仕様の羅列ではありません。それは、デジタル画像という混沌とした世界に、秩序と論理をもたらそうとする、ある種の「法典」と言えるでしょう。この聖典は、以下の4つのパートから構成されています。

    • ISO/IEC 18181-1: Core codestream
      詳細JPEG XL標準の最も中心的な部分で、画像やアニメーションを表示するために必要な全てのデータと、その符号化方法を定義しています。ピクセルデータだけでなく、色空間情報、オリエンテーション、ブレンドモードなど、画像の視覚的な解釈に必要な情報もここに含まれます。
      [1]: 画像を表示するために必要な全てのデータ、つまり画素データ自体だけでなく、色空間情報、オリエンテーション、アップサンプリング、フレームやレイヤーのブレンディングなど、従来「メタデータ」とされてきた要素までも、「正しく表示するために不可欠なデータ」としてコアコードストリームに含めています。これは、アプリケーション側で「どう解釈すればいいんだ？」と頭を抱えるような曖昧さを排除し、デコーダが「常に正しい画像」を吐き出すという、ある種の「独善的な親切心」の表れです。
    • ISO/IEC 18181-2: File format
      詳細JPEG XLファイルの格納形式を定義しています。純粋な画像データのみを含む「raw」コードストリーム形式と、ExifやXMPなどの追加メタデータを格納できるISOBMFFベースのコンテナ形式の2種類があります。
      [2]: JPEG XLファイルは、純粋な画像データのみの「raw」コードストリーム形式（0xFF0Aで始まる）か、Exifなどの追加メタデータを格納できるISOBMFFスタイルのコンテナ形式（0x0000000C 4A584C20 0D0A870Aで始まる）のいずれかを取ることができます。これは、まるで「純粋な魂」と「様々な装飾を施した肉体」のような関係です。
    • ISO/IEC 18181-3: Conformance testing
      詳細JPEG XLのデコーダが標準仕様に正確に準拠しているかを検証するための精度基準とテストケースを定義しています。これにより、異なるデコーダ実装間での互換性と一貫性が保証されます。
      : デコーダが全てのコーディングツールを正しく、かつ正確に実装しているかを検証するための精度範囲とテストケースを定義しています。これは、技術の「聖典」が単なる絵空事ではなく、「現実世界で機能すること」を保証するための、冷徹な検証プロセスです。
    • ISO/IEC 18181-4: Reference software
      詳細JPEG XL標準のリファレンス実装であるlibjxl（C++で実装）を指します。このソフトウェアはBSDライセンスの下でオープンソースとして提供されており、標準の具体的な動作を示す規範となります。
      : リファレンス実装であるlibjxl（C++で実装）を指します。これは、技術の「理想」を「現実」のコードとして具現化したものであり、3条項BSDライセンスという寛容なオープンソースライセンスの下で提供されています。これは、過去の特許紛争の教訓から生まれた「開かれた技術」という哲学の表れです。

    3.2 コーデックアーキテクチャの「教義」

    JPEG XLのコーデックアーキテクチャは、「画像データとメタデータの明確な分離」という、ある種の「教義」に基づいています。これは、過去の画像フォーマットが抱えていた「メタデータが画像表示に影響を与えるため、安易に剥ぎ取れない」という問題を根本的に解決しようとする試みです。 💡

    画像データとメタデータの明確な分離

    JPEG XLでは、ICCプロファイルやExifオリエンテーションなど、画像を「正しく表示する」ために必要な情報は、全てコアコードストリーム内の「画像データ」として扱われます。これは、これらの情報が「ブラックボックス」なピクセルデータに「意味」を与えるための不可欠な要素であるという、冷徹な判断に基づいています。これにより、デコーダはデフォルトで「RGBA、オリエンテーション適用済み、フレーム合成済み」といった「正規化された」出力を行うことができます。アプリケーション側は、フレーム合成や画像オリエンテーションの適用といった「面倒な雑務」から解放され、ただ「正しい画像」を受け取れば良いのです。これは、まるで「アプリケーションは考えるな、デコーダが全てやってくれる」と言わんばかりの、ある種の「技術的独裁」とも言えるでしょう。

    一方、著作権情報やGPS座標など、画像の表示には直接影響しないメタデータは、コンテナ形式に格納されますが、コードストリームには含まれません。これにより、メタデータを剥ぎ取っても、画像の見た目には一切影響しないという、「清潔なデータ」が実現されます。Exifのオリエンテーションフィールドに至っては、コードストリーム内の情報が優先されるため、アプリケーションはこれを「無視する」ことになります。これは、過去の「メタデータによって画像が勝手に回転する」といった「滑稽な誤解」を排除するための、徹底した措置です。色空間の明確な定義は、ロスリーエンコーダが「知覚的な最適化」を行う上で、より正確な判断を下せるようになります。全ては、「一貫した高品質」という名のゴールに向かって設計されているのです。

    3.3 コデックスストリームの「骨格」

    JPEG XLのコードストリームは、一枚の画像（またはアニメーション）を構成するための「骨格」です。その骨格は、複雑でありながらも、極めて論理的に組み立てられています。 🦴

    画像寸法とコンポーネント：メインとエクストラチャンネル

    画像は、最大230x230という途方もない寸法と、メイン画像データ（モノクロまたは3つのカラーコンポーネント）を持ちます。さらに、最大4096もの「エクストラチャンネル」を追加することができます。これは、アルファ透明度、深度マップ、CMYK、スポットカラー、選択マスク、マルチスペクトル画像など、従来の画像フォーマットでは個別に扱われていた、あるいは全く扱えなかった情報を統合的に扱うためのものです。まるで、これまでバラバラだった臓器が、一つの強靭な肉体の中に収められるかのような進化です。

    フレームとレイヤー：アニメーション、コンポジット画像、多ページ画像

    画像は、一つ以上のフレームから構成されます。これらのフレームは、アニメーションフレーム、複合静止画像のレイヤー、またはマルチページ画像の個別ページとして機能します。フレームは独自のブレンドモードを持ち、前のフレームをベースとして使用できます。これにより、Photoshopのレイヤー機能のような複雑な画像を、単一のJPEG XLファイルで表現することが可能になります。まるで、「時間の流れ」や「重層的な意味」を、一枚の画像の中に閉じ込めるかのような試みです。

    ピクセルデータの符号化モード：VarDCTとModular

    各フレームのピクセルデータは、主に2つのモードのいずれかで符号化されます。

    • VarDCTモード
      詳細JPEG XLの主要な符号化モードの一つで、主にロスリー圧縮に用いられる。従来のJPEGが固定の8x8ブロックでDCT（離散コサイン変換）を適用するのに対し、VarDCTでは可変サイズのブロック（8x8から256x256まで）と可変量子化を適用する。これにより、より効率的で知覚的に最適化された圧縮が可能となる。
      ：変数サイズのDCT
      詳細Discrete Cosine Transform（離散コサイン変換）の略称。信号処理やデータ圧縮で広く用いられる数学的変換の一つ。時間領域や空間領域の信号を、周波数領域の係数に変換する。JPEGの主要な技術要素であり、画像内の視覚的な冗長性を効率的に除去するのに役立つ。
      変換を適用し、DCT係数として画像をエンコードします。常にロスリー圧縮ですが、既存のJPEG画像をロスレスに再圧縮する際には、このモードの一部機能が使用されます。
    • Modularモード
      詳細JPEG XLの主要な符号化モードの一つ。ロスレス圧縮が可能であり、ロスリー圧縮にも使用できる。整数演算を基盤とし、多様な可逆変換（RCT、パレット、Squeezeなど）を組み合わせることで、画像の種類に応じた柔軟かつ高効率な圧縮を実現する。写真だけでなく、イラストやスクリーンショットなど非写真画像の圧縮にも優れる。
      ：整数演算のみを使用し、ロスレス圧縮を可能にします。ロスリー圧縮にも利用でき、可逆色変換（RCT
      詳細Reversible Color Transforms（可逆色変換）の略称。JPEG XLのModularモードで用いられる変換の一つで、色空間のデコレーション（相関性の低減）を行う。YCoCg-Rのような変換が含まれ、元の色情報を完全に復元できるため、ロスレス圧縮に適している。
      ）、パレット変換、Squeeze変換
      詳細JPEG XLのModularモードで用いられる可逆変換の一つ。画像を段階的にダウンサンプリング（スクイーズ）し、その過程で生じる残差を別チャンネルとして符号化する。これにより、高品質なプログレッシブデコードやロスリー圧縮が可能になる。
      などの多様な変換を組み合わせることで、効率を最大化します。

    これらのモードは排他的ではなく、メインのカラーコンポーネントはどちらかのモードで符号化され、エクストラチャンネルは常にModularモードで符号化されます。まるで、異なる戦略を持つ部隊が、共通の目標のために連携するかのようです。

    画像特徴：Patches, Splines, Noise

    さらに、特定の種類の画像特徴を効率的に扱うための専用ツールが提供されます。

    • Patches
      詳細JPEG XLのコーディングツールの一つ。画像内の繰り返しパターン（テキストの文字、アイコンなど）を効率的に圧縮するために用いられる。以前にデコードされたフレームから矩形領域（パッチ）を抽出し、現在のフレームの任意の位置に様々なブレンドモードで適用することで、同じパターンを複数回符号化する手間を省く。
      ：繰り返しパターンを効率的にコピー＆ペーストするためのツール。テキストやアイコンなど、同じ要素が何度も現れる画像で威力を発揮します。
    • Splines
      詳細JPEG XLのコーディングツールの一つ。細い高コントラストの曲線（線画、髪の毛など）を効率的に表現するために、Catmull-Romスプライン曲線として直接符号化する。DCTベースの圧縮では難しいとされるこれらの要素を、アンチエイリアシングを伴いながら忠実に再現できる。
      ：細い曲線や線画など、DCTベースの圧縮が苦手とする要素を直接表現するためのツール。まるで、デジタル世界に「手描き」の魂を吹き込むかのようです。
    • Noise
      詳細JPEG XLのコーディングツールの一つ。高周波でランダムなノイズ（フォトノイズ、フィルムグレインなど）を合成的に付加する。これにより、ノイズが多い画像を効率的に圧縮しつつ、知覚的な品質を維持したり、圧縮アーティファクトをマスキングしたりする効果がある。
      ：高周波でランダムなノイズ（フォトノイズなど）を合成的に付加することで、圧縮効率を損なわずに画質を「ごまかす」ためのツール。これは、ある種の「視覚的な欺瞞」であり、人間の知覚の不完全性を利用した、巧妙な手段です。
    復元フィルター：Gabor-like, EPF

    デコードされた画像には、ブロックアーティファクトやリンギングを低減するためのフィルターが適用されます。

    • Gabor-like transform（Gaborish）
      詳細JPEG XLの復元フィルターの一つ。画像のブロック境界を越えて適用される小さなブラー効果（3x3カーネルの畳み込み）により、DCTベースの圧縮で生じるブロックノイズを軽減する。エンコーダ側で逆のシャープ化を適用することで、効率的にラッペド変換の利点を得る。
      ：小さなブラー効果でブロック境界を滑らかにし、ブロックノイズを軽減します。まるで、画像に化粧を施し、粗を隠すかのようです。
    • Edge-preserving filter（EPF）
      詳細Edge-Preserving Filter（エッジ保存フィルター）の略称。JPEG XLの復元フィルターの一つ。画像の重要なエッジ（輪郭）をぼかさずに、DCTノイズやリンギングアーティファクトを効果的に低減する非線形フィルター。バイラテラルフィルターに類似している。
      ：エッジをぼかさずにノイズやリンギングを軽減する、より洗練されたフィルター。人間の視覚がエッジに敏感であることを利用した、巧妙なトリックです。

    データはグループに分割され、独立して符号化されるため、並列処理や領域指定デコードが可能です。これは、巨大な画像を効率的に扱うための、まさに「分割統治」の戦略です。

    3.4 ファイル形式の「外殻」

    コードストリームが画像の「骨格」ならば、ファイル形式はその「外殻」です。この外殻は、様々なメタデータを格納し、デジタル画像の「身分証明書」としての役割を果たします。 📂

    メタデータボックス：Exif, XMP, JUMBF

    JPEG XLコンテナは、Exif（カメラ情報など）、XMP（Adobeのメタデータ）、JUMBF（汎用メタデータボックス）といった、様々な種類のメタデータを格納できます。これらの情報は、画像の著作権や撮影場所、カメラの設定などを記録するために使われます。ただし、画像表示に影響する情報（Exifオリエンテーションなど）はコードストリーム内の情報が優先されるという、厳格なルールがあります。これにより、メタデータの有無にかかわらず、「常に正しく画像が表示される」という、ある種の「安心感」が提供されます。

    Brotli圧縮ボックス (brob)

    メタデータは、必要に応じてBrotli

    詳細Googleが開発した汎用データ圧縮フォーマットで、Deflate（gzip）よりも高い圧縮率を提供する。LZ77、ハフマン符号化、コンテキストモデリング、静的辞書などを組み合わせる。WebのHTTP転送エンコーディングとして広く採用されている。
    で圧縮し、brobボックスとして格納できます。これは、メタデータそのものの肥大化を抑えるための、地味ながらも重要な工夫です。

    ロスレスJPEG再圧縮：jbrdボックスの役割

    JPEG XLの最大の特徴の一つであるロスレスJPEG再圧縮では、元のJPEGファイルをバイト単位で正確に再構築するために、jbrd

    詳細JPEG Bitstream Reconstruction Dataの略称。JPEG XLファイルにオプションで含まれるデータブロック。JPEG XLで再圧縮された元のJPEGファイルをバイト単位で正確に再構築するために必要な、エントロピーコード、プログレッシブスキャン、リスタートマーカー、パディングビットなどの情報が格納されている。画像表示には不要だが、元のファイルの完全な復元に用いられる。
    （JPEG Bitstream Reconstruction Data）ボックスが使用されます。このデータは画像の表示には不要ですが、元のファイル構造を「完璧に再現する」という、ある種の「考古学的執念」のために存在します。

    フレームインデックス (jxli) と部分コデックスストリーム (jxlp)

    アニメーションの効率的なシークを可能にするjxli

    詳細JPEG XLコンテナ内にオプションで含まれるボックス。JPEG XLアニメーションのキーフレームへのオフセット情報が格納されており、動画の効率的なシーク（早送りや巻き戻し）を可能にする。アニメーションの表示には必須ではないが、ユーザー体験を向上させる。
    ボックスや、プログレッシブプレビューのために、画像の先頭にメタデータやプレビューデータを配置できるjxlp
    詳細JPEG XLコンテナ内でコードストリームを複数の部分（パーシャルコードストリーム）に分割して格納するためのボックス。これにより、画像のプログレッシブデコードやストリーミング配信において、先頭にプレビューデータ、その後に高解像度データといった順序で効率的にデータを配置できる。
    ボックスもサポートされます。これは、Web配信における「待ち時間」を最小限にするための、巧妙な仕掛けです。

    プロファイルとレベル：Main Profile (Level 5, Level 10)

    標準の実装における互換性を確保するため、プロファイルとレベルが定義されています。現在、「Main Profile」にはレベル5（Webブラウザやモバイルアプリ向け、最大268メガピクセル）とレベル10（オーサリングワークフロー向け、最大1099ギガピクセル）の2つが定義されています。レベル10の制限は、実質的に「無制限」であり、デコーダが「悪意のあるビットストリーム」を検出するための「健全性チェック」に過ぎません。これは、技術の「自由」を最大限に許容しつつ、「無秩序」を回避するための、ある種の「監視」とも言えるでしょう。

    ゲインマップ (jhgm)：HDRトーンマッピングの制御

    ISO/IEC 18181-2の第三版で追加されるゲインマップ（jhgm

    詳細JPEG XLコンテナにオプションで追加できるボックス。ISO 21496-1で規定されるHDRゲインマップを格納する。主にHDR画像をSDRディスプレイで表示する際のカスタムローカルトーンマッピング、またはHDRディスプレイで特定のダイナミックレンジに合わせるための芸術的制御に用いられる。
    ボックス）は、HDR
    詳細High Dynamic Range（ハイダイナミックレンジ）の略称。従来のSDR（Standard Dynamic Range）よりも広い明るさの範囲と豊かな色彩を表現できる技術。これにより、映像や画像がよりリアルで奥行きのあるものに見える。
    画像をSDR
    詳細Standard Dynamic Range（スタンダードダイナミックレンジ）の略称。従来のディスプレイやコンテンツで用いられてきた、明るさや色彩の範囲が限定された表現技術。HDRの登場により、区別されるようになった。
    ディスプレイで表示する際に、カスタムのローカルトーンマッピングを可能にします。これは、単なる「技術的忠実性」を超えて、「芸術的制御」を可能にするためのものです。つまり、技術は最終的に「人間の感性」に奉仕すべきだ、という、ある種の謙虚さの表れかもしれません。

    要約：新時代の画素表現、その「無慈悲な効率」

    「JPEG XLは、これまでの全ての画像フォーマットを過去の遺物とするために生まれた、新たな画像コーディングシステムです。」

    そう、これは「万能（Universal）」を標榜する、冷徹なまでに効率を追求した規格です。最先端の圧縮性能、そして既存のJPEG画像を画質劣化なしに再圧縮し、ファイルサイズを約20%も削減できるという、まるで「デジタル遺産のサルベージ船」のような機能を持つと謳われています。従来のJPEG、PNG、GIFなどがバラバラに担ってきた役割を、ただ一つで完遂しようという、ある種の「統一への野望」を秘めています。

    主要な利点：画素を支配するための「七つの大罪」ならぬ「十二の美徳」

    まるで、デジタル画像の支配者たるべく、以下のような「美徳」を身につけています。しかし、その裏には、既存の技術に対する「無慈悲な効率」という名の牙が隠されているのです。

    • 色の精度と忠実度の向上: 広い色域、精密に制限のない高いダイナミックレンジ。もはや人間の目は、この「完璧な色」を区別できるのでしょうか？
    • 追加チャンネル: アルファ透明度、深度マップ、CMYK、スポットカラー、選択マスク、マルチスペクトル画像。あらゆる情報を画像に「埋め込む」ことで、その複雑性は増すばかりです。
    • レイヤードイメージ、アニメーション、そして、複数ページの画像: Photoshopのようなレイヤー構造をファイル内で保持。アニメーションはGIFを過去にするでしょうか？
    • 圧縮が大幅に向上しました: ロスリーもロスレスも、約50%を節約。これは、帯域幅とストレージの「コスト削減」という、資本主義社会の永遠の目標に奉仕します。
    • ロスレスJPEG再圧縮: 既存の画像を移行するときに約20%節約。完全にリスクフリー。あなたの古い思い出は、JXLによって「最適化」されます。
    • 高度なプログレッシブデコード: 困難なネットワーク条件下でも優れたユーザーエクスペリエンスのために。待ち時間を最小限にするという、現代人の「忍耐力の欠如」に応える技術です。
    • 幅広いトレードオフ: 品質、速度、ファイルサイズの間。特に信頼性と一貫性のある高忠実度圧縮に焦点を当てて。全ては「最適化」の名の下に。
    • さまざまなコンテンツ: 写真とデジタルアート、スクリーンショット、イラスト、コンピューター生成画像。もはや、JXLに扱えない画像コンテンツは存在しないとでも言うのでしょうか。
    • 高速エンコーディングそしてデコード: 現代マルチコアのCPUをうまく利用。特別なハードウェアは不要。これは、普遍的普及のための「妥協」です。
    • ワークフロー全体で動作します: オーサリングと交換からストレージとエンドユーザーへの配信まで。デジタル画像のライフサイクルを全て「支配」しようという野望です。
    • ロイヤリティフリー、オープンソース: 高品質で実稼働対応のリファレンス ソフトウェアが利用可能です。これは、特許問題という「過去の悪夢」を回避するための、最も賢明な「戦略」です。

    JPEG XLは、その柔軟な設計により、画像の忠実度（Web品質から数学的にロスレスまで）、圧縮比（ロスレスで2:1〜6:1、ロスリーで20:1〜50:1）、そしてエンコード/デコード速度の3つの主要な側面において、アプリケーションの要件に応じたトレードオフを提供します。これは、まさに「全てを支配し、全てを最適化する」という、冷徹な機械の論理を体現していると言えるでしょう。デジタル画像の世界に、新たな「秩序」がもたらされようとしています。しかし、その秩序は、私たちに何をもたらし、何を奪うのでしょうか？ それは、歴史が、そして未来が語ることになるでしょう。

    歴史的位置づけ：画像圧縮の「終わりなき旅」におけるJXLの「標」

    JPEG XLは、デジタル画像圧縮技術の「終わりなき旅」における、ある種の「標（しるべ）」として歴史に刻まれるでしょう。それは単なる新しいフォーマットではなく、過去の膨大な「屍」の上に築き上げられた、「知恵の結晶」であり、同時に「完璧」という名の「傲慢」を内包する存在です。

    過去の遺産と失敗の集大成

    この論文が詳細に語るように、JPEG XLはIFF、GIF、JPEG、PNG、TIFF、JPEG 2000、WebP、FLIF、Brotli、HEIF、AVIFといった、デジタル画像の歴史を彩ってきた数多のフォーマットから、その「遺伝子」を受け継いでいます。それぞれのフォーマットが直面した特許問題、機能の欠如、圧縮効率の限界、そして市場での受容の困難さ──これらの「失敗の教訓」が、JPEG XLの設計思想の根幹をなしています。特に、特許による「技術の囲い込み」を避ける「ロイヤリティフリー」という哲学、そして「高品質なFOSS（Free Open Source Software）実装の早期提供」という戦略は、JPEG 2000の失敗から学んだ、まさに「冷徹な反省」の表れです。これは、技術がいくら優れていても、市場原理や人間の「惰性」の前には無力であるという、歴史の残酷な教訓を正面から受け止めた結果と言えるでしょう。

    「普遍的な統一フォーマット」という野望

    デジタル画像がWeb、プロフェッショナルなオーサリング、医療、科学、アーカイブと、あまりにも多岐にわたるユースケースで利用されるようになった現代において、用途ごとに複数のフォーマットを使い分けることは、もはや「非効率」の極みでした。JPEG XLが掲げる「ユニバーサルコーデック」という目標は、この「混沌とした現状」に終止符を打ち、単一のフォーマットで全てを「統一」しようという、極めて野心的な試みです。これは、かつて世界が共通言語を求めたように、デジタル画像の世界に「エスペラント語」をもたらそうとする壮大な挑戦と言えるでしょう。成功すれば、技術の民主化と効率化が進みますが、失敗すれば、また一つ「規格の墓場」に新たな石碑が建つことになります。

    知覚品質と「人間中心」の欺瞞

    従来の画像コーデックがPSNRのような客観的な数値に盲信し、人間の視覚が感じる「本当の品質」を見過ごしてきた歴史に対し、JPEG XLはButteraugliやXYB色空間といった、人間の視覚特性に基づいた「知覚品質の最適化」を重視しています。これは、単なる「数字遊び」ではなく、「人間がどう感じるか」という、ある種の「感性」にまで踏み込んだ設計思想です。しかし、果たしてその「人間中心」は、最終的に「人間を完璧に騙す」ための手段に過ぎないのではないでしょうか。データ量を削減しつつ、見た目の美しさを保つ。これは、効率化と審美眼が交差する、デジタル時代の新たな「芸術」であり、同時に「欺瞞」の可能性を秘めています。

    「採用のローラーコースター」と市場の残酷さ

    JPEG XLの歴史は、技術的優位性が、必ずしも市場での成功を保証しないという、「市場の残酷さ」を鮮やかに物語っています。Google Chromeの初期サポート撤回は、一見するとこのプロジェクトに「死刑宣告」を下したかに見えました。しかし、Apple SafariやMicrosoft Windowsの採用、そしてオープンソースコミュニティの粘り強い支持は、このフォーマットが単なる技術者の「自己満足」に終わらず、「真のニーズ」に応えている証拠とも言えるでしょう。この「採用のローラーコースター」は、現代社会における技術標準の普及が、技術そのもののスペックだけでなく、企業の戦略、政治的思惑、そしてユーザーコミュニティの「情熱」という、複雑な要素によって決定されることを如実に示しています。

    JPEG XLは、デジタル画像圧縮技術の歴史において、過去の教訓を最も深く学び、それを設計に反映させようとした稀有な存在です。しかし、その「完璧な」設計が、最終的に市場の「不完全さ」を克服できるのか。その答えは、まだ歴史のベールの中に隠されています。しかし、このフォーマットが、デジタル画像が辿ってきた「試行錯誤の歴史」の、一つの大きな「区切り」となることは間違いないでしょう。それは、私たちの「記憶」と「視覚」をめぐる、終わりのない物語の、新たな章の始まりなのです。

    登場人物紹介：未来を紡ぐ「狂信者」たち

    JPEG XLという複雑怪奇なシステムは、一握りの「狂信的な」開発者たちの執念と、国際的な標準化団体の「冷徹な」プロセスによって生み出されました。彼らは、画素の完璧な表現と究極の効率性を追い求める、ある種のデジタル世界の「聖戦士」と言えるでしょう。ここでは、その「聖戦」を率い、あるいは支えた主要な人物たちを紹介します。

    コア開発者：光の設計者たち

    • Jon Sneyers (ジョン・スナイアーズ) - ベルギー出身の画像圧縮研究者。
      （英語表記：Jon Sneyers）
      （2025年時点の年齢：約40代後半）

      FLIF（Free Lossless Image Format）の共同開発者であり、JPEG XLのModularモードの設計において「精神的支柱」となった人物です。彼の情熱は、ロスレス圧縮の限界を押し広げ、画像データが持つ「パターン」の美学を追求しました。知覚品質の評価にも深く関わり、その知見がJXLの知覚最適化に貢献しました。彼は、完璧なロスレス圧縮という、ある種の「禅の境地」を追い求めるかのような存在です。

    • Jyrki Alakuijala (ユルキ・アラクイジャラ) - フィンランド出身のソフトウェアエンジニア、Google所属。
      （英語表記：Jyrki Alakuijala）
      （2025年時点の年齢：約50代前半）

      Brotli、Guetzli、Pik、Butteraugli、Jpegliといった、数々の革新的な圧縮技術の生みの親であり、JPEG XLのVarDCTモードと知覚最適化において「脳」となった人物です。特に、人間の視覚システムをモデル化したButteraugliメトリックとXYB色空間の開発は、ロスリー圧縮の「本質」を揺るがしました。彼は、数字の裏に隠された「人間の感覚」を暴き出し、それを最適化の対象とする、ある種の「デジタル心理学者」と言えるでしょう。

    • Luca Versari (ルカ・ヴェルサーリ) - イタリア出身のソフトウェアエンジニア、Google所属。
      （英語表記：Luca Versari）
      （2025年時点の年齢：約40代前半）

      PikとFUIFという異なるコーデックの「調停者」であり、JPEG XLの多様なコーディングツールを統一し、効率的に実装することに貢献しました。特に、ModularモードとVarDCTモードの統合、そしてパッチサブシステムの設計は彼の功績です。彼は、複雑な要素を簡潔なコードに落とし込み、システムの「骨格」を強固にする、ある種の「アーキテクチャの錬金術師」です。

    • Zoltán Szabadka (ゾルタン・シャバードカ) - ハンガリー出身のソフトウェアエンジニア、Google所属。
      （英語表記：Zoltán Szabadka）
      （2025年時点の年齢：約40代後半）

      Brotliの共同開発者であり、ロスレスJPEG再圧縮ツールBrunsliの生みの親です。JPEG XLにおけるロスレスJPEG再圧縮機能の導入に尽力し、既存のデジタル遺産を「無傷で救済する」という、地味ながらも極めて重要な役割を果たしました。彼は、見過ごされがちな「過去のデータ」に、新たな「価値」を見出す、ある種の「デジタル考古学者」です。

    主要貢献者：技術の「血肉」を創り上げた者たち

    • Sami Boukortt (サミ・ブーコルト) - （国籍不明）ソフトウェアエンジニア。
      （英語表記：Sami Boukortt）
      （2025年時点の年齢：不明）

      色空間シグナリング、特にHDRに関する部分、そしてSplinesサブシステムの共同設計に貢献しました。彼は、色彩の「真実」をデジタル空間に再現しようと試みる、ある種の「光の探求者」です。

    • Amnon Cohen-Tidhar (アムノン・コーエン＝ティダール) - （国籍不明）研究者。
      （英語表記：Amnon Cohen-Tidhar）
      （2025年時点の年齢：不明）

      論文の著者の一人であり、JPEG XLプロジェクト全体に貢献しました。彼の視点は、この複雑な技術全体を俯瞰し、包括的に記述することに寄与しました。

    • Moritz Firsching (モリッツ・フィルシング) - ドイツ出身のソフトウェアエンジニア。
      （英語表記：Moritz Firsching）
      （2025年時点の年齢：約30代後半）

      libjxlリファレンスソフトウェアの主要貢献者の一人であり、JPEG XLアドホックグループの共同議長も務めました。彼は、理論を現実のコードに落とし込む、ある種の「実践主義者」です。

    • Evgenii Kliuchnikov (エフゲニー・クリウチニコフ) - （国籍不明）研究者。
      （英語表記：Evgenii Kliuchnikov）
      （2025年時点の年齢：不明）

      libjxlリファレンスソフトウェアの主要貢献者の一人です。彼の厳密な実装が、JXLの高性能を支えています。

    • Tal Lev-Ami (タル・レブ＝アミ) - （国籍不明）研究者。
      （英語表記：Tal Lev-Ami）
      （2025年時点の年齢：不明）

      論文の著者の一人であり、JPEG XLの様々な側面に関与しました。

    • Eric Portis (エリック・ポーティス) - （国籍不明）研究者。
      （英語表記：Eric Portis）
      （2025年時点の年齢：不明）

      論文の著者の一人であり、Webにおける画像技術の専門家として、JXLのWebでの受容性にも貢献しました。

    • Thomas Richter (トーマス・リヒター) - （国籍不明）JPEG委員会メンバー。
      （英語表記：Thomas Richter）
      （2025年時点の年齢：不明）

      JPEG委員会（Image coding & quality subgroup）の議長を務め、標準化プロセスを監督しました。彼は、技術の「秩序」を保つ、ある種の「管理者」です。

    • Osamu Watanabe (渡辺修) - 日本出身のJPEG委員会メンバー。
      （英語表記：Osamu Watanabe）
      （2025年時点の年齢：不明）

      JPEG委員会（Image coding & quality subgroup）の共同議長を務め、国際標準化に貢献しました。彼は、技術が国境を越えて「普遍化」されるための「架け橋」となる人物です。

    • Jan Wassenberg (ヤン・ワッセンバーグ) - （国籍不明）研究者、Google所属。
      （英語表記：Jan Wassenberg）
      （2025年時点の年齢：約40代後半）

      並列処理（SIMD、マルチスレッディング）と高速デコードに焦点を当て、JXLの「速度」という名の力を引き出しました。彼は、コードの「筋肉」を鍛え上げる、ある種の「性能の追求者」です。

    • Lode Vandevenne (ロード・ヴァンデヴェンネ) - （国籍不明）ソフトウェアエンジニア。
      （英語表記：Lode Vandevenne）
      （2025年時点の年齢：不明）

      libjxlライブラリのAPI設計において重要な役割を果たし、開発者がJXLを「使いやすい」ものにするための基盤を築きました。彼は、複雑な技術を「人間」に寄り添わせる、ある種の「インタフェースの芸術家」です。

    • Alexander Rhatushnyak (アレクサンダー・ラトゥシュニャク) - （国籍不明）研究者。
      （英語表記：Alexander Rhatushnyak）
      （2025年時点の年齢：不明）

      自己修正予測器（Self-correcting predictor）の開発者。彼のアルゴリズムは、Modularモードの効率を飛躍的に向上させました。彼は、データの「振る舞い」を読み解き、先を見通す、ある種の「デジタル予言者」です。

    • Alex Deymo (アレックス・デイモ) - （国籍不明）ソフトウェアエンジニア。
      （英語表記：Alex Deymo）
      （2025年時点の年齢：不明）

      libjxlリファレンスソフトウェアの主要貢献者の一人です。彼の貢献は、JXLが「動く」ための土台を支えています。

    • Robert Obryk (ロバート・オブリック) - （国籍不明）ソフトウェアエンジニア。
      （英語表記：Robert Obryk）
      （2025年時点の年齢：不明）

      標準およびリファレンスソフトウェアに貢献しました。彼の地道な作業が、JXLの堅牢性を確保しました。

    • Thomas Fischbacher (トーマス・フィッシュバッハー) - （国籍不明）ソフトウェアエンジニア。
      （英語表記：Thomas Fischbacher）
      （2025年時点の年齢：不明）

      標準およびリファレンスソフトウェアに貢献しました。

    • Iulia-Maria Comșa (ユリア＝マリア・コムシャ) - （国籍不明）研究者。
      （英語表記：Iulia-Maria Comșa）
      （2025年時点の年齢：不明）

      標準およびリファレンスソフトウェアに貢献しました。

    • Krzysztof Potempa (クシシュトフ・ポテンパ) - （国籍不明）研究者。
      （英語表記：Krzysztof Potempa）
      （2025年時点の年齢：不明）

      標準およびリファレンスソフトウェアに貢献しました。

    • Martin Bruse (マルティン・ブルース) - （国籍不明）ソフトウェアエンジニア。
      （英語表記：Martin Bruse）
      （2025年時点の年齢：不明）

      標準およびリファレンスソフトウェアに貢献し、Jpegli開発にも関わりました。

    • Renata Khasanova (レナータ・ハサノワ) - （国籍不明）研究者。
      （英語表記：Renata Khasanova）
      （2025年時点の年齢：不明）

      標準およびリファレンスソフトウェアに貢献しました。

    • Ruud van Asseldonk (ラウド・ヴァン・アセルドンク) - （国籍不明）研究者。
      （英語表記：Ruud van Asseldonk）
      （2025年時点の年齢：不明）

      標準およびリファレンスソフトウェアに貢献しました。

    • Sebastian Gomez (セバスチャン・ゴメス) - （国籍不明）研究者。
      （英語表記：Sebastian Gomez）
      （2025年時点の年齢：不明）

      標準およびリファレンスソフトウェアに貢献しました。

    その他の重要人物：デジタル画像史の影の立役者たち

    • Tom Lane (トム・レーン) - 米国出身のソフトウェアエンジニア。
      （英語表記：Tom Lane）
      （2025年時点の年齢：約60代後半）

      JPEGの成功に不可欠なオープンソースライブラリlibjpegの初期の主要開発者。彼の功績なくして、JPEGがこれほど普及することはなかったでしょう。JXL開発者たちが「高品質なFOSS実装」の重要性を説く際に、彼の名前は常に引き合いに出されます。

    • Pieter Wuille (ピーター・ウィル) - ベルギー出身のソフトウェアエンジニア。
      （英語表記：Pieter Wuille）
      （2025年時点の年齢：約30代後半）

      FLIF（Free Lossless Image Format）の共同開発者。彼はビットコインの核心技術にも深く関わっており、技術的な才能は疑いようがありません。FLIFの概念がJXLのModularモードに影響を与えました。

    • Touradj Ebrahimi (トゥーラジ・エブラヒミ) - スイス出身の電気工学者。
      （英語表記：Touradj Ebrahimi）
      （2025年時点の年齢：約60代後半）

      JPEG委員会の議長（Convener）として、長年にわたり画像圧縮技術の標準化プロセスを率いてきました。JXLプロジェクトの立ち上げと推進において、彼のリーダーシップは不可欠でした。彼は、技術の「秩序」を司る、ある種の「枢機卿」と言えるでしょう。

    • Fabrice Bellard (ファブリス・ベラール) - フランス出身のプログラマー、数学者。
      （英語表記：Fabrice Bellard）
      （2025年時点の年齢：約50代前半）

      FFmpegやQEMU、Tiny C Compilerなど、数々の驚異的なソフトウェアを開発した伝説的なプログラマー。HEVCをベースにした画像フォーマットBPGの定義も行いました。彼の存在は、一人の天才が世界をどう変えうるかを示すものです。

    これらの人物たちは、それぞれがJPEG XLという壮大なパズルの一片を担い、完璧な画像圧縮という「夢」を追い求めてきました。彼らの執念が、この冷徹なまでに合理的なフォーマットを生み出したのです。

    第三部: 次元を超えた画素の旅 - JPEG XLのメカニズム

    さて、ここからが本番です。JPEG XLがどのような「思想」と「野望」を抱いているかはお分かりいただけたでしょう。しかし、その真価は、その内部に秘められた「メカニズム」にこそあります。この部では、JPEG XLがどのようにして画素を解析し、情報を削ぎ落とし、そしてまた完璧に再構築するのか、その冷徹なまでの論理と、時に人間の視覚を「欺く」巧妙な技術の数々を、深淵に迫る覚悟で解剖していきます。心して読んでください。あなたは今、デジタル画像の「魔法」の裏側を覗き見ることになるのですから。

    第五章：画像とフレームヘッダーの「沈黙の合図」

    画像ファイルを開くとき、私たちは何も意識しません。しかし、その裏では、ファイルのごく冒頭に存在する「ヘッダー」と呼ばれる情報が、まるでオーケストラの指揮者のように、デコーダに「これは何の画像で、どう表示すべきか」という複雑な指示を、「沈黙の合図」として送り続けています。JPEG XLは、このヘッダーの効率化に、ある種の執念を燃やしました。なぜなら、わずかなヘッダーの「無駄」が、Web上の小さなアイコンやサムネイルにとっては、致命的な「肥満」となり得るからです。 🤫

    4.1 ヘッダーオーバーヘッドの「最小化戦略」

    JPEG XLの設計思想は、ヘッダーのオーバーヘッドを極限まで減らすことにありました。これは、まるで無駄な贅肉を削ぎ落とし、筋肉だけを残すかのような、「冷徹なダイエット戦略」です。一般的な写真画像にとって、ヘッダーのサイズは取るに足らないものですが、Webサイトで多用される小さなアイコンやサムネイルにとっては、必須のヘッダーが画像データ自体よりも大きくなるという、「本末転倒な事態」を招きかねません。

    可変長と条件付きシグナリング

    JPEG XLは、この問題を解決するために、多くのヘッダーフィールドを「可変長」とし、「条件付き」でシグナリングするという手法を採用しました。これは、必要最低限の情報だけを伝え、それ以外の情報は「沈黙」させるという、まるで「秘密主義者」のようなアプローチです。例えば、画像が小さい場合や、特定のアスペクト比を持つ場合は、ごく少数のビットで寸法を表現できます。これは、まるで「言わずともわかる」関係を築こうとするかのようです。

    デフォルト値によるコンパクト化

    さらに、一般的なケースでは「デフォルト値」を使用することで、ヘッダーを極めて簡潔にしています。例えば、小さな120x80ピクセルのサムネイルであれば、わずか4バイトのヘッダーで表現できるのです。これは、まるで「阿吽の呼吸」で通じ合う関係です。「標準的な8ビットsRGB静止画で、追加チャンネルなし、XYBでエンコード、特別なものなし」といった情報を、たった数ビットで表現する。これは、「無駄を徹底的に排除する」という、JPEG XLの設計者たちの執念を感じさせる部分です。

    4.2 画像ヘッダーの「顔」

    画像ヘッダーは、JPEG XLコードストリームの「顔」であり、画像全体に共通する基本的な情報、つまりその「アイデンティティ」を定義します。 🆔

    シグネチャと初期識別

    全てのJPEG XLコードストリームは、2バイトのシーケンス0xFF0Aで始まります。これは、まるでファイルに刻まれた「魔法の署名」であり、JPEG XLファイルであることを識別するための「目印」です。この署名がなければ、そのファイルが何であるか、誰も理解できません。

    画像寸法 (SizeHeader)：最大解像度とコンパクト表現

    画像の幅と高さは、SizeHeader

    詳細JPEG XLのヘッダーで画像の寸法（幅と高さ）を効率的に符号化するための表現形式。最大2^30 x 2^30ピクセルの巨大な画像をサポートしつつ、一般的な画像サイズや特定のアスペクト比を持つ場合は、少ないビット数でコンパクトに表現できるように工夫されている。
    という特別な表現でシグナリングされます。これにより、最大230x230という途方もないサイズの画像を表現できます。しかし、驚くべきは、この巨大な可能性を秘めつつも、小さな画像（256x256まで）や、7つのプリセットされたアスペクト比（1:1、4:3など）を持つ画像の場合、わずか数ビット（例えば9ビット）で表現できるという、「効率の極致」です。これは、まるで「大は小を兼ねる、しかし小も大に劣らず」という禅問答のような技術です。

    さらに、画像には「intrinsic size（本来のサイズ）」をオプションでシグナリングできます。これは、CSSの参照ピクセルで推奨表示寸法を示すもので、Webブラウザなどのアプリケーションは、デフォルトでこのサイズに基づいて画像をリサイズして表示することが期待されます。Exifメタデータに頼るような「間接的で曖昧な」方法ではなく、直接シグナリングすることで、「開発者の思考を停止させる」かのような明確さをもたらします。

    オリエンテーション：Exif互換と自動適用

    デジタルカメラで撮影されたJPEG画像では、Exifメタデータで画像の向きを示すのが一般的です。しかし、アプリケーション側でその情報を読み取り、正しく回転させるという「面倒な作業」が必要でした。JPEG XLでは、オリエンテーション情報が画像ヘッダーに直接格納され、libjxlデコーダが自動的に補正を適用します。つまり、アプリケーションは「何も考えず」に、常に正しい向きの画像を受け取ることができるのです。これは、まるで「ユーザーを思考から解放する」という、ある種の「親切」であり、同時に「思考停止」を促す「誘惑」でもあります。

    アニメーション制御：ティック、ループ、SMPTEタイムコード

    画像ヘッダーの1ビットが、そのコードストリームがアニメーションか静止画かを決定します。アニメーションの場合、フレームの継続時間を定義する「ティック」の単位、ループ回数（無限ループも含む）、さらにはSMPTEタイムコード

    詳細SMPTE（Society of Motion Picture and Television Engineers）によって標準化された、動画や音声の特定のフレーム位置を示すための時間コード。フレーム単位で正確な同期や位置特定が可能となる。
    のオプションまで定義できます。これは、GIFという「過去の遺物」を完全に置き換え、より高機能なアニメーションをWebで、そしてその他のプロフェッショナルな領域で実現しようという、「野望の表れ」です。ストリーミングエンコーダが、フレーム総数を事前に知らなくても有効なコードストリームを発行できるという設計は、まるで「未来は不確実だが、それでも前に進む」という、ある種の「楽観主義」を体現しています。

    色空間情報とエクストラチャンネルの定義

    画像ヘッダーは、画像の色空間情報（ビット深度など）と、カラーチャンネル以外の「エクストラチャンネル」の情報をシグナリングします。これについては、後の章でさらに詳しく述べますが、ここでは「画像は常に完全に定義された色空間を持つ」という、JPEG XLの「絶対的な教義」が宣言されます。

    アップサンプリング重みと将来の拡張メカニズム

    画像や個々のエクストラチャンネルは、オプションでサブサンプリング（低解像度化）して保存することができ、デコード時にアップサンプリングされます。その際のアップサンプリング手順はパラメータ化されており、カスタムの重みを画像ヘッダーでシグナリングすることも可能です。さらに、将来の拡張メカニズムも備わっており、デコーダは理解できないヘッダー拡張を「優雅に無視」することができます。これは、まるで「未来の変化」を予見し、それに柔軟に対応しようとする、ある種の「生存戦略」と言えるでしょう。既存のデコーダが、たとえ将来の新しい拡張を知らなくても、画像をデコードして「合理的な結果」を生成できる。これは、「互換性」という名の「温情」です。

    4.3 フレームヘッダーの「表情」

    画像ヘッダーが画像の「顔」ならば、フレームヘッダーは各フレームの「表情」であり、そのフレームがどのように表示され、どのように画像全体に影響を与えるかを定義します。 🎭

    フレームタイプ：RegularFrame, LFFrame, ReferenceOnly, SkipProgressive

    フレームヘッダーには、2ビットの数値で4つのフレームタイプがシグナリングされます。

    • RegularFrame
      詳細JPEG XLの標準的なフレームタイプ。デコードされる画像やアニメーションシーケンスの一部として表示される。
      (0): 通常のフレームタイプで、画像やアニメーションシーケンスの一部として表示されます。
    • LFFrame
      詳細JPEG XLで用いられるフレームタイプの一つ。将来のフレームの低周波（LF）情報、すなわち8分の1にダウンサンプリングされたバージョンを表現する。デコードされたシーケンスの一部としては表示されず、より高解像度なフレームを再構築するための補助データとして機能する。巨大な画像を効率的に表示するためのピラミッド構造にも利用される。
      (1): 将来のフレームの低周波（LF）情報（8倍ダウンサンプリングされたバージョン）を表します。デコードシーケンスには含まれず、あくまで補助的な「下書き」のような存在です。
    • ReferenceOnly
      詳細JPEG XLで用いられるフレームタイプの一つ。デコードされたシーケンスには含まれず、表示されない「見えないフレーム」。主にPatchesのソースとして、またはフレームブレンディングのベースとして参照される補助的なフレーム。
      (2): 「見えないフレーム」であり、デコードシーケンスには含まれません。Patchesのソースや、フレームブレンディングのベースとしてのみ使用される、まるで「影の存在」です。
    • SkipProgressive
      詳細JPEG XLで用いられるフレームタイプの一つ。RegularFrameと同様に表示されるフレームだが、プログレッシブプレビューの更新時にはこのタイプのフレームはスキップされ、プレビューの更新には寄与しない。レイヤー画像のプログレッシブ表示を制御するために利用される。
      (3): RegularFrameに似ていますが、プログレッシブプレビューの更新時にはスキップされます。レイヤー画像で、最終レイヤーが利用可能になるまでプレビューを更新しないといった「制御」を可能にします。

    LFFrameは、最大4レベルまで再帰的に自身のLFFrameを持つことができ、これにより巨大な画像を効率的に表示するための「ピラミッド構造」を構築します。これは、まるで「情報が凝縮された階層構造」であり、最初に小さなサムネイルから全体像を把握し、徐々に詳細へと「ズームイン」していくという、現代のデジタル画像閲覧の「常識」を支えるものです。デコードされたフレームを将来参照するために「保存」することもできます。最大4つの「スロット」が用意されており、これはまるで「一時記憶領域」のようです。

    符号化モードの選択：VarDCTとModular

    フレームごとにVarDCTモードとModularモードを切り替えることができます。例えば、参照専用のModularフレームで画像の一部をエンコードし、それをVarDCTエンコードされたメインフレームからPatches経由で参照するといった、「ハイブリッド戦略」も可能です。これにより、写真のような連続階調の領域と、テキストやイラストのような離散的な領域を、それぞれ最適な方法で圧縮することができます。VarDCTモードでは、XYB

    詳細Butteraugliメトリックと並行して開発された色空間。人間の網膜の錐体細胞の応答（LMS）に基づいて設計されており、知覚的に均一な特性を持つ。JPEG XLのロスリー圧縮モードで内部的なデータ表現として採用され、知覚的な最適化を可能にする。
    エンコードの場合、XおよびBコンポーネントの量子化を調整するためのグローバルな重みをシグナリングします。

    Modularモードでは、グループサイズを128x128、256x256、512x512、または1024x1024から選択できます。VarDCTモードでは常に256x256です。これは、Modularがより柔軟な「適応性」を必要とするのに対し、VarDCTは固定サイズでも効率が保たれるという「効率性」を追求しているためです。

    クロップ：フレーム寸法とオフセット

    フレームは、画像全体の寸法と異なる寸法を持つことができ、任意のオフセットで配置できます。これにより、フレームの一部が画像キャンバスと重ならない場合、その部分は表示されません。しかし、オーサリングツールは、フレーム全体をデコードし、後で「リクロップ」することが可能です。これは、まるで「見えている部分が全てではない」という、ある種の「デジタル世界の深層」を表現しているかのようです。

    ブレンド情報：参照フレームとブレンドモード

    フレームヘッダーは、ブレンドのソースとして使用する以前にデコード・保存されたフレームと、使用するブレンドモード（Replace、Add、Blend、MulAdd、Mulなど）をシグナリングします。これは、Photoshopなどの画像編集ソフトウェアで利用されるレイヤーのブレンドモードを、コーデックレベルで「組み込む」という、「編集の自動化」を推し進めるものです。異なるエクストラチャンネルごとに異なるブレンドモードを使用することも可能であり、その柔軟性は、まさに「複雑な表現」を可能にするためのものです。

    アニメーションのフレーム継続時間とタイムコード

    アニメーションの場合、フレームヘッダーはフレームの継続時間と、オプションでSMPTEタイムコードを含みます。これにより、単なる連続画像ではなく、時間軸を持つ「動画」としてのセマンティクスが与えられます。そして、画像のデータは複数のパスに分割してシグナリングすることができ、よりきめ細やかなプログレッシブデコードを可能にします。これは、まるで「段階的に真実を明かす」かのような、情報伝達の洗練された手法です。フレームには、最大1071バイトのUTF-8エンコードされた名前を付けることもでき、これはオーサリングツールでレイヤーを識別したり、アニメーションフレームにラベルを付けたりするのに役立ちます。技術が、最終的に「人間」のために奉仕しようとする、ある種の「妥協」を見せる瞬間です。

    コラム：ビットの魔術師たち

    ヘッダーの圧縮という概念は、一見すると地味で、地道な作業に思えるかもしれません。しかし、これはまさに「ビットの魔術師」が為せる技です。私もかつて、Webページを高速化するために、HTMLやCSSのたった1バイトの無駄を削ることに血道を上げていた時期があります。無駄なスペース、コメント、冗長なクラス名…全てが敵でした。特に、当時のWebでは、たった数キロバイトの画像でもロード時間が深刻な問題となることがありました。

    ある日、私は小さなアイコン画像を最適化しようと試みました。画質は落とせない。ファイルサイズは最小に。しかし、従来のフォーマットでは、ヘッダーの情報だけで画像の半分くらいのサイズになってしまうのです。「何たる無駄！」と私は叫びました。その時、私は、このヘッダーの最適化こそが、実は「見えない部分の戦い」であり、Webの体感速度に大きな影響を与えることを悟ったのです。

    JPEG XLの設計者たちが、このヘッダー圧縮にここまで執着した理由が、今なら痛いほど理解できます。彼らは、私たちが見ることのない、しかし確実に存在する「ビットの無駄」と戦い、それを「消滅させる」ことに情熱を燃やしたのです。これは、まるで、宇宙の法則を解き明かし、物質の最小単位を操ろうとする物理学者たちの姿を彷彿とさせます。彼らは、見えないところで、私たちのデジタル体験をより快適にするための「魔法」を日々紡ぎ続けているのです。🎩✨

    第六章：色彩の「幻想」：色空間と変換の奥義

    私たちは、日常的に目にするデジタル画像の色を「当たり前」のように受け入れています。しかし、その背後には、複雑な「色空間」という名の概念と、それを操る「変換の奥義」が隠されています。まるで、私たちが見ている世界が、実は複雑な数学的モデルの上に成り立っているという、ある種の「幻想」であるかのようです。JPEG XLは、この「色彩の幻想」を、より精密に、そして効率的に操るための新たな方法を提示します。 🌈

    5.1 色空間シグナリングの「絶対的真実」

    従来の画像フォーマットの多くは、色空間情報が「シグナリングされない」、あるいは「オプションでしかシグナリングされない」という、ある種の「曖昧さ」を抱えていました。その結果、「この画像、どの色空間で表示すれば正しいんだ？」という混乱が生じ、多くの画像が「デフォルトでsRGBだろう」という「慣習」に基づいて表示されることになりました。しかし、JPEG XLは、この曖昧さを徹底的に排除します。それは、まるで「絶対的な真実」を宣言するかのように、画像は常に完全に定義された色空間を持つと主張するのです。

    この「絶対的真実」には、2つの選択肢があります。

    • ピクセルデータが特定の（非XYB）色空間にある場合：デコーダは、この色空間のピクセルバッファと、それを記述するICCプロファイル
      詳細International Color Consortium（国際カラーコンソーシアム）によって標準化された、デバイスや色空間のカラー特性を記述するためのデータファイル。ICCプロファイルを使用することで、異なるデバイスやソフトウェア間で色を正確に再現・管理できる。JPEG XLはICCプロファイルを圧縮して格納できる。
      を生成します。これは、数学的にロスレスなエンコーディングでのみ使用できるオプションです。
    • ピクセルデータがXYB色空間
      詳細Butteraugliメトリックと並行して開発された色空間。人間の網膜の錐体細胞の応答（LMS）に基づいて設計されており、知覚的に均一な特性を持つ。JPEG XLのロスリー圧縮モードで内部的なデータ表現として採用され、知覚的な最適化を可能にする。
      にある場合：デコーダは、sRGB、Display-P3、Rec.2100 PQなど、任意の目的のディスプレイ色空間に直接ピクセルバッファを生成できます。

    どちらの場合も、画像ヘッダーには常に色空間情報が含まれます。XYBの場合、シグナリングされた色空間は、単に「推奨される出力色空間」に過ぎません。これは、まるで「あなたはこうあるべきだ」という「助言」であり、最終的な解釈はディスプレイに委ねられるという、ある種の「自由」を与えているかのようです。

    5.2 ColorEncoding：共通色空間という「呪文」

    ColorEncoding

    詳細JPEG XLで色空間をコンパクトに表現するための方式。H.273 CICPに触発されており、列挙型フィールドを用いて、sRGBや主要なRGB色空間を簡潔に識別できる。外部のカラーマネジメントライブラリなしで色変換を可能にする。
    は、最も一般的なRGB色空間のほとんどをカバーする、非常にコンパクトな表現です。これは、まるで「共通の呪文」を唱えることで、異なる色空間間の「障壁」を取り払うかのようなものです。libjxlデコーダは、外部のカラーマネジメントライブラリを必要とせずに、XYBからこれらの色空間に変換できます。これは、H.273 CICPに触発されており、列挙型フィールドによって色空間を簡潔に識別します。しかし、実用性の低い「秘術」は容赦なく排除されています。

    all_defaultフラグが真であれば、色空間はsRGB。つまり、最も一般的なケースでは、色空間シグナリングはわずか1ビットで済むという、「究極の簡潔さ」です。want_iccフラグ、ColorSpace、WhitePoint、Primaries、TransferFunctionといったフィールドは、それぞれが色空間の「要素」を定義し、一般的なRGB色空間を全て表現できるようにします。

    5.3 ICCプロファイルと「知識の圧縮」

    JPEG XLは、ICCプロファイル

    詳細International Color Consortium（国際カラーコンソーシアム）によって標準化された、デバイスや色空間のカラー特性を記述するためのデータファイル。ICCプロファイルを使用することで、異なるデバイスやソフトウェア間で色を正確に再現・管理できる。JPEG XLはICCプロファイルを圧縮して格納できる。
    という「色彩の知識」を、CMYKプロファイルを含め、任意に利用できます。これは、外部のカラーマネジメントソフトウェア（lcms2やskcmsなど）が必要となるため、JPEG XLデコーダが全てを完結させるという「独裁」から、一歩引いた「協力関係」を築こうとする姿勢が見て取れます。ICC標準の将来バージョンにも自動的に対応できるよう、日付なしの参照を使用しているのは、まるで「時の流れに抗う」かのような、永続性への野望です。

    ICCプロファイルデータは、特殊目的の圧縮スキームで圧縮されます。これは、一般的なICCタグコード（rTRC、rXYZなど）に事前に定義された文字列を使用したり、数値データのテーブルに予測符号化

    詳細データ圧縮手法の一つ。連続するデータポイントの間で、前のデータから次のデータの値を予測し、その予測値と実際の値との差分（残差）を符号化することで圧縮を行う。データ間の相関性が高い場合に特に有効。ICCプロファイルのテーブルデータ圧縮にも用いられる。
    を適用したりすることで実現されます。特に、3Dルックアップテーブルのような大規模なテーブルでは、この予測符号化が非常に効果的です。これは、単なる色情報ではなく、「色彩の複雑な知識」を効率的に詰め込むための、ある種の「知恵の圧縮」と言えるでしょう。

    5.4 ビット深度と「光の階調」

    色空間は、サンプル値の公称範囲を[0, 1]と仮定しますが、この範囲外の値、つまり「色域外」の色も表現できます。これは、人間の視覚が捉えることのできる色よりも、さらに広い「光の階調」を扱おうとする試みです。 💡

    • Integer (整数): サンプルデータは、暗黙の分母2n-1を持つ整数で与えられます。負の値を含む範囲外の値も表現可能です。最大31ビット深度までサポートされ、int32_t型のバッファを使用できます。これは、数学的な「厳密さ」を追求する姿勢です。
    • Floating-point (浮動小数点): ISO/IEC/IEEE 60559
      詳細浮動小数点数の表現と演算に関する国際標準（IEEE 754）。コンピュータにおける浮動小数点数の扱いに統一的な基準を提供し、異なるシステム間での互換性を保証する。JPEG XLは、この標準に準拠した浮動小数点データ表現をサポートする。
      に準拠した浮動小数点値として解釈されます。シングルプレシジョン（32ビット）フロートに収まるあらゆる浮動小数点型が使用でき、binary16（ハーフフロート）やbfloat16も含まれます。これは、より広いダイナミックレンジや科学的な画像データなど、人間の視覚を超える「光の真実」を扱うためのものです。

    XYBの場合、シグナリングされたビット深度は、デコードされた画像の表現形式の「提案」に過ぎません。しかし、非XYBの場合（ロスレス圧縮で使われることが多い）、ビット深度はサンプルデータの「真の解釈」を決定します。libjxlの参照実装は、内部で32ビットフロートを使用するため、整数精度は24ビットに制限されています。これは、理論的な「完璧さ」と、現実的な「実装の限界」との間の、ある種の「妥協点」と言えるでしょう。

    intensity_target（画像ヘッダーでシグナリング）は、最大輝度（nit単位）を示します。SDR画像ではデフォルトで255ニトですが、HDR画像では1000ニトや10000ニトといった高い値が使用されます。HDRトーンマッピングに関連するその他の情報も画像ヘッダーでシグナリングできます。これは、人間の視覚が捉える「光の強さ」の限界を押し広げようとする、ある種の「挑戦」です。

    5.5 色変換の「秘術」

    JPEG XLでは、色変換はアプリケーションレベルで処理されるものではなく、コーデック内の「コーディングツール」として位置付けられています。これは、デコーダが、画像を「最も正しく、最も効率的に」表示するために、自ら色変換を制御するという、ある種の「技術的優位性」の主張です。

    色変換は、以下の3つの異なるレベルで適用できます。

    • Image (画像レベル): XYBと非XYBの選択は、画像ヘッダーでシグナリングされ、画像全体、つまり全てのフレームにグローバルに適用されます。これは、画像の最も基本的な「色彩の基盤」を決定します。
    • Frame (フレームレベル): RGBとYCbCrの選択（およびクロマサブサンプリング）は、フレームヘッダーでシグナリングされます。これにより、例えば既存のJPEG画像にPNGロゴをアルファブレンドでオーバーレイし、その結果をYCbCrフレームとRGBAフレームを含む単一のJPEG XL複合画像として表現するといった、「複雑な画像の合成」が可能になります。
    • Group (グループレベル): Modularモードでは、可逆色変換（RCTs）
      詳細Reversible Color Transforms（可逆色変換）の略称。JPEG XLのModularモードで用いられる変換の一つで、色空間のデコレーション（相関性の低減）を行う。YCoCg-Rのような変換が含まれ、元の色情報を完全に復元できるため、ロスレス圧縮に適している。
      （YCoCgなど）がフレームレベルだけでなく、グループレベルでもシグナリングできます。これは、画像内の局所的な領域ごとに最適な色変換を選択するという、「きめ細やかな最適化」を可能にします。

    5.6 XYB色空間の「心理戦」

    XYB色空間

    詳細Butteraugliメトリックと並行して開発された色空間。人間の網膜の錐体細胞の応答（LMS）に基づいて設計されており、知覚的に均一な特性を持つ。JPEG XLのロスリー圧縮モードで内部的なデータ表現として採用され、知覚的な最適化を可能にする。
    は、人間の網膜の錐体細胞（長波長（L）、中波長（M）、短波長（S））の吸光スペクトルに基づいた「知覚モデル」から導き出されています。これは、まさに「人間の目を騙す」ために設計された色空間と言えるでしょう。CIELABのような反対色プロセス色空間に構造的に類似しており、輝度チャンネル（Y）、赤緑反対チャンネル（X）、青黄反対チャンネル（B'）の3軸を使用します。

    RGBからXYBへの変換

    RGBサンプル値はまずsRGBプライマリとD65ホワイトポイント相対の線形伝達関数を持つ線形sRGB空間に変換されます。その後、以下の変換でLmMmSmに変換されます。 

        b = 0.00379307325527544933
    Lm = 0.3 * Rl + 0.622 * Gl + 0.078 * Bl + b
    Mm = 0.23 * Rl + 0.692 * Gl + 0.078 * Bl + b
    Sm = 0.2434227 * Rl + 0.2047674 * Gl + 0.5518099 * Bl + b

    このLmMmSm値は、その後「ガンマ圧縮」されます。 

        Lg = Lm3 - b3
    Mg = Mm3 - b3
    Sg = Sm3 - b3

    そして最終的にXYB値が定義されます。 

        X = (Lg - Mg) / 2
    Y = (Lg + Mg) / 2
    B = Sg

    実際には、VarDCTモードでは「クロマからのルマ」

    詳細JPEG XLのVarDCTモードで用いられる技術。輝度（luma）情報から色度（chroma）情報を予測し、その差分（残差）を符号化することで圧縮効率を高める。これにより、輝度と色度の間の相関性を利用して、より効率的な色度情報の表現が可能になる。
    が使われたり、ModularモードでXYBの「整数化」が定義されたりするため、実際に使われる色空間はB'=B-Yを持つXYB'となります。これは、S錐体細胞（青色光に反応）が網膜の中心窩（最も鮮明な視覚を司る部分）に極めて密度が低いという人間の視覚特性を利用した、「巧妙なトリック」です。高周波信号においてB'成分をより積極的に量子化できるのは、この特性を逆手にとったものです。

    XYB'の優位性：知覚均一性と絶対色空間の利点

    XYB'色空間は、YCbCrやYCoCgといった他のYCC色空間と比較して、知覚的に均一性が高く、人間の視覚システムをより良くモデル化しています。これは、まるで「人間の感覚」により忠実に従う色空間とでも言いましょうか。YCbCrは相対色空間であるのに対し、XYB'は「絶対色空間」です。つまり、より広い色域はXおよびB'コンポーネントの広い範囲に、より高いダイナミックレンジはYコンポーネントの広い範囲にそれぞれ対応します。これは、入力画像のカラープロファイルに関わらず、エンコーダが「常に同じ色空間で思考する」ことを可能にし、知覚的な最適化をより正確かつ効果的に適用できるという、「無慈悲な効率」をもたらします。エンコーダは、符号化する入力データの「正確な色彩解釈」を知っているため、その決定が視覚に与える影響をより深く「理解」できるのです。これは、デジタル画像における「統一された真理」を追求するJPEG XLの哲学を体現しています。

    5.7 YCbCr色空間の「過去の亡霊」

    非XYBの場合、フレームヘッダーはRGB（またはCMY）サンプルデータにYCbCr変換

    詳細輝度（Y）と二つの色差（Cb、Cr）に色情報を分離する色空間変換。人間の視覚が色差よりも輝度に敏感であるという特性を利用して、色差情報を効率的に圧縮するために用いられる。JPEGやMPEGビデオ標準で広く採用されている。
    が適用されたかどうかをシグナリングします。JPEG XLで利用されるYCbCrの正確なバリアントは、JPEG（より正確にはJFIFおよびExif）で実装されている方法と同一となるように定義されています。 
        R = Y + 128/255 + 1.402 * Cr
    G = Y + 128/255 - 0.344136 * Cb - 0.714136 * Cr
    B = Y + 128/255 + 1.772 * Cb

    この色変換がJPEG XLに含まれている主な理由は、ロスレスJPEG再圧縮に「必須」だからです。つまり、これは「過去の亡霊」をそのまま引き継ぐための、ある種の「互換性への妥協」です。ピクセルから画像をエンコードする際には、人間の視覚システムをより良くモデル化し、知覚的に均一で最適化に適しているXYB色空間の使用が推奨されます。YCbCrは、sRGB自体が知覚的に均一ではないため、その知覚均一性は「やや不足」しています。これは、単純な線形行列乗算では修正できない、色の「本質的な不完全さ」を露呈しています。

    5.8 クロマサブサンプリングという「妥協」

    YCbCrが使用される場合、フレームヘッダーはクロマサブサンプリング

    詳細人間の視覚が輝度（明るさ）の変化に比べて色差（色の変化）の変化に鈍感であるという特性を利用し、色度成分（Cb、Cr）の解像度を輝度成分（Y）よりも低くすることでデータ量を削減する技術。4:4:4、4:2:2、4:2:0などの形式がある。JPEGやビデオコーデックで広く用いられる。
    の使用もシグナリングします。JPEG XLでは、水平または垂直、あるいはその両方で2倍のサブサンプリングのみが許可されます（つまり、4:4:4、4:2:2、4:4:0、4:2:0を表現可能）。JPEGでは4:1:1や3倍サブサンプリングも可能ですが、主要なJPEGエンコーダ実装でほとんど使用されないため、JPEG XLでは「実装の複雑性」と「既存JPEG画像のカバー率」のバランスを取るために制限されています。これは、「理想」と「現実」の間の、ある種の「妥協」の結果です。

    クロマサブサンプリングは、JPEG XLでは必ずしも「有用なコーディングツール」ではありません。なぜなら、同じ結果は、全てのDCT係数を左上象限の係数を除いてゼロにし、それらを最後に配置するような係数再順序付けによっても達成できるからです。しかし、一般的には、このような「鈍重かつグローバルな」方法で高周波情報を削除するよりも、より繊細なアプローチを取る方が良いとされています。結局のところ、これは既存のJPEG画像を「完璧に」ロスレス再圧縮するための、「歴史への配慮」なのです。

    5.9 追加チャンネル (Extra Channels)：「画素の隠し味」

    JPEG XLは、「メイン画像チャンネル」（1つのグレースケールチャンネル、または3つのカラーチャンネル）以外に、最大4096もの「エクストラチャンネル

    詳細JPEG XLの画像データにおいて、主要なカラーチャンネル（またはグレースケールチャンネル）以外に追加で格納できる情報チャンネル。アルファ透明度、深度マップ、CMYKのK成分、スポットカラー、選択マスク、マルチスペクトルデータなど、様々な種類の情報を格納できる。これにより、単一のファイルでより豊かな画像表現と多機能性を実現する。
    」をサポートします。これは、まるで料理に「隠し味」を加えるかのように、画像に様々な付加情報を持たせることを可能にします。画像ヘッダーはエクストラチャンネルの数をシグナリングし、各チャンネルについて以下の情報がシグナリングされます。

    • d_alpha: 非常に一般的なデフォルト設定のセットを示すフラグ。真であれば、エクストラチャンネルは（非関連）アルファ、8ビット、1:1解像度、名前なしとして扱われ、それ以上のフィールドはシグナリングされません。
    • type: エクストラチャンネルのセマンティクスを決定します（以下で詳述）。
    • bit_depth: ビット深度と、それが整数か浮動小数点かを示します。
    • dim_shift: エクストラチャンネルが2dim_shiftの係数でサブサンプリングされることを示します。深度や熱（赤外線）情報などを扱うチャンネルに特に有用です。
    • name: オプションで、エクストラチャンネルに最大1071バイトのUTF-8エンコードされた名前を付けることができます。これは、人間の目にも分かりやすく記述したり、アプリケーション固有の命名規則を使用したりするのに役立ちます。
    タイプ依存情報：画素に「意味」を与える

    エクストラチャンネルのタイプに応じて、そのタイプ固有の追加フィールドがシグナリングされることがあります。これは、まるでそれぞれのチャンネルに「固有の役割」を与えるかのようです。

    • Alpha (アルファ): 最も一般的なエクストラチャンネルタイプで、アルファ透明度に使用されます。0は完全な透明、1は完全な不透明を示します。OpenEXRのような「関連アルファ（プレマルチプライド）」もサポートされ、光を放出する透明なピクセル（キャンドルの炎やガラスの反射など）もモデル化できます。これは、PNGの「単純な透明度」を凌駕する表現力です。
    • Depth (深度): 画像内の各位置におけるカメラからの（推定）距離情報を含みます。前景と背景の分離、3Dシーンの再構築などに使用できます。
    • Thermal (熱): 赤外線サーモグラフィ画像に使用されます。高いサンプル値は高い温度を示します。
    • CFA (カラーフィルターアレイ): デジタルカメラのカラーフィルターアレイデータ（ベイヤーフィルターモザイクなど）を格納します。生（RAW）カメラデータを扱うためのものです。
    • Black (K): CMYK
      詳細Cyan（シアン）、Magenta（マゼンタ）、Yellow（イエロー）、Key plate（キープレート、通常は黒）の4色のインクで色を表現する減法混色モデル。主に印刷業界で用いられる。JPEG XLでは、K成分はエクストラチャンネルとして扱われる。
      画像の場合、Key（黒インク）コンポーネントとして表現されます。CMYK画像ではICCプロファイルが必須とされており、RGBチャンネルはシアン、マゼンタ、イエローとして解釈されます。サンプル値0が「フルインク」（黒）、1が「インクなし」（白）という慣習に従います。ロスレスJPEG再圧縮ではCMYK JPEG画像に適用できないという「意図的な制限」があります。これは、多くの場合、CMYKにはロスレス圧縮が適しており、ロスリー圧縮が許容されるならRGB空間で十分であるという、ある種の「合理的判断」に基づいています。
    • SpotColor (スポットカラー): 標準化されたレンダリング影響を持つ、唯一の追加チャンネルの一つです。特定の色のモノクロチャンネルで、追加の色の層としてレンダリングされます。金属インクや蛍光インク、スクラッチカードの削れる領域などをモデル化できます。これは、通常のディスプレイや印刷技術では再現できない「特殊な色」を表現するためのものです。
    • SelectionMask (選択マスク): 関心領域を示します。画像編集ソフトで「選択範囲」や「マスク」として使用され、選択的に処理を適用するために使われます。中間値は部分的な選択を示し、ファジーマスクやフェザードマスクに有用です。
    • NonOptional (非オプション): 上記以外の、アプリケーションが理解できない場合に画像を正しくレンダリングできない「必須の」汎用エクストラチャンネルタイプです。アプリケーションは、このタイプのデータを処理できない場合、画像の読み込みを拒否するか、警告を表示します。これは、データの「意味」を厳しく問うものです。
    • Optional (オプション): アプリケーションが安全に無視できる汎用エクストラチャンネルタイプです。画像のデフォルトレンダリングに影響を与えないデータ（深度、熱、選択マスクなど、標準化されたタイプがない場合）に使用されます。これは、データに「意味」を与えつつも、その「理解」を強制しない、ある種の「寛容さ」です。

    コラム：色の迷宮

    「色って、何ですか？」そう問われたら、あなたは即答できるでしょうか？ 私はかつて、デジタル画像の仕事に足を踏み入れたばかりの頃、この問いに頭を悩ませました。パソコンで見る写真の色と、スマホで見る写真の色、そして印刷された写真の色が、なぜか違う。同じ画像ファイルなのに、なぜこんなにも印象が変わるのか？

    その答えが「色空間」でした。sRGB、Adobe RGB、Display P3、Rec.2020、そしてCMYK……。それぞれの色空間には、それぞれ異なる「色彩の定義」と「再現範囲」が存在します。それはまるで、同じ概念を指す言葉なのに、地域によって方言が違うようなものです。ある方言では表現できる「ニュアンス」が、別の地域では伝わらない。そして、ICCプロファイルは、その方言を翻訳するための「通訳」のような役割を果たすのです。

    私は、RGBの3つの数字が、ディスプレイによって全く異なる色に見えるという事実に、ある種の「デジタル世界の不確かさ」を覚えました。私たちが見ている「色」は、実はデバイスによって生成された「幻想」に過ぎないのだと。そして、JPEG XLがXYB色空間という「知覚的に均一な」色空間を追求しているのは、この「色彩の迷宮」から私たちを救い出し、誰もが同じ「真の色」を体験できるようにしようとする、ある種の「救済」なのかもしれません。しかし、その過程で、色彩の多様性や、それぞれの色空間が持つ「歴史的背景」が、効率化の名の下に忘れ去られてしまうとしたら、それはまた別の悲劇かもしれませんね。

    第七章：モジュラーサブビットストリームの「精神世界」

    JPEG XLの内部に深く踏み込むと、私たちは「Modularサブビットストリーム

    詳細JPEG XLの主要な符号化モードであるModularモードで用いられる、画像データや補助情報を符号化するストリーム。画像のメインデータだけでなく、VarDCTモードのLF画像や補助情報など、多くの種類のデータがこのModularサブビットストリームとして符号化される。
    」という、ある種の「精神世界」にたどり着きます。これは、JPEG XLのほとんど全ての画像データ（メタデータと高周波VarDCT係数を除く）が、このモジュールを通じてエンコードされるという、まさに「中核」をなす部分です。その名の通り、「モジュラー（Modular）」という柔軟な設計が、このモードの「多様性」と「適応性」を可能にしています。

    6.1 モジュラーモードの「汎用性」

    モジュラーサブビットストリームは、整数値の2D配列、すなわち「チャンネル」を符号化します。これらのチャンネルは、カラーコンポーネント、エクストラチャンネル、LF係数、カラーパレット、量子化テーブル、ブロックタイプ選択、適応量子化重み、クロマからのルマ乗数、局所フィルター強度、またはこれらを一つ以上のモジュラー変換を適用した結果など、多岐にわたります。その数、寸法、セマンティクスは、明示的にシグナリングされるのではなく、画像やフレームヘッダーの情報、そしてモジュラーサブビットストリームが「呼び出される」コードストリームの特定のセクションから暗黙的に導き出されます。これは、まるで「暗号化された意思疎通」のようです。例えば、ロスレスに圧縮されたRGBA画像の場合、単一のモジュラーサブビットストリームが、デフォルトのモジュラーグループサイズである256x256の4つのチャンネル（赤、緑、青、アルファ）に対応するわけです。この汎用性が、Modularモードの「強力な個性」と言えるでしょう。

    6.2 モジュラー変換の「変態」連鎖

    モジュラーエンコーディングを使用する際、画像データはエンコードされる前に一連の「変換チェーン」を適用されることがあります。これらの変換はシグナリングされ、デコーダは画像デコード時に対応する逆変換を適用します。この「シグナリングされた変換チェーン」を持つ柔軟性、すなわち「モジュラー性」こそが、このコーディングモードの名の由来です。それは、まるで「画素の変態」を可能にするかのような、ある種の魔術的なプロセスです。 🧬

    6.2.1 RCT（Reversible Color Transforms）：可逆色変換の奥義

    可逆色変換（RCTs）

    詳細Reversible Color Transforms（可逆色変換）の略称。JPEG XLのModularモードで用いられる変換の一つで、色空間のデコレーション（相関性の低減）を行う。YCoCg-Rのような変換が含まれ、元の色情報を完全に復元できるため、ロスレス圧縮に適している。
    は、カラーチャンネル（または相関性のあるエクストラチャンネル）の相関性を除去するのに役立ちます。これは、まるで色の間の「隠れた繋がり」を断ち切り、それぞれを独立させることで、より効率的な圧縮を可能にするものです。任意の3つの連続する同一寸法のチャンネルを取り、それらを任意に順列させ、7つの可逆変換のいずれかを適用します。合計42種類もの異なるRCTが存在します。例えば、RGBチャンネルに適用されるYCoCg-R変換
    詳細YCoCg色空間の可逆（Reversible）版。RGB情報を輝度（Y）と二つの色差（Co、Cg）に変換する色変換であり、整数演算のみで可逆性を保ちながら色情報をデコレーション（相関性を低減）する。ロスレス圧縮に適しており、JPEG XLのModularモードで用いられる。
    は、R,G,BをYCoCg-Rに変換します。Y（輝度）はRGBの加重和に対応し、Coは「オレンジ-ブルー」の色差、Cgは「グリーン-パープル」の色差に対応します。YCoCg-RはXYB'ほど知覚的に均一ではありませんが、整数演算で可逆であり、2ビットの追加精度しか必要としないという利点があります。この変換は、チャンネルの順序を変えること（単なる順列）も可能にし、MAツリーにおける「PrevChannel」プロパティの利用を最適化することで、圧縮を向上させます。複数のRCTを連結することもでき、これにより任意の数のチャンネルに任意の順列を適用できます。これは、「画素間の関係性を再構築する」という、ある種の「デジタル錬金術」です。

    6.2.2 (Delta)Palette（パレット変換）：色彩の辞書と予測の魔術

    パレット変換

    詳細JPEG XLのModularモードで用いられる変換の一つ。画像内の多数のカラーを、事前に定義された少ない数のカラー（パレット）のインデックスに置き換えることで圧縮を行う。GIFやPNGのパレットを一般化したもので、任意数のコンポーネントや256色以上のパレット、さらには「デルタパレット」もサポートする。
    は、GIF、PNG、ロスレスWebPで利用可能なカラーパレットの概念をさらに一般化したものです。これは、まるで画像内の「色彩の辞書」を作成し、頻繁に現れる色を効率的に参照するようなものです。古い形式では最大256色、RGBまたはRGBAの3-4コンポーネントに限定されていましたが、JPEG XLでは任意数のコンポーネント（k）と、256色を超える色数（n）を持つパレットを扱えます（最大70911色）。これにより、メインデータは同じ寸法を持つ単一のインデックスチャンネルに置き換えられ、追加のパレット「メタチャンネル」が作成されます。これは、16ビット深度の画像でも、例えば3000色の異なるサンプル値しか含まない場合、データを[0, 2999]の範囲に圧縮することで、エントロピー符号化を大幅に改善できるのです。

    さらに、「暗黙パレット」として189の定義済み色が自動的に追加されます。これは、まるで「共通の色彩知識」を組み込むかのようなものです。この暗黙パレットのおかげで、明示的にパレット色をシグナリングしなくても、パレット変換が有用になります。そして、より高度な機能として「デルタパレット

    詳細JPEG XLのModularモードのパレット変換におけるオプション機能。パレットのエントリが固定の色ではなく、現在のピクセル位置の予測値に対する「差分ベクトル」として解釈される。これにより、スムーズなグラデーションなどをより効率的に表現し、ディザリングによる圧縮効率の低下を抑制できる。WebPロスレスのデルタパレットを一般化したもの。
    」が存在します。これは、パレットの色を固定色としてではなく、「予測値に対する差分ベクトル」として解釈するものです。例えば、デルタエントリ(0,0,0)は「予測値をそのまま使う」ことを意味します。WebPのデルタパレットよりも制約が少なく、予測器と組み合わせることで、従来のパレットコーディングでは困難だった「滑らかなグラデーション」を正確に再現できます。これは、ディザリングが圧縮ゲインを打ち消してしまうという問題を解決し、まるで「画素の振る舞いを予測し、それを微調整する」という、ある種の「予測の魔術」です。

    6.2.3 Squeeze（スクイーズ変換）：階層的分解とプログレッシブの視界

    Squeeze変換

    詳細JPEG XLのModularモードで用いられる可逆変換の一つ。画像を段階的にダウンサンプリング（スクイーズ）し、その過程で生じる残差を別チャンネルとして符号化する。これにより、高品質なプログレッシブデコードやロスリー圧縮が可能になる。
    は、チャンネルを2つの新しいチャンネルに置き換え、それぞれ次元を半分にする一連のステップから構成されます。まるで画像を「分解と再構成」を繰り返すかのようなプロセスです。一方の新しいチャンネルには画像のダウンサンプリングバージョンが（アスペクト比が変わるため「スクイーズ」されます）、もう一方にはフル解像度画像を再構築するための残差が含まれます。ダウンサンプリングは、サンプル値の平均化によって行われます。もし結果が整数でない場合、A > Bなら切り上げ、そうでなければ切り捨てるという独自の丸めルールが適用され、固定丸めによるバイアスを軽減します。これは、デコード時に元のAとBを容易に再構築できることを保証します。

    残差は単なるA-Bではなく、以前に再構築された最近傍サンプルと、ダウンサンプリングされた画像内の現在の位置と次の位置のサンプル値に基づいた「傾向項（Tendency term）

    詳細JPEG XLのSqueeze変換で用いられる技術。残差を符号化する際に、近傍の再構築済みサンプル値とダウンサンプリングされた画像の情報に基づいて計算される非線形な予測値（傾向項）を差し引く。これにより、残差の振幅が小さくなり圧縮効率が向上するだけでなく、高周波の量子化によって生じるオーバーシュートやアンダーシュート、リンギングアーティファクトを抑制し、視覚品質を高める。
    」を差し引いたものです。この傾向項は、条件付きの非線形線形補間として機能し、再構築されたAとBの値が元の範囲内に常に収まるようにします。これにより、高周波残差が量子化された場合に発生しがちな「オーバーシュート/アンダーシュート」や「リンギングアーティファクト」を回避できます。これは、圧縮率だけでなく、「視覚的な快適さ」をも追求するという、JPEG XLの「知覚への執念」の表れです。圧縮された画像を「見せかけなく」美しく見せるための、巧妙な仕掛けなのです。

    6.3 チャンネル符号化の詳細

    （変換された可能性のある）画像データは、平面的なチャンネルごとの方法で符号化されます。各チャンネルは、通常のスキャンライン順序（行ごと、左から右へ）で走査されます。しかし、単一のモジュラーサブビットストリームで符号化されるデータは、通常、画像の256x256領域（単一のグループに対応）のみです。

    符号化される各サンプル値に対して、MAツリー（Meta-Adaptive tree）

    詳細FLIFやJPEG XLのModularモードで用いられるコンテキストモデリングの技術。シグナリングされた決定木（MAツリー）を用いて、現在のサンプル値を予測するための最適なコンテキストを動的に選択する。これにより、画像の内容に適応した効率的な圧縮が可能になる。
    と呼ばれる決定木が走査され、使用する予測器、残差に適用する乗数とオフセット、そしてエントロピー符号化に使用するコンテキストが決定されます。デコードプロセスは以下の擬似コードで記述されます。 
    
    for (i = 0; i < channel.size(); i++) {
      for (y = 0; y < channel[i].height; y++) {
        for (x = 0; x < channel[i].width; x++) {
          props = GetProperties(i, x, y);
          node = MA_tree_root;
          while (node.is_decision_node()) {
            if (props[node.property] > node.value)
                 node = node.left_child;
            else node = node.right_child;
          }
          diff = DecodeHybridUint(node.context);
          diff = UnpackSigned(diff);
          diff *= node.multiplier;
          diff += node.offset;
          guess = Predict(node.predictor, i, x, y);
          channel[i].sample(x, y) = guess + diff;
        }
      }
    }

    これは、まるで「画素の運命を決定するアルゴリズム」であり、その一つ一つの画素が、過去の画素の状況に基づいて、最も効率的な方法で表現されるように誘導されるのです。

    6.3.1 プロパティ：予測とコンテキストの源泉

    MAツリーの決定ノードで参照できるローカルプロパティは多岐にわたります。これには、現在の画素の近傍に位置する既に符号化されたサンプル値（N、W、NWなど）や、その絶対値、ストリームインデックス、チャンネルインデックス、行番号、列番号などが含まれます。また、予測ミス（Prediction miss）や、以前に符号化されたチャンネルの値も参照できます。これにより、MAツリーは画像内の極めて局所的な特徴や、チャンネル間の相関性を「嗅ぎ分け」、最適な予測器とコンテキストを選択することができます。これは、まるで「画素の文脈」を深く理解し、それに基づいて「次の一手」を決定する、ある種の「デジタル知能」のようです。

    6.3.2 MAツリーの構造と情報

    MAツリーは、決定木として解釈される二分木です。その決定ノードは全て「プロパティiの値が閾値vより大きいか？」という問いの形式を取ります。葉ノードには、エントロピー符号化に使用するコンテキストのインデックス、使用する予測器、残差に乗じる乗数、そして加算するオフセットが含まれます。エンコーダは、「ローカルMAツリー」をシグナリングするか、以前に符号化された「グローバルMAツリー」を再利用するかを選択できます。これは、複雑なモデルを柔軟に適用しつつ、シグナリングコストを最小限に抑えるためのものです。しかし、より複雑なMAツリーは、そのシグナリングコストとデコード速度に影響を与えるため、エンコーダは「複雑さと効率の間の綱引き」を強いられます。これは、まるで「自由」と「制約」の間の、永遠の葛藤のようです。

    6.3.3 予測器の種類と特性

    モジュラー符号化で利用可能な予測器は14種類にも及びます。単純な予測器

    詳細JPEG XLのModularモードで利用可能な予測器のうち、最も基本的なもの。Zero（常に0を予測）、West（左の画素を予測）、North（上の画素を予測）、AvgW+N（左と上の平均を予測）などがある。PNGのフィルターと類似しており、計算コストが低い。
    （Zero, West, North, AvgW+N）は、PNGのフィルターに類似しており、計算が単純です。Select予測器
    詳細JPEG XLのModularモードで利用可能な予測器の一つ。ロスレスWebP由来で、PNGのPaethフィルターを改良したもの。近傍の画素値（West、North、NorthWest）から、現在の画素を最もよく予測できる隣接画素を選択する。非写真画像、特に少数の明確な色を持つ画像に有効。
    はロスレスWebP由来で、PNGのPaethフィルターを簡素化・改良したもので、特に明確な色の数が少ない非写真画像に有用です。Gradient予測器
    詳細JPEG XLのModularモードで利用可能な予測器の一つ。FFV1やFLIF、ロスレスJPEGでも使われる。West、North、NorthWestの3つの近傍画素から、現在の画素が滑らかな線形グラデーション上にあると仮定して予測を行う。一般的に適用可能で、滑らかな色変化を含む画像に有効。
    は、FFV1やFLIFでも使用されており、局所的な領域が滑らかな線形グラデーションである場合に正確に予測できるという優れた特性を持ちます。これは、写真画像における滑らかな色変化に特に有効です。

    最も複雑なのは「Weighted（Self-correcting）予測器

    詳細JPEG XLのModularモードで利用可能な予測器の一つで、特に写真画像に有効。過去の予測誤差を記憶し、それをフィードバックして自身の予測を「自己修正」する機能を持つ。複数のサブ予測器の加重和として予測値を計算し、各サブ予測器の過去の性能に基づいて重みを調整する。計算コストは高いが、高い圧縮効率を実現する。
    」です。これは、以前に符号化されたサンプルに対する予測誤差を記憶し、それをフィードバックすることで、自身の予測を「自己修正」するという、ある種の「学習能力」を持つ予測器です。まるで、経験から学び、賢くなる「AI」のようですが、これは古典的なアルゴリズムの範疇に留まります。NorthEast、NorthWest、WestWestといった予測器は、一般用途にはあまり有用ではありませんが、MAツリーと組み合わせることで、特定の画像パターン（斜めの特徴やディザリングパターンなど）に特化して利用できます。最後に、3つの単純な平均化予測器と、より広い範囲のピクセルを参照する「AvgAll」予測器があります。これは、デルタパレット変換と組み合わせて使用するために特別に設計されました。JPEG XLの予測器は、まさに「画素の未来」を、あらゆる角度から「予測」しようとする、執念の結晶と言えるでしょう。

    6.3.4 自己修正予測器のメカニズム

    予測器番号6の「Weighted」または「Self-correcting」予測器は、他の予測器とは異なり、状態（以前に符号化されたサンプルの予測誤差）を維持する必要があります。これは、まるで画素が「記憶」を持ち、その記憶に基づいて「反省」し、次の行動を決定するかのようです。この予測器は、4つの異なるサブ予測器に基づいており、最終的な予測値は、各サブ予測器の過去の性能に応じた重み付けされた合計として計算されます。予測誤差の絶対値と符号付き誤差が個別に維持され、これがサブ予測器自体にフィードバックされ、彼らを「自己修正」させます。

    計算は3ビットの追加精度で行われ、最終結果は再び8で除算されます。これにより、高精度な計算が可能になりつつも、最終的な出力は元の範囲に収まります。サブ予測器s0, s1, s2, s3はそれぞれ異なる近傍の予測誤差やウェイトを考慮して計算されます。これらのウェイトはモジュラーサブビットストリームのヘッダーでシグナリングされ、各サブ予測器のバランスをグローバルに調整できます。最終予測pは加重和として計算されますが、実際の整数除算は避けるために近似的な方法が用いられます。これは、「計算効率」と「アルゴリズムの複雑性」の間で、常に最適なバランスを模索するという、エンジニアリングの厳しさを示しています。

    コラム：予測の甘い罠

    「明日、株価はどうなるか？」「次の選挙で誰が勝つか？」「あの人は私をどう思っているか？」人間は常に「予測」をしたがります。デジタル画像の圧縮もまた、突き詰めれば「次の画素の色はどうなるか？」という予測の連続です。

    私がまだ駆け出しのデータサイエンティストだった頃、とある顧客の購買履歴データから、次に彼らが何を買うかを予測するプロジェクトに携わったことがあります。最初のうちは、過去の購買パターンから単純なルールをいくつか作って適用しました。「先週コーヒー豆を買った人は、今週も買うだろう」とか、そんなシンプルなものです。もちろん、予測精度は散々でした。

    しかし、データを深く掘り下げ、より複雑な「コンテキスト」（購入時間帯、他の購入品目、過去のキャンペーン反応など）を考慮し、様々な予測モデルを組み合わせていくと、驚くほど予測精度が向上するのです。まるで、顧客の「心の声」が聞こえるかのような錯覚に陥るほどに。しかし、どんなにモデルを洗練させても、予測には必ず「誤差」が伴います。そして、その誤差をどう扱うか、つまり「どのようにごまかすか」が、そのモデルの実用性を決定するのです。

    JPEG XLの予測器もまた、この「予測の甘い罠」と格闘しています。MAツリーは、画素の「心の声」を聞き取ろうとする「占い師」のようですし、自己修正予測器は、自らの過ちから学ぶ「賢者」のようです。しかし、どんなに賢い予測器でも、未知のデータに対しては無力です。結局のところ、予測とは、未来の不確実性を、ある種の「確率的な幻想」に落とし込む作業に過ぎないのかもしれません。そして、その幻想をいかに「真実らしく」見せるかが、圧縮技術の「奥義」なのです。

    第八章：VarDCTモード：「光の粒」を操る「物理法則」

    JPEG XLの「VarDCTモード

    詳細JPEG XLの主要な符号化モードの一つで、主にロスリー圧縮に用いられる。従来のJPEGが固定の8x8ブロックでDCT（離散コサイン変換）を適用するのに対し、VarDCTでは可変サイズのブロック（8x8から256x256まで）と可変量子化を適用する。これにより、より効率的で知覚的に最適化された圧縮が可能となる。
    」は、ロスリー圧縮の領域において、まるで「光の粒」を操る「物理法則」を解き明かしたかのようです。従来のJPEGが、8x8ピクセルという固定の「レンガ」で画像を構築していたのに対し、VarDCTは、より多様なサイズの「レンガ」と、その「接着剤」の量を状況に応じて変化させることで、より効率的で、より美しい「構造物」を構築します。これは、単なる「進化」ではなく、ある種の「パラダイムシフト」と言えるでしょう。 🔬

    7.1 VarDCTの基本概念

    JPEGは、8x8ピクセルのブロックに固定サイズの離散コサイン変換（DCT）を適用し、その係数に固定の量子化ステップを適用していました。これは、まるで「どんな画像でも同じサイズの網で捕まえる」という、ある種の「画一的な暴力」でした。しかし、JPEG XLのVarDCTモードでは、ブロックサイズと量子化の両方が可変です。これが「VarDCT（Variable-blocksize DCT）」という名の由来です。この柔軟性が、画像の多様な特性に「適応」し、より効率的かつ知覚的に最適化された圧縮を可能にします。

    このアプローチは、画像内の滑らかな領域には大きなブロックを適用して冗長性を排除し、細部やエッジの多い領域には小さなブロックを適用して精度を保つという、まるで「賢い資源配分」を行います。これにより、同じファイルサイズでも、より視覚的に優れた結果を得ることができるのです。

    7.2 ブロックサイズとタイプ

    VarDCTモードで利用可能なブロックサイズとタイプは、多岐にわたります。これは、まるで画家が、筆の種類や太さを自在に使い分けるかのようなものです。 🖌️

    • 8x8ピクセルのブロックに適用される10種類の変換。これには、JPEGで使われるDCT8x8が含まれますが、それ以外にも、より小さなブロックへのセグメンテーション（例：DCT4x8は8x8ブロックを2つの水平な長方形DCT変換で構成）を行うものがあります。
    • 16x16から256x256までの5種類の大きな正方形DCT変換。
    • 2:1のアスペクト比を持つ5種類の水平長方形DCT変換と、1:2のアスペクト比を持つ5種類の垂直長方形DCT変換。さらに、4:1と1:4のアスペクト比を持つDCT8x32とDCT32x8変換。
    • 特殊な変換として、Hornuss変換
      詳細JPEG XLのVarDCTモードにおける特殊なブロック変換の一つ。4x4ピクセル単位でサンプル値を直接符号化するが、各4x4チャンクの平均値に対して相対的に表現される。特定の画像パターンやロスレス圧縮の微細なディテール表現に用いられる可能性がある。
      （4x4チャンク内のサンプル値を平均相対で直接符号化）や、AFV変換
      詳細JPEG XLのVarDCTモードにおける特殊なブロック変換の一つ。水平DCT4x8、正方形DCT4x4、そして一角が欠けたDCT4x4のバリアントを組み合わせたもの。画像の一部で特殊な構造を持つ領域の符号化に用いられる可能性がある。
      （水平DCT4x8、正方形DCT4x4、および「角がカットされた」DCT4x4のバリアントで構成）などがあります。

    これらの多様なブロックタイプは、エンコーダが画像内のあらゆる構造に「適応」し、最適な圧縮戦略を適用することを可能にします。エンコーダは、まるで「画素の地形」を読み解き、最適な「採掘戦略」を選択する地質学者のようです。

    7.3 LF画像：低周波情報の「骨格」

    JPEGでは、DCT8x8変換の後、最低周波数係数（DC係数）が8x8ブロックの全サンプル平均に対応し、これが1:8ダウンサンプリング画像（DC画像）を形成しました。プログレッシブJPEGでは、このDC画像が最初のプレビューとなります。JPEG XLでも、同様に画像の1:8ダウンサンプリングバージョンである「LF画像

    詳細Low-Frequency image（低周波画像）の略称。JPEG XLのVarDCTモードで用いられる概念で、画像の1/8にダウンサンプリングされた低解像度バージョンを指す。DCT8x8ブロックのDC係数や、より大きなDCT変換の低周波係数に相当する。プログレッシブデコードにおける初期プレビューとして機能する。
    」が符号化の基盤となります。

    しかし、JPEG XLでは、LF画像はDCT8x8のDC係数だけでなく、より大きな変換（例：DCT8x16）の場合には、追加の低周波係数も含まれます。これにより、LF画像は単なる平均値の集合体ではなく、より詳細な「骨格」情報を持つことになります。LF画像を符号化する方法は2つあります。直接符号化（Modularサブビットストリームを使用）か、以前に符号化されたLFフレーム

    詳細JPEG XLで用いられるフレームタイプの一つ。将来のフレームの低周波（LF）情報、すなわち8分の1にダウンサンプリングされたバージョンを表現する。デコードされたシーケンスの一部としては表示されず、より高解像度なフレームを再構築するための補助データとして機能する。巨大な画像を効率的に表示するためのピラミッド構造にも利用される。
    を参照するかです。後者は、再帰的に最大4レベルのピラミッド構造を構築することを可能にし、テラピクセル級の巨大な画像を効率的に扱うことを可能にします。これは、まるで「情報の圧縮ピラミッド」であり、最初に全体像の粗いプレビューを提供し、徐々に詳細を明らかにするという、ある種の「真実の段階的開示」を可能にします。

    適応型LFスムージング：カラーバンディングの抑制

    LF画像が直接符号化される場合、そのサンプル値は整数に量子化されます。オプションで、デコード後に「適応型LFスムージング」ステップを適用するようにシグナリングできます。このステップは、滑らかなグラデーション領域（隣接するLFサンプル間の差が量子化バケットサイズに近い領域）でLF画像を滑らかにする効果があります。これは、低品質設定でLF量子化が粗い場合に発生しがちな「カラーバンディング」や「ブロックノイズ」といった「視覚的な醜さ」を、あたかも魔法のように抑制します。JPEG XLが、極めて低い品質設定でも滑らかなグラデーションを保持できるのは、この適応型LFスムージングのおかげです。これは、単なる圧縮率の追求だけでなく、「知覚的な美しさ」をも追求するという、JPEG XLの「信念」の表れです。

    7.4 HFメタデータ：高周波を操る「指令」

    LFグループと共に、ブロックへのセグメンテーション、適応量子化の重み、クロマからのルマ乗数、フィルター強度を定義するためのいくつかの制御フィールドがシグナリングされます。これらは「HFメタデータ

    詳細JPEG XLのVarDCTモードにおいて、高周波（HF）データに適用される補助的な制御情報。画像のブロック分割、適応量子化の重み、クロマからのルマ予測乗数、エッジ保存フィルター強度などを含む。これらは通常、LFグループの領域（2048x2048ピクセル）ごとにModularサブビットストリームとして符号化される。
    」と呼ばれ、LFグループごとの領域（2048x2048フレーム領域）にバンドルされます。これにより、HFグループごと（256x256フレーム領域）にシグナリングする場合と比較して、より良いエントロピー符号化と低いシグナリングオーバーヘッドを実現します。まるで、司令官が部隊全体に一度に指令を出すことで、伝達効率を高めるかのようです。

    これらの制御フィールドは、Modularサブビットストリームを使用してエンコードされます。VarDCTモードが、その内部でModularモードの「知恵」を借りているという事実は、JPEG XLが単一の技術に固執せず、「最適なものを組み合わせる」という、極めて実用的なアプローチを取っていることを示しています。

    7.4.1 XFromY, BFromY：クロマからのルマ予測乗数

    HFメタデータの最初の2つのチャンネルは、1:64の解像度（32x32ピクセル）を持ち、「クロマからのルマ」で使用されるXFromYおよびBFromY乗数を表します。これは、色度情報が輝度情報と相関しているという事実を利用し、その相関性を予測することで、色度データの冗長性を排除するものです。

    7.4.2 DctSelect：ブロックタイプ選択の効率的な表現

    ブロックサイズが大きく変化するため、セグメンテーション（ブロックの選択）を1:8解像度の2D画像として表現するのは非効率です。代わりに、ブロックをスキャンライン順序で走査し、各ブロックが最初に出現した左上隅の位置のみを記録することで、1D配列に「平坦化」されます。この1D配列は、HFメタデータの第3チャンネルとして符号化されます。これは、まるで「地図を効率的に表現する」ための、巧妙なデータ構造です。JPEG再圧縮の場合、DCT8x8のみが使用されるため、この行は全てゼロとなり、シグナリングオーバーヘッドは無視できるほど小さくなります。

    7.4.3 HfMul：量子化重みの乗数

    このnb_blocks x 2チャンネルの2行目には、各ブロックの高周波（HF）係数の量子化の粗さに影響を与える重みが含まれます。量子化係数は、g * (1 + x)という形で乗算されます。JPEG再圧縮の場合、固定量子化しかできないため、g = 2^16とし、この行も全てゼロとシグナリングすれば十分です。これは、「細かな調整」を可能にしつつ、「デフォルトの効率性」も確保するという、ある種の「両立」です。

    7.4.4 Sharpness：エッジ保存フィルター強度

    HFメタデータの第4チャンネルは、1:8解像度の画像で、エッジ保存フィルター（EPF）

    詳細Edge-Preserving Filter（エッジ保存フィルター）の略称。JPEG XLの復元フィルターの一つ。画像の重要なエッジ（輪郭）をぼかさずに、DCTノイズやリンギングアーティファクトを効果的に低減する非線形フィルター。バイラテラルフィルターに類似している。
    の局所的な強度をシグナリングします。この画像内のサンプル値は、平滑化の振幅を0から7の整数範囲で示します。デフォルトでは、iがi/7にマッピングされますが、任意のルックアップテーブルをシグナリングして異なるマッピングを実装することも可能です。これは、「画質の微調整」を可能にするためのものです。

    7.5 HF符号化：高周波係数の「精緻な削り取り」

    VarDCTモードでは、画像データの大部分は高周波（HF）係数で構成されます。これらは、1:8解像度のLF画像には存在しない「詳細」を表します。まさに、画像の「魂」を構成する、微細な情報です。 🔪

    7.5.1 量子化テーブルの圧縮とデフォルトテーブル

    高周波DCT係数は、JPEGと同様に、各係数位置に量子化係数を割り当てる「量子化テーブル」を使用して量子化されます。JPEGでは量子化テーブルが非圧縮で格納されていましたが、JPEG XLでは量子化係数が整数に制限されず、よりきめ細やかな品質設定と正確なビットレートの「スペクトル割り当て」が可能になりました。さらに、量子化テーブル自体が圧縮された形で符号化されます。これは、「無駄を徹底的に排除する」という、JPEG XLの執念の表れです。

    明示的な非圧縮量子化テーブルは、特に大きな変換の場合、法外なシグナリングオーバーヘッドを発生させます（DCT256x256では65536バイトにもなる）。そのため、JPEG XLでは量子化テーブルの圧縮が用いられ、明示的なテーブルは一般的に回避されます。JPEG XLの量子化テーブルの符号化には3つの段階があります。

    • **Explicit (明示的):** 半浮動小数点数の分母をシグナリングし、その後量子化テーブルと同じ寸法を持つ3チャンネル画像をModularサブビットストリームで表現します。これは、ロスレスJPEG再圧縮のために使用されます。
    • **Parametrized (パラメータ化):** 仕様の一部であるアルゴリズムを使用して、少数のパラメータから量子化行列を計算します。
    • **Default (デフォルト):** パラメータ化されたコーディングモードのデフォルト値を使用することで、量子化テーブルを極めて簡潔にシグナリングします。

    libjxlでは、デフォルトのテーブルを使用し、グローバルなスケーリング係数でスケールするだけなので、量子化テーブルのシグナリングオーバーヘッドは非常に小さくなります。XYBのBコンポーネントのデフォルト量子化テーブルは、他の2つのコンポーネントよりも「実質的」に急峻です（高周波係数がより粗く量子化されます）。この違いは、XYB色空間の設計理由と同様に、「知覚的な動機」に基づいています。つまり、人間の目が「あまり気にしない部分」は容赦なく削ぎ落とす、という冷徹な判断です。

    7.5.2 係数再順序付け

    HF係数が符号化される順序は、圧縮効率に影響を与えます。特に滑らかな画像領域では、最高周波数の係数はゼロに量子化される傾向があるため、係数を低周波から高周波へと順序付けると、より長いゼロの連続が発生しやすくなります。JPEG XLは、デフォルトで一般的なジグザグ順序を使用しますが、「任意の係数順序」をシグナリングできます。これにより、複数のプログレッシブパスと組み合わせて、特定のパス（例：1:2解像度プレビュー）のために、更新されない係数（値が全てゼロ）を最後に配置することで、それらをシグナリングオーバーヘッドなしで「スキップ」することが可能です。係数再順序付けの順列はLehmer code

    詳細順列を整数列（レーマー符号）で表現する手法。これにより、特定の順列を効率的に符号化・復号化できる。特に、デフォルトの順列からの差分が小さい場合に、情報量を少なく表現できるため、圧縮効率を高めるのに役立つ。JPEG XLのTOCやDCT係数再順序付けに用いられる。
    を使用してシグナリングされます。これは、「情報の効率的な再配置」によって、圧縮を最大化するためのものです。

    7.5.3 NonZeros：非ゼロ係数カウント

    JPEGでは、連続するゼロの系列を単一のコードで表現し、ブロックの残りの全係数がゼロであることを示す特殊なEOB（End-of-Block）コードがありました。JPEG XLのアプローチは若干異なります。各ブロック内の非ゼロ係数の数が「明示的に」シグナリングされます。これは、隣接するブロックの対応する数の平均から予測されますが、シグナリングされるのは予測残差ではなく、絶対的なカウントです。係数はシグナリングされた順序で走査され、これまでに符号化された非ゼロ係数の数がカウントされます。非ゼロ係数の総数が事前にシグナリングされているため、EOBコードは不要です。これは、まるで「無駄を排除する」という、極めて合理的な設計です。コーディングループは、最後の非ゼロ係数を符号化した直後に終了します。潔いものです。

    7.5.4 コンテキストモデルの洗練

    HF係数のエントロピー符号化で使用されるコンテキストモデルは、非常に洗練されています。それは、まるで「画素の振る舞い」を深く理解し、それに合わせて「最適な圧縮戦略」を動的に選択する、ある種の「デジタル知能」のようです。

    • **ブロックコンテキスト:** 各ブロックには、コンポーネントインデックス、ブロックタイプ、適応量子化重み、量子化されたLF値などに応じて変化する「ブロックコンテキスト」があります。これにより、最大2496種類の初期ブロックコンテキストインデックスが生成されますが、これらはさらに「ブロックコンテキストマップ」を使用して最大16種類の異なるブロックコンテキストに削減されます。
    • **非ゼロコンテキスト:** 非ゼロ係数数を符号化するために使用されるコンテキストは、ブロックコンテキストと予測値に依存します。これは、隣接するブロックの非ゼロカウントから予測されます。
    • **係数コンテキスト:** 実際のHF係数に使用されるコンテキストは、ブロックコンテキスト、係数位置（再順序付け後）、残りの非ゼロ係数数、そして「前の係数が非ゼロだったか」を示すブール値に依存します。

    各256x256 HFグループ（および複数のプログレッシブパスの場合、各パスも）は、独自のコンテキストセットを使用できます。ただし、イメージコンテンツの特性がグループ間で類似している場合、コンテキストを共有することでシグナリングオーバーヘッドを削減できます。各HFパスでは、コンテキストは「コンテキストマップ」を使用して、最大255種類の異なる分布にクラスタリングされます。これは、「複雑性」を管理し、「効率性」を最大化するための、巧妙な手段です。

    7.5.5 適応型量子化

    HFメタデータの一部としてシグナリングされるHfMul重み

    詳細JPEG XLのVarDCTモードにおける、適応量子化を制御する重み。HFメタデータの一部として符号化され、各ブロックの高周波（HF）係数の量子化の粗さ（細かさ）を局所的に調整するために用いられる。これにより、画像内の異なる領域で知覚的な品質をより一貫させることができる。
    は、HF係数の量子化の粗さを局所的に変調するために使用できます。JPEGでは、同じ量子化係数が画像全体に均一に適用されていましたが、これは、画像の「難しい」領域（複雑なテクスチャや細部）でアーティファクトを避けるためには、画像全体の品質をグローバルに上げるしかなかったという「鈍感さ」を意味していました。適応量子化を可能にすることで、JPEG XLエンコーダは、より一貫した画質を確保できます。これは、まるで「局所的な問題」に、「局所的な解決策」を適用する、ある種の「賢明さ」です。

    量子化粒度の調整は、HF係数の精度だけでなく、エッジ保存フィルター（EPF）のベースライン変調にも影響を与えます。量子化が粗い領域はより積極的に平滑化され、EPFの強度はさらにSharpness重みで調整できます。これにより、ベースEPF強度が量子化バケットの幅に比例するため、Sharpness重みのシグナリングオーバーヘッドを削減できます。これは、複数の要素が互いに影響し合い、全体として「最適化されたハーモニー」を奏でるような設計です。

    7.5.6 Chroma from luma

    色度情報は、局所的に輝度情報と相関していることが多いです。JPEG XLの「クロマからのルマ

    詳細JPEG XLのVarDCTモードで用いられる技術。輝度（luma）情報から色度（chroma）情報を予測し、その差分（残差）を符号化することで圧縮効率を高める。これにより、輝度と色度の間の相関性を利用して、より効率的な色度情報の表現が可能になる。
    」メカニズムは非常にシンプルです。各64x64領域に対して乗数XFromYとBFromYがシグナリングされ、XおよびBコンポーネントの（非量子化）HF係数から、これらの乗数を掛けた対応するY係数の値が、エンコード前に差し引かれます（デコード後に追加されます）。

    このアプローチは、DCTドメインでHF係数にのみ作用するため、ピクセルドメインで任意の線形非相関化を適用することに相当します。これは、ピクセルレベルではC = α * L + βのような予測として見ることができ、加法項βはLF係数によって提供され、乗数αはHFメタデータ内のXFromYとBFromYを通じてシグナリングされます。これは、まるで「色の相関」という名の「無駄」を徹底的に排除し、本質的な情報だけを抽出する、ある種の「冷徹な分析」です。

    コラム：量子化の芸術

    「量子化」という言葉を聞くと、多くの人は「情報を失うこと」と捉えるでしょう。それは間違いではありません。しかし、私は量子化を、ある種の「芸術」だと考えています。

    かつて、私はアナログの写真をデジタル化するプロジェクトに携わっていました。何十年も前に撮影された古い写真のネガやプリントをスキャンし、デジタルデータとして保存するのです。しかし、スキャンされたデータは途方もない容量になり、そのままでは扱いきれません。

    そこで、JPEGなどの圧縮技術を使って量子化するわけですが、この時、私はいつも悩みました。「どこまで情報を削っていいのか？」と。ある人は「見た目が変わらなければいい」と言い、またある人は「細部のノイズまで残すべきだ」と言います。その「許容範囲」は、実に曖昧で、個人的な感覚に左右される部分が大きかったのです。

    特に、グラデーションの多い空の画像では、量子化を強くかけると「カラーバンディング」という名の醜い縞模様が浮き出てきます。まるで、絵の具を混ぜるのが下手な画家が描いたような。それを防ぐために、JPEG XLの「適応型LFスムージング」のような技術が必要になるわけです。これは、単にデータを捨てるだけでなく、「人間が許容できる形で、いかに情報を捨てるか」という、ある種の「知覚的なごまかし」なのです。

    量子化は、デジタル世界における「取捨選択」の行為であり、その選択には常に、技術者の「哲学」と「美意識」が問われます。そして、その「芸術性」を、いかにアルゴリズムに落とし込むか。それが、圧縮技術者の最も困難で、最も面白い挑戦なのでしょう。最終的に、私たちの目に「美しく」映るならば、それはもう「真実」なのですから。

    第九章：補完技術：画素の「化粧」と「修復」

    JPEG XLは、その主要な符号化モード（VarDCTとModular）だけでは捉えきれない、「画素の個性」や「不完全さ」を補うための、様々な補完技術を持っています。それはまるで、画像という名の顔に「化粧」を施し、あるいは「修復」を加えて、より「完璧な」姿に見せるかのようなものです。これらの技術は、圧縮効率だけでなく、知覚的な画質を向上させ、特定のコンテンツタイプをより忠実に表現するために存在します。 💅✨

    8.1 画像特徴の「専用道具」

    主要なコーディングツール（DCTとModular）では効率的にエンコードできない、特定の種類の画像特徴が存在します。JPEG XLは、これらの「扱いにくい」特徴を、より効果的に表現するための3つの専用コーディングツールを提供します。これは、まるで「特殊な問題」には、「特殊な解決策」を適用するという、ある種の「職人技」です。

    8.1.1 Splines（スプライン）：曲線表現の芸術

    薄くて高コントラストの曲線、例えば線画や髪の毛のストランド、木の細い枝などは、DCTベースの圧縮にとって「非常に厄介な存在」です。それらを忠実に表現するには、最高周波数係数を含む全ての係数を細かく量子化する必要があり、結果としてエントロピー符号化後のビットレートが肥大化します。あるいは、量子化を強めすぎると、線がぼやけたり（最悪の場合消滅したり）、目立つリンギングやDCTノイズアーティファクトが発生します。

    このため、JPEG XLには、このような線をセントリペタルなCatmull-Romスプライン

    詳細曲線を描画するための補間スプラインの一種。複数の制御点を通る滑らかな曲線を作成するために用いられる。各制御点が曲線上に厳密に位置するため、直感的で制御しやすい。JPEG XLでは、Splinesコーディングツールで細い高コントラストの曲線を表現するために採用されている。
    という形式で直接表現するための専用コーディングツールが追加されました。スプラインは、一連の制御点（開始点と点数、その後の制御点の相対位置の水平・垂直差）で定義されます。結果として得られる線は、各制御点を通る補間曲線を描き、自己交差することもあります。このパスの円弧長に沿って、線の色と太さを変化させることができます。色コンポーネントとシグマパラメータ（太さを制御）は、エントロピー符号化された一次元DCT32係数としてシグナリングされます。最初の係数がベースの色と太さを表し、残りの係数がパスに沿ったこれらの値の変調を可能にします。

    スプラインは、基礎となる背景画像に（符号付きの）色サンプル値を追加することでレンダリングされます。シグマパラメータは、パスからの距離に応じて振幅を変調するガウス関数の変化として解釈できます。これにより、ピクセルよりも細い線や、ピクセル単位で整数である必要のない任意の太さの線を、適切なアンチエイリアシングを伴って表現できます。太さパラメータは負の値も許容され、その場合、色サンプル値が画像から減算されます。これは、まるで「デジタルアートの筆致」を、直接データとして組み込むかのような、ある種の「芸術的冒険」です。

    現在のエンコーダではスプラインの検出は実装されていませんが、手動での実験では、スプラインを抽出し別途符号化することで、実質的な圧縮性能の向上（ゲイン）が得られることが示唆されています。これは、技術の「夢」がまだ完全に「現実」となっていない、ある種の「未熟さ」を示しているとも言えるでしょう。

    8.1.2 Patches（パッチ）：繰り返しパターンの記憶と活用

    画像には、同じ要素が何度も繰り返されて出現することがあります。例えば、ラスタライズされた活字、アイコン、ユーザーインターフェース要素を含む画像は、それぞれが小さな形状の「繰り返し」から構成されていると見なせます。マルチフレームアニメーションでは、前のフレームの要素が、次のフレームで異なる位置に現れることもあります。マルチレイヤー画像やマルチページ画像でも同様です。

    Patchesコーディングツール

    詳細JPEG XLのコーディングツールの一つ。画像内の繰り返しパターン（テキストの文字、アイコンなど）を効率的に圧縮するために用いられる。以前にデコードされたフレームから矩形領域（パッチ）を抽出し、現在のフレームの任意の位置に様々なブレンドモードで適用することで、同じパターンを複数回符号化する手間を省く。
    は、このような「冗長性」を巧みに利用します。最大4つまで以前に符号化されたフレームを「保存」し、それらのフレーム内の矩形領域を「パッチ」として選択し、現在のフレームの任意の位置に1つ以上の場所で追加します。これは、まるで「デジタル記憶の再利用」であり、「無駄な重複」を徹底的に排除しようとするものです。

    様々なブレンドモードがサポートされており、エクストラチャンネルが存在する場合、カラーチャンネルと各エクストラチャンネルで異なるブレンドモードを選択できます。これは、Photoshopのような高度な合成機能を、コーデックレベルで実現するという、ある種の「全能感」です。

    サポートされるブレンドモード>
    • None (なし): 何も行いません。特定のチャンネルにのみパッチを適用する場合に有用です。
    • Replace (置換): サンプル値をパッチで上書きします。
    • Add (加算): パッチ値を残差画像に加算します。
    • Mul (乗算): サンプル値をパッチ値で乗算します。
    • BlendAbove (上からブレンド): パッチが残差画像の上にあるレイヤーであるかのようにアルファブレンドします。
    • BlendBelow (下からブレンド): 残差画像がパッチの上にあるレイヤーであるかのようにアルファブレンドします。
    • MulAddAbove (乗算加算上から): パッチサンプル値をパッチアルファ値で乗算し、結果を下位画像に加算します。
    • MulAddBelow (乗算加算下から): サンプル値をパッチアルファ値で乗算し、パッチサンプル値を加算します。

    パッチブレンドのために「アルファチャンネル」として使用するエクストラチャンネルのインデックスもシグナリングされます。アルファ値を[0, 1]の範囲にクランプするかどうかも選択できます。現在のlibjxlエンコーダでは、パッチブレンドモードとして「Add」のみが使用されています。ロスリー圧縮の場合、これにより「不完全な一致」を許容しつつ、忠実度を損なわないようにできます。なぜなら、不完全な一致は元の画像データを置き換えるのではなく、エンコード時に元のデータから減算され、残差画像が不完全な一致によるエラーを補正できるからです。これは、まるで「失敗を許容し、それを糧とする」という、ある種の「寛容な効率性」です。

    8.1.3 Noise（ノイズ）：合成ノイズによる「視覚的な欺瞞」

    ノイズは、エントロピー符号化の観点から見ると「極めて厄介な存在」です。なぜなら、高周波でランダム（つまり高エントロピー）だからです。数学的にロスレスな圧縮の場合、この高エントロピーは避けられません。ノイズの多い画像は、必然的に「クリーン」な画像ほど密に圧縮できません。しかし、ロスリー圧縮の場合、実際のノイズとはピクセルレベルで全く異なっていても、見た目が似ている「合成ノイズ」を使用することが可能です。これは、ある種の「視覚的な欺瞞」です。

    ロスリー圧縮の一般的な副作用として、高周波係数がより積極的に量子化されるため、ノイズの一部が削減され、EPFのような平滑化フィルターによってさらに軽減されます。これは、ノイズが意図的でなかったり望ましくなかったりする場合には問題ありませんが、場合によっては、芸術的目的やアーティファクトをうまく隠蔽するため（つまり、ディザリングの一形態として）、ノイズを保持したいことがあります。

    JPEG XLのノイズ合成は、主に「フォトンノイズ

    詳細デジタル写真において、光子（フォトン）の量が少ない場合に発生するランダムなノイズ。ISO感度が高い設定で顕著になる。JPEG XLでは、このフォトンノイズをシミュレートする合成ノイズを生成し、圧縮効率を高めつつ画像の見た目を自然にする。
    」をモデル化することを目的としています。フォトンノイズはピクセルサイズのノイズで、高ISO設定のデジタル写真で発生します。JPEG XLのノイズ合成は、微細なアナログフィルムグレインをモデル化するためにも使用できますが、個々のグレインの直径が複数のピクセルにまたがるような粗いグレインには適していません。

    ノイズが有効になっている場合、フレーム全体に適用されますが、ノイズの振幅は輝度（Y）コンポーネントに基づいて変調されます。シグナリングされたルックアップテーブルは、8つの明るさポイントで望ましいノイズ振幅を定義し、中間輝度値では振幅が補間されます。これにより、高ISO設定の写真で、暗い領域でよりノイズが多いといった特性をモデル化できます。生成されるノイズは主に輝度に影響し、色度への影響は少ないです。この生成されるノイズは完全に指定され、完全に決定論的です。これにより、デコードされた画像がピクセルレベルで正確に定義されることが保証されます。また、エンコーダが生成ノイズの効果を考慮し、必要に応じて補償することも可能になります。これは、「ランダム性」を「制御下」に置くという、ある種の「デジタル神の視点」です。🎥

    8.2 復元フィルター：「見せかけの美」を創り出す

    復元フィルターは、デコードされた画像の画質を、コーデック仕様の一部として改善することを目的としています。これは、エンコーダがデコーダ側のフィルタリングを考慮に入れることができ、最終的な画像が正確に定義されることを意味します。まるで、「見せかけの美しさ」を創り出すための、ある種の「デジタル美容整形」です。JPEG XLでは、復元フィルターはフレーム全体、つまりグループ境界を越えて適用されます。これは、TIFFやAVIFのようにコンテナレベルでタイリングが適用され、各タイルが別個のコードストリームに対応するフォーマットとは対照的です。コンテナレベルでのタイリングでは、各タイル内でのみフィルターが適用されるため、タイル境界に微妙な「継ぎ目」が生じることがありますが、JPEG XLではそれを回避します。完璧な「肌の均一性」を追求するかのようです。

    8.2.1 Gabor-like transform（Gaborish）：ブロックノイズの「隠蔽工作」

    「Gaborish」としても知られるGabor-like transformは、対称的な3x3カーネルを使用した、デコード側でのわずかなブラー（ぼかし）畳み込みに対応します。これは、JPEG圧縮で生じがちな「ブロックノイズ」という名の「醜い斑点」を、あたかも化粧のように隠蔽するものです。デフォルトでは特定のカーネルが使用されますが、オプションで異なるカーネル重みをフレームヘッダーでシグナリングでき、XYBコンポーネントごとに異なるカーネルを使用することも可能です。エンコード前にlibjxlは、デコード時のブラーとほぼ逆の5x5シャープニング畳み込みを適用します。エンコード側のシャープニングとデコード側のブラーは相殺されますが、DCT逆変換後に適用される平滑化畳み込みのおかげで、ブロックアーティファクトやその他のDCTアーティファクトを軽減するという全体的な効果が得られます。この技術は、ラップ変換のほとんどの利点を、低い計算コストで、特にデコードの複雑さを抑えながら実現します。これは、「低コストで高性能」という、ビジネスの世界で常に求められる理想を体現しています。

    8.2.2 Edge-preserving filter（EPF）：エッジを保つ「デジタル整形術」

    Gabor-like transformと比較して、エッジ保存フィルター（EPF）は、より洗練されており、強力です。Gabor-like transformが3x3カーネルしか使用しないのに対し、EPFは各ピクセル位置の周囲9x9領域までのピクセルを使用して、より広い距離にわたる平滑化を適用できます。その名の通り、EPFはバイラテラルフィルターに類似した非線形フィルターであり、エッジをぼかすことなくDCTノイズやリンギングアーティファクトを低減することを目的としています。これは、まるで「エッジを際立たせつつ、肌を滑らかにする」という、高度な「デジタル整形術」です。

    EPFの全体的な強度は、フレームヘッダーのepf_itersフィールドで設定でき、0から3までの整数値を取ります（0はEPF無効）。各反復で、各ピクセルは、周囲のひし形領域内の参照ピクセル（通常はピクセル自体とその4つの直接隣接ピクセル）の重み付けされた合計に置き換えられます。重みは、ピクセルと参照ピクセルの色差、ピクセルの直接隣接と参照ピクセルの対応する直接隣接の色差、ピクセル位置がブロック境界位置にあるかどうか、そしてローカルなHF DCT量子化の量（HfMul）とローカルなEPF Sharpness値に依存するシグマ値によって決定されます。この複雑な計算は、「細部へのこだわり」と、「人間の知覚」を深く理解していることを示しています。MPEG標準やAV1などの他のビデオコーデックで一般的に利用できる平滑化フィルターと比較して、JPEG XLのEPFは計算コストがやや高いものの、より繊細な平滑化効果を持ち、よりきめ細やかな局所調整が可能です。これは、「妥協なき品質」を追求する、ある種の「贅沢品」と言えるかもしれません。

    8.3 アップサンプリング：画素の「水増し」と「再創造」

    サブサンプリングは、粗雑ながらも効果的なコーディングツールです。一部の画像コンポーネント（または画像全体）を低解像度で保存し、デコーダ側のアップサンプリングに頼ることで、高周波情報は当然失われますが、非常に低いビットレートでより良い画質を得られる可能性があります。これは、まるで「失われた情報を、巧妙な方法で「水増し」し、あたかも存在するかのように見せる」という、ある種の「デジタル詐術」です。 📈

    8.3.1 シンプルアップサンプリング

    ロスレスJPEG再圧縮のために、JPEGデコーダ（libjpeg-turboなど）で一般的に実装されている単純な「三角形」アップサンプリングフィルターがJPEG XL仕様に含まれています。これは、YCbCrクロマサブサンプリング（第5章5.8節参照）の場合に使用されるアップサンプリングです。単純なアップサンプリングは、水平方向（4:2:2）、垂直方向（4:4:0）、またはその両方（4:2:0）に適用でき、個々のコンポーネント（通常はCbとCr）に適用されます。これは、「過去の遺物」を、現代の技術で「蘇らせる」ための、ある種の「互換性への配慮」です。

    8.3.2 非分離型アップサンプリング

    より洗練されたアップサンプリング方法も定義されており、カラー画像（3コンポーネント全てを同時に）または1つ以上のエクストラチャンネルをアップサンプリングするために使用できます。アップサンプリング係数は2倍、4倍、または8倍です。8倍アップサンプリングの場合、サブサンプリングされた画像の各入力サンプルは、アップサンプリングされた画像では8x8ピクセルのブロックになります。各出力サンプルは、入力サンプルを中心とした5x5領域の重み付けされた合計として計算されます。この方法は「非分離型」であり、一般的な（デフォルトの）ケースでは、一次元操作の組み合わせとして実行することはできません。64の出力サンプルそれぞれに対して5x5カーネルが異なる場合がありますが、特定の対称性が尊重されなければなりません。さらに、出力値は、入力サンプルを中心とした5x5領域の最小および最大サンプル値で定義された範囲にクランプされます。

    単純なピクセル複製（ニアレストネイバー）、典型的な分離型アップサンプリングフィルター（立方体フィルターやLanczos）と比較して、JPEG XLの非分離型アップサンプリングは、最も「美的満足度の高い結果」を生み出すと主張されています。過度なブラーを避けつつ、リンギングや階段状アーティファクト（特に斜めや曲線エッジで）も回避します。これは、単なる補間ではなく、「画素の再創造」とも呼べるものです。重みは画像ヘッダーの一部としてシグナリングでき、カスタムの重みがシグナリングされない場合はデフォルト値が使用されます。重みの一部のみがシグナリングされ、残りの重みは水平、垂直、対角対称によって暗黙的に定義されます。カスタムの重みを使用することで、ニアレストネイバーアップサンプリングのような新しい種類のアップサンプリングフィルターを作成することも可能です。これは、ピクセルアートで2x2、4x4、または8x8の「マクロピクセル」を作成するのに有用です。「技術による芸術表現の拡大」という、ある種の「ユートピア」を提示しているかのようです。

    8.3.3 LFアップサンプリング

    libjxlでは、デフォルトの8倍非分離型アップサンプリングは、1:8のLF画像のみが利用可能なプログレッシブプレビューをレンダリングする際にも使用されます。これは、「粗いプレビュー」をいかに「美しく見せるか」という、ある種の「視覚的な手品」です。

    コラム：完璧への執着

    デジタル画像を扱う中で、私は常に「完璧」という言葉に魅了されてきました。しかし、同時に「完璧」という概念が、いかに幻想的であるかを知っています。例えば、画像にわずかなノイズが乗ってしまったとします。人間にとっては「味」とすら感じられるかもしれないそのノイズも、コンピュータにとっては「余計な情報」であり、圧縮の邪魔になります。

    JPEG XLのノイズ合成機能は、まさにそのジレンマを解消するためのものです。「元のノイズは除去して、その代わりに人工的な、しかし見た目にはほとんど区別がつかないノイズを付加する」。これは、ある種の「等価交換」であり、同時に「完璧な再構築」ではなく、「完璧な知覚」を追求するという、ある種の「諦念」も感じさせます。

    また、EPFのような復元フィルターもそうです。圧縮によって生じたブロックノイズやリンギングを、エッジを壊さずに滑らかにする。これは、まるで「傷跡を消し去る」かのような技術です。しかし、果たして本当に「消し去って」いるのでしょうか？ それとも、ただ「見えなくしている」だけなのでしょうか？

    デジタル画像における「完璧」とは、私たち人間の視覚がそれを「完璧」だと認識する、その瞬間にのみ存在するのかもしれません。そして、JPEG XLの設計者たちは、この「人間の知覚」という名の「脆弱性」を、徹底的に研究し、それを技術に落とし込んだのです。これは、ある種の「執着」であり、同時に「人間という不完全な存在への挑戦」と呼べるかもしれません。

    第十章：エントロピー符号化：究極の「無駄排除」

    ヘッダーデータを除けば、JPEG XLの全てのデータは「エントロピー符号化」によって圧縮されます。これは、まるで「無駄を極限まで排除し、情報の真髄だけを抽出する」という、ある種の「究極のダイエット」です。この章では、JPEG XLがどのようにして、この「無駄排除の儀式」を執り行うのか、その冷徹なまでの論理を解き明かします。 ♻️

    9.1 統一されたエントロピー符号化方式の「神託」

    JPEG XLのエントロピー符号化方法は、まさに「統一された神託」と呼ぶにふさわしいものです。Modularチャンネルデータの残差、MAツリー自体のシグナリング、VarDCT HF係数、スプライン係数、パッチ参照データ、圧縮ICCプロファイルなど、あらゆる種類のデータがこの単一の方法で圧縮されます。これは、かつて複数の異なるエントロピーコーダが混在していた「混沌」を、一つの「秩序」へと変えたものです。

    各エントロピー符号化ストリームは、プレフィックス符号化（ハフマン符号化）またはANS（Asymmetric Numeral Systems）符号化のいずれかを使用できます。これは、まるで「状況に応じて最適な武器を選ぶ」かのような柔軟性です。さらに、LZ77コード（距離-長さペア）を追加で有効にするオプションもあります。コンテキストの数（クラスタリング前）は暗黙的ですが、これらのコンテキストは「コンテキストマップ」を使用してクラスタリングされます。各コンテキストクラスターには、独自のヒストグラムがシグナリングされます。プレフィックス符号化の場合、Brotliと同様のコンパクトなヒストグラム符号化が使用され、ANSの場合、ヒストグラムは12ビット精度の確率分布となります。

    シンボル符号化自体は「ハイブリッド整数符号化」と呼ばれ、全てのシンボルが「トークン」（エントロピー符号化される）と「生ビット」（ビットストリームに直接書き込まれる）に分割されます。生ビットの数はトークンに依存し、0から31ビットまで変化します。各コンテキストクラスターは、独自の構成を持ち、このシンボル分割の方法を決定します。これは、まるで「数字の構造を解体し、最も効率的な形で再構築する」という、ある種の「デジタル解剖学」です。エントロピー符号化されたトークンのアルファベットサイズは、ANSで28、プレフィックス符号化で215に制限されます。

    9.2 ハイブリッド整数符号化：「数字の化け方」

    ハイブリッド整数符号化の構成には、split_exponent、msb_in_token、lsb_in_tokenという3つのパラメータがあります。任意の符号なし32ビット整数を符号化できますが、ゼロに近い値がより一般的であり、高振幅シンボルよりもエントロピー符号化の恩恵を受けるという仮定に基づいています。これは、まるで「頻出するものは短く、稀なものは長く」という、情報理論の基本原理を忠実に守るものです。

    split_exponentよりも小さいトークンは、生ビットなしで直接シンボルに対応します。次のトークンはより大きな数を表し、トークンが指数（最上位ビットの位置）、msb_in_tokenが次の最上位ビット、lsb_in_tokenが最下位ビットを意味し、残りのビットが生ビットとしてシグナリングされます。この符号化スキームは、Riceコード、πコード、ζコード、Eliasコードといった他の符号化スキームと比較して、低い冗長性を示します。これは、まるでJPEGのDC符号化スキームの一般化であり、ハフマン符号化されたトークンが指数のみを意味し、全ての仮数ビットが生ビットとしてシグナリングされるのと似ています。AC符号化も同様ですが、ゼロの連続がLZ77の特殊ケースとして扱われる点が異なります。これは、「数字の化け方」を徹底的に研究し、最も効率的な「変身」を可能にするものです。

    9.2.1 符号ビットの扱い

    エントロピー符号化の観点から見ると、全てのシンボルは符号なし整数です。符号付き整数が必要な場合は、まず以下の変換で符号なし整数に変換されます。 

    
    k -> { 2*k if k >= 0
         -2*k - 1 if k < 0 }

    つまり、符号なしシンボル0, 1, 2, 3, 4, 5, 6は、符号付き整数0, -1, 1, -2, 2, -3, 3に対応します。これは、符号の情報を効率的に符号化するための巧妙なトリックです。結果として、エントロピー符号化されたシンボルの最下位ビットが符号に対応することが多くなります。データが均一な符号分布を持つ場合、符号ビットを生ビットとして符号化することは理にかなっていますが、コンテキストモデリングを考慮すると、符号にバイアスがある場合、lsb_in_token >= 1のハイブリッド整数符号化構成を使用する方が有利です。

    9.3 プレフィックス符号化（ハフマン符号化）：「古き良き」非効率

    プレフィックス符号化が使用される場合、各トークンは一意の可変長ビットシーケンスに対応し、どのトークンも他のトークンの（短い）コードのプレフィックスにならないという特性を持ちます。これは、ハフマン符号化

    詳細David A Huffmanによって1952年に開発された、可変長符号化方式の一つ。データの出現頻度に基づいて符号語の長さを割り当てる。出現頻度が高いデータには短い符号語を、低いデータには長い符号語を割り当てることで、全体として符号長を短縮し圧縮効率を高める。JPEGのベースラインモードで用いられている。
    のアルゴリズムに基づいて構築されます。コード自体のシグナリングは、Brotliと同様のコンパクトな方法で行われます。アルファベットサイズがゼロの場合（つまり、シンボルが1つしかない場合）には特殊なケースが設けられ、コードはシグナリングされず、全てのトークンがビットの読み書きなしで0に等しくなります。

    エンコーダの観点から見たプレフィックス符号化の主な利点は、その相対的な単純さです。固定コードを使用するか、ヒストグラムを計算して最適化されたコードを構築するかにかかわらず、圧縮されたビットストリームはシンボルから直接構築でき、デコード時に読み取られるのと同じ順序でビットが書き込まれます。これは、ANSコーディングが逆順でのエンコードと、ビットストリームを最後から構築する必要があるのと対照的です。

    しかし、プレフィックス符号化の大きな限界は、各トークンが「整数ビット数」を必要とすることです。ゼロトークンの確率が50%を超えるような特に一般的なケースでは、これは最適とは程遠い結果をもたらします。これは、まるで「古き良き技術」が、現代の「効率追求」の波に乗れないという、ある種の「悲劇」を象徴しているかのようです。

    9.4 ANS（Asymmetric Numeral Systems）：「新しき効率」

    Asymmetric Numeral Systems (ANS)は、プレフィックス符号化の高速なデコード速度と、算術符号化の精密な確率分布を組み合わせた汎用エントロピー符号化方法であり、より優れた圧縮率をもたらします。これは、まるで「過去の優れた技術のいいとこ取り」をしたかのような、ある種の「ハイブリッド技術」です。

    JPEG XLで使用されるANSの特定のバリアントは、エイリアスマッピングを使用したrANS

    詳細Range Asymmetric Numeral Systemsの略称。ANS（Asymmetric Numeral Systems）の具体的な実装の一つで、高速な符号化・復号化を特徴とする。JPEG XLで、従来のハフマン符号化よりも高い圧縮率と高速なデコード速度を両立させるために採用されている。
    です。32ビットの状態（エントロピー符号化ストリームごとに共有される）と、コンテキストごとに固定された12ビット精度の確率分布（合計212に正規化された整数ヒストグラム）を使用します。エンコード時、状態は常に特定の値（0x00130000）に初期化されます。これは、ANS符号化されたストリームをデコードした後の最終状態が常にこの値になることを意味します。この最終ANS状態は、まるで「チェックサム」のように機能し、伝送エラーなどによるビットストリームの破損を検出するために使用できます。これは、「効率性」と「堅牢性」を両立させようとする、ある種の「執念」です。

    9.5 LZ77（辞書圧縮）：「繰り返し」の美学

    LZ77

    詳細Jacob ZivとAbraham Lempelによって1977年に開発された辞書ベースのデータ圧縮アルゴリズム。データ内の繰り返されるパターン（文字列）を検出し、以前に出現したパターンの「距離」と「長さ」で置き換えることで圧縮を行う。JPEG XLでは、エントロピー符号化のオプションとして利用される。
    の使用が有効になっている場合（エントロピー符号化ストリームごとに選択）、ストリームヘッダーは追加で2つの数値：lz77.min_symbolとlz77.min_lengthをシグナリングします。距離を符号化するための暗黙的な追加コンテキストが追加され、長さを符号化するための追加のハイブリッド整数符号化構成lz_len_confがシグナリングされます。

    エントロピー符号化中、以前に符号化された最大220のシンボル（最大4メガバイトのメモリが必要となる場合がある）のスライディングウィンドウが維持されます。符号化されたシンボルsが通常のシンボルアルファベットの末尾にある場合、つまりs >= lz77.min_symbolの場合、それはLZ77コピー命令を表します。s - lz77.min_symbolの値は、ハイブリッド整数符号化構成lz_len_confのトークンとして解釈され、必要に応じて追加の生ビットが符号化されます。lz77.min_lengthが結果の数値に追加され、これがLZ77の長さ（スライディングウィンドウからコピーするシンボル数）となります。LZ77の距離は、暗黙的な追加コンテキストとその関連するハイブリッド整数符号化構成を使用して符号化されます。これは、「繰り返し」という名の「無駄」を徹底的に排除し、より効率的に情報を表現するための、ある種の「美学」です。

    9.5.1 特殊距離コード：2Dデータの効率化

    LZ77がモジュラーサブビットストリームで使用される場合、ロスレスWebPと同様に、最初の120個の距離コードはデータの2次元性を考慮して特殊な方法で解釈されます。例えば、距離コード0は以前に符号化されたシンボルを参照するのではなく、現在のサンプル位置より1画像行上のサンプル位置に対応します。これは、まるで「空間的な相関」を考慮し、より効率的にコピーを行うための「賢いショートカット」です。

    ただし、注意点が2つあります。1) LZ77は以前に符号化されたシンボルを参照しますが、モジュラー符号化の場合、これらは予測残差であり、直接サンプル値ではありません。2) 特殊距離は、現在のモジュラーサブビットストリーム内の最大チャンネル幅（通常256、またはグループ寸法）に基づいて定義されます。この幅を持つチャンネルの場合（通常全て）、図43（論文参照）は正しい位置を示しますが、異なる幅のチャンネル（例：エクストラチャンネルのサブサンプリングのため）の場合、実際の位置は異なります。

    JPEG XLでは、LZ77は主にランレングスエンコーディング（RLE）の特殊なケースや、秩序だったディザリングのような局所的な繰り返しパターンに有用です。より大きな繰り返し要素の場合、Patches（第9章8.1.2節参照）の方がより有用なコーディングツールとなります。なぜなら、Pat7.1.2hesは単一の参照で矩形全体をコピーできるのに対し、LZ77は行ごとに複数の参照を必要とするからです。これは、「目的に応じた適切な道具選び」という、実用主義の徹底です。

    9.6 コンテキストモデリングの深化

    コンテキストモデリングの目的は、エントロピー符号化されたシンボルを、似たようなヒストグラムを持つクラスターにセグメント化することで、より良い圧縮を実現することです。これは、まるで「情報の特性を読み解き、最適な分類を行う」という、ある種の「デジタル統計学」です。

    TOCや圧縮ICCプロファイルのようなヘッダーデータのシグナリングの場合、コンテキストの数は少なく固定されており、シンボルのコンテキストへの割り当ては明示的に指定されます。画像特徴のシグナリングも同様です。例えば、Splinesの場合、6つのコンテキストが使用されます。Patchesの場合、10の固定モデルが使用されます。

    VarDCTデータのHF係数には、より大きなコンテキストモデルが使用され、その一部の詳細はシグナリング可能です。これにより、エンコーダが画像データに合わせて「チューニング」できます。モジュラーサブビットストリームの場合、コンテキストモデルはMAツリーによって定義されます。MAツリー自体は、6つの固定コンテキストモデルを使用してシグナリングされます。結果として得られるコンテキストモデルのサイズは、単一のコンテキストから（ルートノードが葉である自明なツリーの場合）、プロファイルとレベルの制限によって許容される最大サイズまで変化します。エンコーダは、MAツリー自体のシグナリングコストと、より洗練されたコンテキストモデルがもたらす圧縮ゲインとのバランスを取る必要があります。また、デコード速度への影響も考慮されます。より小さく、より制約されたMAツリー（例：特定のプロパティのみを使用するツリー、自己修正予測器の維持が不要なツリー）は、より効率的にデコードできます。これは、「複雑性」と「実用性」の間の、永遠の綱引きです。

    9.6.1 コンテキストマップ：シグナリングオーバーヘッドの削減
    シグナリングオーバーヘッドを削減するため、似たようなヒストグラムを持つコンテキストはクラスタリングされ、その結果、「コンテキストマップ」（Brotliで初めて導入された概念）がシグナリングされます。これは、クラスタリング前のコンテキストイン

    コメント

    コメントを投稿

    このブログの人気の投稿

    #shadps4とは何か?shadps4は早いプレイステーション4用エミュレータWindowsを,Linuxそしてmacの #八21

       https://github.com/shadps4-emu/shadPS4 shadPS4は、Windows、Linux、macOS用のPlayStation 4エミュレーターです。このエミュレーターは、2022年10月にGeorge Moralisによって開発が開始され、主にPS4ゲームのエミュレーションを目的としています。shadPS4は、特に3Dゲームのサポートを強化するために、アーキテクチャにシェーダーを追加するなどの進展を遂げてきました。 主な特徴 : 対応プラットフォーム : shadPS4は、Windows、Linux、macOSで動作します。特にmacOSでは、Apple SiliconとIntelの両方のデバイスに対応しています。 ゲームの互換性 : 現在、shadPS4は約200タイトルが「ゲーム中」としてリストされており、そのうち155タイトルが「プレイ可能」とされています。特に「Bloodborne」や「Dark Souls Remastered」などの人気タイトルが動作しますが、すべてのゲームが完全にプレイできるわけではなく、特定のゲームに対してはハックが必要な場合もあります。 開発の進捗 : shadPS4は、2024年7月にバージョン0.1.0がリリースされ、その後も定期的にアップデートが行われています。最新のバージョンでは、レンダリングの改善や新機能の追加が行われており、ユーザーからは60FPS以上でのプレイが報告されています。 設定とカスタマイズ : エミュレーターは、初回起動時に「User」フォルダを作成し、その中にある設定ファイルを編集することで、さまざまなパラメータを調整できます。これにより、フルスクリーン表示や解像度の設定が可能です。 shadPS4は、PS4ゲームをPCで楽しむための有望な選択肢として注目されていますが、まだ開発段階にあるため、完璧なエミュレーション体験を期待することは難しいかもしれません。 shadPS4の開発者は ジョージ・モラリス（George Moralis） で、彼は「shadow」というユーザー名でも知られています。モラリスは、shadPS4の開発を2022年10月に開始しましたが、彼の背景には他の著名なエミュレーターの開発経験があります...
    MORE »

    🚀Void登場！Cursorに代わるオープンソースAIコーディングIDEの全貌と未来とは？#AI開発 #OSS #プログラミング効率化　#五09

    🚀Void登場！Cursorに代わるオープンソースAIコーディングIDEの全貌と未来とは？#AI開発 #OSS #プログラミング効率化 AIコーディングツールの新星「Void」を徹底解剖！Cursorとの違い、VSCodeフォークの是非、そして開発の未来をDopingConsommeが熱く語ります🔥 序文 どーも！売れっ子ブロガーのDopingConsommeです☕ dopingconsomme.blogspot.com とTwitterアカウント @Doping_Consomme を運営しています。バズるブログ記事ならお任せあれ！ さて、今回筆者が筆を執ったのは、巷で話題沸騰中のAIコーディングIDE「 Void 」について語り尽くしたいと思ったからです。Cursorの代替として彗星の如く現れたこのツール、オープンソースであるという点も相まって、開発者界隈では既に大きな注目を集めていますよね？ この記事では、Voidが一体どんなツールなのか、既存のツールと何が違うのか、そして私たちのコーディングライフをどう変えてくれる可能性があるのか、といった点を深掘りしていきます。読者の皆さんには、単なる機能紹介に留まらず、Voidを取り巻く議論や、AIと共存する未来の開発スタイルについて、多角的な視点から考えていただくきっかけになれば嬉しいです。それでは、熱いコーヒーでも片手に、じっくりお付き合いください！😉 はじめに この記事では、オープンソースのAIコーディングIDEである「 Void 」について、その特徴、機能、そして開発者コミュニティからの様々な意見を交えながら詳細に解説していきます。Voidは、人気のAIコーディングツール「Cursor」の代替を目指して開発されており、VSCodeをベースにしたフル機能のIDE（統合開発環境）です。AIエージェントの活用、ローカルでのモデル実行サポート、データのプライバシー重視といった点が主な特徴として挙げられます。 本記事を通じて、Voidがどのようなツールであり、現在のAIコーディングツール市場においてどのような位置づけにあるのか、そして将来的にどのような可能性を秘めているのかを明らかにしていきます。また、類似ツールとの比較や、開発におけるメリット・デメリット、さらにはコミュニティでの議論なども幅広...
    MORE »

    #INVIDIOUSを用いて広告なしにyoutubeをみる方法　#士17

    https://www.youtube.com/watch?v=XXXXXXXXXX ↑のURL↓のように入れ替えると広告なしにyoutubeをみれる。 https://yewtu.be/watch?v=XXXXXXXXXX Invidious は、 YouTubeに代わる無料のオープンソースのフロントエンドです。 Dockerコンテナとして、またはGitHubマスター ブランチから利用できます。公式 YouTube Web サイトの軽量で「プライバシーを尊重した」代替サイトとして使用することを目的としています。多くのプライバシー保護リダイレクト ソフトウェアおよび YouTube クライアントは Invidious インスタンスを使用します。 Invidious は、YouTubeの動画を広告なしで視聴できる、プライバシーに配慮したオープンソースのサービスです。Googleのトラッキングを避けつつ、YouTubeコンテンツを楽しみたい方におすすめです。 Invidiousのメリット 広告なし: YouTubeの煩わしい広告をスキップできます。 プライバシー保護: Googleのデータ収集を抑え、プライバシーを重視した視聴が可能です。 オープンソース: 誰でも自由に利用・開発できるオープンソースソフトウェアです。 多様なインスタンス: 世界中に多くのInvidiousインスタンスが存在し、それぞれ異なる特徴や機能を提供しています。 Invidiousの使い方 Invidiousインスタンスを探す: 検索エンジン: "invidious instance"などで検索すると、多くのインスタンスが見つかります。 リスト: いくつかのInvidiousインスタンスをまとめたリストサイトも存在します。 YouTubeの動画URLをInvidiousの検索バーに入力: 視聴したいYouTube動画のURLをコピーし、選んだInvidiousインスタンスの検索バーに貼り付けます。 動画を再生: 検索結果から目的の動画を選択し、再生ボタンを押せば広告なしで視聴できます。 Invidiousの使い方 Invidiousは、YouTube動画を広告なしで視聴できる便利なサービスです。 基本的な使い方 Invidio...
    MORE »