ほしぞloveログ

天体観測始めました。

タグ:日記

少し間が空いてしまいましたが、SWAgTiで撮影したパックマン星雲について補足です。


実は上の記事にする前に、画像処理ははるか以前に終わっていたんです。でもダーク補正の有り無しで比較した時のノイズの大きさが、理論と全然合わなくて、ずっと検証していました。その結果、かなり面白い考察となったので、その経緯を書いておきます。


ダーク補正ありなしの、数値的な比較

前回示した記事の繰り返しですが見た目ではダーク補正の有り無しは差がわからないようです。

comp_dark

ちなみに左がダーク補正無し、右がダーク補正ありですが、差はあったとしても本当にごくわずかでしょう。でも、ノイズを実際に測定しても同じくらいなのでしょうか?数値で見てみましょう。

ノイズの測定には、いつものようにPixInsightのImageInspectionのStatisticsを使います。各画像で「プレビュー」で
  1. 恒星が入っていない
  2. 背景に近い一番暗い部分
を、小さな領域でいいので選びます。そのプレビュー画面をStatistics上で選択肢、「stdDev」を見ます。stdDevなど、見たい情報の項目が出ていない場合は、スパナマークのアイコンを押して必要な項目を選択してください。その際、左上の単位がきちんとカメラと合っているか確認してください。今回の場合、カメラが14bitなので、「14bit [0,16383]」を選びます。単位は [ct] すなわち、ADCのカウントになります。コンバージョンファクターがわかっていれば、これを電荷の[e]に変換することができます。

上のエリアを選ぶ二つのことは、ノイズを正確に、安定に測定するために必要な条件です。

恒星が入っていると、恒星は飛び抜けて明るいので、バラツキ(=ノイズそのもの)が大きくなり、本来より大きなノイズの値が出てしまいます。

一番暗い部分を選ばないということは、何らかの天体などの明るさを測定していることになります。明るさがあると、そのバラツキからくるショットノイズが大きくなり、本来見たいダークノイズや読み出しノイズが隠れてしまう可能性があります。

これらのことは基本なのですが、その他にも注意すべきことがあります。今回の測定中にやらかした失敗も含めて、反省の意味も込めて今後の測定のために細かく書いておきます。


撮影と画像処理の条件

前の記事の繰り返しになりますが、一応撮影と画像処理の条件も書いておきます。

撮影はRedCat51+DBPでカメラはUranus-C Proで-10℃に冷やしています。架台はSWAgTi (SWAT350 V-SPEC PremiumにAZ-GTiを載せたもの)で、撮影ソフトはNINA。ガイドは無しで、NINAの特殊機能のガイド無しディザーで最初のうちだけ1枚に一回、途中から3枚に1回ディザリングしています。

ライトフレームは露光時間が1枚当たり3分で、カメラのゲインは100、オフセットは40で撮影しています。94枚画像処理に回したので、合計282分 = 4時間42分ぶんです。この間、NINAでも順調に動いて、特にSWAgTiの長時間撮影で縞ノイズを避けるために必須であるディザリングも問題なく動いていました。ライトフレームは10月9日に合計139枚撮影しそのうち94枚を使い、ダーク補正比較のためのダークフレームは後日77枚撮影して使いました。
がそう処理は、SWAgTiの簡単撮影の特徴を活かすために、バイアス補正、フラット補正などは無しです。解像度を上げたいので、drizzle x2を選択しておきます。

というような条件で、この記事ではダーク補正の有り無しを比較します。


測定失敗1

「Bayer配列画像はノイズ測定に用いるべきではない。」

  1. まず正しくスタックされているかどうか確かめるために、ライトフレームのRAW画像1枚のノイズを測定します。結果は12.5 [ct]でした。
  2. 次に、スタック後のダーク補正なしのマスターライト画像のノイズを測定します。予測だと94枚スタックした場合、ノイズが1/√94 = 0.103倍に近い値の12.5 x 0.103 = 1.29程度になるはずです。でも実際測定してみると、1.08 [ct]と予想よりかなり小さい値になってしまいます。
でもこれはすぐに気づきました。1枚画像はBayer配列のままなので、RGGBでそれぞれ平均値が違ってしまっているために、その平均値のばらつきでノイズが大きいと勘違いしてしまっているのです。解決策としては、Debayerしてからノイズを測ります。PIでDebayerして、再度Statisticで恒星のない部分のノイズを測定すると、6.44[ct]となり、これを0.103倍すると0.663[ct]となります。でもまだマスターライトファイルのノイズ1.08[ct]とはかけ離れています。


