ASI1600MC-COOLの謎①

★ASI1600MC-COOLの『謎』

ZWO社の冷却CMOSカメラASI1600MC-COOLは、とにかく『謎』が多いですねぇ。同じカメラを使っているユーザーさんと色々情報交換させていただいているのですが、皆さんお悩みのようで♪

最近無謀にも始めたDelphiでの『開発ごっこ』のおかげで、下記の『謎』が判明しそうです。

謎①：ASI1600MC-COOLはどのようにデータを書き込んでいるのか？

謎②：撮影時のパラメータ「HighSpeedMode」の正体は？

謎③：ハードウエアビニングできるのは本当か？

謎④：MMだけではなくMCも赤外線を透過している疑惑

＜お約束＞

以下の考察は、あぷらなーとの独断によるものですので、信憑性があるとは限りません。

誤りが散見するかもしれませんので、あんまり参考にしないでください。

★謎①の解明『ごっこ』

Delphiでゴソゴソとプログラミングしながら、色々調べたりデータ解析してみた結果、およそ次のことが分かりました。

★ASI本体からFITSファイルへの記録方式

そもそもFITSって天体研究者用の汎用フォーマットだったのですね。全然知りませんでした（汗）

○記録された画像データの型は１６bit整数（符号付）です

数値は１６桁の２進数で記録されていますが、注意すべき点は１６桁全てが数値を表しているのではなく、最上位のビットは「符号」を示しているということです。この値が１ならばマイナス、０ならばプラスを示します。そして残りの１５ビットで絶対値を表します。

したがって、位（桁）をiとし、値（０か１）をNiとすると、絶対値はΣ２＾（i－１）*Niで示されます。

これに最上位ビットの値N16を合わせると、符号付きの数値は

（－１）＾N16＊Σ２＾（i－１）：＊Niとなります。

この場合、格納できる数値は【－３２７６８～＋３２７６７】の６５５３５通りとなりますね。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

※１０／３追記

これ、ウソです。確かに上記のような記録法もありますが、FITSはこれとは異なる「補数表現」を使用していることが判明しました。

詳細は、１０／３のブログ↓を参照してください

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

★ここで問題発生！！

FITSの形式では、正の数値は１６bit分ではなく（符号で１bit取られるので）15bit分しか格納できません。

そもそも天体写真では明るさが『マイナス』にはなり得ないので、半分が無駄ですね。

そこで何らかの「トリック」が必要となります。

「トリック」とは、

このように、左にシフトして書き込んでしまうと言う仕掛けです。（よくこんなこと思いつくなあ）

したがって、本来【０～６５５３５】のデータがFITSの中では【－３２７６８～３２７６７】として格納されているわけですね。

★ヘッダにあるBzeroの正体

このような仕掛けがなされているため、FITSファイルから画像データを読み出すときには、素の値に３２７６８を加算してやる必要があります。

というわけで、先日「謎のパラメータ」だと言っていたFITSのヘッダにある第13番目のパラメータ：「BZERO＝３２７６８」の正体は、このシフト量と判明しました。（ああ、たぶんFITSを扱っている人には常識なんでしょうけどねぇ・・・・。）

★CPUのメーカー依存性

Delphiと格闘しつつも、どうもデータがおかしい状態が続いて頭を抱えていたとき、ふと、大昔（２０年以上前）に大学の研究室で「観測データを解析する時に悩まされた」ことを、思い出しました。

当時、宇宙線の観測データを解析する際にハチャメチャな数値ばかりが出てきて半泣きになっていた時に、観測データを記録する際に用いたＰＣ－９８０１ＶＭ（ＣＰＵ：８０１８６）とデータ解析に用いたスパークステーション１０（ＣＰＵ：SuperSPARC）とでデータの記録方式が異なることを知りました。いわゆるＳＰＡＲＣ系のＣＰＵは普通に上の桁から（左から順に）書き込みますが、インテル系のＣＰＵは不思議なことに２バイト（１６bit）のデータを書き込む際に、上位バイト（左の１バイト８bit分）と下位バイト（右の１バイト８bit分）を「逆転」させて記録する仕様だったのです。したがって、インテル系のＣＰＵで記録したデータをＳＰＡＲＣ系のＣＰＵで読むときにはデータを２バイトずつに区切って、上下（左右）を入れ替えないと正しく読めないよ、というお話しです。

★リトルエンディアンとビッグエンディアン

普通通り上位（左）から順に記録する方式を「BigEndian」方式といいます。どう考えても普通ですよね。

それに対してデータの上位バイトと下位バイトを逆転して記録する方式を「LittleEndian」方式と言います。

現在主流のインテルやＡＭＤのＣＰＵは全てLittleEndian方式で記録するタイプです。

したがって、インテル系のＣＰＵで記録したデータをＳＰＡＲＡＣ系のＣＰＵで読むときにはデータを２バイトずつに区切って、上下（左右）を入れ替えないと正しく読めないよ、というお話しです。

