JP2013535717A - 骨格関節認識および追跡システム - Google Patents

Abstract

ＮＵＩシステムによってユーザーの骨格関節を認識および追跡するシステムならびに方法、ならびに、例えば、ユーザーの上半身というような、一部の骨格関節のみを認識および追跡するシステムならびに方法を開示する。本システムは、肢識別エンジンを含むことができる。この肢識別エンジンは、種々の方法を用いて、場面の中にいる１人以上のユーザーの身体部分の位置を評価し、特定し、追跡する。例では、視野を更に小さいゾーンに区分し、一度に１つのゾーンに焦点を絞ることによって、処理効率の向上を達成することができる。更に、各ゾーンは、それ自体の１組の既定のジェスチャーを有することができ、これらのジェスチャーを認識する。
【選択図】図３

Description

[0001] 従来では、コンピューター・ゲームやマルチメディア・アプリケーションというような計算アプリケーションは、コントローラー、リモコン、キーボード、マウス等を用いて、ユーザーがアプリケーションのゲーム・キャラクタまたはその他の様相(aspect)を操作することを可能にしていた。最近になって、コンピューター・ゲームおよびマルチメディア・アプリケーションは、カメラやソフトウェア・ジェスチャー認識エンジンを用いて、自然ユーザー・インターフェース（「ＮＵＩ」）を提供し始めている。ＮＵＩによって、生の関節データーおよびユーザー・ジェスチャーを検出し、解釈し、アプリケーションのゲーム・キャラクタやその他の様相を制御するために用いる。

[0002] ＮＵＩアプリケーションは、通例、ユーザーの関節の全てからの動き(motion)、および視野全体からの背景物体を追跡する。しかしながら、ときとして、ユーザーが彼または彼女の身体の一部のみを用いてＮＵＩアプリケーションと対話処理していることもあり得る。例えば、ユーザーが、彼または彼女の脚部を用いずに、椅子または車椅子に座っている場合がある。これらの場合であっても、ＮＵＩアプリケーションはユーザーの下半身を追跡し続ける。

[0003] 本明細書に開示するのは、ＮＵＩシステムによってユーザーの骨格関節を認識および追跡するシステムならびに方法であり、実施形態では、例えば、ユーザーの上半身というような、一部の骨格関節のみを認識および追跡するシステムならびに方法である。本システムは、画像キャプチャー・デバイスから視野のフレーム・データーを受け取る肢識別エンジン(limb identification engine)を含むことができる。この肢識別エンジンは、次に、原型(Exemplar)および重心(centroid)生成、マグネティズム(magnetism)、および種々の採点検査(scored test)を含む種々の方法を用いて、場面の中にいる１人以上のユーザーの頭部、肩、およびその他の身体部分の位置を評価し、特定し、追跡する。

[0004] 実施形態では、本システムは、視野内にいる１人以上のプレーヤー（本明細書ではユーザーとも呼ぶ）のカラー画像および／または深度画像を取り込むキャプチャー・デバイスを含む。１人以上のプレーヤーが動いているカラー画像および／または深度画像、あるいは連続画像(image sequence)が与えられると、本技術のような人間追跡システムの共通の最終目標は、画像（１つまたは複数）を分析し、人間の身体部分の位置を含んで、場面の中に人間がいるか否か確実に(robustly)判断することである。

[0005] このような問題を解決するシステムは、２つの下位問題(sub-problem)に分類することができる。即ち、多数の候補身体部分位置を特定すること、次いでこれらの折り合いをつけて(reconcile)全体的または部分的な骨格を求めることである。肢識別エンジンの実施形態は、多数の候補身体部分位置を特定する身体部分提案システムと、候補身体部分の折り合いをつけて全体的または部分的骨格を求める骨格解明システムとを含む。

[0006] 身体部分提案システムは、画像（１つまたは複数）を消費して、場面全域において１組の候補身体部分位置（身体部分毎に潜在的に多数の候補があり得る）を生成することができる。これらの身体部分提案システムは、ステートレスまたはステートフルとすることができる。ステートレス・システムとは、以前の状態（以前のフレーム）を参照せずに候補身体部分位置を生成するものである。ステートフル・システムとは、以前の状態または以前のフレームを参照して候補身体部分位置を生成するものである。ステートレス身体部分提案システムの一例には、候補身体部分を特定する原型および重心が含まれる。更に、本技術は、多くの候補身体部分を識別するためにステートフル・システムも開示する。本明細書では、これをマグネティズム(magnetism)と呼ぶ。身体部分提案システムは、性質上、多くの擬陽性を生成する可能性がある。したがって、肢識別エンジンは、更に、候補身体部分の折り合いをつけて、視野において正しく識別された身体および／または身体部分から擬陽性を区別するために骨格解明システムも含む。

[0007] 骨格解明システムは、潜在的に多くの擬陽性を含む可能性がある、１つ以上の身体部分提案システムからの身体部分提案を消費し、そのデーターの折り合いをつけて確実な骨格全体を求める。一実施形態では、この骨格解明システムは、種々の方法で身体部分提案を繋ぎ合わせて多数の（部分的または全体的）骨格仮説を生成することによって動作する。計算の複雑さを減らすために、骨格のある部分（頭部および肩のような部分）を最初に解明し、その後他の部分（腕のような部分）を解明するとよい。次いで、これらの仮説を種々の方法で採点し、その得点およびその他の情報を用いて、最良の仮説を選択し、折り合いをつけてプレーヤーが実際にいる場所を求める(reconcile)。

[0008] 仮説を採点するには、多くのロバストなコスト関数を用いる。身体部分提案および骨格仮説がコスト関数において高い得点を得る程、正しく識別された身体部分である可能性が高くなる。これらのコスト関数の一部は、これらが最初に上位においていくつかの骨格仮説を除去するために実行することができるということから、上位である。本システムによるこのような検査は、所与の骨格仮説が力学的に有効である（即ち、可能である）か否かを含む。本システムによる他の上位検査には、関節回転検査が含まれる。この検査は、骨格仮説における１つ以上の関節の回転が、予期される身体部分に対する関節回転限界を超えたか否かについて検査する。

[0009] 他のコスト関数には、もっと低レベルのものもあり、全ての骨格仮説にわたって、骨格仮説内の各身体部分提案について実行する。本システムによるこのようなコスト関数の１つは、トレース(trace)および突出(saliency)検査である。これは、１つ以上の身体部分提案内におけるトレース・サンプルおよび１つ以上の身体部分提案外の突出サンプルの深度値を試験する。期待通りの深度値を有するサンプルには、この検査の下では、より高い得点が与えられる。本システムによる更に他のコスト関数は、画素動き検出検査である。これは、身体部分（手のような身体部分）が動いているか否か判断するために検査を行う。仮説の主要エリアにおいてｘ、ｙ、および／またはｚ方向に検出された画素の動きがあると、仮説の得点を高くすることができる。

[0010] 加えて、骨格解明システムと併せて、非常にロバストで精細な手の位置を求める、手を厳格に求める技法(hand refinement technique)についても記載する。
[0011] 本技術の更に他の実施形態では、視野をもっと小さなゾーンに区分し、１度に１つのゾーンに焦点を絞ることによって、更に高い処理効率を達成することができる。更に、各ゾーンは、それ自体の１組の既定ジェスチャーを有することもできる。このジェスチャーは、ゾーン毎に認識され、変化する。これによって、１つのゾーン内で矛盾する(conflicting)ジェスチャーを受け取って処理する可能性を回避し、更に処理を簡略化し処理速度を向上させる。

[0012] 一例では、本技術は、ジェスチャー認識方法に関する。この方法は、ａ）場面の中にいるユーザーから位置情報を受け取るステップであって、ユーザーが第１身体部分および第２身体部分を有する、ステップと、ｂ）第１身体部分からジェスチャーを認識するステップと、ｃ）第２身体部分によって行われたジェスチャーを無視するステップと、ｄ）前記ステップｂ）において認識した第１身体部分からのジェスチャーと関連付けられた動作(action)を実行するステップとを含む。

[0013] 他の例では、本技術は、ユーザーの身体部分を認識し追跡する方法に関する。この方法は、ａ）場面の中にいるユーザーから位置情報を受け取るステップと、ｂ）前記ステップａ）において受け取った位置情報から、ユーザーの第１グループの関節を特定するステップと、ｃ）ユーザーの第２グループの関節を無視するステップと、ｅ）前記ステップｄ）において特定した関節の位置に基づいて、動作を実行するステップとを含む。

[0014] 本技術の他の例は、少なくとも１つの麻痺した身体部分の使用が少なくとも制限されるユーザーの身体部分を認識し追跡する方法を実行するように、プロセッサーをプログラミングすることができるコンピューター読み取り可能記憶媒体に関する。この方法は、ａ）少なくとも1つの麻痺した身体部分の識別の指示を、ユーザーから受け取るステップと、ｂ）ユーザーの第１グループの関節を特定するステップであって、関節が少なくとも１つの麻痺した身体部分の中に含まれない、ステップと、ｃ）第１グループの関節において、関節の位置を特定するステップと、ｄ）前記ステップｃ）において特定した関節の位置に基づいて、動作を実行するステップとを含む。

[0015] この摘要は、詳細な説明の章において以下で更に説明する概念から選択したものを簡略化された形式で紹介するために、設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を判断する際に補助として使用されることを意図するのでもない。更に、特許請求する主題は、本開示のいずれの部分に記されているいずれの欠点を解決する実施態様にも、全ての欠点を解決する実施態様にも限定されるのでもない。

図１Ａは、ターゲット認識、分析、および追跡システムの一実施形態例を示す。 図１Ｂは、ターゲット認識、分析、および追跡システムの他の一実施形態例を示す。 図１Ｃは、ターゲット認識、分析、および追跡システムの他の一実施形態例を示す。 図２は、ターゲット認識、分析、および追跡システムにおいて用いることができるキャプチャー・デバイスの一実施形態例を示す。 図３は、本技術の実施形態にしたがって、自然ユーザー・インターフェースを通じて上半身にある関節をモデリングし追跡するシステムの上位フローチャートである。 図４Ａは、本技術の実施形態にしたがって、自然ユーザー・インターフェースを通じて上半身にある関節をモデリングおよび追跡するシステムの詳細なフローチャートである。 図４Ｂは、本技術の実施形態にしたがって、自然ユーザー・インターフェースを通じて上半身にある関節をモデリングおよび追跡するシステムの詳細なフローチャートである。 図５Ａは、本技術の実施形態にしたがって、自然ユーザー・インターフェースを通じて、上半身にある関節をモデリングおよび追跡するために頭部三角形および肩三角形を生成する図４Ａのステップ３０８のフローチャートである。 図５Ｂは、本技術の実施形態にしたがって、自然ユーザー・インターフェースを通じて、上半身にある関節をモデリングおよび追跡するために頭部三角形および肩三角形を生成する図４Ａのステップ３０８のフローチャートである。 図６は、図５において生成した頭部三角形および肩三角形を採点する際に用いられる要因を示す、図５Ａのステップ３６８のフローチャートである。 図７は、図４Ａ、図４Ｂにおいて手の位置を評価する際に用いられる採点要因を示す、図４Ａのステップ３１２のフローチャートである。 図８は、図４Ａ、図４Ｂにおいて肘の位置を評価する際に用いられる採点要因を示す、図４Ａのステップ３１８のフローチャートである。 図９は、本技術の実施形態において生成したユーザーおよび頭部三角形の図である。 図１０は、ユーザー、ならびに頭部および肩に対するトレース・サンプリング点および突出サンプリング点の図である。 図１１は、ユーザー、ならびにユーザーの上腕、下腕(lower arm)、および手に対するトレース・サンプリング点および突出サンプリング点の図である。 図１２は、ユーザーの頭部、肩、肘、手首、および手に対して、本技術にしたがって戻された骨格関節位置を示す。 図１３Ａおよび図１３Ｂは、本技術の実施形態にしたがって、視野内において画素をサンプリングするゾーン基本システムの実施形態を示す。 図１４は、ジェスチャーを認識するジェスチャー認識エンジンを示すブロック図である。 図１５は、図１４のジェスチャー認識エンジンの動作のフローチャートである。 図１６は、ユーザーの実世界における手の動きおよびジェスチャーによって、画面上のアバターの脚部の動きをユーザーが制御する方法のフローチャートである。 図１７Ａは、ターゲット認識、分析、および追跡システムにおいて１つ以上のジェスチャーを解釈するために用いることができる計算環境の一実施形態例を示す。 図１７Ｂは、ターゲット認識、分析、および追跡システムにおいて１つ以上のジェスチャーを解釈するために用いることができる計算環境の他の一実施形態例を示す。

[0036] 本技術の実施形態について、これより図１から図１７Ｂを参照しながら説明する。これらの図は、総じて、ＮＵＩシステムによってユーザーの骨格関節を認識および追跡するシステムならびに方法に関し、実施形態では、例えば、ユーザーの上半身のような、一部の骨格関節のみを認識および追跡するシステムならびに方法に関する。本システムは、画像キャプチャー・デバイスから視野（ＦＯＶ）のフレーム・データーを受け取る肢識別エンジンを含むことができる。一般に、この肢識別エンジンの実施形態は、多数の候補身体部分位置を特定する身体部分提案システムと、これらの候補身体部分の折り合いをつけて全体的または部分的骨格を求める骨格解明システムとを含む。

[0037] 次いで、身体部分提案システムは、原型(Exemplar)および重心生成方法を用いて、何らかの信頼性レベルを関連付けて、ＦＯＶ内部において身体部分を特定することができる。また、本システムはマグネティズムを利用することもできる。マグネティズムは、直前のフレームにおいて位置が分かっていた身体部分の新たな位置を、新たなフレームについての画像データー内にある近隣の造作(feature)に身体部分を「スナップする」ことによって、推定する。原型および重心生成方法については、"Multiple Centroid Condensation of Probability Distribution Clouds"（確率分布クラウドの多数の重心凝縮）と題する米国特許出願第１２／７７０，３９４号において、更に詳細に説明されている。この特許出願をここで引用したことにより、その内容全体が本願にも含まれるものとする。しかしながら、原型および重心生成は、候補身体部分を特定するために用いることができる１つの方法に過ぎないことは言うまでもない。画像を分析し種々の身体部分について種々の候補関節位置を出力することができる（確率を用いてまたは用いないで）他のアルゴリズムも、原型および／または重心の代わりに、またはこれに加えて用いることができる。

[0038] 原型および重心生成技法を用いる場合、これらの技法は候補身体部分の位置を特定する。特定された位置は、正しいかもしれないし、正しくないかもしれない。本システムの１つの目標は、候補身体部分の位置を一緒に融合して(fuse)、人が場面の中のどこにいるか、そしてどのような姿勢を彼らがとっているかについてコヒーレントなイメージ(picture)を得ることである。実施形態では、肢識別エンジンは、更に、この目的のために骨格解明システムも含むことができる。

[0039] 実施形態では、骨格解明システムは、頭部、肩、肘、手首、および手のような上半身の関節を、取り込まれたデーターのフレーム毎に識別することができる。このような実施形態では、肢識別エンジンは、原型および種々の採点サブルーチンを用いて、ユーザーの肩および頭部に対応する重心集合体を特定することができる。これらの重心集合体を、本明細書では、頭部三角形と呼ぶ。マグネティズム、原型からの重心、またはその他の成分を含むがこれらには限定されない種々のソースからの手の提案(hand proposal)を用いて、肢識別エンジンの骨格解明システムは、更に、ＦＯＶ内にいるユーザーの手について、潜在的に可能な手の位置、または手の提案を特定することができる。骨格解明システムは、次に、手の提案毎に多数の肘の位置を評価することができる。これらの動作から、肢識別エンジンの骨格解明システムは、フレーム毎に、各プレーヤーについて頭部、肩、および腕の位置を特定することができる。

