ほしぞloveログ

天体観測始めました。

カテゴリ: 調整・改造

先日作った画像四隅切り抜きソフトを使って、FS-60CBでの星像を比較してみました。比較対象は焦点距離の長い順から
  1. FS-60CB + エクステンダー => FS60Q: F10、焦点距離600mm
  2. FS-60CB + 旧フラットナー(フラットナー FS-60C): F6.2、焦点距離370mm
  3. FS-60CB + 新フラットナー(FC/FSマルチフラットナー1.04): F6.2、焦点距離370mm
  4. FS-60CB + レデューサー(RD-C0.72×): F4.2、 焦点距離255mm
です。条件などです。

  • カメラは2番目の旧レデューサーのみEOS 60DでAPS-Cですが、他3つは6Dでフルサイズになります。
  • また、旧レデューサー以外はQuad Band Passフィルターが入っています。ほとんど影響はないと思いますが、稀に星像が歪むという報告もあるようなので、一応気に留めておいてください。
  • 撮影場所は全て富山市の自宅ですが、どれも撮影日が違うので、条件は同じでないことをご了承ください。
  • 画像は全て撮って出しのJPEGですが、ホワイトバランスはその時々でいじっているので色はあてにならないです。
  • 何も校正していないので、周辺減光を読み取るのは厳しいです。

それでも下に示す画像を見てもらえればわかりますが、同じ鏡筒でも取り付けるオプションによって星像の違いがはっきりと出るのがわかります。


エクステンダー: 600mm 

まずは、1番のエクステンダーです。四隅と真ん中をそれぞれ250ドット角で切り取った画像と、その元の画像(モンキー星雲)になります。

LIGHT_6D_300s_3200_+3cc_20190109-22h33m50s976ms_4cut

LIGHT_6D_300s_3200_+3cc_20190109-22h33m50s976ms


四隅でもほぼ真円になっています。これなら全く文句ないです。


旧フラットナー: 370mm

次に旧フラットナーです。カメラが60DなのでAPS-Cサイズでの撮影であることに注意してください。北アメリカ星雲です。

NORTH_AMERICA_LIGHT_60s_3200iso_+30c_20170913-21h38m38s_4cut

NORTH_AMERICA_LIGHT_60s_3200iso_+30c_20170913-21h38m38s996ms

やはり四隅がかなり流れているのがわかります。結局旧フラットナーではちゃんとした撮影はこの一枚だけでした。それでも天リフの今日の一枚に選ばれた感慨深い一枚です。

星像比較とは関係ないのですが、この画像の撮影日は2017年9月13日で一年以上前です。フィルターも何もなしで、ISO3200で露光時間1分ですが、他の3つと比べてこれだけかなり背景が明るくなっています。他の3つはQBPで露光時間を伸ばせているので、QBPの効果がかなり大きいことがわかります。


新フラットナー: 370mm

新型のフラットナーです。昨日の記事で出したものと同じ画像でカモメ星雲です。

SEEGULL_LIGHT_6D_300s_800_+9cc_20190205-21h20m00s179ms_4cut

SEEGULL_LIGHT_6D_300s_800_+9cc_20190205-21h20m00s179ms


星像ですがほぼ真円。それでも拡大してエクステンダーとよく見比べてみると、四隅で極々僅かに円周方向に伸びているのがわかります。でもこれくらいなら私的には十分許容範囲です。


レデューサー: 255mm

最後はレデューサーです。オリオン座のM42と馬頭星雲一帯です。

ORION_LIGHT_6D_300s_800_+5cc_20190114-22h39m34s849ms

ORION_LIGHT_6D_300s_800_+5cc_20190114-22h39m34s849ms_4cut

まず、広角なのでさすがに周辺減光が目立ってくることがわかります。フラット補正は必須でしょう。星像も真ん中はまだそれほどでもないですが、四隅では円周方向にもそれと垂直にも伸びていて、十字のように見えます。それでも旧フラットナーよりはましですが、新フラットナーには完全に負けています。

拡大しなければ気にならない範囲とも言えますが、これは画像処理での補正方法を検討した方がいいのかと思います。ちょっと色々試してみようと思います。


まとめ

今回はFS-60CBについて、4種類のアダプターを試してみました。結果としては

エクステンダー > 新フラットナー >  レデューサー >> 旧フラットナー

といったとことでしょうか。ほぼ評判通りで、メーカーの言っていることも正しいと思います。やっぱり自分で確かめると納得しますね。細かい違いもよくわかりました。

できれば、これをレンズ設計ソフトで再現してみたいです。だれかFS-60CBのレンズデータとかどこかにあるか知りませんでしょうか?タカハシに聞いてもさすがに教えてくれないだろうなあ。


今週の火曜日、水曜日と新月期で、冬なのに珍しく晴れていました。外に出てもそれほど寒くないので、平日ですがQBPを使って宅撮りです。前回の撮影ではレデューサーを試したので、今回は新タイプのフラットナーのテストです。ターゲットは、これまで何度か撮ろうとしては雲が出てできて失敗しているかもめ星雲です。

機材セットアップ

今回の目的は、先日購入した新フラットナーでの撮影です。以前の旧フラットナーから星像がかなり改善されているそうなので楽しみです。
  • 鏡筒: タカハシ FS-60CB (口径60mm, 焦点距離355mm) + FC/FSマルチフラットナー1.04で焦点距離370mm
  • 赤道儀: Celestron CGEM II
  • センサー: Canon EOS 6D(HKIR改造)、ISO800、露光時間5分x41枚 、計3時間25分
  • ガイド: ASI178MC + 50mm Cマウントレンズ、PHD2 + BackyardEOSでガイド+ディザー撮影
  • フィルターサイトロン Quad BP フィルター(クアッド バンドパス フィルター、 以下QBP)
  • 撮影場所: 富山県富山市
  • 日時: 2019年2月5日、19時22分から
  • 月齢: 0.6(新月)


撮影

撮影は準備から含めて極めて順調。唯一大変だったのが、前回の撮影で使ったレデューサーからフラットナーへの切り替えだけです。最初は短い方の中間延長アダプターを入れて、回転アダプターを鏡筒バンドから外に出して試したのですが、やはりピントがでませんでした。なので、再び中間延長アダプターを外して、カメラは回転しにくいですが、地面に鏡筒を置いた状態であらかじめカメラの水平を出して、カメラ回転アダプターを固定してから赤道儀に取り付けました。

カメラ回転が面倒な代わりに、新型フラットナーには48mm径のQBPをきちんとねじ込んで取り付けることができました。さすが新デザインで、より汎用性が高まっているようです。

いつものようにSharpCapで極軸をとり、CGEMIIのワンスターアラインメントで初期アラインメントです。実は最近ツースターアラインメントさえ使っていません。極軸がきちんと取れていれば、ワンスターアラインメントで十分です。ただし、流石にワンスターアラインメントだけの自動導入だとズレも出てくるので、Carte du CielとAstroTortillaでplate solvingしながらの構図決め。これは極めて便利で、準備始めから30分くらいで撮影を始めることができました。

何枚か撮れていることを確認して、仮眠をとりました。仮眠のつもりがぐっすり寝てしまい、夜中12時頃目を覚したら外は結構すごい風。しかも天頂越えで最後の何枚かは流れてしまっていたので、すぐに片付け。あとはダーク50枚ほどの撮影を放置しながら、また朝まで寝ていました。


画像処理

次の日フラットとバイアスを50枚づつ撮影して、そのまま全てPixInsightで処理です。枚数も4-50枚と少ないのですぐに終わります。 ストレッチは前回同様、赤とびを抑えるためにArcsinhStretchは使わずにScreenTransferFunctionとHistgram Transformationで済ませました。

今回は彩度までPixInsightで出してみました。今回はColorSaturationツールを使いましたが、Curves TransformationツールでSアイコンを選んで彩度を上げる手もあるようです。でもまだまだ手探りで機能を理解しきっているとは言い難いです。もう少し時間をかけて探ります。あとは、いつも通りPhotoshopに送って仕上げです。


出来上がり画像

出来上がった画像は以下のようになります。

light_PCC_stretched_morfing_satiration_DBE_morph_ps2a

新月期で時期的にはよかったとはいえ、それでも光害地での宅撮りでこのクオリティーなら個人的には十分満足です。3時間以上の露光とはいえ、それでもやはりQBPの威力は大きいでしょう。ただ、少しづつQBPに対する不満も出てきました。列挙しておくと
  • 恒星のオレンジが出ない。
  • 赤が、紅に近い赤で、紫がかった赤や、ピンクっぽい赤は出にくい。(ただし、燃える木のピンクはうまく出るようです。)
  • 恒星が赤飛びしやすい。
  • 青い星雲は出にくい。
