ほしぞloveログ

天体観測始めました。

タグ:全景

前回示したように、画像の一部でドップラーシフトの連続変化が見えるなら、頑張れば画像全体でも見えるはずです。


今回は、全画面でのドップラーシフトをアニメ化する方法を探ってみたいと思います。いい機会なので、JSol'Exの強力なスクリプト言語のImage Mathを使ってみようと思います。


1. 自動画像生成+マニュアルでアニメ化

まずは連続波長ずれ画像(静止画)を出力する一番簡単な方法です。

とりあえず、JSol'Exでserファイルを開いて、「Custum prosess」を選んで「Mode」を「Simple」にして、下の「Select all」ボタンを押し、右上の数字が並んでいるところに「-10;-9;-8;-7;-6;-5;-4;-3;-2;-1;0;1;2;3;4;5;6;7;8;9;10」などと入れてやって、-10pixelから+10pixlelまでシフトした画像を生成してくれます。
redshift_cut

autostrerchフォルダなどに出力された21枚の画像を、適当なツールを使ってアニメ化するというのが、まずは一つ目の簡単な方法になります。例えば、PixInsightのBlinkで動画化することができます。

実際に作って見ました。ブログに載せるために縮小してgif化してますが、これだけでも迫力があります。
Blink_10_blog

一旦はこれで作ったのですが、でもまだまだ不満が残ります。


Image Math

まず、どれだけ波長がシフトしているかの数字を画面内に入れたいのですが、なかなかいいツールが見つかりません。高々20枚ほどなのでPhotoshopなどでマニュアルで入れるのでも構いませんが、JSol'ExのImageMath機能を使うと、さらに細かいことが色々できるみたいです。せっかくなので、ここで使い方を一通り把握しておきたいと思います。

まず、マニュアルや解説に相当するページですが、以下の4つくらいでしょうか。

https://melix.github.io/astro4j/3.3.1/en/jsolex.html
https://melix.github.io/astro4j/3.3.1/en/imagemath.html
https://youtu.be/l6tb-UFC6Zs?si=oyHAQhvETiXK3iJe
https://youtu.be/8XKzFcmvqfI?si=GXIArv_YOCPATGgI

上の2つはバージョンごとにページがあるので、今使っているバージョンのものを見るといいでしょう。アドレス内の数値を自分のバージョンに合わせてください。いっそのこと最新バージョンの3.3.1を落とすのもいいでしょう。このJSol'Exですが、まだ開発絶頂期の範囲なのか、バージョンアップの頻度がものすごいです。私が使い始めたわずか2週間の間に、3.2.1から3.2.2、3.3.0、3.3.1と、3回もアップデートしています。

下の2つは動画ですが、1つ目は基礎からImageMathまでわかりやすく英語で解説してくれています。え?日本語でないからわかりにくい?いやいや、2つ目の動画はImageMath専用の解説ですが、フランス語です。私は大学でフランス語を選択してましたが、今では全くわかりません。作者が解説してくれているJSol’Ex関連のビデオは結構たくさんあります。

https://melix.github.io/blog/jsolex.html

でも見てみるとわかりますが、21本中英語版はわずか3本、他は全部フランス語です。なので英語にしてくれているものは大きな情報源になり、かなり助かります。でもフランス語でも画面を見ているとわかるところもあり、特にImageMathについてはソースコードを見るとわかることも多いので、多少は役に立つと思います。というか、他の方のものなども散々探しましたが、どうもこれくらいしか解説はないようです。


Image Mathを使ってみる

実際にImageMathを触るときは、まずはサンプルコードを見るといいでしょう。JSol'Exのメニューの「Tools」から「Image Math editor」を選びます。出てきた画面で「Sample scripts」を押すと、いくつかの例が出てきます。

IM_card

この中で一番わかりやすいのは「Technical card」でしょうか。Full modeで緯度とか経度が書き込まれるcardという画像が出ていますが、それと同じ画像を作るスクリプトです。中身はこんな感じです。

#
# Generates a technical card similar to the built-in one
#

[params]
gamma=1.5
cropFactor=1.2

[tmp]
contrast=sharpen(auto_contrast(img(0);gamma))
cropped=autocrop2(contrast;cropFactor)
globe=draw_globe(cropped)

[outputs]
techcard=draw_solar_params(draw_obs_details(globe))

