ほしぞloveログ

天体観測始めました。

タグ:読み出しノイズ

CP+連動企画、「電視観望技術を利用して天体写真を撮影してみよう」ですが、前回でやっとオリオン大星雲の撮影を開始することができました。


機材の設置からソフトの設定まで、やはり工程が多いですよね。天体写真撮影が敷居が高いと言われるはずです。それでも電視観望でオートストレッチまで済んでいるので、画像処理は楽になるはずです。そこら辺をCP+でお見せできたらと思っています。


オートストレッチ

前回の記事で重要なことを一つ書き忘れていました。画像保存時におけるホワイトバランスの重要性です。

ライブスタック中に普段画面を見る時からでいいので、3つのことをしておくといいです。
  • ライブスタック画面の「Histogram」タブを開き、左のカラーバーの下にある雷マークアイコンを押し、ホワイトバランスを整えます。
ホワイトバランスはすごく重要で、これができてないとオートストレッチがうまくいかないことがあります。オートストレッチに関しては前回も説明していますが、
  • 次に同じくライブスタック画面の「Histogram」の左の上のもう一つの雷マークアイコンを押し、オートストレッチします。
  • 新たに右パネル「ヒストグラムストレッチ」の方の雷マークを押し、さらに炙り出します。もし画像が明るすぎる場合は、右側パネルのヒストグラムの、山を挟んでいる左と真ん中の2本の線を少し動かしてみるといいでしょう。

今回の記事もこのような状態で画像を保存したものを使っています。


検証項目

撮影までに赤道儀の設置や、オートガイドを使った長時間撮影など、それなりに準備だけでも大変でした。電視観望の技術を使い、ここからの画像処理は楽になるとしても、ここまでの準備をもう少し簡単にできないものなのでしょうか?今回はいろいろ設定を変えてみることで、簡単になるのかどうか議論してみます。

今回比較したいものを準備が簡単な順に並べてみます。矢印の右側は、予想される問題点です。
  1. 経緯台AZ-GTiでの10秒露光 → 露光時間に制限がある(10秒程度)、視野回転、縞ノイズが問題になる
  2. 経緯台AZ-GTiでの10秒露光+ディザー → 露光時間に制限がある(10秒程度)、視野回転
  3. 赤道儀SA-GTiでの20秒露光 → ピリオディックモーションのために縞ノイズが問題になる
  4. 赤道儀SA-GTiでの20秒露光+ディザー → 露光時間に制限がある(20秒程度)
  5. 赤道儀SA-GTiでの60秒露光+ディザー+ガイド 
  6. 赤道儀SA-GTiでの3秒露光でゲインを0に下げる+ディザー+ガイド → 読み出しノイズが顕著になる
順に詳しく見ていきます。


1. 経緯台AZ-GTiでの10秒露光 (ガイドなし、ディザーなし)

まず対極で、できる限り簡単な撮影というものをしてみましょう。

ここでは赤道儀の代わりに、自動導入機能がある経緯台AZ-GTiを使ってみます。鏡筒を軽いもの、例えばFMA135やFMA180とかなら、もっと手軽にトラバースでも構いません。特にトラバースは超小型で自動導入も自動追尾もできるので、対極という意味ではこちらの方がいいのかもしれません。トラバースについては以前撮影例を記事にしているので、よかったらご覧ください。

これらの経緯台は赤道儀と違って、極軸調整などを省くことができます。最初はオートガイドやディザー撮影も無しとします。経緯台なのですが、自動追尾はできます。それでも経緯台は縦と横とでしか動かせないので、長時間で回転していく星を追尾しようとすると、視野の回転が問題となるはずです。視野の回転はそこそこ激しいので、星像が天になるためには露光時間に制限ができます。鏡筒やカメラにもよりますが、今回の機材だと現実的には10秒程度でしょう。また視野が流れてしまうことによる「縞ノイズ」が問題になってきます。

今回使うAZ-GTiの写真です。SA-GTiの元になった機器だと思いますが、経緯台だけあってAZ-GTiもかなり小さいです。

D81DD62F-BDC9-42B4-8948-B36F477D5BA9
左がトラバース、右がAZ-GTiです。どちらもコンパクトです。

実際に撮影した結果を示します。問題を見やすくするために、かなり明るくしています。1枚当たり10秒露光で、30フレームなので高々5分程度の撮影ですが、

Stack_30frames_300s_22_40_26_WithDisplayStretch_HT

まず視野回転しているのがわかります。右下の方にずれていっている様子がわかります。ずれが三角型になっているのが、視野が回転している証拠です。多少ならば最終的にトリミングすればいいのですが、長時間撮影ではカットする部分が大きくなってしまいます。

PlayerOneのCMOSカメラにはDPS (Dead Pixel Supression)という機能があり、輝度が飽和してしまうようなホットピクセルは、輝度が0近くになってしまうコールドピクセルという、センサーにどうしても存在してしまうわずかの欠損を目立たなくしています。さらに今回、SharpCapの設定でホットピクセル/コールドピクセルの簡易除去をしていしてます。それでもホットピ/コールドピクセルのようなものが存在しているようで、高々5分の撮影でもスクラッチ状のノイズを残してしまいます。拡大するとよくわかります。

Stack_30frames_300s_22_40_26_WithDisplayStretch_HT_HT_cut

このように経緯台での簡単撮影では、回転とスクラッチ上のノイズが問題になってしまいます。でも逆に言うと、対極的に簡単な撮影でも問題点は高々これくらいです。セットアップが簡単になるなら、十分ペイするくらいのささいな問題点かもしれません。

この後に画像処理をすることで、たった5分の撮影でも、大迫力のオリオン大星雲の魅力は十分に出てきます。撮影時間が長くなるほど、縞ノイズの問題が深刻になってくることが予測されるでしょうか。許容範囲は人にも求める仕上がり具合にもよると思いますが、後の画像処理次第で十分天体写真として通用するものになるかと思います。


2. 経緯台AZ-GTiでの10秒露光 + ディザー (ガイドなし)ここに文章を入力

経緯台での簡単撮影ですが、どうせ撮影するなら一手間だけかけてみましょう。ここではオートガイドなしのディザーを提案してみます。天体写真に経験のある方だと、ガイドなしでディザーなんかできるのか?と思われる方もいるかもしれませんが、SharpCapのLiveStack撮影ではそれが可能になります。

設定方法です。
  1. SharpCapメニューの「ファイル」の「SharpCapの設定」の中の「ガイディング」タブを開きます。
  2. 下の画面のように「ガイディングアプリケーション」を3つ目の「ASCOMマウントパルス...」を選びます。
  3. 「ディザリング」の「最大ディザステップ」は、AZ-GTi単体で上の「1. 経緯台AZ-GTiでの10秒露光 (ガイドなし、ディザーなし)」で見たホットピクセルやクールピクセルをできるだけ散らしたいため、かなり大きな値にします。ここでは40としました。
  4. その代わり、AZ-GTiが十分に落ち着くように、「ディザリング」の「最大整定時間」を大きくとります。ここでは60秒としました。
  5. 最後に下の「OK」を押します。
07_guide_setting

上記設定でディザー有り、ガイドなしで撮影した結果です。先の1と同じく、10秒露光で5分間の撮影です。
Stack_30frames_300s_22_47_52_WithDisplayStretch_brighter

ホットピクセルやクールピクセルが散らされて、かなり目立たなくなっています。拡大してみます。これくらいなら十分許容範囲ではないでしょうか?
Stack_30frames_300s_22_47_52_WithDisplayStretch_brighter_cut

このように、自動導入経緯台にディザーをかけての撮影というのは、一つのシンプル撮影の到達点かと思います。それでももちろん問題はあって、
  • 視野回転は避けられないこと
  • 露光時間を長く取れない
ということです。今回は10秒程度の撮影なので星像がまともでしたが、AZ-GTiでの経緯台撮影だと20秒程度で星が流れ始めてしまいます。

この星像のずれは、視野回転影響も大きいです。経緯台でオートガイドをすることも不可能ではありませんが、思ったより大変なのと、オートガイドをしたとしても原理的に視野回転は防ぐことはできません。これ以上露光時間を伸ばしたいとすると、赤道儀に移行した方が無難と思われます。


3. 赤道儀SA-GTiでの20秒露光 (ガイドなし、ディザーなし)

というわけで、ここから再び赤道儀のSA-GTiに戻ります。

下の画像はSA-GTiで、オートガイドもディざーも無しで、露光時間を20秒として「1枚だけ」撮影した画像です。
01_single_frame_00001_20_0s_RGB_VNG

中心部付近を拡大してみますが、赤道儀ということもあり視野回転もないし、20秒程度の露光なら星像も全然流れていないことがわかります。
01_single_frame_00001_20_0s_RGB_VNG_cut

「1枚だけ」の撮影なら問題ないのですが、その一方これを例えば20秒露光で「30枚、合計10分」撮影すると何が起こるかというと、以下のようになります。
Stack_30frames_600s_20_28_37_WithDisplayStretch

気づきにくいかもしれないので、拡大します。
Stack_30frames_600s_20_28_37_WithDisplayStretch_cut
星はライブスタックで位置を確認して重ねあわているので、依然流れていません。問題はホットピクセルやクールピクセルが流れて、背景にいくつか縦方向の紫色に見えるスクラッチができているのです。

これは赤道儀のギヤの精度に起因して起こる、「ピリオディックモーション」などと呼ばれる現象が原因です。赤道儀にもよりますが8分程度の周期で、赤経方向にsin波的に揺れてしまう動きが存在します。どれくらい揺れるかは、ギヤの精度に依存します。

ライブスタック技術で、星を位置合わせして重ねるために、星自身は流れなくなっています。その代わりに、1枚1枚に存在する固定位置のホットピクセルやクールピクセルは逆に重なることはなくて、30枚の撮影で軌跡として流れるように残ってしまうというわけです。

