ほしぞloveログ

天体観測始めました。

カテゴリ: 観測・撮影

自宅で淡いもの撮影シリーズ、多分このダイオウイカが最終回になるでしょう。これ以上淡いのは...さすがにもう限界です。

「そこそこ」撮影

私の元々の天体撮影の動機は「自宅でそこそこ撮れればいいな」でした。でも「そこそこ」がいつしか「どこまで」になり、いまでは「限界は」になってしまっています...。初心から考えるとあまり良くない傾向ですね(笑)。

最初に天体写真を始めてからずいぶんかかりましたが、最近では自宅でもやっと「そこそこ」満足に撮れるようになってきました。なんか「そこそこ」の使い方が間違っているようにも感じますが、とにかくイルカさんカモメさんクワガタさんは分解能や階調など見てもそこそこかと思います。ここ数年のソフトの進化の効果もかなり大きいです。でもこれは明るい天体だからまだ言えることで、かなり頑張って出したスパゲッティーさんは自宅撮影の限界はもう超えているんだと思います。今回の撮影のコウモリさんはまだしも、ダイオウイカさんはスパゲティーと同レベルか、もっと淡かったりします。


撮影したのはかなり前

Sh2-129: フライングバット星雲とその中のダイオウイカ星雲を撮影したのはもう半年も前のことで、時期的にはスパゲティー星雲を撮影した直後です。そういう意味でも自宅からどこまで淡い天体が出るのかの検証の一環になります。


ところが、撮影後に長い迷走状態に陥りました。最低限の画像処理としてWBPPまではすぐに終わったのですが、そこからが長い長い。理由ははっきりしていて、何度やっても仕上がりが気にいらなくて、ほっぽらかしてしまっていたからです。

気に入らない理由もはっきりしていて、HαとOIIIに写るものがあまりにもはっきり区別されすぎていて、Hα起因の赤は赤だけでのっぺりしてしまうし、OIIIはそもそもメインのダイオウイカさえもあまりにも写らなくて、炙り出そうとしても画面全体がノイジーになってしまうからです。

とりあえずこちらを見てください。OIIIの5分露光1枚撮りで、ABEとDBEをかけてフラット化して、かなり強度に炙り出してみたものでが、ほとんど何も見えません。フラット補正の誤差レベルで出てくる鏡筒の迷光の僅かな明暗差よりも、星雲本体の方が全然淡いくらです。
2023_12_04_19_13_50_300_00s_g100_9_80C_0000_ABE_DBE_s

WBPP後にどうなるかというと、まあせいぜいこの程度です。OIIIだけで10時間25分あるのですが、強炙り出ししても高々これくらい出るのみです。
2392x1597_2x2_drizzle_2x_integration_ABE1_ABE6_DBE_strong

少しでもS/Nを稼ごうとして、ソフトウェアビニングをかけて、bin4x4状態にして、そこからdrizzleでx2をしています。これについては以前議論していて、上記画像はすでにその過程を経たものになってます。このレベルのノイズだと流石にいかんともしがたく、少しだけ画像処理を進めましたが、全く太刀打ちできませんでした。

こんな調子ですが、画像処理の基本的な方針だけは初期の方に決まりました。恒星はRGBをそれぞれ別撮りしたものから得ます。その結果Hαの恒星もOIIIの恒星も使わないことになります。なので、最初からリニアの段階でHαもOIIIも背景と恒星を分離してしまいます。HαとOIIIの背景と、RGBから作った恒星を、別々にストレッチして、あとから合わせることにしました。

OIIIですが、恒星分離するともう少しフラット化や炙り出しなどを進めることができ、やっとダイオウイカの形がそこそこ見える程度にまでなりました。
2x2_300_00s_FILTER_O_mono_dri2x_ABE1_ABE6_DBEDBEDBE_back_DBEDBE

背景の一部がボケたようになっていますが、DBEなどのフラット化の時になぜかボケてしまいます。どうやらこれは階調が僅かすぎて補正しきれないことに起因するようです。例えこれくらい出ていたとしても、AOO合成して処理しようとすると青と緑の背景があまりにノイジーになりすぎ、全く処理する気にならずに、ここで長期間放置状態になりました。

その後しばらくして、OIII画像は星雲本体のマスクを作ることができることに気づき、なんとかなると思い画像処理を進めました。今度はHαは赤のみ、OIIIは青と緑のみと、ものの見事に別れきっていることに気づいて、あまりに赤がのっぺりしてしまって、さらにはダイオウイカ自身も青一辺倒で後から乗っけたようになってしまい、これまた嫌になってしまって再度長期放置していました。

体調を崩してからまだ夜の撮影を敢行できずにいるので、未処理の画像をと思い、今回重い腰を上げました。スタートは以下の画像です。これとOIII画像から作った星雲本体と明るい青い部分のマスクを使います。
Image80

ただ、これだけだと赤と青共にのっぺりするのは変わらないので、途中からRGB画像のG成分を少し加えてみました。淡いですがG画像の背景に構造は残っているようで、緑成分がHαの赤と合わさって茶色の分子雲を作り出せればと考えました。このやり方が正しいのかどうかは疑問もあるのですが、例えばこれまでもかもめ星雲の時にHαにGBの背景を合わせて、赤の「のっぺり」を防いでいます。OIIIを使っていないのがポイントで、B画像とG画像の青と緑成分を使い色の階調を稼いでいます。また、網状星雲の画像処理ではε130DのテストとしてHαとOIIIのみでAOO合成していますが、これだと右側に広がる茶色の分子雲をどうやっても表現することができません。G画像を持ってくれば何か出せるのかなと考えていて、今回はその布石でもあります。同様のことはクワガタ星雲のAOO画像でも述べています。

初出でXに投稿した画像はマスク処理が功を奏して、やっとなんとかダイオウイカ本体が出てきたものでした。でもダイオウイカ本体から透けて見えるはずのHαの赤成分が全然出ていないことに後から気づきました。今から見るとちょっと恥ずかしいですが、まだ苦労している途中の習作ということで出しておきます。
Image80_3_cut

次に投稿したものは、青から透けて見える背景の赤に気をつけて処理したものです。
Image80_5_cut

その後、ソフトウェアビニングでbin4相当だったOIII画像を元のbin2に戻して、さらに青ハロの処理を間違えていたことと、ダイオウイカ本体以外にも青い部分は存在していることに気づき、青をさらに注意して、再度ほぼ一から処理し直しました。大体の処理方針はもう決まっていたので、再処理でもそこまで時間はかからず、最終的には以下のようになりました。

「Sh2-129: ダイオウイカ星雲」 
final4_cut2
  • 撮影日: 2023年12月4日19時13分-23時47分、12月8日18時53分-22時45分、12月29日17時56分-21時53分、12月30日18時5分-21時13分、2024年1月2日17時54分-20時47分
  • 撮影場所: 富山県富山市自宅
  • 鏡筒: TAKAHASHI製 ε130D(f430mm、F3.3)
  • フィルター: Baader:Hα 6.5nm、OIII 10nm
  • 赤道儀: Celestron CGEM II
  • カメラ: ZWO ASI6200MM Pro (-10℃)
  • ガイド:  f120mmガイド鏡 + ASI290MM、PHD2によるマルチスターガイドでディザリング
  • 撮影: NINA、bin2、Gain 100、露光時間5分、Hα: 28枚、OIII: 125枚、R: 11枚、G: 14枚、B: 11枚、の計189枚で総露光時間15時間45分
  • Dark: Gain 100、露光時間5分、温度-10℃、117枚
  • Flat, Darkflat: Gain100、露光時間 Hα: 0.2秒、OIII: 0.2秒、R: 0.01秒、G: 0.01秒、B: 0.01秒で全て64枚
  • 画像処理: PixInsight、Photoshop CC

背景が赤一辺倒、ダイオウイカ本体は青一辺倒というのから脱却して、少しだけですが階調を出せたのかと思います。処理途中は、かなり最後の方までイカ本体が少しでも見えたらいいくらいに本気で思っていましたが、結果としては正直自宅撮影でよくここまで出たと思います。結局イカ本体はある程度出てくれたので、こんな淡い天体の場合でも画像処理の手法としては存在するということが、今回学べたことです。

その一方、元々超淡くてノイジーなダイオウイカです。マスクを駆使して、相当な無理をして出していることを実感しながら処理していました。これだけ淡いと、環境のいい多少暗いところで撮影したとしても、画像処理には無理が出そうで、例えば他の方のダイオウイカ本体がかなり綺麗に出ている画像を見ても、よくよく見てみると多少強引に処理を進めたような跡が見てとられます。Xに投稿したときに海外の方から「このターゲットを狙う限り、みんな苦労して画像処理している」とか言うようなコメントがありましたが、本当にみんな苦労しているのかもしれません。

