JP2017518663A - 立体ビューイング - Google Patents

Abstract

本発明は、立体画像例えば、３Ｄ映像とも呼ばれる立体映像画像の作成およびビューイングに関する。シーンの一エリアが少なくとも３台のカメラによりカバーされるような形で、重複する視野を伴う少なくとも３台のカメラ・ソースが、シーンをキャプチャするために使用される。ビューワにおいて、カメラ・ソースの場所に位置設定された場合のユーザーの眼のロケーションに最も適合する立体カメラ・ペアを作成するため、多数のカメラの中から１つのカメラ・ペアが選択される。すなわち、カメラ・ソースにより作成される視差が、ユーザーの眼がその位置で有すると考えられる視差に似るような形でカメラ・ペアが選択される。ユーザーが頭を傾けた場合、またはビュー向きが他の形で改変された場合、例えばもう一方のカメラを切換えることによって、新しい対を形成することができる。このときビューワ・デバイスは、臨場感のある立体視差のため各画像の各エリアについて最高のソースをピックアップすることにより、左右の眼についての映像フレームの画像を形成する。

Description

静止画および動画のデジタル立体ビューイングは、すでに当たり前のことになっており、３Ｄ（３次元）ビューイングのための機器はさらに広く利用可能である。映画館は、映画の各フレームについて左右の眼に対して異なる画像のビューイングを保証する特殊なメガネを用いた映画のビューイングに基づく３Ｄ映画を提供している。同じアプローチは、３Ｄ能力のあるプレーヤーおよびテレビセットによる家庭内使用にも持ち込まれてきた。実際には、映画は、同じシーンに対して、左眼用と右眼用に１つずつ２つのビューで構成されている。これらのビューは、立体ビューイングに好適であるこのコンテンツを直接作成する特殊な立体カメラを用いて映画をキャプチャすることによって作成されてきた。ビューが２つの眼に提示される場合、人間の視覚系はそのシーンの３Ｄビューを作成する。この技術には、ビューイング・エリア（映画スクリーンまたはテレビ）が、視野の一部しか占有せず、したがって３Ｄビュー体験が限定されるという欠点がある。

より臨場感のある体験を得るために、全視野のより大きなエリアを占有するデバイスが作成された。小さなスクリーンおよびレンズ配置で眼を覆い左右の眼のためのピクチャを表示するような形で頭部に着用されるように意図された特殊な立体ビューイング・ゴーグルが、利用可能である。このような技術には同様に、３Ｄビューイングのために一般に使用されるかなり大型のＴＶセットに比べ、狭い空間内で、さらには移動しながらでも使用できるという利点もある。ゲーム用には、このような立体メガネと適合性を有し、人工的ゲームの世界の立体ビューイングに必要とされる２つの画像を作成してゲームシーンの内部モデルの３Ｄビューを作成することのできるゲームが存在する。モデルから異なるピクチャが実時間でレンダリングされ、したがってこのアプローチには、特にゲームのシーンモデルが複雑で極めて精細であり、多くのオブジェクトを格納している場合に高い計算能力が求められる。

したがって、立体ビューイング、すなわち３Ｄ画像のビューイングを可能にするソリューションに対する必要性が存在する。

ここに、上述の課題を軽減することのできる改良された方法およびこの方法を実現する技術的機器が発明された。本発明のさまざまな態様には、独立クレームに記載されていることを特徴とする、方法、カメラ装置、サーバー、クライアントレンダラー、および内部に記憶されたコンピュータ・プログラムを含むコンピュータ可読媒体が含まれる。本発明のさまざまな実施形態が、従属クレーム中で開示されている。

本発明は、立体画像、例えば３Ｄ映像とも呼ばれる立体映像画像の作成およびビューイングに関する。シーンの１エリアが少なくとも３台のカメラによりカバーされるような形で、重複する視野を伴う少なくとも３台のカメラ・ソースが、シーンをキャプチャするために使用される。ビューワにおいて、カメラ・ソースのロケーションに位置設定された場合のユーザーの眼の位置に最も適合する立体カメラ・ペアを作成するため、多数のカメラの中から１つのカメラ・ペアが選択される。すなわち、カメラ・ソースにより作成される視差が、ユーザーの眼がその位置で有すると考えられる視差に似るような形で、カメラ・ペアが選択される。ユーザーが頭を傾けた場合、またはビュー向きが他の形で改変された場合、例えばもう一方のカメラに切換えることによって新しい対を形成することができる。このときビューワ・デバイスは、臨場感のある立体視差のため各画像の各エリアについて最高のソースをピックアップすることにより、左右の眼についての映像フレームの画像を形成する。

第１の頭部向きを得るためにユーザーの頭部向きを決定するステップと、前記第１の頭部向きに基づいて、立体画像ソースを形成する第１の画像ソースと第２の画像ソースを選択するステップと、前記第１の画像ソースを用いてユーザーの一方の眼についての第１の標的画像を、そして前記第２の画像ソースを用いてユーザーの他方の眼についての第２の標的画像をレンダリングすることによって第1の立体画像をレンダリングするステップと、第２の頭部向きを得るために前記ユーザーの頭部向きを決定するステップと、前記第２の頭部向きに基づいて、立体画像ソースを形成する前記第２の画像ソースと第３の画像ソースを選択するステップと、前記第２の画像ソースを用いてユーザーの一方の眼についての第３の標的画像を、そして前記第３の画像ソースを用いてユーザーの他方の眼についての第４の標的画像をレンダリングすることによって第２の立体画像をレンダリングするステップと、を含む方法が提供されている。

シーンの立体映像シーケンスを形成するためにユーザーの頭部向きを決定するステップと、前記頭部向きに基づいて第１の画像ソース、第２の画像ソースおよび第３の画像ソースを選択するステップと、前記第１の画像ソースおよび前記第２の画像ソースを用いてユーザーの左眼についての画像シーケンスを、そして、前記第１の画像ソースおよび前記第３の画像ソースを用いてユーザーの右眼についての画像シーケンスをレンダリングすることによって前記立体映像シーケンスをレンダリングするステップであって、前記第１の画像ソースが、前記映像シーケンスの各立体フレーム内のユーザーの左眼および右眼についての前記シーンの異なるエリアをレンダリングするために使用されるステップと、を含む方法が提供されている。

立体ビューイングのために複数のソース映像信号をエンコードするステップであって、前記ソース映像信号が複数のカメラ・ソースからの映像データを含み、前記ソース映像信号が能動シーン・エリア信号および受動シーン・エリア信号を含んでいるステップと、ビューイングのために立体ビューイング・デバイスに対して前記複数のソース映像信号を伝送するステップと、伝送されたソース映像信号内で前記能動シーン・エリア信号が前記受動シーン・エリア信号よりも高い忠実度でエンコードされているように、前記エンコーディングおよび伝送のうちの少なくとも１つを行なうステップであって、前記能動および受動シーン・エリア信号は、前記能動シーン・エリア信号がユーザーによりビューイングされているシーン・エリアに対応し、前記受動シーン・エリア信号が他のシーン・エリアに対応するような形でユーザーの頭部向きに対応しているステップと、を含む方法が提供されている。

少なくとも３台のカメラのうちの任意のカメラ・ペアが、視差を有する立体画像を作成するために視差を有するような形で互いとの関係において位置設定されている、規則的または不規則なセッティング内の少なくとも３台のカメラを含み、前記少なくとも３台のカメラは、全ての部分が前記少なくとも３台のカメラによってキャプチャされるオーバーラップ領域が画定されるような形で、重複する視野を有している、立体ビューイング画像データを作成するためのカメラ・デバイスが提供されている。このカメラ・デバイスは、前記少なくとも３台のカメラの任意のカメラ・ペアが、立体画像を作成するために人間の眼のパララックスに対応するパララックスを有するようなものであり得る。このカメラ・デバイスは、少なくとも３台のカメラが、本質的に仮想立方体の隅に位置付けされ、各々本質的に仮想立方体の中心点から隅に向う光学軸方向を規則的に有する８台の広視野カメラを含み、ここで、前記広視野カメラ各々の視野が少なくとも１８０度であって、このため全球ビューの各部分が少なくとも４台のカメラによってカバーされるようになっているようなものであり得る。

少なくとも１つのプロセッサ、コンピュータ・プログラム・コードを含む装置において、メモリおよびコンピュータ・プログラム・コードが、少なくとも１つのプロセッサを用いて装置に、少なくとも、第１の頭部向きを得るためにユーザーの頭部向きを決定させ、前記第１の頭部向きに基づいて、立体画像を形成する第１の画像ソースと第２の画像ソースを選択させ、前記第１の画像ソースを用いてユーザーの一方の眼についての第１の標的画像を、そして前記第２の画像ソースを用いてユーザーの他方の眼についての第２の標的画像をレンダリングすることによって第1の立体画像をレンダリングさせ、第２の頭部向きを得るために前記ユーザーの頭部向きを決定させ、前記第２の頭部向きに基づいて、立体画像を形成する第２の画像ソースと第３の画像ソースを選択させ、前記第２の画像ソースを用いてユーザーの一方の眼についての第３の標的画像を、そして前記第３の画像ソースを用いてユーザーの他方の眼についての第４の標的画像をレンダリングすることによって第２の立体画像をレンダリングさせるように構成されている装置が提供されている。

少なくとも１つのプロセッサ、コンピュータ・プログラム・コードを含むメモリを含む装置において、メモリおよびコンピュータ・プログラム・コードが、少なくとも1つのプロセッサを用いて、装置に、少なくともシーンの立体映像シーケンスを形成するためにユーザーの頭部向きを決定させ、前記頭部向きに基づいて第１の画像ソース、第２の画像ソースおよび第３の画像ソースを選択させ、前記第１の画像ソースおよび前記第２の画像ソースを用いてユーザーの左眼についての画像シーケンスを、そして、前記第１の画像ソースおよび前記第３の画像ソースを用いてユーザーの右眼についての画像シーケンスをレンダリングすることによって前記立体映像シーケンスをレンダリングさせる、ここで、前記第１の画像ソースは、前記映像シーケンスの各立体フレーム内のユーザーの左眼および右眼についての前記シーンの異なるエリアをレンダリングするために使用される、ように構成されている装置が提供されている。

少なくとも１つのプロセッサ、コンピュータ・プログラム・コードを含むメモリを含む装置において、メモリおよびコンピュータ・プログラム・コードが、少なくとも1つのプロセッサを用いて、装置に、少なくとも立体ビューイングのために複数のソース映像信号をエンコードさせ、ここで、前記ソース映像信号は複数のカメラ・ソースからの映像データを含み、前記ソース映像信号は能動シーン・エリア信号および受動シーン・エリア信号を含んでいる、ビューイングのために立体ビューイング・デバイスに対して前記複数のソース映像信号を伝送させ、伝送されたソース映像信号内で前記能動シーン・エリア信号が前記受動シーン・エリア信号よりも高い忠実度でエンコードされているように、前記エンコーディングおよび伝送のうちの少なくとも１つを行なわせる、ここで、前記能動および受動シーン・エリア信号は、前記能動シーン・エリア信号はユーザーによりビューイングされているシーン・エリアに対応し、前記受動シーン・エリア信号は他のシーン・エリアに対応するような形でユーザーの頭部向きに対応している、ためのコンピュータ・プログラム・コードを含む装置が提供されている。

少なくとも１つのプロセッサ、コンピュータ・プログラム・コードを含むメモリを含むシステムにおいて、メモリおよびコンピュータ・プログラム・コードが、少なくとも1つのプロセッサを用いて、装置に、少なくとも第１の頭部向きを得るためにユーザーの頭部向きを決定させ、前記第１の頭部向きに基づいて、立体画像を形成する第１の画像ソースと第２の画像ソースを選択させ、前記第１の画像ソースを用いてユーザーの一方の眼についての第１の標的画像を、そして前記第２の画像ソースを用いてユーザーの他方の眼についての第２の標的画像をレンダリングすることによって第1の立体画像をレンダリングさせ、第２の頭部向きを得るために前記ユーザーの頭部向きを決定させ、前記第２の頭部向きに基づいて、立体画像を形成する前記第２の画像ソースと第３の画像ソースを選択させ、前記第２の画像ソースを用いてユーザーの一方の眼についての第３の標的画像を、そして前記第３の画像ソースを用いてユーザーの他方の眼についての第４の標的画像をレンダリングすることによって第２の立体画像をレンダリングさせる、ように構成されているシステムが提供されている。

非一時的コンピュータ可読媒体上で実施されたコンピュータ・プログラム製品において、少なくとも１つのプロセッサ上で実行された場合に、装置またはシステムに、第１の頭部向きを得るためにユーザーの頭部向きを決定させ、前記第１の頭部向きに基づいて、立体画像を形成する第１の画像ソースと第２の画像ソースを選択させ、前記第１の画像ソースを用いてユーザーの一方の眼についての第１の標的画像を、そして前記第２の画像ソースを用いてユーザーの他方の眼についての第２の標的画像をレンダリングすることによって第1の立体画像をレンダリングさせ、第２の頭部向きを得るために前記ユーザーの頭部向きを決定させ、前記第２の頭部向きに基づいて、立体画像ソースを形成する前記第２の画像ソースと第３の画像ソースを選択させ、前記第２の画像ソースを用いてユーザーの一方の眼についての第３の標的画像を、そして前記第３の画像ソースを用いてユーザーの他方の眼についての第４の標的画像をレンダリングすることによって第２の立体画像をレンダリングさせる、ように構成されたコンピュータ・プログラム製品が提供されている。

第１の頭部向きを得るためにユーザーの頭部向きを決定するための手段と、前記第１の頭部向きに基づいて、立体画像ソースを形成する第１の画像ソースと第２の画像ソースを選択するための手段と、前記第１の画像ソースを用いてユーザーの一方の眼についての第１の標的画像を、そして前記第２の画像ソースを用いてユーザーの他方の眼についての第２の標的画像をレンダリングすることによって第1の立体画像をレンダリングするための手段と、第２の頭部向きを得るために前記ユーザーの頭部向きを決定するための手段と、前記第２の頭部向きに基づいて、立体画像ソースを形成する前記第２の画像ソースと第３の画像ソースを選択する手段と、前記第２の画像ソースを用いてユーザーの一方の眼についての第３の標的画像を、そして前記第３の画像ソースを用いてユーザーの他方の眼についての第４の標的画像をレンダリングすることによって第２の立体画像をレンダリングするための手段と、を含む装置が提供されている。

