ほしぞ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の使い方がわかったからよしとしましょう。

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


前回から始めたSHG700の応用編


第1回目は波長を大きくずらし太陽表面をさまざまな輝線で見てみました。今回はHα周りで波長をずらしたらどうなるかを見てみます。といっても、これもJSol’Exの標準機能なので、応用というにはまだ物足りないかもしれませんが、それでもこれまであまり見たことのないものかと思います。


ドップラーシフトを連続で見る

まず処理したいserファイルを改めて開きます。バッチモードでなく、単体のファイルを開きます。今回はフルモード、もしくはカスタムモードで全選択して処理を進めます。処理が済んだら、次に画面右の横向きになっているタブのうち「Doppler shift」を押すと次のような画面になります。

redshift_cut

「Box size」は見たい領域で、デフォルトが256x256ですが、出来上がり画像としてはちょっと狭いので512x512くらいがいいかと思います。

ここで選ぶレッドシフトのAからEの領域ですが、これは解析した画像の「redshift」フォルダの中に入っている画像を見ると、ドップラーシフトがあった場所に四角いマーカーが追加されていて、AからEくらいまでのアルファベットで区別されているのがわかります。
07_13_53-trimmed_0000_07_13_53-trimmed_redshift_0_00_brighter
全部選ぶとかなりの処理量になるので、今回は形が面白そうな真ん中近くのBを選んでみました。

ちなみに、最初全部選んで16GBメモリのWindows Surface8で処理したら、メモリ不足で止まってしまい最後まで辿り着けませんでした。そのため、Bを一つだけ選んで、しかもJSol‘ExのARM Mac版をダウンロードし、32GBのメモリを積んでいるM1 Macで処理することにしました。普段太陽用に使っているWindowsのSurface 8より、普通の処理でさえも相当速いことがわかったので、今後重い処理はMacの方が楽そうです。

「Pixex shift margin」は余分にどれだけ見るかみたいですが、とりあえずデフォルトの2でいいでしょう。あとは「Type」で静止画と動画の両方を選び、「Annotate animations」をチェックし数字を波長などの画像内に埋め込みます。「Use full range in panels」もオンでいいでしょう。オフだとプラス側だけの波長になりますが、オンにするとプラスとマイナス両側の波長が処理され、速度が正と負でどう画像に違いが出るかがよくわかります。これで画面下の「Generate」ボタンを押して処理を進めます。かなりの時間がかかるので放っておきましょう。

全部の処理が済むと、今回ずらした全ての波長をパネル城に並べた1枚の画像と、連続表示した動画ができます。静止画の中の各画像に数値が入っていますが、これがどれくらい波長をずらしたかと、それに対応した速度差になります。
07_13_53-trimmed_0000_07_13_53-trimmed_redshift-B

「Profile」タブで見ると、私の機材だとHα線周りでは0.091Å/pixelになることがわかっていて、 このことから1枚1枚が、1ピクセルずらした処理に相当していることがわかります。
スクリーンショット 2025-07-05 101928

同時に出力される動画はmp4形式です。ここではブログに載せやすいように、以下のようにffmpegでgif形式に変換しました。

ffmpeg -i sample_redshift-B.mp4 -filter_complex "[0:v] fps=10,scale=480:-1,split [a][b];[a] palettegen [p];[b][p] paletteuse" output.gif

動画はすごいですよ。

output-palette

波長がズレると見える模様と見えない模様があることがわかります。これは地球から見た時のHαからの速度ずれが起こっていて、ドップラーシフトを起こした結果だと考えているわけです。

ところでこの動画、どうやらその上で示した静止画の1枚1枚をそのまま繋げているだけではなくて、滑らかに見せるために、隣同士の画像の間の画像を補完して動画化しているようです。その証拠に、中心波長の次が0.02Åとかのあり得ないくらい細かい値になっています。近くの2枚の画像の比率を変えてブレンドしたりしているのかと推測します。中間的な波長は真の波長シフトとは違うかもしれませんが、波長の間をシフトさせて見たい時にはこの手法は使えるのかもしれません。


一つの疑問

ここで一つ疑問が湧きます。そもそも、例えばこのgifアニメに写っている、前半と後半で見え方かが変わってくる例えば真ん中の黒い模様は、元々はHαの波長のみで存在しているものなのでしょうか?それとも、Hαの吸収線で周りの波長からの光が暗くなるから、Hα吸収線の底の部分が見えてくるだけで、そこで見えているものは他の波長も暗くできるなら他の波長でも見えるものなのでしょうか?

もしこのドップラーシフト画像が正しいなら、元々はHα線を中心にHα線のみに存在する輝線で、その上や下の波長では見え方が違っていて、地球から見た速度に差があるからHαからズレた波長でも見えているということになります。

その一方、例えばプロミネンスはこれまでHα線のみで見えると思い込んでいましたが、CaKで見た時も同様の形が見えることを今回初めて知りました。Hαで見えてCaKでも見えるのなら、他の波長にも存在していると考えて不思議はなさそうです。そうするとドップラーシフトで見え方が変わるということと矛盾してしまう気がします。

暗線なのか輝線なのかという問題になるのかと思います。まだ自分の中で結論が出ていないので、今後もう少し検討したいと思います。


まとめ

ドップラーシフトがある領域を、波長をずらして見てみました。かなり面白いのですが、これでもJSol'Exの標準機能の一つにすぎません。さらにImage Mathと呼ばれるスクリプトを使うと、もっと色々なことができるようで、どんどん応用になっていきます。これらの件、今後もう少し突っ込んで進めてみたいと思います。

