（連載）第２回：JPEG(じぇいぺぐ)

規格書は ISO/IEC 10918-1

ISO/IEC 10918
ISO (International Organization for Standardization)で規格書の PDF を販売しています。
こちらで "10918-1" を検索してください。
2006年10月現在、10918-1 は無料になったようです。(10819-2,3,4は有料)

CCITT(ITU) T.81 は ISO/IEC 10918-1 と同内容です。
こちらは www.w3.org から自由にダウンロードできます。→ itu-t81.pdf

特徴	・非可逆圧縮(圧縮前と完全に一致する訳ではない) ・自然画の圧縮に向いている。（逆にエッジの多いアニメには向いていない） ・圧縮時間と展開時間に大きな差がない 【長所】 ・圧縮率が高い(圧縮率を高くしても絵として成立する) ・圧縮／伸長の処理が割りと軽い ・自然画に関してはデファクト標準 ・特許問題が無い(と思われている) 【短所】 ・(実は)一度圧縮してみないとファイルサイズ(圧縮率)がわからない ・オーサリングに向いていない ・仕様にグレーゾーンが多い
関連規格	JFIF(じぇいふぃふ) ISO/IEC 10918 規格ではsampling方法、DCT演算、量子化、エントロピー圧縮についてはガッチリ決められていたものの、 実用で使うには曖昧な部分がある。 例えば『色空間』 「モノクロは“色成分＝１個”という運用をする。」 「カラーは“色成分＝３個、順に Y(輝度),Cb(色差),Cr(色差)”という運用をする。」 こう決めたのは JFIF である。 “4:4:4 や 4:1:1 を基本的な使い方とする”と決めたのも JFIF である。 規格として、JFIF は ISO/IEC 10918 を機能制限したサブセットとなっているが、 運用面を明確化した事により、世間一般では「JPEG ＝ JFIF」の図式が成り立っている。 すなわち、業界標準（デファクト・スタンダード）となっている。
	Exif(えぐじふ) JFIF とは独自に日本のカメラ団体が策定した規格。 ISO/IEC 10918 のサブセットであるが、JFIF のサブセットでは無い為、JFIF との互換性は保証され無い。 ※ Exif ファイルは JFIF ではほぼ間違いなく展開できるため、問題にはなっていない。
関連団体	Independent JPEG Group 「自分たちはJPEG規格とは直接関係ないんだ」という有志によって、JPEG 運用面の規格 JFIF が策定された。 彼らは同時に JFIF ソースコードを無償提供し始めた。 ※ 関連規格のJFIF参照 Windows の画像ツール、画像Viewer のほとんどは JFIF ソースを組み込んでいる。 ※ Adobe PhotoShop は JFIF をカスタマイズして使用。Internet Explorer や Mozilla も JFIF を使用。 こうして、世間一般で「JPEG と言えば JFIF のこと」という構図が作られた。 JFIF ソースコードの配布は 1998 年頃まで盛んに行われた。 ・1996/02/07 に Version 6a が配布された（baseline が完成） ・1998/03/27 に Version 6b が配布(progressive が追加された。また Unisys 問題により、GIF ファイルの read/write 部が削除された) この Version 6b を最後に開発が完了している。

■非可逆圧縮(圧縮前と完全に一致する訳ではない)
JPEG は『サンプリング（色空間の変換を含む）』⇒『DCT変換』⇒『量子化』⇒『ハフマン符合化（ジグザグスキャンを含む）』という４工程で作成される。
逆に JPEG ファイルを人が見て分かる画像データにするには『ハフマン復号化』⇒『逆量子化』⇒『逆DCT変換』⇒『逆サンプリング』と圧縮時とは逆の工程で行われる。
実は、可逆圧縮(圧縮してもデータが損なわれない)が保証されているのは４工程のうち『ハフマン符合化/復号化』だけである。