恒例のアノテーションです。
final4_cut2_Annotated1


以前に挑戦していた!?

どうせなのでぶっちゃけますが、実はダイオウイカ星雲は以前撮影していて、お蔵入りにしたことがあります。2021年11月のことです。FS-60CBにDBPフィルターをつけて、EOS 6Dで撮影しました。

DBPで胎児とハート星雲を撮影してみて、結構出るのでこれならダイオウイカでもなんとかなるかなと思って意気揚々と3日に渡り撮影しました。1枚当たりの露光時間はたっぷり10分で82枚、合計で13時間40分です。下の画像は、試しにWBPP後、フラット化だけしたものですが、何個もある黒い穴はホコリなので無視するとして、強炙り出ししても心の目で見てやっと青いイカが確認できるくらいです。

600_20s_FILTER_NoFilter_RGB_drizzle_1x_ABE_ABE

ホコリの跡が目立ったのもありますが、このイカさんの淡さ見て画像処理をする気にもならずに、諦めてしまいました。でもこれが広角の明るい鏡筒でナローバンド撮影をしたくなった強烈な動機になり、それから1年ちょっと経った時にε130Dを手に入れています。(追記: 改めて過去記事を読んでみると、DBPと6Dで胎児とハート星雲を撮影してうまくいったので、次にDBPでスパゲティー星雲を撮影しようと思ったみたいです。でもスパゲティーの前に6D+DBPでダイオウイカに行って上の画像のように打ちのめされて、そのままスパゲティーに行かずに、一旦ε130Dに走ってスパゲティーを撮影して、やっと今回のダイオウイカに戻ったということみたいです。)

今の技術で2年前のダイオウイカを画像処理したらどうなるか、ちょっと興味が出たので、少しだけ挑戦してみました。念の為一からWBPPをかけ直して、ABEとGradientCorrectionでフラット化して、SPCCをかけて、BXTをかけて、リニアの状態で恒星と背景を分離するなど、基本方針はナローで撮った時と同じです。ところが、適当にストレッチしてからダイオウイカ本体の処理のために青のマスクを作ろうとしたのですが、あまりに淡くてノイジーで背景と分離することができずに、結論としてはマスク作成不可能ということで頓挫しました。やはり今の技術を持ってしても、無理なものは無理と分かっただけでも収穫かもしれません。

結局年単位の長期計画になったのですが、改めて明るい鏡筒まで手に入れて、今回ナローでイカを撮った甲斐があったというものです。


PixInsight1.8.9-3のFBPP 

ちょうど6Dの画像処理中の6月24日、PixInsightのメジャーアップデートのお知らせがメールで届きました。目玉の新機能が多数枚の画像の速い処理を可能にするFastBatchPreprocessing(FBPP)と 、色バランスをGaia DR3データと比較して合わせるSpectrophotometricFluxCalibration (SPFC)でしょうか。とりあえずFBPPだけ試してみました。WBPPとの簡単な比較ですが、興味がある人も多いのではないでしょうか。

あ、その前に、1.8.9-3にアップデートした時点でプロジェクトファイル内に保存されていたWBPPのインスタンスが再利用できなくなったので、使い回しができなくなり新たに一から作り直す必要がありました。ダークとかフラットを登録済みで便利だったのに、また登録し直しでちょっと面倒でした。アップデートする方はこの点注意です。

1.8.9-3のインストール後、使えなくなったのはStarNetのみでした。これは前バージョンのPixInsightを消さずにフォルダ名だけ変えて残しておいて、1.8.9-3を元と同じ名前のフォルダにインストールし、古いフォルダ以下に残っていたファイルを新しい方にコピペしました。どのファイルをコピペすればいいかはここを参照してください。コピペでファイルの権限などもそのまま写されるので、このページにあるchmodなどの属性変更は必要ありませんでした。

さて処理にかかった時間の結果ですが、WBPPとFBPPで比較します。ファイルは全てEOS 6Dで撮影したカラー画像です。ファイル数は全く同じで、LIGHTが82枚、FLATが32枚、FLATDARKが32枚、DARKが106枚、BIASは以前に撮ったマスターが1枚です。

まずはこれまでのWBPPでかかった時間です。WBPPはdrizzle x1やLN Referenceなどもフルで実行しています。やっていないのはCosmeticCorrectionくらいでしょうか。トータルでは45分強かかっています。
20240621_WBPP_time2

一方、FBPPは設定でほとんどいじるところがなくて、ここまでシンプルになると迷うことが無くなるので好感が持てました。PixInsightの設定の多さや複雑さに困っている人も多いかと思います。私は多少複雑でも気にしないのですが、それでもこれだけシンプルだとかなりいいです。トータル時間は約11分です。
20240621_FBPP_time2

結果を比べると、Fast Integrationと出ているところは元のIntegrationなどに比べて3倍程度速くなっていますが、Fast IntegrationはLIGHTのみに使われていて、その他のDARKなどのIntegrationには使われないようです。Debayerも5倍弱と、かなり速くなっています。他の処理は元と同じ名前になっていて、かかる時間はほぼ同じようです。その代わりに余分な処理数を減らすことでトータルの時間を短縮しているようです。トータルでは4分の1くらいの時間になりました。

ここから考えると、LIGHTフレームの数が極端に多い場合は、かなりの時間短縮になるのかと思われますが、アナウンスであった10分の1は少し大袈裟なのかもしれません。

処理数を減らしたことに関してはdrizzleを使わないとか、ImageSolveで位置特定を個別にするとかなら、ほとんど問題になることはないと思われます。出来上がりのファイル数も少なくて、操作もシンプルで、FBPPの方がむしろ迷わなくて使いやすいのではと思うくらいです。


今後の改善

ダイオウイカですが、2年くらい前の撮影から進歩したことは確実です。機材が違うのが第一です。ソフトウェアの進化はそこまで効かなくて、以前の撮影の無理なものは無理という事実は変わりませんでした。

さて今後ですが、これ以上の改善の可能性もまだ多少あるかと思います。例えば今使っている2インチのOIIIフィルターはBaaderの眼視用なのですが、透過波長幅が10nmと大きいこと、さらにUV/IR領域で光を透過する可能性があり、まだ余分な光が多いはずです。実際、フラット撮影時にBaaderの撮影用のHαとSIIフィルターと比べると、OIIIのみ明らかに明るくなります。また、明るい恒星の周りにかなりはっきりとしたハロができるのも問題です。これらはきちんとした撮影用のOIIIフィルターを使うことで多少改善するかと思います。この間の福島の星まつりでやっと撮影用の2インチのOIIIフィルターを手に入れることができたので、今後は改善されるはずです。

また、今回OIIIに注力するあまり、Hαの枚数が5分の1程度の25枚で2時間程度と短かったので、もう少し枚数を増やして背景の赤の解像度を増すという手もあるかと思います。

G画像だけはもっと時間をかけて淡いところを出し、分子雲を茶色系に階調豊かにする手もあるかと思います。これはナローバンド、特にAOOで緑成分をどう主張させればいいかという、今後の課題になるのかと思います。

あとは、やはり暗いとことで撮影することでしょうか。いくらナローバンド撮影と言っても、光害での背景光の明るさが変われば、OIIIの波長のところでも違いが出るのかと思います。特にS/Nの低い淡い部分は効いてくるでしょう。


まとめ

2年前に心底淡いと震撼したダイオウイカですが、自宅でのナロー撮影で、まあ画像処理は大変でしたが、これだけ出たのは満足すべきなのでしょう。でももう、自宅ではここまで淡いのは撮影しないと思います。もう少し明るいものにした方が幸せになりそうです。無理のない画像処理で、余裕を持って階調を出すとかの方が満足度が高い気がしています。



最近VMwareのProが個人利用なら無料になるというニュースが流れてきました!


MacのCPUがまだIntelだったころは、Boot CampやParalles、VMware、VIirtualBoxと、仮想化ツールを使っていました。電視観望では別のWindows PCを持っていくのですが、再起動して立ち上げるBoot Campや、VMwareからBoot Camp領域にアクセスした仮想PC上で電視観望を敢行したこともあります。

でもM1 Macを使い出した当時からBoot Campは全く使えなくなり、仮想でもArm対応だけで、一般のソフトの対応はあまり進んでいないという状態でした。でも今回調べてみたら、どうやら特殊なソフトでない限り、一般のソフトは結構普通に動くということのようです。これは再びMacでSharpCapを使っての電視観望で使えないか、また試したくなってきました。私はお客さん相手の観望会の時は、トラブルがあることを考えてWindows PCを2台持っていくことにしています。MacでSharpCapが動くなら、少なくとも持っていくPCを1台減らすことができます。


