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

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


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の曲線（ｙ = x ^2.2 / 出力が入力の2.2乗倍 ）と非常によくにており、gammaノードなどをもちいて簡易的に補正することも出来るが、LUTの中には複雑なカーブであるものもあり、単純にgammaノードで値を操作してってことで簡単に補正できないケースもある。


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

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

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

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

メモ

---------------------------------------
import re

list = []

def hogehoge(s):

    an = nuke.allNodes()

    for i in an:

        name = i.name()

        if re.match(s,name) != None:

            list.append(i)

    return list
---------------------------------------

と思ったけど、コレだと実行するたびにリストが増えていく・・・


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

import re

def hogehoge(s):

　　list = []

    an = nuke.allNodes()

    for i in an:

        name = i.name()

        if re.match(s,name) != None:

            list.append(i)

    return list
---------------------------------------

こうかな？

pfTrackユーザー事例に掲載させてもらいました

マイクロコムさんメールニュースにて、「pfTrackユーザー事例」として掲載させてもらいました。
-----------------------------------------------------------------------
-------------------------------------------------------------
【ニュース】PFTrack ユーザー事例
-------------------------------------------------------------

配置されたモニターの中で踊り続ける人影、青い空間を移動
すると倦怠感のある美女が電話で罵倒している映像が・・・
「SickeTel」はどこか虚無をたたえた世界観を表現した
“キュピキュピ”の映像パフォーマンス作品である。

ギャラクシー・オブ・テラーのVFXアーティスト寺岡氏は
この「SickeTel」の合成シーンを担当している。

「夜間の撮影だったり、ハイスピードカメラを用いていたため、
特異点が検出しづらいことや、素材がノイジーであったりもしましたが、
PFTrackにより難なくトラッキングを行うことが出来ました。」


作品の中には演者が車のガラスを突き破るシーンがある。

「非常によく出来たマネキンを用いて撮影しました。PFTrackの
機能の一つである「ジオメトリトラック」を用い、素体から
頭部のモデルを切り出して.obj形式で PFTrackに持ち込みました。
Pinモードでオブジェクトデータの位置や大きさを合わせ、あとは
トラッキングボタンを押せば自動的にトラッキングできます。
シンプルな操作に加えてその精度の良さにも驚きました。」

「SickeTel」のメイキングムービー
http://microcom.jp/Download/SicketelMaking.mp4


PFTrackは2011からノードベースのインタフェースになっている。

「ノードベースになったことで複雑にマニュアルトラックの組み合わせが
必要なショットも容易に対応できると思います。
ノードベースになって、手順が分かりやすくなったこと、トライアンド
エラーが格段にやりやすくなりました。」

ギャラクシー・オブ・テラー
寺岡昌広氏

“キュピキュピ”は、テレビ番組『オー！マイキー』で知られる
石橋義正を中心とした映像＆パフォーマンス・ユニット。



ノードベースの3Dマッチムーブ・トラッキングソフトウェア
PFTrackは高度なトラッキング技術で実写と3DCG合成シーンに
大きな力を発揮します
http://microcom.jp/product/thepixelfarm/#pixelfarm


PFTrack、PFMatchitのお問い合わせは
toiawase@microcom.jp まで
-----------------------------------------------------------------------

実際やってみると「目」というのは少しでも角度が違ったり、場所が違うと、かなりずれてるように感じられ、ぴったりとトラッキングされていないとうまくなじまないということがわかりました。
また、演者素材はメイクを肌にしており、撮影香盤上、少しメイクが溶けていたりとかで、マネキンとのなじませはnukeがかなり活躍しました。

clean up プレートの作成

実写撮影素材を用いてコンプを行っていると、その撮影素材に映っているモノを消さないといけないという状況にしばし遭遇する。

塗りつぶしたりできるような場合であれば、トラッキングしてマスク作って塗りつぶして・・・　とかでできたりするのであるが、そうもいかない場合もある。

たとえば、

