ほしぞloveログ

天体観測始めました。

タグ:PixInsight

前回の記事でBlurXTerminator (BXT)についてゴースト星雲の画像処理で適用した例を書きました。


最初L画像のみでBTXを試していたのですが、途中からL画像単体でBXTを適用することは止めて、最終的にはLRGB合成した後にBXTを適用しました。前回の記事では、RGB画像へのBXTの適用の過程をざっくり省いてしまいました。実際にはかなり検証していて記事もそこそこ書いたけど、長すぎるのでボツにしてしまいました。Twitter上でカラー画像への適用に興味を持たれた方がいたので、ボツ予定だった記事を一部改変して掲載しておきます。


カラー画像にBTXを適用するに至るまで

大きく分けて次の5段階のことを試しました。
  1. L画像のみBXT、 その後LRGB合成
  2. L画像にBXT、RGB合成した画像にBXT、その後LRGB合成
  3. L画像にBXT、星像の大きいRのみにBXTをかけてGB画像はそのままでRGB合成、その後LRGB合成
  4. L画像にBXT、R、G、Bそれぞれの画像にBXTしてRGB合成、その後LRGB合成
  5. RGB合成、その後LRGB合成 、できた画像にBXT
とりあえず最初に各テストの結果を書くと
  1. 一見問題ないが、よく見ると恒星に色ずれが起きる。原因は恒星の大きさがL画像とRGB画像で違いすぎること。
  2. RGBにBXTをかけた段階では問題がないが、LRGB合成をする際に恒星中心がサチることがある。
  3. 恒星にハロが出て、その影響でSPCCをかけると背景の色が変わる。
  4. 問題なし。
  5. 問題なし。
4と5は手法としては問題はなさそうです。ただしこれにNoiseXTerminator (NTX)が絡むと、3と4で差が出ます。あとの方で詳しく書きます。 


1.

最初は
  1. L画像のみBXT、 その後LRGB合成
した場合です。この方法、一見問題なく見えます。この手法で許容してしまってもいいという人も多いかもしれません。ですが、よく見ると恒星に色ずれが起きる可能性があります。

LRGB合成した後に恒星周りに色ズレのような現象が確認できました。たとえば下の画像の恒星は左下をよく見えるとマジェンタが強くなってしまっています。画像処理を進めていくとこれが目立ってくることに気づきました。

Image55_SPCC_LRGB_zure_cut

いろいろ原因を探っていくと、どうやらBlurXTerminatorをかけたL画像と、BlurXTerminatorをかけていないRGB画像の恒星の大きさと差がありすぎているからのようです。BXTでL画像の恒星の大きさは小さくなるのですが、RGBの恒星の大きさは大きいままです。L画像のエッジを効かせるべき範囲と効かせない範囲が、RGB画像では大きく色情報が違ってしまっているのが原因かと思われます。次の2からの作業をしてこの色ズレが消えたので、おそらくは正しいと思いますが、確証はというとまだいまいちありません。


2.

上記の恒星色ずれ問題があったので、次にRGB合成した画像にL画像と同じパラメータでBXTをかけてみました。RGB画像にBXTを適用すると恒星の色がズレる可能性があるという報告も見ましたが、私が試している限りこの時点での恒星の色は保たれているようでした。RGB画像の段階ではいいのですが、このBXTを適用したRGB画像に、BXTを適用したL画像でLRGB合成すると、恒星中心部が激しく色飛びすることがあるようで、あまりよろしくありません。

Image06_RGB_crop_ABE_ABE_ABE_SPCC_BXT_Preview02_saturation

数回多少パラメータなどを変えて試しましたが、多少の変化はあれどいずれも上記画像のような色飛びがでます。再現性もあるようなのですが、一部の原因は撮影時に恒星中心がサチっていたか、サチりかけていたことがあるのかと思います。

RGB合成だと目立たずに、LRGB合成で顕著に出てくるのが少し不思議ですが、とにかくLRGB合成が鬼門です。BTXを使わなければ、同じ画像でもLRGB合成でこんな過激なサチりはでてきません。この時点で思ったのは、どうもBXTとLRGBは相性問題があるような感触です。BXTのdeconvolutionで星を尖らせているようなものだと考えると、LとRGB尖らせたものどうしで合成する際に問題が出るのは理解できる気もします。


3. と4.

次の策として、R、G、Bの元画像それぞれにBlurXTerminatorをかければと思いつきました。その際、恒星が大きく見えるRのみにかけるか、R、G、B全てにかけるか迷ったので検証してみました。

SPCCをかける前は一見RのみにBlurXTerminatorをかけた方が赤ハロが少なく見えていいと思ったのですが、SPCCをかけるとこの判断は逆転しました。結果だけ見せます。

まずはRだけBlurXTerminatorをかけRGB合成し、SPCCをしたものです。SPCC前の結果とは逆に恒星周りにわずかに青ハロが出てしまって、さらに背景が赤によってしまっています。
Image54_Preview01

次にR、G、BにそれぞれBlurXTerminatorをかけRGB合成し、SPCCをしたもの。ハロもなく、背景もまともな色です。
Image55_BXT4RGB_Preview01

ここまではRGB合成のみのテストですが、この後にL画像も同様のパラメータでBlurXTerminatorをかけ、上の2枚のRGBと合成してみました。この時点で1.で示した恒星の色ズレは見事に消えましたが、やはりRだけBlurXTerminatorをかけた場合は青ハロが残り、RGBそれぞれにBlurXTerminatorをかけた場合は色バランスもきちんと残されたままでした。なので、RだけBXTをかけるとかはやめた方が良さそうです。

なんでこんなまどろっこしいことをあえて書いたかというと、BXTはRGBバランスよくかけた方がいいことがわかりますが、その一方でBlurXTerminatorは恒星の各色の大きさ調整に使えるのではないかということです。鏡筒によってはRGBで収差が違う場合もあり、それがハロなどにつながることがあります。それらの色合わせに役立つ可能性があるということです。ただし上で示したように、SPCCなどで構成の色合わせをしてからでないと判断を間違える可能性があるので、きちんと色バランスをとった上で判断した方がいいということに注意です。

上の結果はさらに、恒星の色バランスが悪いと、SPCCが背景の色バランスに影響を与える可能性があるということを示唆しています。PCCもSPCCもそうですが、基本は「恒星の色」を基に「恒星の色」を合わせるだけの機能で、背景の色を直接検証しているわけではないということです。例えば色収差のある鏡筒では恒星のRGBバランスがズレてそれを元にSPCCを使うと背景の色も狂う可能性があるなど、SPCCもまだ完璧とは言い難いことを意識しておいた方がいいのかと思います。

というわけで、ここまでで4の

L画像にBXT、R、G、Bそれぞれの画像にBXTしてRGB合成、その後LRGB合成

という手法でほぼ問題ないことがわかりました。


5

ここまでで、L、R、G、B画像にそれぞれBXTをかけてLRGB合成するのでほぼ問題がないと言ってきました。念の為、LRGB合成してから、その画像にBXTをかけてみます。この段階では4と5にほとんど差が見られませんでしたが、もう少し見やすくするためにNXTをかけてみました。ここで差がはっきりと出ました。

L、R、G、B画像にそれぞれBXT、後にNXT:
Image37_Preview01


LRGB合成してから、その画像にBXT、後にNXT:
Image65_ABE_ABE_ABE_Preview01


後者の方が明らかにノイズが少ないです。(追記: すみません、ブログ記事にアップ後に改めて見たのですが、ブログ上だとほとんど差が分かりません。一応ローカルでは見分けがつくくらいの差はあるのですが...。あまり気にするレベルではないのかもしれません。)

ではなんでこんなことを試したかというと、R画像はまだしも、G画像やB画像にはゴーストの形はほとんど写ってなくて、それらにBXTをかけた結果を見ていてもシャープさが増すというより、単にノイズが増えたように見えてしまったからです。それならばRGBでバランスよくBXTをかけた方が得なのではと思ったのが理由です。


注意と結論(らしきもの)

あと一つ、今のところ私はBXTをリニア画像にしか適用していません。例えばマニュアルにはBXT内でFWHMを評価するとありましたが、ストレッチなどしてしまうとFWHMも正しく評価できなくなってしまうので、リニアで適用するのが原則かなと思います。ただ、例えばFWHMも絶対評価でなく各色の相対評価とかでもいいと思うと、必ずしもリニア画像でなくてもいいのではとも思います。ここら辺はもう少し検証が必要でしょう。

結論としては、いい方から5>4>1>>3>>2の順で、特に3の方法はもしかしたら色々応用できるかもと思っています。

というので、私的には今のところ普通にLRGB合成をして、その画像にBXTをかけるのが一番いいという結論です。もちろん、これはあくまで今回個人的に出した結論というだけで、まだまだ他に試すべきやり方はあるでしょうし、画像や環境によってはこの結論が根本的に変わる可能性もまだあるかと思いあます。


おまけ1: BXTとNXTどちらが先?

最後におまけで、BXTとNXTどちらを先にかけたらいいかの結果を載せておきます。BXTをかける時にもしもう少しノイズが少なかったらとかいう誘惑に取り憑かれたときのためです。5のLRGB合成してから、その画像にNXT、後にBXTをかけています。

Image65_LRGB_crop_ABE_ABE_ABE_SPCC_clone_Preview01

もう全然ダメですね。これは原理を考えればすぐにわかるのですが、ノイズ処理をしてしまった段階で、deconvolutionをする前提が崩れてしまっているからだと思われます。


おまけ2: L、R、G、BそれぞれにBXT、NXTをそれぞれかけてからLRGB合成

