PixInsighのメジャーアップデート時には、基本的にはほとんどのモジュールは自動的に再インストールされるのですが、星消しで使うStarNet V2だけは、毎回消えてしまって、手動で再インストールする羽目になります。

最近のStarNet V2のインストールは、継続インストールと新規インストールの2つの方法があるようです。以前はPixInsightのメジャーアップデートのたびに継続でインストールしていて、マニュアルにも間違いがあったりして結構面倒なので、このブログでも正しいと思われるインストール方法をお知らせしてきましたが、今後も継続だと面倒そうなので、今回はPixInsightを1.8.9から1.9.2にアップデートするにあたり、StarNet V2を新規でインストールしました。



まず、ここでの話はMacのみなので、Windowdでは一部通用しないことがあるのに注意してください。このページのメニューのDownloadから、今回は新規インストールパッケージをダウンロードします。





です。ダウンロード後、ダブルクリックして解凍してください。パッケージといっても、インストーラーがついているわけではなく、基本は手動インストールなのはかわりません。

インストール方法はいくつか注意が必要ですが、英語でわかりにくいかもしれませんので、ここに分かりやすく書いておきます。



ZIPファイルの中のREADME.txtを読んでみます。まずは「INSTALLATION」です。


とありますが、上で示したように2つのライブラリをきちんと/Applications/PixInsight/PixInsight.app/Contents/Frameworks/内にコピーしないとそもそも、PixInsightのメニューから「Process -> Modules -> Install Modules」で下にある「Serach」ボタンを押しても、StarNetのモジュールがうまく検索されません。

上記コピー操作をきちんとすると、きちんと検索されるはずなのですが、さらにここで注意です。検索結果が出てきたら何も考えずに下の「Install」ボタンを押してください。（私は試してませんが）下手に出てきたモジュールを選択したりすると、インストールに失敗するそうなので、その場合はPixInsightを一度閉じて、立ち上げ直してもう一度検索からやり直してみてください。



StarNetは毎回面倒なので、自分のメモがわりに記事にしておきました。手間を省くためにも、いい加減有料のStar XTerminatorにしようかとも思っていますが、とりあえずうまくいったのでまた今回もスキップして、StarNetを使い続けることになってしまいそうです。

恒星分離の性能に関しては、StarNet V2であまり不満はないので、無料でこのようなソフトを提供してくれている作者様に対しては、ものすごく感謝しています。

タグ ：

#StarNetV2

#PixInsight

#アップデート

前回記事でSWAgTiのディザー撮影ができたことを書きましたが、書ききれなかったこともあるので、少し補足します。

タグ ：

#SWAgTi

#RedCat51

#Uranus-CPro

#SPCC

#iHDR

#PixInsight

#DBP

M106の再画像処理の記事を公開後、Twitter上でかなり熱い議論が交わされました。LRGB合成についてです。LRGBってもっと単純かと思っていたのですが、実際にはかなり複雑で、議論の過程でいろんなことがわかってきました。





詳しくは上の記事を見てもらえるといいのですが、今回の撮影ではRGBの露光時間がLに比べてかなり短くノイジーでした。そこで検証したのが、LRGBの際のLとRGBの比率をどうすればいいかという点です。 

M106の再画像処理のLRGB合成の過程で、Lの比率を上げると分解能は良くなっていく傾向でした。その一方、合成直後の彩度は落ちてしまいます。それでも色情報がなくなったわけではなく、たんにかくれているだけで、その後に彩度を上げていくと色が出てできます。ただし、色が出ると同時に短時間露光のせいかと思いますが、ノイジーになっていきました。

この時点でLとRGBの比率をどうすべきかわからなくなったので、LRGB合成の代わりにRGB画像をLab分解し、Lを入れ替えるという手段を取りました。この方法の利点は、RGBがノイジーな場合にabの分解能を落としてカラーノイズを減らすことが独立してできるということです。これは人間の目が色に対する分解能があまりないということを利用しています。

今回は上記のように試してみましたが、結局のところLRGBもLab変換も、まだ全然理解できていないことがよくわかりました。



その後、TwitterでNIWAさんが反応してくれて、その後botchさん、だいこもんさんも交えてかなりの議論がなされました。

