天体改造C920：土星でテスト

久々の晴れ間に恵まれた6月14日、土星を捉えることができた。

/*******  *******/

改善計画

最初に土星に挑戦したが「納得いかない」結果に終わったのを今見直すと、焦点がちゃんと合っていなかった事の影響が一番大きかった様である。大気の乱れが大きいと、どこで焦点が合ったのか判り辛い。乱れが収まってちゃんと焦点が合った感触を暫く経験していないと忘れてしまうので、「まぁこんなものか」と妥協してしまったのだと思う。こればっかりは失敗と成功を積み重ねる必要があるだろう。安直な解決策は無さそうだ。

予め準備できる事として、キャプチャープログラムを替えた。これについては次で少し詳しく触れる。また今回はWebカメラの設定でコントラストも調整するようにした。多少慣れてきたのでそこまで手が回るようになった、と言うのが正直なところである。白トビ・黒潰れしない範囲で、淡い模様ができるだけ鮮明になるよう調整したところ、私の環境でコントラストは以下のような設定が最良だった。

コントラストを上げると露出が変わるので、「露出」と「ゲイン」も調整しなおす必要がある。大気の乱れが収まった短い時間を捉えられるようシャッター速度を速くしたいので、できるだけ「ゲイン」を上げて「露出」は下げるようにしている。またコントラストにつられて色飽和度が上がるが、今回は「色の強さ」はいじらずに後処理で対応した。

キャプチャープログラムについて

Logicool純正プログラムの利用が最も手軽で安定しているが、どうやっても一旦圧縮された動画を経由することになり、それによる画質劣化の懸念が消えない。また後処理に使うツールによっては無圧縮AVI動画や静止画への変換が必要になり、総合的に考えると「手軽」かどうか疑問が残る。

探せば立派な既成のプログラムが有りそうな気はするが、必要最低限の機能で自分に使いやすいよう割り切ったものなら比較的簡単に書ける。下に示したPythonコードは、起動すると自動的に次の処理を行う。

• カレントフォルダに名前が現在時刻（例：20120614123456）のサブフォルダを作る
• カメラコントロールのダイアログとキャプチャー画像のウインドウが表示される
• 640x360サイズ30FPSで、上記サブフォルダ内に静止画をキャプチャーする
• キャプチャー画像ウインドウが閉じられるまでキャプチャーを続ける

import os, time
import pygame as pg
import VideoCapture as vc

FPS = 30
FILENAME_FMT = "img%05d.tif"

folder = time.strftime("%Y%m%d%H%M%S")
os.mkdir(folder)

cam = vc.Device()
#cam.displayCapturePinProperties()
cam.setResolution(640, 360)
size = cam.getImage().size

pg.init()
fps_timer = pg.time.Clock().tick
screen = pg.display.set_mode(size)

n = 0
run = True

while run:

    for event in pg.event.get():
        if event.type == pg.QUIT:
            run = False

    if run:
        frame = cam.getImage()

        file_name = folder + "\\" + (FILENAME_FMT % n)
        frame.save(file_name)
        n += 1

        surface = pg.image.fromstring(frame.tostring(),
                                      frame.size,
                                      frame.mode)
        screen.blit( surface, (0,0) )
        pg.display.flip()
        fps_timer(FPS)

pg.quit()

コメントアウトされている部分を活かして、その次の行をコメントアウトすれば起動時にキャプチャーサイズを選べるが、そうすると手間が増えて使い勝手は悪くなると思う。当方のWindows Vista + Python 2.7環境で動作を確認しているが、無保証・無サポートである。サンプルプログラムだと思って欲しい。

実際に使ったのは上記をもう少し発展させて、マウス操作でキャプチャーの開始・停止とフルスクリーン表示への切り替え・復帰をできるようにしたものだが、マウスイベントの取り扱いがPygameでは思うようにならない場合があり、意図しないキャプチャーの開始やフルスクリーンからの復帰が起こってしまった。今回は使い方を制限して問題を回避したが、今後wxPythonを使って書き直す予定である。

