JP2009181138A - コンピュータ・システムにおけるビデオ映像の使用 - Google Patents

Abstract

【課題】第１、第２のイメージを重ね合わせて表示する際に、一方のイメージを透明化して表示して、両イメージが見えるようにする。
【解決手段】第１のビデオデータ信号を生成する手段と、第２のビデオデータ信号を生成する手段と、前記第２のビデオデータ信号による第２のイメージがディスプレイ上において前記第１のビデオデータ信号による第１のイメージの上で透明に見えるように、前記第１、第２のイメージのピクセルをインターリービングしてレンダリングする手段と、を設けた。
【選択図】 図２

Description

本件出願書類の一部は、著作権に係る資料を含んでいる。著作権者は、特許商標庁の特許書類あるいは記録として現れる場合であれば、特許書類もしくは特許の開示の第三者による複製を拒絶する理由を持たないが、それ以外は、いかなる場合であってもすべての権利を留保する。

背景
１．分野
本発明は、概してコンピュータ・システムに関し、より具体的に述べれば、コンピュータ・システムに対して入力データを提供するための方法に関する。

２．説明
ユーザからコンピュータ・システムに入力データを伝達するために、多くのテクニックならびにデバイスが開発されてきた。選択したタスクをコンピュータに実行させるためには、キーボード、カーソル移動デバイス（たとえばマウス、トラックボール、およびジョイスティック等）、ペンならびにタブレット、バーコード・スキャナ、およびその他のデバイスが使用されている。ビデオ・カメラを、たとえばパーソナル・コンピュータ（ＰＣ）等のコンピュータ・システムに接続する用法も一般的となり、それに伴って新しく興味深い方法でリアルタイムのビデオ・データを使用する機会も現れた。しかしながら、ＰＣにおける最近の多くのアプリケーションは、各種の表示機能に焦点が当てられており、新しい入力パラダイムへの関心は持たれていない。ビデオ・カメラの機能を利用してＰＣユーザの経験を高め、よりＰＣを使用容易にすることが有意義であると見られる。

概要
本発明の一実施形態は、ディスプレイを有するシステムであって、ビデオ・データ信号ソースに接続されたシステムに入力信号を提供する方法である。この方法は、ビデオ・ソースによって生成された、シーンを表すビデオ・データ信号を取り込むステップ、当該シーンがディスプレイ上において透明に見えるようにそのシーンをディスプレイ上でレンダリングするステップ、ビデオ・データ信号を解析してシーン内のオブジェクトを検出するステップ、および検出したオブジェクトに応答してシステム用の入力信号を生成するステップからなる。
本発明の特徴ならびに利点は、以下の本発明の詳細な説明から明らかになるであろう。

本発明の一実施形態に従ったビデオ映像を示すサンプル表示の一部を示した概要図である。 本発明の実施形態に従ってオペレーティング・システム出力グラフィックス・データとともに表示される透明なグラフィックス・データの例を図示した概要図である。 本発明の実施形態に従った透明化の方法を用いたプログラミングに適したサンプル・コンピュータ・システムを示したブロック図である。 本発明の一実施形態に従って透明グラフィックスをインプリメントするためのソフトウエアならびにハードウエア・スタックを示した概要図である。 本発明の一実施形態に従って透明グラフィックスを提供するために使用される複数のフレーム・バッファを示した概要図である。 本発明の一実施形態に従って透明グラフィックス・フレーム・バッファとオペレーティング・システム出力フレーム・バッファの間における、ピクセルを交番させるテクニックを用いた混合を示した概要図である。 本発明の一実施形態に従ってシステムを初期化し、透明グラフィックスを提供する処理を示したフローチャートである。 本発明の一実施形態に従った二重バッファ・コントロール処理を示したフローチャートである。 本発明の一実施形態に従った色混合およびインターリーブの処理を示したフローチャートである。 本発明の一実施形態に従ったビデオ映像入力テクニックを提供するアプリケーション・プログラムのコンポーネントを示した概要図である。 本発明の一実施形態に従ったフィルタ・グラフを示した概要図である。 本発明の一実施形態に従ったフィルタ初期化の処理を示したフローチャートである。 本発明の一実施形態に従ったハンドル入力イベントの処理を示したフローチャートである。 本発明の一実施形態に従った有効な入力イベントを検出するための処理を示したフローチャートである。 本発明の一実施形態に従った透明化を伴うビデオ・レンダラの処理スレッドを示したフローチャートである。 本発明の一実施形態に従った透明混合コアの処理スレッドを示したフローチャートである。

詳細な説明
以下の説明においては、本発明の各種の側面を説明する。ここでは例示を目的とすることから、本発明の完全な理解に資するため具体的な数、システムならびにコンフィグレーションを示している。しかしながら、当業者であれば、これらの具体的な詳細とは別に本発明を実施し得ることは明らかであろう。他方、周知の特徴については、本発明の不明瞭化を回避するため、省略ないしは簡略化して示している。

本発明の一実施形態は、たとえばＰＣ等のコンピュータ・システムにユーザ入力データ信号を提供するための方法である。リアルタイム・ビデオ・イメージは、ＰＣに接続されたビデオ・カメラによって取り込むか、別のビデオ・データ信号ソースから受け取り、取り込んだビデオ・イメージが透明となってディスプレイ上に表示されるように、ＰＣのスクリーン全体に対してそのレンダリングを行う。ビデオ・データ信号は、通常のフォアグラウンド表示イメージを不明瞭にしない形において通常のアプリケーション・プログラムならびにオペレーティング・システム・ソフトウエアの表示出力データと混合することができる。結果として得られる効果は、ビデオ・カメラがユーザに向けられたとき、ユーザ自身を映したイメージがコンピュータ・スクリーンに映り、それと同時にユーザは、デスクトップのアイコンまたはアプリケーション・プログラム表示といったその他の表示エレメントを見ながら、かつそれと対話することが可能になる。この映されたイメージは透明であることから、他の表示エレメントの表示と干渉することがない。

ここでは、ビデオ・カメラに関連して本発明の実施形態のいくつかを説明しているが、これに関して本発明がそのような形に限定されることはない。別の実施形態においては、ビデオ・データ信号ソースを、たとえばビデオ・カセット・レコーダ（ＶＣＲ）、テレビジョン放送信号、あるいは以前ストアしたビデオ・データ信号等の任意のビデオ・ソースとすることができる。

本発明のいくつかの実施形態における１つの特徴は、ユーザが、ユーザ自身の映像またはイメージを、それがビデオ・カメラによって取り込まれた後、コンピュータ・スクリーン上で見ることができるとういうものである。このビデオ映像を使用するユーザは、ビデオ・カメラの視野内に存在する現実のオブジェクト（たとえばユーザの手および指等）を物理的に動かすことによって、コンピュータ・システムのグラフィカル・ユーザ・インターフェース（ＧＵＩ）の、アプリケーション・プログラムおよびオペレーティング・システムの表示エレメントと対話が可能になる。本発明のいくつかの実施形態における入力能力は、現存するアプリケーション・プログラムに対する修正をまったく必要とすることなく与えることができる。本発明の実施形態においては、これらの動きが、アイコンもしくはその他のアプリケーション・プログラム・エレメントの把持または選択といったコンピュータ・システム内のアクション、つまり現在ユーザがマウスまたはその他の選択用デバイスを用いて行っているアクションの割り当てに使用される。ユーザが映されたイメージを観察しながら希望の結果を得るために行うこの物理的な動きのアクティビティは、ユーザにとって非常に自然であり、かつ直感的である。たとえば、ユーザは、鏡に映されたユーザ自身の鏡像を頻繁に見ながら、それをあまり意識せずに、たとえば手を使って物体を操作することがある。それに加えて、ユーザにとって、通常、映された鏡像を見ながら利き腕もしくは逆の腕、または両腕を使用して操作を行うことは容易である。別の実施形態においては、あらかじめ決定された具体的な小道具がコンピュータ内のアクションを割り当てるためのオブジェクトとして使用される。これらの小道具には、能動的または非能動的のものが考えられる。能動的な小道具は、機械的あるいは電気的メカニズムを包含し、たとえば発光ダイオード（ＬＥＤ）ライトを備える。非能動的な小道具には、たとえば色付けしたスティックまたはパドル、布きれ、および色付けしたグローブ等のアイテムになるが、これに関して本発明が限定されることはない。

本発明のいくつかの実施形態は、コンピュータにおけるマウスの使用と完全に置換し得ないと見られるが、コンピュータ・システムにユーザ入力を与える強力かつ新しいパラダイムとなる。特に、本発明によって、現実のオブジェクトを動かしてコンピュータの表示オブジェクトを操作するという自然であり、直接的な方法が提供される。各種タイプのアプリケーション・プログラムは、この入力パラダイムを利用すべく拡張されることになろう。たとえば、コンピュータ・ゲームにおいてビデオ映像を通じたユーザ入力を使用することにより、ユーザ・インタラクションが向上すると考えられる。ユーザがビデオ表示データの選択エリアをポイントするといった動作のあるビデオ・プレゼンテーション・システムは、より使用が容易になる。追加の入力機能を与えるようにテレビ会議アプリケーションを拡張することもできる。ＰＣ／テレビジョン（ＴＶ）の組み合わせにおいて、特にユーザとディスプレイの間の距離が比較的大きい場合に、この入力能力を使用してもよい。多くのユーザにとって、たとえば子供にとっては、現実のオブジェクトを（たとえばユーザ自身の手を使って）操作し、コンピュータに入力を送ることの方が、通常の入力デバイスを使用するより直感的なものとなる。

一実施形態においては、ＰＣに送られ、そこで処理ならびに表示が行われるビデオ・データ信号に含まれるピクセルの色を解析し、ユーザの手などの現実のオブジェクトの動きを追跡することができる。これは、ユーザの手または指に付けた色つきのドットの使用を介して、あるいはその他のコンピュータ・ビジョン方式を通じて支援することができる。それに代えて、特定のオブジェクト（たとえば親指および残りの指、またはその他の小道具）の上に他と区別し得る色を載せて、本発明の実施形態におけるコンピュータ・ビジョン・コンポーネントが入力イベント発生器として認識されるようにオブジェクトが分離および識別されるのを補助するようにしてもよい。

一実施形態においては、ユーザの人指し指および親指の動きに従ってＰＣのマウスのカーソルを動かすことができる。ユーザがユーザ自身の親指と人さし指を合わせて「つまむ」形にすると、取り込まれたビデオ・イメージ内において親指と人さし指のイメージが検出され、マウスを降ろすイベントがオペレーティング・システム・ソフトウエアに導かれる。ユーザがつまむ形にした手を開くと、取り込まれたビデオ・イメージ内において親指と人さし指のポジションおよびそれらのイメージが検出され、マウスを上げるイベントが導かれる。別の実施形態において、特定の入力信号およびイベントを表すこのほかの動きを定義することもできる。

図１は、本発明の一実施形態に従ったビデオ映像を示すサンプル表示の一部を示した概要図である。この例においては、ユーザのイメージがビデオ・カメラによって取り込まれ、透明な態様でディスプレイにレンダリングされている。この状態でユーザは、たとえばアプリケーション・プログラム・アイコン等の表示オブジェクトと対話し、システムに入力信号およびイベントを提供する。

