ほしぞloveログ

天体観測始めました。

カテゴリ:software > SharpCap

天リフオフ会でのMさんからのリクエストにお応えして、SharpCapを使った電視観望でのトラブル解決集を作りました。うまく見えない時に参考にしてください。

電視観望の基本的な説明は
  1. 電視観望を始めてみたい方へ
  2. 電視観望実践編
  3. 電視の楽しさ
をお読み下さい。一度試してみてうまくいかないときに、今回のトラブル解決集が役に立つかもしれません。



以下FAQ集です。他にも気づいたら随時追加していきます。

・バージョンはどれを使ったらいいの?
2018年3月現在の最新版の3.1は、電視観望に使える最適化ボタンがついているのでオススメです。有料ですが大部分の電視観望に必要な機能は無料で使うことができます。バージョン3.0台もしくは2.9台でも電視観望でもちろん使えますが、調整に少しテクニックが必要になります。

・星雲の色が薄い 
まずは比較的見やすい天体から始めましょう。冬ならオリオン大星雲M42、夏なら惑星状星雲のM57が明るくてオススメです。

IMG_3334



・それでもまだ暗い。
露光時間とゲインを調整しましょう。露光時間は1秒くらいから始めましょう。ゲインはとりあえず最大(カメラによって違います)か、ゲイン最大であまりにノイズが多いならそれから50(5dB=1.7倍)とか100(10dB=~3倍)下げたくらい。

・明るさはこれくらいでいいの?
右パネルの中にある、ヒストグラム(Display Histogram Streatch)を見て下さい。ピークが左すぎたりしていませんか?ピークの位置を左側3分の1くらいになるような明るさを目安に、露光時間とゲインを合わせてください。

・画面は十分明るいんだけど、星雲が全く見えません、導入はうまくいっているはずなのに、なんで?
ヒストグラムのところにある、雷のようなマークのボタンを押してください。かなり見栄えが良くなると思います。

・あ、なんか見えた、でもちょっと見えにくいです。
カラーバランスはあっていますか?ヒストグラムの赤、青、緑のピークの位置が同じところになるくらいに、White Bal(R)とWhite Bal(B)を調整してください。その後、もう一度雷ボタンを押してください。


・でもなんか、色が赤っぽかったり、逆に緑ぽかったりしてます。
カラーバランスはかなり微妙です。White Bal(R)とWhite Bal(B)の値を5とかかえると相当印象が変わります。1とか、2くらいでかえて、好みの色になるよう微調整してみてください。その後、雷ボタンを押すのをお忘れなく。

・さっきまで見えていたのに、どこか触ったら突然見えにくくなった。
ゲインとか、露光時間とか、何か変えたりしませんでしたか?そんな時は雷ボタンを必ず再度押してください。

・結構見えるようになったけど、まだ見栄えがイマイチ
雷ボタンも完璧ではありません。試しにヒストグラムにある3本ある黄色い縦の点線のうち、左2本を動かしてみてください。左2本の間の隙間が小さいほど、淡い部分をあぶり出します。一番左の線を動かすと真ん中の線も合わせて動きますが、これで全体の明るさ(バックグラウンド)を調整できます。2本の線の隙間でピークを挟むようにするくらいがいいでしょう。

・結構見えるようになったけど画面がザラザラしている。
ゲインが高すぎるなど、ノイズが多いからです。SharpCapの目玉機能のライブスタックを試してみましょう。上の方にある「Live Stack」ボタンを押してください。下にパネルが出てきます。同時に画面がスタックされてノイズがどんどん少なくなっていくのがわかると思います。

・ライブスタックがうまくいかない 。
「Alignment」機能がうまくいっていない可能性が高いです。画素数が多くて細かすぎるカメラの場合少し調整が必要です。「Alignment」タブの「Minimum star width」と「Maximum star width」の値を増やしてみてください。「Highlight Detected Stars」にチェックを入れると画面上で検出された星にマークがつきます。マークがつかなかったらうまく検出できてない証拠です。

・Alignmentがどうしてもうまくいかない。
とりあえずAlignment機能を切ってしまうのも一つの手です。星が少し流れていきますが、自動追尾のついている赤道儀や経緯台なら多少の時間はだいじょうぶなはずです。

