PixInsight

2018年1月22日 (月)

NGC3344のDeconvolution

結局L画像は720枚も撮ってしまいましたcoldsweats01

その中からカブリの少ない380枚、更にFWHMの小さい250枚を選んでLNスタックし、Deconvolutionしてみました(↓上段Deco前 下段Deco後)

0121

使用マスク

01212

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

お試しLRGB

Lrgb4

Lrgb4saidodownr

2017年12月23日 (土)

StarAlignmentの謎

NGC3344のR/G/BをSA後1枚ずつLNしていたら、G画像の1枚が変に歪んでいる事に気が付きました。

上段;SA前の元画像、中段;●で一括SA後 下段;■で1枚だけSA後

Why

(※このG、ピンボケ?)

左列の全面表示では解り難いかもしれませんが、右上と右下を拡大してみると縮尺が違う。平面が傾いているような感じなのです。

原因はどうやらReferenceにL画像を使った事らしく、G画像でやり直したら正常に出来ましたが、何故L画像では駄目なのか、総RGB55枚の中で何故1枚だけがこうなってしまったのか。

LとRGBの違いと言えば星の数(写り)なので、透明度の違いによる限界等級が可否を分けたという事かもしれませんが、個別にSTF確認していなければ、気付かないでIntegrateしていた。

LとRGBは別々にSAした方が無難?

2017年12月20日 (水)

画像処理記事の事など

昔の(っていつの話^^;)ブログといえば個人の日記的なものが殆どだったような記憶がありますが、最近は収入を目指すものも増え、お金を稼ぐからには「面白くて、為になる」記事が広く求められる時代なのかもしれません。

私は最近、特にPI関係の記事をUPする事に躊躇を感じるようになりました。

自分のtrial&errorの備忘録として書いていますが、元来理系は苦手だし、コンピューターも未だソフトのインストールで迷う程の初心者レベル。

「また何かやっているな」程度に御覧頂ければ嬉しいのですが、情報を求め検索でいらっしゃる方には申し訳無い気持ちになります。

