ほしぞloveログ

天体観測始めました。

カテゴリ: 画像処理

何日か前、Twitterでまりもさんという方が画像処理に困っていて助けて欲しいとの呼びかけがありました。


ちょっと気になってたんですが、撮影と画像処理で疲れてしまっていてお盆の最終日になってしまいました。


Twitterで声かけ 

ちょうどペルセウス座流星群のブログの記事も書き終えて少し時間があったので、Twitterで「Zoomで画像処理やってみませんか?」と声をかけたらすぐに返事が。その後ダイレクトメールで個別に連絡を取り、16時過ぎから早速Zoomで下打ち合わせ。もうすでに誰かが助けてくれたかと思っていたのですが、聞いてみるとまだ私だけだったみたいです。天体写真に関しては大御所のような方もいらっしゃるので、私なんかがとも思いましたが、多少なりとも力になれるならと。もともと画像処理をZoomでいろいろ検討しながら進められないかと思っていたこともあるので、私にとってもいい機会でした。

さらにいろいろ聞いてみると、大学まで北海道で、就職の時に埼玉に出てきたとのことです。まだかなり若い方にもかかわらず、星歴はなんと16年。私よりずっと長いです。子供の頃からずっと星が大好きで、今はステラメッセンジャーとしてプラネタリウムとかいろんなところに顔を出しているそうです。関東に来たのもいろいろ交流できるからとか。

北海道の空はものすごく綺麗だったとのこと。天の川もごくごく普通に見えるそうで、うらやましい限りです。撮影の方は学生の時の天文部で、最後の学年の時にカメラを手に入れてから始めたそうです。今回も天の川を撮影したけれどなかなかうまく処理できないから困っていたとか、いろいろ余分なことも含めてしばらく話していました。

さて、今回の目的と状況ですが、
  • 伊豆半島の下田で撮影した天の川をうまくあぶり出したい。
  • 下田は光害はあまりなく、十分暗かったはずだが、画像処理で明るくしようとしても天の川がうまく出てこない。
  • 四隅が暗いので、直したい。
などです。

Twitterにあがっている写真を見たらずいぶん青かったので聞いてみたら、やはり青をベースにしたいとのこと。私も青い夜空は好きなので「Zoomで話しながら青をベースに天の川を炙り出す方法を検討しましょう」ということになりました。

その際、カメラやレンズの撮影状況聞いたところ、NikonのD5300に添付の18mm F3.5のレンズを使い、ISOが(多分)12800で20秒で写したとのことでした。処理ソフトはNikonのViewNX 2をつかっているとのことです。とりあえず撮影したファイルを送ってもらい、私の方でもViewNXを一度使ってみてファイルを触ってみるので、午後5時に再びZoomで再開しましょうということに。

さて、急いで準備です

まりもさんが夕方2時間くらいしか空いていないというので、5時からに設定しましたが、この時点でもう残り30分弱。どこまでできることやら、少し焦ってしまいます。

実は、うまくいきそうならTwitterで呼びかけて公開しようという話もしていました。まりもさんは全然OK、でも私の方でソフトの確認がうまくいかず、結局二人で話すことになりました。というのも、ViewNX 2というのは旧版のソフトにあたり、最終バージョンが5年前で、私のMacではインストールすることもできませんでした。後継でのViewNX-iというのがリリースされているようなのですが、インストールはできてもうまく立ち上がらず、メモリを200GB!!も食ったと出て応答無しで止まってしまいます。仕方ないので、まりもさんは持ってないのですが手持ちのPhotoshopをメインに、少しPixInsightで補足することにしました。

下田で撮影した天の川のRAWファイルを2つ送ってくれて、午後5時まである程度見たのですが、意外なほどノイズが多いです。キットレンズで明るくないにしても、通常のあぶり出しではほとんど出てきません。時間もないので、PhotoshopのRAW filterでレンズ補正で周辺減光を落とすのと、PixInsightでABEだけかけてカブリを落としました。少し出そうかなというところでもう時間です。5時ちょうどくらいに、Zoomに再びまりもさんが入ってきてくれました。


Zoomでの画像処理開始

さて、早速画像処理の解説の始まりです。

IMG_0462a
顔出しOKとのことでしたが、一応ぼかしておきました。

最初に「ノイズが思ったより多いみたいです」と少し話すと、どうも露光時間が間違っていたようで「1枚目が5秒、2枚目が10秒だった」とのことです。なるほど、確かに5秒ならあのノイズは納得です。聞いてみると、露光時間を伸ばしたら明るくなりすぎたとのことなので、おそらくISO12800が高すぎたのかと思います。とりあえず少しましな2枚目の10秒のほうで進めることにして、View NXが動かなかったことを説明して、手持ちのPhotoshopをZoomで画面共有して進めてみることにしました。

処理はまりもさんに見てもらうために、再び一から始めます。まずはオリジナルの画像。

01_DSC_0400_org

淡いですが、それでも天の川も十分に見えています。当然周辺減光もあります。周辺減光を生かして天の川をライトアップさせたように見せる手もありますが、ここではまりもさんの希望通り周辺減光をとってみます。

Photoshopで期待したのは、RAWファイルの読み込み時にレンズのプロファイルから周辺減光や歪みが補正できることです。ただ、まりもさんがPhotoshopを持っていないということなので、こんな方法がありますよという例を示すことになります。

02_DSC_0400_corner

最初のと比べると、周辺の暗いのがなくなっていることがわかると思います。

周辺減光をとったあとも、カブリが結構残っていたので、PixInsightのABE (AutomaticBackgroundExtractor)を使うと簡単にカブリがとれますよとかいうのを紹介しました。

03_DSC_0400_DBE2

特に上下の明るさの違いが補正され、さらにホワイトバランスもある程度撮れているのがわかります。

でも、最初から有料の凝ったソフトを使うのは大変なので、できる範囲で始めてくださいというは強調しておきました。重要なのは、周辺減光やカブリをとると、より淡いところが炙り出せるようになるということを知ってもらうことです。

あと、同じ画角で何枚か撮影したとのことなので、スタックするとノイズが減りますという話もしました。スタックは有料ソフトが使いやすいのですが、無料だとDSSとかもあります。固定撮影とのことなので、本当はPixInsightが星を認識して画面を歪ませて位置を合わせてくれるのでいいのですが、それに代わるものとしてSequatorでも近いことができます。ただ、こちらも最初は大変なので「まずは露光時間を30秒くらいまで伸ばして、ISOを3200くらいまで下げて撮影するだけで、かなりマシになるはずです」ということを話しました。

その他、Dfine2やDeNoiseなどのノイズ緩和ソフトも紹介しましたが、やはりカラーノイズとかが残りまくるので、試しただけで採用はしませんでした。

結局いつもやるように、いろんなことをうだうだ試していいものを残していくという、いつもやっている処理を見てもらったような形になります。小1時間なので大した処理もできなくて、結論らしい画像も仕上がらなかったのですが、そんなうだうだ過程を見てもらったのが一番だったかなと思っています。


GIMPの紹介

解説の中で、有料のPhotoshopの代わりに無料のGIMPを紹介しました。以前このブログでEOS kissで天の川を撮ろうというのを特集したのですが、

 

 

 

