ほしぞloveログ

天体観測始めました。

カテゴリ:カメラ > EOS 6D

本記事は、一連の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を使うべきか、それともソフトなど使わずにシャッターを切るだけにするか。まだちょっと迷っています。


前回のASI290MMに続いて、


今回は、同システムを使ったEOS 6Dのクリーニングです。


これまでの6Dの経緯

でも6Dって4月初めにクリーニングしたんですよ。その時の結果が
IMG_3360_RGB_VNG_ABE
になります。 

でも、青い馬星雲を処理した時の途中の画像を見ると
masterLight_DBE
と、既にゴミが入ってしまっているのです。

その時のフラット画像(PixInsightでABEをかけてやっとこれだけ見えるようになりました)を見てみると
IMG_3474_RGB_VNG_ABE
ゴミがいくつか残ってますが、ほとんどのものはうまくフラット処理されています。ほんの数個、天体撮影中、もしくは天体撮影時とフラット撮影時で、動いてしまうゴミがあります。これを覗くことが目的と言えます。


新しいシステムとの比較

6Dでのセットアップはこのようになります。
IMG_2428
レンズが大きくて重いため、フルサイズカメラでも全くふらつくことがありません。光源が紫色に見えますが、これで天体改造した6Dだとちょうどホワイトバランスが取れています。

今回の新しいシステムで先と同じセンサーの汚れを見てみると、
Capture_00017 15_19_14_WithDisplayStretch
と、遥かに汚れていることがわかります。汚れ自体は特に変わっていないはずです。よく見えるようになっただけです。

フラット補正などもしていなくて、SharpCapのストレッチだけでこれだけ見えるのは、やはり周辺減光の少ない中判レンズを使ったからかと思います。


このシステムの課題も見えた

ただし、この画像をコンスタントに出すのは難しいことも分かりました。

まず、SharpCapに6DをASCOM経由で接続します。この機能自身がまだベータ版のみで使えるものです。


ところが、この時に静止モードでsnapshotなどどの撮影方法をとっても、ストレッチした見たままの画像で保存することができず、ストレッチ前のRAWのような状態でしか保存することができません。仕方ないので、見たまま保存するためにライブモードにしますが、シャッターを切り続けることになります。まあ、これは気にしないこととしましょう。

とことが、シャッターを切り続けると、どうもこのライブモード時のシャッター毎に明るさが一定にならないようなのです。6Dのセンサー性能を測定した時


同様に明るさが一定にならずに調整をひたすら繰り返し、1000回くらいシャッタを切ったことを思い出しました。どうもSharpCapでDSLRを接続した時のライブモードのバグのようです。そのため、今回は上の画像のとことまで炙り出さずに、少し見にくいですが、多少明るさがばたついてそこそこ見えるくらいになるように炙り出すことにします。


クリーニングスタート

上記画像をそのように調整すると

Capture_00003 15_23_11_WithDisplayStretch_start
と多少暗くなりますが、これがスタートになります。

まず、前回の記事のASI290MMでも使った、フルサイズ専用のスワブを使います。
センサークリーニングスワブ
 

一度だけ拭いたのが以下になります。
Capture_00001 15_28_34_WithDisplayStretch_swab1
少し左上に残っていますが、ここで止めればよかったんです。


泥沼の始まり

気に入らなくて、もう一度同じスワブで拭いたら下のようになりました。
Capture_00001 15_31_36_WithDisplayStretch_tool2
左上のゴミは少し少なくなりましたが、右の方に縦にゴミが見事に並びました。ここから迷走です。

次はスワブにエタノールをつけて拭いた場合です。
Capture_00001 15_33_17_WithDisplayStretch_ethanol
ゴミはかなり取れましたが、拭きムラが残っています。

拭きムラがさらにひどくなると以下のようになります。
Capture_00001 15_34_41_WithDisplayStretch
でもこれは、乾いたスワブで何度も拭き取ることできれいにすることができます。このときに新しいスワブを出しました。ASI290MMから合わせて4本目です。でもその代わりに下のようにいつのまにかゴミがついたりします。
Capture_00001 15_36_23_WithDisplayStretch_after_mura

もうこうなってくると泥沼ですね。

この後、拭きムラとゴミをひたすら繰り返し、一進一退。毎回のクリーニングのたびに保存した画像だけで20枚。そのうち嫌になって画像も残さなくなって30回以上色々試したので合計50回以上、拭いて、モニターして、というのを繰り返しました。その中で一番酷かったのがこれでしょうか。拭きムラは最悪、かつゴミもまたついてしまっています。
Capture_00001 15_51_10_WithDisplayStretch
でも重要なことは、傷さえつけなければ、ゴミも拭きムラもとることはできるということです。


最終結果

もう最後の結果だけ示します。上の画像から1時間半後の画像です。
Capture_00001 17_02_14_WithDisplayStretch_ok
まだ濃いのが一つ、細かいのはいくつも残っていますが、これが限界でした。この最後の一個を触る勇気が出ませんでした。

おそらくこのゴミもフラット補正さえすれば全く問題ないレベルになるかと思います。これで満足することにしました。


まとめと今後

とにかく、大きなサイズのセンサーはキリがないことがよくわかりました。スワブを使ってもかなり丁寧に吹かないと、すぐにムラになったりゴミが残ったりします。意外にスワブが何度か使い回しが効くこともわかりました。ゴミはそこそこコントロールできますが、全部いっぺんにというのはかなり運に任せるしかないです。

ゴミがある程度の数になったら、大体の位置はわかるので、PENTAX イメージセンサークリーニングキット O-ICK1 39357(通称ペンタ棒)を使った方がいいのかもしれません。



次はこれを仕入れてやってみることになりそうです。

とにかく今回は疲れました。毎回の吹でかなり気を使うのと、先が見えないことです。毎回見るシステムを組んでこれです。もしかしたらセンサークリーニングは素直にメーカーに出すのがいいのかもしれません。でも天体改造をしたカメラも受け付けてくれるのでしょうか?


今回はEOS 6Dのセンサーの掃除についてです。方法はテストも兼ねた自己流ですので、決して自らやることを勧めません。最悪、センサーに傷をつけてしまう可能性もあります。参考程度にしてください。もし自分でやる場合には、あくまで自己責任でお願いします。


そもそもなんで清掃か? 

まず、おとめ座銀河団を撮影した時のフラットフレーム。

masterFlat_RGB_VNG_clone_ABE

かなりひどいですね。実際には小さな点はフラット補正をするとほぼ問題なくなってしまうので、そのままでもいいのですが、一応比較してみます。以前も出した画像ですが、

フラット補正無し
masterLight_integration_DBE1

フラット補正あり
integration1_DBE

