エンジニア徒然草

天体改造WebカメラでIRカットフィルターなしの場合を考える

mitaka1954 — 2012-05-24T16:48:37+09:00

天体改造する時レンズと一緒に取り外したIR（赤外線）カットフィルターの代わりにIDAS LPS-P1フィルター（現行はP2）を使っているが、どうも思わしくない。カラーバランスやレタッチでは修正しきれない色合いの変化や、フィルター倍率2（ISO感度が1/2）程度の感度低下がある。メーカーは従来型では不可能だった連続スペクトル型の天体もOKだと言うが、やはりこの種のフィルターは輝線スペクトル（単色光）を主体とした天体向きであって、連続スペクトルの被写体ではどうしても前述のような影響が出てしまう。もしかすると現行P2は、私の使っているP1より改善されている可能性があるが、全く影響が無いとは思えないし、買い換えて試すには高価だ。

元々ついていたのと同じような特性のフィルター、例えばBaaderのUV-IRカットの様な特性でもっと安価なものを探しているが、見つかるまでの間フィルター無しで何とかならないかと考えた。色合いはレタッチなどで何とかごまかして我慢すると、長い波長の光に関する分散（屈折率の違い）の問題が残る。これは純粋に反射鏡だけで出来ているニュートン式などでは発生しない問題だ。

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

画像センサーの分光特性とIRカットフィルター

シリコン製画像センサーは、特にフィルターなどを使わないと可視光の範囲（380～750nm）を越えて光を検知することができる。波長の短いUV（紫外線）側は350nm位が限界で眼とさほど違わないが、波長の長いIR（赤外線）側は1000nm（1μm）近辺までの広い範囲に反応するのでフィルターでカットしないと眼で見たのと同じ画像にならない。

代表的なIRカットフィルターは、650nm近辺よりも長い波長の光を遮断する、急峻な特性になっている。

Source: http://www.olympus-ims.com/ja/microscope/dp72/

上の図（見辛いのはご容赦）で「IR Cut Filter」の曲線が610nm近辺で「R」の曲線と入れ替わっているので注意して欲しい。「R」チャネルの長波長側特性はIRカットフィルターで決まり、それによって眼の特性と合わせられているのである。上の図では切れてしまっているが、IRカットフィルターが無いことを想定すると700nmよりも長波長側の特性も重要だ。

下は原色カラー画像センサーの特性の一例である。補色の場合はCyan=Green + Blue、Yellow=Red + Green、およびMagenta=Red + Blueと考えれば良いはず。また「Green」のプロットに2種類あるのは、Blueと同じ列あるものとRedと同じ列にあるものを区別している。

Source: http://www.cs.washington.edu/education/courses/cse467/08au/pdfs/lectures/07-cmos-ccd-imagers.pdf

この例では、実際にはIRカットフィルターで阻止される650nmよりも長波長側でGとBチャネルの感度が上昇し、約850nmよりも長い波長ではRGB全てのチャネルの感度が同じになっている。多少差はあるが、ほとんどの画像センサーはこのような傾向がある。その証拠に赤外線リモコンの発光部をデジタルカメラ越しに見ると赤紫がかった白色をしている。リモコンの発光部は輝度が高いので、IRブロックフィルターで阻止し切れなかった波長940nmの光が見えているのだ。デジタルカメラでは、GよりもRおよびBチャネルの明るさが少し低い状態が白く見えるように造られているので、RGB全て同じ明るさの光は少し赤紫（マゼンタ）がかった白色に表現される。

一般のカメラのように可視光だけを対象とした製品では650nmよりも長い波長の光はIRカットフィルターで実用上見えないよう阻止しているが、監視カメラなどでは850nm付近の感度を利用して、赤外線投光器と併用することで白黒だが夜間の実用性を確保している製品がある。この場合、可視光の範囲と850nm付近の光を通すような特殊なフィルターが用いられているらしい。上の図で850nm付近の感度は、可視光感度の基準になるGチャネルのピークに対して0.8程度と低くなっているが、このような監視カメラではもっと850nm付近の感度が高い画像センサーの方が有利である。

下の浜松ホトニクス(株)製Siフォトダイオードの分光特性に見られるよう、光半導体としてのシリコンそのものの850nmの感度は、可視光の中心よりも2倍近く高い（一番上のS1087-01などの曲線）。

Source: http://jp.hamamatsu.com/products/sensor-ssd/pd041/pd050/pd052/S1133-14/index_ja.html

Webカメラに使われる画像センサーはほとんどが1/4および1/3型だと思われ、小型監視カメラに使われるサイズと重なっている。そのため監視カメラ用途でも優位性があるよう850nm付近の感度を高めたセンサーがWebカメラにも使われている可能性があるだろう。可視光専用の製品ではIRカットフィルターに切られてしまうので、650nmより長い波長の特性はどうなっていてもあまり関係ないからだ。この場合、可視光より850nm付近の感度の方が高くても不思議ではない。

この場合の問題は、可視光に焦点を合わせると850nm付近の光では焦点が外れる、と言うこと。近赤外線を含む連続スペクトルの像は、焦点の合った可視光の像にボケた近赤外線の像が重なるはずだ。

近赤外線に焦点が合わない

銀塩しかなかった時代、風景写真を波長750nm近辺の近赤外線に感度のある赤外線フィルムで撮影するテクニックがあった。モノクロだが、非日常的な表現ができる。また昼間でも晴れていると空が夜のように黒く抜けるので、モノクロ映画の夜景シーンの撮影にも使われていたと聞く。
この場合、焦点合わせに注意が必要だった。波長750nmの近赤外線ではレンズの屈折率が小さくなり、焦点距離が伸びる。そのため、レンズの距離目盛を赤外マークに合わせなければならない。一眼レフなら一度ファインダーで焦点を合わせ、その距離を赤外マークに合わせ直すことになる。

上はSMC PENTAX-A 1:1.7 50mm、そして下はSMC PENTAX-M 1:4 200mmレンズで赤外マークに無限遠を合わせた状態である。この状態で可視光の焦点が合う距離から、レンズの公式；

を使って波長750nmの近赤外線での焦点距離を計算すると、前者が約50.2 mm、後者は約201mmに伸びていることが判る。伸びはそれぞれ0.4%および0.5%である。レンズの構成によりこの量は様々だと思われるので、概ね0.1%台と想定するのが安全だろう。これなら波長が多少異なっても議論の行方は変わらないと言える。なお50mmのレンズではF5.6、200mmはF22まで絞ると可視光と近赤外線の焦点距離の違いが被写界深度に収まる。長焦点レンズでは実用的ではないが、短焦点レンズでは近赤外線領域まで含めパンフォーカス的に出来るので、先に触れた夜間は赤外像を写す監視カメラはこのような造りになっているのではないかと思う。ただし、天体望遠鏡に被写界深度と言う概念は無いし、全てが長焦点なので、この議論は当てはまらない。

Webカメラ改造の過程で、テストで地上の風景をIRカットフィルター無しで見たとき白く靄がかかったようになったのは、以上のことが原因だと考えている。それ以来、ファーストライトの金星を除きIDAS LPS-P1フィルターを併用してきたが、ファーストライトの時に白く滲んで見えたのは単に露出オーバーだったのではないか、と言う疑念が出てきた。それを確かめるため、可視光と近赤外線に対して感度が同じセンサーの場合について、どんなボケた像が見えるのかシミュレーションしてみた。

焦点から外れた点光源の像

正確に計算すると、こうなるらしい。

Source: http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Spherical-aberration-disk.jpg

一番上の段が負の球面収差のある場合、真ん中が球面収差の無い場合、一番下が正の球面収差のある場合で、中央の焦点の合った場合の列をはさんで、左が内側（レンズ側？）、右が外側に焦点を外した場合、だそうだ。

数式表現を探したが見つからず、導出するのは私の手に負えないので、幾何学的直感に従い均一な明るさの円盤になると近似した。レンズの口径をDとし、焦点距離f=fv+xの時、レンズからfvの距離に直径d=Dx/(fv+x)の均一な明るさの円盤像が出来るとした。

乱暴な近似だが、像の明るさのある程度広がりのある部分の平均を調べるのには使えると思う。厳密に判らないと答えは出せない、と言うよりはマシである。これを視覚化すると；

上の段は可視光と近赤外光で焦点距離が変わらない、純粋に反射鏡だけでできた望遠鏡のような場合。可視光像（シアン）も近赤外像（マゼンタ）もエアリーディスクを形成するが、波長の違いに応じた大きさになり、明るさはエアリーディスクの面積（直径の二乗）に反比例する。左の図は、見易いよう100x100μmの範囲を拡大している。なお条件は私の望遠鏡に合わせてD=65mm、f=500mm（F7.7）である（以下同様）。

下の段は、近赤外線波長の焦点距離が可視光の場合に対して0.1%伸びるとして計算したもの。0.1%に特に根拠は無いが、あまり荒唐無稽で無い範囲で、次のシミュレーションで判り易い結果が出そうな値を選んだ。近赤外像の大きさは前述の通りで、明るさは面積分した場合にエアリーディスクと同じになるよう計算した。左の図は計算通り色付けすると見分けられないので、計算よりも5倍色を濃く表示している。

