以前、SHG700用に新しい10mm長のスリットを手に入れて、TSA120で分光撮影を試みたのですが、カメラのセンサー拡大も必要で、手持ちのASI294M Proを使ってみたところ、ROIの設定が限定されていてい結局使えなかったという記事を書きました。新しいIMX183系のカメラを買えば済む問題なのですが、最近フェニックスを買ってしまったので、しばらくはお預け状態になっています。





でも捨てる神あれば拾う神ありで、ASI294MM ProのROIを任意に設定する方法があることがわかりました。SharpCapのフォーラムに投稿されていたのですが、やはり悩みは全く同じで、新しいスリットで手持ちのカメラを使えないかというのが発端です。



それによると、Windowsのタスクバーの検索欄に「regedit」などと入れて、出てきた「レジストリエディター」をクリックして立ち上げます。
「\HKEY_CURRENT_USER\Software\AstroSharp Limited\SharpCap\4.1」まで行き、「CustomResolutions」をダブルクリックします。「値のデータ」に例えば「;8000x180」などを加えます。


SharpCapが立ち上がっていた場合は再起動して、ASI294MMProを接続し直すと、設定したROIが選択できるようになっています。




最初8000x180で試しましたが、seeファイルの大きさが10数GBと大きくなってしまったので、もう少し攻めて結局5400x150に落ち着きました。一時、縦幅を120まで攻めたのですが、Hα線をうまく読み出せないことがあったので少し余裕を持たせています。頑張れば5000x130くらいでも実用的になるかと思います。でも、撮影時のファイルサイズが大きいのはそんなに問題ではなくて、JSol'Exで処理するときにserファイルを時間、サイズともに同クオリティで小さくするオプションがあるので、それを使うと結局どんなサイズで撮影してもほぼ同じ小さいサイズで保存することができます。今回も小さくしたファイルでもきちんとHα画像を再現することを確かめました。撮影時7GBくらいのファイルが1.5GBくらいの大きさになるので、撮影時にさえディスクが溢れないように気を付けておけば、処理した後はディスク容量などそこまで問題になることはなさそうです。

問題はフレームレートです。8000x180で70fps、5400x150で76fpsでした。fpsは縦幅のみに依存していて、横幅はほとんど関係ないみたいです。縦幅を120にしてももう大きくは上がらず80fps程度で高止まりです。これまでのG3M678Mは縦幅にも依りますが、実測で450-570fps程度は出ていたので、これまでの6分の1以下のスピードと相当遅くになります。

これは1枚あたりの撮影時間に直結します。出来上がる画像の横の空間分解能はserファイルの撮影枚数で決まります。縦幅が5400ピクセルなので、横幅も同じくらいのピクセル数にすると考えると、ざっくり5400枚撮影する必要があります。撮影時間はこれをフレームレートで割った、5400/76=71秒くらいは必要なわけです。実際には太陽が映っている部分はもう少し小さいとしても、これまでFC-76とG3M678Mだと1回16秒くらいで撮影を済ましていたことを考えると、大幅な撮影時間の増大となります。

また、時間をかけて撮影する必要があるということで、赤道儀のスキャンスピードも16倍から4倍程度にまで落とす必要があります。以前、16倍と32倍で試したのですが、赤道儀としてはどうも速いスピードのほうが安定っぽかったので、ここまでスピードを落としてうまく撮影できるかも心配になります。

最初、1回あたり90秒でスキャンしてテスト撮影していました。一応太陽全景は入るには入っていたのですが、連続撮影のための「SHGスクリプト」の初期位置を最初に太陽中央に置くと、撮影時間ギリギリになってやっと太陽の終わりが入るくらいになってしまいます。その一方太陽の写り始めは録画開始時刻のはるか後になってしまいます。できた動画は前半は何も映っていなくて、後半にのみ太陽が入っているという時間的にもファイルサイズ的にも無駄が多い状態になってしまいました。

