ほしぞloveログ

天体観測始めました。

カテゴリ: software

さて今回M33を撮影したので、Pixinsightのバッチ処理に挑戦しました。ちょっとややこしいですが、多少癖がわかったのか、前回ほど戸惑うことはないです。

バッチ処理は「Script」メニューの「Batch Processing」->「BatchPreprocessing」を選ぶことから始まります。下のAddボタンを押してLightフレーム、Darkフレーム、Flatフレームなどを登録していきます。ここら辺まではいいのですが、最初はやはりなかなかうまくいきません。迷ったところをこれまた全部書いておきます。
  • Debeyerできない -> 右側のCFAimagesにチェックを入れるとできるようになる。
  • Cosmetic CorrectionのTemplate iconが選べない。-> これは特に分かりづらかったです。BatchPreprocessingに入る前に、あらかじめ「Preprocessing」の中から「CosmeticCorrection」を選び作っておく必要があります。前回の記事で説明したように、ファイルを選んで実行までしてから、(2018/3/22変更)CosmeticCorrectionでホットピクセル除去やクールピクセル除去のやり方を指定するだけでよく、ファイルまで選ぶ必要はありません。その後、CosmeticCorrection画面の左下の三角をクリック枠の外に出すと「Instance」が作成されます。これをBatchPreprocessingで指定するみたいです。「CosmeticCorrection」できたファイルを消したりしてしまうと、たとえインスタンスだけ残っていてそれを指定しても、エラーが出ます。
  • 「CosmeticCorrection」で一部の枚数だけ使って処理したインスタンスを使って、多数枚のLightフレームは処理できるのか? -> 問題なくできるみたい。でも、これで本当に全部のファイルのhot/coolピクセルが処理されているかは未検証です。念のため全Lightフレームを使って処理するようにしました。(2018/3/22変更)そもそもCosmeticCorrectionでホットピクセル除去やクールピクセル除去のやり方を指定するだけでよく、ファイルまで選ぶ必要はありません。
  • 一旦バッチファイルの画面を閉じてしまうと、選択したファイルも全てリセットされる。インスタンスを残しておいても、スクリプトファイルのソースみたいなのが出てくるだけで、元の画面が出てこない。 -> 仕様みたいです。何か回避策はあるのでしょうか?(2018/3/22追加)-> 左下の三角を枠外にドラッグ&ドロップしてインスタンスを作って置けば後から再度開くことができることがわかりました。ただ、開く時にインスタンスを右クリックして「Execute in the global context」を選ぶと物と画面に戻ることができて編集を再開できます。
  • ImageRegistrationのDrizzleの意味がわからない。 -> とにかくチェックしないとファイルが出力されない。最終画像も出ない。 (2018/3/22追加)->普通のDrizzleの意味で、解像度を上げるのですが、そのためのデータを出力するだけで、実際に出力ファイルの解像度が上がるわけではないみたいです。なので、チェックは外してもいいとのことですが、チェックしないとファイルが出力されないこともあったので、とりあえずチェックしてあります。
  • 星像が流れていないかなど、撮影後のfitsファイルの確認がしにくい。-> Canonカメラでの撮影の場合JPEGも残しているのと、RAWファイルのCR2形式はWindowsでもMacでも簡単にプレビューできるので便利。その一方、fits形式のプレビュー的なアプリはなかなかなく、今の所Pixinsightで全て開くしかない。 (2018/3/22追加) -> メニューの「Batch Processing」「SubframeSelector」というバッチ処理で星像の肥大度と偏心度などをみて自動判別するとても便利な機能があります。そのうちに解説します。
  • Lightフレームだけではダメみたいで、少なくともDarkかFlatかBiasが一枚はないとダメみたいです。
  • 右側の「Registration Reference Image」は必ず一枚Lightフレームを選ばなくてはならない。
  • Output Directoryも選ばないと怒られる。
  • Biasフレームは必要? ->  (2018/3/22変更) 冷却CCDとかでは必要みたいです。常温のCMOSカメラは?PixinsightではBiasは必ず取った方がいいみたいです。明らかに処理に差が出るようです。今回はとりあえず、よくわからないので撮ってません。調べてみるとBiasフレームとは、レンズにキャップをした状態にし、ライトフレームと同じISO感度かつ「最短シャッタースピード」で撮ったもののようです。簡単そうなので、次回撮影では撮ってみます。
  • Flatフレームもダークで補正されたほうがいいはずなのですが、実際に補正はされるのでしょうか?できたファイルからだけではよくわかりません。→ biasはFlatにもダークにも適用されます。FlatdarkはPixInsightでは必要ないそうです。
  • 実行前に「Diagnostics」ボタンを押すと、問題があるかどうかわかる。準備ができたら「Run」ボタン。
これで待っているとコンポジットされた画像が無事にできます。これ以降のバックグラウンドの処理などのLinear Stageの解説は次回に続きます。

今回も疲れてしまったので、ここからはいつも通りSteller Image8やPhotoShopなどで処理しています。