まずはこのスクリプトを、そのままSaveボタンを押して適当な名前をつけてどこかに保存してみてください。

次にserファイルを開いて、「Custum process」に進んで、出てきた画面の右上の「Mode」を「ImageMath」にします。右横の「Open ImageMath」ボタンを押してエディタを開き、「Load」ボタンを押して先ほど保存したファイルを開きます。

もし先ほどのスクリプトを保存していない場合は、ここであらためて「Technical card」を選択してもいいですが、SaveしてLoadせずに進めると何も読み込まれない状態になってImageMathの処理がされないので注意です。それから、ここで開いたサンプルファイル一覧では、「Tools」から「Image Math editor」から開いた場合で見たサンプルファイル一覧に出てくるものより少ないものしか出てこないので、これも注意です。なので、サンプルファイルは基本的にはメニューの「Tools」から辿って開くようにした方がいいいです。

Image Math editorの「Ok」ボタンを押し元の画面に戻って、「Unselect all」を押します。これでImage Mathの処理のみが行われるので時間の節約になります。JSol'Ex上に処理された緯度経度情報が入った画面が表示されると思います。その後のスクリプトの改造ですが、この画面の右下にImageMath scriptという場所があって、そこに先ほどのソースコードの内容が表示されていると思います。ここをいじっていきます。

手始めに、このモノクロのcard画像をカラー化してみましょう。

まず[param]、[tmp]、[output]の3つのパートに分かれているのがわかります。[param]は変数 (数値) の定義、[tmp]は内部的な画像処理で、[outputs]で指定されたもののみが実際の画像として出力保存されます。

改造のための情報を得るために、関数リファレンスページでコントロールキーとFキーを押すなどして「color」などとページ内検索します。どんなコマンドを使えばいいかはこの関数リファレンスページの関数一覧を一通り読むか、他のサンプルファイルを読み込んでみるといいでしょう。検索すると「COLORIZE」という関数が出てきます。使用例には

colorize(img: img(0), profile: "H-alpha")
colorize(range(-1, 1), "Calcium (K)")

などと書かれていますが、これを参考にします。例えば今処理しているcardスクリプトでは[tmp]の最後にglobeという画像が出来上がっているので、同じ[tmp]のところに

colorized=colorize(globe;"H-alpha")

という1行を追加して、colorizedという変数に画像を入れてみましょう。上の使用例と結構違っているので注意が必要です。それぞれの引数の間は「, (カンマ)」ではなくて、「; (セミコロン)」が標準みたいです。カンマでもいいみたいなのですが、サンプルコードでは全てセミコロンになっているので、私もセミコロンで統一することにしました。あと、引数のところの「img」とか「profile」は入れても入れなくてもいいみたいですが、入れるなら全て入れて、入れないなら全て入れないようにしないとダメみたいです。他のサンプルコードを見ると、入れない方が標準みたいです。

あとは、[output]の中の1行を

techcard=draw_solar_params(draw_obs_details(colorized))

のように書き換えて、先ほど作ったcolorizedを引き継ぎます。これでもう一度JSol'Ex画面右下のImage Math Scriptの「Run」ボタンを押して走らせるとカラー化された緯度軽度情報が入った画像が出来上がる位はずです。ただし、ここで書き換えたスクリプトはあらわにセーブしないと、再度立ち上げた時には元のモノクロの状態のスクリプトしか残ってないので、気をつけてください。

ちなみに、ここで出来たカラー画像ですが、フルモードなどで自動で作ったカラー画像とは色使いが違います。自動処理の方のカラー化はもう少し凝ったことをしているようです。


2. Image Mathで全画面ドップラーシフトをアニメ化

ここまででImage Mathの使い方のきっかけくらいは掴めたのかと思います。次は目的の全景のドップラーシフトアニメーションを作ってみましょう。といっても、これもサンプルファイルがあります。同様にImage Math editorで見えるサンプルリストの中から「Continuum animation」を選びます。以下のような内容です。

#
# Creates an animation of the continuum
#

[params]
# the animation will be created with images from [-shift;+shift]
shift=5
# autocrop factor
cropFactor=1.1
# contrast adjustment
gamma=1.2
# interpolation steps
steps=5
# delay between frames
delay=20

[tmp]
continuum=transition(range(-shift,shift);steps)
cropped=autocrop2(continuum;cropFactor)
contrast_adjusted=auto_contrast(cropped;gamma)

