あぷらなーと


あぷらなーとの写真ブログ
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あぷらなーと が

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

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

生息地:香川・徳島
カテゴリ
最新のコメント
大事にならず良かったです..
by G at 16:36
> にゃあさん え..
by supernova1987a at 09:14
> オヤジさん 光..
by supernova1987a at 09:09
これがスプリッターの実力..
by にゃあ at 01:30
凄いですね! 撮影時間..
by オヤジ at 00:11
> けむけむさん ..
by supernova1987a at 22:04
星雲撮影おめでとうござい..
by けむけむ at 17:47
> Gさん 「su..
by supernova1987a at 14:11
> にゃあさん 不..
by supernova1987a at 14:05
> オヤジさん ほ..
by supernova1987a at 14:00
以前の記事
お気に入りブログ

カテゴリ:天体写真( 100 )

AutoStakkert!2に慣れる①

★昨日の記事で
うっかり設定してしまったSer動画ファイルを救出するために、初めてAutoStakkert!2を使ってみましたが、なかなかに良い感じでした。
・・・じゃ、本来の使い方も試してみよう!というわけで、3月末に撮影していた木星の画像を引っ張り出してきました。ちなみに撮影はいつものASI1600MC-COOLではなくて、久々に登場のASI174-MC-COOLです♪
f0346040_22102136.jpg


★撮って出しでは
ASI174MC-COOLをVMC260L+2.5倍バーローに装着し、ゲイン200・1/100秒露光のAVI動画出力した木星の画像を1コマ切り出してくるとこんな感じ。
f0346040_21300024.jpg
ちなみに、シーイングは良くなかったです。

★スタッキングすると
AutoStackert!2で400コマほどスタッキングして、レジスタックスへバトンタッチ。
ウェーブレット処理を施しますと・・・・
ででん!
f0346040_21324930.jpg
うん。悪くない♪
以前レジスタックスを主体に処理した画像から特に改善したわけではありませんが、とにかく処理が「楽」だったのは確かです。

★似たような条件で月面も再処理
f0346040_23210746.jpg
こちらは、AutoStakkert!で良像25%をスタックした後、レジスタックスへ通さずにステライメージの最大エントロピー画像復元に回してみました。経験上(というか私のスキル上)月面はウェーブレット処理よりも最大エントロピー法の方が肌に合ってますので。・・・で仕上げにアンシャープマスクを。

うーむ。やっぱりウェーブレット処理とかのシャープ系画像処理は、星雲よりも惑星や月面の方が『劇的』に効果が現れますね。
ま、当たり前ですけど。

さて、AutoStakkert!には色々なパラメータがあり、(レジスタックスほどではないにしても)効果がよく分からない機能があるので、少し勉強してみないといけませんねぇ。それにしても、今回AutoStakkert!を使ってみて驚いたのは、レジスタックスと違って処理中に「落ちない!!」ってことです。当たり前のようで、これ大変なことですよねえ。


★・・・で『秘策』とか『ソフト開発』とかは・・・

あら? 困りましたねぇ。
なんか頭の中から散歩に出かけてしまったようで、見当たりません。
一体、どこに行ったのでしょうねぇ??
たぶん、天気が良くなるとかえって来ると思うんですけれど・・・・。


by supernova1987a | 2016-10-14 08:25 | 天体写真 | Comments(4)

『うっかりSer』から救出する

★「SharpCap使い」の皆様の中には・・・

えーとですねぇ。皆様、やらかしたことないですか??
「FITSで保存したつもりが『勝手にser動画』で保存されていて号泣」
なんていう大惨事。

かくいうあぷらなーとも度々やらかしてます。
ピント合わせや対象物の導入のため、撮影前に8bitモノクロで表示させておいて、撮影時に16bitRAWに切り替えた場合に保存形式がserファイルになっちゃうのが原因なのですが、頭では分かっているのに、ついうっかりやらかしてしまいます。


★8月31日に撮影していたM42が・・・

ちょうど5秒露光の50コマ連写のつもりが、見事にser動画になってしまっていて、『ゴミ箱行き予備軍』になっていた画像が4セット(つまり200コマ分も!)死蔵されていたので、救済策を考えてみました。

