ほしぞloveログ

天体観測始めました。

カテゴリ: 画像処理

今回はPixInsight上で動く、太陽画像処理用のSolar Toolboxを紹介します。すでに使っている人も多いかと思いますが、日本語の解説はいまだにどこにも見当たらないようです。


PixInsightの太陽画像処理ツール

PixInsight上で動作するSolar Toolboxというスクリプトが、今から1年ほど前の2024年2月にリリースされました。当初から使ってみたいとは思っていたのですが、今のImPPGからPhotshopという流れでそこまで不満ではなかったので、そのままになっていました。

転機になったのは、Astrobinの2025年4月1日のImage of the dayです。恐ろしく精細なプロミネンスのタイムラプスにびっくりしました。とてもじゃないですが、自分ではここまで出せる自信はありません。使っているツールの中にSolar Toolboxという名前を見つけたので、「あ、やっぱりいいんだ」と思ったのがきっかけです。

Solar Toolboxのインストールは

https://www.cosmicphotons.com/pi-modules/solartoolbox/

をPixInsightのレポジトリーに追加し、アップデートをチェックし、その後PIを再起動します。すると、メニューの「Process」の中に「Solar」という項目が作られていて、その中に「SolarToolbox」が追加されています。

Solar Toolboxは、機能的にはストレッチ、プロミネンスの切り分け、プロミネンスのブースト、コントラスト調整、カラー化と、カラー化に際しての色バランスとコントラスト調整、細部出し、デノイズなどがあります。カラーかと細部出しについては、マスク処理もできるようです。これだけ高機能なところをみると、一見他のツールが必要ないようにも思えるかもしれません。一通り試したのですが、決して万能のツールというわけではなく、得意、不得意があるようです。

モードは3つあり、「太陽表面のみ」と「プロミネンスのみ」と「太陽表面とプロミネンス」になります。自分が撮影した画像に応じて選びます。


事前理解と準備

これ以降はできるだけ機能を説明するために「太陽表面とプロミネンス」を前提に話します。他のモードだと、いくつかの機能が使えなくなります。

スクリーンショット 2025-04-15 010102_dialog

ダイアログの右下のDonumentationボタンを押すと、ヘルプファイルが出てきますが、あまり大した説明はないようです。作者によるインストラクション的な動画がアップロードされていて、それを見るのがいいのかもしれませんが、私はあまり動画を見るのが好きでないので、自分で一通り試してみてから、わかりにくいところだけを動画で見てみました。動画は英語なので、英語が苦手な場合は説明を聞くより実際自分でパラメータをいじって何が変わるかを見た方が早いと思います。その上で、今回は私が試した限りで、どの機能が有益で、どの機能はもう少しとかの説明や感想を書いておきます。

そもそも撮影後の、どこまで処理が進んだファイルを読み込ませるかですが、
  • 少なくともAutoStakkert4!などでスタックした後のファイルを使うことになるでしょう。
  • 細部を事前にどこまで出しておくか、プロミネンスの強調やコントラストをどこまでやっておくかは、Solar Toolboxでどれだけ処理をするかに依ります。このSolar Toolboxですが、特に細部出しはあまり強力ではないようなので、少なくとも細部出しはImPPGなどである程度あらかじめすませておいた方がいいのかと思います。
  • プロミネンスとコントラストはSolar Toolboxが結構得意なので、事前に何も弄らなくてもいいでしょう。
  • また、ImPPGなどでヒストグラムの形をいじって暗いところをあらかじめ炙り出しておくのは、やめておいた方が良さそうです。下で説明するプロミネンスのブーストが、事前に炙り出されていないことを前提にしているみたいで、あらかじめ炙り出してあると、明るくなり過ぎたり、特にImPPGで処理するとドット状のノイズが目立ってしまいます。
  • その一方、ヒストグラムの左右を切り詰めておくことは、あらかじめやっておくと楽です。例えばImPPGだとヒストグラムを「見ながら」切り詰めができる一方、Solar Toolbox上だと、切り詰めパラメータを一回入れる毎に、画像の変化をいちいち時間をかけて見なければならないです。効果としては全く同じですが、時間がかかる上に、見通しがとても悪いです。

Solar Toolboxでは、何をするにしてもリアルタイムプレビュー画面を見ながら各機能のパラメータの値をいじるのですが、一つパラメータを変えるたびに結構な時間をかけてプレビュー画面を更新します。全然リアルタイムではないので、できるだけ速いPCを使った方がいいです。


プロミネンスの切り分け機能

まず、一番上のプロミネンスの切り分け機能です。パラメータの微調整がシビアですが、うまく設定すると太陽表面と周辺のプロミネンスを綺麗に分けることができます。デフォルトの0.5を一度大きく変えると何が変わるか見えるので、どんな機能かがわかるかと思います。わかりにくい場合はすぐ下の「Invert」オプションをオンにしてみてください。傾向がわかったら、0.05単位くらいで微調整していけば、好みの切り分けにできるでしょう。

これに相当する機能は、ImPPGでヒストグラムの曲線をいじって、プロミネンス部分と太陽表面部分を切り分けて輝度調整するとかですが、それよりもSolar Toolboxの方がうまく分離できるようです。普通は輝度の違いだけで判断するとあまりうまく分離できないのですが、Solar Toolboxではかなりうまく分離できるので、見ているのは輝度だけはないのかもしれません。一般的には、うまく分離しようとしたらマスク処理が必須となるのですが、マスク無しでうまく分離できるのでかなり便利です。

Solar Toolboxのストレッチは、ブラックポイントとホワイトポイントの切り詰めだけです。この切り詰めはあらかじめImPPGでやっておいた方が、デフォルトのブラックが「0.000」とホワイトが「1.000」をそのまま使えるので楽です。プロミネンスの背景が明るすぎる場合、ブラックポイントを0.01とか、0.02とかに上げて微調整します。プラージュとかの白いところの階調があまり取れていな場合は、ホワイトの値を1.1とか1.2まで上げると、多少階調を改善すことができます。

ImPPGならヒストグラムを見ながら、ガンマ補正や、曲線そのものを任意にいじることができるので、あらかじめいじっておいてもいいですが、今のところSolar Toolboxの使用が前提なら、事前にあまりいじらない方が楽っぽいです。ImPPGでいじって、さらmにSolar Toolboxでいじると、パラメータが多すぎてよくわからなくなることが多いので、私はImPPGでは細部出しと、ブラックとホワイトのと切り詰めをするだけにしています。


プロミネンスのブースト

プロミネンスのブーストは必要十分な機能です。ImPPGの方がヒストグラムで調整できるので、一見高機能に思えますが、再現性や安定度という意味ではSolar Toolboxのシンプルな操作の方が上かと思います。ImPPGでプロミネンスをあぶり出ししていなければ、0.7とか0.8とかの大きな値にしてもいいかと思います。

3D機能は開発者の動画解説によると、周辺のブーストと太陽表面の球のような輝度分布を重ねるような効果だそうです。3D機能を使わないと、太陽全体が見えている時なんかは太陽表面の輝度がフラット化されて、ノペーっとして、3D機能の値を上げると、立体感が増します。太陽表面の印象が印象が変わるので、いろんな値を試して好みを探るといいでしょう。


コントラスト

