データ処理の制御
ビデオカメラから連続する画像を受信するよう構成されるデータ処理装置であって、該データ処理装置の制御機能と対応づけられている画像領域内の選択されたポイントについて画像間動作を検出するための手段と、該画像間動作について画像領域において検出が行われた場合に制御機能を実行するための手段と、を備え、該検出手段は、ｍ個の連続する一群の画像に亘る画像領域内のポイントについて累積的画像間動作を検出することによって、画像間動作を検出するよう構成され、ここでｍは少なくとも３であることを特徴とするデータ処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ処理の制御に関する。特殊な例として、ビデオゲーム処理操作の制御に関連するが、本発明はより一般的に他の種類のデータ処理にも適用するものである。
【背景技術】
【０００２】
従来のビデオゲーム機において、ユーザーは、ビデオモニターまたはテレビ画面上のゲームを見て、手持ち式のキーパッドまたはジョイスティックを使用してゲームの操作を制御する。ソニー（Sony、登録商標）プレイステーション（PlayStation、登録商標）２等のゲーム機については、手持ち式コントローラが、２本のジョイスティックと数個のユーザー操作キーを提供するものがあり、これは、ゲーム内でイベントが生じた場合、ユーザーに対し触覚性のフィードバックを提供するための振動エレメントを伴う。
【０００３】
これらのゲーム機は、ビデオカメラを利用できることはすでに提案されている。これによって、ユーザーの画像をゲームシナリオの中に出現させることが可能となり、あるいは、空中で「ワンド」を振る等のユーザーのアクションを、ゲーム内のキャラクターが対応するアクションをするように変換できる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
この構成において不都合な点は、ゲーム機能間で切り換えを行う場合、さらに一般的にゲーム機の操作を制御する場合、手持ち式のコントローラを操作しなければならないということである。
【０００５】
制御について今まで出された提案は、一般的にユーザーが特殊な手袋をはめるようにするもので、特に、取り込まれた画像内で手袋をした手により検知を行うという特徴を有するものである。映画「マイノリティ・レポート」の中で、フィクションの例示が見られる。
【課題を解決するための手段】
【０００６】
本発明のさまざまな各態様および特徴は、添付の請求の範囲において定義される。従属クレームによる特徴は、必要に応じて独立クレームの特徴と組み合わせることが可能であり、ただ単にクレーム内で明確に列記されている特徴だけではない。
【０００７】
本発明の第一の態様は、ビデオカメラから連続した画像を受信するよう構成されたデータ処理装置を提供する。当該装置は、
データ処理装置の制御機能と対応づけられている画像領域内の選択されたポイントについて画像間動作を検出するための手段と、
該画像間動作について画像領域において検出が行われた場合、制御を実行するための手段と、を備え、
該検出手段は、ｍ個の連続する一群の画像に亘る画像領域内のポイントについて累積的画像間動作を検出することによって画像間動作を検出するよう構成され、ここでｍは少なくとも３であることを特徴とする。
【０００８】
本発明の別の態様は、次のステップから成るデータ処理方法を提供する。すなわち、
ビデオカメラから、連続した取り込まれた画像を受信するステップと、
データ処理装置の制御機能と対応づけられている画像領域内にある、選択されたポイントについて画像間動作を検出するステップと、
画像間動作が画像領域において検出された場合に制御機能を実行するステップと、を備え、
該検出ステップは、ｍ個の連続する一群の画像に亘る画像領域内のポイントについて累積的画像間動作を検出することによって、画像間動作を検出するよう構成され、ここでｍは少なくとも３であることを特徴とする。
【０００９】
本発明の別の態様は、上記の方法を実行するためのプログラムコードを有するコンピュータ・ソフトウェアを提供する。当該コンピュータ・ソフトウェアは、伝送媒体または記憶媒体等の準備媒体により提供されることが好ましい。
【００１０】
本発明のさらなる個々の態様および特徴は、添付の請求の範囲において定義される。明示されない場合であっても、従属クレームの特徴は、さまざまに異なる独立クレームに対して適用される。
【発明を実施するための最良の形態】
【００１１】
以下、例証のみを目的として、添付の図面を参照しながら本発明の実施例について説明する。
【００１２】
図１は、プレイステーション２の全体的なシステムアーキテクチャを概略的に示すものである。システム・ユニット１０は、システム・ユニットに接続可能なさまざまな周辺デバイスを備える。
【００１３】
システム・ユニット１０は、エモーション・エンジン１００と、グラフィックス・シンセサイザ２００と、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）を有するサウンドプロセッサ・ユニット３００と、読み出し専用メモリ（ＲＯＭ）４００と、コンパクトディスク（ＣＤ）およびデジタル多用途ディスク（ＤＶＤ）リーダ４５０と、ランバス・ダイナミックランダムアクセスメモリ（ＲＤＲＡＭ）ユニット５００と、専用ＲＡＭ７５０を有する入出力プロセッサ（ＩＯＰ）７００とを備える。（任意の）外付けハードディスクドライブ（ＨＤＤ）８００を接続する場合もある。
【００１４】
入出力プロセッサ７００は、２本のユニバーサル・シリアル・バス（ＵＳＢ）ポート７１５およびｉＬｉｎｋまたはＩＥＥＥ１３９４ポート（ｉＬｉｎｋは、株式会社ソニーがＩＥＥＥ１３９４標準を実現したもの）を有する。ＩＯＰ７００は、ＵＳＢ、ｉＬｉｎｋ、およびゲームコントローラのデータトラフィックのすべてを取り扱う。例えば、ユーザーがゲームをしているときに、ＩＯＰ７００はゲームコントローラからデータを受信し、このデータをエモーション・エンジン１００へと送りだし、エモーション・エンジンは、それに従ってゲームの現在の状況を更新する。ＩＯＰ７００は、迅速なデータ転送速度を容易に実現するダイレクト・メモリ・アクセス（ＤＭＡ）アーキテクチャを有する。ＤＭＡは、ＣＰＵを通過させずにメインメモリからデバイスへデータ転送を行う。ＵＳＢインターフェースは、オープンホスト・コントローラ・インターフェース（ＯＨＣＩ）と互換性があり、１．５Ｍｂｐｓから１２Ｍｂｐｓまでのデータ転送速度を処理できる。これらのインターフェースが装備されているということは、つまり、プレイステーション２は、ビデオカセット、レコーダー（ＶＣＲｓ）、デジタルカメラ、セットトップボックス、プリンタ、キーボード、マウスおよびジョイスティック等の周辺デバイスと潜在的に互換性があることを意味する。
【００１５】
通常、ＵＳＢポート７１５に接続している周辺デバイスとのデータ通信が円滑に行われるように、デバイスドライバ等の適切なソフトウェアを備えなければならない。デバイスドライバ技術は大変によく知られているので、ここで詳細は記載しないが、当業者であれば、ここに記載する実施例において、デバイスドライバまたは類似のソフトウェア・インターフェースが必要であると認識していることはいうまでもない。
【００１６】
本実施例において、対応するマイクロフォン７３５とＬＥＤインジケータ７４０が装備されたビデオカメラ７３０がＵＳＢポートに接続されている。様々なタイプのビデオカメラを使用できるが、ビデオカメラ７３５として特にふさわしいタイプは、いわゆる「ウェブカム」である。すなわちこれは、単一の電荷結合素子（ＣＣＤ）エレメントに基づく中分解能カメラであって、基本ハードウェアをベースとするリアルタイムデータ圧縮およびエンコーディング構成を含んでいるので、圧縮ビデオオーディオデータが、例えば画像内部をベースとするＭＰＥＧ（モーション・ピクチャ・エキスパート・グループ）標準等の適切なフォーマットでカメラ７３０からＵＳＢポート７１５へと送信され、プレイステーション２システム・ユニット１０においてデコーディングされる。カメラＬＥＤインジケータ７４０は、システム・ユニット１０とのＵＳＢデータ接続を介して制御データを受信し、このような制御データに応答して点灯するように構成される。
【００１７】
ＵＳＢポートとは別の、２本の他のポート７０５、７１０は、ゲーム関連の情報を格納するための専用不揮発性ＲＡＭメモリーカード７２０、手持ち式ゲームコントローラ７２５、または、例えばダンス・マット等の手持ち式コントローラに似たようなデバイス（図示せず）の接続を可能とする専用ソケットである。
【００１８】
エモーション・エンジン１００は、１２８ビット中央演算処理装置（ＣＰＵ）であり、特にゲームアプリケーション用の三次元（３Ｄ）グラフィックスを効果的にシミュレーションするために設計されたものである。エモーション・エンジンの構成要素は、データバス、キャッシュメモリ、およびレジスタを含み、いずれも１２８ビットである。これによって、大容量マルチメディアデータの迅速な処理を容易にする。これと比較すると、従来のＰＣは、基本６４ビットのデータ構造を有する。プレイステーション２の浮動小数点演算性能は、６．２ＧＦＬＯＰｓである。エモーション・エンジンはまた、ＭＰＥＧ２デコーダ回路を備え、３ＤグラフィックスデータとＤＶＤデータの同時処理を可能にする。エモーション・エンジンは、数学的変換およびトランスレーションを含む幾何学的計算を実行し、更に、例えば２つのオブジェクト間の摩擦の算出などのシミュレーションオブジェクトの物理的過程に関連する計算を行う。これによって、その次にグラフィックス・シンセサイザ２００によって利用される画像レンダリングコマンドのシーケンスを作成される。画像レンダリングコマンドは、表示リスト形式で出力される。表示リストとは、描画コマンドのシーケンスであり、グラフィックス・シンセサイザに対して、どの初期グラフィックオブジェクト（例えば、点、線、三角形、スプライトなど）を画面上に描くか、および、どの座標に描くかを指示する。このように、典型的な表示リストは、頂点を描くためのコマンド、ポリゴン面に陰影をつけたり、ビットマップを描いたりする等のコマンドを含む。エモーション・エンジン１００は、非同期で複数の表示リストを作成できる。
【００１９】
グラフィックス・シンセサイザ２００は、エモーション・エンジン１００により作成された表示リストのレンダリングを行うビデオ・アクセラレータである。グラフィックス・シンセサイザ２００は、複数の表示リストを処理し、追跡記録し、管理するグラフィックス・インターフェースユニット（ＧＩＦ）を含む。グラフィックス・シンセサイザ２００のレンダリング機能は、選択肢となるいくつかの標準出力画像フォーマット、すなわちＮＴＳＣ／ＰＡＬ、高精細度デジタルテレビ、およびＶＥＳＡをサポートする画像データを作成できる。一般に、グラフィックス・システムのレンダリング能力は、それぞれがグラフィックス・プロセッサ内に位置するピクセルエンジンとビデオメモリの間のメモリ帯域幅により定められる。従来のグラフィックス・システムは、外付けのビデオ・ランダム・アクセス・メモリ（ＶＲＡＭ）を使用しており、これはオフチップバスを介してピクセルロジックに接続されるので、有効な帯域幅を制限する傾向にある。しかしながら、プレイステーション２のグラフィックス・シンセサイザ２００は、単一の高性能チップ上のピクセルロジックおよびビデオメモリを提供し、これによって、毎秒３８．４ギガバイトという比較的大きいメモリアクセス帯域幅を可能にする。グラフィックス・シンセサイザは、理論的に、毎秒７５００万ポリゴンの最高描画容量を達成することが可能である。テクスチャ、ライティング、およびトランスペアレンシー等のあらゆるエフェクトを用いた場合であっても、毎秒２０００万ポリゴンの持続速度で連続して描画することが可能である。従って、グラフィックス・シンセサイザ２００は、フィルム品質の画像を描画することができる。
【００２０】
サウンドプロセッサ・ユニット（ＳＰＵ）３００は、事実上、本システムのサウンドカードであり、デジタル多用途ディスク（ＤＶＤｓ）に使用されるサウンドフォーマットであるデジタル・シアター・サラウンド（ＤＴＳ、登録商標）サウンドやＡＣ−３（ドルビーデジタルとしても知られる）のような３Ｄデジタルサウンドを認識できる。
【００２１】
対応するスピーカー構成３１０を伴ったビデオモニターあるいはテレビ等のディスプレイおよびサウンド出力装置３０５は、グラフィックス・シンセサイザ２００およびサウンドプロセッッサ・ユニット３００に接続され、ビデオ信号およびオーディオ信号を受信する。
【００２２】
エモーション・エンジン１００をサポートするメインメモリは、ランバス（Rambus）社製のＲＤＲＡＭ（ランバス・ダイナミック・ランダムアクセスメモリ）モジュール５００である。このＲＤＲＡＭメモリー・サブシステムは、ＲＡＭ、ＲＡＭコントローラ、およびＲＡＭをエモーション・エンジン１００に接続するバスを備える。
【００２３】
図２は、図１のエモーション・エンジン１００のアーキテクチャを概略的に示したものである。エモーション・エンジン１００は、浮動小数点ユニット（ＦＰＵ）１０４と、中央演算処理装置（ＣＰＵ）コア１０２と、ベクトルユニット・ゼロ（ＶＵ０）１０６と、ベクトルユニット・ワン（ＶＵ１）１０８と、グラフィックス・インターフェース・ユニット（ＧＩＦ）１１０と、割り込みコントローラ（ＩＮＴＣ）１１２と、タイマーユニット１１４と、ダイレクト・メモリ・アクセス・コントローラ１１６と、画像データ処理ユニット（ＩＰＵ）１１６と、ダイナミック・ランダム・アクセスメモリ・コントローラ（ＤＲＡＭＣ）１２０と、サブバスインターフェース（ＳＩＦ）１２２と、を備え、これらの構成要素の全ては、１２８ビット・メインバス１２４を介して接続される。
【００２４】
ＣＰＵコア１０２は、３００ＭＨｚでクロック制御される１２８ビットプロセッサである。ＣＰＵコアは、ＤＲＡＭＣ１２０を介して、メインメモリの３２ＭＢにアクセスする。ＣＰＵコア１０２の命令セットは、さらにマルチメディア命令を追加したＭＩＰＳ IV ＲＩＳＣ命令のいくつかを有するＭＩＰＳ III ＲＩＳＣに基づくものである。ＭＩＰＳ IIIおよびIVは、ＭＩＰＳテクノロジー社が所有する縮小命令セットコンピュータ（ＲＩＳＣ）命令セットアーキテクチャである。標準の命令は、６４ビットのツーウェイ・スーパースカラであり、これは、二つの命令を同時に実行できることを意味する。一方、マルチメディア命令は、二本のパイプラインを介した１２８ビット命令を使用する。ＣＰＵコア１０２は、１６ＫＢの命令キャッシュ、８ＫＢのデータキャッシュ、および、ＣＰＵによるダイレクトプライベート使用のために確保されるキャッシュの一部である１６ＫＢのスクラッチパッドＲＡＭを備える。
【００２５】
ＦＰＵ１０４は、ＣＰＵコア１０２用の第一コプロセッサとしての機能を果たす。ベクトルユニット１０６は、第二のコプロセッサとして機能する。ＦＰＵ１０４は、浮動小数点積和演算器（ＦＭＡＣ）および浮動小数点除算演算器（ＦＤＩＶ）を備える。ＦＭＡＣおよびＦＤＩＶはどちらも３２ビット値で演算を行うので、演算が１２８ビット値（４つの３２ビット値から成る）で実行されると、４つのすべての部分において、並行して演算を実行できる。
【００２６】
ベクトルユニット１０６および１０８は、数値演算を実行するものであって、ベクトル方程式の乗算および加算で数値を求める場合に極めて高速に行うことができる、基本的に専門ＦＰＵである。これらは、加算と乗算演算のための浮動小数点積和演算器（ＦＭＡＣ）、および除算と平方根演算のための浮動小数点除算演算器（ＦＤＩＶ）を使用する。また、これらは、マイクロプログラムを格納するための内蔵メモリを有し、ベクトル・インターフェース・ユニット（ＶＩＦｓ）を介して、システムの残りの部分とのインターフェースをとる。ベクトルユニット・ゼロ１０６は、専用１２８ビットバス１２４を介してＣＰＵコア１０２に対するコプロセッサとして機能することが可能であり、従って、これは基本的に第二の専門ＦＰＵである。一方、ベクトルユニット・ワン１０８は、グラフィックス・シンセサイザ２００への専用バスを有するので、それによって、完全に分離したプロセッサであると考えられる。二台のベクトルユニットを搭載することによって、ソフトウェア開発者は、ＣＰＵの異なる部分間で作業を切り分けることが可能となり、これらのベクトルユニットはシリアルまたはパラレル接続のいずれかで使用できる。
【００２７】
ベクトルユニット・ゼロ１０６は、四つのＦＭＡＣＳと、一つのＦＤＩＶを備える。これは、コプロセッサ接続を介してＣＰＵコア１０２に接続している。また、データ用ベクトルユニットメモリ４Ｋｂと、命令用マイクロメモリ４Ｋｂを有する。ベクトルユニット・ゼロ１０６は、表示用画像に関連する物理計算を行うために有用である。これは主に、ＣＰＵコア１０２と共に非パターン化幾何学処理を実行する。
【００２８】
ベクトルユニット・ワン１０８は、五つのＦＭＡＣＳと二つのＦＤＩＶとを備える。これは、ＧＩＦユニット１１０へのダイレクトパスは有するが、ＣＰＵコア１０２へのダイレクトパスを有しない。また、データ用ベクトルユニットメモリ１６Ｋｂと、命令用マイクロメモリ１６Ｋｂを有する。ベクトルユニット・ワン１０８は、変換を実行する際に有用である。これは、主にパターン化された幾何学処理を実行して、作成された表示リストをＧＩＦ１１０に直接出力する。
【００２９】
ＧＩＦ１１０は、グラフィックス・シンセサイザ２００に対するインタフェースユニットである。表示リストパケットの最初のタグ指定に従って、データを変換し、相互に複数の転送を調整しながら、描画コマンドをグラフィックス・シンセサイザ２００に転送する。割り込みコントローラ（ＩＮＴＣ）１１２は、ＤＭＡＣ１１６を除いた周辺デバイスからの割り込みを調整する役割を果たす。
【００３０】
タイマーユニット１１４は、１６ビットカウンタを有する四つの独立したタイマーから成る。このタイマーは、バスクロック（１／１６または１／２５６間隔）によって、または外部クロックを介して駆動される。ＤＭＡＣ１１６は、メインメモリおよび周辺処理装置間の、または、メインメモリおよびスクラッチパッドメモリ間のデータ転送を行う。同時に、メインバス１２４を調整する。ＤＭＡＣ１１６のパフォーマンス最適化は、エモーション・エンジン性能を向上させる鍵となる方法である。画像処理装置（ＩＰＵ）１１８は、圧縮された動画およびテクスチャ画像を展開するために用いる画像データプロセッサである。これは、Ｉ−ＰＩＣＴＵＲＥマクロブロック・デコーディング、カラースペース変換、およびベクトル量子化を実行する。最後に、サブバスインターフェース（ＳＩＦ）１２２は、ＩＯＰ７００に対するインタフェースユニットである。サウンドチップおよび記憶装置等の入出力装置を制御するために、サブバスインターフェースは、それ自体のメモリおよびバスを有する。
【００３１】
図３は、グラフィックス・シンセサイザ２００の構成を概略的に示したものである。グラフィックス・シンセサイザは、ホストインターフェース２０２、セットアップ・ラスタライズユニット２０４、ピクセルパイプライン２０６、メモリインターフェース２０８、フレームページ・バッファ２１４およびテクスチャページ・バッファ２１６を含むローカルメモリ２１２、およびビデオコンバータ２１０を備える。
【００３２】
ホストインターフェース２０２は、ホストとデータのやりとりを行う（エモーション・エンジン１００のＣＰＵコア１０２の場合）。ホストからの描画データおよびバッファデータは双方とも、このインターフェースを通過する。ホストインターフェース２０２からの出力は、グラフィックス・シンセサイザ２００に供給される。このグラフィックス・シンセサイザ２００は、グラフィックスを展開し、エモーション・エンジン１００から受け取った頂点情報に基づいてピクセルを描画し、各ピクセルの、ＲＧＢＡ値、深度値（例えばＺ値）、テクスチャ値およびフォグ値等の情報を算出する。ＲＧＢＡ値は、赤、緑、青（ＲＧＢ）のカラー構成要素を特定し、Α（アルファ）構成要素は画像オブジェクトの不透明性を表す。アルファ値は、完全に透明から完全に不透明まで変化させることができる。ピクセルデータは、ピクセルパイプライン２０６に供給され、ここで、テクスチャマッピング、フォギングおよびアルファブレンディング等の処理を行い、算出されたピクセル情報に基づいて最終的な描画のカラーを決定する。
【００３３】
ピクセルパイプライン２０６は、１６個のピクセルエンジンＰＥ１、ＰＥ２、・・・ＰＥ１６を備え、最大１６ピクセルを同時に処理できる。ピクセルパイプライン２０６は、３２ビットカラーおよび３２ビットＺバッファで、１５０ＭＨｚで動作する。メモリインターフェース２０８は、ローカル・グラフィックス・シンセサイザ・メモリ２１２からデータを読み込み、かつ、書き込みを行う。ピクセル操作の終了時には、メモリに対して描画ピクセル値（ＲＧＢＡおよびＺ）を書き込み、メモリからフレームバッファ２１４のピクセル値を読み込む。フレームバッファ２１４から読み込まれるこれらのピクセル値は、ピクセルテストまたはアルファブレンディングのために使用される。メモリインターフェース２０８はまた、ローカルメモリ２１２から、フレームバッファの現在の内容に対するＲＧＢＡ値を読み込む。ローカルメモリ２１２は、グラフィックス・シンセサイザ２００に内蔵される３２Ｍビット（４ＭＢ）のメモリである。これは、フレームバッファ２１４、テクスチャバッファ２１６および３２ビットＺバッファ２１５で構成できる。フレームバッファ２１４は、カラー情報のようなピクセルデータが格納されるビデオメモリの部分である。
【００３４】
グラフィックス・シンセサイザは、視覚的な細部を三次元ジオメトリに加えるために、二次元から三次元へのテクスチャマッピング処理を使用する。各テクスチャは、三次元画像オブジェクトの周囲に巻きつけられ、伸ばされ、そして曲げられて、三次元のグラフィック効果を与える。テクスチャバッファは、画像オブジェクトに対するテクスチャ情報を格納するために使用される。Ｚバッファ２１５（別名、深度バッファ）は、ピクセルについての深度情報を格納するために利用できるメモリである。画像は、グラフィックスプリミティブまたはポリゴンとして知られる基本構成ブロックにより構築される。ポリゴンが、Ｚバッファリングを使って描かれる場合、各ピクセルの深度値は、Ｚバッファに格納される対応する値と比較される。Ｚバッファに格納される値が新しいピクセル値の深度以上の場合、このピクセルが可視であると決定され、その結果、そのピクセルは描画されることとなって、Ｚバッファは新しいピクセル深度により更新される。しかしながら、Ｚバッファ深度値が新しいピクセル深度値よりも小さい場合、新しいピクセル値はすでに描画されたものの後ろ側にあって、描かれることはない。
【００３５】
ローカルメモリ２１２は、フレームバッファとＺバッファとにアクセスするための１０２４ビットの読み込みポートおよび１０２４ピットの書き込みポート、およびテクスチャ読込み用の５１２ビットのポートを有する。ビデオコンバータ２１０は、ある特定の出力フォーマットにおいて、フレームメモリの内容を表示するよう機能する。
【００３６】
図４および図５により、いくつかの異なるユーザーインターフェース（ＵＩ）制御について説明する。
【００３７】
図４は、概略的にダイヤル制御を示したものである。
【００３８】
図４における長方形のアウトラインは、カメラ７３０によって取り込まれ、ディスプレイ３０５上に表示されている画像の外縁を概略的に表すものである。動作中、カメラ７３０によって、取り込まれる連続した画像またはフレームは、エモーション・エンジン１００によって、グラフィックス・シンセサイザ２００に渡され、グラフィックス・シンセサイザのビデオ出力のすべてあるいは一部に対する背景として表示される。
【００３９】
本実施例では、カメラ７３０は、ユーザー１０００の方へ向けられている。
【００４０】
ダイヤル制御１０１０は、（グラフィックス・シンセサイザによって、）背景取り込み画像上に重畳される。このダイヤル制御は、ポインタ１０２０がその中で表示される円形ボーダー１０１５を備える。ポインタは、ゲームまたはゲーム機の変数に対応づけてもよい。その結果、（例えば）時計回りにポインタを動かすことにより変数を増やし、逆に、反時計回りにポインタを動かすことにより変数を減少させる。このような方法で、ダイヤル制御は、ポテンショメータのような機械的回転制御の操作をシミュレーションすることができる。ポインタができる動きは、点線で示される。ユーザーがポインタをどのように動作させるかについては後述する。
【００４１】
ダイヤル制御を操作するために、ユーザーは、ボーダー１０１５内の少なくとも一部に手を置く。そして、ユーザーの手の動きが、ポインタ１０２０の軸（回転中心）１０３０を基準として検出される。この動きがどのように検出されるかについては後述するが、このような検出によって次のような効果がある。すなわち、もしボーダー１０１５内のユーザーの手の全体の動きが中心１０３０を基準として時計回り方向であると検出された場合、ポインタは、それに対応して時計回りに動かされる（そして、ゲームまたはゲーム機の変数は増加する）。もしボーダー１０１５内のユーザーの手の全体の動きが中心１０３０を基準として反時計回り方向であると検出された場合、ポインタは、それに対応して反時計回りに動かされる（そして、ゲームまたはゲーム機の変数は減少する）。ポインタの動きまたは回転は、手の動きと同じあるいは比例するよう構成できる。また、仮想の「エンドストップ」を備えることもできる。それによって、特定の方向への連続した手の動きが、ポインタの連続した回転につながることなく、エンドストップの一方に到達したときにポインタの回転が止まるようにする。
【００４２】
任意に、円形ボーダー１０１５の中で適切な動きが検出されない場合、ダイヤルをロックする（動きを抑制する）ことができ、それによって、偶発的に調整されてしまうことを防ぐ。このダイヤルは、色を変えることによって、そのロック状況を示唆できる。
【００４３】
ゲームまたはゲーム機の変数は、ただちに変更することができる。または、このような変更は、ユーザーがポインタの回転を止めるまで、あるいはボーダー１０１５内部から手を引き出すまで保留できる。ダイヤル制御を容易にしている機構については、後述する。
【００４４】
図５は、スクロール制御に関して概略的に示したものである。
【００４５】
図４に似たような方法で、スクロールアイコン１０５０は、カメラ７３０から取り込まれたユーザー１０００の画像上に重畳される。本実施例では、このスクロールアイコンは垂直にスクロールように構成されるが、もちろん、適切な方向であればどの方向にスクロールさせてもよい（または実際には、例えばスクロールアイコンがたくさん並んでいる場合は複数の方向でもよい）。このアイコンは、いつでも、現在見えているものを超えて拡張可能である。エンドレスなルーレット式フォーマットに構成するのが好ましいが、単純なライン構造に構成することも可能である。
【００４６】
ここでの基本概念は、一般的な垂直方向の手の動きによって、（または、非垂直方向な手の動きの垂直成分によって）、アイコンを上下にスクロールさせることができるということである。前述の通り、アイコンのスクロール動作は、ユーザーの手の垂直な動作と等しくすることが可能であり、そうでなければ、このような動作に比例する、または、依存するものであるようにできる。この垂直動作は、アイコンを囲んでいる画像の領域１０６０内で検出できる。
【００４７】
検出領域１０６０は他の選択肢も可能である。ユーザーが、ある特定の方向にアイコンを垂直方向にスクロールさせる動きを開始し、領域１０６０から手を引き出しながら、垂直方向に手を動かし続けることができる。このアイコンは、エンドレスに、または、減衰（減速）するように、垂直にスクロールし続けることができる。ユーザーは、領域１０６０の中に、静止している手または動いている手を再び入れることによって、この連続した動きを止める（逆転させるあるいは強化する）ことができる。
【００４８】
選択ボックス１０７０を説明する。一般的にこれは、ディスプレイ内で静止しており、所望のアイコンが選択ボックス内に入るまでアイコンを上下させることにより、アイコンの一つを選択できる。従って、もしアイコンが（例えば）ゲームオプションまたは音楽トラックを表わす場合は、ユーザーが、ボックス１０７０内にアイコンを配置することによって、ゲームオプションを実行する、または音楽トラックを再生させることが可能である。
【００４９】
スクロール制御を容易にする機構について後述する。
【００５０】
再び図４を参照すると、ダイヤル制御の変形として、ホイール制御がある。ホイール制御は、ダイヤル制御と同様の方法で動作する。しかし、ホイールの動きは、ユーザーがホイールボーダー１０１５によって囲まれている領域内で動作を開始し、ホイールボーダー１０１５から手を引き出しながら手を動かし続けることによって、ホイールを回転させることができる点において、スクロール制御に類似している。このアクションの間、手の動きが一貫している場合、ホイールは、あたかも自身の運動量で動くように、エンドレスにまたは減衰（減速）するようにスピンし続ける。ユーザーは、必要に応じて、ホイールボーダー１０１５により囲まれている領域内に、静止した手または動いている手を再度入れることによって、この継続している動きを停止（逆転または強化）させることができる。
【００５１】
このホイール制御は、例えば、垂直スクロールアイテムが円形状をなしているホイール上に示されたオプションから選択を行うために、またはアクションを行う際にゲームキャラクターが使用するエネルギーレベルを表わすために、使用してもよい。
【００５２】
任意に、ホイールは常にロックを外した状態にしておくことが可能であり、それによって、ホイールボーダー１０１５内で検出されたどんな動きでも、潜在的にスピンを誘発するようにすることができる。
【００５３】
ホイール制御を容易にしている機構については、後述する。
【００５４】
図６は、ソフトウェア命令下で動作するエモーション・エンジン１００により実行されるユーザー制御検出機構を示すブロック図である。説明を簡略化するため、この図はオブジェクト指向プログラムのためのオブジェクトクラスを示すものであり、ここでクラスは、データとそのデータ上で動作可能な関数とを備える。例えば、Imageクラス１０は、画像内の各ピクセルの幅、高さ、カラーチャンネルの数、およびそのカラー等の情報を含むことが可能である。また、Imageクラス１０は、このデータに作用する関数をたくさん有することができる。例えば、GetNumPixels()、GetPixelColour(int x、int y)、およびSetPixelColour(int x、int y、Colour RGB）はそれぞれ、画像サイズの数値を決め、所定の座標上にあるピクセルのカラー値を取得し、所定の座標におけるピクセルのカラー値を設定することを表す。
【００５５】
従って、以下の説明において、あるクラスがある特性または情報を有すると言われる場合、それはそのクラス内のデータについて言及しているのであり、一方、そのクラスがそのような情報に作用していると言われるときは、そのクラス内の関数に関連する、と理解される。
【００５６】
図６において、要約すると、エモーション・エンジン１００等のデータ処理装置に取り付けられたビデオカメラ７３０が、画像（すなわち、Imageクラス１０に属するデータ）を作成する。ImageHistoryクラス２０は、最終のＪ個の画像を格納する。DifferenceMetricクラス３０は、現在およびそれより以前の画像を保持し、それらを処理して、連続画像がどこで異なっているか、またどの程度異なるかを示す画像を作成する。これらの差分画像は、閾値とされDifferenceHistoryクラス４０に格納される。OpticalFlowクラス５０における関数は、ImageHistoryクラス２０内の画像を分析して、一つの画像から次の画像まで追跡するための有効で認識可能なポイントを見つけ出す。任意に、OpticalFlowクラス５０における関数は、DifferenceHistoryクラス４０を使って、この処理を検証し処理速度を上げることができる。PointHistoryクラス６０は、OpticalFlowクラス５０の関数により識別されたポイントのリストと、ImageHistoryクラス２０内の各画像のどこにそれらのポイントが位置するかを格納する。
【００５７】
次に、MotionModelクラス７０は、これらのポイントのペアの間で位置変更に相当する動きをモデル化する。現在およびその前の画像に対する移動ポイントについてその前後位置のリストを作り、それらの位置から規定どおりに、トランスレーション、スケールおよび回転モデルを作成する。任意に、MotionConstraintクラス８０は、算出されたオブジェクトの動き・位置を取り込み、ユーザーインターフェース（ＵＩ）制御の所望の動きに従って、それを制限する（例えば、廃棄トランスレーション）。
【００５８】
UserlnterfaceControl（UlControl）クラス９０は、PointHistoryクラス６０内の位置を取り込み、MotionModelクラス７０に対してそれらを供給し、それから結果として生じる動作を取り入れて、MotionConstraintsクラス８０から、一般的に一つまたは複数の制約を適用する。
【００５９】
これによって、この制約された動作は、個々のＵＩ制御の動きを表す。
【００６０】
ここで、本発明の実施例のための、これらのクラスの詳細について説明する。
【００６１】
Imageクラス(１０)は、画像のサイズ（幅と高さ）、カラーチャンネルごとに可能な輝度値の数、およびカラーチャンネルの数を保持する。画像のサイズは、カメラの解像度（例えば３２０×２４０または６４０×４８０）に依存することが多い。しかし、制御が画面の小さな領域でのみ行われる場合、任意にこの小さな領域が画像として扱われ、元画像の残りは廃棄してもよい。
【００６２】
一般的に使用される画像についての三つの主要なタイプは、以下のものである。
【００６３】
i．カラー画像（３カラーチャンネル、各チャネルに対して２５６輝度値）
ii．グレースケール画像（２５６輝度値を伴った１カラーチャンネル）
iii．バイナリ画像（２輝度値を伴った１カラーチャンネル−白黒）
ビデオカメラ７３０は、ある程度固定したフレームレート（例えば毎秒３０、６０、または１２０フレーム）で、カラー画像を作成する。これらは、ImageHistory ２０に渡される前に、グレースケール画像に変換される。
【００６４】
ImageHistoryクラス２０は、上記のようにカメラから取り込まれる最終のＪ 個のグレースケール画像を格納する。新規画像が追加される毎に、最も古いものは保管画像の端から落とされる。例えば、Ｊは、３から１４あるいはそれ以上の場合もある。
【００６５】
DifferenceMetricクラス３０は、二つの画像間の差分を算出して、それを閾値とする関数を提供する。この関数は、入力として二つのカラー画像（例えば、現在およびそれ以前の画像）を取り込む。各ピクセルに対し、各カラーチャンネルにおける差分が合計され、結果として生じる値によってグレースケール画像を作成される。その後、この画像は、スリーポイント・ガウシアンブラー・コンボリューションフィルター（three point Gaussian blur convolution filter）を用いて滑らかにされ、ある程度のトレランスが与えられる。最後に、この画像は閾値とされ、画像のどの部分が十分な量の変化があったかを示すバイナリ画像を生成する。この差分閾値がどのように選択されるかについては、ノイズ校正に関連して後で開示する。
【００６６】
このように、DifferenceMetricクラス３０は、差分データを作成するよう動作可能であり、二つの連続する画像の間のピクセル値における差分に比例する一連の値を備え、この後、差分データを滑らかにするよう動作可能である。
【００６７】
さらに、DifferenceMetricクラス３０は、算出された差分閾値レベルで、差分データに閾値を適用するように動作可能で、結果として生じるバイナリ差分データを出力する。
【００６８】
DifferenceHistoryクラス４０は、一連のＮ−１バイナリ画像を提供する。それぞれの画像が、DifferenceMetricクラス３０から取得した、ImageHistory内の二つの連続する画像間の差分を維持する。ImageHistoryクラス２０と同様に、新規な画像が加えられるたびに、格納されたもののうち最も古いものは廃棄される。
【００６９】
さらに、これはまた「累積的な差分画像」を維持する。DifferenceHistory内の個々の画像のいずれかが白いピクセルを有する場合、これは白いピクセルを有するバイナリ画像である。従って、これはDifferenceHistoryクラス４０内の個々の画像の論理和関数とみなすことが可能である。もちろん、「黒」および「白」として表現するのは、ただ単に本説明を明確化するためである。実際には、このデータはピクセル位置ごとに１ビットとして格納されてもよく、あるいは、記憶装置内の効率性により他のフォーマットで格納することも可能である。目的は、ピクセル位置に対して検出動作をマップすることにある。
【００７０】
例えば、別の静的な場面において、ある人が挨拶の際に手を振った場合、その累積する差分画像は、一般的にその人の肘を原点とする弓形に類似するものであり、ウェーブの範囲に相当する円弧の範囲を定める。
【００７１】
このように、DifferenceHistoryクラス４０は、一連の画像に対するバイナリ差分データを組み合わせるよう動作可能であり、算出差分閾値を超えた連続画像間の差分を示した一連の画像全体に亘るすべての点を示す累積バイナリ差分画像を作成する。
【００７２】
OpticalFlowクラス５０は、特徴ポイントとして作用する最新画像内のポイントを見つけ出し、ImageHistoryクラス２０内の３つ以上の画像を通じてそれらのポイントを逆向きに追跡する。
【００７３】
本発明の実施例において、ポイント追跡は、Lucas-Kanade ポイントトラッカに基づいている。これは１９８１年に開発され、Lucas, B., and Kanade, T., 「An Iterative Image Registration Technique with an Application to Stereo Vision」、第７回人工知能国際合同会議 7 (ＩＪＣＡＩ)の声明書、６７４〜６７９ページにおいて公開されている。
【００７４】
現在の画像、およびその前の画像の、二つの画像を与えられ、Lucas-Kanadeトラッカは、以下を行う。
【００７５】
１．画像内の各ピクセルと対応づけられている固有値を分析することによって容易に認識可能な、現在の画像上の一セットの位置を定める。
【００７６】
２．前の画像内で、これらのポイントに最も近く一致するものを見つける。
【００７７】
３．見つけた場合、画像上で識別可能なポイントについての、前のおよび現在の位置を示す、一セットの位置のペアを出力する。
【００７８】
このように、OpticalFlowクラス５０は、現在の画像内で選択されたポイントとの対応関係に基づいて、前の画像内のポイントを選択するよう動作可能である。
【００７９】
例示されているポイントは、画像内での形状の端部を表わすものであるか、または、このような形状の凹頂点を表わすポイントである。手を例にとると、特徴ポイントは、指の先端、および隣り合う指の間の頂点で識別される。
【００８０】
図７乃至図９は、Lucas-Kanadeポイントトラッカにおける特徴ポイントの検出を概略的に示したものである。
【００８１】
図７は、制御画像領域内のユーザーの手について取り込まれた画像を表わしていると仮定する。従って、図７の範囲は、取り込まれた画像全体の一部にしか過ぎず、これは（例えば）ボーダー１０１５または領域１０６０内にある部分である。
【００８２】
上記に説明したように特徴ポイント２１００が検出される。以下の説明を明瞭にするために、一つの特徴ポイント、つまり、ユーザーの親指先端の位置のポイント２１１０だけを考慮するが、同様の説明がすべての検出特徴ポイントに適用可能である。
【００８３】
Lucas-Kanadeのトラッキング処理を連続して使用することにより、特徴ポイント２１１０は、それぞれ対応する図８と図９の特徴ポイント２１１０’と２１１０”と相関する。これによって、図８と図９において概略的に示されているように、図示されているような事前の親指位置によって、手の動きが表わされることになる。
【００８４】
しかしながら、Lucas-Kanadeトラッカは、多くの問題に陥りやすい。特に、画像内の自己相似性により（例えばタイル張りや草木など）、無関係なポイントが画像間で相関して表れてしまう可能性があり、偽の見かけだけの動きを作り出してしまう。さらに、画像ノイズによる見かけ上のポイントの動きと、真の動き（小さい動きや遅い動き）は区別することができない。もし詳細なＵＩ制御を実現することが望ましいのであれば、このような区別が特に重大になってくる。これらの問題点について以下に詳述する。
【００８５】
問題点１：
例えば、壁、天井、または床のタイルの線に沿ったタイル間の接合は、全て非常に類似して見える。一つのフレームから次のフレームへのカメラ画像における、わずかなノイズまたはブレにより、次の画像において、一つの接合点が、そのライン上のどこか別の接合点に似て見えてしまうことがある。結果的に、画像ノイズによって、Lucas-Kanadeトラッカのステップ２におけるポイントマッチが、フレーム間で異なるタイル接合点を対応づけてしまうことになり、見かけ上の動きを生じさせてしまう可能性がある。似たような問題は、壁紙や縞模様のＴシャツなどの繰り返し模様の場合に起こりうる。
【００８６】
問題点２：
問題点１と同様に、タイルやプリントの繰り返し模様などのように完全に類似するものではないとしても、草木などのような自己相似性オブジェクトは十分に類似性があるので、以下の例示シナリオにおいて問題を生じ得る。ユーザーが手を上げて室内用鉢植えの前に立っており、植物の最上部は覆い隠され、下部の枝が見えるようになっている。例えば指先と葉の集まりに該当する画像内のポイントを識別する。その後、ユーザーが手の位置を低くして、植物の下方の枝を覆い隠し、最上部の枝が見えるようにする。Lucas-Kanadeトラッカは、下方に動く手の中のポイントを追跡するが、植物の下半分において識別されたオリジナルポイントがないので、見えるようになった植物の上半分において、類似ポイントを見つけ出そうとする。そのため、これを上向きの動きと解釈して、感知されたユーザーの動きを効率よく打ち消してしまう。
【００８７】
問題点３：
ここで、図１０（ａ）と図１０（ｂ）を参照する。これらの図は、あるポイントが６枚の連続したフレーム上をどのように移動するように見えるかを示す例である。図１０（ａ）は、このシーンでは静止しているポイントであるが、カメラ画像内のノイズのために移動しているように見える。このポイントは遠くへの動きはなく、恐らく１または２ピクセル分の動きである。図１０（ｂ）は、直線上を移動しているポイントを示す。この場合、ノイズによって、ポイントが少しだけ進路から逸脱しているように見える。これらの図から、単に、ポイントが二つのフレーム間で移動した距離についての閾値だけでは、ポイントが本当に静止しているかどうかを判断するには不十分であるということが明らかである。二つの連続するフレーム間において、静止ポイントが、移動ポイントの見え方に相当する距離を移動するように見える。ポイントの本当の動きの速度が遅くなるにつれ、あるいはカメラのフレームレートが増すにつれ、この問題は悪化する。
【００８８】
これらの問題をすべて考慮し、本発明の実施例では、Lucas-Kanadeトラッカに対する一連の改良をOptical Flowクラス５０内に組み込むこととした。
【００８９】
第一に、問題点１と２に記載されたような自己相似ラインに対する誤ったマッチングと、自己相似オブジェクトに亘るポイントの出現を減らすための技術としてリバースマッチングがある。トラッカは、現在のフレーム内でトラックすべき良い点を見つけ、その位置をその前のフレーム内で決めると仮定する。前のフレーム内のこのポイントをあたかも追跡に適した特徴を有しているととらえ、現在のフレームにおいて、そのポイントの位置を決めようとすることによって、この位置を確認できる（すなわち、逆時間での追跡）。トラッキング・アルゴリズムによって、その現在のフレーム内のポイントが（例えば）そのポイントがあるべき場所のピクセル内、または他の閾値距離内であると分かった場合、有効なポイントのペアであるとみなされる。そうでなければこのポイントは廃棄される。
【００９０】
このように、この技術は、画像フレーム間の自己類似性によるトラッキングエラーにより（特に、ノイズを画像化するような変動が入り込んだ場合）、画像フレーム間で相互交換できる見込みがなくなるため、フレームペアの中で反対方向に適用されると一貫性がなくなる可能性があるという事実を利用するものである。従って、この技術によって、このような誤った追跡の大部分が除去される。
【００９１】
このように、OpticalFlowクラス５０は、もともと現在の画像内で選択された点に対応する、先行する画像内のポイントとの対応に基づいて、現在の画像内のテストポイントを選択し、現在の画像内でもともと選択されたポイントとテストポイントが実質的に一致しないポイントのペアを廃棄するよう動作することができる。
【００９２】
第二に、図１１をさらに参照すると、差分イメージングは、二重の効果をもたらす技術である。その主目的は、マッチングをするためのなんらかの試みがなされる前に移動をしなかったポイントを取り除くことによって、マッチング処理を高速化することにあるが、逆マッチングを行う前に、誤ってマッチしたいくつかのポイントを取り除くという第二の利点もある。
【００９３】
図１１に示される差分画像は、前述したように、画像ペアを得るためにDifferenceMetricクラス３０によって作成され、画像内のポイントは以下のように取り除かれるか、あるいは維持される。
【００９４】
i．差分画像の黒い（静止）部分にある、現在の画像からのポイントは即座に取り除かれる。
【００９５】
ii．差分画像の白い（稼働）部分にある、現在の画像からのポイントは、前の画像に対して追跡される。もし前の画像でのこのポイントが、差分画像の黒い部分にある場合、そのポイントは取り除かれる。
【００９６】
iii．一方、もし前の画像でのポイントもまた差分画像の白い部分にある場合は、逆マッチングが適用され、ポイントのペアの妥当性が確認される。
【００９７】
このように、OpticalFlowクラス５０は、先行する画像においてポイントを選択する前に、差分画像での均等位置が、算出された差分閾値レベルを下回る差分を示している現在の画像内のポイントを廃棄するよう動作することができる。
【００９８】
上記に代えてまたはそれに加えて、OpticalFlowクラス５０は、先行する画像におけるポイントとの一致に基づいて現在の画像でのテストポイントの選択を行う前に、差分画像における均等位置が、算出閾値レベルを下回る差分を示している先行する画像でのポイントを廃棄するように動作することも可能である。
【００９９】
前述のように、DifferenceMetricクラス３０は、ポイントが移動したかどうか決めるために可変の閾値を適用する。これは、もし画像の中で非常に大きい動きがあると思われる場合は、（ユーザーによって、あるいは現行のゲームコンテキストを考慮しながら自動的に）この閾値を上げることが可能であり、それによって、システムが些細な移動に対してそれほど敏感にならないようにするだけでなく、逆マッチングがそれ自体で取り除くことができる数よりもっと多くの誤った結果を取り除くことができる。
【０１００】
差分画像を算出することと、この画像を参照してポイントの状況を算出することは、ポイントマッチングと逆マッチングを行う場合と比較して、非常に高速であり、従って、全体のトラッキング精度を改善するだけでなく、かなりコンピューティング資源を節約できる。
【０１０１】
任意に、想定されているまたはこれまでに算出された、画像フレームレートとユーザー動作の一般的なスピードについての知識を考慮して、さらに、ＵＩ制御を囲む領域の外にあるポイントを自動的に取り除くことが可能である。ＵＩ制御を囲む領域とは、典型的な移動により一つ、二つのフレームによりカバーする距離に相当するが、フレーム数は多いことが望まれる。これによって、画像のどこか別の場所にある真の動きであって無関係な動きを無視しながら、トラッキングするためのＵＩ制御への移動ポイントを検出することが可能になる。
【０１０２】
第三に、マルチフレーム移動ポイント分析を使用して、上記に概説した第三の問題点に対処し、本当に移動しているポイントと、ノイズの微小震動を示している静止ポイントとを区別する。
【０１０３】
図１２（ａ）および図１２（ｂ）を参照すると、ノイズ微小震動のランダムな性質は、静止ポイントの動きが全体に亘る方向に向くわけではないということを意味していることがわかる。従って、移動をしているポイントは結果的に、元の場所からかなり離れたところへ移動して測定可能となり、一方、対照的に、ただランダムに動いているポイントは同じ場所にとどまる傾向がある。
【０１０４】
これらの二つの結果を区別するために、一般的に、ImageHistoryクラス２０内にある数多くの画像を考慮する（少なくとも３つ、一般的には１０から２０）。最初に、現在の画像内で見つけられるトラッキングポイントを正常なものとして先行する画像内で位置を決める。しかし、先行する画像内のそれらの各位置は、追跡すべきポイントとされ、さらにその前の画像等の中で探し出される。フレームレートがどのくらい速いか、動きがどれくらい遅いと予想されるかによって、このポイントは必要とされる限り逆に追跡することが可能であるが、ImageHistoryクラス２０内のメモリ制限や、（各フレームの追加に従い直線的に増加する）処理時間の制限に左右される。
【０１０５】
このポイントの履歴を分析し、最後のＲ個のフレームの間に、いずれかのポイントがある閾値（例えば、円１１０１により表された閾値）よりも遠くへ離れたかどうかを判断し、それに従い、このポイントは、静止ポイントよりむしろ移動ポイントであると判断する。一般的に、Ｒは経験的に決定されるものであるか、あるいは、ビデオキャプチャフレームレートの関数である。計算負荷を減らすため、任意に、あるポイントが一旦、移動ポイントであると判断されたとき（すなわち、関係する画像数に亘って閾値となる画像間動作を超えた場合）は、さらなるフレームを使ってこれ以上逆トラッキングをする必要はない。
【０１０６】
本当に移動しているピクセルにより見込まれる移動量に対する閾値は、もちろん、数Ｒおよびビデオフレームレートにより変動する。この閾値は、より高いＲ値に対して概して高くなり、より低いフレームレートに対しても概して高くなる。
【０１０７】
このように、OpticalFlowクラス５０は、ImageHistoryクラス２０に格納される先行する画像に対して動きを検出するため、ポイントのペアを再帰的に取得し、これらのポイントのペアによる累積した最終的な動きを、距離閾値と比較し、意図的な動きを画像ノイズから区別するよう動作可能である。
【０１０８】
この技術の付加的な利点は、以前に移動していたが現在は止まっているポイントを、一度も移動しなかった点から区別して拾い上げることもできるということである。任意に、これらのポイントは、例えば、もし現在のフレームよりも前に、ポイントが静止しているフレーム数が所定のフレーム数より少ない場合は、差分画像化技術のもとでの排除の対象から外される場合もある。
【０１０９】
任意に、この技術によって、移動しているポイントおよび静止しているポイントが、ディスプレイ３０５上で異なるように描き、移動しているポイントについては、辿ってきた経路を示すことができる。これは、例えば、指導モードにおいて、どのようにして制御が行われるかについてユーザーに対して有益なフィードバックを与えることができるので、ユーザーはより速く使い方を学ぶことができる。
【０１１０】
上記したトラッキング方法は、誤ったポイントのペアを取り除いて演算を軽減するために、差分画像化技術を用いるのが好ましいので、DifferenceHistoryクラス４０は、ImageHistoryクラス２０内の画像に対応する差分画像を格納する。
【０１１１】
特に、「累積した」差分画像の黒の領域で開始するポイントは、最終のＪ個の画像内ではいかなるポイントにおいても動いていないことが保証される。このように、差分画像での解決を使用する場合、累積的差分の中にある任意の黒いポイントは、マルチフレーム移動ポイント分析から除外することが可能である。というのは、それらが全体の画像履歴にわたって静止しているであろうことは周知だからである。このように、画像履歴の中で前回の画像から再帰的にポイントのペアを取得する前に、累積した差分データを使用して、連続した画像間で、算出された差分閾値レベルを超えるには十分な差分がなかったような点を廃棄する。
【０１１２】
PointHistoryクラス６０は、追跡するのによいと識別されたポイントの最終Ｊ個の画像全体での位置を維持する（すなわち、ある程度の時間、意図的な動きを示したと判断された点を格納する）。以下で説明するように、これらのポイントのうちの少なくともいくつかは、ＵＩ制御とユーザーのインタラクションを分析するために使用される。
【０１１３】
MotionModelクラス７０は、剛性体の動作をモデル化するための関数を備えるクラスである。通例は、一連の事前事後のポイントのペアがとられ、この事前ポイントと事後ポイントを最もよくマップする動作が算出される。一般的に、この動作モデルからの出力は４つの値であり、それらは、Ｘ方向移動量（Ｘトランスレーション）、Ｙ方向移動量（Ｙトランスレーション）、スケール、および、ある原点を中心とする回転（ローテーション）である。
【０１１４】
本発明の実施例において、ポイントのペアは、現在および先行する画像から取り出される。別の実施例において、より滑らかな動作モデルを作成するために、さらに古い画像からのポイントペアが使用されるが、使用される画像数およびカメラフレームレートによって、この履歴データはＵＩ制御のレスポンスの中に残像の出現を作り出してしまう場合もある。
【０１１５】
これをモデル化するための方法はたくさんあるが、一般的に、このモデルを描写し、前後のポイントをマップする一連の数式が使用される。この数式は、回転量、トランスレーション量およびスケール量を描写する多くの未知数を含む。観察されたポイントからこれらの未知数を予測するために、ポイントのペアに対して最小二乗誤差式解法が使用される。
【０１１６】
本発明の実施例において、この数式の解法は、ハウスホルダーの直交化最小二乗法（Householder Orthogonalization least squares method）と呼ばれ、例えば、Gene H. Golub and Charles F Van loan "Matrix Computations", 第三版 (ISBN: 0801854148)に記載されている。
【０１１７】
MotionModelクラス７０は、後述のように、多くの動作モデル（またはサブクラス）を含む。
【０１１８】
RotScaleTransModel関数は、ボディが、回転、拡大縮小（スケール）、およびＸ方向またはＹ方向の並進移動（トランスレーション）が可能であると仮定する。これらの動作が測定されるときに基準とする原点の位置は必ず与えられなければならない。
【０１１９】
主計算の前に、原点位置は、各ポイントの位置から減算される。
【０１２０】
ポイントについての修正された現在およびそれより以前の位置は以下のように与えられると仮定する。
【０１２１】
xCurrentkは、第k番目のポイントの現在のｘ座標
yCurrentkは、第k番目のポイントの現在のｙ座標
xPrevkは、第k番目のポイントの前回のｘ座標
yPrevkは、第k番目のポイントの前回のｙ座標
これらのポイントの集合体から、以下の未知数を予測する必要がある。
【０１２２】
スケール：ボディのサイズが増えた量
Θ： ボディの回転角
transX：トランスレーションにおけるＸコンポーネント
transY：トランスレーションにおけるＹコンポーネント
このモデルにおいて、現在のポイントがどのようにして前のポイントから導き出されたかを表す数式は、次のようになる。
【０１２３】
【数１】
【０１２４】
それぞれのポイントペアはすべてこのような二つの数式をもたらす。この目的は、式の集合体におけるエラーを最小限にするスケール、Θ、transXおよびtransYを見出すことである。
【０１２５】
この数式は、マトリックス/ベクトル方程式として再公式化される。
【０１２６】
【数２】
【０１２７】
n個のポイントに対し、マトリックスは2n列を有する。ハウスホルダー直交化アルゴリズムは、このマトリックス式に対して最小誤差解（Ｍ、Ｎ、ＰおよびＱ）を見出すために使用され、ここで、Ｍ = scale.sinΘ、Ｎ = scale.cosΘ、P = transX、およびQ = transYである。
【０１２８】
このようにして、一旦、Ｍ、Ｎ、Ｐ、およびＱの値が得られると、スケール、Θ、transX、およびtransYに対する値が以下のように算出される。以前に開示されたポイントペア式から以下が確認される。
【０１２９】
【数３】
【０１３０】
これは、次を意味する。
【０１３１】
【数４】
【０１３２】
ここで、Θのすべての値に対して
【０１３３】
【数５】
【０１３４】
である。従って、
【０１３５】
【数６】
【０１３６】
である。それによって、
【０１３７】
【数７】
【０１３８】
これを、第二のポイントペア式に代入すると、
【０１３９】
【数８】
【０１４０】
をもたらし、一方、transX = PおよびtransY = Qである。
【０１４１】
RotScaleModel関数は、RotScaleTransModelと同様の方法で機能し、ボディが枢着点で固定されると仮定する。これによって、この点を中心に拡大縮小し、回転させることができるが、並進移動値は常にゼロである。
【０１４２】
結果的に、ポイントペアの数式は、すでに与えられている式とは若干異なる。
【０１４３】
【数９】
【０１４４】
また、この等式は、マトリックス/ベクトル式として再公式化され、
【０１４５】
【数１０】
【０１４６】
前回と同様に解かれて、スケールとΘを得る。
【０１４７】
RotScaleTransModelおよびRotScaleModel関数に代えて、あるいはこれに加えて、画像内のポイントはラインとして接合することが可能であり、あるいは、これらのポイントを横切るエッジについてエッジ検出を行うことが可能である（例えば、指の周りなど）。結果として生じるラインは、いわゆるラドン変換を用いて相対角度の変化を決定するために使用することができ、これによって、変換の投影角度が、画像内のライン角度と一致する場合のピークレスポンス（あるいは分布）が得られる。この技術は、回転データを得るために用いることができる。
【０１４８】
同様に、一つのフレームから次のフレームまで、ラインにより表される物体のサイズは固定しているとみなすことができる。従って、ラドン変換の投射角に沿ってラインを測定することによって、スケールの変化およびそれによる距離の変化を決定できる。
【０１４９】
TransModel関数は、ボディが単に移動することはできても、回転あるいは拡大縮小することができないと仮定する。よって、このモデルは、全てのポイントの平均動作をとり、適宜、transXおよびtransYを設定する。
【０１５０】
【数１１】
【０１５１】
MotionConstraintsクラス８０は、多くの制約をモデル化する関数を備える。すでに開示された動作モデルを使って、概念上のボディのために、とりわけ次のようなプロパティを決定できる。
【０１５２】
つまり、位置、向き、スケール、速度、角速度およびスケーリング速度である。
【０１５３】
制約関数は、これらのプロパティの値を取り込み、ある程度の制約に従うようにそれらの値を修正する。このようなボディは、すぐに作用するような制約をいくつか有することが可能である。
【０１５４】
考えられる制約関数のいくつかの例について以下に記載する。
【０１５５】
LinearConstraint関数は、ボディが、直線に沿って存在するように位置を固定する。また、この線の方向の速度成分によって速度を置き換えることも可能である。
【０１５６】
RangeConstraint関数は、ボディのプロパティのいずれに対しても上限値と下限値を設定する。例えば、この関数は以下のために使用することが可能である。
【０１５７】
- 有限長のスクロールバーを作る。
【０１５８】
- ダイヤルが半分だけ回るようにする。
【０１５９】
- 並進移動（トランスレーション）をゼロに固定する（それによって本体はその位置で枢軸回転する）。
【０１６０】
- ボディがほぼ最大速度を維持することを確実にする。
【０１６１】
尚、並進移動をゼロに固定するための制約を使用してRotScaleTransModel関数を使用することと、制約なしでRotScaleModel関数を使用することは等しくない。前者においては、並進移動はモデル化された後、捨ててしまう。後者において、モデル化は、（RotScaleModel関数によって、できる限り最良であると解釈される並進移動の存在している状態で）単に回転およびスケールをモデル化することのみに向けられている。
【０１６２】
UIControlクラス９０は、PointHistoryクラス６０、MotionModelクラス７０、およびMotionConstraintsクラス８０の間を調整して、ＵＩ制御の、位置、向き、スケール、速度、角速度、スケール速度（スケール変化率）、および形（円、細長い形、正方形等一定を維持するもの）のためのデータを管理できる。
【０１６３】
UIControlクラス９０は、PointHistoryクラス６０を調べて、現在移動しているポイントのみを考慮する。その後、UIControlの形状（例えば、図４において、外側境界線１０１５）の外側に現在位置があるものはすべて除外する。
【０１６４】
このようなポイントが十分にある場合、PointHistoryクラス６０内の移動ポイントについての現在と以前の位置のみを取り、これらをMotionModelクラス７０に渡して、このフレームペアに対して変換を行う。
【０１６５】
ＵＩ制御の速度、角速度、およびスケール速度は、このフレームに対する変換に一致するよう設定される。これらのプロパティ（位置、向き、およびスケールも同様に）は、この修正制御のために存在するMotionConstraintsクラス８０内の制約のいずれかの対象となる。このように修正されたプロパティは、ユーザー入力として機能するために利用可能になる。
【０１６６】
任意に、これらの修正されたプロパティに対してエラー値を算出できる。このエラー値は、修正された速度、角速度およびスケール速度を使用して、最後のフレーム内のすべてのポイントを変換し、それらのポイントが終了する場所と、現在のフレーム内で観察された場所との差分を見ることにより算出される。この差分はその後スケール変更されるので、このエラーは、移動をした各ポイントに対する総距離の一部となる。この値のログをとって、すべてのポイントからのすべてのエラーの合計をポイントの数で割る。これによって、動作の大きさや、いくつのポイントが観察されたかということとは無関係なエラー値が得られ、ユーザーの動きがどの程度うまく制約内にとどまっているのかという表示をすることができる。このような表示は、例えば、ユーザーにフィードバックを与える場合に使うことができる。一例として、もしユーザーがあまりに速くスクロール制御を動かそうとしている場合、赤く点灯するようにしてもよい。
【０１６７】
任意に、エラー値は、検出された動きのエラーの程度が低くＵＩ制御の動作制約にしっかりと適合しているかどうかによって、ＵＩ制御のロックを制御する際に利用することもできる。この構成により可能なのは、例えば、人がダイヤル制御を「通過して」歩くときに、ダイヤル制御はロックしたままにできる。というのは、動きの推移成分に比べると回転成分が非常に低いので、結果的に高いエラーになるからである。逆に、もし人が一つの手ではなく二つの手を使っても、もし、あたかもハンドルを操作するように両手を一緒に回転させた場合は、ダイヤル制御のロックを解除するために有効な動作となる。
【０１６８】
制御の中で、ユーザーのインタラクションであると解釈するような移動ポイントが十分にない場合（例えば、ユーザーの手がＵＩ制御の境界線を離れている場合）、速度（必要に応じて、ダイレクトの速度、角速度および／またはスカラー速度）を均等に維持できるので運動量をモデル化する、あるいは、ゆるやかに減速する（摩擦をモデル化する）、あるいは、ゼロを設定する（簡単であるがしっかりとした制御をモデル化する）、という三つの選択肢がある。
【０１６９】
ここで、上で例示されたＵＩ制御に特有なUIControlクラス９０の作用の構成を詳述する。
【０１７０】
再び図５を参照すると、スクロール制御は、TransModelMotion関数を使用して実行され、（この場合では）垂直なラインに動きを拘束するためにLinearConstraint関数を使用する。また任意に、（有限長のスクロール制御が要求される場合は）ラインに沿って範囲を制限できる。もし十分な移動ポイントが見つからない場合、速度はゆっくりと減速するままにしておき、運動量とある程度の摩擦を伴ったスクロールバーをモデル化する。
【０１７１】
スクロール制御はまた、前に開示された差分画像化技術を使うことにより、オプティカルフロー計算の効率を改善することができる。非常に大きくて速いユーザーの動きが予想されるときは、差分画像化閾値を適切に上昇させることが可能である。差分画像化技術は、このＵＩ制御にとって特に有益である。というのは、この技術は比較的範囲が広いので、それに比例して、外部からのポイントをより多く含んでいることが期待されるからである。
【０１７２】
再び図４を参照すると、ダイヤル制御は、RotScaleTrans関数を使用して実行され、RangeConstraint関数を使用して、速度ゼロおよびスケール速度ゼロの場合を有するように制限する。ダイヤル制御はまた、その動きから算出したエラー値を使って、ユーザーが好適な回転動作を行ったかどうかを判断する。そのような動作が行われなかった場合、ダイヤル制御はロックする。同様に、移動ポイントが十分にない場合、ダイヤル制御はロックする。
【０１７３】
任意に、このダイヤル制御は、OpticalFlowケース５０関数の効率化を行うため、差分バッファを使用しない。その理由は、差分バッファは、あまり感度が高くないので、ダイヤル制御を操作しているときに生じる非常にゆっくりで微細な動きを拾い上げることができないからである（後で開示するようなノイズ校正に依存する）。しかし、ダイヤル制御の領域は、スクロール制御よりもかなり小さいので、計算負荷に対するインパクトも同様に小さい。
【０１７４】
ホイール制御は、ダイヤル制御と同様の方法で実行されるが、ロックは全くかけない。これによって、ホイール内で算出された動作はすべて回転動作として解釈されることが可能となり、ホイール内で十分な移動ポイントが見つからない場合は、ホイールはスピンを続ける（あるいは減速する）。
【０１７５】
ダイヤル制御についての他の変形としては、スケールダイヤルがある。これは、RotScaleTrans関数が、ダイヤルの原点から離れる移動ポイントのトランスレーションを、ダイヤルを表示すべきスケールを示すと解釈することを利用する。従って、上記のダイヤル制御とは異なり、RotScaleTrans関数がスカラー速度を制限せず、その代わりに、ダイヤルが速度ゼロと角速度ゼロの場合を有するように制限する。従って、スケールダイヤルは、ユーザーが手を開閉するのに従って、拡大したり縮小したりする。一般的に、スケールダイヤルは、通常のダイヤル制御と同じようにロックする。
【０１７６】
角速度ゼロに対する制約もまた取り除かれる場合は、ダイヤルの回転とスケール変更を同時に行うことができる。従って、例えば、回転をステレオバランスに関連づける一方、スケールをゲーム機により演奏される音のボリュームに関連付けることが可能である。
【０１７７】
RangeConstraint関数は、例えば、スケールダイヤルが小さくなりすぎて明確に見ることができなくなることを避けるために、あるいは、動作分析のために十分なポイントが含まれるように、最大およびまたは最小スケールを制限することが可能である。スケールホイールも、同様に実現可能である。
【０１７８】
上記の動作と制約を使用した制御についての他の組み合わせは、当業者にとっては明らかなことである。また、スケールダイヤルと同じように、ポイントのトランスレーションに対し長さが依存するようなバー等、他のＵＩフォームファクタも同様に当業者にとって明らかである。
【０１７９】
同じように、インタラクションの他のモードにおいては、グラフィック制御を表示しない場合もある。例えば、RotScaleTransModelおよびRotScaleModelは、ビデオカメラに向かってパンチをする拳のスケールの変化を、ボクシングゲームでの入力として作用するように解釈できる。このシナリオにおいては、全体画像は「透明な」制御領域であって、その領域内のユーザーの動きは適宜解釈される。
【０１８０】
このタイプのインタラクションは、制御の表面的な見かけにより示される。例えば、ダイヤル制御は、予期される通りダイヤルで示され、片手でダイヤルを調節するように自然にユーザーを促す。対照的に、このダイヤルをステアリングホイールによって表すことも可能であり、これは両手でのアプローチを促す。ダイヤルのグラフィックスは、線画または画像に似たものでよく、透明な領域を伴っても伴わなくてもよい。グラフィックとのインタラクションの際、グラフィックと一致している取り込み画像内の移動領域は、重畳され、あるいはアルファブレンドされ、ユーザーはその行為についてよりよいフィードバックを受けられるようにする。
【０１８１】
同様に、ＵＩ制御が、状況に応じて動作を起動し、変化させ、あるいは、動作を取得することはいうまでもない。例えば、スクロール制御は、多くのダイヤルを含む多くのアイコンを表示することが可能である。これらのアイコンが「アクティブな」領域にスクロールして入ると、同じグラフィックを使った実際のダイヤル制御（またはその変形）に継ぎ目なく入れ替わる。ユーザーは、スクロール制御が多くの選択可能なダイヤル制御を格納しているということを経験する。他の例では、ＵＩ制御は、アクティブ領域内にスクロールするときのみ並進移動可能とすることにより、「好みの」または「ショートカットとなる」制御を選択し、画面上に常駐させるためにスクロールバーから引き出すことができる。
【０１８２】
図１３は、ビデオカメラが装着あるいは接続されたソニー(商標登録)プレイステーション・ポータブル(商標登録)ビデオゲーム装置（ＰＳＰ）についての本発明の実施例を示したものである。ＰＳＰにより使用されている「クロスメディアバー」ナビゲーションシステムが例示されており、これは、カテゴリアイコンの横列１３１０を備える。そのうちの一つであるセッティング１３１５がアクティブ領域に位置し、設定に関連するサブカテゴリの縦列１３２０が表示されるようにする。これらのサブカテゴリの中で、現在は「ネットワーク更新」が反転表示されている。
【０１８３】
カテゴリアイコンの横列は、上記のスクロール制御を使って制御され、このカテゴリアイコンの一つに関連するサブカテゴリの縦列が表示されると、これも同様にスクロール制御を使って制御される。両者の違いは、動作モデルに適用された横のトランスレーション制限内にあるか、縦のトランスレーション制限内にあるかということである。同様に、反転表示されるカテゴリの値またはプロパティを変更することも可能であり、例えば、上記のダイヤル制御を使って、オン／オフのために左に回したり右に回したり、あるいは該当する場合には連続値を設定する。
【０１８４】
これらの制御間のインタラクションは、起動、変更（例えば、ロックとロック解除）、または所望の結果を得るために適切な動作の取得をすることにより管理できる。例えば、縦方向スクロール制御あるいはダイヤル制御のいずれかが使用されているとき、現在のカテゴリアイコンにより占有されるアクティブ領域において、横方向の動きが検出されるまで、この横方向スクロールの制御をロックすることができる。これによって、例えば、ユーザーがサブカテゴリの設定を調整している間に、うっかり主要動作がカテゴリを変更してしまうことを防止し、他の制御を調整中は、ユーザーによって具体的に再開が行われるまで横方向スクロールバーはロックするという経験をユーザーに与える。これとは別のインタラクションスキームにおいて、他のＵＩ制御が動きを検出したとき、横方向スクロール制御はただロックするようにする。その結果、横方向スクロール制御はレスポンスの優先度が最も低い。縦方向スクロール制御は、次の優先度レベルを有し、現在反転表示されているサブカテゴリのためのダイヤル制御が最も高い優先度を有する。
【０１８５】
ここで図１４を参照すると、ユーザー制御検出の方法は、
Ｓ１０ 画像を取り込むステップと、
Ｓ２０ ImageHistoryクラス２０に画像を格納するステップと、
Ｓ３０ 現在とそれより前の画像の間の差分に従って画像を作成するステップと、
Ｓ４０ DifferenceHistoryクラス４０に差分画像の閾値型を格納するステップと、
Ｓ５０ ImageHistoryクラス２０に格納されている画像を分析し、ある画像から次の画像へと追跡するための有効なポイントを見出すステップと、
Ｓ６０ これらのポイントをPointsHistoryクラス６０内に格納するステップと、
Ｓ７０ 現在およびそれより前のフレームにおいて選択されたポイントの動きをモデル化するステップと、
Ｓ８０ ＵＩ制御に適する動作制約を適用するステップと、
Ｓ９０ 制約された動作をユーザー入力として解釈するステップと、を備える。
【０１８６】
ここで開示されるユーザー制御検出機構の実施例の作用に相当する、上記方法のさらに別の実施例は、本発明の範囲の想定内であることはいうまでもない。
【０１８７】
図１５は、ノイズ校正方法を説明するフローチャートである。すでに開示されているように、入力されたグレースケール画像をバイナリ画像に変えるために閾値をDifferenceMetricクラス３０内に設定することが必要とされる。ノイズ校正方法は、カメラ画像から効果的にノイズを取り除く一方で、好ましくは、できる限り低くすることできる閾値を見出すように設計される。また、暗騒音をサンプリングするためにユーザーがそのシーンから外に出ることなく達成できるものであることが好ましい。
【０１８８】
この方法は、DifferenceMetricクラス３０を校正するためにOpticalFlowクラス５０の関数を使用する。これによって、OpticalFlowクラス５０が動きとみなすものとDifferenceMetricクラス３０が動きとみなすものの間に、好適な対応関係があることを保証する。
【０１８９】
この方法は、以下のステップを備える。
【０１９０】
Ｓ１．移動ポイントを決定するために、全体の画像領域に亘って最終のＪ個のフレームに対してOpticalFlowクラス５０の計算を行うステップ。この計算を支援するためにDifferenceMetricクラス３０は使用しない。
【０１９１】
Ｓ２．PointHistory ６０からのすべての移動ポイントを識別して、それらを廃棄するステップ。
【０１９２】
Ｓ３．残っている各静止ポイントに対し、その位置におけるもっとも最近の、閾値差分画像でない画像を見て、その値を記録するステップ。これによって、静止している画像にあるポイントから一組の差分値が求められる。
【０１９３】
Ｓ４．統計学的に有意であるように充分な値を得るために、いくつかのフレームに対してステップ１から３を繰り返すステップ。
【０１９４】
Ｓ５．これらの静止差分値を、ゼロを中心とする正規分布としてモデル化し、変動量を算出するステップ。
【０１９５】
Ｓ６．この変動量にある程度適切な値（例えば３）を乗じ、それを差分距離閾値に対する基礎として使用するステップ。３という値は、静止ポイントは閾値の要因にはならないという９９．７％の信頼度を示している。
【０１９６】
別の実施例において、多くの連続したフレームに亘って、各ピクセルに対する差分値のヒストグラムを作成することによって、ノイズが校正される。これは、カメラノイズが常に存在し、かつレベルが同じぐらいなので、ヒストグラムでのピークを形成することが予想されるということを利用するものであり、これに対して、画像における実際の動きはランダムなものであり、広く分散する差分値を有する。結果的に、最小から最大まで差分値を見た場合に、ヒストグラムで発生する最初の明瞭なピークが平均ノイズ値であり、そこに閾値を設定する。
【０１９７】
いずれかの実施例によるノイズ校正を行う場合であっても、このときのシーンの照度が均一であることが好ましい。従って、好ましい実施例においては、テレビディスプレイによる輝度とカラー出力は校正の間は大きく変動すべきではない。主な目的は、テレビ画面による環境での照度における急激な変化によってシャドーが急速に変化し、それによって、見かけ上の動きが生じるのを回避するためである。これとは対照的に、ここで記載されている方法を通常に実行している間は、テレビまたは他の環境要因からの照度変化による見かけ上の動きに対して、各画像をトラッキングするための候補ポイントを評価することによって、有効に耐性を提供することができる。
【０１９８】
任意に、ランダムなカメラノイズを抑制するために、ノイズ低減法を使用することも可能であり、それによって、意図的な動きを区別する。カメラノイズのランダム性とは、空間または時間での平均化によって、効果的なノイズレベルを減らすことを意味する。しかしながら、（各ピクセルに対してｎ×ｎピクセル領域に亘る）空間での平均化は、小さいながらも真の動きに対する感度を減少させる一方で、（連続した画像に亘る）時間での平均化は、ゆっくりであっても真の動きに対する感度を減少させる。このように、これらの技術の適用性は、ビデオカメラのフレームレートまたは解像度にそれぞれ依存するものであり、またユーザーがインタラクションを行うと考えられる制御のタイプにも依存する。差分の閾値化をする前に、どのポイントにおいても平均化を適用できることはいうまでもない。オリジナルの画像から最良の結果が得られるとしても、これはグレースケール差分画像に対する単一平均化に比べると、（赤、緑、青値に対する）三回の平均化が必要であり、したがって、品質と計算負荷に関するこれらの比較値は、アプリケーションに依存する。
【０１９９】
ソフトウェアにより制御されたデータ処理装置によって、少なくとも部分的であっても、上記のような本発明の実施例が実行される限りは、このようなソフトウェアを提供するコンピュータプログラムと、このようなコンピュータプログラムが格納される記憶装置または伝送媒体が、本発明の態様として認識されることはいうまでもない。
【図面の簡単な説明】
【０２００】
【図１】図１は、プレイステーション２の全体的なシステムアーキテクチャを概略的に示す。
【図２】図２は、エモーション・エンジンのアーキテクチャを概略的に示す。
【図３】図３は、グラフィックス・シンセサイザの構成を概略的に示す。
【図４】図４は、ダイヤル制御を概略的に示す。
【図５】図５は、スクロール制御を概略的に示す。
【図６】図６は、ユーザー制御検出機構のブロック図である。
【図７】図７は、特徴点の比較について概略的に示す。
【図８】図８は、特徴点の比較について概略的に示す。
【図９】図９は、特徴点の比較について概略的に示す。
【図１０】図１０は、動作タイプを区別する際の問題点を示す。
【図１１】図１１は、２つの画像間の閾値差分を示す。
【図１２】図１２は、動作のタイプを区別するための手段を示す。
【図１３】図１３は、ソニー（登録商標）ＰＳＰ（登録商標）のナビゲーションシステムに対するユーザー制御検知機構の適用を例示する。
【図１４】図１４は、ユーザー制御検出の方法を示すフローチャートである。
【図１５】図１５は、ノイズ校正の方法を示すフローチャートである。
【技術分野】
【０００１】
本発明はデータ処理の制御に関する。特殊な例として、ビデオゲーム処理操作の制御に関連するが、本発明はより一般的に他の種類のデータ処理にも適用するものである。
【背景技術】
【０００２】
従来のビデオゲーム機において、ユーザーは、ビデオモニターまたはテレビ画面上のゲームを見て、手持ち式のキーパッドまたはジョイスティックを使用してゲームの操作を制御する。ソニー（Sony、登録商標）プレイステーション（PlayStation、登録商標）２等のゲーム機については、手持ち式コントローラが、２本のジョイスティックと数個のユーザー操作キーを提供するものがあり、これは、ゲーム内でイベントが生じた場合、ユーザーに対し触覚性のフィードバックを提供するための振動エレメントを伴う。
【０００３】
これらのゲーム機は、ビデオカメラを利用できることはすでに提案されている。これによって、ユーザーの画像をゲームシナリオの中に出現させることが可能となり、あるいは、空中で「ワンド」を振る等のユーザーのアクションを、ゲーム内のキャラクターが対応するアクションをするように変換できる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
この構成において不都合な点は、ゲーム機能間で切り換えを行う場合、さらに一般的にゲーム機の操作を制御する場合、手持ち式のコントローラを操作しなければならないということである。
【０００５】
制御について今まで出された提案は、一般的にユーザーが特殊な手袋をはめるようにするもので、特に、取り込まれた画像内で手袋をした手により検知を行うという特徴を有するものである。映画「マイノリティ・レポート」の中で、フィクションの例示が見られる。
【課題を解決するための手段】
【０００６】
本発明のさまざまな各態様および特徴は、添付の請求の範囲において定義される。従属クレームによる特徴は、必要に応じて独立クレームの特徴と組み合わせることが可能であり、ただ単にクレーム内で明確に列記されている特徴だけではない。
【０００７】
本発明の第一の態様は、ビデオカメラから連続した画像を受信するよう構成されたデータ処理装置を提供する。当該装置は、
データ処理装置の制御機能と対応づけられている画像領域内の選択されたポイントについて画像間動作を検出するための手段と、
該画像間動作について画像領域において検出が行われた場合、制御を実行するための手段と、を備え、
該検出手段は、ｍ個の連続する一群の画像に亘る画像領域内のポイントについて累積的画像間動作を検出することによって画像間動作を検出するよう構成され、ここでｍは少なくとも３であることを特徴とする。
【０００８】
本発明の別の態様は、次のステップから成るデータ処理方法を提供する。すなわち、
ビデオカメラから、連続した取り込まれた画像を受信するステップと、
データ処理装置の制御機能と対応づけられている画像領域内にある、選択されたポイントについて画像間動作を検出するステップと、
画像間動作が画像領域において検出された場合に制御機能を実行するステップと、を備え、
該検出ステップは、ｍ個の連続する一群の画像に亘る画像領域内のポイントについて累積的画像間動作を検出することによって、画像間動作を検出するよう構成され、ここでｍは少なくとも３であることを特徴とする。
【０００９】
本発明の別の態様は、上記の方法を実行するためのプログラムコードを有するコンピュータ・ソフトウェアを提供する。当該コンピュータ・ソフトウェアは、伝送媒体または記憶媒体等の準備媒体により提供されることが好ましい。
【００１０】
本発明のさらなる個々の態様および特徴は、添付の請求の範囲において定義される。明示されない場合であっても、従属クレームの特徴は、さまざまに異なる独立クレームに対して適用される。
【発明を実施するための最良の形態】
【００１１】
以下、例証のみを目的として、添付の図面を参照しながら本発明の実施例について説明する。
【００１２】
図１は、プレイステーション２の全体的なシステムアーキテクチャを概略的に示すものである。システム・ユニット１０は、システム・ユニットに接続可能なさまざまな周辺デバイスを備える。
【００１３】
システム・ユニット１０は、エモーション・エンジン１００と、グラフィックス・シンセサイザ２００と、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）を有するサウンドプロセッサ・ユニット３００と、読み出し専用メモリ（ＲＯＭ）４００と、コンパクトディスク（ＣＤ）およびデジタル多用途ディスク（ＤＶＤ）リーダ４５０と、ランバス・ダイナミックランダムアクセスメモリ（ＲＤＲＡＭ）ユニット５００と、専用ＲＡＭ７５０を有する入出力プロセッサ（ＩＯＰ）７００とを備える。（任意の）外付けハードディスクドライブ（ＨＤＤ）８００を接続する場合もある。
【００１４】
入出力プロセッサ７００は、２本のユニバーサル・シリアル・バス（ＵＳＢ）ポート７１５およびｉＬｉｎｋまたはＩＥＥＥ１３９４ポート（ｉＬｉｎｋは、株式会社ソニーがＩＥＥＥ１３９４標準を実現したもの）を有する。ＩＯＰ７００は、ＵＳＢ、ｉＬｉｎｋ、およびゲームコントローラのデータトラフィックのすべてを取り扱う。例えば、ユーザーがゲームをしているときに、ＩＯＰ７００はゲームコントローラからデータを受信し、このデータをエモーション・エンジン１００へと送りだし、エモーション・エンジンは、それに従ってゲームの現在の状況を更新する。ＩＯＰ７００は、迅速なデータ転送速度を容易に実現するダイレクト・メモリ・アクセス（ＤＭＡ）アーキテクチャを有する。ＤＭＡは、ＣＰＵを通過させずにメインメモリからデバイスへデータ転送を行う。ＵＳＢインターフェースは、オープンホスト・コントローラ・インターフェース（ＯＨＣＩ）と互換性があり、１．５Ｍｂｐｓから１２Ｍｂｐｓまでのデータ転送速度を処理できる。これらのインターフェースが装備されているということは、つまり、プレイステーション２は、ビデオカセット、レコーダー（ＶＣＲｓ）、デジタルカメラ、セットトップボックス、プリンタ、キーボード、マウスおよびジョイスティック等の周辺デバイスと潜在的に互換性があることを意味する。
【００１５】
通常、ＵＳＢポート７１５に接続している周辺デバイスとのデータ通信が円滑に行われるように、デバイスドライバ等の適切なソフトウェアを備えなければならない。デバイスドライバ技術は大変によく知られているので、ここで詳細は記載しないが、当業者であれば、ここに記載する実施例において、デバイスドライバまたは類似のソフトウェア・インターフェースが必要であると認識していることはいうまでもない。
【００１６】
本実施例において、対応するマイクロフォン７３５とＬＥＤインジケータ７４０が装備されたビデオカメラ７３０がＵＳＢポートに接続されている。様々なタイプのビデオカメラを使用できるが、ビデオカメラ７３５として特にふさわしいタイプは、いわゆる「ウェブカム」である。すなわちこれは、単一の電荷結合素子（ＣＣＤ）エレメントに基づく中分解能カメラであって、基本ハードウェアをベースとするリアルタイムデータ圧縮およびエンコーディング構成を含んでいるので、圧縮ビデオオーディオデータが、例えば画像内部をベースとするＭＰＥＧ（モーション・ピクチャ・エキスパート・グループ）標準等の適切なフォーマットでカメラ７３０からＵＳＢポート７１５へと送信され、プレイステーション２システム・ユニット１０においてデコーディングされる。カメラＬＥＤインジケータ７４０は、システム・ユニット１０とのＵＳＢデータ接続を介して制御データを受信し、このような制御データに応答して点灯するように構成される。
【００１７】
ＵＳＢポートとは別の、２本の他のポート７０５、７１０は、ゲーム関連の情報を格納するための専用不揮発性ＲＡＭメモリーカード７２０、手持ち式ゲームコントローラ７２５、または、例えばダンス・マット等の手持ち式コントローラに似たようなデバイス（図示せず）の接続を可能とする専用ソケットである。
【００１８】
エモーション・エンジン１００は、１２８ビット中央演算処理装置（ＣＰＵ）であり、特にゲームアプリケーション用の三次元（３Ｄ）グラフィックスを効果的にシミュレーションするために設計されたものである。エモーション・エンジンの構成要素は、データバス、キャッシュメモリ、およびレジスタを含み、いずれも１２８ビットである。これによって、大容量マルチメディアデータの迅速な処理を容易にする。これと比較すると、従来のＰＣは、基本６４ビットのデータ構造を有する。プレイステーション２の浮動小数点演算性能は、６．２ＧＦＬＯＰｓである。エモーション・エンジンはまた、ＭＰＥＧ２デコーダ回路を備え、３ＤグラフィックスデータとＤＶＤデータの同時処理を可能にする。エモーション・エンジンは、数学的変換およびトランスレーションを含む幾何学的計算を実行し、更に、例えば２つのオブジェクト間の摩擦の算出などのシミュレーションオブジェクトの物理的過程に関連する計算を行う。これによって、その次にグラフィックス・シンセサイザ２００によって利用される画像レンダリングコマンドのシーケンスを作成される。画像レンダリングコマンドは、表示リスト形式で出力される。表示リストとは、描画コマンドのシーケンスであり、グラフィックス・シンセサイザに対して、どの初期グラフィックオブジェクト（例えば、点、線、三角形、スプライトなど）を画面上に描くか、および、どの座標に描くかを指示する。このように、典型的な表示リストは、頂点を描くためのコマンド、ポリゴン面に陰影をつけたり、ビットマップを描いたりする等のコマンドを含む。エモーション・エンジン１００は、非同期で複数の表示リストを作成できる。
【００１９】
グラフィックス・シンセサイザ２００は、エモーション・エンジン１００により作成された表示リストのレンダリングを行うビデオ・アクセラレータである。グラフィックス・シンセサイザ２００は、複数の表示リストを処理し、追跡記録し、管理するグラフィックス・インターフェースユニット（ＧＩＦ）を含む。グラフィックス・シンセサイザ２００のレンダリング機能は、選択肢となるいくつかの標準出力画像フォーマット、すなわちＮＴＳＣ／ＰＡＬ、高精細度デジタルテレビ、およびＶＥＳＡをサポートする画像データを作成できる。一般に、グラフィックス・システムのレンダリング能力は、それぞれがグラフィックス・プロセッサ内に位置するピクセルエンジンとビデオメモリの間のメモリ帯域幅により定められる。従来のグラフィックス・システムは、外付けのビデオ・ランダム・アクセス・メモリ（ＶＲＡＭ）を使用しており、これはオフチップバスを介してピクセルロジックに接続されるので、有効な帯域幅を制限する傾向にある。しかしながら、プレイステーション２のグラフィックス・シンセサイザ２００は、単一の高性能チップ上のピクセルロジックおよびビデオメモリを提供し、これによって、毎秒３８．４ギガバイトという比較的大きいメモリアクセス帯域幅を可能にする。グラフィックス・シンセサイザは、理論的に、毎秒７５００万ポリゴンの最高描画容量を達成することが可能である。テクスチャ、ライティング、およびトランスペアレンシー等のあらゆるエフェクトを用いた場合であっても、毎秒２０００万ポリゴンの持続速度で連続して描画することが可能である。従って、グラフィックス・シンセサイザ２００は、フィルム品質の画像を描画することができる。
【００２０】
サウンドプロセッサ・ユニット（ＳＰＵ）３００は、事実上、本システムのサウンドカードであり、デジタル多用途ディスク（ＤＶＤｓ）に使用されるサウンドフォーマットであるデジタル・シアター・サラウンド（ＤＴＳ、登録商標）サウンドやＡＣ−３（ドルビーデジタルとしても知られる）のような３Ｄデジタルサウンドを認識できる。
【００２１】
対応するスピーカー構成３１０を伴ったビデオモニターあるいはテレビ等のディスプレイおよびサウンド出力装置３０５は、グラフィックス・シンセサイザ２００およびサウンドプロセッッサ・ユニット３００に接続され、ビデオ信号およびオーディオ信号を受信する。
【００２２】
エモーション・エンジン１００をサポートするメインメモリは、ランバス（Rambus）社製のＲＤＲＡＭ（ランバス・ダイナミック・ランダムアクセスメモリ）モジュール５００である。このＲＤＲＡＭメモリー・サブシステムは、ＲＡＭ、ＲＡＭコントローラ、およびＲＡＭをエモーション・エンジン１００に接続するバスを備える。
【００２３】
図２は、図１のエモーション・エンジン１００のアーキテクチャを概略的に示したものである。エモーション・エンジン１００は、浮動小数点ユニット（ＦＰＵ）１０４と、中央演算処理装置（ＣＰＵ）コア１０２と、ベクトルユニット・ゼロ（ＶＵ０）１０６と、ベクトルユニット・ワン（ＶＵ１）１０８と、グラフィックス・インターフェース・ユニット（ＧＩＦ）１１０と、割り込みコントローラ（ＩＮＴＣ）１１２と、タイマーユニット１１４と、ダイレクト・メモリ・アクセス・コントローラ１１６と、画像データ処理ユニット（ＩＰＵ）１１６と、ダイナミック・ランダム・アクセスメモリ・コントローラ（ＤＲＡＭＣ）１２０と、サブバスインターフェース（ＳＩＦ）１２２と、を備え、これらの構成要素の全ては、１２８ビット・メインバス１２４を介して接続される。
【００２４】
ＣＰＵコア１０２は、３００ＭＨｚでクロック制御される１２８ビットプロセッサである。ＣＰＵコアは、ＤＲＡＭＣ１２０を介して、メインメモリの３２ＭＢにアクセスする。ＣＰＵコア１０２の命令セットは、さらにマルチメディア命令を追加したＭＩＰＳ IV ＲＩＳＣ命令のいくつかを有するＭＩＰＳ III ＲＩＳＣに基づくものである。ＭＩＰＳ IIIおよびIVは、ＭＩＰＳテクノロジー社が所有する縮小命令セットコンピュータ（ＲＩＳＣ）命令セットアーキテクチャである。標準の命令は、６４ビットのツーウェイ・スーパースカラであり、これは、二つの命令を同時に実行できることを意味する。一方、マルチメディア命令は、二本のパイプラインを介した１２８ビット命令を使用する。ＣＰＵコア１０２は、１６ＫＢの命令キャッシュ、８ＫＢのデータキャッシュ、および、ＣＰＵによるダイレクトプライベート使用のために確保されるキャッシュの一部である１６ＫＢのスクラッチパッドＲＡＭを備える。
【００２５】
ＦＰＵ１０４は、ＣＰＵコア１０２用の第一コプロセッサとしての機能を果たす。ベクトルユニット１０６は、第二のコプロセッサとして機能する。ＦＰＵ１０４は、浮動小数点積和演算器（ＦＭＡＣ）および浮動小数点除算演算器（ＦＤＩＶ）を備える。ＦＭＡＣおよびＦＤＩＶはどちらも３２ビット値で演算を行うので、演算が１２８ビット値（４つの３２ビット値から成る）で実行されると、４つのすべての部分において、並行して演算を実行できる。
【００２６】
ベクトルユニット１０６および１０８は、数値演算を実行するものであって、ベクトル方程式の乗算および加算で数値を求める場合に極めて高速に行うことができる、基本的に専門ＦＰＵである。これらは、加算と乗算演算のための浮動小数点積和演算器（ＦＭＡＣ）、および除算と平方根演算のための浮動小数点除算演算器（ＦＤＩＶ）を使用する。また、これらは、マイクロプログラムを格納するための内蔵メモリを有し、ベクトル・インターフェース・ユニット（ＶＩＦｓ）を介して、システムの残りの部分とのインターフェースをとる。ベクトルユニット・ゼロ１０６は、専用１２８ビットバス１２４を介してＣＰＵコア１０２に対するコプロセッサとして機能することが可能であり、従って、これは基本的に第二の専門ＦＰＵである。一方、ベクトルユニット・ワン１０８は、グラフィックス・シンセサイザ２００への専用バスを有するので、それによって、完全に分離したプロセッサであると考えられる。二台のベクトルユニットを搭載することによって、ソフトウェア開発者は、ＣＰＵの異なる部分間で作業を切り分けることが可能となり、これらのベクトルユニットはシリアルまたはパラレル接続のいずれかで使用できる。
【００２７】
ベクトルユニット・ゼロ１０６は、四つのＦＭＡＣＳと、一つのＦＤＩＶを備える。これは、コプロセッサ接続を介してＣＰＵコア１０２に接続している。また、データ用ベクトルユニットメモリ４Ｋｂと、命令用マイクロメモリ４Ｋｂを有する。ベクトルユニット・ゼロ１０６は、表示用画像に関連する物理計算を行うために有用である。これは主に、ＣＰＵコア１０２と共に非パターン化幾何学処理を実行する。
【００２８】
ベクトルユニット・ワン１０８は、五つのＦＭＡＣＳと二つのＦＤＩＶとを備える。これは、ＧＩＦユニット１１０へのダイレクトパスは有するが、ＣＰＵコア１０２へのダイレクトパスを有しない。また、データ用ベクトルユニットメモリ１６Ｋｂと、命令用マイクロメモリ１６Ｋｂを有する。ベクトルユニット・ワン１０８は、変換を実行する際に有用である。これは、主にパターン化された幾何学処理を実行して、作成された表示リストをＧＩＦ１１０に直接出力する。
【００２９】
ＧＩＦ１１０は、グラフィックス・シンセサイザ２００に対するインタフェースユニットである。表示リストパケットの最初のタグ指定に従って、データを変換し、相互に複数の転送を調整しながら、描画コマンドをグラフィックス・シンセサイザ２００に転送する。割り込みコントローラ（ＩＮＴＣ）１１２は、ＤＭＡＣ１１６を除いた周辺デバイスからの割り込みを調整する役割を果たす。
【００３０】
タイマーユニット１１４は、１６ビットカウンタを有する四つの独立したタイマーから成る。このタイマーは、バスクロック（１／１６または１／２５６間隔）によって、または外部クロックを介して駆動される。ＤＭＡＣ１１６は、メインメモリおよび周辺処理装置間の、または、メインメモリおよびスクラッチパッドメモリ間のデータ転送を行う。同時に、メインバス１２４を調整する。ＤＭＡＣ１１６のパフォーマンス最適化は、エモーション・エンジン性能を向上させる鍵となる方法である。画像処理装置（ＩＰＵ）１１８は、圧縮された動画およびテクスチャ画像を展開するために用いる画像データプロセッサである。これは、Ｉ−ＰＩＣＴＵＲＥマクロブロック・デコーディング、カラースペース変換、およびベクトル量子化を実行する。最後に、サブバスインターフェース（ＳＩＦ）１２２は、ＩＯＰ７００に対するインタフェースユニットである。サウンドチップおよび記憶装置等の入出力装置を制御するために、サブバスインターフェースは、それ自体のメモリおよびバスを有する。
【００３１】
図３は、グラフィックス・シンセサイザ２００の構成を概略的に示したものである。グラフィックス・シンセサイザは、ホストインターフェース２０２、セットアップ・ラスタライズユニット２０４、ピクセルパイプライン２０６、メモリインターフェース２０８、フレームページ・バッファ２１４およびテクスチャページ・バッファ２１６を含むローカルメモリ２１２、およびビデオコンバータ２１０を備える。
【００３２】
ホストインターフェース２０２は、ホストとデータのやりとりを行う（エモーション・エンジン１００のＣＰＵコア１０２の場合）。ホストからの描画データおよびバッファデータは双方とも、このインターフェースを通過する。ホストインターフェース２０２からの出力は、グラフィックス・シンセサイザ２００に供給される。このグラフィックス・シンセサイザ２００は、グラフィックスを展開し、エモーション・エンジン１００から受け取った頂点情報に基づいてピクセルを描画し、各ピクセルの、ＲＧＢＡ値、深度値（例えばＺ値）、テクスチャ値およびフォグ値等の情報を算出する。ＲＧＢＡ値は、赤、緑、青（ＲＧＢ）のカラー構成要素を特定し、Α（アルファ）構成要素は画像オブジェクトの不透明性を表す。アルファ値は、完全に透明から完全に不透明まで変化させることができる。ピクセルデータは、ピクセルパイプライン２０６に供給され、ここで、テクスチャマッピング、フォギングおよびアルファブレンディング等の処理を行い、算出されたピクセル情報に基づいて最終的な描画のカラーを決定する。
【００３３】
ピクセルパイプライン２０６は、１６個のピクセルエンジンＰＥ１、ＰＥ２、・・・ＰＥ１６を備え、最大１６ピクセルを同時に処理できる。ピクセルパイプライン２０６は、３２ビットカラーおよび３２ビットＺバッファで、１５０ＭＨｚで動作する。メモリインターフェース２０８は、ローカル・グラフィックス・シンセサイザ・メモリ２１２からデータを読み込み、かつ、書き込みを行う。ピクセル操作の終了時には、メモリに対して描画ピクセル値（ＲＧＢＡおよびＺ）を書き込み、メモリからフレームバッファ２１４のピクセル値を読み込む。フレームバッファ２１４から読み込まれるこれらのピクセル値は、ピクセルテストまたはアルファブレンディングのために使用される。メモリインターフェース２０８はまた、ローカルメモリ２１２から、フレームバッファの現在の内容に対するＲＧＢＡ値を読み込む。ローカルメモリ２１２は、グラフィックス・シンセサイザ２００に内蔵される３２Ｍビット（４ＭＢ）のメモリである。これは、フレームバッファ２１４、テクスチャバッファ２１６および３２ビットＺバッファ２１５で構成できる。フレームバッファ２１４は、カラー情報のようなピクセルデータが格納されるビデオメモリの部分である。
【００３４】
グラフィックス・シンセサイザは、視覚的な細部を三次元ジオメトリに加えるために、二次元から三次元へのテクスチャマッピング処理を使用する。各テクスチャは、三次元画像オブジェクトの周囲に巻きつけられ、伸ばされ、そして曲げられて、三次元のグラフィック効果を与える。テクスチャバッファは、画像オブジェクトに対するテクスチャ情報を格納するために使用される。Ｚバッファ２１５（別名、深度バッファ）は、ピクセルについての深度情報を格納するために利用できるメモリである。画像は、グラフィックスプリミティブまたはポリゴンとして知られる基本構成ブロックにより構築される。ポリゴンが、Ｚバッファリングを使って描かれる場合、各ピクセルの深度値は、Ｚバッファに格納される対応する値と比較される。Ｚバッファに格納される値が新しいピクセル値の深度以上の場合、このピクセルが可視であると決定され、その結果、そのピクセルは描画されることとなって、Ｚバッファは新しいピクセル深度により更新される。しかしながら、Ｚバッファ深度値が新しいピクセル深度値よりも小さい場合、新しいピクセル値はすでに描画されたものの後ろ側にあって、描かれることはない。
【００３５】
ローカルメモリ２１２は、フレームバッファとＺバッファとにアクセスするための１０２４ビットの読み込みポートおよび１０２４ピットの書き込みポート、およびテクスチャ読込み用の５１２ビットのポートを有する。ビデオコンバータ２１０は、ある特定の出力フォーマットにおいて、フレームメモリの内容を表示するよう機能する。
【００３６】
図４および図５により、いくつかの異なるユーザーインターフェース（ＵＩ）制御について説明する。
【００３７】
図４は、概略的にダイヤル制御を示したものである。
【００３８】
図４における長方形のアウトラインは、カメラ７３０によって取り込まれ、ディスプレイ３０５上に表示されている画像の外縁を概略的に表すものである。動作中、カメラ７３０によって、取り込まれる連続した画像またはフレームは、エモーション・エンジン１００によって、グラフィックス・シンセサイザ２００に渡され、グラフィックス・シンセサイザのビデオ出力のすべてあるいは一部に対する背景として表示される。
【００３９】
本実施例では、カメラ７３０は、ユーザー１０００の方へ向けられている。
【００４０】
ダイヤル制御１０１０は、（グラフィックス・シンセサイザによって、）背景取り込み画像上に重畳される。このダイヤル制御は、ポインタ１０２０がその中で表示される円形ボーダー１０１５を備える。ポインタは、ゲームまたはゲーム機の変数に対応づけてもよい。その結果、（例えば）時計回りにポインタを動かすことにより変数を増やし、逆に、反時計回りにポインタを動かすことにより変数を減少させる。このような方法で、ダイヤル制御は、ポテンショメータのような機械的回転制御の操作をシミュレーションすることができる。ポインタができる動きは、点線で示される。ユーザーがポインタをどのように動作させるかについては後述する。
【００４１】
ダイヤル制御を操作するために、ユーザーは、ボーダー１０１５内の少なくとも一部に手を置く。そして、ユーザーの手の動きが、ポインタ１０２０の軸（回転中心）１０３０を基準として検出される。この動きがどのように検出されるかについては後述するが、このような検出によって次のような効果がある。すなわち、もしボーダー１０１５内のユーザーの手の全体の動きが中心１０３０を基準として時計回り方向であると検出された場合、ポインタは、それに対応して時計回りに動かされる（そして、ゲームまたはゲーム機の変数は増加する）。もしボーダー１０１５内のユーザーの手の全体の動きが中心１０３０を基準として反時計回り方向であると検出された場合、ポインタは、それに対応して反時計回りに動かされる（そして、ゲームまたはゲーム機の変数は減少する）。ポインタの動きまたは回転は、手の動きと同じあるいは比例するよう構成できる。また、仮想の「エンドストップ」を備えることもできる。それによって、特定の方向への連続した手の動きが、ポインタの連続した回転につながることなく、エンドストップの一方に到達したときにポインタの回転が止まるようにする。
【００４２】
任意に、円形ボーダー１０１５の中で適切な動きが検出されない場合、ダイヤルをロックする（動きを抑制する）ことができ、それによって、偶発的に調整されてしまうことを防ぐ。このダイヤルは、色を変えることによって、そのロック状況を示唆できる。
【００４３】
ゲームまたはゲーム機の変数は、ただちに変更することができる。または、このような変更は、ユーザーがポインタの回転を止めるまで、あるいはボーダー１０１５内部から手を引き出すまで保留できる。ダイヤル制御を容易にしている機構については、後述する。
【００４４】
図５は、スクロール制御に関して概略的に示したものである。
【００４５】
図４に似たような方法で、スクロールアイコン１０５０は、カメラ７３０から取り込まれたユーザー１０００の画像上に重畳される。本実施例では、このスクロールアイコンは垂直にスクロールように構成されるが、もちろん、適切な方向であればどの方向にスクロールさせてもよい（または実際には、例えばスクロールアイコンがたくさん並んでいる場合は複数の方向でもよい）。このアイコンは、いつでも、現在見えているものを超えて拡張可能である。エンドレスなルーレット式フォーマットに構成するのが好ましいが、単純なライン構造に構成することも可能である。
【００４６】
ここでの基本概念は、一般的な垂直方向の手の動きによって、（または、非垂直方向な手の動きの垂直成分によって）、アイコンを上下にスクロールさせることができるということである。前述の通り、アイコンのスクロール動作は、ユーザーの手の垂直な動作と等しくすることが可能であり、そうでなければ、このような動作に比例する、または、依存するものであるようにできる。この垂直動作は、アイコンを囲んでいる画像の領域１０６０内で検出できる。
【００４７】
検出領域１０６０は他の選択肢も可能である。ユーザーが、ある特定の方向にアイコンを垂直方向にスクロールさせる動きを開始し、領域１０６０から手を引き出しながら、垂直方向に手を動かし続けることができる。このアイコンは、エンドレスに、または、減衰（減速）するように、垂直にスクロールし続けることができる。ユーザーは、領域１０６０の中に、静止している手または動いている手を再び入れることによって、この連続した動きを止める（逆転させるあるいは強化する）ことができる。
【００４８】
選択ボックス１０７０を説明する。一般的にこれは、ディスプレイ内で静止しており、所望のアイコンが選択ボックス内に入るまでアイコンを上下させることにより、アイコンの一つを選択できる。従って、もしアイコンが（例えば）ゲームオプションまたは音楽トラックを表わす場合は、ユーザーが、ボックス１０７０内にアイコンを配置することによって、ゲームオプションを実行する、または音楽トラックを再生させることが可能である。
【００４９】
スクロール制御を容易にする機構について後述する。
【００５０】
再び図４を参照すると、ダイヤル制御の変形として、ホイール制御がある。ホイール制御は、ダイヤル制御と同様の方法で動作する。しかし、ホイールの動きは、ユーザーがホイールボーダー１０１５によって囲まれている領域内で動作を開始し、ホイールボーダー１０１５から手を引き出しながら手を動かし続けることによって、ホイールを回転させることができる点において、スクロール制御に類似している。このアクションの間、手の動きが一貫している場合、ホイールは、あたかも自身の運動量で動くように、エンドレスにまたは減衰（減速）するようにスピンし続ける。ユーザーは、必要に応じて、ホイールボーダー１０１５により囲まれている領域内に、静止した手または動いている手を再度入れることによって、この継続している動きを停止（逆転または強化）させることができる。
【００５１】
このホイール制御は、例えば、垂直スクロールアイテムが円形状をなしているホイール上に示されたオプションから選択を行うために、またはアクションを行う際にゲームキャラクターが使用するエネルギーレベルを表わすために、使用してもよい。
【００５２】
任意に、ホイールは常にロックを外した状態にしておくことが可能であり、それによって、ホイールボーダー１０１５内で検出されたどんな動きでも、潜在的にスピンを誘発するようにすることができる。
【００５３】
ホイール制御を容易にしている機構については、後述する。
【００５４】
図６は、ソフトウェア命令下で動作するエモーション・エンジン１００により実行されるユーザー制御検出機構を示すブロック図である。説明を簡略化するため、この図はオブジェクト指向プログラムのためのオブジェクトクラスを示すものであり、ここでクラスは、データとそのデータ上で動作可能な関数とを備える。例えば、Imageクラス１０は、画像内の各ピクセルの幅、高さ、カラーチャンネルの数、およびそのカラー等の情報を含むことが可能である。また、Imageクラス１０は、このデータに作用する関数をたくさん有することができる。例えば、GetNumPixels()、GetPixelColour(int x、int y)、およびSetPixelColour(int x、int y、Colour RGB）はそれぞれ、画像サイズの数値を決め、所定の座標上にあるピクセルのカラー値を取得し、所定の座標におけるピクセルのカラー値を設定することを表す。
【００５５】
従って、以下の説明において、あるクラスがある特性または情報を有すると言われる場合、それはそのクラス内のデータについて言及しているのであり、一方、そのクラスがそのような情報に作用していると言われるときは、そのクラス内の関数に関連する、と理解される。
【００５６】
図６において、要約すると、エモーション・エンジン１００等のデータ処理装置に取り付けられたビデオカメラ７３０が、画像（すなわち、Imageクラス１０に属するデータ）を作成する。ImageHistoryクラス２０は、最終のＪ個の画像を格納する。DifferenceMetricクラス３０は、現在およびそれより以前の画像を保持し、それらを処理して、連続画像がどこで異なっているか、またどの程度異なるかを示す画像を作成する。これらの差分画像は、閾値とされDifferenceHistoryクラス４０に格納される。OpticalFlowクラス５０における関数は、ImageHistoryクラス２０内の画像を分析して、一つの画像から次の画像まで追跡するための有効で認識可能なポイントを見つけ出す。任意に、OpticalFlowクラス５０における関数は、DifferenceHistoryクラス４０を使って、この処理を検証し処理速度を上げることができる。PointHistoryクラス６０は、OpticalFlowクラス５０の関数により識別されたポイントのリストと、ImageHistoryクラス２０内の各画像のどこにそれらのポイントが位置するかを格納する。
【００５７】
次に、MotionModelクラス７０は、これらのポイントのペアの間で位置変更に相当する動きをモデル化する。現在およびその前の画像に対する移動ポイントについてその前後位置のリストを作り、それらの位置から規定どおりに、トランスレーション、スケールおよび回転モデルを作成する。任意に、MotionConstraintクラス８０は、算出されたオブジェクトの動き・位置を取り込み、ユーザーインターフェース（ＵＩ）制御の所望の動きに従って、それを制限する（例えば、廃棄トランスレーション）。
【００５８】
UserlnterfaceControl（UlControl）クラス９０は、PointHistoryクラス６０内の位置を取り込み、MotionModelクラス７０に対してそれらを供給し、それから結果として生じる動作を取り入れて、MotionConstraintsクラス８０から、一般的に一つまたは複数の制約を適用する。
【００５９】
これによって、この制約された動作は、個々のＵＩ制御の動きを表す。
【００６０】
ここで、本発明の実施例のための、これらのクラスの詳細について説明する。
【００６１】
Imageクラス(１０)は、画像のサイズ（幅と高さ）、カラーチャンネルごとに可能な輝度値の数、およびカラーチャンネルの数を保持する。画像のサイズは、カメラの解像度（例えば３２０×２４０または６４０×４８０）に依存することが多い。しかし、制御が画面の小さな領域でのみ行われる場合、任意にこの小さな領域が画像として扱われ、元画像の残りは廃棄してもよい。
【００６２】
一般的に使用される画像についての三つの主要なタイプは、以下のものである。
【００６３】
i．カラー画像（３カラーチャンネル、各チャネルに対して２５６輝度値）
ii．グレースケール画像（２５６輝度値を伴った１カラーチャンネル）
iii．バイナリ画像（２輝度値を伴った１カラーチャンネル−白黒）
ビデオカメラ７３０は、ある程度固定したフレームレート（例えば毎秒３０、６０、または１２０フレーム）で、カラー画像を作成する。これらは、ImageHistory ２０に渡される前に、グレースケール画像に変換される。
【００６４】
ImageHistoryクラス２０は、上記のようにカメラから取り込まれる最終のＪ 個のグレースケール画像を格納する。新規画像が追加される毎に、最も古いものは保管画像の端から落とされる。例えば、Ｊは、３から１４あるいはそれ以上の場合もある。
【００６５】
DifferenceMetricクラス３０は、二つの画像間の差分を算出して、それを閾値とする関数を提供する。この関数は、入力として二つのカラー画像（例えば、現在およびそれ以前の画像）を取り込む。各ピクセルに対し、各カラーチャンネルにおける差分が合計され、結果として生じる値によってグレースケール画像を作成される。その後、この画像は、スリーポイント・ガウシアンブラー・コンボリューションフィルター（three point Gaussian blur convolution filter）を用いて滑らかにされ、ある程度のトレランスが与えられる。最後に、この画像は閾値とされ、画像のどの部分が十分な量の変化があったかを示すバイナリ画像を生成する。この差分閾値がどのように選択されるかについては、ノイズ校正に関連して後で開示する。
【００６６】
このように、DifferenceMetricクラス３０は、差分データを作成するよう動作可能であり、二つの連続する画像の間のピクセル値における差分に比例する一連の値を備え、この後、差分データを滑らかにするよう動作可能である。
【００６７】
さらに、DifferenceMetricクラス３０は、算出された差分閾値レベルで、差分データに閾値を適用するように動作可能で、結果として生じるバイナリ差分データを出力する。
【００６８】
DifferenceHistoryクラス４０は、一連のＮ−１バイナリ画像を提供する。それぞれの画像が、DifferenceMetricクラス３０から取得した、ImageHistory内の二つの連続する画像間の差分を維持する。ImageHistoryクラス２０と同様に、新規な画像が加えられるたびに、格納されたもののうち最も古いものは廃棄される。
【００６９】
さらに、これはまた「累積的な差分画像」を維持する。DifferenceHistory内の個々の画像のいずれかが白いピクセルを有する場合、これは白いピクセルを有するバイナリ画像である。従って、これはDifferenceHistoryクラス４０内の個々の画像の論理和関数とみなすことが可能である。もちろん、「黒」および「白」として表現するのは、ただ単に本説明を明確化するためである。実際には、このデータはピクセル位置ごとに１ビットとして格納されてもよく、あるいは、記憶装置内の効率性により他のフォーマットで格納することも可能である。目的は、ピクセル位置に対して検出動作をマップすることにある。
【００７０】
例えば、別の静的な場面において、ある人が挨拶の際に手を振った場合、その累積する差分画像は、一般的にその人の肘を原点とする弓形に類似するものであり、ウェーブの範囲に相当する円弧の範囲を定める。
【００７１】
このように、DifferenceHistoryクラス４０は、一連の画像に対するバイナリ差分データを組み合わせるよう動作可能であり、算出差分閾値を超えた連続画像間の差分を示した一連の画像全体に亘るすべての点を示す累積バイナリ差分画像を作成する。
【００７２】
OpticalFlowクラス５０は、特徴ポイントとして作用する最新画像内のポイントを見つけ出し、ImageHistoryクラス２０内の３つ以上の画像を通じてそれらのポイントを逆向きに追跡する。
【００７３】
本発明の実施例において、ポイント追跡は、Lucas-Kanade ポイントトラッカに基づいている。これは１９８１年に開発され、Lucas, B., and Kanade, T., 「An Iterative Image Registration Technique with an Application to Stereo Vision」、第７回人工知能国際合同会議 7 (ＩＪＣＡＩ)の声明書、６７４〜６７９ページにおいて公開されている。
【００７４】
現在の画像、およびその前の画像の、二つの画像を与えられ、Lucas-Kanadeトラッカは、以下を行う。
【００７５】
１．画像内の各ピクセルと対応づけられている固有値を分析することによって容易に認識可能な、現在の画像上の一セットの位置を定める。
【００７６】
２．前の画像内で、これらのポイントに最も近く一致するものを見つける。
【００７７】
３．見つけた場合、画像上で識別可能なポイントについての、前のおよび現在の位置を示す、一セットの位置のペアを出力する。
【００７８】
このように、OpticalFlowクラス５０は、現在の画像内で選択されたポイントとの対応関係に基づいて、前の画像内のポイントを選択するよう動作可能である。
【００７９】
例示されているポイントは、画像内での形状の端部を表わすものであるか、または、このような形状の凹頂点を表わすポイントである。手を例にとると、特徴ポイントは、指の先端、および隣り合う指の間の頂点で識別される。
【００８０】
図７乃至図９は、Lucas-Kanadeポイントトラッカにおける特徴ポイントの検出を概略的に示したものである。
【００８１】
図７は、制御画像領域内のユーザーの手について取り込まれた画像を表わしていると仮定する。従って、図７の範囲は、取り込まれた画像全体の一部にしか過ぎず、これは（例えば）ボーダー１０１５または領域１０６０内にある部分である。
【００８２】
上記に説明したように特徴ポイント２１００が検出される。以下の説明を明瞭にするために、一つの特徴ポイント、つまり、ユーザーの親指先端の位置のポイント２１１０だけを考慮するが、同様の説明がすべての検出特徴ポイントに適用可能である。
【００８３】
Lucas-Kanadeのトラッキング処理を連続して使用することにより、特徴ポイント２１１０は、それぞれ対応する図８と図９の特徴ポイント２１１０’と２１１０”と相関する。これによって、図８と図９において概略的に示されているように、図示されているような事前の親指位置によって、手の動きが表わされることになる。
【００８４】
しかしながら、Lucas-Kanadeトラッカは、多くの問題に陥りやすい。特に、画像内の自己相似性により（例えばタイル張りや草木など）、無関係なポイントが画像間で相関して表れてしまう可能性があり、偽の見かけだけの動きを作り出してしまう。さらに、画像ノイズによる見かけ上のポイントの動きと、真の動き（小さい動きや遅い動き）は区別することができない。もし詳細なＵＩ制御を実現することが望ましいのであれば、このような区別が特に重大になってくる。これらの問題点について以下に詳述する。
【００８５】
問題点１：
例えば、壁、天井、または床のタイルの線に沿ったタイル間の接合は、全て非常に類似して見える。一つのフレームから次のフレームへのカメラ画像における、わずかなノイズまたはブレにより、次の画像において、一つの接合点が、そのライン上のどこか別の接合点に似て見えてしまうことがある。結果的に、画像ノイズによって、Lucas-Kanadeトラッカのステップ２におけるポイントマッチが、フレーム間で異なるタイル接合点を対応づけてしまうことになり、見かけ上の動きを生じさせてしまう可能性がある。似たような問題は、壁紙や縞模様のＴシャツなどの繰り返し模様の場合に起こりうる。
【００８６】
問題点２：
問題点１と同様に、タイルやプリントの繰り返し模様などのように完全に類似するものではないとしても、草木などのような自己相似性オブジェクトは十分に類似性があるので、以下の例示シナリオにおいて問題を生じ得る。ユーザーが手を上げて室内用鉢植えの前に立っており、植物の最上部は覆い隠され、下部の枝が見えるようになっている。例えば指先と葉の集まりに該当する画像内のポイントを識別する。その後、ユーザーが手の位置を低くして、植物の下方の枝を覆い隠し、最上部の枝が見えるようにする。Lucas-Kanadeトラッカは、下方に動く手の中のポイントを追跡するが、植物の下半分において識別されたオリジナルポイントがないので、見えるようになった植物の上半分において、類似ポイントを見つけ出そうとする。そのため、これを上向きの動きと解釈して、感知されたユーザーの動きを効率よく打ち消してしまう。
【００８７】
問題点３：
ここで、図１０（ａ）と図１０（ｂ）を参照する。これらの図は、あるポイントが６枚の連続したフレーム上をどのように移動するように見えるかを示す例である。図１０（ａ）は、このシーンでは静止しているポイントであるが、カメラ画像内のノイズのために移動しているように見える。このポイントは遠くへの動きはなく、恐らく１または２ピクセル分の動きである。図１０（ｂ）は、直線上を移動しているポイントを示す。この場合、ノイズによって、ポイントが少しだけ進路から逸脱しているように見える。これらの図から、単に、ポイントが二つのフレーム間で移動した距離についての閾値だけでは、ポイントが本当に静止しているかどうかを判断するには不十分であるということが明らかである。二つの連続するフレーム間において、静止ポイントが、移動ポイントの見え方に相当する距離を移動するように見える。ポイントの本当の動きの速度が遅くなるにつれ、あるいはカメラのフレームレートが増すにつれ、この問題は悪化する。
【００８８】
これらの問題をすべて考慮し、本発明の実施例では、Lucas-Kanadeトラッカに対する一連の改良をOptical Flowクラス５０内に組み込むこととした。
【００８９】
第一に、問題点１と２に記載されたような自己相似ラインに対する誤ったマッチングと、自己相似オブジェクトに亘るポイントの出現を減らすための技術としてリバースマッチングがある。トラッカは、現在のフレーム内でトラックすべき良い点を見つけ、その位置をその前のフレーム内で決めると仮定する。前のフレーム内のこのポイントをあたかも追跡に適した特徴を有しているととらえ、現在のフレームにおいて、そのポイントの位置を決めようとすることによって、この位置を確認できる（すなわち、逆時間での追跡）。トラッキング・アルゴリズムによって、その現在のフレーム内のポイントが（例えば）そのポイントがあるべき場所のピクセル内、または他の閾値距離内であると分かった場合、有効なポイントのペアであるとみなされる。そうでなければこのポイントは廃棄される。
【００９０】
このように、この技術は、画像フレーム間の自己類似性によるトラッキングエラーにより（特に、ノイズを画像化するような変動が入り込んだ場合）、画像フレーム間で相互交換できる見込みがなくなるため、フレームペアの中で反対方向に適用されると一貫性がなくなる可能性があるという事実を利用するものである。従って、この技術によって、このような誤った追跡の大部分が除去される。
【００９１】
このように、OpticalFlowクラス５０は、もともと現在の画像内で選択された点に対応する、先行する画像内のポイントとの対応に基づいて、現在の画像内のテストポイントを選択し、現在の画像内でもともと選択されたポイントとテストポイントが実質的に一致しないポイントのペアを廃棄するよう動作することができる。
【００９２】
第二に、図１１をさらに参照すると、差分イメージングは、二重の効果をもたらす技術である。その主目的は、マッチングをするためのなんらかの試みがなされる前に移動をしなかったポイントを取り除くことによって、マッチング処理を高速化することにあるが、逆マッチングを行う前に、誤ってマッチしたいくつかのポイントを取り除くという第二の利点もある。
【００９３】
図１１に示される差分画像は、前述したように、画像ペアを得るためにDifferenceMetricクラス３０によって作成され、画像内のポイントは以下のように取り除かれるか、あるいは維持される。
【００９４】
i．差分画像の黒い（静止）部分にある、現在の画像からのポイントは即座に取り除かれる。
【００９５】
ii．差分画像の白い（稼働）部分にある、現在の画像からのポイントは、前の画像に対して追跡される。もし前の画像でのこのポイントが、差分画像の黒い部分にある場合、そのポイントは取り除かれる。
【００９６】
iii．一方、もし前の画像でのポイントもまた差分画像の白い部分にある場合は、逆マッチングが適用され、ポイントのペアの妥当性が確認される。
【００９７】
このように、OpticalFlowクラス５０は、先行する画像においてポイントを選択する前に、差分画像での均等位置が、算出された差分閾値レベルを下回る差分を示している現在の画像内のポイントを廃棄するよう動作することができる。
【００９８】
上記に代えてまたはそれに加えて、OpticalFlowクラス５０は、先行する画像におけるポイントとの一致に基づいて現在の画像でのテストポイントの選択を行う前に、差分画像における均等位置が、算出閾値レベルを下回る差分を示している先行する画像でのポイントを廃棄するように動作することも可能である。
【００９９】
前述のように、DifferenceMetricクラス３０は、ポイントが移動したかどうか決めるために可変の閾値を適用する。これは、もし画像の中で非常に大きい動きがあると思われる場合は、（ユーザーによって、あるいは現行のゲームコンテキストを考慮しながら自動的に）この閾値を上げることが可能であり、それによって、システムが些細な移動に対してそれほど敏感にならないようにするだけでなく、逆マッチングがそれ自体で取り除くことができる数よりもっと多くの誤った結果を取り除くことができる。
【０１００】
差分画像を算出することと、この画像を参照してポイントの状況を算出することは、ポイントマッチングと逆マッチングを行う場合と比較して、非常に高速であり、従って、全体のトラッキング精度を改善するだけでなく、かなりコンピューティング資源を節約できる。
【０１０１】
任意に、想定されているまたはこれまでに算出された、画像フレームレートとユーザー動作の一般的なスピードについての知識を考慮して、さらに、ＵＩ制御を囲む領域の外にあるポイントを自動的に取り除くことが可能である。ＵＩ制御を囲む領域とは、典型的な移動により一つ、二つのフレームによりカバーする距離に相当するが、フレーム数は多いことが望まれる。これによって、画像のどこか別の場所にある真の動きであって無関係な動きを無視しながら、トラッキングするためのＵＩ制御への移動ポイントを検出することが可能になる。
【０１０２】
第三に、マルチフレーム移動ポイント分析を使用して、上記に概説した第三の問題点に対処し、本当に移動しているポイントと、ノイズの微小震動を示している静止ポイントとを区別する。
【０１０３】
図１２（ａ）および図１２（ｂ）を参照すると、ノイズ微小震動のランダムな性質は、静止ポイントの動きが全体に亘る方向に向くわけではないということを意味していることがわかる。従って、移動をしているポイントは結果的に、元の場所からかなり離れたところへ移動して測定可能となり、一方、対照的に、ただランダムに動いているポイントは同じ場所にとどまる傾向がある。
【０１０４】
これらの二つの結果を区別するために、一般的に、ImageHistoryクラス２０内にある数多くの画像を考慮する（少なくとも３つ、一般的には１０から２０）。最初に、現在の画像内で見つけられるトラッキングポイントを正常なものとして先行する画像内で位置を決める。しかし、先行する画像内のそれらの各位置は、追跡すべきポイントとされ、さらにその前の画像等の中で探し出される。フレームレートがどのくらい速いか、動きがどれくらい遅いと予想されるかによって、このポイントは必要とされる限り逆に追跡することが可能であるが、ImageHistoryクラス２０内のメモリ制限や、（各フレームの追加に従い直線的に増加する）処理時間の制限に左右される。
【０１０５】
このポイントの履歴を分析し、最後のＲ個のフレームの間に、いずれかのポイントがある閾値（例えば、円１１０１により表された閾値）よりも遠くへ離れたかどうかを判断し、それに従い、このポイントは、静止ポイントよりむしろ移動ポイントであると判断する。一般的に、Ｒは経験的に決定されるものであるか、あるいは、ビデオキャプチャフレームレートの関数である。計算負荷を減らすため、任意に、あるポイントが一旦、移動ポイントであると判断されたとき（すなわち、関係する画像数に亘って閾値となる画像間動作を超えた場合）は、さらなるフレームを使ってこれ以上逆トラッキングをする必要はない。
【０１０６】
本当に移動しているピクセルにより見込まれる移動量に対する閾値は、もちろん、数Ｒおよびビデオフレームレートにより変動する。この閾値は、より高いＲ値に対して概して高くなり、より低いフレームレートに対しても概して高くなる。
【０１０７】
このように、OpticalFlowクラス５０は、ImageHistoryクラス２０に格納される先行する画像に対して動きを検出するため、ポイントのペアを再帰的に取得し、これらのポイントのペアによる累積した最終的な動きを、距離閾値と比較し、意図的な動きを画像ノイズから区別するよう動作可能である。
【０１０８】
この技術の付加的な利点は、以前に移動していたが現在は止まっているポイントを、一度も移動しなかった点から区別して拾い上げることもできるということである。任意に、これらのポイントは、例えば、もし現在のフレームよりも前に、ポイントが静止しているフレーム数が所定のフレーム数より少ない場合は、差分画像化技術のもとでの排除の対象から外される場合もある。
【０１０９】
任意に、この技術によって、移動しているポイントおよび静止しているポイントが、ディスプレイ３０５上で異なるように描き、移動しているポイントについては、辿ってきた経路を示すことができる。これは、例えば、指導モードにおいて、どのようにして制御が行われるかについてユーザーに対して有益なフィードバックを与えることができるので、ユーザーはより速く使い方を学ぶことができる。
【０１１０】
上記したトラッキング方法は、誤ったポイントのペアを取り除いて演算を軽減するために、差分画像化技術を用いるのが好ましいので、DifferenceHistoryクラス４０は、ImageHistoryクラス２０内の画像に対応する差分画像を格納する。
【０１１１】
特に、「累積した」差分画像の黒の領域で開始するポイントは、最終のＪ個の画像内ではいかなるポイントにおいても動いていないことが保証される。このように、差分画像での解決を使用する場合、累積的差分の中にある任意の黒いポイントは、マルチフレーム移動ポイント分析から除外することが可能である。というのは、それらが全体の画像履歴にわたって静止しているであろうことは周知だからである。このように、画像履歴の中で前回の画像から再帰的にポイントのペアを取得する前に、累積した差分データを使用して、連続した画像間で、算出された差分閾値レベルを超えるには十分な差分がなかったような点を廃棄する。
【０１１２】
PointHistoryクラス６０は、追跡するのによいと識別されたポイントの最終Ｊ個の画像全体での位置を維持する（すなわち、ある程度の時間、意図的な動きを示したと判断された点を格納する）。以下で説明するように、これらのポイントのうちの少なくともいくつかは、ＵＩ制御とユーザーのインタラクションを分析するために使用される。
【０１１３】
MotionModelクラス７０は、剛性体の動作をモデル化するための関数を備えるクラスである。通例は、一連の事前事後のポイントのペアがとられ、この事前ポイントと事後ポイントを最もよくマップする動作が算出される。一般的に、この動作モデルからの出力は４つの値であり、それらは、Ｘ方向移動量（Ｘトランスレーション）、Ｙ方向移動量（Ｙトランスレーション）、スケール、および、ある原点を中心とする回転（ローテーション）である。
【０１１４】
本発明の実施例において、ポイントのペアは、現在および先行する画像から取り出される。別の実施例において、より滑らかな動作モデルを作成するために、さらに古い画像からのポイントペアが使用されるが、使用される画像数およびカメラフレームレートによって、この履歴データはＵＩ制御のレスポンスの中に残像の出現を作り出してしまう場合もある。
【０１１５】
これをモデル化するための方法はたくさんあるが、一般的に、このモデルを描写し、前後のポイントをマップする一連の数式が使用される。この数式は、回転量、トランスレーション量およびスケール量を描写する多くの未知数を含む。観察されたポイントからこれらの未知数を予測するために、ポイントのペアに対して最小二乗誤差式解法が使用される。
【０１１６】
本発明の実施例において、この数式の解法は、ハウスホルダーの直交化最小二乗法（Householder Orthogonalization least squares method）と呼ばれ、例えば、Gene H. Golub and Charles F Van loan "Matrix Computations", 第三版 (ISBN: 0801854148)に記載されている。
【０１１７】
MotionModelクラス７０は、後述のように、多くの動作モデル（またはサブクラス）を含む。
【０１１８】
RotScaleTransModel関数は、ボディが、回転、拡大縮小（スケール）、およびＸ方向またはＹ方向の並進移動（トランスレーション）が可能であると仮定する。これらの動作が測定されるときに基準とする原点の位置は必ず与えられなければならない。
【０１１９】
主計算の前に、原点位置は、各ポイントの位置から減算される。
【０１２０】
ポイントについての修正された現在およびそれより以前の位置は以下のように与えられると仮定する。
【０１２１】
xCurrentkは、第k番目のポイントの現在のｘ座標
yCurrentkは、第k番目のポイントの現在のｙ座標
xPrevkは、第k番目のポイントの前回のｘ座標
yPrevkは、第k番目のポイントの前回のｙ座標
これらのポイントの集合体から、以下の未知数を予測する必要がある。
【０１２２】
スケール：ボディのサイズが増えた量
Θ： ボディの回転角
transX：トランスレーションにおけるＸコンポーネント
transY：トランスレーションにおけるＹコンポーネント
このモデルにおいて、現在のポイントがどのようにして前のポイントから導き出されたかを表す数式は、次のようになる。
【０１２３】
【数１】
【０１２４】
それぞれのポイントペアはすべてこのような二つの数式をもたらす。この目的は、式の集合体におけるエラーを最小限にするスケール、Θ、transXおよびtransYを見出すことである。
【０１２５】
この数式は、マトリックス/ベクトル方程式として再公式化される。
【０１２６】
【数２】
【０１２７】
n個のポイントに対し、マトリックスは2n列を有する。ハウスホルダー直交化アルゴリズムは、このマトリックス式に対して最小誤差解（Ｍ、Ｎ、ＰおよびＱ）を見出すために使用され、ここで、Ｍ = scale.sinΘ、Ｎ = scale.cosΘ、P = transX、およびQ = transYである。
【０１２８】
このようにして、一旦、Ｍ、Ｎ、Ｐ、およびＱの値が得られると、スケール、Θ、transX、およびtransYに対する値が以下のように算出される。以前に開示されたポイントペア式から以下が確認される。
【０１２９】
【数３】
【０１３０】
これは、次を意味する。
【０１３１】
【数４】
【０１３２】
ここで、Θのすべての値に対して
【０１３３】
【数５】
【０１３４】
である。従って、
【０１３５】
【数６】
【０１３６】
である。それによって、
【０１３７】
【数７】
【０１３８】
これを、第二のポイントペア式に代入すると、
【０１３９】
【数８】
【０１４０】
をもたらし、一方、transX = PおよびtransY = Qである。
【０１４１】
RotScaleModel関数は、RotScaleTransModelと同様の方法で機能し、ボディが枢着点で固定されると仮定する。これによって、この点を中心に拡大縮小し、回転させることができるが、並進移動値は常にゼロである。
【０１４２】
結果的に、ポイントペアの数式は、すでに与えられている式とは若干異なる。
【０１４３】
【数９】
【０１４４】
また、この等式は、マトリックス/ベクトル式として再公式化され、
【０１４５】
【数１０】
【０１４６】
前回と同様に解かれて、スケールとΘを得る。
【０１４７】
RotScaleTransModelおよびRotScaleModel関数に代えて、あるいはこれに加えて、画像内のポイントはラインとして接合することが可能であり、あるいは、これらのポイントを横切るエッジについてエッジ検出を行うことが可能である（例えば、指の周りなど）。結果として生じるラインは、いわゆるラドン変換を用いて相対角度の変化を決定するために使用することができ、これによって、変換の投影角度が、画像内のライン角度と一致する場合のピークレスポンス（あるいは分布）が得られる。この技術は、回転データを得るために用いることができる。
【０１４８】
同様に、一つのフレームから次のフレームまで、ラインにより表される物体のサイズは固定しているとみなすことができる。従って、ラドン変換の投射角に沿ってラインを測定することによって、スケールの変化およびそれによる距離の変化を決定できる。
【０１４９】
TransModel関数は、ボディが単に移動することはできても、回転あるいは拡大縮小することができないと仮定する。よって、このモデルは、全てのポイントの平均動作をとり、適宜、transXおよびtransYを設定する。
【０１５０】
【数１１】
【０１５１】
MotionConstraintsクラス８０は、多くの制約をモデル化する関数を備える。すでに開示された動作モデルを使って、概念上のボディのために、とりわけ次のようなプロパティを決定できる。
【０１５２】
つまり、位置、向き、スケール、速度、角速度およびスケーリング速度である。
【０１５３】
制約関数は、これらのプロパティの値を取り込み、ある程度の制約に従うようにそれらの値を修正する。このようなボディは、すぐに作用するような制約をいくつか有することが可能である。
【０１５４】
考えられる制約関数のいくつかの例について以下に記載する。
【０１５５】
LinearConstraint関数は、ボディが、直線に沿って存在するように位置を固定する。また、この線の方向の速度成分によって速度を置き換えることも可能である。
【０１５６】
RangeConstraint関数は、ボディのプロパティのいずれに対しても上限値と下限値を設定する。例えば、この関数は以下のために使用することが可能である。
【０１５７】
- 有限長のスクロールバーを作る。
【０１５８】
- ダイヤルが半分だけ回るようにする。
【０１５９】
- 並進移動（トランスレーション）をゼロに固定する（それによって本体はその位置で枢軸回転する）。
【０１６０】
- ボディがほぼ最大速度を維持することを確実にする。
【０１６１】
尚、並進移動をゼロに固定するための制約を使用してRotScaleTransModel関数を使用することと、制約なしでRotScaleModel関数を使用することは等しくない。前者においては、並進移動はモデル化された後、捨ててしまう。後者において、モデル化は、（RotScaleModel関数によって、できる限り最良であると解釈される並進移動の存在している状態で）単に回転およびスケールをモデル化することのみに向けられている。
【０１６２】
UIControlクラス９０は、PointHistoryクラス６０、MotionModelクラス７０、およびMotionConstraintsクラス８０の間を調整して、ＵＩ制御の、位置、向き、スケール、速度、角速度、スケール速度（スケール変化率）、および形（円、細長い形、正方形等一定を維持するもの）のためのデータを管理できる。
【０１６３】
UIControlクラス９０は、PointHistoryクラス６０を調べて、現在移動しているポイントのみを考慮する。その後、UIControlの形状（例えば、図４において、外側境界線１０１５）の外側に現在位置があるものはすべて除外する。
【０１６４】
このようなポイントが十分にある場合、PointHistoryクラス６０内の移動ポイントについての現在と以前の位置のみを取り、これらをMotionModelクラス７０に渡して、このフレームペアに対して変換を行う。
【０１６５】
ＵＩ制御の速度、角速度、およびスケール速度は、このフレームに対する変換に一致するよう設定される。これらのプロパティ（位置、向き、およびスケールも同様に）は、この修正制御のために存在するMotionConstraintsクラス８０内の制約のいずれかの対象となる。このように修正されたプロパティは、ユーザー入力として機能するために利用可能になる。
【０１６６】
任意に、これらの修正されたプロパティに対してエラー値を算出できる。このエラー値は、修正された速度、角速度およびスケール速度を使用して、最後のフレーム内のすべてのポイントを変換し、それらのポイントが終了する場所と、現在のフレーム内で観察された場所との差分を見ることにより算出される。この差分はその後スケール変更されるので、このエラーは、移動をした各ポイントに対する総距離の一部となる。この値のログをとって、すべてのポイントからのすべてのエラーの合計をポイントの数で割る。これによって、動作の大きさや、いくつのポイントが観察されたかということとは無関係なエラー値が得られ、ユーザーの動きがどの程度うまく制約内にとどまっているのかという表示をすることができる。このような表示は、例えば、ユーザーにフィードバックを与える場合に使うことができる。一例として、もしユーザーがあまりに速くスクロール制御を動かそうとしている場合、赤く点灯するようにしてもよい。
【０１６７】
任意に、エラー値は、検出された動きのエラーの程度が低くＵＩ制御の動作制約にしっかりと適合しているかどうかによって、ＵＩ制御のロックを制御する際に利用することもできる。この構成により可能なのは、例えば、人がダイヤル制御を「通過して」歩くときに、ダイヤル制御はロックしたままにできる。というのは、動きの推移成分に比べると回転成分が非常に低いので、結果的に高いエラーになるからである。逆に、もし人が一つの手ではなく二つの手を使っても、もし、あたかもハンドルを操作するように両手を一緒に回転させた場合は、ダイヤル制御のロックを解除するために有効な動作となる。
【０１６８】
制御の中で、ユーザーのインタラクションであると解釈するような移動ポイントが十分にない場合（例えば、ユーザーの手がＵＩ制御の境界線を離れている場合）、速度（必要に応じて、ダイレクトの速度、角速度および／またはスカラー速度）を均等に維持できるので運動量をモデル化する、あるいは、ゆるやかに減速する（摩擦をモデル化する）、あるいは、ゼロを設定する（簡単であるがしっかりとした制御をモデル化する）、という三つの選択肢がある。
【０１６９】
ここで、上で例示されたＵＩ制御に特有なUIControlクラス９０の作用の構成を詳述する。
【０１７０】
再び図５を参照すると、スクロール制御は、TransModelMotion関数を使用して実行され、（この場合では）垂直なラインに動きを拘束するためにLinearConstraint関数を使用する。また任意に、（有限長のスクロール制御が要求される場合は）ラインに沿って範囲を制限できる。もし十分な移動ポイントが見つからない場合、速度はゆっくりと減速するままにしておき、運動量とある程度の摩擦を伴ったスクロールバーをモデル化する。
【０１７１】
スクロール制御はまた、前に開示された差分画像化技術を使うことにより、オプティカルフロー計算の効率を改善することができる。非常に大きくて速いユーザーの動きが予想されるときは、差分画像化閾値を適切に上昇させることが可能である。差分画像化技術は、このＵＩ制御にとって特に有益である。というのは、この技術は比較的範囲が広いので、それに比例して、外部からのポイントをより多く含んでいることが期待されるからである。
【０１７２】
再び図４を参照すると、ダイヤル制御は、RotScaleTrans関数を使用して実行され、RangeConstraint関数を使用して、速度ゼロおよびスケール速度ゼロの場合を有するように制限する。ダイヤル制御はまた、その動きから算出したエラー値を使って、ユーザーが好適な回転動作を行ったかどうかを判断する。そのような動作が行われなかった場合、ダイヤル制御はロックする。同様に、移動ポイントが十分にない場合、ダイヤル制御はロックする。
【０１７３】
任意に、このダイヤル制御は、OpticalFlowケース５０関数の効率化を行うため、差分バッファを使用しない。その理由は、差分バッファは、あまり感度が高くないので、ダイヤル制御を操作しているときに生じる非常にゆっくりで微細な動きを拾い上げることができないからである（後で開示するようなノイズ校正に依存する）。しかし、ダイヤル制御の領域は、スクロール制御よりもかなり小さいので、計算負荷に対するインパクトも同様に小さい。
【０１７４】
ホイール制御は、ダイヤル制御と同様の方法で実行されるが、ロックは全くかけない。これによって、ホイール内で算出された動作はすべて回転動作として解釈されることが可能となり、ホイール内で十分な移動ポイントが見つからない場合は、ホイールはスピンを続ける（あるいは減速する）。
【０１７５】
ダイヤル制御についての他の変形としては、スケールダイヤルがある。これは、RotScaleTrans関数が、ダイヤルの原点から離れる移動ポイントのトランスレーションを、ダイヤルを表示すべきスケールを示すと解釈することを利用する。従って、上記のダイヤル制御とは異なり、RotScaleTrans関数がスカラー速度を制限せず、その代わりに、ダイヤルが速度ゼロと角速度ゼロの場合を有するように制限する。従って、スケールダイヤルは、ユーザーが手を開閉するのに従って、拡大したり縮小したりする。一般的に、スケールダイヤルは、通常のダイヤル制御と同じようにロックする。
【０１７６】
角速度ゼロに対する制約もまた取り除かれる場合は、ダイヤルの回転とスケール変更を同時に行うことができる。従って、例えば、回転をステレオバランスに関連づける一方、スケールをゲーム機により演奏される音のボリュームに関連付けることが可能である。
【０１７７】
RangeConstraint関数は、例えば、スケールダイヤルが小さくなりすぎて明確に見ることができなくなることを避けるために、あるいは、動作分析のために十分なポイントが含まれるように、最大およびまたは最小スケールを制限することが可能である。スケールホイールも、同様に実現可能である。
【０１７８】
上記の動作と制約を使用した制御についての他の組み合わせは、当業者にとっては明らかなことである。また、スケールダイヤルと同じように、ポイントのトランスレーションに対し長さが依存するようなバー等、他のＵＩフォームファクタも同様に当業者にとって明らかである。
【０１７９】
同じように、インタラクションの他のモードにおいては、グラフィック制御を表示しない場合もある。例えば、RotScaleTransModelおよびRotScaleModelは、ビデオカメラに向かってパンチをする拳のスケールの変化を、ボクシングゲームでの入力として作用するように解釈できる。このシナリオにおいては、全体画像は「透明な」制御領域であって、その領域内のユーザーの動きは適宜解釈される。
【０１８０】
このタイプのインタラクションは、制御の表面的な見かけにより示される。例えば、ダイヤル制御は、予期される通りダイヤルで示され、片手でダイヤルを調節するように自然にユーザーを促す。対照的に、このダイヤルをステアリングホイールによって表すことも可能であり、これは両手でのアプローチを促す。ダイヤルのグラフィックスは、線画または画像に似たものでよく、透明な領域を伴っても伴わなくてもよい。グラフィックとのインタラクションの際、グラフィックと一致している取り込み画像内の移動領域は、重畳され、あるいはアルファブレンドされ、ユーザーはその行為についてよりよいフィードバックを受けられるようにする。
【０１８１】
同様に、ＵＩ制御が、状況に応じて動作を起動し、変化させ、あるいは、動作を取得することはいうまでもない。例えば、スクロール制御は、多くのダイヤルを含む多くのアイコンを表示することが可能である。これらのアイコンが「アクティブな」領域にスクロールして入ると、同じグラフィックを使った実際のダイヤル制御（またはその変形）に継ぎ目なく入れ替わる。ユーザーは、スクロール制御が多くの選択可能なダイヤル制御を格納しているということを経験する。他の例では、ＵＩ制御は、アクティブ領域内にスクロールするときのみ並進移動可能とすることにより、「好みの」または「ショートカットとなる」制御を選択し、画面上に常駐させるためにスクロールバーから引き出すことができる。
【０１８２】
図１３は、ビデオカメラが装着あるいは接続されたソニー(商標登録)プレイステーション・ポータブル(商標登録)ビデオゲーム装置（ＰＳＰ）についての本発明の実施例を示したものである。ＰＳＰにより使用されている「クロスメディアバー」ナビゲーションシステムが例示されており、これは、カテゴリアイコンの横列１３１０を備える。そのうちの一つであるセッティング１３１５がアクティブ領域に位置し、設定に関連するサブカテゴリの縦列１３２０が表示されるようにする。これらのサブカテゴリの中で、現在は「ネットワーク更新」が反転表示されている。
【０１８３】
カテゴリアイコンの横列は、上記のスクロール制御を使って制御され、このカテゴリアイコンの一つに関連するサブカテゴリの縦列が表示されると、これも同様にスクロール制御を使って制御される。両者の違いは、動作モデルに適用された横のトランスレーション制限内にあるか、縦のトランスレーション制限内にあるかということである。同様に、反転表示されるカテゴリの値またはプロパティを変更することも可能であり、例えば、上記のダイヤル制御を使って、オン／オフのために左に回したり右に回したり、あるいは該当する場合には連続値を設定する。
【０１８４】
これらの制御間のインタラクションは、起動、変更（例えば、ロックとロック解除）、または所望の結果を得るために適切な動作の取得をすることにより管理できる。例えば、縦方向スクロール制御あるいはダイヤル制御のいずれかが使用されているとき、現在のカテゴリアイコンにより占有されるアクティブ領域において、横方向の動きが検出されるまで、この横方向スクロールの制御をロックすることができる。これによって、例えば、ユーザーがサブカテゴリの設定を調整している間に、うっかり主要動作がカテゴリを変更してしまうことを防止し、他の制御を調整中は、ユーザーによって具体的に再開が行われるまで横方向スクロールバーはロックするという経験をユーザーに与える。これとは別のインタラクションスキームにおいて、他のＵＩ制御が動きを検出したとき、横方向スクロール制御はただロックするようにする。その結果、横方向スクロール制御はレスポンスの優先度が最も低い。縦方向スクロール制御は、次の優先度レベルを有し、現在反転表示されているサブカテゴリのためのダイヤル制御が最も高い優先度を有する。
【０１８５】
ここで図１４を参照すると、ユーザー制御検出の方法は、
Ｓ１０ 画像を取り込むステップと、
Ｓ２０ ImageHistoryクラス２０に画像を格納するステップと、
Ｓ３０ 現在とそれより前の画像の間の差分に従って画像を作成するステップと、
Ｓ４０ DifferenceHistoryクラス４０に差分画像の閾値型を格納するステップと、
Ｓ５０ ImageHistoryクラス２０に格納されている画像を分析し、ある画像から次の画像へと追跡するための有効なポイントを見出すステップと、
Ｓ６０ これらのポイントをPointsHistoryクラス６０内に格納するステップと、
Ｓ７０ 現在およびそれより前のフレームにおいて選択されたポイントの動きをモデル化するステップと、
Ｓ８０ ＵＩ制御に適する動作制約を適用するステップと、
Ｓ９０ 制約された動作をユーザー入力として解釈するステップと、を備える。
【０１８６】
ここで開示されるユーザー制御検出機構の実施例の作用に相当する、上記方法のさらに別の実施例は、本発明の範囲の想定内であることはいうまでもない。
【０１８７】
図１５は、ノイズ校正方法を説明するフローチャートである。すでに開示されているように、入力されたグレースケール画像をバイナリ画像に変えるために閾値をDifferenceMetricクラス３０内に設定することが必要とされる。ノイズ校正方法は、カメラ画像から効果的にノイズを取り除く一方で、好ましくは、できる限り低くすることできる閾値を見出すように設計される。また、暗騒音をサンプリングするためにユーザーがそのシーンから外に出ることなく達成できるものであることが好ましい。
【０１８８】
この方法は、DifferenceMetricクラス３０を校正するためにOpticalFlowクラス５０の関数を使用する。これによって、OpticalFlowクラス５０が動きとみなすものとDifferenceMetricクラス３０が動きとみなすものの間に、好適な対応関係があることを保証する。
【０１８９】
この方法は、以下のステップを備える。
【０１９０】
Ｓ１．移動ポイントを決定するために、全体の画像領域に亘って最終のＪ個のフレームに対してOpticalFlowクラス５０の計算を行うステップ。この計算を支援するためにDifferenceMetricクラス３０は使用しない。
【０１９１】
Ｓ２．PointHistory ６０からのすべての移動ポイントを識別して、それらを廃棄するステップ。
【０１９２】
Ｓ３．残っている各静止ポイントに対し、その位置におけるもっとも最近の、閾値差分画像でない画像を見て、その値を記録するステップ。これによって、静止している画像にあるポイントから一組の差分値が求められる。
【０１９３】
Ｓ４．統計学的に有意であるように充分な値を得るために、いくつかのフレームに対してステップ１から３を繰り返すステップ。
【０１９４】
Ｓ５．これらの静止差分値を、ゼロを中心とする正規分布としてモデル化し、変動量を算出するステップ。
【０１９５】
Ｓ６．この変動量にある程度適切な値（例えば３）を乗じ、それを差分距離閾値に対する基礎として使用するステップ。３という値は、静止ポイントは閾値の要因にはならないという９９．７％の信頼度を示している。
【０１９６】
別の実施例において、多くの連続したフレームに亘って、各ピクセルに対する差分値のヒストグラムを作成することによって、ノイズが校正される。これは、カメラノイズが常に存在し、かつレベルが同じぐらいなので、ヒストグラムでのピークを形成することが予想されるということを利用するものであり、これに対して、画像における実際の動きはランダムなものであり、広く分散する差分値を有する。結果的に、最小から最大まで差分値を見た場合に、ヒストグラムで発生する最初の明瞭なピークが平均ノイズ値であり、そこに閾値を設定する。
【０１９７】
いずれかの実施例によるノイズ校正を行う場合であっても、このときのシーンの照度が均一であることが好ましい。従って、好ましい実施例においては、テレビディスプレイによる輝度とカラー出力は校正の間は大きく変動すべきではない。主な目的は、テレビ画面による環境での照度における急激な変化によってシャドーが急速に変化し、それによって、見かけ上の動きが生じるのを回避するためである。これとは対照的に、ここで記載されている方法を通常に実行している間は、テレビまたは他の環境要因からの照度変化による見かけ上の動きに対して、各画像をトラッキングするための候補ポイントを評価することによって、有効に耐性を提供することができる。
【０１９８】
任意に、ランダムなカメラノイズを抑制するために、ノイズ低減法を使用することも可能であり、それによって、意図的な動きを区別する。カメラノイズのランダム性とは、空間または時間での平均化によって、効果的なノイズレベルを減らすことを意味する。しかしながら、（各ピクセルに対してｎ×ｎピクセル領域に亘る）空間での平均化は、小さいながらも真の動きに対する感度を減少させる一方で、（連続した画像に亘る）時間での平均化は、ゆっくりであっても真の動きに対する感度を減少させる。このように、これらの技術の適用性は、ビデオカメラのフレームレートまたは解像度にそれぞれ依存するものであり、またユーザーがインタラクションを行うと考えられる制御のタイプにも依存する。差分の閾値化をする前に、どのポイントにおいても平均化を適用できることはいうまでもない。オリジナルの画像から最良の結果が得られるとしても、これはグレースケール差分画像に対する単一平均化に比べると、（赤、緑、青値に対する）三回の平均化が必要であり、したがって、品質と計算負荷に関するこれらの比較値は、アプリケーションに依存する。
【０１９９】
ソフトウェアにより制御されたデータ処理装置によって、少なくとも部分的であっても、上記のような本発明の実施例が実行される限りは、このようなソフトウェアを提供するコンピュータプログラムと、このようなコンピュータプログラムが格納される記憶装置または伝送媒体が、本発明の態様として認識されることはいうまでもない。
【図面の簡単な説明】
【０２００】
【図１】図１は、プレイステーション２の全体的なシステムアーキテクチャを概略的に示す。
【図２】図２は、エモーション・エンジンのアーキテクチャを概略的に示す。
【図３】図３は、グラフィックス・シンセサイザの構成を概略的に示す。
【図４】図４は、ダイヤル制御を概略的に示す。
【図５】図５は、スクロール制御を概略的に示す。
【図６】図６は、ユーザー制御検出機構のブロック図である。
【図７】図７は、特徴点の比較について概略的に示す。
【図８】図８は、特徴点の比較について概略的に示す。
【図９】図９は、特徴点の比較について概略的に示す。
【図１０】図１０は、動作タイプを区別する際の問題点を示す。
【図１１】図１１は、２つの画像間の閾値差分を示す。
【図１２】図１２は、動作のタイプを区別するための手段を示す。
【図１３】図１３は、ソニー（登録商標）ＰＳＰ（登録商標）のナビゲーションシステムに対するユーザー制御検知機構の適用を例示する。
【図１４】図１４は、ユーザー制御検出の方法を示すフローチャートである。
【図１５】図１５は、ノイズ校正の方法を示すフローチャートである。
【特許請求の範囲】
【請求項１】
ビデオカメラから連続する画像を受信するよう構成されるデータ処理装置であって、
該データ処理装置の制御機能と対応づけられている画像領域内の選択されたポイントについて画像間動作を検出するための手段と、
該画像間動作について画像領域において検出が行われた場合に制御機能を実行するための手段と、を備え、
該検出手段は、ｍ個の連続する一群の画像に亘る画像領域内のポイントについて累積的画像間動作を検出することによって、画像間動作を検出するよう構成され、ここでｍは少なくとも３であることを特徴とするデータ処理装置。
【請求項２】
請求項１に記載の装置であって、
前記連続する画像を供給するためのビデオカメラを備えることを特徴とするデータ処理装置。
【請求項３】
前記各項のいずれか一つに記載の装置であって、
ビデオディスプレイと、
該ビデオディスプレイ上に移動可能なユーザー制御を表示するための手段と、を備える装置であって、
前記制御機能は、少なくとも該移動可能なユーザー制御の移動を含むことを特徴とする装置。
【請求項４】
請求項３に記載の装置であって、
前記移動可能なユーザー制御は、前記検出手段によって検出された画像間動作の程度に依存する量だけ動かされることを特徴とする装置。
【請求項５】
前記各項のいずれか一つに記載の装置は、差分測定手段を備え、
該差分測定手段は、
二つの連続する画像間のピクセル値における差分に比例する、一連の値を備える差分データを作成し、
その後、該差分データを平滑化するよう動作可能であることを特徴とする装置。
【請求項６】
請求項５に記載の装置であって、
前記差分測定装置はさらに、異なる閾値レベルで差分データに対して閾値を適用し、結果として生じるバイナリ差分データを出力するよう動作可能であることを特徴とする装置。
【請求項７】
請求項６に記載の装置は、差分データ記憶手段を備え、
該差分データ記憶手段は、連続する画像間で差分閾値を超える差分を示した、一連の画像に亘るすべてのポイントを示す累積的バイナリ差分画像を作成するために、一連の画像に対するバイナリ差分データを組み合わせるよう動作可能であることを特徴とする装置。
【請求項８】
請求項６または請求項７に記載の装置であって、
ｉ．空間的平均化、および
ｉｉ．時間的平均化
のうちの一つまたは両方の処理を適用することによって、前記ビデオカメラから受信した画像データを処理する手段を備えることを特徴とする装置。
【請求項９】
前記各項のいずれか一つに記載の装置であって、
前記画像間動作を検出する手段は、現在の画像において選択されるポイントとの対応関係に基づいて先行する画像におけるポイントを選択し、動作を検出するために結果として生じるポイントのペアを分析するよう動作可能であることを特徴とする装置。
【請求項１０】
請求項９に記載の装置であって、
前記画像間動作を検出するための手段は、現在の画像においてもともと選択されたポイントに一致する、先行する画像内のポイントとの対応関係に基づいて、現在の画像内でテストポイントを選択し、そのテストポイントが現在の画像においてもともと選択されたポイントと実質的に一致しないポイントのペアを廃棄するよう動作可能であることを特徴とする装置。
【請求項１１】
請求項６に従属する請求項９または請求項１０のいずれかに記載の装置であって、
前記画像間動作を検出するための手段は、先行する画像においてポイントを選択する前に、差分画像での均等位置が、差分閾値レベルを下回る差を示している現在の画像内のポイントを廃棄するよう動作可能であることを特徴とする装置。
【請求項１２】
請求項６に従属する請求項９乃至請求項１１のいずれか一つに記載の装置であって、
前記画像間動作を検出するための手段は、先行する画像内のポイントとの対応関係に基づいて現在の画像においてテストポイントを選択する前に、差分画像での均等位置が、差分閾値レベルを下回る差を示している先行する画像内のポイントを廃棄するよう動作可能であることを特徴とする装置。
【請求項１３】
前記各項のいずれか一つに記載の装置であって、
前記差分測定手段は、静止しているということが見出された選択ポイントの差分値における変動量に基づいて、連続する画像間の差分閾値を算出するよう動作可能であることを特徴とする装置。
【請求項１４】
請求項１乃至請求項１２のいずれか一つに記載の装置であって、
前記差分測定手段は、連続する画像間の差分閾値を算出するよう動作可能であって、該算出は、二つ以上の連続する画像内のピクセルについての差分値のヒストグラムに基づくものであり、ヒストグラムの末端にある低い差分値から見て最初に遭遇するヒストグラムピークを、それより上に差分閾値を設定すべき平均カメラノイズであると識別することを特徴とする装置。
【請求項１５】
請求項９乃至請求項１４のいずれか一つに記載の装置であって、
前記差分測定手段は、画像履歴記憶装置に格納されたｎ個の先行する画像について動作を検出するためのポイントのペアを再帰的に取得し、これらのポイントのペアの累積した最終的な動作を距離閾値と比較し、意図的な動きを画像ノイズから区別するよう動作可能であることを特徴とする装置。
【請求項１６】
請求項１５に記載の装置であって、
ｎは、３以上であることを特徴とする装置。
【請求項１７】
請求項１５または請求項１６のいずれかに記載の装置であって、
前記画像間動作を検出するための手段は、画像履歴にある先行する画像から再帰的にポイントのペアを取得する前に、連続する画像間に差分閾値レベルを超えるのに十分な差分がないということが生じたポイントを廃棄するために、累積的差分画像を使用するよう動作可能であることを特徴とする装置。
【請求項１８】
請求項１５乃至請求項１７のいずれか一つに記載の装置であって、
意図的な動きを示したと検出されたポイントを格納するためのポイント履歴記憶手段を備えることを特徴とする装置。
【請求項１９】
請求項１８に記載の装置であって、
ユーザーに対して検出された動作についての情報を供給するために、ポイント履歴から引き出されたデータを、グラフィカルに表示するための手段を備えることを特徴とする装置。
【請求項２０】
請求項１５乃至請求項１９のいずれか一つに記載の装置であって、
意図的な動きを示したと判断された、現在の画像および先行する画像に対するポイントのペアにおける、
i．トランスレーション
ii．ローテーション
iii．スケール
のいずれか、またはすべてに対する変更について決定するよう動作可能である動作モデル化手段を備えることを特徴とする装置。
【請求項２１】
請求項２０に記載の装置であって、
現在の画像および先行する画像よりも古い、いくつかのまたはすべての格納された画像に対するポイントペアは、前記動作モデル化手段によって使用されることを特徴とする装置。
【請求項２２】
請求項２０または請求項２１に記載の装置であって、
所望の動きに一致するように、モデル化された動作を制約するよう動作可能な動作制約手段を備えることを特徴とする装置。
【請求項２３】
請求項２０乃至請求項２２のいずれか一つに記載の装置であって、
前記モデル化された動作に従って、少なくとも最初の表示アイテムを更新するための表示手段を備えることを特徴とする装置。
【請求項２４】
請求項２３記載の装置であって、
前記表示アイテムまたは各表示アイテムは、ユーザーインターフェース制御を表わすことを特徴とする装置。
【請求項２５】
請求項２４記載の装置であって、
前記ユーザーインターフェース制御は、
i．ホイール制御
ii．ダイヤル制御
iii．スクロール制御
iv．スケール制御
のいずれか一つであることを特徴とする装置。
【請求項２６】
請求項２５に記載の装置であって、
前記ホイール制御とダイヤル制御は、スケール変更が可能であることを特徴とする装置。
【請求項２７】
請求項２２乃至請求項２６のいずれか一つに記載の装置であって、
制約のあるモデル化された動作から、ユーザーが逸脱したと判断されると、この逸脱が閾値を超えている場合は、ユーザーインターフェース制御がロックされることを特徴とする装置。
【請求項２８】
請求項２０乃至請求項２７のいずれか一つに記載の装置であって、
前記モデル化された動作は、前記装置に対するユーザー入力として解釈されることを特徴とする装置。
【請求項２９】
前記各項のいずれか一つに記載の装置であって、前記データ処理装置はゲーム機であることを特徴とする装置。
【請求項３０】
データ処理方法であって、
ビデオカメラから連続して取り込んだ画像を受信するステップと、
データ処理装置の制御機能と対応づけられている画像領域内の選択されたポイントについて画像間動作を検出するステップと、
前記画像領域において該画像間動作が検出された場合に制御機能を実行するステップと、を備え、
該検出ステップは、ｍ個の連続する一群の画像に亘る前記画像領域内のポイントについて累積的画像間動作を検出することによって、画像間動作を検出するよう構成され、ここでｍは少なくとも３であることを特徴とするデータ処理方法。
【請求項３１】
コンピュータ・ソフトウェアであって、
コンピュータにロードされると、コンピュータが請求項１乃至請求項２９のいずれか一つに記載のデータ処理装置として動作できるようになるプログラムコードを有することを特徴とするソフトウェア。
【請求項３２】
コンピュータ・ソフトウェアであって、
請求項３０に記載の方法を実行するためのプログラムコードを有することを特徴とするコンピュータ・ソフトウェア。
【請求項３３】
請求項３１または請求項３２に記載のソフトウェアを提供するための提供媒体。
【請求項３４】
請求項３７に記載の媒体であって、前記媒体は、伝送媒体であることを特徴とする媒体。
【請求項３５】
請求項３７に記載の媒体であって、前記媒体は、記憶媒体であることを特徴とする媒体。
【請求項１】
ビデオカメラから連続する画像を受信するよう構成されるデータ処理装置であって、
該データ処理装置の制御機能と対応づけられている画像領域内の選択されたポイントについて画像間動作を検出するための手段と、
該画像間動作について画像領域において検出が行われた場合に制御機能を実行するための手段と、を備え、
該検出手段は、ｍ個の連続する一群の画像に亘る画像領域内のポイントについて累積的画像間動作を検出することによって、画像間動作を検出するよう構成され、ここでｍは少なくとも３であることを特徴とするデータ処理装置。
【請求項２】
請求項１に記載の装置であって、
前記連続する画像を供給するためのビデオカメラを備えることを特徴とするデータ処理装置。
【請求項３】
前記各項のいずれか一つに記載の装置であって、
ビデオディスプレイと、
該ビデオディスプレイ上に移動可能なユーザー制御を表示するための手段と、を備える装置であって、
前記制御機能は、少なくとも該移動可能なユーザー制御の移動を含むことを特徴とする装置。
【請求項４】
請求項３に記載の装置であって、
前記移動可能なユーザー制御は、前記検出手段によって検出された画像間動作の程度に依存する量だけ動かされることを特徴とする装置。
【請求項５】
前記各項のいずれか一つに記載の装置は、差分測定手段を備え、
該差分測定手段は、
二つの連続する画像間のピクセル値における差分に比例する、一連の値を備える差分データを作成し、
その後、該差分データを平滑化するよう動作可能であることを特徴とする装置。
【請求項６】
請求項５に記載の装置であって、
前記差分測定装置はさらに、異なる閾値レベルで差分データに対して閾値を適用し、結果として生じるバイナリ差分データを出力するよう動作可能であることを特徴とする装置。
【請求項７】
請求項６に記載の装置は、差分データ記憶手段を備え、
該差分データ記憶手段は、連続する画像間で差分閾値を超える差分を示した、一連の画像に亘るすべてのポイントを示す累積的バイナリ差分画像を作成するために、一連の画像に対するバイナリ差分データを組み合わせるよう動作可能であることを特徴とする装置。
【請求項８】
請求項６または請求項７に記載の装置であって、
ｉ．空間的平均化、および
ｉｉ．時間的平均化
のうちの一つまたは両方の処理を適用することによって、前記ビデオカメラから受信した画像データを処理する手段を備えることを特徴とする装置。
【請求項９】
前記各項のいずれか一つに記載の装置であって、
前記画像間動作を検出する手段は、現在の画像において選択されるポイントとの対応関係に基づいて先行する画像におけるポイントを選択し、動作を検出するために結果として生じるポイントのペアを分析するよう動作可能であることを特徴とする装置。
【請求項１０】
請求項９に記載の装置であって、
前記画像間動作を検出するための手段は、現在の画像においてもともと選択されたポイントに一致する、先行する画像内のポイントとの対応関係に基づいて、現在の画像内でテストポイントを選択し、そのテストポイントが現在の画像においてもともと選択されたポイントと実質的に一致しないポイントのペアを廃棄するよう動作可能であることを特徴とする装置。
【請求項１１】
請求項６に従属する請求項９または請求項１０のいずれかに記載の装置であって、
前記画像間動作を検出するための手段は、先行する画像においてポイントを選択する前に、差分画像での均等位置が、差分閾値レベルを下回る差を示している現在の画像内のポイントを廃棄するよう動作可能であることを特徴とする装置。
【請求項１２】
請求項６に従属する請求項９乃至請求項１１のいずれか一つに記載の装置であって、
前記画像間動作を検出するための手段は、先行する画像内のポイントとの対応関係に基づいて現在の画像においてテストポイントを選択する前に、差分画像での均等位置が、差分閾値レベルを下回る差を示している先行する画像内のポイントを廃棄するよう動作可能であることを特徴とする装置。
【請求項１３】
前記各項のいずれか一つに記載の装置であって、
前記差分測定手段は、静止しているということが見出された選択ポイントの差分値における変動量に基づいて、連続する画像間の差分閾値を算出するよう動作可能であることを特徴とする装置。
【請求項１４】
請求項１乃至請求項１２のいずれか一つに記載の装置であって、
前記差分測定手段は、連続する画像間の差分閾値を算出するよう動作可能であって、該算出は、二つ以上の連続する画像内のピクセルについての差分値のヒストグラムに基づくものであり、ヒストグラムの末端にある低い差分値から見て最初に遭遇するヒストグラムピークを、それより上に差分閾値を設定すべき平均カメラノイズであると識別することを特徴とする装置。
【請求項１５】
請求項９乃至請求項１４のいずれか一つに記載の装置であって、
前記差分測定手段は、画像履歴記憶装置に格納されたｎ個の先行する画像について動作を検出するためのポイントのペアを再帰的に取得し、これらのポイントのペアの累積した最終的な動作を距離閾値と比較し、意図的な動きを画像ノイズから区別するよう動作可能であることを特徴とする装置。
【請求項１６】
請求項１５に記載の装置であって、
ｎは、３以上であることを特徴とする装置。
【請求項１７】
請求項１５または請求項１６のいずれかに記載の装置であって、
前記画像間動作を検出するための手段は、画像履歴にある先行する画像から再帰的にポイントのペアを取得する前に、連続する画像間に差分閾値レベルを超えるのに十分な差分がないということが生じたポイントを廃棄するために、累積的差分画像を使用するよう動作可能であることを特徴とする装置。
【請求項１８】
請求項１５乃至請求項１７のいずれか一つに記載の装置であって、
意図的な動きを示したと検出されたポイントを格納するためのポイント履歴記憶手段を備えることを特徴とする装置。
【請求項１９】
請求項１８に記載の装置であって、
ユーザーに対して検出された動作についての情報を供給するために、ポイント履歴から引き出されたデータを、グラフィカルに表示するための手段を備えることを特徴とする装置。
【請求項２０】
請求項１５乃至請求項１９のいずれか一つに記載の装置であって、
意図的な動きを示したと判断された、現在の画像および先行する画像に対するポイントのペアにおける、
i．トランスレーション
ii．ローテーション
iii．スケール
のいずれか、またはすべてに対する変更について決定するよう動作可能である動作モデル化手段を備えることを特徴とする装置。
【請求項２１】
請求項２０に記載の装置であって、
現在の画像および先行する画像よりも古い、いくつかのまたはすべての格納された画像に対するポイントペアは、前記動作モデル化手段によって使用されることを特徴とする装置。
【請求項２２】
請求項２０または請求項２１に記載の装置であって、
所望の動きに一致するように、モデル化された動作を制約するよう動作可能な動作制約手段を備えることを特徴とする装置。
【請求項２３】
請求項２０乃至請求項２２のいずれか一つに記載の装置であって、
前記モデル化された動作に従って、少なくとも最初の表示アイテムを更新するための表示手段を備えることを特徴とする装置。
【請求項２４】
請求項２３記載の装置であって、
前記表示アイテムまたは各表示アイテムは、ユーザーインターフェース制御を表わすことを特徴とする装置。
【請求項２５】
請求項２４記載の装置であって、
前記ユーザーインターフェース制御は、
i．ホイール制御
ii．ダイヤル制御
iii．スクロール制御
iv．スケール制御
のいずれか一つであることを特徴とする装置。
【請求項２６】
請求項２５に記載の装置であって、
前記ホイール制御とダイヤル制御は、スケール変更が可能であることを特徴とする装置。
【請求項２７】
請求項２２乃至請求項２６のいずれか一つに記載の装置であって、
制約のあるモデル化された動作から、ユーザーが逸脱したと判断されると、この逸脱が閾値を超えている場合は、ユーザーインターフェース制御がロックされることを特徴とする装置。
【請求項２８】
請求項２０乃至請求項２７のいずれか一つに記載の装置であって、
前記モデル化された動作は、前記装置に対するユーザー入力として解釈されることを特徴とする装置。
【請求項２９】
前記各項のいずれか一つに記載の装置であって、前記データ処理装置はゲーム機であることを特徴とする装置。
【請求項３０】
データ処理方法であって、
ビデオカメラから連続して取り込んだ画像を受信するステップと、
データ処理装置の制御機能と対応づけられている画像領域内の選択されたポイントについて画像間動作を検出するステップと、
前記画像領域において該画像間動作が検出された場合に制御機能を実行するステップと、を備え、
該検出ステップは、ｍ個の連続する一群の画像に亘る前記画像領域内のポイントについて累積的画像間動作を検出することによって、画像間動作を検出するよう構成され、ここでｍは少なくとも３であることを特徴とするデータ処理方法。
【請求項３１】
コンピュータ・ソフトウェアであって、
コンピュータにロードされると、コンピュータが請求項１乃至請求項２９のいずれか一つに記載のデータ処理装置として動作できるようになるプログラムコードを有することを特徴とするソフトウェア。
【請求項３２】
コンピュータ・ソフトウェアであって、
請求項３０に記載の方法を実行するためのプログラムコードを有することを特徴とするコンピュータ・ソフトウェア。
【請求項３３】
請求項３１または請求項３２に記載のソフトウェアを提供するための提供媒体。
【請求項３４】
請求項３７に記載の媒体であって、前記媒体は、伝送媒体であることを特徴とする媒体。
【請求項３５】
請求項３７に記載の媒体であって、前記媒体は、記憶媒体であることを特徴とする媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公表番号】特表２００９−５３７９２４（Ｐ２００９−５３７９２４Ａ）
【公表日】平成２１年１０月２９日（２００９．１０．２９）
【国際特許分類】
【出願番号】特願２００９−５１１５６４（Ｐ２００９−５１１５６４）
【出願日】平成１９年５月１７日（２００７．５．１７）
【国際出願番号】ＰＣＴ／ＧＢ２００７／００１８１３
【国際公開番号】ＷＯ２００７／１３５３７８
【国際公開日】平成１９年１１月２９日（２００７．１１．２９）
【出願人】（５０２０７０６７９）ソニー コンピュータ エンタテインメント ヨーロッパ リミテッド (40)
【Ｆターム（参考）】
【公表日】平成２１年１０月２９日（２００９．１０．２９）
【国際特許分類】
【出願日】平成１９年５月１７日（２００７．５．１７）
【国際出願番号】ＰＣＴ／ＧＢ２００７／００１８１３
【国際公開番号】ＷＯ２００７／１３５３７８
【国際公開日】平成１９年１１月２９日（２００７．１１．２９）
【出願人】（５０２０７０６７９）ソニー コンピュータ エンタテインメント ヨーロッパ リミテッド (40)
【Ｆターム（参考）】
[ Back to top ]