<撮影データは>
[ZWO ASI1600MC-Cool]
Debayer Preview=Off
Pan=0
Tilt=0
Output Format=SER file ←ココで痛恨のミス(泣)
Binning=1
Capture Area=4656x3520
Colour Space=RAW16
Hardware Binning=Off
High Speed Mode=Off
Turbo USB=80
Flip=None
Frame Rate Limit=Maximum
Gain=400
Exposure=4.999974
Timestamp Frames=Off
White Bal (B)=99
White Bal (R)=60
Brightness=1
Gamma=81
Temperature=-15
Cooler Power=32
Target Temperature=-15
Cooler=On

こんなのが4つも!!
・・・ああ、もったいない!
残念ながらステライメージでは手も足も出なかったので
近年よく使われていると評判のスタッキングソフト「AutoStakkert!2」を試してみました。

★AutoStakkert!2の画面イメージ
f0346040_19095611.jpg
雰囲気としてはお馴染みのレジスタックスとよく似たソフトなのですが、後発ソフトなだけに操作が分かりやすくて好感が持てます。また、アライメントポイントが任意の位置に任意の大きさで打てるのがうれしいですね。それになによりSER動画ファイルに対応しているのが素敵♪

動作も非常にキビキビとしていて、スタッキングも速いです。
ちなみに、ASI1600MC-COOLで撮影した16ビットSERファイル中の40コマをアライメントポイント14個設定でスタッキングするのにかかる時間は、
 ○アライメントに0.7秒
 ○スタッキングに6.2秒
 ○その他処理に17.7秒
となかなかの速度でした。
・・・これ、コンポジットが爆速なステライメージ6.5よりもさらに速いかもですね。

★SER動画からの1コマ切り出しだと
f0346040_19170362.jpg
ピクセル等倍でこんな感じですね。5秒露光の割には良く写っていますが、ザラザラです。ただし、-15℃まで冷却していることと超短時間露光のため、ほとんどダークノイズが見当たりません。この辺はASI1600MC-COOLの凄いところですね。

★AutoStakkert!で160コマスタックすると
当日は風が強くて、恒星が踊り狂っていたのですが、品質の悪いコマを選別してくれるので比較的像が安定しているコマを各ファイルから40コマ選別してスタッキングし、それを16ビットTIFFで出力しておいて、ステライメージで4枚加算平均コンポジットしました。要するに、160コマをスタッキングした事になりますね。
・・・すると・・・
f0346040_19205383.jpg
うひゃー!
すんごいなめらか~♪
しかも特殊な画像処理を一切していないのに微細構造が見えてます。
ああ、意図せず「ラッキーイメージング」になっちゃったという訳か!

★さらに手を加えて仕上げてみます
①ステライメージでソフトビニング+デジタル現像+大気差による色ズレを補正+Lab色彩補正
②L画像とRGB画像に分割
③L画像をレジスタックスに回してウエーブレット処理
④ステライメージでLRGB最合成
⑤シルキーピクスでノイズ整列処理+テイスト調整
・・・やっつけ仕事ですが、こんなもんでしょうね。

すると・・・
ででん!
f0346040_19275618.jpg
おお!
とっても良い感じ♪

あ、正しく撮影できてた他の15秒とか30秒とかのファイル使う必要すらなかった・・・。

むむむ。
なんというか、これ・・・
M42の中心部のような明るい天体は、意外と「数秒露光のSER動画保存」が正解なのかも・・・・。
冷却すればダーク補正もいらないし、むちゃくちゃ処理が簡単かつ早い。

以上、せっかく臨時の休日をゲットしたのに空が晴れないので「縮緬ノイズ除去」の『秘策』実験もできず、FireMonkeyの調教からも現実逃避している「軟弱あぷらなーと」の、暇つぶしネタでした。


by supernova1987a | 2016-10-13 19:37 | 天体写真 | Comments(11)

縮緬ノイズ除去に向けて

★『縮緬ノイズ』のジレンマ
天体写真の画像処理で多数枚コンポジットを行った場合に現れる厄介なノイズに『縮緬ノイズ』があります。
例えば、次の写真は昨年にVMC260LとIR改造D5000で撮影したみずがめ座のらせん星雲NGC7293ですが・・・

f0346040_02290934.jpg
一見良く写っているように見えて、拡大してみると・・・・・・

f0346040_02294138.jpg
縮緬状(・・・というかあまりに酷すぎて、もう刷毛状ですね)のノイズがあるのが分かります。
ちなみにこの写真はノータッチガイドで撮影した画像を194枚コンポジットしたものですが、ガイドズレをコンポジット時に修正した結果、本来輝点や暗点になる点状のノイズが流れて刷毛状になったものと思われます。かといって、精密にガイドすれば点状のノイズが出るわけですから、どうにもなりません。