本発明のいくつかの実施形態の基礎となる能力は、コンピュータ・ディスプレイ上にある別の表示データ信号のレイヤの最前面に配置される透明な表示データ信号（たとえば、ビデオ・カメラによって伝えられたビデオ・データ信号等）のレイヤを提供することであり、それによってユーザは、両方のレイヤを明確に、かつ実質的に同時に見ることができる。この能力について、まず一般的な用法を説明し、その後、本発明のいくつかの実施形態における入力検出方法を伴う用法を説明する。透明なウインドウを表示する機能は、アプリケーション・プログラムによる使用のためにディスプレイ上に用意された最大スクリーン・エリアを本質的に２倍にする。一実施形態における透明なコンピュータ・グラフィックス・レイヤを生成する方法の１つは、ビデオ・フレーム・バッファからのピクセルと別のビデオ・フレーム・バッファからのピクセルをインターリーブする（またはパターンを交番させる）ことである。この実施形態においては、第１のフレーム・バッファから選択されたピクセルが、色平均されて第２のフレーム・バッファの対応するピクセルと混合されて、空間多重化のみの使用によってもたらされる「市松模様」効果が抑えられる。それに加えてインターリーブの程度が調整可能であり、また色平均に重み付けを行えば、さらに表示されるイメージの透明度をコントロールすることが可能になる。

この実施形態においては、オペレーティング・システム・ソフトウエアによって使用される出力フレーム・バッファが透明機能の提供によって影響されることがなく、またオペレーティング・システム側では透明オペレーションを意識することがない。つまり、本発明の実施形態によって提供される透明効果は、アプリケーション・プログラムに透明効果を及ぼす事ができるようにアプリケーションプログラムを修正して手を加える必要がない。さらに、アプリケーション・プログラムおよびオペレーティング・システムのウインドウに対する入力オペレーションは、透明なフォアグラウンドの効果によって影響されない。

本発明の一実施形態は、電気信号形式のコンピュータ・グラフィックス出力データまたはビデオ・データ用のフレーム・バッファを少なくとも２つ組み合わせることによって動作する。出力、つまり可視フレーム・バッファのピクセルは、２つの入力フレーム・バッファの内容を空間的にインターリーブすることによって生成される。この実施形態におけるインターリーブは、一方のフレーム・バッファのピクセルと他方のフレーム・バッファのピクセルを合成することによって達成される。この結果、２つのイメージの表示が互いに重ね合った錯視がもたらされる。ピクセルのインターリーブを行うとき、第１のフレーム・バッファのピクセルと第２のフレーム・バッファのピクセルを、それらを配置する直前に色平均する。色平均は、出力フレーム・バッファにインターリーブする前、またはその間に、一方のフレーム・バッファのピクセルと他方のフレーム・バッファのそれに対応するピクセルを平均することによってなされる。その結果、コンピュータ・モニタ等のディスプレイ上に、実質的に同時に見ることができる複数のオーバーラップしたイメージが構成される。

図２は、本発明の実施形態に従って、オペレーティング・システム出力グラフィックス・データとともに表示される透明なグラフィックス・データの例を図示した概要図である。オペレーティング・システム出力フレーム・バッファ１０は、図３に示したコンピュータ・システムの現在の表示データをストアするために使用されるメモリ・エリアである。オペレーティング・システム出力フレーム・バッファは、オペレーティング・システムが使用可能な任意のメモリ内に割り当てることができる。フレーム・バッファは、ピクセル・データの２次元配列をストアするためのストレージ・ロケーションのセットである。オペレーティング・システム出力フレーム・バッファは、データ信号の生成およびコンピュータ・モニタ（図示せず）上におけるその表示をコントロールするコンピュータ・システムのオペレーティング・システム・ソフトウエアと関連付けすることができる。一実施形態においては、オペレーティング・システム・ソフトウエアをＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ（マイクロソフト・コーポレーション）のＷｉｎｄｏｗｓ ９５（登録商標；ウインドウズ９５）またはＷｉｎｄｏｗｓ ＮＴ（登録商標：ウインドウズＮＴ）とするが、それ以外の、グラフィカル・ユーザ・インターフェースをサポートするオペレーティング・システム・ソフトウエアを使用してもよい。この例においては、オペレーティング・システム出力フレーム・バッファ１０が、図２においてラベル１２、１４、および１６をそれぞれ付して示した３つのオーバーラップするウインドウに対応するアプリケーション・プログラムの表示データ信号を含んでいる。

透明グラフィックス・フレーム・バッファ１８は、続いてオペレーティング・システム出力フレーム・バッファの表示データ信号とともに同時に表示する透明グラフィックスの表示データをストアするために使用されるメモリ・エリアである。このメモリ・エリアは、システム内の使用可能な任意のメモリ内に割り当てることができる。透明グラフィックス・フレーム・バッファ１８は、ビデオ・カメラまたはその他のビデオ・データ信号ソースから受け取ったビデオ信号のフレームをストアするために使用される。図２に示した例においては、透明の使用を説明するアプリケーション・プログラム・ディスプレイ形態の表示サンプルとして時計２０および株式相場表示２２等の表示コンポーネントを示しているが、概して任意の表示コンポーネントを本発明の実施形態の使用を介して透明にすることができる。より具体的に述べれば、本発明の実施形態においては、ディスプレイ上の透明イメージのシーケンスとして、取り込んだビデオ・フレームが表示されることになる。

オペレーティング・システム出力フレーム・バッファと透明グラフィックス・フレーム・バッファの表示コンポーネントは、ブロック２４において、それぞれのバッファの選択した対応ピクセルを混合し、同時に色混合オペレーションの結果として得られるピクセルと、オペレーティング・システム出力フレーム・バッファのピクセルをインターリーブすることによって合成され、可視表示バッファ２８の表示コンポーネントが形成される。可視表示バッファは、図画形式を用いて表すと、オーバーラップする３つのウインドウ１２、１４、および１６と、これらのウインドウを部分的にオーバーレイする透明表示コンポーネントとして現れる時計２０および株式相場表示２２となる。この例において、透明表示コンポーネントは、残りの表示コンポーネントを部分的にオーバーレイする。しかしながら、透明表示コンポーネントは、ディスプレイ上における１ないしは複数の不透明ウインドウまたは表示コンポーネントの境界内に完全に含めることができることを理解する必要がある。当然のことながら、特定のアプリケーション・プログラムにおいて、また特定の表示コンポーネントを伴う場合に、一方が実質的にもしくは完全に他方の前面に置かれる２つの表示コンポーネントからのデータの表示が、画質の上での問題をユーザにもたらすこともある。また別のアプリケーション・プログラムにおいては、それにもかかわらず、良好に設計された透明表示コンポーネントをオーバーレイできることが有利かつ望ましいこととなる。

以上に加えて本発明のいくつかの実施形態は、選択されたバックグラウンド・ウインドウに対する入力オペレーションにほとんどもしくはまったく影響を与えない透明表示コンポーネントによるバックグラウンドのウインドウのオーバーレイを可能にする。たとえばユーザは、透明表示コンポーネントが部分的にあるいは完全にバックグラウンド・ウインドウにオーバーレイしている状態において、バックグラウンド・ウインドウに表示されているアプリケーション・プログラムの入力ウインドウと対話することができる。基本的に、オペレーティング・システム・ソフトウエアは、透明表示コンポーネントの表示と実質的な干渉を招くことなく、入力ウインドウに対するユーザ入力イベントまたはキーの打鍵（たとえばマウスのエントリまたはテキストのエントリ等）を受け入れる。

本発明のいくつかの実施形態による透明効果を生成する方法は、表示コンテンツの最小混合を使用している。これは、コンピュータ・モニタ上の隣接ピクセル間を区別し得ないという人間の目の特性を利用している（つまり、人間の目は各ピクセルと近傍のピクセルを平均する）。この方法を用いてピクセルのインターリーブを行ったとき、大型コンピュータ・モニタと低い解像度は「市松模様」効果を生む可能性があるので、いくつかの混合が用いられている。一実施形態においては、第１のフレーム・バッファ（オペレーティング・システム出力フレーム・バッファ等）からのピクセルの１／２および、第２のフレーム・バッファ（透明グラフィックス・フレーム・バッファ等）からのピクセルの１／２を使用し、これらを、２つのフレーム・バッファのピクセルを第３の表示バッファ内にインターリーブするとき平均する。ピクセルの一部を平均することによって、透明効果を与えるときに使用される処理パワーが抑えられる。別の実施形態においては、平均されるピクセルのパーセンテージが異なり（たとえば、１／４のピクセル、１／８のピクセル、１／１６のピクセル、１／３２のピクセルあるいは、任意の正の整数をＮで表した１／Ｎのピクセル）、あるいはこのパーセンテージを動的に変化させることもできる。

図３は、本発明による、ビデオ映像との関連においてユーザ入力を得るために透明表示を生成する方法の実施形態に従ったプログラムに適したサンプル・コンピュータ・システムを示したブロック図である。このサンプル・システム１００は、たとえばここに説明する方法に関する処理を実行するために使用される。サンプル・システム１００は、Ｉｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎ（インテル・コーポレーション）のＰＥＮＴＩＵＭ（登録商標；ペンティアム）、ＰＥＮＴＩＵＭ Ｐｒｏ（登録商標；ペンティアム・プロ）、およびＰＥＮＴＩＵＭ ＩＩ（登録商標；ペンティアムＩＩ）マイクロプロセッサをベースにしたコンピュータ・システムを表しているが、その他のシステム（これ以外のマイクロプロセッサを有するパーソナル・コンピュータ（ＰＣ）、エンジニアリング・ワークステーション、セットトップ・ボックス等を含む）を使用することもできる。サンプル・システム１００は、プロセッサ・バス１０５を介して相互に接続されるマイクロプロセッサ１０２およびキャッシュ・メモリ１０４を備えている。さらにサンプル・システム１００は、高性能Ｉ／Ｏバス１０８および標準Ｉ／Ｏバス１１８を備える。プロセッサ・バス１０５と高性能Ｉ／Ｏバス１０８は、ホスト・ブリッジ１０６によってブリッジされ、高性能Ｉ／Ｏバス１０８と標準Ｉ／Ｏバス１１８は、Ｉ／Ｏバス・ブリッジ１１０によってブリッジされている。高性能Ｉ／Ｏバス１０８には、メイン・メモリ１１２およびビデオ・メモリ１１４が接続されている。このビデオ・メモリ１１４には、ビデオ・ディスプレイ１１６が接続されている。標準Ｉ／Ｏバス１１８には、大容量ストレージ１２０、キーボードおよびポインティング・デバイス１２２が接続されている。一実施形態においては、さらにビデオ・カメラ５０１が標準Ｉ／Ｏバス１１８に接続される。