コントラスト設定はかなりわかりにくいです。まずは左タブの「Histgram equalizatin」で説明します。「Contrast limit」の数字を上げると明るくなって、下げると暗くなるのが基本操作です。「Kernel radius」でどれくらいの粗さかを決めますが、値が100とか小さ過ぎると輝度が大きな範囲で凸凹するようです。私は普段は200以上の大きな値を使っています。

マスク処理は、チェックボックスをオンにしてマスクを表示させながら調整するといいでしょう。「Surface Only」で基本的に太陽表面のみにするか、「None」で全体にするかを分けるものです。「Surface and prom」で好きなところを選べますが、こちらはマスクの状態をよく見ながら、輝度を「Shadow」で合わせる必要があるので、ちょっと面倒です。

結局、「Histgram equalizatin」はかなり扱いにくかったので、隣の「Local contrast」を使った方が楽かと思います。左の「Histgram equalizatin」と右の「Local contrast」は完全に独立な設定で、どちらかを選ぶと、もう一方の設定は全部無視されます。「Local contrast」は数値を大きくすると、特に太陽表面の模様の明るいところと暗いところの差がうまく強調されます。

次のカラー化のところのコントラスト調整と合わせて、この「うまく」コントラストを出すというのが今回のSolar Toolboxを使うことの一番のメリットなのかと思っています。というのも、例えばHα画像をPhotoshopに持っていって、ありとあらゆる調整を試しても、コントラストを素直にうまく改善する機能がほとんど見当たりません。私は普段はImPPGでコントラストを強調してから、Photoshopではほんの微調整くらいしかしませんが、もっと簡単にコントラストを調整できたらとずっと思っていました。そういったい意味で、このSolar Toolboxは非常に優れていると思います。


カラー化

もう一つのSolar Toolboxの利点は、カラー化です。カラー化自身はPhotoshopのレベル補正でなどでもできますが、なかなかいいパラメーターが決まらず、毎回違った設定になって結果も安定な色になりません。

Solar Toolboxのデフォルトの色バランスの設定はかなりうまく選んであって、少し変えてみて結局元のデフォルトの色方が良かったりしたので、ほとんどの場合はデフォルトで処理してしまっています。デフォルトを使うと決めてしまうと、たとえ他の画像を処理しても、かなり安定な色になることが期待できます。もちろんコントラストなどの設定が色味を変えることがあるので、色の微調整はするかもしれませんが、今後画像によって大きくブレるかとは無くなるのかと思っています。

カラー化する場合、その中で2種のコントラスト設定をいじることができます。これらもとてもうまくコントラストを上げてくれるので、下手にPhotoshopなどで自分でやるよりも、簡単に安定して処理してくれるでしょう。ハイライトの方は効果がすぐにわかります。高くすると見栄えが良くなります。通常のコントラストブーストは効果がわかりにくいです。ものすごく大きくしてやるとやっと違いがわかると思います。

ストレッチは0.5から下げると明るくなり、上げると暗くなります。全体の明るさをいじるのはここがメインになります。カラー化する場合はこのストレッチ機能が使えるからいいのですが、モノクロのままだと全体の輝度調整をするのが結構面倒だったりします。モノクロの場合は素直にHistgramTransformationとか使った方が楽かもしれません。

Solar Toolboxダイアログの一番上の「Image type」で「Prominence only」を選ぶと、プロミネンスのマスクが使えるようですが、ここでいうProminence only用の画像とは開発者の解説動画によると、太陽表面が完全に飽和したような画像のことのようです。今回そんな画像は試していないので、ここのマスク機能はまだ使えていません。


細部出し

最後のSharpningは結構微妙です。もちろんシャープにしてくるのですが、こちらはそこまで強力ではなく、ImPPGなどの方がはるかに簡単に強力に処理してくれます。

私が思うImPPGの唯一の欠点は、デノイズ機能がないことです。そのため、ちょっと強力な炙り出し処理をすると、途端に背景とかにツブツブが載ることです。これは月をImPPGで処理すると良くわかります。太陽だとモジャモジャしているところも多いので、背景以外はあまり目立たないのですが、月は表面で滑らかなところがありツブツブが目立ちます。なので、月にはImPPGを使うのを諦めた過去があります。

例えばRegistaxのWaveletや、PIのMultiscaleLinearTransformなどは、細部出しと共にデノイズ機能があるので、ツブツブ感が軽減できるのですが、細部出しそのものについては手軽さまで考えるとImPPGの方が上だと思っています。なので、ImPPGでストレッチと細部出し、少しのプロミネンス強調までして、PIに持っていきMultiscaleLinearTransformでデノイズ処理、その後Solar Toolboxでプロミネンス強調、コントラスト調整、必要ならカラー化とカラー化に伴うコントラスト調整、さらに必要なら細部出しとデノイズを僅かにといったところでしょうか。


タイムラプスへの応用

Solar ToolboxがPixInsightをベースにして動くことで便利なのは、コンテナを使って複数ファイルに自動で同じ処理を適用できることです。今のSolar Toolboxは細部出しが苦手っぽいので、ImPPGを使わざるをえない状況かと思いますが、ImPPGもバッチ処理機能があるので、複数画像に同じ処理を適用できます。連続処理できるツールのみを使うことで、タイムラプスで多数の画像を楽に扱うことができるようになります。


まとめ

Solar Toolboxを一通り試してみましたが、かなり使えます。特にカラー化の安定性と、コントラストを出しやすい点は気に入りました。ただ、Solar Toolbox単体で十分かというと、そういうわけでもないので、他ツールとの併用がいいのかと思います。もう少し使い込んでみようと思います。






前回からの続きで、4月5日の太陽撮影の(その2)になります。


4月5日は快晴で雲のない時間帯が続いたので、大量に撮影したものがあって、その処理が長引いしてまいブログ記事を書く速度が全然追いついていないです。しかもその間に次の週末が来てしまい、新たな撮影が追加されてしまいました。前週のタイムラプス映像の処理がやっと終わったところで一旦記事にしておきます。


プロミネンスのタイムラプス映像

今回は太陽タイムラプスです。前回記事で見せた、太陽表面と周辺の画像撮影をした直後から、プロミネンスの連続撮影を開始しました。機材は前回記事の撮影と同じで、口径20cmのC8にPSTを取り付け、ASI290MMで撮影してます。赤道儀はCGEM IIです。

プロミネンスは大型のものの方が変化が見やすいようです。大型のもので、特に長く伸びている淡いところは変化が激しいと予測し、前回記事にも載せた東端に出ているプロミネンスを引き続き撮影することにしました。今回もカメラの長手方向に収まるように、カメラを90度傾けて撮影し、北が右側、東が上側になるようにしています。

PCの画面を見ると、1枚撮影した時よりも長いプロミネンスが伸びて出ているようなので、早く撮影を始めたいところです。撮影間隔と各撮影でのフレーム数は迷いましたが、1分おきに200フレームとしました。トータル時間もまだ決めてなかったので、とりあえず120枚で2時間としておきました。これは途中でやめる可能性も含めてです。

