JP4782797B2 - ビデオ処理 - Google Patents

Description

本発明は、ビデオデータを処理するための方法及び装置に関し、特に、モバイルビデオデータキャプチャ手段で捕捉されるビデオデータを処理することに関する。

ビデオ会議は、異なる場所にいるが、電子通信を使用して互いを見たり、互いの声を聞いたりすることができる２人以上の人間の間の話し合いである。ビデオ会議を提供する際の１つの目標は、会話の言葉以外の様子をより多く送信することによって会議をさらによくすることである。これらの面に寄与する主要な要因は会議参加者の顔の表情の見え方であることを前提にすると、これらの表情を可能な限り明確に且つ連続的に提示することが望ましい。

モバイルビデオ会議では、ビデオ会議参加者の少なくとも１人が移動通信装置を備えたカメラを使用し、したがってカメラの視界内に留まりながらも動くことができる。

カメラを備える移動通信装置によって捕捉される(captured)ビデオのフレームにおける、ビデオ会議参加者の見え方は、位置、サイズ、向き、照明の方向及び色の変化に左右される。

位置、サイズ及び向きの変化は、参加者とカメラの間の相対的で大局的な動きに起因する。背景除去やフレーム差分等の移動する被写体を検出するための従来の技法は、背景が静止していることを前提としているが、ユーザ自身が移動している場合、この前提はあてはまらないため機能しない。

会議参加者は多くの光源のある環境を通って動き、あるいは移動通信装置の回転を引き起こすので、光が参加者の顔にあたる方向が大きく変化し、及び顔にあたる入射光の変化又は色のついた被写体から反射する光の結果に起因して顔色が大きく変化する。これらは、顔の画像を構成するピクセルの輝度強度と色の、漸次的であるが大きな変化につながる。未処理ビデオデータが、その後「最大ビットレート」の低い要件を満たすために符号化される場合は、これらの変化と顔の表情の明瞭さとのコード化のトレードオフがあり、結果として変化が顔の表情の明瞭さを損なわせる。

さらに、現在の、カメラを備える移動通信装置では、ホワイトバランス補償が画像に適用されることがある。ホワイトバランス補償は、画像の赤、緑、及び青（ＲＧＢ）のチャネルの利得を、該チャネルの総合的な明るさが等しくなるように調整しようとする。この結果、（画像の一部だけを形成する）顔が緑や青に見える場合がある。

本発明の第1の態様よれば、モバイルビデオデータ捕捉手段により捕捉されるビデオデータを処理する方法が提供される。該ビデオデータはフレームデータの組を複数備え、該方法は、
（ａ）前記ビデオの各フレーム内で顔を検出することと、
（ｂ）フレームデータの対応する組を処理し、
（ｉ）前記顔によって占有されている画像の領域を実質的に一定に保ち、
（ｉｉ）前記顔に入射する光の見かけの方向を実質的に一定に保ち、及び／又は
（ｉｉｉ）前記顔の見かけの色を実質的に一定に保つことと、
を備える。

モバイルビデオデータ捕捉手段によって捕捉されるビデオデータのフレーム内で顔を特定し、顔の動き、顔のサイズの変化、顔に入射する光の方向の変化及び顔色の変化を補償するためにフレームデータを変換することによって、フレーム間の顔の見え方の変化を低減し、顔の表情の明瞭さを最大化することが可能である。さらに、照明の方向及び色を調整しない場合には、該特定された顔の領域内におけるポーズをとられた顔の表情に寄与しない変化を送信するために、多くのビットが無駄にされ、このようにしてさらに多くの処理能力を浪費し、及び／又は帯域幅の使用が最適より悪くなるであろう。

用語「色」は、有彩色（色調（光の主波長により決定されるように、赤からすみれ色の範囲で知覚できる色の特性）を有する色）と無彩色（色調を欠いた色、つまり白、灰色、及び黒）の両方を含むことが意図されている。

好ましくは、顔を検出することは、前記顔の１つ以上の特長を特定することを備え、前記顔の１つ以上の特長を特定することは、記憶されている特長テンプレートであって、前記特長テンプレートの各々が顔の特長の画像を備え、サイズが前記領域に対応するものと、前記フレームデータの領域を比較することと、前記フレームデータの領域と前記テンプレートの１つの一致を特定することにより各特長を特定することとを備える。好ましくは、前記特長は前記顔の1組の目を備える。目は、目の形状が異なる角度から見られるときに比較的静的であるため、またテンプレート内に適当な量のコントラストがあるため、テンプレート照合に使用するのに適している。

好ましくは、前記方法は、前記特定された目の組の、それぞれ目の間の距離及び回転角度をチェックすることをさらに備える。このようにして、（目が離れすぎているか、又は目の間の回転角度が大きすぎるために）有効ではない目の組を排除することができる。

好ましくは、前記顔に入射する光の見かけの方向を保つことは、前記フレームデータを低域フィルタリングすることと、前記フレームデータの前記低域フィルタリングされたバージョンを前記フレームデータから減算することと、以前に記憶された基準フレームデータの低域フィルタリングされたバージョンを、前記フレームデータの低域フィルタリングされたバージョンに加算することとを備える。前記以前に記憶された基準フレームデータは無色（ｎｅｕｔｒａｌ）照明の下での前記顔の画像を備える。以前に記憶された基準フレームデータの低域フィルタリングされたバージョンを加算することによって、結果として生じるフレームはさらに自然に見える。

本発明の他の態様は請求項に定められている。

以下、本発明の実施形態が、添付図面に関してここで一例としてのみ説明され、該添付図面において、類似する参照番号が類似する部分を指す。

ここで本発明のいくつかの実施形態で使用されている汎用コンピュータシステムが、図1に関して説明される。他の実施形態が、ハンドヘルド装置、ノートパソコン、メインフレームコンピュータ、ミニコンピュータ、マルチプロセッサシステム、分散システム等を使用することがある。本発明を実現するようにプログラミングされることができる広範囲のハードウェアを考慮すると、本発明の動作は一般的に、プログラムモジュールのような、このコンピュータシステムのコンピュータによって実行されるコンピュータ実行可能命令として後述される。このようなプログラムモジュールには、タスクを実行する又は特定の抽象データ型を実現するプロセス、プログラム、オブジェクト、コンポーネント、データ構造、データ変数等が含まれ得る。分散コンピューティング環境においては複数のコンピュータシステムが通信ネットワークに接続されてもよく、本発明の個々のプログラムモジュールは該複数のコンピュータシステムの間で分散されてもよい。

当分野において一般的に知られている汎用コンピュータシステム（図１）は、コンピュータ処理装置、マザーボード、１つ又は複数のハードディスクドライブ、システムメモリ及びＣＤ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ等のリムーバブル光ディスクから読み取る及び／又はリムーバブル光ディスクに書き込むことができる光ディスクドライブ１１０を含むデスクトップタワー基本装置１００を備えている。さらに、該基本装置１００は、磁気フロッピー（登録商標）ディスクを受け入れ、磁気フロッピーディスクから読み取る及び／又は磁気フロッピーディスクに書き込むことができる磁気フロッピーディスクドライブ１１２も内蔵している。

図１は、例示的なコンピュータシステムを図示しているにすぎず、他の構成のコンピュータシステムも本発明に使用できることが理解されよう。具体的には、該基本装置１００はデスクトップ構成であってもよく、あるいは該コンピュータシステムはラップトップ、ノートブック又はハンドヘルド(handheld)の構成で携帯可能に実現されてもよい。

