あぷらなーと


あぷらなーとの写真ブログ
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 23:18
子供の科学は読んでなかっ..
by kem2017 at 16:39
> オヤジさん オヤジ..
by supernova1987a at 07:38
あぷらなーとさんも、子供..
by オヤジ at 06:19
> kem2017さん ..
by supernova1987a at 23:59
藤井旭先生の「星雲星団ガ..
by kem2017 at 21:40
> にゃあさん 設..
by supernova1987a at 02:22
> HIROPONさん ..
by supernova1987a at 23:13
もっと気軽に遊べるソフト..
by にゃあ at 23:01
> kem2017さん ..
by supernova1987a at 22:58
以前の記事
お気に入りブログ

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

異種混合作戦①

★結局9月と10月は・・・

まさかの天体観測実績0日(涙)
もう、どうしようもないので、過去の画像をいじくることにしました。


★意外とD5000は優秀で・・・

VMC260Lでの天体写真はIR改造D5000を入手してから本格始動したわけですが、そこからD810AやらASI174MC-COOLやらに進んだ後、現在のASI1600MC-COOLに落ち着きました。
ただし、オリオン座の大星雲M42をASI1600MC-COOLで撮影したのが8月末なので、薄明前で高度が低くシーイングも悪かったため、どうもシャープさに欠けていました。

あらためてD5000で去年撮影したM42を見直してみると、シャープ処理をする以前に格段に星像が引き締まっていて品質が高いことに驚きました。


★D5000によるM42
f0346040_00321687.jpg
※VMC260L(レデューサ無し)+IR改造D5000 ISO1600・20秒露光の144コマコンポジット

・・・われながら凄い写り。それにラチチュードがとても広いのですね。トラペジウムが星雲に埋もれずギラギラ輝いてます。
ただし、周辺の分子雲がイマイチ出ていません。
・・・そこで!
8月にASI1600MC-COOLで撮影した画像を合体させるとどうなるか、やってみることにしました。

★ASI1600MC-COOLによるM42
f0346040_00371401.jpg
※VMC260L+レデューサ+ASI1600MC-COOL ゲイン400 5秒×100 10秒×100 のコンポジット


★異種混合の場合、ちと工夫が必要
ここで問題があります。実はCMC260L自体のレデューサ有無はもちろんのことカメラが異なりますので、そのままでは倍率が異なり上手くコンポジットできません。

・・・そこで・・・

①ステライメージで基準星2点間の距離(ピクセル数)を測定し、画像の倍率比率を算出

ちなみに、D5000で2959.0ピクセル離れている星がASI1600MC-COOLでは2910.6ピクセル離れていることが分かりました。
そこでASI1600MC-COOL側の画像解像度を1.0166で割ることで見かけの倍率をそろえてみました。

②ステライメージでコンポジット

先ほどの基準星2点を再度指定しコンポジットをすることで、画像の回転ズレも補正できました。

・・・・さて、上手く重なりますでしょうか・・・・?

★D5000+ASI1600MC-COOLによるM42
f0346040_00460724.jpg
おおっ!
とても上手く重なりましたよ♪

目論み通り、中心部もモクモクもよく写っています。

さて、次はこの画像を元に解像度を限界まで引き上げてみます。
はい。一度L画像とRGB画像に分解して、レジスタックスの投入です。


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


by supernova1987a | 2016-11-01 00:52 | 天体写真 | Comments(8)

ステライメージのマスク処理を使ってみる

★VMC260Lの画像処理に疲れたので

8月末に撮影していたD810A+シグマ20mmF1.8の画像を引っ張り出してきて、遊んでみました。
ちなみに元画像はこんな感じ。
f0346040_01351086.jpg
※ニコンD810A+シグマ20mmF1.8 絞りF2.8 ISO1600 露出30秒 RAW
 キャプチャーNXDで現像(アストロノイズリダクション使用)ダーク減算無し