[outputs]
continuum_anim = anim(contrast_adjusted;delay)

このコードをそのまま使ってもいいのですが、前回のアニメであったような波長などの書き込みはありません。ここでは練習として、動画の各画像にテキストで波長を書き込んでみましょう。

使うコマンドはdraw_textです。[tmp]の最後に1行

text_added=draw_text(contrast_adjusted; 200; 2900; "Shift from Hα: %SHIFT%Å", 72; "FFFFFF")

を付け加えます。200とか2900は位置なので、自分の画像の大きさに合わせて適当に数字を変えてください。%SHIFT%はリファレンスマニュアルのdraw_textのところに書いてありますが、あらかじめ予約されている変数で、単位がÅに換算されたそれぞれの画像の波長のずれを表します。72はフォントの大きさです。こちらも適当に変えてください。FFFFFFは色で、RGBを各2バイトで表していて、この場合はRもGもBも255で一番明るくしてあるので白色になります。

[outputs]内では、最後の行を以下のようにtext_added変数を引き継いだ形に変更します。

continuum_anim = anim(text_added;delay)

基本的にはこれで走るはずですが、[params]内にある数値に少し触れておきます。
  • まず、shiftですが、これは[tmp]内のrange関数の引数に使われます。単位はピクセルなので、serファイルのHαの中心線から上下5ピクセルを処理します。ここは10くらいにしておくと楽しいでしょう。
  • stepですが、transition関数引数で使われていて、1ピクセルと1ピクセルの間を何枚補完するかになります。5の場合はかなり滑らかになります。ただし、先ほど表示したテキストの波長は間が補完されず、元画像の飛び飛びの波長しか出せないみたいなので、私はここは1にしました。
  • 最後delayですが、[output]のanim関数の引数で使われていて、フレームとフレームの間の時間で、単位はmsです。これはshiftとstepの数に合わせて調整しますが、私は1波長1枚としたので、ここでは200としました。

出来たスクリプトは以下のようになります。

#
# Creates an animation of the continuum
#

[params]
# the animation will be created with images from [-shift;+shift]
shift=10
# autocrop factor
cropFactor=1.1
# contrast adjustment
gamma=1.2
# interpolation steps
steps=1
# delay between frames
delay=200

[tmp]
continuum=transition(range(-shift,shift);steps)
cropped=autocrop2(continuum;cropFactor)
contrast_adjusted=auto_contrast(cropped;gamma)
text_added=draw_text(contrast_adjusted; 200; 2900; "Shift from Hα: %SHIFT%Å", 72; "FFFFFF")

[outputs]
continuum_anim = anim(text_added;delay)

走らせた結果ですが、以下のようになります。ブログにアップロードできるように、元々出力された3040x3040のmp4ファイルを600x600のgifに落としています。無事に数値が入って、わかりやすくなりました。

step

これでももう結構十分で、ここでフルサイズの画像をアップしてもいいのですが、追加でもう一つ手法を紹介します。


3. もっと簡単な全画面ドップラーシフトのアニメ化の方法

Image Mathをある程度見てみて、上の動画まで完成させた後に、もっとはるかに簡単に全景画像を作る方法があることを知りました。悔しいですが、紹介しておきます。

処理したいserファイルを、Quick modeで一度処理します。出てきた画像の上で、コントロールキーを押しながら左クリックで処理したい部分を選択します。そして右クリックして「Create animation or panel」を選択します。

anime_select

すると次のような設定画面が出るので適当に設定して「Generate」ボタンを押します。
anime_setting

時間がかかりますが、処理が終わると以下のような画像と動画ができます。
07_13_53-trimmed_0000_07_13_53-trimmed_custom-panel_cut

out

上の動画はブログ用に縮小しています。フルサイズの動画はここにおいておきました。どうもショート動画になってしまうようですが、かなりの解像度なのでぜひ全画面化や、さらに拡大して見てみてください。

この領域選択はどこでもできます。最初からこんな大きな全景範囲で処理すると大変なので、まずは小さなサイズで試してみるといいと思います。例えばプロミネンスなどです。

out

この便利な機能、マニュアルにも記述がないみたいです。


まとめ

