JPEG 2000

JPEG 2000
オリジナルのJPEGフォーマットとJPEG 2000との比較
拡張子.jp2, .jpg2,.jpc,.jph,.j2c, .j2k, .jpf, .jpx, .jpm, .mj2,.jph
MIMEタイプimage/jp2, image/jp2, image/jpx, video/mj2, image/jpm,image/jph
開発者Joint Photographic Experts Group
種別画像ファイルフォーマット
国際標準ISO/IEC 15444
オープン
フォーマット
はい。

JPEG 2000(ジェイペグにせん)は、静止画像圧縮技術及び同技術を用いた画像フォーマットの呼称である。ISOITUの共同組織であるJoint Photographic Experts Groupによって、国際標準化が進められており、ISO/IECの規格書15444およびITU-Tの勧告書Rec.T.800シリーズとして出版されている。

JPEG2000と詰めて書かずに、JPEG 2000と書くのが正式な表記である。JPEG 2000では、JPEGを上回る圧縮効率とスケーラビリティなどの機能を付加することを目的に規格策定作業が進められた[1][2]。なお、国際標準の規格書/勧告書で規定されているのは、JPEG 2000のコードストリームをデコードするための手順である。したがって、エンコーダの仕様については何も定められていない。どのように実装されたとしても、エンコーダに要求されるのは、標準によって規定された手順でデコードできるコードストリームを出力することである。

技術の概要

[編集]

JPEG 2000では、JPEGと同様、入力画像に対して周波数変換を施し、その変換係数に対して量子化エントロピー符号化を適用することで画像の持つデータ量を圧縮する。JPEGとの要素技術における主な相違点は、以下の通り。

JPEG 2000は、一つの圧縮画像を様々な解像度やビットレート等で利用できるというスケーラビリティ機能を有しているが、これは特に、量子化された変換係数から圧縮されたビットストリームを生成する役割を担うEBCOT(Embedded Block Coding with Optimized Truncation[3])アルゴリズムの持つ、高い符号化効率、圧縮後のレート制御(Post Compression Rate Distortion Optimization:PCRD-opt)などの特長に依るところが大きい。

Part

[編集]

2020年6月現在、JPEG 2000はPart1からPart16までが標準化されている[4]

ITU-T側で出版されている勧告書のうち、無料で入手可能なものには参照を付した。

JPEG 2000の各パートの名称と内容
Part 内容 ISO/IEC IS ITU-

T Rec.

1 基本方式, 基本ファイルフォーマット .jp2 15444-1 T.800
2 拡張 15444-2 T.801
3 Motion JPEG 2000, 動画像向けファイルフォーマット .mj2 15444-3 T.802
4 適合性試験 15444-4 T.803[5]
5 参照ソフトウェア 15444-5 T.804[6]
6 複合画像(文字と写真等が混在した画像)向けファイルフォーマット .jpm 15444-6 T.805[7]
7
8 Secure JPEG 2000, JPEG 2000画像のためのセキュリティサービス (JPSEC) 15444-8 T.807[8]
9 双方向通信のためのツール, API, JPIPプロトコル 15444-9 T.808[9]
10 3次元画像データのための拡張 15444-10 T.809[10]
11 ワイヤレス通信のための誤り検出・訂正符号化 (JPWL) 15444-11 T.810[11]
12
13 エントリレベルエンコーダ 15444-13 T.812[12]
14 XMLによるファイルフォーマットあるいはコードストリームの記述法 (JPXML) 15444-14 T.813[13]
15 高スループットブロック符号化, High Throughput JPEG 2000 (HTJ2K), .jph 15444-15 T.814
16 JPEG 2000画像のHEIF(ISO/IEC 23008-12)へのカプセル化 15444-16 T.815

コードストリーム構造

[編集]

JPEG 2000のコードストリーム構造の例を以下の図に示す。図内の用語のうち、タイルパート・レイヤ・DWTレベル・コンポーネント・プリシンクト・パケットヘッダ・サブバンドについては後述する。

