ほしぞloveログ

天体観測始めました。

2017年12月

先日のASI294MCの電視でファイルに保存しておいた画像を少しだけ、お手軽処理してみました。目的は時間をかけて追求してすごい画像を出すのではなく、むしろ正反対のできるだけ時間をかけない簡易撮影、簡易画像処理が使い物になるかどうかを試すことです。

今回3種類を比較しています。 
  1. Live Stackをヒストグラムなどの処理を含めて見たままpng形式に落とした画像: 4sec x 35stacks = 140秒
  2. Live Stackをヒストグラムなどの処理が入らないRAWに近い状態で32bitのfits形式に落とした画像(カラーで保存): 4sec x 33stacks=132秒
  3. Live Stackをしない、CaptureでRAWに近い状態でfits形式に落とした画像(Bayer): 4sec x 35枚=140秒


1. 見たままのpngからの処理

まず、保存されたままの加工なしの画像です。4秒露光で、35回スタックしたところで16bitのpng形式で保存されています。SharpCapで表示されている画像を見たまま保存することになります。ブログアップのために8bitのjpgに落としています。

Stack_35frames_140s_png


相当青に寄っています。ライブビュー重視で、夜のような雰囲気を出そうとしたのだと思いますが、改めて見ると結構ひどいです。これをPhotshopでホワイトバランスを整えて、彩度を強調し、最後に少し好みの色にするためにトーンカーブで青を少しいじっただけです。所要時間は数分でしょうか。超お気軽画像処理です。以下のようになりました。

png_Stack_35frames_140s


よく見るとピクセルが飛んでいるところが何箇所かあるようです。少なくとも7箇所、引っ掻き傷のように色が飛んでいるところが見つかりました。見落としているだけで探せばもっとあると思います。

hotcool


最初何かわからなかったのですが、どうやらホット/クールピクセルがスタックしている間のアラインメントを合わせる際にずれていってしまったのがトレースされているみたいです。

それでもpngからの処理にしてはそこそこ見えるものになってしまっています。口径6cm、露光4秒が35スタックで計140秒と思うと、たいしたものです。


2. スタックされたのfits形式

4秒露光で33回スタックしたところで、32bitのfits形式で保存しました。どんなファイルになっているのか開くまでわからなかったのですが、どうやらヒストグラムなどSharpCap上で画像処理した効果は入ってこないようです。RAWに近いですが、ベイヤー→RGB変換はすでにされているようです。それをブログアップのためにそのままjpgに落とした画像です。

Stack_32bits_33frames_132s_notouch


これをまずはステライメージのレベル補正で、レベルとホワイトバランスを整えて、デジタル現像をして飽和をできるだけ押さえます。あとはPhotoshopに移動して、1の処理と同じで彩度とトーンカーブのみです。これも所要時間は5分程度でしょうか。

結果は以下のようになりました。M42中心部の飽和は元の画像ですでに飽和しているので、デジタル現像などでもトラベジウムなどを復元することはできませんでした。ピクセルが飛んた引っ掻き傷もやはり残っています。

stackfits_Stack_32bits_33frames_132s




3. Captureで撮った複数のfits形式の画像をコンポジット

多分これが一番一般的な撮影の仕方なのでしょう。4秒露光のfits形式のファイルを35枚、ステライメージ8でコンポジットしています。上2つと違うのは、ホット/クールピクセル除去の処理を行っているので、引っ掻き傷のようなものは消えています。ダーク減算、フラット補正などの処理はしていません。かぶり、周辺減光などの処理もしていないので、上2つと条件はホット/クールピクセル以外はほぼ同じです。コンポジット後は2の処理と同じで、レベル、ホワイトをとって、デジタル現像、その後Photoshopに移動して、彩度とトーンカーブです。コンポジットはのんびりやっていたので30分くらいでしょうか、その後は5分くらいしかかけていないのは2と変わりません。結果は以下のようになります。

composite_35_140s


引っ掻き傷が消えているのはいいのですが、一番の問題はなぜか苦労して自分でコンポジットしたものの方がノイズが多いのです。画像処理はマニュアルでやっているので多少の差は出るのですが、その範囲を超えてノイズの量に差が出てしまっています。SharpCapのスタック時になにか余分なノイズキャンセル処理をしているのでしょうか?ShaprCapもステライメージも実際のスタックやコンポジットで内部でどのような処理をしているのか不明なので、結局理由はよくわかりませんでしたが、ここはもう少し検証してもいいかもしれません。


さて、3枚改めて比べて見ると、ノイズに差が出た以外は決定的に大きな差が出ているようには見えません。たとえpng画像からの加工でも、このレベルでは差が出ないようです。もっと露光時間をかけた、暗い天体では差が出るかもしれませんが、電視観望で見るような明るい天体を簡易撮影、簡易画像処理ではこれで十分なようです。

露光時間がわずか2分半程度でここまで出るのも驚きです。ただしこれには少しトリックがあって、F10の暗い鏡筒での電視観望に合わせるために、ASI94MCのゲインを500と相当大きくしています。そのため淡い部分が時間の割によく出る代わりに、明るい部分が飛んでしまいます。特にトラペジウム周りをきちんと出したい時はゲインをきちんと下げて、露光時間を長くするか、別途HDRように短時間画像を撮っておいて合成するなどの工夫が必要になります。簡易という観点では少し手間がかかってきます。

こうやって考えると、ライブスタックでfits画像一枚、もしくはいっその事割り切ってpng画像でもとるだけとっておいて、あとでちょいちょいと画像処理してしまえば、一晩に多数の天体を回ったまとめなんかも簡単に作ることができそうです。その際、SharpCapではダークとフラット補正も撮影中にできてしまうので、最初だけ少し手間をかけてダークフレームとフラットフレームを撮っておくのもいいかもしれません。結論としては、電視で撮った画像でも飽和さえ気をつければ簡易画像処理でそこそこ使えるものかと。

ここまでくると、次は本格的に低いゲインでダイナミックレンジを稼いで(具体的に言うとASI294MCだとゲインが120を超えたあたり) 、もっと長時間露光して撮影してみたくなってきます。今回ゲインが500で例えばゲイン140で撮影するとすると、ゲイン差が360なので、360 = 36dB = 64倍の明るさの差になります。4秒露光だったものは4 x 64 = 256秒なので、4分ちょっと。この長さだとガイドが必要になってきます。













昨晩は楽しかったです。夕方から外に出ていたのですが、19時ころからどんどん雲が多くなってきたので諦めていたのですが、22時過ぎにまた外に出てみると、なんと雲がほとんどなくなり晴れ渡っています。やっと新カメラでテストが思う存分できそうです。星はそれほど多くは見えないので透明度は大したことないですが、赤道儀をセットして準備を始めました。

場所とセットアップは先日と同様、自宅の庭で新CMOSカメラASI294MCをつけたFS-60QをAdvanced VXに載せています。口径は60mm、焦点距離は600mmのF10になります。 

まず試したのは先日の最後に雲がかかってしまったM42、オリオン大星雲です。4秒露光で、16回スタックです。淡いモクモクまで見え始めていて、もう前回よりも圧倒的にすごいです。これでわずか総露光1分ちょいです。ASI294MCのポテンシャルがわかる一枚です。ちなみに先日ASI224MCで撮ったものがこちら。恒星の飛び具合(224のはピンボケとうわけではないです)もかなり改善されているのがわかります。

IMG_3334

このオリオンもそうですが、今回見て回った天体のうちいくつかは、各露光のフレームをfits形式で残してあります。また、ライブスタックをした結果も画面で表示されたままのものをPNG形式で、またトーンカーブとかの効果が入っていない、スタックしだけのそのものをRAW形式で保存してあるので、後日画像処理をしてそれぞれの結果を比較したいと思います。

これ以降、電視て見ていった時間順に示します。

次に、バラ星雲です。以前のASI224MCの結果と比べると飽和は抑えられていて、色も自然ですが、かなり暗くなっています。これはSharpCapの新機能のトーンカーブ調整であわせているためで、画面のコントラストなどの調整がなくなっているからです。明るさを出したい時もあるので、トーンカーブのみでなく画面調整の項目も残しておいて欲しかったです。

IMG_3337


