大阪の計算上の金環日食は7:28:30から7:31:08の2分半。日の出直後くらいは晴れてて完全に太陽が見えてたんだけど、7時前にはかなり雲が増えてて、既に雲越しにしか見えない状態。時々太陽が見えたり見えなかったりを繰り返してたけど、金環日食開始の5分前からは完全に見えないまま、金環日食終了時間まで過ぎてしまった。残念！幸いにも、終了の30秒ほど後には雲の切れ目から太陽が一瞬だけ見えた。このとき撮影できた写真を見てみると、下のほうの60°くらいがつながってない様子。雲で見えてないのか本来の欠けが60°なのかは不明。
雲は空の広範囲をおおってる程でもなかったので、終了直前までは諦めきれなかったけど、結局見られず残念。日食の影を撮影することも考えてたけど、長時間影が映らない状態だったので、金環どころか部分日食でもできず。
以前、日食用に購入したND8フィルタ、結局最終的には4枚持ってるんだけど、今回も出番なし。
嵐山まで往復。98.3km。久しぶりに100kmぐらい走ったけど、冬に50kmくらいでヘタッてた状況からは改善。今日はまだかなり余力はあった。
前回の立ちゴケ後、対策として、ペダルをクリート専用のPD-A520から片面クリート+片面フラットのPD-M324に換装。町なかを走るときは普通のスニーカーにしようかな、と。ペダルにマルチリリースのクリートが付属してきたので、ついでに交換して、今日はそれを使ってみた。これはいい。これまで使ってたシングルリリースだと外側にひねらないと外れなかったけど、マルチリリースだと内側にひねっても外れる。この差は大きくて、立ちゴケしそうになった時でも内側にひねるのは自然にできそうな気がするので、立ちゴケ回避には良さそう。これならペダルを換えなくても、クリートを換えるだけでよかったかも。今回のペダルは横幅が大きいから、今日も早速、車体を傾けた時にちょっとこすったし。
先週作ったAviUtlのプラグイン、当初からBSDスタイルのライセンスのどれかで公開しようとは思ってたけど、結局、MITライセンスにすることにした。昔から何度も関連情報は読んでるんだけど、やっぱりライセンスの話は難しい。そんな中でも、オープンソースなライセンスや...のページが分かりやすくまとまってる感じ。
基本的には先週ので終わってるので、後は微調整とソース公開準備。気になってたのは、JOSMのリモート制御処理を入れると数倍重くなってしまう点。調査したところ、1フレームごとのプラグインの処理のうち、6割ほどがWinInetのInternetOpen()の時間に取られてた。これは毎回するべき処理でもないので、最初の1回だけ行うようにしたことでかなり軽くなった。他にも3割ぐらいがJOSMとのHTTP通信に使われてるんだけど、個人的には十分実用的な速度になったと思うので、まぁこれはこのままでいいかな。JOSMリモート制御部を別スレッドにしてプラグインのメインスレッドから非同期処理として分離してしまえばメインスレッド側の返りを速くできるんだけど、面倒なので放置。
結局、時間が足らなくて調べられなかったんだけど、AviUtlの動作について。プラグイン側で勝手に確保した領域にGPSデータのリストを作ってるので、AviUtlのバッチ出力機能ではうまく動かないだろうな、と思ってたんだけど、試してみたら普通に動いてしまった。一体、どういうメモリ管理になってるんだろう。
とりあえず最低限の機能は一通り入れたので、公開までたどり着けた。今日の朝の段階では今日中に公開できるとは思ってなかったので良かった。
まずはGPXファイルを読み込む処理に着手。しかし、まさかのファイルが開けない問題にぶつかり数時間はまる。結果的には、VC++2005/2008でfstreamの日本語ファイル名が化ける問題を踏んでいた。VC++2010では直っているらしい。
で、GPXファイルの解析、XMLだから自由度が高くて、標準C++だけで仕様通りのファイルを全部自力でサポートしようとすると難しすぎる。そもそも、自分が持ってるGPXファイルだけでもバリエーションがあって無理そう。最初はネイティブDLL部分から何とか.NET側のXML解析機能を使えないかと頑張ってたんだけど、結局やり方が分からず断念。
.NETとは関係なくライブラリを使おうと思って次に調べたのがXerces-C++。コードは書けそうだけど、使い方が難しそうなので他を探す。たどり着いたのがTinyXML-2。1つのcppファイルと1つのヘッダファイルだけで構成されてるので、配布する立場としても配布物が増えるわけでもなくて嬉しい。しかも、ちょっとした使い方なら簡単に使えるようで、変数定義を除いたら20行ぐらいでGPXからのトラックデータ抽出までできてしまった。
AviUtlとプラグインの作者各氏には感謝してるけど、AviUtlのプラグイン開発キットで困ったのが、関数一覧のパラメータが入力なのか出力なのか分からないこと。サンプルもない関数はほんとにどう使ったらいいのか分かんない。まだGPS座標表示プラグインは100%完成しているわけではなくて、細かい動きで不便なところが残ってて改良はしたいので、自分に必要なところだけでももっと調べる必要がありそうだ。
昨日の続き。早速プラグイン開発に着手。まずは開発環境の整備。昨日の調査中にダウンロード済みだったVisualStudio2008に入ってたVC++2008を使うことにする。ダウンロード時点でVisualStudio2010ではなくてVisualStudio2008にしたのは、一応Windowsネイティブアプリで作るんだけど、もしかしたらLinuxとかでもMonoで動いてくれないかな、と思ってたので一昔前のもののほうがいいと思ったのと、仕事でちょっと使ってたのがVC#2008だったので。Aviutlのプラグインに方向転換した段階で関係なくなったんだけど、ま、大したことするわけじゃないし情報の蓄積もありそうだからこれでいいかな、と。
始めるにあたって参考にしたページ。(1)AviUtlプラグイン作成 (2)AviUtl オリジナルプラグイン公開サイト @ wiki ビルド > とりあえず。これとは別に調べて見てたんだけど、VC#ではWindowsネイティブなDLLが作れないようだ。AviutlのプラグインはWindowsネイティブなDLLである必要があるので、少なくともAviutlとの界面はC++とかで書く必要がありそう。ここからさらにVC#で作ったDLLを呼んでもいいんだけど、わざわざVC++とVC#を両方使うのも面倒そうなので、とりあえずVC++だけで進めてみることにする。
.NetになってからのVC++を使うのは初めてなんだけど、やっぱVC#と比べると親切さが落ちるなぁ。すぐに気づくのが、コンパイルするまでエラーが分からない点。VC#は入力したそばからエラー指摘されるので強力すぎ。
OSMの地図調査作業で、カメラで映像を撮影しておいて、後でGPSロガーの情報とあわせてマッピングをするのは、効率のいいマッピングの方法の一つ。ただ、これをやるためのいいソフト環境がない。今のところありそうなのはJOSMにvideomappingプラグインを組み合わせて使う方法くらいなんだけど、このプラグイン、不安定すぎてよく落ちるので使いものにならない。それだけではなくて、Javaで作られててマルチプラットフォームなのはいいけど、Windowsネイティブと比べるとコーデックの対応がかなり少ないらしい。最初はデバッグを手伝って品質上げたいなぁ、と思ってたんだけど、萎えてきた。
ということで、JOSMプラグインは諦めて次の手へ。Windowsネイティブアプリの自己開発。最近だとVC#かな。で調べたんだけど、これも映像データの取扱いがかなり大変らしい。
映像自体はあまり取り扱いたくないんだよ、と思いながらたどり着いたのが、AviUtlのプラグイン開発という選択肢。映像データ自体はAviutlとか他のプラグインが何とかしてくれるので、自分が作りたい部分に重点を置いて開発できそう。既存のものでGPSを取り扱うプラグインにVSD for GPSがあるんだけど、ちょっと必要なものとは方向性が違うので、自分で一から作ったほうがよさそう。でも、AviUtlのプラグインって簡単に作れるんだろうか・・
西宮まで。最近自動車事故のニュースが多いので、巻き込まれないようにいつも以上に注意して走行。が、歩道に入って信号待ち中にまさかのビンディング外れてなくて単独転倒事故発生。今回は服装が夏仕様だったこともあって、ひざを軽くすりむいた。これも前回こけてから注意してたはずなのに。やっぱ、俺にはビンディングは無理ってことだな。そもそも、シューズは自転車を降りて町を歩くのに支障がなさそうなのを選んだはずなのに、やっぱり不便すぎる。サイクリング日でも自転車を降りている時間の割合が高めなことが多い俺にとっては向いてないと今更ながら再認識。