さて今回の処理はM33ですが、機材はFS-60QにASI294MCをつけて、Advanced VXをASI178MCと50mmのCマウントレンズを使い、PHD2でガイドしたものです。撮影はSharpCapで行いました。ASI294MCのゲイン270、各露光時間は5分間で合計25枚、計2時間5分になります。

そこそこの長時間露光になっているのですが、これを処理すると「縞ノイズ」が盛大に出てしまうことがわかりました。

light-BINNING_1


上の画像は、Pixinsightでバッチ処理でコンポジットした画像をSteller Image8に送り、「オートストレッチ」でホワイトバランスを整えてから、「チャンネルパレット」の「σ(1,3)」を押しただけの画像です。画像をクリックすると縦方向に少し斜めの線がたくさん見えると思います。実はこれまでも長時間撮影で何度か遭遇してボツにしてきた経緯があるのですが、そろそろ向き合わなければならない時期にきたみたいです。

この縞ノイズというのは、長時間露光の際に一般的に出てくる問題で、ガイドをしていても機材のたわみなどで少しづつ星像がずれていってしまうために起こるものです。実際、比較明合成で見てみると、縞ノイズの方向とずれの方向が一致しているのがわかると思います。

integration_maxtraced


ちなみに、Pixinsightで比較明合成をするには、原理的にはバッチ処理の中の「Image Registration」の過程を抜いてIntegrationすれはいいので、今回はバッチ処理でできたoutputファイルがあるディレクトリの中のcalibrated/light/debayeredの中のファイルを全て「Process」メニューの「Preprocessing」の「Image Integrartion」でコンポジットします。そうすると、上に示したような比較明合成画像が出来上がります。

さて、この縞ノイズをなくすには機材のたわみなどを極限までなくし、ガイドの精度を上げることなのですが、今回のズレも画像から計算すると2時間でわずか約40秒と決して悪いわけではありません。精度を上げる方向で攻めるのは普通は難しいので、ディザリングなどで撮影時にわざと規則的に画角を繰り返しずらしていくことで、縞ノイズの影響を少なくするような方法をとることができるようです。ここで一つ問題が出ます。今回の撮影でも使ったSharpCapだとディザリングは難しいみたいなのです。撮影の合間にずらして揺れが落ち着くまで少し待つということを繰り返すのですが、SharpCapの撮影は基本的に連続で、ずらしている間に露光を止めることができないようなのです。手持ちのEOSを使う場合はBackYard EOSとPHD2の組み合わせでディザリングももんだいなくできるようですが、CMOSカメラだとAPT(Astro Photography Tool ) などを使う必要があるみたいで、お気に入りのSharpCapが使えません。

ディザリングはおいおい考えるとして、Pixinsightで比較明合成の仕方を探る時に色々試していて面白いことに気づきました。Image Integrationのオプションの違いで明らかに縞ノイズの出方が違うのです。関係するオプションは2つで、「Combinarion」と「Normalization」です。全部のオプションを試したわけではないですが、Combinationでは「Average」と「Maximum」で明らかな違いがありました。またNormalizationではデフォルトの「Aditive with scaling」と「No normalization」でもCombinationと合わせると明らかな違いがありました。結果を画像で示しておきます。

まず、2つ上の画像と同じものですが、デフォルト設定でCombinationは「Average」、Normalizationは「Additive with scaling」となります。

light-BINNING_1
「Average」、「Additive with scaling」

次に、Combinationを「Maximum」に変えます。画像処理は上と同じでSteller Image8のオートストレッチとチャンネルパレットのσ(1,3)のみです。

integration_Maximum_Additive_with_scaling
Maximum」、「Additive with scaling」

明らかに縞ノイズが減っているのですが、少しわかりにくいかもしれません。

次にデフォルトの設定からNormalizationを「No normalization」にします。Combinationは「Average」のままです。に変えます。

integration_Average_No_normalization
「Average」、「No normalization

これは一見ほとんど同じに見えるかもしれません。

最後に両方ともデフォルトから変えて、Combinationを「Maximum」に、Normalizationを「No normalization」にします。

integration_Maximum_No_normalization
「Maximum」、「No normalization」

それでも縦縞はまだ残っていますが、こちらはパッと見ただけでわかるくらい縦縞が減っています。

比較した画面です。

comp

こうやってみると、元の画像に細かいノイズがのっかただけのように見えないこともないです。それでもその後の処理では大きく違うこともわかりました。実際に「Average」、「Additive with scaling」とMaximum」、「No normalization」を比較する意味で、真面目に画像処理してみました。画像をクリックして拡大してみると結果は一目瞭然です。(追記: 次の日見たら後者の方がぼかしてあり比較するのにあまり適していなかったので、処理を同じようなものに合わせました。)

light-BINNING_1_SI3
「Average」、「Aditive with scaling」


integration_Maximum_No_normalization3c

「Maximum」、「No normalization」

処理をしていても、デフォルト設定の「Average」、「Additive with scaling」方は縞を消さなくてはいけないと思い、かなり不自然な処理になってしまっています。それでもまだ全然消しきれていません。一方、Maximum」、「No normalization」の方は処理中も縞をほとんど気にすることなく、画像処理に集中できます。もちろん完全に縞ノイズが消えているわけではないです。また、他のパラメーターでさらに改善する可能性もあるかもしれません。


