ほしぞloveログ

天体観測始めました。

カテゴリ: 画像処理

白濁したレンズを納得済みで購入したFC-76を使って、干潟、三裂、猫の手星雲撮影した画像の仕上げです。いろいろ紆余曲折して時間がかかってしまいました。


3枚の画像を合わせて処理

まずは前回の記事で使った、3枚の画像をまとめて仕上げてみました。FC-76とFSQ-60の2機種で、FC-76は180秒と300秒露光の2枚、FS-60Qは300秒露光が1枚です。総露光時間はそれぞれ30分なので、計1時間半分の画像があるわけです。

まずPixInsightのStarAlignment機能を使って3枚をあわせてスタックするのですが、鏡筒が違うので星像には微妙なズレが出てしまいました。

IMG_7557
例として右上隅の様子。星像の下半分が二重になっています。
上半分がずれていないように見えるのは
画角のずれで重なり合っていない部分だからです。

このずれはデフォルトの位置と回転のみでは補正しきれないので、StarAlignmentのいくつかのパラメータを調整します。

IMG_7554

触ったところは「Registration modl」を「2-D Surface Splines」にしたこと。これは2次元スプライン補間で画面全体を歪ませるモードです。でもこれだけだと不十分で、さらに「Distortion correction」をチェックしたこと。これは非線形な歪みを修正するとのことです。これで周辺部までずれずに綺麗に星像を合わせることができました。


結局2枚だけ使うことに

ここで問題に気づきます。

まず、FC-76が1.04倍のフラットナーを使っているので焦点距離は624mm、FS-60Qは600mmとFS-60Qの方が少し広いエリアを写しています。FS-60Qで写したの画角の中に、FC-76で写したエリアが全て入ってれば何の問題もなかったのですが、FS-60Qへの切り替え時に時間がなくて焦っていていくつかの確認工程を省いてしまい、狭いFC-76の方にしか写っていない部分があることに気づきました。しかもカメラの回転角のチェックも甘かったので、回転でも15度位ずれていたようです。

共通する部分だけを取り出そうとすると、かなりトリミングしなくてはいけません。それに加えて、FS-60Qの星像がピンボケで肥大していること、おそらく口径が小さいことによりノイジーに見えることなどを鑑み、FC-76で撮影した2枚のみを使うことに決めました。


2枚だとダメ!?

しかしここでもまた問題が発生。PixInsightのImageIntegration機能(スタックのことです)は何と最低3枚からしか動かないようです。他のソフトに行くか迷って、それでもいろいろ調べていると、PixInsightの英語のフォーラムの中に同じ画像を登録してしまえばいいと言う記述を見つけました。このページを見つけるためにgoogleで検索したワードは「pixinsight integration two image sources」です。では、なぜこのワードが出てきたかというと、PixInsightで2枚のみでIntegrationしようとしたら

"This instance of ImageIntegration defines less than three source images."

と出てきたからです。普通 "source images" という単語はパッとはなかなか出てきません。このようにエラーメッセージからヒントを得て、PixInsightとつけて検索してやるとすぐに

"ImageIntegration can't integrate 2 images? - PixInsight"

というページが2番目に出てきたと言うわけです。ちなみに日本語のページではこのような情報を見つけることはできませんでした。

さて、2枚の画像を2回登録して4枚にしてスタックしてやると無事に完了。ただし、少しカブリが残っているようなので、DynamicBackgroudExtractionで暗黒帯もなさそうな暗い部分を6-7点ほどのみ選んでカブリを除去しました。少し色がずれているようなので念の為PhotometricColorCalibrationをして、その後ScreenTransferFunctionでAutoStretchをして、HistgramTransformationで適用します。あとはPhotoshop CCに引き渡し、画像処理です。


最終画像

Photoshopで色々いじって、最終的にできたのが以下の画像です。

integration_DBE_PCC_stretched3
富山県富山市下大久保 2019/6/25 22:02-23:21
FC-76 + QBP + 新フラットナー+ CGEM II + EOS 6D(HKIR改造)
f=624mm, F8.2, ISO3200, 露出180秒x10枚 + 露出300秒x6枚, 総露出60分
PixInsightでダーク、フラット補正、スタック, Photoshop CCで画像処理


普段あまりしていないのですが、今回は少し茶色いモジャモジャも出してみました。でも高々トータルで1時間分の画像なので、まだまだノイジーです。ところでこのモジャモジャ部分って名前あるのでしょうか?モジャモジャの間の黒い部分は暗黒帯でいいんですよね。

あと、参考に四隅の切り出し画像を示しておきます。FC-76に新フラットナーをつけたもので、300秒露光したJPG撮って出し画像をオートストレッチしたものです。6Dなのでフルサイズです。これを見る限り、ほぼ点像ですね。新フラットナーいい仕事しています。

M8_LIGHT_6D_300s_3200_+24cc_20190625-22h51m58s692ms_8cut



まとめ

今回白濁したレンズが付いているFC-76で撮影して、上で示したくらいまで写すことができました。これがオリジナルのFC-76に比べてどれくらい劣っているのかはまだわかりませんが、少なくともまともなFS-60Qに比べて、遜色ない程度に撮影することはできるのは示すことができたのではないかと思います。

IMG_7576
改めて白濁が見えやすいように撮ってみました。
一様でもなく、濃いところ薄いところもあります。
結構ひどいことがわかるかと思います。

ではこの白濁の度合いはどうなのでしょうか?これだけ写るのならそもそも大した白濁でないのじゃないか?という疑問も出てきます。単に大げさに騒いでいるだけではないかということです。なので今一度自分自身でも確認の意味を込めて、まとめておきます。
  1. 対物レンズが白濁したFC-76をスターベース名古屋店で閉店直前に格安で購入しました。白濁があるため、タカハシ直営店ではジャンクとみなしてそれだけの値段しかつけることができなかったということです。
  2. 昼間明るいうちに見てみると、接眼側からアイピースを外してのぞいてみると対物レンズは真っ白近く。これはダメだろうと半分諦めながら実際にアイピースで覗いてみたのですが、解像度にため息が出て、少し眠い気もするが、白濁なんか全く気にならないレベルの鏡筒であることがわかりました。
  3. 眼視で月を見ると、FS-60Q年隠して多少コントラストが低下するところがわかりましたが、単体で見たら(少なくとも私レベルでは)絶対気づかないくらいの影響しかなかったこと。
  4. 撮影でも、と言うよりは眼視よりもさらに白濁の影響は少ないのでは、という今回の撮影結果を得たこと。
要するに、メーカーの直営ショップが白濁部分をジャンクレベルと評価し(おそらく世間一般でも同様の評価かと思いますが)安い値段をつけたものであるが、撮影まですると実は性能はその値段ほど落ちているとは思えないというのが今回の結論かと思います。もちろん、白濁していること自体が嫌な方がいるのは十分理解できますので、売値としては正しいものなのかもしれません。でも私は、白濁にさえ目をつぶれば性能的にはいまのところ不満はないので、十分満足です。むしろこの値段でこれだけ面白い経験をさせてもらったので、それだけでお得感満載です。