[0040] ユーザーの身体関節の一部(fraction)のみに焦点を絞ることによって、本システムは、全ての身体関節を測定するシステムにおけるよりも、効率的に画像データーを処理することができる。更に処理効率を高めるために、画像データーを取り込むキャプチャー・デバイスが、視野を更に小さなゾーンに区分することもできる。このような実施形態では、キャプチャー・デバイスは、１つのゾーンだけに焦点を絞り、連続するフレームにおいてこれらの小さなゾーンを一巡することができる。選択した身体関節またはゾーンに焦点を絞ることには、処理効率を超えた他の利点もあると思われる。特定の１組の関節またはゾーンに焦点を絞ることは、矛盾するジェスチャーを受け取って処理する可能性を回避するためにも行うことができる。

[0041] 一旦選択した関節について関節位置を出力したなら、この情報は種々の目的に用いることができる。これは、ジェスチャー認識（取り込んだ身体部分によって行われるジェスチャー）に用いることができるだけでなく、ＮＵＩアプリケーションによって提示される仮想物体との対話処理にも用いることができる。更に他の実施形態では、例えば、ユーザーが彼らの脚部を用いない場合、ユーザーは「脚部制御モード」でＮＵＩアプリケーションと対話処理することができる。この場合、ユーザーの手の動きが、画面上のキャラクタの脚部の動きを制御するための画像データーに変換される。これらの実施形態については、以下で更に詳しく説明する。

[0042] 最初に図１Ａから図２を参照すると、本技術を実現するハードウェアは、ターゲット認識、分析、および追跡システム１０を含む。このシステム１０は、ユーザー１８のような人間のターゲットを認識し、分析し、そして追跡するために用いることができる。ターゲット認識、分析、および追跡システム１０の実施形態は、ゲーミング・アプリケーションまたは他のアプリケーションを実行する計算環境１２を含む。計算環境１２は、ゲーミング・アプリケーションおよびゲーミング以外のアプリケーションというようなアプリケーションを実行するために用いることができるように、計算環境１２は、ハードウェア・コンポーネントおよび／またはソフトウェア・コンポーネントを含むことができる。一実施形態では、計算環境１２は、標準的なプロセッサー、特殊プロセッサー、マイクロプロセッサー等というようなプロセッサーを含むことができる。このプロセッサーは、本明細書において記載するプロセスを実行するためにプロセッサー読み取り可能記憶デバイス上に格納されている命令を実行することができる。

[0043] システム１０は、更に、キャプチャー・デバイス２０も含む。キャプチャー・デバイス２０は、このキャプチャー・デバイスが検知する１つ以上のユーザーおよび／または物体に関する画像データーおよびオーディオ・データーを取り込む。実施形態では、キャプチャー・デバイス２０は、部分的または全体的な身体の動き、１人以上のユーザーのジェスチャーおよび音声に関する情報を取り込むために用いることができる。この情報は、計算環境が受け取り、ゲーミング・アプリケーションまたは他のアプリケーションの様相(aspect)をレンダリングする、これと対話処理する、および／またはこれを制御するために用いられる。計算環境１２およびキャプチャー・デバイス２０の例については、以下で更に詳しく説明する。

[0044] ターゲット認識、分析、および追跡システム１０の実施形態は、ディスプレイ１４を有するオーディオ／ビジュアル（Ａ／Ｖ）デバイス１６に接続することができる。デバイス１６は、例えば、テレビジョン、モニター、高品位テレビジョン（ＨＤＴＶ）等とすればよく、ゲームまたはアプリケーションの映像および／または音声をユーザーに供給することができる。例えば、計算環境１２は、グラフィクス・カードのようなビデオ・アダプター、および／またはサウンド・カードのようなオーディオ・アダプターを含むことができる。これらのアダプターは、ゲームまたは他のアプリケーションに付随するオーディオ／ビデオ信号を供給することができる。オーディオ／ビジュアル・デバイス１６は、オーディオ／ビジュアル信号を計算環境１２から受け取り、次いでこのオーディオ／ビジュアル信号と関連のあるゲームまたはアプリケーションの映像をユーザー１８に出力することができる。一実施形態によれば、オーディオ／ビジュアル・デバイス１６は、例えば、S-Videoケーブル、同軸ケーブル、ＨＤＭＩケーブル、ＤＶＩケーブル、ＶＧＡケーブル、コンポーネント・ビデオ・ケーブル等によって、計算環境１２に接続することができる。

[0045] 実施形態では、計算環境１２、Ａ／Ｖデバイス１６、およびキャプチャー・デバイス２０は、協同してアバターまたは画面上のキャラクタ１９をディスプレイ１４上にレンダリングすることができる。実施形態では、アバター１９は、実世界空間におけるユーザー１８の動きを真似するので、ユーザー１８は、ディスプレイ１４上におけるアバター１９の動きおよび行為(action)を制御する動きおよびジェスチャーを行うことができる。以下で説明するが、本技術の１つの態様では、ユーザーが１組の肢部、例えば、彼らの腕を動かして、画面上のアバター１９の異なる肢部、例えば、脚部の動きを制御することを可能にする。

[0046] 図１Ａでは、キャプチャー・デバイス２０はＮＵＩシステムにおいて用いられ、例えば、ユーザー１８は、ディスプレイ１４上に提示される種々のメニュー選択肢を有するユーザー・インターフェース２１全体にわたってスクロールし、ユーザー・インターフェース２１を制御する。図１Ａにおいて、計算環境１２およびキャプチャー・デバイス２０は、ユーザーの上半身の動きおよびジェスチャーを認識し分析するために用いることができ、このような動きおよびジェスチャーは、ユーザー・インターフェースのための制御として解釈することができる。このような実施形態では、以下で説明するように、ユーザーの上半身のみを追跡してその動きを求めることができる。

[0047] 図１Ｂは、ユーザー１８が椅子２３に座りながらテニス・ゲーミング・アプリケーションをプレーしている、別の実施形態を示す。図１Ｂは、同様の実施形態を示すが、この実施形態では、ユーザーは彼の四肢の全てが使えない身体障害者(differently-abled)であってもよい。図１Ｂでは、ユーザーは車椅子に座っており、彼の脚部を使わない。図１Ｂおよび図１Ｃでは、計算環境１２およびキャプチャー・デバイス２０は、ユーザーの上半身の動きおよびジェスチャーを認識しそして分析するために用いることができ、このような動きおよびジェスチャーは、ゲーム空間におけるアバター１９の行為に影響を及ぼすゲーム制御または行為として解釈することができる。

[0048] 図１Ａ〜図１Ｃの実施形態は、計算環境１２において実行することができる多くの異なるアプリケーションの内の２つであり、計算環境１２において実行するアプリケーションは、種々のその他のゲーミング・アプリケーションおよびゲーミング以外のアプリケーションとすることができる。

[0049] 図１Ａ〜図１Ｃは、椅子および植物のような静止した背景物体２３を含む。これらは、場面（即ち、キャプチャー・デバイス２０によって取り込まれるエリア）内部にある物体であるが、フレーム毎に変化しない。図示する椅子および植物に加えて、静止物体は、キャプチャー・デバイス２０における撮像カメラによって撮影される物体であればいずれでもよい。この場面における追加の静止物体には、あらゆる壁、床、天井、窓、扉、壁飾り等を含むことができる。

[0050] システム１０およびそのコンポーネントに相応しい例が、以下の同時係属中の特許出願において見いだせる。これらの特許出願の全ては、ここで引用したことによって、具体的に本願にも含まれるものとする。２００９年５月２９日に出願され"Environment And/Or Target Segmentation"（環境および／またはターゲット区分）と題する米国特許出願第１２／４７５，０９４号、２００９年７月２９日に出願され"Auto Generating a Visual Representation"（視覚表現の自動生成）と題する米国特許出願第１２／５１１,８５０号、２００９年５月２９日に出願され"Gesture Tool"（ジェスチャー・ツール）と題する米国特許出願第１２／４７４，６５５号、２００９年１０月２1日に出願され"Pose Tracking Pipeline"（姿勢追跡パイプライン）と題する米国特許出願第１２／６０３，４３７号、２００９年５月２９日に出願され"Device for Identifying and Tracking Multiple Humans Over Time"（ときの経過と共に複数の人間を識別および追跡するデバイス）と題する米国特許出願第１２／４７５，３０８号、 ２００９年１０月７日に出願され"Human Tracking System"（人間追跡システム）と題する米国特許出願第１２／５７５,３８８号、 ２００９年４月１３日に出願され"Gesture Recognizer System Architecture"（ジェスチャー認識システムのアーキテクチャー）と題する米国特許出願第１２／４２２，６６１号、２００９年２月２３日に出願され"Standard Gestures"（標準的なジェスチャー）と題する米国特許第１２／３９１，１５０号、 ２００９年５月２９日に出願され"Gesture Tool"（ジェスチャー・ツール）と題する米国特許出願第１２／４７４，６５５号。

[0051] 図２は、ターゲット認識、分析、および追跡システム１０において用いることができるキャプチャー・デバイス２０の実施形態例を示す。一実施形態例では、キャプチャー・デバイス２０は、深度値を含むことができる深度画像を有するビデオを、例えば、飛行時間、構造化光、立体画像等を含むいずれかの適した技法によって、取り込むように構成することができる。一実施形態によれば、キャプチャー・デバイス２０は、キャプチャー・デバイス２０は、計算された深度情報を「Ｚレイヤー」、即ち、深度カメラからその見通し線に沿って延びるＺ軸に対して垂直であることができるレイヤーに編成することができる。ＸおよびＹ軸は、Ｚ軸に対して垂直であると定義することができる。Ｙ軸は、垂直であり、Ｘ軸は水平であるとよい。Ｘ、Ｙ、およびＺ軸は、併せて、キャプチャー・デバイス２０によって取り込まれる３−Ｄ実世界空間を定義する。

[0052] 図２に示すように、キャプチャー・デバイス２０は撮像カメラ・コンポーネント２２を含むことができる。一実施形態例によれば、撮像カメラ・コンポーネント２２は、場面の深度画像を取り込むことができる深度カメラとすることができる。深度画像は、取り込まれた場面の二次元（２−Ｄ）画素エリアを含むことができ、この２−Ｄ画素エリアにおける各画素は、カメラから取り込まれた場面における物体の、例えば、センチメートル、ミリメートル等の単位とした、長さまたは距離のような深度値を表すことができる。

[0053] 図２に示すように、一実施形態例によれば、撮像カメラ・コンポーネント２２は、場面の深度画像を取り込むために用いることができるＩＲ発光コンポーネント２４、三次元（３Ｄ）カメラ２６、およびＲＧＢカメラ２８を含むことができる。例えば、飛行時間分析では、キャプチャー・デバイス２０のＩＲ発光コンポーネント２４は、場面に向けて赤外線光を放出することができ、次いでセンサー（図示せず）を用いて、その場面の中にある１つ以上のターゲットおよび物体の表面からの後方散乱光を、例えば、３Ｄカメラ２６および／またはＲＧＢカメラ２８を用いて検出することができる。

[0054] 実施形態の中には、パルス状赤外線光を用いて、発信光パルスと対応する入射光パルスとの間の時間を測定し、キャプチャー・デバイス２０から場面内にあるターゲットまたは物体上における特定の場所までの物理的距離を判定するために、この時間を用いることができるようにするとよい場合がある。加えて、他の実施形態例では、発信光波の位相を着信光波の位相と比較して、位相ずれを判定することもできる。次いで、位相ずれを用いて、キャプチャー・デバイス２０からターゲットまたは物体上の特定の場所までの物理的距離を判定することができる。

[0055] 他の実施形態例によれば、例えば、散乱光パルス撮像(shuttered light pulse imaging)を含む種々の技法によって、経時的な光の反射ビームの強度を分析することによって、キャプチャー・デバイス２０からターゲットまたは物体上の特定の場所までの物理的距離を間接的に判定するために、飛行時間分析を用いることもできる。

[0056] 他の一実施形態例では、キャプチャー・デバイス２０は、構造化光を用いて深度情報を取り込むことができる。このような分析では、パターン光（即ち、格子パターン、縞パターンのような既知のパターンとして表示される光）を、例えば、ＩＲ発光コンポーネント２４によって場面に向けて投射する。場面における１つ以上のターゲットまたは物体の表面に衝突したときに、パターンが、それに応答して、変形することができる。このようなパターンの変形を、例えば、３Ｄカメラ２６および／またはＲＧＢカメラ２８によって取り込むことができ、次いで分析して、キャプチャー・デバイス２０からターゲットまたは物体上における特定の場所までの物理的距離を判定することができる。

[0057] 他の実施形態によれば、キャプチャー・デバイス２０は、２つ以上の物理的に分離されたカメラを含むことができ、これらが異なる角度からの場面を捕らえて、視覚的な立体像を得て、これを解明することによって深度情報を生成することができる。他の実施形態例では、キャプチャー・デバイス２０は、ポイント・クラウド・データー(point cloud data)およびターゲット・ディジタル化技法を使用して、ユーザーの特徴を検出することもできる。

[0058] 更に、キャプチャー・デバイス２０は、マイクロフォン３０を含むこともできる。マイクロフォン３０は、音響を受けて電気信号に変換する変換器またはセンサー（図示せず）を含むことができる。一実施形態によれば、マイクロフォン３０は、ターゲット認識、分析、および追跡システム１０においてキャプチャー・デバイス２０と計算環境１２との間におけるフィードバックを減らすために使用することができる。加えて、マイクロフォン３０は、計算環境１２によって実行することができる、ゲーム・アプリケーション、ゲーム以外のアプリケーション等のようなアプリケーションを制御するために、ユーザーが供給することもできるオーディオ信号を受け取るために用いることもできる。

[0059] 一実施形態例では、キャプチャー・デバイス２０は、更に、撮像カメラ・コンポーネント２２と動作的に通信することができるプロセッサー３２も含むことができる。プロセッサー３２は、命令を実行することができる標準的なプロセッサー、特殊プロセッサー、マイクロプロセッサー等を含むことができる。これらの命令には、深度画像を受け取り、この深度画像に適したターゲットが含まれ得るか否か判定を行い、適したターゲットをそのターゲットの骨格表現またはモデルに変換する命令、またはあらゆる他の適した命令を含むことができる。

[0060] キャプチャー・デバイス２０は、更に、メモリー・コンポーネント３４も含むことができる。メモリー・コンポーネント３４は、プロセッサー３２によって実行することができる命令、３ＤカメラまたはＲＧＢカメラによって取り込まれた画像または画像のフレーム、あるいはあらゆる他の適した情報、画像等を格納することができる。一実施形態例によれば、メモリー・コンポーネント３４は、ランダム・アクセス・メモリー（ＲＡＭ）、リード・オンリー・メモリー（ＲＯＭ）、キャッシュ、フラッシュ・メモリー、ハード・ディスク、または他の適した記憶コンポーネントであればいずれでも含むことができる。図２に示すように、一実施形態では、メモリー・コンポーネント３４は、画像キャプチャー・コンポーネント２２およびプロセッサー３２と通信することができる別個のコンポーネントであってもよい。他の実施形態によれば、メモリー・コンポーネント３４は、プロセッサー３２および／または画像キャプチャー・コンポーネント２２に統合されてもよい。

[0061] 図２に示すように、キャプチャー・デバイス２０は、通信リンク３６を介して、計算環境１２と通信することができる。通信リンク３６は、例えば、ＵＳＢ接続、Firewire接続、イーサネット（登録商標）・ケーブル接続等を含む有線接続、および／またはワイヤレス８０２．１１ｂ、ｇ、ａ、またはｎ接続のようなワイヤレス接続とすることができる。一実施形態によれば、計算環境２１２は、クロックをキャプチャー・デバイス２０に供給することができる。このクロックは、例えば、通信リンク３６を介して場面をいつ取り込むべきか判定するために使用することができる。

[0062] 加えて、キャプチャー・デバイス２０は、例えば、３−Ｄカメラ２６および／またはＲＧＢカメラ２８によって取り込まれた深度情報および画像を供給することができる。これらのデバイスの補助によって、本技術にしたがって部分的骨格モデルを製作し、その結果得られたデーターを計算環境１２に、通信リンク３６を通じて、供給することができる。

