ほしぞloveログ

天体観測始めました。

タグ:ASI294MC

球状星団を撮影するのは初めてになります。今回、ヘルクレス座の球状星団M13をTSA120を使って撮影してみました。全天で最も美しい球状星団と言われています。


初の球状星団撮影

連休初日に入るこの日の夜、天気は悪くなく、夜中から天の川を撮影しようと思っていたのですが、それまでの繋ぎでM13を撮影してみることにしました。よく考えたら、球状星団をまともに撮影するのは初めてのことです。もちろん、眼視や電視観望などでの簡易撮影などはあります。それでも時間をかけてまじめに撮影するのは初めて、いろいろわからないことがありそうです。
  • そもそも、撮影時間はどれくらいがいいのか?星雲ほど長くなくていいのか、それともやはり長ければ長いほどいいのか。
  • 1枚あたりの露光時間はこれまで通り5分でいいのか?
  • QBPはあってもいいのか?無いほうがいいのか?

天の川が出てくるまで1時間ほどあります。最初なのでとりあえずこれまでの星雲撮影のセッテングをベースとして、撮影時間を1時間としてみました。

撮影は順調。PHD2とAPTで、ガイドも含めて特に問題はなかったです。ちょうど同じ時間帯に、あぷらなーとさんもM13を狙っていたみたいです。


画像処理と結果

球状星団の画像処理も初めてのことで、まだ全然慣れていません。疑問だらけで、また太陽映像に取り掛かっていたこともあり、時間がかかってしまいました。

星雲の場合と違って、いじればいじるほど処理の跡が目立つような感触です。なかなかごまかしが効かない、素材の出来具合がそのまま処理後の出来に直結するような気がしました。とりあえず処理した結果です。



「ヘルクレス座球状星団M13」
light_BINNING_1_integration_ABE_PCC_STR2_cut
  • 撮影日: 2020年4月29日0時24分-1時23分
  • 撮影場所: 富山県富山市下大久保
  • 鏡筒: Takahashi TSA-120 + 35フラットナー + サイトロン QBP (48mm)
  • 赤道儀: Celestron CGEM II
  • カメラ:  ZWO ASI294MC Pro
  • ガイド: PHD2 + f=120mmガイド鏡 + ASI290MMによるディザリング
  • 撮影: ATP、ゲイン220、温度0℃、露光時間300秒x11枚 = 55分 
  • PixInsight、Photoshop CCで画像処理
中心部です。

light_BINNING_1_integration_ABE_PCC_STR2_center

今調べたら簡易撮影では、星を始めて一番最初に撮影したメシエ天体がM13 M3(2020/5/16訂正:玄さんのコメントのおかげで4年を経てM3と気付くことができました。玄さん、どうもありがとうございました。)でした。星を始めて、一眼レフカメラを手に入れてすぐのM13 M3がこれ。1枚撮り、中心からずれてる、星がぶれてる、画像処理も何もしてない。さすがにこれを見ると、4年間で進歩したと思えます。でも望遠鏡とカメラでメシエ天体が写っただけでも、ものすごく嬉しかったこと覚えています。

IMG_0326



反省点色々

最初は、初めてにしてはそこそこ中心部まで見えたのかなと思っていました。でもやはりまだまだですね。以下、反省点です。
  • 一つ一つの星像が大きい。もっと分離してもいいはず。
  • 星雲みたいに背景を出す話ではないので、構成を分離するStarNet++が意味をなさないはずです。今回は試すこともしませんでしたが、背景のノイズを減らすのには役に立つかも知れません。今後の課題とします。
  • 背景のノイズを無くそうと、DeNoiseやDfine2も試しましたが、見事に恒星の不自然さを強調します。今回は試しただけで、結局使いませんでした。
  • 炙り出していくと、背景ノイズがまだ多いです。今回はトータルで1時間弱の撮影だったので、もう少し総露光時間を増やしていいかもしれません。
  • すでに炙り出しすぎの感もあります。中心部から少しずれたところなんかは、微光星なのかノイズなのか見分けがつかなくなってきます。
  • 明るい恒星の裾部分の階調が少し不足しています。微光星を出そうとするとこうなってしまいます。もう少し中心部の微光星を抑えても良かったかも知れません。
  • 同様に、左上に写っている銀河も階調不足の感があります。
  • 中心部の画像を見ると、色が白、オレンジ、青緑と3系統にはっきり分かれています。現実は多分そんなことはないので、何かおかしな画像処理過程が入っているようです。それともQBPのせいでしょうか?
  • やはりまだ決定的に分解能不足です。というか、星が肥大化しています。これは画像処理以前の撮影時の問題です。
画像処理以前のこととして、決定的だと思ったのは、一枚の撮影時間の5分が長すぎたではないかということです。長時間露光はどうしてもブレが積分されるので星像がボケてしまいます。もちろんシンチレーションとか風の揺れによるのですが、1枚は1分程度に抑えて、枚数を増やした方がいいのかも知れません。

揺れに関して少し考えてみます。撮像の揺れ時間スケールで見ると
  • 秒以下の揺れ: シンチレーション、地面の揺れ、風による機材の振動
  • 1秒程度の揺れ: 風
  • 10秒周期以上の揺れ: 赤道儀のピリオディックモーション、機材のたわみ
などがあります。
  • この中で改善できるのは10秒以上の揺れのみ。オートガイドです。それでも1時間オーダーではたわみが問題になってきます。
  • 1秒から10秒程度の揺れはオートガイドで多少は抑えることができますが、速い揺れほどその効果は小さくなります。
  • 秒以下は今のところ打つ手なし。AOを使うことで、シンチレーションみたいな画面の中で揺れるもの以外は改善できます。でもAO高いです。自分で作ることを考えた方がいいかも知れません。
このように考えるとすぐにわかるように、一枚あたりの露光時間を1分程度に短くしても大した効果はありません。ただ、揺れの大きさで考えると、突風などの突発的事象で星像が肥大することはあり得るので、露光時間を短くしてそれらの揺れの大きいものを省くことはできます。ラッキーイメージの考え方ですかね。

