ほしぞloveログ

天体観測始めました。

タグ:SharpCap

本記事は、一連のSWAT+AZ-GTi=SWAgTi (「スワッティ」gは発音せず) の関連記事になります。




目的

今回は、
  1. SharpCapの極軸調整を一眼レフカメラでやれるかどうか?
  2. プレートソルブを一眼レフカメラでできるかどうか?
という2つのことに挑戦したいと思います。

元々の動機は「SWATユーザーには一眼レフカメラを使って撮影している人が多い」という、開発元のユニテックさんからの情報です。せっかくAZ-GTiで自動導入ができるので、一眼レフカメラでもプレートソルブができないかと考えたことが始まりです。ついでにプレートソルブができるなら極軸合わせもできるのではないかと考えました。

本当は、胎内星まつりのSWAgTiの実演でEOS 6Dで試すところを披露したかったのですが、そこまで全く辿り着かず、いつもやっているCMOSカメラでさえ極軸調整がうまくいかなかったので、その後自宅に帰ってからやっと試すことができたというわけです。胎内で期待されていた方がいましたら、申し訳ありませんでした。この記事で代替とさせてください。


セットアップ

実際のセットアップです。鏡筒はFS-60CBにマルチフラットナーで、鏡筒とフラットナーの間にサイトロンのDBP(Dual Band Pass)フィルターを入れています。そのため恒星が多少暗くなり、極軸調整でもプレートソルブでも影響があるかもしれません。それでも簡単のために撮影時の設定を崩したくないので、今回はフィルターを外したりせずにそのまま試すことにしました。一眼レフカメラとしては天体改造済みのEOS 6Dです。これらをSWAT+AZ-GTiのSWAgTiに載せます。SWAgTiはいつものようにGitzo製のバサルトのミニ三脚に載せます。

鏡筒とカメラである程度重くなっているので、ホームセンターで買った12mmのネジが切ってある金属棒をAZ-GTiにつけ、そこにウェイトをつけています。胎内でユニテックさんにデモを見せてもらったように、SWATの回転方向のバランスをきちんと取らないとSWATのギヤに大きな負担がかかることを学んだので、今後はウェイトを使って赤経方向のバランスを取ることを心がけるようになりました。CMOSカメラの時はウェイト側が重過ぎてバランスが取りきれていなかったのですが、一眼レフカメラになってちょどバランスが取れる範囲になりました。

IMG_8504


極軸合わせ

まずはSharpCapで6Dを認識させることからです。今のSharpCapはASCOM経由で一眼レフカメラのかなりの機種を接続することができます。



ポイントは、SharpCapで一眼レフ用のASCOMドライバーを立ち上げる際には、カメラをケーブルで接続をしない状態で行うか、ケーブルで接続をしてもカメラの電源を入れないことです。こうすることで、エラーなど出ずに下の画面のように設定画面でカメラの設定をすることができます。

11_canon

ISOですが、設定画面で設定しものが反映されないことがあるようなので、その場合は一度接続ケーブルを外し、カメラ本体側で操作できるようにしてから設定します。

設定が完了したらカメラを接続して、さらにカメラの電源を入れて、上記設定画面の「OK」ボタンを押します。「カシャーン」とシャッターが上がる音がして動作開始です。おそらく初めて繋ぐときはライブビューモードになっているので、自動的にSharpCapでカメラからの撮影画面が出ますが、これだとシャッターを切り続けてしまい落ち着かないので、すかさず画面右上の「ライブビュー」ボタンを押して以下の画面のようなスティルモードにしてシャッターを切り続けるのを止めます。

10_still

露光時間を設定しますが、今回は16秒で試してみました。シャッター回数が増え過ぎず、一つの動作をあまり待たないくらいの時間という意味です。

ここからはSharpCap上で普通に極軸調整をします。どうやら極軸調整を選ぶと自動的にライブビューモードに切り替わるようです。なので、少なくともここに来るまでに適した露光時間にしておいてください。

12_polar
極軸合わせでは自動的にライブビューモードになるようです。

ここからは単に、一コマ一コマに16秒かかる極軸調整になるだけです。星の認識も問題なくできます。
01_polar

通常通りNextを押して途中SWAT側で赤経つまみを緩めて90度回転し、どれだけずれているか計算してもらいます。下の画面は2度くらいずれてますね。
03_polar

あとは三脚の足の伸び縮みと、三脚をずらしての水平方向の回転で調整します。今回は下のように、30秒角程度まで合わせこむことができました。ここまで合わせると、ずれは4分間かかっても0.3秒程度になるので、今回ターゲットとしている3分間程度の露光では極軸のずれによる星像の流れは完全に無視できるレベルです。おそらく機材のたわみによるズレの方が支配的になってくると思われます。

07_polar

でも露光時間が長いので合わせこむ回数にどうしても制限ができてしまいます。あまり突き詰めなくても、3分角程度まで合わすことができれば十分でしょう。これでも最大で4分間で3秒角程度ずれていく程度なので、SWATの精度と同等くらいになります。


極軸合わせのまとめですが、試してみた結果、露光時間が長いので少し時間はかかりますが、それ以外はCMOSカメラでの極軸合わせと何ら変わりはなく、一眼レフカメラでも十分に極軸を合わせられることがわかりました。

ちなみに、最初はASCOMドライバーでライブビューモードを選び、動画モードで極軸合わせができればと考えていたのですが、感度が全く足りませんでした。そもそも動画レベルなので露光時間が1秒より遥かに短くしか撮れていないことが原因です。1等星クラスの明るい星なら見えるかもしれませんが、ほとんどの星はSharpCapの画面上で見ることができません。

bad
ライブビューモードは使い物になりませんでした。 


プレートソル

極軸合わせでうまくいったので、気を良くして次はAZ-GTiでの初期アラインメントです。ここではちょっと冒険をしてAZ-GTiを使ったプレートソルブを試してみます。

SharpCapからAZ-GTiまでの接続ですが、まずAZ-GTiはSWATの上に乗っかっていて、PC上で立ち上げたSynScan Proから WiFiで接続されています。接続時には赤道儀モードを選んでいます。SharpCapからはASCOMドライバーを介してSynScan Proに繋げます。

この際気を付けることは、SharpCapとSynScan Proがきちんと接続されているか確認することです。きちんと接続されると、SharpCapのコントローラ部に今どちらの方向を向いているかの数字が表示され、その数字が時間とともに動いている様子が見えます。数字が動いていなかったり、0付近になっているとか実際に向いている方向と明らかに違う数字が出ている場合はうまく接続されていません。この場合は、PC上のSynScan Proを一旦閉じて、再度立ち上げてから繋ぐとうまく接続できるかと思います。うまくいかない場合は、PC上のSynScan Proの緯度経度情報を確かめてみてください。スマホやタブレットで繋いだときはGPSがあるので自動的に緯度経度情報は取得できますが、PCは通常GPSがないので緯度経度情報がうまく設定されていないかもしれません。

プレートソルブの設定はSharpCapの設定画面のプレートソルブタブから行います。

14_ps_gauss

私はASTAPとAll Sky Plate Solver(ASPS)を併用していますが、普段はほとんどASTAPです。まれにASTAPでうまく解決できなくてASPSだとうまくいくことがありますが、ASPSのほうが少し余分に時間がかかります。あと注意は、焦点距離をきちんと入れておくことでしょうか。自分の機材にあった焦点距離を大体でいいので入力しておきます。ここが大きくずれているとどうやってもプレートソルブはうまくいかないです。

設定画面には、ズレを計算した後にどうやってAZ-GTiに返すかですが、4つのオプションがあります。以前は2つ目のオプションのきちんと同期するところまでやっていたのですが、最後のAZ-GTiに返すところでうまく動いてくれないことも多くて、最近は4つ目のオプションの「マウント位置をオフセットして、天体を中央に配置する」を選ぶことが多くなりました。

とりあえず実際にプレートソルブをやってみましょう。まずはPC上のSynScan Proから初期アラインメントをします。赤道儀の極軸がかなり合っているので、ワンスターアラインメントで十分でしょう。適当に星を選びます。今回はアルタイルで試しました。一番最初に初期アラインメントで自動導入した後、下のように「マニュアルで中心に」と出ますので、この時にマニュアルで合わせる代わりに上で書いた「4つ目のオプションをえらんで」プレートソルブを使います。

22_PS_ok

うまくいくと、赤道儀が見ていると思っている方向と、実際に今見ている画面から計算した方向のずれが角どで上の緑のバーのところに表示されます。
20_PS_ok

その後、自動的にターゲットの星が真ん中に来ます。
21_PS_ok

このようにターゲット星が真ん中に来て、赤道儀が見ていると思っている方向と、実際に今見ている方向が一致している状態で、SynScan Proの初期アラインメントを完了してください。これで同期が完了し、これ以降は、(SWATの水平出しに依りますが)自動導入でターゲット天体がほぼ正しい位置に来るはずです。


