ほしぞloveログ

天体観測始めました。

タグ:LRGB合成

久しぶりのブログ更新になります。皆様いかがお過ごしでしでしょうか?ゴールデンウィークは天気も良く、特に後半は新月期に入り絶好の星見日和だったのかと思います?

私はというと、あいにくGW中に体調を壊してしまい、前回の小ネタ記事を書いて以降ほぼ何もできない日が続きました。やっと体力も少し回復してきて、今もこの記事は病院の中で書いています。と言っても今回のM104の撮影はずっと前に終わらせていましたし、画像処理もブログ記事ある程度まで終えていたので、少し仕上げたくらいであまり無理はしないようにしています。

せっかくの長期休暇の新月期、暑くもなく寒くもなく、大きな太陽黒点と低緯度オーロラを横目にと、数々の絶好のチャンスを逃してしまい残念でなりません。その不満を払拭すべく、少しづつですが再開していきたいと思います。


三たびM104、でも本当は4度目

M104は分解能ベンチマークのような役割もあり、これまで何度か撮影しています。最初は2021年4月にVISACで。中心部を拡大すると、まだまだ無理やり解像度を出している感があります。


次は2022年8月、SCA260を手に入れてからより大きな口径で違いを見ました。


ただ、SCA260は焦点距離が1300mmとそこまで長くないので、M104は小ぢんまりと写ります。そのためこの時は
  1. バローなどなしでbin1の場合
  2. 2倍のPowerMATEを使ってbin2の場合
で比較しました。1素子あたりの明るさと画角は同じになるようにして比較したということです。違いはFOV(全体の視野角)と、bit depthになります。結果としては、恒星は2の2倍でbin2方が良かったですが、銀河本体は1の方がビミョーに良かったです。でも有意な差はほとんどなくて、結局1のほうがバローの挿入などの余分な操作がなく埃などが入る余地が少ないので、今後は1でいくという結論になりました。あと、この時はまだRGB合成のみで、L画像は撮っていませんでした。

その後、2023年5月にL画像だけ撮影していて、明らかに解像度が上がっていることまで確認したのですが、同時期にRGBを撮影する機会がなかったのでそのままお蔵入りにしてしまいました。2022年のRGB画像と合成しても良かったのですが、いまいち盛り上がらずに2024年を迎えてしまって、このままではさすがにダメだと思い、今回やっとLもRGBも一緒に撮影するに至りました。


NINAが重い

今回の撮影の少し前、3月18日にNINAの3.0が正式に公開されました。ただしちょっと重いみたいです。3.0にしてから撮影画像の保存にすごく時間がかかるようになりました。1枚撮影すると保存だけで毎回1分以上かかり、保存中は撮影は進まないので、かなりの時間ロスになります。

現在はStick PCで撮影し、micro SDに保存しているのです結構非力です。最初ディスクの書き込み速度を疑いました。でも撮影したファイル単体のコピペとかだと全然速く終わります。そこで、タスクマネージャーで撮影中の様子を見てみたら、NINAがものすごくCPUパワーを食っていて、かなりの時間100%になるようです。仕方ないので、以前の2.2に戻したら、ほぼタイムロス無しで連続で撮影できるようになりました。単にソフトが肥大したのか、それとも何か負荷が増えるようなバグっぽいものなのか、3.0がさらにアップデートされたらちょくちょくチェックしてみたいと思います。


今回の撮影

今回の撮影での大きな違いは、
  • 前回まではRGB撮影だけだが、今回はL画像を撮っているところ
  • 露光時間をこれまでの5分から1分にしたこと
です。L画像は実際の解像度向上に大きく貢献することになるかと思います。露光時間に関しては、SCA260+ASI294MM Proの場合gain120で露光時間5分だと、かなりの恒星がサチってしまうことに気づきました。特に、明るいL画像は深刻です。

下の画像は昨年5分で撮影したL画像を反転させています。bin1での撮影なのでそもそも12bit = 4096階調しかありません。ここでは階調の99%以上(4055/4096)になってしまっているところを黒くしています。

2023-05-11_20-58-14_M 104_LIGHT_L_-10.00C_300.00s_G120_0004
結構な数の星と、なんと画面真ん中の銀河中心までサチってしまっています。これはいけませんね。

下は今回露光時間を1分にしたもので、他の条件はほぼ同じです。だいぶマシになっていますが、それでもまだ飽和を避けることはできていません。少なくとも銀河中心は問題ないです。
2024-04-01_22-25-41_M 104_L_-10.00C_60.00s_0013

さらに露光時間を変えるにあたり、以下の2つのことを考えましたが、処理後の画像を見比べた限り違いはわからなかったです。
  1. 自宅撮影に限っていうとスカイノイズが圧倒的に支配的になります。露光時間を短くすると、読み出しノイズの効きが大きくなってくるのですが、露光時間を1分にしたくらいではまだまだ読み出しノイズは全然効かないくらいです。
  2. 淡い部分の階調がADCの暗い側にシフトするので、階調が出にくくなる心配もありましたが、まだ全然余裕があるようです。