VMware Fusion

VMware Fusionのインストール自身はいくつも記事が出ているので、ここではポイントだけ書いておきます。ちょっとクセがあり面倒です。以下のページがわかりやすかったです。


WMwareをダウンロードする際に、アカウントを別途作る必要があること、その際住所などを書かなければならないことがちょっと抵抗がありましたが、これはしかたないでしょう。元々VMwareを使っていたので、昔のアカウントがあるかと思っていたのですが、どうも残っていないようで、結局新たにアカウントを作り直しました。

Windows自身は指示に従ってVMware上でダウンロードするのが楽だと思います。私は上のページに辿り着く前にここを見てしまい、別途Windowsをマニュアルでダウンロードしました。


あと、VMware Toolsが上のページに書いてある方法そのままではうまくいきませんでした。VMware Toolsが入っているisoイメージをあらわにマウントしてやる必要があり、次のようにしました。
  1. Macの「アプリケーション」フォルダ内のVMware Fusion.appを右クリックして、「パッケージの内容を表示」でContents -> Library -> isoimages -> amd64を開き、その中にあるwindows.isoをデスクトップなどにコピーします。
  2. VMwareのメニューの「仮想マシン」から「CD/DVD(SATA)」 -> 「ディスクまたはイメージを選択」で先ほどのwindows.isoを選択
  3. 再びメニューの「仮想マシン」から「VMware Toolsのインストール」を選択して、出てくるダイアログで「Setup.exe」を実行することで、ビデオドライバーやネットワークなどがインストールされ、画面の解像度を変えることができたり、やっとネットワークに繋ぐことができるようになります。

ここまでくれば、もう普通のWindowsと同じです。CMOSカメラのドライバーをインストールしたり、SharpCapをインストールしたりしましょう。必要ならASCOMプラットホームやASCOMドライバーもインストールします。

さて、必要そうなドライバーやソフトのインストールまでは普通にできました。まずは実際にArm版のWindowsで各種ソフトが立ち上がるのでしょうか?ドキドキですが、SharpCapを立ち上げてみます。

おっ!普通に立ち上がるようです。とりあえずカメラが手元になかったので、仮想のテストカメラを選択してみますが、これは少なくとも普通に動くようです。Arm版でも普通に立ち上がるんですね。これだけでもすごいです。

スクリーンショット 2024-06-06 085517
Arm Windowsですが、まずはSharpCapに付属の仮想のテストカメラで、問題なく動きました。


カメラの認識がちょっと大変

さあ、次はカメラを用意して実際に接続してみます。USB機器を接続した時に、Macに接続するか、Windowsに接続するか聞かれます。ここはもちろんWindowsです。「ピロン」と音が鳴って、接続されたことがわかります。

次にSharpCapを開いてカメラの接続を試みようと思いますが、ここで問題発覚です。カメラが全く認識されていません。

カメラは電視観望でいつも使っているPlayerOneのUranus-Cです。ここでPlayerOneのサイトに飛んで上部の「Service」の「Driver and Software」のところを見てみると、なんと(2024年6月4日現在)「Camera native driver on Windows11 on arm (Windows11 in Parallels on Apple silicon Mac)」とあるではありませんか!早速リンクをクリックしますが、出てきたページによるとドライバーインストールの前に注意があるみたいで、どうやらドライバーの署名を強制的にオフにしなくてはダメなようです。


ドライバー署名オフ

ドライバーの署名のオフ説明画面に沿って進めればいいのですが、英語なので一応日本語に相当する部分を書いておきます。
スクリーンショット 2024-06-04 212405
下の4.のところの画面です。

  1. まずはWindowsの「設定」を開きます。今回入れたのがWindows11で普段はまだほとんどWindows10なので少し戸惑いますが、画面下部のタスクバーの中央のWindowsマークのスタートボタンを押すと出てくる、ピン留め済み一覧の中の、ギヤマークの「設定」を押します。ピン留め一覧に出てこない場合は右上にある「すべてのアプリ」を押して、「さ」行から「設定」を探して押してください。
  2. 最初に選択されている「システム」の中の、「回復」を押します。少し下の方にあるので気づきにくいかもしれません。その場合は少し下にスクロールさせてみてください。
  3. 「PCの起動をカスタマイズする」のところの「再起動」を押します。
  4. しばらく待って出てきた「トラブルシューティング」「詳細オプション」「スタートアップ設定」の順に進みます。ここで一度再起動します。
  5. さらにキーボードの数字の「7」を押すか、キーボードの「fnキー」を押してからそれを離すことなく「F7キー」を同時に押します。
  6. その後、再ログインするとやっとドライバーの署名がオフされた状態になります。
  7. 元のページの一番下にあったArm用のカメラドライバー(2024年6月4日現在でバージョン1.3.12.12)をダウンロードし、展開してインストールします。
  8. その際、「ドライバーソフトウェアの発行元を検証できません」とか出ますが、無視して、下の「このドライバーをインストールします」を選択します。
ちなみに、これらの署名オフの過程はドライバーをインストールする前にWindowsを再起動してしまった場合は、ドライバーの署名強制的にオフが解除されるので、また最初からやる必要があるそうです。


まだカメラが認識されない

ところがです、ドライバーインストール後すぐにSharpCapを立ち上げたのですが、まだ認識されませんでした。どうやら一筋縄ではいかないようです。PlayerOneのページにParalles用のドライバーとかと書いてあったので、もしかしたらVMwareでは動かないのかとあらぬ疑いを持ってしまいます。でも普通に考えたらArmで動くか動かないかがポイントで、それを動かす仮想のベースは関係ないはずです。

ここでZWOのカメラはどうなのか試してみました。まず普通にZWOのドライバーページからカメラドライバーをダウンロードしてインストールしましたが、これは予想通りで、カメラは全く認識されません。ZWOのページにはまだArm対応のドライバーは見当たりません。いろいろ検索してみると、ZWOのフォーラムの中に2021年ごろからArmに対する議論が活発になされていることがわかりました。2021年の初期の頃はRossetaを使ってMacOSの上で走らせたIntelベースのASIAirで動いたとかが議論の中心でしたが、途中2023年2月頃にArm用にドライバーをビルドできたとの報告がユーザー側から出てきます。その後いくつかビルド済みのドライバーがアップロードされていますが、PlayerOneの時と同様な署名オフ問題が存在してるようです。「しているようです」というのは、どうもこれらのドライバーはフォーラムにログインしなくてはダウンロードできないようで、唯一2024年4月24日の投稿にあったこのページがgoodleドライブ上にアップロードしてくれていて、ダウンロードすることができました。このドライバーは署名オフ問題を回避してあるらしいのですが、私は回避状態でインストールしてしまったので、確認は取れていません。

さて、このドライバーもPlayerOneのArm用ドライバーと同じように、普通にインストールはできたのですが、それでもやはりSharpCapで認識されません。どうもドライバーの問題というよりは、何かPlayerOneとZWOで同じような問題が起きているような感触です。ここで一旦諦めました。


ドライバーのマニュアル更新: PlayerOneの場合

冷静になってしばらく考えて、デバイスマネージャーで見たらどうかと気づきました。そういえばZWOのフォーラム上でもデバイスマネージャーのスクリーンショットが出ているのを思い出しました。やった手順を書いておきます。
  1. Windwos11のスタートボタンを右クリックして「デバイスマネージャー」を押して開きます。
  2. この状態でUranus-Cを繋ぐと「不明なデバイス」のところにでてきます。これはおかしいです。フォーラムの中のスクリーンショットによるとカメラは「イメージングデバイス」に振り分けられるはずです。
  3. 右クリックして「ドライバーの更新」を選び、「コンピュータを参照してドライバーを検索」を選びます。
  4. 次は「コンピュータ上の利用可能なドライバーの一覧から選択」を選びます。
  5. 次の画面の「互換性のあるハードウェアを表示」オプションは外してください。そうすると(上でPlayerOneのArmドライバーがインストールされている場合は)「PlayerOne」の選択肢が出てきて、それを選ぶとカメラの選択肢が出てきます。私の場合は手持ちがUranus-Cなので「POA Uranus-C Camera」を選びます。
  6. 「ドライバーをインストールしています」と出て順調に行くかと思いきや、ここでまた問題が発覚です。「デバイスのドライバーのインストール中に問題が発生しました」などと出ます。
  7. また失敗かと思いきや「閉じる」を押しますが、デバイスマネージャーを見ると今度はきちんと「イメージングデバイス」にUranus-Cが移動しています。
  8. もしかしてと思い、SharpCapを立ち上げてメニューの「カメラ」で確認すると、何とUranus-Cがきちんと出てきています。
  9. 実際にカメラを選択して接続完了後に画面を見ると、きちんとカメラで写した画像が出てきました。ROIを最大画角で見てもフレームレートは46fpsくらい出ていてます。スピード的には十分で、少なくとも電視観望レベルで問題になるようなことは全然なさそうです。