やはり、フラット補正をしないと壊滅的に細かいゴミの跡が出ます。フラット補正をすると小さいゴミはほとんどわからなくなりますが、それでも大きなゴミはどうしても目立ってしまいますし、おそらく撮影中や撮影後に微妙に動いてしまい、それが原因で補正しきれなかったり、過補正になったりしてしまいます。 

ただし、これはかなり炙り出した状態です。実際の仕上げでは背景をもう少し暗くするのでここまでは目立ちませんが、それでも何らかの補正は必要なレベルです。


現状確認

まずは現状の6Dの汚れを見てみました。方法はフラット画像を撮影する時と同じです。ただし、そのままだと何も見えないので、撮影したRAW画像をPixInsightで読み込み、DeBayerしてABEの4次でフラット化して、SFTでオートストレッチしてゴミを見やすくしています。オートストレッチでもまだ見にくい場合は適当にマニュアルでストレッチしています。

最初は光が直線に入ってくる方がいいと思い、適当なレンズを使い、(ズームで80mmにしてました)F値を50とかなり大きくして光を絞って見てみました。小さな点ですが、上と同じような位置にたくさんゴミがあるのが分かります。

IMG_3342_RGB_VNG_ABE
小さな多数のゴミがあるのが分かります。

IMG_3342_RGB_VNG_ABE_Preview01
左真ん中に見える2つの点の下側を拡大。


この画像で見ると、大きいものでも直径10ピクセルくらい、小さなものだと5ピクセル以下です。1ピクセルが6.3μmなので、たとえ10ピクセルあったとしても63μmの大きさなので、なかなか目で見える大きさではありません。実際、センサー面をじっと目を凝らして見ても全く何かあるようには見えませんでした。

また、大きなシミのような5-6個みえますが、これはおそらくセンサー面から遠いレンズ面などにある汚れかと思います。この時のレンズは中古の安いジャンク品なので、カビなどがあるのかもしれませんが、いずれにせよセンサー面とは関係がないので無視します。


せっかくなので試しにいろいろやってみる

さて、これらを取り除いていきます。清掃は、6Dのメニューで「センサークリーニング」を選びます。

7244D6A9-D03B-4579-A7D2-81A22BBCB180

FB8C48DB-C57B-4506-A08A-D5A1F6734B02

2A1F756F-4E75-4096-90C3-4EFAEC32542F

最後の画面で「OK」を選択すると、シャッターが上がって清掃できる状態になります。清掃後は画面に出ているように、電源を切ることでシャッターが閉じます。

清掃後はFS-60CBにEOS 6Dを取り付け、iPadのColorScreenというソフトで出した白い画面をフラット光源がわりにしてゴミを撮影しています。

まずはダメな例です。綿棒にエタノールを染み込ませ直接こするとどうなるか?
IMG_3347_RGB_VNG_ABE
問題外ですね。綿棒の繊維が飛び散ってしまっています。

次に、FUJIFILMのクリーニングペーパーを、(センサーが奥の方で指だと届かないので)綿棒の綿のところに蓋をするように巻き付け、清掃します。エタノールは渇きカスが残ることがわかったので、乾燥したままのクリーニングペーパーを使いました。

IMG_3348_RGB_VNG_ABE

綿棒の繊維は取れましたが、まだ大きなゴミが1個、小さなゴミがたくさんあります。ただ、最初と位置は変わったようです。

同様にクリーニングペーパーを綿棒につけ縁から順に、一方向に丁寧に清掃していきます。
IMG_3354_RGB_VNG_ABE
かなり良くなりましたが、右下縁にゴミが溜まっています。これは縦横に順に清掃して最後にゴミが行き着いたところです。

さらに、同様にクリーニングペーパーを綿棒につけ4角を重点的に清掃。
IMG_3355_RGB_VNG_ABE
4隅はきれいになったが、逆に真ん中は悪化しています。


非接触の清掃も試してみる

上の状態から、ここで一度缶のエアーダスターを試してみます。
IMG_3356_RGB_VNG_ABE
いくつか大きはものは取れましたが、いつくか新しいゴミも付きました。でも、細かいゴミの大勢はかわらず。

更に、カメラのセンサークリーニング機能を試してみました。合計5回やりました。
IMG_3357_RGB_VNG_ABE
エアダスターと同様に、目立つのがいくつか取れましたが、大勢はかわらずです。


清掃方針

これまでの経験から
  • 大きなゴミはエアダスターが効く。
  • 小さなゴミはエアダスターもカメラのクリーニング機能もほとんど役に立たない。
  • エタノールは乾きカスが出ることがあるので、必ずすぐに乾いたクリーニングペーパーで拭き取ること。
  • 乾いたクリーニングペーパーを綿棒に巻き付けてセンサー面を拭き取ると、小さなゴミを移動することはできる。
  • 拭くたびに毎回チェックすべし。 
というようなことがわかってきました。

このことを踏まえて、以下のような手法で清掃を改めて行います。
  1. 最初にエアダスターで大きなゴミを取る。
  2. 最初はエタノールを綿棒につけ、その上にクリーニングペーパーを巻き付け拭く。
  3. 乾いたクリーニングペーパーを綿棒に巻き付け、丁寧に一方向に拭き取り、最後に溜まった部分も丁寧に拭き取る。


結果

上記手順で清掃した結果が、以下のものです。
IMG_3360_RGB_VNG_ABE
真ん中はそこそこ綺麗になりましたが、左上角に大きなのがいます。でもここらへんで力尽きました。簡単そうに書いてますが、結構苦労しています。小さなゴミも残ってますが、下手に触ると悪化することもあり、ここら辺が妥協点かと思いました。というか、素人が適当にやるとこれくらいが限界なのかと実感しました。細かいゴミは、実際にはフラット補正してしまえばほとんど問題にならないと思います。左上が問題になるようなら、再び清掃します。


まとめ

今回はセンサーの実際の汚れを見て、それを清掃するとどうゴミが動くかとかの反応を知ることができました。市販のクリーニングセットがヘラみたいなの形になっている理由もよくわかりました。センサーの端の方にたまるゴミを撮るためですね。

市販のクリーニング用品も試してみたくて、アマゾンで安めのツールを注文しました。



届いたらまた試そうと思います。

センサーの清掃は本来はメーカーに依頼するべきなんだと思います。でも天体改造をしているので、なかなか頼む気になれず、今回我流で清掃してみました。結論を出すのは再度撮影してからだと思いますが、少なくとも傷がつくようなこともなく、汚れもコントロールできることがわかりました。角の方に溜まるゴミを取るのはまだ課題ですが、これは市販ツールで解決することを期待しています。


前回の6Dのユニティーゲインの記事ですが、難しいという話を聞いたので、できるだけわかりやすく解説してみようと思います。




コンバージョンファクター


IMG_2032