もちろん、根本解決法は、十分な冷却処理や精密なダークファイル除去、そして丁寧なフラット処理などなのでしょうが、対処療法的に改善策はないかと模索中です。

★色々とシミュレーションしていて・・・
ふと縮緬ノイズ除去の妙案が浮かんだので、実践してみようと待ち構えていたのですが、どうも天候と休日が合いません。・・・とか言っている内に月が明るくなってしまいました(泣)。そういえば、この『妙案』の要素を取り入れつつ、夏に撮影していたさんかく座のM33の画像データを再処理してみることにしました。

・・・・とか言いつつ、最近Delphiでの『ソフト開発ごっこ』や『画像解析ごっこ』ばかりやっていて天体画像を触っていなかったので、勘が鈍らないように、たまには画像処理してみよう・・・というのが本音ですが。

★枚数の多さは正義??
今回再処理する撮影データはVMC260L+レデューサにASI1600MC-COOLで撮像したもので、露光15秒から60秒まで織り交ぜ、総画像枚数420枚のコンポジットです。方針として今回は、ノイズを悪化させずに、とにかく点在する赤い星雲を炙り出すことを主眼に処理を施してみました。途中で前述の『秘策』なるものを混ぜてあります。

・・・で、どうだ??

f0346040_03583130.jpg

うーん、
かろうじて自己ベストのM33にはなりましたが、ところどころ暗部の階調が破綻してます。この素材ではこれが限界かなあ・・・。

え?『秘策』の詳細は?・・・ですか。
いや、あの・・・これは本来これは撮影時に施すものでして、今回はたまたま条件に合ったコマを用いただけなのです。
なので、まだ内緒です。撮影時にきちんと実施したら結果報告することにします。

PS
Delphiでの『開発ごっこ』ただいま座礁中(笑)。
ううう、何なんだこの「FireMonkey」っていう、これまでVCLで培ってきた直感を全否定するようなフレームワークは・・・・・。時代についていけません。新しい参考書を買って勉強しないとダメだな、こりゃ・・・・。


by supernova1987a | 2016-10-12 06:40 | 天体写真 | Comments(12)

ASI1600MC-COOLの謎⑤


★ASI1600MC-COOLの謎、再燃

いやもうホント、けむけむさん はじめ 皆さんには「ごめんなさい」としか言いようが・・・・。

先日来、他のユーザーさんと協力して、色んな謎を解き明かしているのですが、そのなかで「解決済み」扱いした課題がありました。
「HighSpeedMode」の『謎』、です。
一応、マニュアルや本家のサイトなどを色々と調べてみて

「HighSpeedMode」は、高速データ転送を優先するために、ADCを12ビットから10ビットに落として撮影するモードである

と結論づけたのですが、なんとなく、
「え~?・・・ホントに階調が1/4にまで落ちているかぁ?」
という疑念があって・・・・こりゃ、早く真面目にテストしてみないと、けむけむさんの「力作マニュアル」に汚点を残すことになるではないか!
・・・というわけで、早速やってみた。


★同等の条件でサクッと比較するための簡易テスト

いつまで待っても晴れそうにないので、もう、室内撮影でデータ取ることにしました。
f0346040_00303813.jpg
ASI1600MC-COOLにニコンGレンズ→マイクロフォーサーズ変換アダプタを通して、マイクロニッコール60mmを装着。
モニタにグラデーションを表示して、これを撮像するという作戦。これなら、すぐにパラメータを変えられます。

なお、変なノイズの影響を極力排除するため、冷却+短時間露光の組み合わせで行きます。

<撮像データ>
Debayer Preview=Off
Output Format=Fits files (*.fits)
Binning=1
Capture Area=4656x3520
Colour Space=RAW16
Hardware Binning=Off
High Speed Mode= <ON /OFF> ←ここだけを変えて『対照実験』してみます
Turbo USB=80
Frame Rate Limit=Maximum
Gain=400
Exposure=0.0017
Timestamp Frames=Off
White Bal (B)=50 ← RGBの強度を補正せず、素のデータを取ります
White Bal (R)=50 ← RGBの強度を補正せず、素のデータを取ります
Brightness=1
Gamma=81
Temperature=-9.8
Target Temperature=-10
Cooler=On

<データ解析>
Delphiでコーディングした自前のFITS分析(というほどでもないけど)プログラムを使います。
もちろん「エンディアン」「FITSの規定」「補数表現」の三大モンスター(バグ)は退治済みです。