最後の疑問、これからもこの白濁レンズFC-76を撮影に使うかと言うと
.
.
.
.
今回は間違いなくこれからも使います。だってホント、全然問題に思えないんですもの。


今回の太陽GIFアニメ制作の過程で太陽画像を大量に処理したので、処理方法がだいぶん確立しました。

昨年まだ太陽を始めた頃に、一度画像処理方法をまとめましたが、あれから随分経ち手法もかなり変わってきたので、ここらで一度メモがわりにまとめておきます。

ネット上で得られた情報を元に、自分で実際に試してみて有効だと思った方法です。自分自身でもいくつか発見した方法も織り交ぜています。有益なソフトを開発してくれた作者様、ネットで各種手法を公開していただいている方々に感謝いたします。


画像スタックと細部出し

AutoStakkert3

太陽を撮影した動画(RAWフォーマットのser形式推奨)ファイルをAutoStakkert3でスタックします。

1.  「1)Opne」を押してファイルをオープン後、「Image Stabilization」で「Surface」を選択。
2. 画像が見える画面で、緑の枠をコントロールキーを押しながら移動。光球面のきわと背景の境目とか、プロミネンスがはっきり見えているところとか、黒点やプラージュの周りとかの構造がはっきりわかる部分を選択。
3. 後のパラーメータはあまり影響はないので適当に、私は下の写真の通り。「2)Analysis」を押す。
IMG_6870

4. 解析終了後、画像の方に移り「Min Bright」を調整して、光球面のみAPでおおわれるように。APの大きさは小さいほうが精度が出るが、小さすぎると出来上がった画像が破綻する。破綻がない程度に小さく。
IMG_6872


5. 「Stak Options」では「TIF」を選択して保存。「Sharpend」はオフに。
6. 「3) Stack」を押してスタック開始。


ImPPG

ImPPGで細部を抽出。パラメータの一例を下に示しておく。
IMG_6873

1. スタックしたtifファイルを開く
2. 上の方のアイコンの、左から4つ目の曲線グラフアイコンをオンにしてトーンカーブ調整エディタを表示。
3. 背景の一部と光球面の一部が四角い枠で選択された状態で、トーンカーブ調整エディタの「stretch」を押す。
4. 「gamma」は出来上がり画像の傾向を見るために使う。まずチェックボックをオンにして、ガンマを調整。光球面を出したいときはガンマの値を0.6くらいまで落とし、プロミネンスを出したいときは1.5-2.0程度までガンマを挙げる。
5. ここから模様出し。「Prevent ringing」はオンに。
6. 「Iterations」は大きい方がいいが、大きすぎると逆にリンギングが目立つ時がある。
7. 「Adaptive」はほとんど使っていない。
8.  画像保存時にはガンマのチェックボックスをオフにする。->後でPhotoshopで同様の処理をするため。画像を16bit tiffで保存。


Photoshopにてフラット補正と疑似カラー化

光球面の切り出し

光球面とプロミネンスをどの様に合成させるかが難しいです。以下に示した方法はあくまで一例です。

1. Photoshop CCにおいて、上で作成した画像を開く。
2. 「イメージ」->「モード」->「RGBカラー」でカラーモードに変換。
3. 背景を全選択して、コピー、ペーストする。光球面処理用レイヤーとする。
4. ペーストで作られた光球面レイヤーを選択してから、画面で「マグネット選択ツール」で光球面とプロミネンスの境、光球面が枠の縁に接しているところをなぞり、光球面のみ選択。
5. 「選択範囲」->「選択範囲を変更」->「境界をぼかす」で4ピクセルほどぼかす。
6. 「選択範囲」->「選択範囲を反転」で光球面以外を選択された状態にし、DELキーなどで削除。光球面のみが残る。これが光球面レイヤーとなる。


フラット補正

次に、光球面のフラット補正。光球面はエタロンの影響で減光が大きいので、フラット補正をした方がいいです。以下に示したフラットフレームの作り方は、境界がボケるのでもっといい方法があるかもしれません。

1. 背景を全選択して、コピーする。ペーストを2回する。一枚はプロミネンス処理用レイヤー、もう一枚はフラット補正レイヤーとする。
2. フラット補正レイヤーを選択し、「フィルター」「ぼかし」「ぼかし(ガウス)」で半径を20ピクセルほどにして適用。フラット画面を作る。念の為もう一度同じガウスぼかしを適用してさらにフラットに。
3. このレイヤーのかぶせ方を「通常」から「除算」に変更。この時点でかなり明るく飛ぶ。
4. 「レイヤー」->「 新規調整レイヤー」->「レベル補正」でできたレイヤーを右クリックして「クリッピングマスクを作成」をクリック。
5. 調整レイヤーのレベル補正のハイライト側をヒストグラムが盛り上がっているところまで下げる。

IMG_6867

(2019/4/13 追記: 上記4、5の方法だと、プラージュなど白い領域が飛んでしまうことがわかりましたので訂正しておきます。明るい領域の諧調を保つためにも、やり方も簡単になることも含め、下に書いた方法のほうがよさそうです。)

4. フラット補正レイヤーを「イメージ」「色調補正」「トーンカーブ」で調整します。トーンカーブで真ん中らへんを一点選んで上下し、明るさが適当になるように調整。
5. 光球面のみのレイヤー、フラット補正レイヤーの2つを選んで、右クリックで「レイヤーを結合」してフラット補正が完了。
6. フラット補正された光球面レイヤーを一番上に持っていく。境が自然になっていることを確認。


プロミネンスレイヤーを疑似カラー化

1. 一番上の光球面レイヤーの目のマークをクリックして非表示に、プロミネンスレイヤーを選択。
2. 「イメージ」->「色調補正」->「レベル補正」を選んでダーク側の三角をヒストグラムが下側の山(背景の暗い部分に相当)になっているところのピーク付近まで持ち上げ、真ん中の三角を下のほうまでもっていき、できるだけプロミネンスを出す。ここでいったん「OK」。
3. 再度「イメージ」->「色調補正」->「レベル補正」を選んで、「チャンネル」の「レッド」を選択。真ん中の三角を左端の山の際くらいまでもっていく。
4. 「チャンネル」の「ブルー」を選択。真ん中の三角を右端くらいまでもっていく。
5. 「チャンネル」の「グリーン」を選択。真ん中の三角を少しだけ右にもっていって赤っぽくなるように調整。
6. もし背景に赤いノイズが残っていたら、Nik collectionのDfine 2が有効。さらに背景を少し暗くするため、「イメージ」->「色調補正」->「トーンカーブ」を選んで補正。


光球面レイヤーを疑似カラー化

