ほしぞloveログ

天体観測始めました。

カテゴリ:software > SharpCap

SharpCap(有料版のみ)やASILiveには、リアルタイムでダーク補正をしてくれる機能がついています。これがどこまで有効なのか、常にオンにしておいた方がいいのか?色々やり方はあると思います。今回は私Samが普段どうしているかSharpCapを使って解説したいと思います。


ホットピクセルがはいずった痕

SharpCapでの電視観望中Live stackをしていると、よく赤、青、緑の単色のミミズみたいなノイズが入ることがあります。「ホットピクセル」とか言われているもので、長時間露光時やセンサー温度が高い時に出てくるダークノイズの言われるもの一種です(下の画像をクリックして拡大して見て下さい)。
hot

この画像は、自動追尾さえしてなくて、Livestackのみで星像を重ねています。なのでこんな短時間で長いミミズさんがでてますが、自動追尾している場合は同じ時間ならこれより遥かに短くなります。

いずれにせよ電視観望でも見栄えが良くないので、これを取り除きたくなるかと思います。こんな時はリアルタイムでダーク補正ができる機能があります。


ダーク補正機能の注意点1

SharpCapでのダーク補正は簡単で便利なのですが、いくつか注意があります。まず一つ目、これはSharpCapに限らず一般的なことなのですが、

撮影したダークフレームは、
同じ露光時間、同じゲインでしか
使用できない

ということです。見たいものが安定していて、露光時間とゲインが確定していれば問題ないのですが、電視観望みたいに露光時間やゲインをちょこちょこ変えて見ていると、ダークフレームをどの設定で撮影すればいいか決まりません。もちろん厳密に合わせなくてもダーク補正の効果はあります。ただし、設定がズレればずれるほど、その補正効果も小さくなっていくので、やはりできるだけ合わせておいた方がいいでしょう。

実際の電視観望では、導入時(移動する動きを見たいので、露光時間は例えば400ms程度)、観察時(止まっているので長い露光時間、例えば1.6秒とか、3.2秒、長くても12.8秒程度まで)の露光時間をあらかじめ決めておきます。ゲインは最大から一段階下げるくらいで、高い位置のままいじりません。このようにして、ダークフレームは観察時の設定に合わせるように一種類だけ撮影しておけば、基本的には事足りるはずです。何種類もとって切り替えてもいいですが、観望会でお客さんがいる時などは、時間のロスになってしまうかもしれません。


ダーク補正機能の使い方

SharpCapでの実際のダーク補正のやり方です。

1. まずはメニューの「キャプチャ」から「ダークフレームキャプチャ」を選びます。
2. 撮影前に、必ず鏡筒に蓋をするのを忘れないで下さい。
3. 枚数は多くなくていいです。8枚とか、16枚で十分でしょう。ただし、撮影のようなことをしたくて数十分以上とかの超長時間ライブスタックを掛ける場合はそれなりの枚数にして下さい。
darkcapture

4. ダークフレームの撮影を開始し、スタックし終わるのを待ちます。
darkcapturing

5. ダークファイルができたら、右の「前処理」タブの「ダーク補正」で「参照」を押し、ダークファイルを選択します。自動的にできたファイルのフォルダに移動さるはずなので、そこにあるファイルを選べばいいでしょう。

これでLive stackをしてみると、目立っていたミミズさんはすっかり消えているはずです。ただ、細かいたくさんの縞が残るかもしれません。それでもダーク補正しないよりはマシになるかと思います。

LS_80


ダーク補正機能の注意点2

さて、ここから少しテクニックです。この状態で鏡筒にカバーをしてヒストグラムを見てみましょう。
nohot

ここでの問題は、ヒストグラムの山の左端が切れてしまっていることです。SharpCapでは輝度が負の値になるようなことはなく、0以下は全て0になるようなので、ものすごくおかしなことは発生しません。でもこれは読み出しノイズがガウス分布に従わずに、不自然な状態になってしまっていることになります。言い換えると、
リードノイズの暗い部分はバッサリ斬られていて、
階調がとれなくなります
これが2つ目の注意点です。

階調がとれないとはどういうことでしょうか?例えば、先ほどの北アメリカ星雲を見ている時に輝度をあえて下げてやって、ヒストグラムの山の左端を欠いてやります。

LS_bad

ライブスタックのヒストグラムの左が欠けていますね。すると色バランスが損なわれ、どういじってもこの画像のように見た目にもおかしいものしか出てきません。

これは極端な場合なので、普通に電視観望している範囲では基本的にはこんなことは発生しません。でも、もし画像を見て階調が取れないような時は変にヒストグラムがカットされていないかを疑った方がいいこともあるので、心に留めておきましょう。


ヒストグラムの山を回復する

さて、リードノイズに関して、このような階調不足を避ける方法を考えます。まず、ダークフレームを撮影する前に、右の「画像情報」タブの「輝度」のところを、最初から少しあげておきます

withhot

私は最大値(ASI294MCの場合80)の半分くらい(40)にします。ポイントは右パネルのの「ヒストグラムストレッチ」で見て、まずはダークフレーム取得時点で山の左が欠けていないことを保証すること。山の左すそが、一番下まで言っていればいいです。山が左に行きすぎて左すそが途中で無くなっているような状況は避けてください。

ここまではいいのですが、この状態でダークフレームを撮影してダーク補正を適用すると、オフセットも消そうとするためヒストグラムの山の左が欠けた状態になります。
nohot

ここで、さらに「画像情報」タブの「輝度」の値を上げて、ヒストグラムに山の左側に欠けがないように再び設定します。

nohot_withoffset
山が回復したのがわかるかと思います。

ちなみに、電視観望をやっているだけなら、上記の補正は特にしなくても、特におかしいことはないと思います。補正の有無で以下のようになります。

LS_80
輝度補正なし(40のまま)。

LS_80real
輝度補正あり(80に増加)。

補正有無で比べても特にどちらかが悪いということはないと思います。ただこれを画像処理とかして、撮影画像とかして扱うときは補正なしだと少し気をつけた方がいいかもしれません。リードノイズに相当する部分が既に破綻しているので、もしかしたら何か影響があるかもしれません。


リアルタイムダーク補正は必要か?

ちなみに、私は電視観望の際は大原則としてリアルタイムダーク補正はしません。理由は、露光時間、ゲインを頻繁に変えることが多いからです。また、月や惑星などの明るい天体を見ていて、ライブスタックに入らないような場合には、ホットピクセルは点のままで線にはならないので、そこまで問題にならないはずです。

