background

ガンマのはなし その8

2011年07月31日(Sun)

人間の目は暗い部分ほど敏感で、明るい部分ほど変化に疎くなるという性質を持っている。ガンマ値で例えるなら約0.5の「明るい歪み」だ。人間の目に映る世界は、実際に目に入ってくる光の量より明るく歪んでいるのである。3DCGソフトは物理的な光の量を計算するものなので、レンダリング結果が暗く感じられるのは当然のことだったのだ。したがってレンダリング結果を人間が感じる明るさに近づけるには、ガンマカーブで明るく歪めてやらなければならない。ただし、人間の目の明るさの感じ方は固定ではないので、シーンに応じて適用量を調整する必要がある。

Poser以外のソフト、たとえばD|SやShadeでは、レンダリング結果のガンマとゲインを操作することができる。ガンマは文字通りガンマカーブをかけるものであり、ゲインは明るさの最大値を指定することでシーン内の輝度差を決定する。なので、明るさの最大値を決め打ちしている(と思われる)Poserのトーンマッピングと異なり、D|Sユーザは自分でシーン内の最も明るい部分に合わせてゲインを調整する必要がある。

ここまでが前回のおさらい。

13. 物理的に正しい色

さて、トーンマッピングを使用することで「物理的な光の量」を「人間の目が感じる明るさ」に修正することが可能になった。シーン内のオブジェクトが真っ白か真っ黒なものばかりだったなら、リニアワークフローはこれで完結しただろう。ところがそれ以外、灰色や他の色を使おうとすると問題が起こる。それまで指定していた色が、トーンマッピングを使うことで明るく淡く、ものによっては色相まで変わってしまうのだ。

110731-1

色が変わってしまう理屈はそんなに難しくない。人間の目には赤・緑・青の各波長を感じ取る受容体があり、人間の脳はそれぞれの受容体から送られる信号の、最も強いものと二番目に強いものの比を色相として捉えている。また、一番弱い信号の弱さで彩度を判断している。たとえば赤と緑が等量なら黄色で、RGB = (1, 1, 0) なら黄色、RGB = (0.5, 0.5, 0) なら暗い黄色、RGB = (1, 1, 0.5) なら淡い黄色といった具合である。

110731-2

トーンマッピングで歪みをかけると、RGB各成分の比率が変わってしまうために色相が変化したように感じてしまうのだ。

トーンマッピングを使うと色が変わる。ということはつまり、私たちが普段見ている色はもともと歪んでいたということである。このことはすでに第一回で書いている。「見た目には50%の灰色でも、物理的な光の量は四分の1程度しかない」という部分だ。そして、本来マテリアルで指定しなければならないのは、見た目の色ではなくこの「物理的な光の量」だったのである。

物理的な光の量というのは、つまり物質の反射率である。たとえば人間の肌の反射率は、赤い波長がだいたい55%ぐらい、緑の波長が30%ぐらい、青の波長が15%ぐらい、ということらしい。もちろん中間の波長が0%ということはないので、可視光線の全波長を合計すればそれぞれはもっと大きな値になるはずだ。また別の資料では、入射光に対して肌の表面上で反射するものが5%ぐらい、吸収されるのが40%ぐらい、残りが拡散反射や皮下分散する分、らしい。これらのことから、RGBの比をだいたい11:6:3にして、トータルの値が白の約55%になるようにすれば、おおむね物理的に正しい反射率ということになる。

110731-3

鏡面反射とかバンプとか色ムラを加えてみてこんな感じ。

110731-4

めんどくさいね(笑)。

物理的に正しいレンダリングとはこういうことなのである。物質の分光反射率から各波長の反射率を求め、鏡面反射と拡散反射を区別し、レンダリング後はトーンマッピングで人間の目の歪みを付加する。だがしかし、すべての物質の分光反射率をいちいち調べ上げるなど、どだい無理な話である。どこかで近似するしかなく、というかもともと鏡面反射だって本来なら全部レイトレース反射で計算するべきだし、全方位に光を反射している拡散反射と一方向のみに反射する鏡面反射が同じ尺度で設定されているのもおかしな話だし、つまりこういったモロモロが適当に片付けられている現状では、物理的な正確さなんてそもそも実現するはずがないのである。