この時にGIMPの使い方を書いてあるので、まりもさんにも少し紹介しておきました。元々娘のNatsuのために書いた記事ですが、改めて読み直すと露光時間が短いとか、処理してもノイズが目立つとか、今回と状況がよく似ています。誰もが一度は通る道なのかもしれません。

GIMPから始めるのはいい経験だと思います。Photoshopを使った後にGIMPを使うと、さすがにPhotoshopは有料だけあるなと思うのですが、それでもGIMPでもPhotoshopでも処理の概念は基本的には同じです。GIMPが不満になったら月980円のコースを始めるのがいいでしょうか。

一つ注意点があって、GIMPはRAWファイルを直接読み込むことができません。Canonもそうだったのですが、今回NikonのRAWファイルの.NEF形式もやはり読むことができませんでした。ViewNXとか何かで別途読み込んでから.tif形式に変換して読み込むのかと思います。その際、tif形式は16ビットで保存するようにしてください。今のGIMPは16ビットの画像ファイルを扱うことができるので、淡い画像を出すのは有利です。


Zoom終了後

結局時間内では、レンズの歪み補正が悪さをして炙り出すと同心円状のノイズがでる、ABEだとカブリ除去が不十分とかで、Zoomが終わってから少し補正して、改めてまりもさんにファイルを送っておきました。これまでの上の写真も含めて、改めてZoom終了後に処理した過程なので、Zoom中に示したものよりも少しマシになっています。

ABEの代わりにDBEを使ったときのものです。

IMG_0467
天の川を避けて補正する点を打っていきます。
すみません、画面をiPhoneで撮ったので写り込みがあります。

DBEを含めて処理した最終画像です。
04_DSC_0400_DBE3

さらに少し青味をかけたものです。
05_DSC_0400_DBE3_blue

露光時間が短いのもあり、炙り出しも私のテクニックではここら辺が限界かと思います。メールの中に、次回撮影する時は露光時間を伸ばすことと、ISOを下げることを書いておきました。往々にして、きちんと撮影した画像ほど後での処理が必要なく綺麗に自然に仕上がって、条件が悪い画像ほど後での処理が大変で、ゴテゴテと不自然になっていくものです。

あと、Zoomの中でも話したのですが、画像処理は決してやっている本人がすごいのではなく、このようなツールを開発してくれた人がすごいだけで、我々はそれを無料、もしくは少しお金を払って使わせてもらっているのだというようなことも伝えておきました。


終わってみて

画像処理をZoomで中継して説明するというのは初めてのことでした。なかなか時間内には終わらなかったですが、それでもまりもさんは喜んでくれたようです。

私自身も十分楽しかったです。

次回、もう少し露光時間を伸ばして撮影できたら再びやりましょうと約束しました。勝手も多少分かったので、できれば今度はもう少し準備に時間をかけて、公開して他の方にも参加してもらってやってみたいと思います。

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

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の相当基本的なところなので、かなり検証されているはずです。

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

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


アンタレス付近を撮影した際のフラット補正に続き、EOS 6Dで撮影した場合のダーク補正について少し述べます。

元々あまり面白くない内容と思い、お蔵入りしようとしていた記事です。でもNINAの使い方の記事コメントでTKさんが撮影時の温度について述べてくれたので、どこまで意味があるか分かりませんが記事にだけしておこうと思いました。大したことは言ってませんが、何かの参考になれば程度です。

温度変化させ撮影した6Dのダークフレーム

今回ダークフレームは180秒露光で冷凍庫と冷蔵度と室温で適度に出し入れしれ温度の上下を行き来させて撮影しています。撮影できた温度は

-2度:3枚
-1度:1枚
0度:2枚
1度:3枚
2度:2枚
3度:2枚
4度:4枚
5度:4枚
6度:3枚
7度:4枚
8度:3枚
9度:4枚
10度:3枚
11度:2枚
12度:3枚
13度:1枚
14度:3枚
15度:5枚
16度:1枚
17度:18枚
18度:12枚
19度:1枚
21度:1枚
23度:1枚
25度:1枚
26度:1枚

の計89枚です。実際に撮影した順序は温度が上下していますが、それを温度別に並べています。実際にダーク補正で使ったものはこの中のうち11度から17度の34枚です。実際のライトフレームは13度から15度までの温度変化なのですが、ダークの枚数を稼ぐために少し温度範囲を広げています。

ちなみに、この温度はBackYard EOSで測定したものなのですが、この温度情報TKさんのコメントによるとファイルのExif情報として書き込まれているとありました。ところが、EOSの中でも温度情報が書き込まれているものと書き込まれていないものがあるらしくて、6Dは私が探した限りは温度情報はファイルには書き込まれていないようでした。他にもAPTでは温度を読めるという情報もありますが、私はまだ試していません。


撮影されたダークフレームの比較

まず、これらのダークファイルを温度が上がっていく方向で動画にしてみたのですが、Youtubeにアップした時点で最初だけブロックノイズが発生し、うまくいきません。まあ、動画で見てもあまり得るものはないので、諦めて幾つか比較するだけにします。

一番温度の低いものをオートストレッチしたもの
Blink00004

と、一番温度の高いものを、(一番温度が低いもののオートストレッチのパラメーターで)ストレッチしたもの
Blink00089
です。この2枚を比べると明らかに温度が高い方が明るく、ノイジーなことがわかります。温度が低いときには縦横の線が見えて、温度が高くなるとその線が熱が上がったことによるノイズで覆い隠されているという状況です。


スタックしたマスターダークの様子

次に、実際のダーク補正に使った、55枚をスタックしたマスターダークフレームです。

masterDark_BINNING_1_EXPTIME_181_integration_RGB_VNG_cut
ランダムノイズがスタックでルート55分の1に減少し、固定ノイズが残ったような状態です。これを見ると、横縞はランダムノイズ成分が多く、縦縞は固定ノイズ成分が多いことがわかります。これはバイアルファイルを見ることでもわかります。

下が、同ISO800で露光時間最小の1/4000秒で100枚撮影してスタックしたマスターバイアスになります。

20190206_bias_6D_ISO800_s4000_x100_integration_RGB_VNG_cut
バイアスノイズは縦縞が多く、これがマスターダークに乗っかっていることがわかります。

上2枚の比較は、オートストレッチ時にパラメータが違うので直接の比較はできません。マスターバイアスのパラメータでマスターダークを表示させたものは直截比較ができるはずで、以下がそれになります。

masterDark_181_integration_RGB_VNG_calibrted_to_master_cut
マスターバイアスに比べて、相対的に青味がかった横縞成分のダークノイズが乗っかっていることがわかります。


輝点ノイズの傾向と、温度変化で出てくるノイズ

次に、撮影時RAWと同時にJPEGで保存されたダークフレームを動画にしたものです。


