(57)【要約】  画像を生成する装置は、シーンの不完全な表現を提供する３Ｄ画像データを受け取る受信器１０１を備える。受信器１０７が、画像に関するシーン内の目標視点を示す目標視野ベクトルを受け取り、基準ソース１０９が、シーンの基準視点を示す基準視野ベクトルを提供する。修正器１１１が、シーンの目標視点及び基準視点の関数としてレンダリング視点を示すレンダリング視野ベクトルを生成する。画像生成器１０５が、レンダリング視野ベクトル及び３Ｄ画像データに応じて画像を生成する。
2020525927.tif 000002
【特許請求の範囲】
【請求項１】
画像を生成する装置であって、
シーンの不完全な表現を提供する３Ｄ画像データを受け取る受信器と、
前記画像に関する前記シーン内の目標視点を示す目標視野ベクトルを受け取る受信器と、
前記シーンの基準視点を示す基準視野ベクトルを提供する基準ソースであって、前記基準視野ベクトルは、前記３Ｄ画像データが画像データを含む前記シーンの部分と、前記３Ｄ画像データが画像データを含まない前記シーンの部分との間の境界を示す境界視野ベクトルに応じて決定される、基準ソースと、
前記シーンの前記目標視点及び前記基準視点の関数としてレンダリング視点を示すレンダリング視野ベクトルを生成する修正器であって、前記目標視野ベクトルの少なくとも一部の値について、前記３Ｄ画像データがデータを全く含まない前記シーンの部分から離れる方へ前記レンダリング視野ベクトルをバイアスする、修正器と、
前記レンダリング視野ベクトル及び前記３Ｄ画像データに応じて前記画像を生成する画像生成器と、
を備える、装置。
【請求項２】
前記３Ｄ画像データを受け取る前記受信器は、前記３Ｄ画像データを含むと共にさらに公称視点データを含むデータストリームを受け取り、前記基準ソースは、前記公称視点データに応じて前記基準視野ベクトルを生成する、請求項１に記載の装置。
【請求項３】
前記装置は、ディスプレイ・プロパティ・データを受け取る受信器をさらに備え、前記基準ソースは、前記ディスプレイ・プロパティ・データに応じて前記基準視野ベクトルを生成する、請求項１又は２に記載の装置。
【請求項４】
前記修正器はさらに、前記レンダリング視野ベクトルに対応する視点について、前記３Ｄ画像データが画像データを含むビューポートの割合に応じて前記レンダリング視野ベクトルを決定する、請求項１から３のいずれか一項に記載の装置。
【請求項５】
前記３Ｄ画像データは、視点のセットからの視野を表す３Ｄ画像データを含み、前記修正器はさらに、前記視点のセットに応じて前記レンダリング視野ベクトルを決定する、請求項１から４のいずれか一項に記載の装置。
【請求項６】
前記修正器は、前記目標視野ベクトルから前記基準視野ベクトルまでの距離が増加するほど、前記レンダリング視野ベクトルから前記目標視野ベクトルまでの距離を増大させる、請求項１から５のいずれか一項に記載の装置。
【請求項７】
前記修正器は、前記目標視野ベクトルから前記基準視野ベクトルまでの距離が減少するほど、前記レンダリング視野ベクトルから前記目標視野ベクトルまでの距離を増大させる、請求項１から５のいずれか一項に記載の装置。
【請求項８】
前記修正器は、前記レンダリング視野ベクトルから前記基準視野ベクトルまでの距離と、前記レンダリング視野ベクトルから前記目標視野ベクトルまでの距離との比を、前記目標視野ベクトルから前記基準視野ベクトルまでの距離が増大するほど減少させる、請求項１から７のいずれか一項に記載の装置。
【請求項９】
前記修正器は、前記目標視野ベクトルと前記基準視野ベクトルとの間の差が閾値未満である場合、前記レンダリング視野ベクトルを実質的に前記目標視野ベクトルとして決定する、請求項１から８のいずれか一項に記載の装置。
【請求項１０】
前記画像生成器は、
前記レンダリング視野ベクトルについて前記画像の第１の領域をレンダリングするレンダラーであって、前記第１の領域は、前記３Ｄ画像データが画像データを含む領域である、レンダラーと、
前記３Ｄ画像データを前記画像の第２の領域の中へ外挿する外挿器であって、前記第２の領域は、前記３Ｄ画像データが画像データを含まない領域であり、前記第１の領域と前記第２の領域とは隣り合う領域である、外挿器と、
を備える、請求項１から９のいずれか一項に記載の装置。
【請求項１１】
前記画像生成器は、空間的に変動するぼかしを前記画像に適用するぼかしプロセッサであって、ぼかしの度合いは、前記第１の領域の内部エリアよりも、前記第１の領域と前記第２の領域との間の遷移領域の方が高い、ぼかしプロセッサをさらに備える、請求項１０に記載の装置。
【請求項１２】
前記遷移領域は、前記第１の領域のエリアを含む、請求項１１に記載の装置。
【請求項１３】
画像を生成する方法であって、
シーンの不完全な表現を提供する３Ｄ画像データを受け取るステップと、
前記画像に関する前記シーン内の目標視点を示す目標視野ベクトルを受け取るステップと、
前記シーンの基準視点を示す基準視野ベクトルを提供するステップであって、前記基準視野ベクトルは、前記３Ｄ画像データが画像データを含む前記シーンの部分と、前記３Ｄ画像データが画像データを含まない前記シーンの部分との間の境界を示す境界視野ベクトルに応じて決定される、ステップと、
前記シーンの前記目標視点及び前記基準視点の関数としてレンダリング視点を示すレンダリング視野ベクトルを生成するステップであって、前記目標視野ベクトルの少なくとも一部の値について、前記３Ｄ画像データがデータを全く含まない前記シーンの部分から離れる方へ前記レンダリング視野ベクトルをバイアスすることを有する、ステップと、
前記レンダリング視野ベクトル及び前記３Ｄ画像データに応じて前記画像を生成するステップと、
を有する、方法。
【請求項１４】
コンピュータ上で動作されるときに、請求項１３に記載の方法の全てのステップを実行するコンピュータプログラムコード手段を含む、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、シーンの不完全な表現を提供する３Ｄ画像データから画像を生成する装置及び方法に関し、特に、限定はしないが、仮想現実アプリケーション用の画像を生成することに関する。
【背景技術】
【０００２】
伝統的に、画像の技術的処理及び使用は２次元の撮像に基づいてきたが、第３の次元が画像処理で明示的に考慮されることが増えている。
【０００３】
例えば、観察者の２つの目に、見られているシーンの異なる視野を提供することによって観察体験に第３の次元を追加する３次元（３Ｄ）ディスプレイが開発されている。これは、ユーザに、表示される２つの視野を分離する眼鏡を装着させることによって実現することができる。しかし、これはユーザにとって不便と考えられるため、多くのシナリオでは、視野を分離し、それらの視野を各視野が個々にユーザの目に到達し得る異なる方向に送るための、ディスプレイにある手段（レンチキュラーレンズ又はバリアなど）を使用するオートステレオスコピック（autostereoscopic）・ディスプレイを使用することが好ましい。立体ディスプレイには２つの視野が必要とされるのに対し、オートステレオスコピック・ディスプレイは、一般に、より多くの視野（例えば９個の視野）を必要とする。
【０００４】
多くの実施形態では、新しい観察方向のための視野画像を生成することが望ましい。画像及び奥行き情報に基づいてそのような新しい視野画像を生成するための様々なアルゴリズムが知られているが、それらは、提供される（又は導出される）奥行き情報の精度に大きく依存する傾向がある。
【０００５】
実際、３次元の画像情報は、しばしば、ある１つのシーンの異なる視野方向に対応する複数の画像によって提供される。具体的には、映画やテレビ番組などの映像コンテンツは、何らかの３Ｄ情報を含むように生成されることが増えている。そのような情報は、わずかにずらしたカメラ位置から２つの同時の画像を撮影する、専用の３Ｄカメラを使用して撮影することができる。
【０００６】
しかし、多くのアプリケーションでは、提供される画像は、望まれる方向に直接対応してはおらず、又はより多くの画像が必要とされる。例えば、オートステレオスコピック・ディスプレイには、３つ以上の画像が必要であり、実際にはしばしば９〜２６個の視野画像が使用される。
【０００７】
異なる視野方向に対応する画像を生成するために、視点シフト処理が用いられ得る。これは、一般に、単一の視野方向に対応する画像を、関連する奥行き情報と共に使用する視野シフトアルゴリズムによって行われる。
【０００８】
３次元の画像処理に基づく用途の具体例は、仮想現実アプリケーションである。典型的な仮想現実体験では、右目の視野画像と左目の視野画像が、例えば仮想現実ヘッドセットがユーザによる移動及び向きの変化に合わせるために、継続的に生成される。そのような動的な仮想現実視野の生成は、一般に、仮想現実環境に対応する所与のシーンを表す３Ｄ画像データの処理に基づく。例えば、仮想現実サーバが、３次元モデル、又は光強度画像及び奥行きマップ、又はテクスチャマップ及び奥行きメッシュによって表される画像などの３次元画像に基づいて、特定の視野についての視野画像を生成する。
【０００９】
仮想現実アプリケーションなどのアプリケーションの場合、一連の画像が、例えば、ユーザが仮想環境内で仮想的に移動する、又は視野方向／向きを変えることに起因してそれらが変化するのに伴って、ユーザの視野を反映するように生成される。一部のアプリケーションでは、画像は、観察者の向きの変化を反映するように生成されるが、当該エリア内での移動はサポートしない。そのようなシナリオを反映した映像は、しばしば、全方向映像と呼ばれる。他のアプリケーションでは、仮想現実環境内でのユーザの仮想移動を反映するために、移動する観察位置もサポートされる。そのようなシナリオを反映した映像は、しばしば没入型映像と呼ばれる。ユーザの現在の視野は、ある視点についての関連する位置パラメータ及び方向パラメータを記述する視野ベクトルによって表される。
【００１０】
全方向映像の場合、視野ベクトルは、一般にはヨー値、ピッチ値、及びロール値を提供することにより、一般には３自由度（３ＤｏＦ）に従って向きを記述する。
【００１１】
没入型映像の場合、ベクトルは、一般にはヨー、ピッチ、ロールと、３つの空間次元との値を提供することにより、一般には６自由度（６ＤｏＦ）に従って向き及び位置の両方を記述する。
【００１２】
しかし、可変の視野位置及び／又は方向をサポートする柔軟な映像及び画像アプリケーションを開発し、サポートしようとする際に固有の課題は、それらが好ましくは、位置及び／又は方向のサブセットに限定されるのではなく、理想的にはすべての位置及び／又は方向がサポートされることである。例えば、６ＤｏＦの没入型映像の場合、観察者は、任意の位置から、任意の方向でシーンを見ている可能性がある。このことにより、シーンのすべての部分について、そしてすべての位置から、及びすべての方向について、３Ｄ情報が入手可能であることが必要となる。この要件は、多くの実際のアプリケーション、具体的には、３Ｄデータが現実世界のシーンの撮影に基づくアプリケーションなどでは、満たすことが困難であるか又は不可能である。
【００１３】
例えば、映画の場合、監督は、撮影しているクルー及び機器を視野から隠すことに大きな注意を払う。１つの手法はいわゆる１８０°映画文法規則であり、これは、カメラが、シーンの一方の側にあって、もう一方の側を向くように配置されるものである。全方向映像を記録することは、各全方向カメラの周りのシーン全体が見えてしまうため、はるかに難しい。このことにより、例えば、クルーがシーンの大道具の後ろに隠れ、事後処理で三脚などの要素を除去することが余儀なくされる。
【００１４】
実際、完全なカバレッジが適し、利用できる可能性のあるシーンにさえ、好ましい方向がしばしば存在する。観察者が例えば１８０°振り向くことは一般には意味をなさないため、この視点に対応する画像データを記録、記憶、又は送信するために必要とされるリソースを費やすことは一般には現実的でない。
【００１５】
しかし、この結果、欠落しているコンテンツがあり、シーンの表現が不完全になるという問題が生じる。そのため、観察者が実際に１８０°振り向いた場合には、適切な視野の生成を可能にするデータが入手できないことになり、その結果カバレッジが制限される。そのような場合、明白な手法は、３Ｄ画像表現によって提供されるデータがない場合には画像情報を描画しないというものであり、或いは、例えばデフォルトのテクスチャを提示することができる。しかし、これは知覚的に非常に目立ち、ユーザにとって目障りであり、例えば仮想現実アプリケーションにとって欠くことのできない没入型体験を壊す傾向がある。
【００１６】
この問題を回避するには、必要とされ得る視野を生成するために動的に評価及び使用される完全な３次元コンピュータグラフィックモデルを生成することが必要であると一般に考えられる。しかし、これはしばしば現実的でなく、非常に複雑で、リソースを多く要し、過度の撮影及びモデル変換等を必要とする。
【発明の概要】
【発明が解決しようとする課題】
【００１７】
したがって、３次元画像データから画像を生成するための改良された手法があれば有利である。特に、改良された動作、高められた柔軟性、より容易な実施、より容易な動作、改良された通信、低減された複雑性、低減されたリソース需要、改良された没入型のユーザ体験、及び／又は改良された性能を可能にする手法があれば有利である。
【課題を解決するための手段】
【００１８】
そのため、本発明は、好ましくは、上述の不都合点の１つ又は複数を単独で、又は任意の組み合わせで、緩和、軽減、又は解消しようとするものである。
【００１９】
本発明の一態様によれば、画像を生成する装置が提供され、この装置は、シーンの３Ｄ画像データを受け取る受信器であって、３Ｄ画像データはシーンの不完全な表現を提供する、受信器と、上記画像に関するシーン内の目標視点を示す目標視野ベクトルを受け取る受信器と、シーンの基準視点を示す基準視野ベクトルを提供する基準ソースであって、基準視野ベクトルは、３Ｄ画像データが画像データを含むシーンの部分と、３Ｄ画像データが画像データを含まないシーンの部分との間の境界を示す境界視野ベクトルに応じて決定される、基準ソースと、シーンの目標視点及び基準視点の関数としてレンダリング視点を示すレンダリング視野ベクトルを生成する修正器であって、目標視野ベクトルの少なくとも一部の値について、３Ｄ画像データがデータを全く含まないシーンの部分から離れる方へレンダリング視野ベクトルをバイアスするように構成された修正器と、レンダリング視野ベクトル及び３Ｄ画像データに応じて画像を生成する画像生成器と、を備える。
【００２０】
本発明は、多くの実施形態及びシナリオにおいて、改良された画像の生成を可能にする。特に、望まれる視点からの望まれる視野を提供することと、高品質の画像を提供することとの間に向上したトレードオフが達成される。この手法は、例えば、画質がより高い好ましい視野に向かう穏やかな視野のバイアスを提供する。この手法は、例えば、ユーザが視点を制御することができるが、それら視点が、向上した品質を提供する視点に向かうようにバイアスされる仮想現実体験を可能にする。例えば、視野が３Ｄ画像データから生成されることが可能である限り、生成された視野についてユーザが視点を自由に制御できるという効果が提供され得る。しかし、３Ｄ画像データがデータを提供しない視点の方を向くと、システムは、この移動に逆らう抵抗又はバイアスを導入する。これは、多くの状況で、結果として修正されたユーザ行動を生じさせる、微妙で、しばしば知覚不能な適合を提供する。
【００２１】
この手法は特に、目標視野ベクトルがユーザ入力に応じて生成され、制御されるシナリオに、画像の有利な生成を提供する。例えば、この手法は、仮想現実アプリケーション用の視野画像を提供する（例えば仮想現実ヘッドセット用の画像を提供する）のに非常に適する。この手法は、シーンの不完全な表現のみが３Ｄ画像データによって提供されることの影響を低減しながら、高い自由度を可能にする。
【００２２】
さらに、この手法は、３Ｄ画像データからのデータが欠如しているために大幅に品質を低下させる傾向のある視点から離れる方へ仮想現実アプリケーションを制御するように、ユーザをバイアスする。
【００２３】
この手法は、多くの実施形態及びシナリオにおいて、基礎となるシーンの完全な表現を必要とすることなく、画像の満足のいく生成を提供する。この手法は、シーンの不完全な表現の結果生じる不都合を低減し、そのため、不完全なモデル又は撮影の使用を可能にする。特に、この手法は、一般に、例えば３Ｄカメラを使用した現実世界シーンの撮影に基づくアプリケーションに、改良されたサポートを提供する。
【００２４】
３Ｄ画像データは、シーンの不完全な表現を提供し得る。
【００２５】
視野ベクトルは、視点を示す任意の値又は値のセットである。視点は、視野／ビューポートに関する位置及び／又は向きである。視野ベクトルは、例えば、視点の位置を示す１つ又は複数の値、及び／又はある視点についての視野の向きを示す１つ又は複数の値を含む。
【００２６】
３Ｄ画像データは、シーンの（視覚的／光強度）視野を表すように画像コンテンツが生成されることを可能にする任意のデータを含む。例えば、３Ｄ画像データは、システムが視野を生成することを可能にするシーンの３Ｄモデルを含む。多くの実施形態において、３Ｄ画像データは、１つ又は複数の３Ｄ画像を含み、各３Ｄ画像は、画像＋奥行き、又はテクスチャマップ＋メッシュ表現などの、光強度及び奥行きの情報を提供する。多くの実施形態において、３Ｄ画像データは、広角の視野角度の画像を含み、具体的には、ほぼ全方向の画像が含まれる。
【００２７】
３Ｄ画像データは、シーンの不完全な表現を提供し得、よって、少なくとも１つの視点について、３Ｄ画像データが視覚的プロパティの記述を提供しないシーンの部分が少なくとも１つある。３Ｄ画像データによって記述されないシーンの部分は、異なる視点ごとに異なり得る。少なくとも１つの視野位置について、対応するビューポートの少なくとも一部について、３Ｄ画像データが視覚的プロパティの（個々の）記述を含まない、少なくとも１つの視野の向きがある。そのような部分について、画像コンテンツは、一般に、シーンの他の部分の３Ｄ画像データから生成され、具体的には、３Ｄ画像データが画像データを提供する領域（第１の領域など）から、３Ｄ画像データが画像データを提供しない領域（第２の領域など）への外挿によって生成される。
【００２８】
よって、一般にシーンのそのような部分については、画像コンテンツをシーンの他の部分から生成する必要がある（一般には、例えば、異なる領域に属する画像コンテンツには変化が起こらないなど、比較的不正確である傾向のある仮定を使用する）。
【００２９】
シーンは、基礎となる３Ｄ環境の特定の部分又は視野の特定の表現、例えば、所与の時間における所与の位置からの環境の視野の３Ｄ表現である。それは、場合によっては、環境又は世界の３Ｄモデルなど、基礎となる３Ｄ環境全体であってもよい。よって、シーンは、その視野を表すように画像が生成される任意の環境と考えられる。
【００３０】
基準視野ベクトル／視点は、一部のシナリオでは好ましい視野ベクトル／視点に対応し、一部の実施形態では望ましくない視野ベクトル／視点に対応する。
【００３１】
３Ｄ画像データは、シーンの不完全な表現を提供し、基準ソースは、３Ｄ画像データが画像データを含むシーンの部分と、３Ｄ画像データが画像データを含まないシーンの部分との間の境界を示す境界視野ベクトルに応じて、基準視野ベクトルを決定するように構成される。
【００３２】
これは、多くのシナリオにおいて特に有利な動作及び／又は性能を提供する。例えば、多くの実施形態において、それにより、３Ｄ画像データがデータを全く含まないシーンのエリアから離れる方へのバイアスを導入する。特に、これはしばしば、許容できないほど自由度を制約する、又は没入感を壊すことなく、より高い品質の視野に向かう望ましいバイアスを提供する。
【００３３】
本発明の任意選択の特徴によれば、３Ｄ画像データを受け取る受信器は、３Ｄ画像データを含むと共にさらに公称視点データを含むデータストリームを受け取るように構成され、基準ソースは、公称視点データに応じて基準視野ベクトルを生成するように構成される。基準視野ベクトルは、公称視点の関数として決定される。使用される関数は個々の実施形態に望まれる選好、要件、及び効果に依存することが理解されよう。多くの実施形態において、基準視野ベクトルは、公称視点データの中で示される公称視点に対応する／公称視点を示すように決定される。
【００３４】
これは、多くのシナリオにおいて特に有利な動作及び／又は性能を提供する。例えば、多くの実施形態においては、それにより、３Ｄ画像データがデータを全く含まないシーンのエリアから離れる方へのバイアスを導入する。特に、これはしばしば、より許容できないほど自由度を制約する、又は没入感を壊すことなく、より高い品質の視野に向かう望ましいバイアスを提供する。
【００３５】
この手法は、特に、望まれる視点に向かうバイアスをコンテンツ提供者が支援、誘導、及び／又は制御することを可能にする。例えば、「監督」の視野が、推奨又は提案される視点として提供される。
【００３６】
本発明の任意選択の特徴によれば、装置は、ディスプレイ・プロパティ・データを受け取る受信器を備え、基準ソースは、ディスプレイ・プロパティ・データに応じて基準視野ベクトルを生成するように構成される。
【００３７】
これは、多くのシナリオにおいて特に有利な動作及び／又は性能を提供する。例えば、それは、各種のディスプレイへの改良された適合を提供し、使用される特定のディスプレイに合わせた最適化を可能にする。ディスプレイ・プロパティ・データは、具体的には、表示画像によって提供される視野角度の指示である。
【００３８】
本発明の任意選択の特徴によれば、修正器は、レンダリング視野ベクトルに対応する視点について、３Ｄ画像データが画像データを含むビューポートの割合に応じてレンダリング視野ベクトルを決定するようにさらに構成される。
【００３９】
これは、多くのシナリオにおいて特に有利な動作及び／又は性能を提供する。
【００４０】
本発明の任意選択の特徴によれば、３Ｄ画像データは、視点のセットからの視野を表す３Ｄ画像データを含み、修正器は、この視点のセットに応じてレンダリング視野ベクトルを決定するようにさらに構成される。
【００４１】
これは、多くのシナリオにおいて特に有利な動作及び／又は性能を提供する。それは特に、３Ｄ画像データが現実世界シーンの撮影を表す場合に、改良された動作及び／又は性能を提供する傾向がある。
【００４２】
本発明の任意選択の特徴によれば、修正器は、目標視野ベクトルから基準視野ベクトルまでの距離が減少するほど、レンダリング視野ベクトルから目標視野ベクトルまでの距離を増大させるように構成される。
【００４３】
これは、多くのシナリオにおいて、特に基準視野ベクトルが好ましい視点を示す場合に、特に有利な動作及び／又は性能を提供する。
【００４４】
いくつかの実施形態では、視野ベクトルソースは、目標視野ベクトルから基準視野ベクトルまでの距離が減少するほど、レンダリング視野ベクトルから目標視野ベクトルまでの距離を増大させるように構成される。
【００４５】
これは、多くのシナリオにおいて、特に基準視野ベクトルが好ましくない視点を示す場合に、特に有利な動作及び／又は性能を提供する。
【００４６】
本発明の任意選択の特徴によれば、修正器は、レンダリング視野ベクトルから基準視野ベクトルまでの距離と、レンダリング視野ベクトルから目標視野ベクトルまでの距離との比を、目標視野ベクトルから基準視野ベクトルまでの距離が増大するほど減少させるように構成される。
【００４７】
これは、多くのシナリオにおいて、特に基準視野ベクトルが好ましい視点を示す場合に、特に有利な動作及び／又は性能を提供する。
【００４８】
いくつかの実施形態では、視野ベクトルソースは、目標視野ベクトルから基準視野ベクトルまでの距離が減少するほど、レンダリング視野ベクトルから基準視野ベクトルまでの距離と、レンダリング視野ベクトルから目標視野ベクトルまでの距離との比を減少させるように構成される。
【００４９】
これは、多くのシナリオにおいて、特に基準視野ベクトルが好ましくない視点を示す場合に、特に有利な動作及び／又は性能を提供する。
【００５０】
本発明の任意選択の特徴によれば、修正器は、目標視野ベクトルと基準視野ベクトルとの間の差が閾値未満である場合、レンダリング視野ベクトルを実質的に目標視野ベクトルとして決定するように構成される。
【００５１】
これは、多くのシナリオにおいて特に有利な動作及び／又は性能を提供し、特に画質を向上させる必要がない場合に、効果が小さい／知覚不能であることを保証する。
【００５２】
本発明の任意選択の特徴によれば、画像生成器は、レンダリング視野ベクトルについて画像の第１の領域をレンダリングするレンダラーであって、第１の領域は、３Ｄ画像データが画像データを含む領域である、レンダラーと、３Ｄ画像データを画像の第２の領域の中へ外挿する外挿器であって、第２の領域は、３Ｄ画像データが画像データを含まない領域であり、第１の領域と第２の領域とは隣り合う領域である、外挿器と、を備える。
【００５３】
本発明は、多くの実施形態及びシナリオにおいて、改良された画像の生成を可能にする。特に、生成された画像が、３Ｄ画像データが画像データを全く提供しない１つ又は複数のエリアを含む場合でも、改良された知覚画質が達成される。
【００５４】
外挿器は、一般に、第１の領域のために生成された画像コンテンツ（具体的にはピクセル値）を第２の領域の中へ外挿することにより、３Ｄ画像データを第２の領域の中へ外挿するように構成される。よって、一般には、第１の領域のレンダリング画像コンテンツが第２の領域の中へ外挿される。
【００５５】
第１の領域及び／又は第２の領域は、複数の互いに素のエリアを含み得る。
【００５６】
本発明の任意選択の特徴によれば、画像生成器は、空間的に変動するぼかしを画像に適用するぼかしプロセッサであって、ぼかしの度合いは、第１の領域の内部エリアよりも、第１の領域と第２の領域との間の遷移領域の方が高い、ぼかしプロセッサをさらに備える。
【００５７】
本発明は、多くの実施形態及びシナリオにおいて、改良された画像の生成を可能にする。特に、生成された画像が、３Ｄ画像データが画像データを全く提供しない１つ又は複数のエリアを含む場合でも、改良された知覚画質が達成される。特に、一般に外挿に伴う劣化の影響が大幅に低減され、多くのシナリオではユーザに知覚可能でなくなる。
【００５８】
遷移領域のぼかしは、特に知覚的影響を低減させる。さらに、レンダリング視点がユーザ入力によって決定される実施形態では、この手法、特にぼかしは、大きな度合いの外挿が必要とされる視点から離れる方へユーザをバイアスする。
【００５９】
本発明の任意選択の特徴によれば、遷移領域は、第１の領域のエリアを含む。
【００６０】
これは、多くのシナリオにおいて特に有利な動作を提供する。例えば、多くの実施形態においては、それにより、３Ｄ画像データがデータを全く含まないシーンのエリアから離れる方へのバイアスを導入する。
【００６１】
この結果、改良された画像が生成され、具体的には、画像は、入手可能な３Ｄ画像データの特定の特性に合わせてより良好に適合される。
【００６２】
本発明の一態様によれば、画像を生成する方法が提供され、この方法は、シーンの３Ｄ画像データを受け取るステップであって、３Ｄ画像データはシーンの不完全な表現を提供する、ステップと、上記画像に関するシーン内の目標視点を示す目標視野ベクトルを受け取るステップと、シーンの基準視点を示す基準視野ベクトルを提供するステップであって、基準視野ベクトルは、３Ｄ画像データが画像データを含むシーンの部分と、３Ｄ画像データが画像データを含まないシーンの部分との間の境界を示す境界視野ベクトルに応じて決定される、ステップと、シーンの目標視点及び基準視点の関数としてレンダリング視点を示すレンダリング視野ベクトルを生成するステップであって、目標視野ベクトルの少なくとも一部の値について、３Ｄ画像データがデータを全く含まないシーンの部分から離れる方へレンダリング視野ベクトルをバイアスすることを有するステップと、レンダリング視野ベクトル及び３Ｄ画像データに応じて画像を生成するステップと、を有する。
【００６３】
本発明のこれら及び他の態様、特徴、及び利点は、この後に本明細書に記載される実施形態の参照から明らかになり、参照によって説明される。
【００６４】
本発明の実施形態について、図面を参照しながら単なる例として説明する。
【図面の簡単な説明】
【００６５】
【図１】本発明のいくつかの実施形態による画像生成装置の一例を示す図である。
【図２】本発明のいくつかの実施形態による画像生成装置を備える仮想現実デバイスの一例を示す図である。
【図３】本発明のいくつかの実施形態による画像生成装置の一例を示す図である。
【図４】本発明のいくつかの実施形態による画像生成装置の一例を示す図である。
【図５】本発明のいくつかの実施形態による例示的画像生成装置によって生成された画像及びマスクの例を示す図である。
【図６】本発明のいくつかの実施形態による例示的画像生成装置によって生成された画像及びマスクの例を示す図である。
【図７】本発明のいくつかの実施形態による例示的画像生成装置によって生成された画像及びマスクの例を示す図である。
【図８】本発明のいくつかの実施形態による例示的画像生成装置によって生成された画像及びマスクの例を示す図である。
【図９】本発明のいくつかの実施形態による例示的画像生成装置によって生成された画像及びマスクの例を示す図である。
【発明を実施するための形態】
【００６６】
以下の説明は、仮想現実アプリケーション用の画像の生成に適用可能な本発明の実施形態に注目する。しかし、本発明はこの用途に制限されず、多くの異なる画像処理及び生成の用途に適用されることは理解されよう。
【００６７】
図１は、シーンの不完全な表現を提供する３Ｄ画像データに基づいてシーンの視野を表す画像を生成するように構成された画像生成装置を例示する。図１の画像生成装置は、具体的には、仮想現実体験を提供する仮想現実デバイス又はサーバの一部として使用されるレンダラーであってよい。
【００６８】
そのような仮想現実デバイスの一例が図２に例示される。この例では、仮想現実デバイスは、仮想現実シーン内での望まれる移動及び向きを反映するユーザ入力を受け取るように構成されたユーザ入力ユニット２０１を備える。例えば、ユーザは、ジョイスティック及び／若しくはキーボードを使用して仮想現実シーンの中を動き回るか、又は、例えば、視野の向きが、ユーザによって装着された、適切なセンサを備える仮想現実ヘッドセットから決定される。多くの実施形態において、ユーザ入力ユニット２０１は、ユーザ入力を、シーンがそこから見られる位置、及び／又は所与の視野位置からの視野の向きを示す、望まれるレンダリング視点に変換する機能を備える。レンダリング視点は、位置の指示、向きの指示、又はその両方を指すと考えてよく、したがってユーザにとって望まれる視野を示す。
【００６９】
いくつかの実施形態では、所与のレンダリング視点に対して複数の視野が生成され、又は、いくつかの実施形態では、同じユーザ入力から複数の視点が生成されることが理解されよう。例えば、仮想現実デバイスは、右目視野に対応する画像と左目視野に対応する画像とを生成し、それによって３Ｄ効果を提供するように構成される。簡潔と分かりやすさのために、以下の説明は、所与のレンダリング視点に対して１つの画像を生成することに注目する。
【００７０】
ユーザ入力ユニット２０１は、具体的には、望まれる／目標のレンダリング視点を示す目標視野ベクトルを生成するように構成される。例えば、ピッチ、ヨー、及びロールパラメータなどの、観察者の向きを定義する３つの成分／値を備える目標視野ベクトルが生成される。多くの実施形態において、目標視野ベクトルは、それに加えて又は代替として、例えばｘ、ｙ、ｚ値によって表される、シーン内の３次元位置を定義する３つの値を備える。いくつかの実施形態では、位置及び／又は向きは、３つより少ない値によって表されることが理解されよう。例えば、位置は、シーンの中を通る所定の経路に沿った距離によって示され、したがって位置は単一の値によって示される。同様に、ピッチ及びヨーは一定と仮定され、向きはロール値のみによって与えられてもよい。
【００７１】
生成された目標視野ベクトルは、具体的には図１の画像生成装置であるレンダリングユニット２０３に供給される。レンダリングユニット２０３は、視野ベクトルによって反映された視点のための画像を生成するように構成される。画像の生成は、３Ｄ画像ストア２０５から取り出される３Ｄ画像データに依存する。生成された画像は、ディスプレイ２０９を駆動するディスプレイドライバ２０７に供給され、ディスプレイ２０９は、例えば右目又は左目用の仮想現実ヘッドセットのディスプレイである。仮想現実ヘッドセットはさらに、ユーザ入力ユニット２０１にユーザ入力を提供するセンサを備える。
【００７２】
よって、仮想現実デバイスは、３Ｄ画像データによって表される仮想シーン内の特定の視点からの視野を表す画像を生成する。視点は、ユーザ入力によって制御され、ユーザが一般には仮想シーン内を移動すること及び見回すことの両方を可能にする。
【００７３】
この手法では、３Ｄ画像データは、シーンの不完全な表現を提供する。３Ｄ画像データは、具体的には、シーンの一部の部分についてのデータを提供するが、シーンのすべての部分についてのデータは提供せず、すなわち、特に、少なくとも一部の視点についての３Ｄ画像データがシーンの視覚的プロパティを記述するデータを全く含んでいない、シーンの領域／部分／要素がいくつかあり得る。
【００７４】
多くの仮想現実アプリケーションでは、３Ｄ画像データは、シーンの３Ｄモデルの形態で提供される。多くのアプリケーションでは、そのような３Ｄモデルは、シーンの完全な表現を提供し、この３Ｄモデルを評価することにより、すべての可能な視点についての視野画像が生成されることが可能になる。この状況は、しばしば、モデルが環境及びシーンを直接定義する仮想又は人工のシーンで該当する。しかし、多くの状況では、完全なモデルを生成することは可能でないか又は実現可能でない。これは、一部の人工モデルに該当するが、より頻繁には、実世界のシーンを撮影した表現に発生する。例えば、現実世界シーンの撮影からモデルが生成されるが、このモデルは、少なくとも一部の視点（位置及び／又は向き）について欠落データを有する傾向がある。
【００７５】
多くの実施形態において、３Ｄ画像データは、適切なカメラを使用した実世界データの撮影から生成される。実際、一般に、３Ｄ画像データは、いくつかの固定された視野位置についての光強度画像及び関連する奥行き情報の形態で提供される。画像は、そのような例の一部では、極めて幅の広い視野角度に対応しており、実際、状況によってはほぼ完全に全方向である。そのような状況では、３Ｄ画像データの画像及び奥行きが視点シフトアルゴリズムによって使用されて、所与のレンダリング視点についての視野画像を生成する。
【００７６】
しかし、一般には、所与の視点からの撮影は完全ではなく、完全な球状画像（及び奥行き）並びに奥行きを提供するのではなく、球体のサブセットのみが撮影される。これは、一般には、完全球状の撮影デバイスが使用される状況であっても該当し、その理由は、撮影プロセスが本質的に、視野を妨害する物体をシーンの一部の部分に導入する傾向があるためである（例えば、クルー、照明機器、又は実際にカメラシステム自体が視野を妨害することがある（例えば、カメラがカメラ自身を観察する、又は撮影に使用される他のカメラを観察する））。
【００７７】
３Ｄ画像データがどのように表されるかに関係なく、３Ｄ画像データは、一般にシーンの少なくとも一部についてのデータを全く含まないか、又は少なくとも不完全な若しくは不十分なデータを含み、よって、多くの場合は、所与の視点について、ビューポートの一部の部分についてのデータを全く含まないか、又は少なくとも不完全な若しくは不十分なデータを含む。
【００７８】
図１の画像生成装置に相当するレンダリングユニット２０３は、シーンの不完全な表現のみを提供する３Ｄ画像データに基づいて、所与のレンダリング視点のための画像を生成することが可能である。さらに、レンダリングユニット２０３は、画像データの欠如の影響がユーザにとってあまり目立たない、又は不都合とならないように、改良された没入効果を提供する画像を生成するように構成される。例えば、仮想現実の観察者は、周りを見回し、３Ｄ画像データが情報を提供しない領域に遭遇したときに、より滑らかでより没入性の高い体験を有する。
【００７９】
レンダリングユニット２０３は、３Ｄ画像データがシーンの不完全な表現を提供するシーンの３Ｄ画像データを受け取るように構成された画像データ受信器１０１を備える。この特定の例では、画像データ受信器１０１は、３Ｄ画像ストア２０５に結合され、そこから３Ｄ画像データを受け取る。３Ｄ画像データは、例えばインターネットを介することを含む、任意の適切な外部又は内部ソースから受け取られることが理解されよう。
【００８０】
レンダリングユニット２０３はさらに、視野画像をレンダリングすべき視点を反映するレンダリング視野ベクトルを提供するように構成された視野ベクトルソース１０３を含む。この特定の例では、視野ベクトルソース１０３は、シーン内の望まれるレンダリング視点を示す目標視野ベクトルを受け取るように構成される。この特定の例では、視野ベクトルソース１０３は、ユーザ入力ユニット２０１から目標視野ベクトルを受け取るように構成される。視野ベクトルは、視点の指示を提供する１つ又は複数の値の任意のセットである。具体的には、視野ベクトルは、視点についての位置及び／又は向きの指示を提供する、１つ又は複数の値の任意のセットである。視野ベクトルは、一般に、位置（例えばｘ、ｙ、ｚ）若しくは向き（ヨー、ロール、ピッチ）を示す３つの成分値を含む。視野ベクトルは異なる数の成分を含んでもよく、例えば、向きは、方位及び仰角／高度値のみによって（又は、実際、場合によっては方位値のみによって）与えられてよいことが理解されよう。そのような場合、あらかじめ決められた値、デフォルトの値、又は推定値に対応する追加的な自由度が考慮される。
【００８１】
画像データ受信器１０１及び視野ベクトルソース１０３は画像生成器１０５に結合され、画像生成器１０５は、提供された３Ｄ画像に基づいて視野ベクトルソース１０３によって提供されるレンダリング視野ベクトルで表される視点のためのビューポートに対応する画像を生成するように構成される。
【００８２】
３Ｄ画像データはシーンの不完全な表現を提供するので、画像生成器１０５によって生成されている画像は、一部の視点については、３Ｄ画像データからの直接の画像合成によって、画像の一部のみしか生成しないことがある。したがって、多くの実施形態において、画像生成器１０５は、３Ｄ画像データが画像データを提供する画像の部分を直接レンダリングするように構成される。そして、画像の欠落部分は、いくつかの実施形態では、単に、あらかじめ決められた色又はテクスチャで埋められる。多くの実施形態において、画像生成器１０５は、適切な外挿アルゴリズムを使用して画像の欠落部分を埋めるように構成される。
【００８３】
しかし、あらかじめ決められたデータを使用した単純な埋め込みが用いられても、又はより複雑な外挿が用いられても、その結果生じる画質は、データが存在しない画像のエリアについては大幅に低下する傾向がある。
【００８４】
そのような問題に対処するために、図１の視野ベクトルソース１０３は、（場合により）レンダリング視野ベクトルを目標視野ベクトルに対して修正し、具体的にはこの修正を基準視野ベクトルに基づいて行う機能を備える。
【００８５】
この例では、視野ベクトルソース１０３は、生成すべき画像の目標視点を示す目標視野ベクトルを受け取るように構成された受信器１０７を備える。この例では、目標視野ベクトルは、ユーザ入力ユニット２０１から受け取られ、ユーザに望まれる視点又は目標視点（多くの場合は位置と向きの両方）を反映している。よって、この例では、入力視野ベクトルは、理想的にはユーザが生成される視野／画像を好むであろう目標視点のための目標ビューポートを示す、望まれる／目標視野ベクトルである。仮想現実アプリケーションに一般的なこととして、これは、仮想現実／環境／シーン内での仮想ユーザの位置及び向きに相当する。
【００８６】
レンダリングユニット２０３はさらに、シーンの基準視点を示す基準視野ベクトルを提供するように構成された基準ソース１０９を備える。基準視点は、視点と、３Ｄ画像データがデータを提供しないシーン／環境の部分との間の関係を示す情報を提供するために使用される。後でより詳細に説明するように、基準視野ベクトルは、例えば、好ましい若しくは提案される視点（例えば監督によって提案される）を示すか、又は、例えば、３Ｄ画像データがデータを含むシーンの部分のエッジに対応する視点を反映する。
【００８７】
いくつかの実施形態では、基準視野ベクトルは、特定の基準視点のセット又は可能な視点の連続若しくは範囲など、複数の視点を示すように生成される。以下の説明は、基準視野ベクトルが１つの基準視点を示す状況に基づくが、この説明は基準視野ベクトルが２つ以上の視点を示すシナリオに拡張できることが理解されよう。例えば、そのようなシナリオの大半では、処理は、例えば、目標視野ベクトルに最も近いものなど、特定の状況に基づいて選択される単一の基準視点を検討することまで低減することができる。別の例として、説明される処理を、基準視野ベクトルの異なる可能な値に行って、異なる可能なレンダリング視野ベクトルを提供し、そこから単一のベクトルが選択される（例えば、特定の実施形態に応じて、目標視野ベクトルに最も近い、又は目標視野ベクトルから最も遠いもの）。
【００８８】
受信器１０７及び基準ソース１０９は両方とも修正器１１１に結合され、修正器１１１は、シーンのユーザに望まれる視点及び基準視点の関数として、すなわち、基準視野ベクトル及び目標視野ベクトルの関数として、レンダリング視野ベクトルを生成するように構成される。そして、その結果生じるレンダリング視野ベクトルを使用して、先に説明したように画像を生成する。
【００８９】
この手法は、より効率的な手法を提供すると共に、ユーザの仮想移動及び向きをある程度制約する又はバイアスして、生成される画像が、３Ｄ画像データがデータを含むシーンの部分についてのものである傾向となるようにする。この手法は、一般には、ユーザの視点が、３Ｄ画像データが十分なデータを提供しない視点から離れる方へ、かつ３Ｄ画像データがデータを提供する視点に向かう方へバイアス又はシフトされるという効果を提供する。
【００９０】
一例として、ユーザが頭部を（例えば後方へ）回し、よって最終的に、撮影されたコンテンツが存在しない視野の方へ回すと、仮想環境内の仮想の回転は、最初はユーザに正確に追従するが、ビューポートが空っぽの部分の中へ移動するのにつれて動きが少なくなり、それにより、ユーザの実際の動きとの直接の対応関係を壊すが、撮影されたコンテンツをより多く含むレンダリング画像を提供する。したがって、システムがユーザの移動に完全に追従するのではなく、コンテンツが入手可能であるシーンの部分に「くっ付く」又は引き付けられる傾向をもつ、すなわち、より高品質の視野に向かうという効果が達成される。
【００９１】
例えば、所与の位置について、３Ｄ画像データは、所与の基準方向に対して−１４０°〜＋１４０°の角度にわたるデータを含み、基準方向は、撮影カメラの主方向、すなわち、３Ｄ画像データの一部として記憶されている撮影画像データの中央方向に対応する。この場合、頭を（仮想的に）回し始めるユーザは、最初、変更された視野方向に完全に追従する視野を提示される。例えば、ディスプレイが６０°の観察範囲に対応する画像を生成する場合、レンダリング視野ベクトルは、カメラ基準方向に対して＋１１０°までの角度については目標視野ベクトルに追従するように生成される。この場合は、３Ｄ画像データが完全なデータを提供するので、対応するビューポート／画像に対して完全な画像をレンダリングすることができ、外挿は必要とされない。
【００９２】
しかし、ユーザが頭を回転させ続けると、目標視野ベクトル／視点は動いて、３Ｄ画像データがデータを含まない部分に入ることになり、外挿が必要となる。外挿が必要とされる画像の割合、よって品質が低下する画像の割合を減らすために、レンダリング視野ベクトルは、今度は、目標視野ベクトルを正確に追従するのではなく、中央のカメラ基準により近くに修正されるように生成される。例えば、ユーザが移動し、その結果、目標視野ベクトルが＋１１０°〜＋１８０°の間隔内の（方位）角を表すとき、これは、（一般には非線形に）＋１１０°〜＋１４０°の間隔内に入る角度を表すレンダリング視野ベクトルにマッピングされる。すなわち、＋１１０°〜＋１８０°の角度間隔は、＋１１０°〜＋１４０°の角度間隔に（非線形に）マッピングされて、前者の間隔内の目標視野ベクトルの角度が、後者の間隔内のレンダリング視野ベクトルの角度にマッピングされるようにする。よって、ユーザが、３Ｄ画像データが存在しない部分の中へビューポートが移動するような形で移動すると、レンダリングビューポートの対応する移動が減らされる。ユーザにとっての効果は、仮想移動がユーザ入力に完全には追従しないが、その代わりに、提示される視野がいくつかの好ましい視野方向に向かうようにバイアスされる傾向があることである。しかし、このことはユーザにとって不都合な効果とも考えられるが、一般には、提示される画像が比較的高品質であるという有利な効果と、多くの実施形態において極めて低下した品質の視野を完全に回避できるという事実との方が勝る。
【００９３】
基本的に、「輪ゴム」効果を実現することができ、これは、種々の選好がレンダリング視野ベクトルを引っ張るが、それぞれ異なる方向に引っ張るものである。「輪ゴム」の一方の側には、ユーザの好ましい視点に相当する目標視野ベクトルがある。目標視野ベクトルは、レンダリング視点を引き付けるように輪ゴムを引っ張る。「輪ゴム」のもう一方の側には、３Ｄ画像データが存在する３Ｄ画像データの部分に対応する１つ又は複数の視点を表す、基準視野ベクトルがある。輪ゴムの２つの端部は、レンダリング視点を異なる方向に引っ張り、その結果生じるレンダリング視点／視野ベクトルは、これらの因子の相対的な「引っ張り」と、その結果生じる輪ゴムの「伸び」とに依存する。実際、レンダリング視野は、好ましい視野方向に向かって引っ張られ、この引っ張りは一般に、ユーザがこれらの好ましい視野方向から遠くへ移動するほど増大する。（「輪ゴム」のたとえは、具体的、制限的、又は正確な説明であることは意図されず、単に、達成される効果の直感的な指示を提供することが意図されるに過ぎないことが理解されよう。）
【００９４】
この手法は、ユーザの自由な仮想移動を制約するが、多くのシナリオにおいて大幅に改良されたユーザ体験、特に、より没入性の高い体験を提供することが判明している。実際、これは、間接的な仮想移動制御が実施される（例えばジョイスティックやマウスの移動）実施形態だけでなく、仮想移動、したがって生成された目標視野ベクトルが、ユーザの移動を直接映し出すことが意図される実施形態でも該当することが判明している。例えば、仮想ユーザ体験は、ヘッドセットがユーザの頭部の移動を追跡することに基づくアプリケーションであっても、しばしば改良されたユーザ体験を提供することが判明している。
【００９５】
基準視野ベクトル及び目標視野ベクトルの関数としてレンダリング視野ベクトルを決定するために修正器１１１によって使用される特定の関数は、個々の実施形態の特定の要件及び選好に依存することが理解されよう。例えば、関数は、基準視点／視野ベクトルに使用される特定の視点に依存する。
【００９６】
しかし、多くの実施形態において、修正器１１１は、目標視野ベクトル／視点から基準視野ベクトル／視点までの距離が増大するほど、レンダリング視野ベクトル／視点から目標視野ベクトル／視点までの距離を増大させるべく、レンダリング視野ベクトルを決定するように構成される。よって、大半の実施形態では、レンダリング視野ベクトルを生成するために目標視野ベクトルに適用される変更は、目標視野ベクトルが基準視野ベクトルから遠くにあるほど増大する。一般に、基準視野ベクトルは好ましい視点を示し、したがって、目標視野ベクトルと基準視野ベクトルとの間の距離は、ユーザの現在の目標視点が好ましい視野ベクトルからどれほど逸脱しているかを示す。そのため、次第に増大していく修正を目標視野ベクトルに適用すると、目標視野ベクトルが好ましい視点ベクトルから逸脱するほど好ましい視点により近くなるレンダリング視野ベクトルが、結果的に達成される。
【００９７】
視点という用語と視野ベクトルという用語は、視野ベクトルは、対応する視点の表現を（値のセットとして）提供することから、等価であることが理解されよう。そのため、例えば視野ベクトルの修正、視野ベクトル間の距離、視野ベクトル同士の比較等の参照は、視点の修正、視点間の距離、視点同士の比較を参照するのと等価であり、逆も同様である。以下の説明は、視野ベクトルの参照に注目する。
【００９８】
多くの実施形態において、修正器１１１は、具体的には、レンダリング視野ベクトルから基準視野ベクトルまでの距離と、レンダリング視野ベクトルから目標視野ベクトルまでの距離との比が、目標視野ベクトルから基準視野ベクトルまでの距離が増大するほど減少するように、レンダリング視野ベクトルを決定するように構成される。よって、レンダリング視野ベクトルからそれぞれ基準視野ベクトルまでと目標視野ベクトルまでとの相対距離の比は、目標視野ベクトルと基準視野ベクトルとの間の逸脱が増大するほど減少する。
【００９９】
例えば、レンダリング視野ベクトルは、一般には、目標視野ベクトルと基準視野ベクトルとの間（例えば、それらの間の線、又はそれらの間の視野方向／角度に対応する線の上にある）、よって、ユーザに望まれる視点と、（３Ｄ画像データに基づく）好ましい視点との間になるように生成される。レンダリング視野ベクトルの相対位置は、目標視野ベクトルが基準視野ベクトルに近いときには、レンダリング視野ベクトルが目標視野ベクトルに近く（又は実際、目標視野ベクトルと同一に）なるように変更される。しかし、目標視野ベクトルが基準視野ベクトルからより多く逸脱し始めると、レンダリング視野ベクトルは、目標視野ベクトルから離れる方へ、かつ基準視野ベクトルに向かって効果的に移動し始め、すなわち、レンダリング視野ベクトルの相対位置は、以前ほど目標視野ベクトルに近くなくなる。よって、目標視野ベクトルまでの相対距離は増大するのに対し、基準視野ベクトルまでの相対距離は減少し（例えば、両方の距離が、基準視野ベクトルと目標視野ベクトルとの間の全距離を基準として正規化される）、そのため、比が減少する。実際、レンダリング視野ベクトルが、目標視野ベクトルと同じになるように生成されるとき（小さい逸脱の場合）、基準視野ベクトルまでの距離と目標視野ベクトルまでの距離との比は無限である（後者の距離がゼロである）。逸脱が増大するのに従い、レンダリング視野ベクトルと目標視野ベクトルとの間の相対距離はゼロから増大するのに対し、レンダリング視野ベクトルと基準視野ベクトルとの間の相対距離は減少する。
【０１００】
この手法は、３Ｄ画像データがデータを提供しない部分に向かって、又はその中へと移動するほど、データが入手可能な３Ｄ画像データの部分に目標視野ベクトルが向かうように次第に大きくバイアスされるレンダリング視野ベクトルを、修正器１１１が生成することを可能にする。それと同等に、修正器１１１は、（少なくとも目標視野ベクトルの一部の値について）３Ｄ画像データがデータを提供しない部分から離れる方へレンダリング視野ベクトルをバイアスするように構成されてもよい。これは、例えば、レンダリング視野ベクトルを基準視野ベクトルに向かうようにバイアスすることによって行われる。例えば、基準視野ベクトルが好ましい視野方向として設定される場合、基準視野ベクトルは、基準視野ベクトルに向かうように目標視野ベクトルをバイアスすることによって生成される（具体的には、少なくとも目標視野ベクトルの一部の値について、レンダリング視野ベクトルと基準視野ベクトルとの間の距離を、目標視野ベクトルと基準視野ベクトルとの間の距離と比較して減少させる）。他の実施形態では、バイアスは、例えば、基準視野ベクトルを基準視野ベクトルから離れる方へバイアスすることによる。例えば、基準視野ベクトルが、３Ｄ画像データが十分なデータを含むエリア（例えば観察角度）と、３Ｄ画像データが十分なデータを含まないエリア（例えば観察角度）との間の境界を示す境界視野ベクトルとして設定される場合、修正器１１１は、目標視野ベクトルを基準視野ベクトルから離れる方へバイアスすることによって基準視野ベクトルを生成するように構成される（具体的には、少なくとも目標視野ベクトルの一部の値について、レンダリング視野ベクトルと基準視野ベクトルとの間の距離を、目標視野ベクトルと基準視野ベクトルとの間の距離と比較して増大させる）。
【０１０１】
前述のように、修正器１１１は、多くの実施形態において、目標視野ベクトルがレンダリング視野ベクトルに十分に近い限り、目標視野ベクトルに直接一致させるようにレンダリング視野ベクトルを生成するように構成される。これは、多くの実施形態及びシナリオにおいて非常に有利な動作を提供し、実際、結果として、実際に望まれる、又は必要でなければバイアス効果が適用されないようになる。そのことは、知覚的影響の低減をもたらし、より没入性の高い体験につながる。
【０１０２】
多くの実施形態において、レンダリング視野ベクトルは、レンダリング視野ベクトルと目標視野ベクトルとの間の距離が、目標視野ベクトルと基準視野ベクトルとの間の距離の単調増加関数となるように生成される。しかし、単調増加関数は、一般には線形関数ではなく、一般には非線形関数であり、一般には、目標視野ベクトルと基準視野ベクトルとの間の逸脱が増大するほど変更又は修正が増大するように、非線形に増大する。
【０１０３】
前述のように、多くの実施形態及びシナリオでは、目標視野ベクトルに適用される修正は、目標視野ベクトルが基準視野ベクトルから著しい量で異ならない限り、非常に小さいか、又は実際ゼロである。例えば、上記の例では、レンダリング視野ベクトルは、この差が＋１１０°に達するまでは目標視野ベクトルと同一であり、すなわち、この例では、レンダリング視野ベクトルは、３Ｄ画像データがデータを含まないシーンの部分の要素を、ビューポート／画像が含み始めるまで、すなわち、第１の領域が画像全体を満たさない点までは、目標視野ベクトルと同一である。さらに、この効果は、一般には、それ以降徐々に増大し、すなわち、非線形増加関数が適用される。
【０１０４】
これらの効果は、バイアス効果が徐々に増大され、目標視野ベクトルが画像の著しい劣化が発生するほど遠くに移動するまでは、バイアス効果が存在しない及び／又は目立たないという体験を提供する。しかし、目標視野ベクトルがさらに、３Ｄ画像データにデータがないシーンの部分の中へ移動していくと、効果は、最初は徐々に、そして著しく増大し、さらなる移動に対して徐々に積極的になる効果をもつ。
【０１０５】
距離を評価するために任意の適切な距離指標が使用されてよいことが理解されよう。多くのシナリオでは、２つの視野ベクトル間の距離は、仮想シーン内の対応するパラメータ間の距離と考えられる。多くの実施形態において、距離は、シーン内の所与の位置からの２つの視野ベクトルによって表される向き又は視野方向の間の角度差などの角度距離である。多くの実施形態において、距離は、例えば視野ベクトルの１つ又は複数の値を直接比較することにより、視野ベクトルの直接の比較に応じて決定される。
【０１０６】
上記の例では、基準視野ベクトルは、例えば実質的に全方向であるカメラの主方向など、シーンを撮影するための中心視点を示す視野ベクトルと考えられる。そのようなシナリオは、例えば、ユーザが仮想環境内で仮想の位置に固定される実施形態において有利であり、固定された位置は、カメラの位置に相当する。よって、これは、特に、ユーザが撮影カメラの位置に静止しているものとみなされるが、シーン内で「周りを見回す」手段がユーザに提供される、すなわち、視点の変化が視野の向きの変化に制約されるアプリケーションに非常に有利な性能を提供する。
【０１０７】
しかし、他の実施形態では、３Ｄ画像データは、２つ以上のカメラによって撮影されたデータを含む、及び／又は、ユーザが向きだけでなく位置も移動することを可能にする。多くのそのような実施形態では、単一の固定された撮影基準視野ベクトルは最適でないことがある。
【０１０８】
いくつかの実施形態では、システムは、３Ｄ画像データをデータストリームとして受け取り（データファイルとして受け取ることを含む）、データストリームはそのため、仮想シーン／環境の３Ｄ画像データ表現を提供する。３Ｄ画像データは、コンテンツ提供者によってこの形態で提供されてよく、コンテンツ提供者はそのため、仮想現実体験を提供するために探索される、又はその他の形で使用され得る仮想シーン／環境を提供する。
【０１０９】
いくつかの実施形態では、３Ｄ画像データを提供するそのようなデータストリームは、公称視点データを提供する。公称視点データは、３Ｄ画像データの公称視点を示す。この公称視点データは、具体的には、３Ｄ画像データがデータを含む部分と、３Ｄ画像データがデータを含まない部分とを示す情報を提供する。
【０１１０】
一例として、公称視点データは、１つ又は複数の好ましい視点を示す。例えば、シーン内の異なる位置について、好ましい視野方向又は向きが提供される。例えば、仮想環境内の位置ごとに、好ましい視野方向／向きが提供される。好ましい視野方向は、例えば、３Ｄ画像データがデータを全く提供しない、シーンの最も近い部分までの最大距離を有する視野方向を示す。
【０１１１】
多くの実施形態において、そのような好ましい方向情報は、結果として大幅なデータオーバーヘッドを生じさせることなく提供され得ることが理解されよう。例えば、多くの実施形態においては、１つの好ましい視野方向の指示が、多数の位置及び可能なすべての位置をカバーするのに適する。例えば、基準線上にあり、同じ方向を向いている１つ又は複数のカメラによって撮影が行われた場合（３Ｄ画像データの欠落データが、カメラのすぐ後ろにあり、よってカメラ方向のちょうど反対方向にあるシーンの部分に対応する）、すべての位置について好ましい視野方向は、単にそのカメラ方向として与えられる。
【０１１２】
他の実施形態では、差異化手法が使用され、ここでは異なる位置は異なる好ましい視野方向を有する。例えば、欠落データを生じさせる妨害物がある場合、所与の位置について好ましい方向は、その物体から離れる方を向いた方向である。
【０１１３】
いくつかの実施形態では、好ましい視野方向は時間と共に変動する。例えば、公称視点データは、３Ｄ画像データによって表される仮想環境の中を通る経路を記述する。このようにして、誘導された又は制御された体験を提供することができる。例えば、コンテンツ提供者は、シーンを通るユーザの移動が制御されるが、ユーザが所与の位置から自由に周りを見回すことができる物語体験を提供する。しかし、公称視点データは、推奨される位置及び視野の向きを時間の関数として提供する。仮想現実アプリケーションは、ローカルユーザから受け取られる矛盾する命令が存在しなければ、続いて、対応する画像をレンダリングし、表示する。しかし、例えばユーザが頭を回して周りを見回していることを示すユーザ入力が受け取られた場合、システムは、それに応じてレンダリング視野ベクトルを修正し、すなわち、レンダリング視野ベクトルは、公称視野方向と異なるように生成される。
【０１１４】
そのような例では、レンダリングユニット２０３は、公称視点データからレンダリング視野ベクトルを生成するように、具体的には、ユーザ入力が別途指示しない限り、示された公称視点に対応するレンダリング視野ベクトルを生成するように構成される。この場合、レンダリング視野ベクトルは、ユーザ入力を反映するように公称視点に対して修正される。しかし、多くの実施形態において、このプロセスは、レンダリング視野ベクトルが目標視野ベクトルと基準視野ベクトルとの間の距離に依存するようにするという記載される手法を要する。具体的には、公称視点は、対応する基準視野ベクトルを生成するために使用され、ユーザ入力が目標視野ベクトルを生成する（可能性としては基準視野ベクトルに対して）。次いで、基準視野ベクトルが撮影カメラ方向に対応している例に関して説明したように、レンダリング視野ベクトルが生成される。
【０１１５】
この手法は、例えば、コンテンツ提供者が、例えば物語を提供するために仮想現実体験を「監督する」ことを可能にする。ユーザは依然としていくらかの自由度を与えられるが、これは、他の方向に関して欠落しているデータの影響を低減するために、「監督」が推奨する視野方向に向かうように制約又はバイアスされる。
【０１１６】
公称視点データは、方向の明示的な記述を提供する必要はないことが理解されよう。例えば、いくつかの実施形態では、３Ｄ画像データは、実質的に全方向である画像の時間シーケンスの形態で提供される。これらの全方向画像各々の中心点を公称の基準視点と考えることができ、すなわち、具体的には、全方向画像がそこから撮影された位置についての公称向きと考えられる。
【０１１７】
ユーザが入力を全く提供しない場合、画像は、受け取られた全方向画像の、該当する中心部を選択することによってレンダリングされる。しかし、ユーザが例えば周りを見回すことによって視野の向きのシフトを指示した場合、レンダリングユニット２０３は、望まれる向きに対応する全方向視野の異なるセクションを選択する。しかし、このセクションがシーンの欠落部分のうち多くの部分を含むというリスクを低減するために、基準視野ベクトルに向かうようにレンダリング視野ベクトルをバイアスするという、記載される手法が適用される。よって、全方向画像のどのセクションを提示するかを示すために生成されるレンダリング視野ベクトルは、（有効な）画像データを含まない全方向画像の部分のうち多くのセクションをそのセクションが含んでしまう選択から離れる方へバイアスされる。
【０１１８】
基準ソース１０９は、境界視野ベクトルに応じて基準視野ベクトルを決定し、境界視野ベクトルは、３Ｄ画像データが画像データを含むシーンの部分と、３Ｄ画像データが画像データを含まないシーンの部分との間の境界を示す。
【０１１９】
例えば、所与の視点位置について、基準ソースは、３Ｄ画像データが画像データを含む状態から画像データを含まない状態へと遷移する角度を決定する。例えば、前の特定の例では、３Ｄ画像データは、１４０°の角度までの画像データを含んでいる。そのため、境界視野ベクトルは、この値に対応するように決定され、基準視野ベクトルは、この値に設定される（又は例えば、ディスプレイによって表される視野角度の半分に対応する値だけ、すなわち、６０°の視野角度を表すディスプレイの例では１１０°にオフセットされる）。
【０１２０】
そのため、レンダリング視野ベクトルは、目標視野ベクトルがどのように基準視野ベクトルに、よって境界視野ベクトルに関係するかに基づいて決定される。よって、レンダリング視野ベクトルは、３Ｄ画像データがデータを含むシーンの部分から３Ｄ画像データがデータを含まないシーンの部分への遷移に、目標視野ベクトルがどのように関係するかに直接基づいて決定される。
【０１２１】
例えば、目標視野ベクトルは基準／境界視野ベクトルを上回る角度を示すので、レンダリング視野ベクトルは、基準／境界視野ベクトルまでの低減した距離を有するように生成される。例えば、前の特定の例では、目標視野ベクトルが１１０°未満の角度を示す場合、これと基準視野ベクトルとの間の角度差は負であると考えられる。１１０°を超え始めると、差は正になり、レンダリング視野ベクトルは、レンダリング視野ベクトルから基準視野ベクトルまでの角度が、目標視野ベクトルと基準視野ベクトルとの間の差未満になるように生成される。例えば、１１０°を超える角度について、レンダリング視野ベクトルは、
【数１】
2020525927.tif 000003
の角度に対応するように生成され、ここで、θＲｅｎは、レンダリング視野ベクトルの角度（単位：度）であり、θＲｅｆは、基準角度、すなわち１１０°であり、θＴａｒｇは、目標視野ベクトルの角度（単位：度）である。よって、１１０°〜１８０°の目標視野ベクトル角度間隔が、１１０°〜１４０°のレンダリング視野ベクトル角度間隔に非線形にマッピングされる。
【０１２２】
境界視野ベクトルと基準視野ベクトルとの間に適用される関係は、異なる実施形態において異なってよいことが理解されよう。多くの実施形態において、基準視野ベクトルは、単に境界視野ベクトルと同一になるように設定される。他の実施形態では、基準視野ベクトルは、例えば２０°など、境界視野ベクトルに対してオフセットされた値に設定される。
【０１２３】
さらに他の実施形態では、基準ソース１０９は、追加的な境界視野ベクトルを考慮し、複数の境界視野ベクトルに基づいて基準視野ベクトルを決定する。例えば、所与の位置について、例えば−１２０°〜＋１４０°の間隔範囲に３Ｄ画像データが入手可能であると判定され、よって、第１の境界視野ベクトルは−１２０°の境界を示し、第２の境界視野ベクトルは１４０°の境界を示す。基準視野ベクトルは、これらの中点として、例えばこの特定の例では＋１０°として、決定されてよい。よって、いくつかの実施形態では、基準視野ベクトルは、望まれる視野方向を反映するように１つ又は複数の境界視野ベクトルから決定され、他の実施形態では、望ましくない視野方向を反映するように１つ又は複数の境界視野ベクトルから決定される。
【０１２４】
レンダリング視野ベクトルの決定は、多くの実施形態において、単に目標視野ベクトル及び基準視野ベクトルのみよりも多くの面を考慮する。例えば、カメラの方向に対応するように基準視野ベクトルを決定することが現実的でない実施形態でも、カメラに関する視点を考慮することがなお可能であり、有利である。
【０１２５】
多くの実施形態において、３Ｄ画像データは、異なる視点からの視野のセットとして生成される。これら視野の各々は、対応する視点のための画像（例えば全方向画像及び／又は３Ｄ画像）に対応し、この画像は、一般に、当該視点の位置に当該視点の向きで配置されたカメラによって撮影されたものである。
【０１２６】
そのような例では、３Ｄ画像データは、一般に、視点を定義するデータを含む（この情報も所与の視点のための画像をレンダリングするために使用される）。この情報は、レンダリング視野ベクトルを生成する際にも考慮されてよい。例えば、レンダリング視点は、結果として３Ｄ画像データの視点に対する距離が低減される視点に向かうようにバイアスされる。
【０１２７】
別の例として、修正器１１１は、３Ｄ画像データが画像データを含む所与のレンダリング視野ベクトルについてのビューポートの割合を考慮に入れるように構成される。例えば、非線形関数は、外挿／埋め込みによって生成する必要のある画像の割合が、目標視野ベクトルの関数としてどれほど速く変化するかを反映するように、動的に適合される。
【０１２８】
例えば、外挿によって生成する必要のある画像の面積が、レンダリング視野ベクトルが変化するのにつれて非常に速く増大する場合は、レンダリング視野ベクトルを基準視野ベクトル（例えばこれが境界視野ベクトルとして与えられる場合）の非常に近くに保つ、積極的な効果が適用される。しかし、変化がごく漸進的なものに過ぎない場合は、結果としてさらに漸進的で目立ちにくい効果を生じさせる関数が適用される。
【０１２９】
レンダリング視野ベクトルを決定する際に複数のパラメータを考慮するための異なるアルゴリズム及び手法が、異なる実施形態で使用されてよいことが理解されよう。例えば、異なるパラメータを組み合わせた効果は、複数の項をもつ非線形エネルギー関数Ｊとして表される。次いで、非線形最適化アルゴリズムを使用して、Ｊを最小化するものとしてレンダリング視野ベクトルを決定する。例えば、勾配降下手法が使用される。
【０１３０】
多くの実施形態において、レンダラー２０３は、意図されるディスプレイの１つ又は複数のパラメータを示すディスプレイ・プロパティ・データを受け取るように構成される。そして、修正器１１１は、レンダリング視野ベクトルを決定する際にそのようなディスプレイ・プロパティを考慮するように構成される。
【０１３１】
例えば、レンダリングユニット２０３は、ディスプレイによってサポートされる視野角度の情報を受け取る。例えばディスプレイが仮想現実ヘッドセットの一部である場合、ディスプレイ・プロパティは、ヘッドセットを着用しているユーザにディスプレイが提供する観察角度を示す。次いでこの情報を使用して、例えば上記で示したように基準視野ベクトルを決定することにより（例えば、この情報を使用して、ディスプレイのエッジが、３Ｄ画像データがデータを含むシーンの部分の端部に達する角度を決定することにより）、又は適用される関数を修正することにより、レンダリング観察角度を決定する。
【０１３２】
前の例では、基準視野ベクトル（及び実際には他のパラメータ）が、一般には、望ましい又は好ましい特性／視野に対応するものと考えられた。そのため、レンダリング視野ベクトルは、基準視野ベクトルに向かうようにバイアスされる。しかし、他のシナリオ又は実施形態では、基準視野ベクトルは、望ましくない／好ましくないプロパティに対応してもよい。例えば、３Ｄ画像データがデータを提供しないシーンの部分にビューポート全体が対応するような視点（具体的には向き）を示す基準視野ベクトルが提供される。この場合、修正器１１１は、基準視野ベクトルから離れる方へのバイアスを適用することによってレンダリング視野ベクトルを生成するように構成される。
【０１３３】
例えば、基準視野ベクトルは、データが提供されないシーンの部分の中心に対する角度を示し、例えば、前に説明した特定の例では１８０°に向かう。そのような場合、レンダリング視野ベクトルは、目標視野ベクトルと基準視野ベクトルとの間の差が十分に大きい限り、目標視野ベクトルに対応するように生成される。例えば、基準角度と目標角度との間の角度差が７０°を超える限り、目標視野ベクトルがレンダリング視野ベクトルとしてそのまま使用される。しかし、差が７０°未満になると、一般には前に説明した手法と同様の非線形関数を使用して、レンダリング角度と目標角度との間の差が導入され始める。
【０１３４】
よって、いくつかの実施形態では、修正器１１１は、目標視野ベクトルから基準視野ベクトルまでの距離が減少するほど、レンダリング視野ベクトルから目標視野ベクトルまでの距離を増大させるように構成される。
【０１３５】
いくつかの実施形態では、修正器１１１は、レンダリング視野ベクトルから基準視野ベクトルまでの距離と、レンダリング視野ベクトルから目標視野ベクトルまでの距離との比を、目標視野ベクトルから基準視野ベクトルまでの距離が減少するほど減少させるように構成される。
【０１３６】
いくつかの実施形態では、修正器１１１は、目標視野ベクトルと基準視野ベクトルとの間の差が閾値を上回る場合、レンダリング視野ベクトルを実質的に目標視野ベクトルとして決定するように構成される。
【０１３７】
よって、いくつかの実施形態では、基準視野ベクトルは、目標視野ベクトルに対して、デトラクタ（detractor）（押しやる）として使用されるのに対し、他の実施形態ではアトラクタ（attractor）（引き寄せる）として使用される。
【０１３８】
多くの実施形態において、修正器１１１は、引き寄せる基準視野ベクトルと遠ざける基準視野ベクトルとの両方を同時に考慮することを含め、複数の異なる基準視野ベクトルを同時に考慮することが理解されよう。これは例えば、適切なエネルギー関数又はコスト関数を定義し、選択された指標を、勾配検索を使用して適宜最大化又は最小化することによって達成される。
【０１３９】
いくつかの実施形態では、仮想現実デバイスはさらに、他のタイプのフィードバックを提供する機能を備える。例えば、触覚フィードバックが、例えばゲームアプリケーションから知られる「力フィードバック」の形態で提供される。これは特に、目標視野ベクトルを修正する手法との関連で使用される。一例として、レンダリング視野ベクトルを生成するために目標視野ベクトルに導入される修正が大きいほど、力フィードバックが大きくなる。触覚フィードバックが方向の刺激を提供する実施形態では、これは、ユーザを望まれる方向に促す方向を有するように構成される。例えば、ジョイスティック及びレーシング・ホイールなどのコントローラを使用して、目標視野ベクトルに対する「引っ張り」の量及び方向の両方の印象が、力フィードバックの感覚によってユーザに伝達される。
【０１４０】
前述のように、画像生成器１０５は、一般に、３Ｄ画像データがデータを提供する画像の部分はレンダリングし、３Ｄ画像データがデータを全く提供しない画像の部分の中への外挿を行う、という２段階手法を使用して、画像を生成するように構成される。そのような手法に基づくレンダリングユニット２０３の一例が図３に例示される。
【０１４１】
この例では、画像データ受信器１０１及び視野ベクトルソース１０３はレンダラー３０１に結合され、レンダラー３０１は、レンダリング視野ベクトルによって表される所与のレンダリング視点について、画像データ受信器１０１が３Ｄ画像データを提供する画像の領域をレンダリングするように構成される。
【０１４２】
レンダラー３０１は、レンダリング視野ベクトルによって示されるレンダリング視点のための画像をレンダリングするために任意の適切な手法を使用してよく、当業者は様々な方法をよく認識しており、そのため、それらについては簡潔のために本明細書において詳細には説明しないことが理解されよう。
【０１４３】
一例として、異なる離散した視点について、３Ｄ画像データが光強度画像に加えて奥行きマップとして（又は例えばテクスチャマップ及び３Ｄメッシュにより）提供される場合、レンダリング視野ベクトルによって示される視点のための画像は、よく知られているように視点シフトによって生成される。３Ｄ画像データが３Ｄモデルの形態で提供される場合は、これを視点の観点から評価して画像コンテンツを生成する。
【０１４４】
しかし、３Ｄ画像データはシーンの不完全な表現しか提供しないため、（一部のレンダリング視点については）入手可能な３Ｄ画像データに直接基づいてはレンダリングできないいくつかの画像のエリアが生じる。例えば、ユーザが振り向き始めて、撮影されていないエリアの方を見た場合、レンダラー３０１は、撮影されているシーンの部分に対応する画像の部分のデータしか生成することができない。
【０１４５】
よって、多くの実施形態において、レンダラー３０１は画像の一部のみをレンダリングするように構成される。具体的には、レンダラー３０１は、画像の１つ又は複数の領域をレンダリングし、画像の他の領域は生成されない。以下では、レンダラー３０１が画像コンテンツをレンダリング／生成した領域を第１の領域と呼び、レンダラー３０１が画像コンテンツを全くレンダリング／生成していない境界領域を第２の領域と呼ぶ。
【０１４６】
第１及び第２の領域への参照は、画像コンテンツがレンダリングされている１つのエリアと、画像コンテンツがレンダリングされていない１つのエリアとに、画像が必ず分割されることを示唆するのではないことが理解されよう。そうではなく、レンダラー３０１が画像コンテンツを生成する複数の領域、及び／又はレンダラー３０１が画像コンテンツを生成しない複数の領域があってよい。それに代えて又はそれと等価に、第１の領域は、レンダラー３０１が画像コンテンツを生成した複数の個別のエリアを含む可能性があると考え、及び／又は第２の領域は、レンダラー３０１が画像コンテンツを生成していない複数の個別のエリアを含むと考えられてよい。
【０１４７】
図３のレンダリングユニット２０３は、そのような状況に対処するように構成される。レンダリングされていないエリア、すなわち第２の領域を単に空っぽのままにしておく、又はデフォルトの色で埋めるのではなく、レンダラー３０１は、第１の領域からの３Ｄ画像データを第２の領域の中へ外挿するように構成された外挿器３０３に結合される。よって、外挿器は、第１の領域の画像コンテンツ／３Ｄ画像データから第２の領域のための画像コンテンツを生成するように構成される。具体的には、大半の実施形態では、３Ｄ画像データは、第１の領域の画像コンテンツ（ピクセル値）が第２の領域の中へ外挿される外挿により、第１の領域から第２の領域の中へ外挿される。
【０１４８】
このようにして、画像生成器は続いて、レンダリング視野ベクトルによって表されるレンダリング視点について、ビューポートに対応する画像のすべての部分のための画像コンテンツを含む完全な画像を生成する。しかし、第１の領域のための画像コンテンツは、視野／シーンの非常に正確な反映／表現を提供する可能性が高いのに対し、第２の領域の画像コンテンツは、劣化した、そしてしばしば著しく劣化した視野／シーンの表現を提供する可能性が高い。例えば、多くの実施形態において、外挿器３０３は、比較的粗いテクスチャ、又は第１の領域の画像コンテンツの色分布を第２の領域に近づけて模した色分布を生成するようにのみ構成される。しかし、第２の領域の生成された画像コンテンツは、依然として、例えばあらかじめ決められた均一な色（例えば黒）よりも目立ちにくい、又は観察者にとって気障りでない可能性が高く、よって改良されたユーザ体験を提供する傾向がある。
【０１４９】
第１の領域の画像コンテンツを第２の領域の中へ外挿するための任意の適切な手法が本発明から逸脱することなく使用され得ることが理解されよう。外挿の具体例については後に説明する。
【０１５０】
しかし、図３のこの特定の例では、画像生成器１０５は、単に画像コンテンツを第２の領域の中へ外挿して、完全に埋められた画像を提供するのではなく、知覚的な効果を向上させ、一般には、結果として改良された、より没入性の高いユーザ体験を生じさせる事後処理をさらに含む。
【０１５１】
そうではなく、この特定の例では、画像生成器１０５は、外挿器３０３から画像を受け取る任意選択のぼかしプロセッサ３０５を備える。ぼかしプロセッサ３０５は、空間的に変動するぼかしを画像に適用するように構成され、ぼかしの度合いは、（少なくとも）第１の領域の内部エリアよりも、第１の領域と第２の領域との間の遷移領域の方が高い。よって、遷移領域には、画像の意図的なぼかしが導入される。多くの実施形態において、遷移領域は第１の領域のエリアを含み、よって、ぼかしプロセッサ３０５は、レンダラー３０１によって生成された画像コンテンツにぼかしを導入して、３Ｄ画像データから生成されることが可能な画像コンテンツから外挿された画像コンテンツへの、ぼかされた遷移を作り出す。
【０１５２】
この遷移領域のぼかしは、特により没入性の高い体験が達成され得る、大幅に改良されたユーザ体験を提供する傾向があることが判明している。観察者は、一般には、現在の視野が、３Ｄ画像データによって表されていないシーンの部分を含んでいることに気付かず、単に、ある方向を見たときに画像がぼけることに意識下で気付くのみである。この手法はさらに、観察者の行動を修正し、特に、３Ｄ画像データが入手可能でない方向を見ることから離れる方へユーザをバイアスする傾向がある。このバイアスはさらに、微妙なものであり、しばしば意識下にある傾向がある。特に、第１の領域の部分、すなわち、入手可能な３Ｄデータから生成される画像コンテンツに行われる空間的ぼかしは、結果として、ユーザによって検出されない微妙な効果をしばしば有するぼかしを生じさせる。しかし、依然として微妙なぼかし効果を提供し、一般には、ディテール及び焦点の欠如が、他の方向を見るように観察者をバイアスする。
【０１５３】
例えば、観察者が頭を回すと、観察者は、最初、入手可能な３Ｄ画像データから全体が生成された、したがって鮮明できめの細かい画像を見る。しかし、ある時点で、入手可能な３Ｄ画像データのエッジに到達し、観察者は、この場合、まず、まだディテールを含んでいる画像エリア（例えば３Ｄ画像データから導出された画像オブジェクトを含む）を提供され始めるが、これらは次第によりぼけた状態になり始める。この効果は、３Ｄ画像データから導出された生成画像の情報を意図的かつ直観に反するように除去することによって達成される。よって、可能な限り良好にシーンを表す画像を提供するのではなく、ぼかしプロセッサ３０５は、第１の領域と第２の領域との間の遷移領域を意図的にぼかし（具体的には、第１の領域の遷移領域の鮮明なレンダリングの一部をぼかし）、それにより、提示されるシーンの視野の精度を意図的に低下させる。しかし、この劣化は、この特定の場合における外挿の精度に完全に依存するのではなく、ぼかしプロセッサ３０５によって制御することができる。
【０１５４】
そのため、遷移の初期の要素が一般には依然として比較的高品質でありながら、３Ｄ画像データが完全な視野のためのデータを含む視点に向かうように観察者をバイアスする傾向があるという効果をもつ、より漸進的な遷移を達成することができる。この効果は、知覚的により良好なユーザ体験を提供し、特に仮想現実体験の場合に、より没入性の高い体験を提供する傾向があることが判明している。
【０１５５】
ぼかしは、例えば、具体的には空間ローパスフィルタなどのぼかしフィルタを使用して行われる。空間ローパスフィルタの強度は、第１の領域の内部エリアよりも、遷移領域の方が強くなるように変動させる。よって、ぼかし／ローパスフィルタリングの強度／度合いが遷移領域よりも小さい、第１の領域内の内部エリアが存在する。一般に、ぼかしプロセッサ３０５は、内部エリアのローパスフィルタリング又はぼかしは提供せず、したがって内部エリア（一般的には第１の領域の大部分に相当する）は、可能な限り鮮明にレンダリングされる。
【０１５６】
ぼかしの度合いは、例えば、空間ローパスフィルタの空間カットオフ周波数を変動させることによって変動させる。例えば、適切なカーネル形状が使用され、それと共に、現在のフィルタ位置及びそれがどのように遷移領域に関係するかに応じてカーネルの空間的広がりを変動させる。例えば、第１の領域の内部及び遷移領域の外側では、カーネルの空間的広がりは１ピクセルに設定されてよく、すなわち、フィルタリングが適用されない。遷移領域の内部では、カーネルの空間的広がりは、例えばあらかじめ決められた大きさまで増大され、それにより、結果として空間ローパスフィルタリング及びぼかしを生じさせる。
【０１５７】
多くの実施形態において、ぼかしは漸進的に増大される。例えば、カーネルの大きさは、遷移領域と第１の領域の残りの部分との間の境界／エッジにおける一般に小さい値から、遷移領域と第２の領域（の残りの部分）との間の境界におけるより大きい値へと漸進的に増大される。
【０１５８】
例えば、ぼかしフィルタは、ガウスカーネルをもつ空間フィルタであり、カーネルの大きさはそのシグマ値によって与えられる。そのような実施形態では、遷移領域内のピクセルについてガウスフィルタに適用されるシグマ値は、当該ピクセルから、遷移領域と第１の領域の残りの部分との間の境界までの距離の単調増加関数として、又は、当該ピクセルから、遷移領域と第２の領域の残りの部分との間の境界までの距離の単調減少関数（又はその両方）として決定される。
【０１５９】
そのような手法は、徐々に増大するぼかし及び漸進的な画像劣化を提供して、３Ｄ画像データが情報をわずかしか提供しないか又は提供しない視野から離れる方へのバイアスを引き起こす。
【０１６０】
第２の領域（又は具体的には、遷移領域が第２の領域の中まで及んでいる場合は遷移領域の外側にある第２の領域の部分）に適用されるフィルタリングは、特定の実施形態に依存し、実際、多くの実施形態において、例えば外挿及び／又は３Ｄ画像データの具体的特性に依存することが理解されよう。
【０１６１】
多くの実施形態において、ぼかしプロセッサ３０５は、第２の領域の少なくとも一部におけるぼかしの度合いを、遷移領域内のぼかしの度合いに対して低減するように構成される。よって、いくつかの実施形態では、遷移領域内のぼかしは、第１の領域の少なくとも一部と第２の領域の一部との両方よりも高い。ぼかしは、よって、第１の領域と第２の領域との間の遷移については増大されるが、その後、外挿された領域については再び低減される。これは、多くの実施形態、及び具体的には多くの外挿技術において、結果として、知覚的により有利な結果及び／又は低下した複雑性をもたらす。
【０１６２】
例えば、多くの外挿技術は、比較的ゆっくりと変動する変化を伴う、比較的粗い外挿を生成する。そのような場合、外挿の結果は、空間的に低い周波数特性をすでに示し、さらに画像コンテンツをぼかす、又はフィルタリングする必要はない。そのため、ぼかしプロセッサ３０５は、遷移領域だけにぼかしフィルタを適用し、それにより複雑性及び計算要件を低減するように構成される。
【０１６３】
ぼかしプロセッサ３０５は、そのため、レンダリングされた領域と外挿された領域との両方を含む生成された画像に、空間的に選択的なフィルタリングを適用する。ぼかし効果は、望まれる視野に向かうようにユーザをバイアスする傾向があるだけでなく、レンダリングされた領域と外挿された領域をさらに一緒に混合することにより、改良された効果を提供する傾向がある。
【０１６４】
図４は、図１の例に対応し、さらにぼかしのプロパティを決定するための特有の機能を備えたレンダリングユニットの特定の例を例示する。
【０１６５】
図４のレンダリングユニットは、画像のためのレンダリングマスクを決定するように構成されたレンダー領域プロセッサ４０１を備え、レンダリングマスクは、個々のピクセルが第１の領域に属するか否かを示す。具体的には、レンダリングマスクは、ピクセルごとに、そのピクセル値が、３Ｄ画像データからのレンダリングによって生成されるか、それとも外挿によって生成されるかを示す。
【０１６６】
多くの実施形態において、レンダリングマスクはバイナリ値を備え、すなわち、ピクセルごとに、レンダリングマスクは、そのピクセルがレンダリングによって生成されるか、それとも外挿によって生成されるか、又はそれと等価に、そのピクセルが第１の領域に属するか、それとも第２の領域に属するかを示す。いくつかの実施形態では、そのようなバイナリフィルタは、第１の領域と第２の領域との間の遷移領域を示す漸進的な値を用いて領域間の漸進的な遷移を生成するように、空間的ローパスフィルタにかけられる。
【０１６７】
レンダー領域プロセッサ４０１はフィルタアダプタ４０３に結合され、フィルタアダプタ４０３はさらにぼかしプロセッサ３０５に結合される。フィルタアダプタ４０３は、レンダリングマスクに応じて画像のための空間的に変動するフィルタ特性を決定するように構成される。例えば、ローパスフィルタリングの度合い／強度を制御するパラメータが、ピクセルのマスク値に基づいて決定される。例えば、フィルタリングされたレンダリングマスクに対して、ローパスフィルタリング強度パラメータ値は、ピクセルのレンダリングマスク値のあらかじめ決められた関数として決定される。よって、中間のレンダリングマスク値によって定義される遷移領域では、漸進的に変化するローパス度合いパラメータが定義される。
【０１６８】
空間的に変動するフィルタ特性は、次いでぼかしプロセッサ３０５に供給され、ぼかしプロセッサ３０５は続いて、この空間的に変動するフィルタ特性を採用した空間フィルタを使用して画像をフィルタリングする。
【０１６９】
この手法は、空間的に変動するフィルタを適用して、レンダリングされた画像コンテンツ及び外挿された画像コンテンツの空間的に選択的なぼかしを提供するための、特に効率的で現実的な方式を提供する。
【０１７０】
以下では、所与の望まれるレンダリング視点に関して所与のビューポートに適用されるこの手法の特定の例を説明する。よって、レンダリング視野ベクトルによって示される位置に視野の向きで位置している観察者のためのビューポートに対応する画像が生成されなければならない。そのような画像を生成する手法について、プロセスの一部として生成された画像、ビューポート、及びマスクの様々な例を示す図５〜図９を参照して説明する。
【０１７１】
最初に、レンダラー３０１は、３Ｄ画像データが情報を提供する画像／ビューポートの部分をレンダリングすることによって初期画像を生成することに進む。この例では、この結果生じる画像は、レンダラー３０１が３Ｄ画像データからのデータをレンダリングすることが可能な第１の領域５０１と、３Ｄ画像データがビューポートのこの部分に関するデータを含んでいないためにレンダラー３０１によって画像コンテンツ／データが生成されない第２の領域５０３とを含む。第２の領域５０３は、この特定の例では２つの個別のエリアを含むことが見て取れる。この例では、シーンの視野は、簡潔のために、暗い円形エリア５０７が前にある均質な背景５０５からなるものと考える（例えば、均質な青空の前にボールがあるというシーンに対応する）。
【０１７２】
外挿器３０３は、次いで、図５に示すように、第１の領域５０１から第２の領域５０３の中へ外挿して、完全に埋められたビューポート／画像を生成する。
【０１７３】
レンダー領域プロセッサ４０１は続いて、３Ｄ画像データがデータを提供する画像／ビューポートのエリアと、そうでない画像／ビューポートのエリアとを示すレンダリングマスクを生成する。よって、レンダリングマスクは、レンダラー３０１が画像コンテンツをレンダリングした所と、画像コンテンツが外挿器３０３によって生成された所とを示す。レンダリングマスクは、第１の領域及び第２の領域に対応する画像の部分を示し、図５の特定の場合についての例が図７に例示される。
【０１７４】
レンダリングマスクはフィルタアダプタ４０３に供給され、フィルタアダプタ４０３は続いて、レンダリングマスクからフィルタリング特性を生成する。具体的には、フィルタアダプタは、図７の鮮明なバイナリマスクをローパスフィルタリングすることによってそれを行う。この結果の一例が図８に提供され、ここでは、レンダラー３０１が画像コンテンツを生成したことを示す値と、外挿器３０３が画像コンテンツを生成したことを示す値との中間の値を含んでいる遷移領域が生成されることが見て取れる。よって、漸進的な遷移が遷移領域に提供される。
【０１７５】
フィルタアダプタ４０３は続いて、フィルタリングされたレンダリングマスク値に基づいて個々のピクセルのローパスフィルタ特性を決定する。例えば、ローパスフィルタリングの度合いは、係数値の関数として決定され、度合いは、ピクセルが外挿によって決定されることをマスク値が大きく示すほど増大する。例えば、フィルタリングされた係数値は、ガウスローパスフィルタのためのシグマパラメータ値のスケーリング後の値を提供するシグママップであると直接解釈される。
【０１７６】
よって、この特定の例では、第１の領域内にはフィルタリングが適用されず、高い度合いのローパスフィルタリングが第２の領域内に適用され、中間のフィルタリングが遷移領域内に適用される。
【０１７７】
いくつかの実施形態では、例えば第２の領域のフィルタリングを低減するように生成されたシグマ値に修正を加えるなど、フィルタ特性のより複雑な決定が適用される。
【０１７８】
最後に、ぼかしプロセッサ３０５は、決定されたフィルタ特性を使用して空間的フィルタリングを行う。フィルタリングは選択的に適用されてよく、例えば遷移領域にのみ適用される。
【０１７９】
このプロセスの結果、図９のような出力が生成される。画像は、レンダリングされた画像コンテンツと外挿された画像コンテンツとの組み合わせからなり、よって、外挿されたエリアは一般に低下した品質／ディテールであるものの、完全に埋められた画像／ビューポートを提供する。さらに、エリア９０１によって示されるように、異なる領域／エリアが一緒に混合される。
【０１８０】
前述のように、外挿を行うための任意の適切な手法が本発明から逸脱することなく使用され得る。
【０１８１】
例えば、隠蔽エリアのインペインティング（inpainting）と同様の手法が使用される。よって、当業者に知られているように、外挿は、例えば、方向性インペインティング（最も近いピクセルからの色値のコピー）、テクスチャ付けインペインティング（第１の領域と第２の領域との間のエッジにあるテクスチャを第２の領域の中へ外挿する）、及び／又はポアソン方程式の手法（エネルギー関数に基づくインペインティング）を使用する。
【０１８２】
シナリオによっては、外挿の目的に依然として有用であるビューポート／画像エリアのすぐ外側の画像コンテンツが存在し得る。そのため、直観に反して、レンダラー３０１は、いくつかの実施形態では、決定されたビューポートの（一般にはすぐ）外側にある画像エリアをレンダリングし、外挿は、ビューポートの外側のレンダリングされた画像コンテンツに応じたものとなる。例えば、方向性インペインティングを使用して、外挿対象のピクセルのピクセル値が、ビューポートの外側にあるピクセルであったとしても最も近いピクセルの値に設定される。
【０１８３】
いくつかの実施形態では、外挿器３０３は、第２の領域に近接した第１の領域の一部のエリアについて、ローパスフィルタリング後の画像プロパティを決定するように構成される。具体的には、第１の領域と第２の領域との間の境界に近い一部のエリアについて、外挿器３０３は、平均（average）（平均（mean））色値を決定する。外挿器３０３は続いて、これらの色値の１つ又は複数に一致するように、第２の領域のエリアのピクセル値を設定する。
【０１８４】
例えば、第２の領域のうち互いに素のエリアごとに、外挿器３０３は、当該互いに素のエリアと境界を接する第１の領域のエリアについてのすべての平均（mean）色値の平均（average）値として、色値を決定する。他の実施形態では、第１の領域が複数の部分エリアに分割され、各部分エリアは、平均（mean）値が決定されている第１の領域の所与のエリアに最も近いピクセルからなる。次いで、第２の領域の部分エリアが、この平均（mean）値に設定される。
【０１８５】
この手法は、非常に低い解像度の処理を利用する。例えば、第１の領域及び／又は第２の領域の各エリアは、１０３、１０４、１０５、又は１０６ピクセル以上からなる。そのため、この手法の結果、第２の領域の中への外挿は、一般には基本的に平均色値の反映に対応するシーンの非常に粗い表現を生成することになる。しかし、これは、多くのシナリオにおいて、許容可能な知覚を提供し、低複雑性の手法を提供する。
【０１８６】
いくつかの実施形態では、外挿は、レンダラー３０１によって生成された画像をダウンスケールしたバージョンのバイラテラル・フィルタリングに基づく。具体的には、外挿器３０３は、まず画像をダウンスケールするように構成される。一般に、このダウンスケールは重要であり、例えば１０４、１０５、又は１０６ピクセルを超えない解像度を有するフィルタ画像を生成する。次いで、バイラテラル・フィルタがこのダウンスケールされた画像に適用され、バイラテラル・フィルタは、レンダリングマスク（例えば元のバイナリ又はフィルタリングされたレンダリングマスク）によって誘導される。よって、空間的フィルタリングの重みは、レンダリングマスク値に、よって、重みが第１の領域に属するピクセルに対するものであるか、又は第２の領域に属するピクセルに対するものであるかに依存する。第１の領域に属するピクセルは、一般に、より高く重み付けされ、第２の領域に属するピクセルは、より低い重みを有する（多くの実施形態ではゼロの重み）。重みはさらに、一般に、重みが決定されるピクセルと、フィルタリングされた値が現在決定されるピクセルとの間の距離に依存する。
【０１８７】
その結果生じる、フィルタリングされ、ダウンスケールされた画像は、次いで元の解像度にアップスケールされ、その後レンダラー３０１からの画像と組み合わせられる。具体的には、第１の領域内のピクセルには、フィルタリングされてない画像のピクセル値が選択され、第２の領域内のピクセルには、バイラテラル・フィルタリングされた画像内のピクセル値が選択される。
【０１８８】
この手法は、多くのシナリオにおいて改良された外挿を提供する。特有の利益は、アップスケール動作のために外挿がすでに適切にぼかされていることである。
【０１８９】
いくつかの実施形態では、画像データ受信器１０１は、３Ｄ画像データをデータストリームで受け取るように構成される。例えば、データは、リモートのソースから、例えば、ネットワーク、具体的にはインターネットを介して、データストリームで受け取られる。別の例として、データストリームは、Ｂｌｕ−ｒａｙ（登録商標）ディスクリーダからなど、ローカルのソースから受け取られる。
【０１９０】
そのような例では、データストリームは、外挿制御データを含み得るメタデータを含み、外挿器３０３は、外挿制御データに応じて外挿を行うように構成される。
【０１９１】
例えば、外挿器３０３は、例えばディテール付きテクスチャインペインティング又は低カラー平均カラー（low color mean color）手法などの、種々の外挿アルゴリズムを行うことが可能である。３Ｄ画像データは、それらのうちどれを使用すべきかを定義した外挿制御データも含むデータストリームで受け取られる。
【０１９２】
この手法は、３Ｄ画像データのソースが画像をレンダリングする際に受け取り側の行動の何らかの態様を制御できるようにし、よって、ユーザ体験に対する追加的なコントロールを３Ｄ画像データの原作者に提供する。例えば、適切なメタデータを追加することによって監督の意図に一致する、明確に定義された外挿の使用を支援する標準化された手法が使用され得る。メタデータには、例えば以下がある。
・（事前定義された）外挿アルゴリズムを選択するためのメタデータ。
・事前定義された外挿アルゴリズムのパラメータを選択するためのメタデータ。
【０１９３】
具体例として、例えば、シェーダモデル４のファイルを含む別のＵＲＬを参照するＤＡＳＨ  ＸＭＬ  ＵＲＬなどの、外挿器を記述するメタデータが提供され、その外挿器は、レンダリングされたビューポートをダウンスケールしたバージョンと、レンダーマスク又はレンダーマスクを符号化する色キーを入力として有する。
【０１９４】
いくつかの実施形態では、図１の画像生成装置はさらに、（一般には）画像が画像生成器１０５によって生成された後に適合空間フィルタを画像に適用するように構成されたフィルタプロセッサを備える。そのような例では、空間フィルタは、画像全体に適用され画像全体について同じプロパティを有するグローバルフィルタであってよく、すなわち、プロパティは空間的に一様となる。
【０１９５】
しかし、空間フィルタは、視点／画像のうちどれほどが３Ｄ画像データに基づいてレンダリング可能であるかに依存するプロパティを有してもよく、すなわち、グローバル空間フィルタのプロパティは、３Ｄ画像が画像データを含まない視点の割合に依存する。この割合は、第１の領域の面積と第２の領域の面積との比として決定される。
【０１９６】
具体的には、フィルタは、第２の領域によってカバーされる画像の割合が増大するほど、強度が増大する。例えば、レンダラー３０１が画像コンテンツ全体を生成することができる状況には、フィルタ効果は小さい（又は実際にフィルタリングが行われない）。しかし、外挿によって埋められる必要のある画像の割合が増大するにつれて、フィルタリング効果は、漸進的に増大させることができ、結果として著しい知覚的な効果を生じさせる。
【０１９７】
よって、いくつかの実施形態では、画像／ビューポートのうち著しい部分に、３Ｄ画像データから直接生成されるコンテンツがないときに、グローバル画像フィルタが適用される。フィルタの強度は、外挿されたコンテンツがどれほど画像／ビューポートの中にあるかに応じて、漸進的に上又は下に変動させる。
【０１９８】
適切な画像フィルタの例には以下がある。
・飽和度の低減
・コントラストの低減
・輝度の低減
・空間ローパスフィルタ
・ホロデッキ（holodeck）や周囲フェンスなど別のシーンの重畳
・上記の組み合わせ
【０１９９】
この手法は、より極端な方向に向かうように知覚される視野に影響を与える、さらなる知覚的効果を可能にし、３Ｄ画像データが直接の情報を提供しないエリアから離れる方へ観察者の行動をバイアスするのを支援することができる。
【０２００】
上記の説明は、分かりやすさのために、種々の機能回路、ユニット、及びプロセッサを参照して実施形態を説明したことが理解されよう。しかし、種々の機能回路、ユニット、及びプロセッサ間における機能の任意の適切な分散が、本発明から逸脱することなく使用され得ることは明らかであろう。例えば、個別のプロセッサ又はコントローラによって行われるものと説明した機能が、同じプロセッサ又はコントローラによって行われてよい。したがって、特定の機能ユニット又は回路への参照は、厳密な論理又は物理的構造若しくは編成を示唆するのではなく、説明される機能を提供する適切な手段への参照としてのみ解釈すべきである。
【０２０１】
本発明は、ハードウェア、ソフトウェア、ファームウェア、又はそれらの任意の組み合わせを含む任意の適切な形態で実施することができる。本発明は、任意選択で、少なくとも部分的に、１つ又は複数のデータプロセッサ及び／又はデジタル信号プロセッサで実行されるコンピュータソフトウェアとして実施されてもよい。本発明の実施形態の要素及び構成要素は、物理的、機能的、及び論理的に、任意の適切な方式で実施される。実際、機能は、単一のユニット内、複数のユニット内に、又は他の機能ユニットの一部として実施される。そのため、本発明は、単一のユニット内に実施されるか、又は異なるユニット、回路、又はプロセッサ間に物理的及び機能的に分散される。
【０２０２】
本発明について、いくつかの実施形態との関連で説明したが、本明細書に述べられた特定の形態に制限されることは意図されない。むしろ、本発明の範囲は、添付の特許請求の範囲によってのみ制限される。また、特徴は、特定の実施形態との関連で説明されるように見えるかもしれないが、当業者であれば、説明される実施形態の様々な特徴は本発明に従って組み合わせ得ることを認識されよう。特許請求の範囲において、「有する」、「含む」という用語は、他の要素又はステップの存在を排除しない。
【０２０３】
さらに、個別に列挙されていても、複数の手段、要素、回路、又は方法のステップが、例えば単一の回路、ユニット、又はプロセッサによって実施されてよい。また、個々の特徴が異なる請求項に含まれることがあっても、それらは、可能性としては有利に組み合わせられ得、異なる請求項に含まれていることは、特徴の組み合わせが実現可能でない、及び／又は有利でないことを示唆するものではない。また、ある請求項カテゴリに特徴が含まれていることは、そのカテゴリへの制限を示唆するものではなく、その特徴が適宜他の請求項カテゴリにも等しく適用可能であることを意味する。さらに、請求項における特徴の順序は、それらの特徴を機能させなければならない特定の順序を示唆するものではなく、特に、方法クレームにおける個々のステップの順序は、それらのステップがその順序で行われなければならないことを示唆するものではない。むしろ、それらのステップは、任意の適切な順序で行われてよい。また、単数形の参照は複数形を排除しない。よって、単数形や、「第１の」、「第２の」等への参照は複数形を排除しない。特許請求の範囲における参照符号は、単に明確にするための例として提供されるものであり、特許請求の範囲をいかなる形でも制限するものとは解釈すべきでない。
【図１】
2020525927.tif 000004
【図２】
2020525927.tif 000005
【図３】
2020525927.tif 000006
【図４】
2020525927.tif 000007
【図５】
2020525927.tif 000008
【図６】
2020525927.tif 000009
【図７】
2020525927.tif 000010
【図８】
2020525927.tif 000011
【図９】
2020525927.tif 000012
【国際調査報告】
2020525927.tif 000013
2020525927.tif 000014