FC2ブログ

OSCカメラの為のカラーフラット

フラットなし画像
 新しく導入したワンショットカラーの冷却C-MOSカメラ(ASI6200MC)による撮影は、先月の24日から全く進んでいません。
現在はその時の画像を使って、一連の画像処理作業を検証している最中です。
これはフラット補正なしのアンタレス付近の星野です。
撮影高度は低いのですが、撮影場所は伊豆で南がかなり暗く、街明かりの影響が少ない画像です。
右上のヒストグラムをご覧になってお解りのように、ピークの左側に傾斜があります。
周辺減光を除去していませんのでバックグランド値に幅があるので当然このようになります。
今回使った鏡筒はTS15028HNT(D150mmF2.8)ですが、このノーフラット画像をご覧になって、これならナンチャッテフラット補正でも楽勝と思われませんか。
4/15の記事にも書きましたが、二重のリング状の補正残りがどうしても取れなくて処理が進まないのです。

TS15028HNT_ASI6200MC_スーパーフラット撮影
 取り敢えず、今迄のデジタル一眼でのフラット撮影と同じように、自宅で上記のように乳白色のポリ袋を筒先にかぶせて、白壁に向けて撮影します。
部屋は遮光カーテンを閉めて、わずかに漏れる屋外からの自然光任せ、露出も光源も適当な状況での撮影です。
そのフラットを使ってできた画像は以下のようになりました。

グレーモニターフラットあり処理画像
 このテストに使ったアンタレス付近の画像は赤や青の星雲が広がっていますので、ヒストグラムの立ち上がりが緩いのは仕方ないのですが、直接画像を見ても四隅が赤っぽくなっていて、中央付近は緑や青が勝っている感じです。
これまで使っていたEOS6D-SEOSP4でもこんなやり方で、その後カラー化した画像をステライメージなどでRGB毎に補正していました。
 今回はEOS Raの2倍近い投資をして購入したカメラですから、もうちょっと真面目な使い方をしたいなあ ・・・。
OSCカメラが吐き出すBayerファイルの場合、フラット補正後にDebayerでカラー化した画像のRGB各プレーンが均等に補正されている、などということは先ずありません。
ステライメージのフラット補正にあるガンマやオフセット調整はとても便利ですが、カラー化してからRGB毎にまた手作業での補正 ・・・ うーん、解ってはいてもやっぱり面倒くさい。
モノクロカメラではなくOSC35mmフルサイズを購入したのは、所詮横着者で楽をしたいからなんですねえ。
ですから、撮影した画像はPixInsightのBPSに放り込んで終わりにしたいというのが本音です。

Expo_600sec.jpg
 大体夜空の色って何色?
人工光がほとんど無いオーストラリアでも大気光で画面が赤くかぶることもありますから、決してニュートラルとばかりは言えません。
伊豆で撮影したアンタレス付近の画像をフラット補正せずにDebayerして、カラーバランスを自動補正せずに表示してみます。
これはASI6200MC/Gain=0/Offset=10/Expo.=600secの画像です。
随分とGレベルが高く、Bは最低です。

Expo_30sec.jpg
 こちらはExpo.=30secです。
同じ空、同じセンサーなのにRGBの関係が変わってしまうのですね。

ColorEdge-CX240.jpg
 フラット撮影を行う光源の色温度というのは関係ないのだろうかと思い始めました。
私の使っているPCモニターはEIZOのCX240で、モニターの明るさ、色温度、ガンマ値を設定することができます。
早速、4000K~10000Kまで500K飛びでの表示用プロファイルを作成しました。

4000K_SI7_Color.jpg
 これはモニターの色温度を4000Kに設定して、RGBの各レベルを40/256に設定したグレー画面を表示して、それでTS15028HNT+ASI6200MCのフラットを撮影した画像です。
前の画像と同じく、カラーバランスの自動調整は外したままです。

7000K_SI7_Color.jpg
 これはモニターを7000Kにしたものです。

10000K_SI7_Color.jpg
 そしてこれが10000Kです。