14. ガンマコレクション(ガンマ補正)

現在のところ、3DCGで物理的に正しいレンダリングを実現するのは幻想である。とはいえ近似でいいならできることはあるわけで、正確な反射率が分からなくてもだいたいの色を再現することはできる。テクスチャや色に対してガンマカーブをかけ、人間の目が感じている明るい歪みを取り除いてやるのである。これをガンマコレクションという。収集(collect)じゃなくて補正(correct)。

Poserでガンマコレクションと銘打たれた機能がついているのはPoser Pro 2010のみだが、画像や色にガンマカーブをかけることなら、実はPoser 5の時代から可能だ。マテリアルルームで演算すればいいのである。

110731-5

画像の各画素に対してガンマ値を累乗したいのだから、数値演算色(Color_Math)ノードの値1に画像を接続し、引数に累乗(Pow)を指定する。値2には乗数を入力するんだけど、カラーパレットでは黒から白(0~1)までの値しか入力できないので、とりあえず白にしておいて数値演算関数(Math_Function)ノードから値を入力する。

画像処理ソフトで直接テクスチャにレベル補正をかけても構わないけど、あんまりおすすめしない。なぜなら画像フォーマットで保存した時点で値が256階調に丸められてしまって、中間調の情報が大幅に失われてしまうからだ。Poser上の演算なら端数が切り捨てられることはない。

ところで、乗数であるガンマ値にはどんな値を指定すればいいだろうか。懲りずに「自分のモニタのガンマ値が2.2なら2.2を…」と考えた人、冷静に考えてみよう。表示しているモニタによって補正値を変えるなら、50%グレーをWindows上のCGソフトでは0.21で、Mac上のCGソフトでは0.29で計算することになる。本来マテリアルで指定する色は「物質の反射率」のはずなのに、二通りの(あるいはユーザの設定によっては無数の)反射率が存在してしまうことになる。

正解は「その画像が作成されたモニタのガンマ値、ただし作者がちゃんとモニタをキャリブレーションしていて、なおかつ『現実の色』を描いていた場合に限る」である。

画像は保存されたときのガンマ値をそのまま持っている。それはモニタガンマかもしれないし、出力時にsRGBに変換されているなら約2.2かもしれない。確率から言えば2.2が圧倒的に多いだろうが、プロファイルが埋め込まれてでもないかぎり断言はできない。

さらに、作者本人が「現実的な色」を目指していなかった場合はどうしようもない。以前のV4M4のテクスチャを比較した記事(さらにトラックバックしてもらっているJezzさんちの記事)を見てもらえば一目瞭然だけど、肌の色はキャラ作家さんによってマチマチである。(もっともあの記事はマテリアルはいじってないから、テクスチャ自体がどんな色をしているかはあの比較画像からは判断できないけれども。)

なので、結局は自分のモニタを見ながら微調整していくしかない。カラーピッカーで選択する単色の場合は、自分のモニタのガンマ値を割り引いたらいいんだけど。

5月のM3復興会議企画のDD Magazineでは、自分の担当ページ(p7~p9とp12~p13。ReBirth絵はベーシックな三点照明)でこの手法を用いている。Poser 8でIDLを使用し、マテリアルに数値演算色ノードを挟んでトーンマッピングをかけている。ライトはレイトレース影の無限光1灯と拡散IBLまたはドーム状の環境光用Prop。生M3と生M4に使用しているのはDAZの標準皮だ。

110731-6(クリックで倍サイズ)

というわけで。

これまでのことをまとめると、リニアワークフローを実現するためには色や画像に対してガンマ補正をかけて物理的な色(反射率)に修正し、レンダリング後、トーンマッピングを使って人間の目の感じ方を模した明るい歪みをかける、ということになる。