これらのエレメントは、当分野において周知の通常の機能を実行する。特に大容量ストレージ１２０は、本発明に従ったビデオ映像の使用を通じてユーザ入力を得るための方法の実施形態に関する実行可能インストラクションを長期間にわたるストアするために使用され、メイン・メモリ１１２は、マイクロプロセッサ１０２による実行間に、本発明に従ったビデオ映像の使用を通じてユーザ入力を得るための方法の実施形態に関する実行可能インストラクションの短期間ベースのストアに使用される。

図４は、本発明の一実施形態に従って透明グラフィックスをインプリメントするためのソフトウエアならびにハードウエア・スタックを示した概要図である。透明表示オブジェクトを使用するために設計されたアプリケーション・プログラム２００は、透明サポート・ソフトウエア２０２によって提供される関数を呼び出し、透明表示オブジェクトの定義ならびに更新を行う。これに応答して透明サポート２０２は、この実施形態においては、オペレーティング・システムのグラフィックス・レンダリング・プログラミング・インターフェース（グラフィックスＡＰＩ）２０４を呼び出す。Ｗｉｎｄｏｗｓ ９５（登録商標；ウインドウズ９５）オペレーティング・システムの場合であれば、これをグラフィックス・デバイス・インターフェース（ＧＤＩ）とすることができる。この実施形態においては、透明サポート・ソフトウエア２０２が、オペレーティング・システムのビデオ・ハードウエア・コントロール・アブストラクション・プログラミング・インターフェース（ビデオ・コントロールＡＰＩ）２０６も呼び出す。Ｗｉｎｄｏｗｓ ９５（登録商標；ウインドウズ９５）オペレーティング・システムの場合であれば、これをＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ（マイクロソフト・コーポレーション）のＤｉｒｅｃｔＤｒａｗ（商標；ダイレクトドロー）ＡＰＩとすることができる。オペレーティング・システムによっては、グラフィックスＡＰＩ ２０２およびビデオ・コントロールＡＰＩ ２０６が同一のアプリケーション・プログラミング・インターフェース内に存在することから、それぞれの区別ができないこともある。グラフィックスＡＰＩ ２０４は、要求されたグラフィックスを、図２に示されるように、透明グラフィックス・フレーム・バッファ１８にレンダリングするために使用することができる。ビデオ・コントロールＡＰＩ ２０６は、フレーム・バッファの透明度をコントロールし、またすべてのフレーム・バッファのコンテンツにアクセスするために使用することができる。この実施形態においては、ビデオ・カード２１０と通信するために、グラフィックスＡＰＩ ２０４およびビデオ・コントロールＡＰＩ ２０６がディスプレイ・ドライバ・ソフトウエア２０８と対話する。このビデオ・カード２１０は、図３のシステムにおけるビデオ・ディスプレイ１１６をコントロールする。ビデオ・カードは、表示データを獲得するためにビデオ・メモリ１１４にアクセスする。透明を使用しないその他のアプリケーション・プログラム２１２は、グラフィックスＡＰＩ ２０４と対話して表示オブジェクトの生成および更新を行う。

一般的に、ビデオ・メモリ１１４内にピクセル・データのフレーム・バッファを作ることによって、たとえばコンピュータ・モニタ等のディスプレイ上に表示を行っている。このフレーム・バッファは、ビデオ・コントロールＡＰＩ ２０６によってビデオ・メモリの可視部分として設計することができる。充分なビデオ・メモリが使用可能な場合は、複数のフレーム・バッファを利用し、一度にそれらの１つのみを使用（ビデオ・カード２１０によって）して現在の可視表示を構築するためのデータ信号を獲得すればよい。周知の二重バッファリング・テクニックにおいては、第１のフレーム・バッファを「可視」バッファとし、ビデオ・カード２１０は、現在の表示データ信号を獲得するためにそこからデータ信号を読み出し、第２のフレーム・バッファ（または「不可視」バッファ）には新しい表示データが書き込まれる。この実施形態においては、次にビデオ・コントロールＡＰＩが呼び出されてフレーム・バッファの「交代」が起こり、第２のフレーム・バッファが可視バッファに、第１のフレーム・バッファが不可視バッファに設定される。このテクニックを使用することによって、表示データを滑らかに更新し、ユーザに審美的に好ましい表示が提供される。本発明の実施形態は、このコンセプトを拡張し、通常の表示データとともに透明表示データ信号を供給する追加のフレーム・バッファを使用する。

図５は、透明グラフィックスを提供するために使用される複数のフレーム・バッファの実施形態を示した概要図である。ビデオ・メモリに少なくとも１つの専用部分を割り当て、コンピュータ・モニタで一度に見ることができる表示とすることができる。これを「可視表示」と呼んでいる。つまり、可視表示は、ユーザに見せるためにコンピュータ・モニタ上に現在表示されているビデオ・メモリのエリアの表示データからなる。概してこの実施形態においてオペレーティング・システム・ソフトウエアのグラフィックスＡＰＩ ２０４は、オペレーティング・システム出力フレーム・バッファ１０にデータ信号を書き込む。ほとんどの現在のシステムにおいては、可視表示用にビデオ・メモリ１１４内に常駐するオペレーティング・システム出力フレーム・バッファが使用されている。しかしながら、本発明の実施形態においては、可視表示に別のフレーム・バッファが使用されることがある。第１のワーキング・フレーム・バッファ３００および第２のワーキング・フレーム・バッファ３０２は、いずれもビデオ・メモリ１１４内もしくはその他のアクセス可能メモリ内に常駐し、本発明の実施形態に従って表示データをストアする。この実施形態においては、各フレーム・バッファがピクセル・データ信号の配列をストアする。この実施形態におけるフレーム・バッファのサイズは、システムの現在の表示特性に応じたものとなる。フレーム・バッファ配列は、たとえば、６４０ピクセル×４８０ピクセル、８００ピクセル×６００ピクセル、または１２８０ピクセル×１０２４ピクセル、あるいはコンピュータ・モニタおよびオペレーティング・システム・ソフトウエアのセッティングに応じたこれら以外の適切なサイズとなる。それぞれのピクセルは、レッド（Ｒ）、グリーン（Ｇ）、およびブルー（Ｂ）成分を含み、オプションとして不透明度（Ａ）成分を有する。それに代えて、これら以外の、たとえばＹＵＶあるいはＹＵＶＡ等のカラー・コーディング・スキームを使用してもよい。メイン・メモリ１１２またはビデオ・メモリ１１４に常駐する複数の透明グラフィックス・フレーム・バッファ１８、１９は、この実施形態においては、透明サポート・ソフトウエア２０２、ビデオ・コントロールＡＰＩ ２０６およびグラフィックスＡＰＩ ２０４によって作られた透明表示データ信号をストアする。透明グラフィックス・フレーム・バッファ１８、１９は、ワーキング・フレーム・バッファに類似の「二重バッファ」であり、透明表示されるイメージの迅速な更新を提供する。

一実施形態においては、透明グラフィックス・フレーム・バッファ１８、１９の一方からのデータ信号がオペレーティング・システム出力フレーム・バッファ１０からのデータ信号と混合され、インターリーブされ、その後ワーキング・フレーム・バッファの１つにストアされる。別の実施形態においては、この混合が、アルファ・ブレンド用の専用回路の支援の下に達成される。混合され、インターリーブされたデータは、ワーキング・フレーム・バッファの１つが「不可視」状態にあるとき、そのワーキング・フレーム・バッファにストアすることができる（つまり、この実施形態においては、このフレーム・バッファにストアされるデータは、コンピュータ・モニタ上に現在表示されていないデータである）。ワーキング・フレーム・バッファの１つに対して不可視状態で書き込みを行っている間は、他方のワーキング・フレーム・バッファを「可視」状態に置いて現在の表示データのソースとして使用することができる。ワーキング・フレーム・バッファに関する色混合およびインターリーブのオペレーションが完了したとき、不可視ワーキング・フレーム・バッファを可視ワーキング・フレーム・バッファに指定し、他方について状態を反転させる。このワーキング・フレーム・バッファの処理の二重バッファリングは、この実施形態においては１秒当たり少なくとも８〜１５回のレートで繰り返され、視覚的に好ましい表示をユーザに提供する。それに加えて、この実施形態における透明グラフィックス・フレーム・バッファの使用も二重バッファとなっている。この実施形態においては、現在修正が行われているフレーム・バッファに対する色混合ができないこと、また、混合が行われているフレーム・バッファを同時に更新できないことから、透明グラフィックス・フレーム・バッファの二重バッファリングが使用される。二重バッファリングを行わないと、表示されたイメージにエラーを生じ、あるいは不必要な処理遅延が招かれることがある。

本発明のいくつかの実施形態においては、透明グラフィックス・フレーム・バッファの１つのピクセルと、オペレーティング・システム出力フレーム・バッファのピクセルのインターリーブを次のようにして達成することができる。すなわち、一実施形態においては、透明グラフィックス・フレーム・バッファのピクセル値と、空間的に対応するオペレーティング・システム出力フレーム・バッファのピクセル値を混合することによって、選択ワーキング・フレーム・バッファ内に１つ置きにピクセルを書き込む。選択ワーキング・フレーム・バッファ内のそれ以外のピクセルは、オペレーティング・システム出力フレーム・バッファからのピクセルを用いて書き込む。別の実施形態においては、オペレーティング・システム出力フレーム・バッファからのピクセルを選択ワーキング・フレーム・バッファにブロック転送し、続いて透明グラフィックス・フレーム・バッファからのピクセルを選択ワーキング・フレーム・バッファのピクセルを用いて空間的に多重化し、色平均する。さらに別の実施形態においては、アルファ・ブレンドを実行するためのビデオ・カード上の回路の補助を受けてこの混合が行われる。ここで、アルファ・ブレンド用の専用回路を使用するときは、インターリーブが必要なくなる点に注意されたい。

図６は、透明グラフィックス・フレーム・バッファの１つとオペレーティング・システム出力フレーム・バッファの間における１つ置きのピクセル混合方法の一実施形態を示した概要図である。選択ワーキング・フレーム・バッファ内の「Ｔ＋ＯＳ混合」として示したピクセルは、選択した透明グラフィックス・フレーム・バッファからのピクセル（値Ｔ）と、オペレーティング・システム出力フレーム・バッファからのピクセル（値ＯＳ）の色平均による混合からなる。選択ワーキング・フレーム・バッファ内の「ＯＳ」ピクセルは、オペレーティング・システム出力フレーム・バッファからコピーした空間的に対応するピクセルを含んでいる。この実施形態においては、２つのフレーム・バッファ内の対応するポジションからの各ピクセルの、各色成分に対して重み付け平均スキームを適用することによって色平均を行っているが、別の実施形態においては、別の色混合テクニックを使用することができる。一実施形態においては、第１のピクセルの成分の値に重み値を乗じ、第２のピクセルの同じ成分の値に別の重み値を乗ずることによって重み付け平均が行われる。２つの重み付けした色成分は、続いて互いに加算し、結果として得られた和を２つの重み値の和を用いて除す。この方法は、アルファ・ブレンドと呼ばれている。この交番パターンを使用することにより、透明効果を生成するために使用される処理を、たとえばフレーム・バッファの全ピクセルを混合する場合に比べると、その半分に抑えることができる。ビデオ・メモリ内におけるピクセル・データの移動は、この実施形態の場合、ドローイングＡＰＩまたはビデオ・コントロールＡＰＩによって提供されるブロック転送オペレーションを用いて実行することができる。

