ほしぞloveログ

天体観測始めました。

カテゴリ: 画像処理

CP+のセミナー、いかがでしたでしょうか?細かい操作も多かったので、その場では少し見にくいところなどもあったかもしれません。すでに動画配信が用意されているので、わかりにくかったところは繰り返しチェックしてみてください。

 

今回の記事は、動画配信を元に、わかりにくかったところの補足をしようと思います。


処理画像の準備

セミナーの中で話した、撮影までの状況と、SharpCapでの再ライブスタックは、これまでの記事で書かれています。







今回の記事は、セミナーで示した中でも、特に画像処理の部分について補足していきたいと思います。「なぜ」この操作をするべきなのかという意味を伝えることができればと思います。

セミナーは
  1. (23:50) 入門用にMacの「プレビュー」を使って、その場で処理
  2. (27:05) 初心者用にPhotoshopを使って、その場で処理
  3. (32:40) 中級者用に「GraXpert」とPhotoshopを使って、その場で処理
  4. (41:50) 上級者用に「PixInsight」をあらかじめ使った処理の結果を流れだけ
という内容 (括弧内の時間は配信動画での位置) でした。

使用した画像は、SharpCapで1分露光で撮影したオリオン大星雲を60枚したものです。これを、上の1と2はオートストレッチしたものをPNGフォーマットで8ビットで保存されてもの、3と4はRAW画像のfitsフォーマットで16ビットで保存されたものです。

オートストレッチで保存できるのは2種類あって
  1. 「Save with Adjustments」を選ぶ、LiveStackでのオートストレッチのみかかったもの
  2. 「Save exactlly as seen」を選ぶ、LiveStackでのオートストレッチに、さらに右パネルのオートストレッチが重ねてかけられてもの
です。今回は後者の2の保存画像を元に画像処理を始めます。いかが、SharpCapで保存されたライブスタック済み、オートストレッチ済みの初期画像です。

ここでオートストレッチについては少し注意が必要で、何度か試したのですが、ホワイトバランスや輝度が必ずしも一定にならないことがわかりました。全く同じRAWファイルをスタックした場合は同じ結果になるのですが、スタック枚数が変わったり、別のファイルをスタックしたりすると、見た目に色や明るさが変わることがあります。どうも比較的暗いファイルでこれが起こるようで、ノイズの入り具合で左右されるようです。明るさはまだ自分でヒストグラムの黄色の点線を移動することで調整できるのですが、RGBのバランスは大まかにはできますが、極端に暗い画像をストレッチするときの微妙な調整はSharpCap上ではできないようです。Photoshopでは背景と星雲本体を個別に色合わせできるのでいいのですが、WindowsのフォトやMacのプレビューでは背景も星雲本体も同じように色バランスを変えてしまいます。このことを念頭においてください。


Windowsのフォトでの簡易画像処理

まず、入門用のOSに付いている簡易なアプリを使っての画像処理です。

セミナー当日はMacとWindowsの接続が不調で、SharpCapのライブスタックとWindowsのフォトでの加工をお見せすることができませんでした。手持ちの携帯Wi-FiルーターでMacからWindowsにリモートデスクトップで接続しようとしたのですが、2.4GHzの信号が飛び交い過ぎていたようで、遅すぎで使い物になりませんでした。あらかじめテストはしていたのですが、本番でこんなに変わるとは思ってませんでした。

お詫びではないですが、Windowsのフォトについては、配信動画の代わりに、ここでパラメータと結果画面を追加しておきます。画像処理前の、SharpCapのオートストレッチで保存された画像は以下のものとします。

Stack_60frames_3600s_20_34_59_WithDisplayStretch

これをWindowsのフォトで処理します。
  1. WindowsではPNGファイルをダブルクリックすると、フォトが立ち上がります。画像処理をするには、上部真ん中にあるアイコン群のうち、左端の「画像の編集」アイコンをクリックします。
  2. 上部に出てくるメニューの「調整」を押します。
  3. フォトの弱点は、背景を暗くするのがしにくいことでしょうか。今回は「コントラスト」を右に寄せることで背景を暗くします。
  4. 星雲中心部が明るくなりすぎてます。トラペジウムを残したいので「強調表示」を左にして明るい部分を暗くします。
  5. 色バランスは「暖かさ」と「濃淡」で整えます。「暖かさ」左に寄せて青を出し。「濃淡」を右に移動しバランスを整えます。
  6. 「彩度」をあげて、鮮やかにします。
setting

画面が暗い場合は「露出」を少し上げるといいかもしれません。「明るさ」は変化が大きすぎるので使いにくいです。

上のパラメータを適用すると、結果は以下のようになります。
photo

たったこれだけの画像処理でも、見栄えは大きく変わることがわかると思います。


Macのプレビューでの簡易画像処理

Macのプレビューでの画像処理過程はセミナー中に見せることができました。でも今動画を見直していたら、どうも本来処理すべき初期画像を間違えていたようです。

Windowsとの接続がうまくいかなくて、内心かなり焦っていたようで、本来は上のフォトで示した初期画像にすべきだったのですが、間違えて出してしまったのがすでに加工済みの下の画像で、これを元に画像処理を進めてしまいました。焦っていたとはいえ、これは完全に私のミスです。本当に申し訳ありませんでした。
Stack_60frames_3600s_20_34_59_WithDisplayStretch 2

ここでは、改めて本来加工するはずの下の画像で進めようと思います。フォトで使ったものと同じものです。
Stack_60frames_3600s_20_34_59_WithDisplayStretch