といったところでしょうか。やはり透過波長域からもわかるように緑系や濃い青、また黄色やオレンジ領域もどうも苦手なようです。これはある意味当たり前で、そのために露光時間を延ばすことができるというわけなので、贅沢な悩みと言えるかもしれません。画像処理で多少誤魔化さなければならないところも出てくるので、ここら辺は腕の見せ所となのでしょう。


Plate solving


話は変わりますが、実際の導入と構図極めの際にはplate solvingとしてAstro Tortillaを使っています。でもあまり高機能でなく、解析結果もいたってシンプルであまりわかりやすくはないのですが、撮影時にBackYardEOSを使っているのである意味仕方なく使っている面もあります。一方、同じplate solvingのソフトなのですが、もう少し高機能なAll Sky Plate Solverを使うと、画像に星雲の名前などを入れてくれたりします。

seegull


右の方で名前がはみ出してしまったりしているのは愛嬌として、今回はいろんな星雲星団がある領域だったので、少し広角を狙いました。フラットナーがちょうどいい画角だったというわけです。plate solvingを使ってこんな解析も楽しいのではないかと思います。

本当はAll Sky Plate Solverが、そのままダイレクトにBackYardEOSに対応してくれたらと思うのですが、とても惜しいです。あ、一応BackYardEOSで撮影して、そのファイルを読み込ませるだけならできます。でもその足で赤道儀にフィードバックして位置を合わせ直すので、何度もそれをやるのは面倒だというだけです。Astro TorttilaとBackYardEOSなら、全自動で赤道儀の位置の合わせ直しまで繰り返しでやってくれるのでものすごく楽なのです。


新フラットナーの実力

この画像処理と並行して、昨日の記事で四隅を切り出すプログラムを作ったのですが、その結果を示しておきます。昨日の記事では画像処理後のものを出したのですが、よく考えたら撮って出しJPEGから切り取ったものの方が周辺減光の様子などもわかるのでいいのかと思います。

これが撮って出しのJPG画像で

SEEGULL_LIGHT_6D_300s_800_+9cc_20190205-21h20m00s179ms

ここから上下左右と真ん中250x250ドットを切り抜いています。

SEEGULL_LIGHT_6D_300s_800_+9cc_20190205-21h20m00s179ms_4cut


旧フラットナーの四隅の星像がどうしても気になって、使う機会があまりなかったのですが、今回の新型のフラットナーははるかに良くなっています。スターベースで店員さんから聞いた時には、それでも色によって極わずか収差で歪むとのことでしたが、これを見る限り私的には全く気にならないレベルです。

 

 

バイアスノイズで少しやり残したことがあるので、試しておきます。


疑問: バイアスフレームをマスターバイアスで補正してみたら?

前回、バイアスフレームを何枚かスタックしてリードノイズを求めてみましたが、枚数のルートで減っていくはずのリードノイズが実際には理論通りに減っていきませんでした。すべてのバイアスフレームに載っている共通のノイズがあると考えられたからです。

それでは、多数のバイアスフレームをスタックして最後に残った共通のバイアスノイズ(PixInsight用語では「マスターバイアス」というそうです)で、各バイアスフレームを補正してから、改めて何枚もスタックしたらどうなるのでしょうか?面白そうなので試してみましょう。


予測

単純に考えるとこんな予想ができます。
  • 前回の測定で、最後まで残った全バアスフレームに共通にあるノイズがさっぴかれるので、理想的に枚数のルートに比例してノイズが少なくなっていく。
  • 最終的にはあるオフセット(一定の輝度という意味)を持った、のっぺりした画像になる。
この予想は、実際に試す前に頭だけで考えたものです。さて本当にそうなるのか、もし違ったとしても実際にどこまで迫れることやら。


測定

さて、実際に試してみましょう。

マスターバイアスは再現性もチェックするために、前回撮影したのとは別に新たに撮影し直しました。枚数ですが、できる限りノイズの少ないものということで、1024枚重ね(て平均し)たものにします。このマスターバイアスで各バイアスフレームを先に補正してから1024枚スタックします。それでもノイズは単に理想的なものを1024枚重ねたものより、(マスターバイアスが足し合わさった分)ルート2倍大きくなるはずです。その分だけ理想的な枚数のルートでノイズが改善されるというのからはずれてくると思います。(と、ここら辺のズレくらいまで実際の測定前に頭の中で考えました。)

また、バイアスフレームも新たに撮影しました。マスターバイアスを作った際の1024枚でもいいのかと思ったのですが、それだと同じものから同じものを引いただけになってしまい、本来残って欲しいノイズもゼロになってしまうかと思ったからです。


結果


今回も1、4、16、64、256、1024枚の比較です。青色の理想的な場合と、緑色のマスターバイアスで補正されたもの赤色のマスターバイアスで補正されていない(前回と同じ)ものを載せています。あと、わかりやすいように縦軸をlogスケールにしました。理想的だとグラフは直線になります。

03_readnoise_vs_gain_02_masterbias


考察

さて、結果を改めて見てみます。マスターバイアスで補正したものは明らかに理想的なラインに近づいています。1024枚の時は同じ程度の(相関のない)ランダムなノイズを2回足し合わせていることになるので、理想的な場合に比べてルート2倍程度大きくなるはずです。無相関なノイズは足しても引いても2乗和のルートになるので、ルート2倍ということです。1.4倍くらいのはずが、実際には1.8倍くらいなので、それでも理論値より少しだけ大きい値になっているようです。256枚のところにも少なからずその影響が出ています。計算上は1.25のルートなので、1.18倍ですが、実際には1.24倍です。さらにマスターバイアスの枚数を増やせば1024枚のところでももっと理想的なラインに近づいてくるでしょう。


少し補足です。まずは1枚重ねで単純にマスターバイアスを引くことを試したのですが、平均値が同じものを差っ引くことになってしまうので、ADU(輝度)が0付近に行ってしまい、その影響で標準偏差も0に近い小さな値になってしまうことがわかりました。そのため次のようにして解決しています。
  1. まずマスターバイアスの平均値の半分の輝度を持ち、標準偏差0の全くのっぺりした画像を、PixInsightのNewImageで作成します。
  2. それをマスターバイアスから引くことで、マスターバイアスの平均値を半分にしました。
  3. そうやって作ったマスターバイアスを、それぞれのバイアスフレームから引きます。
  4. その結果、平均値が輝度0より十分に大きな、マスターバイアスで補正されたバイアスフレームを作り出しました。
IMG_6322


この過程を経て初めて正しそうな結果を得ることができました。


もう一つ、実際に処理した画像を比べてみましょう。左上の奥のがマスターバイアス補正をしていないもの、右下の手前の画像がマスター補正をしたもの。ともに1024枚スタックした時の画像で、輝度は揃えてありますす。

IMG_6328

PCの画面を直接撮影したので、モアレが少し残ってしまっています。見にくいところもあると思うのですが、それでもマスターバイアスで補正をすると残っていた縦線が明らかに消えているのがよくわかると思います。



まとめ

今回わかったことまとめておきます。
  • 全バイアスフレームに載っている共通のコモンノイズが存在する。
  • そのノイズは、多数枚のバイアスフレームをスタックして作ったマスターバイアスを使って、補正することができる。ただし、オフセットごと補正してしまうことに注意。
  • バイアスコモンノイズをさっ引いたバイアスフレームはかなり理想的なランダムノイズに近い。
と言ったところでしょうか。

うーん、今回はかなり予想通りにいったので、結構満足です。予測できなかったところは、マスターバイアスで単純に補正すると平均値が0になってしまい、ばらつきも少なくでしまうことでした。これは通常の画像処理でいう、オフセットをあげて暗い部分を切ることに相当します。

というわけで、画像処理は嘘をつかないということがかなりわかってきました、、、と言いたいところなのですが、すでに少しダークノイズを試していて、こちらはなかなか一筋縄ではいかないみたいです。また余裕ができたらまとめます。


それはそうと、今回新たにバイアスファイルを2000枚ほども撮影してしまいました。すでに合計3000枚、あぷらなーとさんにだんだん迫ってきてしまいました。やばい、これはやばい。まっとうな道を行きたかったのに(笑)。




 

今回はASI294MC Proのバイアスフレームについて色々検証してみました。結構面白い結果が出たのでまとめておきます。


はじめに

昨日の昼間、めずらしくものすごい快晴。これはと思い、早速夜からカモメ星雲を撮影しようと準備をして、やっと撮影を始めたらわずか数枚で雲がもくもく。こんな日はむしゃくしゃするので、諦めてASI294MC Proの評価の続きです。

さて、大きな目的としては、前回の課題の一つダークノイズがどれくらい撮影に影響があるかですが、今回はその前々段階くらいにあたる、リードノイズのいろいろなテストです。実はあぷらなーとさんの解析に触発され、自分でももう少し泥臭い検証をしてみたくなりました。


