あぷらなーと


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

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

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

生息地:香川・徳島
カテゴリ
最新のコメント
> Gさん 安物断..
by supernova1987a at 00:21
> オヤジさん さ..
by supernova1987a at 00:17
> kem2017さん ..
by supernova1987a at 23:56
> にゃあさん 今..
by supernova1987a at 23:55
今年我が家の庭では蝉の鳴..
by G at 10:56
あぷらなーとさんの建築物..
by オヤジ at 10:47
既にクマゼミは圧倒的な戦..
by kem2017 at 09:49
温度と湿度管理大事なんで..
by にゃあ at 09:27
> にゃあさん ミ..
by supernova1987a at 21:55
> オヤジさん な..
by supernova1987a at 21:38
以前の記事
お気に入りブログ

タグ:ASI1600MC-COOL ( 60 ) タグの人気記事

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)

晴れない夜は基本の復習⑧

★「Delphi日和」の顛末

悪天候のため、まったく写真が撮れないのを逆手にとって「Delphi日和」と位置づけた休日ですが、結局丸一日Delphiと格闘するハメになりました。はい。例のASI1600MC-COOL様の画像処理ソフト『開発ごっこ』です。RAWファイルのヘッダを読み込み、撮像データを引っ張り出すところまでは良かったのですが・・・・・・・。


★感覚が鈍ってるのにも程がある

しかし、苦戦しました。なにがって・・・それはもう、酷い有様。
とにかく自分が『完璧な』素人に戻っているのを感じて、自己嫌悪。

<トラブル①>
EAccessViolationで落ちまくる!
昔は良く目にしていたんですがねぇ。思い出せませんでした。今回のケースは確保した配列の要素数を超えるデータをロードしようとしたのが原因。

<トラブル②>
stack overflowで落ちまくる
これは、一般のアプリでも見かけますよね。要するにメモリが不足してるんですが、今回の場合はDelphiの配列に割り当てられるメモリの上限を変える方法を思い出せずに悪戦苦闘していたという顛末。なにしろ、4656×3520の巨大データですものねえ。

<トラブル③>
いくら頑張ってもRAW画像が変!

こればっかりは教則本がありませんので自力で考えるしか無かったのですが、思いついたロジックがことごとく玉砕。

ちなみに「初歩的」なところでは、

 ☆2バイトのバイナリデータを整数値に変換する方法が思い出せない
 ☆データストリームから各個データを読み込むためのバッファーをバイト型で宣言してたのに、その上限を超えるようコーディングしていた
 ☆計算上の要素数と実際の画素数のズレを見逃していた

という燦々たる有様でしたが、とにかく強敵だったのが、「ところどころ階調が反転して見える」という怪現象でして・・・。結局、犯人は(うすうす感じてはいましたが)ヘッダに記録されている「BZERO=32768」なるパラメータの意味するところ。要するにASI1600MC-COOLは12ビットで記録したデータを16ビットで記録しているので、残りの4ビット分の『空白』がどうなっているのかという問題です。結論として、1画素につき2バイトで記録されている各画像データの上位バイトに80が加算されているのが犯人でした。16進で8000=32768ですものねぇ。

★苦節15時間の結果・・・
f0346040_00000847.jpg



・・・ついにっ
f0346040_23491586.jpg
ASI1600MC-COOLのRAWデータから、
ベイヤー画像を取り出すことに成功っ!!

うひゃー。疲れた

これで、『敵の城門』を突破したことになるので、
あとは、いかようにも料理できますね。

なんか、ちょっとやる気が出てきた♪

あ、M42の画像が鏡像になっているのは、ご愛敬。
・・・もう、ディスプレイのY座標は上から下に計るっていう「基礎中の基礎」すら頭から消えてたという(笑)。ま、後からどうにでもなります。

by supernova1987a | 2016-09-19 23:53 | 天体写真 | Comments(9)

晴れない夜は基本の復習⑦

★台風の接近に伴い

台風16号が日本列島に接近中です。皆様、お気をつけください。
さて、というわけで、せっかくの休日ですが

 ○天体写真撮影・・・無理
 ○風景写真撮影・・・無理
 ○バードウォッチング・・・無理
 ○部活の生徒指導・・・お休み(※注:私、学校の教師ではありません)

うーん

こ、これは

まさに

「Delphi日和」っ!

すみません。負け惜しみです。

★先日封印を解いたDelphi7で
f0346040_20040886.jpg
先日実家の物置にある「封印箱」から急遽召還したDelphi7Proですが、ゴソゴソと作業を始めました。
とはいえ、プログラミングのブランクが10年以上あるので、まだヨチヨチ歩きのヒヨコ状態。

★今週の目標は

欲張ると失敗するので、こんなもんですかねぇ。
①ASI1600MC-CoolのRAWデータをきちんと読む
 (どこまでがヘッダで、どういう風に画素データが格納されているのか)
②とりあえず、4画素、たった4画素分で良いのでRAW現像したい。

★少し慣れてきました

累計で6時間ほどDelphiに触ったでしょうか。
徐々に、色々思い出してきました。

まずは、Delphiの統合開発環境下のエディタオプションを「かつての」お気に入り設定に復旧です♪

 予約語とユーザ変数が同じ色だったり
 生きた行とコメント行が同じ色だったり
 数字の1と大文字のIと小文字のlが同じ形だったり