ちなみに、今回のこの軌跡は測定してみると22ピクセル程度の長さです。鏡筒の焦点距離360mmとカメラセンサーの大きさ11.2mm x 6.3mm から、このサイトなどで画角を計算すると1.78度 x 1.00度と出ます。センサーの画素数が3856×2180なので、1.78度 x 60 x 60 = 6408秒角、これを3856で割ると、1ピクセルあたり1.79秒角となります。これが22ピクセルあるので、39.3秒角、プラスマイナスで考えると、+/-19.7秒角のピリオディックエラーということになります。この値はオリオン大星雲で測定しましたが、天の赤道付近なので、この値から大きく変わることはないでしょう(実際には赤緯-5度付近にあるので、5%程度小さく測定されています。それを補正しても+/-21秒角程度でしょう。)。以前測定したAZ-GTiを赤道儀モードで測定した値が+/-75秒角程度でした(今思うとかなり大きな値なので、再計算しましたが間違ってませんでした)から、随分と改善されていることになります。

少し脱線しましたが、このように赤道儀を使ってもピリオディックモーションからくる制限があります。これを解決するために、次はディザーを考えます。


4. 赤道儀SA-GTiでの20秒露光+ディザー  (ガイドなし)

3で見た、ピリオディックモーションでのホット/クールピクセルの軌跡をなくすために、赤道儀でディザーをしたら、どうなるでしょうか?ただし、オートガイドはなしです。露光時間20秒、総露光時間5分間です。
Stack_15frames_300s_20_57_18_WithDisplayStretch

拡大します。
Stack_15frames_300s_20_57_18_WithDisplayStretch_cut

3の時よりかなりマシになっていますが、まだ少し軌跡が残っています。これは少し設定ミスがあって、記録を見たらディザー設定の「最大ディザステップ」が10と少し小さく設定し過ぎたようです。AZ-GTiの時は40だったので、もう少し散らせばもっとまともになるかもしれません。

さて、ディザーで軌跡が少しマシになることは分かりましたが、まだ根本的な問題があります。1枚当たりの最大露光時間がピリオディックモーションで制限されているということです。例えば下の画像は、これまで通りオートガイドなしで60秒露光したものです。
Stack_1frames_60s_20_24_55_WithDisplayStretch

中心付近を拡大するとわかりますが、既に星が流れてしまっています。これは1枚撮影する間にピリオディックモーションによって星が動いてしまい、1枚の画像の中にその動きが記録されてしまうことが原因です。
Stack_1frames_60s_20_24_55_WithDisplayStretch_cut

これを避けるためには、1枚撮影している間に、星の位置を保つようにオートガイドをする必要が出てきます。


5. 赤道儀SA-GTiでの60秒露光+ディザー+ガイド

まず、20秒露光でトータル5分、ディザーあり、それにPHD2によるオートガイドを加えます。ディザーはPHD2の支配下に置かれるので、PHD2でのディザー幅の設定となり、4の時より大きな幅で動かしています。
Stack_15frames_300s_21_09_53_WithDisplayStretch

変な軌跡も完全に消えていますし、星像も流れていません

さらに条件を厳しくして、露光時間を60秒露光と伸ばして、トータルで少し長く16分、ディザーあり、それにPHD2によるオートガイドを加えたものです。
Stack_8frames_480s_21_00_44_WithDisplayStretch

このようにガイドのおかげで、長時間露光してもピリオディックモーションが出てこなくて、星流れていないのがわかります。

赤道儀を使って1枚当たりの露光時間を伸ばそうとすると、やはりガイドとディザーを使った方がいいという結果になります。


一旦まとめ

ここまでをまとめます。
  • 経緯台だろうと、赤道儀だろうと、ディザーはあった方がいい。
  • 経緯台でディザーをするならば、かなりシンプルな撮影体制を構築することができる。ただし、画角回転は避けられない。同時に、1枚当たりの露光時間も10秒程度とかなり制限される。
  • 赤道儀を使うことで画角回転は避けられるが、オートガイドを使わない場合は、ピリオディックモーションのために1枚当たりの露光時間を伸ばすことはできない。
  • 赤道儀でも露光時間を伸ばしたい場合は、オートガイドは必須。
といったところでしょうか。

ここまでで大体の検証は終わりですが、露光時間を伸ばすための努力だったと言ってもいいかもしれません。その反証として最後にもう一つ、1枚当たりの露光時間が短い場合の弊害を見てみましょう。


6. 赤道儀SA-GTiでの3秒露光でゲインを0に下げる+ディザー+ガイド

ここではこれまでのSA-GTiの赤道儀で、露光時間を3秒に下げ、さらにカメラのアナログゲインも220から0にするという、極端な場合を示します。上の5が60秒露光だったので20分の1、さらにアナログゲインが220変わっているので、220 [0.1dB] = 22 [dB] = 20 + 2 [dB] = 10 x 1.26 [倍] = 12.6 [倍]小さくなります。露光時間と合わせると、1/(20 x 12.6) = 1/252  ~ 0.004と0.4%ほどの明るさになったということです。これで100フレーム、合計300秒=5分撮影した結果です。
Stack_100frames_300s_21_28_38_WithDisplayStretch_enhanced

たくさんの縦線と、淡いですが横線も見えています。これは俗に言う「読み出しノイズ (リードノイズ)」が見えてきてしまっているということです。露光時間が短かったり、ゲインが低かったりした場合にこのような状態になります。要するに暗すぎるということです。

同じ露光時間3秒でも、アナログゲインが220の場合はかなりマシになります。1枚当たりの露光時間は上と同じ3秒、100フレームで5分間の撮影は同じです。オートガイドをしていないので、ホット/クールピクセルの軌跡は残ってしまっています。かなり炙り出しているので、縦縞はまだ見えますが、横縞に関してはほとんど無視できます。
Stack_100frames_300s_21_17_26_enhanced

背景はまだひどいですが、面白いのはオリオン大星雲の中心のトラペジウムはよく見えているということです。どうも前回までに撮影したゲイン220で1分露光は少し明るすぎるのかもしれません。中心を取るか背景を取るか、ここら辺が難しくまた面白いところです。

いずれにせよ、露光時間が短いとか、ゲインが小さいとかで、写している天体からの信号が小さい場合、読み出しノイズが支配的になって、縦横の縞ノイズが現れてきます。ホットピクセルやクールピクセルが流れる縞ノイズは斜めに流れることが多いので、このように垂直、水平にノイズが出るようならば、自分の撮影時の設定が暗すぎはしないか、一度疑ってみるといいと思います。


まとめ

いろいろ検証しましたが、結局のところ、電視観望を利用した撮影と言っても、撮影の段階で解決できることはできる限り解決しておいた方がいいということです。

今回の結果から、電視観望技術を利用した撮影方法は、主に下の2つの方法に収束すると思います。
  • 経緯台で、短時間で、ガイドなしで、ディザーを使って縞ノイズを散らす方法は、シンプルという観点から十分使う価値がある。
  • 赤道儀で長時間露光を目指すならば、オートガイドとディザーを使う方がいい。ガイドなしだとピリオディックモーションで1枚当たりの撮影時間が制限される。
といったところでしょうか。

次回は、長時間露光のパラメータを探ってみます。










今回は1ヶ月ほど前に書いたビニングの話の続きです。


ソフトウェアビニングが役に立つのかどうか...、そんな検証です。


ダイオウイカさんが釣れない...

最近ずっと自宅でダイオウイカ釣りをしています。いつまで経ってもダイオウイカさんは出てきてくれません。もうかれこれOIIIだけで10時間になりますが、全部インテグレートして、普通にオートストレッチしただけだとこんなもんで、かなり淡いです。これでもABEの4次をかけてかなり平坦化してるんですよ。

OIII_stacked_normal

今回の画像は、ε130DにASI6200MM Proでbin2で撮影しています。ゲインはHCGが作動する100、露光時間は1枚あたり5分で125枚、トータル10時間25分です。

これだけ時間をかけても高々上に出てくるくらいです。やはり自宅でのダイオウイカ釣りは難しいのでしょうか?


ビニングの効果

これ以上露光時間を伸ばすのはだんだん現実的ではなくなってきました。遠征してもっと暗いところに行けばいいのかもしれませんが、自宅でどこまで淡いところを出せるかの検証なので、限界近くを責めるのはかなり楽しいものです。

さて、こんな淡い時にはビニングです!

そもそもCMOSカメラのビニングはASI294MMなど特殊な機種でない限り、一般的にソフトウェアビニングと同等で、
  • ハードウェアビニングでは信号は4倍になる一方読み出しノイズのを一回だけ受け取ればよく、S/Nで4倍得する。
  • ソフトウェアビニングでは信号が4倍になっても読み出しノイズを4回受け取らなければならないので、4のルートの2倍ソフトウェアビニングが不利になり、S/Nとしては2倍しか得しない。逆に言えば2倍は得をする。
というものです。それでも前回議論したように、スカイノイズなど、読み出しノイズが支配的でない状況ではハードウェアビニングの有利さは活きないので、
  • 実効的には ハードウェアビニングでもソフトウェアビニングでも効果は同等で、両方ともS/Nが2倍得するだけ。
というのが重要な結論になります。

と、ここで天リフ編集長から重要な指摘がありました。
  • 「もしソフトウェアビニングで同等の効果というなら、撮影後にPC上で本当にソフトでビニングしてもいいのでは?」
というものです。理屈の上ではその通りです。でも本当にそんなに都合がいいのか?というのが疑問に残るところでしょうか。


DrizzleとBXTの組み合わせ効果

もう一つ、Drizzleをかけて分解能を2倍にして、それだけだと解像度はそこまで大きくは上がらないのですが、さらにBXTをかけると本来の2倍の解像度程度まで戻すことができるという検証を以前しました。




ここまでのことを合わせます。
  1. 2倍のビニング
  2. Drizzleのx2
  3. BXT
を使うことで、
  • S/Nを2倍得して
  • かつ分解能の犠牲を戻す
ということができるのではというのが今回考えてみたいことです。


検証

さて、上で述べたことは本当なのか?実際に検証してみましょう。ダイオウイカ星雲はものすごく淡いので、格好の検証材料です。

