M106の再画像処理の記事を公開後、Twitter上でかなり熱い議論が交わされました。LRGB合成についてです。LRGBってもっと単純かと思っていたのですが、実際にはかなり複雑で、議論の過程でいろんなことがわかってきました。





詳しくは上の記事を見てもらえるといいのですが、今回の撮影ではRGBの露光時間がLに比べてかなり短くノイジーでした。そこで検証したのが、LRGBの際のLとRGBの比率をどうすればいいかという点です。 

M106の再画像処理のLRGB合成の過程で、Lの比率を上げると分解能は良くなっていく傾向でした。その一方、合成直後の彩度は落ちてしまいます。それでも色情報がなくなったわけではなく、たんにかくれているだけで、その後に彩度を上げていくと色が出てできます。ただし、色が出ると同時に短時間露光のせいかと思いますが、ノイジーになっていきました。

この時点でLとRGBの比率をどうすべきかわからなくなったので、LRGB合成の代わりにRGB画像をLab分解し、Lを入れ替えるという手段を取りました。この方法の利点は、RGBがノイジーな場合にabの分解能を落としてカラーノイズを減らすことが独立してできるということです。これは人間の目が色に対する分解能があまりないということを利用しています。

今回は上記のように試してみましたが、結局のところLRGBもLab変換も、まだ全然理解できていないことがよくわかりました。



その後、TwitterでNIWAさんが反応してくれて、その後botchさん、だいこもんさんも交えてかなりの議論がなされました。

と言っても私は「わからない、わからない」と吠えていただけで、基本的にはNIWAがいろんな有用な情報を提供してくれたというのが実情なので、まずはNIWAさんに感謝です。botchさんはさすが長年この界隈にいる方なので、何が問題か本質的理解されているようでした。だいこもんさんはとてもわかりやすい説明をしてくれました。