などすると、(乱視と近視と老眼の三重苦が始まった)あぷらなーとがコーディングすると、ミススペルしまくりますので、ゴソゴソと設定を変えます。
ちなみに背景は絶対に『黒』派です。(ソラリス使っていた若い頃は白背景派だったんですがね)
そうそう、フォントも大きめで(笑)。
f0346040_02441318.jpg
うん。こんな感じかなぁ?だいぶ見やすくなりました。


★データを少しづつ読み込んで調査した結果

慎重にASI1600MC-COOLのRAWデータを読み込んでみた結果、次のことが分かりました。

f0346040_02550668.jpg
○判明した事・その①

ASI1600MC-COOLのRAWファイル(FITS)は、どうやら
大きく分けて3つのブロックに分かれているみたいです。

 Aブロック:撮影データなどのヘッダ
 Bブロック:ブランク領域
 Cブロック:撮像データ(各画素の輝度データ)

○判明した事・その②
 Aブロックについて

撮影データのヘッダは、ASCIIコードによる1バイト×80=80バイトで1項目を表しているみたい。
f0346040_03002587.jpg
基本的なレコード構造
【パラメータ名】 【=】 【値】 【/】 【コメント】

第1パラメータ:SIMPLE 
 ASI1600MC-Coolで撮影した物は全て値として「T」が格納されていました。調べてみると、SIMPLE変数は、標準FITSかどうかを表すものみたいです。ああ、なるほど「True」だという訳ですか♪
ちなみにコメント欄には撮影時刻が秒まで記録されています。

第2パラメータ:BITPIX
 画像が何ビットで記録されているかを表すパラメータのようですね。上記の例なら「16bit記録」を表しています。

第3パラメータ:NAXIS
 コメントにDimensionalityと書かれているので、明らかに何次元データかを表していますね。上記の例なら2次元データというわけです。というかデジカメなんだから2次元に決まってます。

第4パラメータ:NAXIS1
 第1軸の変域(ASI1600MC-COOLなら長辺のピクセル数)を表します。4656ピクセルですね♪

第5パラメータ:NAXIS2
 第2軸の変域(ASI1600MC-COOLなら短辺のピクセル数)を表します。3520ピクセルですね♪

第6レコード:COLORTYP:
 カラータイプの略でしょうか?ベイヤー配列の型が格納されています。はい、確かに「GRBG」型だと記録されていますね。(もう、ステライメージさん、ここ読んでくれたら自動でデモザイクできるのに~!)

第7パラメータ:CCD-TEMP:
 本来はCCD用のフォーマットなんでしょうが、CMOSセンサーの冷却温度が記録されています。「-10℃」という訳ですね。

第8パラメータ:YBININNG:
 Y軸方向のビニング数なんでしょうね。ちと自信がありません。

第9パラメータ:INSTRUME
 インスツルメントの略でしょうね。撮影機材名というわけですね。「ASI1600MC-COOL」と記録されています。

第10パラメータ:DATE-OBS
 撮影日時だと思うんですが、ちと妙ですね。第1レコードの時刻と9時間ズレています・・・・ああ!時差ですね。というわけで、こちらの時刻は世界標準時のようです。

第11パラメータ:SWCREATE
 ソフトウェア・クリエイトでしょうか?撮像ソフト名ですね。「SharpCap」と記録されています。

第12パラメータ:EXPTIME
 露光時間ですね。秒単位で記録されているようです。

第13パラメータ:BZERO
 これ、謎のデータです。今のところ、これが「ゼロ点補正」(オフセット値)ではないかと睨んでいます。「32768」ねえ・・・・・。一見変な数値に見えて、これ、16進の2バイト表記なら「80」・「00」となり、とてもキリの良い数値ですからあり得そうです。そのうち真面目に検証してみましょう。

第14パラメータ:EXTEND
 拡張フラグ??・・・一応True値が書き込まれており、コメントにも「Extensions are permitted」(拡張機能が許可されている)と記録されていますが、意味不明です。

第15パラメータ:XBINNING
 X軸方向のビニング数なんでしょうが、やはり自信がありません。

第16パラメータ:YPIXSZ
 撮像素子のY方向のピクセルサイズのことでしょうね。「3.8」とありますので単位はマイクロメートルのようです。

第17パラメータ:XPIXSZ
 撮像素子のX方向のピクセルサイズでしょう。「3.8」ですね。
 
第18パラメータ:END
 ここでヘッダ要素が終了することを表すようです。

○判明した事・その③
 Bブロックについて

これ、FITSの仕様なのか、カメラ側の仕様なのか分かりませんが、ちょうどAブロックと同じ広さの領域が「スペース」(ASCIIコードの0x20)で埋め尽くされています。そもそも80バイトのパラメータ×36で1レコードという規格なのかもしれませんね。

○判明した事・その④
 Cブロックについて

いよいよここからが、『本丸』(撮像データが記録されているエリア)のようですねぇ。
さて、ボチボチ読んでみましょうか・・・。
ASI1600MC-COOLは、AD変換した段階で12bitデータになり、それを16bitデータとして書き出していると広告に書かれているので、2バイトで1ピクセルの輝度を表しているのだろうと勝手に予測。