本来このSHGスクリプトでは、太陽中央を初期位置にするので正しいはずなのですが、赤道儀のスキャンスピードが4倍と遅いのが原因なのか、それともスクリプトにまだ対応しきれていないところがあるのかわかりませんが、とりあえずあらかじめ初期位置をずらすことで回避することにしました。具体的には、太陽の進む方向に先回りしたところ（具体的には赤道儀のWestボタンを押して太陽が見えなくなるところから、16倍速で10回ボタンを押すくらい離れたところ）に初期位置を設定してスクリプトを開始すると、動画の真ん中の時間帯に太陽が入ります。この設定で動画の長さを60秒くらいまで短くすることができ、前後5秒くらい余裕が残る程度になりました。これで撮影動画をJSol'Exで処理すると太陽の縦横比が0.98と出たので、ちょうどいいくらいのスピードでしょう。例えば縦横比が0.5とかだと、赤道儀のスピードが速過ぎて潰れたような太陽になってしまい、それを無理に円形にするので、解像度が出ないというわけです。

結局これらの

• ROI5400x150
• フレームレート76fps
• スキャンスピード4倍速
• 撮影時間60秒
• 初期位置が太陽端から16倍速で10回ボタンを押したところ

というパラメータを見つけるのに12月7日(日)と13日(土)とほぼまる2日使ってしまい相当苦労してしまいましたが、とにかく、TSA-120とASI294MM Proで撮影することは可能だということがわかりました。



下の画像は、テスト中に撮影した30枚くらいのがぞうのなかから、30分間くらいの間に撮影した10枚をスタックしたものになります。


残念ながらこの日はかなりの強風で、さらにシーイングも見るも無惨な日でした。特に分光撮影ではスキャン時間の間の風による鏡筒のブレの影響は結構深刻で、画像自体の分解能はまだ議論できるレベルではないと思います。それでも口径がこれまでの76mmから120mmになって分解能が得している様子はある程度伺うことができているように見えます。今回はとりあえず撮影ができることがわかったということで、細かい比較は今後余裕が出た時にしようと思います。



ちなみに、フェニクスでSharpCapのライブスタックで同じような時間帯に撮影したものが下になります。この画像はライブスタックでの簡易撮影ということと、シーイングが相当悪かったこともあり、分解能は前回より相当落ちてしまっています。


先の分光撮影の画像と比較したいのは、波長分解能(波長透過幅)です。白く明るいところはプラージュと呼ばれている領域です。このプラージュ以外にも、先の分光の撮影ではもっと広い領域に白いモヤモヤしたものが写っています。これは波長分解能が相当良くなると見えてくるもので、私的にはこのモヤモヤがどれだけ見えているかで波長透過幅どれくらい狭いかを評価する指標としています。

また、先の分光撮影の方が黒いダークフィラメントがより濃く見えるのも、波長分解能がより細かい証拠で、背景光の影響がより少なくなるためによりコントラストがよくなります。

白いモヤモヤ部分ですが、どのように呼べばいいのか、少なくとも私はまだ名前を知りません。波長分解能がものすごく良くなってから初めてわかるものなので、これまであまり認識されていなかったのかもしれません。どなたかこの名前がわかる方いらっしゃいませんでしょうか？フェニクスはそのモヤモヤが少しですが、実際に見えているところがすごいです。エタロンですが、昔のものよりも性能が確実に上がっているのがよくわかります。

ここら辺の詳しい話は、以前SH700で波長透過幅が分光よりも広いエタロンの写り具合を再現した時の記事で詳しく議論しています。


今回のフェニックスも同程度の写りかと思うので、エタロンの性能としては前回お借りしたフェニックスと大きな差はないものと思われます。フェニクスエタロンの波長透過特性は、そのうちに測定するつもりです。これまでの手持ちのPSTと比べてどれくらい差があるのか、とても楽しみです。



とうとう、SHG700+長めの新スリットと、より口径の大きいTSA-120と、手持ちでセンサ面積の広いASI294MM Proで、太陽全景の分光撮影が成功しました。このカメラのフレームレートが遅いのでかなり苦労しましたが、カメラを新規で購入するまでには至らずになんとかなったので、まあよかったでしょう。

これで以前計算した結果によると、空間分解能は2.2 arcsecから1.4 arcsecと大幅に改善されたことになります。その一方、波長分解のは0.091Åから0.105Åと少し悪くなっていますが、そこまで大きな違いではないでしょう。

トータルとしては大きな改善なのですが、今回の撮影では天候のせいでまだその性能を引き出せたとは言えないので、風もなくシーイングがいい日を狙って再度評価してみたいと思います。

タグ ：

#太陽

#TSA-120

