特許 7075950 画像を生成する装置および方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-05-18

(45)【発行日】2022-05-26

(54)【発明の名称】画像を生成する装置および方法

(51)【国際特許分類】

   G06T 15/00 20110101AFI20220519BHJP

   H04N 13/194 20180101ALI20220519BHJP

   H04N 13/117 20180101ALI20220519BHJP

   H04N 13/178 20180101ALI20220519BHJP

   H04N 13/122 20180101ALI20220519BHJP

   H04N 13/275 20180101ALI20220519BHJP

【ＦＩ】

G06T15/00 501

H04N13/194

H04N13/117

H04N13/178

H04N13/122

H04N13/275

【請求項の数】 15

(21)【出願番号】P 2019570128

(86)(22)【出願日】2018-06-21

(65)【公表番号】

(43)【公表日】2020-08-27

(86)【国際出願番号】 EP2018066511

(87)【国際公開番号】W WO2019002061

(87)【国際公開日】2019-01-03

【審査請求日】2021-04-22

(31)【優先権主張番号】17178669.2

(32)【優先日】2017-06-29

(33)【優先権主張国・地域又は機関】EP

(73)【特許権者】

【識別番号】590000248

【氏名又は名称】コーニンクレッカ フィリップス エヌ ヴェ

【氏名又は名称原語表記】Ｋｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｎ．Ｖ．

(74)【代理人】

【識別番号】100122769

【弁理士】

【氏名又は名称】笛田 秀仙

(74)【代理人】

【識別番号】100163809

【弁理士】

【氏名又は名称】五十嵐 貴裕

(74)【代理人】

【識別番号】100145654

【弁理士】

【氏名又は名称】矢ヶ部 喜行

(72)【発明者】

【氏名】クルーン バルト

(72)【発明者】

【氏名】デ ハーン ウィーベ

【審査官】村松 貴士

(56)【参考文献】

【文献】特表２０１４－５２４１８１（ＪＰ，Ａ）

【文献】特開２０１５－０１２４２９（ＪＰ，Ａ）

【文献】特開２００４－０７０７９３（ＪＰ，Ａ）

【文献】特開２０１４－０７２６３９（ＪＰ，Ａ）

【文献】特開２０００－２１５３１１（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｔ １５／００ － １９／２０

Ｈ０４Ｎ １３／００ － １３／３９８

(57)【特許請求の範囲】

【請求項1】

画像を生成するための装置であって、当該装置は、
シーンの3D画像データを受信する受信機であって、前記３Ｄ画像データは、少なくとも１つの視点に対する前記シーンの少なくとも一部の視覚特性の記述を提供しないという点で、前記シーンの不完全な表現を提供する、受信機と、
前記シーン内の第1の視点を示すレンダリングビューベクトルを提供するビューベクトルソースと、
前記3D画像データに基づいて第1画像の第1領域をレンダリングするためのレンダラーであって、前記第1画像は、前記レンダリングビューベクトルによって示される前記第1の視点のための画像であり、前記３Ｄ画像データが前記第１領域の画像データを含む、レンダラーと、
前記3D画像データを前記第1画像の第2領域に外挿するための外挿器であって、前記3D画像データは前記第2領域の画像データを含まず、前記第1領域と前記第2領域とは隣接する領域である、外挿器と、
前記画像を生成するためのぼかしプロセッサであって、前記画像の生成は、空間的に変化するぼかしを前記第1画像に適用することを含み、ぼかしの程度は、前記第１領域の内部領域よりも、前記第１領域と前記第２領域との間の遷移領域でより高い、ぼかしプロセッサと、
を有する装置。

【請求項2】

前記遷移領域が前記第1領域の領域を含む、請求項１に記載の装置。

【請求項3】

前記画像のためのレンダリングマスクを決定するレンダリング領域プロセッサであって、前記レンダリングマスクは、前記画像のピクセルが前記第1領域に属するか否か示す、レンダリング領域プロセッサと、
前記レンダリングマスクに応じて前記画像に対する空間的に変化するフィルタ特性を決定するフィルタアダプタと、
を有し、
前記ぼかしプロセッサが、前記空間的に変化するフィルタ特性を使用する空間フィルタを前記レンダリングされた画像に適用するように構成される、請求項１または請求項２に記載の装置。

【請求項4】

前記空間的に変化するフィルタ特性は、前記空間フィルタによるローパスフィルタリングの程度を示す、請求項３に記載の装置。

【請求項5】

前記外挿器が、
前記第1画像をダウンスケーリングすることに応じてダウンスケーリングされた画像を生成し、
前記レンダリングマスクによりガイドされる双方向フィルタを前記ダウンスケーリングされた画像に適用することに応じて、フィルタリングされたダウンスケーリングされた画像を生成し、
前記ダウンスケーリングされた画像をアップスケーリングすることに応じて、フィルタリングされたアップスケーリングされた画像を生成し、
前記フィルタリングされたアップスケーリングされた画像から前記第2領域のためのピクセル値を生成する、
ように構成される、請求項３または請求項４に記載の装置。

【請求項6】

前記ぼかしプロセッサが、あるピクセルに対するぼかしの程度を、当該ピクセルの位置から前記遷移領域の境界までの距離に応じて決定するように構成される、
請求項１から請求項５のいずれか一項に記載の装置。

【請求項7】

前記ぼかしプロセッサが、前記遷移領域におけるぼかしの程度に対して前記第2領域の少なくとも一部においてぼかしの程度を低減するように構成される、請求項１から請求項６のいずれか一項に記載の装置。

【請求項8】

前記画像の前記シーンにおけるターゲット視点を示すターゲットビューベクトルを受信する受信機と、
前記シーンの基準視点を示す基準ビューベクトルを提供する基準ソースと、
を有し、
前記ビューベクトルソースが、ユーザ所望の視点と前記シーンの前記基準視点との関数としてレンダリング視点を示す前記レンダリングビューベクトルを生成するように構成される、請求項１から請求項７のいずれか一項に記載の装置。

【請求項9】

前記ビューベクトルソースが、前記３D画像データが画像データを含む前記シーンの部分と前記３D画像データが画像データを含まない前記シーンの部分との間の境界を示す境界ビューベクトルに応じて前記基準ビューベクトルを決定するように構成される、請求項８に記載の装置。

【請求項10】

3D画像データを受信するための前記受信機が、前記３D画像データおよび名目上の視点データを有するデータストリームを受信するように構成され、前記ビューベクトルソースが、前記名目上の視点データに応じて前記基準ビューベクトルを生成するように構成される、請求項８または請求項９に記載の装置。

【請求項11】

前記外挿器が、前記第2領域に隣接する前記第1領域の複数のエリアに対するローパスフィルタリングされた画像の特性を決定し、前記ローパスフィルタリングされた画像の特性に応じて前記第2領域の少なくとも一部に対する画像特性を設定するように構成される、請求項１から請求項１０のいずれか一項に記載の装置。

【請求項12】

前記受信機が、外挿制御データを有するデータストリームで前記３D画像データを受信するように構成され、前記外挿器が、前記外挿制御データに応じて外挿のパラメータを設定するように構成される、請求項１から請求項１１のいずれか一項に記載の装置。

【請求項13】

前記画像にグローバル空間フィルタを適用するように構成されるフィルタプロセッサを有し、前記空間フィルタの特性が、前記３D画像データが画像データを有さない前記画像の割合に依存する、請求項１から請求項１２のいずれか一項に記載の装置。

【請求項14】

画像を生成する方法であって、
シーンの3D画像データを受信するステップであって、前記３Ｄ画像データは、少なくとも１つの視点の前記シーンの少なくとも一部の視覚特性の記述を提供しないという点で、前記シーンの不完全な表現を提供する、ステップと、
前記シーン内の第1の視点を示すレンダリングビューベクトルを提供するステップと、
前記3D画像データに基づいて第1画像の第1領域をレンダリングするステップであって、前記第1画像は前記レンダリングビューベクトルによって示される前記第1の視点のための画像であり、前記３Ｄ画像データが前記第１領域の画像データを含む、ステップと、
前記3D画像データを前記第1画像の第2領域に外挿するステップであって、前記３Ｄ画像データは前記第２領域の画像データを含まず、前記第１領域と前記第２領域とは隣接する領域である、ステップと、
空間的に変化するぼかしを第1画像に適用することを含む、前記画像を生成するステップであって、ぼかしの程度は、前記第１領域の内部領域よりも、前記第１領域と前記第２領域との間の遷移領域でより高い、ステップと、
を有する方法。

【請求項15】

コンピュータにより実行されて、前記コンピュータに請求項１４に記載のステップを実行させる、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、シーンの不完全な表現を提供する３Ｄ画像データから画像を生成するための装置および方法に関し、特に、仮想現実アプリケーション用の画像を生成することに関する(但し、それに限定されない)。

【背景技術】

【0002】

従来、画像の技術的な処理と使用は2次元イメージングに基づいていたが、画像処理において3番目の次元が明示的に考慮されることが増えている。

【0003】

たとえば、視聴者の2つの目に見ているシーンの異なるビューを提供することで、視聴体験に3番目の次元を追加する三次元（3D）ディスプレイが開発されている。これは、ユーザにメガネをかけて表示される2つのビューを分離させることで実現できる。しかしながら、これはユーザにとって不便と見なされる可能性があるため、多くのシナリオでは、ディスプレイの手段（レンチキュラーレンズ、バリアなど）を使用してビューを分離し、それらがユーザの目に個別に到達する異なる方向にそれらを送る自動立体視ディスプレイを使用することが好ましい。ステレオディスプレイの場合には2つのビューが必要であるが、自動立体視ディスプレイでは通常さらに多くのビュー（9ビューなど）が必要である。

【0004】

多くの実施形態では、新しい観察方向のビュー画像を生成することが望ましい場合がある。画像および深度情報に基づいてそのような新しいビュー画像を生成するためのさまざまなアルゴリズムが知られているが、それらは提供された（または導出された）深度情報の精度に大きく依存する傾向がある。

【0005】

実際、三次元画像情報は、シーンの異なる観察方向に対応する複数の画像によってしばしば提供される。特に、映画やテレビ番組などのビデオコンテンツは、ますます3D情報を含むように生成されている。このような情報は、わずかにオフセットしたカメラ位置から2つの同時画像を取得する専用の3Dカメラを使用して取得できる。

【0006】

ただし、多くのアプリケーションでは、提供された画像が所望の方向に直接対応していない場合や、更なる画像が必要な場合がある。たとえば、自動立体視ディスプレイの場合、3つ以上の画像が必要であり、実際には多くの場合9～26枚のビュー画像が使用される。

【0007】

異なる視点方向に対応する画像を生成するために、視点シフト処理を採用してもよい。これは通常、単一のビュー方向の画像と関連する深度情報を使用するビューシフトアルゴリズムによって実行される。

【0008】

三次元画像処理に基づくアプリケーションの特定の例は、仮想現実アプリケーションである。典型的な仮想現実体験では、例えば、ユーザによる動きおよび向きの変化に合わせるように仮想現実ヘッドセットのために右目および左目ビュー画像が連続的に生成される。このような動的な仮想現実ビューの生成は、通常、仮想現実環境に対応する特定のシーンを表す3D画像データの処理に基づいている。たとえば、仮想現実サーバーが、三次元モデル、または光強度画像と深度マップ、すなわちテクスチャマップと深度メッシュで表される画像などの三次元画像に基づいて、特定のビューのビュー画像を生成できる。

【0009】

仮想現実アプリケーションなどのアプリケーションでは、ユーザが仮想環境で仮想的に移動またはビューの方向/方位を変更することにより、これらの変化としてユーザのビューを反映する一連の画像が生成される場合がある。一部のアプリケーションでは、領域内の動きをサポートせずに、観察者の向きの変化を反映するように画像が生成される場合がある。このようなシナリオを反映したビデオは、しばしば全方向ビデオと呼ばれる。他のアプリケーションでは、仮想現実環境でのユーザの仮想的な動きを反映するために、移動する観察位置もサポートされる場合がある。このようなシナリオを反映したビデオは、没入型ビデオと呼ばれることがある。ユーザの現在のビューは、ビューポイントに関連する位置と方向のパラメータを記述するビューベクトルで表されることができる。

【0010】

全方向ビデオの場合、ビューベクトルは通常、ヨー、ピッチおよびロールの値を提供することにより、3自由度（3DoF）に従って方向を表す。

