モニタガンマを考慮したワークフローを行ったとしても色空間を特に気にせずにレンダリングを行った場合、大抵はsRGB空間のデータが入力されていて、そのままsRGB空間でレンダリングされているといえる。
AdobeRGBのモニタ環境で見かけが正しく作られたデータの場合はAdobeRGB空間でレンダリングされているともいえる。
これはsRGBやAdobeRGB等のように色空間が違う場合、同じ見た目の色を扱うと違う数値になるということが問題となる。
例えばsRGB(231,121,35)とAdobeRGB(206,121,47)は同じ色。これらの色は何色かというとXYZ(0.4007,0.3085,0.0543)またはL*a*b*(62.38,37.06,61.53)である。
sRGBは規格の中でも特に狭い色空間でマンセル色表の色のうち50パーセントくらいしか表せないといわれているし、カラーチェッカーのNo18のCyanも赤チャンネルがマイナスになってしまう。
また蝋燭や低温の白熱灯は1900ケルビンくらいの光源色となりsRGBでは青チャンネルがマイナスになるため0にされる。そうなるとホワイトバランスの調整をしても色が戻ってこないことになるので色々と不便。
sRGBは規格の中でも特に狭い色空間でマンセル色表の色のうち50パーセントくらいしか表せないといわれているし、カラーチェッカーのNo18のCyanも赤チャンネルがマイナスになってしまう。
また蝋燭や低温の白熱灯は1900ケルビンくらいの光源色となりsRGBでは青チャンネルがマイナスになるため0にされる。そうなるとホワイトバランスの調整をしても色が戻ってこないことになるので色々と不便。
ポスト処理で色調整などを行うことを考えると、広い色空間で作っておいたほうが有利であることは想像がつくが、かといって高色域の色が表示できるモニタをそろえることは厳しい。
したがって通常はレンダリング空間は色域は広い色空間を使うが、そのままでは表示上は低彩度なうえに色の偏りが生じてしまうので表示時にモニタ環境に合わせた補正が行われる。
レンダリング前の入力データに関しても基本はモニタ環境の色空間で作成しレンダリング前処理としてレンダリングの色空間に変換する必要がある。
例えば作業環境がsRGBでレンダリングの色空間をXYZとした場合は下記のような変換が行われる
ただし上の図はざっくりしたもので実際の映像制作ではもっと複雑であると思われる。
入力値はどの空間で定義しても問題ないが、XYZ色空間のように無駄に広いものを使うと8ビットテクスチャでは諧調が失われやすいので注意が必要。
入力値はどの空間で定義しても問題ないが、XYZ色空間のように無駄に広いものを使うと8ビットテクスチャでは諧調が失われやすいので注意が必要。
もしかしたら最近はRec.2020(4K、8KのUHDTV規格)のモニタもあるみたいなのでそれで統一できれば、入力とレンダリングと表示の色空間がすべて統一でき、上の図のような変換処理はしなくてもよいかもしれない。
レンダリングの色空間は何が良いのか
個人的にはXYZ色空間でのレンダリングは色が変になることがあるのであまりよくないと思っている。
下記の色空間が良いと思われる。
| Sharp RGB | レンダリング用に最適化されている色空間とのこと |
|---|---|
| Aces AP1 (ASECsg) | 最初に作られたACESのAP0という色空間ではなく最近定義されたAP1の色空間で、AP0よりも狭い色空間であるがレンダリング用に最適化されたものとのこと。 Rec.2020の色空間とかなり近いものとなっている |
| Rec.2020 | UHDTVの規格、色域もASECsgと似ている |
ライティング結果の色が正しくならない問題
ライティング結果の色を正しくレンダリングできない大きな原因は波長でレンダリングしていないからだが、この件に関してはスペクトルレンダリングで対応するしかないため普通はあきらめる。
次に問題になるのがどの色空間でレンダリングするかで色が変わってしまうという問題。
入力する個々のデータに関してはどのような色空間で作っても互換性はあるのだが
一度レンダリングしてしまうとレンダリング結果をXYZやL*a*b*に色変換しても色空間が違うレンダリング結果とは違う値になるため互換性がないということ。
なのでどの色空間でレンダリングするのかということは案外重要だと思う。
どの色空間でも単一のカラーやテクスチャ単体では互換性があるが、ライトが照射されたりしてRGBの掛け算等の演算がされてしまうと互換性がなくなるということ。
どの色空間でも単一のカラーやテクスチャ単体では互換性があるが、ライトが照射されたりしてRGBの掛け算等の演算がされてしまうと互換性がなくなるということ。
波長でレンダリングと3原色レンダリングの比較
波長でライティング : 色と光を波長でライティングして最後にXYZにしたもの
XYZでライティング : 色と光をそれぞれXYZにしてライティングしたもの
ここではA光源（タングステンライト）でライティングして、XYZの値をガンマ2.2で補正した色を表示した。
分光反射のデータはNoboru Ohta (1997)を使用した。
XYZでライティング : 色と光をそれぞれXYZにしてライティングしたもの
ここではA光源（タングステンライト）でライティングして、XYZの値をガンマ2.2で補正した色を表示した。
分光反射のデータはNoboru Ohta (1997)を使用した。
この2つが違うのは3原色レンダリングでは仕方のないこと
さらに言えば初期のナトリウムランプのような輝線スペクトル（589nm）では素材色がグレーに見えるはず。
また、日中の自然光と比べて蛍光灯の下では色がくすんで見えることが現実には起こる。
また、日中の自然光と比べて蛍光灯の下では色がくすんで見えることが現実には起こる。
3原色のレンダリングではこのような現象は再現できない。
輝線スペクトルの例
ここでは590nmの単色とした場合の比較でsRGBで表示
単色の輝線スペクトルの場合は濃淡だけとなるのが正しいが3原色のレンダリングでは色がついてしまっている
蛍光灯の例(gif)
黒体輻射の連続的なスペクトルは光源として演色性が良いが、蛍光灯は演色性が悪い。
ここではF2蛍光灯（工業用の広帯域蛍光灯とのこと）を例に挙げる。色温度は4150K。
比較するために黒体放射の色温度も4150Kとし、ホワイトバランスは共に4150Kとした。
表示色はsRGB
波長でライティングされた方は黒体輻射の光源と比べF2蛍光灯は色がくすんでいることがわかる。
一方、XYZでライティングしたものはほとんど変わらない。これは黒体輻射の4150kとF2蛍光灯ではXYZにしてしまうとほぼ同じ値になってしまうから。
左が黒体輻射4500K、右がF2蛍光灯。
スペクトルは全然違うのにXYZの値はほぼ一緒。この2つの光の色だけを見たとき人間には同じ色に見えるということでもある。
このことからも3原色のレンダリングでは限界があり、かといって原色を増やしてスペクトルレンダリングに対応するにはレンダリングコストが大きいのかもしれない。
今回調査したいことはこのことではなくて、3原色レンダリングの最適な色空間を見つけること。
黒体輻射の連続的なスペクトルは光源として演色性が良いが、蛍光灯は演色性が悪い。
ここではF2蛍光灯（工業用の広帯域蛍光灯とのこと）を例に挙げる。色温度は4150K。
比較するために黒体放射の色温度も4150Kとし、ホワイトバランスは共に4150Kとした。
表示色はsRGB
波長でライティングされた方は黒体輻射の光源と比べF2蛍光灯は色がくすんでいることがわかる。
一方、XYZでライティングしたものはほとんど変わらない。これは黒体輻射の4150kとF2蛍光灯ではXYZにしてしまうとほぼ同じ値になってしまうから。
左が黒体輻射4500K、右がF2蛍光灯。
このことからも3原色のレンダリングでは限界があり、かといって原色を増やしてスペクトルレンダリングに対応するにはレンダリングコストが大きいのかもしれない。
今回調査したいことはこのことではなくて、3原色レンダリングの最適な色空間を見つけること。
レンダリング空間の3原色の色比較
レンダリングするためにはいったいどの原色を使ったほうがいいのかを調べたい。
今回テストした色空間
| sRGB | XYZ |
|---|---|
 |  |