JPEG動画の方は比較的理解しやすいです。
  • まず、EOSのDIGICエンジンで、背景の細かいノイズがものの見事に真っ黒になっています。
  • ポツポツとある輝点のはホットピクセルに相当するものだと思います。
  • 輝点も固定されたものと、ランダムなものがあるのがわかります。
  • 最後にノイズがバッと増えるのがわかりますが、これが温度が高くなった時です。
  • 不思議なのが、温度が9度前後のところに一枚だけノイズが格段に大きいものがあります。もしかしたら途中光が漏れた可能性が完全には否定できませんが、これ一枚だけというのもあまりありそうでない話で、それよりも冷蔵庫や冷凍庫への出し入れの際に急激な温度変化が起こって、読み取り温度と実際のセンサーの温度が違った可能性の方が高いと思われます。
結局、何が正しいかはここでは決着はつけられないのですが、一つ言えることは、たとえ温度が問題ないように見えてもノイジーなダークフレームが混ざる可能性は否定し切れないということです。今回はこの画像は必要な温度外にあったので使いませんでしたが、ダーク補正の前に一応念のためにおかしなファイルができていないかは、確かめた方がいいということくらいは言えるのかと思います。



まとめ

大した内容ではないですが、一応まとめます。
  • BackYard EOSで記録された温度は、必ずしもセンサーの温度と一致はしていない可能性が高い。 
  • 撮影された個々のダークフレームにはバイアスノイズ+ランダムなノイズ+固定されたダークノイズ(固定されたホット、クールピクセル含む)
  • スタック(他数枚を加算して、平均化されたという意味)されたマスターダークにはバイアスノイズ+スタック枚数のルート分の1されたランダムなノイズ+固定されたダークノイズ(固定されたホット、クールピクセル含む)
と、今回せいぜい言えるのはこれくらいでしょうか。

こうやって考えると、ダーク補正には輝点ノイズを除去するという役割が大きく、他には「ある温度である長時間露光した時の固定ノイズ」を補正するという役割があるはずですが、今回の結果ではあまりあらわにはその状況を表すノイズだけを可視化するには至っていません。マスターダークからマスターバイアスを除去した画像がそれになるはずですが、うまく除去する方法がわかりませんでした。仮にうまく除去できたとしても、それが本当に固定されたものなのか、ランダムノイズが消し切れずに残ったものなのかは切り分けは難しいでしょう。

もっというと、今回見せた画像は全てPIのオートストレッチで炙り出して初めて見えた画像です。あぶり出さなかったら、全く見えず効果の程は全然わかりません。ではダーク補正は見えていないので効果はないかというと、もちろんそんなことはなく、欲しいライトフ画像も炙り出して得られるもので、その結果ノイズが浮き出てきて、その状態でのダークノイズの除去は効果があるはずです。

でも今回は全部定性的な話のみで、定量的には何も示せていません。もう少し評価方法をいろいろ考えてみたいと思います。

あまり大した結果を示していなくて読んでいただいた方には申し訳ないのですが、ノート程度と思っていただければありがたいです。


前回のアンタレス付近の画像処理をする際、フラット補正で結構うまくいったので、別記事で書いておきます。




フラット補正の方法

フラットですが、これまで口径60mm程度の小口径鏡筒はiPadをフラットライトパネルがわりにして使っていました。でもTSA-120位のある程度の口径になってくると、まだきちんと合わせることができません。また、フラット補正情報のS/Nを稼ぐために暗い光はダメで、明るい光なら大丈夫ということもわかってきました。RGBのカラーバランスも大切そうで、液晶パネルはある程度の波長依存性があるという情報もあるようです。

その過程で思ったのが、フラットライトパネルでなく、暗くない自然光が均等にある状態があればいいのではということです。例えば以前見学に行った木曽シュミットでは、ドームの壁に吊るした白いスクリーンを撮影してフラットフレームにしているとのことです。

IMG_2444

最初、口径が大きいのでフラットパネルライトに相当するものがないのでこうしているのかと勝手に思っていたのですが、むやみに明るい必要はないこと、波長依存性があまりないこと、完全に均等でなくてもどうせ焦点は合わないことなどを考えると、むしろこういったシンプルなほうがいいのではと思ったのです。


実際のフラットフレームの撮影

なので今回は撮影は少し暗い部屋で、廊下の障子越しの光を写してフラットフレームとすることにしてみました。

IMG_0196


見ている限り口径60mm程度のローカル範囲では均等、明るさ的にも十分です。ヒストグラムを見ながら、ISO100で露光時間20ミリ秒でピークが中央に来る程度にして100枚撮影しました。

100枚をスタックして出来上がったマスターフレームになります。オートストレッチして周辺減光を見やすくしています。

masterFlat_BINNING_1_FILTER_NoFilter_integration_RGB_VNG
100枚のマスターフレームをスタックしたMaster flatをオートストレッチしたもの。

ただしこれだと、天体撮影時に時間変化するようなカブリの移動は補正できません。特に今回は撮影中、薄明に少し入って背景の明るさが変わった時に明らかにカブリが変わったことを実際に見ていたので、1次的な変化で変わるようなカブリはPixInsightのDyamicBackgroundExtraction (DBE)で補正することにします。


バッチ処理でのフラットの補正

まずは1枚目のRAW画像をオートストレッチしてJPGにしたものです。周辺減光がかなりあるのが分かります。

LIGHT_6D_180s_800_+13cc_20200530-00h44m10s100ms


次に、これらのRAW画像をPixInsightのWeightedBatchPreprocessingの自動処理でフラット補正をして、スタックした実際の結果が下になります。

masterLight-BINNING_1-FILTER_NoFilter-EXPTIME_181.5_PCC_slope

これを見ている限り、周辺減光は相当きれいに除去することができています。

ただ、やはり予想通り、1次的に変化するようなカブリが見られました。これはDBEで4隅のみを4点、もしくはそれぞれの4点の中間も合わせて8点を指定することで簡単に除去することができます。DBEで補正とともに抜き出してみます。


DBEで4点指定のカブリ補正

まずは四隅の4点のだけ指定した場合。除去された部分を見てみます。

masterLight_EXPTIME_181_5_PCC_background2

分かりやすいようにオートストレッチしていますが、きれいに横向きのカブリが出てますね。そのカブリを補正したものが下です。

masterLight_EXPTIME_181_5_PCC_DBE

すでに悪くないです。でも8点指定した場合と比較すると分かりますが、まだ少し濃淡が残っています。


DBEで8点指定のカブリ補正

念のため8点指定の場合を見てみます。

masterLight_EXPTIME_181_5_PCC_background2

masterLight_EXPTIME_181_5_PCC_DBE3

8点指定の方がやはりいいですね。これなら、かなり炙り出しがいのある画像になったというものです。

おそらく4点だと平面、8点だと縦横で2次曲面での補正になるのかと思います。

ここで少しコツですが、スタックしているとディザーなどの画角のズレで、縁の方は一部明るさが違ったりします。その明るさが違う部分に点を打つのではなく、全枚数がスタックされた部分の外側の方に点を打つときれいにスロープが取り除かれます。縁の明るさがずれている部分は後でトリミングすればいいでしょう。


考察

今回の一番のポイントは、周辺減光とカブリをうまく切り分けられたことかと思います。カブリは長時間撮影の場合は変化するはずで、それを平均化したフラットフレーム一枚で補正し切るのは、原理的に難しいはずです。でも周辺減光さえきれいに補正できていたら、あとは簡単なスロープだけで補正できるので、ソフト的に補正してしまえばいいはずです。

