fc2ブログ

カラーカメラのフラット作成方法

カラー光源用モニター
 天体改造デジタルカメラなどのワンショットカラーカメラで撮影した画像のフラット処理がどうもうまく行かない、周辺が赤っぽく、中央が緑っぽいなどということに悩んだことがありました。
当初の結論は、モノクロカメラのようにR,G,B毎にそれぞれのフラットを作成して後で合成するという考え方でしたが、ベイヤー段階でフラット処理を完了しないと色々な意味で不都合が発生することに気づき始めました。
その後色々考えて自分なりのフラット作成方法が完成したので、忘れないようにまとめて置こうと思います。
 カラーカメラのためのフラット撮影用の光源はグレーではなくカラーになります。
フラットに使うカラー光源の色は、カメラや使用するフィルター毎に準備する必要がありますので、光源として自宅の画像処理用24インチモニター(EIZO)を使います。
モノクロカメラのフラット作成はモニターにグレー色を表示して作成しています。

FlatColor画像フォルダー
 これはフラット撮影用光源色を表示するための各種カラー画像ファイルを納めたフォルダーです。
ファイル名は"FLAT_カメラ名_フィルター名_R値_G値_B値"となっていますので、必要な画像を全画面表示して、机の前に鏡筒+カメラをセットしてフラット撮影しています。

EOS6D-SEOSP4天体生画像
 基本定義として、光害で部分的に色かぶりが起こることや、大気光で空全体が赤くなることがあっても、夜空はグレーです。
ところが、天体用に準備されたカメラで夜空を撮影すると、大抵グレーには写っていません。
これはEOS6Dを天体改造したSEO-SP4で撮影したRAW画像です。
長波長側の感度を抑えて人間の視覚に合わせるための色調整フィルターを外しているので、全体に赤っぽい画像が出来上がります。

ダミー夜空の色画像作成_R30_G30_B30
 グレーの夜空の画像をフラット補正したいので、きっとフラット画像もグレーで有るべきというのが私のフラット作成の基本です。
先ずモニター光源の色をグレー表示するための画像をフォトショップで作成します。
表示最大輝度はR255,G255,B255ですが、少し暗めのR30,G30,B30の色を作って新規画像をこの色で塗りつぶします。

色作成に使ったカメラセット
 そのグレー表示したモニターをEOS6D-SEOSP4カメラで撮影します。
レンズはタムロンSP45mmF1.8解放です。
カメラはミラーレスではありませんので、全てミラーアップ撮影で画像を取得しています。

色画像_R30_G30_B30を6D-SEOSP4で撮影する
 撮影画像のヒストグラムを表示するとこのように、星空を長時間露光したような感じになります。

フラット撮影用の色画像作成_R8_G38_B35
 今度はフラット画像がグレーになるような表示色を作ります。
何度か撮影と調整を繰り返してR8,G38,B35の青緑色に決定しました。

色画像_R8_G38_B35を6D-SEOSP4で撮影する
 そのフラット撮影用モニターを光源として撮影した画像のヒストグラム表示です。
画像はグレーでRGBのレベルが揃っています。

①①MonoFlat(ダミー夜空)撮影_ダーク減算付き_ベイヤー画像
 ここで作成したフラット画像の効果をステライメージ7を使って確認してみます。
前記しましたように、夜空はグレーという前提で実験します。
実際の星空ではなく、モニターにグレー画像を表示してそれをダミーの星空と見立てます。
そのグレー画像がこれです。
ベイヤーのままなので周辺減光は解りますが色は解りません。

①②ダミー夜空フラット補正_ダーク減算付き_ベイヤー画像
 今度はR8,G38,B35のモニターを撮影した画像でフラット補正します。
これもベイヤーのまま処理していますので色は解りません。

①④自動レベル調整
 処理後のベイヤー画像をRGB変換します。
その際、RGB毎のガンマを自動調整しないように設定します。

①⑤RGB分解
 RGB変換後の画像を周辺減光調整ツールで観察します。
