ほしぞloveログ

天体観測始めました。

2024年06月

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

「そこそこ」撮影

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

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


撮影したのはかなり前

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



2024年6月8日、福島県田村市の星の村天文台で行われた星まつりに、こっそりと行ってきました。こっそりとという意味は、GWに崩した体調が戻っていないくて、泊まり(特に車中泊)は全然無理そうなこと、富山から福島までは結構な距離があり運転時間が長くなるので、いまいち自信がなくて、寸前まで誰にもいくことを知らせていなかったからです。


迷いに迷って

IMG_9524
前日のうちに準備だけしておきました。今回は機材も少なめです。

実際直前の直前まで迷っていて、朝起きたときに調子が良ければ行こうと決めて、前日は準備だけはして睡眠時間を確保するために早めに寝ることに。朝4時頃に起きたら結構調子がよかったので、思い切って出発としました。退院後初の長距離ドライブですが、まあいざとなったら引き返せばいいでしょうと、これ以上はあまり考えないことにしました。ただ食事に制限があるので、途中のコンビニでお菓子を買い込むとか、新潟前の黒崎PAのスターバックスで大好きな抹茶クリームフラペチーノを頼むとかもできないので、途中のドライブがずいぶん味気ないものになってしまいました。いや、でも健康が第一です。倒れて趣味も何もできなくなったことを改めて思い出しました。

IMG_9527

午前7時頃でまだスターバックス開いてないと思ったら、甘いものが食べれないこんなときに限って、なぜか 朝からやってるんですよね...。


会場到着

車は順調で、最寄りの田村ICで高速を降り、会場に向かいます。田村ICはETC専用なので注意なのと、このICからだと会場まで10km程度なので、かなり便利です。

会場には10時前くらいに到着したでしょうか。でもいつ求める会場に近い方の駐車場は一杯で、階下のアスファルトの方に止めました。これまでは毎回金曜に来ていたので、駐車場の心配とかしたことなかったのですが、今回はそこまで機材を出さないでおこうと思っているので、こちらの駐車場で十分です。車を降りてもそこまで疲れているわけではなく、まだ十分楽しめそうです。

会場に到着するとちょうど開会式の最中でした。何人かの来賓の挨拶があり、開会式が終わると早速会場内を回ります。

そもそもなんで今回無理してでも参加したかというと、何人かの人と会って話したかったことと、昨年星もと小海で買えなかったOIIIフィルターを買いたかったことです。今回会いたかった人には、半分以上会うことができました。顔を突き合わせて気兼ね無く思ったことを話せるのは、やはりいいですね。電話とかメールでは伝わらないこともあるのと、やはりその場で何人かと楽しく話せるのは、星まつりならではの魅力です。

ブース廻りでは、まずはOIIIフィルターを手に入れておきたかったので、国際光器さんに行きます。事前に国際光器さんのウェブサイトに行って見たのですが、相変わらずBaaderのナローバンドフィルターはごく一部を除きほとんどが在庫なしでした。今回目的のOIIIフィルターも、あればラッキーくらいに思っていたら、店長さんが前回買えなかったことを覚えていてくれて、2インチのOIIIフィルターがつい最近入荷したと教えてくれました。星まつり価格で安かったです。こういうところで交通費分とかを多少なりとも相殺できるので、買い物目的で星まつりに来て、ついでに星まつりを堪能するというのもありだと思います。


外山電子さんに居候

次に外山電子さんのブースに顔を出しました。ユニテックさんの展示もしてあって、今回は昨年の胎内星もとに引き続き、お言葉に甘えてそこにほぼ居候することに。一応昨年展示したSWAgTiを、また今回も展示させていただきました。

IMG_9544

せっかくなのでユニテックさんの宣伝をしておきます。一つとても面白いアダプターがありました。新規開発品とのことですが、Vixen規格のアリミゾに取り付けることで、アルカスイス互換アダプターに変換できる、とてもコンパクトなアダプターです。下の写真の濃い灰色の部分をワンタッチで取り外しすることができ、Vixen規格とアルカスイス互換をすぐに切り替えることができます。反対側のクランプ部の角度は合わないと言ってましたが、それを補ってあまりあるコンパクトさです。

IMG_9537


北軽井沢観測所

ブースはちょくちょくといろんなところを時間をかけて見て周りました。今回星まつりならではの面白かったものというと、圧倒的に北軽さんのところでしょうか。望遠鏡に詳しい方はご存知かと思いますが、「北軽井沢観測所」という名前のアイピースメーカーで、もともと個人のこだわりで作り始めたアイピースを、周りの方のリクエストに答える形で製品化しているところです。

