ほしぞloveログ

天体観測始めました。

2025年05月

今回は、4月から撮影の合間にずっと続けているエタロンの調整についてです。現段階でまだ結論は出てませんが、かなり溜まってきたので、途中経過を一旦記事にまとめておきます。


はじめに

4月30日に書いた記事の中で書いた目標の最後の9番、C8+PSTでの良像範囲の改善です。今回の記事の範囲ではカメラはASI290MMを使っています。次回以降の記事では新カメラも使っていきます。

エタロンの調整はなかなか難しいので、簡単でわかりやすいところから順番に丁寧にやっていきます。この記事の後に試したことで、答えがわかっていてすでに意味がないこともありますが、それを飛ばして書くと意味がつながらなくなることもあるので、基本はやったことを順に書いておくことにします。

作業に入る前に、前提条件を書いておきます。
  • エタロンの回転角の自由度による不定性をどうするか? -> 画面中央が暗くなる位置で、ほぼ一意に決まると考える。
PSTのエタロンは、調整リングを回転させ、エタロンに圧力を加えることで鏡間の距離を変化させ、透過波長を調整します。現在の手持ちのエタロンは良像範囲は狭いのですが、暗い部分が画面中心にくることで中心波長を判断していて、その位置さえ再現すれば回転角はほぼ一意に決まるので、毎回その角度に持ってくるようにして一連の作業を進めています。もちろんん多少の誤差はありますが、今回の調整範囲程度では十分再現性もあると考えています。

(補足) 以前は入射光に対するエタロンの角度を変えて中心波長を調整すると思っていましたが、それだと計算上十分な角度変化が取れなさそう (今考えるとFSRの10%くらいは変わっていいはずで、当時の計算は2%) なので、ずっと疑問に思っていました。PSTを作ったCoronado社が持っている特許と、実際に実装されている方式を見る限り、圧力式と思って間違いないと思われます。2024年春までに一連の特許が切れたために最近のエタロンに採用されたようです。Phoenixのエタロンも、後部のスポンジの存在など、見ている限りPSTのものに酷似しています。

もう一つ、今回の一連の作業で困難と思われることを書いておきます。
  1. エタロンへの入射光の平行光度と、エタロンがきちんと働いているかの関係がまだよくわかっていない。
  2. 良像かどうか、スタックして細部出しをしないとわからないことがある。
  3. ニュートンリングが撮影時に確認できない。
などです。

1については、前回前々回の記事で、8cmでエタロン位置を0-5cm程度動かして、エタロン内に入射する光を平行光からずれた状態を作ったはずなのですが、結局エタロンの働きに差を見出すことはできませんでした。鏡間距離が短いことと、フィネスが低い( = 光の折り返し回数が少ない)ことが要因だと推測していますが、もっと動かしたら違いがわかるのか、実はすでに影響が出ていて気づいていないだけなのか、もう少し検証が必要です。

2は結構厄介です。はっきりとした悪い像はリアルタイム見てもわかるのですが、中にはリアルタイムで(まだボケた状態で)見て問題無いと思っていても、スタックした後で(これもまだボケた状態で)見て問題無いと思っていても、ImPPGで細部を出すと、なんかボケ気味だという場所が画面の中の部分的に存在することがあります。撮影時に確かめられるといいのですが、かなり最後の方まで画像処理して出てくるので、すぐに判断ができなくて調査が進みません。この一部がボケる原因そのものも、まだよくわかっていません。

3は、今回以降の一連の検証作業の途中で、カメラの角度が問題だということがわかってくるのですが、カメラの角度を変えるとニュートンリングが出てくることがあります。ニュートンリングを避けたいのですが、軽いものだと太陽表面の模様などに隠れて、撮影中はよくわからないのです。これも画像処理を進めていく過程、特にタイムラプス映像まで作ると、リング上の模様が動いているのがわかることがあります。撮影時に判断ができないので、困りものです。


PSTを回転

最初にやったのはかなり簡単なことです。

1. PSTとC8の取り付け相対角度を変える

まずいつもの通りC8+PST+ASI290MMで太陽表面のHα画像を撮影します。上に書いた通り、エタロンリングの調整は画面中央付近が一番暗くなるところを選ぶので、ほぼ一意に決まります。少しわかりやすいところを選びましたが、いつものように画面右側が明らかに模様が出ていないのがわかります。

スクリーンショット 2025-04-26 141939

次に順次PSTをC8に対して90度づつ回転していきます。その際、同時にCOMSカメラも順次90度回転させていき、視野の角度が回転しないように補正するようにします。PSTを90度や180度回転させただけではそこまで違いがわからなかったのですが、270度回転させた時には明らかに改善が見られました。

IMG_1198

その時の画像です。見ている場所が違うので少し比較しにくいですが、明らかに右側が改善しているのがわかると思います。

スクリーンショット 2025-04-26 141435_270

この状態で、500フレーム撮影し、改善するかどうか比較してみました。
14_37_04_lapl2_ap2782

うーん、右側は思ったより改善してません。この日(4月26日)はここでおしまいとなりました。


もしかしてエタロンのではない?

2. チルト角度調整

4月30日の記事で書いたように、上のテストの次の日 (4月27日) に粒状斑を撮影しています。そこでふと気づいたのですが、ここでも同じように右側がボケボケなんですよね。クロップしていない画像を改めて載せておきます。

13_34_29_lapl2_ap3983_out

PSTで右側がボケていたのはエタロンの透過中心波長がHαからズレていたと思い込んでいたのですが、粒状斑の撮影では白光なのでエタロンは全然関係ないはずです。ということは、これはC8かカメラから来ているでは?と考えたわけです。

ここで怪しいのは、カメラの手前に入れてあるチルトアダプターです。もともとの目的は、焦点距離が長くなりF値が大きくなると、直線的に入ってくる光が多くなるためにニュートンリングが発生しやすくなるので、それを回避する目的でカメラを傾けて取り付けるために入れています。ただ、その傾き角をかなり大きく取ってしまっているので、もしかしたらそれで焦点が合っていないだけなのではないかと思ったわけです。

IMG_1336