110731-7

リニアと言う割にはなんか歪めてばっかりだったり、肝心な部分は目分量で微調整するしかなかったりで、結局リニアなんちゃらってカンジなのがご理解いただけたかと思う。

さて、長々と続いたガンマの話もそろそろ終わりにしたいところだ(だいぶ飽きてきた)。次回、Poser Pro 2010のガンマコレクションに触れて、簡単なシーンでも作って締めにしようと思う。



ガンマのはなし その7

2011年07月24日(Sun)

11. 歪みとリアリティ

前回の検証で、3DCGソフトは人間の目に映る世界をレンダリングしているのではなく、物理的な光の量を図示していることが明らかになった。したがってレンダリング結果を私たちの感覚に近づけるためには、画像に人間の知覚という明るい歪みを与える必要がある。そして、それは決して「モニタガンマの逆数」などという、決め打ちできる値でないこともわかった。

そのへんをもうちょっと考えてみよう。

人間の目は明るい部分なら明るい部分、暗い部分なら暗い部分で可能な限り明暗を捉えようとする性質がある。カメラでいう露出調整、目が慣れるというやつである。目に入ってくる光の量にさほど明暗差がないなら、その範囲に感覚を集中させるのだ。グラフで考えてみると、通常感じ取れる範囲があったとして、その一部分だけがクローズアップされることになる。

110724-1

すると明暗差が大きい場合と小さい場合では、歪み方が異なることがわかる。

110724-2

つまり明暗差が小さいシーンでは、人間の目に加わっている「明るい歪み」は直線に近づいていくことになる。(すごい乱暴な理屈だけど、まあ考え方としてそんなもんだと思ってほしい)

従来のライティングでは、人間の目が捉えている明暗差を忠実に再現していることはまずない。現実の太陽光と室内光では100倍以上明るさが異なるが、そんな設定にしたらあっという間に白飛びを起こしてしまうからだ。なのでシーン内の明暗差は狭い範囲に押さえられ、必然的に加えるべき歪みもガンマ0.5より線形(1.0)に近くなる、ということになる。

逆に、従来のレンダリング手法でフォトリアリズムを追求したいなら、なるべくシーン内の明暗差を抑えた方がいいことになる。実際にそういう絵は散見されているはずだ。間接光も計算できるソフトで、写真から切り出した高解像度のテクスチャを使用しているのに、やたらと絵面が薄暗かったりするのはその方が人間の目に違和感が少ないからである。

レンダリング結果をモノクロにして、情報量を抑えるのもそういったテクニックの一つだ。日常的に目にする分、人はどうしてもCGの肌に違和感を覚えやすい。そこで色の情報を破棄し、陰影だけの情報にすることで違和感を抑えるのだ。だからレンダリング画像をモノクロにすれば、単純にリアリティは向上する。そうならないのはよっぽどライティングが下手か、映ってるものがリアルからほど遠い(形状やマテリアルである)かのどちらかである。

というわけで、従来の手法を使って人間の感覚に近づけるためには、白飛びが起きないよう全体のライトを抑え、レンダリング結果に中間値を持ち上げるような加工をすればいい。

と、いうようにまとめると「あれ? それって自分がいつもやってることじゃ……」と思った人は結構多いだろう。フォトリアルなどと銘打たなくとも、普通に「見た目の自然さ」を考えてシーン作りをしていれば、大抵の場合は経験的に似たような解答にたどり着いているはずだ。逆に、ノーレタッチに拘って画質調整をしない絵作りをしている人は、理屈から言えばその時点でリアリティをスポイルしていることになる。

12. トーンマッピング

さて、話をリニアなんちゃらに戻そう。このあたりからいよいよPoser 8の話になる。

レンダリング結果を自然に感じられるようにするためには、人間の知覚を模した歪みを加える必要がある。Photoshopならレベル補正やトーンカーブを使って中間値を持ち上げるわけだ。

110724-3

