ASI1600MC-COOLの謎③

★最新のDelphiでは

以前使っていたDelphiから１０年以上が経過していますので当然進化しているのですが、細かいことでちょっと感動したのが、エディタのブロック強調表示機能。
昔、印刷したソースコードを読む時に、どこからどこまでが１ブロックなのかを見やすくするため、よく手書きで線を入れていましたが、最近のエディタは賢いのですね。なんと、勝手にブロックを認識して線を引いてくれるとは！
近年プログラミングから完全に遠ざかっていたので、びっくり。これだけでもバグが減りますね。「Delphiリハビリ」中の身としてはありがたい♪



★読み取り段階で致命的ミス

前回、まさかのBigEndianで記録されていることが発覚したASI1600MC-COOLのFITSデータですが、よく見ると輝度分布が変なことに気づきました。
ベイヤーFITSから、RGBそれぞれの素子についての輝度データを分離して読み出すところまでは成功したのですが、幅広く分布を見るために対数表示させてみると
ぎゃー！
これ、絶対にバグってますよね。ちょうど３万２千あたりでどの色も不連続になっているのが分かります。
あ〜あ。完全に「見切った」と思っていたんですが、甘かったようです。

グラフをよく見ると、左半分のトーンカーブがちょうど左右逆転してるような印象。
ベイヤー画像を表示させると所々諧調が反転してるように見える現象が起こっていたのは、これが原因のようです。



★そもそも符号付き１６ビット整数とは・・・・

よくよく調べてみると、そもそも符号付き16ビット整数の値は、そのままの値ではなく２の補数表現で記録されていることが判明（汗）。・・・これはもう、「FITSがどうのこうの」という以前の根本的な勘違いでした。

まず正の数、これは普通に記録されているだけです。

ところが、負の数は、次のような手順で記録されていることが分かりました。

　①絶対値をとる

　②絶対値を普通に２進数で表す

　③最上位ビットに０を記録する

　④全ビットの数値を反転（０は１に、１は０に）させる

　⑤１を加算する

したがって、ASI1600MC-COOLが出力した値から３２７６８を引いた数値はそのまま記録されるのでなく、さらに補数表現に変換されているというわけです。

たとえば、１３２９８という輝度データは、BZEROシフトで－１９３８０と変換された後、さらに補数表現変換して４６１５６と記録されているのです。

こ、こんなん思いつかんわ～！！（泣）

★というわけで、読み込みのロジック考え直し

というわけで、今度こそ正しい値を読めるようにロジックを考え直します。

変な汗をかきながら（笑）すっかりアホになっている頭で計算した結論だけを書くと、

＜前回までに考案した『誤り』ロジック＞
最上位ビットが１なら上位バイトから１２８を減じたのち符号反転
下位バイトについても符号反転

＜今回修正した新ロジック＞
上位バイトについて、最上位ビットが１なら２５６を減じるのみ

下位バイトはそのまま

たった、これだけで復元できることが分かりました。

興味のある人はあんまり居ないかもしれませんが、前回「大ウソ」を書いちゃったので、流れを載せておきます。

★今度こそ！！

早速、読み込みプログラムに上記のロジックを実装して走らせてみます。

おお、ブラボー！！
見事につながった♪

たぶん、これで大丈夫でしょう。ベイヤー表示もウソのようにきれいになりました。




★ASI1600MC-COOLの新たな謎

さて、12ビットでADCを駆動したASI1600MC-COOLはデータを吐き出すときに16ビットに変換しているのですが、いったいどのように変換しているのでしょう？

　○４ビット分は空データ？
　○16ビットの空間に「散らす」？
　○それとも何らかの形で「補完」してる？
　○色チャンネルによって差はある？

こればかりは、ステライメージでトーンカーブ見て（グラフが荒すぎて）分かりません。

・・・で、１ステップごとに輝度分布が見れるようなコードを書いて、RGB各色ごとに解析してみた！

★★★以下続きます★★★