・ライブスタックをしたら突然画面が暗くなったり明るすぎたり。
ライブスタックのヒストグラムで雷ボタンを押していませんか?その場合は右のパネルにある小さいヒストグラムの雷ボタンをの下のリセットボタンを押してください。少し解説すると、①まずはライブスタックにあるヒストグラムでの調整した結果が、②次に右パネルにあるヒストグラムに反映されます。さらに③右パネルでの効果と重ね合わせたものが結果として④メイン画面に表示されます。2箇所のヒストグラムで操作すると混乱してややこしいので、ライブスタックにあるヒストグラムを触るときは、右パネルのヒストグラムは(雷ボタンの下のリセットボタンで)リセットして何の効果もない状態するなどしてわかりやすい状態で試すのがいいと思います。

・いろいろやったけど、それでもまだ星雲が見えない。
暗い星雲に挑戦していませんか?その場合は露光時間を増やして、ゲインを下げてみてください。読み出しノイズが小さくなるので、より淡い星雲まで見えるようになります。15秒くらいまで増やしてみてもいいです。

・それでもどうしても見えない場合は?
都会で明るすぎるとか、満月で明るすぎるとか、環境が悪すぎる場合は見えにくいです。また、カメラの感度が低い、望遠鏡の口径が小さすぎて暗すぎるなどの機器の問題も。薄雲が出ていて見えにくい場合もあります。諦めが肝心な時もあります。時間を置いて冷静に考えるとおかしい部分を思いつくこともあります。トラブル解決も楽しみの一つと思うくらいの気持ちで、余裕を持ってやるのがいいのかなと思います。


皆さんどうでしょうか?役に立ちましたか?
どうしても解決しない場合はこのブログにコメントしてください。相談に乗ります。







 

先日の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分ちょっと。この長さだとガイドが必要になってきます。













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

富山は今日は雪。せっかくの新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: 続きです。実際の使用を想定して見ました。

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




 

この日は馬頭星雲を撮影する前に、もう一つのテストをしました。電視でのShaprCap Pro 3.1β版の新機能ヒストグラムについてです。この間の志摩での電視観望会でなんとインストールしてあった3.1βが現場で期限切れに気づくという間抜けなことがあったので、新たにアップデートしてきちんと動くかどうか試したのですが、大きく変わっているところがありました。電視観望にも大きく関係しそうです。

これまであった「Display Controls」が無くなってしまっていて、その代わりにRGB別のヒストグラム「Display Histogram Stretch」というのが足されていました。ヒストグラム自身は元のバージョンでもライブスタック時に見て調整することはできていたのですが、今回のものはライブスタックとは別に個々の画面でも使えるものです。しかもこの新しいヒストグラムも、これまであったライブスタック時のヒストグラムもRGB化されてるので、ホワイトバランスなどが取りやすくなっています。

とりあえず、M42オリオン大星雲を写して見た画面を載せます。スタック画面で無く、1.6秒露出のワンショットなのでノイズは多いです。新しいヒストグラムが右下に見えていると思います。

IMG_3163



まずスタックをしない時のこの「Display Histogram Stretch」ですが、Black Level、Middle Level、White Levelという3つの線を移動することによりレベルの応答を変えることができます。これはあくまで表示される画面の結果を変えるだけで、カメラの信号そのものを変更するようなものではないです。基本的にはブラックレベルとミドルレベルの線でヒストグラムのピークを挟むことによりより見やすい画面が得られるのですが、今回はヒストグラムのグラフの中にあるイナズマ状の「自動設定ボタン」を押すことによりこのような見やすい画面がほぼ自動で得られるようになっています。実際に上の画面はほとんど何も調整らしい調整はせず、ただこの自動調整ボタンを押したのみです。


IMG_3162


次に、上の画面の様にライブスタックを始めるともう一つのヒストグラムが有効になります。下の方のライブスタックエリアにある「Histogram」タブをクリックすることでスタック時のヒストグラム機能にアクセスできます。でも結果として、スタック無しの個々の画面用、スタック時用と2つのヒストグラムが出てくるので、その関係に戸惑います。

色々試してわかったのですが、単純に言うとまずスタックのヒストグラムの設定が大元の設定になり、その結果がDisplay Histogram Stretchに受け渡され、そこでの設定と合わさったものが画面に表示されるということみたいです。

