ZDefocus #2

続き

では何が、zdefocusを遅くしているのか？ 簡単にいうと、それは、”差”である。depthの値の差がzdefocusを鈍重にする。”差”と言っても、よくわからないと思うので、実例を示してみよう。

こんな感じでアルファでくり抜かれた画像と、同じアルファでくり抜いたdepthを準備した(2枚目はdepth)。これを、

depth値=50,size=1,focus plane(C)=0

でzdefocusで処理すると、

こんな感じで、このlaptopで30秒以上掛かってしまいます。しかも結果としても、境界がシャープになってしまっている、おかしな結果になっています。 

次に、depthをmaskで抜かずに画面一面を同じ値にしてみます。

2枚目はdepthです。一面同じ値かどうかは分かりにくですが、一面同じ値で、くり抜かれてません。

と、こんな感じで、とても速い処理が行われます。

結果も境界がちゃんとボケていて良好に見えます。

なぜ、こうなるのか？

それは、前者(遅い方)のdepthがくり抜かれており、そこで、くり抜かれてるところ(depth値0)とくり抜かれていないところ(depth値50)で、depthの値の差が出来るためです。加えてzdefocusは(くり抜かれた)境界部分で起こるボケで境界が外に押し出される(フェードアウトしているので実際の値ほどは押し出されてるように感じない)が、押し出された先に適当なdepthの値が無いために、前者のような境界がシャープなままの結果を生み出してしまいます。
このケースだと、depth値0とdepth値50の"差"が引き起こす遅さということになります。正確には、depth値0とdepth値50とsize1でボケの"差"が生じるためのでしょうか。

境界に関しては、実際にコンプしている場合だと、depthの境界をエキステンドします。これをしないと今回のように境界がくっきりしたり、エッジにハロと呼ばれる、ダブりイメージのようなものを得てしまったり。ボケることで、境界部分が50ピクセル外に拡張されるのでれば、50ピクセル外にdepthが必要になります。その時のdepthの値は、そのボケを生み出すに適切なdepth値となります。なので、depthの境界をエキステンドすることになります。

また、例として、くり抜いてないdepthでかつ、depthにグラデーションがついてる場合も、やはり"差"があるので、遅くなります。

 depthに使用しているrampは0-1で、zdefocus側でsize=50,focus plane(C)=0としています。

また、今度はrampノードの下にmultiplyノードをぶら下げて、depth値を50倍、なのでdepthは0-50のグラデーションということになります。で、zdefocus側でsize=1,focus plane(C)=0として、depthの掛かり方的には同じ結果になるようにしてみます。

 処理時間の結果としては、ほぼ同じであると思われます。得れる、見た目の結果も同じであると思われます。

※動画の最初がもたついているのは、zdefocusのせいではなく、quicktimeでキャプチャーを作るために、ボクの操作のもたつきです。

いずれにしても、グラデーションがもたらす"差"でも、やはり遅いです。

ちなみに、"差"が極端に狭いところであったとしても、ほぼほぼ画面一面、等しい値だけど、とても小さいエリアで値の変化があったとしてら？しかも、そこのアルファチャンネルの値が0でくり抜かれている部分だったとしたら？
残念ながら、これでも遅いままです。差が最終的なボケのサイズ換算で、30％ぐらいまでの差であれば、まだ若干はマシなのですが、50％ぐらいの差が出てしまうと極端に遅くなります。

 では、zdefocusの処理を速くするためにはどうすれば良いのか？

また次回に。