これまでSHG700を使った始動編として、基本的な太陽分光撮影の解説を、ハード面ソフト面に渡り記事にしてきました。今回からは徐々に応用編に入っていきます。と言ってもまだしばらくはJSol'Exの標準機能の範囲内の話です。でも、徐々にこれまであまり見ることがなかったものになってくると思います。

前回はSHG700始動編の(その5)でCaK線の撮影をしましたが、今回はもっと多波長で撮影してみました。


撮影途中で気付いたこともいろいろあるので、メモ代わりですが細かく書いておきます。


波長の選択

前回のCaKの分解能が悪かったので、まずはその再現性です。前回終了時の設定を何も変えずに、まずは1ショット撮影しておきました。その後、何が悪いのか見るために色々見てみると、輝線のピントがあった状態で、太陽光と背景の境目の縦線がボケボケでした。縦線は空間分解能に聞くはずなので、何か設定がおかしいようです。ちなみみ、撮影した動画ファイルからCaKの全景を再構築して見てみると、雲が通過していて全景を見るのが厳しかったですが、分解能は前回と変わらずやはりだめそうです。

CaKの分解能がダメそうだったので、次にHαに戻して分解能が回復するかを見ることにしました。その後、波長を順次短くしていっていくつかの代表的な波長を撮影し、再びCaKに再挑戦することにしてみました。

順序としては、
  1. Hα (6562.81Å)
  2. Na D1 (5889.95Å)
  3. Mg b1 (5183.62Å)
  4. Hβ (4861.34Å)
  5. Hγ (4340.47Å)
  6. CaK (3933.66Å)
としました。

この内、HγはJSol‘Exでの全景再構築時に選択肢として出てこないので、JSol‘Exのメニューの「Tools」から「Spectral ray editor」を選び、以下のように名前と波長を入れてやります。
スクリーンショット 2025-07-04 142837_cut
波長を入力するとそれに応じた色が勝手に付きます。でもこの色、ちょっと微妙で、出来上がる画像は設定通りになかなかならないことがわかりました。あとで画像と一緒に検討します。


ピント合わせの自由度

何度か波長を変えていくうちに、ピント合わせ方がある程度確立しました。前々回の記事でCaKに挑戦したときのピントは今思うと大幅にずれていたので、分解能が出なかったのも納得です。

まず自由度の数ですが、SHG700の部分に回折格子の回転 (固定ネジを緩めてラフに回転+マイクロメーターで微調整) と、レンズについているマイクロメーターが2つと、鏡筒のフォーカサーが1つで、合計4つあります。具体的に番号を振っておきます。
  1. 回折格子
  2. コリメーターレンズ
  3. カメラレンズ
  4. 鏡筒フォーカサー
調整を難しくしている一つの原因が、これらの自由度が独立ではなく、各自由度の調整が他の自由度に影響することです。ただし、順を追って調整することで、それぞれの位置が一意に決まることがわかってきたので、メモがわりに手法を書いておきます。ただし、今後もっといい方法が出てくるかもしれないので、とりあえず参考的な手順としてくらいです。また、この方法はSHG700で試しましたがSol'Exでも有効なはずで、また必要そうな精度も書いておいたので、どれくらい頑張って合わせれがいいかの目安にもなるかと思います。


波長を変えた時のピント合わせの具体的手順

A. まず最初に見たい波長を決め、回折格子の回転角度を決定します。
  1. 回折格子下部のネジを手で緩めて、回転台の切り欠き溝の真ん中を印刷されている目的の輝線にラフに合わせます。
  2. SharpCapの画面で見ながら、JSol‘ExのSpectrum browserで表示されるフランフォーファー線図と比較して、目的の波長の近くにいるか確認します。
  3. 似たような輝線模様が見つかったら、目的の輝線が画面の上下で真ん中になるように、回折格子についているマイクロメーターで合わせます。SharpCapで同心円と十字のレチクルを出しておくと合わせやすいでしょう。撮影時にはROIで上下100ピクセル内に輝線を入れる必要があり、そのために必要なマイクロメーターの精度は1-2目盛り程度になります。
付属のマイクロメーターは50目盛りが2回転すると1mm移動するので、1目盛りは10μmに相当します。回転角への変換係数がわからないので、角度の精度で議論はできないのですが、かなりの精度が必要なことがわかります。といっても、多少ずれていたとしても後からROIのTiltを変えてやることで、センサーのどこを見るかの位置調整ができるチャンスがあるので、ここではそこまで精度にこだわる必要はありません。ここで回折格子の回転角を決めたら、これ以上はもうこの自由度はこれ以上いじることはないです。というか、これ回折格子の回転角を以上いじってはいけません。もしいじると、また最初からやり直しです。