こうやって考えると、少なくとも周辺原稿をきちんと補正できる「自然光を利用したフラット補正」は悪くないのかと思います。

今回のフラットフレーム撮影時のポイントは
  • 波長依存性の少ない実際の空に近い自然光。
  • S/Nが悪くならないように光源に十分な明るさがある。
  • 鏡筒がある側の撮影場所は暗く、邪魔な迷光があまり入らない。
  • 光源がフラットになるように、今回は障子を通った光を使った。
  • ランダムノイズが無視できるような十分な枚数。
と言ったところでしょうか。


まとめ

口径が60mmの時は、これまでのフラットライトパネルを使っての補正でもうまくいったことはありますが、これほど周辺減光がきちんとれることは稀で、大抵は補正の残りが四隅とかにあって、毎回DBEで苦労して補正していました。銀河とかならいいと思いますが、全面星雲とか、暗黒帯ウヨウヨとかだと、DBEの多数点指定ではせっかく炙り出したい天体を、無駄に禍補正してしまったりします。

今回の「自然光を利用したフラット補正とDBEでのシンプルカブリ補正」という手法が、例えばまだうまくいっていないTSA-120とかのより大きな口径のものでもうまくいくなら、なかなか確定しないフラット補正のいい手法になるのではないかと思います。引き続き同様の方法で試していきたいと思います。


みなさん、こんにちは。「ほしぞloveログ」のSamです。最近凝っている、太陽プロミネンス動画ですが、昔撮影してうまく最後まで処理できなかったファイルを、改めて処理したので載せておきます。


3月のテスト撮影

一つ目は少し前の3月7日に撮影したものです。まだテスト段階でしたが、ファイルが残っていたので動画にしてみました。でもプロミネンスの大きさがあまり大きくないので、動きもあまりたいしたことありません。

Blink2

鏡筒: 国際光器マゼラン102M、口径102mm、焦点距離1000mm、F10 アクロマート
エタロン: Coronado P.S.T.
赤道儀: Celestron CGEM II
カメラ: ZWO ASI290MM
撮影ソフト: FireCapture
撮影時間: 2020/3/7 13:55-14:50
撮影条件: ゲイン310、露光時間25ms、200フレーム撮影し150フレームをスタック 
画像処理: AS3にてスタック、ImPPGで細部出し、Sharpen AI、Photoshopで画像、PixInsightとffmpegで動画作成 

前回と同じようにgifにしましたが、gifファイルはあまりファイルサイズを小さくできないので、撮影時間1時間の60枚くらいが限界です。


4月の長時間撮影

次のファイルはゴールデンウィーク始めの4月29日撮影の約3時間ぶんの結果です。

  • 鏡筒: 国際光器マゼラン102M、口径102mm、焦点距離1000mm、F10 アクロマート
  • エタロン: Coronado P.S.T.
  • 赤道儀: Celestron CGEM II
  • カメラ: ZWO ASI290MM
  • 撮影ソフト: FireCapture
  • 撮影時間: 2020/4/29 12:59-15:55
  • 撮影条件: ゲイン300、露光時間25ms、200フレーム撮影し120フレームをスタック 
  • 画像処理: AS3にてスタック、ImPPGで細部出し、Sharpen AI、Photoshopで画像、PixInsightとffmpegで動画作成 
PixInsightで動画を作る際、

-y -r 25 -i Blink%05d.png -b:v 15000k -vcodec libx265 Blink2good.mp4

として、H.265でmp4にして、youtubeにアップしました。ただ、やはりプロミネンスがあまり大きくないので、長時間の割に動きが少ないです。このときちょうど小さな黒点も出ていたので光球面も一緒に出してみました。

本当は黒点周りや、Benar対流の動きが見たかったのですが、この日はかなり風が強く鏡筒が揺れてしまっていたので、分解能があまりよくありません。じっくり見てると少しだけ動いているのはわかりますが、いまいちインパクトがありません。再度挑戦して、もう少しはっきりとした動きを見てみたいと思います。やはり、プロミネンスと光球麺を同時に出すのはまだ難しいです。静止画ならマスク処理などで別々に細部を出せるのですが、動画だとそこまで手をかけることはできません。

SODの4月29日の動画との比較です。



UTCなので、午前5時くらいから午前8時までくらいに相当します。


苦労は理解され難く

ちなみに、撮影したファイルの合計は190GBになりました。3時間ものの超大作をやっと動画にまでして、この喜びをわかってもらおうと、妻に「すごいでしょう」と言って見せたとき、なんて言ったと思います?

「なにこれ?シューシューしてるの?
ヤカンの湯気みたい。」

ですよ!1億5千万キロも離れたプロミネンスの動きをヤカンの湯気なんて...。がっくりでした。

妻にとっては下の鳥の方がはるかにいいみたいです。


おまけ、初の鳥写真

さて、気を取り直してもう一つ、天文ネタと全然関係ないですが、庭にいつもいるキジを撮影してみました。ご存知かも知れませんが、キジは国鳥です。

FS-60CBにマルチフラットナー をつけてEOS 6Dで撮影しています。庭の端の方にいて少し焦点距離が足りなかったので、トリミングしています。

IMG_5492_cut

IMG_5492_cut_small-gigapixel-scale-4_00x

鳥をきちんと撮影するのはほぼ初めてで、星雲とかと違って色が最初から出ているのでずいぶんと楽です。普段の画像処理テクを駆使して細部とかも出してみました。羽がとても綺麗です。でもこれって正しい方法なのかどうか?

この子、この辺りにもう何年も住みついていて、グェー、グェーといつもうるさいです。今年もつがいでいます。毎年ひなを育てているのを見るのですが、今年も無事に生まれてほしいです。。

太陽プロミネンスのタイムラプスの手法がやっと確立しました。


これまでの試み

太陽アニメはこれまでも何度か挑戦しています。





でもこれ、めちゃくちゃ大変だったんです。2018年のは10分おきに3時間ですが、そもそも昼間で極軸が出ていないので赤道儀がずれてきます。ほぼずっとつきっきりでとにかく大変で、二度とやりたくないと思いました。

また、いずれもPhotoshopで一コマ一コマ手で位置合わせをしています。2019年4月の2つ目は何分かおきに撮りましたが、コマ数は11コマと少ないのでまだましです。でも位置合わせだけでなく、明るさとかもかなり違っていて、一枚一枚合わせこむので、これくらいが手合わせでは限界です。ジェットの結果は面白かったですが、この時ももう二度とやりたくないと思いました。


太陽タイムラプスの何が難しいのか

