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

DTVをやっていると、さまざまな「色」の問題に出くわします。このコーナーでは、ビデオにまつわる色の問題を解説します。

DTVで関わる「色空間」

DTVで関わる「色空間」には、次のものがあります。

NTSC信号（アナログのTVの信号）における、輝度信号・色差信号

これは、アナログです。単位は、ボルト、またはIRE。

デジタルビデオの色空間であるYUV

Yは、輝度（ルミナンス）。U,Vは、色差（クロマ）。Cr,Cbと表記することもあります。
これらはデジタル信号で、いずれも0〜255までの256種の値を取ります。

コンピュータの色空間であるRGB

0〜255までの256種の値を取ります。

結論から言うと、「DTVで起こる色の問題」は、色空間が異なっている以上、空間変換（換算）に伴うので、原理的にさけられません。これは、DTPにおけるRGB-CMYKにまつわる問題と基本的には同様ですが、DTVの場合、その上、以下のような事情が複雑に絡みます。

「相互変換する際の変換のやりかた」が、DTVソフト・DTVシステムによってさまざまなケースがあること、

DTVの場合、ソースがアナログビデオの場合、ソースがYUV（つまり、DVのようなデジタルビデオデータ）の場合、ソースがRGB（CGなど）の場合など、さまざまなケースがあること、

これらのメディアを混在させながら編集を行い、最終的に作品に仕上げるとき、最終作品が、アナログビデオの場合、YUVの場合（DVやDVD-Video）、RGBの場合（例えば、CD-R用ムービーなどパソコン上で再生するムービー）などさまざまなケースがあること

これをDTPの場合でみると、ソースは基本的にはRGBのみ。出力は、電子出版の場合のRGB（編集モードと同じ）か、印刷の場合のCMYK（編集終了後CMYK書き出し）か、と比較的シンプルです。（もちろん、DTPでも、詳細な諸問題があると思いますが、とりあえずDTVとの比較、ということで、これくらいの記述でご容赦頂きたいと思います。

こうしてみると、上記の事情が複雑に絡むDTVなのですから、「色が変わってしまう問題」に出くわしたとき、一体「どんなケース」において色の問題が起きているのか区別して議論しないと、全く意味がありません。たとえば、Mac上での再生画質を問題にしているのかTV上再生なのか、色が変わるのはレンダリング前なのか後なのか、といった区別がないと、まともな議論や論評になりません。

「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といった具合です。

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編集ソフトと、静止画での色の関係

このようにして、DVを素材として編集処理する分には、白クリップ問題などは通常発生しなくなりました。また、どうしても601レンジに抑えたい場合を想定して、前述の[ホワイト]モードや[ブロードキャストセーフ] フィルタ類も用意されています。

しかし、「DTVでの色問題」、完全に解決しているわけではありません。

一例が、DTV編集ソフトに、PhotoShopに代表されるCGソフトで作成した画像を持ち込む場合です。例えば、2D/3DアニメーションをDVビデオに書き出したとき、意図した色味と異なってしまったとか、白などの明るい色における微妙な階調表現が失われてしまった、といったことが典型例です。

また、通常のDV素材の編集でも、Photoshopで作ったテロップの色が、DVカメラ経由TV上で再生すると、色がくすんでいる、といったケースもあるでしょう。この場合、RGB→YUV変換を伴う「色味変化の問題」をもろに食らいますからね。

Final Cut Proの場合、スーパーホワイトモードだと、R,G,B=255,255,255の白は、109IREとなるように換算されるようです（もちろん、ホワイトモードだと100IRE）。また、逆に、Final Cut Proから静止画フレームとして書き出すと、109IREに相当する白は、R,G,B=255,255,255にマッピングされるようです。このように、RGB→YUV、YUV→RGB双方向に再現性よく、変換されているようです。

　 なぜ、静止画書き出しして戻すと、色味が変わってしまうことがあるのか。

さて、長々と書いてきましたが、このコーナーの目的のひとつには、MACPOWER誌2003年4月号の服部さんのロードテスト（208ページ）にお答えするため、というのが理由の一つです。

服部さんのロードテストの一連の流れは、

Final Cut Proの一フレームを静止画として書き出し、Photoshopで修正した後、再びFinal Cut Proに戻すことで、アナログノイズを消したかった。だけど、一連の操作により、修正前フレームと修正後フレームで色が違ってしまう

というものでした。本質的に、この手のビデオペイント・ロトスコーピング系の処理はCommotionといった専用ソフトを使うのが手っ取り早く正解なのですが（笑）、それはともかく、これに対するお答えのひとつとして、

