ほしぞloveログ

天体観測始めました。

カテゴリ: software

昨日のM8干潟星雲とM20三裂星雲の画像処理の最中に、おかしなことが起きました。結構一般的な話なので、ここでまとめておきます。

下は、SV405CCで撮影した3分露光、34枚をPixInsightのWBPPでインテグレーションした直後の画像をオートストレッチしたものですが、見て分りますように階調が全く無くなってしまうということがありました。

masterLight_BIN-1_4144x2820_EXPOSURE-180.00s_FILTER-NoFilter_RGB

何が問題だったかと言うと、Pedestalの設定をするのを忘れてしまっていたからです。WBPPのCalibrationタブでLightsを選択した時に、右隣のパネルの2段目に出てくる「Output Pedestal Settings」のところで設定できます。
pedestal
私は普段毎回ここを「Automatic」にしています。ただこの設定、WBPPのパネルを開けるたびに度々リセットされてAutomaticでなくなることがあります。今回は「Literal Value」に勝手になってしまっていました。改めて「Automatic」に設定して、WBPPの処理をし直すと下のようにきちんと淡い部分の階調が戻ってきました。

masterLight_BIN-1_4144x2820_EXPOSURE-180.00s_FILTER-NoFilter_RGB

多分これはSV405CCに限ることではなく、オフセットが小さくてダーク補正などで0以下のピクセルが多数出たときに一般的起きる現象です。特に今回はSV405CCのオフセット量が最大255のうち、40という低い値で撮影したことも原因の一つなのかと思います。

このような場合に、画像処理時に上記のようにPedestal設定で回避できるので、もし同様の階調がなぜか出ない現象で困っている方がいたら、是非試してみてください。


  1. SV405CCの評価(その1): センサー編 
  2. SV405CCの評価(その2): 撮影編 
  3. SV405CCの評価(その3): 画像比較
  4. SV405CCの評価(その4): 新ドライバーでの画像比較
  5. SV405CCの評価(その5): 青ズレの調査と作例
  6. 番外編1: 階調が出ない時のPedestalの効果
  7. 番外編2: ASI294MC Proでの結露

前回、SCA260で撮影した馬頭星雲のことを記事にしましたが、3月のオリオン座は早くに西の空に傾くため、後半は別の天体を撮影することにしました。撮影が複数日にまたがっていたので、フラットやダークが使いまわせるよう、基本何も変えない同じ露光時間、同じゲイン、同じカメラ回転角が条件です。

少し迷ったのですが、M100に決めました。理由は
  1. 春の銀河まつりに参戦するのは今年の目標の一つであること
  2. M33などの大きな銀河はすでに試したので、少し小さめの銀河を試したかったこと
  3. 以前おとめ座銀河団を広角で撮影した時にM99やM100が小さいながらもかっこよかったから
などです。

 


まだ赤道儀はCGEM IIで撮影したときのものです。撮影は3分露光です。M100は小さいので真ん中らへんに小さく写っているだけです。これで分解能が出るのかが今回の勝負です。

でも結論だけ言うと、撮影した画像を見て早々と勝負に負けました。やはりこれくらい小さい天体を撮ろうとすると、揺れが大きすぎるのです。


撮影のことはもう忘却の彼方に

撮影は3月3日と3月9日の二日に渡りました。最初の3月3日の方はまだ使えたのが
  • R:18/20枚、G:20/20枚、B:20/20枚
とマシでしたが(それでもかなり甘い判断です)、3月9日の方は(もう忘れてしまいましたが、風が多少拭いていたのかと思いますが)使えたのがわずか、
  • R:4/12枚、G:2/10枚、B:4/35枚
と散々でした。画像を見ていると、大きく揺れて2つの点になってしまっているのが多かったです。これを見て、さすがにCGEM IIで系外銀河の分解能に挑戦するのは辛いことが実感できました。まあ、頭では何となくわかっていたのですが、信じたくないバイアスがかかっていたのかも...。