しかも、午前と午後では赤道儀が反転するので、画面で見て上側を北に保つためにCMOSカメラを午前と午後で180度回転するのですが、たまにこの180度回転を忘れてしまう時があって、その忘れた時はボケが右から左に移動してるのを思い出しました。もしこのボケがエタロンからきているなら、ここでボケの左右反転は起きないはずですが、もしこのボケがチルトアダプターからきているとしたら、カメラとチルトアダプターの取り付けはねじ込み式なので相対角度は常に保たれているので、左右反転が起きるはずで、今ある現象を説明することができます。

この推測を確かめるために、ゴールデンウィークの5月4日の午後の曇りの中の晴れ間を利用して、実際にチルトアダプターを変更してみました。

結果は上から順に、チルトアダプターが 1. これまで通りほぼ最大角、2. 半分の角度、3. 傾きなしとなります。
スクリーンショット 2025-05-04 152454_01_original
スクリーンショット 2025-05-04 153620_02_hal;f
スクリーンショット 2025-05-04 153912_03_0degree

下にフラット補正時のヒストグラムが残ってしまっているので少し比較しにくいですが、右側が明らかに改善されていきます。傾きをなくした時にもニュートンリングはパッと見は確認できません。傾きなしが一番いいので、とりあえずこれ以降は傾きなしでさらに調整を進めます。(その後、別の黒点画像を連続撮影し、タイムラプス映像にしたところで、明らかにニュートンリングの存在がわかりました。なので、傾きをなくす場合は、何らかの対策が必要です。)


C8に対するエタロン位置調整

3. C8に対して、どれだけPST本体を押し込むか

次に試したかったことは、鏡筒に対するPST固定位置の変更でした。でもその前に、カメラ位置の自由度を高めるために、ここでいったんチルトアダプターを外してカメラをより押し込む方向に動かしました。その結果を載せます。

スクリーンショット 2025-05-04 154255_04_notilter

右側の見え方が有意に悪くなっていますが、理由はまだよくわからないので、一旦は放っておきます。ここでのテストは上の画像がスタートになります。

鏡筒に対して、レンズ込みのエタロン位置を相対的に変えるために、手持ちの2インチの延長アダプターをC8とPSTの間に挟み込みます。これでエタロン位置も含めてPST全体が3cmほど後ろに下がったことになります。ここから更にPSTの入れ込み度合いを調整することで、もう少し位置を変化させることができ、最大で6cmくらい下げることができます。その際のピントは、C8側で合わせます。C8の主鏡の位置をずらすということですが、この調整範囲がかなり広くて、以降のテストで様々な個所の位置を変えていますが、すべてピントを出すことができます。この調整範囲の広さはC8を選んだ利点の一つです。

結果になります。上から順に 1. 2インチ延長アダプター挿入後で初期位置から3cm下がった状態、2. さらにアダプターに浅くPSTを入れることでさらに3cmほど、合計で6cmほど後ろに下げた後となります。
スクリーンショット 2025-05-04 154649_05_2inch_adapter

スクリーンショット 2025-05-04 155148_07_2inch_adpter_faresr

上3枚を比較してみると、最初の位置からエタロンを変化させても、予想に反して右側の映り具合はほとんど変化しません。これは8cm鏡筒でのコメントの議論がヒントになって謎が解決しました。gariさんが「PSTの黒箱を望遠鏡に挿してピントを合わせられる場合、対物がいずれの場合でも焦点位置からだいたい200mm手前の位置に-200mmのレンズが配置されることになるので、いずれの対物でもほぼ平行光になります」と言っていて、その後、私から「PSTの場合、レンズ位置とカメラの位置が固定だから、ここをいじれない限り大きく状況は変わらないということですね」と返しています。今回はPSTのピント調整を使わずに、この段階ではカメラ位置も調整していなくて、手前のC8のみでピントを合わせていることになります。結局エタロン以降でのセンサー面までの光の状態に(ほぼ)違いはないので、コメントでの議論が実証されたような形になるのかと思い、納得できました。


カメラ位置の調整

面白いのはここからです。

4. カメラの位置を変えて、エタロンとカメラセンサー面の間の距離を変える

上の最後の状態から、カメラをPSTに対して浅く差し込むようにして、エタロンから遠くで固定するようにしてみました。右側に明らかな改善が見られ、細かい模様が出ています。
スクリーンショット 2025-05-04 155839_09_2inch_adapter_faethest_tilter_far

ここに載せている状況以外でもいろいろ試してみましたが、やはりカメラを遠くに付ける方が右側のボケが少なくなるのは確実なようです。なので結局、C8とPSTの間の2インチ延長アダプターは外して、チルトアダプターを再度取り付けました。その時の画像が以下です。

スクリーンショット 2025-05-04 160149_10_no2inchadapter_tilter_camera_far

ただしこれがベストかというと、たぶんまだ結論を出すのは早そうです。まず画面右側はいいのですが、逆に左側の分解能が出ていない気がします。また、画面上にニュートンリングっぽい回転状の模様が出ているようにも見えます。でも見分けはかなり微妙で難しくて、明らかな差が出るような状況にない限りは自信をもってこれがいいというのは難しいです。


再度PSTを回転

5. PSTをC8に対して、再び回転させてみる

上の状態をもう少し改善できないかと思い、ここから、再度前週に試したPSTの取り付け角度を探ることにしました。書き忘れてましたが、この日のテストは再びPSTを0度で取り付けていて、前週の270度ではなくなっています。正直に言うと、単に270度のことを完全に忘れていただけで、何の疑いもなく最初からいつも通りに0度に取り付けてしまっていました。

0度から順に変えていきます。上から0度、90度、180度、270度です。
スクリーンショット 2025-05-04 162401_01_0deg_original_tilter0deg
スクリーンショット 2025-05-04 162931_03_90deg
スクリーンショット 2025-05-04 163133_05_180deg
スクリーンショット 2025-05-04 162709_01_270deg

これら4枚を比べると、特に画面左側が、有意に180度 > 90 or 270度 > 0度となっていると言えそうです。前週の270度がよかったというのは、やはりチルトアダプターでの右側のピンボケの効果が含まれた複合原因だったといってよさそうで、今回の180度の方がより独立した正しい判断だと言うことができそうです。


更にカメラを遠く

6. カメラを最大限遠くに固定

この日の最後に、カメラ位置をもっと遠くにしたらどうかということで、カメラのところに1インチの延長アダプターを挟み込んでみました。下が結果になります。

スクリーンショット 2025-05-04 164049_06_180deg_externder_best_but_darker