Pixinsightはまだ使い始めたばかりで右も左も分からないので、今回の試みがごくごく一般的なテクニックなのか、それともあまり知られていないものなのかもよくわかりません。洋書の「Inside PixInsight」は買ってあるので、該当する箇所を読んでみたのですが、大したことは何も書いていなくて、Combinationに関しては「Averageを使え」だけです。Nomalizatioinに関しては、ある章では「バイアスを履かすのを保つためにNo normalizatoinを選べ」とかいてあって、別の章では「Additiveは少なくとも使え、Scalingは露光時間が違う場合は使ったほうがいい」とあるくらいで、ほとんど中身の説明はありません。ヘルプのドキュメントをよく読めとも書いてあったので読んでみました。ヘルプの方が確かに少しマシですがそれでも「Averageは一番いいS/Nになる」くらいと、「NormarizationはバックグランドをScalingはばらつき具合を合わせる」というくらいのことしか書いてありません。「ScalingはS/Nを良くする」とも書いてあるので、もしかしたらS/Nを良くするというところの処理が悪さをして、縞ノイズが出る出ないに関わっているのかもしれません。何れにせよアルゴリズムは不明なので、どのような処理をやっているかがわかるようなレベルではないです。

それにしてもPixInsight奥が深すぎます。かなりブラックボックスです。まだしし座のトリプレットの未処理画像が残っているので、引き続きもう少し触ってみます。








ASI294MCでのバーナードループの固定撮影の続きです。

さて、5秒、100枚のスタックですが、三脚にASI294MCを取り付けるだけのお手軽固定撮影のために、時間とともに画面の中で星が動いていきます。歪みが全くないレンズならば問題ないのでしょうが、そんなレンズは存在しません。なのでそのままスタックすると中心と端の方で、どうしても位置にズレが出てきてしまいます。Steller Imageは基本的に並進と回転のみで位置合わせをしているので、このような画面にひずみのようなズレがある画像をうまくスタックすることは苦手なようです。PixInsightはこんなひずみもうまくコンポジットしてくれるとのことなので、今回初めてPixinsightを使ってみました。とりあえずは無料の45日制限のお試し版です。無料といってもフル機能使えるので、試して気に入ったら購入するつもりです。

処理するものはSharpCapでASI294MCを使って5秒露光での撮影で得られた100枚のファイルです。撮影中にダーク補正もフラット補正もしてしまっています。RAW16モードでfits形式で保存したものです。


