ほしぞloveログ

天体観測始めました。

カテゴリ: software

BlurXTerminator (BXT) が面白いです。前回までで、ゴースト星雲でのBXTの試用と、BXTをカラー画像に適用した場合などを記事にしてきました。





その後、BXTのバージョンが上がり1.1.1になりました。初期バージョンでは恒星の色ずれがPIのForumで指摘されていたようですが、新バージョンではそれも解決されているとのことです。

BXTの効果がかなりすごいので、過去画像にもいくつか適用してみました。今回の再処理は全て新バージョンで試しています。


三日月星雲

まずは、はくちょう座にあるNGC6888: 三日月星雲で比較です。下の画像は昨年5月にSCA260で撮影し処理したもので、AOO合成になります。当時はそこそこ分解能もでていると満足していました。
Image11_ABE1_PCC_ABE4_cropped2_mod
この時の反省点は、星雲本体はよく出たのですが、背景がかなり淡くて出にくかったのを覚えていて、結構無理をしてノイズ処理をしました。背景の細かい構造はほとんど飛んでしまっています。ここら辺がBXTとNXTが入ったらどうなるかも気にしたいと思います。


BXTとNXTの適用

元のファイルは前回WBPPまで終了して、AOO合成までしたものを使います。まずはSPCCをかけ、すぐにBTXです。この時点ですごい分解能となり、ちょっとびっくりしました。

ストレッチはHistgramTransformationです。ArcsinhStretchとMaskedStretchも試しましたが、星雲本体の赤の部分が差散り気味になってしまったのであきらめました。あとはCurveTransformationのSaturationで彩度を出します。その後NXTでノイズ処理をしています。

これまでマスク処理は、マスクをPIで作ってからPhotoshopにマスクを渡して処理をすることがほとんどでした。今回はマスク処理自身もPIでやってみることにします。今回のマスクはB画像から作り、星雲本体の青いところを強調しました。最後にPhotoshopに一応手渡してほんの少しだけ色を好みのものにしましたが、今回は自分的には98%くらいがPIでPhotoshopで触ったのは本当にごくわずかです。

結果です。一見しただけでBXTを適用したものは三日月本体の分解能が圧倒的に上がっています。

Image11_SPCC_BXT_HT_HT_CT_SCNR_NXT_maskB_CT_CT_CT_ok2

青いところもよりはっきりと出すことができました。背景もそこそこの階調で出ていて、ノイズ処理もより自然になっているように見えます。以前の処理と、今回の処理の違いを一言で言うと、以前のものは画像の中にある情報を引き出し切れていなかったと言うところでしょうか。BXTの底力を見せつけてくれる結果と言えます。

あと、微恒星の数が圧倒的に増えています。私は元々恒星の処理が下手くそなのですが、BXTとNXTのおかげかかなり楽になりました。作業がPIで閉じていて、恒星と背景を分離したり合成したりする必要がなくなってきたことが大きいです。分離は使うとしても軽い星マスク程度です。言い換えると、分離というある意味特異な処理をする必要がなくなりつつあり、より自然に手間をかけずに恒星を出すことができるようになってきています。


驚異的な分解能

こうして見るとBXTの威力がいかに凄いかわかるのですが、いささか分解能が出過ぎのような気もします。そこで、さらに高解像度の画像、例えばこのページにある三日月星雲と比べてみます。試しにPhotoshopで各レイヤーに自分の画像とリンク先の画像をはって、拡大縮小回転などして位置合わせをして、レイヤーの表示/非表示でかなり詳細に比較してみました。

少なくとも私がみた限りでは、BXTのAIによってあからさまに変な線が出ているようなことはないようです。勝手に上記の画像をこのブログに貼るわけにはいかないのですが、結論としては、おかしくないパラメータの範囲でBXTを使う限りは変な構造を加えるようなことはなく、画像の中に情報として残されている構造をかなりのレベルで引き出しているのかと思います。また、引き出す構造に限界もあり、これも詳細画像と比較するとわかりますが、撮影画像の中に無い構造はやはり出てこないこともわかるので、少なくともAIだからと言って、そこまで変なことをしているわけではないのかと思います。

BXT、今回もかなりの手応えなので、今後もう少し過去画像の再処理を続けたいと思います。

前回の記事で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での結露

前回、SCA260で撮影した馬頭星雲のことを記事にしましたが、3月のオリオン座は早くに西の空に傾くため、後半は別の天体を撮影することにしました。撮影が複数日にまたがっていたので、フラットやダークが使いまわせるよう、基本何も変えない同じ露光時間、同じゲイン、同じカメラ回転角が条件です。