本当は3月3日の撮影でBがまだまだノイジーだなと思い、3月9日はBを重点的に撮り増ししたのですが、使えたBはわずか1割と、この揺れのおかげであまりやる気が起きずに、実際の撮影からかなり日にちが経ってしまいました。とりあえず見えるだけでいいやと重い腰を上げ、やっと画像処理を進めることにしました。


WBPPの変化

PixInsightのWBPPですが、最近いくつか気づいたことがあります。まずBiasファイルですが、これはDarkファイルがBaisを含んでいるために、もう処理には使われていません。CalibrationタブのDark設定のところであえてBiasを含まないというオプションを使うと、「検証の結果、biasを引いたダークは今後はお勧めしない」と怒られてしまいます。かといって、Biasファイルを全く指定しないとエラーで止まったりするので、Master Biasをおまじないで登録しておくことにしています。ちょっとまだ整合性が取れていないようです。

あと、Pedestalというのを入れてみることにしました。これは画像処理の過程で0以下の輝度になることを防ぐようです。
WBPP
最近のWBPPでの設定。

Reference画像をオートで選ぶと、たいていRとかの明るく画質がいいのを選んでくれるのですが、これを基準にしてしまうと例えば暗いBがIntegration時に大量に弾かれてしまうことがわかりました。実際にIntegrationされたのはわずか
  • R:21/22枚、G:16/22枚、B:11/24枚
でした。これは前回の馬頭星雲でも同じことが起きていて、原因がわからなかったのですが、Reference画像をマニュアルであえて暗めのものを選ぶことで回避できることがわかりました。その結果、
  • R:22/22枚、G:22/22枚、B:24/24枚
と全てIntegrationに回りました

RGB合成した画像を見てみると、揺れが平均化されているせいか、かなり真円に近くなりました。
Image27_ABE_PCC_crop_DBE_mosaic01

これだといいと思ってしまうかもしれませんが、一枚一枚は揺れていることと、大きく揺れることもあるので採択率は悪いし、何より銀河の解像度は出ていないはずなのでやはりダメです。


EZ Deonを(少しだけ)使ったdeconvolution

今回の画像処理のポイントは、PixInsightでDecomvolutionを試してみたことです。実はこれまで何回も試していたのですが、一度もうまく行ったことがなく、今回ScriptsにあるEZ Deconを使うことではじめておかしくない結果が得られました。

そもそもDeconvolutionはPSFをあらかじめ作るとか、StarNETであらかじめマスクを作っておくとか、R Range maskが必要とか結構面倒です。しかもマスクをの微調整で結果が劇的に変わったりします。参考にしたのはniwaさんのページ


相変わらずものすごく親切な説明で、素晴らしいです。とても感謝しています。さらにはリンギングを無くすために皆さんでいろいろ議論されたことも、最後の方のリンク先から辿ることができ、かなり実用的です。

それでもこのDeconvolution、なかなかうまくいかないんですよね。なので今回EZ Deconという簡単にdeconvolutionを試すことができるスクリプトを使いました。EZ DeconはEZ Processing Suiteの中の一つで、インストール方法はこちらを見るとわかります。


上のページは英語ですが、niwaさんが日本語でも解説してくれています。


EZ Deconを走らせると、こんな画面になります。
decom1

最初はよく分からないのでおもむろに「How to use EZ Decon」というヘルプボタンを押します。読んでいくと以下のようなことが書いてあります。

1. まずは処理したい画像(リニアステージのもの)を選択し、Star Maskを作れと言います。このスクリプトはまだStarNETのV2には対応していないようなので、今回は別途StarNet  V2で星マスクと作っておいて、スクリプト中で選択しました。

2. 次のレンジマスクはこのスクリプトでおまかせして作ってもらいました。

3. 最後「Deconvolution」タブをに移って、PSFを作れとのこと。なんとこのスクリプト、PSFが「Generate PSF」ボタン一発でできてしまいます。これはかなり楽です。

