今回はCMOSカメラ、ZWOのASI294MC Proの性能評価の一環で、全ての測定の元になるADUからeへの変換のコンバージョンファクターの測定についてです。結論から言いますと、SharpCapの自動測定機能での結果と、SharpCapでマニュアルで一枚一枚撮影しその画像を自分で解析した結果がどうしても合いません

この記事は多分ほとんどの人にはめんどくさい話で、よほどでない限り興味がないことと思いますし、しかもうまく結果が出なかったものなので、公表するかどうかも迷っていたのですが、それでも自分のメモがわりに書いておこうと思います。ご容赦ください。


動機

もともとダークノイズを評価する過程の一環で進めているのですが、今回の測定の動機は2つあります。
  1. ダークノイズの測定は多岐に渡るので、まずは解析環境をpythonで整えようとするのにちょうどいい練習になる
  2. 天体用CMOSカメラだけでなく、一眼レフカメラの性能評価もできないかと思ったから
です。特にEOS 6Dのユニティーゲイン(ADUとeの比が1になるゲイン)、引いてはコンバージョンファクターの測定まで自前でできたらなと目論んでいたのですが、今のところ見事に失敗。

最近ブログをなかなか更新できなかったのは、天気が悪くて星が見えないとか、仕事が忙しいとかもありますが、この解析が全然うまくいかなくてずっと悩んでいたというのが、一番大きな理由です。


測定方法

各画像の撮影はSharpCapで撮影します。共通の設定は
  • iPadのColor Screenというソフトを光源とした
  • RAW16
  • Gain = 0
  • Brightness = 8
  • White Bal(R) = 50
  • White Bal(B) = 50
  • 温度15度程度(コントロールなし)
となります。この状態で露光時間を変更して10枚程度の画像を撮影します。上記設定や露光時間はSharpCapでのセンサー性能を測る時のパラメーターを参考にしています。というか、最初適当に設定していたのですが、結果が全然合わないので、最後はコンバージョンファクターを測る時の状況に限りなく合わせるようにしました。

ゴールとしては下の写真(SharpCapのセンサー性能測定機能で自動測定した場合)の

IMG_3260

右のようなグラフが得られればOKです。横軸(各ピクセルの明るさ)が10000程度の時に縦軸(ノイズの2乗)が2500程度です。グラフの傾きは0.25程度、その傾きの逆数が今回求めたいコンバージョンファクターになり、普通に測定すると1/0.25=4程度になるはずです。この値はZWOが示している値ともほぼ一致しています。

コンバージョンファクターはちょっと理解が大変かもしれませんが、関係式と意味についてはこのページの1のところに、式の証明についてはこのページの一番最後のおまけのところに書いてあります。


測定結果

ところが自分で測定してみた結果は散々なものです。普通に画像を撮影してそのまま何も考えずに解析すると、そもそもDebayerもされていなかったりするので、ノイズが大きく出すぎてしまいます。結果を見せるのもあほらしいのですが、

mymag_all


のようになり、SharpCapの結果にカスリもしないくらいノイズが大きく出てしまっています。傾きが30くらい、コンバージョンファクターは0.03とかで、メーカー値の100分の1以下です。ここから苦難のノイズハンティングの道が始まりました。結局やったことをまとめると
  1. SharpCapでfitsファイルを撮影
  2. PixInsightでCosmeticCorrectionでホット、クールピクセルを除去 (飛び抜けて明るいピクセルなどあるとばらつきが大きく出てしまう)
  3. PixInsightでDebayerをしてカラー化 (RGBでゲインが多少違うため、debayerせずに標準偏差を取るとばらつきが大きく出てしまう)
  4. PixInsightでR、G、B画像に分離し、一枚一枚を個別に保存する (今回解析に使ったirafは天文研究に使われるソフトで、モノクロがほぼ前提なので、カラー画像を解析できない)
  5. 中心近くの50x50ピクセルのみを選択して解析 (画像全体だと周辺減光などの影響で、ばらつきが大きく出てしまう)

4番まで進めた時のグラフが

mymag _rgb_all


のようになりますが、まだ傾きが10程度、コンバージョンファクターにして0.1程度しかありません。

さらに5番目の中心部分のみを解析するようにして、やっと下のグラフくらいにまでなりました。

mymag_rgb_cut


それでも結局傾きが0.35程度、コンバージョンファクターが1/0.35で3程度になり、どうしてもまだ4近くにまでなりません。

考察と今後

なぜこの差が縮まらないか、もう少し検証します。まず、横軸(各ピクセルの明るさ)が10000の時に縦軸(ノイズの2乗)が2500くらいになるためには、ノイズはそのルートの50程度でなければなりません。ではノイズと言っているものが何かと言うと、画像から測定したピクセルの明るさのばらつきということなので、普通は標準偏差(standard deviation)をとればいいと思われます。この標準偏差を求めるのに今回は天文研究でよく使われているirafを使いました。ところが、明るさ10000程度の50x50ピクセルの明るさのばらつきの標準偏差をirafで測定すると60程度になってしまいます。グラフの横軸でいうと2乗なので3600程度になってしまうわけです。

ここでirafを疑いました。何か間違った結果が出ているのではと思ったのです。そこでPixInsightの統計ツールで測定したのですが、標準偏差はやはり60程度とでます。それどころか、SharpCapでも画像の選択したあるエリアの各色の標準偏差をリアルタイムで測定できるのですが、それもやはり60程度なのです。

SharpCapで測定しても60とでるならば、SharpCapの自動センサー性能測定の測定はどうやってやっているのでしょうか?何か特別なことをやって50と出しているのか、それともまだ私が何か勘違いをしているのか

PixInsightの統計ツールで少しヒントになるようなものを見つけました。標準偏差ではなくてオプションでAverage absolute deviationという値を出すことができるのですが、この値がちょうど50程度になるのです。

IMG_6410
標準偏差(stdDev)が60ちょい、Average absolute deviation(avgDev)が
50切るくらいになっているのがわかると思います。

Average absolute deviationのは一般的にはMean absolute average (around the mean)というらしくて日本語では単純に平均偏差というらしいです。標準偏差が各値(Xi)から平均値(M)を引いたものを2乗したものの総和を総数Nで割ったもの

1Ni=0N(XiM)2

に対して平均偏差は各値から平均値を引いたものの絶対値の総和を総数で割ったもの

1Ni=0N(XiM)

となります。他にもMean absolute average (around the median)というのもありますが、こちらは平均値を引く代わりに中心値を引きます。

標準偏差が2乗和のルートになるので、ばらつきがより効いてくることになり一般的に

標準偏差 > 平均偏差

となるそうで、確かに標準偏差より小さい値になっていて納得です。

さて、平均偏差を使えば、メーカー値もしくはSharpCapで測定した値に近い結果が出るはずなのですが、そもそも平均偏差を使っていいものなのか?やはり普通に考えると標準偏差を使った方が、あとの統計的な評価が簡単になりそうで、素直な気がします。

さらに、irafなどの一般的な解析ツールでは平均偏差を出すことができるものが少ないので、グラフまで出せるくらいにきちんと解析するのなら自前で統計処理の部分のコードを書く必要があります。

そんなこんなで、今pythondで書いているのですが、果たしてこの方向が正しいのかどうか?
まだ色々迷っています。