フォーラムへの返信
-
投稿者投稿
-
結果を見ると、ホットピクセルも残っているようなので、ダーク減算が何らかの理由で失敗しているのは確かなのだと思います。
基本事項の繰り返しになって恐縮ですが、ダーク減算では、ライトフレームとダークフレームについて以下の全てが一致している必要があります
- 撮影したカメラ
- 撮像に使用したソフトウェア
- 露光時間
- ゲイン・オフセット
- 撮影温度
これをもう一度確認させてください。
あと、撮影のソフトは何をお使いですか?
あ、設定間違えました。ImageCalibrationのMasterFlatのチェックは外してください
ちなみに出力結果をみると、アンプグローがかなり強く残っているので、ダーク減算に微妙にしっぱいしているのではなく、ダーク減算が全く行われていないのだと予想します
-
この返信は2ヶ月、 3週前に
だいこもん (たの天アンバサダー)が編集しました。
おおっと、消えませんでしたか。私の経験では、単純なミスほど見つかりにくいもので、絶対になにか見落としがあるのだと思います。見事に写っているだけにぜひとも解決したいです。
まず、WBPPから離れてImageCalibrationプロセスでキャリブレーションをしてみるとどうでしょうか?ひとまずフラット補正を無視することにして、添付の設定で、ライトフレームと、ダークフレームを指定します。その際
・WBPPが生成したマスターダークを登録した場合
・撮影したダークフレームを一枚だけMasterDark
に指定した場合で違いが出るかどうか試してみてください。
実行すると、******_c.xisfというファイルが出来るので、それをSTFで仮ストレッチして見せてください

-
この返信は2ヶ月、 3週前に
だいこもん (たの天アンバサダー)が編集しました。
こんにちは。
offset、温度、gain、露光時間があっていてoptimizeMasterDarkをoffにしていればアンプグローは消えるはずなので、秋月さんのケースは興味深いです。丹羽さんのいうとおり、ダークを取り直すのが次の対策になるとおもいますが、私の経験では原因として- 撮像ソフトが勝手に写真の上下の定義を変えてしまっている(以前、SharpCapを使って撮影していた時にこのケースがありました。この場合、通常画像の右上に現れる294MCの強いアンプグローが別の位置に現れます)
- 複数のライトフレームやダークフレームの中に、別のデータが混じってしまっている
です。いづれにしてもダークを撮り直せば解決するかとおもいます。
もしそれでも消えなかったら、かなり不思議です!
-
この返信は2ヶ月、 4週前に
だいこもん (たの天アンバサダー)が編集しました。
WBPPは基本間違った処理はしないので、biasは関係ないだろうとは思っていましたが、試していただきありがとうございます。
たとえば撮像のソフトが変わるとoffsetが勝手に変わってしまうことがあります。PixInsightのFITSHeaderでoffsetの値が記録されているので、ライトフレームとダークフレームで一致しているかどうか確認してみて下さい

秋月さん、こんにちは。
”Optimize Master Dark”をオフにしてもアンプグローが出るとすると- キャリブレーションで何らかの失敗をしている
- ライトフレームとダークフレームの撮影時の温度や露光時間が異なっている
の2通りかなと思います。冬あたりからとのことなので2.の可能性もあるかなと思いましたが、ファイル名に表示されている温度は一致しているのですよね?撮影対象によってはストレッチの度合いも異なるのでひょっとすると夏の撮影からアンプグローは密かに残っていたのかもしれません。
それはさておき、一番上のExecution Monitorを見るとBias framesを登録されていますがこれが原因かもしれません。ひとまずbias framesを削除してWBPPを実行するとアンプグローが消えないでしょうか?
M51の画像、なぜか今掲示板に表示されて見ることができました。これはスタックする前の一枚の画像でしょうか? 若干ピントがずれているようですが、もしそうならよく写っていると思います。WBPPが出力したマスター画像についてもじっくり処理してみて、また結果を教えてください
小西様
WBPPは実行できたのですね。よかったです。
その後の画像処理についても、また遠慮なくご質問ください
キャリブレーションで失敗しているようですね。よくある原因は
- ライトフレームとダークorフラットフレームのサイズが一致していない
ことです。念のためライトフレームとマスターダークorフラットフレームをPixInsightで開いてウインドウの上部に表示されるピクセル数が一致しているか確認してみてください。もう一つ可能性として、
- 外付けハードディスクやUSBなどを作業ディレクトリに指定している
とファイル転送の関係でエラーが出ることがあります。Cドライブに全てのファイルを移してから作業した方がいいかもしれません
(つづき)
ただ、WBPPでエラーが出るとすると別なところに原因がありそうです。WBPPのエラーメッセージをキャプチャして張り付けてもらえれば、原因が分かると思います小西さん、こんばんは。
カラー化した時に、画像全体が緑色になるのはカラーカメラは緑の感度が強く設計されているためで、不具合ではありません。緑色の画像に対して、BackGroundNeutralizationをかけてみると、自然なカラー画像にならないでしょうか?
もしならないならカラー化するときのベイヤー配列の設定が間違っているのかもしれません。Celestron Origin Mark IIに使われているセンサーはIMX678だそうで、そのベイヤー配列はスタンダードなRGGB型のようです。WBPPの下のセッティングでMosaic PatternをRGGBに指定してやってみてください。

こんにちは。
メモリに関係するエラーなので、WBPP終了後にキャッシュを削除しても同じようにエラーがでるかどうか、試していただけますか

また、ウェブを調べてみると、以前のバージョンで似たようなケースが報告されているようです。下のケースではWBPPの実行中に落ちるということで、川崎さんの場合とは少し異なりますが、これはPixInsightをアップデートすることで回復したようです。すでに最新版なら、すこし面倒ですけど再インストールを試してみてください
-
この返信は3ヶ月、 3週前に
だいこもん (たの天アンバサダー)が編集しました。
こてっちゃんさん
打点の位置は全て同じとのこと、そうでしたか。
すると理由はよくわかりませんが、DBEの結果が違うなら、それを利用して良い方を採用する作戦は有効そうですね。
(2)に関して、カラー画像にDBEをかける場合と、モノクロのRGB各チャンネルにDBEをかける場合の違いは、サンプルの打点位置の違いではないのでしょうか?
カラー画像に打点する場合は、色の傾斜も見ながらになるのでモノクロに対して行う場合と変わりそうです。
結局どっちが打点しやすいか?って話になるのでは無いでしょうか?
こてっちゃんさん
こんにちは。確かに赤いムラが画面の右端やその他ところどころに現れていますね。
ムラがR chだけに現れているから、画像をRGB分解して、RだけDBEの打点を変えるという方法は納得できます。カラー画像に対してDBEを行ってもムラが取りきれないようでしたら、その方法が良さそうです。特にデメリットもなさそうな気がします。
(SHTとは、Screen Transfer Function(STF)のことでしたでしょうか?)
-
投稿者投稿