何はともあれ、まず重要なのはコンバージョンファクター (conversion factor) とか、gain (ややこしいのですがISOに相当するgainとは全然の別の意味です。以下区別するために、コンバージョンファクターの意味ではgainやゲインという言葉は使わず、ISOの意味でのみgainもしくはゲインと書きます。)とか呼ばれている、センサーで発生する電子の数と出力信号のカウント数を変換する係数で、単位は[e/ADU]になります。eは電子1個の単位、ADUはADC (Analog to Digital Converter) でカウントする1カウントの単位です。発生する電子の数は後で書きますが、検出される光子の数と比例するので、ここではとりあえず光子の数と言ってしまうことにします。

このページの結果によるとEOS 6Dの場合、例えば、ISO100のとき、コンバージョンファクターは5.6413 [e/ADU]で、光子が6個近くセンサーの1素子に入ってやっとADCのカウントが1増えます。6Dの場合14bit = 16384なので、5.6413 x 16384 = 92427個の光子が1素子に入ると、その素子のカウントは一杯になり「飽和」状態になります。このブログでは「サチる」とか、「サチった」とかいう表現をしています。これは「飽和」の英語Saturationから来ています。

例えば、ISO400のとき、コンバージョンファクターは1.4178 [e/ADU]となり、光子が1.5個くらい入るとADCのカウントが1増えます。

この表から考えると、ISO575くらいが実現できるなら、コンバージョンファクターは1 [e/ADU]となり、光子が1個入るとADCのカウントが1増えます。このときのゲインをその名の通り、ユニティーゲイン(unity gain)と呼びます。ユニティーは1という意味ですね。ISOなので、ユニティーISOとか読んでもいいでしょう。呼び方はまあどうでも良くて、重要なのはセンサーで検出される光子1個がADCを1カウント増やすという、1対1の関係です。

CMOSセンサーの解析はこのコンバージョンファクターの値を求めるところから全てが始まります。


コンバージョンファクターの原理

ではコンバージョンファクターを求めるためにはどうしたらいいのでしょうか?まずは原理式を理解してみましょう。CMOSセンサーをある出力ゲインに固定して測定した信号\(S\mathrm{[ADU]}\)とそのときのノイズ\(N\mathrm{[ADU]}\)には以下の関係があります。

\[(N\mathrm{[ADU]})^2=\frac{S\mathrm{[ADU]}}{f_{\mathrm{c}}\mathrm{[e-/ADU]}}+\frac{(N_{\mathrm{read}}\mathrm{[e-]})^2}{(f_{\mathrm{c}}\mathrm{[e-/ADU}])^2}\]

このとき\(N_{\mathrm{read}}\mathrm{[e-]}\)は読み出しノイズ、\(f_{\mathrm{c}}\mathrm{[e-/ADU]}\)がコンバージョンファクターです。

右辺2項目の読み出しノイズは十分小さい仮定として、簡単に

\[(N\mathrm{[ADU]})^2=\frac{S\mathrm{[ADU]}}{f_{\mathrm{c}}\mathrm{[e-/ADU]}}\]
を考えます。

画像を撮影して、その1ピクセルの明るさ\(S\mathrm{[ADU]}\)を測り、その1ピクセルの明るさがどれくらいバラけているかを多数プロットしてやればいいのです。

この式自身の証明はこのページの最後のおまけの部分を見てください。ちょっととっつきにくいと思うかもしれませんが、ショットノイズの関係式だけから数学的に綺麗に出てくるので、話としては至極単純です。逆にこの関係式があるので、多数の点数をとってくれば統計的にコンバージョンファクターが確定するというわけです。多数の点をとってくるのは、画像ファイルが多数の点でできていることを考えると十分可能で、アイデア次第で多くのサンプルを取り出すことができるわけです。この関係式をものすごくうまく利用してますよね。

多くのサンプルを取り出すのはいろいろな方法があります。
  1. 一画面内に暗いところから明るいところまで写っている、同じ画角の景色などを多数枚撮影し、ある位置のピクセルに注目し、その平均値とバラけ具合を多数枚にわたって見る。多数のピクセルに対して同じことをする。
  2. フラットに近い画像を露光時間を変えて何枚か撮り、一枚のある100x100くらいのエリアの平均値とそのバラけ具合を見る。露光時間ごとにプロットする。
  3. 星などの適当な画像を2枚撮影し、その2枚の画像の差を取り(信号を消して、ノイズの2乗和のルートをとるということ)、その中の明るさが一定のエリアの平均値とバラけ具合を見る。明るさの違う領域で、同じことをしてプロットする。
などがあります。私が一番最初に学んだ方法は1.でした。SharpCapは2.の方法をとっています。最初に紹介したページ(大元はこのページです)やPixInsightでは3.を使っています。3.が撮影枚数が2枚と少なく、一番簡単でしょうか。工夫次第でまだ測定方法はいろいろ考えることができると思います。

PixInsightでの測定方法はNiwaさんが秀逸なタイトルをつけて詳しく解説してくれています。




実際の測定例

実際に信号とそのバラつきをプロットしたグラフを見てみましょう。まずは2.の例のSharpCapで測定した場合です。6Dの計測の時にグラフを写真に取り損なったので、ASI294MCの測定の時の写真を示します。

IMG_3262

一番右が、横軸明るさS、縦軸ノイズNの2乗でプロットしたものになります。測定点を結ぶと一本の線になり、その傾きの逆数がコンバージョンファクターになります。この場合、横軸が5000くらいの時に縦が1300くらいなので、傾きは0.26、その逆数は1/0.26=3.85[e/ADU]くらいになります。すなわち、光子3.85個入って、やっとADCのカウントが1進むということです。

次の例は自分で画像を撮影して測定した時の結果です。SharpCapがやる過程をマニュアルでやったような形になります。すなわち、同じゲインで露光時間を変えて何枚か撮影し、あるエリアの明るさとバラけ具合を測定すると言うものです。画像解析はMaltabを使ってやりました。Matlabを使ったのは、画像読み込みが楽なのと、平均や分散などの統計解析が揃っているからです。別に一枚一枚Photoshopとかで解析しても原理的にはできるはずです。センサーはASI290MMでモノクロのCMOSカメラです。モノクロはきちんとメーカー値とも合うのですが、いまだにカラーの場合でうまく計算できたことがないので、もうここ2年ほど悩み続けています。

Conversion_Factor_ASI290MM_std

同様に横軸が明るさで縦軸がノイズの2乗のN^2になります。測定点が一直線で近似できるのがわかると思います。そのグラフの傾き0.306の逆数1/0.306=3.26がコンバージョンファクターになります。