4. ここからがすごいです。deconvolutionを試すのですが、「Evaluate EZ Decon Run」ボタンを押すたびにタブが増えていき、右の方の「Change Tab to Original」ボタンと「Change Tab to Decon Run XX」ボタンを交互に繰り返し押すと、オリジナルとの違いを簡単に切り替えて比較することができます。基本的に変更できるパラメータはスターマスクをどう扱うかのみ。ヘルプに書いてますが、スターマスクを強調したりソフトにしたりすることで結果の違いを見ます。
  • もし画像がノイジーになるなら、Wavletの強さ(strength)を増やす。
  • もし画像がシャープになりすぎるなら、繰り返し(iteration)の数を減らす。
  • もし恒星にリンギングが出るなら、Star Maskの半径を増やして、恒星をよりカバーする。
とのことです。

5. うまくいきそうなら、最後に下の「Run EZ Decon」を押して実際の画像に反映させます。

でも結局このEZ deconでは、どうしても最後までリンギングが残ってしまい、結果は使わなかたんですよね。その代わり、EZ deconで生成されたPSF画像を使い、niwaさんが解説してくれていた、このページ

のもりのせいかつkさんのGlobal dark 0方法でやることで、リンギングを抑えてうまく細部を出すことができたようです。

decon_comp

左がDeconvolution前、右がDeconvolution後です。EZ Star Reductionもかけてしまったので、恒星の大きさは無視してください。銀河の細部は多少出てるようになったと思います。

というわけで、このEZ Decon、結局は簡単PSF生成ツールとしてしか使いませんでしたが、スターマスクの効き具合の感覚とかを気軽に試して、振る舞いを理解するのにはすごく役に立ちました。deconvolutionで困っている人は、一度同じように試すといいのかもしれません。

ところで、DeconvolutionのLocal supportというのがいまいち何をしているのかわかりません。スターマスクをリンギング防止に使っているのなら、恒星自身のdeconvolutionができていない気もするのです。実際、恒星がスリムになったような効果は見えませんでした。そういうものなのか、それとも撮影条件が悪くあまり効かないのか、もう少し理解する必要がありそうです。

その後、ものはついでにEZ star reductionも適用しました。以前、トール兜星雲の時にも試しましたが、その時はそこまで有用性は見出せませんでしたが、今回はかなりの効果があったようです。


いつものPhotohopでの仕上げ

あとは普通にPhotoshopに持っていっての処理でしょうか。今回少し違ったのは、Photoshopで細部があまり出せなかったことです。すでにdeconvolutionである程度の細部出しができているためでしょうか。試しにdeconvolutionなしの画像をPhotoshopに引き渡し、いつも通り加工するのですが、こちらは細部が出てきます。ですが、出来上がった画像の細部はほぼ同等でした。細部をどこで出すかだけの問題で、その画像が持っている限界があり、ポテンシャル以上のものは出ないということがよくわかりました。まだまだDeconvolutionをたいして試していないので、少し甘い気もしますが、むしろ自然な処理具合な気がしています。今後は(やっとですが)Deconvolutionの方に移行していくことになると思います。

結果です。

「M100」
Image27_ABE_PCC_crop_DBE_decom_stredu_ABE_PCC6
  • 撮影日: 2022年3月3日23時51分-3月4日4時37分、3月10日2時54分-5時1分
  • 撮影場所: 富山県富山市自宅
  • 鏡筒: SHARP STAR製 SCA260(f1300mm)
  • フィルター: Baader RGB
  • 赤道儀: Celestron CGEM II
  • カメラ: ZWO ASI294MM Pro (-10℃)
  • ガイド:  f120mmガイド鏡 + ASI290MM、PHD2によるマルチスターガイドでディザリング
  • 撮影: NINA、Gain 120、露光時間3分、R: 22枚、G: 22枚、B: 24枚の計68枚で総露光時間3時間24分
  • Dark: Gain 120、露光時間3分、128枚
  • Flat, Darkflat: Gain 120、露光時間 RGB: 0.08秒、RGBそれぞれ128枚
  • 画像処理: PixInsight、Photoshop CC

実は赤ポチとか青ポチとか期待してHαとOIIIも撮影したのですが、枚数が少なすぎで諦めました。M100の周りの淡いところがもう少し出るかと期待していたのですが、少し露光時間が足りないのかもしれません。もしくはゲインを例えばもう3倍とか上げた方がよかったかもしれません。