今回は3通りの全画面の連続波長ずらしのアニメ化の方法を示しました。本当は2つ目までだったのですが、一旦2つ目までの記事をほとんど書き終えてから3つ目の画像の一部選択の方法があることを知りました。まさか全画面ではできないかと思っていたら、あまりに簡単にできてしまったので、悔しかったですが紹介することにしました。でもまあ、Image Mathの使い方がわかったからよしとしましょう。

次の記事はこのドップラーシフトの全景画像を使って、色々議論したいと思っています。


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


SharpCapでのリアルタイム処理

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


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


撮影設定など

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

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

撮影中はPHD2でのガイドと、SharpCapでのセンタリングを併用しています。SharpCapでの設定内容は以下のようにしました。
スクリーンショット 2025-06-05 150152_cut

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

ただし、このことは快晴だったからというのが大きいと思います。これまで雲がある時にタイムラプス用の連続撮影を試していますが、小さな雲の通過でも影響が大きく、長時間撮影では途中で位置がずれてしまったり、スタックがうまくいかなくなったり、プロミネンスの炙り出しがうまくいかなかったりしていました。なので、この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時間半で太陽の自転がわかったことでしょうか。これはタイムラプスというよりは、最初と最後の画像を比べればいいでしょう。
Blink3

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







2025年5月18日の日曜日、前日の土曜の天気が悪くて悶々としていたところ、この日は朝から太陽が出ていて、6時頃には起きて早速太陽撮影の準備です。でも肝心の天気はというと、結構雲もあり、晴れ間を見つけて撮影とかになりそうでした。


エタロンの調整


IMG_1372

この日、最初にやりたかったことは、C8でのエタロンの調整です。ここ一か月くらい色々試していて、なかなか結果が出ていないのですが、この日新カメラのG3M678Mを使ったことで、少し進展がありました。ただし、まだ調整の余地がありそうなので、もう少し続けようと思っています。

エタロン調整はまだ結論まで出ていないので、もう少しまとまったら、また別途記事にします。


黒点周りをより広角で

朝の早い時間を利用したかったので、エタロン調整の成果を試すべく、すぐに撮影に入ります。まずは黒点周りです。

1ショットあたり200フレームで、いいシーイングを逃したくなかったので30秒に1回、トータル30分で合計60ショットとしました。30分の短時間にしたもう一つの理由がファイルサイズです。カメラをこれまでのASI290MMかG3M678Mに変えたので、前回計算したとおりピクセル数は約4倍になるため、ファイルサイズも単純に4倍くらいになります。ディスク喰いなので、長時間撮影を何度もできないということに気づきました。

撮影後、全60ショットを仮処理して、細部出しまでしてから改めて分かったのですが、この日は相当シーイングが良かったです。以前のかなりシーイングがいい日と思った日の、1-6までランク付けしたときの基準に合わせてみると、悪い方のランク6と5は皆無、4もほぼないと言っていいでしょうか、全部3以上で、ランク1の枚数が多かったです。ただし晴れ間は続かなくて、撮影したうちの3分の1程度はほぼ真っ暗で捨てることになりました。多少暗くなっているだけのものは残しています。そのうち、ランク1の中で、実際そこまで差はないのですが、一番いいと思われる時間帯の、ほぼ連続した4ショットを処理しました。モノクロ、カラー、カラー反転版を載せておきます。

07_51_59_pipp_lapl3_ap15534_IP

07_51_59_pipp_lapl3_ap15534_IP_color_s

07_51_59_pipp_lapl3_ap15534_IP_color_inv._mod_sjpg
  • 撮影場所: 富山県富山市
  • 撮影時間: 2025年5月18日7時51分
  • 鏡筒: Celestron C8 口径203mm、焦点距離2032mm
  • エタロン: Coronado P.S.T.
  • 赤道儀: Celestron CGEM II
  • カメラ: Touptek G2M678M
  • 撮影ソフト: SharpCap 4.1 (64bit)
  • 画像処理: AS!4にてスタック、ImPPGで細部出し、PixInsightでカラー化など、PhotoshopCCで仕上げ

まず、カメラをこれまでのASI290MMかG3M678Mに変えたので、画角が縦横ともに1.5倍くらい、面積では2倍以上増えています。それでも良像範囲が増えているのは、エタロン調整の効果です。しかも揺れも少なく安定していたせいか、四隅を含めてほぼ全面にわたって使える画像になっています。今回はクロップを何もしていないので、ずれたところも含めて表示していますが、細い枠程度でほとんど影響がないくらいの範囲で収まっているのがわかります。

