あぷらなーと


あぷらなーとの写真ブログ
by あぷらなーと
S M T W T F S
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
あぷらなーと
文系寄りの元理系(?)
「天体」「マクロ」「実験ごっこ」その他諸々の科学写真が大好きな HN:あぷらなーと が いろんな写真ネタをのんびり語ります。あまり気合い入れすぎると続かないので、「ぼちぼち」いきます。
※コメント大歓迎です♪

生息地:香川
カテゴリ
最新のコメント
相変わらず秀逸な記事を量..
by kem2017 at 07:59
わぁー、これがカラーシフ..
by にゃあ at 03:07
> Samさん ありが..
by supernova1987a at 22:46
縮麺ノイズ完全制覇ですね..
by Sam at 22:07
> ゴットハンドさん ..
by supernova1987a at 20:41
美しい~。ノイズの”ノ”..
by ゴットハンド at 20:20
> kem2017さん ..
by supernova1987a at 18:28
お見事! サッポロポテ..
by kem2017 at 16:48
> Te Kureさん ..
by supernova1987a at 13:53
ツィートを拝見して慌てて..
by Te Kure at 09:19
以前の記事
お気に入りブログ

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

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

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



★コードを書いてるヒマはないので・・・
ええ、本来ならいつぞやDelphiで書いたFITSファイル簡易解析コードを改修して一気に統計処理すれば良いんだけれど、あのコードあまりに読み込みが遅いのでC#で書き直そうと思いつつ、まだ着手できてないという・・・(汗)。
でも、今回の件が気になって仕方ないので・・・・

・・・ええい!
こうなったら手動で解析してやるわっ!
f0346040_17164610.jpg
はい。
ダークファイル16コマを全部開いて、特定のピクセルをG1・R・B・G2それぞれのチャンネルから1匹選んで、手作業で輝度変化を調べる・・・という力技を敢行。

これを
 ①:ダークフレームそのもの
 ②:①をコンポジットして作ったダークファイル
 ③:①にダーク補正を加えたもの
 ④:③のコンポジット
それぞれについて調査するっていう、気の長い作業。

ああー面倒くさいなあ。
なんだか、昔の放射線乾板解析をしている宇宙線物理学者になったような気分(笑)

・・・で、例えばこんなふうに整理
f0346040_17353528.jpg
分かります?
要するに、ステライメージ6.5の自動ダーク補正(ファイル読み込んでダークファイルとの減算を一気にやってくれるヤツ)だと、「補正後に負の値になったピクセルデータがカットされてる」んですね。
上の図の補正後輝度値を平均したものが実際の「ダーク減算後に加算平均コンポジットした画像」におけるダークノイズとなるわけだけど、このロジックで行くとダークファイルの値(ダークノイズの平均値)よりも小さなノイズを持つピクセルがサチったようになって、コンポジット時に加味されない・・・・と。
これは定性的には「ダークノイズが取り切れない」方向に作用するので、結果としてダークノイズが残っちゃうんですね。

ちなみに他のチャンネルについても、同様の傾向。
f0346040_17573216.jpg
本来各コマのダークノイズ輝度は揺らぎますから、その平均値であるダークファイルを減算すると0を中心として正負各方向にばらつくハズなのですが、そのうち負の方向に分布したデータがバッサリ切られちゃってるわけですね。
f0346040_18064798.jpg
それぞれグラフにすると、こんな感じです。
f0346040_18191056.jpg

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

すると・・・

ででん!
f0346040_18384343.jpg

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

※実際にはライトフレームのバックグラウンドがダークノイズの揺らぎを『受け止める』ほど明るければ問題ありませんので、長時間露光した場合は影響が減るかも知れません。
※ダークファイル中のダークノイズの揺らぎはダークファイルを作成する際のコンポジット枚数によっても小さくなりますので、十分な量のコンポジットをしておくことは大前提でしょうね。

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

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

え?
ひ、ひょっとして・・・
撮影時のオフセット設定(固定輝度値加算)とか、この現象の回避のためだったりして、実は常識なの??


PS
すっきりしたけど、ある意味ショック。今まで何やってたんだろ・・・ボク。
むうー。しかし・・・なんだ、このデジャブは??

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


