今回はフェニックスでできるだけ高分解能で撮影したという話です。



以前CP+でフェニックスをお借りしていた時は、手持ちで太陽の全景が入るモノクロカメラでちょうど良さそうなものはApplo-M miniくらいでした。このカメラはグローバルシャッターが付いていて、シーイングなどで素早く動く太陽の模様を撮影するのには向いているのですが、ピクセルサイズが4.5μmとそこそこ大きく、高分解能撮影にはちょっと厳しいです。当時、分解能の比較として手持ちのピクセルサイズ2.9μmのASI290Mで画像比較をしてみました。下の画像はCP+で使ったスライドの1ページです。


下の2段は同型のASI294で、カラーとモノクロ（ただし、センサーはIMX294とIMX492で違うものです）で比較したもので、同じピクセルサイズならやはりモノクロの方が分解能的に有利なことがわかります。ピクセルサイズの違いは、上の段の2枚を比べてもらえばわかるように、ピクセルサイズが高々2/3になっただけなのに、小さい方がかなり有利ということがわかると思います。その一方、このASI290MMはセンサー全体のサイズが小さいため、フェニックスでの撮影では太陽の全景が入らないので不便で、その当時のフェニックスには常用使いにはなりませんでした。

その後SHG700での分光撮影のために、センサーサイズが大きくさらにピクセルサイズも2.0μmと小さい、ToupTekのカメラG3M678Mを手に入れました。口径8cmの鏡筒にPSTをつけた状態で、ASI290MMとG3M678Mの比較は以前していますが、今回はフェニックスでこのカメラを使って撮影してみます。全景が入るのはもちろん、分解能がどこまで向上しているのか楽しみです。



試したのは2025年12月6日のことです。前回フェニックスのファーストライトの続きで、まずは眼視で楽しみます。

ところが、エタロンの様子がちょっとおかしいです。元々回転リングの動く角度は60度程度と大きくないのですが、その範囲でHα線の周りを走査できるようになっているはずです。ですが今回は接眼側から見てエタロン回転リングを反時計方向に回していくと徐々にプロミネンスが濃く大きくなっていき、大きくなりきっているかどうかわからないくらいで回転できる範囲が終わってしまい、それ以上エタロンを調整できないのです。

少なくとも、先々週のファーストライトではこんなことは気づきませんでした。夕方間近で時間がなくて気づかなかっただけかもしれませんが、流石にこれだけ不自然だと気づいていておかしくないレベルです。

前回と大きく違っていることは、ここ最近で気温が急激に下がったので、エタロンの振る舞いが違っている可能性があることです。そういえば、CP+で借りたフェニックスも同じ方向にHα線の中心波長が寄ってしまっていたことを覚えています。季節もちょうど同じ冬だったので、元々暖かい時期に回転中心に調整したものが、気温変化で同方向にずれてしまっていると考えてもおかしくなさそうです。

さて、これで撮影してもつまらないでしょう。せっかくの透過幅の狭いエタロンの能力を引き出すことができません。販売店に相談して送り返してもいいのですが、それだとまた時間がかかってしまいます。

フェニックスのエタロンは、裏にスポンジがついていて、PSTのエタロンと似た構造になっています。下の画像はCP＋講演のときのスライドの1ページですが、裏から見たエタロン部のところにオレンジ色のスポンジのようなものが見えるのがわかるかと思います。


PSTエタロンの特許が切れたので同型のエタロンを作ることができるようになったとの噂もあり、構造は酷似していると考えられます。PSTのエタロンならエタロン本体（2枚鏡の心臓部）以外は完バラしているので、構造はよく理解しています。手で触れる外側の回転リングの内側にもう一つ回転リングがあり、実際の調整は内側のリングで圧力をかけてエタロンの2枚の鏡の間の距離を変えています。外側のリングと内側のリングは一本のネジで固定されていて、しかも内側のリングには円周上にネジ穴がいくつも開けられているために、ネジをそのうちのどれかに締め込むことによって、内側のリングと外側のリングの相対的な位置が決められています。

もしフェニックスのエタロン部の構造が同じなら、同様のネジがあるはずで、そのネジを緩めて外側の回転リングを独立して回してやり、ネジを別の穴に挿して締めてやることで調整範囲を変えることができるはずです。



フェニックスのエタロン部の外観を見ると、ちょうどそれらしいネジがありました。


これから示す方法は、決して難しい方法ではありませんが、マニュアルなどには記載されていない方法で、あくまで自己責任での調整になります。これで故障などしても販売店の保証は受けられなくなる可能性があります。それを理解した上で、必要な方はお試しください。中心波長が回転範囲内に入っていないと思っても、心配な方は販売店に修理依頼などをお尋ねください。このブログではあくまで調整方法があるということを示すだけで、それによって生じた不具合などを補償することはできません。繰り返しになりますが、あくまで自己責任ということを理解した上で実行するようにしてください。


事前準備1: 外側リングをどちら方向にずらした方がいいかをあらかじめ確認しておきます。

1. 太陽を見ながら、Hα線の中心と思われる位置に外側回転リングを回して合わせます。
2. 波長中心に持って行ける場合は、そこからリングを回して、回転端までどちらの方向が狭いか、どちらの方向が広いかを確認します。
3. 回転端まで狭い方向にリングを回しきってしまいます。
4. もし、Hα線の中心に行く前に回転端に到達してしまった場合はそのままにしてください。こちらも下の調整では回しきった反対側の方向に回転リングを回します。

事前準備2:

