ほしぞloveログ

天体観測始めました。

カテゴリ: software

連休中にε130Dのテスト撮影をしているのですが、その画像処理の過程で面白いことがわかりました。このネタだけで長くなりそうなので、先に記事にしておきます。


最初に出てきたε130Dの分解能にビックリ!

今回ε130Dで初の撮影を進めています。満月直前で明るいので、ナローバンド撮影です。初めての機材なので色々トラブルもありますが、それらのことはまた次の記事以降で書くつもりです。とりあえず2日かけてなんとか約2時間半分のHα画像を撮影しました。細かく言うと、ASI6200MM Proのbin1で1時間ぶん、かなり暗かったのでその後bin2で2時間半分撮影しました。

その後、まだ仮処理段階のbin2のHα画像を見てびっくりしました。bin2撮影の2時間半ぶんをインテグレートして、BlurXTerminator(BXT)をかけて、オートストレッチしただけですが、なぜかわからないレベルのすごい分解能が出ています。下の画像はペリカン星雲の頭の部分を拡大して切り出しています。

BIN_2_4784x3194_EXPOSURE_300_00s_FILTER_A_ABE_Preview01

昔FS-60CBとEOS 6Dで撮ったものとは雲泥の差です。
283e6bd1_cut

分解能の理由の一つ

ちょっとビックリしたのでTwitterに速報で流してみたのですが、かなりの反響でした。分解能がいいと言われているε130DにモノクロCMOSカメラなので、ある程度分解能は出ると予想していましたが、予想以上のちょっとした魔法クラスです。

その後、画像処理がてらいろいろ検証を進めていたのですが、魔法の原因の一つは少なくとも判明しました。ちょっと面白いので検証過程を紹介しつつ、謎を解いていきます。


意図せずして高解像度に...

まず、今回大きなミスをやらかしたことです。テスト撮影ではbin1とbin2の2種類を撮ったのですが、それらの画像をPixInsightで同時に処理していました。2種類のマスターライト画像が出来上がるわけですが、ここで問題が起きていたことに後に気づきました。

reference画像をオートで選択していたのですが、そこにbin1のものが自動で選択されてしまっていた
のです。その結果、bin2の低解像度のものもregistration時に強制的にbin1のものに合わせられてしまい、高解像度になってしまっていました。その状態に気づかずにBXTをかけてしまい、予期せずして恐ろしい分解能の画像になっていたというわけです。

その後、気を取り直し再度普通のbin2画像を処理して比較してみると、いろいろ面白いことに気づきました。メモがわりに書いておきます。


1. BXTのPFSの値と解像度の関係

まず、BXTのパラメータですが、恒星の縮小とハロの処理は共に0としてしないようにしました。背景の青雲部の詳細を出すために、PSFを7.0にしてSharpen Nonstellerを9.0にします。

これをbin1画像に適用してみます。この中の一部をカットしたのが以下です。最初の画像と同じものです。少し出しすぎなくらいのパラメーターですが、まあ許容範囲かと思います。

BIN_2_4784x3194_EXPOSURE_300_00s_FILTER_A_ABE_Preview01

これをそのまま同じBXTのパラメーターでbin2画像に適用してみます。明らかに処理しすぎでおかしなことになっています。許容範囲外です。
bi2_bad_BXT_BIN_2_4784x3194_300_00s_FILTER_A_Preview01

次に、bin2画像は解像度が半分になっていることを考慮し、PSFを7.0から3.5にします。するとbin1でPSF7.0で処理した程度になります。これをbin2画像に適用します。

bin2_good_BXT_BIN_2_4784x3194_300_00s_FILTER_A_Preview011

bin1にPSF7.0で適用したのと同じくらいの効果になりました。これでbin1とbin2に対するBXTの効果が直接比較ができるようになったと考えることができます。

このことはまあ、当たり前と言えば当たり前なのですが、BXTのPSFは解像度に応じて適時調整すべきという教訓です。もちろんオートでPSFを決めてしまってもいいのですが、オートPSFはいまいち効きが悪いのも事実で、背景の出具合を調整したい場合はマニュアルで数値を入れた方が効果がよく出たりします。


2. referenceで解像度が倍になったのと、drizzleで2倍したものの比較