撮影が始まるとしばらく暇になるので、朝食と、もう一本の太陽望遠鏡を準備してました。ここら辺は前回記事に書いてますね。結局のんびりしていたら2時間が過ぎてしまっていて、PCを見たらすでに撮影が終わっていました。ところが、撮影したものを見てみると、30分を過ぎたあたりから少し雲が出ていて画面が暗くなっていたこと、長く伸びるプロミネンスはわずか30分でほぼ消えたこと、その後のシーイングは少し劣ることなどから、最初30分だけで処理することにしました。やっぱり早く撮影を始めれば良かったとこの時点で反省しました。

このプロミネンスタイムラプスの画像処理は、その後1日くらいで終えることができました。今回は静止画と同じく、見栄えがいいようにカラー化しています。カラー化する際、これまで色がなかなか安定しなかったのですが、静止画でいろいろ試して、やっと安定化する目処がついてきました。ここら辺の処理については別途記事にする予定です。

大まかな処理の流れは
AutoStakkert4! -> ImPPG -> PixInsight -> FIJI->ffmpeg
といったような順です。多数枚の連続処理なので、いつも仕上げに使っているPhotoshopだとちょっと面倒なので、今回はPhotoshopは使わないようにしました。
  1. ImPPGは細部出しと位置合わせをしています。プロミネンスは光球面と周辺部のコントラスト比が高いので、これだけでもある程度位置合わせできます。
  2. PixInsightはSolarToolboxで色出しと、Blinkで連番ファイルの書き出しです。
  3. 連続処理はImageContainereとProcessContainerを使っています。
  4. 位置出しは相変わらずFIJIが最強です。
  5. 動画化はffmpegです。

結果ですが、やはりシンチレーションが良かったのでしょう。動画にしてもそこそこ細部が出ています。


わずか30分ですが、プロミネンスの形も、長く伸びた筋も激しく変化しているのがわかります。ツンツン出ているスピキュールも分単位で出たり消えたりしています。光球面の模様に関しては、まだ精度よく出ているとは言えません。これは今後の課題でしょう。

1分おきでの撮影でしたが、これだけ激しい変化なのでやはり30秒ごと、できれば10秒とか20秒ごとでもいいかもしれません。特にスピキュールの出入りは相当速いようで、1分単位だと明らかに短すぎです。

1枚あたりのフレーム数の200枚ですが、この枚数だとやはり少な過ぎで、ImPPGでの細部出しの際に粒状のノイズが目立ってしまったのが気になります。これはフレーム数を1000枚程度まで増やすとかなり改善することはわかっているのですが、今後数時間単位の撮影を考えると、ディスク容量が足りなくなることは目に見えているので、できれば増やしたくありません。少なくとも今回の200枚では、ノイズ処理が必須でした。逆にノイズ処理を前提とするなら、200枚からどこまで減らせるかの方に興味があります。例えば、SharpCapのリアルタイム処理では100枚でもそこそこ見える画像になります。

フレーム枚数を増やすと、1ショットあたりの撮影時間も伸びるので、撮影間隔をあまり短くできないことも問題です。フレーム枚数を増やしても撮影間隔を短くしても、いずれもファイルの総量は大きくなっていきます。画質とディスク容量のトレードオフなのですが、今後もいい落とし所を探っていこうと思います。


太陽黒点周りのタイムラプス映像

プロミネンスタイムラプスの撮影が終了すると、そのまますぐに黒点周りのタイムラプス撮影に移りました。これも1分おきに200フレームで、2時間分撮影しましたが、こちらはそのうちの最後20枚だけ捨てて、約100枚を使うことにしました。

太陽表面は動きが少ないので2分おきでもいいと思っていましたが、まだよくわからなかったので今回は1分おきにしました。でも結果を見る限りかなり動きが速い部分もあり、1分で良かったと思っています。

プロミネンスとの処理の違いは、各種パラメータくらいで、大まかな行程はほとんど同じです。処理はその後数日けかてやっています。ある程度の時点で一度Xに投稿しましたが、コントラストがあまり高くなくて縞模様の動きがあまり目立っていないがどうしても気に入らなくなり、その後Photoshopのアクションの多数枚処理で色を変えたことが、プロミネンスの時の処理からの大きな違いでしょうか。

結果は以下のようになりました。変化がわかるように、25fpsで動画化してあります。短いので、よかったら繰り返し見てやってください。


出来上がった映像は、自分的にはかなりインパクトがありました。太陽表面はそこまで動いていないと思っていたのですが、一部は非常に激しく動いています。この激しく動いているところは、プロミネンスやダークフィラメントに相当する部分なのでしょうか?同じような模様に見えても、動きの差が場所によって全然違っています。

後半には小さいですが、一部フレアと思われる明るいフラッシュが見えています。フレアだとしたら、私としては初めて撮影できたことになります。


まとめ

今回、処理に思ったより時間がかかりましたが、できた太陽タイムラプス動画はすごいインパクトがありました。ずっと見てても飽きません。特に黒点周りの方は、最初の動画バージョンができた時に1時間くらい見続けていて、どこが面白くてどこの処理を変えたらいいとか、ずっと考えてました。

ちょっとした変更がとても大変だと言うことも今回実感しました。動画にして始めて判断できるところもあり、気に入らなくて途中のパラメータを触ろうとすると、最後までの処理を再び延々とやり直しになります。

今回時間をかけた甲斐もあり、方針も方法も大分見通しがついてきたと思います。今の機材でどこまで出せるのか、もう少し挑戦したいことがあるのでしばらくは太陽を続けようと思います。

ちなみに、この日の撮影だけでファイル総量は181GBにもなってしまいました。使わなかった動画ファイルを捨ててもこの量です。これからずっとタイムラプスを続けるとしたら、ちょっと考えたくなる量です。

次の記事はカラー化のことを書いておこうと思っています。











つい先日仕上げた勾玉星雲ですが、赤が強いのが気に入らなかったので再処理しました。


RGB画像の見直し

WBPPまでは同じですが、そこからはかなり方針を変えています。元々はAOOにRGBの恒星を加えたようなものでした。Hαはよく撮影できているので、この階調の豊かさを残したかったのです。問題はOIIIで、星雲本体の際中心部以外にはほとんど構造を持っていなくて、結局は背景を含むほとんどの場所が赤一色になってしまい、もうどうしようもないです。

そこで改めてRGB画像を見てみました。自宅撮影で背景光が明るくて、スカイノイズが支配的なためにノイジーなのですが、強炙り出ししてみるとそこそこ階調が残っていることがわかります。例えばHαとR画像を比較すると、

Hα画像:
MGC2048_5_10_better_BXT_HT_NXT_back_LHE_A_s

R画像:
Image22_R_s
と、Hα画像に比べてR画像はノイジーですが、同じような形の模様が見えています。

ところがOIIIとB画像を比べてみると

OIII画像:
integration_O_ABE2_SPFC_BXT_back_LHE_OIII_s

B画像:
Image22_B_s
B画像の方が当然ノイジーなのですが、より広い領域にわたり青成分が広がっているのがわかります。

ちなみにG画像は以下のようになり、これもOIII画像より構造を含んでいます。
Image22_G_s

というわけで、方針としてはRGB画像のRをHαと入れ替え、GとBは少しきつめのノイズ軽減をしてきちんと使い、OIIIは最初から使わないという方向でいきます。


比較

結果は
Image26_HT4_cut_s