サンプリングは４：１：１の場合、Cb, Cr のデータ量を４分の１にする処理が行われる。
サンプリングでデータ量を落とさない場合は４：４：４である。
色空間をＲＧＢからＹＣｂＣｒに変換する場合に計算誤差（整数に丸める）が発生することがある。
DCT変換/逆DCT変換は、理論上は可逆であるが、FastDCT アルゴリズム (Arai, Agui, and Nakajima's algorithm for scaled DCT) を用いる場合などでは、±１程度（色深度０～２５５の内の±１程度）は許容範囲としているようだ。
実際の JPEG の使われ方では量子化でゴッソリ情報量を落とす。
だとすれば DCT での±１程度の誤差は許容されるのかもしれない。

色空間の変換	計算誤差あり
サンプリング	モノクロとカラーの4:4:4は可逆 それ以外は色差成分のデータ量が削減される
DCT変換	計算誤差あり
量子化	量子化テーブルの要素をすべて１にすれば可逆 普通は量子化でデータ量をごっそり削る
ジグザグスキャン	可逆
ハフマン符合化	可逆

色空間はカラー画像をYCbCrに変換して用いる。
4:1:1のサンプリングではCb,Crの2x2ピクセルを1ピクセルに間引く処理が行われる。

	4:4:4	4:1:1
Y
Cb
Cr

■自然画の圧縮に向いている。（逆にエッジの多いアニメには向いていない）
JPEG では８ｘ８ピクセルの格子状の単位で２次元の周波数分解を行い、高周波数成分を除去する事で高圧縮率を実現している。
自然画においてはたいていの場合、大きな変化(低周波数成分)が重要で、細かい変化(高周波数成分)は重要度が低い。

下記の２つの四角、色合いの違いを除いて、何が違うか見分けがつくだろうか？

実は、左側の四角は１ピクセル単位で黒と白を交互に並べている。 右側は灰色で全面を塗りつぶしただけである。
左は高周波数成分が極めて高い画像、右は高周波数成分が全く無い画像である。
自然画においては、このような細かい凸凹は見えなくても良い場合が多い。
人の顔のシワなんて見えなくったって大した問題はないのである。

■本当にアニメには向いていないのか？
アニメは自然画と違ってエッジの部分（すなわち高周波数成分）が重要な意味を持つ（らしい）

『サンプリング』『DCT変換』『量子化』『ハフマン符合化』のうち情報量をゴッソリ削るのは『量子化』工程のみです。
量子化テーブルの６４要素をすべて１にすれば、量子化でのデータ欠損は無くなります。
そうすれば、モスキートノイズやブロックノイズはもちろん発生しません。

量子化テーブルの要素をすべて１にする事は可能なのでしょうか？
JFIF 配布のソースでは可能です。(quality=100 にすれば良いだけ)
一般のエンコードソフトでは、量子化テーブルがオール１にはならない様に制限を掛けているようです。

圧縮前

圧縮後
低画質	←の拡大図	高画質

■圧縮時間と展開時間に大きな差がない
『DCT変換』と『逆DCT変換』はおおよそ同じ時間で処理できます。
『ハフマン符号化』と『ハフマン復号化』の時間もほぼ同じです。
１枚のJPEGを作る時の『DCT変換』の時間は画像サイズに比例します。
『ハフマン符号化』は出来上がった JPEG ファイルのサイズに比例します。
圧縮レートによって『ハフマン符号化』の時間は前後するわけです。

MPEG ではエンコード時の動き補償の計算に処理時間が掛かります。
綺麗な画を作ろうとすればするほどパターンマッチングの処理量が増加するためです。
MPEG ではエンコード処理とデコード処理には大きな差があります。

それに比べ JPEG はほぼ同じ。

サンプリングと逆サンプリング	ほぼ同じ メモリのreadとwriteの時間が大きく異なるシステムでは差が出る
DCT変換と逆DCT変換	ほぼ同じ DCT変換処理を何らかの手段で工夫している場合 (AC成分がすべてゼロの場合の最適化など)差が出る場合もある
量子化と逆量子化	量子化を除算命令で実現している場合は差が出る (普通CPUでは積算より除算が遅い) 逆数を掛ける実装になっていればほぼ同じ
ジグザグスキャンと逆ジグザグスキャン	ほぼ同じ
ハフマン符合化と復号化	ほぼ同じ アルゴリズムを工夫している場合は差が出る

■圧縮率が高い(圧縮率を高くしても絵として成立する)
JPEG は圧縮率を変えられる（データ量を加減できる）のが大きな特徴の１つだ。

このバラの写真は JFIF ソースの中にサンプル画像として含まれるもの。

テスト用画像（圧縮前）
	BMP フォーマット 227x149ピクセル(24bit) データ部は101,469byte

PhotoShopというツールでは JPEG 圧縮オプションでレベル１２（最高画質）～レベル０（最低画質）を選択できる。
（次の絵は、上ほど綺麗で下ほど圧縮率が高い）

あなたならどのレベルで妥協できるだろうか？

（圧縮後）圧縮レベルを変えて圧縮
Adobe PhotoShop 画像品質Level=12		21,345byte (圧縮率21% (≒ 1/5 ) )
Adobe PhotoShop 画像品質Level=11		15,065byte (圧縮率15%)
Adobe PhotoShop 画像品質Level=10		11,346byte (圧縮率11%)
Adobe PhotoShop 画像品質Level=9		9,304byte (圧縮率9.2%)
Adobe PhotoShop 画像品質Level=8 (最高品質 (低圧縮率) )		7,901byte (圧縮率7.8% (≒ 1/13 ) )
Adobe PhotoShop 画像品質Level=7		6,568byte (圧縮率6.5%)
Adobe PhotoShop 画像品質Level=6 (高画質)		6,046byte (圧縮率6.0% (≒ 1/17 ) )
Adobe PhotoShop 画像品質Level=5		5,438byte (圧縮率5.4%)
Adobe PhotoShop 画像品質Level=4		4,859byte (圧縮率4.8%)
Adobe PhotoShop 画像品質Level=3 (標準)		4,107byte (圧縮率4.0% (≒ 1/25 ) )
Adobe PhotoShop 画像品質Level=2		3,055byte (圧縮率3.0%)
Adobe PhotoShop 画像品質Level=1 (低画質 (高圧縮率) )		2,331byte (圧縮率2.3% (≒ 1/44 ) )
Adobe PhotoShop 画像品質Level=0		2,137byte (圧縮率2.1% (≒ 1/47 ) )

人によっては「最高画質でも妥協できない」だろうし、他の人では「標準以下でも耐えられる」だろう。

どの圧縮率が良いか？は『用途による』のである。

(注)上記の画像はJFIFのサンプルに含まれるものなので、圧縮に有利な画像（圧縮率を上げても絵として見えやすい画像）と思われます。
一般に、JPEG の圧縮率は『１０分の１程度が妥当』とされています。

■圧縮／伸長の処理が割りと軽い
JPEGは今ではWebでの標準画像フォーマットのように使われる。
パソコンのブラウザはもちろん、携帯でもJPEGは展開され表示されている。
パソコンの処理能力に比べ、携帯のLSI処理能力が著しく劣っていることをご存知だろうか？
ＰＣでは電源供給も十分行われ、ＣＰＵに馬鹿でかいヒートシンクを付ける事によってＣＰＵをぶん回す事が当たり前になっている。
今ではＣＰＵ周波数がギガは当たり前。
それに比べ、携帯はバッテリーで動作する。もちろん手で持てないほど熱くなってはダメ。
おのずと動作周波数が抑えられる。
携帯で Web を見ようと思うと、このような制限された環境で動作するスペックでなければならない。

もし仮に、Web で標準となっている画像フォーマットがとてつもない処理量を要求するものだったとしたら・・・
「ＰＣでは見ることができても、携帯では見ることができない。」
そのような状況を一般消費者は受け入れられるのだろうか？
それとも携帯に専用LSIを組み込み「携帯利用料金が月５００円アップし、携帯端末の重量が３グラム増え、バッテリーの持ちが悪くなったら」 それを消費者が受け入れるのだろうか？

『画像フォーマットが普及するかどうか』は『一般消費者がそれを受け入れるかどうか』という判断が左右する。

今の携帯にJPEGデコード専用のLSIなんか入っていない。
ソフトデコードで十分なのだ。
JPEGのデコード処理は携帯のCPUで処理できるほど軽い。

■自然画に関してはデファクト標準
デジカメでは JPEG が標準的に使われる。
例外は一部のハイエンド機(HDD内蔵タイプが多い)で非圧縮データを用いるぐらいである。

JPEGでは伸長(＝展開)の処理量と圧縮の処理量はほぼ同じ。
処理量は画像サイズに比例すると考えて良い。
しかし Web で使われる画素数とは桁違いの画素数がデジカメには求められる。
デジカメでは、今やメガピクセルは当たり前。 その内、ギガピクセルになるかもしれない。
（CCDの集積化やメモリの速度がファクターになる）

ギガピクセルの後はテラピクセルまで行くだろうか？
そこまでの情報は必要なのだろうか？

（話がそれてしまったが）
デジカメでは専用のJPEGエンコードLSIを内蔵している。
画素数が増えてしまうと、さすがにソフト処理という訳にはいかない。
一度、標準的なハードが確立してしまうと、容易にはくつがえらない。

■特許問題が無い(と思われている)
世間一般のほとんどの人は「JPEGに特許問題がある」なんて思っちゃいない。
一部のコアな人は「特許問題があった」事を知っている。
ネット検索で“JPEG”と“特許”をキーワードにすれば、有名なJPEG特許問題１件が出てきます。

しかし実情は「１件どころではない」。

JPEGに関するサブマリン特許は何件もあり、セットメーカー(デジカメやプリンタ)が標的にされている。
彼らのやり口はこうだ。
まず特許を登録しておく。
しばらくは黙って標的を絞る。
標的が決まると個別にセットメーカーを訪問し「あんたのところの製品、うちの特許に抵触してるんですが、特許料払ってくれません？」と言い寄るのである。
単なる“言いがかり”の場合もあるし、“後々、特許無効”と判断される場合もある。
しかし「金で解決するなら・・・」と特許内容を吟味せずに示談に応じるメーカーも多い。
このようにして示談に応じたメーカーから数億（時には百億以上）の金が流れることになる。
このような特許料はデジカメやプリンタの代金に上乗せされて一般消費者がかぶっているのだ。（もちろん、企業努力によって企業がかぶっている場合もある）

報道にすっぱ抜かれて、無効判決を受けた JPEG 特許の例や、一般消費者をターゲットにしてしまった GIF の Unisys の例は、 “当たり屋”としては素人なのです。
裏道には玄人が行脚しているのです。

（ちょっと生なましい話になってしまいましたね。技術的な論点に戻しましょう。）

■(実は)一度圧縮してみないとファイルサイズ(圧縮率)がわからない
JPEG では量子化テーブルを決めた後に圧縮を開始し、１枚の画像圧縮が終わるまで同じ量子化テーブルが使われる。
途中で量子化テーブルを変える事はできない。

圧縮対象の画像データによって圧縮率は変化する。
たとえば高周波数成分を全く含まない真っ白な画面は極めて圧縮率が高くなる。

そのため、圧縮 JPEG ファイルのサイズを一定サイズにする事は難しい。

もしやろうとすると、
『一度圧縮しサイズを見る』⇒『量子化テーブルを変えて再圧縮』
なんて処理を２，３回繰り返して理想サイズに近づけるぐらいしか手がない。

■オーサリングに向いていない
最近はダイレクトプリンタなんていうデジタルカメラのメモリカードを直接（ＰＣ無しで）印刷できるものが出てきている。
これらのプリンタにはLSIが内蔵され、デコードしながら印刷をしているのである。
ソフト処理をしている場合もあるし、専用のハードを載せている場合もある。

ところで、JPEG ファイルは MCU という単位で左から右へとデータが収められている。
4:4:4 の場合には８ライン単位で、4:1:1 の場合は１６ライン単位でデータが格納されているのだ。

プリンタで画像ファイルを印刷する場合、この並び通りに印刷できれば良いのだが、 縦方向の印刷並びが必要になる場合もある。
画像を９０°回転させて印刷する場合があるのである。
プリンタの機種によってはクリッピングといって、画像の一部だけを切り取って印刷する事も可能だ。

印刷する JPEG 画像ファイルをいったんメモリにデコードしてしまえば印刷並びの問題など関係無いのだが、 ３００万画素の場合はデコードすると９メガバイト近くになってしまう。
普通、プリンタにはそんなに多くのメモリは載せない。（パソコンとはメモリ量の単位が違う）
プリンタでは、印刷ヘッドが動く時間よりも早くデコードが出来ていればよく、 そうなると「少ないメモリで頑張れ！」という理屈が通ってしまう。
少しでも原価を抑えることが企業努力とされる。

JPEG ファイル中で印刷しようとするMCUの位置は JPEG ファイルの先頭からシーケンシャルになぞっていくしかない。
JPEG ファイルにはリスターとマーカー ( RSTn ) が用いられる場合もあるが、サーチ処理がほんの少し楽になる程度である。
JPEG ファイル内をサーチする、すなわちオーサリングには向いていないのである。

■仕様にグレーゾーンが多い
エンドユーザー（一般消費者）にとってはほとんど関係無い事なのだが、開発者にとっては仕様の曖昧さ（グレーゾーン）は大きな問題だ。

JPEG は 1991 年という古い時代に研究者たちが集まって成立した規格であるため、 仕様がフレキシブルである反面、仕様が曖昧だ、という部分がある。
たとえば色空間が定義されていない、なんてのは最たるものである。
色空間については JFIF が「YCbCr を使う」と決めてそれがデファクトとなったが、 本来なら仕様で決めるべき内容である。
JFIF が手をつけなかった曖昧な部分に『マーカーが重複した場合どうするか』『必要なマーカーが含まれていない場合の処理はどうするか』 などがある。
componet_id なんてのは固定で決めてしまっても実用面でなんら不自由は無いし、マーカーの出現順番だって固定してしまっても大きな問題は無い。

開発者を悩ませる問題の１つに『マーカーの直前の0xFF』がある。
JPEG 規格ではマーカーの手前に複数個の 0xFF を置くことを許可している。
この 0xFF は単なるゴミ・バイトである。（データとしての意味は持たない）
マーカーセグメントとマーカーセグメントの間の不要な 0xFF であれば、無視するだけで済むのだが、 マーカーには RSTn (リスタート・マーカー) や EOI (エンド・オブ・イメージ)もある。
圧縮データ中の 0xFF は 0xFF 0x00 で置き換える事が仕様で決まっているため、ゴミの 0xFF は厄介な問題だ。
JPEG の仕様で「JPEG ファイル中に不要なゴミデータは認めない」と決めてしまえばスッキリするのであるが、 曖昧な仕様がそのまま残ってしまうと、開発者を悩ませる事になってしまう。

JFIF が作り出したグレーゾーンもある。
JPEG 規格では JPEG ファイルの最後に EOI の 0xFF 0xD9 が存在しないといけない事になっている。
JFIF では EOI が無い JPEG ファイルも許可している。
通信が発達していなかった昔は JPEG ファイルが途中で切れる場合もあった。
JPEG ファイルが途中で切れている場合、エラーとして全く表示しないのが良いのか、データがある分だけ表示した方が良いのか。
JFIF は「途中まででも表示した方が良い」と考えたのかもしれない。
このようにデファクトによって作られたグレーゾーンも存在する。

ちなみに ISO の規格は MPEG1 ⇒ MPEG2 ⇒・・・と時代を経るにしたがってグレーゾーンを減らす努力が行われているようだ。

（つづく）