まあ玉石混交も自然淘汰も世の道理なので、気にしても仕方が無いのかもしれませんが(案外図々しいcoldsweats01

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

傘マークの多い予報

12201

年末年始に一時帰国するし撮影チャンスは無いかもですが、NGC3521を撮り足したくなりました。

12202

天体写真も一般写真同様、被写体そのものの魅力が大事なのかなと思い始めています。

2017年12月19日 (火)

LNテスト(再)

多数枚からの選別は、相変わらず悩みの種です。

「せっかく撮ったデータを無駄にしたくない」という気持ちと、「悪いデータを混ぜる事によってスポイルしてしまうのでは」という恐れと。

シャープさについては、FWHMで枚数を区切りながらDeconvolution結果で比較するという一応の目安を持っていますが、SNについてはカブリ画像の取捨選択に迷います。

utoさんに教えて頂いたのは、「無補正の画像は入れるべきではないが、基本的には単画像を補正して"使う"のが正解」 

この単画像の補正には、ABEやDBEよりもLocalNormalization(以下LN)が便利に使えそうだと、tantanさんから御紹介頂いたForumのスレッドで知りました。

https://pixinsight.com/forum/index.php?topic=11550.0

https://pixinsight.com/forum/index.php?topic=11513.0

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

処理プロセスは4段階です。手順については、蒼月城さんのページを拝見しました。

Ln5

①最初にStarAlignment(以下SA) 

一度うっかりLNを先にやってしまい、SA出来ずにやり直す羽目に。先にSAしておけば、LNの際、画角にズレのある画像をreferenceに使う事も出来ます。

Add Filesで処理画像選択、output directoryを指定し、Generate drizzle dataにチェックを入て実行。

②LN

Reference imageが肝要。

上で、「画角にズレのある画像(つまり別の夜に撮影したデータ)もreferenceに使える」と書きましたが、こちらで開発チームの方が"LN works for similar images."と明言している事からも、おそらくは撮影当日のbest imageをreferenceとして、各夜毎にLNするのが良いかもしれません。

ただ今回は終夜カブリの日もあったので、撮影全画像から最も良質と思われるもの2枚を選び(A;均一度良but透明度やや悪 B;下辺部に帯状のムラ有りbut透明度良)、各々ABEしてから使ってみました。

まず単画像でテスト。左の2枚がreference image 右の上から順に補正前、Aで補正、Bで補正

Ln11

この元画像、やっぱり長いフードが必要ですねcoldsweats01 

補正が甘いのでscaleをデフォルトの128→64にしてみましたが、

Ln12

砂粒のようなザラつきが出て使いものにならず、デフォルトの方が良さそうです。

効果を確認したら、いよいよLNを実行します。

Target imagesに①で作成されたSAデータを入れ、Output directoryでフォルダを指定。これはSAと同一フォルダでも良いのですが、今回は2枚のreference imageでの違いを見たかったので、別フォルダA,Bを作りました。

Generate Normalization dataにチェックを入れて●

③ImageIntegration

Add Files/Add L Norm. Files/Add Drizzle Files

NormalizationでLocal normalizationを選択するのを忘れずに←2度やり直しました

④Drizzle Integration

 

Add Files/Add L Norm.Files で● この処理は特に時間がかかります

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

こうして作ったdrizzle画像が下段の2枚です。上段左はLN無し、右は同夜画像referenceで1枚ずつLN(超疲れましたwobbly

Ln14

STFは均一度の高い画像程レンジが詰まると思っているので(という理解で良いのでしょうか?)、最も好結果なのは右上の"同夜画像をreference"、次は"Bをreference"、"Aをreference"の順で、最後がLN無し。

この4枚に同じストレッチをかけようとすると、"Bをreference"だけが外れてしまうのは何故なのか。referenceBの背景輝度が全体の平均より暗過ぎた?

Ln15

Ln16

とりあえず同じような見え方に調整した時のヒストグラムは、こんな感じです。

Ln17

最初にリンクしたFormuスレッドで、開発チームの方が書かれている、

"LocalNormalization is a powerful tool able to solve difficult problems efficiently, but unfortunately, it is also an extremely dangerous tool. This is because the local normalization problem is, as most inverse problems, inherently ill-posed. That's why I have implemented many control and analysis features in the LN tool, including complex graphical representations that can be very useful to judge the correctness of each particular application."

を真摯に受け止めるならば、面倒でも1枚ずつ3Dグラフを確認しながら使った方がいいのかも。

あの3Dグラフ、傾斜と凹凸は何となく解るけれど、平面の高低はどう理解すれば良いのでしょう。低い方に補正されるのが〇?
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

おまけ

(SAの前にLNした場合)元画像と画角がズレている画像をReferenceにを選んでしまうと、右端のようになります↓

Ln2

LN補正結果の3D画像は、元画像のムラが大きいほど平坦になり易い?元画像にムラが少ないと、却ってガタガタになる事も・・

Ln3

Ln4

2017年12月10日 (日)

NGC2683のDconvolution

これまで使って来たMaskは、StarMaskと、レンジを詰めたノンリニア画像をminimum合成していましたが、銀河の淡い部分と微光星を分離出来ないのが難点でした。

淡い部分は(復元痕が出てしまうので)マスクから除外したいけれど、微光星は(収束させたいので)マスクに含めたい。

NGC2683のような銀河では特に問題で、強いMaskと弱いMaskでの2パターン用意して合成する事も考えていたのですが、こちらの動画でMLTを使った微光星マスクを知りました。(Oさん、有難うございました)

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

① まずノンリニア画像のレンジを少し詰めます。

2

② ①からMLTで星マスクを作ります。

3

③ ②のレンジを詰めて(背景ノイズに注意)、微光星マスクが出来ました。

4

④ 輝星・中間星マスクもMLTで作れるとの事ですが、とりあえず使い慣れたStarMsk→Invert

5

⑤ こちらもいつもの銀河マスクですが、微光星の消失を気にせずにDeconvolution処理をかけたい部分だけ残す事が出来るようになりました。

1

⑥ こうして出来た3枚をPixMathでmaximum(minimum,minimum)合成(一晩寝たら解りました^^;)

6

11

このマスクでDeconvolutionしてみました。

左上;元画像 右→左下→右下の順にiteration30、50、80

10

この画像(対象?)では、iteration少な目の方が良さそうです。

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

テストLRGB

2683test

銀河部分の飽和を抑えるMaskedStretchの割合と、解像感を演出する暗黒帯の強調が肝かもしれません。(黒い部分をより黒くするには、どうしたら良いのか・・)

2017年11月 6日 (月)

ヒストグラム

NGC7741の各プロセスでヒストグラムに何が起こるのかを把握したくて作ってみました。

LRGB合成1回目の右側の画像は、SCNRを使わなかった場合です。

11061

完成画像のヒストグラム。上段は同じヒストグラムの目盛を広げたものです。

11062

PCCを使った完成画像のヒストグラム

11063

これらを見ながら考えます。

:::::::::::::::::::::::::::::::::::::::::::::::::::::

NGC925のも貼っておきます。

1106_2

:::::::::::::::::::::::::::::::::::::::::::::::::

とても解り易い解説を読んで、単画像に光害の影響が見えるのか試してみましたが、良く解りませんでした。

11065
11088

2017年10月14日 (土)

カラー画像の調整

NGC925のカラー画像の調整過程の備忘録です。

①1回目のLRGB合成。RGB→LRGBでヒストグラムがこんなに変わってしまう

1

②それを修正し、

2

③左上のマスクをかけてMLT

3

④star maskをかけて彩度up

4

⑤低輝度部分の彩度down

5

⑥2回目のLRGB合成

6

2017年9月29日 (金)

MLT

tantanさんの画像を拝見し、私もNRを試してみました。

左上;元画像(16枚スタック) 右上;マスク(元画像をHT変換Invertから作成)

左下;リニア画像にMLT  右下;ノンリニア画像にMLT

2

このサイトでは"Works equqlly well with linear and non-linear"と書かれているけれど、私が何か間違えているのかthink

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

追記;リニア画像にも"Dyadic"のまま使っていたので"Linear"に直してみました。

3

更に、リニア画像MLTのAmountを下げてみましたが(右はノンリニアMLT)

4

星が潤む(解像感が下がる)のは、強度の問題では無さそう?代わりに、星の周囲の円形痕はリニア画像MLTの方が目立たなくなっています。

(リニア画像MLTは、以前に試したこの画像(右端)に良く似ています)

2017年9月16日 (土)

NGC1400,1407再処理

色々試して来ましたが最終的に3枚の中から1枚を残す予定です。

星の黒縁については、MLT時のマスクに、非選択範囲をボカし広げたStarMaskを合成してみました。

2

が、効果はイマイチ解りませんでした。

1

そもそも、元画像に存在する輝度低下(?)の大きさと、MLTが「形」を保護する範囲と、作成するマスクの範囲が絶妙にバランスしないと、逆効果になってしまう可能性もある訳で・・

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

追記;

楕円銀河などでマスクのレンジを詰め過ぎると階調段差が生じる事を忘れていたので、やり直してみました。

でも緩いマスクだと最微光星が霞み、解像感も失われてしまう(↓中央)

3

この辺り、慎重な調整が必要です。

(そして星マスクの円形よりも、元画像の円形痕の方が強いという謎)

2017年8月24日 (木)

画像処理メモ

(7月の記事を一部修正して移動しました)

MaskedStretch画像の透明感、通常HT画像の輝き感、どちらを採るべきか決めかねています。

とりあえずの手順としては、

①Deconvolution後のリニア画像をHTしたもの(A)と、同じ背景輝度でMaskedStretchしたもの(B)を作る。

②Aと、StarMaskで星を除外したBを、PixMathで合成する(C) 割合は試行錯誤。星についてはLRGB合成後にMTを使う。

③Cをコピーし、LHEを施す(D) →16bitTIFFで保存

④CにMLTでノイズリダクションを施す(E)→16bitTIFFで保存

⑤必要があれば、Dの銀河部分をEに合成する。

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

今後撮り直し・撮り足したい対象は、M74 NGC925 NGC3344 NGC2683 NGC5921 NGC4449 NGC4559 M51 M63 他は画像処理をやり直し。

無料ブログはココログ
2018年2月
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28