さらに、カラーCMOSカメラで撮影していることも分解能を低下させている原因の一つです。モノクロの冷却CMOSカメラでそこそこのセンサー面積のものをそろそろ本気で考えた方がいいのかも知れません。

少なくとも今回の結果は、TSA-120のが持っている光学的な分解能には全く達していないと思います。


おまけとまとめ

最後にいつものアノテーションです。少しだけ斜めになってました。念のため再度ImageSolverで計算したら回転のズレ結果は0.41度でした。上が北で、経線が縮まっていくので上の方が間が小さくなっていまるので、より斜めに見えてしまっているようです。

light_BINNING_1_integration_ABE_PCC_STR2_Annotated

本当はこの撮影の後に天の川が登ってくる時間になり、中心部の干潟とか三裂星雲を狙おうとしていたのですが、外に出たら曇り。この日は撤収しました。

画像処理まで進めて、まだまだ改善の余地がたくさんあることがわかりました。球状星団は撮影時の条件がそのまま出てごまかしが来なさそうです。今回の撮影の後、もう少し試したくて、別の日にVISACで長時間撮影してみました。 これはまた次の記事で書きます。


 

今回はAPT(Astro Photography Toos)とPHD2を使って、CMOSカメラでディザーをしながらガイド撮影をします。以前にもAPTを何度か試したのですが、いずれも長続きせず結局使わずじまいでした。


縞ノイズとディザー撮影

長時間露光撮影をしようとすると、ディザーが必要になります。たとえガイドをしていても、ガイド鏡や鏡筒のたわみなどでどうしても相対的にズレが生じてしまい、視野が1時間とかのオーダーだとかなりズレていってしまいます。その結果何が起きるかというと、画像処理の段階で盛大な縞ノイズ(縮緬ノイズ)に悩まされるわけです。前回の記事で紹介した4日間撮影したバラ星雲も、初日のガイドなしでは以下のような縞ノイズが画面全体に出てしまいました。



integration_DBE_PCC_AS_cut

この縞ノイズは多少の画像処理ではどうしようもありません。ある程度の軽減はできますが、少なくとも私は最終画像に持っていくまで影響のないくらいにすることができていません。

あぷらなーとさんが以前面白いアイデアで縞ノイズの除去に成功しています。その結果がFlatAidProに反映されているとのことなので、FlatAidProに通すことも一つの解です。無料版でも画像サイズ制限なしで使うことができます。今回実はFlaAidProで試して、細かい縞ノイズは結構きれいに消えたのですが、下の画像のように元画像で恒星中心などのサチりぎみの箇所が、流れたラインに沿って大きなスクラッチのようになってしまったので、今回は諦めました。

light_BINNING_1_integration_Preview01

なんだかんだ言って、縞ノイズを確実に解決するのは、ソフト側で苦労するよりは、今のところディザーが一番手軽なのかと思います。

さてディザー撮影ですが、一眼レフカメラの場合は、私は6DなのでBackyard EOSを使うことで、PHD2と連携してディザー撮影が簡単にできます。しかしながらCMOSカメラはこれまでほとんどSharpCapですませてきて、せいぜいlivestackで短時間撮影を重ねたくらいで、大した長時間撮影はまともにはしてきませんでした。今回COMSカメラでどうやってディザーを実現しようか色々と考えてみました。


SharpCapでのディザー撮影

最近のSharpCapはディザー撮影もサポートしていますが、なぜかこの機能livestackの中でのみ動きます。少し試したのですが、どうもまだこなれきっていないようで、ディザーをするタイミングを「何秒ごと」としか決められないようです。

ディザーのスタート自身は、そのフレームの撮影が終わるまで待っててくれるらしいのですが、ディザーをしている最中もカメラは動いていて撮影はし続けているようです。その間に撮影した画像はぶれてしまうために捨てざるを得ません。ディザーが止まって、そのフレームの撮影が終わってから改めて撮影を始めたフレームがやっと使える画像になります。マニュアルによると、ディザーの際中の画像はlivestackでスタックされることは無いと書いてあります。逆にいうとやはりディザー中も撮像は続けられていてその撮像時間を一枚だけ変えるとかはできないので、無駄になるとわかりつつもディザー後その画像の撮影終了時間が来るまで待つしかないということのようです。

具体的には、livestackの中の機能で、個々のフレームを全て保存するというオプションがあり、これをオンにするとlivestackモードでも通常の撮影のように使うことができます。問題は、短時間露光撮影ならまだそこまで無駄にはならないのですが、例えば5分とかの長時間露光をすると、数十秒のディーザーのために丸々5分の画像を取り終わるまで待って、次の画像を使うことになります。なのでディザーしている時間以上の露光時間で撮影する時には、撮影効率は必ず50%以下になってしまうというわけです。

基本的にはSharpCapのディザーはlivestackの中の一機能だけの役割で、せっかくスタックした画像をディザーで乱さないための機能ということになります。

うーん、さすがにこれはもったいないです。もっとうまいやり方があるのかもしれませんが、少なくとも私にはうまい回避方法が見つかりませんでした。何かいい方法があったら知りたいです。

とりあえず今回はCMOSカメラでの長時間露光をする必要があったので、この時点でSharpCapでのディザー撮影を諦め、兼ねてから使ってみたかったAPTに、少なくともCMOSカメラのディザー撮影に関しては、プラットフォームを移行することにしました。


APTのインストール

以前にもAPTのインストールについては書いていますし、日本語でも随所に解説されているので詳しくは書きませんが、ポイントや気づいたことをメモがてら書いておきます。

まず今回の目的で、ガイド撮影のためにPHD2は必須なので、これはインストールしておきます。

PHD2もそうですし、APTもそうなのですが、ソフト間と各機器を相互接続するためASCOM関連のソフトが必要になります。まずはASCOMプラットフォームをインストールしておきます。この際、.NET framework 3.5が必要になります。後でAPTをインストールするときに.NET framework 2.0が必要になるのですが、.NET framework 3.5は2.0も含んでいるのでAPTより先にASCOMをインストールしておいた方がいいです。.NET framework 3.5インストール後は一度Windowsの再起動が必須です。OS再起動後、再度ASCOMプラットフォームをインストールしてみてください。

