投稿

2Xドリズル画像の星雲が星側に分離される問題 (※追記 1Xドリズルも同じ)

イメージ
いろいろな対象を 2X ドリズル・インテグレーションしています。次の網状星雲も解像度が向上して、全く問題ないように見えます。 しかし、リニア状態で StarXTerminator で星雲と星に分離すると、次のように 星雲の 一部が星側に分離されました。 最終的に、この二つの画像は合成されるので問題はなさそうですが、右の星雲側はいろいろな強調処理を行うのに、左の星側は大きな操作を行いません。そのため、最終画像では分離された星雲のつなぎ目がはっきりわかります。 次期バージョンで解決 StarXTerminator の AI バージョンを 6 から 11 まで試しましたが、いずれも多かれ少なかれ同じ問題が起きました。そのため、ホームページを経由して RC-Astro に質問したところ、次の回答がありました。 StarXTerminator is due for an update which will improve this.  この問題は認識されているようで、アップデートで解決されるとのことです。なお現状での解決策は、 1X Drizzle にするしかないようです。 Starnet は問題外 試しに Starnet を使ってみましたが、星雲側に全ての星が残されていて、輝星の中心部が不自然になっています。スターマスクは、輝星の中心部だけを抜き出しで作られているようです。 これから どのような対象でこの現象が起きるのかは良くわかりません。網状星雲 NGC6992 では問題ありませんでした。いずれにしろ、 StarXTerminator のバージョンアップを待ちたいと思います。 ※追記(2022/1/21) 1X ドリズルではこの問題は起きないとのメールをもらっていましたので、試してみたところ、 AI バージョン lite 11 では同じように星雲が星側に分離され、 AI バージョン 11 ではかなり改善されるものの、ある程度は星側に残ることが分かりました。 この現象について再度問い合わせを行いましたが、スターレス画像作成に完璧なものはないものの、次期バージョンで改善されるとの回答を改めてもらいました。

都内からのクラゲ星雲とドリズルインテグレーション

イメージ
正月からふたご座クラゲ星雲を撮りためていて、総撮影時間が 15 時間を超えましたので処理してみました。画角が狭くて構図が妙ですが、初めての撮影ですのでこれで良しとします。 撮影時間: 2023 年 1 月 3 日 ~1 月 12 日の 6 日間で 120 秒 X468 枚 =936 分 撮影地:東京都足立区 鏡筒: Askar FRA 400 カメラ: ZWO ASI 533 MC Pro Gain:101 Offset:50 -10 度冷却 赤道儀: ZWO AM5 オートガイダー: ZWO 30F4 ミニスコープ + ASI 290MM mini フィルター: IDAS NBZ オートフォーカサー: ZWO EAF 撮影 PC : MeLe Quieter 3Q ( Windows 11 ) + Fire HD 8 ( TeamViewer ) 撮影ソフト: N.I.N.A. + PHD2 画像処理: PixInsight のみ( SHO 風処理) ひどい撮影環境 南北は 10 階建て、東は 6 階建ての団地、西側は東京都心で明るくなっていますので、天頂付近を東から西へ動いている対象だけを撮影しなければなりません。この対象もその中から選んだのですが、次の写真のように南側の建物の端ギリギリを通っていきます。遮光フードをボール紙で長めに作ったのですが、建物の通路灯の光が入っていると思われます。 もともと淡い対象なのにこの光害では、あまり期待できそうもないと思ったのですが、寒い中なんとか頑張ってみました。 撮影時間による画像比較 今回は撮影するたびにインテグレーションして画像処理をしましたので、撮影時間に応じて画像がどのように変化するかを見てみました。 撮影時間が増えるにつれて、クラゲの形が徐々にはっきりしてきます。「時間は正義」だと思いました。 左: 226 分  中: 590 分  右: 936 分 解像感の乏しさとドリズル・インテグレーション 撮影時間とともに、星雲の構造ははっきりしていきますが、網状の構造は、時間に関わらずぼんやりしているように思えます。クラゲの上部を拡大した画像です。 そのため、 2 倍のドリズル・インテグレーションをしてみました。新しい WBPP ではドリズル情報を作るだけでな...

輝星が星雲側に分離される問題

