MacDTV 情報ひろばトップページ 　＞＞　 MacDTV研究室 　＞＞　ビデオの色

「DTVでの色の問題」の歴史を振り返りながら、技術背景にふれてゆきます。

「DTVでの色の問題」の歴史

ITU-R601

「NTSC信号」と、デジタルビデオの色空間である「YUV」、コンピュータの色空間である「RGB」の相互間を変換（換算）するためには、少なくとも、

NTSCの「白」「黒」　　　YUVの「白」「黒」　　　RGBの「白」「黒」
そして、これら3つの間の「相互換算方法」

が決まっていなければなりません。基準点がないと、物差しの作りようがないですから。

もっとも基本的には、ITU-R601「デジタルビデオスタジオのための符号化規格」に従うことになっています。輝度に関していうと、アナログNTSCの白（0.714V=100 IRE）を表現するためのデジタルビデオでの輝度値はY=235、アナログNTSCの黒（0V=0 IRE）をY（輝度）=16、と定め、Yを255階調化することになっています（これを、601ルミナンスレンジ、などと呼ぶことがあります）。

例えば、50%の白（=真灰色）は、Y=125といった具合です。

一方、YUVとRGBとの間の換算に特に規定はなく、それぞれのDTVソフト・DTVシステムにゆだねられています。

DV登場前のDTVでは、アナログキャプチャーをしていたわけですが、この時代、NTSCカラーバーを使って、YUVの601レンジの範囲を超えないように調整（キャリブレーション）して、色味が変わることを避けることが（ある程度）できていました。この当時、DTVをしていた方は、アナログビデオにも精通していた方が比較的多かったので、色の管理の意識も（高いヒトは）高かったといえます。また、アナログビデオの性能自体、100IREを超えるような白を録画することが難しかった、という事情もありましたが。

DVの登場

さて、NTSCの輝度信号では、基本的には0〜100 IREのはずです。

規格上は、輝度のみでは115IREまで、色差信号も含めると133IREまで許されています。

なので、100IREを超えない「白」はリーガルホワイトなどと呼ばれます。

ところが、DVでは、100IRE以上の「NTSCの白よりも白い白」が含まれてしまうことがあります。この白のことを、スーパーホワイトとか、（規則外の白という意味で）イリーガルホワイトなどと呼びます。

考えてみると、スーパーホワイトのおかげで、アナログビデオに比べてDVでは白の微妙な階調表現ができるわけですが、反面、DTVとの関係でいうと、「白クリップ」という問題が生じてしまった時期がありました。白クリップ問題に関しては、こちらをごらんいただきたいのですが、

レンダリング前画像にくらべ、レンダリング後画像が、明らかに暗くなる

という現象が、ある一時期に起こっていました。

この白クリップ問題、簡単に言うと、こんなことが起こっていたからでした。

スーパーホワイトを含むような画像が録画されたDVテープを、FireWire経由でDVキャプチャーすると、輝度Yが236〜255間での値を示す白を含むことになります。

アナログキャプチャーと異なりFireWire経由ですので、DVテープに録画されたデジタルデータがHDDに転送されてくるだけですから、撮影時に輝度Yが236〜255が録画されてしまっていたら、そうなりますよね。

ところが当時のDTV編集ソフトは、このDV素材を編集してレンダリングする際、YUVでのリーガルホワイト（Y=235）をPCルミナンスレンジの白（R,G,B=255,255,255）に変換する処理をしていたのでした。つまり、レンダリング処理の過程でRGB空間を使っていたので、スーパーホワイトを含むDV素材をレンダリングすると、Y=236〜255の白を、Y=235の白と同様、R,G,B=255,255,255にしてしまう訳です。そして、RGB空間で合成・モーション演算などをしたあと、再びYUVに変換し直します。でも、RGB空間に持ち込む際に失われたY=236〜255の白は、RGBからYUVに戻しても失われたままです。

このため、レンダリング後のビデオデータには、Y=236以上のスーパーホワイトが含まれない様になり、白クリップ問題（全体に暗くなり、白の階調表現が甘くなる、といった症状）が発生していたのです。

