ほしぞloveログ

天体観測始めました。

タグ:binning

今回は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時近くまで話し込んでいました。ノイズの話で盛り上がること自体がそもそも濃いのですが、さすが星沼会、他に話している内容もとても濃かったです。私自身もかなり楽しい時間を過ごすことができました。ゲスト参加を認めていただき、どうもありがとうございました。

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

ASI294MMで撮影後、画像処理をしていたのですが、一つトラブルがあったのでメモがてら記述しておきます。


ASI224MC Proでの天体撮影

NINAでライトフレーム
NINAを使い普通に天体を撮影しました。ASI294MMはセンサーにIMX492を使っていて、bin1だと8288x5644とかなりの高解像度になります。DSOだとそこまでいらないので、本来のASI294MC(IMX294使用)と同じ4144x2822になるようにNINA上でbin2モードでライトフレームを撮影しました。

SharpCapで補正用フレーム
画像処理用にバイアスフレーム、ダークフレーム、フラットフレーム、フラットダークフレームを撮影する必要があるのですが、画面のレスポンスやヒストグラムの見やすさなどから、SharpCapを使って、これらの後処理用のファイルを撮影しました。その時は解像度を 4144x2822にするために「11 megapixel」の方を選んでbin1を選びました。高解像度の場合には「47 megapixel」なのですが、この場合bin2は選べないようなので、4144x2822にするには「11 megapixelでbin1」が唯一の選択肢になります。


WBPPできない⁉︎

撮影自体はいいのですが、これらを使ってPixInsightで画像処理をしようとするとはまります。下の画像のように、ライトフレームに警告マークが入っていて、バイアス、ダーク、フラットどれも補正してくれにというのです。
binning2x2
最初何が悪いのかわからなかったのですが、色々触っているとどうもビニングの設定が、NINAで撮影したライトフレームは2x2、その他SharpCapで撮影したフレームは1x1となっているのが問題だとわかってきました。でもどちらも画素数は4144x2822です。


解決法

一番簡単な方法は、NINAで補正フレームをライトと同条件にして、全て取り直すことです。でもフラットフレームは撮り直すと合わないことがあるので、できればNINAでの撮り直しは避けたいです。

ここまで撮影してきたファイルをなんとか使うことはできないのでしょうか?

まずわかったのは、このビニング情報はFITSファイルのヘッダに書かれているテキスト情報をただ読んでいるだけなので、例えばライトフレームのヘッダの2x2を1x1に書き換えてやれば、PixInsight上で各種補正をしてくれることはわかりました。


本当にこの方法でいいの?

そうすると次は、そもそもNINAで2x2ビニングと、SharpCapの11 megapixelで1x1ビニングは同じ効果なのか?ソフトウェアビニングが入る余地はないのか?などが疑問になってきました。

海外のページをあたっていくと、特にSharpCapで初期にASI294MMに対応したときに結構な時間をかけてZWOともコンタクトを取りながら決めていった過程を辿ることができました。おそらくは多分混乱のないようにわかりやすくするために高解像度でビニングのない47 megapixelモードと、低解像度で14bitにしたハードウェアビンニングの11 megapixelモードと、あからさまに切り分けたのかと思います。おそらくこの切り分け方が、本来のASI294MMの294の名を冠したことから考えると、正しいのかと思います。

もう一つ重要なことは、ASI294MM Prp発売当初、ここら辺のことで混乱した人が何人もいたようなのですが、先人達の色々な検証の結果一つ言えることは「どんなソフトでも2x2のビニングを入れると確実にハードウェアビニングが入る」ということのようです。なので、NINAで単にbin2を選んだとしても、ソフトウェアビニングになっていることはないということが分かります。

実際のところは自分で検証しない限りは確実ではないですが、調べている限りこの情報は正しいようなので、画像処理を進めるためにもとりあえず1x1と2x2で名前は違うけれど、共にハードウェアビンニングが適用され、4144x2822の画像ができていると思うことにします。


実際のヘッダー情報の書き換え

となると、あとはどうやってFITSヘッダーを書き換えるかです。一枚一枚書き換えていってもいいのですが、ここにあるキーワードの値を書き換える、PixInsight上で動くスクリプトが公開されています。



今回はこれを利用しました。実際にはXBINNING、YBINNINGをそれぞれ書き換える必要があるため、2回走らせます。注意はソースの途中の拡張子が「.fit」になっているてため、「.fits」にしてやることと、最初の方のoldKeywordValueなどの値が「2.」とか小数点まで入れてやらないと動かない時があることくらいです。


WBPPで処理再開

これでライトフレームを1x1ビニングと騙してやることで、下のようにうまくPixInsightのWBPPを走らせ、
binning2x2_mod
きちんと各種補正も適用することができました。

さて、やっとこれでM27の画像処理を続けられます。

このページのトップヘ