まず思ったことは、PixInsigtはものすごくとっつきにくいです。ある程度噂では聞いていましたが、これほどとは。とにかくメニューが多すぎて何がどこにあるかわからない。どれがどの機能を指しているのかよくわからないといった状況です。とりあえず迷ったところ全部書いておきます。この方法が正しいかどうかもまだよくわかっていません。かろうじてコンポジットまでできた経緯です。同じように迷えるどなたかの役に立てばという思いです。

  1. まず、ファイルをどうやって開けばいいのかわかりません。「File」メニューから「Open」は意味がありません。「Process」メニューの「Preprocessing」の中のメニューを選択して開くことが大事です。ここまでわかるのに一苦労でした。Preprocessingという言葉はSteller Imageで言うコンポジットまでの一連の処理のことを指すみたいです。
  2. その「Preprocessing」の中からまずは「CosmeticCorrection」を選びます。ホット、クールピクセルの除去などができるようです。「Add Files」ボタンを押して、今回撮影した複数の「.fits」を全て選択して開きます。次に「Output」から保存したいフォルダを指定します。フォルダを指定しないと同じフォルダにファイルが追加されていきます。「Use Auto Detect」にチェックして、「Hot Sigma」も「Cool Sigma」もチェックします。下の左の黒丸を押して実行します。問題があればここでエラーダイアログが出ますが、特に問題がなかければテキストベースのコンソール画面のようなものが出てきて、処理が進んでいくのが見えます。
  3. これまたわかりにくいのですが、それぞれの処理画面の左下の三角をクリックして、クリックしたまま枠の外に出すと「Instance」というものが作成されて、アイコンができます。このアイコンは作業のリンク(ショートカット)のようなものと理解しています。画面を消してしまっても、このアイコンをダブルクリックするとまた同じ画面が出てきます。
  4. 次に再び「Process」メニューの「Preprocessing」にいき、今度は「Debayer」を選びます。白黒の画像をカラー化します。先ほど処理してできた「_cc.xisf」という拡張子がついたファイルを「Add Files」ボタンを押して全て開きます。ここで左下の黒丸ボタンを押してエラーが出て悩みました。この解決方法は一番上の「Bayer/mosaic pattern」を「Auto」から「RGGB」に変更します。どのパターンにするかは事前に調べておいたほうがいいです。SharpCapの方でDebayer方式をかえて、変な色にならないものを見つけました。これで黒丸が押せるようになり実行できます。まだ、黒丸と黒四角の違いはよくわかりません。もし確認したければ、ここでできた「_cc_d.xisf」ファイルを「File」のメニューの「Open」から選んでみると見事カラーになっているのがわかります。ここでも左下の三角を押してInstaceを作っておくといいでしょう。
  5. 再び「Process」メニューの「Preprocessing」にいき、「StarAlignment」を選びます。位置を揃えてコンポジットするための事前計算です。この事前計算は「ImageCalibration」でもできるみたいですが、それぞれの画像で歪んでいるような場合はこちらの「StarAlignment」がいいみたいです。(2018/3/22追記: ImageCalibrationはダーク補正やフラット補正をするプロセスです。本来Debayerの前にする処理です。今回は撮影時にダーク補正もフラット補正もしているので、簡単のため割愛します。)ここも普通に「Add Files」からすぐ上で作ったカラー画像「_cc_d.xisf」ファイルを全て選びます。一つだけ違うのは、さらに基準となるファイルを一番上の「Reference Image」で選ばなければならないことです。「Add Files」で選んだうちの一枚を選びます。すぐ横の「VIew」を押して、「File」を選んで、さらに右の三角を押せば選択できます。色々オプションが選べるみたいですが、よくわからないのでまずはそのままの設定でやってみました。あとは左下の黒丸を押して実行します。
  6. 最後は「Process」メニューの「Preprocessing」の「ImageIntegrartion」でコンポジットです。同じく「Add Files」で最後にできた「_cc_d_r.xisf」ファイルを開きます。ここも色々オプションがありますが、全てデフォルトです。まだ細かいことはよくわかりません。黒丸を押して待つとやっとコンポジットされた画像が出来上がります。画像が2枚出てきて、一枚はコンポジットしたもの、もう一枚は暗い除かれたものみたいです。コンポジットされたものを「File」メニューの「Save As」で適当なファイル形式を選び保存します。同じfits形式でも色々互換性とかの問題があるみたいなので、とりあえずPixinsight標準のxisf形式で保存して、あとは色々な形式で試して目的のソフトで開くことができるか確認するといいかもしれません。Steller Imageでも開くことができるものは限られていました。
  7. ここからPixinsight語で言う「Linear Process」(Steller Imageで言うカブリ補正やレベル補正) に入っていきます。この際Screen Transfer Function (STF)というのを使ってレベル補正に相当することをしていくようなのですが、最初レベルを変えるSTFバーの出る画面がどうしても見つかりませんでした。中途半端に「Image」メニューの「Screen Transfer Function」に色々あるのがわかりにく原因で、バーを出したい場合には「Process」メニューの「IntensityTransformations」のところにある「Screen Transfer Function」を選ばなければいけません。メニューとオプション多すぎです。ここらへんで力尽きました。
ところで、以上の行程はバッチ処理での自動生成もできるみたいですが、今回はダークとかフラットが別のファイルになっていないので、理解する意味も含めて一つ一つ手でやってみました。バッチ処理はかなり便利とのことなので、次にまた試してみようと思います。


さて、比較のためにSteller Image8でも同様にコンポジットしてみました。まずSteller Image バージョン8の売りの「自動処理モード」だと、SharpCapで保存されたfitsファイル(RAW16)が白黒のままコンポジットされてしまい、コンポジットされた画像もカラー化することができませんでした。結局いつものように「詳細編集モード」で100枚を開いて、一枚一枚「ベイヤー・RGB変換」するしかありませんでした。「Altキー+I、Altキー+Y、Enter」で多少早くできますが、それでも100枚を一枚づつ手動で変換しなくてはならないことには変わりありません。この手間だけは冴えないですが、あとはバッチ処理でほぼ自動でできます。

できた画像を比較してみます。まず興味のある中央と四隅を拡大してみます。

cut
Steller Image8(左)                                 Pixinsight (右)


左がSterller Image8、右がPixinsightです。中央はそれほど変わりませんが、四隅を比べるとやはりSteller Image8だと流れたりぼけたりしてしまっています。Pixinsightも少し流れているように見えますが、これはレンズのせいで、一枚一枚の個々の画像ですでに流れてしまっています。f1.4のレンズを一段絞ってf2.0で撮影したのですが、ピクセル等倍で見るとまだ流れが目立つので、もう一段絞ったほうがよさそうです。

つぎに、全体の比較も面白いので見てみます。上がSteller Image8、下がPixInsightです。

Capture 23_35_59_00001-00101_23_36_01

integration

驚異的なのが、Steller Imageの方は、固定撮影のために空が流れていってしまい撮影できていない枚数が少ないところは普通に暗くなっているのに対し、PixInsightの方は撮影できていない部分も枚数で重み付けして明るさを復元していることです。

やはり噂通りPixInsightのコンポジットはかなり強力なようです。


 今回初めてPixinsihgtを使ってみました。確かに高機能で、性能もいいです。でもなぜ日本でSteller Imageがメジャーなのか?やっとわかりました。Steller Imageの方がはるかに簡単だからです。慣れの問題もあるでしょうし、Steller Imageは?なところも多少ありますが、日本語ですし、操作は想像がつきますし、ある程度一本道だし、マニュアルなどもしっかりしています。簡単にできるということは思っていた以上にありがたいことだと実感しました。