これは、Final Cut Pro 1.0〜1.2.1までで実際に起こっていたことです。また、当時、他のDTVソフト・DTV編集システムにおいても、おそらく同様な理由により白クリップ問題は発生していました。

MacDTV.FAQ レンダリングすると動画が若干白味が増してしまいます

比較最近では、Final Cut Pro 3 on Mac OS 9の環境で、cleanerやcinestream, EditDVを併用した場合に限って、白クリップが起こることもありました。

　 白クリップをいかにして乗り越えたか

ところが、現在では、白クリップは通常使用時には特に問題になることはありません。それはどんな措置が執られたからなのでしょうか。

Final Cut Proを例にすると、解決が図られたのは、Final Cut Pro 1.2.5以降です。
Final Cut Pro 1.2.5以降では、レンダリング処理の過程で、RGB色空間を使う従来のやり方の他に、YUV色空間を使用するやりかたが用意されました。また、シーケンスのデフォルト設定が、スーパーホワイトに設定されました。これらの措置の意味を説明します。

まず、YUV色空間でレンダリング処理することにより、YUV-RGB変換に伴う色味やレベルの変化自体を避けるようにしました。前述の例でレンダリング中間処理でRGBを経由しないわけですから。
また、ITU-R601という規格に従うと0〜100IRE（601ルミナンスレンジ）を超える色は原則存在しないはずですが、現実にはDVテープではスーパーホワイトを含んでしまっています。
ですから、Final Cut Pro 1.2.5以降では、この現状を認めて、スーパーホワイトが入っていても白クリップなどが生じないようにしましょう、というポリシーに変更したのです。

マニュアルの記載やいくつかの実験の結果、Final Cut Pro 3の[スーパーホワイトモード]では、109 IREまでのスーパーホワイトの存在を許すように設定されているようです。

黄色(R,G,B=255,255,0)から白(R,G,B=255,255,255) へのグラデーションを掛けた静止画をFinal Cut Proの[スーパーホワイト]モードへ持ち込んだ例。 波形モニタで計測した場合、最大値が約109 IREとなる。

この換算の仕方は、非常にリーゾナブルです。つまり、デジタルビデオのY=255という値は、ITU-R601に従うとアナログ（NTSCビデオ）の109IREに相当する「きりのいい」値です。こんなY=255とR,G,B=255,255,255とを換算するというのも、なにかと都合がいいのです。

一方で、ここで新たな問題が生じました。DVカメラでスーパーホワイトを含む画像を撮影してしまったことは致し方なかったとしても、放送局におさめるような作品を作る際に、納品作品が100IRE以内のレンジに収まっていなくてはならない、といったシビアな状況もあるでしょう。

ただ、最近では、TV放送でも、スーパーホワイトを含むビデオ画像をかなり平気で放映しているそうですが....。

そんな場合に使用するのが、[ホワイト]モードです。このモードだと、シーケンスの出力レンジは100IRE以内に抑えられます（ただし、ソースがスーパーホワイトを含むビデオ画像なのですから、全編レンダリングが必要になります）。

黄色(R,G,B=255,255,0)から白(R,G,B=255,255,255) へのグラデーションを掛けた静止画をFinal Cut Proの[ホワイト]モードへ持ち込んだ例。 波形モニタで計測した場合、最大値は100 IREに抑えられている。

[スーパーホワイト]モードにおいても[ホワイト]モードにおいても、「Final Cut ProでRGB静止画を持ち込んでレンダリングし、それを再度RGB静止画へ書き出し」という操作を繰り返しても、元のRGB静止画と書き出しRGB静止画との間に、大きな色の変化はありませんでした。つまり、

Final Cut ProへのRGB静止画持ち込み（入力）、Final Cut ProからのRGB静止画書き出し（出力）の双方向処理においても、再現性は高い、

ということです。

DTVで関わる「色空間」

DTV編集ソフトと、RGB

MacDTV.com

Copyright(C) Yasushi SATO　All Right Reserved.

MacDTV情報ひろばトップページ　＞＞　MacDTV研究室
＞＞　ビデオの色　＞＞「DTVでの色の問題」の歴史

MacDTV.comトップページに戻る