はじめまして。
　PCにキャプチャしたDV映像の画質について質問させて頂きます。

　私は最近DVカメラによる水中映像を始めまして、その編集用に下記システムをそろえました。
　で、気付いたのですが、一旦キャプチャしてDVに書き戻した映像では、元の映像ではそれなりに綺麗に撮れている水中の海水の微妙なコントラスト（明暗？）が、潰れてしまって色（明暗？）の境目がくっきり出てしまいます。それも綺麗なラインでは無くガタガタしたラインになります。
　　水中に人が漂うシーンや、水面を見上げて魚を撮ったシーンなどでは、人や魚の色合いや模様などにキャプチャ前と変化は見られない（気付かない？）のに、バックの海水の色だけ上記のような症状が見られます。

　これは、キャプチャ時の画像圧縮の影響（例えば、コントラストの少ない領域は圧縮率が上がる等）によるもので、避けられないものなんでしょうか？

　理由、対処法を御存じの方がいらっしゃいましたら、御教授願えませんでしょうか。
　よろしくお願いします。

【システム】
パソコン：440BXチップセット、RIVA TNT、
　　　　　celeron 366、メモリ　64MB、HD　約５G
キャプチャカード ： IO-DATA GV-DVC/PCI
DVカメラ： Panasonic DJ-100

PC上で再圧縮するとブロックノイズがでてくる可能性があります。

1.ブロックノイズについて
DV，JPEG，MPEGでは，画像データを8*8ピクセルに区切り，DCT変換して得た数値を丸めることで大きな圧縮率を実現しています。このため，圧縮率を高くしたり，比較的均一に近い色合いの画面では，8*8ピクセル区切りのブロックノイズがあらわれます。
DVは1:5と低圧縮率ですが，やはり一面が均一に近い色合いは，そもそも苦手です。

2.色空間の特性について
DVカメラでは，CCDからスキャンしたRGBデータを，輝度，色差に分けて記録しています。輝度は，人間の目の特性に基づいて，0.299R+0.587G+0.114Bの比率で計算されます。返せば，青色と明るさの結びつきが弱いことになります。
このため，空や海のような青一色の映像では，隣接ピクセルとの色差が小さい上に，輝度の差も小さくなりやすいので，DV圧縮時に数値が丸められてブロックノイズに結びつき易くなります。

対処方法としては，次の二通りがあると思います。
1.該当シーンを編集に使わない。具体的には，キャプチャしたファイルのまま保存しておき，出力時に手動で編集したビデオファイルとつなぎ合わせて出力する。
2.該当シーンにコントラストを強くするフィルタをかけ，意図的に輝度を強調してブロックノイズを避ける。

これは、DVカメラで録画したものを一旦PCにキャプチャ
し、一切変更しない状態で再びDVテープに書き戻しただ
けで、ブロックノイズが増えるということでしょうか?
たしかに、やすたかさんがかかれていることは間違って
はいないのですが、しかし、全く編集しない状態であれ
ば同じデータをPCに読み込み、再度エンコードするだけ
でブロックノイズが増えるというのは「異常」だと思い
ます。
もちろん、一旦RGBに変換し、それを再びDVエンコード
する段階で丸め誤差等は生じる可能性があるわけですが、
画像に加工を加えない、すなわち画像の空間周波数が変
化しない状態であれば、目で見て明らかにわかるほどの
ノイズ増加するというのは、おかしいと思います。
下の方でもちょっと書きましたが、アイオーのコーデッ
クは、0-100IREをRGB0-255にマッピングしているため
に、PCに読み込んでRGB変換した段階ですでにデータが
欠落します。これは、DVへの書き戻し編集には向かな
いコーデックなのではないかと思います。

＞ PCにキャプチャしたDV映像の画質について

何やら誤解も有りそうなので、少しだけ。

iLINK経由でＰＣに取り込んだＤＶデータは、原則テープ上の
録画データと同じです。＜AVIの形にファイル化したダケ！

＃「キャプチャ時の画像圧縮の影響」は、存在しません

これをＰＣ上で観る場合に変だとしたら
　　・使用するソフトのプレビューの品質or設定が悪い
　　・キャプチャカード附属のソフトDVcodecの品質が悪い
　　・まさか、色数を落としたＰＣで見てませんよね？
→ＤＶテープに書き戻してＴＶで観れば、変化ないハズです

＃更に、カット編集するダケなら、スマートレンダリングが
＃働いている前提で、品質は変化しません！＜MSP5.2VE

これが、ワタシの勘違いで
特殊効果や、トランジションを掛けた部分が変化するという
お話でしたら、やすたか さんの御指摘通りです。

「映像とＤＶ圧縮の相性」か「codecの品質が悪い」または
「エフェクトを繰り返し掛け過ぎ」が原因でしょう。