実際にやる場合は
  1. スタックなしの単独画面の時は右側のDisplay Histogram Stretchで自動設定ボタンを押す。電視の最適化に近いような画面に簡単にすることができる。
  2. スタックがある場合は右側のDisplay Histogram Stretchは自動設定ボタンの下のリセットボタンを押して応答をまっすぐにしておいてから、スタック用のヒストグラムで調整する。スタック用のヒストグラムも自動設定ボタンが同じように使えて、簡単に電視の最適化に近いようなことができる。
  3. スタック用ヒストグラムはさらにカラーバランスを変えることもできる。この結果もそのまま右側のDisplay Histogram Stretchに渡される。
  4. 問題は、スタック用ヒストグラムで調整したことは、スタック用ヒストグラムでは確認できないということです。スタック用ヒストグラムで調整して、右側のDisplay Histogram Stretchでその効果を確認するというやりかたが使いやすいようです。


とにかく電視に関して特筆すべきは、今回はイナズマ状の自動設定ボタンを押すことによりこのような見やすい画面がほぼ自動で得られるようになっていることでしょう。これまであった「Display Controls」のGammaやContrast、Brightnessでの調整もなかなか細かいことができたり、大きくいじることで見えにくかったものが見えてきたりもしたのですが、それと比べても自由度は減っている気はしますが今回の自動設定ボタンはかなり優秀です。自由度は減っても、同じようなことを圧倒的な短時間と、技術に全くよらずにできてしまうことは、電視観望会などで大きな威力を発揮するのかと思います。

馬頭星雲で比較して見ました。最初が以前のバージョンのDisplay Controlsで調整した場合です。

IMG_3165


次が、新しいバージョンの自動設定ボタンで調整した場合です。

IMG_3167

共にスタックしていますが、古いバージョンは6.4秒x26スタック、新しいバージョンは6.4秒x16スタックと、総露出時間が短くても新しいバージョンの方が明らかに綺麗に見えています。

ベータ版で次々に新しい機能が付いてくるので、まだまだ今後のShapCapの進化が本当に楽しみです。


電視に大分満足してきたので、少し精度面を見直そうと思います。

2016/11/7、まず手始めにSharpCapでの極軸合わせです。SharpCapでの極軸の合わせた方自身は以前の記事でレポートしたのですが、その後牛岳での実戦投入で惨敗でしたので、改めて自宅で試しました。

セットアップはAdvanced VXにFS-60CBをつけ、その上にASI224MCを載せました。50mmのCマウントレンズにCSへの変換アダプターを付けてCCDにつけています。その際の画角と画素数から計算すると、1素子あたり15.2秒角になります。

今回、SharpCapを使っての極軸合わせ自身は特に問題なくできました。Advanced VXには微調整のネジがPitch(上下の回転)とYaw(横の回転)方向についているので、合わせ込むと誤差が10秒角以下になるくらいまでになったと表示させることができます。

IMG_0584


ただ、画素の細かさから言ってもこの値自体にはあまり意味がないことは言うまでもありません。実際の誤差がどれくらいか知りたくて、一旦極軸を合わせて誤差10秒以下と表示されてから、再び同じことを何度も繰り返したり、赤経周りに反対に回転させてみたりと試すと、大まかに言って平均で2.5分角くらいの精度でした。

IMG_0587


ただし、今回は赤道儀を赤系方向に手で回してしまったので、モーターで回せばもう少し精度が出るのかもしれません。 また、セットアップの簡略化の一環で、赤道儀の足のところにつけるアイピース台を取り付けなかったので、足を開き上げることができていないため、架台として少し弱い可能性があります。また、鏡筒はFS-60のみと軽かったのですが、赤道儀にウェイトを取り付けなかったのでバランスが悪く、もしかしたらこれが悪さをしている可能性もあります。今回は如何に手を抜いて実用的に出せる精度を見てみたのですが、精度追求という意味でこれらの欠点をなくして今一度確かめたいと思います。また限界を知ると言う意味で、レンズももう少し焦点距離の長いものを使うのもいいかもしれません。