大きく変わったことが2つあります。まず、明らかに全体が暗くなりました。画面での見かけ上はストレッチを駆使して同じくらいになるように調整していますが、ヒストグラムの山の位置を比べて見ると明らかに左に移動しているので、実際は暗くなっているのがわかります。この暗くなるのが、BFの径が小さいことによる制限からきているのか、エタロンの働きが変わってよりHαに合ったので暗くなったのか、もしくは全く別の理由なのかは今のところ不明です。ただ、全体的に分解能はよくなったようにも見えますが、これは時間にも依るものなのかもしれないのでまだ結論は出ていません。

まとめ

と、今回の記事はここまでとしたいと思います。

ここ最近ずっとこのエタロン調整のことを考えています。週末の天気が悪くて、何の検証もできなかったのが不満なのか、昨晩はとうとう夢の中にエタロンが出てきて、全く訳のわからない調整を延々としていました。もうちょっとした末期症状です。

この後、より画角の広いG3M678Mが来て、さらにいろんなことがわかるのですが、これまた長くなるので、次回以降に書くことにします。







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で撮影した黒点周りとプロミネンスは新カメラということもあり、思ったより時間がかかってしまいました。天気がイマイチで雲が結構な頻度で通り、少し暗くなった画像をどうするか迷ったのと、画角が広くなった分のエタロンの調整がまだ不十分で、どこまで採用するかを迷ってしまったからです。特に、プロミネンスは静止画にするかタイムラプス化するか迷いました。タイムラプスの処理過程は静止画より遥かに複雑で、前にやったものを思い出しながら、しかもカメラが違うのでパラメータも違い、思ったより時間がかかってしまいました。


まとめ

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







新カメラのTouptek社のG3M678Mを使うと、8cm鏡筒での太陽全景でエタロン位置をさらにずらし、像が改善するはずです。実際にやってみました。これはちょっと前の2025年5月11日、あまり天気の良くない日に、晴れた瞬間瞬間を狙ってなんとかやれたテストです。


エタロン位置の最適化 (その2)

8cm鏡筒を使ったエタロン位置の検証は4月末に一度ASI290MMを使って試しています。鏡筒にPSTが当たる最前の位置0mmから、最大33mmまでPSTを後ろに下げることができ、以前のブログ記事では0mmと30mmの画像を比較しています。比較によると、
  • 口径80mm、焦点距離400mmの対物レンズで集光された光は、200mm進むと光径が40mmになる。そこに口径20mmのエタロン手前のレンズが置かれるので、F値は口径から考えるF5ではなく、レンズ径による制限でF10になる。
  • エタロンとともにレンズの位置を後ろに下げると、光径が40mmより小さい位置にレンズが置かれることにより、実効的なF値の制限が緩和される。
  • 実行的な口径が大きくなったことに相当し、分解能が改善する。
  • 実際の画像で見る限り有意な改善が見られた。
というのが結論でした。エタロンを最も下げた33mmという位置では、その位置でピントを出そうとするとカメラを最も奥にPST側に差し込まなければならず、それ以上エタロン位置を下げようとすると、カメラをそれ以上差し込めないので、ピントが出ないのです。これまで使っていたASI290MMではエタロン位置が33mm後ろというのが限界でした。

新カメラのG3M678Mはアイピース型で、さらにPST側に差し込むことができるため、今回はエタロンを50mmまで下げることができました。

その時の撮影画像の結果です。露光時間0.25秒、gain 400 (= 2倍 = 12dB = ZWO換算で120)、100/500framesをAS4!でスタック、ImPPGで細部出しをしています。左がエタロン位置が0mmで、右が50mmです。画像処理過程は両方とも全く同じです。
スクリーンショット 2025-05-18 193130_8cm_G3M678M_0mm_50mm_cut

画像ををクリックして拡大しながら比べて頂きたいのですが、黒点や、黒点右上のダークフィラメントが比較しやすいでしょうか。明らかに50mm下げた方が分解能が出ています。前回の0mmと30mmの比較よりも今回の方が差がはっきりしていて、やはりレンズ径がF値を制限していて、それが緩和されるために分解能が改善されたと言えるのかと思います。

撮影している最中は、エタロン位置が後ろの方が、ヒストグラムで見ていると画面が明るくなっているのが確認できます。これはレンズ径での光のケラレがより少なくなることで説明ができます。実はその際、その明るさの違いから0mmより50mm位置の方が一見分解能が出ていないように見え、なんでだろうと思っていました。でもきちんと同条件で画像処理をして比較すると、やはり理屈通り50mm位置の方がより細かいところが見えたので、やはり考え方におかしなところはなさそうです。

ただし、エタロンが0mmの位置の場合と、50mmズレた位置の場合での、エタロンの効果の違いはまだ認識できていません。エタロンに入る光は少なくともどちらかは平行光からずれることになるので、エタロンの効果が変わってきて、その差がわかるのではないかと期待していたのですが、今のところどちらがいいと、どちらが悪いとかはまだ言えていません。やはりエタロンの鏡間の距離が0.1mm程度と極端に短いので、多少平行光からずれてもエタロンとしての機能は失わないのかと推測しますが、位置を50mmもずらしても、まだあからさまに何も変わらないというのは、ちょっと意外でした。


ROIによる画像サイズの縮小

他にも、画面の大きさを制限するROI機能を使ってみました。目的は2つで、
  • フレームレートを上げたいこと
  • 画像サイズを小さくしたいこと
です。

G3M678Mのフレームレートは23fpsくらいで、ASI290MMの60-70fpsに比べると明らかに落ちています。これは画素数が1936×1096=2121856から3840x2160=8294400へと増えていて、その比8294400/2121856 = 3.91にほぼ比例したフレームレートの低下になっています。ROIで画素数を制限することにより、これが改善しないかと思ったわけです。

太陽でほぼ真円に近い形で写るので、ROIを正方形の2160x2160にした撮影してみたましたが、フレームレートは全く同じの23fpsで何ら改善は見られませんでした。

これで一気にROIを使う動機が薄くなってしまいました。もちろん画像サイズは小さくなります。横幅が3840/2160=1.78なので、ファイルサイズも約1.8分の1になります。その一方、写せる範囲がが小さくなるので、ガイドずれなどに対する耐性は下ってしまうため、少し迷います。