もう一つおまけで、Twitterでt a k a h i r oさんからのリクエストです。L、R、G、BそれぞれにBXT、NXTをそれぞれかけてからLRGB合成したらどうなるかです。4.のmodバージョンですね。

結果だけ示します。
Image12_BXT_NXT_LRGB_SPCC_CT_CT_cut


私の予測は4の結果とほとんど変わらないだったのですが、これだけ見ると全然ダメですね。というか、なんでここまでダメなのかむしろ理由がわからなくらいです。何か間違ってないか見直しましたが、NXTの順序を入れ替えただけで、特におかしなところはなかったです。

改めて見てみると、やはりGとBの星雲本体が淡すぎることが問題の気がしてきました。淡すぎるとNXTがノイズを無くしているだけで、特に星雲を炙り出すようなことは全然できてないのです。BTXもNXTもやはり何かはっきりした対象があって、初めて効果的に働くような気がしています。もしくは、今回どのテストも同じパラメータでやって、そのパラメータはというとゴースト本体が一番よく出るようにというので選んでいるので、他のパラメータを考えてみればまた結果は変わってくるのかもしれません。


まとめ

限られた環境ですが、ある程度の結論として「BlurXTerminatorはカラー画像に適用できる」ということは言ってしまってもいいのかと思います。むしろL画像のみに適用する場合はLRGB合成をかなり注意深く実行する必要がありそうです。

いずれにせよ、このBXTはすごいソフトです。もう少し色々触ってみたいと思っています。またまとまったら記事にするかもしれません。


前回記事のゴースト星雲の処理の続きです。




前回はSPCCまでで、モノクロ撮影でBaaderフィルターを選んだらうまく補正ができたという話でした。今回は主にBlurXTerminatorについて試してみて、ゴースト星雲を仕上げています。


BlurXTerminator 

今回はBlurXTerminator (以下BXT)と呼ばれるdeconvolutionソフトを処理してみます。このソフトはRussell Croman氏が独自に書いているもので、氏が書いているいくつかのソフトの最新のものです。特に2021年から機械学習を取り入れたXTerminatorシリーズはノイズ除去のためのNoiseXTerminator (NXT)、スターレス画像を作るStarXTerminator (SXT)といずれも大きな話題となっています。

ノイズ除去ソフトは他にも実用レベルのものがいくつもあるのと、スターレス画像についてはStarNet V2が無料でかなり性能がいいので、私はこれまで氏のソフトは使ってきませんでした。それでも今回のBXTは分解能が信じられないほどに向上するようです。

私自身がdeconvolutionが苦手で、これまでも実際に作例にまで適用したのは数例。大抵は試してもあまり効果がなかったり、リンギングが出たりで、よほどうまくいった場合でないと適用してきませんでした。deconvolutionはどうしても時間を費やしてしまうので、画像処理の中でも大きな鬼門の一つでした。

BXTは、マニュアルとかに書いてあるわけではないようなのですが、基本的にはリニア画像のL画像のみに使うべきだという噂です。とりあえずまずはスタック直後のL画像で検証してみます。パラメータは基本的に2つだけで、
  1. 星像をどこまで小さくするかと、
  2. 分解能をどこまで出すか
だけです。

星像の補正

パラメータは上記の2つだけですが、BXTで「Correct」と呼ばれている、あまり注目されていな星像補正の効果があります。これだけでもかなりすごいので、まずはそこに注目してみたいと思います。

この機能はBXTを走らせるとデフォルトで適用される機能です。ですがこの機能の凄さを確かめるために「Correct Only」オプションをオンにして、この機能だけを試してみます。星像を小さくしたりとか、星雲の分解能を上げるといいった効果を適用「しない」、ある意味BXTのベースとなるような機能です。

マニュアルを読むと以下のものを補正できるそうです。
  • limited amounts of motion blur (guiding errors)
  • astigmatism
  • primary and secondary coma
  • unequal FWHM in color channels
  • slight chromatic aberration
  • asymmetric star halos.
とあります。日本語に意訳すると、
  • ある程度のブレ(ガイドエラー)
  • 非点収差
  • 1、2次のコマ収差
  • 各色のFWHM (星像の大きさ) の違い
  • 多少の色収差
  • 非対称なハロ
となります。どうやらものすごい威力のようです。マニュアルにはさらに「画像位置によってそれぞれローカルなPSFを適用する」ということで、たとえば四隅ごとに星像の流れが違っていてもそれぞれの流れに応じて補正してくれるようです。こんなソフトは私の知る限りこれまでなかったはずで、もし本当ならすごいことです。

試しにスタック後のL画像でオリジナルの画像とCorrect onlyだけで試した結果を比較して、四隅をGIFアニメにしてみました。
masterLight_BIN_2_4144x2822_EXPOSURE_300_00s_FILTER_L

自分的には四隅とも十分真円に見えていたので、全然問題ないと思っていました。でもBXTは躊躇することなくおかしいと認識しているようで、正しく直してくれているようです。左下は星像の大きさが少し小さくなるくらいでままだましですが、左上の画像は少し下方向に、右上の画像は大きく左下方向に、右下の画像は大きく左方向にずれていたことがわかります。本当に正しく直しているかどうかは今の段階では不明ですが、少なくとも見た目は正しい方向に直しくれているようです。効果が分かりにくいという方は、できるだけ画面を拡大して見てみてください。

この結果はすごいです。実際の撮影が完璧にできることはほとんど無理で、何らかの不具合がある方がごくごく普通です。これらのことが画像処理で補正できるなら、安価な機材が高価な機材に迫ることができるかもしれませんし、なにより撮影時のミスなどで無駄にしたと思われる時間を救い出せるかもしれません。はっきり言って、この機能だけでも購入する価値があると思います。

また、BXTはL画像のみに適用した方がいいとも言われていますが、マニュアルによると各色の星像の大きさの違いも補正できるということなので、BXTをカラー画像に適用することも可能かと思われます。


恒星の縮小

上記補正はBXTでデフォルトで適用される機能。さらにすごい機能が続きます。BXTの適用例を見ていると、普通は星雲部の構造を出すのに期待すると思うのですが、私はdeconvolutionの原理といってもいい星像を小さくする効果にとんでもなく驚かされました。まずは背景の効果をオフにして、星像改善のみSharpen Starsが0.25、Adust Star Halosが-0.25として、適用してみます。

Original:
orignal

BXT (恒星の縮小のみ):
staronly

まだ小さくすることもでき不自然になることもほとんどないですが、とりあえず今回はほどほどにしておきます。特に左下の明るい星に注目してもらえるとよくわかるかと思いますが、近づいていていあまり分離できていない2つの星がはっきりと分離されます。パラメータによってはハロの処理が少し不自然に見えたりもしますが、自分で頑張ってやった場合より遥かにましなハロになっているので、全然許容範囲です。

これもすごい効果ですね。星像を小さくするのはいつも相当苦労するのですが、リンギングなどもほとんど出ることがなく、このソフトが決定版の気がしています。ぜひともM57の分解能ベンチマークに使ってみたいです。


背景の分解能出し

やっとBXTの一番の目玉の背景の構造を出す機能です。今回はゴースト星雲のバンザイしている手のところなどを見ながらパラメータを攻めていきました。結局のところ、構造を出すSharpen Nonstellerはかなり大きな値にしないとほとんど効果は見えなかったのでデフォルトの0.9のまま、それよりもPSFをマニュアルで設定することで効果が大きく変わることがわかりました。興味があるところをpreviewで表示して効果を見ながら値を決めればいいと思いますが、今回は最終的にPSF Diameterを0.75、Sharpen Nonstellerを0.90にしました。

結果としては以下のような違いとなりました。

Original:
orignal

BTX(恒星の縮小と背景の分解能出し):
BXT_all

あまり効果があるように見えていませんが、これ以上分解能を出すと、ゴースト君が崩れてきてしまいました。かなり拡大して見ているのですが、ここまで拡大してみることをしないなら、もっと大きな構造を見ながら細部を調整するという手もあるかと思います。


その後の画像処理

でもですね、結局L画像にBXTを適用するのは止めました。じゃあどうしたかというと、スタック後RGB合成した後、そのままL画像とLRGB合成をして、その後にSPCC、CTで色出し、その後にやっとBXTを適用しました。

理由は、L画像のみに適用するよりもLRGB画像に適用する方が、特に細部出しのところでノイズに負けずにゴースト部分が出たというのが大きいです。

カラー画像に適用した場合でも、懸念していた恒星の色ズレもなかったです。今回は色々やって最後この順序になりましたが、この順序が正しいかどうかもまだよく分かっていません。BXTはパラメータこそ少ないですが、他のプロセスとの組み合わせで、順序なども考えたら無限の組み合わせがあり、ものすごく奥の深いソフトなのかと思います。

その際、BXTのついでに、NoiseXTerminator(NXT)も使ってみました。もちろんノイズ除去の効果があったのはいうまでもないのですが、その結果大きく変わったことがありました。PixInsightの使用する割合が多くなり、これまでストレッチ後のほとんどの処理を担っていたPhotoshopの割合が相当減って、処理の大方針が大きく変わったのです。具体的にはdeconvolutionが楽になったこと、そのため恒星の処理が楽になったこと、ノイズ処理もPixInsightでNXTで動くことが大きいです。不確定要素を少なくするという意味でも、PIの処理を増やすのは多分真っ当な方向で、以前から考えていてできる限りの処理をPIのみで済ませたいという思いがやっと実現できつつある気がします。