LRGB画像は今後1分でいいと思います。ナローに関しては輝度が10分の1以下になるので、露光時間5分をキープするか、ダイナミックレンジがそこまで必要なければgainを上げてもいいかと思います。


画像処理 

WBPPでLRGBそれぞれインテグレートまでします。その後、すぐにRGBを合成して、カラーにしてからABEとDBEでフラット化をかけました。それぞれの色でフラット化してもいいのですが、カラーでやっても独立して働くので効果は同じはずで、1度で済むので手間を省いているだけです。

銀河で自宅撮影なので、背景のIFNなどは気する必要はなく、RGB画像もL画像も、気軽に簡単にフラット化してしまいます。だいこもんさんのブログ記事(元情報はUTOさんだそうです)によると、M104の周りにも相当淡い構造(更に大元がここ)があるようなので、試しに去年撮った5分露光画像も含めてL画像をかなり頑張って炙り出しましたが、私のところではその片鱗さえ全く見えませんでした。大顧問さんはチリで30時間露光して見えたとのことなので、自宅のような光害環境ではここまで淡いのは全然無理なのかと思います。なので、今回は背景は気にしないで、とにかく目的のM104本体の内部の細部構造がどこまで見えるかに全力を傾けます。

この内部構造、シンチレーションに強度に依存するようです。L画像は二日にわたって撮影していますが、二日目の画像は全然ダメで使うかどうか迷いました。1日目だけのもの133枚と、1日目133枚+2日目の中でもマシなもの56/103枚を使ったものを比較しましたが、見た目では違いがわからなかったので2日目のも入れたもので処理を進めました。

L画像はABEの2次、DBE、BXTをかけていますが、この時点でかなりの解像度が出ていて期待が持てそうです。
Light_BIN_1_8288x5644_60s_L_drizzle_1x_ABE4_DBE_BXTc_BXT_BXT03


LRGB合成

RGBとLをどう合成するかはいまだに迷います。過去に何度が議論しています。LRGB合成を初めて試したのは2022年10月のまゆ星雲です。この時わかったのは、L画像を合成したときに色がかなり出なくなるのですが、見えなくなっているだけで色情報としては十分残っているということでした。でもLとRGBをどのタイミングで合成すべきか、どういった比率で合成すべきかなどはまだまだ謎のままでした。


その後、この2つの過程でLRGB合成の経験的な方法はある程度確立したのかと思います。



そしてこのページである程度の理屈も含めて結論が出ています。


久しぶりのLRGB合成になるのでかなり忘れていることもあり、今回改めて読み直しましたが、今見てもかなり有用な議論です。当時のniwaさん、botchさん、だいこもんさんに感謝です。

今回まずは様子見で、PIのLRGBCombinationを使ってL画像を指定してRGB画像放り込んでみると、カラーノイズが結構目立ちました。RGBの撮影時間が短いので当然なのかもしれません。そこでLab分解してaとb画像にぼかしをかけてみました。以前うまくいった方法なのですが、今回はカラーノイズに対してほとんど効果が見られませんでした。カラーノイズ対策ができないのならa、b画像で何かする価値はほとんどなくなってしまいます。カラーノイズは後で対策できることと、奇をてらう方法はできるだけ避けたいこともあり、今回は素直にLRGBCombinationを使う方法を探ります。

未だ残っている一番の疑問は、LとRGBの混合比率です。これまでわかっていることは、
  • LRGBCombination処理はリニアでやらずにノンリニアでやること。ノンリニアとはフルストレッチしてからということ。
  • でもフルストレッチは厳しすぎる制限で、多少のストレッチでも大丈夫そうなこと。
  • リニアで処理すると、恒星内部に明るい飽和の飛びができ、後からどうしようもなくなること。
  • 飽和の飛びはL画像がRGB画像より暗い場合にできたが、L画像を明るくすると無くなること。

まず思っている疑問は、リニア段階での処理では本当にダメなのかということです。リニアはノンリニアの特別な場合と考えることができ、ノンリニアでいいのならリニアでも当然大丈夫だと思うからです。今のところ確認できている弊害は、
  • 恒星の飛び
だけです。

結論だけ言うと、今回リニア段階でLRGBCombinationを試しましたが、いずれも恒星の飛びは確認できませんでした。ただしこの結果は、LとRGBの明るさの違い(混ぜる比率)に依存しそうなので、その比率を変えて幾つか試しました。試したのはLRGBCombinationのCannel Weightsを変えることです。これらは相対的な比だけで決まり、例え全部を0.1とかにしても、処理後の画像の全体の明るさは変わらないことは以前確認しています。試したのは以下の4種類です。
  1. L : R : G : B = 0.1 : 1 : 1 : 1
  2. L : R : G : B = 1 : 1 : 1 : 1
  3. L : R : G : B = 1 : 0.1 : 0.1 : 0.1
  4. L : R : G : B = 1 : 0.01 : 0.01 : 0.01