RGB分解してみても周辺減光が揃って少し補正不足です。
周辺減光補正がなぜ不足しているかはこの段階では究明できていません。
しかし、部分的に多少色ムラが見られますがほぼフラットなグレー画像に補正されたようです。
この実験はライト画像もフラット画像も1枚なので、枚数が増えれば多少結果も変わってくるかもしれません。

REDCAT51_ASI6200MC_WBPP_MasterLightImage_Lock.jpg
 私が使っているカラーカメラはZWOの冷却CMOSカメラもあります。
これらのカメラも同じような手順でカラー画像を作り、それを光源としてフラット作成を行っています。
上は年初めに撮影したREDCAT51+ASI6200MCのリニアのカラー画像です。
PixInsightのWBPP処理直後のマスター画像です。
カラーバランス調整無しでは緑が強いですね。

REDCAT51_ASI6200MC_WBPP_MasterLightImage.jpg
 カラーバランス調整を含めると、大体良い感じになります。
左が南ですので光害で少し緑かぶりが見られますが、殆ど問題ない程度にフラット補正出来ています。
軽くABEで調整すれば使えそうです。
https://blog-imgs-136.fc2.com/a/s/t/asterism5592/20220108083614a33.jpg

 長々と書きましたが、まとめると以下のようになります。
1.夜空はグレーである。
2.カメラやフィルターが変わるとフラット画像も変わる。
3.カラーカメラ用のフラット画像はグレーになるように光源色を調整する。
4.光源色を調整するにはカラーモニターが便利。

FLATフォルダー
 このようにして作成したフラット画像は専用のフォルダーに名前を付けて収められています。
私はライト画像の撮影毎にフラットやダークを撮影することはありません。
光学系やセンサー付近は常にゴミが付かないように注意し、たまたま画像のゴミ影が出たらその時は諦めてレタッチします。
フラット画像のフォルダー名は鏡筒、カメラ、フィルター、画面方向(EWorNS)別に作成してフラットライブラリーとしています。
先日、木人さんが同じような興味深い記事を書かれていたのに触発されて、やおら重い腰を上げました次第です。
スポンサーサイト



祝:Windows11でステラリウムが動いた

Windows11_AMDでステラリウムが動いた
 1/11に新しいWindows11のノートPCが届いてから、1週間以上掛かってようやくステラリウムが動きました。
良かったーっ、これで次の遠征で安心して撮影が出来そうです。
今夜はぐっすり眠れます。

Stellarium_log_errors.jpg
 これまではWindows11とステラリウムのバグ関連の調査ばかりしていましたが、エラーを起こしたログを眺めてゆくとOpenGLに関するエラーが見つかりました。
こりゃあ、グラフィック関連のドライバーが問題ではないかと検索してみました。

AMD_DriverDownlode.jpg
 AMDのドライバー&サポートが目に飛び込んできて、早速AMDのサイトに飛びます。

AMD_Softwear_Insttal.jpg
 インストール用のファイルをダウンロードして実行します。
最初はハードウェアとドライバーのチェックが行われました。

AMD_GraphicsDriver.jpg
 なんと全くAMD関連のドライバーがインストールされていなかったようです。
インストールできるバージョンは昨年の10月と今年の1月のものがありましたので最新版をインストールします。
PCメーカーの取説ではこんなことには全く触れていません。
ドライバー関係はOSが自動的に選んでインストールするので、それで良いものと思っていましたが、どうも違ったようです。

AMD_Arara.jpg
 インストールが終わったと思ったら、どいうこと?

Win11が余計なことを
 こんな解決方法が表示されました。
Windows11はどこまで邪魔をするのでしょう。
提示された解決策に従ってWindowsデバイスのインストールを無効にして、もう一度AMDドライバーのインストールをやりう直しです。

AMD_SoftwearInstComp.jpg
 今度は上手く行きました。