あともう一つ、PIのWBPPでいつものようにLocal Normarizationをオンにしおいたのですが、どうやらこれが悪さをしていたようでした。RGBでそれぞれの背景の大構造でズレが起きてしまったようで、背景に大きな色むらができてしまいました。ABEのせいかとも思い色々探っていって、やっと最後にLNが原因だと突き止めるに至りました。明るい光害地で、かなり無理して淡いところを出していて、スカイノイズの影響は大きいはずです。もしかしたらそこら辺も関連しているのかもしれません。暗いところに行くか、さらに撮影時間を伸ばす必要がありそうです。ここら辺が今後の課題でしょうか。


仕上げ

今回Photoshopでやったことは、最後の好みの色付けくらいです。恒星も背景もPIできちんと出してからPhotoshopに渡したので、かなり楽でした。

「sh2-136ゴースト星雲」

Image13_ABE_ABE_ABE_cut
  • 撮影日: 2022年10月25日20時2分-26日0時27分、10月26日19時17分-21日0時0分
  • 撮影場所: 富山県富山市自宅
  • 鏡筒: SHARP STAR製 SCA260(f1300mm)
  • フィルター: Baader RGB
  • 赤道儀: Celestron CGX-L
  • カメラ: ZWO ASI294MM Pro (初日分は-10℃、2日目は+9℃から11℃)
  • ガイド:  f120mmガイド鏡 + ASI290MM、PHD2によるマルチスターガイドでディザリング
  • 撮影: NINA、Gain 120、露光時間5分、L: 54枚、R: 18枚、G: 15枚、B: 12枚の計99枚で総露光時間9時間55分
  • Dark: Gain 120、露光時間5分、温度-10℃、32枚
  • Flat, Darkflat: Gain120、露光時間 L: 0.001秒、128枚、RGB: 0.01秒、128枚
  • 画像処理: PixInsight、Photoshop CC


おまけ

恒例のAnnotatonです。
Image13_ABE_ABE_ABE_cut_Annotated

あと、前以前飛騨コスモス天文台でTSA120で撮影したゴースト星雲と比較してみます。

まずは以前のもの:
TSA120

今回の画像を同じ画角で比べると、
Image13_ABE_ABE_ABE_cut_comp
自宅といえど、さすが大口径で露光時間も長いだけあります。分解能、恒星、ノイズ、いずれも大きく進歩しています。バンザイしているところもきれいに出ていますね。


まとめ

画像処理をサボっている間に、SPCCやBXTとかなり状況が進んでいました。新しいツールも躊躇せずに、どんどん取り込んでいければと思います。BXTも迷走したりしていますが、使い方によって明らかに良くなったりするので、最適な方法を探っていくほかないと思います。


今回はケフェウス座のSh2-136: ゴースト星雲です。撮影したのはもう結構前で、10月終わり頃になります。

前後関係で言うと、自宅でSCA260で撮影したアイリス星雲とセットで撮影したもので、その意味ではもっと早く処理していても良かったものです。


現実的には撮影後に、小海の星フェスや皆既月食など、他にも色々忙しくてなかなか取り掛かることができなかったという理由もあります。最近のBlurXTerminatorが結構凄そうなので、少し試してみたくなり、時間の取れる年末年始に画像処理を進めてみました。


R画像?

撮影は10月25日の夜と、26日の夜の二日に渡っています。アイリス星雲を撮影していたセットアップのままなので、特に何か変更するでもなかったです。

画像処理を進めていくと、なぜかR画像のみ右上に変なスジが残りました。
masterLight_BIN-2_4144x2822_EXPOSURE-300.00s_FILTER-R_mono

最初は単にアンプグローの残りかと思ったのですが、そうだとすると2つ奇妙なことがあります。一つはGとBにこんなスジは全く出ていないこと、もう一つはダークフレームで見たアンプグローとスジの方向がずれていることです。R画像のスジは全部下向きですが、ダークフレームの筋は放射状に広がっていて、上剥き成分もあります。重ねて比べてみると、上向き成分のあるエリアでもR画像では下向き成分になってしまっているので、アンプグロー起因でない可能性が高い気がします。多数スタックで画角がずれてスジもずれたことも考えましたが、明らかに画角ずれ以上にスジがずれています。

こうなるとRフィルターが何か悪さをしているのかと思ったのですが、この前に撮影しているアイリス星雲のR画像にも、この後の同じ日に撮影している燃える木のR画像にも、そんなへんなスジは見当たりません。そうすると本当に存在するスジかとも思ってしまいますが、他の方の、かなり炙り出してある画像を見てもそれらしいものは見当たりません。釈然としませんが、今回は画像処理で誤魔化すことにしました。


USBケーブル

もう一つトラブルを思い出しました。ゴースト星雲と燃える木の撮影ターゲット切り替えの時に一つやらかしたことです。USBケーブルが引っかかってしまいました。

6B15B0B8-118F-499E-89DD-2B5595D700F1
子午線反転のところは必ずその場にいるようにしているのですが、ターゲット切り替えは部屋の中からリモートでやっています。中途半端に垂れ下がっているケーブルが赤道儀の出っ張りに引っかかったようです。ターゲット移動のときにカメラの映像を見ていたのですが、突然変な感じで映像が止まり、接続が切れたみたいだったのでもしやと思って外に出たら、案の定でした。幸いケーブルの方が破損しただけで、肝心なカメラの端子は無事で、USBケーブルを交換して接続し直したらきちんと認識され、撮影も可能でした。ケーブルの方を弱く作ってくれているのかと思いますが、こういったところはありがたいです。

反省点としては、
  • ケーブルの設置はきちんと弛まずに、かつ回転を妨げないようにすること
  • ターゲット移動の時もきちんと現場にいること
などしょうか。


SPCCの意義

新たにPixInsightで実装されたSPCC(SpectrophotometricColorCalibration )は、かなりすごいですね!懸案だったフィルター補正の機能をうまく実装したと思います。かなり原理的に正しい色に近づく可能性が高くなったと思います。

「PCCは科学的に正しいことをしているので、出来上がった色はおかしいはずがない」とかいう意見もちらほら聞きましたが、実際には全然そんなことはなかったということです。以前からPCCでは基準となるカメラと、個人が撮影するカメラの波長に対する応答が違うので、その分の色ズレが原理的に起きてしまうという主張をしていましたが、その機能が見事に実装されています。


個々のカメラの応答をデータとして持ち、参照カメラとの差を補正しない限り、正しい色にならないということです。今回のSPCCでは、実際に個々のフィルターやセンサー特性をデータベース化して持とうとしているため、原理的にも正しい方向に大きく進んだわけです。

さて、どれくらいの機能が実装されたのか、SPCCを使って実際に色合わせをしてみました。SPCCのインストール方法や、巨大なガイアのデータを落として使えるようになるまでは、マニュアルを見ればすぐにわかりますし、日本語の解説ページもいくつかありますのでそちらに任せるとして、使ってみてのポイントだけ少し書いておきたいと思います。

まず、プレートソルブがScriptのImageAnalysisにImageSolverに集約されたことです。これまではPCCは専用のプレートソルブ機能を持っていたのでですが、SPCCはもちろん、PCCもあらかじめ別途ImageSolverを走らせておかなければ、使うことができないようになってしまっています。このことを知らなければ、これまでのユーザはとまどうかもしれませんが、これは正常進化の一環で、一度わかってしまえばこれ以降特に問題にはなることはないはずです。

一番戸惑うところは、フィルターの選択でしょう。デフォルトはソニーセンサーのUV/IRカットフィルターになっています。今回の撮影ではASI294MM Proを使っているので、最初はここら辺から選ぶのだろう考えました。UV/IRフィルターは使っていないので、フィルターなしのソニーセンサーのRGBで試しました。フィッティンググラフは以下のようになります。
SPCC_Sony_RGB
ですが、これを見ると、明らかにフィッティング直線にかなりの星が載っていないことがわかります。

フィルターの選択肢をよく見ているとBaaderというのがありました。よく考えたら今回使っているカメラはモノクロで、応答の違いは主にRGBフィルターで起きていると思うと、使っているフィルターに応じて選ぶ方が良さそうです。実際に今回使ったはBaaderのRGBフィルターだったので、RGBそれぞれにBaaderを選んでみることにしました。すると以下のように、ほぼ全ての恒星がフィッティング直線に載るようになり、少なくともこちらのBaaderを選んだ方が正しそうなことがわかります。
SPCC_Baader
でもこれ、よく考えるとモノクロセンサーの特性は考慮していないんですよね。量子効率はソニーセンサーの選択肢がないので、理想的な場合を選びました。この場合量子効率は全波長で100%とのことなので、やはりセンサーの応答は実際には考慮されていません。

一眼レフカメラは、ある程度専用フィルターファイルが用意されているようです。でもCMOSカメラに関しては、一部のソニーセンサーの型番は専用フィルターを用意されているようですが、基本的には代表的な設定で代用しているので、まだまだ今後発展していくものと思われます。もしくはフィルターファイルは自分で用意できるようなので、実際に使っている環境に応じて自分でフィルターを書くことがいまの段階では正しい使い方と言えるでしょう。

重要なことは、考え方自体は真っ当な方向に進んでいて素晴らしいのですが、まだSPCCは今の段階では色合わせについては完璧はないということです。今後少なくともフィルターファイルが充実して、例えば複数選択できるなど、柔軟に対応することなどは必須でしょう。その上で多くのユーザーレベルで実際の色合わせの検証が進むことが重要かと思います。今後の発展にものすごく期待しています。

さて、PCCとも比較してみましょう。PCCでのフィッティングのグラフを示します。
PCC
SPCCに比べて一見ばらけていて誤差が多いように見えますが、縦軸、横軸のスケールに注意です。SPCCはかなり広い範囲をみているので、直線に載っているように見えるだけで、スケールを合わせるとばらつき具合はほとんど変わりません。実際に色合わせした画像を比べても、少なくとも私の目では大きな違いは見えません。