最終的なパラメータはこれくらいでしょうか。一つづつ説明してきます。
setting
  1. オートストレッチで星雲本体を炙り出た状態だと、星雲中心部が明るくなりすぎます。トラペジウムを残したいので「ハイライト」を下げます。
  2. 背景が明るすぎるので、上のヒストグラムの左のマークを右に動かします。星雲本体を炙り出すために、真ん中のマークを左に少し寄せます。これは後のPhotoshopの「レベル補正」に相当します。
  3. 色バランスは「色温度」と「色合い」で揃えるしかないようです。「色濃度」は左に動かすと青っぽくなります。「色合い」は右に動かすとバランスが整います。最後は画面を見ながら微調整します。
  4. 「シャープネス」を右に寄せると、細部を少し出すことができますが、今回はノイズがより目立ってしまうので、ほとんどいじっていません。

結果は以下のようになりました。
Stack_60frames_3600s_20_34_59_WithDisplayStretch
これをみると、セミナー本番中にプレビューで処理を開始したものとよく似ているかと思います。要するに、練習でプレビューで処理をしたものを間違えて開いてしまったと言うわけです。こんなことも気づかないとは、やはりその時はかなり焦っていたんですね。それでも次のPhotoshopの処理はそれに気づいて、SharpCapから直接保存されたものを処理に使っています。


Windowsのフォトも、Macのプレビューも、いじることができるパラメータはそう多くはないので、解はある程度一意に決まります。むしろパラメータは画像処理を始めるときの初期のホワイトバランスと、初期の背景の明るさに依りますでしょうか?これはSharpCapの保存時に決まるのですが、保存時に細かい調整ができないのが問題です。それでも、方針さえしっかりしていれば、パラメータに関してはここら辺しかありえないというのがわかるかと思います。繰り返して試してみるといいかと思います。


Photoshopを使った画像処理

次はPhotoshopです。こちらはできることが一気に増えるので、パラメータ決定の際に迷うかもしれません。それでも方針をしっかり立てることで、かなり絞り込むことができるはずです。

初期画像は上と同じもので、SharpCapでストレッチされたPNGファイルです。
Stack_60frames_3600s_20_34_59_WithDisplayStretch
  1. (27:10) まず、背景の色バランスの調整です。これはPhotoshopのメニューから「イメージ」「色調補正」「レベル補正」を使うと楽でしょう。RGBの各色をそれぞれ個別に調整して、まずは各色の山のピーク位置と、各色の山の幅を調整します。調整の様子は動画で確認してみてください。山の位置が揃うと、背景の色バランスがとれたことになります。
  2. (27:40) 次に動画では、同じ「レベル補正」を使って背景を暗くしています。左の三角を少し右に移動します。暗くしすぎると、後から分子雲が出にくくなるので、これはもしかしたら必要無かったかもしれません。
  3. (27:55) 次に、青を少し強調します。一般的に星雲本体の青は出にくかったりします。特に今回は光害防止フィルターでQBP IIIを使っているので、そのまま処理すると、赤でのっぺりした星雲になりがちです。「イメージ」「色調補正」「トーンカーブ」と行って、「ブルー」を選び、ここは慎重に真ん中ら辺を少しだけ上げます。トーンカーブは左の方が暗い背景に相当し、真ん中ら辺が星雲の淡いところ、右が星雲の明るいところや、恒星に相当します。
  4. ただし真ん中を上げると、せっかくバランスをとった背景も青くなってしまうので、トーンカーブの線上の左の方をクリックしてアンカーを打ち、暗い背景部分があまり変わらないようにします。アンカーの部分だけが動かなくなるので、アンカーの右の方の線を動かすと、アンカーの左側も変わってしまって背景のバランスが崩れることがあります。そんな時は、左の方にアンカーを複数打って、背景バランスが崩れないようにしてください。
  5. (28:20) 少し地味なので、彩度を上げて各色の諧調が豊かな、見栄えがする画像にします。「イメージ」「色調補正」「自然な彩度」と選びます。その中に2つ触れるパラメータがありますが、「彩度」の方はかなり大きく変わってしまうので、私は「自然な彩度」の方を触ることが多いです。
  6. 補足ですが、色を出そうとしてよくあることなのですが、彩度を単体であげるとくすんだような俗にいう「眠い」画像になります。そんな時はまずは輝度を上げるようにしてください。輝度に関しては、画面に集中してしまうと、暗い状態でもいいと思ってしまうことがよくあります。一度ネットなどで自分が一番いいと思う画像をブラウザ上で見て、そのすぐ横に今編集している画像を並べてみてください。思ったより明るさも色も出ていないことに気づくかもしれません。客観的になるのは難しいですよね。並べて比べながら、まずは一番いいと思う画像くらいになるように明るさや彩度を出してみるのがいいのかと思います。
  7. (28:40) Photoshopで便利な機能が、「フィルター」の中の「CameraRawフィルター」です。まずは「ライト」の中の「ハイライト」を下げることでトラペジウムを守ってやります。
  8. (29:10) 次に、背景に含まれる分子雲を引き出すために「ブラック」を右に振り、「シャドウ」を左に振ります。ブラックとシャドウはよく似ていますが、逆にブラックを左にシャドウを右に振ってやると、似て非なるものだとわかるでしょう。この分子雲の炙り出しは、「効果」の「明瞭度」も効き目があります。セミナーでは説明しませんでしたが、「コントラスト」も同じような効果がありますが、こちらは強すぎる感があるので、使うとしても微妙に調整します。
  9. セミナーでは説明しませんでしたが、細部は「効果」の「テクスチャ」である程度出すことができます。同時に背景のノイズや不自然な大きな構造も出すことになるので、かけすぎには注意が必要です。
  10. (29:35) ここまで分子雲をかなりあぶり出してきたことになるので、かなりノイズが目立っていると思います。Photoshopでも簡単なノイズ処理ができます。その一つが「CameraRawフィルター」の「ディテール」の「ノイズ軽減」です。ノイズの具合に応じて、50とか、最大の100とかに振ってやります。同時に「カラーノイズ」も除去してしまいましょう。カラーノイズは画像を拡大すると、RGBの細かい色違いのノイズがあるのがわかると思います。拡大しながらカラーノイズが除去されるのを確認してみるといいかと思います。
  11. (30:45) ノイズを除去すると、どうしても細部が鈍ってしまいます。これは同じところの「シャープ」を上げてある程度回避できますが、完全に戻すことはPhotoshop単体ではできないかと思います。ノイズ処理に関してはここら辺がPhotoshopの限界でしょうか。
  12. (31:15) 最後に仕上げで再びトーンカーブをいじっています。ここら辺は好みでいいと思いますが、今回はまだ青が足りないのでBのを少し上げました。派手さは赤色で決まるので、Rも少し上げます。緑は自然さを調整します。赤とか青が強くて、全体に紫っぽくて人工的な気がする場合は、Gをトーンカーブで気持ち上げると自然に見えたりします。セミナーでは説明しませんでしたが、必要ならばトーンカーブの右側にも適時アンカーを打って、明るい部分が明るすぎにならないようにします。特にせっかく撮影時に残ったトラペジウムを、明るくしすぎて消さないようにします。
