(☆☆) ビぃーーームっ！

AviUtil Plug-In ... Unplugged






このページは IE 5.5 SP2 と Netscape 6.0 で表示を確認しています。
長いので分離しました。。。

非可逆圧縮について（技術的説明）

可逆圧縮と非可逆圧縮について

可逆圧縮(LossLess) というのはファイルを圧縮し、展開すると完全に元に戻る圧縮方法です。
zip や LHA などがその例です。

マルチメディア（画像や音声）では多少の劣化があっても良い場合が多いので、 非可逆圧縮(Lossy) が使われます。
（※ 医療用の画像など、可逆性が求められる場合もあります。）

【音声】
まずは【音声】から

音声ファイルといえば、圧縮されていないベタデータをWAVなんて言ったりしますが。
下左（↓）は、とあるWAVファイルの波形表示データです。
波形表示はイメージがつかみやすいと思いますが、 データを周波数分解したスペクトル表示の方が便利です。
下右（↓→）がスペクトル表示です。（横軸は時間、縦軸のメモリは周波数です。）
テストデータ（波形表示） テストデータ（スペクトル表示）
wav(圧縮前)の波形表示 wav(圧縮前)のスペクトル表示
L3Codec でmp3圧縮した結果
(128kbps)		 GoGoのコーダ でmp3圧縮した結果
(128kbps)
l3codecで圧縮結果（スペクトル表示） gogoのコーダで圧縮結果（スペクトル表示）

mp3エンコードは『人間の耳は高い周波数を聞き取る事ができない』という特性を利用し、 主に高周波をカットする事で高圧縮を実現しています。

上のデータはmp3では評価の高いL3Codecと、 そこそこの評価のGoGoのこ〜だの出力結果を比べたものです。
どちらのエンコーダが優れているかを判断する時は、右と左とを見比べたりしますが、
今は、元データとエンコード後のデータを比較してみてください。
ちなみに
同じ mp3 というフォーマットなのにエンコーダによって出力データの質が変わってしまうのは、 アルゴリズム（アルゴリズムの実現方法）が違うからです。
mp3 などのマルチメディア規格は“デーコードできればＯＫ”という規格の書き方をしています。
処理を高速化するためにアルゴリズムを取り換えたりするからです。

L3Codecは16KHz以上の高周波をキレイにカットしている事がわかります。
GoGoはその辺、チョット甘そうです。

