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

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

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

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

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



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

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


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

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

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

結合したseeファイルをAutoStakkert!4で読み込み、解析だけすると、各コマの質の評価がされます。

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

AS!4ではその後、この評価結果の通りにいいものから先に並べかえてしょりをすることになります。一番最初に来ているコマを見てみると次のように分解能がいいAからのものが来ていて、

一番後ろに来ているコマを見てみると、ボケボケのBからきているのものになっていることがわかります。

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

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



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

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

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

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

結果は以下のようになります。

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

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

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

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

まずはAutoStakkert4で上位10％選んだものです。

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

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

別の個所を比較します。同じく左がAutoStakkert!4で上位10％選んだもの、右がNinoxで上位10%選択してAutoStakkert4で100%スタックしたものです。

こちらの比較は左の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さん、ありがとうございました。
(追記終り)



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で解析してみると、
のように、先に分解能の悪い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ファイルを作ります。

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



「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ファイルの数を増やして、もう少し検証してみるのもいいのかもしれません。

タグ ：

#太陽

#AutoStakkert

#PIPP

#スタック

#ser

#Ninox