バイアスフレーム一枚からのリードノイズの算出

あぷらなーとさんが自作ツールでバイアスフレームを解析し、見事メーカーが公表しているリードノイズと値が一致しました。私も前回の記事でSharpCapのSensor Analysis機能を使うことで、メーカー値と同じ値を確認したのですが、もう少し自由に測定できないか試したくなりました。それでも独自ツールを作るのは大変なので、今回はPixInsightの「ImageInspection」の「Statistics」を使いってリードノイズを求めたいと思います。

まず、SharpCapを使い、ASI294MC Proのバイアスフレームを撮影します。条件は
  • モード: RAW16 (16bit)
  • 露光時間: 0.0032ms
  • Gain: 121
  • Brightness(オフセット): 20
  • ホワイトバランス: Red 50, Blue 50
とします。それをPixInsightで読み込み、Statisticsツールを起動し、開いた画像を選択します。

IMG_6308


Statisticsツールでは「14bit [0,16383]」を選び「Normalized」にチェックを入れます。その時のavgDevの値を読みます。この場合、2.1でした。単位はADUなので、eに変換するためにコンバージョンファクターを使います。前回の測定から

IMG_6283

ゲイン121のところ見ると、0.88とあります。先ほどの2.1 [ADU]にこの0.88 [e/ADU]をかけると1.85 [e]となります。SharpCapで測定した値が1.86 [e]なのでほぼ正しい値が出ているようです。

ちなみにコンバージョンファクターがわからない時は、あぷらなーとさんのブログの記事でも紹介されていたように、ユニティーゲイン (UG、eとADUが同じになるゲインのこと、すなわちコンバージョンファクターが1ということ)から求めても同じことです。メーカーによるとUGが117とのことです。ゲイン121の時とは(117-121)/10=-0.4dB違うので、10^(-0.4/20) = 0.95となります。コンバージョンファクターも0.95倍すればいいので0.95 [e/ADU]となります。SharpCapの実測の0.88 [e/ADU]とは少し違いますが、UGをメーカー値としたためこれくらいのズレはあり得るでしょう。UGが正しいとしてリードノイズを求めると、2.1 [ADU] x 0.95 [e/ADU] = 2.00 [e]となりますが、それでもそれほどのズレではないです。


ちょっと脱線します。SharpCapで測定したデータですが、実際に測定しているところは

Gain Value e/ADU Read Noise (e) Full Well (e) Relative Gain Rel. Gain (db) Dynamic Range (Stops)
0 3.99686 7.80246 65484.6 1 0 13.0349
59 2.04740 6.86512 33544.6 1.95217 5.81034 12.2545
61 1.99842 6.83844 32742.1 2.00001 6.02064 12.2252
100 1.28103 6.34598 20988.4 3.12004 9.88322 11.6915
119 1.03257 6.11416 16917.6 3.87080 11.7560 11.4341
121 0.88019 1.85936 14421.0 4.54092 13.1429 12.9211
200 0.35776 1.59308 5861.64 11.1717 20.9624 11.8453
300 0.11418 1.41354 1870.75 35.0044 30.8825 10.3701
400 0.03624 1.35693 593.803 110.280 40.8499 8.77350
500 0.01171 1.32912 191.794 341.432 50.6661 7.17294

だけで、あとは全て計算値です。このことは、例えばFull Wellの値とRelative Gainをかけてみると、全てのゲインで65484.6(上の表は小さな桁を丸めてあるので少しずれます。)と同じ値になり、さらにこれにゲイン0の時のe/ADUの値3.996863906をかけるとぴったりと14bitで整数値の16384になることなどでわかります。Full Wellは本来サチルくらいの光量をカメラに入れて測定から求めるべきなのですが、SharpCapは14bitの最大値をサチった値と仮定して簡易的に求めていることもわかります。ZWOのメーカー値もどうやら同じように測定されているみたいなので、これはこれでありなのかもしれません。


さて、本題に戻ります。一例としてゲイン120の場合で計算してみましたが、他のゲインはどうでしょうか?他のゲインの値も、実際に撮影した画像からPixInsightを使ってリードノイズの値を求めてみたので、グラフにしてみます。赤がSharpCapのSensor Analysis機能で測定した線青がPixInsightを使って一枚一枚マニュアルで求めた線です。

03_readnoise_vs_gain1


グラフを見ても、SharpCapとマニュアル測定の差はほとんど誤差の範囲だとわかります。

というわけで、PixInsightを使うことで、リードノイズの値を画像からいつでも求めることができるという手法を手に入れたということになります。



バイアス画像を多数枚スタックするとどうなるか?

とりあえず、簡単にリードノイズを測定することができるようになったので、色々やってみたいと思います。

まずは、これらバイアスフレームを多数枚スタックするとどうなるのでしょうか?

スタックするとばらつきが平均化されるので、もしバイアスフレームに存在するノイズが完全にランダムなら、理想的には枚数のルートに比例してノイズが小さくなっていくはずです。

2、4、16、256、1024枚と、枚数を増やして、上と同様にPixInsightで実測したリードノイズの値を求めてみました。その結果をグラフに示します。理想の場合(青線)と、実際にスタックした場合(赤線)での比較になります。スタックはPixInsightのIntegration機能を使いました。蛇足になりますが、Macbook Proでスタックした場合4144x2822の16bitのfits画像1024枚でスタック時間は7分くらいでした。これくらいなら待つことができます。



03_readnoise_vs_gain2


グラフを見るとわかりますが、理想的なノイズの減り方に比べて、実測の方が明らかにノイズの減り具合が悪いです。これはなぜなのでしょうか?


実際のスタックしたバイアス画像を見比べてみる

この謎を解決するために、実際にスタックした画像を見比べてみましょう。まずはこちら、

IMG_6310


左上の奥の画像から1、4、16枚、最後の右下手前の画像が256枚重ねたものです。輝度は1枚ときの画像に全て合わせているので、直接見比べることができます。ぱっと見てわかるのは、枚数が多くなると明らかにノイズが滑らかになっていることでしょうか。これを見る限りは理想的にはどんどんノイズ(ばらつき具合)は少なくなっていってもいいはずです。


では次に、同じ画像で輝度を256枚重ねた画像に合わせてみましょう。

IMG_6312


前は綺麗に見えていた256枚画像も、実は完全にランダムなノイズではないことがわかります。縦線みたいなものが残っています。逆に1枚の時には横線が目立っています。これは横線に関してはランダムに近いノイズで、枚数を重ねることで滑らかになっていくのですが、それでも全枚数に共通に存在する縦縞のノイズが残ってしまい、それがグラフでの理想値との差を生むと推測されます。実際に1枚重ねだけの画像を何枚も見比べてみると、横線がてんでバラバラに入っていることがわかります。

ここからわかることは、
  • 多数のバイアスフレームを使うのは、バイアスフレームのランダムに存在するノイズを減少させるため。
  • バイアスフレームでライトフレームを補正するのは、スタックしたバイアスでさえも残った、バイアスフレーム全てが持つ共通のノイズを除くため。
ということが言えるのではと思います。

まとめ


はあ、ババーッとまとめてさすがに疲れたので、今日はこれくらいにします。まだまだ面白いことはあるのですが、さすがに書くスピードの方が追いつきません。さて、今日のまとめです。
  • 単体のバイアスフレームから、リードノイズを見積もることができる。
  • SharpCapも全部のゲインで全部の測定をしているわけでなく、一部を測定して、あとは計算で出している。
  • バイアスフレームをスタックすると、ノイズは減っていくくが、無限に小さくなるわけではない。
  • バイアスフレーム全てに共通するノイズが存在し、それらはバイアス補正でライトフレームから差っ引くことができる。
といったところでしょうか。

ちなみに、あぷらなーとさんはバイアス解析だけ1万枚も撮影するというような、言わずと知れた変な人です。私はたかだか千枚ほどしか撮影していないので、あぷらなーとさんに比べて10分の1くらいしか変でないということがわかってもらえると思います。






近頃、KYOEIさんにおいてZWO社のASI294MC Proを手に入れました。これまでもASI294MCを使ってきていましたが、今回はこの冷却タイプにあたります。私にとっては初の冷却カメラの使用になります。

でもずっと天気が悪くていまだにファーストライトが実現できていないので、その分時間は余っています。せっかくなので、冷却タイプの性能評価を、ノーマルタイプと比較してみたいと思います。

IMG_6171


 
評価方法

さて、同じようなカメラが2台あるので、興味があるのはその性能の比較です。ノーマルタイプについては以前も性能評価をしています。SharpCapを利用することで、センサーの性能を簡単に実測することができます。測定できる項目は
  • コンバージョンファクター
  • リード(読みだし)ノイズ
  • フルウェル(飽和容量)
  • 実効ゲイン
などです。

