Moonmile Solutions Blog

とある事情で「ロケットガール」を見ながら、c/c++の本を書いています。c/c++の本では、windows環境とlinux環境で動作確認をするわけですが、あっちこっちに移動するのが面倒なので、前チェックとして cygwin の gcc/g++ を使っています。

# 「ロケットガール」のほうは後日

さて、Visual C++ 2008 と gcc/g++ ですが、微妙に動作が違います。標準関数系はだいたい同じ（って同じじゃないと困るけど）なんですが、例外やらエラーの発生の仕方が異なります。なので、例外（try-catch）を使って受け取ったときに、メッセージを出力してチェックすることになります。

#include <string>
#include <iostream>
using namespace std;

int main( void )
{
 string str1(&quot;Hello C++ world.&quot;);
 int n;
 
 try {
  n = 4;
  cout << n << &quot;バイト目:[&quot; << str1[n] << &quot;]&quot; << endl;
  n = 100;
  cout << n << &quot;バイト目:[&quot; << str1[n] << &quot;]&quot; << endl;
 } catch ( ... ) {
  cout << &quot;エラーが発生しました &quot; << endl;
 }
 return 1;
}

これを、コマンドラインでコンパイルして、コマンドラインで実行、ってことになります。

cygwin のシェルを立ち上げて、実行すると

＜001＞

な具合に文字化けします。これは、cygwinをインストールした直後にシェルのLANG 環境変数を設定していない場合に、発生します。

なので、日本語（SJIS）が通るように、

export LANG=ja_JP.SJIS

を設定してやると、次のように文字化けせずに済みます。

＜002＞

そんな簡単な話なんですけどね、しばらく使っていないもので結構悩みました。
unicodeが動作するように、wstringを使ってwcoutを利用して出力、setlocate忘れ、で文字化け、なんてのはよくやるのですが。

#include <string>
#include <iostream>
#include <locale.h>
using namespace std;

void main( void )
{
 string str1(&quot;Hello world.&quot;);
 string str2;
 
 str2 = str1;
 cout << str2 << endl;
 str2 = &quot;Hello C++ world.&quot;;
 cout << str2 << endl;
 str2 = 'C';
 cout << str2 << endl;
 // Unicodeを使う
 setlocale(LC_CTYPE, &quot;&quot;); // これが必須
 wstring s;
 s = L&quot;ようこそ C/C++ の世界へ&quot;;
 wcout << s << endl;
}

まあ、ライブラリを作るときは、こういうことに悩まないためにメッセージを英語にしておくのが無難ですね。
「文字コードはunicodeで統一される」と言われて、十数年経ちますが、結局のところ統一されることはないようですので。まだまだ、ASCII(7ビット文字)が現役です。将来的に中国語がのして来るとbig5が多くなったりして。

年末なので、夢を語って終わりにしましょう。

夏頃から構想している動体認識＝Zaku認識の話です。何故「Zaku認識」なのかといえば、当然、緑の量産ザクとシャア・ザクを区別したいからですね（ガンダムRX-78とMk-IIの違いでもいいんだけど、こちらは細部の特徴比較なので少し趣が違う、両方やるけど）。

現在の構想/妄想を公開メモしておきます。少しでも訳が分かった方はコメントなりメールなりを下されば、その先の詳細をお話することはやぶさかではありませぬ（いや、マジで）。

さて、Zaku認識のほうは、動体認識と個体認識を同時にやります。当然、動いているロボットに載せることも考慮して、背景画像からの物体抽出も入ります。いわゆる、視覚と認識の両方を一体化させます。

■前処理

色成分を残さないと、量産ザクとシャア・ザクの区別がつかないので、単純なグレー化では駄目です。
HSV成分に分解するか、グレー色調との混合による色距離を計算します。このために、

・色相、あるいは、YCbCrのCbCrのみの二次元
・明度による一次元

の２種類を使うほうが妥当しょう。

■座標補正

いわゆる、カメラのブレを計算します。移動体にカメラを載せるために、

・上下左右の二次元
・回転
・拡大/縮小

を考慮します。
先行きは、デジタルカメラの手ぶれ補正のように、加速度センサのフィードバックを含めます（そうしないと計算量が膨大になるので、ある程度「予測」を立てるため）。
また、人が頭を左右に振ったときにも、視点を固定するような自動補正を組みいれるためにも、３次元加速度センサのフィードバックが必須です。