1. 一番上の光球面レイヤーの目のマークをクリックして表示させ、選択。
2. 「イメージ」->「色調補正」->「レベル補正」を選んで、「チャンネル」の「レッド」を選択。真ん中の三角を左端の山の際くらいまでもっていく。
3. 「チャンネル」の「ブルー」を選択。真ん中の三角を右端くらいまでもっていく。
4. 「イメージ」->「色調補正」->「トーンカーブ」を選んで、50%のところを選んで少しだけ下げ、模様を強調。これはImPPGのガンマ補正で数値を上げたことに相当する。

IMG_6869


これで完成です。あとは適当に荒れた縁の方をトリミングして、画像を保存するなどしてください。


太陽観測のススメ

他のソフトや、細かい工夫などの方法はまだまだあるかと思いますが、画像処理の基本はこんなところかと思います。太陽の隠れた面が見えてくるのはとても楽しです。あなたも太陽観測試してみませんか?

と気楽に呼びかけているのですが、太陽の一番のハードルはやはり観測機器の値段でしょうか。太陽観測に必須のエタロンは精度が必要な光学部品なので、どうしても価格が上がってしまいます。入門用のCORONADOのP.S.T.でも簡単に10万円越え。これでも口径40mmなので解像度に不満が出るかもしれません。P.S.T.より上級機ではCORONADOのSolar MaxやLUNTなど、口径60mmクラスでBFの径にもよりますが数10万円から50万円コース、口径80mm越えだと50万円からなんと100万円以上のものもあります。

この値段がネックなのか、海外などでは比較的安価に手に入るP.S.T.の改良記事もたくさん見受けられます。このブログでも改造記事を紹介していますが、くれぐれも太陽観測は安全に気をつけて、改造するにしても自己責任で、繰り返しになりますが本当に安全に気をつけながら楽しんでください。


しつこいようですが、いまだにコンバージョンファクターの測定です。だんだん何が目的かわからなくなってくる完全に自己満足の世界です。カラーでどうしても疑問が解決しないので、モノクロCMOSカメラのASI290MMを使って、基本に立ち返って検証してみました。


疑問点


疑問は2つ。
  1. ノイズの評価に標準偏差を使うとSharpCapに比べて大きく出すぎる。平均偏差だと同じくらいのノイズになるが、正しい方向なのか?
  2. debayerをするとノイズが平均化され小さく出るが、果たして公平な解析と言えるのか?
です。カラーカメラは余分な処理も多いので、もっとシンプルなモノクロCMOSカメラを使えば何か知見が得られるかもしれません。


モノクロカメラのSharpCapでの自動測定の結果


まずはSharpCapのセンサー測定機能で測定してみます。光源はこれまで通りiPadのColor Screenです。測定結果だけ示しますが、ほぼメーカー値と同じ値が出ます。ゲイン0でのコンバージョンファクター(Gain, e/ADU)は3.6程度です。

IMG_6411


モノクロカメラのマニュアル測定と自作コードでの解析の結果

次は自分で撮影して、その画像を解析します。画像の撮影自身にはSharpCapを使いました。今回はより厳密に、SharpCapで自動測定している様子をビデオに撮って、その時に使われたパラメータ、特に露光時間を全く同じにして測定しました。解析はpythonでの自作コードです。結果を示しますが、ここでは2つの結果を比較したいと思います。まず一つは、ノイズの評価に標準偏差を使ったもの。これはカラーCMOSカメラの場合は、ノイズが大きすぎると結論を出したものです。結果です。

Conversion_Factor_ASI290MM_std
モノクロの場合は標準偏差を使うことで、少しだけずれますがほぼメーカー値およびSharpCapの自動測定と同じ結果を出すことができるようです。Unity gainのズレとして15程度、1.5dBなので、1.18倍くらいの違いなので、まあ許容範囲でしょう。

一方、カラーで正しそうな値を出した平均偏差を使った場合の結果はというと

Conversion_Factor_ASI290MM_madmean
というように、ノイズが小さく評価されすぎていてメーカー値より大きなコンバージョンファクターとなってしまっています。

カラーカメラを再びマニュアルで解析

前回の測定は何かまだ問題があったかもしれません。再確認のために、モノクロカメラで測定した時と限りなく同様に、自動測定の時の様子をビデオに撮影し、その時のパラメーターを再現することで、より厳密にマニュアルで撮影、解析してみました。

まずは一番素直でモノクロの結果に一番近いはずの、標準偏差でのノイズ評価と、CFA分離です。結果はやはりノイズが大きく出すぎていて、コンバージョンファクターはメーカー値4程度に対して、わずか半分程度と出てしまいます。

Conversion_ASI294MC_Pro_Factor_CFA_std1
次に、CFA分離ですが平均偏差での評価です。3.3程度とだいぶんましになりますが、やはりまだ4とは優位にズレがあります。

Conversion_ASI294MC_Pro_Factor_CFA_madmean


次に、あぷらなーとさんが解析してくれたようにdebayerした場合です。ノイズが平均化されてばらつきが少なく出ます。まずは標準偏差を使ってノイズ評価した場合。それでも結果は2.5程度と、まだノイズが大きく出すぎています。

Conversion_ASI294MC_Pro_Factor_RGB_std

最後に、前回正しいと判断したdebayerして平均偏差をノイズ評価に使った場合です。結果は4.06と、メーカー値の4程度にかなり近い値が「たまたま」出ています。

Conversion_ASI294MC_Pro_Factor_RGB_madmean

今回はモノクロで正しい値が出たものと、相当近い方法でより厳密に測定していますが、結果は前回と変わりませんでした。前回もすでに、測り方としては特におかしい方法だったわけではない、ということがわかります。でもやはりこの平均偏差を使うことと、debayerでノイズを小さく見積もることが、恣意的な操作がなされているようで、どうしても正しいと思うことができません。


考察

モノクロの結果だけ見ると、ノイズの評価には標準偏差を使うことで、メーカー値やSharpCapと同様の結果を出すことができるので、標準偏差を使った方が正しそうということがわかり、統計の観点から言ってもその後の解析もしやすそうですし、素直な気がします。debayerで滑らかになったものを評価するような恣意的なことも入り込む余地もないので、このモノクロの結果には特に疑問となるようなことはありません。

それではなぜカラーCMOSカメラの場合は標準偏差を使うとノイズが大きく出すぎたり、debayerしたものの方よりも、RGGBのアレイごとに分割したCFA分離の方のノイズがメーカー値よりも大きな値が出たりしてしまうのでしょうか?SharpCapのSensor Analysisの説明
if you have a colour camera it must be in a RAW mode to perform sensor analysis as the debayer process used to convert RAW images into RGB or MONO images causes sensor analysis to give incorrect results.
という記述があることから、やはり解析の際にはdebayerはしていないようにしているようにとれます。


補足

ここで少し気づくことがありました。下の写真はカラーのASI294MC ProでADU値が10000程度の時を測定している様子です。

IMG_6436

SharpCapでは16bit形式で値を出しているので、実際に記録された14bitに換算する場合は4で割ってやります。横軸は10000程度になることがわかります。