referenceで解像度が倍になったのと、drizzleで2倍したものの比較をしてみました。これはほとんど違いが分かりませんでした。下の画像の左がreferenceで解像度が倍になったもの、右がdrizzleで2倍にしたものです。かなり拡大してますが、顕著な差はないように見えます。
comp1

これにBXTをかけた場合も、ほとんど違いが分かりませんでした。同じく、左がreferenceで解像度が倍になったもの、右がdrizzleで2倍にしたものです。
comp2

この結果から、わざわざbin1を撮影してフィットとかしなくても、bin2でdrizzleしてしまえば同様の分解能が得られることがわかります。


drizzleで2倍にしてBXTをかけた場合

次に、bin2で撮影したものと、bin2で撮影したものをdrizzleで2倍にした場合を比べてみます。左がbin2で撮影したもので、右がbin2をdrizzleで解像度を2倍にしたものになります。左のbin2の拡大はPhotoshopで細部を残しすようにして2倍にしましたが、やはり一部再現できてないところもあるので、もと画像を左上に残しておきました。
comp1b

それでもちょっとわかりにくいので、PCの画面に出したものをスマホで撮影しました。こちらの方がわかりやすいと思います。左がbin2で撮影したもので、右がbin2をdrizzleで2倍にしたものです。(わかりにくい場合はクリックして拡大してみてください。はっきりわかるはずです。)
658E3BF1-9F61-4E65-BAE0-340184B9DC67

ぱっと見でわかる効果が微恒星が滑らかになることです。ですが、背景に関してはそこまで目に見えた改善はなさそうに見えます。

ところが、これにBXTをかけた場合、結果は一変します。明らかに2倍drizzleの方が背景も含めて分解能が上がっているように見えます。(と書きたかったのですが、どうも画像を2倍に大きくするときにやはり補正が入ってよく見えすぎてしまい、右とあまり変わらなく見えます。ここら辺がブログでお伝えできる限界でしょうか。実際には左上の小さな画像と、右の画像を比べるのが一番よくわかります。)
comp2b

同じくわかりにくいので、これもPCの画面に出したものをスマホで撮影しました。左がbin2で撮影したもので、右がbin2をdrizzleで2倍にしたものに、それぞれBXTかけています。
27718827-C94A-4A1D-B101-0A9F619FC62F

この右のものは、最初に示したbin1画像を参照してしまって予期せずして解像度が倍になった場合の結果とほぼ等しいです。

どうやら「BXTは画像の解像度を上げてから適用すると、背景の分解能を目に見えてあげることができる」ということがわかります。解像度を上げたことで情報をストックする余裕が増えるため、BXTで処理した結果をいかんなく適用保存できると言ったところでしょうか。言い換えると、BXTが普通に出す結果はまだ表現しきれない情報が残っているのかもしれません。これが本当なら、ちょっと面白いです。


分解能が増したように見える画像を、解像度2分の1にしたらどうなるか

では、解像度増しでBXTで分解能が増したように見える画像を、再度解像度を半分にして元のように戻した場合どうなるのでしょうか?比較してみます。左が1で得た「bin2にBXTをPSF3.5で適用した画像」、右が「一旦解像度を増してBXTをかけ再度解像度を落とした画像」です。

comp2c

結果を見ると、そこまで変化ないように見えます。ということは、解像度自身でBXTが出せる分解能は制限されてしまっているということです。

ここまでのことが本当なら、BXTの能力を引き出すには、drizzleで画像自身の解像度を上げてからかけたほうがより効果的ということが言えそうです。


まとめ

以上の結果をまとめると、
  • drizzleは適用した方が少なくとも微恒星に関しては得をする。
  • BXTと合わせると背景でも明らかに得をする。
  • drizzleして分解能を上げるとBXTの効果をより引き出すことができる。

ただしこのdrizzle-BXT、拡大しないとわからないような効果なことも確かで、そもそもこんな広角の画像で無駄な分解能を出して意味があるのかというツッコミも多々あるかと思います。それでも系外銀河など小さな天体にはdrizzle-BXTは恩恵がある気がします。まあ取らぬ狸の皮算用なので、小さな天体で実際に検証してから評価するべきかと思います。

今回の効果はおそらく意図したものではないと思いますが、BXT ある意味すごいポテンシャルかと思います。ここまで明らかに効果があると思うと、過去画像もdrizzleしてもう少しいじりたくなります。

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




M106での画像処理

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

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

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

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


Twitterでの議論

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

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