うまくいかない時:
実は今回、初期アラインメントのテストにあたり、一番最初アルタイルでなくベガを選びました。実際初期導入すると、すでにベガが画面の端の方に入ってきました。ところが真ん中に持っていこうとプレートソルブをかけますが、なぜか全然位置を解決できません。ASTAPもASPSも両方ともダメです。一眼レフカメラなので何か弊害があるかと思い、露光時間、ISO、その他各種設定を色々いじっても全くダメです。もしかしたら本当にダメなのか...と、諦めかけていたのですが、ターゲットをベガからアルタイルに変えたら、一発で解決しました。しかも露光時間など多少設定を変えても全部きちんと解決してくれます。もしプレートソルブがうまくいかない場合は、早々に諦めてべつのターゲットにしてみるというのも手なのかと思います。


まとめ

この日は月も明るく、平日だったので、プレートソルブのテストまでで、撮影は敢行しませんでした。極軸調整もプレートソルブも、SharpCapを一眼レフカメラで使う時特有の、ライブビューモードとスティルモードをきちんと意識して使い分けることで、CMOSカメラと比べてもほとんど遜色なく使うことができるとわかりました。この際、露光時間を16秒としたのですが、やはりこのくらいが適当かと思います。短かすぎると操作性はよくなりますが、シャッターを切りまくるのでメカニカルシャッターの寿命が気になりますし、長すぎると操作性が悪くなるかと思います。

次は実際の撮影をどうするかですが、月のない天気の良い日を待ちたいと思います。SharpCapで撮影すべきか、これまで通りBackYardEOSを使うべきか、それともソフトなど使わずにシャッターを切るだけにするか。まだちょっと迷っています。


今回の目的はSWAgTi君を使って、ノータッチガイド撮影でディザーをすることです。

でも結論だけ言うと、現段階の環境でノータッチガイドで、ディーザーだけ追加というのは難しいと言うことがわかりました。どんなことを試したか、実際の撮影に即して書いておこうと思います。


たわみの影響

前回の記事で、極軸の精度について話しました。でも実際に撮影を始めてみると、合わせたはずの極軸精度よりも、一方向に大きく流れていってしまうことがわかりました。

原因の目処はついています。機材の撓み(たわみ)によるものです。ここで言う撓みとは、一般的なガイド撮影で問題となる「鏡筒とガイド鏡の相対的な撓み」のことではなく、「鏡筒、ガイド鏡、AZ-GTi、SWAT、三脚など、ありとあらゆるところで起きる撓み」のことで、影響は遥かに大きいです。

ガイド撮影の場合は、ガイド鏡で見た星の初期位置からのずれを赤道儀に返すことで、撮影鏡筒の向きがずれないよう補正します。それでも、ガイド鏡の固定が十分でなかったりすると、その撓みによってガイド鏡と撮影鏡筒の相対的なずれが発生して、撮影鏡筒での星像の流れに繋がります。でもこのズレは高々相対ズレに起因することなので、実用上はそこまで大きくはないです。それでも数時間とかに及ぶ長時間撮影では無視できない量になり、縞ノイズになることがあり、ディーザーを使い撮影途中で少し方向を変え、縞ノイズになる原因のホットピクセルやクールピクセルを散らしてやることにより、スタック画像ではほぼ影響がなくなります。

今回のノータッチガイドの場合の撓みは、撮影中に起きたどの場所で起きた機材の撓みもそのまま直結して星の流れになっていくので、遥かに影響が大きくなります。その大きさをざっくりですが見積もってみました。使ったのはSharpCapの曲軸調整機能です。

まず、使う機材を設置して、ガイド鏡を北に向けて、通常のように極軸調整をします。今回はFS-60CBの焦点距離が370mmと大して長くないことと、カメラがUranus-Cでそこそこセンサー面積が広いので、ガイド鏡を使わずに撮影鏡筒で直接極軸調整をしました。前回の記事でも書きましたが、微動雲台とか使わなくても、三脚の足の伸び縮みと水平方向の移動で、1分角程度の精度で合わせることは十分に可能です。調整の際に、赤道儀の赤経方向を90度程度傾けることで、カメラで見た製造の位置を比べ極軸方向とのずれを計算します。今回も下のように1分角以下程度、42秒角の精度で調整することができました。

04_polar_after

極軸調整が終わった直後は、最初の位置に比べて鏡筒が90度赤経方向に傾いた位置にあります。今回、この位置から再度極軸調整をスタートします。再びずれの計算のために90度赤経方向に回転し、元の位置に戻します。その結果が以下になります。

05_polar_after_right

本来、たわみなどなければ最初に調整した時と同じくらいの値の1分角以下程度が出なければなりません。今回は3分角程度のずれが出てしまっています。何度か試しましたが、毎回有意にこれくらいずれます。反対側に90度回転させて測定した場合は5分角位のズレになることもありました。これは90度赤経方向に回転した時の撓みの量相当のずれをそのまま表していることになるはずです。

というこうこは、撮影して赤経が回転していくにつれ、6時間で3分角から5分角はずれてしまうことになります。STAgTi君での撮影時間を仮に2時間としても、1-2分角位はずれてしまということです。前回計算したように、カメラの1ピクセルが1.6秒角に相当するので、40ピクセルから80ピクセルくらい、もし左右両方向の回転のずれを合わせると120ピクセルくらいずれる可能性があり、それくらいの長さの縞ノイズが出ても全くおかしくないことになります。

例えば2時間程度何もいじらずに撮影した実際の画像はライブスタック画像は以下のようになり、盛大な縞ノイズが出ていることがわかります。縦方向に典型的に120ピクセルくらいの縞ノイズになっていて、オーダー的には撓み起因のずれで縞ノイズになっていると考えておかしくなさそうです。

Stack_16bits_21frames_3780s

この撓みがどこから来ているのか?三脚なのか、SWATの固定なのか、SWATとAZ-GTiの固定なのか、鏡筒の載せ方が悪いのか、はたまた全体で悪さをしているのか?今後調査して、弱いところが見つかったら補強していく方向になるかと思います。


撮影時のテクニック「DECモード」

ここで一つ、SWAgTiでの撮影し際してのテクニックです。ユニテックさんが前回の「ほしぞloveログ」の記事を紹介してくれた際に紹介してくれました。

SWATは電源ケーブルを繋ぐことですぐに動作体制に入りますが、その際赤経方向に一旦大きくズレ、やがて戻ってくるキックバックのようなことが起きます。元に戻るまで数十秒待つことになります。これを防ぐためには、あらかじめSWATの電源を入れておいて、その際に追尾モードを「DEC」に合わせておけば追尾をしないでそのまま止まってくれます。AZ-GTiの追尾をオフにする際に、この「DEC」を「STAR」にすれば、キックなしでスムーズに移行できるとのことです。

実際私も試してみましたが、撮影の際の画面を見る限りジャンプの様なものは全く見えずみ、スムーズに切り替えることが出来ました。


ディザーで縞ノイズを回避したい

今回の記事のメインの目的です。撮影する際にディザーを試してみます。

すでにSWATでの追尾にしてあり、AZ-GTiはSynScan ProとASCOM経由でSharpCapと接続されていますが追尾は止めてある状態から始めます。


1. SharpCap+AZ-GTi

SharpCapの設定でガイドのタブを選び、3つあるガイド検知方法のうちの一番下のASCOMを選びます。ちなみに1番上がphd2で、次がMGENです。3つ目を選ぶことで、ガイドソフトがなくてもディザーをすることができるようになります。

02_gudesetting


SharpCap上でガイド(ガイドソフトが有り無しにかかわらず)をする場合はライブスタックモードにする必要があります。ここらへんがSharpCapがイマイチ撮影に対してはちょっと?なところなのですが、まあこういうコンセプトということでとりあえずはよしとしましょう。

さて、撮影開始という意味でライブスタックを始めますが、ここで問題発生です。なぜかAZ-GTiの自動恒星追尾が勝手にオンになるのです。なので、再度マニュアルでAZ-GTiの自動追尾をオフにして、ずれた位置を少し合わせ直して、ライブスタックをクリアして一から撮影を始めます。ディザーは3枚おきにする様に設定しました。SharpCapのライブスタック画面のガイドタブのステータスを見ていると、ディーザーをしようとしているように見えます。でも10枚ほど撮影してから画像をチェックしても、全然ディザーされてる様子が見えません。

いろいろ試してわかったことは、ライブスタックを始めるときに「ガイドをするように選択している」と、勝手にAZ-GTiの「自動追尾がオン」になること、それをマニュアルであえてオフにしたりして「自動追尾がオン」にならない限りディザー信号はAZ-GTi側に行かないことがわかりました。

言い換えると、SharpCapからSynScan Proに信号を送る限りでは、AZ-GTiの自動追尾をSWATに切り替えた状態で、ノータッチガイドでディザーをする方法はないということです。