上段が可視光と近赤外両方とも焦点が合っている場合、下段が近赤外光だけ焦点が0.1%外れている場合の二次元インパルス応答に相当し、これを用いて幾何学的に期待される完璧な像がどのようにボケて見えるのか計算した。また右下の断面プロファイルから、最近カメラレンズについて議論されることの多いMTFも計算してみた。

近赤外の方は、断面プロファイルが矩形になるような乱暴な近似をしたのでMTFが|sin(x)/x|のカーブになってしまった。本当は可視光の曲線のように滑らかで、空間周波数30/mmあたりでほとんどゼロになる曲線ではないかと思われる。

シミュレーション

最大離角の金星を想定して、その時の見掛けの大きさ23.5”と焦点距離500mmから期待される半円形の像がどうボケるかシミュレーションを行った。もとになった半円形の像は次の通りである。

黒い部分の外周の1辺が100μmになるよう、視野を合わせている。この像の上の全てのメッシュを中心とする、先に示したインパルス応答を足し合わせると、求めるボケた像が得られるはずだ。

図に示した項目はインパルス応答の場合と同様だが、今回は左側の図で色付けを強調していない。

広がりのある像のある一点の明るさを考えると、その点の像がボケて広がっている場合でも、その点からボケの広がりの範囲内の他の点からの光が入ってくるため、明るさはあまり減少しない。ボケの大きさに比べて充分大きな像の内側では、ボケていない場合と明るさは変わらないはずだ。今回想定した焦点の差0.1%では、点像がボケてできる円盤の大きさより金星の像の直径がやや小さい。また円ではなくて半円であることも加わり、可視像の中の近赤外線の明るさが40%になったのだと考えられる。

可視像の周りに出来るはずの近赤外線の「後光」を見ると、ファーストライト時の画像はこれほど広がっていなかったように思える。

見直すと「滲み」は最大解像度720pでフルスクリーンにして、ようやく判る程度だ。また大気の分散のせいか、可視像より右側（地平線側）にずれている様である。前のシミュレーションの、焦点距離が変わっていない左上側の図に大気の分散が加わって近赤外像がずれただけのように見えるが、これは少しおかしい。

ファーストライト直前にテストで撮った動画2本も見てみよう。先ずテスト動画1；

そしてテスト動画2；

どうやら｢ファーストライト｣と称している動画は、露出オーバーで白飛びして、その周りにフレアが出ている、と考えたほうが正しそうだ。IRカットフィルターが無いとRチャネルの波長領域が広がった分、画像が赤っぽくなるのが正常だが、RGB全てのチャネルが飽和してしまって白く写ったのだろう、と言うこと。今思うと、なぜテストの時と露出を変えてしまったのだろうという疑問があるが、恐らく露出を変えてみて、この方が適正と誤った判断をした可能性が高い。

今回シミュレーションした850nm付近の成分のボケは、うしろ2つの動画を見る限り影響していない様である。これには2つの原因が考えられ：(1) 入射光量 x 感度が可視光に比べて小さい、および (2) 850nmの焦点距離の伸びが0.1%よりも大きい（0.3%以上？）、後者の影響が大きいのではないかと思われる。

焦点距離の伸びを0.3%にしたシミュレーション結果を以下に示す。

「後光」の全体を収めるため、左側の図の1辺は250μmにした。「後光」の部分の明るさは、可視像の最大の明るさの約5%である。これが動画に写っていないとなると、ちょっと困ったことだが、実際にそれが起こっている疑いがある。

私の使っているLogicool HD Pro Webcam C920は、全ての設定を手動で出来るようになっているが、最大ゲインが足りないようだ。

Webカメラを完全な暗黒環境に置くと、この設定パネルをどういじってもセンサー自体のノイズが見えるようにはならない。つまり、ノイズぎりぎりの信号は捉えられない。あるいは最低の明るさの光が入射しているかもしれないと判断するセンサーの出力レベルの基準が、どこか内部で少し高めに設定されているのかもしれない。いずれにせよ、ノイズよりも充分大きな信号でないと完全な暗黒として取り扱われてしまっているようなのだ。個体差や温度変化へのマージンをとる目的もありそうで、もしかしたら私の分は個体差で一番感度の低い部類になっている可能性もあるかもしれない。

天文用途にはあまり向いているとは言えないが、Webカメラの場合このあたりの作りがどうなっているのか、公開されている仕様から判断するのは難しく、実際に購入して確かめるしかない。今回、少なくとも感度に関しては失敗したかなと思うが、これなら良かっただろうと確信の持てる機種がある訳ではないし、もしかしたら最近のWebカメラはどれもこんなものではないかとも思うので、もう暫くこのカメラでどこまで行けるかやってみようと思っている。

今回のまとめ

IRカットフィルターの話題だった。

フィルターを取ってしまったことで波長850nm付近の近赤外線が悪影響を与えるのではないかと心配したが、広い意味の色収差が充分大きくなるの、少なくとも金星程度の大きさの天体ならでほとんど影響が無いだろう、と言う結論になった。今は確かめられないが、木星でも大丈夫だろうと思われる。恐らく影響がわかるとしたら月と太陽だけだろう。

ただしIRカットフィルターが無いと、今回はごまかすことにしてしまった色合いはイマイチ不自然な感じにしかならない。これはIDAS LPS-P1をIRカットフィルター代わりにしても同じだが、不自然さのベクトルはかなり異なる。と言うことで、そう遠く無い将来装着する方向で考えている。水素のバルマーαに特別なこだわりは無いから、一般的なデジタルカメラ用のフィルターでかまわない。

余談の感度の件だが、この時期の火星は確認済み、OKだ。恒星は4等星まで確認済みで、それよりも暗い星は試していない。土星は何回かf≒1400mm/F21.5にアイピース拡大した状態で試したが、未だ捉えていない。同じ条件でデジタル一眼ならOKだったので、カメラ感度の問題である。どうもこのあたりに限界があるらしい。見えたらいいなと思っていた対象だけに、残念だ。直焦点F7.7なら写るのではないかと思うので、試してみようと思っているが、こんな場合に限って待ち構えている夜は晴れないものだ。

Webカメラ＋火星でピリオデックモーション測定

mitaka1954 — 2012-05-21T13:07:45+09:00

シーイングの悪い夜、大気の乱れが収まる兆候はないかと期待しながらWebカメラ越しに火星を眺めていたら、ゆらゆら揺れている火星がスーッと視野の端に近づいた。「極軸合わせをしくじったかな」と思って見ていると、3分位で今度はスーッと戻ってきた。おやおや、これは間違いなくPE（Periodic motion Error、ピリオデックモーション）だ。極軸がずれている場合は行ったきりで、こんなに短期間で戻ってくるはずは無い。

シーイングが改善しそうも無いので今夜はPE測定にしよう、と言うことで、カメラの向きを出来るだけ正確に上=北、左=東に合わせ、ウォーム2回転分、20分間の動画を撮った。先ずは直感的に把握するため、30倍のコマ落とし、今風に言うTime-lapse Videoを作ってみた。

目見当だと直径数個分かな。これは情緒に訴えるには良さそうだが、定量的に測るのには不向きだ。最後のほうで暗くなっているのは雲がかかったせいである。

今回はこの動画を元に出来るだけ正確にPEを測ってみた。また主な原因がわかったので、その対策も併せて紹介しよう。

画像などデータ処理には、動画の変換にffmpegを使ったほかはプログラミング言語Pythonで短いコードを書いた。Pythonは道具として使うには最も適したプログラミング言語の一つで、覚えておいて損はないと思う。これは各種ライブラリーモジュールが充実していることが大きく寄与している。今回使った主要なライブラリーモジュールは以下の通りだ。

数値処理：numpy

視覚化：matplotlib（SciPy/PyLab）

動画表示：PyGame

動画・静止画キャプチャーなど：OpenCV、VideoCapture

静止画の加工：PIL（Python Image Library）

なおPythonやそのライブラリーモジュールについては、解説やドキュメント類がインターネット上に豊富にあるので、そちらを参照してほしい。

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

伝統的方法のエミュレーション

伝統的PE測定手法は、極軸をわざと東西どちらかにずらして、南中前後の天の赤道付近の恒星を長時間露光するものだ。こうすると、PEが無ければ概ね南北一直線に流れて写るはずの星像が東西方向にくねくねする振れ幅でPEの量を測ることができる。視野の中で角距離のわかっている恒星のペアを角度の基準にする。例えばこんな具合；
http://katabami.blog.so-net.ne.jp/2007-01-08
http://ponkotu-gg.cocolog-nifty.com/blog/2008/08/post_ecde.html

これをエミュレートするため、縦長の真っ黒な背景を用意してコマ落とし動画の各フレームを1ピクセルずつ下にずらしながら比較明合成を行った。従って時間の経過は上が古く、下が新しい。時間の経過が判りやすいよう、60コマ、すなわち1分毎に輝度を強調している。

