ほしぞloveログ

天体観測始めました。

タグ:ASI294MMPro

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

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

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


三たびM104、でも本当は4度目

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も一緒に撮影するに至りました。


NINAが重い

今回の撮影の少し前、3月18日にNINAの3.0が正式に公開されました。ただしちょっと重いみたいです。3.0にしてから撮影画像の保存にすごく時間がかかるようになりました。1枚撮影すると保存だけで毎回1分以上かかり、保存中は撮影は進まないので、かなりの時間ロスになります。

現在はStick PCで撮影し、micro SDに保存しているのです結構非力です。最初ディスクの書き込み速度を疑いました。でも撮影したファイル単体のコピペとかだと全然速く終わります。そこで、タスクマネージャーで撮影中の様子を見てみたら、NINAがものすごくCPUパワーを食っていて、かなりの時間100%になるようです。仕方ないので、以前の2.2に戻したら、ほぼタイムロス無しで連続で撮影できるようになりました。単にソフトが肥大したのか、それとも何か負荷が増えるようなバグっぽいものなのか、3.0がさらにアップデートされたらちょくちょくチェックしてみたいと思います。


今回の撮影

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

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

2023-05-11_20-58-14_M 104_LIGHT_L_-10.00C_300.00s_G120_0004
結構な数の星と、なんと画面真ん中の銀河中心までサチってしまっています。これはいけませんね。

下は今回露光時間を1分にしたもので、他の条件はほぼ同じです。だいぶマシになっていますが、それでもまだ飽和を避けることはできていません。少なくとも銀河中心は問題ないです。
2024-04-01_22-25-41_M 104_L_-10.00C_60.00s_0013

さらに露光時間を変えるにあたり、以下の2つのことを考えましたが、処理後の画像を見比べた限り違いはわからなかったです。
  1. 自宅撮影に限っていうとスカイノイズが圧倒的に支配的になります。露光時間を短くすると、読み出しノイズの効きが大きくなってくるのですが、露光時間を1分にしたくらいではまだまだ読み出しノイズは全然効かないくらいです。
  2. 淡い部分の階調がADCの暗い側にシフトするので、階調が出にくくなる心配もありましたが、まだ全然余裕があるようです。
LRGB画像は今後1分でいいと思います。ナローに関しては輝度が10分の1以下になるので、露光時間5分をキープするか、ダイナミックレンジがそこまで必要なければgainを上げてもいいかと思います。


画像処理 

WBPPでLRGBそれぞれインテグレートまでします。その後、すぐにRGBを合成して、カラーにしてからABEとDBEでフラット化をかけました。それぞれの色でフラット化してもいいのですが、カラーでやっても独立して働くので効果は同じはずで、1度で済むので手間を省いているだけです。

銀河で自宅撮影なので、背景のIFNなどは気する必要はなく、RGB画像もL画像も、気軽に簡単にフラット化してしまいます。だいこもんさんのブログ記事(元情報はUTOさんだそうです)によると、M104の周りにも相当淡い構造(更に大元がここ)があるようなので、試しに去年撮った5分露光画像も含めてL画像をかなり頑張って炙り出しましたが、私のところではその片鱗さえ全く見えませんでした。大顧問さんはチリで30時間露光して見えたとのことなので、自宅のような光害環境ではここまで淡いのは全然無理なのかと思います。なので、今回は背景は気にしないで、とにかく目的のM104本体の内部の細部構造がどこまで見えるかに全力を傾けます。

この内部構造、シンチレーションに強度に依存するようです。L画像は二日にわたって撮影していますが、二日目の画像は全然ダメで使うかどうか迷いました。1日目だけのもの133枚と、1日目133枚+2日目の中でもマシなもの56/103枚を使ったものを比較しましたが、見た目では違いがわからなかったので2日目のも入れたもので処理を進めました。

L画像はABEの2次、DBE、BXTをかけていますが、この時点でかなりの解像度が出ていて期待が持てそうです。
Light_BIN_1_8288x5644_60s_L_drizzle_1x_ABE4_DBE_BXTc_BXT_BXT03


LRGB合成

RGBとLをどう合成するかはいまだに迷います。過去に何度が議論しています。LRGB合成を初めて試したのは2022年10月のまゆ星雲です。この時わかったのは、L画像を合成したときに色がかなり出なくなるのですが、見えなくなっているだけで色情報としては十分残っているということでした。でもLとRGBをどのタイミングで合成すべきか、どういった比率で合成すべきかなどはまだまだ謎のままでした。


その後、この2つの過程でLRGB合成の経験的な方法はある程度確立したのかと思います。



そしてこのページである程度の理屈も含めて結論が出ています。


久しぶりのLRGB合成になるのでかなり忘れていることもあり、今回改めて読み直しましたが、今見てもかなり有用な議論です。当時のniwaさん、botchさん、だいこもんさんに感謝です。

今回まずは様子見で、PIのLRGBCombinationを使ってL画像を指定してRGB画像放り込んでみると、カラーノイズが結構目立ちました。RGBの撮影時間が短いので当然なのかもしれません。そこでLab分解してaとb画像にぼかしをかけてみました。以前うまくいった方法なのですが、今回はカラーノイズに対してほとんど効果が見られませんでした。カラーノイズ対策ができないのならa、b画像で何かする価値はほとんどなくなってしまいます。カラーノイズは後で対策できることと、奇をてらう方法はできるだけ避けたいこともあり、今回は素直にLRGBCombinationを使う方法を探ります。

未だ残っている一番の疑問は、LとRGBの混合比率です。これまでわかっていることは、
  • LRGBCombination処理はリニアでやらずにノンリニアでやること。ノンリニアとはフルストレッチしてからということ。
  • でもフルストレッチは厳しすぎる制限で、多少のストレッチでも大丈夫そうなこと。
  • リニアで処理すると、恒星内部に明るい飽和の飛びができ、後からどうしようもなくなること。
  • 飽和の飛びはL画像がRGB画像より暗い場合にできたが、L画像を明るくすると無くなること。

まず思っている疑問は、リニア段階での処理では本当にダメなのかということです。リニアはノンリニアの特別な場合と考えることができ、ノンリニアでいいのならリニアでも当然大丈夫だと思うからです。今のところ確認できている弊害は、
  • 恒星の飛び
だけです。

結論だけ言うと、今回リニア段階でLRGBCombinationを試しましたが、いずれも恒星の飛びは確認できませんでした。ただしこの結果は、LとRGBの明るさの違い(混ぜる比率)に依存しそうなので、その比率を変えて幾つか試しました。試したのはLRGBCombinationのCannel Weightsを変えることです。これらは相対的な比だけで決まり、例え全部を0.1とかにしても、処理後の画像の全体の明るさは変わらないことは以前確認しています。試したのは以下の4種類です。
  1. L : R : G : B = 0.1 : 1 : 1 : 1
  2. L : R : G : B = 1 : 1 : 1 : 1
  3. L : R : G : B = 1 : 0.1 : 0.1 : 0.1
  4. L : R : G : B = 1 : 0.01 : 0.01 : 0.01
いずれの場合も上で書いたように飛びは出なかったので、とりあえず今回は少なくともリニア段階でLRGB合成したとしても確認できるような問題は起きなかったと言えます。

その一方、できた画像の解像度には明確な差が出ました。下の画像になりますが、左から順に上の1,2,3,4となります。
comp

注意すべきは2, 3, 4で、Lの比率が高いとLRGBCombination直後はほとんど色がなく、一見モノクロのように見えることです。でも色情報はきちんとのこっているので、ここで心配する必要はありません。CurveTranformationで右のSの彩度を選んで曲線をΓの字になるくらいにして彩度を上げてやると確認できます。上の画像はそのように彩度を上げたもので比較しています。

4つの画像を見る限り、カラーノイズ、彩度に関しては明確な有利不利は確認できませんでした。最も大きな違いは分解能で、Lが一定以上の明るさがないとRGBが持つ低い分解能のままで制限されてしまうということです。わかりにくい場合は上の画像をクリックして拡大して比べて見てください。明確に違いがわかります。LとRGBの比が0.1:1や1:1ならばL分解能が十分生きてこなくて、1:0.1ならば十分、1:0.01にしてももう変化がないことがわかります。以前M106で試した時は1:0.25とかにして分解能が出たので、今回も再現性があり、ある程度L画像の明るさを保たないとダメだという結果を改めて確認できたことになります。

というわけで、今後もLRGBCombinationでシンプルに、Cannel WeightsだけLをある程度大きくしてLRGB合成をすればいいということにします。


結果

結果です。とりあえずはクロップして本体をある程度の大きさにしたものを完成とします。

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

まず目的の銀河本体内部の構造ですが、結構出たといっていいかと思います。これはひとえにシンチレーションが良かったからと言うのが今回の結論です。BXTの効果も大きいかもしれませんが、シンチレーション自身が良かったのがまず第一だと思います。色は下に載せたハッブル画像に近くしました。

クロップ前の全体像になります。
Image07_low

恒例のAnnotationです。
Image07_low_Annotated

銀河っぽいシミがいくつかあると思ったのですが、候補に入らないものがいくつかあります。単に画像処理でなにか失敗してるのか、はたまたまだカタログ不足なのでしょうか?


ハッブルとの比較

恐れ多くもハッブルと比べてみます。