第１の頭部向きを得るためにユーザーの頭部向きを決定するステップと、前記第１の頭部向きに基づいて、立体画像ソースを形成する第１の画像ソースと第２の画像ソースを選択するステップと、前記第１の画像ソースを用いてユーザーの一方の眼についての第１の標的画像を、そして前記第２の画像ソースを用いてユーザーの他方の眼についての第２の標的画像をレンダリングすることによって第1の立体画像をレンダリングするステップと、第２の頭部向きを得るために前記ユーザーの頭部向きを決定するステップと、前記第２の頭部向きに基づいて、立体画像ソースを形成する前記第２の画像ソースと第３の画像ソースを選択するステップと、前記第２の画像ソースを用いてユーザーの一方の眼についての第３の標的画像を、そして前記第３の画像ソースを用いてユーザーの他方の眼についての第４の標的画像をレンダリングすることによって第２の立体画像をレンダリングするステップと、前記第１の画像ソースを使用して形成された前記画像および前記第３の画像ソースを用いた前記画像からの時間的遷移をブレンディングするステップ、を含む方法が提供されている。この方法は、頭部運動速度に関する情報を使用することによって時間的遷移ブレンディングの持続時間を調整するステップを含み得る。

第１の頭部向きを得るためにユーザーの頭部向きを決定するステップと、前記第１の頭部向きに基づいて、立体画像ソースを形成する第１の画像ソースと第２の画像ソースを選択するステップと、前記第１の画像ソースを用いてユーザーの一方の眼についての第１の標的画像を、そして前記第２の画像ソースを用いてユーザーの他方の眼についての第２の標的画像をレンダリングすることによって第1の立体画像をレンダリングするステップと、第２の頭部向きを得るために前記ユーザーの頭部向きを決定するステップと、前記第２の頭部向きに基づいて、立体画像ソースを形成する前記第２の画像ソースと第３の画像ソースを選択するステップと、前記第２の画像ソースを用いてユーザーの一方の眼についての第３の標的画像を、そして前記第３の画像ソースを用いてユーザーの他方の眼についての第４の標的画像をレンダリングすることによって第２の立体画像をレンダリングするステップと、前記画像ソースについてのソース向き情報を決定するステップと、前記画像ソースを選択するために前記頭部向き情報と併せて前記ソース向き情報を使用するステップとを含む方法が提供されている。

第１の頭部向きを得るためにユーザーの頭部向きを決定するステップと、前記第１の頭部向きに基づいて、立体画像ソースを形成する第１の画像ソースと第２の画像ソースを選択するステップと、前記第１の画像ソースを用いてユーザーの一方の眼についての第１の標的画像を、そして前記第２の画像ソースを用いてユーザーの他方の眼についての第２の標的画像をレンダリングすることによって第1の立体画像をレンダリングするステップと、第２の頭部向きを得るために前記ユーザーの頭部向きを決定するステップと、前記第２の頭部向きに基づいて、立体画像ソースを形成する前記第２の画像ソースと第３の画像ソースを選択するステップと、前記第２の画像ソースを用いてユーザーの一方の眼についての第３の標的画像を、そして前記第３の画像ソースを用いてユーザーの他方の眼についての第４の標的画像をレンダリングすることによって第２の立体画像をレンダリングするステップと、前記第１、第２および第３の画像ソースのためのレンダリングされた剛性画像を生成するために仮想カメラを用いてコンピュータ・デバイスの出力として前記第１、第２および第３の画像ソースを形成するステップと、を含む方法が提供されている。

以下では本発明のさまざまな実施形態について、添付図面を参照しながら、より詳細に説明する。

ユーザーに対し立体画像を形成するためのセットアップを示す。 ユーザーに対し立体画像を形成するためのセットアップを示す。 ユーザーに対し立体画像を形成するためのセットアップを示す。 ユーザーに対し立体画像を形成するためのセットアップを示す。 立体ビューイングのためのシステムおよび装置を示す。 立体ビューイングのための立体カメラ・デバイスを示す。 立体ビューイングのためのヘッドマウント・ディスプレーを示す。 カメラ・デバイスを例示する。 画像ソースからの第１および第２の眼のための立体画像の形成を例示する。 画像ソースからの第１および第２の眼のための立体画像の形成を例示する。 画像ソースからの第１および第２の眼のための立体画像の形成を例示する。 頭部向きが変化している場合の立体画像の作成のための画像ソースの選択を例示する。 頭部向きが変化している場合の立体画像の作成のための画像ソースの選択を例示する。 頭部向きが変化している場合の立体画像の作成のための画像ソースの選択を例示する。 頭部向きが変化している場合の立体画像の作成のための画像ソースの選択を例示する。 頭部向きが変化している場合の立体画像の作成のための画像ソースの選択を例示する。 画像ソースとして使用されるためのカメラ・デバイスの一例を示す。 画像ソースとして使用されるためのカメラ・デバイスの一例を示す。 音響ソースとして使用されるためのマイクロホン・デバイスの一例を示す。 立体ビューイングのためのソースおよびデスティネーション座標系の使用を示す。 立体ビューイングのためのソースおよびデスティネーション座標系の使用を示す。 立体ビューイングのためのソースおよびデスティネーション座標系の使用を示す。 立体ビューイングのためのソースおよびデスティネーション座標系の使用を示す。 立体ビューイングのための画像ソース・データの伝送を例示する。 立体ビューイングのための画像ソース・データの伝送を例示する。 立体ビューイングのための画像を作成するための仮想現実モデル内の合成画像ソースの使用を例示する。 立体ビューイングのための画像を形成する方法の流れ図を示す。 立体ビューイングのための画像を伝送する方法の流れ図を示す。

以下では、本発明の複数の実施形態が、３Ｄメガネを用いた立体ビューイングとの関連で説明される。ただし、本発明が任意の特定のディスプレー技術に限定されないという点に留意すべきである。実際、異なる実施形態が、例えば映画およびテレビなど、立体ビューイングが必要とされているあらゆる環境における利用分野を有している。さらに、本明細書では、画像ソースの一例として一定のカメラ・セットアップが使用されているものの、異なるカメラ・セットアップおよび画像ソースの配置を使用することができる。

図１ａ、１ｂ、１ｃおよび１ｄは、ユーザーに対して立体画像を形成するためのセットアップを示す。図１ａにおいては、人間が両方の眼Ｅ１およびＥ２を用いて２つの球Ａ１およびＡ２をビューイングしている状況が示されている。球Ａ１は、球Ａ２に比べてビューワに近く、第１の眼Ｅ１までのそれぞれの距離はＬ_E1、A1およびＬ_E1、A2である。異なるオブジェクトは、空間内で、座標系ＳＺ、ＳＹおよびＳＺによって定義されるそれぞれの（ｘ、ｙ、ｚ）座標に存在する。人間の両眼の間の距離ｄ₁₂は、平均しておよそ６２〜６４ｍｍで、人によって５５〜７４ｍｍの間で変動し得る。この距離は、パララックスと呼ばれ、人間の視覚の立体的ビューは、これに基づいている。ビューイング方向（光学軸）ＤＩＲ１およびＤＩＲ２は典型的には本質的に平行であり、場合によって、平行状態からわずかな偏差を有し、眼の視野を画定する。ユーザーの頭は、周囲環境との関係における向き（頭部向き）を有し、これは眼が真直ぐ前を見ている場合の眼の共通の方向により最も容易に画定される。すなわち、頭部向きは、ユーザーが存在するシーンの座標系との関係における頭のヨー、ピッチ、ロールを示す。

図１ａのセットアップにおいては、球Ａ１およびＡ２は、両眼の視野内にある。両眼と２つの球の間の中心点Ｏ₁₂は同一ライン上にある。すなわち、中心点から見て、球Ａ２は球Ａ１の後方にある。しかしながら、各々の眼は、球がいずれの眼からも同じ視線上にないことから、球Ａ２の一部をＡ１の背後に見る。

図１ｂには、図１ａで眼が置かれていたロケーションに位置付けられたカメラＣ１およびＣ２で両眼を置換したセットアップが示されている。その他の点ではセットアップの距離および方向は同じである。当然のことながら、図１ｂのセットアップの目的は、球Ａ１およびＡ２の立体画像の撮影を可能にすることにある。画像キャプチャの結果得られる２つの画像はＦ_C1とＦ_C2である。「左眼」画像Ｆ_C1は、球Ａ１の画像Ｓ_A1の左側に部分的に見える球Ａ２の画像Ｓ_A2を示す。「右眼」画像Ｆ_C2は、球Ａ１の画像Ｓ_A1の右側に部分的に見える球Ａ２の画像Ｓ_A2を示す。左右の画像の間のこの差は視差と呼ばれ、人間の視覚系が奥行き情報を決定しシーンの３Ｄビューを作成するのに用いる基本的メカニズムであるこの視差は、３Ｄ画像の錯覚を作成するために使用することができる。

図１ｃには、この３Ｄ錯覚の作成が示されている。カメラＣ１およびＣＤがキャプチャした画像Ｆ_C1およびＦ_C2は、それぞれディスプレーＤ１およびＤ２を用いて眼Ｅ１およびＥ２に表示される。画像間の視差は人間の視覚系によって処理され、奥行きの理解が作成される。すなわち、それぞれ左眼が球Ａ１の画像Ｓ_A1の左側に球Ａ２の画像Ｓ_A2を見、右眼が右側にＡ２の画像を見るとき、人間の視覚系は、３次元世界において球Ｖ１の背後に球Ｖ２が存在するという理解を作成する。ここで、画像Ｆ_C1およびＦ_C2が合成でもあり得る、すなわちコンピュータによって作成され得るという点を理解する必要がある。これらの画像が視差情報を担持する場合、合成画像は同様に人間の視覚系によっても３次元のものとして見られる。すなわち、立体画像として使用できるような形でコンピュータ生成画像対を形成することができる。

図１ｄは、３次元であるという錯覚を有する３Ｄ映画または仮想現実シーンを作成するために、眼に対する立体画像の表示という原理をいかに使用できるかを例示している。画像Ｆ_X1およびＦ_X2は、画像が適切な視差を有するように、立体カメラを用いてキャプチャされるか、またはモデルから計算される。左眼および右眼の間の画像が視差を有するようにディスプレーＤ１とＤ２を用いて両眼に毎秒多数（例えば３０）のフレームを表示することにより、人間の視覚系は、移動している３次元画像の認知を作成する。カメラが旋回させられるかまたは合成画像を計算するビュー方向が変化した場合、画像内の変化は、ビュー方向が変化しているすなわちビューワが回転している錯覚を作成する。このビュー方向すなわち頭部向きは、例えば頭部に取付けられた向き検出器によって頭部の現実の向きとしてか、またはユーザーが実際に頭を動かすことなくビュー方向を操作するために使用できるジョイスティックまたはマウスなどの制御デバイスによって決定される仮想向きとして決定され得る。すなわち、「頭部向き」という用語は、ユーザーの頭またはこの頭の変化の実際の物理的向きを意味するために使用することができ、あるいはコンピュータ・プログラムまたはコンピュータ入力デバイスにより決定されるユーザーのビューの仮想方向を意味するためにも使用され得る。

図２ａは、立体ビューイング用、すなわち３Ｄ映像および３Ｄ音響デジタルキャプチャおよび再生のためのシステムおよび装置を示す。システムの役割は、特定のロケーションにあるということの体験また存在の説得力ある再現が、異なるロケーションに物理的に位置設定された１つ以上のビューワによって、任意にはその時以降の将来の一時点において達成可能となるような形で、この特定のロケーションから充分な視覚的および聴覚的情報をキャプチャするという役割である。このような再現には、ビューワが自らの眼と耳を用いてシーン内部のオブジェクトの距離およびロケーションを決定できるように、単一のカメラまたはマイクロホンによってキャプチャ可能な情報よりも多くの情報が必要となる。図１ａ〜１ｄに関連して説明されている通り、視差を有する一対の画像を作成するためには、２つのカメラ・ソースが使用される。同様にして、人間の聴覚系がサウンド方向を検知できるためには、少なくとも２つのマイクロホンが使用される（一般に公知の立体サウンドは、２つの音響チャンネルを録音することによって作成される）。人間の聴覚系は、サウンド方向を検出するために、例えば音響信号のタイミング差のキューを検出することができる。

図２ａのシステムは、３つの主要な部分、すなわち画像ソース、サーバーおよびレンダリング・デバイスで構成され得る。映像キャプチャ・デバイスＳＲＣ１は、映像キャプチャ・デバイスの周りのビューの領域が少なくとも２つのカメラでキャプチャされるように、重複する視野を伴う多数（例えば８つ）のカメラＣＡＭ１、ＣＡＭ２、…ＣＡＭＮを含む。デバイスＳＲＣ１は、異なる方向からの音響のタイミングおよび位相差をキャプチャするため、多数のマイクロホンを含み得る。デバイスは、複数のカメラの向き（ビュー方向）を検出し記録できるように、高解像度の向きセンサーを含み得る。デバイスＳＲＣ１は、コンピュータ・プロセッサＰＲＯＣ１とメモリＭＥＭ１とを含むかまたはこれらに機能的に接続されており、このメモリは、キャプチャ・デバイスを制御するためのコンピュータ・プログラムＰＲＯＧＲ１コードを含む。デバイスによりキャプチャされた画像ストリームは、例えばビューワなどの別のデバイス内で使用するためメモリ・デバイスＭＥＭ２上に記憶され得、かつ／または通信インターフェースＣＯＭＭ１を用いてサーバーに伝送され得る。