SPCC:
Image05_crop_ABE_ABE_SPCC_HT

PCC:
Image05_crop_ABE_ABE_PCC_HT

PCCは各恒星の点が2つのグループに分かれたりとフィッティング直線に乗らないケースもよくあります。そんな時はどうしようもなかったのですが、SPCCではそれらを解決する手段が手に入ることになります。SPCCは手持ちセンサーのデータを持つことで、色を正しい方向へ持っていこうとしています。科学的に正しい方向に進むのはいい方向で、少なくともそういった方向が選択肢として選べることは素晴らしいことだと考えています。

SPCCだけでもうかなり長くなってしまいました。続きもまだまだ長くなりそうなので、今回の記事はここまでにします。次は主にBlurXTerminatorについてですが、こちらもなかなか面白いです。

昨日のM8干潟星雲とM20三裂星雲の画像処理の最中に、おかしなことが起きました。結構一般的な話なので、ここでまとめておきます。

下は、SV405CCで撮影した3分露光、34枚をPixInsightのWBPPでインテグレーションした直後の画像をオートストレッチしたものですが、見て分りますように階調が全く無くなってしまうということがありました。

masterLight_BIN-1_4144x2820_EXPOSURE-180.00s_FILTER-NoFilter_RGB

何が問題だったかと言うと、Pedestalの設定をするのを忘れてしまっていたからです。WBPPのCalibrationタブでLightsを選択した時に、右隣のパネルの2段目に出てくる「Output Pedestal Settings」のところで設定できます。
pedestal
私は普段毎回ここを「Automatic」にしています。ただこの設定、WBPPのパネルを開けるたびに度々リセットされてAutomaticでなくなることがあります。今回は「Literal Value」に勝手になってしまっていました。改めて「Automatic」に設定して、WBPPの処理をし直すと下のようにきちんと淡い部分の階調が戻ってきました。

masterLight_BIN-1_4144x2820_EXPOSURE-180.00s_FILTER-NoFilter_RGB

多分これはSV405CCに限ることではなく、オフセットが小さくてダーク補正などで0以下のピクセルが多数出たときに一般的起きる現象です。特に今回はSV405CCのオフセット量が最大255のうち、40という低い値で撮影したことも原因の一つなのかと思います。

このような場合に、画像処理時に上記のようにPedestal設定で回避できるので、もし同様の階調がなぜか出ない現象で困っている方がいたら、是非試してみてください。


  1. SV405CCの評価(その1): センサー編 
  2. SV405CCの評価(その2): 撮影編 
  3. SV405CCの評価(その3): 画像比較
  4. SV405CCの評価(その4): 新ドライバーでの画像比較
  5. SV405CCの評価(その5): 青ズレの調査と作例
  6. 番外編1: 階調が出ない時のPedestalの効果
  7. 番外編2: ASI294MC Proでの結露

今回の記事は、2022年5月28日の飛騨コスモス天文台の観望会の後に撮影したIC1396の画像処理です。




IC1396を選んだ理由

ゴールデンウィークにASI2400MC Proで青い馬星雲を撮影しましたが、5月中は借りていて良いということになり、もうワンショット何か撮影できればと思っていました。