ホットピクセルが多い場合(カメラの機種に依りますし、気温にも依ります。)で、ライブスタックに入り、かつ露光時間とゲインの設定をあまりいじらなくていいくらいになると、リアルタイムダーク補正をすることがあります。特に、ライブスタックで数分以上の長さでしばらく放っておくような時です。

リアルタイムダーク補正を行う際は、上で説明したリードノイズの山の形の補正は必ずやるようにしています。といっても、炙り出しがキワキワになった時にもしかしたら効くかもしれないと思ってしまうからという程度です。

あとよく似たことで、リアルタイムフラット補正は使ったことがないです。これは鏡筒の方向を変えるとカブリなどの状況がガラッと変わるからです。かなり昔に一度だけリアルタイムフラット補正を試したことがありますが、あまりうまくいかなくてそれ以来使っていません。その頃から大分状況は変わっているので、もしかしたら今試してみたらもう少しいい方法があるのかもしれません。


まとめ

いつかこのリアルタイムダーク補正の話を書こうと思って、途中書きになっていたのですが、前回の記事のコメントでちょうどカトーさんからダーク補正についての質問がありました。これが答えになってくれるといいのですが。


ASI294MMで撮影後、画像処理をしていたのですが、一つトラブルがあったのでメモがてら記述しておきます。


ASI224MC Proでの天体撮影

NINAでライトフレーム
NINAを使い普通に天体を撮影しました。ASI294MMはセンサーにIMX492を使っていて、bin1だと8288x5644とかなりの高解像度になります。DSOだとそこまでいらないので、本来のASI294MC(IMX294使用)と同じ4144x2822になるようにNINA上でbin2モードでライトフレームを撮影しました。

SharpCapで補正用フレーム
画像処理用にバイアスフレーム、ダークフレーム、フラットフレーム、フラットダークフレームを撮影する必要があるのですが、画面のレスポンスやヒストグラムの見やすさなどから、SharpCapを使って、これらの後処理用のファイルを撮影しました。その時は解像度を 4144x2822にするために「11 megapixel」の方を選んでbin1を選びました。高解像度の場合には「47 megapixel」なのですが、この場合bin2は選べないようなので、4144x2822にするには「11 megapixelでbin1」が唯一の選択肢になります。


WBPPできない⁉︎

撮影自体はいいのですが、これらを使ってPixInsightで画像処理をしようとするとはまります。下の画像のように、ライトフレームに警告マークが入っていて、バイアス、ダーク、フラットどれも補正してくれにというのです。
binning2x2
最初何が悪いのかわからなかったのですが、色々触っているとどうもビニングの設定が、NINAで撮影したライトフレームは2x2、その他SharpCapで撮影したフレームは1x1となっているのが問題だとわかってきました。でもどちらも画素数は4144x2822です。


解決法

一番簡単な方法は、NINAで補正フレームをライトと同条件にして、全て取り直すことです。でもフラットフレームは撮り直すと合わないことがあるので、できればNINAでの撮り直しは避けたいです。

ここまで撮影してきたファイルをなんとか使うことはできないのでしょうか?

まずわかったのは、このビニング情報はFITSファイルのヘッダに書かれているテキスト情報をただ読んでいるだけなので、例えばライトフレームのヘッダの2x2を1x1に書き換えてやれば、PixInsight上で各種補正をしてくれることはわかりました。


本当にこの方法でいいの?

そうすると次は、そもそもNINAで2x2ビニングと、SharpCapの11 megapixelで1x1ビニングは同じ効果なのか?ソフトウェアビニングが入る余地はないのか?などが疑問になってきました。

海外のページをあたっていくと、特にSharpCapで初期にASI294MMに対応したときに結構な時間をかけてZWOともコンタクトを取りながら決めていった過程を辿ることができました。おそらくは多分混乱のないようにわかりやすくするために高解像度でビニングのない47 megapixelモードと、低解像度で14bitにしたハードウェアビンニングの11 megapixelモードと、あからさまに切り分けたのかと思います。おそらくこの切り分け方が、本来のASI294MMの294の名を冠したことから考えると、正しいのかと思います。

もう一つ重要なことは、ASI294MM Prp発売当初、ここら辺のことで混乱した人が何人もいたようなのですが、先人達の色々な検証の結果一つ言えることは「どんなソフトでも2x2のビニングを入れると確実にハードウェアビニングが入る」ということのようです。なので、NINAで単にbin2を選んだとしても、ソフトウェアビニングになっていることはないということが分かります。

実際のところは自分で検証しない限りは確実ではないですが、調べている限りこの情報は正しいようなので、画像処理を進めるためにもとりあえず1x1と2x2で名前は違うけれど、共にハードウェアビンニングが適用され、4144x2822の画像ができていると思うことにします。


実際のヘッダー情報の書き換え

となると、あとはどうやってFITSヘッダーを書き換えるかです。一枚一枚書き換えていってもいいのですが、ここにあるキーワードの値を書き換える、PixInsight上で動くスクリプトが公開されています。



今回はこれを利用しました。実際にはXBINNING、YBINNINGをそれぞれ書き換える必要があるため、2回走らせます。注意はソースの途中の拡張子が「.fit」になっているてため、「.fits」にしてやることと、最初の方のoldKeywordValueなどの値が「2.」とか小数点まで入れてやらないと動かない時があることくらいです。


WBPPで処理再開

これでライトフレームを1x1ビニングと騙してやることで、下のようにうまくPixInsightのWBPPを走らせ、
binning2x2_mod
きちんと各種補正も適用することができました。

さて、やっとこれでM27の画像処理を続けられます。

sanpojinさんのSharpCapでの極軸測定がうまくいかないという記事を見て、どうもたわみが原因な気がしました。三脚の足を伸ばし切って極軸測定しているため、足元が弱くて、赤経体を90度回転させるとたわんで正確な測定ができていないのではと思ったのです。

逆に、もしたわみによって極軸調整の精度がずれするなら、そのSharpCapでのズレの値評価することでたわみ自身が定量的に測定できるのではと思い、今回考えてみました。

IMG_0829


たわみの測定原理

簡単なところから考えます。