少し迷ったのですが、M100に決めました。理由は
  1. 春の銀河まつりに参戦するのは今年の目標の一つであること
  2. M33などの大きな銀河はすでに試したので、少し小さめの銀河を試したかったこと
  3. 以前おとめ座銀河団を広角で撮影した時にM99やM100が小さいながらもかっこよかったから
などです。

 


まだ赤道儀はCGEM IIで撮影したときのものです。撮影は3分露光です。M100は小さいので真ん中らへんに小さく写っているだけです。これで分解能が出るのかが今回の勝負です。

でも結論だけ言うと、撮影した画像を見て早々と勝負に負けました。やはりこれくらい小さい天体を撮ろうとすると、揺れが大きすぎるのです。


撮影のことはもう忘却の彼方に

撮影は3月3日と3月9日の二日に渡りました。最初の3月3日の方はまだ使えたのが
  • R:18/20枚、G:20/20枚、B:20/20枚
とマシでしたが(それでもかなり甘い判断です)、3月9日の方は(もう忘れてしまいましたが、風が多少拭いていたのかと思いますが)使えたのがわずか、
  • R:4/12枚、G:2/10枚、B:4/35枚
と散々でした。画像を見ていると、大きく揺れて2つの点になってしまっているのが多かったです。これを見て、さすがにCGEM IIで系外銀河の分解能に挑戦するのは辛いことが実感できました。まあ、頭では何となくわかっていたのですが、信じたくないバイアスがかかっていたのかも...。

本当は3月3日の撮影でBがまだまだノイジーだなと思い、3月9日はBを重点的に撮り増ししたのですが、使えたBはわずか1割と、この揺れのおかげであまりやる気が起きずに、実際の撮影からかなり日にちが経ってしまいました。とりあえず見えるだけでいいやと重い腰を上げ、やっと画像処理を進めることにしました。


WBPPの変化

PixInsightのWBPPですが、最近いくつか気づいたことがあります。まずBiasファイルですが、これはDarkファイルがBaisを含んでいるために、もう処理には使われていません。CalibrationタブのDark設定のところであえてBiasを含まないというオプションを使うと、「検証の結果、biasを引いたダークは今後はお勧めしない」と怒られてしまいます。かといって、Biasファイルを全く指定しないとエラーで止まったりするので、Master Biasをおまじないで登録しておくことにしています。ちょっとまだ整合性が取れていないようです。

あと、Pedestalというのを入れてみることにしました。これは画像処理の過程で0以下の輝度になることを防ぐようです。
WBPP
最近のWBPPでの設定。

Reference画像をオートで選ぶと、たいていRとかの明るく画質がいいのを選んでくれるのですが、これを基準にしてしまうと例えば暗いBがIntegration時に大量に弾かれてしまうことがわかりました。実際にIntegrationされたのはわずか
  • R:21/22枚、G:16/22枚、B:11/24枚
でした。これは前回の馬頭星雲でも同じことが起きていて、原因がわからなかったのですが、Reference画像をマニュアルであえて暗めのものを選ぶことで回避できることがわかりました。その結果、
  • R:22/22枚、G:22/22枚、B:24/24枚
と全てIntegrationに回りました

RGB合成した画像を見てみると、揺れが平均化されているせいか、かなり真円に近くなりました。
Image27_ABE_PCC_crop_DBE_mosaic01

これだといいと思ってしまうかもしれませんが、一枚一枚は揺れていることと、大きく揺れることもあるので採択率は悪いし、何より銀河の解像度は出ていないはずなのでやはりダメです。


EZ Deonを(少しだけ)使ったdeconvolution

今回の画像処理のポイントは、PixInsightでDecomvolutionを試してみたことです。実はこれまで何回も試していたのですが、一度もうまく行ったことがなく、今回ScriptsにあるEZ Deconを使うことではじめておかしくない結果が得られました。

そもそもDeconvolutionはPSFをあらかじめ作るとか、StarNETであらかじめマスクを作っておくとか、R Range maskが必要とか結構面倒です。しかもマスクをの微調整で結果が劇的に変わったりします。参考にしたのはniwaさんのページ


相変わらずものすごく親切な説明で、素晴らしいです。とても感謝しています。さらにはリンギングを無くすために皆さんでいろいろ議論されたことも、最後の方のリンク先から辿ることができ、かなり実用的です。

それでもこのDeconvolution、なかなかうまくいかないんですよね。なので今回EZ Deconという簡単にdeconvolutionを試すことができるスクリプトを使いました。EZ DeconはEZ Processing Suiteの中の一つで、インストール方法はこちらを見るとわかります。