この処理を3DCGソフト上で行うのが、Poser 8から追加されたトーンマッピングである。名称はソフトによって異なることもあるが、おおむね処理としては、レンダリング結果にトーンカーブをかけるというものだ。Poserのトーンマッピングはレンダリングオプションで設定する。

110724-4

英語版ならTone Mappingに、None/Exponential/HSV Exponentialの三項目からなるリストボックスがある(日本語版でどう訳されているかは未確認)。適当に訳すと「なし」「指数関数」「輝度のみ指数関数」といった感じだ。ExponentialまたはHSV Exponentialを選択すると、指数部の値(の逆数)を指定するテキストボックスExposureが有効になる。ちなみに初期値は1.6。ExponentialとHSV Exponentialの違いは、ExponentialがRGBの各値にエフェクトをかけるのに対し、HSV Exponentialは輝度のみにエフェクトをかけるため、輝度や彩度が保持される点にある。

このトーンマッピング、適当に使ってみてなんとなくレンダリング結果が淡く薄くなったなあ、で終わっている人もいるかもしれない。というのも、普通のシーンでそのまま使っても、結果はレタッチソフトでレベル補正をかけたものと大して変わらないからだ。しかしもちろん、トーンマッピングの本来の機能はただ中間値を底上げすることではない。

トーンマッピングを使用するメリットを挙げてみよう。

  1. Poser内で処理が完結するので画像処理ソフトを起動する必要がない。
  2. 画像処理ソフトと異なり、RGB各256階調の画像データに対してではなくレンダリング直後の生の計算結果に処理をかけるため、階調飛びが発生しない。
  3. 256階調を超える輝度を256階調内に収めることができる。

この中で、最大のメリットが3番である。これがどういうことなのかを確認するために、次のようなテストシーンを用意する。

110724-5

テスト形状は拡散色が白で、拡散値のみを変化させている。鏡面値その他はすべて0。で、この形状に正面から色が白で強度が1のライトを当てる。拡散値が1を超えるものは白飛びしてしまって同じ白い色にしか見えないが、ライトの強度を下げればその違いがわかる。

110724-6

ここで再びライトの強度を1に戻し、トーンマッピングをExponentialにして、明るさがどう変化するかを確認する。

110724-7

モニタに表示されるレンダリング結果は各色256階調の約1677万色だが、Poser内部の計算はHDRで行われている。画像データになる時点でLDR (Low Dynamic Range) に変換されているだけで、本当は明るさ100%、256階調を超える部分もキチンと計算されているのだ。そしてトーンマッピングは、従来ならクリップされていたその階調オーバーの部分を、各色256階調(トーン)の範囲内に割り当て(マッピング)することができる。

(ちなみにこのグラフから、トーンマッピングはモニタガンマの逆数のカーブをかけているのではないことがわかる。ガンマカーブならExposureが1の時には直線になっているはずだからだ。いろいろやってみたけど、シーン内の光量に合わせて範囲調整をしていることもないらしい。まあその方がありがたいけど。このへんはもっと詳しく調べたいところ。)

このトーンマッピングを使用することによって、今までなら白飛びが起こるために回避せざるを得なかった、強度100%を超えるライティングが可能になる。

最も恩恵を受けるのは拡散IBLライトである。拡散IBLライトは明るすぎて、とても強度100%などでは使えないことは誰もが知っているだろう。白色の無限光を100とすると、拡散IBLは(イメージマップを接続しない白色の状態で)440の強度を持っている。画像を接続することで若干は抑えられるものの、やはり他のライトとの兼ね合いで低い強度でしか使えなかったはずだ。接続した画像の色合いも、ほとんど生かされていないことになる。

それが、トーンマッピングを使用すると飛んだ階調を表現できるのだ。

110724-8

白飛びが発生しないので、太陽光のような圧倒的な光量を持つ光源も遠慮なく設定することができるようになる。また暗部を持ち上げるので、IDLの二次反射光もしっかり描画できる。これまでは難しかった明暗差の大きいシーンを、より現実に忠実に構成することができるのだ。