2バイト分を呼び出して、最初の1バイト分を上位バイト、その次の1バイト分を下位バイトと見なして10進整数値に変換を試みます。

ゴリゴリとコードを書いて
・・・・えいっ!っと。
f0346040_04112544.jpg
第1ピクセルの輝度データは、16進で「A632」。10進に直して「42546」と呼び出せました。
もしも16ビットをフルに埋めると、輝度データの上限は16進で「FFFF」で10進なら「65535
」。一応その中には収まっているので、あり得ない値ではないし、まあ良しとします。(ホントか?)

★さて・・・・と

「敵」の正体は、ほぼ掴めてきました・・・が。これ、客観的に言って、「1600万人の敵兵のうち、1人だけ捉えた」って状態ですよねぇ。
むむむむむ。ここから、一体どう「攻め」ようか・・・・・?????最大の障壁は、昔と違って、・・・ろ、ロジックが沸いてこないっ!
うぇーん(涙)。
よし、今日のところは・・・・寝ます。


by supernova1987a | 2016-09-19 04:46 | 天体写真 | Comments(2)

晴れない夜は基本の復習⑥

★Delphiのリハビリ開始っ!
ついにDelphiの封印を解いてしまい、『なんか開発するぞ』と大見得を切ったは良いけれど、なんだか最近の皆様のコメントを拝見していると、出てくる用語の系統から「ただ者じゃ無い感」が伝わってきて、ビビってるあぷらなーとです。

おそらく、「えっ?『Hello World』のコンパイルが通らない状態から、なにか開発する気?・・・正気か?」と心配(?)されていると思いますので、週1ペースではリハビリ状況を掲載することにしますねぇ。ちなみに現在の環境でプログラミングに充てられる時間は、毎週月曜日(本業の定休日♪)の数時間足らずです。

★リハビリ1日目
<目標>
 ①とにかく発掘したDelphiの開発環境を稼働させる。
 ②入門書1冊の重要なところだけ読破。
 ③最終目的地に向けて「第一歩」を踏み出す。

<結果>
 なんとか目標クリアです。

・・・というわけで

★最初の一歩♪
とにもかくにも、まずASI1600MC-COOLで撮像したRAWデータを読めないことには進みませんので、ここに突破口を開けることにしました。

出でよDelphi!!
うりゃー!
f0346040_03073931.jpg
色んな本や過去のソース(分野は全然画像処理と違いますが)見ながら、度重なるミススペルと文法エラーに耐えながらガシガシコードを書きます。
色々初歩的な感覚が少しばかりよみがえってきました。
いや、ブランクがブランクだけに、最初は変数への代入が「=」なのか「==」なのか「:=」なのかで右往左往する位の酷さでしたが、我ながらよく頑張りました♪

コンパイル!ラン!

・・・うっわ。久しぶりに見たけどDelphiってコンパイル速っ。
まさに目にも止まらぬ速さですねぇ。
f0346040_03142330.jpg
ボタン1を実行すると、すぐにファイルを指定する窓が開いて・・・
ASI1600MC-COOLのRAWファイルをクリックすると・・・・

よっしゃ~!
f0346040_03162591.jpg
FITSファイルのバイナリをゴリゴリ読み込んで16進で表示しながら、ヘッダ部分から撮影データを抜き取って表示することに成功♪
ささやかですが、確実に「一歩だけ」前に進みました。

はぁはぁ、ぜぇぜぇ・・・。今週のリハビリは、ここまでですね。

★★★以下、進展した場合だけ、続く予定★★★


by supernova1987a | 2016-09-13 03:23 | 天体写真 | Comments(8)

晴れない夜は基本の復習⑤

★先日来やっている・・・
EXCEL-VBAを使ったRAW現像『なんちゃってシミュレータ』ですが、
今回はいよいよノイズデータの再現機能を実装してみました。

仮定したノイズは下記の通り

①ダークノイズ
 いわゆるホットピクセルが固定セルに生じると仮定
②ショットノイズ
 光電子の量子論的効果により不可避なランダムノイズを仮定
③リードノイズ
 CMOSの各ラインを読み出した際に正規分布に基づきゲイン変動すると仮定


★たとえばこんな感じになりました

左画像:仮定した元画像(これが本来の天体の像だと仮定)
中画像:上記①②③のノイズを含めて記録されるRAWデータのシミュレート
右画像:標準的なデモザイク処理で現像した場合のシミュレート
f0346040_19534798.jpg
『邪ノイズ』(横しまノイズ)とホットピクセルがきれいに再現できました♪


★となれば、すこし本気出して・・・・

Excel+VBAでは、上記の処理だけで(たった1600画素で)30秒も演算時間がかかるので、その1万倍の画素数を持つASI1600MC-COOLだと83時間(!)もかかる計算になって、お話になりません。・・・というか、4000行のEXCELワークシートとかあり得ない(笑)。そろそろ『封印』を解く時がやってきたようです。


★出でよ!懐かしのDelphi7っ!!