ノイズは4で割って、さらにdebayerした時に15くらい下がることを考えると、RGBともに200後半台なので、結果として50程度になることが予測できます。ノイズは2条分布で評価するので、この50を2乗して2500程度。先ほどの10000をこの2500で割ってやるとコンバージョンファクターになって、10000/2500=4程度となるわけです。でもよく見るとRGBの線の他にもう一本白い線があり、こちらの方がかなり小さいノイズになっています。たぶんこれLなんですが、でもなんで?RGBよりもばらつき具合が小さくなる理由が全くわからないです。

Lの標準偏差で評価した時のノイズが、RGBでdebayerして平均偏差を使った時のノイズと、数学的に等価になるとか証明できたら安心して校舎を使うことができますが、パッと考えてもなかなかイメージできません。あと、Lのノイズが小さすぎることも気になります。

(追記: 一晩寝て考えたら多分謎が解けました。もっと単純な話で、今晩帰ったら検証してみます。)
(さらに追記: ヤッリダメでした。詳しくはコメント欄を。何か根本的におかしなところがあるのか?)

まとめ


いずれにせよ、SharpCapの自動測定は何かRGBとは違う評価方法を使っているのかと推測できます。

まだまだ先は長いですが、コンバージョンファクターもそろそろ飽きてきました。この状態だとまだASI294MCのダークノイズの評価の準備がまだ整っていない気もしますが、徐々にちらの方に移っていこうと思います。


ASI294MC Proのコンバージョンファクターを求める一環であぷらなーとさんからのコメントがあり、debayerせずにRGGBの画素ごとに分離してみたらという助言がありましたので試してみました。 

RGB分離したファイルからS-N^2分布をプロットするpythonコードを、fitsから直接CFA (Color Filter Array)のRGGBの4つ分に分離するようなものに改良して再度プロット。画像数は縦横2分の1、面積では4分の1になります。結果が以下のようになります。

20190304_02_Conversion_Factor_CFA



ところがグラフを見てもわかるように、全然メーカー値(コンバージョンファクター: 4程度、ユニティーゲイン:120程度)を再現できていません。要するに各画素の画像ファイルのノイズが大きい、すなわち輝度のばらつきが大きすぎるのです。 自分で書いたルーチンが何かおかしいのかと疑い、PixInsightを使ってマニュアルでも解析してみました。

PixInsightにはPreprocessingのところにSplitCFAというコマンドがあります。これを画像に適用してやると、画素ごとに分離された画像が自動的に出来上がります。この画像を使って、これもPixInsight上のImageInspection -> Statisticsで統計的な値をみてやりましたが、pythonで解析したのと同様の傾向でした。また、CosmeticCorrectionでのホットピクセルとクールピクセルの除去は結果にほとんど影響を与えませんでした。これは中心付近だけをみてもほとんどホットピクセルとクールピクセルが入っていないからかと思われます。

わかりやすいところで、輝度10000付近になるところを例として、結果を示しておきます。

Capture_00_16_30_00010_00_20_06_cc_CFA0->Preview01
CFA0 CFA1 CFA2 CFA3
count (px) 15544 12540 15120 14868
mean 10205.3 9805.5 9803.4 9209.9
median 10205.5 9806.6 9803.6 9209.6
stdDev 65.7 67.0 65.3 61.1
avgDev 52.6 53.2 51.9 48.9
MAD 44.0 44.0 44.0 42.0
minimum        9912.5 9528.6 9543.6 8977.6
maximum        10444.5 10049.5 10084.5 9475.6


Capture_00_16_30_00010_00_20_06_cc_RGB_VNG->Preview01
R G B
count (px) 14950 14950 14950
mean 10229.3 9798.6 9206.1
median 10229.5 9798.8 9206.9
stdDev 59.566 56.9 57.6
avgDev 47.138 44.4 45.6
MAD 39.040 36.2 38.0
minimum 10003.5 9551.6 8941.1
maximum 10484.4 10049.5 9445.2


上がCFAで分離した場合、下がdebayerした場合になります。赤いところを見比べればいいのですが、全く同じ画像から作り出したにも関わらず、明らかにCFA分離の方が平均偏差(avgDev)が大きく出てしまっています。あまり大きな差に見えないかもしれませんが、分布図を作るときにこの値を2乗してプロットするので、ざっくり(52/46)^2で1.28、約3割の増加です。1次グラフの傾きも3割くらい変わってきて、コンバージョンファクターも、ユニティーゲインも3割くらい(ZWOカメラのゲインにして40程度)変化があります。

どうもPixInsightでdebayerをするときにばらつきが減るような効果があるようなのですが、なぜそうなるのかはまだよく理解できていません。ただ、SharpCapでもただちにRGBにdebayerして測定していると思われるので、とりあえずはdebayerを正しいと思って進めることにします。

まとめですが、今回の過程でまだ2つのしっくりこない部分が残りました。
  • ばらつき具合を評価するのに標準偏差よりも平均偏差を使ったこと。
  • debayerとCFA分離でノイズに明らかに差が出る。debayerの方がノイズが少ない。
ということが判明したのですが、特に後者のわかりやすい説明があれば知りたいです。

debayerの時に周りの(同じカラーの)ピクセルの値を一部情報として輝度を決めるはずなので、確かに少しばらつきがなくなるというのも一理あるのですが、はたしてそれを性能評価として使っていいものなのか?科学的には間違っている気がしてなりません。

ではなぜメーカー値もSharpCapも同じ値を出せるのか?やはりまだ何か自分が根本的に間違っているのでしょうか?


続きの記事。

 

画像処理で出来上がったファイルの四隅の星像を比べたくなることがあると思います。これまでPhotoshopで手作業で切り取り貼り付けを駆使して作っていたのですが、何度もやるとなるとめんどくさいので、簡単にできるようにpythonとOpenCVを使って作ってみました。

超お手軽プロブラミングなので、内容はソースを見たらすぐにわかると思います。唯一工夫したところはファイル名をGUIで選択するところくらいでしょうか。Macで試しましたが、多分Windows他でも動くと思います。(すみません、チェックもしてません。)


必要な環境

環境を構築するのもいたって簡単です。今回はMacで試したので、Macでやる場合を書きます。WindowsなどでもPythonとOpenCVが動く環境なら走るはずなので、難しくもなんともないと思います。

1. Macの場合、Phython3はHomebrewからインストールするといいでしょう。Homebreはターミナルを立ち上げて、

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

でインストールできます。


2. 次にPython3です。これもコマンド一発で、

brew install python3


3. 最後はOpenCVのインストールです。

pip3 install opencv-python

でインストール完了です。xcodeをインストールしていない場合は、最初にそれも必要かも。うまくいかない場合は、私なんかの説明よりも、適当に検索すればOpenCVが使えるようになるまでの説明はすぐに出てくるので、探してみてください。


ソースコード

さて、python3とOpenCVの環境が整ったら次はプログラミングです。今回はホントにチャカチャカっと書いたコードなので、全然綺麗ではありませんのでご容赦ください。ファイル選択の際文句が出たりもしますが、とりあえず動きます。

