このページは、IO-DATA 製 DV キャプチャカード(決して DV 編集カードではない)に付属の Panasonic DV Codec の画質のすばらしさに感激した1ユーザが、思いあまって作製したものであり、IO-DATA および 松下電器産業 とは無関係なページです。
サポートソフトウェア 2.00 に付属のコーデック (Ver. 2.46) では今までの問題点は解決しているので、このページは消そうかと思ったのですが、まだサポートソフトウェアの更新をしていない方がいるとしたら、更新することでどのような画質の変化が得られるかを示すために、Ver. 2.46 での実験結果を加えて残しておきます。
下の表は、それぞれ Panasonic DV Codec のバージョンを変更して画質がどう変化してきたか調べたものです。
サンプル画像の為替情報は NEC GCT-500 から Panasonic NV-DM1 (3DNR - OFF, 3DYCS - ON) の外部入力に入れたデータを GV-DVC を使用して直接取りこみ、そのままデコードしたもので、グラデーションは Y = 0 〜 255 の横方向グラデーションをビットマップファイルで作製し、9回再圧縮したものです。(再圧縮を繰り返す事で CODEC の問題を洗い出す事ができます)
Ver. | 画像 | ヒストグラム |
2.42 | ||
輝度情報が減っていく〜 |
||
2.43 | ||
どっか変わった? |
||
2.44 | ||
げ、色まで変わるようになってる |
||
2.45 | がーん!! Raptor 方式 |
|
色の変化がもっと酷くなってる〜 |
||
2.46 ON |
うん、確かにストレートで変換してる |
|
やっと直ってくれた(喜) |
||
2.46 OFF |
うん、再マップしてるね |
|
これぐらいなら、許容範囲 |
上の表のグラデーションは、9 回再圧縮を繰り返したものですが、オリジナルは下の画像です。
画像 | ヒストグラム |
Version 2.42 の Panasonic DV Codec (以下 Codec) での問題点は、再圧縮を繰り返した場合輝度情報がどんどん失われていくことです。
上の「今までの画質」で掲載している Y のグラデーションを9回再圧縮した場合のヒストグラムから判るように、オリジナルでは 0 〜 255 のグラデーションであったのが、9 回の再圧縮の後では 32 〜 198 のグラデーションになってしまっています。
これは Codec の圧縮エンジン側での YUV 変換の問題の為です。為替情報のサンプル画像のヒストグラムから判断できるように、このバージョンの Codec では DV の ITU-R BT.601 形式の輝度データを PC のモニタ上で正しく表示できるように再マップしています。
この際、素直な変換式を使用している場合は Y = (Y'-16) * 255 / 219 で計算しているはずですが、ひょっとしたら別の式を使って、一気に YUV から RGB に変換している可能性もあります。
どちらにせよ、圧縮時には展開時と逆の変換を行い ITU-R BT.601 形式の輝度データに戻す必要があるのですが、ここの変換式で間違えている為に、再圧縮の繰り返しで情報が失われているのです。
再圧縮を繰り返すと、輝度データの範囲が狭まっていくことから、
Ver. 2.43 は 2.42 とさほど変化がないように見えます。問題点も何一つ解決していません。
Ver. 2.44 は、輝度の変換に単純な式を使用するのではなく、補完を使うようになった為か、輝度の段差は目立たなくなりました。しかし、相変わらず輝度データが失われていくのは直っていません。
また、何故か色が多少変化する(緑っぽくなる)新たな問題が発生しています。ひょっとしたら今までは ITU-R BT.601 形式の UV(色差)データをストレートに(16 〜 240 のまま)表示していたのを、今回から(0 〜 255 に)再マップして表示するように変更したのかもしれません。
Ver. 2.45 では今までと処理方式をがらりと変えて、ITU-R BT.601 形式から輝度データを再マップするのを止めています。
この為、圧縮時と展開時の変換方式の食い違いが無くなり、結果として輝度情報は保持されるようになりました。しかし、この結果 PC のモニタと TV での表示に食い違いがでるようになってしまいました。
また、圧縮時に UV データを再マップするのを止めるのを忘れているのでしょうか、再圧縮を繰り返すと色がどんどん緑の方向へずれていってしまいます。
Ver. 2.46 で、今まで上げてきた問題点はほぼ解決されています。
まず、2.45 で凶悪なまでに(再圧縮1回でも気がつく)出現していた色の変化は 2.46 ではまったく現れません。さらに、CCIR 601 準拠の色変換を行うというオプション欄が Codec の設定画面に加わり、YUV データをストレートに RGB 変換するか、PC ディスプレイ用に再マップして RGB 変換するかをユーザが選択できるようになっています。これを OFF にした状態で再圧縮を繰り返しても、Ver. 2.44 以前の Codec のように輝度データがどんどん失われていくことはありません。
もちろん重箱の隅を突つこうと思えばいくつか怪しい点は指摘できますが、通常の DV 編集で行われると思われる 1 〜 3 回程度の再圧縮で判別できてしまうような問題はありません。Ver. 2.46 であれば、使えるコーデックとなっています。
まず、正しい(と私が考える)処理方式を書いておきます。
1 に関しては 2.45 の Codec から色関係の不具合を除けば簡単に実現できるはずです。2 も 2.44 以前の Codec で圧縮時の変換式を適切なものに直せば実現できます。3 の実装は 1 と 2 が実現できれば簡単でしょう。
私の期待していることは「規格通り厳密に処理すること」「再圧縮の繰り返しでぼろを出さないこと(規格に厳密であれば出ないはず)」の2点だけで、速度については遅くても構わないと考えているのですが、IO-DATA と松下電器にこれを期待するのは過ぎた望みなのかもしれません。
2.46 の Codec で「再圧縮の繰り返しでぼろを出さないこと」を確認することができました。どうやら、IO-DATA はサポートソフトの更新をしっかりやるという点では信頼できる企業のようです。(直るまでにかなり時間がかかっていますが、それは共同開発に伴う連絡の困難さからきたものでしょう。納得できます)
ITU-R BT.601 形式の YUV データを PC のモニタ用に再マップすると白飛び・黒つぶれの原因になるとの意見がありますが、正しく調整された TV では、Y = 16 以下の値は全て黒く表示され(DV 雑誌などのカラーバーでの調整方法を参照) Y = 235 以上のデータは全て白く表示されてしまうのですから、再マップが白飛び・黒つぶれの原因となるというのは少し的外れな指摘のように思います。
もしも、白飛びや黒つぶれが発生しているとしたら、再マップの際の変換式が間違っている(Y だけ再マップしていて UV はそのまま表示しているとか、変換式自体が間違っているとか)のを疑うべきだと考えます。
ITU-R BT.601 形式の YUV データのまま RGB 変換を行う事に利点があるとしたら、画像編集時に余計な処理が入らなくなるので画質の変化を最小限に押さえることができることと、カラーバーの作成時に -5%(TV の輝度調整時に 0% と違いが見えないようにする)部分を作成できる事ぐらいだと考えます。
この二つは DV データを PC に取りこみ、編集を行って、DV デッキに書き戻す「DV 編集ボード」では必須の機能だと思いますが、少なくとも「DV キャプチャボード」には不要な機能ではないかと思います。
画像 | ヒストグラム |
2.46(ON)と比べても勝ってる |
内容は、Panasonic DV Codec と同じです。