SharpCapのSensor Analysis測定は3段階に分かれています。
  1. 最初はGain 0でe/ADU(コンバージョンファクター)を測定。
  2. 次が蓋をしての、ダーク、最短露光時間状態での、リードアウトノイズの測定。
  3. 最後に、再び蓋を外してゲインを変えての実ゲインの測定です。

詳しい説明はリンク先を参照するとして、興味があるのはセンサーが同じで、冷却した時にどこにどれくらい違いがでるのかを実際に確かめてみたいと思います。


 

測定時の注意点

測定は久しぶりだったので多少戸惑いました。今回気になった、測定するときの注意点です
  • 最初はRAW8に設定されていることが多いです。RAW16モードで測定すること。
  • 光源はiPadを使ったのですが、明るすぎるのと、フリッカーのような瞬きがあるので、紙を何重にかして光を通しています。
  • 光の量の調整が結構シビアです。暗いよりは明るいほうが測定の失敗が少ないです。測定開始時の最初の自動露光時間調整で、適度な露光時間に落ち着いたときの値が20msとかより短くなると、測定を開始することができますが、光量がまだ少なくて失敗する確率が増えます。露光時間が2msから5msくらいまでの間になるようにすると成功率が上がります。
IMG_6280
  • うまくいかない場合の典型なケースでも、最初のe/ADU(コンバージョンファクター)の測定と、ダークの測定まではすんなりいくはずです。
  • 次の「ゲインを変えての測定」がうまくいかないことがあるかもしれません。ここで失敗すると最初からすべてやり直しです。そのほとんどが光量が少なすぎて、露光時間が長くなりすぎるケースです。一つは、ものすごく光量が少ないとゲイン0の時に10秒以上の露光になって止まってしまうこと。たとえもう少し光量があっても、多分これはSharpCapのバグだと思うのですが、露光時間が1.5sとか1.7sくらいの時に、測定完了の判定がうまくできなくて、露光時間を長くしたり短くしたりを繰り返すことで、タイムアウトで終わってしまうことです。回避方法としては、光量を増やして、すべての測定の露光時間を1s以下に抑えることです。
  • できる限りホワイトバランスが取れている光を入れたほうがいいのかと思います。測定時の写真が以下のように紫に寄ったような光になりますが、センサーで見るとバランスが取れていたりします。
IMG_6273
  • 今回はiPadのColor Screenというソフトを使い、センサー側で見たホワイトバランスをある程度合わせてから測定しました。でもホワイトバランスがある程度ずれていてもうまく測定してくれるようで、何度か測定してもあまり結果は変わりませんでした。あまり気にしなくてもいいのかもしれません。
  • 結構重要なのが、SharpCapの一番下のPreviewingとかdroppedとか出ているところです。接続状態が悪いとdroppedの値が増えていきます。droppedが0でなかったらおかしいと思って、ケーブルをさしなおす、ケーブルを変えるなどしてください。0でなくても測定はできますが、すごく時間がかかります。通常の測定は全部終了するまでに5分もかかることはありません。dropしていると10分以上かかったりしてしまいます。


ASI294MC ノーマルタイプ

まずは測定がうまくできているかを検証するために、以前と同じASI294MCのノーマルタイプで測定しました。この時のセンサーの温度は冬の暖かい部屋の中での測定ということで、37度程度でした。センサーが動いている場合は外気温よりは高くなるので、特に問題ない温度だと思います。

IMG_6224


測定結果ですが、約一年前に測ったものと比べても、誤差の範囲内で特に変化はなく、経年劣化なども確認されなかったと言えます。相当ハードに、約1年間使い込んでもほとんど性能劣化が見られないというのは特筆すべきことだと思います。

ただ、読みとっている横軸のゲインの設定値がだいぶん違っています。これはSharpCapの方の選択の問題なのですが、以前は低ゲインを細かくとっていたり、最大ゲインの570をとっていたりしましたが、それらがなくなりました。その代わりに59と61をとるとか、119と121をとるとか、性能が大きく変わるところをあらかじめ知っていて、測定しているみたいです。今回の場合もゲインが119と121で特に読み出しノイズの値が大きく変わっていて、メーカーが出しているグラフの結果をよく再現しています。

ちなみに、RAW8で測定した結果は以下のようになり、8bitのダイナミックレンジで制限されてしまうことがよくわかります。SharpCapのマニュアルにはできるだけ大きなビット数で測定しましょうと書いてあるので、16ビットで測っておくのがいいのでしょう。

IMG_6207


ASI294MC Pro 冷却タイプ


IMG_6235
箱の中身。オフアキとかのことも考えて、各種厚みのリングが入っています。
CD-ROMの中に日本語のマニュアルが入っています。わかりやすいです。 

次にASI293MC Proですが、まずはUSB接続のみで、外部電源(12V/3Aと表示されています)も繋げずに常温で比べてみます。ただ、同じ部屋の中で測定してもなぜかセンサーの温度がそこまで上がりません。しばらく待って温度をならして、しかも測定をしながらでも25度程度でした。これは冷却コントロールをしなくても外気温をうまく取り入れる機構ができているのかもしれません。

IMG_6283

測定結果は、ASI294MCのノーマルタイプとほぼ同じです。正確に言うと、ノーマルが37度、Proが25度と温度が低いにもかかわらず、Proのほうが少し結果が悪いのですが、これは個体差の範囲内でしょう。


実際に冷却しての測定

さて、ここからの冷却過程は初めての経験になります。12V, 3A以上出せる外部電源を用意します。今回はいつも使っているACも出すことのできる40000mAhのリチウムイオンバッテリーの12V出力端子を使いました。SharpCapのThermal Controlsのところをオンにします。ターゲット温度を下げていくと、使用電力が上がり、センサー温度が下がっていく様子がわかります。何度が試しましたが、一番下がった時で-20度に設定して、-15.8度まで行きました。ものの5分もたたないくらいにターゲット温度まで行くので、ずいぶん簡単です。最低到達温度は外気温に結構依存しそうです。

測定時は-15度がターゲットで、到達温度が-11.7度でした。その状態での結果です。

IMG_6271


一見常温の時と変わりないように見えますが、リードノイズは明らかに下がっています。温度を変えて測定したのでグラフを示しておきます。

all

上のグラフだとかなり重なっていてわかりにくいので、Gain = 500のところだけを別のグラフにしてみました。

G500


これを見ると、温度とともにリードノイズが増えていることがわかります。理屈の上では回路系の抵抗の熱雑音が多少貢献していると考えられるので、温度が下がることによってリードノイズも下がることが期待されます。測定でもリードノイズが温度によって下がることは確かめられましたが、その一方、結果だけ見ると大した効果でなく、せいぜい40℃温度が上がると1割増えるとか、たかだかそれくらいということもよくわかると思います。


ダークノイズとリードノイズの関係


ここで今一度リードノイズとダークノイズの関係を確認しておきます。カメラに蓋をしてセンサーに光が入らないような暗い状態で測定した場合、測定されるノイズはダークノイズσdark [e-/sec] と読み出しノイズσread [e-]が合わさったノイズが出てきて、実際に測定されるノイズをσとすると、

σ=σ2darkt+σ2read

という関係式で書くことができます。ダークノイズとはセンサーに光が入っていない時にも暗電流が流れることにより存在してしまうノイズで、時間 t のルートに比例して増大していくノイズです。

SharpCapの場合は、測定時間 を設定できる最短の時間0.032msとして、上式の前項を無視できる形にして読み出しノイズσreadを直接測定しているようです。ただ測定過程をじっとみていると、測定中に"Brightness"を変化させてバイアス(ヒストグラムで見ると、ピークの中心値のこと)を何度か変えてテスト測定をし、最後は"Brightness"を20に固定して最終的な読み出しノイズを測っているようでした。この過程の理由がよくわからないのですが、ばらつきの結果出てくる負の値を防ぐためのように思われます。

ちなみに読み出しノイズは、画像処理で行われるバイアスノイズと同義と言ってしまってもいいのかと思います(これちょっと自信がありません)。


ダークノイズの温度依存性

読み出しノイズは温度の依存性はあまりないことは上の実測でわかりましたが、ダークノイズは盛大に温度に依存します。簡単にですが、その結果だけ示しておきます。

測定時の条件は
  • モード: RAW16 (16bit)
  • 露光時間: 30s 、バイアスノイズの時だけ0.0032ms
  • Gain: 120
  • Brightness(オフセット): 20
  • ホワイトバランス: Red 50, Blue 50
  • 画像はfitsファイルをPixInsightで開き、DebayerはせずにそのままJPEGに変換
です。Gainが120の理由ですが、ここでノイズが小さくなるからです。

まず露光時間を最短にしたリード(バイアス)ノイズに相当するもの。ただし測定時の温度は17.6℃です。
dark_10_frames_17.6C_2019-01-27T02_11_10