別の実施形態においては、使用する特定のインターリーブ・パターンに応じて、混合ピクセルが選択ワーキング・フレーム・バッファ内のピクセルの１／４、ワーキング・フレーム・バッファ内のピクセルの１／８、あるいは正の整数Ｎを用いて１／Ｎと表される他の任意のパーセンテージとなる。さらに別の実施形態においては、インターリーブのパターンが変更される。たとえば、透明グラフィックス・フレーム・バッファからのラインとオペレーティング・システム出力フレーム・バッファからのラインを水平に交番させたインターリーブ・パターンとすることが考えられる。それに代えて、透明グラフィックス・フレーム・バッファからのラインとオペレーティング・システム出力フレーム・バッファからのラインを垂直に交番させたインターリーブ・パターンとすることもできる。市松模様パターンと水平または垂直に交番するラインの組み合わせも使用可能である。当業者であれば、本発明の実施形態において、透明効果の程度の変化とともに各種のインターリーブ・パターンの使用が可能であり、特定のパターンに本発明の範囲が限定されないことを理解されよう。

本発明の別の実施形態においては、インターリーブ・パターンが周期的に、もしくは非周期的に、あるいはあらかじめ決めた方法で変更される。たとえば、前述した各種のインターリーブ・パターンのうちの任意の２つを使用し、一方のインターリーブ・パターンを透明グラフィックス・フレーム・バッファの第１の生成に使用し、他方のインターリーブ・パターンを透明グラフィックス・フレーム・バッファの、それに続く第２の生成に使用するというように交番させる。この処理を繰り返し、それによって空間的な、つまり色混合と、時間的な透明の方法をハイブリッドする。

さらに別の実施形態においては、専用回路を使用して、ソフトウエアによるピクセルの混合の必要性をなくすことができる。

ここで、透明グラフィックス・フレーム・バッファ内の各ピクセルを、複数回にわたって使用し、あるいはまったく使用しないことにより、結果として得られる透明出力において拡大または縮小の効果を達成できることに注意されたい。ピクセルの再使用もしくは不使用の頻度およびそのロケーションは、少なくとも部分的には、希望する拡大または縮小の量に依存する。

図７は、システムを初期化して透明グラフィックスを提供するための実施形態を示したフローチャートである。ブロック４００においては、オペレーティング・システムの表示出力コントロール情報を決定する。このコントロール情報は、表示サイズ、色分解能、およびそのほかのデータからなる。続いてこの実施形態の場合は、ブロック４０２においてビデオ・メモリ内に２つのワーキング・フレーム・バッファを割り当てることになる。これらのオペレーションは、この実施形態の場合であれば、ビデオ・コントロールＡＰＩを呼び出すことによって実行することになる。ブロック４０４において、ブロック転送オペレーションを実行すれば、通常の状態で可視となっているオペレーティング・システム出力フレーム・バッファから２つのワーキング・フレーム・バッファのうちの選択した１つにデータをコピーすることができる。ここで、この例の場合は、第２のワーキング・フレーム・バッファを最初に選択すると仮定するが、第１のワーキング・フレーム・バッファを最初のワーキング・フレーム・バッファとして選択してもよい。ブロック転送は、この実施形態の場合、ビデオ・コントロールＡＰＩを呼び出すことによって実行することになる。ブロック４０６においては、ビデオ・コントロールＡＰＩを呼び出すことによってオペレーティング・システム出力フレーム・バッファを「不可視」状態にセットする。この実施形態の場合は、ブロック４０８において、選択したワーキング・フレーム・バッファ（たとえば第２のワーキング・フレーム・バッファ）を、ビデオ・コントロールＡＰＩを呼び出すことによって可視にしている。別の実施形態においては、１回のビデオ・コントロールＡＰＩ呼び出しによってブロック４０６およびブロック４０８が実行されることもある。この時点において、ビデオ・カードの現在の表示出力データは、オペレーティング・システム出力フレーム・バッファではなく、選択したワーキング・フレーム・バッファから獲得できるようになる。別の実施形態においては、同一の結果を得るために他のＡＰＩが使用されることもある。

図８は、二重バッファ・コントロール処理の実施形態を示したフローチャートである。スタート・ブロック４１０の後、この実施形態の場合は、ブロック４１２においてビデオ・コントロールＡＰＩを呼び出すことによって、ブロック転送オペレーションを実行し、不可視の第１のワーキング・フレーム・バッファにオペレーティング・システム出力フレーム・バッファをコピーしている。ブロック４１４においては、第１のワーキング・フレーム・バッファと透明グラフィックス・フレーム・バッファのうちの選択した１つのコンテンツを混合しインターリーブし、それを第１のワーキング・フレーム・バッファに書き込むオペレーションが行われる。ブロック４１６においては、第１のワーキング・フレーム・バッファを可視に、第２のワーキング・フレーム・バッファを不可視にそれぞれ変えて、結果的に、現在の表示出力データ・ソースとして２つのフレーム・バッファを交代させる。ブロック４１８においては、この実施形態の場合、ビデオ・コントロールＡＰＩを呼び出すことによってブロック転送を実行し、不可視の第２のワーキング・フレーム・バッファにオペレーティング・システム出力フレーム・バッファをコピーする。ブロック４２０においては、第２のワーキング・フレーム・バッファと透明グラフィックス・フレーム・バッファのうちの選択した１つのコンテンツを混合し、インターリーブし、それを第２のワーキング・フレーム・バッファに書き込むオペレーションが行われる。この選択した透明グラフィックス・フレーム・バッファは、ブロック４１４においてすでに選択している透明グラフィックス・フレーム・バッファあるいはその他の透明グラフィックス・フレーム・バッファとすることができる。ブロック４２２においては、第２のワーキング・フレーム・バッファを可視に、第１のワーキング・フレーム・バッファを不可視にそれぞれ変えて、結果的に、現在の表示出力データ・ソースとして２つのフレーム・バッファを交代させる。その後ブロック４１２に戻り、上記の処理を繰り返すことになる。以上のブロックのそれぞれの間に、オペレーティング・システム・ソフトウエアは、同時にオペレーティング・システム出力フレーム・バッファ内に追加の表示データを書き込むことができる。

ブロック４１４および４２０における色混合およびインターリーブのオペレーションの実施形態について図９を参照してさらに詳しく説明する。ブロック４２６においては、現在の選択している透明グラフィックス・フレーム・バッファの参照ポイントを設定するため、現在不可視になっている（第１または第２の）ワーキング・フレーム・バッファ内のメモリ・ロケーションを決定する（たとえばポイントＭ ３０４）。ブロック４２８においては、現在不可視になっているワーキング・フレーム・バッファからピクセルのデータ信号値を読み出し、現在選択している透明グラフィックス・フレーム・バッファ内の、それと空間的に対応するピクセルを決定する。透明グラフィックス・フレーム・バッファのイメージを拡大し、あるいは縮小することによってワーキング・フレーム・バッファの部分に適合させることがあるため、この対応は、必ずしも１：１とならないことがある。このピクセル対応の決定は、当分野において周知であり、一般的にオペレーティング・システム・ソフトウエアにおける引き延ばしブロック転送（たとえばＷｉｎｄｏｗｓ ９５（登録商標；ウインドウズ９５）オペレーティング・システムにおけるＳｔｒｅｔｃｈＢｌｔ ｆｕｎｃｔｉｏｎ）に使用されている。次のブロック４３０においては、この実施形態の場合、ワーキング・フレーム・バッファからのピクセルと、現在選択している透明グラフィックス・フレーム・バッファからのピクセルの重み付け平均を計算する。個別のピクセル成分の重み付け平均は、色成分ベースによりそれぞれの色成分に対して決定することができる。つまり、レッド成分の平均、ブルー成分の平均、およびグリーン成分の平均がそれぞれ可能である。それぞれの成分に対する重みは、結果として得られるピクセルの透明度を決定するが、所定のピクセルのすべての成分に対して同一の重み値を使用してもよい。ピクセルに関連付けされた重みは、少なくとも部分的に透明度に影響を及ぼす。これらの重みが、各種の混合比を達成するために透明度を使用するアプリケーション・プログラムによって操作されることもある。また、これらの透明度を使用するアプリケーション・プログラムから、ユーザによる直接ないしは間接的に混合比のコントロールを可能にするユーザ・インターフェース・エレメントが提供されることもある。

重み付け平均計算の結果は、ブロック４３２において、ワーキング・フレーム・バッファ内の処理中の現在のピクセルと同一のロケーションに格納すればよい。ブロック４３４においては、現在のインターリーブ・パターン（たとえば、２ピクセルごとに１つ、４ピクセルごとに１つ、水平または垂直の１つ置きのライン等）を考慮に入れて、ワーキング・フレーム・バッファ内の、次に処理するロケーションを決定する。ブロック４３６においては、ワーキング・フレーム・バッファ内に未処理のピクセルがあり、現在選択している透明グラフィックス・フレーム・バッファの処理が必要であるか否かを判断し、それに該当すれば、ブロック４２８に戻って次のピクセルを用いてこの処理を継続する。それに該当しない場合には、ブロック４３８において色混合およびインターリーブの処理を終了する。

別の実施形態においては、専用アルファ・ブレンド回路を使用するビデオ・コントロールＡＰＩのブロック転送を通じてピクセルの混合が行われる。

図１０は、本発明の実施形態に従ったビデオ映像入力テクニックを提供するアプリケーション・プログラムのコンポーネントを示した概要図である。ビデオ・データ信号５００は、図３に示したコンピュータ・システムに接続されたビデオ・カメラ５０１によって、あるいはその他の任意のビデオ・ソースによって生成することができる。ビデオ・カメラは、標準Ｉ／Ｏバス１１８に接続され、大容量ストレージ１２０内もしくはメイン・メモリ１１２内のストレージにビデオ・データ信号５００を提供する。コンピュータ・システム１００にビデオ・データ信号が取り込まれると、マイクロプロセッサ１０２によって実行される、たとえば図１０に示したアプリケーション・プログラム５０２およびフィルタ・グラフ・マネージャ５０４等のプログラムがそれを処理する。引き続き図１０を参照すると、アプリケーション・プログラム５０２は、ユーザに所望の機能を与えるように設計することができる。最低限この実施形態においては、このアプリケーション・プログラムがビデオ映像の使用を介したユーザ入力機能を提供するように設計されている。このアプリケーション・プログラムは、コンピュータ・システムのプロセッサによって実行されている他のアプリケーション・プログラム（図示せず）およびオペレーティング・システム・ソフトウエア（図示せず）と対話することができる。アプリケーション・プログラム５０２が、本発明のいずれかの実施形態に従ったビデオ映像の使用を介したユーザ入力による選択機能を提供するように設計されているときには、このアプリケーション・プログラムに、フィルタ・グラフ・マネージャ５０４、フィルタ初期化５０６、ハンドル入力イベント５０８、フィルタ・グラフ５１０、およびＣＯＭインターフェース５１２が含まれる。