まず、赤道儀が完全に天の北極を向いていて、極軸に誤差がない状態を考えます。もしこの状態でSharpCapで極軸調整をしたら、誤差は0と出ます。この誤差がなく、赤経体が最初上を向いている状態を初期状態としてはじめます。
  1. 最初極軸に誤差がない状態から、SharpCapの極軸測定中に90度赤経体を西側に回転させたときにたわみが発生したとします。簡単のために、鉛直方向に鏡筒が傾き、視野が1度角下を向いたとします。
  2. このときSharpCapは極軸が元々1度ずれていたのか、それともたわんだ結果1度角ずれて見えているのか分からないため、とにかく極軸が1度ずれていると表示してしまいます。
  3. そこで人間が赤道儀の仰角を1度(間違えて)上げることでSharpCapは正しく極軸が設定されたと勘違いをします。でも現実にはこの時点ではSharpCapも人間も本当は極軸が間違っていたのか、たわみでずれたのか知る由はありません。
さて、この90度回転している状態で、再度極軸調整を最初からやり直します。
  1. 鏡筒はまだ下に1度角ずれたところを見ていますが、SharpCapはそんなことは知りませんし、お構いなしです。
  2. 再び赤経体を90度戻す方向に回転させると、今度は鏡筒のたわみが解消され元の位置に戻ります。
  3. そのとき、西側に倒していたものを戻したので、鏡筒は東側にたわみが1度角戻る方向に動きます。
  4. SharpCapは最初の鏡筒の位置のズレなどお構いなしなので、最初から見て視野が1度東にずれたことのみを認識します。すなわち極軸が東1度ずれていると表示するわけです。
  5. と、同時に1回目の調整で勘違いして赤道儀を上に1度角ずらしてしまっているので、そのズレも検出されます。そのため、SharpCapは東と上方向に極軸が1度角ずれていると認識します。
2度目の測定で出た結果のズレは元々たわみから来ているので、たわみのずれの量そのものと比例しているというわけです。

最初極軸が理想的にあっている状態から考えましたが、もし1度目の極軸調整の前にもともと極軸がずれていたとしたらどうなるでしょうか?それでも1度目の調整を終えた後は「極軸があった状態+たわみでずれた位置」になるので、2度目の調整時のはじめには同じ状態になりますね。


イメージしにくい場合

上の説明を読んでもなかなかわかりにくいと思います。まずはSharpCapでの極軸調整(ちょっと古い記事ですがリンクを張っておきます。)を一度試してみて下さい。これをやらないと何を言っているのかよく分からないと思います。

その上で、90度赤経体を回転させたときに、たわみの代わりに赤緯体をコントローラーで例えば1度角落とす方向に回転させることを考えてみて下さい。その赤緯体の回転を補正するように、赤道儀全体の向きを変えるというようにイメージするとよくわかるかもしれません。

赤経体を90度戻すときも、先ほど赤緯体を1度角落としたのをコントローラーで戻してやると考えるとわかりやすいと思います。


他の方向のたわみの例

他のたわみの方向も同様に考えてみます。
  • もし最初に赤経体を90度西側に傾けたときに、たわみが西側(外側)に1度でるなら、それを補正するように東に赤道儀を1度間違って調整し、2度目の極軸調整で90度戻すときに上に1度角たわみが戻るのを下向きに補正するので、東の下向き方向に極軸がずれていると表示されるはずです。
  • 赤経体を西に回転させたときに、たわみが東側に起きることもあるでしょう。
  • 視野を考えているので、もしかしたらたわみ(見ている方向が)が上向きに動くことも可能性としてはあるでしょう。

全部の場合を書き出してみる

全部の場合をまとめて書いておきます。

赤経体を西に回転させたとき
  • たわみが下向き -> 東上向きのズレになる
  • たわみが西向き -> 東下向きのズレになる
  • たわみが東向き -> 西上向きのズレになる
  • たわみが上向き -> 西下向きのズレになる

赤経体を東に回転させたとき
  • たわみが下向き -> 西上向きのズレになる
  • たわみが西向き -> 東上向きのズレになる
  • たわみが東向き -> 西下向きのズレになる
  • たわみが上向き -> 東下向きのズレになる
となります。


一般化

簡単な数学で考えてみます。今、東のズレと西のズレをそれぞれ右のズレと左のズレと考えると、赤経体を西に回転させたときは、「たわみからSharpCapでのずれ」の変換が+135度の回転写像、赤経体を東に回転させたときは「たわみからSharpCapでのずれ」の変換が-135度の回転写像と考えることができます。

一般化すると、SharpCapで最初の極軸調整で90度赤経体を進めて、2度目に90度戻してたときの誤差を(x2, y2)とすると、たわみによってずれた角度(x1,y1)は

x1 = x2 cosθ - y2 sinθ
y1 = x2 sinθ + y2 cosθ

となる。θは赤経体を西に回転させたときは+135度、赤経体を東に回転させたときは-135度である。ただし、赤経体を元の位置に戻したらたわみは戻るものと仮定する。

ということが言えます。

ちなみにsin135°=1/√2、cos135°=-1/√2なので、

x1 = -1/√2 (x2 + y2)
y1 = 1/√2 (x2 - y2)

となります。


現実的には

でもこのままだとちょっと計算が面倒なので、簡単のためにもっと現実的な場合を考えましょう。基本的にたわみはほぼ垂直方向にのみ起こると考えってしまって差し支えないと思います。なので、x2とy2の絶対値はほぼ同じような値になると期待できます。SharpCapの2度目の極軸調整で出てきた誤差のx2かy2のどちらかの値を√2 = 1.4倍くらいしてやった値が実際のたわみと考えてほぼ差し支えないと思います。

もしx2とy2の絶対値に結構な差があるならば、たわみに横向きの成分があることになります。

まじめに計算してもいいのですが、もし更なる測定を厭わないならば、最初に西向きに赤経体を回転させて2度測定したならば、次は東向きに赤経体を回転させてさらに2度測定します。東向きの誤差の結果をx4、y4とすると、(もし横向きのたわみが西に回転させたら西に、東に回転させたら東に出るならば)
  • x2とx4は逆符号で、絶対値は似たような値
  • y2とy4はどう符号で絶対値は似たような値
になるはずです。なので、x2+x4は0で、
  • (x2-x4)/2が横方向のたわみを表し
  • (y2+y4)/2が縦方向のたわみを表します。
一番厄介なのが、もし横向きのたわみが西に回転させたら西に、東に回転させても西に出る(多分レアな)場合で、これはどうしようもないです。向きだけでなく、たわみの大きさも違う可能性があり、東向きと西向きを測定し、真面目に計算する方が早いです。まあ、そもそも横方向のたわみを相手にすること自身稀だと思うので、こんなのはホントにレアなケースだと思いますが。