私のことをご存知の店長さんがわざわざ声をかけてくれ、見て欲しいものがあるというのです。それはなんと、縮小系光学を利用して明るさ8倍を実現するという、超ファストシステムです。機構自身は全然複雑ではなく、アイピースと、カメラ前に取り付けた明るいCマウントレンズ、それを繋ぐ筒です。

IMG_9552

実際にアイデアとして縮小光学系は試した人を何人か知っていますが、そこまでうまく行ってないようで、なかなか実用レベルにならないようです。でもそこはさすがの北軽さん、自分のところの超高性能長焦点アイピースと、計測レベルのCマウントレンズを組み合わせて、歪みを最小限に抑えているとのことです。

実際に電視観望という体で撮影された画像を印刷してあったので見せてもらいました。上の写真にに載っているM13もそうなのですが、M51もくっきり写っているものもあり、どれもトータル露光時間が秒のオーダーだそうです!それもそのはず、撮影したのが口径10cmでF8程度の鏡筒で、これが8倍の明るさになるのですからF1(!?!?!?)とかです。実際にはカメラ前に付けてあるレンズのF値で制限されるとのことですが、それでもF1.2とかのとんでもない値です。

ここまで明るいと、本当のリアルタイム電視観望ができそうです。元々電視観望はリアルタイムで、星雲などを含めて動く様子を見ながら星雲や星団を見ようというのがコンセプトでした。実際にはそこまで明るい光学系を揃えるのが大変なので、ライブスタックで総露光時間を伸ばして、ノイズを落としていくのが主流になっているという側面があります。ライブスタックなので、当然画角が動くようなリアルタイム性まではありません。この北軽さんのアイデアなら、「本当にリアルタイム」の電視観望ができそうです。こんな機材に出会えるので、星まつりの参加ははやはりやめられません。今回無理してでも書いた甲斐がありました。

他にもEDレンズを利用したアイピースも見せていただきました。私は眼視はあまり経験がないので、違いがわかるか心配だったのですが、ほぼ同じ設計でED有り無しで比較させてもらい、コントラストなどの違いがわかりました。暗いところがより黒く出るという感じです。これは特に太陽観測Hαに有効だとのことです。Hαは単色なのでEDでも違いが出ないのではと思いましたが、コントラスト改善という観点でいくと確かに納得できそうです。これも一度太陽で実際に見てみたいです。


Vixenさんが元気

最近Vixenさんがかなり元気です。2020年のここ福島でわざわざ私を訪ねて会いにきてくれた、当時はまだ新入社員に近かった Iさんが色々紹介してくれました。Iさん、今ではVixen内の望遠鏡関連の各種製品に関わっている、もう立派な中堅どころのようです。Vixen製品の中でやはり注目はVSDです。星沼会のメンバーの最近の試用レポートを見ても、素晴らしい仕上がりのようです。VSDは試作版の段階でもすごいという噂は聞こえてきましたが、星沼会では製品版を試してもらっているということ。量産の製品段階ででもきちんと安定して性能を出せているというのはVixenの技術力の高さを物語っているのかと思います。やはりフラッグシップモデルできちんと成果を出せるというのは、信頼がおけるという意味でもとても重要なのだと思います。

IMG_9531
別売り(初出で付属と書きましたが正しくは別売りです。訂正してお詫びいたします。)
のケースをかなり軽量に、
しかも中のスポンジ部にこだわって作ったとのことです。
専用ケースがついているのはいいですね。 

他にもCP+で展示してあった、VSDの廉価版にあたる70mm鏡筒と、筒の中の対物レンズが移動してフォーカスする65mmmの鏡筒が展示されていました。CP+ではフォーカサーを筒内に収めるかどうかまだ迷っていて、通常のドロワータイプと合わせて2パターン展示してあったのですが、どうやら筒内内部フォーカスに舵を切ったようです。しかも内部の位置を外から覗ける目盛窓のようなものをつける予定だとか。なかなか面白い製品になりそうです。

IMG_9533


太陽系

星見屋さんでデモしていたDaystarのGeminiもかなりインパクトがありました。プロミネンス用と光球面用の2つを楽しめるとのことで、話を聞くと半値幅を変えているとのこと。どうやって切り替えるのか不思議だったのですが、よくよく聞くとエタロンが2つ搭載されているとのことです。確かに切り替えて見てみると、プロミネンス用は明るく見え、光球面用は暗く見えます。この間のドップラーシフトの記事ではないのですが、プロミネンスはそこの速度で移動している可能性があり、波長がずれることがあるので、多少大きな半値幅で見た方が有利なのかもしれません。それにしても、エタロンを2つ組み込むとは。最初にわかに信じられませんでしたが、波長調整つまみも2つ付いていることからどうやら本当のようです。後でDaystarのサイトで調べたら、本当に2つエタロンを搭載していると書いてありました。結構びっくりでしたが、値段も当然その分2倍!とのことです。