ということで念のためPC再起動後ステラリウムを実行すると、インテルプロセッサを積んだWindows10と同じように無事に動いてくれました。
AMDのプロセッサを選んだのは今回が初めてでしたので、まさかドライバーのインストールから始めるとは知りませんでした。
PCメーカーの取説にもちょっと書いておいてくれれば良さそうなものですが、そんなことをサポートに言ったら「常識でしょ!」とか言われかねない。
全く、ポンコツ爺さんがPCを扱うのは一苦労です。
長かったなあ ・・・ そうそう、ついでにBLOGもSS化しました。

Windows11とステラリウム

ステラリウム起動直後
 これまで使っていました観測のメイン機材用ノートPCの調子が悪い(頻繁に瞬停を起こす)ので新調しました。
今時ですからOSはWindows11を選ぶしかないのですが、今までWindows10で使っていたPCのようにローカルアカウントでアプリのインストールを進めました。
動作確認を続けているうちに、ステラリウム(v0.21.3)で問題が発生しました。
ステラリウムはWindows10の入った全てのPCで使用中ですが、今回のWindows11では表示設定で赤経・赤緯、高度・方位線の表示が出来ません。
それだけではなく、表示設定のカスタマイズをする前のデフォルトで起動した時の使用メモリーが375MB位だったものが、表示設定を進めるとメモリー使用量がどんどん増えてゆき止まりません。

ステラリウム起動暫くして
 起動してから数分でこんな風にメモリー使用が4GBを超えて、RAMが8GBのPCではやばい状況に。
そしてクラッシュ、消えてしましました。
その後、PCのメモリー診断をしたり、WindowsUpdateを最新にしたりと手を尽くしたのですが、まったく改善する様子は見られません。

イベントビュアー
 Windowsのイベントビュアーを見ると、ucrtbase.dllが障害を起こしてクラッシュしてるようです。
Windows10のWindows\System32\ucrtbase.dllとはファイルバージョンが違うので、何とか旧バージョンに入れ替えてみますが効果無しでした。
どうやら昨年の10月のWindows11のリリース当時から問題になっていた特定アプリなどで発生するメモリーリーク問題が絡んでいるようです。
特に今回新規導入したPCのCPUがAMDのプロセッサーだったことも災いしているような感じです。
国内ではWindows11でステラリウムに問題が発生するという情報が見られませんので、ステラリウムの開発者のフォーラムに質問してみたのですが、Windows11を導入する意味はないということでした。
全てはマイクロソフトのWindows11の問題でステラリウムは無関係というスタンスです。
まあ、Windows11は要らないと言われても、今時新しいPCが必要になったらWindows11が普通にプレインストールされていますから、こちらに選択肢はないのですがねえ。
その後も色々やってみるのですが、どうもステラリウムは使えないようです。
望遠鏡制御などには使っていませんが、天文情報量が多くて便利に使っていたので残念です。
ステラリウムを使いたければ、マイクロソフトがWindows11のメモリーリーク問題を完全修正するのを待つか、Windows10をクリーンインストールするか二択の状況です。
インテルPCを選んでいたらWindows11でステラリムが正常に動いたのか ・・・ 気になりますね。

PixInsightによる彗星+恒星基準合成

C2021A1_20211211-05h03mJST_new.jpg
 これは12/11朝に野辺山で撮影した、低空のレナード彗星です。
12/12のBLOGに掲載した画像を再処理したものです。
PixInsightを使うようになって5年ほどたちますが、明るい彗星が現れるたびにこの合成方法を行うにあたって試行錯誤して来ました。
その結果を忘れないようにBLOGに残してきましたが、今回のレナード彗星の処理でも少し進化したので備忘録として残します。

Comet Alignmentの前に画像の平坦化を行う
低空で撮影した彗星画像30分の変化
 この日の撮影開始時5h03mJSTのレナード彗星の高度は9.1度で、その後30秒露光で40コマを連続撮影しました。