任意の回転角のたわみ量

今回の結果は赤経体を90度傾けた時のたわみ量です。90度以下の場合はφにたわみを知りたい赤経体の角度を入れてcosφを上の結果にかけてやればいいいと思います。


赤緯体の場合

でも今回求めたのは、今回は赤経体の角度が変わった時のたわみ量だけなんですよね。赤緯体が回転した時のたわみ量はSharpCapを使う今回の方法では全く太刀打ちできません。赤緯体の方でまたいいアイデアがあったらブログに書きます。


まとめ

とりあえず頭の中でざっくり考えただけなので、もしかしたら何か勘違いしてるかもです。一度実際のSharpCapを使って、夜に赤緯体の回転をたわみとして試してみようと思います。

ラッキーイメージの過程で、M87を撮影して見ました。M87といえば...

目的はもちろんジェットを見ることです。

さてさて、うまく見えるのでしょうか?


SharpCapでのディザー

実際の撮影は前回のラッキーイメージNGC4216の後に続けて撮影しています。なので設定は全く同じで、10秒露光を30回LiveStackして、今画像を見たら10枚撮影していたので、合計50分でした。

前回書くのを忘れましたので、今回改めて書いておきます。SharpCapの最新ベータ版を使っていますが、ディザー対応がかなり改善されています。

一番大きいのがLiveStackパネルのguidingタブのところに「Reduce Exposure While Dithering 」とうオプションができたことです。これはPHD2などとの連携でディザーをしている間は露光時間を短くするという意味で、以前はDhitherの間も露光し続けていたので、例えば5分間の露光とすると、ディザーが終わっても最大5分近く待たなければならず、まるまる1枚は必ず無駄になっていました。撮影毎にディザーしていたら、撮影時間の最低半分はディザーに取られてしまっていたので、ほとんど使い物にならなかったのです。

そのため、SharpCapでディザーは実質やる気にならず、結果SharpCapは長時間露光は向いていない、もしくはできないという結論でした。今回のオプションで、SharpCapにも長時間露光での撮影に道が開いたことになります。

今回のLiveStack撮影でも、ディザーは使っています。ディザーを15分毎にするように設定しているために、(10秒x30ライブスタックを)3枚撮影するたびにディザーが適用されます。でもディザー量を試しに減らしたため、揺れ幅が不十分で、縞ノイズが少し出てしいました。


画像処理と結果

今回は鑑賞目的というよりは、少し科学写真に近くなりますので、画像処理はほとんど凝ったことはしてません。ダーク補正はLiveStack中にリアルタイムでしてます。WBPPではフラット補正のみで、バイアス補正もなし、ダーク補正もなしです。あとはストレッチと、一度トーンカーブで暗いところを持ち上げて暗いでしょうか。あ、恒星の色を出すために少しだけ彩度を上げています。


「M87」
masterLight_ABE_ABE_ABE_AS_HT2
  • 撮影日: 2021年4月11日0時49分-4月8日1時45分
  • 撮影場所: 富山県富山市
  • 鏡筒: Vixen VC200L
  • フィルター: なし
  • 赤道儀: Celestron CGEM II
  • カメラ:  ZWO ASI294MC Pro、-10℃
  • ガイド: f120mmガイド鏡 + ASI120MM mini、PHD2によるマルチスターガイドでディザリング
  • 撮影: SharpCap、gain420、露光時間10秒x30枚のライブスタック x10枚 = 50分、ダークは10秒x64枚をライブスタック中にリアルタイムで補正、フラット128枚(gain420、露光0.78ミリ秒)、フラットダーク128枚(gain420、露光0.78ミリ秒)
  • 画像処理: PixInsight、Photoshop CC


でも困ったことに、JPEGに落とす時点でM87の周りの淡いところの諧調が制限されてしまい、階段上になってしまいます。あと撮影中に少したわみで流れたみたいで、ディザーであまり散らしてなかったので明るくすると縦の縞ノイズが少し出ていました。

さてさて、ジェットは見えてますでしょうか?拡大してみます。

masterLight_ABE_ABE_ABE_AS_HT3_cut

おおー、右上にはっきり見えてますねー!上が北なので、方向から考えてもジェットで間違いなさそうです。不思議なのは、切り出すとJPEGでも諧調が飛ばないことです。そこそこきれいに見えてますね。自分で撮影したものだと、感動もひとしおです。

6000万光年先の銀河で、ジェットの長さは7-8000光年におよぶそうです。ご存知の通り、2019年に超長基線の電波干渉計によりM87の姿が映し出されました。リング形の中心にブラックホールが存在すると考えられています。このリング中の黒いところは直径1000億km程度なのですが、これがそのままブラックホールというわけではなく、事象の地平線は直径400億kmでもっと小さいと考えられているそうです。



ついでにアノテーションです。ここにもそこそこの数の銀河があります。

masterLight_ABE_ABE_ABE_AS_HT2_Annotated

少し斜めになってしまっています。これは前々回の記事の最後に書いた、鏡筒バンドに対してまだ鏡筒の回転方向を合わせ切らずに撮影してしまったからです。実際にはこのM87で回転が残っているのに気付いて、この撮影の直後に直しました。


M87といえば

M87といえば、M87JETさんを真っ先に思い出します。胎内星まつりで初めてお会いしたのですが、当時からほしぞloveログを読んでいてくれて、興奮気味に自分で撮影したM87のジェットを見せてくれした。ペンネームをそのままM87JETとしようと思っている」と、その時お聞きしました。その後は小海の星と自然のフェスタでも一緒に食事したりしてました。いつも面白い文体のブログ記事を書いていて、最近はISSの追尾でご活躍されています。



M87JETさーん、やっと私もジェットを取ることができましたよ!


 

とうとう念願の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の一眼レフの対応にあたって、これまでEOS 6Dで試してきましたが、今回残りの手持ちの機種でもテストしてみました。

 



手持ちの一眼レフカメラの接続テスト

前回電視観望まで試したEOS 6D以外にはEOS kiss X5とEOS kiss X7とEOS 60Dがあります。



X7はノーマルですが、娘のものなのでとりあえず手を出さないようにしておいて、X5と60Dを試すことにします。この2機種は天体改造済みのもの。なので接続テスト後は赤外の星雲とか見てみるのも面白いはずです。

