ほしぞloveログ

天体観測始めました。

タグ:画像処理

前回の撮影時の記事から少し間が空いてしまいましたが、前回FS-60CBでSV405CCとASI294MC Proで撮影した画像を処理してみました。

 

この撮影後、6月13日付の新しいドライバーが発表されましたが、今回の記事はその前の6月11日にメールで送られてきたものを使っています。そのため(おそらくゲイン120以上で)HGCモードに入りますが、さらにゲインが200プラスされた状態で撮影されています。今回はゲイン120としましたが、実質は320と同等と推測され、ダイナミックレンジが犠牲になっていますので、その点ご注意ください。


共通条件

撮影日の透明度がかなり悪かったため、ここでは比較することを主目的とし、仕上げはさらっと軽めに処理するだけにしました。撮影については、後日透明度のいい日にリベンジしたので、最終画像は後で示します。

ASI294MC ProとSV405CCで共通の事情は、
  • 鏡筒はタカハシのFS-60CB。赤道儀はCelestronのCGEM II。
  • マルチフラットナーをつけていますが、1.1.25インチのノーズアダプターをつけているので、バックフォーカスが合ってなくて、四隅が流れてしまっています。
  • 冷却温度は0℃。
  • 光害防止フィルターとしてCBPの1.25インチをノーズアダプターの先に付けています。
  • 120mmのサイトロンのガイド鏡にASI120MMをつけて、PHD2でガイド。
  • 1枚あたりの露光時間は3分で、10枚に制限し、トータル30分の露光時間。
  • ゲインは120ですが、SV405CCはドライバーがまだ改良途中で実質ゲインが320になっていると思われます。
  • 公平を記すために同日の撮影にして、SV405CCで15分、ASO294MC Proで30分、さらにSV405CCで15分撮影した画像を使用しています。
  • 画像処理はPixInsightでWBPPを使いインテグレートまでしたのを、オートストレッチしています。
となります。


ASI294MC Proの画像(参照)

まずはASI294MC Proです。最初の画像処理でフラット画像に問題があることがわかり、フラットを後日再撮影しました。そのためライトフレーム撮影時についていたゴミが、フラット撮影時に取れてしまったようで、ペリカンの目の下あたりと、下辺中央あたりに丸い大きなスポットが残ってしまいました。カメラの評価にはあまり関係ないのでそのままにしておきます。

下の画像がPixInsightでスタックしてSTFとHTでオートストレッチストレッチだけした画像です。あまり主観的な操作が入っていない段階のこれで比較します。

ASI294MCPro_autostretch_180.00s_FILTER-NoFilter_RGB

この時のヒストグラムは、再掲載になりますが

histgram_ASI294MCPro

となります。至極真っ当そうに見えます。


SV405CCの画像

一方今回の評価対象のSV405CCの画像です。同じく、PixInsightでスタックしてSTFとHTでオートストレッチストレッチだけした画像です。

SV405CC _-180.00s_FILTER-NoFilter_RGB

ヒストグラムは

histgram_SV405CC

となります。まだドライバーでおかしなところがあるため、ゲインを120と設定しても実質のゲインが320
となっていると思われ、同じゲイン設定のASI294MC Proのヒストグラムに比べて全体に右にシフトしていています。120と320で10倍違うはずなのですが、平均は4186から7385と2倍にもなっていないので一見おかしいと思うかもしれません。でもオフセットの値込みの平均値なので10倍になっていないのは問題ないです。

おかしなところは2点、
  • 赤のノイズの広がり方が大きすぎること
  • 60000(最大値の65536でないところが不思議)くらいの値のところに大きなピークがあること
です。その後、ドライバーをアップデートすることで、前者の赤のノイズのおかしいところは解決されることがわかっています。ですが、60000のところのピークは最新ドライバー1.7.3でも解決しないことまでは確かめました。

後もう一つ気になるところは、120秒以上の露光でアンプグローがなくなるというSVBONYの説明です。ですが、マスターダークフレームを見る限り、アンプグローは残っているようです。

masterDark_EXPOSURE-180.00s

それでも撮影時に気になることがあって、ほぼ毎回ですが、長時間露光の場合、一連の露光を開始する最初の1枚だけ、画面全体が暗いです。SharpCapでの撮影もNINAでの撮影も同じです。もしかしたら何かしようとはしているのかもしれませんが、ダークフレームでみて上の様になっているので、少なくともまだうまくいっていないようです。次の最新のドライバーでも注目したいと思います。


比較

両画像を比較してみましょう。オートストレッチ後なので一見どちらもよく似ていて、両者それほど変わらないように見えます。両方とも左が明るく、右が暗いような、1次のカブリがあります。これは左が北側に近く、富山の街の明かりが効いているものと思われます。

あえて言うなら、SV405CCの方が少し赤や緑が濃いでしょうか。でも誤差の範囲の気もします。

大きく違う点は、恒星です。中央下の二つの並んだ星を見るとわかりやすいでしょうか。

starspsd
左がASI294MC Pro、右がSV405CC

一見SV405CCの方が彩度が出てると思うかもしれませんが、よくみると明らかな右上方向への青ズレのようなものが出ています。

実はこれ最初は見逃していて、ここまで拡大することなく、遠目で単に色が出てる恒星だなと思っていたくらいでした。SV405CCで北アメリカ星雲をさらに1時間30分撮影したのですが、その画像処理の時に青ズレが出ているのが気になって、最後までどうしても残るので元を辿っていくと、一枚一枚のライトフレームに載っていることがわかりました。

最初、CBPでのゴーストかとも思ったのですが、ASI294MC Proでこれまでも今回もそんなことに困ったことはないのでおそらく関係ないです。FS-60CBの収差かとも思いましたが、それならやはりASI294MC Proでも出てもいいはずです。この青ずれの方向が常に一定なのも気になります。

とりあえず比較はここまでにして、これ以降は透明度の悪い日の高々30分露光の画像で処理を進めても、あまり意味はなさそうなので、次はこれ以降にSV405CCで撮影した1時間半の画像での処理を進めます。


画像処理

次に気になったのが、SV405CCの画像にPCCをかけた時、同パラメータをいじっても背景が青や緑に寄ってしまうことです。。BackgroundNeutralizationでパラメータをかなりいじって試しても同様だったので、画像の方に何か問題がありそうです。いろいろ探っていって、どうやらRのノイズ幅がおかしいことが原因という結論にたどり着きました。上で見せたSV405のRGBのヒストグラムで赤の幅が大きく、山の高さが低いことです。このグラフの縦軸はlogスケールなので、あまり差がないように見えるかもしれませんが、実際にはGBと比べて1/3から1/4ほどです。

histgram_SV405CC

PCCやBackgroundNeutralizationは幅の方は補正してくれますが、高さの補正はしてくれないようです。そのため、今回はLineaFitで高さを合わせました。しかも1回ではまだ合わせきれなかったので2回LineaFitをかけ、その後PCCをかけると、やっと背景もまともな色になりました。この変な赤の振る舞いは、6月13日付のドライバーをインストールした後は出ていません。もし古いドライバーを使って撮影している方は、最新ドライバーにアップデートしたほうがいいでしょう。

PCC後はストレッチなどした後に、Photoshopに受け渡しました。上で述べた青ズレは仕方ないものとして画像処理を進めました。なので、恒星がいまいちなのは気にしないでください。また、透明度が悪かったためにノイズ処理などもしているので、カメラの性能をそのまま見ると言うよりは、SV405CCで少なくともこのくらいまでは出せるという目安くらいに考えてください。

Image94_clone2

透明度がかなり悪い日の撮影にしては、そこそこ色も出ているのではないでしょうか。この後、透明度のいいに日再度同じ画角で撮影しているので、随時画像処理していきます。


まとめ

今回の記事を書くのにものすごく時間がかかりました。理由は青ズレの解明でかなりの時間を使ったからです。

SVBONYさんとも連絡を取りながら、欠点もブログで正直に書いていくということ、そして開発側にフィードバックしてさらに改善していくことを互いに確認しました。ここらへんはメーカーとしての基本方針のようで、かなり好感の持てるところです。SVBONY初の冷却カメラです。ユーザーとしても新たなカメラメーカーが選択肢として出てくるのは大歓迎です。今後の成長も含め、できるだけ協力し、期待したいと思います。

まだ青ズレの原因は完全にはわかっていませんが、今回の一連の記事の中でできるだけ理由に迫ってみたいと思います。

次回の記事から新型ドライバーを適用します。さて、どこまで改善されているのでしょうか?


  1. SV405CCの評価(その1): センサー編 
  2. SV405CCの評価(その2): 撮影編 
  3. SV405CCの評価(その3): 画像比較
  4. SV405CCの評価(その4): 新ドライバーでの画像比較
  5. SV405CCの評価(その5): 青ズレの調査と作例
  6. 番外編1: 階調が出ない時のPedestalの効果
  7. 番外編2: ASI294MC Proでの結露


ゴールデンウィークに3連続撮影の3日目、地元牛岳において青い馬星雲を撮影しました。撮影時の顛末などは当日の記事をご覧ください。



今回はその後の、画像処理などについてです。


分子雲がここまで出た!

まずは結果を見てください。

「IC4592: 青い馬星雲」
masterLight_180s_ABE_PCC_ASx4_SCNR_bg2_cut_s
  • 撮影日: 2022年5月6日0時10分-2時57分
  • 撮影場所: 富山県富山市牛岳
  • 鏡筒: TAKAHASHI FS-60CB+マルチフラットナー(f370mm)
  • フィルター: なし
  • 赤道儀: Celestron CGEM II
  • カメラ: ZWO ASI2400MC Pro (-10℃)
  • ガイド:  f50mmガイド鏡 + ASI290MM、PHD2によるマルチスターガイドでディザリング
  • 撮影: SharpCap、Gain 150、露光時間3分x55枚で総露光時間2時間45分
  • Dark: Gain 150、露光時間3分、64枚
  • Flat, Darkflat: Gain 150、露光時間 0.1秒、64枚
  • 画像処理: PixInsight、Photoshop CC

一見してわかるように、分子雲がものすごい階調ででました。正直ここまで出るとは思っていませんでした。自分でもびっくりしています。

鏡筒はFS-60CBで、撮影時間は2時間45分。そこまで明るい鏡筒でもなく、そこまで露光時間が長いわけではありません。今回の大きなポイントは間違いなくASI2400MC Proでしょう。このカメラ、三つ子銀河の時もものすごく画像処理が楽でした。



今回も実は画像処理はかなりシンプルです。ASI2400MC Proで撮影した2回の撮影で、2回とも同じような状況なので、あながち気のせいというわけでもないと思います。

一方、この画像の反省点です。まず、撮影時の記事で述べたように、11mmの EWFの代わりに適当なFC76用のマルチフラットナーリングをいれたので、バックフォーカスが少しずれていて四隅が流れています。また、赤い部分があるのでもう少し強調しても良かったかもしれません。

とまあ、欠点もありますが、青い馬星雲としてはそこそこ表現できているので、個人的にはかなり満足です。