まずはPC上でのソフトウェアビンングの準備です。今回は、PixInsightのIntegerResampleを使います。「Resample factor」を2として、「Downsample」を選び、「Average」を選びます。Dimemsionsはいじる必要はないです。左下の三角マークをPIの画面上に落として、このインスタンスを作っておきます。あとはImageContainerで、ビニングしたい画像を全て選び、出力ディレクトリを選択したら、これも同様にインスタンスを作成します。IntegerResampleのインスタンスをImageContainerに放り込むと処理が始まり、しばらく待つとさらにbin2相当、元から見るとbin4相当の画像が出来上がります。

と、最初は結構簡単に考えていたのですが、ここから実際にWBPPで処理を進めようとすると、ダークフレーム、フラットフレーム、フラットダークフレーム全てを同様にbin2相当にしておかないとダメだということに気づきました。

さらに注意は、WBPPのReferene frameです。bin2処理をしたOIIIと何もしないHαを最後に合わせようとする場合、Referene frameに同じライトフレームを選んでおく方が楽です。その際に、bin2処理をする場合のReferene frameのみ、あらかじめbin2でダウンサンプリングしておかないと、結果が変になってしまいます。考えてみればあたりまえなのですが、気づくまでなぜか結果がおかしいと悩んでしまいました。

さて、結果を比較します。左が普通にOIIIをWBPPで処理した結果、右がダウンサンプリングでbin2(元からだとbin4)相当でさらにWBPPでDrizzle x2を適用した結果です。両方ともABEの4次をかけ、強度のオートストレッチをかけています。イカの明るい所を拡大しています

preview_s

違いがわかりますでしょうか?
  • まず恒星ですが、やはり右のビニング画像した方が大きく見えます。
  • 背景のノイズの散らばり具合は、左はトゲトゲしいですが右は丸くなっています。でもこれは単純にダウンサンプリングのせいでしょう。S/Nが良くなったかというと、うーん、見た目だけだとどうでしょうか?心持ち右が良くなったように見えなくもないですが、あまりわからないです。

背景についてはっきりさせるために、S/Nを数値で定量的に評価しましょう。比較すべきは、
  1. ノイズN: 背景と思われる何も天体が写っていない暗い部分と、
  2. 信号S: 天体と思われる、ダイオウイカの明るい部分
です。具体的には上の画像のプレビューのところを比較しました。元々の画像で位置合わせがきちんとできていることと、プレビューの位置もタグを放り込んできちんと合わせているので、公平な評価になっている思います。

測定ですが、ノイズNはPixInsightのImageInspectionのStatistics結果は「Standard deviation」で直接比較できます。問題は天体の信号Sです。同じくStatisticsの「Mean」を使いますが、そのままだと値が大きすぎてよくわかりません。ここでは、ノイズ解析でS/Nを求めた時と同じように、天体部分の輝度から背景部分の輝度を引いたものをSとします。

結果は
  • 元画像: 天体部分の輝度 411.3、背景部分の輝度: 404.6、背景部分のノイズ:1.21
  • ビニング画像: 天体部分の輝度 308.1、背景部分の輝度: 301.3、背景部分のノイズ:0.73
でした。この結果からS/Nを計算すると
  • 元画像のS/N: (411.3-404.6) / 1.21 = 5.54
  • ビニング画像のS/N: (308.1-301.3) / 0.73 = 9.32
となり、S見事に予想通り、2倍のソフトウェアビニングで2倍程度のS/Nの改善になっています。このことは、PC上のソフトウェアビニングが実際に十分な効果があるということを示しています。もちろんその分、分解能は犠牲になっています。

さて、S/Nは向上しましたが、実際に画像処理で本当に効いてくるのかどうかは興味深いところで、次の課題と言えるでしょう。


さらにBXT

ソフトウェアビニングが理屈通りに効果があることがわかってきたので、次にBXTでの分解能が改善するかを見てみましょう。これまでの議論から、Drizzle x2を欠けていることが前提です。パラメータはデフォルトの、
  • Sharpen Stars: 0.5, Adjust Star Halos: 0.0, Automatic PSF: on, Sharpen Nonsteller: 0.50
としています。左が元の画像、右がソフトウェアビンニングしたものです。
BXT_s

恒星については、どちらも小さくなっていて、結構近い大きさになっています。微恒星に関しても、ビニングした方もほとんど取りこぼしなどもなさそうです。これはすごいですね。

その一方、背景の細部出しについては、元画像もビニング画像も、BXTの効果は共にほとんど見られず、差は縮まったりしなくて、依然としてビニングした方は細部が出ていないように見えます。BXT2はBXT1に比べて背景が出にくくなっているので、そのせいかとも思い、この後両方ともにBXT2を背景のみに複数回かけましたが、はっきり言ってほとんど変化が見られませんでした。さらに、AI4からAI2に戻してBXT1相当にしてかけてみても、効果がほぼ何もみられませんでした。

どうも天体部分がまだ淡すぎる、もしくは天体と背景のS/Nが低すぎるのかと思っています。ブログで示した画像は目で見えるようにストレッチしたものを掲載していますが、ストレッチ処理前の画像は真っ暗です。S/Nを見ても最も明るいところでわずかわずか5とか10で、背景との輝度差にするとわずが7 [ADU]程度で暗すぎるのです。少しストレッチしてコントラストを上げて、背景との輝度差を付けてからBXTをかけるとかの対策が必要かもしれません。

とりあえずOIIIに加えて、Hα、恒星のためのRGBの撮影も完了しているので、次は画像処理です。BXTの効果についても、仕上げまで持っていく際にもう少し検証できればと思います。


まとめ

今回の検証で2倍のソフトウェアビニングで実際にS/Nが2倍得することはわかりました。これは撮影時間にしたら4倍長くしたことに相当し、今回10時間撮影しているので、実行的に40時間撮影していることと同等です。もしCMOSカメラのbin2をそのままのbin1で撮影した時と比べるとさらに4倍で、160時間撮影したことと同等になります。分解能は当然犠牲になります。

さらにDrizzle2倍 x BXTで、恒星に関しては分解能をかなりのレベルで回復できることは分かりましたが、背景に関してはほとんど効果がないことが判明しました。ある程度広域で見た天体であること、かなり淡いので詳細はあまり見えないことなどもあり、分解能はそこまで必要ないと考えることもできますが
少し悔しいところです。淡すぎて背景との輝度差がほとんどないことが原因かと思われます。


日記

正月に能登半島で最大震度7という大きな地震がありました。その時私は実家の名古屋にいたのですが、名古屋でも大きく揺れました。すぐに富山に残っていた家族に電話をしたのですが、これまでに体験したことがないような揺れだったそうで、立っていることもできなかったそうです。

元々、元日夜に車で富山に戻ろうとしていたのですが、安全を考えて2日の明るいうちの移動としました。自宅に着いて部屋とかを見てみましたが、自宅は富山市内でも山川に近い比較的南の方で、幸いなことに何かが倒れるとかいう被害もほとんどありませんでした。天体機材もほぼ無事で、棚の上の方に置いてあった空箱が一つ落ちたくらいでした。

自宅周りは地盤的にも比較的頑丈なのか、近所の人に聞いてもほとんど大きな被害を聞くことはなかったです。その一方、少し離れた川に近いところや、富山の少し中心街に近いところは、自宅から大した距離でなくても、そこそこ被害があったと聞いています。さらに富山駅より北側、富山県の西部、金沢などはかなりひどいところもあったのことで大変だったようです。震源地に近い能登半島は、日が経つにつれ被害の状況が伝わってきて、想像をはるかに超える被害でとても心が痛みます。石川の星仲間もいるので、無事を祈るばかりです。

今週末は気温が下がり、場所によっては雪も降るとのことです。被害のひどいところでは平時の生活に戻るまではまだかかるかと思いますが、一刻も早い復旧を願って止みません。

画像からのノイズ解析の一環でいろいろ考えているのですが、ビニングについて考えていたら1回分くらいの記事の分量になってしまいました。番外編として独立記事とします。

一般的にCMOSカメラでの撮影でbin1以外を選択すると、通常はソフトウェアビニングとなり、本来のハードウェアビニングに比べて不利であると言われています。でもこのことについて真面目に議論している記述をあまりみたことがないので、少し考えてみます。

ちなみに、ハードウェアビニングは以前主流だったCCDカメラには搭載されていた機能ですが、最近主流のCMOSカメラではハードウェアビニング は原理的に搭載するのが難しく、ソフトウェアビニングとなります。それでも例えばASI294MM Proなどは、4つのピクセルを合わせて1ピクセルとしたものが標準で、オプションで1ピクセルごとの画素のデータも読み取ることができ、実施的にハードウェアビニングと同じような機能を搭載しているものもあります。




ビニングでのS/N向上

そもそも、ビニングとはどんなものなのでしょうか?撮影ソフトの機能だけでみたら、bin2は縦横2つで計4つのピクセルを1つのピクセルとして扱い、4倍の明るさを得る手法です。明るさが4倍なのでショットノイズは√4=2倍になり、そのため、ショットノイズに対してのS/Nは4/2=2倍よくなります。

これだけのS/N増加をbin1で得ようとしたら4倍の時間をかける必要があります。例えば、bin2で1時間撮影することとbin1で4時間撮影することが同じ、bin2で4時間撮影することとbin1で16時間撮影することが同じ、bin2で10時間撮影することとbin1で40時間撮影することが同じです。10時間撮影は頑張れば可能ですが、40時間撮影はそれこそ長期にわたって安定した天気と、相当な根気が必要になってきます。撮影日数は1週間オーダーになるでしょう。私が住んでいる富山ではこんなに連続で晴れることはほぼあり得ないので、今の私の環境ではトータルで10時間くらいが限界です。例え10時間でも、実際には設置やトラブル回避などにも時間をとられるので、数日にわたります。

bin3なら3x3=9個のピクセルを一つとして扱うので、9倍の明るさ、√9=3倍のショットノイズで、S/Nの向上は9/3=3倍となり、同じS/Nをbin1で得ようとしたら、9倍の時間をかける必要があります。

このように、S/Nの向上という観点からはビニングは効果があることはあきらかです。その代わりに空間分解能(解像度)を犠牲にしています。


ハードウェアビニング

