記事の目次

    キー合成はNUKEの強みのひとつだ。KeylightPrimatteUltimatteという代表的な3つのキーヤーに加え、NUKE独自のIBK Colour、IBK Gizmoを用いたImage Based Keyingという手法も標準で搭載されている。
    さて、前回にひき続きキー合成を取り上げるが、今回はキー合成のクオリティを上げるべく、インテグレーション(なじませ)について紹介していこう。「百聞は一見にしかず」ということで、NUKEのサンプルデータを用意(後述)したので、ぜひダウンロードした上でのご一読いただければと思う。

    TEXT_テラオカマサヒロ(Galaxy of Terror



    <1>キー合成の問題点

    キー合成での一番の問題点は恐らくエッジ処理だろう。前回も同様のことを述べたが、そのエッジ処理が上手くいかない場合に、マット(キー抽出の結果のアルファチャンネル)の調整でなんとかしようとしている人をよく見受ける。筆者の持論ではあるが、キー合成の問題の多くは、キー抽出で起こっているわけではなくて、ディスピル処理やそれに付随するFG(Foreground)の処理で起こっていると筆者は考える。
    正確には、完全なキー抽出が可能であれば完璧な合成が可能であるが、それは難しく、ディスピル処理やそれに付随するFGの処理でかなりの部分を解決できると考えているわけだ。

    連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)

    <1> (左)ディスピル処理が上手くいっていない例/(右)それをディスピルだけ調整したもの

    実際、もちろんCGでのアルファチャンネル出力のように、完璧なキー抽出ができるわけではない。なので、キー抽出で起こる問題を完全に解決するよりも、ディスピル、 FGプレートをできる限り調整して合成結果を好ましいものにする方が、近道あるというのが筆者の考えである。
    そもそも、スクリーン合成というのは、例えば、現実では撮影できない状況を再現するために行われていたりして、合成されるべく背景が暗いのに、キーイングがしやすいように、撮影したグリーンスクリーンがある程度の明るさを持っているってケースなんかは本当に多い。
    そしてこの場合に、被写体のエッジ付近のピクセルに何が起こっているかをじっくりと考察してみよう。そもそもキー合成において完全不透明な部分ではあまり大きな問題が起こりづらい。しかしエッジ部分にはモーションブラーやアンチエイリアス等で、背景が透けており被写体とグリーンスクリーン等がブレンドされているピクセルが存在する

    連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)

    <2> モーションブラーや被写界深度によるボケ等で半透明部分には、背景色がブレンドされたものが表示色として現れている。これは、度合いの大小はあれど、アンチエイリアス部分にも確実に同様の効果が現れわており、これらをいかに処理するかで、キー合成のインテグレーションも大きく左右される

    また、撮影された素材は、当たり前ながら純粋に2D素材であり、そういうモーションブラー部分などは、そうやってブレンドされた状態で撮影されている。
    くどいが要するに、被写体がこの色で、グリーンスクリーン分がこの色で、といったdeepデータのように収録されているわけではない。したがい、被写体のモーションブラー部分の半透明部分にブレンドしてしまっているグリーンスクリーン成分、つまり撮影時の背景成分をキャンセルする必要がある。

    連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)

    <3> ちなみに、deepデータであれば、サンプルしたピクセルが半透明である場合、手前のピクセル情報と透けた先の奥のピクセルの情報を取り出せる

    【サンプルデータを無償配布!】

    今回は確実な結果のでる deepデータを用いて、検証することにする。作例データを公開しているので、下記リンクからダウンロードしてデータを見ながら読み進めていただければと思う。

    連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)

    ○ダウンロードリンク
    cgwjp_nukePracticalGuide011_data.zip

    ※データダウンロード先URLの表示/データはnuke9で開くことを推奨します、NUKE 8でも開きます。また、Non Comercial版でも開きます。Non Comercial版は www.thefoundry.co.uk/ products/nuke/ の「Product downloads」から入手可能です。

    ▶︎次ページ:
    <2>半透明の向こう側

    [[SplitPage]]

    <2>半透明の向こう側

    仮にmergeノードのoverオペレーションの計算式が、現実世界を忠実に再現できているとしたら、グリーンスクリーンの前での撮影プレートは、A+B(1-a)となっており、つまり、被写体(A)の半透明部分に含まれるグリーンスクリーン(B)は、B(1-a)分に相当する。まず、これを再現してみよう。

    ※以降の解説は、前ページにて公開配布した「サンプルデータ」に基づいています

    公開したnuke scriptの一番左側にある「No.1」のところをみると、deepデータを撮影プレートと仮定して、背景を被写体を分離して、さらに、それを再合成し直し、撮影プレートを再現しているのが確認できる。B(1-a)分はBにa(Aのアルファ )を反転したもの掛けたもの、つまりBをAのアルファでくり抜いたものということになる。ここでは「stencil」で再現している。

    • 連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)
    • <4> deepデータから前景と背景を分離させて、そこから元の状態を再構築している。オリジナルと結果を比べると完全に致するのが確認できる


    連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)

    <5> A成分とB(1-a)成分。mergeのoverオペレーションはこれら2つの和である。つまり、BはAのアルファ(a)でくり抜かれて加算される

    さらに考えをすすめて、元ソースから、A成分だけを抽出してみる。「No.2」のところを見てみると、先ほど求めたB(1-a)分を用いて、元ソースからこの B(1-a)分を引き算すると(nuke script内ではfromで再現)、A成分のみが抽出できる。
    つまり、これが、撮影プレートから被写体部分だけを正確に抜き取る方法だ。

    連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)

    <6> くどい説明であるが、「No.1」で導いたB(1-a)を用いて、オリジナルからその分をさっ引いて、A成分を求める。当たり前であるが、「No.1」のそれと一致する。rgba.alpha = 1の部分に乗っているグリーン、つまりリフレクションによるスピルまでは除去できていないのが同時に確認できる

    ただし、実際には、deepデータとして撮影しているわけではないし、3DCGでもないので、撮影プレートは一枚画のRGB情報としてしか存在し得ない。正確なAもなければ、Bもなく、ましてやaもない。ちなみに、ここでいうaはキー抽出分、つまりキーイングで得られるマットということになる。

    次に、上述の一枚画のRGBから、まずは、仮にキー抽出が完全に可能だったとして、deepから被写体分のアルファだけ用いて、キー合成のプロセスを再現してみる。
    「No.3」のところに移動してもらうと、前回説明した「ルミナンスバック」を加味したKeylightでのディスピルを行なってキー合成した例を確認できる。

    • 連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)
    • 連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)

    <7><8> 前回(Vol.10)紹介した手法でのKeylightを用いたディスピルとルミナンスバックの例。ただこれだけだと、エッジに明るい境界(ハロ)を感じてしまう。
    今回説明は割愛しているが、「No.3」「No.5」でこれを回避する方法の一つを示しておく。これは、前回も紹介したブログ「Compositing Mentor」の記事「Advanced Keying Breakdown: DESPILL 2.2 - Despill Techniques」で詳しく紹介されている


    次に、やはり現実世界からキー抽出を「No.3」のように完全にできるわけではないので、「No.4」でIBKを用いてキー抽出を行い、キー合成をしてみよう。

    連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)

    <9> 「key extraction」としたところで、IBKでのキーイングとそれに必要なクリーンプレートの作成の流れを示している。今回はDenoiseしないことを前提としたした手法になっているが、手前味噌ながら、ここで示している流れはかなり有効であるので、是非データでチェックしていただきたい

    IBKを用いると、キー抽出の途中でクリーンプレートができる。これは撮影プレートのBに近しい結果なので、これを用いて、B(1-a)分を導くことにする。ここで得たB(1-a)をオリジナルプレートから引き算すると、「No.2」で説明したようにA成分のみが抽出できるはずだが、「No.2」「No.4」のAのところで確認してみると、「No.4」「No.2」のそれと比べてあまり良好なものでないことがわかる。モーションブラーで半透明になっている部分とそうでない部分の境界に、グリーン成分がでてしまっている。

    連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)

    <10> 左が「No.2」でdeepを用いて導いたA成分、右が「No.4」でキー抽出から導き出したA成分。後者が不完全なものであることは明白である

    これは、やはりキー抽出が完全に行えるわけではないことに起因する。「No.2」「No.4」をそれぞれaで比べるとわかりやすいかと思う。

    連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)

    <11> 上がdeepから導いた正確なアルファ情報。下が、キー抽出で導いたアルファ。よく見ると、下段のアルファはモーションブラー部分で半透明部分の幅が狭く、本来半透明になるべくところが、 再現されずrgba.alpha = 1になってしまっている部分がある。このため、先掲した<10>のような差が現れる

    今回の例ではIBKGizmoのred weightを下げるとこの問題は改善されるが、そうすると、他の良好だった部分までが影響されてしまう。

    連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)

    <12> 「No.4」「No.5」で再現した「key extraction」のIBK Gizmoのred weightを調整した例。「No.4」と結果、A成分で比べてもらうと、改善していることが確認できる

    ここでは追加のディスピルを用いて改善してみた。また、場合によっては多少のロト等を用いて、部分部分に調整するのも効果的だ。ただ、今回のようにクリーンプレートが作りやすいケースではB(1-a)分が作りやすいので、このような手法がとれるが、クリーンプレートが作るのが困難なケースもある。グリーンスクリーンにムラが多かったり、被写体の形状が複雑だったりすると、IBKでクリーンプレートを作成するのが困難だ。そうした場合は、前回(Vol.10)に名前だけ紹介したAdditive Keyerが有効だ。

    ▶︎次ページ:
    <3>Additive Keyerによるキー合成

    [[SplitPage]]

    <3>Additive Keyerによるキー合成

    実例は、サンプルデータ内の「No.5」を参照していただきたい。Additive Keyer自体については、Nukepedia「Additive Keyer」で解説されている。
    要約すると、撮影プレートとクリーンプレート(つまり被写体を除いたと想定するグリーンだけのプレート )の差分を求め、その差分のrgbの平均値 (saturationを下げたもの)がプラスの場合は合成されるべく背景と掛け合わせたもの、マイナスの場合はそのままの値を合成されるべく背景に加算する。

    連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)

    <13> 「No.5」にある、Additive Keyerのノード構成。Nukepedia「Additive Keyer」を参照してもらいたい。今回はコンセプトはそのままにして少し改良している。linlogして、loglinで戻しているのは、明るさ等を足し引きする場合、コンプの通例として割とこの変換を用いる。理由は、影部分等の差がなだらかになり、また非常に強い値でも極端な値にならないというメリットがある

    こうすることで、モーションブラー等で半透明部分が合成結果時に黒ずむことなく、背景の色を加味したモノで合成される、というコンセプトだ。

    ちなみに、マイナス値の部分は、グリーンスクリーンで撮影された被写体が比較的暗いのに、グリーンスクリーンが明るい場合に、その半透明部分に明るいグリーンスクリーンが透けてしまうことで、合成結果としてハロと呼ばれる明るいボーダーラインを得てしまうのを抑えることができる。
    要するに、合成されるべく背景を考慮したFGプレートを作成することを目的としている。また、「No.5」ではB(1-a)に頼っていないので、完全なクリーンプレートを作成するのが困難であっても、ある程度機能する構造になっている。addive keyerとしてあるbackdrop内の赤いsaturationに[0]を用いることで平均値を出しているが、この値を少し上げることで、半透明部分に、元の色を少し返すことができる。

    連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)

    <14> 本文説明にあるようにAdditive Keyer にあるsaturationの値を上げてみた例。半透明部分に赤を感じるようになった。わかりやすくなるように値に0.6を用いているが、今回例では0.2ぐらいがちょうど良いように思える

    「No.6」「No.7」では、グリーンスクリーンが合成されるべく背景と比べて、明るい場合と暗い場合の例を挙げている。

    連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)

    <15> 上段が、撮影プレートで適切だと思われるグリーンスクリーンの明るさよりさらに明るく、かつ、合成されるべく背景が暗い場合の例(「No.6」)。一番右の結果をみるとハロが目立っている。下段がその逆でグリーンスクリーンが暗く、背景が明るい例(「No.7」)。右の結果にはエッジが暗くなっているのを感じる

    いずれも、Additive Keyerとしてあるbackdrop内の緑のgradeノードをON/OFFしてみるとその調整方法が確認できる。細かい説明は割愛するが、前述の、プラス値とマイナス値を調整することで、背景になじみやすいエッジになるような効果を得ている。

    連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)

    <16> 「No.6」での調整例。Additive Keyerにある、2つある緑のgradeノードで調整している。調整は、主にoffsetで行なっている

    連載「NUKEプラクティカル・ガイド」(第11回:続・キー合成)

    <17> 「No.7」での調整例。「No.6」と同様に、2つのgradeノードで調整している。Additive Keyerの特長として、ハロやブラックエッジを比較的容易に調整することが可能になっている

    ここで紹介した手法が、いかなる場合も有効でいかなる素材であっても良好な結果を導くとはなかなか言えないが、数人の同僚コンパー(コンポジター)に「キー合成の極意とは?」を聞いてみたところ、みんな口を揃えて「ケースバイケース」や「色々やってる」みたいな回答であった。

    つまり、キー合成に置いてはみんなそれぞれがそれなりに、手法を持っており、条件によって使い分けているという印象であった。今回紹介したことが、読者にとってその幾つか有るうちのひとつの選択肢になりえるであろう。
    また、前回もふれたが、キー合成においての問題はほとんどの場合ディスピルやFGの調整においてだ。完全なキーと完全なクリーンプレートを得ることができれば完全なキー合成が可能であるが、それはもはやキー合成ではない。そして、現実的には完全なキーが得ることは難しく、どうにかしようと削ったり延ばしたりするのは、本来であれば避けるべきであり、それよりも、ディスピルやFGの調整を背景に合わせた形で行うことで、キーの状態に左右されづらい合成を行うこと方がクオリティを上げやすいと筆者は考える。

    Column.
    北米でも「隣の芝生は青い」?

    担当編集N氏からの提案で、今回からコラム的なものを書くことになりました。せっかくいただいた機会なので図々しくも何かしら書こうと頭をひねってはみたものの......やはり薄っぺらい人間なので、なかなか思い浮かばないですね(笑)。

    山路を登ったりしながら、しぼり出さないといけないのかとも思っておりますが......そう言えば、筆者はPythonやTclを用いてツールを作りながらコンプすることが多く、現在活動拠点としているバンクーバーの同僚たちから「そういうプログラム的な知識はどうやって学んだのか?」と、よく質問されます。
    それを言ったら、「君たちのコンプのセンスはどうやって学んだのか?」って、常々思っているのですが(笑)。とまぁ、周りのコンパーの腕の良さに毎日嫉妬しております......やはり向こう三軒両隣にちらちらするのは、ただの人ではないぞと。

    TEXT_テラオカマサヒロ(Galaxy of Terror)

    株式会社ギャラクシーオブテラーにて VFX ディレクターとして活躍中。
    現在は北米に活動拠点を置き、実写合成からフルCGまで幅広いVFX制作に携わっている。
    個人サイト「tiraokan.」