シンプルな画像処理

元々私は凝った画像処理は嫌いではなく、マスクなども多用しますし、ノイズ処理も必要なら強力なものを使います。でも今回はそれらのものがほとんど必要ありませんでした。

やったことはひたすら諧調を残すように、見えている分子雲を壊さないように、目で見える範囲の輝度に落とし込んでいくだけです。その際、星雲にかけるようなレンジマスクの類は一切使っていません。唯一使ったマスクが、PixInsight上で使ったStarNetで作った星マスクだけです。ノイズ処理もPhotoshopにある標準的なものを軽く使ったのみです。ちなみに今Photoshopの作業工程を数えてみたら「開く」から数えてわずか16工程でした。

よくある話ですが、素材がいい場合は色々凝った画像処理をすると、素材の良さを潰してしまうというのがあります。事実、この画像は2回目の画像処理で、最初はいつも通り凝った処理をしていました。 ちょっと恥ずかしいのですが、最初の処理を載せておきます。

masterLight_180s_ABE_PCC_ASx4_SCNR3_small

一見するとそこまで悪くないようにも見えますし、そのまま出しても特に変とも思われることもないでしょう。私も最初はこれでそこそこ満足していました。でも一旦PixInsightを閉じようと戻って、StarNetをかけた直後の背景画像を見た時に、ちょっとまずいと思ったわけです。

masterLight_180s_ABE_PCC_ASx4_SCNR_bg

この背景画像と比べると、最初に処理した画像では青い馬本体や分子雲などの淡いところの階調がほとんど潰れてしまい、のペーっとしてしまっていることがわかります。

ここで一旦戻って、2度目の画像処理となりました。分岐点はPixInsightでストレッチをした後の、Photoshopに手渡すところです。PixInsightの最終段階ではきちんと階調が残っていたということで、Photoshopでそれを生かせたかどうかだけが違いとなります。


ASI2400MC Proについて

シンプルな画像処理で仕上がることは、その撮影画像の素性の良さ、ひいてはこのカメラASI2400MC Proのポテンシャルの高さを示しているのかと思います。ASI2400MC Proのスペックだけ見ても、もちろんスペックも申し分ないのですが、メーカスペックに出てこない安定性というか、素直さが出ていると思います。例えばASI294MC Proはダイナミックレンジは同じ14bitで同じですが、三つ子銀河と合わせてASI2400MC Proで味わえたようなシンプル処理にも関わらず、ハッとするようなインパクトと、分子雲の透明感のような表現はこれまで経験したことがありません。

今日たまたま届いた「CCD/CMOSイメージセンサの性能と測定評価」という本を読んでいたのですが、例えば今ZWOが出しているカメラのスペックでは、この本で論じられているような細かいノイズなどは全然違いを表現できていません。また、ノイズについてはこれまで私もそれなりに気にしてきましたが、画像を作るはずの信号の方についてはあまり検討してこなかったことを実感させられました。この本についてはまた別記事で書評を書こうと思っていますが、我々ユーザーが知り得ない、表には出てこない性能差というのはあって然るべきなのかと思います。カメラセンサー自身の性能になってしまうので、ユーザー自身がどうこうできるものでありませんが、撮影した画像としてその違いが認識できるのかと思います。

一方、画像処理の途中で起こったハード的な不安定性のことも書いておかなければいけません。今回ASI2400MC Proを使うにあたり、テスト撮影時にNINAでは一度きちんと画像が撮れましたが、それ以降うまく画像がPCにダウンロードできません。SharpCapの方がまだ安定ですが、いい時はいいのですが、ダメな時は画像を落とす段階になりdroppedになりその数が増えていきます。

ダメな時の解決策は、一旦ROIでかなり小さい画面にして、うまくいったら元の画像に戻すことですが、これも完璧ではなく失敗する時もあります。一旦うまくいくと、それ以降は問題なくダウンロードできるのですが、そこまで持っていくのが何度かトライしなければなりません。どうも転送関係でうまくいかないのが原因かと思います。ケーブルを変えたりしましたが、同様でした。もしかしたら同様の現象の方もいるかと思います。少しでも情報共有ができればと思います。


Annotation

いつものAnnotationです。

masterLight_180s_ABE_PCC_ASx4_SCNR_bg2_small_Annotated



過去画像との比較

ちなみにこれまで青い馬星雲は過去に自宅で撮ったのみ。今回と同じFS-60CBですが、カメラはEOS 6D。青がでただけマシで、自宅だとこれくらいが限界です。今回牛岳に行ってせっかくの暗い場所だったので、自宅で撮りにくい青い馬星雲にしたのは正解だったようです。

masterLight_DBE_PCC_ASx5_ET_HT3a


まとめ

あくまで個人的な感想なのですが、このASI2400MC Proは間違いなく素晴らしいカメラでしょう。

普段フルサイズの撮影はEOS 6Dですが、ASI2400MC Proの冷却機能はダークフレームの管理ができるとかはすぐに見えるメリットです。6Dもノイズが少なく、かなり素直でとても信頼できるカメラです。それでもこのASI2400MC Proならば6Dを置き換えたくなります。

問題はその価格。欲しいと言ってなかなかすぐに手が出るものではありません。でも欲しい。カラーはこれがあれば満足な気がします。

今回はお借りしただけですが、いつか手に入れられるのか...。


2022年の初記事ですね。皆様、あけましておめでとうございます。

年末からずっと天気が悪くてほとんど何もできなかったのですが、1月8、9、10日の連休中は北陸としては意外なほど天気が良かったです。ただしシーイングや風など色々問題もあって、結果としてはどれもイマイチでした。記録がわりに簡単に書いておきます。

土曜の太陽

そもそも今週は水曜、木曜と2日連続で、夕方からSCA260を出し、極軸をとり、カメラ回転角とピントを合わせ、撮影準備完了とともに曇って片付けるという空振り続きだったので、かなり不満が溜まっていました。連休初日の土曜日は朝から快晴。午前中はCostcoで買い物に付き合い午後から久しぶりに太陽撮影です。黒点も派手に出ているようです。ただしシーイングが相当悪かったので、結果だけ示します。

13_35_01_lapl6_ap2550_IP_cut
AR2924群ですが、2つの大きな黒点と小さなたくさんの黒点がリングを作っています。問題は今のPSTだとHαの中心波長がきちんと見える範囲が画面の3−4割と一部のみで、今回のように複数の黒点が広い範囲に広がると、模様が均一に見えないことです。しかも右の黒点がピンボケのようになってしまいました。画面内でピントがずれるのはあまりないはずなのでちょっと不思議ですが、シーイングが悪かったのであまり議論しても意味がないのかもしれません。

プロミネンスもたくさん出ていましたが、一番大きなものを一つだけ処理しました。こちらもシーイングがよくないので、あまり気合が入っていません。
13_38_50_lapl6_ap1314_IP_cut


土曜の月

そのまま星が見え出した夕方になだれ込み、SCA260に載せ替えて極軸を取り直しますが、徐々に雲が出始めました。まだ月がでているので、試しにSCA260とASI294MM Pro(常温)で、BIN1(ピクセルサイズ2.3μm)で高解像を狙い、RGBフィルターでカラー化してみました。撮影は星雲撮影のセットアップなのでStickPCを使っています。USBでの取り込み速度が速くないのですが、さらに間違えてfitsで保存していました。そのため0.1fpsくらいのスピードしか出なかったので、RGB各20枚のみの撮影です。serにしていたらもう少し速度が出たのかと思います。

画像処理はなかなか面倒で、まずRGB別々にAS!3でスタックします。BIN1で画素数が多いため、Regisgtaxは使えないので、ImPPGで細部出しをします。ImPPGは全面ごちゃごちゃしている太陽だといいのですが、平面がいくつかある月だとDenoise機能がないため細部にノイズが残ってしまいます。

更に問題がRGB合成です。最初PIで位置合わせしようとしましたが、星が写っていないため不可。ImPPGで位置合わせをしました。ただし、スタック時に画面を歪ませて位置合わせしているはずなので、RGBで本当に合っているかどうかよくわかりません。今回はシーイングが悪くて分解能的にも意味がなく、全くやる気無しだったので手を抜きましたが、根本的にやり方を考えた方が良さそうです。

一応画像だけ貼っておきます。

Image04_cut_s


その後、月が沈むに伴いトール兜星雲を狙っていたのですが、風がビューゴー言い出して星がすごい勢いてブレていて、やがて雲が空全面を覆ったので、あきらめて撤収しました。


Masaさんの北アメリカ星雲

連休2日目の日曜は天気が悪くほとんど何も成果がありません。Masa@MasaAstroPhotoさんからTwitterのDMで長時間撮影した北アメリカ星雲のファイルを公開するので処理してほしいとの依頼がありました。Twitterを見るとすでに何人かの方が画像をアップされています。

画像を実際に見てみると3つあって、一番短い時間のものでも23時間とものすごい露光時間です。Masaさんに了解との返事をして、夕方くらいから画像処理を始めました。あまり詳しいことは書きませんが、
  1. まずxisfフォーマットを開き明るい方でリジェクトされた画像を見ると、どうも何度か画像が回転しているようです。実際の画像は測定すると9.5度程度回転しています。そのためまずは南北を揃えて、はみ出した部分をトリミングします。
  2. 左側の緑カブリがひどかったのですが、DBEを暗い部分に3点打ちして1回、さらに4点打ちしてもう一回かけることで除去できました。
  3. PCCで恒星の色を合わせますが、QBP IIを使っているとのことなので、見た目を合わせる程度にしかならないでしょう。やはりオレンジは出にくいです。
  4. ストレッチはASSで色を保ち、かつ赤がサチらないようにHTで。
  5. あとはStarNetで星マスクを作ります。
  6. ストレッチ後の画像とマスク画像をPSに引き渡して、炙り出しです。QBP IIだと赤がのっぺりしてしまいます。そのため星雲部の青を少し出します。
  7. 超長時間露光のためでしょう、ノイズらしいものはほとんど目立たないため、思う存分あぶり出すことができます。ノイズ処理は何も必要ありませんでした。
出来上がった画像です。北アメリカ星雲真ん中の透明感を重視してみました。
masterLight_PCC_clone_DBE_DBE_PCC_AS2_HT5

ついでにAnnotationです。
masterLight_PCC_clone_DBE_DBE_PCC_AS2_HT5_Annotated

一言で言うと、非常に楽な処理でした。長時間撮影でノイズが少ないのもそうですが、元の3枚の画像を見比べてみても、星像などんほとんど差がなく、とても丁寧に撮影したことがわかります。長時間撮影自信がそもそも大変だと思うのですが、ノイズのことを考えたら明るい星雲でもこれくらいの長時間撮影をするのがいいのかもしれません。

他の方も色々特徴的な画像処理をされています。Masaが比較検討動画を作るとのことなので結果が楽しみです。


月曜は再び太陽撮影