星の色と同じように、色温度が上がると青っぽくなってゆきますね ・・・ 解り切ったことでした。
それで先ずは600秒露光と同じようなRGB関係の色温度はとみると、10000Kが比較的近かったので、10000Kでフラットを作成して、ステライメージでBayer画像のフラット補正を行います。
その際、フラット補正のオフセット値を調整して全体の補正が適正になるようにするのですが、Debayerを行うとやはりRGBが均等にはなりません。

 問題は空(この場合はフラット光源)ばかりではなく、同じ空を撮影してもOSCカメラによるRGBの分光特性が違うので、RGBバランスは一定ではない筈ですね。
となればもう、光源の色温度ではなく、表示する画面の色そのものを変えてやればよいということになります。

FlatColor作成
 これはフォトショップでモニターに表示する画像のRGB値を調整しているところです、というか今回の実験の最終値です。
作業はフォトショップの色の設定でRGBの値を変更して、色を追加したらその色で画面を塗り替えます。

PCモニターによるカラーフラット撮影
 そのモニター表示画像を表示して、横の観測用ノートPCでフラット画像を撮影し、そのままノートPC上でベイヤーのフラット補正実行、更にカラー化してRGBが均等にフラット補正できる色を探します。
この時のカラー化では自動補正を有効にして、できたカラー画像をRGB分解したり、カラーのまま彩度強調して判定します。
今回の作業では、こういうテストをするときは散光星雲や反射星雲などの広がったガス星雲が入っていない、星だけの星野を使った方が判定が簡単だっと反省しています。
上の画像でも判りますが、最終的に作られたフラット撮影用の画面は結構緑色になりました。
ちなみにモニターの色温度設定は何時も作業に使っている6500Kでした。

フラットファイルのオフセット調整作業
 複数枚撮影したフラット画像は、PIのIIでBaseFlatを作成しますが、ライトフレームの露出時間によって補正効果が変化します。
PIのBPSに使う前に、そのライトフレーム露出時間用にオフセット行います。
PIのPixelMathでベースの値を加減してICで事前にフラットの効果を確認しておきます。
EOS6Dは14bitしかありませんでしたので、ライトフレームもフラットフレームも4096の半分くらいの値になるよう撮影していましたが、ASI6200MC/Gain=0/Expo.=600secでは今回の鏡筒(F2.8)で比較的暗い伊豆の空ではレベルがK=1300ほどしかありません。
フラット画像レベルはそれよりも少し低いK=1000程度に撮影してオフセット(+0.005)を加えると1400位で丁度良くなりました。
Expo.=30sec画像用フラットのオフセットは(+0.2)位でした。
尚、PixelMathでは16bitファイルの計算でしたので、加算値=1.0=16bit=65536です。

アンタレス付近_カラーフラット補正あり
これがPIのバッチプロセスに元画像と今回作ったカラーフラットを放り込んで出来上がったアンタレス付近の画像です。

M8付近600s_カラーフラット補正あり
 これは同じ日に撮影した600秒露光のM8&M20の処理画像です。
RGBのレベル調整と切り詰めをしましたが、直線性を弄っていません。
こちらの方が画面内のガス星雲の広がりが少ないので、バックグランドがフラットで、ヒストグラムの左側がスッと立ち上がっています。

M8付近600s_カラーフラット補正あり_彩度強調
 確認のため、上の画像の彩度を目一杯に上げてみました。

M8付近30s_カラーフラット補正あり
 さらに念のため、30秒露光のM8&M20の処理画像です。

M8付近30s_カラーフラット補正あり_彩度強調
 こちらも、彩度を目いっぱいに挙げてみます。
ベースのフラット画像をオフセットして使っても、RGBの平坦性は大きく崩れていないようです。

 今回作ったフラット光源用カラー画像ファイルはASI6200MC専用です。
モニターの色温度6500Kでこのカラー画像を画面に表示して、それを光源としてASI6200MCを取り付けた鏡筒で撮影すればベースフラットが作成できます。
更に、露出毎にオフセットを加えたフラットをMasterFlatとして使えば、キャリブレーション作業はPIのBPSを回すだけです。
 ところで、今回ASI6200MCの画像6枚をBPSに放り込むと作業終了までに30分かかりました。