１つの画像ストリームまたは複数の画像ストリームを作成する映像キャプチャ・デバイスＳＲＣ１に対し代替的にまたは付加的に、システム内には１つ以上の合成画像ソースＳＲＣ２が存在し得る。このような合成画像ソースは、それが伝送するさまざまな画像ストリームを計算するために仮想世界のコンピュータ・モデルを使用し得る。例えば、ソースＳＲＣ２は、仮想ビューイング位置に位置設定されたＮ個の仮想カメラに対応するＮ個の映像ストリームを計算し得る。このような合成映像ストリーム・セットがビューイングのために使用される場合、ビューワは、図１ｄについて先に説明した通り、３次元仮想世界を見ることができる。デバイスＳＲＣ２は、コンピュータ・プロセッサＰＲＯＣ２とメモリＭＥＭ２とを含むかまたはこれらに機能的に接続されており、このメモリは、合成ソース・デバイスＳＲＣ２を制御するためのコンピュータ・プログラムＰＲＯＧＲ２コードを含む。デバイスによりキャプチャされた画像ストリームは、例えばビューワなどの別のデバイス内で使用するためメモリ・デバイスＭＥＭ５（例えばメモリカードＣＡＲＤ１）上に記憶され得、または通信インターフェースＣＯＭＭ２を用いてサーバーに伝送され得る。

キャプチャ・デバイスＳＲＣ１に加えて、記憶、処理およびデータ・ストリーム・サービング・ネットワークが存在し得る。例えば、キャプチャ・デバイスＳＲＣ１からまたは計算デバイスＳＲＣ２からの出力を記憶するサーバーＳＥＲＶまたは複数のサーバーが存在し得る。デバイスは、コンピュータ・プロセッサＰＲＯＣ３およびメモリＭＥＭ３を含むかまたはこれらに機能的に接続されており、メモリはサーバーを制御するためのコンピュータ・プログラムＰＲＯＧＲ３コードを含んでいる。サーバーは、有線または無線のネットワーク接続またはその両方によってソースＳＲＣ１および／またはＳＲＣ２に、ならびに通信インターフェースＣＯＭＭ３上でビューワ・デバイスＶＩＥＷＥＲ１およびＶＩＥＷＥＲ２に接続され得る。

キャプチャされたまたは作成された映像コンテンツをビューイングするために、１つ以上のビューワ・デバイスＶＩＥＷＥＲ１およびＶＩＥＷＥＲ２が存在し得る。これらのデバイスは、レンダリング・モジュールと表示モジュールを有することができ、あるいはこれらの機能を単一のデバイス内で結合させることもできる。デバイスは、コンピュータ・プロセッサＰＲＯＣ４およびメモリＭＥＭ４を含むかまたはこれらに機能的に接続され得、メモリは、ビューイング・デバイスを制御するためのコンピュータ・プログラムＲＰＯＧＲ４コードを含む。ビューワ（再生）デバイスは、サーバーからの映像データ・ストリームを受信しこの映像データ・ストリームをデコードするためのデータ・ストリーム受信機で構成され得る。データ・ストリームは、通信インターフェースＣＯＭＭ４を通してネットワーク接続上で、またはメモリカードＣＡＲＤ２のようなメモリ・デバイスＭＥＭ６から受信され得る。ビューワ・デバイスは、図１ｃおよび１ｄを用いて説明されている通り、ビューイングのために好適なフォーマットへとデータを処理するためのグラフィック・プロセッシング・ユニットを含み得る。ビューワＶＩＥＷＥＲ１は、レンダリングされた立体映像シーケンスをビューイングするための高解像度の立体画像ヘッドマウント・ディスプレーを含む。ヘッドマウント・デバイスは、向きセンサーＤＥＴ１と立体音響ヘッドホンとを有し得る。ビューワＶＩＥＷＥＲ２は、（立体映像を表示するための）３Ｄ技術で有効化されるディスプレーを含み、レンダリング・デバイスは、それに接続された頭部向き検出器ＤＥＴ２を有することができる。デバイス（ＳＲＣ１、ＳＲＣ２、ＳＥＲＶＥＲ、ＲＥＮＤＥＲＥＲ、ＶＩＥＷＥＲ１、ＶＩＥＷＥＲ２）のいずれも、コンピュータまたは携帯用計算デバイスであり得、あるいはこのようなものに接続されてよい。このようなレンダリング・デバイスは、本明細書中で説明されているさまざまな実施例に係る方法を行なうためのコンピュータ・プログラム・コードを有することができる。

図２ｂは、立体ビューイングのためのカメラ・デバイスを示す。カメラは、左右の眼の画像を作成するためにカメラ・ペアの形に構成されているかまたはこのようなペアに配置され得る３台以上のカメラを含む。カメラ間の距離は、人間の眼の間の通常の距離に対応し得る。カメラは、それらがその視野内に有意なオーバーラップを有するような形で配置され得る。例えば、１８０度以上の広角レンズを使用することができ、３、４、５、６、７、８、９１０、１２、１６または２０台のカメラが存在し得る。カメラは、全ビュー球を横断して規則的にまたは不規則に間隔取りされ得、あるいは、全球の一部のみをカバーする場合もある。例えば、三角形内に配置され、この三角形の１辺に向かって異なるビュー方向を有して、３台のカメラ全てがビュー方向の中央でオーバーラップエリアをカバーするようになっている３台のカメラが存在し得る。別の例としては、広角レンズを有し仮想立方体の隅に規則的に配置されかつ全球をカバーして全球または本質的に全球が少なくとも３台または４台のカメラにより全方向でカバーされるようになっている８台のカメラが存在し得る。図２ｂでは、３対の立体カメラ・ペアが示されている。

図２ｃは、立体ビューイングのためのヘッドマウント・ディスプレーを示す。ヘッドマウント・ディスプレーは、左眼および右眼の画像を表示するための２つのスクリーン区分または２つのスクリーンＤＩＳＰ１およびＤＩＳＰ２を格納する。ディスプレーは、眼に近接し、したがって画像を容易にビューイング可能にするためおよび眼の視野の可能なかぎり多くをカバーするように画像を展開させるためにレンズが使用される。デバイスは、ユーザーが頭を回した場合でも所定のロケーションにとどまるような形でユーザーの頭に取付けられる。デバイスは、頭の運動および頭の方向を決定するための向き検出モジュールＯＲＤＥＴ１を有することができる。ここで、このタイプのデバイスにおいては、頭部の運動の追跡が行なわれるが、ディスプレーが視野の大きなエリアをカバーしていることから、眼の動きの検出は必要でないという点を指摘しておくべきである。頭部向きは、ユーザーの頭の現実の物理的向きに関係付けされ得、それは、ユーザーの頭の現実の向きを決定する目的でセンサーにより追跡され得る。代替的または付加的に、頭部向きは、コンピュータ・プログラムによってかまたはジョイスティックなどのコンピュータ入力デバイスにより制御されるユーザーのビュー方向の仮想向きに関係付けされ得る。すなわち、ユーザーは、入力デバイスを用いて、決定された頭部向きを変更できる可能性があり、またはコンピュータ・プログラムがビュー方向を変更することができる（例えばゲーミングにおいては、ゲーム・プログラムは、現実の頭部向きの代りにまたはそれに追加して、決定された頭部向きを制御し得る。

図２ｄは、カメラ・デバイスＣＡＭ１を例示している。カメラ・デバイスは、センサー素子にぶつかる光の強度を検知するための複数のセンサー素子を含むカメラ検出器ＣＡＭＤＥＴ１を有する。カメラ・デバイスはレンズＯＢＪ１（または複数のレンズのレンズ配置）を有し、レンズは、センサー素子にぶつかる光がレンズ内をセンサー素子まで移動するように位置付けされている。カメラ検出器ＣＡＭＤＥＴ１は、複数のセンサー素子の中央点、例えば矩形センサーについては対角線の交点である公称中心点ＣＰ１を有する。レンズは、例えばレンズの対称軸上に存在する公称中心点ＰＰ１も有する。カメラの向き方向は、カメラセンサーの中心点ＣＰ１から、そしてレンズの中心点ＰＰ１を通過する半直線によって画定される。

上述のシステムは以下のように機能する。第１に、時間同期された映像、音響および向きデータが、キャプチャ・デバイスで記録される。これは、上述の通りの多数の同時発生の映像および音響ストリームで構成され得る。これらは次に、直ちにまたは後に、再生デバイスへの後続する送達に好適なフォーマットへの処理、変換のため、記憶および処理ネットワークに伝送される。変換には、データの質を改善しかつ／または質を所望のレベルに保ちながらデータを削減する目的の音響および映像データに対する後処理ステップが関与し得る。最後に、各再生デバイスがネットワークからデータ・ストリームを受信し、ユーザーがヘッドマウント・ディスプレーおよびヘッドホンを用いて体験できる当初のロケーションの立体ビューイング再現の形にそれをレンダリングする。

以下で説明される通りのビューイングのための立体画像を作成する新規の方法によると、ユーザーは頭を多方向に回すことができる可能性があり、再生デバイスは、原初のレコーディングのロケーションから見えたはずの特定の向きに対応するシーンの高周波数（例えば毎秒６０フレーム）の立体映像および音響ビューを作成することができる。

図３ａ、３ｂおよび３ｃは、動的ソース選択および動的スティッチング・ロケーションを使用することにより画像ソースから第１および第２の眼についての立体画像を形成するステップを例示している。特定の頭部向きについての立体ビューを作成するためには、少なくとも２つの異なるカメラからの画像データが使用される。典型的には、単一のカメラが、全視野をカバーすることはできない。したがって、このソリューションによると、異なるカメラからの画像の複数の区分を合わせてスティッチングすることにより、立体ビューイングのための両方の画像を作成するために、多数のカメラが使用され得る。スティッチングによる画像作成は、３Ｄビューを作成できるような形で画像が適切な視差を有するように行なわれる。これについて以下で説明する。

最高の画像ソースを使用するために、カメラおよび眼の位置のモデルが使用される。カメラはカメラ空間内に位置を有することができ、眼の位置は、眼がカメラの間に現われるようにこの空間内に投影される。現実的パララックス（両眼の間の距離）が利用される。例えば全てのカメラが規則的に間隔取りされた球上に位置設定されている８カメラの規則的セットアップにおいては、眼は、同様にこの球上に投影され得る。このソリューションは、まず、各眼に最も近いカメラを選択する。ヘッドマウント・ディスプレーは、１つの眼あたり大きい視野を有することができることから、１つの眼のビュー全体をカバーする単一の画像（１つのカメラからの）は全く存在しない。この場合、１つのビューは、スティッチングされている２つの画像の中でほぼ同じコンテンツを格納するラインに沿って画像を共に「スティッチング」する公知の技術を用いて、多数の画像の複数の部分から作成されなければならない。図３ａは、立体ビューイングのための２つのディスプレーを示す。左眼ディスプレーの画像は、カメラＩＳ２、ＩＳ３およびＩＳ６からの画像データから組立てられる。右眼ディスプレーの画像は、カメラＩＳ１、ＩＳ３およびＩＳ８からの画像データから組立てられる。この例では、左眼と右眼の画像の両方のために同じ画像ソースＩＳ３が使用されているが、これは、両方の眼においてビューの同じ領域がカメラＩＳ３によりカバーされないようにするために行なわれるという点に留意された。こうして、全ビューを横断する適切な視差が保証される。すなわちビュー内の各ロケーションにおいて、左眼と右眼の画像間に視差が存在する。

スティッチング・ポイントは、最も近いカメラから眼の位置まで撮られたビューの中央領域の周りのエリアを最大にするため、各頭部向きについて動的に変更される。同時に、２つの画像中のビューの同じ領域のために、異なる眼用として異なるカメラが確実に使用されるように注意を払う。図３ｂでは、ビュー内の同じエリアに対応する領域ＰＸＡ１およびＰＸＡ２は、それぞれ異なるカメラＩＳ１およびＩＳ２から撮られている。２台のカメラは離隔されており、したがってＰＸＡ１およびＰＸＡ２は視差効果を示し、こうして、人間の視覚系内で３Ｄ錯覚を作成する。最も近いカメラが典型的に中心の周りのエリアをカバーすることから、（より可視性の高い）シームＳＴＩＴＣＨ１およびＳＴＩＴＣＨ２も同様にビューの中心に位置することが回避される。この方法により、頭部向きに応じてビューの或る領域についての画像を作成するために使用すべきカメラ・ペアの動的選択が導かれる。この選択は、検討された頭部向きを用いて、各画素および各フレームについて行なわれ得る。

スティッチングは、全てのスティッチングされた領域が適正な立体視差を有することを保証するアルゴリズムを用いて行なわれる。図３ｃでは、左右の画像は、シーン内のオブジェクトが異なるカメラ・ソースからのエリアを横断して継続するように、合わせてスティッチングされる。例えば、シーン内の最も近い立方体は左眼の画像へ向けて１つのカメラから、そして右眼のビューに向けて２つの異なるカメラから撮られ、合わせてスティッチングされる。左右の眼について立方体の全ての部分のために使用される１つのカメラが存在し、これが視差を作成する（立方体の右側は右眼の画像内でより可視性が高い）。

同じカメラ画像を、左右両方の眼の中で部分的に使用することができるが、同じ領域について使用することはできない。例えば、左眼のビューの右側はカメラＩＳ３からスティッチング可能であり、右眼の左側は同じカメラＩＳ３からスティッチング可能であるが、この場合、これらのビューエリアが重複しておらず、他方の眼の中でこれらのエリアをレンダリングするために異なるカメラ（ＩＳ１およびＩＳ２）が使用されることが条件となる。換言すると、左眼の画像と右眼の画像の両方について立体ビューイングを行なう際には、同じカメラ・ソース（図３ａ中ではＩＳ３）を使用することができる。従来の立体ビューイングにおいては、反対に、左のカメラが左の画像のために使用され、右の画像のためには右のカメラが使用される。こうして、本方法により、ソース・データをより完全に利用できることになる。このことは、映像データのキャプチャにおいて利用でき、こうして、（毎秒３０フレームなどの一定のサンプリングレートで）異なる時間インスタンスで異なるカメラによりキャプチャされた画像は、ビューイングのための左右の立体画像を作成するために使用される。これは、一定の時間インスタンスにおいてキャプチャされた同じカメラ画像が左眼についての画像の一部および右眼についての画像の一部を作成するために使用されるような形で行なうことができ、ここで左右の眼の画像は、ビューイングのための立体映像ストリームの１つの立体フレームを形成するために共に使用される。異なる時間インスタンスにおいて、異なるカメラを、映像の左眼の一部および右眼フレームの一部を作成するために使用することができる。こうして、キャプチャされた映像データをはるかに効果的に使用することが可能になる。