エディタなどで以下のコードをテキストファイルにコピぺして、適当なファイル名をつけて、拡張子を.pyにすれば準備完了です。

import cv2
import numpy as np
import tkinter
from tkinter import messagebox as tkMessageBox #python3
from tkinter import filedialog as tkFileDialog #python3


def pathname(fullpath):
    n = fullpath.rfind('/') + 1
    return fullpath[:n]

def select():
    root=tkinter.Tk()
    root.withdraw()
    fTyp = [('JPEG file','*.jpg')]
    iDir = '/Users/ユーザー名/' #自分のユーザー名を入れてください
    filename = tkFileDialog.askopenfilename(filetypes=fTyp,initialdir=iDir,title = "ファイル選択")
    iDir = pathname(filename)
    return filename


filenameselect = select()
img = cv2.imread(filenameselect)


mlen = 250
size = img.shape
roi_UL = img[0:mlen, 0:mlen]
roi_UR = img[0:mlen, size[1]-mlen:size[1]]
roi_LL = img[size[0]-mlen:size[0], 0:mlen]
roi_LR = img[size[0]-mlen:size[0], size[1]-mlen:size[1]]
roi_CC = img[round((size[0]-mlen)/2):round((size[0]+mlen)/2), round((size[1]-mlen)/2):round((size[1]+mlen)/2)]

width = mlen*3
height = mlen*3
imageArray = np.zeros((height, width, 3), np.uint8)
count = np.array([[0,0],[0, mlen*3],[mlen*3, mlen*3],[mlen*3, 0]])
cv2.fillPoly(imageArray, pts=[count], color=(255,255,255))

imageArray[0:mlen, 0:mlen] = roi_UL
imageArray[0:mlen, mlen*2:mlen*3] = roi_UR
imageArray[mlen*2:mlen*3, 0:mlen] = roi_LL
imageArray[mlen*2:mlen*3, mlen*2:mlen*3] = roi_LR
imageArray[mlen:mlen*2, mlen:mlen*2] = roi_CC

savefile = filenameselect.replace('.jpg', '_4cut.jpg')
cv2.imwrite(savefile,imageArray)



実行結果

ターミナル上で上のプログラムがあるフォルダに行き、

python3.py ファイル名.py

とかで実行すると、画像ファイルを選択するダイアログが現れます。ダイアログが前面に出てこないことがあるので、下のDocからPythonというアイコンを選んでみてください。JPEGファイルしか選べませんが、プログラムの中の15行目を*.pngとかすれば多少他のファイル形式も選べます。

切り取りたいファイルを選択すると、同じフォルダの中に

オリジナルファイル名_4cut.jpg

というファイルが出来上がります。

出来上がりは下のようになります。元の画像から四隅250x250ドット分と真ん中を250x250ドット分を切り取って750x750ドットのファイルを作ってくれます。ホントにこれだけです。

test_4cut


ちなみにこれは、タカハシの新フラットナーで撮ったFS-60CBの星像です。カモメ星雲ですが現在画像処理中のものです。ほとんど流れていないことがわかると思います。元々の動機が、新旧フラットナー、レデューサー、エクステンダーでの四隅の星像を比較したくて、いちいちやるのがめんどくさいのでプログラミングに走ったというわけです。

今回のプログラムは色々制限もありますが、簡単なプログラムなので中身もすぐにわかると思います。各自で適当に改良してみてください。

例えば、26行目の250を他の値に変えると切り出してくれる画像の大きさが変わります。
ちょっと頑張れば上下左右も合わせて8方向の切り取りとかもできると思います。

画像処理プログラミングの取っ掛かりとしては、いい練習になるかと思います。




参考ページ

以下のページを参考にしました。
どのページもわかりやすくて、とても役に立ちました。どうもありがとうございました。 

週末土曜日に飛騨コスモス天文台に行って、M57とM27を撮影しました。それぞれの撮影枚数は、露光時間が20秒と短いこともあり、かなりの枚数になります。具体的にはM57が282枚、M27が244枚をなり、処理の前に簡単に閲覧するだけでも大変になります。しかもSharpCapで撮影したRAWファイルなので、拡張子が.fitsファイルとなり、開けるソフトも限られています。

最初の頃はfitsファイルもステライメージで確認していたのですが、これだけ数が多いと大変になります。PixInsightでも開くことができますが、一枚一枚が結構重いので、全部を気楽に開くわけにいかなくて、選別するのが結構大変です。

そんなときはPixInsightの「ImageInspection」->「Blink」が便利です。

IMG_5690

  1. 下のフォルダマーク「Add Image Files」から複数ファイルを選択して読み込みます。
  2. 読み込みは数百枚だど数分かかるので、50枚くらいずつにしたほうがいいと思います。
  3. RAW画像でも、Debayerした画像などでも読み込むことができます。
  4. 画像が暗くて見にくい場合でもSTFがかけられた状態で表示されるので、見やすくなっているはずです。これは真ん中に3つ縦に並んでいるアイコンの、真ん中を押すと確認することができます。
  5. 読み込んだ後は、左右の矢印を押すか、画像のファイル名を一つ選択してあとはカーソルの上下で、すごい勢いで画像を連続で切り替えることができます。
  6. 左の三角ボタンを押せばアニメーション表示することもできます。
  7. ただし、ソート順はファイル名のみのようなのがちょっと残念なところです。
  8. 弾きたい画像は、マウスでファイル名を選択(複数も可能)してから、下のアイコン群の左から5つ目の小さい矢印がついているアイコンを押すと、移動したいフォルダが選択できるので、そこに移動されます。
  9. 終わった後は、下の左から3番目のアイコンを押して、すべてのファイルを閉じます。
  10. これを次の50枚とか繰り返すと、かなり効率よく見た目で明らかに悪い画像ファイルを弾くことができます。


もう一つ便利なのが、「Script」->「Batch Processing」->「SubframeSelector」になります。各画像の星像のFWHM(半値全幅)やEccentricity(偏心度)を測定してくれます。自動でだめな画像を別ディレクトリに移動することなどもできます。

詳しいことはマニュアルを読むといいのですが、英語で結構大変なので簡単な説明を書いておきます。

IMG_5688

  1. いつものようにAdd Filesで解析したいファイルを複数選択します。
  2. 最低限解析するだけなら、そのまま一番下の「Measure」を押します。
  3. CPUや解像度にも依りますが、一枚解析するのに7-8秒程度なので、数百枚でもなんとか耐えられる時間の範囲です。結構かかりますが、それでも一枚一枚やるよりははるかに楽です。最初は少数枚でテストするといいでしょう。
  4. 「Plots」を開くと結果が出ています。「FWHM」や「Eccentricity」で飛び抜けている画像を判断することができます。
  5. 飛び抜けているところをクリックするとx印がつくので、Outputで弾きたいファイルをMoveなどする設定をすると、移動してくれます。
  6. 式で評価して、自動で弾くこともできますが、そのためには下に示すようなパラメータを入れたほうがいいですし、式の入力にはいろいろやり方があるようなので、詳しくはマニュアルなどを参照してください。「星見庵日記」さんのこのページが日本語で比較的詳しく説明しています。