ハードウェアビニングの特徴は、カメラのセンサー部の段階でピクセルを足し合わせてから、情報として読み出すことです。例えばbin2の場合、輝度は4倍になり、読み出しノイズは1倍のままなので、読み出しノイズに関してはS/Nで4倍も得することになります。その代わりに、分解能が一辺あたり半分、面積では4分の1になります。

また、ハードウェアビニングではダイナミックレンジが、例えばbin2では2ビット分減る可能性があぷらなーとさんによって指摘されています。というか、ASI1600ってCMOSカメラなのにハードウェアビニングできるんですね。本家ZWOのページを見ると、確かにできると書いてます。

 

このように、ハードウェアビニングも少なからず不利な点があることに注意する必要があります。

まとめると、ハードウェアビニングでは、例えばbin2はbin1に比べて
  1. 空間分解能が一辺半分になって(不利)
  2. 4倍明るくなり(有利)
  3. ショットノイズに対してS/Nが2倍良くなり(有利)
  4. 読み出しノイズに対してS/Nが4倍良くなり(有利)
  5. ダイナミックレンジが2ビット減る(不利)
ということになります。


ソフトウェアビニング

次に、ソフトウェアビニングについて考えてみます。一般に、ソフトウェアビニングはハードウェアビニングより不利と言われていますが、どうなのでしょうか?

まず、ビニングで輝度が上がることによるショットノイズについてはハードウェアビニングもソフトウェアビニングも効果に違いはありません。

ではソフトウェアビニングの何が不利なのかというと、読み出しノイズの部分です。ハードウェアビニングではセンサー部でピクセルを足し合わせているので、足し合わせた輝度について1回読み出すだけでいいのですが、ソフトウェアビニングでは輝度の値を読み出した後に「ソフト的に」輝度を足し合わせるので、読み出し回数は足し合わせるピクセルの数の分だけ必要となります。読み出しノイズはその回数分増えるので、bin1に比べて不利になります。

ソフトウェビニングをすることで、ハードウェアビニングに対してどれくらい読み出しノイズが増えるか、計算してみましょう。例えばbin2の場合、bin1の一つのピクセルの読み出しノイズをN_rとすると、ノイズは2乗和のルートで効いてくるので、4ピクセル分で4回読み出すとすると

sqrt(N_r^2+N_r^2+N_r^2+N_r^2) = sqrt(4xN_r^2) = 2N_r

となり、2倍の読み出しノイズとなります。このことがハードウェアビニングに対して、ソフトウェアビニングは不利になるという根拠になります。でもこれはあくまでハードウェアビニングに対して2倍不利になるというだけで、bin2のソフトウェアビニングでも輝度は4倍となるので、S/Nをとると4/2 = 2倍有利になるので、読み出しノイズに関して得します。ハードウェアビニングに対して得する度合いが小さいというだけです。

まとめると、ソフトウェアビニングでは、例えばbin2はbin1に比べて
  1. 空間分解能が一辺半分になっていて(不利)
  2. 4倍明るくなり(有利)
  3. ショットノイズに対してS/Nが2倍良くなり(有利)
  4. 読み出しノイズに対してS/Nが2倍良くなり(有利)
  5. ダイナミックレンジも変化無し(同じ)
ということになります。

あ、ダイナミクレンジに関しては、16ビットセンサーだと勿体無いかもしれません。元々16ビットの情報を持っているとすると、ソフトウェアビニングで計算機内部では18ビット相当まで行きますが、ファイルフォーマットが16ビットだとすると、ファイルに保存するときに2ビット分はいずれ捨てられることになります。あくまで勿体無いというだけで、少なくとも16ビットのままで悪くはならないのですが、ファイルフォーマットのダイナミックレンジを撮影ソフトから書き出す時に大きくできれば、さらに2ビット稼げる可能性があります。

ダイナミックレンジに関しては、私自身はきちんと検証しているわけではないので、あくまで理論的な話です。例えば14ビットセンサーのbin2のソフトウェアビニングが、14ビットで保存されるのか、(ファイルのフォーマット的には余裕があるので)16ビットで保存されるのかちょっと興味があります。


本当にソフトウェアビニングは不利なの?

ここまでの記事なら、よくあるハードウェアビニングとソフトウェアビニングの説明になります。よくある記事と言っても、実際には定性的に説明してあるページがほとんどで、実際に数値できちんと書いてあるところは探すのが大変なくらい少ないです。

で、ここからが「ほしぞloveログ」ならではの本番の記事となります。多分どこも議論しているところはないと思います。それは、ソフトウェアビニングはハードウェアビニングに比べて本当に不利かという疑問です。

ここまでの上記の検証で、ソフトウェアビニングがハードウェアビニングに比べて不利な点は、読み出しノイズについてのみです。しかもダイナミックレンジに関しては、むしろソフトウェアビニングの方が有利な可能性が高いです。

読み出しノイズについてもう少し考えてみます。これまでの実画像からのノイズの検証で、撮影画像のノイズ成分についてずっと議論してきました。その結果、開田高原や海外チリなどのかなり暗い環境においてさえも、実際のトータルのノイズはスカイノイズに制限されていることが多く、読み出しノイズがほとんど効いていないことがわかります。特に自宅のような光害地ではその傾向が顕著で、圧倒的にスカイノイズが支配的で、読み出しノイズやダークノイズはほぼ完全に無視できることがわかります。

このように、本格天体撮影のほとんどの場合において、読み出しノイズが支配的な状況になるとはあまり考えられず、その場合は唯一の違いであるハードウェアビニングとソフトウェアビニングでの読み出しノイズでの有利不利はなくなると考えられます。ダイナミックレンジの観点からは、むしろソフトウェアビニングの方が有利になる可能性さえあります。

ただし、
  • 環境のいい暗い空において
  • 暗い鏡筒使っている
  • 一枚あたりの露光時間が短い
  • ナローバンド撮影で明るさを制限して撮影している
などの場合には、読み出しノイズが支配的な状況になることもあるはずです。その場合、ハードウェアビニングのほうがソフトウェアビニングに対して有利になることは当然あり得ますが、これまでの検討からかなり稀な状況であると思われます。

そもそもハードウェアビニングとソフトウェアビニングの違いを気にするような方は、かなり撮影にも凝った方なのかと思います。明るいF値の鏡筒を使うことも多く、長時間露光で、読み出しノイズよりもダークノイズやスカイノイズに支配的な状況になりがちかと思います。もし今回の私の検討が正しいとするならば、ハードウェアビニングとソフトウェアビニングの違いについては気にする必要はなく、(分解能を気にする状況でなければですが)遠慮なく現在のCMOSカメラのソフトウェアビニング使っていいのかと思います。

どうしても心配な方は、自分で撮影した画像で一度ノイズを実測してみるといいかと思います。最近のこのブログの記事を見返すと、ノイズの原理と測定方法など書いておいてあるので、どなたも簡単に測定と評価までできるのかと思います。




特に淡いSh4-240のOIII成分

というわけで、つい最近淡いSh2-240を、上記のような考えの元でソフトウェアビニングのbin2で、明るい自宅の庭で撮影してみました。

光害地であるため、ナローバンド撮影といえどもスカイノイズが完全に支配的です。これまでの議論から、このような状況での撮影ではハードウェアビニングとソフトウェアビニングの読み出しノイズの差なんて完全に無視できます。それよりも淡い天体に対して輝度を高くでき、S/Nを稼ぐことができるほうがはるかに有利になります。例えば、ショットノイズ(=スカイノイズ)に関しては露光時間4倍で撮影することと同等なので圧倒的に有利で、現実的な撮影時間で淡い部分を出すことにかなり貢献してくれます。

masterLight_BIN_2_300_00s_FILTER_O_integration_ABE

結果を見る限り、光害地からの撮影でも、特に淡いOIII成分も情報と十分に残っていることがわかります。今回は6時間半の撮影ですが、これをもしbin1で撮影していたら、(空間分解能は無視するとして)同等のS/Nを得るためには28時間の撮影時間となっていたはずです。


まとめ

今回の記事ではビニングについてまとめてみました。特にハードウェアビニングとソフトウェアビニングの違いついて、少し定量的に議論してみました。ちょうどこの満月期で、しかも天気も悪いので昼間に太陽を見ることもなく、時間をかけてじっくり考えることができました。

読み出しノイズに支配されないような状況下では、ハードウェアビニングとソフトウェアビニングについて大きな差はないので、必要ならば分解能を犠牲にして輝度を上げS/Nを上げることができる、現在のCMOSカメラで使えるソフトウェアビニングを遠慮なく使っていいという結論になります。ただし、自分で考えたことなので大きく勘違いして間違っている可能性もあります。何か気づいた際にはコメントでも残していただけるとありがたいです。


参考記事

この記事をほぼ書き終えて、改めて検証のために、ある程度の理屈と感度向上を数値まで含めてで日本語で記述しているあるページを探してみましたが、ほとんど見つけることができませんでした。これまでビニングに関しては神話的に色々囁かれていたような状況だったことが想像できます。
  • 画像のビニングについて、定性的な説明だけをしているページはたくさんあります。感度が4倍になるとだけ書いているページもある程度見つかります。でもきちんと理由とともに説明していあるページは、調べた限りWikipediaだけでした。

 

  • 実画像で検証してあるページがありました。ひろしさんという方が書いている「ヒロシの天体観測」というブログの中に書いてあり、2011年とかなり古い、CCD時代の記事です。いろんなケースを比較していて、とても好感が持てます。ハードウェアビニングとソフトウェアビニングで結果があまり変わらないとか、レンジもハードビニングのほうが狭いなど、理由がはっきりとせずかなり疑問もあったようです。画像の比較結果は、今回の私の記事での説明と矛盾するようなことはないように思いますし、疑問に対しても今回の記事の内容でかなり程度説明できるように思えます。コメント欄を見ても、当時活発に議論していることがわかります。


  • シベットさんのブログ「浮気なぼくら」でも検証記事があります。bin1からbin4まで4つ比較していて、それぞれで違いはないと結論づけられていますが、ヒストグラムを見てもbinの数が増えるごとに明らかに山の幅が短くなっていること(=ノイズが小さくなっているということ)、画像を見ても背景のノイズが明らかに減っているので、S/Nという観点からは十分な効果が出ていると思われます。