となり、赤の諧調をそこそこ残しつつ、星雲本体の中心以外はほぼ赤一辺倒だったものから脱却し、多少なりともBとかGを生かすことができました。前回はMGCで頑張って調整したRGBをほぼ全く生かせてなかったのですが、これでMGCの結果も生かせたことになります。

ちなみにAOOベースのものはこれだったので、やはりかなり赤だけが相当強いのがわかります。
Image03_AOO2_s_brighter_cut

ただ、こうやってAOOベースと比べるとRGBベースはどうしてもノイジー感が出てしまいます。これは痛し痒しで、まあ彩度とノイズレスのどちらを取るかなので、仕方ないですね。


MARSデータベースのアップデート

3月21日にこの記事を書いているのですが、画像処理は昨日のうちに終えています。ちょうど今朝、新しいMARSデータベースがリリースされたとアナウンスされました。なんとOIIIデータが含まれたらしいです。これでAOOは可能になり、SAOもRをSに適用することで簡易的に可能となったとのことです。あと、オリオンのデータの露光時間が68分から11時間と約10倍になったとのことですが、もうオリオンも季節終わりなので、実際に使えるのは来シーズンでしょうか。

今回のRGB+Aでの画像処理ですが、せっかくのMARSアップデートなので、今一度OIIIを復活させて再再処理してみてもいいかもしれません。

お蔵入り?になりかけ

実を言うと、この記事書くのをあきらめてました。今回の彗星の核の撮影画像を見てみると、星像がかなり甘いのです。しかも星の数がかなり少なく、うまく画像処理できるか?と初めから疑問でした。実際途中まで全然うまく行かなくて、半ばお蔵入りするところでした。

というのも、ちょっと前に今回使ったSCA260のバッフル交換のアップグレードがあって、ちょうど販売店から返ってきたばかりでした。光軸調整はしてくれたとのことなのですが、その後、強度を保っているはずのアルミの長さ40cmトッププレーを自分で付け替えたため、鏡筒に歪みが残ったままになっている可能性が高いです。改めて光軸調整せずにそのまま持ち出してしまったためでしょうか、とにかく今回の撮影時にピントを合わせても星像が小さくならないのです。もしかしたら単に低空だったからかもしれません。いずれにせよ、普通だったら画像処理をする気にもならないくらいの画質でしか撮影できなかったのです。

とまあ、前置きはこれくらいにして、紫金山アトラス彗星の記事も今回で最後になるかと思います。10月20日に撮った、3セットの機材のうちの3つ目、焦点距離1300mmのSCA260にASI294MC Proを取り付けています。カメラは冷却可能ですが、今回は冷却せずに常温で稼働させています。

前回の記事で、焦点距離250mmのRedCat51とフルサイズの一眼レフカメラ6Dで撮影した画像の核の部分を拡大し、練習がてらLarson-Sekaninaフィルターで角度方向の輝度変化を強調して見てみましたが、広角画像の核の部分をかなり拡大しているため、粗いながらも回転している様子がわかりました。



今回は焦点距離が長く、それよりも遥かに解像度が良いはずなので、どこまで見えるかが楽しみです。


画像処理

とにかく、撮影した画像の処理をPIのWBPPで始めましたが、まずスタックが全然うまくいきません。各画像の位置特定でおそらく星の認識数が全然足りてないのでしょう、RANSACエラーが出まくりで、registeredにたどり着いたのが64枚のうちわずか20枚でした。Debayerまで普通に全部処理されているようなので、その後は自動のWBPPでなく、マニュアルで一ステップづつ処理することにします。

まずはStarAlignmentです。Star Detectionの基準をデフォルトの0.5から0.75にしたら、WBPPでは20枚しか認識されていなかったものが、30枚ほど位置合わせされていました。この方向で良さそうなので、さらに基準を相当甘くします。いろいろ試して、まず元々位置が大幅にズレていた15枚を省き、残り49枚で剃りを進めることにしました。さらにSensitivityとPeak responseを共に0.9程度にしたら、49枚全部を認識し、49枚分のImageIntegrationまでできました。その後、StarAlignmentした画像を、さらにCometAlignmentし、ImageIntegrationすることで無事に彗星核基準のスタック画像になりました。

今回は核の周りの構造を見たいために、基本的にスタックのみで他の処理はほぼ何もしません。ABEなどのソフト的なフラット化さえもしません。当然、恒星の分離もしませんが、核の周りだけ見るには恒星が流れていても基本的にはお構い無しのはずです。ただし、SPCCやPCCなどの恒星を使った色合わせができないことは認識しておくべきでしょう。なので最終画像はグレースケールに落として、モノクロとしました。


Larson-Sekanina フィルター

さて、核基準でスタックだけした画像に、早速Larson-Sekanina フィルターを適用してみます。パラメータを注意深く探りながら色々試して、最終的に距離2ピクセル、回転2度、量0.2であとはデフォルトと決まりました。

角度はあまり敏感ではなく、今回は2度から5度くらいまであまり変化はありませんでした。今回の画像では5度以上ずらすと根本的に違った構造が出てくるようです。そもそもズレを使って淡い輝度の違いを見やすくするものなので、ズレた時にある程度相関を持って重なる必要があるはずです。なので、今回の場合5度以上のズレになってくるとおそらくズレすぎで、全然相関がないところとのフェイク構造が出てしまうのかと思われます。前回、例え話で出した古文書などのズラしを考えてみても、一文字の中の狭い範囲内でズラすことに意味があるのであって、文字を超えて例えば上とか横の別の文字とのズレを見出い出してしまうのは、Larson-Sekanina フィルターでは距離や角度を大きくズラしすぎることに相当するでしょう。全く違う文字と重ね合わせてそのズレを見るのだと、たまたまそれぞれの文字の一部が重なるなどの偶然の相関が検出されるだけで、出てきた構造はフェイクで、結果に意味がないことは容易に想像ができるかと思います。

一方、今回入れた距離ズレの2はそこそこ敏感で、1とか3だと全然違う結果になります。前回の粗い画像でも2.5にしているのですが、これだけ分解能が違うのに、なぜ同じような値なるのかまだ謎です。彗星の核周りの構造の大きさ自身によるのでしょうか?焦点距離が前回250mmと今回1300mm、ピクセルサイズが前回6.3umと今回4.3umなので、焦点距離もピクセルサイズもより細かく見ていることになります。比を計算してみると、1300/250 x 6.3/4.3 =7.62となり、前回と今回の距離のズラしはピクセル単位で8倍くらいあっても良さそうです。前回2.5なら今回は20くらい、今回2なら、前回0.25くらいになっていいはずです。前回の画像でも、今回の画像でも、この比くらい大きくズラしてもみましたが、少なくとも有意な画像に見えることはありませんでした。もしかしたら、まだ私自身が大きな勘違いをしている可能性もあるので、今後の課題とします。

今回のLarson-Sekanina フィルターの適用結果ですが、回転のように見える構造がかなりはっきりと出ました。以下の画像は核まわりを見やすくするために、すでに縦横半分ほどにクロップしています。また、比較しやすいように良画像ともモノクロにしてあります。

フィルター適用前の画像と、
integration2_49files_normal_cut_mono

フィルター適用後の結果です。
integration2_49files_LS_cut_mono

核回りに明らかに時計回りの回転構造と、テイルに縞がはっきりと出ているのがわかります。ただ、Larson-Sekanina フィルターで出てきたテイルの縞は、フェイクの可能性もあるという情報をどこかで見たので、判断は慎重になるべきかと思います。