今回もコンポジットまではPixinsihgtでやりましたが、それ以降のカブリや周辺減処理、デジタル現像に相当するものはPixinsightでもできるはずですが、まだ手が出ません。PixInsightは疲れたのでしばらくはここからはいつも通りSteller Image8で続けることにします。

integration4

富山県富山市, 2018年1月13日23時36分
NIKKOR NC 35mm f1.4 + ASI294MC 固定撮影
露出5秒x100枚 総露出8分20秒
PixInsight + Steller Image 8、Photoshop CCで画像処理


最後の仕上げにSteller Image8とPhotoshopCCで続きの処理をした画像が上になります。さすがに5秒露光の100枚だとトータル10分もないので厳しいです。画像処理でかなりごまかしています。それでも馬頭星雲あたりは見えていますし、目的のバーナードループも見えています。他にもバラ星雲もなんとか見えますし、うっすらとですがエンゼルフィッシュも少しは出ているみたいです。

自宅の庭で、赤道儀も使わない、ポンと適当に置いた三脚に固定での、わずか10分のお気楽極楽撮影
なら、まあ十分ではないでしょうか。この方法だと部屋の窓際に適当に置くだけでいいので、かなり楽かもしれません。

今の制限は、一回の露光で星が流れないという5秒からきているので、ちょっとめんどくさくなりますが、ポタ赤でも使ってもう少し長い露光時間でやってみるのも面白いと思いました。



先日の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の進化が本当に楽しみです。


木星撮影の仕上げです。WinJUPOSに挑戦してみました。ちょっと癖のあるソフトなのですが、効果は絶大です。結果をまず載せます。

2017-06-04-1242_6-RGB_j_p_fine

富山県富山市下大久保 2017/6/4 21:36:31
C8 + Explore Scientific x5 barlow lense + ZWO ASI224MC + Advanced VX 
F50, Shutter 10.00-20ms, 79-49fps, gain 409-460, 20000/40000 frames


WinJUPOSでのDe-rotationのおかげで前回より明らかに解像度が増しています。処理したファイルは前回処理したときの記事と同じ6月4日に撮影したもので、その日は計5つの動画ファイルを撮影して、そのうちの4つが5倍バロー、一つが3倍バローです。前回の記事では3倍バローの800x600pixelものをdrizzleで3倍の解像度にしましたが、今回は5倍バローの1024x768pixelのものをちょと無理をしてdrizzleで3倍の解像度にしてから処理しています。さすがに1024x768のdrizzle3倍はスタック時に結構時間を食いましたが、それでも一つ20分くらいでしょうか。

4つのファイルの内訳は
  1. 10ms, 79fps, gain460, 10000frame
  2. 20ms, 49fps, gain409, 10000frame
  3. 20ms, 49fps, gain409, 10000frame
  4. 20ms, 49fps, gain410, 10000frame
となります。それぞれAutostakkert3でスタックし、RegistaxでWavelet変換をします。画像が大きすぎて、全部の画面を一度に処理しようとすると時間がかかりすぎるので、一部のエリアに処理を制限して、最後に「Do All」全画面を処理します。一部しか画面が見えないので、Waveletのパラメーターは相当慣れてからでないとうまくいかないと思います。小さい画像でかなり練習してから、大きな画像に挑戦したほうがいいでしょう。今回のパラメータは

capture


の様にしました。drizzleで3倍の解像度にしているので、空間周波数で5段階目くらいまで有効に使えています。数字の小さい、周波数の高いところほど大きく強調して、かつDenoiseでノイズを除去しているのがわかると思います。前にも書きましたが、Previewを押してどのくらいの解像度に効いているか見ながら、どの周波数を強調したいかを意識していじるといいと思います。

パラメータはセーブできるので、拡張子.rwvで保存すると同じパラメータで何度も処理を繰り返すことができます。最初拡張子がわからず、セーブしたファイルが読めなかったのですが、拡張子をきちんと指定することでロード時に読み込むことができるようになりました。4つのスタック画像を全てRegistaxで処理して、WinJUPOSに移ります。

WinJUPOSはちょっと癖のあるソフトです。今回使ったバージョンは10.3.5です。
  1. 起動時にJupitarを選んでから、まずファイルを「Recording」メニューの「Image measurement」を押して、でて来た画面の「Open Image」で開きます。
  2. 画像が表示されたら「Adj.」タブを押して「Zoom」で木星全体が表示されるように調整します。
  3. 木星画像のところで右クリックをして、「Automatic detection of outline frame」を押します。
  4. すると白いサークルが画像の木星にフィットするかと思います。Nの位置が上下逆だとうまくフィットできないことがあるので、その場合は「N」キーと「P」キーでNの位置を下にしたりします。その際コントロールキーを押すと大きく動きます。サークルの位置はカーソルで移動できますが、基本的に使うことはないでしょう。こちらもコントロールキーで大きく動きます。
  5. 回転方向も含めてうまくフィットできたら「Imag.」タブを押して「Save」で.imsファイルとして保存します。
  6. これを全ての(今回は4枚)の画像について同じことをします。
  7. 次に「Tools」タブの「De-rotation of images」を選び、右上の「Edit」ボタンを押し「Add」で先ほど作った.imsファイルを順次加えていきます。
  8. その後「Compile image」を押してしばらく待つと木星の自転を補正してスタックした画像が出来上がります。