Photoshop

こんなところで完成としましたが、いずれにせよここでは、背景と星雲本体を個別に色バランスをとりつつ、背景を炙り出し、コントラストを上げることが重要です。背景はそもそも暗いためにノイズが多く、分子雲を炙り出すとどうしてもノイズが目立つようになるので、何らかのノイズ処理が必要になってきます。

WindowsのフォトやMacのプレビューだけで処理したものと比べると、背景と本体のバランスがとれていて、それらしい画像になってきたのかと思います。


GraXpert

ただし、Photoshopでの処理だけだと、背景の分子雲はまだあまり見えていないですね。この淡いところを出すにはどうしたらいいでしょうか?基本は、星雲本体と背景の輝度差をなくすことです。特に、画面全体に広がるような大きな構造(「空間周波数が低い」などと言います)での輝度差をなくすことが重要です。ここでは「GraXpert」という無料のアプリを使います。WindowsにもMacにも対応しています。

GraXpertは操作がそれほど多くないので複雑ではないのですが、少しクセがあります。

1. (32:35) GraXpertにストレッチ機能があるので、今回はすでにストレッチされたPNGではなく、暗いままのRAWフォーマットのFITSファイルを使いましょう。ストレッチされてない画像なので。最初にGraXpertの「1」の「Load Image」で開くとこんなふうに真っ暗に見えるかと思います。
Stack_16bits_60frames_3600s_20_21_42_fits_nostretch

2. (33:05) GraXpertの「2」の「Stretch Options」で何か選ぶと、明るい画像になるかと思います。ここでは見やすくするために「30% Bg」を選びます。

3. (33:15) 画像の周りに黒いスジなどある場合はフラット化がうまくいきません。ライブスタックの時にディザリングなどで少しづつ画像がずれていくと、黒い筋になったりするので、まずはそれを左メニュー一番上の「Crop」の横の「+」を押して、出てきた「Crop mode on/off」を押します。黒い筋を省くように選択して、クロップして取り除きます。クロップ機能がGraXpertにあるのは、画像周辺の情報の欠落に敏感だからなのでしょうね。実際の取り除きの様子は配信動画を参考にしてください。

4. 「Saturation」は彩度のことなので、少し上げておくと後から彩度を出すのが楽になるかもしれません。今回は1.5を選びました。

5. (33:48) 「3」の「Points per row」と「Grid Tolerance」は画像によって適時調整してください。「Create Grid」を押します。目安は星雲本体が黄色の枠で選択されないくらいです。ここであまり神経質にならなくてもいいのがGraXpertのいいところでしょうか。

6. (34:00) 「Interporation Method」ですが、これは4種類ありますが、各自試してみてください。場合によって適不適があります。私はKriging>RBF>AI>Splineくらいの印象でしょうか?セミナーでは時間のかからないRBFを選びました。Methodによっては差が出る場合もありますが、ほとんど差が出ない場合もあります。

7. (34:25) しばらく待って結果が出たら、画面真ん中上の「Processed」と「Original」で比較してみるといいでしょう。その差が「Background」で見ることができます。
bg
こうやってみると、左が緑に寄っていて、右が赤に寄っていたことがわかります。

8. (35:28)できた画像をこのまま保存すると、ストレッチがかかりすぎているので、「Stretch Options」で「10% Bg」程度を再度選びます。その後「5」の「Saving」で「16bit TIFF」を選択し、「Save Stretched & Processed」を押して、ファイルを保存します。

TIFFファイルはサイズが大きくなるので、ここではTIFFファイルをjpgに変換したものを表示しておきます。
Stack_16bits_60frames_3600s_20_34_59_stretched_GraXpert

9. (36:14) 保存されたTIFFファイルをPhotoshopで開き、あとは上でPhotoshopで処理したものとほぼ同様に進めます。

10. (36:20) 今回の場合、ヒストグラムで全ての山がそろっています。GraXpertで背景のホワイトバランスも合わせてくれています。

