これまでSHG700を使った始動編として、基本的な太陽分光撮影の解説を、ハード面ソフト面に渡り記事にしてきました。今回からは徐々に応用編に入っていきます。と言ってもまだしばらくはJSol'Exの標準機能の範囲内の話です。でも、徐々にこれまであまり見ることがなかったものになってくると思います。
前回はSHG700始動編の(その5)でCaK線の撮影をしましたが、今回はもっと多波長で撮影してみました。
撮影途中で気付いたこともいろいろあるので、メモ代わりですが細かく書いておきます。
前回のCaKの分解能が悪かったので、まずはその再現性です。前回終了時の設定を何も変えずに、まずは1ショット撮影しておきました。その後、何が悪いのか見るために色々見てみると、輝線のピントがあった状態で、太陽光と背景の境目の縦線がボケボケでした。縦線は空間分解能に聞くはずなので、何か設定がおかしいようです。ちなみみ、撮影した動画ファイルからCaKの全景を再構築して見てみると、雲が通過していて全景を見るのが厳しかったですが、分解能は前回と変わらずやはりだめそうです。
CaKの分解能がダメそうだったので、次にHαに戻して分解能が回復するかを見ることにしました。その後、波長を順次短くしていっていくつかの代表的な波長を撮影し、再びCaKに再挑戦することにしてみました。
順序としては、
この内、HγはJSol‘Exでの全景再構築時に選択肢として出てこないので、JSol‘Exのメニューの「Tools」から「Spectral ray editor」を選び、以下のように名前と波長を入れてやります。
波長を入力するとそれに応じた色が勝手に付きます。でもこの色、ちょっと微妙で、出来上がる画像は設定通りになかなかならないことがわかりました。あとで画像と一緒に検討します。
何度か波長を変えていくうちに、ピント合わせ方がある程度確立しました。前々回の記事でCaKに挑戦したときのピントは今思うと大幅にずれていたので、分解能が出なかったのも納得です。
まず自由度の数ですが、SHG700の部分に回折格子の回転 (固定ネジを緩めてラフに回転+マイクロメーターで微調整) と、レンズについているマイクロメーターが2つと、鏡筒のフォーカサーが1つで、合計4つあります。具体的に番号を振っておきます。
A. まず最初に見たい波長を決め、回折格子の回転角度を決定します。
B. 次に、2のコリメーターレンズのマイクロメーターと、3のカメラレンズのマイクロメーターの2自由度を同時に動かします。
調整位置が決定したら、回折格子のマイクロメーターも含めて3つともこれ以上触ってはダメです。
C. 最後に、鏡筒のフォーカサーを調整します。
この段階で、縦線は見えるのに境目のピントが合わないとか、境目のピントを合わせると瞬く縦線が見えなくなる場合などは何かおかしいので、Bからやり直すことをお勧めします。ここでのフォーカサーの精度は使っている鏡筒に依るかと思いますが、微動減速装置が欲しくなるレベルです。まだ微動装置を付けていないので、ここのピント合わせに一番気を使います。
逆に言うと、SHG700にマイクロメーターが付いているために、回折格子と2つのレンズの調整がかなり楽になっているということです。この微調整の精度で、横向きの輝線のピントが波長分解能に効き、瞬く縦線や太陽光と背景光の境目の縦線のピントが空間分解能に効いてきます。画像の仕上がり精度にそのまま直結する部分です。Sol‘Exでは微調整の機構はないので、ここで苦労するのかと推測します。SHG700ではSol‘Exで大変だったところをきちんと改善しているのがわかります。
今回合わせたピントを合わせた状態で、前回分解能が出なかったCaKを改めて14枚スタックしてみました。見てもわかる通り、あからさまに分解能が増しているのがわかるので、とりあえずは子のピント出し方法でしばらくは続けていこうと思います。
今回、数多くの.serファイルをJSol'Exで処理して分かったのですが、処理中に結構頻繁にエラーが出ます。処理中にタスクマネージャーで見ていると、CPUパワーもメモリも9割以上使っていることが多いので、かなり重い計算をしているようです。撮影用のPCで画像処理もしているのですが、処理用のPCは別途もっと速くてメモリが多いものにするほうがいいのかもしれません。
エラーが出ると、途中で止まってしまったり、画像が最後まで生成されません。一見エラーが見えなくても、特にバッチ処理途中のエラーですでにログ上でスクロースされてしまっていてエラーじゃないと思っても、結局最後まで辿り着かずに止まってしまうこともあります。止まる確率は10%くらいでしょうか。バッチ処理ではいくつのserファイルは成功しても、一つでも止まってしまうものがあると、フォルダの中のどれが完了しているわからなくなるので、結局最初から全部やり直しています。複数のserファイルがあることになるので、全部が成功する確率は結構低くなってしまいます。完了したというメッセージが出ない時は、何か足りないファイルがあると思っていいでしょう。
JSol'Exのバージョン3.2.2がリリースされました。ちょっと重くなったように感じています。エラーの頻度も増したように思えて、最後までたどり着く率が下がった気がします。なので、私は今は3.2.1に戻して使っています。
かなり寄り道をしてしまいましたが、今回撮影した各波長です。色はJSol'Ex標準にしています。細部出しとかも何もしていないので、拡大してみるとちょっと物足りないかもしれません。
各タイトルの波長の横に書いてある数字は、波長分解能になります。例えばHαなら
というように実測で0.091Å/pixelと評価できていて、実際に隣のピクセルとも有意な差が見えているので、分解能を0.091Åと言ってもよさそうです。この分解能は見ている波長によって変わってきて、波長が短くなるほど分解能が悪くなります。最初、あれ逆では?波長が短い方が精度がよくなって分解能もよくなるのでは?と思ったのですが、ピクセルサイズが決まっていてそこに短い波長を詰め込むと考えると、同じピクセルサイズなら見える波長の細かさは粗くなってしかるべきと理解できました。でも波長分解能の違いは、波長の違いの比のルートに比例するようです。1次でそのまま効きそうなので線形化と思いましたが、なぜルートに比例なのか?未だに疑問です。
1. Hα (6562.81Å), 0.091Å