終了時刻は5h29mで高度は14.2度で、5h13mには天文薄明に突入していました。
上の画像はRedcat51+EOS6D-SEOSP4の生画像で、撮影開始・中間・終了を並べています。
中間コマが最もバックグランドが低く、画面内の輝度傾斜が小さいのが解ります。
更に最終コマは薄明の影響を受けて青成分が強くなっています。
 このように、低空で撮影された画像から作られた彗星画像を各画像から引き算すると一体何が起こるか想像に難くありません。
彗星画像を全画像の中央値で合成した場合、彗星のみ画像のバックグランドは中間に撮影した画像のバックグランドよりも高くなり、彗星引き算で作った彗星無し画像のバックグランドは全てゼロ値になってしまいますね。
そのようにして作られた彗星なし画像をスタックした画像は、彗星コマ付近の影響が消えたり消えなかったりの合成になってしまします。
そこで、WBPPが終わってregisteredフォルダに作られた画像は、先ず全ての画像の輝度傾斜とバックグランドレベルの統一処理が欠かせません。
尚、WBPPでは正しいFLAT除算を必ず実行してあること、撮影画像はCFA画像での話です。
 何故、彗星撮影はCFAかと言えば、彗星が地球に接近すると日々運動が大きくなるだけでなく、コマから電離したイオンの尾も拡大されて短時間で変化を繰り返します。
ディティールを保つため時間分解能を高めるにはモノクロカメラによるRGB撮影は時間が掛かって不向きだからです。
勿論カラーカメラを使いながら星雲・星団撮影のようにディザー撮影しますというのは論外ですから、ノイズ対策はダーク減算やCosmeticCorrectionで対応します。

WBPPで出来たregisteredフォルダ内画像の平坦化
registeredフォルダ内ファイルをABEバッチ処理
 2020年11/30の「薄明の超低空で撮影した彗星の処理」という記事では、この事前処理をBlinkのAutomatic Histgramで統一して保存(TIFF)しました。
それは便利だったのですが、今回は32bitのまま作業を進めるためにImageContainerとAutomaticBackgroundExtractor(ABE)を使います。
2018年12/3の「PIのImageContainerを使ったバッチ処理」もご参照ください。
WBPPでフラット処理が出来ていれば画像の輝度分布は街明かりによるリニアに近い傾きだけなので、ABEのFunction degreeはデフォルトの4ではなく2に変更します。
この値を大きくして高次のフィッティングを行うと、彗星輝度が落ちて周辺がリンギングのように黒っぽくなってしましますので、必ず1次か2次での処理に留めます。
それ以上の高次補正でないと平坦化しないという画像はフラット補正が正しくないからであると考えられます。

平坦化画像のバックグランドレベル統一
バッチ処理できないSTFとHTによるレベル統一作業
 上記の作業で平坦化したregistered_abeフォルダ内の画像はBlinkでチェックすれば分かりますが、まだバックグランドレベルが統一されていません。
それもバッチ処理で楽をしたいのですが方法が解りませんので、全画像を図のような繰り返し手順で作業します。
上記作業でレベル調整した画像は手順⑤で新しくregistered_abe_htフォルダを作ってSave asで保存しても良いのですが、面倒であればSaveで上書きすれば楽です。
※12/22追記
STFのバッチ処理を蒼月城さんにTwitter経由で教えて頂きました。
****************************************************************
STFのオートストレッチは PixelMath でもできます。
まずは鎖マークをオフにした unlinked autostretch から。以下をコピペしてください。

[RGB/K]
c = min( max( 0, med( $T ) + SC*mdev( $T ) ), 1 );
mtf( mtf( TB, med( $T ) - c ), max( 0, ($T - c)/~c ) )

[Symbols]
SC = -2.8,
TB = 0.25,
c
****************************************************************
STFのバッチ処理
ということで、PixelMathの[RGB/K]と[Symbols]におまじないを記述することで、ImageContanerと連携してバッチ処理が実現できました。
linked autostretchも教えて頂きましたが、既にABEを実行していますので結果はどちらも一緒なのでそちらは略します。
蒼月城さん、何時もありがとうございます。m(_"_)m

彗星+恒星基準合成
1)彗星基準に並び替え
 上記で平坦レベル調整を終わった画像で、愈々彗星+恒星基準合成作業を開始します。
