OS X用GigE Visionカメラドライバ - その38

もうずいぶん前のことですっかり忘れてるんだけど、やっぱりちゃんとやりたいので継続する。ギガビットイーサネットをデータの転送路として利用した無圧縮カメラの機能を制御するには、GEN<i>CAMという規格があって、カメラのメモリ内にXMLファイルとして格納されているカメラ記述ファイルを読みだして解析する必要がある。GEN<i>CAMはGenApiとGenTLという副次的な標準規格を持っていて、GenApiはカメラ記述ファイルを解析して、GenTLは実際にそれを制御データとしてカメラとやりとりする。それぞれ標準実装としてGEN<i>CAMが公開しているけど、Windows用のライブラリとドキュメントが主で、Linux用がおざなりに、OS X用は残骸程度のものが公開されているにすぎない（GenApi3.0として今年初めに最新版が公開されて、そのOS X用標準実装はかなり真面目になっている。でも力の入り方はWindowsとは比べものにならないし、詳しく見れば見るほど周回遅れ感がひしひしと伝わってくる）。

GenApi3.0は別途研究するとして、僕は（ずいぶん前だけど）GenApi+GenTL互換のOS X用GigEカメラドライバをフレームワークの形にまとめようとしていた。その前回はXML形式のカメラ記述ファイルの定義をしているスキーマを読んで、どういうふうにObjective-Cのオブジェクトに変換するかを考えていた。非常に複雑だ、ということはわかったけど、今日からそれを思い出して、続きを進めることにする．．．．

GenApiではカメラの一つの機能をXMLファイル上のトップレベルの一つ下のエレメントとして記述することになっている。それをそのままノードと呼んでいる。ノードはさらに子要素（トップから見ると孫要素）を持っていて、それでノードがどういうふうに動作するかを記述してある。

ノードは少なくとも形式的には単一継承のルールに従っているので、そのままObjective-Cのオブジェクトとするのは不可能ではないように見える。とりあえずそうすることにして、エレメント（トップの孫要素）をどう扱うか。

スキーマファイルを見る限り、ノードのエレメントはすべてがフラットに並んでいて内部構造を持たない。ところが前回見たようにエレメントは動作の意味の上（セマンティクス上）は複雑に絡まりあっていることがわかった。

実装を簡単にするために、エレメントをノードの持つプロパティとして実装したい。そうすると例えば単なる定数を保持しているだけのエレメントもひとつのオブジェクトとして実装するほうが一貫性があってわかりやすいし、そう考えるとエレメント側にもうすこし機能をもたせたほうがノードの実装がすっきりする。

たとえばスキーマファイル上ではカメラのレジスタのバイト幅を表すエレメントとしてLengthとpLengthがある。これは、Lengthは決まった定数で、pLengthは別のノードを参照してその値を得る、ということになっていて、ノードの内部ではどちらか一つが必ず存在していなければいけない。スキーマファイルをそのまま読めば、ノードはバイト幅を知るためにどちらのエレメントが存在しているかを調べて、存在している方に問い合わせる、という作業を実行時にすることになる。

LengthとpLengthをそれぞれふたつのプロパティとせずにひとつにまとめて、XMLを読み込んでノードをインスタンス化するときに定数か参照かどちらかのオブジェクトを作ってプロパティにしておけばいい。そうするとノードオブジェクトはバイト幅を知るときはそのプロパティを評価すればいいだけになって、実行時にどちらがあるか判断する必要は無くなる。

アドレスに対しても同じようにAddressとpAddressとpIndexとIntSwissKnifeをひとつのプロパティにすればLengthと同じ扱いができる。でもこの場合、IntSwissKnifeはノード型でもあるのでノードも同等に扱えるようにしないといけない。

そう考えると、ノードとエレメントは同じ基底クラスから導出できるようにするか、共通の評価プロトコルに準拠するようにして、統一して扱えるようにしたほうがいいように思える。XMLファイルを読み込んでインスタンス化するときに、XMLのエレメントのタグから生成するオブジェクトを切り替えるようにする。そうするとノードが入れ子になっているような場合でも再帰呼び出しするだけですむ。

しかし、GEN<i>CAMのXMLでは1番目のレベル（子要素）と2番目（孫要素）とでは意味が違っている。1番目のレベルはカメラの持つ機能としてアトリビュートで名前が必ず与えられるけど、2番目には名前はなく、XMLのタグで区別されるだけである。同じ扱いができないので非常にめんどくさい。さらにはその下のレベルにアトリビュートで名前がつくエレメントも存在する。それは例えばGroupノードがそうであるが、StructRegの中にあるStructEntryもそうである。StructEntryはStructRegのエレメントの一部であるにもかかわらず、名前を持っていて、それはすなわち他のノードからの参照がある、ということである。

このStructRegはStructEntryの定義を引き継いで、最終的にはGenApiにおけるビットフィールドの表現であるMaskedIntRegに分解されることを期待してるらしい。その証拠にStructEntryの親ノードであるStructRegノードには名前のアトリビュートがなく、Groupノード同じCommentアトリビュートになっている。

ちょっと考えれば、これはカメラのユーザにとってなんの利益もない（ユーザはXMLを読むことはなく、必要な機能にアクセスする方法がビットフィールドだと言われればそうするだけ）。ただXMLファイルの作成が簡単になって、ファイルサイズをほんのちょっとだけ圧縮するだけである。僕には規格がどこを向いて作られているのか、ということに疑問を感じてしまう。

ここでまた文句を言ってても進まないので前回エレメントを整理したようにノードの定義も自前で整理して、どうオブジェクト設計すればいいか考えることにする。

今日は前置きだけで終わってしまったな。次回からがんばろう。