【0011】

没入型ビデオの場合、ベクトルは通常、ヨー、ピッチ、ロール、および3つの空間次元の値を提供することにより、6自由度（6DoF）に従って方向と位置の両方を表す。

【0012】

ただし、可変のビューの位置および/または方向をサポートする柔軟なビデオおよび画像アプリケーションを開発およびサポートしようとする際の特定の課題は、これらが好ましくは位置および/または方向のサブセットに限定されず、すべての位置および/または方向が理想的にサポートされることである。たとえば、6DoFの没入型ビデオの場合、観察者はあらゆる位置およびあらゆる方向からシーンを見ることができる。これには、シーンのすべての部分、すべての位置、すべての方向で3D情報が利用可能である必要がある。この要件は、特に3Dデータが実世界のシーンのキャプチャに基づいているアプリケーションなど、多くの実用的なアプリケーションで満たすのが困難または不可能である。

【0013】

たとえば、映画の場合、監督は撮影クルーと設備を視界から隠すのに細心の注意を払っている。1つのアプローチは、180°フィルムグラマールールと呼ばれるもので、カメラはシーンの片側に配置され、もう一方の側を向いている。全方向性ビデオの録画は、各全方向カメラの周囲のシーン全体が見えるため、はるかに困難である。このため、たとえば、クルーは風景の後ろに隠れ、後処理で三脚などの要素を消去する必要がある。

【0014】

実際には、全範囲が必要で潜在的に利用される可能性のあるシーンであっても、しばしば優先される方向がある。通常、観察者が180°向きを変えるのは理にかなっていないため、この視点に対応する画像データを記録、保存または送信するために必要なリソースを消費することは一般的に実用的ではない。

【0015】

ただし、これによりコンテンツが欠落し、シーンの表現が不完全になるという問題が生じる。したがって、観察者が実際に180°向きを変えると、適切なビューを生成することを可能にするデータが利用できず、カバレッジが制限される。そのような場合、明白なアプローチは、3D画像表現によってデータが提供されない場合、画像情報をレンダリングしないか、あるいは、たとえばデフォルトのテクスチャを提示することもできる。ただし、これは知覚的に非常に目立ってしまい、ユーザを混乱させ、例えば仮想現実アプリケーションにとって非常に重要な没入型体験を中断する傾向がある。

【0016】

この問題を回避するために、動的に評価されて、必要とされるビューを生成するために使用される完全な三次元コンピューターグラフィックスモデルを生成する必要があると一般に考えられている。ただし、これは非現実的であり、非常に複雑で、多くのリソースを必要とし、過剰なキャプチャとモデル変換などを必要とする。

【0017】

したがって、三次元画像データから画像を生成するための改善されたアプローチが有利であろう。特に、操作の改善、柔軟性の向上、実装の容易化、操作の容易化、通信の改善、複雑さの軽減、リソース需要の削減、没入型ユーザ体験の改善、および/またはパフォーマンスの改善を可能にするアプローチが有利である。

【発明の概要】

【発明が解決しようとする課題】

【0018】

したがって、本発明は、好ましくは、上記の欠点の１つまたは複数を単独でまたは任意の組み合わせで緩和、軽減、または排除しようとするものである。

【課題を解決するための手段】

【0019】

本発明の一態様によれば、画像を生成する装置が提供され、当該装置は、
シーンの3D画像データを受信する受信機であって、前記３Ｄ画像データは、少なくとも１つの視点に対する前記シーンの少なくとも一部の視覚特性の記述を提供しないという点で、前記シーンの不完全な表現を提供する、受信機と、前記シーン内の第1の視点を示すレンダリングビューベクトルを提供するためのビューベクトルソースと、前記3D画像データに基づいて第1画像の第1領域をレンダリングするためのレンダラーであって、前記第1画像は、前記レンダリングビューベクトルによって示される前記第1の視点用であり、前記３Ｄ画像データが前記第１領域の画像データを含む、レンダラーと、前記3D画像データを前記第1画像の第2領域に外挿するための外挿器であって、前記3D画像データには、前記第2領域の画像データは含まれず、前記第1領域と前記第2領域とは隣接する領域である、外挿器と、画像を生成するためのぼかしプロセッサであって、前記画像の生成は、空間的に変化するぼかしを前記第1画像に適用することを含み、ぼかしの程度は、前記第１領域の内部領域よりも、前記第１領域と前記第２領域との間の遷移領域でより高い、ぼかしプロセッサと、を有する。

【0020】

本発明は、多くの実施形態およびシナリオにおいて、改善された画像の生成を可能にし得る。特に、3D画像データが画像データを提供しない1つ以上の領域を生成された画像が含む場合でも、改善された知覚画像品質が達成され得る。特に、外挿に通常関連する劣化効果は大幅に減少され、多くのシナリオではユーザは気付かないだろう。

【0021】

遷移領域のぼやけは、特に知覚的影響を減らすことができる。さらに、レンダリング視点がユーザ入力によって決定される実施形態では、このアプローチ、特にぼかしは、大きな程度の外挿が必要な視点からユーザを遠ざけることができる。

【0022】

このアプローチは、特に、ユーザ入力に応じてレンダリング視点が生成および制御されるシナリオのための画像の有利な生成を提供し得る。たとえば、このアプローチは、仮想現実アプリケーションにビュー画像を提供する（たとえば、仮想現実ヘッドセットに画像を提供する）のに非常に適している。このアプローチは、シーンの不完全な表現しか3D画像データによって提供されないことの影響を軽減しながら、高い自由度を可能にする。

【0023】

さらに、このアプローチは、3D画像データからのデータの不足のために品質を実質的に低下させる傾向がある視点から離れるように仮想現実アプリケーションを制御するようにユーザをバイアスすることができる。

【0024】

このアプローチは、多くの実施形態およびシナリオにおいて、基礎となるシーンの完全な表現を必要とせずに満足のいく画像の生成を提供し得る。このアプローチは、シーンの不完全な表現に起因する不便さを軽減し、したがって、不完全なモデルまたはキャプチャの使用を可能にすることができる。特に、このアプローチは、通常、例えば3Dカメラを使用した現実世界のシーンのキャプチャに基づいたアプリケーションのサポートを改善する。

【0025】

ビューベクトルは、視点を示す任意の値または値のセットである。視点は、ビュー/ビューポートの位置および/または方向である。ビューベクトルは、例えば、視点の位置を示す1つまたは複数の値および/または視点のビューの向きを示す1つまたは複数の値を含むことができる。

【0026】

３Ｄ画像データは、シーンの（視覚／光強度）ビューを表すように画像コンテンツが生成されることを可能にする任意のデータを含んでもよい。例えば、３Ｄ画像データは、システムがビューを生成できるようにするシーンの３Ｄモデルを含むことができる。多くの実施形態では、３Ｄ画像データは、１つ以上の３Ｄ画像を含み、各３Ｄ画像は、画像＋深度またはテクスチャマップ＋メッシュ表現などの、光強度および深度情報を提供し得る。 多くの実施形態では、３Ｄ画像データは広視野角画像を含むことができ、特にほぼ全方向の画像を含めることができる。

【0027】

３Ｄ画像データは、シーンの不完全な表現を提供し、したがって、３Ｄ画像データが少なくとも１つの視点の視覚特性の記述を提供しないシーンの少なくとも一部が存在する。3D画像データで記述されていないシーンの部分は、視点が異なると異なる場合がある。少なくとも1つのビュー位置に対して、3D画像データに視覚特性の（個々の）記述が含まれない少なくとも1つの部分を対応するビューポートが含む少なくとも1つのビュー方向がある。そのような部分については、画像コンテンツは通常、具体的には、3D画像データが画像データを提供する（第1領域などの）或る領域から、3D画像データが画像データを提供しない或る領域（第2領域）への外挿によって、シーンの他の部分の3D画像データから生成される。

【0028】

したがって、通常、シーンのそのような部分については、（通常は、たとえば、異なる領域に属する画像コンテンツに変化が生じないなど、比較的不正確である傾向がある仮定を使用して）画像コンテンツをシーンの他の部分から生成する必要がある。

【0029】

シーンは、例えば、特定の時間における特定の位置からの環境のビューの3D表現などの、基礎となる3D環境の特定の部分またはビューの特定の表現であり得る場合によっては、環境または世界の3Dモデルなど、基礎となる3D環境全体である場合がある。したがって、シーンは、ビューを表すために画像が生成される環境であると見なすことができる。

【0030】

外挿器は通常、第1領域に対して生成された画像コンテンツ（特にピクセル値）を第2領域に外挿することにより、3D画像データを第2領域に外挿するように構成される。したがって、通常、第1領域のレンダリングされた画像コンテンツが第2領域に外挿される。

【0031】

第１および／または第２領域は、複数のばらばらの領域を備えてもよい。

【0032】

本発明の任意の特徴によれば、遷移領域は第１領域の領域を含む。

【0033】

これは、多くのシナリオで特に有利な動作を提供する。例えば、多くの実施形態において、3D画像データがデータを含まないシーンの領域から離れるバイアスを導入する一方で、依然として高画質を維持することができる。

【0034】

本発明の任意の特徴によれば、装置はさらに、画像のレンダリングマスクを決定するためのレンダリング領域プロセッサであって、前記レンダリングマスクは画像のピクセルが第1領域に属するかどうかを示す、レンダリング領域プロセッサと、前記レンダリングマスクに応じて、画像に対して空間的に変化するフィルタ特性を決定するフィルタアダプタと、を有し、前記ぼかしプロセッサは、空間的に変化するフィルタ特性を採用した空間フィルタをレンダリングされた画像に適用するように配置される。

【0035】

これは、多くの実施形態において特に効率的および/または有利な動作および/または実装を提供し得る。

【0036】

空間的に変化するフィルタ特性は、遷移領域では、第1領域（のその他の部分）とは異なる場合がある。空間的に変化するフィルタ特性は、遷移領域では、第2領域（のその他の部分）とは異なる場合がある。

【0037】

本発明の任意の特徴によれば、空間的に変化するフィルタ特性は、空間フィルタによるローパスフィルタリングの程度を示す。

【0038】

これは、多くの実施形態において特に効率的および/または有利な動作および/または実装を提供し得る。空間的に変化するフィルタ特性は、具体的には、空間ローパスフィルタのフィルタカーネルのサイズなど、ローパスフィルタリングの程度であってもよい。

【0039】

本発明の任意の特徴によれば、外挿器は、中間画像のダウンスケーリングに応じてダウンスケーリングされた画像を生成し、レンダリングマスクによってガイドされる双方向フィルタをダウンスケーリングされた画像に適用することに応じてフィルタリングされたダウンスケーリングされた画像を生成し、ダウンスケーリングされた画像のアップスケーリングに応じてフィルタリングされたアップスケーリングされた画像を生成し、フィルタリングされたアップスケーリングされた画像から第2領域のピクセル値を生成するように構成される。

【0040】

これにより、特定のアプローチに対して特に有利な外挿が可能になる。

【0041】

本発明の任意の特徴によれば、ぼかしプロセッサは、ピクセルの位置から遷移領域の境界までの距離に応じてピクセルのぼかしの程度を決定するように構成される。

【0042】

これは、多くの実施形態において有利な性能および/または改善された動作および/または実装を提供し得る。

【0043】

ピクセルのぼかしの程度（通常はローパスフィルタリングの程度）は、遷移領域内で、遷移領域と第1領域の間でエッジまでの距離とともに増加することができ、および/または、遷移領域内で、遷移領域と第2領域の間でエッジまでの距離とともに減少することができる。

【0044】

本発明の任意選択の特徴によれば、ぼかしプロセッサは、遷移領域のぼかしの程度に対して第２領域の少なくとも一部のぼかしの程度を低減するように構成される。

【0045】

これにより、多くの実施形態で動作の改善が可能になり、具体的には多くのシナリオで計算リソース要件が削減される。

【0046】

本発明の任意の特徴によれば、装置はさらに、画像のシーン内のターゲット視点を示すターゲットビューベクトルを受信する受信機と、シーンの基準視点を示す基準ビューベクトルを提供する基準ソースとを有し、前記ビューベクトルソースは、ユーザの所望の視点とシーンの基準視点の関数としてレンダリング視点を示すレンダリングビューベクトルを生成するように構成される。

【0047】

