SSブログ

仕事で使うGigEカメラ [日常のあれやこれや]

今僕がいる会社は半導体レーザ応用デバイスが本命で、そのデバイスの組み立てや評価には光の強度分布を見ないといけないことが多い。しかしS/Nやダイナミックレンジがたくさん必要というわけではなくて、たいていの場合最終的な測定結果として有効数字二桁あれば十分である。ということで半導体イメージャを使ったカメラをたくさん使うことになってきた。

でもそのためには安く手に入るWebカメラみたいなのは残念ながら使えない。というのは入射する光量に対してある程度のリニアリティが必要なのに、普通の写真やムービーを撮るためのカメラではガンマ補正がかかっていて、オートゲインやオートシャッタが普通はオンになっていて、転送レートを抑えるためにカメラ側がMPEGあるいはJPEG圧縮した結果だけをホストに送るようになっている。元の光の量がどれくらいだったのか画像データからはほとんどわからなくなる....

ということで、そういう計測用のカメラが存在する。ガンマ値は正確に1.0、勝手にはゲインやシャッタスピードは変わらないし、データ転送は無圧縮でやる。昔のビジコン管ならいざしらず、半導体になってからはリニアリティは原理的に良くなってるので、ようするにイメージャからのデータを何もせずに渡してもらえればいい。何もしなければ値段は安くなるか、というとそうではなくてなぜかむしろ高くなる。それは、画像の見た目という面ではかえって悪くなって必要とする人が減るのと、最大のフレームレートが総画素数に正確に反比例するので、太いインターフェイスが必要になってしまうからである。まあしょうがない。

ということで、こないだからギガビットイーサネットを使ってデータをホストに転送するGigE Visionカメラをいろいろなところで使っている。去年の夏に工場の自動調整装置に2台のカメラを使ったあと、小さな会社なのに今では合計6台使っていて今年中にあと2台、来年にはそれと同じくらいの台数が追加で必要になる。

今の会社に入って最初にカメラを買うことになったとき、数社から見積をもらってそのとき同じイメージャを使った機種で一番安かったドイツのメーカのにした。そのあともそのメーカから買い続けてたけど、最近になって会社の社長副社長の知り合いが営業をしているカナダのメーカが、知り合いのよしみでちょっと値段を安くしてくれることになって、そっちに乗り換えよう、ということになった。

そもそもシーケンサで無圧縮カメラのデータを簡単に受けられるようなのはないらしくて、付き合いのある設備屋さんはみんなお手上げで、そういうカメラはホストに直接接続するのが普通らしい。ホストは僕が書くことになっていて、僕にはOS Xしか使えない。カメラメーカのドライバはWindows用ではバージョンごと32ビット64ビットごとにいっぱいダウンロードサイトに並んでいてどれにすればいいのかわからないくらいだけど、「OS X」は一言もない(LinuxはAravisのおかげでどこもちょっとだけ言及があるけど)。しかたないのでひとりでGigE Visionと仕様書を読んでドライバをしこしこと書いてなんとか動くようにした。

何がめんどくさいと言ってカメラの機能を知って使えるようにするためにはGen<i>Camという規格に従ったXML形式の記述ファイルをカメラから読み込んで解析しないといけない。ずっとまえにも書いたけど、僕から見るとGen<i>Camの規格はダサくて書きづらい。結局今はカメラを記述したXMLファイルをカメラから読み込んだら、いったんそれをファイルに落としてそれを僕が自分で読んで、使いたい機能をハードコードしてきた。

カメラごとにデータ転送開始のコマンドさえ違っている上にフォーマット(縦横の画素数)やデータ幅もいろいろになってきた。これまで使ってきたドイツのメーカのカメラはそれほどいろいろな機能があるわけではないのにXMLファイルは20kBぐらいある。さらにこんどのカナダのメーカのはXMLファイルが300kBを超える。人間が読めるサイズではなくなってきて、カメラごとにハードコードするのには限界が見えてきた。

めんどくさいけどGen<i>Camをプログラマティックに処理するしかない。Gen<i>Camの規格に従ったXMLファイルの解析は出来上がってる(ダサいせいでコード量は多いけど、それほど難しくない)んだけど、Gen<i>CamでいうTransport層、つまり実際にカメラとデータをやり取りする部分の実装が悩ましくて進んでいない。Gen<i>Camは高信頼性のTransport層を前提にしているようで、通信に失敗することを考慮した規格になっていないことが原因。GenTLというTransport層の標準実装があるんだけど、それとコンパチな実装ができそうな気がしないせいで手が進まない。

それ以前に、今動かしているコードもあまり美しくないのが気になっている。GigEカメラからの画像データがUDPで来るんだけど、今の実装ではそれを受け取るための専用スレッドを起こしている。とりあえずフレームが埋まるとすぐメインスレッドにフレームを渡すように書いたんだけど、ちょっと早すぎる。例えば一画素12ビットデータの時に2画素を3バイトに詰め込んで渡すモードがあるが、その場合バイト境界に揃えるところまで受け取りスレッドでやるべきだろう。また、Bayer配列のカラーデータは、RGBに変換してからメインスレッドに渡したほうがいいかもしれない。ようするにメインスレッドは上位の作業だけに集中できるように書くべきだった。でもそのためにはクラス構造を大幅に変更する必要がある。

それを別にしても、Gen<i>Camからちゃんと動かせるようにしないと、ハードコードしたソースファイルが増える一方で何が何だかわからなくなるのは火を見るより明らか。どうしようかなあ。しょうがないなあ。どこかで折り合いをつけるしかないな。悩ましい....
nice!(0)  コメント(0)  トラックバック(0) 

nice! 0

コメント 0

コメントを書く

お名前:
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

トラックバック 0

OS X10.11 El Capitan..OS XのOpenCL - その24 ブログトップ

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。