まず今回撮影し画像を5度時計回りに回転させ、次のハッブル画像と同じような画角に切り出したものです。
Image07_rot5_Hubble

次がハッブル望遠鏡が2003年に発表したM104です。
STScI-01EVT8YHAGM2WGQTV3DGKRFZ7Q

もちろん分解能には全然差はあって追いつけっこないですし、恒星に至っては大きさも微恒星の写りも全く違います。でもなんかちょっと比べてみようと思うくらいにはなったのかなと思って、自己満足しています。


まとめ

足掛け2年にわたって悶々としていたM104にやっと決着がつきました。2022年の結果がこれなので、大きな進歩だと思います。
final

ソフトは変わりましたが機材は同じです。今回L画像を撮影したのは大きな違いですが、やはりそのL画像のシンチレーションの影響が一番大きいと思います。撮影時のHFRを見るとシンチレーションの評価になりそうなので、いい日かどうかを定量的に評価しながらL画像を撮影すべきなのかカラー画像を撮影すべきなのかを決めることなどができそうです。そこらへんの補足記事を次に書こうと思っています。

今回健康を害すると何もできなくなってしまうことを実感しました。まだ今後も長年続けていきたい趣味なので、少し体に気をつけて、無理をせずに楽しみながらやっていけたらと思います。

画像処理も溜まっています。ダイオウイカは昨年10月くらいから残ってますし、ヘラクレス銀河団、さらに南天がいくつか残っています。これらも焦らずに進めていきたいと思います。


2023/10/12、久しぶりに新月期で晴れです。平日なのであまり無理をしたくないのですが、せっかくなので撮影を敢行しました。


久しぶりの撮影

実は前日の10月11日も晴れていたのですが、ε130Dの光軸調整で時間を潰してしまい、何の成果もありませんでした。実際光軸調整も大したことはできず、せっかくの晴れでもったいないです。なんとか撮影の成果だけは残そうと思い、SCA260+ASI294MM Proで簡単な撮影をしました。この日の撮影は、前半がM27、後半がM45です。でも結局撮影が忙しくて、せっかくε130Dを出してセットアップまでしたのに、光軸調整はやっぱりできないんですよね。平日に二つのことは厳しいです。

今回M27にした理由ですが、5月にHα画像を写していました。その後続けてOIIIも撮ったはずなんです。でも撮影後に確認したら、実際に撮影していたのはB...。AOO撮影のはずなのに、Aの次はBと思い込んでしまったようです。今回はそのリベンジで、OIIIの撮影です。でもここでも痛恨のミス。縦横を合わせ損なって90度ずれてしまい、使えるのは重なる正方形の部分だけとなってしまいました。

前回M27を撮影したのは2年前のTSA120を使ってです。2021年9月になります。この時が、そこそこセンサー面積があるモノクロカメラを使った初のナローバンド撮影で、まだフィルターホイールも持っていなかったので、手でフィルターを付け替えてのAOO撮影でした。本体周りの羽の部分を出したくてOを重点的に出そうとしました。羽はそこそこ写ったのですが、意外にAが出なくて、Aのリベンジが課題だったことを覚えています。



それでもこの時のM27には結構満足していて、もうしばらく撮ることはないなと思っていましたが、2年経つとアラも見えてきますし、SCA260でさらに光量が稼げるとか、BXTが台頭してきたとかで、状況も大分変わってきています。高度も高く、夏を中心に一年のうちのかなりの期間撮影が可能なので、ベンチマークがわりに再びM27を撮影しようとここしばらく思っていて、やっと実現できたというわけです。


撮影

SCA260での撮影は久しぶりです。少しづつ思い出しながらのセットアップになりますが、それでもほとんどトラブルもなく、比較的順調に撮影開始となりました。一つだけミスがあって、StickPCを使っているのですが、SCA260+ASI294MM Proで使っているStickPCと、ε130D+ASI6200MM Proで使っているStickPCが入れ替わっていて、気づかずにカメラの設定やフィルターごとのEAFのピント位置とかの設定でファイルを上書きしてしまいました。気づいたのはプレートソルブがどうしてもできなくて、ε130Dの焦点距離の400mmが入っていた時でした。でも面倒なのでそのままStickPC交換せずに使い続けたのですが、色々不具合が出てきて、すぐに交換すればいいと後から後悔しました。
M27
撮影中のNINAの画面。ガイドも順調です。

撮影は順調に続き、OIII画像が溜まっていきます。23時位になるとM27が隣の家の屋根にかかってしまい、次に考えたのが、ずっとやってみたかったモザイク撮影です。以前拡大撮影したM45: プレアデス星団が次のターゲットですが、これは別の記事で書きたいと思います。


追加撮影

OIIIの撮影直後は5月に撮影したHαと合わせて仕上げてしまおうと思っていましたが、縦横の間違いが悔しかったので、結局10月17日にHαを、OIIIと同じ方向にして撮影し直してしまいました。こうなってくるとOIIIもHαももう少し追加したくなり、18日にも追加撮影して、5分露光でHαが44枚、OIIIも44枚で、合計88枚、総露光時間440分で7時間20分となりました。17日から18日にかけては庭に望遠鏡を出しっぱなしにしていたので、すぐに撮影に入ることができ、18時台から撮影を開始できています。


フラットでトラブル

久しぶりの撮影なので、フラットを撮り直しています。フラット撮影は、昼間に明るい部屋で白い壁を映しています。ところが、今回条件を一緒にしようとして「冷却して」撮影したのは失敗でした。結露が起こってしまったことに後から気づき、結局常温で全て撮影し直しです。DARKFLATも温度を合わせるため、こちらも全部取り直しです。
2023-10-14_14-00-20_M 27_2x2_FLAT_R_-10.00C_0.01s_G120_0000
フラット撮影中にオートストレッチして、こんな風に真ん中にシミのような大きな模様ができていたら、結露しています。拡大すると、おかしな黒い点々が見えたりします。

普段はフラットは昼間に部屋が明るい時に撮っていましたが、雲があると明るさがバラバラになるのでダメですね。今回は早く画像処理を始めたかったため、暗くなってから部屋のライトをつけて撮影しました。でもこれ、もしかしたらダメなのかもしれません。特にHαですが、微妙にフラット補正が合わずにムラになってしまいました。

以前記事に書いたことがあるのですが、ナローバンド系はフラットファイルそのものがどうしてもムラムラになってしまいます。



当時、センサー自身のムラではないかと予測したのですが、その後ZWO自身がこのムラはセンサーの特徴だと言及しているページを見つけました。



当時このページの存在は知らなかったのですが、後からやはり推測は正しかったと分かりました。でもいずれにせよ、このムラはフラット補正で解決できましたし、ZWOの説明でも同様のことが書いてあります。

でも今回は、フラット補正をしてもどうしても、ムラの形が残ってしまいました。まず、今回撮影したフラット画像のうちの1枚です。ナローバンド特有の大きなムラ構造が出ています。
masterFlat_BIN-2_4144x2822_FILTER-A_mono

次に、AOO合成した直後の画像です。上のフラット画像と比べてみると、ムラの形がよく似ていて、暗いところが赤くなってしまっているのがわかると思います。
Image11_ABE

まだ未検証ですが、部屋の明かりを使ったのが悪かった気がしています。明かりとしては、蛍光灯と電球を合わせたのですが、それぞれ波長が違っていて、違った種類の光源が複数方向から来ているので、複雑な形の輝度勾配ができてしまっていた可能性があります。もし時間が取れるなら、再度晴れた日の明るい部屋の中で自然光を光源に、再度撮影してみたいと思います。あ、多分ですが、晴れた日にの薄明時に鏡筒を空に向けるのが一番いいのかとは思いますが、時間が限られるので、壁での方法を確立しておきたいということです。

今回問題だったフラットのムラはHα、OIIIともにDBEを細かくかけることで、なんとか見える程度にすることができました。


ダークの撮影

あと、今回ついでにダークも久しぶりに撮影しました。ダーク系を撮るのも昼間は注意が必要です。カーテンを閉めてできるだけ部屋を暗くするのはもちろんですが、鏡筒や特にフォーカサー部などにきちんと暗幕(タオルとか、服とか)をかけて撮影しないと、完全にダークになりません。今回は二度に分けてダークを撮りましたが、最初の暗幕が甘くて、十分暗くなりませんでした。
IMG_8668
こんな風に望遠鏡をくるんで、さらに部屋を暗くしてダークを撮影してます。


最新版PixInsightと、Mac M1でのStarNet

私は画像処理にMacのM1を使っているのですが、最近PixInsightを1.8.9-2にアップデートしたら、StarNet V2が使えなくなりました。その後StarNet V2もアップデートされ、最新バージョンのPIでも使えるようになったということでしたが、再インストールの方法を忘れてしまい少し手間取りました。Niwaさんのページやその参照元のCloudy Nithtsに解説があるのですが、自分の環境とは微妙に違っていて、そのままではうまく動きません。うまく動いた方法を書いておきます。

まず、ダウンロードページに行って、



