ASI294MM Proで試したかった高解像度撮影です。対象はM57です。
実は今回が初のまともなモノクロセンサーを使った撮影になります。一応ASI290MMは持っていて、太陽とかはもちろん本当のモノクロ撮影なのですが、モノクロセンサーにフィルターというので最後のカラー化まで仕上げたのは今回が初めてです。
ASI294MMProを使いたかった理由の一つが、ピクセルサイズの小ささです。Bin1モードのピクセルサイズ2.3μmは、これまで持っていた最小のASI178MCの2.4μmよりも小さく、しかもモノクロなので単純にはさらに半分のピクセルサイズと同等。ASI294MC Proから見たらBin1モードとモノクロで一辺4分の1、面積にしたら16分の1のピクセルサイズと同等です。手持ちのASI290MMのピクセルサイズ2.9μmと比べてもまだ有利になりそうです。
その一方、今回はM57と小さい惑星上星雲なので、広視野はあまり得をしませんが、それでもASI290MMのセンサーサイズの1/2.8インチと比べると、一辺で約4倍、面積で約16倍（実際は13.9倍）です。これくらいあると比較的大きな天体まで狙えることになります。小さな天体はROIで撮影時にカットしてしまえばいいので、こちらは大は小を兼ねるになっています。
その代わりBin1モードはダイナミックレンジと感度は落ちるので、そこをどううまく回避していくか、適材適所で使う必要があります。
実はM57ですが、随分以前から分解のベンチマークとも言える挑戦を続けています。今までの最高がVISACとASI178MCでの撮影で、もう2年ほど前のことになります。
ブログの記事にはしてませんが、その後もちょくちょく、2020年にはTSA120やVISAC、ASI178MCやASI290MM+RGBフィルターなどを色々組み合わせて撮影を続けてました。2021年の今年に入ってからも5月と6月にVISACとNeptune-CIIやASI294MM Pro+RGBフィルターで撮影していたのですが、いずれもシンチレーション が悪かったり、雲が途中から出てRGB全部撮れなかったりで、すべてボツになっていました。たとえ仕上げたとしても2年前のものを全く超えられそうになかったのです。
梅雨が明けてからしばらく、かなりシンチレーションがいい日が続いていて、これは分解能をためすまたとないチャンスです。鏡筒はVISAC。ただしやはりこの鏡筒はじゃじゃ馬の呼び声高く、星像がどうしても落ち着きません。
撮影の様子は7月17日の記事に書いてあります。重なるところもありますが、改めて書いておきます。
今回は初のモノクロ撮影ということで、RGBフィルターで試してみることにしました。もう何年も前にKYOEI Tokyoで特価で売っていたBarderのRGBフィルターをずっと持っていたのですが、やっと日の目を見ることができました。あと、ZWOの1.25インチフィルターが5枚入る電動ホイールもかなり前にKYOEI Tokyoの店舗で買ったものです。もう東京にしばらく行っていなくて最近はネットでの注文ばかりですが、たまにはやはり店舗で色々話ながら購入したくて、懐かしくなってしまいます。
写真にはオフアキ用にASI178MCが付いていますが、これはまだ試していなくてとりあえず付けてあるだけです。
今回はL画像は撮影せずにRGBだけにしてみました。Lは全波長入ってくるので、この解像度だと色収差と大気収差が気になる可能性があるからです。
このように収差に関してもモノクロセンサーは有利になるはずです。これもASI294MM Proを試したかった理由の一つです。
今回は分解能狙いなので、露光時間10秒のラッキーイメージライクにしてみます。実際に撮影時の画像を何枚も見ていると、10秒露光でさえもいい時と悪い時が相当変わるので、シンチレーションの影響が効いているのでしょう。この中から比較的星像が小さくキリッとしているものを後で選ぶことになります。
これまでの結果から、短時間露光では星像が多少は小さくなること、その代わり長時間露光に比べて微光星の写りが悪くなり暗い星が写りにくくなることがわかっています。
なので今回は分解能は出ても、淡いところは長時間露光にかなわないため、M57のさらに周りの淡い部分や、近くにあるIC1296は難しいと思います。
露光時間はR、G、Bそれぞれ30分。その中からいいものを選ぶのでトータルでは1時間半を切ることになり、そこまで長い撮影とはならないです。それでも10秒と短いので各色180枚、トータル480枚となってそこそこの枚数と容量になります。その代わり、ASI294MM Proのフルサイズで撮影するのではなく、ROIで一辺を2分の1にしたので、画像サイズとしては4分の1になります。
撮影にテストで見てみると、Rはキリッと出ても、Gは結構ぼやける、Bはさらにぼてっとするようです。ピント位置のせいかと思い合わせ直したりもしましたが、劇的な改善はしなかったので、今回はRでピントを合わせて、GとBのピント位置はそのままいじらずに撮影しました。そもそもフィルターが同じ厚さなのでピント位置はそのままでいいのか、鏡筒に色収差が多少なりともあるはずなので、やはり合わせ直した方がいいのか、今後もう少し検証する必要があるかと思います。
撮影後、日を置いてflat、flatdark、darkの各フレームを撮影しました。
flatはフィルターがRGBとそれぞれ違うので、それぞれに128枚撮影しました。ただ、少し失敗してしまい、ゲインを220で撮影時と同じにして、露光時間を明るさによってRが20ms、GとBが50msとしたのですが、GとBの露光時間がflatdarkの露光時間と違ってしまい、PixInsightで最初flatdarkが当たらないというトラブルがありました。一応あらわにflatdarkを指定してやることでことなきを得ていますが、もしかしたらflatdarkも別個に撮った方がいいのかもしれません。
そんなこともありflatdarkはゲイン220、（気づかずに）20msで共通で128枚です。さらにですが、もしかしたらflatdarkの枚数が少なかったかもしれません。flatのトータルが384枚なので、せめて倍の256枚か、512枚の方が良かったかもです。
darkはlightと同じ設定、ゲイン220、露光時間10秒、温度-10度で256枚です。最初少しでも暗いところと思い、箱の中に突っ込んでおいたら熱くなったので、再度もう1セット取り直しました。256枚でも1時間弱なので、楽勝です。
RGBの画像処理も初めてです。実際には去年ASI290MMでM57を撮影した時に少しだけ試したのですが、その時はまだテスト撮影みたいなもので、なぜか色バランスが無茶苦茶になったなど仕上げる価値なしと判断しました。なので、まともなRGBでの画像処理は今回が初めてになります。
各lightフレームはPixInsightのBlinkで読み込んで、見た目でだめそうなものを弾きました。SubFrameSelectorもかけたのですが、ある程度は見た目と結果が一致するのですが、明らかに目で見てだめなのに、数値で見るとよく見えてしまうものなどがあったからです。でもこれからするWeighted Batch Preprocessing(WBPP)ですが、処理中に内部でSubFrameSelectorを呼び出してウェイトをつけて判断しているみたいです。もしかしたらきちんと注意してみてやらないとダメなのかもしれません。
実際のWeighted Batch Preprocessing(WBPP)ですが、RGBをいっぺんに放り込んでも処理してくれるものなのでしょうか？まあわからなかったので最初はR、G、Bをそれぞれ処理することにしました。
まず困ったのが、しょっぱなのRの処理の時から位置合わせがうまくいきません。3枚くらいしか位置合わせできないとエラーを吐かれました。
原因はおそらく星の数が少ないことと、星像が丸ではないことです。過去のVISACの撮影の時も同様なことがありました。今後もこのままだと使い物にならないので、別途StarAlingmentを走らせて、回避する方法を探りました。
この問題2つに分かれます。
1. まずは星を星として認識にない場合。
のようなエラーが出ます。この場合はStarAlingmentの中の「Log(sensitivity)」を-2.00とかまで下げます。もしくは「Peak response」を0.9とか1.0まで上げると効果的です。
2. 次にうまく位置が認識されない場合は
のようなエラーが出ます。ここは「Star Matching」の「RANSAC tolerance」の歪許容量を上げることが効果的です。
でも難しいのはここからで、位置が認識されないエラーがでる場合でも、どうも星自身が認識されていないことが原因の場合がある時です。こんな時は「Star Detection」の「Noise reduction」が劇的に効くことがあります。ここを1または2くらいまであげてください。また、「Detection scale」が効くこともあります。こうやって考えると、位置決めの時も星がきちんと星として認識されているかどうかが重要であるのがわかります。むしろ、位置決めがうまくいかないと最初から出た場合、RANSAC toleranceをいじるよりもNoise reductionを増やした方が解決になることも多いです。まずはこちらを試すのがいいのではと思います。
その他のパラメータは色々試しましたが、ほとんど効かないか、効いてもごく僅かでした。
これらのStarAlignmentでの経験をWBPPに反映させます。いじるのは「Lights」タブの「Image Registration」です。StarAlignmentとよく似たパラメータがありますが、StarAlingmentほど細かくありません。とりあえずは一番効果のあるNoise reductionを増やします。これで一応Rは全て位置合わせができてスタックまで完了しました。
ところがです、G(緑)がまだダメなんですよね。Gでは結局WBPPのNoise reductionを2、Detection scaleを6、Log(sensitivity)を-2.00、Peak responseを0.9までして、やっと全枚数スタックされました。
さらにところがです、B(青)はWBPPでは全然ダメなんです。どうパラメータをいじっても数枚しかスタックされませんでした。ところが、StarAlignmentではRANSAC toleranceをあげることができ、そうするとうまく位置決めができます。今回は結局WBPPでは諦めました。WBPPでどうしてもダメでもStarAlignmentの方がもう少し足掻くことができるということは覚えておいてもいいのかもしれません。
出来上がったR画像を見てやると、縦方向に縞ノイズが入っています。縮緬ノイズとも言われているやつです。
よくよく調べると、WBPPの振る舞いが少し変わったようで、そのままだとbiasが使われない設定になっていました。理由はdark frameにflat frameにもbiasが含まれてるので撮影したbias frameは使わなくてもいいということのようです。
私はこれが気に入らなくて、master flatを作る際にbiasを使うようにしました。これはイコールflatdarkを使わないということになります。これが問題だったようです。以前flat補正をする際に縞ノイズが乗っかるのはフラットが何かしらで汚くなる（その時は撮影時間が短くてノイズが載るという理由だった）というのを示したことがありますが、flat frameのダーク補正をしないと、残ったダークノイズが縞ノイズを作るということが今回改めて示されました。こたろうさんが以前この件について言及されていたと思います。
というわけで、biasの代わりにflatdarkを使うと次の写真のように縞ノイズは無くなりました。
RGB合成前の画像を示しておきます。
まずはR。かなり鋭い星像となっています。縮緬ノイズも消えているのがわかります。
Greenは以下のようになりますが、Rに比べると明らかに暗い星が少なく、星像も甘いです。
Bはさらにその傾向が強く、星像もかなり大きくなっていて、明らかに星の数も少ないです。
このような傾向は普通のことなのでしょうか？それともピントがずれているのでしょうか？でもテストで画面を見ていた限り、ピントをどう合わせてもRがいつも鋭くてBは散々でした。
また、これらのズレは画像処理に影響がないのでしょうか？
さて、上の画像をみると、横縞が結構多く残っているので、WBPPの新機能のLinear Pattern Subtractionを試しました。結果だけ言うと、あまりうまくいきませんでした。いくつかの横縞は目だたなくなるのですが、下のようによりハッキリした横縞となぜか縦縞が余分に加えられてしまうようです。
今回はまだあまり試していないですが、一旦ここではLinear Pattern Subtractionを使わないで、次に進みます。
これでやっとR,G,Bのスタックしたものが出来上がりました。ただ、これらをそのままChannelCombinationなのでRGB合成しても星の位置がずれてしまいます。そのため、StarAlignmentで改めてこの3枚を位置合わせしました。これでやっとカラー画像が出来上がりました。
でもR画像で見たときのように、やはり横の線が気になります。なので今回はRGB合成後、ScriptのUtilitiesからCanonBabdingReductionを使いました。これはかなりよかったです。いくつかパラメータを試しましたが、Active Previewはほとんど役に立ちませんでした。値を変えて何度か試した方が良さそうです。デフォルトの1でもほとんど大丈夫でした。0.2だとノイズが消しきれません。また、2だとノイズが加えられるような感じです。0.5と比べると1の場合は少し黒い部分が残っている感じがしました。結局最後0.7としました。要するに大きすぎても小さすぎてもダメなので、いくつか試すといいということです。結果は以下のようになります。
かなり良くなりました。
ここまで来れば、あとはこれまでのカラーの画像処理と同じです。
まずカラーバランスが滅茶苦茶なので、念のためDBEで少しカブリをとってからPCCでカラーバランスを整えます。PCCで恒星の色はそこそこまともになりました。ただ、鋭さがR>G>Bの順でかなり差があるので、鋭いRとボケたBの差で、赤が強いところは赤ハロが、青が広がってしまっているところは青ハロがあるようにも見えます。逆に言えば恒星の色がよく出ているようにも見えます。
その一方、PCCをかけてもどうしても背景が青く見えます。これはヒストグラムを見て理由がわかりました。背景のノイズが青が一番多いのです。おそらくRGBの感度に差があり、Rが一番感度がいいためノイズが少なく、次がG、Bは感度が低いためノイズが大きくなるのかなと推測していますが、実際のところはよくわかりません。もう少し検証が必要かと思います。
いずれにせよ今回はPhotoshopに持っていった際に、背景のRGBのヒストグラムを合わせる事でカラーバランスを整えることにします。
あとは、ArcsineStretchなどでストレッチしてPhotoshopに渡すのですが、よく見ると星像がガタガタです。
特に短時間露光の場合に多いのですが、VISACの星像にはいつも苦労します。今回はなぜか4方向に尖って見えます。しかもスパイダーの方向ではなくて、なぜか45度傾いた方向です。MophologicalTransformationで少し整えますが、星マスクが必要です。
この星マスクも苦労しました。ストレッチ後、StarNetで恒星と背景を分離しようとしても、星の3割ほどしか分離できません。分離できない理由は、星像が汚い、中心のピークが出ていない、明るすぎる、暗すぎるなどです。きちんと丸になっていて、中心がサチり気味の方がうまく分離できるようです。そのため、今回は
こうしてできた星マスクを適用して、MophologicalTransformationで十字型にDilationで伸ばし、X字型にErosionで縮めることで円に近づけていきます。これでやっとPhotoshopに引き渡しです。
今回はPhotoshopではほとんどたいしたことはしていません。ノイズ処理もなしです。ノイズ処理をすると背景がボテボテになり、星像の鋭さと合わなくなってしまうからです。
2年前のVISACとASI178MCで撮ったものと比べます。左が以前のもの、右が今回のものです。
今回は自己ベストかと思ったのですが、分解能だけ見たらもしかしたら以前の方がいいかもしれません。いやこれは画像処理のやりかたのせいで、見栄えをよくしようとした前の方が一見よく見えているだけかも。
もし以前の方がいいというなら、機材は今回の方が圧倒的に有利なので、これは完全にシンチレーション勝負になると思います。2年前の時はよほどシンチレーションがよかったのを覚えています。その他星の色、星雲の自然さ、背景の素直さなどは今回の方が格段に上でしょうか。
そういえば、この撮影の後になってVISACの光軸調整をしたのでした。その結果は反映されてないので、今一度シンチレーション のいい日を狙うとかでしょうか。
初のRGBフィルターでの撮影と画像処理。いろんな新しいことがあってブログ記事が長くなってしまいまた。次回はもう少し早く処理できそうです。
分解能に関しては、やっぱり最後はシンチレーション なのでしょうか。リアルタイムで露光時間を1秒以下にして見てても、明らかに揺らいでいて、10秒ではこれくらいになってしまいます。次は揺れない日を狙うことになるのかと思います。
どうやらM57はAOOでもそこそこ色が出るみたいなので、次はナローのもしかしたら逆に長時間露光で、淡いところに挑戦するかもしれません。
もう一つ、PixInsightの細かいテクです。projectファイルを保存して、ファイルのフォルダ名を変えたり、ファイルの場所を変えたりした時に、WBPPのインスタンスを右クリックして「Excecute in the global context」から再度開こうとすると、以下のようなエラーが出ることがあります。
この場合、WBPのインスタンスををダブルクリックして出てきたMD5 checksumを消してやって、再びインスタンスをPI内で保存。それを右クリックのExcecute in the global contextで開くと普通に開けるようになります。
とうとうモノクロ撮影に
実は今回が初のまともなモノクロセンサーを使った撮影になります。一応ASI290MMは持っていて、太陽とかはもちろん本当のモノクロ撮影なのですが、モノクロセンサーにフィルターというので最後のカラー化まで仕上げたのは今回が初めてです。
ASI294MMProを使いたかった理由の一つが、ピクセルサイズの小ささです。Bin1モードのピクセルサイズ2.3μmは、これまで持っていた最小のASI178MCの2.4μmよりも小さく、しかもモノクロなので単純にはさらに半分のピクセルサイズと同等。ASI294MC Proから見たらBin1モードとモノクロで一辺4分の1、面積にしたら16分の1のピクセルサイズと同等です。手持ちのASI290MMのピクセルサイズ2.9μmと比べてもまだ有利になりそうです。
その一方、今回はM57と小さい惑星上星雲なので、広視野はあまり得をしませんが、それでもASI290MMのセンサーサイズの1/2.8インチと比べると、一辺で約4倍、面積で約16倍（実際は13.9倍）です。これくらいあると比較的大きな天体まで狙えることになります。小さな天体はROIで撮影時にカットしてしまえばいいので、こちらは大は小を兼ねるになっています。
その代わりBin1モードはダイナミックレンジと感度は落ちるので、そこをどううまく回避していくか、適材適所で使う必要があります。
小さなM57を綺麗に出したい
実はM57ですが、随分以前から分解のベンチマークとも言える挑戦を続けています。今までの最高がVISACとASI178MCでの撮影で、もう2年ほど前のことになります。
ブログの記事にはしてませんが、その後もちょくちょく、2020年にはTSA120やVISAC、ASI178MCやASI290MM+RGBフィルターなどを色々組み合わせて撮影を続けてました。2021年の今年に入ってからも5月と6月にVISACとNeptune-CIIやASI294MM Pro+RGBフィルターで撮影していたのですが、いずれもシンチレーション が悪かったり、雲が途中から出てRGB全部撮れなかったりで、すべてボツになっていました。たとえ仕上げたとしても2年前のものを全く超えられそうになかったのです。
梅雨が明けてからしばらく、かなりシンチレーションがいい日が続いていて、これは分解能をためすまたとないチャンスです。鏡筒はVISAC。ただしやはりこの鏡筒はじゃじゃ馬の呼び声高く、星像がどうしても落ち着きません。
撮影
撮影の様子は7月17日の記事に書いてあります。重なるところもありますが、改めて書いておきます。
今回は初のモノクロ撮影ということで、RGBフィルターで試してみることにしました。もう何年も前にKYOEI Tokyoで特価で売っていたBarderのRGBフィルターをずっと持っていたのですが、やっと日の目を見ることができました。あと、ZWOの1.25インチフィルターが5枚入る電動ホイールもかなり前にKYOEI Tokyoの店舗で買ったものです。もう東京にしばらく行っていなくて最近はネットでの注文ばかりですが、たまにはやはり店舗で色々話ながら購入したくて、懐かしくなってしまいます。
写真にはオフアキ用にASI178MCが付いていますが、これはまだ試していなくてとりあえず付けてあるだけです。
今回はL画像は撮影せずにRGBだけにしてみました。Lは全波長入ってくるので、この解像度だと色収差と大気収差が気になる可能性があるからです。
このように収差に関してもモノクロセンサーは有利になるはずです。これもASI294MM Proを試したかった理由の一つです。
今回は分解能狙いなので、露光時間10秒のラッキーイメージライクにしてみます。実際に撮影時の画像を何枚も見ていると、10秒露光でさえもいい時と悪い時が相当変わるので、シンチレーションの影響が効いているのでしょう。この中から比較的星像が小さくキリッとしているものを後で選ぶことになります。
これまでの結果から、短時間露光では星像が多少は小さくなること、その代わり長時間露光に比べて微光星の写りが悪くなり暗い星が写りにくくなることがわかっています。
なので今回は分解能は出ても、淡いところは長時間露光にかなわないため、M57のさらに周りの淡い部分や、近くにあるIC1296は難しいと思います。
露光時間はR、G、Bそれぞれ30分。その中からいいものを選ぶのでトータルでは1時間半を切ることになり、そこまで長い撮影とはならないです。それでも10秒と短いので各色180枚、トータル480枚となってそこそこの枚数と容量になります。その代わり、ASI294MM Proのフルサイズで撮影するのではなく、ROIで一辺を2分の1にしたので、画像サイズとしては4分の1になります。
撮影にテストで見てみると、Rはキリッと出ても、Gは結構ぼやける、Bはさらにぼてっとするようです。ピント位置のせいかと思い合わせ直したりもしましたが、劇的な改善はしなかったので、今回はRでピントを合わせて、GとBのピント位置はそのままいじらずに撮影しました。そもそもフィルターが同じ厚さなのでピント位置はそのままでいいのか、鏡筒に色収差が多少なりともあるはずなので、やはり合わせ直した方がいいのか、今後もう少し検証する必要があるかと思います。
後日、 flatやdarkの撮影
撮影後、日を置いてflat、flatdark、darkの各フレームを撮影しました。
flatはフィルターがRGBとそれぞれ違うので、それぞれに128枚撮影しました。ただ、少し失敗してしまい、ゲインを220で撮影時と同じにして、露光時間を明るさによってRが20ms、GとBが50msとしたのですが、GとBの露光時間がflatdarkの露光時間と違ってしまい、PixInsightで最初flatdarkが当たらないというトラブルがありました。一応あらわにflatdarkを指定してやることでことなきを得ていますが、もしかしたらflatdarkも別個に撮った方がいいのかもしれません。
そんなこともありflatdarkはゲイン220、（気づかずに）20msで共通で128枚です。さらにですが、もしかしたらflatdarkの枚数が少なかったかもしれません。flatのトータルが384枚なので、せめて倍の256枚か、512枚の方が良かったかもです。
darkはlightと同じ設定、ゲイン220、露光時間10秒、温度-10度で256枚です。最初少しでも暗いところと思い、箱の中に突っ込んでおいたら熱くなったので、再度もう1セット取り直しました。256枚でも1時間弱なので、楽勝です。
初めてのRGB画像処理
RGBの画像処理も初めてです。実際には去年ASI290MMでM57を撮影した時に少しだけ試したのですが、その時はまだテスト撮影みたいなもので、なぜか色バランスが無茶苦茶になったなど仕上げる価値なしと判断しました。なので、まともなRGBでの画像処理は今回が初めてになります。
各lightフレームはPixInsightのBlinkで読み込んで、見た目でだめそうなものを弾きました。SubFrameSelectorもかけたのですが、ある程度は見た目と結果が一致するのですが、明らかに目で見てだめなのに、数値で見るとよく見えてしまうものなどがあったからです。でもこれからするWeighted Batch Preprocessing(WBPP)ですが、処理中に内部でSubFrameSelectorを呼び出してウェイトをつけて判断しているみたいです。もしかしたらきちんと注意してみてやらないとダメなのかもしれません。
実際のWeighted Batch Preprocessing(WBPP)ですが、RGBをいっぺんに放り込んでも処理してくれるものなのでしょうか？まあわからなかったので最初はR、G、Bをそれぞれ処理することにしました。
スタック時の位置決めがうまくいかない!?
まず困ったのが、しょっぱなのRの処理の時から位置合わせがうまくいきません。3枚くらいしか位置合わせできないとエラーを吐かれました。
原因はおそらく星の数が少ないことと、星像が丸ではないことです。過去のVISACの撮影の時も同様なことがありました。今後もこのままだと使い物にならないので、別途StarAlingmentを走らせて、回避する方法を探りました。
この問題2つに分かれます。
1. まずは星を星として認識にない場合。
2. 次にうまく位置が認識されない場合は
でも難しいのはここからで、位置が認識されないエラーがでる場合でも、どうも星自身が認識されていないことが原因の場合がある時です。こんな時は「Star Detection」の「Noise reduction」が劇的に効くことがあります。ここを1または2くらいまであげてください。また、「Detection scale」が効くこともあります。こうやって考えると、位置決めの時も星がきちんと星として認識されているかどうかが重要であるのがわかります。むしろ、位置決めがうまくいかないと最初から出た場合、RANSAC toleranceをいじるよりもNoise reductionを増やした方が解決になることも多いです。まずはこちらを試すのがいいのではと思います。
その他のパラメータは色々試しましたが、ほとんど効かないか、効いてもごく僅かでした。
これらのStarAlignmentでの経験をWBPPに反映させます。いじるのは「Lights」タブの「Image Registration」です。StarAlignmentとよく似たパラメータがありますが、StarAlingmentほど細かくありません。とりあえずは一番効果のあるNoise reductionを増やします。これで一応Rは全て位置合わせができてスタックまで完了しました。
ところがです、G(緑)がまだダメなんですよね。Gでは結局WBPPのNoise reductionを2、Detection scaleを6、Log(sensitivity)を-2.00、Peak responseを0.9までして、やっと全枚数スタックされました。
さらにところがです、B(青)はWBPPでは全然ダメなんです。どうパラメータをいじっても数枚しかスタックされませんでした。ところが、StarAlignmentではRANSAC toleranceをあげることができ、そうするとうまく位置決めができます。今回は結局WBPPでは諦めました。WBPPでどうしてもダメでもStarAlignmentの方がもう少し足掻くことができるということは覚えておいてもいいのかもしれません。
縞ノイズ(縮緬ノイズ)が出てる!?
出来上がったR画像を見てやると、縦方向に縞ノイズが入っています。縮緬ノイズとも言われているやつです。
よくよく調べると、WBPPの振る舞いが少し変わったようで、そのままだとbiasが使われない設定になっていました。理由はdark frameにflat frameにもbiasが含まれてるので撮影したbias frameは使わなくてもいいということのようです。
私はこれが気に入らなくて、master flatを作る際にbiasを使うようにしました。これはイコールflatdarkを使わないということになります。これが問題だったようです。以前flat補正をする際に縞ノイズが乗っかるのはフラットが何かしらで汚くなる（その時は撮影時間が短くてノイズが載るという理由だった）というのを示したことがありますが、flat frameのダーク補正をしないと、残ったダークノイズが縞ノイズを作るということが今回改めて示されました。こたろうさんが以前この件について言及されていたと思います。
というわけで、biasの代わりにflatdarkを使うと次の写真のように縞ノイズは無くなりました。
RGBの合成前の画像
RGB合成前の画像を示しておきます。
まずはR。かなり鋭い星像となっています。縮緬ノイズも消えているのがわかります。
Greenは以下のようになりますが、Rに比べると明らかに暗い星が少なく、星像も甘いです。
Bはさらにその傾向が強く、星像もかなり大きくなっていて、明らかに星の数も少ないです。
このような傾向は普通のことなのでしょうか？それともピントがずれているのでしょうか？でもテストで画面を見ていた限り、ピントをどう合わせてもRがいつも鋭くてBは散々でした。
また、これらのズレは画像処理に影響がないのでしょうか？
Linear Pattern Subtraction
さて、上の画像をみると、横縞が結構多く残っているので、WBPPの新機能のLinear Pattern Subtractionを試しました。結果だけ言うと、あまりうまくいきませんでした。いくつかの横縞は目だたなくなるのですが、下のようによりハッキリした横縞となぜか縦縞が余分に加えられてしまうようです。
今回はまだあまり試していないですが、一旦ここではLinear Pattern Subtractionを使わないで、次に進みます。
RGB合成とBanding noise除去
これでやっとR,G,Bのスタックしたものが出来上がりました。ただ、これらをそのままChannelCombinationなのでRGB合成しても星の位置がずれてしまいます。そのため、StarAlignmentで改めてこの3枚を位置合わせしました。これでやっとカラー画像が出来上がりました。
でもR画像で見たときのように、やはり横の線が気になります。なので今回はRGB合成後、ScriptのUtilitiesからCanonBabdingReductionを使いました。これはかなりよかったです。いくつかパラメータを試しましたが、Active Previewはほとんど役に立ちませんでした。値を変えて何度か試した方が良さそうです。デフォルトの1でもほとんど大丈夫でした。0.2だとノイズが消しきれません。また、2だとノイズが加えられるような感じです。0.5と比べると1の場合は少し黒い部分が残っている感じがしました。結局最後0.7としました。要するに大きすぎても小さすぎてもダメなので、いくつか試すといいということです。結果は以下のようになります。
かなり良くなりました。
ここからはカラーでの画像処理
ここまで来れば、あとはこれまでのカラーの画像処理と同じです。
まずカラーバランスが滅茶苦茶なので、念のためDBEで少しカブリをとってからPCCでカラーバランスを整えます。PCCで恒星の色はそこそこまともになりました。ただ、鋭さがR>G>Bの順でかなり差があるので、鋭いRとボケたBの差で、赤が強いところは赤ハロが、青が広がってしまっているところは青ハロがあるようにも見えます。逆に言えば恒星の色がよく出ているようにも見えます。
その一方、PCCをかけてもどうしても背景が青く見えます。これはヒストグラムを見て理由がわかりました。背景のノイズが青が一番多いのです。おそらくRGBの感度に差があり、Rが一番感度がいいためノイズが少なく、次がG、Bは感度が低いためノイズが大きくなるのかなと推測していますが、実際のところはよくわかりません。もう少し検証が必要かと思います。
いずれにせよ今回はPhotoshopに持っていった際に、背景のRGBのヒストグラムを合わせる事でカラーバランスを整えることにします。
星像に苦労
あとは、ArcsineStretchなどでストレッチしてPhotoshopに渡すのですが、よく見ると星像がガタガタです。
特に短時間露光の場合に多いのですが、VISACの星像にはいつも苦労します。今回はなぜか4方向に尖って見えます。しかもスパイダーの方向ではなくて、なぜか45度傾いた方向です。MophologicalTransformationで少し整えますが、星マスクが必要です。
この星マスクも苦労しました。ストレッチ後、StarNetで恒星と背景を分離しようとしても、星の3割ほどしか分離できません。分離できない理由は、星像が汚い、中心のピークが出ていない、明るすぎる、暗すぎるなどです。きちんと丸になっていて、中心がサチり気味の方がうまく分離できるようです。そのため、今回は
- ストレッチ前のカラー画像をL画像にしてから
- いったんSTFでオートストレッチして
- HistgramTansformationで適用、
- その後ExpornentialTransformationでPIPのOrderを1.5にして適用、
- STFで真ん中の三角をを右に移動して暗くする
こうしてできた星マスクを適用して、MophologicalTransformationで十字型にDilationで伸ばし、X字型にErosionで縮めることで円に近づけていきます。これでやっとPhotoshopに引き渡しです。
Photoshopでの仕上げと結果
今回はPhotoshopではほとんどたいしたことはしていません。ノイズ処理もなしです。ノイズ処理をすると背景がボテボテになり、星像の鋭さと合わなくなってしまうからです。
- 撮影日: 2021年日7月17日1時16分-2時51分
- 撮影場所: 富山県富山市自宅
- 鏡筒: Vixen VC200L
- フィルター: Bardar RGBP
- 赤道儀: Celestron CGEM II
- カメラ: ZWO AIR294MM Pro -10℃
- ガイド: なし
- Light: SharpCap、Gain220、 露光時間: 10秒 x 461枚(R:163、G129、B169 x 19枚) = 1時間16分50秒
- Dark: Gain220、10秒 x 256枚
- Flat: Gain220、R:20ms x 128枚、G:50ms x 128枚、B:50ms x 128枚
- Flat Dark: 20ms x 128枚
- 画像処理: PixInsight、Photoshop CC
2年前のVISACとASI178MCで撮ったものと比べます。左が以前のもの、右が今回のものです。
今回は自己ベストかと思ったのですが、分解能だけ見たらもしかしたら以前の方がいいかもしれません。いやこれは画像処理のやりかたのせいで、見栄えをよくしようとした前の方が一見よく見えているだけかも。
もし以前の方がいいというなら、機材は今回の方が圧倒的に有利なので、これは完全にシンチレーション勝負になると思います。2年前の時はよほどシンチレーションがよかったのを覚えています。その他星の色、星雲の自然さ、背景の素直さなどは今回の方が格段に上でしょうか。
そういえば、この撮影の後になってVISACの光軸調整をしたのでした。その結果は反映されてないので、今一度シンチレーション のいい日を狙うとかでしょうか。
まとめ
初のRGBフィルターでの撮影と画像処理。いろんな新しいことがあってブログ記事が長くなってしまいまた。次回はもう少し早く処理できそうです。
分解能に関しては、やっぱり最後はシンチレーション なのでしょうか。リアルタイムで露光時間を1秒以下にして見てても、明らかに揺らいでいて、10秒ではこれくらいになってしまいます。次は揺れない日を狙うことになるのかと思います。
どうやらM57はAOOでもそこそこ色が出るみたいなので、次はナローのもしかしたら逆に長時間露光で、淡いところに挑戦するかもしれません。
おまけ
もう一つ、PixInsightの細かいテクです。projectファイルを保存して、ファイルのフォルダ名を変えたり、ファイルの場所を変えたりした時に、WBPPのインスタンスを右クリックして「Excecute in the global context」から再度開こうとすると、以下のようなエラーが出ることがあります。
この場合、WBPのインスタンスををダブルクリックして出てきたMD5 checksumを消してやって、再びインスタンスをPI内で保存。それを右クリックのExcecute in the global contextで開くと普通に開けるようになります。