by supernova1987a | 2018-10-07 19:02 | 天体写真 | Comments(8)
Commented by にゃあ at 2018-10-07 23:13 x
>分かります?
分かりません(泣)

いつもながらに、すごい分析力と根気ですね。なぜに、そのようなグラフが作れるのか想像を絶します。

過程を理解するのが難しくて、授業についていけない学生のような気分ですが、でも結論だけは、なんとなく理解しました。前回の授業に出てきた最後の数式を徹底的に分析したのが今回の授業ですよね?

適切なオフセット値を求めるにはどうしたらいいのかとか、そのあたりが気になりました。これがまた難しそう(笑)
Commented by supernova1987a at 2018-10-07 23:32
> にゃあさん

たぶん、本来のオフセットは今回の現象を回避する物ではなくて、1電子あたりのシグナルが(山のように)揺らいで分布していて、その裾野を切らないように底上げするものではないかとは推測してるのですが、オフセット値を上げるべきなのかゲインを上げるべきなのか、色々と悩んでいます。あとAD変換のビット数が小さい(荒い)と今回の要因とは別件でダークが消しきれないと推測してます。

あ!ぴんたんさんのFlatAidePROなら一定数値の加算処理がバッチ処理できるんだった!!
Commented by Te Kure at 2018-10-08 08:51 x
む・難しい〜‼︎
ダーク減算なんて試した事も有りません。(汗)
前回のブログでその必要性はよく分かりました。

で、今回のと合わせて勉強しますと、おまかせのダーク補正ですとある輝度(閾値)以下のホットピクセルが残ってしまうとの理解でよいのでしょうか・・?
Commented by kem2017 at 2018-10-08 13:54
デジャブ...
エンドユーザが開発元より詳しいので、まったく歯が立たないプロジェクト...
Commented by supernova1987a at 2018-10-08 15:56
> Te Kureさん
いずれもう少し詳しく考察ごっこしてみますが、いわゆるホットピクセルって点灯しっぱなしじゃなくて不規則に点滅してるっぽいんですが、その点灯頻度が少なく、かつ点灯時の輝度が高いと、輝度ノイズが残っちゃうと予想しています。
ってことは、平均じゃなくてメジアン使えば軽減するのかも。
Commented by supernova1987a at 2018-10-08 16:05
> kem2017さん

開発元よりも詳しいエンドユーザー、それは恐ろしすぎる!
そういえば、昔、専門家の先生方を集めて全く畑違いの講演をさせられたことがあって、もう、背中が冷や汗でびっしょり・・・。頼むから質疑しないでっていう。

ちなみに私はヘタレなので(本業以外では)文句言わない善良なエンドユーザーのつもり♪
Commented by せろお at 2018-10-08 21:56 x
ど素人には自動処理しか手が無いので、
その自動処理に不具合があると困りますぅ。
って事で開発元に突貫してください!(笑)
Commented by supernova1987a at 2018-10-08 22:39
> せろおさん
いやー。私も素人なので、ブラックボックス化された処理工程があると、それを『信じる』しかないので期待通りの動きをしていないとパニクります(笑)。

一応今回の『検証ごっこ』でおおよそのロジックが分かってきたので対処法は編み出せますね。前回のエントリーで書いたマニュアル操作でダーク減算のバッチ処理を組む方法だと、演算開始前に「0以下の値を切り捨てる」のチェックを外すことができるんですよー。これでおそらく解決♪

またダークフレームをコンポジットしてダークファイルを作成するときに単純な加算平均ではなくてシグマクリップとか中央値とかを使えば軽減できると推測してますが、これ演算時間が膨大にかかっちゃうのでステライメージ6.5の『爆速コンポジット』のメリットが消えちゃうっていう・・・(泣)

開発元に突貫・・・おお、恐れ多くてヘタレな私には無理っす。
でも、でも・・・せめてステライメージの次期バージョンで、6.5に備えられていた『爆速コンポジット』仕様を復活してくれたら速攻で買いますよー、とだけ言いたい(小声)。
名前
URL
削除用パスワード
<< ダーク減算処理についての『不快... ダーク減算処理についての『不快... >>


検索
タグ
最新の記事
記事ランキング
ファン
ブログジャンル
画像一覧
外部リンク