JPEG 2000コードストリームの構造の例(LRCPプログレッション)

基本的には、SOC(Start of Codestream)マーカから始まるバイナリデータであり、その終端はEOC(End of Codestream)である。

SOCマーカの直後からメインヘッダが格納されており、各種符号化パラメータに関する情報がここに記録されている。メインヘッダの直後より、タイルパートが格納される。各タイルパートはタイルパートヘッダから始まる。タイルパートヘッダの直後より、そのタイルパートに含まれる圧縮データが格納される。

この圧縮データは、プログレッション順序に基づいて格納される。プログレッション順序とは、レイヤ(ある画質あるいはビットレートに対応する圧縮データの集合)、DWTレベル(DWTの分解レベルに対応する圧縮データの集合)、コンポーネント(色コンポーネント成分に対応する圧縮データの集合)、プリシンクト(DWT係数内の部分空間に対応する圧縮データの集合)の4つの要素のうち、優先的にデコードする要素の階層構造を意味する。コードストリームが取り得るプログレッション順序については後述する。

符号化手順

[編集]

下図は、JPEG 2000 Part 1の符号化手順のブロック図である。なお、本符号化手順は参考例であり、規格化されたものではないことに注意されたい。以下では、Part 1エンコーダにおける各ブロックの処理内容について述べる。以後、ここでは非可逆符号化をロッシーモード、可逆符号化をロスレスモードと呼ぶ。

JPEG 2000 Part 1 符号化の手順
JPEG 2000 Part 1 符号化の手順

入力画像

[編集]

規格上サポートされる入力画像のサイズ・ビット深度・色コンポーネント数などを以下にまとめる。各値は、実際にはエンコーダ・デコーダの実装上の制約を受ける。

  • サイズ:
  • ビット深度(1画素あたりのビット数):1〜38(符号付きデータの場合、符号ビットも含む)
  • 色コンポーネント数:1〜16384

タイル分割(オプション)

[編集]

入力画像はタイルと呼ばれる任意サイズの矩形領域に分割可能である。タイル分割は、エンコーダで利用できるメモリに制限がある場合などに有用である。各タイルは完全に独立して符号化されるため、分割数やビットレートによってJPEGで見られるようなブロックノイズが現れる場合もある。タイルの符号化結果であるバイトストリームは、上述のようなエンコーダの制約に応じて複数の部分集合(タイルパート)に分割することも可能である。

DCレベルシフト(オプション)

[編集]

入力画像が符号なしデータの場合、後述するDWT後の画像の直流成分が0中心になることを期待して、そのダイナミックレンジの1/2を入力画像から差し引く。

入力画像を、入力画像のビット深度、DCレベルシフト後の画像をとおくと、

と表すことができる。

色空間変換(オプション)

[編集]

入力画像がRGB色空間で定義されている場合、各色コンポーネント間の冗長性を排除するために、輝度-色差色空間(YUV)への変換を行う。用いる色空間変換はICT(Irreversible Color Transform)とRCT(Reversible Color Transform)の2種類が規定されている。ロッシーモードではICTを、ロスレスモードではRCTを用いる。以下では最初に、ICT、続いてRCTについて述べる。入力画像の各色コンポーネントをとする。ICTおよびRCTは以下の式で表すことができる。以下の式において、変換後の輝度コンポーネントはまたは、色差コンポーネントはまたはである。

ICT (Irreversible Color Transform)

[編集]

RCT (Reversible Color Transform)

[編集]

DWT

[編集]