イメージ
StarXTerminator でスターレス画像を作ると、輝星が星雲側に分離されるため、スターレス画像のマスクから、輝星を手作業で消していました。次のスターレス画像の、上部の左右に二つの輝星が残っています。下部の両側にも、星の跡があります。 GHS ストレッチ後に StarXTerminator を掛けることが原因 あまりに面倒なので、この原因を検索してみると、なんと StarXTerminator のページにしっかりと書いてありました。 https://www.rc-astro.com/resources/StarXTerminator/ StarXTerminator は MTF ( midtones transfer function )でストレッチされた画像を使って学習しており、なおかつリニア画像を MTF ストレッチして処理し、その後で元のリニア状態へ戻すという作業をしているとのことです。 PixInsight の HistogramTransformation は、 MTF と同じ方法を使っていて、このストレッチとは相性がいいのですが、これと全く異なるストレッチ方法( arcsinh と GHS )では、星のプロファイルが大きく変更され、輝星と小さな楕円銀河が区別できなくなるとのことです。私はストレッチで generalized hyperbolic stretch ( GHS )を使っていました。 GHS は、星の肥大化と過飽和が防げ、星雲の構造がより良く残るとされています。 GHS でストレッチする場合は、リニア状態で StarXTerminator を実行しなければならなかったのです(そのとき Unscreen Stars オプションは無効)。むしろ、 StarXTerminator はできるだけ早く、ストレッチの前に掛けるべきであり、その方が良い画像になるとのことでした。説明はしっかり読むべきでした。 リニア状態でスターレス画像を作ってから GHS ストレッチ リニア状態で StarXTerminator を掛け、スターレス画像(星雲画像)に GHS でストレッチすると、輝星は星雲画像から見事に消えていました。 GHS のストレッチを PixelMath スクリプトで簡単に しかし今度は、星雲画像と星画像の両方に GH...

デュアルナローバンド画像のハッブルパレット風超簡単処理の系譜

イメージ
輝線星雲を対象とするときは、 ZWO ASI 533 カメラに IDAS NBZ フィルターを付けて、 Ha と OIII のデュアルナローバンド画像を撮影しています。これまではモノクロカメラを使ってベランダから撮影していたのですが、引っ越しをしてベランダが使えなくなりました。団地前の公園に機材を運び出す必要があり、 1 日の撮影時間はせいぜい 2 ~ 3 時間に限られるようになったのです。撮影時間が 3 倍以上かかるモノクロカメラは使いにくくなり、ワンショットカラーカメラに変更しました。また、都内であることと、公園の三方が団地で明るいことから、通常の光害カットフィルターでは役に立たないと思われるため、ハロがほとんど出ないこのデュアルナローバンドフィルターに行き着きました。 しかしデュアルナローバンド画像に通常の処理をするだけだと、 Ha の信号が強いために赤が支配的になり、あまり面白くありません。ところが、これをハッブルパレット風の鮮やかな画像に簡単に変換することができるという動画を見つけ、その劇的な効果に驚きました。次の二つの動画が参考になりました。これらはいずれも、 PixInsight のスクリプトをドラッグ・ドロップするだけという、超簡単な方法を使っていました。そのため、この処理方法のルーツをすこし詳しく探ってみることにしました(それほど大げさではありませんが)。   (1) Cuiv, The Lazy Geek BACK TO ASTRO!! Color camera & Single Night vs California Nebula! https://www.youtube.com/watch?v=c1-DaPtqr60   (2) astrojourneyuk Creating an SHO image from HOO data using PixInsight https://www.youtube.com/watch?v=Qb0jXcCq8nU Luke Newbould さんの SHO 風処理 ハッブルパレットは、 SII 、 Ha 、 OIII の信号をそれぞれ RGB に割り当てますので、 SHO パレットとも呼ばれますが、デュアルナローバンド画像は、 Ha と OIII だけであり、 SII 画像がありませ...

ポータブル電源の不具合とその対応

イメージ
先日の撮影で、新しく購入したポータブルバッテリー Anker 521 Portable Power Station の残量が 30% あたりになったとき、その直後に電源が落ちるというトラブルがありました。冷却カメラの昇温処理ができませんので、これは極めてまずい現象です。 その後室内で、撮影 PC や赤道儀と同じ程度の消費電力である 35W の保温マットをつないで、負荷試験を行いました。その結果、次のように 30% 前後で急速に残量が 0 になることが裏付けられました。 購入元の Anker Japan に連絡すると、すぐに対応してくれ、製品を返送後に不具合を確認してくれました。昨日代替品が届きましたので、本日同じような負荷試験を行いました。 その結果、時間とともに残量がほぼ線形で減少していることを確認しました。使用時間が 90 分程度伸びています。残量が 10% 程度から 20 分は動きますので、カメラの昇温と片付けを始めることができます。 6.5 時間は撮影できることになりそうです。 Anker は、不要になったバッテリーを無料で回収してくれますし、今回の対応も適切で、信頼できる企業であるとの印象を受けました。