ぱっと見、火星の直径の4～5倍振れていることがわかる。ウォーム1回転に1回、30秒くらいの間に火星3個分位動いている場所があり、これは見るからに何かがおかしいと思える症状だ。
もう一つ気になるのは全体としてナナメになっていること。これはウォーム1回転によりもっと長期的な追尾誤差の存在を示唆している。火星が画面で西に逃げているので追尾速度が僅かに遅過ぎる。先ず思いつくのがモータードライブの回転数誤差だが、これを制御している水晶発振回路の出力周波数をカウンターで測ると恒星時で追尾するのに必要な周波数に対してプラス0.01%弱の誤差がある。ナナメ加減から予想される数値に対して絶対値で1桁程小さいし、そもそもこれは早過ぎる方向の誤差なので、関係無さそうだ。これ以外の原因もいくつか思い浮かぶが、確かめる方法が無いので原因追究は保留しよう。

PEの量を測る角度の基準に火星の直径を使うつもりだったが、この画像から正確な数値を求めるのはちょっと無理だ。コンポジットした画像を作るべきだろう。伝統に則るとPEも画像の画素数を目で追うことになるが、画像は既にデータなので機械に画素を数えさせてしまえ、と言うことで合成前各フレームの火星の像の横方向の直径と中心位置を測ってプロットするPythonプログラムを書くことにした。

画素を数えるプログラムの概念

FFTを利用することも出来そうだが結果の解釈をしくじると悲惨な結果になるので、もっと素朴な直感的に間違いの無さそうな方法にした。各フレームの画像毎に以下の様に処理する。

画像を「RGBモード」から「Lモード（白黒）」に変換する。これにより画像は[縦の画素数, 横の画素数]の大きさの2次元配列データとして扱える。
画像を「火星の像の部分」と「背景」に2値化する。配列全体の最大値（最も明るい画素の値）の10%よりも大きな画素を「像の部分」とし、それ以外を「背景」とする。ここの閾値が、この処理で唯一任意に調整できるパラメータである。
火星の像がかかっている配列の各行について「像の部分」に該当する列番号の最小値と最大値を求め、横幅＝最大値―最小値＋1、および中心位置＝（最大値＋最小値）÷2を計算する。
横幅の最大値をそのフレームの像の直径とし、最大値が得られた行の中心位置をそのフレームの像の位置とする。

numpyを利用すると各段落の処理はほとんどが1～2行で書ける。ただし段落3の処理は配列の行数分のループ制御および条件分岐があり、段落4の処理と合わせて9行必要だ。また配列行数分のループ制御などをPythonで書いているので全体の処理は遅いが、20分間のデータ処理が3分程度で終わるので許容範囲だと思う。

各フレームについて計算した値から、動画全体について直径の平均値と位置の振れ幅（最大値―最小値）を計算している。

長期的な追尾誤差がありそうだと判っているので、中心位置の時間変化について直線回帰式の係数を求め、それから推定した各時点の長期的追尾誤差の量と、長期的追尾誤差を差し引いた正味PEの量を計算した。正味PE量についても振れ幅（最大値―最小値）を計算している。

結果のプロット（可視化）

計算の結果を時間に対してプロットした。主要な数値などは凡例内に示している。

位置のプロット（赤の実線）は、基本的に比較明合成画像を横倒しにしたものだが、目盛りが入って数値で語れることの違いは大きい。300秒付近で追尾速度がスーッと速くなり、像が数十画素左にずれている。500秒付近で、今度は何かにガツンとぶつかったような唐突な感じで追尾速度が遅くなり、像が数十画素右にずれたことが読み取れる。また同じことが900秒付近および1100秒付近で起こっていることもわかる。

長期的追尾誤差（赤の破線）は20分間で火星の直径1つ分ずれる程度だ。これを差し引いた後の位置の変化（青の実線）は、平均が300画素の位置になるようプロットしているが、概ねウォームの回転に伴う周期的変動になっているように見える。ただし、ウォームの回転より短い周期で変動する成分も相当量あるようだ。

プロットがランダムに数画素程度変動していることが判る。これは大気の乱れによる像の歪みが現れているもので、シーイングが悪いほど変動幅が大きくなる。また最後の30秒間の値が上昇しているのは、火星が雲に隠され像が不鮮明になった影響ではないかと思われる。

凡例に示した数値などは、大気の乱れや雲に隠されたことの影響を考慮していない。これは明らかに手抜きだが、考慮しようとすると結構煩雑だし恣意的な操作も出来てしまうので、このままにしておく。pk-pk値（最大値―最小値）は大気の乱れの分大きく出るが、平均値はほとんど影響を受けていないはずだ。この事を念頭にご覧いただきたい。この夜の火星の見かけの直径10.2秒角が61.2画素に写っているので、

周期的追尾誤差＝±(10.2×195.6÷61.2÷2)＝±16.3秒角
長期的追尾誤差＝10.2×0.0458×1200÷61.2＝9.16秒角/20分
総合的追尾誤差＝±(10.2×233.0÷61.2÷2)＝±19.4秒角/20分

見た目で覚悟していたよりも小さめの数値でホッとしたが、決して誇れたものではない。

PEの原因

初めてPEに気付いたとき、赤道儀のオーバーホールが必要なのだろうと思った。何と言っても30年物だからね。しかし、追尾誤差のプロットが「カックン、カックン」と動いているのを見て思い当たるフシがあった。私の使っているビクセンMD-5モータードライブは、軸もハウジングもリジッドに赤道儀と結合されていたのだ。

回転機屋さんが見たら腰を抜かしそうだが、購入時の取扱説明書に指示されていたか、あるいは取説が無くても付属の部品ではこれ以外の結合方法は考えられなかったかで、当時から私も相当違和感があったが一応動いているので「まぁいいか」で30年経過してしまった。とは言っても、通算してもウォームが何千回転もしていないと思うから、大きなダメージは無いだろう（これは気休め）。

これだと大なり小なり軸の中心がずれた状態なので、回転が渋くなる。偏芯して軸が回転するので、角度によって辛い方向とラクな方向が出てくる。ラクなエリアに入るところで加速して、辛いエリアに入るとき減速していると考えると辻褄が合う。300:1のギアヘッド付きPMステッピングモーターなのでそこそこ駆動トルクがあり、軸の回転数が0.1rpmと超低速なので今まで明るみに出ていなかっただけで、不都合が見逃されていたのだ。

ただし対策を講じて効果を確認する事しか、これが原因と確定する手段は無い。

セオリーはハウジングをリジッドに結合して回転軸はフレキシブルカップリングなどで結合する方法だが、この程度の軽いモーターなら軸をリジッドに結合してハウジングをフローティングにすることも選択できるだろうと考えた。これだとモーターを軸と軸受けで支えることになるが、モーターは軽いし、少なくとも両方ともリジッドに結合していたときよりストレスは少ないだろう、と言う理由。フローティングと言っても完全に自由にしたのでは回転が伝わらないので、回転方向のみ拘束し他の方向には自由に動けるようにする。

モーター側・赤道儀側、両方のステーに幅が6mmよりも少し広い長穴が明いているが、赤道儀側ステーの長穴は何故かテーパーになっていて、赤道儀と反対側では6mmよりも狭くなっている。そのため、赤道儀側ステーの穴にプリント基板をシャーシから浮かして取り付けるときに使う外径6φの金属製スペーサーがちょうど止められ、モーター側のステーに対しては適度なアソビが出る状態になる。写真はナナメから見ているので、アソビが大きく見えるが、実際は回転の接線方向で0.2mm以下だと思われる。

さあ、これでどうだ、と思って試運転すると、意外な伏兵が現れた。モーターの振動で金属同士が軽く触れ合っている箇所がカタカタと耳障りな音をたてるのだ。MD-5は運転中ほとんど音をたてなかった分、余計に耳障りである。対策としてショックコードと言うと聞こえがいいが、要はゴム紐で、回転方向に予圧を与えた。

これで耳障りな音は止む。回転方向以外の抵抗は、ほとんど増えていないはずだ。同じように火星を撮影した。

コマ落とし動画

比較明合成；

機械読み取りのプロット；

この夜の火星の見かけの直径は9.6秒角である。上の図の直径61.4画素が前回の61.2画素より大きくなっているのが気になるが・・・（前回よりシーイングが悪いせい？）；

周期的追尾誤差＝±(9.6×103.7÷61.4÷2)＝±8.1秒角
長期的追尾誤差＝9.6×0.08733×1200÷61.4＝16.4秒角/20分
総合的追尾誤差＝±(9.6×162.5÷61.4÷2)＝±12.7秒角/20分

周期的追尾誤差、すなわちPEが半減したので、対策は効果があったと言える。その一方で長期的追尾誤差が倍近く増加した。今回の対策で増える要素は無いと思うが、元々原因不明なのでなんとも言えない。

短い周期の追尾誤差

対策後の機械読み取りプロットの600秒付近に、10分より短い周期のサイン波のような波形が見える。その振幅は周期的追尾誤差全体の半分を超えているようであり、周期が10分より短い成分が対策後のPEに占める割合がかなり多い様である。この事を確かめるため、対策前後の、長期的追尾誤差を差し引いた後の位置の変動パターンについてフーリエ変換を行ってみた。なおフーリエ周波数ゼロの成分が極端に少ないのは、長期成分を差し引いているためである。またプロットの横軸フーリエ周波数は10分あたりのサイクル数、縦軸は各フーリエ周波数成分のサイン波の片側波高を画像上の画素数で表したものである。