JPEG 2000では、2分割フィルタバンクに基づく分離型2次元DWTが採用されている。分離型2次元DWTは、1次元に対する処理を、水平・垂直方向に施すことによって2次元の変換係数を得る手法である。Part 1では、ロッシーモード用とロスレスモード用の2つのDWTが定義されている。それぞれのDWTは、リフティングと呼ばれる構成法を取ることによって実現される。リフティング構成を取る理由は、数学的に可逆な変換が、変換係数の精度を有限(例えば整数)にしたとしても実現できることにある。下図は、3レベルの2次元DWTの実行例である。水平方向・垂直方向の各次元で、ローパスおよびハイパスフィルタがかけられるため、1レベルのDWTによって、4つのサブバンド(LL:水平垂直ローパス、HL:水平ハイパス、垂直ハイパス、LH:水平ローパス、垂直ハイパス、HH:水平垂直ハイパス)が生成される。各レベルでは、LLサブバンドを次々に分解していくオクターブ分割が実行される。Part 1で許されるDWTレベル数は0〜32と規定されている。

順方向2次元DWTの例

各々のDWTレベルにおいて、下図に示すようにプリシンクトと呼ばれる矩形領域が定義される。

JPEG 2000におけるプリシンクト

プリシンクトのサイズは2のべき乗の整数でなければならず、最大でのサイズを取ることができる。同一番号のプリシンクトは画像の部分領域を構成するDWT係数と考えることができ、後述するパケットおよびプログレッション順序の構成要素となる。

量子化

[編集]

Part 1では、スカラー量子化のみがサポートされている。Part 2ではTCQ(Trellis Coded Quantization[14])と呼ばれる量子化方法も使用可能である。

サブバンドのDWT変換係数を、ステップサイズをとおくと、スカラー量子化後の変換係数は次式で表される。

ロスレスモードでは、量子化による情報の損失は許されないため、で固定である。ロッシーモードにおけるステップサイズは、各DWTレベル、各サブバンドごとに異なる値を指定できる。

ROI(Region of Interest)(オプション)

[編集]

画像中の特定の領域を興味領域(ROI)として、他の領域(背景領域)と比べて符号化の優先度を高めるための処理である。興味領域内のDWT係数をMAXSHIFT[15]と呼ばれる方法でシフトアップすることで、符号化の優先度を高めることができる。サブバンドのDWT係数のダイナミックレンジを(bit)とすると、MAXSHIFT法によるシフト量は次式で表される。

MAXSHIFT法によるROI機能では、優先度の調節は不可能であるものの、デコーダに際してROIの形状に関する情報が不要という特長がある。

EBCOT

[編集]

コードブロック分割

[編集]

下図に示すように、EBCOTでは、各サブバンドは、コードブロックと呼ばれる矩形領域に分割される。コードブロックはEBCOTにおける最小符号化単位であり、各コードブロックはそれぞれ独立に符号化可能である。

コードブロック分割の例

コードブロックのサイズは、水平・垂直方向それぞれのサイズが4以上1024以下、面積が4096以下の条件を満たす2のべき乗の整数から自由に選ぶことができる。一般に64x64や、32x32のサイズが用いられることが多い。メインヘッダに記録されるコードブロックのサイズは一つであるが、実際のコードブロックサイズは画像サイズやDWTレベル数、プリシンクトサイズなどの様々なパラメータによって決定され、かならずしも全てのコードブロックで同一とはならない。コードブロック内の量子化されたDWT係数は、符号絶対値表現(符号付数値表現)で表される2進数として表現され、以後の処理はビットプレーンごとに進められる。

EBCOTにおけるビットプレーン

上図は、EBCOTにおけるビットプレーンの概念を示している。なお、図中のは、各コードブロックごとに計測されたゼロビットプレーン数である。ゼロビットプレーンとは、符号ビットを除く振幅係数において、プレーン内の係数ビットがすべて0であるプレーンが最上位ビットから連続する数である。このゼロビットプレーンに対する処理はスキップされ、その数のみが後述するパケットヘッダに記録される。

ビットモデリング

[編集]

各コードブロックは、ビットプレーンに分割される。各ビットプレーンは、最上位ビットに位置するプレーンから順に最下位ビットプレーン至るまで処理される。各ビットプレーン内のDWT係数ビットは、周辺係数ビットの状態に応じて、最大3つの符号化パスに分割される。各符号化パスは、Significance Propagation(SP), Magnitude Refinement(MR), Cleanup(CU)と呼ばれる。各係数ビットは、必ずこれらの符号化パスのいずれかに一度だけ属する。