その後、Photoshopなどで調節し完成です。

WinJUPOSの効果は結構強力で、長い露出時間の画像をスタックしたことに相当するので、よりノイズが少なくなり、解像度も増したというわけです。







 

6月4日、家族で外でバーベキューをした後、とても天気が良かったのと、月が明るいので星雲は諦め、先週に引き続き再度C8とASI224MCで木星撮影に挑戦しました。最初に結果を載せます。

2017-06-04-1252_7-RGB-Jup_lapl4_ap28_Drizzle30_w_p_cut


富山県富山市下大久保 2017/6/4 21:53:20
C8 + Explore Scientific x3 barlow lense + ZWO ASI224MC + Advanced VX 
F30, Shutter 10.00ms, 99fps, gain 401/600, 2500/5000 frames

何本か撮影したものの一本を処理したものですが、前回のものよりかなり良くなっているのがわかると思います。


撮影に関して前回と違う点は
  • ずっと前に胎内星まつりで買ったZWO社製のIRカットフィルターを入れた。
  • FireCaptureの「Control」タブの「More」を開けてRedとBlueのを調整してホワイトバランスを取った。また、Brightnessが240だったので100にした。(どうもSharpCapの設定が残っていたみたいです。)
  • 前回間違えてAVI形式にしたのをSER形式にした。(ビット指定はないのだろうか?)
  • Gamma補正をオフにした。
  • 5倍のバローで1024x768に加えて、3倍のバローで800x600でも撮ってみた。
  • 800x600の動画を、Drizzleの3.0Xにして解像度を増やした。(Registaxでより細かく空間周波数を扱えるので、1024x768でDrizzle無しよりいい結果だった。1024x768でDrizzleの3.0Xはかなり重いので次回の課題。)
  • なにより、シーイングが前回よりもかなりいいと思われる。

その時の動画がこれです。前回の動画よりもはるかにましになっています。南天に近い位置で撮影したため結局ADCは使っていません。



その後画像処理をしたものが上の最初の写真になります。

ここで一つ疑問が湧きました。画像にした時の木星の向きがよくわかりません。実際には木星の縞が水平になるようにカメラの向きを変えて撮影していますが、画像処理の段階で180度回転させました。これは他の方の木星の画像を参考にしたのですが、なぜこの向きがいいのかがまだ理解できていません。確か木星の北極が上とかなんとかという記事を以前どこかで見たことがある気がしますが、多分そのような理由なのでしょう。あとで調べてみます。


さて、次の課題ですが、
  • WinJUPOSでDe-rotationを試す。(後日、De-rotationまで試しました。)
  • 是非とも大赤斑の見える時間をねらって撮ってみたい。
  • 5倍バローの1024x768撮影でDrizzleの3.0Xを試す。
  • L画像のためにASI290MMを買うか?
といったところでしょうか。 ASI224MCの限界に達していそうならばできればASI290MMを試してみたいですが、予算を出せるかが悩みどころです。

 

先日撮影した木星の画像処理をしてみました。まずは結果の写真です。惑星撮影は久しぶりでいろいろ戸惑うところもあり、まだまだ全然解像度が足りませんが、それでも(下のビデオを見てもらうとわかると思いますが)よくこのシーイングの悪さでここまで出たなというのが正直な感想です。スタックとWavelet変換恐るべしです。ちなみに去年EOSX7で拡大撮影で頑張って撮影したのがこちら。これ以降木星を撮る機会がなかったのですが、一年たってさすがにかなり進歩しました。


Jup_221451_lapl6_ap60_w_p_s

富山県富山市下大久保 2017/5/29 22:13:48
C8 + Explore Scientific 5x forcal extender + ZWO ASI224MC + Advanced VX
F50, Shutter 25.00ms, 40fps, gain 450/600, 2500/5000 frames



まず、撮影した動画で、一番ましだったものを載せておきます。アップロードしたファイルは圧縮してあり、2分撮ったうちの最初の5秒分ですので、そのままのクオリティーではないですが、ぱっと見の見栄えは元のファイルとほぼ同じ印象です。これくらいシーイングが悪かったということです。


FPSは20から80まで、Gainは350から500くらいまで、計8種類くらいの動画ファイルを撮影して試したのですが、結局使ったのはShutter25ms、Gain450、40FPSでトータル5000フレームのファイルでした。これはFPSが高すぎると画面が揺れすぎるのと、同じコマ数だとトータルの撮影時間が短くなること、ゲインが低くて暗いよりも多少ノイズが入ってもゲインを上げて明るくしたほうがいいという傾向が見られたからです。画面サイズは1024x768ですが、これはC8のF10(f2000mm)に5倍のバローなのでF50になってしまい、結局このサイズになってしまいました。気にしていなかったのですが、履歴を見るとGammaが20入ってしまっていたみたいです。これはオフにしてもいいみたいです。あと、IRカットフィルターが入っていないため赤が出すぎてしまっています。