ASCOMプラットフォームインストールさらに、もう一つ。のちにAPTのplate solvingで赤道儀をいじりたくなるはずなので、各メーカーに合った赤道儀用のASCOMドライバーも入れておきます。

あ、CMOSカメラを初めて使う場合は、カメラのドライバーも必要になります。これは各メーカーのページからダウンロードしてインストールすればいいと思います。例えばZWOならここです。同ページのASCOM用のドライバーですが、APTにおいてはもう必要無いようです。APTの履歴を見てみると2019年12月以前のバージョンのAPTでは、ZWO社のASIカメラはASCOMカメラとして認識されていたのですが、それ以降のバージョン3.82からはASIカメラをネイティブドライバーで動かすようになっているとのことです。

ここでやっとAPTダウンロードして、インストールします。とりあえずは評価用のデモ版でいいでしょう。デモ版でもほとんど全ての機能が使えます。ダウンロードと同じページに日本語化するファイルや、日本語のマニュアルもあるので便利です。これは星見屋のM店長がご尽力されたおかでです。

インストール完了後、さっそくカメラを繋いで立ち上げてみましょう。最初はわかりにくいので、昼間にやってみることをお勧めします。できるならこの時点で赤道儀もPCとケーブルで繋げておくといいでしょう。


APT動作のポイント

最低限ディザー撮影を始めるまでに必要なことを書いておきます。たくさんの機能があるのですが、必要なことはそれほど多くはありません。

まず立ち上げると自分が今いる位置の座標を聞かれます。デフォルトはグリニッジ天文台になっているので、実際に撮影する場所の緯度経度入れます。最初にめんどくさくてキャンセルしてしまった場合は、「Tools」タブの「APT Settings」から「Location」タブに切り替えて設定できます。

この「APT Settings」ですが、最初はほとんどいじる必要はないです。唯一いじったところが「Main」タブの「Images Path」くらいです。これもデフォルトでよければ触らなくてもいいです。少なくとも撮影まで持っていけます。

他にも「Tools」タブにはたくさんのボタンがありますが、ほとんどは使わなくても撮影までは辿りつけます。実際にはピント合わせの時に「Magnifier」を使ったくらいでしょうか。「LIve View」と合わせて星を拡大してピント合わせをしました。「Focus Aid」とかもあるのですが、拡大できなかったり、下手にスタックしてしまったりでピントを触った時のブレの影響が出てしまい、あまり使い勝手は良くなかったです。

CMOSカメラを繋いで、「Camera」タブから「Connect」を押すとカメラが動き出します。ガイド用にもカメラを繋いでいる場合、撮影用のカメラと合わせてCMOSカメラが2台になります。たまにガイドカメラが選択されてしまうことがあります。でもこれ結構気付きにくて、例えばピントを合わせようとしても全然星が見えなかったり、見えていても変化しないとかで、やっと気づいたりします。その場合は「Camera」タブの一番下の「Setting」ボタンから選択できます。

冷却する場合は下のほうにある「Cooling Aid」を「Warming Aid」が有用です。ゆっくりと冷やしたり温めたりするので、カメラへのショックが少ないでしょう。

とりあえずは赤道儀の自動導入で撮影したい天体を導入します。導入後の位置が多少目的のものとずれていても構いません。次の「goto++」で自動で位置調整できます。

「Gear」タブで赤道儀との接続をします。上で書いた赤道儀用のASCOMドライバーをインストールしてある必要があります。「Connect Scope」ボタンで赤道儀が接続できたら、早速同じエリアにある「Point Craft」を押してAPT最大の特徴のgoto++を試してみましょう。

ここで必要なことは、一番下の「Settings」ボタンを押して「PlateSolve 2」と「All Sky Plate Solver(ASPS)」をインストールしてきちんとパスを設定しておくこと。ダウンロードをどのページからすればいいかも、リンクが張ってあるのですぐにわかるかと思います。PlateSolve 2は本体と「UCAC3」のみでいいです。「APM」はなくても動きます。UCAC3はPlateSolve 2をインストールしたフォルダの中に入れてください。そうでない場合は一度PlateSolve 2を立ち上げて、FileメニューからUCAC3をインストールしたフォルダを指定する必要があります。これら2つのインストールはあらかじめ昼間に済ませておいた方がいいでしょう。

ここまででgoto++を試す準備ができたら、「Point Craft」スクリーンに戻って、「Objects」か「Scope Pos」を押してざっくりとした座標を入力します。大画面右上の「Shoot」ボタンで一枚撮影して「Solve」か「Blind」ボタンを押します。うまく解析が終わると、画面真ん中に丸が出てきます。「Sync」ボタンを押しておくと、今の位置が赤道儀に送られ同期し、その方向を向いていると認識します。

次に「Aim」ボタンを押すと別の丸が出てきて、マウスを移動したいところに持っていってクリックすると、2つ目の丸が移動します。その後「goto++」を押すと、その位置が中心になるように赤道儀を移動してくれます。勝手にもう一度撮影するので、本当にその位置に移動できたかどうかわかります。


ディザーガイド撮影

希望通りの構図になったらPHD2でガイドをはじめてください。そういえばPHD2の解説ってあまり詳しいのはしたことがないですね。ずっと昔まだ撮影を始めたばかりの時の記事がありますが、古くてあまり役にたたなさそうです。PHD2はHIROPONさんのページで解説されていますし、同ページから同じくHIROPONさんが書かれた日本語のマニュアルもあるので、特に問題はないと思います。

必要なのはPHD2で「ツール」(Tools)メニュー下の「Enable Server」をクリックしておくこと。これでAPTから自動的にディザー時にガイドを止めてくれるはずです。