一眼レフカメラの例は、このページに出てますね。「Details of measurements at each ISO setting」のところからの一連のグラフになります。このようにISO(出力ゲイン)を変えて、順次ISOごとのコンバージョンファクターを測定していきます。コンバージョンファクターが1になるところが「ユニティーゲイン」「ユニティーISO」「ユニティーゲインの時のISO」(言葉だけを知っていても意味がないです、逆に意味をきちんと理解していれば、言葉が多少違っても通じますね)ということになります。

ところが上にも書きましたが、SharpCapではISO(ゲイン)を変えて各コンバージョンファクターを測定することをサボっています。どうせ、コンバージョンファクターはゲインに比例するので、一番低いISOのコンバージョンファクターだけを測って、あとは出力ゲインで割ってやることで、測定回数を劇的に減らしています。これは測定の自動化をするために考えた苦肉策(良く言えば簡単に測定できる方法)といえるでしょう。


読み出しノイズ

これまでのどのグラフでもそうですが、傾きの逆数がコンバージョンファクターになり、信号Sが0の時の切片がその時のISOの読み出しノイズになります。ただし、読み出しノイズに関してはこのページでも書いてあるように
but, for the readout noise it is preferable to measure directly the deviation on a bias image - the result is more precise
と書いてあるように、バイアスファイルから直接測定せよと書いてます。奇しくも、ノイズ会議の時に議論したバイアスと読み出しノイズは同じかというというに対する回答になっていて、やはりバイアス(オフセットとかいう概念と同じ)ファイルで測定されるノイズは読み出しノイズと考えて良さそうです。

読み出しノイズの測定は、カメラにキャップをして最小光量で、時間と共に大きくなるダークノイズを無視するために最小時間で撮影した画像を使います。やはりバイアスの撮影と同じですね。こうやって撮影された画像は読み出しノイズに支配されています。読み出しノイズの直接的な測定についてはこのページを参照してください。
 


測定からいろいろなことがわかる

一連の測定の結果から、非常に重要な幾つかの結論が出ます。例えば、このページで言っている主要なことは
  • Unity gainはISO575のところにある。
  • これは個々のISOについてコンバージョンファクターを測定した結果から来ている。
  • コンバージョンファクターの測定方法は、各ISOで2枚撮影して、その差分から明るさとノイズの関係を評価した。
  • 読み出しノイズはISO6400までは減ってきていて、それ以上のISOでは一定値。なので、暗い天体はISO6400を使うのがベスト
  • 飽和容量は13235ADUと考える(と書いてあが、根拠は不明。14bitだから16348ADUと思ったら、それより小さいので何かかから測定したのか?)。
  • ダイナミックレンジはISO400までは一定で、それ以降は減り始める。なので明るい天体はISO400以下で撮影するのがいい
  • 中間ISOは使うな!例えばISO1000はISO800と同じ読み出しノイズでかつダイナミックレンジは小さい。
ということです。


コンバージョンファクターやユニティーゲインは何の役に立つのか?

答えを一言で言うなら、コンバージョンファクターという(ゲイン依存の)変換係数があるおかげで、ADCの値を読むだけでありとあらゆるものを電子の数で考えることができるようになるので、「単位が揃って便利」だということです。

例えば飽和電子容量(full well)です。本来の飽和電子容量の測定の仕方は、十分にサチレーションを起こすくらい明るい光をカメラに入射し、その時のADCの値の平均値を読み取り、それをコンバージョンファクターで電子の数に変換してやります。コンバージョンファクターが分からなけれが飽和「電子」容量とは言えずに、飽和「ADC」容量とかになってしまいますね。

読み出しノイズの測定もそうです。バイアスファイルは読み出しノイズに支配されています。この時の各素子の明るさのばらつき具合が読み出しノイズになるのですが、当然のことながらこれらの測定は全てADCの出力を見ているので単位は [ADU] で出てきます。こんな時に先に測定したコンバージョンファクターがあると、あーら不思議!なんと電子の数 に変換することができ、普通の読み出しノイズの単位[e-]になります。

逆に言えば、どれだけ画像ファイルからADCでカントされた数を数えることができても、コンバージョンファクターがないと、電子、光子のところまで持っていくことができません。と言うわけでコンバージョンファクターがいかに大切かおわかりいただけましたでしょうか?

では、ユニティーゲインがどうして必要かと言うと、実はそこまで重要な値ではないんですよね。ADU1カウントと測定された電子1個が等しいと言うくらいです。まあ、目安ですね。


電子数と光子数の関係

さらに光子の数sと、センサーで数える電子の数nが、定数で変換できます。この定数をシステム効率ηなどと呼び
\[\eta=\frac{n}{S}\]
と表すことができます。通常はシステム効率は1以下の値をとりますが、ここでは簡単のため1としています。

ポイントはこのシステム効率が内部回路のゲインや積分時間などによらないということです。なので、出てきた電子の数を数えるということは、幾つ光子が入ってきたかが直接わかるため、重宝されるというわけです。

その一方、ADCのカウント数とセンサーで出てくる電子数の関係は内部回路のゲインに依存してしまうため、便利でないのです。

ISOと実ゲインの関係

前回測定していまだに腑に落ちないISOと実ゲインの測定ですが、同様の測定例がどこを探しても見つかりません。ISOとコンバージョンファクターのグラフはすぐに見つかります。これってもしかしたらISOの線形性がほとんどないから出回らないのでしょうか?だとしたら、前回示したグラフは何か失敗しているかと思ったのですが、逆に貴重なのかもしれません。

自分でも各ISOのコンバージョンファクターを測ってみるのが次の課題でしょうか?少なくとも3種類の測定の仕方は考えられるので、それぞれで違いが出るかとかも興味があります。そこで測られたコンバージョンファクターは、やはり実ゲインに比例しているはずなので、もし前回の測定結果のように実ゲインがISOに比例しないなら、どこに矛盾があるか突き止めていくのもまた面白そうです。


おまけ: Unity gainで撮影する意味

unity gainで撮影することには、ほとんど何の意味もないです。これは測定される電子数とADCのカウントの比を表している単なる係数に過ぎません。

たまにunity gainで撮影することが有利だとかいう話を聞くことがありますが、根拠が全くありません。その際によく話されるのが、ADCの1カウント以下で電子(光子でもいい)を測定できないからとかだとかが理由とされますが、そもそも光子を1個だけ数えるのは(量子力学で考えるとあたりまえですが)原理的に不可能です。多数の(単位時間あたりに数にばらつきのある)光子が測定され、統計的に平均値をとると何個の光子が来ていたと言えるだけです。

なので、unity gainに拘らずにISOを決めていいのですが、原理的に考えると最適なISOはDynamic Rangeを損なわない最大のISOということになります。もちろんこれは対象の明るさによってきちんと考えるべきで、明るいもの(昼間の景色や恒星など)がサチるのを避けたいならばISOを下げたほうがいいですし、暗いものを撮影するときはダイナミックレンジを犠牲にしてでもISOをあげた方がいい時があります。