該コンピュータシステムの内部構成要素は、ランダムアクセスメモリ１２０を備えるシステムメモリ１１８が取り付けられているマザーボードと、読取専用メモリ１３０とを含む。加えて、システムメモリ１１８を含む多様なシステム構成要素を処理装置１５２と結合する、システムバス１４０が設けられている。フロッピーディスクドライブ１１２に差し込まれている任意のフロッピーディスクからデータを読み取り、あるいは該フロッピーディスクにデータを書き込むように該フロッピーディスクドライブ１１２を制御するフロッピーディスクドライブインタフェース１５６と、光ディスクドライブ１１０に差し込まれているリムーバブル光ディスクからデータを読み取り、該リムーバブル光ディスクにデータを書き込むように該光ディスクドライブ１１０を制御する光ドライブインタフェース１６０と、ＩＲポート１１６とブルーツース（商標）ＰＣカード１１８を制御するブルーツース（商標）カードインタフェース１５５とを制御する赤外線（ＩＲ）ポートインタフェース１５３ともまた、該システムバス１４０に結合されている。該ＩＲポート１１６及びブルーツース（商標）ＰＣカード１１８により、該コンピュータシステムは他の同様に有効にされている装置と通信できる。ネットワーク１９０上で該コンピュータシステムが他のコンピュータシステムと通信できるように構成されている、ネットワークカード等の形式のネットワークインタフェース１６２もまた、該システムバス１４０に結合されている。該ネットワーク１９０はローカルエリアネットワーク、広域ネットワーク、ローカル無線ネットワーク等であってもよい。特に、ＩＥＥＥ８０２．１１無線ＬＡＮネットワークは、該コンピュータシステムの移動性を許容するために特に有用である場合がある。該コンピュータシステムは、該ネットワークインタフェース１６２によって、ネットワーク１９０上でプログラム又はデータの交換のためにサーバ、ルータ、又はピアレベルコンピュータ等の他のコンピュータシステムとの論理接続を形成できる。

ネットワークインタフェース１６２に関して、本発明者らは、該ネットワークインタフェース１６２が無線ＬＡＮネットワークカードであることがどのように好ましいかを前述したが、該コンピュータシステムに、シリアルポートインタフェース又はパラレルポートインタフェース（図示しない）に接続され、公衆交換電話網（ＰＳＴＮ）を介して該コンピュータシステムから他のコンピュータへの論理接続を形成するように構成されたモデムが設けられてもよいことも等しく理解されなければならない。

該コンピュータシステムがネットワーク環境で使用される場合、該コンピュータシステム内に局所的に記憶され得るアプリケーションプログラム、他のプログラム及び他のデータは、代わりに、又は、加えてリモートコンピュータにも記憶されることができ、該ネットワーク１９０上で形成されている論理接続により該コンピュータシステムによってアクセスされてもよいこともさらに理解されなければならない。

加えて、システムバス１４０に結合され、ハードディスクドライブ１６８からのデータ又はプログラムの読み取り、及びハードディスクドライブ１６８へのデータ又はプログラムの書き込みを制御するハードディスクドライブインタフェース１６６も提供される。ハードディスクドライブ１６８、光ドライブ１１０とともに使用される光ディスク、又はフロッピーディスク１１２と使用されるフロッピーディスクのすべては、コンピュータが読み取り可能な、命令、データファイル、プログラムモジュール及び該コンピュータシステムのための他のデータの不揮発性記憶を提供する。これらの３つの特定のタイプのコンピュータ読み取り可能記憶媒体が本明細書で説明されてきたが、データを記憶できる他のタイプのコンピュータ読み取り可能媒体、特に磁気カセット、フラッシュメモリカード、テープ記憶ドライブ、デジタル多用途ディスク等が使用され得ることが、意図されている読者によって理解されるであろう。

ハードディスクドライブ１６８、又は任意のフロッピーディスク又は光ディスクのようなコンピュータ読み取り可能記憶媒体の各々は、種々のプログラム、プログラムモジュール又はデータを記憶することができる。特に、本実施形態のハードディスクドライブ１６８は、アプリケーションプログラム１７５、アプリケーションプログラムデータ１７４、コンピュータシステム１又はユーザに必要とされるその他のプログラム１７３、Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｗｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ（登録商標）、Ｕｎｉｘ（登録商標）等のコンピュータシステムのオペレーティングシステム１７２及びその他のユーザデータ１７１も記憶する。該ハードディスクドライブ１６８は、プログラム及びデータが電力を使用せずに恒久的に記憶できるように、前述されたプログラム及びデータの不揮発性記憶装置を提供する。

コンピュータシステムがアプリケーションプログラムを実行するため、あるいはハードディスクドライブ１６８又は他のコンピュータ読み取り可能記憶媒体に記憶されているデータを処理するために、システムメモリ１１８は、ランダムアクセスメモリ１２０を提供し、該ランダムアクセスメモリ１２０は、コンピュータシステムによって必要とされるときに、アプリケーションプログラム、プログラムデータ、その他のプログラム、オペレーティングシステム及びユーザデータのための記憶装置を提供する。これらのプログラム及びデータがランダムアクセスメモリ１２０にロードされるとき、該メモリの特定の部分１２５がアプリケーションプログラムを保持し、別の部分１２４がプログラムデータを保持し、第３の部分１２３が他のプログラムを保持し、第４の部分１２２がオペレーティングシステムを保持し、第５の部分１２１がユーザデータを保持してもよい。多様なプログラム及びデータは、必要に応じて該コンピュータシステムによって該ランダムアクセスメモリ１２０の中に、及び中から移動され得ることが理解されるであろう。さらに詳細には、プログラム又はデータが該コンピュータシステムによって使用されていない場合には、該プログラム又はデータはランダムアクセスメモリ１２０に記憶されず、代わりにハードディスク１６８上の不揮発性記憶装置に返される可能性が高い。

該システムメモリ１１８は、該コンピュータシステム内のシステム要素間で情報を転送するために基本情報及びコマンドを含むバイオス（ＢＩＯＳ）のための記憶装置を提供する読取専用メモリ１３０も提供する。ＢＩＯＳは、多様なシステム要素がどのように互いに通信するのかに関する基本情報を提供し、システムが起動するのを可能にするために、システム起動時に必須である。

本発明の第１の実施形態では、ビデオ通信システムが提供される。該通信システムは、既に説明されたようなコンピュータシステムと、ノキア（登録商標）３６５０携帯電話等の携帯可能なハンドヘルド装置１９９とを含む。

該コンピュータシステムは、電源を入れると、ハードディスク１６８に記憶されているＭｉｃｒｏｓｏｆｔ（登録商標） Ｗｉｎｄｏｗｓ（登録商標） ２０００オペレーティングシステムプログラムを実行する。当業者により理解されるように、該オペレーティングシステムプログラムは、Ｍｉｃｒｏｓｏｆｔ（登録商標） ＤｉｒｅｃｔＳｈｏｗ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）を含むＤｉｒｅｘｔＸ ８．１をサポートする。

装置１９９は、ビデオを捕捉し、国際電気通信連合（ＩＴＵ）Ｈ．２６３規格に従って該ビデオを符号化するカメラを含む。捕捉されたビデオは３ＧＰＰマルチメディアファイル、すなわち、第３世代パートナーシッププロジェクトによって規定されるファイル規格として該モバイル装置１９９に記憶される。装置１９９は、該コンピュータシステムにプレインストールされ、該ハードディスクドライブ１６８に記憶されているソフトウェアを使用して赤外線又はブルーツース（商標）を介してコンピュータシステム１と情報を交換できる。また該コンピュータシステムには、（モバイル装置１９９から受信される）３ＧＰＰマルチメディアファイルを、ＤｉｒｅｃｔＳｈｏｗ ＡＰＩで提供される機能を使用して読み取ることができるＡＶＩファイルに変換するためにアップルコンピュータ社のＱｕｉｃｋＴｉｍｅソフトウェアを利用するｍｏｖ２ａｖｉと呼ばれるフリーウェアツールも記憶されている。