図４ａおよび４ｂは、異なる頭部向きのための最も近いカメラを選択するためのモデルを例示する。一例として（図４ａ参照）、全てのソース（カメラ）は、それらの位置が８面体を形成し中心点からのソースまでの距離が等しくなるような形で、中心点の周りに配置されている。これは、規則的なカメラ間の間隔取りを有する８カメラ型デバイスに対応する。ソースは、３ｄ空間内で一定のｘ、ｙおよびｚ座標を有する。ソースは、中心点から離れる方向に直接向けられている（ソースの向きは、図２ｄに関連して説明される）。ヘッドマウント・デバイスは、ビューワの頭のロール、ピッチおよびヨーを報告し、これらは、ソースの座標を変換してそれらを頭の座標系との関係においてレンダリングするために使用され得る。代替的には、眼の座標を、ソースの座標系に変換することができる。さらには、ソースの座標系を、正規化された座標系に変換することができ、かつ、頭の座標系をこれと同じ正規化された座標系に変換することもできる。こうして、ソースおよび眼の両方共が、互いとの関係において同じモデル内に位置付けされる。

換言すると、ユーザーの前記眼に対応する第１および第２の仮想眼のロケーションが、頭部向きを用いて座標系内で決定され、その後、画像ソースは、座標系内の画像ソースのロケーションとの関係において仮想眼のロケーションに基づいて選択される。

ｘ軸を中心とした座標の角度γ（ピッチ角としても知られる）だけの回転変換Ｒ_xの例が、以下の回転行列によって定義される。

同様にして、異なる軸を中心とした回転Ｒ_y（ヨーについて）およびＲ_z（ロールについて）を形成させることができる。一般的回転として、Ｒ＝Ｒ_xＲ_yＲ_zだけの３つの回転の行列の乗算が形成され得る。この回転行列を次に、ｖ₂＝Ｒ_V1にしたがった第１の座標系内の任意のベクトルを乗算してデスティネーション座標系内のベクトルを得るのに使用することができる。

ソースおよび眼の座標の変換例が、以下で示されている。全てのベクトルは、３次元空間内のベクトルであり、（ｘ、ｙ、ｚ）として記載される。原点は（０、０、０）にある。全ての画像ソースは、原点を中心とするヨー、ピッチおよびロールにより定義される向きを有する。

各ソースについて、位置ベクトルが、以下のように計算される。
− ソースについての位置ベクトルを作成し、それを（０、０、１）で初期化する。
− アイデンティティ変換行列を作る。
− この行列に、ｙ軸を中心にしてヨーの量だけ座標を回転させる別の行列を乗じる。
− この行列に、ｘ軸を中心にしてピッチ量だけ座標を回転させる別の行列を乗じる。
− この行列に、ｚ軸を中心にしてロール量だけ座標を回転させる別の行列を乗じる。
− 乗算内で左から適用される行列を用いて、行列乗算で位置ベクトルを変換する。

眼について、位置ベクトルを計算する。
− 眼についての位置ベクトルを作成し、それを（０、０、１）で初期化する。
− ビューイング方向（頭部向き）にしたがってソースをレンダリングするために使用されるビュー行列を取り上げ、それを反転させる。（ビュー行列がなぜ反転されるかを例示すると、例えばビューイング方向がｙ軸を中心にして１０度回転させられる場合、ソースはｙ軸を中心にして−１０度回転させられる必要がある。同様にして、オブジェクトを見ていて、その頭を右に回転させた場合、貴方のビュー内のオブジェクトは左に移動する。したがって、我々が想像上の眼の位置に適用する回転は、ソース／ビューに適用する回転の逆数として考慮され得る。）
− （以下で説明する通り）シミュレートされた眼の視差にしたがって、ｙ軸（頭の座標系内で上に向いている軸）を中心として、反転ビュー行列を回転させる。
− 行列が適用されたプリベクトルを用いて、結果として得た行列にしたがって位置ベクトルを変換する。
− 眼の位置とソースの間の距離を計算し、最短距離をピックアップする（以下参照）。

眼の想像上の位置（左または右）が、カメラと等しい中心点からの距離に位置付けされ、キャプチャ・デバイスの向きに比較したビューワのヘッドマウント・デバイスの相対的方向にしたがってｘ、ｙおよびｚ軸全ての周りの中心点を中心にして回転させられる。図４ａおよび４ｂに示されている通り、こうして、面の中央における想像上の中央の眼ＭＥＹの位置（図１ａのＯ₁₂に対応する）が結果としてもたらされる。ビューワの想像上の中央の眼の位置は、次に、仮想左眼ＬＥＹＥまたは右眼ＲＥＹＥの位置を得るために、（顎から頭頂部までビューワの頭と整列させられた）ビューのｙ軸を中心にして回転させられる。人間の眼の視差をシミュレートするため、ビューが左眼のものか右眼のものかに応じて、この回転は、対応する方向に行なわれる。仮想の左眼と右眼の間の角度は、８０度と１２０度の間、例えばおよそ１００度であり得る。角度が９０度より大きい場合、両方の眼について同じ領域内の同じカメラがピックアップされるのを防ぐことができ、角度が１１０度より小さい場合、カメラ間距離が開きすぎるカメラがピックアップされるのを防ぐことができる。

ソース（例えばカメラ）は、ソースと仮想眼の間の距離にしたがって順序付けされており、ビューは、画素がそれぞれ、Ａ）画素をカバーする、およびＢ）条件Ａを満たす全てのソースに対して比較された場合に仮想眼まで距離が最短である、ソースからピックアップされるような形でレンダリングされる。換言すると、ユーザーの第１の眼についての画像の画素のための画像ソースは、前記第１の眼に対応する仮想眼に対する近接性基準を満たす近接する画像ソースである（例えば最も近接するソースである）ものとして決定され、ここで近接する画像ソースは、画素に対応するシーン部分をキャプチャする。近接する画像ソースが画素に対応するシーン部分をキャプチャしない場合、ユーザーの第１の眼についての画像の画素のための画像ソースが、前記第1の眼に対応する前記仮想眼に近接する画像ソースとは別のソースとなるように選択される。

図４ｃおよび４ｄは、頭部向きが変化している場合の立体画像の作成のための画像ソースの選択を例示している。画素は、以下の通りにピックアップされたソースからレンダリングされる。
１．現行の画素をカバーする全てのソースをリストアップする。
２．リスト上の全てのソースから、ソースの中心点が存在しヘッドマウント・ディスプレーの（ビューワの頭の）向きにしたがって回転させられるところに人物の頭が位置付けされた場合に、その人物に見えるものと特定の眼が見るものを最もうまく整合させるソースをピックアップする。
３．ソースが左眼と右眼について同じでないことそしてピックアップされたソースが人間の眼に可能なかぎり近い視差（例えば６４ｍｍ）を有することを確認するために、想像上の人物の眼の視差を調整する。この調整の量は、利用可能なソースおよびそれらの位置によって左右される。この調整は前もって行なうこともできる。第１の眼のための最も近接したカメラが、第１の眼よりもピッチが例えば１０度低いことが発見された場合、最も近接した第２の眼も同様に１０度低いピッチで回転され得る。これは、少なくとも一部の場合において、ピッチがより高いカメラをピックアップする他方の眼から結果としてもたらされるはずの複数のカメラ間のパララックスラインの傾動（ロールを作成する）を回避する目的で行なわれ得る。

仮想位置は、最も近接するカメラのリストに対しルックアップテーブルを用いて予めマッピンクされ得、このマッピングは、例えば１ｍｍの粒度を有することができ、この粒度の内部では全ての位置が同じリストを共有している。表示すべき画像のための画素がレンダリングされている場合、最も近接するカメラからの画素が最初にレンダリングされステンシル・バッファ内にレンダリングされたものとしてマーキングされるような形で、ステンシル・バッファを利用することができる。その後、次に最も近接するカメラからレンダリングされ得るレンダリングされていない画素を決定するためにステンシルテストが実施され、次に最も近接するカメラからの画素がレンダリングされマーキングされ、全ての画像がレンダリングされてしまうまで、こうして続けられる。すなわち、１つの眼についての１つの画像の領域は、これらの領域が画像ソースに対応するような形でレンダリングされ、ここでこれらの領域は、画像ソース座標系内の前記眼に対応する仮想眼に対する画像ソースの近接性順でレンダリングされる。

１つのカメラ・エリアからもう１つのカメラ・エリアへの平滑な「シーム」（空間的遷移）を作成するために、カメラの縁部領域は、以下の通りのアルファ・チャンネル・レンダリングを用いてレンダリングされ得る。各画素について、画素の（赤−緑−青）色値は、例えば補間法によってまたは最も近接するソース画素の色値を使用することによって、ソース画素のソース色値から計算される。大部分の画素について、アルファ値（不透明度）は１である。ソースの縁部上の画素については、アルファ値は１未満に設定され得る。このことはすなわち、次の重複するソースからの色値と先に計算された色値とが混合されて、より平滑なスティッチを作成することを意味している。縁部エリアについては、こうしてレンダリングは、画素をカバーする最も遠位のカメラから開始し得る。すなわち、画像の領域は、領域の縁部エリアをブレンディングすることによって結合され得る。

以上では、２つの任意の最適化、すなわちステンシル・バッファの使用とアルファ・チャンネル・スムージングが説明されてきた。このようにして、グラフィックス・プロセッサの機能性が利用され得る。

図４ｃ、４ｄおよび４ｅは、頭部向きが変化している場合の立体画像の作成のための画像ソースの選択を例示している。図４ｃでは、第１の頭部向きを得るためにユーザーの頭部向きが決定される。その後、以上で説明した通り、第１および第２の画像ソースが立体画像ソースを形成するような形で第１の頭部向きに基づいて第１の画像ソース（ＩＳ７）と第２の画像ソース（ＩＳ２）が選択される。シーン内には、そのシーンの或る細部に対応する仮想領域が存在し得ることがわかる。左右の眼の画像の中には、シーン領域を表わす対応する画素領域（ＰＸＡ１およびＰＸＡ２）が存在する。シーンの第１の領域に対応する第１の画素領域（ＰＸＡ１）の色値が、第１の画像ソース（ＩＳ７）を用いて決定され、この第１の画素領域の色値は左眼画像へと形成される。シーンの同じ領域に対応する第２の画素領域（ＰＸＡ２）の色値が、第２の画像ソース（ＩＳ２）を用いて形成され、この第２の画素領域の色値は、右眼画像へと形成される。

ユーザーが頭を回した（ピッチ、ヨーおよびロール値により表わされる回転が存在する）場合、第２の頭部向きを得るために再びユーザーの頭部向きが決定される。これは、例えばヘッドマウント・ディスプレー内に頭部運動検出器が存在することになるような形で発生し得る。第１のシーン領域に対応する画像領域を形成するために、図４ｄに示されているように、画像ソースが再び選択される。頭が回転したことから、第２の画像ソース（ＩＳ２）そして今度は第３の画像ソース（ＩＳ８）が、第２の頭部向きに基づいて選択され、第２および第３の画像ソースが立体画像ソースを形成する。これは、以上で説明された通りに行なわれる。シーンの第１の領域に対応する第３の画素領域（ＰＸＡ３）の色値は、第３の画像ソース（ＩＳ８）を用いて形成され、第３の画素領域（ＰＸＡ３）の色値は、左眼に対して表示するための第３の画像へと形成される。シーンの同じ第１の領域に対応する第４の画素領域（ＰＸＡ４）の色値は、第２の画像ソース（ＩＳ２）を用いてなおも形成され、第４の画素領域の色値は、右眼に対して表示するための第４の画像へと形成される。

このようにして、検出または決定された頭部向きは、１つの眼のために１つの画像を形成するのに使用される画像ソースの選択に影響を及ぼす。シーンの一領域の立体画像を作成するために使用される画像ソース（カメラ）ペアは、ユーザーが頭を回すかまたはカメラビューが回転させられた場合に、１つの時間インスタンスと別の時間インスタンスの間で変化し得る。これは、同じ画像ソースが常に（仮想）眼に最も近接画像ソースでない場合があるからである。

多数のカメラからの入力に基づいて特定のビュー配位について立体ビューを再現する場合、鍵となるのは、カメラ間のパララックスを得ることである。しかしながらこのパララックスは、画像領域のためのカメラ・ペアがビューイング角度（頭部向き）の変化に起因して変化する場合、２つの連続するフレーム間の画像領域（および視差）のジャンプをひき起こす可能性があるということが指摘されてきた。このジャンプは、ビューワを混乱させ、再現の忠実度を低減する可能性がある。図４ｃにおいて、左の画像は、カメラＩＳ１、ＩＳ３およびＩＳ７からレンダリングされ、右の画像はカメラＩＳ２、ＩＳ３およびＩＳ６からレンダリングされている。ユーザーが頭を左に傾けた場合、画像は、自然に反時計回り方向に回転させられる。しかしながら、ソースとの関係における眼の位置も同様に変化している。図４ｄでは、１つのカメラ（ＩＳ７）は、左の画像のために（ＩＳ８へと）変更された。ＩＳ７からの画像は、ＩＳ８とはわずかに異なり、したがって、ユーザーが頭を傾けた時点で、カメラは、画像の下部部分における視差の顕著な変化をひき起こし得る。

このソリューションにおいて使用される技術は、２つのカメラ・ペアの間の多数のレンダリングされたフレーム内にクロス・ブレンディングを行ない、ビューイング方向の角速度にしたがってクロスブレンドのタイミングおよび持続時間を調整することにある。その目的は、ビューイング方向が急速に変化している場合にクロス・ブレンディングされたジャンプを行なうことにあるが、これは、その場合、すでに自然な動きのぼやけが存在しユーザーはいずれかの特定の点に焦点を合せることがないからである。クロスブレンドの持続時間は、同様に、角速度に応じて調整され得、こうして、低速の動きにおいてクロスブレンドはより長時間にわたり行なわれ、より高速の動きでは、クロスブレンドの持続時間はより短いものとなる。この方法は、カメラ対間でのジャンプの可視性を削減する。クロス・ブレンディングは、影響を受ける画像領域値の加重加算により達成可能である。例えば、図４ｅに示されている通り、ブレンディングすべきエリアは、ＩＳ７およびＩＳ８の結合エリアとなるように選択され得る。エリアは同様に、ＩＳ８のみまたはＩＳ７のみのエリアとなるようにも選択され得る。この方法は、特にヘッドマウント・ディスプレーを用いてビューイングされた場合に、カメラ間のジャンプの顕著さを削減するものとして評価されてきた。換言すると、映像画像の質を改善するために、第１の画像ソースを用いて形成された画像から別の画像ソースを用いた画像にブレンディングすることによって、時間的遷移を作成することができる。時間的遷移ブレンディングの持続時間は、頭の運動速度、例えば角速度についての情報を使用することによって調整され得る。