#ASI294MMPro

#SHG700

#Phoenix

#SharpCap

#ROI

#フレームレート

#fps

太陽分光撮影のアップグレード計画の開始です。


以前議論したように、現在のFC-76+SHG700+G3M678Mがどこまで性能が上がるのか、実際に機材をアップグレードして試してみることにします。

きっかけは、元々SHG700に標準で付いていた幅7μm、長さ7mmのスリットが、幅は同じで長さが10mmのものにアップグレードされることが検討され、そのテストも完了し、やっと一般配布が始まったことです。私も発表されてすぐに発注しました。到着はかなり前だったのですが、今のセットアップでやりたいことも大体できたので、やっとテスト開始というわけです。

そもそも、スリットの長さが長くなると何が良いのかというと、一言で言うと鏡筒の焦点距離が伸ばせると言うことです。分光撮影ではスリット上で焦点を合わせる必要があることから、焦点距離によって太陽像の大きさが一意に決まってしまいます。ざっくり言うと、長さ7mmのスリットで焦点距離700mmまで、長さ10mmのスリットで長さ1000mmまでです。今使っているFC-76の焦点距離は600mmなので、7mmスリットでまだ少し余裕があります。今回は10mmスリット用に、焦点距離900mmのTSA-120を使うことを考えています。

でも単純に焦点距離を伸ばせば良いのかというとそうでもなくて、例えばカメラセンサー上の太陽像の大きさも大きくなるので、センサー面積を大きくするか、カメラレンズの焦点距離を短くするなどの手当てをしてやる必要があります。また、焦点距離が長くなると口径も大きくなりがちで、その分集光された光のエネルギーが上がるので、スリットが焼けたり壊れたりしないかなども考慮する必要があります。SHG700で使われているスリットは溶融石英製で熱膨張率が小さいため、MLastroによると口径4インチ(102mm)までは大丈夫とのことです。普通のBK7などのスリットだと耐熱量はもっと下がるので、普通はNDフィルターなどを入れる必要があります。だた、溶融石英と言えど今回は口径120mmと推奨口径より大きくになるので、少し心配です。



まず比較のために現在のFC-76ベースでのHα画像を撮影しておきます。その結果は前回の記事にまとめてあります。そうです、前回記事はいつもの記録撮影に加えて、新システム移行に際しての比較テストという意味も兼ねていたのです。これと今回撮影する画像との比較で、性能が上がったかどうか判別します。

比較のための事前撮影が終わった後に、まず最初にやったのは、口径を大きくしてスリットが溶けたり燃えたりしないかの安全テストです。口径が120/76=1.58倍となるので、光量は(120/76)^2~2.5倍となります。上でも書いたように少し心配なので、C8にPSTを取り付けた際に使ったようなUV/IRカットフィルターを入れてやります。

タグ ：

#太陽

#分光

#TSA-120

#FC-76

#スリット

#G3M678M

#ASI294MMPro

#SGH700

前回の記事で今年5月に撮影した南天の天体を処理しましたが、今回はさらに前の4月の撮影結果になります。



私は春の銀河はあまり得意ではありません。SCA260の1300mmの焦点距離と、ASI294MM Proの画角だと、少し広くて銀河の細かい構造に迫力があまり出ないからです。それでも今回は、一度撮影してみたかったヘルクレス座銀河団に挑戦してみました。

銀河団といえばおとめ座銀河団が有名で、以前撮影しています。範囲もヘルクレス座銀河団よりも遥かに広く、焦点距離420mmのε130Dとフルサイズのカメラでもまだ収まりきりません。



今回のヘルクレス銀河団の場合、もっと小さい領域に小さい銀河が集まっていて、一部を拡大して細かい銀河を見ることになるので、分解能が勝負となり、きちんと撮影しようとするとかなり手強いです。

撮影はもうかなり前で記憶の彼方なのですが、その時の様子は当時文章にして残してあったので、ほぼそのままの形でブログ記事として使いました。その時のことを読んでて、赤道儀の反転を失敗したのも思い出しました。ことなきを得たのですが、冷や汗ものでした。

時期的には4月初めに撮影したM104の次で、4月中頃になります。LRGB合成の予定で、3晩にわたって撮影し、Lだけで6時間以上、RGBがそれぞれ約1時間と、合計9時間以上になっています。画像処理の途中で思ったのが、思ったより色が出ないので、もう少しRGBをの枚数を増やしても良かったのかもしれません。