仕上がり画像

上記画像を、北向きを上にして、クロップして、核の周りをより詳しく見てみます。大きさを示す矢印も入れたので、スケール感もわかるかと思います。
integration2_49files_LS_cut_mono_middle_rot_cut_arrow

拡大してみると、更にはっきりと時計回りに回っていることがわかります。核の大きさがわからないのですが、調べたところによると直径20-40kmとのことです。ほとんどの彗星は直径10マイル(16km)を超えることはないとのことなので、この大きさが本当なら、やはりかなり大きな彗星ということになります。

撮影をした日の地球から核までの距離は、この日は0.595 [au] = 8.9e7 [km]とのことなので、核の直径30kmとすると、核の視野角は0.069秒角程度になります。クロップ前の画像の横幅が50分角程度でそれをCMOSセンサーの横幅の4144ピクセルで見ているので、1ピクセル辺り0.72秒程度です。すなわち、1ピクセルで核の10倍程度の幅があるということです。核は相当小さいことがわかりますし、核がガスを出すことでここまで大きく見えることも実感できます。

パッと見える回転の構造は10ピクセル程度あるので、核が回転しながら、核のすぐ周辺に核の100倍程度のくらいの太さでガスを出していると推測されます。

まだ全然大したことは引き出せていないですが、このはっきりとした回転が見えただけで、もう興奮モノの面白さです。Larson-Sekanina フィルター偉大です。数学的には単純と言いましたが、相当強力で、相当の汎用性を持っていると思います。逆に言うと、汎用性を持っているからこそ単純な数式で表すことができるといってもいいのかもしれません。

汎用的なLarson-Sekanina フィルターをもっと応用できないのかと思いましたが、もしかしたらステライメージに搭載されている「回転アンシャープマスク」は応用例にあたるのかもしれません。ステライメージの回転アンシャープマスクの解説ページを見ると、Larson-Sekanina フィルターにあたるローテーショナル・グラディエントより、微細構造の抽出と滑らかさを両立し、結果を確認しながら仕上げられると言うようなことが書いてあります。惜しむらくは、この回転アンシャープマスクの使用例がほとんど皆既日食で、彗星に使った例は極々わずかなことです。もしこれを彗星核にうまく使えたら、面白い結果が出るのかもしれないと思いました。


まとめ

回転らしきものが見えるのはわかってきたので、次回の大彗星では日を変えて連続で撮影して回転がどう変化していくのかなどに興味があります。日々の変化で、核の回転速度などもう少し何か意味が引き出せるかもしれません。次回の大彗星でどこまでできるかかなり楽しみです。

今回の大彗星の一大騒動、自分的にはやっと終局を迎えました。1ヶ月以上楽しめたので、かなり満足です。特に最後に辿り着いたLarson-Sekanina フィルターでの核の回転画像は、普段の画像処理とはまた違った方向性だったからでしょうか、自分の中でかなりインパクトがありました。その一方、今回の紫金山アトラス彗星では弧を描くようなテイルは見えなかったので、私の中ではそれでもネオワイズ彗星の方が印象が大きいです。これは最初に見た大彗星だったと言うこともあるのかもしれません。

次に大彗星が来るのはいつのことか?8年で2回見たペースの通り、4年後なのか?もっと先なのか?意外にすぐ来るのか?今から楽しみに待ちたいと思います。


少し間が空いてしまいましたが、SWAgTiで撮影したパックマン星雲について補足です。


実は上の記事にする前に、画像処理ははるか以前に終わっていたんです。でもダーク補正の有り無しで比較した時のノイズの大きさが、理論と全然合わなくて、ずっと検証していました。その結果、かなり面白い考察となったので、その経緯を書いておきます。


ダーク補正ありなしの、数値的な比較

前回示した記事の繰り返しですが見た目ではダーク補正の有り無しは差がわからないようです。

comp_dark

ちなみに左がダーク補正無し、右がダーク補正ありですが、差はあったとしても本当にごくわずかでしょう。でも、ノイズを実際に測定しても同じくらいなのでしょうか?数値で見てみましょう。

ノイズの測定には、いつものようにPixInsightのImageInspectionのStatisticsを使います。各画像で「プレビュー」で
  1. 恒星が入っていない
  2. 背景に近い一番暗い部分
を、小さな領域でいいので選びます。そのプレビュー画面をStatistics上で選択肢、「stdDev」を見ます。stdDevなど、見たい情報の項目が出ていない場合は、スパナマークのアイコンを押して必要な項目を選択してください。その際、左上の単位がきちんとカメラと合っているか確認してください。今回の場合、カメラが14bitなので、「14bit [0,16383]」を選びます。単位は [ct] すなわち、ADCのカウントになります。コンバージョンファクターがわかっていれば、これを電荷の[e]に変換することができます。

上のエリアを選ぶ二つのことは、ノイズを正確に、安定に測定するために必要な条件です。

恒星が入っていると、恒星は飛び抜けて明るいので、バラツキ(=ノイズそのもの)が大きくなり、本来より大きなノイズの値が出てしまいます。

一番暗い部分を選ばないということは、何らかの天体などの明るさを測定していることになります。明るさがあると、そのバラツキからくるショットノイズが大きくなり、本来見たいダークノイズや読み出しノイズが隠れてしまう可能性があります。

これらのことは基本なのですが、その他にも注意すべきことがあります。今回の測定中にやらかした失敗も含めて、反省の意味も込めて今後の測定のために細かく書いておきます。


撮影と画像処理の条件

前の記事の繰り返しになりますが、一応撮影と画像処理の条件も書いておきます。

撮影はRedCat51+DBPでカメラはUranus-C Proで-10℃に冷やしています。架台はSWAgTi (SWAT350 V-SPEC PremiumにAZ-GTiを載せたもの)で、撮影ソフトはNINA。ガイドは無しで、NINAの特殊機能のガイド無しディザーで最初のうちだけ1枚に一回、途中から3枚に1回ディザリングしています。

ライトフレームは露光時間が1枚当たり3分で、カメラのゲインは100、オフセットは40で撮影しています。94枚画像処理に回したので、合計282分 = 4時間42分ぶんです。この間、NINAでも順調に動いて、特にSWAgTiの長時間撮影で縞ノイズを避けるために必須であるディザリングも問題なく動いていました。ライトフレームは10月9日に合計139枚撮影しそのうち94枚を使い、ダーク補正比較のためのダークフレームは後日77枚撮影して使いました。
がそう処理は、SWAgTiの簡単撮影の特徴を活かすために、バイアス補正、フラット補正などは無しです。解像度を上げたいので、drizzle x2を選択しておきます。

というような条件で、この記事ではダーク補正の有り無しを比較します。


測定失敗1

「Bayer配列画像はノイズ測定に用いるべきではない。」

  1. まず正しくスタックされているかどうか確かめるために、ライトフレームのRAW画像1枚のノイズを測定します。結果は12.5 [ct]でした。
  2. 次に、スタック後のダーク補正なしのマスターライト画像のノイズを測定します。予測だと94枚スタックした場合、ノイズが1/√94 = 0.103倍に近い値の12.5 x 0.103 = 1.29程度になるはずです。でも実際測定してみると、1.08 [ct]と予想よりかなり小さい値になってしまいます。
