ほしぞloveログ

天体観測始めました。

カテゴリ: software

長時間露光で問題になる縞ノイズの考察です。

  • ガイドのズレと同じ方向に縞が出る。
  • RGBと黒の4色。
  • 太さは一枚のコンポジットされた画像の中ではだいたい一定。でも画像によって細かったり太かったりします。太さは、ずれの長手方向に垂直な方向のずれの大きさに一致している?
  • クールピクセル説が強い。でも本当にこんなに前面にクールピクセルが広がっているのか?
  • カラーセンサーでクールピクセルが一つあると、上下左右のみでなく、斜め方向にも影響が出るので、ある程度の太さになる。
  • 不思議なのは、ガイドでずれたのを比較明合成した星像のずれの長さよりも、縞一本の長さの方が全然長く見えるのです。ずれの長さの3倍くらいは長く見えます。でもRGBと黒の4色しかないので、たまたま同じ色の線が繋がっているのが目立っているだけに見えなくもないです。ある色があった時2色繋がるのが4分の1で、3色繋がるのが16分の1。長いのは目立つのと、短いものも存在するので、長く見えるというのは説明できそうです。
  • 10分単位くらいに分けてコンポジットし、それをさらにコンポジットしてもダメだという報告あり(自分では未確認)。
と、ここら辺まで書いてあぷらなーとさんのコメントとブログを見て、やっとクールピクセルが原因というので納得してほぼ解決したのですが、せっかく自分でも途中まで考えてはいたので、そこまでだけでも書いておきます。


まず試したのは、簡単にするためにクール補正も、フラット補正もダーク補正もせず、三つ子銀河のIntegrationをすることでした。ImageCalibrationがなぜかうまくいかなかったのでStarAlignmentで代用。その結果がこれです。

nocosmetic


赤とか青とか緑とかのかすれた線が無数にあります。全部クールノイズだと思われます。前面に散らばっています。もっとわかりやすくするために、位置合わせをしないただの比較明合成をします。

nocosmetic_nocalibration_integration_a


クールノイズが点になって無数の輝点になって見えます。この時点で、やっとクールノイズの可能性が高そうだと思い始めました。

今度はクール補正をかけたものの比較明合成です。

cosmetic_nocalibration_integration_a


クールピクセルがなくなってかなりましに見えます。これなら変なノイズとかでなさそうなので、これで位置合わせを行います。

cosmetic_calibration_integration_a


でも結果はなぜか縞ノイズが出てしまいます。この理由が最初全くわかりませんでした。ところがIntegrartionの時にAverageを使わずにMaximumを使うと理由がかなりはっきりしました。

cosmetic_calibration_integration_Maximum_a


Maximumなので一番明るいものが残っています。形をよく見ると縞ノイズとかなり一致しているように見えます。Maxmumで見えるということは、このような明るい輝点はまだ存在していて、飛び抜けたもの含んで無理やりIntegrationの時にAverageで平均化したりすれば、さすがにそこにムラができるのは不思議ではありません。ImageIntegrationの時にPixel rejection(1)で「Rejection Algorithm」を「min/max」にすると多少は改善できることもわかりましたが、それでも縞は残ります。

あと、Maximumは星像が歪むという弊害があることもこの時気づきました。昨晩はここで終わって寝てしまいました。


その後、あぷらなーとさんからのコメントに答える形で前々回のページに書いたのですが、今日になってあぷらなーとさんのブログの過去記事を見るとここら辺のようなことがすでに見事に検証されていて、さらに輝点を加算するという解決法まで示してくれています!しかもぴんたんさんがすでにFlat Aide Proにその手法を実装してしまったとは!

カラー画像でもうまく輝点が出ないようにコンポジット前の画面を補正してしまえばいいと思いますが、あぷらなーとさんがやったようなモノクロならまだしも、やはりカラーだとちょっと難しそうです。


HUQさん、あぷらなーとさん、Scopioさんクールノイズにいつまででも納得できなくて色々説明してもらって申し訳ありませんでした。そして、こんな私に付き合っていただいてきちんと説明してくれて本当にありがとうございます。

自分で納得でないないと気が済まないのですが、今回の話は最初からアプラナートさんの2017年の9月くらいの記事を読んでおけば済む話でした。でも自分で試すという方向性はやめたくないので、また変なことを言うかもしれませんが、初心者のたわごとと思って温かい目で見ていただけるとありがたいです。


 


 

PixInsight(以下PI)の続きです。今日はLinear Stageについて書いておきます。

さて今日の材料は、しし座の三つ子銀河、通称トリプレットを3分露光で60枚、計3時間ぶん撮ったものです。FS-60QにASI294MCのセット、Advanced VXにPHD2でガイドなどは前回M33のときと同じです。これらをPIのバッチ処理でインテグレート(コンポジット)までしました。M33と同じく斜めの縞ノイズも、多少はマシですが見えてしまっています。比較合成したものを見ると、やはりガイドがずれていってしまっています。

light-BINNING_1_max