いずれの場合も上で書いたように飛びは出なかったので、とりあえず今回は少なくともリニア段階でLRGB合成したとしても確認できるような問題は起きなかったと言えます。

その一方、できた画像の解像度には明確な差が出ました。下の画像になりますが、左から順に上の1,2,3,4となります。
comp

注意すべきは2, 3, 4で、Lの比率が高いとLRGBCombination直後はほとんど色がなく、一見モノクロのように見えることです。でも色情報はきちんとのこっているので、ここで心配する必要はありません。CurveTranformationで右のSの彩度を選んで曲線をΓの字になるくらいにして彩度を上げてやると確認できます。上の画像はそのように彩度を上げたもので比較しています。

4つの画像を見る限り、カラーノイズ、彩度に関しては明確な有利不利は確認できませんでした。最も大きな違いは分解能で、Lが一定以上の明るさがないとRGBが持つ低い分解能のままで制限されてしまうということです。わかりにくい場合は上の画像をクリックして拡大して比べて見てください。明確に違いがわかります。LとRGBの比が0.1:1や1:1ならばL分解能が十分生きてこなくて、1:0.1ならば十分、1:0.01にしてももう変化がないことがわかります。以前M106で試した時は1:0.25とかにして分解能が出たので、今回も再現性があり、ある程度L画像の明るさを保たないとダメだという結果を改めて確認できたことになります。

というわけで、今後もLRGBCombinationでシンプルに、Cannel WeightsだけLをある程度大きくしてLRGB合成をすればいいということにします。


結果

結果です。とりあえずはクロップして本体をある程度の大きさにしたものを完成とします。

「M104: ソンブレロ銀河」
Image07_middle
  • 撮影日: 2024年4月1日22時3分-4月2日2時41分、4月10日20時27分-4月11日3時18分
  • 撮影場所: 富山県富山市自宅
  • 鏡筒: SHARP STAR製 SCA260(f1300mm)
  • フィルター: 無し
  • 赤道儀: Celestron CGX-L
  • カメラ: ZWO ASI294MM Pro (-10℃)
  • ガイド:  f120mmガイド鏡 + ASI290MM、PHD2によるマルチスターガイドでディザリング
  • 撮影: NINA、Gain 120で露光時間1分でL: 189枚、R: 59枚、G: 51枚、B: 64枚、総露光時間363分 =6時間3分
  • Dark: Gain 120で露光時間1分が204枚
  • Flat, Darkflat: Gain 120で露光時間 LRGB: 0.01秒でそれぞれ128枚
  • 画像処理: PixInsight、Photoshop

まず目的の銀河本体内部の構造ですが、結構出たといっていいかと思います。これはひとえにシンチレーションが良かったからと言うのが今回の結論です。BXTの効果も大きいかもしれませんが、シンチレーション自身が良かったのがまず第一だと思います。色は下に載せたハッブル画像に近くしました。

クロップ前の全体像になります。
Image07_low

恒例のAnnotationです。
Image07_low_Annotated

銀河っぽいシミがいくつかあると思ったのですが、候補に入らないものがいくつかあります。単に画像処理でなにか失敗してるのか、はたまたまだカタログ不足なのでしょうか?


ハッブルとの比較

恐れ多くもハッブルと比べてみます。

まず今回撮影し画像を5度時計回りに回転させ、次のハッブル画像と同じような画角に切り出したものです。
Image07_rot5_Hubble

次がハッブル望遠鏡が2003年に発表したM104です。
STScI-01EVT8YHAGM2WGQTV3DGKRFZ7Q

もちろん分解能には全然差はあって追いつけっこないですし、恒星に至っては大きさも微恒星の写りも全く違います。でもなんかちょっと比べてみようと思うくらいにはなったのかなと思って、自己満足しています。


まとめ

足掛け2年にわたって悶々としていたM104にやっと決着がつきました。2022年の結果がこれなので、大きな進歩だと思います。
final

ソフトは変わりましたが機材は同じです。今回L画像を撮影したのは大きな違いですが、やはりそのL画像のシンチレーションの影響が一番大きいと思います。撮影時のHFRを見るとシンチレーションの評価になりそうなので、いい日かどうかを定量的に評価しながらL画像を撮影すべきなのかカラー画像を撮影すべきなのかを決めることなどができそうです。そこらへんの補足記事を次に書こうと思っています。

今回健康を害すると何もできなくなってしまうことを実感しました。まだ今後も長年続けていきたい趣味なので、少し体に気をつけて、無理をせずに楽しみながらやっていけたらと思います。

画像処理も溜まっています。ダイオウイカは昨年10月くらいから残ってますし、ヘラクレス銀河団、さらに南天がいくつか残っています。これらも焦らずに進めていきたいと思います。


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


前回の記事で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はすごいソフトです。もう少し色々触ってみたいと思っています。またまとまったら記事にするかもしれません。


このページのトップヘ