と言うわけで、この状態でカメラでの撮影に挑むと、やっと1分の露光ではほとんど流れなくて、2分露光で流れるものと流れないものが半々というくらいです。特に風もなく、それでも流れるものが半分ということは、すでにピリオディックエラーの影響が出始めている可能性があります。とすると、実際には極軸としてはこのくらいの精度が実用ともいえますので、ピリオディックエラー補正に挑戦してどれくらい改善するのかをみるのが次の手でしょうか。それでも最終的にはガイドが必要だという結論になりそうです。

上の結果を踏まえた今日の成果です。撮影に際し、FS-60CB状態からエクステンダーを再び付けてFS-60Q状態にし、焦点距離を600mmとしました。Canon EOS 60D、ISO6400、120秒でとったM45です。JPEGの撮りっぱなしで未加工です。

M45_LIGHT_120s_6400iso_+19c_60D_20161107-22h23m18s517ms


RAWでも撮っていますが、頑張って加工すれば星間ガスくらいは見えそうです。でもまだダークノイズも撮っていないし、フラット画像をも撮っていないしで、準備不足です。なによりまだ画像処理ソフトがGIMPなどのフリーのものばかりしかないので、これからいろいろ揃えたいと思っています。加工はもう少し先に試そうと思います。

極軸調整その2に続く











昨晩その後の牛岳での電視観望で学んだSharpCapのちょっとしたコツなどを書いておきます。ただし、ASI224MCを繋いだ時の話で、あくまで電視観望用に見栄えが良くなるという観点です。あまり正しい説明ではないと思いますので、各自で実際に試してみてください。


露光時間:
  • 天体の輝度によって調整しますが、明るいもので0.25秒から、暗いものでも10秒くらいまでにしています。

Gain:
  • Maxは600(=60dB=1000倍のこと)まで行きますが、300(=30dB~30倍のこと)以上はソフト上のゲインアップなのであまり得しません。300とか350で使っています。それよりも下のDisplay Contrastなどで調整した方がすぐに結果が反映されるので楽です。

Image Controls: (2018/3/2追記: 現行バージョンの3.1ではこの機能はなくなってしまいました。その代わりにヒストグラム機能であぶり出すことができるようになっています。)
  • Image Controlsは露光及びスタックが始まると、いじっても遅れて効果が出てくるので、ほとんど固定です。
  • Gammaは50で標準。
  • Brightnessは色を出すために最大の240にしてあります。下げて試したりもしたのですが、特に淡い天体ではあまり得しないような印象です。
  • White Balance(R)とWhite Balance(B)はかなり効くので、触ったとしてもほどほどに。以前はこれを盛大にいじって色を無理やり出していましたが、今はIR/UVカットフィルターを入れて、昼間に自然な色合いになるように特に緑色をきちんと合わせて、そこから天体の色に応じてほんの少し見栄えを良くするためにいじるくらいです。

Display Controls: (2018/3/2追記: 現行バージョンの3.1ではこの機能はなくなってしまいました。その代わりにヒストグラム機能であぶり出すことができるようになっています。)
  • スタック途中でもリアルタイムで反応があるDisplay Controlsは微調整に便利です。
  • Gammaは低いほど星雲が滑らかな階調になります。色が濁りますが、あまり気にしません。気になるようなら真ん中らへんにしておきます。逆に背景の黒を締めたいならGammaは高くします。高くしすぎるとつぶつぶ感が出ます。
  • Contrastが高いほど、星雲がはっきり出ます。次のBrightnessとhistgramのタテ軸と合わせて調整します。
  • Brightnessはできるだけ低くします。その分Contrastを上げたほうが見栄えがいいです。