上のページは英語ですが、niwaさんが日本語でも解説してくれています。


EZ Deconを走らせると、こんな画面になります。
decom1

最初はよく分からないのでおもむろに「How to use EZ Decon」というヘルプボタンを押します。読んでいくと以下のようなことが書いてあります。

1. まずは処理したい画像(リニアステージのもの)を選択し、Star Maskを作れと言います。このスクリプトはまだStarNETのV2には対応していないようなので、今回は別途StarNet  V2で星マスクと作っておいて、スクリプト中で選択しました。

2. 次のレンジマスクはこのスクリプトでおまかせして作ってもらいました。

3. 最後「Deconvolution」タブをに移って、PSFを作れとのこと。なんとこのスクリプト、PSFが「Generate PSF」ボタン一発でできてしまいます。これはかなり楽です。

4. ここからがすごいです。deconvolutionを試すのですが、「Evaluate EZ Decon Run」ボタンを押すたびにタブが増えていき、右の方の「Change Tab to Original」ボタンと「Change Tab to Decon Run XX」ボタンを交互に繰り返し押すと、オリジナルとの違いを簡単に切り替えて比較することができます。基本的に変更できるパラメータはスターマスクをどう扱うかのみ。ヘルプに書いてますが、スターマスクを強調したりソフトにしたりすることで結果の違いを見ます。
  • もし画像がノイジーになるなら、Wavletの強さ(strength)を増やす。
  • もし画像がシャープになりすぎるなら、繰り返し(iteration)の数を減らす。
  • もし恒星にリンギングが出るなら、Star Maskの半径を増やして、恒星をよりカバーする。
とのことです。

5. うまくいきそうなら、最後に下の「Run EZ Decon」を押して実際の画像に反映させます。

でも結局このEZ deconでは、どうしても最後までリンギングが残ってしまい、結果は使わなかたんですよね。その代わり、EZ deconで生成されたPSF画像を使い、niwaさんが解説してくれていた、このページ

のもりのせいかつkさんのGlobal dark 0方法でやることで、リンギングを抑えてうまく細部を出すことができたようです。

decon_comp

左がDeconvolution前、右がDeconvolution後です。EZ Star Reductionもかけてしまったので、恒星の大きさは無視してください。銀河の細部は多少出てるようになったと思います。

というわけで、このEZ Decon、結局は簡単PSF生成ツールとしてしか使いませんでしたが、スターマスクの効き具合の感覚とかを気軽に試して、振る舞いを理解するのにはすごく役に立ちました。deconvolutionで困っている人は、一度同じように試すといいのかもしれません。

ところで、DeconvolutionのLocal supportというのがいまいち何をしているのかわかりません。スターマスクをリンギング防止に使っているのなら、恒星自身のdeconvolutionができていない気もするのです。実際、恒星がスリムになったような効果は見えませんでした。そういうものなのか、それとも撮影条件が悪くあまり効かないのか、もう少し理解する必要がありそうです。

その後、ものはついでにEZ star reductionも適用しました。以前、トール兜星雲の時にも試しましたが、その時はそこまで有用性は見出せませんでしたが、今回はかなりの効果があったようです。


いつものPhotohopでの仕上げ

あとは普通にPhotoshopに持っていっての処理でしょうか。今回少し違ったのは、Photoshopで細部があまり出せなかったことです。すでにdeconvolutionである程度の細部出しができているためでしょうか。試しにdeconvolutionなしの画像をPhotoshopに引き渡し、いつも通り加工するのですが、こちらは細部が出てきます。ですが、出来上がった画像の細部はほぼ同等でした。細部をどこで出すかだけの問題で、その画像が持っている限界があり、ポテンシャル以上のものは出ないということがよくわかりました。まだまだDeconvolutionをたいして試していないので、少し甘い気もしますが、むしろ自然な処理具合な気がしています。今後は(やっとですが)Deconvolutionの方に移行していくことになると思います。

結果です。

「M100」
Image27_ABE_PCC_crop_DBE_decom_stredu_ABE_PCC6
  • 撮影日: 2022年3月3日23時51分-3月4日4時37分、3月10日2時54分-5時1分
  • 撮影場所: 富山県富山市自宅
  • 鏡筒: SHARP STAR製 SCA260(f1300mm)
  • フィルター: Baader RGB
  • 赤道儀: Celestron CGEM II
  • カメラ: ZWO ASI294MM Pro (-10℃)
  • ガイド:  f120mmガイド鏡 + ASI290MM、PHD2によるマルチスターガイドでディザリング
  • 撮影: NINA、Gain 120、露光時間3分、R: 22枚、G: 22枚、B: 24枚の計68枚で総露光時間3時間24分
  • Dark: Gain 120、露光時間3分、128枚
  • Flat, Darkflat: Gain 120、露光時間 RGB: 0.08秒、RGBそれぞれ128枚
  • 画像処理: PixInsight、Photoshop CC