タスクマネージャーでデバイスの稼働率を見ていると、Debayerまでの作業では楽勝なのですが、Debayer実行開始すると途端に他の作業が完全停止となります。
内部計算ではファイルを32bitのRGBで扱っているからでしょうか、HDDのアクセスランプが完全点灯で、ディスクの耐久テスト状態になってしまいます。
現在画像処理に使っているPCはそろそろ10年選手、i7-860(2.80GHz)でメモリが16GBしかないのでHDD上の大きな仮想メモリで作業するのだと思うけれど、厳しいなあ ・・・ と言っても、こちらの懐も。
スポンサーサイト



PHD2とMaxImDLでディザリング撮影

1_PHD2-Dither-App.jpg
 星景写真以外の天体撮影用のカメラとして、カラー版の冷却C-MOSカメラASI6200MCを選びました。
なぜASI6200MMにしなかったのかについては以前にこのBLOGにも書きました。
それでも、少しでもベイヤーフィルターを使ったカメラの画質を向上させるために、ディザリング撮影は有効そうです。
キャプチャーソフトはMaxImDLでガイドソフトはPHD2を使っていたのですが、"PHD2 Dither App"というソフトを使うと新しい投資なしでディザリングが可能になるというので試してみました。
https://openphdguiding.org/phd2-dither-app/

MaxImDL_Autosave-setup.jpg
 詳しい使い方はPHD2の日本語マニュアルにも書かれていますので、興味のある方はそちらをご覧ください。
実は、MaxImDLにもDitherがあるのです。
MaXImDLカメラコントロールのAutosave Setupにある"Dither"は使わずに、各Slotの最後にあるScriptにPHD2 Dither Appを収納したデレクトリ内にあるスクリプトファイル"Dither_script.vbs"を指定します。

PHD2-Dithering-Parameters.jpg
 PHD2の設定が終わってガイドができる状態になったら、"PHD2_Dither.exe"を起動してみるとこんな画面が出ます。
上のウインドウの"Config..."をクリックすると下の設定画面が出ます。
この画面のパラメータはデフォルトのままですがこれで問題ないようでした。
PHD2のメインウインドのツール/サーバの有効化にはチェックを入れておきます。
PHD2の設定(脳みそマークで出てくるウインドウ)の全体/Dither Settingsではスケールを"1.0"のままにしておきます。
またModeはデフォルトでは"Random"ですが、今回は"Spiral"にしてみました。

PHD2-Dither-APP_Script.jpg
 これは実際にMaxImDLのAutosaveで撮影を行っているときの画面です。
1Slotが終わってスクリプトが実行されると"PHD2 Dither"のウインドが現れます。
最初に現れたときは実行確認画面が現れていちいち確認を求めてきましたが、その画面の中にあった詳細設定で"通知しない"というのを指定してからは、勝手に起動してスクリプトが完了すると勝手に閉じてMaxImDLのAutosaveが停止しなくなりました。
PHD2 Ditherウインドの"Latest Message"の"current separetion is:"の値が小さく変わっていって、10秒くらいでウインドウが消えて次のスロットの撮影が開始され、30秒のタイムアウトになるスロットはありませんでした。
思っていたよりも、簡単にディザー動作を終了して時間のロスも小さい感じです。

PHD2-Graph_Dithr.jpg
 ディザー動作を行うとPHD2の履歴グラフの上に"ディザー"と表示されますが、グラフの折れ線とともに左に移動してゆきます。
実際のディザー動作中はグラフが止まっているのか、特に乱れが記録されていません。

PHD2-Dither-App.gif
 これは実際にディザリング撮影した6枚のベイヤー画像をPIのBrinkで400%に拡大してTIFに出力、PhtoshopでGIFアニメに加工したものです。
ランダムではなくスパイラルを指定していたので、円を描くように星が動くのかと思ったのですが、チョット歪な円形に移動しているような。
まあ、充分にディザリングにはなっているようで、良かったヨカッタ。

 「世界初(*)有効約6100万画素の35mmフルサイズ裏面照射型CMOSセンサー」というコピーは、勿論SONYのデジタル一眼カメラα7R IVのことです。