でもこれはすぐに気づきました。1枚画像はBayer配列のままなので、RGGBでそれぞれ平均値が違ってしまっているために、その平均値のばらつきでノイズが大きいと勘違いしてしまっているのです。解決策としては、Debayerしてからノイズを測ります。PIでDebayerして、再度Statisticで恒星のない部分のノイズを測定すると、6.44[ct]となり、これを0.103倍すると0.663[ct]となります。でもまだマスターライトファイルのノイズ1.08[ct]とはかけ離れています。


測定失敗2

「Drizzle画像はノイズ測定に用いるべきではない。」

Debayer同士で比べているのに、なぜスタック後のノイズが予想より大きすぎるのか?これも少し考えてすぐにわかりました。Drizzleした画像は微妙にずらして重ねたりして解像度を増やしているので、そもそもノイズがどうなっているのかよくわかりません。ここはDrizzle前の画像で評価すべきでしょう。Drizzleはオプションなので、Drizzle前のマスターファイルもきちんと保存されています。Drizzle前のマスターファイルのノイズを測定すると、0.620[ct]で、今度は予測値の0.663[ct]とほぼ一致しました。

これで少なくともダーク補正なしで1枚画像を94枚スタックした場合、ノイズが理論通りの1/√94 = 0.103倍に近い値になることがわかりました。


ダーク補正でノイズは数値でどうなるか

さて、いよいよ別途77枚のダークファイルで作ったマスターダークファイルを使って、各ライトフレームをダーク補正して、WBPPでスタックまでしてマスターライトファイルのノイズを測定します。今回は最初からDrizzleされていない方を選び、Preview機能で恒星がない部分のノイズを測定します。結果は、目で見て比べた時と同様に、ノイズの値はダーク補正がない時の0.620[ct]と比べて、ダーク補正ありだと0.625[ct]となり、ほとんど同じなのでものの見事に一致したと言っていいでしょう。

結論としては、ダーク補正ありでも無しでも、ノイズはほとんど変わらないというのが今回の結果から言えることです。

見た目でダーク有無でほとんど差がないのが、数値でも同様に、ほとんど差がないと示されたわけです。


本当にダーク補正の影響はないの?
.
.
.
え???
.
.
.
でも、

なんでここまで同じなの?ダーク補正の影響は全くないの?

ランダムノイズであるダークノイズを持つ画像で補正しているわけです。ランダムなので引こうが足そうが、補正すればノイズは必ず2乗和のルートで「増える」はずでは?何も増えないのは少なくともおかしいのでは?

とここから長い迷走が始まりました。


スカイノイズが大きいのでダーク補正のノイズ増加が無視できる?

パッと考えられることは、明るい環境で撮っているので、スカイノイズが大きすぎてダークノイズが無視でき、たとえダーク補正してもほとんど影響がないというシナリオです。でも今回はサイトロンのDBPを使っているので、光害はかなり軽減されているはずで、スカイショットのいずの影響は少ないはずです。もしかして、DBPを入れていてもスカイノイズが大きすぎるくらい明るい環境なのでしょうか?

こちらも定量的にきちんと比較してみましょう。そのためにはライトフレームの背景領域の全ノイズに比べて、ダークノイズがどれくらい貢献しているかを比較すればわかるはずです。簡単のために、1枚撮影したファイルで比較します。

まずはダークフレームのノイズですが、今回もきちんとDebayerすることを忘れずに、これまでと同様にPreviewで領域を選択して、Statisticで測定します。結果は5.30[ct]でした。ここにはダークノイズと、バイスノイズ(読み出しノイズ)が含まれていることに注意です。

一方、ライトフレームの1枚画像のノイズは上の測定でわかっていて、6.44[ct] 程度です。

5.30[ct] と6.44[ct] なので、少なくともダークノイズと読み出しノイズが含まれたものは、ライトフレームに含まれるスカイノイズ(+ダークノイズ+読み出しノイズ)に比べて、無視できるくらい小さなものではないことがわかります。

ライトフレームは94枚、ダークノイズは77枚でスタックするので、予測では
  1. ダーク補正無しだと6.44 x1/√94 = 6.44 x 0.103 = 0.663[ct]というノイズと、
  2. ダークフレームの5.30 x 1/√77= 5.30 x 0.114 = 0.60のノイズが2乗和のルートで加わるため、
  3. sqrt(0.663^2 + 0.60^2) = 0.90[ct]
程度になるはずです。でも実測は0.625[ct]と、予想の0.90[ct]1.5分の1くらいで、これは有意に小さすぎます。この矛盾を見つけるのに、相当な時間がかかってしまいました。


なぜダークノイズは増加しない?

1週間以上考えていたでしょうか。答えがわかったあとは、まあ当たり前のことでしたが、これまであまり考えたことはありませんでした。いや、概念としてはおそらく考えていましたが、どう適用するとか、数値で確かめるというようなことは全くしてきませんでした。他に同じようなことを考えた例はないかと思って検索しましたが、定量的な評価はおろか、それに関する記述も見つけることができませんでした。

さてここでクイズです。

今回、なぜダーク補正しても
背景のノイズが増えなかったのでしょうか?

一見不思議ですが、きちんと説明することができます。答えは下の方に書いていますので、自分で考えてみたい方は、ここでスクロールするのを一旦止めてください。答えに必要な条件は上の「撮影と画像処理の条件」のところに全て書いてあります。

答えがまとまった、もしくは答えを見てみたい場合は、下に進んでください。
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
と、答えに行く前に、一つヒントを出します。ヒントはディザリングです。これで答えに辿り着きますでしょうか?

答えがまとまったら、さらにスクロールしてみてください。
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

はい、もうわかりましたでしょうか?答えは「マスターダークファイルも、ディザリングでノイズが散らされる」からですよね。

まだ、ちょっと言葉足らずかもしれません。そもそも今回はPIのWBPP処理に則っているので、先にマスターダークファイルを作って、それを各1枚1枚のライトフレームにおいてそれぞれダーク補正しています。マスターダークファイルを使っての補正の効果は、個々のライトフレームで補正してから重ね合わせても、ライトフレームを(位置がズレることなく)重ね合わせてからマスターダークファイルで補正しても、数学的には同じことです。証明はここ


「ダーク補正の定量的な扱い」あたりから読んでもらえるとわかるかと思います。

ところが実際の撮影では、それぞれのライトフレームは、ディザーをしてライトフレーム時に画面を少し散らして撮影しているので、画像処理の際に「星の位置が合うように」重ね合わると、当然背景はディザーの分だけ散らして重ね合わせられます。個々に補正したマスターダークファイルが、全く位置をずらさずに重ね合わせられるなら、先ほどいった数学的な証明の通り、マスターダークファイルのノイズが2乗和のルートで増えます。ところが、マスターダークファイルがディザーの効果でずれて重ねあってしまうと、個々のライトフレームで補正されたマスターダークファイルのノイズはコヒーレントに重なることはなく、ランダムに重なってしまうことになります。そのため、個々のライトフレームに対して、マスターダークファイル1枚(元のダークノイズの)のノイズ分増加したものが、ライトフレームの枚数のルート分軽減されてしまうのと同じことにになるので、今回の場合さらに1/√94 = 0.103倍となり、ほぼ無視できてしまうというわけです。