[0063] 更に、計算環境１２は肢識別エンジン１９２を含むことができる。肢識別エンジン１９２は、候補身体部分を提案する身体部分提案システム１９４と、候補身体部分の折り合いをつけて(reconcile)全体的または部分的骨格を求める骨格解明システム１９６を有する。他の実施形態では、身体部分提案システム１９４および骨格解明システム１９６を含む肢識別エンジン１９２は、部分的にまたは全体的にキャプチャー・デバイス２０内で実行させることもできる。身体部分提案システム１９４および骨格解明システム１９６を含む肢識別エンジン１９２の更なる詳細については、以下で明記する。

[0064] 本技術の実施形態の動作について、これより図３の上位フローチャートを参照しながら説明する。ステップ２８０において、システム１０を起動する。ステップ２８２において、キャプチャー・デバイス２０は画像データーを取り込む。ステップ２８６において、身体部分提案システム１９４は候補身体部分位置を提案する。様々な可能な実施形態の１つでは、身体部分提案システムは、原型(Exemplar)を実行して重心(centroid)を生成する。原型および重心の生成は、二次元深度テクスチャ画像を受け取り、その画像内にある特定の身体部分の適正な識別に関する確率を求める既知の技法である。実施形態では、以下で説明するように、ユーザーの頭部、肩、肘、手首、手について重心を生成する。しかしながら、他の実施形態では、重心は、下半身部分の関節、身体全体、選択した関節について生成してもよいことは言うまでもない。再度注記しておくが、原型および重心の生成は、画像において身体部分を識別する一例に過ぎず、多種多様の他の方法のいずれでも、この目的に用いてもよいことは言うまでもない。他のステートレスな技法を用いてもよい。更に他の実施形態では、以下で説明するように、例えば、マグネティズムを含むステートフルな技法を、付加的に用いてもよい。

[0065] 身体部分提案システムのステップ２８６は、キャプチャー・デバイス２０またはコンピューター環境１２のいずれかにおいて、グラフィクス処理ユニット（ＧＰＵ）によって実行することができる。このステップの一部は、キャプチャー・デバイス２０における中央演算装置（ＣＰＵ）によって計算環境１２のために実行することもでき、また他の実施形態では、専用のハードウェアによって実行することもできる。

[0066] ステップ２９２において、骨格解明システム１９６は、以下で説明するように、上半身における関節を特定および追跡することができる。ステップ２９６において、骨格解明システム１９６は、計算環境１２または計算環境１２上で実行しているアプリケーションを制御する際に用いるために、特定した肢の位置を戻す。実施形態では、肢識別エンジン１９２の骨格解明システム１９６は、ユーザーの頭部、肩、肘、手首、および手についての情報を戻すことができる。更に他の実施形態では、戻される情報は、これらの関節の内一部のみ、下半身あるいは身体の左側または右側からの関節というような追加の関節、または身体の関節全てを含むこともできる。

[0067] 肢識別エンジン１９２の身体部分提案システム１９４および骨格解明システム１９６の更に詳細な説明を、図４Ａおよび図４Ｂのフローチャートを参照しながら行う。一般に、肢識別エンジン１９２は、頭部、肩、および四肢を識別し、他の実施形態では、潜在的に他の身体部分も識別することが可能である。エンジン１９２は、重心（または他の身体部分提案システムからの候補身体部分位置）および深度マップ・データーを消費し、プレーヤーの関節位置(positions of player joint locations)を、対応する信頼性と共に戻す。ステップ３０４において、キャプチャー・デバイス２０は、次のフレームのためにＦＯＶの画像データーを取り込む。実施形態では、フレーム・レートは３０Ｈｚとするとよいが、他の実施形態では、フレーム・レートはこれよりも高くてもまたは低くてもよい。ステップ３０８において、肢識別エンジン１９２は、最初に頭部三角形を発見する。一般に、候補頭部三角形は、画像データーから原型によって特定された頭部および肩の重心のグループからの２カ所の肩に繋がれた１つの頭部重心から形成することができる。図１０は、候補重心５０２、５０４、および５０６から形成された頭部三角形５００の一例を示す。頭部三角形を発見するステップ３０８についての更に詳細な説明を、図５Ａおよび図５Ｂのフローチャートを参照しながら、これより行う。

[0068] 一般に、原型は、ユーザーについての強い頭部および肩の信号を供給する。この信号は、１つの頭部および２つの肩の重心のパターンを一緒に発見できるときに一層強くなる。頭部の重心は、原型／重心以外のあらゆる数のソースから受けてもよく、例えば、ソースは、頭部マグネティズムおよび単純なパターン照合を含む。ステップ３６０において、肢識別エンジン１９２は、最新のフレームにおいて、新たな頭部および肩の重心を集める。新たな頭部および肩の重心は、以前のフレームにおいて発見された既存の重心、言い換えると、「経時」(aged)重心を更新するために用いられる。遮蔽(occlusion)が存在することもあるので、全ての重心が各フレームにおいて見える訳ではない。経時重心は、候補身体部分の位置の知識を、所与のゾーンの直前の処理から受け渡すために用いられる。ステップ３６４において、新たな頭部および肩の重心を用いて経時重心を更新する。新たな重心の内、経時重心の近くで発見されたものはいずれも、既存の経時重心に併合する(merge)ことができる。経時重心に近くない新たな重心は、いずれも、ステップ３６６において新たな経時重心(new aged centroid)として追加する。経時重心および新たな重心によって、多数の候補頭部三角形を得ることができる。

[0069] ステップ３６８において、頭部三角形を組み立てる(compose)ことができる。頭部および肩が見える場合、頭部三角形は、前述のソースの１つ以上から組み立てることができる。しかしながら、例えば、１人のプレーヤーが他のプレーヤーの前に立っている場合というように、ユーザーの１つ以上の関節が偶然遮られることもあり得る。頭部または肩の関節の１つ以上が短い間遮られるとき、そこには新たな重心がないかもしれない（新たな深度マップから）。その結果、その位置を印していた経時重心は更新されるかもしれないし、またはされないかもしれない。その結果、この経時重心は、２つのことの内１つを実行する可能性がある。

[0070] 第１に、経時重心は、その位置が変化せずに、存続する（遮蔽が終わるまで待つ）可能性がある。第２に、経時重心は、間違って新しい近隣位置にジャンプする可能性がある（例えば、左肩が遮られていたが、長椅子の左上縁が肩のように見え、そしてかなり近いと、経時重心がそこにジャンプする）。これらの場合を扱うために、三角形の頂角の内１つ以上に対する経時重心を無視する追加の候補三角形を組み立てることもできる。３つの関節の内どれが遮られているか分からないので、以下で説明するように、評価のためにできるだけ多くの三角形を提案するとよい。

[0071] 場合によっては、１つの関節が遮られていることもある。例えば、左肩が遮られているが、頭部および右肩は見えることもある（この場合も、遮られているのが左肩であることは未だ分っていない）。頭部および右肩は、例えば、平均３ｍｍだけ右に動いていたこともあり得る。この場合、左肩も右に３ｍｍだけ動いた（それがあったところにドラッグしたり、間違って新たな場所にジャンプするのではなく）追加の候補三角形も組み立てることにより、関節の内１つがある時間見ることができなくても、三角形状が（特に、ときの経過と共に）保存されるようにする。

[0072] 他の例では、頭部が、例えば、他のプレーヤーの手によって遮られているが、両肩は見えることもある。この場合、肩が動くと、新たな肩の位置を用いて、追加の候補三角形が作られるが、頭部は肩と同じ平均変位量だけ変位する。

[0073] 場合によっては、２つの関節が遮られることもある。３つの関節の内１つしか見えない場合、先に説明したように、他の２つが「揃ってドラッグする」(drag along)することができる（即ち、１つの見える関節と同じ方向に同じ量(magnitude)だけ動く）。

[0074] ３つの関節のいずれもが見えない（３つ全てが遮られている）場合、適所に留まり続ける予備の候補三角形を作ることができる。これが役に立つのは、１人のプレーヤーが他のプレーヤーの前を歩いて、後ろにいるプレーヤーを完全に遮ったときであり、後ろのプレーヤーの頭部三角形がある時間量だけその場に存在することが許され、その後破棄されるときである。例えば、８秒間適所に留まることができるが、他の実施形態では、それよりも長い間または短い間留めておいてもよい。一方、その時間が経過する前に遮蔽が終わった場合、三角形は正しい場所にあり、後ろのプレーヤーの背後に機敏に移ることができる。これは、場合によっては、後ろのプレーヤーを再度発見するよりも望ましいこともある。何故なら、プレーヤーの識別(identity)が維持されるからである。

[0075] 頭部三角形を評価するための採点サブルーチンについて、以下に説明する、この採点サブルーチンを、頭部三角形トレースおよび突出(head triangle trace and saliency)と呼ぶ。このサブルーチンは、サンプル点（それらの期待深度値、即ち、Ｚ値を含む）を、その画像における同じ画素（Ｘ．Ｙ）位置における深度値に対して検査する。このサブルーチンは、三角形が偶然殆ど（または全体的にでも）遮られている場合であっても、提案された三角形の中で深度マップに一番よく当てはまる三角形を選択するように設計されている。前述のように追加の三角形を含ませることによって、経時重心が短時間正しくなかったり、見失ったりしても、確実に正しい三角形を提案する。

[0076] ステップ３６９において、頭部三角形を、採点サブルーチンによって評価することができる。ステップ３６８における肢識別エンジンの目標は、実際にＦＯＶの中にいる１人以上のユーザーの頭部および肩の正しいインディケーターとなる、経時重心の頭部三角形を特定することである。肢識別エンジン１９２は、開始すると、頭部経時重心を左肩および右肩の経時重心と繋ぎ合わせることによって、多くの三角形を生成する。これらの各々が、候補頭部三角形を形成する。これらは、所与のユーザーの頭部および肩であっても、なくてもよい。次いで、多数の肩採点サブルーチンを実行することによって、これらの候補頭部三角形の各々を評価する。

[0077] 採点サブルーチンは、候補頭部三角形に対して実行して、最良の（即ち、得点が最も高い）頭部三角形を特定する。ステップ３６８における採点サブルーチンの更なる詳細について、これより図６のフローチャートに関して更に詳細に説明する。ステップ３９０において、第１採点サブルーチンが、候補三角形における２つの肩重心間の距離を測定し、左肩および右肩間の最小分離未満かまたは最大分離を超えているか否か確認する。例えば、人間の、左肩および右肩の間における最大の肩幅は約８０ｃｍであることが知られている。本システムは、追加のバッファをそれに加えることができる。２つの候補肩重心がこの最大値を超えた場合、この候補三角形を候補として取り除く。

[0078] 他の採点サブルーチンは、頭部が最小分離未満か、またはステップ３９４における両肩間の線よりも上の最大分離を超えているか否かについて測定することができる。この場合も、この寸法は、既知の最大値および最小値を有することもできる。本システムは、何らかの追加の緩衝(buffer)をそれに加えることもできる。候補の頭部三角形がその最大値を超えるか、または最小値未満である場合、この候補を除外することができる。

[0079] ステップ３９０および３９４と同様の採点ルーチンの他の例には、以下のものが含まれる。肩の中心から頭部の中心へのベクトル方向。この肩の中心から頭部の中心までのベクトルが好ましくない方向（下というような方向）を指し示す場合、三角形の得点が減点されるか、または（論外の場合）その三角形が破棄される可能性がある。左肩と右肩との間のベクトル。左肩と右肩との間のベクトルが好ましくない方向（予期したのとは逆というような方向）を指し示す場合、三角形の得点が減点されるか、または（論外の場合）その三角形が破棄される可能性がある。頭部から左／右肩までの距離の差。頭部からいずれかの肩までの２つの距離が徐々に大きく異なっていく場合、三角形の得点が減点されるか、または（論外の場合）その三角形が破棄される可能性がある。経時重心間の平均距離。３つの経時重心間の平均距離（または、言い換えると、頭部三角形の縁の長さ）が非常に短いかまたは非常に長い場合、三角形の得点が減点されるか、または（論外の場合）その三角形が破棄される可能性がある。このサブルーチンまたは以上のサブルーチンのいずれかにおいて、サブルーチンの採点の結果候補三角形が破棄された場合、その候補について別のサブルーチン検査を実行する必要はない。他の採点サブルーチンを用いてもよい。

[0080] 候補頭部三角形を採点する際の重要な採点サブルーチンは、トレースおよび突出ステップ４０２および４０６である。トレース・ステップ４０２は、３本の線に沿ったトレース・サンプルを取り込むことを伴い、各線は、候補頭部三角形における両肩間の線の中心において開始し、当該三角形の３つの先端に向かう。例えば、図１０はユーザー１８上における頭部サンプル・トレース５１０を示す。トレース・サンプル５１０に沿って画素を測定し、深度値が期待通りでない場合（即ち、撮像カメラ・コンポーネント２２からの深度データーによって示される、３−Ｄ実世界におけるユーザーの深度を表す）、候補頭部三角形を減点する。

[0081] 以上のトレース・サンプルの例は、関節間の線に沿って並んでいるサンプルを伴うが、トレース・サンプルは、多種多様のユーザーについて身体内部に入るはずのサンプルであって、更に内部空間を均等に占めるサンプルであればいずれでもよい。実施形態では、これらのサンプルは人の最小のシルエットを埋めるのであればよい。実施形態では、これらのサンプルのレイアウトは、候補頭部三角形の向き、または他の候補の特徴に左右されて、劇的に変化する可能性がある。

[0082] トレース・サンプルについて、相応しいＺ−一致(Z-match)（期待深度値およびその画面のＸ，Ｙ位置における実際の深度値が同様である場合）は加点(reward)となり、相応しくないＺ−一致は減点となる。不一致(mismatch)の一致に対する近さ(closeness)／激しさ(severity)は、減点／加点の量に作用することができ、正の不一致および負の不一致では、異なる得点を付けることもできる。一致について、近い一致(close match)は弱い一致(weak match)よりも高い得点を得る。劇的な不一致は、その差の符号に基づいて、分けて扱う。深度マップ・サンプル(depth map sample)が期待したよりも遠い場合、これは「突出」サンプルであり、厳しい減点を招く。深度マップ・サンプルが期待したよりも近い場合、これは「遮蔽」サンプルであり、軽い減点を招く。実施形態の中には、候補身体部分位置の深度間で、期待Ｚ値を単に内挿補間する場合もある。他の実施形態では、首および肩に対する、あごおよび顔の突出のような、共通する非線形な身体の形状を補償するために、期待Ｚ値を調節する。骨格の他の部分から開始する他の実施形態では、期待Ｚ値の同様の内挿補間および調節を行うことができる。

[0083] ステップ４０６における突出サブルーチンが動作すると、所与の候補頭部三角形における３つの点の各々を中心としてある距離の所に、多数の突出サンプル（図１０における５１２）を定義する。実施形態の中には、これらのサンプルが三角形の点の上において円弧の形状をなすのであってもよい。ユーザーの体格は様々であると考えられるので、肩の周囲に形成される突出サンプル５１２は、可能な限り最も大きな（即ち、嵩張る）ユーザーであってもその両肩の外部にこれらが確実に来るように、場合によっては頭部三角形または他の候補造作のサイズに対して十分に大きな半径で形成しなければならない。このサイズ調節は、子供の頭部は大人の頭部よりも比例して大きいことの観察に基づいて、頭部周囲のサンプルの半径には、より低い程度で適用してもよい。しかしながら、突出サンプル５１２は、ユーザーに対して最も大きい可能性がある頭部の外側に確実に来るように、候補三角形の頭部の位置を中心としてある距離の所に位置付けられる。高得点の候補頭部三角形では、トレース・サンプル５１０とは対照的に、全ての突出サンプル５１２の深度値はユーザー１８よりも深い（即ち、Ｚ方向において離れている）はずである。

[0084] 突出サンプルについては、相応しいＺ−一致は減点となり、相応しくないＺ−一致は加点となり、正の不一致および負の不一致では、異なる得点を付けることもできる。深度マップ値が期待値に近い場合、これは減点を招く。そして、深度マップ値が期待したよりも近い場合、これは「遮蔽」サンプルであり、緩い減点を招く。