| ACES ap0 | ACES ap1 | Sharp RGB |
|---|---|---|
 |
 |
 |
- わかり易いように表示色空間はsRGB固定とする。
- レンダリング空間の白色点と表示空間のsRGBの白色点の違いはBradford変換している。
- sRGBの値と、その値からL*a*b*の差分であるΔEの値も比較した
- 光源は演色性の良い黒体放射を使用する。6500Kでは違いが少なかったので3000Kと20000Kで検証する。
XYZ : 反射と光源の色をXYZに置き換えて掛け算したものをsRGB表示
sRGB : 反射と光源の色をsRGBに置き換えて掛け算したものをsRGB表示
ACES Ap0 : 反射と光源の色をACES Ap0に置き換えて掛け算したものをsRGB表示
ACES Ap1 : 反射と光源の色をACES Ap1に置き換えて掛け算したものをsRGB表示
Sharp RGB : 反射と光源の色をSharp RGBに置き換えて掛け算したものをsRGB表示
リファレンス : 波長から求めた色 光源は黒体輻射20000K
XYZ : 反射と光源の色をXYZに置き換えて掛け算したものをsRGB表示
sRGB : 反射と光源の色をsRGBに置き換えて掛け算したものをsRGB表示
ACES Ap0 : 反射と光源の色をACES Ap0に置き換えて掛け算したものをsRGB表示
ACES Ap1 : 反射と光源の色をACES Ap1に置き換えて掛け算したものをsRGB表示
Sharp RGB : 反射と光源の色をSharp RGBに置き換えて掛け算したものをsRGB表示
XYZ : 反射と光源の色をXYZに置き換えて掛け算したものをsRGB表示
sRGB : 反射と光源の色をsRGBに置き換えて掛け算したものをsRGB表示
ACES Ap0 : 反射と光源の色をACES Ap0に置き換えて掛け算したものをsRGB表示
ACES Ap1 : 反射と光源の色をACES Ap1に置き換えて掛け算したものをsRGB表示
Sharp RGB : 反射と光源の色をSharp RGBに置き換えて掛け算したものをsRGB表示
次はさらにレンダリング空間内でホワイトバランスを調整した場合
- ホワイトバランスは光源色に合わせ、sRGB(白色点D65)空間で白になるようにしている
- 光源は黒体輻射3000Kで行った
リファレンス : 波長から求めた色 光源は黒体輻射3000K。ホワイトバランスは3000K
XYZ : 反射と光源の色をXYZに置き換えて掛け算したものをsRGB表示
sRGB : 反射と光源の色をsRGBに置き換えて掛け算したものをsRGB表示
ACES Ap0 : 反射と光源の色をACES Ap0に置き換えて掛け算したものをsRGB表示
ACES Ap1 : 反射と光源の色をACES Ap1に置き換えて掛け算したものをsRGB表示
Sharp RGB : 反射と光源の色をSharp RGBに置き換えて掛け算したものをsRGB表示
結果
カラーチェッカーだけではサンプルが少ないかもしれないがはやり色域が広いからといってXYZをレンダリング空間にすることは向いていないみたい。
ACES ap1 と Sharp RGBが特に安定している。
そもそもXYZは色を定義するためのもので色計算を行う空間には向いていないと思う。
Bradford法のホワイトバランス変更でもXYZから一度LMS空間に戻しているのも似た問題なのかも。
現状の映像業界ではデジタルシネマの標準の一つDCI-P3が使われることが多いかもしれない。
色域の広さからもDTPで使われているadobeRGB的な位置づけだと思われるが今後はもっと色域の広いUHDTVの規格であるRec.2020に置き換わっていくと思われる。
ただ最近のデジタルシネマではACESが標準になりそうな感じなのでACES ap1が使われる可能性も高いかも。
Rec.2020は実際に表示できる色域だが、ACES1 ap1 は可視領域から少しはみ出ているためRec.2020のほうが扱いやすいのかもしれない。
色域の広さからもDTPで使われているadobeRGB的な位置づけだと思われるが今後はもっと色域の広いUHDTVの規格であるRec.2020に置き換わっていくと思われる。
ただ最近のデジタルシネマではACESが標準になりそうな感じなのでACES ap1が使われる可能性も高いかも。
Rec.2020は実際に表示できる色域だが、ACES1 ap1 は可視領域から少しはみ出ているためRec.2020のほうが扱いやすいのかもしれない。
どうやらMaya2016ではレンダリングの色空間が設定できるようなので次はそれを試してみたい。
参考
sharp RGB
Picture Perfect RGB
SIGGRAPH2009 Color Imaging
（後半）
Picture Perfect RGB Rendering Using Spectral Prefiltering and Sharp Color Primaries
0 件のコメント:
コメントを投稿