恒例のAnnotationです。M100の他にもNGC4312を始めいくつか銀河があるのがわかります。

Image27_ABE_PCC_crop_DBE_decom_stredu_ABE_PCC6_Annotated

最後に、FS-60CBで撮影した時画像
up_DBE_DBE_PCC_AS_HT_all_disks_back2_rot_denoise_larage_cut
からM100の同じ領域を抜き出して拡大してみます。
FS-60

回転して向きをあわせてますが、左端は映ってない領域でした。恒星はまだいいとして、FS-60CBで撮ったM100の解像度が良すぎてなんか怖いです。


まとめ

撮影途中で揺れているのがわかってしまい、あまりやる気の出なかった画像処理ですが、やってみると意外に実のあるものでした。これまで何度も試してことごとく諦めていたDeconvolutionですが、今回のこのEZ Deconでできなかったらもう2度とやらないかもしれないと思いながらやりました。まだ満足とはいきませんが、今後続けていく気にはなりました。それでもFS-60CBで撮ったのが今思うとすごすぎます。SCA260の口径が大きくてもまだ揺れが大きくて性能出しきれていないのでしょう。

まだCGEM IIで撮影した、M101が残っています。サクッと終わらせたいのですが、とにかく忙しくてなかなか時間が取れません。某天文雑誌の原稿もやっと目処がついてきました。その後、晴れてやっとCGX-Lで三つ子銀河と、M51の画像処理ができます。


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とずれているのかもしれません。こうなったら修理コースなので、もう少しいろいろ試してから結論を出したいと思います。


3月3日の雛まつりの日の夜、月の出が22時18分なので、夕方から準備すればしばらくの間撮影できそうです。狙いは迷ってましたが、早い時間なので季節遅れのカリフォルニア星雲にすることに。結構大きいので、FC-60CBと6Dで視野角的にもちょうど良さそうです。今回も狙いは自宅でフィルターなしでどこまで写るのか? (2021/3/19 追記: 勘違いで、CBPが入ったままでした。)ISO800で、露光時間3分にして、6Dのヒストグラムで見て一番明るい青が1/3くらいでした。

前回Sh2-240を同じセットアップで撮っていて、まだ機材はそのままの状態でほとんど残っています。なので、準備も時間で済み、仕事から帰って、夕食後から用意しても20時過ぎくらいには撮影を開始できました。撮影時間はちょうど月が昇る22時半ころまで。実際には西に傾き屋根に隠されて終了となりました。その後すぐに空が霞んできて曇りのようになったのでここで撤収です。

後でチェックしてみると39枚撮影して使えるのは36枚。3枚は屋根が入っていました。星像が流れているようなものはありません。後半になるに従って西の空に傾くので明るくなってきてしまうのですが、今回はそれらも全部使うことにしました。


WBPP 2.0

次の日フラットとフラットダークを同ISO800、1/400秒で128枚撮影し、ダークは以前撮った同じ範囲の温度をものを使用してWBPP(WeightedBatchPreprocessing)で処理。最近WBPPがメジャーアップデートされて2.0になり、かなり変更がありました。以前のバージョンから使っている人はまあ普通に使えるかもしれませんが、1箇所だけ注意。全てのファイルを登録後、新しくできたControl PanelタブのFLATのところでファイルを選択すると右側にオプションが現れます。これまではライトフレームはカラーかどうか選択するためにCFAオプションがあったのですが、今回からFLATもCFAが選べるので、もしフラットフレームもカラーで撮影したなら必ずCFAオプションにチェックを入れます。

今回のバージョンから処理過程を図にしてくれるのですが、FLATのCFAがオフのままだと下の写真のようになって、フラットが適用されていないのが分かります。

IMG_1943

きちんとFLATのCFAをオンにすると
IMG_1942
のように、きちんとフラットが適用されていることがわかります。

さて、その下のSeparate CFA scalling factorはまだよく理解していないのですが、とりあえず今まで通りオフでやってみました。ただ、オンにするとRGBで別々の係数を使い、オフだとまとめて一つの係数を使うということです。今回のフラットフレームはカラーバランスが取れていないので、もしかしたらオンにした方がいいのかもしれません。