3日目の月曜は朝から快晴です。期待しながら太陽撮影の用意をしますが、実際に見てみるとやはりシーイングが全くダメです。午前に黒点とプロミネンスを何ショットか撮影しました。午後に少しだけシーイングがいい時間があったので少し撮影し直し、その後に雲で撤収です。

13_44_16_lapl6_ap2568_IP_cut

13_28_07_lapl6_ap2551_IP_cut
ピントがずれているかもと思い、カメラの傾きを緩めたらニュートンリングが出てしまいました。それでもまだ右上の黒点は少しピントがずれている気がします。傾きは後で戻しておきました。

10_41_00_lapl6_ap2544_IP_cut

10_16_58_lapl6_ap791_IP_cut


まとめ

3日間の結果としては全く冴えなかったですが、それでも晴れ間があっただけまだマシです。久しぶりでちょっと満足しました。 

昨年9月に自宅に遊びに来てくれたあんとんシュガーさん。その時はまだ機材を揃え始めたばかりで、長時間の撮影はできてませんでした。その後自宅前でアンドロメダ銀河を、FS-60CBをポラリスUに載せ、FUJIFILMのX-T2で約1時間半を切るくらいの時間で撮影したそうです。撮った画像は自分自身で、時にはTwitterでの猛者たちの力も借りて、PixInsightの練習も兼ね画像処理を熱心に進めてきてました。その様子はあんとんしゅガーさんのTwitterでの投稿を見てるとよくわかり、私もいくつかコメントを返し、いつかまた一緒に画像処理やりましょうと約束してました。


直前に訪問が決まる

1月22日の金曜日「そろそろどうですか?」と聞いてみたら「それでは明日の土曜日に」となり、急遽自宅に来てもらうことに。新潟の考太郎さんも以前から参加したいと表明されていたので、声をおかけしたのですが、直前のお誘いのためにやはり仕事で都合がつかないとのこと。とても残念がってくれたので、次回こそはぜひ参加していただきたいです。


到着

久しぶりのお客さんなので、午前中少し部屋を片付けました。午後1時過ぎ、あんとんシュガーさんが到着。早速見せてくれたのが、大阪あすとろぐらふぃ〜迷人会の井戸端さん製作の自由微動雲台の改良版。

IMG_1528

以前テストしたものよりも見た目もシンプルに、より頑丈そうになっていて、動きもスムーズそうでした。ただ、星を見てのテストまではできてないので、できれば実測でテストしてみたいです。ちょうどTwitterで井戸端さんと繋がって聞いてみると、揺れを収めるための制振用の柔らかい金属を挟み込んでいるとのことでした。でもこれは後から聞いた情報で、その場で見ただけではわからなかったです。これを聞いてますます実際の星で見てみたくなりました。Twitter上でも、他に手に入れられたからの意見で「相当頑丈に固定できる」との意見が出ていたので、かなりいいものに仕上がっているのかと思います。数は出ていないと思うので、手に入れられたユーザーは多分相当ラッキーなのかと思います。末長く実用レベルで使えるのか思います。


画像処理へ

さて、会話のままに引き続き画像処理になだれ込んでいったのですが、どうやってやるかが考えものでした。あんとんシュガーさんは見事にPixInsight (PI)門下になってしまって(笑)、WeightedBatchPreprocessing (WBPP)でIntegrationしたくらいの画像までは出せるようにはなっています。ただ、それ以降の炙り出しをPIの中だけでやろうとしているため、なかなか苦戦しているようです。まずはあらかじめPIでIntegrationまでした画像を用意して、今回はストレッチまで進めるところを実際にやってもらって、その後は別のソフト(今回はPhotoshop)に移して(あんとんシュガーさんはPhotoshopは持っていないので)やり方を「見て」もらう、としました。


PixInsightにて

まずIntegrationした直後の画像は、当然ですがPI上では真っ暗です。あんとんシュガーさんは、そもそもきちんと撮影できているかどうか不安で、この画像にどれくらいの情報が入っているのか理解し切れていないようでした。なかなか細部まで出てこなかったことから来ている不安だと思います。少し安心してもらいたくて、以前Twitterに投稿された画像(JPEG)から、私の方でStarNetで分離して、少しだけ炙り出した画像をTwitterで再投稿したことがあります。

Epqa74tVEAQiGyN_ABE_DBE_back

JPEGから出したものなので、情報は既に欠落しているはずです。それでもこれくらいの淡いところまで残っているので、もう素材としては十分なものが撮れているわけです。その眠っている情報を引き出すことはやはり多少の技術がいるので、今回はそこを重点的に説明することになりました。

といってもやったことは当たり前のことで、
  • AutomaticBackgoundExtractor(ABE)、DynamicBackgroungExtraction(DBE)で周辺減光など、できるだけフラット化しておくこと。
  • PhotometricColorCalibration(PCC)で恒星の色を正しいと思われるものに合わせること。
  • 主にArcsinhStretch(AS)を使って、彩度を落とすことなくストレッチすること。
がメインです。

まずABEですが、2次と4次で個別に処理してみましたが、どちらも結果にあまり変わりはなく、銀河の周りに大きなリングが残ってしまいました。ここでABEは諦めてDBEに。今回は銀河なので、暗黒帯や広い範囲にわたる星雲もなく、DBEでのアンカーは銀河以外のところに数多く、明るさの差があるところは細かく打っていきます。その結果、ABEの時よりはかなりマシになりましたが、それでもリングはうっすらと残ってしまっています。ちょうど良いタイミングでniwaさんがDBEの面白い使い方を示してくれていました。



この情報はあんとんシュガーさんが帰ってから読んだので、今回は試せませんでしたが、これでうまくリングが消えるかもしれません。それでもDBEで相当フラットになったので、M31のかなり淡いところまで出てくるようになります。ここがまず一つ理解してもらいたかった点です。

PCCはデフォルトの12等星まででなく15等星くらいまでにすること、Apartureをデフォルトの8でなく12くらいまで増やすことで、おかしな色バランスになることを防ぎます。詳しくはniwaさんたち委員会の結果を見るといいです。ちなみに私は(どこで知ったか、もう覚えていないのですが)おまじないのように15等星までやっていたので、これまで色バランスがおかしいと思ったことはないです。




次ですが、あんとんシュガーさんは色を出すのに苦労しているようなので、ASで彩度を落とさないようにストレッチしてみます。ASにはハイライトを防ぐオプションがあるのですが、これは通常オンにしておきます。ところが今回はこれをオンにしたことで少し苦労しました。ASを何段階かに分けてかけ、最後のみScreenTransferFunctionとHistogramTransformationで微調整して以下のようになりました。

_60_30__ABE_DBE1_Sam_toPS

最大にストレッチしきる手前で止めてあります。ASのハイライト防止のオプションのために恒星がサチることはいです。この状態でStarNetをかけると、一部の恒星が銀河や星雲などととして認識され、うまく分離できないという問題が出ました。恒星としての鋭さがないことが原因です。そのため、別途ストレッチを戻してから再びSFTとHTをかけて、あえて恒星をサチらせるようにすると、きちんと恒星と背景を分離できました。ここで作った恒星部をMorphologicalTransformation(MT)でDilationをかけて少し恒星を拡大してマスクとしました。

そうそう、このときあんとんシュガーさんから「サチる」がわからないと質問されました。Twitterとかでも使われてるのをみるけど意味が分からないというのです。多分これ理系用語なんですよね。「飽和」を意味するSaturationからきていますが、実験とかして電圧が測定範囲外で上に張り付いたりするときに「あ、サチってる」とか普通に使っています。

恒星をサチらせていない上の画像と、別で恒星をサチらせて作ったマスクを、16bitのTIFFフォーマットで保存して、Photoshopで開きます。でもここからはあんとんシュガーさんがPhotoshopを持っていないので、あらかたの作業工程を見せるだけになります。


Photoshopにて

Photshop上ではアルファチャンネルを利用して星マスクをかけて、銀河部分をあぶりだし、且つ銀河以外の背景のノイズを軽減します。特に銀河部の色出しは彩度、明度をともに調整しつつ自分の好みになるように調整します。中でもCamera Rawフィルターは便利なので初心者にも使いやすいと思います。

今回は星マスクを使いPhotoshopで処理しましたが、StarNetで分離した恒星画像とその他銀河を含んだ背景画像に分けた状態で処理し、レイヤーで重ねる方法もあります。ただ、PI上でArcsinhStretchを使ったために恒星が一部分離できなかったので、今回はこの方法を取ることができませんでした。後のレイヤーでの合成をうまくできるなら、初心者にはこちらの方がやりやすいと思います。

ノイズに関してはNik CollectionのDfine2やDeNoise AIが強力です。それでもこれらツールには限界はあるのと、ときには強力すぎることもあるので注意が必要です。

_60_30__ABE_DBE1_Sam_low

Photoshopに持ってくる前の画像と比べると、銀河の色は出ていますが、どこまで淡いのが出てるかに関しては、Photoshopで処理してもそこまで変わらないのかと思います。背景は銀河の炙り出しとともに荒れてきたのでDeNoiseをかけています。本当は銀河部だけのマスクを作って、銀河だけ炙り出すようなことをやるともう少しましになるのかと思いますが、今回はそこまで時間をかけることができませんでした。


課題

それらのことを含めて、まだできそうな改善の余地をあげておくと
  • DBEでもう少し銀河回りのリングをうまく除去する
  • Pink starの除去
  • 銀河部だけのマスクを使った処理、そのための銀河以外の背景のノイズ処理
  • 最後の微調整に時間をかけること
などかと思います。

結局午後6時くらいまででしょうか、5時間くらいずっとほぼ休憩なく画像処理でした。私自身いつものように紆余曲折しながら長い時間かけましたが、こういったごちゃごちゃした過程を、丁寧に一つ一つ潰しながら、時に後ろに戻って時間をかけてやっていくということを見せたかったのです。

あんとんシュガーさんはすごく熱心なので、多分今回やったこと、見てもらったことを、また自分で繰り返してくれるのかと思います。その場でも話していたのですが、前回9月にきたときにはまだ処理する画像ファイルも無いような状態だったので、すでに今回までに相当大きく進歩しています。春になれば北陸も晴れる日が増えてくるはずなので、撮影もどんどん重ねていくのかと思います。

重要なのはせっかく撮影した画像からいかに情報を引き出してやるか。環境の良いところで長時間撮影したものは処理も楽なのですが、自宅前で撮影したようなものは、画像処理もある程度手間をかけてやらなければなかなか見栄えのするものにならないです。これからも楽しんで画像処理をすすめて頂けたらと思います。


ネオワイズ彗星の画像処理をしていて、検証できたことが一つありました。バイアスノイズの影響です。

4連休なのに天気がずっと悪くてどうしようもないです。少しでも見えれば電視観望くらいと思っているのですが、さすがに雨が降っているようでは手が出ません。仕方ないので画像処理時少し時間を費やしました。


なぜか縦縞ノイズが残る?

まずこちらを見てください。

integration1_ABE_DBE2_STR_stripenoise_cut