ピクセルサイズが小さくなったせいなのかわかりませんが、ASI290MMの時に比べて明らかにノイジーになっています。もしかしたら、ImPPGが細かすぎる画像が苦手なことがあるので、その生の可能性もあるかもしれません。ここら辺はもう少し経験を積む必要があるでしょう。

あと、黒点の右側など、まだピントが合っていない部分が変な形であるように見えます。エタロンのせいなのか、C8やカメラのせいなのか、なぜかはまだ謎で、ここら辺をもう少し突き詰めていきたいと思っています。


プロミネンス

次はプロミネンスです。大きなものがいくつか出ていましたが、午後4時半方向の南西に出ているものが大きかったので、それがカメラの長辺になるようにカメラを回転して撮影しました。プロミネンスを撮影したカメラもG3M678Mなので、これまでより広い範囲で撮影ができています。

黒点撮影の時より、さらにシーイングが安定だったみたいで、ほぼ全ての画像でかなりの解像度が出ていました。どれが一番いい画像が選ぶのが難しくて、いっそのことタイムラプスにしてしまおうと、少し処理を進めました。

本当は1時間撮影する予定でしたが、途中で雲が出てしまい、結局連続で使えた部分は午前8時19分から8時46分までのわずか26分間でした。その26分の間も多少雲が通過して少し暗くなってしまったショットもありました。明るさ調整は多少できますし、暗い時に出るノイズもタイムラプスで動画にしてしまうと目立ちにくいので、それでとれる最大の26分を使いました。そうは言っても高々26分の52コマなので、タイムラプスとしては短くて全然期待していなかったのですが、ある程度拡大しているからなのでしょうか、連続で見ると結構動いているのがわかります。

output-palette2

上の動画は、ブログ上で動くのが見やすいようにgifファイルにしていますが、サイズがかなり制限されてしまいます。HDMIサイズにした動画はYoutubeに挙げておきましたので、よかったらご覧ください。

今回はシーイングが相当良かったので、1枚1枚の画像処理をかなり抑えています。多少ノイジーなところは残っていますが、細かい様子も十分残っていて、短時間ながら迫力ある映像になったのではないかと思います。

これだけの良好なシーイングだったので、もしずっと晴れていたらと思うと、とても惜しかったです。


全景

IMG_1377
もうかなり雲が出てきています。この後、全面を覆うようになっていきます。

最後は太陽全景です。この頃には一つ一つの雲が大きくなってきていて、鏡筒を変えて導入するときも、ピントを合わせるときも、一瞬太陽が出たところで素早く合わせていました。時間がたつほど全面が雲に覆われてきて、撮影時はかなり待ちながら本当に一瞬で出たところを何ショットか狙いました。何度かの途中で雲が通る程度での撮影したあと、9時46分に、やっと全く雲が通らない1ショットが撮れて撤収としました。

画像処理はこれまで通りで、こちらもモノクロ、カラー化、反転バージョンを作ってみました。

09_46_31_lapl3_ap2937_out_mono

09_46_31_lapl3_ap2937_out_color

09_46_31_lapl3_ap2937_out_color_inv

PSTでここまで撮れるならかなり満足です。解像度もピクセルサイズが2μmと小さいので、拡大して見てもある程度耐えうるくらいに、十分に出ています。今回の撮影では分解能を出すために、エタロン位置を、8cmの口径が効くように、かなり後ろにしています。後ろにする理由は前回記事をご覧ください。


その後の処理

撮影後は完全に曇ってしまって時間ができたので、画像処理に移りました。

簡単そうなので先に処理を始めた全景は、その日のうちに済んでXに投稿したのですが、C8で撮影した黒点周りとプロミネンスは新カメラということもあり、思ったより時間がかかってしまいました。天気がイマイチで雲が結構な頻度で通り、少し暗くなった画像をどうするか迷ったのと、画角が広くなった分のエタロンの調整がまだ不十分で、どこまで採用するかを迷ってしまったからです。特に、プロミネンスは静止画にするかタイムラプス化するか迷いました。タイムラプスの処理過程は静止画より遥かに複雑で、前にやったものを思い出しながら、しかもカメラが違うのでパラメータも違い、思ったより時間がかかってしまいました。