天の川とともに、すばる・ヒアデス・M31・二重星団・カリフォルニアなどなど、「おいしそうな天体一網打尽の図」ですなぁ。

★ちょうどヒアデスとプレアデスの左側に・・・
画像を拡大して観察してみると、なにやらモクモクした領域を発見。
ネットで調べてみると、このあたりには分子雲がウジャウジャいるみたいですね。
f0346040_01393859.jpg
ちょっとわかりにくいですが、上記画面の下中央から画面上部にかけてアヒルの足形のように薄暗い模様が見えます。それが「モクモク」。

★ステライメージ+シルキーピクスで画像処理
まずは、キャプチャーNXDでアストロノイズリダクション+1段増感して現像したTIFFファイルをステライメージで28枚加算平均コンポジット。
これをデジタル現像して最低限の画像処理を施した後、いつもの「L画像とRGB画像」に分割。
その後、私が苦手としている「星マスク」をかけてトーン修正やレベル修正などをゴニョゴニョ実行。
できあがったTIFF画像をシルキーピクスに転送して、色彩を強調した後HDR処理を実行。
再びステライメージに戻って微調整。
すると・・・・

ででん!
f0346040_01463283.jpg
なるほど、たしかにモクモクの正体が分子雲らしきものだと分かりますね。
まあ、分子雲に関しては名手の方々が大勢いらっしゃるので、とてもその域には達していませんが、真面目に撮影すればあぶり出せそうな「気配」がしてきました。
今回はフルサイズデジタル一眼+20mmという超広角画像からのトリミングですが、これを35mm程度のレンズ+ASI1600MC-COOLでたくさん撮影して多数枚コンポジットすれば面白そう♪

しかし、マスク処理って難しいなぁ・・・・。
え?レイヤー処理はしないのか、ですって?
いやー、たしかにフォトショがなくてもGIMPやエレメンツでレイヤー処理は出来ますし職場でちょっとしたチラシとかを作成するときは多用してますが、最近色んなソフトをいじくり回ってるので、頭がパンクしそうです。

・・・という訳で、今回の休日も「晴れたら撮影したいこと」の画像処理予行演習で終わってしまいました。


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

なめらかなオリオンはいかが?

★AutoStakkert!2のおかげで
一度はゴミ箱行きかと思われたオリオン座大星雲M42の5秒露光×200コマのデータが蘇ったのがうれしくて、せっかくなので元々正しくFITSで保存されていた10秒露光のコマ×100コマと合わせて真面目に画像処理してみることにしました。せっかくの休日前夜なのに雨がザーザー降ってるので、現実逃避♪

今回の方針は
 ①トラペジウム近辺をサチらせない
 ②できるだけ周辺部も拾い上げる
 ③荒れない程度に「もくもく感」を出す
です。

<撮影データは>
VMC260L+レデューサVMC+LPS-P2フィルタ (1860mmF7.1 相当)
ASI1600MC-COOL 冷却温度-12℃前後 ゲイン400
K-ASTEC改造Newアトラクスでノータッチガイド
露光5秒×200コマのうち良像100コマ
露光10秒×100コマ
といったところです。

★10秒露光1コマをレタッチすると
f0346040_06584324.jpg
RAW画像をステライメージでデモザイク+ソフトウェアビニング+デジタル現像+Lab色彩調整+レベル調整しただけです。
いや、たったの10秒でこれだけ写っちゃうASI1600MC-COOL恐るべしなのですが、中心部はサチってますし、全体的にボロボロに荒れてます。

<下ごしらえ>
 A群:露光5秒で(誤って)動画保存しちゃったSERファイルを
    AutoStakkert!2でスタック+ステライメージで加工(ダーク減算なし)
 B群:露光10秒のFITSファイルを
    ステライメージで100コマコンポジット+調整(ダーク減算あり)