でもやっぱり太陽の変化をアニメにしたいんです。しかも1分おきくらいに数時間にわたるアニメです。そのためにはクリアしなければならない問題がいくつもあります。
  • PSTは安価ため、エタロンの平行度があまりいいわけでなく、Hαをうまく出せる部分が限られていて、画面の30-40%のみ。長時間撮影で太陽の位置が画面内でずれると、Hαの見え方も変わってくる
  • そのため長時間太陽がずれないような手法を確立する必要がある。極軸さえ合わせられないので、ほっといたらずれていく。ガイドか?でもどうやって?
  • 撮影時間が長く、画像の枚数が多いと、個別の画像処理は現実的ではなくなる。画像処理をまとめて一気にやってしまいたいが、一度にうまくできるのか?
  • たとえ撮影時の位置があまりずれなかったとしても、その精度ではアニメにしようとするとブレブレになってしまう。かと言ってステライメージやPixInsightなどの画像処理ソフトで位置合わせをしようとしても、星を使った位置合わせのような基準が何もないのでできない。
など、思ったより大変そうです。もう少し細かく考えます。
  • 撮影したserファイルをAutoStakkert!3でスタックしますが、太陽のブレ具合によって毎回出来上がる画像のサイズ(縦、横のピクセル数)が変わってきます。オプションでcropにしても拡大する方を選らんでもサイズは毎回変わってしまうようです。このため、動画にするときの位置合わせが難しくなります。
  • 炙り出しの際ImPPGを使っていますが、同じ設定でも撮影時の条件の微妙な違いにより、出来上がりの明るさや細部の描写などがバラバラになってしまいます。撮影時の条件をよほどうまく合わせるような工夫を何かしなくてはダメです。
実はあまり記事にしていないのですが、これまで何度もアニメには挑戦してきて、やっと上記問題を解決しなければうまくいないことがわかってきました。これらの反省点を含めて、手法を何度か改善しつつ、今回やっとうまく動画まで持っていける手法を確立することができました。

今回やった方法を順に書いていきます。それでもそこそこ大変です。


FireCaptureによる太陽オートガイド撮影

撮影はFireCaptureを使います。ポイントはガイド機能を使うこと。そのためにまずは赤道儀をASCOMやST4経由でPCから制御できるようにしておきます。接続がOKなら、「Setting」タブで「Telescope」を選んで、ASCOMやST4ドライバーを選びFireCaptureと赤道儀を接続してください。うまく接続できると画面の最前面に方向ボタンが出てきます。いくつか押してみてFireCaptureの画面に見えている太陽がきちんと移動するか確認するといいでしょう。

その状態で縦に並んでいるアイコンの上から5つ目の「AutoGuide」にいきます。まずは右クリックをするとオプションが選べます。制御はPHD2などと比べると随分シンプルでできることも限られますが、「Swap direction」でフィードバックする方向をきちんと選ぶこと、極軸があっていないので思ったよりずれていくことがあるので、「Guide rate」フィードバック量をデフォルトの倍くらいに増やすことなどに気を付けて調整します。

IMG_0012


設定が終わったら「AutoGuide」横のチェックボックスをクリックして、ガイドをオンにします。赤い四角いボックスが表示され、太陽のリムの形を使ってをオートガイドすることができます。最初なかなかうまくいかないかもしれません。しばらく待ってずれていかなければ成功ですが、方向とかを間違えるとどんどんずれていきます。いくつか設定を変えて試してみてください。うまくいくと数時間とかの単位できちんとガイドしてくれました。

タイムラプス映像にしたいので、一コマ一コマの時間間隔が重要になります。そのため撮影はフレーム数単位でなく、時間単位になります。今回は12.5ms露光で5秒間撮影、その後55秒休みます。保存はRAWで残したいので.serにします。今のPCだと80fpsで取り込めるので1ファイル400フレームくらい、サイズは1.7GBくらいです。これをFireCaptureの「Capture」タグのところにある「カメラアイコン」を押して出てくる「AutoRun」機能で繰り返します。「Delay」を55秒、「Limt」を5秒にします。これで1分に1度5秒間撮影します。出来たファイルのサイズやフレーム数は多少ばらつきが出ますが、気にしないでおきます。

cap1

撮影時にもう一つ気を付けておくことが、ゲインの設定です。ゲインはサチるくらい高めにしておきます。今回は440まで上げています。理由は、淡いプロミネンスを階調よく撮るためというのが一つの理由です。でも、実はもう一つの理由の方が重要で、ヒストグラムで見た時の背景ピークの幅を広げてピーク位置の依存性を少なくし、後の画像処理の時のパラメータにあまり依らないようにするためです。輝度の高い光球面までダイナミックレンジの中に入れようとすると、背景のピークが鋭く左の暗い方に寄ってしまいます。この状態で画像処理をしようとすると、撮影条件が変わった時にピーク位置がずれ、画像処理の設定が対応しきれなくなって、仕上がり画像のばらつきが大きくなってしまうからです。今回のようにゲインを上げて撮影する場合、当然ですが光球面の模様は諦めなくてはいけません。プロミネンスに特化したアニメになると思ってください。

実際のガイドの様子の動画です。娘のギターがうるさいですが、気にしないでください(笑)。


PC画面の右上の矢印がピコピコ反応して、きちんとガイドしているのがわかると思います。

長時間にわたる撮影の場合、保存されるファイル量が数百GBクラスになることもありますので、残りのディスク容量に注意してください。


ちょっと脱線、太陽のオートガイドについて

この記事を書きながら色々調べてみました。どうやら、このFireCapureのガイド機能を太陽撮影で使った例は、海外も含めてほとんどないようです。基本的に惑星での使用例ばかりです。太陽でのガイド撮影はCloudy Nightsとかでも「Hinode(ヒノデ)ソーラーガイダー」を勧めていました。名前は日本語っぽいですが、アメリカ製だそうです。ガイド精度も上記ページで動画があります。実はこれ、胎内(だったと思います)で実物を見た記憶があります。太陽を始めていたのでガイドにちょっと興味があったのですが、値段がそこそこ。なんか工夫してできないかと思っていました。

今回、SharpCapの機能で画像認識をしてそれがズレないようにガイドするのも試しました。まだ実験的と書いてあるからなのでしょうか、こちらはあまりうまくガイドできませんでした。FireCaptureはなんとかうまくガイドできましたが、これも最初はあまりうまくいかずパラメータ出しに苦労しました。あと、雲とかで一度位置を失うと、その後の復帰は位置が大きくズレる可能性があります。

要するに、まだ太陽のガイドってあまり確立された技術ではないようなのです。まあ、太陽やっている人が少ないので、仕方がないと言えば仕方ないのですが。

今考えているのは、別のカメラを用意して焦点距離を短くして、全体を見ながらガイドをかけるとかでしょうか。というのは、今回は太陽の縁が入っていたのでたまたまガイドできましたが、今後、黒点のアップなどを長時間撮影したい場合は今の方法では無理なので、何か別の方法を考える必要があります。


画像処理

ここから動画ファイルになるまでの過程を説明していきます。

まずは撮影後の画像処理ですが、動画の場合は通常以上に複雑になります。これまで太陽撮影や、太陽画像の処理をしたことがない方は、まずは下記のページを参考に一枚の画像を最後まで処理してみてください。




一枚がきちんと出せないようでは、多数枚を出すのは至難の技です。今回の動画の処理過程もある程度このページの処理方法に依っています。今回の記事では上記ページに加えて、動画作成で必要な部分に焦点を当てて、一枚画像の処理との違いを中心に説明していきます。


AutoStakkert!3での一括スタック