まとめ

処理した画像は、まだ一部の個所に不満はありますが、全体としてはそこそこ満足です。これはシーイングがかなり良かったのが主な理由です。このクラスのシーイングで、天気が良く、別の大容量外部ディスクなども用意して、思う存分撮影し、処理もルーチン化して慣れた状態で短時間でできるなら、もう夢のようですね。エタロンの調整は、まだ余地があるならもう少し続けたいと思います。







今週末は天気があまり良くないので、先週撮影した画像の検証をしてみます。


カメラセンサーの違い

前々回、口径8cmの鏡筒+PSTにTouptekのG3M678Mを使って太陽全景を撮影した記事を書きました。これまではASI290MMだったのですが、これに比べるとセンサーが1/3インチから1/1.8インチになったので、一辺で1.5倍長くなりより広角で撮影できるようになったこと。さらにピクセルサイズが2.9μmから2.0μmに小さくなったので、こちらも1.5倍くらい分解能が良くなったことが利点です。

SharpCapで全景をリアルタイムスタック撮影し、PNGに直接落とした画像は前々回掲載したのですが、同時に動画のserファイルでASI290MMでもG3M678Mでも撮影しておいたので、それらの動画ファイルからマニュアルでフル処理をして、どこまで細部が出るのか試してみました。

露光時間はASI290MMが1msで、G3M678Mが0.5msです。ピクセルサイズはG3M678Mの方が小さいのですが、画面での明るさはG3M678Mの方が上でした。ゲインはASI290MMは100(= 10dB = ~3倍)として、G3M678Mの方の設定が最初わからなかったので400として大体画面の明るさが一致しました。ZWOの場合だとgain = 400は40dBという意味で、100倍になります。でもG3M678Mの400はどう見てもそこまで明るくなく、後で分かったことですが、これはデジタル一眼レフカメラのISOと全く同じだと理解しました。すなわち、100はISO100でgain=1、400はISO400と同じでgain=4というわけです。SharpCapでカーソルを近づけると、なんと値が何倍まで含めて直接表示されるように進化していました。こう考えてもG3M678Mはかなり明るいカメラということがわかりますが、これは単にconversion factor [e/ADU]が小さいのかと思います。

その他の条件はほぼ同じにしてあります。それぞれ500フレームをserフォーマットで撮影して、そのうちAS!4で上位50%をスタックした後、ImPPGで同じパラメータで細部出しをしています。この状態で拡大して二つのカメラの比較してみます。左がASI290MMで右がG3M678Mです。

スクリーンショット 2025-05-08 2128402_cut

この比較は面白いです。前々回の記事でも示したのですが、口径からくる分解能の制限のほうが厳しいために、センサーのピクセルサイズはあまり効いてこないはずです。なので本質的な分解能はあまり変わりません。でも拡大しているのでピクセルの大きさ自体はすでに見えるくらいになっていて、オーバーサンプリング状態だとしてもピクセルサイズの影響は多少なりともあるようで、やはり右の新カメラの方が分解能がいい印象です。その一方、ピクセルサイズが小さいということは1ピクセルあたりの光子数は少なくなり、トータル露光時間も半分なので、ノイズ的には不利になるはずです。拡大して比べるとわかりますが、ピクセルごとの輝度のバラつき(=ノイズ)は左の方が多く見えます。もう一つの不安要素が、ピントを明るい中で合わせているのでどこまで正確かいまいち自信がないです。ピントが合っているとするなら、そこそこ理屈に近いような画像の比較になっているのかと思います。

カメラを触っていて、もう一つ新カメラが不利なところがあるのに気づきました。フレームレートが出ないのです。ASI290MMは60-70fpsくらいは出ていましたが、G3M678Mの場合は23fps程度でした。ROIで画面を小さくしてもフレームレートは変化がなかったです。もしかしたらこの低フレームレートは撮影によっては将来決定的に不利になるかもしれません。


全体画像

G3M678Mで撮影した画像を、その後PixInsightのSolarToolboxでカラー化し、最後Photoshopに渡して仕上げました。モノクロとカラーと反転バージョンを載せておきます。

15_06_36_lapl2_ap18975_IP2_mono_cut

15_06_36_lapl2_ap18975_IP2_color_cut