測定失敗2

「Drizzle画像はノイズ測定に用いるべきではない。」

Debayer同士で比べているのに、なぜスタック後のノイズが予想より大きすぎるのか?これも少し考えてすぐにわかりました。Drizzleした画像は微妙にずらして重ねたりして解像度を増やしているので、そもそもノイズがどうなっているのかよくわかりません。ここはDrizzle前の画像で評価すべきでしょう。Drizzleはオプションなので、Drizzle前のマスターファイルもきちんと保存されています。Drizzle前のマスターファイルのノイズを測定すると、0.620[ct]で、今度は予測値の0.663[ct]とほぼ一致しました。

これで少なくともダーク補正なしで1枚画像を94枚スタックした場合、ノイズが理論通りの1/√94 = 0.103倍に近い値になることがわかりました。


ダーク補正でノイズは数値でどうなるか

さて、いよいよ別途77枚のダークファイルで作ったマスターダークファイルを使って、各ライトフレームをダーク補正して、WBPPでスタックまでしてマスターライトファイルのノイズを測定します。今回は最初からDrizzleされていない方を選び、Preview機能で恒星がない部分のノイズを測定します。結果は、目で見て比べた時と同様に、ノイズの値はダーク補正がない時の0.620[ct]と比べて、ダーク補正ありだと0.625[ct]となり、ほとんど同じなのでものの見事に一致したと言っていいでしょう。

結論としては、ダーク補正ありでも無しでも、ノイズはほとんど変わらないというのが今回の結果から言えることです。

見た目でダーク有無でほとんど差がないのが、数値でも同様に、ほとんど差がないと示されたわけです。


本当にダーク補正の影響はないの?
.
.
.
え???
.
.
.
でも、

なんでここまで同じなの?ダーク補正の影響は全くないの?

ランダムノイズであるダークノイズを持つ画像で補正しているわけです。ランダムなので引こうが足そうが、補正すればノイズは必ず2乗和のルートで「増える」はずでは?何も増えないのは少なくともおかしいのでは?

とここから長い迷走が始まりました。


スカイノイズが大きいのでダーク補正のノイズ増加が無視できる?

パッと考えられることは、明るい環境で撮っているので、スカイノイズが大きすぎてダークノイズが無視でき、たとえダーク補正してもほとんど影響がないというシナリオです。でも今回はサイトロンのDBPを使っているので、光害はかなり軽減されているはずで、スカイショットのいずの影響は少ないはずです。もしかして、DBPを入れていてもスカイノイズが大きすぎるくらい明るい環境なのでしょうか?

こちらも定量的にきちんと比較してみましょう。そのためにはライトフレームの背景領域の全ノイズに比べて、ダークノイズがどれくらい貢献しているかを比較すればわかるはずです。簡単のために、1枚撮影したファイルで比較します。

まずはダークフレームのノイズですが、今回もきちんとDebayerすることを忘れずに、これまでと同様にPreviewで領域を選択して、Statisticで測定します。結果は5.30[ct]でした。ここにはダークノイズと、バイスノイズ(読み出しノイズ)が含まれていることに注意です。

一方、ライトフレームの1枚画像のノイズは上の測定でわかっていて、6.44[ct] 程度です。

5.30[ct] と6.44[ct] なので、少なくともダークノイズと読み出しノイズが含まれたものは、ライトフレームに含まれるスカイノイズ(+ダークノイズ+読み出しノイズ)に比べて、無視できるくらい小さなものではないことがわかります。

ライトフレームは94枚、ダークノイズは77枚でスタックするので、予測では
  1. ダーク補正無しだと6.44 x1/√94 = 6.44 x 0.103 = 0.663[ct]というノイズと、
  2. ダークフレームの5.30 x 1/√77= 5.30 x 0.114 = 0.60のノイズが2乗和のルートで加わるため、
  3. sqrt(0.663^2 + 0.60^2) = 0.90[ct]
程度になるはずです。でも実測は0.625[ct]と、予想の0.90[ct]1.5分の1くらいで、これは有意に小さすぎます。この矛盾を見つけるのに、相当な時間がかかってしまいました。