赤の実線が対策前、緑が対策後である。

楽器の音や人間の声に倍音が含まれるのと同様、完全なサイン波ではない周期的波形には高調波が含まれる。対策前の波形はかなり歪んでいるので、多くの高調波が含まれている。その一方対策後では、周波数1の成分が1/3近くまで減っているのに加え、周波数4（周期2分半）の成分が多いのが目に付く。これは周波数1の成分の高調波と考えるには多過ぎる。素朴にMD-5の最終減速比が4:1で、出力軸の4倍の速さで回っている軸についている歯車が偏芯していると考えると辻褄が合う。また周波数10の成分も突出している様なので、次の減速比は2.5:1だろうか。

ギヤトレインの設計には素人なので妥当な推定かどうかわからないが、周波数4の成分がウォーム周り以外で発生していると考えるのは安全な範囲だろう。そう言う目で見ると、対策前の追尾誤差の波形にも周期150秒=2分半のサイン波が現れている、と言うか、コチラの方が明確である。この周波数4のパターンを目印にすると、不適切な軸の結合方法で発生していた追尾誤差成分をうまく分離できそうだ。

なお周波数4の成分は対策後の方が大きくなっているが、対策前では周波数1の成分の高調波とウォーム周り以外で発生した波形の位相が合わず、一部相殺されていたためだと考えられる。

対策により取り除かれた誤差成分の分離

対策前後で追尾状況記録開始時のウォーム回転角を特に合わせるような配慮はしていないので、このまま単純に引き算する訳にはいかない。タイミングを合わせる必要があるが、特に手がかりが無ければ600通りから一つ選ぶ必要がある。しかし、2分半周期の波形が対策前後で同じ位置に出ていると考えると、4通りに選択肢が絞れる。

先ず周期2分半の単位で山の位置を見ると、対策前605秒付近だったのが対策後は565秒付近が最寄りの山である。対策前後で40秒早くなっているが、これは2分半=150秒が単位となっているので、40＋150N（N=0,1,2,3）秒の可能性がある。

対策後の400～600秒の波形に注目すると、対策前の600～800秒とよく似ていることに気付く。これはN=1、すなわち190秒ずれている場合に該当しそうだ。

シーイングの影響を取り除くため、長期的追尾誤差を取り除いた対策後の波形から1分よりも短い周期の成分を取り除き190秒遅らせた波形と、長期的誤差とシーイングの影響を除去した対策前の波形を比較すると、対策により取り除かれた誤差成分が得られる。

一番上から、対策後の生の波形（緑色）とシーイングの影響を取り除いたもの（ピンク色）。生の波形の190秒付近にずらしたことによる継ぎ目が見えるが、赤色の線では取り除かれている。次が対策により取り除かれた成分の波形（黒色）。その下が対策前の生の波形（青色）とそれからシーイングの影響を取り除いたもの（赤色）である。この二つのプロットはほとんど重なっていて見分けにくいので、その差を10倍して一番下に黄色でプロットした。500秒付近と1100秒付近で大きな差が出ているのは、1分よりも短い期間に大きく動いていることが反映されている。

黒色の波形はほぼ矩形波で、想定したシナリオと辻褄が合う。ただし「それらしく見える」だけでN=0, 2, および3の場合の可能性を完全に排除するのは無理だが、特にこれ以上議論する材料も無いので、今回はこれを仮の結論としておく。

ここでシーイングの影響を取り除いた周期的追尾誤差曲線が得られたので、それに基づくと対策前の振れ幅が182.1画素で±15.2秒角、対策後が同90.2画素で±7.1秒角になる。

今回のまとめ

動画の各フレームを機械に読ませることで、比較的正確な数値が得られたと思う。ただし、ここで「正確」と言っているのは画像から数値を得る部分であって、実際に起こっていること全体に関しては見方を変える必要があるだろう。今回特に気になるのが、火星の像の大きさと見かけの大きさの関係だ。恒星ペアの角距離に比べてシーイングなどの影響を受けやすいようである。これを考慮すると、結果には10%程度の誤差があってもおかしくなく、今回一律に小数点1桁まで計算しているのは不適切である。しかしこれは、扱っている桁数があまりに少ないと手を抜いているように見えるかもしれない、と言う見栄もあるので、勘弁して欲しい。

永年見過ごしてきた問題に対策が打てたのは大きな収穫だ。今までも視野の中で星が動いたのに何回か気付いたことがあるが、短時間の内に大きく動いたので「三脚の脚がすべったかな」程度に考え、モーターの取り付けを疑うことは無かった。やはりセオリーを無視してはいけない。

長期的な追尾誤差があるのには困ったが、カメラがデジタルになって銀塩のころに比べるとシャッターを開けている時間が格段に短くなっているので、実用上問題にはならないだろう。今まで星野写真を撮った事が無いが、これならちょっとやってみようか、と言う気になるが、天文道楽が復活してつくづく思うのは「スカッと晴れた夜は稀」と言うこと。天気とシーイングには勝てない。

C920画像センサーの基礎情報

mitaka1954 — 2012-05-18T12:36:22+09:00

Webカメラでも以前はもう少し詳しいセンサー情報が公表されていたように思うが、C920に限らず最近の製品の画像センサーについては画素数しか公表されない場合が多い。これは商品の位置づけがマニア向けではなく一般消費者向けに変わってきたことを反映しているのだろう。

天体写真撮影に使うので、画素ピッチおよび有効受光エリア寸法は把握しておきたい。これに加え、いくつか気付いたことについて書いておく。

2012/4/23訂正：
「ファイル形式は1080pがmovである以外はwmvになる」とあるのは誤り。
「ファイル形式は1080pと720pがmovである以外はwmvになる」が正しい。

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

上弦の月

4月28日、月齢7の月を見ながら日没を待っていたら雲が広がってきたため、空が明るい内に直焦点（500mm）・1080pで撮影し、コンポジット合成など後処理した。後続処理の都合で白黒にしている。

2M画素の画像にしては少し甘い感じがする。焦点が合わせきれていないかシーイングの影響があったかもしれない。Webカメラ画像の長辺が月の直径・約0.5度よりも少し大きいことが一目瞭然だが、もう少し定量的に見てみよう。

ピクセル単位で目盛りを入れて、月の地平線が見分けやすいよう明るさを擬似カラーで表示し、上端と下端を拡大した。

月の直径が1720画素（1830-110）であると読み取れる。

この時の月の見かけの半径が15.2分角なので、500mm直焦点上の画像の直径Dは；

従って、画素ピッチpおよび有効画像エリア寸法：縦H x横Wは；

以上は1080pモードで出力された画像に関するものだ。C920の物理的な画像センサーは3M画素あり、AMCapの様な汎用キャプチャーソフトウエアで調べると有効画素数が2304x1536の3:2フォーマットであることが判る。また高さを切り詰め16:9フォーマットにした2304x1296画素のモードもある。

1080pモードと2304x1296モードで画角は同じに見えるので、信号処理でサンプルを間引いている様である。これを信じて物理的な画像センサーの寸法を計算すると；

3:2フォーマットの寸法をみると、小型ビデオカメラ用として一般的な1/3型センサーであることが確認できた、と言えるようだ。画素の配列が正方形ではなく長方形の場合もあり得るが、特に決め手となる根拠も無いので、正方形と想定している。

画素ピッチ2.14μmはかなり小さいが、天体望遠鏡で使う場合どうなのか考えてみよう。

実質的に点光源である恒星の像の大きさは、望遠鏡に収差が無いと仮定するとエアリーディスクの大きさ2.44λF（直径）になる。私の望遠鏡F=7.7と可視光の中央付近λ=500nmについて計算すると9.4μmで、この中に3x3=9画素がすっぽり納まってしまう。これは直焦点に関する値である。

デジタルカメラでは画像センサーの前に光学的ローパスフィルターが入っていて、点光源の像を2x2=4画素にぼかすようになっている。これはセンサー上の像の最高空間周波数がサンプリング理論のナイキスト周波数を越えてエリアスノイズ（モアレと呼ぶ場合もある）を発生しないようにすること、およびベイヤー配列のカラーセンサーで正常に色分解できるようにすることが目的だ。天体望遠鏡であっても同じことが言えるが、上で計算したように2x2=4画素は1つのエアリーディスクの中に充分納まるのでローパスフィルターは要らない、と言うか、5割ほど画素ピッチに余裕がある（画素数なら2倍）。4画素がエアリーディスクに内接する条件でF5、面積が同じになる条件だとF4.5まで大丈夫である。

以上の計算から直焦点でも充分な分解能であることがわかるが、私の小さな望遠鏡で火星のような見かけの大きさが小さい対象を直焦点で撮影すると画素の角が目立ってしまうため、実際はアイピース拡大法で3倍程度に拡大することになる。

フレームレートなど

汎用キャプチャーソフトウエアを使うと、フレームレートは1920x1080とそれより小さいサイズでは最大30FPSまで設定できるが、

2304x1296および2304x1536は2FPSにしか設定できない。