serファイルは絶対量が大きくなるので、それが小さくなるのは少し魅力です。実際、今回500フレーム撮影した場合にできたserファイルは、ROI無しだと8.1GB、ROIで正方形にすると4.6GBです。ただし、全景の場合は枚数を多くとることはあまりないですし、枚数を写すタイムラプスは、SharpCapで直接スタック後の画像だけを保存することを考えているので、トータルサイズはそこまで大きな差にはならなさそうです。ディスク容量を見ながら影響がありそうなら正方形の2160x2160を使うことにするかもしれません。

ちなみに、今回ROIで正方形にしてserで撮影したものから画像処理を進めてみました。最初のG3M678Mの画像は8bitで撮影してしまいましたが、今回は16bitのRAW16できちんと撮影しています。ただし、この日は天気が悪かったので、上記エタロン位置を最適化する前にとりあえず撮影しているので、以下の画像ではエタロン位置やカメラ位置はまだ適当です。

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


タイムラプスは次回以降に

その後はSharpCapのリアルタイムスタックを利用したタイムラプスを撮影したのですが、雲が出てきてわずか20分で中断、その20分も雲の通過で明るさが変わったり、プロミネンスのブーストを失敗していたりで、見るも無残で動画化するにも至っていません。


まとめ

G3M678Mの全景撮影の最適化も進んできました。天気が悪かったので、最低限の全景撮影と、やりたかったテストの一部だけしか進みませんでしたが、それでも8cm鏡筒での振る舞いがよりはっきりしてきました。

実は、この日のことはすでに記事を書いたものと思い込んでいて、すっかり記事を書くのを忘れていました。この前後も色々撮影はテストをしていますが、すでに書いた記事もありますし、まだ書いていないことも随時気示威していきたいと思います。特に、エタロンの良像範囲に対する検証がやっと進んできたので、こちらは早いうちにまとめたいと思います。






CP+のセミナーの中で、SharpCapを使うと太陽をリアルタイムでスタックして画像処理ができるので楽だという説明をしましたが、ブログ記事にはしていなかったのでまとめておきます。この記事を書く気になったのは本ブログのコメントで、リュウさんから設定画面を見てみたいというリクエストがあったからです。


太陽の導入

カメラをPCに繋いでSharpCapで太陽を映すまではいいでしょうか?特に昼間の導入は意外に面倒だったりするので、少しだけコツを書いておきます。
  1. まず、赤道儀や経緯台の水平をきちんと取ることは必須です。水平出しは、これ以降の精度全てに効いてきますので、水準器を使ってきちんと水平になっているのを確認します。(補足: 昔の記事で赤道儀の場合は極軸さえ合っていれば水平出しは原理的にどうでもいいと書いていますが、それはあくまで極軸が正確に合わせられる場合です。昼間はほぼ太陽しか出ていなくて、極軸を精度よく合わせることは無理なので、最低限水平をきちんと取ってから始めたほうが遥かに楽です。)
  2. 鏡筒をホームポジションの方向に向けます。ホームポジションは赤道儀や経緯台の機種によるのでマニュアルをきちんと見てもらえばいいのですが、赤道儀の場合は北極星方向、経緯台の場合は北向き水平が多いでしょうか。太陽ファインダーを持っていない場合は、ここはできるだけ精度よく合わせたほうがあとあと楽です。
  3. 経緯台の場合、水平方向は鏡筒に水準器を当てるといいでしょう。
  4. 北向きにするのはなかなか精度が出ません。最近ではスマホにコンパスアプリがついているので、それを使うといいでしょう。その場合、設定で「真北」を選んでください。デフォルトでは「磁北」になっている場合が多いので、これだと6−7度ずれてしまいます。
  5. 次に進む前に、ここで重要な確認です。望遠鏡は太陽を見ることができる状態になっていますか?白色光の場合は太陽用減光フィルター、Hα線の場合はエタロンとブロッキングフィルターなど確実に付いていますか?私は必ず指差し確認をするようにしています。慣れてしまうとどうしても確認が疎かになる可能性が出てくるからです。
  6. 次に、カメラを鏡筒にセットし、カメラをPCに繋ぎます。SharpCapの上部メニューの「カメラ」から接続したカメラと同じ名前のカメラを選択します。
  7. ここまできたら、やっと赤道儀や経緯台の自動導入を使って、太陽を導入します。昼間の太陽導入は安全のために機能的に制限されている赤道着や経緯台が多いので、その制限を解除します。解除方法は機種に依ります。
  8. 必要なら導入前に念のため、赤道儀や経緯台の現在位置の設定と、時刻の設定を見直してください。現在位置や時刻がずれていると、これ以降導入がズレが出る可能性が高いです。緯度と経度を入力する場合は、スマホのコンパスアプリなどで今いる場所の緯度経度を確認できるので、その値を入力するのが楽です。
  9. 太陽を自動導入後、SharpCapで画面を確認しますが、大抵の場合は太陽は画面内に入ってこないと思います。
  10. 太陽ファインダーを持っているなら、太陽光がファインダーの投影板の真ん中に来るように、赤道儀の場合は架台部分の「ネジ」を使って水平方向と垂直方向を合わせます。この時点ではモーターを使わないように注意してください。この時点では、設置時の赤道儀の極軸からのズレを補正するためです。経緯台にはネジがついていないと思いますが、ネジの代わりに三脚をの足を伸ばしたり、水平にずらしたりして、水平方向や垂直をある程度合わせてもいいでしょう。
  11. 太陽ファインダーがない場合は、次のようにSharpCapの画面で確認するしかありません。
  12. 太陽ファインダーの真ん中に来たら、SharpCapの画面に入ってきているか確認してください。露光時間は機材に依りますが、1msとかかなり短くていいはずです。ゲインも0とかせいぜい200(=20dB=10倍)までで大丈夫かと思います。
  13. 太陽が画面内に入りかけているか確認するために、SharpCapの右側パネルのヒストグラムのところにあるオートストレッチボタンを押して、画面を明るくします。端の方が明るかったりしたら太陽が近くまで来ているということなので、ここからはモーターを使って明るいのが真ん中に来るように合わせます。太陽が入ってきて、極端に明るくなったら、今一度オートストレッチボタンを押して明るさを調整します。太陽の一部でも入ればあとはモーターで真ん中に持ってくるだけです。
  14. 最後に、赤道儀もしくは経緯台の追尾設定を、デフォルトの恒星から太陽に変更するのを忘れないでください。