一実施形態においては、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ（マイクロソフト・コーポレーション）が提供するＡｃｔｉｖｅＭｏｖｉｅ（商標；アクティブムービー）アプリケーション・プログラミング・インターフェース（ＡＰＩ）（ＤｉｒｅｃｔＳｈｏｗ（商標；ダイレクトショー）またはＤｉｒｅｃｔＭｅｄｉａ（商標；ダイレクトメディア）ＡＰＩとしても知られている）のフィルタ・グラフ・アーキテクチャの一部としてフィルタ・グラフ５１０が生成されるものとするが、別の実施形態においては別のＡＰＩが使用されることもあり、これに関して本発明の範囲が拘束されることはない。ＡｃｔｉｖｅＭｏｖｉｅ（商標；アクティブムービー）は、マルチメディア・データ信号のストリームをはじめ、ユーザによる、各種の周知のデータ・フォーマットを使用してコンピュータ上にエンコードされたディジタル・ビデオならびにサウンドの再生を可能にするアーキテクチャを使用するランタイム環境のソフトウエアをコントロールし、処理するためのソフトウエア・アーキテクチャである。この再生機能は、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ（マイクロソフト・コーポレーション）のＤｉｒｅｃｔＸ（商標；ダイレクトＸ）のＡＰＩセットをサポートするビデオならびにオーディオ・ハードウエア・カードを使用するが、それ以外のＡＰＩを使用することも可能であり、これに関して本発明の範囲は限定されない。ＡｃｔｉｖｅＭｏｖｉｅ（商標；アクティブムービー）アーキテクチャは、フィルタ・グラフ５１０と呼ばれるコンフィグレーション内に結合されているフィルタと呼ばれるモジュラ・ソフトウエア・コンポーネントを使用することによって、タイムスタンプ付きのマルチメディア・データ信号のストリームをコントロールし、処理する方法を定義する。

フィルタ・グラフ・マネージャと呼ばれるソフトウエア・オブジェクト５０４は、フィルタ・グラフ５１０をアッセンブルする方法、およびフィルタ・グラフを介してデータを移動させる方法をコントロールするためにアプリケーション・プログラム５０２によってアクセスされる。例として示したフィルタ・グラフ・マネージャは、フィルタ・グラフを生成し、管理する。このフィルタ・グラフは、ビデオ・データ信号を処理するためのカスタム・フィルタを少なくとも１つ含んでいる。フィルタ・グラフ・マネージャ５０４は、コンポーネント・オブジェクト・モデル（ＣＯＭ）インターフェース５１２のセットを提供して、フィルタ・グラフとアプリケーション・プログラム５０２の間の通信を可能にする。アプリケーション・プログラム５０２は、フィルタ・グラフ・マネージャのＣＯＭインターフェースを呼び出すことによって、マルチメディア・データ・ストリームの処理をコントロールし、あるいはフィルタ・イベントを検索することができる。これに接続されたビデオ・カメラ５０１から到来するビデオ・データ・ストリームをアプリケーション・プログラム５０２が処理することから、この実施形態においては、フィルタ・グラフ・マネージャおよびフィルタ・グラフがアプリケーション・プログラム内に統合されている。別の実施形態においては、フィルタ・グラフ・マネージャがアプリケーション・プログラムとは別の独立したプログラムとなることもある。

一実施形態においては、フィルタ・グラフ・アーキテクチャのすべてのコンポーネントをＣＯＭオブジェクトとして実装することができる。これには、データ信号が通過するフィルタ、フィルタ間の接続としての機能あるいはメモリを割り当てるフィルタ・コンポーネントも含まれる。各オブジェクトは、１ないしは複数のインターフェースを実装し、そのそれぞれは、メソッドと呼ばれるあらかじめ定義された関数のセットからなる。概して、アプリケーション・プログラム５０２は、メソッドを呼び出して、インターフェースに面しているオブジェクトと通信する。たとえば、アプリケーション・プログラムは、フィルタ・グラフ・マネージャ５０４のオブジェクト上のＩＭｅｄｉａＣｏｎｔｒｏｌ（アイメディアコントロール）インターフェース上において、マルチメディア・データ・ストリームを開始するＲｕｎメソッド等のメソッドを呼び出すことができる。一方、フィルタ・グラフ・マネージャは、フィルタ・グラフ５１０のフィルタのそれぞれが面しているＩＦｉｌｔｅｒインターフェースにＲｕｎメソッドを呼び出す。

フィルタ・グラフ５１０は、各種タイプのフィルタのコレクションからなる。ほとんどのフィルタは、３つのタイプのいずれかに分類することができる。ソース・フィルタは、ディスク上のファイル、サテライト・フード、インターネット・サーバ、あるいはビデオ・カメラ５０１等の何らかのソースからデータ信号を取り込み、そのデータ信号をフィルタ・グラフに導く。変換フィルタは、データ信号を取り込み、それを処理して別のフィルタに渡す。レンダリング・フィルタは、データ信号のレンダリングを行う。通常、処理されたデータ信号は、コンピュータ・ディスプレイ等のハードウエア・デバイスにレンダリングされるが、データを、メディア入力を受け入れる別のロケーションにレンダリングすることもできる（たとえば、メモリ、ディスク・ファイル等）。

一般にフィルタ・グラフは、フィルタを介した、たとえばビデオ・データ等のマルチメディア・データのストリーミングのために使用される。マルチメディア・データ・ストリームにおいては、フィルタ・グラフ内において、１つのフィルタから下流にある次のフィルタにマルチメディア・データが渡される。フィルタ・グラフを動作させるために、フィルタをあらかじめ決定した順序で接続し、マルチメディア・データ・ストリームを、決定されたその順序で開始および停止することができる。フィルタ・グラフ・マネージャは、フィルタを接続し、マルチメディア・データ・ストリームをコントロールする。マルチメディア・データ・ストリームのコントロールは、マルチメディア・データ・ストリームの開始、ポーズ、もしくは停止、特定の持続時間にわたるデータ・ストリームの再生、またはデータ・ストリーム内の特定ポイントのシークからなる。フィルタ・グラフ・マネージャ５０４は、アプリケーション・プログラム５０２によるこれらのアクティビティの指定、およびそれに続き、それらを起動するためのフィルタ上の適切なメソッドの呼び出しを可能にする。またフィルタ・グラフ・マネージャは、フィルタによるポスト・イベント通知を可能にし、アプリケーション・プログラムはそれを受け取ることができる。このようにしてアプリケーション・プログラムは、そのアプリケーション・プログラムがフィルタ・グラフにインストールしたフィルタの、マルチメディア・データがそのフィルタ・グラフを通過した後の状態を引き出すことができる。

初期化の処理の間に、アプリケーション・プログラム５０２は、フィルタ・グラフ・マネージャ５０４に対してフィルタ・グラフを記述したグラフ・ファイル（図示せず）のロードを指示する。フィルタ・グラフ・マネージャは、このグラフ・ファイルおよびフィルタ初期化５０６から受け取ったフィルタ特性コマンドに基づいてフィルタ・グラフ５１０を生成する。フィルタ特性コマンドは、名前によって特定のフィルタを参照し、そのフィルタ用の入力およびコントロール・パラメータを指定する。ビデオ・データ５００がフィルタ・グラフを介してストリーミングされ、指定のフィルタに従って処理されるとき、イベント通知（ウインドウ・メッセージとしても知られる）がフィルタ・グラフからＣＯＭインターフェース５１２を介してハンドル入力イベント５０８に送られる。一実施形態においては、この入力イベントを、マウスを降ろすイベント、またはマウスを上げるイベントとして判断することができる。別の実施形態においては、この入力イベントを、フィルタ・グラフによるビデオ・データ・ストリームの処理の間に検出された任意のユーザ入力による選択とすることができる。ハンドル入力イベント５０８は、イベント通知を受け取ると、アプリケーション・プログラム５０２のためにその処理を行う。一部の実施形態においては、ハンドル入力イベント５０８が、希望の機能を実行するためのアプリケーション・プログラム内にある別のコンポーネントに対する呼び出しからなる。

図１１は、本発明の一実施形態に従ったフィルタ・グラフを示した概要図である。この実施形態においては、フィルタ・グラフが７つのフィルタ：すなわちビデオ・キャプチャ・フィルタ５２０、ティー・フィルタ５２２、オプションの第１ならびに第２の色空間コンバータ・フィルタ５２４、５２６、透明化を伴うビデオ・レンダラ・フィルタ５２８、色解析フィルタ５３０、およびブロブ検出フィルタ５３２から構成されるものとするが、これに関して本発明の範囲が限定されることはない。ビデオ・キャプチャ・フィルタ５２０は、ＰＣが、それに接続されたビデオ・カメラまたはその他のビデオ・ソースから受け取ったビデオ・データ信号の個別のフレームを取り込む。ビデオ・データ信号の各フレームは、ティー・フィルタ５２２に渡される。ティー・フィルタは、このビデオ・データ信号を実質的に類似の２つのデータ・ストリームに分岐する。一方のデータ・ストリームは、第１の色空間コンバータ・フィルタ５２４に渡され、他方のデータ・ストリームは、第２の色空間コンバータ・フィルタ５２６に渡される。第１の色空間コンバータは、ビデオ・データ信号の色空間がシステムの表示色空間と類似になるように第１のデータ・ストリームを変換する。一実施形態においては、ビデオ・データ信号のピクセル・フォーマットがビデオ・カードのピクセル・フォーマット（たとえば、１６ビットＲＧＢカラー、または２４ビットＲＧＢカラー等）に一致しなければならない。第１の色空間コンバータ・フィルタからの変換済みデータ信号は、透明化を伴うビデオ・レンダラ・フィルタ５２８に渡される。透明化を伴うビデオ・レンダラ・フィルタ５２８は、図４〜９を参照して説明を前述した透明化の方法により、ディスプレイ上において第１のデータ・ストリームのレンダリングを行う。またビデオ・データ信号を、各フレームの仮想中心線に関して変換、つまり「裏返し」を行い、シーンの左右におけるオブジェクトがディスプレイの同じ側に現れるようにしてもよい（つまり、シーンが鏡に映ったようにディスプレイ上に現れることになる）。

この実施形態においては、第２の色空間コンバータ・フィルタ５２６が第２のデータ・ストリームを、第２のデータ・ストリームのそれぞれのピクセルごとに、アルファ値を使用して追加のピクセル情報を保持することができるレッド、グリーン、ブルー、アルファ（ＲＧＢＡ）の色フォーマットに変換する。第２の色空間コンバータ・フィルタからの変換済みデータ信号は、色解析フィルタ５３０に渡される。この色解析フィルタは、第２のデータ・ストリームのピクセルを解析し、指定のアルファ「Ａ」値を用いて指定色範囲内のピクセルの色値に対するタグ付けを行う。タグ情報が追加された第２のデータ・ストリームは、ブロブ検出フィルタ５３２に渡される。