1. 金色の金属の回転リングの対物側の端と、エタロンを上から固定している文字が印刷されている金色の金属円盤との黒い溝状の隙間の長さを確認しておきます。3-4mmくらいかと思います。

実作業:

1. 上の写真で見えている、外側リングに埋め込まれているネジをマイナスドライバーで緩めてネジを引き出します。
2. ある程度緩めるとそれ以上出てこなくなるので、つまんで少し引っ張ってやります。
3. ネジが内側リングの穴から抜けると、外側のリングが独立して軽い力で回転方向にも、前後にも動くようになります。その際、ネジが外側リングからスッポリ抜けてしまっても構いませんが、その際は再び外側リングに挿し込んで、尚且つ内側リングからは抜けた状態になるようにネジをもっていってください。
4. 事前準備2で確認した、黒い溝の隙間の距離を保ちながら、事前準備で確認した、回転端に達したのと反対方向にリングをゆっくり回します。
5. 黒い溝の隙間の距離を保つことに気をつけつつ、ネジの頭を少し押しながら回していくと、ネジが少し押し込める場所があることがわかります。ここが隣のネジ穴になります。
6. 一度ネジを数回転回して仮止めしてから、実際の太陽像を見ながら外側回転リングを（内側回転リングと一緒に）回して、Hα線が回転範囲の中心に来たかどうか確認します。
7. ネジ穴をずらした距離が不十分なら、さらに隣のネジ穴を探して同じことを繰り返します。

私の場合はHα中心が丁度回転端付近にまで達していたので、3つくらいネジ穴をずらしたところで、回転範囲の中心にHα線の中心が来るようになりました。



上のように調整した後は、眼視で見てもプロミネンスがちょうど回転中心付近でよく見えるようになりました。表面の複雑な模様もよく見えます。大きな黒点が出ていてちょうど真正面にきているので、眼視でも迫力がありました。

付属アイピースは焦点距離を調節できるタイプのものなので、拡大もできて便利です。また、スマホアダプターも付属されているので、使ってみました。うまくスマホを固定するのに少しコツはいりますが、固定さえできればあとは簡単に撮影することができます。普通に写すとかなり明るくなってしまうので、スマホのカメラ機能で輝度を落とすといいのかもしれません。


jpegで保存されていますが、これでも多少の画像処理をするだけでプロミネンスや表面の模様が見えてきます。



スマホの殺絵だけでも楽しいかもしれませんが、ここからはモノクロCMOSカメラを使った本格的な撮影にうつります。カメラはG3M678Mです。このカメラはピクセルサイズが2μmと天体用カメラとしてはかなり細かい部類で、分解能を上げることができると思われます。その一方、センサーサイズも1/1.8インチとそこそこ大きく、今回のフェニックスの焦点距離400mmだと太陽全景がプロミネンスも含めてちょうど入るくらいの大きさです。

フェニックスの鏡筒の口径は8cmですが、エタロンを取り付けたときはエタロンの開口径の4cmに制限されるため、実効的には口径4cmとなります。その場合の分解能は例えばドーズ限界を考えると11.6秒 / 4cm = 2.9秒となります。

その一方、センサーサイズが7.7x4.3mmなので、焦点距離400mで画角を計算すると1.10 x 0.616度となります。解像度が3840x2160なので、1ピクセル当たりの画角は1.03秒となります。上のドーズ限界と比べると、カメラの分解能の方がすでに十分細かいので、オーバーサンプリングになります。うーん、こうやって改めて比較してみると、すでにオーバースペックのカメラですね。

それでも、ドーズ限界は眼視における2つの星を輝度で見たときの分離限界とも言えるので、撮影の際にはのちの画像処理も考えると輝度差を拡大できるので、分解能はもう少しよくなるはずです。例えば、かなり昔に惑星撮影でドーズ限界をどれくらい超えることができるかを議論したことがあって、ざっくり1.5-2倍程度まで改善できそうだという検討結果でした。

また、カメラのピクセルサイズと分解能について議論したこともあり、ピクセルサイズがレイリー限界やドーズ限界よりも細かい方がより分解能を上げる効果があるのではないかと、当時は結論付けています。

なので、おそらくですがまだこのレベルだとピクセルサイズが小さくなることは効果があって、今回のカメラは分解能に対してまだ貢献できるのかと思います。実際には口径4cmの分解能にかなり近いところを攻めるくらいになっているはずで、言い換えると、フェニックスの性能限界にちょうど迫るくらいになっているのかと思います。

ここら辺の検証は、カメラを例えば手持ちの2.9μm/pixelのASI290MMにわざと分解能を落として比較するとか、バローレンズを入れて分解能が上がるのか上がらないのかを見るなどで実際に確かめることができるのかと思います。余裕があったら試してみたいと思います。



実際にG3M678Mで見てみます。まずはSharpCapで簡易的にライブスタック機能を使います。この時点で黒点周りのHαの模様もかなりの分解能で見えることがわかります。


この時にそのままPNGで保存したファイルになります。

どうでしょうか?画面にWaveletの設定が出ていますが、ほぼオート設定です。500枚のライブスタックで、簡単にここまで見ることができますが、これは楽でいいです。実際ここまで出るのはかなり楽しいと言わざるを得ません。

せっかくなので、serフォーマットで動画で撮影し、マニュアルでスタックして、画像処理までしてみました

直接比較してみるとどうでしょうか？左がSharpCapのライブスタック、右がserファイルからのマニュアル処理です。