ピント合わせ

太陽が導入できたら、次はピントを合わせます。ピント合わせも少しコツがあります。
  1. 赤道儀や経緯台のモーターを利用して、見たい位置に太陽を持ってきます。
  2. SharpCapの画面を見ながら、とりあえずそこそこフォーカサーなどでピントを合わせます。
  3. SharpCap右側パネルのヒストグラムで、オートストレッチをかけます。
  4. ヒストグラムの3本ある線の、左の線を背景光を表す左のピークより少し右側に、右側の線をヒストグラムの盛り上がりの右端くらいに合わせます。
  5. 画面を見ながら、真ん中の線を少し右に寄せ、細かい模様がよく出るところを探ります。グラフが下に凸の形になるはずです。
  6. ピントを微調整します。
スクリーンショット 2025-05-11 105533
ヒストグラムで調整するとこれくらいになるので、
かなりピントが合わせやすくなるはずです。


必要ならフラット化で見やすく

もし画面全体が太陽表面だけを見る場合(太陽の縁より外が画面に入っていない場合)は、常時フラット補正をしておくといいでしょう。これを行うことで、上記ピント合わせも遥かに精度よく見ることができます。
  1. 黒点周りなど、太陽表面の見たいところを赤道儀のモーターを使って導入する。
  2. 鏡筒のフォーカサーでピントをかなりずらす。その際、つまみをどちら向きに何回転くらい回したかを覚えておくといいでしょう。
  3. ボケボケになったところで、SharpCapのメニューの「キャプチャ」の「フラットフレームキャプチャ」を選びます。
  4. 出てきた画面でフラット撮影の設定をします。枚数は16枚とか32枚もあれば十分でしょう。スタートボタンのすぐ下の「撮影後新しいフラットを適用する」とかいうオプションにチェックを入れておくと楽です。
  5. スタートボタンを押します。
  6. フラットが適用されていることを、画面(真っ白になるはず)や下部に出ているヒストグラム(一本の細い山になるはず)で確認します。
  7. 画面下部に出ているヒストグラムを閉じ、ピントを元に戻します。ピントの再調整は、必要なら上の手順に従ってください。今回は太陽表面の輝度差が補正されているので、かなり合わせやすくなっているはずです。

これでセンサーやフィルターのホコリ、太陽表面の輝度の違い、エタロンの中心波長のずれで見えにくくなっていたエリア、ニュートンリングなどが補正され、圧倒的に見やすく、コントラストを上げて撮影できるようになります。この状態では、露光時間やゲインはある程度変更できますが、あまりに違う設定の場合はフラットを取り直してください。また、位置などが大きくズレると補正もずれてしまうので、その場合もまたフラットを取り直してください。


SharpCapの撮影設定

太陽が導入できてピントもあったなら、太陽が見えているはずです。まずはカメラの設定をします。
  1. モードはモノクロカメラならMONO16一択です。カラーカメラの場合はRAW16でしょう。
  2. 明るすぎたり暗すぎたりしないように、露光時間とストレッチ度合いを今一度合わせます。
  3. 露光時間は撮影のことも考え1ms程度、ゲインは0 ( = 0dB = 1倍) とか100( = 10dB = ~3倍) から、せいぜい200( = 20dB = 10倍) くらいまでで、ゲインがその範囲に入らなければ露光時間を長くしたり短くしたりします。適度な明るさとは、ヒストグラムで見て山が右も左も切れていなく、かつ山が全体的に広がっている状態です。
  4. ストレッチは適時オーとストレッチボタンを押します。露光時間やゲインを変えたとき、雲が通過して画面の明るさが変わった時も押すといいでしょう。


太陽画像のリアルタイムスタック

明るさが適度に調整出来、ピントもあっていたとしても、まだシャキッとした画像にななりません。ここでいよいよライブスタックを開始します。
  1. メニューの「ツール」の「太陽/月/惑星のライブスタッキングと強化」を選択します。
  2. 出てきた画面で「Sharping&Adjunstment」を選んで、下の画面を参考に調整します。
  3. 左側の「Gaussian Wavelet Sharpening」は十分な解像度が出ているなら「Fine」を上げるだけでほとんど大丈夫です。Level1以降は画面を拡大しながら上げてもいいですが、たいていは強すぎるのでほどほどにした方がいいと思います。画面を引いてみる場合と拡大してみる場合は、いいと思われる設定は違うと感じると思います。好みで設定すればいいと思いますが、私は拡大したときに強くなりすぎずに、引いてみたときにあっさりしすぎなくらいでちょうどだと感じています。
  4. 同画面右側の「Image Adjustments」はかなり便利です。でもその前に、オートストレッチをリセットしてヒストグラム画面で出ている曲線をきちんと直線にするのを忘れないでください。ヒストグラムで画像調整してしまうと、画像を保存するときに二重に調整効果がかかってしまって、変なことになる場合が多いです。
  5. 画面が明るすぎたり暗すぎたりするときは「Brightness」を調整します。「Gamma」は見栄えに大きく関係するので、毎回いいところを探してください。
  6. その後は好みで「Solar Colorization」をオンにするとカラー化されます。カラーの度合いはあまりいじることはできないはずです。
  7. 次の「Corona Boost」は、全景の場合はもうデフォルトオンでいいでしょう。ただし雲などが通過するとずれて強調されたりするので、その場合はオフにしてください。「Radius Offset」は適時変えてみて、いいところを選んでください。これも好みかと思います。

スクリーンショット 2025-05-11 113714

次のタブは「Frame Filtering」です。これでラッキーイメージ的なことができます。下の画面では250フレームにわたって画質の良さを評価して、上位85%をスタックするという意味です。
スクリーンショット 2025-05-11 113731
ここに出ているグラフはピント合わせに利用することもできます。主にコントラストを見ているようなので、特に全景の場合は太陽と背景のコントラスト比に比例して数値が出ます。言い換えると、ピントを前後させて、一番値が大きいところがピントが合っているところということです。先に説明した方法でうまくピントが出ない場合は、こちらを利用してみてもいいかもしれません。