ソースの変更においては、変更ヒステリシスを適用することができる。ヒステリシスとは、第２のソースが第１のソースに比べて仮想眼により近接しているという決定に起因して、第１のソースから第２のソースへのソース変更がひとたび適用された場合、第１のソースに戻す変更は、第１の変更ほど容易には行なわれないことを意味する。すなわち、頭部向きが変更直前の向きに戻る場合、第１のソースに戻す変更が影響を受けることはない。第１のソースに戻す変更は、第１のソースが明らかに第２のソースに比べて仮想眼に近接することになるように、より大きな頭部向きの変化を必要とする。このようなヒステリシスの使用は、第１と第２のソースが仮想眼に対しほぼ同じ近接性にある向きにおいて、カメラを前後に高速切換えすることによってひき起こされるちらつきを防止するために利用可能である。全エリアのための画像ソースが変更され、その結果全エリアがクロスブレンドされることになるようにクロス・ブレンディングを行なうこともできるということを理解する必要がある。

図５ａおよび５ｂは、画像ソースとして使用されるためのカメラ・デバイスの一例を示している。完全３６０度の立体パノラマを作成するためには、全てのビュー方向を２つのロケーション、つまり左眼用のロケーションと右眼用のロケーションから撮影する必要がある。映像パノラマの場合、これらの画像は、眼を互いに同期した状態に保つため同時に撮られる必要がある。少なくとも別のカメラにより遮られることなく、１つのカメラが全３６０度のビューをカバーすることが物理的に不可能であることから、全３６０度のパノラマを形成するためには、多数のカメラが存在する必要がある。しかしながら追加のカメラはシステムのコストおよびサイズを増大させ、処理すべきデータ・ストリームの数を増大させる。この問題は、より大きい垂直方向の視野を得るために球またはプラトンの立体の形状をした構造にカメラを組付ける場合に、さらに一層大きなものになる。しかしながら、多数のカメラ・ペアを例えば球またはプラトンの立体、例えば８面体または１２面体上に配置することによってさえ、カメラ・ペアが眼のビュー間で自由角度パララックスを達成することはない。眼の間パララックスは、１つの対内の個別のカメラの位置に対して固定されており、すなわち、カメラ・ペアに直交する方向において、いかなるパララックスも達成され得ない。このことは、ｚ軸を中心としたビューイング角度の自由回転も可能にするヘッドマウント・ディスプレーを用いて立体コンテンツがビューイングされる場合に、問題が多い。

キャプチャ・デバイスの周りの全ての点を２回カバーする多数のカメラが必要とされる場合、キャプチャ・デバイス内に非常に多数のカメラが求められることになる。このソリューションにおいて使用される新規の技術は、１８０度（半球）以上の視野を有するレンズを使用すること、およびキャプチャ・デバイスの周囲の入念に選択された配置を用いて、カメラを配置することにある。このような配置は、図５ａに示されており、ここではカメラは、本質的に立方体の中心点から離れる方向に向いている向きＤＩＲ＿ＡＭ１、ＤＩＲ＿ＣＡＭ２、…、ＤＩＲ＿ＣＡＭＮを有し、仮想立方体の隅に位置付けされている。

カメラが１つのカメラ・ペアの左眼ビューとしてと同時に別のカメラ・ペアの右眼ビューとしても役立つことができるような形で、重複する超広視野のレンズを使用することが可能である。これにより、必要とされるカメラの量は半減する。意外な利点として、このようにしてカメラの数を削減すると、互いに充分な重複するビューを有するかぎりにおいて全てのカメラの中から任意に左眼および右眼のカメラをピックアップすることも可能であることから、立体ビューイングの質は良くなる。異なる数のカメラおよび球およびプラトンの立体などの異なるカメラ配置でこの技術を使用すると、（先に説明した通り）各々の眼について最も近接する適合するカメラのピックアップが可能となり、同時に眼の間の垂直方向のパララックスも達成される。このことは、特にヘッドマウント・ディスプレーを用いてコンテンツがビューイングされる場合に有益である。説明されているカメラ・セットアップは、先に説明したスティッチング技術と併せて、カメラ・デバイスのより低いコストでより忠実度の高い立体ビューイングを作成することを可能にし得る。

広い視野は、１つカメラからの画像データを、現行のビュー方向に応じて異なる眼についてのソース・データとして選択することができるようにし、必要なカメラ数を最小限に抑える。間隔取りは、デバイスの上方および下方の高い画質が求められずリング軸に直交する方向からビュー向きが傾いていない場合、１つの軸を中心とした５台以上のカメラのリング内であり得る。

高画質の画像および全ての方向における自由なビュー傾斜が求められる場合には、立方体（カメラ６台）、８面体（カメラ８台）または１２面体（カメラ１２台）のいずれかの、プラトンの立体形状を使用しなければならない。これらのうち、８面体または立方体の隅（図５ａ）は、異なるビュー向きについて利用可能であるカメラ・ペアの組合せの数を最大限にしながらカメラ数を最小にすることの間の優れたトレードオフを提供することから、良い選択である。８台のカメラを伴って構築される実際のカメラ・デバイスが、図５ｂに示されている。カメラ・デバイスは、１８５度の広角レンズを使用し、こうして、カメラの全カバレッジは、４個超の全球となる。このことはすなわち、シーンの全ての点が、少なくとも４台のカメラでカバーされていることを意味する。カメラは、デバイスの中心から離れる方向を向いた向きＤＩＲ＿ＣＡＭ１、ＤＩＲ＿ＣＡＭ２、…、ＤＩＲ＿ＣＡＭＮを有する。

これより少ないカメラでも、このようなオーバー・カバレッジを達成することができ、例えば６台のカメラおよび同じ１８５度のレンズで、３倍のカバレッジを達成することができる。シーンがレンダリングされ、或る画素について最も近接するカメラが選択されている場合、このオーバー・カバレッジは、１つの点をカバーするカメラが常に少なくとも３台存在し、その結果その点について少なくとも３つの異なるカメラ・ペアが形成され得ることを意味する。こうして、ビュー向き（頭部向き）に応じて、優れたパララックスを有するカメラ・ペアがより容易に発見され得る。

カメラ・デバイスは、互いとの関係において少なくとも３台のカメラのうちのいずれのカメラ・ペアも視差を有する立体画像を作成するための視差を有するような形で位置設定された規則的または不規則なセッティングで少なくとも３台のカメラを含むことができる。少なくとも３台のカメラは、これら少なくとも３台のカメラにより全ての部分がキャプチャされるオーバーラップ領域が画定されるような形で、重複する視野を有している。少なくとも３台のカメラのいずれのカメラ・ペアも、立体画像を作成するために人間の眼のパララックスに対応するパララックスを有することができる。例えば、カメラ・ペアの間のパララックス（距離）は５．０ｃｍおよび１２．０ｃｍ、例えばおよそ６．５ｃｍであり得る。少なくとも３台のカメラは、異なる光学軸方向を有することができる。オーバーラップ領域は、単連結トポロジーを有することができ、これはすなわち、それが孔を全くまたは本質的に全く伴わない隣接する表面を形成し、このため全ビューイング表面にわたって、または少なくともオーバーラップ領域の大部分について視差が得られるようになっているということを意味している。前記少なくとも３台のカメラの各々の視野は、おおよそ半球に対応する。カメラ・デバイスは、３台のカメラを含むことができ、３台のカメラは、三角形セッティングで配置されており、こうして、任意のカメラ・ペア間の光学軸の方向は９０度未満の角度を成す。少なくとも３台のカメラは、本質的に仮想立方体の隅に位置付けされ各々本質的に規則的に仮想立方体の中心点から隅への光学軸方向を有する８個の広視野カメラを含み、ここで、前記広視野カメラの各々の視野は少なくとも１８０度であり、こうして、全球ビューの各々の部分は、少なくとも４台のカメラによりカバーされるようになっている（図５ｂ参照）。

図５ｃは、音響ソースとして使用されるためのマイクロホン・デバイスの一例を示す。デバイスの中心の周りに規則的または不規則に、複数のマイクロホンＭＩＣ１、ＭＩＣ２、ＭＩＣＮを位置付けすることができる。例えば、仮想球の表面上に８〜２０個のマイクロホンが位置付けされ得る。シーン再現の存在体験を増大するため、圧倒的な立体音響信号を生成することができる。キャプチャ・デバイスは、多数のロケーションにおいて、デバイスの周りの全ての方向から、音場をキャプチャする多数のマイクロホンを含むことができる。映像レンダリングの場合と同様に、これらのソース・ストリームは、ビューワの頭の位置により指示されるシーン内の場所に耳が位置設定されていた場合に聞こえたはずの信号に類似する合成音響信号を（例えば頭部関連伝達関数を用いて）レンダリングするために使用可能である。

仮想耳の位置に整合するサウンド・ストリームは、多数の技術を用いて多数のマイクロホンの録音から作成され得る。１つの技術は、各々の仮想耳に最も近接する単一の原初のサウンド・ソースを選択することである。しかしながら、これは、マイクロホンの原初の数に限定された空間運動解像度を提供する。より優れた技術は、２つ以上のマイクロホン・セットからの録音を組合せ、キャプチャ・デバイスの周囲空間の多数の集束ローブに対応する合成中間音響ストリームを作成するために、周知の音響ビーム・フォーミング・アルゴリズムを使用することである。レンダリング中、これらの中間ストリームは次に、現在のユーザーの頭部向きと整合する仮想ヘッド内の仮想耳との関係におけるその現行のロケーションに対応する頭部伝達関数（ＨＲＴＦ）を用いて各々フィルタリングされ、その後合計されて、仮想耳と同じ位置で１つの耳が聞いたはずのストリームにより密接に整合するシミュレートされた最終的ストリームを提供する。頭部伝達関数（ＨＲＴＦ）は、空間内の一点からのサウンドが１つの耳にどのように聞こえるかを告げる伝達関数である。２つの頭部伝達関数（左耳と右耳用）を使用して、或る方向および距離から来るように思われる立体サウンドを形成することができる。異なる方向および距離からの多数のサウンド・ソースを単純に合計して、これらのソースからの結合された立体サウンドを得ることができる。

以下で説明する映像について使用される向き補正は、同様に、ビューワの頭が移動していない場合にキャプチャ・デバイスの動きを任意に相殺するために音響にも適用される。

ヘッドマウント・ディスプレーでビューイングされる３Ｄコンテンツの没入型体験は、ユーザーが頭を回すことによっていかに周りを見回すことができるかそして頭部向きにしたがってコンテンツがいかに正しく見られるかに起因する。キャプチャ・デバイスがキャプチャ中に移動した場合（例えばスキューバ・ダイバーのヘルメットまたは木の枝に組付けられたとき）、運動はビューワの頭部向きとは独立してユーザーのビューイング角度に影響を及ぼす。これは、没入感を中断させ、ユーザーが或る一点またはビューイング角度に集中するのを困難にすることが指摘されている。

図６ａおよび６ｂは、立体ビューイングのためのソースおよびデスティネーション座標系の使用を示す。ここで使用される技術は、重複する映像データと同期化したキャプチャ・デバイス向きを記録し、ユーザーに提示されるビューの向きを補正して（再生中にキャプチャ・デバイスの回転を有効に相殺し）キャプチャ・デバイスではなくユーザーがビューイング方向を制御できるようにするために向き情報を使用することである。その代わりビューワがキャプチャ・デバイスの原初の動きを体験したい場合には、補正を無効にすることができる。ビューワが原初の動きのさほど極端でないバージョンを体験したい場合、原初の動きをたどるもののより速度が遅く、通常の向きからの偏差がより少なくなるようにフィルターを用いて補正を動的に適用することができる。

図６ａおよび６ｂは、カメラ・デバイスの回転、およびカメラ座標系（ソース座標系）の回転を例示している。当然のことながら、各カメラのビューおよび向きは変化しており、その結果、ビューワは、たとえ以前と同じ向きにとどまっていても、左への回転を見ることになる。同時に、図６ｃおよび６ｄに示されているように、ユーザーが頭を左に回転させたとすると、結果として得られたビューは、さらに一層大きく左へ回転し、場合によってはビュー方向を１８０度変更する。しかしながら、カメラ・デバイスの運動が取消された場合、ユーザーの頭の運動（図６ｃおよび６ｄを参照）は、ビューを制御する運動となる。スキューバ・ダイバーの例では、ビューワは、ダイバーが見ていたものとは無関係に、見るべきオブジェクトをピックアップできる。すなわち、画像ソースの向きがユーザーの頭の向きと共に使用されてユーザーに表示すべき画像を決定する。

図７ａおよび７ｂは、立体ビューイングのための画像ソース・データの伝達を例示する。本出願において提示される立体ビューイングのシステムは、ビューワに対してソース映像データを伝送するためにマルチビュー映像コーディングを使用し得る。すなわち、サーバーはエンコーダを有することができ、あるいは映像データはサーバーにおいてエンコードされた形態であり得、こうして、帯域幅のために映像データの冗長性が利用されることになる。しかしながら、広角レンズによりひき起こされる大幅な歪みに起因して、コーディング効率は低減され得る。このような場合、異なるソース信号Ｖ１〜Ｖ８を、図７ａにあるように１つの映像信号に結合し、１つのコードされた映像ストリームとして伝送することができる。ビューイング・デバイスは、このとき、左右の眼についての画像をレンダリングするのに必要な画素値をピックアップすることができる。

再生中、ビューワはビューワの頭部の角度的動きに対し直ちに応答し正しい角度からコンテンツをレンダリングする必要があるため、全シーンについての映像データを伝送する（および／またはビューワにおいてデコードする）ことが必要であり得る。これを行なえるためには、ユーザーが頭をいつ何時でも回転させる可能性があることから、サーバーからビューイング・デバイスまで、全３６０度のパノラマ映像をサーバーからビューイング・デバイスまで転送することが必要である。これには大量のデータが求められ、これにより帯域幅が消費されてデコーディング・パワーが必要になる。