2. Na D1 (5889.95Å), 0.100Å
3. Mg b1 (5183.62Å), 0.106Å
4. Hβ (4861.34Å), 0.108Å
5. Hγ (4340.47Å), 0.111Å
6. CaK (3933.66Å), 0.113Å
こうやって見ると、波長ごとに模様がかなり違うのがわかります。でもNa D1を見てもわかるように白色光とあまり変わらず特徴が無かったりもします。というか、ほとんどの波長はこのNa D1みたいに白色とほぼ同じに見えるようです。
実は他に、He-D3 (5875.62Å)というのが結構面白そうな模様を出しそうなのですが、Spectrum browserで確認したところ、あまりに淡そうなので今回は諦めました。
またいつか挑戦してみたいと思います。
実はJSol’ExではHαの色だけ、特別な処理をしています。Hαだけ他のものに食らえて派手すぎです。即別な処理を外して、JSol’Ex標準のルールに従って色付けすると、Hαといえど下のようにかなり地味になってしまいます。
私は結構派手な色使いも好きなので、他の波長もHαでやる場合と同じように特別な処理をして派手目にしようとしてみました。でもうまくいきません。どうやらバグみたいで、Spectral rays editorでcolor curveオプションをオンにして色をいじってみるとわかるのですが、青を濃くしてしまうと、serファイルでカラー画像を出した時に変更できるstretchingの所で選択できる「Linear stretch」と「Curve stretch」で初期状態での色遣いが違ってしまっていて、しかもLinear stretchで調整したものは保存できないようです。Hαは青をほとんど出さないので、バグとして認識されていないのかもしれません。
というわけで、もう少し派手目に色付けするとして、Photoshopで自分でやってみました。参考にしたものはMLastroのこのページの一番下にある各波長の色付けです。
と、こんなカラフルな太陽画像はどうでしょうか?
SHG700関連記事も応用編に入り、徐々に分光撮影の威力が発揮されてきました。全波長で本当に0.1Åオーダーで撮影できてます。これは結構すごいです。しかも今回は1枚画像での処理で、JSol'Exのオーとストレッチと色付けだけで、スタックや細部出しもしてません。必要なら、特定の波長は枚数を撮ってもっと凝った処理にしてもいいのかと思います。コンスタントな撮影ももう少し落ち着いたら続けて見たいと思います。
新しく撮影したものを含む、手持ちの撮影ストックはこれくらいです。これまで撮影した画像を使いまだ試したいことがあります。次回、次々回と、ドップラーシフト関連の記事になるかと思います。
前回はSHG700始動編の(その5)でCaK線の撮影をしましたが、今回はもっと多波長で撮影してみました。
撮影途中で気付いたこともいろいろあるので、メモ代わりですが細かく書いておきます。
波長の選択
前回のCaKの分解能が悪かったので、まずはその再現性です。前回終了時の設定を何も変えずに、まずは1ショット撮影しておきました。その後、何が悪いのか見るために色々見てみると、輝線のピントがあった状態で、太陽光と背景の境目の縦線がボケボケでした。縦線は空間分解能に聞くはずなので、何か設定がおかしいようです。ちなみみ、撮影した動画ファイルからCaKの全景を再構築して見てみると、雲が通過していて全景を見るのが厳しかったですが、分解能は前回と変わらずやはりだめそうです。
CaKの分解能がダメそうだったので、次にHαに戻して分解能が回復するかを見ることにしました。その後、波長を順次短くしていっていくつかの代表的な波長を撮影し、再びCaKに再挑戦することにしてみました。
順序としては、
- Hα (6562.81Å)
- Na D1 (5889.95Å)
- Mg b1 (5183.62Å)
- Hβ (4861.34Å)
- Hγ (4340.47Å)
- CaK (3933.66Å)
この内、HγはJSol‘Exでの全景再構築時に選択肢として出てこないので、JSol‘Exのメニューの「Tools」から「Spectral ray editor」を選び、以下のように名前と波長を入れてやります。
波長を入力するとそれに応じた色が勝手に付きます。でもこの色、ちょっと微妙で、出来上がる画像は設定通りになかなかならないことがわかりました。あとで画像と一緒に検討します。
ピント合わせの自由度
何度か波長を変えていくうちに、ピント合わせ方がある程度確立しました。前々回の記事でCaKに挑戦したときのピントは今思うと大幅にずれていたので、分解能が出なかったのも納得です。
まず自由度の数ですが、SHG700の部分に回折格子の回転 (固定ネジを緩めてラフに回転+マイクロメーターで微調整) と、レンズについているマイクロメーターが2つと、鏡筒のフォーカサーが1つで、合計4つあります。具体的に番号を振っておきます。
- 回折格子
- コリメーターレンズ
- カメラレンズ
- 鏡筒フォーカサー
波長を変えた時のピント合わせの具体的手順
A. まず最初に見たい波長を決め、回折格子の回転角度を決定します。
- 回折格子下部のネジを手で緩めて、回転台の切り欠き溝の真ん中を印刷されている目的の輝線にラフに合わせます。
- SharpCapの画面で見ながら、JSol‘ExのSpectrum browserで表示されるフランフォーファー線図と比較して、目的の波長の近くにいるか確認します。
- 似たような輝線模様が見つかったら、目的の輝線が画面の上下で真ん中になるように、回折格子についているマイクロメーターで合わせます。SharpCapで同心円と十字のレチクルを出しておくと合わせやすいでしょう。撮影時にはROIで上下100ピクセル内に輝線を入れる必要があり、そのために必要なマイクロメーターの精度は1-2目盛り程度になります。
B. 次に、2のコリメーターレンズのマイクロメーターと、3のカメラレンズのマイクロメーターの2自由度を同時に動かします。
- SharpCapの画面を300%程度に拡大し、画面を右か左にスクロールさせて、太陽光が切れるところまで持っていき、ヒストグラムの一番右の線を左にかなり寄せて背景光の輝線が見えるようにします。
- 背景光で輝線がうまく出たら、さらに端に寄せて、スリットの境の光が見えるところと見えないところまで画面を持っていきます。ここで二段階目の調整をします。
- まずは3のカメラレンズのマイクロメーターを回して、画面の横向きの線のピントが合うようにします。
- 一旦横線のピントがあったら、次に2のコリメーターレンズのマイクロメーターを回して、縦の「光があるところとないところの境目」のピントを合わせます。
- ここを合わせると、3のカメラレンズのピントが少しズレるので、また3のカメラレンズのマイクロメーターを微調整します。この時に必要な精度は+/-2目盛りくらいです。かなりの精度が必要なことがわかります。
- 3を微調整したら、再び2のコリメーターレンズのマイクロメーターを微調整します。ここでの必要な精度は+/-7,8目盛りくらいでしょうか。こちらは多少大きく動かしてもいいでしょう。
- この2と3のマイクロメーターの調整を数回繰り返し、横の輝線と縦の光の境目の線の両方のピントが出るようにします。
調整位置が決定したら、回折格子のマイクロメーターも含めて3つともこれ以上触ってはダメです。
C. 最後に、鏡筒のフォーカサーを調整します。
- ヒストグラムを調整するなどして、太陽の直接光の輝線が見えるようにします。
- フォーカサーのピントを調整すると、粒状斑や黒点などの瞬く縦線が濃く見えるところがあるはずです。
- 同時に、太陽光と背景光の境目のピントもぴったり合うはずです。
この段階で、縦線は見えるのに境目のピントが合わないとか、境目のピントを合わせると瞬く縦線が見えなくなる場合などは何かおかしいので、Bからやり直すことをお勧めします。ここでのフォーカサーの精度は使っている鏡筒に依るかと思いますが、微動減速装置が欲しくなるレベルです。まだ微動装置を付けていないので、ここのピント合わせに一番気を使います。
逆に言うと、SHG700にマイクロメーターが付いているために、回折格子と2つのレンズの調整がかなり楽になっているということです。この微調整の精度で、横向きの輝線のピントが波長分解能に効き、瞬く縦線や太陽光と背景光の境目の縦線のピントが空間分解能に効いてきます。画像の仕上がり精度にそのまま直結する部分です。Sol‘Exでは微調整の機構はないので、ここで苦労するのかと推測します。SHG700ではSol‘Exで大変だったところをきちんと改善しているのがわかります。
今回合わせたピントを合わせた状態で、前回分解能が出なかったCaKを改めて14枚スタックしてみました。見てもわかる通り、あからさまに分解能が増しているのがわかるので、とりあえずは子のピント出し方法でしばらくは続けていこうと思います。
JSol'Exがよく止まる
今回、数多くの.serファイルをJSol'Exで処理して分かったのですが、処理中に結構頻繁にエラーが出ます。処理中にタスクマネージャーで見ていると、CPUパワーもメモリも9割以上使っていることが多いので、かなり重い計算をしているようです。撮影用のPCで画像処理もしているのですが、処理用のPCは別途もっと速くてメモリが多いものにするほうがいいのかもしれません。
エラーが出ると、途中で止まってしまったり、画像が最後まで生成されません。一見エラーが見えなくても、特にバッチ処理途中のエラーですでにログ上でスクロースされてしまっていてエラーじゃないと思っても、結局最後まで辿り着かずに止まってしまうこともあります。止まる確率は10%くらいでしょうか。バッチ処理ではいくつのserファイルは成功しても、一つでも止まってしまうものがあると、フォルダの中のどれが完了しているわからなくなるので、結局最初から全部やり直しています。複数のserファイルがあることになるので、全部が成功する確率は結構低くなってしまいます。完了したというメッセージが出ない時は、何か足りないファイルがあると思っていいでしょう。
JSol'Exのバージョン3.2.2がリリースされました。ちょっと重くなったように感じています。エラーの頻度も増したように思えて、最後までたどり着く率が下がった気がします。なので、私は今は3.2.1に戻して使っています。
特徴波長での画像
かなり寄り道をしてしまいましたが、今回撮影した各波長です。色はJSol'Ex標準にしています。細部出しとかも何もしていないので、拡大してみるとちょっと物足りないかもしれません。
各タイトルの波長の横に書いてある数字は、波長分解能になります。例えばHαなら
というように実測で0.091Å/pixelと評価できていて、実際に隣のピクセルとも有意な差が見えているので、分解能を0.091Åと言ってもよさそうです。この分解能は見ている波長によって変わってきて、波長が短くなるほど分解能が悪くなります。最初、あれ逆では?波長が短い方が精度がよくなって分解能もよくなるのでは?と思ったのですが、ピクセルサイズが決まっていてそこに短い波長を詰め込むと考えると、同じピクセルサイズなら見える波長の細かさは粗くなってしかるべきと理解できました。でも波長分解能の違いは、波長の違いの比のルートに比例するようです。1次でそのまま効きそうなので線形化と思いましたが、なぜルートに比例なのか?未だに疑問です。
1. Hα (6562.81Å), 0.091Å