該コンピュータシステムには、ともに、米国カリフォルニア州９５０５２、サンタクララ、ミッションカレッジ通り２２００のインテル（登録商標）社から入手できるＯｐｅｎＣＶソフトウェアライブラリ及び画像処理ライブラリ（ＩＰＬ）もインストールされている。

本実施形態では、画像処理プログラムはＣＤ ＲＯＭで提供され、光ディスクドライブ１１０を使用して該コンピュータシステムにインストールされ、ハードディスクドライブ１６８に記憶されている。プログラムコードはＣ＋＋プログラミング言語で書かれ、コンパイル時及び実行時に、装置１９９の該カメラによって捕捉されたビデオデータを表現するＡＶＩファイルを処理する。

ここで該画像処理プログラムは図３から図８に関連して説明される。以下の説明は、以下の内容を前提とする。つまり（１）ユーザはカメラを見ている。（２）該ユーザの目が両方とも見える。（３）該ユーザの頭部の縦揺れ、横揺れ及び偏揺れが小さい（つまり＜ｃ１０°）、及び（４）該カメラは通常の見える距離（つまり、ｃ１５から５０ｃｍ）に留まっている。ユーザの頭部の縦揺れ、横揺れ、及び偏揺れは図２を参照して定められる。縦揺れは頭部を縦に振ることに関し、横揺れは耳を肩の方に動かすことに関し、偏揺れは頭部を振ることに関する。

該画像処理プログラム（図３）のメインループのための擬似コードが以下に示される。

言い換えると、及び図３を参照すると、該画像処理プログラム３は、未処理の画像データ３００を処理して安定化した出力画像データ７００にすることを含む。未処理画像データ３００は、画像データが該画像処理プログラム３によって処理されていないという意味で未処理であり、捕捉され、３ＧＰＰファイルの形で装置１９９に記憶され、コンピュータシステム１に転送され、ＡＶＩファイルに変換されているビデオフレームデータのセットを備える。その後未処理画像データ３００を形成するフレームを該ＡＶＩファイルから読み取るためにＤｉｒｅｃｔＳｈｏｗ ＡＰＩが使用される。

メインループ内で呼び出されるセットアップ（ｓｅｔｕｐ）関数は、メイン関数（ｍｏｂｉｌｅＦａｃｅＰｒｅｐｒｏｃｅｓｓｏｒ（））内で使用されるいくつかの変数をロードし、初期化するために使用される。該セットアップ関数の中で呼び出される多様な関数が以下でさらに詳細に説明される。

次に、未処理データ３００は３つの段階４００、５００、６００で処理される。該第１の段階は該未処理画像データの各フレーム内の頭部の画像を検出し、位置合わせし（４００）、該第２の段階は該頭部の顔にあたる光の方向を正規化し（５００）、該第３の段階は該画像のカラーバランスを補正する（６００）。該画像処理プログラム（図３）のメイン関数（ｍｏｂｉｌｅＦａｃｅＰｒｅｐｒｏｃｅｓｓｏｒ（））の擬似コード例が以下に示される。

これらの段階のそれぞれが、以下でさらに詳しく説明される。

頭部画像位置合わせ（４００）
ここで図４を参照して、該未処理画像データの各フレームの頭部画像を位置合わせする段階（４００）が説明される。頭部画像を位置合わせすることは、（ｉ）該頭部を追跡すること（４０１）と、（ｉｉ）該頭部がすべてのフレーム（４５０）で同じ場所、向き、及び規模のままとなるように該未処理画像データ３００のアファインワープ（ａｆｆｉｎｅ ｗａｒｐ）（直線状の変形及び回転の組み合わせ）とクロップ（ｃｒｏｐ）を実行することの２つの段階からなる。該頭部画像位置合わせ段階４００の擬似コード例が以下に示される。

ここで該段階のそれぞれがさらに詳しく説明される。

頭部追跡（４０１）
追跡は、複数のフレームにわたり、ユーザの頭部の特定の特長の動きについていく反復プロセスである。代替策は、未処理画像内のすべてのピクセルにわたり、所望される特長の新たな検索を実行することであろう。しかしながら、初期の推定値が与えられると、該推定値の周辺だけ検索すればよいので、使用される計算処理リソースはさらに少なくなるため、追跡の方がよい。本実施形態では、頭部の追跡は、ユーザの目の動きを追跡することにより達成される。チェックされる狭い領域の中に特長を見つけることが不可能な場合には、追跡が失敗する可能性がある。これは、例えば、該特長が塞がれている（例えば該ユーザの手等の何らかの他の物体により隠されている）場合、あるいは該特長がチェックされている領域外に移動する場合（例えば、カメラが突然動くことにより、該特長がフレームを大きく横切る場合）に起こることがある。

本実施形態では、頭部を追跡する方法（４０１）は、以下の擬似コードによって示される。

言い換えると、及び図５を参照すると、該プロセスは、目（４０３）の初期の位置があるかどうか、つまり以前のフレームにおいて目の組の座標が検出されていたかどうかをチェックすることにより開始する。このチェックの結果が肯定的である、つまり目の組の座標が以前のフレームにおいて発見された場合には、該頭部の追跡は可能であり、初期推定値として以前に検出された座標を使用して、カレントフレーム内の該ユーザの目についてローカルサーチ（４０５）が実施される。他方、結果が否定的である場合には、頭部の追跡は失敗し、代わりに未処理画像全体にわたり、該ユーザの目についてグローバルサーチ（４０７）が実施される。該ローカルサーチ（４０５）と該グローバルサーチ（４０７）の両方が、以下でさらに詳しく説明される。

ローカルサーチ４０５
本実施形態では、該ローカルサーチ（４０５）を実行する方法は以下の擬似コードにより示される。

ローカルサーチは、ユーザの左目とユーザの右目の両方について実施され、正規化された相互相関を使用するテンプレート照合によって実行される。

テンプレート照合は、一致を見つけるために未処理画像データ内の領域と、関心のある特長の公知の例を含むテンプレートを比較することを備える。本実施形態では、２つのテンプレートが事前に記憶されている。一方は未処理画像データ内の左目の位置を検出するために使用される、あらかじめ撮影されたユーザの左目の画像であり（ｅｙｅＴｅｍｐｌａｔｅ．ｌｅｆｔ）、他方は未処理画像データの中で右目の位置を検出するために使用される、あらかじめ撮影されたユーザの右目（ｅｙｅＴｅｍｐｌａｔｅ．ｒｉｇｈｔ）の画像である。該２つのテンプレートは、装置１９９で捕捉された静止画像から作成され、その結果、調べられているフレーム内で予想される画像に見え方及びサイズにおいて非常に類似している。正規化された相互相関は、該未処理画像の領域とテンプレートの比較のためのスコアを生成するために使用される数学的な技法である。

記憶されているテンプレートのサイズに基づいて、正方形の形状をした検索範囲が、最初に設定され、次に未処理画像データ内で関心のある領域がＩＰＬソフトウェアライブラリのｃｒｅａｔｅＲＯＩ関数を使用して選択される。この領域は、以前に検出された目の座標から、該検索範囲だけオフセットされている。テンプレート照合は該画像のグレイスケールバージョン（単一の、２次元行列であって、該２次元行列は、場所（ｘ、ｙ）での輝度強度を表す整数、つまり単一チャネル）で実行されるため、該領域は次にＩＰＬソフトウェアライブラリのｃｏｌｏｒＴｏＧｒｅｙ関数を使用してグレイスケールに変換される。（該テンプレートはグレイスケール画像として記憶されてもよいし、あるいは該テンプレートが必要とされるときにグレイスケール画像に変換されてもよい。）次に、ＯｐｅｎＣＶソフトウェアライブラリのｃｖＭａｔｃｈＴｅｍｐｌａｔｅ関数が使用され、該グレイスケール領域全体で該グレイスケールテンプレートの該テンプレート照合及び正規化相互相関が実行される。新しい目の位置（ユーザの左目と右目の座標の組）は、領域内において比較スコアが最高である位置にあると解釈され、該比較スコアはＯｐｅｎＣＶソフトウェアライブラリのｃｖＭｉｎＭａｘＬｏｃ関数を使用して計算される。