最後は「Stabilizatin/Alignment」です。私はガイド鏡を使ってPHD2の太陽バージョンでガイドすることが前提なので、個々の設定はかなりシンプルにしています。こうしないと、PHD2とけんかしたり、正しい状況が見えにくかったりするからです。
スクリーンショット 2025-05-11 091737
全景の場合は「Stabilization Mode」は「Planet/Full Dis」のほうがいいのかもしれませんが、「Surface」でも普通にズレずにスタックできています。「Stacking Mode」も「Single Point」で十分なようです。というよりも、雲が来るとどんな設定でもだめで、雲が来なければどんな設定でもいいと言うような印象です。

その一方、フル設定だと以下のようになると思います。今回の記事のために設定してみただけなので、あまりあてにしない方がいいかもしれません。上で書いたように、ここまでしてもアラインメント精度はあまり違いがない印象です。いい時はいいけど、ダメな時はどう設定してもダメっぽいです。「Stabilize to cente...」はカメラの画角の中に太陽全景が入っていさえすえば、太陽を常に画面中心に持ってきてくれます。タイムラプスなどの時は便利だと思いますが、カメラの画角から太陽が出てしまったときは途端に像が崩れます。問題はこのオプションがオンになっていると、画角の端まであとどれくらい余裕があるのかわかりにくいことです。

「Track Planet with Camera ROI」は普段ROIを使うことがないので、私の場合は意味がないです。ROIで画角を制限したときに、fpsが上がればいいのですが、実用的なROIの範囲ではfpsは変わらないので、フルで撮影するようにしています。動画ファイルが大きくなりすぎるなら、ROIを設定するのもありだと思います。

さらにチェックしていない「Re-align...」と「Overlay...」は試してみましたが、何が変わるのかいまいちよくわかりませんでした。モノクロ撮影だからなのかもしれませんが、よくわかりません。

スクリーンショット 2025-05-11 113509

最後、「Time Lapse」タブですが、これもまだあまり試してはいません。できるだけ階調良く保存したいのでフォーマットはSERかTIFFです。でもSERではバグなのか、いまだにうまく保存できないようなので、今がにTIFF一択です。

「Apply Display Histgram...」はここではオンになっていますが、オフの方がいいでしょう。これがオンになっている、もしくはヒストグラムでリセット状態のまっすぐな線になっている場合以外は、たとえTIFFフォーマットだとしても8bitで保存されると下部のノートに書かれています。

「Create short animated GIF...」がオンになっていますが、いまだにうまくGIFファイルが生成されたことがありません。オフでいいかと思います。

あとは何秒ごとに画面を保存するか設定してスタートボタンを押せばいいのかと思います。動画よりもはるかにファイルサイズが小さくなるので、多少間隔を短くしても大したファイル量にはならないでしょう。「Reset stack after...」は経緯台の場合には画面の回転を防いで枠が回っていくのを防ぐことができるので、うまくフレーム数を設定してみるといいでしょう。ただ、タイムラプス撮影をするなら、あえて回転を見たいとかでなければ太陽の場合は素直に赤道着を使った方がいいかと思います。

スクリーンショット 2025-05-11 120116

いくつかはうまく動かない機能があるので、私の環境が悪いのか、バグなのか不明ですが、タイムラプスに関してはまだそこまで期待しない方がいいのかもしれません。

右から二つ目のタブで設定が3通りまで保存、再現できます。設定を変えた時の比較などに使えるので随時使うといいでしょう。


まとめ

以前は惑星も太陽も画面センターにキープできる機能が便利で、FireCaptureで撮影することが多かったのですが、SharpCapの機能が圧倒的に進んでしまい、少なくとも私は太陽用にはもうSharpCapオンリーです。今回はかなり基本的な太陽の導入の仕方から解説したので、よかったら参考にしてください。私なりのテクニックも随所に入れ込んでいます。







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


カメラセンサーの違い

前々回、口径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だったことも今週気づきいたことです。







太陽画像の処理をしているのですが、AutoStakkertの画像選別がいまいち信用できていません。

最近は1ms程度の露光時間で、そう多くない200フレーム程度を撮影し1ショットとし、この1ショットを30秒ごとに撮影して、1時間とか2時間とか長時間の連続撮影しています。その中で統計的に飛び抜けてシーイングのいい時間帯を探すと、そのショットはたのショットに比べて平均的にシーイングがいいので、そのうちの上位90%とかを使うことにしています。

その対極の方法が、1ショットを数千フレーム、時には万のオーダーのフレーム数で撮影して、スタック時にその中から上位フレームを数%とかのかなり少数を選んでスタックすることでしょうか。

後者の方法でやっていたこともあるのですが、そもそも平均的にシーイングがイマイチな時間を撮影している限り劇的によくなることはないことは、ここ1ヶ月くらいで理解できました。それはそれとして、上位フレームを選ぶのにAutoStakkertを使っていますが、長時間ファイルから少数を選んでもスタック結果を見る限りきちんと上位フレームを選べている実感があまりなく、この結果がいまいち信用できなかったのです。

少なくともこれまで、きちんとしたフレームが選ばれるという確認を自分では取ったことがなかったので、今回少し検証してみました。


PIPPを使ってAutoStakkertの画質評価を検証

かなり昔にインストールしたserファイルの事前処理アプリのPIPPを最近再び使うようになってきて、思ったより色々できそうなことを再認識できたので、ちょっと面白そうな実験をしてみました。

PIPPの機能の一つとして「複数のserファイルを結合する」ということができます。serファイルの読み込みの「Source Files」のタブで複数のserファイルを読み込んだ状態で、同じ画面内の「Multiple Soure Files:」で「Join mode」を選ぶことで、結合された動画ファイルを生成する処理となります。


1:
ここに2つのserファイルを用意します。一つは A:シーイングがいい時間帯のもので、分解能がよく出るとわかっているserファイルです。Aのファイルを実際に90%スタックして、ImPPGで細部出しをしたものが以下の画像になります。分解能も出ているのでシーイングが良かったことがわかります。
12_05_56_lapl2_ap3965_out

もう一つは、B:シーイングが悪い時間帯のもので、分解能が出ないとわかっているもので、同条件でBを細部出しまでしても、以下の画像のようにかなりボケボケです。
12_12_43_lapl2_ap3955_out