M104のときには画像処理にかなり時間をかけてしまったのも、今回のヘルクレス座銀河団の画像処理が遅れてしまった理由の一つです。実は画像処理は4月の時点で一度パッとやっていたのですが、気に入らなかったので改めて一からやり直しでした。それから約半年後になりますが、今回新たに書いた記事は主に画像処理についての部分です。



今回の撮影ですが、夜中の2時半頃に子午線反転があります。この時間夜中に起きているときついこともあり、NINAの自動反転機能で乗り切ろうとしました。ただし、自動反転は以前痛い思いをしたことがある



ので、ある程度の対策をしてました。

数十cm程度の短いUSBケーブルとDC電源ケーブルをカメラ側に取り付け、カメラの周りにケーブルタイで固定して、引っ張られた時に必ずケーブルの長手方向にのみ力がかかるようにして、引っ張って抜けるようにしておいたのです。


今回はこれが功を奏しました。朝起きて撮影結果を見ると、PHD2が途中で止まっていて、カメラが認識されないと出ています。撮影画像のタイムスタンプもちょうど反転時刻くらいまでで、その後は撮影されていません。これはまずい！と直ぐに外に出てみてみると、どうやら赤緯体がクルッと一回転しているような状態で、ケーブルが首に巻かれているような状態になっていました。

それでも想定通り、短いケーブルのところでUSBもDC電源も共に抜けていて、ことなきを得ました。こんな風に首を巻いた状態は初めてでしたが、赤緯体が初期位置からほぼ真反対に向いた状態での撮影になるのでこんなことが起きたのかもしれません。南天の高いところの天体は少し注意が必要かもしれません。今のところはっきりとした原因は不明ですが、とにかく機材が壊れなくて何よりでした。



手持ちのバッテリーの一つが、気温が低いと変な振る舞いを見せることが確実となってきました。以前開田高原に行ったときには低温警告が出たのですが、警告は出なくても、温度が低いと電圧降下が激しいようです。

まず、気温が低い時は最初は使えるのですが、途中で電池の消耗が早いと自ら誤認識してしまうようです。一晩持つことはなく、夜中気温が低くなってくると止まってしまいます。こうなると、電源を入れようとボタンを押しても何も反応がないのですが、充電しようとしてACアダプターに繋ぐと何故か一瞬（秒単位）で100%になります。温度がまだ低いうちにACアダプターを外すとまた直ぐにダウンしてしまうのですが、しばらく待って温度が少し上がってからACアダプターを抜いても100%を保ったままになります。充電し切れているとはとても思えない短時間で100%になるので、何か表示がおかしいかです。

季節が進み気温が上がってくると、一晩持つようになってきます。撮影が終わって朝チェックすると、気温によって0％と出る時と、数十％残る時があります。0％となっているときにACアダプターに繋ぐと、これもなぜか一瞬で100%に戻りますが、一晩使っているので明らかに電力が多く残っているとは思えず、充電時の表示が何かおかしいと思われます。一方、数十%とか残っている時は、すぐに100%にはならずに、数十%が徐々に増えて、でも直ぐに（1分くらい?）で99%とかになります。温度が上がってきて徐々に振る舞いがまともなものに近づいてくる印象ですが、まだ春くらいの温度だと信用できません。一応100%充電されていると表示されていようが、そのまま充電を続けて半日くらい放っておきますが、次回使うときは今のところ問題なく使えています。

他のバッテリーを5台ほど使ってきましたが、同じような状況で同時に使っても、今のところこの一台のみがこのような変な振る舞いをします。たまたまこの個体だけなのか、興味がありますが、Amazonのレビューとかみても低温関連のことはあまり書いてないので、よくわかりません。Amazonの同機種のレビューを見ると、低温以外でもよく似たトラブルはたくさん報告されていて、途中から充電できなくなったとか、保証期間を過ぎると修理もできないとかの投稿がたくさんあります。大手のものだから数が出ているからというのもあるのかもしれません。

