あぷらなーと


あぷらなーとの写真ブログ
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
あぷらなーと
「自然写真大好き」
HNあぷらなーと が

いろんな写真ネタを
のんびり語ります。

気合い入れすぎると
続かないので、
「ぼちぼち」いきます。

生息地:香川・徳島
カテゴリ
最新のコメント
> kem2017さん ..
by supernova1987a at 01:57
台風一過、こちらも見えて..
by kem2017 at 04:06
> にゃあさん い..
by supernova1987a at 02:36
備えあれば憂いなしですね..
by にゃあ at 01:43
> オヤジさん 玉..
by supernova1987a at 23:28
四国は、オンコースでした..
by オヤジ at 23:19
> kem2017さん ..
by supernova1987a at 23:47
> オヤジさん ホ..
by supernova1987a at 23:43
> にゃあさん プ..
by supernova1987a at 23:41
> kem2017さん ..
by supernova1987a at 23:23
以前の記事
お気に入りブログ

2016年 09月 26日 ( 1 )

ASI1600MC-COOLの謎①

★ASI1600MC-COOLの『謎』

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

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

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

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

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

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

<お約束>
以下の考察は、あぷらなーとの独断によるものですので、信憑性があるとは限りません。
誤りが散見するかもしれませんので、あんまり参考にしないでください。

★謎①の解明『ごっこ』

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


★ASI本体からFITSファイルへの記録方式
そもそもFITSって天体研究者用の汎用フォーマットだったのですね。全然知りませんでした(汗)

○記録された画像データの型は16bit整数(符号付)です
数値は16桁の2進数で記録されていますが、注意すべき点は16桁全てが数値を表しているのではなく、最上位のビットは「符号」を示しているということです。この値が1ならばマイナス、0ならばプラスを示します。そして残りの15ビットで絶対値を表します。
f0346040_20473337.jpg
したがって、位(桁)をiとし、値(0か1)をNiとすると、絶対値はΣ2^(i-1)*Niで示されます。
これに最上位ビットの値N16を合わせると、符号付きの数値は
(-1)^N16*Σ2^(i-1):*Niとなります。
この場合、格納できる数値は【-32768~+32767】の65535通りとなりますね。

***************************************
※10/3追記
これ、ウソです。確かに上記のような記録法もありますが、FITSはこれとは異なる「補数表現」を使用していることが判明しました。
詳細は、10/3のブログ↓を参照してください
***************************************

★ここで問題発生!!
FITSの形式では、正の数値は16bit分ではなく(符号で1bit取られるので)15bit分しか格納できません。
そもそも天体写真では明るさが『マイナス』にはなり得ないので、半分が無駄ですね。
そこで何らかの「トリック」が必要となります。
f0346040_21053700.jpg
「トリック」とは、
f0346040_21382675.jpg
このように、左にシフトして書き込んでしまうと言う仕掛けです。(よくこんなこと思いつくなあ)
したがって、本来【0~65535】のデータがFITSの中では【-32768~32767】として格納されているわけですね。

★ヘッダにあるBzeroの正体
このような仕掛けがなされているため、FITSファイルから画像データを読み出すときには、素の値に32768を加算してやる必要があります。
というわけで、先日「謎のパラメータ」だと言っていたFITSのヘッダにある第13番目のパラメータ:「BZERO=32768」の正体は、このシフト量と判明しました。(ああ、たぶんFITSを扱っている人には常識なんでしょうけどねぇ・・・・。)

★CPUのメーカー依存性
Delphiと格闘しつつも、どうもデータがおかしい状態が続いて頭を抱えていたとき、ふと、大昔(20年以上前)に大学の研究室で「観測データを解析する時に悩まされた」ことを、思い出しました。
当時、宇宙線の観測データを解析する際にハチャメチャな数値ばかりが出てきて半泣きになっていた時に、観測データを記録する際に用いたPC-9801VM(CPU:80186)とデータ解析に用いたスパークステーション10(CPU:SuperSPARC)とでデータの記録方式が異なることを知りました。いわゆるSPARC系のCPUは普通に上の桁から(左から順に)書き込みますが、インテル系のCPUは不思議なことに2バイト(16bit)のデータを書き込む際に、上位バイト(左の1バイト8bit分)と下位バイト(右の1バイト8bit分)を「逆転」させて記録する仕様だったのです。したがって、インテル系のCPUで記録したデータをSPARC系のCPUで読むときにはデータを2バイトずつに区切って、上下(左右)を入れ替えないと正しく読めないよ、というお話しです。