11. (36:28) 背景が暗いのですが、中心部は明るいので、Camera RAWフィルターで、ハイライトを下げ、黒レベルを上げ、さらに露光を少し上げると、背景の分子雲がPhotoshop単体で出したものよりも、すでに黙々しているのがわかります。これがGraXpertのフラット化の効果です。

12. (37:17) あとは同様にトーンカーブで青を少し出します。

13. (37:35) GraXpertのフラット化の弊害として、色が出にくいというのがあります。彩度を少し強調するといいでしょう。

14. (38:15) Camera RAWフィルターの「ディテール」の「ノイズ軽減」でノイズが目立ちにくくなります。ここまでの完成画像を示します。

Stack_16bits_60frames_3600s_20_34_59_stretched_GraXpert_final

明らかにPhotoshop単体より、GraXpertでフラット化することにより、背景の分子雲が出たのかと思います。

よりあぶり出せたのはいいのですが、その分ノイズが目立つと思います。そのため、動画では (40:13)あたりで DeNoise AIを紹介しています。これはAIを利用したノイズ除去ツールで、非常に強力なのですが、恒星の処理が苦手で、星が崩れたりしてしまいます。今回は中心が抜けたような星になってしまいました。

これは次に話すように、星と背景を分離するなどして、背景のみに実行することでうまく使うことができますが、ここまで来ると今回の範囲を超えてくるので、参考までにノイズツールはこのようなものもあるということだけ認識しておいてください。


PixInsight

セミナーでは最後にPixInsightでの処理を紹介しましたが、これは今回の目的の範囲を超えていると思いますので、参考程度に処理したものを順に示すだけにしました。なのでここでも詳細な解説は控えておきます。というか、これを解説し出すとこの一記事では到底収まりきりません。

ポイントは
  1. (42:40) BlurXTerminatorで収差を改善し星を小さくシャープにすること
  2. (44:47) 星と背景を分離すること
でしょうか。これらはPhotoshopでの処理とは全く異なり、天体画像処理専用ソフトの強いところです。最初からここまで手を出す必要は全くないと思いますが、いつか自分の処理が不満になった時に、こんな手法もあるということくらいを頭の片隅に入れておけばいいでしょう。


比較

最後に、今回それぞれで画像処理をした
  1. Macのプレビュー
  2. Photoshotp
  3. Graxpert
  4. PixInsight
の4枚を並べて比べてみます。左上からZの字を書くように、上の1、2、3、4と配置しています。

all

Macのプレビューだと、背景と星雲本体を別々に色合わせできなかったことがよくわかります。Photoshopになると、色がある程度バランスよくなっています。分子雲のモクモクはGraXpertが一番出ているでしょうか?

セミナー当日見せるのを忘れてしまいましたが、同じ4枚を拡大したものも比較してみます。
all_magnified

Macのプレビューはノイズ処理がないので、やはりノイジーです。拡大すると、PhotoshopのみとGraXpertが入った時の違いもよくわかります。モクモクのあぶり出しと同時に、細部もでています。それでも細部はPixInsightがBXTのおかげで圧倒的でしょうか。

セミナーの最後でも言いましたが、4枚目でも情報を引き出し切ったかというと、かなりいいところまで入っていると思いますが、まだ少し余地が残っていると思います。マスクを使ったりすることで、ノイズ処理やあぶり出しをもう少し改善することはできるかと思います。


まとめ

さて、今回のセミナーと合わせての一連のブログ記事いかがだったでしょうか?電視観望から始まり、撮影に発展し、画像処理までを解説してきました。セミナー本番は少し詰め込みすぎたかもしれませんが、後の配信を前提に動作を示すことを中心としたので、よろしければ動画を繰り返し見ながら確認して頂ければと思います。皆さんの画像処理の何かのヒントになるのなら、今回のセミナーを引き受けた甲斐が十分にあるというものです。

画像処理はとても奥深いところがあり、今回示したBlurXterminatorもそうですが、まだまだ今後ソフトや技術も進化していくはずです。大切なことは、ここまで説明したことの繰り返しになるかもしれませんが、闇雲に処理を進めるのではなく、何が問題で、どうすれば解決するかの方針を立てて、手持ちの技術で実際に進めていくことかと思います。画像処理といっても、いわゆる普通の問題解決プロセスと同じですね。

今回色々な手法を示しましたが、これが唯一の方法だなんてことは口が裂けても言えませんし、正しい方法かどうかもわかりません。あくまで一例で、他の方法もそれぞれ皆さんで、試行錯誤もあるかと思いますが、いろいろ編み出して頂ければと思います。











天文ファン、カメラファンの皆様、いかがお過ごしでしょうか?いよいよCP+の時期が近づいてきましたが、

今年もサイトロンさんに講演依頼を頂き、
CP+2024で話すことになりました!

タイムテーブルなど、詳しくはこちらのCP+のオンラインプログラム一覧の2.24(SAT)のタブをご覧ください。



今年はなんと、現地であぷらなーとさんとの連続講演になります。


セミナー情報


2024年2月24日(土) 13:20-14:00

パシフィコ横浜 CP+2024
「サイトロンジャパンブース」
(オンライン配信あり)


「画像処理でオリオン大星雲の分子雲を
あぶり出してみよう」

元々、リアルタイムで星雲星団を見ることを目指して開発されてきた電視観望ですが、近年はその延長で天体写真撮影へと手を伸ばすことも盛んになっています。本来とても手間のかかかった天体写真撮影ですが、電視観望のライブスタックなどの技術をそのまま使うことで、かなり敷居の低いものになってきています。