きまぐれ日記

これまで書いてきたノイズ検証の関連で、だいこもんさんとNiwaさんから画像を提供して比較検討してきました。その過程でお二方からDMで質問や議論があり、直接話しますかということになりました。

ちょうど昨晩、星沼会の定例のミーティングといういうことで、そこで話せばいいのではと、私もゲスト参加させていただきました。メンバーはだいこもんさん、Niwaさん、hinokirさん、ぐらすのすちさんでした。

ミーティング自体は21時から始まっていたのですが、私は途中21時から参加して、結局0時近くまで話し込んでいました。ノイズの話で盛り上がること自体がそもそも濃いのですが、さすが星沼会、他に話している内容もとても濃かったです。私自身もかなり楽しい時間を過ごすことができました。ゲスト参加を認めていただき、どうもありがとうございました。

ブログ記事と関係ないのですが、天文関連でちょっとしたことがあったら、こんなふうに記事にに混ぜて日記がてら書いて行けたらと思っています。

この記事は「実画像のノイズ評価(その3): 信号について」の続きになります。



久しぶりのブログ更新になってしまいました。実は小海の星フェスからコロナになってしまいました。4−5日で平熱に戻ったのですが、その後体力が全然戻らず、仕事から帰っても疲れ果ててすぐに寝てしまうことをずっと続けていました。新月期で晴れた平日もあったのですが、全く機材を出す気力がありませんでした。細々と今回の計算だけは続けていて、発症から3週間たってやっとブログを新たに書くくらいの気力がもどってきました。

というわけで前回の記事から結構経ってしまいましたが、今回の記事ではこれまでのノイズ評価がどこまで通用するか、具体例を検証してみたいと思います。だいこもんさんと、Niwaさんの協力もありましたので、いくつかの撮影条件を比べてノイズ評価が正しいかどうか検証してみることにします。


開田高原で撮影したファイルの検証

まずはこれまで通り、開田高原のものから。使っているカメラはASI294MM Proです。


1. Read noise


最初はRead noiseを検証してみましょう。比較すべきは、
  1. ASI294MM ProのRead noiseのグラフから読み取ったノイズ
  2. 自分で撮影したBiasファイルから実測したノイズ
の2つです。

  1. 今回の撮影ではゲインを120としたので、その時のRead noiseの値をグラフから読み取ると、1.8 [e]程度でしょうか。
  2. その一方、Baisファイルはゲインを120として、最初露光時間(0.032ms)で撮影し、RAW16のfits形式で保存します。実測はPixInsightのStatisticsツールをつかいました。撮影されたファイルは実際には14bit階調なので、Statisticsツールで「14bit [0,16383]」を選びます。その時のavgDevの値を読むと2 [ADU]となります。この場合単位はADUなので、比較できるようにeに変換するため、コンバージョンファクターを使います。コンバージョンファクターはグラフの縦軸「Gain(e/ADU)」から読み取ります。横軸の「Gain(0.1dB)」の120のところでは0.95 [e/ADU] 程度となります。これを使うと、Baisファイルのノイズは1.9 [e]となり、グラフから読み取った値にほぼ一致します。
結論としては、Read noiseに関しては、メーカーの示すグラフから読み取った値と、実測の値が10%以下の精度でかなり一致していると言えます。実はこのことは、2019年に既に確認していて、その時もよく一致していることがわかっています。


2. Dark noise

次にDark noiseを検証します。こちらも比較すべきは、
  1. ASI294MM Proの Dark currentのグラフから読み取った暗電流値から計算したdark noise
  2. 自分で撮影したDarkファイルから実測したノイズ
の2つです。

  1. 今回の撮影時の温度は-10℃、1枚あたりの露光時間は300秒です。グラフから安電流は0.006 [e/s/pix]程度、露光時間の300 [s]をかけて1.86 [e/pix]。単位がeなので、ノイズはそのルートをとればよく、ピクセルあたりでは1.3 [e]となります。
  2. 一方、自分で撮影したダークファイルから、Biasファイルの時と同様にノイズをPixInsightで実測すると2.5 [ADU]となりました。これをコンバージョンファクター0.95[e/ADU]で単位をeに変換してやり、2.38 [e]となります。ここからRead noise 1.8 [e]を引いたものが実測のDark noiseとなります。ただし引く際には、互いに相関のないランダムなノイズなので、実測値の2乗とRead noiseの2乗の差を取り、ルートを取ることになります。出てきた値は1.4 [e]となりました。
結果としては、Dark noiseに関してもメーカーのグラフから求めた値と、実測の値が10%以下の精度で一致していることがわかります。


3. トータルノイズ

さらに、開田高原で撮影したライトフレームの輝度から推測したノイズと、ライトフレームのノイズの実測値を視覚します。
  1. 天体や分子雲が支配的でない暗い部分の輝度をPixInsightのStatisticsで実測すると、920 [ADU]程度となりました。ここから撮影時のオフセット40x16=640を引き、実際の輝度が280[ADU]であることがわかります。これをコンバージョンファクターで[e]にすると266 [e]。単位が[e]なので、ノイズは輝度のルートをとると直接出てきて、16.3 [e]となります。
  2. その一方、ライトフレームからPixInsightのStatisticsでノイズを直接測定すると、16.9 [e]となりました。
撮影したライトフレームの輝度から計算したノイズと、実測のノイズが10%以下の精度でかなり一致していることがわかります。


4. Sky noise

輝度から推測したノイズと直接測ったノイズから、トータルノイズがかなり一致することがわかったということと、Read noiseもDark noiseも推測値と実測値がかなり一致していることがわかるので、残り(今は天体が写っていない部分を考えているので、天体からのショットノイズはないと考える)のSky noiseもそこそこ一致すると推測できます。Sky  noiseは、トータルノイズからRead noiseとDark noiseを引いたものと考えることができます。ただしこの場合も、それぞれのノイズを2乗して、トータルからRead noiseとDark noiseを引く必要があることに注意です。その結果、Sky noiseは16.2[e]程度となりました。トータルノイズが16.3 [e]なので、Read noiseとDark noiseはほとんど効いていなくて、ほぼSky  noiseに支配されていることがわかります。


開田高原撮影のまとめ


まとめると、

グラフから読み取ったRead noise1.8 [e]
実測のRead noise1.9 [e]

グラフから読み取ったDark noise
1.3 [e]
実測のDark noise [e]1.4 [e]

背景光の輝度から推測したトータルノイズ

16.3 

[e]
実測のトータルノイズ [e]16.9 [e]

Sky noise
16.2 [e]

となります。

開田高原の暗い空であっても、L画像であること、口径260mmでF5のかなり光を集める鏡筒であることなどから、Sky noiseが支配的になってしまうのかと思われます。これが小さい口径で暗い鏡筒を使った場合や、明るい鏡筒でもナローバンドフィルターを使い入射する光を小さくした場合には、Read noiseとDark noiseが効いてくる可能性が高くなることに注意です。


条件を変えた場合

少なくとも、これまで検証してきた開田高原で撮影したライトフレームでは、メーカーグラフからの読み取り値と実測などがかなり一致することがわかりました。他の例とも比べてみましょう。

ここでは4つを比較します。鏡筒、カメラ、露光時間、ゲイン、温度、背景光の明るさなどがそれぞれ違います。
  1. 開田高原: SCA260 (d260mm、f1300mm)、ASI294MM Pro、露光時間300秒、gain120、-10℃
  2. 自宅: SCA260 (d260mm、f1300mm)、ASI294MM Pro、露光時間300秒、gain120、-10℃
  3. チリ1: RS200SS (d200mm、f760mm)、ASI294MM Pro、露光時間120秒、gain120、-20℃
  4. チリ2: FSQ106N (d200mm、f760mm)、ASI1600MM Pro、露光時間300秒、gain0、-20℃
協力: だいこもんさん(チリ1)、Niwaさん(チリ2)

個々の計算過程は省略しますが、結果は

1. 開田高原2. 自宅3. チリ14. チリ2
グラフからのRead noise [e]1.8 1.8 1.8 3.6 
実測のRead noise [e]1.9 1.9 1.9 3.6 

グラフからのDark noise [e]
1.3 1.3 0.9 1.4 
実測のDark noise [e]1.4 1.4 0.9 1.3 

背景光輝度からのトータルノイズ [e]
16.3 49.3 12.0 7.0 
実測のトータルノイズ [e]16.9 51.3 12.5 8.3 

Sky noise [e]
16.2 49.3 11.8 5.8 

となりました。各種条件はかなり違っていますが、どれも推測値と実測値がかなりの精度で一致しています。これまでの検証が大きく間違ってはいないことがわかるのかと思います。言い換えると、グラフからの推測値だけである程度正しいことがわかるので、今後の計算では実測値を用いなくともグラフから計算した値を用いて話を進めても、ほぼ問題ないと言えるのかと思います。

「背景光輝度からのトータルノイズ」と「Sky noise」を比較すると、やはりSky noiseが支配的なのがよくわかり、それでもチリ2のように暗いところで小口径の場合は、Sky  noiseの貢献度が小さくなり、Read noiseやdark noiseの貢献度があるていど大きくなることがわかります。

逆に言うと、Read noiseやdark noiseが効かない範囲でうまく撮影されているとも言えます。Read noiseやdark noiseが支配的と言うことはある意味暗すぎるわけです。暗い鏡筒を使っていたり、1枚あたりの露光時間が足りなかったり、ゲインが小さすぎるなどの状況や、ナローバンドフィルターやかなりきつい光害防止フィルターを使った場合などは暗すぎる状況になることがあります。

Read noiseやdark noiseが効かない状態の撮影ができているなら、あとはどこまで淡いところが出るかは背景がどこまで暗くできるかに依ります。より暗い空が有利となってきます。この状態ではもう1枚あたりの露光時間を伸ばしても意味はなくなり、トータルの露光時間を伸ばすことでSky noiseの影響を小さくしていくしか手はありません。