次に、露光時間を撮影時を想定して30秒とした場合でリードノイズとダークノイズが合わさった場合で、温度が低温時の-16.2℃の場合です。明るさは上のバイアスノイズと比較できるように同じ値でストレッチしました。
dark_10_frames_-14.1C_2019-01-26T20_42_42

右上にアンプノイズが見えます。左側に明るいカブリが見えますが、これは漏れ光とかではないと思うので、何か余分なノイズが出ているようです。

最後に同じく露光時間30秒で、常温時の温度が25℃です。
dark_10_frames_16.2C_2019-01-27T02_06_54

低温時と比べて背景も相当明るくなります。さらに拡大してみるとわかるのですが、輝点がはるかに大量に発生しています。


まとめ

疲れたので、今日はとりあえずここら辺までとします。今回わかったことは、
  • ASI294MCは一年ほど使い込んでも経年劣化のようなものは見られない。
  • ASI294MCとASI294MC Proにおいては常温時では性能に差が見られない。
  • Proの方がクーラーを使わなくてもセンサー温度が低い状態を保つことができる。
  • 読み出しノイズは、温度の増加で大きくなるが、大した影響ではなく、40℃温度が上がって1割程度の増加である。
  • 一方、ダークノイズは温度増加で、背景、輝点ともに盛大に増える。
などです。温度によるダークノイズの差は見えましたが、これが実際の撮影にどれくらい効くのか、次回以降、気合が残っていればもう少し定量的に評価してみたいと思います。

今回の記事は結構一般的なことだけ書きましたが、まだまだ他にもまとめきれていないことがたくさんあります。例えば、
  • リードノイズとBrightnessによるバイアス設定の関係
  • バイアスはゲインを合わせなくてはいけないのか?
  • Gain120の振る舞いがあまりに面白くて、これだけでひとつ記事が書けそう
とかです。特にGain120はちょっと変っぽいです。なんか、サチらないピクセルが存在するためにノイズが少なく見えているだけのような印象です。

いやあ、CMOSカメラも奥が深いです。温度というパラメータが一つ増えたのでちょっと溢れ気味ですが、焦らずゆっくり進めていきたいと思います。




先日の名古屋名城公園での電視観望の際、最初新しいiPhone XRのSynScan Proで操作していたのですが、どうもWi-Fi接続が時間にして分くらいのオーダーですぐに切れてしまいます。接続し直すと再度操作できるようになるのですが、ちょっと手間なのとアラインメントが保たれるか不安だったので、その時は仕方なくPCの方のSynScan ProでWi-Fi接続してことなきを得ました。PCからの接続は安定していて、際接続が必要なことはなかったのですが、SharpCapと併用していたのでいちいちソフトを切り替えるのが面倒だったくらいです。

この件ちょっと気になっていたので、色々調べてみました。


問題点の確認

まず検証できる手持ちの機材ですが、
機種SynScan Pro Ver.SynScan Ver.
iPhone XR1.13.01.12.0
iPhone 51.9.01.9.0
iPad mini 31.9.01.9.0

の3機種で、それぞれに上記のようなバージョンのSynScanとSyncScan Proが入れてあります。iPhone XRに入れてあるバージョンのみが他と比べて新しいです。

この状態で3機種を比べました。
  • まず、iPhone XRのみ不安定です。iPhone 5とiPad mini 3においては以下の現象は発生しません。
  • 現象としては、一旦接続をして操作ができる状態になった状態で、右スイッチで一旦画面を暗くしたり、自動ロックで画面が暗くなってしまうと、そこで接続が切れてしまうようです。再度アプリに戻って矢印を押したり、「設定」->「Diagnostic」->「Response Time」と調べてもわかるのですが、接続が確立されていません。
  • その後、上部の「AZ-GTi(経緯台)」とか書いてあるところをクリックし、一旦切断してから、
  • 再度接続をやり直すとまた接続が確立し、操作できるようになります。
  • この状況は、SynScan、SyncScan Proともに同じです。
  • また、アクセスポイントモードでつながっていても、ステーションモードでつながっていてもともに同様に起きるため、AZ-GTiのハードの方の問題というよりは、SynScanとSyncScan Proと考えられます。
SynScanとSyncScan Proのバージョンが関係しているかどうかはこの時点では不明です。でもこの間バージョンアップするまではiPhone XR普通に安定に動いていたと思うので、バージョンアップによって引き起こされた可能性も高いです。SyncScan Proのバージョンを落とそうと努力したのですが、最近は普通の方法だと難しそうなので結局あきらめました。

他の方の状況

ネットを調べてみても、あまりこのような状況をあらわに書いてある記事が見当たりません。数少ない記事の中、あっかさんという方のブログにそれらしきことが書いてありました。よく似た現象なので、再接続をしていないからかと思ったのですが、のちの記事にアライメント方法で解決したと書いてあるので、もしかしたら勘違いかもしれません。(追記: その後、あっかさんのブログのここ半年の記事を全部読んだら、そのものの記事がこことか、ここにありました。)

ほかにも、TAKさんという方のページにSkySfariとの接続の記事があって、その中に「現行のiOSはバックグランドの処理で...」とか書いてあるので、もしかしたらiOSのアップデートも関係するのではと考え、とりあえず最新のiOSにしました。結果はまったく改善せず。同様の記事で、iPadだとバックグランド処理も問題ないとどこかに書いてあったので、やはりiPhone XRが問題なのか?


アップデート実験 

問題を切り分けるために、今ある古いバージョンのものをアップデートしてもいいのですが、それによって今使えているものが不安定になるのも嫌です。なので一番使用頻度の低いiPhone 5のSynScanのみ最新版の1.13.0にアップデートしてみました。

すると、最新バージョンのSynScanではiPhone 5でも同様に接続が切断されることがわかりました。同じiPhone 5でも、アップデートしなかったProの方は画面を一旦画面ロックしても安定に接続し続けています。

結局最新バージョンのSynScanアプリの問題ということで確定
です。もし、今のバージョンで接続が安定して保っているなら、この問題が解決するまでは今しばらくSynScanとSyncScan Proのアップデートは控えておいたほうが賢明かと思います

IMG_6139
こんな風に右上にクルクルマークが出たら、もうダメです。
再接続しか手がありません。


  • 同様に困ってる方いらっしゃいますでしょうか? 情報を共有したいです。コメントに書き込んでいただけるとありがたいです。
  • Sky-Watcherさんには早急に対策をしていただきたいです。


その他Tips

この検証の過程でいくつか発見したことがありました。メモがわりに載せておきます。
  • AZ-GTiのWi-Fiはいくつも同時に接続できるようです。例えば3機種同時に接続してもきちんと反応します。それぞれで操作してバッティングしないか、例えばアラインメント情報がどうなるかとかはまだ不明です。
  • ネットワークの情報は本体の方に保存されているようです。例えば一旦アクセスポイントモードステーションモードを両立させてしまえば、その後AZ-GTiの電源を切ってもその情報は保存され、再度立ち上げた時に同様のWi-Fiが使えればステーションモードで勝手につながります。
  • SynScan、SynScan Proの「設定」->「ユーザーインターフェース」にある「Keep screen on」をオンにておくと、SynScan、SynScan Proが立ち上がってる最中は画面の自動ロックがかからなくなるので接続は保たれます。それでも自分でロックして画面を暗くしてしまうと接続が外れるので注意です。あと、付けっ放しになるので電池の持ちにも注意ですね。


後日談

ここから2019/1/14に追記です。

バージョンが1.14.1になって画面ロックでの接続断は解決されたようです。自分でも確かめました。皆さんの情報のおかげです。販売店に伝える時も何人もの人が同じ状況だと説明できたので、説得力が増しました。どうもありがとうございました。
販売店に伝えたのが1月8日で、その時点でもメーカー側も把握していなかったとのことで、それからわずか10日ほどでの解決となります。メーカーの方の素早い対応にも感謝です。 

赤道儀のセッティングの記事のコメント欄で延々と続いていた、Advanced VXの時刻の保持の謎がやっと解けました。

わかってしまえば簡単なのですが、謎が解けるまでにいろんなことをやりました。このブログは自分の天文関連の日記のような役割もあるので、読んでくださる方にはまためんどくさいことをと思われるかもしれませんが、一応失敗したことも含めて書いておきます。

IMG_5986
ハンドコントローラーの内部。
基板上に内蔵電池らしきものは見当たりません。(後述)


Celestron Advanced VXのアップデート手順