というやりかたをご用意させていただきました。

それはそれとして、なぜ、静止画書き出しして戻すと、色味が変わってしまうことがあるのか、という疑問は残ります。この点が気になって、こうして「DTVにまつわる色の問題」を書きはじめた次第です。

前節で示したとおり、Final Cut ProのスーパーホワイトモードだとR,G,B=255, 255, 255の白はYが109 IREとなるように換算され、逆に、Final Cut Proから静止画フレームとして書き出すと109 IREに相当する白はR,G,B=255, 255, 255にマッピングされる、というように、RGB→YUV、YUV→RGB、双方向に再現性よく変換されています。では、ここまでしていて、なぜ、色味が変わってしまうことがあるのか、というと...。

もうおわかりの方もおられるでしょうね。

色味が変わってしまう（ことに気づく）ような図柄は、そもそも明るい画です。人間の目は輝度には敏感、という特性がありますので。たとえば、こんな夕焼けの図柄などはまさにそうで、夕日の黄色〜白は完全にスーパーホワイトです。

で、輝度が109 IRE以下に収まっている分には問題ないです。実際、Final Cut Proの波形モニタを見ている分には、一見109 IRE以下で収まっているように見えます（Final Cut Pro波形モニタの一番上の目盛りは110IRE相当）。

でも、これを本格的な波形モニタソフトVideoScope（Evological社）を使いますと、

Final Cut Proの波形モニタと全体はよく似ていますが、ピークトップ部に突出している部分（たぶん夕日の中心部）があることがわかります。

VideoScopeで見た波形の拡大図 一番上のメモリは、100%の白	Final Cut Proで見た波形の拡大図 一番上のメモリは、110IREの白

Final Cut Proの波形モニタでは最大目盛りが110IREなのでもしこれ以上の輝度が含まれていても表示しようがないこと、NTSCは規格上115IREまでを許されている*ことも考えあわせると、この画像は109〜115IREのスーパーホワイトを含んでいると考えて良いように思います。

* 色差信号も含めると133IREまで許されています。

ところが、Final Cut Proは、109IREを上限として処理するようになっているようです。そうすると、109〜115IREのスーパーホワイトについては、Final Cut Proではどのように扱われるでしょうか。

Final Cut Proは、109IREを超える成分を含むフレームを静止画に書き出すとき、109〜115IREのスーパーホワイトについては、本来のルールである「109IRE←→R,G,B=255, 255, 255」となるよう、自動的に画像をいじってくれているのではないか。

これが、静止画書き出しして戻すと色味が変わってしまうことに関して、わたしがたどり着いた推察です。

このようなケースでのRGBレンダーモードの是非

RGBレンダーモードは、（AfterEffectsと同様）CGにモーションを付けたムービーを作る、といった場合に使用することが基本です。

また、これもAfterEffectsと同様、書き出しは、「CD-R用のQuickTimeムービー」のようなRGBものをターゲットとする場合もそうです。

一方、DVなどのビデオに書き出す際には、YUVを使用する[スーパーホワイト]モードや[ホワイト]モードにしましょう。

さて、前述の服部さんのロードテストのようなケースでの「RGBレンダー」使用は是か非か?。これは、単純に「RGBレンダーは色が変わるからダメ」という問題ではありません。なにしろ、100IREはおろかFinal Cut Proで扱えない109IRE以上の白を含むような明るいDV画像（を撮影してしまったこと）自体が「間違っている」のですから。間違った画像を「正しい画像」へ変換すること、すなわち、より正しいレンジの範囲内に収めようとする結果として色が変わるということが、間違っているとは思えません。

とはいえ、もし、より正しいレンジの範囲内に収めようとするのなら、[ブロードキャストセーフ] フィルタ類を使ってユーザが意識的に修正するのが本道でしょうし、また、元々のRGBレンダーモードの目的からすると、けがの功名的な使い方には違いないので、あまり積極的にはおすすめしません。
総合的に作業性も考えると、この手のビデオペイント・ロトスコーピング系の処理はCommotionといった専用ソフトを使うのが手っ取り早く正解ですし、あるいはぷれぷれさんのぷれぷれさんのFinal Cut Pro Unofficial、2003年1月29日の記事記載の方法（MACPOWER誌2003年4月号208ページの服部さんのロードテストでも紹介されています）もあることですし。

まあ、DTVを巡る色の問題を考えるには良い機会ではありました。

ビデオの色に関してはまだまだネタはあるのですが、長くなりましたので、とりあえず今日はこのくらいで。

MacDTV.com

Copyright(C) Yasushi SATO　All Right Reserved.

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

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