前回、前々回に引き続き、私のガンマ補正に関する理解のメモです。あくまでも私の理解の範囲で書いているので、情報の正しさに関しては保証の限りでありません。
〇色の整合性 (Color Integrity)とガンマ補正
ところで、作業色空間に、ガンマ補正 (トーン再生カーブ = TRC) をかけた非リニア空間で画像処理を行うのではなく、ガンマ (TRC) 補正をかけないリニアな色空間で画像処理を行うソフトが徐々に出てきています。主に、HDR処理を行うソフトや3D画像作成ソフトでリニアな空間で処理を行うケースが増えています。ちなみにリニアな色空間が使える主要な写真画像処理ソフトとしてはdarkableが挙げられます。Photoshop, Lightroom, Luminarなどはいずれも非リニアの色空間を使っています。RawTherapeeは非リニアが原則ですが、ガンマ値を変更することが可能です。しかしモニタ表示はガンマ補正がかけられていることが前提になっているようです。ですのでガンマ値を1にしてリニアにすると、モニタ表示は薄暗くなってしまいます。
リニアな色空間での処理が提唱される理由の一つは、ガンマ補正をかけなければ計算負荷が少なく、スピーディーに処理できるということかと思いますが、理由はそれだけではありません。
大きな問題は色の整合性(Color Integrity)にあります。Color Perfectの開発元であるC F Systemsの技術文書*1に、色の整合性について詳しく説明されていますので、そこから内容を解釈・抜粋してお伝えします。
今、仮に、山の絵を写生することを考えます。当然絵の具を使って写生するわけですが、日が陰ってきて暗くなったらどうでしょうか？絵具に黒を混ぜて絵具を暗くして絵を描きます。あるいは白い霧が出てきて、山全体が白くかすんだらどうでしょうか？絵具に白を混ぜて、絵具を白っぽくして描きますよね。これと同じことをコンピュータ上のRGB画像でやろうとするとどうするでしょうか。黒っぽくするにはRGBの値に一律1未満の値を掛けるか、あるいは一定の値を引くことで黒い絵の具を混ぜるのに相当する操作を行いますし、白っぽくするには一律１を超える値を掛けるか、あるいは一定の値を足すことで実現します。
その際、絵具に黒や白を混ぜても、色の明るさは変わったとして色 (色相) 自体は変わりません。赤だったものが明るい赤になるか暗い赤になるだけです。白を加えたら藤色になる、ということはありません。藤色になったら色相が変わってしまったことになります。
で、コンピュータ上の場合リニアな色空間ですと、RGBそれぞれに一定の値を掛けたり、足し引きをすることで、やはり色自体 (色相) が変わることはありません。絵具に白や黒を混ぜるのと同じです。この状態を色の整合性が取れている、とします。
ところが、非リニアな色空間ですと、絵具と同じようにならないのです。このような操作を加えることで色自体 (色相) が変わる可能性があるからです。非リニアな色空間では、人間の知覚上均等になるように色の階調を決めています。しかしそれは物理的には均等ではありません(リニアな色空間では物理的に均等)。人間の知覚で敏感な中暗部に多く階調を割り当て(1諧調当たりの色の幅は狭くなる)、鈍感な明部では階調の割り当てはまばら(1諧調当たりの色の幅は広くなる)です。従って、非リニアなRGB値に0.8を掛けたとしても、常に物理的に20%暗くなるとは限りません(知覚的には20%暗くなっているはずですが)。元のRGB値が暗めであれば物理的にはさほど暗くなっていませんし、明るければ20%以上暗くなっているはずです。それでもRGBのそれぞれの値が同じであれば(例えば、100, 100, 100)であれば、RGBそれぞれの値が同じ幅だけ暗くなっているはずです。しかしRGB値がばらばらであれば、(例えば、Rが30 Gが100 Bが200など) 数字上同じ割合(20%)で値が下がったとしても、物理的には、RGBそれぞれがばらばらな幅で値が下がっていることになります。そうすると、元の色を単に暗くしたのではなく、色相も変わってしまうことになります。このような場合が、色の整合性が崩れた状態です。色を明るくしたり暗くしたりするときには、知覚的(非リニアの数字上)ではなく、物理的(リニアの数字上)に同じ割合で変化させない限り、色相が変わり、色の整合性が崩れてしまうのです。
これを避けるためには、理論的には、一旦非リニアな値をリニアに戻し変換し、さらに非リニアに戻すという計算を行えば良いということになります。しかし、そうすると負荷が高いので、ソフトウェアの動作がのろくなってしまいます。結局 Photoshopなどでは、非リニア、知覚ベースで計算をしているので、色のレベル操作などを行うと、色の整合性が失われてしまうということです。C F Systemsの文書では、Photoshopの、例えばレベル補正で色の明るさを変えれば色の整合性が失われると主張しています。
で、C F Systemsの主張通り、実際にPhotoshopが非リニアな表面的な(つまり非リニアな知覚ベースの)RGB値に基づく計算をやっているのか調べてみました。例えばあらかじめ画像のあるレイヤーの上に、均一な値(例えばRGBがそれぞれ30)のレイヤーを置きます。そしてそのレイヤーのモードを「差の絶対値」にしてみると、果たして、下の画像の値からそのまま30引いた画像を表示しているようです。つまり表面的に(つまり知覚ベースの非リニアな)RGBの値に基づいた計算を行っていて、物理ベース(リニア)に基づく値で計算をしていません。つまり色の明るさの変化を伴う調整を行うと色の整合性が失われる状態です。
ちなみにGIMPでもやってみました。例えば、画像を新たに作成し、明るさ30で均一に塗ったレイヤーのモードを[減算]にしておき、その下に様々な明るさのレベルのレイヤーを置いて引き算をさせると、引かれる値が一定にならず、下のレイヤーが暗め程大きな値が引かれ、明るめだと小さな値しか引かれません。GIMPの場合は、画像処理のために、いったんリニアに戻して計算をし、再度数値表示を非リニアに戻しているのは明らかです。あるいはもともと作業空間はリニア、そして表示だけ非リニアにしている2段構えになっているのではないかとも推測しますが(そのほうが計算量が減るはずです)...
◆GIMPにおいて、明るさが30のレイヤーで、様々な値のレイヤーから減算をした結果
引かれるレイヤーの明るさ 引いた後の明るさ 引いた値
255 → 253.5 → 1.5
180 → 177.7 → 2.3
100 → 95.0 → 5.0
70 → 62.7 → 7.3
50 → 37.5 → 12.5
35 → 12.4 → 17.6
30 → 0.0 → 30.0
※ 値は非リニア (知覚) sRGB色空間ベースの値 (最大値255)
255が最も明るく、0が最も暗い
因みにPhotoshopは、上に述べたように、30の明るさのレイヤーで引けば、常に30引かれます。引かれる元のレイヤーの明るさによって、引いた値が変わるということはありません。実はしばらく前から、GIMPで画像同士の加減乗除をやると数字(非リニア上のRGB値の数字)がその通りにならないということは気づいていたのですが、そういうことだったのか... 表面的な(非リニアの)数字上ではなく、リニアに戻した数字で計算してたということです。道理でGIMPの方がPhotoshopより動作がもっさりしているはずです。そういえば、GIMPの一番トップのバーに GIMP Built-in Linear sRGB*2と表示されます。うぅーん、そうだったのか... そういう意味だったのか... つまりsRGBの色空間を使っているけれど、リニアで計算しているよ、という意味だったのです*3。
ちなみに、GIMP(Ver. 2.10)では、リニアに保存されたTIFFファイルを読み込んでも、非リニアで保存されたTIFFファイルを読み込んでも、しっかり同じように表示されます。リニア保存が可能なRaw現像ソフト、darkableで同じ画像をsRGB, Linear RC709, AbobeRGBの3つのプロファイルでTIFFファイルとして保存し、それをGIMPに読み込ませたところ、見事に全く同一に表示されます。RGB値も全く同一です。同じファイルをIrfanVIewで表示すると全くバラバラで(ヒストグラムも当然異なる)、特にリニアに表示したファイルは暗く表示されます。RGB値も同一です。GIMPではカラーマネジメントがしっかり働き、リニアだろうが非リニアだろうが、表示は同一になりますが、IrfanVIewはそもそもカラーマネジメントを行っていないので、バラバラな表示になってしまいます。なお、GIMPではRGB値の表示は、たとえリニアな画像であっても、sRGBガンマ補正カーブが適用された非リニアの値で表示されるようです。ともあれ現在のバージョンのGIMPではリニアな画像であってもしっかり処理されるようです。この点はRawTherapeeでも同じでした。RawTherapeeの場合はRGB値がごく僅かに差が出ましたが、リニアなファイルでも、やはり非リニアにおけるRGB値表示を前提としているのは同じなようです。
さらに、同じ画像をImageJで読むと、IrfanVIewと同じようにsRGB, Linear RC709, AbobeRGBがそれぞれ異なって表示されます。表示面ではやはりsRGBが前提になっているようです。これは単にWindowsのデフォルト設定が適用されているためのようですが、本来ImageJは科学技術目的のソフトウェアなので、意図的にカラーマネジメントを行なっていないものと思われます(医学、生物学等ではガンマ1.0で固定するのが常識)。意図しないガンマの変更はデータの誤読や捏造につながりかねませんので。とはいえ、ガンマ1.0を前提とするなら、ガンマ1.0のリニアな画像が、本来モニタ上1.0で表示されるべきです。Windowsではガンマ1.0の画像はガンマ逆エンコードされた状態で表示されていると思います(デフォルトでカラーマネジメントの行われていない画像はsRGBであるものとして扱われますので)。そのあたりはモニタの調節で何とかできなくもないとは言えますが...
ImageJ読込結果 (Windows上)
左上: リニアRC709, 中央: sRGB, 右上: adobeRGB
ところで、Photoshopのように、非リニアな色空間の数字に基づく色の操作を加え、色の整合性が崩れても 、多くの人は気づかないのは、なぜなのか。
C F Systemsの文献では、色の整合性と色のバランスの概念が異なるからであり、色の整合性が失われても色のバランスが確保されていれば、おかしいとあまり思わない、と言っています(逆に色の整合性は取れていてもバランスは崩れている場合もありうる)。
また、私の考えでは、おそらく自然の風景写真などではRGBの値が大きく離れているピクセルはあまり多くないからだと思います。原色ですとRGBそれぞれの値が大きく離れています。人工物ではそのようなRGB値が大きく離れている色が使われる可能性はありますが、自然の中には、原色などRGB値が大きく離れている色のオブジェクトはあまり見られません。ですので、色の明るさを操作して色相が変わったとしても、多くの場合その変化幅は大きくなくあまり気づかないためだと思います。私の不均等黄変写真を補正するBチャンネル再建法は、BとGの値が接近する (つまり色相が変化する) 副作用がありますが、見た目上意外に、事後にBとGを離さなければならない編集を迫られるケースが少ないのも、そのためです(つまり元々BとGの値がかけ離れているピクセルは少ない)。
ちなみに、私の作成した黄変写真補正用のプラグインですが、基本的には、表面的なRGB値で計算しています。ただファイルが非リニアなら非リニアで、リニアならリニアで計算することになりますが、非リニアな画像を前提で考えていました。問題があるとすれば、Bチャンネル補正法用のプラグインで128を閾値として作成しているファイルがありますが、その値を変えたリニア版のプラグインを作成する必要があるかもしれません。
←ガンマ補正理解メモ(2) - 画像処理ソフトとガンマ補正に戻る
→ガンマ補正理解メモ(4) - GIMPでのリニア / 非リニア画像処理と作業色空間の変更に行く
*1: Dunthorn, David, 2009,'Complete Color Integrity', C F Systems CFS-276
*2:もちろん、[画像]→[モード]→[作業カラースペースの変換]で色空間を変更すると「sRGB」というところが、変更した色空間に変わります。また色空間を変えると、RGBの値も変わります。
*3:なお、レイヤーダイアログの下記の画面([標準]の右側のアイコン)で、レイヤー(計算)モードの[デフォルト]を[レガシー]に変更すると、一旦リニアに変換することなく、従来通りsRGBの値そのままで計算を行います。