なぜダークノイズは増加しない?

1週間以上考えていたでしょうか。答えがわかったあとは、まあ当たり前のことでしたが、これまであまり考えたことはありませんでした。いや、概念としてはおそらく考えていましたが、どう適用するとか、数値で確かめるというようなことは全くしてきませんでした。他に同じようなことを考えた例はないかと思って検索しましたが、定量的な評価はおろか、それに関する記述も見つけることができませんでした。

さてここでクイズです。

今回、なぜダーク補正しても
背景のノイズが増えなかったのでしょうか?

一見不思議ですが、きちんと説明することができます。答えは下の方に書いていますので、自分で考えてみたい方は、ここでスクロールするのを一旦止めてください。答えに必要な条件は上の「撮影と画像処理の条件」のところに全て書いてあります。

答えがまとまった、もしくは答えを見てみたい場合は、下に進んでください。
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
と、答えに行く前に、一つヒントを出します。ヒントはディザリングです。これで答えに辿り着きますでしょうか?

答えがまとまったら、さらにスクロールしてみてください。
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

はい、もうわかりましたでしょうか?答えは「マスターダークファイルも、ディザリングでノイズが散らされる」からですよね。

まだ、ちょっと言葉足らずかもしれません。そもそも今回はPIのWBPP処理に則っているので、先にマスターダークファイルを作って、それを各1枚1枚のライトフレームにおいてそれぞれダーク補正しています。マスターダークファイルを使っての補正の効果は、個々のライトフレームで補正してから重ね合わせても、ライトフレームを(位置がズレることなく)重ね合わせてからマスターダークファイルで補正しても、数学的には同じことです。証明はここ


「ダーク補正の定量的な扱い」あたりから読んでもらえるとわかるかと思います。

ところが実際の撮影では、それぞれのライトフレームは、ディザーをしてライトフレーム時に画面を少し散らして撮影しているので、画像処理の際に「星の位置が合うように」重ね合わると、当然背景はディザーの分だけ散らして重ね合わせられます。個々に補正したマスターダークファイルが、全く位置をずらさずに重ね合わせられるなら、先ほどいった数学的な証明の通り、マスターダークファイルのノイズが2乗和のルートで増えます。ところが、マスターダークファイルがディザーの効果でずれて重ねあってしまうと、個々のライトフレームで補正されたマスターダークファイルのノイズはコヒーレントに重なることはなく、ランダムに重なってしまうことになります。そのため、個々のライトフレームに対して、マスターダークファイル1枚(元のダークノイズの)のノイズ分増加したものが、ライトフレームの枚数のルート分軽減されてしまうのと同じことにになるので、今回の場合さらに1/√94 = 0.103倍となり、ほぼ無視できてしまうというわけです。

実際に、マスターダークファイルで補正した個々のライトフレームを、星の位置合わせをせずに、重ねただけの画像を示します。
integration

小さな揺れが見えることからディザーはされているのはわかりますが、7時間にわたる長時間露光なので、一方向にドリフトしていっている様子も伺えます。この画像の恒星の無いところの背景ノイズを測定してみると、0.938 [ct]となり、見事に予測値の0.90[ct]とかなり近い値で一致します。


結論

というわけで、「ディザーをしているために、マスターダークファイルを使ったダーク補正では、マスターダークファイルの相関のある部分が散らされすために、補正後のダークノイズが増えることはない」というのが今回の結論です。

また、そもそものダーク補正の目的であるホットピクセルですが、
  • Uranus-C ProはDPS (Dead Pixel Suppression)機能のために元々ホットピクセルが緩和されていること
  • PixInsightでCosmeticCorrectionでホット/クールピクセルが緩和されること
と2つの効果で、実際の画像比較でもダーク補正の本来のホットピクセルの緩和の効果がほとんどわからないのかと思われます。


少し見直し

以前の解析で、ライトフレームに対して、ダークフレームは何枚くらい撮影したらいいかを検討していますが、


ディザリングの効果を考慮考えるとこのダークフレームの必要枚数の条件は遥かに緩和されることになります。これを数学的にどう表せばいいのか?ディザリングでどれくらい散らされるかに依るので、統計的な表現が必要になりそうです。かなり複雑になりそうなので、ここではこれ以上の計算はちょっと諦めます。