今回の講演では撮影方法について少し紹介し、実際事前にライブスタックで撮影したオリオン大星雲を例に、セミナー会場で画像処理をしてみたいと思います。

まず最初にお見せしたいのは、星雲本体を鮮やかに出してみること。暗い中から星雲がブワッとあぶり出される様子は、天体写真をまだ扱ったことがない方には圧巻かと思います。

次は、特に初心者がつまづきやすい星雲周りの淡い分子雲をあぶり出すことです。画像に隠れている情報をいかに引き出すか、実際に操作を見せながら、なぜその操作が必要なのか、その理由をわかりやすく説明しようと思います。こちらは画像処理を始めたくらいの方から、背景までこだわった天体写真を目指そうとする方などに参考になるかと思います。

普段私はブログ記事の文章がメインで、あまり動画など 配信しないので、私自身にとっても動作そのものを見せることができる貴重な機会になりそうです。オンライン配信されるとのことなので、後日繰り返し見ることができればより理解も進むかと思います。その中で何か得て頂くものがあればと思います。

私の会場入りは前日の金曜日午後くらいからです。土曜日は講演終了後もしばらくCP+会場にいますので、私の姿を見つけた方はお気軽にお声掛けください。一応いつものネームプレーをとぶら下げておくことにします。

私のセミナーの後に、同じくサイトロンブースにて14:35から15:15まであぷらなーとさんのセミナーがあります。タイトルは「リーズナブルな天体望遠鏡で星雲撮影を楽しむ方法」とのことです。あれ?もしかして少し内容が被るかな?とも思いましたが、独自路線のあぷらなーとさんなので、そんな心配は杞憂ですね (笑)。


現地パシフィコ横浜会場にいらっしゃる方は、来場登録をお忘れなく。
 


前前々回の記事でクワガタ星雲のSAO合成をしました。



せっかくなのでいつものようにAOO合成もするのですが、普通にAOO合成をするとHαの淡い構造とかが一切出てきません。これが不満で、色々試してみました。


Hαの情報量

AOO合成をして、オートストレッチすると大体これくらいです。
Image21s

きちんとクワガタの形が出ています。でも、Hαだけの画像を見るとまだまだ模様がいっぱい残っているんです。

Hα画像を強オートストレッチしてみます。
FILTER_A_mono_drizzle_2x_integration_ABE1_ABE2_ABE4s
すごい模様が出てきます。一番暗いところが背景だとしたら、多少なりとも明るいところはなんらかのHα成分が存在していると考えていいでしょう。普通にAOO合成した画像に、このHαの模様が活かされ切っているとはさすがに言い難いのかと思います。今回はこれをどこまで表現できるかやってみたいと思います。


まずはどこまで出そうか、テスト

まずAOO合成させたものを、強オートストレッチして、さらに微調整します。
Image21_strongs
ここらへんまで出せたらHαを使い切っていると言えそうですが、いくつか問題点があります。
  1. 右真ん中に大きな黒い窪みがある。
  2. 赤がサチりかけているところがある。
  3. 星がうるさい。
くらいでしょうか。一つづつ片付けます。


1. フラット化の大切さ

まず1の黒い窪みですが、普通にAOO合成したら対して問題にならないのですが、淡いところを頑張って出そうとすると目立ってしまいます。これはOIII画像に残っていた、ε130Dの迷光の残りのようです。今回は撮影時に鏡筒にフードもつけていますし、もちろんフラット補正もしています。それでも強あぶりで、これくらいのフラットの誤差が出てくるようです。ここまででもHα、OIII共にABEの1次と2次と4次をかけていますが、さらにOIIIにDBEをかけて窪みをとることにしました。その結果が以下になります。
Image24_strongs
窪みは目立たなくなり、さらにもう少し炙り出すことができるようになりました。

しかしながら窪みが目立たなくなったことで、今度は右上に注目すると、赤が構造なしでのっぺりしている気がします。本当にHα成分があるのか、カブリなのか見極めが難しいところです。仮にカブリだとすると、ここだけをうまく取り除くのは結構難しそうです。

今回は、ABEの2次を再度かけ、右上と、左下の赤も少し緩和するようにしました。もっとはっきり除いてもいいのですが、そもそもここら辺の領域を強度に炙り出しいる参考画像がほとんどなく、何が正解かよくわかりません。これ以上やると恣意的な操作になると判断し、今回はそのままで残しました。
Image24_ABE1s
こういったカブリ問題は、将来PixInsightのMARSプロジェクトがうまくいったら解決するのかもしれません。



情報を余すところなく引き出して炙り出す場合、上の操作のように「正しい背景にするというよりは、あぶり出しやすいように、できる限りあらかじめフラット化させておく」方向になるのかと思い思います。そのため、フィルターやセンサー面についているゴミはうまくフラット補正で除けないと、強あぶり出しの際にとんでもなく目立ってしまったり、周辺減光や迷光もフラット処理がうまくいかないと、そこの輝度差で制限されてしまって炙り出しが十分できないなど、致命的になる可能性があります。

先日の記事のように
最近はソフトの力でかなりの補正が効くようになってきていますが、BXTは分解能は出せても淡いものを出すことにはほとんど助けになりません。ソフトで補正が効かないこともたくさんあり、今回のように淡い構造を引き出し切ろうとすると、光学機器の段階での丁寧な汚れの除去や迷光処理、確実なフラット補正がとても大切だと言うことも肝に銘じておきたいものです。

