>   >  NUKE プラクティカル・ガイド:Vol.11:続・キー合成 ※サンプルデータあります!
Vol.11:続・キー合成 ※サンプルデータあります!

Vol.11:続・キー合成 ※サンプルデータあります!

<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によるキー合成

その他の連載