各ビットプレーンのスキャンパターンを下図に示す。スキャンの際には係数ビットからなるstripeという単位が存在し、各stripe内は上から下へと順にスキャンされる。

EBCOTにおける係数ビットのスキャンパターン

最上位ビットプレーンをスキャンする際には、上位のビットプレーンに関する情報が得られないため、必ずCleanupパスとして処理される。最上位のすぐ次のビットプレーンからは、SP→MR→CUの順に属する符号化パスが決定される。

符号化パスの決定には、現在の係数ビットと、その周辺8近傍の係数ビットの状態が用いられる。係数ビットは"1"か"0"の値をとるが、それぞれ"有意"および"非有意"状態とみなされる。

SPパスは自身が非有意かつ周辺にすでに有意となった係数ビット存在する係数ビットが属する。このとき、現在の係数ビットは非有意から有意の状態へと更新される。

MRパスは、上位ビットプレーンですでに有意となっている係数ビットが属する。

CUパスは、SPパスにもMRパスにも属さない係数ビットが属する。

なお、それぞれの符号化パスは、さらにその周辺係数ビットの有意状態の情報に、コンテクスト(CX)と呼ばれるラベルが付けられる。規格で規定されたコンテクストの数は19である。

MQ符号化

[編集]
概要
[編集]

SP、MR、CUの各符号化パスに属する係数ビットは、そのコンテクストCXの値と共に2値算術符号化器であるMQ-coderへと送られ、算術符号化される。MQ-coderは、各コンテクストごとに独立した確率遷移テーブルを持つ。この確率遷移テーブルのエントリ数は46である。

MQ-coderは、係数ビットの正負を表す符号ビットと、値ビットから計算されるディシジョンビットDと、CXを入力として、出力ビットを計算する。符号ビットが入力されるのは、初めて有意となる係数ビットが符号化されるときに限られる。MQ-coder内には5つのレジスタが存在し、そのうちの出力ビットを蓄えているレジスタ上でバイト境界に達すると、バイトストリームとして1バイトが新たに出力される。この際、デコーダにとって重要なマーカとなるFF90h〜の値がバイトストリーム内に出現するのを回避するため、直前のバイト出力がFFhであった場合には、レジスタ内における次のバイト境界の先頭1ビットをスキップし、データを書き込まないようにする処理が追加される。これはビットスタッフィングと呼ばれる。

終端処理
[編集]

コードブロック内の全ての係数ビットを符号化した後でも、通常、MQ-coder内のレジスタにはバイト境界に満たない符号語が残っているため、終端処理によって全ての係数ビットをデコードするのに必要な長さの符号語を出力する。

符号化モード
[編集]

MQ-coderには、符号化モードとして、以下の6つのモードがオプションとして用意されている。

  • Selective arithmetic coding bypass:
    • 最上位から数えて5つ目のビットプレーン以降のSPおよびMRパスに属する係数ビットをRAWデータのまま符号語とするモード。CUパスは常に算術符号化される。
  • Reset context probabilities on coding pass boundaries
    • 各符号化パスの符号化開始時に各コンテクストごとの確率遷移テーブルを初期状態にリセットするモード。
  • Termination on each coding pass
    • 各符号化パスの符号化終了時に終端処理を呼び出すモード。
  • Vertically causal context
    • コンテクストの値を求める際のウインドウが、ひとつ下のstripeにまたがれないように制約を与えるモード。
  • Predictable termination
    • 終端処理を規定された方法で行うモード。
  • Segmentation symbol
    • エラー耐性機能のために、CUパス符号化終了時に特別なシンボルを挿入し符号語に加えるモード。

レート制御(オプション)

[編集]
レート歪み最適化(Rate-Distortion Optimization)
[編集]