あとは画像処理

出来上がったライトフレームをいつも通りDBE、PCC、ArcsinehStrech、HT、StarNetなどで処理をして、Photoshopに渡してさらに炙り出し。とりあえずできたのがこれです。

Image53_2

恒星がいまいち鋭くないとかいくつか不満はありますが、これはこれで完成です。さあ、ブログと書こうと今に至っているわけですが...

あれ?ダークがおかしい

...と(既に画像処理も終えて、このブログを書くために改めてダークファイルの数を)チェックしていて変なことに気づきました。WBPPのControl PanelにmasterDarkが多数枚登録されているのです。

IMG_1947

そしてDarksタブを見てみると露光時間ごとに一枚づつ、多数のmasterDarkが登録されているのが分かります。

IMG_1946

ところが、試しに今回撮影したフラットフレームとかライトフレームを登録してもこんな変な状況にはなりません。ダークフレームのみこのような状況になります。

ファイル名からdarkというのを取り除いたり、ヘッダ情報を見たりいろいろしたのですが、原因はもっと単純なことでした。ダークファイルが存在する上流のフォルダ名に一つでも「master」という文字が含まれているとこのような状況になってしまうようです。例えば今回は以前撮ったダークフレームを使い回したために「master」というフォルダの下に、さらに露光時間やISO別に幾つかのフォルダに分散してためてあったものを使ったために起きた問題でした。例えば「master」を「mas」とか抵当に名前を変更してダークフレームを登録するだけで、masterDarkでない普通のダークフレームとして登録されます。

さてさて、間違った多数の1枚偽masterDarkファイルで処理したものときちんとダークを登録して処理した画像と、で画像の差はあったか興味がある方もいるかと思います。拡大すると正しいダークを登録した方が明らかに黒い小さな点がなくなる、もしくは緩和されていました。差がわかる部分を拡大して比較ものが下の画像です。左が間違ったもの、右が正しいものです。このような小さな点が画像全面に散らばっています。

comp

ただ、最終仕上げに影響があるかというと、ドット単位くらいの話ですし、間違ったダークと言っても多少の補正はできているので、拡大してじっくり見ない限りはわからないレベルでしょう。

ちなみにこの「master」というフォルダ名、ダークだけでなく、バイアスやフラットを登録する際にも全く同じことが起きて、いずれもマスターファイルとして認識されてしまいます。これだとあまりにも制限が多いので、そのうちもう少し良い方法で解決されると思いますが、PixInsightを使う際にはmasterというのは特別な意味を持つので、むやみやたらに、少なくとも読み込む画像ファイルに関するところには使わないほうがいいでしょう。


仕上げ

このあとまた一通りの炙り出し過程をすませ、不満だった恒星部をもう少し出します。ついでに赤いところももう少しだけ。

master_cut_rot_DBE_DBE_PCC_SCNR_ASx4_HTx2_CT2
  • 撮影日: 2021年3月3日20時26分-22時29分
  • 撮影場所: 富山県富山市
  • 鏡筒:Takahashi FS-60CB + マルチフラットナー
  • フィルター: 無し SIGHTRON CBP
  • 赤道儀: Celestron CGEM II
  • カメラ:  Canon EOS 6D(HKIR改造, ISO800, RAW)
  • ガイド: f120mmガイド鏡 + ASI120MM mini、PHD2によるマルチスターガイドでディザリング
  • 撮影: BackYard EOS、露光時間180秒x36枚 = 1時間48分、ダーク50枚(ISO800、露光180秒)、フラット128枚(ISO800、露光1/400秒)、フラットダーク128枚(ISO800、露光1/400秒)  
  • 画像処理: PixInsight、StarNet++、Photoshop CC、DeNoise AI
Dark補正の違いはほぼ何も影響がないですが、2回炙り出しをやったのでいい訓練となりました。自宅でフィルターなし、2時間弱でこれくらい出るのなら、気楽でいいのかもしれません。