当面は、膨大な計算量/高速化をものともしないCPUを使って、フィードバックなしで計算します。
これは、実際に移動体に載せたときには加速度センサによる予測が成り立つのですが、ゲーム画面のように静止したカメラの場合はこの予測が不可能になるためです。つまり、画面からのフィードバックだけを頼りに、動体を追跡します。

座標補正については、前処理で行った画像を元に差分を取ります。
この差分がより少ないものが、正しい背景（静止物体）の認識ができているとみなします。

■動体認識

単純な動体については、超音波センサやレーザーによる反射を使ったほうが効果的です。しかし、ガンダム無双でザクの機体を数えたり、シャア・ザクに向かったりするためには、この方法は取れません。

なので、先の座標補正を行った画像について前後の複数のフレームで比較をします。
当初は、一枚の画像からと考えていたのですが、動体認識をいれたほうがより人間の眼と認識に近いので、この方法をとります。つまりは、残像を追跡します。

動体の追跡に関しては、重心あるいは中央値の移動による計算で十分かと考えています。高速移動物体を認識することも考慮すれば、おそらく、中央値で十分かなと。

懸念事項ではありますが、アニメの切り替えのように、前のフレームが全く違っている場合（画面切り替えが行われた場合）を考慮する必要があります。

■個体認識

その物体が何であるか、を認識するには「認識票（識別信号）」を見ればいいわけですが、敵のZakuでは無理ですよね。なので、機影を確認します。これがパターンマッチングです。ただし、RX-78とMk-IIの違いを認識させるためには、ぼけぼけの画面では無理です。いや、逆にぼけぼけの画面の場合では、両者は同じものとして認識されなければいけません。
また、遠くにあって色識別が難しい場合（空気遠近法など）は、量産ザクの緑とシャア・ザクの赤は区別がつきません。あるいは、赤という色が認識できれば「シャアではないか？」という想像が可能です。

これらを考慮するために、

・テンプレートマッチング法
・特徴量抽出

の２種類を同時にこなす必要があります。

～～

さて、これらが夢なのか妄想なのか、年末出血大サービスなのかは、皆様のご想像にお任せいたします。

ええと、これらのコードを何で書こうかと画策中なのですが、高速化を含めればC言語で書いた方がいいのだけど、プロトタイプはC#で書こうかなと思っています。Javaでもいいんですが、ロジックはokなのですが、画像出力の方法をいくつか調べないといけないので、面倒なんですよね私にとって。まぁ、画像認識は、入力と出力以外は純粋にロジックなので、何で書いてもok。
# OpenCV 準拠ってのも考えたのですが、ひとまず、C#でロジックを書いた後に、C言語で書きなおしたほうが早いかな、と。