15_06_36_lapl2_ap18975_IP2_color_inv_cut

リムの内側の表面外周部の模様がそこまで出ていないのが少し不満なくらいでしょうか。 最周部と中央の間に少し段差があるように見えるのが不思議です。そもそもPSTエタロンなので、最近のPhoenixとかの0.5Åクラスのエタロンには勝てないですが、それでも十分楽しめるくらいにはなっているかと思います。


SharpCapとの比較

先週SharpCapで見えた全景をPNGに落としたものを前々回の記事でも示しましたが、それと今回のserファイルからマニュアルで画像処理したものを比較してみます。左がSharpCap、右がマニュアル処理です。

スクリーンショット 2025-05-10 135439_cut

思ったより違いがあります。SharpCapの方ももう少し見栄えを良くすることができるのかもしれません。まだまだテスト段階なので、今後もっと詰めていこうと思います。


まとめと今後

と、上のところまで書き終えて週末を迎えて、次の週(今週末)に再度カメラを立ち上げたときに、なんと上の撮影を全て8bitで撮影していたことに気づきました。SharpCapの比較で差が出たのは、ビット数が関係しているのかもしれません。

やっぱりまだ触り始めなので、見逃していることがあります。ちなみに、ゲインがISOだったことも今週気づきいたことです。







前回の記事で4月12日にシーイングの持続時間を評価してみましたが、もう一つ試したことが太陽の全景撮影です。


4月5日の挑戦

全景撮影に関しては、前週の4月5日にも口径102mm 焦点距離1000mmの国際光器のMAGELLAN 102で試しています。面積の広いフォーサーズを使い、一応全景を入れて撮影はできました。でもPST的には、BFの5mmという径も、エタロンの良透過波長エリア的にも、プロミネンスがほとんど出ていなかったことからも、限界を超えていると言っていいでしょう。


問題点は焦点距離が長すぎるために、太陽の径が大きくなりすぎてしまい、BFで蹴られることでした。これはBFのマウントの穴径を広げることで、ある程度回避しました。もう一つは、エタロンの良像範囲がリング状に変化していき、Hαに一致する範囲に制限があることです。焦点距離1000mmでの太陽径では、この波長が合う面積内に全体を入れることが難しかったということです。

いずれにせよ、焦点距離が問題なので、鏡筒を変更する必要があります。レデューサーは像が決まった後に入れるものなので、今回は使えないでしょう。


口径8cm、焦点距離400mmで挑戦

とにかく全景に関しては、焦点距離1000mmではこれ以上解がなさそうなので、焦点距離の短い鏡筒を考えます。

また、カメラもフォーサーズのASI294MM Proはそもそも冷却も使う必要がないのでちょっと勿体無いです。しかも、冷却をしないとしても12V電源を別途繋がなければ使えないので、余分なケーブルが必要となり取り回し的にも面倒です。元々は、高分解能目的でbin1のピクセルサイズ2.3μmを狙っていたのですが、bin1だと(いまだに理由はわからないのですが) 4x4のピクセルパターンがどうしても出てしまうので、bin2での撮影にせざるを得ないということがわかりました。このことは、Phoenixで試したときもそうでしたし、4月5日に試したときもそうだったので、今のところ少なくとも太陽にASI294MM Proのbin1を使うことはできないという結論です。DSOにどこまで影響があるのかは、今のところ気付いたことはないのでよくわかっていません。

というわけで、カメラはモノクロでピクセルサイズが小さいものという観点から、とりあえず手持ちのASI290MMで入る範囲ということにしました。センサーサイズは1/3''とかなり小さいので、全景を入れようとしたら、計算上は焦点距離は400mmよりもかなり短くなってしまいます。実際、焦点距離400mmのPhoenixでもASI290MMだと全景は一度に入りませんでした。ただ、400mm以下だと分解能がかなり悪くなってくるので、とりあえず今回は焦点距離400mmにASI290MMで2枚のモザイクというので妥協します。今後センサーサイズの大きいカメラを使うことを検討しているので、そのうち1枚で写せるようになるかと思います。

さて口径です。順当に行くとPSTの鏡筒がちょうど焦点距離400mmなのでそれでもいいのですが、以前手持ちの口径8cmで焦点距離400mmのiOptronの安価な鏡筒を太陽で試して、口径4cmのPSTよりも分解能がよくなったので、今回も同じことをやってみます。