せっかくのフルサイズのカラーカメラなので、飛騨コスモス天文台の利点を生かした北の暗い空で、フィルターなしでどこまで出るのかを、できるだけ広角で大きな天体で試してみたいというのが第一です。いろいろ考えて、IC1396:象の鼻星雲(Elephant's Trunk Nebula)をターゲットとしました。ケフェウス座にあるかなり大きな星雲で、北アメリカ星雲より大きいくらいです。

実はこの前後に、象の鼻の部分をSCA260で拡大して撮影しています。こちらはナローバンドフィルターを使って撮影しているので、比較が楽しそうという理由もあります。

機材はFS-60CBとCGEM IIで、青い馬星雲を撮った時と同じです。カメラもASI2400MC Proなので同じものですが、露光時間とゲインも同じにしました。設定も含めて全く同じにしたのはダークやフラット、フラットダークフレームを使い回しするためです。NINAだとまた撮影時にカメラを認識でトラブりそうなので、今回は最初からSharpCapを使っての撮影です。それでも認識させるまでに何度か接続し直しをしました。青い馬星雲の撮影時と同じように、ディザーをしていないので縞ノイズがでる可能性があります。青い馬ではとりあえず出ていないようだったので大丈夫かともいますが、おそらく今回の方が淡いので少し心配です。

あと、青い馬星雲を撮影した時はバックフォーカスを合わせる手段がなくて、現地でFC76用のマルチフラットナーのリングを使って適当にマルチフラットナーからセンサーまでの距離合わせましたが、今回はZWO製のフルサイズクラスのCanon EFマウント用のアダプターを使い、さらに足りないフィルターホイール分の11mmを別途M54のアダプターを使い、1mm単位でバックフォーカスを合わせることができました。比較すると、青い馬星雲のときの四隅を見ると相当ずれていたのがわかります。

masterLight_ABE_PCC_ASx4_SCNR_bg2_mosaic

今回の四隅は下のようにかなりマシになりました。でもよく見ると、左より右側が流れています。カメラのスケアリング調整が必要なのでしょうか?アダプターをいくつも使っているので、微妙にずれた可能性もあります。

masterLight_ABE_mosaic


撮影は3分露光で全部で45枚、合計2時間15分の撮影時間なので、大して長くはないです。撮影はかなり安定していて、45枚全てを画像処理に回すことができました。気になるのは人工衛星で、45枚中11枚に軌跡が入り込んでいます。ひどいのは3分で3つの線が入っています。そんなのが2枚ありました。

Capture_00033 02_36_58

撮影はもう先々週のことになるのですが、これが一番新しい素材で、他に4月から未処理の画像が大量に溜まっています。それでもカメラを返す必要があるので、こちらを先に処理することにしました。


画像処理

PixInsightが5月18日にアップデートされて1.8.9-1となりました。StarNet V2だけは相変わらず手動インストールが必要でした。

新しいこととしては、WBPPで途中経過を示すスクリーンが出るようになりました。これを見ていると、Local Normarizationに一番時間をかけていることがわかります。馬頭星雲の画像処理の時にLocal Normarizationの有り無しでかなり差が出たので、時間はかかっても今後もオンのままで行こうと思います。

IMG_5688

スタック直後の画像をオートストレッチしたものがこちら。結構淡いですが、まあなんとかなるでしょう。

masterLight_BIN-1_6072x4042_EXPOSURE-180.00s_FILTER-NoFilter_RGB

あと、フラットフレームが室内での壁撮影だったこともあり、1次の傾きがあるかもしれなないため、ABEの1次で補正しました。実際上の画像は右側が暗いです。Deconvolutionは試しましたが、ほとんど効果がなさそうで適用せず。その後ストレッチして、少し星がうるさかったのでEZ StarReductionのみかけました。後はPhotoshopに渡して仕上げです。


結果

「IC1396: ケフェウス座散光星雲」
masterLight_integration_ABE_PCC_ASx5_HT_starreduction_SCNR3a_tw
  • 撮影日: 2022年5月29日0時57分-3時13分
  • 撮影場所: 岐阜県飛騨市
  • 鏡筒: TAKAHASHI FS-60CB+マルチフラットナー(f370mm)
  • フィルター: なし
  • 赤道儀: Celestron CGEM II
  • カメラ: ZWO ASI2400MC Pro (-10℃)
  • ガイド:  f50mmガイド鏡 + ASI290MM、PHD2によるマルチスターガイド
  • 撮影: SharpCap、Gain 150、露光時間3分x45枚で総露光時間2時間15分
  • Dark: Gain 150、露光時間3分、64枚
  • Flat, Darkflat: Gain 150、露光時間 0.1秒、64枚
  • 画像処理: PixInsight、Photoshop CC
オレンジ色のガーネットスターが綺麗です。わずか2時間ちょっとの露光としてはかなり淡いところまで出たのかと思います。自宅富山では得られないような暗い北の空なのでそもそも有利なのですが、カメラの性能のおかげというのもかなりあるのかと思います。画像処理に関しては以前同じカメラで撮った三つ子銀河青い馬星雲と同じような感想で、とても素直で、露光時間が短いにも関わらず手間がかかりません。やっぱり素直にASI2400MC Proはかなりいいカメラだと思います。

今回、周りの淡い部分を出すために全体を明るくしているため、右側から伸びる象の鼻のところをうまく出すことができませんでした。ここは結構明るい部分なので、そこにある暗黒体は潰れてしまいがちで、もっと輝度を落とすと出てくるのですが、それだと全体が暗くなってしまいます。この部分はSCA260で撮影したナローでリベンジかと思います。

あと、どうしてもSolverがうまくいかなかったため、今回Annotationは無しです。ストレッチ前の画像ではきちんとできるので、ストレッチの過程で星がうまく検出できない何かが起きているようです。それでも最高で98%まで検出できていると出てくるので、後少し何かが違うだけだと思うのですが...。別画像でSolverをかけてその情報を他の画像に移す用法もある気がするのですが、ちょっとわかってません。


まとめ

それにしてもカラーカメラは楽でいいですね。分解能を求めるような系外銀河とかでなければ、もうカラーで十分な気がします。特に短焦点の広角はそこまで分解能必要ないですし、フルサイズの方がより大きなエリアを見ることができるので、このカメラはベストに近い選択の気がします。もう一つ上にASI6200MC Proがありますが、逆にこちらはピクセルサイズが小さくなり画像サイズが大きくなるので、感度的には2400の方がいいのと、画像サイズ的に使い勝手がいいのかもしれません。でも6200の16bitは少し気になるし、モノクロと合わせてLとRGBの2つで撮るとかの応用も効くので、こういった活用なら6200はかなり魅力です。

とまあ、お借りしたカメラをもとに感想を言っているだけなので気楽なものですが、今回も含めてこれだけ出るのなら、値段さえ許すなら本当に今の6Dを置き換えたいです。でも中古の6Dが4-5台分、どうしても考えてしまいます。

今回を含めて、このASI2400MC Proで「三つ子銀河」「青い馬星雲」「IC1396」と3つの作品を仕上げました。これだけの高性能のカメラを使わせていただく機会を与えていただき、感謝しています。自分としてはどれもこれまでにない仕上がりとなり、心置きなく返却できます。いや、かなり後ろ髪をひかれます...。もうちょっと使いたい...。できれば欲しい...。



前回の記事でSCA260の赤道儀の反転時のガタつきによる光軸ズレを解決しました。


早く撮影したいのですが天気はしばらく回復しなさそうなので、ガタつきが判明した反転前の前半のトール兜星雲の画像を撮り増し分を加えて、以前の画像に追加して仕上げてみました。


以前の画像の問題点

前回仕上げた際画像の問題点は、
  1. 露光時間が足りないため、背景がノイジーで炙り出しにくかったこと
  2. Hα画像とOIII画像を合成すると、背景に大きなムラが出てしまったこと
  3. おそらく光軸があっていなかったために特に微恒星などにシャープさがないこと
  4. シャープさ、とくに恒星の中心が出ていないせいか、StarNetで恒星と青雲を含む背景が分離できなかったこと
などです。

1については今回追加した分でHα: 3分x27枚、OIII: 3分x36枚、総露光時間3時間9分となり、前回までのHα17枚、OIII19枚の計36枚で総露光時間1時間45分に比べて倍近くになりました。

2についてはOIII画像のフラットフレームのみ変なムラがあったので、OIIIのライトフレームにHαフィルターで撮影したマスターフレームを適用することで、かなりましになりました。なぜOIIIのフラットのみそんなにムラがあるのか理由は不明です。曇った日の窓からの光が壁に当たるのを使いましたが、壁の反射などどこかでOIIIの帯域に関して均一でないのかもしれません。また、フィルターのおかげで暗くて十分な光量が取れなかったのかもしれませんが、まだ何も根拠はありません。これは時間をとってもう少し追求してみます。

3については、SCA260の光軸を合わせてから赤道儀を反転するまでの画像を追加で使ったので、少しマシかと思います。それでも時間と共に光軸合わせをした水平からどんどんずれていくので、撮影した画像の四隅をよく見ると少しズレの影響が出ているようです。今後はもうずれないはずなので次回以降の撮影に期待したいと思います。

4ですが、今回たまたまStarNet2がリリースされていて、かなり性能アップされているので少し比較してみます。


StarNet2の威力

これまでもStarNetは背景と恒星を分離してくれて、スターマスクにするなど非常に強力なツールでした。でも、恒星分離がうまくいかないことも多くあり、例えば風などでブレてしまった時、長焦点距離で恒星が大きくなってしまった時、そして前回のトール兜撮影の時のように光軸がズレた時など、主として恒星の中心が出ていない時に恒星を恒星として判断できないようで、分離できない微恒星がたくさん残ることが時々ありました。特に長焦点での場合などは頻繁に起こりました。

これは前回のトール兜でStarNetで分離しようとして全然うまくいかなかった画像です。かなりの星が残ってしまっています。

Image11_DBE_DBE_AS_HT_HT

このような場合には、事前にSTFのオートストレッチとHistgramTransformatioinでわざと恒星をサチらせてとか、ExponentialTransformationでわざわざ中心を尖らせてからStarNetをかけるとかしていましたが、今回のトール兜はそれらのテクを駆使しても全く太刀打ちできませんでした。前回の仕上げの時の炙り出しで攻めきれなかったのは、このStarNetがうまくいかなかったことが大きな原因の一つです。

ところが、今回リリースされたStarNet2はものすごい威力で、この全く太刀打ちできなかった画像もなんなく恒星分離できてしまいます。



StarNet2のインストールに関してはすでに各所で解説されているので、ここでは詳しくは書きませんが、一つだけ。Mac版のPixInsightですが、その時点の最新版の1.8.8-12にしたら、StaNet2をダウンロードしてくると付属されているlibtensorflow.2.dylibとlibtensorflow_framework.2.dylibがすでにPixInsightのbinに入っていました。私は結局StarNet2に付属のものはコピーせずに、PIに入っていたものをそのまま使いましたが、今のところ特に問題は起きていません。

StarNet2はオプションも簡単で、背景も同時に出力するオプションにチェックを入れるだけで、あとはStrideも256のままで、以前よりも短時間で遥かに強力に恒星を分離でき、以前は目立っていた恒星の後のブロック状のノイズもほとんどわからなくなっています。

上のStarNetでうまくいかなかった画像をStarNet2で処理してみるとここまで綺麗に分離してくれます。
Image11_DBE_DBE_AS_HT_HT

ここまで綺麗に分離してくれると、いろいろ応用できそうです。


画像処理と結果

撮り増し分も合わせて、StarNet2を使い、トール兜星雲を仕上げてみます。前回との違いは、
  1. Hα: 3分x27枚、OIII: 3分x36枚、総露光時間3時間9分と大幅増加。前回までのHα17枚、OIII19枚の計36枚で総露光時間1時間45分に比べて倍近くになりました。
  2. ムラのあるOIIIのフラットフレームは使わずに、HαのマスターフラットをOIIIのライトフレームのフラット補正に使いました。
  3. StarNet2を使って恒星を分離。
  4. StarNet2でうまく分離できたので、恒星のL画像を使いEZ Star Reductionを使いました。明るい星は小さくなりましたが、微恒星はほとんど変わらず、やはり甘いです。
  5. 普通は分離した構成画像をマスクとして使いますが、今回は恒星だけの画像も、背景の画像も変なブロックノイズがないので、Photoshop上で「覆い焼き(リニア) - 加算」で合成しています。
とこれくらいでしょうか。

この中で大きく貢献しているのはStarNet2だと思います。撮り増し分は星像に関しては少しシャープでマシなのですが、低空で透明度が悪かったので微恒星の写りがあまり良くなく、暗い星が写っていないのと、トール兜の写りも淡いです。それよりも、きちんと構成と背景を分離できたことで思う存分あぶりだせたのが大きいです。あと、OIIIのムラが緩和されたのも、炙り出ししやすくなったという意味で地味に貢献しています。

結果です。

「NGC2359: トール兜星雲」
Image07_DBE_PCC_DBE_AS_HTx3_reducestar2_3_crop_mod
  • 撮影日: 2022年1月22日22時2分-23日2時5分、1月27日18時57分-21時00分
  • 撮影場所: 富山県富山市自宅
  • 鏡筒: SHARP STAR製 SCA260(f1300mm)
  • フィルター: Baader Hα:7nm、OIII:7nm
  • 赤道儀: Celestron CGEM II
  • カメラ: ZWO ASI294MM Pro (-10℃)
  • ガイド: オフアクシスガイダー + ASI120MM mini、PHD2によるマルチスターガイドでディザリング
  • 撮影: NINA、Gain 120、露光時間3分、Hα27枚、OIII36枚の計63枚で総露光時間3時間9分
  • Dark: Gain 120、露光時間3分、128枚
  • Flat, Darkflat: Gain 120、露光時間0.2秒、128枚
  • 画像処理: PixInsight、Photoshop CC
前回の画像と比べても、背景ムラがなくなり、恒星がシャープになり、トール兜星雲本体も細かく出るなど、かなり良くなっているかと思います。まだ微恒星のシャープさは不満がありますが、これは今回は仕方ないでしょう。次回以降に期待したいです。でもまあ、総じてそこそこ満足です。次は別の天体に移りたいと思います。

いつものAnnotationです。

Image07_DBE_PCC_DBE_AS_HTx3_reducestar2_3_Annotated


まとめ

StarNet2のリリースもあり、うまく撮り増し分が生きたと思います。微恒星のシャープさがまだ足りませんが、次回以降にさらに挑戦したいと思います。シーイングにもよるので、これくらい以上がコンスタントに出るなら、まあ満足かと思います。

今回ももそうですが、恒星の処理がまだあまりうまくないので、もう少し時間をかけてどんなのがいいか挑戦してみたいと思います。

天気が悪くてなかなか欲求不満が改善されませんが、少しガス抜きになりました。早く晴れて欲しいです。

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の画像処理を続けられます。

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を綺麗に出したい

実は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の店舗で買ったものです。もう東京にしばらく行っていなくて最近はネットでの注文ばかりですが、たまにはやはり店舗で色々話ながら購入したくて、懐かしくなってしまいます。

IMG_2825

写真にはオフアキ用に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のピント位置はそのままいじらずに撮影しました。そもそもフィルターが同じ厚さなのでピント位置はそのままでいいのか、鏡筒に色収差が多少なりともあるはずなので、やはり合わせ直した方がいいのか、今後もう少し検証する必要があるかと思います。

IMG_2823


後日、 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. まずは星を星として認識にない場合。
IMG_3066
のようなエラーが出ます。この場合はStarAlingmentの中の「Log(sensitivity)」を-2.00とかまで下げます。もしくは「Peak response」を0.9とか1.0まで上げると効果的です。

2. 次にうまく位置が認識されない場合は
IMG_3069
のようなエラーが出ます。ここは「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画像を見てやると、縦方向に縞ノイズが入っています。縮緬ノイズとも言われているやつです。

integration

よくよく調べると、WBPPの振る舞いが少し変わったようで、そのままだとbiasが使われない設定になっていました。理由はdark frameにflat frameにもbiasが含まれてるので撮影したbias frameは使わなくてもいいということのようです。

私はこれが気に入らなくて、master flatを作る際にbiasを使うようにしました。これはイコールflatdarkを使わないということになります。これが問題だったようです。以前flat補正をする際に縞ノイズが乗っかるのはフラットが何かしらで汚くなる(その時は撮影時間が短くてノイズが載るという理由だった)というのを示したことがありますが、flat frameのダーク補正をしないと、残ったダークノイズが縞ノイズを作るということが今回改めて示されました。こたろうさんが以前この件について言及されていたと思います。

というわけで、biasの代わりにflatdarkを使うと次の写真のように縞ノイズは無くなりました。


RGBの合成前の画像

RGB合成前の画像を示しておきます。

まずはR。かなり鋭い星像となっています。縮緬ノイズも消えているのがわかります。
masterLight_BIN-1_EXPOSURE-10.00s_FILTER-Red_Mono

Greenは以下のようになりますが、Rに比べると明らかに暗い星が少なく、星像も甘いです。
masterLight_BIN-1_EXPOSURE-10.00s_FILTER-Green_Mono

Bはさらにその傾向が強く、星像もかなり大きくなっていて、明らかに星の数も少ないです。
integration

このような傾向は普通のことなのでしょうか?それともピントがずれているのでしょうか?でもテストで画面を見ていた限り、ピントをどう合わせてもRがいつも鋭くてBは散々でした。

また、これらのズレは画像処理に影響がないのでしょうか?


Linear Pattern Subtraction

さて、上の画像をみると、横縞が結構多く残っているので、WBPPの新機能のLinear Pattern Subtractionを試しました。結果だけ言うと、あまりうまくいきませんでした。いくつかの横縞は目だたなくなるのですが、下のようによりハッキリした横縞となぜか縦縞が余分に加えられてしまうようです。

masterLight_BIN-1_EXPOSURE-10.00s_FILTER-Red_Mono_c3

今回はまだあまり試していないですが、一旦ここではLinear Pattern Subtractionを使わないで、次に進みます。


RGB合成とBanding noise除去

これでやっとR,G,Bのスタックしたものが出来上がりました。ただ、これらをそのままChannelCombinationなのでRGB合成しても星の位置がずれてしまいます。そのため、StarAlignmentで改めてこの3枚を位置合わせしました。これでやっとカラー画像が出来上がりました。

Image04_clipped

でもR画像で見たときのように、やはり横の線が気になります。なので今回はRGB合成後、ScriptのUtilitiesからCanonBabdingReductionを使いました。これはかなりよかったです。いくつかパラメータを試しましたが、Active Previewはほとんど役に立ちませんでした。値を変えて何度か試した方が良さそうです。デフォルトの1でもほとんど大丈夫でした。0.2だとノイズが消しきれません。また、2だとノイズが加えられるような感じです。0.5と比べると1の場合は少し黒い部分が残っている感じがしました。結局最後0.7としました。要するに大きすぎても小さすぎてもダメなので、いくつか試すといいということです。結果は以下のようになります。

Image04_clipped_banding

かなり良くなりました。


ここからはカラーでの画像処理

ここまで来れば、あとはこれまでのカラーの画像処理と同じです。

まずカラーバランスが滅茶苦茶なので、念のためDBEで少しカブリをとってからPCCでカラーバランスを整えます。PCCで恒星の色はそこそこまともになりました。ただ、鋭さがR>G>Bの順でかなり差があるので、鋭いRとボケたBの差で、赤が強いところは赤ハロが、青が広がってしまっているところは青ハロがあるようにも見えます。逆に言えば恒星の色がよく出ているようにも見えます。

その一方、PCCをかけてもどうしても背景が青く見えます。これはヒストグラムを見て理由がわかりました。背景のノイズが青が一番多いのです。おそらくRGBの感度に差があり、Rが一番感度がいいためノイズが少なく、次がG、Bは感度が低いためノイズが大きくなるのかなと推測していますが、実際のところはよくわかりません。もう少し検証が必要かと思います。

いずれにせよ今回はPhotoshopに持っていった際に、背景のRGBのヒストグラムを合わせる事でカラーバランスを整えることにします。


星像に苦労

あとは、ArcsineStretchなどでストレッチしてPhotoshopに渡すのですが、よく見ると星像がガタガタです。

特に短時間露光の場合に多いのですが、VISACの星像にはいつも苦労します。今回はなぜか4方向に尖って見えます。しかもスパイダーの方向ではなくて、なぜか45度傾いた方向です。MophologicalTransformationで少し整えますが、星マスクが必要です。

この星マスクも苦労しました。ストレッチ後、StarNetで恒星と背景を分離しようとしても、星の3割ほどしか分離できません。分離できない理由は、星像が汚い、中心のピークが出ていない、明るすぎる、暗すぎるなどです。きちんと丸になっていて、中心がサチり気味の方がうまく分離できるようです。そのため、今回は
  1. ストレッチ前のカラー画像をL画像にしてから
  2. いったんSTFでオートストレッチして
  3. HistgramTansformationで適用、
  4. その後ExpornentialTransformationでPIPのOrderを1.5にして適用、
  5. STFで真ん中の三角をを右に移動して暗くする
とい過程を取りました。4、5は2回繰り返しました。これにStarNetをかけることでM57の中にある以外の恒星は全て救い上げることができました。M57の内部にあるいくつかの恒星は分離できませんでしたが、こちらは別途RangeSelectionでうまく分離します。

こうしてできた星マスクを適用して、MophologicalTransformationで十字型にDilationで伸ばし、X字型にErosionで縮めることで円に近づけていきます。これでやっとPhotoshopに引き渡しです。


Photoshopでの仕上げと結果

今回はPhotoshopではほとんどたいしたことはしていません。ノイズ処理もなしです。ノイズ処理をすると背景がボテボテになり、星像の鋭さと合わなくなってしまうからです。

Image04_clipped_banding_DBE_PCC_AS_HT2_MT_PCC_ok
  • 撮影日: 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で撮ったものと比べます。左が以前のもの、右が今回のものです。

comp

今回は自己ベストかと思ったのですが、分解能だけ見たらもしかしたら以前の方がいいかもしれません。いやこれは画像処理のやりかたのせいで、見栄えをよくしようとした前の方が一見よく見えているだけかも。

もし以前の方がいいというなら、機材は今回の方が圧倒的に有利なので、これは完全にシンチレーション勝負になると思います。2年前の時はよほどシンチレーションがよかったのを覚えています。その他星の色、星雲の自然さ、背景の素直さなどは今回の方が格段に上でしょうか。

そういえば、この撮影の後になってVISACの光軸調整をしたのでした。その結果は反映されてないので、今一度シンチレーション のいい日を狙うとかでしょうか。


まとめ

初のRGBフィルターでの撮影と画像処理。いろんな新しいことがあってブログ記事が長くなってしまいまた。次回はもう少し早く処理できそうです。

分解能に関しては、やっぱり最後はシンチレーション なのでしょうか。リアルタイムで露光時間を1秒以下にして見てても、明らかに揺らいでいて、10秒ではこれくらいになってしまいます。次は揺れない日を狙うことになるのかと思います。

どうやらM57はAOOでもそこそこ色が出るみたいなので、次はナローのもしかしたら逆に長時間露光で、淡いところに挑戦するかもしれません。


おまけ

もう一つ、PixInsightの細かいテクです。projectファイルを保存して、ファイルのフォルダ名を変えたり、ファイルの場所を変えたりした時に、WBPPのインスタンスを右クリックして「Excecute in the global context」から再度開こうとすると、以下のようなエラーが出ることがあります。

IMG_2922

この場合、WBPのインスタンスををダブルクリックして出てきたMD5 checksumを消してやって、再びインスタンスをPI内で保存。それを右クリックのExcecute in the global contextで開くと普通に開けるようになります。

3月3日の雛まつりの日の夜、月の出が22時18分なので、夕方から準備すればしばらくの間撮影できそうです。狙いは迷ってましたが、早い時間なので季節遅れのカリフォルニア星雲にすることに。結構大きいので、FC-60CBと6Dで視野角的にもちょうど良さそうです。今回も狙いは自宅でフィルターなしでどこまで写るのか? (2021/3/19 追記: 勘違いで、CBPが入ったままでした。)ISO800で、露光時間3分にして、6Dのヒストグラムで見て一番明るい青が1/3くらいでした。

前回Sh2-240を同じセットアップで撮っていて、まだ機材はそのままの状態でほとんど残っています。なので、準備も時間で済み、仕事から帰って、夕食後から用意しても20時過ぎくらいには撮影を開始できました。撮影時間はちょうど月が昇る22時半ころまで。実際には西に傾き屋根に隠されて終了となりました。その後すぐに空が霞んできて曇りのようになったのでここで撤収です。

後でチェックしてみると39枚撮影して使えるのは36枚。3枚は屋根が入っていました。星像が流れているようなものはありません。後半になるに従って西の空に傾くので明るくなってきてしまうのですが、今回はそれらも全部使うことにしました。


WBPP 2.0

次の日フラットとフラットダークを同ISO800、1/400秒で128枚撮影し、ダークは以前撮った同じ範囲の温度をものを使用してWBPP(WeightedBatchPreprocessing)で処理。最近WBPPがメジャーアップデートされて2.0になり、かなり変更がありました。以前のバージョンから使っている人はまあ普通に使えるかもしれませんが、1箇所だけ注意。全てのファイルを登録後、新しくできたControl PanelタブのFLATのところでファイルを選択すると右側にオプションが現れます。これまではライトフレームはカラーかどうか選択するためにCFAオプションがあったのですが、今回からFLATもCFAが選べるので、もしフラットフレームもカラーで撮影したなら必ずCFAオプションにチェックを入れます。

今回のバージョンから処理過程を図にしてくれるのですが、FLATのCFAがオフのままだと下の写真のようになって、フラットが適用されていないのが分かります。

IMG_1943

きちんとFLATのCFAをオンにすると
IMG_1942
のように、きちんとフラットが適用されていることがわかります。

さて、その下のSeparate CFA scalling factorはまだよく理解していないのですが、とりあえず今まで通りオフでやってみました。ただ、オンにするとRGBで別々の係数を使い、オフだとまとめて一つの係数を使うということです。今回のフラットフレームはカラーバランスが取れていないので、もしかしたらオンにした方がいいのかもしれません。


あとは画像処理

出来上がったライトフレームをいつも通りDBE、PCC、ArcsinehStrech、HT、StarNetなどで処理をして、Photoshopに渡してさらに炙り出し。とりあえずできたのがこれです。

Image53_2

恒星がいまいち鋭くないとかいくつか不満はありますが、これはこれで完成です。さあ、ブログと書こうと今に至っているわけですが...

あれ?ダークがおかしい

...と(既に画像処理も終えて、このブログを書くために改めてダークファイルの数を)チェックしていて変なことに気づきました。WBPPのControl PanelにmasterDarkが多数枚登録されているのです。

IMG_1947

そしてDarksタブを見てみると露光時間ごとに一枚づつ、多数のmasterDarkが登録されているのが分かります。

IMG_1946

ところが、試しに今回撮影したフラットフレームとかライトフレームを登録してもこんな変な状況にはなりません。ダークフレームのみこのような状況になります。

ファイル名からdarkというのを取り除いたり、ヘッダ情報を見たりいろいろしたのですが、原因はもっと単純なことでした。ダークファイルが存在する上流のフォルダ名に一つでも「master」という文字が含まれているとこのような状況になってしまうようです。例えば今回は以前撮ったダークフレームを使い回したために「master」というフォルダの下に、さらに露光時間やISO別に幾つかのフォルダに分散してためてあったものを使ったために起きた問題でした。例えば「master」を「mas」とか抵当に名前を変更してダークフレームを登録するだけで、masterDarkでない普通のダークフレームとして登録されます。

さてさて、間違った多数の1枚偽masterDarkファイルで処理したものときちんとダークを登録して処理した画像と、で画像の差はあったか興味がある方もいるかと思います。拡大すると正しいダークを登録した方が明らかに黒い小さな点がなくなる、もしくは緩和されていました。差がわかる部分を拡大して比較ものが下の画像です。左が間違ったもの、右が正しいものです。このような小さな点が画像全面に散らばっています。

comp

ただ、最終仕上げに影響があるかというと、ドット単位くらいの話ですし、間違ったダークと言っても多少の補正はできているので、拡大してじっくり見ない限りはわからないレベルでしょう。

ちなみにこの「master」というフォルダ名、ダークだけでなく、バイアスやフラットを登録する際にも全く同じことが起きて、いずれもマスターファイルとして認識されてしまいます。これだとあまりにも制限が多いので、そのうちもう少し良い方法で解決されると思いますが、PixInsightを使う際にはmasterというのは特別な意味を持つので、むやみやたらに、少なくとも読み込む画像ファイルに関するところには使わないほうがいいでしょう。


仕上げ

このあとまた一通りの炙り出し過程をすませ、不満だった恒星部をもう少し出します。ついでに赤いところももう少しだけ。

master_cut_rot_DBE_DBE_PCC_SCNR_ASx4_HTx2_CT2
  • 撮影日: 2021年3月3日20時26分-22時29分
  • 撮影場所: 富山県富山市
  • 鏡筒:Takahashi FS-60CB + マルチフラットナー
  • フィルター: 無し SIGHTRON CBP
  • 赤道儀: Celestron CGEM II
  • カメラ:  Canon EOS 6D(HKIR改造, ISO800, RAW)
  • ガイド: f120mmガイド鏡 + ASI120MM mini、PHD2によるマルチスターガイドでディザリング
  • 撮影: BackYard EOS、露光時間180秒x36枚 = 1時間48分、ダーク50枚(ISO800、露光180秒)、フラット128枚(ISO800、露光1/400秒)、フラットダーク128枚(ISO800、露光1/400秒)  
  • 画像処理: PixInsight、StarNet++、Photoshop CC、DeNoise AI
Dark補正の違いはほぼ何も影響がないですが、2回炙り出しをやったのでいい訓練となりました。自宅でフィルターなし、2時間弱でこれくらい出るのなら、気楽でいいのかもしれません。

それでもやはり背景はノイジーなのは否めません。分子雲がもう少しあるはずなのですが、もっとはっきり出す技術をまだ確立できていません。今回2時間弱と短かったので、まだまだ撮影時間を伸ばしてみるのもいいのかもしれません。もしくはISOをもう少し上げて恒星がサチるのには目をつぶり、背景を重点的に出すことを考えてやってみるのもいいのかもしれません。

あ、そうだ真ん中らへんの一番明るい星の左のなぜか明るく見える星。ここだけボワッとにじみが出ています。そもそもこんなに明るい星でもないですし、もっと明るい星でもこんな滲みは出てません。ここのファイルはそれほど目立つにじみでもなく、いまだになぜか理由がわかりません。とりぜず理由がわかていないのでそのままにしています。

いつものAnotationです。

master_cut_rot_DBE_DBE_PCC_SCNR_ASx4_HTx2_CT2_Annotated


過去画像との比較

2年ちょっと前の2018年11月に撮影したカリフォルニア星雲です。

NGC1499_CUT

これは直接比較していいものなのでしょうか?記録を見ると撮影時間30分となっています。露光時間も約4倍、画像処理も今と全く違うので、淡いところも全然見えるようになっています。さすがに今回の方が圧倒的に進歩していますね。


まとめ

PixInsightのWBPPですが、まだメジャーアップデート直後でこなれ切れていない気がします。自分の慣れのこともありますし、また不具合などもあると思ってしばらく付き合っていくべきでしょう。

実際にはこれまであやふやだったフラットのCFA処理とかもはっきりしたり、コントロールパネルも見やすくていいです。これからもWBPPの進化に注目していきたいです。



カリフォルニア星雲(2): 撮り増し」に続く
 


めずらしく晴れた!さあ撮影だ!

1月20日と21日、珍しく1日半程度、撮影ができるくらいに晴れました。しかも昼間の立山があまりにきれいにくっきり見えました。透明度はいいに違いありません。

もうずっと晴れてなくて、途中短時間の電視観望や太陽撮影はありましたが、星雲に関して言えば前回の撮影日が12月9日でオリオン大星雲なので、もう一月以上撮影できていません。



M42は楽しかったですが、昔撮ったものの取り直しも飽きてきたので、今回はあまりにメジャーな明るいものでなく、少し淡いモクモクしたものを撮りたくなってきました。そのための最初の一歩になります。平日なので自宅撮影です。でもそもそもそんな淡いモクモク、遠征せずに撮れるのでしょうか?

ターゲットですが、この時期でTSA-120と6Dで撮れる画角のものから選びます。いろいろ考えてオリオン座の上の方のM78としました。まだ真面目に撮影したことがないので、初撮影になります。かなり昔、電視観望では見たことがありましたが、中心以外はかなり暗いのでほとんど何も映らなかった記憶があります。


半月が出ててもフィルター無しで撮影

今回は少し課題をつけます。
  1. 平日なので自宅になるため光害は気にしない
  2. 冬の北陸で天気のいい日がかなり限られているので、月があっても厭わない。この日は月齢7日で、ほぼ半月。沈むのは0時頃ですが、そのころにはオリオン座も結構西に傾いてしまっているので、夜の早いうちから撮影を始めます。
  3. M78は白色や青色が豊富なので、フィルターを入れるとどれくらい色が変わってしまう可能性があります。なのでNo光害フィルターでいきます。ただし、恒星にハロが出る可能性があるのがわかっているので2インチのUV/IRカットフィルターを入れます。
要するに、ほとんど光害対策をしなくてどこまで淡い天体が出るかということです。

これまでQBP、CBPなどを使って、自宅でも輝線スペクトルをそこそこコントラスト良く出せることを示してきました。しかしながら、これらはかなり強力な光害防止フィルターのようなものなので、たとえ輝線スペクトルをきちんと通すとしても、カラーバランスが崩れてしまうことはどうしても避けられないのかと思います。例えばQBPではかなり赤によりがちになります。CBPは青をもう少し出してくれるのでまだマシかと思います。ところが、特に今回のM78のように、反射星雲だと波長は恒星によるはずで、QBPやCBPでは本来あるべき波長がカットされてしまっている可能性があります。また、暗黒星雲とその周りのモクモクの色なんかも光害カットフィルターで様子が変わってしまうのでは思っています。これはCBPで網状星雲を撮影したときに、右側に出るはずの広い暗黒星雲が全く出てこなかったことに起因します。

実はこのフィルター無しでとこまで写るのか、ずっとやってみたかったのです。だってHIROPNさんが都心で低ISOで成果を出しているし、トータル露光時間を伸ばせば背景光ノイズは相当小さくできるはずで、必ず記録はされているはずの天体情報は、うまくすれば引き出すことができるはずだからです。でも失敗してせっかくの撮影時間をまるまる潰す可能性があるので、なかなか勇気が出ませんでした。


撮影開始、でもやはり光害の影響はすごい

そんなこんなでいろいろ考えながらも、準備を焦らずゆっくりして、22時近くから撮影を始めました。6DでISO800、露光時間は3分です。ところが途中で試しに1枚、ABEで滑らかにしてオートストレッチ後、HTしてみたのを試しに見てみたのですが、もうひどいものです。

LIGHT_180s_ISO800_0c_20210120_23h55m36s483ms_RGB_VNG_ABE

リングは多分ABE由来ですが、M78自身が中心以外ほとんど何も写ってません。センサーの汚れも目立ちます。衛星もたくさん写り込んでそうです。どうもこの超ノーマル状態での光害下での撮影はだめそうです。

ちなみに撮って出しJPEGだとそれこそほとんど何も写ってません。

LIGHT_180s_ISO1600_+8c_20210120-21h32m46s782ms

この時点でかなりやる気をなくしたのですが、また設定し直すのも面倒なので、そのままフテ寝してしまいました。朝起きて確認すると夜中の1時頃でカメラのバッテリー切れで止まっています。トータル3時間、月が沈むのが0時だったので、最初の2時間分はまだ月が出ていたことになります。もうだめそうだし、時間も途中で切れてかけれなかったのでここで諦めても良かったのですが、次の日も途中までは晴れそうです。

結局二日目も同じ構図で、少し撮り増し。というか、どうせ途中で曇る予報なので新たに別の天体を撮り切る時間もなさそうですし、M78なら前日の設定が全て残っているので、楽だったからと言うのが実際の理由です。二日目は準備もほとんどできているので、少し早めの18時過ぎから撮影を始めました。天気予報通り、21時すぎで雲が出てきたのでここで終了。この日も3時間程度の撮影時間でした。


スタックした画像を見てみると!

こんな状態だったので、画像処理もあまりやる気にならずに半ば諦めて放っておいたのですが、一応後日フラットとフラットダークを撮影してPixInsightでスタックまでの画像処理をしてみました。

ダークとバイアスは以前の使い回しなので、最近は楽なもんです。ISOと露光時間を合わせておくと、冷蔵庫法のダークライブラリの構築がそこまで大変でないです。スタック後の画像を見てみると、なんと意外にいけそう。下はオートストレッチ後、HistgramTransformation (HT)で適用したものです。

masterLight-BINNING_1-FILTER_NoFilter-EXPTIME_180.8

失敗画像を除いても5時間越えぶんの露光時間が効いたのでしょうか?色もきちんとついてますし、暗黒体の部分も結構出ています。

これは俄然やる気になってきました。


フラット補正とカブリ

ただし上の画像、フラットフレームを部屋で別撮りで撮ったので、実際の空とは違いどうしても1次的なカブリが残ってしまっています。

今回フラットフレームの撮影も簡易的な方法に置き換えました。昼間に太陽が出てる時、もしくは全面曇りの時に、部屋の中の窓から少し遠い白い壁を写すだけです。注意点は
  • 鏡筒の影を避けるために、壁に近づけすぎないこと。
  • 以前は鏡筒の先にスーパーの白い袋をかぶせていたが、今回はそれも外したこと。
  • ISOを同じにして、露光時間を短くしてヒストグラムのピークが中央らへんにくるようにすること。
  • その場で蓋をしてフラットダークも一緒に撮影してしまうこと。
などです。以前は晴れの日を選んで、スーパーの袋をかぶせていました。太陽が出ていて雲が横切ると明るさが変わってあまり良くなかったのですが、空一面の曇りなら大丈夫ではということです。あと、どうせピントは合わないので(多少壁はざらざらしているが)スーパーの袋はなくてもいいのではと言うところが改善点です。

さて、上の画像に残るカブリを取りたいのですが、左下の赤い部分はバーナードループなのでこれは残したいです。こんなときはABEはあまり使えません。実際にABEを1次で試しましたが、赤い部分が大きく取り除かれてしまいした。こんな時はDBEの方がよく、しかも点数をかなり制限してやります。実際打ったアンカーは数えたら10個ちょいでした。

DBE
(アンカーが見やすいように少し画面を暗くしています。)

これでできたのが以下のようになります。カブリが取れて、かつ左下の赤いのはしっかりと残ってます。

masterLight_180_8_integration_DBE4


ここでPCCのトラブルに直面

この後はPCCで、恒星の色を合わせます。ところがところが、肝心な時にPCCがなぜかうまく動きません。これで2日ほどストップしてしまいましたが、その顛末は前回の記事にまとめてあります。




ストレッチからPhotoshopに渡して仕上げへ

PCCがうまくいったあとはArcsinhStretch (AS)を何度かに分けてかけ、ストレッチします。ASは彩度を落とさない利点があるのですが、恒星の鋭さが無くなるので、StarNetで恒星が分離しきれない問題があります。そのため、ストレッチ前の画像から改めてScreenTransferFunctionでオートストレッチして、HTで適用することで恒星を鋭くしました。こうすることでStarNetできちん恒星と背景を分離できるようになります。分離した恒星画像から星マスクを作ります。実際にMaskとして使うにはMohologiacalTransformationのDilationをかけて少し(1.5倍位)星像を大きくします。

あとはPhotoshopに渡していつものように仕上げです。基本はほとんどが先ほど作った恒星マスクを当てての作業になります。DeNoiseも使います。そういえばDeNoiseのバージョンが2.4.0に上がり、Low Lightモードのノイズがさらに改善されたとのことです。DeNoiseは非常に強力ですが、それでもやはりマスクの境や、モコモコしたカラーノイズのようなものが出るなど、悪影響がどうしても残ってしまうことは否めません。今後はいかにDeNoiseから脱却することが課題になってくるのかもしれません。

結果を示します。少しトリミングして90度回転しています。

「M78」
masterLight_DBE4_crop_PCC_pink_AS3_cut

  • 撮影日: 2021年1月20日21時51分-1月21日1時12分、1月21日18時12分-21時20分
  • 撮影場所: 富山県富山市
  • 鏡筒: タカハシ TSA-120 (口径120mm, 焦点距離900mm) + 35フラットナー + SVbony 2inch UV/IRカットフィルター
  • 赤道儀: Celestron CGEM II
  • センサー: Canon EOS 6D HKIR改造
  • ガイド: PHD2 + 120mmガイド鏡 + ASI120MM miniによるディザリング
  • 撮影: BackYard EOS, ISO800,  露光時間: 180秒 x 108枚 = 5時間24分
  • 画像処理: PixInsight、Photoshop CC, DeNoise
どうでしょうか?光害下で、Noフィルターとは思えないくらい出たのではないかと思います。自分でもびっくりです。M78はこれまでも何度か挑戦しようとして諦めていたので、これくらい出ればそこそこ満足です。

ついでにAnotationです。

masterLight_DBE4_crop_PCC_pink_AS3_cut_Annotated



考察

今回の結果はある意味一つの挑戦です。

光害や月明かりが、実際の仕上げまでにどこまで影響するかです。はっきり言って、庭で半月でフィルターなしでここまで出てくるとは全く思っていませんでした。少なくとも1枚画像を見たときはこのチャレンジは失敗だと思っていました。

色バランスを考えた場合、フィルターは少なからず影響を与えます。なので色の再現性だけ考えたときには、フィルター無しの方が良いのかと思います。その代わり当然ですが、フィルターが無いと光害地では明るい背景光やカブリが問題になります。

明るい背景光は大きなノイズ(ノイズは明るさのルートに比例します)を出すので、淡い天体はノイズに埋もれてしまいます。それでも背景光に比べて、天体の明るさの分、少しだけ明るく記録されます。背景光のノイズは多数枚スタックすることで小さくなります。ヒストグラムで考えると、ピークの広がりが小さくなるということです。ノイズピークの広がりが小さくなれば、その一定値に近くなった明るさの中央値をオフセットとして引くことで、天体をはっきりと炙り出すことができるようになります。トータルの露光時間が増えれば、多少の光害地でも淡い天体を炙り出すことは不可能ではないということです。

ではフィルターの役割はなんでしょう?まずは背景光のノイズを光の段階で軽減させることが一番の理由でしょう。もちろん程度問題で、暗いところで撮影したら光害防止フィルターの効果は小さいでしょう。逆にあまりにひどい光害地でフィルターなしで撮影しても、一枚あたりの露光時間をろくにとれなくなったりするので、どうしてもフィルターが必須という状況もありえるでしょう。

あとこれは個人的な意見ですが、フィルターのメリットの一つは画像処理が圧倒的に楽になることではないかと思います。今回の光害下での撮影の画像処理は結構というか、おそらく初心者から見たらかなり大変です。例えばカブリ取りなんかは相当戦略を考えて進めることになります。こういった困難さを避けることができるのなら、光害防止フィルターは大きな役割があると言っていいのかと思います。

逆にフィルターのデメリットの一つは、すでに書きましたがカラーバランスが崩れるということがあると思います。画像処理で多少は回復できますが、それはそれで負担になってしまいます。あと、高級なフィルターの場合、値段もデメリットの一つと言えるのかと思います。

フィルターを使う使わないは、状況に応じて臨機応変に考えれば良いのかと思います。それでも今回、光害地で半月が出ている状況で、フィルターなしでも、画像処理によっては淡い天体をある程度炙り出すことも可能であるということが、多少は示すことができたのではないかと思います。このフィルター無しの方法が、どのくらいひどい光害まで適用できるのか、ここら辺は今後の課題なのかと思います。

今回は失敗かと思ったところからの大逆転、かなり楽しかったです。



 

このページのトップヘ