IMG_5689


もう少しきちんとしようとすると、最低限入力する値は、「System Parameters」の中の「Subframe scale」になります。ざっくりした見積もりの「1ピクセルあたりの画角は焦点距離600mm、ピクセルサイズ4umで約1.5秒」とかから考えてもいいですし、こんなサイトから焦点距離と自分の持っているセンサーのサイズを選択して、センサーのピクセル数で割ってやっても簡単に求めることができます。

「Camera gain」も入れるべきでしょう。でもこれは結構難しいです。メーカーのページに行ってもいいですが、例えばASI294MC場合ここの「GAIN」というグラフの横軸「Gain」の実際に撮影した時の値のところを見ればいいのですが、グラフから読み取ろうと思っても0近くになり正確な値は読み取れません。SharpCapがあれば自分で測定することもできます。結果の表からある程度の値は読み取ることができます。それでも誤差があるので、ある程度の値でかまわないでしょう。

ここまで入れると、結果もある程度(絶対値に近いという意味で)正しい値になってくるので、センサーやカメラが変わっても比較することができるようになりますし、式を使った評価でも正確性が出てきます。が、とりあえず面倒なら何も考えずに「Measure」ボタンを押してしまったほうが幸せかもしれません。


ここしばらくブログの更新が滞っていました。忙しかったのもあるのですが、一番の原因は天の川の画像処理でずっと悩んでいるからです。

8月初めに撮った木曽シュミットを背景にした天の川。ところが、気合を入れて画像処理を始めたのが、今回の迷走の始まりでした。Lightroomのレンズプロファイルでの補正と、PixInsightのDBEで周辺減光とさらカブリを除きます。星マスクを利用したり、景色部分にマスクを施したり、天の川部分のマスクも苦労して作ったりして色々試しました。多分正しい方向で進めているはずです。でもなぜでしょう、やればやるほどわざとらしくなって自然感が損なわれていく気がします。

IMG_1312_DBE1_ps

多分上の処理でも悪くないのかと思います。でも、ふと元のJPEG撮って出し画像を見直してみると、もちろんホワイトバランスも取れていないし、周辺減光はありまくりだし、天の川も強調されていないのに、なぜかわざとらしさのないこちらの方が好きな自分がいることに気づきます。ここら辺で完全に迷走状態になりました。
  • 周辺減光はきちんと補正するのが善か?天の川を中心に持ってきたらむしろ周辺減光があった方が天の川を目立たせることができるのでは?
  • 背景のホワイトバランスを撮ることは本当に正しいのか?なぜ青い夜空はダメなのか?
  • 星景写真は、科学なのか?芸術なのか?
などなど疑問が尽きません。天体写真は自分の場合あくまで趣味なので、科学写真とは違います。それでも星雲などの天体写真は宇宙の深淵を覗くという意味でまだ科学に近い気がしますが、星景写真はその名の通り景色を入れます。景色と星の組み合わせという意味ではなにか主観を入れたいという意図があることが普通なので、やはり芸術に相当近いような気がしています。こんなことを悩んでいても、正解もなければ答えが出ないこともよくわかっています。

そんな時に、ちょうどプロの星空風景写真家の方の話を聞く機会がありました。その方に上のような疑問をぶつけてみたのですが「一旦補正した周辺減光をあえて加える場合もある」「結局は自分が何を表現したいかではないか」という助言をいただきました。おそらく天体写真として撮っているアマチュアと、生計を立てているプロの写真家というのでは、全然目指している方向は違うのかもしれません。それでも人に見せるという意味では、この写真家の方の言うことは正しいのではないかと思いました。

まだ迷いはとれませが、星景で自分の見せたいものを見せてもいいという道があることがわかっただけでも大きな進歩です。でも個性を出すということは怖いですね。それを凌駕して魅力的な作品を生み続けるのがプロということなのでしょうか。色々悩んでいたことも少し吹っ切れた気がして、今回の星景写真に関しては少し自分が好きなものを目指そうと思いました。

IMG_1312_low

素材がいい場合は、画像処理も最小限で済みます。強度なあぶり出しもしていませんし、周辺減光も必要以上にとったりしていません。ホワイトバランスも多少合わせますが、好みを残しています。カブリもそのままで、この黄色から黄緑を経て青へと変わっていくような色が結構好きです。

くだらない悩みかもしれませんが、ここに至るまでに二週間くらいかかりました。まだ迷走する気はしますが、しばらくは技術にあまりこだわらずに処理をしてみようと思います。

前々回の記事のプロミネンスですが、結構な分解能で撮れていたのでどれくらいのスケールで形が変わっていくかを知りたくて、2018年6月17日午前11時30分からほぼ10分間隔で3時間ちょっと撮影を続けました。合計24ショット撮りそれをGIFアニメーションにしたものが以下の映像です。

pronimence_position_background_color3_cut01

動画にするにしてはコマ数が少なすぎるので、GIFアニメにしてみました。ただ、変化部分が小さいのでトリミングしてサイズを1024x576にしています。途中止まってしまうことがあるようなので、その際はページを再読み込みしてみてください。

細かい写り具合は撮影状況や画像処理によって大きく変わるのですが、大まかな動きを見ると最初小さめの三角型だったのが、少しづつ広がって釣鐘型のように形が変わっていくのがわかると思います。

撮影と画像処理は結構大変で、基本的にエタロンもCMOSカメラの位置もPSTでのピントも変えないようにと思っていたのですが、赤道儀が回転することによる重力のかかりたの変化なのか、それとも温度の変化なのかわかりませんが、何十分かに一回はピントを合わせる必要があるくらい、なぜか焦点がずれ続けました。また、プロミネンスの写り具合が画像処理に大きく依存します。画像処理もできるだけ同じような工程で進めましたが、やはりなかなか同じにはならないようです。

それぞれの動画は500フレームで撮影し、保存した.serファイルからAutoStakkert!3でスタックします。ファイル選択時に、複数本最初に選ぶことで、一回の設定で一度に選んだぶんだけの動画を処理できます。その時にSharpendオプションを選んで、Registaxなどの後処理を簡略化しました。光球面や惑星などに比べて、プロミネンスの場合Registaxの効果は限定的なのでこれでも十分との判断です。

PhotoShopもアクションで擬似色化の処理を自動化しています。その後、PhotoShop上でレイヤーを利用して一枚一枚手合わせで位置とカラーバランスを調整していきますが、これが一番大変でした。最後はPhotoShopのタイムラン機能を使いgifアニメ化しています。

時間も手間もかかりますが、出来上がったものを見るとこれはなかなか面白いです。もう少し安定に写し出せるように経験を積んで、フレアクラスの大きなものが刻一刻と変わっていくのをいつか撮影出来たらと思っています。