最初はいつも通り、AutoStakkert!3でのスタックです。撮影した全てのserファイルを一度に開きます。最初のファイルだけ処理すると、順に同じ設定で全てのファイルを処理してくれます。

ファイルの数が多いので、時間がかかります。間違えると全てやり直しで大変なので、慣れていない方は練習のためにまずはファイルを一つだけ開いて、うまく処理できるかどうか試した方がいいでしょう。これでうまく処理できたのを確認してから、改めて全てのファイルを一度に開いて処理した方がいいでしょう。

多数のファイルを処理する場合、撮影時の太陽の位置が長時間安定していなかったり、雲などで画面の明るさに変動があるとそのファイルはうまくスタックできない可能性があります。少なくとも、最初の方のファイルと最後の方のファイルをRAW動画で見てみて、位置が大きくずれていないか、明るさは大きく変わっていないかを確認した方がいいです。

全部の処理には時間がかかると思いますので、じっくり待ちます。


Photoshopで画像の大きさを揃える

次のステップとして、Photoshopで画像の大きさを揃えます。この過程はすごく重要です。なぜなら、AutoStakkert!3は写りの良い部分だけを処理するので、出てきたファイルの画像サイズは一枚一枚バラバラだからです。サイズを合わせないと、後の位置合わせがうまくいかなくて、全くアニメになりません。サイズ合わせはPhotoshopの「イメージ」->「カンバスサイズ」を使ってやります。AutoStakkert!3でできたサイズの中で一番小さいサイズ以下の大きさに設定します。

この過程をアクションツールを使って全てのスタックされたファイルに適用します。詳しいやり方は「Photoshop アクション 繰り返し」などで検索すると出てきますので、そちらを参考にしてください。ちなみにこのページが分かりやすかったです。ここでは簡単な手順だけ書いておきます。
  1. Photoshopを立ち上げ、「ウインドウ」から「アクション」を選び表示します。
  2. アクションパネルの下のアイコンの右から二番目の「新規作成」アイコンを押します。
  3. 新規アクションに名前をつけて、記録を開始します。
  4. 画像ファイルを開くところを含んで記録します。
  5. 先のサイズ合わせを一通りします。
  6. ファイルを「別名で」保存します。
  7. その後、アクションウィンドウの下の左の停止ボタンを押し記録を止めます。
  8. 次に「ファイル」->「自動処理」->「ドロップレットを作成」を開きます。
  9. 「ドロップレットを保存」で先ほどのアクションを選びデスクトップなどに保存します。ポイントは左の「”開く”コマンドを無視」と右の「”別名で保存”コマンドを省略」にチェックを入れておくことです。
  10. デスクトップなどに出来たドロップレットに、ImPPGで処理したTIFFファイルを全て選択し放り込みます。
うまくできましたでしょうか?実際に画像サイズが全て揃った、出力ファイルをきちんと確かめてみてください。


ImPPGで位置合わせ

次にImPPGを使い位置合わせをします。「Tools」の「Align image scequence」を選びます。上のPhotoshopの処理をサボって画像サイズがバラバラだと、位置合わせは全くうまくいかないので注意してください。

cap_ImPPG01

Photoshopで大きさを揃えた画像ファイルを選択します。ポイントは「Align on the solar limb」を選ぶこと。条件は太陽の縁がきちんと出ていることです。太陽が円になっていなくて、一部だけが写っていても、縁さえ写っていればうまく処理できます。これでうまくいかない場合は上の「Stabilize high-contrst feature」でやりますが、こちらは精度が悪くアニメにした時にぶれてしまうと思います。


ImPPGでの一括処理

次に改めてImPPGで炙り出しと細部出しをします。まずはImPPGで位置合したファイルを画像を1枚開き、処理過程を進めます。処理が終わったところで、「File」->「Save Processing Settings」でその際の設定を保存します。次に「File」->「Batch Processing」で、AutoStakkert!3でスタックされた画像を全て選び、先ほどの設定ファイルを選択し、適当な出力先を指定します。保存形式は「TIFF 16-bit」を選択します。「Start processing」ボタンを押して連続処理します。

IMG_0011


最終調整

この時点でもう動画にする準備はできていますが、ImPPGでの画像処理だけだと不十分なこともあるでしょう。例えばPhotoshopのアクション機能を使うことで、全ての画像に同じような処理をすることもできます。また、DeNoiseも最新バージョンではバッチ処理をサポートしていて、同じ処理を多数のファイルに一括で適用することができます。

それでも、背景の明るさが揃い切っていなかったりすることもあるかと思いますが、ある程度は一枚一枚微調整が必要なこともあるかと思います。ここら辺はアニメーションを扱うときには仕方のないことでしょう。


動画ファイルの作成

さて、素材のファイルができたのでここからやっと動画ファイルの作成になります。動画作成はいろいろな方法があるかと思いますが、ここではPixInsightを使います。PixInsightを立ち上げ、「Process」->「ImageInspection」->「Blink」を選び、これまでにできた画像ファイルファイルを全て開きます。
  1. 再生ボタン(右三角)を押すと動画の様子が確認できます。
  2. 真ん中のアイコン列の上から2つ目のオートストレッチがオンになっている場合、画像処理されてしまいます。オフにすると元の画像のまま表示されます。
  3. Previewで一部を切り取るとその部分だけ拡大してその部分だけ動画にすることもできます。
  4. Blink画面の右下の一番右端の撮影開始マークアイコンで動画にします。
  5. ffmpegがない場合は別途インストールしてください。ffmpegがインストールされていても、実行ファイルをフルパスで入れないとうまくいかないことがあります。/usr/local/bin/ffmpegとかいうことです。
  6. 今回の場合秒15コマのgifファイルにしたかったので、-y -r 15 -i Blink%05d.png Blink.gifとしました。
gifファイルは256色の制限があるので、パレットを最適化したい場合は別途コマンドラインで、

ffmpeg -y -r 15 -i Blink%05d.png -filter_complex "[0:v] fps=15,scale=1024:-1,split [a][b];[a] palettegen [p];[b][p] paletteuse" Blink.gif

などとするといいかもしれません。

Blink

実際に出てきたgifファイルを確認してみてください。gifアニメはWebなどでは再生することなく勝手に動画になってくれるので、見ていて楽しいです。長いファイルだとサイズが大きくなりすぎるかもしれません。その時はmp4などに変換するといいでしょう。


まとめ

IMG_9612


一応、動画になるまでの過程を書き出しましたが、うまく動画ファイルになりましたでしょうか?一枚一枚みていただけではあまり変化がわからなかった画像も、動画にするとプロミネンスが活発に動いていることに驚かれるかと思います。

ここに挙げた方法はあくまで一例です。他にも面白い方法があれば、どんどん探ってみてください。また、自分でやってみて分かりにくいところがありましたら、コメントでお尋ねください。できるだけ応えるようにします。

今後、このような動画ファイルがたくさん出てくると、太陽をやってみようという人がもっと出てくるかもしれません。早く太陽活動活発にならないかなー?もっとすごい動画が見てみたいですよね。

太陽楽しいですよー。