[0085] ステップ３９０から４０６における種々のサブルーチンの得点を合計して、最高得点の頭部三角形を得る。これらの採点サブルーチンの中には、例えば、ステップ４０２および４０６のトレース検査および突出検査のように、この合計に他よりも大きく重み付けするとよい場合もある。尚、更に他の実施形態では、採点サブルーチンが異なれば、重みも異なる場合もあることは言うまでもない。更に、候補の頭部三角形が実際にＦＯＶの中にいるユーザーの頭部および両肩を表すか否か評価するために、図６に示した採点サブルーチンに加えて、またはその代わりに、他の採点サブルーチンを用いてもよい。

[0086] これより図５Ａに戻り、一旦最高得点の候補頭部三角形を特定したなら、これらの三角形を既存の「アクティブ」、「インアクティブ」、および「潜在的」ユーザー上にマッピングする。具体的には、視野の中にいて人であると既に確実に識別されているユーザー（椅子やマネキンではなく）を、アクティブ・ユーザーまたはインアクティブ・ユーザーのいずれかに分類する。本システムは、潜在的ユーザーと、人間のように見えることがある物体との間で、手の動きを経時的に検出することによって区別する。実施形態では、処理の制約を想定して、本システムは視野の中にいる２人のユーザーの手の動きのみを追跡すればよい（以下で説明する）。このような実施形態では、２人のアクティブなプレーヤーを、人間のような手の動きによって、どちらの潜在的プレーヤーが最初に人として確認されたかというような、多数の規準のいずれかに基づいて選択することができる。代替案として、折り合いをつけた骨格データーの最後の消費箇所(consumer)というような、システムにおける他のコンポーネントによって、アクティブ・プレーヤーを選択することもできる（１組のアクティブ・プレーヤーおよびインアクティブ・プレーヤーの中から）。残りの識別されたユーザーは、インアクティブ・ユーザーとなる。アクティブ・ユーザーの手の動きを追跡するが、インアクティブ・ユーザーの手の動きは、追跡しない。更に他の実施形態では、２人よりも多いユーザー、または全てのユーザーをアクティブと見なし、彼らの手の動きを追跡するようにしてもよい。

[0087] また、深度カメラが、肢ＩＤエンジンによる処理の結果として、視野内に、以前に特定されていない新たな人を含むように見える画像を検出したということが起こる場合もある。この場合に示されたユーザーを、潜在的ユーザーと呼ぶ。潜在的ユーザーの手の動きを、これらを人間であると確実に識別できるまで、多数のフレームにわたって追跡することができる。識別できた時点において、状態が潜在的ユーザーからアクティブ・ユーザーまたはインアクティブ・ユーザーのいずれかに切り替わる。

[0088] ステップ３７０において、アクティブ・プレーヤー毎に、最高の候補三角形を既存のアクティブ・プレーヤー上にマッピングする。アクティブ・プレーヤーの直前のフレームの頭部三角形に基づいて、視野の中にいて直前のフレームからサイズまたは位置が大きく変化していなさそうなアクティブ・プレーヤーに三角形をマッピングすることができる。ステップ３７２において、ステップ３７０においてマッピングした三角形に近すぎる候補三角形を、いずれも候補としては破棄する。これは、２人のユーザーが同じフレームにおいて実質的に同じ空間を占めることはできないからである。次いで、直前のフレームに他にいずれかのアクティブ・プレーヤーがいる場合、本プロセスはステップ３７３において繰り返す。

[0089] ステップ３７０および３７２は、具体的には、以下のステップを含むことができる。直前のフレームのプレーヤー毎に、各候補三角形をプレーヤーと突き合わせて検査する。次いで、三角形の形状がどの位変化したかに比例して、減点を適用する。次に、三角形（またはその頂角）がどの位動いたかに比例する減点を適用する（減点は線形でも非線形でもよい）。また、ここで点の運動(motion)予測（運動量）を考慮にいれてもよい。次いで、最高の得点となった三角形を選出する。得点が閾値よりも高い場合、この三角形を直前のフレームのプレーヤーに割り当て、近隣にある他の全ての候補三角形を破棄する。他の直前のフレームのプレーヤー毎に、以上のステップを繰り返す。他の実施形態では、候補三角形を直前のフレームのアクティブ・プレーヤーの三角形と照合するのに、異なる採点規準を用いることもできる。

[0090] ステップ３７４において、インアクティブ・プレーヤー毎に、上位候補三角形を既存のインアクティブ・プレーヤー上にマッピングする。インアクティブ・プレーヤーの直前のフレームの頭部三角形に基づいて、視野の中にいるインアクティブ・プレーヤーに三角形をマッピングすることができる。ステップ３７６において、ステップ３７４においてマッピングした三角形に近すぎる候補三角形を、候補としては破棄する。次いで、直前のフレームに他にいずれかのインアクティブ・プレーヤーがいる場合、本プロセスはステップ３７７において繰り返す。ステップ３７４および３７６の更なる詳細は、直前の節において説明した通りでよい。同様に、ステップ３７８において、潜在的なプレーヤー毎に、上位候補三角形を、特定した潜在的プレーヤー上にマッピングする。潜在的なプレーヤーの直前のフレームの頭部三角形（識別された場合）に基づいて、または潜在的なプレーヤーの位置を特定する他の既知の方法に基づいて、視野の中にいる潜在的なプレーヤーに三角形をマッピングすることができる。ステップ３８０において、ステップ３７８においてマッピングした三角形に近すぎる候補三角形を、いずれも候補としては破棄する。次いで、直前のフレームに他にいずれかの潜在的なプレーヤーがいる場合、本プロセスはステップ３８１において繰り返す。ステップ３７８および３８０の更なる詳細は、直前の節で説明した通りでよい。

[0091] ステップ３８２（図５Ｂ）において、肢識別エンジン１９２は、ユーザーにマッピングされておらず破棄もされていない候補三角形の残り物の中に相応しいものがないかチェックする。ある場合、これら残り物の相応しい候補三角形を、視野に入って来た新たなユーザーに属すると解釈することができる。この場合、ステップ３８４において、残り物の頭部三角形をその新たなユーザーに割り当て、この新たなユーザーを潜在的ユーザーと名付ける。次いで、手の動きについて先に説明したように、この潜在的ユーザーの手の動きを連続フレームにおいて追跡する。

[0092] 再度図４Ａを参照する。ステップ３０８において頭部三角形を特定した後、肢識別エンジン１９２は、ステップ３１０において手の提案(hand proposal)を発見する。これらの動作は、全てのアクティブ・ユーザーおよび潜在的ユーザーについて実行することができる。実施形態では、インアクティブ・プレーヤーについては手の提案を追跡しないが、他の実施形態ではこれらを追跡してもよい。アクティブ・ユーザー、インアクティブ・ユーザー、および潜在的ユーザーについて、頭部三角形の動きを追跡することができる。

[0093] 実施形態では、種々の方法によって手の提案を発見し、一緒に組み合わせることができる。第１の方法では、手であると正しく識別された確率が高い重心を用いる。本システムは、例えば、片側当たり７つ（左手毎に７つの提案、および右手毎に７つの提案）というように、多数のこのような手の提案を用いることができる。所与の側で選択した重心手提案(centroid hand proposal)に加えて、原型(Exemplar)はときとしてどの手がどちらなのか混乱することがある。このため、例えば、更に４つといように、追加の数の候補を、関連のある肩の反対側における手の重心について取り込むとよい。尚、これらの数よりも多いまたは少ない手の提案も、他の実施形態では用いてもよいことは言うまでもない。

[0094] 手の提案を集める第２の方法は、マグネティズム（magnetism)と呼ばれる技法による。マグネティズムは、以前の１つまたは複数のフレームからの骨格造作（例えば、手）の位置を、新たな深度マップに「撮る」(snapping)という概念を伴う。例えば、以前のフレームにおいてあるユーザーの左手が識別され、その手が分離されている（何も触っていない）場合、マグネティズムは、現在のフレームにおけるその手の位置を、新たな深度マップを用いて、精度高く更新することができる。加えて、手が動いている場合、２つ以上の以前のフレームにわたってその手の動きを追跡することによって、新たなフレームにおけるその位置の正しい推定を行うことができる。この予測した位置は、手の提案として明白に用いることができる。加えてまたは代わりに、この予測した位置を現在の深度マップに、マグネティズムを用いて撮ることができ、現在のフレームよりも一致する他の手の提案を得ることができる。実施形態では、肢識別エンジン１９２は、以下で説明するように、種々の開始点に基づいて、プレーヤー毎に各側で（各プレーヤーの左手について３つ、そして各プレーヤーの右手について３つ）マグネティズムによって３つの手の提案を行うことができる。実施形態では、重心およびマグネティズムの内一方または他方を、双方の代わりに、用いてもよいことは言うまでもない。更に、更に他の実施形態では、手の提案を発見するために、他の技法を採用してもよい。

[0095] マグネティズムによって手の提案を発見する特殊な場合が、前腕の手に向かってその軸に沿った動きの有無をチェックするときに適用される。この場合、マグネティズムは、ユーザーの手を彼らの前腕の中間まで撮ることができるが、これは望ましくない。この場合正しく処理するためには、本システムは、手の位置を下腕(lower arm)よりもある距離だけ下に動かしたとき、例えば、ユーザーの前腕の長さの１５％動かし、次いでマグネティズムを用いて撮ったときの、他の手の提案を生成することができる。これによって、前腕に沿った軸方向の運動の場合に、手の提案の１つが正しく位置付けられることを確保する。

[0096] マグネティズムは、身体部分の提案(body part proposal)を深度マップに「撮る」ことによって、その位置検出(location)を厳格に求める。これは、手、足、および頭部というような、関節を区切る(terminate)のに非常に有用である。実施形態では、これは、深度マップにおいて近隣の画素を調べて提案の位置に最も近い（３Ｄにおいて）画素を求めることを伴う。一旦この「最も近い点」が発見されたなら、その点を、厳格な手の提案(refined hand proposal)として用いることができる。しかしながら、その点は、大抵の場合、対象となる造作（手のような造作）の中心ではなく縁にあるが、中心の方が望ましい。このため、追加の実施形態では、前述した「最も近い点」からある距離（３Ｄにおいて）以内にある近隣画素を探すことによって、手の提案を更に厳格に求めることができる。この距離は、身体部分（手のような身体部分）の期待直径(expected diameter)にほぼ一致するように設定するとよい。次いで、「最も近い点」からこの距離以内にある画素の一部または全ての位置の平均を取り、手の提案の更に厳格な位置を求めることができる。実施形態では、「最も近い画素」および寄与する画素を結ぶ滑らかな経路を発見できない場合、この平均に寄与する画素の一部を拒否してもよいが、実施形態ではこれを省略することもできる。

[0097] 一旦ステップ３１０における種々の方法から手の提案が発見されたなら、ステップ３１２においてこれらを評価する。頭部三角形の場合と同様、種々の採点サブルーチンによって、候補の手の提案に対して種々の重心およびマグネティズムを実行することによって、手の提案を評価することができる。これらのサブルーチンについて、これより図７のフローチャートに関して更に詳しく説明する。

[0098] ステップ４１０において、手の提案の近くにおける画素の動き(motion)の有無をチェックする採点サブルーチンを実行することができる。この検査では、手の提案の近傍における画素がどの位速く「動いているか」検出する。実施形態では、この動き検出技法は、手だけでなく他の身体部分の提案について、動きを検出するためにも用いることができる。視野は、直交座標系を基準にして決めることができ、Ｚ軸は深度カメラ２０から真っ直ぐ外に向かい、Ｘ−Ｙ平面はＺ軸に対して垂直になる。Ｘ−Ｙ平面における動きは、その画素位置における深度値を、あるフレームと次のフレームとの間で比較したときに、所与の画素位置における劇的な／急激な深度変化として現れる。このような劇的なＺ−変化を受ける画素の量（種々の位置における）は、手の提案の近傍においてどの位Ｘ−Ｙの動きがあるかという指示を与える。

[0099] Ｚ方向の動きは、これらの画素間における、正味の正または負の平均的な前方または後方の動きとして現れる。手の提案の位置（Ｘ−Ｙ平面）に近い画素の内、直前のフレームおよび新たなフレームの双方において、その深度値が手の提案の深度に近い画素だけを考慮すればよい。一緒に平均を取ると、これらの画素のＺ変位が全て前方または後方に動く場合、これは、大まかに空間的に一貫性のあるＺ方向への手の動き(motion)の指示となる。そして、この場合、この動きの正確な速度は直接分かる。

[00100] 次に、Ｘ−Ｙ平面における動き、およびＺ軸方向の動きを組み合わせて、Ｘ、Ｙ、およびＺ方向の手の動きの総量を示す。次いで、これを手の動きの得点に（およびこの手の提案において累積された(build)あらゆる手の仮説の得点にも）分解する(factor)することができる。一般に、手の提案の近傍におけるＸＹＺ方向の動き(motion)は、手の提案が、家具のような生命のない物体ではなく、生きている存在に属することを示す傾向があり、ステップ４１０においてその手の提案に対してより高い得点が得られる。実施形態では、本システムが人としてまたは人以外として破棄しようとする潜在的なプレーヤーに対して、このスコアにより多くの重み付けをすることができる。

[00101] ステップ４１６において、肢識別エンジン１９２は、提案された手が、この提案が指す手の最後の直前フレームの位置からどれだけ遠くまでジャンプしたかチェックする別の採点サブルーチンを実行することができる。ジャンプが大きい程、現在の候補は手でないことを示す可能性が高く、それに応じて得点は減点される。ここでは、限定は線形でも非線形でもよい。

[00102] 原型によって生成された手の提案について、肢識別エンジン１９２は、更に、ステップ４２０において所与の手の提案に対して重心信頼性(centroid confidence)を用いることができる。この重心信頼性が高い値であると、その手の提案に対する得点が加点される可能性が高くなる。

[00103] ステップ４２４において、肢識別エンジン１９２は、対応する肩からの手の提案の距離をチェックする採点サブルーチンを実行することができる。肩からの距離が、肩と手との間で可能な距離よりも長い場合、これに応じて得点を減点する。この肩から手までの距離の最大範囲は、推定されたプレーヤーの体格にしたがって調整(scale)することができる。プレーヤーの体格は、ときの経過と共に減衰する(damp)頭部−肩三角形から、またはプレーヤーの腕の長さから求めることができる。

[00104] ステップ４２８において、他の採点サブルーチンによって、ステップ４１０における弱い画素動き得点(pixel motion score)と結び付けて、手の提案を直前のフレームにおいて追跡するのに成功したか否かチェックすることができる。このサブルーチンは、手が直前のフレームにおいて追跡されなかった場合、動き得点閾値と一致するまたはこれを超える手の提案のみを考慮すればよいという事実に基づく。この理由のために、腕または手のように見える（椅子の肘掛けのような）深度が動かない造作(non-moving depth feature)は、連続する可能性は低い。手は、追跡を開始するためには、動かなければならない（家具は動かない）。しかし、いつ動いても、動くのを止めることができ、それでも追跡することができる。以下で説明するが、頭部三角形照合によって特定した肩の位置が分かっていると仮定して、所与の手の候補、種々の可能な肘の位置を計算する。以上で説明した手採点サブルーチンは、いずれも、以下で説明するように、発見された手／肘の組み合わせの各々について実行することができる。しかしながら、以上で説明した手採点サブルーチンはいずれも肘の位置には依存しないので、処理の観点からは、これらのサブルーチンを、種々の肘の位置をチェックする前に実行する方が一層効率的である。図７における採点サブルーチンの各々からの得点を合計し、以下で説明するように用いるために格納することができる。

[00105] 再度図４Ａを参照すると、ステップ３１８において、手の提案毎に、多数の肘の位置を検査し、肘の位置毎に手、肘、および肩を採点して、完全な腕の仮説を得る。可能な肘の位置の数は、様々であり、例えば、１０と１００の間である可能性もあるが、他の実施形態ではこの範囲よりも広い場合も狭い場合もあり得る。また、肘の位置の数は、動的に変化することもあり得る。手の提案および固定された肩に対して、肘の位置を選択し、肘がその位置にある全体的な腕の仮説を採点し、次の肘の位置を選択し、全体的な腕の仮説を採点するというように、所望数の肘の位置を計算し、腕の仮説を採点し終えるまで続ける。あるいは、採点する腕の仮説の数は、利用可能な計算時間を最大限用いるために、動的に決定することもできる。これは、ステップ３１６の後に残っている手の提案毎に実行して、種々の腕の仮説についての得点を決定する。