あ、SharpCapでカメラに接続時に1-2度フレームレートが0のままや、上がらないことがありました。USB接続の不良(2.0で繋がってしまったとか)もありますので、繋ぎ直すと解決することがあります。私はケーブル再接続で直り、その後は何度か繰り返しましたが全く問題なく安定に動いています。

というわけで、問題は接続したカメラにドライバーがきちんとあてられておらず、ドライバーを更新して手動であえて正しいドライバーを選択してやる必要があったということです。でもこのような問題は、いずれ時間と共に解決するはずなので、今だけの問題なのかと思います。


ドライバーのマニュアル更新: ZWOの場合

さて、PlayerOneのカメラは上のようにすればOKだったのですが、ZWOはさらにひとひねり必要でした。ドライバーがきちんと当たっていないのは同じなので、上の3までは同じです。4のところで今度は「コンピュータ上のドライバを参照します」を選び、ZWOのArmドライバーがインストールされたフォルダ、例えば私の環境では

C:\Program Files (x86)\ZWO Design\ZWO_USB_Cameras_driver\driver\arm64

を選択します。要するに、まだWindowsのシステム内にもドライバーがうまくインストールされていないみたいです。今のところはユーザーがビルドしたオフィシャルでも何でもないドライバーなので、ある程度は仕方ないですね。

これで上の6以降に合流し、同じように文句は出ますが、「イメージングデバイス」に移動しているはずです。これでSharpCap上で接続(今回試したのはASI294MC)して、画面にきちんと像が出てくることを確認できました。フルサイズで12fpsくらい出ているので、仮想OSで動かしていると考えると、こちらも十分な速度かと思います。


Window再起動後の問題

ところがところが、まだ問題が残っています。Windowsを再起動すると、どうも署名オフの効果が消えるみたいで、ZWOのカメラのみ、再接続するとデバイスマネージャー上のASI294MCが、イメージングデバイスには置かれているのですが、三角の警告マークが出てきて、プロパティを見ると「このデバイスに必要なドライバーのデジタル署名を検証できません。... (コード 52)」などと出てきます。この場合、署名オフのプロセスを再度実行しなくてはダメなようで、再起動のたびにこれを繰り返すのは少し面倒です。

一方、PlayerOneのカメラはそのような署名オフ問題は再度出てこないので、こちらはWindowsを再起動しても問題なく再度カメラを使えています。

というわけで、カメラのインストールは少し大変ですが、PlayerOneのカメラは問題なく使えますし、ZWOのカメラはインストールはもう少しだけ手を加えることと、あとはWindos再起動のたびに署名オフのプロセスを繰り返す必要なことが大変でしょうか。でもそこだけ我慢すれば一応使えるというのが今の所の結論です。


SynScan ProとASCOM関連

カメラの認識にかなり苦労したので、その後のSynScan Proとか、SharpCapからSynScanアプリを動かすASCOMドライバー関連がかなり心配になりました。

まずはSysScan Proです。ダウンロード、インストールして、ミニマム電視観望の定番のトラバースで試してみました。ポイントは、WindowsのネットワークアダプターがMacのものをそのまま仮想的に利用しているので、Windowsから見たら一般的なイーサーネットアダプタとなっているということです。Wi-Fiではなく、あえて言うなら仮想的なLANケーブルに繋がったインターネット接続でしょうか。なので、トラバースに繋ぐのはMac側になります。MacのWi-FiでSSIDを見てみると、トラバースらしきものが見つかると思います。まずはここで繋ぎ、次にWindowsに行きます。SynScan Proを立ち上げて、接続を試みます。最初うまく検出できなかったので「ダメか?」と思ったのですが、通常のWindows単体での接続より少し時間がかかるようです。30秒程度掛け何度か接続を試していると、トラバースを認識して接続に成功しました!ネットワークアダプタの違いがあるので厳しいかとも思っていたのですが、これはあっさりし過ぎなほど簡単につながりました。

次は難敵ASCOMです。ドライバーに当たる部分なのでArmに対してはいろいろ未知数です。と覚悟を決めて試してみました。まずはSynScanアプリ用のASCOMドライバーをSkyWatcherのページから落として、インストールします。

SharpCapのメニューの「ファイル」の「SharpCapの設定」から「ハードウェア」タブを選び、「マウント」の「ハードウェアの選択」のところで出てくる「SynScan App Driver」を選び、下の「OK」ボタンを押します。あとは、右パネルの「望遠鏡制御」のところにある「接続」チェックボックスを押し、チェックマークを入れます。おお、何の問題もなく接続するではありませんか!!念の為「レート」を最大にして矢印マークを押すと、トラバースがきちんと動きました。ASCOMもあっさりし過ぎなほどうまく行きました。

やっと電視観望に辿り着いた!

ここまでくれば、もう電視観望も試せます。すべての接続がうまく行ったあと、夜を待って実際の電視観望を少しだけ試してみました。
IMG_9518

IMG_9515
このように、M1 Macbook ProでSharpCapを使って電視観望が普通にできています。

初期アラインメントと、途中何度かの導入の際はSharpCapからSharpSolveを使いプレートソルブをしていますが、これらも全く問題なく動きました。下のようにライブスタックも普通にできます。

スクリーンショット 2024-06-05 215006

スクリーンショット 2024-06-05 220445

スクリーンショット 2024-06-05 221602

スクリーンショット 2024-06-05 222127


簡単にできるかと思っていたArm Windowsでの電視観望ですが、思ったより手こずりました。同様のことを試そうと思っている方は、事前の明るいうちに接続関連をすべてクリアしてから夜に臨んだほうがいいかと思います。私はWMwareだけは昼にインストールしておいたのですが、カメラの接続を夜になってから始めたので、まるまる一晩潰しました。昼間もいろんなトラブルで、2日ほど費やしています。

一旦うまくいけば、Windows PCと比べても、全く遜色なく、いやむしろMacbook Proで画面とか大きいので、さらに快適に電視観望が楽しめます。あと、ブログをまとめるときも、すべての保存画像がMacから直でアクセスできて、Windwow-Mac間も普通にコピペできるので、これまでのようにわざわざ別PCから画像を移動する必要もなく、こちらもむしろ快適だったりします。

ここまでくると、あと出来なさそうなのは太陽とかのミリ秒スケールの短時間露光撮影でしょうか?さすがにフレームレートがそこまで出ないことが予想できますが、面積の小さいカメラを使うので実際どうなのでしょうか?太陽撮影はASI290MMでZWOカメラなのでちょっと面倒かもしれませんが、時間があるときに試してみたいと思います。


まとめ

というわけで、M1 Macで個人利用が無料になったVMware fuisonを使い、Arm64版のWindows11を仮想OSで動かし、電視観望ができるか試しました。カメラ関連はドライバーのインストールとカメラの認識に多少手こずりましたが、少なくともPlayerOneのカメラでは問題なく、ZWOのカメラではWindows再起動時に毎回署名オフのプロセスを踏む必要はありますが、フレームレートも含めて十分なスピードで使うことができます。実際の電視観望も、SynScan Pro、ASCOMプラットフォーム、ASCOMドライバーも全く問題なく動き、ネットワークアダプターもMacでトラバースに繋ぐことさえ注意すれば、問題なく接続し、プレートソルブも含めて動かすことができることがわかりました。

MacユーザーでBoorCampが使えなくて困っていたユーザーは、今回無料になったVMwereを使うことでコストパフォーマンスよく、Windows PCを別途用意することなく、Mac上のArm Windows11で電視観望まですることができます。


M104の画像処理も終わり、補足も含めてブログ記事も書き終えたと思って安心していました。


次に撮影したヘルクレス座銀河団の画像をチェックしていたら、なんとM104をさらにもう1日ぶん追加で撮影していたことに気づきました。その日のシンチレーションが悪ければ無視していいのですが、こういう時に限ってなぜか有意にいいのが撮れてしまっているんですよね。


まずは画像のチェック