実は赤ポチとか青ポチとか期待してHαとOIIIも撮影したのですが、枚数が少なすぎで諦めました。M100の周りの淡いところがもう少し出るかと期待していたのですが、少し露光時間が足りないのかもしれません。もしくはゲインを例えばもう3倍とか上げた方がよかったかもしれません。

恒例のAnnotationです。M100の他にもNGC4312を始めいくつか銀河があるのがわかります。

Image27_ABE_PCC_crop_DBE_decom_stredu_ABE_PCC6_Annotated

最後に、FS-60CBで撮影した時画像
up_DBE_DBE_PCC_AS_HT_all_disks_back2_rot_denoise_larage_cut
からM100の同じ領域を抜き出して拡大してみます。
FS-60

回転して向きをあわせてますが、左端は映ってない領域でした。恒星はまだいいとして、FS-60CBで撮ったM100の解像度が良すぎてなんか怖いです。


まとめ

撮影途中で揺れているのがわかってしまい、あまりやる気の出なかった画像処理ですが、やってみると意外に実のあるものでした。これまで何度も試してことごとく諦めていたDeconvolutionですが、今回のこのEZ Deconでできなかったらもう2度とやらないかもしれないと思いながらやりました。まだ満足とはいきませんが、今後続けていく気にはなりました。それでもFS-60CBで撮ったのが今思うとすごすぎます。SCA260の口径が大きくてもまだ揺れが大きくて性能出しきれていないのでしょう。

まだCGEM IIで撮影した、M101が残っています。サクッと終わらせたいのですが、とにかく忙しくてなかなか時間が取れません。某天文雑誌の原稿もやっと目処がついてきました。その後、晴れてやっとCGX-Lで三つ子銀河と、M51の画像処理ができます。


SharpCap(有料版のみ)やASILiveには、リアルタイムでダーク補正をしてくれる機能がついています。これがどこまで有効なのか、常にオンにしておいた方がいいのか?色々やり方はあると思います。今回は私Samが普段どうしているかSharpCapを使って解説したいと思います。


ホットピクセルがはいずった痕

SharpCapでの電視観望中Live stackをしていると、よく赤、青、緑の単色のミミズみたいなノイズが入ることがあります。「ホットピクセル」とか言われているもので、長時間露光時やセンサー温度が高い時に出てくるダークノイズの言われるもの一種です(下の画像をクリックして拡大して見て下さい)。
hot

この画像は、自動追尾さえしてなくて、Livestackのみで星像を重ねています。なのでこんな短時間で長いミミズさんがでてますが、自動追尾している場合は同じ時間ならこれより遥かに短くなります。

いずれにせよ電視観望でも見栄えが良くないので、これを取り除きたくなるかと思います。こんな時はリアルタイムでダーク補正ができる機能があります。


ダーク補正機能の注意点1

SharpCapでのダーク補正は簡単で便利なのですが、いくつか注意があります。まず一つ目、これはSharpCapに限らず一般的なことなのですが、

撮影したダークフレームは、
同じ露光時間、同じゲインでしか
使用できない

ということです。見たいものが安定していて、露光時間とゲインが確定していれば問題ないのですが、電視観望みたいに露光時間やゲインをちょこちょこ変えて見ていると、ダークフレームをどの設定で撮影すればいいか決まりません。もちろん厳密に合わせなくてもダーク補正の効果はあります。ただし、設定がズレればずれるほど、その補正効果も小さくなっていくので、やはりできるだけ合わせておいた方がいいでしょう。

実際の電視観望では、導入時(移動する動きを見たいので、露光時間は例えば400ms程度)、観察時(止まっているので長い露光時間、例えば1.6秒とか、3.2秒、長くても12.8秒程度まで)の露光時間をあらかじめ決めておきます。ゲインは最大から一段階下げるくらいで、高い位置のままいじりません。このようにして、ダークフレームは観察時の設定に合わせるように一種類だけ撮影しておけば、基本的には事足りるはずです。何種類もとって切り替えてもいいですが、観望会でお客さんがいる時などは、時間のロスになってしまうかもしれません。


ダーク補正機能の使い方

SharpCapでの実際のダーク補正のやり方です。

