ここ最近、補正の結果に対して画像の色数をお示ししていますが、画像ファイルの色数のカウントは簡単そうに見えて実は意外に難しいです。そもそも画像の色数をカウントするツールが意外にありません。Raw現像ソフトである、RawTherapeeもdarktableも、ファイルの情報を見ても色数は取得できないようです。Photoshopもそのような機能はありません。
とりあえず見つけた方法は IrfanViewを使う方法とGIMPを使う方法です*1。
IrfanViewの場合は、[Image]→[Information]から見られます。
GIMPの場合は[色]→[立体色分析]から見られます。
そして、この両者の結果は多くの場合ほぼ一致します。
ところで、RawTherapeeやdarktableで編集したファイルをsRGBで保存した場合とadobeRGBその他で保存した場合では、IrfanViewやGIMPで色数を計測すると、両者で色数に差が出ます。sRGBで保存すると色数が多く、adobeRGBで保存すると色数が大幅に少なくなります。adobeRGBの方が色空間が広いはずですので、これは本来ならば変な結果ではないかと思われるのですが....
それで自分で ImageJ上で色数をカウントするプログラムを作ってみたりして、はたと気づいたことは次のようなことでした。
まず、IrfanViewの色のカウント機能ですが、IrfanViewは16bit, 32bitの画像もすべて一旦8bitにビット深度を落として扱います。従ってまず、IrfanViewの色数カウント機能はすべて8bitベースのはすです。
次にGIMPのカウント結果がIrfanViewに一致するということはGIMPも、8bitに落として色数をカウントしているということです。つまり現状、16bitや32bitベースで色数をカウントするツールはないということです。
ただこれはよく考えると当然です。8bitの場合、もし、考えうるあらゆる色数があったとすると、2の24乗 (8bit x 3チャンネルで24bitですので)色、つまりマックス1677万色以上あることになります。実際に1677万色あるケースはありませんが、その10分の一程度の色数であれば、今まで御覧に入れた画像でもありました。これが16bit (→16bit x 3チャンネル= 48bit) だとマックス281兆色以上という話になります。もちろん281兆色ということはありえませんが、そこそこ大きいファイルだと、その10分の1、つまり30兆色程度は十分ありうる可能性があるので、その場合色をカウントするだけで、PCにかなりの負荷と時間がかかります。16bitや32bitで色数をカウントするツールは、作れないことはないにせよ、実用的ではないのです。
もし、どうしても16bitベースで色数をカウントしたいというならば、ファイルのピクセルサイズを制限するという方法があります。例えば1280 x 960ドットにサイズを制限すれば、総ピクセル数は122万8800ピクセルに制限されますので、122万8800色を超えることはあり得ません。これであれば何兆という色数をカウントしなくても済みます。ただそういう変換を行うなら、8bitに変換してカウントしても良いだろうという話になります。つまり最大色数は、ビット深度の最大値と画像のピクセル数の、より小さいほうで決まる、ということです。
さらに、仮に今色空間がsRGBの画像をadobe1998に変換したと仮定します。そしていずれもビット深度が8bit (0-255) だと仮定すると、狭い色空間から広い色空間に変換するわけですから、データのRGB値の分布範囲は逆に狭まってしまいます。しかもRGB各明度 (輝度) の諧調は0-255に限定されますので、変換したときに丸められて諧調数も減ってしまう、ということになります。
(3次元で表記できないので、2次元で表記)
これがsRGBの画像をadobe1998に変換したとしても、16bit画像や32bit浮動小数点であれば、諧調数の減少は少ない、もしくは起こらないかもしれませんが、色のカウント上8bitに落としたときにどうしても丸められてしまいますので、元々の諧調が少ない場合以外は、広い色空間に画像を移すと、カウントされた色の諧調は通常減ります。
ただ計測対象の画像が16bitや32bitといった高深度であれば、8bit上で単にカウントされた色数が少ないことは、直ちに実際の画像の色の諧調が少ないことを必ずしも意味するわけではない、ということに注意が必要です。
例えば下記の画像ですが、
この画像は、スキャンしたときにadobeRGB 16bit TIFFで取り込んでいますが、その時の色数は8bit相当でカウントして約305万、一方これをRawTherapeeやdarktableを使って、sRGBに変換すると色数は約450万に増加します(但しオリジナルの約7500 x 5000ピクセル での色数です)。この数は8bitの最大色数1677万の4分の1以上です。
但し、広い色空間で、フルに広い範囲で色が分布していた場合は、その画像を狭い色空間に変換したときに、狭い色空間に入りきらない色がクロップされ、狭い色空間の方が色数が減るということはあり得ます。しかし、8bitで計測する場合、多くの場合広い色空間の方が色数が少なく、狭いほうが色数が多くなる傾向にあります。
またこのことは、逆に考えると、単に色数の計測にとどまらずに、8bitのような色深度の浅い形式で画像を実際に保存する場合は、sRGBのような狭い色空間を使うべきで、広い色空間を使うとかえって画像の色の諧調が実際に減ってしまう(劣化してしまう)、ということを意味します。このことは、あまりきちんと認識されていないのではないでしょうか。
ともあれ、以上のことから、この両者のツールを使ってある程度正確な色数をカウントするには、sRGBで保存する必要があるということです。あるいは計測したいファイルがadobeRGB等他の色空間のファイルの場合は、正確な色数はカウントできないものの、ファイルを加工して色数の増減を確認したいというような場合、読み込ませるファイルの色空間が例えばadobeRGBに統一されていれば、色数の増減を比較するための目安となる値は取得できる、と考えてよいと思います。逆に言えば読み込ませるファイルが、あるファイルはsRGB、あるファイルはadobeRGBと、色空間が統一できない場合は、色数の多少を比較することはできません。同時にファイルのピクセル数の異なる画像の色数の比較も意味がありません。
なお、GIMP上で色空間を変更する場合は、丸め誤差が発生することを考慮する必要があります。実際に、GIMP上で、sRGBの画像を別の色空間に変換し、再びsRGBに戻したりするなど色空間の変換を繰り返してみたら、途中で発生した丸め誤差で減った色数で頭打ちになり、どんどん色数が減っていってしまいました。これは、GIMP上で色空間を変換したときに、色を補間する機能がないため、どんどんトーンジャンプが発生するためだと考えられます。従って、色空間の異なる画像の色数を比較・計測する際に、色空間をsRGBに変換・統一して保存しなおす必要がある場合は、GIMP上で変換せずに、色の補間機能のあるRawTherapeeやdarktableで読み込んで色空間をsRGBに変換したファイルをGIMPやIrfanViewに読ませるようにしたほうが良いと思います。
因みに、私の記事ではすでに何度か指摘していますが、RawThrapeeやdarktableの色補間は、デモザイクのときのみ働いているのではなく、色空間の変換やその他あらゆる色調整の際にも働いているようです。このこともほとんど指摘されていないと思います。
*1:他にPaint Shop Pro でも可能なようです。以下のページをご覧ください。