<本処理>
 ①ステライメージでA群とB群を加算コンポジット
 ②ステライメージでレベル調整+デジタル現像+Lab色彩調整
 ③ステライメージでL画像とRGB画像に分解
 ④ステライメージでL画像について最大エントロピー画像復元+トーン修正
 ⑤ステライメージでLRGB最合成→16ビットTIFF保存
 ⑥シルキーピクスでホワイトバランス+テイスト調整
 ⑦シルキーピクスでノイズ整列処理
 ⑧シルキーピクスで軽くHDR処理
 ⑨シルキーピクスでテイスト調整など微調整→TIFF保存
 ⑩ステライメージで周辺減光補正
 ⑪ステライメージでバックグラウンドスムーズ処理
 ⑫ステライメージでスターシャープ処理
 ⑬GIMP2で微調整
といったところです。


★悪戦苦闘の末・・・

さて、果たしてややこしい画像処理の結果、どうなりますでしょうか?

・・・ででん!
f0346040_07202402.jpeg
おお、これなら自己ベストのM42と言えそうです。
複雑なモクモク構造がたまりません♪

ああ、疲れた。
気が済んだので、少し寝ます(笑)。


by supernova1987a | 2016-10-17 07:26 | 天体写真 | Comments(6)

AutoStakkert!2に慣れる②

★AutoStakkert!2が面白いので

5月にASI174MC-COOLで撮影した月面を再処理してみました。

今回は真面目にdrizzleや画像選別もやってみます。
なお撮影はVMC260L直焦点+ASI174MC-coolです。

<元画像(動画)データ>
[ZWO ASI174MC-Cool]
Pan=0
Tilt=0
Output Format=AVI files (*.avi)
Binning=1
Capture Area=1936x1216
ColourSpace=RGB24
High Speed Mode=On
Turbo USB=80
Flip Image=None
Frame Rate Limit=Maximum
Gain=200
Exposure (ms)=0.010609
Timestamp Frames=Off
White Bal (B)=99
White Bal (R)=60
Brightness=0
Gamma=79
Sensor Temp=-12.5
Cooler Power %=25
Target Temperature=-15
Cooler=On

★スタックした画像の選別効果を見る
AutoStakkert!2に限った話ではありませんが、スタックする前に画像の品質を解析して「品質が高い順に何%分の画像をスタックするか」を設定できます。

早速、この効果をチェックしてみます。
条件を変えてスタックした画像をコペルニクスクレーターで比較してみましょう。

f0346040_19275192.jpg
スタック用の画像は約400コマの30秒間AVI動画ですが、左から順に
 左:全コマスタック
 中:50%スタック
 右:12%スタック
となります。たしかに、右に行くにつれて鮮明度が増すことが分かりますね。
ちなみにスタック時にはDrizzle×3を掛けています。

★画像復元の効果
ここからステライメージに回して画像復元を試みます。
(本来ならレジスタックスに回してウェーブレット処理するところですが、どうも月面のウェーブレット処理が苦手なので)
f0346040_19384413.jpg
左から順に
 左:スタック直後の画像をソフトウエアビニングしたもの
 中:さらに最大エントロピー法を用いて画像復元したもの
 右:さらにアンシャープマスクをかけたもの
です。

個人差はあるでしょうが、やっぱり私は月面の処理には最大エントロピー法+アンシャープマスクが好きですねえ。


★トリミングして仕上げます
画面の周辺は画像復元のエラーで変なゴミが生じますのでカット。
さらに画面の傾きを補正してトリミングして仕上げると・・・。

f0346040_13452714.jpg

おお!なかなか良い感じ♪
以前の処理よりも自然でシャープになりました。

月面は写真よりも眼視の方が圧倒的によく見えるのですが、これでだいぶ眼視に近づいてきましたかね?

うわ~。こんどは久しぶりに月面撮りたくなってきた。(当面無理ですが)
ASI1600MC-COOLではどんな風に写るんだろう??


by supernova1987a | 2016-10-15 05:01 | 天体写真 | Comments(10)

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)


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