1. まずはメニューの「キャプチャ」から「ダークフレームキャプチャ」を選びます。
2. 撮影前に、必ず鏡筒に蓋をするのを忘れないで下さい。
3. 枚数は多くなくていいです。8枚とか、16枚で十分でしょう。ただし、撮影のようなことをしたくて数十分以上とかの超長時間ライブスタックを掛ける場合はそれなりの枚数にして下さい。
darkcapture

4. ダークフレームの撮影を開始し、スタックし終わるのを待ちます。
darkcapturing

5. ダークファイルができたら、右の「前処理」タブの「ダーク補正」で「参照」を押し、ダークファイルを選択します。自動的にできたファイルのフォルダに移動さるはずなので、そこにあるファイルを選べばいいでしょう。

これでLive stackをしてみると、目立っていたミミズさんはすっかり消えているはずです。ただ、細かいたくさんの縞が残るかもしれません。それでもダーク補正しないよりはマシになるかと思います。

LS_80


ダーク補正機能の注意点2

さて、ここから少しテクニックです。この状態で鏡筒にカバーをしてヒストグラムを見てみましょう。
nohot

ここでの問題は、ヒストグラムの山の左端が切れてしまっていることです。SharpCapでは輝度が負の値になるようなことはなく、0以下は全て0になるようなので、ものすごくおかしなことは発生しません。でもこれは読み出しノイズがガウス分布に従わずに、不自然な状態になってしまっていることになります。言い換えると、
リードノイズの暗い部分はバッサリ斬られていて、
階調がとれなくなります
これが2つ目の注意点です。

階調がとれないとはどういうことでしょうか?例えば、先ほどの北アメリカ星雲を見ている時に輝度をあえて下げてやって、ヒストグラムの山の左端を欠いてやります。

LS_bad

ライブスタックのヒストグラムの左が欠けていますね。すると色バランスが損なわれ、どういじってもこの画像のように見た目にもおかしいものしか出てきません。

これは極端な場合なので、普通に電視観望している範囲では基本的にはこんなことは発生しません。でも、もし画像を見て階調が取れないような時は変にヒストグラムがカットされていないかを疑った方がいいこともあるので、心に留めておきましょう。


ヒストグラムの山を回復する

さて、リードノイズに関して、このような階調不足を避ける方法を考えます。まず、ダークフレームを撮影する前に、右の「画像情報」タブの「輝度」のところを、最初から少しあげておきます

withhot

私は最大値(ASI294MCの場合80)の半分くらい(40)にします。ポイントは右パネルのの「ヒストグラムストレッチ」で見て、まずはダークフレーム取得時点で山の左が欠けていないことを保証すること。山の左すそが、一番下まで言っていればいいです。山が左に行きすぎて左すそが途中で無くなっているような状況は避けてください。

ここまではいいのですが、この状態でダークフレームを撮影してダーク補正を適用すると、オフセットも消そうとするためヒストグラムの山の左が欠けた状態になります。
nohot

ここで、さらに「画像情報」タブの「輝度」の値を上げて、ヒストグラムに山の左側に欠けがないように再び設定します。

nohot_withoffset
山が回復したのがわかるかと思います。

ちなみに、電視観望をやっているだけなら、上記の補正は特にしなくても、特におかしいことはないと思います。補正の有無で以下のようになります。

LS_80
輝度補正なし(40のまま)。

LS_80real
輝度補正あり(80に増加)。

補正有無で比べても特にどちらかが悪いということはないと思います。ただこれを画像処理とかして、撮影画像とかして扱うときは補正なしだと少し気をつけた方がいいかもしれません。リードノイズに相当する部分が既に破綻しているので、もしかしたら何か影響があるかもしれません。


リアルタイムダーク補正は必要か?

ちなみに、私は電視観望の際は大原則としてリアルタイムダーク補正はしません。理由は、露光時間、ゲインを頻繁に変えることが多いからです。また、月や惑星などの明るい天体を見ていて、ライブスタックに入らないような場合には、ホットピクセルは点のままで線にはならないので、そこまで問題にならないはずです。

ホットピクセルが多い場合(カメラの機種に依りますし、気温にも依ります。)で、ライブスタックに入り、かつ露光時間とゲインの設定をあまりいじらなくていいくらいになると、リアルタイムダーク補正をすることがあります。特に、ライブスタックで数分以上の長さでしばらく放っておくような時です。

リアルタイムダーク補正を行う際は、上で説明したリードノイズの山の形の補正は必ずやるようにしています。といっても、炙り出しがキワキワになった時にもしかしたら効くかもしれないと思ってしまうからという程度です。