2. PHD2を使い、カメラ赤道儀共にシミュレーター

気を取り直して、次の方法を考えます。返す先がSynScan Proでだめなら、他の場所にと考えPHD2を立ち上げました。この場合、SharpCapの設定でガイドのタブの3つあるガイド検知方法のうち、一番上のPHD2を選びます。

03_guide_setting

ガイド鏡は使っていないので、PHD2は単なる擬似ガイダーとして使います。とりあえずはPHD2の設定でカメラも赤道儀もシミュレーターを選びます。SharpCapのディザー設定で、ディザーは3枚おきにするようにしました。3枚目になるとSharpCapはディザー信号をPHD2に送り、PHD2も反応していますが、AZ-GTiには信号が行かないようで、ディザー時にきちんと画角がずれている様子が全く確認できません。返す赤道儀がシミュレーターなので理解できる結果です。


2. PHD2を使い、カメラはシミュレーターだが、赤道儀はSynScan Proに設定

次に、カメラはシミュレーターで、赤道儀はSynScan Proを選び、実際にAZ-GTi信号を返すようにしてみます。確認ですが、ディザー信号だけ返したくて、SWATの精度を生かすためにガイド信号は返したくないです。

まず、PHD2の設定でガイド信号を返さないオプションを選んでみました。Advanced Setupの「guiding」タブの「Enable mount guide output」のチェックマークを外します。ですが、この状態だとSynScan Pro側に信号が全く行かないようで、ディザー信号も返すことができず、ディザー動作はしないようです。

次に、「Enable mount guide output」にチェックを入れ直して、ガイド信号を返すようにします。この場合も、ディザー信号のみ返してガイド信号は返したくないので、Agrを最初の0、MinMo(ズレがこの値を超えたら信号を赤道儀に返す)を最大の20、Hysを最小の10などとします。

04_PHD2_screen
ダミーカメラでSynScan Proに返しているため、
何度かディザーをしたあとはターゲット星が全然ずれてしまいます。

これは短時間では一見うまくいきます。3枚撮影するごとにディザー信号のみSynScan Proに返すようにしたので、3枚おきにディザー信号がAZ-Gtiまで行き、実際に指定したピクセル(上の設定だと50ピクセル)分だけ動きます。目で見てその動きがリアルタイムでわかるので、やっとうまくいったと喜んでいました。問題はそのまま長時間撮影が続いた場合です。疑似カメラのターゲット星からのズレがまだ小さい場合はいいのですが、そのズレが何度かディーザーを繰り返しある程度大きくなると、最大時間まで待って(上のSharpCapの設定だと20秒間)再び3分露光が始まります。さらに、あまりにターゲット星とのズレが大きくなると、PHD2の方でガイドが始まってしまい、これは実際にSynScan Proに信号を返していくので、その後どんどんズレが大きくなり、カメラは疑似カメラのままでフィードバックされたことを検知しないので収束することなく、最後破綻します。

あと、この過程で気づいた最大の問題は、AZ-GTiの精度がSWATと比べると悪いために、ディザー信号をAZ-GTiに返すと大きく揺れ過ぎてしまうことです。そのため、十分な緩和時間を取る必要があるのですが、上の20秒とかでは短すぎるようで、分単位の緩和時間が必要そうな様子です。


今後どうすべきか

今回はここで詰みとなりました。PHD2のパラメータはもう少し探れば何か見つかるかもしれませんが、大原則でディザーだけ返すというのはダメそうでした。その後、2軸ガイドとかも試したのですが、これはまた機会があったら記事にします。

ここまで試した上で、必要なことを考えてみます。とにかく大事なことは、ガイド信号を返さずに、ディザー信号だけ返すようなソフト側の対応です。今のところ一番見込みがあるのが、ASCOM経由でSynScan Proに信号を送る方法です。SynScan Proの恒星時追尾だけオフにして、SharpCapからのディザー信号をSynScan Proが受け取って実際にAZ-GTiを動かすことですが、上述のように恒星追尾をオフにするとディザー信号は伝わらないようで、今のところこれはできません。それでもSharpCapの矢印ボタンには反応するので、この矢印ボタン相当のところに返すことができれば、今回の目的は達成できそうです。

PHD2は触ってみた限り、そもそも外部から来た信号とPHD2から出す信号の区別がつかないようで、ディザー信号だけAZ-GTiに出すというのは根本的に難しいようです。

それでも原理的にソフト側で解決できる問題ではあるので、今のところはいつか解決するのを期待することとします。


せっかくなので仕上げてみる

ディザーは諦めたのですが、3日ほどに渡ってM27を色々試しながら撮り溜めた画像があり、それぞれバラバラの位置で撮影しているので、ある意味ナチュラルディザー状態になっています。せっかくなので仕上げてみます。


masterLight_180.00s_ABE124_SPCC_BXT_MS_NXT3
  • 撮影日: 2023年7月17日22時18分-23時16分、7月22日1時40分-2時6分、7月22日21時55分-23時39分
  • 撮影場所: 富山県富山市自宅
  • 鏡筒: TAKAHASHI FS-60CB+マルチフラットナー(f370mm、F6.2)
  • フィルター: サイトロン Dual Band Pass (DBP)
  • 赤道儀: SWAT+AZ-GTi
  • カメラ: Player One Uranus-C(常温)
  • ガイド: なし
  • 撮影: SharpCap、bin1、Gain 200、露光時間3分x57で総露光時間2時間51分
  • Dark: Gain 200、露光時間3分、常温、64枚
  • Flat, Darkflat, Gain200、0.05秒、64枚
  • 画像処理: PixInsight、Photoshop CC

ある程度長時間連続で位置をずらさずに撮影した分の縞ノイズは多少なりとも出てしまいますが、画像処理でなんとかできるレベルです。今回はM27の周りの淡い羽部分が少し見え始めるくらいまで出すことはできました。

今回の撮影は富山の住宅街での自宅撮影なので光害はそこそこあります。これ以上出したい場合は、もっと鋭いワンショットナローバンドフィルターを使う、ナローバンドとモノクロカメラで撮影する、口径を大きくする、露光時間を伸ばすなどの工夫が必要になってくると思います。また、ダークノイズに関しては非冷却カメラはどうしても不利で、特に夏場の暑い夜はかなりのノイズが出ていることが1枚ショットの画像を見るとよくわかります。冷却のためのケーブルは増えてしまいお気軽撮影からは少し遠くなりますが、夏場で淡い天体を撮影する場合は冷却カメラの恩恵は無視できないでしょう。

今のところオートでディザーをする方法は見つかっていないので、縞ノイズがどうしても気になる場合は、少し面倒ですが、適時LiveStackの露光を一時停止して、マニュアルでランダムに位置を少しずらしてやれば、気にならないレベルに持ってくることができると思います。

SWATとAZ-GTiの組み合わせのSWAgTiというお気楽撮影に、少しだけマニュアルディザーをするという工夫を加えるだけで、ここくらいまでは出すことができることがわかってきました。


まとめ

結論としては、今のところノータッチガイドで撮影すると、どうしても縞ノイズが出てしまいます。ディザーはソフト側の対応が必要そうです。あと、AZ-GTiとの精度差があるので、十分な緩和時間をとることです。

マニュアルディザーである程度回避できるのですが、何かもっと簡単な方法はないのか?どうなるSWAgTi...



寒冷地でのSWAT

ユニテックさんとやりとりしていて、また面白い情報を聞くことができました。もしかしたら興味があるかともいるかと思いますので、共有します。SWATの寒冷地での使用についてで、個別で対応してくれるかもと言うことです。以下、ユニテックさんのメールから抜粋です。

「ちなみにSWAT用のグリスは-50℃に対応したものを使っています。ただし-50℃対応はグリスメーカーの仕様書での値でSWATの動作を保証しているわけではないです(試したことがない)。公称してませんが、実用最低温度は-10℃程度(自分で試した値)としています(-20℃で動いたという報告はあります)。

ただしボールベアリングは汎用のシールド型なので、-20℃くらいが限界と思います。寒冷地仕様の場合は、開放型のボールベアリングにして、上の-50℃対応のグリスにします。金属の収縮率の違いもあるので、極低温動作を保証してトラブルになると大変なので…。

寒冷地仕様は各部クリアランスをわずかに大きくつける(熱収縮を考慮して)ので、遊びが大きくなるデメリットもあり、個別に希望した方のみの対応です。こういった小回りが効くのは手作りの弱小メーカーだからですね。(笑)」

とのことです。もし寒冷地で使うことを想定している場合は、個別に相談してみるのがいいのかと思います。





 
 
 
 
 

先週末の観望会の電視観望でプレートソルブがうまくいかずに大敗を喫したのですが、その原因を調べました。




機材など