そのサイトを見に行くと「ピクセルシフトマルチ撮影」という機能があることが解ります。
https://www.sony.jp/ichigan/products/ILCE-7RM4/feature_1.html
ベイヤーセンサーはモノクロセンサーやシグマのFoveonセンサーに比べて解像度の点で不利ですが、それをカバーする撮影方法や画像処理方法がユーザーも気が付かないうちに浸透してくるのですね。
基本的にはディザリングと同じですが、この機能が天体写真でも使えるのだろうか。
うーん、最近はソニーのデジタル一眼がキャノンやニコンを凌駕しているが、凄いですねえ。

RegiStax 6.1 による土星の処理

 お天気が悪いので、以前撮影した土星画像をRegiStax 6.1によるスタックとウェーブレット処理の練習です。

こんな土星画像でどうするの
 元々はこんな画像を処理しています。

AS26vsRS61_土星スタック比較
 前回の木星でも見たように、AutoStakkertでは土星も環の周辺に汚れが現れています。

RS61によるWavelet仕上げ
 WinJUPOS 11.0.4 で12分 De-rotation したモノクロ画像を Wavelet で仕上げます。
うーん、本体の輪郭線が消えてくれません。
どうも WinJUPOS の使い方にも問題があるのかも知れません。

AutoStakkertによるスタック画像が汚い

 ビデオカメラによる惑星撮影を始めてから随分となりますが、今になっても綺麗なスタック画像が得られずに悩んでいます。

AutoStakkert!-26_jupiter.jpg
 これはASI290MMによる木星画像をAutoStakkert! 2.6でスタックしている状況です。
それにしてもQuality Graphを見ると結構酷い画像ですね。
こんな画像は使わないのが正しい選択なのかもしれませんが、そんなことを言うと惑星撮影は年に何回も出来ないことになってしまいます。
 ここではAlignment Pointsは少なめにAP sizeを200、輪郭付近を避けて取るようにMin Brightを60に設定しました。
こんなに悪い画像ではQuality EstimatorのNoise Robustの値をもっと上げるように推奨されますが、Normal範囲の[6]まで上げてみましたがあまり改善する感じが無かったので[4]をデフォルトとして処理します。
ということで、一般に推奨されるようなパラメータ設定はこんな感じでしょう。

AutoStakkert!-30_jupiter.jpg
 そろそろバージョンアップをと思っていたので、これを機会にAutoStakkert! 3.0を導入しました。
全く同じ画像を上のVer2.6と同じパラメータで走らせたところ、処理時間は約40%に短縮されていました。
楽ができます ・・・ ではなく、今回は品質の話でした。

AS比較_20190628-223517_ap100
 結果はご覧のように、木星のリム付近に汚いゴミの影のような模様が発生しています。
AutoStakkert! 2.6と3.0では、全く同じパラメータで、スタック後のRegiStax 6.0によるWavelet処理も同じにしたのですが、汚れの出方が少し違っています。
同じ画像なのにQuality Graphも少し違っているので、バージョンアップでアルゴリズムも変わったの鴨。

RegiStax-60によるスタック
 AutoStakkertでは輪郭に発生する汚い影が消えないようですので、久々にRegiStax 6.0によるスタックを試みました。

RegiStax-60によるWavelet
 次にAutoStakkertと同じパラメーターでWavelet処理を行います。

AS3-APsizeとRS6のスタック結果比較
 これがAutoStakkert! 3.0とRegiStax 6.0によるスタックの結果比較です。

上からAS3でAPsが48、104、200、304で、一番下がRS6によるスタックの結果です。
全ての画像はスタック後に全く同じパラメータによるWavelet処理を行っています。
AS3による木星は程度の差はありますがゴミのような影が残ります。
それに比べて、RS6は綺麗ですね。
しかもWaveletのパラメータが同じなのに随分と滑らかな仕上がりになっています。
AS3とRS6のスタック品質は大差がないという話も聞くのですが、ここでは元々の画像品質が悪いと結構な差が出るという結論になりました。
AS3でもリム付近の汚い影が出来なくなるようなパラメータ設定が見つかれば良いのですが、それまでは時間が掛かってもRS6によるスタックが安全そうです。
 ASI290MCによるカラー画像だと多少状況が違うようですが、画像によってはやはり汚い影がは発生するようです。