あとよく似たことで、リアルタイムフラット補正は使ったことがないです。これは鏡筒の方向を変えるとカブリなどの状況がガラッと変わるからです。かなり昔に一度だけリアルタイムフラット補正を試したことがありますが、あまりうまくいかなくてそれ以来使っていません。その頃から大分状況は変わっているので、もしかしたら今試してみたらもう少しいい方法があるのかもしれません。


まとめ

いつかこのリアルタイムダーク補正の話を書こうと思って、途中書きになっていたのですが、前回の記事のコメントでちょうどカトーさんからダーク補正についての質問がありました。これが答えになってくれるといいのですが。


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

sanpojinさんのSharpCapでの極軸測定がうまくいかないという記事を見て、どうもたわみが原因な気がしました。三脚の足を伸ばし切って極軸測定しているため、足元が弱くて、赤経体を90度回転させるとたわんで正確な測定ができていないのではと思ったのです。

逆に、もしたわみによって極軸調整の精度がずれするなら、そのSharpCapでのズレの値評価することでたわみ自身が定量的に測定できるのではと思い、今回考えてみました。

IMG_0829


たわみの測定原理

簡単なところから考えます。

まず、赤道儀が完全に天の北極を向いていて、極軸に誤差がない状態を考えます。もしこの状態でSharpCapで極軸調整をしたら、誤差は0と出ます。この誤差がなく、赤経体が最初上を向いている状態を初期状態としてはじめます。
  1. 最初極軸に誤差がない状態から、SharpCapの極軸測定中に90度赤経体を西側に回転させたときにたわみが発生したとします。簡単のために、鉛直方向に鏡筒が傾き、視野が1度角下を向いたとします。
  2. このときSharpCapは極軸が元々1度ずれていたのか、それともたわんだ結果1度角ずれて見えているのか分からないため、とにかく極軸が1度ずれていると表示してしまいます。
  3. そこで人間が赤道儀の仰角を1度(間違えて)上げることでSharpCapは正しく極軸が設定されたと勘違いをします。でも現実にはこの時点ではSharpCapも人間も本当は極軸が間違っていたのか、たわみでずれたのか知る由はありません。
さて、この90度回転している状態で、再度極軸調整を最初からやり直します。
  1. 鏡筒はまだ下に1度角ずれたところを見ていますが、SharpCapはそんなことは知りませんし、お構いなしです。
  2. 再び赤経体を90度戻す方向に回転させると、今度は鏡筒のたわみが解消され元の位置に戻ります。
  3. そのとき、西側に倒していたものを戻したので、鏡筒は東側にたわみが1度角戻る方向に動きます。
  4. SharpCapは最初の鏡筒の位置のズレなどお構いなしなので、最初から見て視野が1度東にずれたことのみを認識します。すなわち極軸が東1度ずれていると表示するわけです。
  5. と、同時に1回目の調整で勘違いして赤道儀を上に1度角ずらしてしまっているので、そのズレも検出されます。そのため、SharpCapは東と上方向に極軸が1度角ずれていると認識します。
2度目の測定で出た結果のズレは元々たわみから来ているので、たわみのずれの量そのものと比例しているというわけです。

最初極軸が理想的にあっている状態から考えましたが、もし1度目の極軸調整の前にもともと極軸がずれていたとしたらどうなるでしょうか?それでも1度目の調整を終えた後は「極軸があった状態+たわみでずれた位置」になるので、2度目の調整時のはじめには同じ状態になりますね。


イメージしにくい場合

上の説明を読んでもなかなかわかりにくいと思います。まずはSharpCapでの極軸調整(ちょっと古い記事ですがリンクを張っておきます。)を一度試してみて下さい。これをやらないと何を言っているのかよく分からないと思います。

その上で、90度赤経体を回転させたときに、たわみの代わりに赤緯体をコントローラーで例えば1度角落とす方向に回転させることを考えてみて下さい。その赤緯体の回転を補正するように、赤道儀全体の向きを変えるというようにイメージするとよくわかるかもしれません。

赤経体を90度戻すときも、先ほど赤緯体を1度角落としたのをコントローラーで戻してやると考えるとわかりやすいと思います。


他の方向のたわみの例

他のたわみの方向も同様に考えてみます。
  • もし最初に赤経体を90度西側に傾けたときに、たわみが西側(外側)に1度でるなら、それを補正するように東に赤道儀を1度間違って調整し、2度目の極軸調整で90度戻すときに上に1度角たわみが戻るのを下向きに補正するので、東の下向き方向に極軸がずれていると表示されるはずです。
  • 赤経体を西に回転させたときに、たわみが東側に起きることもあるでしょう。
  • 視野を考えているので、もしかしたらたわみ(見ている方向が)が上向きに動くことも可能性としてはあるでしょう。