続いて馬頭星雲と燃える木です。これも以前と比べると明るさが足りないです。明るさが足りない理由の一つがやはりノイジーということもありますが、今回はスタックを重ねることができなかったことも原因の一つです。冬場で寒いので、StickPCに繋げてリモートで家の中から接続してます。接続自身は多少の画質劣化はあってもそれほど問題はないのですが、それよりもStickPCのUSBの転送速度のせいでしょうか、フレームレートが高すぎて取り込みを落としている可能性があるとの警告がしょっちゅう出ています。実際、結構な率で取りこぼしや、アラインメント失敗が起きています。これは実際に外でまともなPCに接続して直接見ていた時には気づかなかったことなので、やはり電視にはSrtickPCは少し非力なのかもしれません。

IMG_3338


オリオン座星雲内で、M78です。実は自分で見るのは初めてです。別れている様子はなんとかわかりますが、細かい構造はさすがに厳しいです。

IMG_3339


M45、すばるは結構進展がありました。自宅で星間分子雲がこれだけ見えたのは初めてです。

IMG_3343


クラゲ星雲です。さすがに淡い天体は厳しいです。

IMG_3344


ペルセウス座の二重星団です。星団は比較的電視に向いているかもしれません。もう少し露光時間を伸ばすなど、まだ工夫の余地がありそうです。

IMG_3348


続いてモンキー星雲。これもバラ星雲やクラゲ星雲と同じくやはり暗くて色が薄いです。結構露光時間を取ってもこれなのでリアルタイム性という観点からいくと厳しいかもしれません。口径の大きい鏡筒を試してみたいです。

IMG_3349


M1、カニ星雲のリベンジですが、前回とあまり変わりありません。今回も結構拡大しています。やはりこの口径の鏡筒ではこれくらいが限界か。

IMG_3350

午前3時過ぎ、夜も更けてきた最後の方はもう春の星座になってきます。系外銀河です。「マルカリアンの鎖」と呼ばれるM84、M86、M87周りです。NGC4402, 4388, 4413, 4425, 4435, 4438, 4461なども見えています。このころになるとまた透明度が悪くなってきて、星が見えにくくなっていました。それでもこれくらいは見えるので結構驚きました。

IMG_3351


富山は海に面している北のほうが街なので、北の空は明るくてこれまでほとんど見たことがなかったのですが、夜中で街灯りも多少はマシかと思い、少し見てみました。下はM106、りょうけん座の渦巻銀河です。腕の様子も多少見えています。他にもNGC4217やNGC4220も写っています。色がつかないので電視のメリットは半減しますが、それでも光害の中、系外銀河も意外に見えるようです。

IMG_3354


午前3時半過ぎ、風が強くなってきました。フクロウ星雲を狙って見ましたが、光害と風でかろうじて穴二つが見えているくらいでしょうか。風で赤道儀が揺れているというよりは、繋がっているケーブルの揺れのようです。

IMG_3358

最後の最後で真北のM81を見てみましたが、さすがにこの方向は厳しいみたいです。空も透明度が相当悪くなっていて、外に出るとほとんど星も見えない状況でした。

IMG_3359


少し時間を戻して、同じ日の夕方過ぎにオリオンが登り始める18時半ころにSIGMA 10-20mm F3.5 EX DC HSMを10mmにしてASI294MCに取り付けて見てみました。焦点距離が短いので星の数は大したことないですが、かなり広い範囲を見渡せます。ヒアデス星団、すばるがはっきり見えています。雲があるのと、透明度もよくなかったので目ではすばるがやっとぼやーっと見える程度でしたが、PCの画像を通すとはるかに星の数が多くなります。WideBino28で見た時と同等か、それ以上でしょうか。複数の星座が一度に見えるので、星座をみんなでトレースしながら確認するのとかに使えるかもしれません。

IMG_3327



今回のまとめ

やはり全般に暗いというのが挙げられると思います。特に淡い天体は厳しいです。この面積のセンサーを有効活用するためには、できるだけ焦点距離をキープしたまま鏡筒の口径を大きくする必要がありそうです。

あと、まじめに撮影をしようとすると厳しいかもしれませんが、富山でも意外に北の空も電視だと楽しめることがわかったので、今度もう少し探索してみたいと思います。

とにかく昨晩は久しぶりに晴れた空を満喫してかなり満足でした。後日、fitsで保存した画像を加工したものも比較してみます。そこそこ見える画像になるのか、それとも全くダメなのか。もし撮影の道がひらけそうなら、次はノイズを最適化して、ガイドで長時間露光でしょうか。

 

週末の金曜日、夕方ものすごく晴れていたので張り切っていたら、食事を終えた午後7時頃にはまた雲が。それでも昇りかけのオリオン座は見えていたので、短時間ですがASI294MCに再びNIKKORの50mm f1.4をつけてバーナードループに挑戦しました。

結果はかなり厳しかったです。 6.4秒露光を50回ほどスタックしていますが、数十回くらいからはほとんど改善しません。よく見ると三つ星の下を回り込むように、本当にうっすらループが見えている程度でしょうか。馬頭星雲と燃える木は小さいですがきちんと色がついて見えています。

IMG_3320

レンズは十分に明るいので、やはり厳しいのは自宅庭の光害のせいかと思います。電視だと流石に淡いものはなかなか手強いです。次の手は光害防止フィルターを入れるとかでしょうか?あと、SharpCap自身にフラット補正の機能があるので、それも試す価値があるかもしれません。

あまりに寒いのでしばらく家に入り、温まってから外に出たら雲一面と、ものすごい風でした。ショックだったのはPCが風で吹っ飛んでいたこと。少し傷がつきましたが、一応問題なく動いて今もこのブログを書いています。机から落ちていたのによく壊れなかったです。短時間でも放っておくのはちょっと心配です。反省しました。

 

前回のASI294MCのファーストライトはほんの晴れ間でしたが、12月21日、昼間くらいから本当に久しぶりに晴れ渡ったので、やっと念願のASI294MCのフルテストができそうでした。前回赤道儀を使ったのは記録によると11月27日。さすがに北陸といっても天気悪すぎです。

場所は自宅の庭。セットアップとしては口径60mm、焦点距離600mmのFS-60QをAdvanced VXに載せたいつものものです。たくさんやりたいことはありましたが、残念ながら途中から雲が出てきてしまい、結局試せたのは焦点距離600mmでの電視で、数も限られた天体だけでした。

これまで電視はセンサーサイズが1/3インチとかなり小さいASI224MCであったため、焦点距離の355mmと短いFS-60CBにさらに0.5倍のレデューサーをつけて、焦点距離が180mm程度になっていました。今回はASI294MCでセンサーサイズが4/3インチと、これまでに比べて各辺で4倍、面積で16倍と大きくなったため、焦点距離が600mmと4倍くらい長いFS-60Q状態で使えるようになりました。その代わり、4倍くらい暗くなっているので、そこらへんがどうなっているかが見ものです。

最初はM31、アンドロメダ銀河です。いつものようにPCの画面をiPhoneで写しているだけで、実際の見え味にかなり近いものです。これで6.4秒露光を16回スタックしたものです。スタック回数は適当な時に写真を撮っただけで、こんなにスタックしなくても数回でそこそこ見えるくらいになってきます。

IMG_3313
新しいASI294MCでの電視によるアンドロメダ銀河。


先月11月に志摩に遠征に行った時にASI224MCで撮ったものが下になります。空は志摩の方が圧倒的にいいです。今回のは自宅で、しかも決して環境がいい方ではないですが、それでも今回の方が全然良くなっていることがわかります。ソフトの進歩もあるでしょうが、やはりカメラの差だと思います。

IMG_3135
これまでのASI224MCでの電視によるアンドロメダ銀河。

相違点を上げていきます。

  • ノイズが以前よりかなり少なくなっています。確かに実際にノイズ自身少なくなっているようなのですが、解像度がかなり高くなっているので、そのことによりノイズが目立たなくて少なくなっているような印象も受けます。
  • 飽和しているエリアが小さくなっています。これはダイナミックレンジが増えた効果、もしくはfull wellが大きくなった効果といっていいと思います。
  • 0.5倍のレデューサーのせいでしょうか、星像がかなり歪んでいたのが、今回は綺麗な点像になっています。
  • 色もより自然になっています。これはヒストグラムを見ながら調整できるせいでしょう。
  • やはり今回焦点距離が長く以前より暗いので、ゲインを最大の570にしてしまっています。最大ゲインでこれくらいのノイズで抑えられているのもすごいのですが、それでも6.4秒くらいの露光時間がないと写りが悪くなります。また、これ以上露光時間を長くするとリアルタイム性がなくなってきます。もう少し明るい鏡筒にしたいです。