と言っても私は「わからない、わからない」と吠えていただけで、基本的にはNIWAがいろんな有用な情報を提供してくれたというのが実情なので、まずはNIWAさんに感謝です。botchさんはさすが長年この界隈にいる方なので、何が問題か本質的理解されているようでした。だいこもんさんはとてもわかりやすい説明をしてくれました。



NIWAさんからの最初の有用な情報はPixInsight forumのJuanさんの発言(スレッドの#2,3,7)でした。



NIWAさんがこのページをもとに日本語でまとめてくれているので、英語が辛い場合はここを読むといいかと思います。



Juanさんの言う大事な主張は、

• RGBはリニアでやっていいが、LRGBはノンリニアで処理しなければならない。

ということです。理由は

• CIE L*a*b*とCIE L*c*h*はノンリニアカラースペースであり、それらがLRGB合成するために使われているから。

ということなのですが、最初この意味が全くわかりませんでした。そもそも私はLRGB合成はリニアのうちに処理してしまっていて、今のところ何か不具合のようなものは何ら感じていなかったからです。ここでいう「ノンリニア」というのはどうも「ストレッチ」というのと同義らしいので、このまま受け取ると

• LRGB前に全てRもGもBも、当然Lもフルストレッチしきっていなければならない。

とも受け取れます。これはかなりきつい制限で、できるなら私は早いうちに合成してしまって、まとまった画像で色と解像度のバランスを見ながら処理したいのです。しかも、上記のように理由が挙げられていますが、この意味が全くよくわかりません。



そもそも、PixInsightのLRGBCombinationが実際どんなアルゴリズムで実行されているのか、どこにも情報がありません。NIWAさんからという説明があり、LRGB合成のなかみを推測する材料などが提供されたりしましたが、やはりリニアとかノンリニアに関することを含めてブラックボックスに近い状態です。


そこでbotchさんがTwitterで

• 「ほとんどの場合で、使うRGB画像の質が相対的に悪いので、強い後処理を行うとアラがでます。そもそもLとabが一致していないので。RGB画像とそれをモノクロ化した画像を扱っているのではない点を考えてみてください。」という発言と
• 「んー、LRGBって非可逆ですよね。」という意見を言ってくれたのですが、この時点でも私はまだほとんど理解できていませんでした。

私が返した

• 「Lab変換して、L画像を置き換えてLab合成し、それをまたLab変換して元のL画像に置き換えたら、元の画像に戻ると思っていたのですが、何か間違ってますでしょうか？」に対して、
• botchさんが「Lを置き換えて、もう一度Lを置き換えるだけでなら同じです。samさんの「それをまたLab変換」と言う部分はその前にRGBになどに変換している事になるので、そうなると元には戻りません」というところで、だんだん理解できて
• 「違うLとLab合成した段階で、次にLab変換で分離したaとbには違うLの情報が混じり、最初のabとは違うものになるという理解でいいでしょうか?これが正しいなら確かに不可逆です。」と答えましたが、まだこのことがリニアな画像にLRGB合成を適用してはダメな理由には結びつきませんでした。

ここでだいこもさんがものすごくわかりやすい説明をしてくれました。

• 「リニアのRGB画像から抽出したモノクロ画像をLc、Lフィルターで撮影したリニア画像をL、と呼ぶことにする。LcはRGBをストレッチして得られているのでノンリニア画像であるというのがまず前提です。それで、フィルターの性質上LcとLは輝度が違うので、そのままLRGB合成すると色が薄くなったりして良好な色が得られません。そこで例えばLinearFitをつかって輝度をそろえる必要がでますが、それをやってLcとLをそろえるとそれぞれノンリニアとリニアなので、うまく輝度がそろわない。そのような理由で、結局はLにノンリニアなストレッチを施して、Lcとヒストグラムを一致させてからLRGB合成すると上手く行くという話になるのだと思っています。」

素晴らしい説明で、これでやっとなぜJuanさんがノンリニアと言っているかが理解できてきました。要するに

• LとLcの輝度を合わせることをノンリニアと言っているに過ぎないということです。

botchさんの最初の説明も本質的に同じことを言っているのだということがわかりました。だいこもさん、ありがとうございました。

でもこの考えも実際にはまだ不十分で、議論はさらに続き、下の「ノンリニアの本当の意味は？」でさらに明らかになります。



だいこもんさんはさらに

• 「ただし、画像依存はあってリニアなままLRGB合成しても破綻なく上手く行くこともありました。」

と述べているのですが、こちらは私の経験とよく合います。最初から輝度がそこそこあっていればリニアなままでもいいかもですが、それは特殊なケースなのかと。

では、LRGB合成をリニアでやったら現実的には何が問題になるかというと、NIWAさんが

• 「リニアでやると輝星に原色のノイズが出ることがよくあります。一番明るい部分が例えば階調なく原色で青く塗り潰されるような現象です。発生メカニズムは不明ですが『明るいLに対して対応できるRGBの組み合わせがなくて、破綻して原色になってしまった』と言うように見えます。」

と具体例を述べてくれています。さらにだいこもんさんがPIのメニューのSCRIPTS>Utilities>LinLRGBに今回の問題に対応するようなスクリプトを見つけてくれました。

• 「単純にLRGB合成すると星が破綻する画像でも、これを使ったら破綻しませんでした」とのことなので、リニアで処理してもうまくいくのかもしれません。
• 「スクリプトの中身見てみたら、カラー画像をHSI分解して、IをLと入れ替えているだけのようです。そうすると星の破綻も起きませんでした。」

とのことなので、リニアでもうまくLを入れ替えることができるのかもしれません。

リニアで色がおかしくなる事は私も前回のM106の処理中にありました。これはLがRGBより暗い部分で起こるようです。私の場合はLを少しストレッチしてRGBより明るくすると回避できました。

NIWAさんからもう一つJuanさんが発言されているスレッドの紹介がありました。ここでもあからさまにRGBはリニア、LRGBはノンリニアと言っています。



Juanさんが#5の最後で言っているのは、ここまで議論していた「入れ替えのLの輝度を合わせるストレッチをすることをノンリニアという」ということに近いかもしれません。でもまだ別の意味の気もします。

このことは次で明らかになったのかと思います。



上の疑問に関して、

• だいこもんさんの「LcはRGBをストレッチして得られているのでノンリニア画像であるというのがまず前提」という発言から、
• NIWAさんが「つまりRGBからLを取り出した時点で、ストレッチされてしまうわけですね。」

と非常に重要な発言をされています。NIWAさんが調べたところによると、そのLを取り出すときにガンマ補正が入るようで、根拠は
あと、この議論はあくまで原則論で、実際にどう運用するか、実際の画像処理に影響があるかどうかは程度問題の可能性も十分にあります。本当に正しいかどうかもさらなる検証が必要かと思います。天体写真に対する考え方は人それぞれで、科学の範囲と思ってストイックに考えている方もいれば、趣味として楽しんでいる方もいるのかと思います。たとえこの議論を読んだとしても何が正しいかは自分で判断すべきで、必要ならばこの議論も参考にしてみるというような考え方でいて頂ければありがたいです。


NIWAさんの情報初め、みなさんの議論におんぶに抱っこで、私は疑問を出しまくっているだけでした。本当に皆様に感謝です。こんなまとめをするのも越権かもしれませんが、私自身のメモという意味も兼ねていますので、どうかご容赦ください。でも、こうやってネット上で議論が進んで理解が深まるというのは、とても有意義で、とても楽しいことなのかと思います。皆様どうもありがとうございました。

タグ ：

#PixInsight

#Lab

#LRGB合成

#RGB合成

#linear

#nonlinear

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




前回はSPCCまでで、モノクロ撮影でBaaderフィルターを選んだらうまく補正ができたという話でした。今回は主に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アニメにしてみました。

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

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

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



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

Original:

BXT (恒星の縮小のみ):

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

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



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

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

Original:

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

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



でもですね、結局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に渡したので、かなり楽でした。


恒例のAnnotatonです。

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

まずは以前のもの:

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



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

タグ ：

#SA260

#ASI294MMPro

#NoiseXterminator

#BlurXTerminator

#ゴースト星雲

#Sh2-136

#PixInsight