ほしぞloveログ

天体観測始めました。

カテゴリ:カメラ > ASI294MC Pro

SV405CCとの比較で、ASI294MCでの北アメリカ星雲の画像処理中に、点状の多数のノイズが出現しました。普段こんなのみたことがありません。

masterLight_180_00s_FILTER_NoFilter_RGB_integration1_Preview01

原因を探ったら、どうやらフラットに同様のノイズが載っていて、そのフラットを使って補正処理したためと分かりました。

_2022_06_18_15_48_32_Preview01
あるフラットフレーム1枚の中心部500x300ドットくらいをストレッチしたもの。

フラットフレームは0度に冷却して撮影しました。拡大してみないと分からないような細かい一様のノイズなので、撮影時はOKと判断してしまいました。個々のフラットフレーム全部に点々が散りばめられていて、そのため同様のマスターフラットができてしまたようです。

どうもこれセンサー面が結露してしまったことで起きる現象のようです。昼間の部屋で0℃に冷却してフラットをとった場合、再現性はあるようなので、今後フラットは多少部屋が暑くても常温で撮影するようにします。

ちなみに、SV405CCも同様に冷却してフラット撮影したのですが、このような現象は見られませんでした。実は今回あまりに部屋が暑かったので、最初にSV405CCで冷却してフラット撮影していて、それに条件を合わせようとして(普段は常温でフラット撮影しているのに)ASI294MC Proでも冷却してフラット撮影してみてはまったというわけです。

常温でフラットを取り直していたため、当時余分に時間がかかってしまいましたが、その結果下のように見事にノイズは消えました。

_2022_06_19_16_38_23_NGC_7000_FLAT__0_20s_g120_23_50c_0068_cut

その後、これらのフラットフレームを使い、改めて画像処理をし直したら、下の写真のようにノイズは消えたので、ライトフレーム撮影時には結露のようなことは起こっていなかったと判断できてほっとしています。
 
masterLight_180_00s_FILTER_NoFilter_RGB_integration_Preview01

 

  1. SV405CCの評価(その1): センサー編 
  2. SV405CCの評価(その2): 撮影編 
  3. SV405CCの評価(その3): 画像比較
  4. SV405CCの評価(その4): 新ドライバーでの画像比較
  5. SV405CCの評価(その5): 青ズレの調査と作例
  6. 番外編1: 階調が出ない時のPedestalの効果
  7. 番外編2: ASI294MC Proでの結露
 

昨日の記事の続きです。やっとなんとか形になりました。

ノイズを標準偏差で評価するか、平均偏差で評価するか迷っていたのですが、Twitteでガウス分布から外れているのなら飛んだ値が多いはずなので、(飛んだ値に影響されにくい)平均偏差の方がいいのではという意見をもらいました。なるほど、考えてみればその通りで、標準偏差と平均偏差にすでに無視できないような有意な差があるということは、いいかえてみればガウス分布から外れた値も多いということが言えるのではと思います。

Fits画像のhistogram


というわけで実際にヒストグラムで分布を見てみました。まず、debayerなど何の処理もしていないRAW画像です。 

histgram_raw

見ての通り、ガウス分布からかなり外れていることがわかります。これはRGBでそれぞれ反応が違うために山がいくつもできるのかと思われます。

次に、同じ画像をdebayerしてRed、Green、Blueに分けたヒストグラムものを示します。

まずはRed:
histgram_R
次にGreen:
histgram_G

最後にBlue:
histgram_B


不思議なのは、RGBに分離しても山がいくつも見えることです。debayerの際に周りのピクセルの状況も読み込んでいるからなのか、もしくは画面の中で場所によって明るさに違いがあって、それが山になっているのかもしれません。また、RGBを合わせてもRAWの山の形になりそうもないことも不思議です。一瞬違う画像を処理したかと思ってしまったのですが、きちんと確認しても同じRAW画像から分離したものです。debayerもそんなに単純でないようです。

最後に、その中の50x50ピクセルを取り出してきた場合のヒストグラムです。
histgram_50x50
山がいくつもあるようなことはなくなり、大まかな形としてはガウス分布にだいぶん近づきます。それでもサンプル数が少ないことによるばらつきがあるのも確かなので、ここでは平均偏差でいくのが良いと考えることにします。