全部の場合を書き出してみる

全部の場合をまとめて書いておきます。

赤経体を西に回転させたとき
  • たわみが下向き -> 東上向きのズレになる
  • たわみが西向き -> 東下向きのズレになる
  • たわみが東向き -> 西上向きのズレになる
  • たわみが上向き -> 西下向きのズレになる

赤経体を東に回転させたとき
  • たわみが下向き -> 西上向きのズレになる
  • たわみが西向き -> 東上向きのズレになる
  • たわみが東向き -> 西下向きのズレになる
  • たわみが上向き -> 東下向きのズレになる
となります。


一般化

簡単な数学で考えてみます。今、東のズレと西のズレをそれぞれ右のズレと左のズレと考えると、赤経体を西に回転させたときは、「たわみからSharpCapでのずれ」の変換が+135度の回転写像、赤経体を東に回転させたときは「たわみからSharpCapでのずれ」の変換が-135度の回転写像と考えることができます。

一般化すると、SharpCapで最初の極軸調整で90度赤経体を進めて、2度目に90度戻してたときの誤差を(x2, y2)とすると、たわみによってずれた角度(x1,y1)は

x1 = x2 cosθ - y2 sinθ
y1 = x2 sinθ + y2 cosθ

となる。θは赤経体を西に回転させたときは+135度、赤経体を東に回転させたときは-135度である。ただし、赤経体を元の位置に戻したらたわみは戻るものと仮定する。

ということが言えます。

ちなみにsin135°=1/√2、cos135°=-1/√2なので、

x1 = -1/√2 (x2 + y2)
y1 = 1/√2 (x2 - y2)

となります。


現実的には

でもこのままだとちょっと計算が面倒なので、簡単のためにもっと現実的な場合を考えましょう。基本的にたわみはほぼ垂直方向にのみ起こると考えってしまって差し支えないと思います。なので、x2とy2の絶対値はほぼ同じような値になると期待できます。SharpCapの2度目の極軸調整で出てきた誤差のx2かy2のどちらかの値を√2 = 1.4倍くらいしてやった値が実際のたわみと考えてほぼ差し支えないと思います。

もしx2とy2の絶対値に結構な差があるならば、たわみに横向きの成分があることになります。

まじめに計算してもいいのですが、もし更なる測定を厭わないならば、最初に西向きに赤経体を回転させて2度測定したならば、次は東向きに赤経体を回転させてさらに2度測定します。東向きの誤差の結果をx4、y4とすると、(もし横向きのたわみが西に回転させたら西に、東に回転させたら東に出るならば)
  • x2とx4は逆符号で、絶対値は似たような値
  • y2とy4はどう符号で絶対値は似たような値
になるはずです。なので、x2+x4は0で、
  • (x2-x4)/2が横方向のたわみを表し
  • (y2+y4)/2が縦方向のたわみを表します。
一番厄介なのが、もし横向きのたわみが西に回転させたら西に、東に回転させても西に出る(多分レアな)場合で、これはどうしようもないです。向きだけでなく、たわみの大きさも違う可能性があり、東向きと西向きを測定し、真面目に計算する方が早いです。まあ、そもそも横方向のたわみを相手にすること自身稀だと思うので、こんなのはホントにレアなケースだと思いますが。


任意の回転角のたわみ量

今回の結果は赤経体を90度傾けた時のたわみ量です。90度以下の場合はφにたわみを知りたい赤経体の角度を入れてcosφを上の結果にかけてやればいいいと思います。


赤緯体の場合

でも今回求めたのは、今回は赤経体の角度が変わった時のたわみ量だけなんですよね。赤緯体が回転した時のたわみ量はSharpCapを使う今回の方法では全く太刀打ちできません。赤緯体の方でまたいいアイデアがあったらブログに書きます。


まとめ

とりあえず頭の中でざっくり考えただけなので、もしかしたら何か勘違いしてるかもです。一度実際のSharpCapを使って、夜に赤緯体の回転をたわみとして試してみようと思います。

ラッキーイメージの過程で、M87を撮影して見ました。M87といえば...

目的はもちろんジェットを見ることです。

さてさて、うまく見えるのでしょうか?


SharpCapでのディザー

実際の撮影は前回のラッキーイメージNGC4216の後に続けて撮影しています。なので設定は全く同じで、10秒露光を30回LiveStackして、今画像を見たら10枚撮影していたので、合計50分でした。