をダウンロードします。その後、ファイルを解凍します。
  1. StarNet2_weights.pbとStarNet2-pxm.dylibは/Applications/PixInsight/bin/にコピーします。
  2. libtensorflow.2.dylibとlibtensorflow_framework.2.dylibはApplications/PixInsight/PixInsight.app/Contents/Frameworks/にコピーします。PixInsight.appの中身は、PixInsight.appを右クリックして「パッケージの中身を表示」を選ぶとアクセスすることができます。
  3. 以下のコマンドを、一つ一つコピペしてターミナルから実行します。
  • sudo chown root:admin           /Applications/PixInsight/bin/StarNet2_weights.pb
  • sudo chmod 644                  /Applications/PixInsight/bin/StarNet2_weights.pb

  • sudo chown root:admin      /Applications/PixInsight/bin/StarNet2-pxm.dylib
  • sudo chmod 755             /Applications/PixInsight/bin/StarNet2-pxm.dylib

  • sudo rm -f             /Applications/PixInsight/bin/libtensorflow*
  • sudo chown root:admin  /Applications/PixInsight/PixInsight.app/Contents/Frameworks/libtensorflow*
  • sudo chmod 755         /Applications/PixInsight/PixInsight.app/Contents/Frameworks/libtensorflow*

あとはREADME.txtに書いてある通りに、
  • PI上でPROCESSES=>Modules=>Install Modulesで'Search'を押すと、StarNetが出てきます。
  • その後他のボタンは何も押さずに'Install'を押します。
  • うまくいくとStarNet2がPROCESSES-><Etc>もしくはPRECESSES-><All Processes>に出てくるはずです。
怖かったのは、マニュアルに「ちゃんと手順を踏んでやってもサーチでStarNetが出てこない場合は、AVXに対応してないから仕方ないとか、心を折るような記述があることです。でもM1のMacでPIの最新版で、確実にStarNet V2をインストールできたので、諦めずに正しい手順でやってみてください。


結果

画像処理に関しては、あとはほとんど問題はありませんでした。ナローなので、色決めに一意の解はなく、SPCCも恒星の色を合わせるように設定したので、星雲の色は自由度があります。他の画像を見ていてもM27の色は様々で迷いますが、前回TSA120で出した色が比較的好みなので、今回も近い色としました。

画像処理の結果が下のようになります。
masterLight_BIN_2_300_AOO_SPCC_BXT_DBE_MS_MS_BG2_cut_X3
  • 撮影日: 2023年10月12日20時59分-22時52分、10月17日20時34分-23時29分、10月18日18時18分-22時35分、
  • 撮影場所: 富山県富山市自宅
  • 鏡筒: SHARP STAR製 SCA260 (f1300mm)
  • フィルター: Baader Hα, OIII
  • 赤道儀: Celestron CGX-L
  • カメラ: ZWO ASI294MM Pro (-10℃)
  • ガイド:  f120mmガイド鏡 + ASI290MM、PHD2によるマルチスターガイドでディザリング
  • 撮影: NINA、Gain 120、露光時間5分、Hα:44枚、OIII:44枚の計88枚で総露光時間7時間20分
  • Dark: Gain 120、露光時間5分、温度-10℃、42枚
  • Flat, Darkflat: Gain120、露光時間 Hα, OIII:10秒、128枚
  • 画像処理: PixInsight、Photoshop CC

ちなみに、2年前に撮ったTSA120の画像が以下になります。
Image09_DBE2_stretched7_cut_crop_b


比較と評価

2年前と今回を比較してみます。
  • 最初のスタック画像を見ていると、微恒星に関してはどうも前回のTSA120の方がより出ている気がしました。これまで同じ対象でTSA120とSCA260を比べて、SCA260が負けたことはないので、意外な結果でした。原因はシンチレーションくらいしか考えらないです。もう夏の気候は終わってしまったので、揺れは大きくなっているのかもしれません。それでもBXTをかけて改善する余地があったので、結果としては今回の方が微恒星は数も鋭さも出ています。
  • 狙いの本体外側の蝶の羽の部分は、今回の方が明るい鏡筒で露光時間も倍以上と長いため、明らかに綺麗に出ています。羽の部分はOIIIの青よりも、Hαの赤の方がやはり淡いようで、前回よりも出てはいますが、フラットムラのこともあり、まだ露光時間を伸ばすか、このレベルの淡さになってくると自宅よりはさらに暗いところに行ったほうが効率がいいのかと思います。ここ最近の記事で、明るいところと暗い所のスカイノイズの影響が数値で定量的に出るようになってきたので、いずれこの淡さならこの場所に行くべきというようなことが言えるようになるのかと思います。
  • 中心部の微細構造は、口径とBXTの効果で圧倒的に今回の方がいいです。ただし、淡い羽部分の分解能との差がありすぎるので、多少なりともバランスを取るために、あえて少し分解能を落としてあります。
今回のM27、羽の部分、中心部分の分解能、微恒星の鋭さ、背景のノイズなど、ほぼ全てを2年前の結果を上回っていて、自己記録更新です。あえていうなら、透明度みたいなのだけは以前の方が良かったように思いますが、これは画像処理に依っていて、まだ私も確信を持って(少なくとも見かけの透明度さえも)透明度をコントロールできていないので、偶然によってしまっています。それ以外はトータルとしてはかなり満足しています。


まとめ

久しぶりのSCA260での本気撮影でしたが、かなり満足な結果でした。自宅庭撮りで、M27の羽がここまで出るのなら、十分なのかと思います。その一方、これ以上出すのは撮影時間がかかりすぎることなどから難しく、暗いところに行く必要があると思います。次のシーズンに飛騨コスモスでしょうか?

ε130Dの光軸調整がなかなかはかどっていないので、しばらくはSCA260での撮影も継続していこうと思います。


一連のBXTによる再画像処理の4例目です。これまで以下のように3つの再処理例を記事にしてきました。





元々BXTで言われていた星雲部分の分解能、あまり話題になってなくて遥かに期待以上だった恒星の収差補正など、劇的な効果があります。

その一方、最近のM106の画像処理で分かったのは

  • BXTで銀河中心部の飽和が起きることがある。
  • BXTの恒星認識に引っかからない微恒星が小さくならなくて、恒星の明るさ位に対する大きさの逆転現象が起きる。
  • 光軸調整が不十分なことから起きる恒星の歪みはBXTで補正できなくてむしろ変な形を強調してしまうことがある。
  • BXTはリニア段階(ストレッチする前)で処理すべき(とBXTのマニュアルにも書いてあります)だが、LRGB合成はノンリニア(ストレッチしてから)処理すべきなので、リニアでできるRGB合成した後の段階ではBXTを使うことができるが、(額面通りに理解すると)LRGB合成した段階でBXTを使うことはできないということになる。
など、弊害や制限も少なからずあるということです。

M106も2度処理しているのである意味再処理なのですが、BXTを使っての「過去画像の」再処理という意味では、銀河を扱うのは今回初めてになります。これまで手をつけなかったことには実は明確な理由がありますが、そこらへんも記事に書いておきました。

そう言ったことも踏まえて、今回のBXTを使った処理では何が分かったのでしょうか?


子持ち銀河

ターゲットのM51: 子持ち銀河ですが、昨年4月に自宅でSCA260を使い、ASI294MM ProのRGB撮影で総露光時間4時間半で撮影したものです。

実はM51の再処理、かなり初期の頃に手掛けています。時期的は最初のBXTでの再処理の最初の記事の三日月星雲よりも前に試しています。銀河はBXTで分解能が上がることをかなり期待していました。でも改善がほとんど見られなかったのです。

BTX導入直後くらいに一度M51の再処理を試み、その後三日月星雲とかを処理してある程度技術的にも確立してきた後に、さらに再処理してみたM51です。
Image199_ABE_ABE_ABE_DBE_NTX_HT_CT_CT_NXT_CT2_cut1

同じ画角の元の画像を下に載せます。
64da897b_cut

再処理ではHαを載せていないので、派手さはないのは無視してください。2つを比較してみると、確かに少し分解能は上がったかもしれません。でも思ったほどの改善ではありませんし、むしろノイジーになるなど、悪くなっているところも見受けられます。なんでか色々考えたのですが、恐らくですが以前の処理はDeNoise AIを利用するなどかなり頑張っていて、すでにそこそこの解像度が出ていたということです。言い換えると、(今のところの結論ですが)いくらAIと言えど、画像に含まれていない情報を引き出すことは(例え処理エンジンは違っても)できないのではということです。逆に情報として含まれていないものを飛び抜けて出したとしたら、それは流石にフェイクということになります。

BTXとDeNoise AIを比べてみると、DeNoise AIの方が(天体に特化していないせいか)大きくパラメータを変えることができるので、おかしくなるように見えると思われがちですが、おかしくならない程度に適用する分には、BXTもDeNoise AIもそこまで差がないように思いました。DeNoise AIはノイズ除去と共にSharpen効果もあるのですが、BXTはノイズについてはいじることはないので、DeNoise AI = NoiseXTerminator + BlurXTerminatorという感じです。

それでは、DeNoise AIではなくBlurXTerminatorを使う利点はどこにあるのでしょうか?最も違うところは、恒星の扱いでしょう。DeNoise AIは恒星ありの画像は確実に恒星を劣化させるので、背景のみにしか適用できないと思っていいでしょう。その一方、BlurXTerminatorはAIと言っても流石にdeconvolutioinがベースなだけあります。星像を小さくする効果、歪みをかなりのレベルで補正してくれる効果は、BlurXTerminatorの独壇場です。恒星を分離した背景のみ、もしくは恒星をマスクした背景のみの構造出しならDeNosie AIでもよく、むしろノイズも同時に除去してくれるので時には便利ですが、やはり恒星をそのままに背景の処理をできるBXTとNXTの方が手間が少なく恒星のダメージも全然少ないため、天体写真の処理に関して言えばもうDeNoise AIを使うことはほとんどなくなるのかと思います。