B. 次に、2のコリメーターレンズのマイクロメーターと、3のカメラレンズのマイクロメーターの2自由度を同時に動かします。
  1. SharpCapの画面を300%程度に拡大し、画面を右か左にスクロールさせて、太陽光が切れるところまで持っていき、ヒストグラムの一番右の線を左にかなり寄せて背景光の輝線が見えるようにします。
  2. 背景光で輝線がうまく出たら、さらに端に寄せて、スリットの境の光が見えるところと見えないところまで画面を持っていきます。ここで二段階目の調整をします。
  3. まずは3のカメラレンズのマイクロメーターを回して、画面の横向きの線のピントが合うようにします。
  4. 一旦横線のピントがあったら、次に2のコリメーターレンズのマイクロメーターを回して、縦の「光があるところとないところの境目」のピントを合わせます。
  5. ここを合わせると、3のカメラレンズのピントが少しズレるので、また3のカメラレンズのマイクロメーターを微調整します。この時に必要な精度は+/-2目盛りくらいです。かなりの精度が必要なことがわかります。
  6. 3を微調整したら、再び2のコリメーターレンズのマイクロメーターを微調整します。ここでの必要な精度は+/-7,8目盛りくらいでしょうか。こちらは多少大きく動かしてもいいでしょう。
  7. この2と3のマイクロメーターの調整を数回繰り返し、横の輝線と縦の光の境目の線の両方のピントが出るようにします。
うまく調整できると下の画面のようになるはずです。左の明るい部分が太陽の直接光で、真ん中の木線が見えている部分が背景光になります。

スクリーンショット 2025-07-04 092825
 
調整位置が決定したら、回折格子のマイクロメーターも含めて3つともこれ以上触ってはダメです。


C. 最後に、鏡筒のフォーカサーを調整します。
  1. ヒストグラムを調整するなどして、太陽の直接光の輝線が見えるようにします。
  2. フォーカサーのピントを調整すると、粒状斑や黒点などの瞬く縦線が濃く見えるところがあるはずです。
  3. 同時に、太陽光と背景光の境目のピントもぴったり合うはずです。
うまくいくと、下の画面のようになるはずです。
スクリーンショット 2025-07-04 092926

この段階で、縦線は見えるのに境目のピントが合わないとか、境目のピントを合わせると瞬く縦線が見えなくなる場合などは何かおかしいので、Bからやり直すことをお勧めします。ここでのフォーカサーの精度は使っている鏡筒に依るかと思いますが、微動減速装置が欲しくなるレベルです。まだ微動装置を付けていないので、ここのピント合わせに一番気を使います。

逆に言うと、SHG700にマイクロメーターが付いているために、回折格子と2つのレンズの調整がかなり楽になっているということです。この微調整の精度で、横向きの輝線のピントが波長分解能に効き、瞬く縦線や太陽光と背景光の境目の縦線のピントが空間分解能に効いてきます。画像の仕上がり精度にそのまま直結する部分です。Sol‘Exでは微調整の機構はないので、ここで苦労するのかと推測します。SHG700ではSol‘Exで大変だったところをきちんと改善しているのがわかります。

今回合わせたピントを合わせた状態で、前回分解能が出なかったCaKを改めて14枚スタックしてみました。見てもわかる通り、あからさまに分解能が増しているのがわかるので、とりあえずは子のピント出し方法でしばらくは続けていこうと思います。

IP_resize_lapl2_ap5118_IP


JSol'Exがよく止まる

今回、数多くの.serファイルをJSol'Exで処理して分かったのですが、処理中に結構頻繁にエラーが出ます。処理中にタスクマネージャーで見ていると、CPUパワーもメモリも9割以上使っていることが多いので、かなり重い計算をしているようです。撮影用のPCで画像処理もしているのですが、処理用のPCは別途もっと速くてメモリが多いものにするほうがいいのかもしれません。

エラーが出ると、途中で止まってしまったり、画像が最後まで生成されません。一見エラーが見えなくても、特にバッチ処理途中のエラーですでにログ上でスクロースされてしまっていてエラーじゃないと思っても、結局最後まで辿り着かずに止まってしまうこともあります。止まる確率は10%くらいでしょうか。バッチ処理ではいくつのserファイルは成功しても、一つでも止まってしまうものがあると、フォルダの中のどれが完了しているわからなくなるので、結局最初から全部やり直しています。複数のserファイルがあることになるので、全部が成功する確率は結構低くなってしまいます。完了したというメッセージが出ない時は、何か足りないファイルがあると思っていいでしょう。

JSol'Exのバージョン3.2.2がリリースされました。ちょっと重くなったように感じています。エラーの頻度も増したように思えて、最後までたどり着く率が下がった気がします。なので、私は今は3.2.1に戻して使っています。


特徴波長での画像

かなり寄り道をしてしまいましたが、今回撮影した各波長です。色はJSol'Ex標準にしています。細部出しとかも何もしていないので、拡大してみるとちょっと物足りないかもしれません。

各タイトルの波長の横に書いてある数字は、波長分解能になります。例えばHαなら
スクリーンショット 2025-07-05 101928
というように実測で0.091Å/pixelと評価できていて、実際に隣のピクセルとも有意な差が見えているので、分解能を0.091Åと言ってもよさそうです。この分解能は見ている波長によって変わってきて、波長が短くなるほど分解能が悪くなります。最初、あれ逆では?波長が短い方が精度がよくなって分解能もよくなるのでは?と思ったのですが、ピクセルサイズが決まっていてそこに短い波長を詰め込むと考えると、同じピクセルサイズなら見える波長の細かさは粗くなってしかるべきと理解できました。でも波長分解能の違いは、波長の違いの比のルートに比例するようです。1次でそのまま効きそうなので線形化と思いましたが、なぜルートに比例なのか?未だに疑問です。


1. Hα (6562.81Å), 0.091Å
09_39_22-trimmed_0000_09_39_22-trimmed_colorized_0_00

2. Na D1 (5889.95Å), 0.100Å
0000_08_24_28_colorized_0_00

3. Mg b1 (5183.62Å), 0.106Å
0000_08_34_13_colorized_0_00