ズレは前回より小さくて、3時間で30秒程度でしょうか。縞ノイズは嫌なので、前回のように「Maximum」、「No normalization」でIntegrateしたものを使用します。

一応縞ノイズを比べます。デフォルトの「Average」、「Aditive with scaling」でIntegrationしたものと
light-BINNING_1_DBE_STF


「Maximum」、「No normalization」でIntegrateしたもの
light_BINNING_1_Maximum_No_normalization_DBE_STF3


です。やはり今回も縞ノイズに関してはあからさまに違いが見えていて、後者の方が圧倒的にいいです。それに加えて前者ではアンプノイズがまだ結構目立つくらいに残っています。このアンプノイズはASI294MC共通の欠点らしくて、どの個体もこの位置にアンプノイズが存在するようです。でもこの前者の画像を見ていると、ダーク補正が本当にうまくできているか疑問に思えてきました。違いはIntegrationのところだけのはずなので、ダークフレームによる補正の違いはないはずなのですが...。いずれにせよ、かなり差があるのでこれ以降は後者の方を使います。


Linear Stageでやるべき主なことは3つ、
  1. バックグラウンドを平らにする、カブリ補正のようなもの。
  2. ホワイトバランスを揃える。
  3. 色のキャリブレーションをする。
です。それぞれについてやりかたは何通りかあるみたいで、
  • 1と2は「Process」->「BackgraoundModelization」->「AutomaticBackgroundExtraction」もしくは「Process」->「BackgraoundModelization」->「DynamicBackgroundExtraction」
  • でまとめてできます。
  • 2として「Process」->「ColorCalibration」->「BackgraoundNeutralization」をする方法もあるみたいなのですが、うまくいく場合とうまくいかない場合があるので、今では使っていません。
  • 3は「Process」->「ColorCalibration」->「ColorCalibration」や「Process」->「ColorCalibration」->「PhotometricColorCalibration」などです。

DynamicBackgroundExtraction(DBE)が結構簡単で優秀みたいなので、今回はこれを使ってホワイトバランスまでを処理します。
  1. まずIntegrationした画像を開きます。次にメニューから「Process」->「BackgraoundModelization」->「DynamicBackgroundExtraction」と選んで、設定画面を出します。
  2. その状態で画像の星や星雲などがない暗い点を10から20個くらい選びます。設定画面の上の左右の矢印で選んだところのプレビューが出るので、あまりにおかしいところは赤いxじるしで選択から外します。
  3. DBEの設定画面の中の「Target Image Correction」で「Subtraction」を選びます。これを選ばないと出来上がった画面が出て来ません。
  4. DBEインスタンスを画像に放り込むか、下のチェックマークをクリックして実行します。
その時の画面が下になります。左がIntegration後すぐの画像、右の上の画面が適用後。右の下が補正分です。もともと青にかなり酔っていたので、青の補正がされているのがわかります。フラット補正はしてあったので被りや周辺減光に相当するのはほとんど目立っていません。出来上がった右上画面のバックグランドがホワイト化されているのもわかります。

IMG_3470


出来上がった画面をHistgramTransformation (HT)で見てやるとホワイトが揃っているのを確かめることができます。必要ならばこの後にBackgraoundNeutralizationをするのもいいみたいなのですが、今回は省きます。


上のDBEをするのに必要だと思われるPixInsightの特殊な操作方法について書いておきます。
  • 処理を実行するのに、下の丸ボタンを押してもいいのですが、Instanceを作る左下の三角じるしをドラッグして適用したい画像に放り込むと、その効果が適用されます。でもうまくいくときとうまくいかない時があります。xが出たり、何も出ないとうまくいかなくて、チェックマークが出るとうまくいきます。どうやったらうまくチェックマークになるのか未だによくわかりません。パッと入れるとうまくいくことが多いのはなぜでしょうか?
  • ScreenTransferFunction(STF)で簡易的にトーンカーブをいじって見やすくしてまずは把握する。この見やすくするというのは、SharpCapのヒストグラムの稲妻ボタンでトーンカーブをいじって電視観望で見やすくするのと同じ概念です。というより多分PixInsightからヒントを得てSharpCapに移植したみたいに思えます。試しに、HistgramTransformation (HT)画面とSTFバー画面を出しておいて、STF画面の放射能マークみたいな「Auto Stretch」ボタンを押してから、左下の三角じるしをドラッグして、インスタンスをHT画面の一番下の三角と四角と丸があるラインらへんにドロップすると(ものすごくわかりにくい操作方法です!)、トーンカーブの形がSharpCapのオートボタンを押してできるトンカーブとほとんど同じ形になることが確認できます。
  • STFは見かけ上の画像処理なので、Auto Stretchをした画像を保存しても、元の画像のままです。
  • ちなみにSTFの効果を効かせた状態で画像を保存するためには、上に書いたようにHistgramTransformation (HT)画面を出して、STFのインスタンスをHT画面の一番下の三角と四角と丸があるラインらへんにドロップして、さらにHTのインスタンスを画像にドロップして初めて実際の処理がなされます。それを保存すればやっとSTFを適用した画像を保存するということができます。
  • 各処理画面の下のところに白丸がある場合、Real-TIme Previewを見ることができます。プレビューで効果を確認して、パラメーターが決まったらプレビューを閉じて、オリジナルの画面にインスタンスを放り込むというやり方が主流のようです。

