« (連載)第1回:色空間について | トップページ | (連載)第2.5回:JPEG progressive モード »

(連載)第2回: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演算、量子化、エントロピー圧縮についてはガッチリ決められていたものの、 実用で使うには曖昧な部分がある。
例えば『色空間』
「モノクロは“色成分=1個”という運用をする。」
「カラーは“色成分=3個、順に 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変換』⇒『量子化』⇒『ハフマン符合化(ジグザグスキャンを含む)』という4工程で作成される。
逆に JPEG ファイルを人が見て分かる画像データにするには『ハフマン復号化』⇒『逆量子化』⇒『逆DCT変換』⇒『逆サンプリング』と圧縮時とは逆の工程で行われる。
実は、可逆圧縮(圧縮してもデータが損なわれない)が保証されているのは4工程のうち『ハフマン符合化/復号化』だけである。

サンプリングは4:1:1の場合、Cb, Cr のデータ量を4分の1にする処理が行われる。
サンプリングでデータ量を落とさない場合は4:4:4である。
色空間をRGBからYCbCrに変換する場合に計算誤差(整数に丸める)が発生することがある。
DCT変換/逆DCT変換は、理論上は可逆であるが、FastDCT アルゴリズム (Arai, Agui, and Nakajima's algorithm for scaled DCT) を用いる場合などでは、±1程度(色深度0~255の内の±1程度)は許容範囲としているようだ。
実際の JPEG の使われ方では量子化でゴッソリ情報量を落とす。
だとすれば DCT での±1程度の誤差は許容されるのかもしれない。
色空間の変換計算誤差あり
サンプリングモノクロとカラーの4:4:4は可逆
それ以外は色差成分のデータ量が削減される
DCT変換計算誤差あり
量子化量子化テーブルの要素をすべて1にすれば可逆
普通は量子化でデータ量をごっそり削る
ジグザグスキャン可逆
ハフマン符合化可逆


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


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

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

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

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

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

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

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

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

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

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


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

このバラの写真は JFIF ソースの中にサンプル画像として含まれるもの。
テスト用画像(圧縮前)
テスト画像 BMP フォーマット
227x149ピクセル(24bit)

データ部は101,469byte

PhotoShopというツールでは JPEG 圧縮オプションでレベル12(最高画質)~レベル0(最低画質)を選択できる。
(次の絵は、上ほど綺麗で下ほど圧縮率が高い)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

開発者を悩ませる問題の1つに『マーカーの直前の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 ⇒・・・と時代を経るにしたがってグレーゾーンを減らす努力が行われているようだ。

(つづく)

|

« (連載)第1回:色空間について | トップページ | (連載)第2.5回:JPEG progressive モード »

画像フォーマット」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: (連載)第2回:JPEG(じぇいぺぐ):

« (連載)第1回:色空間について | トップページ | (連載)第2.5回:JPEG progressive モード »