またLogicool純正のキャプチャーソフトウエアでは1080p、720p、480p、および360pしか選べない。これらはそれぞれ1920x1080、1280x720、864x480、および640x360に対応するものと考えられる。この場合、フレームレートは全て30FPSで、ファイル形式は1080pがmovである以外はwmvになる（ユーザー選択不可）。

なお、どこかにボトルネックがなければ設定したフレームレートでキャプチャーできるが、露出を上げていくと実際に画像が更新される頻度は2回/秒位まで下がるようだ。つまりシャッター速度が遅くなると言うこと。30FPSでも15フレームずつ同じ絵が続いているかのように見える。従って、ゲインを出来るだけ大きくして露出を抑えるようにすると実効フレームレートが上がるので、シーイングが良くない時に有利である。ちなみにC920はゲイン最大に設定してもノイズをほとんど感じないので、最大ゲインをもう少し高く設計してくれた方が天文向けには良かったと思う。

ズームなどについて

純正キャプチャーソフトウエアでズームを行った場合、最も拡大すると2304x1536の画像から所定のサイズを切り出す処理を行っているようだ。これは惑星などの撮影に利用できそうである。と言うのは、私の望遠鏡の角分解能（1.78秒角）を考えると見かけの大きさ1秒角について2画素以上あれば充分であって、むやみと光学的に拡大しても暗くなるだけで無意味だと考えられるからだ。最もズームアウトした状態で目的の天体を中央付近に導入してからズームインすれば、導入がずいぶん容易になる。ソフトウエアでパン・ティルトが行えるのも便利だ。

大きな画像サイズ、例えば1080pで撮影・コンポジットしてから切り出しても同じ結果になるはずだが、記憶容量や処理負荷の点で不利になる。

私の環境によるのかもしれないが、1080p 30FPS無圧縮avi（movからffmpegで変換）ファイルをRegiStax 6でコンポジット処理する場合10秒程度が限界の様で、これ以上長時間のファイルでAlign処理を開始すると「Starting Extended AVI mode」と一応頑張っているようだが「Processing bitmap: 0」とステータス表示した後フリーズしてしまい、タスクマネージャでプロセスを削除しないと終了すら出来ない。360p 30FPSならもっと長時間のファイルでもOKである。また1080pでも予め全フレームを画像ファイルにしてあれば300枚（10秒分）をかなり超えても問題ないので、もしかすると一時ファイルを作るスペースが足りない、と言うオチかもしれない。何であれ、フリーズするのは勘弁して欲しい。

なお、ズームが行えるのは動画キャプチャーだけで静止画では使えない。また汎用キャプチャーソフトウエアを利用している場合はズームの挙動が少し違い、ズーム率によっては物理的解像度を超えてソフトウエア補間で拡大している疑いがあるが、白黒はっきりさせられるだけの手がかりは未だつかめていない。

今回のまとめ

月の直径がWebカメラ画像の長辺にちょうど収まる条件だったため、画像センサーの寸法をかなり正確に測ることができた。同じ3M画素のWebカメラでも1/4型センサーを使っている機種もあるようなので、1/3型と判ったのは一応の収穫だ。Logicoolの現行最上位機種と言うことになる様なので、当然なのかもしれない。

このWebカメラは口径300mm/F5くらいのニュートン式反射望遠鏡などと組み合わせると最高だろう。私の小さな望遠鏡とっては、ズーム機能で導入が楽になるのが最大のメリットになりそうだ。

Logicool C920天体改造

mitaka1954 — 2012-05-15T13:40:11+09:00

Webカメラを天体望遠鏡に付けられるように改造した事例を紹介する。これは、アイデアとしては8mmビデオだったハンディカムに望遠鏡を覗かせてみた頃からの懸案だ。

どのWebカメラを使うか迷った。製品の変遷が激しいので、現行世代で前例のあるものはほとんど無い。ならば前例を作ろうじゃあないか、と言うことで、世間で評判の高いLogicool® HD Pro Webcam C920を選んだ。

使うのが小口径望遠鏡なので、低光量の場合の感度が気になる。

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

改造前の感度チェック

売り物の1080Pで、4月3日にバクダン低気圧が通り過ぎた後、月の上を飛ぶように横切る雲を撮った。

月の真上より少し左側、大体11時の方向に火星が写っている！
こんなに小さなレンズで火星が写るとは、予想外の驚きだ。これは幸先良い、と喜んだのだが、これは少々勘違いだったことが後ほど判明するのであった・・・。

改造内容

最小限の改造で済ます方針で臨んだ。

レンズとクリップの取り外し
31.7φスリーブの取り付け

レンズとクリップを取り外すには、分解する必要がある。C910の分解事例がインターネットにあり、外観から同じ様なものだろうとタカをくくっていたのだが、作りが全く変わっていて焦った。
ガラスのように見える前面の透明なプラスチックのパーツを外せれば、目的の部分に手が届きそうだ。押したり引いたり捻ったりしているうちに、最初に取り外せるのは左右のマイクロフォンのカバー部分以外に無さそうだと見極めを付けた。最悪、マイクロフォンカバーの部品を壊してしまうことを覚悟して、大胆にこじ開けたのが正解だったようだ。

レンズとクリップの取り外し

ステンレス製ものさしを隙間に差し込んでこじ開ける（普通のマイナスドライバーでは力が集中してしまい、プラスチックパーツが壊れると判断）。上側はツメが外れて抜けてくるが下側は噛合していて抜けないので、無理やり引きちぎった（写真右半分に破断面が見える）。

マイクロフォンカバーを外すと、片側4本、両側で8本のネジの頭が見える。内側の4本を外すと、透明なプラスチックのパーツ（実際は黒色のプラスチックと2層構造）が外れ、レンズがむき出しになる。
レンズはオートフォーカス用のボイスコイルモーターにねじ込まれているので、左に回せば外れる。

レンズの左右にある4本のネジを外すとクリップが外れ、下に引き抜ける。
透明なパーツが入っていた部分から見える基板上に、カメラが動作中に光る青色チップLEDが4つ見える。私は放置したが、光を遮りたい場合は小さく切った黒色ビニールテープを貼る、などするのが良いだろう。

これで改造のための部品取り外しは完了だ。取り外したレンズの後端に、感度の波長特性を人間の眼に合わせるためのIR（赤外線）カットフィルターが付いているのが判る。

透明なプラスチックパーツとマイクロフォンのカバーを元に戻して、Webカメラ自体の改造はおしまい。

31.7φスリーブの取り付け

安価なBORGのアイピース延長筒【4611】を加工して、両面テープで貼り付けた。アイピースを差し込む方の太い部分に、Webカメラがちょうど入るような切込みを入れる。金鋸で少し小さめに切込みを入れ、鉄工用やすりで現物合わせする。この時、上下方向の中心が調整しておけるので、後で貼り付けるときの中心合わせが楽になる。下側については、カメラの平坦な部分に合わせて短くカットする。

延長筒とカメラの間に白く見えるのは両面テープのスポンジ状の素材。内側は黒色の油性フェルトペンで塗っておいた（気休め）。
カメラ上下にかぶった延長筒の太い部分は、何かの拍子に引っ掛けて壊してしまうおそれがあるので、黒色のビニールテープで保護しておく。これは延長筒とカメラの接合を補強する意味もある。

これで改造完了。

改造前よりもカメラらしく見えるから不思議。
31.7φスリーブの外側には盛大に指紋がついているが、内側にうっかりつけてしまう心配はほとんど無い。

望遠鏡側の準備

私の古い望遠鏡のアイピースは24.5φのツァイスサイズなので、このままではWebカメラを取り付けられない。またアイピースによる拡大撮影もやりたかったので、ビクセンの42T→31.7AD SXを準備した。

このパーツは比較的安価で容易に入手できる上、カメラのマウントアダプターと同じ場所に取り付けることができるので、実に便利である。Webカメラの代わりにアメリカンサイズのアイピースを差し込めば、目的天体の導入が容易にできる。手持ちにはツァイスサイズしかなかったので、この機会に安価な31.7φアイピースを買い求めた。

見え方は値段相応である。

差込長さを調整して同焦点アイピースにできたら良かったのだが、Webカメラの光路長が中途半端になってしまい、アイピース先端のフィルターネジにねじ込む方式の延長筒が必要だが入手できなかったので、カメラの焦点合わせはコンピュータの画面を見ながら行っている。同焦点アイピースがあったとしても、最終的な焦点合わせは画面を見ながら行だろうから電動フォーカサーが欲しくなるが、口径65mmの小さな望遠鏡には少々不釣り合いだ。

今は目的の天体を視野に導入して焦点合わせを行っているが、明るい恒星でカメラの焦点合わせを行った後、目的の天体を導入した方が正確に焦点を合わせられるのかもしれない。この手順だと、カメラをアイピースに差し替えて導入する際、アイピースをネジで固定せずに抜き差しを手加減してピントを合わせる必要があるが、何とかなるだろう。

ファーストライト

アイピース拡大法の合成焦点距離約1,400mmで撮影した、4月12日の金星である。

本来大気の分散でフランス国旗のように色付いて見えるのだが、ほとんどそれが無い。また少し白く滲んで見え、上下より左右が顕著だ。これはIRカットフィルターが無くなってしまったため、赤外線の影響が強く出ているのだと考えられる。

