Raw現像ソフトに関連する情報を探していると、シーン参照ワークフロー、だとかディスプレイ参照ワークフローという言葉を見かけます。特に Raw現像ソフトの中では darktable が Ver. 3.0以降、その新しい特徴としてシーン参照ワークフローの採用ということを強調しています(実は darktable だけではなく ART も採用しているのですが)。
それ以外にもリニアワークフロー (ということは非リニアワークフローもあるのですが) という言葉も聞きます。これらの概念について darktable のマニュアルを参考にまとめてみます。なお、シーン参照ワークフロー、ディスプレイ参照ワークフローという言葉は先にビデオ編集業界で定着した概念のようで、スティルフォト編集の世界ではまだ十分に認識された概念とは言えません。
そもそも外界の光のダイナミックレンジはかなり広いですが、カメラセンサーのダイナミックレンジはかつては 7～8EV程度、最近は、10～12EVぐらい*1、それに対してモニタのダイナミックレンジは、6.5EV程度と言われています。デジタルカメラのセンサーのダイナミックレンジはかつてはモニタより多少広い程度でしたが、現在はそれよりもかなり広くなっています。そのような中で、センサーに写った画像をどうモニタや紙の狭いダイナミックレンジに押し込めるかということが課題になります*2。
darktable 4.0のマニュアル、p. 29の記述によりますと、基本的には darktable の画像処理パイプラインは、以下の図のようになっています。
上の図の 1 はシーン参照モジュールです。2は、広いダイナミックレンジのデータを、ディスプレイや紙への出力に適した狭いダイナミックレンジのデータに変換する、トーンマッピングモジュールです。3 は、狭いダイナミックレンジに変換されたデータで画像処理を行うディスプレイ参照モジュールです。
1 のシーン参照モジュールは、カメラのセンサーの(広い)ダイナミックレンジそのままの、リニアなデータを扱うモジュールで、データをRawデータのまま処理する (なおこの段階では、厳密に言えばセンサーの感度の歪みが反映されたままの状態のはず) モジュールと、RawデータをリニアなRGBデータ (センサーの感度の歪みは補正済み) に変換して扱うモジュールが含まれます。画像データのダイナミックレンジが広いことが前提となっているので「シーン参照」と称しています。
2のトーンマッピングモジュールは、S字カーブ、シグモイド曲線を掛けたり、あるいはシャドー、ハイライトのデータを切り捨てたりして、狭いダイナミックレンジ表示するのに適切な形にピクセル分布を整形します。またこの時に知覚的なTRC (トーン再現カーブ) を掛けたりします。
この機能を darktable で担うのがフィルミックRGBモジュールです。下図は、フィルミックRGBがどのように、シーン参照データをディスプレイ参照データにに割り付けるのかを示している図です。
(darktableの割付けグラフ)
なお、darktable のフィルミックRGB、およびARTの対数トーンマッピングで、黒の相対露出値を引き上げるということは、ブラック領域のデータを切り詰めることを意味し、白の相対露出値を引き下げることは、ハイライト領域のデータを切り詰めることを意味します。
また darktable のフィルミックRGBは、割り付け方を決定するだけではなく、S字カーブの適用の仕方なども決定します。これは、複数の編集機能間の相互依存関係が重要なので、複数の編集機能をなるべく統合して１つのモジュールにまとめてなるべく破綻のない編集結果を導こうという設計思想によるものです。そのためフィルミックRGBの設計者である、Aurerrian Pierre氏は、フィルミックRGBの機能をもう少し分割しては、という提案に対して強く抵抗しています。
一方、ARTの場合は、シーンからディスプレイへの割り付け方は対数トーンマッピングで決定し、それ以外のピクセル分布の整形は、トーンカーブ等に任せています。こちらは各編集モジュールの機能はなるべく単機能化し、それをどう統合するかはユーザに任せるという設計思想です。
私が darktable よりも ART を多用するのは、変褪色したフィルム画像編集を行うことが多く、そのため、darktable が前提としている、カメラセンサーのデータは、それなりに外景を反映しているだろう、という前提が崩れており、元データが変褪色や、印画紙と電子的センサーの感度ヒストグラムの違い等の問題から、既に破綻しているケースが多いためです。
なお、この時注意したいのはRGBデータそのものは、ダイナミックレンジの情報を持たない、ということです。通常、デジタルカメラのセンサーは 12bit (4096諧調) もしくは 14bit (16348諧調) です。従って、そのRawファイルからRGBファイルを作ると(シーン参照)、0～4096 もしくは、0～16348 となるはずです。これを各センサーの最大値に対する%値で扱うとすればいずれにせよ、0～100%になります。
このデータをディスプレイ参照に変えるということは、ディスプレイ参照ではそのデータの0～70%の範囲だけ使うということではありません。ディスプレイ参照データにおけるRGBデータであっても、最小値～最大値は、0～100%です。ただ、例えば、シーン参照データの時のシャドーとハイライトを切り詰めた、 5～80%のデータをディスプレイ参照データで 0 ～100% に割り付けなおして(トーンマッピング)、狭いダイナミックレンジのデバイスで見ても違和感のないようにする、というようなことが行われるということです。
ですからここであえてRGBデータを一切動かさない (シーン参照の0～100%をディスプレイ参照の0～100%に単純に割り付ける) という選択肢もありえます(但し、ここではTRCを掛けるかどうかということは一旦捨象します)。その場合デジタルカメラで得た 12EV のデータを、パソコンの6EVのモニターでそのまま見せるということになります。これも結果的にダイナミックレンジの圧縮になっていますが(つまりどの明るさの領域も均等に圧縮して割り付けた形)、そうすると、非常に眠い画像になってしまいます。
また、HDRを実行してみたら、非常に眠い画像になって、全然HDRらしくなくなったという経験はないでしょうか。これも同じ理屈です。我々が「HDRらしい」と感じるのは、よりダイナミックレンジの広いデータが含まれているというよりは、「HDR風」演出*3によって「HDRらしさ」を感じているためで、逆によりダイナミックレンジの広いデータが狭いダイナミックレンジに均等に押し込められると却ってパッとしないと感じることになるかと思います。
そして、画像のコントラストを高めるためによく使われるS字カーブやシグモイド曲線は、元々広いダイナミックレンジのデータを、狭いダイナミックレンジのディスプレイで表示した時、なるべく効果的にダイナミックレンジがあるように見せる工夫といえます。
ただ、これもモニタ自体が改良され、モニタ自体が持つダイナミックレンジが広がれば、感じ方は変わるはずで、狭いダイナミックレンジのモニタで見ると、パッとしない画像が、広いダイナミックレンジのモニタで見ると、迫力ある画像に見える、ということが起こる可能性があります。今でも、プロジェクタで投影した画像を暗い部屋 (高ダイナミックレンジ) で見るのと明るい部屋 (低ダイナミックレンジ) で見るのでは見え方が異なりますが、それと同様かと思います。明るい部屋 (低ダイナミックレンジ) で見ることを前提とすると、それなりに見せるにはコントラストの高いメリハリのある画像作りが重要になりますが、それと同じでしょう。しかし、今後、ダイナミックレンジの広いモニタがスタンダードになってくると写真の編集の仕方も変わることになるでしょう*4。
3 のディスプレイ参照モジュールは、ダイナミックレンジの狭いディスプレイ用に最適化した画像データを使って処理するモジュールで、RGBデータとして扱う際、多くの場合知覚的TRCが掛けられた非リニアデータになっています(つまり物理的な18%グレーを、視覚的感度に合わせてRGB値の50%に割り付ける)。またRGBデータをL*a*b*に変換して処理を行う場合もありますが、L*a*b*の軸自体既に知覚的な影響を織り込まれていますので(L*a*b*値の50%が、物理的18%グレーとして定義されている)、L*a*b*データ自体非リニアです。画像データのダイナミックレンジがディスプレイに合わせて狭いことが前提となっているので「ディスプレイ参照」と称しています。
どのRaw現像ソフトでも最終的にはディスプレイに表示したり、紙に出力するので、必ずこの３つのモジュールが組み合わされています。では、ディスプレイ参照ワークフローとシーン参照ワークフローの違いは何でしょうか。
従来からあるディスプレイ参照ワークフローを採用したRaw現像ソフトでは、画像処理パイプラインの早い段階でトーン・マッピング・モジュールを適用し、多くの画像処理を、非リニアな色空間を使った表示参照モジュールで行うことになります。それに対して、シーン参照ワークフローは、なるべく多くの画像処理を1.のシーン参照モジュールで行い、なるべく出力直前にトーン・マッピング・モジュールで圧縮をかけ、最後のディスプレイ参照モジュールでは、どうしてもそこでないとできない処理(例えばどうしてもL*a*b*空間でやらなければならない処理など)のみを行う、ということになります。
なお、現状では出力は必ず低ダイナミックレンジのデバイスになりますので、シーン参照ワークフローであっても、最後には必ずディスプレイ参照プロセスが含まれます。
狭ダイナミックレンジの非リニア色空間で行う
リニア色空間で行う
なお、現像済みのTIFFファイルなどを編集するときは、一旦リニアな作業用色空間に落とし、上のカメラマトリックス適用後の部分からスタートすると考えられます。ただし、この場合は、多くの場合既にダイナミックレンジの狭いディスプレイに最適化したデータになっていると考えられるので、リニア処理にはなっていますが、厳密にはシーン参照とは言えないでしょう。
このように考えるとシーン参照ワークフローの理論的な優位は明らかです。つまり、ディスプレイ参照ワークフローだと早い段階で切り落とされてしまうデータを使って編集を行えるので、編集の自由度が格段に上がりますし、不自然な効果 (artifacts) も起こりにくいということです。
しかし、理論的な優位と使いやすさは別問題で、darktableの少なくないユーザが、シーン参照ワークフロー推進 & ベースカーブ(=DCPトーンカーブ)を排除しようとする darktable の方針に対して異を唱えているのも、むしろ編集の自由度の高さのために途方に暮れてしまう人が多く、編集出発のレファレンスポイントとして、メーカのカメラ出しJpeg や純正ソフトでの現像結果を置きたいということかと思います。また、市販のRaw現像ソフトの大半もおそらく、基本は現在もディスプレイ参照ワークフローを採用しているものと思われます。私がこのブログで、メーカの色作りが好きならまず純正ソフトを使って現像するのが筋だよ、と主張しているのもそのためです。
なお、ARTもシーン参照ワークフローを採用していますが*5(ですので、シーン参照ワークフローを前提とした、OCIOのCLF LUTsを使えるのです) *6、darktableで言うところのベースカーブ、つまりDCPトーンカーブの使用を排除していません。その代わりDCPプロファイルの適用をなるべく後ろにおいて、つまりシーン参照モジュールの一番最後に置くことで、DCPトーンカーブ利用の副作用をなるべく抑えるという方針を取っています。なお、RawTherapeeとはDCPプロファイルのパイプライン上の適用場所が異なるため、ART と RawTherapee とでは、DCPプロファイルの適用結果に差があります。おそらく同様に、Lightroom等の市販のRaw現像ソフトの結果とも差があるでしょう。
また、GIMPやPhotoshopの場合は、基本的に、現像済み画像データ、すなわちディスプレイ表示に最適化済みのデータを扱うため、シーン参照ワークフローという言葉は意味を持ちません。ただし、リニアワークフローか、非リニアワークフローかということになると思います。因みにGIMP 2.10 以降はリニアワークフロー、つまり内部の作業用色空間では、基本的にリニアな色空間を採用しています。
とは言え、GIMPやPhotoshopで、なるべくデータが切り落とされていない現像済み画像データを使って編集を行いたい場合は、ARTやRawTherapeeで、ニュートラル・プロファイルを使って現像を行ったファイルをGIMP等に読み込ませると良いと思います。これだと、シーン参照からディスプレイ参照にトーンマッピングを行う時に、切り落とされるデータが最小になると思われます。しかし、これで得られる画像は (通常のディスプレイでは) 非常に平板な冴えない画像に見えますので、ここから好みの画像に追い込んでいくには技術や熟練が必要です。