★輝度分布グラフの比較
<HighSpeedMode:OFF>
f0346040_01255409.jpg
すごい!前回出ていた『変な群』がほとんどない!!さすが冷却+短時間露光
カラーバランスの補正も切ったことになるので、RとBはほぼ一致。Gが高いのは想定内(画素数が他の色の2倍あるのでカウント数も2倍あって当たり前)。
さて、「ON」にすると・・・・

<HighSpeedMode:ON>
f0346040_01262366.jpg
なぬ?
あれれ?????
ほとんど何も変わらない!!

いや、あの・・・そんなハズは・・・・。
よし、生き残っているデータのビット数を推定するため、有効な階調数を解析してみる!

★輝度分布を超拡大してみる
先ほどの輝度分布データを超拡大して、輝度データの隙間がどう変わっているか見てみます
f0346040_01462853.jpg
うぐぅ・・・
こ、これは、『全く同じ』と言って良いのでは・・・・。
まるで同じ輝度値のところにカウントが来ています。

えーい。
ではでは、相関関係はどうなのだ?!


★輝度値とデータ間隔の相関比較

<HighSpeedMode:OFF>
f0346040_02035620.jpg
ああ、やっぱりノイズが少ないと、美しい相関が現れますね。恐らくはトーンのガンマ通りかと。

<HighSpeedMode:ON>
f0346040_02053007.jpg
げげっ・・・。

ま、全くもって同じ・・・です。
そ、・・・そんなハズは・・・・。
え・・と、ちょっと待って!

・・・ヒットしたピクセルがゼロのデータを削除して、残った輝度数を数えてみるのだっ!!

<HighSpeedMode:OFF>

データ数:4096個
 = 12ビット理論値ピッタリ

<HighSpeedMode:ON>

データ数:・・・4096個(えっ?)
 = 12ビット理論値ピッタリ(ええ~!)


・・・・ということは・・・・


★前言撤回(涙)
今回の検証実験の結果

16ビットFITSに出力する場合において、
HighSpeedModeパラメータはONでもOFFでも
『全く』差がないらしい

ことが検証・・・・されちゃいました。


ううう。じゃあ、・・・じゃあ、あの、マニュアルとかに書かれてた
「HighSpeedModeをONにするとADCは10ビットで駆動する」
とか
「スピードを優先しない場合は、OFFにすべし」
とか、の文言は一体なんだったんだ~???

ん?ひょっとして、これ、
8ビット出力の場合限定のお話だった、なんてオチじゃ・・・・・??

ともかく、皆様、お騒がせしてごめんなさい・・・でした。


★気を取り直して、別な『謎』に・・・・

次回は、『MMだけでなくMCも赤外線通すんじゃね?』疑惑、行ってみます。

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



by supernova1987a | 2016-10-05 05:36 | 天体写真 | Comments(2)

ASI1600MC-COOLの謎④

★ここまで長かったぁ

結局、「エンディアン形式」「FITSの書式」「補数表現」の3匹のモンスターと3週間ほど格闘していたことになりますが、おかげさまで、ようやくまともにASI1600MC-COOLのFITSファイルが読み出せるようになりました。
これで、いろんなパラメータを変えたときに、輝度分布がどうなっているのかとか、シグナルとノイズの見分け方はあるのかとか、色々遊べそうです。
ちなみに、RGBそれぞれの画像データを抜き取るルーチンも実装済みなので、その気になれば「自前RAW現像」できそうです。うひひ・・・・。


★おっと、その前に!!

色々と楽しむ前に、基本を固めておかないとダメでした。
ご承知のようにASI1600MC-COOLは、撮像したアナログデータを12ビットADCで量子化して、最終的に16ビットFITSを吐き出します。
ただし、格納できる輝度空間(明るさのレンジ・階調)が、(2^16)/(2^12)=16 となり 16ビットの16分の1しかありません。さてどのように記録されてるのでしょうか?
・・・・というわけで、やってみた♪


★G素子の輝度分布の「超」拡大

前回のトーンカーブを描いた元データからG1素子(GRBGグループに含まれる2個のGのうち片方)の輝度データを抜き出して、その一部を拡大表示させてみると
f0346040_22555668.jpg
はい。
こんな感じで輝度分布が『飛び飛び』になっているのが分かります。
理論的には、「16」離れた間隔でデータが散らばっていると想像できますが、本当にそうなのでしょうか?今度は少し別な角度から分析してみます。