EBCOTでは、MQ符号化後のバイトストリームに対して、符号化パスを最小単位として符号切り捨てを行うことで圧縮後のレート歪最適化(PCRD-opt)を行うことが可能である。レート制御については、エンコーダにおける処理であるため規定された技術はないが、一般的に以下の処理によって実現されることが多い。

コードブロック内の切り捨て点として、符号化パスを考える。までのデータ量を、そのパスでバイトストリームを切り捨てることで増加する歪みの推定量をとおく。所望のビットレートをとして、の条件のもと、を最小化するを各コードブロックごとに決定する。この一連の手順はラグランジュの未定乗数法を用いることで実現できる。

レイヤ(Layer)生成
[編集]

また、上述のレート制御処理は、コードストリームのプログレッション順序の構成要素の一つであるレイヤを形成するためにも用いられる。レイヤとは、SNR(Signal-to-Noise Ratio, SNR)スケーラビリティを実現するための概念である。

レイヤを用いたSNRスケーラビリティとは。最上位レイヤから最下位レイヤにデコード処理が進むにしたがって、段階的にデコード画像の画質が向上する(SNRが向上する)機能を意味する。レート制御処理によって、各コードブロックの符号化パスがどの程度画質に寄与するかが予測できるため、この情報を用いてレイヤを生成する。具体的には、各コードブロックにおいて、どのレイヤに符号化パスがいくつ属するかをレート制御によって得られる情報をもとに決定する。このレイヤごとのパス数は、パケットヘッダ生成アルゴリズムによってパケットヘッダに記録される。

パケットヘッダ生成

[編集]

MQ-coderからの出力バイトストリームは、プリシンクトを単位とした「パケット」として整列される。各パケットには、パケットヘッダとして以下の情報が付加される。

  1. emptyパケットフラグ(1bit)
  2. レイヤ番号におけるコードブロックの包含情報
  3. ゼロビットプレーン数
  4. 符号化パス数
  5. バイトストリームの長さ

各パケットヘッダの先頭1bitは、そのパケットのデータが空である場合には0、それ以外には1となるフラグである。

2. 3.については、タグツリーと呼ばれるデータ構造によって符号化される。

生成されたパケットヘッダは、各パケットの先頭あるいは、メインヘッダ内、あるいはタイルパートヘッダ内のいずれか一つの場所に格納される。

パケット生成

[編集]

各パケットは、指定されたプログレッション順序に応じて並べ替えられる。指定可能なプログレッション順序は、

  • レイヤ、DWTレベル、色コンポーネント、プリシンクト(LRCP)
  • DWTレベル、レイヤ、色コンポーネント、プリシンクト(RLCP)
  • DWTレベル、プリシンクト、色コンポーネント、レイヤ(RPCL)
  • プリシンクト、色コンポーネント、DWTレベル、レイヤ(PCRL)
  • 色コンポーネント、プリシンクト、DWTレベル、レイヤ(CPRL)

の5つである。

動向

[編集]

デジタルシネマ[16]、公文書や芸術作品のアーカイブ[17]、医療用画像の圧縮[18]、業務用途の画像配信システム、監視カメラPDFファイル内の画像フォーマットなどでは既に広く使われている。高い圧縮効率や豊富な機能を備えていることから、発表当初はコンシューマ向け分野でも急激に普及することが期待されたが、JPEGと比較すると計算負荷が高くバッテリー消費が激しいことや、またスループットを稼げず連写速度の向上が難しいことから、デジタルカメラ用途での採用は進んでいない。

Part 15(High Throughput JPEG 2000)では、EBCOTの弱点であった計算負荷の高さとそれに起因する低スループットおよびバッテリー消費量の問題を解決するべく、新しいブロック符号化アルゴリズムが標準化された。若干の圧縮効率の低下と引き換えに、10倍以上のスループット向上が達成されている。また、決して並列化向きのアルゴリズムではなかったEBCOTとは異なり、GPUなどによる並列化を強く意識したアルゴリズムとなっており、並列化によるスループットのさらなる向上が期待できる。