そういう訳で、Zaku認識(ザク認識）の「その１」はおしまい。１ヶ月後ぐらいに「その２」を書きましょう。

MSのK高さん的には「それ意味がわからないですからｗ」なんですが、M崎さん的にはどうでしょう？

というわけで、少し真面目に考えてみました（ネーミングも）。
visual basic 6.0.net か、vba.net のどちらがいいか悩みましたが、ドメイン的に「vb60.net」が空いているので、こっちがいいかな、と。

■言語は visual basic 6.0 ベース

言語体系は、visual basic 6.0 がベースにします。なので、クラスはありません。継承できないクラスはあるけど、まあ、最初は実装しなくて良いでしょう。使っている人は多くないし。

なので、基本は sub/function の関数で作ります。

ただし、

set xlapp = CreateObject(“Excel.Application”)

な形で、COM オブジェクトは作れる、と。
それに付随して、.NETクラスライブラリは呼び出せたほうがいいかな、と。

文法的には vb6.0 を踏襲するので、ややこしい構文は open 何とかぐらいなものです。

■中身は IronPython と同じ？

.NET Framework は ver.4 をベースにします。これは、動的言語ランタイム（DLR）を使うためです。というか、使ってみたいがためです。

DLRを使いこなせるようになれば、LUAの移植も可能でしょう。って訳ですね。このあたり、制御用のスクリプト言語として使えるようになります。
http://dlr.codeplex.com/

■動作環境は？

DLRを使うので .NET Framework 4 限定になりますが、LUA 風に silverlight 上でも動く、というのもいいですよね。

できれば、

・visual basic 6.0 のように GUI でアプリを作る環境がある。
　→　最初から、WPF で開発環境を作るとか。
・excel や word の vba から呼び出せる。
・ついでだから、openoffice でも動かせるようにする？

というのもやれるといいかなぁと。
一見（というか何度見ても）、時代に逆行しているように見えますが、無駄な技術を削ぎ落として、コアな部分を残してみるのもひとつの進化のひとつですよね。多様性を見落とさないために。

以前より技術系の勉強会はたくさんでているのですが、最近は月1回が限度。今のところ.NETラボだけに出ています。

そんな訳で、.NETラボでは「おいしい関係」の話をしたのですが、これは珍しいほうで、主に microsoft 系の話が中心です。その中で、今回はMSのK高さんがいらっしゃいました。。。って伏字にする必要はなくて、microsoftのエバンジェリスト日高さんの解説でした。

Code Recipe
http://msdn.microsoft.com/ja-jp/samplecode.recipe.aspx

のうち、今後の予定である silverlight で作るショッピングサイトの例です。
http://msdn.microsoft.com/ja-jp/dd266962.aspx#01

このショッピングサイト、ブラウザ全面で silverlight を使います。このあたり、よくある flash のサイトと同じです。逆に言えば、flash と同等なショッピングサイトを siverlight で作ることを目的としている、、、と思うですがどうなんでしょう？

さて、本筋の解説は日高さんが為さるということで、ちょっと横道を私なりに考察していきます。

以前、LAMP上でsilverlightを使うために、いくつか実験をしました。

手始めに Silverlight+WCFの組み合わせで実験
http://www.moonmile.net/blog/archives/358

この手のショッピングサイトで重要な層は、

・ブラウザによるUI層
・データ検索などの通信層
・サーバーでのデータベース層

の３層があります。細かい部分の違いはさておき（特にデータベース層は、DAOの違いなど異論があるでしょうが）設計段階で、どこで何の技術/言語を使うのかを選定してきます。このあたり、要求仕様段階の技術検証も必要なのですが、

・設計のしやすさ
・プログラマの集めやすさ
・人件費（外注、社内など）

も大きく関わってきます。特に外注になる場合、元請けのコンサルタントが技術面を決めてしまうことが多く、後々のコストが考慮されてない場合が多くあります。

# 現実問題として、提案する会社（microsoft や oracle など）の技術（silverlightやjavaなど）に寄ってしまうのも常だったりしますね。営業的にそういうものです。

さて、ショッピングサイトを作るにしても、外注/内製の違いあり、業務系/一般系の違いあり、というわけで、この段階で何が一番いい技術という訳でもありません。それぞれの違い、特に「得手不得手」を考慮するのが良いでしょう。

例えば、先の３つの層を flash で考えると、

・UI層　Flash
・通信層 xmlhttp
・データベース MySQL

が考えられます。

同じく、Ajax で考えると、

・UI層　ajax(prototype.js, jQuery)
・通信層 xmlhttp
・データベース MySQL

となります。

実は、このUI層はブラウザが前提になっていますが、curl などの専用アプリを用意してもいいし、windows アプリでもいいのです。

・UI層 windows/wpf
・通信層 http/soap
・データベース sql server

なんて感じもできます。

このあたり、層の間のインターフェースだけきちんと考えていけば、何にでも応用ができます。

本当のところ、web サービス、wcf、xml soap、soap なんてのはこれらの繋ぎの部分に使う技術なのですが、なんかフロントエンドが決まってしまっていて、microsoft で言えば、wpf と silverlight がうまく切り替えられないのが問題ですね、という話になります。
wpf が広まらない理由にこれも一因があると思うんです。まぁ、もっと根本的には、microsoft も含めて、この手の技術が多様になり過ぎているのが根本的なところですが（この話はまた別の機会に）

そんな訳で、最近の技術は、

・手早くできる
・分かりやすい

ことに重点が置き過ぎていて、

・汎用性/相互結合

が弱くなっているのかなぁと。軽視という訳ではないけれど、経済的に余裕がなくなっている、という印象を受けます。

それはさておき、私のほうでは、

・UI層 silverlight
・通信層 wcf/soap
・データベース php/mysql

の組合せを実験/実装していきます。