ほしぞ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フィルターを入れると、雲が入った時の画像のスタックを回避できるので、そういったことも今後試していきたいと思います。

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



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

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


まとめ

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

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

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








前回の記事では、ノイズだけ考えたら露光時間を短くしてもいいという結論でしたが、一つ重要なことを言い忘れてました。今回の記事につながることなのですが、露光時間を短くしすぎると、天体自身が暗くなりすぎる場合があります。これまで考えてきたノイズ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を求めています。








    このページのトップヘ