APTでのディザーの設定は、「Gear」の赤道儀設定のとことにある「Guide」ボタンから。一番上の「Guiding Program」は「PHD」になっているので、今回は「PHD2」に変更。上から二番目の「Auto Dithering」はオンに。振幅がデフォルト値だと小さすぎて縞ノイズが回避できない可能性があるので、「Guiding Setting」スクリーンで、上から三番目の「Dithering Distance」をデフォルトの1から4くらいに大きくしておきます。これで準備完了です。

実際の撮影はメイン画面の「Camera」タブから「LIGHT PLANS」の「Test」とか選んで、横の「Edit」を押して、「Plan to edit」のところを「Add New Light Frame Plan」で新規プランを作って、露光時間とか枚数とか入れていきます。

PHD2がきちんとガイドをしているなら、あとはAPTの「Camera」タブの「Connect」ボタンのすぐ横の「Start」ボタンを押します。もし「Start」ボタンが押せない場合は、カメラが接続されていないとか
Live Viewがスタートしているとかです。「Camera」タブの「Connect」ボタンがきちんと「Disconnect(これが繋がっている状態を表してます)」になっているか、「Live View」ボタンの色が濃くなっていないか(ボタン背景が黒の場合がLiveViewがオフです。)確かめてみてください。正しい場合は「Start」ボタンの背景が濃くなっているはずです。

実際にディザーされているかどうかは、「Gear」タブの「Guide」のところに「(D)」が出ていれば大丈夫です。念のため何枚か撮ったら、「Img」タブで撮影できた画像をダブルクリックして、星がきちんと動いているか確認してみてください。


APTを使ってみての感想、SharpCapとの違いなど

実際にAPTを使ってみると、随分とSharpCapとのコンセプトの違いを感じます。撮影に特化した感じです。
  • 例えば、撮影した画像をできるだけ無駄にしない努力が随所にされているのは好感が持てます。保存形式は、プレビュー に当たる「Shoot」を除いて、基本Fits形式のみです。撮影中は必要のないボタンは押すことができないようになっています。ディザーもPHD2が動いていれば基本的にはデフォルトでオンになるので、オンにし忘れたとかで撮影画像を無駄にしなくて助かります。
  • SharpCapに比べるとAPTはディザーのオプションもしっかりしていますが、ディザーパターンは選べないようです。ランダムだけのようです。一方、PHD2にはランダムかスパイラルかを選べる項目があります。どちらが優先されるのでしょうか?まだよくわかっていません。
  • SharpCapとの違いを感じたのは、露光時間とゲインの調整がしにくいことでした。実際に移す画面は「Live View」ボタンを押せば見えるのですが、実際の露光時間とゲインは数字で打ち込むか、Ringy Thingyと呼ばれる小さな丸いジョグダイアルのようなもので合わせる必要があります。SharpCapのスライダーが秀逸だったことがわかります。
  • Live ViewはさすがにSharpCapの方がはるかに高機能です。パッと触っただけでも、APT側はカラーバランスが取れない、livestackは当然ないなどです。APTにもオートストレッチは一応あります。「Tool」タブの「Histogram」でヒストグラムを出し、「Auto-Str L」を推します。ただ、調整幅が少なく操作性がいまいち、かつこのヒストグラムも輝度しか見えなくて、カラー情報はわかりません。逆に言えば、写っている画面はあまり気にさせずに、撮影にすぐに入って欲しいという意図が感じられます。ShapCapの経験から行くと、カラーバランスによってはADCの範囲に入ったり入らなかったりするので、少し気になりますが、まあ大丈夫なのでしょう。(2020/4/16 追記: APT Settingsの CCD/CMOS settingsタブのRed Channel Color BalanceとBlue Channel Color Balanceで色のバランスを取ることができるのがわかりました。保存されるRAWファイルには適用されず、見た目だけのバランスのようです。また、Auto Stretch Factorをいじると、デフォルトのオートストレッッチの強さを変えることができるので、これで合わせると程よい明るさで見ることができそうです。)
  • とにかくAPTは撮影に特化していると思っていいです。これと比べるとSharpCapの撮影へのこだわりはまだ中途半端に見えてしまいます。短時間撮影や、Live Stackを使ってのラッキーイメージ撮影など、ガイドを使わない撮影ならSharpCapの方がいいかもしれませんが、長時間撮影はAPTの方が遥かに向いています。逆に、APTで電視観望は無理だと思いました。カラーバランスが取れないとか炙り出しが全然甘いとかです。

APTとSharpCap2本のソフトを使いわけることで、撮影と電視観望の切り分けがきちんとできるようになるでしょう。


Demo版と有料版の違い

さてAPTですが、最初はデモ版を使っていました。無料のデモ版でもほとんどの機能は使えるようです。無料版でさえもこれだけの機能が使えるのは素晴らしいことです。

有料のフル版とのちがいはこのページの一番下の緑の字になっているところに載っています。少なくとも撮影を始めたばかりの人ならデモ版でも困るようなことはほとんどないでしょう。フル版で気になる機能はObject選択のところで星や星雲星団が見やすくなるかとか、PiontCraftの結果を残せれるかとかくらいでしょうか。無料版とあまりさをつけていないところはユーザーの間口を広げる意味でも好感が持てます。もっと使い込んでいく場合には撮影用のスクリプトとかも有料版のみサポートされているらしいので、違いが重要になってくるのかもしれません。

でもこれだけの機能にして18.7ユーロ。日本円にして2千円ちょっとなので、私は感謝の意味も込めてフル版にしました。ヒストリーを見てみると4ヶ月ほど前にZWOのカメラがネイティブでサポートされたとのことなので、いいタイミングだったかもしれません。そう言えば以前はASCOM経由でのカメラの接続確認画面がAPT画面の裏に隠れていて苦労したのですが、今回はカメラの接続は普通に行われていて特に困った覚えがないです。


まとめ

なかなか使うことができなかったAPTですが、今回CMOSカメラのディザー撮影という必要に迫られてやっと使うことができました。使ってみると素直なソフトで、操作性も悪くありません。何より、撮影画像をミスとかで無駄にしないという方針みたいなのが随所に見えたのは素晴らしいです。