CometAlignmentで並べ替えます。
このプロセスは他にも説明が多いので省略します。

2)星無し彗星画像の生成
星消し彗星のみ画像生成設定
 以前はImageContainerとStarNetやStarXTerminatorのバッチ処理で星消し画像を生成してImageIntegrationで合成しました。
しかし、NIWAさんのPI解説によるImageIntegration/Combination:Median/Rejaction algorithm:Liner Fit Clipping/Linear fit high:1.0~0.5が処理時間も短く優れていました。

II_medianで生成された彗星画像
 これがLinear fit high:0.5で生成した星無し彗星画像ですが、まだ恒星の消し残しが見られます。

CloneStampで修正した彗星画像
 M3とのランデブーではM3の消し残しが強烈で、どうしてもCloneStampによる手動消去を避けられませんでした。
ここでも僅かですが星の消し残しの処理をします。

3)彗星無し恒星画像の生成
彗星減算のバッチ処理
 彗星基準画像から彗星のみ画像を減算するのはImageContainerとPixelMathでバッチ処理します。
新しく作ったcomet_lessに収納します。
先ずは前段で生成した引き算する彗星のみ画像を読み出します。(この場合は"comet_median_lfc050_cs.xisf")
PixelMathの記述では、処理対象となる元画像は「$T」と記述します。

元画像と彗星画像のバックグラウンド比較
 また、事前に減算する画像のバックグランドと2)で作った彗星のみ画像のBGレベルとを比較してみてください。
引き算する彗星のみ画像の値の方が高い場合は元画像のバックグランドよりもギリギリ低くなるように調整しましょう。
今回生成した彗星画像のバックグランドは元画像よりも僅かに低かったので調整せずに減算を行いました。

4)彗星無し恒星画像
彗星減算のバッチ処理
 彗星の減算が終わったら、StarAlignmentで恒星基準に並び替えてcometless_staralignというフォルダに保存します。

彗星無し星野の完成
 次はImageIntegrationで彗星無し恒星画像を作ります。
この場合は星消しの設定ではなくCombination: AverageでPixel Rejection(1)ではAlgorithmを通常ライトフレーム合成時と同じものを選択します。
Pixel Rejection(2)のパラメータはデフォルトのまま。
上は上記の手順で作った今回の彗星無し恒星画像です。

5)彗星と恒星の合体
彗星_恒星基準合成画像の完成
 2)と4)で作った画像をPixelMathで加算するだけです。
ご覧のように正しいフラット補正を行い、更に画面の輝度傾斜の修正とレベル統一を行ってから処理すれば、超低空での彗星画像もこのように滑らかに仕上がります。
ここでは星無し彗星画像を手修正しましたが、消し残りがあればStarAlignmentでズレた影となって必ず現れます。
固有運動の小さい場合はあまり気になりませんが、地球に接近して日々運動が大きくなった彗星画像では余程バックグランドを黒くしない限りスジだらけになるでしょう。

CloneStampによる星消し仕上げ
 特に輝星が画面中に入った場合は現状の星消しツールの実力ではCloneStampによる手動消去は必須となります。
このようなレタッチ作業は上手い、下手で結果が変わりますのであまり使いたくない手法ですが、DynamicBackgroundExtraction(DBE)も慣れが要求されて人それぞれで仕上がりに違いがあることを思えば、星消しツールが完璧でない以上は必要悪として認めざるをえません。

comet_star_lfc050_cs_rf01.jpg
 以上で彗星+恒星基準合成画像が完成しました。
これまでは全てリニア画像の処理でしたので、トーンカーブなどを使って先頭画像のように仕上げます。
超低空での総時間20分の露光ですので、あまりキツイ処理はできませんが何とか鑑賞に堪える程度には処理できるでしょう。
 長々と書いた彗星+恒星基準合成の魅力は、他の天体とのランデブーで両方の動きを止めてこそ真価を発揮するというものです。