初日に撮影したうちの処理途中のネオワイズ彗星を少し見やすくしたものです。炙り出しを進めると縦方向に縞ノイズがあることが分かります。このノイズ全体にあるのですが、特にダストテイルの真ん中下部が分かりやすいかもしれません。分かりにくい方は今見ているモニターの明るさをできるだけ明るくしてみてください。

この時は速報性重視で時間が勝負だったので、撮影から帰ったその夜中に、しかも朝には仕事があるにもかかわらず、PixInsightでライトフレームだけ使い、バイアス補正、ダーク補正、フラット補正をしていない状態で出てきたものです。

このノイズがあるために画像処理を控えめにして縦縞ノイズを目立たないようにしたものをブログに載せています。コメントでRAINYさんから「屏風絵のようで和を感じる」などと評価いただいたのですが、私はそんなに心の綺麗な人間ではないので、本当はもっと炙り出したかったのです(笑)。その時のコメントでこっそり書いてますが、まだまだ彗星の画像処理も未熟で迷走状態だったわけです。


縦縞ノイズの原因

原因は比較的はっきりしています。マスターバイアスフレームを炙り出したものを見てみます。

20191109_bias-6D_ISO1600_s4000_x100

縦縞の様子が似通っています。最初は何もノイズ処理をしていなかったので、取り除いていなかったバイアスノイズが出てしまったと推測されます。


真面目にノイズ処理をしみた

1回目の撮影はあまり真面目にノイズ処理をやらずに縦縞ノイズが残ってしまったので、2回目の撮影ではきちんと各種補正をしようと思い、PixInsightで
  • バイアス補正あり、ダーク補正あり、フラット補正あり
で画像処理をしました。詳しく言うと、
  1. ライトフレームISO1600、30秒露光を20枚に対して
  2. バイアスフレームはカメラにキャップをして、暗所で撮影、ISO1600で最短露光の1/4000秒を100枚スタック、ただし半年以上前に撮影したもの
  3. ダーク フレームはカメラにキャップをして、暗所で撮影、ISO1600で30秒露光を50枚
  4. フラットフレームはライト撮影時の105mmレンズを開放のF2.4にして、ISO100で1/50秒露光で50枚、ここにあるように障子の漏れ光を利用して昼間に撮影
となります。結果を見ます。

masterLight_BINNING_1_FILTER_NoFilter_EXPTIME_30_integration_DBE

全ての補正をしたのでこれでOKと思っていました。でもまだ縦縞ノイズが残るんです。なぜでしょう?ここから迷走して少し時間がかかってしまいました。

でも、鋭い方ならここの時点でピンと来た人もいるのかと思います。この時点で全てのヒントは出ているので、もし理由を考えたい方がいたらここでじっくり考えてみてください。
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.


縦縞ノイズが残った原因

何が問題だったか、答えを言いますとフラットフレームだけISOを100として撮影していて、その他ライト、バイアス、ダークフレームのISO1600と違っていたことが原因です。

フラットフレームを撮影する際、昼間の障子紙越しの光を使ったのですが、十分明るいのでISO100、1/50秒で撮影しました。この際のISOがライトフレームの1600と大きく違ったことが問題だったというわけです。ISO100で撮影したフラットフレームに残っているバイアスノイズが、ISO1600で撮影したライトフレームのバイアスノイズを補正できなかったのです。

その証拠にライトフレームと合わせるためにフラットのISOを1600と上げ、その代わりに露光時間を1/2000秒と短くして撮影し直し、上記で試した
  • バイアス補正あり、ダーク補正あり、フラット補正あり
で、フラットファイルだけを新しいISO1600のものに変更して処理し直したものを示します。

masterLight_BINNING_1_FILTER_NoFilter_EXPTIME_30_integration_DBE

これまで出ていた縦縞ノイズが綺麗さっぱり消えています。分かりやすいように目立つ場所の比較をしてみます。左が間違ったISO100のフラットフレームで補正した画像、右が正しいISO1600のフラットフレームで補正した画像です。

comp_center

明らかにライトフレームと違うISO100の補正では縦縞が残っていて、ライトフレームと同じISO1600では補正がうまく行っているのがわかると思います。

ここで一つ結論が出ます。

以前紹介した短時間で撮影したフラットフレームは、ライトフレームとISOを合わせる必要がある。そうでないとバイアス補正がうまくいかない。

ということです。以下のページを見て参考にされた方がいましたら、是非とも今回の結論に合わせてISOを揃えるようにしてください。





このような淡い縦縞ノイズは、相当な炙り出しをしない限りは問題にならないかもしれませんが、今回のような彗星の淡いテイルなどは確実に影響を受けます。最初シンクロニックバンドに直交するように縞が出てしまって「なんじゃこりゃ?」となったわけです。

実はこの短時間フラットフレーム撮影のISOを合わせた方がいい件、確かどなたかがコメントかTwitterで指摘してくれていたと思ったのですが、その発言を見つけることができませんでした。今回はやっとここが検証できたことになります。

これでめでたしめでたしかと思いきや、でも実はそうでもなかったんですよね。これ以降詳しく書きますが、こちらの方の検証で相当時間を食ってしまったというのが実情です。


ここからがバイアス補正の謎

さて、これまでの議論が正しければ、フラット補正やダーク補正なしで、正しいISOのバイアス補正だけをした場合も綺麗に縞ノイズが消えるはずです。ところが、ところがですが、
  • バイアス補正あり、ダーク補正なし、フラット補正なし
という状態で処理した画像を示しますが

masterLight_BINNING_1_FILTER_NoFilter_EXPTIME_30_integration_DBE

上の画像が示す通り、なぜかバイアス補正だけでは縦縞ノイズは消えないんですよね。いろいろ検証しましたが、いまだに謎です。やったことは

縞ノイズが残った場合
  1. バイアス補正なし、ダーク補正なし、フラット補正なし
  2. バイアス補正あり、ダーク補正なし、フラット補正なし
  3. バイアス補正あり、ダーク補正あり、ISOの違うフラット補正あり

縞ノイズが消えた場合
  1. バイアス補正あり、ダーク補正あり、正しいISOでのフラット補正あり
  2. バイアス補正なし、ダーク補正なし、正しいISOでのフラット補正あり
  3. バイアス補正あり、ダーク補正なし、正しいISOでのフラット補正あり
です。ここからわかることは、とにかく正しいISOでのフラットで補正でないといずれも縦縞ノイズが出てしまうということです。

繰り返しになりますが、以下の2通り
  1. バイアス補正なし、ダーク補正なし、フラット補正なし
  2. バイアス補正あり、ダーク補正なし、フラット補正なし

でバイアス補正が共にされていないという事実から、バイアスファイルに問題があるのではとも思いました。半年以上前に撮影されたものなので、もしかしたら温度とかの条件が違うからかもしれないからです。念のため、今回さらに新たにバイアスフレームをISO1600、露光時間1/4000秒で100枚撮影しました。そのバイアスフレームを使って、
  • バイアス補正あり、ダーク補正なし、フラット補正なし
で、試しますが、

masterLight_BINNING_1_FILTER_NoFilter_EXPTIME_30_integration_DBE

上のようにやはり縞ノイズが残ってしまいます。バイアスフレーム自身は直近で撮影していて流石に問題ないと思うので、むしろバイアス補正が全く効いていないような状態です。確かにライトフレーム撮影直後にバイアスフレームを撮影したわけではないので数日の時間差はありますが、それでもその程度の時間差でバイアス補正が効かないとしたら、やはりこの補正方法自体が役には立たないでしょう。

結局この新しいバイアスフレームでもいろいろ試しましたが、結果は全て上と同等で、正しいISOでのフラット補正をした場合のみ縦縞ノイズが消え、バイアス補正は縦縞ノイズに何ら関係ないとなりました。

一方、ダーク補正につても考えます。単純に考えるとフラットフレームの中にバイアスノイズが含まれているので、正しいフラットフレームならバイアスノイズを消せるはずというので理解はできます。これが正しいならダークフレームの中にもバイアスノイズは含まれていて、ダーク補正だけでも縦縞ノイズは消えるはずです。
  • バイアス補正なし、ダーク補正あり、フラット補正なし
というのも試しましたが、縦縞ノイズは消えませんでした。少なくとも今回の検証ではダークフレームに含まれるはずのバイアスノイズは、ダーク補正において縦縞ノイズに何の影響も与えていないという結果です。


うーん、何がおかしいのか?

ちなみにこの結果は、一連の状況を経験してから、改めて一から全ての処理をし直し、再確認しています。それでもなにか勘違いなどで間違いを繰り返している可能性はあります。ただ、最後はバイアスの有無だけとかなり物事をシンプルにしたので、おかしいところは相当限定されていると思います。

これまでのことから、PixInsightにおいては、バイアス補正のみだとうまく補正できていない、もしくは補正し切れていなくて、正しいフラット補正(ISOを合わせたという意味)においてのみバイアスノイズの補正がうまく行われているようだということが言えます。

もしかしたらPixInsightのバグかもしれません。でもバイアス補正はPixInsightの相当基本的なところなので、かなり検証されているはずです。

私がとんでもない勘違いをしている可能性もあります。一つの可能性が、バイアスノイズと思い込んでいるものが実はフラットフレームのみに現れる全く別のノイズかもしれないことです。でもこれもあまり正しいとも思えません。

今回の検証が本当に正しいのかどうか、もしどなたか追試していただける方がいてくれると嬉しいです。


回転花火銀河M101を撮影してみました。この天体は電視観望では何度か観たことがありますが、撮影は初めてです。自宅からですが、富山特有の北の明るい空です。さて、どうなることやら。


light_BINNING_1_integration_ABE_DBE_STR_DBE_STR_SNP_all_PS4_cuts
銀河部分を大きくみるために最終結果を切り出したものです。


撮影

今回はもう少し北側のM101に挑戦です。挑戦と言う意味ですが、富山は日本海側のため基本的に北が市街地になっているので、北の空はどうしても明るくなってしまい、これまでも撮影は避けてきました。

前回、三つ子銀河の自宅からの撮影がQBPを入れたまま知らずに撮影してしまうというアクシデントのおかげか、思いの外うまくいったので味をしめてしまいました。これならもう少し明るい領域でもなんとかなるのではと思い、この季節北東から真北に動いていくM101にしました。

機材セットアップは三つ子銀河の時と全く同じで、TSA-120にQPDでASI294MCProです。撮影自身は順調。ガイドもほとんどズレなしです。透明度はというと、三つ子銀河の時よりは悪かったと思います。見た目でもわかるくらい三つ子さんの時は細かい星まで散りばめられていましたが、M101のこの日の空は、悪くはないですが、まあそこそこと言ったくらいでしょうか。普通に星は見えますが、細かい星まではあまり見えません。