ローカルサーチから得られる目の組の座標は、次に、該座標が有効であるかどうかをチェックするために試験される（４０９）。すなわち、左目と右目の相対的な位置が、該左目と右目が遠く離れすぎていない、あるいは近すぎていないこと、及び該左目と右目の間の回転角度が小さいことを確実にするためにチェックされる。本実施形態では、有効組試験（４０９）を実行する方法は、擬似Ｃ＋＋コードによって以下に示される。

本実施形態では、目の組は、右目と左目の間の距離ｅｄが０．１^＊ｉｍａｇｅＷｉｄｔｈ未満である、あるいは０．４^＊ｉｍａｇｅＷｉｄｔｈより大きい場合（ｅｄ及びｉｍａｇｅＷｉｄｔｈ（画像の幅）は共にピクセル単位で測定される）、あるいは頭部の横揺れｅａが０．５より大きい又は−０．５未満である場合（ｅａはラジアンで測定される）に、無効と見なされる。しかしながら、これらの範囲は装置１９９のカメラの視野に応じて変化する。目の組が無効であることが判明する場合には、頭部の追跡は失敗し、未処理画像全体におけるユーザの目のグローバルサーチ（４０７）が代わりに実施される。目の組が有効であることが判明する場合には、目の組の座標４１３のセットが検出されたので、該頭部追跡段階４０１が完了する。

ローカルサーチ４０５の間、目の組の座標に加えて、一連の以前のフレームにわたって観察されるように、以前のフレームについて検出された座標の「速度」を考慮に入れることも可能である。これはローカルサーチ中に目の組の推定される位置を改善する効果を有する。この機能をローカルサーチに加えるためにカルマン(Kalman)フィルタ（プロセスの状態を推定するための効率的な計算手段を提供する数学方程式の組）を使用することができ、本実施形態では、該カルマンフィルタはＯｐｅｎＣＶソフトウェアライブラリのｃｖＫａｌｍａｎＵｐｄａｔｅＢｙＴｉｍｅ関数とｃｖＫａｌｍａｎＵｐｄａｔｅＢｙＭｅａｓｕｒｅｍｅｎｔ関数によって提供される。

グローバルサーチ４０７
本実施形態では、該グローバルサーチ（４０７）を実行する方法が、以下の擬似コードによって示されている。

言い換えると、及び図６を参照すると、プロセスは右目と左目のために実行されるグローバルテンプレート照合（４１９、４２９）（未処理画像データ全体のグレイスケールバージョン上でのグレイスケールテンプレートとの正規化された相互相関）で開始する。上述のように、ＯｐｅｎＣＶソフトウェアライブラリのｃｖＭａｔｃｈＴｅｍｐｌａｔｅ関数が、テンプレート照合及び正規化相互相関を実行するために使用される。場所ごとに相互相関からの結果として生じるスコアは、その特定の場所に目がある推定確率のマップとして見ることができる。

ひいては、右目に対する左目の相対的な位置の知識に基づいて左目の位置を推定し、左目に対する右目の相対的な位置の知識に基づいて右目の位置を推定することも可能である。（グローバルサーチを実行する必要なく頭部追跡が成功するほど、頭部の動きが十分に低速であったときの）装置１９９で捕捉される簡略なビデオトレーニングシーケンスからの統計が、ユーザの左目の位置が、平均的な眼間隔でユーザの右目の位置からオフセットされる配置（ｄｉｓｔｒｉｂｕｔｉｏｎ）を形成することを示した。したがって、（該右目グローバルテンプレート照合４１９から得られる）右目の推定値を、ガウス分布（画像を「不鮮明にさせ」、詳細及び雑音を取り除くために使用される演算子）で畳み込み積分し、オフセットすることによって左目の該位置の確率マップを形成できる。（左目グローバルテンプレート照合４２９から得られる）左目推定値をガウス分布で畳み込み積分し、オフセットすることによって右目の位置の確率マップを形成することも可能である。これは、「ぼかし（ｂｌｕｒ）」関数と「シフト（ｓｈｉｆｔ）」関数によって上記の擬似コードに、及びステップ４２１／４２３及び４３１／４３３によって図６に表されている。本実施形態では、（該トレーニングシーケンスを使用して計算されるような）ｘシフト及びｙシフトは、左目の場合それぞれ−０．１７^＊ＩｍａｇｅＷｉｄｔｈ及び０．００４^＊ＩｍａｇｅＨｅｉｇｈｔであり、右目の場合、０．１７^＊ＩｍａｇｅＷｉｄｔｈ及び−０．００４^＊ＩｍａｇｅＨｅｉｇｈｔである。

本実施形態では、「ｂｌｕｒ」を実行するための方法は、以下の擬似コードで示されている。

ここで、ｃｏｎｖｏｌｖｅＳｅｐ２Ｄ関数は、インテルＩＰＤソフトウェアライブラリによって提供される。ガウスカーネルを設定するために使用され得る関数の擬似コード例が以下に示される。

ガウスカーネルｇａｕｓｓｉａｎＫｅｒｎｅｌｘとｇａｕｓｓｉａｎＫｅｒｎｅｌｙを設定するために、この関数をｓｅｔｕｐ関数の一部として以下のように呼び出すことができる。

本実施形態では、「ｓｈｉｆｔ」（つまり上述したようなオフセット）を実行する方法は、以下の擬似コードによって示される。

ｃｒｅａｔｅＲＯＩ関数は、インテルＩＰＤソフトウェアライブラリによって提供され、ｆｉｌｌＩｍａｇｅ関数とｃｏｐｙＩｍａｇｅ関数はインテルＯｐｅｎＣＶソフトウェアライブラリのｃｖＦｉｌｌｉｍａｇｅ関数とｃｖＣｏｐｙＩｍａｇｅ関数によって提供される。

このように、テンプレート照合（４１９／４２９）、ぼかし（blurring)（４２１／４３１）及びオフセット（４２３／４３３）から、右目の位置について２つの推定が得られ、一方は右目グローバルテンプレート照合によって得られるものであり（上記の擬似コードで「ｍａｔｃｈ．ｒｉｇｈｔ」と呼ばれている）、もう一方は、左目のためのグローバルテンプレート照合をぼかし、オフセットさせること（上記の擬似コードで「ｓｈｉｆｔ．ｌｅｆｔ」と呼ばれている）によって得られるものである。同様に左目の位置に対しても（上記の擬似コードの中で「ｍａｔｃｈ．ｌｅｆｔ」と「ｓｈｉｆｔ．ｒｉｇｈｔ」と呼ばれる）２つの推定値がある。