今回のまとめ

少々乱暴なやり方だったが、無事改造することができた。マイクロフォンカバーの固定が甘くなるが、通常の使用で外れてしまうことは無い。Webカメラの機能を全て温存しているので、必要なら機能的に元の状態に戻すことも可能である。

レンズに付いていたIRカットフィルターが無くなってしまったことで、色合いや画像のキレに悪影響が出ている。当面手持ちのIDAS LPS-P1光害防止フィルターで代用する予定だが、撮影後にどう調整しても色合いに不自然さが残ってしまう。かと言って天体用のIRカットフィルターは、同じWebカメラをもう1台買ってお釣りが来るくらい高価だ。ジャンクのデジタルカメラから調達するのが一番安あがりかもしれない。要検討。

今後使ってみた結果を報告できると思う。自然が相手なので天候など思うに任せない部分が多々あり、時間がかかりそうだ。カメラの性能を評価しているつもりで、結局私のウデが評価される結果になりそうでもある。

晴れ、ときどき天文道楽

mitaka1954 — 2012-05-10T17:38:13+09:00

私の天文道楽の虫は、普段は冬眠していて、ときどき何かの拍子に目を覚ます。今回は金環日食で騒々しくなった世の中に起こされた。目を覚まして日食観測の準備をしているのかと言うと、そうではない。これは、余りありがたくないジンクスのせいでもあるが、結局私はヘソ曲がりだと言うだけのことだ。

永年懸案だった改造Webカメラによる天体写真撮影を試している。これはまた別の機会に書くことにしたい。今回はWebカメラを取り付けている望遠鏡とそれを入手するまでの経緯を書く。

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

天文マニアになりたかった頃

1980年台初めごろだったと思う。天文道楽のドロ沼にどっぷりつかりたい、と思いつめた時期がある。入門用の7x50（倍率7倍x口径50mm）双眼鏡はもう物足りない、と言うか、眼視で最初に見えた時はうれしいが双眼鏡で長時間眺めていてもそんなに楽しいものではないし、そもそも手が疲れる。口径200mm以上の高性能な望遠鏡で天文雑誌に投稿されているような写真が撮りたいと思うようになった。

記憶は必ずしも正確ではないが、私が望んだような本格的な天体望遠鏡、そしてそれを載せて天体を安定に追尾できる赤道儀は当時市販されているものが少なく、あっても相当高価だったと思う。そんな時に「天文ガイド編：本格派のための反射望遠鏡の製作（研磨から赤道儀まで）」と言う書籍に出会った。

オリジナルの天体望遠鏡を作りたい、と思っている人にうってつけの本だと思う。かなり具体的・実用的な内容であるのと同時に、応用が利くような書き方になっているのが良い。今読み返しても、エレクトロニクスの部分を除き、古さはあまり感じない。と言うのは、機構的な部分や反射型光学系では本質的な改革が起こっていないからだろう。敢えて違いを挙げると研磨に人工ダイアモンドが容易に利用できるようになった事がありそうだが、あまり本質的なこととは思えない。同じような書籍がその後あまり出版されていないためか、古本に結構良い値段がついている。もし図書館などで見かけたなら、一度手に取ってご覧になるようお勧めしたい。

この本を何回も読み返していると、自分でも望遠鏡が作れそうだ、と思えるようになって来た。超えなければならないハードルは少なくないが、時間をかければ何とかなるだろう。旋盤などの工作機械が必要だが、望遠鏡ができてしまえばもう要らないのだから、どこかで借りるよう手配する必要がある。買い揃えるには望遠鏡を買うよりも多くの費用が要るだろうし、そもそも置いておく場所も必要だよね。え？

置いておく場所、出来上がった望遠鏡にも要るよねぇ・・・。

当時考えていた「本格派」な望遠鏡は、赤道儀や架台まで含めた重量が100kgを軽く超えてしまうはずだったから、普段はどこかにしまって置いて使うときだけ出してくるのは現実的ではない。望遠鏡を使える状態で置いておく場所、つまり自前の天文台が必要だ。これは誤算。望遠鏡を作るだけなら5年くらいの期間で何とかなるだろうと思っていたが、自前の天文台となると10年20年の話、人生設計そのものに関わってくる。「本格派」天文マニアへの道は険しいと思い知らされたのだった。

「本格派」望遠鏡計画はプロジェクトから夢に路線変更だ。

フローライトならいいんじゃあないかな

天文道楽に人生をかける、と言うと少々大げさだが、道楽に合せて人生設計を決めてしまうほどの覚悟は無かった。そうは言っても、7x50双眼鏡で我慢できるものでもなかった。そんなモヤモヤした心に、高橋製作所のFC-50卓上経緯台の広告はちょっとした衝撃だった。双眼鏡と同じ口径だが、蛍石アポクロマートなら随分良く見えるんじゃあないかと言う気分になる。南向きの窓辺で月などを眺めたら随分とオシャレだよね。

イカイカン経緯台では天体写真は撮れない。これは見送りだね、と思っていたら、Skyキャンサー赤道儀とのファミリーセットが出てきた。口径50mmの望遠鏡に多くは期待できなくても、モータードライブも付けられるからノータッチガイドで星野写真もできそうだ。予算的にも何とかなる範囲だから、もうこれしかないかな、と「本格派」望遠鏡に比べてかなり手軽な方向に流れてしまった。

当時、梅田駅から東にしばらく行った所にあった協栄産業の大阪店（だったと思う）に出向くと、比較的安価なビクセンのモータードライブMD-5も使えるとの事。これなら予算の範囲でひとまわり大きなFC-65に手が届く。

ファミリーセットには眼視用のアイピースなどに加え、写真撮影に必要なアクセサリーが一通り標準で付属していたが、利用するカメラのマウントに合わせるアダプターだけは別売りだったので、ペンタックスKマウント用アダプターと先にも書いたビクセンMD-5を併せて購入。これで直焦点撮影、アイピース拡大撮影、さらに星野写真撮影もできる屈折望遠鏡システムが手に入った。当初の目論見に比べて望遠鏡の性能は数段劣るが、機動性と汎用性に優れ、何と言っても実際に望遠鏡が使えるまでの期間が劇的に短縮されたのだから、充分割に合う。しばらく使うほうの腕を磨いて、作るほうは機が熟すまで待つことにしよう、などと思っていたら30年が過ぎてしまった。

結果として、この望遠鏡が天文道楽の虫封じになったようである。

購入時期の謎

いつ買ったか思い出せないので、これを書くに当たり調査したが、少し謎の残る結果となった。

高橋製作所Webの「企業情報」→「ヒストリー」ページの1982年10月に「・・・FC-65（200台）ファミリーセット期間限定10/1～11/30」とあり、『おお、この望遠鏡は世界に200セットしかない内の1つなのか。大事にしなくちゃ』と喜んだのだが、少し違うようだ。鏡筒の製造番号は1983年製造を示唆しているようだし、さらに同Webの「製品情報」→「歴代カタログ」ページで、「フローライト屈折赤道儀ファミリーセット」は1983年に記載されている。

おそらく「期間限定」の後もファミリーセットの販売は継続されていたのだろう。ファーストライトが南中少し前のM42だった事は良く覚えているので、私が購入したのは1983年の初冬だった可能性が高い。しかし製造番号の上位2桁が製造年と無関係なら1982年11月だった可能性も否定できない。まぁ、どちらであったとしても何かが大きく変わる訳ではない。気持ちがすっきりしない、と言うだけのことである。

蛍石レンズのメンテナンス

購入直後の1年程度は時々使っていたが、その後10年以上休止期間が発生した。これも記憶がはっきりしないが1990年代の半ばくらいだったと思う、大掃除か何かのついでに望遠鏡を見たら、蛍石レンズが曇っているのに気付いた。「あれ、コーティングがはげてしまったのかな」などと思いつつも、仕方が無いので再研磨してもらった。\15,000くらいの費用だったと思う。

最近知ったのだが、私が買った頃のFCシリーズの蛍石レンズは無コーティングだったらしい。そうだとすると蛍石（CaF₂）の表面が空気中の水分（H₂O）や炭酸ガス（CO₂）と反応して、消石灰（Ca(OH)₂）や炭酸カルシウム（CaCO₃）で粉を吹いたようになっても不思議ではない。保管時に生石灰（CaO）系の乾燥剤でも入れておくと発生を遅らせることができたと考えられるが、無コーティングだと長い期間が経てばいずれ再研磨が必要になるのではないだろうか。

再研磨後、以前とほとんど同じ環境で保管しているが、今のところレンズの曇りは発生していない。再研磨の際、コーティングしてくれたはずだと思う。

ありがたくないジンクス

1972年10月8-9日のジャコビニ流星群の時、天文マニアの友人に誘われ暗い空を求めて山に登った。世間では大流星雨を予想する声が多数あったが、それに反してほとんど星が流れなかった。

それ以来、天文イベントに準備万端･意気込んで臨むと、かなりの確率で振られるイヤなジンクスができてしまった。なので、今回の金環食もNDフィルターなど準備すると雨になりそうな気がするので、やっていない。5月21日の朝起きて晴れていたら、コチラを参考に、有り合わせの材料でピンホールカメラでも作ろうと思っている。

