ほしぞloveログ

天体観測始めました。

カテゴリ:software > Pixinsight

前回記事でSWAgTiのディザー撮影ができたことを書きましたが、書ききれなかったこともあるので、少し補足します。


機材

鏡筒ですが、最近手に入れた新機材でRedCat51です。と言っても新品ではなく、譲り受けたもので、IIでもIIIでもなく初代です。

富山県天文学会のK会長が4月に逝去されました。2016年の5月、星を始めたときに牛岳で誘われて入会して以来、折につけお世話になっていました。会内では最もアクティブな方で、とにかく天気さえ良ければいろんなところに顔を出して星を見てた方です。星や宇宙の解説が大好きで、普通に来てた一般の人にも、いつも分かりやすく説明されていました。昨年末くらいからでしょうか、急に痩せられて、体調を悪くされているようでしたが、3月の役員会には顔を出されていたのに、まだ60代半ばで、あまりに早すぎるお別れでした。熱心な方だったので、当然大量の天文機器があるのですが、遺族の方のご好意で、できれば皆さんで使ってくれないかということで、私はRedCat51とEOS 6Dを格安で譲っていただくことになりました。ちなみにK会長、6Dがよほど気に入っていたのか、3−4台もあって、私はその中であえて1台だけあった無改造機を選びました。私が持っている一眼レフカメラは全て天体改造をしてあるもので、ノーマル機を一台も持っていなくて、普通の景色も少しは撮ってみたいと思っていたので、実はとてもありがたかったのです。

IMG_9796

撮影用のコンパクト鏡筒としてはこれまで主にFS-60CBを使っていましたが、赤ハロ青ハロ問題を避けたいというのがありました。これはFS-60CB特有の問題で、ピント位置が赤と青で微妙にずれていて、赤か青のどちらかのハロがどうしても出てしまうというものです。ジャスピンが難しく、赤と青を均等になるように合わせたりしてきました。また、FS-60CBにレデューサをつけると焦点距離が250mm程度になるのですが、周辺星像がすこし流れるのも気になっていたこともあり、250mm程度の短焦点で性能の良い鏡筒を狙っていました。実は最近はBXTがあるので、これらのFS-60CBの欠点はソフト的にかなり解決できますが、やはり撮影時に解決したいという思いがあります。

RedCat51を使ってみて驚いたのは、周辺減光の少なさです。今回使ったカメラがUranus-C Proでセンサーサイズが1/1.2インチと決して大きくはないのですが、オートストレッチで強あぶり出ししてもほとんど周辺減光が確認できませんでした。なので、簡単撮影という目的も考えて、今回あえてフラット補正をしませんでした。さらにいうと、PixInsight上でもなんのフラット化もしていません。普通は周辺減光とかあると、輝度差で淡い部分のあぶり出しがうまくいかないはずです。でも今回はフラット補正も、ABEも、DBEも、GCも、本当に何もしていないのですが、きちんとM27の羽まで見えるくらい問題なく炙り出しができています。これは今までにない経験で、RedCat51の性能の高さの一端を見た気がしました。

前回記事でも見せましたが、改めて何のフラット補正もしていない、WBPP直後の画像を載せておきます。M27の周りを広い範囲で撮っているのってあまり見当たらないので、本当は背景の構造を出したかったのですが、今回の2時間では全然ノイジーです。でももうSWAgTiで長時間露光も楽にできるので、天気がいい時に放置で10時間とか露光しても面白いと思います。
masterLight_BIN-1_3856x2180_EXPOSURE-180.00s_FILTER-NoFilter_RGB

カメラですが、M27は結構小さいので、センサー面積が小さく、夏場なので冷却ができるものというので、PlayerOneのUranus-C Proを使いました。CP+で使わせてもらったカメラです。PlayerOne社のカメラの特徴の一つ「DPS」も魅力で、これでホットピクセルはかなり軽減されるはずです。実は今回、ダーク補正を全くしていません。PixInsightのCosmetic Correctionのみ使いました。それでホットピクセルやクールピクセルは全く問題にならないレベルになったので、お気楽撮影にふさわしいカメラだと思います。

IMG_8960


iHDRがすごい!

今回初めて使いましたが、PixInsightのストレッチの中でも比較的新しい「iHDR」がすごいです。M27の星雲本体とその周りの淡い羽の部分には相当な輝度差があり、普通のストレッチでは両方を同時にうまく出すことができません。そのため、一般的にはマスク処理が必要となるのですが、今回は部分的なマスクを使うことなく、ほぼ自動で輝度差が出ないようにストレッチすることができました。

iHDRの説明についてはこちらをご覧ください。
 

インストールは

https://uridarom.com/pixinsight/scripts/iHDR/

をレポジトリに登録して、アップデートをチェックするだけです。インストールされたiHDRはメニューの「Scripts」の「Sketchpad」の中に入っています。

パラメータですが、iHDRでMaskStrengthを倍の2.5にしてより明るい部分を抑え、Iterationを3にしだけで、あとはデフォルトにしました。中心の明るい部分を十分に抑えることができました。
  1. まず、背景が何回くらいIterationすれば適した明るさになるか、何度か繰り返して試してから確定します。
  2. 星雲本体の輝度差がまだ残るようならMaskStrengthの値を増やして、これも何度か調整してみます。