本出願中で使用される技術は、ビュー・シグナリングを用いてサーバーに対して現行のおよび予測された将来のビューイング角度を報告し返し、サーバーがビューイング角度にしたがってエンコーディング・パラメータを適応させることができるようにすることにある。サーバーは、頭の動き（受動画像ソース）に基づいて可視領域（能動画像ソース）が、利用可能な帯域幅のより多くを使用しかつより高い画質を有するようにする一方で、現在見えないかまたはまもなく見えるようになると予期されている領域については帯域幅のより小さな部分（そしてより低画質の部分）を使用するような形でデータを転送することができる。実際には、このことは、ユーザーが頭をすばやく大きく回した場合、コンテンツは当初より低い画質を有するが、その後サーバーが新しいビューイング角度を受信し相応してストリームを適応させると直ちに画質は高くなる、ということ意味する。１つの利点は、頭の動きがより小さいものである間、シーンを横断して同等の静的帯域幅割当ての場合に比べて画質は改善されることになるという点にあり得る。このことは、図７ｂに例示されており、ここで、能動ソース信号Ｖ１、Ｖ２、Ｖ５およびＶ７は、残りのソース信号（受動画像ソース）Ｖ３、４Ｖ、６ＶおよびＶ８よりも高い品質でコーディングされている。

（多数のビューワを伴う）ブロードキャスティングの場合、サーバーは、多数のストリームをブロードキャストすることができ、ここで各ストリームは、全てが同等に圧縮される１つのストリームの代りに、大幅に圧縮された球形パノラマの異なるエリアを有している。ビューイング・デバイスは、このとき、ビューイング角度に応じて、どのストリームをデコードしてビューイングすべきかを選択することができる。このようにして、サーバーは、個別のビューワのビューイング角度を知る必要はなく、コンテンツを任意の数の受信機にブロードキャストすることが可能である。

帯域幅を節約するためには、球形ビューの一部がより低い品質で転送されるように画像データを処理することができる。これは、伝送時間における計算要件がより小さいものとなるように、例えば前処理ステップとしてサーバーにおいて行なうことができる。

ビューワとサーバー間の１対１の接続（すなわちブロードキャストではない）の場合、より低い品質で転送されるビューの部分が選択され、こうしてそれが現行のビューイング角度内で見えないようにする。クライアントは、そのビューイング角度を連続的にサーバーに報告し返すことができる。同時に、クライアントは同様に、自ら受信したいストリームの質および帯域幅についての他のヒントを送り返すこともできる。

ブロードキャスティング（１対多数の接続）の場合、サーバーは多数のストリームをブロードキャストでき、ここではビューの異なる部分は、より低い品質で転送され、そのときクライアントは、自らデコードしビューイングするストリームを選択して、より低品質のエリアが、その現行のビューイング角度を有するビューの外側にあるようにする。

球形ビューの一定のエリアの品質を低下させるためのいくつかの方法としては、例えば以下のものがある。
− 空間解像度を低下させかつ／または画像データを縮小する。
− カラーコーディング解像度またはビット深度を低下させる。
− フレーム・レートを低下させる。
− 圧縮を増大させる。および／または
− 画素データの追加のソースを下ろし、画素用の１つのソースのみを保ち、その領域を有効に、ステレオスコピックではなくモノスコピックにする。

これらは全て、個別に、組合せた形で、さらには全てを一度に、例えば、ストリームを高品質ストリームまたは低品質ストリームのいずれかであり１ストリームあたり１つ以上のソースを格納している２つ以上の別個のストリームへと分断することによって各ソースベースで行なうことができる。

これらの方法は同様に、全てのソースが同じストリーム内で転送される場合でも適用可能である。例えば、８面体配置の８つのソースを格納するストリームは、現行ビューイング方向を完全にカバーする４つのソース（およびそれ以上）を無欠の状態に保ち、残る４つのソースのうち２つを完全に下ろし、残りの２つを縮小することにより帯域幅を有意に削減するができる。さらに、サーバーは、フレーム１つおきにこれら２つの低品質ソースを更新して、圧縮アルゴリズムが未変更の連続的フレームを非常に密に圧縮すると同時に場合によっては問題の圧縮の領域を４つの無欠のソースのみをカバーするように設定可能にすることができる。こうすることによって、サーバーは、全ての可視的ソースを高品質に保つものの、不可視的なエリアをモノスコピックで、より解像度が低く、フレーム・レートが低くかつより圧縮されたものにすることにより所要の帯域幅を有意に削減するように管理する。このことは、ユーザーがビューイング方向を急に変更した場合にはユーザーに見えるものの、その場合、クライアントは新しいビューイング角度に適応し、高品質で新しいビューイング角度を有するストリーム（単複）を選択するか、または１対１のストリーミングの場合には、サーバーは、新しいビューイング角度のために高品質のデータを、そして隠されているソースについてはより低い品質を提供するように、ストリームを適応させる。

合成３Ｄコンテンツは、対話型再生用のグラフィクス・プロセッシング・ユニットを用いてシーンの内部モデルからレンダリングされ得る。このようなアプローチは、例えばコンピュータ・ゲームにおいて一般的である。しかしながら、このようなコンテンツの複雑性および臨場感は常に、ノンライブ・レンダリングに利用可能なものよりもはるかに少ないものである、利用可能なローカル処理能力の量によって制限される。

しかしながら、コンピュータ・アニメ３Ｄコンテンツを伴うプレレンダリング３Ｄフィルムは、従来、立体画像対にエンコードされた固定ビューポイントを伴って送達される。ビューワは自らの好みの対を手動式で選択できるのがせいぜいであり、それも映画の環境では１対しか利用可能でない。これらのアプローチには、ローカル・レンダリングされたコンテンツを対話型にする可能性が無い。

図８は、立体ビューイングのための画像を作成するための仮想現実モデルにおける合成映像ソースの使用について例示している。この利用分野で使用される技術は、コンピュータによりレンダリングされた仮想コンテンツをプレレンダリングし、配信し再生するために現実世界コンテンツをキャプチャするための、すでに前述したものと同じ方法を使用することにある。この場合、図８で示した通り、複数のカメラを含む仮想カメラ・デバイスＶＣＡＭＳが、映画の仮想世界の中に位置付けされ、発生したアクションはコンピュータにより、仮想カメラ・デバイスの仮想カメラに対応する映像ストリーム内にキャプチャされる。換言すると、プレーヤーに送達されるコンテンツは、従来の３Ｄフィルムについてと同じ方法で合成的に生成されるが、この場合、仮想ビューワの周囲の全球を少なくとも２回カバーする多数のカメラビュー（２回超）、および各ビューワ向きについて臨場感のある音響信号が作成され得るようにする多数の音響ストリームが含まれている。実際的には、仮想世界の内部３次元（移動）モデルが、画像ソースの画像を計算するために使用される。異なるオブジェクトＯＢＪ１、ＯＢＪ２およびＯＢＪ３のレンダリングの結果として、カメラにより１つの画像がキャプチャされ、計算は、各々のカメラについて実施される。例えば、４面体の隅にある３６０度の仮想カメラは、先に説明された物理的な８カメラ・デバイスと類似のオーバーラップ量を提供すると考えられる。全シーンをキャプチャするものの対で撮られた場合視差特性を有する４台のカメラは、合成世界の自由角度の立体ビューイングを可能にすると考えられる。８台あるいは他の任意の実用的数の半球カメラが同様に使用可能である。仮想カメラは、仮想世界では不可視にされ得ることから、現実のカメラと同じような形で互いに妨害し合うことはない。したがって、仮想カメラの数は、ビューワのデバイスが画像のレンダリングを実施できることになるように整合させることができる。

ビューイング・デバイスにおいて、広角合成ソース信号をデコードすることができ、左右の眼のソース信号を選択し場合によってはスティッチングの必要があれば前述のスティッチング方法により画像を作成することによって、合成世界の立体画像を作成することができる。その結果、このコンテンツの各ビューワは、フィルムの仮想世界の内部にあり、フィルムが休止されている間でも全ての方向を見ることができる。

図９ａは、立体ビューイングのための画像を形成する方法の流れ図を示す。前述の通り、第１の頭部向きを得るため段階９１０においてまず、ユーザーの頭部向きが決定される。この頭部向きに基づいて第１の画像ソースおよび第２の画像ソースが９１５で選択される。これらの画像ソースは、立体画像ソースを形成するようなものであり、すなわちこれら２つのソースの画像から作成された立体画像が、人間の視覚系内で３次元ピクチャとしての理解を生み出すと考えられる。９２０において、第１の画像ソースを用いてユーザーの一方の眼についての第１の標的画像をレンダリングし、第２の画像ソースを用いてユーザーの他方の眼についての第２の標的画像をレンダリングすることにより、第１の立体画像が作成される。画像ソースは、第１および第２の標的画像全体にとって充分であり得、あるいは先に説明した通り、他の画像ソースを使用することも可能である。９３０において、ユーザーの頭部向きを再び決定して、第２の頭部向きを得る。ここで９３５において、第２の頭部向きに基づいて、同じ第２の画像ソースと新しい第３の画像ソースが選択される。これらの画像ソースは、立体画像ソースを形成するようなものであり、すなわちこれら２つのソースの画像から作成された立体画像が、人間の視覚系内で３次元ピクチャとしての理解を生み出すと考えられる。次に９４０において、第２の画像ソースを用いてユーザーの一方の眼についての第３の標的画像をレンダリングし、第３の画像ソースを用いてユーザーの他方の眼についての第４の標的画像をレンダリングすることにより、第２の立体画像が作成される。

図９ｂは、立体ビューイングのための画像を伝送する方法の流れ図を示す。

メモリ内に存在し関連する装置に本発明を実施させるコンピュータ・プログラム・コードの助けを借りて、本発明のさまざまな実施形態を実現することができる。例えば、デバイスには、データを操作し受信し伝送するための回路および電子部品、メモリ内のコンピュータ・プログラム・コード、およびコンピュータ・プログラム・コードを実行する場合にデバイスに一実施形態のフィーチャを実施させるプロセッサ、が含まれ得る。さらに、サーバーのようなネットワーク・デバイスは、データを操作、受信および伝送するための回路および電子部品、メモリ内のコンピュータ・プログラム・コード、およびコンピュータ・プログラム・コードを実行する場合にネットワーク・デバイスに一実施形態のフィーチャを実施させるプロセッサ、を含むことができる。

本発明が以上に提示された実施形態のみに限定されず、添付のクレームの範囲内で修正可能であるということは、明白である。

Claims (74)

1. 第１の頭部向きを得るためにユーザーの頭部向きを決定するステップと、
   前記第１の頭部向きに基づいて、立体画像ソースを形成する第１の画像ソースと第２の画像ソースを選択するステップと、
   前記第１の画像ソースを用いて前記ユーザーの一方の眼についての第１の標的画像、
   および、前記第２の画像ソースを用いて前記ユーザーの他方の眼についての第２の標的画像をレンダリングすることによって、第１の立体画像をレンダリングするステップと、
   第２の頭部向きを得るために前記ユーザーの頭部向きを決定するステップと、
   前記第２の頭部向きに基づいて、立体画像ソースを形成する前記第２の画像ソースと第３の画像ソースを選択するステップと、
   前記第２の画像ソースを用いて前記ユーザーの一方の眼についての第３の標的画像、および、前記第３の画像ソースを用いて前記ユーザーの他方の眼についての第４の標的画像をレンダリングすることによって第２の立体画像をレンダリングするステップと、
   を含む方法。
2. 前記第１の画像ソースを用いて、１シーンの第１の領域に対応する画素の第１の領域の色値を形成するステップであって、画素の前記第１の領域の前記色値が、第１の眼に表示するのに前記第１の標的画像を形成するために使用されている、ステップと、
   前記第２の画像ソースを用いて、１シーンの前記第１の領域に対応する画素の第２の領域の色値を形成するステップであって、画素の前記第２の領域の前記色値が、第２の眼に対して表示する目的で前記第２の標的画像を形成するために使用されている、ステップと、
   前記第３の画像ソースを用いて１シーンの前記第１の領域に対応する画素の第３の領域の色値を形成するステップであって、画素の前記第３の領域の前記色値が、前記第１の眼に対して表示する目的で前記第３の標的画像を形成するために使用されている、ステップと、
   前記第２の画像ソースを用いて１シーンの前記第１の領域に対応する画素の第４の領域の色値を形成するステップであって、画素の前記第４の領域の前記色値が、前記第２の眼に対して表示する目的で前記第４の標的画像を形成するために使用されている、ステップと、
   を含む請求項１に記載の方法。
3. 前記頭部向きを用いて座標系内で前記ユーザーの前記眼に対応する第１および第２の仮想眼のロケーションを決定するステップと、
   前記座標系内の画像ソースのロケーションとの関係における前記仮想眼の前記ロケーションに基づいて前記画像ソースを選択するステップと、
   を含む、請求項１または２に記載の方法。
4. 前記第１の眼に対応する仮想眼に対する近接性基準を満たす近接画像ソースとなるように前記ユーザーの第１の眼についての画像の画素のための画像ソースを決定するステップであって、前記近接画像ソースが前記画素に対応する、前記シーン部分をキャプチャするステップと、
   前記第１の眼に対応する前記仮想眼に対する近接画像ソースとは別のソースとなるように前記ユーザーの前記第１の眼についての画像の画素のための画像ソースを決定するステップであって、前記近接する画像ソースが前記画素に対応する前記シーン部分をキャプチャしない、ステップと、
   を含む請求項３に記載の方法。