今回RGB用としてASI290MCで撮影したSERファイルは、一度AVIファイルに変換しないとRS6では読めないのですから厄介 ・・・ と思いながらSER playerでSERをAVIで保存すると、あれーっ、なぜかRS6では読めなくて ・・・ 問題が多いです。
この問題が解決するまでは、カラー画像の保存はAVIにしておいた方が良さそう。
 それにしても今頃RS6でスタックしている人はいるのでしょうか?
モノクロ&カラーカメラでのLRGB合成は、WinJUPOSでの合成も含めて中々ハードルが高いです。
かなり条件の悪かったであろう環境で取得した画像を、コンスタントに処理している方を見ると本当に感心します。

FireCapture(v2.6.08 x64) RAM Buffer(experimental !)の効果

惑星撮影システムとFireCaptuer
 太陽・月・惑星に使うビデオカメラがUSB3.0に対応してからは、ずっとASIのC-MOSカメラとFireCaptureを使い続けています。
惑星撮影ではこんな風にPowermate + ADC + Flip Mirrorを使い、モノクロとカラー2台のカメラを同時に起動した状態でミラーを切り替えながらLとRGB画像の撮影を行います。

観測用PCのシステム構成
 カメラをUSB3.0に換える際、観測用ノートPCも新調しました。
これが現在惑星などの撮影に使っているPCのシステム構成です。

 使い始めた頃のFireCaptureはV2.2でしたが、現在はV2.6.08 x64を使っています。
私にはバージョンが進化しても頭を悩ませ続ける問題がありました。
それは撮影する度にキャプチャーフレーム数が安定しないことです。
FireCaptureの使い方で良く見かける"USB Traffic"の設定なども見直しても全く効果が無く、国際宇宙ステーションの日面通過の際に途中で歯抜けのようになってしまったこともありました。orz
探し方が悪いのか、ネットでこの問題と解決策を検索してみても適当な記事が発見できません。

FireCaptuerで木星撮影したファイルサイズ
 これは一昨晩に木星を撮影した際の保存フォルダーのファイル表示です。
撮影は常にクロップ画像(1032x990)を60秒間キャプチャーしているのですが、これらのファイルサイズを見てください。
サイズが安定せずバラバラです。
これでも酷くサイズが小さいものは削除しているのです。
つまり、キャプチャー終了後に"Captures/Saved"が示すファイルサイズが、撮影のたびに大きく変化しているということです。

撮影ごとに違うFPS
 これらのファイルの中から連続して撮影した画像LOGファイルの"Jup_221453.txt"と"Jup_221638.txt"を比較してみます。
どちらも緑枠で囲った"Duration"と"Shutter"は同じですが、赤枠で囲った"Frames captured"と"FPS(avg.)"が違っています。
ここで書かれているFPSはキャプチャーウィンドウの"Status"の"FPS(max/current)"ではなく、"Frames captured"を"Duration"で除した値です。
キャプチャーボタンを押す度に保存フレーム数が変化してしまうということになります。
実際には、撮影中の"Captures/Saved"を監視していると、コンスタントに上昇する筈のフレーム数が時々停止してしまうのが確認できます。
その際"Captures/Saved"のすぐ下に表示される"RAM"の残りMBがどんどん小さくなって、0に達すると保存作業が止まってしまいます。

FireCaptuer_Use-RAM-Buffer-Settings.jpg
 夜中気になって、室内でチャプチャー実験を行いました。
ASI290MMと290MCを同時に起動して、タスクマネージャーでCPU、メモリ、ディスク(SSD)の動きを見ながらキャプチャーを実行すると、メモリにもCPUにも余裕があるのにやはり"Captures/Saved"が示す保存フレーム数が時々停止して、思うように伸びません。
 色々と調べ回って、"Settings:General"の"Use RAM Buffer(experimental !)"に行き当たりました。
こんな設定が以前のバージョンからあったかな?
"experimental !"と書いてありますので、V2.6で試験的に導入された物らしい。
「RAMにまだ余裕がるのに仮想メモリの設定だったら意味が無いなあ」と思いながらもチェックを入れて適当にサイズを設定(512MB)しました。