さすがにライブスタックそのままだと差が大きいので、別途画像処理してみましょう。左がSharpCapのライブスタックを画像処理したものです。右は上と同じでserファイルからのマニュアル処理です。

どうでしょうか？両方とも画像処理することが前提なら、ライブスタック画像もマニュアル処理にかなり迫ることができます。それでもやはり差はあって、特に明るいところと暗いところの階調の滑らかさや分解能など、きちんと出すならやはり動画からマニュアルで処理した方が多少いいようです。

今回のフェニックスとG3M678Mは、太陽全景を一度に写しつつ、口径4cmのフェニックスの限界近くに達しているものと思わ、ある意味ベストに近い組み合わせなのかと思います。これ以上分解能を上げるには大きな口径の鏡筒を使うのが正しい方向です。口径を増やして、さらに拡大して撮影して分解能を上げるのが、次に考えることになるのかと思います。



今回の組み合わせは、フェニックスが15万円強、G3M678Mが4万円強で、合計20万円程度です。決して安い価格ではありませんが、一昔前の太陽望遠鏡ではこの値段ではここまでの性能を出すのはかなり難しかったと思います。太陽望遠鏡としてはまだ入門機なのですが、それでもフェニックスの透過波長幅は0.6Å以下とかなり優秀で、ここまで太陽Hα画像が出るのなら、しかも簡単なライブスタックでもこれくらいは出るのなら相当なコストパフォーマンスです。

上の全景画像のように簡単に全面がムラなくほぼ一様にHα中心に見えるというのは、実は驚異的なことだと思います。例えば手持ちのPSTエタロンでは、均一範囲は3-4割と言われています。フェニックスエタロンは製品ごとのばらつきもほとんどないと聞いているので、安心して手に入れることができる入門用の太陽望遠鏡なのかと思います。いい時代になったものです。フェニックスエタロンの詳しい性能については、CP+での講演動画をご覧いただければと思います。





この日は天気は良かったのですが、思ったより風が強かったので、フェニックスでの撮影を終えてからは少し気が抜けてしまって、自宅でのんびりしていました。そんな折、お客さんがきてくました。以前、太陽を見に来てくれたＭさんの所の中3のお嬢さんです。私が朝からXでつぶやいていたのを見てお母さんと一緒に訪れてくれました。

まだフェニックスのセットアップは残っていたので、アイピースに戻して実際に太陽を見てもらいました。と言ってももう夕方近くで、太陽が隣の家の高い木にかかってしまっていたので、わざわざ赤道儀をずらして太陽が見える位置に移動しての観察になります。星座ビノに太陽フィルムを付けたもので、太陽黒点も直接見てもらいました。

満月の次の日でちょうど月の話が出たので、望遠鏡を一本持って帰ってもらいました。ビクセンのポルタで、昔星まつりで中古で特価で手に入れたものです。振動比較で使ったくらいでほとんど使っていなかったので、長期貸し出しということで自由に使ってもらいたいです。うまく月が見えたかどうか、今度会ったときに感想を聞いてみたいです。

タグ ：

#太陽

#フェニックス

#Phoenix

#Hα

#エタロン

#SharpCap

#G3M678M

#PORTA

最近ずっと太陽で少し疲れてきたので、たまには夜もと思い、少しメンテナンスも兼ねて電視観望関連のテストをしました。



先月末の飛騨コスモス天文台での電視観望は散々な結果に終わりました。やはり普段から触っていないと、いざというときに使い物になりません。今回はちょっと反省して、きちんとメンテナンスすることにしました。


現在電視観望用としては3台のPCを運用しています。Windows SURFACEの7と8、M1 MacのVMware上で動くArm Windowsです。その中でメインはSURFACE 7で、予備がM1 Macだったりします。理由は仮想上でない普通のWindowsの方がなんだかんだ言って安定していることと、予備も含めてWindows PCを2台も持っていきたくないことです。SURFACE 7はSWAgTiなど撮影用にも使っていて環境を壊したくないので、いまだにWindows 10で、電視観望に用の環境も整っています。SURFACE 8はWindows 11で、太陽用に使っていたりでそこまで電視観望用の整備をしてませんでした。

今回いい機会なので、3台とも関連ソフトをアップデートをすることにします。想定ハードウェアはFMA135+Uranus-C+トラバースと、50mmレンズ+ASI294MC+自由雲台の広角電視観望の2種類です。そのための関連ソフトは最新のバージョン番号も書いておくと

• SharpCap 4.1.13484.0
• SynScan Pro 2.5.18
• ASCOM driver for SynScan App 1.5.1
• ASCOM platfome 7.0.2

となり、これらを3台のPCで全て最新版にアップデートしました。年単位でアップデートしていなかったものも結構あったので、いい機会となりました。

最新版にするにあたり設定も少し見直しました。特に以下の4点は、おまじないかもしれませんが、SharpCapとSynScan Proとの接続の不安定性の解決に効く可能性があります。

• SynScan Proの「設定」「接続の設定」の「リードアウトタイム」をデフォルトの200msから1000msにしました。これで最初に接続に失敗することが少なくなります。
• ファイヤーウォールでパブリックでの接続を許可しました。これは効果があるか不明ですが、プライベートだけだとダメだったことがあります。
• SynScan Proの「設定」「観測値」の緯度、経度情報を自動ではなく手入力すること。
• SharpCapのプレートソルブ設定の所の鏡筒の焦点距離をきちんと入力すること。