実家の物置を2時間探し回って、ついに発掘しました。
約10年間封印していた「MY開発環境セット」♪
f0346040_20040886.jpg
2002年(かな?)リリースのボーランドDelphi7プロと、参考文献の山です。
いやー。まさかコイツらがゾンビのごとく目を覚ます時が来るとは・・・・・。
・・・あ、くれぐれも私はプログラマーでもSEでもありません。業務の必要に迫られて(泣く泣くボランティアで)数千~数万行程度の小規模アプリのソース数本書いたことがあるだけの素人です。
f0346040_20084216.jpg
ああ、書籍に貼りまくってある付箋が昔の(2週間で15kg痩せた)地獄の日々を思い出させます。
あの思い出したくない日々を繰り返すつもりはありませんが、のんびりと復習を始めるとします。とりあえず付箋貼ってるところだけ読み返して、自分が昔書いたソースを読めばいいか・・・的な・・・・。

さて、まずは入門書から・・・・・・・・・

・・・ん?あれれ??

うぇーん。
な、なにも覚えていない!!

そうか・・・人間、イヤなことは積極的に忘れる動物だと言うしなあ・・・。


★そんな事よりも、そもそも・・・

ああ、もっと大切なことがありました。
Delphi7はWindows98SEとか2000とかが主力だった時代の『遺物』。
そもそも、Windows10で動くのか?!

・・・・で、早速やってみた。
「インストールの上限回数を超えた」ので自動アクティベーションできないとか、インストールも開発環境の立ち上げも全て管理者権限でやらないとエラーが出たりとか、些細なトラブルはありました・・・が!!

ばば-ん!
f0346040_20191925.jpg

おかえり♪Delphi
なんか色んな意味で泣きそう・・・・。
じゃじゃ馬のDelphi7よ。まあ、お手柔らかに頼むわ・・・・。

えっ?今のあぷらなーとのコーディングスキルですか?

ええ・・・と、正直言って良いですか?

何も見ずにコードを書いたら『Hello World』がコンパイル途中で止まった!・・・というレベル。

エラーメッセージの意味が分からなくて(Delphiのエラーメッセージって核心を突いてこないんですよねぇ)よく見ると、行末に「;」忘れてることに気づいた時には、自分のアホさ加減に笑ってしまいました。
もう、PascalとBasicとFORTRANとCとSQLの断片的知識が「ちゃんぽん」になってることを再認識しました・・・です、はい。

★★★以下、不定期掲載★★★
ここからは勉強の日々なので、すぐには記事が続きそうにはありませんなぁ(笑)。
・・・別ジャンルの記事ばかりが長期間続いたら、今回の記事のこと、暖かく忘れてやってください。


by supernova1987a | 2016-09-12 20:45 | 天体写真 | Comments(6)

晴れない夜は基本の復習①

★台風一過の秋空・・とはならず
今回の休日は曇りでした。新たなテスト撮影ができないので、基本に立ち返って色々勉強し直すことにします。
さて、ASI1600MC-COOLのノイズ特性は極めて優秀です。
・・・が、前愛機ASI174MC-COOLとどの程度違うのでしょうか。
実際の天体撮影画像で比較してみます。

条件(撮影日)が異なるので直接比較はできませんが、基本的データは次の通り

撮影月:ASI174MC-COOL:2016年5月 ASI1600MC-COOL:2016年8月
望遠鏡:VMC260L+レデューサVMC+LPS-P2 (両者共通)
冷却温度:ASI174MC-COOL:-15℃ ASI1600MC-COOL:-10℃
ゲイン:ASI174MC-COOL:300 ASI1600MC-COOL:400
露出:15秒 (両者共通)
撮影対象:亜鈴状星雲M27(両者共通)
画像処理:レベル調整のみ(ダーク減算も無し)


★ASI174MC-COOLの撮って出し(ノートリ)
f0346040_23252376.jpg
いや、これでも驚異的な写りだと思うんですよ。市街地ニワトリのたった15秒で・・・。
冷却の威力でホットピクセルはほとんど消滅しているのも特筆すべき点です。
ただ残念なことに、画面全体に見られる強烈な『横しまノイズ』と画面右下の盛大なアンプノイズが痛いですね。
また、メーカーサイトの分光特性資料から予測していたことですが、緑に対して赤の感度が低いのが分かります。

★ASI1600MC-COOLの撮って出し(ノートリ)
f0346040_23344439.jpg
対して、ASI1600MC-COOLだと撮って出しでコレです!
ホットピクセル無し・シマシマノイズ無し・アンプノイズ無しの三拍子が揃っています。画素数とかフォーマットが云々以前に基本的な性能が雲泥の差。
しかも、明らかにHα線に対する感度がASI174MC-COOLよりも(緑に対して相対的に)高く感じます。

★ASI174MC-COOLの撮って出し(トリミング)
f0346040_23391719.jpg
中央部をピクセル等倍で切り出した物です。中心星の青い色や星雲内の色の変化など良く写っていますが、ノイズが・・・。


★ASI1600MC-COOLの撮って出し(トリミング+縮小)
f0346040_23393786.jpg
ピクセルサイズが174と異なりますので画像を縮小して切り出した物です。
色特性としては、ちょうどIR改造のD5000と似たような感じでしょうか。とにかく赤い星雲が良く出ます。
変なノイズが一切無いところも素敵です。