これまでずっと電視を試して来て色々不満な点もありましたが、それでもやっと満足できるレベルになって来ました。M31が自宅で、しかもその場でリアルタイムでこれだけ見えるのなら、電視観望としてはもう実用と言っていいレベルなのかと思います。



次はM45、プレアデス星団です。

IMG_3315
ASI294MCで見たプレアデス星団。

さすがに自宅だと分子間雲が少し見えるくらいです。だんだん霞みがかってきたので、もう少し空がいい日ならば自宅でもまだましになるかと思います。

下が、去年の10月に同じ自宅でASI224MCで見た時です。飛びまくっていますし、かなり無理して色を出していました。今回の上の方が無理をせずに自然な色になっているのがわかります。分子間雲も自然な感じで見えています。

IMG_0398
昨年10月に同じ自宅でASI224MCで見たプレアデス星団。


M1、カニ星雲はさすがにフィラメントまでは見えませんでした。所詮600mmでかなり小さくしか見えないので、相当拡大しています。そのためノイジーに見えてしまいます。実はM1を見たのは一人メシエマラソンの時だけで、その時も月明かりでほとんど全く見えなかったので、実質初めてかもしれません。これは長焦点でリベンジしてみたいです。

IMG_3317


最後はM42、オリオン大星雲です。

IMG_3318

もう雲がかかってきてしまっています。ギリギリで最後に撮ったものです。晴れていればこれはさすがにもっともっと綺麗に見えるはずです。これ以降は完全に雲がかかってしまい、今日はここまでになってしまいました。

実は雲の中、ASI294MCに手持ちのシグマの10-22mmのf3.5のレンズをつけて、かなりの広角でも見てみました。写真には残さなかったですが、目で星がほとんど何も見えない状態でも、雲の薄いところだと星を炙り出してくれます。さすがにこれくらいの広角だと複数の星座が一度に余裕で見える画角なので、都会の観望会で星座をトレースするのに使えるかもしれません。これはセンサーサイズも解像度も足りないASI224MCでも、明るさがどうしても足りないASI178MCにもできなかった芸当です。ASI294MCの利点の一つになるかと思います。またもう少し晴れた日にきちんと試してみます。

とりあえず、少しですがASI294の実力がわかってきました。はっきり言って電視目的にはかなり満足できるレベルになりそうです。ただし、センサーサイズの拡大に伴って焦点距離が長い鏡筒になってくると、そもそも暗くなってくるので、もう少し口径の大きい鏡筒を使った方がより露光時間を短くできるので、より臨場感が出そうです。最初に買った口径20cm、F4のニュートン反射のBKP200がいよいよ再稼働かもしれません。口径比では(20cm/6cm)^2 ~ 11.1倍の明るさ、焦点距離で(600mm/800mm)^2 ~ 0.56の明るさになるので、11.1 x 0.56 = 6.2となり、ざっくり6分の1の時間で同じように見えるはずです。今回更新6.4秒だったので、1秒になれば相当リアルタイム性が出るかと思います。それに伴い、視野が少し狭くなるのですが、ギリギリ許容範囲かもしれません。もったいないですが、これに安価な0.5倍のレデューサを入れるか。これだとより広角に見えて、明るさは4倍です。カメラの解像度はPCの画面の解像度に比べてあり余るほどあるので、適当にズームすればよく、こちらの方が有利かもしれません。

もう一つ、今思い出したことがありました。解像度が高いので有効活用するために途中ビニングをしたのですが、この効果がいまいち見えません。例えば2x2でビニングすると解像度は半分になるので画面の大きさはSharpCap上で4分の1の面積になります。これは確かめることができました。ただし、そのぶん明るくなって欲しいのですが、画面で見てもヒストグラムで見ても変化があるようには見えません。もしかしたらバグなのかもしれません。そして、分解能が下がるのに伴ってノイズの解像度も下がるので、点々が目立つようになってしまい、実質余計ノイジーになったように見えてしまいます。3x3、4x4のビニングでも同様です。もう少しバージョンが安定するまで見続ける必要がありそうです。



まだまだ試したいことだらけです。冬なのでペースが天気にものすごく左右されますが、できる範囲で色々やっていこうと思います。



IMG_3308
今日のセットアップ。この時はまだ極軸合わせのため、
ASI294MCが鏡筒の上に載っています。

もう、ムハッという感じです。ASI294MCすごすぎです。電視の画面の中で神々しいくらいの星がちりばめられています。

IMG_3297
オリオン座の三つ星付近です。画面は何の加工もしていません。
露光時間800ms、ゲイン450で、スタックも何もしていません。
iPhoneでPCの画面をそのままとっただけです。


今日もずっと雪で天気が悪かったのですが、夜に外に出て見ると雲が少し切れているところがあったので、駄目もとと思いながらASI294MCを出しました。

カメラ側はZWO製のCanonアダプターを付けて、レンズはNIKKOR-S 50mm F1.4のオールドレンズにCanonアダプターを付けてです。二つをくっつけて、簡単に三脚の自由雲台に乗せてのマニュアル導入です。中くらいの星座がちょうど入るくらいの画角なので、かなり広角で、手で合わせるので十分です。

IMG_0873


雲の切れ間といっても、けっこう霞んでいるので、目ではほとんど星なんて見えないです。たまに明るいプロキオンが見えるくらいで、リゲルもベテルギウスもほとんど見えません。とにかく動画を見てください。



ものすごい高感度のためにまるで昼間みたいに見えますが、れっきとした夜の映像です。場所は自宅の庭。露光時間は400ms、ゲインは500。ASI294MCの最大ゲインは570なのですが、それに近いゲイン500でもノイズがこれまで使ってきたカメラよりも圧倒的に少ないです。アップロードのために解像度を1024x698に落としていますが、もとは4144x2822の超高解像度映像です。

何本か撮影したうちの一つですが、間も無く雲が多くなってきて撤収しました。とにかくASI294MCですが、凄いポテンシャルかと思います。早く晴れたににじっくり見たいです。


その5: 2017/12/21にFS-60Qで電子を試しました。
 

Natusです。今年(中1)の夏休みの自由研究を紹介します。

夏休み明けに学校に提出した後、学校で展示していました。1ヶ月ほどで返って来たのですが、そのまま放りっぱなしになっていました。せっかくなのでブログにまとめておきます。


IMG_3281


テーマは「手動赤道儀の恒星自動追尾化」です。
去年の自由研究の「星でめぐる銀河鉄道の夜」に続き、今年も天文関係のテーマにしました。
夏休み前にハンドルを手で回して星を追う手動赤道儀型の天体望遠鏡を手に入れたので、手でハンドルを回さなくて済むように、自分で赤道儀を自動追尾化させてみようという内容です。




IMG_3278

使用した望遠鏡:ポラリス80L

<望遠鏡の説明>
    夏休み前に名古屋のスコーピオで手に入れました。

望遠鏡セット:Vixenのポラリス80L
       40年ほど前の製品で、1980年にはすでに発売されていたことが確認できた
      
   赤道儀:手動
       赤緯を0度にすることで経緯台にもなるタイプ
       目盛り環付き
       赤経、赤緯軸ともに微動ハンドル付き

<視野角の測定>
 昼間に下の写真のように望遠鏡から10m離れたところにあるメジャーを見てどのくらい見えるのかを調べ、その結果から望遠鏡の視野角を計算しました。 
IMG_3285

望遠鏡の視野角の測定

<赤道儀を動かす>
目標は「10分経っても視野の中心に入れた星が真ん中と端の中間を超えない」ようにすることです。そのためにはできるだけ正確に10分間で微動ハンドルを1回転させる必要があります。    
 
IMG_3286

                                               
1番のポイントは微動ハンドルをどうやって回すかということですが、最初、重りを使って回してはどうかと考えました。モーターの代わりに何らかの重りを使って回転軸をまわすというものです。

