昨日の記事の続きです。やっとなんとか形になりました。
ノイズを標準偏差で評価するか、平均偏差で評価するか迷っていたのですが、Twitteでガウス分布から外れているのなら飛んだ値が多いはずなので、（飛んだ値に影響されにくい）平均偏差の方がいいのではという意見をもらいました。なるほど、考えてみればその通りで、標準偏差と平均偏差にすでに無視できないような有意な差があるということは、いいかえてみればガウス分布から外れた値も多いということが言えるのではと思います。
というわけで実際にヒストグラムで分布を見てみました。まず、debayerなど何の処理もしていないRAW画像です。
見ての通り、ガウス分布からかなり外れていることがわかります。これはRGBでそれぞれ反応が違うために山がいくつもできるのかと思われます。
次に、同じ画像をdebayerしてRed、Green、Blueに分けたヒストグラムものを示します。
まずはRed:
次にGreen:
最後にBlue:
不思議なのは、RGBに分離しても山がいくつも見えることです。debayerの際に周りのピクセルの状況も読み込んでいるからなのか、もしくは画面の中で場所によって明るさに違いがあって、それが山になっているのかもしれません。また、RGBを合わせてもRAWの山の形になりそうもないことも不思議です。一瞬違う画像を処理したかと思ってしまったのですが、きちんと確認しても同じRAW画像から分離したものです。debayerもそんなに単純でないようです。
最後に、その中の50x50ピクセルを取り出してきた場合のヒストグラムです。
山がいくつもあるようなことはなくなり、大まかな形としてはガウス分布にだいぶん近づきます。それでもサンプル数が少ないことによるばらつきがあるのも確かなので、ここでは平均偏差でいくのが良いと考えることにします。
さて、実際にコンバージョンファクターを求めてみました。サンプル数を多くするために画像中心付近の100x100ピクセルを選んで解析しています。
結局今回はPythonで平均偏差を求めるルーチンをを自前で書いて、各ピクセルごとに計算しています。書き忘れてましたが上のヒストグラムも全部Pythonで書いています。やっとPythonでの画像解析に慣れてきました。結果ですが、以下のようになります。
ついにここまでくることができました。結果はグラフの中にも数値で書いてありますが、コンバージョンファクターとして4.12、そこから計算できるUnity gainが200 x log10(4.12) = 123となり、メーカー値の117とわずか0.6dB、1.07倍の誤差くらいの範囲で求めることができました。
もう少し検証してみます。
上のようなSharpCapでの自動測定の結果のグラフと比べると、自動測定の測定値を伸ばしていくと0点近くに行きますが、自分で測定したものは0点に向かわずに、y切片で-352くらいのところにあたります。本当にきちんと測定しようとするならバイアスノイズをのぞいたり、フラット補正をすべきなのですが、今回は省いています。それでもSharpCapもそれ専用の測定はしていないように見えるので、うまくy切片が0になるような補正をかけているものと考えられます。
もう一点、自動測定の場合、測定点がいくつか重なっているように見えます。おそらくこれはRGBと分解した3点が重なっていると推測されるのですが、それにしても横軸(ADU)が一致しすぎています。普通に測定すると、自分で測定した時みたいにRGBで光源も違えばセンサーのフィルター特性も違うはずなので、ずれるはずです。これもSharpCapの自動測定では何らかの補正をしているものと思われます。
結局、上の結果を得るまでに2週間くらいかかりました。色々苦労しましたが得たものも多く、まずPythonでの画像解析の環境がだいぶ揃いました。既存ライブラリに頼らない、ピクセルごとに解析する手法もある程度得ることもできました。統計的にどのようにアプローチすればいいのかも少し学ぶことができました。
次はEOS 6Dのユニティーゲインを求めることでしょうか。
あー、ホントはCP+行きたかったです。
続きの記事。
ノイズを標準偏差で評価するか、平均偏差で評価するか迷っていたのですが、Twitteでガウス分布から外れているのなら飛んだ値が多いはずなので、（飛んだ値に影響されにくい）平均偏差の方がいいのではという意見をもらいました。なるほど、考えてみればその通りで、標準偏差と平均偏差にすでに無視できないような有意な差があるということは、いいかえてみればガウス分布から外れた値も多いということが言えるのではと思います。
Fits画像のhistogram
というわけで実際にヒストグラムで分布を見てみました。まず、debayerなど何の処理もしていないRAW画像です。
見ての通り、ガウス分布からかなり外れていることがわかります。これはRGBでそれぞれ反応が違うために山がいくつもできるのかと思われます。
次に、同じ画像をdebayerしてRed、Green、Blueに分けたヒストグラムものを示します。
まずはRed:
最後にBlue:
不思議なのは、RGBに分離しても山がいくつも見えることです。debayerの際に周りのピクセルの状況も読み込んでいるからなのか、もしくは画面の中で場所によって明るさに違いがあって、それが山になっているのかもしれません。また、RGBを合わせてもRAWの山の形になりそうもないことも不思議です。一瞬違う画像を処理したかと思ってしまったのですが、きちんと確認しても同じRAW画像から分離したものです。debayerもそんなに単純でないようです。
最後に、その中の50x50ピクセルを取り出してきた場合のヒストグラムです。
Conversion Factor
さて、実際にコンバージョンファクターを求めてみました。サンプル数を多くするために画像中心付近の100x100ピクセルを選んで解析しています。
結局今回はPythonで平均偏差を求めるルーチンをを自前で書いて、各ピクセルごとに計算しています。書き忘れてましたが上のヒストグラムも全部Pythonで書いています。やっとPythonでの画像解析に慣れてきました。結果ですが、以下のようになります。
ついにここまでくることができました。結果はグラフの中にも数値で書いてありますが、コンバージョンファクターとして4.12、そこから計算できるUnity gainが200 x log10(4.12) = 123となり、メーカー値の117とわずか0.6dB、1.07倍の誤差くらいの範囲で求めることができました。
検証
もう少し検証してみます。
上のようなSharpCapでの自動測定の結果のグラフと比べると、自動測定の測定値を伸ばしていくと0点近くに行きますが、自分で測定したものは0点に向かわずに、y切片で-352くらいのところにあたります。本当にきちんと測定しようとするならバイアスノイズをのぞいたり、フラット補正をすべきなのですが、今回は省いています。それでもSharpCapもそれ専用の測定はしていないように見えるので、うまくy切片が0になるような補正をかけているものと考えられます。
もう一点、自動測定の場合、測定点がいくつか重なっているように見えます。おそらくこれはRGBと分解した3点が重なっていると推測されるのですが、それにしても横軸(ADU)が一致しすぎています。普通に測定すると、自分で測定した時みたいにRGBで光源も違えばセンサーのフィルター特性も違うはずなので、ずれるはずです。これもSharpCapの自動測定では何らかの補正をしているものと思われます。
まとめ
結局、上の結果を得るまでに2週間くらいかかりました。色々苦労しましたが得たものも多く、まずPythonでの画像解析の環境がだいぶ揃いました。既存ライブラリに頼らない、ピクセルごとに解析する手法もある程度得ることもできました。統計的にどのようにアプローチすればいいのかも少し学ぶことができました。
次はEOS 6Dのユニティーゲインを求めることでしょうか。
あー、ホントはCP+行きたかったです。
続きの記事。