それでもやはり背景はノイジーなのは否めません。分子雲がもう少しあるはずなのですが、もっとはっきり出す技術をまだ確立できていません。今回2時間弱と短かったので、まだまだ撮影時間を伸ばしてみるのもいいのかもしれません。もしくはISOをもう少し上げて恒星がサチるのには目をつぶり、背景を重点的に出すことを考えてやってみるのもいいのかもしれません。

あ、そうだ真ん中らへんの一番明るい星の左のなぜか明るく見える星。ここだけボワッとにじみが出ています。そもそもこんなに明るい星でもないですし、もっと明るい星でもこんな滲みは出てません。ここのファイルはそれほど目立つにじみでもなく、いまだになぜか理由がわかりません。とりぜず理由がわかていないのでそのままにしています。

いつものAnotationです。

master_cut_rot_DBE_DBE_PCC_SCNR_ASx4_HTx2_CT2_Annotated


過去画像との比較

2年ちょっと前の2018年11月に撮影したカリフォルニア星雲です。

NGC1499_CUT

これは直接比較していいものなのでしょうか?記録を見ると撮影時間30分となっています。露光時間も約4倍、画像処理も今と全く違うので、淡いところも全然見えるようになっています。さすがに今回の方が圧倒的に進歩していますね。


まとめ

PixInsightのWBPPですが、まだメジャーアップデート直後でこなれ切れていない気がします。自分の慣れのこともありますし、また不具合などもあると思ってしばらく付き合っていくべきでしょう。

実際にはこれまであやふやだったフラットのCFA処理とかもはっきりしたり、コントロールパネルも見やすくていいです。これからもWBPPの進化に注目していきたいです。



カリフォルニア星雲(2): 撮り増し」に続く
 

CP+での星空中継のためのテストをしているのですが、なかなか難しい状況だというのがわかってきました。トークの時間が18時から18時半でまだそこそこ明るい時間帯です。中継を後半に持ってきたとしても18時20分くらいから、それでもまだ西の空に明るさが残ってます。こんな中でも、電視観望の魅力を伝えるためにはやはり星雲を見せたいです。


さて、どうしよう?

あらかじめ天体が導入されていればまだマシなのですが、そもそもトークの始まる18時前にアラインメントを済ませておくのは、さすがに明るすぎて無理です。それにトーク前にあまり焦りたくありません。

どうやれば確実に導入できるか色々考えてました。一番確実なのは、前日にきちんとした赤道儀、例えば手持ちのCGEM IIで極軸を完全に合わせておいて、アラインメントもきちんととっておいて、そのアラインメントを昼間も保っておくこと。でも前日が晴れる保証もないですし、やっぱりせっかくSIGHTRONのブースで話すので、やはりAZ-GTiでやりたいです。

次に考えたのが、カメラをASI294MCにして視野を広げて導入しやすくすること。でもこれもせっかくSIGHTRONブースで、しかも入門用と謳っているからには、やはりここはSV305-SJでどこまで見えるのかを見せたいです。

最後は、親子亀にして一つを広角ファインダーにしてあたりをつける方法。ですが、入門用で複雑に見えるのはやはりダメです。


いい方法を思いついた!

結局色々試してたどり着いた結論は、SharpCapのプレートソルブ機能を使うことでした。それをSyn Scan proと組み合わせます。SV305-SJの取得画像からプレートソルブして、それをAZ-GTiの経緯台モードに返します。

IMG_1849



これ結構すごいですよ。
なんたってケーブルがPCとカメラを繋ぐ1本だけの
超シンプルなシステムでのプレートソルブの実現です。


準備

あらかじめ、SharpCapとSynScan ProがノートPCにインストールされ、共に立ち上がっているとします。また、SynScan ProはWi-Fiを通してAZ-GTiに接続されているとします。

ポイントは

1. まずSharpCapからプレートソルブ(Astapが速くていいです)が動くようにきちんとインストールすること。PCは速いものを使ってください。StickPCクラスだと結構時間がかかります、が不可能ではないです。
IMG_1840
設定画面の一例です。下の方で、AstapがFoundとなっていれば大丈夫かと思います。 