4. Hβ (4861.34Å), 0.108Å
03_Hbeta_0001_08_44_26_colorized_0_00

5. Hγ (4340.47Å), 0.111Å
04_Hgamma_0000_08_56_44-trimmed_colorized_0_00

6. CaK (3933.66Å), 0.113Å
05_CaK_0003_09_14_06_colorized_0_00

こうやって見ると、波長ごとに模様がかなり違うのがわかります。でもNa D1を見てもわかるように白色光とあまり変わらず特徴が無かったりもします。というか、ほとんどの波長はこのNa D1みたいに白色とほぼ同じに見えるようです。

実は他に、He-D3 (5875.62Å)というのが結構面白そうな模様を出しそうなのですが、Spectrum browserで確認したところ、あまりに淡そうなので今回は諦めました。
スクリーンショット 2025-07-05 090320

またいつか挑戦してみたいと思います。


JSol'Exでの色付け

実はJSol’ExではHαの色だけ、特別な処理をしています。Hαだけ他のものに食らえて派手すぎです。即別な処理を外して、JSol’Ex標準のルールに従って色付けすると、Hαといえど下のようにかなり地味になってしまいます。
09_39_22-trimmed_0000_09_39_22-trimmed_colorized_0_00

私は結構派手な色使いも好きなので、他の波長もHαでやる場合と同じように特別な処理をして派手目にしようとしてみました。でもうまくいきません。どうやらバグみたいで、Spectral rays editorでcolor curveオプションをオンにして色をいじってみるとわかるのですが、青を濃くしてしまうと、serファイルでカラー画像を出した時に変更できるstretchingの所で選択できる「Linear stretch」と「Curve stretch」で初期状態での色遣いが違ってしまっていて、しかもLinear stretchで調整したものは保存できないようです。Hαは青をほとんど出さないので、バグとして認識されていないのかもしれません。

というわけで、もう少し派手目に色付けするとして、Photoshopで自分でやってみました。参考にしたものはMLastroのこのページの一番下にある各波長の色付けです。

6colors

と、こんなカラフルな太陽画像はどうでしょうか?


まとめ

SHG700関連記事も応用編に入り、徐々に分光撮影の威力が発揮されてきました。全波長で本当に0.1Åオーダーで撮影できてます。これは結構すごいです。しかも今回は1枚画像での処理で、JSol'Exのオーとストレッチと色付けだけで、スタックや細部出しもしてません。必要なら、特定の波長は枚数を撮ってもっと凝った処理にしてもいいのかと思います。コンスタントな撮影ももう少し落ち着いたら続けて見たいと思います。

新しく撮影したものを含む、手持ちの撮影ストックはこれくらいです。これまで撮影した画像を使いまだ試したいことがあります。次回、次々回と、ドップラーシフト関連の記事になるかと思います。



前回までに、Hαについては撮影も画像処理も大体一通り試せたので、次は波長を変えてみます。



CaK線

今回はHα線(6562.8Å)に次いでメジャーなCaK線(3933.6Å)を見てみたいと思います。

分光以外でもCaKを見る機器はいくつもあって、PSTのCaKバージョンがFWHMで2.4Å、LUNT社の2.4Åのフィルター、Antliaの5Å3Åのフィルターなどがあります。Daystarのものも5Å、2Å、1Åとあるようですが、研究用途のようで値段も桁が違います。いずれにせよ、Hαがエタロンタイプで0.5Åクラスが普通に手に入ることを考えると、CaKでは半値幅の狭い製品を探すのは難しそうです。

その一方、分光では、眼視はできないですし、全体像を一度にそのままで写すなどはできませんが、波長透過幅は0.1Åオーダーで、一桁程度鋭い範囲で写し出すことができます。


回折格子の回転

SHG700で見る波長を変えるには、回折格子を回転する必要があります。マイクロメータの下部に固定ネジがあるので、手で緩めると回転体が回るようになります。凹型の矢印をCaKと印字されている線に合わせます。固定ネジを再び手で回し、固定します。微調整でマイクロメーターを初めて使います。

太陽光を視野から外し、背景光をSHG700に付けたカメラでとりあえず見てみます。可視光のかなり端の方に来ているからでしょうか、カメラの感度も悪くなっているからかと思いますが、Hα線より明らかに暗くなりました。露光時間を増やしたり、ゲインをあげたりして、ある程度明るくして見てみます。

ここでの一番の問題は、線がたくさんありすぎてどの線がCaKなのか全くわからないことです。何か比較できる画像はないかと探してみましたが、あまりいいのは見つかりません。今後の他の波長のこともあるので、何か波長を特定する手段を確立する必要がありそうです。ここでは、前回解説したJSol'ExのSpectrograph editorを実際に使ってみます。使い方は簡単で、メニューの「Tools」->「Spectrograph editor」を選んで、出てきた画面でCaK線を指定します。CaK周りと思われる輝線をSharpCapで映しながら、Spectrograph editorの画面を横に並べて、画面上の-(マイナス)ボタンで画面の波長幅を小さくしていくと、似たパターンの輝線が見つかるでしょう。

スクリーンショット 2025-06-18 151746

CaK線がわかったので、それを画面の真ん中に持ってくるように、回折格子のマイクロメーターを回して調整します。この状態でカメラレンズ側のマイクロメーターを回してピントを合わせます。また、線が左右で傾いていたら、ここでカメラの回転角を調整して補正します。

