2011-11-15

3Dコンポジット時のチャンネルについて

3Dコンポジットはとても有効。
たとえば演者がグリーンバック、ブルーバックで撮影された素材複数あるとして、それをキーアウトしてcardノードを用いて立体的に配置してやれば、ある程度のカメラワークにも耐えることもでき群集シーンにはとても適している。

それだけであれば、AfterEffectsでも可能だが、nukeの利点はカメラプロジェクション、プリミティブ以外のジオメトリの追加などいろいろと利点もある。

通常のrgbaだけならそんなに問題はないのだが、その他のエキストラのチャンネルの扱いには少し癖があるので、ちょっとした説明を。


こんな感じでアルファチャンネルを持ったcardノードが3枚ある。これらはすべて、通常のrgba以外に、[test]というチャンネルをRGBAで別に持っている。
ざっくりと説明して・・・

nodeA

nodeB

nodeC

それぞれ、上が[rgba]チャンネル 下が[test]チャンネル、左がRGA 右がA である。
nodeABCそれぞれ[rgba]として白色のマスクされた形状を持っており、nodeAは[test]チャンネルとして、同じ形状で赤でアルファありのもの。nodeBは[test]チャンネルとして何も持ってない。nodeCは[test]チャンネルとして青のアルファなしである。

これらをScanlineRenderノードを通してみると・・・

(ScanlineRender)

[rgba]チャンネルは上のようになる。おそらく「over」の計算式が適応されているようである。
[test]チャンネルはというと・・・
(ScanlineRender)


となり、

nodeAの円がnodeBの円によってくりぬかれてるのが確認できる。

nodeBの[test]チャンネルをもう一度見てみると・・・


下段[test]チャンネルにはRGBAともに何もないはずなのに、結果として、Bの円より後ろにあるAの円がくりぬかれている。
これは実は、「3Dコンプの合成計算式に用いるA(アルファ)はrgbaのAである」ということに起因している。
なので、nodeBのrgba.Aは真っ黒ではなく、ちゃんと塗り形状が存在し、overの計算式

output = A + B*(1-Aa)

ややこしいが、この場合で前景であるnodeBがA、背景であるnodeAがBである。
よって「Aa」の部分で

A が (nodeB.test.RGB)   a が (nodeB.rgba.A)

となる。
そのため、黒がアルファ値1によって上から塗られている状態である。
また、この3Dコンプのアルファチャンネルを見てみると

(ScanlineRender)

となり、どうやら、アルファの部分を別でさらに計算しているようで、

A が (nodeB.test.A)   a が (nodeB.rgba.A)

で計算しているようだ。
なので、nodeBのアルファを0にすると

nodeB

nodeBの[rgba]のアルファを0にした結果(ScanlineRender)
上記のアルファ(ScanlineRender)

となる。


nodeCの円弧のラインがAの円の上に透けているのが確認できる。



気をつけたいのはアルファは常に[rgba]のアルファを参照しているということである。
これをうまく使えば、グリーン素材とその背景の煙素材なども、普通にcardで配置して、煙のチャンネルだけを別に[smoke]チャンネルとかに格納して取り出せば、煙だけmerge operation(over, plus, screen等)を変えて乗せることが可能だ。



(ScanlineRender)
(ScanlineRender)

となり、mergeで結合すると



mergeの結果

が得られる。

2011-11-11

追記:Beautyの再構築

先日の追記です。
コンプでBeautyを再構築したとして、前回問題であった
--------------------------------------------
RawReflection*ReflectionFillter = Reflection
--------------------------------------------
の部分をCG側で直接だしたとして(パスをRawReflectionとReflectionFillterに分けず、Reflectionとして出力)、その後コンプの調整でReflectionを抑えたいとなった場合・・・


となってしまう。
やはりダイナミックレンジの恩恵は大きく、本来であれば

exrからBeautyを再構築したものから調整
となってしかるべきであろう。

2011-11-10

Beautyの再構築

CGを用いたコンプの場合、各レンダーパスをもとにしてBeautyの再構築をしなければならないことがある。こんかいは、必ずしも一般的ではないが、vrayを用いてレンダーパスを出力し、それをnuke内で再構築したいと思う。

こんな感じでレンダーされているとする。



 各レンダーパスの計算式は以下で成り立つ

------------------------------------------------------
diffuse*RawGI = GI
diffuse*RawLight = Lighting
GI + Lighting = TotalLighting

reflectionFilter*RawReflection = Reflection
refractionFilter*RawRefraction = Refraction

TotalLighting + Reflection + Refraction + Specular = Beauty

------------------------------------------------------

レンダーパスはAOVsにしてexrを用いて作成した。
nukeでLayerContactSheetノードを用いて表すとこんな感じ。


まずは、
------------------------------------------------------
diffuse*RawGI = GI
diffuse*RawLight = Lighting

------------------------------------------------------
から、

diffuse
RawGI
RawLighting

で掛け算(multiply)して



ここでは、Multiplyノードの中のA、Bチャンネルでチャンネルを指定している


がShuffleノードをつかって、


とやっても可能。
できあがったGIとLightingを足して


TotalLighting
とする。
と同様の方法で、ReflectionとRefractionを得るのだが、実はこの最終的に再構築しようとしているBeautyは