今回のようなことがあると改めて思うのですが、大型のバッテリーを買って1台で運用するようなことは、撮影失敗のリスクを考えるとちょっと怖いと思ってしまいます。私は1万円からせいぜい2万円までの機種で抑えていて、そのクラスの数を揃えるという戦略です。トラブルの時はすぐに交換して、冗長性で回避できることと、不具合時の1台あたりの金額的なダメージを防ぐのが目的です。低温時には問題があるこのバッテリーも、その後暑い夏には普通に使うことができたので、冬場は他のバッテリーを使えば良く、長い目で見たらそこまでダメージはないです。



撮影直後の画像処理では銀河がのっぺりと絵のようになってしまい、やる気を無くしてしまいました。反省して、今回はRAW画像の選択からやり直しです。

まず、前回画像処理した自分の画像と、Astrobinのヘラクレス銀河団でよく写っているものを見比べてみました。のっぺりは仕方ないとして、パッとわかる決定的な違いは微恒星の数です。例えばAstrobinのImage of the day (IOD) に選ばれた画像と自分の画像で、同じ領域を切り出してPixInsightのSubframeSelectorで認識できる星の数を比べてみると、IODの方が約1.5倍の星の数になりました。実際の画像を見ても、細かい星があるかないかでかなり違って見えて、1.5倍というのはちょうど納得できるくらいの数字です。

1回目の画像処理ではFWHMが5以下、星の数が250以上という閾値を設けてRAWのL画像を振り分けました。その場合、376枚中、147枚が採用されました。できるだけ小さな星を救おうとしたために、悪い画像を切り捨てたつもりですが、かなりの枚数を捨てていることになります。今回、2回目の画像処理はFWHMが7以下、星の数が150以上と条件を緩め、採用枚数を376枚中、274枚としました。

まずこれで微恒星の数が変わるかです。ここでいう微恒星の数というのは、M104の時に散々議論したBXTで認識される小さな星の数ということです。


結果はというと、M104の時とほぼ同じで、

• 1回目の、枚数を絞ったFWHMが小さい方が、出来上がりの恒星の大きさは小さい。
• この場合、背景ノイズが大きい。
• ノイズに埋もれた淡い微恒星を救いきれない。

でも、落としてしまう微恒星の数は大したことはなく、IODの画像で見えている微恒星からみたらまだ全然少ないままなので、誤差の範囲です。

一方2回目では、

• FWHMは大きくても枚数が多い方が背景のノイズは明らかに小さくなる。
• S/N測定でもいい結果出ている。
• かつ残る恒星の数も多少増える。
• 恒星の大きさが少し大きくなる。

といいことが多いのので、今回は枚数を増やしたもので処理することにしました。不利な点として、恒星が少し大きくなるのはBXTでどうにでもなると考え、今回は重要視しなかったです。もしBXT無の場合は、判断が変わるかもしれません。


次に今回の画像処理でやり直したことは、drizzleの有無です。今回は最初drizzle無しで処理しましたが、小さい銀河が多数あるので、改めて比較するとdrizzle x2の方が有利そうです。

そのため、2度目の処理はdrizzle x2を使いました。

本当はM104の時のように、撮影時からASI294MMのbin1にしてもよかったのですが、撮影時から画像サイズが大きくなり、画像処理の負担も大きくなり、かなりきついです。フラットなども合わせると、ディスク容量も平気で数100GBを使用してしまいます。bin2のdrizzleのx2なら、最後のインテグレーションで増えるだけなので、全然許容範囲です。drizzle x2にBXTをかけるとかなり解像度が出ることがわかっているので、これでbin1に迫れるといいのですが。

ただし今回は、露光時間をこれまでの自分の標準の5分から1分に短くしました。恒星が飽和するのをできるだけ避けるためです。そのため撮影枚数はこれまでの5倍と多くなるので、その分ディスク容量を食います。

4月の最初の画像処理でのっぺりとしてしまった原因もわかりました。ストレッチ時のGHSの使い方が原因でした。GHSは最初にSP (Symmetric Point)を選ぶのですが、SPに0以外の値を入れてしまうと銀河の中の淡い部分が明るくなりがちで、どうも階調が取れません。今回だけなのかもしれませんが、SPは0にして、当然LP保護も0になりますが、HPの保護は明るいところをあまり明るくしないように適当に0.5とかにしました。あとの残りのパラメータはStretch FactorとLocal Intensityだけなので、これで銀河の暗いところから明るいところまで階調ができるだけ残るようにストレッチとLPを調整しました。どちらも大きくしすぎないことがコツみたいですが、まだあまりよくわかっていない部分もあるので、もう少し経験が必要みたいです。