先週、今週と2回にわたり撮影したホタル。前回記事にした静止画に引き続き、今回動画をまとめました。ホタルのリアルタイム撮影は超高感CMOSかめらを手に入れてからずっとやって見たいと思っていたことでした。

カメラはこれがあって初めてリアルタイムのホタル撮影が実現したと言ってもいいZWO社のASI294MCで、そこに50mmのオールドNIKORレンズをつけています。F1.4なので、ASI294MCの高感度と相まってかなり明るく撮ることができます。ソフトはいつものSharpCapです。それでも実際のホタルが飛ぶのが映るくらいのリアルタイムでの撮影は相当暗かったので、いくつか工夫をしています。

まず動画と言うためには、最低10FPSほどないとスムーズに見えないことがわかりました。できれば20FPSくらいあるとかなり滑らかになります。露光時間でいうと50msということです。今回の動画は主に20FPSで撮ったもので、一部10FPSです。それ以下のものはホタルの軌跡に飛びができてしまっていて使うことを諦めました。15FPS程度が明るさとスピードの妥協点くらいかもしれません。

FPS数を大きくすると、当然一コマあたりの露光時間が短くなるの、でゲインを上げる必要があります。ゲインを上げすぎるとノイズが大きくなり、ダイナミックレンジが小さくなってくるのであまり上げたくありませんが、それでも明るく取ろうとするとほぼ最大ゲインレベルに近いものが必要となります。

それを回避するためにハードウェアビニングを2としました。これで明るさが4倍になります。解像度は落ちますが、それでももともとASI294MCは高解像度なのでビニングしても2072x1410ピクセルで撮影でき、Full HD(1920x1080)を十分確保できます。実はASI294MCのフル解像度4144x2822で撮影すると転送速度の制限で数FPS程度にまで落ちててしまいます。4Kのリアルタイム撮影は、画素数的には足りていてもかなり厳しいのかと思います。

解像度だけを落として転送速度を上げることもできますが、それだと画面の一部だけ切り取ってしまうので、ASI294MCの特徴の4/3インチ大センサーの恩恵が生きてきません。ビニングだと画角は最大のままで解像度だけ落ちるので、大センサーの恩恵が使え、そのまま広角で撮ることができます。


一つ不思議だったのが、RAW16で撮影すると表示画面が相当暗くなってしまうことです。撮影されたファイルを見てもRAW16の方が見た目暗くなるようです。仕方なく今回はRAW8で撮影しましたが、なぜこうなるのか理由がわかっていません。もしかしたらバグの可能性もあります。


撮影した動画の編集はMac上のiMovieで行いました。SharpCapのRAWファイルは.ser形式なので、まずはSER PlayerでAVIに変換します。それでもiMovieはAVIをそのまま読み込むことはできないので、例えばHandBrakeでMP4形式などに変換するか、QuckTime PlayerでMOV形式に変換します。最初HandBreakでやっていたのですが、どうもQuickTimeの方が階調が豊かに出るようです。もちろんビットレートなどの条件によるので一概には言えませんが、編集環境がMacで閉じるならば標準でついて来るQuckTime Playerの方が最初から強制的にMOVに変換して表示してくれるので楽だと思いました。

iMovie上では多少の画像処理ができます。ホワイトバランス、Brightness、コントラスト、レベル補正に相当するもの(ただしRGBまとめて)、彩度、カラーバランスくらいでしょうか。ないよりは遥かにマシですが、やはり少し物足りません。本当は動画上でトーンカーブがいじれればもう少ししまった仕上がりにできたのかもしれませんが、無料のiMovieにそこまで求めるのは酷かもしれません。Premireクラスだとそういったこともできるのでしょうか?他にも、タイトルとかキャプションももう少し豊富だとありがたいと思いました。

タイトルです。シンプルなものを選びました。

vlcsnap-2018-06-14-09h01m27s072

最初の動画は、歩いて行くと一番初めに見えてくる川べりです。いつもはここはそれほど飛んでいないのですが、今年は大量に飛んでいました。さすがに暗いのである程度ノイジーになってしまいます。

vlcsnap-2018-06-14-09h04m31s508


娘のNatsuの手の中で遊んでいるところです。捕まえると小さい子とが寄ってきます。ここは地区を挙げてホタルを保護しているところです。当然ですが、すぐに逃がしてあげます。持って帰るようなことをする人は見たことがないです。地域の方とおしゃべりすることができるのもこの場所の魅力でしょう。ここまでがASI294MCとNIKKOR50mmでの撮影です。

vlcsnap-2018-06-14-09h05m32s269


水路のところの遠景と近景です。この景色が一番好きかもしれません。この2ショットはASI294MCとNIKKOR35mmで10FPSでの動画です。初日でビニングも思いつかなかった、まだ試行錯誤段階の時です。

vlcsnap-2018-06-14-09h06m26s747


次が前回も出した比較明合成のために撮ったもののタイムラプス映像です。EOS 60DとシグマのF3.5, f10-22mmです。

vlcsnap-2018-06-14-09h07m32s302

再びASI294MCとNIKKOR50mmで動画撮影です。かなり暗くて相当厳しいです。

vlcsnap-2018-06-14-09h07m15s043


最後がASI294MCシグマのF3.5, f10-22mmでの天の川撮影です。天の川はそこそこ出ているのですが、調整不足で周辺がかなり流れてしまっています。

vlcsnap-2018-06-14-09h06m48s740


さて、実際の動画ですが、下がYouTubeにアップしたものになります。まともに動画を編集しようとしたのは今回が初めてで、YouTubeへのアップも初めて少し真面目にやって見ました。推奨のH.264で15Mbpsでアップしましたが、それでもやはりオリジナルのものからは、特に階調と細部描写は多少落ちてしまっているようです。ここら辺はもう少し最適化の余地があるかと思います。




この動画を作るにあたって、ホタルの動画を検索しましたが、ホタルが飛んでいる動画を、リアルタイムかつ明るく、なめらかに撮っているものはそれほど多くは無いようです。いくつかSONYのα7Sで撮影しているものが見つかりましたが、暗いものも多いです。センサー自身はASI294MCよりα7Sの方が高性能のはずなのですが、ASI294MCは計算機を必要とする代わりに、ビニングなどの微調整をPC上でできるのが有利に働いているのかもしれません。それでもいくつかはα7Sで綺麗に撮れているものがありました。レンズなどの機材や撮影技術にももちろん依るのかと思います。あと、NIKONのD800で今回の私と全く同じ場所を撮った素晴らしい動画がありました。この方は動画編集にAdoveのPremireを使っているようです。ものすごく綺麗な画質で出ています。

私も相当昔、まだ学生の頃、動画処理がやっとできるかどうかという時代に秋葉原の当時のTSUKUMOでIEEE1394カードと、SCSI3(!)接続の不思議な格安の10GBの大容量(笑)HDDを買って、そこについてきたPremireを使って動画編集をしていたことがあります。今ではもうほとんどどんな機能だったか忘れてしまいましたが、その当時から飛び抜けて高機能だったので、今もすごいのかと想像してしまいます。高感度カメラもどんどん一般になって来るので、将来はもっと楽に取れるようになるのかと思います。



