★ずっと感じていた『不快感』
※左:ダークファイル20コマのコンポジット
見づらいのでさらに拡大すると・・ ※左:ダーク減算なし 中:オートでダーク補正 右:マニュアルでダーク補正
冷却CMOSカメラはその温度を低下させることによってダークノイズ自体を低減させるとは言え、星雲などを炙り出そうというレベルの画像処理においては、まだまだ大量のダークノイズが邪魔になります。そこで、暗闇で撮影したダークファイルを減算することによりノイズを消すのが常套手段なのですが・・・・。
ええと・・・画像処理の下ごしらえとしてステライメージのバッチ処理で「ダーク補正」を行った際に、ですねぇ・・・「ダークノイズが取り切れてない」感がするってことありませんか?
さて、前回のエントリーで、(過去に構想しつつも実行に移せていなかった)「ダークファイルのみを加工して」ノイズの挙動を『考察ごっこ』するという手法をついに実行しました。その結果、輝点ノイズに起因する『縮緬ノイズ』がディザリングを用いることで目立たなくなることを検証できたのですが、そもそも(原理的にダーク減算でもフラット除算でも消せない)クールピクセルに起因する『縮緬ノイズ』はともかく、輝点ノイズ(ホットピクセル)に起因する『縮緬ノイズ』が出ること自体が気色悪いんですよねぇ。・・・だって、原理的にこれはダーク減算で消せるハズじゃないですか。・・・でも実際は消しきれない・・・と。
いや、ちょっと待て!
そもそも、ダークファイルのノイズ画像自体をダークファイルで消せるのか?
いえ、笑い事ではありません。これって、ダークファイル自体をダークファイルで減算するようなことで、あまりにも「消えてあたりまえ」すぎて誰も検証したことなかったりして・・・・。
★やってみた♪
ASI1600MC-Coolで過去に撮影したダークファイルを使って『検証ごっこ』開始♪
ちなみに、このときの撮像データは下記の通り
[ZWO ASI1600MC-Cool]
Debayer Preview=Off
Pan=0
Tilt=0
Output Format=Fits files (*.fits)
Binning=1
Capture Area=4656x3520
Colour Space=RAW16
Hardware Binning=Off
High Speed Mode=Off
Turbo USB=80(Auto)
Flip=None
Frame Rate Limit=Maximum
Gain=400
Exposure=15
Timestamp Frames=Off
White Bal (B)=99
White Bal (R)=63
Brightness=10
Gamma=50
Temperature=-14.8
Cooler Power=30
Target Temperature=-15
Cooler=On
Auto Exp Max Gain=300
Auto Exp Max Exp=30
Auto Exp Max Brightness=100
Mono Bin=Off
Subtract Dark=None
Display Brightness=1
Display Contrast=1
Display Gamma=1
さて、今回の『検証ごっこ』は愛用のステライメージ6.5で行いました。
①同じ条件で撮像した20コマを位置合わせ無しで加算平均コンポジットしたものをAとします。
②Aを共通ダークファイルに指定し、コンポジット前のダーク画像20コマそれぞれにダーク補正バッチ処理を加えます。
③ダーク減算処理済みの20コマを位置合わせ無しで加算平均コンポジットします。
さて、どうなるでしょう??
え?
「そんなもの、全部消えて当たり前だろ!」
ですか?
まあまあ、そう言わずにもう少しおつきあいくださいな。
いきますよー。
ででん!
右:ダーク補正済みのダークファイル20コマのコンポジット
意外ッ!
ダークファイルがダークファイルで消えないッ!!
なんというパラドキシカル(逆説的)な現象(笑)
(余談:ま、本業で教えている入試現代文なら「ダークファイルがダークファイルで消えない」には傍線を入れて、どういうことか?と問いますね。絶対。)
ええ、確かに相当に軽減されてはいます。でも、そもそも『実体が同じ物』なんですよ?。もっとバチッと消えて良さそうじゃないですか。
★一体どういうことなのだ??
なんだか狐に化かされたような気分ですが、気を取り直して原因を邪推してみましょうか・・・。
仮説①「フラクチュエーションとスレッショルドの喧嘩」説
個々のダークにはフラクチュエーション(揺らぎ)がある。そこに何らかのスレッショルド(閾値)が作用した結果、数学的には「個々の値から平均を引いたもの」の合計はゼロのハズだが、実際にはゼロにならない。
仮説②「ソフトウェアのロジック上の問題」説
いつもステライメージ6.5のバッチ処理でダーク補正を行っているが、それは「きちんと処理されているだろう」という盲信に基づいており、そのロジックを知らないため、なにか意図せぬ不具合が起こっている。
仮説③「パラメータの設定ミス」説
そもそも16ビット整数型の撮像ファイルに32ビット実数型のダークファイルを演算させて大丈夫なんだろうか?
(※一応、マニュアルにはそうするように指示されてはいます)
勘違いして欲しくないのですが、決してステライメージにケチをつけているわけではありません。
単にあぷらなーと自身が仕様やロジックを理解していないだけのお話です。
★困ったときの手作業
ブラックボックス化された自動処理が不安になったときは『マニュアル』に切り替えればよろしい♪
ほら、高度なテクノロジーを駆使した超兵器を扱う映画などでも、ピンチを切り抜けるときはたいてい手作業じゃないですかー(笑)
というわけで、ステライメージ6.5を用いて「マニュアル操作でダーク補正」する方法を考えてみた。
①20コマコンポジットした共通ダークファイルを読み込む
②素のダークファイル1枚を読み込む
③ワークフローに②のファイルから①のファイルを減算する操作を記憶させる
④バッチ処理で20コマのダークファイルそれぞれに③の演算を実行し保存する
⑤④で生成されたファイルを加算平均コンポジットする。
ま、理論的にはフルオートと同じハズなんですが・・・・。
すると・・・
ででん!!
※左:ダークファイル20コマのコンポジット
中:ダーク補正済みのダークファイル20コマのコンポジット
右:マニュアル操作でダーク補正したダークファイル20コマのコンポジット
げげっ!
ぜ、全然違うやんかー!
・・・てことは、
無精してフルオートに任せず、真面目に手作業でダークを引けば画質が改善するかもしれないってこと??
★実写画像で試してみる
9月に『三連装にせBORG』で撮影した北アメリカ星雲のHα画像(ASI1600MM-Pro)にこの手法を適用し、差異が出るかどうか試してみます。
あ、ついでにもしもダーク減算を行わなければどれだけ悲惨なことになるかも再確認しておこう♪
では行きますよー
ででん!!!
※左:ダーク減算なし 中:オートでダーク補正 右:マニュアルでダーク補正
左のダーク減算無しは論外(0℃冷却でも炙るとこんなに盛大なダークノイズが・・・これディザリングでも消せないかも?)として、中と右をよく見比べると明らかに右の方がホットピクセルが良く消えてます。
まあ、過補正っぽい黒いノイズも出てはいますが、こんなのクールピクセル除去フィルタや必殺『クールファイル補正法』で退治できますし。
★ん?これって、もしかして・・・
「オフセット」(SharpCapで言うところのブライトネス)ってこれまで意識してなかったけれど、もしや、そういうことなのか??
(撮影時はもちろんのこと、ダーク減算などフラクチュエーションに起因する負の値が発生しうる際には注意が必要的な・・・・)
5が平均値の各データが[2,5,8]だったとして、演算ルールに「0以下の値はカット」という条件を加えた場合、
「((2-5)+(5-5)+(8-5))÷3 が 0にならない」っていう類いの・・・・。
★★★以下たぶん続きます♪(台風25号のせいで)★★★
Commented
by
supernova1987a at 2018-10-07 15:43
あれれ?
なぜかコメント欄が無効になってました。
10/7 15:40現在、正常に戻ってます。
ご迷惑おかけしました。
by あぷらなーと
なぜかコメント欄が無効になってました。
10/7 15:40現在、正常に戻ってます。
ご迷惑おかけしました。
by あぷらなーと
0
by supernova1987a
| 2018-10-04 06:49
| 解析ごっこ・検証ごっこ
|
Comments(1)