L画像を追加してLRGBに

さて、上の結果を見るとこのままの状態でBXTを使ってもあまり旨味がありません。根本的なところでは、そもそもの元画像の解像度がをなんとかしない限り何をやってもそれほど結果は変わらないでしょう。

というわけで、RGBでの撮影だったものに、L画像を新たに撮影して、LRGB合成にしてみたいと思います。当時はまだ5枚用のフィルターホイールを使っていて、Lで撮影する準備もできていくてLRGBに挑戦する前でした。この後のまゆ星雲ではじめて8枚用のフィルターホイールを導入し、LRGB合成に挑戦しています。

撮影日はM106の撮影が終わった3月29日。この日は前半に月が出ているのでその間はナローでHα撮影です。月が沈む0時半頃からL画像の撮影に入ります。L画像だけで合計47枚、約4時間分を撮影することができました。

ポイントはASI294MM Proで普段とは違うbin1で撮影したことでしょうか。RGBの時もbin1で撮影していますが、これはM51本体が小さいために高解像度で撮影したいからです。bin2で2倍バローを用いた時と、bin1でバローなど無しで用いた時の比較は以前M104を撮影した時に議論しています。


解像度としてはどちらも差はあまりなかったが、バローをつける時にカメラを外すことで埃が入る可能性があるので、それならばbin1の方がマシというような結論でした。

以前RGBを撮影した時は1枚あたり10分露光でしたが、今回は5分露光なので、ダーク、フラット、フラットダークは全て撮り直しになります。


画像処理

画像処理は結構時間がかかってしまいました。問題はやはりLとRGBの合成です。前回のM106の撮影とその後の議論で、理屈上は何が正しいかはわかってきましたが、実際上は何が一番いいかはまだわかっていないので、今回も試行錯誤です。今回下記の6つの手順を試しました。Niwaさん蒼月城さんが指摘されているように、LinearでのLRGB合成で恒星の色がおかしくなる可能性があるのですが、今回は際立って明るい恒星がなかったので、LinearでのLRGB合成がダメかどうかきちんと判断することができなかったのが心残りです。
  1. RGBもL画像もLinear状態で、LRGB合成してからBXT
  2. RGBもL画像もLinear状態で、BXTをしてからLRGB合成
  3. RGBもL画像もLinear状態で、だいこもんさんがみつけたLinLRGBを使い、HSI変換のうちIとL画像を交換
  4. RGBとL画像とLinear状態でBXTまでしてから、フルストレッチしてNon Linear状態にしてからLRGB合成。
  5. RGBとL画像とLinear状態でBXTまでしてから、フルストレッチしてNon Linear状態にしてからLab変換して、aとbをconvolutionでStdDev=5でぼかしてからLab合成。
  6. RGBとL画像とLinear状態でBXTまでしてから、少しだけストレッチしてLinearに近いNon Linear状態にしてからLab変換して、aとbをconvolutionでStdDev=5でぼかしてからLab合成。
と試しました。赤は間違ったやり方、紫はまだ検証しきれていないやり方です。

ちなみに
  • BXTはリニアで使うべし。
  • LRGBはノンリニアで使うべし。
というルールがあるので、最も正しいと思われる順番は
  • WBPP -> ABE or DBE -> RGB合成 -> RGB画像にSPCC -> RGB画像、L画像それぞれにBXT -> ストレッチ -> LRGB合成
かと思われます。この手順は4番に相当します。RGBがノイジーな場合には5番もありでしょうか。

それぞれの場合にどうなったか、結果だけ書きます。赤はダメだったこと、青は良かったことです。
  1. 星雲の明るい部分に青飛びが見られた。(極端に明るい恒星はなかったので)恒星などの飛びは見られなかった。LRGB合成した後でBXTをかけるので、本来恒星が小さくなると期待したが、うまく小さくならず、変な形のものが残った
  2. 星雲の明るい部分に青飛びが見られた。(極端に明るい恒星はなかったので)恒星などの飛びは見られなかった。1に比べて恒星が明らかに小さくなった。
  3. 星雲の明るい部分に青飛びが見られた。(極端に明るい恒星はなかったので)恒星などの飛びは見られなかった。1に比べて恒星が明らかに小さくなった。ちなみに、LinLRGBはPixInsightに標準で組み込まれているものではなく、Hartmut Bornemann氏が作ったもので、ここにインストールの仕方の説明があります。
  4. 青飛びが少し改善した。1に比べて恒星が明らかに小さくなった。ただし最初にストレッチしすぎたせいか、解像度があまり出なかった。
  5. 青飛びが無くなった。1に比べて恒星が明らかに小さくなった。ただし最初にストレッチしすぎたせいか、解像度があまり出なかった。
  6. 青飛びが無くなった。1に比べて恒星が明らかに小さくなった。ストレッチしすぎてなかったせいか、一番解像度が出た

というわけで、正しいと思われる4番は悪くないですが、青飛びを完全に解決できなかったことと、ストレッチの度合いがRGBとLが別だとどこまでやっていいかの判断がつきにくく、結局6番を採用しました。でもストレッチをあまりかけずにLを合成することが正しい方法なのかどうか、いまだによくわかっていません。その一方、Lab変換でabをボカしたことが青飛びを完全に回避しているので、手段としては持っておいてもいいのかもしれません。


仕上げ

その後、Photoshopに渡して仕上げます。分解能を出すのにものすごく苦労しました。AstrtoBinでM51を検索するとわかりますが、形の豪華さの割に、大きさとしては小さい部類のM51の分解能を出すのはなかなか大変そうなのがわかります。物凄く分解能が出ている画像が何枚かあったので「おっ!」と思ったのですが、実際にはほとんどがHubble画像の再処理でした。1枚だけHubble以外でものすごい解像度のものがありましたが、望遠鏡の情報を見たら口径1メートルのものだったのでさすがに納得です。それよりもタカsiさんが最近出したM51の解像度が尋常でないです。口径17インチなので約43cm、これでAstroBinにあった口径1メートルの画像に勝るとも劣りません。43cmでここまででるのなら、自分の口径26cmでももう少し出てもおかしくないのかと思ってしまいます。今回私の拙い技術で出せたのはこれくらいです。クロップしてあります。

「M51:子持ち銀河」
masterLight_ABE_crop_BXT_BXT_Lab_conv5_Lab_CT_bg2_cut_tw

  • 撮影日: RGB: 2022年4月2日20時32分-4月3日3時50分、LとHa: 2023年3月29日20時17分-3月30日4時34分
  • 撮影場所: 富山県富山市自宅
  • 鏡筒: SHARP STAR製 SCA260(f1300mm)
  • フィルター: Baader RGB、Hα
  • 赤道儀: Celestron CGX-L
  • カメラ: ZWO ASI294MM Pro (-10℃)
  • ガイド:  f120mmガイド鏡 + ASI290MM、PHD2によるマルチスターガイドでディザリング
  • 撮影: NINA、Gain 240で露光時間10分がR: 7枚、G: 7枚、B: 10枚、Gain 240で露光時間5分がL: 47枚、Hα: 21枚の計27枚で総露光時間240+340 =580分 =9時間40分
  • Dark: Gain 240で露光時間10分が64枚、Gain 240で露光時間5分が128枚
  • Flat, Darkflat: Gain 240で露光時間 RGB: 0.03秒、L: 0.01秒、Hα: 0.2秒、 RGBがそれぞれ64枚、LとHαがそれぞれ128枚
  • 画像処理: PixInsight、Photoshop CC

元の大きさではこうなります。ただしbin1のままだと画素数が多すぎてブログにアップロードできないので、解像度を縦横半分のbin2相当にしてあります。

masterLight_ABE_crop_BXT_BXT_Lab_conv5_Lab_CT_bg2_lowreso

中心部を比較してみます。左が昨年のRGBだけのもの、右がL画像とHα画像を撮り増ししたものです。
comp

見比べると、明らかに今回のL画像が入った方が分解能が増していることがわかります。ただすでに画像処理がキツすぎる気もしています。今の機材でこれ以上の分解能を求めるにはどうしたらいいのでしょうか?

考えられる改良点は、
  • シーイングのいい時に撮影する。
  • Lがフィルター無しなので、UV/IRカットフィルターを入れて赤外のハロなどをなくす。
  • 振動が問題になる可能性があるので、三脚の足に防震シートなどを入れる。
  • 読み出しノイズに制限されているわけではなさそうなので、揺れ対策で1枚あたりの露光時間を3分ほどにしてみる。
  • Lの総露光時間をもっと増やす。
  • 暗い空で撮影する。
  • バローを入れて焦点距離を伸ばし、かつbin1で撮影する。
などでしょうか。小さな天体を撮影する際の今後の課題としたいと思います。


まとめ

BXTという観点からはあまり大したことは言えていません。分解能という観点からはDeNoise AIとそこまで能力は差がなさそうなことがわかりますが、恒星の収差補正などに利点があり、今後DeNoise AIを使うことはほぼなくなるでしょう。リニアなステージで使うことが正しそうで、RGBとLで別々に処理して合成しても問題なさそうなことがわかりました。BXTなしとありでは分解能に圧倒的に差が出て、今回もM51としてはそこそこの分解能になっていますが、まだ鏡筒の性能を引き出し切っているとは言い難いのかと思います。