それぞれの目にとって「最良の」位置とは、テンプレート照合推定値及びオフセットされ、ぼかされたテンプレート照合推定値がともに良好なところである。該２つの推定値は、該２つの推定値を互いにに乗算することによって結合させることができ、これは上記擬似コードにおいては「ｍｕｌｔｉｐｌｙ（乗算）」関数によって、及び図６ではステップ４２５／４３５によって表される。本実施形態では、乗算関数は、ｃ（ｘ，ｙ）＝［ａ（ｘ，ｙ）^＊ｂ（ｘ，ｙ）／２５５］であるような、新しい画像ｃを形成するよう２つの画像ａとｂのピクセル単位の乗算を実行する、インテルＩＰＬソフトウェアライブラリのＭｕｌｔｉｐｌｙ（乗算）関数によって提供される。上記の擬似コードでは、入力画像は「ｍａｔｃｈ」と「ｓｈｉｆｔ」と呼ばれ、出力画像は「ＢｅｓｔＧｕｅｓｓ」と呼ばれている。次に、グローバル最大値の検索（上記の擬似コードにおける「ｌｏｃａｔｅＭａｘｉｍｕｍ」関数及び図６の段階４２７／４３７）が、インテルＯｐｅｎＣＶソフトウェアライブラリのｃｖＭｉｎＭａｘＬｏｃ関数を使用して実行され、目の座標４３９の最良の組を生じさせる。

再び図５を参照すると、グローバルサーチから得られる目の座標の最良の組は、次に最良の組が有効であるかどうかをチェックするために試験される（４１１）。該チェックは、ステップ４０９に関連して前述されたように、ローカルサーチから得られる目の組の座標に対して実行されるチェックに事実上類似している。目の組が有効であると判明すると、目の組の座標４１３の組が検出されたので頭部追跡段階４０１が完了する。しかしながら、該目の組が有効でないと判明すると、頭部追跡は失敗に終わる４１５。この場合、１つのオプションは、データのこのフレームに対しては出力を提供せず、該目の初期位置なしでデータの次のフレームに対して該プロセスを再スタートすることである。これは、さらなるグローバルサーチ４０７が実行されることを確実にするためにステップ４０３で実施される試験の失敗につながる。また、（例えば、カルマンフィルタを使用することによって）該目の前回の既知の位置を基準にして、目の組の座標（４１７）を推定するというオプションもある。

アフィンワープ及びクロップ（４５０）
目の組４１３の座標を取得したので、頭部が全データフレームで同じ位置、向き及び規模に留まるように、該未処理画像３００のアフィンワープ(affine warp)及びクロップ(crop)（４５０）を実行できる。本実施形態では、アフィンワープ及びクロップは、該頭部のｘ、ｙ位置、縮尺及び横揺れの変化に対処するにすぎない。該アフィンワープ及びクロップは、頭部の横揺れと偏揺れの変化、あるいは異なる遠近的な歪み（つまり、顔がカメラに非常に近いとき、顔は短縮されて見える）が異なることに起因する変化には対応しない。しかしながら、ユーザがカメラに視線を合わせ続ける場合には、これらの変化は、小さくなりがちである。

クロップを実行する際の接写の程度を調整できる。さらなる機械処理が目標である場合には、顔の該特長（額から顎）だけの極端な接写が最も安定した画像を提供する。しかしながら、これは見て美しい画像を生じさせない。顔全体を示す、より自然な頭部のショットも可能である。接写の程度は、出力画像における右目の所望される座標、及び該出力画像での所望される目の間の距離を表す変数ｄｅｓｉｒｅｄＲｉｇｈｔＥｙｅＬｏｃａｔｉｏｎとｄｅｓｉｒｅｄＥｙｅＷｉｄｔｈによって制御される。頭部画像を検出するための上記の擬似コードを参照すると、本実施形態では、極端な接写の場合これらの変数はそれぞれ０．６、０．２、及びピクセル単位の極端な接写画像の幅の０．３倍として設定される。接写の場合、該変数は０．４、０．３、及びピクセル単位の接写画像の幅の０．４１倍として設定される。

本実施形態では、アフィンワープ及びクロップを実行する方法（４５０）は、以下の擬似コードによって示されている。

ここで、ｗａｒｐＡｆｆｉｎｅ関数は、インテルＩＰＬソフトウェアライブラリから提供される。

（頭部画像位置合わせ（４００）段階の結果でもある）アフィンワープ及びクロップ（４５０）の結果は、クロップの程度に応じてｃｌｏｓｅｕｐＩｍａｇｅ又はｅｘｔｒｅｍｅＣｌｏｓｅｕｐＩｍａｇｅのどちらかとして記憶される顔（４９０）の位置合わせされた画像である。

これが、頭部画像を位置合わせする段落（４００）を完了する。

光方向正規化（５００）
図７を参照すると、段階４００で検出された該頭部にあたる光方向の正規化プロセス（５００）がここで説明される。

再び画像処理プログラム（図３）のための擬似コード例を参照すると、光方向の正規化が、頭部画像位置合わせ段階４００でのクロップの程度に応じて、ｅｘｔｒｅｍｅＣｌｏｓｅｕｐＩｍａｇｅデータ又はｃｌｏｓｅｕｐＩｍａｇｅデータのどちらかで実施されることが分かる。

本実施形態では、光方向を正規化する方法（５００）が以下の擬似コードによって示されている。

図７を参照すると、光方向の正規化がＹＵＶ色空間内のＹ（輝度）チャネルに含まれる輝度強度情報だけについて実行される。（上記の擬似コードでは、ａｌｉｇｎｅｄＩｍａｇｅと呼ばれ、ｅｘｔｒｅｍｅＣｌｏｓｅｕｐＩｍａｇｅデータ又はｃｌｏｓｅｕｐＩｍａｇｅデータのどちらかを備える）入力画像データはＲＧＢ色空間からＹＵＶ色空間に変換され、（上記のコードの中のｙｕｖ．ｙ変数によって表される）Ｙチャネルが抽出される（５０１）。本実施形態では、これはインテルソフトウェアライブラリのＲＧＢ２ＹＵＶ関数を使用して実行される。

該ユーザの顔全体にあたる光の方向が顔全体で明から暗へのゆっくりとした変化を引き起こすことが仮定される。したがって、光輝度強度の変化の大部分は、画像の低周波に捕捉される。ガウスぼかし（Ｇａｕｓｓｉａｎ ｂｌｕｒｒｉｎｇ）（つまり、ガウス関数との畳み込み積分）は、効果的に画像を低域フィルタリングする（ステップ５０３）。本実施形態では、これはインテルＩＰＬソフトウェアライブラリのｃｏｎｖｏｌｖｅＳｅｐ２Ｄ関数を使用して実施される。前述されたｃｒｅａｔｅＧａｕｓｓｉａｎＫｅｒｎｅｌｓ関数は、ガウスカーネルｌｉｇｈｔＤｉｒＧａｕｓｓｉａｎＫｅｒｎｅｌｘとｌｉｇｈｔＤｉｒＧａｕｓｓｉａｎＫｅｒｎｅｌｙをセットアップするために使用でき、前述されたセットアップ関数の中で以下のように呼び出されるであろう。

このぼかしバージョンをオリジナルから減算すると、高空間周波数だけを含む画像が残る（ステップ５０５）。本実施形態では、これは、ｃ（ｘ，ｙ）＝ａ（ｘ，ｙ）−ｂ（ｘ，ｙ）となるように新しい画像ｃを形成するように２つの画像ａとｂのピクセル単位の減算を実行するインテルＩＰＬソフトウェアライブラリの減算関数を使用して実施される。

この段階で、照明の影響は著しく取り除かれたが、その結果生じる画像はあまり自然には見えないため、無色照明(neutral lighting)（強力な陰影が該顔全体に投げかけられることなく該顔にむらのない外観を与える拡散照明）の下での頭部の画像のガウスぼかし（つまり、低域フィルタリングされた）バージョンを加算することによって何らかの低周波情報を回復する。

本実施形態では、ガウスぼかし画像が、クロップの程度に応じて、無色照明下の頭部の位置合わせされた接写画像又は極端な接写画像のどちらかから作成される。これらの位置合わせされた中間色画像５１７は単一画像ではなく、多くの位置合わせされた画像を合計することにより生じる平均画像であり、光の方向の変化を一様にする効果がある。