★リトルエンディアンとビッグエンディアン
普通通り上位(左)から順に記録する方式を「BigEndian」方式といいます。どう考えても普通ですよね。
f0346040_21502406.jpg
それに対してデータの上位バイトと下位バイトを逆転して記録する方式を「LittleEndian」方式と言います。
現在主流のインテルやAMDのCPUは全てLittleEndian方式で記録するタイプです。
f0346040_21515655.jpg
したがって、インテル系のCPUで記録したデータをSPARAC系のCPUで読むときにはデータを2バイトずつに区切って、上下(左右)を入れ替えないと正しく読めないよ、というお話しです。
(例)真の値:41867(16進数で表すと A3 8B )のとき、インテル系CPUでは「 8B A3 」と記録される。
したがって、本当は41867という数値なのに実際には35747という値で記録されていることになりますね。

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

★ところが、そもそもFITSは・・・
FITSファイルはプロの研究者も使う万国共通の測定データフォーマットですので、解析に用いる計算機はパソコンではなく、ワークステーションやメインフレームである可能性も高いと推察されます。そこでFITSの規定を調べてみると、「必ずBigEndian方式で記録すること」と定められていました。
ASI1600MCを制御したのはAMDのCPUを搭載したPCで、しかもOSはWindowsなので、普通は上下反転させたLittleEndian形式で数値が記録されているはずです。検索エンジンでヒットした某フォーラム中でのコメントでも、たしかに「LittleEndianだ」とのコメントを見つけることができます。しかし、そもそもBigEndianでの記録を定めているFITSにLittleEndianで記録するだろうか?これだとプロが困るんじゃ・・・というのが疑問で、なかなか結論が出ません

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

 ①インテル系・AMD系CPUでは数値をLittleEndian形式で記録する仕様

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

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

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

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

  ・・・えっ?!

うえーん。
ややこしいなあ、まったくもう!一体どっちが正しいの??
今回あぷらなーとがデータの読み込みに四苦八苦した理由がここにあります。

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

・・・・・・・・・BigEndian形式(らしい)と判明しました。

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

・・・やれやれ。

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

①画像データを1バイト分読み込み、バッファーに格納する
②次のデータを1バイト分を読み込んだら、先ほどとは異なるバッファーに格納する
③上位バイトのデータの最上位bitを読んで符号を決める(0なら正、1なら負)
④符号を決めたら、上位バイトの最上位bitを消す。(理論的には128を引けばいいはず)
⑤上位バイトと下位バイトの両方に共通の符号を与える
⑥上位バイトの値に256を掛けて、下位バイトと加算する
⑦最後にBZero値(32768)を加算して補正する

・・・ロジックはできたので、早速Delphiでプロシージャ(サブルーチン)を書きます。
f0346040_22120885.jpg
・・・・ん。完成♪
******************************
10/3追記
ごめんなさい。このロジックも間違ってます。
詳細は上にリンクしている10/3の記事をご覧ください
******************************



★そして、これが本邦初公開(?)の
DelphiでFITSファイルから読み込んで解析した
ASI1600MC-COOLののRAWデータの「正真正銘無加工の」トーンカーブだあっ!!

f0346040_22301035.jpg
どうですか?
美しいでしょう?

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

そりゃもう、実際に「R」と「G」と「B」の3種類のセンサーが混在してますからねぇ。
そもそも、カラーカメラなのにベイヤーデータのトーンカーブが1本につながってちゃおかしいんです。
ステライメージとかで見慣れたベイヤーデータのトーンカーブは、おそらく自動的にゴニョゴニョされちゃった後だと思います。

******************************
10/3追記
ごめんなさい。この分析結果も間違ってます。
詳細は10/3の記事をご覧ください
******************************

※「あれ?これ先週までのDelphi7のコーディング画面となんか違う!?」
と思われた方は、もう「Delphiの呪縛」にかかってます。
ええと、その・・・RAD-Studio-10.1『Berlin』に乗り換えました(最新版のDelphiですね)。

あの・・・今なら「スターター」が、・・・ま、まさかの「無料」ですよぉ・・・・・・。
64bitネイティブコンパイラは止められていますが、ほとんどの機能は使えそうですね♪
無料バラマキ作戦って何年ぶり??ひょっとして、またDeilhiの時代が来る・・・のか?

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


by supernova1987a | 2016-09-26 22:42 | 機材 | Comments(6)


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