これ以降、CMOSカメラでの長時間ディザーガイド撮影もどんどん進めていきたいと思っています。とりあえずはTSA-120とフラットナーにASI294MC Proをつけての撮影ですかね。


シベットさんが最近フィルターを使った電視観望を盛んに試されています。私のところにも31.7mmのアメリカンサイズのQBPフィルターが届いたので、ずっと試したかったテストをしてみます。


アメリカンサイズのQBPができた!

そもそもは昨年9月にQBPを使って電視観望をするとどれくらい見えるようになるかというテストをしたことに始まります。



この時の結論はHαで見えている赤い星雲はQBPによって相当見やすくなる一方、プレアデス星団などの青い星雲や白色光に近い系外銀河はむしろQBPによって電視観望では見えにくくなってしまうというものでした。なので、見る対象によってQBPをつけたり外したりするといいのですが、48mm版のQBPはFS-60CBの鏡筒とフラットナーの間に入れてあって、なかなか取り外しにくいのです。

そんな折、ちょうどBLACK PANDAさんからTwitter上でQBPの新バージョンができるというアナウンスがありました。なんでも基材を合成石英にアップグレードするということです。これまでの基材が何かはわからない(2020/2/3追記: B270だそうです。)のですが、合成石英は研究レベルでもよく使われ、熱膨張が少なく、紫外、赤外共に透過率が高かったりします。

上のブログの更新時のTwitterでのアナウンスでBLACK PANDAさんがコメントをくれ、「QBP入れ替えができるように、CMOSカメラに直接つけることができる31.7mmサイズがあればいいなあ」とか返事をしたら、なんと本当に反応してくれました。新バージョンを作る際に、31.7mmバージョンも作ってくれるというのです!これは期待大です。

合成石英を使用した新バージョンのQBP自身は11月半ばにできたと記憶しています。その時のものは元と同じ48mmサイズでした。その後、つい先日の1月29日、とうとう新バージョンの52mm版と、まさかまさかの31.7mm版が本当に発売されたのです!約束を守っていただいて本当に嬉しいです。BLACK PANDAさんどうもありがとうございました。

しかも値段を見ると、アメリカンサイズはこれまでの約半額、税抜きだとなんと1万円切りです。これならユーザーとしては気軽に試すことができるので、大変嬉しい価格設定です。

さらにここから話は急展開します。なんと製品を送るのでテストで使って欲しいとのこと。願いまで聞いていただいて、しかもサンプルも送っていただけるとは!

というわけで、送っていただいた新型のアメリカンサイズのQBP、やっと昨晩テストを敢行することができました。


31.7mmのQBPが生きるところ

フィルターサイズが小さくなって一番良かったのは、CMOSカメラに直接取り付けたり、フィルターホイールに入れたりできるところでしょうか。センサーサイズ的にはフォーサーズまでは使うことができるはずです。電視観望でよく使うASI294MCならば大丈夫でしょう。

もともとはASIカメラについている前に出ているアダプター

IMG_9368


に取り付けることを考えていましたが、年末の名古屋年越し観望会の智さんのレデューサートラブルの検討のときのコメントで「ASI294MC Proについていた薄いアダプターに31.7mmフィルターを取り付けるこができる穴が開いていて、以前よりも飛び出ることなくセンサーに近いところにフィルターを取り付けることができる」ということを教えてもらいました。

実際にASI294MC ProにQBPを取り付けると下のようになります。

IMG_9308

これまでは鏡筒に取り付ける時のみQBPを利用することができました。これならば、一眼レフのレンズをASIカメラに取り付ける時にも、アダプターの中に十分スペースがあるので、広角レンズを使ってもQBPを試すことができます。シベットさんはすでに同様のことを各種フィルターで試しているようなので、私も今回チャレンジしてみます。

今回は上の写真のように、古いオールドNIKKORの50mm/f1.4の明るいレンズにCanonレンズのアダプターをつけて、そこにさらに、ZWOが出しているASIカメラにCanonレンズを取り付けることができるアダプターを取りつけています。そのアダプタの空間にフィルターがうまく収まっています。

IMG_9309


明るいレンズとQBPを組み合わせての電視観望

さて、土曜の晩晴れた際にTSA-120のファーストライトの合間を縫って、このセットアップで電視観望を試しました。ポイントは焦点距離が50mmと広角なので、赤道儀やAZ-GTiさえ使う必要がなく、ただの三脚と自由雲台に載せただけで、手で動かすだけで見たいところを見ることができます。

IMG_9311

このセットアップ、本当に超手軽です。ぱっと持ち出してPCとケーブル一本繋ぐだけです。

もう一つのポイントは、f1.4の相当明るいレンズを使っていることです。以前ASI294MCを最初に手に入れたときその後何度か明るい広角のレンズを使って電視観望をしています。それでも十分に見えたのですが、明るすぎるレンズは画面が飛ばないように露光時間やゲインを抑える必要があるので、星雲なども当然見えにくくなってしまいます。今回はQBPを使って光害をカットしているので、星雲のコントラストが上がり見えやすくなっています。しかも明るいレンズのために露光時間をそこまで伸ばさなくても、十分情報を得ることができ、リアルタイム性に一役買っています。


実際の見え方

実際の見え味ですが、結構衝撃的です。まずは1.6秒露光のライブスタックなしのオリオン座です。

IMG_9322

真ん中に三つ星が映っているのがわかると思います。すぐ下のオレンジの明るいところがM42オリオン大星雲になります。繰り返しますが、これわずかトータル時間で1.6秒だけ露光したものです。三つ星の一番左のところに馬頭星雲らしきものがうっすら出ています。それどころか、よく見るとバーナードループ まですでに出ています。

これを24枚スタックしたのが次の写真です。あ、写真は全てPCの画面をiPhoneで写しているだけなので、ほとんど実際の見え味と同じです。

IMG_9324

馬頭星雲も燃える木もバーナードループも普通にはっきりしています。これでもトータル40秒以下です。

