2013年8月19日月曜日

VFXワークフロー LogToLin

協力:株式会社ロゴスコープ http://www.facebook.com/Logoscope.Ltd 
現在、Logoscopeでは映像制作における撮影・編集・VFX・上映に関するワークフロー構築及びコンサルティングを絶賛募集中だそうです(2013.8.19)

Nukeに「LogToLin」というノードがあります。僕はあまり馴染みのない種類の画像処理で、使い所がよく分からなかったのですがシーンリニアワークフローの導入に伴い、最近使う機会が増えてきたので、どのような時に扱っているのかを紹介したいと思います。ただし、非常に難しい部分でもあり、ブログの記事として掲載するのはかなり躊躇する部分でもあります。何より、僕がしっかり理解していません。おかしな点やその他事例など教えて頂けるとありがたいです。

「yamagishi 2bit-Blog」というタイトルなのに「10bit cineon-log」と本家の話になってしまいますね。10bit恐れ多いです。

LogToLinについて
シーンリニアの画像をLogに変換したり、Logの画像をシーンリニアに変換する際に使用します。




VFX制作でLogといった場合、一般的にはCineonLogの事を言っている事が多いようです。NukeのLogToLin系ノードのデフォルト設定もCineonLogに設定されているようです。
 
「Colorspace」「Log2Lin」「OCIOLogConvert」どれで変換しても全く同じ結果になる。
場合によって違いが出てくる事があります。後ほど触れます。


3dsMAXで.cinで保存する際のデフォルト設定も同じですね。

最近ではカメラメーカー毎に様々なLogを準備していたりするので「Log」という単語やワークフローにおける扱いでも注意が出てきています。

アーティスト向けの内容ではないですがこちらでも触れていますね。

AREA JAPAN カラーマガジン

AREA JAPAN 第3回:CineonとOpenEXRカラースペース

AREA JAPAN 第6回:異なるイメージステートのイメージビューイングとログからリニアへの変換

では、どのように普段扱っているかいくつか例を挙げていきます。

1.シーンリニア画像をトーンカーブで調整する際(特に暗部の微調整が多い時)

シーンリニアの画像をトーンカーブで調整する際に、 画像のトーンによっては調整しづらい事があります。ナイトシーンの微調整とか、非常に大変なのではないでしょうか?また、シーンリニアに移行してまだ慣れていない時など、トーンカーブが扱いづらく感じる事があるかと思います。シーンリニアにおけるチャートを想定したグレースケールとカーブの関係を見てみます。

シーンリニアにおけるチャートとカーブの関係

このように、左に偏っているのが分かると思います。右から2番目以降のグレーは0.5以下に集中しています。結構な領域が0.5以下にあるのが分かると思います。グレースケールの見た目とカーブの関係も、なんか直感的ではないですよね。

結果、暗部を調整しようとした際に左側のほんの一部で調整する事になります。Nukeではカーブのの拡大縮小が行えるのでまだいいのですが、AE等の場合はかなり苦労してしまいます。「AEはシーンリニアコンポジット向いていない」というような事をたまに口にするのですが、その理由の1つです。
さらに、中間色と言われているグレーと比較してみるとこんな感じです。
相当左によってますね。領域が狭い狭い。
そこで、LogToLin。トーンカーブで調整を行う際はLogスペースで行うようにします。そうすることで、使いやすさが増した印象を受けると思います。
シーンリニアの画像を「Lin2Log」でcineonLogに変換。
その後、トーンカーブで調整して調整が終わったら「Log2Lin」でシーンリニアに戻す。

CineonLogでは均一に近い状態になる。中間色のグレーも大体真ん中に来てますね。

赤い部分0.0-1.0の外の領域になります。マイナス値とHDR。

NukeのGradeノードなどの一部のスライダが均一ではないのはそういった理由があるのかもしれませんね。