実際に、マスターダークファイルで補正した個々のライトフレームを、星の位置合わせをせずに、重ねただけの画像を示します。
integration

小さな揺れが見えることからディザーはされているのはわかりますが、7時間にわたる長時間露光なので、一方向にドリフトしていっている様子も伺えます。この画像の恒星の無いところの背景ノイズを測定してみると、0.938 [ct]となり、見事に予測値の0.90[ct]とかなり近い値で一致します。


結論

というわけで、「ディザーをしているために、マスターダークファイルを使ったダーク補正では、マスターダークファイルの相関のある部分が散らされすために、補正後のダークノイズが増えることはない」というのが今回の結論です。

また、そもそものダーク補正の目的であるホットピクセルですが、
  • Uranus-C ProはDPS (Dead Pixel Suppression)機能のために元々ホットピクセルが緩和されていること
  • PixInsightでCosmeticCorrectionでホット/クールピクセルが緩和されること
と2つの効果で、実際の画像比較でもダーク補正の本来のホットピクセルの緩和の効果がほとんどわからないのかと思われます。


少し見直し

以前の解析で、ライトフレームに対して、ダークフレームは何枚くらい撮影したらいいかを検討していますが、


ディザリングの効果を考慮考えるとこのダークフレームの必要枚数の条件は遥かに緩和されることになります。これを数学的にどう表せばいいのか?ディザリングでどれくらい散らされるかに依るので、統計的な表現が必要になりそうです。かなり複雑になりそうなので、ここではこれ以上の計算はちょっと諦めます。

ただし、このディザリングがあればダークフレームの枚数を減らすことができるというのも、ある程度の制限があるはずで、例えばライトフレームの背景のノイズが、ダークノイズが支配的な場合は、少ない枚数のダークフレームで補正すると、今回考えたようなディザリングによる散らしの効果はあまり聞かなくなるはずです。

極端な例を示します。非常に暗い空で超長時間露光などして、ライトフレームがダークノイズに比べて読み出しノイズも背景のスカイノイズも無視できるとします。ダークフレームは1枚だけ撮影し、それでライトフレームを補正します。個々のライトフレームのダークノイズは√2~1.4倍になります。ライトフレームをスタックする際に、ディザリング効果でどう散らそうが、ダーク補正によって加えられたダークノイズはスタック枚数のルートで軽減されるだけで、ライトフレームに元々あったダークノイズのスタックによる軽減と同じ効果なので、結局のところダーク補正をした場合はダーク補正しない場合に比べて1.4倍程度ノイジーになります。

もしディザーしなかった場合は、ダーク補正によって加えられたダークノイズは、スタックによって軽減されないので、スタック枚数のルート倍大きくまります。例えば、100枚ライトフレームをスタックすると、ダーク補正しない場合に比べて10倍ダークノイズが大きくなります。

極端な場合の比較ですが、ディザーの有り無しで、1.4倍の悪化から10倍の悪化までと、非常に大きな差が出ます。必要ダークフレームの枚数に対して、ディザリングの効果が相当影響すると思っていいでしょう。

ネットを検索すると、ディザリングでホットピクセルが散らされて軽減されるというような記述はたくさん見つかりましたが、調べた限り、ディザリングがマスターダークフレームを散らすので、ダークフレームの枚数を減らすことができるというような記述を見つけることはできませんでした。定性的に考えたら至極当たり前だと直感的にもわかるのですが、定量的な話はおろか、定性的な話もこれまでほとんど言及されてこなかったようです。今後興味があるのは、これをどう定量的に示すかです。言い換えると、ディザリングの効果をどう数学的に記述するかです。また機会があれば考えてみたいと思います。


ダークノイズについて

天文関連の画像処理のページを検索すると、所々に、ダークノイズ = ホットピクセルとか、ダークノイズにはホットピクセルやクールピクセルのような固定ノイズと、ランダムなノイズがあるというような表現を見かけます。私も後者のような表現を使ってきました。でも、ダークノイズというのは本来はダークカレント(暗電流)の揺らぎが起因のノイズのはずです。ダークカレントも、ホットピクセルも、温度の増加とともに増えてくるものですが、ホットピクセル自身がダークノイズというのは、やはり少し強引な気がします。

「ダークフレームを撮影すると、(ランダムに振る舞う) ダークノイズとともに、ホットピクセルも顕著に見えるようになり、そのダークフレームを使うことで固定ノイズであるホットピクセルをライトフレームから除去することができるが、ダークノイズはランダムに揺らぐ(インコヒーレントな、コヒーレントでない、相関の無い) 「ノイズ、揺らぎ」なので、引くことはできずに、必ず2乗和のルートで増える。」

というのがある程度正確な記述かと思います。ホットピクセルはダークカレント起因ではないはずなので、やはりダークノイズとははっきり区別した方がいいのではないでしょうか?


まとめと日記

ここしばらく悩んでいたことが、やっと解決して、ブログ記事にまでまとめることができました。つうじょうに撮影していて、ディザリングもしていて、ダーク補正されている方は、ダークフレームの枚数がより少なくてもいいという話なので、これまで特に問題がないようならば、今回の話は特に気にする必要はないです。でもこういった解析はやはりしておくべきだと思います。しかも、できるだけ定量的に評価できるようにというのが重要だと思います。こういった積み重ねが、どんなノイズが支配的で、どこを改善すればより良くなるかなどに、効率的につながっていくのかと思います。ディザリングの数学的な表現をどうすればいいのか、今後の課題です。

ついでに日記です。今日11月8日(金)から小海において星フェスが開催されています。例年だと諸手を挙げて参加なのですが、今年は体調があまり良くなく、全然予定が立っていませんでした。ここしばらく調子は良かったのですが、先週の長野の泊まりで少し疲れてしまって、今週はあまり調子が良くありません。明日の朝起きて、調子が良ければあまり長居しない程度で行こうと思っています。天気はすごくいいみたいなので、できれば行きたいのですが...。


2024年10月20日に撮影した3種のセットアップですが、



なかなか画像処理を進める時間がとれていません。彗星は時事ネタなので、本当はもっと早く仕上げたいのですが、まだ時間がかかりそうです。とりあえず処理が終わったものからブログ記事にしていくことにします。

今回、まずはタイムラプス映像を処理しました。


機材など

機材はシグマの50mmのレンズをF2.8で使いました。ISOは1600で固定、露光時間は最初1/4000秒、F11から始めて暗くなるごとにまずはF値を小さくしてF2.8まで行きます。今回使った画像はF3.5から2.8に至るまででした。F2.8になったところで、あとは露光時間を暗くなるごとに伸ばして、最後は2秒まで行って、この頃になると彗星もきちんと写っているので、あとは放置で撮影を続けました。連続撮影にはMagic Lanternを使っているので、PCなどは使っていません。画像はRAWのcr2フォーマットでSDカードに保存されます。保存された画像は492枚ありました。

画像処理は、今回は基本的にPixInsight (PI)を使いました。最後の動画を作るところでffmpegをPI内から呼び出して利用しています。


PIでの動画作成

実際に使った画像は452枚。RAW画像なので、PixInsightで開くとBayer配列でモノクロに見えます。まずは、PixInsightでまとめてDebayerをかけます。パラメータはデフォルトです。