(※このムービーは　http://www.hollywoodcamerawork.us/trackingplates.html　より許可を得て使用させてもらっております)

このムービーの手前のおそらくトラッキング用に立てられたであろうマーカーを消しこむ必要があるとしよう。残念なことに、このムービーは手持ちでカメラが動いている。実は、パンやチルトのようないわゆるノーダルと呼ばれる動きであれば、このマーカーと背景の関係は変わらない。球体にマッピングされたものを、その中から「首の振り」だけの動きで撮影しているのと同じである。カメラトラッキングさえできてしまえば、割と消しこむのは容易な部類に入ると思う。
ただ、このムービーのように、ノーダルでなく、カメラが手持ちで動いていると、マーカーと背景の位置関係は絶えず変わり、地面のパースも変化していき、いろいろと厄介である。 Imagineer Systems社のmokeyなどを用いるとペコっと消えてしまう場合もあるのだけど、今回はnukeを用いて、clean upを行う手法を紹介したいと思う。

こういうclean upは3Dトラッキングを行いカメラアニメーションを取得し、cardなどのジオメトリに一枚消しこんだ画像（静止画）をプロジェクションして、それをそのトラッキングして得られるカメラから撮影（レンダリング）して、それをマーカー部分に重ねるとうまくいく場合が多い。
ただ、この撮影素材の厄介なところは地面の芝生が平面もしくは、それに近いものでないことである。
多少の起伏があるので、それをうまくマーカーのたて看板の上から重ねても、全フレームでうまくは合わない。

手法としては、たとえば、50f目 での地面の芝生部分を基準として、

同じ位置の比較的50f目から変化の少ない別フレームの画像（下記は70f目）を

パースを合わせて上から被せる。「比較的50f目から変化の少ない別フレーム」ってのは要するに、50f目の近傍になるであろう。ただし、近すぎると、その位置から、マーカーがまだ「行き過ぎていない」ってこともあり得る。
で、この「パースを合わせて」ってのは、3Dトラッキングを行いカメラアニメーションを取得し、大体、地面と思しきあたりに、地面と大体パースを合わせて回転などを掛けcardを置いて（point cloudなどから推測）、そのcardにProject3Dノードを用いて用いて投影する。投影するのだが、同じフレームを同じカメラアングルから投影し、同じフレームで撮影しても結果は同じモノを得るだけなので、今回は合成時のロトのボケ足を含めた、マーカーの移動分が大体20ｆだったので、20fずらした画を、20fずらしたカメラからプロジェクションして、それをscanlineRenderを介して、トラッキングしたカメラでレンダリングする。
 

 トラッキングが正確で、投影を受けるジオメトリが正しければ、理論的には20fずらしても、そのジオメトリの任意の位置における投影されるピクセルは同じピクセルが投影されるはずである。 言い換えれば、正しい位置から、正しいジオメトリに、正しい画を投影すれば、その画を別アングルからレンダリングしても、そのアングルから見た画が来てるはずということである。ただし、今回の場合、ジオメトリの形状が単一でないことや、マーカーの位置等の問題で、そこまではうまくはいかないので、割と近いフレームで変化の少ない画をそのアングルから投影するとこでそれを回避している。

上の画で20f遅らせたカメラというのは、エクスプレッションを用いて調整している。以前にも説明したが、nukeの場合アニメーションをつけるとエクスプレッションに「curve」というものがはいる。で、エクスプレッションでたとえば、

curve(100)

とすると、そのカーブの100f目の値という意味になる。また、

curve(frame)

とすると、現在のフレーム数での値を返す。要するにこれは「curve」と変わらないのだけど、たとえば、

curve(frame + 20)

とすると、現在のフレームから20フレーム先の値のを返してくれる。で、さらに、「+20」で上手くいくかどうかはわからないので、調整しやすいように、この「+20」にあたる部分を「user knob」で再定義できるものにしておく。具体的には、プロパティー上で右クリックし「Manege Usetr knob...」で「Add」>「Floating Point Slider」でUserタブに新たに数値を入力できるようにする。

今回はトラッキングして得たカメラの位置と回転のアニメーションをこれを用いて20fずらす。
位置と回転のカーブに対して、

curve( frame + [python nuke.thisNode().knob('offset').value()] )

こんなふうに、+20 に相当する部分を

[python nuke.thisNode().knob('offset').value()]

としてやる。基本的にエクスプレッションはtclスクリプトという記述方法にのっとっているが、

[python hoge～～～]

でpythonを用いることが出来る。こうすることで、「+20」部分の調整が楽になる。
同じく、「20f分遅れた画像」を処理するのはTimewarpノードだ。Timewarpノードは作成した時点で、デフォルトでそのシーンの最初と終わりにキーフレームが打たれており、すでに「curve」を持っている。なので、その「curve」を同様に調整する。

curve(frame+[python nuke.toNode('Projection_CameraA').knob('offset').value()])

 さっきは、同じノード内の別knobだったので「nuke.thisNode().knob('offset')」だったが、今回は、別ノードのアクセスするため、「nuke.toNode('Projection_CameraA').knob('offset')」としている。

オリジナルの画と比べてみると・・・

となる。重ねて「差分」を見てみる。

となり、ぴったりきている。これで、現在のフレームで 

マーカーの位置で隠れていた地面芝生の画像

を取得することができた。
あとは、これを、マーカーのマスクを作成して、元の画の上から被せる。

マーカーのマスクの作成には、6.3から搭載されたplanar trackerを用いてみる。
planer trackerは非常に簡単で楽チン！
とりあえず、rotoノードなどでマーカーの形に沿ったベジェマスクを作成。

 で、次に、そのそのベジェを選んで、右クリックで「planar track this shape」でplanar trackingを開始。今回は「fwd」で前進フレーム側へトラックさせた。

すると、自動的にトラッキングが始まり、ちゃんと見切れるまでトラッキングしてくれる。この見切れるまでってのが地味に便利だと思う。

planar trackingを行うと、自動で、PlanarTrackerノードがぶら下がる。

で、あとは、ちょっとしたズレなどを、ベジェの頂点で修正したり、ボケ足をつけたりすれば、簡単にマスクが取得できる。

プロジェクションの都合で、今回の場合は、どうしても下位置で見切れが発生したが、そういうものを調整して完成。

ちなみに、こちらがオリジナル。

 下位置の見切れは次回説明します！
しかし、画質悪いですね・・・

Gradeノードのtips

Gradeノードは説明したけど、去年の夏にやったnuke勉強会で、ボクの尊敬する 腕利きコンパーの人　に教えてもらった超便利技。

ホワイトバランスなどがちゃんととれてない画があるとして

こんな感じでアンバーによった素材。
これにGradeノードを使って・・・

こんな感じで画像の白だと思われるところと黒だと思われるところをそれぞれ、whitepointのカラー、blackpointのカラーへドラッグアンドドロップ。
すると

こんな感じで色合いが補正される。

これを応用して、こいつに例の如くアイツを合成するとして

同じくGradeノードを使って、下画から whitepoint と　blackpoint　をピックしてやり、

reverseのチェックを入れてやると、アイツの色が下画になじむ。

アニメーションのtips

アニメーションのちょこっとしたtipsを。

Propertyペーンでアニメーションをコピーする際は、値の部分で右クリックしてメニューたどってコピーして、ペーストしたいところで同じようにして・・・　って出来るけど、割とめんどくさい。
そんなときは、値の横にあるグラフっぽいアイコンの上でshift+ドラッグアンドドロップで、ペーストしたい同じところへもってけばOK。

もう一つ。DopeSheetでキーフレームを数値入力でシフトさせたい場合は、そのキーを選んで、下に数値を入力するボックスがあるのでそこにシフトさせたい数値いれて、横の"Move"を押せばOK。

(un)premult チェック

以前CGWorld.jpで紹介した山口さんが勉強会でおっしゃっていた　unpremultノード　ですが・・・

 こんな感じで、premultiplyされたモノを色をいじるとエッジ部分に不具合が出てしまうケースがあります。この場合、下画（この場合グレー）とあわせる前にblackpointを下げてます。でover で重ねてますが、overの計算式

output = A + B*(1-Aa)

でAa、つまりAのアルファが1の部分ではAが完全な不透明でBは関係がなくなります。Aaが0の部分、つまりAのアルファが0で完全に透明の部分ではA+Bとなり、基本的にその部分では(r,g,b)=(0,0,0)のはずなので実質Bが前面に出てきます。
問題は半透明部分である0の部分です。要するにアンチ部分だったりするのですが・・・
premultiplyは自ずと下画が黒としてアルファをあらかじめ乗算するので、本来の色よりも暗くなっています。でこの部分に色調整が入ると通常はrgbのみが処理されるので、既にアルファ値にしたがって乗算された色が調整をさらに調整することになり、その乗算分強めに処理されてしまいます。なので、黒ずんだり、エッジ部分でルミナンスが落ちずに明るくなりすぎでエッジがガビガビになったりします。

これを避けるために、premultiplyされたを一旦 unpremult ノードでアルファ分を戻してやり（実際にはアルファ値で割り算）premultiplyが無い状態にします。ただアルファ値としては半透明のきれいなエッジのアルファをもっているので unpremultノードで処理したものに、色調整し、もう一度Premultノードを用いてアルファをpremultiplyしてやります。premultiplyされてアルファを考慮した画像ではなく、rgbとaを切り離しって考え方ですね。

ただ、いつのバージョンからか　(un)premult by のチェックボックスが付属していて、この二つのノードを用いなくても、ほぼ同様の結果を得ることが出来るようになりました。

ただ、コンプは通常NodeGraphをみたら大体把握できるのが理想なので、チェックボックスよりもこの2つのノードを挟んだ方が分かりやすいですよね・・・　このあたりはそのスタジオごとのルールでしょうか・・・

注意：premultiply画像はアルファを乗算してるので、その係数に変化をもたらしてしまうようなblackpoint、whitepoint、lift、gain、multiply、gammaはそれでいけるのですが、offsetは単純にプラスマイナスし係数に変化がないので、ちょっと違います・・・　このあたり面倒です・・・