SubframeSelectorで個々の画像のFWHMを見てみます。L画像を3日間撮影しているので、それぞれL1、L2、L3とします。前回までで、L1がFWHM = 13pixelくらい、L2は20pixelくらいで、L1にL2から特に悪いものを除いたものを画像処理に回しました。L2の内、特に悪いものは20pixelよりもさらに悪く、残ったいいものでも20pixel程度だったので、L1とは明らかに差があるものを混ぜて処理してしまいました。それでも、実際インテグレートした画像のFWHMを測っても、そこまで有意な落ちがなかったので良しと判断しました。

FWHMを順に見ていきます。まずはL1です。133枚あって、前回までの画像処理では全て使いました。ここでは後に見たL3の基準に合わせた判断をしてみていて、FWHMが12以上、もしくは星の数が35以下なら弾くと判断しています。赤のx印はダメだという判断で、撮影したL1の133枚のうち40枚が残るという判断です。この判断は後で使います。_
SS_L1

L2は酷いもので、上の判断に従えば全滅です。これでも前回はBlinkで見た目判断でダメなものはすでに捨てていて、その残りの56枚でこの結果です。
SS_L2

最後はL3です。新たに発掘された4月12日に撮影したものですが、FWHMだけ見ても9以下のものもあり、L1と比べても全然いいのがわかります。途中時間が経つと悪くなってしまっているので、FWHMが12以上、もしくは、星の数が35以下は使わないという判断をここでしました。FWHMが12という理由は、前回の主にL1のFWHMが13程度だったので、それよりもいいものを使おうということ、星の数は、飛び抜けて数が少ないものを捨てようという意図です。L1にも同様の判断をしたものが、上の図の結果というわけです。L3は全部で139枚撮影して、そのうち24枚除いた115枚を採用しています。
SS


L1とL3の画像で比較

L2は論外なので使わないとして、まずはL1を全て(赤のxは無視して)使った場合と、L3を基準内で使った場合を比較します。それぞれWBPPでインテグレートしてできたL画像に、ABEの4次とDBEをかけて、BXTのCorrect onlyをかけ、その後BXTの星の縮小を0.5、ハロは0、PSFはオートで、背景は1.0をかけます。2枚ともインテグレート後も全て同じ条件で処理しています。

できた2枚の画像を前回締めしたハッブルの画像とほぼ同じ位置で切り取り、重ねてGIF画像で切り替えて見えるようにしてみました。
L1

違いがわかりますでしょうか?ぱっと見どこが違うかわかりにくいかもしれませんが、じっと見てるとモヤっとしてるか、星になっているかなど、違いが見えてくると思います。恒星が大きく見えるのがL1、小さく見えるのがL3です。BXTを同様にかけても、出来上がりの恒星の大きさは元の恒星の大きさに依るということがまずわかります。

上の画像だとちょっとわかりにくかもしれないので、L1でBXTに拾われなくて、L3でBXTに拾われたと思われる恒星を拾ってみました。
L3_marked
もしかしたら取りこぼしているものもあるかもしれませんし、判断が難しいものもありましたが、とりあえず24個と少なくとも無視できないくらいの数の違いがあります。

これらは最終処理で見える星として生き残るものです。一方、モヤモヤしていてまだBXTで取りこぼしてしまっているものも多数あることもわかります。これらは最終処理では背景に埋もれてしまい、星として見えることはないですし、モヤモヤも背景をある程度明るくしないとわからないので、実質的には表には出てこないでしょう。それでも、どれだけシンチレーションがいい日に撮影したとしても、BXTを使う限り、その閾値の上下で星として生き残るか無視されてしまうかが決まってしまうのかという問題は、今のところ避けることはできないようです。かといって、BXTを使わなければ、さらに多くの星が星として成り立たずに背景に埋もれてしまうので、今の所BXTを使う方向でいくほうが有利なのかと思います。

いずれにせよシンチレーションでBXTの有効範囲が大きく変わり、シンチレーションがいいほどより多くの恒星を救えることがわかりました。

一方、銀河本体はというと、あまり目に見えては改善しているように見えませんが、それでも細かいところを見てみると少なくとも何か改善はあるように見えます。


L3画像に同基準のL1画像を加えてみる

次に興味があるのが、L1にL3と同じ採用基準でいいと判断した画像を、L3画像に加えてインテグレートしたものを考えてみます。せっかく撮影した画像をできるだけ使いたいというもったいない精神です。

枚数は元のL3が115枚で、同条件で採用されたL1が40枚です。枚数が(115 + 40) /  115 = 1.38倍に増えたので、S/Nは√1.38 = 1.16倍くらいよくなるはずです。インテグレーション直後の画像でPIのScript -> Image Analysis -> SNRView (PI上にロードしてある画像のS/Nを一度に評価してくれる)比較してみると、L3のみのS/Nが41.24dB、L3+L1のS/Nが42.65dBでその差は1.41dB = 1.176倍になり、ほぼ枚数増加で期待されるS/Nの増加となっていることがわかります。

これで気を良くしたので、恒星の数も増えると期待して、改めてL3だけの画像と、L3+L1の画像を同様にGIFで比較してみます。
L3_vs_L1L3

こちらはさらに変化がわかりにくいですね。なのでこれも同様に、変化のあった恒星を丸で囲みました。非常に面白い結果です。まず、青丸がL3+L1でBXTに構成として認識されずL3のみのときにBXTで認識されたと思われる恒星です。数を数えると12個もあります。黄色の丸は逆にL3+L1の方がBXTで救い取られている恒星ですが、こちらの方が数が圧倒的に少ないです。撮影枚数の少ないL3だけの方が、恒星に関してはより分解能が出ているということで、S/Nとは逆転現象が起きてしまっています。
L3_vs_L1L3_marked

ちなみに紫色の丸はL3とL3+L1で位置がずれてしまっているものです。BXTで何らかの認識はされたのですが、補正が必ずしもうまくいっていないということでしょうか。どちらの位置があっているかはわからないですが、そもそもたまたま量画像で星の一致しているからといって、必ずしもその位置が正しいかどうかはわかりません。元々相当暗くて淡くて広がってしまっている星です。シンチレーションで星の位置がぶれていたり、インテグレートする時に画像を歪ませていることもありするので、この結果だけでBXTに問題があるというのは早計でしょう。これらのことについては、別途きちんと定量的な評価をすべきかと思います。


S/Nと分解能の関係は?

さて、このS/Nと恒星の分解能について少し考えてみます。私は最初単純に枚数が多いL3+L1の方がS/Nもよくなり、分解能も良くなると思い込んでいました。S/Nは数値的にもほぼ理論に従いましたが、分解能に関してはL1を加えた枚数が多い方が悪くなってしまっているようです。

このことについては、ラッキーイメージ的な解釈である程度納得することができました。L3に加えたL1画像は、基準が同じといってもL3と比べたら、L3の中でもかなり悪い画像に相当するものなのかと思います。ここでいう悪いというのは、FWHMが12に近い大きなもので、星の数も少ない方という意味です。たとえ枚数が少なくても、いい画像のみを集めて使うラッキーイメージと似たことが起こったと思うと、S/N(明るい信号部分と暗いノイズ部分の比)は悪くても、明るいところの分解能は得をするということでしょうか。

こう考えると、S/Nと分解能は結構独立で、別個のパラメータと考えた方が良さそうです。今回はL3をFWHMが12以下で区切って使っていますが、銀河部分をメインに考えるとS/Nは十分取れているので、もっと枚数を減らしても良いのではと考えることもできます。FWHMの基準を厳しくしたほうが、元々の目的のM104の内部の構造を出すという目的からは、正しいのではないかと推測できるわけです。

でもこれをどこまで攻めてもいいのか?S/Nをどこまで落としてもいいのかの基準がよくわからないので、判断が難しいです。例えばL3画像でFWHMを10以下として、枚数は半分程度に減ってしまうかもしれませんが、実際に試して画像処理までしてみるのは価値があるかもしれません。

と、ここまで記事を書いて疑問に思ったので、焦らずに疑問はできるだけ解決するということで、実際に試してみました。条件はSubframeSelectorでL3画像のうちをFWHM10以下、かつ星の数が50以上のものを採用するとしました。枚数的にはFWHM12以下、かつ星の数が35以上だったときに115/139枚だったのが、44/139枚と、3分の1強くらいになりました。これで全く同じ条件でWBPPをかけインテグレーション直後でまずはS/Nを測定してみると、115枚だった時が上でも示しましたが41.24dBで、さらに女権を厳しくした44枚の方が37.57dBでした。115枚と44枚から計算したS/Nの改善比はsqrt(115/44) = 1.62です。一方インテグレーションした画像の実測値での比は41.24 - 37.57 [dB] = 3.67 [dB] = 10 ^ (3.67 / 20) = 1.53となるので、1.62から少しだけずれますが、まあ誤差の範囲内で一致してるといっていいでしょう。