まとめ

コンバージョンファクターについて、できうる限り簡単に書いてみました。みなさん理解できましたでしょうか?わかりにくいところとかありましたら、コメント欄にでもお書きください。

もう少し6D測定を続けてみたいと思います。他の結果と矛盾がないのか、それとも何か間違っているのか?どのような設定で撮影すればいいかの根拠になっていくので、これはこれでかなり楽しいです。



とうとう念願のEOS 6Dのユニティーゲイン(unity gain、電子とADCの1カウントが等しくなるゲイン)を測定してみました。といってもまだ思うところもあるので、暫定的な結果です。


これまでの経緯

使ったのはSharpCapで、昨年9月ころの3.3βから一眼レフカメラをサポートし出したため、もしかしたらLive view機能でシャッタを切り続ければ、センサー解析機能を使って一眼レフカメラのセンサーも解析できるのではと思ったからです。



ShapCapを使ったセンサーの解析手法についてはASI294MCなどを測定していて、メーカー値とかなり一致することがわかっています。





6Dでの測定

さて、実際に6DをSharpCapに繋いで、「センサー解析」を使用してみましょう。使ったSharpCapは2021/3/10リリースの最新の4.0.7493.0(BETA)の64bit版です。

ところで、なんでわざわざカギ括弧付きでセンサー解析と書いたかというと、メニューとカメラ制御の部分の日本語化に貢献しているからです。いのさんと智さんも貢献してくれました。特にいのさんは私の拙い訳をかなりまともな用語に直してくれました。

さて、まずセンサー解析を立ち上げますが、やはりどうも「ライブビュー」モードにしないとそもそも機能しないみたいです。逆にいえばライブビューモードにさえしておけば、あとはほとんどCMOSカメラと同じ操作になりました。

まず大事なのは光源の明るさ設定。目標はBrightnesのとこの50%付近に鋭いピークが立つこと。私は以前と同様にiPadのColor Screenというアプリを使い、Hue0、Saturation0、Brihgtness 32となるようにして、6Dのレンズを外しそのままiPadの上にセンサー面が向くように置きました。エリア選択がありますが、選択範囲内で周辺減光など光のスロープがあるとノイズが必要以上に大きく出てしまうので、センター付近の比較的狭いエリアを選びます。円状のレチクルを出して、その一番小さい円に内接するように正方形のエリアを決めました。あとは初期の光の量がまずいと怒られるので、ISOを100、露出時間を250msとしたら解析スタートの許可が出たので、そのまま進めます。

IMG_1980
セットアップの様子。

あとはひたすら待つだけです。CMOSカメラと違い、1フレームづつ撮っていくので時間とコマ数がかかります。終了まで約1時間ちょっと、1000回弱のシャッターを切りました。SharpCapからASCOMを通じて6Dの露出時間とISOを随時切り替えてシャターを切ります。ただしSDカードに記録はしないため、バッテリーは1000枚撮影したあともまだフルゲージ残ってました。

IMG_1972
下にフレーム数と時間が出ています。

今回測定したゲインはISO100からISO500までの8段階でした。それぞれのゲインで、センサーの読み取りから、暗すぎたりサチったりしないように適当に露出時間にフィードバックして適した露出時間を決めるため、それだけで何度もシャッタを切るので、どうしてもシャッター回数が多くなってしまいます。

一眼レフカメラのシャッター回数は寿命に繋がるので、無駄な機械シャッターを切らないように少なくとも何度かCMOSカメラで練習することをお勧めします。

以前のバージョンの測定の時には、この適した露出時間がなかなか決まらなくて長くしたり短くしたりを永遠と繰り返すバグなどもありましたが、今回はそのようなことはなかったです。ただし、測定中に露出時間も同じでISOも同じなのに撮影した画面に出てくる明るさがあからさまに変わって、安定しないような時がありました。原因はわかりませんが、ここは少し結果に対して不安要素となっています。

途中ダークノイズの測定のためにキャップをしたり、終わったら外したりしますが、それらは指示に従えばいいでしょう。 


測定結果

結果を見てみます。

IMG_1977

Gain Valuee/ADURead Noise (e)Full Well (e)Relative GainRel. Gain (db)Dynamic Range (Stops)
1005.6927.18931441.000.0011.74
1254.4526.69730541.282.1111.42
1603.2912.66730541.734.7412.06
2002.4911.87407922.287.1711.75
2501.9011.393107239.5411.41
3201.365.77223064.1812.4111.92
4000.954.99155525.9915.5511.60
5000.744.87121217.6817.1111.28

グラフ化しておきます。一番下のグラフは読み出しノイズをADUで表した場合です。ISO300くらいまではゲインが上がると共にe-単位での読み出しノイズが小さくなっていくのでほぼ一定で、ISO300を超えるとADUで見て読み出しノイズが上がってきます。これはISO300を超えると実際の画像で見て読み出しノイズが大きく見えてくるということを示しています。

6D_gain_graph_cut


これだけみていると、unity gain (unity ISO)は e/ADUが1になるところなので400を切るところ程度と読めます。ところがこの値は少し疑問が残ります。

Read noiseについては3段階に分かれているようなので、ここから3種のアナログゲインがあるのではとかの推測ができます。さらに、細かいゲインについてはデジタルゲインの可能性が高いと言えます。


考察

まずはこちらのページを見てください。


6Dのセンサーについて測定しているページです。このページではunity gainはISO575であると言っています。今回自分で測定したISO400弱とというのとは1.5倍くらいのズレがあります。

わかりやすくするために上記ページの表のISO800までをお借りします。

ISOgain[e-/ADU]read noise[e-]DR[dB]
505.641327.4868.7
1005.691127.5868.7
2002.773213.6668.6
4001.41787.5367.9
8000.72914.4566.7

Read noiseについてはISO100、200、400、800にアナログゲインが入っていると考えられるので、今回測定した結果と矛盾ないと考えられます。

gain[e-/ADU]については少なくとも今回測定した値の中でISO100のところはgainもread noiseも上の測定結果とよく合っていると言っていいと思います。ところがそれ以外のISOのところは全て1.5倍くらいずれています。これはどういうことなのでしょうか?

この違いは、今回SharpCapが簡易的な測定をしていることに起因します。先に示して表の中で、実際に測定しているところを赤くしてみます。

Gain Valuee/ADURead Noise (e)Full Well (e)Relative GainRel. Gain (db)Dynamic Range (Stops)
1005.6927.18931441.000.0011.74
1254.4626.69730541.282.1111.42
1603.2912.66539621.734.7412.06
2002.4911.87407922.287.1711.75
2501.9011.393107239.5411.41
3201.365.77223064.1812.4111.92
4000.954.99155525.9915.5511.60
5000.744.87121217.6817.1111.28