一例ですが、私が使っている機材を今回の検証の前提条件として書いておきます。必ずしも同じ状況にしなくても、同様のトラブルはありえると思いますので、参考にしてください。

  • ハードウェア: 鏡筒(FMA135)、CMOSカメラ(Uranus-C)、AZ-GTi or TRAVERSE、三脚、PC(Surface 8, Surface 9, StickPC)
  • ソフトウェア: OSはWindows 10 or 11、SharpCap 4.1、SynScan Pro 231 or older、ASCOMプラットフォーム 6.1、SynScanアプリ用ASCOMドライバー 1.31 or 1.30、カメラドライバーなど

状態:
  1. AZ-GTiをスマホなどのSynScan Proを使って操作する準備ができている。
  2. PC上にSharpCapがインストールされていて、電視観望などができる準備ができている。
  3. PC上にSynScan Proがインストールされ、AZ-GTiに接続して操作する準備ができている。
  4. PC上にASTAPやASPSなどのプレートソルブ環境がインストールされている。
  5. SharpCapからASCOMを介して、SynScan Proに接続する。
  6. SharpCapを使ってプレートソルブをする。
今回は特に1、3、5、6がトラブル箇所で、中でも3と5、特に5が不安定な箇所です。


最初に確認しておきたいこと

まず最初は基本的なところで、PC上のSynScan ProとAZ-GTiがWi-Fi経由できちんと接続されているかです。接続ができているかと思っていても失敗している、もしくは接続していても知らない間に接続が切れていることなどもよくあります。チェックすべきことは
  • PC上のSynScan  Proの「ユーティリティ」の「情報」を見て、きちんと数字が動いているか?スマホやタブレットだけで繋がっていることがあります。
  • スマホとPCの両方から同時にAZ-GTiに接続していないか?
  • PC上で二つ以上のSynScan  Proが立ち上がっていて、重なってAZ-GTiに接続していないか?
  • 観望会などで間違えて他人のAZ-GTiに接続していないか?SynScan  Proの矢印ボタンを押して、きちんと自分のAZ-GTiが回転するか見ます。
などです。ここまではバグとかの可能性はほとんどないので、自分の設定ミスの可能性が高いです。でもこれ以降は自分の設定ミスというより、バグに近いものがたくさんあることがわかりました。ここまでで、きちんとPC上のSynScan ProとAZ-GTiが接続されていることが、ここからのトラブルシューティングの前提条件となります。


トラブル1: SharpCapとSynScan Pro接続の不安定性

ここからはさらにややこしい状況で、この不安定性はバグの一つかと思われます。

現象
  • SharpCapからASCOM経由でAZ-GTi(実際にはSynScan Pro)に接続しようとするとエラーメッセージが出て接続できない。
  • もしくは一旦SharpCapから接続できても、SharpCap上の矢印ボタンからAZ-GTiが反応しない。
  • もしくはSharpCapから接続できていたものを一旦外して、再度接続しようとするとエラーメッセージが出て接続できなくなる。

エラー
  • エラーメッセージはASCOMドライバーからで、下のように接続先が存在しないとか言われる。
スクリーンショット 2023-06-21 204049


状況確認
  • PC上のSynScan Proの「ユーティリティー」「情報」から、方位などの数字が動いているかどうか見る。止まっていたら(Wi-Fiなどの問題で)すでにPC上のSynScan ProとAZ-GTiの接続が切れているので、特に前項を見ながら接続をきちんと確認する。
スクリーンショット 2023-06-21 204520
  • SharpCapからまだ接続されいるなら、SharpCapのタブの望遠鏡パネルの数字が動いているかどうか見てみる。止まっていたらすでにSharpCapとPC上のSynScan Proの接続は確立されていない。次の解決策を試す。
  • SharpCapとの接続が確立されていないなら、次の解決策を試す。

解決策
  • PC上のSynScan Proを立ち上げ直す。わざわざ画面上部をクリックして「接続を切る」とかをする必要はありません。そのまま右上のxボタンを押してバチッと閉じてしまっていいです。


トラブル2: プレートソルブした時に解がない

トラブル1までで、ShaprCapとSynScan Proとの接続はうまくいっているはずです。その後プレートソルブをしようとして、以下画面のように「プレートソルブに解がない」とか言われる場合は、それでも前提のSynScan ProとAZ-GTiの接続がうまくいっていないことが多いです。再度前項目をチェックするなどして、SynScan ProとAZ-GTiの接続を確立、チェックしてください。

次にチェックするのが、ShaprCapとSynScan Proとの接続です。普通は右パネルの「望遠鏡制御」のチェックボックスを押すて5秒くらい待つとチェックボックスが出て接続が確立されます。この時点でチェックマークがつかない場合はトラブル1などを見直します。問題はチェックマークがつくのに、実際には接続されていない場合です。

スクリーンショット 2023-06-21 204001
その証拠の一つが、上の画面の右下の接続状況を示すパネルです。接続のチェックマークがきちんと出ていますが、AZ-GTiからの数値の多くが0になっていて明らかにおかしいです。接続されたと見えて実は接続できていないケースで、バグの一つです。

最初接続されても、途中で接続が切れて、右下の接続状況を示すパネルの数値が止まってしまっている場合などもこのケースですが、これはバグというよりは例えばAZ-GTiの電池がなくなったとか、Wi-Fiがなんらかの原因で切れたとかの、ミスの部類になります。

解決方法ですが、とにかく右下の接続状況を示すパネルの数値がきちんと動き出すまで、PC上のSynScan Proを立ち上げ成すなどして接続を繰り返してください。どうしても上手くいかない時は、ASCMOMドライバーのバージョンを落とすなどして入れ替えたり、SynScan Pro のバージョンを落とすなどして入れ替えたりしたら途端に直るということを何度か経験しました。ただし、どのバージョンだと動くとか(3種のPCで試しましたが)法則は無いようで、どうも入れ替えたこと自体が何か書き換えて回避するような感じです。


トラブル3: プレートソルブが全く進まない

現象
  • プレートソルブすると「星が多すぎるので、露光時間を減らすとかしろ」とエラーが出て全く進まない。実際の画面の星の数はそんなに多くはない。
キャプチャ_02


状況
  • PC上のSynScan Proの緯度経度情報が大きく間違っている。
  • AZ-GTiが向いていると思っている方向と、実際の方向があまりに違う。

解決策
  • PC上のSynScan Proの緯度経度情報を確認します。「設定」の「観測位置」から確認できます。PCは普通GPSユニットはもっていないことが多いので、マニュアルで数値を入れる必要があります。スマホなどのコンパスアプリでその場の緯度経度の値を取得できるかと思います。
  • 緯度経度を合わせ直したら、再度一からアラインメントをやり直します。
  • 星が多いというのはおそらくノイズをカウントしてしまっています。エラーメッセージとは逆ですが、まずは露光時間を伸ばしてみてください。

トラブル4: 同期なしプレートソルブはできるが、同期ありだと何も進まない

これはかなりたちの悪いバグです。

現象
  • 同期なしのプレートソルブはうまくいくのに、同期ありだとプレートソルブすることなく「星が多すぎる」とエラーが出る。
  • ASTAPだと上記の状況だが、ASPSだと同期ありもとりあえずプレートソルブには進むが、次のトラブル5のように実際には同期できない。

原因
  • トラブル2のところでチェックしたように、右下の接続パネルの数値が動いていて一見うまく接続できているように見えても、実はまだ内部で接続がうまくいっていない。
  • PC上のSynScan用のASCOM driverが悪い。

解決策
  • トラブル2でやったように、ShaprCapとSynScan Proの接続を何度かやり直す。
  • ASCOM  driverのバージョンを変える。最新版(1.31)は明らかに挙動がおかしかった。1.30戻したらエラーは出なくなり、プレートソルブを継続するようになった

ハマってしまうと、一番時間がかかるところだと思います。不思議なことに、全くトラブルなしで行く場合もあれば、接続をし直して一度うまくいくとそれ以降は問題が一切出なくなったり、何度接続し直してもうまくいかずに、ASCOMドライバーのバージョンを一つ(1.31から1.30)に落としたら途端に上手くいったとか、とにかく現象も解決策も不安定なバグです。

あと、ドライバーなどの以前のバージョンを落とすには

https://inter-static.skywatcher.com/downloads/setup_synscan_app_ascom_driver_131.exe



https://inter-static.skywatcher.com/downloads/setup_synscan_app_ascom_driver_130.exe

などとウェブブラウザーのアドレスのところを書き換えてアクセスすると、そのファイルが存在すれば落とすことができます。

SynScan Proの場合は

https://inter-static.skywatcher.com/downloads/synscanpro_windows_238.zip



https://inter-static.skywatcher.com/downloads/synscanpro_windows_220.zip

などと書き換えます。


トラブル4: 同期しようとするが、実際には同期されない

これもかなり解決しにくいバグです。

現象
  • 同期なしのプレートソルブはうまくいって、同期ありだと何度ずれているという計算結果まで出てこれから同期すると表示されるのに、実際にはAZ-GTiが反応せずに同期されない。
  • ASTAPでもASPSでも同じ状況。