PixInsight forumの解説、でもよくわからない

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


ノンリニアとはLの輝度合わせ?

そもそも、PixInsightのLRGBCombinationが実際どんなアルゴリズムで実行されているのか、どこにも情報がありません。NIWAさんから
  • パラメータ調整無しの場合、LRGBCombinationとChannel CombinationのLabのL入れ替えは同じ。
  • RGBからのL画像とL画像を50%ずつブレンドしたLによるLRGBCombinationと、Weights 0.5のLRGBCombinationは同じ。
という説明があり、LRGB合成のなかみを推測する材料などが提供されたりしましたが、やはりリニアとかノンリニアに関することを含めてブラックボックスに近い状態です。

その後、Juanさんの発言の#11を読み込んでいくと、luminance transfer functionとchannel weightsが何を意味するのか、少しわかってきました。本来は適用するLと、適用されるRGB画像のLが同じ輝度とバックグラウンドというのを前提としているようです。

そこで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合成しても破綻なく上手く行くこともありました。
と述べているのですが、こちらは私の経験とよく合います。最初から輝度がそこそこあっていればリニアなままでもいいかもですが、それは特殊なケースなのかと。

では、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を取り出すときにガンマ補正が入るようで、根拠は
だとのことです。要するに、
  • リニアなRGB画像だったとしても、そこからLを引き出しただけでノンリニアなL画像になってしまう
というのが本質のようであり、ある意味今回の結論になります。


まとめてみると

これまでの議論が正しいなら、
  1. RGB合成まではリニアなのでストレッチなどする必要はないが、LRGB合成はノンリニアになる。
  2. 具体的はRGBからLを引き出す際にノンリニア処理になるので、それ以降はリニアな処理はしない方がいいということが重要。
  3. 言い換えると、R、G、Bに関しては事前にストレッチしておく必要はない
  4. LRGB合成する際のL画像も事前に必ずしもストレッチしておく必要はないが、RGBから引き出したL画像と同じ輝度レベルにした方がいい。例えばL画像がリニアなままでは恒星の色が破綻することがある。
  5. LinLRGBなどでHSI分解してIとLを入れ替えると破綻しにくくなる(要検証)。
ということが、ある程度のまとめとして言えるのかと思います。

個人的に重要視したかった「ストレッチのタイミング」ですが、少なくとのR、G、Bに関してはストレッチは合成後でいいことがわかったので、最初に言っていた「LRGB合成前に全てRもGもBも、当然Lもフルストレッチしきっていなければならない」というかなりきつい制限は相当緩和されるという結論になったかと思います。

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

今回はLabのノンリニア性とか、まったく意識していなかったことがたくさんありました。まだまだ学ぶことが多いです。NIWAさんが参考ページを教えてくれました。

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


EAF(電動フォーカサー)を使ったNINAのオートフォーカスはものすごく便利です。うまくいくとかなり正確にピンと位置を合わせることができます。でもうまくいっていない方も多いみたいなんですよね。私もL画像撮影時だとそこそこうまくいっていますが、Hαとかの暗くて恒星が少ない場合ではあまりうまくいかなかったりしています。

今回、M106の撮影時と次のM51の撮影時に、だんだん誤差が大きくなってきて、ある時からNINAのオートフォーカスが全くうまくいかなくなったのです。その原因を探りました。


Hアルファの場合

特に暗くなってしまうHα撮影時のオートフォーカス調整では、元々そこまで上手く測定できていたわけではなく、典型的にはこんな感じで最初の右端の2つくらいは星像の大きさが0と検出されてしまっていました。

A_original

ところが、ある時からこんなふうに星のサイズHFRが真ん中も含めて全然測定できなくなってしまったのです。

A_bad


何が問題だったか

何をしたかなあ?と思い出してみると、撮影中にオートストレッチのパラメータを触っていたことに気づきました。

オートストレッチは、撮影時のNINAの「撮像」タブの「画面」の見栄えを調整します。見やすくなるように、ちょくちょくいじっていて、その過程で星像の認識率が悪くなっていったようです。特に今回はM51の撮影中のある時に、見栄えを大きく変えたことが原因でした。

調整場所は、下の画面の右の真ん中らへんの詳細設定を開けた「自動ストレッチ因数」と「ブラッククリッピング」です。
stretch