5. １つの眼についての１つの画像の領域を、該領域が画像ソースに対応するように、レンダリングするステップであって、前記領域が、画像ソース座標系内での前記眼に対応する仮想眼に対する前記画像ソースの近接性順にレンダリングされる、ステップを含む、請求項１ないし４のいずれか１項に記載の方法。
6. 前記画像の前記領域が、画像スティッチング技術を使用することによってその縁部で結合される、請求項５に記載の方法。
7. 前記画像の前記領域が、該領域の前記縁部のエリアをブレンディングすることによって結合される、請求項６に記載の方法。
8. 前記第１の画像ソースを使用して形成された前記画像、および、前記第３の画像ソースを用いた前記画像からの時間的遷移をブレンディングするステップ、を含む、請求項１ないし７のいずれか１項に記載の方法。
9. 頭部運動速度に関する情報を使用して、時間的遷移ブレンディングの持続時間を調整するステップを含む、請求項８に記載の方法。
10. 頭部関連伝達関数を用いて２つ以上の音響ソースからの音響情報を修正するために、前記頭部向き情報を用いて左耳の音響情報と右耳の音響情報を決定するステップを含む、請求項１ないし９のいずれか１項に記載の方法。
11. 前記画像ソースについてのソース向き情報を決定するステップと、
    前記画像ソースを選択するために前記頭部向き情報と併せて前記ソース向き情報を使用するステップと、
    を含む、請求項１ないし９のいずれか１項に記載の方法。
12. 前記音響ソースについてのソース向きを決定するステップと、
    前記音響ソースからの音響情報を修正するために前記頭部向き情報と併せて前記ソース向き情報を使用するステップと、
    を含む、請求項１０に記載の方法。
13. 前記画像ソースが、現実の世界のカメラである、請求項１ないし１２のいずれか１項に記載の方法。
14. 前記画像ソースが、レンダリングされた合成画像を生成するため仮想カメラを用いてコンピュータ・デバイスの出力として形成される、請求項１ないし１２のいずれか１項に記載の方法。
15. 前記頭部向きが、ユーザーの頭部の物理的向きに関係付けられる、請求項１ないし１４のいずれか１項に記載の方法。
16. 前記頭部向きが、コンピュータ・プログラムまたはコンピュータ入力デバイスによって制御されるユーザーのビュー方向の仮想向きに関係付けされる、請求項１ないし１４のいずれか１項に記載の方法。
17. 前記立体画像が立体映像シーケンスを形成するために使用される、請求項１ないし１６のいずれか１項に記載の方法。
18. シーンの立体映像シーケンスを形成するためにユーザーの頭部向きを決定するステップと、
    前記頭部向きに基づいて、第１の画像ソース、第２の画像ソースおよび第３の画像ソースを選択するステップと、
    前記第１の画像ソースおよび前記第２の画像ソースを用いてユーザーの左眼についての画像シーケンス、および、前記第１の画像ソースおよび前記第３の画像ソースを用いてユーザーの右眼についての画像シーケンスをレンダリングすることによって前記立体映像シーケンスをレンダリングするステップであって、前記第１の画像ソースが、前記映像シーケンスの各立体フレーム内の前記ユーザーの前記左眼および右眼についての前記シーンの異なるエリアをレンダリングするために使用される、ステップと、
    を含む方法。
19. 立体ビューイングのために複数のソース映像信号をエンコードするステップであって、前記ソース映像信号が複数のカメラ・ソースからの映像データを含み、前記ソース映像信号が能動シーン・エリア信号および受動シーン・エリア信号を含んでいる、ステップと、
    ビューイングのための立体ビューイング・デバイスに対して前記複数のソース映像信号を伝送するステップと、
    前記伝送されたソース映像信号内で、前記能動シーン・エリア信号が、前記受動シーン・エリア信号よりも高い忠実度でエンコードされているように、前記エンコーディングおよび伝送のうちの少なくとも１つを行なうステップであって、前記能動および受動シーン・エリア信号は、前記能動シーン・エリア信号が前記ユーザーによりビューイングされている前記シーン・エリアに対応し、前記受動シーン・エリア信号が他のシーン・エリアに対応するように、ユーザーの頭部向きに対応している、ステップと、
    を含む方法。
20. 前記ソース映像信号は、前記能動シーン・エリア信号の少なくとも２つの異なるペアを、１シーンの前記領域の立体映像を作成するために使用することができるように、前記少なくとも３つの能動シーン・エリア信号が１つのシーンの１領域をカバーするように、少なくとも３つの能動シーン・エリア信号を含む、請求項１９に記載の方法。
21. 前記少なくとも３台のカメラのうちの任意のカメラのペアが、視差を有する立体画像を作成するための視差を有するように互いに関係するように位置設定されている、規則的なまたは不規則なセッティング内の少なくとも３台のカメラを含み、
    前記少なくとも３台のカメラは、全ての部分が、前記少なくとも３台のカメラによってキャプチャされるオーバーラップ領域が、規定されるように、重複する視野を有している、立体ビューイング画像データを作成するためのカメラ・デバイス。
22. 前記少なくとも３台のカメラの任意のカメラ・ペアが、立体画像を作成するために人間の眼のパララックスに対応するパララックスを有する、請求項２１に記載のカメラ・デバイス。
23. 前記任意のカメラ・ペアの間の前記パララックスは、５．０ｃｍから１２．０ｃｍの間である、請求項２２に記載のカメラ・デバイス。
24. 前記少なくとも３台のカメラが、異なる光学軸方向を有する、請求項２１、２２または２３に記載のカメラ・デバイス。
25. 前記オーバーラップ領域が単純に接続されたトポロジーを有する、請求項２１ないし２４のいずれか１項に記載のカメラ・デバイス。
26. 前記少なくとも３台のカメラの各々の前記視野が、およそ、半球に対応する、請求項２１ないし２５のいずれか１項に記載のカメラ・デバイス。
27. 前記カメラ・デバイスが３台のカメラを備え、
    前記３台のカメラが三角形セッティングで設置され、
    このため、任意のカメラ・ペアの間の前記光学軸方向が、９０度未満の角度をなす、
    請求項２１ないし２６のいずれか１項に記載のカメラ・デバイス。
28. 前記少なくとも３台のカメラが、本質的に仮想立方体の隅に位置付けされ、
    各々が、本質的に前記仮想立方体の中心点から隅に向う光学軸方向を規則的に有する８台の広視野カメラを備え、
    前記広視野カメラ各々の前記視野が、全球ビューの各部分が少なくとも４台のカメラによってカバーされるように、少なくとも１８０度である、
    請求項２１ないし２６のいずれか１項に記載のカメラ・デバイス。
29. 少なくとも１つのプロセッサ、コンピュータ・プログラム・コードを含むメモリを備える装置であって、
    該メモリおよび該コンピュータ・プログラム・コードは、該少なくとも１つのプロセッサを用いて、前記装置に、少なくとも、
    第１の頭部向きを得るためにユーザーの頭部向きを決定させ、
    前記第１の頭部向きに基づいて、立体画像を形成する第１の画像ソースと第２の画像ソースを選択させ、
    前記第１の画像ソースを用いて前記ユーザーの一方の眼についての第１の標的画像、
    および、前記第２の画像ソースを用いて前記ユーザーの他方の眼についての第２の標的画像をレンダリングすることによって第１の立体画像をレンダリングさせ、
    第２の頭部向きを得るために前記ユーザーの頭部向きを決定させ、
    前記第２の頭部向きに基づいて、立体画像を形成する前記第２の画像ソースと第３の画像ソースを選択させ、
    前記第２の画像ソースを用いて前記ユーザーの一方の眼についての第３の標的画像、および、前記第３の画像ソースを用いて前記ユーザーの他方の眼についての第４の標的画像をレンダリングすることによって第２の立体画像をレンダリングさせる
    ように構成される、装置。
30. 前記装置に、前記第１の画像ソースを用いてシーンの第１の領域に対応する画素の第１の領域の色値を形成させ、ここで、画素の前記第１の領域の前記色値は、第１の眼に表示するように前記第１の標的画像を形成するために使用され、
    前記第２の画像ソースを用いてシーンの前記第１の領域に対応する画素の第２の領域の色値を形成させ、ここで、画素の前記第２の領域の前記色値は、第２の眼に表示するように前記第２の標的画像を形成するために使用され、
    前記第３の画像ソースを用いてシーンの前記第１の領域に対応する画素の第３の領域の色値を形成させ、ここで、画素の前記第３の領域の前記色値は、前記第１の眼に表示するように前記第３の標的画像を形成するために使用され、
    前記第２の画像ソースを用いてシーンの前記第１の領域に対応する画素の第４の領域の色値を形成させる、ここで、画素の前記第４の領域の前記色値は、前記第２の眼に表示するように前記第４の標的画像を形成するために使用される、
    ためのコンピュータ・プログラム・コードを備える請求項２９に記載の装置。
31. 前記装置に、
    前記頭部向きを用いて座標系内で前記ユーザーの前記眼に対応する第１および第２の仮想眼のロケーションを決定させ、
    前記座標系内の画像ソースのロケーションとの関係における前記仮想眼の前記ロケーションに基づいて、前記画像ソースを選択させる、
    コンピュータ・プログラム・コードを備える、請求項２９または３０に記載の装置。
32. 前記装置に、
    前記第１の眼に対応する仮想眼に対する近接性基準を満たす近接画像ソースとなるように前記ユーザーの第１の眼についての画像の画素のための画像ソースを決定させ、ここで、前記近接画像ソースは前記画素に対応する前記シーン部分をキャプチャし、
    前記第１の眼に対応する前記仮想眼に対する近接画像ソースとは別のソースとなるように前記ユーザーの前記第１の眼についての画像の画素のための画像ソースを決定させる、ここで、前記近接する画像ソースは、前記画素に対応する前記シーン部分をキャプチャしない、
    ためのコンピュータ・プログラム・コードを備える請求項３１に記載の装置。
33. 前記装置に、該領域が画像ソースに対応するように、１つの眼についての１つの画像の領域をレンダリングさせるコンピュータ・プログラム・コードを備え、
    前記領域は、画像ソース座標系内での前記眼に対応する仮想眼に対する前記画像ソースの近接性順にレンダリングされる、請求項２９ないし３２のいずれか１項に記載の装置。
34. 前記装置に、画像スティッチング技術を使用することによって前記画像の前記領域をその縁部で結合させるためのコンピュータ・プログラム・コードを備える、請求項３３に記載の装置。
35. 前記装置に、前記領域の前記縁部のエリアをブレンディングすることによって前記画像の前記領域を結合させるコンピュータ・プログラム・コードを備える、請求項３４に記載の装置。
36. 前記装置に、前記第１の画像ソースを使用して形成された前記画像および前記第３の画像ソースを用いた前記画像からの時間的遷移をブレンディングさせるコンピュータ・プログラム・コードを備える、請求項２９ないし３５のいずれか１項に記載の装置。
37. 前記装置に、頭部運動速度に関する情報を使用することによって時間的遷移ブレンディングの持続時間を調整させるコンピュータ・プログラム・コードを備える、請求項３６に記載の装置。
38. 前記装置に、頭部関連伝達関数を用いて、２つ以上の音響ソースからの音響情報を修正するために、前記頭部向き情報を用いて、左耳に対する音響情報と右耳に対する音響情報を決定させるコンピュータ・プログラム・コードを含む、請求項２９ないし３７のいずれか１項に記載の装置。
39. 前記装置に、
    前記画像ソースについてのソース向き情報を決定させ、
    前記画像ソースを選択するために前記頭部向き情報と併せて前記ソース向き情報を使用させる
    コンピュータ・プログラム・コードを備える請求項２９ないし３８のいずれか１項に記載の装置。
40. 前記装置に、
    前記音響ソースについてのソース向きを決定させ、
    前記音響ソースからの音響情報を修正するために前記頭部向き情報と併せて前記ソース向き情報を使用させる
    コンピュータ・プログラム・コードを備える請求項３８に記載の装置。
41. 前記画像ソースが、現実の世界のカメラである、請求項２９ないし４０のいずれか１項に記載の装置。
42. 前記画像ソースが、レンダリングされた合成画像を生成するために仮想カメラを用いてコンピュータ・デバイスの出力として形成される、請求項２９ないし４０のいずれか１項に記載の装置。
43. 前記頭部向きが、ユーザーの頭部の物理的向きに関係付けられる、請求項２９ないし４２のいずれか１項に記載の装置。
44. 前記頭部向きが、コンピュータ・プログラムまたはコンピュータ入力デバイスによって制御されるユーザーのビュー方向の仮想向きに関係付けされる、請求項２９ないし４２のいずれか１項に記載の装置。
45. 前記立体画像が立体映像シーケンスを形成するために使用される、請求項２９ないし４４のいずれか１項に記載の装置。
46. 少なくとも１つのプロセッサ、コンピュータ・プログラム・コードを含むメモリを備える装置であって、前記メモリおよび前記コンピュータ・プログラム・コードが、前記少なくとも１つのプロセッサを用いて、前記装置に、少なくとも、
    シーンの立体映像シーケンスを形成するためにユーザーの頭部向きを決定させ、
    前記頭部向きに基づいて第１の画像ソース、第２の画像ソースおよび第３の画像ソースを選択させ、
    前記第１の画像ソースおよび前記第２の画像ソースを用いてユーザーの左眼についての画像シーケンス、および、前記第１の画像ソースおよび前記第３の画像ソースを用いてユーザーの右眼についての画像シーケンスをレンダリングすることによって前記立体映像シーケンスをレンダリングさせる、ここで、前記第１の画像ソースは、前記映像シーケンスの各立体フレーム内の前記ユーザーの前記左眼および右眼についての前記シーンの異なるエリアをレンダリングするために使用される、
    ように構成される装置。
47. 少なくとも１つのプロセッサ、コンピュータ・プログラム・コードを含むメモリを備える装置であって、
    前記メモリおよび前記コンピュータ・プログラム・コードは、前記少なくとも１つのプロセッサを用いて、前記装置に、少なくとも、
    立体ビューイングのために複数のソース映像信号をエンコードさせ、ここで、前記ソース映像信号は、複数のカメラ・ソースからの映像データを含み、前記ソース映像信号は、能動シーン・エリア信号および受動シーン・エリア信号を含み、
    ビューイングのための立体ビューイング・デバイスに対して前記複数のソース映像信号を伝送させ、
    前記伝送されたソース映像信号内で、前記能動シーン・エリア信号が、前記受動シーン・エリア信号よりも高い忠実度でエンコードされているように、前記エンコーディングおよび伝送のうちの少なくとも１つを実行させる、ここで、前記能動シーン・エリア信号が、前記ユーザーがビューイングしている前記シーン・エリアに対応し、前記受動シーン・エリア信号が、他のシーン・エリアに対応するように、前記能動および受動シーン・エリア信号は、ユーザーの頭部向きに対応している、
    ように構成される、装置。