スクリーンショット 2023-06-21 211349
ここまで行くのに、なぜが経緯台側が動いてくれない。

原因
  • ASTAPでもASPSでも同じ状況なので、プレートソルブソフトの問題ではないと推測。SharpCapの信号を出す部分か、その信号を受け取る部分が悪いと推測。結局PC上のSynScan Proが悪かった。 

解決策
  • トラブル2でやったように、ShaprCapとSynScan Proの接続を再度やり直す。
  • SynScan Proのバージョンを最新版から戻したら解決した。

はっきりした解決策は、いまだに分かっていません。再接続を何度かやったり、PC上のSynScan Proを入れ替えると突然直ったりしました。

一つ言えることは、どうも全体的にSharpCapのバグというよりは、ASCMOドライバー、SynScan Pro側のトラブルという感触です。SharpCapのバージョンもいくつかえて試したりしましたが、何ら改善も悪化もしませんでした。なので疑うとしたら ASCMOドライバー、SynScan Proかと思います。あとAZ-GTiのファームウェアを赤道儀化をかなり昔にして以来アップデートしていないので、それが問題の可能性もありますが、今回は少なくともAZ-GTiの方はいじらずに、また、TRAVERSEのファームは最新に近いはずなので、あまり関係ないと思っています。


ASTAPは動かずASPSだと動く

うまくいくならASTAPのほうが速いので、私は普段ASTAPを使うのですが、ASTAPだと解まで辿り着かなくて、ASPSだと解決して同期までできるるということが何度かありました。でも不思議なことに、一度ASPSで同期までできると次はASTAPでも同期までできたりします。まだ感覚的な範囲なのですが、どうもAZ-GTiで認識している方向と、実際の方向に大きな差があったりするとASTAPだとうまくいかないことがあるような気がしています。でも気のせいかもしれません。とにかくASTAPでうまくいかない時はASPSも試してみてください。ちなみに、ASPSがうまくいかなくてASTAPだけ上手くいったことは今のところありません。なので普段使いでASPSでもいいのかと思います。ただし遅いです。


まとめ

もちろん、今回のトラブル回避が全てではなく、環境によっては再現できなかったり、違った振る舞いになることもあるかと思います。この情報を鵜呑みにするのではなく、トラブルに出会った場合は、こんなところが怪しい可能性があるという程度で参考にするのがいいのかと思います。基本的にトラブルさえなければ必ずプレートソルブは動きます。

今回は3台のPCで試したところ、とりあえず飛騨コスモス観望会で発生したトラブルを全て再現できて、無事にどのPCでも解決しました。解決する手段は必ずあるということです。でもその解決策もまだまだ不安定で、ソフトやドライバーのバージョンを変えるとしても最新版が必ずしもいいわけでもなさそうです。さらに古いものも、どのバージョンがいいかまでは検証できませんでした。途中でも書いたのですが、入れ替えること自体がどこかの値を書き直して、それで解決している可能性もあります。

今回の経験から、まずはSynScan ProとAZ-GTiの接続をきちんと確立すること、緯度経度情報が重要なことなどがわかりましたし、さらにはShapCapとSynScan Proの接続の確立が一番大切なこと。むやみやたらに最新版にバージョンアップしないことが重要なようです。もし安定に動いているならそれを保つこと。アップデートする場合は、必ず時間のあるきに行い、実際の星空でテストすることが大事かと思います。安定に動いていても、何かの拍子に不安定になることもあります。

今思うと、AZ-GTiだけなら安定だったのが、2台目としてTRAVERSEもつないだことが突然のトラブル発生の気もしています。最初TRAVERSEで発生したので、一度はTRAVERSEを疑いましたが、同じことがAZ-GTiで起ったのでTRAVERSEのせいというわけでも、かと言ってAZ-GTiのせいというわけでもなく、複数台を運用したことが問題の可能性が高いのかと思われます。おそらくですが、複数台でどこかのアドレスの値を共有しているのが原因かなと思います。

今回、一応全部解決はしましたが、明らかにバグと思われる部分もあるので、できればメーカーの方で複数台のテストも十分にしていただけると、ユーザーは助かるかなと思います。特に、SynScan Pro単体では問題には見えなくても、ASCOM経由で接続すると不安定さが露呈します。3台のPCで同様のトラブルが確認できたので、偶然とかではないはずです。AZ-GTiはかなりの数が出ているので、複数台を使っている方も少なくないかと思います。ちなみに、Celestronの赤道儀を3種をこれまで3台程度のPCで入れ替えて使っていますが、同様のASCOM経由の接続でのプレートソルブで、このようなトラブルは一度も遭遇したことはありません。


もう小海の星フェスの前のことになってしまいますが、11月8日の皆既日食で撮影した画像処理を進めています。これから数回に分けて、月食関連の記事を書いていきます。

今回はどういう方針かと、リハーサルの様子などです。


今回の方針

今回の皆既月食はかなり気合が入っていました。本番は11月8日ですが、その前の5日の土曜からいろいろ準備開始です。

前回の限りなく皆既に近い月食の時の撮影の反省から、いくつか方針を立てます。



前回のブログを読み直すなどして、今回の皆既月食で達成したい大きな目標を3つ立てました。
  • 一つのカメラで一つの設定だけだと、満月時と皆既時で輝度差がありすぎるので、写す時は毎回露光時間と輝度を変えて複数枚撮影すること。
  • 太陽時で撮影し、後から月の位置をずらすことなく、何枚か重ねて、地球の影を出すこと。
  • 天王星食を動画で撮影すること。
です。

具体的な撮影機材のセットアップは4種類考えます。
  1. 固定三脚の短焦点距離のカメラレンズで広角で、1分ごとに撮影し、月食の初めから終わりまでの全景を。
  2. FS-60CB+ASI294MCで赤道儀の同期レートを太陽時に合わせて、月が画面内で移動していく様子を撮り、あとで影で地球の形を出すもの。
  3. TSA120+ASI294MC Pro(常温)で、タイミング、位置など、被強に応じて自由に撮影するもの。
  4. 天王星食を拡大で撮影するもの。
としました。

これらを実現するために、当日までにリハーサルで特にやっておくことは、
  1. 1分の撮影に2つの設定(露光時間とゲインを自由に変えること)ができるかどうか試すこと。
  2. 満月の時の露光時間とゲインを各機器で確かめておくこと。
としました。


1つのカメラに、2つの設定での撮影テスト

特に1の、一つのカメラで複数の設定を切り替えながら繰り返し撮影というのはこれまでやったことがないので、本当にできるかどうかよくわかっていません。

試したソフトは4種。
  1. FireCapture
  2. NINA
  3. SharpCap
  4. BackYard EOS
実際に試してみて、これらのソフトの中でCMOSカメラと一眼レフカメラ両方に対応しているのは2と3ということがわかりました。さらに試していくと、例えば1分で2回、30秒ごとに設定を変えるようなことを繰り返し撮影できるのも2と3のみのようです。NINAはアドバンスド・シーケンス、SharpCapはシーケンサーというちょっと複雑なスクリプトようなものを使うと、設定を変えながら繰り返し撮影できるようです。

どちらでもよかったのですが、NINAで6Dを繋いで撮影したことがほとんどないことと、ガイドを使う必要はないので、今回はSharpCapを使うことにしました。実はNINAの方が「月の照度」というパラメータがあり、明るさがあるところになると条件を変えるというようなことができるようなのですが、複雑になりすぎるのと、当日は天気が良くないことが予想されたので、SharpCapで十分だったように思います。

SharpCapのシーケンサーはかなり直感的でわかりやすく、CMOSカメラの場合動画で撮影したいので
  1. 「Repeat」の中に
  2. 露光時間設定、ゲイン設定、キャプチャ開始、ウェイト、キャプチャ停止、ウェイト
  3. を露光時間とゲインを変えて2回書き
  4. ウェイトを含めた一回のループの時間を1分間になるように設定し、
  5. トータルの回数を4時間分の240回にする
というような設定になります。部屋の中で試しながら、色々スクリプトを書き換えて、上記の状態に行きつきました。保存ファイルは.ser形式になりますが、一つ一つのファイルサイズが大きくなりすぎないように、5秒間だけ撮影することにしました。それでも1つ800MB程で、4時間で240枚x2(30秒ごとなので1分で2枚)で約500個のファイルができることになり、トータル約400GB!となる予定です。

SharpCapのシーケンサーの設定はCMOSカメラの方が遥かに楽でした。一眼レフカメラの場合は静止画撮影になるので、「Still Mode」にして、キャプチャ開始とかではなく、1静止画をキャプチャとかになります。難しいのは、PCとカメラの接続がUSB2で転送が遅く、しかもそのダウンロード時間がばらつくので、1分間ごとのループにならないことです。そのため、ストップウォッチで計測しながら1分間になるようにウェイトを調整します。これも後から気づいたのですが、NINAのアドバンスド・シーケンスにはループする時間を直接指定できるコマンドがあるようです。次回からはもしかしたらNINAを使うかもしれません。でもNINAって大原則DSOが対象なんですよね。msオーダーの極短時間露光の月とかでもうまくいくのかどうかはきちんとテストする必要があるかと思います。