★それでも・・・・・
このようにASI1600MC-COOLは驚異的に低ノイズなのですが、それでも淡い天体を炙り出そうとすると、嫌なシマシマノイズが出ます。
・・・というか、出ないカメラってあるのか?というのが正直なところなのですが、とにかく何か工夫がしたいところですね。
試行錯誤するための準備として、今一度ベイヤーデータについて考えてみることにします。
・・・ううむ。色んな原理の理解のため、13年ぶりにEXCELのVBAコード触ってみることにします。
ああ、丸10年以上コーディング(プログラミング)から遠ざかっていたので、もう何も覚えていないでしょうね・・・・。少しは復習しておくんだった。




by supernova1987a | 2016-09-06 01:48 | 天体写真 | Comments(2)

満天の星空目指してリベンジ③

★やはり星座は冬の優勝ですね
とにかく冬の星座は豪勢ですよね。先日のプチ遠征で薄明前に冬の星座が上ってくるのを見て、一人でテンションが上がってしまった、あぷらなーとです。
・・・というわけで、8月30日に撮影した『冬』の写真データを処理しました。

★星座の王者オリオン
f0346040_20092076.jpg
久しぶりに持ち出したポータブル赤道儀ケンコースカイメモNSにIR改造D5000+サムヤン35mmF1.4を載せてオリオン座を狙いました。

絞りF2.8・ISO1600・30秒露光の撮って出しだと、こんな感じ。
f0346040_20104527.jpg
さすがIR改造D5000+カメラ内蔵型のLPS-P2フィルタの威力で、なんだかオリオン座大星雲M42とか鮮烈に写っています。
ただ、背景色が汚いですね。また、バーナードループやエンゼルフィッシュ星雲が弱いです。

そこで、ソフトウェアビニング+16枚コンポジット+デジタル現像その他色々調整してトリミングしてみると・・・
f0346040_20135678.jpg
ああ、良い感じです♪
さすがに分子雲などを炙り出すほどのテクニックは持ち合わせていませんが、なんか天文少年だった頃に憧れた写真のイメージですね。
ベテルギウスのオレンジとリゲルの青白色もきれいに出せました。本当に久しぶりにオリオン座を撮りましたが、そらの状態が良いと楽勝ですね・・・。

★星雲の王者M42
超メジャーですが、本当に奥が深くて何度撮っても飽きないのがオリオン座大星雲M42です(私だけ??)。
今回は、自己ベストの滑らかさを出すべく、初の二段階露光に挑戦です。

撮影データは次の通り
 VMC260L+レデューサVMC(1860mmF7.1相当)+LPS-P2フィルタ
 ASI1600MC-COOL 冷却温度-15℃
 K-ASTEC改造newアトラクス+QHY5-IIMオートガイド(PHD使用)
 ゲイン:400 露光:10秒×100コマ&5秒×50コマ

さて、150コマコンポジットをしてみましょう。
f0346040_20305395.jpg
※ほぼノートリミング

さすがにASI1600MC-COOLで明るい天体を150コマコンポジットすると、ほとんどノイズ感無しになりますね。
(厳密にはガイドエラー方向【画面短辺方向】に縮緬状のノイズが残っています。)
ややシャープさに欠けますが、いつもよりフンワリと仕上げてみました。
ありきたりな描写ですが、いかにもM42っていう感じがしますね。


★ちょっと気になったことが・・・
段階露光したのに中心部が飛んでしまったのには理由があります。
実は市街地でニワトリした際にはゲイン400の15秒露光でも全然サチらなかったので、余裕見て5秒と10秒で楽勝と読んでいたのですが、なぜか10秒露光のコマの全てが中心部トンでました。??????? バックグラウンドがあると飛びにくい??いやいや、そんなバカな・・・・・。
ASI1600MC-COOL、どこまで行っても謎だらけです。ま、そこが面白いんですがね。






by supernova1987a | 2016-09-03 05:33 | 天体写真 | Comments(6)

満天の星空を求めてリベンジ②

★久々の満天の星空の下
8/30の夜の満濃池遠征では、まずD810A+シグマ20mm+スカイメモNSできれいな秋の天の川が撮れましたが、本命の機材で撮像したデータもボチボチ処理をしてみましょう。ちなみに色々と『検証ごっこ』するつもりだったのですが、いかんせん夜前半がドン曇り+一時雨という悲惨な状況だったので、VMC260Lの撮影準備が完了したのが1:40という始末。4:00の薄明まであまり時間が無いので、色々とパラメータを変えて実験している余裕がなく、とりあえず「たぶんこれが『正解』」という設定を信じて「本命の天体」を各個撃破していくことにしました。

★本日の『本命』は・・・
ずばり、「カニ」です♪
はい。おうし座の超新星残骸であるM1かに星雲ですね。
相当にメジャーな天体のハズなのですが意外と難敵です。
昨年IR改造D5000とVMC260Lで市街地からチャレンジした時には、あまりにも悲惨な写りでブログにも載せられずボツ箱行きになりました。
ちなみに、昨年撮影した かに星雲の元画像(レベルだけ調整)がこちら↓
f0346040_15443310.jpg
これは相当な枚数をコンポジットしてもなかなかまともな像になりそうにありません。