Conversion Factor

さて、実際にコンバージョンファクターを求めてみました。サンプル数を多くするために画像中心付近の100x100ピクセルを選んで解析しています。

結局今回はPythonで平均偏差を求めるルーチンをを自前で書いて、各ピクセルごとに計算しています。書き忘れてましたが上のヒストグラムも全部Pythonで書いています。やっとPythonでの画像解析に慣れてきました。結果ですが、以下のようになります。

20190302_01_Conversion_Factor

ついにここまでくることができました。結果はグラフの中にも数値で書いてありますが、コンバージョンファクターとして4.12、そこから計算できるUnity gainが200 x log10(4.12) = 123となり、メーカー値の117とわずか0.6dB、1.07倍の誤差くらいの範囲で求めることができました。

検証


もう少し検証してみます。

IMG_3262

上のようなSharpCapでの自動測定の結果のグラフと比べると、自動測定の測定値を伸ばしていくと0点近くに行きますが、自分で測定したものは0点に向かわずに、y切片で-352くらいのところにあたります。本当にきちんと測定しようとするならバイアスノイズをのぞいたり、フラット補正をすべきなのですが、今回は省いています。それでもSharpCapもそれ専用の測定はしていないように見えるので、うまくy切片が0になるような補正をかけているものと考えられます。

もう一点、自動測定の場合、測定点がいくつか重なっているように見えます。おそらくこれはRGBと分解した3点が重なっていると推測されるのですが、それにしても横軸(ADU)が一致しすぎています。普通に測定すると、自分で測定した時みたいにRGBで光源も違えばセンサーのフィルター特性も違うはずなので、ずれるはずです。これもSharpCapの自動測定では何らかの補正をしているものと思われます。


まとめ

結局、上の結果を得るまでに2週間くらいかかりました。色々苦労しましたが得たものも多く、まずPythonでの画像解析の環境がだいぶ揃いました。既存ライブラリに頼らない、ピクセルごとに解析する手法もある程度得ることもできました。統計的にどのようにアプローチすればいいのかも少し学ぶことができました。

次はEOS 6Dのユニティーゲインを求めることでしょうか。
あー、ホントはCP+行きたかったです。


続きの記事。


今回は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で書いているのですが、果たしてこの方向が正しいのかどうか?
まだ色々迷っています。


続きの記事です。



バイアスノイズで少しやり残したことがあるので、試しておきます。


疑問: バイアスフレームをマスターバイアスで補正してみたら?

前回、バイアスフレームを何枚かスタックしてリードノイズを求めてみましたが、枚数のルートで減っていくはずのリードノイズが実際には理論通りに減っていきませんでした。すべてのバイアスフレームに載っている共通のノイズがあると考えられたからです。

それでは、多数のバイアスフレームをスタックして最後に残った共通のバイアスノイズ(PixInsight用語では「マスターバイアス」というそうです)で、各バイアスフレームを補正してから、改めて何枚もスタックしたらどうなるのでしょうか?面白そうなので試してみましょう。


予測

単純に考えるとこんな予想ができます。
  • 前回の測定で、最後まで残った全バアスフレームに共通にあるノイズがさっぴかれるので、理想的に枚数のルートに比例してノイズが少なくなっていく。
  • 最終的にはあるオフセット(一定の輝度という意味)を持った、のっぺりした画像になる。
この予想は、実際に試す前に頭だけで考えたものです。さて本当にそうなるのか、もし違ったとしても実際にどこまで迫れることやら。


測定

さて、実際に試してみましょう。

マスターバイアスは再現性もチェックするために、前回撮影したのとは別に新たに撮影し直しました。枚数ですが、できる限りノイズの少ないものということで、1024枚重ね(て平均し)たものにします。このマスターバイアスで各バイアスフレームを先に補正してから1024枚スタックします。それでもノイズは単に理想的なものを1024枚重ねたものより、(マスターバイアスが足し合わさった分)ルート2倍大きくなるはずです。その分だけ理想的な枚数のルートでノイズが改善されるというのからはずれてくると思います。(と、ここら辺のズレくらいまで実際の測定前に頭の中で考えました。)