ところが、重りでは動摩擦係数と静止摩擦係数の差が大きすぎるため、なかなか星を追う時の回転速度を安定させて出すような仕組みは作れそうにないことが分かりました。



次にモーターで赤道儀を動かすことにしました。

IMG_3273

モーターを取り付けた写真

 
モーターのギアと微動ハンドルを外したところにつけたギアを噛み合わせて動かします。
モーターの回転速度は計測するとぴったりでそのまま使うことができました。



IMG_3283

極軸が1°ずれたときの星の動きと赤道儀の動きの誤差の計算

<実測>
実際に星を自動追尾させてみました。
モーターで星を自動追尾させ、目標の視野の真ん中と端の中間を超えるまでの時間を計測します。
前の日も計測をしたのですが、極軸を正確に合わせていなかったため、8分ほどで星が中間を超えてしまいました。
今回は極軸をできるかぎり正確に合わせました。(2分のずれ)

IMG_3277



結果、1時間経っても星は視野の中心からまったくずれませんでした。極軸合わせで結果がここまで変わるのかと驚きました。



<結論・感想>
元々の目標の10分間の追尾を大幅に越して、1時間をこえても目では確認できないくらいの星像の流れに収めることができたので、大成功です。
今までただ見ていただけの星を自分で追いかけることができると分かったことに、何より感動しました。
来年はもっとレベルアップしたものに挑戦したいです。



夜に晴れるのを待ちこがれながら、雪の日曜日の昼間にSharpCapでテストをしています。β版がまた期限切れになってしまったのでアップデートしたら、ヒストグラムがすごいことになっていました。


ヒストグラムと情報

小さなヒストグラムがLive stackモードにしなくても使えるようになったのは以前報告しましたが、右の狭いエリアの中にしか表示できなかったので、見にくかったのと操作がちょっとしにくかったです。今回のアップデートでは、以前Live stackモードでしか出てこなかった大きな画面でのヒストグラムが、スタックとは独立にいつでも見えるようになりました。上の方のズームのすぐ右にある緑色のアイコンを押すと出てきます。もしくは「Tools」メニューからから選ぶこともできます。

まず便利なことは、カーソルを置くと、その位置での情報が見えます。

IMG_3254


意味は上から順に
  • Value: 横軸に相当。一番右端で2048(11bit?なぜ?)で100%になります。
  • Count: 縦軸に相当。カーソルを置いた位置でのピクセル数。
  • True ADU: 横軸に相当。ADCで数えたカウント数。一番右端で今回の場合14bitなので16384。単位は [ADU]。
  • Electrons: 上の数にコンバージョンファクターfcをかけたもの。単位は [e-]。
  • Electron Rate: 謎です。単位は[e-/s/um^2]
となるみたいです。また、RGBそれぞれの平均値(Mean)と標準偏差(SD, standard deviation)もわかるのもすごいです。

これらのヒストグラムの値は、デフォルトでは全画面ですが、上の方の赤い枠が表示されている小さなアイコンを押すと、エリアが選択できるようになり、場所と面積を任意に選べるようになります。その場合はヒストグラムはそのエリア内の情報を示すようになります。


読み出しノイズの影響

これだけでもすごいのですが、このヒストグラムの真骨頂は使っているセンサーの性能から、今見ている画面が読み出しノイズに支配されているか、ADCの分解能の影響があるかないかなどが、大まかにですがものすごく簡単にわかることです。ただし、まずはセンサーの性能を測定しないと、この機能が出てこないので注意です。8bit rawモードもしくは16bit rawモードで測定する必要がありますが、測定したモードの分しかこの機能は出てきないので、これも注意です。

さて実際の機能ですが、ヒストグラムの上の方に2本の色付きのバーが見えます。上のバーが読み出しノイズがどれだけ影響するかを示すもの。星雲の淡い成分もヒストグラムのピークより少し右側くらいにいますから、目安としてはヒストグラムのピーク位置で考えればいいと思います。このピークがどの色のところに来ているかで、読み出しノイズが支配的かどうかがわかります。赤のエリアにピークが来ている場合は、読み出しノイズが支配的なので、露出時間を長くすると読み出しノイズの影響を抑えることができるということを示しています。

IMG_3248
ピーク位置が上のバーの赤色のところにあると、読み出しノイズに支配されています。
露出時間を上げることで画質が改善されます。


オレンジはまだましですが、それでも読み出しノイズに影響されています。これもさらに露光時間を長くとった方がいいということです。

IMG_3247
ピークがオレンジのところだと、読み出しノイズが画質に明らかに影響があるという意味です。
これも露出時間を伸ばすと画質が改善されます。


グリーンのところに来ていれば問題ありません。このエリアになるまで露光時間を増やすといいということがわかります。

IMG_3250
この緑のところにヒストグラムのピークが来ると、読み出しノイズは画質には影響ありません。

上のバーの色の割合は、ゲインを変えると変化します。それぞれのゲインにあったピーク位置が存在するということです。一方、露光時間を変えただけではバーの色の割合は変化しません。このことはちょうど昨日記事にした、「読み出しノイズは露出時間を長くすると無視することができるようになる」と言っていたことと一致します。でも、昨日の時点でこの機能のことは知らなかったので、今朝のアップデートはものすごくタイムリーな機能を知ることとなりました。


ADCのbit分解能は十分?

一方、下のバーは8bitでいいのか、16bitの方が有利なのかを教えてくれます。 左の緑のエリアにピーク位置があると、8bitでは足りていなくて、このASI224MCが持っている14bit、もしくはもし得られるならばそれ以上のbit数の方が有利ということを示しています。

IMG_3252
ここの位置にピークが来ていると、SharpCapの設定で8bitにした場合と、
16bitにした場合に明らかに差があって、16bitに設定した方が有利だと示しています。


一方、ピークが黄緑の位置にある時は8bitでも14bitでもどちらでも画質に差はないということを示しています。

IMG_3253
黄緑のところにヒストグラムのピーク位置がくれば、
8bitモードでも16bitモードでも差がないということを示しています。



このことは、長年の疑問の一つ、ピーク位置をどこに持ってくればいいのかという疑問に対して一つの指針を示してくれています。ゲインを上げて、ピーク位置を黄緑のところまで持ってくれば8bitでもいいということです。ただし、これには注意が必要で、ピークを右側に持ってくれば当然明るい部分が飽和するまでに余裕がなくなってしまいます。なので当然14bitで撮影する(SharpCapの設定では16bit RAW)として、ピーク位置を緑と黄緑の境界くらいに持って来ると、暗い方の階調に関しては手持ちのbit数を最大限引き出しているということになるのかと思います。ただし、これも明るい部分の飽和には注意する必要があります。


背景光の測定モードも

他にもまだスカイノイズの測定もできるようです。バーの左上の脳みそマークを押すと、測定画面が出て来ます。こちらは暗い空を必要とするようなので、またいずれ試そうと思います。 

IMG_3255



最近のSharpCapのアップデート、特にTool類の追加はセンサー性能実測機能にとどまらず、凄まじいものがあります。特に最近個人的にはちょうどカメラのノイズのことを考え出したので、(もちろんただの偶然ですが)まるで自分のノイズの理解度に呼応してアップデートしてくれているような気分になってしまっています。 
 

KYOEIさんの在庫ありでせっかく手に入れることができたASI294MCですが、すでに一週間何もできずに過ごしてしまっています。昨日の朝起きたら、久しぶりに青空が広がっていて期待したのですが、夕方にはすでに曇り。今日はまたこれから雪みたいです。天気だけはどうしようもないので、相変わらず脳内ミュレーションです。今日はノイズについてもう少し考えてみます。


FullSizeRender

今日も家の外は雪景色。北陸の冬は天体観測には厳しいです。

カメラによる天体撮影をする時、誰もが綺麗な仕上がりになることを目指して撮影に臨むわけですが、最初は何をしたらいいのか、完全に手探りで全くよくわからないものです。それでも調べていくうちに、先人たちの貴重な経験から色々な手法があることがわかり、それに従ってマスターしていけばかなりのレベルで撮影ができるようになってきます。ところが、ある事柄について全く方向性が逆の手法が示されていたり、おまじないのようになぜそれをしなければならないかなど、手法の根拠がよくわからないということがよくあります。何が正しくて何が間違っているかよくわからなくなるのです。その助けになればいいと思って、ノイズのことをいろいろ調べたり考えてみましたので、メモがわりに書いておきます。