前回書くのを忘れましたので、今回改めて書いておきます。SharpCapの最新ベータ版を使っていますが、ディザー対応がかなり改善されています。

一番大きいのがLiveStackパネルのguidingタブのところに「Reduce Exposure While Dithering 」とうオプションができたことです。これはPHD2などとの連携でディザーをしている間は露光時間を短くするという意味で、以前はDhitherの間も露光し続けていたので、例えば5分間の露光とすると、ディザーが終わっても最大5分近く待たなければならず、まるまる1枚は必ず無駄になっていました。撮影毎にディザーしていたら、撮影時間の最低半分はディザーに取られてしまっていたので、ほとんど使い物にならなかったのです。

そのため、SharpCapでディザーは実質やる気にならず、結果SharpCapは長時間露光は向いていない、もしくはできないという結論でした。今回のオプションで、SharpCapにも長時間露光での撮影に道が開いたことになります。

今回のLiveStack撮影でも、ディザーは使っています。ディザーを15分毎にするように設定しているために、(10秒x30ライブスタックを)3枚撮影するたびにディザーが適用されます。でもディザー量を試しに減らしたため、揺れ幅が不十分で、縞ノイズが少し出てしいました。


画像処理と結果

今回は鑑賞目的というよりは、少し科学写真に近くなりますので、画像処理はほとんど凝ったことはしてません。ダーク補正はLiveStack中にリアルタイムでしてます。WBPPではフラット補正のみで、バイアス補正もなし、ダーク補正もなしです。あとはストレッチと、一度トーンカーブで暗いところを持ち上げて暗いでしょうか。あ、恒星の色を出すために少しだけ彩度を上げています。


「M87」
masterLight_ABE_ABE_ABE_AS_HT2
  • 撮影日: 2021年4月11日0時49分-4月8日1時45分
  • 撮影場所: 富山県富山市
  • 鏡筒: Vixen VC200L
  • フィルター: なし
  • 赤道儀: Celestron CGEM II
  • カメラ:  ZWO ASI294MC Pro、-10℃
  • ガイド: f120mmガイド鏡 + ASI120MM mini、PHD2によるマルチスターガイドでディザリング
  • 撮影: SharpCap、gain420、露光時間10秒x30枚のライブスタック x10枚 = 50分、ダークは10秒x64枚をライブスタック中にリアルタイムで補正、フラット128枚(gain420、露光0.78ミリ秒)、フラットダーク128枚(gain420、露光0.78ミリ秒)
  • 画像処理: PixInsight、Photoshop CC


でも困ったことに、JPEGに落とす時点でM87の周りの淡いところの諧調が制限されてしまい、階段上になってしまいます。あと撮影中に少したわみで流れたみたいで、ディザーであまり散らしてなかったので明るくすると縦の縞ノイズが少し出ていました。

さてさて、ジェットは見えてますでしょうか?拡大してみます。

masterLight_ABE_ABE_ABE_AS_HT3_cut

おおー、右上にはっきり見えてますねー!上が北なので、方向から考えてもジェットで間違いなさそうです。不思議なのは、切り出すとJPEGでも諧調が飛ばないことです。そこそこきれいに見えてますね。自分で撮影したものだと、感動もひとしおです。

6000万光年先の銀河で、ジェットの長さは7-8000光年におよぶそうです。ご存知の通り、2019年に超長基線の電波干渉計によりM87の姿が映し出されました。リング形の中心にブラックホールが存在すると考えられています。このリング中の黒いところは直径1000億km程度なのですが、これがそのままブラックホールというわけではなく、事象の地平線は直径400億kmでもっと小さいと考えられているそうです。



ついでにアノテーションです。ここにもそこそこの数の銀河があります。

masterLight_ABE_ABE_ABE_AS_HT2_Annotated

少し斜めになってしまっています。これは前々回の記事の最後に書いた、鏡筒バンドに対してまだ鏡筒の回転方向を合わせ切らずに撮影してしまったからです。実際にはこのM87で回転が残っているのに気付いて、この撮影の直後に直しました。


M87といえば

M87といえば、M87JETさんを真っ先に思い出します。胎内星まつりで初めてお会いしたのですが、当時からほしぞloveログを読んでいてくれて、興奮気味に自分で撮影したM87のジェットを見せてくれした。ペンネームをそのままM87JETとしようと思っている」と、その時お聞きしました。その後は小海の星と自然のフェスタでも一緒に食事したりしてました。いつも面白い文体のブログ記事を書いていて、最近はISSの追尾でご活躍されています。



M87JETさーん、やっと私もジェットを取ることができましたよ!


 

このページのトップヘ