一度試すたびに、Undoで元に戻してから再度パラメータを変えて試し、値を確定していくと楽かと思います。その際、Undoは一度で元に戻らないことがあるので、Undoアイコンのところにカーソルを持っていって、ちょっと待って、何の作業を戻すのか表示されるのを確認すると良いと思います。これがPixelMathと表示されるうちは、まだUndoしきれていないです。

iHDRの後は、NXTでノイズを軽く落として、StarNet++で恒星と背景を分離して、最後Photoshopに渡して仕上げますが、ストレッチまでかなり仕上がりに近い形で済んでいるので、Photoshopでは軽く好みに処理するだけで済みました。


SPCC

もう一つ、PixInsightでの色合わせツールのSPCCを少し使い込んでみました。実際にはWBPPでスタック後にすぐに試したことです。

今回は光害防止フィルターとして、サイトロンのDual Band Pass (DBP) フィルターを使いました。これまではSPCCのナローバンドモードを使って適当な波長幅を指定していましたが、いい機会なのでフィルターをきちんと設定することにしました。参考にさせて頂いたのはだいこもんさんのこのページです。
 

同ページにだいこもんさん自身が作ってくれたフィルター用ファイルが紹介されていて、その中にDBPのファイルもあったので、それを使わせて頂きました。フィルターを設定して公開してくれているだいこもんさんと、さらにオリジナルのJason Coonさんに感謝です。

だいこもんさんによると、カメラがASI294MCの場合はSonyのCMOSの標準フィルターでいいとのことでしたが、Uranus-Cで使っているIMX585は特に赤外の感度が高く、標準の応答とは少し違っています。いい経験になると思い、ついでにIMX585用のカラーフィルターを作ってみました。

実際自分でフィルターデータを作ってみるとわかりますが、cvsファイルの1箇所に波長情報を全て入れるとか、透過率も1箇所にいれるとか、結構面倒です。また、メーカーのグラフから値を読み取るのですが、読み取りソフトはだいこもんさんお勧めのPlotDigitizerを使いました。面倒だったのは、赤外の領域ではRGBの線が重なっていて、グラフで一番上の色(この場合青でした)しか読み取ることができず、後から赤と緑に同じ波長の青の線を近似的に追加するなど、少し加工が必要だったことです。

IMX585_R
IMX585のR曲線ですが、長波長側は青線と重なっていて直接読めないので、
青線から起こしています。


自分で作ってIMX585とDBPの応答を合わせて、今回の撮影に合わせた応答を作りましたが、結局2つのグラフを合わせると、ただの一本線になってしまうので、IMX585のデータを作った意味があるかどうかはちょっと疑問です。でも面白いのは、例えば下のBグラフでは、長波長の赤の領域にも線があるんですよね。
DBP_IMX585_B2

これはIMX585がRGBともに長波長に感度があるからです。だからBもGも実は赤を少し含みます。どれくらいの割合かというと、B曲線ではBが0.44に対してRが0.07と16%程度、G曲線ではGが0.78に対してRが0.17と22%程度と、無視できないくらいの結構な割合で含まれることになります。カラーカメラとDBPはモノクロカメラで撮ったAOO相当になると思うのですが、DBPでは赤と青でのっぺりせずに多少なりとも色調が豊かに見えるのは、この余分な色の成分のせいなのかもしれません。ちなみに、R曲線にもGがすこしまざりますが、Rが0.96に対してGが0.03とごく僅かなので、こちらはあまり効いてこないでしょう。

上の重ねたグラフを使い、SPCCで測定した結果を見ると見事に直線に載ったので、ちょっと嬉しかったです。

SPCC

でもSPCCのフィルター制作は完全に蛇足で、SWAgTiの簡単撮影のためにはこんなことまでやる必要は全くないと思います。


SWAgTiについて

SWAgTiを改めて振り返ってみます。

高精度追尾で1軸単機能のSWATに、低精度でも2軸で高機能のAZ-GTiを組み合わせることで、SWATがまるで高精度高機能赤道儀のように生まれ変わります。実際、SWAT350のピリオディックエラーはPremium仕様で+/-2.8秒を実測して出荷しているそうです。これだけの精度を有している赤道儀はポータブル型ではほぼ皆無で、大型の高級機と比較しても何ら遜色ない素晴らしい値なので、ガイドなしでの簡単撮影が生きてきます。

AZ-GTiを赤道儀化される方も多いかと思いますが、その際の極軸を北極星方向に向ける35度の角度をつける台座に苦労します。揺れてしまわないためにも、台座の強度も重要になります。SWATには底面に角度がつけてある、SWAT自身が強固な35度の台座を兼ねることができます。

AZ-GTiは、自動導入、プレートソルブ、エンコーダー内蔵など、値段から考えたら非常に高機能で汎用性が高く、ユーザーも多いため情報に困ることはまずないと思います。プレートソルブだけは今回ディザーと併用できませんでしたが、元々できていたことなので単なるバグの可能性が高く、いずれ解決するものと思っています。AZ-GTiは精度があまりないと言っても、モーターさえ動かさなければその強固な筐体と合わせて、極めて安定しています。追尾中はSWATのみが動き、AZ-GTiのモーターは動かないので、撮影時の精度はSWATのみで決まります。AZ-GTiのモーターが動くのは、導入時や、撮影の合間のディザーの時のみです。