時刻の保持とは関係ないかもしれませんが、まずはファームウェアのアップデートです。はっきり言ってこの手順も分かりにくいですね。自己責任らしいのですが、他の方にも役立つかもしれないので、とりあえず試した順に書いておきます。
  1. 機器の接続ですが、ハンドコントローラー (NexStar+、以下コントローラー) と赤道儀本体は繋いでおいて、電源もいれておきます。コントローラーとPCの接続はRS232Cです。最近のPCでRS232Cがついているものは稀なので、USB-RS232C変換ケーブルなどを購入してつなぎます。RS232C端子とコントローラーは、赤道儀を買った時についてくる付属のRS232C-4pinモジュラー変換ケーブルで接続します。私はこのケーブルの存在を完全に忘れていて、過去に改めて買おうと思ったことがあるので注意が必要です。持っていないという方は箱の中を探してみてください。最初から付属しています。
  2. 一方ソフトの方ですが、CelestronのサイトからSUPPORT -> Manuals & Softwareに進み、Drivers & Softwareのページに行きます。その後たくさんあるソフトの中から適したものを選ばなければいけまえん。Hand Control Firmware Updatesとか、Motor Control Firmware Updatesとかそれらしい名前があるのですが、これらは古い機種用のアップデートツールみたいです。Advanced VXの場合は、Celestron Firmware Manager (CFM)を選びます。私がダウンロードしたのは2.3.7111というバージョンでした。
  3. ダウンロードしたzipファイルを解凍して、その中のCFM.jarファイルをダブルクリックします。あ、Windowsでしか動かないのと(追記: あれ?JAVAだから機種依存しない?未確認です。)、あと、JAVAがインストールされていないと実行できませんので、必ずJAVA(JRE)をインストールしておきます。
  4. ここまでできたら、あとは勝手にCFMが機器を認識してくれるはずです。最初ちょっとわかりにくかったのですが、コントローラーと赤道儀本体の「2つ」の機器が認識されたと出るはずです。一度のアップデートで、コントローラーと赤道儀本体の二つともアップデートしてくれます。
  5. うまく認識されたら、Updateボタンが押せるようになるはずなので、押します。12個のファイルをアップデートして終了です。
IMG_5993
アップデート時の様子。
この写真を撮っているときにケーブルを触ってしまい、
この後、失敗します。

ところがここでポカをやらかしました。12個目のファイルをアップデートしている最中にケーブルが外れてしまったのです。アップデートは当然停止、しかも赤道儀を立ち上げると「Bootloader invalid pkg: 0002」とかいうエラーが出て何もできなくなります。ここから迷走し出したのですが、Celestron Firmware Managerで機器が認識できない時に出る解説の通り、一旦赤道儀の電源を切り、コントローラーの左下のボタンと、すぐ上のMENUボタンを同時に押して、立ち上げなおします。「BOOT LOADER Serial User Keyoad Entry」とでて、本来これでファームウェアが壊れていても接続できる状態になっているはずなのですがなにをどうやっても接続できません。ファームが壊れて接続自身ができなくなったと思い込んでしまいました。

この段階で小一時間格闘して、別のPCを持ってきてやっと原因が判明しました。COMポートの自動選択がうまくいかなかったようです。最初のPCにはCOMポートが複数あり、うまくいった時は自動で赤道が繋がったものを見つけ出したようですが、うまくいかなくなった時はコントローラーが繋がっていないCOMポートを見ていて、その結果繋がらないというメッセージを繰り返していたというわけです。別のPCはCOMポートが一つしかなくて間違えようがなかったということです。Celestron Firmware Manager はCOMポートの選択を任意にできないようなので注意が必要です。

とにかく、ケーブルの接続に注意して再びアップデート。今度はうまく行きました。バージョンを見てみると
  • HC:GEM 5.28.5184
  • MC:7.11.4244
から
  • HC:GEM 5.29.7137
  • MC:7.15.8270
にアップデートされていました。 HCはハンドコントローラーのこと、MCがモーターコントローラーで赤道儀のことを表しているとやっと理解できました。

ファームウェアは日本語が含まれるものと含まれないもの2種類あるのは、以前CGEMIIをアップデートした時のブログのコメントでの情報で知っていましたが、今回は自動的に日本語が含まれるファームが適用されました。
 
IMG_5995
 


時刻の保持

やっと今回のメイン記事に当たるのですが、ここでも結構手こずりました。無駄なことも含まれてますが、やったことを書いておきます。

  1. アップデート後、一旦アラインメントで時刻を設定し、再度立ち上げなおして時刻が保持されるか確認しましたが、時刻は最初に設定した時のままで進まず。
  2. アップデート時に工場出荷時にされますが、りっくんさんがされたようにあえて再度工場出荷時にリセット。それでも同じで、立ち上げた時に設定した時刻が残るのみです。
  3. いろいろ触っていて一つ気づきました。「MENU」ボタンを押して上下ボタンを適当に押すと出てくる「時刻・場所の表示」です。これを押すと「位置を記憶」というのが出てきます。ここでEnterを押してやると、その時の時刻が保存されるようです。でも時刻が進むことはありません。でも保存時刻をコントロールできることはこの時点でわかりました。
  4. 半分諦めかけて、昼食を食べ買い物に行って帰ってきてから、後片付けの前に最後にと思って「advanced vx time keep」で検索してCloudy nightsでやっと答えが見つかりました。「MENU」ボタン -> ユーティリティー -> RTCのON/OFFです。RTCとはReal Time Clockとのことで、これをオンにすると内部時計が電源を切っても進み出します。
  5. でもこれもなかなか曲者で、時刻を合わせても、なぜかRTCをオンにすると「現地時刻」が30分くらいずれてしまいます。諦めずに、再度工場出荷時にリセットし、最初の時刻を合わせ、RTCをオンにし、30分くらいのズレが出ても「MENU」ボタン -> スコープセットアップ -> 時刻・場所の設定で時刻を合わせなおして、やっと現地時刻が正確な時間になりました。
  6. 確認方法は、赤道儀のスイッチを入れた時に、これまで時刻を合わせていたところで突然場所の設定が表示されてしまいます。ここでビビらずに、下ボタンを押すと現地時刻が表示され、しかも時間がリアルタイムで進んでいるのが分かります。

幾つか不具合や謎らしきものも見受けられました。
  • ユーティリティー -> スコープセットアップ -> 時刻・場所の設定でtoyamaを選択してもなぜかakitaになってしまう。何度かやったらやっとtoyamaになりました。
  • Cloudy Nightsによると、しかも電池(CR2032)もあると。前回ネジを外してカバーを取って基板を見ても見つからなかったので、今一度、裏表も含めてきちんと見てもやはり見当たりません。2032なら大きいのですぐに見えるはずなのですが、不思議です。
  • 内部電池が見えないので、まさかと思って一旦ハンドコントローラーも赤道儀も電源ケーブルも全て外してしばらくしてから再接続し、再起動しましたが、時間は保持しているようです。何かどこかに時間を保持する電力があるはずなのですが、今のところ不明です。(追記: Twitterで情報がありました。電池は赤道儀本体側にあるとのことです。)

とはいえ、やっとAdvanced VXの時刻保持の謎が解けました。結構長かったです。知っている人にとってはあたりまえのことかもしれませんが、りっくんさんもkiharaさんも私もそうだったのですが、このことに気づいていない人は意外にたくさんいるのかと思います。

外は大雪。こういったことに時間をかけられるのは、なかなか星の出ない北陸の冬だからこそですね。
 

週末土曜日、満月の日。一晩中明るい月が出ていますが、北陸の貴重な晴れの日と、週末が重なったので、こんな日は絶好の機材のテスト日和です。

せっかくなので、先日シュミットで購入した月明かりでも撮影が可能だというQuad BP フィルターを試してみたいと思います。そこそこ写るなら遠征に行けない「平日」でも、「月」が出ていても、「自宅で気楽に」撮影を楽しむことができます。


セットアップ

  • 鏡筒: タカハシ FS-60Q (口径60mm, 焦点距離600mm)
  • 赤道儀: Celestron CGEM II
  • センサー: Canon EOS 6D(HKIR改造)
  • 日時: 2018年12月22日、22時頃から
  • 月齢: 15.2、満月
  • テスト対象: サイトロン Quad BP フィルター(クアッド バンドパス フィルター、 以下QBP)
少し困ったのが、QBPをFS-60Qにどうやって取り付けるかです。フィルター径は48mm。ところが、FS-60シリーズは回転装置の出口部分内側に52mmのフィルターネジが切ってあるため、48mm径のフィルターはそのままでは取り付けられません。いろいろ試してみると、回転装置と延長鏡筒の間に挟み込むと、ねじ込みや固定はできないのですが、うまい具合にピッタリはまって取り付けられそうです。

IMG_5912


コツは、フィルターのネジが切ってある側を鏡筒の対物レンズ側に入れ込むことです。こうしないと延長鏡筒を1-2回転くらいしかねじ込めなくて、不安定になります。まあとりあえず大丈夫そうなので、今回はこの状態で撮影してみます。


対象天体