このように、トーンマッピングには大きな利点がある。また設定自体も手軽である。しかし実際に使用するには、その前にクリアにしておかなければならない問題がある。マテリアルである。

(つづく)



ガンマのはなし その6

2011年07月13日(Wed)

10. ランバートシェーディング

従来の「レンダリング結果はモニタガンマで暗く歪んでいる」という説明の根拠となったのは、レンダリング結果が自分の意図した結果(=普段私たちが目にする現実世界の様子)より暗い、というものだ。具体的に図示するとコレである。

110713-01

こんな複雑な形状を使うから話がややこしくなるんである。

確かに、このレンダリング結果は私たちがよく知っている現実とは異なるようである。しかしだからといって、モニタが悪さをしているのだ、いやレンダラの質が悪いのだ、などと結論づけるのは性急だ。明らかにレンダリング結果がおかしいと思うのなら、まず「なぜ通常のレンダラはそのような結果が出るように設計されているのか」と考えるべきだろう。

というわけでテスト形状。

110713-02

基本小道具の箱を使用。本当は平面で構わないんだけど、片面ポリゴンはカメラが裏に回ったときに見辛いんで箱にしておく。

拡散反射についておさらいしておこう。拡散反射とは、物質の表面の微細な凹凸によって、照射された光があらゆる方向に乱反射(つまり拡散)したものである。

110713-03

あらゆる方向に等しく反射しているので、どの方向から見ても同じように見える。つまり、拡散反射はカメラ位置の影響を受けない。

110713-04

これに対し、照射された光が一定方向に反射するものが鏡面反射である。一定の方向に反射しているので、カメラの位置が変化すると鏡面反射の位置や明るさは変化する。

110713-05

現実の物質には拡散反射や鏡面反射というパラメータはなく、ただ物質の反射率と表面の粗さ(凹凸)があるだけである。物質の分子構造によって入射光(のどの波長)がどれだけ吸収されるのかが決定し、表面の凹凸によって、入射光がまっすぐ反射するか乱反射するのか、その割合が決定する。CGにおける拡散反射や鏡面反射は、計算のために便宜的に分離して考えているだけなのだ。

さて、テスト形状の鏡面反射および他のあらゆるパラメータを0にして、拡散色を白に、拡散値を1にする。またライトを無限光1灯にし、色を白、強度を100%にしてテスト形状の真正面から照射する。このときのレンダリング結果から、ライトが当たっている面の色を拾って計測する。

110713-06

まあ予測通り白(輝度100%)になるわけだけども。次に、ライトの強度を変化させ、同様に色を計測する。

表1: ライト強度による表面の明るさの変化
ライト強度 [%]1009080706050403020100
表面輝度 [%]1009080706050403020100

このように、ライトの強度と表面の明るさは正比例の関係であることがわかる。(たぶんこの辺で結論がわかった人もいると思うけど、とりあえず最後までお付き合いいただきたい。)

ではライトの照射角度が変化した場合、物質表面の明るさ、すなわち拡散反射はどう変化するだろうか。これを計算するのが3DCGで最も基本的な陰影付け、ランバートシェーディングである。

ランバートシェーディングとはランベルトさん(ドイツ読み)が考えた「ランベルトの余弦則」に基づくシェーディング(陰影付け)手法である。その内容は「拡散反射は入射光の強度と拡散反射率、および入射光と物体表面の法線がなす角の余弦に比例する」というものだ。難しそうなので数式に翻訳してみよう。

Id=IL・Kd・cosθ

ここで、ILは入射光の強さ、Kdは拡散反射率、θは入射角(入射光と物体表面の法線のなす角度)である。式を眺めれば、拡散反射はライトが垂直に当たったときに最も強くなること(θ=0のときcosθ=1)、ライトの強さや拡散値に比例することなどが読み取れる。

では、なぜそうなるのかを考えてみよう。