[00106] 一般に、所与の手の提案および既知の肩の位置に対して可能な肘の位置は、円に沿って並ぶように制約を受ける。この円は、２点（肩および手）を取り、直前のフレーム（またはこのデーターが入手できない場合は推定値）からの既知の上腕および下腕の長さを取り、次いでこれらの制約を仮定して、肘が通るはずの円（中心、ｘ、ｙ、ｚ、および半径）を数学的に計算することによって定義する。この問題は、周知の分析解を有し、一般に、点１から距離Ｄ１のところ、および点２から距離Ｄ２の所にある全ての点を記述するのは円である。手と肩との間の距離がＤ１＋Ｄ２未満である限り、有効な円がある。候補の肘位置は、この定義された円から選択することができる。しかしながら、これらの位置は不規則に乱れる可能性もある。これは、上／下腕の長さが正しくないかもしれないからであり、または肩／手の位置が近いが完全ではないかもしれないからである。

[00107] 尚、候補の肘位置は、例えば、腕の重心を含む、他の方法でも発見できることは言うまでもない。更に他の実施形態では、肘の位置に完全に不規則な点を選択することもでき、直前のフレームの肘の位置を用いることもでき、運動量射影(momentum-projected)肘位置を用いることもできる。また、これらの予測も乱れる（動き回る）可能性があり、異なる混乱で１回よりも多く用いられる可能性がある。

[00108] 図８は、手の提案毎に、各肘位置について実行することができる採点サブルーチンの更なる詳細を示す。ステップ４３０において、肢識別エンジン１９２は、現在の肘の位置および手の提案によって与えられる上腕および下腕の長さを測定することができる。上腕および下腕を組み合わせた長さが長すぎる場合または短すぎる場合、その肘位置および手の提案に対する得点を減点する。

[00109] ステップ４３４において、全長をチェックする代わりに、肢識別エンジン１９２は、上腕の長さの上腕および下腕の長さの和に対する比を、その腕の仮説についてチェックするサブルーチンを実行することができる。この比率は、人間の身体では、０．４５および０．５２の間で殆ど普遍である。この範囲を外れる肘の位置はいずれも減点すればよく、この減点は期待範囲から外れる超過量(trespass)に比例する。一般に、これらの採点関数、および本明細書において説明する他の採点関数は、連続でかつ微分可能(differentiable)であるとよい。

[00110] ステップ４３６において、所与の腕の仮説が力学的に有効か否か検査する採点サブルーチンを実行することができる。即ち、人の上腕および下腕の動き(motion)の既知の位置、ならびに腕の胴体に対する可能な向きを想定すると、人は所与の腕の仮説において、関節の位置を有効に有することができる。有効でない場合、腕の仮説を減点するか、または除去することができる。実施形態では、力学的有効採点サブルーチンを開始すると、３Ｄ実世界空間における人の位置を、この人の胴体の基準フレーム（実世界空間とは独立している）に対して平行移動および回転させることができる。このサブルーチンの動作は、他の実施形態では、実世界空間における人の位置／向きを用いて実行することができるが、最初に人の胴体の基準フレームに対してユーザーを平行移動させる方が、計算的には容易である。

[00111] この基準フレームにおいて、胴体空間に対する直交正規基準ベクトル(ortho-normal basis vector)を次のように可視化することができる。＋Ｘは左肩から右肩に向かう方向であり、＋Ｙは胴体／脊柱を上に向かう方向であり、＋Ｚはプレーヤーの胸部を通って外に向かう方向である（即ち、概略的に実世界空間における＋Ｚの逆である）。この場合も、この基準のフレームは一例に過ぎず、他の実施形態では様々であってもよい。

[00112] その後、所与の上腕位置に対して、肢識別エンジン１９２は、下腕が、この所与の上腕位置に対してこの下腕の可能な位置（方向および角度）を定義する円錐の中に入るか否かチェックする。前述の直交正規基準ベクトルを用いると、上腕は、６つの直交正規ベクトル位置（上腕前、上腕後ろ、上腕左、上腕右上、上腕下）に沿って（またはこれらの間に）位置する可能性がある。上腕のこれら直交正規方向の各々について、下腕の可能な方向を定義する対応する円錐は、指定するのが容易であり、大まかに分かっている。上腕の方向は（仮説において）これら６つの直交正規方向の内１つと正確に整列する(align)のは希であり、代わりにこれらの内数個の間に位置することが多いので、最も近い直交正規上腕方向と関連付けられた円錐の定義を一緒に配合して、上腕が位置する特定の方向に合わせて特別に作られた新たな円錐を生成する。この配合において、上腕が最も接近して整列する軸の円錐はより多くの重みを受け取り、上腕の反対方向に位置する軸の円錐は０の重みを有する。一旦配合円錐(blended cone)が分かったなら、次に下腕がこの円錐の中に位置するか否か確認するために検査する。次いで、下腕の方向が（有効な下腕の方向の）配合円錐の入らない腕の仮説を減点することができ、または論外である場合、破棄することできる。この減点は、線形でも非線形でもよい。

[00113] 尚、力学的に有効な腕の位置を検査する方法は他にもあることは言うまでもない。このような方法には、姿勢辞書参照、ニューラル・ネットワーク、または多数の他の分類技法の内いずれでも含まれる。

[00114] ステップ４３８において、現在の肘の位置が、最後のフレームにおいて決定された肘の位置からどれくらい遠くまでジャンプしたかチェックする採点サブルーチンを実行することができる。ジャンプが大きい程、減点も大きくなる。この減点は、線形でも非線形でもよい。

[00115] ステップ４４０および４４４において、腕の仮説に対してトレースおよび突出サブルーチンを実行して、採点することができる。具体的には、図１１を参照すると、所与の手の提案、肘、および既知の肩の位置に対して、上腕および下腕の中心線に沿った半径において、トレース・サンプル５１６を定義することができる。この半径は、これらのサンプルが、腕が細いユーザーであっても、ユーザーの上腕および下腕の間に確実に入るように十分に小さく設定する。一旦トレース・サンプルを定義したなら、これらのトレース・サンプルの深度を調べる。個々のサンプルが深度マップとの相応しくないｚ不一致(z mismatch)を有する場合、このトレース・サンプルは悪い得点を得る。全てのサンプルからの得点を記録して(tally)、最終的な得点を得ることができる。図９から図１１におけるユーザー１８は一方の腕を彼の背中の後ろに回しているが、トレース・サンプル、および以下で説明する突出サンプルも、左腕および右腕双方について取り込むことができることを注記しておく。更に、ユーザーの上半身を追跡するこの例では、図９から図１１におけるユーザー１８は、代わりに座ってもよい。

[00116] 同様に、Ｘ−Ｙ平面（キャプチャー・デバイス２０に対して垂直）内で腕の関節において、突出サンプル５２０を円、半円、または部分円状に定義する。また、突出サンプルは、図１１における上腕の回りに見られるように、「レール」状に並ぶこともでき、これらの肢セグメントがＺ方向に整列されていない場合（図１１では、明確化のために、下腕の回りの突出サンプルを省略する）上腕および下腕の各側で平行な線となる。円およびレール上双方におけるこれらのサンプルの全てを、実際の関節よりもある距離だけ離れたところ（ＸＹ平面内）に並べる。所与のサンプルの半径は、仮説が正しい場合、非常に太った(bulky)プレーヤーについてでも、サンプルが全てプレーヤーの腕のシルエットの外側に並ぶように、十分に大きくなければならない。しかしながら、最適な結果を得るために、半径はそれよりも大きくてはならない。

[00117] 一旦サンプル位置をＸＹ平面に並べたなら、各サンプル位置において観察した深度値と期待深度値を比較することができる。次いで、突出サンプルの内いずれかが、仮説の深度と同様の深度を示す場合、これらのサンプルを減点する。例えば、図１１において、突出サンプル５２０Ａ（図では塗り潰した正方形で示す）は、上腕および手の回りで減点される。トレースおよび突出検査の個々のサンプルの得点は、頭部三角形を考慮するときのトレースおよび突出検査について先に説明したのと同様とすればよい。

[00118] 以上の実施形態では、トレースおよび突出が一緒に動作する場合について纏めて論じたが、他の実施形態では、これらを個別におよび／または単独で用いることができることは注記してしかるべきである。例えば、システムがトレース・サンプルのみを用いて、または突出サンプルのみを用いて、種々の身体部分の回りの仮説を採点することもできる。

[00119] トレースおよび突出サブルーチンによって与えられる得点には、図８および図８に示した他のサブルーチンよりも高く重み付けすることができる。しかしながら、図７および図８における異なるサブルーチンは、異なる実施形態では異なる重みが与えられてもよいことは言うまでもない。更に、図７および図８に示すサブルーチンは一例に過ぎず、他の実施形態では、他のまたは代わりのサブルーチンを用いて、手の提案および可能な肘の位置を評価してもよいことも言うまでもない。

[00120] 一旦全ての腕の仮説についての得点を決定したなら、最も高い得点（１つまたは複数）を有する腕の仮説を、図４Ａのステップ３２２において特定する。これは、そのフレームに対する手、手首、下腕、および上腕を含む、ユーザーの左腕および右腕の位置の強いインディケーターを表す。ステップ３２６において、特定した肘の位置の近傍で肘の位置を動かすことによって、最も得点が高い腕の提案に対する肘の位置を更に厳格に求める(refine)。ステップ３２８において、肢識別エンジン１９２は、腕の位置を厳格に求めた結果、この腕の仮説の腕の位置の得点が高くなったか否かチェックする。高くなった場合、ステップ３３２において、厳格に求めた腕の仮説が、これまで得点が最も高かった仮説と置き換わる。ステップ３２６から３３２までは任意選択肢であり、他の実施形態では省略してもよい。

[00121] ステップ３３６において、ユーザーの左腕および右腕について得点が最も高い腕の位置を、何らかの既定の閾値信頼性値と比較する。実施形態では、この閾値は、直前のフレームにおいて手が信頼性を持って報告されたか否かに基づいて、または他の要因に基づいて変化することができる。これより図４Ｂを参照すると、ステップ３４０において、高い得点の左腕または右腕が閾値よりも低い場合、ステップ３４２において、信頼性報告を行わず、その腕についての腕データーをそのフレームに対して戻さない。

[00122] ステップ３４２において、所与のアームに対して信頼性報告を行わない場合、本システムは、このフレームに対して、その腕についての信頼性値やデーターを戻さなくてよい。この場合、本システムはステップ３５４に直接移って、以下で説明するように、潜在的なプレーヤーが確認されたかまたは除去されたか調べることができる。一方の腕の得点が閾値を超えたが他方が超えない場合、本システムは、閾値よりも高い腕についてのデーターを戻すことができる。一方、ステップ３４０において、双方の腕が閾値よりも高い得点を上げている場合、ステップ３４６において、頭部、両肩、肘、手首、および手を含む上半身における全ての関節についてその位置を戻す。以下で説明するが、これら頭部、肩、および腕の位置は、種々の動作のいずれでも実行できるように、計算環境１２に供給する。種々の動作には、計算環境１２上で実行するアプリケーションによる、ジェスチャー認識、およびディスプレイ１４上に提示された仮想物体との対話処理が含まれる。

[00123] ステップ３５０において、肢識別エンジン１９２は、任意に、特定されたユーザーの手の位置を更に厳格に求めようとすることができる。ステップ３５０において、肢識別エンジン１９２は、肘から手までの実世界空間ベクトルに沿って、下腕から最も離れた画素を発見して繋ぎ合わせることができる。これらの画素は、フレーム深度マップにおいて手にも繋がれる。次いで、これらの画素の内ある数または全ての平均を取り、ユーザーの手の位置を更に厳格に求めることができる。

[00124] 更に、肘から手のベクトルに沿って、これらの画素がどの位離れて位置するかに基づいて、これらの画素を採点することができる。次いで、この集合において、得点が最も高いある数の画素の平均を取り、滑らかな手の先端の位置を求めることができ、この集合において次に得点が高いある数の画素の平均を取り、滑らかな手首の位置を求めることができる。更に、これら２つの位置の間のベクトルから、滑らかな手の方向を導き出すことができる。用いる画素の数は、手の提案の深度、ユーザーの体格の推定値、またはその他の要因に基づくとよい。

[00125] 更に、繋がれている画素を探している間に、境界半径(bounding radius)を用いてもよい。この半径は、開いている手の最大期待半径であり、プレーヤーの体格および手の深度に合わせて調節される。この境界半径にヒットする正得点画素(positive-scoring pixel)が発見された場合、これは、手の先端を厳格に求め(refinement)損ねたらしいことの証拠となり（手を超えた何らかの物体または身体部分に広がる）、この厳格に求めた手の先端を、信頼性を付けずに、報告することができる。ステップ３５０は、ユーザーの手が他の物体と接触していないときに、最も正しく動作する。これは、多くの場合、信頼性検査に合格する十分な突出得点を有する腕に当てはまる。ステップ３５０は任意選択肢であり、他の実施形態では省略してもよい。

[00126] 先に示したように、アクティブ・ユーザーにもインアクティブ・ユーザーにも未だ関連付けられていないフレームにおいて、適した頭部三角形が特定された場合、これらの頭部三角形を潜在的なプレーヤーとして結び付ける(tag)。ステップ３５４において、肢識別エンジン１９２は、これら特定した潜在的なプレーヤーが、以下で説明するような、人の手の動きを行ったか否かチェックする。行っていない場合、エンジン１９２は、ステップ３５５において、十分な時間が経過したか否か、または手の動きを探し続けるためにもっと長い時間が必要か否か判断することができる。潜在的なプレーヤーから人の手の動きを確認できずに十分な時間が過ぎた場合、ステップ３５６において、潜在的なプレーヤーは間違いであったとして削除する。ステップ３５５において、潜在的なプレーヤーが人の手の動きを行ったか否か結論を出せる程十分な時間が経過していない場合、本システムは図４Ａのステップ３０４に戻ることができ、次のフレームのデーターを入手して、図４Ａから図８までに示すステップを繰り返す。

[00127] 各フレームの終端において、潜在的なプレーヤー毎に、肢識別エンジン１９２は、潜在的なプレーヤーが人か否か判断することを試みる。最初に、頭部および手追跡履歴を調べて、過去の１５程度のフレームを求める。他の実施形態では、これよりも多いフレームでも少ないフレームでもよい。選択した数のフレームの中に潜在的なプレーヤーが存在していた場合、以下のことをチェックすることができる。（１）これらのフレームの全てにおいて、頭部三角形が詳しく(strongly)追跡されたか否か。（２）これらのフレームの全てにおいて、左手または右手のいずれかが一貫して追跡されたか否か。（３）これらのフレームの中でやや滑らかな経路(semi-smooth path)に沿って少なくとも最小の正味距離だけ、例えば、１５ｃｍ手が動いたか否か。他の実施形態では、この値よりも大きくてもまたは小さくてもよい。これらが肯定の場合、プレーヤーを「人として確認した」と見なし、アクティブ・ユーザーまたはインアクティブ・ユーザーに格上げする。

[00128] プレーヤーを最初に追跡して以来１５フレームが未だ経過していないが、以上の制約の内いずれかが早い時期に違反された場合、潜在的なプレーヤーは人間ではないとして破棄し、新たな潜在的なプレーヤー(potentials)を次のフレーム上において選択することができる。例えば、潜在的なプレーヤーが存在する５番目のフレームにおいて、いずれの手も追跡できなかった場合、この潜在的なプレーヤーを直ちに抹消することができる。

[00129] また、この判断には、ある種の他の検査も用いることができる。「最小の正味距離」検査は、動き(motion)がない背景物体を落とすように設計されている。「やや滑らかな経路」の検査は、何らかの人の手の動きを行っている人の手を殆ど通すが、不規則で、混沌とした動き(motion)（大抵の場合、カメラのノイズによる）をする背景物体を殆ど常に落とすように設計されている。人の手の動きは、（約）３０Ｈｚで観察すると、人ができるだけ速くそして鋭い動きを行おうとしている場合であっても、ほぼ常にやや滑らかとなる。やや滑らかな検査を設計するには、多種多様な方法がある。