位置合わせされた画像データ４９０と同様に、位置合わせされた中間色画像データ５１７は最初にＲＧＢ色空間からＹＵＶ色空間に変換され、Ｙチャネルが抽出される（５１９）。本実施形態では、これはインテルＩＰＬソフトウェアライブラリのＲＧＢ２ＹＵＶ関数を使用して実行される。次に、ガウスぼかし（５２１）が、インテルＩＰＬソフトウェアライブラリのｃｏｎｖｏｌｖｅＳｅｐ２Ｄ関数を使用して抽出されたデータに実施される。位置合わせされた中間色画像の処理のための擬似コードの例は以下に示される。

ぼかされ、位置合わせされた中間色の画像は、クロップの程度ごとに一度だけ作成さればよいため、この関数は前述されたセットアップ関数内で以下のように呼び出される。

次に、ぼかされた中間色の位置合わせされた画像は、減算ステップ（５０５）から出力される画像データに加算される（５０７）。本実施形態では、これは、ｃ（ｘ，ｙ）＝ａ（ｘ，ｙ）＋ｂ（ｘ，ｙ）となるように新しい画像ｃを形成するために２つの画像ａとｂのピクセル単位の加算を実行するインテルＩＰＬソフトウェアライブラリの加算関数を使用して実施される。

結果として生じる画像データは、次にＲＧＢ色空間に変換し直される（５１５）。本実施形態では、これはインテルＩＰＬソフトウェアライブラリのＲＧＢ２ＹＵＶ関数を使用して実行される。

光方向正規化段階（５００）の結果、該クロップの程度に応じて、ｂａｌａｎｃｅｄＥＣＩｍａｇｅ又はｂａｌａｎｃｅｄＣＩｍａｇｅのどちらかとして記憶されるバランスのとれた光方向（５５０）と位置合わせされた顔の画像が生じる。

これで光方向を正規化する段階が完了する（５００）。

カラーバランスの補正（６００）
図８を参照すると、段階５００から出力されたバランスのとれた光方向と、位置合わせされた画像（５５０）のカラーバランスを補正するプロセス（６００）がここで説明される。

本発明の目的のために、用語「色」は、有彩色（「色調」（光の主波長により決定されるように、赤からすみれ色の範囲で知覚できる色の特性）を有する色）と無彩色（色調を欠いた色、つまり白、灰色、及び黒）の両方を含むことが意図されていることが思い出されるであろう。

再び画像処理プログラム（図３）の擬似コード例を参照すると、カラーバランスの補正が、クロップの程度に応じてｂａｌａｎｃｅｄＥＣＩｍａｇｅデータ又はｂａｌａｎｃｅｄＣＩｍａｇｅデータのどちらかで実施されることが分かる。

本実施形態では、カラーバランスを補正する方法（６００）は、以下の擬似コードによって示される。

図８に関連して、カラーバランスの補正はステップ６０１でＲＧＢ画像の各チャネルに対して別々に実施され、ＲＧＢ画像の各チャネル（赤、緑及び青）の平均ピクセル値が計算される。前述された擬似コードでは、これはインテルＯｐｅｎＣＶソフトウェアライブラリのｃｖＭｅａｎ関数に相当するｆｉｎｄＭｅａｎ関数によって表される。無色照明（５１７）の下での頭部の位置合わせされたＲＧＢ画像の各チャネルの平均ピクセル値も計算される（６０５）。位置合わせされた中間色画像の処理のための擬似コードの例が以下に示される。

無色照明（５１７）の下の頭部の位置合わせされたＲＧＢ画像の各チャネルの平均ピクセル値は一度だけ計算すればよい。さらに、平均ピクセル値は顔領域からだけ計算されるため、無色照明の下での頭部の位置合わせされた極端な接写画像が使用される。したがって、この関数は前述されたセットアップ関数の中で以下のように呼び出される。

次に、中間色画像を適合させるために平均Ｒ値、Ｇ値、及びＢ値を調整するピクセルシフトが計算され（６０３）、このシフトは次に各ピクセルに加算される（６０７）。

カラーバランス補正段階（６００）の結果、光方向のバランスがとられ、カラーバランスが補正された顔の位置合わせされた画像、すなわちクロップの程度に応じて顔の接写画像（ｓｔａｂｉｌｉｓｅｄＣＩｍａｇｅ）又は極端な接写画像（ｓｔａｂｉｌｉｓｅｄＥＣＩｍａｇｅ）のどちらかからなる安定した出力画像（７００）が生じる。

これで光方向の正規化の段階が完了する（５００）。

画像処理プログラム（図３）のｍｏｂｉｌｅＦａｃｅＰｒｅｐｒｏｃｅｓｓｏｒ（）関数のビデオデータに対する影響は、場面を通した被写体の大局的な動き、カメラと被写体との間の相対的な動き、あるいは処理後等における自動ホワイトバランス及び露光補償等の特定のカメラパラメータの電子調整により生じるフレーム間のピクセル値の変動を削減することである。被写体の外観のその他の変化は、実質的には被写体の非剛体（ｎｏｎ−ｒｉｇｉｄ）変形（例えば、顔の場合−表情の変化）、及び被写体の表面特性の変化（例えば、顔の場合では、しわ及び紅潮）に起因する。

再び上記の画像処理プログラムのメインループのための擬似コードの例を参照すると、いったん安定した出力画像７００が得られると、該出力画像は何らかの他の関数で使用することができ、これは関数ｄｏＳｏｍｅｔｈｉｎｇによって表されている。

例えば、画像処理プログラム（図３）は、ビデオ会議システムの一部となることがあり、該ビデオ会議システムでは、安定化した出力画像が符号化され、従来のビデオコーデック（例えばＨ．２６４）及びネットワークプロトコル（例えばＲＴＰ、ＴＣＰ）を使用して送信されるであろう。（また、このようなビデオ会議システムにおいて、この種の画像処理が常に必要とされない可能性もある。例えば、人物の状況及び周囲が人物の表情より重要であるときがある場合がある。したがって、このようなビデオ会議システムでは、未処理データの符号化／送信と、安定化した出力データの符号化／送信の間で切り替えることが可能になるであろう。）
代替例では、安定化した出力画像７００が別の人間のユーザに提供されるのではなく、人間への送信の前にさらなる何らかの画像処理を実行するであろう機械に提供される可能性がある。機械が該機械自体顔の表情に関する自動的な理解に到達することも考えられ、これは特定の顔の表情（例えば笑み）のダイナミクスが、例えばコンピュータネットワーク又は安全な場所へのアクセスを可能にするために使用される応用例で有用であろう。

代わりに、カメラが車両のダッシュボード上に取り付けられ、運転者の顔のビデオを捕捉するために使用できるであろう。このシナリオでは、顔全体にあたる光は顔／頭部に対する方向の変化があることに加えて（特に夜に）大きく変化するであろう。安定化した出力画像は、運転者に油断のないこと、したがって車両を安全に制御する能力を監視するために使用できるであろう。

画像処理プログラム（図３）は多くの場合ビデオデータの送信前に実行されるため、前処理と呼ぶことができることが理解される。

上記説明から、本発明から逸脱することなく、多くの修正又は変形が前述された実施形態に加えられてもよいことが明らかであろう。このような修正及び変形は以下を含む。