ただし、このディザリングがあればダークフレームの枚数を減らすことができるというのも、ある程度の制限があるはずで、例えばライトフレームの背景のノイズが、ダークノイズが支配的な場合は、少ない枚数のダークフレームで補正すると、今回考えたようなディザリングによる散らしの効果はあまり聞かなくなるはずです。

極端な例を示します。非常に暗い空で超長時間露光などして、ライトフレームがダークノイズに比べて読み出しノイズも背景のスカイノイズも無視できるとします。ダークフレームは1枚だけ撮影し、それでライトフレームを補正します。個々のライトフレームのダークノイズは√2~1.4倍になります。ライトフレームをスタックする際に、ディザリング効果でどう散らそうが、ダーク補正によって加えられたダークノイズはスタック枚数のルートで軽減されるだけで、ライトフレームに元々あったダークノイズのスタックによる軽減と同じ効果なので、結局のところダーク補正をした場合はダーク補正しない場合に比べて1.4倍程度ノイジーになります。

もしディザーしなかった場合は、ダーク補正によって加えられたダークノイズは、スタックによって軽減されないので、スタック枚数のルート倍大きくまります。例えば、100枚ライトフレームをスタックすると、ダーク補正しない場合に比べて10倍ダークノイズが大きくなります。

極端な場合の比較ですが、ディザーの有り無しで、1.4倍の悪化から10倍の悪化までと、非常に大きな差が出ます。必要ダークフレームの枚数に対して、ディザリングの効果が相当影響すると思っていいでしょう。

ネットを検索すると、ディザリングでホットピクセルが散らされて軽減されるというような記述はたくさん見つかりましたが、調べた限り、ディザリングがマスターダークフレームを散らすので、ダークフレームの枚数を減らすことができるというような記述を見つけることはできませんでした。定性的に考えたら至極当たり前だと直感的にもわかるのですが、定量的な話はおろか、定性的な話もこれまでほとんど言及されてこなかったようです。今後興味があるのは、これをどう定量的に示すかです。言い換えると、ディザリングの効果をどう数学的に記述するかです。また機会があれば考えてみたいと思います。


ダークノイズについて

天文関連の画像処理のページを検索すると、所々に、ダークノイズ = ホットピクセルとか、ダークノイズにはホットピクセルやクールピクセルのような固定ノイズと、ランダムなノイズがあるというような表現を見かけます。私も後者のような表現を使ってきました。でも、ダークノイズというのは本来はダークカレント(暗電流)の揺らぎが起因のノイズのはずです。ダークカレントも、ホットピクセルも、温度の増加とともに増えてくるものですが、ホットピクセル自身がダークノイズというのは、やはり少し強引な気がします。

「ダークフレームを撮影すると、(ランダムに振る舞う) ダークノイズとともに、ホットピクセルも顕著に見えるようになり、そのダークフレームを使うことで固定ノイズであるホットピクセルをライトフレームから除去することができるが、ダークノイズはランダムに揺らぐ(インコヒーレントな、コヒーレントでない、相関の無い) 「ノイズ、揺らぎ」なので、引くことはできずに、必ず2乗和のルートで増える。」

というのがある程度正確な記述かと思います。ホットピクセルはダークカレント起因ではないはずなので、やはりダークノイズとははっきり区別した方がいいのではないでしょうか?


まとめと日記

ここしばらく悩んでいたことが、やっと解決して、ブログ記事にまでまとめることができました。つうじょうに撮影していて、ディザリングもしていて、ダーク補正されている方は、ダークフレームの枚数がより少なくてもいいという話なので、これまで特に問題がないようならば、今回の話は特に気にする必要はないです。でもこういった解析はやはりしておくべきだと思います。しかも、できるだけ定量的に評価できるようにというのが重要だと思います。こういった積み重ねが、どんなノイズが支配的で、どこを改善すればより良くなるかなどに、効率的につながっていくのかと思います。ディザリングの数学的な表現をどうすればいいのか、今後の課題です。

ついでに日記です。今日11月8日(金)から小海において星フェスが開催されています。例年だと諸手を挙げて参加なのですが、今年は体調があまり良くなく、全然予定が立っていませんでした。ここしばらく調子は良かったのですが、先週の長野の泊まりで少し疲れてしまって、今週はあまり調子が良くありません。明日の朝起きて、調子が良ければあまり長居しない程度で行こうと思っています。天気はすごくいいみたいなので、できれば行きたいのですが...。