とにかくこのようにすることで、CMOSカメラも、一眼レフカメラも、30秒ごとに
  • ゲインが低く露光時間が短い満月用の設定
  • 皆既時用のゲインが高く露光時間が長い設定
の2種類を一つのカメラで撮影することができます。頑張れば20秒ごとに3種類の撮影もできますが、撮影後のファイルの数と容量ともに膨大になるので、2つの設定に抑えたほうがよさそうです。


明るさの設定

次に暗くなってからの調整です。こちらは実際には月食前日の月曜に行いました。満月に近い月齢13日のかなり明るい月が出ているので、露光時間とゲインをその月の明るさに合わせます。

問題は皆既時の明るさの設定です。これまでの月食の経験から、露光時間とゲインをかけた明るさの比が100倍(TSA120+ASI294MC)、400倍(FS-60CB+ASI294MC)、1600倍(35mmレンズ+EOS 6D)とかになるように設定しました。明るさの比にかなりばらつきがありますが、TSA120は自由撮影機なのであとから変更することもあり、かなり仮の設定です。

重要なことは、サチると何も情報は残りませんが、暗い分には画像処理で持ち上げることで十分な明るさにすることができると考え、少し暗めの設定にしておきました。この判断は正しかったようで、実際に撮れた画像は最初思ったより暗いと感じたのですが、DSOの時の炙り出しに比べたら全然大したことなく、十分すぎる情報があるので、どの設定も最終的には全く問題がなかったです。ただし、暗いと背景がノイジーになることがあるので、そこは画像処理時に適したレベル補正や、もしくはノイズ処理が必要になる場合がありました。


当日の撮影

前日までの予報では、日本海側の天気はかなり絶望的でした。もうあきらめるか、一時期は休暇を取って太平洋側に行こうかと思っていました。でも当日になり、夕方くらいから晴れそうな予報に変わってきたので、結局自宅で撮影することにしました。

雲が出るなどの、天気によっては連続撮影は意味が無くなってしまうので、様子を見ながらのセットアップになります。最初は天気が悪くても雲間からでも狙えるように、自由撮影のTSA-120とASI294MCをセットしました。途中からどんどん雲も少なくなってきたので、次に広角35mmとフルサイズのEOS 6Dを置き、さらに太陽時に合わせて連続撮影で写すFS-60CB+ASI294MCもセットします。

暗くなりかけてきたところでまずはFS-60CBの方から、ガイド鏡を仮載せしてSharpCapで赤道儀の極軸を取ります。でも雲がまだ北の空にそこそこ残っているので、雲が薄くなっているところを狙います。今回は赤道儀の精度が肝なので、Excellentがでる30秒角を切るくらいまで合わせこみます。

IMG_7046

18時には撮影を開始したかったのですが、最初の頃は雲が多くてかなり戸惑っていたため、実際に撮れた画像の時刻を確認してみると、35mmの方が部分月食開始の18時7分から、FS-60CBの方が部分日食開始が過ぎた18時13分からになってしまいました。

FS-60CBの連続撮影を開始し、ついでにTSA-120の極軸とりと連続撮影も開始したらやっと少し余裕が出て、最後にCGX-LにVISACを載せてUranus-Cを付けたものをセットアプしました。天王星食の拡大撮影用です。でもこれ、後で詳しく書きますが結局失敗でした。

途中、お隣のご夫婦がきて、一緒に月食をみました。撮影の面倒を見ていたのであまりお世話ができなくて申し訳なかったのですが、それでも双眼鏡を出してみてもらったりしました。今回は皆既の時間がかなり長かったので、そこまで焦らずに見ることができたと思います。


撮影結果は次の記事から

次の記事から、セットアップの詳細と結果を順に書いていきます。ファイルを見たら全部で900GB近くあったので、まだ処理をしている最中です。

とりあえず今回の記事では撮影の最中に、iPhoneでSharpCapの画面を撮ったものだけ載せておきます。

IMG_7044
FS-60CBで連続撮影をしている画面です。
欠け始めていて、雲がまだ多いのがわかります。
シーケンサーが走っているのが分かると思います。

IMG_7047
皆既に入って間も無くくらいの時です。
TSA-120での撮影です。右上が明るいです。

IMG_7049
天王星が認識できたところです。TSA-120で拡大して写しています。  

IMG_7053
VISACでの撮影です。天王星が出てくるところです。

最後の写真ですが、月食も終わりの頃でFS-60CBで露光を変えて2種類撮っているところです。
IMG_7055

IMG_7056
最初は画面左下から始まった月の位置も、月食が終わる頃には真ん中のかなり上まで移動してきました。太陽時に合わせてあるので、地球の影が固定されているはずで、その影を映すスクリーンのように月が動いていく様子を見ることができました。

さて、次の記事からは実際に撮影した画像を載せていきます。


 
 
 
 
 
 
 
 


長く続いてきたSV405CCの評価も佳境になってきました。今回の記事は作例とともに、青ズレの謎に迫ります。さてさて、どこまで解明できるのか?


北アメリカ星雲再び

まずは作例です。今回の一連の記事のその2で出した北アメリカ星雲の再撮影です。

目的は2つ、
  • 前回の撮影は透明度がかなり悪く、階調がほとんど出なかったので、そのリベンジ。
  • 四隅の流れを改善しておきたい。
といったところです。本当はあと一つ、あわよくば青ズレを直す方法が見つかったらと思いましたが、この時点ではそれは叶いませんでした。

まず透明度ですが、今回の撮影では白鳥座の羽の先が見えるくらいよかったです。その影響はかなり大きく、見た目だけなら今回の3分露光の1枚で前回の全スタック分くらいの諧調が出ています。(アップロードの関係でサイズを各辺半分にしています。)

2022-07-02_00-00-47_NGC 7000_180.00s_g120_0.10c_0050_low

依然青ズレは出ていますが、これならインテグレーションしたら階調に関してはかなり期待できそうです。

もう一点、マルチフラットナーを使っているにもかかわらず、前回までバックフォーカス長を適当にとっていたため、SV405CCでもASI294MC PRoでも、いずれの撮影にも関わらず四隅の星像が流れまくりでした。

2022_07_01_01_39_49_M_20_180_00s_g120_0_10c_0034_mosaic
前回までの間違ったバックフォーカスでの四隅の一例。

タカハシの鏡筒はCanonやNikonといった、一眼レフカメラのバックフォーカス長に合わせてアダプターなどの製品を提供しています。今回は手持ちのタカハシ純正のCanon用の一眼レフカメラ用のアダプターを使ってマルチフラットナーのバックフォーカス長に合わせるようにしました。このアダプターに合わせてCMOSカメラを使う場合は、例えばZWOから出ているCMOSカメラとCanon EFマウントに変換するアダプターを使うこと、ほぼ何も考えることなくバックフォーカス長があった状態にしてくれるので楽です。

今回は、かなり前に買ったZWOのCanon EFマウントアダプターを使ってみました。現行モデルはフランジ長が固定ですが、初代のZWOのCanonマウントアダプターはフランジ長を1cm位調整できます。CBPを取り付けたくて、SV405CCに付属の1.1.25インチフィルター用のリングをセンサー部に取り付けたので、ZWOのCanonマウントアダプターは少し手前で固定されるはずです。そのため、マウントアダプターの長さは最短に調整しました。この状態で四隅を見てみると、

2022_07_02_00_00_47_NGC_7000_180_00s_g120_0_10c_0050_mosaic
のように四隅の流れはほぼ無くなりました。

その後、撮影前に少しだけ青ズレを直せないか試したのですが、この日は結局太刀打ちできず、透明度も良くて時間ももったいなかったので、そのまま撮影続行としました。結局天文薄明開始までの午前3時前まで3分露光で72枚撮影しました。前半は雲が通ることも多かったですが、後半はずっと快晴でした。使えたのは雲のない44枚の2時間12分ぶんでした。


画像処理

インテグレーション直後の画像をオートストレッチしたものです。

integration1

一部拡大するとわかりますが、依然青ズレがあります。

integration1_Preview01

もう一つ、今一度上の画像をクリックして拡大して見てもらいたいのですが、微恒星の中心が暗く抜けてしまっています。最初はピントが合っていなかったと思っていたのですが、実際にはかなりピントは気を付けて合わせているにもかかわらず、ほぼ毎回こうなります。また、そーなのかーさんがSV405CCで撮影した画像も同様に中心抜けになっているようなので、どうもこれはピンボケというよりは何か系統的に問題があるような気がしています。

恒星に関しては仕方ないとして、そのまま画像処理を進めます。