これらA、Bの2つのserファイルを、PIPPを使って特に余分な処理を何もせずに、そのまま単純に結合します。結合の順序は、分解能が出ていないBを先、分解能が出ているAを後としました。これはAutoStakkertではいいと判断されたコマが先に持ってこられるので、きちんと順序づけできているかどうか、元ファイルの先にいいものがあるか、後にいいものがあるのかで不公平が出ないようにチェックするためです。

結合したseeファイルをAutoStakkert!4で読み込み、解析だけすると、各コマの質の評価がされます。
スクリーンショット 2025-05-09 110155_cut1

評価されたグラフの灰色の線で結果を見ると、ファイルの先に記録されているほぼ半分のコマは評価が低く、後半半分のコマの評価が高いです。緑色の線はこの評価を利用していい順に並べ替えた後の結果なので、ここでは無視してください。これはPIPPで指定したように、前半はシーイングが悪いB、後半はシーイングがいいAという順序の通りになっていて、AS!4でもきちんと評価できていることがわかります。

AS!4ではその後、この評価結果の通りにいいものから先に並べかえてしょりをすることになります。一番最初に来ているコマを見てみると次のように分解能がいいAからのものが来ていて、
スクリーンショット 2025-05-09 110155_cut2

一番後ろに来ているコマを見てみると、ボケボケのBからきているのものになっていることがわかります。
スクリーンショット 2025-05-09 110242_cut2

上の2枚の比較はよく見ないとわからないかもしれません。スタックして細部を出した後にものすごい差が出るとしても、動画の状態での一コマの比較ではこのように最良コマと最悪コマで見たとしても、わずかこの程度の差に過ぎません。もし元々撮った一つのserファイルを、AutoStakkert!4でいい悪いを評価してもらったとしても、見える差は非常に小さくて、それが本当にいいのか悪いのか、少なくとも私の眼力でははっきり見分けることができません。

それでも上の結果だけ見ると、AutoStakkert!4の順位づけは正しく使えるという評価になりますが、それは本当なのでしょうか?


では明るさが違うと?

2:
では次に少し意地悪をして、C: シーイングは良かったけれども少し暗く撮影したserファイルと、D: シーイングは悪かったけれども明るく撮影できたファイルを用意します。2つのserファイルC、Dを同様にPIPPで単純に結合します。ちなみに、それぞれ細部出しまでした画像が以下になります。

C: 分解能が出ていても、全体的に暗い
12_02_14_lapl2_ap3963_out

D: 分解能が出ていないが、全体的に明るい:
12_30_03_lapl2_ap3859_out

今回はserファイルの結合順序を、シーイングがいいCを先、シーイングが悪いDを後とします。結合したserファイルをAutoStakkert!4で読みこんで同様に解析にかけます。シーイングをきちんと評価しているなら、前半がいい評価で、後半が悪い評価になるはずです。

結果は以下のようになります。
スクリーンショット 2025-05-09 110740_cut1

ここでも灰色の線を見ます。はい、期待とは全く逆で、前半のシーイングがいいCを悪く評価し、後半のシーイングが悪いDを良く評価してしまっています。

これは、判断基準の一つに「明るさ」というものを使っているからかと思われます。しかもこの明るさが違う場合の評価の差が、先の明るさが同等くらいの時の評価の差よりもはるかに大きくなっているので、シーイングの差よりも明るさの差の方をはるかに重要視しているというまずい結果なのかと推測できます。

ここら辺がAutoStakkert!4での評価が信頼できないところの一つです。

(2025/5/10: 追記) 記事公開後、ASで上位10%を選択してスタックしたものと、Ninoxで上位10%選択してASで100%スタックしたもので差が出るかという質問があったので、試してみました。私はあまり差が出ないと予測していたのですが、結果は思ったより差が出ました。細部出しまでふくめて、同じ条件で処理した結果を示します。

まずはAutoStakkert4で上位10%選んだものです。
12_12_06_lapl2_ap3983_IP

次はNinoxで上位10%選択してAutoStakkert4で100%スタックしたものです。
12_12_06_pipp_lapl2_ap3944_IP

かなりわかりにくいので、わかりやすいところを一部拡大して並べて見ます。左がAutoStakkert4で上位10%選んだもの、右がNinoxで上位10%選択してAutoStakkert!4で100%スタックしたものです。
スクリーンショット 2025-05-10 170954_cut
特に黒点や、その右上は明らかに右のNinoxの方がいいかと思います。

別の個所を比較します。同じく左がAutoStakkert!4で上位10%選んだもの、右がNinoxで上位10%選択してAutoStakkert4で100%スタックしたものです。
スクリーンショット 2025-05-10 172527_cut

こちらの比較は左のASの方が細部まで出ています。どうやら得意不得意があるみたいで、まだどちらがいいのかちょっと迷っていますが、今現在の判断は、最細部がASの方が出ているとすると、ASの方に傾いていますでしょうか。

1つ目の比較だけで判断していた時はNinoxを使えばいいという判断弟でしたが、2つ目の比較でASの方がいいとなったので、どちらのアルゴリズムを選んだ方がいいのか迷うことになります。serファイル内に明るさの変化がある場合はNinox、変化がない場合はASでしょうか。結構面倒です。もう少し検証例を増やした方がいいのかもしれません。(追記終わり)


画像評価のアルゴリズム

少しAutoStakkert!4の画像評価のアルゴリズムを示しておきます。元々は私自身も、AS4!でどんな評価アルゴリズムが使われているのか全然知らなかったのですが、いつも非常に的確な意見を言ってくれる薜くんが、X上でCloudy Nightsで議論の情報をくれました。このページの中の2つ目のリンク先を開き、その中のさらに2つのリンクをたどると、元の論文と思われるものにたどり着きます。特に2つ目のリンクが具体的にどんな太陽の画像を使っているかも示してあり、Gram  matrix Gijと呼ばれる評価関数を使っていることが示されています。Gram  matrixは

(1) The size of the Gram matrix depends only on the number of feature maps instead of the image size.(2) The Gram matrix is only related to texture features of an image, not itsstructural content.