ある一定の範囲に、垂直に光が当たったときのことを考えてみる。太いレーザー光か極端に絞ったスポットライトのように円筒状の光が当たったと考えてもいい。

110713-07

さてこのとき、ライトが斜めから当たったらどうなるだろうか。

円筒を斜めに切断すれば断面積は増える。ライトが斜めから当たれば、光の照射されている範囲が広くなるわけだ。ところが、ライトの強度が変化したわけではないので、照射されている光の量は変わらない。すると、どういうことが起こるだろう?

面積が増えた分、それまでの範囲に照射されている光の量が減るのである。

110713-08

光の当たる面積が倍になれば、照射されている光の量は半分になる。つまり

同範囲に照射される光量=垂直時の光量×(垂直時の面積/傾斜時の面積)

である。あとは三角比の問題だ。高校一年生の冬を思い出そう(中学校かもしれない)。

110713-09

入射角がθであるとき、面積は1/cosθ倍となり、単位面積あたりに照射される光の量はcosθ倍となる。照射される光の量がcosθ倍になるので、拡散反射もcosθ倍になるというわけだ。

このランバートシェーディングは3DCGにおいて最も基本となる陰影付けの方法である。おそらくほとんどのCGソフトがこの手法を用いているだろう(トゥーンなど特殊なシェーダを除く)。

では、実際にPoser上で確認してみよう。ここではライトを固定して、形状を回転させている。

110713-10

で、このときの色を計測してみる。

表2: 照射角度による表面輝度(拡散反射)の変化
θ [deg]030456090
cosθ 1.0000.8660.7070.5000.000
表面輝度 [%]1008771500

このことから、Poserの拡散反射もランベルトの余弦則に基づいていることがわかる。レンダリング結果のどこにも意図的な歪みはないし、手法は非常に明快に物理法則を単純化している。

気がついただろうか?

ここまでずっと、物理法則について話してきた。物質表面で拡散する光の量、物理的な光の量についての話をしてきたのだ。そう、その物理的な光が、人間の目にどのように映るかなどという話は一切出てきていないのである。

人間の知覚は変化を倍々で捉える法則がある。人間の知覚は明るく歪んでおり、ガンマ値だいたい0.5ぐらいのガンマ補正がかかっている。だけど、CGソフトはそんなものは考慮しない。ランベルトの余弦則に人間の知覚は登場しない。計算されるのはあくまで物理的な光の量である。

CGソフトが計算したレンダリング結果は、人間に見える世界を表現したものではない。あくまでそのピクセルからカメラに届く物理的な光の量をプロットしたものであって、言わばピクセルの輝度で図示した「光量分布図」なのだ。

なぜレンダリング結果が意図したより暗くなってしまうのか。モニタのガンマ特性によって画像が暗く歪められているからではなかった。最初からレンダリング結果そのものが、人間の感じる明るさを表現していなかったのだ。ならば、私たちの感覚に近づけるためにすべきことは何か。人間の知覚という、明るい歪みの補正をかけるのである。

人間の知覚はガンマ値にしてだいたい0.5ほどの歪みを持っている。だからまあ、モニタガンマの逆数、モニタガンマ2.2なら0.45の補正をかけてもあんまり大きな違いはない。なので従来の解説が微妙でも、結果はそれなりに伴っていたのだ。

しかしだからといって、「じゃあやっぱり今までの解説通りモニタの逆数で補正すればよかったんじゃないか」と早合点するのは危険そのものである。自分がさんざん「だいたい0.5ぐらい」と歯切れの悪い書き方をしてきたように、人間の知覚というのは一定の値ではないからだ。

人間の目の補正機能は複雑怪奇かつアバウトに高性能である。明るい場所でも暗い場所でも、しばらくすればそれなりに目が慣れる。日中の日陰のように極端に明るさが変化するところでも明部暗部それぞれきちんと知覚できる。一つの視界の中でさえ補正が働き、焦点・輝度はおろか画角まで奔放に変化するのだ。そんなシロモノを真似るのに、決して「じゃあ補正ガンマは0.45で」などと決め打ちできるわけがないのである。