次に、SPCCでナローバンドを選び、AOOの正しい波長と、手持ちのフィルターの波長幅を入力します。重要なことは、ニュートラルバックグラウンドをどこにするかです。プレビューで一番暗いところを選択して「Region of interest」に設定しておいた方がいいでしょう。これをしないと、赤が再び出にくくなったり、暗いところが緑がかったりしてしまいます。RGB画像を別撮りなどしていない場合は「Oprimize for stars」にチェックを入れておくと、星の色を優先的に最適化するとなっていますが、試したところ少なくとも今回は大きな違いはわかりませんでした。SPCCがうまくいくと、赤がかなり残った状態で色バランスが取れるようになります。


2. 恒星にはBXT

次に2の星がうるさいことですが、やり方は色々あると思います。今回は簡単にBXTを使ってしまいましょう。恒星も併せて十分にあぶり出しても、恒星自身が小さければ、全体を見た時のうるささは緩和されるはずです。今回はHαの淡いところを画面全体で見せたいので、トリミングやバブル星雲のところのみを拡大することなどは考えていないです。そのためSAO合成の時よりもBXTの効果は緩和させて
  • Sharpen Stars: 0.25, Adjust Star Halos: -0.30, Automatic PSF: on, Sharpen Nonsteller: 1.00
としました。


3. ストレッチは迷うところ

最後に3のサチり気味(=飽和気味)の赤をどう扱うかです。ストレッチをいかにうまくするかと言う問題です。

既に赤は色が十分出ているので、ArcsinhStretchは色が濃くなりで使えませんでした。意外なのがMaskedStretchが本来マスクで、本来はきちんとサチるのを保護してくれるはずなのに、赤のサチりを強調してしまい使えなかったことです。結局ここでは、HistgramTransformationで恒星が飽和しない範囲で軽くストレッチして、ここでStarNet2で恒星と背景を分離し、その後背景のみ必要なところまで強調しました。その後、私の場合はPhotoshopに引き渡して最終調整します。


仕上げ

最後のPhotoshopは個人の好みによるところも大きいでしょう。今回は赤の淡いところを残します。OIIIの青を少し持ち上げて色調を少しでも豊かに見せるのは、いつもの手段です。赤ももう少しいじって、強弱をつけたりします。それでも色相(RGBをそれぞれどれだけストレッチするかと、各色のブラックポイント)自体はSPCCで決めたので、それ以上は触っていません。

結果です。
Image24_ABE1_SPCC_BXTSS025_HT2_s_cut

元がHαとOIIIの高々2色なので、前回のSAOと比べてもどうしても赤でのっぺりしてしまうのは避けられません。実はAOOにする前に、なんとかSIIを使えないか、いろいろ比率を変えて試しました。複雑な比率にして、そこそこよさそうな候補はいくつかあったのですが、結局AOOのシンプルさを崩すほどいい配色は見つからず、結局今回はSIIは使わずじまいです。いつかHαとOIIIとSIIまで使った擬似RGB配色で自然に見える組み合わせが見つかるといいですが、少なくともAOOを凌駕するものでないとダメだと思うので、そんなに簡単ではないと思います。

今回のHαを余すことなく引き出すAOOですが、懸念事項の一つは画面全体が赤に寄ってしまう印象を受けることです。でも赤にのみ構造がある限り、そこを出そうとすると赤を底上げする以外に今の所いい方法を思いつきません。アメペリも同じように処理をしていて、こちらも背景が赤いですが、それでも暗いところは存在していて、それ以上明るいHαが全面近くに渡り散らばっています。

今回、やっとこのAOO手法を言語化して記事にしたことになります。他に、全体をもう少しニュートラルに寄せて、Hαにふくまれる淡い構造もきちんと強調できる方法を探していきたいと思います。


まとめ

前回の記事で年末の挨拶をしてしまったのですが、今回の記事が本当の2023年最後の記事になります。 年が明けてからのんびりまとめようと思ったのですが、大晦日に少し時間があったので、まとめてしまいました。

クワガタ星雲をとおしてSAOとAOOの議論を少ししたことになります。でもまだ十分かというとそうでもなく、SAOの色がまだハッブルパレットと違う気もしますし、AOOは全画面真っ赤問題をなんとかしたいです。所詮人工的な色付けになるので、多少色相とかいじってもいい気もするのですが、今のところはまだ躊躇しています。理由は再現性がなさそうなところです。複雑になりすぎないというのも重要かと思います。何かいい方法はないのか?今後も探していくことになるでしょう。またいい方法があったら記事にします。


日記

最近はブログ記事を休日のガストのモーニングで書くことが多いです。以前はコメダのモーニングのみでしたが、最近はガストと半々か、ガストの方が多いくらいです。ガストのドリンクバーが飲み放題でいいのと、最近はマヨコーンピザが安くて美味しいからです。多分田舎のガストなので、朝はガラ空きで、混んでくるランチタイムくらいまでは長居も可能なので、とても居心地がいいです。同じようにPCを広げている常連さんも何人かいます。この記事も最後の仕上げを大晦日にガストで書いています。

これから実家の名古屋に向かいます。元旦は実家で、おせちをつまみながらのんびり過ごす予定です。残念ながら新年2日の北陸スタバ密会は中止になってしまいました。時間が少しできるので、またノイズ計算の方を進めたいと思っています。


連休中にε130Dのテスト撮影をしているのですが、その画像処理の過程で面白いことがわかりました。このネタだけで長くなりそうなので、先に記事にしておきます。


最初に出てきたε130Dの分解能にビックリ!