このアプローチは、多くの実施形態およびシナリオにおいて、改善された画像の生成を可能にし得る。特に、所望の視点から所望のビューを提供することと、高品質の画像を提供することとの間の改善されたトレードオフが達成され得る。このアプローチは、例えば、画像品質がより高くなり得る好ましいビューに向かってビューの穏やかなバイアスを提供し得る。

【0048】

このアプローチは、例えば、ユーザが視点を制御できる仮想現実体験を可能にし得るが、これらは改善された品質を提供する視点にバイアスされる。たとえば、3D画像データからビューを生成できる限り、生成されたビューの視点をユーザが自由に制御できるという効果が得られる。ただし、3D画像データがデータを提供しない視点に向けられた場合、システムは抵抗して、この動きに対抗するバイアスをする場合がある。これは、多くの状況で、微妙でしばしば知覚できないほどの適応をもたらし、ユーザの行動を変更する可能性がある。

【0049】

このアプローチは、特に、ユーザ入力に応じてターゲットビューベクトルが生成および制御されるシナリオのための画像の有利な生成を提供し得る。たとえば、このアプローチは、仮想現実アプリケーションのためのビュー画像を提供する（たとえば、仮想現実ヘッドセットに画像を提供する）のに非常に適している。このアプローチは、シーンの不完全な表現しか3D画像データによって提供されないことによる影響を軽減しながら、高い自由度を可能にする。

【0050】

さらに、このアプローチは、3D画像データからのデータの欠如のために品質を実質的に低下させる傾向がある視点から離れるように仮想現実アプリケーションを制御するようにユーザをバイアスすることができる。

【0051】

本発明の任意の特徴によれば、ビューベクトルソースは、３Ｄ画像データが画像データを含むシーンの部分と３Ｄ画像データが画像データを含まないシーンの部分との間の境界を示す境界ビューベクトルに応じて基準ビューベクトルを決定するように構成される。

【0052】

これは、多くのシナリオで特に有利な動作および/または性能を提供する。例えば、多くの実施形態において、3D画像データがデータを含まないシーンの領域から離れるバイアスを導入する一方で、依然として高画質を維持することができる。特に、多くの場合、この容認できないほど制限された自由度と、台無しにされた没入感の中で、高品質のビューに向けて望ましいバイアスを提供することができる。

【0053】

本発明の任意の特徴によれば、３Ｄ画像データを受信するための受信機は、３Ｄ画像データを含み、名目上の視点データをさらに含むデータストリームを受信するようにさらに構成され、ビューベクトルソースは、名目上の視点データに応じて基準ビューベクトルを生成するように構成される。

【0054】

これは、多くのシナリオで特に有利な動作および/または性能を提供する。例えば、多くの実施形態において、3D画像データがデータを含まないシーンの領域から離れるバイアスを導入する一方で、依然として高画質を維持することができる特に、多くの場合、この容認できないほど制限された自由度と、台無しにされた没入感の中で、高品質のビューに向けて望ましいバイアスを提供することができる。

【0055】

このアプローチは、特に、コンテンツ提供者が所望の視点へのバイアスを支援、案内および/または制御することを可能にし得る。たとえば、「ディレクタ」ビューは、推奨または提案された視点として提供される。

【0056】

本発明の任意の特徴によれば、外挿器は、第2領域に近接する第1領域の複数の領域のローパスフィルタリングされた画像特性を決定し、ローパスフィルタリングされた画像特性に応じて第2領域の少なくとも一部の画像特性を設定するように構成される。

【0057】

これにより、特定のアプローチに対して特に有利な外挿が可能になる。

【0058】

本発明の任意の特徴によれば、受信機は、外挿制御データをさらに含むデータストリームで3D画像データを受信するように構成され、外挿器は、この外挿制御データに応じて外挿のパラメータを設定するように構成される。

【0059】

これにより、特定のアプローチに対して特に有利な外挿が可能になる。

【0060】

本発明の任意の特徴によれば、装置は、画像にグローバルな空間フィルタを適用するように構成されたフィルタプロセッサをさらに備え、この空間フィルタの特性は、3D画像が画像データを含まない画像の割合に依存する。

【0061】

これにより、利用可能な3D画像データの特定の特性により良く適合した改善された画像を生成することができる。

【0062】

本発明の一態様によれば、画像を生成する方法が提供され、当該方法は、シーンの3D画像データを受信するステップであって、前記３Ｄ画像データは、少なくとも１つの視点のシーンの少なくとも一部の視覚特性の記述を提供しないという点で、シーンの不完全な表現を提供する、ステップと、シーン内の第1の視点を示すレンダリングビューベクトルを提供するステップと、3D画像データに基づいて、第1画像の第1領域をレンダリングするステップであって、第1画像はレンダリングビューベクトルによって示される第1の視点のための画像であり、前記３Ｄ画像データが前記第１領域の画像データを含む、ステップと、前記3D画像データを第1画像の第2領域に外挿するステップであって、前記３Ｄ画像データは前記第２領域の画像データを含まず、第１領域および第２領域は隣接する領域である、ステップと、画像を生成するステップであって、空間的に変化するぼかしを第1画像に適用することを含む、ステップとを有し、ぼかしの程度は、第１領域の内部領域よりも、第１領域と第２領域との間の遷移領域でより高い。

【0063】

本発明のこれらおよび他の態様、特徴、および利点は、以下に説明する実施形態を参照して明らかになり、説明される。

【図面の簡単な説明】

【0064】

本発明の実施形態は、図面を参照して、単なる一例として説明される。

【図1】本発明のいくつかの実施形態による画像生成装置の例を示す図。

【図2】本発明のいくつかの実施形態による画像生成装置を含む仮想現実デバイスの例を示す図。

【図3】本発明のいくつかの実施形態による画像生成装置の例を示す図である。

【図4】本発明のいくつかの実施形態による例示的な画像生成装置によって生成された画像およびマスクの例を示す図。

【図5】本発明のいくつかの実施形態による例示的な画像生成装置によって生成された画像およびマスクの例を示す図。

【図6】本発明のいくつかの実施形態による例示的な画像生成装置によって生成された画像およびマスクの例を示す図。

【図7】本発明のいくつかの実施形態による例示的な画像生成装置によって生成された画像およびマスクの例を示す図。

【図8】本発明のいくつかの実施形態による例示的な画像生成装置によって生成された画像およびマスクの例を示す図。

【図9】本発明のいくつかの実施形態による画像生成装置の例を示す図。

【発明を実施するための形態】

【0065】

以下の説明は、仮想現実アプリケーション用の画像の生成に適用可能な本発明の実施形態に焦点を当てている。しかし、本発明はこの用途に限定されるものではなく、多くの異なる画像の処理および生成の用途に適用できることを理解されたい。

【0066】

図１は、シーンの不完全な表現を提供する３Ｄ画像データに基づいてシーンのビューを表す画像を生成するように構成された画像生成装置を示している。図１の画像生成装置は、具体的には、仮想現実体験を提供する仮想現実デバイスまたはサーバーの一部として使用されるレンダラーであってもよい。

【0067】

このような仮想現実デバイスの例を図2に示す。この例では、仮想現実デバイスは、仮想現実シーンにおける所望の動きおよび／または向きを反映し得るユーザ入力を受信するように構成されたユーザ入力ユニット201を備える。たとえば、ユーザは、ジョイスティックおよび/またはキーボードを使用して仮想現実シーンをナビゲートするか、たとえば、ビューの向きを、ユーザが装着し適切なセンサーを備えた仮想現実ヘッドセットから決定することができる。多くの実施形態では、ユーザ入力ユニット２０１は、ユーザ入力を、シーンが観察される位置および／または所与の観察位置からのビューの向きを示す所望のレンダリング視点に変換する機能を備えてもよい。レンダリング視点は、位置指示、方向指示、またはその両方を指すと見なされる場合があり、したがって、ユーザにとって望ましいビューを示す。

【0068】

いくつかの実施形態では、所与のレンダリング視点に対して複数のビューが生成され得るか、またはいくつかの実施形態では、同じユーザ入力から複数の視点が生成され得ることが理解されよう。例えば、仮想現実デバイスは、右目ビューに対応する画像および左目ビューに対応する画像を生成するように構成され、それにより3D効果を提供することができる。簡潔さと明確さのために、以下の説明は、所与のレンダリング視点のための1つのイメージの生成に焦点をあてる。

【0069】

ユーザ入力ユニット２０１は、具体的には、所望の／ターゲットレンダリング視点を示すターゲットビューベクトルを生成するように構成され得る。例えば、観察者の向きを定義する３つの成分／値、例えばピッチ、ヨーおよびロールパラメータを含むターゲットビューベクトルが生成され得る。多くの実施形態では、ターゲットビューベクトルは、追加的または代替的に、例えばｘ、ｙ、ｚ値によって表される、シーン内の３次元位置を定義する３つの値を含むことができる。いくつかの実施形態では、位置および／または向きは、３つ未満の値によって表され得ることが理解されよう。例えば、位置は、シーンを通る所定のルートに沿った距離によって示される場合があり、したがって、位置は単一の値によって示される場合がある。同様に、ピッチとヨーは一定であると想定され、方向はロール値のみで与えられることができる。

【0070】

生成されたターゲットビューベクトルは、具体的には図１の画像生成装置であるレンダリングユニット２０３に供給される。レンダリングユニット２０３は、ビューベクトルによって反映される視点の画像を生成するように構成される。画像の生成は、3D画像ストア205から取得された3D画像データに依存する。生成された画像は、例えば右目用または左目用の仮想現実ヘッドセットのディスプレイであり得るディスプレイ209を駆動するディスプレイドライバ207に供給される。仮想現実ヘッドセットは、ユーザ入力ユニット201へのユーザ入力を提供するセンサーをさらに備えてもよい。

【0071】

したがって、仮想現実デバイスは、３Ｄ画像データによって表される仮想シーン内の特定の視点からのビューを表す画像を生成し得る。視点はユーザ入力によって制御され、ユーザは、典型的には、仮想シーン内を移動したり見回したりすることができる。

【0072】

このアプローチでは、3D画像データはシーンの不完全な表現を提供する。3D画像データは、シーンのすべての部分ではなく、シーンのいくつかの部分のデータを具体的に提供する場合があり、すなわち、特に、少なくともいくつかの視点の3D画像データがシーンの視覚特性を記述するデータを含まないシーンのいくつかの領域/部分/要素があり得る。

【0073】

多くの仮想現実アプリケーションでは、3D画像データはシーンの3Dモデルの形式で提供される。 多くのアプリケーションでは、このような3Dモデルはシーンの完全な表現を提供する場合があり、3Dモデルを評価すると、考えられるすべての視点のビュー画像を生成できる。 この状況は、多くの場合、モデルが環境とシーンを直接定義する仮想シーンまたは人工シーンの場合である。ただし、多くの場合、完全なモデルを生成することは不可能または実行不可能である。これは一部の人工モデルの場合に当てはまるが、実際のシーンをキャプチャした表現ではより頻繁に発生する。たとえば、実世界のシーンのキャプチャからモデルを生成できるが、このモデルには、少なくとも一部の視点（位置および/または方向）のデータが欠落する傾向がある。

【0074】

多くの実施形態では、３Ｄ画像データは、適切なカメラを使用して実生活データからのキャプチャから生成されることができる。実際、典型的には、3D画像データは、多数の固定観察位置の光強度画像および関連する深度情報の形で提供される。 そのような例では、画像は非常に広い視野角に対応する場合があり、実際には、状況によってはほぼ完全に全方向性になる場合がある。そのような状況では、3D画像データの画像と深度を視点シフトアルゴリズムで使用して、所与のレンダリング視点のビュー画像を生成できる。

【0075】

ただし、通常、特定の視点からのキャプチャは完全ではなく、完全な球面画像（および深度）と深度を提供せず、球面のサブセットのみがキャプチャされる。これは通常、全天球キャプチャデバイスが使用される状況でも当てはまる。これは、キャプチャプロセスが本質的に、シーンの一部のビューをブロックするオブジェクト（たとえば、クルー、照明器具）を導入する傾向があり、または、実際にはカメラシステム自体がビューをブロックする場合があるからである（たとえば、カメラ自体を観察したり、キャプチャに使用される他のカメラを観察したりすることがある）。

【0076】