つーか、補正を0.45でやったら多分普通に階調飛び起こしてると思う。やったらわかるけど。

(つづく……の前に付記)

レンダリング画像は物理的な光の量を図示したものだった。では写真のような見た目通りに表示されている画像はどうだろう。写真は物理的な光の量によってフィルムを感光させるものなので、現像時に恣意的に変化させられることはあるものの、実物の時点ではおおむね現実と同じ物理的な光の量を発している。ではなぜモニタ上でも同じように見えるのかというと、データ化されるときに補正がかけられているからである。スキャナで読み込むときやデジカメ内部でJpeg形式で保存されるとき、物理的に0.5ならデータは0.73にという具合に、明るい歪みによる補正をかけられているのだ。なので写真画像はモニタ上でリニアに表示されても、現実と同じように見えるのである。

だから前回はキッパリ否定したけど、このことを以てして「画像にはモニタガンマの逆数の補正がかかっている」と言ってしまっても、まあ間違いではないとは思う。正確にはスキャナで微調整した値だったり、デジカメでsRGBに変換したならsRGBのガンマ値を持っているわけだけど。さらに正確に言うなら、巷にあふれる写真画像で「恣意的な」ガンマ補正のかかってない画像なんてまずないわけで、今や安価なデジカメでさえ露出補正機能がついているわけで、一律にモニタガンマの逆数の影響だけを取り除けば「物理的な光の量」になるかと言えば、必ずしもそうではない。なので、モニタガンマが2.2なら2.2をかければいい、というような短絡的な思考は真っ先に封殺させてもらった。

あと、全ての画像に補正がかかってるなんて言ったら、今度はバンプや拡散「値」に画像を適用するときにいらん悩みを抱えることになる。画像は見た目通りの値をデータとして持っている。考慮するべきは物理的な光の量。そう考えた方が最終的にスッキリ整理されるだろう。

というわけで、次回はそんな観点からワークフローを考えてみる。更新は遅れる見込み。



ガンマのはなし その5

2011年07月11日(Mon)

ずいぶんと更新の間隔が開いてしまった。原因は勢いで新しいMacを買ってしまって、移行アシスタントを使わずに環境を再構築していたからで、色々変わったんだけどその辺の話はまたいずれ。
ということでサクサク進めよう。

9. 誤解だらけのCGとガンマ

おそらくこれを読んでくださっている大半の方が期待しているように、今回のガンマの話の終着点は「Poserとリニアワークフロー」である。しかしそこに辿り着く前に、もう二つばかり証明しておかなければならないことがある。

それは、リニアワークフローにモニタのガンマ値は無関係だということ。そして「物理的に正しいレンダリング」などというものは、いまだ幻想に過ぎないということだ。

たびたび見かけたリニアなんちゃらの説明はこうである。

従来のレンダリング結果にはモニタガンマ2.2がかかっている。だから現実より暗く、物理的に正しくない。したがって2.2の逆数、0.45のガンマカーブをかけ明るく補正する必要がある。またガンマ2.2のモニタで作られたテクスチャには、ガンマ2.2(の逆数のカーブによる補正)がかかっているので、レンダリング前にリニアに戻す必要がある。そうすればリアルになる。

このガンマの話の冒頭で、自分が「よくわからない」と書いた主な原因がコレである。前回までの記事を読んでくださった人なら、自分と同じような気持ち悪さを覚えたかもしれない。

これまで散々説明してきたように、コンピュータの中のデータはリニア(直線)である。モニタで暗く歪められた明るさは、人間の明るく歪んだ知覚によって相殺され、私たちの目にはほぼデータ通りのリニアに見えていたはずだ。それがどうして「CGソフトに限って」再び暗く表示されなければならないのだろう?

レンダリング結果にガンマカーブがかかっているなら、均等に変化するグラデーションは暗い方に偏ってレンダリングされるだろう。また、ライトを半分にすると明るさは半分よりずっと暗くなるだろう。かつてそんなレンダラがあっただろうか。