しかし、特に彗星のように星雲状で動かない天体との合成では、彗星部分だけをマスク合成するくらいしか方法がないのではないでしょうか。
そうなると合成は合成ですが、完全な嵌め込み画像になってしまいます。
散光星雲上を彗星が通過などというイベントがあっても、これまで説明しました方法では手も足も出ないでしょうね。
この方法が使えるのは球状星団や銀河とのランデブーまででしょう。

StarXTerminatorの再評価

SXTvsStarNetHTvsLow_全体
 10/23にM31を使った星消しツールの比較を行ったのですが、昨日掲載したIC1805の処理中に評価が一変してしまいました。
上の2点がStarXTerminator(以降SXT)で下の2点がStarNetによるものです。
更に右の2点がオリジナルスタック後のLow画像をそのまま星消ししたもので、左の2点が適度な明るさにレベル補正したStretch画像に星消しを行った結果です。
右下はLow画像をStarNet処理した画像で星が消えていません。
左下のStretch画像をStarNet処理した画像では輝星は消えているのですが、暗い星の消し残しが多くノイジーな感じです。
右上はLow画像をSXT処理した画像で左下よりも暗い星が良く消えて星雲部が随分と滑らかな感じに仕上がっているのですが、輝星の消し跡が気になります。
左上はStretch画像をSXT処理した画像で、右上よりも星消しも星雲の滑らかさも優れていますが、星雲部分のディティールが消されてツルンとした感じです。
それと全体のコントラストが下がったような感じにも見られます。

SXTvsStarNetHTvsLow_拡大
 こちらが50%拡大画像です。
この段階で下のStarNet画像は使いたくないなあ、という感じです。
左上は全体で見たときよりも滑らかさが一段と際立ちます。
星雲のディティールが消えたような感じだったのですが、この程度でしたら背景が滑らかになった分、シャープ感を出す後処理で何とでもなりそうです。

HT無し星あり元画像をStarNet処理
 今回使ったIC1805画像はε-160EDにNB2フィルターを装着したASI6200MCのRGB画像です。
PIで読み込むとこのように画面は真っ暗です。
上の星消しに使ったLow画像というのは、この状態からSTFのRGB Channelのリンクを外してAuto Stretchをかけた状態です。
全く元画像のままの処理になります。

星あり元画像の処理
 更にSTFのAuto Stretchで明るくなった画像をHTに移してレベル補正をFixedした後の状態をStretch画像と呼びました。
HTではトーンカーブは弄りませんので、リニア画像のままです。
特にStarNetではこの処理画像のレベルが結果に大きく関わるようです。
星消しを画像処理全体のどこで行うのが最適かまだ分かっていませんが、トーンカーブ調整などのノンリニアな調整を行う前においても、バックグランドの適正化後に行うのが良さそうです。

 前回の星消しツール比較を書いた後、のんたさんとSXTはディティールが消えるからどうもねえ ・・・ と意気投合したのですが。
早くも裏切り報告になりスミマセン。 m(_"_;)m
その一方で、既にSXTをライセンス購入し早まったかと思っていたので、ちょっとだけホッとした鴨。
皆さんは他人の評価を真に受けず、30日の試供期間内にシッカリ評価してください。
プロフィール

voyager_camera

Author:voyager_camera
随分昔に小惑星観測をしていましたが、もう新天体捜索も位置測定もしませんので、鑑賞天体写真撮影に努めています。天文雑誌は買わない読まない流儀なので雑誌のフォトコンには応募しません。偶に天文カレンダーに採用していただきますが、主にブログで写真を見ていただいています。
mail:y-osima@r.sannet.ne.jp

最新記事
最新コメント
月別アーカイブ
カテゴリ
カウンター
検索フォーム
RSSリンクの表示
リンク
ブロとも申請フォーム

この人とブロともになる

QRコード
QR