今回の記事でははまだ1枚撮影のみをこと議論しているのですが、本当は多数枚撮影してスタックした時のことを考えて判断するべきですね。次回以降に議論できればと思います。


撮影時の背景光の輝度推測

実は、鏡筒とカメラのパラメータがわかっている(口径、焦点距離、量子効率、ピクセルサイズ、コンバージョンファクターなど)ので、画像から撮影時の背景光の輝度が推測できるはずです。それぞれの場所でのSQMがわかっていれば、推測値と比較して画像として得られた背景光がある程度正しいのかどうか検証できるはずです。

結果としては、開田高原とだいこもんさんが撮影したチリの画像は、1.4倍くらい開田高原の方が明るかったです。開田高原はPolution Mapで見た場合、SQM21.8程度、チリはだいこもんさんによるとSQM22.1程度のことなので、10^((22.1-21.8)/2.5)=1.32倍なので、比較ではそこそこ正しいです。ただ、開田高原の当日の現地でiPhoneのアプリで簡易測定したSQMだと20.9が最高だったので、開田高原の実際はもっと(2.5倍くらい)明るかった可能性もあります。

でもNiwaさんが撮影したチリの画像からの推測値の輝度はだいこもんさんが撮影したものより1.8倍くらい明るく出てしまい、どうしても合いません。新月期ではないのではと思いましたが、撮影日から調べてみると新月期です。方向など何か別の明るい理由があったのか、まだ計算がどこかおかしいのかよくかっていません。Niwaさんのだけカメラが違うので、何か取り込めていないパラメータがある可能性もあります。

また、富山の自宅での撮影では開田高原より10倍以上明るく、Polution Mapで見たSQM20.6とかけ離れています。一つの可能性は、北の空なので街明かりが効いていたというのはあり得るかもしれません。と考えると、チリも方向によって明るさが結構違うのか?昔方個別の光害マップ「ふくろう」というのがあったのですが、残念ながらもう稼働していないようです。

いずれにせよ、画像ファイルからの背景光の輝度の測定はまだあまり正確ではないようなので、具体的な値は割愛します。だいこもんさんにも言われましたが、輝度は既知の恒星の明るさから求めるべきなのかもしれません。でも今回の範囲は越えるので、輝度の推測は諦めることにします。 


まとめ

これまでのノイズの検証が正しいかどうか、簡単にですが検証してみました。条件を変えてもそこそこ正確に見積もれているのかと思います。

といっても、メーカーが示しているグラフからの計算値との比較なので、ある意味そのグラフが実際の測定と正しいかどうかの検証とも言えます。少なくともメーカーが示しているグラフは、今回の測定で自己矛盾のような現象は見られず、実際にユーザーが手にしているカメラでの実測とかなり近い値となっていると思われます。

これ以降の記事では「グラフから推測したノイズはそこそこ正しい」と考えて進めていけばいいと言うことが言えるのかと思います。








 

この記事は、実画像のノイズ評価(その1): 各ノイズの貢献度合


の続きになります。


前回の復習

かなり前の記事になってしまうので、私自身忘れてしまったことも多くて記事を読み返しながら今回の記事を書いています。前回の記事で何がポイントだったのか、復習がてら少しまとめ直してみます。

前回の記事では読み出しノイズ、ダークノイズ、スカイノイズの3つについて、実際に撮影した画像を元に数値的に具体的な値を見積もりました。特にこれまでスカイモイズをどう見積もるかが難しかったこともあり、あまりきちんと評価されてこなかったようです。前回の記事では画像の明るさからコンバージョンファクターを使いスカイノイズを見積もるという手法を提案し、実際のスカイノイズを数値で出すという試みをしています。

その結果、撮影地で有名な暗いと言われる開田高原の空でさえ、スカイノイズが支配的で、15.9[e] 程度ありました。読み出しノイズ、ダークノイズがそれぞれ1.8[e] と1.5[e] で10分の1程度です。実際の効きは2乗して比較すべきなので、それぞれスカイノイズに対して(15.9/1.8)^2 = 1/78、(15.9/1.5)^2 = 1/112と78分の1とか、112分の1とかしか影響していないことがわかります。

これが富山の街中の自宅になると、スカイノイズがさらにひどいことになり48.0[e] となり、3倍近くの大きさです。開田高原と同じクオリティーにしようとしたら、(48/15.9)^2 = 9.1で9.1倍ほどの露光時間を必要とします。開田高原で5時間45分かけているので、自宅だと52時間20分かけて撮影すると同じになるというわけです。自宅だと平日も撮影して放って置けるのですが、北陸で冬に1週間も連続で晴れることはほぼありえないので、実質不可能です。こうやって具体的な数値を入れてみると、大きな違いになることがわかります。

このように、スカイノイズが支配的な場合は読み出しノイズやダークノイズはほとんど効いていないので、露光時間をもっと増やしてもいいのではないかと疑問を投げかけた形で前回の記事を終えています。今回はその疑問に応えるような形で、撮影条件やパラメータを変えながら、検討してみます


どこまで露光時間を縮めることができるか?

簡単のため、L画像のみを考えます。カラー画像も原理は同じですが、ディベイヤーなど計算が複雑になるので、とりあえずここではモノクロとします。

読み出しノイズ:
まずは露光時間を短くして、スカイノイズを小さくして、読み出しノイズと同程度になるような状況を考えてみましょう。露光時間をどこまで短くできるかを求めてみます。

今回使った開田高原で撮影したM81の画像では、露光時間300秒の時に、スカイノイズと読み出しノイズの比が

15.9[e] : 1.8[e] = 8.8 : 1

で約9倍の差があります、スカイノイズを約9分の1にすればいいので、明るさで考えると2乗で81分の1にしてやればいいことになります。露光時間で考えると300秒を81分の1にしてやればいいので、300[s] / 81= 4.8 [s]と、露光時間をわずか3.7秒にまで短くするとやっとスカイノイズが読み出しノイズと同等になります。こんなに短くていいんですね!?

ダークノイズ:
次に、スカイノイズがダークノイズと同程度になる温度を求めてみます。まずは300秒露光だとすると、スカイノイズとダークノイズの比は前回記事の計算から

15.9[e] : 1.5[e] = 10.6: 1

と10.6倍程度の余裕があるので、−10℃で撮影した時のダークノイズが10.6倍程度になるには、暗電流で考えると2乗になるので、−10℃での暗電流が10.6^2 = 112倍程度になるところの温度を暗電流のグラフ(縦軸が2倍ごとの対数グラフであることに注意)から読み取ってやればいいはずです。−10℃での暗電流が0.007程度なので、112倍だと0.79とかなってしまい、もう30℃超えとかの温度になってしまいます。今回くらいスカイノイズが支配的ならばもう冷却に関しては全然気にしなくていいと言うことになってしまいます。


本当にそんなに余裕はあるのか?

開田高原の暗い空でさえ、露光時間は3.7秒以上ならOK、温度は30℃以下ならOKと、にわかには信じ難い数字が出てきました。さらに(今回撮影した日の)開田高原より明るい空ではこの条件は緩和され、さらに短い露光時間でも、高い温度でもよくなります。これまでおまじないのように露光時間を伸ばし冷却をしてきたのですが、実際にはほとんど効いていなくて、1枚あたりの露光時間を減らしていいし、センサー温度ももっと高くてもいいということになります。

でも、ここまでの検証、本当に正しいでしょうか?

答えは原理的にはYesですが、実用上はNoでしょう。まず、暗い空に行けば行くほどこのパラメータの余裕は少なくなっていきます。また光害防止フィルターを使うと、実質的に暗くなるのでスカイノイズは小さくなり、上記露光時間と温度の余裕は少なくなっていきます。これらの場合1枚あたりの露光時間を増やした方が有利になるし、センサー温度も低い方が余裕が出ます。

例えばHαのようなナローバンド撮影の場合を考えます。典型的な7nmのナローバンドフィルターを使うとしましょう。7nmというのはフィルターを透過する光の波長の(多分ですが)FWHM(Full Width Half Maximum、半値全幅、縦軸のピークの半分の値をとる時の横軸の全部の幅、他にも半値半幅などがある)が7nmということなので、仮にASI294MMが可視である波長のFWHMを380nmから800nmの420nmとしましょう。420nmが7nmとなるので、単純に考えると明るさは60分の1になります。スカイノイズにするとルートで効くので8分の1程度でしょうか。

今回の計算ではスカイノイズと読み出しノイズの比が8.8分の1、スカイノイズとダークノイズの比が10.6分の1と見積もっていたので、大きく余裕あると思っていました。でもナローバンド撮影の場合スカイノイズが8分の1になるいうことは、この余裕を全て取り去ってしまいます。ナローバンド撮影だと300秒露光と−10℃での撮影で、スカイノイズと、読み出しノイズと、ダークノイズが大体一緒くらいになるということになります。


現実的な露光時間と温度

ナローバンドでは300秒という露光時間も、−10℃というセンサーの温度も妥当だということは分かったのですが、明るいL画像ではやはりこれまでの検証に特におかしなところはなく、露光時間も温度も全然余裕があるということは(私が大きな勘違いをしていなければですが)事実です。

でも、途中の複雑な機器設定の変更で撮影が失敗するリスクなどを考え、同じようなセッティングで全ての光学フィルターに対して対応しようとするのは戦略として全然おかしくはなく、その場合、一番厳しいところにセッティングを合わせることは十分妥当でしょう。
 
このように全部一緒のセッティングにするということも一理ありますが、明るい場合にはパラメータに余裕があることを理解した上で、フィルターによっては露光時間を変える、ゲインを変えるという戦略を立てることは次の可能性につながるのかと思います。例えばHαをRGBに混ぜる赤ポチ画像を作るのに、StarNetなんかで背景と恒星を分離するときなんかは特にそうです。この場合、恒星は大きさも色情報も使えなかったりもするので、背景のみにダイナミックレンジを振ることができ、余裕ができるはずです。

ただし、露光時間やゲインを変えてパラメータ数を闇雲に増やすと、その後の画像処理に対して必要なダークファイル、フラットファイル、フラットダークファイル、バイアスファイルなどの種類も増えていく羽目になります。少しまとめておきます。