この赤いところ以外は実測ではなく、実測した値から計算しているに過ぎません。例えば
  • e/ADUのISO100の5.69以外のところは、5.69を単にRelative Gainで割った値に過ぎません。
  • Full Wellも同様で、ISO100のところの93144を単にRelative Gainで割った値に過ぎません。
  • Dynmic Rangeは計算値のFull Wellを実測のRead Noiseで割ってbitで表しただけです。
こうやってみると、Dynmic Rangeが今回測定した範囲の中であまり変わらないのも理解できます。なぜなら、Read Noiseがアナログゲイン(ISO)に比例してよく下がってくれている範囲内だからです。今回の測定範囲外は上記ページを見てもらえばよくわかります。ある一定値以上のISOでは、これ以上いくらアナログゲイン(ISO)をあげても、Read Noiseが他の要因である一定値に制限されてしまう一方、Full Wellは下がっていくために、ダイナミックレンジが小さくなっていきます。

また、Dynamic Rangeで考えたら、最大値とほとんど変わらないISO1000位までまではISOを上げたほうが得。Dynamic Rangeの落ちを1bitまで(半分になるということ)許容するとしたら、ISO1600までは許容範囲で、ISO3200だとそれよりほんの少し損をするといったところでしょうか。なので私がもし使うならISO800か1600、もう少し明るさが欲しい場合はぎりぎりISO3200ということにするのかと思います。


今回の測定の問題点

さてここで、今回実測したRelative Gainのところに注目します。通常はISO100を基準にISO200なら2倍、ISO400なら4倍になるはずですが、結果はISO400で2.3倍、ISO800で6倍でどうも1/1.5倍程度小さく測定されてしまっているようです。しかも線形性もあまりないという冴えない結果です。先に、測定中に撮影した明るさが一定にならないと書きましたが、これが悪さをしている可能性があります。もしISOと実際のゲインが理論値で一致しているなら(ISO200なら2倍、ISO400なら4倍とかいうこと)unity gainはISO569になるはずで、上記ページの結果ともほぼ一致します。

SharpCapでの測定方法は、CMOSカメラが前提のためにシャッター回数を気にしなくてため、何枚も画像を撮り、それらの同じエリアを使うことで、時系列でずれたようなデータを使い解析しています。一方、1枚の暗いところから明るいところまで含まれるような画像を撮影し、その画像の中で空間的にずれたようなデータを使うことでも同様の解析ができます。

というか、普通は後者の方が素直なやり方で、SharpCapは測定を自動化するために時系列のデータを使っているというわけです。最初SharpCapのやり方を見た時に「上手いやり方だなあ」と思いましたが、測定してみると簡易的な方法であることはすぐに認識できて、しかも今回一眼レフカメラのシャッター回数のことを考えると、やはり1枚の画像で解析した方がいい気がしてきました。

明るさのところをもう少し改良して、もう一度くらいなら測定したいと思います。シャッターの寿命が10万回としたら、1回の測定でシャッター寿命の約1%を使ってしまう計算なので、SharpCapで測定するのは最小限に抑えておいたほうがいいでしょう。

むしろISO100の結果だけは正しく測定していて、結果も矛盾なく正しく得られていると思われるので、あとは自分で別途ゲインを測定したほうがマシそうです。


ISOと実ゲインを実測

というわけで、ISOと実際に撮影できる明るさを実測してみたいと思います。

測定方法はSharpCapで測った時と同様に、iPadのアプリColor Screenを使い、そこにカメラを載せて、ISOを変えて撮影します。ただし、SharpCapでの測定がばらついたのでその反省を生かし、外光の影響ができるだけないのようにしました。まず、Color Screenの明るさを32から128の4倍にします。さらに、Color Screenの上に薄い紙を一枚敷きiPadの表面の反射の影響をなくすようにします。先の測定ではレンズなしのセンサー面を暴露しての測定でしたが、これもレンズをつけてレンズの先の光だけがセンサーに入るようにしました。

露光時間を1/50秒に固定して、ISOを800から100まで下げて撮影していきます。というのはISO800でサチらないように気をつけるためです。

測定は、撮影した各画像の中心の100x100ピクセルの平均の明るさ。RGB個別に取り出してます。中心を選ぶ理由は、縁のほうに行くと周辺減光が影響してくるからです。また、ADCの値に何らかのオフセットが加わっている可能性があるために、レンズに蓋をして明るさを測りましたが、レンズを開けた時に対して0.5%程と測定にほぼ影響はないので今回は無視しました。

これだけやったのですがやはり結果は変わらず、ISOと実際のゲインは全然合いませんでした。結果を示します。ISO100の時のゲインを1としています。
6D_ISO_gain
普通はISO800ならISO100の8倍の明るさになるはずです。グラフの点線に近くなるはずです。ところが実測は4-5倍程度しかないどころか、線形性(測定点を結んだ線が真っ直ぐになること)さえもありません。

測定はかなりしっかりやったつもりです。いったい何がおかしいのでしょうか?一つの可能性は、ヒストグラムのピークが一定の場所になるように露光時間を変えるなど調整しながら、その露光時間ぶんを補正してISOを変えて測定するとかでしょうか?ちょっといろいろ不明で、そろそろ力尽きたのでここは次の課題とします。


今回の結論

はっきりとした結論は出ませんでしたが、まとめます。
  • SharpCapのセンサー解析機能を使うことで、EOS 6DのISO100についてのコンバージョンファクター(Gain)はきちんと測定できたようです。
  • ですが、それ以外のところは1.5倍ほどずれていると考えられます。
  • その原因は、ISOを変えることに対して明るさが期待通りにならないことから来ていると思われます。
  • なので、unity gainに関しては保留とします。
  • 他の場所ではunity gainはISO600を切るくらいと、複数確認できるのと、ISOとゲインの関係さえしっかりしたら今回の測定でもそのくらいになるので、おそらくunity gainはISO600を切るというのが正しいと思われます。
今ふと思ったのですが、もしかしたら持っている6Dのゲイン設定がおかしくなっていて、本当にISOとずれているのかもしれません。こうなったら修理コースなので、もう少しいろいろ試してから結論を出したいと思います。


昨晩とても晴れていたので、SharpCapを使った一眼レフカメラでの電視観望テストの第2段です。


SharpCap3.3β接続確認状況

まずはこれまで私が聞いた可動情報を書いておきます。情報は全てTwitterや本ブログのコメント、個別のやりとりなどです。

(11月21日午後23時55分現在)

