ほしぞloveログ

天体観測始めました。

カテゴリ:アイデア、理論など > ノイズ

今回は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日の明るいうちの移動としました。自宅に着いて部屋とかを見てみましたが、自宅は富山市内でも山川に近い比較的南の方で、幸いなことに何かが倒れるとかいう被害もほとんどありませんでした。天体機材もほぼ無事で、棚の上の方に置いてあった空箱が一つ落ちたくらいでした。

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

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

めだかと暮らすひとさんが、SharpCapでのライブスタック撮影で、縞ノイズに悩まされているようです。



ここではできる限り簡単な解決策の一つとして、ガイド無しのディザー撮影のやり方を示したいと思います。


縞ノイズの原因

 最近電視観望というと、リアルで見ると言うより、ライブスタックを使った簡単な撮影を指すことも多いようです。めだかと暮らすひとさんも、最近やっとAZ-GTiを赤道儀モードにして、視野回転のない追尾を実現したとのことです。でもまだガイド鏡もなく、ノータッチガイド(死語?)での撮影で、電視観望的にライブスタックを利用して、最後にスタックされた画像を処理しているとのことです。問題は、赤道儀の極軸が合っていないとライブスタックをの間に画面が流れていって、縞ノイズができてしまうことです。これは例え極軸が合っていたとしても、またガイド撮影をして画面が流れないように頑張っても、機材のたわみなどがごく普通に存在するので、1時間オーダーの長時間の撮影では縞ノイズが出ることがよくあります。

縞ノイズの原因は、ホットピクセルやクールピクセルなどの、センサーのある点にいつも存在する異常ピクセルが、画面の流れとともに全て同じ方向に動き、縞のようになることです。


縞ノイズの解決策

縞ノイズ軽減する方法の一つは、ダーク補正することです。SharpCapには簡単なダーク補正方法が搭載されていて、右側パネルの「ダーク補正」の「Hot and Cold Pixel Remove」を選び、簡易補正で済ませます。これはホットピクセルとコールドピクセルを簡易的に取り除く機能ですが、つい最近搭載されたもので、これまでは「Hot Pixel Removal Only」とホットピクセルのみの除去しかできませんでした。以前示したSharpCap上でダークファイルを撮影してリアルタイムダーク補正することもできますが、

ダークファイルでの補正だと基本的にコールドピクセルの補正はできないはずなので、簡易的ですが「Hot and Cold Pixel Remove」の方が有利な可能性が高いです。このオプションががある場合とない場合では数のような違いがあります。
comp
左がオプションなし、右がオプションありです。左の画像を見ると、赤とか緑の輝点が下向きに伸びているのがわかります、右もすごくよく見るとまだ輝点が残っているのがわかりますが、ほとんど目立っていないのがわかります。

それでもダーク補正では縞ノイズを軽減するだけで、完全に消すことはできません。一番確実な方法は、ディザー撮影をすること。ディザーというのは、長時間撮影の途中でわざと画面を数ピクセルとかずらして、異常ピクセルの影響を散らしてやることでかなり軽減できます。今回の問題はこのディザー、一般的にはガイド撮影と込で実現されるので、ガイド撮影をしていない限りディザーはできないと認識されているだろうことです。めだかと暮らすひとさんみたいに、ガイドをしていなくても縞ノイズを解決したいという要求はきっとあることでしょう。


ガイド無しディザーの方法

その方法ですが、前提としてSharpCapで経緯台、赤道儀などが接続されていて、SharpCapからコントロールできることです。赤道儀でなくてもコントロールできるなら経緯台でも構いません。今回はトラバースで試しました。トラバースはAZ-GTiのミニチュア版とも言える、自動導入、自動追尾機能がある経緯台です。

設定方法です。まずメニューの「ファイル」の「SharpCapの設定」の中の「ガイディング」タブで、下の画面のように「ガイディングアプリケーション」を3つ目の「ASCOMマウントパルス...」を選びます。

07_guide_setting
「ディザリング」の中の「最大ディザステップ」はある程度大きくしておいた方が効果が大きいです。私は「40」まで増やしました。値が小さいと効いているかどうかもわかりにくいので、最初多少大きめの値をとっておいて効果を確認し、大きすぎたら減らしていくがいいのかと思います。

その後、ライブスタックの下部設定画面の「Guiding」のところで、最初のチェック「Monitor Guideng Application...」をオンにします。「Automatically DIther」をオンにし、「Dither every:」でどの頻度ディザーするのか選びます。撮影の場合は「Frames」を選んで、何枚撮影することにディザーをするかを選んだ方がいいでしょう。実際には数分に1回くらい散らせば十分なので、今回の1回の露光時間が20秒とすると、10枚に1枚、3分ちょっとに1回ずらすことにしました。
05_dither