露光時間とゲインという観点では:
  • 露光時間もゲインも変えたくないもの: ダークファイル
  • ゲインを変えたくないもの: フラットファイル、フラットダークファイル、バイアスファイル
光学フィルターごとという観点では:
  • それぞれのフィルターに対して撮影するもの: フラットファイル
  • 共通で撮影できるもの: ダークファイル、フラットダークファイル、バイアスファイル
くらいになりますでしょうか。

特にダークファイルは撮影に時間がかかるので、できるだけ種類を少なくしておきたいです。明るい時と暗い時の2パターンくらいに決めておけるなら、ダークだけ設定ごとに一度撮ってしまって使いまわすことで、後の手間はそれほど変わらないと思います。あらかじめダークライブラリーを作っておくと気にしないでよくなるかもしれません。バイアスもゲインごとのライブラリを作ることができますね。

フラットはホコリなどの状況でかわってしまうので、その都度撮影した方がいいかもしれませんが、センサー面やフィルター面を暴露しないようにしてホコリなどの混入があまりない状況を作れるのなら、使い回しが効くと思います。

多分大丈夫だとは思うのですが、フラットとフラットダークはできれば同時に取ったほうがいい気がしています(温度が変わると縞ノイズに影響があるかも、でも未検証)。


まとめと今後

今回は露光時間とセンサー温度について、本当に理屈通りでいいのか、実際の撮影などのことも含めて少し検証してみました。実用上はフィルターなどの変更もあるので、これまで通りの露光時間やセンサー温度でも構わないかもしれませんが、これらのパラメータを変更する場合にどれくらい余裕があるかを知っておくことは、今後の方針を立てる上で有利になるのかと思います。

まだまだ検証したいことはたくさんあって、ゴールまではかなり遠いです。これまではノイズのみの議論で、ノイズ同士がどうなるかだけを問題にしていて、信号についてはまだ何も議論していません。ノイズに対して、撮影目標の天体が信号ということになるのですが、信号SとノイズNの比S/N (SN比)が重要になります。また、スタックすることでS/Nを稼ぐことができます。でも真面目に信号部分を考えるのって結構大変なんですよね。またゆっくり考えてみます。


この記事の続き



になります。実際に信号を考えてS/Nを求めています。








2022年の反省でも述べましたが、最近自分で考えることがあまりできてなかったので、今回の記事は久しぶりに計算です。内容は、撮影した画像にはどんなノイズが入っていて、それぞれどれくらいの割合になっているかを見積ってみたという話です。


動機

まずは動機です。1月に開田高原でM81を撮影した時に、M81本体に加えて背景のIFNが見えてきました。下は300秒露光を28枚撮影したL画像を強度にオートストレッチしています。
masterLight_BIN-2_4144x2822_EXPOSURE-300.00s_FILTER-L_mono

一方、2022年の5月にも自宅で同じM81を撮影しています。背景が埃とスカイノイズで淡いところがまってく出なかったので記事にしていないのですが、下は露光時間600秒を22枚撮影したL画像で、強度にオートストレッチして、かつできるだけ見やすいようにABEとDBEをかけてカブリを排除しています。開田高原の時よりもトータル露光時間は1.6倍ほど長く、被りを除去しても、淡い背景については上の画像には全く及びません。
masterLight_600_00s_FILTER_L_mono_integration_ABE_DBE3
明らかにスカイノイズの影響が大きいのですが、これを定量的に評価してみたくなったというものです。

もう一つの動機ですが、このブログでも電視観望について多くの記事を書いています。電視観望はリアルタイム性を求めることもあるので、露光時間を短くしてゲインを高く設定することが多いです。この設定が果たして理に適っているのかどうか、これも定量的に議論してみたいとずっと思っていました。


目的

これからする一連の議論の目的ですが、
  1. 画像に存在するどのノイズが支配的かを知ること。
  2. 信号がノイズと比較して、どの程度の割合で効くのかを示す。
  3. 電視観望で高いゲインが有利なことを示す。
を考えてたいと思っています。今回の記事はまずは1番です。こちらはスカイノイズをどう評価するかが鍵なのかと思っています。

2番は意外に難しそうです。信号である天体は恒星ならまだしも、広がっている天体の明るさの評価ってなかなか大変です。これは後回しにするかもしれません。

3番は長年の電視観望がなぜ短時間で天体を炙り出せるのかという疑問を、定量的に表す事ができたらと考えています。こちらは大体目処がついてきたので、近いうちに記事にするかと思います。


基本的なノイズ

天体画像撮影におけるノイズは5年くらい前にここで議論しています。SN比の式だけ抜き出してくると

S/N=ntSsigAnσ2+AntSsky+AntSdark+ntSsignS/N=ntSsigAnσ2+AntSsky+AntSdark+ntSsign
と書くことができます。ここで、
  • AA [pix] : 開口面積
  • nn : フレーム枚数
  • σσ [e-/pix] : 読み出しノイズ
  • tt [s] : 1フレームの積分(露光)時間
  • SskySsky  [e-/s/pix] : スカイバックグラウンド
  • SdarkSdark  [e-/s/pix] : 暗電流
  • SsigSsig  [e-/s] : 天体からの信号
となり、S/Nとしては何枚撮影したかのルートに比例する事がわかります。今回のノイズ源としては読み出しノイズ、スカイノイズ、ダークノイズを考えます。ショットノイズは天体などの信号があった場合に加わるノイズですが、今回は天体部分は無視し背景光のみを考えるため、天体からのショットノイズは無視することとします。

重要なことは、読み出しノイズは露光時間に関係なく出てくるために分母のルートの中にtがかかっていないことです。そのため、他のノイズは1枚あたりの露光時間を伸ばすとS/Nが上がりますが、読み出しノイズだけは1枚あたり露光時間を増やしてもS/Nが上がらないということを意識しておいた方がいいでしょう。その一方、撮影枚数を稼ぐことは全てのノイズに対してS/N改善につながり、読み出しノイズも含めて撮影枚数のルートでS/Nがよくなります。繰り返しになりますが、一枚あたりの露光時間を伸ばすのでは読み出しノイズだけは改善しないので、他のノイズに比べて効率が悪いということです。

分子にあたる天体信号の評価は意外に大変だったりするので、今回は分母のノイズのみを考えることにします。


パラメータ

上の式を元に、ここで考えるべきパラメータを固定しやすいもの順に書いておきます。
  1. カメラのゲイン(gain)
  2. 温度 (temperature)
  3. 1枚あたりの露光時間 (time)
  4. 空の明るさ
の4つで実際に撮影した画像の各種ノイズを推定できるはずです。少し詳しく書いておくと、
  • 1は撮影時のカメラの設定で決める値です。読み出しノイズ (read noise)を決定するパラメータです。
  • 2は撮影時のセンサーの温度で、冷却している場合はその冷却温度になります。単位は[℃]となります。この温度と次の露光時間からダークノイズを決定します。
  • 3は撮影時の画像1枚あたりの露光時間で、単位は秒 [s]。2の温度と共にダークノイズ (dark noise)を決定します。ダークノイズの単位は電荷/秒 [e/s]。これは[e/s/pixel]と書かれることもありますが、ここでは1ピクセルあたりのダークノイズを考えることにします。なお、ホットピクセルはダークノイズとは別と考え、今回は考慮しないこととします。ホットピクセルは一般的にはダーク補正で除去できる。
  • 4は撮影場所に大きく依存します。今回は実際に撮影した画像から明るさを測定することにします。単位は [ADU]で、ここからスカイノイズを推測します。ちなみに、3の露光時間も空の明るさに関係していて、長く撮影すれば明るく写り、スカイノイズも増えることになります。

実際のパラーメータですが、今回の記事ではまずはいつも使っている典型的な例で試しに見積もってみます。私はカメラは主にASI294MM Proを使っていて、最近の撮影ではほとんど以下の値を使っています。
  1. 120
  2. -10℃
  3. 300秒
これらの値と実際の画像から背景光を見積もり、各種ノイズを求めることにします。


読み出しノイズ

読み出しノイズはカメラのゲインから決まります。ZWOのASI294MM Proのページを見てみると、


真ん中の少し手前あたりにグラフがいくつか示してあります。各グラフの詳しい説明は、必要ならば以前の記事



をお読みください。上の記事でもあるように、カメラの各種特性はSharpCapを使うと自分で測定する事ができます。実測値はメーカーの値とかなり近いものが得られます。

グラフから読み出しノイズを読み取ります。gain 120の場合おおよそ

1.8 [e rms]

ということがわかります。rmsはroot mean sqareの意味で日本語だと実効値、時系列の波形の面積を積分したようなものになります。例えば片側振幅1のサイン波なら1/√2で約0.7になります。他のノイズも実効値と考えればいいはずなので、ここではrmsはあえて書かなくて

1.8 [e]

としていいでしょう。

読み出しノイズは、実際の測定では真っ暗にして最短露光時間で撮影したバイアスフレームのノイズの実測値に一致します。以前測定した結果があるので、興味のある方はこちらをご覧ください。



ダークノイズ

ダークノイズの元になる暗電流に関しては温度と1枚あたりの露光時間が決まってしまえば一意に決まってしまい、これもZWOのASI294MM Proのページから読み取ることができます。

私はこの値を実測したことはないのですが、そーなのかーさんなどがSV405CCですが同系のIMX294センサーで実測していて、メーカー値とほぼ同じような結果を得ています。

グラフから温度-10℃のところの値を読み取ると暗電流は

0.007 [e/s/pixel]

となるので、1枚あたりの露光時間300秒をかけると

2.1 [e/pix]

となります。/pixはピクセルあたりという意味なので、ここは略してしまって

2.1[e]

としてしまえばいいでしょう。単位[e]で考えた時に、暗電流のルートがダークノイズになるので、

sqrt(2.1)=1.5[e]

がダークノイズとなります。