前述された実施形態では、画像処理プログラムはコンピュータシステム１に記憶され、該コンピュータシステム１上で実行されるが、モバイル装置１９９上に該プログラムを記憶し、該モバイル装置１９９上で実行することも可能である。これにより、リアルタイムの人間−人間の通信が可能になるであろう。このような実施形態では、画像処理プログラムによって実施される処理をモバイル装置と該コンピュータシステムの間で分割することが可能である。処理のいくらかをモバイル装置と、該モバイル装置が接続される基地局の間、あるいはモバイル装置とネットワークに接続される別のコンピュータの間で分割することも可能である。例えば、モバイル装置が、頭部の画像の場所を突き止め、該頭部の画像の位置合わせをするために必要な処理を、光方向の正規化と、カラーバランス調整に必要な処理を実行する該基地局／コンピュータと共に、実行することができるであろう。代わりに、目の組に対するグローバルサーチを、基地局／コンピュータで実行し、結果をモバイル装置に送り返すこともできるであろう。

前述された実施形態では、テンプレート照合はユーザの目のローカルサーチ及びグローバルサーチに使用された。代替実施形態では、テンプレート照合は鼻孔、眉毛等のユーザの顔の他の特長のローカルサーチ及び／又はグローバルサーチに使用できるであろう。

代替実施形態では、テンプレート照合は、ここに説明されるように適応カラーマッチング方法と結合され、あるいは置換されることもできるであろう。顔の初期位置が与えられると、「顔」及び「顔以外」である画像の領域を画定することが可能である。これらの２つの領域から、２つの確率分布、すなわちピクセルが「顔」領域に属する場合にピクセルが色ｃである確率（Ｐ（ピクセルは色ｃである｜ピクセルは顔に属する）と、ピクセルが「顔以外の」領域に属する場合にピクセルが色ｃである確率（Ｐ（ピクセルは色ｃである｜ピクセルは顔の一部ではない））とを計算することができる。新しい画像の場合、ピクセルごとに上記の２つの分布を使用して、ピクセルが色ｃである場合にピクセルが「顔」領域に属する確率（Ｐ（ピクセルは顔に属する|ピクセルは色ｃである）を決定するために、ベイズ定理（Bayes' Theorem)が利用できる。顔に属する確率が高いピクセルの空間分布を調べることにより、新しい画像内での顔の場所を決定することが可能である。

本実施形態では、色はＲＧＢよりむしろＹＵＶとして（又はＨＳＶとしても）最もよく表され、さらに計算量を削減するために、この空間は極めて粗くすることもできるであろう（例えば、Ｙに４ビット、Ｕに４ビット、Ｖに４ビット）。

しかしながら、頭部及びカメラは移動し、照明の変化を引き起こすので、顔の色はもはやこれらの静的な確率分布ではよく表されないであろう。したがって、分布を更新できる。新しい画像の中で該顔の位置を突き止めると、再度「顔」領域と「顔以外の」領域を決定することが可能である。新しい確率分布はこれらの領域のピクセルから計算することができ、ひいては該グローバル分布は移動平均法を使用して更新できる。

例えば、ｐＹＵＶ（ｔ）は、ピクセルが「顔」領域に属する場合に、該ピクセルが色Ｙ、Ｕ、Ｖを有する確率（Ｐ（ピクセルは色Ｙ、Ｕ、Ｖである｜ピクセルは顔である））であり、フレームｔの中の該ピクセルから計算され、ｇｐＹＵＶ（ｔ）は、ピクセルが「顔」領域に属する場合に、該ピクセルが色Ｙ、Ｕ、Ｖを有する移動平均確率（Ｐ（ピクセルは色Ｙ、Ｕ、Ｖである｜ピクセルは顔である））であり、フレームｔの中の該ピクセルから計算される。すなわち、ｇｐＹＵＶ（ｔ＋１）＝ｇｐＹＵＶ（ｔ）^＊（１−ａ）＋ｐＹＵＶ（ｔ）^＊ａであり、ここでａは定数であり小さい（例えば０．１）。

代わりに、「顔」領域及び「顔以外」の領域の確率分布も、ガウス分布によって表すことができ、ガウス分布は平均及び分散によってより簡略に特徴付けることができるため、モバイル装置の実現にさらに適している可能性がある。

顔のサイズ／場所がありそうもないように見える、あるいは顔の色のついたピクセルの分布が粗すぎる場合に顔の軌跡の完全な損失が検出される。このケースでは、顔の位置を突き止めるために再初期化が必要とされるであろう。

顔の向きについてのさらなる情報が必要とされる場合、ローカル特長マッチング（例えば、ローカルサーチ４０５に関連して前述されたような）が顔の位置及び向きに関する決定を微調整するために使用できるであろう。

前述された実施形態では、ガウス分布が目の組のグローバルサーチで使用されたが、他の確率分布を使用できる。例えば、トレーニングシーケンスは、目の相対的な位置の２次元確率分布、つまり左目が（ｘ，ｙ）にあると考えて、右目が位置（ｘ＋ｄｘ，ｙ＋ｄｙ）にあるという確率（ｐ（右目が（ｘ＋ｄｘ，ｙ＋ｄｙ）にある|左目が（ｘ、ｙ）にある））を生成するために使用できる。次にこの２次元分布は、前述されたオフセット／ガウス関数との畳み込み積分の代わりに、テンプレート照合結果に直接的に畳み込み積分するために使用できる。しかしながら、オフセット／ガウス関数との畳み込み積分を使用する利点は、（２次元分布での畳み込み積分のためのｎ^２回の演算と対照的に）ガウス畳み込み積分が２つの１次元の畳み込み積分に分割でき、２ｎのオーダーの回数の演算を含むことができるため処理が高速化するという点である。

該グローバルサーチに関連して前述されたプロセスに対する別の代替策は以下のとおりである。左目テンプレート照合と右目テンプレート照合を前述されたように実行する⇒一致スコアを閾値化する（ｔｈｒｅｓｈｏｌｄ）⇒左目に対するｎ個の場所と右目に対するｍ個の場所を与えるために残りのブロブの図心の位置を突き止める⇒左目／右目の位置のそれぞれの考えられる組（ｎ^＊ｍ個の考えられる組）を比較する⇒ｐ（右目は（ｘ＋ｄｘ，ｙ＋ｄｙ）にある｜左目は（ｘ，ｙ）にある））に基づいてこれらの組のスコアを付ける⇒最高スコアの付いた組として目の組を選ぶ。これは前述された方法よりさらに高速である（したがって、モバイル装置での実現により適している）が、目の正しい場所が閾値段階をパスしないと失敗する。

カラーバランスを補正するための前述された方法は、該方法から出力されるピクセルの色が、該方法に対する入力としての該同じピクセルの色の何らかの関数であることを前提とする。つまり出力色＝Ｆ（入力色）であり、ここで、Ｆは関数であって、その特性が顔の色の測定値及び所望される色の出力分布から導き出される関数である。前述された関数に対する代替の関数は当業者に明らかであろう。

該光方向を正規化するための前述された方法において、低域フィルタリングはガウスフィルタカーネルとの畳み込み積分によって達成されたが、ハニング（Ｈａｎｎｉｎｇ）、カイザー（Ｋａｉｓｅｒ）等の他のフィルタカーネルが使用できるであろう。しかしながら、ガウスカーネルは多くのゆがみを生じさせず、２つの１次元カーネルとして実現でき、高速計算につながるため、特に効果的である。フィルタカーネルと畳み込むことによる空間領域での低域フィルタリングに対する代替策は、２次元高速フーリエ変換（ＦＦＴ）を使用して画像を周波数領域に変換し、高周波を抑制するフィルタカーネルを乗算し、空間領域に戻すために逆ＦＦＴを実行することである。

