太陽黒点の観測のしかた デジタル編(1)

●第四の観測方法:デジタル撮影法

 太陽観測の方法は、大きく分けて
(1)投影法…太陽投影板に太陽を投影し、観測用紙に黒点を写しとる方法
(2)直視法…減光フィルタで減光して、直接眼視で観測する方法
(3)撮影法…カメラで撮影する方法
 の3種類あります。また同じ事を書いて申し訳ないのですが。

 で、投影法は、現実問題として、手間がかかりすぎます。
 直視法は、記録の正確性に欠けることと、安全性に問題が残ります。

 記録の正確性で言えば撮影法が有利なのですが、フィルムを使っている限り、ランニングコストがかかりすぎることと、東西方向の検出に課題が残ります。(一般には望遠鏡を固定し、時間差で像が重なるように二重露光します。当たり前ですが、フィルム上の話なので後処理で2つの像を分離することはできません。)

フィルムの撮影法での東西決定法。二重露光して重なり合った円の接点を頼りに東西南北を決める。

 ところで、現在、銀塩フィルムカメラが絶滅の一途をたどり、代わってデジタルカメラが主流となっています。

 デジタルカメラによる撮影法はどうでしょう?

 少なくともフィルム代が不要です。現像の手間も要りません。デジタル画像処理が可能です…。

 冷静に考えてみると、従来のフィルムによる撮影法とは全く次元の違う観測が可能だということがわかります。
 これは第四の観測方法と呼んでもいいかもしれません。


2006/09/27
●デジタル撮影法の利点

 デジタルカメラによる撮影法は、フィルムによる撮影法とは比較にならないほどのメリットをもたらします。整理してみましょう。

・近年の画素数の向上で、精細度はフィルムを上回ります。

・フィルムを使わず、現像する必要もないので、ランニングコストはほとんどかかりません。また、現像するための手間も時間も必要ありません。

・二重露光しなくても、別カットの2枚の画像を比較することで東西方向の決定が正確にできます。(ネガフィルムの場合、背景が黒いためにコマの境界がわからず、別カットとの位置比較ができません。このため、二重露光する必要があります。デジタルカメラは素子が固定されているので、画像比較ができます。)

・JPEGデータには撮影日時が埋め込まれているので、観測日時の記録し忘れをすることがありません。

・撮影後、JPEGデータになるので、これを編集するということは、コンピュータを使わざるを得ません。であれば、P,B0,L0の取得も自動計算が可能です。

・画像がデジタルデータなので、別途スキャンしておいた太陽面経緯度図を正確に合成することが可能です。

・いや、そんなことをするぐらいなら、直接経緯度図を描画して画像に合成してしまえば、太陽面経緯度図を購入する必要すらありません。

・紙の太陽面経緯度図のB0が1度ステップだったのに対して、計算された経緯度図は、誤差0.1度未満の超高精度経緯度図となります。飛躍的な位置読み取り精度の向上が実現可能です。

・太陽面経緯度図を計算で描画するなら、L0で補正してしまって、経度を直読みできる経緯度図を合成できます。

・太陽の画像に経緯度図を合成すると、リム近辺の位置の読み取りが難しいという欠点はありますが、展開図を作れば位置の読み取りは非常に楽になります。


2006/09/27
●デジタル撮影法の唯一の欠点

 デジタル撮影法の唯一の欠点は、支援ツールが全くないということです。


2008/06/08
●フロントエンドをデジタル化する意味

 フロントエンド:最前列のこと。データ発生源に一番近い場所。

 投影法の場合、相対数が出た後の集計表を作る作業の手間も馬鹿にならないので、後処理(月別の一覧表から、蝶形図を生成するといった部分)を自動化するためのツールは過去いくつか作られていたようです。

 しかし、スケッチから黒点の位置を読み取れる状態にするまでの工程がどうしてもデジタル化できずにいました。

 コンピュータの処理能力(特に画像を記録しておけるだけの記憶容量)が不十分だったことと、観測に耐えられるだけの充分な解像度(200〜300万画素か、それ以上)で太陽を撮影できるカメラが存在しなかったためです。

 そのため、直接的な撮影はあきらめて、スケッチ用紙をデジタイザやスキャナで読み取って処理をするといった事をしなければなりません。これでは効率化したのか手間が増えたのかよくわかりません。

 その点、デジタル撮影法では、太陽をデジタルカメラで撮影するため、スケッチ用紙のデータ取り込み作業も不要という利点があります。


2006/09/27
●この際、バックエンドもデータベース化

 バックエンド:後端のこと。データを加工し、整理された情報として取り出す部分。

 学校で行われている黒点観測のデータは、多くは表計算ソフトのファイルにまとめられているかと思います。
 表計算ソフトは操作が簡単な反面、データの蓄積には向いていません。

 たとえば、蝶形図や相対数の推移グラフを起こすためには過去のデータを一挙に読み取らなければなりません。このとき、日別や月別にファイルを分けていると、データを通しで読まなければならず、大変手間取る作業になります。