ASI290MC_1000x1000_60sec.jpg
 オオッ ・・・ 問題が完全に解決しました。
途中で"Captures/Saved"が停滞することも無く、毎回コンスタントなフレーム数が保存されることが確認できました。

 これにチェックを入れると"Status"の"RAM"MBは現在のキャプチャー画像の"Buffer"framesに変わります。
更にUSB Trafficとの関連を調べるため、40~100まで変化させてキャプチャーしましたが、どれもフレーム数には変化が少なく安定していました。
そして再度"Use RAM Buffer(experimental !)"のチェックを外すと、"Captures/Saved"の単位は"MB"に戻るのですが、キャプチャー中に0MBに達することが無くなり、安定してキャプチャーが進行するように変化しました。
うーん、何かが変わったようですが ・・・ 心配なのでチェックを入れておきます。
 いやーっ、メデタシ!
これで4年も頭を抱えていた問題が解決しました。
試しにASI290MMと290MCをクロップ(1000x1000)で同時キャプチャーを実行してみましたが、私の現在のPCシステム構成ではCPUにもメモリにも余裕があり、キャプチャーフレーム数も安定していました。
勿論、フリップミラーを使っているので2台同時撮影はあり得ませんね。( 調子に乗り過ぎ)勿論、フリップミラーを使っているので2台同時撮影はあり得ませんね。( 調子に乗り過ぎ)


※RB星さんからコメントを通して新情報を頂きましたので、追加テストの結果を追記します。

RB星さんはFireCaptureで以下のように設定してキャプチャー速度を上げられているとのことです。
Setting:General
Misc→ Performance→ Force aggressive memory recovery during captureにチェック
Settings_Performance.jpg
 早速、私が効果的と書きました"Use RAM Buffer(experimental !)"のチェックを外してから"Force aggressive memory recovery during capture"にチェックを入れ、念のためPCを再起動してから同様のテストを行いました。
その結果は以下のようになりました。

FireCaptreのキャプチャー速度改善方法_RB星
 凄いですねえ。
"Use RAM Buffer(experimental !)"のチェックした場合に比べて約1.5倍(FPS=54~57)に向上しました。
ただ同上のチェックを外したためか"Status"の"Buffer"が"RAM"に変わって100~200MB程度になり、キャプチャー中に100MB以下に下がることもありました。(0MBになって止まることはありませんでしたが)

FireCaptreのキャプチャー速度改善方法_RB星_VC
 そこで"Use RAM Buffer(experimental !)"のチェックも復活して1024MBに設定してからPCの再起動かけてテストした結果が上記です。
ファイルは前記のテスト分を含んでいます。
タイムスタンプが14:59以降が"Use RAM Buffer(experimental !)"と"Force aggressive memory recovery during capture"の両方にチェックを入れてキャプチャーしたファイルです。
結果は更に向上して"Use RAM Buffer(experimental !)"のチェックだけの1.7倍近く(FPS61~64)になりました。
尚、私のテストは以下の条件で行いました。
1) FireCapture v2.6.08 x64
2) ASI290MMとASI290MCの2台起動
3) ASI290MCでキャプチャー
4) ビデオフォーマット=SER
5) Exp.(ms)=15.00
6) ROI=1000x1000
7) Limit=60s
8) PCのシステム構成→このページの第2画像参照
9) ストレージ→KIBGSTON SV300S37A240G SCSI Disk Device

 記事を書いてからほんの僅かの時間に頂いたRB星さんの情報で、これまで抱えていた問題が解消しました。m(_"_)m
これで今晩から気持ちよく惑星撮影が出来ます ・・・ 晴れればですが。
プロフィール

voyager_camera

Author:voyager_camera
小惑星観測屋崩れの三流天体写真家です。もう新天体サーベイも位置測定もしませんので、鑑賞天体写真撮影に努めています。天文雑誌などのフォトコンには怖くて応募しませんが、このブログ以外でも写真を見ていただける機会が増えるようボチボチやってます。(大島 良明)
mail:y-osima@r.sannet.ne.jp

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

この人とブロともになる

QRコード
QR