★輝度間がどれだけ離れているか集計してみる

ヒットしたピクセル数がゼロの輝度値を削除して、「輝度間隔がいくらのデータが多いのか」「輝度と間隔との相関はあるのか」を視覚化してみます。
f0346040_00540946.jpg


※横軸は輝度値、縦軸は輝度間隔を示します。
たとえば、300という値の次が320ならば、間隔は20となりますので、座標(320,20)に1つ点が打たれます。
数値軸は、より広範囲について相関が見やすいように、両対数グラフにしてあります。

これを見ると、輝度が高くなればなるほど、間隔が狭くなっていることが分かります。高輝度データがサチったりトーンジャンプしないように、ガンマ値を調整したと考えればつじつまが合いますね。

ところが、「きれいな相関を示す群」(オレンジ囲い)の上下には「奇妙な分布を示す群」(ブルー囲い)が見られます。これは一体何なんでしょう??

別に根拠があるわけではありませんが、たいていこういったイレギュラーな分布を示すデータは『個人的に』ゴミデータだと思いたいのが心情。その正体がショットノイズなのか、ダークノイズなのか、はたまたリードノイズなのかは分かりませんが、12ビットADCからは『出るはずのない』値が吐き出されているのは間違いありませんねぇ。


★もっと細かく見てみます

実際に、等間隔であるべき狭い領域に、不自然に割り込んできたデータの実例をお見せします。
f0346040_23243887.jpg
表の黄色セルは、他の白いセルに1万個前後のピクセルがヒットしているというのに、たった1~2個のピクセルしか該当していません。どうも胡散臭いですね。右の方対数グラフでも、ほぼ等間隔に並んでいる上の群と異なり、下の群は異質です。
そういえば、前回のブログでお見せした輝度分布図の中に現れてきていた、「変なところにあるデータ」↓と同一なのではないかと推測。
f0346040_00493860.jpg

★あらたな謎も・・・・

もっと比較データを取らないと、はっきりしたことは言えませんが、今のところ暫定的結論として

<ASI1600MC-COOLのADCを12ビット駆動して16ビットFITS出力すると>

 ①16ビットの輝度空間に12ビット分の輝度データが分散配置される。
 ②分散配置される感覚は一定ではなく、輝度値と相関関係がある(ガンマ値次第?)
 ③想定される輝度値と異なる数値を示すピクセルが混じっている(ノイズの影響?)



★ではノイズが出そうにもない条件ならどうだ?

ASI1600MC-COOLは元々ノイズが少ないので、冷却した上に超短時間露光ならノイズの影響はほとんど受けないと思われます。

・・・・で、やってみた。
f0346040_00303813.jpg
ディスプレイに映し出したグラデーションをASI1600MC-COOLで撮影して分析する・・・という・・・。

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


by supernova1987a | 2016-10-04 07:18 | 天体写真 | Comments(2)

ASI1600MC-COOLの謎③

★最新のDelphiでは

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



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

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

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



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

よくよく調べてみると、そもそも符号付き16ビット整数の値は、そのままの値ではなく2の補数表現で記録されていることが判明(汗)。・・・これはもう、「FITSがどうのこうの」という以前の根本的な勘違いでした。
まず正の数、これは普通に記録されているだけです。
ところが、負の数は、次のような手順で記録されていることが分かりました。

 ①絶対値をとる
 ②絶対値を普通に2進数で表す
 ③最上位ビットに0を記録する
 ④全ビットの数値を反転(0は1に、1は0に)させる
 ⑤1を加算する

したがって、ASI1600MC-COOLが出力した値から32768を引いた数値はそのまま記録されるのでなく、さらに補数表現に変換されているというわけです。
たとえば、13298という輝度データは、BZEROシフトで-19380と変換された後、さらに補数表現変換して46156と記録されているのです。

こ、こんなん思いつかんわ~!!(泣)



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

というわけで、今度こそ正しい値を読めるようにロジックを考え直します。
変な汗をかきながら(笑)すっかりアホになっている頭で計算した結論だけを書くと、

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

<今回修正した新ロジック>
上位バイトについて、最上位ビットが1なら256を減じるのみ
下位バイトはそのまま

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


★今度こそ!!

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

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


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




★ASI1600MC-COOLの新たな謎

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

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


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

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

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


by supernova1987a | 2016-10-03 20:34 | 天体写真 | Comments(4)

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

★「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)


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