Ubuntu 12.04 Desktopのdnsmasq

mitaka1954 — 2012-05-03T11:13:17+09:00

4月27日にUbuntu 12.04がリリースされた。Desktopでも5年間サポートのLTSだ。

諸事情によりLinux desktop機のUbuntuを再インストールする必要があったので、Beta2の頃から色々試していた。初体験のUnity desktopには相当戸惑いつつ「へぇ～、こんなことができるんだぁ」と感心しきり。未だに新発見がある。当分楽しめるだろう。
その一方でdnsmasqには悩んでしまった。ローカルドメイン内がホスト名で参照できなくなってしまったのだ。結局dnsmasqを無効化してしまった。そんなに多くは無いと思うが、同じようなことを経験された方の参考になれば幸いである。

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

現象はネットワーク環境依存

私のネットワーク環境は概ね下の図のとおりだ。説明が容易になるようホスト名やアドレスをアレンジしているが、概念的に重要な部分は合わせたつもりである。
割合しっかりしたDNS機能がBB（ブロードバンド）ルーターに備わっていることが、平均的な「家庭内LAN」との違いだと思う。このDNS機能は正引き・逆引きレコードを手動で設定できて（実はMXレコードなども設定できるのだが、使っていない）、該当するDNS要求に対してはその設定内容を返し、該当しなければISPから提供されているDNSに代理要求をしてその結果を要求元に返すようになっている。

問題は、上の図で「ubuntu02」と表示したコンピュータのUbuntuを12.04にしたところ、「nas03」の管理画面が見られなくなったこと。従来とおりwebブラウザで「http://nas03/」と指定すると「・・・このページは表示できません」と言われる。「nas03」の代わりにIPアドレスを指定（例えば「http://192.168.0.123/」）すれば、見られる。それ以外目立った問題は見当たらない。

どうやらBBルーターの内向きDNS機能だけが使えなくなった模様だ。特にこれと言った原因に思い当たらないので、LinuxのDNS利用関連トラブル対応の定石に従い、/etc/resolv.confの中身を確認してみた;

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search mydomain

Desktop機ではDHCPを利用するのが一般的であり、私の場合もそうなっている。この場合resolv.confは動的に生成されるのが普通だが、それを行っているのが「resolvconf」だったり「nameserver 127.0.0.1（DNSは自分自身）」となっているのは初めて見る内容だ。
こうなるとGoogleするのが手っ取り早い。「ubuntu 12.04 resolvconf」で検索したら、Ubuntu開発サイドの人によると思われる解説が見つかった。
http://gihyo.jp/admin/clip/01/ubuntu-topics/201203/02 （日本語）
http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/ （英語）

要は、DNSプロキシとでも言うべきdnsmasqプロセスが立ち上がり、複数DNSとのやり取りの交通整理をしてくれる、と言うことらしい。どんな「交通整理」をしてくれるのか、もう少し調べてみよう。

「交通整理」の具体的な内容は、2011/10/20付けの Ubuntu Blueprint: Improvement to DNS resolving in Ubuntu （英語）に在った。中盤の「For example in the following scenario:」以降がわかりやすい、と言っても英語なので、要訳を記載しておく。

例えば以下のようなシナリオで:
- ドメインblah.comならびにDNS 1.1.1.1と有線接続
- ドメインexample.comならびにDNS 2001::2と無線接続
- ドメインubuntu.comならびにDNS 2.2.2.2とVPN接続

従来のネットワークマネージャは全てのDNS要求を2.2.2.2に送ってしまい、この接続の遅延が多ければ全てが遅くなってしまう。またblah.comおよびexample.comに関する要求も2.2.2.2に送られるが、このDNSはそれらのドメインについて知っているとは限らない（もし全てがプライベートドメインだったとしたら）。
新しいリゾルバーは、要求のドメインに基づき適切なDNSに振り分けることで遅延を抑えDNSの信頼性の向上を図るものである。

確かに、このシナリオには効果がありそうだ。開発関係者で本当に困った人が居たんじゃあないかと思う。でもこれに該当する場合って、そんなに一般的ではないと思うし、少なくとも今の私の場合は該当しない（将来的に該当する可能性は残る）。

完全に老婆心、余計なおせっかいだが、上記シナリオの3つの接続先の内どれかが私の環境のようにインターネットにつながっている場合を想定すると、インターネット上のホストに関するDNS要求を送る宛先を正しく選べるのだろうか。「最初に確立した接続のDNSを選ぶ」と言うルールが多くの場合正しそうだが、例外的な場合に対処するには任意に設定できる必要がありそうだ。しかしUbuntu 12.04 Desktopのそのような設定項目は調べた範囲では見つけられなかった。

残念ながら、ここまで判っても私の内向きDNSが参照できない理由が見つからない。つまり、これまでの説明とおりなら、「nas03」に関するDNS要求は内向きDNSに送られなければならないはずだ。dnsmasqをもう少し調べる必要がある。

dnsmasqって何だぁ？

「dnsmasq」も初見なので、即Google。これも簡単に見つかった。
http://sourceforge.jp/magazine/08/12/16/0010251

Desktop機上の機能と思って読んでいると、どうも話がかみ合わない。独立した「dnsmasqサーバー機」のようなものを想定しているのだと気付くのに少し時間がかかった。前出の図のBBルーターの、DHCPとDNSの代わりに使うとちょうど良さそうな機能である。

Ubuntu 12.04 Desktopでは、ネットワークマネージャを構築する手段としてdnsmasqの一部機能を「組み込み」しているようだ。独立型dnsmasqで、はdnsmasq-baseパッケージと dnsmasqパッケージがセットで利用されるはずだが、前者だけしか利用していない。そのため独立型では存在しているはずの設定ファイル/etc/dnsmasq.confが無いし、hostsやresolv.confファイルの扱いも全く異なっている。

実は設定ファイルの内容からdnsmasqの挙動がわかるだろうと期待していたのだが、それは見事に打ち砕かれてしまった訳だ。またしても苦しい時のGoogle頼み、インターネットでdnsmasqの設定ファイルのサンプルが見つかった。
http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq.conf.example

多少順序が前後するが、関連する設定を見てみよう。

# Add other name servers here, with domain specs if they are for
# non-public domains.
#server=/localnet/192.168.0.1

この設定を活かす（行頭の#を削除する）と、ローカルドメイン「localnet」に関する正引き要求は192.168.0.1のDNSサーバーに送る。（「Add other name servers...」とあるのは、独立型dnsmasqではディフォルトでresolv.confに設定されたDNSを使い、この設定はそれに追加する形になるから）

# Example of routing PTR queries to nameservers: this will send all
# address->name queries for 192.168.3/24 to nameserver 10.1.2.3
#server=/3.168.192.in-addr.arpa/10.1.2.3

同様、「192.168.3.0/24」に関する逆引き要求は10.1.2.3に送る設定。

Ubuntu 12.04 Desktopでは、ネットワークに接続するたびにDHCPから得た情報に基づいて、これらの設定情報を動的に生成することで機能を実現しているのではないかと思う。またBBルーターの内向きDNS機能が使えなかったのは、以下の設定が常に活きた状態になっているためではないだろうか。

# Never forward plain names (without a dot or domain part)
#domain-needed
# Never forward addresses in the non-routed address spaces.
#bogus-priv

前段は、インターネット上のDNSに投げても「存在しないドメイン」と返されることが明らかな正引き要求は転送せずに答えを返してしまう設定。後段は、プライベートIPアドレス範囲に関する逆引き要求は転送せずに「存在しないドメイン」と応える設定。

今回の私の問題では、ホスト「nas03」は完全修飾して「nas03.mydomain」としても、トップレベルドメインを欠いているのでインターネット上に存在しないことが明らかである。そのため、上記設定が効いた形になっていてブロックされてしまった可能性が考えられる。

問題回避

前出のStéphane Graberの記事に載っていた「dnsmasqをオフする方法（I really don’t want a local resolver, how can I turn it off?）」を実施した。

具体的には、ネットワークマネージャの設定ファイル/etc/NetworkManager/NetworkManager.confの中の1行dns=dnsmasqをコメントアウトするだけである。

sudo gedit /etc/NetworkManager/NetworkManager.conf

この後、ネットワークマネージャを再起動が必要。

sudo restart network-manager

これにより、見慣れた内容のresolv.confが生成される。

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.0.1
nameserver ISPのDNSアドレス1
nameserver ISPのDNSアドレス2
search mydomain

悩み事 – ローカルドメイン名のベストプラクティス？

今回の問題は、ローカルドメイン名を「mydomain.com」や「mydomain.jp」にすれば解決した可能性が高い。またUbuntuのこの部分を開発した人たちは、そうするのが当然だと考えているように思える。しかし私には、これが良い考えだとは思えない。むしろ避けるべき事だと考えている。

ローカルドメイン名を「google.com」にするのが良い考えだと思う人は稀だろう。このローカルドメイン名を敢えて使うなら、Googleの提供するサービスが利用できない場合を覚悟しておく必要がある。さらに何かの拍子、例えばBBルーターの設定変更を間違えたときなどに、webブラウザがnas03の管理画面に自動ログオンしようとして管理者idとパスワードをGoogleに送ってしまうかもしれない。