撮像画面での見やすさと、星像を評価するHFRの最適値は結構違っていて、オートフォーカスはこのHFRを元に評価していることが原因です。どの値がいいのかは機材によって違うと思いますので一概には言えませんが、私は上の画像くらいの設定値にして、下の画面のように背景がそこそこ暗くなるくらいのストレッチになった時の方がHFRには適しているように思いました。

キャプチャ

改善の様子は、真ん中右の方の緑と黄土色のグラフを見てもらえばわかるかと思います。横軸は撮影枚数、縦軸の緑線がHFRで星像の大きさを示し、黄土色の線が検出できた星の数を示します。最初そこそこ安定して測定できていたのが、途中4枚目あたりでストレッチのパラメータを変えたのでグラフがぐちゃぐちゃになり、18枚目あたりで再度調整してからは星像の大きさがピタッと安定し、検出できた星の数も増えています。

でもグラフがぐちゃぐちゃの場合でも、これはストレッチした見掛け上の炙り出しでそくていしているだけなので、実際の画像には何ら影響していません。ただしこのぐちゃぐちゃした時のように、HFRがうまく測定できない場合にオートフォーカスをすると、上手くフォーカスが合わなくて実画像がピンボケになったりします。もっと言うと、オートフォーカス時にHFRが全く測定できない場合は元のフォーカス位置に戻るからまだいいのですが、中途半端に測定できてしまうと誤差が大きいピント位置決めになってしまい、撮影に大きな影響が出ることになります。

さて、オートストレッチをHFRに合わせて上手く調整できた時は、測定しにくかったHαの場合でも以下のように改善されました。オートフォーカスパラメータ以外は全く同じ設定です。

A_good

理論曲線からまだ少し形がずれてますが、はるかに綺麗に測定できているのがわかるかと思います。

調べている限り、日本語でNINAのオートフォーカスについて解説しているページでは、ステップサイズやバックラッシュについては言及していますが、オートストレッチに大きく依存するという記事は見つかりませんでした。これまでオートフォーカスがどうしても上手くいかなかったという方は、一度ストレッチパラメータをいじるのを試してみるといいかと思います。

でも英語も含めてよく調べると、なんとこのことNINAのマニュアルページにサラッと書いているんですよね。


長いページですが、真ん中近くの「Important considerations」あたりのところです。英語ということもありますが、それを差し置いてもサラッと書きすぎで、日本語だっとしてもそのまま読み飛ばしてしまいそうです。


Lフィルターの場合

ちなみに、Hαでなく測定しやすいL画像のオートフォーカスの場合、私の環境では毎回下のような結果になります。

L_typical

オートフォーカスとは関係なく、それどころか何をどう設定しても、必ず一番右が少し下がってしまい、フィッティングによる最適値が少し右にずれてしまいます。今のところ解決策は見つかっていません。オフセットを調整すると直るという話も聞いたことがあるのですが、色々試しましたが解決には至っていません。

でも実はこの解決策もマニュアルにサラッと書いてありました。かなり下の「Backlash IN/OUT」のすぐ下に、あまり目立たなく書いてあります。私はバックラッシュの設定は既にオーバーシュートにしてある(自分でも試しましたが、これが一番安定です)のですが、オーバーシュートにする場合はバックラッシュの値を片方だけに書き込むのが必須のようです。この情報は知らなかったので、次回の撮影の時に試してみようと思います。



BlurXTerminator (BXT)を使った、過去画像の再処理の第3弾です。

第1弾は三日月星雲、第2弾は青い馬星雲でした。



三日月星雲は主に星雲本体、青い馬星雲は主に恒星の収差の改善でしたが、今回もすごいです。


トールの兜星雲

今回のターゲットは、NGC2359: トールの兜星雲です。昨年1月に撮影しているので、1年ちょっと前になります。


SCA260で撮影していますが、この時はまだ、今使っている大型赤道儀のCGX-Lではなくて、もう一つ小さいCGEM IIに重いSCA260を載せています。そのため、今見ると3分露光でも揺れの影響が残ってしまっているようで、恒星像が今一ピシッとしていません。これがBXTでどこまで改善できるかがまずはポイントになります。


再処理の途中で

処理をしている途中で、BXTで明るい恒星が崩れる現象が見られました。
Image07_ABE1_DBE_SPCC_BXTbad_NXT_stretch_cut