前述された実施形態では、カラーバランス補正ステップはＲＧＢ色空間で実行されたが、（ＲＧＢとＹＵＶ間の変換は線形変換であるため、ＲＧＢ色空間で実行することに同等である）ＹＵＶ色空間で該カラーバランス補正ステップを実行することも可能である。このような実施形態では、カラーバランス補正ステップは、Ｙチャネルに影響を及ぼさないであろう。加えて、光方向を正規化するステップはＹチャネルだけで実施されるため、ＵチャネルとＶチャネルに影響を及ぼさないことが思い出されるであろう。したがって、光方向の正規化及びカラーバランスの補正のステップがどの順序で実行されるのかは関係ないであろう。

効率という点では、該２つのステップの間でＲＧＢ色空間に変換し直すことなく、ＹＵＶ色空間で両方のステップを実行することが有利であろう。このような実施形態の場合、Ｙチャネルに対するカラー補正は意図的に無視されるであろう。事実上、頭部の位置特定のためのテンプレート照合はグレイスケール画像（Ｙチャネルのみ）で実行されることが思い出されるであろう。結果的に、プロセス全体はＹＵＶ色空間で実行され、（多くのビデオコーダが入力としてＹＵＶデータを受け入れるため）該出力は恐らくＹＵＶ画像となるであろう。しかしながら、クロップアウトされた（ｃｒｏｐｐｅｄ ｏｕｔ）画像の領域についてＵとＶを計算することを必要とするであろうため、このような実施形態での処理の考えられる順序は以下のとおりになるであろう。ＲＧＢを入力する⇒Ｙを検出する⇒ＲＧＢとＹをクロップする⇒クロップされたＲＧＢでＵ、Ｖを検出する⇒ＹＵＶをアファインワープし（ａｆｆｉｎｅ ｗａｒｐ）、拡大縮小する⇒Ｙで光方向を正規化する⇒Ｕ、Ｖのカラーバランスを補正する⇒ＹＵＶを出力する。

前述された実施形態では、安定化した出力画像７００はＲＧＢ画像から成るが、所望される出力が頭部のグレイスケール画像であることも考えられる。このケースでは、未処理画像はまずグレイスケールに変換される（ＲＧＢ色空間からＹＵＶ色空間に変換し、Ｕチャネル及びＶチャネルを廃棄することに同等）ので画像処理ステップは簡略化されるであろう。したがって、ローカルサーチ段階又はグローバルサーチ段階のどちらかで、テンプレート照合のために注目される領域をグレイスケールに変換する必要はなく、光方向を正規化するときにＲＧＢ色空間とＹＵＶ色空間の間で変換する必要はなく、カラーバランスを補正するときに、ただ１つのチャネルを調整するだけである。

前述された実施形態では、画像処理プログラムからの出力は安定化した出力画像であったが、目は頭部の中で固定された位置に留まり、目の平均位置は画像内の頭部の適した位置を与えるため、頭部の位置と縮尺に関する出力情報を提供することもできる。

汎用コンピュータシステムのシステム構成要素のシステムブロック図の説明図である。 ユーザの頭部の移動の方向を示す説明図である。 画像処理方法の動作を描くフローチャートである。 画像処理方法の頭部画像位置合わせ段階の動作を描くフローチャートである。 画像処理方法の頭部画像位置合わせ段階の頭部追跡段階の動作を描くフローチャートである。 画像処理方法の頭部画像位置合わせ段階の頭部追跡段階のグローバルサーチ段階の動作を描くフローチャートである。 画像処理方法の光方向正規化段階の動作を描くフローチャートである。 画像処理方法のカラーバランス段階の動作を描くフローチャートである。

Claims (10)

1. モバイルビデオデータ捕捉手段により捕捉されるビデオデータを処理する方法であって、前記ビデオデータはフレームデータの組を複数備え、前記方法は、
   （ａ）前記ビデオの各フレーム内で顔を検出するステップと、
   （ｂ）フレームデータの対応する組を処理し、
   （ｉ）前記顔によって占有される画像の領域を実質的に一定に保つ、及び／又は、
   （ｉｉ）前記顔の見かけの色を実質的に一定に保つステップと、
   を備え、
   前記ステップ（ｂ）はさらに、
   （ｉｉｉ）（１）前記フレームデータを低域フィルタリングするステップと、
   （２）前記フレームデータから、前記フレームデータの低域フィルタリングされたバージョンを減算するステップと、
   （３）前記フレームデータの低域フィルタリングされたバージョンに、以前に記憶された基準フレームデータであって、無色照明の下での前記顔の画像を備える前記以前に記憶された基準データフレームの低域フィルタリングされたバージョンを加算するステップとによって、前記顔に当たっている光の見かけの方向を保つステップと、
   を備える方法。
2. 顔を検出するステップは、前記顔の１つ以上の特長を特定するステップを備える、請求項１に記載の方法。
3. １つ以上の特長を特定するステップは、
   記憶されている特長テンプレートと前記フレームデータの領域を比較するステップであって、前記特長テンプレートのそれぞれは顔の特長の画像を備え、かつ前記領域にサイズが対応している、ステップと、
   前記フレームデータの領域と前記テンプレートの１つとの間の一致を特定することにより各特長を特定するステップと、
   を備える、請求項２に記載の方法。
4. 領域を比較するステップは、領域内の各ピクセルをテンプレート内の該ピクセルに対応するピクセルと比較するステップを備え、前記方法はさらに、
   領域内のピクセルと、記憶されている目のテンプレート内の該ピクセルに対応するピクセルとの比較のそれぞれにスコアを生成するステップと、
   最大スコアを有するピクセルを選択することにより特長を特定するステップと、
   を備える、請求項３に記載の方法。
5. フレームデータを低域フィルタリングするステップは、前記フレームデータを所定のフィルタカーネルと畳み込み積分することにより達成される、請求項１に記載の方法。
6. 前記顔の見かけの色を実質的に一定に保つステップは、各カラーチャネルの相対的なオフセット及び絶対値を実質的に一定に保つために、前記フレームデータの各カラーチャネルを個別に調整するステップを備える、請求項１乃至請求項５のいずれか１項に記載の方法。
7. 前記フレームデータの各カラーチャネルの平均ピクセル値を、所定のシフト量だけ、シフトするステップをさらに備える、請求項６に記載の方法。
8. 選択されたカラーチャネルについて、前記シフト量が、前記フレームデータ内の前記選択されたチャネルの平均ピクセル値と、無色照明の下での前記顔の画像を備える以前に記憶された基準フレームデータ内の前記選択されたチャネルの平均ピクセル値との差異に対応する、請求項７に記載の方法。
9. 請求項１乃至請求項８のいずれか１項に記載されている方法ステップを実行するために処理装置によって実行可能な命令のプログラムを保持するデジタルデータキャリヤ。
10. モバイルビデオデータ捕捉手段によって捕捉されるビデオデータを処理するために処理可能なプロセッサ読み取り可能コードが記録されている記憶媒体を備える装置であって、前記ビデオデータがフレームデータの組を複数備え、前記コードが、
    前記ビデオの各フレーム内で顔を特定するために処理可能な特定コードと、
    フレームデータの対応する組を処理し、
    （ｉ）前記顔により占有される画像の領域を実質的に一定に保つ、及び／又は、
    （ｉｉ）前記顔の見かけの色を実質的に一定に保つ、ために処理可能なフレームデータ処理コードと、
    を備え、
    前記フレームデータ処理コードはさらに、
    （ｉｉｉ）（ａ）前記フレームデータを低域フィルタリングするステップと、
    （ｂ）前記フレームデータから、前記フレームデータの低域フィルタリングされたバージョンを減算するステップと、
    （ｃ）前記フレームデータの低域フィルタリングされたバージョンに、以前に記憶された基準フレームデータであって、無色照明の下での前記顔の画像を備える前記以前に記憶された基準データフレームの低域フィルタリングされたバージョンを加算するステップとによって、前記顔に当たっている光の見かけの方向を保つステップとを実行するコードを含んでいる、装置。

Images