3台とも、ソフトアップデート後、上のような設定に気を付けてセットアップしましたが、どれもSharpCapとSynScan ProのWiFi接続も安定していて全く落ちることはなく、以前あったSharpCapのプレートソルブを3回実行すると必ずSynScan Proとの接続が落ちるという謎の現象も無くなりました。



広角電視観望ではできるだけ大きいセンサー面積が欲しいので、ASI294MCを使っています。手軽さ優先なので冷却は無しです。問題はM1 MacのArm版 Windowsです。カメラドライバーだけはArm版専用のものを必要とします。逆にカメラドライバー以外では今のところ大丈夫で、ASCOM用ドライバーなどカメラ以外の全てのドライバー、その他全てのアプリはArm用ではなく普通のWindowsのものがそのまま使えます。これは結構驚きでした。

カメラドライバーのインストールは以前かなり苦労しました。


その苦労もあり、PlayerOneのドライバーは安定して動いています。

問題はZWOカメラで、ドライバーをインストールはできて一応動くのですが、Windowsを再起動するたびに署名を無効にしなくてはならずに、そのためだけにWindowsをさらに2回再起動する必要があるなどかなり面倒です。しかもその署名無効方法があまり直感的でなく、覚えきるのが大変で、手順を間違えると深刻なことになる可能性もあり、毎回手順を確認しながら実行するようにしています。そのためやる気が大きく削がれてしまい、観望会においてM1 MacでASI294MCを稼働することはかなり稀な状況になってしまっています。

今回約1年以上たって状況が改善されていることも期待したのですが、調べた限りは状況は全く変わっていないようで、相駆らわず今も署名オフが必要なようです。これは結構残念でした。VMwarewを落とさないか、レジューム機能でWindowsを停止状態にしておけば復帰後もカメラドライバーが生きているので、観望会前は事前に一度認識させておくのがいいのかもしれません。



M1 Macで電視観望を控えるもう一つの理由が、SynScan Appのプレートソルブ「SynMatrix AutoAlign」でUranus-Cが認識されないことでした。SURFACE 7ではきちんと認識されているのに、なぜかM1 MacのArm Windowsでは認識されていないのです。この問題、SynMatrixが必要になるときは結局SURFACE 7を使ってしまって、M1 Macのほうでは長らく解決せずという状態が続いていました。

今回は少し気合を入れて調べてみます。まず、SynMatrixでPlayerOneカメラを認識しているのがSURFACE 7のみ、しかもよく見てみるとZWOカメラもSURFACE 7のみでしか認識されていません。M1 Macだけでなく、今回SynScan ProをアップデートしてSynMatrixが使えるようになったSURFACE 8の方もカメラを全く認識していません。どうやらArm Windowsだからという問題ではないようで、Armが悪いというのは単なる思い込みだったようです。

結局この問題はかなり単純で、少し調べると、SynMatrixがリリースされた時のどこかのコメントに、カメラ用のASCOMドライバーが必要だという記述がありました。まずSURFACE 8に、ZWOカメラ用のASCMOMドライバーと、PlayerOne用のASCMOドライバーをインストールしたら、無事に両カメラとも認識され実際に画像を取り込むことができました。特に、PlayerOneの方はASCOM platformの6.5を必要とすると書いてあったので心配でしたが、7.0.2でも普通に動くようです。

さて問題のM1 Mac上のArm Windowsですが、こちらもZWOとPlayerOneの ASCMOドライバーをインストールしてみました。すると何の問題もなくSynMatrixで両カメラとも認識され、(ZWOの方は署名をオフにしてから)無事に画像を取得することができました。

これで3台ともSynScan Proでのプレートソルブ、SharpCapでのプレートソルブ、安定なSharpCapとSynScan Proの接続が実現され、今後の観望会での電視観望運用に目処をつけることができました。



広角電視観望で、カメラレンズとZWOカメラを接続するアダプターをAmazonで見つけた安物にしたところ、飛騨コスモス天文台の観望会でピントが出なかったという致命的な欠点がありました。その時は時間がなかったので結局諦めたのですが、あらためて見直してみました。

まず一番の原因が、QBPが入っていて、それが薄型のT2と1.25インチフィルターをつけるアダプターでカメラにねじ込んで取り付けてあったので、接続アダプターのねじ込みが足りなかったことが問題でした。薄型といっても厚さが数mmはあるので、影響があるみたいです。

まず、フィルターをねじ込みアダプターごと外して、接続アダプターを一番奥までねじ込んで試してみると、ギリギリですがなんとかピントが出ます。このテスト自宅でやっていたのですが、ここでちょっと驚きました。この状態で見る天の川があまりにはっきりしているのです。これまで天の川電視観望は何度もやってきましたが、いずれもCBPやQBPを入れた状態で試していました。これは同時に主に赤い星雲を見るためなのですが、天の川自身の見え方はかなり犠牲にしていたようです。


ただし、当然ですが星雲の見え方はかなり犠牲になります。上の画像は天の川の一番濃いところらへんで、M8干潟星雲などが映り込んでいるのですが、どこにあるかわかりますでしょうか?

この写りだと星雲を見てもらうにはちょっと厳しいので、試しに何とか元々使っていたQBPを入れてなんとかピントが出ないか試してみることにしました。結局、カメラ側に取り付けるのではなく、接続アダプターとレンズの間の隙間に、ねじ込むことをせずにポンと置くだけのような形で入れ込みました。


揺らすとちょっとカタカタ鳴りますが、T2アダプターが防波堤になってレンズを傷つけるとかもなさそうなので、実用上は問題ないでしょう。