Canon

  • EOS 6D (Sam): 動作確認済、LiveStack可能、ミラーアップモードでは動作せず
  • EOS 6D (RAINYさん): 動作確認済、ASCOMドライバーでのLive ViewオプションでCapture Areaがデフォルトでは960X640なることを確認
  • EOS X7i (ぺんぱるさん): 動作確認済、LiveStack可能
  • EOS 6D Mark II (steorraさん): 動作確認済、LiveStack可能
  • EOS R (steorraさん): 動作確認済、LiveStack可能、ミラーレスで初確認
  • EOS Ra (steorraさん): さすがに試すのを躊躇
  • EOS X2 (ソルトさん): 接続してミラーアップはするが、シャッター切れずエラー
  • EOS RP (リュウさん): 動作確認済
  • EOS 7D (kumbenさん): 動作確認済
  • EOS 60D (Sam): 動作確認済、LiveStack可能、ミラーアップモードでは動作せず
  • EOS X5 (Sam): 動作確認済、LiveStack可能、ミラーアップモードでは動作せず
  • EOS M  (薜さん): 動作せず
  • 5D mark II (donchanさん): 動作確認済、LiveStack可能
  • EOS X7 (donchanさん): 動作確認済、LiveStack可能
  • EOS  kiss M  (MASAさん): 動作せず

Nikon
  • D750 (智さん): 動作確認、ミラーアップモードでは動作せず
  • D5000 (あぷらなーとさん): ニコンレガシー使用、FITS書き出し・ライブビュー・ライブスタック・ROIが可能
  • D810 (あぷらなーとさん): 「ニコン」使用、一度本体動作しなくなった、復帰後に動作確認済、FITS書き出し・ライブビュー・ライブスタック・ROIが可能、重い
  • D810a (あぷらなーとさん): さすがに試すのを躊躇
  • D5300 (ソルトさん): 動作せず
  • D50 (智さん): 動作せず
  • D7000 (あぷらなーとさん):  ニコンレガシー使用、FITS書き出し・ライブビュー・ライブスタック・ROIが可能
  • CooLPix B700 (ソルトさん): 動作せず
  • D3300 (あぷらなーとさん):  ニコンレガシー使用、FITS書き出し・ライブビュー・ライブスタック・ROIが可能(SDカード必須)
  • D3100 (あぷらなーとさん):  ニコンレガシー使用、FITS書き出し・ライブビュー・ライブスタック・ROIが可能(SDカード未確認)
  • Z6 (OSAさん): 動作確認済、LiveStack可能、サイレント撮影モード(シャッター動作による振動とシャッター音を出さずに撮影できる)は動かなかった
  • D3 (あぷらなーとさん): ニコンレガシー使用、FITS書き出し・ライブビュー・ライブスタック・ROIが可能
  • D300 (あぷらなーとさん): ニコンレガシー使用、FITS書き出し・ライブビュー・ライブスタック・ROIが可能
  • D90 (あぷらなーとさん): ニコンレガシー使用、FITS書き出し・ライブビュー・ライブスタック・ROIが可能
  • D610 (あぷらなーとさん): 「ニコン」使用、FITS書き出し・ライブビュー・ライブスタック・ROIが可能
  • D810a (あぷらなーとさん): 「ニコン」使用、FITS書き出し・ライブビュー・ライブスタック・ROIが可能、重い

PENTAX
  • K-30 (ソルトさん): 動作確認済
  • K-S2 (ソルトさん): 動作せず
  • K-50 (ソルトさん): 動作確認済
  • KP (薜さん): 動作せず
  • ist D (ソルトさん): 動作確認済
  • K100D (ソルトさん): 動作確認済
  • K-70 (Shinjiさん): 動作確認済、LiveStack可能
  • K-01 (ソルトさん): 動作確認済
  • Pentax K-5IIs (donchanさん) 動作せず
  • Pentax Q-S1 (donchanさん): 動作せず 

SONY
  • α7S or α7SII?(HUQさん): 動作せず
  • yα6000(amayama_54): 動作確認済、LiveStack可能

もし上記リストの訂正や、漏れている方で載せておきたい方がいましたら、Twitterかコメントに書いておいてください。上のリストをアップデートしておきます。また公開したくないという方がいましたら、TwitterのDMかコメントに書いてください。後でコメント自身も消しておきます。


さあ、6D電視観望の2回目のテストだ!

一昨晩は台風のせいか風も強かったのですが、昨晩は晴れて、風が吹いた後のこともあり透明度がそこそこ良かったです。でも21時半頃から月が出るので、長時間撮影も気が引けます。なので、まずは21時半まで少し暗いところに行って天の川撮影。これはまた記事にします。結局22時過ぎに自宅に戻って、眼視、惑星、電視観望と選択肢がありましたが、この日はやっぱりまだホットな一眼レフ電視観望です。

今回の目的はとにかく実践で使ってみること。できる限りいろんなところに向けて、これくらいまで見え、これくらいの使用にまで耐えうるとかいうことを示したいと思います。

前回のテストと少し変更したところがあります。まずはレンズですが、前回はNikonの135mm F2.8でしたが、今回はPENTAX 6x7の中判レンズの165mm F2.8です。理由は、周辺減光が顕著で、しかも色によって反応が多少違うようで、結果四隅に行くに従ってひどくなるカブリのようになってしまい、炙り出しが制限されるからです。フラット補正をリアルタイムでやってもいいのですが、いまだにうまく行ったことがなくて、今回も躊躇してしまいました。

もう一つの変更点は、今回Stick PCを使ったことです。前回はSurface PCなので、そこそこ速いですが少し大きいです。普段撮影用に使うStick PCが使えれば、さらにコンパクトにできます。


準備とトラブル

さて、まずは前回の状態の復帰です。機材はシンプルでポン置きでいいので、楽なもんです。レンズを水平にそこそこ北向きになるようにセットして、AZ-GTiでアラインメントを始めます。広角なので1スターアラインメントでもう十分です。計算によると3.65°x2.45°だそうです。これくらいの精度で最初置くだけでターゲットが視野に入ってくるので、まず取りこぼすことがありません。さすがフルサイズセンサーです。

すぐに網状星雲まで入って、画像が取り込めるようになったので、一つ新しいことを試しました。前回の一番大きな問題が、LiveViewモードの間シャッターをずっと「カシャン、カシャン」と切り続けること。6D本体のモニターをオンにすることでシャッターを開けっぱなしにしてかどうできないかです。

IMG_0574
一枚撮りではリモートでカラーバランスを調整できないです。
必要なら本体の方で色を合わせる必要があります。

まずSharpCapのStillモードで撮影開始してないときに、カメラ本体のモニター開始ボタンを押したらシャッターが開いて、SharpCapも落ちたりしないので、このまま行けるか!と期待しました。さらにSharpCapでLiveViewモードにして撮影開始しても音も鳴らずOKかと一瞬思いました。ところが、一枚撮影が終わったらわざわざシャッターを一度閉じて!?またすぐ開いて次の撮影にいくのです。結局各枚各枚の撮影終了時に必ずシャッターを閉じるという機能が働くらしくて、モニターオフにしている時と同じことでした。