さらにその後、GHS以外にもいくつか試したのですが、今回は背景の淡い構造を出す必要はないこと、飽和しないことという条件で、結局もっとシンプルなMaskedStretchとしました。結果を見ると、もう少し彩度を出しても良かったので、ArcsinhStretchでもよかったのかもしれません。

そこからの最後の仕上げはかなり苦労して、結局5回くらいやり直しました。Astrobinを見ていると、銀河も恒星も色彩豊かで、一つの銀河内でオレンジから青白まで出ているものもあるのですが、自分の画像だとなかなかそこまで出ないです。RGBの撮影時間が短いので色情報がノイジーなこともあるのかと思います。もう少し手はあるのかもしれませんが、キリがないのでできる範囲でまとめました。まだ少し不満が残っているので、微恒星の写りも含めていつかリベンジしたいです。



今回画像処理した結果を示します。drizzle x2だと画像が大きくなりすぎてアップロードできなかったので、ブログ用に少しだけ(75%くらい)解像度を落としています。


画角が少し広いので、一部銀河団の中心部を切り取った画像も載せておきます。銀河をできるだけ取り込むために、縦型に切り出した後、90度回転させています。これぞ「銀河団」という感じです。

特に拡大図の方をみると、4月ののっぺり画像処理から比べたら、輝度の階調を残し、色調もある程度確保することができたと思います。BXTの効果も絶大で、drizzle x2と合わさって、銀河の細部もよく出ていますし、恒星の肥大も抑えられています。

見る距離や拡大率にもよると思いますが、小さな銀河なので離れた時見てもある程度はっきり見えるように、もう少し輝度や彩度を出してもいい気もします。その一方、あまり派手でないこのくらいがいいのかとも思えます。まだ自分の中で銀河にあまりはっきりとした基準がないので、今後しばらく試行錯誤かと思います。

上で議論したように、M104の時と同じでBXTで認識できない微恒星を取りこぼしてしまっているので、あるところより暗い恒星が全く見えなくなるという、あからさまな閾値ができてしまっています。BXTで小さな銀河と恒星の見分けが本当にできているか、StarNetで恒星と背景を分離するときに、銀河をうまく背景に分離できているかどうかは、まだ多少疑問が残ります。私は趣味と割り切っているのであまり気にしていませんが、気にする人は気になるかもしれません。ただし、同じクオリティーをBXTなどなしで出そうとすると、鏡筒の大口径化、赤道儀の大型化、シンチレーションのいい撮影地の選択、更なる長時間撮影など、敷居がはるかにはるかに上がります。簡単に同程度の効果をソフト的に実現するBXTやStarNetは、やはりすごいと言わざるを得ません。

最後に、恒例のアノテーションです。


確かにそこそこ銀河の数はありますが、おとめ座銀河団の時のアノテーション画像ほどではなく、面積も数もやはりもう少し小ぢんまりとした印象です。



長く処理されずに残っていたヘルクレス座銀河団も、やっとブログ記事にたどりつきました。細部をいかに出すかで、おとめ座銀河団の時はε130Dで最初から焦点距離が短かったのであまり気にしなかったのですが、今回は焦点距離1300mmなので、かなり細かい描写でシンチレーションとかも効いてくるはずです。処理してみると、思ったよりはるかに手強かったです。

HDDの中身を見ても未処理画像も、だいぶん底が尽きてきました。残っているのは中途半端に撮影したものとかで、今後処理する気になるかどうかもよくわからないものばかりです。なんとか救ってやりたいものもあるのですが、もう2年前に撮影したものとかもあるので、撮り直したほうが早いかもしれません。

撮影にも画像処理にも時間がかかるようになっています。もっと気楽に済ませたいという思いもあります。この場合はSWAgTiとかを活用すればいいのでしょうか。でも大口径のものと比べてしまい、満足できるのかどうかはまた別問題になるのかと思います。

さて、次はここしばらく何日か撮影している網状星雲です。もう諦めて画像処理を進めるか、さらに撮影枚数を増やすか。いや、全然気楽な方向に行ってないですね...。

タグ ：

#ヘルクレス座銀河団