途中やはり恒星部分で苦労しました。一番大変だったのは、StarNetのバックグラウンドと恒星部の分離の時に、色ズレのせいかハロの部分がバックグラウンドと認識されてしまい、ここを誤魔化すのが大変で、最後まで不満が残ってしまいました。

Image24_Linear_PCC_ASx2_MS_HT_bg

パッと見はわかりませんが、B画像を抽出してみると同様のハロが他にもたくさん残っていて、あぶり出しとともにたくさんのハロが目立ってきます。

結果


Image24_Linear_PCC_ASx2_MS_HT3_cut_tw
  • 撮影日: 2022年7月2日0時38分-2時53分
  • 撮影場所: 富山県富山市自宅
  • 鏡筒: TAKAHASHI FS-60CB+マルチフラットナー(f370mm)
  • フィルター: SIGHTRON CBP(Comet BandPass filter)
  • 赤道儀: Celestron CGEM II
  • カメラ: SVBONY SV405CC (0℃)
  • ガイド:  f50mmガイド鏡 + ASI290MM、PHD2によるマルチスターガイド
  • 撮影: NINA、Gain 120、露光時間3分x44枚で総露光時間2時間12分
  • Dark: Gain 120、露光時間3分、128枚
  • Flat, Darkflat: Gain 120、露光時間 0.3秒、128枚
  • 画像処理: PixInsight、Photoshop CC

淡いところの階調もかなり出ています。前回の透明度の悪い時より相当良くなっています。庭撮りでここまで出るならまあ満足でしょう。あとはやはり恒星です。

普通ならここでおしまいなのですが、もう少し続きます。ここから大きな進展です


青ズレ検証その後

上の北アメリカ星雲の撮影のあと、もう少し青ズレに関して何かわからないかと思い、後日いろいろ試してみました。ただし雲が多く出ていたので、その隙間でのテストであまり時間をかけることができませんでした。

とりあえず、SharpCapで3分露光を何ショットか撮影しました。最初のショットがやはりこれまでのように暗くなるのが再現され、やはりドライバーレベルで何かやっているのかと思います。この時、雲の動きが速く、雲間が貴重なためにすぐにNINAに移りました(ここで焦っていたのが後で効いてきます)。

NINAでは少し雲が薄くなってきて余裕も出てきたので、じっくり青ズレを見ながら、ASI294MC Proとも交換しながら、何が問題かじっくりみることができました。

一つ疑っていたことがあって、オフセットが40と小さすぎることが原因ではないかということです。SV405CCの場合、オフセットは最大255まで設定でき、今回はわずか40と、最大の6分の1くらいとしています。ちなみにASI294MC Proの場合は最大80で半分の40としています。前回のPedestalの記事であったように、オフセットが低くて輝度の低いところが問題を起こしているのかと思ったわけです。でもオフセットが40の場合でも、120にした場合でも、青ズレに関してはなんら違いが見られませんでした。なので、オフセットは無関係かと思います。

結局、このとき画面を見ながら出した結論は、ASI294MC Proでは何をどうやっても(ゲインやオフセット、露光時間など)青ズレのようなものは出ない、その一方SV405CCでは何をどうやっても(こちらおゲインやオフセット、露光時間など)青ズレを消すことはできない。ということでした。

その後、改めてSV405CCのRAW画像を、RGBで分離して見たり、4つのセグメントごとに見たりしました。
  • SV405CCのBayer パターンがなぜかGRBGであること。ASI294MC ProはRGGB。
  • でもなぜか星雲の濃さから判断するとCF0:G1, CF1:B, CF2:R, CF3:G1のように見えること。
  • CF2の恒星中心部近くに極端に暗くなっている欠損部が多いこと。輝度は周りの1%程度であるが0でないこと。
  • CF1に星の中心部近くに輝度が完全に0のところがあること。CF2ほど欠損の数は多くないこと。
などがわかりました。そーなのかーさんも同様のレポートをしていたので、再現性もあるようです。

結局、この時点ではどうすることもできなくて諦めて、次はNINAで触れないパラメータをいじってみるのかなと思っていました。というのも、CMOSカメラはどこかに設定が保存されていて、例えばSharpCapで触った設定が、FireCaptureを立ち上げるとそのまま引き継がれるというようなことがあるからです。


なんと、原因判明!

そんなことを考えながら昨晩、上の北アメリカ星雲の画像処理を終えて、次回テストの準備をしようと思い、「そういえばSharpCapでSV405CCで撮影した画像があったなあ」と何の気無しに開いてみたら、どこをどう見ても青ズレが見えません。

Capture_00001_20_47_33_RGB_VNG
SV405CCでSharpCapで撮影。青ズレは皆無です。

2022_07_04_21_28_47_NGC_7000_30_00s_g120_10_00c_0084
上の画像の直後にSV405CCでNINAで撮影。明らかに青ズレが出ています。

わかりやすいように拡大して比較して見ます。
ShapCap_NINA_SV405CC
左がSharpCap+SV405CC、右がNINA+SV405CCです。

明らかに違いがわかると思います。ただし、SharpCapでの露光は180秒、NINAでの露光は30秒です。露光時間が逆だったらまだ疑いの余地もありますが、NINAでわずか30秒で青ズレが出てしまっているので、結論は覆らないでしょう。これは明らかにどうやっても青ズレが消えなかったNINAとは、状況が全く違います。

カメラのドライバーはSharpCapでもNINAでも同じ「SVBCameraSDK.dll」を使っています。一応念のために改めて確認しましたが、SVBONYで配布されている1.7.3のカメラドライバーを普通にインストールしたあと、SharpCapは最新版を改めてインストールすると、SVBCameraSDK.dllに置き換わっていました。その一方NINAでは現在の最新版でも、カメラドライバーは最新のものに自動的に置き換わらず
、その前に使っていた1.7.2のままだったので、マニュアルでSharpCapにインストールされていたSVBCameraSDK.dllをNINAの方にコピペして、改めてNINAを立ち上げて1.7.3になったことを確認しています。

ここまでの検証が正しければ、最新版のNINAでの読み出し方の問題ということになります。


よく考えると、SharpCapで撮影した時は雲が流れてたので、時間がなくあせっていて青ズレをきちんと画面で確認していませんでした。そういえばSharpCapで電視観望した時もSV40CCで青ズレが出なくて、彩度もSV405CCとASI294MCで変わりがなかったことを改めて思い出しました。この時は露光時間が短かったからかと思っていましたが、どうもNINAとSharpCapの違いの方が濃厚そうです。

今のところCMOSカメラを使ってのDSOの撮影はShaprCapではディザーガイドがやりにくいなど、NINAやAPTなどに頼らざるを得ません。SV405CCはAPTは対応していないので、実際はほぼNINA一択になるかと思います。NINAでこの青ズレがある状態は致命的です。

というわけで、SVBONYさんの方に今回の結果を報告し、開発陣に連絡してもらうように頼みました。これでキチンとNINAでも対応してくれるように手配してもらえれば、青ズレ問題はとりあえず解決することになりそうです。

今の段階であとやれることは、次に晴れた時に改めてSV405CCを使ってSharpCapで撮影、画像処理までしてみて、(ディザーはやりにくいのでパスするかもしれませんが)青ズレが出ない仕上げ画像まで作ってみることでしょうか。


まとめ

ここまでの結果が正しいのなら、問題はハードではなくてソフトで解決できるということになります。ここが切り分けられるだけでも、かなりSV405CCの未来は明るくなります。その際、彩度がこれまで通り出なくなるのかちょっと気になりますが、まあ優先度としては次の話でしょう。

SV405CCの初期の評価、長かったですがやっと解決につながる道を見つけることができました。やっとあぷらなーとさんにお渡しすることができそうですが、どうもあぷらなーとさん骨折で入院しいるとかで心配です。焦らせてしまっても申し訳ないので、活動できるようになってから渡るようにしたいと思います。


北アメリカ星雲撮影後、6月13日付で新型ドライバー1.7.3が出ました。今回の記事はこのドライバーを適用して書いています。


新ドライバーでのセンサー解析

早速ですが、前ドライバーでも試したように、SharpCapを使いセンサー解析を実行します。

20220630_SV405CC_1.7.3

この結果を見る限り、100と150の間、おそらく120あたりでHCGもオンになり、前回測定した時のような変なゲイン設定と実測のゲインがずれるというようなおかしな振る舞いももう見られません。

ここで改めてASI294MC Proの測定結果を再掲して比較してみます。

ASI294MCPro

  • まず、コンバージョンファクターがSV405CCの方が2割ほど大きく出ています。
  • 読み出しノイズも2割ほど大きく出ているように見えますが、これは単位が [e] になっています。これを2割大きく測定されたコンバージョンファクターで割ってやり [ADU] で見てやると、ASI294MC Proの結果とほとんど同じになります。なので、ノイズに関しては同様の結果で、コンバージョンファクターに差があるということです。
  • フルウェルに関しても同様です。SV405CCの方が2割ほど増して電荷を貯めることができるように思われるかもしれませんが、これは14bit = 16384 [ADU] にコンバージョンファクターをかけているだけなので、コンバージョンファクターが大きいと勝手に大きなフルウェルとなってしまうだけです。