適当にレールを組み合わせ、PSTを無理やりっぽいですが、何とか鏡筒に取り付けます。でも全然ピントが出ません。上の記事を改めて見て写真を確認してみると、PSTをかなり鏡筒内部に入れ込むような状態で取り付けています。同じような距離になるくらいに組み直してみると、やっとピントが出ました。やっぱり記録のための写真は撮っておくものですね。

IMG_1169
今回、PSTをこれくらい鏡筒の中に入れ込みました。


太陽全景画像

その状態でそれぞれ1000フレーム撮って上位75%をスタックしたもの2枚をモザイク合成したものになります。細部出しはImPPG、カラー化にはSolar Toolboxを使いました。カラー化後にモザイク合成を、Photoshopを使って手作業でやりました。
16_22_23_lapl2_ap2102_cut

中心部の分解能と周辺部のHαの出方にまだ違いがあるので少し不満はありますが、口径10cm、焦点距離1000mmのMAZELLANで撮ったものよりも、はるかにHαの模様が出ています。全然出なかったプロミネンスも、少なくとも形が判断できるくらいには十分出ています。分解能も、モザイクで2枚に分けている効果もあり、同じASI290MMで1枚で撮ったものよりも出ています。

まあとりあえず全景撮影用として何とか使えると思うことにしますが、特にHαのコントラストでPhoenixには劣るので、いいエタロンが欲しくなります。

分解能は口径10cmの時よりもよくなっているので、10cmという口径は全景撮影には全然貢献していなくて、ほとんど意味がないことを示しています。カメラの解像度や、Hαの良像範囲のほうが聞いていたと言っていいでしょう。では、今回の口径8cmは分解能に貢献しているのでしょうか?同じ焦点距離で口径4cmと比較してみればわかるはずです。一応以前の結果では意味があったと結論づけているので、もし時間があれば今一度同じことをやってみてもいいかもしれません。


あれ?、F値は?

さて、ここで疑問になってくるのが、そもそも「PSTのエタロンはF10を仮定してあるはずのでは?」ということです。もう少し正確にいうと「エタロンのところで平行光になるようにエタロン手前にレンズ(調べた限り焦点距離200mmの凹レンズらしい)が入っていて、そのレンズがF10の光に対してエタロンに平行光を作り出すはずなのでは?」という意味です。

でも今回使った鏡筒は口径10cmで焦点距離400mmなので、F5です。今のレンズだと平行光にならないはずなのに、なんでこれでうまくエタロンが働くのでしょうか?

いくつかわからないことが出てきました。
  • 平行光を生み出す200mm凹レンズの位置に対する要求はあるのか?焦点より後ろにレンズを置いた場合は、光がさらに広がっていくのダメなことはすぐわかります。じゃあ焦点の前ならば、どこでも平行光になるのか?特に、焦点に近づくと変なことは起こらないのか?
  • エタロンは本当に平行光しか受け付けないのか?鏡の間の距離が短くてフィネスが10程度のオーダーなら平行光にこだわる必要はないのではないか?
  • そもそも、F値ってなんなのでしょう?今の口径8cm、焦点距離400mmの鏡筒の対物側に、直径4cmの穴を中心に空けたキャップをつけたらF10になるのでしょうか?
  • 口径を制限する穴は、カメラレンズで言う「絞り」と同等なんだと思いますが、絞りの位置はどこでもいいのでしょうか?エタロンの後に入れたら無意味なのはわかるのですが、例えばエタロンより前の対物側にだったらどこにつけてもいいのでしょうか?

ここら辺の疑問が、なぜPSTのエタロンは現状リング状に良像範囲が変わっていくのか?という疑問につながります。これまでは単純にモードが合っていなくてLaguerre-Gaussianモードが見えていると思っていたのですが、これだと上の疑問に全く答えられません。


まとめと今後

ちょっとトリッキーですが、何とか太陽全景をそこそこの分解能で写し出すことができました。でも、なんでF5鏡筒でPSTエタロンが問題ないのかがよくわかっていません。とにかく事実としては、特に平行光を注意して作らなくてもエタロンは少なくとも働いているように見えることから、もしかしたら全くの思い違いをしている可能性もあります。ちょっとまだ答えは出ていないので、もう少し考えて、今後色々試していこうと思います。




このページのトップヘ