PCとAZ-GTiとの接続はワイヤレスなので、ケーブルの数も一本減らせています。それでも少なくとも今回の2時間は全く接続が落ちることなどなく、安定でした。なのでケーブルの数は、PCとCMOSカメラを繋ぐUSB3.0ケーブル、CMOSカメラの冷却電源ケーブル、SWATの電源ケーブルの3本です。PCは内臓バッテリー駆動です。ダーク補正しないなら、特に冬場なら、冷却カメラでなくてもいい気もするので、冷却用の電源ケーブルは減らせるかもしれません。SWATも乾電池駆動が可能なので、SWATの背中側に電池をおいてしまえばさらに長いケーブルの数を減らせます。AZ-GTiも私は電池駆動にしています。こう考えると、最小構成ではPCとカメラを繋ぐUSBケーブル一本で稼働可能かもしれません。あ、StickPCを使えばさらにUSBケーブルも短くできるので、超シンプルになるかもしれません。こうなってくるとASIAirみたいですね。どこまでシンプル化ができるか、ちょっとやってみたくなってきました。

重量に関しても少しコメントを書いておきます。SWATもAZ-GTiもそこそこの重さはあるので、二つ合わせると決して軽量とは言い難くなります。一般的な小型赤道儀程度の重量と言っていいでしょうか。それでも十分に軽くてコンパクトなので、私は鏡筒を取り付けたまま運んでいます。玄関においてあるのですが、そのままなんの組み外しも組み立てもなしで運べるのはかなり便利です。超高精度と考えると、最軽量クラスの赤道儀と言ってもいいのかと思います。

逆に、今のところの欠点ですが、SharpCapでの極軸調整を三脚をずらすことでやっているので、ちょっとテクが必要です。微動雲台を使ったほうがいいのかもしれません。ただ、微動雲台は双刃の剣で、揺れを導入するかのうせいがあるので、以前テストさせていただいた迷人会の微動雲台クラスのものが欲しいレベルかと思います。

プレートソルブが使えなかったのはかなり痛いです。でもこれはソフト的な問題のはずなので、いずれ解決するでしょう。短期的にも、何か回避策がないか少し試したいと思います。


まとめ

アイデアが出たのが去年の6月、星まつりでデモなどしましたが、今回ディザーができ縞ノイズが解決して、ある程度のキリがついたと思います。1年以上にわたるテストでしたが、(プレートソルブを除いて)何とか形になりましたでしょうか。今後は鏡筒やカメラを変えて、実用で使っていきたいと思っています。

そうそう、Unitecさんにディザーが成功したことを伝えたら「諦めないところがすごいです」と言われてしまいました。結構嬉しかったです。その経緯でUnitecさんのページでもSWAgTiがまた紹介されてます。

今週末の胎内はちょっと時間的に厳しそうなので、参加は見送ることになりそうですが、9月15日の京都の「星をもとめて」でUnitecさんのブースでまたSWAgTiをお披露目できるかと思います。その際は、お気軽にお声掛けください。


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


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




前回は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も迷走したりしていますが、使い方によって明らかに良くなったりするので、最適な方法を探っていくほかないと思います。


今回はケフェウス座のSh2-136: ゴースト星雲です。撮影したのはもう結構前で、10月終わり頃になります。

前後関係で言うと、自宅でSCA260で撮影したアイリス星雲とセットで撮影したもので、その意味ではもっと早く処理していても良かったものです。


現実的には撮影後に、小海の星フェスや皆既月食など、他にも色々忙しくてなかなか取り掛かることができなかったという理由もあります。最近のBlurXTerminatorが結構凄そうなので、少し試してみたくなり、時間の取れる年末年始に画像処理を進めてみました。


R画像?

撮影は10月25日の夜と、26日の夜の二日に渡っています。アイリス星雲を撮影していたセットアップのままなので、特に何か変更するでもなかったです。

画像処理を進めていくと、なぜかR画像のみ右上に変なスジが残りました。
masterLight_BIN-2_4144x2822_EXPOSURE-300.00s_FILTER-R_mono

最初は単にアンプグローの残りかと思ったのですが、そうだとすると2つ奇妙なことがあります。一つはGとBにこんなスジは全く出ていないこと、もう一つはダークフレームで見たアンプグローとスジの方向がずれていることです。R画像のスジは全部下向きですが、ダークフレームの筋は放射状に広がっていて、上剥き成分もあります。重ねて比べてみると、上向き成分のあるエリアでもR画像では下向き成分になってしまっているので、アンプグロー起因でない可能性が高い気がします。多数スタックで画角がずれてスジもずれたことも考えましたが、明らかに画角ずれ以上にスジがずれています。

こうなるとRフィルターが何か悪さをしているのかと思ったのですが、この前に撮影しているアイリス星雲のR画像にも、この後の同じ日に撮影している燃える木のR画像にも、そんなへんなスジは見当たりません。そうすると本当に存在するスジかとも思ってしまいますが、他の方の、かなり炙り出してある画像を見てもそれらしいものは見当たりません。釈然としませんが、今回は画像処理で誤魔化すことにしました。