次に太陽光を導入し、太陽光をSHG700に入れます。それに合わせて、露光時間を短く、ゲインを下げたりして丁度いい明るさにします。私の場合、1msでゲインを1600(16倍、ZWO換算で240、24dB)にしました。ゲインを増やす代わりに、もう少し露光時間を伸ばしてもいいのですが、最長許容露光時間が1.8msというのを計算上で得ていたので、今回はゲインの方に振りました。

ここから少し迷いました。まず、鏡筒のピントが大きくずれている可能性があります。見ている波長が違うからしかたないかもしれませんが、ボケすぎていて最初ピントがずれていることにさえ気づきませんでした。鏡筒のフォーカサーを大きく動かしてまずは太陽光がきちんとした横幅である程度シャープに見えていることを確認します。分かりくい場合はROIを戻して全画面で見た方がいいでしょう。

次に、SharpCapで画面を300%程度に拡大し、画面を横にスクロールし、太陽光の右端か左端を画面に写し出します。SHG700の鏡筒側に近いコリメーターレンズのマイクロメーターを回して、太陽光の端がシャープになるように調整します。すると輝線のピントがずれるので、再び鏡筒のフォーカサーを調整してピントが出るようにします。次にまたコリメーターレンズのマイクロメーターを回して太陽光の端をシャープにします。これを何度か繰り返して、輝線のピントが合って、太陽光の端がシャープになるようにします。フォーカサーの精度によりますが、鏡筒によっては鏡筒のフォーカサーを調整して太陽光の端をシャープにし、コリメーターレンズのマイクロメーターを回してピントを出す方が楽かもしれません。FC-76にフォーカス微調整のために、余っている自作の減速器を付けたくなりました。

スクリーンショット 2025-06-18 153850_CaK_forcus_cut

輝線のピントは、前々回記事で書いた、ヒストグラムの真ん中の線を右にずらしてコントラストを上げ、縦線が最も濃くなる位置にします。ただしCaK線周りでは縦線は遥かに淡くなるので、SharpCapのヒストグラムの左の線を少し左に、右の線をかなり左に持ってくるなどして、うまくコントラスをあげる必要があると思います。それでも縦線は見えるので、それが全く見えなければ、まだコントラストが取れていないか、ピントが合っていないかどちらかです。ピントに確証を得るためにも、縦線を見える状態に頑張ってすることをお勧めします。

ここまでくれば、あとはHαで撮影した時と同じです。
  • ROIを設定して横長の画面にする。
  • CaK線が真ん中に入っていることを確認。
  • モーターの速度を4倍とか8倍の適した速度する。
  • 階調がRAW16になっているか確認。
  • FPSが100以上で十分なことを確認。
  • 一度テストでモータを回して太陽をスキャンして、一番明るいところでも飽和しないか確認。
などでしょうか。準備ができたら、一旦太陽の端を越えるところまでWかEの赤経のモーターで持っていって、時間無制限で録画されることを確認してから録画開始ボタンを押し、モーターを反対側に回します。太陽がスキャンできたら録画を停止します。

もちろん前々回の記事で示したように、スクリプトを使ってオートで連続撮影をするのもいいでしょう。


画像処理

撮影した動画を処理してみましょう。JSol'Exで撮影した.serファイルを開きます。その際出来上がる画像の向きは、午前と午後で赤道着が反転していることで左右が反転、SHGスクリプトで連続撮影をしたときに往復両方とも撮影すると動く向きによって上下が反転します。これだけで4通りあるので、一度Quick modeで正しい向きになるか確認した方がいいでしょう。もし向きが違っていたら、JSol’Exのオプションで処理時に画像をフリップさせてください。

JSol’Exで処理する際に、見ている輝線を指定してしてやると、カラー画像にはその貴賤に応じた波長の色が自動的に付けられます。今回はCaKと指定したので、400nm程度で紫色になります。下の画像は、colorizedフォルダにできる画像です。1枚だけでスタックなどはしていません。

0001_15_55_41_colorized_0_00

同じような画像でmixフォルダに入っているものが以下になります。

0001_15_55_41_mix_0_00

Hαの時はあまりきづかなかったのですが、mixフォルダにはプロミネンスをあぶりだして合成したものが入ることになります。そもそもCaKでもプロミネンスが見えることを全然知りませんでした。

CaK線画像で波長幅が小さいものはあまりないので、波長をシフトした時にどうなるか見てみるのは面白いです。モノクロですが、-3, 0, +3ピクセル = -0.336Å, 0, +0.336Åずらしたものを示します。

0001_15_55_41_autostretch_-3_00

0001_15_55_41_autostretch_0_00

0000_15_54_25_autostretch_3_00

3枚を比べてみてわかるのですが、
  • 中心波長では黒点があまり目立ちません。Hαでも同じような傾向が見られるのですが、結構一般的なことのようです。おそらくですが、一般的に吸収輝線の中心波長が一番暗くなるので、黒点が目立たなくなるのではと推測したのですが、どうでしょうか?
  • 中心波長の方がダークフィラメントが濃いです。これも黒点と同様で、中心の方がより全体的に暗いからでしょうか?改めてHα画像でも0, -3, 3ピクセルずれで比較してみたら、ちょっとわかりにくいですが 明らかに中心波長の方がより濃く出ているので、おそらく推測が正しそうな気がします。
  • 右下のプロミネンスの形が全然違います。
  • 全体的な模様に関しては中心波長が多少コントラストがよくなる程度で、傾向は変わらない。