QBPを通して見た天の川ですが、上と同じような画角で見るとこうなります。

今度はM8、M20、M17、M16など星雲がはっきりとわかりますが、逆に天の川が随分と淡くなります。

見栄えがかなり違うので比較してみるのが面白いかと思います。なので、できるならフィルターの取り外しがすぐにできるといいのですが、これは今後の課題としたいと思います。



SharpCapのアップデートに伴い、ライブスタックで恒星の色合わせを実現する機能が追加されていました。調べたら6月30日のバージョン4.1.13447.0で搭載されたようなので、まだ出来立てホヤホヤみたいです。どの星の色かを特定するために、プレートソルブと合わせて働く機能のようです。

それに合わせて、背景を自動で調整する機能も搭載されたようです。

各色の上にある白いマーカーの左側をずらすことで、マニュアルでどれだけ引くか調整することもできるようです。

これまでも色バランスと輝度のストレッチなどを駆使して恒星の色を調整するとかはできることはできたのですが、今回はPixInsightのPCCみたいに、より客観的に、安定して色をそろえることができるようになったということかと思います。



以上久しぶりの電視観望ネタでしたが、先月あったトラブルはメンテナンスでかなり状況は改善されたと思います。3台体制で、どれも機能に差がなく、同様の動作が期待できます。

今週末にまた飛騨コスモス天文台で観望会があることと、夏休みで8月にも何度か観望会の予定があるのでこれでちょっと安心です。さらに、今回試したノーフィルター天の川も含めて来てくれたお客さんに披露できればと思います。

タグ ：

#電視観望

#FMA135

#トラバース

#Uranus-C

#ASI2904MC

#SharpCap

#広角電視観望

#天の川

#QBP

前回記事で、やっと1枚分の画像を処理しました。


それでも、細かい部分は分光撮影特有のブレが生じてしまっています。今回はこれを改善します。

今回の紹介するスクリプトは、SHG700に特化しているわけではないので、Sol’Exユーザーにも有効な撮影方法になるかと思います。



改めて拡大して細かいところを見てみます。



黒点部分も、プロミネンス部分も、潜在的な分解能はそこそこあるのに、縦縞のようなブレが起きてしまっていて実質的な分解能が落ちてしまっています。

このブレを理解する前に、分光撮影から太陽画像の再構築がどうやって行われているかのプロセスをきちんんと理解しておく必要があります。



まず、鏡筒から出てきた光が7μmという細いスリットを通り抜け、細長い形をした光が回折格子にあたります。回折格子では波長ごとに分光され、空間的に広がりを持ってカメラに向かっていきます。カメラのところでは、その分解された光がセンサーの縦方向に広がって記録されますが、ROIで縦方向を200ピクセルに制限して記録しているので、(分解能が約0.1Å/pixelと分かっているので) 合計で約20Å幅ぶんが記録されます。

一方、センサーの横手方向は、赤道儀のモーターでRA方向にスキャンすることで、太陽を縦方向にスライスしていった線が、横向きになって記録されていきます。この横に長い線は、センサー上の縦方向に波長ごとに広がって記録されるので、面積を持った像になります。この時の一本の線から得た面積を持った画像が1コマとなり、それを連続してスキャン撮影することで動画として記録しています。

同じ波長の線、ここではHα線を考えましょう、この線は一直線にはならずに今回の場合上に凸の曲線になります。


暗い部分がＨα線に相当し、赤い曲線はその中で最も暗い部分をフィッティングした線です。この曲線に沿った同波長の部分を1コマの画像から取り出し、直線に変換します。その直線が太陽全景を描くための一本の縦線となります。それら一本一本の線をプリンタのように書いていくことで、一枚の太陽の全景画像が出来上がるというわけです。



このように全景画像をどう再構築するかを理解しておくと、なぜ分光撮影の場合に細かいブレがしょうじてしまうのかが理解できます。直接の原因は、スキャンしている間に機材に揺れが起きてしまうことです。ある一本の線を撮影するときの揺れと、次の一本の線を撮影するときの揺れは、撮影する時間が違うために揺れの分だけずれてしまいます。

一般的な撮影でこのようなズレが起きないのは、画面全体を面積として一度に撮影しているからです。画面内では分光の時の線のような時間的、相対的なズレはなく、全体的な揺れが撮影時間で平均されたものになっているだけだからです。

改めて最初の拡大した画像を見てみます。特に太陽表面とプロミンセンスの境のところを見るとよくわかりますが、縦方向に細かい線のようになっているブレが目立ちます。一瞬スピキュールと思うかもしれませんが、スピキュールなら表面とプロミネンスの境界線に対してほぼ垂直に立つはずです。でもこれらの線は、境界線の上でも横でも下でも、たとえ太陽表面内の真ん中でも、全部縦方向のみに表れます。これは縦線を並べていく際に、縦線の縦位置がブレているものを並べたからだということがわかります。


一本の縦線は一度に撮影するので、相対的なズレはないが、各縦線は別時間に撮影しているために、縦線同士ではどうしても相対的なブレが生じてしまっているということで、これは分光撮影では原理的に完全に取り去ることは難しいでしょう。

