Rolling Shutter - その2

FoundryのRolling Shutterを試用してみました。(AE版)
レンダリング待ちの時間にmac miniで試したので動作は軽快とは言いがたいのですが、MacProであれば問題なさそうな範囲。前後フレームを参照するようなのでマルチコア/プロセッサによる分散レンダリングは不可。
(訂正)マルチコアの分散レンダリング機能してました。

Rolling Shutterプラグイン自体はモーション補完技術を使っているようで、技術的には特に目新しいものはありません。

rs_001.png
(上が未使用の状態、下がRollingShutter適用)

上の例は比較的良好な結果が得られたフレーム。車窓から並走する車をハンドヘルドで撮るという、RollingShutterの問題提起ためのような映像ですが、少しパラメータを追いこんでやるとかなり自然に見えてきます。縦方向の変形も気になりません。

...が、少し細かく見ていくと、やはりおかしなことも見えてきます。

rs_002.png

手ぶれなどの不規則な動きや、背景などのボケた部分とシャープな部分の境界、ガラス面への映り込みなどのコントラストの弱い部分は要注意。
使うにしても、事前に綿密なテストをしないと駄目っぽいですね。

実際に使うのは来年だから、時間ができたらもう少しテストしてみます。

Smoke on Mac

twitterでも書きましたが(→)、InterBEEでSmoke 2010のMac版が発表される模様。
気になるお値段はソフトウェアのみで$15,000.00。そしてさらに気になるのは「Flameは? Flareは? Toxic?!なんだっけそれ?」...ということでしょう。


そういえばFireってなくなったんでしたっけ?

(追記) FireはSmokeに統合されてました。→Autodesk Fire

Rolling Shutter

CMOSセンサのSkewの問題ですが、一見問題ないような画でも確実にSkewは発生しているので、mokeyでトラックかけてみると相当な斜め方向の変形を確認できます。単純なフィックスでパンフォーカスのカットでも、実際に合成作業をするには不都合なほどにかかってます。
というわけで、TheFoundryのRolling Shutterプラグインを買おうか悩み中。

mokeyのレンズディストーションで修正できるかな?時間ないので試してませんが、一回やってみる価値はありそう。

参考:EX1のSkewテスト[dvinfo.net]
色深度の話、その3です。今回で色深度については一区切りの予定。

前回の話でフッテージが8bitである場合には、オーバーレンジによる明部、暗部のディテール再現を期待できないと書きました。
しかし、コンポジット、VFXの作業では様々なシーンにおいてピクセルを合成して計算する過程が存在します。そのような場合にはオーバーレンジを使うことで16bit整数の色深度では得られないメリットが受けられ、これが32bpcでコンポジットを行う最大の利点でもあります。

以下実例。
黒い背景の上に白い星の平面(シェイプレイヤー)を置き、その上に色のついた一回り小さい星のレイヤーを重ねます。このとき小さい星は完全に下の白い星の内側に入っています。
7715__0003_1.jpg

星のレイヤーをすべて加算で合成します。白い星は1.0の完全な白色ですので、当然ながらすべての色は白になります。
7715__0002_2.jpg

次にこれにブラーをかけます。(ここではS_Blur/360pxを調整レイヤーでかけています。プリコンポーズしてからかけても同じ結果が得られます。)

16bpcの場合
7715__0001_3.jpg

32bpcの場合
7715__0000_4.jpg

このブラー処理によって、32bpcと16bpcでは明確な差がでます。白い星の上に重ねられた色の付いた星は、画面上は白になっていますが、32bpcでは1.0+のオーバーレンジにデータを保持しています。これらが周辺の黒のピクセルと合成されることで、色の差として現れます。

フッテージ素材が8bitであっても、処理の結果にはこのような差が生じますので、素材自体は8bitのままでも、コンポジット作業時にこのような変化を期待することができます。

注意点としては、このような変化を期待するためにはエフェクトプラグインも32bpcに対応している必要があるということです。32bitに対応していないプラグインを使用した場合には、そのエフェクトが適用された時点でオーバーレンジのデータが破棄されてしまい、エフェクトの順番によって結果が大きくことなる可能性があります。

例えばAE付属の「カラーバランス」は32bpcに対応していません。例えパラメータをいじらなくても、このエフェクトを通過した時点でデータはオーバーレンジ分のデータを失ってますので、それにブラーをかけても上の例のように青い色を保持していません。ブラーをかけた後に、「カラーバランス」を適用すれば、オーバーレンジの色を取り込んだ上に「カラーバランス」を適用することができます(が、この時点でオーバーレンジはやはり失ってます)。

今回提示した例はわかりやすくブラーをかけていますが、このような特性はピクセル同士の計算時(レイヤーのトランスフォームや合成時)には常に機能します。
このようにオーバーレンジを扱うことができるのが32bpcの最大のメリットであり、必ずしも素材が作成されていなくてもコンポジットの作業時に利用することができます。
ただし出力は10bitまたは8bitですので、これらの機能を使って出力画像のダイナミックレンジを増やして、バンディングを除去することが目的ではありません。むしろ32bpcでの作業ではバンディングは発生しやすくなる傾向にあります。

とりあえず色深度のお話はここまでです。また次回。

最近、NucleoのBackground Renderの調子が悪くて難儀してたんです。レンダリングが正常に終了せず、キューが残ったまま止まってるという状態。いつもなるわけではないけど、かなり高確率で発生するというもの。
原因もよくわからなかったんで、バッチレンダーに切り替えてたんですが、どうやらSapphireが原因だったみたいで、アップデータが出ました。バッチレンダーでもいいんですけど、QuickTimeでも連番でもマルチプロッサでガリガリレンダリングしてくれるので便利なんです。

My Latest Video

flickr

www.flickr.com
Powered by Movable Type 4.25