IMG_9530
手前の2つのつまみがついているのが、2つのエタロン調整に相当するようです。

太陽望遠鏡は他にも会場のどこかしこにたくさん出ていました。SHOWAさんのところではLUNTのダブルスタックで半値幅の狭いHα像を見せてもらいました。屋上の望遠鏡でも太陽を見ていて、へりから飛び出したはぐれプロミネンスが出てたと話題になっていました。太陽活動期なので見ていても楽しいのかと思います。


食事事情

今回はキッチンカーがいくつか出ていました。食事系ではカレーが一台と、スパゲティ系が一台でした。昼食時はズラーっと長い列ができていました。かなり空いてきた15時頃に行ったのですが、いくつかのカレーはすでに売り売り切れで、私はスパイシーチキンカレーをいただきました。かなりおいしかったです。

IMG_9541

キッチンカーではないですが、毎年恒例のキノコの串焼きもあったり、食事系以外にもスイーツがあったり、コーヒーのキッチンカーも出ていました。

会場では毎年顔を合わせているでかでかまんさんのグループに色々ご馳走になりました。お好み焼きにはじまり、おでん、ベーコンなど、どれもとてもおいしかったです。朝会場に到着した時にメイン会場に近い方の駐車場が一杯だったのですが、でかでかまんさんには「機材出すんですよね?バイクが止まっている所を空けましょうか?」と親切に言っていただきました。今回はあまり無理をしない予定だったので、お礼だけ言って別の駐車場に止めることにしました。このメンバーには毎回福島では親切にしていただいて、とてもありがたいです。

止めた駐車場に荷物を置くなどして場所を確保しておけるなら、車で移動して会場から数km坂を降りるとコンビニがあるので、多少の買い出しはそこまで不便なくできます。コンビニの隣にはガソリンスタンドがあるので、帰りが夜遅くになる場合はあらかじめ昼のうちに帰りの分のガソリンを入れておくといいです。今回も行きがけにガソリンを入れておきました。


イベント

会場では各種イベントがあり、家族連れでも楽しむことができます。ビンゴ大会では大量の景品が用意されています。国立天文台の渡部潤一先生は福島が地元で、毎年この星祭りに参加され、面白い講演をしてくれます。今年も初日の金曜から参加されていたとのことです。ここ数年恒例になっている重力波の話もまたありました。私は「聞く」ことはできなかったのですが、周りの人に聞いたら結構面白かったとのことです。渡部先生は今年はなんと屋上のドームで星空案内もしてくれたとのことです。他にも天文台スタッフによる子供向け星空解説や、プラネタリウムを利用したコンサートや、ショップスタッフによる講演、夜にはオークションもありました。

1日目の金曜の夜はかなり天気が良かったようですが、私が行った2日目は夜は曇り気味でした。家族連れの方も夜までいると会場にたくさん出ている望遠鏡で、星や星雲、星団、銀河などを見せてもらえます。ただ6月は日が長いので、暗くなるのが少し遅くて、子供はその前に疲れて眠ってしまうかもしれません。でもせっかくの機会なので、夕方少し昼寝してでも夜の星空を見ると、より楽しめるかと思います。1日目は天の川も綺麗に見えたそうです。特に、メイン会場のみでなく駐車場側に出ている、全国から集まってきたアマチュア天文家の自慢の大型望遠鏡を巡ると、かなり楽しめると思います。普通ではなかなか見られないような天体を導入してくれているはずです。


ちょっとだけ電視観望

さて私はというと、元々は機材も出さずにおとなしくしてようと思っていました。ところが、ユニテックのスタッフさんから中高生の頃にNIKONの35mmのF1.4のレンズで撮影していたという話を聞いてしまったのです。「え?私、それまだ使っていますよ。今日持ってきてますよ。」と広角電視観望で使っている機材を車から持ってきたのが運のつきでした。「おー、これこれ!」とかなり盛り上がったのですが、その時ついでにFMA135とトラバースの通常の電視観望セットも持ってきてしまったので、結局暗くなる頃には電視観望の準備を始めることになってしまいました。