今回ε130Dで初の撮影を進めています。満月直前で明るいので、ナローバンド撮影です。初めての機材なので色々トラブルもありますが、それらのことはまた次の記事以降で書くつもりです。とりあえず2日かけてなんとか約2時間半分のHα画像を撮影しました。細かく言うと、ASI6200MM Proのbin1で1時間ぶん、かなり暗かったのでその後bin2で2時間半分撮影しました。

その後、まだ仮処理段階のbin2のHα画像を見てびっくりしました。bin2撮影の2時間半ぶんをインテグレートして、BlurXTerminator(BXT)をかけて、オートストレッチしただけですが、なぜかわからないレベルのすごい分解能が出ています。下の画像はペリカン星雲の頭の部分を拡大して切り出しています。

BIN_2_4784x3194_EXPOSURE_300_00s_FILTER_A_ABE_Preview01

昔FS-60CBとEOS 6Dで撮ったものとは雲泥の差です。
283e6bd1_cut

分解能の理由の一つ

ちょっとビックリしたのでTwitterに速報で流してみたのですが、かなりの反響でした。分解能がいいと言われているε130DにモノクロCMOSカメラなので、ある程度分解能は出ると予想していましたが、予想以上のちょっとした魔法クラスです。

その後、画像処理がてらいろいろ検証を進めていたのですが、魔法の原因の一つは少なくとも判明しました。ちょっと面白いので検証過程を紹介しつつ、謎を解いていきます。


意図せずして高解像度に...

まず、今回大きなミスをやらかしたことです。テスト撮影ではbin1とbin2の2種類を撮ったのですが、それらの画像をPixInsightで同時に処理していました。2種類のマスターライト画像が出来上がるわけですが、ここで問題が起きていたことに後に気づきました。

reference画像をオートで選択していたのですが、そこにbin1のものが自動で選択されてしまっていた
のです。その結果、bin2の低解像度のものもregistration時に強制的にbin1のものに合わせられてしまい、高解像度になってしまっていました。その状態に気づかずにBXTをかけてしまい、予期せずして恐ろしい分解能の画像になっていたというわけです。

その後、気を取り直し再度普通のbin2画像を処理して比較してみると、いろいろ面白いことに気づきました。メモがわりに書いておきます。


1. BXTのPFSの値と解像度の関係

まず、BXTのパラメータですが、恒星の縮小とハロの処理は共に0としてしないようにしました。背景の青雲部の詳細を出すために、PSFを7.0にしてSharpen Nonstellerを9.0にします。

これをbin1画像に適用してみます。この中の一部をカットしたのが以下です。最初の画像と同じものです。少し出しすぎなくらいのパラメーターですが、まあ許容範囲かと思います。

BIN_2_4784x3194_EXPOSURE_300_00s_FILTER_A_ABE_Preview01

これをそのまま同じBXTのパラメーターでbin2画像に適用してみます。明らかに処理しすぎでおかしなことになっています。許容範囲外です。
bi2_bad_BXT_BIN_2_4784x3194_300_00s_FILTER_A_Preview01

次に、bin2画像は解像度が半分になっていることを考慮し、PSFを7.0から3.5にします。するとbin1でPSF7.0で処理した程度になります。これをbin2画像に適用します。

bin2_good_BXT_BIN_2_4784x3194_300_00s_FILTER_A_Preview011

bin1にPSF7.0で適用したのと同じくらいの効果になりました。これでbin1とbin2に対するBXTの効果が直接比較ができるようになったと考えることができます。

このことはまあ、当たり前と言えば当たり前なのですが、BXTのPSFは解像度に応じて適時調整すべきという教訓です。もちろんオートでPSFを決めてしまってもいいのですが、オートPSFはいまいち効きが悪いのも事実で、背景の出具合を調整したい場合はマニュアルで数値を入れた方が効果がよく出たりします。


2. referenceで解像度が倍になったのと、drizzleで2倍したものの比較

referenceで解像度が倍になったのと、drizzleで2倍したものの比較をしてみました。これはほとんど違いが分かりませんでした。下の画像の左がreferenceで解像度が倍になったもの、右がdrizzleで2倍にしたものです。かなり拡大してますが、顕著な差はないように見えます。
comp1

これにBXTをかけた場合も、ほとんど違いが分かりませんでした。同じく、左がreferenceで解像度が倍になったもの、右がdrizzleで2倍にしたものです。
comp2

この結果から、わざわざbin1を撮影してフィットとかしなくても、bin2でdrizzleしてしまえば同様の分解能が得られることがわかります。


drizzleで2倍にしてBXTをかけた場合

次に、bin2で撮影したものと、bin2で撮影したものをdrizzleで2倍にした場合を比べてみます。左がbin2で撮影したもので、右がbin2をdrizzleで解像度を2倍にしたものになります。左のbin2の拡大はPhotoshopで細部を残しすようにして2倍にしましたが、やはり一部再現できてないところもあるので、もと画像を左上に残しておきました。
comp1b

それでもちょっとわかりにくいので、PCの画面に出したものをスマホで撮影しました。こちらの方がわかりやすいと思います。左がbin2で撮影したもので、右がbin2をdrizzleで2倍にしたものです。(わかりにくい場合はクリックして拡大してみてください。はっきりわかるはずです。)
658E3BF1-9F61-4E65-BAE0-340184B9DC67

ぱっと見でわかる効果が微恒星が滑らかになることです。ですが、背景に関してはそこまで目に見えた改善はなさそうに見えます。