撮影はStickPCを利用したリモート撮影です。いったんセットして撮影が始まってしまえば、あとは部屋からヌクヌク状態でモニターすることができます。予定では3時間以上の露光時間を狙います。ところが、天頂越えまでまだ少し時間がある頃、部屋からリモート接続のでダウンロードされる画像を見ていると、星が流れて出していることに気づきました。おかしいと思い、外に出てチェックしてみると、天頂越え直前でカメラが三脚の当たって止まってしまっていました。これまでこんなことあまりなかったのですが、鏡筒が長いと天頂近くになるとカメラ側が脚に当たってしまうこともあるのがわかりました。こんなことならAPTで赤道儀の反転テストを試せばよかったです。赤道儀が明らかにずれてしまったのと、もうしばらくすると月も出てくるので、この日はこれで終了としました。5分露光で30枚なので2時間半分の撮影です。


全体の流れ

ガイドのズレを見るためにいつものように2時間半分の画像を動画にしてみます。

Blink

今回は1方向に動いているわけではなく、一度左に行って、右に戻ってきているような感じです。APTのDithering Distanceで4としてあるのですが、このランダムな動きがその4というので動いているのかもよくわかりません。1方向のドリフトではないのですが、まだたわみか何かが原因で動きすぎている気がします。

上の動画は明るさを規格化してしまっていますが、一番最初と一番最後ではヒストグラムで見ると明るさが1.5倍くらい違います。なぜかだんだん暗くなっていきます。最初北東にあったM101が高度を上げながら真北へ向かっていくくらいまでを撮影したのですが、普通に目で見ても北の方が明るいのは確かです。高度が上がっていくから暗くなるのか、夜中になり町の明かりが減っていったから暗くなっていったのかはわかりませんが、(QBP有り無しで高々3倍の明るさの違いなので)1.5倍は無視できないくらいの違いです。2時間半分あるのですが、淡いところだけを出すのなら後半のみ使うくらいの方がいいのかもしれません。今回は、結局画像処理をやっている過程で、最初の30分を使うのをやめました。そのため淡い部分がもう少し出るようになった気がします。


画像処理

今回結構色々学びました。特にAPTはまだまだ経験不足で慣れていないことも多いので、癖を知っておく必要がありそうです。


1. light frame

撮影した画像を見てみると、どうもホワイトバランスが根本的に取れてません。QBPのせいでしょうか?赤がどうしても強くなってしまいます。でも、後のフラットで逆に赤が暗くなったことを考えると、QBPのせいでもない気がします。

ight_redshift
rawファイルをカラーバランス補正なしでオートストレッチした画面。
ヒストグラムを見ても赤が支配的です。

SharpCapの場合はカラーバランスをソフト側でとることができて、fitsファイルにもそれが反映されてます。APTの場合にはカラーバランスを調整できる場所がありません。いや正確には見かけのカラーバランスは調整する場所はあるのですが、画面だけに反映され、fitsファイルにはそれは反映されないようです。


2. dark補正

今回はdarkの補正の時にアンプグローをうまく差っ引くために、前回のUTOさんのアドバイスを元にOptimizeオプションをオフにして処理しました。  オンとオフで比べてみます。

light-BINNING_1
デフォルトのOptimizeがオンのまま。右上にひどいアンプグローが残っています。

light-BINNING_1
ダーク補正の際のOptimizeをオフにした場合。
アンプグローは相当マシになります。

最初BatchPreProcessで設定場所が見つからなかったので、ImageCalibrationの中でOptimizeをオフにしてバッチ処理でなくその後もマニュアルでやったのですが、後にBatchPreProcessの右側のグローバルオプションのところに設定できる場所があることを見つけました。これでバッチ処理で手間をかけずに進めることができるようになりました。

ちなみに、ダークだけをものすごく炙り出してみるとこんな風になります。

Capture 00_12_39_00001 00_17_12_c_d

右上が目立ちますが、左上にもそこそこのアンプグローがあり、よく見ると右下にも少しあります。3箇所もあるので大変そうですが、ダーク補正でOptimizeをオフにすることで解決できるので、もうそれほど大きな問題ではないのかと思います。


3. bias補正

最初bias補正をすると画面が暗くなりすぎてしまいました。これはbais frameの撮影時のbiasの値(オフセット)が大きすぎたことと、次に書くフラット補正がうまく行っていなかったことが原因かと思われます。

badbias
カラーバランス補正をしてオートストレッチすると青と緑が暗すぎてしまう。
バイアス補正でオフセットが引かれ過ぎていると考えられる。

ligh frameの撮影時、APTでのbias設定が40でした。そのためbias frameの(オフセットの意味での)bais値は撮影時に40以下にしています。最初オフセットを30にしてSharpCapdで0.0032msで撮影したのですがまだ十分下げ切れていませんでした。それに合わせてflat frameのカラーバランスも合っていなかったせいで、赤が過補正のため青と緑が相対的にオフセットを引かれすぎた状態になってしまって、出来上がり画像の青と緑が暗すぎてしまったのかと思います。

そのため改めてbiasを撮影して、その際オフセットを20に下げ、今度は念のためAPTで撮影しました。一応これでうまく行きましたが、実際にはbias値を下げたからよくなったのか、後述のフラットのバランスが取るように対策したからなのかは不明です。


4. flat補正

その中でも、今回の撮影では特にflat補正で学ぶことが多かったです。TSA-120の口径が大きすぎて、いつもやっているようなiPadでのフラット撮影は出来ませんでした。手持ちのiPadでは画面が小さすぎてはみ出てしまうのです。その代わりにMacbook Proのモニターをフラットパネル代わりに使ってやりました。使ったツールは天リフさんのこのページです。



このページはカラーバランスを整えることができるので、非常に便利です。

短時間露光のflat frameなので、最初はディスクへの画像取り込み時間が速いのでSharpCapで撮影していたのですが、条件をそろえる意味で途中からAPTでの撮影に切り替えました。ゲインはlight frameと同じ220、露光時間は以前の検証から100msです。枚数は50枚程度ですが、これも以前の検証からこれくらいの枚数で十分だと思われます。

ここから色々不思議なことがあり、まだ完全に解決できていません。あいからわらずフラットは謎が多いです。

上の「1. light frame」のところでも述べましたが、APTでlight frameを撮影すると赤色が一番強調して撮影されます。上のスナップショットでヒストグラムのところを見ると、赤が青や緑に比べて1.5倍くらい明るいのがわかります。

これは有意なずれで画像処理に影響を与えるくらいかなり大きな差です。最初QBPのせいで赤くなっているのかなと思っていたのですが、不思議なことに鏡筒とカメラの設定を全く状態を変えないでMacのモニターでホワイトバランスをとったものをflat frameとして撮影すると、今度は赤が一番暗くなるのです。青や緑に比べて2分の1以下くらいの明るさです。

flat-BINNING_1

このflat frameを使いフラット処理をすると、もともと1.5倍明るい赤が、2分の1位の暗さの赤で割られるので、その結果赤が3倍くらい明るいlight frameが出来上がることがわかりました。そのため少なくともPIでは、light framとflat frameのカラーバランスは、そこそこ同じようにする必要があることがわかります。実際にはMacの画面のカラーバランスを、あらかじめ赤が3倍くらい明るいものにして、それを撮影することで、そこそこlight flameと同じカラーバランスの取れたflat frameを作ることできるようになりました。

もう一つ問題がありました。撮影したflatの画面のうち赤色だけ様子がおかしいのです。RGBに分解してみてやると、青や緑はいたって普通に見えますが、赤色だけはセンサーの長手方向に蝶形になるような、形が現れてきて、変に見えます。

flat_BINNING_1_integration_RGB_VNG
赤だけ変な形が現れる。

とりあえず軽減する方法は見つけました。どうもフラットパネル(今回はMacbook Proのモニター)で撮影することが悪さをしているようです。まず、フラットパネルを使わずに、昼間にスーパーの袋を二重に重ねてflatを撮影してみると、この変な形は随分とマシになります。カラーバランスはその時に入る光に依るので、少し赤っぽい、実際には電球色の光を入れています。

flat_BINNING_1_integration1_RGB_VNG
蝶のような形はなくなったようにみえます。 

画像を見ても少しマシになっていることがわかると思います。でもマシになっただけで、やはり同じような形は残っています。

で、結局最終的にやったことはというと、flat補正をしないという選択肢を取りました。どう見てもこれが一番マシなのです。そもそもカメラがフォーサーズ相当で周辺減光があまりないので、それほどフラット補正にこだわる必要はないのかもしれまん。

でもここで不思議なのは、同じ鏡筒で同じ条件で撮影しているのに、なんで普通のlight frameの撮影の方では、こんな変な模様が見えてこないかです。まだflat frameの撮影方法に問題があるような気がしています。ここらへんは時間があったらもう少し試してみます。


5. 仕上げ

フラット補正なしにしてスタックした画像がまともになるとやっと、その後の仕上げの画像処理に困ることはなくなりました。ちなみにこれ以前のフラットが合っていない時の画像処理は熾烈を極め、時間も相当かけてしまいました。ちなみに最後のフラット無しの結論に至るまでに、PixInsightでのフルスタックの画像処理の回数は11回。そのうちPhotoshopに移って最後まで処理を進めたのが4回。下処理がきちんとしていればいるほど、画像処理にかける時間も少なくなりますし、出来上がった画像もいいものになります。


結果

画像処理の段階で色々紆余曲折はしましたが、そこそこ満足のいく仕上がりになりました。透明度の差もあるのでしょうか、三つ子銀河の時ほどくっきり出すのは難しかったですが、アンプグローが軽減できたのと、フラットがマシになったぶんもあり、淡い部分をより炙り出すことができていると思います。

light_BINNING_1_integration_ABE_DBE_STR_DBE_STR_SNP_all_PS4_cut
  • 撮影日: 2020年4月16日21時29分-4月17日0時20分
  • 撮影場所: 富山県富山市下大久保
  • 鏡筒: Takahashi TSA-120
  • 赤道儀: Celestron CGEM II
  • カメラ:  ZWO ASI294MC Pro
  • 撮影条件: ゲイン220、温度-15℃、露光時間300秒x24枚 = 2時間0分 
  • フィルター: サイトロン QBP (48mm)
  • PixInsight、StarNet++、Photoshop CC、DeNoise AIで画像処理

自宅でこれなら、まあ十分ではないでしょうか。これも一度暗いところへ行って撮影してみたい対象です。一体どれくらい変わるのか、真ん中のしわしわの部分をもっときれいに出せたらと思います。

その一方、富山の北の空でこれだけ出るのなら、もう少し自宅で時間をかけていろんな銀河を探っていきたくなりました。自宅からなら、天気さえ良ければ平日でも比較的気楽に試すことができます。


Annotation

天体の名前入りの画像です。こちらも定番になりそうです。

light__integration_ABE_DBE_STR_DBE_STR_SNP_all_PS4_cut_Ann


前回の三つ子銀河は全面縦横ズレなしだったのですが、今回は右はあっていても左側が斜めになっています。北の空だからでしょうか。座標に対しては画面が歪んで写るんですね。


まとめ

TSA-120の自宅での撮影第2段。QBPのおかげもあり、北の空の銀河でもそこそこ写ることがわかりました。銀河の撮影も楽しくなってきました。TSA-120での撮影を今しばらく続けていきたいと思います。