それでは「mydomain.com」や「mydomain.jp」ならどうだろう。調べてみると、偶然かもしれないが、これら2つとも既に登録済みである。Googleの様に便利なサービスを提供している訳ではないが、「このドメインを利用したい方に格安（？）でお譲りします」と言うことらしい。ほとんどの「ありがちな」ドメイン名はこうなっているのかもしれない。その辺の事情がどうであれ、これらをローカルドメイン名に利用した場合、「google.com」の場合の懸念事項の前半は心配の必要が無さそうだが、後半については依然としてリスクが残るだろう。

インターネット上のドメインとして登録可能な形式のドメイン名をローカル用に使っている限り、予め登録されていないと確認しても、気付かない内に登録されている場合が無いとは言えない。従って、ローカルのつもりで外部の第三者と通信してしまうリスクを防ぐため、インターネット上のドメイン名としては成立し得ない形式として、トップレベルドメインを持たないローカルドメイン名を使うのはかなり有効なはずだ。

もしインターネットに登録され自分が管理しているドメインがあるなら、ファイアーウォールに内外を区別するルールをしっかり設定した上で、それをローカルネットワークにも使うと一番問題が少ないのかもしれない。しかし家庭内LANのために、新規にドメインを登録・維持するのは現実的でない。

まとめ

Ubuntu 12.04 Desktopのディフォルト設定で、私のローカルドメインの内向きDNSが引けない正確な原因は明らかではない。dnsmasqの挙動を制御する手段が無い限り、今のネットワーク環境または運用方法を変えずにそれを利用するのは難しいと思われる。ただし、これは不幸な例外と言うべきだろう。もしかするとちゃんと動作させる設定方法があるのだが、それが私に伝わっていないコミュニケーションの問題である可能性も考えられる。

目指したシナリオでdnsmasqは有効に働きそうである。また大多数の利用者には邪魔にならない（ちょっとイヤミな言い方をすると毒にも薬にもならない）し、私のように副作用が出たとしても簡単に無効化できるのだから、一応の成功だと言うべきなのだろう。

将来、私のUbuntu機から現状のネットワークに加えてVPNを同時に利用する必要が発生した場合を考えると、少々憂鬱である。その頃には設定項目などが整備され、もっと使い易くなっていることを期待したい。

RealTimeIsUniversalの落とし穴にはまった

mitaka1954 — 2012-01-21T15:46:23+09:00

「RealTimeIsUniversal」はWindowsレジストリの設定項目で、Mac OS XやLinuxとデュアルブートで使う際、コンピューターのバッテリーでバックアップされたハードウエア時計（リアルタイム・クロック、Real Time Clock, RTC; 以降RTCと略）の取り扱いを統一するために必要なものだ。この設定値を「1」にすると、RTCの時刻がUTC（Universal Time, Coordinated：協定世界時）であるとしてWindowsの時刻を設定するようになる。その方法・効用などについて、ここで改めて説明するより、「RealTimeIsUniversal」で検索していただいた方が宜しかろうと思う。

現在プライベートで主に使っているコンピューターのOSはWindows Vista SP2である。２年ほど前Linuxとデュアルブートにしていた時期があり、その際上記の設定をしていた。Linuxを専用のハードウエアに移してデュアルブートを止めた後も、特に支障が無いと思いそのまま使い続けたのだが、それが大きな間違いだった。

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

RTCは修正しない「仕様」

結論を先に言ってしまおう。「RealTimeIsUniversal=1」に設定すると、Windows上で時刻を修正しても、一切RTCに反映されない。つまり再起動したり、スリープ（サスペンド）や休止状態から復帰する都度、修正前の遅れ/進みのある時刻に戻ってしまう、と言うこと。NTPサーバー（インターネット時刻サーバー）と時刻を同期させて、その結果をRTCに反映するには、Windows以外のOSとデュアルブートになっていないと不可能である。

この２年間、こんな「仕様」になっているとは思いが及ばなかった。全く「想定外」である。
インターネット上で「RealTimeIsUniversal=1」に設定するとデュアルブートに伴う時刻の問題が解決すると言う趣旨の情報は多数見かけるが、WindowsからはRTCの修正ができなくなると言う点に明確に言及したものを以前見た記憶がない。

「インターネット時刻サーバーと同期する」にしているのに時計が狂う

以前から「コンピューターの時刻が何かおかしい」と感じていた。
１年半くらい前、NTPサーバーと時刻を同期する間隔をディフォルトの１週間から１時間に変更した。でもまだ何か変だ。
今回ようやく以下のような現象が常に起こっている事が確認できたので、気合を入れて調査してみた。

Windows起動直後に時刻が５分遅れている
NTPサーバーと同期を「今すぐ更新」すると時刻が合う
再起動すると時刻が５分遅れている

その結果、前述の「仕様」が判明した。
実は皆知っていて、私だけ知らなかったのかもしれないが・・・。

確かな情報はケンブリッジにあった

できるだけ正統な情報を求めてMicrosoftのサイトを探したが、見つからなかった。「RealTimeIsUniversal」は、Microsoftが「非公式に公認」している「裏技」だから、らしい。
Microsoftが「非公式に公認」と言うニュアンスを含め、最も確かな情報は英国ケンブリッジでコンピューター・サイエンスの教授をやっているMarkus Kuhnのホームページにあった^[1]。そこにたどり着く一歩手前で見つけたMicrosoftの開発者フォーラムのスレッド^[2]で引用され、結果的に追認されているようなので、正統な情報と見て間違い無いだろう。Markus Kuhnのホームページの関連部分を要約すると、

Windows Vista SP2およびWindows 7で、「RealTimeIsUniversal=1」に伴う問題が解決した
それ以前のWindows（XPやVista SP1）では、サスペンドや休止状態から復帰した際、UTC時刻になってしまう問題がある
「RealTimeIsUniversal=1」を設定すると、Windows Vista SP2およびWindows 7であっても、RTCを更新しない
RTC更新するには、デュアルブートになっているWindows以外のOSでインターネット時刻サーバーと同期する必要がある

Markus Kuhnが「...this improved support for UTC in the CMOS clock may not immediately be widely documented...」と書いている通り、これら情報全部がまとめて記述されているのは、私が検索結果から辿った限りでは他に見つからなかった。改めて読み返すと、そういう趣旨の内容だったのかと判るものもあったが、予備知識無しにそれを読み取るのは難しいと思う。

結局・・・

「RealTimeIsUniversal=1」はデュアルブート環境限定、と言うことらしい。「RealTimeIsUniversal=0」に設定を直して、今は順調である。
オマケとして、問題のコンピュータのRTCの長期的な偏差が約２年間で５分遅れ、つまり約-5ppmだと判った。RTC用に使われる32.768kHzの水晶振動子は許容偏差が±20ppmになっている場合が多いので、まぁそんなものだろう。

「リアルタイム放射線情報」開設

mitaka1954 — 2011-03-19T21:47:58+09:00

「こんな時、私にできることは何だろう」と考えた。
その最初の結論である。

三鷹市上連雀のリアルタイム放射線情報

ありあわせの材料で手作りしたものである。
一定時間の平均を取ること以外は全く加工していない、生の情報だ。
幸い、当方では今のところ平常値を維持している。

Webサーバーの動作ができるだけ軽くなるように作ったので、少々アクセスが集中しても大丈夫だと思う。

他にも個人で測定値を公開している方がいらっしゃるようなので、参考にして欲しい。

「直ちに健康への影響は無い」という言葉は聞き飽きた。定量的な数値が示されないのは、疑念を生むマイナスの効果しかないと思う。
しかし、生の情報を正しく理解するのには、ある程度のスキルが必要となるのも事実だ。

驚くことに、関西でも買いだめが横行しているらしい。女房の実家（兵庫県）の母からの情報だ。
「政府・行政は深刻な情報を隠しているのではないか」といった漠然とした不安が、人々を買いだめに走らせているのだと思う。

福島第一原発：放射性物質拡散予測

mitaka1954 — 2011-03-17T21:56:23+09:00

私たちは運が良かったようだ。

2011/3/27追記：
この種の拡散シミュレーションは、どうやらコチラが大元らしい。

N.Y. TimesのWebで、"Forecast for Plume's Path Is a Function of Wind and Weather"というのを見つけた。

今回の事故は、未だ予断を許さないが、これを見る限り我々には多少のツキが残っていたようだ。もし仮に事故が日本海側、たとえば敦賀あたりで起こっていたらと思うと、ゾッとするものがある。

N.Y. Timesのコンテンツを注意深く見ると、3/15～16の間の一時期、南関東まで放射性物質の通り道になっていたようだが、今のところ実害は生じていない。放射線物質濃度が低かったからだろう。これもまた、運が良かったと言えるかもしれない。

運が尽きないうちにFukushima50がなんとかしてくれると、信じて待っていよう。

Fukushima 50 Heroes

mitaka1954 — 2011-03-17T20:13:16+09:00

「フクシマ・フィフティ」
彼らを応援したい。

しかし、顔も名前もわからない相手を応援するのは容易ではない。
彼らがどんな人たちなのか、ぜひ知りたいものだ。