48. 前記能動シーン・エリア信号の少なくとも２つの異なるペアが、１シーンの前記領域の立体映像を作成できるように、前記少なくとも３つの能動シーン・エリア信号が１つのシーンの１領域をカバーするように、前記ソース映像信号は、少なくとも３つの能動シーン・エリア信号を含む、請求項４７に記載の装置。
49. 少なくとも１つのプロセッサ、コンピュータ・プログラム・コードを含むメモリを備えるシステムであって、
    該メモリおよび該コンピュータ・プログラム・コードが、該少なくとも１つのプロセッサを用いて、該システムに、少なくとも、
    第１の頭部向きを得るためにユーザーの頭部向きを決定させ、
    前記第１の頭部向きに基づいて、立体画像を形成する第１の画像ソースと第２の画像ソースを選択させ、
    前記第１の画像ソースを用いて前記ユーザーの一方の眼についての第１の標的画像、
    および、前記第２の画像ソースを用いて前記ユーザーの他方の眼についての第２の標的画像をレンダリングすることによって第１の立体画像をレンダリングさせ、
    第２の頭部向きを得るために前記ユーザーの頭部向きを決定させ、
    前記第２の頭部向きに基づいて、立体画像を形成する前記第２の画像ソースと第３の画像ソースを選択させ、
    前記第２の画像ソースを用いて前記ユーザーの一方の眼についての第３の標的画像、および、前記第３の画像ソースを用いて前記ユーザーの他方の眼についての第４の標的画像をレンダリングすることによって第２の立体画像をレンダリングさせる
    ように構成される、システム。
50. 非一時的コンピュータ可読媒体上で具体化されたコンピュータ・プログラム・プロダクトであって、
    少なくとも１つのプロセッサ上で実行されたときに、装置またはシステムに、
    第１の頭部向きを得るためにユーザーの頭部向きを決定させ、
    前記第１の頭部向きに基づいて、
    立体画像を形成する第１の画像ソースと第２の画像ソースを選択させ、
    前記第１の画像ソースを用いて前記ユーザーの一方の眼についての第１の標的画像、および、前記第２の画像ソースを用いて前記ユーザーの他方の眼についての第２の標的画像をレンダリングすることによって第１の立体画像をレンダリングさせ、
    第２の頭部向きを得るために、前記ユーザーの頭部向きを決定させ、
    前記第２の頭部向きに基づいて、立体画像ソースを形成する前記第２の画像ソースと第３の画像ソースを選択させ、
    前記第２の画像ソースを用いて前記ユーザーの一方の眼についての第３の標的画像、および、前記第３の画像ソースを用いて前記ユーザーの他方の眼についての第４の標的画像をレンダリングすることによって第２の立体画像をレンダリングさせる
    ように構成されたコンピュータ・プログラムを備えるコンピュータ・プログラム・プロダクト。
51. 第１の頭部向きを得るためにユーザーの頭部向きを決定するための手段と、
    前記第１の頭部向きに基づいて、立体画像ソースを形成する第１の画像ソースと第２の画像ソースを選択するための手段と、
    前記第１の画像ソースを用いて前記ユーザーの一方の眼についての第１の標的画像、
    および、前記第２の画像ソースを用いて前記ユーザーの他方の眼についての第２の標的画像をレンダリングすることによって第１の立体画像をレンダリングするための手段と、
    第２の頭部向きを得るために前記ユーザーの頭部向きを決定するための手段と、
    前記第２の頭部向きに基づいて、立体画像ソースを形成する前記第２の画像ソースと第３の画像ソースを選択する手段と、
    前記第２の画像ソースを用いて前記ユーザーの一方の眼についての第３の標的画像、
    および、前記第３の画像ソースを用いて前記ユーザーの他方の眼についての第４の標的画像をレンダリングすることによって第２の立体画像をレンダリングするための手段と、
    を備える装置。
52. 前記第１の画像ソースを用いて１シーンの第１の領域に対応する画素の第１の領域の色値を形成するための手段であって、画素の前記第１の領域の前記色値が、第１の眼に対して表示する目的で前記第１の標的画像を形成するために使用されている、手段と、
    前記第２の画像ソースを用いて１シーンの前記第１の領域に対応する画素の第２の領域の色値を形成するための手段であって、画素の前記第２の領域の前記色値が、第２の眼に対して表示する目的で前記第２の標的画像を形成するために使用されている、手段と、
    前記第３の画像ソースを用いて１シーンの前記第１の領域に対応する画素の第３の領域の色値を形成するための手段であって、画素の前記第３の領域の前記色値が、前記第１の眼に対して表示する目的で前記第３の標的画像を形成するために使用されている、手段と、
    前記第２の画像ソースを用いて１シーンの前記第１の領域に対応する画素の第４の領域の色値を形成するための手段であって、画素の前記第４の領域の前記色値が、前記第２の眼に対して表示する目的で前記第４の標的画像を形成するために使用されている、手段と、
    を備える、請求項５１に記載の装置。
53. 前記頭部向きを用いて座標系内で前記ユーザーの前記眼に対応する第１および第２の仮想眼のロケーションを決定するための手段と、
    前記座標系内の画像ソースのロケーションとの関係における前記仮想眼の前記ロケーションに基づいて、前記画像ソースを選択するための手段と、
    を備える、請求項５１または５２に記載の装置。
54. 前記第１の眼に対応する仮想眼に対する近接性基準を満たす近接画像ソースとなるように前記ユーザーの第１の眼についての画像の画素のための画像ソースを決定するための手段であって、前記近接画像ソースが前記画素に対応する前記シーン部分をキャプチャする、手段と、
    前記第１の眼に対応する前記仮想眼に対する近接画像ソースとは別のソースとなるように前記ユーザーの前記第１の眼についての画像の画素のための画像ソースを決定するための手段であって、前記近接する画像ソースが、前記画素に対応する前記シーン部分をキャプチャしない、手段と、
    を備える、請求項５３に記載の装置。
55. １つの眼についての１つの画像の領域を、該領域が画像ソースに対応するように、レンダリングするための手段であって、前記領域が、画像ソース座標系内での前記眼に対応する仮想眼に対する前記画像ソースの近接性順にレンダリングされる、手段を備える、請求項５１ないし５４のいずれか１項に記載の装置。
56. 画像スティッチング技術を使用することによって前記画像の前記領域を、その縁部で結合させるための手段を備える、請求項５５に記載の装置。
57. 前記領域の前記縁部のエリアをブレンディングすることによって前記画像の前記領域を結合させるための手段を備える、請求項５６に記載の装置。
58. 前記第１の画像ソースを使用して形成された前記画像、および、前記第３の画像ソースを用いた前記画像からの時間的遷移をブレンディングするための手段を備える、請求項５１ないし５７のいずれか１項に記載の装置。
59. 頭部運動速度に関する情報を使用することによって時間的遷移ブレンディングの持続時間を調整するための手段を備える請求項５８に記載の装置。
60. 頭部関連伝達関数を用いて２つ以上の音響ソースからの音響情報を修正するために、前記頭部向き情報を用いて前記左耳に対する音響情報と前記右耳に対する音響情報を決定するための手段を備える、請求項５１ないし５９のいずれか１項に記載の装置。
61. 前記画像ソースについてのソース向き情報を決定するための手段と、
    前記画像ソースを選択するために前記頭部向き情報と併せて前記ソース向き情報を使用するための手段と、
    を含む、請求項５１ないし５９のいずれか１項に記載の装置。
62. 前記音響ソースについてのソース向きを決定する手段と、
    前記音響ソースからの音響情報を修正するために前記頭部向き情報と併せて前記ソース向き情報を使用する手段と、
    を備える、請求項６０に記載の装置。
63. 前記画像ソースが、現実の世界のカメラである、請求項５１ないし６２のいずれか１項に記載の装置。
64. 前記画像ソースが、レンダリングされた合成画像を生成するため仮想カメラを用いてコンピュータ・デバイスの出力として形成される、請求項５１ないし６２のいずれか１項に記載の装置。
65. 前記頭部向きが、ユーザーの頭部の物理的向きに関係付けられる、請求項５１ないし６４のいずれか１項に記載の装置。
66. 前記頭部向きが、コンピュータ・プログラムまたはコンピュータ入力デバイスによって制御されるユーザーのビュー方向の仮想向きに関係付けされる、請求項５１ないし５４のいずれか１項に記載の装置。
67. 前記立体画像が立体映像シーケンスを形成するために使用される、請求項５１ないし６６のいずれか１項に記載の装置。
68. シーンの立体映像シーケンスを形成するためにユーザーの頭部向きを決定するための手段と、
    前記頭部向きに基づいて第１の画像ソース、第２の画像ソースおよび第３の画像ソースを選択するための手段と、
    前記第１の画像ソースおよび前記第２の画像ソースを用いてユーザーの前記左眼についての画像シーケンス、および、前記第１の画像ソースおよび前記第３の画像ソースを用いてユーザーの前記右眼についての画像シーケンスをレンダリングすることによって前記立体映像シーケンスをレンダリングする手段であって、前記第１の画像ソースが、前記映像シーケンスの各立体フレーム内の前記ユーザーの前記左眼および右眼についての前記シーンの異なるエリアをレンダリングするために使用される、手段と、
    を備える装置。
69. 立体ビューイングのために複数のソース映像信号をエンコードする手段であって、前記ソース映像信号が複数のカメラ・ソースからの映像データを含み、前記ソース映像信号が能動シーン・エリア信号および受動シーン・エリア信号を含んでいる、手段と、
    ビューイングのための立体ビューイング・デバイスに対して前記複数のソース映像信号を伝送するための手段と、
    前記伝送されたソース映像信号内で、前記能動シーン・エリア信号が、前記受動シーン・エリア信号よりも高い忠実度でエンコードされているように、前記エンコーディングおよび伝送のうちの少なくとも１つを実行するための手段であって、前記能動および受動シーン・エリア信号は、
    前記能動シーン・エリア信号が、前記ユーザーがビューイングしている前記シーン・エリアに対応し、
    前記受動シーン・エリア信号が、他のシーン・エリアに対応するように、
    ユーザーの頭部向きに対応している、手段と、
    を含む装置。
70. 前記能動シーン・エリア信号の少なくとも２つの異なるペアは、１シーンの前記領域の立体映像を作成するのに用いることができるように、前記少なくとも３つの能動シーン・エリア信号が１つのシーンの１領域をカバーするように、前記ソース映像信号は、少なくとも３つの能動シーン・エリア信号を含む、請求項６９に記載の装置。
71. 第１の頭部向きを得るためにユーザーの頭部向きを決定するステップと、
    前記第１の頭部向きに基づいて、立体画像ソースを形成する第１の画像ソースと第２の画像ソースを選択するステップと、
    前記第１の画像ソースを用いて前記ユーザーの一方の眼についての第１の標的画像、および、前記第２の画像ソースを用いて前記ユーザーの他方の眼についての第２の標的画像をレンダリングすることによって第１の立体画像をレンダリングするステップと、
    第２の頭部向きを得るために前記ユーザーの頭部向きを決定するステップと、
    前記第２の頭部向きに基づいて、立体画像ソースを形成する前記第２の画像ソースと第３の画像ソースを選択するステップと、
    前記第２の画像ソースを用いて前記ユーザーの一方の眼についての第３の標的画像、および、前記第３の画像ソースを用いて前記ユーザーの他方の眼についての第４の標的画像をレンダリングすることによって第２の立体画像をレンダリングするステップと、
    前記第１の画像ソースを使用して形成された前記画像、および、前記第３の画像ソースを用いた前記画像からの時間的遷移をブレンディングするステップと、
    を含む方法。
72. 頭部運動速度に関する情報を使用することによって時間的遷移ブレンディングの持続時間を調整するステップを含む、請求項７１に記載の方法。
73. 第１の頭部向きを得るためにユーザーの頭部向きを決定するステップと、
    前記第１の頭部向きに基づいて、立体画像ソースを形成する第１の画像ソースと第２の画像ソースを選択するステップと、
    前記第１の画像ソースを用いて前記ユーザーの一方の眼についての第１の標的画像、および、前記第２の画像ソースを用いて前記ユーザーの他方の眼についての第２の標的画像をレンダリングすることによって第１の立体画像をレンダリングするステップと、
    第２の頭部向きを得るために前記ユーザーの頭部向きを決定するステップと、
    前記第２の頭部向きに基づいて、立体画像ソースを形成する前記第２の画像ソースと第３の画像ソースを選択するステップと、
    前記第２の画像ソースを用いて前記ユーザーの一方の眼についての第３の標的画像、および、前記第３の画像ソースを用いて前記ユーザーの他方の眼についての第４の標的画像をレンダリングすることによって第２の立体画像をレンダリングするステップと、
    前記画像ソースについてのソース向き情報を決定するステップと、
    前記画像ソースを選択するために前記頭部向き情報と併せて前記ソース向き情報を使用するステップと、
    を含む方法。
74. 第１の頭部向きを得るためにユーザーの頭部向きを決定するステップと、
    前記第１の頭部向きに基づいて、立体画像ソースを形成する第１の画像ソースと第２の画像ソースを選択するステップと、
    前記第１の画像ソースを用いて前記ユーザーの一方の眼についての第１の標的画像、および、前記第２の画像ソースを用いて前記ユーザーの他方の眼についての第２の標的画像をレンダリングすることによって第１の立体画像をレンダリングするステップと、
    第２の頭部向きを得るために前記ユーザーの頭部向きを決定するステップと、
    前記第２の頭部向きに基づいて、立体画像ソースを形成する前記第２の画像ソースと第３の画像ソースを選択するステップと、
    前記第２の画像ソースを用いて前記ユーザーの一方の眼についての第３の標的画像、
    および、前記第３の画像ソースを用いて前記ユーザーの他方の眼についての第４の標的画像をレンダリングすることによって第２の立体画像をレンダリングするステップと、
    前記第１、第２および第３の画像ソースのためのレンダリングされた合成画像を生成するために仮想カメラを用いてコンピュータ・デバイスの出力として前記第１、第２および第３の画像ソースを形成するステップと、
    を含む方法。

Images