[00130] 一例として、このような実施形態の１つは以下のように動作する。手について１５フレームの位置の履歴がある場合、中央にある１１フレームを考慮することができる。フレーム毎に、以下のようにして代替位置(alternate location)を再現することができる。（１）単純な線形投影を用いて、直前の２つのフレームにおける位置のみに基づいて、手の位置を予測する。（２）続く２つのフレームにおける位置に基づいて、手の位置を逆予測する(reverse-predict)。（３）２つの予測の平均を取る。（４）この平均を、そのフレームにおいて観察した手の位置と比較する。これは、このフレームに対する「誤差」となる。

[00131] この「誤差」を１１フレーム分合計する。また、フレーム間で手が移動した距離も、１１フレーム分合計する。次いで、誤差の和を、移動した正味距離で除算する。この結果がある比率（例えば、０．７というような比率）よりも高い場合、この検査は不合格となる。そうでない場合、この検査は合格となる。尚、潜在的なプレーヤーを人として確認し、アクティブ・プレーヤーまたはインアクティブ・プレーヤーに格上げするか否か判断するためには、他の方法を用いてもよいことは言うまでもない。

[00132] 前述のように、ステップ３５４において、潜在的なプレーヤーが人であると確認した場合、ステップ３５８において、この潜在的なプレーヤーをインアクティブ・プレーヤーまたはアクティブ・プレーヤーに格上げする。ステップ３５６または３５８のいずれかを実行した後、本システムは図４Ａのステップ３０４に戻り、次のフレームのデーターを入手して、図４Ａから図８までに示すステップを繰り返す。このように、本技術は、各フレームにおいてキャプチャー・デバイス２０から受け取ったデーターを評価し、そのフレームにおける１人以上のユーザーの１つ以上の関節の骨格位置を特定することができる。

[00133] 例えば、図１２に示すように、肢識別エンジン１９２は、頭部５２２、肩５２４ａおよび５２４ｂ、肘５２６ａおよび５２６ｂ、手首５２８ａおよび５２８ｂ、ならびに手５３０ａおよび５３０ｂの位置を戻すことができる。図１２に示す種々の関節の位置は一例に過ぎず、これらは、他の例では、可能なユーザー位置であればいずれにでも変化する。また、ユーザーの関節の一部のみを測定すると、処理効率を超えた、潜在的な利点が得られる可能性があることも言うまでもない。更に、矛盾するジェスチャーを受け取り処理する可能性を回避するために、特定の１組の関節に焦点を絞るのでもよい。追跡しない関節は、所与のジェスチャーが行われたか否か判断するときに、無視する。

[00134] 以上で説明した実施形態では、肢識別エンジン１９２を用いてユーザーの上半身における関節を特定した。尚、同じ技法は、ユーザーの下半身における関節を発見するために用いてもよいことは言うまでもない。更に、ストロークから復帰しているユーザーというような、ある種のユーザーは、彼らの身体の左側または右側だけを使用することもあり得る。以上で説明した技法は、ユーザーの身体の左側または右側を追跡するためにも同様に用いることができる。一般に、いずれの数の関節でも追跡することができる。他の実施形態では、以上で説明した本システムは、ユーザーの身体における全ての関節を追跡するために用いることができる。指またはつま先の骨および関節、あるいは鼻および目というような顔の個々の造作というような、追加の造作も特定することができる。

[00135] ユーザーの身体の関節の内一部(fraction)のみに焦点を絞ることによって、本システムは、全ての身体の関節を測定するシステムよりも効率的に画像データーを処理することができる。このために、オブジェクト(object)をレンダリングするときに処理の高速化およびレイテンシーの低減が得られる。あるいはおよび／または加えて、これによって、所与のフレーム・レート以内で追加の処理も実行することが可能になる場合もある。この追加の処理は、例えば、フレーム毎に生成する関節データーの精度を更に確保するために、より多くの採点サブルーチンを実行する際に用いることができる。

[00136] 更に処理効率を高めるために、画像データーを取り込むキャプチャー・デバイスは、視野をもっと小さなエリアまたはゾーンに区分することもできる。このような実施形態を、例えば、図１３Ａおよび図１３Ｂに示す。図１３Ａでは、ＦＯＶを３つの縦向きゾーン５３２ａ、５３２ｂ、および５３２ｃに区分する。ユーザーは一般にキャプチャー・デバイス２０の真正面に立つという仮定を行うことができる。したがって、追跡すべき動きの殆どは、中央ゾーン５３２ｂ内で行われる。実施形態では、キャプチャー・デバイス２０はゾーン５３２ｂというような、１つのゾーンだけに焦点を絞ることができる。あるいは、キャプチャー・デバイスは、この例では、３フレーム毎に１回各ゾーンからフレーム・データーを読み取るように、連続フレームでこれらのゾーンを一巡することもできる。他の実施形態では、キャプチャー・デバイスは、中央ゾーン５３２ｂのような１つのゾーンに焦点を絞るが、既定数のフレーム毎に１回残りのゾーンも周期的に走査することもできる。それぞれのゾーン５３２ａ、５３２ｂ、および５３２ｃの他の走査シナリオも考えられる。更に、３つのゾーンへの区分は一例に過ぎない。他の実施形態では、２つのゾーンまたは３つよりも多いゾーンがあってもよい。明確な境界を有するゾーンが示されているが、他の実施形態では、これらのゾーンが互いに多少重複するのであってもよい。

[00137] 他の例として、図１３Ｂは、横に並んだゾーン５３２ａ、５３２ｂ、および５３２ｃを示す。図１３Ｂにおける種々のゾーン５３２ａ、５３２ｂ、および５３２ｃの走査は、図１３Ａに関して先に論じた例のいずれかに従えばよい。図１３Ａおよび図１３Ｂは二次元の区分を示すが、これらの実施形態のいずれかまたは双方は、更に、Ｘ−Ｙに加えて、あるいはＸまたはＹの代わりに、深度成分を有することもできる。つまり、ゾーンは、二次元または三次元とすることができる。

[00138] 本技術の更に他の態様によれば、ある種のゾーンにおいてある種のジェスチャーまたは行為(action)のみを許可することもできる。つまり、キャプチャー・デバイスは図１３Ｂにおける全てのゾーンを走査することができるが、例えば、ゾーン５３２ａでは、ユーザーの頭部のジェスチャーおよび動きのみを追跡するのであってもよい。ゾーン５３２ｂでは、ユーザーの膝のジェスチャーおよび動きのみを追跡する。そして、ゾーン５３２ｃでは、ユーザーの足のジェスチャーおよび動きのみを追跡する。このような実施形態は、例えば、ヨーロッパのフットボール（アメリカではサッカー）のような、計算環境１２上で実行するアプリケーションによっては、有用となり得る。以上のことは一例に過ぎない。あらゆる数のゾーンにおいても、他の身体部分を追跡することができる。

[00139] 動作において、仮想物体が動いて実世界ゾーン５２３ａ、５３２ｂ、および５３２ｃの１つに対応する機械空間位置に来るときを特定することができる。次いで、動いている物体が中にあるゾーンに基づいて、１組の許されているジェスチャーを引き出すことができる。ジェスチャー認識（以下で説明する）は通常通りに処理を進めることができるが、限られた数の許されたジェスチャーについてのみとする。所与のゾーンにおいて許すことができるジェスチャーは、計算環境１２上において実行するアプリケーションにおいて定義することができ、またそうでなければ、計算環境１２またはキャプチャー・デバイス２０のメモリーに格納することができる。このように定義されていない他の身体部分によって行われるジェスチャーは無視することができ、一方ジェスチャーが受け入れられる身体部分の定義内に含まれる身体部分によって、同じジェスチャーが行われた場合、何らかの関連のある行為に影響を及ぼす。

[00140] この実施形態は、所与のゾーンにおいて行われたジェスチャーがそのゾーンに対して定義されているか否かに応じて、この所与のゾーンにおいてある種の定義されたジェスチャーのみを受け入れると説明した。更に、この実施形態は、ＦＯＶをゾーンに分割しない場合でも動作することができる。例えば、システム１０は、ジェスチャーが受け入れられるある種の身体部分の定義によって動作することができる。このようなシステムは、認識プロセスを簡略化しジェスチャーの重複を防止する。

[00141] 図１４は、ジェスチャー認識エンジン１９０のブロック図を示し、図１５は、図１４のジェスチャー認識エンジン１９０の動作のフローチャートを示す。ジェスチャー認識エンジン１９０は、ステップ５５０において、姿勢情報５４０を受け取る。この姿勢情報は、画像データーにおいて検出されたユーザーの身体部分および関節の位置および／または動き(motion)に関する種々のパラメーターを含むことができる。

[00142] ジェスチャー認識エンジン１９０は、ステップ５５４において、受け取った姿勢情報５４０を分析し、この姿勢情報が、ジェスチャー・ライブラリー５４０に格納されているいずれかの既定の規則５４２を満たすか否か調べる。格納されている規則５４２は、姿勢情報５４０によって示される特定の位置および／または力学的運動を、既定のジェスチャーとして解釈すべきときを記述する。実施形態では、各ジェスチャーは、異なる一意の規則、または１組の規則５４２を有することができる。各規則は、図１２に示した身体部分の１つ以上について、多数のパラメーター（関節位置ベクトル、最大／最小位置、位置変化等）を有することができる。格納されている規則は、パラメーター毎に、そして図１２に示した身体部分５２６〜５３４ｂ毎に、１つの値、ある範囲の値、最大値、最小値を定義することができ、またはその身体部分についてのパラメーターが、その規則が該当するジェスチャーの判断に関連がないことの指示を定義することができる。規則は、ゲーム著作者によって、ゲーミング・プラットフォームのホストによって、またはユーザー自身によって作成することができる。

[00143] ジェスチャー認識エンジン１９０は、識別したジェスチャー、およびユーザーの位置／動きがそのジェスチャーに対応する尤度に対応する信頼性レベルの双方を出力することができる。具体的には、ジェスチャーについて必要となるパラメーターを定義することに加えて、規則は、更に、姿勢情報５４０をジェスチャーと解釈する前に要求される閾値信頼性レベルも含むことができる。一部のジェスチャーは、システム・コマンドまたはゲーミング命令として、他のジェスチャーよりも強い衝撃を有することもあり、したがって、姿勢をそのジェスチャーと解釈する前に、更に高い信頼性レベルが必要となる。姿勢情報を、規則について格納されているパラメーターと比較することによって、その姿勢情報がジェスチャーを示すか否かについての累計信頼性レベルが得られる。

[00144] 一旦所与の姿勢または動き(motion)が所与のジェスチャー規則を満たすか否かについて信頼性レベルが決定されたなら、ジェスチャー認識エンジン１９０は次にステップ５５６において、この信頼性レベルが、考慮対象の規則に対する所定の閾値よりも高いか否か判定を行う。この閾値信頼性レベルは、考慮対象の規則と関連付けて格納することができる。信頼性レベルが閾値よりも低い場合、ジェスチャーは検出されず（ステップ５６０）、何の動作も行われない。一方、信頼性レベルが閾値よりも高い場合、ユーザーの動き(motion)は、考慮対象のジェスチャー規則を満たすと判断し、ジェスチャー認識エンジン１９０は、ステップ５６４において、特定したジェスチャーを戻す。

[00145] 以上で明記した実施形態は、特定の関節を追跡する例、および／または特定のゾーンを追跡する例を提供した。このような実施形態は、多種多様のシナリオにおいて用いることができる。図１Ａに示した１つのシナリオでは、ユーザー１８がユーザー・インターフェース２１と対話処理している。このような実施形態では、本システムはユーザーの頭部および両手のみを追跡すればよい。計算環境１２において実行するアプリケーションは、ある種の関節（頭部および手というような）のみからの入力を受け取るように設定され、したがってどの関節またはゾーンを追跡すべきか、肢識別エンジン１９２に示すことができる。

[00146] 他の実施形態では、ＮＵＩシステムを有する何らかのユーザー・インターフェースを設けることもでき、ユーザーが、どの関節を追跡すべきか、および／またはどのゾーンを追跡すべきか示すことができる。このユーザー・インターフェースがあると、ユーザーが永続的な設定、または一時的な設定を行うことを可能にする。例えば、ユーザーが彼または彼女の右腕を怪我しており、ある時間期間動かせない場合、本システムは、その時間期間はその肢を無視するように設定することができる。

[00147] 更に他の実施形態では、図１Ｃに示すように、ユーザーが車椅子に座っている場合や、他の何らかの器官の障害者である場合もある。更に他の例には、彼の身体の左側または右側のみを使用する脳卒中患者(stroke victim)がある。一般に、ここでは、ユーザーは彼または彼女の身体のある種の部分に対して使用または制御が制限されているのでもよい。このような場合、本システムは、ユーザーによって、ある種の関節および／またはある種のゾーンのみからの動きを認識し追跡するように設定することができる。これは、ジェスチャーまたはユーザー・インターフェースとの他の何らかの手作業による相互作用によって遂行することができる。

[00148] ＮＵＩシステムは、多くの場合、ユーザーが猿まね（ＭＳＭＤ）のような画面上のアバター１９の動きおよびアニメーションを制御することを伴う。障害者のユーザーがＭＳＭＤモードでアバター１９を制御している実施形態では、１つ以上のインアクティブな四肢からの入力データーを無視し、予め保存してあるアニメーションと置き換えることができる。例えば、車椅子のユーザーがアバターを制御して仮想競技場を「歩いて」横断しているという場面では、アバターの位置的動き(positional motion)を、胴体上部および頭部によって導くことができ、四肢のＭＳＭＤマッピングの代わりに、アバターの脚部に合わせて、歩くアニメーションを再生することができる。

[00149] 実施形態の中には、ＮＵＩシステムとの所与の行為または相互作用を遂行するために、正常に動かない肢の動き(motion)が必要となる場合もある。このような実施形態では、本システムは、ユーザーが四肢のマッピングし直しを定義することを可能にする。即ち、本システムは、ユーザーの正常に動く肢の動きがアバター１９の意図する肢にマッピングされるように、正常に動く肢を正常に動かない肢と交換することを可能にする。これを遂行するこのような実施形態の１つについて、図１６のフローチャートを参照しながら説明する。

[00150] 図１６において、肢識別エンジン１９２から戻された腕のデーターを用いて、画面上のアバターの脚部を動画化し制御することができる。通常のＭＳＭＤ動作では、ユーザーの腕または両腕の動きから、画面上のアバターの腕または両腕の対応する動きが得られる。しかしながら、既定のジェスチャーを定義することもでき、これが行われそして認識されると、脚部制御モードに切り替わり，ユーザーの両腕の動きから、画面上のアバターの脚部の動きが得られる。ステップ５６２において、ジェスチャー認識エンジン１９０がこのようなジェスチャーを検出すると、計算環境１２は、５６４において、脚部制御モードで実行することができる。このようなジェスチャーがステップ５６２において検出されない場合、以下で説明するステップ５６８から５８８までによって、通常のＭＳＭＤ動作を行うことができる。

[00151] いずれのイベントでも、ステップ５６８において、キャプチャー・デバイスおよび／または計算環境は、上半身位置情報を受け取り、ステップ５７０において、頭部、肩、および腕の位置を肢識別エンジン１９２によって前述のように計算することができる。ステップ５７４において、本システムは、脚部制御モードで動作しているか否かチェックする。脚部制御モードで動作している場合、計算環境１２は、ユーザーの右腕および／または左腕における腕関節を処理して、ユーザーの左および／または右脚部の脚部関節の３−Ｄ実世界位置を求めることができる。

[00152] これは多数の方法で行うことができる。一実施形態では、実空間におけるユーザーの腕の動きを画面上のアバター１９の脚部にマッピングすることができ、またそうでなければ、脚部入力データーとして解釈することができる。例えば、既定の数学的関数によって、ある範囲の動き(motion)にわたって、肩関節をユーザーの臀部にマッピングすることもできる。既定の数学的関数によって、ある範囲の動き(motion)にわたって、ユーザーの肘をユーザーの膝にマッピングすることもできる（肘は、膝が下肢を動かすのとは逆方向に下腕を動かすという事実を考慮に入れる）。そして、数学的関数によってある範囲の動き(motion)にわたって、ユーザーの手首をユーザーの踝にマッピングすることもできる。

