トレンド&テクノロジー / カラーマガジン
第6回：異なるイメージステートのイメージビューイングとログからリニアへの変換

今回のThe Color Magazineでは、Inferno、Flame、Flint、Smoke (以下IFFS) 2009 Extension 1ビューイングパイプラインに搭載された新しい機能と、標準的なLOG-TO-LIN（ログからリニア）色変換の仕組みを解説する。

これまでのThe Color Magazineですでに紹介しているが、イメージステートにはOutput-Referred、Scene-Referred、Intermediate-Referredという3種類のカラースペースがある。Output-Referredにはビデオカラースペースが、Intermediate-Referred にはロガリズミックカラースペースが、Scene-ReferredにはHDR、Raw、そしてOpenEXRに用いられるscene-linearカラースペースがある。これらグループ間の変換のためにカラートランスフォームの必要があることも学んだ。ビジュアルエフェクトやフィニッシングの作業においては、1つのプロジェクトでこの3つのイメージステート全てのソースマテリアルを扱わなければならないことも珍しくない。そのような状況では、イメージを正確にビューすることさえ難しい場合があるので、IFFS製品シリーズのユーザー・インターフェイスには、3種類のイメージステート全てでのイメージビューを容易にするための新しい機能を加えた。


図1

図1は、新しいIFFSビューワーでの色処理のフロー図である。イメージデータ（クリップ等）は左側から入り、そのイメージステートによって3つの経路のどれかに分かれる（どの経路に行くかはユーザーが完全にコントロール可能である）。処理の第一段階で、全てをロガリズミックエンコーディングに変換する。プリントストックのシミュレーションに用いられる3D-LUTは通常このカラースペースでのインプットを予想しているため、この方法は便利だ。次のステップは、露光とコントラストノブである。3D-LUTが有効にされている場合は適用され、ない場合はフレームバッファへの途中でLOG-TO-LINトランスフォームを行う。この処理は全てグラフィックスカード上で行うので、リアルタイムに、インタラクティブに行われる。

露光とコントラストの処理は、ロガリズミックスペースでのシフト（露光）とスケール（コントラスト）だけである。諸君がもし数学を覚えていれば、Scene-Linearスペースでの乗算とガンマ補正にそれぞれ相当することがわかるだろう。このコントロールの目的は、入力映像のカラーコレクションではなく、ユーザーが迅速に調整を行って、ソースのクオリティを判断することである。これは、Scene-Linear HDRにあるハイライト情報、ロガリズミックイメージ、シャドーのノイズの量等を確認するのに役立つ。

このパイプラインの興味深いメリットの一つは、プリントシミュレーション3D-LUTを、通常意図されているログイメージだけでなく、Scene-Linearイメージやビデオイメージにも正確に適用できることだ。これは特に、最近のデジタルカメラで撮影したイメージで役立つ。



処理の最後の段階で、3D-LUTが有効にされていない場合、LOG-TO-LIN トランスフォームを使って、ログスペースデータをフレームバッファ用ビデオスペースに変換する。この場合、フィルムアウトプットのシミュレーションは3D-LUTほど正確ではないが、このトランスフォームはビジュアルエフェクトの世界で昔から使われてきたものなので、ユーザーの間では良く知られている。このトランスフォームは、ロガリズミックCineonイメージをグラフィックスモニター上でビューするために処理することと繋がっており、Kodakが初めて紹介したものである。これは初期に（15年前）LOG-TO-LINEARと呼ばれたが、実はLOG-TO-VIDEO変換である。よく普及したトランスフォームなので、この仕組みを説明しておきたい。

基本的なステップは次の通り：
1）リファレンスホワイトを引き算する（10-bitイメージで通常685）
2）フィルムガンマで割る（通常0.6だが、少し高いかも知れない）
3）欲しいカメラガンマを掛ける（通常0.45だが、少し低いかも知れない）
4）その解で10を累乗（つまりanti-log）
5）定数を減算し、blackをビデオスペースで0にマッピング、whiteを最大までスケール

ご存知の様に、ログイメージが持つハイライト値はビデオモニターで表示できる域を超えているので、ステップ1では、whiteの中で最も明るいと思われるものを0にシフトする。10の0乗は1なので、このwhiteは最大のビデオ信号になる。（このアルゴリズム自体は、フィルムで徐々にハイライトを落としていく様子を再現する”soft-clip”が可能だが、これについて今回は触れないでおく。）

ステップ2では、フィルムガンマによる除算で、デンシティー（密度）軸上（つまりフィルム感度グラフ上）の値を、ログシーン露光軸に変換する。ここではネガフィルムの足部と肩部が無視され、感度を直線と想定しているが、現実面ではこれで十分である。

ステップ3では、ビデオカメラでのシーンキャプチャをシミュレーションする。ITU-R BT.709（rec. 709）については聞いたことがあると思うが、これはスタンダードなビデオキャプチャのレスポンスについての規格である。この数式では0.45（= 1 / 2.22)の累乗を使っているので、しばしばビデオキャプチャのガンマであると想定される。しかし、この規格にはシフトとスケールも含まれているため、単純な指数法則の数式による最近似値から、0.53（ = 1 / 1.9）に近いガンマが得られる。多くの人が、これはCRTモニターで適用される指数法則のインバース（つまりガンマ）であると、誤って推測してしまう（これはおよそ2.4）。しかし、過去の号ですでに論じたように、これは間違いである。Scene-Referred イメージステートから Output-Referredイメージステートへの変換であるから、正味のコントラストを強める必要がある。ビデオシステムの場合、これはディスプレイガンマに対してキャプチャガンマを相殺する形をとる。

ステップ4では、ログから「リニア」スペースへと変換するが、このトランスフォームの名はここからきているのかも知れない。前にも見たように、このトランスフォームにはガンマ補正があるので、シーンに関してはリニアでない。ログスペースのリファレンスホワイトを0にシフトしたので、リニアスペースではこれが1になる。ステップ5では、定数を引き算して、ログスペースのリファレンスブラック（通常10-bitイメージで約95）をビデオシステムのblackに戻すことで仕上げる。これによってリファレンスホワイトが1より小さくなるので、whiteをビデオシステムの最大値まで戻す。

図1の最初の段階では、ビデオインプットとScene-Linear インプットの両方を、LIN-TO-LOGトランスフォームを使ってログスペースに変換していることに気づいているだろう。ビデオの場合、これは先ほど説明したLOG-TO-LINトランスフォームの単純な逆数である。Scene-Linearインプットのトランスフォームも同様だが、ただステップ3のキャプチャガンマが1に設定されている（つまり、これはビデオデータではなくシーンなのでカメラがない）。このトランスフォームは1以上の値をクリップしないので、ユーザーは続く露光コントロールで、イメージ内のHDRハイライト情報をすべてビューできる。

イメージステート間の変換には、例えば3D-LUTを使う等、これより正確な方法もあるが、目的が判断（イメージ内にあるものを見ること）であって、最終的な加工でない（これはアプリケーションの他の部分で行う）ビューワーのコンテキストでは、この典型的なLOG-TO-LIN と LIN-TO-LOG のトランスフォームが、十分有効である。単純で、正しい動作が確認できる、ユーザーの間で長く使われてきた1Dトランスフォームである。

今回は、標準的なLOG-TO-LINトランスフォームの仕組みと、IFFS 2009 Extension 1 ユーザー・インターフェイスの非常に便利な新機能を紹介した。