結局突き詰めると、コンバージョンファクターのみがASI294MC ProとSV405CCで2割ほど違うということになります。ではなぜSV405CCのコンバージョンファクターが大きく出たのでしょうか?少し考えてみます。

そもそもコンバージョンファクターは撮影された輝度(信号)と、その輝度のばらつき具合(ノイズ)の比から計算されます。さまざまな輝度を横軸に、ばらつき具合縦軸にプロットし、その傾きの逆数がコンバージョンファクターとなります(簡易証明はここを参照)。ということは、コンバージョンファクターが大きいということは、同じ量の輝度に対し(傾きの逆数なので)その輝度のばらつき具合が小さいということになります。簡単にいうと、ノイズが小さいということです。今回の測定結果だけ考えると、SV405CCの方がASI294MC Proよりもノイズが小さいということです。また、言い換えるとADCの1カウントを稼ぐためにより多くの電子(突き詰めれば光子)が必要になるため、効率が悪いとも言えます。効率が悪いために、ADCの飽和までにより多くの殿下が必要になり、フルウェルが大きく出るというわけです。

ただ、センサーが同じで測定結果が違うということなので、そのまま信じるのも少し疑問が残り、他に何か別の要因が効いている可能性は残されていると思います。今のところは測定結果がわかっているのみで、それ以上のことはわかっていないので、これはこれで事実として置いておくとして、先に進みます。


画像比較

今回はM8干潟星雲とM20三裂星雲で画像を比較してみました。機材は前回同様FS-60CBとCBPで、ASI294MC ProとSV405CCで自宅撮影した画像での比較です。撮影日の透明度はかなり良く、白鳥座の羽は端まで見えていていて、こと座も三角形と平行四辺形が良く見えました。天の川も薄っすらですが見えていて、3分露光一枚でもかなりはっきり写るくらいでした。

NINAの画面と、ASIFitsViewerでのヒストグラムを示します。


SV405CC

01_capture

3分露光のオートストレッチになりますが、すでにこの時点でかなり色濃く出ています。

撮影画面の右下隣のグラフを見るとわかりますが、黄土色の線が検出された星の数を表していて、相変わらず最初の1枚はなぜか暗く撮影されるため、星の数が少ない状態で写っています。

少し気になるのは、冷却時のパワーが大きいことです。1.7.2の時から冷却時も加熱時も時間がかかるようになりました。それはそれで結露しにくくなるはずなのでいいのですが、同じ温度にするときにSV405CCが65%で、ASI294MC Proが48%なので、1.4倍ほどパワーを食うようです。冷却効率はまだASI294MC Proに分があるようです。

02_histgram

ヒストグラムも全ドライバーのように右にシフトすることもないですし、赤だけ山の広がりが極端に大きいということもありません。


ASI294MC Pro

比較のASI294MC Proです。
03_capture_ASI294MCPro

上と比べると明らかに色は淡いです。ただ、右下グラフの緑線を見ると、恒星の径が294に移った時点で3.15を切るくらいから2.9付近に1割近く改善しています。これも毎回のことでそこそ再現性があり、不思議なところの一つです。

02_histgram_ASI294MCPro

このヒストグラムと比べると、まだSV405CCは最適化の余地があるように思えます。まず山の左側の裾の具合が違います。ASI294MC Proのほうが左側がスパッと切れていて、理想に近いです。

あと、やはりSV405CCの赤はまだ少し広がりが大きいようにも見えます。ただ、後の画像処理では前回起きたPCCの背景がニュートラルにならないというようなことはありませんでした。

それぞれ30分程度撮影して、PixInsightのWBPPでインテグレーションまでして、オートストレッチしたものを比較します。天頂を挟んで先にSV405CCで30分撮影、その後ASI294MC Proで30分撮影しました。ASI294MC Proの方が心持ち天頂に近く、10分ぶんくらいの差で少しだけ有利ですが、まあ誤差の範囲でしょう。

上がSV405CCで、下がASI294MC Proになります。
masterLight_BIN-1_4144x2820_EXPOSURE-180.00s_FILTER-NoFilter_RGB

masterLight_BIN-1_4144x2822_EXPOSURE-180.00s_FILTER-NoFilter_RGB

ここで見ても、明らかにSV405CCの方が色が濃いことがわかります。その代わりに、SV405CCの方は恒星の青ズレが依然出ていることも変わりません。

また、SV405CCのマスターダークファイルは以下のようになり、やはりアンプグロー抑制のような効果は確認することができませんでした。
masterDark_BIN-1_4144x2820_EXPOSURE-180.00s


ただ、これはASI294MC Proでも以下のように同様に出ているので、SV405CCが不利ということではありません。
masterDark_BIN-1_4144x2822_EXPOSURE-180.00s

その証拠に上のWBPP後の画像を見ても、SV405CCの場合も、ASI294MC Proの場合もアンプグローのような後は確認できません。


SV405で撮影したM8干潟星雲とM20三裂星雲

その後、さらにSV405CCで追加撮影して、M8干潟星雲とM20三裂星雲を仕上げてみました。テスト撮影の時と同様にFS-60CBにCBP入れて自宅庭撮りで、露光時間は3分x34枚でトータル1時間42分です。

WBPPでインテグレーションした直後の画像です。さすがに上の30分の画像よりは滑らかになっています。

masterLight_BIN-1_4144x2820_EXPOSURE-180.00s_FILTER-NoFilter_RGB

あとはいつも通りPIでストレッチして、Photoshopで仕上げたものが以下になります。
masterLight_180_00s_FILTER_NoFilter_ABE2_mod_cut
  • 撮影日: 2022年6月30日23時56分-7月1日1時39分
  • 撮影場所: 富山県富山市自宅
  • 鏡筒: TAKAHASHI FS-60CB+マルチフラットナー(f370mm)
  • フィルター: SIGHTRON CBP(Comet BandPass filter)
  • 赤道儀: Celestron CGEM II
  • カメラ: SVBONY SV405CC (0℃)
  • ガイド:  f50mmガイド鏡 + ASI290MM、PHD2によるマルチスターガイド
  • 撮影: NINA、Gain 120、露光時間3分x34枚で総露光時間1時間42分
  • Dark: Gain 120、露光時間3分、128枚
  • Flat, Darkflat: Gain 120、露光時間 0.3秒、128枚
  • 画像処理: PixInsight、Photoshop CC

このカメラ、画像処理するとよく分かりますが、色がかなり出やすいです。三裂星雲の周りの青も簡単に出ました。そもそも1枚画像でも色が出てますし、インテグレーション直後でもかなりきちんと色が出ているので、色出しについては全然楽です。実際、明らかにASI294MC Proで画像処理を試したときよりもはるかに楽でした。

画像処理の中でも、色出しは最初のうちは苦労すると思うので、撮影用の入門カメラとしては大きな特徴であると言えるのかもしれません。ただし、青ズレが気になる場合は画像処理でどうにかする必要があり、上の画像くらいには目立たなくすることは可能かと思われます。

正直言うと、庭撮りでここまで色が出やすいなら利点の方が大きく、青ズレのことは画像処理である程度気にならないくらいになるので、結構満足です。

ちなみに、以前FC-76で自宅で撮影したものが以下になります。

integration_DBE_PCC_stretched3

当時はそこそこ満足していましたが、今回の方がM20周りの青の出方、指先の青、階調、分子雲、どれをとっても圧倒的に進歩していると思います。


まとめ

SV405CCですが、最新のドライバー1.7.3でセンサーの振る舞いとしてはかなりまともになりました。

撮影では依然青ズレは存在しますが、画像処理まで考えると色が出やすく一気に評価が高くなります。とくに、画像処理初心者にとっては色が出るというのはかなりの魅力なのではないでしょうか?青ズレ問題は画像処理である程度目立たなくすることもできるのかと思います。

そうは言ってもこの青ズレ問題、できることならやはり解決したいと思っているので、もう少し検証してみます。その一方心配しているのが、青ズレがなくなると同時に、この色が出やすいと言う特徴ももしかしたら無くなってしまうのではという可能性です。まだ解決法も見つかっていない状態なので、結果がどうなるかは分かりませんが、もう少しお付き合いください。


  1. SV405CCの評価(その1): センサー編 
  2. SV405CCの評価(その2): 撮影編 
  3. SV405CCの評価(その3): 画像比較
  4. SV405CCの評価(その4): 新ドライバーでの画像比較
  5. SV405CCの評価(その5): 青ズレの調査と作例
  6. 番外編1: 階調が出ない時のPedestalの効果
  7. 番外編2: ASI294MC Proでの結露


このページのトップヘ