その一方、まだ画像処理では理解不足なところがあります。特にflatはいまだにミステリーです。きちんとしたflat撮影方法をもう少しきちんと考える必要がありそうです。
 

過去の縞ノイズでも試してみる

もしかしたら、flat補正の効果が今回の撮影だけの特別な場合だった可能性もあります。なので、過去の画像で縞ノイズが出たファイルを再処理してみます。使ったのは、2年以上前のPixInsightを最初に使い始めた頃に撮影したM33。

シンプルにするためにフラットの有無だけで比較します。撮影条件は
  • 鏡筒: タカハシFS-60Q、焦点距離600mm
  • 赤道儀: Celestron Advaned VX
  • カメラ:  ZWO ASI294MC
  • ガイド: ASI178MCと50mmのCマウントレンズをPHD2にて
  • 撮影条件: SharpCapでゲイン270、温度-15℃、露光時間300秒x25枚 = 2時間5分
  • ディザー: なし 
  • ファイル保存形式: RAW16bit、fits形式
です。本質的なところではカメラは常温ですが同じ、長時間、ディザーなしというのでよく似た条件です。Flat frameの内容はというと、記録から
  • flat frame: light frame撮影後すぐに、鏡筒に状態でスーパーの白い袋を2重に被せて撮影。ゲイン270、露光時間300秒、常温で、3枚撮影。
となっているので、これも撮影後すぐにとったとか、枚数が少ないとかの条件も同じです。この似た条件というのが鍵になる可能性がありますが、まずは時期的にも違うという点で検証して一般性を見ます。

まずはflat補正あり。やはり以前と同じように縞ノイズは盛大に出るので再現性もあります。

light-BINNING_1

次にflat補正なし。ゴミの跡とかは目をつぶってください。当然周辺減光も出ますし、アンプグローも残ります。その代わりに、バラ星雲の時と同じで縞ノイズは消えます。厳密に言うとバラ星雲の時も今回のM33の時も同じで少しの縞ノイズは残っています。でもflat補正のあるなしで、いずれも劇的な違いがあることはわかります。

light-BINNING_1

この時点で、PIに限られますが違う画像でも起きているので、一般的にも十分あり得る話だということがわかります。


PixInsight以外では?ステライメージで確かめてみる

もしかしたらこれ、PIのflat補正のアルゴリズムに問題があって、PIだけの問題という可能性があります。他のソフトの代表で、ステライメージ8で確かめてみました。

そう言えば最近Windowsを入れ直してステライメージまだ入れてませんでした。久しぶりに再インストールして、M33を使ってflat補正をしてみました。自動処理モードは使わずに、詳細編集モード(マニュアルモード)で試しました。自動処理モードはこれまでもほとんど使ったことがないのと、一応は試したのですがうまく色が出なかったからです。

最初の結果がこれです。

light

「お、縞ノイズないじゃん!なんで?PIだけの問題か?」と思ったのですが、よくみるとゴミの跡も残っていてフラット補正全くされていないみたいです。自動処理モードでやっても結果は変わらず、flatファイルが悪いのかとか色々疑ったのですが、原因はステライメージのバグ。バージョン8をディスクからインストールしたてで、アップデートしていなかったことが原因でした。現行のバージョン8.0hにして試してみると、

light

ちゃんとflat補正もされて、縞ノイズも盛大に出るようになりました。なので、PIだけの問題でないということが分かります。

ちょっと蛇足です。久しぶりにステライメージ触ったのですが、随分といろんなことを忘れていました。今回サボりましたがflat darkとかも本当は撮らないとダメ(flat darkあるなしで縞ノイズに影響がないことは確かめています)なんですよね。その代わりにbiasファイルを撮らなくていいとか、今思うとPIとはだいぶん違います。

初心者向けの自動処理モードも「ほとんど何も設定出来ない」との批判も多いですが、私はこれでいいと思います。多分ステライメージは、初心者にとっては天体画像処理ソフトとしては唯一の選択肢です。日本語で操作できて、マニュアルも(十分ではないかもしれませんが)日本語で読むことができてという意味で、敷居がずいぶん低いはずです。初めて天体写真に挑む人は、一番最初は本当に何も分からず手探りでやるので、自動モードもこれくらい簡潔にしておくのはある意味正しいと思います。自動モードで理解できてきたら、詳細モードに行って、詳細モードでいろんな操作をして理解して、その上で不満が出たらより高機能なPixInsightという手もあるかと思います。

ステライメージで一つ不満があるとしたら、「ベイヤー・RGB変換」のところでしょうか。バッチ処理が無いので、一枚一枚手で変換しなくてはダメなんですよね。ALTキーでI、ALTキーでYで、Enterで処理、マウスで最小化ボタンを押して次の画像というのを繰り返し、出来るだけ楽に進めてます。今回20枚程度でしたが、100枚とかはやりたくないです。最近はPIで1000枚とかの処理もする時があるので、これだとステライメージでは現実無理です。せめてコンポジットやホット/クールピクセル除去機能みたいにバッチ処理ができるようになるといいのですが。


ついでにDSSでも

あと日本で流行っているスタックソフトの残りは、惑星用除いたらあとは、DSS(DeepSkyStacker)とRAP2くらいでしょうかRAP2は有料で持っていないので試せませんが、DSSはフリーなので試すことはできます。DSSは星を始めた4年前にまだ有料ソフトに手を出す前に、フリーだからと少し試しただけくらいの経験しかありません。もう久しく触っていませんが、いい機会なので試してみます。

昔はものすごく複雑だった印象があるのですが、機能自身は今思うとまあ一直線で素直ですね。少なくともPIに比べるとはるかにシンプルです。特に困ったところは2箇所だけで、一つはRegisteringのところで進まなくなってしまったところ。これは検出する星の数が多すぎたことが原因で、「Register Setting」の「Advanced」タブの「Star Detection Threshold」を増やして、検出する星の数を減らすことで解決しました。もう一つは一度最後まで処理をしたのですが、モノクロのままだったので、メニューの「RAW/FITS Settings」の「FITS Filters」できちんとdebayerしてやることでした。

さて結果です。フラットもうまく補正されたようです。

light

あー、ダメですね。やはり縞ノイズ出ますね。

と言うわけでflat補正問題、PixInsightだけの問題でもなく少なくともステライメージとDSSも含めて、同様に縞ノイズを発生させることがわかりました。日本で使われている3大スタックソフト(惑星用除く)で同じ状況というので、flat補正が縞ノイズに与える影響はかなり一般的と言っていいかと思います。


とりあえず、今回の記事のまとめ

他のデータでも、他のソフトでも同様の傾向で、flat補正の影響はあると言えそうです。

ただしやはり気になるところは、flatの撮り方が2例とも撮影後すぐに同露光時間、同ゲインで、スーパーの袋をかぶせて空で撮っていることです。露光時間が長いので、明るさ的に足りないことはないと思います。ただし、カラーバランスはかなり黄色っぽくなってしまっています。また、枚数が足りない可能性もあります。

次回以降はここら辺のflat frame自身についてもう少し検討できたらと思っています。実は今回の謎の答えもう出ています。今検証を進めているところです。乞うご期待です。



多分このシリーズ、長くなります。普段の記事を全然長いと思っていない私が長くなると思っているので、多分本当に長くなります。試したいことがありすぎるので、書けるとこまで書きます。途中で力尽きたらごめんなさい。

今回縞ノイズの一つを、多分特定しました。最初に断っておきますが、限られた条件でのことかもしれません。この記事を読んで試してみても、全然効果がなかったと言う方もいるかもしれません。ですが幾らかの悩んでいる方の解決にはなると思います。私自身、他の方の環境でどうなるか興味があるというのもあります。

comp

この比較写真のように違います。左がこれまでの縞ノイズ、右が無くなった(実際には軽減された)場合です。以下、詳しく説明します。


バラ星雲で出た縞ノイズ

この間のEVOSTAR 72EDでのバラ星雲の撮影で、ディザーをしなかったために縞ノイズが出たという報告をしました。

integration_DBE_PCC_AS_cut


その後、上記の縞ノイズを可視化した記事を書きました。この動画は結構反響が大きかったので、ご覧になった方も多いかと思います。






なぜか突然縞ノイズが消えた!?

この後、もう少し縞ノイズの検証をしてみようとファイルをいじってみました。とりあえずシンプルなところからと思って、rawのlight frameをDebayerしてStarAlignmentだけして縞ノイズを再現しようとしたのです。ところがところが、縞ノイズが綺麗さっぱりなくなっています。

integration

拡大です。
integration_cut

え?
なんで?
全然縞ノイズ出てないじゃん!
せっかく縞ノイズの解析しようと思ってたのに!

さあ、ここからが戦いの始まりです。


PixInsight用語

今回、PixInsight (PI)用語がたくさん出てきます。PIに慣れていない方のために、簡単に解説しておきます。
  • PixInsight: 世界的に有名な天体画像処理ソフト。英語でものすごくとっつきにくいが、高機能。
  • BatchPrepocessing: 撮影したファイル(light, bias, dark, flatなどの各frame)を掘り込んでおけば、スタックまでボタン一発でやってくれる便利な機能。
  • master: bias, dark, flatなど、他数枚の補正ファイルを一度処理すると、スタックされた一枚のmasterというファイルをそれぞれ作ってくれる。以降はそれを使うと処理時間を削減できる。
  • ImageCalibration: BatchPrepocessingのような自動で処理する以外に、マニュアルでもっと細かくオプションを指定しながら処理する方法がある。これはbias, dark, flatなどの補正をマニュアルでする機能のこと。
  • Debayer: 同様にマニュアル処理の一つ。モノクロのBayer配列のRawファイルをカラー化すること。
  • StarAlignment: マニュアル処理の一つ。多数枚数の画像の星位置を合わせること。PIでは平行移動、回転にのみならず、画面を歪ませて星の位置をそれぞれ合わせることができる。
  • ImageInteglation: マニュアル処理の一つ。他数枚の画像をスタックすること。
  • ScreenTransferFunction: 簡易的にストレッチ(明るくすること)をする機能。見かけの表示のみをいじるので、ファイルには何の手も加えない。見かけを適用したい場合はHistgramTransfomationを使う。
  • Auto Stretch: ScreenTransferFunctionの一機能。あぶり出しのすんでいないまだ暗い画像などを、そこそこ見やすいように自動でストレッチする機能のこと。超便利。
  • DynamicBackgroundExtraction (DBE): 背景の被りや周辺減光などをソフト的に除去する機能。任意の補正点を指定できるので、星雲部分の補正を避けるなど細かい補正が可能。超便利。
  • AutomaticBackgroundExtraction (ABE): 背景の被りや周辺減光などをソフト的に除去する機能。細かい補正はできないが、大局的に補正してくれるので簡単で便利。
  • TVGDenoise: PI場で最強と言われているノイズ除去機能。

比較条件