するとライブスタックで10枚スタックするごとに、下の画面のように上部にの緑色のバーが現れて、ディザーが実行されます。
06_dither

実際にディザーの効果があるか確認してみましょう。30フレーム分を動画にしてみました。輝点が右下に進んでいきますが、その途中で一度カクッと下に降りて、またカクッと上に上がるのがわかると思います。でもまだずれが少ないので、もっと大きな値でも良かったかもしれません。
Blink

実際のSharpCap上のライブスタック画面では、ディーザーが何度が進むと、最初に見えていたミミズが散らされてどんどん薄くなっていきます(すみません、画像を保存するのを忘れてしまいました)。

ただし、今回は雲がすぐに出てきてしまい、実際の長時間で縞ノイズが見えたわけではないので、ディざーなしで縞ノイズが出て、ディザーをオンにして縞ノイズが消えることを確認すべきなのですが、今回はとりあえず手法を書くだけにしました。後日確認ができたら、また結果を追加したいと思います。


ついでの画像処理

最後に、今回撮影した画像2種を仕上げてみました。FMA135にCBPを付け、Uranus-Cで撮ってます。課題はトラバースなので小さくて楽なものです。ただし経緯台なので星が回転もしくは流れてしまうので長時間露光はできず、1フレーム当たり20秒露光の露光で、ゲインは高めの300としています。共に、かなり淡いところまであぶ出していますが、上の動画でもわかりますが、少なくとも経緯台でガイド無しなので、撮影時にかなり流れてはいるのですが、これくらいの露光時間ではかなり炙り出しても縞ノイズは出ていないことがわかるかと思います。


M42: オリオン大星雲
オリオン大星雲はライブスタックで30フレームの計600秒、ちょうど10分経った時に保存したfitsファイルから画像処理しました。SharpCapの時点でスタックまで終わっているので、かなり楽です。星雲本体周りの分子雲も少し写っています。
Stack_16bits_30frames_600s_21_35_52_crop_SPCC_ABE4_BXT_MS2

向きを変えて星雲部分を切り取り。
Stack_16bits_30frames_600s_21_35_52_crop_SPCC_ABE4_BXT_MS_cut2

口径3cmの高々10分でこれならまずまずではないでしょうか。


M31: アンドロメダ銀河
2枚目はM31、アンドロメダ銀河です。こちらは途中雲がかかり、ライブスタック画像ではかすみがかってしまったので、別途1枚1枚保存してあったRAWファイルから、PixInisightでスタックして処理しました。トータル露光時間はM42よりさらに短く、14枚でわずか4分40秒です。
3856x2180_EXPOSURE_20_00s_ABE4_SPCC_BXT_GHT_HT_bg_rot
こんな短い時間でも、情報としてはある程度残っているものです。さすがにかなりギリギリ出しているので、どうしてもノイジーなのは否めません。


まとめ

今回は、ガイド無しでディザーする方法を示しました。まだ実際の長時間撮影はできていないので、またいつか試したいと思います。

曇りがちで十分な撮影時間をかけることができませんでしたが、それでも口径3cmでもそこそこ情報は残っていて、ある程度画像処理すれば十分見えるくらいにはなることがわかりました。途中で気づいたのですが、ライブスタック時にBrightnessフィルターを入れると、雲が入った時の画像のスタックを回避できるので、そういったことも今後試していきたいと思います。

こうやって見ると、小さなトラバースでも撮影に耐え得るくらい、十分に安定していることがわかります。



