PixInsight

2018年7月13日 (金)

DBEで暗いムラが出来るのは

「え、知らなかったの!?」と言われそうですが、今頃気が付きました・・・

サンプルが星や星雲に乗っていると、補正が上手く行かないという事を。

Dbe1

Dbe2

今まで何をやっていたんだ~と思いますsad

ちなみに、サンプルは出来るだけ等間隔が望ましいけれど、列からズレてもor空白が出来てもOK(星に乗せて過補正を招くより、そのサンプルを削除する方が良い)

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

改めてこちらを読み、備忘録に

・画像の端の重ならない部分は、予めcropしておく。

・星が密な領域ではサンプル半径を小さく

・サンプル半径を決め→per rowを決める

・全てのサンプルを有効にするために、

Minimum sample weightを下げる(e.g.→0.1) Toleranceを上げる(e.g.→1.0~1.5)

vignetting;周辺減光 dust motes;ゴミの影 

2018年5月 6日 (日)

ドイツ語は解らないけれど

AstroBinで、とても共感できるNGC4559画像をみつけました。

ウェブサイトを訪ねてみたら、ベルリン郊外にお住まいの方らしく、庭に小さな望遠鏡小屋を作り、銀河は10インチニュートン+Atik 460EXをメインに撮影なさっているようで、私よりちょっとずつスペック高いけれど、目標に出来そうな親近感を持ちました(身の程知らずでしょうかcoldsweats01

画像処理の動画もUPなさっています。

http://www.spaceimages.de/en/processing/ebv-workshop

workshop1はPI中心のRGB調整で、私がやっている処理の流れと概ね同じ。

違う点は、背景輝度(レンジ)、DBEにdivisionを使っている事やABEとの併用、SCNR1.00使用、ヒストグラムのRGB高さ、MLTにk-sigmaを入れていた事、など。

SCNRは「光害が」とおっしゃっているけれど、ドイツでもGカブリ?では当地のナトリウム灯は何カブリ?(Wikiの「光害」で、"ナトリウム灯のオレンジ色の光の影響は、光量で見れば水銀に比べて軽微であり、観望や撮像の時には無視できる"という記述も気になっています)

workshop2の方はPS中心で、何をやっているのか良く解らず、繰り返し見ている所です。

この方の画像に共感を覚えた理由は、DLして彩度・輝度を上げてみて解ったような気がしました。こういう画像を目指したい。ほんの少し華やかさも添えて。

2018年4月27日 (金)

ステライメージの色、PixInsightの色?

以前にも何度か書きましたが、ノンリニア変換前のRGB調整に、ステライメージを使うと黄色・緑が強い暖色系の仕上がりになり、PixInsightを使うと紫・青が強い寒色系になるのが不思議でした。

0427_2

色差が見え易いように彩度100%に上げています。

左;ステライメージ7(チャンネルパレットを見ながらレベル調整後、デジタル現像w/マスクrgb) ※今気が付いたけど背景バランス甘かったsweat01

右;PixInsight(CC後、HT時にヒストグラムを見ながら再調整)

LRGB画像

04273

ステラ調整は青い星が出難い(DDPのbマスクにb以外をかければ出るが、輝星に偽色が残る)し、PI調整は銀河部分に深味のある緑、黄色を出す事が出来ませんでした。

これはソフトの特徴というよりも、R/G/B各画像を(私の)目視で調整したか or (画像を見ないで)CCとヒストグラムだけで調整したかの違いだったのですが、

utoさんからの御指摘で思い出しましたが、PIのCCは銀河を白と仮定するので、この色調になるのは当たり前なのかも?

検索すると、PCCとeXcalibratorを比較しているサイトもありました。

http://bf-astro.com/pccTest/pccTest.htm

この方も「PCCは青が強め」と結論されているようです。

CCやPCCを使用せず(あるいは使用後に)ノンリニア変換時のヒストグラムを調整すれば、PIでステラの色調を引き出す事も出来るはずと思います。

でもどちらの色合いがいいのでしょうね・・think

左は昔好きだったAOPの画像に似ている。その後、A.B.さんの画像が右のような色彩になった時は落胆したものでしたが、今は綺麗だと思うし、一般にもこちらの方が受け入れられそう?

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

彩度調整に使ったマスクなど

04272

今回の手順は、

①PI>CTでSaturationカーブを持ち上げ(上使用)

②SI>Lab色彩調整の各色を右にスライド(下使用)

③Lab色彩調整を各色8~9に彩度down(上マスク or レンジを詰めた輝度マスクを反転使用 下げ過ぎないように)

④PI>MLTでノイズリダクション(銀河の大きさを下のマスクぐらいまで詰めた輝度マスクを反転使用)

⑤④とL画像をPSで(2度目の)LRGB合成 

銀河部分の色を出そうとすれば、星の色に負担がかかる?とすれば、カラーでも各々を別にストレッチする必要があったのかもしれません。いろいろ気付くの遅過ぎ。そして直ぐ忘れる。

2018年3月26日 (月)

LNの悪影響?

透明度の悪い画像もSN改善に貢献するという星羊翁さんの記事を拝読し、ゴミ箱から薄雲画像を回収しました。

復活23枚を加えた290枚をIntegrateする過程で、改めてLocal Normalizationに疑問符が。

PIのForumに、「LNのReferenceには、スタック後DBEした画像を使う事も出来る」と書かれていたのでやってみたら、銀河周辺に著しい輝度低下が出てしまったのです(↓中列)

1

左列;LN無し 右列;単画像referenceでLN

上段はReference 中段がIntegrate結果、下段はIntegrate後DBEした画像です。

更に、左下と右下のDBE画像を拡大してみると、LN無し/有りでSNに差が。

2

また、290枚LN無しIntegrate(↓左)と、267枚LN有りIntegrate(↓右)を較べてみると、

3

コントラストは右の方が良いですが、SNや淡いガスの拡がりはLN無しの方が断然勝ります。

経験的に200枚を超えての23枚差程度で、ここまで劇的な優劣をもたらすとは考え難いので、LNの有無が影響していると考えられます。

もちろん一概にLNが悪いという訳では無く、使い方-条件の異なる数夜分を一括LNしている弊害かもしれません。Reference画像の構図ズレによる黒い端が悪さをしている可能性も?

いずれにせよ、LNの使用には注意が必要。

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

念の為、290枚と267枚のLN無し画像の比較も。

4

やはり、LN使用267枚スタックは失敗だったようです。

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月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は、以前に試したこの画像(右端)に良く似ています)

無料ブログはココログ
2018年7月
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
29 30 31