#銀河団

#SCA260

#ASI294MMPro

#CGX-L

#反転

#バッテリー

#トラブル

久しぶりのブログ更新になります。皆様いかがお過ごしでしでしょうか？ゴールデンウィークは天気も良く、特に後半は新月期に入り絶好の星見日和だったのかと思います？

私はというと、あいにくGW中に体調を壊してしまい、前回の小ネタ記事を書いて以降ほぼ何もできない日が続きました。やっと体力も少し回復してきて、今もこの記事は病院の中で書いています。と言っても今回のM104の撮影はずっと前に終わらせていましたし、画像処理もブログ記事ある程度まで終えていたので、少し仕上げたくらいであまり無理はしないようにしています。

せっかくの長期休暇の新月期、暑くもなく寒くもなく、大きな太陽黒点と低緯度オーロラを横目にと、数々の絶好のチャンスを逃してしまい残念でなりません。その不満を払拭すべく、少しづつですが再開していきたいと思います。



M104は分解能ベンチマークのような役割もあり、これまで何度か撮影しています。最初は2021年4月にVISACで。中心部を拡大すると、まだまだ無理やり解像度を出している感があります。


次は2022年8月、SCA260を手に入れてからより大きな口径で違いを見ました。


ただ、SCA260は焦点距離が1300mmとそこまで長くないので、M104は小ぢんまりと写ります。そのためこの時は

1. バローなどなしでbin1の場合
2. 2倍のPowerMATEを使ってbin2の場合

で比較しました。1素子あたりの明るさと画角は同じになるようにして比較したということです。違いはFOV(全体の視野角)と、bit depthになります。結果としては、恒星は2の2倍でbin2方が良かったですが、銀河本体は1の方がビミョーに良かったです。でも有意な差はほとんどなくて、結局1のほうがバローの挿入などの余分な操作がなく埃などが入る余地が少ないので、今後は1でいくという結論になりました。あと、この時はまだRGB合成のみで、L画像は撮っていませんでした。

その後、2023年5月にL画像だけ撮影していて、明らかに解像度が上がっていることまで確認したのですが、同時期にRGBを撮影する機会がなかったのでそのままお蔵入りにしてしまいました。2022年のRGB画像と合成しても良かったのですが、いまいち盛り上がらずに2024年を迎えてしまって、このままではさすがにダメだと思い、今回やっとLもRGBも一緒に撮影するに至りました。





今回の撮影での大きな違いは、

• 前回まではRGB撮影だけだが、今回はL画像を撮っているところ
• 露光時間をこれまでの5分から1分にしたこと

です。L画像は実際の解像度向上に大きく貢献することになるかと思います。露光時間に関しては、SCA260+ASI294MM Proの場合gain120で露光時間5分だと、かなりの恒星がサチってしまうことに気づきました。特に、明るいL画像は深刻です。

下の画像は昨年5分で撮影したL画像を反転させています。bin1での撮影なのでそもそも12bit = 4096階調しかありません。ここでは階調の99％以上(4055/4096)になってしまっているところを黒くしています。

結構な数の星と、なんと画面真ん中の銀河中心までサチってしまっています。これはいけませんね。

下は今回露光時間を1分にしたもので、他の条件はほぼ同じです。だいぶマシになっていますが、それでもまだ飽和を避けることはできていません。少なくとも銀河中心は問題ないです。

さらに露光時間を変えるにあたり、以下の2つのことを考えましたが、処理後の画像を見比べた限り違いはわからなかったです。

1. 自宅撮影に限っていうとスカイノイズが圧倒的に支配的になります。露光時間を短くすると、読み出しノイズの効きが大きくなってくるのですが、露光時間を1分にしたくらいではまだまだ読み出しノイズは全然効かないくらいです。
2. 淡い部分の階調がADCの暗い側にシフトするので、階調が出にくくなる心配もありましたが、まだ全然余裕があるようです。

LRGB画像は今後1分でいいと思います。ナローに関しては輝度が10分の1以下になるので、露光時間5分をキープするか、ダイナミックレンジがそこまで必要なければgainを上げてもいいかと思います。

タグ ：

#M104

#ソンブレロ銀河

#SCA260

#ASI294MMPro

#LRGB合成

#BXT

#ハッブル

#Hubble

#露光時間

#飽和