ブロブ検出フィルタは、このデータ・ストリームを解析し、指定のアルファ値を伴うピクセルのブロックおよびポスト・イベント通知（たとえばメッセージ）を探し出し、アプリケーション・プログラム５０２のウインドウをコントロールする。アプリケーション・プログラムは、これらのイベント通知をハンドル入力イベント５０８に送る。一実施形態においては、ブロブ検出フィルタを、色解析フィルタによってタグ付けされたあらかじめ決定された所定色の、実質的に連続なブロックを探し出すように設定することができる。ブロックは、色のブロブと呼ばれることもある。ここでは、ブロブが、他と区別可能な色を伴う所定の物理的属性を有し、ピクセルのグループとしてディジタル的に表すことができるものとする。ブロブ検出フィルタには、検出したブロブをレポートする指定のウインドウ・ハンドルが通知される。一実施形態においては、ブロブ検出フィルタがビデオ・データ・ストリーム内においてブロブを検出したとき、あらかじめ決定されたパターンのブロブが入力イベントとして判断され、ハンドル入力イベント機能が、そのブロブが設定済みの評価基準またはあらかじめ決定されている評価基準に適合することを検証する。この場合、ビデオ・データ・ストリーム（つまり、現在のビデオ・フレーム）内のブロブのロケーションをハンドル入力イベント５０８に渡すこともできる。

図１１に示した実施形態においては、ブロブ検出フィルタおよび色解析フィルタが別体のフィルタとして図示されているが、別の実施形態においては、これらのフィルタの機能を単一のフィルタに統合するか、あるいはビデオ・レンダラ・フィルタと結合することもできる。当業者であれば、これらのフィルタの各種の組み合わせが使用可能であり、これに関して本発明が限定されないことを理解されよう。

図１２は、本発明の一実施形態に従ったフィルタ初期化の処理を示したフローチャートである。概してフィルタ初期化５０６は、フィルタ・グラフ・マネージャ５０４に対してフィルタ・グラフ５１０を生成して初期化し、フィルタ・グラフを通るビデオ・データ信号のフローを開始する指示を与える。ブロック５４０において、フィルタ初期化は、フィルタ・グラフ・マネージャに指示を与えてフィルタ・グラフを生成する。ブロック５４２においては、フィルタ・グラフ内の透明化を伴うビデオ・レンダラ・フィルタがロケートされる。フィルタのロケートとは、フィルタの名前に基づいてＩＦｉｌｔｅｒＣＯＭインターフェースの検索を行い、続いてそのフィルタを介してコンフィグレーション・インターフェースを獲得することを意味する。次にブロック５４４において、透明化を伴うビデオ・レンダラ・フィルタ用の初期化パラメータをセットする。たとえば、その後のビデオ・データ信号処理に使用する不透明度の希望レベルをここでセットすることができる。このほかの初期化パラメータとしては、ミラーリングのセッティングおよびインターリーブ・パターンが挙げられる。ブロック５４６においては、フィルタ・グラフ内の色解析フィルタをロケートする。ブロック５４８においては、ビデオ・データ・ストリーム内のピクセルの、色解析フィルタによって追跡される色範囲および対応するアルファ値をセットする。たとえば、親指および残りの指による入力イベントを追跡する実施形態においては、親指および残りの指の色範囲およびアルファ値を、指定範囲内の色値を有するビデオ・データ・ストリーム内のピクセルに対するタグ付けが色解析フィルタによって行われるようにセットすることができる。ブロック５５０においては、フィルタ・グラフ内のブロブ検出フィルタをロケートする。ブロック５５２においては、コントロール・ウインドウの識別名、アルファ値、および対応するコントロール・メッセージをブロブ検出フィルタ内にセットする。ブロック５５４においては、フィルタ・グラフを通るビデオ・データ信号のフローを開始することができる。

ビデオ・データ信号がフィルタ・グラフを通って流れると、ウインドウ・メッセージと呼ばれるイベント通知がハンドル入力イベント５０８によって、ブロブ検出フィルタ５３２から受け取られる。図１３は、本発明の一実施形態に従ったハンドル入力イベントの処理を示したフローチャートである。処理は、ブロック５６０におけるウインドウ・メッセージ・レディの待機から開始する。ウインドウ・メッセージ・レディ・イベントがない場合には、ハンドル入力イベントは、可能性のある入力イベントを受け取るまで待機状態を継続する。ウインドウ・メッセージを受け取ると、それが可能性のある入力イベントであるか否かをさらに判断する。ブロック５６２においては、ウインドウ・メッセージを調べて、ブロブ検出フィルタによってブロブ・タイプ１イベントが検出されているか否かを判断する。一実施形態においては、ブロブ・タイプ１を、たとえば人さし指等の、ビデオ・フレーム内に生じている物理的なアーティファクトに関連付けし、ブロブ・タイプ２を、たとえば親指等の、ビデオ・フレーム内に生じている別の物理的なアーティファクトに関連付けしているが、当業者であれば、各種の物理的なアーティファクトならびにオブジェクトおよびそれらに付随する色を入力インジケータとして、各種の実施形態において使用し得ることを認識されよう。この実施形態においては、明らかに区別可能な２つの色をインジケータとして使用するが、別の実施形態においては、任意数の色を使用することもできる。この実施形態の場合は、ブロブ・タイプ１が検出されたときには、ビデオ・データ・ストリームの現在のビデオ・フレーム内におけるブロブ・タイプ１のサイズならびにロケーションを、ブロック５６４においてタイプ１リストとして示されるデータ構造内に記録する。その後この処理は、可能性のある別の入力イベントを待つ待機を設定する。

ブロック５６２においてブロブ・タイプ１が検出されなかった場合には、ブロック５６６に処理が進み、それにおいてウインドウ・メッセージを調べて、ブロブ検出フィルタ５３２によってブロブ・タイプ２イベントが検出されているか否かを判断する。ブロブ・タイプ２が検出されていれば、ブロック５６８において、ビデオ・データ・ストリームの現在のビデオ・フレーム内におけるブロブ・タイプ２のサイズならびにロケーションをタイプ２リストとして示されるデータ構造内に記録する。その後この処理は、可能性のある別の入力イベントを待つ待機を設定する。ここでブロブ・タイプ２が検出されなかった場合には、処理がブロック５７０に進み、それにおいてウインドウ・メッセージを調べて、ブロブ検出フィルタによってフレーム終了インジケータが検出されているか否かを判断する。フレーム終了インジケータが検出されていれば、ブロック５７２が処理されて、現在のビデオ・フレーム内において有効な入力イベントが検出されているか否かが判断される。ブロック５７２の後は、ブロック５６０に処理が進み、それにおいて別のウインドウ・メッセージを待機する。フレーム終了インジケータを検出したときのブロブ・リスト内には、そのフレームの処理の間に検出されたブロブがストアされている。一実施形態においては、タイプ１およびタイプ２リストが、ビデオ・データ・ストリーム内に表現されている可能性のある２つの異なる物理的オブジェクトの発生をストアしている。別の実施形態においては、任意数のリストを使用し、ビデオ・データ・ストリーム内に表現されている対応する数の物理的オブジェクトを追跡することもできる。

フレーム終了インジケータが検出されなかった場合には、ブロック５７４においてウインドウ・メッセージを調べて、アプリケーション終了メッセージを受け取ったか否かを判断する。アプリケーション終了メッセージを受け取ったときには、ブロック５７６においてフィルタ・グラフを停止し、ブロック５７８においてフィルタ・グラフを削除し、さらにブロック５８０においてアプリケーション・プログラム５０２を終了することができる。アプリケーション終了メッセージを受け取らなかった場合はブロック５６０に進み、それにおいて別のウインドウ・メッセージを待機する。

図１４は、有効な入力イベントを検出するための処理を示したフローチャートである。有効な入力イベントの検出処理の開始時には、完全なビデオ・フレームの処理がフィルタ・グラフによって完了されており、アプリケーション・プログラム５０２は、そのビデオ・フレーム内において発生したブロブについての少なくとも２つのリストを有していることになる。一実施形態においては、これら２つのリストをブロブ・タイプ１およびブロブ・タイプ２とし、それぞれをブロブ色領域の空間を表すリストとする。したがって、有効な入力イベントの検出処理は、ブロブ・リストをサーチして互いの間がもっとも近いブロブのペアを探し出すことからなる。つまり、それぞれのペアについて、互いの近接が選択したスレッショルド距離より近いか否かを調べる。そのようなブロブのペアが存在する場合には、このブロブのペアの検出を有効な入力イベントであると判断する。複数のペアが検出された場合には、もっとも近接しているペアをその後の処理に使用する。ブロック６００においては、有効な入力の検出として、まずブロブ・タイプ１リストのエンドに到達したか否かを判断する。ブロブ・タイプ１リストのエンドに到達していなければ、ブロック６０２を実行し、ブロブ・タイプ２リスト内の、そのビデオ・フレーム内において現在のブロブ・タイプ１にもっとも近いブロブを探し出し、そのもっとも近いブロブ・タイプ２のブロブ・タイプ２リスト内におけるインデクスを、ブロブ・タイプ１リストの現在のエントリに記録する。この実施形態においては、近いということを、ビデオ・フレームの２次元平面における２つのブロブのロケーション間の空間的な距離と定義することができる。ブロック６０４においては、ブロブ・タイプ１リスト内にある次のエントリを次の処理のために選択する。その後、ここで選択した次のブロブ・タイプ１を伴ってブロック６００に戻り、処理を継続する。ブロック６０５においてペアがまったく存在しなければ、ブロブ・タイプ１の現在のエントリに適切なフラグまたはインジケータをセットする。

ブロブ・タイプ１リストのエンドに到達したときには、ブロック６０６を実行して、ブロブ・タイプ１リスト内のもっとも近いブロブ・タイプ１とブロブ・タイプ２のペアを求める。もっとも近いペアがスレッショルド離隔距離より近ければ、ブロック６０８からブロック６１０に進み、検出した入力イベントをコンピュータ・システムのオペレーティング・システム・ソフトウエアに渡す。続いてオペレーティング・システム・ソフトウエアは、この入力イベントを必要に応じて別のアプリケーションに渡すことができる。一実施形態においては、現在のビデオ・フレーム内のブロブのロケーションが、入力イベントをレポートする前にマップされるか、スクリーン座標（たとえば正規化されたマウス座標）に変換される。ブロック６１０において調べたとき、もっとも近いペアがスレッショルド離隔距離より離れている場合には、ブロック６１１を実行して、前述とは別の入力イベントをオペレーティング・システム・ソフトウエアに渡す。次に、ブロック６１２においてタイプ１ブロブ・リストおよびタイプ２ブロブ・リストをリセットする。その後、ブロック６１４において有効な入力イベントを検出する処理を終了する。

ユーザの親指およびその他の指の動きを検出することによって、入力イベントを取り扱う例について説明したが、当業者であれば、異なる色ならびに動きを持った多数の多様な物理的オブジェクトを含むビデオ・データ・ストリームの取り込みおよび解析を使用して入力イベントを表すことが可能であり、また本発明の範囲がここで示した特定の例に限定されないことを理解されよう。さらに、この実施形態においては、ブロブ情報のストアにリストが使用されている。しかしながら、別の実施形態においては、別のデータ構造が使用され、またデータ構造をサーチしてブロブのペアを検出するための別のテクニックが使用されることも考えられる。