画像処理に関しても昨年記事にはしていなくて、結構いろいろ思い出しながら進めたの、メモがわりに書いておこうと思います。


Autostakkert3

動画をスタックするのに使います。64bit版のベータ版の3.0.14を使いました。基本的にはほとんどデフォルトでしか使っていません。
  1. 「1)  Open」で動画ファイルを開きます。FireCaptureで録画したファイルならそのまま開けるはずです。
  2. 「Planet」を選択、「Dynamic Background」はチェック、「Lappace」はチェック、「Noise Robust」はシンチレーションが悪かったので4から6にしました。 これで「2) Analysis」を押します。
  3. 「Double Stack Reference」はチェックしませんでしたが、時間を気にしないならチェックしたほうがいいかもしれません。「Auto size」はチェック、「TIFF」を選んで、「Frame percentage to stack」に50といれいい方から50%をスタック。これは悪いのは思い切って切ったほうがいい結果が得られるということからこれくらいにしました。「Normarized Stack」と「Sharpened」は後でRegistaxで処理するのでチェックなし、「RGB Align」は後でも処理できるのですが、面倒なのでここでチェック。「Dizzle」は一度3倍を試しましたが、時間がかなりかかるのでそのままOffです。Windowを移って、「AP Size」を104として、「Place AP grid」を押します。 あとは「3) Stack」を押すだけです。
  4. AS_P50とかいうフォルダができていて、その中にTIFFファイルができるので、それを Rregistaxで読み込みます。
出来上がったTIFFファイルをJPEGにしたものです。スタックした直後はこんな風にボケボケに見えます。

Jup_221451_lapl6_ap60



Registax

もう長い間バージョンアップしていないみたいです。アップデートは2011年から止まっていての、6.1.0.8が最新のようです。
  • Registaxを立ち上げたら、Autostakkertで作ったTIFFファイルを、「Select」ボタンを押して開きます。
  • その時に出て来るStrech intensity-levelsは変化させたくなかったのでNoにしました。
  • TIFFファイルの画面サイズが大きすぎると一部しか効果が見えないので、「Setting」タブの「Processing Area」の値を大きくします。ただし大きくするとパラメータの変更の度に結構時間がかかったりするので、小さいままで進めて、最後に「Do All」 タブで全てに適用するのがいいのかもしれません。
  • まず、ホワイトバランスが全く取れていなかったので、右のFunctionsの「RGB Balance」から「Auto balance」を選びました。これで少しましになりましたが、後でホワイトについてはPhotoshopなどで調整します。
  • 一番の目玉の「Wavelets」ですが、慣れるまで大変だと思います。いろいろ試したのですが、私はとりあえず「Dyadic()2^n」で「Gaussian」でそれぞれの空間周波数を「Preview」を押してどこらへんが変わるのか確認しながら進めます。数字の小さい細かい周波数は大きく変えますが、ノイズが入って来るのでそのノイズが目立たなくなるように「Denoise」を0.05からせいぜい0.2くらいの間で上げます。数字の大きい粗い空間周波数はほとんどあげないか、時には0以下にすることもあります。
  • Functionsも一通り試しましたが、使うのはせいぜい「RGB Align」くらいですが、これも少しバグっているのであまり期待しないほうがいいかもしれません。いずれにせよWavelets以外は後でPhotoshopなどでいじったほうが効率がいいのかと思います。
  • 全て終わったら、「Do All」 タブで全てに適用して、「Save image」でTIFF形式でセーブします。

その後、Photoshopでレベル補正、トーンカーブ、NikCollectionなどを駆使して、好みの色調にします。出来上がったものが一番上に載せたものになります。


この画像処理中に、「RB星のブログ」さんなどの撮影時の生動画に近いものをアップされているページを見させて頂いたのですが、さすがにそういった動画はいいシーイングの時をアップしてあるのは重々承知ですが、それでも今回撮影した時のシーイングがかなり酷いものだということはよくわかりました。恐らくC8の性能も全く使いきれていませんし、ASI290MMでL撮影に挑戦したいと思っているのですが、ASI224MCのカラーだけの性能も出しきれていないでしょう。やはりいい空が第一条件なのは惑星でも星雲でも同じですね。


後日、再撮影に挑戦しました。






 

5月29日、平日ですが先週あたりからC8を出したので、久しぶりに自宅で木星の撮影をしてみました。木星の撮影は去年の5月28日拡大撮影でX7で撮って以来ほぼ一年ぶりです。

IMG_1937


機材は前年中断した時と同じ鏡筒: Celestron C8 + 赤道儀: Advanced VXにCMOSカメラ: ASI224MCを付けています。ピント調節用に笠井トレーディングのシュミカセ用マイクロフォーカス接眼部を使っています。バローレンズは以前特価の時にKYOEIで購入したScientific Explorer社の5倍のものです。昨年買って少しだけ試して結局撮影での使用までいかなかったADCですが、今回少し使って見ましたが、木星が南天高くのぼっていたせいか調整してもほとんど変化が見られませんでした。一度画像処理をして見てから再度使用してみようと思います。