ところが、これにBXTをかけた場合、結果は一変します。明らかに2倍drizzleの方が背景も含めて分解能が上がっているように見えます。(と書きたかったのですが、どうも画像を2倍に大きくするときにやはり補正が入ってよく見えすぎてしまい、右とあまり変わらなく見えます。ここら辺がブログでお伝えできる限界でしょうか。実際には左上の小さな画像と、右の画像を比べるのが一番よくわかります。)
comp2b

同じくわかりにくいので、これもPCの画面に出したものをスマホで撮影しました。左がbin2で撮影したもので、右がbin2をdrizzleで2倍にしたものに、それぞれBXTかけています。
27718827-C94A-4A1D-B101-0A9F619FC62F

この右のものは、最初に示したbin1画像を参照してしまって予期せずして解像度が倍になった場合の結果とほぼ等しいです。

どうやら「BXTは画像の解像度を上げてから適用すると、背景の分解能を目に見えてあげることができる」ということがわかります。解像度を上げたことで情報をストックする余裕が増えるため、BXTで処理した結果をいかんなく適用保存できると言ったところでしょうか。言い換えると、BXTが普通に出す結果はまだ表現しきれない情報が残っているのかもしれません。これが本当なら、ちょっと面白いです。


分解能が増したように見える画像を、解像度2分の1にしたらどうなるか

では、解像度増しでBXTで分解能が増したように見える画像を、再度解像度を半分にして元のように戻した場合どうなるのでしょうか?比較してみます。左が1で得た「bin2にBXTをPSF3.5で適用した画像」、右が「一旦解像度を増してBXTをかけ再度解像度を落とした画像」です。

comp2c

結果を見ると、そこまで変化ないように見えます。ということは、解像度自身でBXTが出せる分解能は制限されてしまっているということです。

ここまでのことが本当なら、BXTの能力を引き出すには、drizzleで画像自身の解像度を上げてからかけたほうがより効果的ということが言えそうです。


まとめ

以上の結果をまとめると、
  • drizzleは適用した方が少なくとも微恒星に関しては得をする。
  • BXTと合わせると背景でも明らかに得をする。
  • drizzleして分解能を上げるとBXTの効果をより引き出すことができる。

ただしこのdrizzle-BXT、拡大しないとわからないような効果なことも確かで、そもそもこんな広角の画像で無駄な分解能を出して意味があるのかというツッコミも多々あるかと思います。それでも系外銀河など小さな天体にはdrizzle-BXTは恩恵がある気がします。まあ取らぬ狸の皮算用なので、小さな天体で実際に検証してから評価するべきかと思います。

今回の効果はおそらく意図したものではないと思いますが、BXT ある意味すごいポテンシャルかと思います。ここまで明らかに効果があると思うと、過去画像もdrizzleしてもう少しいじりたくなります。

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


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




M106での画像処理

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

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

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

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


Twitterでの議論

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

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


PixInsight forumの解説、でもよくわからない

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


ノンリニアとはLの輝度合わせ?

そもそも、PixInsightのLRGBCombinationが実際どんなアルゴリズムで実行されているのか、どこにも情報がありません。NIWAさんから
  • パラメータ調整無しの場合、LRGBCombinationとChannel CombinationのLabのL入れ替えは同じ。
  • RGBからのL画像とL画像を50%ずつブレンドしたLによるLRGBCombinationと、Weights 0.5のLRGBCombinationは同じ。
という説明があり、LRGB合成のなかみを推測する材料などが提供されたりしましたが、やはりリニアとかノンリニアに関することを含めてブラックボックスに近い状態です。

その後、Juanさんの発言の#11を読み込んでいくと、luminance transfer functionとchannel weightsが何を意味するのか、少しわかってきました。本来は適用するLと、適用されるRGB画像のLが同じ輝度とバックグラウンドというのを前提としているようです。

そこで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合成しても破綻なく上手く行くこともありました。
と述べているのですが、こちらは私の経験とよく合います。最初から輝度がそこそこあっていればリニアなままでもいいかもですが、それは特殊なケースなのかと。

では、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を取り出すときにガンマ補正が入るようで、根拠は
だとのことです。要するに、
  • リニアなRGB画像だったとしても、そこからLを引き出しただけでノンリニアなL画像になってしまう
というのが本質のようであり、ある意味今回の結論になります。


まとめてみると

これまでの議論が正しいなら、
  1. RGB合成まではリニアなのでストレッチなどする必要はないが、LRGB合成はノンリニアになる。
  2. 具体的はRGBからLを引き出す際にノンリニア処理になるので、それ以降はリニアな処理はしない方がいいということが重要。
  3. 言い換えると、R、G、Bに関しては事前にストレッチしておく必要はない
  4. LRGB合成する際のL画像も事前に必ずしもストレッチしておく必要はないが、RGBから引き出したL画像と同じ輝度レベルにした方がいい。例えばL画像がリニアなままでは恒星の色が破綻することがある。
  5. LinLRGBなどでHSI分解してIとLを入れ替えると破綻しにくくなる(要検証)。
ということが、ある程度のまとめとして言えるのかと思います。

個人的に重要視したかった「ストレッチのタイミング」ですが、少なくとのR、G、Bに関してはストレッチは合成後でいいことがわかったので、最初に言っていた「LRGB合成前に全てRもGもBも、当然Lもフルストレッチしきっていなければならない」というかなりきつい制限は相当緩和されるという結論になったかと思います。

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

今回はLabのノンリニア性とか、まったく意識していなかったことがたくさんありました。まだまだ学ぶことが多いです。NIWAさんが参考ページを教えてくれました。

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


このページのトップヘ