原因は、元画像の恒星自身が何か歪んでいたことで、よく見ると以前の画像でもその兆候が見られますが、気づいていませんでした。BXTでその歪みが助長されて気づくことができました。BXTといえど全然万能ではなく、元画像がダメな時はどうしようもないです。

ではその恒星の乱れはなんだったかというと、Integrationの時に起こっていて今回はrejectionにWinsorized Sgma Clippingを選んでいたことが原因でした。High側で恒星中心付近がいくつかrejectされていて、非連続になっていたというわけです。今まで気づいたことがなかったので、恒星がおかしい時はrejectionにちょっと気をつけた方がいいかもしれません。

masterLight_BIN-2_4144x2822_EXPOSURE-180.00s_FILTER-HA_mono_cut
明るい恒星の右側がrejectionで不連続になってしまっています。

結局、WBPPでのIntegrationのRejection algorithmをAutoにして解決したのですが、マニュアルでのPreprocdessing からのIntegrationとWBPPのIntegrationでは少し振る舞いが違うようです。マニュアル操作ではそもそもWinsorized Sgma Clippingでも(WBPPのときと同じパラメータにしても)rejectonの度合いはもっと緩やかで、問題が露呈しないレベルで抑えられます。WBPPのWinsorized Sgma Clippingのパラメータをどういじっても解決はできなかったので、諦めてAutoにしたらあっさり解決しました。

それ以外はBXT、NXT合わせて特に困ったことはありませんでした。しかも青い馬星雲の背景出しで相当な時間をかけたので、それがいい練習になっていて、今回の再処理は短時間で終わりました。


結果の比較

結果ですが、以前のものと比べます。まずは以前のもの。背景が暗いので、今回の再処理でもう少し淡いところが出るかもしれないという目論見です。あとはやはりSCA2660とCGEM IIの組み合わせでの揺れのせいでしょう、今見ると恒星の締まりがないのが気になります。
Image07_DBE_PCC_DBE_AS_HTx3_reducestar2_3_crop_mod

次に、今回再処理した結果の画像です。一皮どころか、二皮も三皮もむけた感じです。ちょっとやり過ぎの感もあります。
Image07_ABE1_DBE_SPCC_BXTbad_NXT_stretch2_cut

まず、兜本体の分解能が尋常でないです。これはひとえにBXTのおかげです。また、恒星の大きさですが、不自然でない程度にとどめておきましたが、かなりシャープに絞ることができています。微恒星もより暗いものまではっきりと出ています。

comp1

あと、背景も積極的に炙り出せました。前回の青い馬星雲で練習した成果になるでしょうか。ただ、背景についてはは自宅の明るい場所での撮影なのでこれくらいが限界です。すでにノイズの荒々しさが残ってしまっています。本当はもっと広い範囲で淡い青いところが広がっているはずなのですが、これ以上出したかったら、露光時間をさらに増やすか、もしくはもっと暗い所へ行くべきです。それでもまあ、今回の再処理でとりあえずここまで出たのでよしとしましょう。


まとめ

これまで何度か試したBlurXTerminatorですが、これは天体写真の解像度向上に革命を起こすくらいのツールと言えそうです。その一方、今のAI技術はまだまだ発展途中、もしくは遠い将来から見たら出始めのかなりあやふやな技術だと評価されるかもしれないので、疑似的な画像を作り上げる可能性も否定はできません。中身がほとんどブラックボックスという心配もあります。

そうは言ってもこの素晴らしいツール、手間の軽減、時間の短縮、星像のシャープさ、分解能の向上などメリットの方が遥かに遥かに大きいです。私個人としては新しいツールにかなり寛容なので、DeNoise AIの時もそうでしたが、趣味の範囲では見た目でよさそうなら積極的に使っていきたいと思っています。DeNoiseの時もフェイクになる可能性があるという批判はありましたが、大きな目で見れば今回のBXTはそのアップグレードと考えることもでき、順当な進化なのかと思います。

AIと画像処理は研究ベースでも親和性がとてもいいようなので、今後もアマチュア天文を対象にAIを利用したソフトがさらに出てくることと思います。個人的には拒否反応など示すことなく、冷静にいいところを見つけて、積極的に使っていきたいと思っています。

BlurXTerminator (BXT)を使った、過去画像の再処理の第二弾です。

第一弾は三日月星雲でした。


この時は主に背景の改善が特徴でしたが、今回は特に恒星の改善がすごいです。