3D画像データがどのように表されるかに関係なく、通常、シーンの少なくとも一部のデータは含まれないか、少なくとも不完全または不十分なデータで構成され、したがって、特定のビューポイントのためのビューポートの部分のデータがまったくないか、少なくとも不完全または不十分であることがしばしばある。

【0077】

図１の画像生成装置に対応するレンダリングユニット２０３は、シーンの不完全な表現のみを提供する３Ｄ画像データに基づいて所定のレンダリング視点の画像を生成することができる。さらに、レンダリングユニット２０３は、画像を生成して、ユーザにとって画像データの欠如の影響が目立たず、または不便が少ない、改善された没入効果を提供するように構成される。 たとえば、仮想現実の観察者は、3D画像データが情報を提供しない領域を見て回ったり遭遇したりするときに、よりスムーズで没入感のある体験をすることができる。

【0078】

レンダリングユニット２０３は、シーンの３Ｄ画像データを受信するように構成された画像データ受信機１０１を備え、３Ｄ画像データはシーンの不完全な表現を提供する。特定の例では、画像データ受信機101は、3D画像ストア205に結合され、そこから3D画像データを受信する。 ３Ｄ画像データは、例えばインターネットを含む任意の適切な外部または内部ソースから受信できることが理解されよう。

【0079】

レンダリングユニット２０３は、ビュー画像がレンダリングされる視点を反映するレンダリングビューベクトルを提供するように構成されたビューベクトルソース１０３をさらに含む。特定の例では、ビューベクトルソース１０３は、シーン内の所望のレンダリング視点を示すターゲットビューベクトルを受け取るように構成されている。特定の例では、ビューベクトルソース103は、ユーザ入力ユニット201からターゲットビューベクトルを受け取るように構成される。ビューベクトルは、視点の指標を提供する1つ以上の値の任意のセットである。具体的には、ビューベクトルは、視点の位置および/または方向の指標を提供する1つまたは複数の値の任意のセットであり得る。ビューベクトルは通常、位置（x、y、zなど）もしくは方向（ヨー、ロール、ピッチ）を示す3つの成分値、または位置（x、y、z）および方向（ヨー、ロール、ピッチ）の６つの成分値を含む。ビューベクトルは、異なる数の成分を含むことができ、たとえば、方向は、方位角と仰角/高度値のみによって（または実際には、いくつかのケースでは、方位角値のみによって）与えられることが理解されよう。そのような場合、追加の自由度は、所定の値、デフォルト値、または推定値に対応すると見なすことができる。

【0080】

画像データ受信機１０１およびビューベクトルソース１０３は、画像データ受信機１０１がレンダリングビューベクトルによって表される所与のレンダリング視点の３Ｄ画像データを提供する画像の領域をレンダリングするように構成されたレンダラー１０５に結合される。この例では、レンダラー105はターゲットビューベクトルの画像を生成するために使用されるため、ターゲットビューベクトルがビューベクトルソース103から供給され、そこでレンダリングビューベクトルとして使用される。したがって、この例では、レンダリングビューベクトルとターゲットビューベクトルは同じである。

【0081】

レンダラー１０５は、レンダリングビューベクトルによって示されるレンダリング視点の画像をレンダリングするための任意の適切なアプローチを使用することができ、当業者は様々な方法を十分に認識していることが理解され、したがって、これらは簡潔にするためにここでは詳細に説明されない。

【0082】

例として、3D画像データが、異なる個別の視点の光強度画像と深度マップ（または、たとえばテクスチャマップと3Dメッシュ）として提供される場合、よく知られているように、レンダリングビューベクトルによって示される視点の画像は、視点シフトによって生成される。３Ｄ画像データが３Ｄモデルの形で提供される場合、これは、画像コンテンツを生成するために視点の観点から評価されることができる。

【0083】

ただし、3D画像データはシーンの不完全な表現のみを提供するため、（一部のレンダリングビューポイントでは）使用可能な3D画像データに基づいて直接レンダリングできない一部の画像の領域がある。例えば、ユーザが向きを変えて、キャプチャされていない領域に目を向け始めた場合、レンダラー105は、キャプチャされているシーンの部分に対応する画像の部分のためのデータのみを生成できる。

【0084】

したがって、多くの実施形態では、レンダラー105は画像の一部のみをレンダリングするように構成される。具体的には、レンダラー１０５は、画像の１つまたは複数の領域をレンダリングすることができ、画像の他の領域は生成されない。以下では、レンダラー１０５が画像コンテンツをレンダリング／生成した領域を第１領域と呼び、レンダラー１０５が画像データを生成していない境界領域を第２領域と呼ぶ。

【0085】

第１および第２領域への言及は、画像コンテンツがレンダリングされた１つの領域と画像コンテンツがレンダリングされていない１つの領域とに画像が分割されることを必ずしも意味しない。 むしろ、レンダラー１０５が画像コンテンツを生成する複数の領域、および／または画像コンテンツが画像コンテンツを生成しない複数の領域があり得る。あるいは、同等に、第１領域は、レンダラー１０５が画像コンテンツを生成した複数の別個の領域を潜在的に含むと考えられ得、および/または、第２領域は、レンダラー１０５が画像コンテンツを生成していない複数の別個の領域を含むと考えられ得る。

【0086】

図１のレンダリングユニット２０３は、そのような状況に対処するように構成される。むしろ、レンダラー105は、レンダリングされていない領域、第2領域を単に空のままにするかデフォルト色で塗りつぶすのではなく、3D画像データを第1の領域から第2の領域に外挿するように構成された外挿器107に結合される。したがって、外挿器は、第１の領域の画像コンテンツ／３Ｄ画像データから第２の領域の画像コンテンツを生成するように構成される。特に、ほとんどの実施形態では、３Ｄ画像データは、第２領域に外挿される第１領域の画像コンテンツ（ピクセル値）の外挿により、第１領域から第２領域に外挿される。

【0087】

このようにして、レンダリングユニットは、レンダリングビューベクトルによって表されるレンダリング視点のビューポートに対応する画像のすべての部分の画像コンテンツを含む完全な画像の生成に進むことができる。しかしながら、第1領域の画像コンテンツはビュー/シーンの非常に正確な反映/表現を提供する可能性が高い一方で、第2領域の画像コンテンツは、ビュー/シーンの劣化した、しばしば非常に劣化した表現を提供する可能性がある。例えば、多くの実施形態では、外挿器１０７は、第２領域に近い第１領域の画像コンテンツのそれに類似する比較的粗いテクスチャまたは色分布のみを生成するように構成され得る。しかしながら、第２領域のために生成された画像コンテンツは、例えば、所定の均一な色（例えば黒）よりも視聴者にとって目立たないかまたは邪魔にならず、したがって、改善されたユーザ体験を提供する傾向がある。

【0088】

第１領域の画像コンテンツを第２領域に外挿するための任意の適切なアプローチが、本発明を損なうことなく使用され得ることが理解されるであろう。外挿の具体例は後述される。

【0089】

しかしながら、レンダラー１０５は、完全に満たされた画像を提供するために単に画像コンテンツを第２領域に外挿するだけでなく、知覚効果を改善し、典型的には改善された没入型ユーザ体験をもたらす後処理をさらに含む。

【0090】

レンダリングユニット２０５は、外挿器１０７から画像を受け取るぼかしプロセッサ１０９を備える。ぼかしプロセッサ１０９は、空間的に変化するぼかしを画像に適用するように構成され、ぼかしの程度は、第１および第２領域の間の遷移領域において、（少なくとも）第１領域の内部領域よりも高い。したがって、遷移領域において、画像の意図的なぼかしが導入される。多くの実施形態では、遷移領域には第1領域の領域が含まれ、したがって、ぼかしプロセッサ１０９は、レンダラー１０５によって生成された画像コンテンツにぼかしを導入して、３Ｄ画像データから生成され得る画像コンテンツから外挿された画像コンテンツへのぼかされた遷移を生成する。

【0091】

遷移領域のこのぼかしは、ユーザ体験を大幅に改善する傾向があり、特により没入感のある体験を実現できることがわかっている。観察者は通常、現在のビューに3D画像データで表されていないシーンの部分が含まれていることに気付かず、ある方向で見ると画像がぼやけていることに潜在的に気が付くのみである。このアプローチは、観察者の行動をさらに変化させる傾向があり、特に、3D画像データが利用できない方向を見ることから離れるようにユーザをバイアスする傾向がある。さらに、このバイアスは捉えにくく、しばしば無意識下である傾向がある。特に、第1領域の部分、すなわち利用可能な3Dデータから生成された画像コンテンツに対して実行される空間的ぼかしは、ユーザによって検出されない微妙な効果を持つことが多いぼかしをもたらす。しかしながら、それでも微妙なぼかし効果を提供し、通常は詳細とフォーカスが欠けているため、観察者は他の方向を見るようにバイアスされる。

【0092】

たとえば、観察者は頭を回すと最初に、利用可能な3D画像データから完全に生成され、したがってシャープで詳細である画像を見るだろう。しかしながら、ある時点で、利用可能な3D画像データの端に到達し、この場合、観察者には、最初はまだ詳細を含む画像領域が提供される（たとえば、3D画像データから派生した画像オブジェクトが含まれる）が、これらはよりぼやけ始める。この効果は、3D画像データから生成された生成画像の情報を意図的および非直感的に削除することにより実現される。したがって、可能な限りシーンを表す画像を提供するのではなく、ぼかしプロセッサ１０９が、第１および第２領域の間の遷移領域を意図的にぼかし（具体的には、第１領域の遷移領域の鮮明なレンダリングの一部をぼかし）、したがって、シーンの示されるビューの精度を意図的に低下させる。しかしながら、この劣化は、特定の場合の外挿の精度に完全に依存するのではなく、ぼかしプロセッサ109によって制御されることができる。

【0093】

したがって、遷移の最初の要素は通常比較的高品質でありつつ、3D画像データが完全なビューのデータを含む視点に向かって観察者をバイアスする傾向があるという効果を持つ、より緩やかな遷移を実現できる。この効果は、知覚的に優れたユーザ体験を提供する傾向があり、特に仮想現実体験では、より没入感のある体験を提供することがわかっている。

【0094】

ぼかしは、例えば、具体的には空間ローパスフィルタなどのぼかしフィルタを使用して実行されてもよい。空間的ローパスフィルタの強度は、第1領域の内部領域よりも遷移領域に対してより強くなるように変更されることができる。したがって、第１領域には、ぼかし／ローパスフィルタリングの強度／程度が遷移領域に対してよりも小さい内部領域が存在する。通常、ぼかしプロセッサ１０９は、内部領域にローパスフィルタリングまたはぼかしを提供しないため、内部領域（通常、第１領域の大部分である可能性がある）は可能な限り鮮明にレンダリングされる。

【0095】

ぼかしの程度は、例えば、空間ローパスフィルタの空間カットオフ周波数を変えることにより変更することができる。例えば、適切なカーネル形状を使用して、現在のフィルタ位置とそれが遷移領域に対してどのように関係するかに応じてカーネルの空間的範囲を変えることができる。たとえば、第1領域内および遷移領域の外側では、カーネルの空間範囲を1ピクセルに設定でき、すなわち、フィルタリングは適用されない。遷移領域内で、カーネルの空間的範囲は、例えば所定のサイズまで増加され、それにより、空間的ローパスフィルタリングおよびぼかしをもたらし得る。

【0096】

多くの実施形態では、ぼかしは徐々に増加し得る。たとえば、カーネルのサイズは、遷移領域と第1領域の残りの部分との間の境界/エッジでの通常小さな値から、遷移領域と第2領域（の残りの部分）との境界におけるより大きな値まで徐々に増加されることができる。

【0097】

たとえば、ぼかしフィルタは、ガウスカーネルを使用した空間フィルタであり、カーネルのサイズはシグマ値で指定されることができる。そのような実施形態では、遷移領域のピクセルのガウスフィルタに適用されるシグマ値は、ピクセルから遷移領域と第1領域の残りの部分との間の境界までの距離の単調増加関数として、もしくは、ピクセルから遷移領域と第2領域の残りの部分との間の境界までの距離の単調減少関数として（または両方として）、決定される。

【0098】

そのようなアプローチは、3D画像データが情報をほとんどまたはまったく提供しないビューから離れるバイアスを引き起こすために、増加するぼかし、および徐々の画像の劣化を提供することができる。

【0099】