また、バイアスフレームも新たに撮影しました。マスターバイアスを作った際の1024枚でもいいのかと思ったのですが、それだと同じものから同じものを引いただけになってしまい、本来残って欲しいノイズもゼロになってしまうかと思ったからです。


結果


今回も1、4、16、64、256、1024枚の比較です。青色の理想的な場合と、緑色のマスターバイアスで補正されたもの赤色のマスターバイアスで補正されていない(前回と同じ)ものを載せています。あと、わかりやすいように縦軸をlogスケールにしました。理想的だとグラフは直線になります。

03_readnoise_vs_gain_02_masterbias


考察

さて、結果を改めて見てみます。マスターバイアスで補正したものは明らかに理想的なラインに近づいています。1024枚の時は同じ程度の(相関のない)ランダムなノイズを2回足し合わせていることになるので、理想的な場合に比べてルート2倍程度大きくなるはずです。無相関なノイズは足しても引いても2乗和のルートになるので、ルート2倍ということです。1.4倍くらいのはずが、実際には1.8倍くらいなので、それでも理論値より少しだけ大きい値になっているようです。256枚のところにも少なからずその影響が出ています。計算上は1.25のルートなので、1.18倍ですが、実際には1.24倍です。さらにマスターバイアスの枚数を増やせば1024枚のところでももっと理想的なラインに近づいてくるでしょう。


少し補足です。まずは1枚重ねで単純にマスターバイアスを引くことを試したのですが、平均値が同じものを差っ引くことになってしまうので、ADU(輝度)が0付近に行ってしまい、その影響で標準偏差も0に近い小さな値になってしまうことがわかりました。そのため次のようにして解決しています。
  1. まずマスターバイアスの平均値の半分の輝度を持ち、標準偏差0の全くのっぺりした画像を、PixInsightのNewImageで作成します。
  2. それをマスターバイアスから引くことで、マスターバイアスの平均値を半分にしました。
  3. そうやって作ったマスターバイアスを、それぞれのバイアスフレームから引きます。
  4. その結果、平均値が輝度0より十分に大きな、マスターバイアスで補正されたバイアスフレームを作り出しました。
IMG_6322


この過程を経て初めて正しそうな結果を得ることができました。


もう一つ、実際に処理した画像を比べてみましょう。左上の奥のがマスターバイアス補正をしていないもの、右下の手前の画像がマスター補正をしたもの。ともに1024枚スタックした時の画像で、輝度は揃えてありますす。

IMG_6328

PCの画面を直接撮影したので、モアレが少し残ってしまっています。見にくいところもあると思うのですが、それでもマスターバイアスで補正をすると残っていた縦線が明らかに消えているのがよくわかると思います。



まとめ

今回わかったことまとめておきます。
  • 全バイアスフレームに載っている共通のコモンノイズが存在する。
  • そのノイズは、多数枚のバイアスフレームをスタックして作ったマスターバイアスを使って、補正することができる。ただし、オフセットごと補正してしまうことに注意。
  • バイアスコモンノイズをさっ引いたバイアスフレームはかなり理想的なランダムノイズに近い。
と言ったところでしょうか。

うーん、今回はかなり予想通りにいったので、結構満足です。予測できなかったところは、マスターバイアスで単純に補正すると平均値が0になってしまい、ばらつきも少なくでしまうことでした。これは通常の画像処理でいう、オフセットをあげて暗い部分を切ることに相当します。

というわけで、画像処理は嘘をつかないということがかなりわかってきました、、、と言いたいところなのですが、すでに少しダークノイズを試していて、こちらはなかなか一筋縄ではいかないみたいです。また余裕ができたらまとめます。


それはそうと、今回新たにバイアスファイルを2000枚ほども撮影してしまいました。すでに合計3000枚、あぷらなーとさんにだんだん迫ってきてしまいました。やばい、これはやばい。まっとうな道を行きたかったのに(笑)。




 

今回はASI294MC Proのバイアスフレームについて色々検証してみました。結構面白い結果が出たのでまとめておきます。


はじめに

昨日の昼間、めずらしくものすごい快晴。これはと思い、早速夜からカモメ星雲を撮影しようと準備をして、やっと撮影を始めたらわずか数枚で雲がもくもく。こんな日はむしゃくしゃするので、諦めてASI294MC Proの評価の続きです。

