Visual Studioを使った方法です。
１．新しいプロジェクトか、OpenNIを使用したい既存のプロジェクトを開きます。
２．メニューから、「プロジェクト」-「プロパティ」を開きます。
３．C/C++セクションの「全般」で、「追加のインクルードディレクトリ」に、以下を追加します。
$(OPEN_NI_INCLUDE)
これは、OpenNIのインクルードディレクトリの場所を指す環境変数です。
（デフォルトは、C:\Program Files\OpenNI\Include です。）
４．「リンカ」セクションの「全般」で、「追加のライブラリ ディレクトリ」に、以下を追加します。
$(OPEN_NI_LIB)
これは、OpenNIのライブラリファイルのある場所を指す環境変数です。
（デフォルトではC:\Program Files\OpenNI\Lib です。）
５．「リンカ」セクションの「入力」で、「追加の依存ファイル」に、以下を追加します。
OpenNI.lib
６．OpenNIの設定にXMLファイルを使用したい場合、OpenNIの「Data」フォルダにあるサンプルファイルを使用します。
（デフォルトの位置は、C:\Program files\OpenNI\Dataです。）
OpenNIのxmlについて、詳しくは、Xml Scriptsを見てください。
７．上記で説明した、追加のインクルードディレクトリとライブラリディレクトリは、Release構成とDebug構成の両方に設定してください。
８．あなたのコードがCの場合はXnOpenNI.hをインクルードしてください。
C++の場合は、XnCppWrapper.hをインクルードしてください。
2011年6月19日日曜日
Getting Started
Supported Platforms
OpenNIは、以下のプラットフォームをサポートします。
・ Windows XP and later, for 32-bit only
・ Linux Ubuntu 10.10 and later, for x86
Main Objects
・Context Object
contextはOpenNIのメインオブジェクトです。
contextは、アプリケーションが使用しているproduction chainを含む、OpenNIを使用しているアプリケーションの完全な状態を保持します。
同じアプリケーションが１つ以上のcontextを生成できますが、それらのcontextは情報を共有しません。
例えば、認識ミドルウェアは他のcontextのデバイスを使用することはできません。
contextは使用するまえに初期化する必要があります。初期化により、モジュールはロードされ、接続されます。
contextにより使用されたメモリを開放するため、アプリケーションはshutdown関数を呼び出す必要があります。
・Metadata Objects
OpenNIのMetadata Objectは、あるデータのもつプロパティのセットをカプセル化したものです。
例えば、深度マップの典型的なプロパティは、マップの解像度（例えばX方向およびY方向のピクセルの数）です。データを生成するgeneratorは、データを特定するためのMetadata Objectを持ちます。
加えて、Metadata objectは、データ生成時の設定（コンフィグレーション）の記録に重要な役割を果たします。
ノードからデータを読み込んでいるにもかかわらず、アプリケーションが設定（コンフィグレーション）を変更してしまう場合があります。この場合、うまくコントロールしないと、エラーとなってしまいます。
例：
depth generatorがQVGA（320x240）解像度で深度マップを生成するよう設定されており、
アプリケーションはそこから連続的にデータを読み込んでいたとします。
ある時点で、アプリケーションがnodeの出力解像度をVGA(640x480)に設定変更したとします。
新しいフレームデータが届く前は、xn::DepthGenerator::GetDepthMap()を呼び出すと、QVGAのマップが返ってきますが、xn::DepthGenerator::GetMapOutputMode()を呼び出すと、現在の解像度はVGAであると返ってくるため、アプリケーションは不一致に遭遇します。この場合、アプリケーションは受け取った深度マップがVGAであると想定しているため、存在しないピクセルにアクセスしてしまいます。
この場合の解決策は以下のようになります。
個々のnodeはmetadata objectを持っています。metadata objectはデータを読み込んだ際のデータのプロパティを記録しています。上の例の場合、正しい方法は、metadata objectを取得し、そこから解像度を取得することです。
Configuration Changes
OpenNIの設定（コンフィグレーション）オプションは、以下の関数を持ちます。
・Set：設定（コンフィグレーション）を修正する
・Get：現在の値を取得する
・Register/Unregister：オプション変更時のコールバック関数の登録／登録解除を行います。
Data Generators
Map Generator
各種のマップを生成するgeneratorの基本となるインタフェイスです。
主な機能は
・Output Mode property：マップを生成するための設定を制御します。
・Cropping capability
・Alternative Viewpoint capability
・Frame Sync capability
Depth Generator
深度マップを生成するgeneratorです。
主な機能は
・Get depth map：深度マップを生成します。
・Get Device Max Depth：計測可能な最大の距離を取得します。
・Field of View property：センサーの水平方向と垂直方向の角度を設定します。
・User Position capability
Image Generator
カラーイメージマップを生成します。
主な機能は
・Get Image Map
・Pixel format property
IR Generator
IRマップを生成します。
主な機能は
・Get IR Map
Scene Analyzer
センサーの生データを取得し、意味付けしたラベル付きマップを生成するmap generator
主な機能は
・Get Label Map：各ピクセルに意味を持ったラベルを付加したマップを生成します。
（figure1、figure2、backgroundなどのラベルをつけます。）
・Get Floor：床平面の座標を取得します。
Audio Generator
・音声データを生成するオブジェクトです。
主な機能は
・Get Audio Buffer
・Wave Output Modes property：音声出力の設定をします。サンプリング周波数やチャンネル数、ビットレートなどを設定します。
Gesture Generator
人体や手のジェスチャートラッキングを行います。
主な機能は
・Add/Remove Gesture：ジェスチャーのon/offを切り替えます。onにすると、generatorは、ジェスチャーを探し始めます。
・Register/Unregister Gesture callbacks
・Register/Unregister Gesture change
Hand Point Generator
手の位置のトラッキングを行います。
主な機能は
・Start/Stop Tracking：指定した手のトラッキングを開始／終了します。
・Register/Unregister Hand Callbacks：以下のイベントがコールバックを発生します。
新しい手が生成された場合
認識済みの手が移動した場合
認識済みの手を見失った場合
User Generator
空間内の人体データを生成します。
主な機能は
・Get Number of Users：空間内で認識済みのユーザーの人数を返します。
・Get User CoM：ユーザーの中心位置を返します。
・Get User Pixels：ユーザーを表すピクセルを返します。出力は、空間全体のマップで、ユーザーのボディを表すピクセルにはユーザーIDが付加されています。
・Register/Unregister user callbacks：次のアクションがユーザーコールバックを呼び出します。
新しいユーザーを認識した場合
認識済みのユーザーを見失った場合
OpenNIは、以下のプラットフォームをサポートします。
・ Windows XP and later, for 32-bit only
・ Linux Ubuntu 10.10 and later, for x86
Main Objects
・Context Object
contextはOpenNIのメインオブジェクトです。
contextは、アプリケーションが使用しているproduction chainを含む、OpenNIを使用しているアプリケーションの完全な状態を保持します。
同じアプリケーションが１つ以上のcontextを生成できますが、それらのcontextは情報を共有しません。
例えば、認識ミドルウェアは他のcontextのデバイスを使用することはできません。
contextは使用するまえに初期化する必要があります。初期化により、モジュールはロードされ、接続されます。
contextにより使用されたメモリを開放するため、アプリケーションはshutdown関数を呼び出す必要があります。
・Metadata Objects
OpenNIのMetadata Objectは、あるデータのもつプロパティのセットをカプセル化したものです。
例えば、深度マップの典型的なプロパティは、マップの解像度（例えばX方向およびY方向のピクセルの数）です。データを生成するgeneratorは、データを特定するためのMetadata Objectを持ちます。
加えて、Metadata objectは、データ生成時の設定（コンフィグレーション）の記録に重要な役割を果たします。
ノードからデータを読み込んでいるにもかかわらず、アプリケーションが設定（コンフィグレーション）を変更してしまう場合があります。この場合、うまくコントロールしないと、エラーとなってしまいます。
例：
depth generatorがQVGA（320x240）解像度で深度マップを生成するよう設定されており、
アプリケーションはそこから連続的にデータを読み込んでいたとします。
ある時点で、アプリケーションがnodeの出力解像度をVGA(640x480)に設定変更したとします。
新しいフレームデータが届く前は、xn::DepthGenerator::GetDepthMap()を呼び出すと、QVGAのマップが返ってきますが、xn::DepthGenerator::GetMapOutputMode()を呼び出すと、現在の解像度はVGAであると返ってくるため、アプリケーションは不一致に遭遇します。この場合、アプリケーションは受け取った深度マップがVGAであると想定しているため、存在しないピクセルにアクセスしてしまいます。
この場合の解決策は以下のようになります。
個々のnodeはmetadata objectを持っています。metadata objectはデータを読み込んだ際のデータのプロパティを記録しています。上の例の場合、正しい方法は、metadata objectを取得し、そこから解像度を取得することです。
Configuration Changes
OpenNIの設定（コンフィグレーション）オプションは、以下の関数を持ちます。
・Set：設定（コンフィグレーション）を修正する
・Get：現在の値を取得する
・Register/Unregister：オプション変更時のコールバック関数の登録／登録解除を行います。
Data Generators
Map Generator
各種のマップを生成するgeneratorの基本となるインタフェイスです。
主な機能は
・Output Mode property：マップを生成するための設定を制御します。
・Cropping capability
・Alternative Viewpoint capability
・Frame Sync capability
Depth Generator
深度マップを生成するgeneratorです。
主な機能は
・Get depth map：深度マップを生成します。
・Get Device Max Depth：計測可能な最大の距離を取得します。
・Field of View property：センサーの水平方向と垂直方向の角度を設定します。
・User Position capability
Image Generator
カラーイメージマップを生成します。
主な機能は
・Get Image Map
・Pixel format property
IR Generator
IRマップを生成します。
主な機能は
・Get IR Map
Scene Analyzer
センサーの生データを取得し、意味付けしたラベル付きマップを生成するmap generator
主な機能は
・Get Label Map：各ピクセルに意味を持ったラベルを付加したマップを生成します。
（figure1、figure2、backgroundなどのラベルをつけます。）
・Get Floor：床平面の座標を取得します。
Audio Generator
・音声データを生成するオブジェクトです。
主な機能は
・Get Audio Buffer
・Wave Output Modes property：音声出力の設定をします。サンプリング周波数やチャンネル数、ビットレートなどを設定します。
Gesture Generator
人体や手のジェスチャートラッキングを行います。
主な機能は
・Add/Remove Gesture：ジェスチャーのon/offを切り替えます。onにすると、generatorは、ジェスチャーを探し始めます。
・Register/Unregister Gesture callbacks
・Register/Unregister Gesture change
Hand Point Generator
手の位置のトラッキングを行います。
主な機能は
・Start/Stop Tracking：指定した手のトラッキングを開始／終了します。
・Register/Unregister Hand Callbacks：以下のイベントがコールバックを発生します。
新しい手が生成された場合
認識済みの手が移動した場合
認識済みの手を見失った場合
User Generator
空間内の人体データを生成します。
主な機能は
・Get Number of Users：空間内で認識済みのユーザーの人数を返します。
・Get User CoM：ユーザーの中心位置を返します。
・Get User Pixels：ユーザーを表すピクセルを返します。出力は、空間全体のマップで、ユーザーのボディを表すピクセルにはユーザーIDが付加されています。
・Register/Unregister user callbacks：次のアクションがユーザーコールバックを呼び出します。
新しいユーザーを認識した場合
認識済みのユーザーを見失った場合
Backwards Compatibility
OpenNIは完全な後方互換性を保証します。
これは、ある特定のバージョンのOpenNIで作成されたアプリケーションは、
再コンパイルなしで将来のOpenNIのバージョンでも動作することを保証します。
実際場面で、このことは、理想的にはコンピュータには最新のOpenNIがインストールされるべきであることを意味します。
もしそうでない場合、コンピュータにインストールされたアプリケーションから、最新のOpenNIを要求されます。
これを実現するため、アプリケーションはOpenNIも同時にインストールすることを推奨します。
Production Node Error Status
Production Nodeは、それが現在機能しているかどうかを表す、エラーステータスを持ちます。
たとえば、もしデバイスがコンピュータに接続されていなければ、デバイスnodeは機能することができません。
デフォルトのエラーステータスは、Error Status capabilityが実装されていなければ、いつも「OK」です。
このcapabilityは、production nodeに、エラー発生時のエラーステータスの変化を可能にする能力です。
このcapabilityが実装されていない場合、ステータスはいつも「OK」です。
アプリケーションは、エラーのnodeが「どれか」に興味がなく、エラーのnodeがあるかどうかだけ知りたい場合でも、それぞれのnodeのステータスを調べる必要があります。
nodeのエラーステータスが変化した際の通知を受け取るために、アプリケーションはコールバック関数を登録することができます。
OpenNIは、すべてのnodeのエラーステータスを、「Global Error Status」と呼ばれるエラーステータスに集約します。
これは、アプリケーションが、nodeの現在の状態を取得するのを簡単にします。
Global Error Status「XN_STATUS_OK」はすべてのnodeのエラーステータスがOKであることを意味します。
もし、１つのnodeにだけエラーが発生した場合、そのエラーステータスが、Global Error Statusとなります。
（たとえば、もし一つのセンサーが接続されていなければ、Global Error Statusは、XN_STATUS_DEVICE_NOT_CONNECTED になります。）
もし１つより多くのnodeがエラーの場合、Global Error Statusは、XN_STATUS_MULTIPLE_NODES_ERROR になります。このような状況の場合、アプリケーションはすべてのnodeをチェックしてerror nodeを特定し、原因を調べる必要があります。
たとえば、もしデバイスがコンピュータに接続されていなければ、デバイスnodeは機能することができません。
デフォルトのエラーステータスは、Error Status capabilityが実装されていなければ、いつも「OK」です。
このcapabilityは、production nodeに、エラー発生時のエラーステータスの変化を可能にする能力です。
このcapabilityが実装されていない場合、ステータスはいつも「OK」です。
アプリケーションは、エラーのnodeが「どれか」に興味がなく、エラーのnodeがあるかどうかだけ知りたい場合でも、それぞれのnodeのステータスを調べる必要があります。
nodeのエラーステータスが変化した際の通知を受け取るために、アプリケーションはコールバック関数を登録することができます。
OpenNIは、すべてのnodeのエラーステータスを、「Global Error Status」と呼ばれるエラーステータスに集約します。
これは、アプリケーションが、nodeの現在の状態を取得するのを簡単にします。
Global Error Status「XN_STATUS_OK」はすべてのnodeのエラーステータスがOKであることを意味します。
もし、１つのnodeにだけエラーが発生した場合、そのエラーステータスが、Global Error Statusとなります。
（たとえば、もし一つのセンサーが接続されていなければ、Global Error Statusは、XN_STATUS_DEVICE_NOT_CONNECTED になります。）
もし１つより多くのnodeがエラーの場合、Global Error Statusは、XN_STATUS_MULTIPLE_NODES_ERROR になります。このような状況の場合、アプリケーションはすべてのnodeをチェックしてerror nodeを特定し、原因を調べる必要があります。
Recording
Recordingは、強力なデバックツールです。
データをすべてキャプチャし、デバック時に、ストリームを完全に再現することが可能です。
OpenNIは、Production node chainのレコーディングをサポートします。
個々のnodeの完全な設定（コンフィグレーション）とnodeからの全データストリームを記録できます。
OpenNIは、データを記録し、再生するフレームワークを持っています。（再生の際はmock nodeを使用します。）
それらは、nimRecorderモジュールにより実現されます。
nimRecorderモジュールは、".ONI"ファイルフォーマットを定義し、このフォーマットによる記録と再生をサポートします。
データをすべてキャプチャし、デバック時に、ストリームを完全に再現することが可能です。
OpenNIは、Production node chainのレコーディングをサポートします。
個々のnodeの完全な設定（コンフィグレーション）とnodeからの全データストリームを記録できます。
OpenNIは、データを記録し、再生するフレームワークを持っています。（再生の際はmock nodeを使用します。）
それらは、nimRecorderモジュールにより実現されます。
nimRecorderモジュールは、".ONI"ファイルフォーマットを定義し、このフォーマットによる記録と再生をサポートします。
General Framework Utilities
OpenNI APIに加えて、アーキテクチャやOSの違いを吸収するため、
以下のユーティリティが用意されています。
・USBアクセス用の抽象レイヤ
・基本的なデータ型の実装（リストやハッシュなど）
・ログとダンプ
・メモリ＆パフォーマンスプロファイル
・イベント（イベントに対するコールバックを実現するため）
・タスクスケジューラ
OpenNIを使用するアプリケーションは、これらのユーティリティを使用可能です。
しかし、これらのユーティリティはOpenNIの標準には含まれないため、
完全な後方互換性は保証されません。
以下のユーティリティが用意されています。
・USBアクセス用の抽象レイヤ
・基本的なデータ型の実装（リストやハッシュなど）
・ログとダンプ
・メモリ＆パフォーマンスプロファイル
・イベント（イベントに対するコールバックを実現するため）
・タスクスケジューラ
OpenNIを使用するアプリケーションは、これらのユーティリティを使用可能です。
しかし、これらのユーティリティはOpenNIの標準には含まれないため、
完全な後方互換性は保証されません。
Licensing
OpenNIは、モジュールやアプリケーションが使用する、シンプルなライセンスシステムを提供します。
OpenNI Context Object（OpenNIを使用しているすべてのアプリケーションの状態を保持するオブジェクト）は、現在ロードされているライセンスのリストを保持します。
このリストは、あるライセンスを検索する、どの段階でもアクセス可能です。
ライセンスは、ベンダー名と、ライセンスキーから構成されます。
このライセンスシステムを使いたいベンダーは、独自のキーフォーマットを使用することができます。
ライセンスシステムはモジュールによって使用され、モジュールが、認証済みのアプリケーションによって使用されていることを保証します。
特定のコンピュータにインストールされた特定のベンダーの提供するモジュールが、
特定のアプリケーションからのみアクセス可能であることを保証します。
Production Nodeの列挙プロセスにおいて、OpenNIは有効なProduction Chainを探しますが、
その際にモジュールはライセンスをチェックします。もし有効なライセンスが登録されていなければ、
モジュールは自身を隠してしまい、結果として、有効なProduction Chainとはなりません。
OpenNIは、ライセンスキーのグローバル登録もサポートします。
グローバル登録の場合、OpenNI Context Objectを初期化する際にロードされます。
大部分のモジュールはインストールの際にライセンスキーを必要とします。
ユーザーが入力したライセンスキーは、niLicenceコマンドラインツールを使って、グローバルライセンスレジストリに登録されます。niLicenceコマンドラインツールは、登録解除の際にも使用します。
加えて、アプリケーションはモジュールのプライベートライセンスを持つことも可能です。
これは、あるモジュールが、特定のアプリケーションからのみ使用可能であることを意味します。
（他のアプリケーションがモジュールを使用することを禁止します。）
OpenNI Context Object（OpenNIを使用しているすべてのアプリケーションの状態を保持するオブジェクト）は、現在ロードされているライセンスのリストを保持します。
このリストは、あるライセンスを検索する、どの段階でもアクセス可能です。
ライセンスは、ベンダー名と、ライセンスキーから構成されます。
このライセンスシステムを使いたいベンダーは、独自のキーフォーマットを使用することができます。
ライセンスシステムはモジュールによって使用され、モジュールが、認証済みのアプリケーションによって使用されていることを保証します。
特定のコンピュータにインストールされた特定のベンダーの提供するモジュールが、
特定のアプリケーションからのみアクセス可能であることを保証します。
Production Nodeの列挙プロセスにおいて、OpenNIは有効なProduction Chainを探しますが、
その際にモジュールはライセンスをチェックします。もし有効なライセンスが登録されていなければ、
モジュールは自身を隠してしまい、結果として、有効なProduction Chainとはなりません。
OpenNIは、ライセンスキーのグローバル登録もサポートします。
グローバル登録の場合、OpenNI Context Objectを初期化する際にロードされます。
大部分のモジュールはインストールの際にライセンスキーを必要とします。
ユーザーが入力したライセンスキーは、niLicenceコマンドラインツールを使って、グローバルライセンスレジストリに登録されます。niLicenceコマンドラインツールは、登録解除の際にも使用します。
加えて、アプリケーションはモジュールのプライベートライセンスを持つことも可能です。
これは、あるモジュールが、特定のアプリケーションからのみ使用可能であることを意味します。
（他のアプリケーションがモジュールを使用することを禁止します。）
Sharing Devices between Applications and Locking Nodes
ほとんどのケースでは、OpenNIのnodeが生成するデータは、ハードウェアデバイスからやってきます。
ハードウェアデバイスは、1つ以上の設定（コンフィグレーション）を設定できます。
ゆえに、いくつかのアプリケーションが同時に同じデバイスを使用する場合、
その設定（コンフィグレーション）は同期されなければなりません。
しかし、通常、アプリケーションを書いているときに、他のどんなアプリケーションが同時実行されるのか知ることはできないので、設定の同期は不可能です。
加えて、アプリケーションが、ある特定の設定を必要とし、他の設定ではアプリケーションが正常に動作しない場合もあります。
OpenNIでは、複数のアプリケーションがハードウェアデバイスを共有するための２つのモードを用意しています。
・Full Sharing(default)
このモードでは、アプリケーションは設定ハンドラを宣言します。
OpenNIインターフェースは、設定変更時に呼ばれるコールバック関数を登録できるようにします。
これにより、設定変更時にはアプリケーションは通知を受け取ることができます。
（設定を変更したのがアプリケーション自身であっても、他のアプリケーションであっても通知を受け取ります。）
・Locking Configuration
このモードでは、アプリケーションは、あるNodeの現在の設定をロックする要求を発行します。
このため、このモードでは、OpenNIは「Set」関数の呼び出しを許可しません。
nodeがハードウェアデバイスである場合（または、プロセス境界を越えて共有されるようなオブジェクトの場合）、nodeは「Lock Aware」capabilityをサポートする必要があります。
「Lock Aware」capabilityは、プロセス境界を越えてロックする能力を意味します。
注
nodeがロックされた場合、ロックしたアプリケーションはロックハンドルを受け取ります。
nodeをアンロックすることに加えて、このハンドルは、ロックを解除することなしに、設定を変更することを可能にします。
（他のアプリケーションに設定を盗まれないようにするためです。）
ハードウェアデバイスは、1つ以上の設定（コンフィグレーション）を設定できます。
ゆえに、いくつかのアプリケーションが同時に同じデバイスを使用する場合、
その設定（コンフィグレーション）は同期されなければなりません。
しかし、通常、アプリケーションを書いているときに、他のどんなアプリケーションが同時実行されるのか知ることはできないので、設定の同期は不可能です。
加えて、アプリケーションが、ある特定の設定を必要とし、他の設定ではアプリケーションが正常に動作しない場合もあります。
OpenNIでは、複数のアプリケーションがハードウェアデバイスを共有するための２つのモードを用意しています。
・Full Sharing(default)
このモードでは、アプリケーションは設定ハンドラを宣言します。
OpenNIインターフェースは、設定変更時に呼ばれるコールバック関数を登録できるようにします。
これにより、設定変更時にはアプリケーションは通知を受け取ることができます。
（設定を変更したのがアプリケーション自身であっても、他のアプリケーションであっても通知を受け取ります。）
・Locking Configuration
このモードでは、アプリケーションは、あるNodeの現在の設定をロックする要求を発行します。
このため、このモードでは、OpenNIは「Set」関数の呼び出しを許可しません。
nodeがハードウェアデバイスである場合（または、プロセス境界を越えて共有されるようなオブジェクトの場合）、nodeは「Lock Aware」capabilityをサポートする必要があります。
「Lock Aware」capabilityは、プロセス境界を越えてロックする能力を意味します。
注
nodeがロックされた場合、ロックしたアプリケーションはロックハンドルを受け取ります。
nodeをアンロックすることに加えて、このハンドルは、ロックを解除することなしに、設定を変更することを可能にします。
（他のアプリケーションに設定を盗まれないようにするためです。）
Generating and Reading Data
Generating Data
前に示したように、データを生成するProduction nodeを、「Generator」と呼びます。
Generatorの生成後は、アプリケーションによる設定が必要となる場合があるため、
即座にデータの生成を開始するわけではありません。
このことは、アプリケーション提供されるデータは、アプリケーションによる設定に従って生成されていることを保証します。
Generatorは、データを生成するよう指示されるまで、データを生成しません。
xn::Generator::StartGenerating() 関数は、データ生成を開始するのに使用します。
また、アプリケーションは、xn::Generator::StopGenerating()を使用することで、nodeを破棄せずにデータ生成を中断し、nodeの設定を変更することができます。
Reading Data
Data Generatorは、連続的に新しいデータを生成します。
しかし、アプリケーションは、古いデータもまた使用可能です。（たとえば、深度マップの前のフレームデータなど）
この結果として、generatorは、新しいデータの取得を明示的に指示されるまで、新しいデータを内部的に保持します。
このことは、アプリケーションが「UpdateData」関数によって明確に指示するまで、Data Generatorは新しいデータを内部に隠していることを意味します。
OpenNIは、xn::Generator::WaitAndUpdateDate()関数によって、新しいデータが取得可能になるまで、アプリケーションを待機させることができます。
あるケースでは、アプリケーションは１つ以上のnodeを持ち、すべてのnodeのupdateが必要になることがあります。
OpenNIはこれを行うための関数をいくつか用意しています。
これらの関数の違いは、UpdateAllの引き金となるイベントの違いです。
・xn::Context::WaitAndUpdateAll()
待機中のnodeの１つで新しいデータが取得可能になったとき、すべてのnodeをupdateする
・xn::Context::WaitOneUpdateAll()
ある特定の１つのnodeを監視し、そのnodeの新しいデータが取得可能になったとき、すべてのnodeをupdateする。これは、複数のnodeがあるが、そのうちの１つのnodeがアプリケーションの進行を決定する場合に有効です。
・xn::Context::WaitNoneUpdateAll()
待機せずに、即座にすべてのnodeをupdateします。
・xn::Context::WaitAndUpdateAll()
すべてのnodeを待機し、すべてのnodeで新しいデータが取得可能になったら、updateします。
上記の４つの関数は、２秒のタイムアウト後に終了します。
ある特定のnodeのみupdateする必要がある場合を除いて、通常はxn::Context::Wait[...]UpdateAll()関数を使用することを強く推奨します。
すべてのnodeをupdateすることは、以下の点で有益です。
・nodeが相互に依存している場合、目的のnode（アプリケーションがupdateしたいnode）が依存しているnode（このnodeは、より低レベルなnodeで、他のnodeにデータを供給するnodeです。）が、updateされた後に、目的のnodeがupdateされることを保証します。
・記録からデータを再生している場合、条件に合致するまで再生を続けます。
・recorderが存在する場合、この関数は自動的にrecorderの対象となるnodeからの記録を始めます。
Mock Nodes
OpenNIはnodeのMock実装をサポートします。
nodeのMock実装は、データの生成ロジックを一切含みません。
代わりに、（アプリケーションや、他のnode実装などの）外部コンポーネントに対して設定変更やデータを与えることを可能にします。
アプリケーションがMock nodeを必要とするケースはまれです。
ただ、データ再生を行うnodeが、データ読み込みの際に、実際のnodeをシミュレートする場合は有用です。
前に示したように、データを生成するProduction nodeを、「Generator」と呼びます。
Generatorの生成後は、アプリケーションによる設定が必要となる場合があるため、
即座にデータの生成を開始するわけではありません。
このことは、アプリケーション提供されるデータは、アプリケーションによる設定に従って生成されていることを保証します。
Generatorは、データを生成するよう指示されるまで、データを生成しません。
xn::Generator::StartGenerating() 関数は、データ生成を開始するのに使用します。
また、アプリケーションは、xn::Generator::StopGenerating()を使用することで、nodeを破棄せずにデータ生成を中断し、nodeの設定を変更することができます。
Reading Data
Data Generatorは、連続的に新しいデータを生成します。
しかし、アプリケーションは、古いデータもまた使用可能です。（たとえば、深度マップの前のフレームデータなど）
この結果として、generatorは、新しいデータの取得を明示的に指示されるまで、新しいデータを内部的に保持します。
このことは、アプリケーションが「UpdateData」関数によって明確に指示するまで、Data Generatorは新しいデータを内部に隠していることを意味します。
OpenNIは、xn::Generator::WaitAndUpdateDate()関数によって、新しいデータが取得可能になるまで、アプリケーションを待機させることができます。
あるケースでは、アプリケーションは１つ以上のnodeを持ち、すべてのnodeのupdateが必要になることがあります。
OpenNIはこれを行うための関数をいくつか用意しています。
これらの関数の違いは、UpdateAllの引き金となるイベントの違いです。
・xn::Context::WaitAndUpdateAll()
待機中のnodeの１つで新しいデータが取得可能になったとき、すべてのnodeをupdateする
・xn::Context::WaitOneUpdateAll()
ある特定の１つのnodeを監視し、そのnodeの新しいデータが取得可能になったとき、すべてのnodeをupdateする。これは、複数のnodeがあるが、そのうちの１つのnodeがアプリケーションの進行を決定する場合に有効です。
・xn::Context::WaitNoneUpdateAll()
待機せずに、即座にすべてのnodeをupdateします。
・xn::Context::WaitAndUpdateAll()
すべてのnodeを待機し、すべてのnodeで新しいデータが取得可能になったら、updateします。
上記の４つの関数は、２秒のタイムアウト後に終了します。
ある特定のnodeのみupdateする必要がある場合を除いて、通常はxn::Context::Wait[...]UpdateAll()関数を使用することを強く推奨します。
すべてのnodeをupdateすることは、以下の点で有益です。
・nodeが相互に依存している場合、目的のnode（アプリケーションがupdateしたいnode）が依存しているnode（このnodeは、より低レベルなnodeで、他のnodeにデータを供給するnodeです。）が、updateされた後に、目的のnodeがupdateされることを保証します。
・記録からデータを再生している場合、条件に合致するまで再生を続けます。
・recorderが存在する場合、この関数は自動的にrecorderの対象となるnodeからの記録を始めます。
Mock Nodes
OpenNIはnodeのMock実装をサポートします。
nodeのMock実装は、データの生成ロジックを一切含みません。
代わりに、（アプリケーションや、他のnode実装などの）外部コンポーネントに対して設定変更やデータを与えることを可能にします。
アプリケーションがMock nodeを必要とするケースはまれです。
ただ、データ再生を行うnodeが、データ読み込みの際に、実際のnodeをシミュレートする場合は有用です。
Capabilities
Capabilities mechanismは、複数のミドルウェアとデバイスをOpenNIに登録できる、という柔軟性を提供します。
OpenNIは、異なるベンダーが能力を変更したり、コンフィグレーションオプションをProduction Nodeに提供するのを許可します。それゆえに、ある種のオプション拡張がOpenNIによって定義されています。
それらのオプション拡張に関するAPIは、「Capabilities」と呼びます。
また、その拡張を実装するかどうか、ベンダーが決めることができます。
Producion Nodeは、ある能力をサポートしているかどうか問い合わせることができます。
その問い合わせは、個々のnodeに対して行われます。
OpenNIは、能力のセットを提供しており、このセットは将来追加される可能性があります。
モジュールは、自分がサポートする能力を宣言することができます。
さらに、Produciton Chainの列挙時、アプリケーションは、特定の能力を必須条件として指定することができます。その場合、指定された能力をサポートするモジュールのみが返されます。
現在サポートされているcapabilities
・Alternative View
マップを生成する型（深度マップ、イメージマップ、IR）に対し、センサーが別の場所にあるかのように、マップデータを変換する能力
「別の場所」は、他のProduction Nodeによって提供され、通常、他のセンサーが出力するマップです。
・Cropping
マップを生成する型（深度マップ、イメージマップ、IR）に対し、フレーム全体ではなく、指定領域のみを出慮ｋうする能力。
Croppingが有効な場合、生成されるマップのサイズは、より低い解像度となります。
たとえば、map generatorがVGA（640x480）で出力し、アプリケーションが300x200サイズのCroppingを指定した場合、横１行のピクセル配列のサイズは300ピクセルになります。
Croppingは、パフォーマンスチューニングに有効です。
・Frame Sync
２つのフレームデータを生成するセンサー（たとえば、深度センサーとイメージセンサー）に対し、それらのフレームの同期をとることができる能力です。
・Mirror
generatorによって生成されたデータを鏡像反転する能力。Mirroringは、センサーが人物の正面に置かれている場合に有効です。（その場合、センサーが取得したデータは鏡像反転されている、つまり右手が左手の位置にあるため）
・Pose Detection
user generatorの能力で、人物がある特定の位置でポーズをとったことを認識する能力。
・Skeleton
user generatorが、人体のデータを、Skeletonデータとして出力する能力。
このデータは、間接の位置データを含みます。
また、Skeletonの位置をトラッキングする能力、user calibrationの能力も含みます。
・User Position
深度Generatorが、空間の特定の領域に関する出力を活用する能力
・Error State
nodeが、エラー状態であることを通知する能力。
「エラー」とは、実用上、nodeが適切に機能しない状態を言います。
・Lock Aware
nodeが、ある領域の外側をロックする能力。詳しくは、「アプリケーション間のデバイス共有とNodeロック」（Sharing Devices between Applications and Locking Nodes）を見てください。
OpenNIは、異なるベンダーが能力を変更したり、コンフィグレーションオプションをProduction Nodeに提供するのを許可します。それゆえに、ある種のオプション拡張がOpenNIによって定義されています。
それらのオプション拡張に関するAPIは、「Capabilities」と呼びます。
また、その拡張を実装するかどうか、ベンダーが決めることができます。
Producion Nodeは、ある能力をサポートしているかどうか問い合わせることができます。
その問い合わせは、個々のnodeに対して行われます。
OpenNIは、能力のセットを提供しており、このセットは将来追加される可能性があります。
モジュールは、自分がサポートする能力を宣言することができます。
さらに、Produciton Chainの列挙時、アプリケーションは、特定の能力を必須条件として指定することができます。その場合、指定された能力をサポートするモジュールのみが返されます。
現在サポートされているcapabilities
・Alternative View
マップを生成する型（深度マップ、イメージマップ、IR）に対し、センサーが別の場所にあるかのように、マップデータを変換する能力
「別の場所」は、他のProduction Nodeによって提供され、通常、他のセンサーが出力するマップです。
・Cropping
マップを生成する型（深度マップ、イメージマップ、IR）に対し、フレーム全体ではなく、指定領域のみを出慮ｋうする能力。
Croppingが有効な場合、生成されるマップのサイズは、より低い解像度となります。
たとえば、map generatorがVGA（640x480）で出力し、アプリケーションが300x200サイズのCroppingを指定した場合、横１行のピクセル配列のサイズは300ピクセルになります。
Croppingは、パフォーマンスチューニングに有効です。
・Frame Sync
２つのフレームデータを生成するセンサー（たとえば、深度センサーとイメージセンサー）に対し、それらのフレームの同期をとることができる能力です。
・Mirror
generatorによって生成されたデータを鏡像反転する能力。Mirroringは、センサーが人物の正面に置かれている場合に有効です。（その場合、センサーが取得したデータは鏡像反転されている、つまり右手が左手の位置にあるため）
・Pose Detection
user generatorの能力で、人物がある特定の位置でポーズをとったことを認識する能力。
・Skeleton
user generatorが、人体のデータを、Skeletonデータとして出力する能力。
このデータは、間接の位置データを含みます。
また、Skeletonの位置をトラッキングする能力、user calibrationの能力も含みます。
・User Position
深度Generatorが、空間の特定の領域に関する出力を活用する能力
・Error State
nodeが、エラー状態であることを通知する能力。
「エラー」とは、実用上、nodeが適切に機能しない状態を言います。
・Lock Aware
nodeが、ある領域の外側をロックする能力。詳しくは、「アプリケーション間のデバイス共有とNodeロック」（Sharing Devices between Applications and Locking Nodes）を見てください。
Production Chains
前の章で説明したように、複数のモジュール（センサーと認識ミドルウェア）を同時にOpenNI実装に登録することができます。
この構成は、アプリケーションに、データの取得や処理に使用するセンサーや認識ミドルウェアの選択の柔軟性を与えてくれます。
Production Chainとは？
Production Nodeの章で、user generator型のProduction Nodeがアプリケーションによって生成される例を見ました。
人体データ（body data）を生成するために、このProduction Nodeは、より低レベルのProduction Nodeであり、センサーから生データを取得するdepth generatorを使いました。
この例で、Production Nodeのシーケンス（user generator -> depth generator）は、人体データを生成するために互いに依存しており、これをProduction Chainと呼びます
異なるベンダーが、同じProduction Node型の実装を提供することができます。
例：
Ａブランドがuser generatorの実装を提供しているとし、Ｂブランドがまた別のuser generatorの実装を提供しているとします。
両方のgeneratorはアプリケーションの開発者が利用可能です。
OpenINは、アプリケーションが、どのモジュールを使用するか、どのProduction Chainを使用するか、定義することを可能にしています。
OpenNIは、登録済みのモジュールから、可能なProduction Chainの組み合わせをすべて列挙します。
アプリケーションは、好ましいブランドや、バージョンなどに従って、そこから１つのChainを選択します。
注：アプリケーションは、chainを特定せず、OpenNIから、最初のchainを取得することも可能です。
普通、アプリケーションは、chainの最上位にのみ興味があります。
これは、アプリケーションにとって使い物になるレベルのデータを提供してくれるnodeだからです。
たとえば、hand point generatorなど。
OpenNIでは、その下にあるchainを意識することなしに、アプリケーションが一つのnodeだけを利用することも可能です。
詳細な設定のために、このchainにアクセスして、個々のnodeを設定することも可能です。
たとえば、前に、OpenNIに複数のモジュール（認識ミドルウェアとデバイス）を登録する例を見ました。
その場合、アプリケーションがuser genertorを要求すると、OpenNIは以下のように、人体データを取得するための４種類のProduction Chainを返します。
上図は、以下のモジュールがOpenNIに登録された場合の例です。
・異なるベンダーの供給する、２つの人体認識見取るウェア。
・異なるベンダーの提供する、２つの3Dセンサー。
上図は、この実装中で見つかった、４つの選択可能なProduction chainを表します。
それぞれのChainは、人体認識ミドルウェアと3Dセンサーの可能な組み合わせを表します。
OpenNIは、アプリケーションが上の４つから１つを選択できるようにします。
この構成は、アプリケーションに、データの取得や処理に使用するセンサーや認識ミドルウェアの選択の柔軟性を与えてくれます。
Production Chainとは？
Production Nodeの章で、user generator型のProduction Nodeがアプリケーションによって生成される例を見ました。
人体データ（body data）を生成するために、このProduction Nodeは、より低レベルのProduction Nodeであり、センサーから生データを取得するdepth generatorを使いました。
この例で、Production Nodeのシーケンス（user generator -> depth generator）は、人体データを生成するために互いに依存しており、これをProduction Chainと呼びます
異なるベンダーが、同じProduction Node型の実装を提供することができます。
例：
Ａブランドがuser generatorの実装を提供しているとし、Ｂブランドがまた別のuser generatorの実装を提供しているとします。
両方のgeneratorはアプリケーションの開発者が利用可能です。
OpenINは、アプリケーションが、どのモジュールを使用するか、どのProduction Chainを使用するか、定義することを可能にしています。
OpenNIは、登録済みのモジュールから、可能なProduction Chainの組み合わせをすべて列挙します。
アプリケーションは、好ましいブランドや、バージョンなどに従って、そこから１つのChainを選択します。
注：アプリケーションは、chainを特定せず、OpenNIから、最初のchainを取得することも可能です。
普通、アプリケーションは、chainの最上位にのみ興味があります。
これは、アプリケーションにとって使い物になるレベルのデータを提供してくれるnodeだからです。
たとえば、hand point generatorなど。
OpenNIでは、その下にあるchainを意識することなしに、アプリケーションが一つのnodeだけを利用することも可能です。
詳細な設定のために、このchainにアクセスして、個々のnodeを設定することも可能です。
たとえば、前に、OpenNIに複数のモジュール（認識ミドルウェアとデバイス）を登録する例を見ました。
その場合、アプリケーションがuser genertorを要求すると、OpenNIは以下のように、人体データを取得するための４種類のProduction Chainを返します。
・異なるベンダーの供給する、２つの人体認識見取るウェア。
・異なるベンダーの提供する、２つの3Dセンサー。
上図は、この実装中で見つかった、４つの選択可能なProduction chainを表します。
それぞれのChainは、人体認識ミドルウェアと3Dセンサーの可能な組み合わせを表します。
OpenNIは、アプリケーションが上の４つから１つを選択できるようにします。
2011年6月18日土曜日
Production Node
「意味のある」3Dデータは、空間を翻訳し、理解することによって得られます。
意味のある3Dデータの生成は複雑な仕事です。
典型的には、この仕事は生データを出力するセンサーを使います。
この生データは、各ピクセルがセンサーからの距離になっているdepth mapであることが多いです。
専用のミドルウェアでこれを処理し、アプリケーションに渡すための上位データを生成します。
OpenNIでは、「Production Node」という言葉を定義します。
Production Nodeとは、NIアプリケーションに必要なデータを生成する過程において、生産的な役割を果たすコンポーネントのことです。
Production Nodeは、ある特定のデータ生成に関わる機能一式をカプセル化したものです。
Production Nodeは、OpenNIがアプリケーションに提供するインタフェースの基本的な構成要素となるものです。
しかしながら、Production NodeのAPIは、インタフェイスなど標準的なルールを定義するだけです。データを生成するロジックは、OpenNIに登録されたモジュールで実装する必要があります。
たとえば、手の位置を生成する機能一式を揃えたProduction Nodeがあったとして、
手の位置データの生成ロジックは、OpenNIに登録され、かつそのようなデータ生成ロジックを実装した、OpenNI外部のモジュールが行わなければなりません。
原則として、Production Nodeは、特定のデータを生成する、独立した存在です。
そして、生成したデータを、他のProduction Nodeや、アプリケーションなど、様々なオブジェクトに提供します。
しかし、中には、他の低レベルデータを生成するProduction Nodeに依存し、その低レベルデータを分析してアプリケーションにデータを提供するProduction Nodeも存在します。
例
３次元空間内の人間の動きをトラッキングするアプリケーションを考えてみましょう。
このアプリケーションは、人体データを提供してくれるProduction Nodeが必要です。
このようなProduction Nodeを「user generator」と呼びます。
user generatorは、元データを「depth generator」から取得します。
depth generatorはセンサーによって実装されたProduction Nodeで、深度センサーから生のセンサーデータを取得し、（たとえば、毎秒Xフレームのストリームデータです。）そして、深度マップとして出力します。
より上位のレベルの例をいくつか見てみましょう
１．1ユーザーの手の位置の取得
ユーザーの手のひらの中心（よく、ハンドポイントと呼ばれる点です）や、指先を出力します。
２．空間内の人体の取得
人体の間接の現在の位置と向きを出力します。
（よく、人体データ（=body data)と呼ばれます。）
３．手のジェスチャーの認識
出力は、特定のジェスチャーが発生した、というアプリケーションへのメッセージになります。
Production Node型
Production Nodeは型をもっており、次のいずれかのカテゴリに分類されます。
１．Sensor-Related Production Nodes
２．Middleware-Related Production Nodes
現在、OpenNIでは以下のProduction Node型をサポートします。
意味のある3Dデータの生成は複雑な仕事です。
典型的には、この仕事は生データを出力するセンサーを使います。
この生データは、各ピクセルがセンサーからの距離になっているdepth mapであることが多いです。
専用のミドルウェアでこれを処理し、アプリケーションに渡すための上位データを生成します。
OpenNIでは、「Production Node」という言葉を定義します。
Production Nodeとは、NIアプリケーションに必要なデータを生成する過程において、生産的な役割を果たすコンポーネントのことです。
Production Nodeは、ある特定のデータ生成に関わる機能一式をカプセル化したものです。
Production Nodeは、OpenNIがアプリケーションに提供するインタフェースの基本的な構成要素となるものです。
しかしながら、Production NodeのAPIは、インタフェイスなど標準的なルールを定義するだけです。データを生成するロジックは、OpenNIに登録されたモジュールで実装する必要があります。
たとえば、手の位置を生成する機能一式を揃えたProduction Nodeがあったとして、
手の位置データの生成ロジックは、OpenNIに登録され、かつそのようなデータ生成ロジックを実装した、OpenNI外部のモジュールが行わなければなりません。
原則として、Production Nodeは、特定のデータを生成する、独立した存在です。
そして、生成したデータを、他のProduction Nodeや、アプリケーションなど、様々なオブジェクトに提供します。
しかし、中には、他の低レベルデータを生成するProduction Nodeに依存し、その低レベルデータを分析してアプリケーションにデータを提供するProduction Nodeも存在します。
例
３次元空間内の人間の動きをトラッキングするアプリケーションを考えてみましょう。
このアプリケーションは、人体データを提供してくれるProduction Nodeが必要です。
このようなProduction Nodeを「user generator」と呼びます。
user generatorは、元データを「depth generator」から取得します。
depth generatorはセンサーによって実装されたProduction Nodeで、深度センサーから生のセンサーデータを取得し、（たとえば、毎秒Xフレームのストリームデータです。）そして、深度マップとして出力します。
より上位のレベルの例をいくつか見てみましょう
１．1ユーザーの手の位置の取得
ユーザーの手のひらの中心（よく、ハンドポイントと呼ばれる点です）や、指先を出力します。
２．空間内の人体の取得
人体の間接の現在の位置と向きを出力します。
（よく、人体データ（=body data)と呼ばれます。）
３．手のジェスチャーの認識
出力は、特定のジェスチャーが発生した、というアプリケーションへのメッセージになります。
Production Node型
Production Nodeは型をもっており、次のいずれかのカテゴリに分類されます。
１．Sensor-Related Production Nodes
２．Middleware-Related Production Nodes
現在、OpenNIでは以下のProduction Node型をサポートします。
１．Sensor-Related Production Nodes
・Device
物理デバイスを表現するProduction Node
（たとえば、深度センサーやＲＧＢカメラ）
この Production Nodeの目的は、デバイスの設定を行うことです。
・Depth Generator
深度マップを生成するProduction Node。
OpenNI準拠の３Ｄカメラによって実装されます。
・Image Generator
カラーイメージマップを生成するProduction Node。
OpenNI準拠のカラーセンサーによって実装されます。
・IR Generaotr
IRイメージマップを生成するProduction Node。
OpenNI準拠のIRセンサーによって実装されます。
・Audio Generator
音声ストリームを生成するProduction Node。
OpenNI準拠のオーディオデバイスによって実装されます。
２．Middleware-Related Production Nodes
・Gestures Alert Generator
あるジェスチャーが行われた場合に、アプリケーションへのコールバックを生成します。
・Scene Analyzer
空間の分析を行い、背景と対象物を分離し、空間内の人体を認識し、床平面を検出します。
Scene Analyzerの主な出力は、ラベル付けされた深度マップです。
ラベルはピクセル単位に付けられ、そのピクセルが人体なのか、背景なのかを表します。
・Hand Point Generator
手の検出とトラッキングを行います。
このProduction Nodeは、ハンドポイント（手のひら）を検出した際のコールバックを生成します。
また、トラッキングが有効な場合は、その位置が変化した際のコールバックを生成します。
・User Generator
空間内の人体（全体または一部）を検出します。
レコーディングのために、以下のProduction Nodeがサポートされています。
・Recorder
データの保存を実装します。
・Player
保存されたデータを読み込み、再生します。
・Codec
保存の際の圧縮や解凍に使用します。
OpenNIの階層
下の図は、OpenNIのコンセプトを階層で表したものです。
１．センサーモジュール
３Ｄセンサー
ＲＧＢカメラ
ＩＲカメラ
マイクロフォン
２．ミドルウェア
・人体認識ミドルウェア：センサーデータを分析し、人間の体に対応するデータを生成するプログラムです。
・手認識ミドルウェア：センサーデータを分析し、人間の手の位置などを生成するプログラムです。
・ジェスチャー認識ミドルウェア：あらかじめ定義されたジェスチャーを認識し、ジェスチャーを認識した場合にアプリケーションに通知するプログラムです。
・空間認識ミドルウェア：画像データを分析に、以下のような情報を生成するプログラムです。
１．背景と対象物の分離
２．床平面上の座標
３．空間中の物体の識別
例
下の図は、OpenNIに５つのモジュールが登録された様子を表します。
うち２つのモジュールは、３Ｄセンサーです。
残りの３つのモジュールは認識ミドルウェアで、２つは人間の全身データを生成し、もう１つは手の位置をトラッキングします。
最上位：NIアプリケーションを指します。
中間：OpenNIそのものです。センサーと、センサーからのデータを分析する認識ミドルウェアの間のインターフェースを定義します。
最下層：視覚および聴覚デバイスを指します。
モジュール
OpenINは、物理デバイスと、認識ミドルウェア間のインターフェースを定義します。
APIは、OpenNIフレームワークに、たくさんのコンポーネントを登録することが可能です。
それらのコンポーネントは「モジュール」と呼ばれ、センサーデータを生成したり、処理したりします。
必要なデバイスを選んだり、必要な認識ミドルウェアを選ぶのは簡単で柔軟性があります。
モジュールには現在、以下の２種類があります。
１．センサーモジュール
３Ｄセンサー
ＲＧＢカメラ
ＩＲカメラ
マイクロフォン
２．ミドルウェア
・人体認識ミドルウェア：センサーデータを分析し、人間の体に対応するデータを生成するプログラムです。
・手認識ミドルウェア：センサーデータを分析し、人間の手の位置などを生成するプログラムです。
・ジェスチャー認識ミドルウェア：あらかじめ定義されたジェスチャーを認識し、ジェスチャーを認識した場合にアプリケーションに通知するプログラムです。
・空間認識ミドルウェア：画像データを分析に、以下のような情報を生成するプログラムです。
１．背景と対象物の分離
２．床平面上の座標
３．空間中の物体の識別
例
下の図は、OpenNIに５つのモジュールが登録された様子を表します。
うち２つのモジュールは、３Ｄセンサーです。
残りの３つのモジュールは認識ミドルウェアで、２つは人間の全身データを生成し、もう１つは手の位置をトラッキングします。
プログラムやセンサーをOpenNI準拠とするためには、いくつかのインターフェイスを実装する必要があります。
概要
１．NIについて
NI(=Natural Interaction)とは、主に視覚や聴覚などの人間の感覚を利用したコンピュータの操作を指します。
マウスやキーボードに代わって、視覚デバイスや聴覚デバイスをコンピュータ操作に用いるという発想です。
すでに、以下のようにNIは利用されています。
・音声認識技術。コンピュータへの命令を、人間の声によって与えることができます。
・ジェスチャー認識。あらかじめジェスチャーを決めておくことで、ジェスチャーをコンピュータへの命令とすることができます。たとえば、リビングに置いた家電製品を、手の動きで操作することができます。
・人体トラッキング。人の動きを認識することは、ゲームに利用されています。
２．OpenNIについて
OpenNI (Open Natural Interaction)は、NIのための、言語、プラットフォームに依存しないフレームワークです。
OpenNIは、NIを利用したアプリケーションを書くためのAPIを提供します。
OpenNIの目的は、以下の両者が通信するための、標準的なAPIを定義することです。
・センサー（視覚および聴覚）
・視覚および聴覚の認識ミドルウェア
※「認識ミドルウェア」とは、センサーからのデータを元に、そのデータを解析して、意味を解釈するプログラムのことを指します。
たとえば、画像データを受け取って、手のひらを検出し、その位置を返すようなプログラムです。
OpenNIは、物理的なセンサーデバイスや認識ミドルウェアの実装そのものではなく、
アプリケーションが、個々のセンサーデバイスや認識ミドルウェアを部品として利用するための標準的な規格を定めるものです。
OpenNIは、センサーによって実装されたAPIと、認識ミドルウェアによって実装されたAPIを提供します。
センサーと認識ミドルウェアの間の依存性を取り除くことによって、OpenNIは、アプリケーションを異なる認識ミドルウェア上で動作させるための作業を不要にし、移植を容易にします。
(“write once, deploy everywhere”)
OpenNIは、物理的なセンサーデバイスや認識ミドルウェアの実装そのものではなく、
アプリケーションが、個々のセンサーデバイスや認識ミドルウェアを部品として利用するための標準的な規格を定めるものです。
OpenNIは、センサーによって実装されたAPIと、認識ミドルウェアによって実装されたAPIを提供します。
センサーと認識ミドルウェアの間の依存性を取り除くことによって、OpenNIは、アプリケーションを異なる認識ミドルウェア上で動作させるための作業を不要にし、移植を容易にします。
(“write once, deploy everywhere”)
また、認識ミドルウェアの開発者は、最上位データを処理するアルゴリズムを書けばよく、どんなセンサーがそのデータを生成したかを意識する必要はありません。
さらに、センサー製造者には、OpenNI準拠のアプリケーションを動かすためのセンサーを作るための仕様を提供します。
OpenNI APIは、センサーデータから計算されたデータを用いて、3Dトラッキングが可能です。
アプリケーションは、センサーやミドルウェアの提供者について意識する必要はありません。
OpenNIは、オープンソースのAPIです。
登録:
投稿 (Atom)