また、完パケを他のフォーマットにトランスコードした際に
おかしいとのコトでしたら、使用するソフトの品質か設定を
疑った方が良いデス。例えば
　　・MSPの縮小、デインターレースの品質は、今一つ
　　・GV-DVC/PCIに附属のDVcodecは「個性的？」らしい

Y.Masuyamaさん＞
フォローありがとうです。m(_ _)m

ponyonさん＞
PinnacleやDPSあたりも，0-100RLE(7.5-100?)を0-255RGBにマッピングしているようです。
RCAコンポジットやS端子しかついていないDVカメラで，0-100IREに入りきらない映像があるのも変ですね。
テレビで赤が滲んだり，青がボケたり，明るいところが歪んだりしても，「撮り方が悪い」で片づけるつもりなんでしょうかね？＜カメラメーカー
カノープスは随分広い範囲でIREをマッピングしているみたいですが・・・・編集屋さんに怒られてしまう映像になりそうですね。

>RCAコンポジットやS端子しかついていないDVカメラで，0-100IREに入りきらない映像があるのも変ですね。

アナログ入力でNHKのカラーバーをDVに録画してみるとほぼ
ITU-R601の規格であるY(0IRE)=16、Y(100IRE)=235に近い
値になっていました。（DVRaptor codec)
ところが、そのNHKの実際の番組でY=255に達することが有ります。
カメラにはゲインコントロールが付いているはずですが、
放送局のカメラでこの結果からすると、DVカメラのゲイン
コントロールも平気で100IREを超える信号を出しそうですね。

ちなみにYだけでなくCbCrも規格上は16〜240と決まってい
ますけど、IO-DATAのcodecはYのマッピングからして、
CbCrも16〜240を0〜255にマッピングするようなRGB変換を
しているのではないかと思います。
Yが235の規格を超えるようであれば、CbCrもこの0〜240の
範囲を超えるのでIO-DATAのcodecではCbがほとんど飽和に
近い水中の青などは再レンダリングで簡単に飽和して
グラデーションが消えてしまう気がします。

話からするとIO-DATAのcodecで再レンダリングしてDVに
書き戻してしまった結果のような気がしますね。

＞カノープスは随分広い範囲でIREをマッピングしているみたいですが・・・・編集屋さんに怒られてしまう映像になりそうですね。

