株式会社ヘキサドライブ | HEXADRIVE

お久しぶりです。
昨日のブログにおでこと腕だけ写真掲載されました、
隠れた太陽good sunこと山口です。
前回、リニアワークフローに触れた事を切っ掛けに自身の勉強の為と思い立ち、
ノードベースのコンポジットソフト作成を始めてみました。
今回はこの勉強を踏まえてリニアワークフローの話をしたいと思います。
OpenEXRのサンプルの写真データを使って単純な合成テストをしてみました。
この.exrに格納されているデータはリニアなデータになっている為、
プレビュー等で画面出力するときにはディスプレイの逆ガンマ補正をしないと、
↓の様に大きく見た目が異なって見えます。


微妙な光の減衰等が消えてしまって見えますね。
リニアではないワークフローでは、
各ノード毎に正しく見える明るさにガンマ補正してその補正したデータ同士を合成することになります。
つまり逆ガンマによって上向きのカーブに底上げされた状態になります。

ディスプレイ上では正しく見える画像でも実際のデータでは底上げされている為、
この画像同士を直接加算合成などすれば、必要以上に明るくなってしまいます。
3Dでのシェーディングにおいてもこの部分は非常に重要な要素になっています。
リニアでないテクスチャに対してライティングを行った結果は、
当然求める結果とは異なった情報となってしまいます。
これにはアルベドマップにシェーディング結果が入り込んでいてもNGです。
今月のCGWORLDのコナミさんの記事でテクスチャの作り方が紹介されていますが、凄く徹底されています。
さて話はコンポジットに戻りまして、
リニア対応ついでにレンジも8bitではなく32bit浮動小数に変更してみました。
これによって従来のPhotoshop等で使われている合成の処理の一部は破綻してしまう事が分かりました。
例えばスクリーン合成がそれにあたります。
スクリーン合成の計算は以下のようになっています。
1.0 – (1.0 – src1) * (1.0 – src2)
このため入力値に1.0以上の値を設定すると、
計算結果がマイナスとなってしまい、
想定とは違う結果になってしまいます。

リニア化する事によってスクリーンでは無く、
加算を利用することで程よく明るくなる合成が出来るようになっています。
さらに当たり前ですが、地味にうれしい効果として1.0をオーバーフローした後に減算しても劣化しません。
従来の8bitデータでは255が上限値となる為、
オーバーフローした値はクランプされてしまい、
そこから値を減算した場合は
残念な感じに情報が失われてしまいます。

このような画像に対して、減算を行うと

このように劣化してしまいますが、
32bitデータだと

このように劣化はありません。
光線等の合成後の色味調整等で絶大な効果を発揮しそうです。
と、まだまだ浅い勉強過程ではありますが、
ノンリニアワークフローでのコンポジットの魅力の一部を紹介させて頂きました。
実際に作ってみると単純な合成だけでも処理負荷が高く、
市販ソフトで1フレームあたりがとても高速なのには改めて感服させられます。
まだまだOpenCLやパラレル化でパフォーマンスの向上も目指していきたいと思います。
このような事もWebCLといった仕様が策定されていたりするため、
将来的にはWeb上のツールでもコンポジットが出来る時代が来るかもしれないですね。
ではまた 。