ダイナミックレンジの検討（その１）
シリーズの第２回の末尾に、元のフレームのダイナミックレンジが大きい逆光では、スマホの写真は細部がつぶれるので、避けた方がよいと書きました。そして、元のフレームのダイナミックレンジの大きさが問題を引き起こす原因であれば、逆光であって、ダイナミックレンジがさほど広くなければ、まともに写るはずです。ですので、最初に、そのように説明を書いたのですが、撮った写真を確認したところ、逆光写真は全滅でしたので、慌てて、その部分の記事を修正しました。
検討の前提にはダイナミックレンジの比較的狭い逆光写真とは何かということが問題になります。逆光写真で、輝度が一番高いのは、直接写っている太陽になります。ですから、第１に、太陽が隠れている逆光写真ならよいと考えたわけです。でも、結果は、さんざんでした。
そこで、それでは、いったいJpegのダイナミックレンジは、どうなっているのか。これが、今回の検討課題です。darktableは3.0になって、トーンイコライザーという強力な
モジュールが追加されました。これを使うと、ピクセルのEV値がわかるので、Jpegのフレームのなかで、EV値の最大の部分と最小の部分を検索して、その差をとれば、Jpegのダイナミックレンジがわかります。
処理の基準の確認
画像をチェックする場合には、履歴のどのレベルを対象にするかを決めておく必要があります。
あらかじめ確認しておきますが、darktableの画像処理はピクセルパイプラインの指定する順番で行われ、履歴の順番ではありません。ただし、処理を履歴から外せば、その処理は行われないはずです。はずというのは、基本的な部分については、その限りでないためです。
履歴１はスマホのJpegファイルを読み込んだ時の履歴です。読み込み時は、４の画像の向きまで、自動的に処理がなされます。反転している部分を、０のオリジナルにうつせば、理屈の上では、全ての処理が行われる前の画像になります。しかｈし、読み込み時に、画像の向き（ポートレート、ランドスケープ）を見ていないと、縦横がおかしくなりますので、これが、処理されないことはありません。同様に、１，２も何らかの指定がなければ、画像が表示されませんので、外すことはできないと思われます。唯一、外すことが可能かもしれない機能は、３．ガンマになります。ガンマについては、反転している部分をガンマの上下に移動して、画像とヒストグラムをチェックしましたが変化はありませんでした。
まとめると、Jpegを読み込むと、自動的に履歴１のように１から４の処理が表示されますが、実質的な処理はなされていないと思われます。
履歴2は、Jpegを読み込んだ時の履歴です。これは、カメラ内現像をdarktableが再現していると解釈できます。RAWのJpegへの圧縮は主に、ベースカーブで行われます。ですので、RAWとJpegを比較する場合には、ベースカーブ処理後のRAWと比較することになります。ベーカーブを外すと、色乗りがおかしくなります。このブログに
今回、取り上げる画像は、サンプル１，２，３の3枚で、サンプル１，２は既に、逆光と順光に例で使った画像です。
サンプル１が逆光の例に使った画像です。サンプル１で一番明るいところは太陽で、トーンイコライザーの値をサンプル１にしますように+0.5EVです。逆に、一番くらいところは左下で-2.0EVです。したがって、ダイナミックレンジは2.5EVになります。これは、逆光写真としてはありえない値です。細部がつぶれるのは、当然といえます。
サンプル２は順光写真の例に使った画像です。サンプル２で一番明るいところは中央の空で+0.2EVです。サンプル１で一番明るい太陽が+0.6EVでした。このスマホでは、一番明るとところが、0.0から+0.5EVの間になるようで、変化のレンジは、暗所が大きく、明所は少ない傾向があるようです。一番くらいところは、サンプル２に示すように右下の-3.0EVになります。したがって、ダイナミックレンジは3.2EVです。サンプル１は2.5EVでしたので、サンプル２のダイナミックレンジが、サンプル１より大きいことになります。
いくらなんでも、逆光のダイナミックレンジが順光より小さいのは間違いだろうと考えて、ダイナミックレジの大きそうな逆光画像を探した例がサンプル３です。サンプル３で一番明るいとことは、太陽の部分で+0.6EVです。一番くらいところはサンプル３に示すように、左下にあり、-3.7EVです。これから、ダイナミックレンジは4.3EVになります。ダイナミックレンジは、サンプル１より、広くなったものの、センサーやJpegのダイナミックレンジの7から8EVからすれば、まだ、ありえないレベルと思われます。
まとめ
ダイナミックレンジの大きさをD(シーン)と表すことにします。さらに、Dに添え字をつけて、条件を表すことにします。例えば、リアル、または、肉眼のダイナミックレンジをD_real(),D_eye()などと書くことにします。こうすると、JpegのダイナミックレンジはD_jpeg()になります。画像がJpegしか扱えないスマホであれば、D_smartphone()と書けます。
もとのフレームのダイナミックレンジは、次になります。
D_real(逆光) > D_real(順光)
一方、サンプル１、２は次のようになりました。
D_smartphone(逆光) < D_smartphone(順光)
ここでは、反転が起こるとは、考えていなかったので、これは、予想外のことでした。
また、スマホのセンサーのダイナミックレンジは7EVはあるはずなので、Jpegのダイナミックレンジは、6から7EVはあると思いましたが、結果をみると、非常に狭くなっています。Jpegのダイナミックレンジ8EVの半分も使っていない場合が多いです。この点については、シリーズの次回に引き続き検討したいと思います。
センサーデータのダイナミックレンジがJpegになると減少する最大の原因はベースカーブにあると考えられます。スマホのベースカーブは、劣悪であると言えます。これだけひどいベーズカーブが使われているのであれば、小型センサーのスマホやカメラでも、RAWデータを使った方がよいのではないかと思われます。
色々なことがわかりました。課題を整理しておきます。
