フォーラムへの返信
-
投稿
-
ちなみにご質問の話題については、自分も以前いろいろ考えていて、ブログの記事にしています。もしご興味あればご一読ください
https://snct-astro.hatenadiary.jp/entry/2026/01/31/165052田中さんこんにちは。
書かれている「意味がない・ある」とは科学的な合理性のお話なのか、それとも天体写真を好みの美しい画像に仕上げる目的に対してのお話なのかで結論が変わってくると考えます。
前者なら、使用したフィルターの透過特性をSPCC/PCCに適用することで、「適切に設定したホワイトバランスの下で、このフィルターを透かして天体を見たらこういう色になりますよ」という画像を出力することが出来ます。それが一応、「合理的な色」にはなるかと思います。
やってみるとわかるのですが、上の結果はそれほど「映える」色彩にはなりません。ですので私の意見では合理性に囚われず自由にアレンジするのが良いと思います。後者の立場ですね。
全部書いた後に思い出したのですが、オプションでResistration modelを”Two-dimensional surface splines”に変更するとひょっとするとうまくいくかもしれません。上の方法はこれがダメだったら試してみてください
”Restricted Preview”は、SAの計算範囲をプレビューに限定して計算してくれるので、極端に画角が違う場合に有効です
最後に2枚の画像をスタックするときにちょっと工夫が必要になるかもですが、それはそのときにまたご相談ください
そうでしたか、失礼しました。
焦点距離が270mmと550mmで焦点距離がだいぶん違うのですね。ちょっと面倒ですが、以下のような方法を思いつきました
- 270mmの画像群と550mmの画像群をそれぞれ別々に位置合わせして、スタックまでを済ませる。
- それぞれのmasterファイルの位置合わせを以下の手順で行う
- 550mmのマスター画像をリファレンスに指定、270mmの画像をTargetImageに指定
- 270mmのマスター画像のうちで550mmの画像に写っている範囲をpreview指定
- StarAlignmentのStarMatchingタブ内”Restricted Preview”にチェックを入れて実行
- おそらくSAがうまくいく
- 位置合わせを終えた2枚の画像をさらにスタック
おはようございます、乗り遅れました。
一つ確認があるのですが、Toshy-jiGさんがStarAlignmentで合わせようとしている画像はリニア画像でしょうか？ストレッチを終えた後のノンリニア画像だと、星の認識がうまくいかず失敗することがよくあります。
石黒様
なるほど、状況がよくわかりました。
私の経験ですと、ストレッチ後のプレートソルブは、たまたま星をうまく検出して解けることもあれば、そうならずに解けないこともあるという感じです。
解けない場合は、リニア画像の段階であらかじめプレートソルブを行っておくか、または事後的にリニア画像にプレートソルブを行い、その情報をストレッチ後にコピーするかの二通りです。そのばあいは、プレートソルブが済んでいるリニア画像を選択した状態（ウインドウが青くなっている状態）で、プロセスコンソールに
cpast “コピー先の画像のタグ名”
と入力します。するとプレートソルブ情報がコピーされます
石黒様、こんにちは
添付いただいたImageSolverの設定画面にて、ImageParametersのタブが隠れてしまっていて中身が見えていませんが、そこには対象画像に写っている天体の座標、望遠鏡の焦点距離（GS200RCなら1600mmですね）とカメラのピクセルピッチを入力する必要があります。そこは入力されてましたでしょうか？
さらに、上記を正しく入力してあっても、ノンリニアのストレッチ済み画像に対しては星が検出できない場合があります。もしノンリニア画像に対して行っていたようなら、リニアの段階でImageSolverを行う必要があります。
石川さんの書き込みで、離島と富士宮で撮影したそれぞれのミックスするときに、PSF Signal Weightを全面的に信用して良いかどうかの難しい問題ですね。理屈では、光害値のデータでも適切なウエイトで加えればSNは向上すると理解してますが、ちゃんとやったことがないのでわかりません。
でも「あまり変わらなかった」という結果は面白いと思います。いろいろ試してみてください。結果にも興味ありです！
Eccentricityについて自分も気になって調べてみました。ちょっと古いのですが、2021年のJuan氏の書き込みによると
Eccentricity = Sqrt( 1 – (sy / sx)^2 )
で、syとsxはそれぞれ星のx方向とy方向の標準偏差だそうです。
https://pixinsight.com/forum/index.php?threads/subframe-selector-gives-different-eccentricity-results-on-same-data-on-different-computers.17225/
（ただ上の定義だと平方根の中身がマイナスになってしまうことがあるので実際には標準偏差の大きい方をsxにしているはず）。ともあれ、この定義だと星が真円ならEccentricity = 0となるはずですが丹羽さんが書かれたよう真円でもゼロにならないのは、サンプリングの問題でsxとsyを正確に測定できていないからだと思います実際に、CatalogStarGeneratorスクリプトを使って理想的な星を出力してsubframeSelectorにかけてみるとEccentricity =0.35くらいでした。結論としてシャープに写り過ぎていて、星が数ピクセルくらいで写っているような状況だとEccentricityの値はあまり当てにならないという理解でよいのではないでしょうか？
もちいる光学系によって周辺像などが伸びていたりすると、eccentricityが大きくなることはあると思います。また、ASI-AIR上でガイドグラフが良好でも、実際の撮影データが流れることはさまざまな理由で起こります。
ちなみに添付の画像は私がSharpStar15028で撮影したデータで、eccentricyty=0.64です。この夜は平均しても0.65くらいでしたがガイドの精度としてはこんなものかな、と考えています
いしかわさん、こんにちは。拙著をお買い上げいただいたとのこと、嬉しい限りです。
eccentricityの件ですが、お使いの鏡筒がFL55SSなら光軸ずれが原因であるとは考えにくいと思います。
添付いただいたデータは、ガイドなしでの撮影とガイドありの撮影のミックスという理解で良いでしょうか？（eccentricityの値が小さい集団がガイドありと理解しました）そうだとすると可能性としては
- ガイドエラーでeccentricityが大きくなっている
- そもそもFL55SSではeccentricity≒0.6は標準的
のいずれかだと予想しますが、おそらく2.なのではないかというのが自分の予想です。FrameSelectorでは該当のファイルをダブルクリックすると画像が表示されますので、eccentricityが大きいフィイルの実際の星像を確認してみてください。その上で星があまりに楕円であれば除外すると良いと思います。