また、一本一本の線が完全にバラバラにブレているというわけではなく、何本かまとまってゆらゆら揺れているのがわかります。この揺れのエンベロープをたどっていくと、機材が時間的にどのように揺れていったのかがわかります。この揺れは情報として残っているので、それを補正するように線を置いて行けば、一枚画像でももっとブレの少ない画像になるはずですが、探した限りではそのような補正をしているソフトは見つかりませんでした。(2025/7/4 追記: JSol'ExのImage Enhancedに「Jagged edges correction」という似たような試みがありました。でも実験レベルとのことで、試してみましたが、プロミネンスを段差と認識してしまったり、確かに実用レベルにはなかなかならないようです。)このような試みも、次に書く改善方法の一つだと思います。



これらのブレを改善するためには、まず直接的には揺れを抑えることです。この機材の揺れはどこが大きいかというと、やはりネックとなっている鏡筒とSHG700の接続部が弱いので、鏡筒に対してSHG700本体が大きく揺れていると考えていいでしょう。もちろん赤道儀や鏡筒部分も揺れてはいますが、特に風邪などが吹いた場合にはSHG700自身がどうしても一番揺れてしまうのかと思います。実際、分光撮影では風が一番効くという記述が多くあります。シーイングがいい日を選ぶのも大事ですが、分光撮影ではまずは風の静かな時を選んだ方がいいというのは理にかなっている気がします。

もう一つの改善策は、惑星撮影での画像処理のように、多数の枚数を撮影して、画像を歪ませて位置合わせをしてスタックすることです。通常の太陽撮影でもスタック処理はしますよね。太陽でも私の場合、最近は200フレーム、必要なら500フレームとか1000フレームとかをスタックします。

今回はこの多数枚スタックを試してみたいと思います。

ただし、分光撮影では1枚の画像を作るのも結構な手間なので、そこまで枚数を増やすことはできません。いかに手間をかけずに多数枚撮影するかが鍵となります。



ここまでが前振りで、やっと今回書きたいことに辿り着きました。多数枚のスキャンをどうやって楽にやるかです。ここでは、SharpCapのスクリプト機能を使います。

まずはこのページで紹介されているスクリプトをダウンロードします。SharpCapで連続スキャンを実現するスクリプトです。上の方にあるオリジナルは中国語ですが、英訳されたバージョンが下にスクロールすると見つかります。落としたZIPファイルを適当なフォルダに展開します。

SharpCapを立ち上げ、メニューの「ファイル」->「SharpCapの設定」から「起動スクリプト」タブを選択します。「追加」ボタンを押し、上記スクリプト(SHG_SharpCap-Script-202XXXXX.py) をSharpCap起動時に読み込むように設定します。SharpCapを再起動すると、アイコン群の中の右のほうに「SHG」と書かれたボタンができるはずなので、それを押すと次のような画面が出てくるはずです。


設定はある程度見ればわかると思いますが、

• 「Target」はとりあえずSun-Hαを選びます。
• 「Slew Rate」の値は赤道儀によりますが、4とか8とか16になるかと思います。この値は先に一度マニュアルで撮影した値と同じでいいはずですが、私の場合その時の8だとなぜが遅くなったので、最終的には結局16としました。
• 「Duration of each Video Record(sec)」は何秒間撮影し続けるかです。上のSlew Rateにも依存します。一度マニュアルで太陽の端から端までスキャンして、時間を測るといいと思います。それより多少長めに設定します。私の場合、太陽が通る時間は15秒くらいですが、ここでは30秒と指定しています。なかなかぴったりとは収まらないので、ある程度余裕がないと、像が途中で切れてしまいます。
• 「Delay before Record(sec)」は録画前に何秒待つかですが、決めにくいパラメータの一つです。私はとりあえずデフォルトの3秒にしておきました。
• 「Fine tuning(sec)」はモーターが加速しはじめてから一定のスピードになるまでの時間のようなのですが、あまりよくわかりません。説明には1とか1.2がいいと書いてあります。とりあえず1.0で試しました。
• 「Scanning Count」は何往復するかの繰り返し回数です。
• 「Scan Axis」はSHG700の場合はRAになるかと思います。
• 「Record Direction」はどちらの方向に動く時に撮影するかです。最初は「Foward only」でやってましたが、途中から時間がもったいないので「Forward & Backward」にしました。ただしForward & Backwardは1往復で2回撮影するので、Scanning Countを10とかにすると20本動画ファイルができます。またプラス方向とマイナス方向でそれぞれ.serファイルを処理する必要があるので、2度手間になったりします。結局私はForward & BackwardでScanning Countを5とかにし、プラスとマイナス2回処理するのをデフォルトにしました。
• それ以降の2つの「per Round」と「--> ROI...」と「--> Click...」はよくわかりません。説明にもないもので、後から追加で付けたみたいです。全部0にしています。

ちなみに、これらの設定は、解凍したスクリプトと同じフォルダにある、SHG_SharpCap-Script-202XXXXX.profile.iniを編集することで、プロファイル名と設定内容を保存でき、再度SHGスクリプトを起動したときにプロファイル名を指定することで呼び出すことができます。例えば上の設定なら、




ここまでの設定がOKなら、撮影テストと、本番の連続撮影になります。

1. まず、RAモーターを動かして、太陽の丁度真ん中くらいの位置に来るようにします。とりあえず繰り返し回数は1にして「Start batch Scan Record」ボタンを押してみてください。
2. ピッと音がして、バック方向(East)に動き出します。
3. 太陽の端を通り過ぎてしばらくしたところで止まって、今度はフォワード方向(West)に動き出します。
4. 録画開始とか出るので、その時点でまだ太陽が見えていないこと、ちょっとしてから太陽が見え始めること、太陽がもう一方の端に到着すること、その後に録画終了とメッセージが出ることを確認します。
5. しばらく(10秒くらい)すると最初にあった位置に戻るので、それまで何も触らないほうがいいです。
6. 撮影した.serファイルを改めて確認します。もしここで、録画内に太陽が全然収まりきらないなら、Duration of each Video Record(sec)を長くします。もしくは最初か最後の片側だけ切れているなら、最初が切れている場合はバックのEast方向に少しずらし、最後が切れている場合はEast方向に少しずらし、撮影初期位置を調整します。
7. 再び「Start batch Scan Record」を押して、きちんと太陽が全て録画時間内に収まるまで、録画時間もしくは撮影初期位置の調整を繰り返します。
8. 無事に録画時間内に太陽が入るなら、「Scanning Count」を例えば10に増やし、Start batch Scan Recordを押して、10往復するのを待ちます。
9. 全てが終わると、元の位置に戻るはずです。この元の位置への再現性はそこそこ正確なので、もし戻る位置が違うなどがある場合は、何かハード的にトラブルが起こっている可能性が高いです。

2025/6/27 追記: 特に赤道儀の極軸がずれていると、何度か撮影している間に徐々にずれてしまう可能性があります。昼間なのでそもそも極軸を合わせるのが難しいこと、赤道儀のモーターを回しながらの撮影なので原理的にオートガイドはできないことなど、太陽の位置がずれていく可能性は十分にあります。回数にもよりますが、連続撮影は10分程度はかかるので、その間太陽が画面内に保たれるような曲軸合わせの精度が必要になります。



保存された.serファイルが問題ないなら、次はJSol'Exで複数のファイルを一度に処理しましょう。JSol'Exのメニューの「File」->「Open SER file」から撮影したserファイルを開いて、出てきた画面の下の真ん中の「Quick mode」ボタンを押してください。

ここではメニューの「File」->「Batch mode」から撮影した複数の.serファイルをまとめて開きます。出てきた画面のいくつかの横バーの一番下の「Miscellaeous」を開いて、「File naming pattern」を「Batch」にしておくといいでしょう。ここからは前回と同じ簡易処理で、真ん中の「Quick mode」ボタンを押します。しばらく待つと同じ種類の画像ファイルがまとめて一つのフォルダに保存されます。

あとはこれらをスタックします。JSol'Exにもスタック機能はありますが、使ってみた限りあまり精度がよくないようなので、ここは普段のようにAutoStakkert!4を使います。AutoStakkert!4を立ち上げ、ファイルを開くときに「Images」を選択し、先ほどできた画像ファイルを全て選択し処理します。今回はdiskフォルダ以下に入っていたストレッチと化していないRAWに近いような13枚の像をスタックしました。

出来上がった画像を下に示します。どうでしょうか？

比較のための拡大図です。この記事の最初に載せた画像と同じ画角です。


明らかに細かいブレが軽減されているのがわかります。これ以上は枚数を増やすか、風やシーイングが穏やかな日を選ぶとかになるかと思います。



ここからの処理は普通の太陽画像と同じです。まだRAWファイルをスタックしたような状態なので、画像処理で細部を出すことができます。

ImPPGを使ったり、SolarToolboxを使ったりすればいいでしょう。今回はImPPGで細部出しとプロミネンス強調までして、さらにPixInsightでSolar Toolboxは使わずに細部出しをしてみました。

最終的にはこのようになりました。まずはモノクロです。

解像度もかなり出ていて、プロミネンスの淡いところも出ています。縦方向のブレは完全には消せませんでしたが、そこそこ見えるくらいにはなっているかと思います。

次にモノクロの反転です。

更にカラー版と、その反転です。




これでやっと満足できるレベルの太陽全景画像になりました。普通の撮影と違い、多少手間もかかりますが、0.18Åという波長分可能と、全景でここまで空間分解能がでるなら、これだけの手間をかける価値も十分にあるというものです。

次回はJSol'Exの使い方です。これも面白いですよ。いろんな種類の画像が出てきます。

タグ ：

#太陽

#SHG700

#分光

#連続撮影

#SharpCap

#SHG

#JSol'Ex

#AutoStakkert

#script

#ImPPG

最近ものすごく忙しくて、土日も仕事のことが多いです。先週末の福島も行けずじまいでした。そんな忙しい状況ですが、先週のある晴れた平日に朝早く起きて、色々と試しました。結局この日は自宅にいたので、セッティングだけして撮影中はほったらかしにしておきます。しばらく梅雨で何もできそうにないので、しばらくこの日にやったことを記事にしていきます。



最初はSharpCapを使っての太陽全景のタイムラプス映像です。SharpCap単体で、リアルタイムでスタックして細部出し、さらにはカラー化からプロミネンスの炙り出しまでできるので、撮影さえしてしまえば、あとは動画化するだけになります。


上記記事にSharpCapでの太陽全景撮影のための設定は説明していますが、実際の長時間タイムラプス映像はまだ試せていませんでした。なので今回の記事はその続編ということにもなります。



実際の撮影です。全景撮影で太陽の細かいところまでは見えないためシーイングはあまり関係ないので、午後からの撮影としました。シーイングがいい午前の撮影については、C8で高解像度のテストとしましたが、これについてはまた後日記事にします。

20秒に1枚で、トータル2時間25分の撮影で、数えたら422枚の大量の画像です。枚数は多いですが、ファイル量としてはトータルで高々10GB程度です。同じカメラで動画撮影する200フレームのserファイル換算だと、たった3本分程度です。ちなみに動画の場合は100本レベルで撮影したりしています。しかも処理ずみの画像が保存されるので、それ以上の画像処理も必要なく、心理的にもかなり気楽です。

撮影中はPHD2でのガイドと、SharpCapでのセンタリングを併用しています。SharpCapでの設定内容は以下のようにしました。

以前に示した設定よりも少し凝った設定になっていますが、これでほぼ完全にセンターに保つことができました。後々の位置合わせは全く必要なく、全コマに渡り、見ている限りピッタリ位置が揃っていました。これはすごい。

ただし、このことは快晴だったからというのが大きいと思います。これまで雲がある時にタイムラプス用の連続撮影を試していますが、小さな雲の通過でも影響が大きく、長時間撮影では途中で位置がずれてしまったり、スタックがうまくいかなくなったり、プロミネンスの炙り出しがうまくいかなかったりしていました。なので、このSharpCap単体でのタイムラプス映像のための撮影は（あまり設定にかかわらず
）、本当に雲がないという意味での快晴の時でないと、うまくいかないと思います。



繰り返しにもなりますが、今回のやり方の利点をまとめておきます。

• リアルタイムで、スタック、細部出し、カラー化、プロミネンス炙り出しなど、それ以上の画像処理が必要ないレベルで、画像を保存していくことができる。
• トータルファイルサイズを節約できる。
• 各画像の位置合わせの必要が、全くない。
• あとは、動画化するだけ。

なので、ホントに保存された画像をそのままアニメ化します。今回はPixInsihgtのblinkで動画化しました。blink上でtifから一旦pngにして、mp4で書き出しています。その後、ブログに載せるために以下のコマンドでYoutubeに適したフォーマットにしています。

 ffmpeg -i .\Blink.mp4 -vf "scale=1920:1400" -vcodec libx264 -pix_fmt yuv420p -strict -2 -acodec aac .\Blink_X.mp4

実際に出来たタイムラプス映像です。

見てもらってもわかりますが、はっきり言って全然面白くないんですよね。理由はひとえに動きが少なすぎるからです。でも実際には一部動いていて、たとえば左の大きなプロミネンス部分を拡大してみると以下のようになります。

たしかに動いていはいるのですが、いつものC8のタイムラプス映像と比べると、まあ当然ですが解像度不足なのは否めません。また、拡大して見るレベルだと太陽表面とプロミネンスの境がさすがに不自然です。

全景動画をよく見てみると、まだ他にも動いているところはありますが、上の動画よりはるかに小さな動きでしかありません。

結局、実際に長時間撮影したものをタイムラプス化して面白かったことは、2時間半で太陽の自転がわかったことでしょうか。これはタイムラプスというよりは、最初と最後の画像を比べればいいでしょう。

赤道付近の自転の周期が25日程度というので、半回転180度として、それをざっくり12日で回転するとしたら、1日あたり15度、2時間半だと1.5度程度回転するはずです。高々2時間半でこれくらいわかるので、夏場の朝から晩まで、1時間おきくらいに撮影して12時間くらいの自転を見るのも楽しいかもしれません。



さて、今回長時間撮影してわかった問題点もあります。今後の改善のために列挙しておきます。

• SharpCapで保存されたtif画像が、階調8ビットで保存されてしまっています。SharpCapのタイムラプスの設定画面の下の方に、画面のストレッチをしたら8bitで保存されると書いてあるので、逆に言うとストレッチしていなければ16bitで保存されるはずなのかと思います。実際、以前PhoenixとASI290MMで撮影した過去画像を調べたらきちんと16bitで保存されていたので、何か方法があるはずです。でも8bitで保存されたとしても、すでにプロミネンスまで炙り出し済みなら、階調は問題でないのかと思います。
• 黒点やダークフィラメントなど、何か構造が見えるところだけボケてしまっていて、アニメ化するとブレてしまっています。SharpCapから保存されてtifファイルの時点でもうボケが見えているので、スタックの問題か、変なノイズ処理が入っているからとかかと思うのですが、今の所不明です。今回はアニメ化してからこのことに気づきました。次回からは画像をとにかく1枚保存して、きちんと撮れているか確認しようと思います。ちなみに、このボケのため、太陽表面が動いているように見えるものはほとんどフェイクです。
• 太陽表面の模様があまり出ていない気がします。シーイングがものすごく悪かったのか、設定が悪かったのか、今となっては確認できません。短時間でいいので、serファイルを別途撮影しておけばよかったです。
• やはり全景では変化がなさすぎてつまらないです。拡大してみるとプロミネンスの変化などがわかるので、拡大を前提に楽しむべきか、それでも拡大するとすぐに分解能の限界でアラが見えるので、どこまで拡大するかのバランスが大事なのかと思います。
• プロミネンスの境が不自然に見えます。リアルタイム処理なので仕方ないのかもしれません。
• プロミネンスの境がブレるようです。アニメ化すると目立ちます。

色々問題点もありますが、それでもこれだけ簡単にタイムラプス映像ができるのは、魅力なのかと思います。



やっとSharpCapのリアルタイムスタックを利用して長時間のタイムラプス映像まで辿り着きましたが、あまり面白くもないので、これを今後継続するかはちょっと迷っています。ただ、問題点はまだあることはわかったので、もう少しはマシになるはずです。これらの問題点をある程度解決してから判断しようかと思います。

タグ ：

#太陽

#タイムラプス

#全景

#分解能

#SharpCap

#リアルタイムスタック

#プロミネンス