久しぶりのSWAgTi ネタです。

1年ほど前から試していた
SWAT+AZ-GTi = SWAgTi (gは発音せず、スワッティ)。


SWATの追尾精度とAZ-GTiの柔軟性を合わせて、単機能に近いSWATに自動導入やプレートソルブなどの現代的な便利な機能を追加して使うことができるようになります。かつ追尾精度はSWATそのままと、互いの弱点を補い、いいとこ取りの機能となります。


SWAgTiの弱点

SWAgTiで目指していたところは「気軽な撮影」です。元々SWAT自身は1自由度の追尾精度がものすごくいい赤道儀で、ガイドなしでもそこそこの焦点距離で星を点像にすることができます。以前の SWAT350のテストでは、370mmの焦点距離で3分露光の場合、ガイドなしで歩留まり率は100%だったので、実用的にも十分だと思います。ガイドなしで気軽なSWATの撮影に、AZ-GTiの2自由度の便利な機能を追加して、さらに気軽にしようというのがアイデアです。

これまでのテストの過程で出てきた唯一の欠点が、長時間撮影時にディザーができないことです。


ディザーができないと、長時間撮影のドリフトなどでホットピクセルやクールピクセルが縞ノイズを作ることがあります。


実際に、SWAgTiの長時間撮影ででてきた縞ノイズの例がここにあります。


上のページでも挑戦していますが、縞ノイズは画像処理で改善しようとしても、緩和することはあっても完全に消すことはかなり困難です。できることなら撮影時に縞ノイズが出ないようにしたほうがはるかに楽で、ディザーはその解決策としては最も有効な方法です。

ところが、SWAgTi動作時にはSWAT側で恒星を追尾して、AZ-GTi側の恒星追尾を切る必要があり、AZ-GTiの恒星追尾がオフになるとSharpCapで出すディザー信号がAZ-GTiのモーター側伝わらずに、ディザーができないという結果になってしまったのです。

もちろんSWAT単体ではディザーすることはできないので、SWAgTiがSWATに比べて不利になったということではありません。ドリフトは数時間以上の長時間撮影で問題になってくるので、短時間撮影だと縞ノイズはそこまで目立ちません。SWAT単体で長時間撮影する際にどうするかですが、SWAT開発者が去年の胎内の星まつりで示してくれたように「撮影中に何度かわざと三脚をずらしてドリフトする方向を変える」とか、今年の福島の星まつりで見せてもらった10時間以上かけて撮影したというオリオン大星雲では「日を変えて何度も撮影することでドリフトの方向を一定にしない」などの対策をしているようです。ある意味余計な機材を使わないシンプルな解決策で、開発者の方が「そんな複雑なことはしてないですよ」とおっしゃられていたことが印象的でした。

なので、少し手間をかければ縞ノイズを避ける方法はあるということですが、私的にはやっぱりなんとかしたいので、再度ディザーに挑戦です。


ソフト的に何か間に割り込ませるか?

では具体的にどうするかですが、最初はSharpCapとAZ-GTiの間に何かソフト的に挟んで、命令を無理やり出せるようにしようと考えていました。Uedaさんがトラバースの赤道儀化でSynScan Appとトラバースの間に赤道儀のふりをするような別ソフトを間に入れて上手くいっているので、同じような手法が使えないかと思いました。幸いなことにソースコードを公開してくださっていて、C#で書かれているようです。初めての言語だったのですが、コードは規模的にも大きくなく、自分でビルドまでできて、とてもいい勉強になりました。SWAgTi用にどうハックすればいいのか、ある程度の目安が立ってきたので、とりあえず取り組んでみようと思っていた矢先でした。


SharpCapが変わった?

まずは状況の確認で、以前のSWAgTiの設定を再現します。再現といっても、プログラミングのための準備なので昼間の明るいうちでの確認になります。SWATとAZ-GTiを組み合わせて、SynScan ProからAZ-GTiに接続し、SharpCapからSynScan Proを操作できるように接続します。

ところがです、いつぞやのSharpCapのプレートソルブ関連の大幅アップデートらへんのことだと思うのですが、AZ-GTi側の恒星追尾をオフにしてもどうもディザー信号がきちんとモータまで届いているようなのです。