では同様にL3で115枚使った時と、44枚使った時を、GIFアニメで比較してみます。
L3_115_L3_44
S/Nで高々1.5倍程度の違いなのに、大きく違って見えます。違いを挙げてみると、
  1. 115枚の方が、恒星が大きく見えて、44枚の方は恒星が小さく見える。
  2. 44枚の方が背景がノイジーで荒れている。
  3. 44枚の方はBXTで救いきれていない、取りこぼしている恒星が多い。
  4. 銀河本体の評価は難しく、一見44枚の方が細かいところまで出ている気もするが、ノイジーなだけの気もする。
1. 恒星の肥大に関しては、FWHMが小さい44枚の方が(同じパラメータの)BXTをかけた後でも小さくでるので、FWHMだけで判断してしまっていいでしょう。やはりラッキーイメージ的なFWHMが小さいものを選ぶのは、恒星の鋭さでは結果的にも有利です。

2. 見かけの背景の荒れ具合はどこまで炙り出したかだけの問題なので、背景が荒れ荒れに見えるのは気にしないでください。同じS/Nの画像でも強炙り出しすれば荒れて「見えて」しまいます。

3. それよりもここで重要なのは、暗くて淡い恒星の出具合が全く違ってしまっていることです。明るい恒星は元々S/Nが高いので、2枚の画像であまり差はないですが、暗い恒星はS/Nが低いのでNの影響をより大きく受けます。

例えば、115枚インテグレーションした画像の中で、BXTでギリギリ生き残った星のS/Nをインテグレーション直後の画像で測定すると (実際は淡い星の範囲を決めるのが難しいので測定もなかなか難しいのですが)、少なくとも2から3くらいはあります。一方、115枚画像で生き残った同じ星と同じ位置の、44枚の画像で生き残らなかった星のS/Nを測定すると1から1.5程度で、優位に差があります。115枚の時に2とか3あったS/Nが、枚数が44枚と少なくなりノイズが1.5倍ほど上がり、S/Nも1.5分の1ほどになり、恒星として認識されなくなったということかと思います。

このように、高々1.5倍程度のわずかなノイズの増加が、淡い部分には決定的に効いてしまうわけです。

4. 構成のFWHMが小さいと背景の分解能もより出ているはずですが、いかんせんノイズのNが悪くて判断がつきにくく、全体としては44枚の方が不利と言っていいでしょう。


こうなるともうラッキーイメージで枚数を制限するか、S/Nを稼ぐために多少FWMHは悪くても枚数を増やすかは、トレードオフですね。恒星の鋭さを取るか、淡い恒星が残るのを取るかです。銀河本体も同様にトレードオフかと思います。要するにその場その場に置いて、どちらを取る方が有利か判断して決めるべきなのかと思います。しかもインテグレーションまでしての判断なので、手間も時間もかかり、きちんとやろうとするとかなり大変になりそうです。

それよりも、これ以上の劇的な改善を考えるとすると、
  • 同等のシンチレーションのいい日に、より多くの枚数を撮影するか
  • 同等のシンチレーションのいい日に、より暗い空で撮影するか
だと思います。今のノイズは光害によるスカイノイズが支配的なので、このスカイノイズを改善する方法を考えるべきだということです。言い換えると、ここまで来てやっと自宅の光害が問題になるレベルに辿り着き、やっと暗い場所で撮影するべきかどうかの議論する価値が出てきたということなのかと思います。これまでは基本自宅撮影が多くて、今回のM104は系外銀河で背景を気にしなければ銀河本体はそこそこ明るいので、自宅でも十分だと思っていました。今のところ自宅だと厳しいと思ったのが、
  • M81を撮影した時のIFN
  • Sh2-240やダイオウイカなどのものすごく淡い天体を撮影した時
ですが、今回の
  • 系外銀河周りの恒星を出したい時
が新たに加わり、3つになりました。

まだ暗黒帯とかにあまり手を出していないので、ここら辺もいずれ暗いところを求めることになるかと思いますが、徐々に自宅撮影の限界が見えてきたということだと思います。今のところ頻繁に遠征に行くのは時間的に厳しいので、貴重な遠征の機会を逃さないように、あらかじめ遠征時のターゲットをはっきり決めて置くことがこれからの課題でしょうか。


画像処理

FWHMを12ピクセルで切ったL3のみ44枚でインテグレートしたL画像と、前回までの画像処理で使ったRGB画像を使って、画像処理をしてみます。

比較しやすくするため、ハッブル、今回、前回の順で並べます。
STScI-01EVT8YHAGM2WGQTV3DGKRFZ7Q

Image07_rot_Hubble_mod_cut

Image07_rot5_Hubble

恒星のシャープさは上がりました。救い上げた星の数は増えましたが、一部以前残っていた星が新たに消えてしまっているものもあります。でも、ハッブルの画像みたいに微恒星が一面に星が散らばっている様子からは程遠いので、ここら辺が次の課題でしょうか。

銀河本体は一部前回のほうが良かったところもあるように見えますが、基本的には今回の方が細部も出ていて、明らかに良くなっています。ハッブルの画像に多少なりとも近づいているのかと思います。どうやら改めて全画像処理工程をほぼやり直した甲斐はあったようです。

全体像も更新です。
Image07_middle

Image07_ABE1_crop_ABE4_DBE_BXTc_SPCC_BXT_LRGB_BXT_back_GHSx3_low
  • 撮影日: 2024年4月10日20時27分-4月11日3時18分、4月12日21時49分-4月13日0時46分
  • 撮影場所: 富山県富山市自宅
  • 鏡筒: SHARP STAR製 SCA260(f1300mm)
  • フィルター: 無し
  • 赤道儀: Celestron CGX-L
  • カメラ: ZWO ASI294MM Pro (-10℃)
  • ガイド:  f120mmガイド鏡 + ASI290MM、PHD2によるマルチスターガイドでディザリング
  • 撮影: NINA、Gain 120で露光時間1分でL: 115枚、R: 59枚、G: 51枚、B: 64枚、総露光時間289分 =4時間49分
  • Dark: Gain 120で露光時間1分が204枚
  • Flat, Darkflat: Gain 120で露光時間 LRGB: 0.01秒でそれぞれ128枚
  • 画像処理: PixInsight、Photoshop


まとめ

今回いろいろ試したことで、FWHMで分解能を評価できる手法はある程度確立できたのかと思います。やはりシンチレーションの影響は大きく、まずはいい日を選ぶことかと思います。その一方、淡い部分はS/Nの、特にノイズが大きく関係するので、全体の仕上がりとしてはFWFMだけでなく、枚数をある程度確保するか、スカイノイズを回避する必要があるのかと思います。

長かったですが、M104はとりあえずこれで完了とします。次回M104に挑戦するときは、暗い場所に行って撮影し、恒星がどこまで出るのか挑戦してみたいと思います。



今回の記事は座学です。太陽撮影でよく見ているプロミネンスですが、ほとんど何も知らないことがよくわかりました。関連する事柄を調べたので、メモがてら書いておきます。

そもそもの疑問は、黒点から出ていた2本の線ですが、Hαからズレたところで見えていて、Hαだと見えないと謎だったのですが、ドップラーシフトで青側に寄ったガスの噴出だということです。


でも、ズレたということは元々はHαのみで見えるということになりますが、太陽内部から出てくるときにHαで吸収されていると思っていたので、なぜHα以外の波長で輝度がないのかが疑問でした。要するに、このガス噴出と思われるものは、Hαの吸収線なのかHαの輝線なのかという疑問です。

このガスの前に、もっと身近で毎回撮影しているプロミネンスも同じ疑問が出てきます。縁(へり、リム)のところに出ているプロミネンスはご存知の通り、PSTなどの太陽望遠鏡でHαからズレると途端に見えなくなり、背景の黒だけが見えるようになります。この現象から推測すると、Hαでよく見え、周りの波長の輝度ははるかに小さい、輝線ということがわかります。

一方、プロミネンスが光球面上に存在すると、今度はダークフィラメントと呼ばれて、周りより温度が低いので暗く見えます。この場合はHαを見たときに、光球面の明るい周りの波長がカットされて残ったHαのみが見えるというわけです。この場合は二通り考えることができ、光球面の特徴的な模様とともにダークフィラメントも見えてくるような吸収線と考えることもできますし、そもそもHαのみに輝度を持っている輝線と考えることもできます。