さて、大きな目的としては、前回の課題の一つダークノイズがどれくらい撮影に影響があるかですが、今回はその前々段階くらいにあたる、リードノイズのいろいろなテストです。実はあぷらなーとさんの解析に触発され、自分でももう少し泥臭い検証をしてみたくなりました。


バイアスフレーム一枚からのリードノイズの算出

あぷらなーとさんが自作ツールでバイアスフレームを解析し、見事メーカーが公表しているリードノイズと値が一致しました。私も前回の記事でSharpCapのSensor Analysis機能を使うことで、メーカー値と同じ値を確認したのですが、もう少し自由に測定できないか試したくなりました。それでも独自ツールを作るのは大変なので、今回はPixInsightの「ImageInspection」の「Statistics」を使いってリードノイズを求めたいと思います。

まず、SharpCapを使い、ASI294MC Proのバイアスフレームを撮影します。条件は
  • モード: RAW16 (16bit)
  • 露光時間: 0.0032ms
  • Gain: 121
  • Brightness(オフセット): 20
  • ホワイトバランス: Red 50, Blue 50
とします。それをPixInsightで読み込み、Statisticsツールを起動し、開いた画像を選択します。

IMG_6308


Statisticsツールでは「14bit [0,16383]」を選び「Normalized」にチェックを入れます。その時のavgDevの値を読みます。この場合、2.1でした。単位はADUなので、eに変換するためにコンバージョンファクターを使います。前回の測定から

IMG_6283

ゲイン121のところ見ると、0.88とあります。先ほどの2.1 [ADU]にこの0.88 [e/ADU]をかけると1.85 [e]となります。SharpCapで測定した値が1.86 [e]なのでほぼ正しい値が出ているようです。

ちなみにコンバージョンファクターがわからない時は、あぷらなーとさんのブログの記事でも紹介されていたように、ユニティーゲイン (UG、eとADUが同じになるゲインのこと、すなわちコンバージョンファクターが1ということ)から求めても同じことです。メーカーによるとUGが117とのことです。ゲイン121の時とは(117-121)/10=-0.4dB違うので、10^(-0.4/20) = 0.95となります。コンバージョンファクターも0.95倍すればいいので0.95 [e/ADU]となります。SharpCapの実測の0.88 [e/ADU]とは少し違いますが、UGをメーカー値としたためこれくらいのズレはあり得るでしょう。UGが正しいとしてリードノイズを求めると、2.1 [ADU] x 0.95 [e/ADU] = 2.00 [e]となりますが、それでもそれほどのズレではないです。


ちょっと脱線します。SharpCapで測定したデータですが、実際に測定しているところは

Gain Value e/ADU Read Noise (e) Full Well (e) Relative Gain Rel. Gain (db) Dynamic Range (Stops)
0 3.99686 7.80246 65484.6 1 0 13.0349
59 2.04740 6.86512 33544.6 1.95217 5.81034 12.2545
61 1.99842 6.83844 32742.1 2.00001 6.02064 12.2252
100 1.28103 6.34598 20988.4 3.12004 9.88322 11.6915
119 1.03257 6.11416 16917.6 3.87080 11.7560 11.4341
121 0.88019 1.85936 14421.0 4.54092 13.1429 12.9211
200 0.35776 1.59308 5861.64 11.1717 20.9624 11.8453
300 0.11418 1.41354 1870.75 35.0044 30.8825 10.3701
400 0.03624 1.35693 593.803 110.280 40.8499 8.77350
500 0.01171 1.32912 191.794 341.432 50.6661 7.17294

だけで、あとは全て計算値です。このことは、例えばFull Wellの値とRelative Gainをかけてみると、全てのゲインで65484.6(上の表は小さな桁を丸めてあるので少しずれます。)と同じ値になり、さらにこれにゲイン0の時のe/ADUの値3.996863906をかけるとぴったりと14bitで整数値の16384になることなどでわかります。Full Wellは本来サチルくらいの光量をカメラに入れて測定から求めるべきなのですが、SharpCapは14bitの最大値をサチった値と仮定して簡易的に求めていることもわかります。ZWOのメーカー値もどうやら同じように測定されているみたいなので、これはこれでありなのかもしれません。