具体的にはSharpCapの右パネルの「望遠鏡制御」のところを見るのですが、AZ-GTiが恒星を追尾していると「方位」「高度」「赤経」が動き続けます。AZ-GTiが恒星を追尾を止めると「方位」「高度」は止まり、「赤経」のみ数値が動き続けるようになります。ここで SWATに恒星追尾を引き渡すと、ここまでのAZ-GTiの代わりにSWATが動き出し実際に星を追尾してくれるようになります。この状態でも、SharpCapの「望遠鏡制御」のところの矢印ボタンを押すと、信号はきちんとモーターまで行き、見ている方向を変えることができます。その際「方位」「高度」の数値もモーターへの信号に連動して動きます。ここまでは以前にも試した結果と同じでした。

ここでSharpCap上でライブスタックを立ち上げてディーザーをオンにします。以前はディザーをしようとしても実際にはモーターまで信号がいかなくて、画面は全く揺らされないことは確認していました。でも今回「望遠鏡制御」の数値を見ている限り、ディーザーのたびに「方位」「高度」の数値が動いているのです。以前この数値が動いていた記憶は全くない(動いていれば必ず気づいていたはず)ので、勘違いでなければ何か状況がわかっているはずです。少なくとも、現段階でこれらの動いている数値を信じるならば、ディザーはきちんと作動していることになります。


夜のテストは全くうまくいかず

昼間に試しただけでは、PC上に出てくる数値は動いていても実際の撮影画面が動くかどうかは見ていないので、まだ本当にディザーが動いているかどうかの確証は持てませんでした。なので夜になって実際に試してみました。ところがディザーを試す以前に、かなりひどい状況にぶち当たってしまいました。

IMG_9758

具体的には、一眼レフカメラ(EOS 6D)をSharpCapに繋ぎ、AZ-GTiで操作しました。CMOSカメラでなくてもSharpCapに繋ぎさえすれば、一眼レフカメラで極軸調整もプレートソルブも、全然問題なくできます。


今回も極軸調整をFS-60CBと6Dの画面で直接やり、初期アラインメントも6Dでプレートソルブを使うことで簡単に済ますことができました。
スクリーンショット 2024-08-03 215020_cut

その後、ターゲット天体を導入し、SharpCap右パネルの「望遠鏡制御」の矢印ボタンを使って位置決めをします。ここら辺までは問題ないです。

次に追尾をSynScan ProからSWATに渡して撮影に入る準備をします。ところが長時間露光を開始すると程なくしてSynScanとの接続がダメになります。ディザーをするためにはライブスタックモードにしなくてはいけません。 この接続トラブルはライブスタックに関係なく、ライブスタックをする以前に露光時間を分のオーダーとかに長くした時に発生するようです。SharpCapの「望遠鏡制御」のところでAZ-GTiからの位置情報が数値で見えるのですが、SWATで追尾しているので「赤経」の数値だけが増えていきます。最初はスムーズに数値が変わるが見えるのですが、徐々に数値が飛び飛びになり、最後は止まってしまって、それ以降は接続は切れているような状態になります。処理に時間がかかっているような印象で、何度やっても同じ状況になります。最初はCPUの負荷か何かと思って、SynScanの再起動、SharpCapの再起動、最後はPCまで再起動でもダメでした。

実はSharpCapとSynScan Proとの接続不安定な時は、SynScan Proを管理者権限で立ち上げると安定になるという情報があります。知り合いが試してみて、管理者権限での起動がものすごく効いて、実際にかなり安定になったという例を聞いています。ですが、今回の場合は管理者権限も効果がなく、状況は変わりませんでした。

次に一眼レフカメラが原因かと思って、ASI294MC Proに変えたり、さらにはPCが何か原因の可能性があるとも思い、別PCを持ってきて試しましたが、いずれの場合も最初はプレートソルブまで含めて順調なのに、長時間露光(180秒)の撮影の途中でSynScanとの接続がダメになり、その後はPCを再起動するまでは何をやってもダメです。ダメというのは、SharpCapからSynScan Proになんらかの信号を送った時に接続エラーが表示されるということです。PC再起動後はまたプレートソルブもできるようになりますが、長時間撮影開始でダメになると言うのを何度か繰り返しました。というわけでこの晩はここで諦めましたが、これまで電視観望で同じような状況にはしていたので、もしかしたら長時間露光がダメったのかもしれません。電視観望ではせいぜい10秒露光が最長ですが、今回は撮影ということで3分露光にまで伸ばしています。長時間露光が何か負担になっているのかもしれません。