CineonLogは仕様上、扱いに注意する点があります。情報が劣化したり欠落する場合がある事に注意して下さい(主にマイナス値やHDR)。お勧めの方法は、Logの変わりに最も慣れているであろうsRGBやGamma2.2に「colorspace」ノードで変換して対応するのがいいかもしれません。
方法は色々ありますが、例えば「colorspace」ノードで変換。
緑の部分のin、outは同じであれば考慮されないのでこの場合は同じであればなんでもよい。
なかなかいい感じの配分になりますね。0と1の位置も変わらないので扱いやすいのではないでしょうか?
話しはそれますが、一番左側の黒は数値でいうと0.035くらい。(チャートの黒色を想定)反射率だと3.5%なのですが、0まで結構な領域がありますね。この部分、人間の目はまだ明度の違いに敏感です。「0黒使うな」とか、合成の際に「ブラックポイントをきちんと合わせなさい」と言われる理由の1つではないでしょうか?
「スクリーンでは気にならなかったのにTVだとCGが浮いて観える」と言われる1つの理由だと個人的には思ってます。
今度、機会があれば実験してみたいですね。

 例えば、標準設定のAEでRGBの数値が5と6の黒を並べて配置します。
全体をガンマでカラコレするとその違いが目立ってきます。(表示環境によっては違いが分かりづらいかもです)
わずか1の差でも、場合によっては目だってしまうという事ですね。恐ろしいっす。

【LogToLin使用上の注意】

CineonLogではblack-point、white-pointを定義します。

「10bit=1024の諧調の0.0黒を95。1.0の白を685にします。」みたいな感じです。これにより、ある程度のマイナスの値とHDRを扱う事が出来ます。
Nukeのデフォルト設定のCineon。ある程度より暗い領域をマイナス値として使用しているのが分かりますかね。

説明が大変なので文章だけで失礼しますが・・・。こんな事が起きる可能性があるということですね。

1.シーンリニアの画像をcineonLogに変換した。この時点でシーンリニアで0.0の黒は約0.09位になります。

2.カラコレで暗部を落とした。0.09の数値が例えば0.05とかになったとします。

3.それを再びシーンリニアに戻します。 結果、0.05だった値が約-0.03になります。

こんな感じでマイナス値が発生してしまいました。さて、このマイナス値、どうしましょう・・・・。同様の事がHDR、1.0以上の値でも言えます。CG素材などαを持っている場合はどのように対応しましょうか?正しい対応がなかなか難しいですね。
また、過去に僕が関わった案件では、別部署でカラコレされた画像をcineonLogで頂き、シーンリニアに展開したらマイナス値が発生していた。というような事もありました。おそらく、上のような理由だとは思うのですが、どのようなワークフローが適していたか、今でもよく分かりません。

さて、NukeでのLogToLinですがノードごと特徴が異なるので、違いを見てみましょう。HDRとマイナス値の変化についてです。

「Colorspace」ノードの結果
「Log2Lin」の結果

「OCIO LogConvert」の結果
ちなみに、Nukeでピクセルの値が「inf」と表示されているところからexrで出力した場合、そこのピクセルの数値は「inf」となります。(似たような現象として、Nukeは32bit floating pointでデータを扱いますが、保存先となるexrの保存形式を16bit half floatにした場合、16bit fpで扱えるデータの範囲が-32767.0~32767.0くらいまでなので、それを超える範囲は同じく「inf」となります。これは3DCGソフトからレンダリング結果を出力する際も同じようです)

2.シーンリニアで特定のフィルタで問題が起きる際等に