canopusのcodecはITU-R601の規格に乗っ取ったDVのデータを
そのままの状態でRGB変換しているだけで、これを再レンダリング
した際には元信号がそのまま保存されているはずです。
（圧縮時の演算誤差以外は）
問題になるのはPCでBMPを作製してそれを編集に用いると
0IRE〜100IREの外にマッピングされる可能性があることですね。
私はRaptorVodeoの切り貼りの編集しかしていないので
実際エフェクトをかけたときにそうなるのかは未確認です。(^_^;

それにしても安価で人気のGV-DVC/PCIですが、結構罪作り
のような気が・・・。

ちょこっと訂正。

＞Yが235の規格を超えるようであれば、CbCrもこの0〜240の
＞範囲を超えるので

「Yが235の規格を超えるようであれば、CbCrもこの16〜240の
範囲を超えるので」

です。

それと解決方法を書くのを忘れました。
原因がPCで再レンダリングしたことであれば、GV-DVC/PCI
を使う限り再レンダリングをしないこと以外ありません。
（エフェクト等をかけないでカット編集だけにする）
PCでデコードした時点で青のグラデーションが潰れていると
思います。

やすたかさんの

＞2.該当シーンにコントラストを強くするフィルタをかけ，意図的に輝度を強調してブロックノイズを避ける。

では駄目です。

この問題が発生しないのはcanopusのDVRaptorなどです。

フォローして頂いた方々どうも有難うございました。

昨日、ふとGV-DVC/PCIには２つのDV CODECがあると言う事に思い当りました。
panasonic DV CODEC とpanasonic & I-O Data DV GigaAVI CODEC です。

前者はファイルサイズ２G未満の制約がある、普通の（？）AVIファイルを作成します。
後者はPana.&I-O.独自のファイルサイズに制限を持たない、GIGA AVI（参照AVI）ファイルを作成します。

そこで以下の試みを行いました。

「ケース１」
　元AVIファイル（キャプチャしたファイル）をそのままDVカメラに書き戻す。
「ケース2」
　元ファイルをMSPに読み込み、panasonic DV CODEC でAVIファイルを作成し、書き戻す。（無編集）
「ケース3」
　元ファイルをMSPに読み込み、panasonic & I-O Data DV GigaAVI CODEC で参照AVIファイルを作成し、書き戻す。（無編集）

【結果】
　ケース１（元AVIファイル）とケース２（DV CODEC、AVIファイル）では、私が指摘した現象は生じませんでした。
　ケース３（DV GigaAVI CODEC、参照AVIファイル）では、やはり私が指摘した現象が生じました。

　ちなみに、AVIファイルのファイルサイズを比較すると
「ケース１（元AVIファイル）」
　　　 ＝「ケース２（DV CODEC、AVIファイル）」
　　　 >> 「ケース3（DV GigaAVI CODEC、参照AVIファイル）」
　です。
　詳しい値は忘れてしまいましたが、参照AVIファイルは、それ自体のファイルサイズは元ファイルと比較して、かなり小さくなる様です。

　詳しい理屈等はまだ判りませんが、「panasonic & I-O Data DV GigaAVI CODECで作成した参照AVIファイル」というのがミソなのかなぁと言う気がしています。

> 、「panasonic & I-O Data DV GigaAVI CODECで作
> 成した参照AVIファイル」というのがミソなのかなぁと
> 言う気がしています。
これは違います。
発生する原因は、ケース3の場合だけはMSPで「再レンダ
リング」が行われるためです。ケース1と2では、MSP上で
再レンダリングが行われないため、YCrCbとRGBの相互変換
が発生せず、問題が出ないのです。

私もアイオーのカードを使ったことはあるのですが、結局
のところ結論は、GV-DVC/PCIに付属のDVコーデックは、
まったく使い物にならない、ということだと思います。
今後もDVテープへの書き戻しを伴う編集を行うつもりな
のならば、早ういちにGV-DVC/PCIに見切りをつけて、
DVRaptorあたりに買い替えるのが得策だと思いますね。

それから、matsuさんもかかれているとおり、100IREを
越えるような信号レベルは、世の中普通に使われていま
す。たとえばTV放送では、NHKでさえ110IRE程度は平気
で送出していますし、ビデオカメラでもあたりまえの様
に出てきますから。

> これは違います。


　「ケース２」でも再レンダリングが必要となる様な編集を行なえば、例の現象が現れるはずだと言う事でしょうか？

　また機を見て試して見る事にします。

>「ケース２」でも再レンダリングが必要となる様な編集を行なえば、例の現象が現れるはずだと言う事でしょうか？
みなさんの話があたりなら、「ケース2」でテロップを入れただけでも、逆にケースにはありませんが、参照ＡＶＩで
取り込んで通常ＡＶＩに変換をしても、再レンダリングされますからその現象は発生します。

もしかして音声を貼り付けるだけでもなるかもしれませんネ。

参照AVIでしか確かめてませんけど、音編集だけの場合はさすがに大丈夫でしたよ(^^;＞劣化

　予想された結果ですが、
　AVIで取り込んで、エフェクトをかけて、AVIで書き戻したら、やはり例の現象が再現しました。
　御指摘頂いたとおり、YCrCbとRGBの相互変換の問題だったのですね。
　良い勉強になりました。

　ところでDVコーデックがハードに依存せず完全にソフトで行われるなら、DVコーデックのみの移植や、アップグレードなんかはそれほど難しい事では無い様な気がしますが.....どうなんでしょう？。
　もし、そうならI-O DATAさん、アップグレードしてくれないだろうか...。

　まあ、私の場合はそれほどエフェクトに凝ろうとは思っていないので、安価なGV-DVC/PCIでほぼ満足しています。

GV-DVC/PCIのコーデックは、I-O/Panasonicの共同開発
ということです。特に確認したわけではない、私の想像
なんですが、おそらくDVのエンコード/デコード部分は
Panasonicが開発したもので、それを参照AVI化する部分
は、I-Oが開発したものなのではないでしょうか。
どうもコーデック名を見るとそう思えてなりません。
この想像が正しければ、修正するべきはPanasonicの側
ということになるのかもしれません。

ところで、困ったことにWindows98/SEやWindows2000に
含まれているはずのDVコーデックも松下製だそうです。
もしそれらも同じ仕様であるなら、Windows98/SE
やWindows2000でIEEE1394経由でDV編集が「標準」で
できるようになったとしても、同様の問題が発生する
恐れがありますね。

単なる杞憂であればよいのですが。

今更・・・ですが，カノープスサイトのFAQに以下の記載がありました。

「YUV<->RGB変換を150%でクリップする」にどんな効果があるのでしょうか？」
http://www.canopus.co.jp/tech/faq/faq000123.htm

上記のFAQですが、canopusのcodecでもRGB変換でクリップが
起こるという意味に取れますね。その場合に「YUV<->RGB変換
を150%でクリップする」を有効にしろと。

計算してみるとCbCrは基準レベルに対し113%までクリップ
しませんが、Yは109%でクリップするようです。
この差でRed単色、Blue単色などでCbCrがクリップしていない
場合でもPCでRGB変換するとクリップする現象が起こりそうです。

110%前後の輝度あるいは色差信号の話なので、滅多に起こる
ことではないと思いますが、こんなところまで考えている
canopusって偉いですねぇ。
（canopusの回し者ではありません。）

トップページ