★先日来、気になっていたこと
横軸はピクセルＮｏで、縦軸がバイアス出力値（光電子数に変換済）です。
ASI294MC-Proの謎解きシリーズ第5弾ですが、今回は先日来気になっていたバイアスノイズ分布の「形」解明の糸口を探ってみます。
本来、バイアスノイズが正規分布に従っているとすると、その輝度分布グラフを片対数グラフで表すと、理論上は上に凸の放物線が描かれるハズです。
ところが実際のグラフは、下記のように放物線よりも裾野が広がってしまってます。
★２つの仮説
この一見奇妙な現象について、２つの仮説を立ててみました。
＜仮説①＞バイアズノイズの発生源が２種類ある
発生源というよりは発生タイミングと言う方が適切かも知れませんが、要するにゲインアップによる増幅が成される前後に２種類のノイズが発生しているのではないかという仮説です。これは、上記のノイズ輝度分布グラフにおいて、『裾野のピーク』が『全体のピーク』とズレていることから思いついたことです。
試みとして、平均値と標準偏差が異なる２種類の正規分布を仮定してシミュレーションしてみると、下記のようになかなか興味深い再現度を示します。
＜仮説②＞性質の異なる２種類の素子が混在している
これはピクセル毎にその特性が異なっており、いわばバイアスノイズが少ないピクセルと多いピクセルが混在しているという仮説です。これまでのバイアスノイズ推算に関しては、１コマのバイアスファイルに展開する全ピクセルごとの輝度がどのようにばらついているのかを統計したものであって、いわば『空間的ノイズ』と表現できます。しかし、これとは別に撮影フレームごとに輝度が変動する効果も存在しているべきで、こちらはいわば『時間的ノイズ』とでも言えましょうか。
前者の場合は他のピクセルよりも高輝度（あるいは低輝度）であるピクセルが展開していればバイアスノイズの標準偏差が大きくなるように寄与するはずですが、実はこれは『良性のノイズ』であって、十分にコンポジット枚数を稼いだバイアスファイルやダークファイルで殲滅できることが期待されます。
それに対して後者の場合は厄介で、バイアスやダークの減算では対処できません。
★個々のピクセルはどのような輝度変化をしているのか？
ここまでに行った『解析ごっこ』では１コマのバイアスフレームだけを扱っていましたが、個々のピクセルがどのように時間的変化をしているのかを調べて見ることにしました。
ゲイン120で撮影したバイアスフレーム128コマ分について、同じ場所のピクセルを各500個抽出し、それぞれのバイアス出力分布を拾ってみました。
横軸はピクセルＮｏで、縦軸がバイアス出力値（光電子数に変換済）です。
ここではＮｏ３４０～５００のピクセルについてプロットしましたが、それぞれのピクセルによって、その輝度平均値が異なるだけでは無く、輝度値の散らばり方も異なる事が分かります。
要するに、バイアスについては『明るすぎるピクセル』と『暗すぎるピクセル』と『明滅するピクセル』が混在していることが推測できますね。
では、その中でも「平均輝度が似ているにも関わらず、そのふらつきが異なる」例をお見せしましょう。
ででん！！
出力値はそれぞれ光電子数に変換済みです。
どちらのピクセルも平均出力が約122ですが、その標準偏差が約1.4と約9.8というようにまるで異なります。下の様な特性を持つピクセルに関しては原理上、単純なバイアスファイル減算だけではノイズ除去できそうにありませんね。そもそもバイアスファイル（やダークファイル）の減算で除去できるのは「ピクセル間の平均輝度差」であって、個々のピクセルの輝度値がふらつく影響は回避できないからです。こちらについてはコンポジットによってのみ軽減できると言えそうです。
★平均輝度と標準偏差の間に相関はあるか？
さて、冒頭のバイアス輝度分布図では『裾野が広がっている』という傾向が見られました。
これがピクセルごとの差異だと仮定すると平均輝度ごとに標準偏差が異なることが予想されます。
今度は、これについてチェックしてみましょう。
★さて・・・・と
なんだか調べれば調べるほど色々と謎が深まりますが、これ以上立ち入るには（Delphiで書いた）現有の解析ツールでは少々力不足です。
今後、コンポジットした場合やバイアスファイル減算などをした効果も調べたいのですが、ステライメージで画像処理した後だと（データと同じ16bit整数型で保存しても）上手くロードできないのですね。ま、単に私が書いたコードがＺＷＯのＡＳＩシリーズに特化されすぎていて汎用性が低いのが原因ではあるのですが、このままだとバグ取りだけで何ヶ月もかかってしまいそうです。それになにより、実行速度が遅すぎて、大量のファイルをさばくのには限界が・・・・。
・・・・というわけで・・・・
今度は、ぱ・・・Pythonだと？？
タグ：
出た！Python！ （全体に難しかったので、ここしか反応できない）Pythonは、SharpCapでいじっただけですが、いろんなライブラリがそろっていて面白そうですね。実行速度はDelphiより速いと期待できるのですか？ 楽しみ、楽しみ。
Like
Commented
by
是空
at 2019-02-12 18:16
x
右に同じく、難しくて反応が・・・
何をして、どういう結果がでているというのを追うのが精いっぱい。
この「何して」が「何のために」がうまく結びついてこない。
たぶん、次回以降で次第に明らかになってくると思うので、必死についていこうと思う。
にしきへびに負けてたまるか。＾＾
何をして、どういう結果がでているというのを追うのが精いっぱい。
この「何して」が「何のために」がうまく結びついてこない。
たぶん、次回以降で次第に明らかになってくると思うので、必死についていこうと思う。
にしきへびに負けてたまるか。＾＾
at 2019-02-12 22:28
> にゃあさん
本来はコンパイラであるDelphiがインタープリタであるPythonに負けるわけがないのですが、素人が書くアルゴリズムと専門家が書いたライブラリーの差が出ちゃった感じでして、読み込み速度が数十倍になりました。
解析ごっこと同時進行で、本来やりたかった諸々の試行に突入です♪
本来はコンパイラであるDelphiがインタープリタであるPythonに負けるわけがないのですが、素人が書くアルゴリズムと専門家が書いたライブラリーの差が出ちゃった感じでして、読み込み速度が数十倍になりました。
解析ごっこと同時進行で、本来やりたかった諸々の試行に突入です♪
> 是空さん
今やってる『解析ごっこ』は、単なる基礎研究遊びなので、結果を見て新たな活用法を考案しようと思ってます。
そう遠くない日に、昨日思いついた『ボラーチョ・マッピング法』（仮称）を構築できる・・・かなぁ？
というわけで、当分の間はニシキヘビと格闘します。
今やってる『解析ごっこ』は、単なる基礎研究遊びなので、結果を見て新たな活用法を考案しようと思ってます。
そう遠くない日に、昨日思いついた『ボラーチョ・マッピング法』（仮称）を構築できる・・・かなぁ？
というわけで、当分の間はニシキヘビと格闘します。
Commented
by
noritos1047
at 2019-02-13 04:20
x
Python=ニシキヘビね。
う〜ん、諸先輩方は遠くに行ってしまわれたようなので、初心者はいい場所にいるけど思うように撮れない「かに星雲」のガイド付き撮影に挑戦することにしました。
基礎研究、いい活用法が出たら、美味しいところだけ拝借します。
世の中、難しいことがいっぱいなのね。
う〜ん、諸先輩方は遠くに行ってしまわれたようなので、初心者はいい場所にいるけど思うように撮れない「かに星雲」のガイド付き撮影に挑戦することにしました。
基礎研究、いい活用法が出たら、美味しいところだけ拝借します。
世の中、難しいことがいっぱいなのね。
> noritos1047さん
ニシキヘビ、これをマスターするとSharpCapを自己流にアレンジできたり、既存の膨大なツールが利用できたり、色々と面白いことができるのだけれど『流行りもの』が嫌いな天の邪鬼あぷらなーとは避けてきたんですよー。でも、そろそろ限界っぽいので観念する事にしました。
ともかく、ようやくノイズの本質（？）が見えてきたような気がします。
ニシキヘビ、これをマスターするとSharpCapを自己流にアレンジできたり、既存の膨大なツールが利用できたり、色々と面白いことができるのだけれど『流行りもの』が嫌いな天の邪鬼あぷらなーとは避けてきたんですよー。でも、そろそろ限界っぽいので観念する事にしました。
ともかく、ようやくノイズの本質（？）が見えてきたような気がします。
Commented
by
kem2017
at 2019-02-15 03:25
Python (^o^)
見た目は大切ですよね
見た目は大切ですよね
> kem2017さん
とにかくPythonは、「すぐに使える」部品がたくさん用意されててビックリ。
上手く組合せれば、本来やりたかった事が実現できるかもしれません。
まあ、気の長いお話ではあるのですが。
とにかくPythonは、「すぐに使える」部品がたくさん用意されててビックリ。
上手く組合せれば、本来やりたかった事が実現できるかもしれません。
まあ、気の長いお話ではあるのですが。