06
長時間露光を開始すると毎回こんなエラーが出てしまします。 


昼間に原因究明

次の日、昼間に今一度、全く同じ設定で試しましたが、なぜか今度は何をやっても安定します。カメラを変えようが、PCを変えようが、昨晩のトラブルは何だったんだというくらい、どうやっても不安定な状況を再現できません。3分の長時間露光でも全く問題がないです。一体何が問題なのでしょうか?

違うことといえば、昼間で実際に星が見えないので、プレートソルブはしていませんし、ライブスタックも星の位置合わせをせずに単に重ねていっているだけす。


再び夜に試して光明が!

その晩、昼間の状態を再現すべく、試しにプレートソルブなしでマニュアルアラインメントしてから長時間撮影してみたら、何と完全安定です。その後すぐに曇ってしまったので、プレートソルブありで不安定になるかどうかのテストができませんでしたが、長時間露光そのものは大丈夫ということはわかりました。ディザーも実際一回動かすことができて「望遠鏡制御」のところの「方位」も「高度」も数値が変わったのですが、肝心のディザー前後の撮影画像比較での動きがあったのかなかったのか、あったとしても移動量の設定値が小さ過ぎたようで、確証が得られるほどの揺れは確認できませんでした。

雲でこれ以上試せないので、この日はこれで撤収ました。今の段階でディザーが出来ているかどうかの判断はできていません。でも見込みはありそうです。今後もテストを続けたいと思います。

(2024/8/17追記: ディザー撮影成功しました!)



日記

あまりブログ記事にならない細かいネタも多いので、久しぶりに日記としてまとめて書いておきます。

お盆の季節になりました。8月7日の富山環水公園の観望会に引き続き、8月10日も高岡市のおとぎの森で観望会がありました。2週連続になります。初参加の観望会で、これまでは他の予定と重なることも多く参加できてませんでしたが、今年はお盆の休暇の初日で少し余裕もあるので参加することに決めました。機材は先週とと同じく電視観望で、20時20分頃に月によるスピカ食があるとのことで、外部モニターも用意して大勢で見ることができればと思っていました。夕方のまだ明るい頃は月もが見えていたのですが、暗くなり始めて機材も準備もできたころには空一面が曇ってしまい、それ以降は星も明るい月さえも、カメラを通した電視観望でも全く見えないくらいの雲になってしまいました。お客さんは100人以上と、かなりたくさん来てくれていたので、とても残念でした。もうこうなるとどうしようもないので、天文の話やクイズをずっとしていました。一番受けたのはASI294MCで暗闇が見えるかどうかで、カメラの周りには子供達が群がっていて画面に映る自分の姿を見て大騒ぎでした。

次の日の8月11日は自分の出身高校の天文部の合宿に参加させてもらいました。場所は奥飛騨で、富山からだとそう遠くない距離なので気軽に参加できました。昨年の12月にも豊田市元気村の合宿にも参加させてもらったのですが、それに引き続きとなります。年末の合宿もそうでしたが、残念ながら今回も天気には全く恵まれず、星一つ見ることもできませんでした。なんでもコロナ後にやっと復活した1年前の同じ場所での合宿の時は台風で、ここ最近の合宿は天文部としては非常に厳しいとのことでした。私は日を跨ぐ前くらいに帰路につきましたが、次の日は神岡の道の駅にある「カミオカラボ」まで行くそうです。でも夜の天気予報はあまり良くありません。ペルセウス座流星群なので、少しでも見えることができればいいのですが。

実は私も奥飛騨まで行く途中にカミオカラボに寄っていきました。
IMG_9803

IMG_9810
こんな面白い写真が撮れます。


とにかく最近は天気が全然ダメです。昼間はまだ比較的晴れているのですが、夜になるとドン曇りというパターンです。ペルセウス座流星群も自宅から雲の薄いところで1個だけ見ましたが、とても撮影とかするレベルの天気ではないです。せっかくの休暇でまだ月が昇っている時間もかぎられているので、なんとかお盆中に長時間撮影をしたいのですが、天気予報を見る限りまだしばらくは難しそうでうす。


このページのトップヘ