さてここで、ちょっと嫌なことに気づきました。明るい星の周りにハロが出ている(2020/2/5追記: 猫目ハロは解決しました。新型QBPが問題ではなく、カメラレンズが問題でした。)のです。炙り出しなどせずに普通に見ているだけではこのハロは気付きません。電視観望でヒストグラムをいじって炙り出すと目立ってきます。この時点ではQBPのせいなのか、レンズが悪いのかはっきりしなかったので、ここでQBPを外してみました。

IMG_9325

同じ1.6秒露光、30枚スタックです。QBPがないと明るくなりすぎるのでゲインを50(5dB、半分近く)落としています。バーナードループも辛うじて見えているようですが、明らかにコントラストは悪くなっています。これはQBPの効果が大だったといえるでしょう。でもその一方、ハロは抑えられています。

シベットさんがブログの中でQBPは赤外を通すためにハロがでるのではという報告をしています。その中でアポクロマートなど赤外でも収差補正をきちんとしている鏡筒はこの問題は出ないのではという考察がされています。これまで私もFS-60CBやFS-60Q、FC-76で旧版の48mmのQBPを使ったのですが、星がサチらない限りはハロは出ることはありませんでした。

今回星がサチっている可能性が一つと、単なる相当昔のカメラレンズなので、赤外で収差があるのは十分可能性があるでしょう。ただ、ハロの様子が赤だけでなく、なんかカラフルになっているのも気になります。シベットさんによるとUV/IRカットフィルターを併用すると、星像はフィルター間の反射で少し悪くなるが、ハロは消えたという報告がなされているので、次回私も試してみようと思います。

ハロは確かにあるのですが(2020/2/5追記: 猫目ハロは解決しました。新型QBPが問題ではなく、カメラレンズが問題でした。)、暗い星ではそこまで気にならないのと、星雲の出かたが思いの他すごいので、とりあえず今回はQBPをつけてこのまま進めます。


ばら星雲です。1.6秒露光で31スタック。トータル50秒くらいです。

IMG_9334

ばら星雲の上にも少し赤い領域があります。クリスマスツリー星雲ですね。

というか、今回何かを導入するというのではなく、画面を見ながら赤いのがあるとこれはなんだ?と、「星雲を見ながら探す」という夢のような体験をしています。例えば上のバラはリアルタイムの1.6秒一枚露光ではこのように見えます。

IMG_9327

もう、全然見える範囲の明るさです。

一番衝撃的だったのは次の例でした。

IMG_9339

真ん中らへんに何か赤いのが見えます。スタックするとさすがにわかります。

IMG_9340


そう、電柱の上をカモメが飛んでいるわけです。もう夜中に一人で大爆笑。普通の住宅街でこんなのがほぼリアルタイムで見えるわけです。面白くないわけがありません。

その様子を動画にまとめました。


左手でiPhonedで撮影しながら、右手で三脚の自由雲台の上のCMOSカメラを操作しているので、揺れたりして見にくい点はご容赦ください。オリオン座から電柱上のカモメ星雲、次にバラ星雲を突き止めて、最後にまたオリオン座に帰ります。バラ星雲なんかポンッと出てきます。実際にホントにこのように見えるわけです。

他にもプレセペ星団、

IMG_9336


M46、47、48です。

IMG_9337


適当にレンズを向けて見えたものです。1.6秒だけの露光なのでM46、47、48は少し見にくいですが、カモメ星雲のところの左上にもM46とM47は写り込んでいます。

あいにく、系外銀河は一つも認識できませんでした。アンドロメダとか出ていれば別ですが、さすがに広角レンズでは銀河は小さすぎるのと、やはりQBPは白色の系外銀河が苦手なのかと思います。あと今回はハロがキツかったので、恒星と銀河の見分けがつきにくかったのもあるかと思います。

最後に、オリオンが沈みかけるところです。右のほうが赤カブリになっていますが、それでもよく見るとエンゼルフィッシュ、辛うじてですが写ってますよね!

IMG_9332


まとめ

まだハロの件など克服すべき課題も多い(2020/2/5追記: 猫目ハロは解決しました。新型QBPが問題ではなく、カメラレンズが問題でした。)ですが、QBPと明るい広角レンズを用いることで、

光害地で、導入いらず、
リアルタイムにかなり近い、超お手軽な星雲星団観察

が可能だというのは特筆すべきことだと思います。一番最初にHUQさんが見せてくれてα7Sでの電視観望に近いかもしれません。α7Sの凄いセンサー感度にSharpCapとQBPで頑張って迫っているという感じでしょうか。

ちなみにこの50mm/f1.4レンズ、古くても標準レンズだったこともあり、今でも中古カメラ店やヤフオクで格安で普通に手に入れることができます。私は名古屋のコメ兵で5-6千円くらいだったと思います。

レンズは安くてもやはりASI294MCがまだ高いですかね。そこはASI385MCとかに代えて節約するという手もあります。

キットの望遠レンズを使った電子観望
も以前試しましたが、



広角、QBPが違う点になります。今回のこの手法も同様に、導入のための機器もいらないのと、さらに広角レンズを使っているために導入スキルも必要ありません。なので、相当手軽かと思います。

自由に空を見て星雲を探すインパクトは相当なものなのですが、今回のブログでそれが伝わったかどうか?比較的楽なセットアップだと思いますので、これまで電視観望を試したことがない人も、よかったら試してみてください。




あぷらなーとさんはじめ何人かの方がMatlabを購入し画像処理に活用し始めましたようです。



私もMatlabは学生の頃から使っていて、今調べてみたら一番古いファイルは1998年でした。なので20年以上使っていることになりますが、 これまで画像処理に使ったことはありませんでした。

あぷらなーとさんが指摘しているように、確かにMatlabは行列を容易に扱えるので、2次元が基本の画像処理は向いているはずです。最近過去のコードをpython化したりしてるのですが、pythonは2次元だと必ず繰り返し処理が入るので、コードが冗長になりがちです。私も少し試してみたのですが、どうやら画像処理に関してはMatlabの方がコードがかなりシンプルになり見通しが良くなるので、有利というのは正しそうです。とうわけで、遅ればせながら私もMatlab画像処理に参画します。