M42 オリオン大星雲:
  • これまでなんども撮っているので比較しやすい。
  • 満月との距離が25度角程度とあまり遠くなく、この日は非常に明るい領域。
  • 肉眼で見ている限り、リゲルとベテルギウスはなんとか月の光に負けずに見える。3つ星はほとんど見えないくらい。

画像比較1: 同じ露光時間でQBPありなしでの比較


まずは、露光時間を同じにしてQBP有り、無しで比較してみます。JPEG撮って出し画像での比較です。

  • QBPなしの通常の撮影: ISO1600, 10秒露光
M42_LIGHT_6D_10s_1600_+8cc_20181222-22h07m33s760ms

10秒以上の露光だと明るすぎなので、これくらいまでしか露光できません。

  • QBPありでの撮影: ISO1600, 10秒露光
M42_LIGHT_6D_10s_1600_+14cc_20181222-22h21m29s692ms


同じ時間でもQBPフィルターがあると、当然の結果ですが随分暗くなることがわかります。


なお、上の2枚とも色温度設定が3200Kと低いので青が強く出てしまっています。


画像比較2: 露光時間を変えて背景明るさを合わせる

これもJPEG撮って出しです。
  • QBPなしの通常の撮影: ISO1600, 10秒露光(画像比較1と同じもの)
M42_LIGHT_6D_10s_1600_+8cc_20181222-22h07m33s760ms

  • QBPありでの撮影: ISO1600, 30秒露光
M42_LIGHT_6D_30s_1600_+10cc_20181222-22h28m12s224ms

  • QBPありでの撮影: ISO1600, 60秒露光
M42_LIGHT_6D_60s_1600_+8cc_20181222-22h37m16s270ms



実際の背景の明るさを比べると、最初のQBPなしの1枚と、後のQBPありの2枚を比べるとわかりますが、露光時間が3倍だとまだ少し暗く、6倍だとかなり明るいくらいなので、4倍程度の違いでしょうか。


QBPによる背景明るさの変化の簡単な推定


月の明かりが太陽の反射なので白色光に近いとして、太陽光のスペクトル

SunLightSpectrum-280-2500nm-J
(Wikipediaより引用)

にセンサーの感度曲線をかけたものと、さらに今回のQBPの透過率

qbpf_g
(シュミットの販売ページより引用)

をかけたものとの面積比を比較すると、この明るさの比になります。太陽のスペクトルは調べるとすぐにでくるのですが、EOS 6Dセンサーの感度曲線が調べても出てきません。しかも天体改造してあるので、さらに良くわかりません。

それでもものすごくざっくりとした見積もりをしてみます。太陽のスペクトルが350nmくらいから900nmくらいまではそこそこ一定とし、一般的なCOMSセンサーの感度も350nmくらいから700nmくらいまでは一定と考えます。そうすると、QBPの透過率がある部分が465-510nmと640-685nmくらいまでと読み取ります。それぞれ透過幅はともに45nmとなり、合計90nmです。透過率は95%と程度としますが、ざっくり1としてしまってもいいでしょう。すなわち、350nmのうち90nmくらい通すと考えてしまうと、90/350 x 0.95 = 0.24となり、QBPと通すと月の光で制限されるような背景の場合の光量は24%程度になるということです。言い換えると、1/0.24 ~ 4なので、露光時間が4倍くらいで同じ明るさになるということで、実際の撮影結果にもかなり合っています。

これとは別に、月明かりがない場合の人工光による光害が支配的な場合、露光時間をどれくらい伸ばせるかはまた興味深いところです。これは場所や光源の種類に大きく依存するはずですが、LED灯でも上記くらいの改善比、水銀燈やナトリウム灯ならかなり高い改善比が期待できるはずです。


画像処理をした場合のQBPの効果


さて、一番興味のあるフィルターの効果の確認ですが、画像処理をかけた場合を想定して比較したいと思います。できるだけシンプルでわかりやすくするために、PixInsightで1枚どりの上記RAW画像に
  1. ScreenTransferFunctionでLink RGB Channelsをオフにして各色のロックを外してからオートストレッチをかけて
  2. HistgramTransformationで実際に画像に適用し
  3. JPGで保存
というような工程をとりました。

上記工程で、上の3枚の画像処理したものを比較してみます。

  • QBPなしの通常の撮影: ISO1600, 10秒露光
M42_LIGHT_6D_10s_1600_+8cc_20181222-22h07m33s760ms

  • QBPありでの撮影: ISO1600, 30秒露光
M42_LIGHT_6D_10s_1600_+14cc_20181222-22h21m29s692ms

  • QBPありでの撮影: ISO1600, 60秒露光
M42_LIGHT_6D_30s_1600_+10cc_20181222-22h28m12s224ms


検討してみます。
  • まず、10秒という同じ露光時間のものでも、QBPありの方が構造がはっきり出ていることがわかります。
  • 次に、QBPありの場合はさらに露光時間を延ばすことができ、より構造が鮮明になります。
  • QBPなしとQBPありで思ったより色の変化がないです。これは意外でした。
最近シュミットから出たM42のデモ画像は、思ったより赤が出ていたので、青が相当出にくいのかと思っていましたが、そうでもないようです。他の方の例を見ても青は思ったより普通に出ていたので、青の出方に関してもそれほど心配ないというのが今回自分で試した上での感想になります。


簡易画像処理

QBPを通して撮った画像をスタックして、画像処理をしてみました。と言っても、結局雲間での撮影で、きちんと撮影できたのは60秒の露光でわずか18枚の、総露光時間18分の画像です。

画像処理はPixInsightでプリプロセッシング、(フラット撮影はサボってしまったので)DynamicBackgroundExtraction (DBE)で背景ムラを整えて、PhotometricColorCalibration (PCC)で恒星の色を合わせました。恒星の色がうまく出るか心配だったのですが、確かに少し近似直線上から分布がずれるきらいはありましたが、それほどおかしくないレベルで色は出ているのかと思います。

結果だけ示します。

light_BINNING_1_integration_DBE_CP_Stretched_cut

本当はもっとあぶり出したかったのですが、かなり大きなレンジ(空間周波数が低いという意味)での色むらが残ってしまっていて、背景を出すと目立ってくるので、ここら辺までに押さえておきました。この色むらはフィルターのせいなのか、総露光時間が足りないからなのか、はたまた雲が常時流れていてその合間を縫っての撮影なのでその影響が出てしまったのかなどの判断はまだできていません。

本当はM42の後、もう少し淡いカモメ星雲を撮りたかったのですが、雲が多くなってきて撮影できるレベルではなくなってしまったので、ここで撤収しました。


Quad Band Pass フィルターを使ってみて 

うーん、今回のQBPかなり良いのではないでしょうか。満月下でこれだけ遊べれば十分満足です。色が思ったより変わらなかったのも、私的には気軽に楽しめるので、いい点です。今回は雲のために実際の撮影時間が短かったのでちょっとしたテストくらいでしたが、長い時間かけてじっくり撮影してみたいです。

元々の目的が、平日で遠征などできないときに、自宅の庭で月明かりや光害下でも気軽に撮影が楽しめたらというものです。このくらいの目的ならば十分に達成できそうです。あとは、月がない環境で自宅の光害下でどれくらい効果があるかを試してみたいです。以前の結果からも、透明度がいいときはそこそこ撮影も楽しめるくらいの環境です。ただし、暗い天体は今の所、フィルター無しでは自宅庭からでは全滅です。このQBPでもう少し暗い天体も狙えるようになれば、購入しただけの価値は十二分にあります。また試してみます。


赤道儀のセッティングの続きを少しだけ。初期アランメントで一発目に度くらいの精度で入ってくるかという話です。比較するのは、前回の記事で評価した

  • 水平インデックス法
  • 鏡筒水平法

の2通りの方法で実際どれくらいの誤差になりそうかというのを評価してみます。今回も極軸は十分な精度であっているとの仮定が入っています。あ、便宜上名前は勝手につけてしまいました。全然正式な名前ではありませんのでご了承ください。


水平インデックス法

1. 三脚の脚の長さででる水平度の誤差:
水準器を見ながら、最下部の脚の開きがざっくり1mくらいの幅で、手で3mmくらいの精度の脚の長さを合わせるのはできそうなので、
0.003[m] / 1[m] x 180[deg] / pi[rad] ~ 0.2 [deg] 

2. AVXの赤経体の直径が10cm(半径5cm)くらい、インデックスマークの幅が2mmくらいで半分の半分くらい幅の幅では少なくとも合わせられるとして、
(0.002[m] / 4) / 0.05[m] x 180[deg] / pi[rad] ~ 0.57[deg] 

3. 同じくAVXの赤緯体の直径が10cm(半径5cm)くらい、インデックスマークの幅が2mmくらいで半分の半分くらい幅の幅では少なくとも合わせられるとして、
(0.002[m] / 4) / 0.05[m] x 180[deg] / pi[rad] ~ 0.57[deg] 