などでしょうか。こう考えると、CaKはHαほど波長ずれの依存性が少なく、これまでのフィルターのようにHαに比べて多少広い範囲で見てもそこまで違いはないのかもしれません。


スタック画像

最後に、10枚スタックした画像です。CaKの画像処理が初めてで慣れていないせいもあり、かなり迷走しましたが、まあこんなもんでしょうか。解像度は1枚の時よりもあからさまによくなっていますが、なんか解像度がHαに比べてイマイチです。CaKだらかこうなってしまうのか、何か調整不足なのか、今後調べていきたいと思います。

Image06_ABE3

面白いのは、Hα画像の中心波長のみで見えていた、淡い白い模様は、CaK画像の明るい部分と一致するということでしょうか。同じ日に撮ったHα画像(スタックなしの1枚撮りですが)を載せておきます。白いところの位置を見比べるとよくわかるかと思います。

07_13_53_0000_07_13_53_autostretch_0_00

これが何を意味するのか?HαでもCaKでも、中心波長に近くなって暗くなるとやっと隠れていた淡く明るい部分が見えてくるとかでしょうか?だとしたら、そもそもこの明るい部分は何なのか?まだまだ謎です。ほかの波長の画像も見比べてみたいですね。


まとめ

初めてのHα以外での太陽画像が撮影できました。分光器一台でHαだけでなく、CaKも撮影できるのは随分お得な気がします。しかももちろんCaKだけでなく、400nm程度から800nm程度まで、可視光の範囲内ならどの波長の輝線でも撮影できます。波長を変えられることだけでなく、その任意の波長で波長透過幅を鋭く狭められることのほうが真骨頂なのかと思います。

ここまでで5回の記事ですが、ハード、ソフト含めて基礎的なことは大体試すことができました。今後はこの機器を利用したもう少し応用的なことを試していきたいと思います。と言っても、撮影ストックはこれで尽きてしまったので、新たに撮影する必要があるのですが、とにかく暑いです。晴れている休日に朝早く撮影するのが良さそうです。最近休日も忙しくてあまりチャンスがないので、のんびりとしか進まないのですが、楽しみながらゆっくりやっていこうと思います。












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


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

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


分光特有のブレ

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

10_09_34_x4_20250617_disk_0_00_cut_prom

10_09_34_x4_20250617_disk_0_00_cut_spot

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

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


どうやって太陽画像をつくるのか

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

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

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

07_13_53_0000_07_13_53_average

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


なぜブレるのか?

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

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

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

スクリーンショット 2025-06-23 195202_cut

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

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


改善方法

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

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

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

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


SharpCapで自動連続スキャン

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

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

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

スクリーンショット 2025-06-22 111159

設定はある程度見ればわかると思いますが、
  • 「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スクリプトを起動したときにプロファイル名を指定することで呼び出すことができます。例えば上の設定なら、

[76/600APO_SHG700_Touptek678m_r80-916fps]
TargetName = Sun-Hα
MoveRate = 8
RecSeconds = 30
DelayBeforeRec = 3
AdjustSec = 1.0
Count = 10
ScanAxis = RA
RecDirection = 1
ForceGotoSun = 0

のようになります。最初の行のプロファイル名は任意なので適当です。


撮影

ここまでの設定が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枚の像をスタックしました。

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

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

IP_crop_lapl2_ap23267_cut_sot

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


画像処理

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

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

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

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

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

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

IP_crop_lapl2_ap23267_IP_inv_col


まとめ

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

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












前回の記事で、SHG700の開封と事前準備などについて書きました。


今回はSHG700本体を鏡筒に取り付けて、実際に撮影した様子を記事にしていこうと思います。

一番確実なのはMLastroのチュートリアルビデオを見ることでしょう。

このビデオの主に後半が今回の記事の範囲になります。ただ、英語なのと、私はあまり動画は好きではないので、自分のやったことも含めてまとめておこうと思います。


鏡筒

まず鏡筒ですが、今回は手持ちのタカハシのFC-76を選びました。このブログの昔の記事を読んだことがある方は覚えているかもしれませんが、名古屋にスターベースがまだある頃に、ジャンクで格安で購入した白濁レンズものです。

IMG_7127_cut

鏡筒カバーが分厚い金属製で、まだ鋳造メーカーの名残が残る逸品です。惜しむらくは、レンズのコーティングがまだ未熟な時代のもので、時間と共に必ず白濁してしまうようです。これはのちのマルチコーティングになって解決されていますが、実際は多少の白濁なら望遠鏡をのぞいて見る限りは、全く気になりませんでした。眼視で月など非常に明るいものを見ると、もしかしたら気づくかもというくらいです。カメラで撮影している分には全く問題なかったので、まあ多分今回も大丈夫でしょう。

IMG_7068

鏡筒選びのポイントです。狭い範囲の分光撮影の場合は、ある意味単波長撮影のようなものなので、3枚玉とか4枚玉とかのそこまでハイスペックな光学系は必要ないこと。それともう一つ、こちらの方が重要ですが、接眼部がしっかりしていることです。さすが鋳造を自分のところでやっているだけあって、FC-76の接眼部はかなり強固で、今回のかなりモーメントの大きくなる長もの機器を付けるのにはもってこいです。

加えて、焦点距離が600mmと、SHG700の限界の700mmに近いので性能を十分発揮できるはずです。口径が8cm近くと、PSTやPhoenixなどの4cmよりは倍くらい大きいのも効いてくるはずです。


鏡筒への取り付けとピント出し