今回検証するRAWファイルは全て同じです。他に共通撮影条件は
  • 鏡筒: SkyWatcher EVOSTAR 72ED + x0.72レデューザー、焦点距離300mm
  • 赤道儀: Celestron CGEM II
  • カメラ:  ZWO ASI294MC Pro
  • ガイド: ASI178MCと50mmのCマウントレンズをPHD2にて
  • 撮影条件: SharpCapでゲイン220、温度-15℃、露光時間300秒x20枚 = 1時間40分
  • ディザー: なし 
  • ファイル保存形式: RAW16bit、fits形式
  • フィルター: サイトロン QBP(アメリカンサイズ)
となります。

今回の検討を始める前までに、縞ノイズが出た時の処理と、出なかった時の処理の違いを書いておきます。処理は全てPI上でやっています。
  • 縞ノイズあり: BatchPreprocessingでbias補正、dark補正、flat補正を適用し、走らせた。
  • 縞ノイズなし: マニュアルでDebayer、StarAlignment、ImageInteglation。
この中に決定的な違いがあるはずです。以下、各補正ファイルの条件です。全てSharpCap上で撮影していて、最初の処理でmaster fileができるので、以降はそれを利用。
  • bias frame: ゲイン220、露光時間が最小の0.032ミリ秒で、100枚撮影。
  • dark frame: frat frame撮影後、片付けの後すぐに、家の中で撮影。ゲイン220、露光時間300秒、-15℃で、28枚撮影。
  • flat frame: light frame撮影後すぐに、鏡筒に状態でスーパーの白い袋を2重に被せて撮影。ゲイン220、露光時間300秒、-15℃で、7枚撮影。

処理結果に大きな違いが出ていて、検証材料も全て揃っているので、何が違いに影響しているのか順に検証していきます。


検証過程

ここからはほぼ実際にやった手順です。
  1. まず、再度BatchPreprocessingとマニュアル処理で再現性を確認。->きちんとBatchPreprocessingのときには縞ノイズ出て、マニュアル処理では出ないです。再現性はきちんとあります。
  2. 次に、一番怪しくないと思ったflat frameのみ適用させBatchPreprocessingで処理 -> 縞ノイズ出ます。「うーん、あんまり関係ないよな。」
  3. 次、一番怪しそうなbias framaのみを適用させBatchPreprocessingで処理 -> 縞ノイズ消えた!「そりゃbias必要でしょ。」
  4. 次、flatとbias frameを適用させBatchPreprocessingで処理 -> 縞ノイズ出ます。「あれ?flatあまり関係ないはずなのに。」-> ところが、ここでやっと思い違いに気づきます。今回、何も補正していない方が縞ノイズが出なくて、補正した方が縞ノイズが出たのでした。と言うことは、bias関係なしで、flatで縞ノイズ有無が決まっていることになります。え、本当?
  5. 確認で、darkとbias frameを適用させBatchPreprocessingで処理 -> 縞ノイズ出ません。「えー、ホントにdarkもbiasも関係ないよ!?」
  6. 念のため、darkのみ適用させBatchPreprocessingで処理 -> 縞ノイズ出ません。「確かにdark関係なし。」
  7. さらに念のため、master flatを使うのではなく、改めて個々のflat frameを使ってBatchPreprocessing処理 -> 縞ノイズ出る。「やっぱりflatが原因だ!」
  8. さらに、BatchPreprocessingが何か悪さをしている可能性も考えて、マニュアルのImageCalibrationを使ってflat処理だけしてみます->縞ノイズあり。「少なくともPIで処理する限りflatが悪さをしているのは確定でよさそう」


Flat補正をしない場合、本当に改善されているのか

確かに上の画像で見た通り、flat補正をしないと縞ノイズは無くなって見えているのですが、本当でしょうか?それぞれSTFでオートストレッチをしているのですが、本当に正確な比較をしているのか疑問になってきました。オートストレッチは星雲を含む背景の最大の輝度と最小の輝度から適用範囲が決まります。例えば、flat補正をしていない周辺減光のある画像ではあぶり出しも中途半端で、周辺減光のない平坦に近い画像では極限まで炙り出すことをするので、細かい差(この場合縞ノイズも含めて)をより浮き出させてくれます。

ここでは公平に比較するために、それぞれの画像にAutomaticBackgroundExtraction (ABE)を適用し、周辺減光の影響をできるだけ少なくして比較してみます。flat補正をしたものでもまだ明暗のばらつきは無視できないほど存在していて、ABEを適用することで多少の変化があります。それぞれABEをしてから、STFでオートストレッチをしています。

まず、flat補正ありの画像。

light_BINNING_1_integration_ABE

light_BINNING_1_integration_ABE_cut
これまで通り、縞ノイズは盛大に見えています。

次にflat補正しない場合。
integration_ABE

integration_ABE_cut

結局、周辺減光がABEで補正できる範囲を超えてしまっているので全然補正できていません。そのためオートストレッチ後、少し補正して目で見て、拡大部分の明るさをそこそこ合わせています。多少公平性は欠けてしまいましたが、それでも不公平になる程の違いは無いくらいにはなっているでしょう。結果はというと、flat補正なしであからさまに縞ノイズは改善されていますが、よく見るとやはり完全に無くなりきってはいないです。「相当軽減する」くらいは言っていいでしょうか。

この比較から、flat補正は縞ノイズの影響を悪化させていることは確からしいですが、完全には撮りきれないことから、それだけが原因というわけでもなさそうです。

実際の画像処理では背景はもう少し暗くなるので、flat補正なしにして、この程度の縞ノイズになるのなら個人的には許容範囲でしょうか。


Flat frameについて

でもここでふと我に返ります。でも今回使ったflatってそんなに変なの?

確認してみる限りごくごく普通のflatだと思います。master flatをAuto Stretchしたものです。(blogに載せるためのファイルサイズ制限で、bayer配列を無理にjpegにしているので、偽色が出てしまってノイジーに見えてしまっています。)
flat-BINNING_1

拡大です。pngなので、偽色とかは出ていないはずです。(画像サイズが小さいのでpngでもファイルサイズが大きくなり過ぎず、blogでもアップロードできます。)
flat-BINNING_1_cut

見ている限り、極々ノーマルで、ノイズが特別多いようにも思えません。

でも、master flatをdebayerしてAuto Stretchしてみると少し正体が見えてきます。
flat_BINNING_1_integration_RGB_VNG

拡大です。
flat_BINNING_1_integration_RGB_VNG_cut

カラー化すると結構ノイジーなのがわかります。なんだかカラーノイズと言われているものに似ています。これが固定ノイズとなって、星像を止めたときには逆に、この固定ノイズが流れるのでしょう。

でも本当にこれくらいのことであんなに盛大に縞ノイズが出てくるまで画像を悪化させるのでしょうか?だって直接処理しているのはlight frameの1枚1枚で、それに対してflat frameは枚数少ないとは言え7枚です。それが流れて見えるので、スタックした20枚:7枚でなく、1枚:7枚の比で比較してもいいような気がします。ここは少し疑問が残ります。


flat frameのノイズを改善してみたら?

本当にflatが効いているのか確認するためにもう少し試します。master flatにPI上でTVGDenoiseでノイズを減らしたflat frameを適用して処理してみました。その結果がこれです。
integration

拡大です。
integration_cut

わかりますでしょうか?多分拡大していない方がわかりやすいと思いますが、細かい縞ノイズが消えて、大きな構造の縞ノイズが出てきています。

この結果から考えられることは、flat frame自身でのノイズ除去があまりうまくいっていなくて、細かいカラーノイズが大きな構造のノイズになってしまったからです。

少なくとも、これらの結果からflat frameが縞ノイズに影響を与えているのは間違いないでしょう。ただし、あくまでこれも限られた環境、限られた条件下での話の可能性もあります。ここら辺は次回以降に検討してきます。


とりあえずのまとめ

どうも聞いていると、縞ノイズに困っている人と困っていない人がいるみたいです。なので、一概に今回の結果が正しいとは言えないと思いますが、flat補正の影響は私と同じような状況の人には朗報となるかもしれません。でもflatが原因の全てだなんていうことを言う気は全くありません。あくまで原因の一つであるのではないかということです。

いろいろ検索してみましたが、flat補正が縞ノイズの原因だとバッチリ書いてあるところは見つかりませんでした。むしろこれまで思っていた通り、flat補正をきちんとすると縞ノイズが解決できるはずだと書いてある記述はたくさん見つかりました。普通だとこちらのセンスの方が正しといと思ってしまうのは、ある意味ごくごく普通でしょう。そもそもなんでflat補正が縞ノイズに対してダメなのか、まだよくわかっていません。これからいろいろ検証していきたいところです。

今回、縞ノイズに対する根本的な解決策を示したわけではありませんが、状況によってはflat補正を外して画像処理することで、縞ノイズを軽減できる可能性があることがわかります。その上で、PIのABEやDBE、FlatAidProなどを使ってカブリや周辺減光を減らすことで対応する必要もあるでしょうか。この場合、ゴミやアンプグローなどは除去できません。

もう一つ重要なことはは、きちんとディザーをして散らすことでしょうか。多分縞ノイズって複合原因なんです。1方向に流さないようにすること。これが重要なのは変わりません。ディザーはおそらく根本解決の方法の一つです。


この記事まだまだ続きそうです。今回はバラ星雲での撮影のみ取り上げましたが、次回は過去に出た縞ノイズの場合なども検討してみたいと思います。

 

今回の目的は、AZ-GTiの経緯台モードを使って、できるだけ簡単に星雲を撮影しようというものです。


もっと簡単に星雲とか撮影できないか? 

ここしばらく、できるだけ簡単に星を楽しむことができないかを考えています。明るい広角レンズとただの三脚を使った電視観望もその過程のひとつです。これはQBPという武器があって初めて実現することでした。

同様に、撮影に関しても高すぎる敷居をもっと下げることができないか、ずっと考えていました。もちろん、究極的な画像を求めよういう場合は別ですが、もっと手軽に、画質は自分で満足できればいいくらいの撮影というのも、あっていいと思うのです。ここではAZ-GTiを武器として試しています。

眼視から少し手を伸ばしてみたい、電視観望よりもう少し綺麗な天体を自分で撮ってみたいとかいう人たちがきっといるはずです。天体写真の敷居を下げることで、天文人口を増やすことにつながればと思います。


経緯台撮影の問題点

赤道儀は極軸合わせなど、若干敷居が高いので、より簡単な経緯台を想定します。今回は自動導入と自動追尾がついているAZ-GTiを使うことにします。

しかしながら経緯台は撮影にはあまり向いているとはいえません。問題点は二つあります。
  • 経緯台なので撮影していると写野が回転していくのですが、それをどうするか?
  • ガイドも当然なしなので、星像がふらついたり流れたりして長時間露光ができない点。

でもこれらは、もしかしたら電視観望で培った技術が解決するのではと考えるようになってきました。カメラは一眼レフカメラは使わずに、その代わりに電視観望のようにCMOSカメラを使います。


撮影手順