先週末の金曜の夜、時間が少しあったのでその2機種のテストをしました。60Dはそのまま問題なく繋がり、X5の方も最初つながらないと思ったのですが、単なるミスで、手順さえ間違えなければそのまま順調に動きました。ちなみにミスというのは、
  • 最初動画モードでやっていてエラーが出た(でもそのあとさらに動画モードで試したら動いたので、この時点でバッテリーがギリギリだったのかも)。
  • バッテリーが空だった。
  • バッテリーを変えて、1枚だけ撮れたが、また動かなくなった。と思ったら変えたバッテリーも空だった。
  • 接続ケーブルのコネクタがゆるゆるで、いつのまにか抜けていた。
と、簡単なことばかりです。でも古い機種とかいう先入観があるとダメですね。「あー、やっぱり動かないんだな」と思ってしまいます。皆さんはくれぐれも私のような間抜けなミスは避けてください。


安価な電視観望入門セットアップの可能性

60DとX5の両方ともが動いたのと、夜になって天気も良くなってきたので、外でどう映るかのテストをしてみます。どちらにしようか迷いましたが、より安価で使える方をと思い、X5で試すことにしました。

レンズはキタムラかどこかで中古で数千円で手に入れた、キットレンズクラスのEF 28-80mm  F3.5-5.6で、昔一度三脚ごと倒れて壊れたやつです。CANON CAMERA MUSEUMに1991年発売で、定価42000円とあるので、付属レンズではなかったのかもしれません。これを80mm側で使います。なのでF5.6でそこそこ暗いです。

ちなみに、当時のX5のレンズキットにはEF-S18-55 IS IIがついてきたそうです。ダブルズームキットだとEF-S55-250mm F4-5.6 IS IIなので、電視観望には後者の方が焦点距離的にはいいかもしれません。中古だと、本体だけだと1万円台前半から後半、レンズキットで2万円代前半でした。もしこのテストがうまくいくなら、これくらいの値段からなら始めたいという人がいるかもしれません。

全くの初心者、
もしくは一眼レフカメラだけを持っている人が
電視観望に挑戦した場合、どんなことができるのか?

という可能性を示せればと思っています。いかに電視観望に対する敷居を下げるのかというのも目標としたいところなので、できるだけ安価にすむというのは大きなファクターの一つです。

以前も格安電視観望について記事を書いたことがありますが、電視観望をする際、一番高価になるなのがCMOSカメラなのです。安価なCMOSカメラはセンサー面積が小さく導入が難しくなり、その一方、十分な面積のセンサーを持つCMOSカメラはかなり高価で、そのことが初心者に対する敷居を上げてしまっています。

中古市場ではもうかなり安価なX5でもAPS-Cサイズで、電視観望で主流のマイクロフォーサーズサイズのASI294MCより既に大きいのです。でも値段だけで考えたら5分の1から10分の1とかでしょうか。これはうまくいったら相当インパクトがありそうです。


EOS X5による電視観望テスト

とりえずテストの結果を見てみましょう。まずはファーストライト。雲がある時のオリオン座付近です。全景が見えるようにZoomが25%です。20秒露光で4枚スタックなので、80秒ぶんです。

IMG_0710

ノイズも多少ありますが、意外に悪くなさそう。

雲がなくなった時に少しだけ拡大(33%)。同じく20秒露光で4枚スタック、80秒ぶんです。

IMG_0713

馬頭星雲とかも一応出てますね。

さらにM42部分を拡大。20秒が5枚です。

IMG_0715

うーん、ノイズはまだ多いですが、写りはそんなに悪くないですね。高々80mmのレンズで、M42部分をかなり拡大していることになるのですが、恒星がそこまで肥大していないです。レンズ枚数が少ないのか?F5.6で暗いから収差も小さいのか?これなら観望会で見せることも許容範囲かと思います。

X5のセンサーはAPS-Cの22.3×14.9mmで5184×3456ドット。ここから計算すると1ピクセル4.3μmで、ASI294MCのピクセルサイズとほぼ同じサイズです。感度はほぼほぼ1ピクセルのサイズに比例するので、ASI294MCクラスが格安で買えると考えると、かなりお得かもしれません。

一方、馬頭星雲と燃える木をみると、もう少し赤の感度が欲しいかなというところです。

IMG_0717
これで20秒x6枚です。一応天体改造済みでこれなので、センサーの感度そのものはASI294MCに比べるとやはりもう少しといったところなのでしょうか。今回使ったのがF5.6と結構暗いレンズなので、レンズを明るいものに変えることでまだまだ改善はするはずです。さらにQPBとかの光害フィルターもつけていないので、その分も改善するかもしれません。

もう一つ、M31アンドロメダ銀河です。これで20秒x5枚、計100秒です。

IMG_0724

ちょっとノイジーですが、何とか構造も見えかています。ここらへんまで見えるなら、十分楽しめるのではないかと思います。

視野が回転し始めてるがわかるくらいまで、5分くらいまでスタックしたのが下の画像です。ノイズがまだノイズが大きいですね。スタックでのノイズ軽減があまり効果的に見えません。でも今回はダーク補正もしていないので、次の課題はここらへんのノイズの緩和とかでしょう。

IMG_0729


最後はM42すばるの20x13=4分20秒スタック。これも回転が見え始めています。青い分子雲がわずかに見えかています。CBPとか試すと面白いかもしれません。

IMG_0736


この日の環境

ちなみにですが、この日は月齢23日で、下弦からもう少し欠けた位の、まだまだ明るい月夜です。場所も自宅の庭からで、光害フィルターも無しです。普通に考えたら星雲や銀河を見るような状況ではないにもかかわらず、ここまで見えているのは随分と頑張っているのではないでしょうか。環境がいい状態で試すとまだまだ改善しそうです。

今回使ったものは一眼レフカメラの中でも入門クラスで、レンズもキットレンズクラス。それも結構昔のもので中古市場では値段もかなりこなれています。少なくとも、CMOSカメラしか選択肢がなかった状況から、中古の一眼レフカメラまで範疇に入ってくるとなると、はるかに可能性が開けると思います。


電視観望と撮影の境界

実はこのテストをしている時に、結構いろいろ考えさせられました。果たして電視観望と撮影の境界はどこだろうというものです。一眼レフカメラを使って、15秒とか20秒とかの露光で連続してシャッターを切るのは、もう撮影ではないのか?という疑問を持つ方も多いと思います。リアルタイム性として考えると、少なくとも動画のようになるわけではありません。

私自身は、それでもまだはっきりとした境界が存在すると考えています。特に今回のテストを通してよりはっきり自覚できるようになりました。