USBケーブル

もう一つトラブルを思い出しました。ゴースト星雲と燃える木の撮影ターゲット切り替えの時に一つやらかしたことです。USBケーブルが引っかかってしまいました。

6B15B0B8-118F-499E-89DD-2B5595D700F1
子午線反転のところは必ずその場にいるようにしているのですが、ターゲット切り替えは部屋の中からリモートでやっています。中途半端に垂れ下がっているケーブルが赤道儀の出っ張りに引っかかったようです。ターゲット移動のときにカメラの映像を見ていたのですが、突然変な感じで映像が止まり、接続が切れたみたいだったのでもしやと思って外に出たら、案の定でした。幸いケーブルの方が破損しただけで、肝心なカメラの端子は無事で、USBケーブルを交換して接続し直したらきちんと認識され、撮影も可能でした。ケーブルの方を弱く作ってくれているのかと思いますが、こういったところはありがたいです。

反省点としては、
  • ケーブルの設置はきちんと弛まずに、かつ回転を妨げないようにすること
  • ターゲット移動の時もきちんと現場にいること
などしょうか。


SPCCの意義

新たにPixInsightで実装されたSPCC(SpectrophotometricColorCalibration )は、かなりすごいですね!懸案だったフィルター補正の機能をうまく実装したと思います。かなり原理的に正しい色に近づく可能性が高くなったと思います。

「PCCは科学的に正しいことをしているので、出来上がった色はおかしいはずがない」とかいう意見もちらほら聞きましたが、実際には全然そんなことはなかったということです。以前からPCCでは基準となるカメラと、個人が撮影するカメラの波長に対する応答が違うので、その分の色ズレが原理的に起きてしまうという主張をしていましたが、その機能が見事に実装されています。


個々のカメラの応答をデータとして持ち、参照カメラとの差を補正しない限り、正しい色にならないということです。今回のSPCCでは、実際に個々のフィルターやセンサー特性をデータベース化して持とうとしているため、原理的にも正しい方向に大きく進んだわけです。

さて、どれくらいの機能が実装されたのか、SPCCを使って実際に色合わせをしてみました。SPCCのインストール方法や、巨大なガイアのデータを落として使えるようになるまでは、マニュアルを見ればすぐにわかりますし、日本語の解説ページもいくつかありますのでそちらに任せるとして、使ってみてのポイントだけ少し書いておきたいと思います。

まず、プレートソルブがScriptのImageAnalysisにImageSolverに集約されたことです。これまではPCCは専用のプレートソルブ機能を持っていたのでですが、SPCCはもちろん、PCCもあらかじめ別途ImageSolverを走らせておかなければ、使うことができないようになってしまっています。このことを知らなければ、これまでのユーザはとまどうかもしれませんが、これは正常進化の一環で、一度わかってしまえばこれ以降特に問題にはなることはないはずです。

一番戸惑うところは、フィルターの選択でしょう。デフォルトはソニーセンサーのUV/IRカットフィルターになっています。今回の撮影ではASI294MM Proを使っているので、最初はここら辺から選ぶのだろう考えました。UV/IRフィルターは使っていないので、フィルターなしのソニーセンサーのRGBで試しました。フィッティンググラフは以下のようになります。
SPCC_Sony_RGB
ですが、これを見ると、明らかにフィッティング直線にかなりの星が載っていないことがわかります。

フィルターの選択肢をよく見ているとBaaderというのがありました。よく考えたら今回使っているカメラはモノクロで、応答の違いは主にRGBフィルターで起きていると思うと、使っているフィルターに応じて選ぶ方が良さそうです。実際に今回使ったはBaaderのRGBフィルターだったので、RGBそれぞれにBaaderを選んでみることにしました。すると以下のように、ほぼ全ての恒星がフィッティング直線に載るようになり、少なくともこちらのBaaderを選んだ方が正しそうなことがわかります。
SPCC_Baader
でもこれ、よく考えるとモノクロセンサーの特性は考慮していないんですよね。量子効率はソニーセンサーの選択肢がないので、理想的な場合を選びました。この場合量子効率は全波長で100%とのことなので、やはりセンサーの応答は実際には考慮されていません。

一眼レフカメラは、ある程度専用フィルターファイルが用意されているようです。でもCMOSカメラに関しては、一部のソニーセンサーの型番は専用フィルターを用意されているようですが、基本的には代表的な設定で代用しているので、まだまだ今後発展していくものと思われます。もしくはフィルターファイルは自分で用意できるようなので、実際に使っている環境に応じて自分でフィルターを書くことがいまの段階では正しい使い方と言えるでしょう。

重要なことは、考え方自体は真っ当な方向に進んでいて素晴らしいのですが、まだSPCCは今の段階では色合わせについては完璧はないということです。今後少なくともフィルターファイルが充実して、例えば複数選択できるなど、柔軟に対応することなどは必須でしょう。その上で多くのユーザーレベルで実際の色合わせの検証が進むことが重要かと思います。今後の発展にものすごく期待しています。

