ほしぞloveログ

天体観測始めました。

タグ:SN比

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

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

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

前回の記事では、ノイズだけ考えたら露光時間を短くしてもいいという結論でしたが、一つ重要なことを言い忘れてました。今回の記事につながることなのですが、露光時間を短くしすぎると、天体自身が暗くなりすぎる場合があります。これまで考えてきたノイズ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の具体的な評価方法がかなり見通しよくなったかと思いますし、実際の画像を見た直感的な印象ともかなり一致すると思います。

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







    このページのトップヘ