M17とフラットと写野回転とスケアリングと。

 ようやく梅雨が明け、待ちに待った撮影が6/28に出来ました。

結果から先にいきます。

機材：SE102, ZV-E10, QBP

条件：ISO1250, 25s露光×298枚

処理：トリミング、SPCC、AI デノイズ&デコンボリューションあり

撮影を始めてから７天体目。

初めて露光時間が２時間を超えました。

撮影よりも処理が難しかったです・・・

tomとしては満足のいく仕上がりになりました。

今回の撮影で試そうと思っていた事が２つあります。

①撮影時にフラットを撮る

今まで撮影後にダークを撮って、フラットは別日に撮っていました。

今回は撮影後にフラットを撮って、ダークを別日に撮りました。

ダークの温度合わせは出来ませんが、光学系は完全に同一なのでフラットは精度が上がるはずです。

どちらの方が良いのか調べていきます。

②フラット補正時に、-equalize_cfa の有無で差異の確認

tomはQBPフィルターを用いているので、撮影した映像もフラットもRGBが偏っています。

このRGBが偏ったマスターフラットで補正をする場合、 -equlize_cfa でマスターフラットのRGB強度を強制的に均一化させる事で何かしらの影響があるかを確認します。

では①からです。
これはスタッキングが終わった瞬間に結果が分かりました。
上は過去撮影したM42、下は今回撮影したM17です。

M42は露光時間１時間、M17は２時間なので写野回転の影響はM17の方が大きいです。
が、M42にあった円形のカブリがM17ではなくなっています。


明らかにフラットを当日撮影した方が良くなっています。

フラットを当日撮影したデメリットとして、ダークの温度が合わなくなります。
これに加え、夏場の高温でダーク減算が更に合いにくくなるはずです。

…と思っていましたが、過補正や補正不足となっているピクセルが分かりません。


なんでだ…？？

私はAZ-GTiを使っているので、写野回転が発生します。

過補正や補正不足によるノイズは写野回転に伴って同心円状に発生すると考えています。

また、家が鉄筋コンクリートのマンションなのでスマホのコンパスが狂ってしまい、真北が正確に分かりません。

追尾エラーはそこそこ大きいです。

今回の撮影でも、途中で鏡筒の向きを修正する必要が出ました。

写野回転に加えて追尾エラーも発生し、これらが合算される事でノイズが見事に散っている可能性があります。

いわゆる天然ディザリングになっているのかもしれません。

これは素人には嬉しい誤算の様に思います。

逆に、腕や機材がレベルアップしないと様々なノイズに遭遇する事すら出来ないんでしょうね（ノイズ以前の問題という事）。

少し残念（？）ですが、戦うべきノイズと遭遇できるまでコツコツと経験値とお金を貯めて行くしか無いです。

話を元に戻して、ダークを別の日に撮影するデメリットは今のところ無視できそうです。

ひとつ検証終了。

さて、②に進みます。

フラット補正時の -equalize_cfa による差異の確認です。

スクリプトのcalibration部分を抜粋します。

calibrate light -dark=../masters/dark_stacked -flat=../masters/pp_flat_stacked  -cfa -equalize_cfa

このオプションにある -equalize_cfa は、マスターフラットのRGB強度を均一にし、強制的にグレーにします。

前述の通り、QBPフィルターを使用していてライトフレームもフラットフレームもRGBが偏っているので、グレーにする意味があるのかどうかの検証です。

まず比較画像を出してみます。

上が -equalize_cfa あり、下が無しです。

左からカラー、R、G、Bです。

正直、全く差が分かりません。

RGBはそれぞれフラットの効き方が違っています。

Rはカブリが無いように思います。

GとBは写野回転部分をトリミングで除けば、直線的なカブリなので容易に補正できそうです。

が、-equalize_cfa 有り無しの差がホントに分かりません。

フラット画像はこんな感じで、グレーとは程遠い状態です。

絶対影響出ると思ったのになぁ…

まぁ、差が無いなら無いで気にしなくて良くなったのでOK。

どっちでも問題なしという結論です。

そして、処理時にホントに問題になったのがスケアリングです。

上の方フラット補正の画像を見てもらうとわかる通り、画面の右下が猛烈に流れています。

これにAI deconvolution(stellar) をかけると、右下が強く補正されて違和感のある画像になります。

右下だけ星が小さいっておかしいよ…

PSFを最大の10にして、strengthを0.2程度にする事で何とか違和感を最小限に抑えて出来上がりました。

が、実は最初にスタックした写真では、どんな設定値でも違和感のある仕上がりにしかなりませんでした。

原因は写野回転の影響と思われます。

最初は右下の星の流れがあまりにも大きすぎたため、GraXpertでどんな値を設定しても右下ばかり補正されて違和感のある仕上がりになっていた様に感じています。

解決方法として、スタッキング前の位置合わせを工夫しました。

何も指定せずにスタッキングを実行すると１枚目の画像が基準となります。

これではスタック時に端の方の情報が大量に犠牲となります。

撮影の中盤の画像を基準としてスタックすると犠牲になる情報が最低限になるはずです。

（少なくとも１番美味しいところをトリミングできるはず）

イメージで表すと下の通りです。

赤が基準となるフレームです。

左は１枚目が基準となるスタック、右が撮影中盤を基準とするスタックてす。

では、これをSirilでどう行うかという所です。

これは各フレームの星合わせを一旦行った上で、全フレームの重心を計算し最適なフレーミング位置を算出する方法があります。

register の -2pass オプションと、-framingオプションを使います。

前回説明したスクリプトの内、ライトフレーム処理のregisterの部分は次の通りです。

register pp_light -drizzle -scale=1.0 -pixfrac=1.0 -kernel=square -flat=../masters/pp_flat_stacked

-2pass & -framing 適用後は次のスクリプトになります。

register pp_light -2pass
seqapplyreg pp_light -drizzle -scale=1.0 -pixfrac=1.0 -kernel=square -flat=../masters/pp_flat_stacked -framing=cog

最初の register -2pass で位置合わせの計算だけを行います。

続く seqapplyreg で画像生成する際に -framing=cog オプションでフレーミング位置を算出する様に指定します。

これなら何も考えずにスタックするだけで、最適なフレームになります。

経緯台で撮影している人には重宝できると思います。

これにより右下の星の流れが若干マシになりdeconvolutionの違和感を抑える事が出来たという事です。

ただし、画面右下の星の流れは本当に酷く、右側1/4くらいは使い物になりません。

使い始めた直後から分かっていた事ですが、どうせトリミングするしと思って重要視していませんでした。

今回の撮影で問題となったので、改善する必要が出てきました。

根本解決にはスケアリング調整が必要です。

望遠鏡を買って４ヶ月目の素人にできるかな…？

スケアリング調整アダプターって調べてみると１万円近くするので手が出ないんですよね。

どうするか、のんびり考えていきます。