NIWAさんからの最初の有用な情報はPixInsight forumのJuanさんの発言(スレッドの#2,3,7)でした。



NIWAさんがこのページをもとに日本語でまとめてくれているので、英語が辛い場合はここを読むといいかと思います。



Juanさんの言う大事な主張は、

• RGBはリニアでやっていいが、LRGBはノンリニアで処理しなければならない。

ということです。理由は

• CIE L*a*b*とCIE L*c*h*はノンリニアカラースペースであり、それらがLRGB合成するために使われているから。

ということなのですが、最初この意味が全くわかりませんでした。そもそも私はLRGB合成はリニアのうちに処理してしまっていて、今のところ何か不具合のようなものは何ら感じていなかったからです。ここでいう「ノンリニア」というのはどうも「ストレッチ」というのと同義らしいので、このまま受け取ると

• LRGB前に全てRもGもBも、当然Lもフルストレッチしきっていなければならない。

とも受け取れます。これはかなりきつい制限で、できるなら私は早いうちに合成してしまって、まとまった画像で色と解像度のバランスを見ながら処理したいのです。しかも、上記のように理由が挙げられていますが、この意味が全くよくわかりません。



そもそも、PixInsightのLRGBCombinationが実際どんなアルゴリズムで実行されているのか、どこにも情報がありません。NIWAさんからという説明があり、LRGB合成のなかみを推測する材料などが提供されたりしましたが、やはりリニアとかノンリニアに関することを含めてブラックボックスに近い状態です。


そこでbotchさんがTwitterで

• 「ほとんどの場合で、使うRGB画像の質が相対的に悪いので、強い後処理を行うとアラがでます。そもそもLとabが一致していないので。RGB画像とそれをモノクロ化した画像を扱っているのではない点を考えてみてください。」という発言と
• 「んー、LRGBって非可逆ですよね。」という意見を言ってくれたのですが、この時点でも私はまだほとんど理解できていませんでした。

私が返した

• 「Lab変換して、L画像を置き換えてLab合成し、それをまたLab変換して元のL画像に置き換えたら、元の画像に戻ると思っていたのですが、何か間違ってますでしょうか？」に対して、
• botchさんが「Lを置き換えて、もう一度Lを置き換えるだけでなら同じです。samさんの「それをまたLab変換」と言う部分はその前にRGBになどに変換している事になるので、そうなると元には戻りません」というところで、だんだん理解できて
• 「違うLとLab合成した段階で、次にLab変換で分離したaとbには違うLの情報が混じり、最初のabとは違うものになるという理解でいいでしょうか?これが正しいなら確かに不可逆です。」と答えましたが、まだこのことがリニアな画像にLRGB合成を適用してはダメな理由には結びつきませんでした。

ここでだいこもさんがものすごくわかりやすい説明をしてくれました。

• 「リニアのRGB画像から抽出したモノクロ画像をLc、Lフィルターで撮影したリニア画像をL、と呼ぶことにする。LcはRGBをストレッチして得られているのでノンリニア画像であるというのがまず前提です。それで、フィルターの性質上LcとLは輝度が違うので、そのままLRGB合成すると色が薄くなったりして良好な色が得られません。そこで例えばLinearFitをつかって輝度をそろえる必要がでますが、それをやってLcとLをそろえるとそれぞれノンリニアとリニアなので、うまく輝度がそろわない。そのような理由で、結局はLにノンリニアなストレッチを施して、Lcとヒストグラムを一致させてからLRGB合成すると上手く行くという話になるのだと思っています。」

素晴らしい説明で、これでやっとなぜJuanさんがノンリニアと言っているかが理解できてきました。要するに

• LとLcの輝度を合わせることをノンリニアと言っているに過ぎないということです。

botchさんの最初の説明も本質的に同じことを言っているのだということがわかりました。だいこもさん、ありがとうございました。

でもこの考えも実際にはまだ不十分で、議論はさらに続き、下の「ノンリニアの本当の意味は？」でさらに明らかになります。



だいこもんさんはさらに

• 「ただし、画像依存はあってリニアなままLRGB合成しても破綻なく上手く行くこともありました。」

と述べているのですが、こちらは私の経験とよく合います。最初から輝度がそこそこあっていればリニアなままでもいいかもですが、それは特殊なケースなのかと。

では、LRGB合成をリニアでやったら現実的には何が問題になるかというと、NIWAさんが

• 「リニアでやると輝星に原色のノイズが出ることがよくあります。一番明るい部分が例えば階調なく原色で青く塗り潰されるような現象です。発生メカニズムは不明ですが『明るいLに対して対応できるRGBの組み合わせがなくて、破綻して原色になってしまった』と言うように見えます。」

と具体例を述べてくれています。さらにだいこもんさんがPIのメニューのSCRIPTS>Utilities>LinLRGBに今回の問題に対応するようなスクリプトを見つけてくれました。

• 「単純にLRGB合成すると星が破綻する画像でも、これを使ったら破綻しませんでした」とのことなので、リニアで処理してもうまくいくのかもしれません。
• 「スクリプトの中身見てみたら、カラー画像をHSI分解して、IをLと入れ替えているだけのようです。そうすると星の破綻も起きませんでした。」

とのことなので、リニアでもうまくLを入れ替えることができるのかもしれません。

リニアで色がおかしくなる事は私も前回のM106の処理中にありました。これはLがRGBより暗い部分で起こるようです。私の場合はLを少しストレッチしてRGBより明るくすると回避できました。

NIWAさんからもう一つJuanさんが発言されているスレッドの紹介がありました。ここでもあからさまにRGBはリニア、LRGBはノンリニアと言っています。



Juanさんが#5の最後で言っているのは、ここまで議論していた「入れ替えのLの輝度を合わせるストレッチをすることをノンリニアという」ということに近いかもしれません。でもまだ別の意味の気もします。

このことは次で明らかになったのかと思います。



上の疑問に関して、

• だいこもんさんの「LcはRGBをストレッチして得られているのでノンリニア画像であるというのがまず前提」という発言から、
• NIWAさんが「つまりRGBからLを取り出した時点で、ストレッチされてしまうわけですね。」

と非常に重要な発言をされています。NIWAさんが調べたところによると、そのLを取り出すときにガンマ補正が入るようで、根拠は
あと、この議論はあくまで原則論で、実際にどう運用するか、実際の画像処理に影響があるかどうかは程度問題の可能性も十分にあります。本当に正しいかどうかもさらなる検証が必要かと思います。天体写真に対する考え方は人それぞれで、科学の範囲と思ってストイックに考えている方もいれば、趣味として楽しんでいる方もいるのかと思います。たとえこの議論を読んだとしても何が正しいかは自分で判断すべきで、必要ならばこの議論も参考にしてみるというような考え方でいて頂ければありがたいです。


NIWAさんの情報初め、みなさんの議論におんぶに抱っこで、私は疑問を出しまくっているだけでした。本当に皆様に感謝です。こんなまとめをするのも越権かもしれませんが、私自身のメモという意味も兼ねていますので、どうかご容赦ください。でも、こうやってネット上で議論が進んで理解が深まるというのは、とても有意義で、とても楽しいことなのかと思います。皆様どうもありがとうございました。

タグ ：

#PixInsight

#Lab

#LRGB合成

#RGB合成

#linear

#nonlinear

先日、M106の記事をアップしましたが、記事を書き終えてから画像処理にアラがかなりあることに気づき、改めて再処理をしました。



でもこの再処理過程、苦労の連続で思ったより時間がかかりました。以下にまとめましたが、実際にはこんなにすんなりとはいっていなくて、いろんな回り道をしてある程度見通しがついたものだけを列挙しています。



問題点は以下の通りです。問題の大きさの順に、

タグ ：

#M106

#再処理

#Lab合成

#SCA260

#光条線

#赤ポチ

#Hα

#ジェット

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のページから読み取ることができます。

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

グラフから温度-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

#自宅

#開田高原

BlurXTerminator (BXT)を使った、過去画像の再処理の第3弾です。

第1弾は三日月星雲、第2弾は青い馬星雲でした。



三日月星雲は主に星雲本体、青い馬星雲は主に恒星の収差の改善でしたが、今回もすごいです。



今回のターゲットは、NGC2359: トールの兜星雲です。昨年1月に撮影しているので、1年ちょっと前になります。


SCA260で撮影していますが、この時はまだ、今使っている大型赤道儀のCGX-Lではなくて、もう一つ小さいCGEM IIに重いSCA260を載せています。そのため、今見ると3分露光でも揺れの影響が残ってしまっているようで、恒星像が今一ピシッとしていません。これがBXTでどこまで改善できるかがまずはポイントになります。



処理をしている途中で、BXTで明るい恒星が崩れる現象が見られました。

原因は、元画像の恒星自身が何か歪んでいたことで、よく見ると以前の画像でもその兆候が見られますが、気づいていませんでした。BXTでその歪みが助長されて気づくことができました。BXTといえど全然万能ではなく、元画像がダメな時はどうしようもないです。

ではその恒星の乱れはなんだったかというと、Integrationの時に起こっていて今回はrejectionにWinsorized Sgma Clippingを選んでいたことが原因でした。High側で恒星中心付近がいくつかrejectされていて、非連続になっていたというわけです。今まで気づいたことがなかったので、恒星がおかしい時はrejectionにちょっと気をつけた方がいいかもしれません。


結局、WBPPでのIntegrationのRejection algorithmをAutoにして解決したのですが、マニュアルでのPreprocdessing からのIntegrationとWBPPのIntegrationでは少し振る舞いが違うようです。マニュアル操作ではそもそもWinsorized Sgma Clippingでも（WBPPのときと同じパラメータにしても）rejectonの度合いはもっと緩やかで、問題が露呈しないレベルで抑えられます。WBPPのWinsorized Sgma Clippingのパラメータをどういじっても解決はできなかったので、諦めてAutoにしたらあっさり解決しました。

それ以外はBXT、NXT合わせて特に困ったことはありませんでした。しかも青い馬星雲の背景出しで相当な時間をかけたので、それがいい練習になっていて、今回の再処理は短時間で終わりました。



結果ですが、以前のものと比べます。まずは以前のもの。背景が暗いので、今回の再処理でもう少し淡いところが出るかもしれないという目論見です。あとはやはりSCA2660とCGEM IIの組み合わせでの揺れのせいでしょう、今見ると恒星の締まりがないのが気になります。

次に、今回再処理した結果の画像です。一皮どころか、二皮も三皮もむけた感じです。ちょっとやり過ぎの感もあります。

まず、兜本体の分解能が尋常でないです。これはひとえにBXTのおかげです。また、恒星の大きさですが、不自然でない程度にとどめておきましたが、かなりシャープに絞ることができています。微恒星もより暗いものまではっきりと出ています。


あと、背景も積極的に炙り出せました。前回の青い馬星雲で練習した成果になるでしょうか。ただ、背景についてはは自宅の明るい場所での撮影なのでこれくらいが限界です。すでにノイズの荒々しさが残ってしまっています。本当はもっと広い範囲で淡い青いところが広がっているはずなのですが、これ以上出したかったら、露光時間をさらに増やすか、もしくはもっと暗い所へ行くべきです。それでもまあ、今回の再処理でとりあえずここまで出たのでよしとしましょう。



これまで何度か試したBlurXTerminatorですが、これは天体写真の解像度向上に革命を起こすくらいのツールと言えそうです。その一方、今のAI技術はまだまだ発展途中、もしくは遠い将来から見たら出始めのかなりあやふやな技術だと評価されるかもしれないので、疑似的な画像を作り上げる可能性も否定はできません。中身がほとんどブラックボックスという心配もあります。

そうは言ってもこの素晴らしいツール、手間の軽減、時間の短縮、星像のシャープさ、分解能の向上などメリットの方が遥かに遥かに大きいです。私個人としては新しいツールにかなり寛容なので、DeNoise AIの時もそうでしたが、趣味の範囲では見た目でよさそうなら積極的に使っていきたいと思っています。DeNoiseの時もフェイクになる可能性があるという批判はありましたが、大きな目で見れば今回のBXTはそのアップグレードと考えることもでき、順当な進化なのかと思います。

AIと画像処理は研究ベースでも親和性がとてもいいようなので、今後もアマチュア天文を対象にAIを利用したソフトがさらに出てくることと思います。個人的には拒否反応など示すことなく、冷静にいいところを見つけて、積極的に使っていきたいと思っています。

タグ ：

#トールの兜星雲

#再処理

#BXT

#BlurXTerminator

#NXT

#SA260