実効フレームレート

今回は全て画像サイズ640x360で物理画素等倍にズームし30FPSに設定したが、キャプチャーされた画像を見ると同じ画像が数フレーム続いているように見える場合がある。以前にも「露出を上げるとシャッター速度が遅くなり、同じ画像が出力される」と書いたが、それが起こっているようだ。同じ内容が混ざっている画像ファイルをコンポジットすると無駄な処理をするだけではなく、重複したファイルの数に応じて重みが変わるので、結果に悪影響が出る可能性がある。

同じように見えるファイルの内容をfc /bコマンドで比較すると一致するので、ビット単位でファイルの内容を比較し、ユニークなものだけ別のフォルダにコピーするプログラムを書いた。

直焦点では露出をさほど上げる必要が無いためか、同じ内容のファイルはわずかしかなかった。設定通り30FPS出ている。しかしアイピース拡大ではユニークなファイルは全体の1/6しかなく、実効フレームレートは5FPSである。これはキャプチャー時に撥ねたほうが効率的なので、書き直すプログラムに反映しよう。

直焦点の結果

先ずコントラストをいじらない状態で直焦点を試した。下はコンポジット処理前の、比較的良く写っているフレームである。

これを見て「最初とあまり変わらない」と思い、キャプチャーを止めたつもりだった。そしてコントラストや露出を変えてみても「やっぱりダメか」と、アイピース拡大法に切り替えた。アイピース拡大法でキャプチャーを始めようとして、実際にはキャプチャーが止まっていなかったことに気づいた。

ディスクの空きが充分だったので「削除は後でもできる」とファイルを残しておいたのが幸いだった。後で拡大してみると、小さいなりに何か写っている。

RegiStax 6でコンポジットした。大気の乱れで劣化した画像を撥ねるよう、「Limit Setup」を「Lowest Quality 95%」に設定したところ、この状態でキャプチャーした画像合計40フレーム中Stackに利用されたのは19フレームまで絞られた。

輪の輪郭と縞一本は写っているが、カッシーニの隙間は無理なようだ。土星本体の直径が19画素なので、期待するほうに無理があるのかもしれない。

キャプチャーするつもりの無かったコントラスト調整中の画像もコンポジットしてみることにした。下はコンポジット前の、一番良く写っていると思われるフレームである。

細部のコントラストが一番良くなるよう調整したつもりだが、ずいぶん暗い画像になってしまっている。同じような画像が140フレームあり、Stackに利用されたのは20フレームである。前の例よりも利用された率が低いが、元々の明るさが低い分、大気の乱れで劣化した画像が判別し易いのかもしれない。

このサイズでは前とほとんど同じに見えるが、後で触れるアイピース拡大法と大体同じ大きさに画像処理ツールで拡大すると；

カッシーニの隙間が写っているような気がする。撮影時のコントラストを調整したこと、およびより多くのフレームから良像を選んでいることの効果だろう。

アイピース拡大法の結果

アイピース拡大法では、なかなか土星を捉えることができなかった。今回と最初に土星に挑戦したときとの間にもう一回、短時間だが土星を捉えるチャンスがあり、その時Webカメラの代わりにアイピースを使って導入と焦点合わせを念入りに行ったら成功した実績がある。そのため、今回直焦点にあまり時間を割かずにアイピース拡大法に切り替えた。

モニターで見てもかなりイイ感じだったので約6000フレームほどキャプチャーしたつもりだったが、シャッター速度との関係でユニークなものは1085フレームだった。下はその中で良く写っているものの一つだ。

コンポジットでStackに使われたのは80フレームである。

他に比べて色が薄いが、自動RGBバランスの結果こうなったのをいじっていないだけで、特別な意図はない。またWavelet処理はかなり控えめだ。これ以上強くかけると元々あった模様なのかアーティファクトなのか見分けがつかず、かなりウソっぽい画像になってしまうからだ。