[00153] このようなマッピングを行うとき、ユーザーは、例えば、ユーザーの脚部が歩いているまたは走っているという印象を醸し出すような方法で、彼の肩、肘、および手首を一緒に動かすとよい。他の例として、車椅子のユーザーが、彼の腕を動かすことによって、ボールを蹴る行為を真似することもできる。本システムは、総体レベルの動きをアバターの骨格にマッピングし、アニメーションの配合を用いて、それが足の動きであるかのように見えることを可能にすることができる。尚、ユーザーは、以上のステップを用いずに、または代わりのステップによって、正常に動く肢を正常に動かない肢と交換してもよいことは言うまでもない。

[00154] 実施形態では、脚部制御モードにある間ユーザーの腕の一方がアバターの脚部の一方を制御しつつ、ユーザーの他方の腕は、アバターの腕の１本を制御しているのでもよい。このような実施形態では、ユーザーによって制御されないアバターの脚部は、単に些細な動きを、制御される脚部に対して行えばよい。つまり、ユーザーが彼の腕を動かし、左足の歩調と一致させると、アバターはこの左足の歩調を、対応する右足の歩調と共に、その通りに真似る。他の実施形態では、脚部制御モードにある間、ユーザーはアバターの両脚部を、実世界における彼の両腕で制御することもできる。尚、他の実施形態では、アバターの脚部を制御するように腕関節の位置を脚部関節に対して処理するためには、種々の他の方法を用いてもよいことは言うまでもない。

[00155] ステップ５８０において、関節位置（ステップ５７６において脚部制御モードで処理されたまたはされていない）を、ＧＰＵによるレンダリングのために、計算環境１２に供給する。アバターの脚部を制御することに加えて、ユーザーは脚部制御モードにあるときに脚部のジェスチャーと解釈することができる、ある種の腕のジェスチャーも行うことができる。ステップ５８２において、本システムは、認識された脚部ジェスチャーの有無をチェックする。この脚部のジェスチャーは、実世界におけるユーザーの脚部によって（脚部制御モードにないとき）行うことができ、またはユーザーの腕によって（脚部制御モードにあるとき）行うこともできる。このようなジェスチャーがステップ５８２においてジェスチャー認識エンジンによって認識されると、ステップ５８４においてそれに応答する動作が行われる。

[00156] ステップ５８２において特定の脚部のジェスチャーが認識されてもされなくても、本システムは次にステップ５８６において、脚部制御モードを終了させるように既定された何らかのジェスチャーが行われたか否かチェックする。行われた場合、本システムはステップ５８８において脚部制御モードから抜け出し、ステップ５６２に戻って本処理を再度開始する。一方、脚部制御モードを終了させるジェスチャーがステップ５８６において検出されない場合、ステップ５８８を飛ばして、本システムはステップ５６２に戻り以上のステップを繰り返す。

[00157] 図１７Ａは、ターゲット認識、分析、および追跡システムにおいてユーザーの１つ以上の位置および運動(motion)を解釈するために用いることができる計算環境の一実施形態例を示す。図１Ａから図２に関して先に説明した計算環境１２のような計算環境は、ゲーミング・コンソールのようなマルチメディア・コンソール６００とすることができる。図１７Ａに示すように、マルチメディア・コンソール６００は、レベル１キャッシュ６０２、レベル２キャッシュ６０４、およびフラッシュＲＯＭ（リード・オンリー・メモリー）６０６を有する中央演算装置（ＣＰＵ）６０１を有する。レベル１キャッシュ６０２およびレベル２キャッシュ６０４は、一時的にデーターを格納し、こうしてメモリー・アクセス・サイクルの回数を減らすことによって、処理速度およびスループットを向上させる。ＣＰＵ６０１は、１つよりも多いコアを設けることができ、したがって追加のレベル１およびレベル２キャッシュ６０２および６０４を有することもできる。フラッシュＲＯＭ６０６は、実行可能コードを格納することができる。実行可能コードは、マルチメディア・コンソール６００の電源をオンにしたときに、ブート・プロセスの初期段階中にロードされる。

[00158] グラフィクス処理ユニット（ＧＰＵ）６０８およびビデオ・エンコーダー／ビデオ・コデック（コーダー／デコーダー）６１４は、高速および高分解能グラフィクス処理のためにビデオ処理パイプラインを形成する。データーは、バスを介して、ＧＰＵ６０８からビデオ・エンコーダー／ビデオ・コデック６１４に伝達される。ビデオ処理パイプラインは、テレビジョンまたは他のディスプレイに送信するために、データーをＡ／Ｖ（オーディオ／ビデオ）ポート１４０に出力する。メモリー・コントローラー６１０がＧＰＵ６０８に接続されており、限定ではなく、ＲＡＭのような種々のタイプのメモリー６１２にプロセッサーがアクセスし易くなっている。

[00159] マルチメディア・コンソール６００は、Ｉ／Ｏコントローラー６２０、システム管理コントローラー６２２、オーディオ処理ユニット６２３、ネットワーク・インターフェース・コントローラー６２４、第１ＵＳＢホスト・コントローラー６２６、第２ＵＳＢコントローラー６２８、およびフロント・パネルＩ／Ｏサブアセンブリ６３０を含む。これらは、好ましくは、モジュール６１８上に実装されている。ＵＳＢコントローラー６２６および６２８は、周辺コントローラー６４２（１）〜６４２（２）、ワイヤレス・アダプター６４８、および外部メモリー・デバイス６４６（例えば、フラッシュ・メモリー、外部ＣＤ／ＤＶＤ ＲＯＭドライブ、リムーバブル媒体等）のためのホストとしての役割を果たす。ネットワーク・インターフェース６２４および／またはワイヤレス・アダプター６４８は、ネットワーク（例えば、インターネット、ホーム・ネットワーク等）へのアクセスを与え、イーサネット（登録商標）・カード、モデム、Bluetooth（登録商標）モジュール、ケーブル・モデム等を含む広範囲にわたる種々の有線またはワイヤレス・アダプター・コンポーネントの内いずれでもよい。

[00160] システム・メモリー６４３は、ブート・プロセスの間にロードされるアプリケーション・データーを格納するために設けられている。メディア・ドライブ６４４が設けられており、ＤＶＤ／ＣＤドライブ、ハード・ドライブ、またはその他のリムーバブル・メディア・ドライブを備えることができる。メディア・ドライブ６４４は、マルチメディア・コンソール６００の内部にあっても外部にあってもよい。アプリケーション・データーには、マルチメディア・コンソール６００が実行、再生等のために、メディア・ドライブ６４４を通じて、アクセスすることができる。メディア・ドライブ６４４は、シリアルＡＴＡバスまたはその他の高速接続（例えば、IEEE1394）のようなバスを介して、Ｉ／Ｏコントローラー６２０に接続されている。

[00161] システム管理コントローラー６２２は、メディア・コンソール６００が利用可能であることを確保することに関する種々のサービス機能を提供する。オーディオ処理ユニット６２３およびオーディオ・コデック６３２は、高忠実度およびステレオ処理を行う、対応のオーディオ処理パイプラインを形成する。オーディオ・データーは、通信リンクを介して、オーディオ処理ユニット６２３とオーディオ・コデック６３２との間で搬送される。オーディオ処理パイプラインは、外部オーディオ・プレーヤーまたはオーディオ処理能力を有するデバイスによる再生のために、データーをＡ／Ｖポート６４０に出力する。

[00162] フロント・パネルＩ／Ｏサブアセンブリ６３０は、電力ボタン６５０およびイジェクト・ボタン６５２の機能をサポートするだけでなく、あらゆるＬＥＤ（発光ダイオード）またはマルチメディア・コンソール６００の外面上に露出されるその他のインディケーターもサポートする。システム電源モジュール６３６は、マルチメディア・コンソール６００のコンポーネントに電力を供給する。ファン６３８は、マルチメディア・コンソール６００内部にある回路を冷却する。

[00163] ＣＰＵ６０１、ＧＰＵ６０８、メモリー・コントローラー６１０、およびマルチメディア・コンソール６００内部にある種々のその他のコンポーネントは、１系統以上のバスを介して相互接続されている。これらのバスには、シリアルおよびパラレル・バス、メモリー・バス、周辺バス、ならびに種々のバス・アーキテクチャの内いずれかを用いるプロセッサー・バスまたはローカル・バスが含まれる。一例として、このようなアーキテクチャーは、ペリフェラル・コンポーネント相互接続（ＰＣＩ）バス、PCI-Expressバス等を含むことができる。

[00164] マルチメディア・コンソール６００の電源をオンにすると、システム・メモリー６４３からメモリー６１２および／またはキャッシュ６０２、６０４にアプリケーション・データーがロードされ、ＣＰＵ６０１において実行することができる。アプリケーションは、グラフィカル・ユーザー・インターフェースを提示することができる。このグラフィカル・ユーザー・インターフェースは、マルチメディア・コンソール６００において利用可能な異なるタイプのメディアにナビゲートするときに、一貫性のあるユーザー体験を提供する。動作において、アプリケーションおよび／またはメディア・ドライブ６４４内に収容されている他のメディアをメディア・ドライブ６４４から起動または再生して、マルチメディア・コンソール６００に追加の機能を設けることもできる。

[00165] マルチメディア・コンソール６００は、単にシステムをテレビジョンまたはその他のディスプレイに接続することによって、単体システムとして動作させることができる。この単体モードでは、マルチメディア・コンソール６００は、１人以上のユーザーがシステムと対話処理を行い、ムービーを見ること、または音楽を聞くことを可能にする。しかしながら、ネットワーク・インターフェース６２４またはワイヤレス・アダプター６４８によって利用可能となるブロードバンド接続機能を統合することにより、マルチメディア・コンソール６００を更に大きなネットワーク・コミュニティにおける関与個体(participant)として動作させることもできる。

[00166] マルチメディア・コンソール６００の電源をオンにすると、マルチメディア・コンソールのオペレーティング・システムによって、設定されている量のハードウェア・リソースがシステムの使用のために確保される。これらのリソースは、メモリー（例えば、１６ＭＢ）、ＣＰＵおよびＧＰＵサイクル（例えば、５％）、ネットワーク接続帯域幅（例えば、８ｋｂｓ）等の確保を含むことができる。これらのリソースは、システムのブート時に確保されるので、確保されたリソースは、アプリケーションの視点からは存在しない。

[00167] 特に、メモリーの確保は、起動カーネル、コンカレント・システム・アプリケーション、およびドライバーを収容できる程に十分大きいことが好ましい。確保されたＣＰＵ使用枠(usage)がシステム・アプリケーションによって用いられない場合、アイドルのスレッドがいずれかの未使用サイクルを消費するように、ＣＰＵの確保は一定であることが好ましい。

[00168] ＧＰＵの確保に関して、ＧＰＵ割り込みを用いてポップアップをオーバーレイにレンダリングするコードをスケジューリングすることによって、システム・アプリケーション（例えば、ポップアップ）が生成する軽量メッセージ(lightweight message)を表示する。オーバーレイに用いられるメモリー量は、オーバーレイのエリア・サイズによって異なり、オーバーレイは画面の解像度に合わせて拡縮小する(scale)ことが好ましい。コンカレント・システム・アプリケーションによってフル・ユーザー・インターフェースが用いられる場合、アプリケーションの解像度とは独立した解像度を用いることが好ましい。周波数を変更しＴＶの同期を取り直す必要性をなくすように、この解像度を設定するためにスケーラー(scaler)を用いるとよい。

[00169] マルチメディア・コンソール６００がブートして、システム・リソースが確保された後、コンカレント・システム・アプリケーションが実行してシステム機能を提供する。システム機能は、前述の確保したシステム・リソースの内部で実行する１組のシステム・アプリケーションの中にカプセル化されている。オペレーティング・システム・カーネルは、システム・アプリケーション・スレッドと、ゲーミング・アプリケーション・スレッドとの間でスレッドを識別する。一貫したシステム・リソース・ビューをアプリケーションに提供するために、システム・アプリケーションは、所定の時点および間隔でＣＰＵ６０１において実行するようにスケジューリングされていることが好ましい。このスケジューリングは、コンソール上で実行しているゲーミング・アプリケーションに対するキャッシュ破壊(disruption)を最少に抑えるためにある。

[00170] コンカレント・システム・アプリケーションがオーディオを必要とする場合、時間に敏感であるため、ゲーミング・アプリケーションには非同期にオーディオ処理をスケジューリングする。マルチメディア・コンソール・アプリケーション・マネージャー（以下で説明する）は、システム・アプリケーションがアクティブのとき、ゲーミング・アプリケーションのオーディオ・レベル（例えば、無音化、減衰）を制御する。

[00171] 入力デバイス（例えば、コントローラー６４２（１）および６４２（２））は、ゲーミング・アプリケーションおよびシステム・アプリケーションによって共有される。入力デバイスは、確保されるリソースではないが、各々がデバイスのフォーカス(focus)を有するように、システム・アプリケーションとゲーミング・アプリケーションとの間で切り換えられる。アプリケーション・マネージャーは、ゲーミング・アプリケーションの知識を用いずに入力ストリームの切換を制御し、ドライバーはフォーカス・スイッチ(focus switches)に関する状態情報を維持する。カメラ２６、２８およびキャプチャー・システム２０は、コンソール６００の追加の入力デバイスを定めることができる。

[00172] 図１７Ｂは、ターゲット認識、分析、および追跡システムにおいて１つ以上の位置および動き(motion)を解釈するために用いられる、計算環境７２０の他の実施形態例を示す。計算環境７２０は、図１Ａから図２に示した計算環境１２であってもよい。計算システム環境７２０は、適した計算環境の一例に過ぎず、本明細書において開示される主題の使用範囲または機能に関して、いかなる限定を示唆する意図もない。また、計算環境７２０が、本明細書において例示されるいずれの１つのコンポーネントまたはコンポーネントの組み合わせに関して何らかの依存性または要件を有するように解釈してはならない。実施形態によっては、図示する種々の計算エレメントが、本開示の特定の態様をインスタンス化するように構成されている回路を含むこともあり得る。例えば、本開示において用いられる回路という用語は、ファームウェアまたはスイッチによって機能（１つまたは複数）を実行するように構成されている特殊ハードウェア・コンポーネントを含むことができる。別の実施形態例では、回路という用語は、機能（１つまたは複数）を実行するために動作可能なロジックを具体化するソフトウェア命令によって構成される汎用演算装置、メモリー等を含むことができる。回路がハードウェアおよびソフトウェアの組み合わせを含む実施形態例では、実装者(implementer)は、ロジックを具体化するソース・コードを書くことができ、ソース・コードを機械読み取り可能コードにコンパイルすることができ、この機械読み取り可能コードを汎用演算装置によって処理することができる。技術的現状では、ハードウェア、ソフトウェア、またはハードウェア／ソフトウェアの組み合わせの間には殆ど差がないというところまで発展していることを当業者は認めることができるので、特定の機能を実行するためにハードウェアまたはソフトウェアのどちらを選択するかということは、実装者に委ねられた設計選択事項である。更に具体的には、ソフトウェア・プロセスを等価のハードウェア構造に変換することができ、更にハードウェア構造自体を等価のソフトウェア・プロセスに変換することができることを、当業者は認めることができる。つまり、ハードウェアの実施態様およびソフトウェアの実施態様のどちらを選択するかということは、実装者に委ねられた設計選択事項の１つである。