2. ASCOM環境は必須です。ASCOMプラットフォームをカメラを接続したPCにインストールしておいてください。
3. SynScan用のASCOMドライバーをインストールしておくこと。
4. SharpCapの環境設定画面でMountとしてSynScanを選んでおくこと。
IMG_1842
ドライバーの選択です。SynScan App Driverを選んでください。

5. SharpCapの画面右側の「Scope Controls」のところで、「Connected」にチェックを入れること。
IMG_1843
きちんと接続されると、このようにどこを向いているかSharpCapが認識します。

これで準備完了です。


実行方法

  1. まずは通常通り鏡筒を北向きにして置いて、ノートPCで走っているSynScan proからAZ-GTiで初期アラインメントをします。どうせプレートソルブするのでワンスターアラインメントで十分でしょう。
  2. ここで視野にターゲットの天体が入っていなかったら、普通は方向ボタンをマニュアルで押して目的の天体を導入します。ここではそうせずに、SharpCapの「Tools」メニューからプレートソルブを実行します。ここでは「Plate Solve and Resync」を選びます。
  3. うまく位置を特定できると、その情報をSynScanの方に渡して、初期アラインメントで選んだ希望の天体を、ズレを補正して自動で導入してくれます。
  4. もし一度で導入されなければ、再度プレートソルブをします。大抵は2回で導入できるはずです。無事に導入されたら、あとはSynScanでアラインメント完了ボタンを押すと完了です。
IMG_1839
プレートソルブがうまくいくと、こんなメッセージが出ます。

この一連の流れが実現すると、AZ-GTiの設置が相当楽になります。AZ-GTiと鏡筒設置時に水平とかはある程度出しておいた方がいいですが、鏡筒の方向も大体北に向けておけばいいです。もし水平出しをさぼった場合でも、プレートソルブで導入した天体が少しずれ、視野ないに一発で入ってこないだけです。かなり近くまではきてるので、もう一度プレートソルブすればまず入ってくるでしょう。

どうです?結構すごいと思いませんか?しかもAZGTiが電池駆動で、PCがノートとかのバッテリ持ちなら、必要なケーブルはホントのホントにPCとカメラを繋ぐケーブル一本です。


実際に明るいうちからテストしてみた

さて、これらのことをこの時期の18時にやった時にどうなるか?

18時ぴったりだとまだ明るすぎて少し厳しかったですが、18時15分だと問題なくできました。この際、露光時間は5秒程度までにした方が良かったです。そもそもAZ-GTiの追尾の精度が出ていないので、10秒とかにするともう長すぎで星が流れてしまい、プレートソルブで恒星を認識することができませんでした。

CP+本番は今から約1週間後です。太陽が沈む時間がだいたい5分くらい遅くなるので、18時20分ならなんとか見せることができるでしょう。実際に今日の18時15分だと、オリオン大星雲M42なら、十分に見ることができました。

でもまあプログラムが多少遅れることを期待して、もう少し暗くなってから見てもらった方がいいのかもしれません。いずれにせよ、全ては晴れてくれたらのことで、北陸の冬なので厳しいかもしれません。今のところの天気予報、日曜夕方は「曇りのち晴れ」みたいです。


CP+のトークをお楽しみに

今回のアイデアどうだったでしょうか?これ相当シンプルで、ソフトの設定の簡単さはASI AIRには負けると思いますが、ケーブルの数の少なさだけ言ったらASI AIRに負けないと思います。

今回のテストはCP+の星空中継のためなのですが、CP+本番ではこんな凝った話はできないので、ブログに書いておくことにしました。でも晴れていれば実際の過程は(偶然一発でターゲット天体が視野に入らない限り)見ることができるかと思います。

それではCP+でのトーク楽しみにしていてください。


 

星雲がその場で見える!
電視観望にチャレンジしてみよう

日時: 2月28日(日)18時から18時30分

by Sam @ ほしぞloveログ 

 


PixInsightのPCCが動かない!

先週撮影したM78の画像処理を進めているのですが、何日か前からPixInsightのPhotometricColorCalibration (PCC)が使えなくなるという現象が起きていました。Plate solveを使った位置決めまではうまくいくのに、色合わせのところで3回エラーが起こって止まるという問題です。エラーは