さて、PCCとも比較してみましょう。PCCでのフィッティングのグラフを示します。
PCC
SPCCに比べて一見ばらけていて誤差が多いように見えますが、縦軸、横軸のスケールに注意です。SPCCはかなり広い範囲をみているので、直線に載っているように見えるだけで、スケールを合わせるとばらつき具合はほとんど変わりません。実際に色合わせした画像を比べても、少なくとも私の目では大きな違いは見えません。

SPCC:
Image05_crop_ABE_ABE_SPCC_HT

PCC:
Image05_crop_ABE_ABE_PCC_HT

PCCは各恒星の点が2つのグループに分かれたりとフィッティング直線に乗らないケースもよくあります。そんな時はどうしようもなかったのですが、SPCCではそれらを解決する手段が手に入ることになります。SPCCは手持ちセンサーのデータを持つことで、色を正しい方向へ持っていこうとしています。科学的に正しい方向に進むのはいい方向で、少なくともそういった方向が選択肢として選べることは素晴らしいことだと考えています。

SPCCだけでもうかなり長くなってしまいました。続きもまだまだ長くなりそうなので、今回の記事はここまでにします。次は主にBlurXTerminatorについてですが、こちらもなかなか面白いです。

前回、SCA260で撮影した馬頭星雲のことを記事にしましたが、3月のオリオン座は早くに西の空に傾くため、後半は別の天体を撮影することにしました。撮影が複数日にまたがっていたので、フラットやダークが使いまわせるよう、基本何も変えない同じ露光時間、同じゲイン、同じカメラ回転角が条件です。

少し迷ったのですが、M100に決めました。理由は
  1. 春の銀河まつりに参戦するのは今年の目標の一つであること
  2. M33などの大きな銀河はすでに試したので、少し小さめの銀河を試したかったこと
  3. 以前おとめ座銀河団を広角で撮影した時にM99やM100が小さいながらもかっこよかったから
などです。

 


まだ赤道儀はCGEM IIで撮影したときのものです。撮影は3分露光です。M100は小さいので真ん中らへんに小さく写っているだけです。これで分解能が出るのかが今回の勝負です。

でも結論だけ言うと、撮影した画像を見て早々と勝負に負けました。やはりこれくらい小さい天体を撮ろうとすると、揺れが大きすぎるのです。


撮影のことはもう忘却の彼方に

撮影は3月3日と3月9日の二日に渡りました。最初の3月3日の方はまだ使えたのが
  • R:18/20枚、G:20/20枚、B:20/20枚
とマシでしたが(それでもかなり甘い判断です)、3月9日の方は(もう忘れてしまいましたが、風が多少拭いていたのかと思いますが)使えたのがわずか、
  • R:4/12枚、G:2/10枚、B:4/35枚
と散々でした。画像を見ていると、大きく揺れて2つの点になってしまっているのが多かったです。これを見て、さすがにCGEM IIで系外銀河の分解能に挑戦するのは辛いことが実感できました。まあ、頭では何となくわかっていたのですが、信じたくないバイアスがかかっていたのかも...。

本当は3月3日の撮影でBがまだまだノイジーだなと思い、3月9日はBを重点的に撮り増ししたのですが、使えたBはわずか1割と、この揺れのおかげであまりやる気が起きずに、実際の撮影からかなり日にちが経ってしまいました。とりあえず見えるだけでいいやと重い腰を上げ、やっと画像処理を進めることにしました。


WBPPの変化

PixInsightのWBPPですが、最近いくつか気づいたことがあります。まずBiasファイルですが、これはDarkファイルがBaisを含んでいるために、もう処理には使われていません。CalibrationタブのDark設定のところであえてBiasを含まないというオプションを使うと、「検証の結果、biasを引いたダークは今後はお勧めしない」と怒られてしまいます。かといって、Biasファイルを全く指定しないとエラーで止まったりするので、Master Biasをおまじないで登録しておくことにしています。ちょっとまだ整合性が取れていないようです。

あと、Pedestalというのを入れてみることにしました。これは画像処理の過程で0以下の輝度になることを防ぐようです。
WBPP
最近のWBPPでの設定。

Reference画像をオートで選ぶと、たいていRとかの明るく画質がいいのを選んでくれるのですが、これを基準にしてしまうと例えば暗いBがIntegration時に大量に弾かれてしまうことがわかりました。実際にIntegrationされたのはわずか
  • R:21/22枚、G:16/22枚、B:11/24枚
でした。これは前回の馬頭星雲でも同じことが起きていて、原因がわからなかったのですが、Reference画像をマニュアルであえて暗めのものを選ぶことで回避できることがわかりました。その結果、
  • R:22/22枚、G:22/22枚、B:24/24枚
と全てIntegrationに回りました

RGB合成した画像を見てみると、揺れが平均化されているせいか、かなり真円に近くなりました。
Image27_ABE_PCC_crop_DBE_mosaic01

これだといいと思ってしまうかもしれませんが、一枚一枚は揺れていることと、大きく揺れることもあるので採択率は悪いし、何より銀河の解像度は出ていないはずなのでやはりダメです。


EZ Deonを(少しだけ)使ったdeconvolution

今回の画像処理のポイントは、PixInsightでDecomvolutionを試してみたことです。実はこれまで何回も試していたのですが、一度もうまく行ったことがなく、今回ScriptsにあるEZ Deconを使うことではじめておかしくない結果が得られました。