次が色のキャリブレーションです。今回はPIの最近のバージョンでの目玉機能と言われているPhotometricColorCalibration(PCC)を試してみます。これは複数の恒星をPlate Solvingでマッピングして、登録されている恒星の色情報から正しいと思われる色に合わせてくれるという、とても客観的な色合わせ機能です。早速試して見ましょう。

  1. 「Process」->「ColorCalibration」->「PhotometricColorCalibration」で操作画面を出してから、「Image Parameters」の「Search Coordinates」で写っている天体を探します。ここでは「M65」とかです。
  2. うまく座標が入ったら、「Observation date」に撮影した日にちくらいまで入れます。時間は適当でいいみたいです。あとは「Forcal length」に撮影時の焦点距離を、「Pixel size」に使っているカメラの素子のサイズをマイクロメーター単位で書き込みます。ここもかなり適当でいいみたいですが、5割違うとダメだと書いてありました。
  3. 「Background Neutralizatio」を選択します。「Regeon of interest」にチェックをつけて、Previewエリア(下に説明あり)を選んで、そのPreviewを「From Preview」から選択します。Upper limitはPreviewタブを押してPreview画面を開いてから暗い部分の値を、Readout modeで読んでやり、その付近の値を入れますが、デフォルトのままでも結構うまくいくみたいです。
  4. 三角じるしのインスタンスをDBE処理した画像に放り込むと処理が始まります。
  5. 結構進んだ最後の方で、実行した時に星が見つからないとか言われてうまくいかない時は、「Photometry Parameters」の「Limit magnitude」の「Automatic limit magnitude」のチェックを外し、「Limit magnitude」をデフォルトの12から15くらいまで暗くするとうまくいくことがあります。
IMG_3496


うまくいくと上の画像のように、グラフの表示とともに画像に今回の結果が適用されます。グラフはまだ何を言っているのかよくわかりませんが、検出された星をカタログ値の色にフィットしているのでしょうか?ここでCtrl+zやCommand+zでUndoすると、以前の画像と比較することができます。今回は少し赤みがかっていたのが補正されてよりホワイトになったことがわかりました。

PixInsightのとても特徴ある操作の説明です...。なんでこんな操作になるのか...、この記事が誰かの役に立ってくれると信じて書きます。
  • Previewという概念が特殊です。画像を開いている時に、上のアイコンの中の左から12番目くらいのフォルダのような形の「New Prview Mode」を選ぶと、画面の中の一部を選ぶことができます。プレビューもどの状態で画像の一部を選択すると、「Previwe01」とかいう領域が選ばれるとともに、左横のタグに同じ名前のものができます。この状態になって、初めて画像処理の画像の一部の選択、例えばバックグラウンドの領域選択などでこのプレビューを選ぶことができるようになります。
  • Readout modeは上のアイコン群の左から7番目にあり、デフォルトのモードになります。結構便利で、このReadout modeの時に画像の上で左クリックすると、拡大して画像を表示してくれて、マウスポインタが指している場所の色などを数値で出してくれます。Preview画面でもこのReadout modeは使えるので、Previewで暗い部分を選んで、さらに拡大して暗い部分の値を読み取ることができるわけです。
今回のところまでで、やっとPixInsightの全機能の1割くらいでしょうか。摩訶不思議な操作方法は、いろんな意味でもう「僕は嫌だ」状態です。とりあえずここまでで疲れ果てたので、Photoshopに持っていって簡単に仕上げてみました。

light_BINNING_1_Maximum_No_normalization_DBE_PCC
富山県富山市, 2018年1月20日0時19分
FS-60Q + ASI294MC+ Advanced VX赤道儀
f50mm + ASI178MC +PHD2による自動ガイド, 露出3分x60枚 総露出3時間0分
Pixinsight, Photoshop CCで画像処理


少し飛んでいるところもあったりしてまだ色々PIを使いこなすに至っていません。3秒露光の画像も撮ってあるので、HDR合成とか星マスクとかやって、もう少し時間をかけて仕上げてみたいですが、気合が続くかどうか。

次はNon-Linear Stageに挑戦ですが迷っています。Linear ProcessingまではあからさまにPixInsightは面白い機能が目白押しのはわかりました。Non-Linear Processingを含めて最終仕上げまで全てをPIでやることも可能みたいですが、Non-Linear ProcessingになったらPhotoshopなどに任せてしまってもいい気がします。PIの有利な点はマスクを簡単に作れるところでしょうか。これは結構魅力で、ここで作ったマスクをPhotoshopに持っていくのとかでもいいのかもしれません。

あ、あとPixInsightのライセンスを購入しました。まだ試用期間も残っていて、230ユーロと結構な値段ですが、その価値はありと判断してです。
 

さて今回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を試してみたいですが、予算を出せるかが悩みどころです。

 

このページのトップヘ