テクスチャに逆数カーブの補正がかかっているというが、プロファイルも読みとれないCGソフトがなぜガンマ2.2もしくは1.8を考慮してレンダリングを行うのだろうか? だいたい、自分の環境がガンマ2.2だから2.2で補正、などと言って、もしテクスチャの作者がガンマ1.8のMacユーザーだったらどうするつもりなのだろうか。

穴だらけである。そしてもっとも気持ち悪いのは、どう考えても理屈がヘンなのに、なぜか結果が伴っているように見える、ということだ。

難しいことを難しく考えていては、いつまで経っても始まらない。一つずつ考えてみよう。まず、CGソフトは本当にモニタガンマに応じてリニアな結果を暗く歪めているのか、という点だ。

これを確認するにはさほど手間はかからない。一つのグラデーション画像を画像ビューアとCGソフトのレンダリング結果とで同時に表示してみればいい。そこに差がないのなら、「CGソフトだけモニタガンマを余分にかけている」という仮説は崩れる。

110711-1

そして第二回で証明した「モニタガンマの暗い歪みは人間の知覚の明るい歪みで相殺されている」ということから、画像ビューアに表示されている明るさは、ほぼデータのままのリニアである。であれば、CGソフトのレンダリング結果もデータ通りのリニアに表示されている。0.5で表示されるべきところは0.5で表示されているのだ。モニタガンマで本来の明るさより暗くなっている、という説明は誤りであることがわかる。

では次に、テクスチャ画像になんらかの「明るい歪み」という補正がかかっているかどうか。これを確認するには、画像を使わない方法で色を指定してみればいい。これはすでに以前のエントリで検証済みである(ていうかあの検証自体が今回のための伏線だったわけで)。結果、画像の明るさと値で指定された明るさは等価であることがわかっている。

もっと簡単な確認方法は、一枚のポリゴンである平面小道具にUまたはVノードを接続することだろう。UまたはVノードはジオメトリのUV値を参照する。

110711-2

平面小道具のUV値は0と1しかなく、中間部分は線形に変化している。もしUV値が均等に中割りされていなかったら、貼り付けたテクスチャは左右または上下に偏ってしまうことになる。なのでUV値が作り出すグラデーションと画像のグラデーションが同じに見えるなら、画像のグラデーションもリニアであることになる。

いやいや、数値で指定してもやはり補正はかかっているのだ、CGソフトの内部でモニタガンマを参照(または決め打ち)し、数値に逆数のカーブをかけているのだ、と主張するなら仕方ない。20年以上前から存在するCGソフトが、(Windowsでは)ようやく最近OSベースでサポートされるようになったモニタのガンマをどうやって参照していたのか、またOSによってわざわざ数値を変更していたのか、レンダラを設計したすべての開発者がどういう意図をもってそんな仕組みを作ったというのか、ぜひ具体的に筋の通った説明をしていただきたいものである。

そんなわけで。

レンダリング結果はモニタガンマで暗く歪んでなどいないし、テクスチャに明るい補正などかかっていない。最初から順序立てて考えていけば、これが素直な帰結である。

すると、また新たな問題が浮上する。従来のリニアなんちゃら解説の「そうすればリアルになる」という部分である。確かに従来の解説で結果は伴っているように見える。というか結果が伴っているからこそ微妙な解説でもまかり通るんである。これは一体、どういうことだろうか。

(つづきは明後日更新、の予定)





Menu

Profile

Kyotaro

確定名:Kyotaro
ネタを探しているらしい。

Categories

Calendar

06 | 2011/07 | 08
- - - - - 1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31 - - - - - -

Comments

Archives

Track back

RSS feed

Links

Search

※2011年4月6日のサーバ障害の為、エントリのアドレスが以前のものからズレています。当Blogのエントリにリンクを張っておられた方は、お手数ですがアドレスのご確認をお願い致します。

※Internet Explorer非推奨。