図１５は、本発明の一実施形態に従った透明化を伴うビデオ・レンダラの処理スレッドを示したフローチャートである。透明化を伴うビデオ・レンダラの処理は、ブロック７００から開始される。ブロック７０２においては、ビデオ・コントロールＡＰＩオブジェクト（たとえばＤｉｒｅｃｔＤｒａｗ（商標；ダイレクトドロー）オブジェクト）、３つのビデオ・フレーム・バッファ、および２次スレッドを生成する。ブロック７０４においては、透明グラフィックス・フレーム・バッファが存在しないか、それらのうちの１ないしは複数がサイズ変更されているとき、新しい透明グラフィックス・フレーム・バッファを作り、第１の透明グラフィックス・フレーム・バッファを現在アクティブのフレーム・バッファとしてマークする。ブロック７０６においては、現在アクティブの透明グラフィックス・フレーム・バッファに関するグラフィックス・ディスプレイ・インターフェース（ＧＤＩ）の表示コンテキスト（ＤＣ）を生成する。ブロック７０８においては、ビデオ・レンダラがＧＤＩを使用し、ブロック７０６において生成した透明ＤＣ上にビデオ・データ信号を書き込む。続くブロック７１０においては、現在非アクティブになっている透明グラフィックス・フレーム・バッファをアクティブとしてマークし、現在アクティブになっている透明グラフィックス・フレーム・バッファを非アクティブとしてマークする。ブロック７１２においては、透明ＤＣを削除する。ブロック７１４においては、新しく非アクティブとなった透明グラフィックス・フレーム・バッファが色混合およびインターリーブ・オペレーションに使用可能であることを示すようにシステム・イベントをセットする。ブロック７１６においてビデオ・レンダラは、ビデオ・データ・ストリーム内に未処理のビデオ・フレームが残っているか否かを判断する。ビデオ・フレームが残っている場合には、ブロック７０４に戻ってフレームの処理を継続する。未処理のフレームが残っていなければ、ブロック７１８においてフレーム・バッファを破壊する。ブロック７２０においては、２次スレッド（前述のブロック７０２において生成）の終了を待機する。その後、ブロック７２２においてビデオ・レンダラが終了する。

図１６は、本発明の一実施形態に従った透明混合コアの処理スレッドを示したフローチャートである。このスレッドは、図１５に示したブロック７０２において生成される２次スレッドである。２次スレッドは、メインのビデオ・レンダラ処理と独立した処理またはタスクとすることができる。２次スレッドが生成（ブロック７４０）された後、透明ＤＣは、透明グラフィックス・フレーム・バッファが完成するまで待機する。一実施形態においては、透明グラフィックス・フレーム・バッファにおいて色混合および他のデータ信号とのインターリーブの準備が整うと、それが完成する。この２次スレッドが待機するイベントは、図１５に示したブロック７１４のシステム・イベントとすることができる。ブロック７４４においては、オペレーティング・システム出力フレーム・バッファのコンテンツを、両方のワーキング・フレーム・バッファにブロック転送する。ブロック７４６においては、オペレーティング・システム出力フレーム・バッファを不可視、または非アクティブ状態にセットし、ワーキング・フレーム・バッファの一方を可視状態にセットする。これらの２つのオペレーションは、ディスプレイ上にデータ信号を表示するために使用するフレーム・バッファを実質的に「入れ替える」。この時点において、オペレーティング・システム出力フレーム・バッファは、ディスプレイから直接見ることができなくなる。ブロック７４８においては、２次スレッドが、所定時間（たとえば７５ミリ秒）の経過または透明グラフィックス・フレーム・バッファの完成を待機する。

２次スレッドは、所定時間の経過または透明グラフィックス・フレーム・バッファの完成（つまりビデオ・データ信号がロードされる）を待機した後、ブロック７５０において、不可視のワーキング・フレーム・バッファを用いて非アクティブの透明グラフィックス・フレーム・バッファのコンテンツの混合を行う。この混合は、たとえば図８を参照して前述した方法に従ってなし得るが、専用の混合ハードウエアを使用して混合オペレーションを行うこともできる。ブロック７５２において２次スレッドは、２つのワーキング・フレーム・バッファを交代させ、その結果、それまでの可視ワーキング・フレーム・バッファが不可視ワーキング・フレーム・バッファになり、不可視ワーキング・フレーム・バッファが可視ワーキング・フレーム・バッファになる。ブロック７５４においてすべてのフレーム・バッファがまだ存在していると判断される場合は、透明グラフィックス・フレーム・バッファに対して、さらに色混合およびインターリーブ処理を実行するために、ブロック７４８に戻って処理を継続する。いずれかのフレーム・バッファがすでに存在しなくなっている場合には、ブロック７５６を実行して透明表示コンテキストのスレッドを終了する。

フィルタ・グラフの色解析フィルタ５３０の一実施形態における処理を表Ｉに示す。この処理は、２つの入力、すなわちＲＧＢＡフォーマットのビデオのフレーム（続いて色相、彩度および明度（ＨＳＶ）フォーマットに変換される）および、フレーム内に含まれる個別のピクセルの色値の一致に使用するための色値の範囲を受け付ける。ピクセルは、そのピクセルの色相、彩度および明度が指定の色値の範囲にあるとき、一致すると見なされる。色相が直線ではなく円であることから、一致させる色相の範囲は、ラップのない範囲（たとえば２０〜５３）もしくはラップのある範囲（たとえば２４０〜２５５および０〜２０）のいずれにすることもできる。一致させる色の範囲は、ビデオ・カメラ、ビデオ、キャプチャ・ハードウエア、および検出されるオブジェクトの特性に応じて一定とするか、あるいは経験に基づいて決定してもよい（当業者であれば、色の範囲が自動的に決定される自動キャリブレーションについてもここで想定することができよう）。

表Ｉ
著作権：１９９８年Ｉｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎ（インテル・コーポレーション）
色解析
入力：ＲＧＢＡフォーマットのビデオのフレーム；ＨＳＶフォーマットの最小一致ピクセルＲａｎｇｅＭｉｎ；ＨＳＶフォーマットの最大一致ピクセルＲａｎｇｅＭａｘ。Ｐ（Ｈ）は色相を表し、ＲａｎｇｅＭｉｎ（Ｈ）も同様である；Ｐ（Ｓ）は彩度を表し、Ｐ（Ｖ）は明度を表す。
出力：ＨＳＶＡフォーマットのビデオのフレーム
開始
ループ開始：ビデオ・フレーム内のそれぞれのピクセルＰごとに以下の処理を繰り返す
ＲＧＢＡピクセルをＨＳＶＡピクセルに変換
ＩＦ文開始：ＲａｎｇｅＭｉｎ（Ｈ）＜＝ＲａｎｇｅＭａｘ（Ｈ）であれば
／／通常の範囲（たとえば２０〜５３）
ＩＦ文開始：
（ＲａｎｇｅＭｉｎ（Ｈ）＜＝Ｐ（Ｈ））かつ（Ｐ（Ｈ）＜＝ＲａｎｇｅＭａｘ（Ｈ））かつ
（ＲａｎｇｅＭｉｎ（Ｓ）＜＝Ｐ（Ｓ））かつ（Ｐ（Ｓ）＜＝ＲａｎｇｅＭａｘ（Ｓ））かつ
（ＲａｎｇｅＭｉｎ（Ｖ）＜＝Ｐ（Ｖ））かつ（Ｐ（Ｖ）＜＝ＲａｎｇｅＭａｘ（Ｖ））であれば
ピクセルＰはキー・カラーに一致する
ＩＦ文終了
該当しない場合：
／／色相がＲａｎｇｅＭｉｎ（Ｈ）からＲａｎｇｅＭａｘ（Ｈ）を通り、
／／逆側の範囲までラップする場合。たとえば２４０〜２５５および０〜２０
ＩＦ文開始：
（（Ｐ（Ｈ）＜＝ＲａｎｇｅＭａｘ（Ｈ））または（ＲａｎｇｅＭｉｎ（Ｈ）＜＝Ｐ（Ｈ）））かつ
（ＲａｎｇｅＭｉｎ（Ｓ）＜＝Ｐ（Ｓ））かつ（Ｐ（Ｓ）＜＝ＲａｎｇｅＭａｘ（Ｓ））かつ
（ＲａｎｇｅＭｉｎ（Ｖ）＜＝Ｐ（Ｖ））かつ（Ｐ（Ｖ）＜＝ＲａｎｇｅＭａｘ（Ｖ））であれば
ピクセルＰはキー・カラーに一致する
ＩＦ文終了
ループ終了
終了

ブロック検出フィルタの実施例における処理を表ＩＩに示す。この処理は、垂直に移動するごとに、ビデオ・フレーム内のスキャン・ライン内のピクセルを調べて、希望のキー・カラーに一致する「ラン」と呼ばれる水平に連続したピクセルを探し出す。この処理においては、これらのオペレーションを実行するとき、現在のスキャン・ライン上のランに結合する、別のスキャン・ライン（たとえば直前のスキャン・ライン）のランを探し出し、それらを連結する。現在のスキャン・ラインと意味のある結合を持たないランのセットが見つかった場合には、この処理は、そのセットを、希望するキー・カラーに一致した連続ピクセルのブロブとすべきランのセットであると見なす。この処理は、希望の最小寸法と最大寸法の間にあるすべてのブロブを返す。

表ＩＩ
著作権：１９９８年Ｉｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎ（インテル・コーポレーション）
ブロブ検出
開始
ループ開始：ビデオ・フレーム内のそれぞれのスキャン・ラインごとに以下の処理を繰り返す
ループ開始：キー・カラーに一致する水平に連続するピクセルのセットごとに以下の処理を繰り返す
このスキャン・ライン上のこれらのピクセルを表すラン・オブジェクトを生成する
このランを含むブロブ・オブジェクトを生成する
ループ開始：直前のラインの、このランと水平にオーバーラップするそれぞれのランごとに以下の処理を繰り返す
ＩＦ文開始：
そのランのブロブが現在のスキャン・ラインまでまだ延びていない場合
そのランおよびそれのブロブを現在のブロブに組み込む
該当しない場合
ＩＦ文開始：
現在のランがまだブロブに追加されていない場合
そのランを別のランのブロブに組み込む
該当しない場合
ほかのランを無視する
／／すでに、現在のスキャン・ライン上のほかのブロブの一部に
／／なっている
ＩＦ文終了
ＩＦ文終了
ループ終了
ループ終了
ループ終了
／／現在のスキャン・ラインを終了
／／このスキャン・ライン上のランのカタログ作成を完了し、
／／それらを適切なブロブに追加する。
／／次に、ブロブの終わりを調べる。
ループ開始：現在のスキャン・ラインのブロブに組み込まれていない直前のスキャン・ラインのそれぞれのランごとに以下の処理を繰り返す
ＩＦ文開始：
そのランがそのスキャン・ライン上の別のブロブの一部でない場合
ＩＦ文開始：
そのランが「仮終了」としてマークされているか、
あるいは現在のスキャン・ラインがイメージの最後のスキャン・ラインである場合
このランを完成ブロブとしてマークする
ＩＦ文開始：
このブロブが寸法要件を満たす場合
ブロブの特性を示すメッセージを通知する
ＩＦ文終了
該当しない場合
このランを「仮終了」としてマークする
このランを現在のスキャン・ラインのリストに出力する
ＩＦ文終了
ＩＦ文終了
ループ終了
ビデオ・フレームの最終ラインを処理する
フレーム完了メッセージをターゲット・ウインドウに出力する
終了