簡単星雲撮影のセットアップは基本的に電視観望とよく似ています。今回はテスト記事なので全くの初心者が必要な細かい手順の説明は省きます。電視観望をやったことがある人くらいが対象です。本当の初心者向けの記事は、もっと細かい位置からの手順を踏まえて後日まとめるつもりです。

IMG_9267

経緯台にはAZ-GTi、鏡筒には評価用に手元にあったSkyWatcerのEVOSTAR 72EDを使います。比較的安価なアポクロマート鏡筒なので、初心者にも手頃かと思います。CMOSカメラはASI178MCを使います。ASI224MCでも良かったのですが、安価で少しでもセンサーの大きさを稼ぎたかったのでこれにしました。
  1. 今回のターゲットは初心者向けに、かなり明るいオリオン大星雲M42とします。
  2. AZ-GTiは経緯台モードで自動追尾します。精度はそこまでないのと、原理的に写野が回転していくので露光時間は長すぎると星が流れていきます。長くても30秒くらい、できれば10秒くらいまでが無難。今回は短めの3秒としました。
  3. ソフトは定番のSharpCapを使います。
  4. ゲインは高すぎるとノイズが多くなってしまいます。逆に低すぎると何も映りません。露光時間は短めなので、少し高めでもよくて、最大のゲインから1段か数段下げるといいかと思います。今回は310としました。
  5. 目的の天体がそこそこ見えていたらSharpCap上でライブスタックをしてみます。
  6. ライブスタックパネル左下の何分かおきに画像を保存するにチェックを入れます。今回は3分にしておきました。
  7. AZ-GTiの精度だと、長時間撮影していると画面がずれていくかもしれません。例えば10分くらい経ってから画面を見てみて、もし天体がずれているような時は再びSysScanのコントローラーを使って天体を真ん中に入れます。その際、ライブスタックのリセットボタンを押すのを忘れないようにしてください。
ポイントは、星像が流れないようにするために、短時間露光に抑えることです。その一方露光時間が短いと読み出しノイズが支配的になりがちですが、そこは枚数を稼ぐことで緩和します。ゲインが高いのでダイナミックレンジが不足しがちですが、淡い部分を映し出す方を優先します。また、ライブスタックを活用することで、撮影枚数を減らします。

と、ここまで読んで分かる通り、やっていることは電視観望とほとんど大差ありません。それでも、赤道儀やガイドなどの、通常の撮影に比べて遥かに手軽なことがわかると思います。

今回はライブスタック3秒x60スタックで、一枚あたり3分露光した画像を、合計1時間程度撮影し、その中の画面からずれていない10枚、30分ぶんの画像を取得しました。画像のズレはAZ-GTiのものもありますが、1時間も撮影するとそもそも15度程度写野が回転してしまいます。

写野の回転は原理的にどうしようもありません。多少の回転はトリミングで見えないようにします。なので超長時間露光は難しいですが、それとて時間が経ったらカメラ自身をマニュアルで回転させてしまえば対応できないこともありません。


撮影画像のスタック

初心者にとって厄介なのは、撮影よりもむしろ画像処理です。

写野の回転と同時に、周辺の歪みによるスタック時のずれが問題になってくる可能性があります。今回はPixInsightで星を認識して星像を合わせるような重ね方をしています。でも初心者にPIを求めるのは酷と言うものです。

ステライメージは回転は補正してくれますが、画面を歪めて星を重ねるような機能はないので、こういった場合は難しいです。あとはDSSでしょうか。DSSは一番最初に星を始めた頃に触っただけなので、ほとんど理解していないのですが、調べた限りでは画面を歪ませて合わせるような機能はないみたいです。

そういった意味でも、小さめのセンサーを使って星像がブレにくい中心像だけ使うと言うのは理にかなっているとおもいます。DSSは無料で使えることもあり、最初からあまりお金をかけることができない初心者にとってはほとんど唯一の選択肢になるので、検討する余地は十分にあると思います。


追尾時のズレの様子

撮影した10枚をスタックして画像処理をしてみました。まず、どれくらいずれている10枚でやったのか、スタック直後でストレッチだけかけた画像です。

integration

初期アラインメントがワンスターアラインメントしかやっていないので、AZ-GTiの設置時の水平度不足による並行ずれと、長時間の撮影による回転のズレが生じているのがわかると思います。

水平精度をさぼったので、並行ズレは結構酷くて、10分に一回くらい構図を合わせ直していました。ちなみに、20枚撮影して落とした10枚は、様子を見ていなくて平行移動し過ぎてはみ出していたもので、10枚全部がそれです。さすがにこれはひどいので、水平をきちんと取ることにより、もう少し抑えることができるはずです。逆に言うと、星像のズレとかで落としたものは一枚もないです。SharpCapのアラインメントは相当優秀です。

回転ずれは時間とともに出てきます。もっと短時間で終わらせてしまうのも一つの手です。


撮影した画像の仕上げ

画像処理をして、そこからトリミングしてまともなところを切り出します。画像処理にそれほど時間をかけていないのでイマイチなところも多々ありますが、経緯台で簡易で撮ったにしては、そこそこ写るのかと思います。

integration2_cut
  • 撮影場所: 富山県富山市
  • 撮影時間: 2020年2月1日22時25分
  • 鏡筒: SkyWatcher EVOSTAR 72ED
  • 経緯台: SkyWatcher AZ-GTi
  • カメラ: ZWO ASI178MC
  • 露光: ゲイン310、3秒x60枚のライブスタック x10枚 = 総露光時間30分
  • フィルターなし、SharpCapでのリアルタイムダーク補正 (3秒x16枚)あり、フラット補正なし
  • PixInsigjt、Photoshopで画像処理
トラベジウムとか少し多段でマスクをかけましたが、そもそも短時間のラッキーイメージングの手法に近くて露光不足気味で、元々ほとんど飛んでいないところが効いてきています。


いっそ、一枚撮りで


もう一つの方法が、ライブスタックの画像保存までの時間を10分とか20分とか長くしてしまって、SharpCapのライブスタック結果の一枚画像のみにして、後からスタックをしないことです。

SharpCapでは、ライブスタックの最中は恒星を多数認識して、その星がずれないようにスタックするたびに画像を歪ませて重ね合わせるので、この機能を使う利点は相当大きいです。その代わりに、長時間撮影のために天体全体が徐々にずれていくのが問題になります。これは撮影の間に画面を見ていると回転していってずれていく様子が積算されていくのがわかるので、適当なところで止めてしまえばいいのかと思います。

さらに画像の保存方式も初心者にはいくつか選択肢があって、RAWのfits形式で保存することももちろんできるのですが、もっと一般なtiff形式、もしくはPNG形式でもいいのかもしれません。特に、PCで見えている画像そのものをファイルに保存してしまう機能もあるので、これを使うと後の画像処理でストレッチをする必要もなくなります。

これと似たようなことは実はかなり昔に試していて、どの形式で保存するのが綺麗かと言う比較をしたことがあります。意外なことに、SharpCapのライブスタックに任せてしまったPNGでも十分に見るに耐える画像になっています。

少し前ですが、名古屋での大晦日年越し電視観望中に1時間ほどほったらかしておいてた3秒露光の画像を、そのままライブスタックし続けた画像が残っていました。

Stack_198frames_634s_WithDisplayStretch
1時間くらい放っておいたライブスタック画像。撮って出し。

カメラはASI294MC Pro、鏡筒はFS-60CBに旧フラットナーですが、AZ-GTiでの自動追尾なので、そういった意味では今回の撮影方法そのものの、一枚撮りバージョンになります。ダーク補正とフラット補正をリアルタイムでしてあります。

撮って出しと言っていいのかよくわかりませんが、画面に見えているのをそのままPNGで落として、それをアップロード用にJPGにしたものです。撮影時間は1時間ほどと書きましたが、時間はあまりよく覚えていません。15度くらいいという画面の回転角から、それ位の長さだったんだろうと推測しているだけです。重要なのは、AZ-GTiでのほったらかしでも、水平の設置さえ良ければこれくらいの時間は位置を合わせ直すことなく撮影できることです。

上の画像をある程度仕上げてみます。回転で切れてしまっている部分をトリミング。ASI294MCはセンサー面積が広いので、中心部だけでも十分な面積が生き残っています。

まずはWindowsの「フォト」の「編集と作成」から「調整」のみを使った場合。

Stack_198frames_634s_WithDisplayStretch_win_photo
Windwos「フォト」での加工例。

簡単な調整だけでも多少は出てきます。

次はMacの「プレビュー」の「ツール」「カラーを調整」のみを使ったものです。

Stack_198frames_634s_WithDisplayStretch_mac
Mac「プレビュー」での加工例。

うーん、どうでしょうか、Windowsの方が、ディテール、ノイズともにまさっている気がします。ここら辺は腕にも大きく依存するので、容易に逆転するかもしれません。

いずれのケースでも、さすがにトラペジウム周りのサチってしまっているところは救い出すことはできませんでした。でも、一枚PNGからここら辺まで出れば、撮影を試してみるというのならある程度十分で、これに不満が出るならスタックや赤道儀を用いるなど、次のステップに進むことになるのかと思います。

重要なのは、このようなOS付属の簡易的なツールでも、多少は画像処理ができてしまうと言うことです。これは初心者にとっては大きなメリットでしょう。逆に、改めてみてわかったのは、さすがに1時間スタックは星像が多少肥大するとするということ。これは課題の一つかもしれません。

最後は、このPNG1枚画像をツールの制限なしに画像処理した場合です。と言ってもPhotoshopです。あと、最後の仕上げに今話題のTopazのDenoiseを試してみました。これは結構強力です。しかも簡単なので初心者向けです。有料なのが初心者にとって唯一のネックかもしれません。でもそれだけの金額を出す価値のあるソフトかと思います。Denoiseに関してはまた別記事で書こうと思います。

Stack_198frames_634s_WithDisplayStretch_DN_cut
Photoshop CC+Topaz Denoiseでの画像処理。


まとめ

AZ-GTiを使った経緯台での撮影は一言で言うと「やはり楽」です。似たようなことを既にやっている方も、もしかしたら初心者でも同様のことをごく自然な流れとしてやってしまっている方もいるのではないかと思います。

ポンと北に向けて適当に置くだけ、極軸を取る必要なし、ワンスターアラインメント、ガイドもなし、大きくずれたら直す、というので大幅に大変さを軽減できます。30分露光でここら辺まで出れば、最初に挑戦する撮影としてはかなり満足できるのではないかと思います。

その一方、画像処理の敷居は依然高いかもしれません。後でスタックするのが敷居が高いのも事実なので、一枚どりで画面の見たままで保存してしまうのでもいいのかと思います。あとはGIMPなどの無料の画像処理ソフトや、今回試したWindowsの「フォト」やMacのプレビューでの簡易画像処理だけでも最初はいいのかもしれません。 


後日、今回使ったEVOSTAR 72Dについて、試用記を書いています。よかったら合わせてご覧ください。



このページのトップヘ