そもそもDeconvolutionはPSFをあらかじめ作るとか、StarNETであらかじめマスクを作っておくとか、R Range maskが必要とか結構面倒です。しかもマスクをの微調整で結果が劇的に変わったりします。参考にしたのはniwaさんのページ


相変わらずものすごく親切な説明で、素晴らしいです。とても感謝しています。さらにはリンギングを無くすために皆さんでいろいろ議論されたことも、最後の方のリンク先から辿ることができ、かなり実用的です。

それでもこのDeconvolution、なかなかうまくいかないんですよね。なので今回EZ Deconという簡単にdeconvolutionを試すことができるスクリプトを使いました。EZ DeconはEZ Processing Suiteの中の一つで、インストール方法はこちらを見るとわかります。


上のページは英語ですが、niwaさんが日本語でも解説してくれています。


EZ Deconを走らせると、こんな画面になります。
decom1

最初はよく分からないのでおもむろに「How to use EZ Decon」というヘルプボタンを押します。読んでいくと以下のようなことが書いてあります。

1. まずは処理したい画像(リニアステージのもの)を選択し、Star Maskを作れと言います。このスクリプトはまだStarNETのV2には対応していないようなので、今回は別途StarNet  V2で星マスクと作っておいて、スクリプト中で選択しました。

2. 次のレンジマスクはこのスクリプトでおまかせして作ってもらいました。

3. 最後「Deconvolution」タブをに移って、PSFを作れとのこと。なんとこのスクリプト、PSFが「Generate PSF」ボタン一発でできてしまいます。これはかなり楽です。

4. ここからがすごいです。deconvolutionを試すのですが、「Evaluate EZ Decon Run」ボタンを押すたびにタブが増えていき、右の方の「Change Tab to Original」ボタンと「Change Tab to Decon Run XX」ボタンを交互に繰り返し押すと、オリジナルとの違いを簡単に切り替えて比較することができます。基本的に変更できるパラメータはスターマスクをどう扱うかのみ。ヘルプに書いてますが、スターマスクを強調したりソフトにしたりすることで結果の違いを見ます。
  • もし画像がノイジーになるなら、Wavletの強さ(strength)を増やす。
  • もし画像がシャープになりすぎるなら、繰り返し(iteration)の数を減らす。
  • もし恒星にリンギングが出るなら、Star Maskの半径を増やして、恒星をよりカバーする。
とのことです。

5. うまくいきそうなら、最後に下の「Run EZ Decon」を押して実際の画像に反映させます。

でも結局このEZ deconでは、どうしても最後までリンギングが残ってしまい、結果は使わなかたんですよね。その代わり、EZ deconで生成されたPSF画像を使い、niwaさんが解説してくれていた、このページ

のもりのせいかつkさんのGlobal dark 0方法でやることで、リンギングを抑えてうまく細部を出すことができたようです。

decon_comp

左がDeconvolution前、右がDeconvolution後です。EZ Star Reductionもかけてしまったので、恒星の大きさは無視してください。銀河の細部は多少出てるようになったと思います。

というわけで、このEZ Decon、結局は簡単PSF生成ツールとしてしか使いませんでしたが、スターマスクの効き具合の感覚とかを気軽に試して、振る舞いを理解するのにはすごく役に立ちました。deconvolutionで困っている人は、一度同じように試すといいのかもしれません。

ところで、DeconvolutionのLocal supportというのがいまいち何をしているのかわかりません。スターマスクをリンギング防止に使っているのなら、恒星自身のdeconvolutionができていない気もするのです。実際、恒星がスリムになったような効果は見えませんでした。そういうものなのか、それとも撮影条件が悪くあまり効かないのか、もう少し理解する必要がありそうです。

その後、ものはついでにEZ star reductionも適用しました。以前、トール兜星雲の時にも試しましたが、その時はそこまで有用性は見出せませんでしたが、今回はかなりの効果があったようです。


いつものPhotohopでの仕上げ

あとは普通にPhotoshopに持っていっての処理でしょうか。今回少し違ったのは、Photoshopで細部があまり出せなかったことです。すでにdeconvolutionである程度の細部出しができているためでしょうか。試しにdeconvolutionなしの画像をPhotoshopに引き渡し、いつも通り加工するのですが、こちらは細部が出てきます。ですが、出来上がった画像の細部はほぼ同等でした。細部をどこで出すかだけの問題で、その画像が持っている限界があり、ポテンシャル以上のものは出ないということがよくわかりました。まだまだDeconvolutionをたいして試していないので、少し甘い気もしますが、むしろ自然な処理具合な気がしています。今後は(やっとですが)Deconvolutionの方に移行していくことになると思います。

結果です。

「M100」
Image27_ABE_PCC_crop_DBE_decom_stredu_ABE_PCC6
  • 撮影日: 2022年3月3日23時51分-3月4日4時37分、3月10日2時54分-5時1分
  • 撮影場所: 富山県富山市自宅
  • 鏡筒: SHARP STAR製 SCA260(f1300mm)
  • フィルター: Baader RGB
  • 赤道儀: Celestron CGEM II
  • カメラ: ZWO ASI294MM Pro (-10℃)
  • ガイド:  f120mmガイド鏡 + ASI290MM、PHD2によるマルチスターガイドでディザリング
  • 撮影: NINA、Gain 120、露光時間3分、R: 22枚、G: 22枚、B: 24枚の計68枚で総露光時間3時間24分
  • Dark: Gain 120、露光時間3分、128枚
  • Flat, Darkflat: Gain 120、露光時間 RGB: 0.08秒、RGBそれぞれ128枚
  • 画像処理: PixInsight、Photoshop CC