Live Stack:
  • Align Frameは星が見つからないと警告が出るとき以外は基本的にオンにします。多少極軸がずれていても、星を認識して画面上で追いかけてうまく重なるようにスタックしてくれので、多少のズレはカバーしてくれます。一回の露光中に星が流れるくらいだと、さすがに極軸がずれすぎで、Align Fameでも補正しきれません。
  • Align FramesタブののNoise reductionはオン、オフ切り替えて、うまく認識できるように場合によって使い分けてください。
  • Histgramの調整がかなり効きます。この機能はスタックしたときのみ効いて、Individual Framesでは機能しません。横軸の下のつまみをヒストグラムが盛り上がるところらへんに合わせると、背景が黒で締まって、かつ欲しい色を落としません。タテ軸のつまみは欲しい色の立ち上がりを調整しますが、全体の明るさとも大きく関係するので、上のDisplay ControlのContrast及び、Display ConrolのBrightnessと合わせて調整します。横軸の上のつまみが明るい部分の立ち上がりををどこまで引き下げるかですが、淡い星雲ではあまり得することがないので普通はデフォルトのMaxにしておきます。
  • 注意ですが、設定によってはIndividual FramesとStackで全く違う画面になってしまいます。それぞれ得意な値が違うので、切り替え時に適時調整するようにしています。
  • 特に暗い天体はIndividual FramesとStackでは相当印象が違います。明るい天体はIndividual Framesでも十分綺麗に見えますが、それでもStackするとさらに細部が浮き出てきます。

その他:
  • OptionのFull Screenを選ぶと上部のメニューを非表示にすることができます。カーソルを上に持っていくとメニューが現れます。
  • 各種パネルの右上のピンマークをクリックすると、パネルを非表示にすることができます。その際出てくるタブの所にカーソルを持っていくと、パネルが出て来ます。 
  • これらを使うと天体をほぼ画面いっぱいに映し出すことができるので、より迫力が出ます。
  • メニューにあるFXというプラグイン(多分スクリプトで書いたもの)のようなものがいろいろ使えそうです。まだあまり試していませんが、回数を決めたスタックや、イメージブーストも試してみようと思います。画面の一部分だけ効果を適用するというようなこともできるみたいです。

SharpCapを使い込んでいくと、電視用に使うことに関してはどんどん不満がなくなってきました。もう手放すことができないです。あえて言うなら、普通のカメラの設定にあるシャープネスとかもあればいいなと思います。

昨日のTG-SPの自動追尾テストに引き続き、追尾の精度を出すためにSharpCapで極軸の調整をしてみました。使った機材は手持ちのCMOSカメラASI224MC16mmのCSマウントのレンズです。

はっきりいってむちゃくちゃ便利です。しかもとても簡単です。あえて難しいところを言うなら、日本語に対応していないところだけでしょうか。

1. まず、CMOSカメラをどこかにマウントします。今回は高橋の鏡筒バンドの上に固定しました。

IMG_0274


2. CMOSカメラを赤経用の回転軸とだいたい同じ方向に向けます。SharpCapの途中の説明の中には1度から5度までの精度と書いてありました。

3. 次に、赤経回転軸がだいたい北に向くように三脚ごとでいいので、方向を合わせます。これも5度くらいの精度でいいでしょう。実際にはカメラ画像に北極星周りが入ればよく、その範囲はカメラの画角で決まるので、今回のASI224MCで16mmのレンズを使うの場合、横17度、縦12度くらいの範囲が見えます。なので画面の真ん中あたりを中心に使うとすると、5度までというのは的を得た値だと思います。

4. SharpCapを立ち上げ、ToolメニューからPolar Alignを選びます。最初に説明が書いてあるので読んだほうがいいですが、書いてあることは、
  • 赤道儀が必要。
  • 1度から5度までの画角が必要。200mmの焦点距離のガイダーが理想。(と書いてますが、今回の16mmでも十分使えています。)
  • 10個から15個の星が見える必要がある。
  • 初期のアラインメントは5度くらいの精度が必要。
  • 赤道儀は望遠鏡が上方を向くホームポジションから始めるといい。
逆に必要のないものは
  • 正確なファインダーのアラインメントやコーンエラーを正すこと
  • 自動導入
  • 他のソフトやインターネット接続
など、何が必要で何が必要ないかという一般的なことで、大したことではありません。

5. Nextを押して、いよいよ北極星周りの認識です。15個くらいの星を認識しないとダメみたいです。
この時点で北極星周りがきちんと見えていると、Plate solvingでデータとして持っている星図と比較して、各星の位置が認識され、極軸周りに同心円が多数見えます。

IMG_0271

6. 星の認識がうまくいくと、右下のCould not soleveがSolevedに変わります。CMOSカメラの露出時間とゲイン、およびPolar Align設定の中のNoise Reductionが結構効きます。私は0にしました。うまくいくと写真のようになります。