以前はCelestronの3倍のバローレンズを使っていたのですが、ADCを入れた時にバローレンズから撮影面の距離が変わると拡大率が変わってしまうという欠点がありました。今回新兵器のExplorer Scientific社のフォーカルエクステンダーはテレセントリック系のバローレンズで、距離が変わっても拡大率がほとんど変わらないというメリットがあります。そのおかげでしょうか、拡大率が5倍に変わっても、ADCを入れてもターゲットを見失うことが圧倒的に少ないです。

これまで惑星用のソフトの解説をしたことがなかったので、いい機会なのでメモがわりに今回少し書いておこうと思います。また、以前書いた胎内星まつりでのChristfer Goさんの講演のメモも役にたつと思います。

撮影用のソフトはFireCapture2.6βです。βのバージョンが去年の2.5から2.6に上がっていました。今回試したのは2.6.01です。インストールは特に問題なく、最初に実行ファイルをダブルクリックして、その後はASIカメラ用のショートカットができるので、それをクリックします。カメラの認識は特に問題ないです。設定したところだけメモしておくと
  • 画像が出ているWindowの左横のアイコンの「Set capture folder」で、ファイルの保存場所のルートディレクトリを好きなところに設定。私はD:¥home¥starの下にBYEやらSharpCapやらのフォルダがあるので、そこに指定。
  • 「Image」タブのROIで1024x768を選択
  • 「Capture」タブのところで、フォルダ名とファイル名に関係してくるJupitar, RGBを選択。5000Framesを選択。ファイル形式をAVIからSERに変更。
  • 「Option」タブの「Debayer」にチェックを入れカラー画像にする。
最初StickPCで取り込んだのですが、ROIで1024x768ピクセルにしてフレームレートが15fpsとかひどいと10fps以下になってしまうので、結局MacbookProのbootcamp上で撮り込みました。OSはStickPCもMacのbootcampもWindows10の64bit版です。それでもMacbookProでも25fps程度までしか上がりません。そこで、「Setting」タブから「Performance」を選んで、「Force agressive memory recovery during capture」を選びます。このメモリオプションありだと80fpsでも安定に保存までできました。

おそらくもう少し早いフレームレートも撮り込みができるのですが、暗くなりすぎてゲインを500以上に増やさなければならなくなるので、一旦80fpsまでとして出来上がりの明るさとノイズのバランスを見てこれからどこまでフレームレートを下げていけるかの調整していきたいと思います。 ちょうど天文リフレクションズで惑星撮影で有名なRB星のブログのまとめを紹介していて、その中で50fpsと書いてあったので、(追記) 最近のRB星のブログを見てみると、木星の場合はLが90fps、RGBが50fpsのようです。今後そこらへんを目処に試していきます。

実際の撮影では、21時頃まではシンチレーション(大気ゆらぎ)がひどかったのですが、その後22時頃にかけて揺れがかなり収まりました(追記)かなり像が揺らいでいて、21時頃からやっと筒内気流が落ち着いてきて少しましになりましたが、まだ空の揺らぎがひどく、また少し霞みがかっていることもあり、もう少しシーイングのいい日を待つ必要がありそうです。撮影中は画像が出ている左横のアイコンの中の「AutoAlign」をオンにします。すると、1024x768の画面を自動的に惑星が真ん中になるように移動してくれます。4つの赤い点が出て今画面のどこらへんを写しているかわかるので、端の方になった時は赤道儀のコントローラーで4つの点が真ん中になるように移動してやります。

ADCを使う時はWindowの左横のアイコンの中の「ADC tuning」というのを使うと楽ですが、今回は効果のほどがわからなかったのでこれは次回以降にもう少し試します。

アイコンを見ていくとダークフレームもふらっとフレームも取れるみたいですが、まだ試していません。実は手持ちのASI224MCは電視で酷使していてかなり汚れがひどく、惑星撮影時にセンサー保護ガラス面の汚れがそのまま拡大されて写ってしまい、黒いシミができまくっていました。撮影には致命的です。かなり綺麗に掃除したのですが、それでもまだ少し汚れが残っているので、フラット補正はしておいたほうがいいのでしょう。

結局、ファイルを80GBくらい取ったところでHDDが残り少なくなってきてしまったので、この日はおしまいにしました。今回の反省点は
  • なぜかRedがすごく強くBlueが弱い。
  • SERファイルにしたつもりがAVIのままだった。
  • C8がF10なので、5倍のバローでF50となり拡大しすぎかもしれない。
  • 多分シーイングはまだまだ全然良くないので、もっといい日を狙う。
くらいでしょうか。とりあえず今回の文の画像処理をして、後日また記事にしたいと思います。



あと、惑星関連でやってみたいことを少し書いておきます。
  • ASI290MMを手にいれて少なくともLとASI224MCのカラー合成、できればフィルターを使ってRGB合成を試す。
  • 昨年頂いたMEADEの250mmを試す。
  • MagicLanternでのRAW動画での惑星撮影がどこまでASIに迫れるか試す。
などです。
 

このページのトップヘ