第2領域（具体的には、遷移領域が第2領域に及ぶ場合には、遷移領域の外側にある第2の領域の部分）に適用されるフィルタリングは、特定の実施形態に依存し得、実際、多くの実施形態では、例えば、外挿および/または3D画像データの特定の特性に依存する場合があることが理解されるだろう。

【0100】

多くの実施形態では、ぼかしプロセッサ１０９は、遷移領域のぼかしの程度に対して第２領域の少なくとも一部のぼかしの程度を低減するように構成されてもよい。したがって、いくつかの実施形態では、遷移領域のぼかしは、第1領域の少なくとも一部および第2領域の一部の両方よりも高い。したがって、第１領域と第２領域との間の遷移に対して、ぼかしを増加させることができるが、外挿された領域については、再び減少させることができる。 これは、多くの実施形態において、特に多くの外挿技術に対して、知覚的により有利な結果および/またはより低い複雑さをもたらし得る。

【0101】

たとえば、多くの外挿技術は、変化が比較的緩やかな比較的粗い外挿を生成する。このような場合、外挿結果はすでに空間的な低周波数特性を示しており、画像コンテンツをさらにぼかしたりフィルタしたりする必要はない。したがって、ぼかしプロセッサ１０９は、遷移領域にのみぼかしフィルタを適用し、それにより複雑さおよび計算要件を低減するように構成されることができる。

【0102】

したがって、ぼかしプロセッサ１０９は、レンダリングされた領域と外挿された領域の両方を含む生成された画像に空間的に選択的フィルタリングを適用する。ぼかし効果は、ユーザを望ましいビューにバイアスするだけでなく、レンダリングされた領域と外挿された領域をさらにブレンドすることにより、改善された効果を提供する傾向がある。

【0103】

図３は、図１の例に対応し、ぼかしの特性を決定するための特定の機能をさらに含むレンダラー１０５の特定の例を示している。

【0104】

図３のレンダラー１０５は、画像のレンダリングマスクを決定するように構成されたレンダリング領域プロセッサ３０１を含み、レンダリングマスクは、個々のピクセルが第１領域に属するか否かを示す。具体的には、レンダリングマスクは、各ピクセルについて、ピクセル値が3D画像データからレンダリングすることにより生成されるか、または外挿により生成されるかを示してもよい。

【0105】

多くの実施形態では、レンダリングマスクはバイナリ値を含むことができ、すなわち、各ピクセルについて、レンダリングマスクは、ピクセルがレンダリングによって生成されたかまたは外挿によって生成されたかどうか、または同等に、それが第1領域に属するか第2領域に属するかを示すことができる。いくつかの実施形態では、そのようなバイナリフィルタは、第１および第２領域間の遷移領域を示す漸進的な値を有する領域間の漸進的な遷移を生成するために空間ローパスフィルタリングされ得る。

【0106】

レンダリング領域プロセッサ301は、フィルタプロセッサ303に結合され、フィルタアダプタ303はさらにぼかしプロセッサ109に結合される。フィルタアダプタ３０３は、レンダリングマスクに応じて画像の空間的に変化するフィルタ特性を決定するように構成される。例えば、ローパスフィルタリングの度合い/強度を制御するパラメータは、ピクセルのマスク値に基づいて決定される。例えば、フィルタリングされたレンダリングマスクの場合、ローパスフィルタリング強度パラメータ値は、ピクセルのレンダリングマスク値の所定の関数として決定されてもよい。したがって、中間レンダリングマスク値によって定義されている遷移領域では、徐々に変化するローパス度パラメータが定義される。

【0107】

次いで、空間的に変化するフィルタ特性は、ぼかしプロセッサ１０９に供給され、空間的に変化するフィルタ特性を採用する空間フィルタを使用して画像をフィルタリングすることに進む。

【0108】

このアプローチは、空間的に変化するフィルタを適用して、レンダリングされたおよび外挿された画像コンテンツの空間的に選択的なぼかしを提供する特に効率的かつ実用的な方法を提供し得る。

【0109】

以下では、所与の所望のレンダリング視点の所与のビューポートに適用されるこのアプローチの特定の例を説明する。したがって、画像は、レンダリングビューベクトルによって示されるような位置および観察方向に位置する観察者のビューポートに対応して生成される。そのような画像を生成するアプローチは、プロセスの一部として生成される画像、ビューポート、およびマスクの様々な例を示す図4～8を参照して説明される。

【0110】

最初に、レンダラー105は、3D画像データが情報を提供する画像/ビューポートの部分をレンダリングすることにより、初期画像の生成に進むことができる。この例では、結果の画像は、レンダラー105が3D画像データからデータをレンダリングできる第1領域401、および、3D画像データがビューポートのこの部分のデータを含まないことに起因してレンダラー105によって画像コンテンツ/データが生成されない第2領域403を含む。特定の例では、第２領域４０３は２つの別個の領域を含むことが分かる。この例では、シーンのビューは、単純化のために、前面に暗い円形領域407を持つ均質な背景405で構成されると見なされる（たとえば、シーンが均質な青い空の前のボールであることに対応する）。

【0111】

次に、外挿器１０７は、第１領域４０１から第２領域４０３に外挿して、図５に示すように完全に満たされたビューポート／画像を生成することができる。

【0112】

レンダリング領域プロセッサ３０１は、３Ｄ画像データがデータを提供するおよびデータを提供しない画像／ビューポートの領域を示すレンダリングマスクの生成に進むことができる。したがって、レンダリングマスクは、レンダラー105が画像コンテンツをレンダリングした場所、および画像コンテンツが外挿器107によって生成された場所を示す。レンダリングマスクは、第1領域と第2領域に対応する画像の部分を示し、図4の特定のケースの例を図6に示す。

【0113】

レンダリングマスクはフィルタアダプタ３０３に送られ、フィルタアダプタ３０３は、レンダリングマスクからフィルタリング特性を生成することに進むことができる。具体的には、図6のシャープなバイナリマスクをローパスフィルタ処理することでそうすることが可能である。結果の例を図7に示し、レンダラー１０５が画像コンテンツを生成したことを示す値と、外挿器１０７が画像コンテンツを生成したことを示す値との中間の値を含む遷移領域が生成されることがわかる。このようにして、遷移領域では段階的な遷移が提供される。

【0114】

フィルタアダプタ３０３は、フィルタリングされたレンダリングマスク値に基づいて、個々のピクセルのローパスフィルタ特性を決定することに進むことができる。例えば、ローパスフィルタリングの程度は、係数値の関数として決定され、ピクセル値が外挿によって決定されていることを示すマスク値が増加するほど、その程度は増加する。たとえば、フィルタ係数値は、ガウスローパスフィルターのシグマパラメーター値のスケーリングされた値を提供するシグママップとして直接解釈される。

【0115】

したがって、この特定の例では、第1領域内でフィルタリングを適用せず、第2領域内で高い程度のローパスフィルタリングを適用し、遷移領域内では中間的なフィルタリングを適用することができる。

【0116】

いくつかの実施形態では、例えば、生成されたシグマ値の修正を追加して第２領域のフィルタリングを低減するなど、フィルタ特性のより複雑な決定を適用することができる。

【0117】

最後に、ぼかしプロセッサ109は、決定されたフィルタ特性を使用して空間フィルタリングを実行してもよい。フィルタリングは選択的に適用されてもよく、例えば、遷移領域にのみ適用されてもよい。

【0118】

このプロセスの結果として、図8のような出力が生成されることができる。画像は、レンダリングされた画像コンテンツと外挿された画像コンテンツの組み合わせを含むため、外挿された領域の品質/詳細は通常低下しているが、完全に満たされた画像/ビューポートを提供する。さらに、領域801で示されているように、さまざまな領域/エリアがブレンドされている。

【0119】

前述のように、外挿を実行するための任意の適切なアプローチが、本発明を損なうことなく使用され得る。

【0120】

例えば、オクルージョン領域の修復のアプローチと同様のアプローチを使用できる。したがって、当業者に知られているように、外挿は例えば、方向性修復（最も近いピクセルからの色の値のコピー）、テクスチャ修復（第1及び第２領域間のエッジのテクスチャを第2領域に外挿）および/またはポアソン方程式アプローチ（エネルギー関数に基づく修復）を使用することができる。

【0121】

一部のシナリオでは、ビューポート/画像領域のすぐ外側に、外挿の目的にまだ役立つ画像コンテンツが存在する場合がある。したがって、いくつかの実施形態において、レンダラー１０５は、直感に反して、決定されたビューポートの（通常はちょうど）外側にある画像領域をレンダリングし、外挿はビューポートの外側のレンダリングされた画像コンテンツに応じることができる。たとえば、方向性修復を使用すると、外挿されるピクセルのピクセル値は、ビューポートの外にあるピクセルであっても最も近いピクセルの値に設定される。

【0122】

いくつかの実施形態では、外挿器１０７は、第２領域に近接する第１領域のいくつかの領域についてローパスフィルタリングされた画像特性を決定するように構成される。具体的には、第１領域と第２領域との間の境界に近いいくつかの領域について、外挿器１０７は代表（平均）色値を決定することができる。次いで、外挿器１０７は、これらの色値の１つまたは複数と一致するように、第２領域のエリアのピクセル値を設定することに進むことができる。

【0123】

例えば、外挿部１０７は、第２領域の各非結合領域について、非結合領域に接する第１領域の領域すべての平均色値の平均値として色値を決定してもよい。他の実施形態では、第１領域は複数のサブエリアに分割され、各サブエリアは、平均値が決定された第１領域の所定のエリアに最も近いピクセルを含む。次に、第2領域のサブエリアをこの平均値に設定できる。

【0124】

このアプローチでは、非常に低い解像度の処理を利用できる。例えば、第１領域および／または第２領域の各エリアは、少なくとも１０^３、１０^４、１０^５または１０^６個のピクセルを含むことができる。したがって、このアプローチは、典型的には平均色値の反射に本質的に対応し得るシーンの非常に粗い表現を生成する第2領域への外挿をもたらし得る。ただし、これは多くのシナリオで許容可能な知覚を提供し、複雑さの低いアプローチを提供することができる。

【0125】

いくつかの実施形態では、外挿は、レンダラー105によって生成された画像のダウンスケーリングされたバージョンの双方向フィルタリングに基づいてもよい。具体的には、外挿器１０７は、最初に画像をダウンスケーリングするように構成されてもよい。通常、ダウンスケーリングは重要であり、たとえば、10⁴、10⁵または10⁶ピクセルを超えない解像度を持つフィルタ画像を生成する。次に、このダウンスケーリングされた画像に双方向フィルタが適用され、双方向フィルタは、レンダリングマスク（たとえば、元のバイナリまたはフィルタリングされたレンダリングマスク）によってガイドされる。したがって、空間フィルタリングの重みは、レンダリングマスク値に依存し、したがって、重みが第1領域に属するピクセルに対するものであるか、第2領域に属するピクセルに対するものであるかに依存する。通常、第1領域に属するピクセルはより高く重み付けされ、第2領域に属するピクセルはより低い重み（多くの実施形態ではゼロの重み）を有する。重みは、典型的には、重みが決定されるピクセルと、フィルタリングされた値が現在決定されるピクセルとの間の距離にさらに依存し得る。

【0126】

次に、結果のフィルタリングされたダウンスケール画像は元の解像度にアップスケールされ、その後レンダラー105からの画像と結合される。具体的には、第１領域のピクセルについては、フィルタリングされていない画像のピクセル値が選択され、第２領域のピクセルについては、双方向フィルタリングされた画像のピクセル値が選択される。

【0127】

このアプローチは、多くのシナリオで外挿を改善することができる。特別な利点は、アップスケーリング操作のために外挿がすでに適切にぼやけていることです

【0128】

いくつかの実施形態では、画像データ受信機１０１は、データストリームで３Ｄ画像データを受信するように構成されてもよい。例えばデータは、インターネットなどのネットワークを介して、リモートソースからのデータストリームで受信されてもよい。別の例として、データストリームは、ブルーレイディスクリーダーなどのローカルソースから受信されてもよい。

【0129】

そのような例では、データストリームは、外挿制御データを含むことができるメタデータを含むことができ、外挿器107は、外挿制御データに応じて外挿を実行するように構成されることができる。

【0130】