★今回の装備は
お盆の撮影時にK-ASTEC改造ニューアトラクスのオートガイドを初めて行った際、どうもガイド鏡がたわんでいるようだったので今回は
f0346040_15460925.jpg
鏡筒の『下』に取り付ける方式で行きます。いわゆる『親子亀方式』ならぬ『コバンザメ方式』ですね♪
前回のテスト運用でミニBORG50+QHY5-IIMの場合、どこに向けてもほぼガイド星が見つかる状況だったので微動装置は排除。鏡筒バンドを直接アリミゾにつけました。これで幾分ガイドエラーが緩和されることでしょう。
f0346040_16022209.jpg
★いざ撮影!
今回の主要撮影データは次の通りです。

VMC260L+レデューサVMC(1860mmF7.1相当)+LPS-P2フィルタ
ASI1600MC-COOL 冷却温度-15℃
K-ASTEC改造newアトラクス+QHY5-IIMオートガイド(PHD使用)
ゲイン:400 露光:20秒 保存形式:RAW(FITS)

準備に手こずりましたが、いざ撮影が始まると快適です。
sharpcap2.8の時には連続撮影しているように見えて、途中で勝手に止まるという不具合がしばしば発生していましたが、2.9にしてみたら嘘のように安定動作しています。バグだったのかなあ??

★撮って出し画像は
こんな感じです
f0346040_16133055.jpg
なにがなんだか分かりませんね。ええ、結構かに星雲は暗いんです。
・・・で、レベル調整するとこんな感じ。
f0346040_16142116.jpg
おおっ!これは良い感じです♪
ザラザラですが去年撮ったヤツとは雲泥の差。コンポジットすれば相当な像に化けるのは間違いありません。

★取り急ぎ最低限の画像処理を・・・
諸般の事情でまだダークファイルが撮れていないので、ステライメージのホット&クールピクセル除去フィルタで代用します。
こんなとき、ダークノイズが少ない冷却カメラは処理を妥協できるので良いですね。

では、100枚コンポジット行ってみます♪

すると・・・
f0346040_16185512.jpg
おお、まさしく『かに星雲』~。

ほんのり青い本体に纏わり付くように赤いフィラメント構造。
なんだか立体感を感じますね。
そう、こんなのが撮りたかったんですよ♪

・・・やっぱ冷却+良い空だと違いますねぇ。


by supernova1987a | 2016-09-01 05:18 | 天体写真 | Comments(11)

サンニッパと冷却CMOSカメラ

★やりたかったこと
ZWOの冷却CMOSカメラ ASI1600MC-COOLですが、マイクロフォーサーズフォーマットという巨大なチップなため、ぜひやってみたかったのが、望遠鏡ではなくカメラ用のレンズで天体写真を撮ってみるということ。F値明るいですしね♪
・・・というわけで、かねてから用意していた ニコンF→マイクロフォーサーズ→ASI1600MC-COOL アダプタの出番がやってきました。
どうせなので、大本命レンズ ニコンのサンニッパ(300mmF2.8)を使ってみます。

★今回はアトラクスではなく
赤道儀は最近K-ASTEC改造Newアトラクスばかりを使っていたのですが、ポールマスターのテストも兼ねてEQ6PROを使ってみます。
撮影対象は、『お約束』のM31とM42です!

★雲の妨害と格闘
・・・・・が、赤道儀を据え付けた辺りから「嫌がらせのように」北の空から雲がどきません。せっかくのポールマスターの画面も雲しか写らず、時折顔を見せる北極星もすぐに隠れてしまうという状況で、極軸合わせにまさかの90分もかかってしまいました。この時点で早3:00過ぎ。もたもたしていると薄明が始まってしまいます。
外気温が低かったのでASI1600MC-COOLを-15℃まで冷却して、アルフェラッツ(アンドロメダ座α星)を使って1点アライメント+ピント合わせを行いM31を導入。
いざ撮像開始!・・・と思ったら、曇りました(泣)。
西から天頂にかけてワラワラと雲が流れてきているうちにM31は電線に架かってしまいボツ。
作戦を変更して、オリオン座大星雲M42に向け直します。
・・・・が、今度は東から南にかけてモクモクと雲が流れてきます。

★薄明との格闘
イライラしているうちに4:30を過ぎてしまいました。たしか今日の天文薄明は4:00過ぎのハズ。
市街地からのニワトリなので、まだ肉眼では薄明を感じませんが、これ、絶対に背景真っ青になっちゃうパターンです。
そんな中、オートガイダーがキャリブレーションエラー。ああ!と思ったらノートパソコンがバッテリー切れ。
もう絶体絶命・・・・。
諦めきれないので、急遽外部電源から給電してノートPCを復活させ、EQ6PROはノータッチガイドに変更。
露光も10秒まで切り詰めて、「やっつけ撮影」に切り替えです。

★撮れはしましたが・・・
なんとか撮れた画像は、撮って出しだとこんな感じです。
f0346040_10292549.jpg
※ニコンAF-S300mmF2.8 絞り開放 LPS-D1フィルタ併用
ASI1600MC-COOL ゲイン400 露光10秒 RAW
EQ6PROでノータッチガイド
ステライメージ6.5でデモザイク(ダークファイル減算なし。色補正なし。)
トリミングあり