ですが、問題なのは16KHz以下の低周波の部分です。
高周波の聞こえない部分がどうなっていようと、たいした問題じゃないんです。（少し乱暴(^^;;
低周波部分の色が白っぽい部分（音が強い部分）の形が違うのがわかりますか？
フィルターを掛けて減色処理した結果
比較用にフィルターを掛けてみました

ヒストグラム
実際に耳でこのデータを聞いてみると、このデータに関しては、L3Codec, GoGo の両方ともＮＧです。
ええ、たまたまそういうデータなんです。
そんなデータを選んで解析してみたんです。


普通のデータなら、L3Codec, GoGo とも、聞いてて気にならないぐらい良くできています。
なぜこのような事が起こるか？というと、mp3 の圧縮方式に秘密があります。
mp3 では mdct という方式で音データを周波数分解し、高周波部分などをカットしていますが、
高周波以外の部分もカットしてしまいます。
ビットレートを落とすと、重要な部分まで次々切り落とされてしまいます。

これがデータ劣化の理由です。
mp3エンコードではなく、TwinVQというエンコード方式を用いると、さらに高圧縮で劣化も少ない場合がありますが、
どの方式が流行るか？というのは方式の優劣だけではなく、その方式をサポートしているプレイヤーが多いとか、
エンコード方式を開発している側のリリース方式（マーケティング）の違いによっても影響されます。
mp3 に関しては一部のユーザー層に圧倒的に支持された、ってこともあるのでしょう。

【まとめ】
・mp3 エンコードは高周波部分をカットするだけではなく、低周波の一部をもカットしてしまう場合がある。
・データによっては、「低周波の一部をカットしてしまった」結果が、とても耳障[みみざわ]り
・カットされてしまったデータは元には戻らない。


【画像】
音はこのくらいにして、【画像】にしましょう。
昨年１２月頭（2001/12/03）に Irfan View32 が JPEG2000 に対応したので、それを記念して（って何が？
JPEG2000 にしましょう。（ぉぃ
テスト用画像
テスト画像

JPEG2000で
20分の1に圧縮した画像		 40分の1に圧縮した画像 60分の1に圧縮した画像 80分の1に圧縮した画像

下側の画像は、左から JPEG2000 方式で 20分の１に圧縮、、、、80分の１に圧縮してできた画像です。
正確には、現在のブラウザが JPEG2000 ファイル ( *.jp2 ) を表示できないっぽいので、
JPEG2000 → BMP →（可逆圧縮）→ PNG
としてあります。JPEG2000 デコード以降は、データの劣化が無いはずなので、画質としては JPEG2000 デコード結果と同じです。

※ついでに言うと、JPEG2000には非圧縮のオプションもあります。非圧縮はPNGよりも圧縮効率が良いです。JPEG2000がブラウザで正式サポートされるようになれば PNG は終わるでしょう。

JPEG2000 では、20分の1程度に圧縮しても画像にノイズらしきものは見えません。
すばらしいですネ！
ですが、圧縮率：40分の1ではノイズが出始め、（その影響で、顔の表情が微妙に違うのわかります？私は表情に影が出ているように感じるのですが）
※ JPEG2000 では DCT 変換ではなく Wavelet 変換というのを使うため
『ブロックノイズ』（四角い形）や『モスキートノイズ』（エッジがキツイ所にモヤモヤ）ではなく、
画面の一部にモワッとしたフィルターが掛かったようなノイズが出ます。
 60分の1では、顔の表情がゆがみ、
80分の1では、「キャー」

つまり、20分の1を目安に圧縮しましょう。
80分の1程度の圧縮は、一種のフィルターとして使うことは可能でしょうが、通常の使い方としては使えないでしょう。
で、20分の1ですから、JPEG では 10分の1が限界だっただけに、一気に『倍』です！
が、「たったの２倍かぃ」って気もします。

さて、話を元に戻して、
一般的に『画質』と『圧縮率（ビットレート）』はトレードオフの関係にあります。
『どこで妥協するか？』『どこまで妥協できるか？』はエンコードする人次第です。
画像であっても、音と同様に「人間が知覚しづらい高周波成分を除去する」事で高い圧縮率を実現しています。
ですから、「ここまでは許せる」「これ以上は我慢できない」という部分で境界線を引けば良いのです。
また、「人は風景よりも人の顔の表情に敏感」という事が言えるので、
顔の表情で妥協点が見つかれば、たいていは大丈夫です。

【まとめ】
・静止画も音と同様に、人間の目で知覚しづらいとされる高周波成分をカットすることで高圧縮を達成しようとする。
・圧縮率を高めると、人間の目で判る部分までカットされる。
・ノイズは圧縮アルゴリズムによって、エッジ部分に現れたり、平坦なグラデーション部分に現れたり、顔の表情に現れたり、まちまち。

【動画】
次に【動画】です。
動画についてはイロイロな人が解説しているのでサラッと(w。

実写は 100Kbps ぐらいにしても耐えられるのに、アニメは300Kbps ぐらいにしないと耐えられない。
なんて事があります。
これは静止画像の理屈と同じで、コーデックのクセによってノイズが目立ってしまう場合があるためです。

動画の場合は、これ以外に、
・シーンチェンジの所でノイズが気になる。
・人の口の動きと耳から聞こえている声がチョットでもズレていると違和感がある。
などがあります。
「シーンチェンジ」については動画のコーデックが「フレームの差分を取る方式」が一般的なため、シーンチェンジの部分で追いついてないのです。
声と口の動きの違和感は、人間の脳の構造が関係してるんだろうな、たぶん。

【まとめ】
・動画は音声データ圧縮の特徴と静止画圧縮の特徴を引き継ぐ
・音声データ部分は、音声データ単体の場合より、多少なら音質が劣っても耐えられる（特に視覚効果が高い画像部分は特に）
・画像データ部分は静止画像データよりかなり劣っても耐えられる。
・しかし、シーンチェンジの部分にノイズがあると目立つ。
・音声データと画像データにズレがある場合に違和感がある（特に実写の人の口の動きで）

----- 以下書きかけ。
【ビットレートとノイズの蓄積】
JPEG 画像のビットレートによる画質テスト
Quality 75
圧縮率：　1 / 15.40		 Quality 50
圧縮率：　1 / 22.18		 Quality 25
圧縮率：　1 / 32.61		 Quality 10
圧縮率：　1 / 51.82		 Quality 5
圧縮率：　1 / 72.82
JFIF のパブリックドメインソース(Independent JPEG Group のソース) Ver 6.0b を使用。
圧縮オプション：-quality Ｎ
伸長オプション：(デフォルト)
JFIFのソース
JPEG 規格をまとめているのは ISO という組織なのですが、
Independent JPEG Group という団体がパブリックドメインでフリーのソースを提供しています。
PhotoShop, IrfanView など、ほとんどの画像表示ソフトがこのソースを流用しています。
Mozilla (Netscape) にも含まれています。

動画のビットレートは、静止画像だと圧縮率に相当します。
上のような比較図（圧縮率を上げると画像は汚くなる）は見たことがあるでしょう。
圧縮率と引き換えに画像の質が悪くなっていきます。

プログラムを組んでいる側の人は「元データ」と「Codecで圧縮したデータ」をよく比較します。
その比較自体は重要なのですが、
それと同程度、いや、それ以上に重要なのは「それがあるべき姿との差異」です。

人間の脳の中にはイメージが作られていて、その頭の中で作られるイメージと、 感覚器から入ってくる入力信号によって作られるイメージとの間に差分が大きいと、 違和感を発する仕組みのようです。
たとえば、声。
Ａさんの声が、いきなりＢさんの声になると、違和感があります。
同じＡさんの声でも、目の前で喋っているＡさんの声を何かの装置を使って急に電話越しの声に切りかえると、 やっぱり違和感を生じます。
けれども、電話を使っている事を前提にしていれば、違和感としてではなく、「電話なんだから、こんな声」として認識されます。
S/N 比とかの数字だけではないのです。
ムズカシイですネ。

次に、再圧縮によるノイズの蓄積です。
一般に、一度圧縮した物を再度圧縮するとデータが劣化する、とされています。
同じ JPEG でやってみましょう。
同じ、JFIF のソースで、"-quality 75" というオプション（多くのアプリがデフォルト値とする画像品質）で圧縮しました。
１１回目までは微妙に劣化（バイナリレベルで違う程度(^^;）していきますが、
１１回目の結果を圧縮、伸長した１２回目の結果はバイナリレベルで１１回目の結果と一致しました。
この場合、この先１３回やっても１万回やっても結果は同じです。
ノイズの蓄積が収束する例です。
JPEG 画像の再圧縮によるノイズ蓄積テスト
1回圧縮した画像
(dct intオプション)		   10回圧縮した画像
(dct intオプション)		    
     
JFIF のパブリックドメインソース(Independent JPEG Group のソース) Ver 6.0b を使用。
圧縮オプション：-dct int -quality 75
伸長オプション：-dct int
1回圧縮した画像
(dct fastオプション)		 5回圧縮した画像
(dct fastオプション)		 10回圧縮した画像
(dct fastオプション)		 20回圧縮した画像
(dct fastオプション)		 50回圧縮した画像
(dct fastオプション)
JFIF のパブリックドメインソース(Independent JPEG Group のソース) Ver 6.0b を使用。
圧縮オプション：-dct fast -quality 75
伸長オプション：-dct fast

JFIF のソースには dct ルーチンが３種類含まれています。（インプリメントする人がそれを選択するのです）
float浮動小数点版
綺麗だが遅い
int
(デフォルト)		固定小数点版
高速で、そこそこ綺麗
fast上の固定小数点版をより高速にしたもの
若干、画質を犠牲にしている

そこで、"-dct fast" とオプションを変え、圧縮を繰り返してみました。
圧縮１０回目で認識できるほどノイズが蓄積し、２０回目で耐えられないほどに。
これはノイズが蓄積する（収束しない）例です。

じゃあ今度は、"-dct int" オプションに対するリベンジって事で（何が？
同じ "-dct int" オプションで、ノイズが収束しないように、 圧縮の度に画像を前後左右に１ビットずらしてみました。
すると、どうでしょう。見事にノイズが現れました（笑　　←　アホ。┐('〜`；)┌
JPEG 画像の再圧縮によるノイズ蓄積テスト

JPEG圧縮→伸長→右へ１ビットずらず→
JPEG圧縮→伸長→下へ１ビットずらず→
JPEG圧縮→伸長→左へ１ビットずらず→
JPEG圧縮→伸長→上へ１ビットずらず→・・・
とやってノイズを分散させた結果
10回圧縮した画像
(dct intオプション)		 20回圧縮した画像
(dct intオプション)		 30回圧縮した画像
(dct intオプション)		 40回圧縮した画像
(dct intオプション)
10回圧縮した画像
(dct floatオプション)		 20回圧縮した画像
(dct floatオプション)		 30回圧縮した画像
(dct floatオプション)		 40回圧縮した画像
(dct floatオプション)
JFIF のパブリックドメインソース(Independent JPEG Group のソース) Ver 6.0b を使用。
圧縮オプション：-dct int -quality 75
伸長オプション：-dct int

データを再圧縮すると、さらにデータが失われる。

動画像の場合は静止画像よりも大胆にデータを削るので、再圧縮によってノイズは加速的に蓄積されます。

一度失われたデータは再圧縮でも失われたまま。

フィルターなどを駆使してノイズを目立たなくする方法はありますが、基本的に失われたものは失われたまま帰ってきません。

コーデックによって、失われる部分は微妙に異なる。

同じ Codec であれば、どの類いの部分が失われるかは規則性があります。
けれども、「どのコーデックがどの部分のデータを…」なんて普通気にしませんよね。
だったら、せめて「複数種類のコーデックで再圧縮するのは避けるようにするのが良い」と思いませんか。

ファイルの結合では再圧縮しない場合もある

AviUtl であれば、
[ファイル] ⇒ [AVIファイル操作] ⇒ [AVIファイルの連結]
によって AVI をくっ付ける時、あの処理速度からすると、再圧縮しているとは思えません。
つなぎ目となるファイルのお尻や先頭は再圧縮している可能性があるのですが、全体に渡ってということは無いでしょう。
MPEG ファイルの GOP も、もともとオーサリング用に考えられた経緯があるので、 MPEG オーサリングソフトの中に再圧縮無しのファイル連結機能を持つものもあるでしょう。


AVI ファイルには 2GB の壁がある。

では非圧縮フォーマットならいいんでしょうか？
WAV ファイルの場合は、48KHzステレオで２時間分でも 2GB までは行きません。
48000 (Hz) * 2 [stereo=right+left] * 2 [=16bit=2byte] * 60 (秒) * 60 (分) * 2 (時間)
　= 1,382,400,000 byte
　≒ 1.3 GB
けれども、動画ファイルの Video 部分の場合は、非圧縮だとあっという間に 2GB を越えてしまいます。
AVI ファイルを幾つも串刺しにする事で解決しようとする人もいます。
DV デッキを使ってキャプチャ時の劣化を最小限にしようとする人もいます。

けれども「限られた資産でより良いものを」となると、知恵をしぼらねばなりません。

オチ、考え中。。。

オチ。見つからない。。。

このまま、オチ無いまま終了するのも手かな？

トップページに戻る
[PR]ﾍﾞﾋﾞｰ用品はたまひよ♪:子育てが楽しくなる便利ｱｲﾃﾑいっぱい