フォーラムへの返信
-
投稿
-
石川さんの書き込みで、離島と富士宮で撮影したそれぞれのミックスするときに、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
Biasは関係ないですね。ダーク減算でbiasが必要になるのは”Optimize Master Dark”を行うときだけで、基本的にはBiasは必要ありません。最後に見せていただいた画像を出力するときはBiasは指定していませんよね？
結果を見ると、ホットピクセルも残っているようなので、ダーク減算が何らかの理由で失敗しているのは確かなのだと思います。
基本事項の繰り返しになって恐縮ですが、ダーク減算では、ライトフレームとダークフレームについて以下の全てが一致している必要があります
- 撮影したカメラ
- 撮像に使用したソフトウェア
- 露光時間
- ゲイン・オフセット
- 撮影温度
これをもう一度確認させてください。
あと、撮影のソフトは何をお使いですか？
おおっと、消えませんでしたか。私の経験では、単純なミスほど見つかりにくいもので、絶対になにか見落としがあるのだと思います。見事に写っているだけにぜひとも解決したいです。
まず、WBPPから離れてImageCalibrationプロセスでキャリブレーションをしてみるとどうでしょうか？ひとまずフラット補正を無視することにして、添付の設定で、ライトフレームと、ダークフレームを指定します。その際
・WBPPが生成したマスターダークを登録した場合
・撮影したダークフレームを一枚だけMasterDark
に指定した場合で違いが出るかどうか試してみてください。
実行すると、******_c.xisfというファイルが出来るので、それをSTFで仮ストレッチして見せてください
こんにちは。
offset、温度、gain、露光時間があっていてoptimizeMasterDarkをoffにしていればアンプグローは消えるはずなので、秋月さんのケースは興味深いです。丹羽さんのいうとおり、ダークを取り直すのが次の対策になるとおもいますが、私の経験では原因として- 撮像ソフトが勝手に写真の上下の定義を変えてしまっている（以前、SharpCapを使って撮影していた時にこのケースがありました。この場合、通常画像の右上に現れる294MCの強いアンプグローが別の位置に現れます）
- 複数のライトフレームやダークフレームの中に、別のデータが混じってしまっている
です。いづれにしてもダークを撮り直せば解決するかとおもいます。
もしそれでも消えなかったら、かなり不思議です！