・・・なんか、完全にアウトですねぇ。薄明に襲われてしまえば、もはや光害どころの騒ぎではありません。(フィルタが無力化されちゃうので)
でも、まあ、M42本体は一応しっかりと写っていることですし、ここは『デジタルマジック』に期待してダメ元で処理してみましょう。


★画像処理で『後から』がんばってみる
撮像した画像の内雲が写っていなかったコマ42コマを下ごしらえします。
どうせ薄明の影響でボロボロでしょうから、ダークファイルも引きません。
気休め程度にステライメージでホット・クールピクセル除去フィルタをかけた後デモザイク。
それに2×2ソフトビニングをかけてからコンポジットし、大気差を補正したり、デジタル現像したり、トーンをいじったりしてみます。

・・・えいっ!!
f0346040_10382600.jpg
おお。意外や意外!
こ、こんな劣悪環境下でも・・・け、結構良い感じでは♪
ダークもフラットも無く、薄明中なのに、M42とM43はもちろんのこと『ランニングマン』(NGC1977)もくっきり鮮やか♪
お恥ずかしながらランニングマン、きれいに写せたの「初めて」です。(天文歴30年以上のクセに、ちっとも釣果が上がらなかったもので・・・)
しかし、近年VMC260Lでドアップにした「おどろおどろしい感じ」のM42(↓こんなん)しか撮ってなかったので、定番構図で撮るとホッとしますね♪
f0346040_21355244.jpeg
 ※VMC260L+ASI1600MC-COOLで先日撮影したM42のどアップ



・・・・・うーむ。
ともあれ、やはりASI1600MC-COOL、かなり『できる子』ですねぇ。

あれ?・・・そういえば今回の写真、どのコマ見てもシマシマノイズが見当たらない・・・・あれ一体なんだったんだんだろう??
あ!・・・また無意識のうちにhighspeedmodeをOFFにしてた・・・けれど、けむけむさんの検証実験では「シロ」と判明したしなあ?
なんか、他に気づいていない要因がありそうな気配・・・。
結局今回も、ゲインの比較、露光の比較、シマシマノイズの原因、オートガイドのリトライ・・などなど、やりたかった『検証ごっこ』はできずじまい(泣)。


★GPV予報を見ていると・・・
・・・ん???

今夜は夜半、雲量ゼロ予報ですと??
え、遠征、・・・行って・・・みようかなあ??


by supernova1987a | 2016-08-30 10:57 | 機材 | Comments(12)

お盆の各種テスト覚え書き④

「検証ごっこ」第4弾です♪

ZWOの冷却CMOSカメラASI1600MC-COOLについて、
「短時間+多数枚コンポ VS 長時間+少数枚コンポ」 ですが、
今回は、別な視点から見てみます。

★総露光時間が同じなら良い?

いえ、色々と他の要素が絡んでくるので、一概にそうとも言えないようです。

<短時間露光のメリット>
 ①高輝度画像がサチらない(飽和しない)
  低輝度データは加算で救えますが、一度サチったデータは救えません。
 ②ガイドミスのリスクが少ない(ノータッチガイドでも可)
  オートガイドしないなら、唯一の選択肢になります。
 ③何枚重ねるかで後から露出を加減できる(加算できる)
  前回の「検証ごっこ」で短時間露光コマを加算すると
  長時間露光コマに匹敵することが分かりました。
 ④ディザリング(もしくはそれに類した)効果を出しやすい
  ノータッチガイドだと『勝手にディザリング』状態になり
  ノイズが消えちゃいます。
 ⑤とにかく、手抜き撮影に最適(これ、重要)
  まず失敗しませんので・・・楽ちんです。

<短時間露光のデメリット>
 ①撮影データが膨大になる。
  もしD810Aを現像してFITSにした日には、100コマ画像が
  実に『83GB』にもなっちゃいます。
 ②いくらなんでも限度というものがありそう。
  1秒露光の3600コマコンポジットとかは非現実的っぽい。
  (データ量と処理時間の面で)
 ③処理時間が多くかかる。
  今回の「検証ごっこ」は、この点に注目してみます

★基本的なワークフローについて
 ①ASI1600MC-COOLのRAWデータをFITS形式で記録する
 ②あらかじめ準備したダークファイルを減算してベイヤーのまま保存
 ③消し切れていないホット&ダークピクセルなどを除去処理する
 ④デモザイク(ディベイヤー)してRGB化する
 ⑤加算コンポジットを行う
 ⑥レベル調整を行う
 ⑦デジタル現像を行う
 ⑧その他、モロモロの処理を施す

このうち、撮像枚数が処理時間に関係するのは、②~⑤の工程です。
では、先日自作した新PC(Core i5-6600 3.3GHz メモリ16GB)を使用しておよその処理時間を計ってみましょう。

★工程②に要する時間
 ダーク減算+ベイヤー保存に要するおよその作業時間を測定してみました。40コマのASI1600MC-COOLのビニングなしRAWデータからダークを引いて、ベイヤーデータのままFITS保存するのに要する時間は
  ステライメージ6.5:33.5秒
  ステライメージ7.1:70.5秒