viewerの右上にある「cliptest」で確認するとわかるのだけど、1以上の値がある。実際には、exrはダイナミックレンジを収録できるので、


とこんな感じで、1以上の値を確認できる。
これをtargaのような8bitの画像でレンダリングすると、


こんな風に1以上の値は自動的にクランプされ、「cliptest」をオンにしてもダイナミックレンジ領域(?)が確認されない。

これがどのように影響されるかというと・・・
たとえば、クランプされた画像(要するこれは8bitの画像と同じことであるが・・・)でBeautyを再構築すると


という具合にハイライトの部分がいまいち上がりきらない画像になる。
これは、 今回のケースの場合
------------------------------------------------------
reflectionFilter*RawReflection = Reflection
------------------------------------------------------
の部分でのRawReflectionが

exrを直接viewerで確認

exrをクランプしたものをviewerで確認(8bit画像を想定


という感じで、8bitの画像でも、ダイナミックレンジを持っている画像でも、見た目はハイライトで白く飛んでいる部分があるが、実際にはレンジの違いがある。

RawReflctcionをcliptestで見た場合
これに、ReflectionFilterを掛けると、この白く飛んでしまっている1以上の領域の階調が1以内に収まってる部分ができ、その部分にグラデーションを確認できる。クランプした画像(8bitを想定)だと、どうしてもそうはいかない・・・(下記例ではわかりやすくするため、Multiplyノード(math)で0.05を掛けてます)

ReflectionFilter
exrに掛け算をして暗くしてみた例。1以上で飛んでいたハイライトの中にグラデーションが生まれる。

exrをクランプしたもの(8bitを想定)に掛け算をして暗くしてみた例。1以上で飛んでいたハイライトがくすんでつぶれる。
結果として、

オリジナル
exrからBeautyを再構築
exrをクランプしたもの(8bitを想定)からBeautyを構築

という差が生じる。もちろん、ピクセルの値が1を超えないものであれば、問題が無いケースも多々あるであろうが・・・

2011-10-14

「らしい」の話 ← 訂正しました

今回は「らしい」ばかりです。
ちゃんと自分で調べたわけでないので・・・


PCモニターなどは元々、「入力」と「出力」が一対一の関係にない。
モニター上で真っ白を半分の輝度にするために、信号を半分にしても輝度は半分にはならないらしい。


こんな感じで曲線的に入力と出力の関係がなりたっているらしい。これをガンマ曲線といったりするらしい。要するに、データの持つRGBデータに対して、中間部分で「暗め」に映るようである。


じゃあ、たとえば写真をとったとしてそれをこのPCモニターに写すことにする。仮にカメラで保存されたjpg等のファイルがカメラで撮った情報そのもののRGB値だとすると・・・




となり、モニターガンマの影響をうけ、実際に見えてほしい明るさとはことなってしまう。
これを避けるため、通常、画像ファイルは「カラースペース」などと呼ばれる補正カーブを持っている。




という感じで、カメラで撮った画が、ちゃんとPCモニターなどに出力される。


補足

ちなみにNukeでsRGBの画像を読み込みガンマLinear出だすと、ファイルガンマの状態が確認できる。


原理的にはこんな感じ



という前置きがあり、しかしこの補正カーブというのが各ファイル形式によって違いがあったりする。
たとえば、デジカメで保存されたりwebで見かけるイラスト等のjpgファイルは8bitファイルであり、「sRGB」と呼ばれるカラースペースをもっている。10bit cineon形式(.dpxなど)は「log」と呼ばれるカラースペースをもっており、近年でてきたOpenExrなどは「linear」で保存できたりする。
※ファイル形式によりカラースペースが決まるのではなく、埋め込みlutを何にするかで決まる。
一般的には上記のようでないかと思う。
参考↓
http://area.autodesk.jp/column/trend_tech/color_magazine/cineon_openexr_colorspace/


で、じゃあそんな風にバラバラのカラースペースを持つファイルをどうやって合成すればいいのか・・・
各々の「カラースペース」を打ち消して、一旦「1:1」入出力の「リニア」にしてやり、それを最終的に、PCモニターに出すのならsRGBのカラースペースを与えてやる。すると、その画をPCモニターなどで確認すると、さっき説明したように、sRGBの補正カーブでモニターガンマが相殺され、正しい結果をPCモニター越しに得ることができる。
また、この補正カーブをLUT(Look Up Table)と呼んだりもする。


sRGBのLUTの曲線はガンマ2.2の曲線(y = x ^2.2 / 出力が入力の2.2乗倍 )と非常によくにており、gammaノードなどをもちいて簡易的に補正することも出来るが、LUTの中には複雑なカーブであるものもあり、単純にgammaノードで値を操作してってことで簡単に補正できないケースもある。


Nukeの優秀な点は、そのファイル特有のカラースペースを指定してやることで、それを打ち消して、一旦すべてをリニアな状態で合成が出来るという点である。

補足:Nuke内でリニアで合成を行うため、Readノードでファイルガンマの逆ガンマをあて、viewer(ノード)ではモニターガンマの逆ガンマをあてている。

どのようなファイルフォーマットがきても、一旦リニアで扱い、最終送出ソースに合わせてviewerLUTを変更することで、正しい出力をすることが出来る、





このような感じで、いろんな種類のフォーマットを正しく扱うことが出来る。らしい・・・