7. Solvedの状態がある程度続くようになったら、Nextを押します。

8. CMOSカメラを含めて、赤道儀を赤経方向に90度位回転させます。

9. 再び星の位置が認識され、写真のようにターゲットの星を矢印のところまで持って行けという指示が出ます。

IMG_0276

10. 三脚をずらすなどして赤道儀全体を動かして、微調整します。このとき注意なのですが、当然赤道儀のモーターを利用して合わせてはいけません。あくまで、架台の方の移動(大きな赤道儀には微調ネジがついていますが、ポタ赤などにはそんな豪華なものは付いていないので、本当に三脚をずらします。)で位置を調整します。合わせている途中で、移動量に応じてターゲットの位置もリアルタイムでずれていきます。ほぼ合わせ終わったのが下の写真です。

IMG_0277


11. ある程度合わせてからNextを押すと、誤差がどれくら残っているか表示されます。

IMG_0280


初めてやったにもかかわらず、実作業は15分くらいでした。この記事を書いている時間の方がはるかに長いです。慣れれば、ものの数分で終わると思います。恐ろしく簡単です。

途中画面上で星の位置を移動して合わせるのに、三脚の足の長さを変えて微調整したのですが、星の村のスターライトフェスティバルでHUQさんに見せていただいた、

IMG_0199


のようなものがあると便利そうです。これどこのメーカーのものなのでしょうか?(2016/10/20 追記: タカハシ製でした。Vixenでもよく似たものを出しているみたいです。「三脚アジャスター」で検索すると出てきます。)

赤道儀の水平出しはしなくていいのでしょうか?とか、考えていたのですが、赤道儀自身がポタ赤で自動導入はしないので赤径の回転軸さえあっていればよく、そもそも水平などもなす必要がないために、このような簡易調整で十分なのですね。

それと似た話で、実は最初極軸を合わせる前、CMOSカメラの中心は赤径の回転軸と合ってなくていいのだろうか?とか、センサー平面は赤経回転軸に垂直になってなくていいのだろうか?など、いろいろ考えました。でも無限遠のものに合わせて回転させて見ているので、場所も角度も極軸が画面内に入るくらい大雑把でいいという事が、やっと理解できました。いやあ、簡単です。(追記: 2016/11/3 牛岳でAdvanced VXにBKP200を乗せ、その上にFS-60を乗せて、さらにその上にASI224を乗せて試した時は全くうまくいきませんでした。合わせ終わって回転させると、回転軸が全く極軸からずれたところで回っています。その後2016/11/7に自宅で試した時はうって変わってうまくいきました。BKP200を無くしたからかもしれません。)



さらにHUQさんが以前コメントで教えてくれたのですが、CMOSカメラが完全にファインダーの代わりになります。しかもより広範囲を明るく見ることができるのと、無理な体勢で覗かなくていいので、はるかに便利です。これでFS-60Qについているファインダーを外して、さらに軽量化する目処がつきました。取り外したファインダーは青色でかっこいいので、同じ青色でまだファインダーのついていないMEADのLX200-25に取り付けようかと思います。

さて、極軸調整の結果ですが、今回は誤差にして10分の1度くらいのオーダー、写真で撮ると20秒くらいは追尾できるようになりました。

LIGHT_Tv20s_3200iso_+23c_60D_20161016-00h21m47s283ms

それよりも他の問題が発生して、どうも追尾できるときと全く追尾しない場合で別れる現象が見られました。どうもギヤの駆動に合わせてどこかでスリップしているみたいです。撤収してから明るいところで調べたら、2箇所ネジが緩んでいました。これは自分のミスです。また、赤道儀自身も中のネジが調整されていないと精度が出ないという記事もどこかにありました。これはメーカーの方で調整する部分だそうです。まだ犯人は確定していませんが、とりあえず自分で閉め忘れていた箇所は締め直し、今晩以降、再度検証です。(追記: 2016/10/17に解決しました。)

あと、追尾がうまくいっているときに問題になるのが、風です。結構揺らされて星像が流れます。さらに機材を軽くしたいのですが、風の揺れのほうで問題になるのかもしれません。三脚がまだたわんで揺れるので、もう少しいい三脚が欲しいです。



このページのトップヘ