まず、鏡筒を赤道儀に取り付けます。この時点ではSHG700はまだ外しておいた方がいいでしょう。導入の際は下の写真のような太陽用のファインダーを使うと楽でしょう。
IMG_1478

撮影時には赤経(RA)か赤緯(DEC)のモーター(どちらのモーターにするかは結局スリットが取り付けられている向きで全てが決まるみたいです。今回の場合は結局赤経モーターになりました。)をスイープさせるので、モーターが一定速度で動く必要があります。そのため、ある程度精度のいい赤道儀がいいかと思われます。私は普段使っているCelestronのCGEM IIにしました。

SHG700を鏡筒に取り付ける前に、一度太陽を導入します。追尾を太陽モードにするのを忘れないで下さい。導入後、接眼部から太陽の明るい光が出ていることを、手などに光を当てて確かめてみてください。熱いので火傷しないようにパッと手をかざすくらいでしょうか。心配なら金属の板などをあてて確かめるといいでしょう。SHG700では、鏡筒接合部の手前についているスリット位置に鏡筒の焦点を合わせる必要があります。あらかじめその位置を確認しておいて、フォーカサの調整範囲内で焦点がスリット位置に持って来れるかどうか、試しておくといいでしょう。

MLastroのページによると、SHG700の前方についているスリットの器材は合成石英でできていて、熱膨張に強いため、口径102mmの鏡筒で集光させて使っていても問題なかったと書いてあります。あまり大きな口径の鏡筒を使うとスリットがダメージを受けることがあるので、注意が必要です。今回は口径76mmなので、スリットを壊すような問題はないでしょう。

いよいよ鏡筒にSHG700を取り付けます。SHG700の取り付け角度はとても重要です。赤道儀の赤緯体が回転する平面にできるだけ平行に取り付けます。あとで撮影して、どれくらいズレているか出て、その量を補正するのですが、とりあえずここの段階である程度正確に取り付けておくに越したことはないでしょう。

IMG_1465

IMG_1476

同時にPCと繋いだカメラの画像をSharpCapで見ます。まだ太陽から視野からがずれていると、背景光が見えます。背景光は暗いですが、事前にフラウンフォーファー線を見たように、露光時間とゲインを上げてやれば見えるはずです。線は水平になっているか(左右の高さが揃っているか)?、ピントが合っているか、今一度確認するといいかもしれません。左右の高さが合っていなければカメラの回転角を調整します。ピントが合っていなければ、カメラレンズ側のマイクロメーターを調整します。

その後、鏡筒の向きを赤道儀で調整して、カメラ視野の中に太陽を入れると、かなり明るい、おそらく飽和した画面になるので、露光時間とゲインを下げます。私の場合は1msでゲインが最低の100(1倍、ZWOで0相当、0dB)で丁度いい明るさになりました。

事前準備の段階、もしくは背景光で、カメラ側のピントをSHG700内部のカメラレンズ位置をマイクロメーターで調整することで合わせてあるので、ここではもうカメラやマイクロメーターに触る必要はありません。また、初期状態ではSHG700内部の手前側のコリメーターレンズの位置は出荷時に調整してあるとのことなので、コリメーター側のマイクロレンズも最初は触らないほうがいいでしょう。また、回折格子の回転角は出荷時ではHαに合わせてくれているようです。最初は一番見やすいHαから試すのが無難なので、回折格子のマイクロメーターも触らないでおくことにします。

太陽が導入された状態で適当に露光時間をゲインを合わせると、横線のフラウンフォーファー線がたくさん見えてくるはずです。もし見えない場合は鏡筒のフォーカサーを調整します。繰り返しになりますが、この時点でカメラの位置やカメラ側レンズのマイクロメーターは触らないことです。ピントが合ってくると線がはっきりしてきますが、ここからはかなりの微調整が必要です。コツはチュートリアルビデオにもありますが、SharpCapのヒストグラムの真ん中の線を右側に持っていってコントラストを上げて、フォーカサーを微調整して見えてくる「縦のたくさん動く線」が最も濃くなるようにすることです。これは太陽表面の模様が見えているのですが、縦全体に見えるということは、Hα線のところだけでなく、模様が広い波長域に渡って広がっているということを意味します。ビデオでも言っていたように、粒状斑が見えていると思って良さそうです。

スクリーンショット 2025-06-17 100723_cut2

最後に重要な確認です。画面上はROIで制限されて表示されていると思いますが、それを300%くらいに拡大表示して、画面を右と左にスクロールさせて、太陽の端の部分見て見ます。太陽と背景が以下の写真のように、十分シャープになっていることを確認してください。

スクリーンショット 2025-06-18 153850_CaK_forcus_cut

初期設定ではきちんとシャープに映るようになっているはずですが、万が一輸送などの振動で、特にコリメーターレンズの位置がズレたりすると、ここがシャープにならずにボケボケになります。その場合は、コリメーターレンズをいじる必要があります。少なくとも私の場合はいじらなくて大丈夫なレベルでしたが、いずれ波長域をHαから変えた時にはいじる必要が出てきます。詳しい調整方法はその時に説明します。


SharpCapの設定

ここまでで、ハード的な準備はほぼ整いました。必要ならばSharpCapと赤道儀を接続しておきましょう。撮影時モーターでスイープさせる時に、ハンドコントローラーで操作してもいいのですが、いずれ自動でスイープできるようにするので、PCから操作できたほうがいでしょう。