例えば、外挿器１０７は、例えば、詳細なテクスチャ修復、または低色平均色アプローチなどの異なる外挿アルゴリズムを実行することができてもよい。３Ｄ画像データは、これらのどれが使用されるべきかを定義する外挿制御データも含むデータストリームで受信されてもよい。

【0131】

このアプローチは、3D画像データのソースが画像をレンダリングするときの受信端の動作のいくつかの側面を制御することを可能にし、したがって、3D画像データの発信者にユーザ体験に対する追加の制御を提供し得る。たとえば、適切なメタデータを追加することで、監督の意図に一致する明確に定義された外挿の使用をサポートできる標準化されたアプローチを使用でき、このメタデータは、例えば以下を含む。
* （事前定義された）外挿アルゴリズムを選択するためのメタデータ。
* 定義済みの外挿アルゴリズムのパラメータを選択するメタデータ。

【0132】

特定の例として、シェーダーモデル4ファイルで別のURLを参照するDASH XML URLなどの外挿器を記述するメタデータを提供でき、その外挿器は、入力としてレンダリングされたビューポートのダウンスケールバージョンと、レンダリングマスク、またはレンダリングマスクをエンコードするカラーキーを持つ。

【0133】

いくつかの実施形態では、図１の画像生成装置は、（通常は）ぼかしプロセッサ109によってぼかされた後の画像に適応空間フィルタを適用するように構成されたフィルタプロセッサをさらに備えてもよい。そのような例では、空間フィルタは、画像全体に適用され、画像全体に対して同じ特性を持つ、つまり特性が空間的に不変であるグローバルフィルタであることができる。

【0134】

しかしながら、空間フィルタは、3D画像データに基づいてレンダリングできる視点/画像の量に依存する特性を有し、すなわち、グローバル空間フィルタの特性は、3D画像が画像データを含まない視点の割合に依存することができる。この割合は、第１領域の面積と第２領域の面積との間の比として決定され得る。

【0135】

特に、第２領域によって覆われる画像の割合が増加すると、フィルタは増加する強度を有し得る。例えば、レンダラー１０５が画像コンテンツ全体を生成できる状況では、フィルタ効果は重要ではないかもしれない（あるいは実際にフィルタ処理がないかもしれない）。しかしながら、外挿によって埋める必要がある画像の割合が増加するにつれて、フィルタリング効果が徐々に増加し、有意な知覚効果をもたらす可能性がある。

【0136】

したがって、いくつかの実施形態では、画像/ビューポートの大部分に3D画像データから直接生成されたコンテンツがない場合に、グローバル画像フィルタを適用することができる。フィルタの強度は、画像/ビューポート内の外挿されたコンテンツの量に応じて、徐々に上下に変化する。

【0137】

適切な画像フィルタの例は、
彩度低減
コントラスト低減
輝度低減
空間ローパスフィルタ
ホロデッキや境界フェンスなどの別のシーンのオーバーレイ
上記の組み合わせ
を含む。

【0138】

このアプローチは、知覚されたビューをより極端な方向に影響を与えることができる更なる知覚効果を可能にし、3D画像データが直接的な情報を提供しない領域から離れるように観察者の行動をバイアスするのを支援する。

【0139】

上記の例では、ターゲット及びレンダリング視点は同じであり、それに対応して、レンダリングビューベクトルは単純にターゲットビューベクトルと等しくなるように設定された。その結果、レンダラー１０５は、ターゲットビューベクトルによって表されるターゲット視点のビューポートに対応する画像を生成する。

【0140】

しかしながら、他の実施形態では、レンダリングユニット２０３は、ターゲットビューベクトルに対してレンダリングビューベクトルを（潜在的に）変更する機能、特に基準ビューベクトルに基づいてこの変更を行う機能を備えてもよい。そのようなレンダリングユニット２０３の例が図９に示されている。

【0141】

この例では、レンダリングユニット２０３は、生成される画像のターゲット視点を示すターゲットビューベクトルを受信するように構成された受信機９０１を備える。この例では、ターゲットビューベクトルはユーザ入力ユニット201から受信され、ユーザの希望、すなわちターゲットの視点（多くの場合、位置と方向の両方）を反映する。したがって、この例では、入力ビューベクトルは、ユーザが理想的にはビュー/画像を生成したいターゲットビューポイントのターゲットビューポートを示す望ましい/ターゲットビューベクトルである。通常、仮想現実アプリケーションの場合、これは仮想現実/環境/シーンにおける仮想ユーザの位置と向きに対応する。

【0142】

レンダリングユニット２０３は、シーンの基準視点を示す基準ビューベクトルを提供するように構成された基準ソース９０３をさらに備える。基準視点は、視点と、3D画像データがデータを提供しないシーン/環境の部分との間の関係を示す情報を提供するために使用されることができる。後で詳述するが、基準ビューベクトルは、たとえば、好ましい視点または提案された視点（たとえば、監督によって提案された）を示すことができ、または、例えば、３Ｄ画像データがデータを含むシーンの一部のエッジに対応する視点を反映することができる。

【0143】

いくつかの実施形態では、基準ビューベクトルは、特定の基準視点のセットまたは可能な視点の連続体または範囲など、複数の視点を示すように生成されてもよい。以下の説明は、基準ビューベクトルが１つの基準視点を示す状況に基づいているが、基準ビューベクトルが複数の視点を示すシナリオに拡張できることが理解されるであろう。たとえば、ほとんどのこのようなシナリオでは、処理は、たとえばターゲットビューベクトルに最も近いものなど、特定の状況に基づいて選択された単一の基準視点を考慮することまで減らすことができる。別の例として、記載された処理は、基準ビューベクトルの異なる考え得る値に対して実行されて、異なる可能なレンダリングビューベクトルを提供し、そこから単一のベクトルが選択される（たとえば、特定の実施形態に応じて、ターゲットビューベクトルに最も近いまたは最も遠いもの）。

【0144】

受信機９０１および基準ソース９０３は両方とも、ユーザ所望の視点およびシーンの基準視点の関数として、つまり、基準ビューベクトルとターゲットビューベクトルの関数としてレンダリングビューベクトルを生成するように構成されたビューベクトルソース１０３に結合される。次に、結果のレンダリングビューベクトルを使用して、前述のように画像を生成する。

【0145】

このアプローチは、より効率的なアプローチを提供し、生成される画像が、3D画像データがデータを含むシーンの部分のためのものである傾向があるように、ユーザの仮想的な動きと向きをある程度制約またはバイアスすることができる。このアプローチは通常、3D画像データが十分なデータを提供しない視点から、データを提供する視点に向かってユーザの視点をバイアスする、またはシフトする効果を提供する。

【0146】

例として、ユーザが頭を振り返る（たとえば、後ろを向き）、最終的にキャプチャされたコンテンツがないビューの方を向くと、仮想環境での仮想回転は、最初はユーザに正確に従うが、ビューポートが空の部分に移動すると、移動が少なくなり、実際に移動するユーザとの直接的な対応が損なわれる可能性があるが、キャプチャされたコンテンツをより多く含むレンダリング画像を提供する。したがって、システムがユーザの動きに完全に追随せず、コンテンツが利用可能なシーンの部分、つまりより高品質のビューに「貼り付く」または引き付けられる傾向があるという効果が得られる。

【0147】

例えば、特定の位置について、3D画像データは、キャプチャカメラの主方向、つまり3D画像データの一部として保存されたキャプチャ画像データの中心方向に対応する所与の基準方向に対して-140°から+140°の角度のデータを含むことができる。この場合、（仮想的に）頭を回し始めたユーザは、最初に、変更された観察方向に完全に追従するビューを提示される。たとえば、ディスプレイが60°の表示スパンに対応する画像を生成する場合、レンダリングビューベクトルは、カメラの基準方向に対して最大+110°の角度でターゲットビューベクトルに従うように生成される。この場合、3D画像データが完全なデータを提供し、外挿が必要ないため、対応するビューポート/画像のための完全な画像をレンダリングできる。

【0148】

ただし、ユーザが頭を回し続けると、ターゲットビューベクトル/視点が、3D画像データがデータを含まない部分に移動し、外挿が必要になる。外挿が必要な画像の割合、つまり品質が低下した画像の割合を減らすために、レンダリングビューベクトルは、ターゲットビューベクトルに正確に追従するのではなく、中央カメラ基準に近づくように修正されるように生成されるようになる。例えば、ユーザが移動して、ターゲットビューベクトルが+110°から+180°の間の（方位角）角度を表すようになると、これは（通常は非線形で）+110°から+140°の間にある角度を表すレンダリングビューベクトルにマッピングされ、すなわち、+110°～+180°の角度間隔は、（非線形に）+110°～+140°の角度間隔にマッピングでき、前者の間隔内のターゲットビューベクトルの角度は、後者の間隔内のレンダリングビューベクトルの角度にマッピングされる。したがって、3D画像データが存在しない部分にビューポートが移動するようにユーザが移動すると、レンダリングビューポートの対応する移動が減少する。ユーザへの影響は、仮想の動きがユーザの入力に完全に追従せず、代わりに提示されるビューがいくつかの好ましい観察方向にバイアスされる傾向があることである。ただし、これはユーザにとって不利な効果と見なされる場合があるが、通常、多くの実施形態では、提示される画像が比較的高品質であるという有利な効果と、極端に品質が低下したビューを完全に回避できるという事実が勝る。

【0149】

本質的に、さまざまな優先傾向が異なる方向にレンダリングビューベクトルを引っ張る「ゴムバンド」効果が実現されることができる。「ゴムバンド」の片側には、ユーザの好みの視点に対応するターゲットビューベクトルがある。ターゲットビューベクトルは、レンダリングビューポイントを引き付けるためにゴムバンドを引っ張る。「ゴムバンド」の反対側には、3D画像データが存在する3D画像データの部分に対応する1つ以上の視点を表す基準ビューベクトルがある。ゴムバンドの両端は、レンダリングビューポイントを異なる方向に引っ張り、結果のレンダリングビューポイント/ビューベクトルは、これらのファクタの相対的な「引き」と、結果としてのゴムバンドの「伸び」に依存する。実際、レンダリングビューは好ましい観察方向に向かって引かれることができ、この引きは通常、ユーザがこれらの好ましい観察方向から移動するほど増加する（「ゴムバンド」の比喩は、特定の、限定的な、または正確な説明を意図するものではなく、達成できる効果の直感的な兆候を提供することのみを目的とすることが理解されよう）。

【0150】

このアプローチはユーザの自由な仮想移動を制限する場合があるが、多くのシナリオで、ユーザ体験を大幅に改善し、特に、より没入感のある経験を提供することがわかっている。実際、これは、間接的な仮想移動制御が実装されている実施形態（例：ジョイスティックまたはマウスの移動）だけではなく、仮想の動き、ひいては生成されるターゲットビューベクトルが、ユーザの動きを直接反映することを意図する実施形態においても事実であることがわかっている。たとえば、仮想ユーザ体験がユーザの頭の動きを追跡するヘッドセットに基づいているアプリケーションでも多くの場合にユーザ体験を向上することが分かった。

【0151】

基準ビューベクトルおよびターゲットビューベクトルの関数としてレンダリングビューベクトルを決定するためにビューベクトルソース１０３によって使用される特定の関数は、個々の実施形態の特定の要件および好みに依存することが理解されよう。たとえば、基準視点/ビューベクトルに使用される特定の視点に依存する場合がある。

【0152】

しかしながら、多くの実施形態では、ビューベクトルソース１０３は、レンダリングビューベクトルを決定して、ターゲットビューベクトル／視点から基準ビューベクトル／視点までの距離が増加するにつれて、レンダリングビューベクトル／視点からターゲットビューベクトル／視点までの距離を増加させるように構成される。したがって、ほとんどの実施形態では、レンダリングビューベクトルを生成するためにターゲットビューベクトルに適用される変更は、ターゲットビューベクトルが基準ビューベクトルから遠ざかるにつれて増加する。通常、基準ビューベクトルは優先視点を示すため、ターゲットビューベクトルと基準ビューベクトル間の距離は、ユーザの現在のターゲット視点が優先ビューベクトルからどれだけ逸脱しているかを示す。したがって、ターゲットビューベクトルが優先視点ベクトルからさらに離れるほど、優先視点により近いレンダリングビューベクトルが得られるように、ターゲットビューベクトルに増加する修正が適用される。

【0153】