実は赤ポチとか青ポチとか期待してHαとOIIIも撮影したのですが、枚数が少なすぎで諦めました。M100の周りの淡いところがもう少し出るかと期待していたのですが、少し露光時間が足りないのかもしれません。もしくはゲインを例えばもう3倍とか上げた方がよかったかもしれません。

恒例のAnnotationです。M100の他にもNGC4312を始めいくつか銀河があるのがわかります。

Image27_ABE_PCC_crop_DBE_decom_stredu_ABE_PCC6_Annotated

最後に、FS-60CBで撮影した時画像
up_DBE_DBE_PCC_AS_HT_all_disks_back2_rot_denoise_larage_cut
からM100の同じ領域を抜き出して拡大してみます。
FS-60

回転して向きをあわせてますが、左端は映ってない領域でした。恒星はまだいいとして、FS-60CBで撮ったM100の解像度が良すぎてなんか怖いです。


まとめ

撮影途中で揺れているのがわかってしまい、あまりやる気の出なかった画像処理ですが、やってみると意外に実のあるものでした。これまで何度も試してことごとく諦めていたDeconvolutionですが、今回のこのEZ Deconでできなかったらもう2度とやらないかもしれないと思いながらやりました。まだ満足とはいきませんが、今後続けていく気にはなりました。それでもFS-60CBで撮ったのが今思うとすごすぎます。SCA260の口径が大きくてもまだ揺れが大きくて性能出しきれていないのでしょう。

まだCGEM IIで撮影した、M101が残っています。サクッと終わらせたいのですが、とにかく忙しくてなかなか時間が取れません。某天文雑誌の原稿もやっと目処がついてきました。その後、晴れてやっとCGX-Lで三つ子銀河と、M51の画像処理ができます。


3月3日の雛まつりの日の夜、月の出が22時18分なので、夕方から準備すればしばらくの間撮影できそうです。狙いは迷ってましたが、早い時間なので季節遅れのカリフォルニア星雲にすることに。結構大きいので、FC-60CBと6Dで視野角的にもちょうど良さそうです。今回も狙いは自宅でフィルターなしでどこまで写るのか? (2021/3/19 追記: 勘違いで、CBPが入ったままでした。)ISO800で、露光時間3分にして、6Dのヒストグラムで見て一番明るい青が1/3くらいでした。

前回Sh2-240を同じセットアップで撮っていて、まだ機材はそのままの状態でほとんど残っています。なので、準備も時間で済み、仕事から帰って、夕食後から用意しても20時過ぎくらいには撮影を開始できました。撮影時間はちょうど月が昇る22時半ころまで。実際には西に傾き屋根に隠されて終了となりました。その後すぐに空が霞んできて曇りのようになったのでここで撤収です。

後でチェックしてみると39枚撮影して使えるのは36枚。3枚は屋根が入っていました。星像が流れているようなものはありません。後半になるに従って西の空に傾くので明るくなってきてしまうのですが、今回はそれらも全部使うことにしました。


WBPP 2.0

次の日フラットとフラットダークを同ISO800、1/400秒で128枚撮影し、ダークは以前撮った同じ範囲の温度をものを使用してWBPP(WeightedBatchPreprocessing)で処理。最近WBPPがメジャーアップデートされて2.0になり、かなり変更がありました。以前のバージョンから使っている人はまあ普通に使えるかもしれませんが、1箇所だけ注意。全てのファイルを登録後、新しくできたControl PanelタブのFLATのところでファイルを選択すると右側にオプションが現れます。これまではライトフレームはカラーかどうか選択するためにCFAオプションがあったのですが、今回からFLATもCFAが選べるので、もしフラットフレームもカラーで撮影したなら必ずCFAオプションにチェックを入れます。

今回のバージョンから処理過程を図にしてくれるのですが、FLATのCFAがオフのままだと下の写真のようになって、フラットが適用されていないのが分かります。

IMG_1943

きちんとFLATのCFAをオンにすると
IMG_1942
のように、きちんとフラットが適用されていることがわかります。

さて、その下のSeparate CFA scalling factorはまだよく理解していないのですが、とりあえず今まで通りオフでやってみました。ただ、オンにするとRGBで別々の係数を使い、オフだとまとめて一つの係数を使うということです。今回のフラットフレームはカラーバランスが取れていないので、もしかしたらオンにした方がいいのかもしれません。


あとは画像処理

出来上がったライトフレームをいつも通りDBE、PCC、ArcsinehStrech、HT、StarNetなどで処理をして、Photoshopに渡してさらに炙り出し。とりあえずできたのがこれです。

Image53_2

恒星がいまいち鋭くないとかいくつか不満はありますが、これはこれで完成です。さあ、ブログと書こうと今に至っているわけですが...

あれ?ダークがおかしい