次にBlinkで動画にします。Blinkでそれらのファイルを開きます。
blink0

Blinkを使って全ファイルにオートストレッチをかけます。オートストレッチは2種類あって、
  1. 真ん中の列の、一番上のボタンが個々の画像にあわせたオートストレッチパラメーターをするもので、画像ごとにそれぞれにパラメータが違うので時間がかかります。
  2. 真ん中の列の、上から2つ目のボタンが、ある画像でオートストレッチをして、そのパラメータを全画像に適用するもので、同じパラメータなので早く処理できます。
1の場合、明るさが揃うので一見綺麗に見えますが、夕方から夜にかけての明るさの「変化」は失われてしまいます。2の場合、空の明るさの変化を追うことができますが、今回の場合途中で露光時間を変えたりして、手作業でカメラで明るさ調整をしているので、その調整がうまく行っていないところが不自然な明るさ変化になってしまいます。両方見比べましたが、今回は明るさの変化を残したくなり、2を採用しました。2の場合ですが、ある程度暗くなったところを基準にオートストレッチパラメータを決めたので、最初の方の画像が明るすぎることがありますが、まあこれは仕方ないでしょう。

Blinkのオートストレッチボタンの列の、上から3つ目は、色バランスをリンクさせる(撮影時そのまま)か、リンク解除(ホワイトになるように整える)かが選べます。今回はリンクを外しましたが、後でここからさらに全画像にHistgramTransformをかけたので、どちらでも良かったかもしれません。

とりあえずこの時点で、右下の一番右端の撮影開始マークアイコンを押して、一旦動画にまでしてみました。この時点でもしffmpegがない場合は、別途インストールしてください。ffmpegがインストールされていても、実行ファイルをフルパスで入れないとうまく動画にできません。Macだと/usr/local/bin/ffmpegとかいうことです。

blink

ファイルサイズを大きくしないように、デフォルトのpngではなくjpgをはき出したいので、一番下のファイル形式を.jpgに変更します。ffmpegのオプションは秒20コマのmp4ファイルにしたかったので、

-y -r 20 -i Blink%05d.jpg Blink.mp4

としました。

出来上がった動画を見てみると、炙り出しがまだ不足気味なのと、背景がグレーになってしまいあまり面白くなかったので、もう少しそれぞれの画像段階での処理を進めます。


PIでの他数枚の画像ファイルの処理

多数の枚数の画像処理は、PixInsightの
  • ImageContainer
  • ProcessContainer
が便利です。

  1. まずはImageContainerを開きます。そもそもImageContainerがどこにあるのか見つからないかもしれませんが、PIのメニューのProcessの一番下のところにポツンとあります。Process内に並ぶたくさんのグループの中には無いので注意です。
  2. 先ほどBlinkでストレッチまで済ませた多数のjpgファイルを、ImageContainerに登録します。
  3. さらに出力フォルダを設定します。その際、Outputl templatで出力ファイルのファイル名の指定を「&file name;&extension;」とします。そうするとファイル名がそのまま保持されるので、ffmpegで再度動画にするときに、そのまま同じコマンドが使えます。
  4. 次に、ImageContainerのインスタンスを作ります。左下の三角マークをマウスでクリックして、そのままマウそのボタンを離さずに、PI内の背景画面にドロップ (マウスを移動してマウスのボタンを離す) してください。

次はProcessContainerです。
  1. まずは、Blinkが出力したjpg画像のうち、適当な1枚をPixInsightで開きます。
  2. 今回はScreenTranserFunction(STF)を使いました。STFを立ち上げ、開いた画像を自分の好みの明るさとカラーバランスにします。
  3. 次にHistgramTransformation(HT)を開き、STFのインスタンス(左下の三角マーク)を、HTの下のバーに放り込みます。このように、バーに放り込むというのは、PixInsight独特の操作方法ですね。
  4. ProcessContainer(PC)を開き、今度は開いたPCの画面内に、先ほどのHTのインスタンスを投げ込みます。
  5. 最後に、ProcessContainerのインスタンスを、先ほど作ったImageContainerのインスタンスに投げ込みます。
PC

すると順次各ファイルの処理が進みます。

実はHTだけならProcessContainerは必要なく、直接ImageContainerにHTのインスタンスを投げ込むだけでできるのですが、Script処理などのさらに複雑な処理を多数枚の画像に適用しようとするとProcessContainerが必要になります。なので今回は略さずに説明しましたが、面倒な場合はProcessContainerをスキップしても構いません。

実際の画像処理にはもっと凝ったことをやってもいいかもしれませんが、タイムラプス動画なのでこれくらいに抑えておこうかと思います。もう少しやるとしたらですが、見る限りノイズが結構多いので、もう少し1コマあたりの露光時間を伸ばしてもいいかもしれません。ただ、単に露光時間を伸ばすだけだと星が流れるので(まあ動画なので多少流れてもいいのかもしれません)、1コマの時間にあたる20秒内でもっと枚数をかせいで、1コマごとに10枚くらいをスタックするとかでもいいのかもしれません。もしくは、20秒の前後の画像を何枚か合わせてスタックして一コマを作り、その前後のファイルを少しづつずらしつつ重ねてノイズを減らすとかも面白いかもしれません。ただし、これ以上撮影枚数を増やすとなると、メカニカルシャッターの回数制限のこともあるので、デジタル一眼レフカメラよりは、フルサイズのカラーCMOSカメラが欲しくなってきます。


タイムラプス映像

出来上がった動画を見てOKそうなら、最後に画像サイズを変更します。Macだとターミナルを開いて、出来上がった動画ファイルがあるフォルダに移動して、

ffmpeg -y -r 20 -i Blink%05d.jpg -vf scale=1920:-1 -b:v 20000k Blink.mp4

などとします。Blinkでこのコマンドを直接指定してやってもいいかもしれませんが、jpgファイルをまた出力することになるので時間がかかってしまいます。一旦jpgファイルが出力されて、もうjpgファイルレベルでの変更はないと思ったら、ffmpegを単独で走らせた方がいいでしょう。

もしjpg画像の最初の方を使いたくなくて、たとえばBlink00100.jpg以降のファイルのみ使いたい場合は

ffmpeg -y -r 20 -start_number 100 -i Blink%05d.jpg -vf scale=1920:-1 -b:v 20000k Blink.mp4

などとします。

今回は横幅を1920のHDMIサイズとし、ビットレートを20Mbpsとしています。最初453枚で作りましたが、上のコマンドで示したように初めの99枚を除いて処理したので、合計354枚の画像を使い、47.1MBの動画ファイルとなりました。できたmp4ファイルをYoutubeにアップロードしたものです。


最後に雲が流れる時くらいに、左側に少し天の川が入ってきています。

もし出来上がった画像のファイルサイズが大きいなどの場合や、フォーマットを変えたい場合は、Handbreakが便利です。でもこちらも時間がかかるので、ビットレートを変えたいだけとかならffmpegを再度走らせた方が速いかもしれません。


まとめ

久しぶりの動画なので、メモがわりに作成方法を少し詳しく書いておきました。

まだ画像処理がたくさん残っています。次は何から手をつけようか?早めにやらないと時期も去ってしまいますが、焦っても仕方ないので、落ち着いて順次進めるようにします。

このページのトップヘ