久しぶりの太陽です。記事としては3.5nmのHαフィルターの記事以来でしょうか。でも実は太陽撮影はちょくちょくやっています。ただ太陽活動があまり活発でなく、絵的にぜんぜん面白くないので、記事にするに至っていません。


晴れ間にパッと見た太陽に大きなプロミネンスが!

今年のゴールデンウィークはなかなか外に遊びに行ける状況でもなく、遠征撮影もままならないのでZoomで中継をしたりしてましたが、後半は天気もあまり良くないので、庭撮りも諦めていました。5月4日、この日も天気予報は曇りで期待していませんでしたが、午前中外を見ると珍しいくらいの綺麗な青空が広がっていました。透明度は良さそうですが、少し雲もあるので短時間なら太陽撮影できるかなと気楽に機材を出してみたら、東南方向に大きなプロミネンスが見えました。

晴れてる合間にすぐに撮ってしまおうと、午前11時半頃から撮影を始め、一度5000フレームほどのファイルを保存したのですが、風が強かったせいか、シンチレーションがたまたま悪かったのか、処理してみると写りはイマイチ。その後12時近くのわずか400フレームのファイルの方がはるかに細部が出ます。多分風がおさまったせいだと思っています。それを処理したのが下の画像です。

Sun_115711_lapl4_ap1328_IP3_OS_cut
  • 鏡筒: 国際光器マゼラン102M、口径102mm、焦点距離1000mm、F10 アクロマート
  • エタロン: Coronado P.S.T.
  • 赤道儀: Celestron CGEM II
  • カメラ: ZWO ASI290MM
  • 撮影ソフト: FireCapture
  • 撮影時間: 2020/5/13 11:57
  • 撮影条件: ゲイン440、露光時間12.5ms、400フレーム撮影し320フレームをスタック 
  • 画像処理: AS3にてスタック、ImPPGで細部だし、Sharpen AIで処理。
珍しくちょっと大きめのプロミネンスで、きちんと輪になっているのがよくわかります。シンチレーションも悪くなく、細部もよく出ています。

今回、細部を出すのにSharpen AIを使っています。かなり強力なシャープツールなので、擬似線が出てしまう可能性は否定できません。それでも元のファイルの出来が悪いといくらやっても綺麗に出ないこともまた事実で、やはりどんなソフトでも引き出せる限界はあるようです。AIと言えども万能ではないことは言うまでもありません。

上の画像の擬似カラー版です。

Sun_115711_lapl4_ap1328_IP3_OS_color_cut


プロミネンスのタイムラプス動画

さて、今回の目玉はこのプロミネンスのタイムラプス動画です。上のを撮影した後、まだ晴れが続いていたので、同じ構図で連続して撮影してみました。上の画像を撮影したときから30分くらい後の5月4日12時32分から12時50分までになります。

撮影条件は上の静止画の時と同じで、1分おきに5秒間撮影しています。約400フレーム撮影できるのは同じで、そのうちの240フレームをスタックしています。19分間ぶんの画像19枚でgifアニメーションを作っています。19枚で止まってしまったのは、これ以降は曇ってしまったからです。

最初短い時間しか撮影できなかったので全く期待していませんでした。せいぜい画像処理方法を試そうというくらいです。でも実際に動画にしてビックリです。

Blink

およそ20分の間ですが、細かいところがかなり動いていることがわかります。こんなに速く動いているとは想像していませんでした。これを見ると1分おきでもギリギリな間隔なくらいです。ここまでプロミネンスの動きが見えると相当面白くなってきます。

先にTwitterでテスト動画を公開したのですが、160いいねを記録し、TSA-120購入の時の言い値の数を超えて過去最高となりました。そもそも太陽関連の記事はマイナーなせいか、これまでも人気があまりなかったのでこの反応には驚いています。やはりこれだけ活発に太陽が動いているというのはインパクトがあるのでしょう。

ちなみに、その日のSDOの動画がここにあります。



時刻がUTCで表されているのでこの動画の最初の方、5月4日の午前3時半くらいのときのものが今回撮影したタイムラプス動画に相当します。SDOはこのページを見てもわかるように衛星なので、地上から撮影しているアマチュアでは到底太刀打ちすることはできません。それでも時間分解能ではそこそこ検討しているのではないでしょうか?今後、もっと長い時間撮影してみたいと思っています。


撮影方法と画像処理については次回解説

さて、太陽のタイムラプス映像ですが、これまで記事にしたものもあれば、
 

 

撮影だけして記事にしていないものもいくつもあり、実は結構な回数に挑戦しています。

やっと今回、短い間隔で多数枚撮影して、うまく最後まで画像処理する過程を確立することができました。その方法ですが、結構複雑で記事にすると長くなりそうで、未だにてこずっています。次の記事に独立して書こうと思います。多分明日くらいにはアップできると思いますので、今しばらくお待ちください。


おまけ: 撮影風景

タイムラプスの撮影時の風景です。撮影は始まってしまえばリモートで部屋の中から画面を見ることができます。娘が目の前でギターを弾いています。ギターがうるさい中、頼むから曇らないようにと祈っていました。

IMG_0005


縞ノイズ考察(その2): flat補正を他の環境でも試してみる」の続きです。




flatの何が悪いのか?

flat補正がどうも縞ノイズに対して悪さをしているのは、かなり一般的だというのが前回の結論です。flat frameが縞ノイズを作り出すメカニズムとしては、
  1. 出来上がったmaster flatに固定ノイズが存在する。
  2. 固定ノイズが存在するmaster flatで個々のlight frameをflat補正すると、その固定ノイズが個々のlight frameに乗っかる。
  3. ガイド時のずれで流れていく星像を、StarAlignmentで位置合して星が固定になると、今度はこれまで固定だったmaster flatのノイズが流れ出す。
ということです。

ここでの疑問は「なぜflat frameがそんなにノイジーなのか?」これにつきます。この疑問にたどり着いた時に、いくつか原因の答えの候補がありました。ぱっと思いついたのが
  • まずflat frameの枚数が少ない。
  • flat dark補正をしていなかった。
  • カラーバランスが悪かった。
くらいです。その後いろいろ考えていると、何となく答えがわかってきました。答えにたどり着いてから改めて見てみると、上の候補には答えと少し関連することもありますが、ズバリの回答はありませんでした。


推論の検証

では、今回推論したことが正しいかどうかを確認するために、以下の3つのことをこの順序で確認をしてみました。この時点ではまだ考えだけがあって、その考え方が正しいかどうかを検証する方法にたどりついた所で、実際に画像処理をしてみて予測が正しいかどうかを検証してみたということです。
  1. 短時間露光(100ミリ秒)でいいので、多数枚(100枚)のflar frameを新たに撮ってflat補正。
  2. 短時間露光(100ミリ秒)でいいので、前回と少数枚(7枚)のflar frameをを使ってflat補正。
  3. 前回の露光時間と同じ長時間の300秒露光で、そこそこ多数枚(50枚)のflar frameを新たに撮ってflat補正。
この条件を見ると、もう相当ヒントが出ているのですが、何でflatが縞ノイズを盛大に出すくらいノイジーだったのかわかりますでしょうか?少し発想を変えなければ答えにはたどり着かないかもしれません。