対応ソフトウェア

[編集]

出典

[編集]
  1. ^ Taubman, David S. (2002). JPEG2000 : image compression fundamentals, standards, and practice. Marcellin, Michael W.. Boston: Kluwer Academic Publishers. ISBN 079237519X. OCLC 47737760. https://www.worldcat.org/oclc/47737760 
  2. ^ The JPEG 2000 suite. Schelkens, Peter., Skodras, Athanassios., Ebrahimi, Touradj.. Chichester, West Sussex, U.K.: J. Wiley. (2009). ISBN 9780470744635. OCLC 441886987. https://www.worldcat.org/oclc/441886987 
  3. ^ Taubman, D. (2000-7). “High performance scalable image compression with EBCOT”. IEEE Transactions on Image Processing 9 (7): 1158–1170. doi:10.1109/83.847830. http://ieeexplore.ieee.org/document/847830/. 
  4. ^ JPEG - JPEG 2000”. jpeg.org. 2019年8月12日閲覧。
  5. ^ T.803 : Information technology - JPEG 2000 image coding system: Conformance testing”. www.itu.int. 2019年9月6日閲覧。
  6. ^ T.804 : Information technology - JPEG 2000 image coding system: Reference software”. www.itu.int. 2019年9月6日閲覧。
  7. ^ T.805 : Information technology - JPEG 2000 image coding system: Compound image file format”. www.itu.int. 2019年9月6日閲覧。
  8. ^ T.807 : Information technology - JPEG 2000 image coding system: Secure JPEG 2000”. www.itu.int. 2019年9月6日閲覧。
  9. ^ T.808 : Information technology - JPEG 2000 image coding system: Interactivity tools, APIs and protocols”. www.itu.int. 2019年9月6日閲覧。
  10. ^ T.809 : Information technology - JPEG 2000 image coding system: Extensions for three-dimensional data”. www.itu.int. 2019年9月6日閲覧。
  11. ^ T.810 : Information technology - JPEG 2000 image coding system: Wireless”. www.itu.int. 2019年9月6日閲覧。
  12. ^ T.812 : Information technology - JPEG 2000 image coding system: An entry level JPEG 2000 encoder”. www.itu.int. 2019年9月6日閲覧。
  13. ^ T.813 : Information technology - JPEG 2000 image coding system: XML structural representation and reference”. www.itu.int. 2019年9月6日閲覧。
  14. ^ Kasner, J.H.; Marcellin, M.W.; Hunt, B.R. (Dec./1999). “Universal trellis coded quantization”. IEEE Transactions on Image Processing 8 (12): 1677–1687. doi:10.1109/83.806615. http://ieeexplore.ieee.org/document/806615/. 
  15. ^ Christopoulos, C.; Askelof, J.; Larsson, M. (2000-9). “Efficient methods for encoding regions of interest in the upcoming JPEG2000 still image coding standard”. IEEE Signal Processing Letters 7 (9): 247–249. doi:10.1109/97.863146. ISSN 1070-9908. http://ieeexplore.ieee.org/document/863146/. 
  16. ^ Digital Cinema Initiatives (DCI) - DIGITAL CINEMA SYSTEM SPECIFICATION, VERSION 1.2”. www.dcimovies.com. 2019年8月12日閲覧。
  17. ^ 国立公文書館 デジタルアーカイブ”. www.digital.archives.go.jp. 2019年8月12日時点のオリジナルよりアーカイブ。2019年8月12日閲覧。
  18. ^ 8.2.4 JPEG 2000 Image Compression”. dicom.nema.org. 2019年8月12日閲覧。
  19. ^ gdk-pixbuf - An image loading library”. 2014年7月16日閲覧。
  20. ^ Qt Image Formats | QtImageFormats 5.3 | Documentation | Qt Project”. 2014年7月16日閲覧。

外部リンク

[編集]