CPU交換で画像処理時間が30%に

イメージ
年明けに CPU を交換しようと思っていたのですが、候補の Core i7 12700 の価格が上がっていること、合わせて買おうと思っていたマザーとのセットがツクモネットショップにあったこと、年末年始がひまなことから、急遽 68,980 円で購入しました。 現在の第 8 世代 CPU である、 Core i5 8400 と比較すると、スレッド数が3倍以上になっています。これがどのように影響するか調べてみました。 ・ Core i5 8400 ( 6 コア 6 スレッド) ・ Core i7 12700 ( 12 コア 20 スレッド) 1260 枚の画像処理時間 おたまじゃくし星雲を撮影した 420 枚の fits 画像を、 PixInsight の WBPP を使って、ディベイヤーして 1260 枚の RGB 画像に分離し、 RGB 別にレジストレーション、ローカルノーマライゼーション、インテグレーションをします。 撮影カメラは ZWO ASI 533MC (約 900 万画素)ですので、 fits ファイルは 17.2MB とそれほど大きくはありませんが、ディベイヤー後の xsif ファイルは 103MB と大きくなります。 CPU (とマザーボード)以外は、同じ条件です。メモリは 64GB で、 GPU は NVIDIA Geforce GTX1650 、 PixInsight の作業ドライブは、 256GB の SSD に割り当てています(およそ半分を使います)。 Core i5 8400 の処理時間を、 WBPP の Execution Monitor とストップウォッチを使って測ってみました。なお、ダークはマスターを使いますし、フラットは毎回撮影後にインテグレーションしていますので、ダーク・フラットのインテグレーションはスキップされます。合計時間は 5 時間 20 分( 320 分)でした。 同じように、 Core i7 12700 の Execution Monitor は次のようになっており、処理時間は 1 時間 33 分( 93 分)でした。 Core i5 の 320 分と Core i7 の 93 分を比較すると、 29 %の処理時間で済んでいます。半分以下になるだろうとは思っていましたが、 1/3 以下になりました。単...

StarXTerminatorの高速化

イメージ
10 時間を超える画像を、 PixInsight の WBPP を使って RGB 別に処理すると、終了までに 5 時間を超えるようになりました。現在の CPU は第 8 世代の Core i5 8400 ですので、これはなんとかしなければと思うようになりました。もう新しい世代への移行時期ですね。 もう一つ気になったのは、 StarXTerminator でのスターレス画像作成にひどく時間がかかっていることです。調べてみると 1 枚のスターレス画像を作るのに、 5 分 54 秒もかかります。現在のグラフィックボードは、 ASUSTeK の NVIDIA GTX750Ti です。発売が 2014 年だそうですからもう 8 年も前になります。さすがに古くなっています。なによりビデオメモリが 2GB しかありませんから、 NVIDIA の CUDA ( Compute Unified Device Architecture )が使えません。 そこで、まずビデオカードを更新して、 CUDA を使って StarXTerminator を高速化することから始めてみることにしました。購入したのは、エントリーモデルですが 4GB のメモリがある MSI GEFORCE GTX1650 で、メルカリで 13,000円 でした(財布に優しいので助かります)。同じ画像を使って、速度を測ってみると 42.6 秒でした。以前の 5 分 54 秒と比較すると、 8.3 倍速くなっています。この程度の投資で、これだけの結果が得られるのは驚きです。 ビデオカードのメモリが実際に使われていることが、タスクマネージャーのパフォーマンスグラフでも確認できました。 CUDA の設定 CUDA の設定は結構面倒でしたので、覚書としてまとめておきたいと思います。参考にしたのは、次の StarNet を CUDA で高速化するサイトです。 https://www.williamliphotos.com/starnet-cuda (1) CUDA のインストール NVIDIA のサイトで、 CUDA Toolkit 12.0 をダウンロードして、インストールします。 https://devel...