...と(既に画像処理も終えて、このブログを書くために改めてダークファイルの数を)チェックしていて変なことに気づきました。WBPPのControl PanelにmasterDarkが多数枚登録されているのです。

IMG_1947

そしてDarksタブを見てみると露光時間ごとに一枚づつ、多数のmasterDarkが登録されているのが分かります。

IMG_1946

ところが、試しに今回撮影したフラットフレームとかライトフレームを登録してもこんな変な状況にはなりません。ダークフレームのみこのような状況になります。

ファイル名からdarkというのを取り除いたり、ヘッダ情報を見たりいろいろしたのですが、原因はもっと単純なことでした。ダークファイルが存在する上流のフォルダ名に一つでも「master」という文字が含まれているとこのような状況になってしまうようです。例えば今回は以前撮ったダークフレームを使い回したために「master」というフォルダの下に、さらに露光時間やISO別に幾つかのフォルダに分散してためてあったものを使ったために起きた問題でした。例えば「master」を「mas」とか抵当に名前を変更してダークフレームを登録するだけで、masterDarkでない普通のダークフレームとして登録されます。

さてさて、間違った多数の1枚偽masterDarkファイルで処理したものときちんとダークを登録して処理した画像と、で画像の差はあったか興味がある方もいるかと思います。拡大すると正しいダークを登録した方が明らかに黒い小さな点がなくなる、もしくは緩和されていました。差がわかる部分を拡大して比較ものが下の画像です。左が間違ったもの、右が正しいものです。このような小さな点が画像全面に散らばっています。

comp

ただ、最終仕上げに影響があるかというと、ドット単位くらいの話ですし、間違ったダークと言っても多少の補正はできているので、拡大してじっくり見ない限りはわからないレベルでしょう。

ちなみにこの「master」というフォルダ名、ダークだけでなく、バイアスやフラットを登録する際にも全く同じことが起きて、いずれもマスターファイルとして認識されてしまいます。これだとあまりにも制限が多いので、そのうちもう少し良い方法で解決されると思いますが、PixInsightを使う際にはmasterというのは特別な意味を持つので、むやみやたらに、少なくとも読み込む画像ファイルに関するところには使わないほうがいいでしょう。


仕上げ

このあとまた一通りの炙り出し過程をすませ、不満だった恒星部をもう少し出します。ついでに赤いところももう少しだけ。

master_cut_rot_DBE_DBE_PCC_SCNR_ASx4_HTx2_CT2
  • 撮影日: 2021年3月3日20時26分-22時29分
  • 撮影場所: 富山県富山市
  • 鏡筒:Takahashi FS-60CB + マルチフラットナー
  • フィルター: 無し SIGHTRON CBP
  • 赤道儀: Celestron CGEM II
  • カメラ:  Canon EOS 6D(HKIR改造, ISO800, RAW)
  • ガイド: f120mmガイド鏡 + ASI120MM mini、PHD2によるマルチスターガイドでディザリング
  • 撮影: BackYard EOS、露光時間180秒x36枚 = 1時間48分、ダーク50枚(ISO800、露光180秒)、フラット128枚(ISO800、露光1/400秒)、フラットダーク128枚(ISO800、露光1/400秒)  
  • 画像処理: PixInsight、StarNet++、Photoshop CC、DeNoise AI
Dark補正の違いはほぼ何も影響がないですが、2回炙り出しをやったのでいい訓練となりました。自宅でフィルターなし、2時間弱でこれくらい出るのなら、気楽でいいのかもしれません。

それでもやはり背景はノイジーなのは否めません。分子雲がもう少しあるはずなのですが、もっとはっきり出す技術をまだ確立できていません。今回2時間弱と短かったので、まだまだ撮影時間を伸ばしてみるのもいいのかもしれません。もしくはISOをもう少し上げて恒星がサチるのには目をつぶり、背景を重点的に出すことを考えてやってみるのもいいのかもしれません。

あ、そうだ真ん中らへんの一番明るい星の左のなぜか明るく見える星。ここだけボワッとにじみが出ています。そもそもこんなに明るい星でもないですし、もっと明るい星でもこんな滲みは出てません。ここのファイルはそれほど目立つにじみでもなく、いまだになぜか理由がわかりません。とりぜず理由がわかていないのでそのままにしています。

いつものAnotationです。

master_cut_rot_DBE_DBE_PCC_SCNR_ASx4_HTx2_CT2_Annotated


過去画像との比較

2年ちょっと前の2018年11月に撮影したカリフォルニア星雲です。

NGC1499_CUT

これは直接比較していいものなのでしょうか?記録を見ると撮影時間30分となっています。露光時間も約4倍、画像処理も今と全く違うので、淡いところも全然見えるようになっています。さすがに今回の方が圧倒的に進歩していますね。


まとめ

PixInsightのWBPPですが、まだメジャーアップデート直後でこなれ切れていない気がします。自分の慣れのこともありますし、また不具合などもあると思ってしばらく付き合っていくべきでしょう。

実際にはこれまであやふやだったフラットのCFA処理とかもはっきりしたり、コントロールパネルも見やすくていいです。これからもWBPPの進化に注目していきたいです。



カリフォルニア星雲(2): 撮り増し」に続く
 

このページのトップヘ