Matlabを使ってまず手始めに試したのが、昨年3月依頼謎が解けなくて止まってしまっているASI294MC Proのノイズ解析の続きです。

 


最初にごめんなさいと謝っておきます。今回の記事はかなり細かくてめんどくさい話で、ほとんどの人には役に立たないです。しかもうまくいかなかったという結果なので、ほんとに興味のある方だけ読んでみてください。

Matlabで画像処理を始めてみたいという人がいたら、もしかしたらコードが参考になるかもしれません。


以前のおさらい 

ざっとおさらいしてみます。ZWO社のASIシリーズは性能を示すデータを公開してくれています。例えば広いセンサー面積を利用した電視観望や、撮影にも十分に使うことができるASI294MC Proのページを見ていくと、下の方にいくつかグラフが出てきます。このグラフ、一見分かりそうで分かりにくいところもあるので、以前その読み方を解説しました。



上のページでも解説している通り、SharpCapを使うとZWOのページにあるようなデータを測定することができます。冷却バージョンのProも



で実際に測定した記事を書いています。特にGain[e/ADU]の値はコンバージョンファクターとも呼ばれて、設定gainが0の時のコンバージョンファクターはユニティーゲインなどにも直結するような非常に重要な値になります。少しコツは必要ですが、SharpCapのスクリプトでCMOSカメラの特性を実測すると、ZWOにあるような値に非常に近いものを測定することができます。2つのツールで同様のデータが取れているということはかなり信頼が置けるはずです。さらにもう一歩進めて、このようなツールでのスクリプトでなく、実際に自分でノイズを撮影して解析してみようと試したのが、昨年3月までの一連の記事になります。

ところが、実際に撮影して解析してみるとどうしてもZWOのデータやSharpCapでの解析結果と合いません。

SharpCapで撮影した時の撮影条件は限りなく再現させたと思っています。具体的には撮影対象の明るさ、カメラのゲイン、露光時間です。明るさは同等のものが撮れているので、撮影に関しては問題ないと思います。問題はノイズです。明るさとノイズの関係からコンバージョンファクターを求めるのですが、撮影された画像の明るさのばらつきが、想定していたものよりかなり大きいと出てしまいます。

具体的には標準偏差を用いるとノイズが大きすぎると出てしまい、苦肉の策で(ノイズが小さいとでる)平均偏差を使うと、大体ZWOとSharpCapの測定と一致するという結果でした。

ヒントになるかと思いモノクロのASI290MMで測定したら、標準偏差で計算してもZWOやSharpCapと一致した結果を得ることができました。ということはやはりカラーの場合も平均偏差などを使わずに標準偏差を用いるのが正しいのではと推測することができます。

そんな折、あぷらなーとさんがRGGBを一素子づつ解析したCFA(Color Filtr Array)で評価した場合と、RGBにdebayerした場合では、debayerの方が標準偏差で考えて0.75倍とか0.79倍程度に小さくなることを示してくれました。



それでもdebayerで計算してもまだZWOやSharpCapでのノイズの少なさには辿りつきません。

いろいろやっていて結局行き着いたところはこの画面で、

IMG_6436

小さいと思われるRGBの標準偏差よりも、Lの標準偏差の方がなぜかさらに小さいことがSharpCapの一枚の撮影で出てしまっていることです。いまだにSharpCapが内部でどうやって計算しているのかよくわかりません。このLの標準偏差を仮定するとノイズはかなりZWOもしくはSharpCapのスクリプトで測定した結果に一致します。言い換えると、これくらい小さい標準偏差くらいのばらつきになっていないと結果は一致しないということです。


Matlabでの画像処理の実際

やっと前振りが終わりましたが、今回Matlabで以前のpythonコードを書き直すかたらわら、どうしたら一致した結果を出せるか、なぜSharpCapのLがノイズが小さく出ているかを念頭に置きながらいろいろ試してみました。

Matlabを初めて使う人が一番面食らうのは、配列の表記法かと思います。これが独特なのですが、この独特な表記によりコードがシンプルになるので避けるわけにもいきません。私が書くよりももっといい説明がたくさんあるかと思いますが、今回の画像処理に必要な最低限だけ書いておきます。

まず2次元の配列、Matlabだと行列といっていますが、例えば2行x3列の配列Aを

>> A=[1 2 3;4 5 6;]

A =
     1     2     3
     4     5     6

と作ります。例えば第2行,第1列成分を見たい場合には

>>A(2,1)

と打つだけです。答えは

ans = 4

と出ます。これは至って普通です。独特なのは:(コロン)の使い方で、例えばAの1行目すべてを見たい場合は

>>A(1,:)

と打ちます。答えは 1 2 3となります。:はどこからどこまでを意味し、

>>A(1,1:2)

だと

ans =     1     2

となります。:(コロン)だけだとその次元の最初から最後まで全部という意味です。これがMatlabで絶対理解しておかなければならない表記法の一つです。

今回は画像を扱うのに4次元の配列を使っています。1、2次にy座標とx座標。左上からyは向かって下に、xは右に移動していきます。3次目はRGBやCFAのインデックス。RGBなら3つ、CFAなら4つとっています。 4次目は何枚目の画像かを表しています。今回8枚の画像を使っていますが、その何枚目かを表します。あと成分を表す数字は1から始まることにも注意です。0からではありません。 

例えば、AにRGBで別れた画像が8枚入っているとすると、5枚目のG画像を表す時は

A(:, :, 2, 5)

と表します。:が2つあるのはy、x座標それぞれ全部を表しています。"2"はRGBの2番目と言う意味です。Bなら3ですね。"5"は5枚目と言うことです。

例えばサンプルコードの最初の方にある

 Raw(:, :, i) = fitsread(ファイル名);

はi番目の画像にfitsファイルを読み込んで、1次目にy座標のデータ、2次目にx座標のデータを全部入れていきなさいと言うのをわずか1行で表記したものです。