RGBだけの場合と、Lがある場合では分解能にあからさまに差が出ることが改めてわかりました。でもなぜそこまで差が出るのか、自分自身本質的にはあまりよくわかっていません。単にLの露光時間が長いからなのか? R、G、Bとフィルターで光量が減るので、それに比べて全部の光子を拾うLが得なのか? それとも他に何か理由があるのか? 一度、R、G、B、Lを全て同じ時間撮影して、RGB合成したものからLを引き出して比較してみるのがいいのかもしれません。

とまあ色々議論したいことはありますが、庭撮りで着実に進歩はしてきていて、M51がここまで出たこと自身はある程度満足しています。でももう少し出るかと淡い期待を抱いていたことも事実です(笑)。


2022年の反省でも述べましたが、最近自分で考えることがあまりできてなかったので、今回の記事は久しぶりに計算です。内容は、撮影した画像にはどんなノイズが入っていて、それぞれどれくらいの割合になっているかを見積ってみたという話です。


動機

まずは動機です。1月に開田高原でM81を撮影した時に、M81本体に加えて背景のIFNが見えてきました。下は300秒露光を28枚撮影したL画像を強度にオートストレッチしています。
masterLight_BIN-2_4144x2822_EXPOSURE-300.00s_FILTER-L_mono

一方、2022年の5月にも自宅で同じM81を撮影しています。背景が埃とスカイノイズで淡いところがまってく出なかったので記事にしていないのですが、下は露光時間600秒を22枚撮影したL画像で、強度にオートストレッチして、かつできるだけ見やすいようにABEとDBEをかけてカブリを排除しています。開田高原の時よりもトータル露光時間は1.6倍ほど長く、被りを除去しても、淡い背景については上の画像には全く及びません。
masterLight_600_00s_FILTER_L_mono_integration_ABE_DBE3
明らかにスカイノイズの影響が大きいのですが、これを定量的に評価してみたくなったというものです。

もう一つの動機ですが、このブログでも電視観望について多くの記事を書いています。電視観望はリアルタイム性を求めることもあるので、露光時間を短くしてゲインを高く設定することが多いです。この設定が果たして理に適っているのかどうか、これも定量的に議論してみたいとずっと思っていました。


目的

これからする一連の議論の目的ですが、
  1. 画像に存在するどのノイズが支配的かを知ること。
  2. 信号がノイズと比較して、どの程度の割合で効くのかを示す。
  3. 電視観望で高いゲインが有利なことを示す。
を考えてたいと思っています。今回の記事はまずは1番です。こちらはスカイノイズをどう評価するかが鍵なのかと思っています。

2番は意外に難しそうです。信号である天体は恒星ならまだしも、広がっている天体の明るさの評価ってなかなか大変です。これは後回しにするかもしれません。

3番は長年の電視観望がなぜ短時間で天体を炙り出せるのかという疑問を、定量的に表す事ができたらと考えています。こちらは大体目処がついてきたので、近いうちに記事にするかと思います。


基本的なノイズ

天体画像撮影におけるノイズは5年くらい前にここで議論しています。SN比の式だけ抜き出してくると

S/N=ntSsigAnσ2+AntSsky+AntSdark+ntSsignS/N=ntSsigAnσ2+AntSsky+AntSdark+ntSsign
と書くことができます。ここで、
  • AA [pix] : 開口面積
  • nn : フレーム枚数
  • σσ [e-/pix] : 読み出しノイズ
  • tt [s] : 1フレームの積分(露光)時間
  • SskySsky  [e-/s/pix] : スカイバックグラウンド
  • SdarkSdark  [e-/s/pix] : 暗電流
  • SsigSsig  [e-/s] : 天体からの信号
となり、S/Nとしては何枚撮影したかのルートに比例する事がわかります。今回のノイズ源としては読み出しノイズ、スカイノイズ、ダークノイズを考えます。ショットノイズは天体などの信号があった場合に加わるノイズですが、今回は天体部分は無視し背景光のみを考えるため、天体からのショットノイズは無視することとします。

重要なことは、読み出しノイズは露光時間に関係なく出てくるために分母のルートの中にtがかかっていないことです。そのため、他のノイズは1枚あたりの露光時間を伸ばすとS/Nが上がりますが、読み出しノイズだけは1枚あたり露光時間を増やしてもS/Nが上がらないということを意識しておいた方がいいでしょう。その一方、撮影枚数を稼ぐことは全てのノイズに対してS/N改善につながり、読み出しノイズも含めて撮影枚数のルートでS/Nがよくなります。繰り返しになりますが、一枚あたりの露光時間を伸ばすのでは読み出しノイズだけは改善しないので、他のノイズに比べて効率が悪いということです。

分子にあたる天体信号の評価は意外に大変だったりするので、今回は分母のノイズのみを考えることにします。


パラメータ

上の式を元に、ここで考えるべきパラメータを固定しやすいもの順に書いておきます。
  1. カメラのゲイン(gain)
  2. 温度 (temperature)
  3. 1枚あたりの露光時間 (time)
  4. 空の明るさ
の4つで実際に撮影した画像の各種ノイズを推定できるはずです。少し詳しく書いておくと、
  • 1は撮影時のカメラの設定で決める値です。読み出しノイズ (read noise)を決定するパラメータです。
  • 2は撮影時のセンサーの温度で、冷却している場合はその冷却温度になります。単位は[℃]となります。この温度と次の露光時間からダークノイズを決定します。
  • 3は撮影時の画像1枚あたりの露光時間で、単位は秒 [s]。2の温度と共にダークノイズ (dark noise)を決定します。ダークノイズの単位は電荷/秒 [e/s]。これは[e/s/pixel]と書かれることもありますが、ここでは1ピクセルあたりのダークノイズを考えることにします。なお、ホットピクセルはダークノイズとは別と考え、今回は考慮しないこととします。ホットピクセルは一般的にはダーク補正で除去できる。
  • 4は撮影場所に大きく依存します。今回は実際に撮影した画像から明るさを測定することにします。単位は [ADU]で、ここからスカイノイズを推測します。ちなみに、3の露光時間も空の明るさに関係していて、長く撮影すれば明るく写り、スカイノイズも増えることになります。

実際のパラーメータですが、今回の記事ではまずはいつも使っている典型的な例で試しに見積もってみます。私はカメラは主にASI294MM Proを使っていて、最近の撮影ではほとんど以下の値を使っています。
  1. 120
  2. -10℃
  3. 300秒
これらの値と実際の画像から背景光を見積もり、各種ノイズを求めることにします。


読み出しノイズ

読み出しノイズはカメラのゲインから決まります。ZWOのASI294MM Proのページを見てみると、


真ん中の少し手前あたりにグラフがいくつか示してあります。各グラフの詳しい説明は、必要ならば以前の記事



をお読みください。上の記事でもあるように、カメラの各種特性はSharpCapを使うと自分で測定する事ができます。実測値はメーカーの値とかなり近いものが得られます。

グラフから読み出しノイズを読み取ります。gain 120の場合おおよそ

1.8 [e rms]

ということがわかります。rmsはroot mean sqareの意味で日本語だと実効値、時系列の波形の面積を積分したようなものになります。例えば片側振幅1のサイン波なら1/√2で約0.7になります。他のノイズも実効値と考えればいいはずなので、ここではrmsはあえて書かなくて

1.8 [e]

としていいでしょう。

読み出しノイズは、実際の測定では真っ暗にして最短露光時間で撮影したバイアスフレームのノイズの実測値に一致します。以前測定した結果があるので、興味のある方はこちらをご覧ください。



ダークノイズ

ダークノイズの元になる暗電流に関しては温度と1枚あたりの露光時間が決まってしまえば一意に決まってしまい、これもZWOのASI294MM Proのページから読み取ることができます。

私はこの値を実測したことはないのですが、そーなのかーさんなどがSV405CCですが同系のIMX294センサーで実測していて、メーカー値とほぼ同じような結果を得ています。

グラフから温度-10℃のところの値を読み取ると暗電流は

0.007 [e/s/pixel]

となるので、1枚あたりの露光時間300秒をかけると

2.1 [e/pix]

となります。/pixはピクセルあたりという意味なので、ここは略してしまって

2.1[e]

としてしまえばいいでしょう。単位[e]で考えた時に、暗電流のルートがダークノイズになるので、

sqrt(2.1)=1.5[e]

がダークノイズとなります。