BXTの収差補正能力

昨年ゴールデンウィークに、近くの牛岳においてFS-60CBにASI2400MC Proを取り付けて撮影した青い馬星雲。



当時出来上がった画像はASI2400MCの能力が思う存分発揮されたもので、背景の淡い部分が十分に表現され、遠目で見る限り素晴らしいものです。自分的にも十分満足していました。その一方、遠征先で撮影時に接眼側の延長筒の長さが手持ちで合わず、バックフォーカスがずれてしまい、四隅が思いっきり流れてしまいました。
mosaic1

これはさすがに救いようがないとずっと思っていたのですが、BXTはこのレベルでも大幅に改善してくれます。しかも今回使ったのは「Collect only」だけで、恒星を小さくしたりハロを押さえたりする機能は使っていません。
mosaic3

左上だけまだ少し流れていますが、他の8枚は完全に許容範囲です。これだけでもBXTの収差改善は圧倒的にすごいです。

しかもFS-60CBには、昔から指摘されている弱点の一つとして、撮影の際に赤と青とでピント位置がどうしてもずれてしまうという問題があります。現場において赤に合わせるか、青に合わせるか、もしくはその中間に合わせるかいつも大問題です。どうするかは場合によるのですが、今回は青い領域なので青にピントを合わせたために、全ての恒星周りに赤いハロが出てしまっています。ところが、これらの赤ハロも今回のBXTはものの見事に綺麗に除去してくれています。これはFS-60ユーザーにとっては大きな福音となるのではないでしょうか。


背景と仕上げ

この四隅で仕上げた画像です。今回はNXTも使いノイズをある程度除去しています。また、青い馬付近は意外に赤い領域もあり、前回はこの特徴をあまり出せなかったので、今回は少し強調してあります。

masterLight_180_00s_RGB_integration_ABE_SPCC_ABE3_cut

下はこれまでの画像ですが、今回のと比べると、やはり少し緑に寄っている気がしますし、赤が弱いと思います。
masterLight_180s_ABE_PCC_ASx4_SCNR_bg2_cut_s

これまでと、今回の再処理の2枚を比較して検討してみます。まず恒星ですが、明らかに分解能が増しています。特に首元にある青い明るい2つの星の下の方のものは、2つの星がかなり近接しています。前回のものでは明るすぎて分離できていませんでしたが、今回のでは余裕で分離しています。また、微恒星に関しても、拡大して比べるとよくわかりますが、より暗い星までかなりはっきりと写っています。恒星に関してはほとんどの処理がPixInsightで閉じるようになったのでずいぶん楽になったのと、その恩恵でしょうか仕上がりも大分良くなったと思います。BXTのおかげですね。

その一方、分子雲に関しては今回かなり苦労しました。前回のレベルまで全然持っていけないのです。前回の時点ですでにかなりのレベルで淡いところを引き出し切っていて、しかも最後のところをPhotoshopでやっていたので、肝心要の最淡の部分でどうやったか記録が全く残っていません。元々の素材が良かったので、画像処理はかなりシンプルだったはずです。色々試しても、ごくわずかのところでどうしても前回のレベルまで持っていけません。結局今回は第9バージョンまで処理し直して、やっとそこそこ満足しました。ポイントはマスクの使い方だったのですが、前回シンプルにやっていたのを、今回凝りすぎていたというのが原因でした。本当にシンプルに星マスクをうまく適用することで、背景の分子雲モクモクを再現することができました。

あと今回はNXTも使ったので、背景が全体的にノイジーだったのが改善されています。ある程度拡大して比較するとよくわかります。


まとめ

BXTを使い再処理すると、やはり有意に違いがわかるレベルで改善します。今回に関しては主に恒星です。その一方、今回実感できたことは、BXTは恒星や星雲部の分解能は向上させることはあっても、諧調に関してはほぼ何も貢献しないということです。前回の三日月星雲の再処理では背景の階調が改善しているように見えますが、あくまで副次的な効果で、基本的にはこれまで通り丁寧に階調のある部分をうまく拡大させることが必要となるということがよくわかりました。


BXTによる再処理シリーズの第三弾はトールの兜星雲です。
 

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、今回もかなりの手応えなので、今後もう少し過去画像の再処理を続けたいと思います。


(追記) 第二弾は青い馬星雲です。

このページのトップヘ