この記事は「実画像のノイズ評価(その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とかけ離れています。一つの可能性は、北の空なので街明かりが効いていたというのはあり得るかもしれません。と考えると、チリも方向によって明るさが結構違うのか?昔方個別の光害マップ「ふくろう」というのがあったのですが、残念ながらもう稼働していないようです。

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


まとめ

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

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

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








前回の記事では、ノイズだけ考えたら露光時間を短くしてもいいという結論でしたが、一つ重要なことを言い忘れてました。今回の記事につながることなのですが、露光時間を短くしすぎると、天体自身が暗くなりすぎる場合があります。これまで考えてきたノイズNに対して、目的の天体である信号Sが小さすぎて、S/N(Signal to Noise ratio, SN比)が悪くなってしまうということです。

露光時間を伸ばしたり縮めたりすることで、ADC(Analog to Digital Converter)のダイナミックレンジ内に、適した大きさの信号を入れるということです。露光時間を伸ばすと、ダークノイズもスカイノイズも大きくなるので、単に暗いからといって闇雲に長くすればいいというわけでもないです。

露光時間もそうですが、カメラのゲイン(一眼レフカメラならISO)も同じような状況で、こちらも信号をADCのダイナミックレンジ内に持ってくるという重要な役割があります。同時に、ゲインを変えると読み出しノイズの効きも変わってくるので、こちらも単純な話ではありません。




ゲインの調整

まず簡単なゲインの方から片付けましょう。最近のCMOSカメラのゲインの選択については、天体写真撮影の場合、ほぼ2択のみだと考えています。具体的には、ゲイン0か、HCG (High Conversion Gain)モードが起動するところです。HCGが起動するゲインはカメラによりますが、典型的にはゲイン100とか120とかです。少しピックアップしてみると
  • ZWO ASI294MC, MC Pro, MM Pro (IMX294): gain 120
  • Player One Artemis-C Pro (IMX294): gain 120 
  • ZWO ASI533 MC Pro, MM Pro (IMX533): gain 100
  • Player One Saturn-C (IMX533): gain ~125
  • ZWO ASI2600 MC Pro, MM Pro (IMX571): gain ~100
  • Player One Poseidon-C Pro, M Pro (IMX571): gain ~120
  • ZWO ASI2400 MC Pro (IMX410): gain ~140
と、100から140、典型的には120ですかね。センサーが同じでもHCG発動ゲインはメーカーによって違うので、これはセンサー自身で決まるのではなく、カメラメーカーの組み込みの際のアナログ回路のゲイン調整で決まるものかと推測されます。

どのカメラも、グラフを見てもらうとわかりますが、ゲインが0かHCGのところでダイナミックレンジが大きいです。このダイナミックレンジが大きいというのが有利なところになるので、ゲインは2択となるわけです。明るい対象ならゲイン0、暗い対象ならHCGということです。

ラッキーイメージや電視観望など、露光時間が極端に短く、ダイナミックレンジを犠牲にしても明るく撮りたい場合は、ゲインをもっと上げて信号をADCの適正範囲内に持ってくるということは、戦略として正しいかと思います。私はラッキーイメージはあまりやりませんが、電視観望の場合はゲインを400とかそれ以上にします。

さて、典型的なHCGのゲイン120ですが、ゲイン0とどれくらい明るさが違うのでしょうか?ゲインの単位は0.1dBなので、12dBの違いがあることになります。では12dBとはどれくらいの倍率なのでしょうか?

定義式は20 x log10(gain)なので、0dBで1倍、20dBで10倍、40dBで100倍、−20dBで0.1倍、-40dBで0.01倍、6dBで2倍、−6dbで1/2倍、10dBで約3倍、−10dbで約1/3倍とかなるので、12dbだと6+6dBで、2x2=4倍になります。実測でもほぼ4倍になります。そう、高々4倍なのですよね。

高々これくらいの違いなので、淡い天体写真の場合にはゲインを上げて明るく撮ったほうが有利なので、実質的にはゲインはHCGのところ一択だと思っていて、私はゲイン0dBで撮影したことは未だありません。

というわけで、ゲインはHCGのところで固定としましょう。これ以降の明るさ調整は、露光時間のみで行うことにするとします。


露光時間の調整

ゲインが固定なら、露光時間は目標天体が十分な明るさになるように設定すればいいだけです。でも、この「十分な明るさ」というのが、ものすごく難しいのです。

ある露光時間で撮影した天体の明るさと、前回までで求めたノイズからS/Nが決まります。当然S/Nは高いほどいいので、露光時間を伸ばせば伸ばすほどS/Nは上がり、星雲などの淡い天体はよく見えるでしょう。でも撮影しているのは星雲とかの淡い天体ばかりではなく、恒星など狭い範囲ですが非常に明るくなる天体も含まれています。露光時間を長くすると、当然このような明るい恒星などは飽和してしまいます。そのため、露光時間に上限ができます。それでも画角内に3等星や2等星以上の明るい恒星があると、飽和を避けて淡い天体を写すことは難しくなってきて、その場合は飽和を許容し、明るい恒星のためにあえて露光時間を短くして暗くして別撮りし、HDR(High Dynamic Range)合成などという手を取ることもあり得ます。

露光時間の上限は飽和のみで決まるというわけではなく、赤道儀などの性能でも決まり、星像が流れない範囲で露光時間の上限が決まるということもあるでしょう。突発的な車のライトの映り込みなどもあり得ることを考えると、露光時間を例えば1時間とすることはあまり現実的ではありません。


S/Nの見積もりかた

これまでの検証で、具体例として開田高原で撮影したM81の1枚画像では、背景光の部分は14.9 [e]くらいのノイズがあって、その中でスカイノイズが支配的だということがわかっています。

でも1枚撮りの画像を見ているだけだと、どこが分子雲でどこが背景なのか、なかなかわからないと思います。例え分子雲がある場所だとしても、この1枚画像だけでは分子雲としての信号に相当するSが小さいため、S/Nが相当低くなってしまっていて、おそらく1以下とかになっているということです。

ではここでクイズです。そもそも、S/Nが「1」ということはどういうことなのでしょうか?単純にはノイズNに対して、同じ大きさの信号Sがあるということです。でも、Nと同じ大きさのSというのも、よく考えるとあまり単純なことではありません。例えば、ノイズとして背景光が支配的で、背景光の量が100、そのノイズがルートをとってN=10と仮定します。この時、天体が写っている領域の輝度を測定したとして、一体幾つならば、S/Nが1となるでしょうか?単位は面倒なのでノイズも信号も [ADU] (ADCのカウント数)とします。

ノイズが10 [ADU]なので、測定された輝度が10 [ADU] となる所がS/Nが1となるのでしょうか?でも、一番暗いはずの背景光自身が100もあるので、(ある領域の輝度を平均した場合)輝度が10の所なんて、そもそも無いですよね。なので、ここでは測定された(平均)輝度から背景光を引いたものと比較するとしましょう。色々考えたのですが、こう考えるのが一番自然かと思います。この場合、輝度が110と測定されたところが110-100=10でSが10となり、S/Nが1となる所です。例えば、輝度が200ならば、200-100=100でS/Nが10になりますね。

でも実はこれだけではまだ不十分で、まず撮影された画像には底上げされたオフセットがある可能性があります。SharpCapやNINAで「輝度」とか「オフセット」とかいう値です。ASI294MM Proではこの値に16をかけたものが画面全部に加わっています。 この値をあらかじめ輝度から引いてやらなければならないことに注意です。私は撮影時はいつも40という値を使っているので、40x16=640を、測定した輝度から引いた値が正しい輝度になります。

さらにややこしいのが、天体部分の明るさからくるショットノイズがノイズとして加わります。分母のノイズ部分に、明るさのルートからくるショットノイズを2乗和のルートを取る形で加えてやり、それがノイズNとなります。淡い天体部分ではあまり効きませんが、明るい天体部分では無視できないでしょう。 

さらに忘れてはいけないのは、背景ではスカイノイズが 支配的として考えましたが、ダークノイズや読み出しノイズが支配的な状況では、これらのノイズも2乗和のルートを取る形で加えてやる必要があります。

こうしてNが決まるので、多少ややこしいですが、Sの値としては、測定した輝度値から背景光量とオフセット量を引くということに注意すればいいのかと思います。


実際の画像でのS/Nの見積もり
 
では、実際の撮影画像でどれくらい信号があるのか見積もってみましょう。評価したいのはこれまでと同じ、開田高原で撮影したM81のL画像の1枚撮りです。1枚撮りのRAW画像をストレッチしたものが下になります。

2023-01-21_22-52-45_M 81_L_-10.50C_300.00s_0000_HT
 
今回は背景と分子雲のところの違いを見たいのですが、1枚撮り画像だと背景と分子雲の見分けがつきません。そのためまずはスタック済みでS/Nを上げたものを使います。

ただし、通常のWBPPなどのプロセスでスタックしたものは、ダーク補正やフラット補正、さらにIntegration時に背景の規格化などをしていて、背景の値が変わってしまうため、今回はこれらの補正や規格化を一切しないでスタックした画像を、別途用意しました。スタック済み画像で評価して、スタックの効果を取り除いて1枚画像でのS/Nを評価しようという算段です。

下が、スタック済み未処理画像をjpegにしたものです。リニア画像なので、実際の見た目は真っ暗で、所々に恒星が見えるだけです。
just_integration1_HT_normal

わかりやすくするためにマニュアルでストレッチしたものを下に載せておきますが、測定はあくまで上の真っ暗な画像を使います。フラット補正や、ABE、DBEなどをしていないため、周辺減光もそのまま残ってしまっています。それでも銀河本体の周りに分子雲があるところなどがわかると思います。

just_integration1_HT

その中で、右下部分で、下の画像のように三点を抜き出して評価します。
previews

  • Preview01が「背景」に近いかなり暗いところ
  • Preview02が少なくとも「分子雲」とはっきりわかるところ
  • Preview03が「銀河の腕」の部分
の3箇所で進めます。一点での測定ではノイズのため輝度にばらつきが出てしまうので、PixInsightのプレビュー機能を使い、ある程度の面積の平均輝度を測定しました。実際の測定は暗いリニア画像を用いています。
    結果は
    • 背景: 940.8 [ADU]
    • 分子雲: 943.2 [ADU]
    • 銀河の腕: 974.9 [ADU]
    となりました。今回、背景と言っても本当の背景かどうかはわからないのですが、周辺減光の影響があまりなさそうな所でかなり暗いところを選んだので、ここの輝度を背景光の平均輝度とします。このシリーズのその1で測定した920と20程度の差がありますが、あの時は比較的暗い画像を選んだので、スタックして平均をとるとこのくらいになるのかと思います。場所は同じようなところを選んでいます。

    これらの値から、オフセット分の40x16 = 640を引くと
    • 背景: 300.8 [ADU]
    • 分子雲: 303.2 [ADU]
    • 銀河の腕: 334.9 [ADU]
    となります。これが実測の輝度となります。

    さらに、天体部分の後ろ2つから、背景光分の輝度300.8を引くと
    • 分子雲: 3.2 [ADU]
    • 銀河の腕: 34.9 [ADU]
    となりますが、これが信号のSに相当します。単位は[ADU]なので、コンバージョンファクターを使って[ADU]から[e]に変換します。コンバージョンファクターは測定値の[ADU]から、比較に便利な共通単位の[e]に変換できる、重要な値でしたね。ここでは横軸gainが120の所の、0.9 [e/ADU]を上の値に掛けてやります。その結果
    • 分子雲: 2.9 [e]
    • 銀河の腕: 31.4 [e]
    となります。

    一方ノイズですが、同じ場所の実測値を使います。これまで見積もり値を使ってきましたが、実測値とよく一致していることがもうわかっているので、そのまま実測値を使ってしまっていいでしょう。なぜ実測値を使いたいかというと、天体の明るさが起因のショットノイズも含んでいるからです。そのため、より現実的なS/Nを得ることができるからです。ノイズの実測値は、単位を[e]にするところまで求めて、
    • 背景: 3.07 [ADU] -> 2.76 [e]
    • 分子雲: 3.16 [ADU] -> 2.84 [e]
    • 銀河の腕: 3.73 [ADU] -> 3.36 [e]
    となります。

    SとNが単位[e]で出たので、S/Nが計算でき、
    • 分子雲部分のS/N: 2.9/2.76 =  1.04
    • 銀河の腕部分のS/N: 31.4/3.36 = 11.0
    となりました。

    ヒョエー!?
    分子雲のところ、何とS/Nがわずか1程度です!
    しかもこれ28枚の画像をスタックした後の値ですよ...。

    S/N=1ということは、背景に比べた明るさの持ち上がり具合が、そこでの輝度のばらつき具合と同じくらいということです。実際、スタックされた画像を見る限り、やはりそれくらいかと思います。

    さらに1枚画像で考えると、S/Nはルート28 = 5.3分の1に減るので、1.04 / 5.3 = 0.196となります。やはり1枚画像ではS/Nが1よりかなり下で、分子雲がノイズの中に埋もれてしまい、見分けがつかなかったということに納得できます。

    その一方、銀河の部分はかなり明るくS/Nも10以上と高いです。スタックの効果を無くした1枚画像でも、同様の計算で11.0 / 5.3 = 2.08となり、S/Nが2を超えていて十分に大きく、撮影直後でもストレッチさえしてしまえば腕の形も認識できることがわかります。
     

    まとめ

    今回は信号を考えてみて、実際の画像の特に淡いところを見積もってみました。S/Nの具体的な評価方法がかなり見通しよくなったかと思いますし、実際の画像を見た直感的な印象ともかなり一致すると思います。

    今回の計算中に、前の記事での細かい計算ミスが見つかり、直しておきました。もしかしたらまだ大きな勘違いがあるかもしれないので、もし何か気づいた方がいましたら、コメントなどお願いします。







    この記事は、実画像のノイズ評価(その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]

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

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

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


    まとめ

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

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

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

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


    この記事の続き



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








    このページのトップヘ