大枠での定義は、目的の天体がモニターなどを通して「観望しているその場で」十分に見えているなら、それは電視観望と言っていいのでは。もし、その場で十分に見えなくて、「後の画像処理」をして初めて十分に見えるようになるのなら、それは電視観望というよりは撮影という範疇に入るのではということです。

例えば、
  • 今回使ったX5とレンズだけで、赤道儀に載せて10秒の露光をして、カメラ付属のモニターに出してみるだけだと、おそらく「後の画像処理」がなければ十分天体が見えることにならないと思うので、これは電視観望ではないと思います。
  • 一方、HUQさんが最初にやったように、α7Sで1/4秒露光で動画モードでHDMI出力してその場で十分見えるようにしている場合は、十分電視観望と言えるでしょう。
  • 例えば、暗い空でX5で1分くらいと十分露光して、目的とする天体が十分出ていて、それをその場で楽しむというのなら、これはリアルタイム性は薄いけれども電視観望と言ってしまってもいいのかと思います。
どれくらいの露光時間かではなかなか定義はできないので、その場で楽しめるかどうかというところがポイントになるのかと考えるようになってきました。 


電視観望を可能にする重要な技術

電視観望の技術の中で、いくつか非常に重要なものがあります。例えばSharpCapのヒストグラムでのオートストレッチボタンや、ストレッチ関数と呼ばれる中間値と黒レベルを利用した、リアルタイムでの簡易画像処理です。これは「その場で天体を楽しむ」ということに大きく貢献しています。

また、LiveStackも電視観望の重要な技術だと思います。もっと具体的に言うと、単に画像をその場で重ね合わせるだけでなく、また画面の平行移動や回転だけで星を合わせるだけでもなく、LiveStack時に星の位置をきちんと認識して画面を歪ませて星を合わせていく技術です。PixInsightやSequatorなどでは後の処理で同様の画面を歪ませての位置合わせはできます。でもその場で毎回やるわけにはいかないので、電視観望のツールにはなり得ません。こういった高度な処理をリアルタイムで行うことで、星像を肥大させずにスタックし、ノイズを減らしていくことができます。さらに言うと、この技術を用いると赤道儀も必要とせず、たとえ経緯台で視野が回転してもきちんと星の位置が合うということです。もっと言うと、ある程度広角にして、見ている間に天体が画面から逃げていかなければ、経緯台さえも必要とせず、固定の三脚だけで星像の肥大を避けスタックしていくことができます。

このような高度な技術はいまのところ私が知る限り、PC上ではSharpCapとASIStudioのみ。私はまだ使っていないですがASIAIRも同様の機能を持っているはずです。最近ではeVscopeも同等の機能を持っているのかもしれません?他には、電視観望用のハードウェアのRevolution Imagerがありますが、こちらはスタック機能は持っていますが、スタック回数を何回かに制限しているだけで、星像を合わせてスタックするような機能は持っていません。

リアルタイムで画像処理に近いような事をして、その場で天体をあぶり出す事でより楽しめるようになり、そう言った意味ではSharpCapは電視観望という分野を切り開いた秀逸なソフトと言うことができるでしょう。

こういった高度な機能はあればもちろんいいのでしょうが、たとえそんな機能がなくても、その場でモニターとかに写して天体がみんなと共有で楽しめたりするならば、もう電視観望の一種と言ってしまっていいのかと思います。これから先、さらに技術が発達して、その場で楽しむことはより簡単になり、手法もどんどん広がっていくことでしょう。電視観望の概念も柔軟に変化していけばいいのかと思います。


まとめ

今回のEOS X5は、元々中古で安価で手に入れたたものです。SharpCapが一眼レフカメラを扱えるようになったことで、使う機会が少なくなってきた中古のカメラに、また一つ大きな可能性が開かれようとしています。

本来SharpCapと一眼レフカメラを繋ぐというのは、撮影時の取り扱いを便利にするというが元々の目的だと思います。それだけではなく、LiveViewモードを明示的に分けて実装してくれるなど、EAA(電視観望)用途として考えると、今回のアップデートは相当なエポックメーキングなのかと思います。

現在はテスト段階なので、本当に初心者が触るとなるとまだ敷居が高くて不安定なところもあります。でもこれは今度どんどん改良されていくことでしょう。このブログも、興味を持った人たちができるだけスムーズに楽しめるように、説明やサポートなどで貢献できていければと思っています。

手持ちのカメラや、安価な中古の一眼レフカメラを利用するなどで、電視観望の敷居が下がり、天文人口の裾野が広がってくれればと思っています。

昨日のSharpCapの一眼レフ対応の騒動から一夜明けてブログを書いています。まだちょっと興奮気味です。


SharpCapバージョンアップ間近

何日か前からSharpCapのβテストフォーラムで3.3βが間も無くリリースされるというニュースはあがっていました。金曜の夜にも確認し、そろそろかなと思って土曜の昼くらいに見たらすでにリリースされてるではないですか!

バージョン3.2から3.3βへの大きな変更点は、シーケンサー操作と、デジタル一眼レフカメラのサポートです。電視観望にとっては後者が重要です。


これまでの一眼レフへの対応状況

以前にもSharpCapで一眼レフを使う方法は少なからずありました。2018年の夏頃でしょうか、ASCOMの一眼レフカメラのドライバーを使ってSharpCapからアクセするするというものです。

でも実際私も6Dで試したりしたのですが、全く動きませんでした。その当時、幾らかの実際に動いた人がSharpCapでライブスタックを試したりもしていたそうですが、その方法はかなりトリッキーでした。カメラから直接、PC上のあるフォルダに画像ファイル書き込んで、そのフォルダ内のファイルをSharpCapが読み取ってスタックするというのが唯一の方法だったはずです。私の場合は、そもそもそれを試すところまでたどり着けない状態で、非常に不安定でした。

その後ちょくちょく気にしてはいましたが、年単位でなかなか進展がなく、そのため前回の記事のようにSIGMA fpに走って電視観望を試したりしていました。


なぜSharpCapと一眼レフカメラ?

ではそもそも、なぜSharpCapで一眼レフカメラが使えるといいのか?

一般的には撮影です。PCからカメラが制御できれば、ファイルのPCへの取り込みや、設定を変えながらの撮影、リモート操作などにつながります。でもこれらのことはこれまでも、少なくともCanonの場合はEOS UtilityやBackYardEOSを使うことでかなり以前から実現されてます。まだ私は試してませんが最近ではNINAを使ってもできるはずです。