とのことなので、画像の特徴を表すことに適しているようです。これらを利用して、Lqualityを求め、そのLqualityがPE (perception evaluation)そのもので、そのPEとPSF (point spread functionsを表すD/r0との関係をFigure 6で示してくれています。AutoStakkertはこれを利用しているということなので、適当に評価しているわけでは全くなく、かなりしっかり評価しているようです。

その一方、ここまでしっかり評価しているのなら、高々明るさだけの違いでシーイングの評価が、ひどいレベルで完全にひっくり返ってしまうのは何なんだというのが、今の個人的な感想です。

(2025/5/10: 追記)
tentaiさんの情報によると、結局AutoStakkertはLaplacian、下に出てくるNinoxはGradientという、かなり一般的なシンプルなアルゴリズムで処理されていて、リンク先の論文にあるPE (perception evaluation)を求めるような、複雑な判別はしていないことが判明してきました。
シンプルなアルゴリズムでは、例えば輝度に依存するというような実際に判断したいものとは違う基準で判別されることも十分にありうるのかと思います。

複雑な判別とはどれくらいのものなのか、試しにサンプルコードを走らせてみました。太陽表面のHαのサンプル画像が付いていて、PE (perception evaluation)を計算してくれるみたいです。結果は0.239とかいう数字が出てきました。数字そのものの評価はまだよくわかっていませんが、問題は計算時間で、付属の1024x1024ピクセルの小さな画像でも1枚計算するのにM1 Macで1分以上かかりました。実際に撮影する数百枚や、千枚を超える画像を評価する必要があるので、トータルではちょっと計算時間がかかりすぎ、毎回これだとさすがに実用的ではなくなってくるので、結局は今のシンプルなLaplacianやGradientが現実的なのかもしれません。

記事にコメントを書いてくれたほんのり光芒さんのASの評価記事の中でがJUN1WATAさんのLaplacianを利用したserファイルのフィルターを書いた記事がリンクされていました。4月の記事で私も読んでいるはずですが、その時はまだ重要性を認識できていなかったと思います。今読むとものすごく面白くて、OpenCVを利用したコードを公開してくれているので、もし判別のためのフィルターを組みたくなったらここを参考にさせてもらうことになるかと思います。

徐々に理解が進んできていて楽しいです。コメントや情報など参考にさせて頂いたHIROPONさん、OHZAKIさん、tentaiさん、ほんのり光芒のみゃおさん、JUN1WATAさん、ありがとうございました。
(追記終り)


PIPPのNinoxアルゴリズム

ASの明るさ判断に文句ばっかり言っても仕方がないので、ここでもう一つ試します。すぐ上で試したCとDのserファイルの結合時に、PIPPの方で画質評価を適用してやります。


3:
PIPPには「Quality Options」とうタブがあり、その中の「Quality Algorithm Selection」で画質を何通りかで評価でき、各コマをその評価に従っていいものから順に並べ替えてserファイルを再度作ることができます。複数のserファイルを扱う場合でも、複数ファイルに含まれる全コマを並べ替えます。

まずはデフォルトの「Default PIPP Quality Algorithm」というのを選択して再結合したserファイルを作ります。実際にできたserファイルをSER Playerで見てみると、明るくて分解能の悪い画像が前半に来ていて、暗い分解能のいい画像が後半に来ているので、AutoStakkert!4の場合と同じような結果になっています。実際、AS!4で解析してみると、
スクリーンショット 2025-05-09 112004_cut
のように、先に分解能の悪いDから来たと思われる明るいコマをいいと評価し、後半に分解能のいいCから来た暗いコマを悪いと評価してしまっています。これを見る限り、PIPPのDefault PIPP Quality AlgorithmとAutoStakkert!4のアルゴリズムはよく似ているのかと思われます。


4:
次に、PIPPで「Quality Options」の「Quality Algorithm Selection」で「Original Ninox Quality Algorithm」を選んで、2つのserファイルC、Dから再結合したserファイルを作ります。
スクリーンショット 2025-05-09 112357_cut3

できたserファイルをSER Playerで見てみます。おっ!、今度はきちんと暗くても分解能がいいコマが先に来ていて、明るくても分解能が悪いコマが後半にきています。AutoStakkert!4でも解析してみると、
スクリーンショット 2025-05-09 112357_cut1
の灰色の線を見てもわかるように、やはり間違えて分解能のいい前半を悪いと評価して、分解能の悪い後半をいいと評価してしまっています。明るさが優先されてしまっているのがわかります。


結論

「Original Ninox Quality Algorithm」できちんと評価して、必要ない部分はPIPPの方で枚数制限をしてserファイルにして、AutoStakkert!4ではそのいいコマだけを100%利用するようにすれば、変な評価をする可能性のあるAutoStakkert!4の評価を、避けてスタックすることができます。

今回、すくなくとも、「Original Ninox Quality Algorithm」は分解能に対して期待した正しい評価を下してくれることがわかりました。まだこれが完璧なのかどうかの評価ではありませんが、今後はAutoStakkertの評価をそのまま使うことはせずに、きちんと上位画像を選択したいときは少し手間ですが、事前にPIPPの「Original Ninox Quality Algorithm」を通すことにしたいと思います。

ちなみに、Cloudy Nightsの議論一つ目のリンクがNinoxについて書いてあるとのことなのですが、見る限りリンク先は何も表示されません。興味深いのでとても残念です。


まとめ

自分で実際に確かめてみて、やっと少しスタック時の画像選択評価についてあるていど納得できてきました。

AutoStakkertでの画質評価で、いいものがを選択できるという意見も聞きますが、国内国外問わず、AutoStakkertの画像仕分けは信用できないという意見は随所に散見します。

私自身もこれまでAutoStakkertでの画質評価において明るさが関係することは、以前皆既月食で雲があり明るさが変わる悪条件のときに試したので定性的には知っていました。でもきちんとした検証はできていませんでした。実際には、今回のように撮影している最中にも明るさが変化することは十分あり得るはずで、少なくとも今回の結果で、AutoStakkertの明るさの評価が効きすぎていて、他の重要な評価が無視されることがある得るということがよくわかりました。

今回、「分解能」と「明るさ」があらかじめはっきり区別できる撮影ファイルを使うことで、PIPPの「Original Ninox Quality Algorithm」が、見かけの明るさのには惑わされずに、分解能をきちんと見て評価しているらしいことがわかりました。これは、今後も役立つ、大きな確認事項になると思います。

ただこれ以上の評価は、順位付けされたserファイル内のコマを見ても、自信をもってはっきりとどれがいいとは言えないので、なかなか難しいと思います。また余裕があったら、はっきり傾向のわかるserファイルの数を増やして、もう少し検証してみるのもいいのかもしれません。






このページのトップヘ