4. 時刻の精度ですが、実際に時刻を打ち込んでからいつが赤道儀が動き出す最初かあまり確定していないのですが、30秒くらいの精度では合うとして、
0.5[min] / 60[min] / 24[h] x 360[deg] ~ 0.125[deg]


誤差は1から4までの2乗和のルートくらいになり、

sqrt(0.2^2 + 0.57^2 + 0.57^2 + 0.125^2) ~ 0.84[deg]

となります。この精度がどれくらいの意味を持つかというと、基本的にそのまま赤道儀の初期アラインメントの一発目がどれくらい中心からずれるかを示します。
  • 典型的な光学ファインダーの視野が、例えばVixenで7倍、50mmで実視界7度とのことなので、十分ファインダーには入るはずです。
  • 電子ファインダーで例えば、焦点距離50mm、1.8インチのASI178MCだと8度x6度と十分すぎる画角です。
  • 例えばFS-60Qで焦点距離600mmの鏡筒でフォーサーズサイズのASI294MCだと1.6x1.2度なので、まあなんとか入ってくるくらいです。
  • 例えばFS-60CBで焦点距離355mmの鏡筒で1/3インチのASI224MCだと0.8x0.6度くらいなので、ちょっと厳しいですね。


鏡筒水平法

一方鏡筒水平法では、誤差は結構変わってくるはずです。基本的に、三脚の脚の長さ調整の誤差と赤経のインデックスマークの誤差が、鏡筒においた水準器の精度に置き換わります。水準器の誤差はホームセンターで普通に売っている簡易なものでも簡単に0.1度くらいは出るようです。赤緯のインデックスマークの誤差は同じとします。全部の誤差を考えると

sqrt(0.1^2 + 0.57^2 + 0.125^2) ~ 0.59[deg]

くらいで、 
  • 光学ファインダーで電子ファインダーでも当然一発目で入ってきて、
  • 焦点距離600mmの鏡筒でフォーサーズサイズセンサーだとかなり真ん中に来て、
  • 焦点距離355mmの鏡筒で1/3インチセンサーでもなんとかギリギリ入ってくるくらいです。

確かにこのあいだの実際のテストでも、何度かやってみても鏡筒水平法の方が真ん中近くに来ていたので、あながち間違った見積もりでもないでしょう。

IMG_5887
水平インデックス法: 視野のギリギリで入るくらいです。入らない時もあります。

IMG_5895
鏡筒水平法: だいぶ真ん中に寄ります。視野に入らないことはまずありあません。

あと、鏡筒の光軸自身が赤道儀に取り付けたアリガタの向きからずれれている誤差は今回入れていません。これがずれていると、上の誤差以上のずれが出るかもしれませんが、見た目でそこそこ合わせているならそれほど大きくずれることはないでしょう。私は極軸を合わせた時に、カメラの視野の真ん中が極軸になるようにある程度光軸を合わせてあるので、実際に上の誤差よりも十分小さい範囲で合わせこまれていることになります。これはSharpCapで極軸調整した際に一回合わせてしまえば、それ以降アリミゾと鏡筒を外したりしなければあまりずれないので、一度はきちんと合わせておいてもいいかと思います。


いずれにせよ、水平インデックス法に変えて、鏡筒水平法にせよ、ファインダーレベルで一発目に入らないのはさすがに論外な誤差と言えるので、何か根本的におかしいと思っていいはずです。例えばりっくんさんは、AVXの設定を工場出荷時に戻したら、少なくとも一発目でファインダーに入るようになったというので、あまりに状況がおかしかったら他の原因を考えるのも解決につながるかもしれません。

先々週の赤道儀のセッティングの記事で、水平出しのことが議論になりました。コメントがいくつかあったのですが、かんたろうさんとその後もメールのやり取りをして、白熱した議論となりました。以後の議論では赤道儀の極軸は十分な精度であっていて、また、鏡筒も極軸と平行に設置されるものと仮定しています。

突き詰めていくと、今回の論点は、

  • Celestronの赤道儀Advanced VXで、ワンスターアラインメントでの初期アラインメントの時に、水平出しをしていることで、きちんと視野に入るかな入らないかに影響があるか?

というものになります。私は水平出しをしていなければ入らないという主張で、かんたろうさんは必ずしも水平出しをしていなくても、赤緯体が天頂方向を向いていれば、きちんと視野に入るというものです。

もう少し噛み砕いていうと、私はいつも赤道儀の水平出しをしてからインデックスマークを合わせるので、赤緯体は基本的に誤差の範囲内で天頂方向を向きます。かんたろうさんのは赤道儀の水平を出していなくても、赤緯体を天頂方向に向ければそれでよくて、その場合は赤経のインデックスマークが(水8兵からずれた分だけ)ずれた状態となるということです。赤緯体を天頂方向に向ける方法は、赤緯方向を90度傾けて鏡筒を東西に向ける。鏡筒の上に水準器を乗せて、赤経を調整して水平を出せば、赤緯体は天頂方向を向くというものです。

議論は平行線で、やはり実際に確かめなければ納得できなかったので、久しぶりに晴れた今日、試してみみました。

まずは、自分の方法できちんとワンスターアラインメントで入ることで、機器に異常がないかどうか確かめます。三脚についた水準器で赤道儀の水平を出し、

IMG_5885


SharpCapで極軸を1分角以下の精度であわせて、

IMG_5886


ワンスターアラインメントで手近なカペラを導入します。まあいつもやっているのでわかっているのですが、結果はきちんと視野の中に入ってきて、

IMG_5887


左がASI178に50mmのレンズをつけた電子ファインダー、右がASI294MCを600mmのFS-60Qに取り付けた鏡筒の視野です。両方とも明るいのがカペラです。電子ファインダー、鏡筒の視野ともに、赤いクロスの交点は一致しています。すなわち、右の鏡筒でクロス点にきているなら、左の電子ファインダーでもクロス点にきます。実際の導入はファインダーでざっくり0.8度くらい中心からずれた位置で導入されています。水平出しやインデックスマークの誤差もこれくらいのオーダーなので、特におかしくない精度です。機器に特に異常もないと思われます。


次に、三脚の脚の一本を数cm伸ばします。

IMG_5888


三脚につけた水準器はこの時点で全く水平を示していません。

IMG_5889


この状態で極軸をSharpCapを使って再び1分角以内の精度で合わせ直します。

IMG_5890


ここから、赤緯を90度程度傾けて、鏡筒に水準器を乗せて、赤経を調整してその水準器が水平になるようにします。

IMG_5893


この時点で赤緯体は天頂方向を向き、赤経のインデックスマークは当然ずれます。

IMG_5894


90度傾けた赤緯を戻して、赤緯のインデックスマークを合わせて準備完了です。この状態でワンスターアラインメントを実行します。

私の説が正しければ天体は導入できない、かんたろうさんが正しければ天体は導入できることとなります。果たして結果は...



なんと、見事カペラが導入されました。

IMG_5895


確かめるべく、ベテルギウス、リゲルなどもそのまま導入してみましたが、きちんと導入されます。これは完全に私の負けです。

さてここでやっと、なんできちんと導入されたのか考えました。答えはすぐにわかりました。私はワンスターアランメント(2スターアラインメントの最初でも同じです)のアルゴリズムは「赤道儀の水平」を仮定していると思い込んでいたのですが、実際にはアルゴリズムは「赤緯体が天頂を向いている」ということを仮定していたわけです。落ち着いてよく考えてみると確かに、水平を仮定するよりも赤緯体が天頂を向いていると仮定する方が、より条件が緩く、かつこれで十分だということがわかります。

すぐにかんたろうさんに電話して、私が間違っていたことを素直に伝えました。最後まで意見を変えなかった頑固な私に、ずっと付き合って頂いたかんたろうさん、どうもありがとうございました。改めてお礼を述べさせていただきます。


というわけで、赤道儀の初期アラインメントで一発目に天体を視野に入れるためには、必ずしも水平は必要ないと訂正しておきます。ただし赤緯体を天頂に向ける必要があることは変わりありません。かんたろうさんの方法を使ってインデックスはずれた状態で赤緯体を天頂に向けるもよし、赤道儀のの水平を出してインデックスを合わせて赤緯体を天頂に向けるもよしです。

ちなみに、言うまでもないかもしれませんが、「初期アラインメントで一発目」にさえこだわらなければ、水平も出す必要はないですし、赤緯体を天頂に向ける必要はありません。2スターアラインメント以上でマニュアルで一つづつ丁寧に導入していけば、自動導入可能な状態までもっていけます。


とにかくやっと納得しました。やはり自分で実際に試すのが一番わかりやすいです。かんたろうさんはじめ、コメントをくれたせろおさん、りっくんさん、いろいろお騒がせして申し訳ありませんでした。

このページのトップヘ