でもSharpCapでしかできないことがあります。一般的にいう天体写真の画像処理を、簡易的にですがリアルタイムでしてしまうことです。オートストレッチやヒストグラムを見ながらのマニュアルストレッチ、LiveStackを使ってのノイズ緩和、ダーク補正やフラット補正もリアルタイムでできてしまいます。

さらにスタック時には、撮影した画面を元に星が重なるように画面を移動して追いかけます。しかもただ追いかけるだけでなく、個々の星の位置を認識し、画面を歪ませて星位置を合わせながらスタックしていきます。

これらの機能は、なかなか他のソフトでは実現できていなくて、今のところ知る限りSharpCapとASIStudioの中のASILiveのみです。これらの機能が電視観望へと繋がっていきます。快適な電視観望はこのような高度な機能の上に初めて成り立つのです。

SharpCapで一般の一眼レフカメラを使うことができると、より大きなセンサーをより安価に利用して電視観望を実現する道が開かれるのです。

そこにきて、昨日におけるSharpCap 3.3βのリリースです。まだβテスト段階に過ぎませんが、今回のバージョンでこれまで滞っていた一眼レフカメラのサポートが一気に進んだ感があります。


現段階での対応状況

さて、これらを動かすためにはASCOM環境がインストールされている必要があります。ASCOM Platformはここからダウンロードしてインストールします。DSLR(一眼レフカメラ)用のASMOMドライバーはいまだ開発段階のような状況で、私はここからダウンロードしました。インストールするとわかるのですが、接続方法は
  • CanonSdk
  • BackyardEOS
  • Nikon
  • Pentax
  • NikonLegacy
とあります。いくつかの説明を見る限り、LiveViewはCanonとNikonのみと書いてありますが、この説明も古い可能性がありますので、ここの機器の対応は現段階では自分で試す必要がありそうです。現状としては、
  • Canonは少なくとも私のところで動きました。
  • Nikonは智さん、あぷらなーとさんが動かしたという報告があります。ASCOMドライバーのカメラ選択のメニューで「ニコン」だと不安定でしたが、「ニコン・レガシー」だと比較的安定だったとのこと。
  • Sony用カメラのドライバーもあるようですが、Sonyカメラを持っていないので試せてはいません。 HUQさんが試したようですが、動かないと言っていました。
ところがです、あぷらなーとさんのところでNikonのD810をSharpCapで動かそうとしたらエラーで本体が壊れたという情報が流れました。幸い「バッテリーを抜いて強制電源OFFした後、電源を再投入してシャッターボタン長押し」で復帰したそうですが、まだ一番最初の一般向けのβテスト段階ですので、何か試す場合も自己責任で、くれぐれもご注意下さい。


SharpCapから実際に一眼レフを動かしてみる

さて、実際のテストの様子です。SharpCap3.3βのインストールはここを見てください。注意書きにもあり、また繰り返しにもなりますが、あくまでβテストです。自己責任で、人柱になるくらいの覚悟を持って、最悪機器が壊れてもいいような環境で試すことを強くお勧めします。撮影に使っている主力機などはまだこの段階では試すべきではないかもしれません。

IMG_0549


ASCOM関連もきちんとインストールしてあれば、あとはカメラとPCを繋ぐだけです。SharpCap3.3βを立ち上げてCameraのところを選ぶと、該当するカメラが出てきているはずです。それを選ぶと「カシャーン」シャッタを開ける音がして接続完了です。

この時点で「Snapshot」を押せば、撮影した画像が出てくるはずです。もし何も出て来なかったらカメラのキャップが外れてるかとか、露光時間が短か過ぎないかとか、ISOが低過ぎないかとかきちんと確かめてみてください。夜にいきなり本番で試す前に、一度昼間明るいところで試してみて、まずはきちんと動くかどうか確かめた方がいいと思います。


LiveViewモード

ここからが新機能です。メニュー下の左端にある新しい「LiveView」を押します。するとシャッターが「カシャーン、カシャーン、カシャーン」と鳴り始め、連続での撮影が始まります。これがこれまでのCMOSカメラでの通常の撮影にあたります。ずっとシャッターを切り続けるので、シャッター回数を気にする人はやはりまだ躊躇すべきかもしれません。もしくは露光時間を長くして対処した方が良いのかと思います。通常、これまでのCMOSカメラはメカニカルシャッターなどは、SharpCapでカメラを接続すると連続でずっと撮影をし続けています。

本当は電視シャッターを持っているか、もしくはミラーアップ撮影ができれば良いのですが、私のところのCanonでも、智さんのところのNikonでもミラーアップにした途端SharpCapが止まってしまいました。私のほうはまだマシで、ミラーアップを解除したらまたSharpCapが動き出したのですが、智さんのところはミラーアップにした途端エラーでSharpCapが落ちてしまったそうです。ここら辺は今後改良されることを期待するしかないと思います。


あと、少し理解しておいた方が良いことは、メニュー下の「Capture」とかは画像データをディスクに「保存する」ということを意味します。カメラを繋いだ段階で、保存はしなくても撮影(PCに画像を送ること)はし続けていて、保存はせずに画像を捨て続けているということです。一眼レフになってもこれは同じ概念のようで、シャッターを切り続けても、PC上のディスクにも、カメラ内の記録カードにも画像は一切保存されません。これがデフォルトの設定のようです。

表示された画像は、ヒストグラムの3本の線で見え方を変えることもできます。簡単なのは真ん中の線で、左右に動かすと明るくなったり暗くなったりするのがわかると思います。画像処理でのあぶり出しの効果を撮影している最中にできるというわけです。SharpCapの有料版のライセンスを持っている方は、オートストレッチもできます。ヒストグラム右の雷のようなボタンを押してください。簡単にある程度の最適化ができます。


とうとう、LiveStackができた! 

ここまでのテストが終わったら、次はLiveStackを立ち上げます。すると、シャッタを毎回切るとともに画像がスタックされていきます。これを見た時、おおっ!!!と感動しました。

とうとう念願だった一眼レフカメラによる電視観望で、リアルタイムに炙り出しまで実現できる道が開かれたことになります。

さらに、Live Stack中にSave Allというオプションを選ぶことができて、こうするとPCに全てのシャッターの画像ファイルが保存されるようです。でも、それでもカメラカード内には何も保存されないみたいです。

この時点で16時過ぎくらいだったでしょうか。Twitterに投げたところ、すごい反響でした。特にあぷらなーとさんは狂喜乱舞。これまでの複雑な解析手法を相当簡略化できるとのことで、早速追試して、上記の通りカメラを壊しそうになったというわけです。