以前アイピース拡大法の時の合成焦点距離が約1400mmと書いたと思うが、今回土星の像の大きさを比べて正確に計算すると、リレー倍率3.2、焦点距離f=1600mm、F24.6である。

解像度について

以前の記事の、ぐんま天文台の土星画像を元にシミュレーションした口径65mm望遠鏡の画像と見比べると、アイピース拡大法の画像はシミュレーション結果と同じように見える。これは望遠鏡が合成F24.6なので、画像センサー上の像の大きさ基準でWebカメラの解像度よりも回折限界の方がはるかに低い（像が大きい）ためである（被写体に関する角度基準の回折限界は直焦点と変わらない）。

また今回の直焦点の画像は、アイピース拡大法による画像よりも被写体に関する角度基準の解像度で若干劣るが、コンポジットに使ったフレーム数が1桁違う事の影響、およびコンポジットの位置合わせ精度の影響を考慮する必要がある。

コンポジットの位置合わせは画素単位で行われていると考えられ、位置の推定が完璧でも、その場合最大±0.5画素の誤差がある。そのため倍率の低い画像では位置合わせ誤差が相対的に大きくなり、解像度に与える影響が大きい。

以上を勘案すると、直焦点の解像度はアイピース拡大法より若干劣る、と言うより、あまり違わないと考えるべきかもしれない。実用的には、特にコンポジットを前提にすると、それが可能ならアイピース拡大法（またはパワーメイトなどバローレンズ類）を利用したほうが有利だ。しかし、何か理由があって直焦点で使うことは可能だと思う。

余談

小さな画素ピッチによる高解像度、と言うことに注目すると、PENTAX Qの画素ピッチ1.5μmは大きな魅力だ。天体写真での潜在能力はかなりのものらしい。

メカニカルシャッターが無いことは一つの懸念材料だ。コンピューターとつながっていないことの利点と難点、両方あるだろう。

私も予算が許せばWebカメラよりも優先してコチラを試したいが、マウントアダプターを含めるとそれなりの価格になるのが痛い。

感度について

以前デジタル一眼で土星を撮ったときの条件はF32、T0.7、ISO200だった。それに対して今回アイピース拡大法の条件はF24.6、T0.2（実効フレームレート5FPS）なので、ISO400相当になる。ただしWebカメラの方が画像を構成する画素数が10倍近く多い（土星の直径で60画素対20画素）ことを考えると、意外に高感度だと言えるだろう。

数値もさることながら、今回のアイピース拡大法による土星は露出もゲインも最大にする必要があり、これがほぼ限界である。土星は、今回天体改造したWebカメラの最も淡い被写体だと思われるので、ある意味ちょうど良いのかもしれない。散光星雲など深宇宙天体向けにToUcamの長時間露光改造が昔流行ったようだが、今日のWebカメラは専用ASICで出来ているので、ハードウエア改造はほとんど不可能である。

今回のまとめ

解像度・感度ともに当初の予想に近い結果が得られたと思う。どちらも「ぎりぎりセーフ」と思っていたが、直焦点の解像度は実はアウトで、アイピース拡大法の感度はセーフだったから、一勝一敗と言ったところだろうか。

これで改造Webカメラの確認事項は一通り済んだことになる。これからは実用に向け、プログラムを整備したり晴天を願って精進したりするわけだ。

しかしC920でなければならなかったのか、と言う点は残された疑問だ。H.264エンコーダーもステレオマイクロフォンも使っていない。キャプチャーサイズは主に360pである。C270でも充分だったのではないか？ もしそうならコストパフォーマンス5倍だ、と言う計算は、実は間違っている。もうC920を買っているので、新たにC270を買っても2倍使える訳ではなくパフォーマンスは変わらない。コストだけが増える。

そう判っていると言うことと、その通り行動すると言うことは、必ずしも一致しない。気になることは確かめたいし、PENTAX Qに予算は付かなくてもC270なら何とでもなる。なーに、C920は地上用に戻せばいいさ・・・これでまた人柱かなぁ。