以上、例示の実施形態を参照して本発明を説明してきたが、この説明は、限定の意味において解釈されることを意図したものではない。例示の実施形態をはじめ本発明のその他の実施形態における、本発明の属する分野の当業者であれば明白であろう各様の修正は、本発明の精神ならびにその範囲に含まれると見なされる。
この発明の実施形態は次の通りである。
実施形態１ ディスプレイを有し、ビデオ・データ信号ソースに接続されるシステムに入力信号を提供する方法であって：
前記ビデオ・ソースによって生成された、シーンを表すビデオ・データ信号を取り込むステップ；
前記シーンが前記ディスプレイ上において透明に見えるようにそのシーンを前記ディスプレイ上にレンダリングするステップ；
前記シーン内のオブジェクトを検出するために前記ビデオ・データ信号を解析するステップ；および、
前記検出したオブジェクトに応答して前記システム用の入力信号を生成するステップ；
を包含することを特徴とする方法。
実施形態２ 前記シーンは、システムのユーザを含み、前記レンダリングしたシーンは、前記ユーザの映したイメージを含むことを特徴とする前記実施形態１記載の方法。
実施形態３ 前記検出したオブジェクトは、少なくとも１つの、前記システムのユーザの身体の一部を含むことを特徴とする前記実施形態１記載の方法。
実施形態４ 前記検出したオブジェクトは、少なくとも１つの、あらかじめ決定した小道具を含むことを特徴とする前記実施形態１記載の方法。
実施形態５ さらに、前記透明にレンダリングしたシーンに加えて、少なくとも１つの表示オブジェクトを前記ディスプレイ上に表示するステップを含むことを特徴とする前記実施形態１記載の方法。
実施形態６ さらに、前記シーン内における前記検出したオブジェクトの動きを、前記少なくとも１つの表示オブジェクトの選択として解釈するステップを含むことを特徴とする前記実施形態５記載の方法。
実施形態７ 前記少なくとも１つの表示オブジェクトはアイコンであることを特徴とする前記実施形態６記載の方法。
実施形態８ 前記ビデオ・データ信号の解析は、前記ビデオ・データ信号のピクセルの色値を解析するステップ、および選択した色値を有するピクセルにタグ付けを行うステップを含むことを特徴とする前記実施形態１記載の方法。
実施形態９ さらに、タグ付けしたピクセルのブロックを、検出したオブジェクトとして識別するステップ、および前記検出したオブジェクトが、あらかじめ決定した入力イベントを表すオブジェクトの評価基準に一致するとき、対応する入力信号を生成するステップを含むことを特徴とする前記実施形態８記載の方法。
実施形態１０ 前記入力信号は、マウスを下げるイベント、マウスを上げるイベント、およびカーソル・ポジションの移動のうちの少なくとも１つであることを特徴とする前記実施形態１記載の方法。
実施形態１１ ビデオ・ソースによって生成された、シーンを表すビデオ・データ信号を取り込むための手段；
前記シーンが前記ディスプレイ上において透明に見えるようにそのシーンをディスプレイ上にレンダリングするための手段；
前記ビデオ・データ信号を解析して前記シーン内のオブジェクトを検出するための手段；および、
前記検出したオブジェクトに応答して前記システム用の入力信号を生成するための手段；
を備えることを特徴とするビデオ・データ・ソースおよびディスプレイを有するシステムの装置。
実施形態１２ さらに、前記透明にレンダリングしたシーンに加えて、少なくとも１つの表示オブジェクトを前記ディスプレイ上に表示するための手段を備えることを特徴とする前記実施形態１１記載の装置。
実施形態１３ 前記生成するための手段は、前記シーン内における前記検出したオブジェクトの動きを、前記少なくとも１つの表示オブジェクトの選択として解釈する手段を備えることを特徴とする前記実施形態１２記載の装置。
実施形態１４ 前記解析するための手段は、前記ビデオ・データ信号のピクセルの色値を解析するための手段、および選択した色値を有するピクセルにタグ付けを行うための手段を備えることを特徴とする前記実施形態１３記載の装置。
実施形態１５ さらに、タグ付けしたピクセルのブロックを、検出したオブジェクトとして識別するための手段、および前記検出したオブジェクトが、あらかじめ決定した入力イベントを表すオブジェクトの評価基準に一致するとき、対応する入力信号を生成するための手段を備えることを特徴とする前記実施形態１４記載の装置。
実施形態１６ ビデオ・ソースによって生成された、シーンを表すビデオ・データ信号を取り込むためのビデオ・キャプチャ回路；
前記シーンが前記ディスプレイ上において透明に見えるようにそのシーンをディスプレイ上にレンダリングするためのビデオ・レンダラ回路；
前記ビデオ・データ信号を解析して前記シーン内のオブジェクトを検出するための色解析回路；および、
前記検出したオブジェクトに応答して前記システム用の入力信号を生成するための入力ハンドラ回路；
を備えることを特徴とするビデオ・データ・ソースおよびディスプレイを有するシステムの装置。
実施形態１７ 複数のマシン可読インストラクションであって、プロセッサによって実行されたとき、システムに、ビデオ・ソースによって生成されたビデオ・データ信号であってシーンを表すビデオ・データ信号を取り込ませ、前記シーンがディスプレイ上において透明に見えるようにそのシーンを前記ディスプレイ上にレンダリングさせ、前記ビデオ・データ信号を解析させて前記シーン内のオブジェクトを検出させ、かつ前記検出したオブジェクトに応答して前記システム用の入力信号を生成させる複数のマシン可読インストラクションを有するマシン可読メディアからなる製品。
実施形態１８ 前記マシン可読メディアはさらに、前記シーンを映したイメージからなるシーンがレンダリングされるように、前記ディスプレイ上に前記シーンのイメージをレンダリングさせるインストラクションを含むことを特徴とする前記実施形態１７記載の製品。
実施形態１９ 前記マシン可読メディアはさらに、前記透明にレンダリングしたシーンに加えて、少なくとも１つの表示オブジェクトを前記ディスプレイ上に表示させるインストラクションを含むことを特徴とする前記実施形態１７記載の製品。
実施形態２０ 前記マシン可読メディアはさらに、前記シーン内における前記検出したオブジェクトの動きを、前記少なくとも１つの表示オブジェクトの選択として解釈させるインストラクションを含むことを特徴とする前記実施形態１９記載の製品。
実施形態２１ 前記マシン可読メディアはさらに、前記ビデオ・データ信号のピクセルの色値を解析させ、選択した色値を有するピクセルにタグ付けを行わせるインストラクションを含むことを特徴とする前記実施形態１７記載の製品。
実施形態２２ 前記マシン可読メディアはさらに、タグ付けしたピクセルのブロックを、検出したオブジェクトとして識別させ、前記検出したオブジェクトが、あらかじめ決定した入力イベントを表すオブジェクトの評価基準に一致するとき、対応する入力信号を生成させるインストラクションを含むことを特徴とする前記実施形態２１記載の製品。
実施形態２３ ビデオ・データ信号ソースおよびディスプレイに接続されたコンピュータ・システム内の、そのコンピュータ・システムに入力データを提供する装置であって：
前記ビデオ・ソースから受け取った、前記ビデオ・ソースによって取り込まれたシーンを表すビデオ・データ信号を処理するフィルタ・グラフであって：
前記シーンが前記ディスプレイ上において透明に見えるようにそのシーンを前記ディスプレイ上にレンダリングするビデオ・レンダラ・フィルタ；
前記ビデオ・データ信号のピクセルの色値を解析して指定範囲内のピクセルの色値にタグ付けする色解析フィルタ；および、
前記色解析フィルタに結合され、ビデオ・データ信号のピクセルの前記タグ付けされた色値を解析し、選択した色値を伴うピクセルのブロックを前記シーン内の検出したオブジェクトとして識別し、可能性のある入力イベントを通知するブロック検出フィルタ；を包含するフィルタ・グラフ；および、
前記通知を解析し、前記検出したオブジェクトが前記コンピュータ・システム用の入力信号を表しているか否かを判断するための入力イベント・ハンドラ；
を備えることを特徴とする装置。
実施形態２４ 前記フィルタ・グラフはさらに、前記ビデオ・ソースからビデオ・データ信号の個別のフレームを取り込むためのビデオ・キャプチャ・フィルタを備えることを特徴とする前記実施形態２３記載の装置。
実施形態２５ 前記フィルタ・グラフはさらに、前記ビデオ・キャプチャ・フィルタに結合され、前記ビデオ・データ信号を少なくとも２つの、一方は前記ビデオ・レンダラ・フィルタに渡されるデータ・ストリームとし、他方は前記色解析フィルタに渡されるデータ・ストリームとする、実質的に類似のデータ・ストリームに分岐するティー・フィルタを備えることを特徴とする前記実施形態２４記載の装置。
実施形態２６ 前記レンダリングされたシーンは、前記シーンを映したイメージからなることを特徴とする前記実施形態２３記載の装置。
実施形態２７ さらに、前記フィルタ・グラフと前記入力イベント・ハンドラの間のメッセージ・ベースのインターフェースを備えることを特徴とする前記実施形態２３記載の装置。

１０：ＯＳ出力用のフレームバッファ
１８：透明表示用のフレームバッファ
２４：色混合コンポーネント
２６：インターリーブ・コンポーネント
２８：ディスプレイ表示用のバッファ

Claims (4)

1. 第１のビデオデータ信号を生成する手段と、
   第２のビデオデータ信号を生成する手段と、
   前記第２のビデオデータ信号による第２のイメージがディスプレイ上において前記第１のビデオデータ信号による第１のイメージの上で透明に見えるように、前記第１、第２のイメージのピクセルをインターリービングしてレンダリングする手段と、
   を含む装置。
2. 請求項１記載の装置において、
   前記レンダリングが、前記第１のイメージの第１のピクセルの色を使用して前記第２のイメージの第２のピクセルの色を調整することを含む装置。
3. 第１のビデオデータ信号を生成する手段と、
   第２のビデオデータ信号を生成する手段と、
   前記第２のビデオデータ信号による第２のイメージがディスプレイ上において前記第１のビデオデータ信号による第１のイメージの上で透明に見えるように、前記第１、第２のイメージのピクセルをインターリービングしてレンダリングする手段と、
   前記第２のイメージ内のオブジェクトを検出するために前記第２のビデオ・データ信号を解析する手段と、
   前記第２のイメージ内で前記オブジェクトを検出したとき、装置のプログラム用の入力イベントを自動的に生成する手段と
   を含む装置。
4. 請求項３記載の装置において、
   前記レンダリングが、前記第１のイメージの第１のピクセルの色を使用して前記第２のイメージの第２のピクセルの色を調整することを含む装置。

Images