それでは結果を順に見ていきます。


1. 短時間露光、多数枚

ケース1、今一度EVOSTAR 72EDにレデューサを取り付け、その先にASI294MC Proを取り付けて、改めてflat frameを撮影します。ただし、短時間露光撮影なので、iPadの「Color Screen」といういつものソフトを使って、画面をRGBそれぞれ128にして鏡筒の前に置きます。ゲインは220と同じですが、露光時間を短く100ミリ秒にして100枚撮影します。カメラと鏡筒の回転角がきちんと再現できないのですが、縞ノイズの影響を見るだけなのでまあいいでしょう。多分ダークノイズも関係ないので、温度も常温でいいでしょう。

出来上がったflat frameを使って、PIのバッチ処理でこれまでと同様に処理ましす。結果は

light-BINNING_1

light-BINNING_1_cut

となり、今回初めてflat補正をしても見事に縞ノイズがほぼ消えています。ということは、やはりflat frameの枚数が多いことで、ノイズが平均化されたことが効いているのでしょうか?

結論を焦らずに、もう少し見てみましょう。


2. 短時間露光、少数枚

ケース2、次は、先ほど撮った100枚のflat frameのうち、もともと持っていたflat frameと同じ枚数の7枚だけ使います。同様の処理をした結果が以下になります。

light-BINNING_1

light-BINNING_1_cut

拡大した画像をよく見ると、先のケース1に比べると多少縞ノイズが目立ちます。なるほど、やはり枚数が問題なのですかね。

いやいや、まだ焦って結論を出してはいけません。


3. 長時間露光、多数枚

では最後、星雲撮影時と同じ露光時間の300秒で試します。その他、ゲインとかもできる限り当時の状況を再現します。違うところは枚数。枚数は当時の7枚からかなり増やして50枚とします。4時間以上分のflat frameになります。
  • 枚数だけで比べたらケース1よりノイジーで、ケース2より滑らかになるはずです。
  • 露光時間だけで考えたら、相当長いのでケース1,2よりも一番きれいになってもいいはずです。
でも私の予測は違っていて、
  • ケース3が一番ノイジー。枚数の少ないケース2よりもノイジーだと予測しました。

では結果はというと

light-BINNING_1

light-BINNING_1_cut

Eureka!!!
何と、やはりケース1よりはもちろん、遥かに枚数の少ないケース2よりもどう見てもノイジーです。露光時間の長いflat frameが一番ノイズが大きいのです!!


露光時間の長いflatが悪さをする理由

なんで?と思う方も多いでしょう。
少し落ち着きましょう。

ここから解説です。まだ答えを見たくないという人は、ここでじっくり考えてみてください。
準備ができたら、下へスクロールしてください。
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

みなさんの中には露光時間を伸ばせばノイズが下がると思い込んでいる人もいるかと思います。でもこれは間違いで、きちんと考えると
  1. 露光時間を伸ばすと信号Sが時間に比例して1次で大きくなる。
  2. ノイズNは時間のルートに比例して大きくなる
  3. その比をとると、時間のルートに比例してS/N(SN比)がよくなる(大きくなる)。
というのが正しい解釈です。で、今回の問題はというと、

スカイフラット撮影時に露光時間を300秒と長くしたのですが、適した明るさのflat frameにするために、露光時間を短い時と同じ明るさに合わせてしまって、信号Sを実質的に何も増やしていないところです。Nはそのまま露光時間のルートで大きくなっていきます。そうするとS/Nは当然露光時間が短い時より悪くなります。この信号が増えていないところが本質的にダメなところです。

逆にいうと、露光時間が短いflat frameの撮影においても、明るさを合わせるために信号は長時間露光の時と同じ。でも撮影時間が短いのでノイズ量はざっくり1/sqrt(300/0.1) = 0.018とわずか2%ほどになります。1枚あたりでこれだけ違うわけです。長時間露のflatを50枚使っても、短時間露光のflat7枚に太刀打ちできるわけがありません。

というわけで、長時間露光flatはSN比でいったら全然得をしていない、いわばノイジーなflat frameになるわけです。やっと答えにたどり着けました。


どうやって考えたか

今一度振り返りますが、今回の考え方はかなり原理に近くて、特に奇異なところもなく、実際に撮影しての比較でも何の矛盾もないので、flatからの縞ノイズに関してはおそらくこれで決着がついたものと思われます。でもなんでこの考えにたどり着いたか?この過程が一番大事だと思うので、自分自身へのメモも兼ねて書いておきます。

まず、今回のflat補正が問題なるということが分かったくらいから、なんでなのかずっと考えている最中に、
  • 縞ノイズに悩まされるのは決まってディザーなし
  • トータル1時間越えとかの長時間露光したとき
だということに気づきました。しかもそんな時は余裕があるので、
  • あえて頑張ってスカイフラットをとったり
しています。この時点で、ある程度スカイフラットが悪いと予測できるようになりました。ディザーをしているケースとしていないケースがあったことがややこしくしていましたが、ディザーをしていなくてスカイフラットの場合は漏れなく縞ノイズが出ていました。

でもなぜスカイフラットが悪いのか?ここを考えるのには結構時間がかかりました。結局、
  • 短時間フラットと長時間フラットで何が違うのか
  • 特にまずはノイズに関してどうなるかを原理からきちんと検証し始めた
のがきっかけでした。すなわり、
  • ノイズに関しては長時間露光の方が当然大きくなる
という、極めて原理的な話です。これはすぐに納得できました。この次に、
  • じゃあ信号は?
と考えた時に、ピンときたわけです。
  • え、長時間露光の場合、信号って得してないのでは?
  • 短時間露光は大きな(明るい)信号を使って時間が短い。
  • その一方長時間露光ではあえて小さい(暗い)信号を長い時間です。
  • 信号の大きさと時間をかけると、どちらも同じ量じゃん!
というところまでたどり着いたのは、ピンときてからわずか30秒くらいです。シャワーを浴びたあと、洗面所で体を拭いている時でした。いつもそうなんですが、シャワーを浴びている時はポーッとしてて、他のことを何も考えずに、そのことだけに集中できる至福の時間。面白いアイデアは、大体シャワー時間近辺で出てきます。

やはりきちんと基本に従って考えるのが一番答えに近かったという、いい例だと思います。ヒントはいろんなところにありましたが、こうやって考えて答えにたどり着く過程はやはり楽しいものです。


まとめ

今回の件、私的には結構な発見でしたが、どうでしょうか?意外な答えでしたか?それとも「当たり前すぎでつまらん」という方もいましたでしょうか?

flat flameからくる縞ノイズの考察については、とりあえずここまで。思ったより早く解決しました。3回の記事でいろいろ検証しましたが、flatに関してはある程度満足した回答を得ることができました。長時間露光flatがノイジーな理由、短時間露光でノイズの小さいflat frameを作る意義も示すことができたのは大きいと思います。これでディザーをしない場合でも、対処する方向性をある程度示すことができたかと思います。

それでも縞ノイズという観点で考えると、まだ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方向に流さないようにすること。これが重要なのは変わりません。ディザーはおそらく根本解決の方法の一つです。


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

 

このページのトップヘ