シャープフィルタを例にします。これは、Cinematic Color(http://cinematiccolor.com/)にて紹介されています。 一部のフィルタをシーンリニアで適用した場合、思わぬ事が起きることがあります。例えばシャープフィルタですが、強い輝度を持つHDRがあった場合、効果がかかりすぎる事があったりします。

シーンリニアの画像で非常に強い値の数値を持つピクセルがあったとします。(右側のハイライト)

その画像にシャープフィルタを適用。ハイライトの周りに黒いエッジが発生してしまった。

そこで一度Logに変換してシャープフィルタを適用する事で、その現象を抑える事が出来る。
このような感じで、シーンリニアでの環境で思わぬ現象が起きた際の解決策として「LogToLin」 を使う事が出来ます。

【シャープフィルタについて】
整数の環境ではマイナス値はクランプされるため、さほど問題にならなかったシャープフィルタですが、32bit fpではマイナス値が発生する事があるため、問題となる事があります。ただし、これを利用するテクニックもあるので、一概に駄目とは言えない所が難しいですね。マイナス値が発生した場合には正しい対応が出来ることが望ましいです。
Photoshop「フィルタ」→「カスタム」
Photoshopは32bit fpにすると「シャープフィルタ」や「カスタムフィルタ」を使えなくしていますね(CS6)
マイナス値回避の目的などもあるのでしょうか?
CGソフトのレンダリング時のアンチエイリアエシングの中にもマイナス値が発生するものがあります。
シャープな仕上がりになるものはマイナス値が発生する可能性が高いと思っておきましょう。
それらをexrなどで保存した場合、マイナス値を持つデータが出来る場合がるので、扱いに注意しましょう。
Nukeのシャープフィルタ。画像の輪郭部分の数値がマイナスになっている。
AEでも同じ現象を確認出来ました。
また、拡大縮小などの画像処理の際に用いられるフィルタの中にもマイナス値が発生するタイプがある。
図はNukeのfilter「Keys」。シャープな結果を得る事が出来るが、マイナス値が発生することがある。Transform、reformatなど様々なところに登場。

3.カラコレ情報の共有(Lutの使用

現在、VFX制作現場で採用されるLUTファイルの中には0.0-1.0までの情報しか扱えないものがあります。このLUTファイルを画像に適用した場合、1.0以上の情報はクランプされてしまう場合があります。扱いには注意が必要です。僕の経験では、今まで扱った事があるLUTの殆どは0.0-1.0しか扱えないタイプのものでした。

カーブのカラコレ情報を代表的な1D-LUTで出力
 
それを読み込んでみると、0.0-1.0までの情報しか対応していないのが分かる

そのため、HDRが考慮されないのですが、1つの解決策としてシーンリニアの画像をLogに変換することで、画像の諧調を0.0-1.0に納める事が出来ます。そしてLogスペースでカラコレすることで、ある程度のHDRに対応したLUTファイルを作成する事が出来ます。また、詳しくないのですが現状Davinci等のカラコレはシーンリニアで行われていないのではないでしょうか?ほとんどがcineonLogで行われているのではないかと思います。それらソフトや部署間でカラコレ情報を共有したい際などに、logスペースでカラコレ情報を共有する事が非常に役に立ちます。

Kodakのテスト画像(シーンリニア)の女性の髪のハイライト部分
白飛びして見えるがデータ的には約2.0と強い値を持っている

カラコレを行い(左)、代表的な3D-LUTでカラコレ情報を出力
3D-LUTを用いてカラコレを再現(右)HDRのカラコレ情報が失われている。

(NUKEで画像作成したのですが、いい具合に補完処理してくれているようで結果が分かりづらいですね。
v7.0からなにか仕様が変わったのでしょうか?前はクランプされてたような気がしたのですが。
でも髪の毛のハイライト部分のカラコレ情報が損なわれているのが分かるかと思います)



 そこで、Logスペースでカラコレを行う事で、ある程度のHDRのカラコレに対応した3D-LUTを出力出来る。

右の方法のように直接画像に適用してしまうと失われてしまう情報があるので、
実際の運用の際はVIEWLUTとして使用するなど注意が必要。

同じ方法でV-ray framebufferでHDRに対応した3D-LUTを読み込めます。V-Rayは.cubeに対応しているので、Logスペースで行ったカラコレ情報を.cube形式で出力。

LUTを読み込む部分に「Convert to log space before applying LUT」とという部分があるのでチェックを入れる。
ここでいうlog=cineonLog。これで、シーンリニアのレンダリング結果に対して、HDRにも対応したカラコレ情報を仮想フレームバッファで共有する事が出来る。これにより、最終出力を先回りで確認する事が出来たりするので、非常に便利ですね。これからは使う機会が減るかもしれませんが、フィルムエミュレーターとして使用したりとか。
ちなみにですが、HDRに対応したLUT形式としてShaper LUT(.csp)などがあります。これもCinematic Color(http://cinematiccolor.com/)で少し紹介されています。僕が知っている所ではMAYAの仮想フレームバッファなどが対応しています。今後主流となっていくのでしょうかね?
また、他の解決策としてACESを使うというのもありそうです。ACESはRRTを適用する事で0.0-1.0にトーンマップされるという特性があります(OCES)。

たまに、海外にグレーディングを発注するような話しを聞くのですが、その際のDPXの中身ってどうなってるんですかね?「8bitのRec709で編集したデータをDPXで渡してる」とかだと、あまりDPXの意味がない気がするんですが謎です。

画像処理の基礎知識、大事ですね。
Nukeはノードの色が画像処理の系統ごとに色分けされているので、それらを理解して出来るだけ正しい画像処理を心がけて行きたいですね。

噂でACES用のLogである「log ACES」を準備していると聞きました。そちらにも期待したいですね。今後、cineon-log の代わりとなっていくのでしょうか?


12 件のコメント:

  1. このLog2Linは今に始まった訳でもないですが
    AppleのShakeでも標準装備されておりました。
    10年前以上からこの考えはあった事があります。

    最近はLogも各メーカからのカラースペースが増えてきたので、整理する必要もでてきますね。

    返信削除
  2. コージさんコメントありがとうございます。恥ずかしながら、今更なのかもしれないのですが、意外とまだ必要なんだなと実感しております。また、ようやくcineonLogというものも理解し始めた気がします。少しでもその辺の理解がVFX制作現場でも進めばいいなと思いブログとして掲載してみました。今後ともよろしくお願いします。

    返信削除
  3. 良い記事ですね。

    あとLog と linear 空間を行き来するワークフロー、特にレイヤー毎に異なる空間の場合は、ブラーのボケ足が変わるのも注意するポイントです。
    ブラー系の処理が入っているGlow系のエフェクトも同様ですね。

    返信削除
    返信
    1. コメントありがとうございます!そして情報ありがとうございます。僕は3DCGの仕事をしているのですが、CGのモーションブラー等もシーンリニアで計算されているので注意が必要そうですね。

      Log、sRGB、Linearが混在するワークフロー・・・。考えただけでも頭が痛いです・・・。

      ディゾルブの効果もガンマによって変わりそうですね。今度、時間が取れたら見え方の違いを確認してみたいと思います!

      画像処理、奥が深いです。

      削除
    2. それと、ReSize系の処理をかけた時に、マイナス値が発生する場合もあります。
      特に、拡大時にエッジのディテールをなるべく保持する傾向のあるフィルターなどの場合に発生傾向があります。

      削除
  4. 数年前にLAのグレーディングスタジオの見学に行った事がありますが、あちらでは普通にlogファイル使ってスクリーンで確認しつつカラーグレーディングをオペレーションするって感じでしたね。最近だとまた変わってきてるかもしれませんが…

    返信削除
    返信
    1. hal555さんコメントありがとうございます。とても参考になります。ここ数年でソフトや機材の対応が急速に進んでいるのでまた変わってきてるかもしれませんね。

      削除
  5. 個人的には、logファイルは過去の遺物と考えていました。
    Log形式自体、10bit の 1024階調になるべく広くの帯域を詰め込もうと Kodak社が20年も前に、 Cineon System用に考えた素晴らしいアイデアですが、デバイスの進化で、32bit float などのデータが比較的容易に扱えるようになってきた現代ではいずれ消滅していくものと思っていたんですけど、Logで直接出力するカメラが結構安価に出てきたので、また最近復活してきちゃいましたね。

    ポスト処理では厄介事が多いので、ワークフローの初期段階で多ビット系の Linear dataにしてしまう方が安心だとおもいます。あるいはLogで統一するとか。
    どちらにするかは素材の種類と割合で決まるとおもいますけど。

    少なくとも、一つのシーン内でLogとLinが混在したまま、いつまでも作業を進めるのだけは避けるのが吉。

    返信削除
    返信
    1. ozakiさん、詳細な説明ありがとうございます。とても参考になります。
       今まで、DPXなどを触れた事はあったのですがよく分からないまま扱ってしまってました。今まで適当すぎたので、今一生懸命勉強しております。
       「Logは過去の遺物」「Logで直接出力するカメラが結構安価に出てきた・・・」これはハイエンドの技術が一般化してきたのだと思うのですが、僕のいる環境はそういった環境です。「こういう時どうしているんだろ?」と思ったときの答えのほとんどは、既に出ているんですよね。しかも10年以上前とかに。
       それらを知っている人たちの知識、言葉は非常に役に立ちます。ありがとうございます。

      削除
  6. ここ1~2年でも変化してきてますが、ちょっと前までopenEXRでの納品が受け入れられない所とかもあったりして、Linearとカラースペースの認識はうまく浸透されると良いなぁと期待してます。
    日本ではLogがあまり使われなかった分カラースペースの話も混乱が生じてるのかな?と思ったりします。

    返信削除
    返信
    1. 少しずづ変化してきてますよね。今までEXR納品はCG部から説明などする必要があったのですが(扱った事がない等)先日納品した仕事は「EXRですが」「OKです」と、すんなり納品する事ができました。日本でもDITなどの職種が登場して来てます。このままいい方向にワークフローを変えていけるといいですよね!

      削除
    2. このコメントは投稿者によって削除されました。

      削除