SharpCapの設定を見直します。
スクリーンショット 2025-06-17 100657_cut
  • 重要なのはROIです。横幅はカメラの最大幅で、G3M678Mの場合は3840ピクセル、縦幅は200ピクセル程度でいいでしょうか。私の場合、ファイル量節約のため最終的には縦幅100ピクセルまでしましたが、慣れないうちは200ピクセルくらいあったほうがいいでしょう。
  • Hα線が真ん中に入っていることを確認します。上下にずれている場合は、ROI設定画面の「ティルト」を調整して、Hαの上に凸の曲線の全てが画面の中に入るようにします。使うのはHα線の周りのせいぜい数ピクセルなので、基本的に暗い線の中心が全部画面内に入っていれば大丈夫でしょう
  • 露光時間が1ms程度十分速いこと、ゲインが高すぎないこと。
  • モーターの速度を4倍とか8倍適した速度する。速過ぎると中心線を分離よく撮影することができません。遅過ぎるとファイルサイズが大きくなります。
  • 階調がRAW16になっているか、フォーマットがserになっているか確認。
  • FPSが100以上十分速いこと、ドロップが原則0であることを、画面下部に出ている数値で確認します。私の場合、上記ROIだと220fpsくらい出ます。必要ならUSB転送速度を最速や、高速モードオン、フレームレートを最大など、fspを制限しないように設定します。
  • 最後に、一度テストでモータを回して太陽をスキャンして、一番明るいところでも飽和しないか確認。
などでしょうか。ちなみに緑字のところは、使っている機材のパラメータなどから必要な値を正確に計算することができます。でもややこしくなるので、詳しくは後日別記事で解説します。


いよいよ撮影

準備ができたら、いよいよ撮影開始です。一旦太陽の端を越えるところまでWかEの赤経のモーターで持っていきます。フレーム数や時間が無制限で、ストップするまで録画される設定になっていることを確認してから録画開始ボタンを押し、モーターをさっき進めたのと反対側に回します。太陽がもう一方の端までスキャンできたら録画を停止します。これで終わりです。

一応撮影された.serファイルを、SerPlayerなどで確かめるといいでしょう。きちんと太陽の端から端まで撮影できていますでしょうか?


太陽像を再構築

撮影したファイルから太陽の全景像を再構築するためには、何らかの変換ソフトを使った方が楽でしょう。ここではMLastroでオススメされていた「JSol'Ex」を使いたいと思います。かなり高機能なソフトで、この解説だけで一記事使ってしまうほどなので、詳しいことは後日別途記事にしようかと思います。

ここではメニューの「File」->「Open SER file」から撮影したserファイルを開いて、出てきた画面の下の真ん中の「Quick mode」ボタンを押してください。しばらく待つと、serファイルがあったところの下にフォルダができていて、そこを探っていくと「processed」というフォルダの中に太陽全景の画像が2枚入っていると思います。1枚はストレッチなし、もう1枚はオーとストレッチしたものです。

今回、ホントのホントに最初の撮影でできた画像が以下になります。ストレッチしていない方なので、撮って出しと言ってしまっていいでしょう。右に見える筋は雲でしょうか。また、細かいところ、特にプロミネンス周りを見ると、分光撮影特有のギザギザが見えます。
10_06_08_20250617_disk_0_00

それにしても、初っぱなからかなりの解像度で撮影されています。

実際に雲などなく、うまく撮れたのは3ショット目で、オーとストレッチしたものですが、以下になります。
10_09_34_x4_20250617_autostretch_0_00

とりあえずここまで出たなら、十分満足でしょう。細かいギザギザを取るためには、複数枚とってスタックするのがいいらしいのですが、それはまた次回以降に試すとします。

その前に、一つ重要なことを。チュートリアルビデオにも指摘があるのですが、JSol'Exでserファイルを解析するときに、何度傾いて撮影されたかが角度で表示されます。下の画面のログの中にある「Tilt angle:」というところです。

スクリーンショット 2025-06-20 201321


私は最初-3.88度でした。これは、赤道儀のモータを動かした時の動きに対して、SHG700が平行からどれだけずれて取り付けられているかを表しています。鏡筒のアイピース固定ネジなどを緩めて、SHG700本体をしてされた角度だけ、まあ目分量になりますが、ずらします。方向はわからないので、とりあえずどちらかにずらしてみてください。私は2回目はズレが-6度になりました。3回目は回転方向を変えて0.1度とかになりました。ズレが+/-1度以下がいいとのことです。その後必要なら、今一度鏡筒のフォーカサーでピントを合わせます。


まとめ

初めての分光撮影ですが、とりあえず太陽の再構築までうまくいったようです。分解能もかなりのもので、今後が期待できます。

やはり最初から組まれているSHG700を買って正解だったかもしれません。3Dプリンタを持っていないのですが、たとえ持っていたとしてもSol'Exを自分で印刷してから撮影するまでの敷居よりははるかに低いはずです。完成品でも普通の天体撮影と違いかなり苦労するので、自分で印刷して撮影までたどり着いた方たちには敬意を表します。

長くなったので、今回はここまでにしたいと思います。次は何について書きましょうか?実作業はかなり終えていて、分光撮影でやりたかったことの半分くらいはすでに済んでいます。その一方、記事書きの方が全く追いついていません。JSol'Exの使い方にするか?多数枚スタック撮影の方法にするか?、まあ書きあがった記事からアップしていくことにします。

明日の土曜日も晴れるとのことなので、もう少し凝った撮影に入っていきたいと思います。書くべき記事は更にたまっていきますが...。













このページのトップヘ