2009年10月アーカイブ

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

前回までの話で32bpcメリットについてざっと話しましたが、これは32bitだからというよりもfloat(浮動小数点)であるということ、そしてオーバーレンジをデータ的に保持できることが重要であって「階調飛びを防止する」という目的ではありません。
16bitで作業をしても出力時に8bitあるいは10bitに落とす以上、階調の量子化は避けられないことで、これをうまく補間して階調飛びを回避するのはソフトウェアの16bit->8bitへのコンバートが優れているということで、これを利用するために16bitで合成しているだけです。(これは直接的な映像の品質管理の問題ではなく、対症療法でしかありません)
極論では8bitで合成しても解決可能な問題です。

ここでは、最終的には8bitまたは10bitで出力するのに、16bitでなく敢えて32bpcでコンポジット作業を行なうメリットに絞ります。

これまで便宜的に「32bpc = オーバーレンジが使える」と書いてきましたが、実はファイルフォーマットとしては、オーバーレンジを扱うための必ずしも32bitである必要はありません。前回も書きましたが、Cineonは10bit整数でオーバーレンジを扱っていますし、DPXでは10bit/12bit/16bitに拡張されています。またOpenEXRは16bit floatを使用しています。(32bitにも対応)
AfterEffectsでのコンポジット作業にfloat(浮動小数点)のオーバーレンジを扱うにはプロジェクトで32bpcを設定する必要があるということです。

下の参考画像はOpenEXRのデータで露出を下げた例です。32bpcでは元画像の白飛びしている部分にオーバーレンジとして保持されていた階調が見えています。
doc_17754_img01.png

オーバーレンジで得られるメリットは前回書いた通り、白以上/黒以下でも階調を保持する点にあります。

しかし、実際作業で使用するフッテージの多くは8bitであり、これらに関してコンポジッタが直接的に16bit/32bit化を要望しても、Photoshopでは16bit,32bitと色深度が上がるにつれ使用できる機能が減ってしまい、32bitになると多くのエフェクト/色調補正の機能が使用できなくなるなどデメリットがメリットを上回ります。
アニメの場合は、r3dファイルのようにカメラから出力されたデータを扱うことも(ほとんど)ありません。素材が8bit整数である以上、それら素材作成時に生じていたオーバーレンジのデータは白または黒としてデータが破棄されていますので、上の例のようにレベルや露出に補正によるディテールの再現は期待できません。

全然先に進まなかった。以下次回に続く。

My Latest Video

Powered by Movable Type 4.25