(追記: 2023//4/19) ちょっと脱線ですが、だいこもんさんのブログを読んでいると、2019年末の記事に「dark currentはgain(dB)に依存しないのか?」という疑問が書かれています。答えだけ言うと、[e]で見ている限り横軸のゲインに依存しないというのが正しいです。もしダークカレント、もしくはダークノイズを[ADU]で見ると、元々あったノイズがアンプで増幅されると言うことなので、単純に考えて横軸のゲイン倍されたものになります。実際の画面でも横軸ゲインが高いほど多くのダークノイズが見られるでしょう。でも、コンバージョンファクターをかけて[ADU]から[e]に変換する際に、コンバージョンファクターが横軸のゲイン分の1に比例しているので、積はゲインによらずに一定になるということです。

ちなみに、ホットピクセルはダーク補正で取り除かれるべきもので、ここで議論しているダークノイズとは別物ということを補足しておきたいと思います。

(さらに追記:2023/10/15)
ダークファイルを撮影したので、実際のダークノイズを測定してみました。画像からのノイズの読み取り値は2.6 [ADU]でした。コンバージョンファクターで単位を[e]にすると、2.6x0.9 = 2.3 [e]。ここから読み出しノイズを引いてやると、2乗の差のルートであることにちゅいして、sqrt(2.3^2-1.8^2) = 1.5 [e] と見積り値に一致します。このように、見積もりと実測が、かなりの精度で一致することがわかります。


スカイノイズ

ここが今回の記事の最大のポイントです。読み出しノイズとダークノイズだけならグラフを使えばすぐに求まりますが、恐らくスカイノイズの評価が難しかったので、これまでほとんど実画像に対してノイズ源の評価がなされてこなかったのではないでしょうか?ここでは実画像の背景部の明るさからスカイノイズを推測することにします。

まず、明るさとノイズの関係ですが、ここではコンバージョンファクターを使います。コンバージョンファクターはカメラのデータとして載っています。例えばASI294MM Proでは先ほどのZWOのページにいくと縦軸「gain(e/ADC)」というところにあたります。コンバージョンファクターの詳しい説明は先ほど紹介した過去記事を読んでみてください。コンバージョンファクターは他に「ゲイン」とか「システムゲイン」などとも呼ばれたりするようです。名前はまあどうでもいいのですが、ここではこの値がどのようにして求められるかを理解すると、なぜスカイノイズに応用できるか理解してもらえるのかと思います。

コンバージョンファクターの求め方の証明は過去記事の最後に書いてあるので、そこに譲るとして、重要なことは、画像の明るさSとノイズNは次のような関係にあり、
(N[ADU])2=S[ADU]fc[e/ADU](N[ADU])2=S[ADU]fc[e/ADU]明るさとノイズの二つを結ぶのがコンバージョンファクターfcとなるということです。逆にいうと、このコンバージョンファクターを知っていれば、明るさからノイズの評価が共にADU単位で可能になります。

もっと具体的にいうと、コンバージョンファクターがわかっていると、スカイノイズが支配していると思われる背景部分の明るさを画像から読み取ることで、スカイノイズを直接計算できるということです。これは結構凄いことだと思いませんか?


実際のスカイノイズの見積もり

それでは実画像からスカイノイズを見積もってみましょう。最初に示した2枚のM81の画像のうち、上の開田高原で撮影した画像の元の1枚撮りのRAW画像を使ってみます。

上の画像は既にオートストレッチしてあるので明るく見えますが、ストレッチ前の実際のRAW画像はもっと暗く見えます。明るさ測定はPixInsight (PI)を使います。PIには画像を解析するツールが豊富で、今回はImageInspectionのうち「Statistics」を使います。まず画像の中の暗く背景と思われる部分(恒星なども含まれないように)をPreviewで選び、StatisticsでそのPreviewを選択します。その際注意することは、カメラのADCのbit深度に応じてStatisticsでの単位を正しく選ぶことです。今回使ったカメラはASI294MM Proなので14bitを選択します。輝度の値は「mean」を見ればいいでしょう。ここでは背景と思われる場所の明るさは約920 [ADU]と読み取ることができました。ついでに同じStatisticsツールのノイズの値avgDevをみると17.8 [ADU]と読み取ることが出来ました。

もっと簡単には、画像上でマウスを左クリックするとさまざまな値が出てきますので、その中のKの値を読み取っても構いません。ここでも同様に、単位を「Integer Renge」で手持ちのカメラに合わせて「14bit」などにすることに注意です。

いずれのツールを使っても、背景と思われる場所の明るさは約920[ADU]と読み取ることができました。

前節の式から、輝度をコンバージョンファクターで割ったものがノイズの2乗になることがわかります。gain120の時のコンバージョンファクターはグラフから読み取ると0.90程度となります。

これらのことから、背景に相当する部分のノイズは以下のように計算でき、

sqrt(920/0.90) = 32.0 [ADU] -> 28.8 [e]

となります。どうやら他の読み出しノイズやダークノイズより10倍程大きいことになります。あれ?でもこれだとちょっと大きすぎる気がします。しかも先ほどのStatisticsツールでの画面を直接見たノイズ17.8[ADU]をコンバージョンファクターを使って変換した

17.8 [ADU] x 0.90 [e/ADU] = 16.0 [e]

よりはるかに大きいです。これだと矛盾してしまうので何か見落としているようです。

計算をじっくり見直してみると、どうやら測定した輝度は「背景光」とオフセットの和になっているのに気づきました。撮影時のオフセットとして40を加えてありますが、この値に16をかけた640がADUで数えたオフセット量として加わっているはずです。実際のマスターバイアス画像を測定してみると、輝度として平均で約640 [ADU]のオフセットがあることがわかったので、これは撮影時に設定したものとぴったりです。この値をを920 [ADU]から引いて、280 [ADU]を背景光の貢献分とします。その背景光からのスカイノイズ成分は

sqrt(280/0.90) = 17.6 [ADU]


これを[ADU]から[e]に変換するためにさらにコンバージョンファクター[e/ADU]をかけて

17.6 [ADU] x 0.90 [e/ADU] = 15.9 [e]

となります。これだと画面からの実測値16.0[e]と少なくとも矛盾はしませんが、既に実測のトータルノイズにかなり近い値が出てしまっています。果たしてこれでいいのでしょうか?


各ノイズの貢献度合い

次にこれまで結果から、各ノイズの貢献度を見ていき、トータルノイズがどれくらいになるのかを計算します。

画像1枚あたりの背景に当たる部分の各ノイズの貢献度は多い順に
  1. スカイノイズ: 15.9[e]
  2. 読み出しノイズ: 1.8 [e]
  3. ダークノイズ: 1.5[e]
となります。Statisticsツールで測定した実際の1枚画像の背景のノイズの実測値は14.9[e]程度だったので、上の3つのノイズがランダムだとして2乗和のルートをとると、

sqrt(15.9^2+1.8^2+1.5^2) = 16.0 [e]

となり、実測の16.0[e]になる事がわかります。スカイノイズに比べてトータルノイズがほとんど増えていないので、読み出しノイズとダークノイズがほとんど影響していないじゃないかと思う方もいるかもしれません。ですが、互いに無相関なノイズは統計上は2乗和のルートになるので本当にこの程度しか貢献せず、実際にはスカイノイズが支配的な成分となっています。

ここまでの結果で、今回のスカイノイズ成分の推定は、定量的にも実画像からの測定結果とほぼ矛盾ないことがわかります。この評価は結構衝撃的で、暗いと思われた開田高原でさえスカイノイズが圧倒的だという事がわかります。


富山の明るい空

ちなみに、最初の2枚の画像のうち、下のものは自宅で撮影したM81です。富山の明るい北の空ということもあり、そのRAW画像のうちの最も暗い1枚(2022/5/31/22:48)でさえ、背景の明るさの読み取り値はなんと3200[ADU]程度にもなります。バイアス640を引くと2560[ADU]で、開田高原の背景光の値240に比べ約10倍明るく、ノイズは

sqrt(2560/0.90) = 53.3 [ADU] -> 48.0 [e]

となります。実際の画像からPIのStatisticsで読み取ったトータルノイズの値が53.4[ADU]->48.1[e]でした。

スカイノイズ48.0[e]に、読み出しノイズ1.8 [e] 、ダークノイズ1.5[e]を2乗和のルートで考えるとトータルノイズは

sqrt(45.0^2+1.8^2+1.5^2) = 48.1 [e]

となり、明るい画像でも背景光の輝度から推測したノイズをもとに計算したトータルノイズ値と、画面から実測したノイズ値が見事に一致します。

開田高原の暗い画像でさえスカイノイズが支配的でしたが、富山の明るい空ではスカイノイズが読み出しノイズ、ダークノイズに比べて遥かに支配的な状況になります。淡いところが出なかったことも納得の結果です。

うーん、でもこんなスカイノイズが大きい状況なら
  • もっと露光時間を短くして読み出しノイズを大きくしても影響ないはずだし、
  • 冷却温度ももっと上げてダークノイズが大きくなっても全然いいのでは
と思ってしまいます。でもそこはちょっと冷静になって考えます。早急な結論は禁物です。次回の記事では、そこらへんのパラメータをいじったらどうなるかなどに言及してみたいと思います。


まとめ

背景の明るさとコンバージョンファクターから、スカイノイズを見積もるという手法を考えてみました。実際の撮影画像のノイズ成分をなかなか個別に考えられなかったのは、スカイノイズの評価が難しいからだったのではないかと思います。

今回の手法は背景の明るさが支配的と思われる部分がある限り(天体写真のほとんどのケースは該当すると思われます)スカイノイズを見積もる事ができ、状況が一変するのではと思います。また手法も輝度を測るだけと簡単なので、応用範囲も広いかと思われます。

今回の手法を適用してみた結果、実際に遠征した開田高原のそこそこ暗い空で撮影した画像でさえもスカイノイズが支配的になる事がわかりました。もっと暗い状況を求めるべきなのか?それとも露光時間を短くしたり、温度を上げてしまってもいいのか?今後議論していきたいと思います。

とりあえず思いつくアイデアをばっとまとめてみましたが、もしかしたら何か大きな勘違いなどあるかもしれません。何か気づいたことがありましたらコメントなどいただけるとありがたいです。


この記事の続き



になります。露光時間と温度について、実際の撮影においてどの程度にすればいいか評価しています。








このページのトップヘ