今回の反省点です
  • いくつかのホットピクセルと思われる輝点が出てしまっています。露光時間も感度も決まっているので、ダーク補正をリアルタイムするべきでした。
  • ASI294MCにZWOのCanonレンズアダプターを付けて、さらにNIKORレンズにCanonアダプターを付けて撮影しています。そのため周辺がボケまくってしまいました。レンズからセンサー面の距離をきちんと調整していないためかと思われます。あと、少しガタがあるので間にテープなどを詰めてガタつかないようにしなくてはいけません。
  • 動画はASI294MCが適していますが、比較明合成するための20秒程度の長時間露光はEOS 60Dの方が楽だと思いました。当たり前ですが計算機など必要無く単体で撮ることができます。露光時間をかけることができ、画像処理もじっくりできるなら、わざわざCMOSカメラで撮る必要はないという意味です。動画の場合は高感度センサーのASI294MCの方が圧倒的に有利です。

反省点は多々ありますが、今回初の本格的な動画編集で、念願のホタル動画が撮れたこともあり、結構満足です。

ちなみに今日は自分の誕生日。いつのまにやらもう46です。家族には先週末に祝ってもらい、物は赤道儀をかなり前に先物買いしてしまったので、この動画は自分自身の誕生日記念になりそうです。


 

最近悩んでいるのが、動画スタックによる画像の分解能の限界です。まだあまりよくわかっていないのですが、とりあえず簡単なことから始めようと思います。今回知りたいことは、そもそも「動画スタックでドーズ限界を超えることができるのかどうか」。印象としてはそんなんとっくに超えてるんじゃない?と勝手に思っていたのですが、実は確かめたことはなかったので、少し検証してみました。

IMG_9336



まずドーズ限界を感覚的に知るために、木星がもしドーズ限界で制限されるとしたらどのような画像になるかを試してみました。元画像はハッブルで最近(2018/4/25)撮影されたのものです。

JupiterOpal_HubbleMasztalerz_1880

検証するには十分な解像度があります(実際の画像は上の画像をクリックして拡大して見てください)。NASAの画像は著作権を主張していないとのことで、このようにブログでも使うことができるのでありがたいです。


これを手持ちのC8の画像と比べてみます。下は去年の惑星シーズン(2017/6/8)に撮影したもの。口径200mmでASI224MCを使いました。C8としてはそれほど悪い方でもなく、ちょっと頑張ればここら辺までは出るくらいかと思います。カメラがASI224MCでカラーなので、モノクロでL画像を撮ればもう少し改善の余地はあると思います。
2017-06-08-1241_5-RGB2


まずはドーズ限界による分解能を計算します。ドーズ限界は

115.8 / D [秒]

で表され、Dは口径をmmで表したものです。C8は口径203mmなので

115.8 / 203 = 0.570秒

となります。木星の視直径は変化しますが、撮影当時の視直径は調べてみると39.6秒だとのことです。なので、木星の直径を39.6/0.570=68.4ドットで表せばいいことになります。

Hubbleの画像の木星の直径(画面全体ではないことに注意)がキリのいい68ドットになるように画像の解像度をPhotoShopで落とし(その際、見かけが近くなるように彩度を落とし、上下逆にしました。)、その後、元のドットになるようにバイキュービック法で再び解像度を上げました。その結果がこちらになります。

JupiterOpal_HubbleMasztalerz_1880_200mm2

自分でC8で撮った上のものと比較してみると、ざっくりいって、ドーズ限界と同じかもう少し悪いくらいの分解能だったことがわかります。うーん、では状況がいいとドーズ限界に近づいていくのか、それでも超えることはないのか?もう少し検証してみます。


次にC14を想定して、355mmの口径の場合で、最近の木星の視直径44.1秒を仮定してドーズ限界での画像を再現してみると

JupiterOpal_HubbleMasztalerz_1880_355mm

くらいになります。これだと木星の直径を136ドットで表すことに相当します。ところが、例えばC14で最近撮影された日本の惑星撮影で代表的な「RB星のブログ」さんの2018/4/21の画像(RB星さんのご好意で掲載許可をいただきました)

j180421s1

と比べると、明らかにドーズ限界を超えて綺麗に見えています。この日はシーイングがベストではなかったとのことですが、C14では最高峰に近い木星画像かと思います。

ちなみにドーズ限界を1.5倍くらいよくしたものが

5

になりますが、これくらいだとだいたい同じくらいか、まだ撮影した方が少しいいくらいでしょうか。高々1.5倍の解像度増ですが、見え味は相当よくなるのがわかります。ちなみに今回の場合、2倍だと明らかに良くなりすぎてしまうので、条件が整えばドーズ限界の1.5倍から、2倍くらまで迫ることが出来そうだということがわかります。

うーん、でも個人的にはドーズ限界なんかはもっとはるかに越えていけるのかと勝手に思っていました。意外に近い結果でしたが、まあ考えてみれば光学的には回折限界から来ているので、当たり前かといえば当たり前ですかね。

ただし、波長によっても分解能は違うはずで、PhotoShopでRGBにチェンネル分解し波長に応じてドーズ限界を求めて再びチャンネル統合して試してみたのですが、Rが解像度が悪くなり、Bが解像度が良くなるので、結果的には相殺しほとんど見た目の影響はありませんでした。なので、上の画像には波長の依存性は入っていません。

こうやってみると、やはり口径の効果は大です。他の素晴らしい成果を出している方々の画像を見比べてみても、C8よりC11、C11よりC14の方がより精細なところまで描写できているので、やはりドーズ限界のような光学的な限界がまだまだ効いていると言えるでしょう。ここにシンチレーションなどの効果が邪魔をしているので、現在の手法はそのシンチレーションの効果を除き、いかに光学的な限界まで迫るのかという状況なのかと思われます。

では他に何が関わってくるかというと、例えばシンチレーションの軽減には
  • 露光時間(転送速度とも関係あり)
  • スタック枚数
などが関わり、ノイズには
  • カメラの感度
が関わってくると言えるでしょうか。カメラをモノクロにしてLを撮影してさらに解像度が上がったりもしているので、感度も解像度に効いてくると思うのですが、まだそのメカニズムがよく理解できていません。また、C14くらいの口径では
  • カメラの解像度
は今回の検証から考えるとまだまだ余裕がありますが、さらに大きい口径だと解像度が効いてくるようになるのかと思います。あと大きな効果は
  • 画像処理
でしょう。特にRegistaxなどのWavelet処理は見た目の解像度に大きく影響します。

さて、モノクロカメラを買うかどうか。まだ結論は出てませんが、まずは今のカラーカメラで口径を250mmで撮影してみて、去年の結果を超えることを目標にして、その結果が出てから考えます。



このページのトップヘ