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

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

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



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


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


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

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

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

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





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

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

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

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

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

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

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

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

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

タグ ：

#M104

#ソンブレロ銀河

#SCA260

#ASI294MMPro

#LRGB合成

#BXT

#ハッブル

#Hubble

#露光時間

#飽和

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交換せずに使い続けたのですが、色々不具合が出てきて、すぐに交換すればいいと後から後悔しました。

撮影は順調に続き、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も温度を合わせるため、こちらも全部取り直しです。
フラット撮影中にオートストレッチして、こんな風に真ん中にシミのような大きな模様ができていたら、結露しています。拡大すると、おかしな黒い点々が見えたりします。

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

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



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



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

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

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

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

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



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



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

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



あとはREADME.txtに書いてある通りに、
怖かったのは、マニュアルに「ちゃんと手順を踏んでやってもサーチでStarNetが出てこない場合は、AVXに対応してないから仕方ないとか、心を折るような記述があることです。でもM1のMacでPIの最新版で、確実にStarNet V2をインストールできたので、諦めずに正しい手順でやってみてください。



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

画像処理の結果が下のようになります。

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



2年前と今回を比較してみます。

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

今回のM27、羽の部分、中心部分の分解能、微恒星の鋭さ、背景のノイズなど、ほぼ全てを2年前の結果を上回っていて、自己記録更新です。あえていうなら、透明度みたいなのだけは以前の方が良かったように思いますが、これは画像処理に依っていて、まだ私も確信を持って(少なくとも見かけの透明度さえも)透明度をコントロールできていないので、偶然によってしまっています。それ以外はトータルとしてはかなり満足しています。



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

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

タグ ：

#M27

#亜鈴状星雲

#SCA260

#ASI294MMPro

#ナローバンド

#AOO

#Hα

#OIII

#CGX-L

#フラットムラ

一連の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です。

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

再処理では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を使うことはほとんどなくなるのかと思います。



さて、上の結果を見るとこのままの状態で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でももう少し出てもおかしくないのかと思ってしまいます。今回私の拙い技術で出せたのはこれくらいです。クロップしてあります。



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


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

見比べると、明らかに今回の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がここまで出たこと自身はある程度満足しています。でももう少し出るかと淡い期待を抱いていたことも事実です(笑)。

タグ ：

#BXT

#M51

#子持ち銀河

#再処理

#画像処理

#DenoiseAI

#SCA260

#ASI294MMPro

#LRGB

#RGB

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



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

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

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



これからする一連の議論の目的ですが、

1. 画像に存在するどのノイズが支配的かを知ること。
2. 信号がノイズと比較して、どの程度の割合で効くのかを示す。
3. 電視観望で高いゲインが有利なことを示す。

を考えてたいと思っています。今回の記事はまずは1番です。こちらはスカイノイズをどう評価するかが鍵なのかと思っています。

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

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



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

$$S/N=\frac{nt{S}_{sig}}{\sqrt{An{\sigma }^2+Ant{S}_{sky}+Ant{S}_{dark}+nt{S}_{sig}}}\propto \sqrt{n}$$
と書くことができます。ここで、

• $A$ [pix] : 開口面積
• $n$ : フレーム枚数
• $\sigma$ [e-/pix] : 読み出しノイズ
• $t$ [s] : 1フレームの積分(露光)時間
• $S_{sky}$  [e-/s/pix] : スカイバックグラウンド
• $S_{dark}$  [e-/s/pix] : 暗電流
• $S_{sig}$  [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の場合おおよそ


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


としていいでしょう。

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




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

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

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


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


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


としてしまえばいいでしょう。単位[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\left[ADU\right]{)}^2=\frac{S\left[ADU\right]}{f_c[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程度となります。

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


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


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

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



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


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



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

画像1枚あたりの背景に当たる部分の各ノイズの貢献度は多い順に

1. スカイノイズ: 15.9[e]
2. 読み出しノイズ: 1.8 [e]
3. ダークノイズ: 1.5[e]

となります。Statisticsツールで測定した実際の1枚画像の背景のノイズの実測値は14.9[e]程度だったので、上の3つのノイズがランダムだとして2乗和のルートをとると、


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

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



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


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

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


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

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

うーん、でもこんなスカイノイズが大きい状況なら

• もっと露光時間を短くして読み出しノイズを大きくしても影響ないはずだし、
• 冷却温度ももっと上げてダークノイズが大きくなっても全然いいのでは

と思ってしまいます。でもそこはちょっと冷静になって考えます。早急な結論は禁物です。次回の記事では、そこらへんのパラメータをいじったらどうなるかなどに言及してみたいと思います。



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

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

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

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


この記事の続きは



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

タグ ：

#スカイノイズ

#コンバージョンファクター

#ダークノイズ

#読み出しノイズ

#ASI294MMPro

#M81

#自宅

#開田高原