視点およびビューベクトルという用語は、ビューベクトルが対応する視点の表現（値のセットとして）を提供するため、同等であると見なされ得ることが理解されよう。したがって、例えば、ビューベクトルの修正、距離、比較などへの言及は、視点の修正、距離、比較への言及と同等であり、その逆も同様である。以下の説明では、ビューベクトルへの参照に焦点を当てる。

【0154】

多くの実施形態では、ビューベクトルソース１０３は、具体的には、レンダリングビューベクトルから基準ビューベクトルまでの距離とレンダリングビューベクトルからターゲットビューベクトルまでの距離との比が、ターゲットビューベクトルから基準ビューベクトルまでの距離が増加するにつれて減少するように、レンダリングビューベクトルを決定するように構成され得る。したがって、レンダリングビューベクトルから基準ビューベクトルおよびターゲットビューベクトルそれぞれまでの相対距離の比は、ターゲットビューベクトルと基準ビューベクトルとの間の差が大きくなるにつれて減少する。

【0155】

例えば、レンダリングビューベクトルは通常、ターゲットビューベクトルと基準ビューベクトルの間にあるように（たとえば、これらの間の線上にあるように、またはこれらの間の視線方向/角度に対応するように）、したがって、ユーザが望む視点と（3D画像データに基づく）優先視点との間にあるように生成される。レンダリングビューベクトルの相対位置は、ターゲットビューベクトルが基準ビューベクトルに近いとき、レンダリングビューベクトルがターゲットビューベクトルに近い（または実際にこれと同じ）ように変更される。しかしながら、ターゲットビューベクトルが基準ビューベクトルからさらに外れ始めると、レンダリングビューベクトルは、ターゲットビューベクトルから基準ビューベクトルに向かって効果的に移動し始め、すなわち、レンダリングビューベクトルの相対位置はもはや、ターゲットビューベクトルの近くではなくなる。したがって、ターゲットビューベクトルまでの相対距離が増加する一方、基準ビューベクトルへの相対距離が減少し（たとえば、両方の距離は、基準ビューベクトルとターゲットビューベクトル間の合計距離を基準にして正規化される）、それに応じて比は減少する。実際、（わずかな偏差の場合に）レンダリングビューベクトルがターゲットビューベクトルと同じになるように生成されると、基準ビューベクトルまでの距離とターゲットビューベクトルまでの距離の比は無限となる（後者の距離がゼロとなる）。偏差が増加し、レンダリングビューベクトルとターゲットビューベクトルとの間の相対距離がゼロから増加すると、レンダリングビューベクトルと基準ビューベクトルとの間の相対距離が減少する。

【0156】

このアプローチにより、ビューベクトルソース１０３は、3D画像データがデータを提供しない部分に向かってまたはその部分へとターゲットビューベクトルが移動する程、データが利用可能な３Ｄ画像データの部分にますますバイアスされるレンダリングビューベクトルを生成することができる。

【0157】

前述したように、多くの実施形態では、ビューベクトルソース１０３は、レンダリングビューベクトルに十分に近い限り、ターゲットビューベクトルに直接一致するようにレンダリングビューベクトルを生成するように構成され得る。これは、多くの実施形態およびシナリオにおいて非常に有利な動作を提供し、実際に、それが実際に望まれないかまたは必要でない限り、バイアス効果が適用されない結果となることができる。知覚的影響を軽減し、より没入感のある体験をもたらすことができる。

【0158】

多くの実施形態において、レンダリングビューベクトルは、レンダリングビューベクトルとターゲットビューベクトルとの間の距離が、ターゲットビューベクトルと基準ビューベクトルとの間の距離の単調増加関数であるように生成される。ただし、この単調増加関数は通常、線形関数ではなく、通常は非線形関数であり、通常は非線形に増加するため、ターゲットビューベクトルと基準ビューベクトルの間の偏差が大きくなると、変更または修正が増加する。

【0159】

前述のように、多くの実施形態およびシナリオでは、ターゲットビューベクトルに適用される修正は、ターゲットビューベクトルが基準ビューベクトルと大幅に異なる場合を除き、非常に小さいか、実際にはゼロである。たとえば、上記の例では、この差が+110°に達するまで、レンダリングビューベクトルはターゲットビューベクトルと同一であり、すなわち、この例では、ビューポート/画像に3D画像データがデータを含まないシーンの一部の要素が含まれ始めるまで、すなわち、最初の領域が画像全体を満たさないポイントまで、レンダリングビューベクトルはターゲットビューベクトルと同一である。さらに、典型的には、効果はそれから徐々に増加されることができ、すなわち、非線形に増加する関数が適用されることができる。

【0160】

これらの効果は、バイアス効果が徐々に増加し、通常、ターゲットビューベクトルが移動して画像の大幅な劣化が発生するまで存在しないおよび/または気付かないという経験を提供することができる。しかしながら、ターゲットビューベクトルが3D画像データにデータがないシーンの部分にさらに移動すると、最初は徐々に効果が大きくなり、さらに移動するとより積極的な効果が得られる。

【0161】

任意の適切な距離測定を使用して距離を評価できることが理解されよう。多くのシナリオでは、2つのビューベクトル間の距離は、仮想シーン内の対応するパラメータ間の距離と見なすことができる。多くの実施形態では、距離は、シーン内の所与の位置からの２つのビューベクトルによって表される向きまたは観察方向間の角度差などの角距離であり得る。多くの実施形態では、距離は、例えばビューベクトルの１つ以上の値を直接比較することにより、ビューベクトルの直接比較に応じて決定されてもよい。

【0162】

上記の例では、基準ビューベクトルは、たとえば実質的に全方向性のカメラの主方向などの、シーンをキャプチャするための中央視点を示すビューベクトルであると見なされる。そのようなシナリオは、例えば、ユーザが仮想環境内の仮想位置に固定され、固定位置がカメラの位置に対応する実施形態において有利であり得る。したがって、特に、ユーザが、シーン内を「見回す」手段が提供されるが、キャプチャカメラの位置に静止していると見なされ、つまり、視点の変化が観察方向の変化に制限されるアプリケーションに非常に有利なパフォーマンスを提供することができる。

【0163】

しかし、他の実施形態では、3D画像データは複数のカメラによってキャプチャされたデータを含むことができ、および/または、ユーザが向きと同様に位置も移動できるようにすることができる。多くのそのような実施形態では、単一の固定されたキャプチャ基準ビューベクトルは最適ではない場合がある。

【0164】

いくつかの実施形態において、システムは、仮想シーン／環境の３Ｄ画像データ表現を適宜提供するデータストリームとして（データファイルとして含む）３Ｄ画像データを受信してもよい。３Ｄ画像データは、コンテンツ・プロバイダによってこのフォーマットで提供されてもよく、コンテンツ・プロバイダは、それに応じて、仮想現実体験を提供するために探索または使用できる仮想シーン／環境を提供してもよい。

【0165】

いくつかの実施形態では、３Ｄ画像データを提供するそのようなデータストリームは、名目上の視点データを提供し得る。名目上の視点データは、3D画像データの名目上の視点を示し得る。この名目上の視点データは、特に、3D画像データがデータを含む部分とそうでない部分を示す情報を提供してもよい。

【0166】

一例として、名目上の視点データは、１つ以上の好ましい視点を示し得る。例えば、シーン内のさまざまな位置に対して、好ましい観察方向または向きを提供することができる。例えば、仮想環境内の各位置に対して、好ましい観察方向/方位を提供することができる。好ましい観察方向は、例えば、３Ｄ画像データがデータを提供しないシーンの最も近い部分に対して最大距離を有する観察方向を示し得る。

【0167】

多くの実施形態において、そのような好ましい方向情報は、著しいデータオーバーヘッドを生じることなく提供できることが理解されるであろう。例えば、多くの実施形態では、１つの好ましい観察方向表示は、多数の位置、および可能なすべての位置をカバーするのに適している場合がある。例えば、キャプチャがベースライン上の同じ方向を向いている1つ以上のカメラによって行われる場合（3D画像データの欠落データは、カメラの真後ろの、つまりカメラの方向と直接反対方向にあるシーンの部分に対応する）、すべての位置の好ましい観察方向は、単にそのカメラの方向として指定できる。

【0168】

他の実施形態では、それぞれの位置が異なる好ましい観察方向を有する差別化されたアプローチが使用されてもよい。たとえば、データの欠落を引き起こす障害物がある場合、特定の位置の優先方向は、そのオブジェクトとは反対方向を向いている可能性がある。

【0169】

いくつかの実施形態では、好ましい観察方向は時間的に変化してもよい。たとえば、名目上の視点データは、3D画像データによって表される仮想環境を通るパスを記述できる。このようにして、ガイドされたまたは制御された体験を提供できる。たとえば、コンテンツ・プロバイダは、シーンを通したユーザの動きは制御されるが、ユーザは指定された位置から自由に見回すことができる、物語の体験を提供することができる。しかしながら、名目上の視点データは、時間の関数として推奨される位置と観察方向を提供することができる。仮想現実アプリケーションは、ローカルユーザーから受信する競合する指示がない場合、対応する画像のレンダリングと表示に進むことができる。ただし、たとえば、ユーザが頭を回して見回すことを示すユーザ入力が受信された場合、システムはそれに応じてレンダリングビューベクトルを変更でき、つまり、レンダリングビューベクトルは、名目上の観察方向とは異なるように生成される。

【0170】

そのような例では、レンダリングユニット203は、名目上の視点データからレンダリングビューベクトルを生成するように構成され、特に、ユーザ入力が別の指示をしない限り、示された名目上の視点に対応するレンダリングビューベクトルを生成する。 この場合、レンダリングビューベクトルは、ユーザの入力を反映するために名目上の視点に対して変更される。しかし、多くの実施形態では、このプロセスは、ターゲットビューベクトルと基準ビューベクトルとの間の距離に依存してレンダリングビューベクトルを作成するという説明されたアプローチの対象となり得る。具体的には、名目上の視点を使用して、対応する基準ビューベクトルを生成し、ユーザ入力で（基準ビューベクトルに対する）ターゲットビューベクトルを生成する。このように、基準ビューベクトルがキャプチャカメラの方向に対応する例で説明したように、レンダリングビューベクトルを生成することができる。

【0171】

このアプローチは、例えば、コンテンツ・プロバイダが、例えば物語を提供するために仮想現実体験を「指示」することを可能にし得る。ユーザにはまだある程度の自由が与えられるが、これは、他の方向で失われたデータの影響を減らすために、「ディレクタ」推奨の観察方向に制限またはバイアスされる可能性がある。

【0172】

名目上の視点データは、方向の明示的な記述を提供する必要がないことが理解されるであろう。 例えば、いくつかの実施形態では、３Ｄ画像データは、実質的に全方向性の画像の時間シーケンスの形で提供されてもよい。これらの全方向画像のそれぞれの中心点が名目上の基準視点であると見なされてもよく、すなわち、特に、全方向画像がキャプチャされた位置に対する名目上の向きであると見なされてもよい。

【0173】

ユーザが入力を提供しない場合、受信された全方向画像の適切な中央部分を選択することにより、画像がレンダリングされる。しかしながら、例えば周囲を見回すことにより、ユーザが観察の向きのシフトを示した場合、レンダリングユニット203は、所望の向きに対応するように全方向ビューの異なるセクションを選択する。ただし、シーンの欠落部分の相当な部分を含むこのセクションのリスクを軽減するために、基準ビューベクトルに向かってレンダリングビューベクトルをバイアスする前述のアプローチが適用される。したがって、全方向画像のどのセクションを表示するかを示すために生成されるレンダリングビューベクトルは、（有効な）画像データを含まない全方向画像の部分の相当なセクションを含む選択から離れるようにバイアスされる。

【0174】

いくつかの実施形態では、ビューベクトルソース１０３は、３Ｄ画像データが画像データを含むシーンの部分と3D画像データが画像データを含まないシーンの部分との間の境界を示す境界ビューベクトルに応じて、基準ビューベクトルを決定してもよい。

【0175】