これらの表式は慣れるしかないのですが、ここらへんを感覚的に理解できるとコードもすらすら読めて、シンプルなコードを書くことができるようになるのかと思います。


モノクロセンサーASI290MMの場合

とりあえずMatlabでやってみた画像処理を説明していきます。まずはモノクロのASI290MMの結果です。

ASI290MM
このグラフを出したMatlabのソースコードをアップロードしておきます。使用した画像も(サイズを切り詰めるために中心部のみ切り取ったものですが)一緒に入れておきましたので、すぐに走らせることができると思います。もしMatlabを持っていて興味があったら走らせてみてください。

ASI290MM.zip 


結果は前述したとおり、平均偏差ではなく一般的な標準偏差を使っています。メーカー値はコンバージョンファクターが3.6程度、ユニティーゲインが110程度ですので、グラフ内の数値と比較してみるとそこそこ一致していることがわかります。なので、カラーでも標準偏差を用いる方向を探りたいと思います。

また、以前pythonで書いたコードと比較して同等の結果を出すことできています。

Conversion_Factor_ASI290MM_std

Maltabでもこれまでと同様のことができることがわかり、かつ遥かにシンプルに書けることがわかりました。


カラー版ASI294MC Proの場合: CFAで解析 

さて、Matlabでの画像処理にも慣れたところで問題のカラーのASI294MC Proの解析です。

結論から言うと、結局今回も謎は解けずじまいでした。

まずはシンプルなCFAの方から。RAW画像からCFAへ分離するところはビルトインの関数とかはないようなので自分で書いてみました。以前は平均偏差(mad)で無理やり答えを合わせましたが、今回ASI290MMの結果なども含めていろいろ考えた末に、結局諦めて標準偏差(std)を使うことにしました。

ASI294MCPro_CFA

各測定点はそのまま解析した結果を表示していますが、フィッティングは無理やり合うように補正してます。考え方としては、謎な部分をunknown factorとしてフィッティングするところで無理やり補正するというやりかたです。今回のCFAの場合、unknown factorはノイズ(標準偏差の2乗)を2分の1とすることでZWO、SharpCapの結果と一致することがわかりました。

ちなみにメーカー値はコンバージョンファクターが3.9程度、ユニティーゲインが117程度です。繰り返しますが、CFAで測定されたノイズを無理やり半分にすることでメーカー値に近くなります。

先に説明したように、SharpCapでLのノイズが小さく出ている理由がわからなかったので、もうこのように無理やり合わせてしまうしかなかったという苦肉の策です。これはあぷらなーとさんが示してくれた、CFAとRGBで標準偏差で0.75倍違うというのを考慮してもまだ少し足りません。

まあ、このやり方に言いたいことはたくさんあるかと思いますが、とりあえず先に進むことにします。


カラー版ASI294MC Proの場合: RGBで解析

次はRGBでの解析です。

最初はMatabビルトインのdemozaicという関数を使ったのですが、これだと中で何か変に処理しているのかノイズが話にならないくらい大きくなりすぎました。仕方ないので自分でRGBに落とすコードを書いています。そこそこまともそうな値は出たのですが、ただしこのコードまだ未完成です。なぜかというと、センサーアレイはRGGBなのでG(グリーン)が二つあるのですが、その応答が少し違うことに起因します。Gを2つ使って求めると強度の山が2つでできてしまい、ばらつきが大きくなりすぎるからです。そのため今回は2つあるG素子のうち1つだけを使うことにしました。

ASI294MCPro_RGB

RGBになりあぷらなーとさんが示してくれた通り、CFAの時よりもばらつきは少なくなることがわかりました。それでもまだノイズが大きすぎるのでCFAの時と同様にunknown factorとしてフィッティングするところに無理やり入れました。RGBの場合、unknown factorはノイズ(標準偏差の2乗)をルート2で割ってやることでZWO、SharpCapの結果とかなり一致することがわかりました。


考察

ASI294MC Proで使ったファイルもアップロードしておきます。よかったら参考にしてください。

ASI294MCPro.zip 

今回はまだ苦肉の策で、無理やり答えを合わせるように測定結果を割っているだけなので、考察と呼べるようなものにはなりません。CFAの場合出てきたノイズを半分に、RGBの場合ルート2でわってやるとSharpCapやZWOの結果とかなり近い結果になりましたが、その理由は全然わかっていません。

前回のpythonコードを使った時はCFAやRGBの変換はPixInsightを使いました。でも今回はRAWファイルから直接計算してCFAもRGBも取り出しています。ここら辺はMatlabに移ったことでやりやすくなったところだと思います。このように今回はかなり噛み砕いてブラックボックスがないように進めてきたつもりです。撮影した画像はSharpCapのスクリプトで撮影したものと同等と仮定していいかと思います。これでも結果が一致しないということは、
  • ZWOもSharpCapも何か特殊なことをやっているか
  • もしくはまだ私が馬鹿なミスを犯しているか
です。とにかく怪しいのがZWOのLのノイズが小さく出過ぎていること。この謎が解けない限り進展がない気がします。


まとめ

週末を結構な時間費やしましたが、コンバージョンファクターに関しては結局昨年から進展がなかったので疲れてしまいました。それでも得られた成果としては、
  • Matlabでの画像解析の手法に慣れることができた。
  • あぷらなーとさんが出してくれた、debayerの方がCFAよりもノイズが0.8倍程度と小さくなることを確かめることができた。
ことくらいでしょうか。でも全然だめですね。これ以上は時間の無駄になりそうなので、一旦ここで打ち切ることにします。

それでもMatlabが使いやすいことは分かったので、今後の画像解析はMatlabで進められそうな目処はついたと思います。

元々この解析はダークノイズ解析につなげたいとか、EOS 6Dのユニティーゲインを測定したいとかで始めたのですが、なかなか進みません。いつ実現できるのかまだまだ未定ですが、諦めることはしたくないのでまたいつか再開する予定です。

このページのトップヘ