ダーク減算処理についての『不快感』の正体②

★先日のエントリーで書いた『不快感』

最近、なんか「ダークファイル補正してもダークノイズって消しきれないよなぁ」と不思議に思ってた件について、自動ダークファイル補正処理に頼らず手動で減算処理すると結構キレイにダークノイズが消えることを見つけたんだけど・・・

直感的に「平均値の差分」と「差分の平均値」が一致してないのが原因ではないかと感じたので、少し『検証ごっこ』してみることに。

★コードを書いてるヒマはないので・・・

ええ、本来ならいつぞやDelphiで書いたFITSファイル簡易解析コードを改修して一気に統計処理すれば良いんだけれど、あのコードあまりに読み込みが遅いのでC＃で書き直そうと思いつつ、まだ着手できてないという・・・（汗）。

でも、今回の件が気になって仕方ないので・・・・

・・・ええい！

こうなったら手動で解析してやるわっ！

はい。

ダークファイル１６コマを全部開いて、特定のピクセルをG1・R・B・G2それぞれのチャンネルから１匹選んで、手作業で輝度変化を調べる・・・という力技を敢行。

これを

　①：ダークフレームそのもの

　②：①をコンポジットして作ったダークファイル

　③：①にダーク補正を加えたもの

　④：③のコンポジット

のそれぞれについて調査するっていう、気の長い作業。

ああー面倒くさいなあ。

なんだか、昔の放射線乾板解析をしている宇宙線物理学者になったような気分（笑）

・・・で、例えばこんなふうに整理

分かります？

要するに、ステライメージ6.5の自動ダーク補正（ファイル読み込んでダークファイルとの減算を一気にやってくれるヤツ）だと、「補正後に負の値になったピクセルデータがカットされてる」んですね。

上の図の補正後輝度値を平均したものが実際の「ダーク減算後に加算平均コンポジットした画像」におけるダークノイズとなるわけだけど、このロジックで行くとダークファイルの値（ダークノイズの平均値）よりも小さなノイズを持つピクセルがサチったようになって、コンポジット時に加味されない・・・・と。

これは定性的には「ダークノイズが取り切れない」方向に作用するので、結果としてダークノイズが残っちゃうんですね。

ちなみに他のチャンネルについても、同様の傾向。

本来各コマのダークノイズ輝度は揺らぎますから、その平均値であるダークファイルを減算すると０を中心として正負各方向にばらつくハズなのですが、そのうち負の方向に分布したデータがバッサリ切られちゃってるわけですね。

それぞれグラフにすると、こんな感じです。

★補正前と補正後の輝度値の相関

では、ダーク補正の前後で輝度値がどのように変化しているかをスキャッタープロットして整理してみましょう。

すると・・・

ででん！

このように自動ダークファイル補正では、ダークファイル減算の前後でダークノイズの平均値をスレッショルド（閾値）としてリニアリティ（線形性）が崩れていることが分かります。これじゃそもそもダークノイズが消える訳がないじゃん！（膨大な量のライトフレームをコンポジットすればこの影響は多少緩和されますが、それでも固定ノイズは原理上取り切れないはず）

※実際にはライトフレームのバックグラウンドがダークノイズの揺らぎを『受け止める』ほど明るければ問題ありませんので、長時間露光した場合は影響が減るかも知れません。

※ダークファイル中のダークノイズの揺らぎはダークファイルを作成する際のコンポジット枚数によっても小さくなりますので、十分な量のコンポジットをしておくことは大前提でしょうね。

これを防ぐためには・・・・

前回のエントリーで試みたように、手動でダーク減算処理をワークフローに保存してバッチ処理するか、撮影時に（ダーク減算で負の値が生じないように）輝度データの底上げをするかの必要がありそうです。

不覚っ！

・・・ディザリングとかに初挑戦する前に、すべきことがあった・・・か。

え？

ひ、ひょっとして・・・

撮影時のオフセット設定（固定輝度値加算）とか、この現象の回避のためだったりして、実は常識なの？？

PS

すっきりしたけど、ある意味ショック。今まで何やってたんだろ・・・ボク。

むうー。しかし・・・なんだ、このデジャブは？？

ああ、そうだ。たしか、学生時代に複数のワークステーション使って大気原子の破砕シミュレーションをやっていた時に、なぜか特定の機体だけ演算が無限ループに陥っていて悶絶。泣きながら調べて見るとIEEE754規格でいうところの非数処理仕様がCPUの種類によって異なってたのを発見した時、ちょうどこんな感じのショックを受けたっけなあ・・・。（０を０で割ったときに、非数とするか、１とするか、０とするかっていうやつ・・・）