ほしぞloveログ

天体観測始めました。

タグ:AutoStakkert

前回記事で、やっと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の使い方です。これも面白いですよ。いろんな種類の画像が出てきます。












太陽画像の処理をしているのですが、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ファイルの数を増やして、もう少し検証してみるのもいいのかもしれません。






このページのトップヘ