[00173] 図１７Ｂにおいて、計算環境７２０は、コンピューター７４１を含む。コンピューター７４１は、通例、種々のコンピューター読み取り可能媒体を含む。コンピューター読み取り可能媒体は、コンピューター７４１がアクセス可能な入手可能な媒体であればいずれでも可能であり、揮発性および不揮発性の双方、リムーバブル、および非リムーバブル媒体を含む。システム・メモリー７２２は、リード・オンリー・メモリー（ＲＯＭ）７２３およびランダム・アクセス・メモリー（ＲＡＭ）７６０のような揮発性および／または不揮発性メモリーの形態で、コンピューター記憶媒体を含む。基本入出力システム７２４（ＢＩＯＳ）は、起動中のように、コンピューター７４１内のエレメント間におけるデーター転送を補助する基本的なルーチンを含み、通例ＲＯＭ７２３内に格納されている。ＲＡＭ７６０は、通例、演算装置７５９が直ちにアクセス可能であるデーターおよび／またはプログラム・モジュール、または現在これによって処理されているデーターおよび／またはプログラム・モジュールを収容する。一例として、そして限定ではなく、図１７Ｂは、オペレーティング・システム７２５、アプリケーション・プログラム７２６、その他のプログラム・モジュール７２７、およびプログラム・データー７２８を示す。更に、図１７Ｂは、グラフィクス・プロセッサー・ユニット（ＧＰＵ）７２９も含む。グラフィクス・プロセッサー・ユニット７２９は、高速および高解像度グラフィクス処理および格納のために、付随するビデオ・メモリー７３０を有する。ＧＰＵ７２９は、グラフィクス・インターフェース７３１を介して、システム・バス７２１に接続することができる。

[00174] また、コンピューター７４１は、その他のリムーバブル／非リムーバブル揮発性／不揮発性コンピューター記憶媒体も含むことができる。一例にすぎないが、図１７Ｂは、非リムーバブル不揮発性磁気媒体からの読み取りおよびこれへの書き込みを行なうハード・ディスク・ドライブ７３８、リムーバブル不揮発性磁気ディスク７５４からの読み取りおよびこれへの書き込みを行なう磁気ディスク・ドライブ７３９、ならびにＣＤ ＲＯＭまたはその他の光媒体のようなリムーバブル不揮発性光ディスク７５３からの読み取りおよびこれへの書き込みを行なう光ディスク・ドライブ７４０を示す。動作環境の一例において使用可能なその他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピューター記憶媒体には、限定する訳ではないが、磁気テープ・カセット、フラッシュ・メモリー・カード、ディジタル・バーサタイル・ディスク、ディジタル・ビデオ・テープ、ソリッド・ステートＲＡＭ、ソリッド・ステートＲＯＭ等が含まれる。ハード・ディスク・ドライブ７３８は、通例、インターフェース７３４のような非リムーバブル・メモリー・インターフェースを介してシステム・バス７２１に接続され、磁気ディスク・ドライブ７３９および光ディスク・ドライブ７４０は、通例、インターフェース７３５のようなリムーバブル・メモリー・インターフェースによって、システム・バス７２１に接続する。

[00175] 先に論じ図１７Ｂに示すドライブおよびそれらと関連のあるコンピューター記憶媒体は、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、およびコンピューター７４１のその他のデーターを格納する。図１７Ｂでは、例えば、ハード・ディスク・ドライブ７３８は、オペレーティング・システム７５８、アプリケーション・プログラム７５７、他のプログラム・モジュール７５６、およびプログラム・データー７５５を格納するように示されている。尚、これらの構成要素は、オペレーティング・システム７２５、アプリケーション・プログラム７２６、他のプログラム・モジュール７２７、およびプログラム・データー７２８と同じでも異なっていても可能であることを注記しておく。オペレーティング・システム７５８、アプリケーション・プログラム７５７、他のプログラム・モジュール７５６、およびプログラム・データー７５５は、ここで、少なくともこれらが異なるコピーであることを示すために、異なる番号が与えられている。ユーザーは、キーボード７５１、および一般にマウス、トラックボールまたはタッチ・パッドと呼ばれているポインティング・デバイス７５２のような入力デバイスによって、コマンドおよび情報をコンピューター７４１に入力することができる。他の入力デバイス（図示せず）には、マイクロフォン、ジョイスティック、ゲーム・パッド、衛星ディッシュ、スキャナー等を含むことができる。これらおよびその他の入力デバイスは、多くの場合、ユーザー入力インターフェース７３６を介して、演算装置７５９に接続されている。ユーザー入力インターフェース７３６は、システム・バスに結合されているが、パラレル・ポート、ゲーム・ポート、またはユニバーサル・シリアル・バス（ＵＳＢ）によって接続することも可能である。カメラ２６、２８およびキャプチャー・デバイス２０は、コンソール７００の追加入力デバイスを定めることができる。モニター７４２またはその他のタイプの表示装置も、ビデオ・インターフェース７３２のようなインターフェースを介して、システム・バス７２１に接続されている。モニターに加えて、コンピューターは、スピーカー７４４およびプリンター７４３のような、その他の周辺出力装置も含むことができ、これらは出力周辺インターフェース７３３を通じて接続することができる。

[00176] コンピューター７４１は、リモート・コンピューター７４６のような１つ以上のリモート・コンピューターへの論理接続を用いて、ネットワーク環境において動作することも可能である。リモート・コンピューター７４６は、パーソナル・コンピューター、サーバー、ルータ、ネットワークＰＣ、ピア・デバイス、またはその他の共通ネットワーク・ノードとすることができ、通例、コンピューター７４１に関して先に説明したエレメントの多くまたは全てを含むが、図１７Ｂにはメモリー記憶装置７４７のみを示す。図１７Ｂに示す論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）７４５およびワイド・エリア・ネットワーク（ＷＡＮ）７４９を含むが、他のネットワークも含むことができる。このようなネットワーク環境は、事務所、企業規模のコンピューター・ネットワーク、イントラネットおよびインターネットにおいては一般的である。

[00177] ＬＡＮネットワーク環境で用いる場合、コンピューター７４１は、ネットワーク・インターフェースまたはアダプター７３７を介してＬＡＮ７４５に接続する。ＷＡＮネットワーク環境で用いる場合、コンピューター７４１は、通例、モデム７５０、またはインターネットのようなＷＡＮ７４９を通じて通信を設定するその他の手段を含む。モデム７５０は、内蔵でも外付けでもよく、ユーザー入力インターフェース７３６またはその他の適切な機構を介してシステム・バス７２１に接続することができる。ネットワーク環境では、コンピューター７４１に関係付けて図示したプログラム・モジュール、またはその一部は、リモート・メモリー記憶装置に格納することもできる。一例として、そして限定ではなく、図１７Ｂは、リモート・アプリケーション・プログラム７４８がメモリー・デバイス７４７に存在するものとして示している。尚、図示のネットワーク接続は一例であり、コンピューター間で通信リンクを設定する他の手段も使用可能であることは認められよう。

[00178] 実施形態では、本技術は、キャプチャー・デバイスによって取り込まれた画像データーから、視野の中にいるユーザーを識別するシステムに関し、このシステムは、ステートレスな身体部分提案システムで構成されている。

[00179] 実施形態では、ステートレス身体部分提案システムは、身体部分提案および／または骨格仮説を生成する。
[00180] 実施形態では、ステートレス身体部分提案システムは、頭部三角形についての身体部分提案、手の提案、および／または腕の仮説を生成する。

[00181] 実施形態では、ステートレス身体部分提案システムは、原型および重心によって動作することができる。
[00182] 実施形態では、本技術は、キャプチャー・デバイスによって取り込まれた画像データーから、視野の中にいるユーザーを識別するシステムに関し、このシステムはステートフル身体部分提案システムで構成されている。

[00183] 実施形態では、ステートレス身体部分提案システムは、マグネティズムによって動作することができる。
[00184] 実施形態では、ステートレス身体部分提案システムは、マグネティズムを用いて、身体部分提案および／または骨格仮説を生成する。

[00185] 実施形態では、ステートレス身体部分提案システムは、マグネティズムを用いて、頭部三角形についての身体部分提案、手の提案、および／または腕の仮説を生成する。

[00186] 実施形態では、本技術は、キャプチャー・デバイスによって取り込まれた画像データーから、視野の中にいるユーザーを識別するシステムに関し、このシステムは、身体部分提案システムと、この身体部分提案システムによって生成された提案の折り合いをつける骨格解明システムとで構成されている。

[00187] 実施形態では、骨格解明システムは、１つ以上のコスト関数、またはロバストな採点検査を採用する。身体部分提案システムによって生成された提案の折り合いをつけて候補を求める。

[00188] 実施形態では、骨格解明システムは、多数の身体部分提案および／または骨格仮説を用いる。
[00189] 実施形態では、骨格解明システムは、トレースおよび／または突出サンプルを用いて、身体部分提案システムによって生成された候補提案、および／または候補提案の組み合わせを評価し折り合いをつける。

[00190] 実施形態では、トレース・サンプルは、候補身体部分および／または骨格仮説が正しい場合、１つ以上の候補身体部分および／または骨格仮説の中にあるサンプルに対して検出された深度値が、期待通りであるか否か検査する。

[00191] 実施形態では、突出サンプルは、候補身体部分および／または骨格仮説が正しい場合、１つ以上の候補身体部分および／または骨格仮説の輪郭の外側にあるサンプルについて検出された深度値が、期待通りであるか否か検査する。

[00192] 実施形態では、トレースおよび／または突出サンプルは、身体部分のいずれかおよび全てに関する仮説、または骨格仮説全体に関する仮説も格納するために用いることができる。

[00193] 実施形態では、骨格解明システムは、身体部分が動いているか否か判断するための検査を用いる。
[00194] 実施形態では、手が動いているか否か判断するための検査は、身体部分の動き(motion)に対応するｘ、ｙ、および／またはｚ方向における画素の動き(motion)を検出する。

[00195] 実施形態では、画素動き検査(pixel motion test)は、手の提案の動き(motion)を検出する。
[00196] 実施形態では、画素動き検査は、頭部、両腕、脚部、および両足の動き(motion)を検出する。

[00197] 実施形態では、画素の動きが主要な身体部分（手または頭部というような身体部分）の近くで検出されるまで、骨格は確認されない。
[00198] 実施形態では、主要な身体部分が経時的にやや滑らかな経路に従うことが観察されるまで、骨格は確認されない。

[00199] 実施形態では、骨格解明システムは、所与の骨格仮説が力学的に有効か否か判断する。
[00200] 実施形態では、骨格解明システムは、骨格仮説における１つ以上の関節が、予期される身体部分に対する関節回転限界を超えて回転したか否か判断する。

[00201] 実施形態では、本システムは、更に、手を厳格に求める技法も含み、骨格解明システムと共に、非常にロバストで、厳格に求められた手の位置を生成する。
[00202] 先の実施形態では、骨格解明システムは、最初に、頭部および肩関節に基づいて、プレーヤーを識別し、続いて両手および両肘の位置を特定する。他の実施形態では、骨格解明システムは、最初に、身体の関節のいずれかの部分集合においてプレーヤーを特定し、続いて他の身体の関節の位置を特定することもできる。

[00203] 更に、骨格解明システムによる身体部分の特定順序は、これまでに説明したものとは異なっていてもよい。例えば、胴体、臀部、手、または脚部というような、いずれかの身体部分を最初に解明し、以前のフレームからのプレーヤーに結び付けることもでき、その後、腕について先に説明した技法を用いて、しかし他の身体部分に適用して、骨格の残りを解明することもできる。

[00204] 更に、骨格解明システムによる身体部分の特定順序は、動的であってもよい。言い換えると、最初に解明すべき身体部分のグループは、動的な条件によって異なってもよい。例えば、プレーヤーが横を向いて立っており、左腕がその身体の内最も明確に見える部分であるとすると、骨格解明システムは、その腕を用いて（頭部三角形の代わりに）プレーヤーを識別し、続いて骨格の他の部分および／または骨格全体を解明するのでもよい。

[00205] 実施形態では、本システムは、更に、手の先端の位置、およびその手の角度の双方を精度高く判断する方法を含む。
[00206] 以上の本発明のシステムについての詳細な説明は、例示および説明の目的で提示された。これは、網羅的であることも、開示された技術を開示された形態そのものに限定することを意図するのではない。多くの変更や変形が、以上の教示に照らして、可能である。記載した実施形態は、本技術の原理およびその実用的な用途を最良に説明し、それによって当業者が本技術を種々の実施形態において、そして個々の考えられる使用に適するような種々の変更と共に、最良に利用することを可能にするために選択されたのである。本発明のシステムの範囲は、本明細書に添付されている特許請求の範囲によって定義されることを意図している。

Claims (10)

1. 場面から位置情報を取り込むキャプチャー・デバイスに結合されている計算環境を備えているシステムにおいて、ジェスチャー認識方法であって、
   ａ）前記場面の中にいるユーザーから位置情報を受け取るステップであって、前記ユーザーが第１身体部分および第２身体部分を有する、ステップと、
   ｂ）前記第１身体部分からジェスチャーを認識するステップと、
   ｃ）前記第２身体部分によって行われたジェスチャーを無視するステップと、
   ｄ）前記ステップｂ）において認識した前記第１身体部分からの前記ジェスチャーと関連付けられた動作(action)を実行するステップと、
   を備えている、方法。
2. 請求項１記載の方法において、前記第２身体部分によって行われたジェスチャーを無視する前記ステップｃ）が、ジェスチャーが受け入れられる身体部分の定義を有するステップを含み、前記第２身体部分が、前記定義には含まれていない、方法。
3. 請求項１記載の方法において、前記第２身体部分によって行われたジェスチャーを無視する前記ステップｃ）が、前記第２身体部分から位置情報を受け取らないステップを含む、方法。
4. 請求項１記載の方法であって、更に、前記視野を複数のゾーンに区分するステップであって、前記第２身体部分によって行われたジェスチャーを無視するとき、前記第２身体部分が前記複数のゾーンの内第１ゾーンの中にある、ステップを備えており、更に、前記第２身体部分からの同じジェスチャーが前記複数のゾーンの内第２ゾーンにおいて行われたとき、このジェスチャーを認識し、これに応じて動作するステップを備えている、方法。
5. 場面から位置情報を取り込むキャプチャー・デバイスに結合されている計算環境を備えているシステムにおいて、ユーザーの身体部分を認識し追跡するステップであって、
   ａ）前記場面から位置情報を受け取ったステートレス身体部分提案システムから、身体部分の提案を入手するステップと、
   ｂ）ステートフル身体部分提案システムから身体部分の提案を入手するステップと、
   ｃ）骨格解明システムによって、前記候補身体部分の折り合いをつけて、全体的または部分的骨格を求めるステップと、
   を備えている、方法。
6. 請求項５記載の方法において、ステートレス機械学習身体部分提案システムから身体部分の提案を入手する前記ステップａ）が、前記ユーザーの頭部および肩についての身体部分の提案を、重心確率によって入手するステップを含む、方法。
7. 請求項５記載の方法において、ステートフル身体部分提案システムから身体部分の提案を入手する前記ステップｂ）が、前記ユーザーの頭部および肩についての身体部分の提案を、マグネティズムおよび過去のフレームからの存続の内少なくとも１つによって入手するステップを含む、方法。
8. 請求項５記載の方法において、前記候補身体部分の折り合いをつけて、全体的または部分的骨格を求める前記ステップが、最大のサポートを有する仮説の特定を可能にする１つ以上の採点検査を実行するステップを含む、方法。
9. 請求項８記載の方法において、第１グループの関節を特定する前記ステップｂ）が、更に、
   ｄ）実際のプレーヤーに対応する候補頭部および肩の提案を特定するステップと、
   ｅ）前記ステップｄ）における各候補の各肩に属する潜在的な可能性がある手の提案を評価するステップと、
   ｆ）前記ステップｅ）における手の提案を、前記ステップｄ）における肩の提案と結び付ける肘の提案を評価するステップと、
   を備えている、方法。
10. 少なくとも１つの麻痺した身体部分の使用が少なくとも制限されるユーザーの身体部分を認識し追跡する方法を実行するように、プロセッサーをプログラミングすることができるコンピューター読み取り可能記憶媒体であって、前記方法が、
    ａ）前記少なくとも1つの麻痺した身体部分の識別の指示を、前記ユーザーから受け取るステップと、
    ｂ）前記ユーザーの第１グループの関節を特定するステップであって、前記関節が前記少なくとも１つの麻痺した身体部分の中に含まれない、ステップと、
    ｃ）前記第１グループの関節において、関節の位置を特定するステップと、
    ｄ）前記ステップｃ）において特定した前記関節の位置に基づいて、動作を実行するステップと、
    を備えている、コンピューター読み取り可能記憶媒体。