では、そもそもプロミネンスってなんなのでしょうか?少し調べるとわかりますが、プロミネンスとは低密度で百万度以上の高温プラズマ中に浮かぶ、高密度の1万度程度の低温プラズマとのことです。ここでいう、高温プラズマとはコロナのことです。高度百万キロ程度の希薄なコロナの中に、プロミネンスが雲のように濃く存在しているということです。そしてその低温プラズマは採光面からの水素に照らされて吸収と放射を繰り返し、Hαで輝く輝線となるとのことです。太陽の縁のあたりに見えるプロミネンスの場合、背景は希薄なコロナで何も見えず(Hαやその周りの波長では輝いていない)、Hαで見るとプロミネンスのみが見えるということです。

ダークフィラメントも基本的には同じものですが、背景が光球面ということだけが違います。吸収と放射でHαに明るさを持つことは同じですが、背景が明るいためにHα以外では真っ白になってしまい、Hαのみを見ると温度の低いダークフィラメントが暗く写るということです。

プロミネンスがプラズマだったなんて全然知りませんでした。また、なんでHαのみで見えるのかの理由も深く考えたことはなかったのですが、輝線で輝いているということもはっきりわかりました。

このプロミネンスですが教科書レベルの本で調べると、大きく分けて静穏型プロミネンスと活動型プロミネンスの2種類に分けられるそうです。
  • 静穏型は数週間大体同じ形を保つもので、全体の構造はほぼ静止状態、ただし内部のガスは数km/秒くらいでゆっくり流れ落ちている。
  • 活動型は運動状態にあり数分から数時間で形を変えるもの。
我々が普段撮影するのはほとんどが静穏型なのかと思います。活動型は変化が相当速くて大規模な変化が多く、フレアとも大きく関係するため、その名の通り相当活発なもののようです。活動型はタイムラプスなどでは変化がよく見え、迫力ある映像になるのかと思います。

活動型はさらに以下のようにいくつかの種類に分けられるということです。
  • 噴出型プロミネンス
  • スプレイ
  • サージ(ジェット型プロミネンス)
  • ループプロミネンス(ポストフレアループ)
最初の噴出型プロミネンスは静穏型プロミネンスが突然不安定になり上昇や消失してしまう現象で、上昇速度は数百km/秒でかなり速いです。フレアとも関係があり、噴出型プロミネンスが発生するとフレア現象が起こることも多いそうです。

スプレイはフレアからガスがバラバラに飛び散りながら噴出する現象で、速度がさらに速く500-1200km/秒。噴出型プロミネンスとの違いは、噴出型プロミネンスは元々プロミネンスやフィラメントが存在しているのに対して、スプレイはフレア前にはプロミネンスもフィラメントもなかった(見えなかった)ということなので、明確な違いがあることになります。

さて、今回見た2本の線は、この分類からいくと「サージ」になりそうです。ジェット型プロミネンスとも呼ばれているようです。速度は数十から数百km/秒とのことなので、前ページで見積もった速度とも大方一致します。面白いのはこのサージも、噴出前にプロミネンスもフィラメントも存在しないことです。このことも、今回数分後に撮影したHαには少なくともフィラメントのようなものは見えなかったので、これも一致しているといっていいのかと思います。

さらに、プロミネンスとドップラーシフトで検索してみると、さまざまなページが見つかります。特に、天文台などの大型望遠鏡で撮影したデータから、ドップラーシフトで解析したというような高校の天文部などの記事も見つかります。この場合、Hαからの波長のズレがどれくらいかはっきりと分かっているので、逆に画像からプロミネンスの速度を求めようというような方向が多いです。

今回わかったことをまとめます。
  • 今回見た黒点からの2本の線は、サージもしくはジェット型と呼ばれる活動型プロミネンスの一種。
  • プロミネンスとは高温プラズマであるコロナに浮かぶ低温プラズマで、採光面からの水素に照らされてHαで輝く輝線であること。
  • サージは速度が数10km/sから数100km/sと速く、ドップラーシフトが起こり、地球から見た方向によって波長がHαから短い青側もしくは長い赤側にズレる。
  • PSTなどの太陽望遠鏡ではHαからわざとズラしてやることで観測できる。
これでかなりスッキリしました。

うーん、これまでプロミネンスとか黒点とか写っているだけで喜んでましたが、やはりその背景を知るとさらに楽しくなってきますね。もっと勉強すべきですが、こういった自分で撮影したものがきっかけでさらに調べていくというのは、とてもいい機会になるのかと思います。

今回撮影した不思議な現象の謎もほとんど解けたので、今回でサージ関連の記事は一応終わりです。次回もし書くとしたら、再びHαからズラしてみることを気にかけておいて、何か見えたときに再び記事にしようと思います。その際は、時間変動や波長依存性などを撮影することがきたらと思いますが、一度に両方は無理でしょう。今回のように、ここまであからさまなドップラーシフトしたサージをはっきり見た画像あまり数がないようで、そこそこ珍しい現象のようです。チャンスがあったらその機会を大切に撮影したいと思います。







非常に有益な情報が!

昨日の太陽撮影の記事に、hasyamaさんという方から早速有用なコメントをいただきました。どうやら黒点から伸びるあの謎の線は、ガスの噴出現象とのことです。

09_33_03_lapl2_ap1826_IP_cut

上昇方向で地球方向に向かってくるガスだとすると、ドップラーシフトで波長が青側に移るために、エタロンを波長が短くなる方向に回転すると、このようガスが見えることがあるということです。逆に、下降方向などで地球から遠ざかる向きの場合は赤側にシフトするとのことです。

コメントにはFacebookへのリンクも書かれていて、以前にも同様のものが波長がずれたLUNTで撮影されたとのことです。その投稿によると、やはりこのガスの噴出はそこそこ珍しいもので、あまり頻繁に撮影されているものではないようです。

今回は実際に何をみているのか、矛盾点はないかなど、自分なりに評価してみました。新たに疑問点が出たりしていますが、ある程度納得できたので記事にしておきます。


そもそもHαで何を見ているのか?

でもそもそも、なぜガスがHαで見えるのか、理由がまだよくわかっていません。光球面は納得できます。Hαに吸収線があり、Hαの653.6nmに合わせたエタロンでそこだけ透過させると、他の波長の明るい部分を除外することができ(吸収されながらも残った)Hα固有の光で作られる模様を見ることができます。要するに、吸収された光なのでHα部分は周りの波長より暗いということです。その一方、例えば彩層面からはるかに高いところまで写る派手なコロナまで含む30.4nmや19.3nmの光は、吸収線ではなく輝線です。すなわち周りの波長より明るいということです。

Hα領域の光は太陽表面に出てくるまでに吸収されるので、プロミネンスや噴出するガスも同様にHαに吸収線を持っていることは容易に想像がつきます。でも上で書いたように、Hα領域は周りの波長より暗いので、他の波長では明るく光っていることになります。光球面上は明るすぎるので、その明るさをエタロン除いてやるとHαがよく見えるようになるのはわかります。でもプロミネンスを見ている太陽の縁のところの背景は、光球面よりはるかに暗く、それに比べてHα以外の波長で明るいはずのプロミネンスが、エタロンの調整角をHαからずらしたら見えなくなるのかが、まだ理解できていません。

私の太陽の知識はせいぜいこれくらいです。まずはこの疑問を解決したいです。


波長のずれを見積もってみよう

とりあえず上の疑問は疑問として置いておくとして、その上で今回見えたガスも、プロミネンスと同様に元々はHαのみで見えるものなのでしょう。仮にそうだとして、エタロンで光球麺を見た時、狭い透過波長のみで見ることになるので、その周りの波長は暗く見えて、その結果ガスも見えることになるのかと思います。

この仮定の元、今回Hαからずらしたエタロンで見えたガスがドップラーシフトによるものだとして、ガスの速度から計算できる波長のズレと、エタロンの調整角から推定できる波長のズレが、一致するのか、それとも全然おかしいのか、簡単に評価してみたいと思います。

まずガスの速度からの見積もりです。
  1. ガスの長さは太陽直径の100分の1よりは大きくて、10分の1には届いていないくらいですが、ざっくり1/10とします。
  2. 太陽の直径はざっくり地球が100個並ぶくらいで、地球の直径はざっくり1万kmとすると、100万kmのオーダーです。
  3. なのでガスの長さはざっくり10万kmとします。
  4. ガスが伸びる時間は1分よりは長くて1時間よりは短いと思うので、とりあえず1000秒としましょう。
  5. そうするとガスの速度は10万km / 1000秒 = 100km/秒程度となります。
  6. 光の速度は30万km/秒で、それが100km/秒程度ぶん圧縮されるとすると、ドップラー効果で波長も同様の比率100/300000 = 1/3000くらいで短くなるので、653.6nmは0.2nm程度短くなります。