PCC

のようなものです。エラーを吐き出すhttps以下のところをブラウザにコピペして呼び出すと

No catalogue or table was specified or found.

というエラーが出ます。通常はフランスのサーバーがデフォルトなのですが、他のいくつかあるサーバーを全部試しても同じ状況でした。また、PIのMac版、Windows版で試しても同じでした。


しびれをきらしてTwitterにヘルプを

しばらくしたら直るかと思って放って置いたのですが、何日か経ってもダメ。ここでTwitterに同じ症状がいないか投げてみると、次々と同じ症状の人が。PCC事故調査委員会の再招集です。



するとすかさずnabeさんが、Gaiaデータをローカルに落とす方法があると示唆してくれました。

少し調べてみると、ここにやり方が載っていました。



そうこうする間にも、誰すのちさんから世界中で同じ状況が起こっているという情報が。




その後も、うまくいったとか、やっぱりガセだったとか、DR3だったらいいかもとか、情報が乱れ飛びます。とりあえず私もDR3で試そうとしていたので、ダウンロード完了後試してみますが、やはりダメ。そもそもローカルに落としたファイルを使えているかどうかの確証がありませんでした。

その後、まず適当なファイルをデータベースとして選択してやると、位置合わせからエラーで全く動かないことが確認できたので、少なくとも位置合わせが動くときはローカルのデータベースは使っていたことが判明。ということは、GaiaファイルはローカルなものもDR2でもDR3でもダメなことが分かりました。

ここで一旦進展が止まって悩みます。

しばらくPCCの設定画面を見ていたら、どうも位置合わせはGaiaとか使っているのですが、色合わせはAPASSというのを使っているのではと思い始めました。

結論だけ言うとこれがビンゴでした。

ラッキーなことに、APASSもDR2、DR3とアップロードされています。あとはどうローカルで使うか。手順を書いておきます。


解決法

まずはここからAPASS DR9かDR10をダウンロードしてどこかに置いておきます。ダウンロードにはユーザーアカウントとパスワードが必要になります。



その後、PixInsightに移り以下の手順でローカルに落としたAPAPPを使うようにします。
  1. Process Explorerの画面を左のタブのところにカーソルを持っていって出します。タブがない場合は「View」メニューの「Explore Windows」から「Process Explorer」を押してください。
  2. かなり下の方の「Start Catalogs」の中の「APASS」をダブルクリック。
  3. 出てきた画面の右下のスパナマーク (Preferences) を押します。
  4. 「Data release」でDR9かDR10かを選びます。先にダウンロードしたファイルに合わせてください。
  5. 「Select」を押し、ダウンロードしたファイルを選択します。
  6. 「ok」を押せば準備完了。
  7. PCCの設定画面に移り、「Photometry Parameters」の「Automatic catalog」のチェックを外し、APASSDR9_XPSDかAPASSDR10_XPSDをダウンロードしたファイルに合わせて選択します。
  8. あとは普通にPCCを走らせてください。エラーが出ることなく、最後までいき、グラフが表示されると思います。


Twitterすごい

Twitterに投稿してわずか1時間くらいで解決でした。確かに最後のAPASSまでたどり着いたのは私でマッチポンプ状態(笑)ですが、nabeさんのローカルでGaiaデータが使えると言う助言がなければ、自分だけでやっていた限り絶対こんな短時間では解決策まで辿り着けなかったと思います。誰すのちさんのフォーラムの情報にも助けられました。

nabeさん、誰すのちさん、Cooさん、だいこもんさん、あんとんシュガーさん、智さん

コメント、助言、テストなどありがとうございました。みなさん事故調査委員会のメンバーですね。私も前回のPCCの色違いの時は委員に入れなかったので、今回は委員の一員になれたのかと思うと光栄です。


(追記: 2021/1/29 復帰したみたいです。サーバー上のAPASSでうまくPCC最後まで行きます。PIをアップデートしたわけではないので、Vizierの方で対応したのかと思います。)

このページのトップヘ