Excelでの集計表作成イメージ。相対数やその平均などが自動計算されて便利ではあるが、効率的なまとめかたとは言えない。


 集計の効率を考えるとファイルが1つにまとまっていた方が便利なのですが、1つのファイルに可能な限りの長期間のデータを押し込めると、今度はファイルが巨大化し、読み書きに時間がかかったり、破損する危険性が高まってしまいます。

 ファイルを細かく分ければ、破損の危険が低減しますが、長期的集計はあきらめざるを得ません。

 ファイルを小分けするもう一つの問題点は、ファイルフォーマットが変わってしまう事です。
 96年頃のデータはExcel95形式、98年頃はExcel97形式、2001年頃はExcel2000形式で保存…なんていう具合にファイル構造が年を追って変化してしまいます。将来に渡って、過去のフォーマットを読めるかどうかは保証がありません。

 もっと前に戻ると、93年頃はデータが3.5インチフロッピーが主流。90年頃のものは5インチフロッピーで、85年頃は5インチフロッピーでも2DD(640MB)で、8インチフロッピーやカセットテープも珍しくない時代でした。

 少なくとも、今は既に5インチフロッピー以前のメディアは読む手段がありません。仮に8インチフロッピーにデータがあるとわかっていても、もはや過去のデータを取り出す事ができません。

 そういった事がないよう、ソフトが新しくなる度に、過去すべてのデータを現在の形式にコンバートしなければなりません。

 そしてまたどんな単位で1つのファイルにするかが悩みどころですが、それは本来悩む部分ではありません。(つまり、この時点で、Excelでは手に負えないスケールのデータであると認識すべきです。)

 多量の日々のデータを蓄積し、データを過去に遡って通して読むには、データベースにした方がはるかに効率的です。新しい形式へのコンバート作業も1回で済みます。

 太陽観測データはデータベース化するほど複雑な構造のデータではありません。かと言って、表計算ソフトでは手に負えないスケールのデータであることもまた事実です。


2007/02/13
●データベースにMicrosoftAccessを使う

 そこで、データベース化です。
 難しい、高度なシステムは要りませんので、MicrosoftAccessを使います。

 MicrosoftAccessは、ワンパッケージで開発言語までくっついてくるので、データベースの基礎を学ぶにも適している面があります。(少なくともデータベースに接続できない、接続できても更新できないといった、根本的な苦労はしなくて済みますので。)

 最近では MSDE 改め SQLServer 2005 Standard Editionは、無料提供されている上に管理ツールも含まれているし、開発言語もVisual Studio 2005 Standard Editionも無料提供されてきているので、だいぶ環境は良くなってきましたが、まだまだ決定打に欠ける面は否めません。

 さて、デジタルカメラで撮影し、データベースによるデータ集計まで一貫したデジタル化のシステムを構築する基礎部分は整いました。


2006/09/27
●駄目押し:資料のHTML化

 Webを探すとわかりますが、太陽黒点観測の結果を掲載しているページは、数えるほどしかありません。(下手をすれば片手で間に合います。太陽活動の活発化に伴って増えていくのを期待したいですが…。)

 別に観測結果はWeb公開してマズいモノではないし、自分の観測結果である以上、著作権は自分にあるのですから、煮るも焼くも自由です。

 では、太陽黒点観測をしている人が少ないのかと言えば、それは考えにくいでしょう。というのも、中・高・大学の天文部(科学部天文班)の定番テーマですし、一般の天文同好会でも、ある程度の規模があれば太陽黒点観測をしている人が一人や二人はいるものです。
 情報ソースの数は、下手をすれば日本国内だけでも4桁台になるでしょう。

 では、なぜ掲載ページが少ないのでしょうか?

 おそらく、報告用資料を作るのが精一杯で、Web公開用のデータを起こす所まで手が回らないというのが実状でしょう。

 投影法による観測は、想像以上に手間がかかります。それに加えてWeb公開用のデータを起こすとなると、並大抵の作業量ではありません。
 せっかくまとめた資料をさらにHTML化するのは、私だって嫌です。

 そこで、発想をひっくり返します。

 Web公開用のデータを作る方を優先するのです。
 当座の資料はWebブラウザで開いて印刷すればいい訳ですから、HTMLになっていればWeb公開もできて一石二鳥です。

 Webページのハードコピーではダメだ、という場合は、それ用の資料に仕立てたものを作ればいいだけです。

 くわしくはデータベースの考え方の方で述べるつもりですが、『元データさえきちんと整理されていれば、あとはデータ加工のやり方次第でどうにでも資料が作れる』というのがデータベースの考え方、使い方です。

 「せっかくまとめた資料をさらにHTML化する」という余分な手間暇をかけるのは無駄です。データベースにデータを押し込んでおいて、そこから紙資料を作ったり、HTMLデータを生成したり、はたまたExcelのセルに基礎数値を流し込んでしまった方が手間がかかりません。

 HTML化資料は、そういった資料作成の自動化の象徴という訳です。


2006/12/22

[戻る]