さて、本題に戻ります。一例としてゲイン120の場合で計算してみましたが、他のゲインはどうでしょうか?他のゲインの値も、実際に撮影した画像からPixInsightを使ってリードノイズの値を求めてみたので、グラフにしてみます。赤がSharpCapのSensor Analysis機能で測定した線青がPixInsightを使って一枚一枚マニュアルで求めた線です。

03_readnoise_vs_gain1


グラフを見ても、SharpCapとマニュアル測定の差はほとんど誤差の範囲だとわかります。

というわけで、PixInsightを使うことで、リードノイズの値を画像からいつでも求めることができるという手法を手に入れたということになります。



バイアス画像を多数枚スタックするとどうなるか?

とりあえず、簡単にリードノイズを測定することができるようになったので、色々やってみたいと思います。

まずは、これらバイアスフレームを多数枚スタックするとどうなるのでしょうか?

スタックするとばらつきが平均化されるので、もしバイアスフレームに存在するノイズが完全にランダムなら、理想的には枚数のルートに比例してノイズが小さくなっていくはずです。

2、4、16、256、1024枚と、枚数を増やして、上と同様にPixInsightで実測したリードノイズの値を求めてみました。その結果をグラフに示します。理想の場合(青線)と、実際にスタックした場合(赤線)での比較になります。スタックはPixInsightのIntegration機能を使いました。蛇足になりますが、Macbook Proでスタックした場合4144x2822の16bitのfits画像1024枚でスタック時間は7分くらいでした。これくらいなら待つことができます。



03_readnoise_vs_gain2


グラフを見るとわかりますが、理想的なノイズの減り方に比べて、実測の方が明らかにノイズの減り具合が悪いです。これはなぜなのでしょうか?


実際のスタックしたバイアス画像を見比べてみる

この謎を解決するために、実際にスタックした画像を見比べてみましょう。まずはこちら、

IMG_6310


左上の奥の画像から1、4、16枚、最後の右下手前の画像が256枚重ねたものです。輝度は1枚ときの画像に全て合わせているので、直接見比べることができます。ぱっと見てわかるのは、枚数が多くなると明らかにノイズが滑らかになっていることでしょうか。これを見る限りは理想的にはどんどんノイズ(ばらつき具合)は少なくなっていってもいいはずです。


では次に、同じ画像で輝度を256枚重ねた画像に合わせてみましょう。

IMG_6312


前は綺麗に見えていた256枚画像も、実は完全にランダムなノイズではないことがわかります。縦線みたいなものが残っています。逆に1枚の時には横線が目立っています。これは横線に関してはランダムに近いノイズで、枚数を重ねることで滑らかになっていくのですが、それでも全枚数に共通に存在する縦縞のノイズが残ってしまい、それがグラフでの理想値との差を生むと推測されます。実際に1枚重ねだけの画像を何枚も見比べてみると、横線がてんでバラバラに入っていることがわかります。

ここからわかることは、
  • 多数のバイアスフレームを使うのは、バイアスフレームのランダムに存在するノイズを減少させるため。
  • バイアスフレームでライトフレームを補正するのは、スタックしたバイアスでさえも残った、バイアスフレーム全てが持つ共通のノイズを除くため。
ということが言えるのではと思います。

まとめ


はあ、ババーッとまとめてさすがに疲れたので、今日はこれくらいにします。まだまだ面白いことはあるのですが、さすがに書くスピードの方が追いつきません。さて、今日のまとめです。
  • 単体のバイアスフレームから、リードノイズを見積もることができる。
  • SharpCapも全部のゲインで全部の測定をしているわけでなく、一部を測定して、あとは計算で出している。
  • バイアスフレームをスタックすると、ノイズは減っていくくが、無限に小さくなるわけではない。
  • バイアスフレーム全てに共通するノイズが存在し、それらはバイアス補正でライトフレームから差っ引くことができる。
といったところでしょうか。

ちなみに、あぷらなーとさんはバイアス解析だけ1万枚も撮影するというような、言わずと知れた変な人です。私はたかだか千枚ほどしか撮影していないので、あぷらなーとさんに比べて10分の1くらいしか変でないということがわかってもらえると思います。






このページのトップヘ