フォーラムへの返信
-
投稿
-
石黒様
なるほど、状況がよくわかりました。
私の経験ですと、ストレッチ後のプレートソルブは、たまたま星をうまく検出して解けることもあれば、そうならずに解けないこともあるという感じです。
解けない場合は、リニア画像の段階であらかじめプレートソルブを行っておくか、または事後的にリニア画像にプレートソルブを行い、その情報をストレッチ後にコピーするかの二通りです。そのばあいは、プレートソルブが済んでいるリニア画像を選択した状態（ウインドウが青くなっている状態）で、プロセスコンソールに
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が大きいフィイルの実際の星像を確認してみてください。その上で星があまりに楕円であれば除外すると良いと思います。
三村様、こんにちは。
お示しいただいた設定で正しいです。
カラーカメラのフィルター情報にはセンサーの感度も含まれているので、キャプチャのように、QE Curveは IdealQEcurveを指定します。このときGrayfilterの情報は無視されます。
HKIR改造なら、フィルターを取り除いた後UV/IRカットフィルターを入れてくれているはずなのでRGBのフィルター指定もキャプチャの通りで大丈夫です。
こんにちは
前提として、ほかのRAW現像ソフトで現像を行ったあとに16bitのtiff形式などで保存したファイルをpixInisightに読み込んで処理されているとして、その場合ならGHSかMaskedStretchをお勧めします。GHSであれば、強調したい星雲付近をシンメトリーポイントとして指定して、bの値を-1程度に設定した上でストレッチを行ってみてください。
MaskedStretchはまずデフォルトでやってみてください。うまく動かないようでしたら、ここでもう一度質問されても良いですし、よければ拙著「PixInsightの使い方応用編」にも詳しい解説を書いております。
RAWファイルを直接に読み込んですべてPixInsightで処理することも可能ではありますが、風景と空のカラーバランスを両立するのが難しいと思います。
夏に撮影されたデータでは、ダーク減算でアンプグローがキレイに消えることを確認できました。
これまでの状況を整理すると、2月22日の夜に撮影されたNGC4725の画像と、同夜に撮影したフラットフレームだけがストレッチされた状態で保存されており、それ以外の画像（昨年5月から7月にかけて撮影されたダーク・フラット・ライト・バイアス）と、直近の4月に撮りなおしたダーク画像は、正常なリニア画像として保存されています。
恐らく何らかの理由で、2月22日の夜に撮影したデータのみが異常な状態で保存されたのだと思います。それがなぜかはよく分かりませんが、パソコンからカメラを制御するドライバーの動作が不良だったのかもしれません。
念のため、ZWOをカメラドライバーを再インストールしてみてください。そのうえで次回の撮影でまた同じことが起るようなら、また教えてほしいと思います
秋月さん、画像を受け取りました。
拝見したところ、画像のコントラストが高く（ヒストグラムが横に太い）、星雲の中心部がすでに飽和していました。撮って出しからこのような高コントラストの画像が得られることは無いので、何らかの理由でライトフレームがすでにストレッチされたノンリニアな画像になってしまっているようです。これだとダーク減算もフラット補正も合わないです。
ASIImageを使ったことが無いので、原因が分からないのですが、たとえばステライメージでの出力を上書きしてしまったとか、何か心当たりはありますでしょうか？
丹羽さんはASIImageを使ったことがあるそうなので画像の確認をお願いしました。、あとでコメントを書き込んでくれると思います。
Biasを指定していないのであれば、画像を直接拝見しないとわからなそうです。
コチラに撮影されたライトフレーム、フラットフレーム、ダークフレーム、バイアスフレーム（フラットダークの代用）を数枚づつで良いのでアップしていただけますか？https://drive.google.com/drive/folders/1fcFPMAOdxtgSmkoZ62WqKd50mScJPFKC?usp=drive_link