例えば、所与の視点位置について、ビューベクトルソース103は、3D画像データが画像データを含む状態から画像データを含まない状態に移行する角度を決定してもよい。例えば、前の特定の例では、3D画像データは最大140°の角度までの画像データを含む。したがって、境界ビューベクトルはこの値に対応するように決定され、基準ビューベクトルはこの値に設定される（または、例えば、ディスプレイによって表される視野角の半分に対応する値、すなわち、60°の視野角を表すディスプレイの例では110°でオフセットされてもよい）。したがって、レンダリングビューベクトルは、ターゲットビューベクトルが基準ビューベクトルに、したがって境界ビューベクトルにどのように関係するかに基づいて決定され得る。したがって、レンダリングビューベクトルは、ターゲットビューベクトルが、3D画像データがデータを含むシーンの部分からデータを含まない部分への遷移にどのように関係するかに基づいて直接決定され得る。

【0176】

たとえば、ターゲットビューベクトルが基準/境界ビューベクトルを超える角度を示すとき、基準/境界ビューベクトルまでの距離が短くなるようにレンダリングビューベクトルを生成できる。たとえば、前の特定の例では、ターゲットビューベクトルが110°未満の角度を示している場合、これと基準ビューベクトルとの間の角度差は負であると見なされる。110°を超え始めると、差は正になり、レンダリングビューベクトルは、レンダリングビューベクトルから基準ビューベクトルへの角度がターゲットビューベクトルと基準ビューベクトルの差を下回るように生成される。たとえば、110°を超える角度の場合、レンダリングビューベクトルは、次式の角度に対応するように生成されることができる。

【数1】

【0177】

ここで、θ_Renはレンダリングビューベクトルの角（度）、θ_Refは基準角度（つまり110°）、θ_Targはターゲットビューベクトルの角（度）である。したがって、110°～180°のターゲットビューベクトル角度間隔は、110°～140°のレンダリングビューベクトル角度間隔に非線形にマッピングされる。

【0178】

レンダリングビューベクトルの決定は、多くの実施形態において、単にターゲットビューベクトルおよび基準ビューベクトルよりも多くの特徴を考慮してもよい。例えば、１つのカメラの方向に対応するように基準ビューベクトルを決定することが実際的ではない実施形態では、いくつかのカメラの視点を考慮することも可能であり、有利であり得る。

【0179】

多くの実施形態では、３Ｄ画像データは、異なる視点からのビューのセットとして生成され得る。これらのビューのそれぞれは、通常は、その視点の位置で、その視点の向きで配置されたカメラでキャプチャされたものとして、対応する視点の画像（全方向画像および/または3D画像など）に対応することができる。

【0180】

このような例では、3D画像データには通常、視点を定義するデータが含まれる（この情報は、特定の視点の画像をレンダリングするためにも使用される）。この情報は、レンダリングビューベクトルを生成するときにも考慮される。例えば、レンダリング視点は、3D画像データの視点に対する距離が短くなる視点に向かってバイアスされることができる。

【0181】

別の例として、ビューベクトルソース１０３は、３Ｄ画像データが画像データを含む所与のレンダリングビューベクトルのためのビューポートの割合を考慮するように構成されてもよい。例えば、非線形関数は、外挿によって生成される必要がある画像の割合がターゲットビューベクトルの関数としてどれだけ速く変化するかを反映するように動的に適応されることができる。

【0182】

例えば、外挿によって生成される必要がある画像の領域が、レンダリングビューベクトルが変化するにつれて非常に急速に増加する場合、レンダリングビューベクトルを基準ビューベクトルに非常に近づける（たとえば、これが境界ビューベクトルとして指定されている場合）積極的な効果が適用されることができる。しかしながら、変化が非常に緩やかである場合には、非常に緩やかで気付きにくい効果をもたらす関数が適用されることができる。

【0183】

レンダリングビューベクトルを決定するときに複数のパラメータを考慮するための異なるアルゴリズムおよびアプローチが、異なる実施形態で使用され得ることが理解されよう。例えば、異なるパラメータの複合効果は、複数の項を持つ非線形エネルギー関数Jとして表されることができる。そして、非線形最適化アルゴリズムを使用して、Jを最小化するものとしてレンダリングビューベクトルを決定することができる。たとえば、勾配降下アプローチを使用できる。

【0184】

多くの実施形態では、レンダラー２０３は、意図されたディスプレイの１つまたは複数のパラメータを示すディスプレイ特性データを受信するように構成され得る。そして、ビューベクトルソース１０３は、レンダリングビューベクトルを決定するときにそのようなディスプレイ特性を考慮するように構成され得る。

【0185】

例えば、レンダリングユニット２０３は、ディスプレイによってサポートされる視野角の情報を受け取ることができる。たとえば、ディスプレイがバーチャルリアリティセットの一部である場合、ディスプレイ特性は、ディスプレイがヘッドセットを装着しているユーザに提供する視野角を示すことができる。この情報を使用して、たとえば、前述の通り、基準ビューベクトルを決定することにより（例えば、3D画像データがデータを含むシーンの部分の端に表示の端が到達する角度を決定するためにそれを使用することにより）、または、適用される関数を変更することにより、レンダリングの表示角度を決定できる。

【0186】

前の例では、基準ビューベクトル（および実際には他のパラメータ）が、望ましいまたは優先される特性/ビューに対応すると見なされていた。したがって、レンダリングビューベクトルは基準ビューベクトルに向かってバイアスされる。しかし、他のシナリオまたは実施形態では、基準ビューベクトルは望ましくない/優先されないプロパティに対応する場合がある。例えば、３Ｄ画像データがデータを提供しないシーンの部分にビューポート全体が対応する視点（特に方向）を示す基準ビューベクトルが提供され得る。この場合、ビューベクトルソース１０３は、基準ビューベクトルから離れるバイアスを適用することによりレンダリングビューベクトルを生成するように構成されてもよい。

【0187】

例えば、基準ビューベクトルは、データが提供されないシーンの部分の中心に対する角度、例えば、前述の特定の例では180°を示す場合がある。そのような場合、レンダリングビューベクトルは、ターゲットビューベクトルと基準ビューベクトルとの差が十分に大きい限り、ターゲットビューベクトルに対応するように生成されてもよい。たとえば、基準角度とターゲット角度の角度差が70°を超えている限り、ターゲットビューベクトルをレンダリングビューベクトルとして直接使用できる。ただし、差が70°を下回ると、通常、前述のアプローチと同様の非線形関数を使用して、レンダリング角度とターゲット角度の差が生じ始める可能性がある。

【0188】

したがって、いくつかの実施形態では、ビューベクトルソース１０３は、ターゲットビューベクトルから基準ビューベクトルまでの距離が減少するにつれて、レンダリングビューベクトルからターゲットビューベクトルまでの距離を増加させるように構成され得る。

【0189】

一部の実施形態では、ビューベクトルソース１０３は、レンダリングビューベクトルから基準ビューベクトルまでの距離と、レンダリングビューベクトルからターゲットビューベクトルまでの距離との間の比を、ターゲットビューベクトルから基準ビューベクトルへの距離が減少するにつれて減少させるように構成され得る。

【0190】

いくつかの実施形態では、ビューベクトルソース１０３は、ターゲットビューベクトルと基準ビューベクトルとの間の閾値を超える差に対して実質的にターゲットビューベクトルとしてレンダリングビューベクトルを決定するように構成され得る。

【0191】

したがって、いくつかの実施形態では、基準ビューベクトルは、ターゲットビューベクトルに対して、デトラクタ（押しやるもの）として使用されてもよく、他の実施形態では、アトラクタ（引き付けるもの）として使用されてもよい。

【0192】

多くの実施形態において、ビューベクトルソース１０３は、複数の異なる基準ビューベクトルを同時に考慮することができ、引き付ける基準ビューベクトルと押しやる基準ビューベクトルの両方を同時に考慮することを含むことが理解されるであろう。これは、たとえば、適切なエネルギー関数またはコスト関数を定義し、勾配検索を使用して、選択した測度を必要に応じて最大化または最小化することで実現できる。

【0193】

いくつかの実施形態では、仮想現実デバイスは、他のタイプのフィードバックを提供する機能をさらに備えてもよい。例えば、触覚フィードバックが、例えば、ゲームアプリケーションから知られている「フォースフィードバック」の形で提供されてもよい。これは、特にターゲットビューベクトルを変更するアプローチに関連して使用されることができる。 例として、レンダリングビューベクトルを生成するためにターゲットビューベクトルに加えられる修正が大きいほど、フォースフィードバックが大きくなる。触覚フィードバックが方向性刺激を提供する実施形態では、これは、ユーザを所望の方向に促す方向を有するように構成されてもよい。たとえば、ジョイスティックやレーシングホイールなどのコントローラを使用すると、ターゲットビューベクトルに対する「引き付け」の量と方向の両方の印象を、フォースフィードバック感覚によってユーザに伝えることができる。

【0194】

いくつかの実施形態では、画像を生成するための装置が提供されることができ、当該装置は、シーンの3D画像データを受信するための受信機（101）であって、前記3D画像データがシーンの不完全な表現を提供する、受信機と、画像のシーン内のレンダリング視点を示すレンダリングビューベクトルを提供するためのビューベクトルソース（103）と、前記レンダリングビューベクトルに対する中間画像の第1領域をレンダリングするレンダラー（105）であって、第１領域は３Ｄ画像データが画像データを含む領域である、レンダラーと、3D画像データを中間画像の第2領域に外挿するための外挿器（107）であって、第2領域は3D画像が画像データを含まない領域であり、第1領域と第2領域とは隣接する領域である、外挿器と、中間画像に空間的に変化するぼかしを適用することに応じて画像を生成するぼかしプロセッサ（109）であって、ぼかしの程度は、第１領域の内部領域よりも第１領域と第２領域との間の遷移領域でより高い、ぼかしプロセッサとを有する。

【0195】

明確にするための上記の説明は、異なる機能回路、ユニット、およびプロセッサを参照して本発明の実施形態を説明したことが理解されるであろう。しかしながら、本発明を損なうことなく、異なる機能回路、ユニットまたはプロセッサ間での機能の任意の適切な分配を使用できることは明らかであろう。例えば、別個のプロセッサまたはコントローラによって実行されるように示されている機能は、同じプロセッサまたはコントローラによって実行されてもよい。したがって、特定の機能ユニットまたは回路への参照は、厳密な論理的または物理的な構造または編成を示すのではなく、説明した機能を提供するための適切な手段への単なる参照と見なされる。

【0196】

本発明は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組み合わせを含む任意の適切な形式で実装することができる。本発明は、オプションとして、少なくとも部分的に、１つ以上のデータプロセッサおよび／またはデジタル信号プロセッサで実行されるコンピュータソフトウェアとして実装されてもよい。本発明の実施形態の要素およびコンポーネントは、任意の適切な方法で物理的、機能的、および論理的に実装され得る。実際、機能は、単一のユニット、複数のユニット、または他の機能ユニットの一部として実装されてもよい。したがって、本発明は、単一のユニットで実施されてもよく、または異なるユニット、回路、およびプロセッサ間で物理的および機能的に分散されてもよい。

【0197】

本発明はいくつかの実施形態に関連して説明されたが、本明細書に記載された特定の形態に限定されることは意図されていない。むしろ、本発明の範囲は添付の特許請求の範囲によってのみ制限される。さらに、特定の実施形態に関連して特徴が説明されているように見えても、当業者は、説明された実施形態の様々な特徴を本発明に従って組み合わせることができることを認識するであろう。請求項において、「含む」「有する」という用語は、他の要素またはステップの存在を排除しない。

【0198】

さらに、個別に列挙されていても、複数の手段、要素、回路、または方法のステップは、たとえば単一の回路、ユニット、またはプロセッサによって実装されてもよい。さらに、個々の特徴は異なる請求項に含まれる可能性があるが、これらは有利に組み合わされる可能性があり、異なる請求項に含まれることは、特徴の組み合わせが実行可能および/または有利でないことを意味しない。また、クレームの1つのカテゴリに機能を含めることは、このカテゴリの制限を意味するものではなく、その機能が必要に応じて他のクレームカテゴリに等しく適用できることを示す。さらに、クレーム内の機能の順序は、機能が動作しなければならない特定の順序を意味するものではなく、特に方法クレーム内の個々のステップの順序は、ステップがこの順序で実行されなければならないことを意味しない。むしろ、ステップは任意の適切な順序で実行されてもよい。さらに、単数の参照は複数を除外しない。したがって、「a」、「an」、「first」、「second」などへの言及は、複数を排除するものではない。 特許請求の範囲の参照符号は、明確な例として提供されているに過ぎず、特許請求の範囲を限定するものと解釈されるべきではない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】