（例）真の値：４１８６７（１６進数で表すと Ａ３ ８Ｂ ）のとき、インテル系ＣＰＵでは「 ８Ｂ Ａ３ 」と記録される。

したがって、本当は４１８６７という数値なのに実際には３５７４７という値で記録されていることになりますね。

ちなみにWindowsはLittleEndian方式で動作しています。・・・では、インテルやAMDのCPUを介してデータを記録したFITSファイルは、なにも問題なく画像を読み取ることができるのでしょうか？・・・いやいや、さらに厄介なことがありまして・・・。

★ところが、そもそもＦＩＴＳは・・・

ＦＩＴＳファイルはプロの研究者も使う万国共通の測定データフォーマットですので、解析に用いる計算機はパソコンではなく、ワークステーションやメインフレームである可能性も高いと推察されます。そこでＦＩＴＳの規定を調べてみると、「必ずBigEndian方式で記録すること」と定められていました。

ＡＳＩ１６００ＭＣを制御したのはＡＭＤのＣＰＵを搭載したＰＣで、しかもＯＳはWindowsなので、普通は上下反転させたLittleEndian形式で数値が記録されているはずです。検索エンジンでヒットした某フォーラム中でのコメントでも、たしかに「LittleEndianだ」とのコメントを見つけることができます。しかし、そもそもBigEndianでの記録を定めているＦＩＴＳにLittleEndianで記録するだろうか？これだとプロが困るんじゃ・・・というのが疑問で、なかなか結論が出ません

問題を整理しておきます。

　①インテル系・ＡＭＤ系ＣＰＵでは数値をLittleEndian形式で記録する仕様

　　・・・ふむふむ。つまり数値の上位バイトと下位バイトは反転している訳だな。

　②WindowsもLittleEndian形式に準拠している

　　・・・ほうほう。じゃあ、やはりFITSファイルの中身は数値の上位バイトと下位バイトが反転しているということだな。

　③しかし、そもそもＦＩＴＳ自体がBigEndian形式で記録するよう定めている

　　・・・えっ？！

うえーん。

ややこしいなあ、まったくもう！一体どっちが正しいの？？

今回あぷらなーとがデータの読み込みに四苦八苦した理由がここにあります。

★・・・仕方が無いので

らちがあかないので、力技で１バイトずつデータを細切れに読み出して色々と分析した結果

・・・・・・・・・BigEndian形式（らしい）と判明しました。

ああ、なんということ！。

せっかく１ワード単位（２バイト丸ごと）読み込んで直接「ShortInt型」の変数にぶち込めば符号も含めて一発解決だと踏んでいたのに、いざやってみると「むちゃくちゃ」な数値ばかりが出ていた理由が、これでした。

・・・やれやれ。

★結局、考案した読み出し方法は・・・

①画像データを１バイト分読み込み、バッファーに格納する

②次のデータを１バイト分を読み込んだら、先ほどとは異なるバッファーに格納する

③上位バイトのデータの最上位bitを読んで符号を決める（０なら正、１なら負）

④符号を決めたら、上位バイトの最上位bitを消す。（理論的には１２８を引けばいいはず）

⑤上位バイトと下位バイトの両方に共通の符号を与える

⑥上位バイトの値に２５６を掛けて、下位バイトと加算する

⑦最後にBZero値（３２７６８）を加算して補正する

・・・ロジックはできたので、早速Delphiでプロシージャ（サブルーチン）を書きます。

・・・・ん。完成♪

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

１０／３追記

ごめんなさい。このロジックも間違ってます。

詳細は上にリンクしている１０／３の記事をご覧ください

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

★そして、これが本邦初公開（？）の

DelphiでFITSファイルから読み込んで解析した

ASI1600MC-COOLののRAWデータの「正真正銘無加工の」トーンカーブだあっ！！

どうですか？

美しいでしょう？

え？「なんで山が３つもあるの？」ですって？？

そりゃもう、実際に「R」と「G」と「B」の３種類のセンサーが混在してますからねぇ。

そもそも、カラーカメラなのにベイヤーデータのトーンカーブが１本につながってちゃおかしいんです。

ステライメージとかで見慣れたベイヤーデータのトーンカーブは、おそらく自動的にゴニョゴニョされちゃった後だと思います。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

１０／３追記

ごめんなさい。この分析結果も間違ってます。

詳細は１０／３の記事をご覧ください

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

※「あれ？これ先週までのDelphi７のコーディング画面となんか違う！？」

と思われた方は、もう「Delphiの呪縛」にかかってます。

ええと、その・・・RAD-Studio-10.1『Berlin』に乗り換えました（最新版のDelphiですね）。

あの・・・今なら「スターター」が、・・・ま、まさかの「無料」ですよぉ・・・・・・。

６４bitネイティブコンパイラは止められていますが、ほとんどの機能は使えそうですね♪

無料バラマキ作戦って何年ぶり？？ひょっとして、またDeilhiの時代が来る・・・のか？

★★★その他の『謎』は、後日続けます★★★