ちょうどこのブログの前の記事がM1 MacとArm Windowsでの電視観望だったので、せっかくだからM1 Macで試すことにしました。多分M1 Macで電視観望までやっている人は日本ではまだ私一人だと思うので、わかる人にはわかるセットアップで、結構受けていました。機材はいつものFMA135+Uranus-Cをトラバースに載せたミニマム電視観望セットです。あまりの小ささに、来た人みんな驚いていました。小さくて目立たないので、途中何度か気づかれずに蹴飛ばされそうになったり、鏡筒の前をブロックされてしまって、その度に「あー、そこ気をつけて!」とお客さんから声が上がっていました(笑)。

ただし雲がなかったのは最初の時間帯だけで、その頃はまだ夏の面白い星雲とかは山の下に隠れてしまって、大したものは見せることができなかったです。結局、M13:ヘルクレス座球状星団、M57:惑星状星雲、M81&M82くらいだったでしょうか。それでもそこそこの人が、特にどう操作するかの様子に興味を持ってくれて、足を止めて見てくれていました。以前ブログにコメントをくれた方も来てくれました。
スクリーンショット 2024-06-08 200239

スクリーンショット 2024-06-08 202054

最後亜鈴状星雲がやっと山から出てきたと思ったら、その真下にブースの明るい電気があって、迷光が地面のかなり低いところに置いてあるFMA135に入ってしまっているようで、星雲レベルは全く見えなくて、さらに雲もひどくなってきたのであきらめてしまいました。

Arm Windowsは全く順調で、普段やっているSURFACE8とかSURFACE9のWindows PCより快適なくらいです。仮想 OSですがそこまでパワーを使わないみたいで、Macのバッテリーも十分持ちますし、画面も広くて、「画面が綺麗で不思議に思った」と声をかけてもらったほどMacBook Proのレティーナディスプレイは性能がいいです。

問題は、SynScan Proとの接続が安定しなかったことです。プレートソルブをかけて、基本はうまくいくのですが、何度かに一回接続が切れてしまい、それが何度もありました。接続が切れた時はエラーメッセージが出たり、エラーメッセージが出る前にプレートソルブが動かなったりしてわかるのですが、その度にSynScan Proを落として再起動すればまた普通に動くようになります。でも今回落ちる頻度が結構多くて、観望会だとお客さんを待たせてしまうレベルだったので、改善が必要そうです。一応SharpCapも、SynScan ProもASCOMプラットフォームも、SynScan用のASCOMドライバーも、全て最新バージョンですが、もしかしたらWindows PCに入っている古いバージョンの方が安定だったかもしれません。少し探る必要がありそうです。

その他にも、トラバース本体の電池が切れて交換するとかのトラブルなどもありましたが、それよりも雲の方が深刻で、あまり遅くならない夜の22時くらいになって、終了としました。この日は大した機材は出していないので片付けもすぐに済み、最後まで残ってくれていた方達にお礼を言って、少し名残惜しかったですがここでお別れです。


会場をあとに

まだメイン会場には片付けとかで人も残っていて、最後に挨拶だけして帰路につきました。夕食に相当するものを食べてなかったので、坂を降りたコンビニで最後に一つ残っていた弁当を買って食べ、眠くならないようにコーヒーだけ用意して、一番近いETC専用の田村ICに向かいます。

途中眠くなるまで走って、PAとかで仮眠をとって、とにかく自宅に早めに着いてゆっくり休もうと思って走らせたのですが、夜中の高速道路は空いていてすごく順調で、午前4時くらいには自宅に着きました。流石に眠くて片付けもろくにせずにすぐに寝てしまいましたが、やはり自宅で眠ることができたのは良かったです。寝不足なのもあったのですが、かなり疲れてしまったこともあり、結局帰った日曜の昼間はほとんど寝ていました。起きてからサクッとこのブログ記事を書いています。昼間もほとんど寝ていたのですが、明日からの仕事もあるので、これ以上無理しないように早めに寝たいと思います。


戦利品

最後に今回手に入れたものです。

IMG_9557
  1. ビンゴで当たったタカハシのクリアファイルはもう何種類にもなりました。
  2. 外山電子さんには自作レポートのコピーをいただきました。
  3. プリズム関連を何種類か買い込みました。もしかしたら今考えていることに使えるかもしれないという淡い期待からです。いつもとんでもない値段で販売してくれているので、とても助かります。ついでに謎のネームプレートもいただきました。
  4. あとは水準器が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に挑戦するときは、暗い場所に行って撮影し、恒星がどこまで出るのか挑戦してみたいと思います。



このページのトップヘ