(追記: 2023//4/19) ちょっと脱線ですが、だいこもんさんのブログを読んでいると、2019年末の記事に「dark currentはgain(dB)に依存しないのか?」という疑問が書かれています。答えだけ言うと、[e]で見ている限り横軸のゲインに依存しないというのが正しいです。もしダークカレント、もしくはダークノイズを[ADU]で見ると、元々あったノイズがアンプで増幅されると言うことなので、単純に考えて横軸のゲイン倍されたものになります。実際の画面でも横軸ゲインが高いほど多くのダークノイズが見られるでしょう。でも、コンバージョンファクターをかけて[ADU]から[e]に変換する際に、コンバージョンファクターが横軸のゲイン分の1に比例しているので、積はゲインによらずに一定になるということです。

ちなみに、ホットピクセルはダーク補正で取り除かれるべきもので、ここで議論しているダークノイズとは別物ということを補足しておきたいと思います。

(さらに追記:2023/10/15)
ダークファイルを撮影したので、実際のダークノイズを測定してみました。画像からのノイズの読み取り値は2.6 [ADU]でした。コンバージョンファクターで単位を[e]にすると、2.6x0.9 = 2.3 [e]。ここから読み出しノイズを引いてやると、2乗の差のルートであることにちゅいして、sqrt(2.3^2-1.8^2) = 1.5 [e] と見積り値に一致します。このように、見積もりと実測が、かなりの精度で一致することがわかります。


スカイノイズ

ここが今回の記事の最大のポイントです。読み出しノイズとダークノイズだけならグラフを使えばすぐに求まりますが、恐らくスカイノイズの評価が難しかったので、これまでほとんど実画像に対してノイズ源の評価がなされてこなかったのではないでしょうか?ここでは実画像の背景部の明るさからスカイノイズを推測することにします。

まず、明るさとノイズの関係ですが、ここではコンバージョンファクターを使います。コンバージョンファクターはカメラのデータとして載っています。例えばASI294MM Proでは先ほどのZWOのページにいくと縦軸「gain(e/ADC)」というところにあたります。コンバージョンファクターの詳しい説明は先ほど紹介した過去記事を読んでみてください。コンバージョンファクターは他に「ゲイン」とか「システムゲイン」などとも呼ばれたりするようです。名前はまあどうでもいいのですが、ここではこの値がどのようにして求められるかを理解すると、なぜスカイノイズに応用できるか理解してもらえるのかと思います。

コンバージョンファクターの求め方の証明は過去記事の最後に書いてあるので、そこに譲るとして、重要なことは、画像の明るさSとノイズNは次のような関係にあり、
(N[ADU])2=S[ADU]fc[e/ADU](N[ADU])2=S[ADU]fc[e/ADU]明るさとノイズの二つを結ぶのがコンバージョンファクターfcとなるということです。逆にいうと、このコンバージョンファクターを知っていれば、明るさからノイズの評価が共にADU単位で可能になります。

もっと具体的にいうと、コンバージョンファクターがわかっていると、スカイノイズが支配していると思われる背景部分の明るさを画像から読み取ることで、スカイノイズを直接計算できるということです。これは結構凄いことだと思いませんか?


実際のスカイノイズの見積もり

それでは実画像からスカイノイズを見積もってみましょう。最初に示した2枚のM81の画像のうち、上の開田高原で撮影した画像の元の1枚撮りのRAW画像を使ってみます。

上の画像は既にオートストレッチしてあるので明るく見えますが、ストレッチ前の実際のRAW画像はもっと暗く見えます。明るさ測定はPixInsight (PI)を使います。PIには画像を解析するツールが豊富で、今回はImageInspectionのうち「Statistics」を使います。まず画像の中の暗く背景と思われる部分(恒星なども含まれないように)をPreviewで選び、StatisticsでそのPreviewを選択します。その際注意することは、カメラのADCのbit深度に応じてStatisticsでの単位を正しく選ぶことです。今回使ったカメラはASI294MM Proなので14bitを選択します。輝度の値は「mean」を見ればいいでしょう。ここでは背景と思われる場所の明るさは約920 [ADU]と読み取ることができました。ついでに同じStatisticsツールのノイズの値avgDevをみると17.8 [ADU]と読み取ることが出来ました。

もっと簡単には、画像上でマウスを左クリックするとさまざまな値が出てきますので、その中のKの値を読み取っても構いません。ここでも同様に、単位を「Integer Renge」で手持ちのカメラに合わせて「14bit」などにすることに注意です。

いずれのツールを使っても、背景と思われる場所の明るさは約920[ADU]と読み取ることができました。

前節の式から、輝度をコンバージョンファクターで割ったものがノイズの2乗になることがわかります。gain120の時のコンバージョンファクターはグラフから読み取ると0.90程度となります。

これらのことから、背景に相当する部分のノイズは以下のように計算でき、

sqrt(920/0.90) = 32.0 [ADU] -> 28.8 [e]

となります。どうやら他の読み出しノイズやダークノイズより10倍程大きいことになります。あれ?でもこれだとちょっと大きすぎる気がします。しかも先ほどのStatisticsツールでの画面を直接見たノイズ17.8[ADU]をコンバージョンファクターを使って変換した

17.8 [ADU] x 0.90 [e/ADU] = 16.0 [e]

よりはるかに大きいです。これだと矛盾してしまうので何か見落としているようです。

計算をじっくり見直してみると、どうやら測定した輝度は「背景光」とオフセットの和になっているのに気づきました。撮影時のオフセットとして40を加えてありますが、この値に16をかけた640がADUで数えたオフセット量として加わっているはずです。実際のマスターバイアス画像を測定してみると、輝度として平均で約640 [ADU]のオフセットがあることがわかったので、これは撮影時に設定したものとぴったりです。この値をを920 [ADU]から引いて、280 [ADU]を背景光の貢献分とします。その背景光からのスカイノイズ成分は

sqrt(280/0.90) = 17.6 [ADU]


これを[ADU]から[e]に変換するためにさらにコンバージョンファクター[e/ADU]をかけて

17.6 [ADU] x 0.90 [e/ADU] = 15.9 [e]

となります。これだと画面からの実測値16.0[e]と少なくとも矛盾はしませんが、既に実測のトータルノイズにかなり近い値が出てしまっています。果たしてこれでいいのでしょうか?


各ノイズの貢献度合い

次にこれまで結果から、各ノイズの貢献度を見ていき、トータルノイズがどれくらいになるのかを計算します。

画像1枚あたりの背景に当たる部分の各ノイズの貢献度は多い順に
  1. スカイノイズ: 15.9[e]
  2. 読み出しノイズ: 1.8 [e]
  3. ダークノイズ: 1.5[e]
となります。Statisticsツールで測定した実際の1枚画像の背景のノイズの実測値は14.9[e]程度だったので、上の3つのノイズがランダムだとして2乗和のルートをとると、

sqrt(15.9^2+1.8^2+1.5^2) = 16.0 [e]

となり、実測の16.0[e]になる事がわかります。スカイノイズに比べてトータルノイズがほとんど増えていないので、読み出しノイズとダークノイズがほとんど影響していないじゃないかと思う方もいるかもしれません。ですが、互いに無相関なノイズは統計上は2乗和のルートになるので本当にこの程度しか貢献せず、実際にはスカイノイズが支配的な成分となっています。

ここまでの結果で、今回のスカイノイズ成分の推定は、定量的にも実画像からの測定結果とほぼ矛盾ないことがわかります。この評価は結構衝撃的で、暗いと思われた開田高原でさえスカイノイズが圧倒的だという事がわかります。


富山の明るい空

ちなみに、最初の2枚の画像のうち、下のものは自宅で撮影したM81です。富山の明るい北の空ということもあり、そのRAW画像のうちの最も暗い1枚(2022/5/31/22:48)でさえ、背景の明るさの読み取り値はなんと3200[ADU]程度にもなります。バイアス640を引くと2560[ADU]で、開田高原の背景光の値240に比べ約10倍明るく、ノイズは

sqrt(2560/0.90) = 53.3 [ADU] -> 48.0 [e]

となります。実際の画像からPIのStatisticsで読み取ったトータルノイズの値が53.4[ADU]->48.1[e]でした。

スカイノイズ48.0[e]に、読み出しノイズ1.8 [e] 、ダークノイズ1.5[e]を2乗和のルートで考えるとトータルノイズは

sqrt(45.0^2+1.8^2+1.5^2) = 48.1 [e]

となり、明るい画像でも背景光の輝度から推測したノイズをもとに計算したトータルノイズ値と、画面から実測したノイズ値が見事に一致します。

開田高原の暗い画像でさえスカイノイズが支配的でしたが、富山の明るい空ではスカイノイズが読み出しノイズ、ダークノイズに比べて遥かに支配的な状況になります。淡いところが出なかったことも納得の結果です。

うーん、でもこんなスカイノイズが大きい状況なら
  • もっと露光時間を短くして読み出しノイズを大きくしても影響ないはずだし、
  • 冷却温度ももっと上げてダークノイズが大きくなっても全然いいのでは
と思ってしまいます。でもそこはちょっと冷静になって考えます。早急な結論は禁物です。次回の記事では、そこらへんのパラメータをいじったらどうなるかなどに言及してみたいと思います。


まとめ

背景の明るさとコンバージョンファクターから、スカイノイズを見積もるという手法を考えてみました。実際の撮影画像のノイズ成分をなかなか個別に考えられなかったのは、スカイノイズの評価が難しいからだったのではないかと思います。

今回の手法は背景の明るさが支配的と思われる部分がある限り(天体写真のほとんどのケースは該当すると思われます)スカイノイズを見積もる事ができ、状況が一変するのではと思います。また手法も輝度を測るだけと簡単なので、応用範囲も広いかと思われます。

今回の手法を適用してみた結果、実際に遠征した開田高原のそこそこ暗い空で撮影した画像でさえもスカイノイズが支配的になる事がわかりました。もっと暗い状況を求めるべきなのか?それとも露光時間を短くしたり、温度を上げてしまってもいいのか?今後議論していきたいと思います。

とりあえず思いつくアイデアをばっとまとめてみましたが、もしかしたら何か大きな勘違いなどあるかもしれません。何か気づいたことがありましたらコメントなどいただけるとありがたいです。


この記事の続き



になります。露光時間と温度について、実際の撮影においてどの程度にすればいいか評価しています。








先週末に開田高原に遠征した際に撮影したM81です。撮影時の様子は前回の記事に書いてるので、今回は主に画像処理についてです。



WBPPとLRGB合成

今回は撮影した画像はLRGBに加えて、赤ポチをアクセントに加えたいのでHαも撮っています。

撮影中のNINAの画像ですが、5分の1枚どりなのでに以前自宅で3時間分をスタックしたのに迫るくらいの淡いところが出ています。撮影中からこれは期待できそうだという感触でした。
Fm_6VpNacAM0yEK


画像処理はPixInsightのWBPPでLRGBAいっぺんに処理します。

L画像を撮影している際の午前2時半頃に子午線で反転した際に、どうやらカメラが回転してしまったようです。光条線ではほとんど目立ちませんでしたが、強度にストレッチしたら画像周りに三角形でS/Nが悪い部分が見えたので、少し余分にクロップしています。

できたL、R、G、BをそのままPIのLRGBcombinationで一気に合成してしまいます。RGBの色バランスが例えずれていてもSCPPで背景のニュートラルまでふくめて調整できることと、彩度は保たれていることは検証してあるからです。


SPCCの参照銀河

SPCCで参照銀河を平均とM81のSa型で比べてみました。

平均:
Image09_LRGB_crop_ABE1_ABE2_SPCCave

Sa型:
Image09_LRGB_crop_ABE1_ABE2_SPCCsa

やはり少し違いが出ます。Sa型の方がより青く出るようです。銀河によってタイプを変えることで、より近い色になるのかと思います。今回はSa型を採用しました。


NoiseXTerminator

ノイズ処理でよく出てくる不自然なモコモコはあまり好きではないのですが、ツールを色々変えてもどうしてもある程度出てきてしまいます。NoiseXTerminator (NXT)も例外ではないのですが、Denoiseの値を例えば0.75などの大きくして一度にかけるのではなく、例えば0.25とかして3回かけた方がいいようです。

NXTをかける前:
Image09_ABE_ABE


Denoise:0.75, Detail:0
Image09_ABE_ABE_NXTx075

Denoise:0.25x3, Detail:0
Image09_ABE_ABE_NXTx025x3

0.75一回の時は明らかにノイズ処理によりのっぺりしていますが、0.25が3回の時はあまり大きな構造は見えず、ノッペリ感もなく、適度に細かいノイズは除去されています。

まだ最適な使い方はよくわかりませんが、Denoiseの度合いとかける回数である程度の空間周波数の調整はできそうなことがわかります。


結果

出来上がった画像です。

「M81:ボーデの銀河」
Image09_LRGB_crop_ABE1_ABE2_SPCCsa_BXT_MS_SCNR6
  • 撮影日: 2023年1月21日21時19分-22日5時22分
  • 撮影場所: 長野県開田高原
  • 鏡筒: SHARP STAR製 SCA260(f1300mm)
  • フィルター: Baader RGB
  • 赤道儀: Celestron CGX-L
  • カメラ: ZWO ASI294MM Pro (-10℃)
  • ガイド:  f120mmガイド鏡 + ASI290MM、PHD2によるマルチスターガイドでディザリング
  • 撮影: NINA、Gain 120、露光時間5分、L:28枚、R:12枚、G:11枚、B:12枚、Hα:6枚の計69枚で総露光時間5時間45分
  • Dark: Gain 120、露光時間5分、温度-10℃、32枚
  • Flat, Darkflat: Gain120、露光時間 L:0.001秒、128枚、RGB:0.01秒、128枚、Hα:20秒、17枚(dark flatは32枚)
  • 画像処理: PixInsight、Photoshop CC

反省点です。
  • 背景のモクモクがやっと出たのはかなり嬉しかったです。実は昨年5月に自宅で撮影していて、その時はどう画像処理してもカスリもしなかったので、お蔵入りになりました。なので今回暗い開田高原で撮影した甲斐が大いにありました。その一方、まだかなりノイジーで今回は画像処理で誤魔化しているところがあるのは否めません。L画像だけで10時間とか撮影したくなってきます。
  • 背景に緑色の構造が見えます。これが本当に正しいのか?形はあっているようですが、色がこれでいいのかまだよくわかっていません。ゴースト星雲の時もそうだったのですが、WBPPのLocal Normarizationが悪さをしている可能性があります。もしくはフラットを使い回しているので、合っていないのかもしれません。
  • 恒星が少し不自然です。今回MaskedStretchを使ったのですが、どうも暗くなって迫力にかけます。最近はHistgramTransformでわざとサチらせた方が自然に見える気がしています。まだ恒星処理は下手です。
  • 恒星があまり綺麗でないもう一つの原因が、背景を相当炙り出しているからです。今回スターマスクの類を使わなかったのですが、スターマスクを使ってもう少し丁寧に処理した方が良かったのかと思います。
  • BXTで恒星を小さくできるのですが、小さすぎておかしくならないように多少加減しています。でも後の炙り出しで多少見かけが大きくなることがあるので、リニアの段階ではもう少し小さくしていいのではと思いました。
  • 右上に斜めに走る2本の光が入ってしまっています。RAW画像を見るとL、G画像はほぼ全て、B画像は後半のもので確認できました。RとA画像には入っていませんでした。どうも漏れ光の疑いがあります。原因究明と、フラット取り直しが必要そうです。
  • 昨年春の撮影(結局お蔵入りしたもの)はM82とモザイク合成することを前提にセットで撮っています。自宅と開田高原で背景にこれだけ差があると、おそらく自宅でとってもモザイク合成するのは難しいでしょう。もう一度あの寒いところに行くか?それとも春を待って飛騨コスモスで撮るか?迷うところです。

恒例のAnnotationです。画像処理での回転補正なしですが、縦横もかなり合っていますね。
Image09_LRGB_crop_ABE1_ABE2_SPCCsa_BXT_MS_SCNR5_Annotated


Integrated Flux Nebula

銀河周りにある淡いモヤモヤですが、「Integrated Flux Nebula」と呼ばれていて、略して「IFN」とか、「IF Nebula」とか言うようです。日本語ではなんて言うんでしょうか?調べてみたら「銀河巻雲」という言葉が出てきました。

IFNが認識されたのは結構最近とのことで、文献を見ると2005年が一番古いようで、その著者のSteve Mandelによって名付けられたようです。彼のスライドを見ると例が出ています。一見の価値ありで、アマチュア天文に関しても少し触れられています。

基本的にはIFNは我々の銀河系の外に広がっているもので、天の川全体からのエネルギーによって照らされているということです。

M81、M82まわりのINFが有名みたいで、上記文献でも表紙にM81とM82が出ています。星雲本体を超えて、もっと相当広い範囲にわたって広がっている星雲全体を言うようです。今回はそのうちのM81本体のごく一部が出てきたということです。文献に「我々が思っているより多くの星雲がある」と書いてあり、さらにプロもそれに続けと書いてあるので、もしかしたらアマチュアの結果が先に出てきたのかもしれません。そういった意味では我々アマチュア天文家としても非常に興味深いものになるのかと思います。暗い空が必要ですが、IFNをターゲットとして、短焦点でもっと広い範囲を長時間かけて撮影してみるのも面白いのかもしれません。


まとめ

背景に関しては自宅では絶対出そうにないところまででているので、寒い中撮影した甲斐が十分にありました。やはり暗いところで撮影するのは十分に価値のあることだと思います。

IFNをターゲットに少し挑戦してみたくなりました。焦点距離は400mm以下でしょうか。手持ちで単焦点であまり明るい鏡筒がないので、できればε130とかが欲しくなります。

明るい対象は自宅で、淡いものは遠征でという使い分けを今後していくことになるのかと思います。そのためには遠征前にターゲットを十分に吟味しておくべきです。でも今回なんか、その場でM81に決めたので、これじゃあダメですね。


前回記事のゴースト星雲の処理の続きです。




前回はSPCCまでで、モノクロ撮影でBaaderフィルターを選んだらうまく補正ができたという話でした。今回は主にBlurXTerminatorについて試してみて、ゴースト星雲を仕上げています。


BlurXTerminator 

今回はBlurXTerminator (以下BXT)と呼ばれるdeconvolutionソフトを処理してみます。このソフトはRussell Croman氏が独自に書いているもので、氏が書いているいくつかのソフトの最新のものです。特に2021年から機械学習を取り入れたXTerminatorシリーズはノイズ除去のためのNoiseXTerminator (NXT)、スターレス画像を作るStarXTerminator (SXT)といずれも大きな話題となっています。

ノイズ除去ソフトは他にも実用レベルのものがいくつもあるのと、スターレス画像についてはStarNet V2が無料でかなり性能がいいので、私はこれまで氏のソフトは使ってきませんでした。それでも今回のBXTは分解能が信じられないほどに向上するようです。

私自身がdeconvolutionが苦手で、これまでも実際に作例にまで適用したのは数例。大抵は試してもあまり効果がなかったり、リンギングが出たりで、よほどうまくいった場合でないと適用してきませんでした。deconvolutionはどうしても時間を費やしてしまうので、画像処理の中でも大きな鬼門の一つでした。

BXTは、マニュアルとかに書いてあるわけではないようなのですが、基本的にはリニア画像のL画像のみに使うべきだという噂です。とりあえずまずはスタック直後のL画像で検証してみます。パラメータは基本的に2つだけで、
  1. 星像をどこまで小さくするかと、
  2. 分解能をどこまで出すか
だけです。

星像の補正

パラメータは上記の2つだけですが、BXTで「Correct」と呼ばれている、あまり注目されていな星像補正の効果があります。これだけでもかなりすごいので、まずはそこに注目してみたいと思います。

この機能はBXTを走らせるとデフォルトで適用される機能です。ですがこの機能の凄さを確かめるために「Correct Only」オプションをオンにして、この機能だけを試してみます。星像を小さくしたりとか、星雲の分解能を上げるといいった効果を適用「しない」、ある意味BXTのベースとなるような機能です。

マニュアルを読むと以下のものを補正できるそうです。
  • limited amounts of motion blur (guiding errors)
  • astigmatism
  • primary and secondary coma
  • unequal FWHM in color channels
  • slight chromatic aberration
  • asymmetric star halos.
とあります。日本語に意訳すると、
  • ある程度のブレ(ガイドエラー)
  • 非点収差
  • 1、2次のコマ収差
  • 各色のFWHM (星像の大きさ) の違い
  • 多少の色収差
  • 非対称なハロ
となります。どうやらものすごい威力のようです。マニュアルにはさらに「画像位置によってそれぞれローカルなPSFを適用する」ということで、たとえば四隅ごとに星像の流れが違っていてもそれぞれの流れに応じて補正してくれるようです。こんなソフトは私の知る限りこれまでなかったはずで、もし本当ならすごいことです。

試しにスタック後のL画像でオリジナルの画像とCorrect onlyだけで試した結果を比較して、四隅をGIFアニメにしてみました。
masterLight_BIN_2_4144x2822_EXPOSURE_300_00s_FILTER_L

自分的には四隅とも十分真円に見えていたので、全然問題ないと思っていました。でもBXTは躊躇することなくおかしいと認識しているようで、正しく直してくれているようです。左下は星像の大きさが少し小さくなるくらいでままだましですが、左上の画像は少し下方向に、右上の画像は大きく左下方向に、右下の画像は大きく左方向にずれていたことがわかります。本当に正しく直しているかどうかは今の段階では不明ですが、少なくとも見た目は正しい方向に直しくれているようです。効果が分かりにくいという方は、できるだけ画面を拡大して見てみてください。

この結果はすごいです。実際の撮影が完璧にできることはほとんど無理で、何らかの不具合がある方がごくごく普通です。これらのことが画像処理で補正できるなら、安価な機材が高価な機材に迫ることができるかもしれませんし、なにより撮影時のミスなどで無駄にしたと思われる時間を救い出せるかもしれません。はっきり言って、この機能だけでも購入する価値があると思います。

また、BXTはL画像のみに適用した方がいいとも言われていますが、マニュアルによると各色の星像の大きさの違いも補正できるということなので、BXTをカラー画像に適用することも可能かと思われます。


恒星の縮小

上記補正はBXTでデフォルトで適用される機能。さらにすごい機能が続きます。BXTの適用例を見ていると、普通は星雲部の構造を出すのに期待すると思うのですが、私はdeconvolutionの原理といってもいい星像を小さくする効果にとんでもなく驚かされました。まずは背景の効果をオフにして、星像改善のみSharpen Starsが0.25、Adust Star Halosが-0.25として、適用してみます。

Original:
orignal

BXT (恒星の縮小のみ):
staronly

まだ小さくすることもでき不自然になることもほとんどないですが、とりあえず今回はほどほどにしておきます。特に左下の明るい星に注目してもらえるとよくわかるかと思いますが、近づいていていあまり分離できていない2つの星がはっきりと分離されます。パラメータによってはハロの処理が少し不自然に見えたりもしますが、自分で頑張ってやった場合より遥かにましなハロになっているので、全然許容範囲です。

これもすごい効果ですね。星像を小さくするのはいつも相当苦労するのですが、リンギングなどもほとんど出ることがなく、このソフトが決定版の気がしています。ぜひともM57の分解能ベンチマークに使ってみたいです。


背景の分解能出し

やっとBXTの一番の目玉の背景の構造を出す機能です。今回はゴースト星雲のバンザイしている手のところなどを見ながらパラメータを攻めていきました。結局のところ、構造を出すSharpen Nonstellerはかなり大きな値にしないとほとんど効果は見えなかったのでデフォルトの0.9のまま、それよりもPSFをマニュアルで設定することで効果が大きく変わることがわかりました。興味があるところをpreviewで表示して効果を見ながら値を決めればいいと思いますが、今回は最終的にPSF Diameterを0.75、Sharpen Nonstellerを0.90にしました。

結果としては以下のような違いとなりました。

Original:
orignal

BTX(恒星の縮小と背景の分解能出し):
BXT_all

あまり効果があるように見えていませんが、これ以上分解能を出すと、ゴースト君が崩れてきてしまいました。かなり拡大して見ているのですが、ここまで拡大してみることをしないなら、もっと大きな構造を見ながら細部を調整するという手もあるかと思います。


その後の画像処理

でもですね、結局L画像にBXTを適用するのは止めました。じゃあどうしたかというと、スタック後RGB合成した後、そのままL画像とLRGB合成をして、その後にSPCC、CTで色出し、その後にやっとBXTを適用しました。

理由は、L画像のみに適用するよりもLRGB画像に適用する方が、特に細部出しのところでノイズに負けずにゴースト部分が出たというのが大きいです。

カラー画像に適用した場合でも、懸念していた恒星の色ズレもなかったです。今回は色々やって最後この順序になりましたが、この順序が正しいかどうかもまだよく分かっていません。BXTはパラメータこそ少ないですが、他のプロセスとの組み合わせで、順序なども考えたら無限の組み合わせがあり、ものすごく奥の深いソフトなのかと思います。

その際、BXTのついでに、NoiseXTerminator(NXT)も使ってみました。もちろんノイズ除去の効果があったのはいうまでもないのですが、その結果大きく変わったことがありました。PixInsightの使用する割合が多くなり、これまでストレッチ後のほとんどの処理を担っていたPhotoshopの割合が相当減って、処理の大方針が大きく変わったのです。具体的にはdeconvolutionが楽になったこと、そのため恒星の処理が楽になったこと、ノイズ処理もPixInsightでNXTで動くことが大きいです。不確定要素を少なくするという意味でも、PIの処理を増やすのは多分真っ当な方向で、以前から考えていてできる限りの処理をPIのみで済ませたいという思いがやっと実現できつつある気がします。

あともう一つ、PIのWBPPでいつものようにLocal Normarizationをオンにしおいたのですが、どうやらこれが悪さをしていたようでした。RGBでそれぞれの背景の大構造でズレが起きてしまったようで、背景に大きな色むらができてしまいました。ABEのせいかとも思い色々探っていって、やっと最後にLNが原因だと突き止めるに至りました。明るい光害地で、かなり無理して淡いところを出していて、スカイノイズの影響は大きいはずです。もしかしたらそこら辺も関連しているのかもしれません。暗いところに行くか、さらに撮影時間を伸ばす必要がありそうです。ここら辺が今後の課題でしょうか。


仕上げ

今回Photoshopでやったことは、最後の好みの色付けくらいです。恒星も背景もPIできちんと出してからPhotoshopに渡したので、かなり楽でした。

「sh2-136ゴースト星雲」
Image13_ABE_ABE_ABE_cut
  • 撮影日: 2022年10月25日20時2分-26日0時27分、10月26日19時17分-21日0時0分
  • 撮影場所: 富山県富山市自宅
  • 鏡筒: SHARP STAR製 SCA260(f1300mm)
  • フィルター: Baader RGB
  • 赤道儀: Celestron CGX-L
  • カメラ: ZWO ASI294MM Pro (初日分は-10℃、2日目は+9℃から11℃)
  • ガイド:  f120mmガイド鏡 + ASI290MM、PHD2によるマルチスターガイドでディザリング
  • 撮影: NINA、Gain 120、露光時間5分、L: 54枚、R: 18枚、G: 15枚、B: 12枚の計99枚で総露光時間9時間55分
  • Dark: Gain 120、露光時間5分、温度-10℃、32枚
  • Flat, Darkflat: Gain120、露光時間 L: 0.001秒、128枚、RGB: 0.01秒、128枚
  • 画像処理: PixInsight、Photoshop CC


おまけ

恒例のAnnotatonです。
Image13_ABE_ABE_ABE_cut_Annotated

あと、前以前飛騨コスモス天文台でTSA120で撮影したゴースト星雲と比較してみます。

まずは以前のもの:
TSA120

今回の画像を同じ画角で比べると、
Image13_ABE_ABE_ABE_cut_comp
自宅といえど、さすが大口径で露光時間も長いだけあります。分解能、恒星、ノイズ、いずれも大きく進歩しています。バンザイしているところもきれいに出ていますね。


まとめ

画像処理をサボっている間に、SPCCやBXTとかなり状況が進んでいました。新しいツールも躊躇せずに、どんどん取り込んでいければと思います。BXTも迷走したりしていますが、使い方によって明らかに良くなったりするので、最適な方法を探っていくほかないと思います。


このページのトップヘ