0. 天体撮影におけるノイズの一般式

まず一般的に天体撮影をする時にどういったノイズが出てくるかですが、定性的な話は調べるとたくさん出てくるのですが、きちんと式で説明してくれているようなところはなかなか見つかりませんでした。それでも天文系のCCDカメラやCMOSカメラを研究、開発しているようなところは、やはりノイズについても相当定量的に調べていて、我々アマチュア天文家の撮影にも使えそうな定式化をしてくれているので、そこらへんの話を考えてみます。

CCDカメラやCMOSセンサーを使ったカメラでの天体撮影において、信号とノイズの比S/Nは

S/N = (n t Ssig/ sqrt( A n σ^2 + A n t SskyA n t Sdark + n t Ssig) ∝ sqrt(n)

と書くことができます。ここで
  • A [pix] : 開口面積
  • n : フレーム枚数
  • σ [e-/pix] : 読み出しノイズ
  • t [s] : 1フレームの積分時間
  • Ssky  [e-/s/pix] : スカイバックグランウンド
  • Sdark  [e-/s/pix] : 暗電流
  • Ssig  [e-/s] : 天体からの信号
です。この式から様々なことがわかります。

まず、この式は全てのノイズ(分母の方)は枚数nを増やせば増やすほど、原理的には枚数のルートに比例して増えていくことを示しています。ノイズは減るのではありません、増えていくのです。その代わりに、ターゲットの信号に当たるS(分子の方)も枚数の1次で比例して増えていくので、結果としてS/Nは

/ sqrt(t) = sqrt(t)

で向上して行きます。もっと簡単に言い換えると、コンポジットした枚数のルートに比例して綺麗になっていくということです。

次に、分母のノイズの中身をもう少し詳しく見ていきましょう。


1. 読み出しノイズ

まず、読み出しノイズは積分時間によらず一定です。このことは、読み出しノイズは一枚のフレームをとるたびに必ず一定量入りますが、長く撮っても増えもしなければ減りもしないということを意味します。もちろん信号Sは時間の1次に比例して増えていくので、S/Nは結果として時間の1次で良くなっていきます。これはその他の時間のルートに比例して増えていくノイズと比べて、長時間かけて撮影するならば無視できうるノイズということになります。でも誤解しないで、式を今一度よく見てください。読み出しノイズは枚数を増やしても他のノイズと効きが同じでなだけで、無視できるようにはなりません。一枚あたりの時間を伸ばすことで初めて無視できるノイズということです。ここら辺は目からウロコの方も多いのではないでしょうか。私も最近まで意識できていませんでした。

読み出しノイズ以外のその他のノイズの振る舞いは、時間と枚数に関しては良く似ています。読み出しノイズを無視した形でS/Nを再び式を書くと


S/N ~ (n t Ssig) / sqrt( A n t Ssky + A n t Sdark + n t Ssig)
          = Ssig / sqrt( Ssky + Sdark + Ssig) x sqrt(n t∝ sqrt(n t)

となります。今度は時間のルートで全てのノイズが増大(減少ではありませんよ)していって、信号Sは時間の1次で比例して大きくなっていくので、結果としてS/Nが時間のルートで向上していくというわけです。nについても同じような関係になるため効果は同じですね。もう少し噛み砕いていうと、一枚の撮影時間をふやすか、もしくは撮影枚数を増やす、すなわちトータルの撮影時間を増やしていけばいくほど、そのルートで綺麗になっていくということです。


2. ダークノイズ

さて、分母に残った3種類のノイズの中で一番馴染みがあるのはダークノイズでしょうか。これはダークフレームを撮影した時にホットピクセルやクールピクセル、アンプの熱雑音ノイズなどに起因して明るくなったりするパターンノイズなどという形で実際に見ることができると思います。ここで注意ですが、そのダークフレームの中に写っている真っ暗に見える部分にも、ある程度の写り方のバラツキが存在するということです。ばらつきに関しては、すぐ下のノイズの説明のところで詳しく説明します。ダークフレームも時間をかけて撮影すると、時間のルートに比例してノイズが大きくなってきます。


3. スカイバックグランドノイズ

スカイバックグラウンドノイズは光害などに起因する背景の明るさのノイズですが、普段の撮影では、最もよく目にしているはずのノイズで、最も問題になるはずなのに、あまり定量的に議論されているのを見たことがありません。実はこれは撮影した画像からきちんと測定できるものなのですが、私もまだ実際に評価したことはないので、機会のある時に真面目に測ってみたいと思っています。撮影したときのある内部ゲインの時の、ADU(ADCのカウント数)からe-(センサーで数えられた電子の数)へのコンバージョンファクターfcが分かっていれば、画像の中での星が写っていない背景部分のADCのカウント数を数えることによって、きちんと定量的に見積もることができ、かつ電子の数として他のノイズと直接大小を比較できるわけです。ただ、ひとつ誤解を招かないようにしておきたいのは、今議論している画像というのは、すでにフラット補正もされて、背景光のオフセット分(DC成分)を差っ引いて、ノイズとなる揺らぎのみを考えているという意味です。なので、背景部分のADCのカウントをそのまま数えるのではなく、ある範囲のピクセルを多数数えて、そのバラつきを測定しなくてはいけません。また、ノイズがバラつきであるということを意識できていない場合が結構あるようなので、少しだけ説明しておきます。


ノイズとは

そもそも天体撮影におけるノイズとは一体どういうことなのでしょうか?ノイズを考えるには統計のことを少し知らなくてはなりません。例えば一台のカメラを使って全く同じ場所、同じ明るさ、同じ温度で多数枚の撮影をすることを考えます。赤道儀に望遠鏡を乗せて、カメラで設営するという状況で構いません。ゲインや露光時間も同じとします。適当な露光撮影、例えば1秒で、1000枚の画像を撮ったとしましょう。全く同じ状況なので、1000枚とも同じような画像が撮れると思いますが、ある一つのピクセルに注目した場合、1000枚とも全く同じ明るさ、言い換えると全く同じADCのカウントで全て記録されているでしょうか?通常はそんなことはありえません。よく似た明るさにはなるので、1000枚の平均値はある値を持ち、その値がそのピクセルでの明るさと言ってもいいともいます。ノイズというのはその平均値からどれくらいずれているか、そのずれがどれくらいの範囲に散らばっているかということを表す量です。細かい統計の話は教科書のようなものに譲るとして、ここで理解しておきたいことは、一般にノイズというのはバラツキ具合を「標準偏差σ」で表しているということです。標準偏差σという言葉に拒否反応を起こす人もいるかもしれませんが、最低限理解したいことはただ一点のみ。ある測定をしたときに、このバラツキの68%が標準偏差σで表される範囲内に入っているということです。

例えば先日測定したASI294MCの読み出しノイズは1.3[e-]ですが、これは平均値はよくわかりませんが、そのバラツキの68%は1.3[e-]という値の中に入っていますよという意味です。平均値はよくわからないので例えば10[e-]としましょう。ノイズはバラツキなので測定値がたまたま平均値と同じ10[e-]の時もあれば、10.1[e-]の時もあります。11.2の時もあれば11.5のときもあります。たまには12.6という結構外れた値をとることもあるでしょうし、13.9とかいうかなり外れた値をとる可能性も0ではありません。標準偏差のすごいところはここで、この場合10 - 1.3 = 8.7 [e-]から10 + 1.3 = 11.3 [e-]までの間に測定値が来る確率が68%と分かってしまうことです。もっと言うとσ=1.2 [e-]の倍の2.4[e-]、この場合2σ (にしぐま)と言いますが、この範囲に入っている確率は95%ということです。もし12.6[e-]なんていう値が測定されたら、これはありえない方5%に入っているので珍しいというわけです。ちなみに3σ = 3.9 [e-]なんていうと99.87%とほとんどの値が入ってしまうので、今回の場合13.9 [e-]以上なんていうとんでもない値をとるのは1000枚のうち1.3枚ほどしかないのですが、可能性としては0枚では決してないのです。

上は1000枚のフレームのある同じ1ピクセルについてのみ考えましたが、背景光なんかを測定する場合にはある一枚の100x100ピクセル分の平均値とバラツキの標準偏差を測定してやってコンバージョンファクターを使い電子の数に換算してやることで、読み出しノイズなどのその他のノイズとの大小が議論できるようになるというわけです。


4. ショットノイズ

さて式に戻って、分母の最後の残りsqrt(Ssig)についてです。これは入っている信号のルートに比例して出て来るノイズです。いろいろWebを調べていると、ダークノイズとショットノイズを混同しているケースた多々見受けられます。ショットノイズはセンサーに光を入れた時に、その光の量のルートに比例して出てくるので、真っ暗な時に出て来る限界のようなダークノイズとは別で扱う必要があります。ノイズなので、当然そのバラツキ具合で議論します。具体的な例でいうと、淡い星雲のようなところでは、当然星雲からの明るさがセンサーに入っているので、ダークノイズや、背景光のノイズもありますが、それに加えて星雲そのものの明るさのバラツキ具合もノイズとして考えなくてはいけません。また、天体がない背景の部分では逆に信号としてのSsigが小さいので信号Ssigからのバラツキも小さいため、Ssig起因のショットノイズは無視できるでしょう。


考察

以上のことから、ノイズを考えていくと、定量的にいろいろなことが評価できる可能性が見えてきます。実際には
  1. ある性能を評価したいカメラを使い、あるゲインを設定します。
  2. 既知の明るさが分かっている星を利用して、Ssigを測定してカメラのキャリプレーションのようなことを行い
  3. Sskyを測定することで
  4. そのカメラ、そのゲインでの限界等級を求める。限界等級は測定時間の関数になる。
  5. ゲインを変えて、各ゲインでの限界等級を繰り返し求めていく。
というような経緯で、カメラの性能をきちんと出すことができます。でもこれ真面目にやろうとすると結構大変で、私もそのうち余裕ができたらやろうと思っているくらいです。


定量的な評価まで行かなくても、式からわかる定性的な評価だけでも結構面白いです。例えば分母のノイズの項を考えてみましょう。理想的な暗い空では

Sdark ~ Ssky << Ssig

というような状況かと思います。冷却カメラはこのような状況時に非常に有効です。冷却はダークノイズを下げることができるので

Sdark << Ssky << Ssig

というような状況を作り出せてしまい、より高いS/Nを目指せます。

が、こんな状況はまれで普通は光害などがあり、淡い星雲などを写そうとすると

Sdark << Ssky ~ Ssig

というようになってしまいます。この場合はもともとダークノイズが十分無視できるため、冷却の効果は期待できません。光害地では冷却はあまり意味がないということになります。都市部などもっとひどい時には淡い天体は

Sdark << Ssig << Ssky 

というような状況にもなりますが、こうなってしまうと画像処理で無理やり天体をあぶり出す必要が出てきます。もちろんこのような状況でも撮影枚数や撮影時間を長くとることで、S/Nを改善することはできるということが式の上からわかります。


あとがき

今回色々式から天体撮影のノイズが原理的にどのような振る舞いをするのかを考えましたが、それでもしょせん式から導き出した推測だけに過ぎないことは心に留めて置いてください。なんでもそうなのですが、理論と実測は違います。例えば、S/Nはコンポジット枚数のルートに比例して無限に良くなっていくかと思いがちなのですが、実際にはそんなことはなく、ある程度の枚数に達すると改善しなくなります。例えば考えていなかったノイズに支配されてしまったりするからです。枚数をきちんと重ねられる方は、やはり撮影時の条件がきちんとしていて、多数枚のコンポジットにも耐えうるようなそもそもの素材を作り出していると言えるのでしょう。

もう少し言うと、一般的にどんな実験もそうなのですが、条件をきちんとしてかなり理想的な状況を作り出せば実験は理論に近づいていきます。でも通常は理想的な状態を作るのはものすごく大変なので、なかなかうまくいかないのです。理論が足りなかったり、実験条件が不十分だったりする場合がほとんどです。天体撮影は、夜のしかもとても暗い中でするので、決して環境がいいとは言えません。くれぐれも理想を追い求めるあまり無理をしすぎたりしないで、できないものはできないと割り切って、趣味の範囲で楽しみながら、少なくとも私はそのように進めたいと思っています。


おまけ

最後におまけとして、ノイズを考える例として、コンバージョンファクターを求める時に使った関係式

([ADU])^2 = [ADU] / fc [e-/ADU] + (Nread [e-])^2 / (fc [e-/ADU] )^2


の証明をしてみましょう。証明と言ってもあまり数学的にやるのもつまらないので、できるだけノイズの物理的な意味を具体的に理解できるように考えたいと思います。

ものすごく簡単に考えると、スタートはショットノイズの関係式ということになります。ショットノイズは信号のルートに比例するということです。式で書くと

[e-] = sqrt(S [e-])

両辺2乗して

([e-])^2 = S [e-]

コンバージョンファクター(gain) fc [e-/ADU]を考えると

(fc [e-/ADU] x [ADU])^2 = fc [e-/ADU] x S [ADU]

両辺fcの2乗でわると

([ADU])^2 = [ADU] / fc [e-/ADU]

という求めたい式の読み出しノイズを無視した形が出てきました。これは簡単に信号をショットノイズのみで考えたたためで、信号をきちんとショットノイズと読み出しノイズからなると考えると

[e-] = sqrt( (S [e-])^2 +(Nread [e-])^2 ) )

となるので、同様にして求める式がでてきますが、実際にコンバージョンファクターを求める時も読み出しノイズを無視できるくらい長時間をかけて測定するので、前半までの証明でも十分かと思います。


 

先日の記事で、メーカーが出しているASI294MCの性能のグラフの読み方を考えてみました。実際の性能を確かめるため、SharpCapを使い手持ちのASI294MCの実測もしたのですが、記事自体はかなり一般論になっていて、じゃあ具体的にどのような設定で使えばいいのかという話まではまだ繋がっていません。今回はそこら辺のところを考えてみたいと思います。難しい理屈は嫌だという方は、今回の記事だけ読んでも実用的には役に立つのかもしれません。

IMG_3233



さて今回は
  1. 電視観望
  2. 空が暗く、非常にいい環境での撮影
  3. 光害地での撮影
という3パターンに分けて考えてみましょう。



1. 電視観望

まずは電視観望から始めます。普通の天体撮影をされる方にとっては電視観望というのはあまり一般的ではないかもしれませんが、電視観望はかなり極端な設定を必要としますので、性能の限界を考える時にはなかなか面白いのです。

電視観望では、短時間でのリアルタイムビューを重要視するために、内部ゲインを相当上げて、露光時間をできるだけ短くして臨場感を出します。その代わりにノイズは大きいですし、そのノイズを緩和するためにライブスタックと呼ばれる、いわゆるコンポジットをリアルタイムで行なっていきます。

かなり基本的なところから考えます。まず、内部ゲインを上げるとは一体どういうことなのでしょうか?物理的にはセンサーの後に増幅回路があって、その増幅回路のゲインを上げるということなのですが、これがメーカのグラフの上でどのようなことを意味するのかを考えてみます。

電視観望ではZWOの言うGainを400とか500とか600近くまで上げます。Gainは200で20dB、すなわち10倍、400で40dB、すなわち100倍、600で60dB、すなわち1000倍ということです。簡単のため電視で仮に400まで上げたとしましょう。ZWOが出しているページのグラフの横軸で400のところを見ると、Read noiseは1.4 [e-] 程度とかなり小さい値を示しています。でも画面ではなぜかノイズが目立ちます。Read noiseは小さいはずなのになぜ?という疑問が湧くかもしれません。そこにコンバージョンファクター(ZWOのグラフではGAIN(e-/ADU)となっている2つ目のグラフ)がキーとなります。この値はGain400ではかなり低く、0近くになっていてグラフから読み取ることも困難です。昨日実測した値を見て見ると0.036 [e-/ADU]と記録されています。この値でADCのカウントでどれだけノイズが目立つのか計算してみると、

1.4 [e-]  / 0.036 [e-/ADU] = 39 [ADU]

となり、何とADCの読みで39カウントもノイズが出ていることになります。じゃあ39カウントのノイズって何だと言う話になりますが、分散とかの話をすると難しくなるので、まあざっくり39カウントくらいの間で明るくなったり暗くなったりしているピクセルが画面中にバラついていると考えてください。それよりも意識しておきたいことがあって、このGain400の時のfull wellの値です。full wellとは内部ゲインが高すぎる時にセンサーの出力が限られてしまい、これ以上ADCの値が上がらない上限値のことを指します。これも昨日の実測値を見てみると、何とわずか585です。ADCの値にすると、585が最大値でそのうちの39がノイズだとしたら、1割とは行かないまでもレンジの約7%がノイズになってしまっていることを示します。これじゃあ画面がノイズだらけなのは致し方ないと言うことです。

(追記1: すみません、上の記述勘違いしていました。[e-] が単位のfull wellと、[ADU]が単位の画面のサチレーションを勘違いしていました。ADCのサチレーションカウント16384の中で39カウントノイズになっているだけです。ちなみにゲインを600まで上げると400カウントくらいがノイズになります。これだと4%くらいになるので、これくらいでさすがに目に見えるくらいですね。)

(追記2: 改めてSharpCapのfull wellの値を見ているのですが、どうもこれは真面目に全てのゲインで飽和カウントを測定したわけではなく、単にADCのフルレンジ16384をコンバージョンファクターで割っているだけのようです。これはSharpCapだけでなくZWOの測定結果も同様の方法で簡易的に出しているだけのようです。そう言った意味ではセンサーが出せる最大出力という意味での真のfull wellとは言えないので注意が必要です。あくまで、ADCの最大カウントからくるfull wellがZWO及びSharpCapで示されているに過ぎないということでしょう。)



ライブビューを謳うので露光時間もあまり上げることができません。残る手はSharpCapの秘技、LiveStackです。これは単に画面を重ね合わせるのではなく、恒星の位置を数十個自動認識して、それらが重なるように画面をリアルタイムでコンポジットしていきます。上の読み出しノイズは枚数に正比例(注: 枚数のルートに比例してではありません、ノイズに関しての詳しい議論は後日します。)して減っていきますので、見ている間に劇的にノイズが軽減されていくというわけです。

(追記: 2017/12/212017/12/23実際にASI294MCで電視を試してみました。)


2. 空が暗く、非常にいい環境での撮影

次に、かなり空が暗いすごく環境の良い状態で、撮影をすることを考えて見ましょう。まず、空が暗いということは、長時間露光してもサチルことがないので、一枚一枚の露光時間を長くとることができます。 内部ゲインx 露光時間でヒストグラムのピーク位置が決まります。ピークの位置が左から3分の1程度になればいいとか言われている(これもまた議論の余地があると思いますが、いつか検証します。)ので、適当にゲインと露光時間を調節するのですが、じゃあゲインは具体的にはどれくらいにすればいいのでしょうか?

こんな時に指標になるのが、3つ目のグラフDR、すなわちダイナミックレンジです。ダイナミックレンジはFull wellをRead noiseで割ったものをbit換算したものになります。グラフを見ると一番いいところで13[stops]くらいでしょうか、これは2の13乗を意味し、2^13=8192となるので、信号部分である天体を最大8192階調で表すことができると言うことを示しています。ここで面白いのが、Read noiseが横軸のGain120あたりのところで、いきなりジャンプして劇的に良くなっていることです。このためダイナミックレンジも最初Gainとともに落ちていくのが、Gain120のあたりで再び良くなっています。これはGain120より多少大きいあたりで撮影するのが一番得だということを示しています。このGainでヒストグラムのピークが3分の1くらいになるような露光時間で撮るのが、最も効率のいいセッティングになります。これで時間が許す限り取れるだけの枚数を撮ってしまい、あとはコンポジットしてノイズを減らしていきます。


3. 光害地での撮影

最後に光害地での撮影です。基本的には上の最も効率のいいGain120で、露光時間を短くすることでヒストグラムのピーク位置を3分の1程度のところに持って来ればいいのですが、それでも明るすぎる場合には、Gainを0近くに持ってくる手もあるのかと思います。ダイナミックレンジが一番得をするところを探すという考え方は同じです。ただ、同じクオリティーの画質を出すのにより長い時間かかってしまうので、結局は損をしてしまうと思います。



3パターンで考えましたが、センサーの性能を理解していると、効率のいい設定をあらかじめ予測することができます。もちろんこの設定が完璧というわけではなく、例えば雲が多くて時間が限られている日には多少恒星が飽和するのを覚悟して、Gainを上げて短時間で撮影するなどの戦略をとることもできます。実はこのカメラが欲しかった理由の一つが、センサー感度がいいことを利用しての短時間露光のシンチレーション回避を試してみたいと思っていることなのですが、これはまた上の原則には当てはまらずに、いろいろ戦略を練ることになりそうです。ここら辺は追い追い試していきます。

(追記: 実は上のことだけ考えていると、一般的なカメラ撮影でもダイナミックレンジが一番広い低感度で撮る、すなわちiso100とか極端なのがいいという変な結論に陥ってしまいますが、もちろんそんなわけはないです。これをきちんと考えるためには、撮りたい天体の極限等級、露光にかけたい時間などの要求値をあらかじめ決めておかなければならず、それらの条件のものでノイズを考え、その時のS/Nから要求が満たせるかどうかの判断をして、その要求が充たせる範囲の中でゲインや露光時間を調整すべきです。S/Nの話は、定性的なお話や、定式化までは簡単なのですが、定量的に考えようとすると、読み出しノイズやダークノイズなどのカメラの性能だけでなく、ターゲット天体の明るさを信号として、空の明るさなどをノイズとして数値的にきちんと評価してやらなくてはいけません。具体的にこのブログのレベルで示せるものなのか、ちょっと今試行錯誤中です。)




さて、外を見ると今日は一日中雪が降り続いています。晴れるのはいつになることやら。

もう少し、次はノイズについてちょっとだけ議論したいと思います。


( 追記: ノイズについていろいろ検討してみました。定式化までですが、参考になればというくらいです。定量化はもう少し。)

富山は今日は雪。せっかくの新CMOSカメラも外で試すことができないので、仕方なくASI294MCの脳内シミュレーションです。

ZWOのASI294MCのページを見ると、カメラの性能を表すのにFW, gain, DR, Read noiseだとかいうグラフがならんでいますが、最初これらのグラフを見た時あまり意味がよくわかりませんでした。
  • Read noiseはなんとなく小さい方がいいとわかるのですが、それでもその数値の意味がよくわかりません。
  • DRはdyanmic rangeですが単位の[stops]が不明です。でもグラフの数値が14までなので、これはADCのビットに相当するものなのかという予測がつきます。ということは14というのは2^14で16383という意味なのでしょうか?
  • FWはfull well capacityのことで日本語でいうと飽和電荷数だとか、飽和容量というらしいのですが、一体どんな意味なのでしょうか?
  • gainに至ってはわかりそうなのに全くよくわかりません

一つ一つ紐解いていきましょう。まず、これらグラフの中で出てくる単位のADUだとかe-ですが、ADUはADC(Analog to Digital Converter)で読んでいる単位(Unit)の略でADU。ADCから出てくる数値そのものです。ASI294MCの場合RGB各色で14bitのADCが使われているので、例えばCMOSセンサーの一素子のR(赤)色成分に入ってくる光を露光時間分積分した結果、0から16383のある値をとります。この読み取った値そのものがADUとなります。真っ暗なら0[ADU]、サチルくらいなら16383[ADU]、半分くらいの明るさなら8192[ADU]となります。もちろん値はノイズで揺らいでいるので、真っ暗でも0にはなりません。e-は電子(電荷)の数です。例えば10 [e-]というと、10個の電子がセンサーの一素子で数えられたという意味です。

本当は全部電子の数で考えたいんです。でも直接電子の数を知ることはできません。唯一読み取れるのがADCの値なんです。電子の数はこのADCの値から推測するしかないのです。ところがこの推測が一定の変換ではなく、その変換係数が増幅回路のゲインに依って変わってしまうことが物事を難しくしています。それではこれ以降、個別に考えていきます。


1. gain: conversion factor, コンバージョンファクター

実際には電子の数は簡単には数えられませんね。そこで出てくるのが、一番わかりにくい「gain」というやつです。gainは「Conversion Factor」などと言われたりもしますが、ADCでのカウント数と電子の数を変換してくれるとても便利な値です。なので単位は[e-/ADU]とかになっています。要するに、電子の数は直接数えられなくてもADCでカウントした数は計算機上で数値を読み取ることができるので、このコンバージョンファクターさえ分かっていればADCのカウント数から、幾つ電子が数えられたかを知ることができるのです。例えば、ZWOのASI294MCのページのグラフの横軸のGain(unit0.1dB)の0のところのFW(e-ADC)を見ると、3.9位でしょうか。これはADCが約4カウントを数えると電子を一個数えたことになります。Gainが175くらいのところだと、gainが0.5[e-/ADC]くらいなので、ADCの読み2[ADU]で電子1個を数えたことになります。

そうは言っても、電子の数を数えても何がいいことがあるのかいまいちよくわかりません。でもこれは天体から入ってくる光子の数sと、センサーで数える電子の数nが、定数で変換でききるからなのです。この定数をシステム効率ηなどと呼び

η=n/s

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

このことは次の式を理解すると意味がわかるようになってきます。

センサー感光部に、入射光と暗電流を合わせてカウント[ADU]にあたる一定の電子が発生する時、あるピクセルのカウントの標準偏差を[ADU]、読み出しノイズをNread [e-]とすると、コンバージョンファクター(gain) fc [e-/ADU]は

([ADU])^2 = [ADU] / fc [e-/ADU] + (Nread [e-])^2 / (fc [e-/ADU] )^2

を満たします(証明は略します)。簡単のためNreadは十分小さいとし、右辺2項目を無視します。

例えば1秒間の積分の画像データを100フレーム取得し、各(ij)ピクセル目の100フレームの平均値をカウントSijとして、分散をカウントNij^2として測定することができます。測定したデータを横軸にSij、縦軸にNij^2として各ピクセルをプロットしてやると、例えば一例としてADI294MCで内部ゲイン0の場合のプロットが下の写真の右のグラフのようになります。

IMG_3238


上の関係式があるために、何とADCの値の読みSとその散らばり具合Nを多数プロットするだけで、これまでわからなかった[ADU]と [e-] との関係を導くことができてしまうのです。具体的には、このグラフの傾きがコンバージョンファクターの逆数に相当します。今回の結果によると、グラフの傾きは0.259と測定できたので、コンバージョンファクターは1 / 0.259 = 3.86 [e-/ADC]と測定することができました。この値を、ZWOが測定したASI294MCの値と比べて見ると、上から2番目のGAIN(e-/ADU)のグラフのから3.9程度と読み取ることができるので、実測とメーカーが測定した値とかなり一致していることがわかります。このコンバージョンファクターはカメラの増幅回路のGainに依存するので、各Gainで測定してやらなければいけません。

ちなみに、ZWOのカメラのGianの単位は0.1dBなので、200で20dB、すなわち一桁明るくなります。Gainは294MCの場合600まで上げることができるので、Gain600だと60dBすなわち3桁明るさを明るくすることができるというわけです。そうやってそれぞれのゲインで何点も測定した結果が以下のようになります。

IMG_3235

この結果は実はShaprcapのβ版に搭載された新機能で、カメラの性能を自動で実測して、コンバージョンファクター、読み出しノイズ、full well、実際のゲイン、ダイナミックレンジと評価に必要なデータを、数値データとともに直接出すことができる優れものの機能です。各数値をZWOのASI294MCの測定値と比較しても、かなり一致していることがわかるので、ZWOの出しているデータはかなり信頼できることがわかります。

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



2. FW: full well, 飽和電荷容量

さて、このコンバージョンファクターがわかると、ADCの読みから様々なものが単位 [e-]として、電子の数で数えることができるようになります。例えばfull wellです。十分にサチレーションを起こすくらい明るい光をカメラに入射し、その時のADCの値の平均値を読み取り、それをコンバージョンファクターで電子の数に変換してやったものがfull wellになります。実測から例えばゲイン0だとADCで16385 [ADU]程度カウントされ、full wellが63271 [e-]となっているので、14bitのADCの分解能である16383の全部を使っていることになります。この値もZWOによるASI294MCの測定値の63700と比較してかなり一致していることがわかります。他にも、例えばGain200、すなわち20dBで一桁内部ゲインを上げた時のADCのカウントは1494 [ADU]で、その時のfull wellが5766で、これは14bitのADCフルレンジ16383の約9.1%を使用していることになります。

こうやって考えると、ZWOが今回改善されたと言っているfull wellの値63700は実際にはADCの14bitというダイナミックレンジの上限から制限されていることがわかります。


3. Read noise: 読み出しノイズ

ここまでわかると、Read noiseの意味もやっと分かってきます。日本語でいうと読み出しノイズだとか言われるこのノイズは、センサーの読み出し回路に起因するノイズのことです。これは露光時間に依存せずに短時間撮影でも必ず存在するノイズです。もう一つよく似たノイズにダークノイズというのがあります。こちらはセンサーに光が入っていない時にも暗電流が流れることにより存在してしまうノイズで、時間のルートに比例して増大していくノイズです。

これらのノイズの測定は、実際にはカメラに蓋をしてセンサーに光が入らないような暗い状態で測定したトータルノイズから算出します。測定されるノイズはダークノイズσdark [e-/sec] と読み出しノイズσread [e-]が合わさったノイズが出てきて、実際に測定されるノイズをσとすると、

σ^2 = σdark^2 x t + σread^2

という関係式で書くことができます。ダークノイズは時間のルートで増加していき、読み出しノイズは時間に依存せずに一定なので、十分な積分時間を取ると後者は無視できるため、まずは長時間撮影をしてダークノイズを測定します。その後、2枚の同条件で暗いところで1秒間でとった画像2枚をの差分を取ると、その時のノイズσ2との関係は

σ2^2 = 2 σdark^2 + 2 σread^2

となるため、そのトータルノイズから既知となったダークノイズの貢献分を除くことにより、目的の読み出しノイズを求めることができます。

当然のことながらこれらの測定は全てADCの出力を見ているので単位は [ADU] で出てくるのですが、先に測定したコンバージョンファクターがあるために、電子の数 [e-]に変換することができます。例えばカメラのGainが200、すなわち20dBのとき、今回の実測からRead noiseは1.65 [e-]と出ましたが、この時のコンバージョンファクターが0.35 [e-/ADU]なので、(この20dBというゲインの時は)ADCの出力として1.65 / 0.35 = 4.7 [ADU]くらいのノイズが実際には出てくることになります。

SharpCapはこの読み出しノイズまで自動的に測定してくれる優れものです。実測した値は最小値で1.4 [e-]程度と、ZWOが言っている1.2 [e-]には少し及びませんでしたが、それでも実測でこれならば十分優秀なカメラなのだと思います。


4. DR: dynamic range, ダイナミックレンジ

さて、最後に残ったダイナミックレンジですが、これはもう簡単で、Full wellをRead noiseで割って、bit換算したものです。例えばGainが0の時は63271 / 7.91 = 7999ですが、これをbitで表してやるとほとんど13bitになります。Gainが400の時は585 / 1.43 = 409とかなりダイナミックレンジは小さくなり、bitで書くと8bitが256で9bitが512なので、8bitの後半ということで8.68と出ています。



いま外を見たら、とうとう雪になっていました。今週はまだしばらく天気は期待できそうもありません。そんなわけで、今回は色々と部屋の中で試してしまいましたが、SharpCapの新機能にびっくりするなど、面白いことがたくさんわかりました。今回言えることは、ZWOのASI294MCはメーカーが示している性能と実測値がかなり一致していることがわかったということだと思います。これはある意味驚異的だと思います。

とりあえずなんとかカメラを測定する手段を手に入れたので、次回もう少し手持ちの他のカメラも測定してみようと思っています。


その3: 続きです。実際の使用を想定して見ました。

また、ノイズについてさらに詳しく検証して見ましたので、
興味のある方はこちらをご覧ください。 




 

このページのトップヘ