でした。

★工程③④に要する時間
 40コマのダーク減算済ベイヤーデータからホット&クールピクセル除去を行い、デモザイク処理してRGBデータをFITS保存するのに要する時間は
  ステライメージ6.5:576秒
  ステライメージ7.1:746秒
でした。 

 ちなみに、ホット&クールピクセル除去フィルタ処理をせず、
デモザイクのみ(行程④のみ)なら
  ステライメージ6.5:78.5秒
  ステライメージ7.1:82.7秒
でした。急ぐときは、断然こっちの処理ですね。

★工程⑤に要する時間
 40コマのデモザイク済みRGBデータを位置合わせし、加算平均コンポジットするのに要する時間は
  ステライメージ6.5:17.5秒
  ステライメージ7.1:260秒
でした。ミスタイプではなくホントに15倍かかります。

・・・ええと、D810AのRAW現像ができないにも関わらず未だにステライメージの6が捨てられないのは、⑤のコンポジット処理の『圧倒的な速さ』なのですね。
これは、コンポジットの位置合わせに関してその仕様が全く異なるからです。

ステライメージ7で最速コンポジットをやろうとすると、
 (1)40枚の画像を全てを開きます
 (2)そのうちの1枚に基準星マークを入れます
 (3)バッチメニューから基準星指定を実行します
 (4)バッチメニューからコンポジットを実行します
ちなみに、40枚全てをロードするのでメモリも10Gほど食います

これが、ステライメージ6だと・・・
 (1)代表として1枚だけ画像を開きます
 (2)基準星マークを入れます
 (3)バッチメニューからコンポジットを実行します
ちなみに、7と同じ操作も可能ですが、6のコンポジットには「自動で読み込みながら順次位置合わせ」してコンポジットしてくれる機能があり、圧倒的に高速な上にメモリもほとんど食いません。

★40枚の総処理時間は・・・

その1:ホット&クール除去フィルタを使う場合
 ステライメージ6.5:627秒
 ステライメージ7.1:1077秒
 
その2:ホット&クール除去しない場合
 ステライメージ6.5:130秒
 ステライメージ7.1:413秒

★ということは1枚あたり・・・

その1:ホット&クール除去フィルタを使う場合
 ステライメージ6.5:15.7秒
 ステライメージ7.1:26.9秒
 
その2:ホット&クール除去しない場合
 ステライメージ6.5:3.23秒
 ステライメージ7.1:10.3秒

が、それぞれかかる処理時間ということになりますね。

★・・・というわけで
15秒露光×40コマでも、30秒露光×20コマでも、60秒露光×10コマでも、撮影に要する時間は同じですが、その画像処理時間は、枚数に比例して多くなっていきます。今回の『検証ごっこ』では

ステライメージ6を用いた場合で
 15秒露光×40コマコンポジット:130~627秒
 30秒露光×20コマコンポジット: 65~314秒
 60秒露光×10コマコンポジット: 33~157秒

ステライメージ7を用いた場合で
 15秒露光×40コマコンポジット:413~1077秒
 30秒露光×20コマコンポジット:207~538秒
 60秒露光×10コマコンポジット:103~269秒

がそれぞれ最低限必要であることが分かりました。

たとえ400コマコンポジットをする場合でも、ステライメージ6.5で、しかもホット$クール除去フィルタを使わなければ、ものの20分で終わっちゃいますので、どうでも良いことかもしれませんが・・・・・。

ただし、これがデジタル一眼の場合には、事態は深刻です。ステライメージでダーク減算するために、まずRAWファイルをFITSに変換する必要がありますし、とにかくNEFファイルに対する動作は恐ろしく遅いので、以前D810Aで撮影した干潟星雲のRAW画像400コマを処理しようとしたときには、まだPCを作り直す前でメモリ3GBだったこともあり、丸1日を費やしても無理でした。結局あきらめて、JPEGからの処理に切り替えました。ASI1600MC-COOLの最大のメリットは、RAWファイルがいきなりFITSであることかもしれませんね。

★文字ばかりが続いたので
今回の「検証ごっこ」で、前回M33の画像処理に用いた60秒露光のコマ60コマ分に加えて、15秒露光×50コマと30秒露光×25コマも処理したので、合わせてコンポジットしてみました。
合計135コマのコンポジットとなります。以前の物よりさらに少しだけ良くなったかな??
f0346040_20084792.jpg
お恥ずかしながら、さそり座の『カラフルタウン』など、我が銀河系内の分子雲・いわゆる『モクモク』すら写したことが無いのに、ご近所の銀河の『モクモク』を先にゲットできるとは想定外でした。

それにしても、初心者の方は、まさかコレ↓が元画像だとは思いもしないでしょうね。
f0346040_21255309.jpg
うーむ。まさに、デジタルマジック♪

★★お約束★★
本記事のデータは、あくまでも検証『ごっこ』です。
私あぷらなーとの頭からは、すでに「有効桁」とか「シグマ」とかの概念は蒸発しています。したがって、数値は精度を保証する物では無く、根本的に何かを勘違いしている可能性も大いにあり得ます。あくまでもネタとしてお楽しみください。

by supernova1987a | 2016-08-19 05:52 | 機材 | Comments(6)


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