次にエタロンの回転で変わる波長です。
  1. PSTのエタロンの透過波長性能は、1Å = 0.1nm程度です。
  2. エタロンは半回転くらいしかしませんが、半回転の4分の1くらい回すと見えているHα領域がほとんど見えないくらいになります。ということは8分の1回転で変化する波長が1Å程度と考えてオーダー的にはおかしくないでしょう。
  3. 今回エタロンは波長の長い側か短い側かはわかりませんが、完全に端に回し切ったところにに行っていました。ということは、真ん中がHαに合っているとして、半回転のうちのさらに半分回っていたことになるので、4分の1回転回っていたことになります。
  4. 1/8回転で1Å = 0.1nmなので、4分の1回転回っていたとすると、エタロンでは2Åぶん、すなわち0.2nm程度Hαから波長がズレていたことになります。

おおっ!!

ものすごいラフなオーダー計算ですが、ものの見事に0.2nmで、両者ドップラー効果の波長のズレとエタロンの波長のズレが一致しました。多少のファクターのズレはありますが、少なくともオーダー的にはドップラー効果でHαからズレたガスを見ていたと結論づけておかしくなさそうです。


以前の撮影でもジェットが!

そういえば、以前もジェットのようなものを見たと報告したことがあるのを思い出しました。


この時はHαで見ていたはずですが、真横に出ているので地球方向に向かう速度成分はほとんどなかったのかもしれません。また、ジェットが数分で伸びていると書いてあるので、もしかしたらジェットの速度は今回見積もったものよりもかなり速いのかもしれません。ただし、それに地球方向の速度成分をかける必要があるので、それでもオーダー的にはそこまで間違っていないかと思います。


プロミネンスでも波長のずれは起こる?

ところで、プロミネンスもタイムラブスで見ると非常に高速に動いていることがわかります。下の動画は以前撮影したものですが、わずか19分間でこれだけ動いています。
Blink

プロミネンスの移動速度もそこそこ出ているはずで、地球に向かう速度成分も多少はあるとすると、エタロンを回転して調整する時に、いつも光球面とプロミネンス部でエタロンの最適位置が合わないように思えるのは、もしかしたらこちらもドップラーシフトが起こっているからなのでしょうか?


まとめ

簡単なオーダー見積もりでしたが、少なくともドップラー効果で波長がズレたものが見えていたようだということは納得しました。

でもまだなぜプロミネンスやガスがHαだけでよく見えるのかは納得できていません。どこかにいい説明はないのでしょうか?

でもこうやって、自分で撮影した謎の現象が理解できているというのは、とても面白いです。天文趣味の醍醐味の一つなのかと思います。






やっと退院して初の週末の土曜日。この日は一日快晴のようです。

病院では検査で毎朝早く起きていたので、その名残で朝早くに目が覚めてしまうのと、まだ外食も控えていていつものコメダも行けないので、朝から太陽を見ることにしました。そもそもGW中に大きな黒点が話題でしたが、寝ているだけで全く何もできなかったので、今回出てきた黒点でその不満がやっと解消されそうです。

最初に見えた謎の2本の線

セットアップはいつものC8+PST+ASI290MMで、それをCGEM IIに載せています。PCとカメラを繋いで太陽を導入し、まず最初に見えたのが「えっ???」と思った、黒点から飛び出ている変な2本の曲線です。リアルタイムの動画状態でもそのまま確認できます。

ピントを合わせて、次にエタロンの回転を調整しようとして気づいたのですが、見ている画像はHαから全然ずれていて、エタロンの回転の端まで行っているような状態で、ある意味白色光に近いような画像です。とりあえずAutoStakkert!4で1000フレームをスタックして、ImPPGで少しだけ細部を出す画像処理した物です。
09_33_03_lapl2_ap1826_IP_cut
2本の線がはっきりと確認できるかと思います。その後しばらくしてから気づいたのですが、手前側にも何か黒い模様が出ています。

最初はフレアかなと思いました。でも2分後に撮影したHα画像には何も写っていません。
09_35_24_lapl2_ap1975_IP_cut
フレアなら白いスパークのような模様があってもおかしくないと思います。同時刻で調べたのですが、特に何かフレアのようなイベントが起こっているようなこともなさそうでした。

X上でダークフィラメントが伸びているのでは?とのコメントがありましたが、こちらももしダークフィラメントならHα画像に暗い線が写っていてもおかしくないと思いますが、やはりそれらしいものは見当たりません。

先ほど白色に近いと書きましたが、エタロンでHαから外しているだけなので、結構Hαに近いことでしょうか。もしかしたらそれがヒントになるのかもしれませんが、今のところ謎のままです。


大きな黒点群と、大きなプロミネンス

その後はしばらくHα画像を幾つか撮影しました。見栄えのする黒点と、すぐその下に出ていた大きなプロミネンスです。

09_51_20_lapl2_ap2532_IP3_cut

09_50_58_lapl2_ap2516_IP_cut


モザイク合成に挑戦

かなり大きな範囲で黒点、プロミネンス、ダークフィラメントが出ていたので、東側をモザイク合成してみました。

all3_cut

結構頑張ったのですが、まだ境目がわかります。PSTは画面内でHα付近のいいところが限られるので、モザイクは相当難しいです。さらに一枚一枚を見て分かったのですが、どうも上部はピントが出ずに、下部のみピントが出ているようです。しかもこれ、撮影中はほとんど分からず、スタックしてImPPGなどで細部出しまでしてやっとわかるのです。

今回ニュートンリングが残っているのが分かったので、最初の方でカメラをチルトアダプターでさらに傾けました。そのことが原因でピントずれの部分が出ているのかもしれません。一度チルトアダプターの向きをかえて、もう少し小さいチルトでニュートンリングが消えるところがないかなど、一度探る必要がありそうです。


フィラメントとプロミネンス

これまでも何度かチャンスがあったのですが、縁の近辺にあるダークフィラメントから、連続して縁に出ているプロミネンスに続く画像をうまく撮りたいとずっと思っていました。でも画像処理が未熟で、その接続部、特に光球面側のフィラメントをうまく出して、明るさをプロミネンスに合わせる方法が確立できずにいました。

プロミネンスをぐるっと一回り見ている最中に、ちょうどうまく繋がっていそうな場所がありました。今回、光球面とプロミネンス部を別々に処理することで、うまく繋がるのが表現できたのかと思います。
09_46_57_lapl3_ap1360_IP_cut


白色光

その後、今度はNDフィルターを使って、本当に白色光で撮影してみました。PowerMATEの4倍を使っています。
10_01_51_lapl2_ap3240_IP2_cut

最初の変な線が出た撮影から約30分が経っていますが、時間が過ぎたせいなのか、本当に白色光にしたからなのかわかりませんが、あの目立っていた線は見えませんでした。今一度、エタロンをHαからはずして同様のものが見えることがあるのかどうか、試してみたいと思います。

白色光は粒状斑らしきものが少し見えてきています。動画時でもごく僅かそれらしいものが見えていました。以前、粒状斑がきちんと出るくらいの、シンチレーションのいい時の動画を見せてもらったことがあるのですが、今回はその動画には遠く及びません。そもそも、この30分ですでにシンチレーションが悪くなったようで、朝イチの時の方が(バローとかつけてないので)カメラの解像度としては悪いはずなのに、明らかに分解能が良かったように見えます。

実はブログに書いてこなかったのですが、休日で晴れている時はたいてい太陽撮影を敢行していました。ただし、休日の午前はほとんとコメダかガストに行っていたので、朝早くに太陽を撮影することは実は一度もありませんでした。なかなかいい結果が出ず、ほとんどお蔵入りになっています。今回入院でまだ外食は控えているのでたまため朝早くに撮影をしたのですが、朝の早い時間というのはやはりシンチレーションがいいのかもしれません。しばらくは日が長いので早い時間でも太陽は高い位置にくるはずです。できるだけ朝早くに撮影することを今後しばらくしてみようと思いました。


まとめ

久しぶりにブログを書く気になる太陽撮影でした。モザイクに時間がかかってしまい、記事にするのが遅くなりましたが、肝心なモザイクはまだ課題がありそうです。

やはり太陽はシンチレーションがかなり重要です。これまで動画の段階で粒状斑が出るようなのが撮れていなかったのですが、機材のせいかともずっと疑っていました(まだ疑っています)。でも朝早いとシンチレーションが全然マシかもしれないと今回思えたのは収穫でした。

今後は休日の晴れの日は、早起きして、撮影を済ませ、その後にコメダに行くことにしたいと思います。休日の天国のコメダは外せません。





このページのトップヘ