さて、次にLiveViewへの移行です。途中SharpCapが落ちることが何度かありました。しかも一度落ちると、SharpCapを立ち上げ直してもASCMOの設定画面に行ってしまい、その後それを繰り返しカメラとの接続ができなくなってしまいました。SharpCapの立ち上げでも、カメラ本体の再起動でも解決しなくて、しばらくはPCの再起動で解決していたのですが、途中からタスクマネージャーで見てみるとSharpCapのゴミプロセスが残っていて、それを消すと再度SharpCapが問題なく立ち上がることに気づきました。

IMG_0573
こんなエラーが出て、これ以降接続できなくなりました。
でも実は反応がものすごく遅くなってるだけで、
分単位で待つと反応したりする時もあります。
SharpCapのゴミプロセスが残っているために起こる現象です。 

何度かやっているうちに、LiveStackに行こうとすると必ずSharpCapが落ちることに気づきました。前回とSharpCapのバージョンが違うのではとかも疑ったのですが、それも同じ。違うのはPCだけだということに気付いて、Stick PCから前回のSurface PCに戻しました。すると全く問題なくLiveStackに移行します。というより改めてSurfaceに戻ると、いかにStick PCでのSharpCapの反応が遅かったかに気づきました。少なくとも3.2の普通のCMOSカメラを繋いでいる時まではそんなことは気にならなかったので、今の3.3βと6Dは相当重いことになります。CPUが非力なためなのか、もしくはUSBの接続が遅い可能性もあります。でもUSB2.0って流石に転送速度に差が出るとは思えないので、やはりCPUの違いかなと思ってます。


充実の電視観望フルツアー

さて、これ以降は極めて順調。シャッター回数を節約したいので、15秒露光にしました。ISOは6400です。回った順番に示していきます。

状況はというと、月齢21日の半月以上の大きい月が出ていて、富山の中心の街から少し離れた住宅地です。普通なら決して星雲を見るようないい状況ではないです。そのため、QBPを入れてます。

  • 網状星雲です。赤と緑の色の違いもはっきり見えてます。
IMG_0576
LiveStackになると色バランスをリモートで調整することができるようになります。

  • 小さなM27亜鈴状星雲
IMG_0578
左端にかわいいM27が見えてます(笑)。
面倒だったので真ん中に持ってくのをサボりました。
この前にM57を見ましたが、流石に小さすぎました。
これくらいの大きさの天体だとレンズの焦点距離を伸ばす必要があります。


IMG_0584

拡大するともう少し形もわかりますが、恒星のハロが目立ちます。
レンズのせいです。
赤外起因だとしたらもしかしたらCBPにすると消えるかも。

  • M31アンドロメダ銀河、QBPは銀が苦手かもと思ってましたが、意外にいいかも
IMG_0587
構造も少しわかります。


  • らせん星雲
IMG_0590

  • 北アメリカ星雲一帯、ここまではっきり見えると迫力あります
IMG_0594

  • 白鳥座のサドル付近
IMG_0596
左下に小さく三日月星雲も見えます。

  • M33さんかく座銀河
IMG_0598
かろうじて腕らしきものが見えるくらいでしょうか。


  • カリフォルニア星雲
IMG_0599
月が近くにあるので、かなりカブってます。それでもこれくらい見えました。

  • ハート星雲と胎児星雲
IMG_0604
ここまで見えるとは。
でもかなり炙り出してるので周辺減光が目立ちます。

IMG_0611
でもセンサーの解像度はあるので、
多少拡大してしまえば周辺減光も気にならなくなってきます。

  • エンゼルフィシュ星雲?
IMG_0614
ここらへんはもうネタです。
まだ光度が低いのでほとんど見えません。
かろうじて右上を向く頭がわかるか?

  • のぼり掛けのM42オリオン大星雲と馬頭星雲、バーナードループ?
IMG_0618
これもネタです。黒い影は木の葉っぱです。
左端のカブリの中にバーナードループが淡く見えてます。
昇り立てで高度が低いのでこれくらい。
冬に向かって持って見やすくなるはずです。


M45プレアデス星団も導入したのですが、月が真横にあり、流石にダメでした。


まとめ

午前0時20分くらいから2時くらいまでの1時間40分。夏から冬までの星雲と銀河、もうフルコースです。ここまで見えれば大満足です。

一言で言うと、さすが撮影でも十分な実績がある6Dです。電視観望でも遺憾無く実力を発揮しています。センサーのピクセルサイズがASI294MC Proが4.6μm、6Dが6.3μmなので、一辺で1.4倍くらい大きいのです。1ピクセルの面積が大きければより多くの光子を取り込めるので、根本的に有利です。

かつ同じ焦点距離ならより広い面積を見ることができます。逆に同じ面積を見るならより焦点距離の長いレンズを使うことができるので、より暗い恒星を見ることができるはずです。実際に使ってみての感想は、確実にASI294MC Proよりも迫力があるということです。

その一方、シャッター回数の制限から一枚一枚の露光時間を長くせざるを得ないので、動きは少なくリアルタイム性には欠けます。ただ、移動する時は星の軌跡は写るので、それはみている人にとっては動きを感じるところで、全く動きがないというわけではないです。

さて、最後の画像の記録を見たら2時間近くで365回のシャッターを切っていました。15秒で一回なので、連続なら1分で4枚、1時間で240枚計算です。途中LiveViewモードからStillモードにしたりもしてたので、数的にはまあこんなもんでしょう。メカニカルシャッターの寿命が10万回だとすると、300回位観望回避r区と壊れる計算です。実際タイムラプスでは平気でこれくらいのシャッター回数になるので、15秒露光でのシャッター回数ならまあ許容範囲でしょうか。


今後やりたいこと

まだまだ試すべきことがたくさんあります。ソフト自身はアップデートを待つとして、手持ちでEOS X5があるので、これで電視観望できるかどうか。天体改造なしなので、赤は出にくいはずです。

X5の中古の値段が1万円台中くらいでしょうか。キットレンズ付きで2万ちょいです。これで本格的な電視観望が簡単にできるなら、裾野が広がりそうです。

あと、SharpCapからのプレートソルブを試してみたいです。これで導入が簡単になるかも。うまくいったらAZ-GTiなしで、StarSense ExplorerみたいなことがPCを使って実現しないかと思っています。そうするとハードは三脚と雲台とカメラとレンズ(とPC)だけで、ほぼ一般的な一眼レフカメラセットになるので、さらに敷居が下がるかもしれません。







このページのトップヘ