テストは上記の写真の通り、昼間の明るいうちに行いました。できれば夜に実際の空で試したいのですが、天気予報は曇り。果たしでどうなるか?


実際に夜の星を見てみる

夕方過ぎ、暗くなってきたのですが全面に雲が出ています。落ち着かなくてちょくちょく外に出て見てみると、20時半頃でしょうか、ごく一部ですが薄雲越しに星が見えています。雨は大丈夫そうなので、とりあえず機材を出そうと思い、AZ-GTiに6Dを取り付けて外に持っていきます。レンズはNikonの135mm f2.8です。下の写真はちょうど天頂付近をみている様子を上の方から撮影したものです。6Dの文字が誇らしげに見えると思います。
IMG_0556
あとで写真だけ見たら、一瞬背景が星に見えました。実際はアスファルトです。

カメラと接続して外に置いたPCではもちろんSharpCapの3.3βを走らせます。さらにAZ-GTiをコントロールするSynScan Proを走らせて、このPC自体を部屋からリモートデスクトップで接続します。まだ暑いので、クーラの効いた部屋で快適リモート電視観望です。

さて、実際の6Dでの電視観望ファーストショットです。

IMG_0563

ISO6400、10秒露光の一発撮りです。10秒ごとにこんな画像が出てきます。QBPがついているので、ヒストグラムであぶりだしてやると、淡いですがすでに星雲が見えています。上の方が網状星雲、下の方が北アメリカ星雲です。

レンズの焦点距離は 135mm。これまでツースターで使っていたフォーサーズのASI294MCと比べて、フルサイズの6Dの場合1.85倍くらいセンサーの一辺が長くなるので、同じレンズで3.5倍くらいの面積が見えます。ASI294MCで135mm/1.85~75mmくらいのレンズを使うと同じような面積になりますが、恒星の見え具合は直焦点の場合レンズの焦点距離に比例してよくなります。6Dで135mmレンズを使う場合、ASI294MCで75mmのレンズを使う場合に比べて1.85倍くらい暗い星まで見えることになります。1等級以上くらい星まで見えるようになります。

星が画面いっぱいに散りばめられたような電視観望にしたい場合は、長焦点のレンズを使うことが必須になります。これまではセンサー面積が小さいと狭い範囲しか見れないことが、フルサイズのセンサーを使うことで解決されたわけです。 

でもこの画面を撮った直後に雲が出てきて、LiveStackはお預け。しばらく待ちます。


ついにLiveStackで星雲がはっきりと!

その後10分くらい待つとすぐにまた雲がひらけてきて、ついに6DのLive Stackで星雲をはっきり映し出すことに成功しました!!!

IMG_0566

LiveStackなので、待てば待つほど背景のノイズが少なくなってきて、星雲がどんどん見えてきます。上の画像で15秒x8=120秒、ISOは6400です。

しかもアラインメントも普通に成功です。SharpCapのアラインメント機能はものすごく優秀で、撮影した画面の中の個々の星の位置を認識し、画面を歪ませて星位置を合わせながらスタックしていきます。このためある程度広角のレンズなら赤道儀や経緯台の自動追尾なども必要なく、固定三脚でも十分実用な電視観望ができます。

操作性に関していうと、少なくとも6Dの場合は露光時間もゲインもSharpCap上から調整できます。もうCMOSカメラと変わらないくらいの操作性です。ただしカラーバランスを調整できるのはLiveStack中のみでした。CMOSカメラの時にできた取り込み時の赤と青の調整は、そもそもパネル自体が出てこないです。

とりえずうまくいったのですが、この後またモニター上で見ても雲に覆われてしまって、外に出たら空全体が厚い雲で覆われてました。雨が心配だったのでそのまま機材も片付けることにしました。一瞬のテストチャンスだったみたいです。


一眼レフカメラがSharpCapで使えることのメリットのまとめ


今一度一眼レフカメラがSharpCapで使えることのメリットをまとめておきます。
  • まず、センサー面積が大きくなる。
  • 同じ面積を見るのに、焦点距離を伸ばすことができる。
  • より暗い恒星まで見えるので、星いっぱいの電視観望になる。
  • 見える面積が広がるので、特に初心者にとっては導入が楽になる
  • 中古一眼レフカメラは安価なので、大きなセンサーが安く手に入る。フルサイズのCCDやCMOSカメラはものすごく高い。初心者では全く出が出ないほど高い。
  • カメラ用の安いレンズを電視観望に使うことができる。これはこちらのページをご参照ください。
  • 初心者が初めて電視観望を始める時、一番高いのがカメラです。この値段が下がる可能性があるので、電視観望の敷居が一気に下がることが期待できる。
など、メリットだらけです。一方デメリットは
  • まだ操作が少し複雑。最初のうちは丁寧なインストラクションや解説が必要。
  • 安定性に問題がある。これは時間が解決することになると思う。
  • シャッターを切り続けるので、シャッターの寿命が気になる
など、どれもソフト的になんとか解決しそうなものです。


まとめ

とにかく、これまで面積の大きいセンサーを使うことが(ものすごく高価で)大変で、小さい面積で初心者は四苦八苦してたはずなのです。面積が小さいと、最初に天体がセンサーないに入って来なくて、導入がすごく難しいのです。一眼レフカメラが利用できるとなると、今までベストと言われてきたフォーサーズのASI294MCよりも大きな、APS-Cとか、もしかしたらフルサイズまで安価に手に入れられるかもしれません。もしくは手持ちのカメラがあったら簡単に試すこともできるかもしれません。これらが解決するなら、さらに電視観望の敷居が下がり、天文人口の増加につながるかもしれません。 

今回のSharpCapのアップデートは大きなエポックメーキングです。このブログでは電視観望にターゲットを絞って説明しましたが、あぷらなーとさんのように他にもメリットを感じるケースは多々あるかと思います。今回触って感想として、私的には極上の電視観望用のカメラが増えたような、得した気分になれました。

私はSharpCapの開発には全然貢献できていなくて、ただのユーザーにすぎないのですが、開発陣の努力に心から感謝します。今回のようにソフトの改良、特に最近はAZ-GTiのようなハードと柔軟なソフトの組み合わせで状況が劇的に変わり、以前よりはるかに便利になったりしています。プレートソルブなんかも良い例かと思います。私が星を始めてわずか4年の間にも物事は大きく変わってきています。まだまだこれからの将来も楽しみでなりません。 


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

このページのトップヘ