★本体だけで楽しむというのもアリ
念願の新兵器：ASI294MC-ProとM-GENを入手したものの、まだまだ本格運用にはほど遠い現状です。
まあ、お休みの前夜に快晴になる確率は低いので仕方ありません。
でも（ASI1600シリーズの時もそうでしたが）当面は、『ASI294MCの謎』と題して色々と『検証ごっこ』して遊んでみることにしましょう。
★『解析ごっこ』にあたって
モノクロカメラと異なり、カラーカメラの特性を調べて遊ぶ際に最大の障害となるのは「R/G1/G2/B」の各チャンネルを分離しないといけないことです。
幸い最近のSharpCapにはSamさんが言及されているように
カメラの特性を自動でチェックしてくれる素晴らしい機能が実装されていますし、撮影したときに自動的に色毎の輝度分布データがCSVファイルで吐き出してくれます。
ただ、あぷらなーとは理系能力をすでに喪失しているので、自分の手を動かして調べて見ないと「何が起こっているのか」が釈然としないんですよぉ。ははは。
というわけで・・・・
★輝度データの解析方針
面倒くさいんですが、そこがまた良いんですよねぇ・・・泥臭い『解析ごっこ』は。
とりあえず、
①FITSデータから輝度データの集計はDelphi10.1を用いて自分で書いたコードを用いることにします。
以前、ASI1600シリーズの謎解きで使ったコードの改修版ですね。
自前のコードですから、いくらでも解析プロセスを盛り込めるのですが、バグを見つける度にコンパイルし直すのは難儀なので、今回は欲張らず「チャンネル毎の輝度分布データ集計」以外の機能は切りました。
②視覚化や各種統計処理はEXCELを用いることにします。
途中の過程がセルの値として見えるのが嬉しいですし、最近のPC環境だと数万件程度のレコードならEXCELで楽勝ですものねぇ。
★解析の前提条件
ちゃんとした測定装置がある訳ではありませんし、もともとメカやエレキに弱い性格なので、下記の点は大前提としました。
①ASI294MCのユニティゲインは117である
②ASI294MCのFITSファイルは16bit整数で出力されている
③FITSファイル中の数値は補数表現を用いてBigEndian形式で書かれている
④カメラ本体以外に起因するノイズは考えない
★キャリブレーション代わりに・・・
とりあえず、致命的なバグが無いことを確かめるために、いくつか予備テストを行ってみましょう。
＜テスト＞SharpCapが吐き出した輝度分布データと一致するかどうか？
横軸は素の出力輝度値で、縦軸はイベント数（ヒットしたピクセル数）です。
一見ずいぶん違いますね。大局的には
①横軸（輝度値）がズレている
②縦軸（イベント数）がズレている
まずは、この『謎』を解き明かすとしましょうか。
★出力された輝度分布の数値を比較する
いえ、慣れた人ならグラフ見て一発で気付くんでしょうが、現在のあぷらなーとには無理っす。
というわけで数値自体を見てみましょう。
さて、これらを見比べると、まず気づく大きな違いは「隙間」の有無です。
自前コードの方は有効な輝度値が全て４の倍数限定になっています。これは、本来14bitでAD変換したASI294MCの撮像データを16bitFITSに書き出す際に生じた『水増し分』の隙間と解釈できます。つまり16bitと14bitの差である2bit分の隙間を入れて16bit空間全体に輝度を『散らして』いるという訳ですね。なぜこんな面倒くさいことをやっているかというと、素の輝度では16bitの階調のうち低輝度側1／4にしかデータが無いことになり（例えサチるほどの露光量であっても）露光アンダーの画像になってしまうからだと推測されます。
一方、SharpCapが出力したデータの方は、この「隙間」がありません。つまりデータを16bit空間にあえて散らさずに集計していると推測されます。
では、自前コードが出した輝度を４で割れば一致するか確かめてみましょう。
ここで、良くデータを見ると、そもそもSharpCapが吐き出した輝度分布データのCSVファイルは輝度の上限値が4095になっていることに気がつきました。
この数値に０も加味するとちょうど12bitになりますね。
要するに、SharpCapの輝度分布データは14bit機であるASI294MCであってもASI1600等と同様に12bitで統計しているということが推測されます。
では、自前コードの輝度値を12bitにまとめるために４で割ってみましょう。
でもよく見ると縦軸方向が一致しませんね。・・・ここまできて猛烈なデジャブが襲います。
これは・・・大昔理系だった頃に見た気がする症例・・・ええと・・・なんだったっけ・・・・
そうだ！！「bin幅」が違ってるんだー！
えへへ。
いやはや低レベルのお話ですみません。統計処理をするときに広い幅(bin幅）で統計した場合はその階級に入るイベント数は増えて当然・・・ってだけのお話です。
これを補正してみると・・・
ででん！
※正確にはまだ一致していませんが、これは４つの階級を集計せずに、単純に4倍したからです。
というわけで・・・・。
本日分かったことは・・・・
①ASI294MCは14bitでAD変換した値を16bitに散らして出力している
②SharpCapの輝度分布集計は14bitでAD変換した値を12bitに圧縮して出力している
③自前の解析コードのバグは治ったらしい♪
でした♪
★★★以下（出撃不能な状況である限り）つづきます★★★
Commented
by
kem2017
at 2019-01-28 20:12
メカやエレキに弱い人は、絶対エンディアン変換とか言わないと思うに一票
Like
メタリカとエレキが好きな人がここにいますよん。エイドリアンと言えば、ヴァンデンバーグ。あぁ、コメント欄を汚してしまってスミマセン...orz
Commented
by
noritos1047
at 2019-01-28 22:24
x
Commented
by
是空
at 2019-01-28 22:32
x
最近ある人がダイナミックレンジについてYoutubeで説明してました。
その内容を要約すると、
感度はほぼ受光素子の有効面積で決まり、ダイナミックレンジはフルウェルキャパシティで決まる。
と、いうもの。（あくまで私の理解）
私もその通りだと思っているのですが、以前からダイナミックレンジに関して文系の頭で色々考えていると変な疑問がたくさん湧いてくるんです。
今回の「解析ごっこ」ですが、なんかその疑問を解決するヒントみたいなものが出てきそうな予感をヒシヒシと感じている。
少しでも疑問が解決できればいいなぁ。と思ってる次第。
前回の内容の「輝度の単位と光電子数」の違いがうまく理解できない。＞＜
輝度の単位は光電子数と対数の関係だということであってます？
※難しいようであれば説明不要です。すでにある多くの疑問の中にしまっておき、何かのきっかけで解決できればと。
その内容を要約すると、
感度はほぼ受光素子の有効面積で決まり、ダイナミックレンジはフルウェルキャパシティで決まる。
と、いうもの。（あくまで私の理解）
私もその通りだと思っているのですが、以前からダイナミックレンジに関して文系の頭で色々考えていると変な疑問がたくさん湧いてくるんです。
今回の「解析ごっこ」ですが、なんかその疑問を解決するヒントみたいなものが出てきそうな予感をヒシヒシと感じている。
少しでも疑問が解決できればいいなぁ。と思ってる次第。
前回の内容の「輝度の単位と光電子数」の違いがうまく理解できない。＞＜
輝度の単位は光電子数と対数の関係だということであってます？
※難しいようであれば説明不要です。すでにある多くの疑問の中にしまっておき、何かのきっかけで解決できればと。
at 2019-01-28 23:16
> kem2017さん
いやーエンディアン変換とかは、あくまでソフト面なので、やはりハード面には弱いんですよぉ。なにしろ学生時代は『解析屋』さんだったもので・・・。
といっても現在はソフトも強くないんだけれど・・・・。
いやーエンディアン変換とかは、あくまでソフト面なので、やはりハード面には弱いんですよぉ。なにしろ学生時代は『解析屋』さんだったもので・・・。
といっても現在はソフトも強くないんだけれど・・・・。
なるほど～
確かに、ASCOM経由で、冷却CCDソフトで撮像すると、ヒストグラムが歯抜けになっていて、こりゃー、12bit→16bitに伸長してるなーと思ったことはありましたが、
SharpCapだと、逆に、12bitに落とし込んでいる訳ですか・・・(◎-◎;)!!
それでも、32bit実数で保存する場合には何の問題もないのでしょうが・・
マジモンの冷却CMOSは持ってないのですが、CMOSカメラは、ダーク減算に苦労しています。
ダーク撮影時の方が、ベースカウントが上がっていて撮影データを侵食するというかスポイルすることがあるみたいで・・・（要するにダーク減算するとマイナスになるので０に置き換えられちゃう・・・コンポジットー減算ならOkなのかも・・）
まぁ、これは、ダーク取得の環境が悪いかもです（明るくなりはじめてから撮ってるので外気温と漏光が無いとは言えない）
CMOSはBIASに当たる設定も、OFFSETでユーザ委任だし、いろいろとホント、難しい・・・と思ってます。
冷却CCDのセオリーは通じない。あぷらなーとさんの様なしっかりとした解析が必要だと痛感しています・・。
確かに、ASCOM経由で、冷却CCDソフトで撮像すると、ヒストグラムが歯抜けになっていて、こりゃー、12bit→16bitに伸長してるなーと思ったことはありましたが、
SharpCapだと、逆に、12bitに落とし込んでいる訳ですか・・・(◎-◎;)!!
それでも、32bit実数で保存する場合には何の問題もないのでしょうが・・
マジモンの冷却CMOSは持ってないのですが、CMOSカメラは、ダーク減算に苦労しています。
ダーク撮影時の方が、ベースカウントが上がっていて撮影データを侵食するというかスポイルすることがあるみたいで・・・（要するにダーク減算するとマイナスになるので０に置き換えられちゃう・・・コンポジットー減算ならOkなのかも・・）
まぁ、これは、ダーク取得の環境が悪いかもです（明るくなりはじめてから撮ってるので外気温と漏光が無いとは言えない）
CMOSはBIASに当たる設定も、OFFSETでユーザ委任だし、いろいろとホント、難しい・・・と思ってます。
冷却CCDのセオリーは通じない。あぷらなーとさんの様なしっかりとした解析が必要だと痛感しています・・。
> noritos1047さん
ごめんなさい。ちとマニアックな会話が飛び交ってます（笑）
ちなみに「FITSファイル」とは天文のプロが規定した画像ファイル形式の一種で、冷却CMOSカメラや天文画像処理ソフトが吐き出すのはこの形式です。
エンディアン変換は、文化の異なるコンピュータ間でデータをやり取りするときに生じる「読み書きの際の奇妙なルール」です。雰囲気としては「左から読む英語と右から読むアラビア語」の混乱を回避するルールみたいなものです。
ごめんなさい。ちとマニアックな会話が飛び交ってます（笑）
ちなみに「FITSファイル」とは天文のプロが規定した画像ファイル形式の一種で、冷却CMOSカメラや天文画像処理ソフトが吐き出すのはこの形式です。
エンディアン変換は、文化の異なるコンピュータ間でデータをやり取りするときに生じる「読み書きの際の奇妙なルール」です。雰囲気としては「左から読む英語と右から読むアラビア語」の混乱を回避するルールみたいなものです。
> 是空さん
そうですね。最近、どのチップも量子効率が高くなっていますので、「感度」は概ね１画素あたりの面積で決まっちゃいますね。また、ダイナミックレンジは「最大何個の電子を数えられるか」を表すフルウェルキャパシティと最も関連性が高いのも事実です。
ただし、現実にはゲイン（光電子１個を何個の電子に変換して出力するか）を変えたりすると「どれだけの幅の明るさ」を捉えられるのかという意味のダイナミックレンジは異なってきますし、ノイズが増えてくるとノイズ起因の電子がダイナミックレンジを喰ってしまいます。
なお、輝度の単位を光電子（あくまで初動で発生する増幅前の光電子）で表すのは、ゲインによる増幅の影響を排除して公平な比較ができるようにするためです。これによりノイズの評価なら「星の光から生じた１個の光電子に対してどれだけのノイズが邪魔するのか」が評価できます。なお光電子１個から電子１個を出力する「ユニティゲイン」で撮影した場合は「輝度」＝「光電子数」になりますので、先述の変換は、「ユニティゲインの時にどんな明るさになるか」を表しているという解釈も成り立ちますね。
※現実にはもっと複雑なので、上記のお話はあくまでイメージです。
そうですね。最近、どのチップも量子効率が高くなっていますので、「感度」は概ね１画素あたりの面積で決まっちゃいますね。また、ダイナミックレンジは「最大何個の電子を数えられるか」を表すフルウェルキャパシティと最も関連性が高いのも事実です。
ただし、現実にはゲイン（光電子１個を何個の電子に変換して出力するか）を変えたりすると「どれだけの幅の明るさ」を捉えられるのかという意味のダイナミックレンジは異なってきますし、ノイズが増えてくるとノイズ起因の電子がダイナミックレンジを喰ってしまいます。
なお、輝度の単位を光電子（あくまで初動で発生する増幅前の光電子）で表すのは、ゲインによる増幅の影響を排除して公平な比較ができるようにするためです。これによりノイズの評価なら「星の光から生じた１個の光電子に対してどれだけのノイズが邪魔するのか」が評価できます。なお光電子１個から電子１個を出力する「ユニティゲイン」で撮影した場合は「輝度」＝「光電子数」になりますので、先述の変換は、「ユニティゲインの時にどんな明るさになるか」を表しているという解釈も成り立ちますね。
※現実にはもっと複雑なので、上記のお話はあくまでイメージです。
> utoさん
少々語弊があったようなので補足です。
自前のコードで解析している元ファイルも「SharpCapで撮像した画像」なので、SharpCapが12bitに丸めた画像を出力しているわけではありません。
あくまで撮影時に付録としてSharpCapが勝手に吐き出してくれる「輝度分布ファイル」の輝度が12bitに圧縮されているという主旨です。実際の画像は16bitに拡張しているのに輝度分布データが12bitに圧縮されているので、これを把握しておかないとノイズの評価値が16倍もズレてしまう恐れがあり、四苦八苦してたんです。
分かりづらくてごめんなさい。
少々語弊があったようなので補足です。
自前のコードで解析している元ファイルも「SharpCapで撮像した画像」なので、SharpCapが12bitに丸めた画像を出力しているわけではありません。
あくまで撮影時に付録としてSharpCapが勝手に吐き出してくれる「輝度分布ファイル」の輝度が12bitに圧縮されているという主旨です。実際の画像は16bitに拡張しているのに輝度分布データが12bitに圧縮されているので、これを把握しておかないとノイズの評価値が16倍もズレてしまう恐れがあり、四苦八苦してたんです。
分かりづらくてごめんなさい。
Commented
by
是空
at 2019-01-29 15:20
x
丁寧な説明ありがとうございます。
＞※現実にはもっと複雑なので、上記のお話はあくまでイメージです。
もちろんわかってます。色んな要素が複雑にからみあってるのでしょうから。
＞現実にはゲイン（光電子１個を何個の電子に変換して出力するか）～
というのは、すべての数が等倍でゲインされ頭打ちしないのであれば、対数(ｄｂなど)で表せば同じですよね？
最大／最小は同じだと。
自分の疑問の根源は、多分もっとシンプルで(なさけないことに自分の疑問が自分でもよくわかってない)、
たとえば音の場合、記録できる最小の音と最大の音の幅がダイナミックレンジ(そう捉えている)で、かつ再生側の制限がなければ再生も(アンプによる)ゲインにかかわらず最小と最大の幅は対数的に保たれる。と考えている。
が、写真や映像の最終出力(再生側)の最大ってぶっちゃけていうと「白」だと思っていて、フルウェルが10000e-でも65000e-でもAD後にフルビット立った時の出力は同じなんではないかと。(ここが間違い？)
感度(最初の1e-ができる条件)が同じなら表現できる幅も同じになり、異なるフルフェルのギャップは諧調に反映されるだけではないかと思ってるんですよね。
この辺がず～っとモヤモヤ～っと・・・
＞※現実にはもっと複雑なので、上記のお話はあくまでイメージです。
もちろんわかってます。色んな要素が複雑にからみあってるのでしょうから。
＞現実にはゲイン（光電子１個を何個の電子に変換して出力するか）～
というのは、すべての数が等倍でゲインされ頭打ちしないのであれば、対数(ｄｂなど)で表せば同じですよね？
最大／最小は同じだと。
自分の疑問の根源は、多分もっとシンプルで(なさけないことに自分の疑問が自分でもよくわかってない)、
たとえば音の場合、記録できる最小の音と最大の音の幅がダイナミックレンジ(そう捉えている)で、かつ再生側の制限がなければ再生も(アンプによる)ゲインにかかわらず最小と最大の幅は対数的に保たれる。と考えている。
が、写真や映像の最終出力(再生側)の最大ってぶっちゃけていうと「白」だと思っていて、フルウェルが10000e-でも65000e-でもAD後にフルビット立った時の出力は同じなんではないかと。(ここが間違い？)
感度(最初の1e-ができる条件)が同じなら表現できる幅も同じになり、異なるフルフェルのギャップは諧調に反映されるだけではないかと思ってるんですよね。
この辺がず～っとモヤモヤ～っと・・・
> 是空さん
なるほどそういう意味合いでしたか。これなかなかに難問だと思います。基本的には高ゲインにした場合には、ある一定輝度以上が全てカットされた結果階調が乏しくなると思うんですが、実際には意外に差異が無かったりして謎が深まります。とにかく『理屈的にはこうなるハズ』というのがなかなか通用しないので難儀しますね。
のんびりと解き明かすつもりなので、あまり期待せずにお待ちください。
なるほどそういう意味合いでしたか。これなかなかに難問だと思います。基本的には高ゲインにした場合には、ある一定輝度以上が全てカットされた結果階調が乏しくなると思うんですが、実際には意外に差異が無かったりして謎が深まります。とにかく『理屈的にはこうなるハズ』というのがなかなか通用しないので難儀しますね。
のんびりと解き明かすつもりなので、あまり期待せずにお待ちください。
Commented
by
是空
at 2019-01-30 15:23
x
こういう疑問を(無い頭で＾＾；)色々考えるのが、あぷらなーとさんの「ごっこ」と同じで私のお遊びなんですよ。
だからこういった疑問を積極的に解決しようと思っているわけでなく、色んな情報（たとえば、あぷらなーとさんのサイト）から理解の点が線になって面になって行き、その中で疑問が解決していくのが面白んです。
※ レスポンスは不要です。
だからこういった疑問を積極的に解決しようと思っているわけでなく、色んな情報（たとえば、あぷらなーとさんのサイト）から理解の点が線になって面になって行き、その中で疑問が解決していくのが面白んです。
※ レスポンスは不要です。