- 撮影日: 2025年7月4日9時39分
- 撮影場所: 富山県富山市自宅
- 鏡筒: Takahashi FC-76(f600mm、F7.9)
- 分光器: SHG700
- 赤道儀: Celestrn CGEM II
- カメラ: Touptek G2M678M
- 撮影: SharpCap Gain 200 (=6dB)、露光時間0.75ms、ROI: 3840x100、平均381fps
- 画像処理: JSol'Ex、ImPPG
2. Na D1 (5889.95Å), 0.100Å
- 撮影日: 2025年7月4日8時24分
- 撮影: SharpCap Gain 200 (=6dB)、露光時間0.75ms、ROI: 3840x100、平均381fps
3. Mg b1 (5183.62Å), 0.106Å
- 撮影日: 2025年7月4日8時34分
- 撮影: SharpCap Gain 200 (=6dB)、露光時間0.75ms、ROI: 3840x200、平均221fps
4. Hβ (4861.34Å), 0.108Å
- 撮影日: 2025年7月4日8時43分
- 撮影: SharpCap Gain 200 (=6dB)、露光時間0.75ms、ROI: 3840x100、平均381fps
5. Hγ (4340.47Å), 0.111Å
- 撮影日: 2025年7月4日8時56分
- 撮影: SharpCap Gain 200 (=6dB)、露光時間1ms、ROI: 3840x100、平均381fps
6. CaK (3933.66Å), 0.113Å
- 撮影日: 2025年7月4日9時14分
- 撮影: SharpCap Gain 400 (=12dB)、露光時間1.5ms、ROI: 3840x100、平均381fps
こうやって見ると、波長ごとに模様がかなり違うのがわかります。でもNa D1を見てもわかるように白色光とあまり変わらず特徴が無かったりもします。というか、ほとんどの波長はこのNa D1みたいに白色とほぼ同じに見えるようです。
実は他に、He-D3 (5875.62Å)というのが結構面白そうな模様を出しそうなのですが、Spectrum browserで確認したところ、あまりに淡そうなので今回は諦めました。
またいつか挑戦してみたいと思います。
JSol'Exでの色付け
実はJSol’ExではHαの色だけ、特別な処理をしています。Hαだけ他のものに食らえて派手すぎです。即別な処理を外して、JSol’Ex標準のルールに従って色付けすると、Hαといえど下のようにかなり地味になってしまいます。
私は結構派手な色使いも好きなので、他の波長もHαでやる場合と同じように特別な処理をして派手目にしようとしてみました。でもうまくいきません。どうやらバグみたいで、Spectral rays editorでcolor curveオプションをオンにして色をいじってみるとわかるのですが、青を濃くしてしまうと、serファイルでカラー画像を出した時に変更できるstretchingの所で選択できる「Linear stretch」と「Curve stretch」で初期状態での色遣いが違ってしまっていて、しかもLinear stretchで調整したものは保存できないようです。Hαは青をほとんど出さないので、バグとして認識されていないのかもしれません。
というわけで、もう少し派手目に色付けするとして、Photoshopで自分でやってみました。参考にしたものはMLastroのこのページの一番下にある各波長の色付けです。
と、こんなカラフルな太陽画像はどうでしょうか?
まとめ
SHG700関連記事も応用編に入り、徐々に分光撮影の威力が発揮されてきました。全波長で本当に0.1Åオーダーで撮影できてます。これは結構すごいです。しかも今回は1枚画像での処理で、JSol'Exのオーとストレッチと色付けだけで、スタックや細部出しもしてません。必要なら、特定の波長は枚数を撮ってもっと凝った処理にしてもいいのかと思います。コンスタントな撮影ももう少し落ち着いたら続けて見たいと思います。
新しく撮影したものを含む、手持ちの撮影ストックはこれくらいです。これまで撮影した画像を使いまだ試したいことがあります。次回、次々回と、ドップラーシフト関連の記事になるかと思います。














コメント
コメント一覧 (6)
情報ありがとうございます。He D3線は暗線でなくて輝線であることは調べていて分かってきました。また、Fe I線か、Na D2線からのオフセットで撮影するのが手かなあとも考えていました。でもJSol’ExのAutodetectでHe D3画像を生成してくれると言うのは全く考えてもいませんでした。仕組みがイマイチ思いつかないのですが、とにかく機会がある時にやってみます。楽しみです。どうもありがとうございました!
https://melix.github.io/astro4j/1.5.0/en/jsolex.html
の
Measurements thanks to the spectrum debugger
にあります。hasyamaさんが言っているのと同じ方法ですね。これでオフセットを手作業で測ってそのの分ずれたところを処理するとのことです。
AutodetectだとNa D2から自動的にこの輝線を選んでくれるという情報ですが、その選択アルゴリズムがかなり難しそうな気もします。一度自分で確かめてみます。
おお、やっぱりオートでできるんですね。今度撮影の機会があればやってみます。