IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ コーニンクレッカ フィリップス エヌ ヴェの特許一覧

特表2024-522463マルチビュービデオにおける奥行きセグメント化
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-06-21
(54)【発明の名称】マルチビュービデオにおける奥行きセグメント化
(51)【国際特許分類】
   G06T 7/55 20170101AFI20240614BHJP
   H04N 13/268 20180101ALI20240614BHJP
   H04N 13/271 20180101ALI20240614BHJP
   H04N 13/282 20180101ALI20240614BHJP
【FI】
G06T7/55
H04N13/268
H04N13/271
H04N13/282
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023571330
(86)(22)【出願日】2022-05-25
(85)【翻訳文提出日】2023-11-16
(86)【国際出願番号】 EP2022064243
(87)【国際公開番号】W WO2022253677
(87)【国際公開日】2022-12-08
(31)【優先権主張番号】21177608.3
(32)【優先日】2021-06-03
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
(71)【出願人】
【識別番号】590000248
【氏名又は名称】コーニンクレッカ フィリップス エヌ ヴェ
【氏名又は名称原語表記】Koninklijke Philips N.V.
【住所又は居所原語表記】High Tech Campus 52, 5656 AG Eindhoven,Netherlands
(74)【代理人】
【識別番号】100122769
【弁理士】
【氏名又は名称】笛田 秀仙
(74)【代理人】
【識別番号】100163809
【弁理士】
【氏名又は名称】五十嵐 貴裕
(74)【代理人】
【識別番号】100145654
【弁理士】
【氏名又は名称】矢ヶ部 喜行
(72)【発明者】
【氏名】ファレカムプ クリスティアーン
【テーマコード(参考)】
5L096
【Fターム(参考)】
5L096CA05
5L096DA01
5L096FA66
5L096FA67
5L096HA11
5L096KA04
(57)【要約】
マルチビュービデオデータを生成するための奥行きセグメンテーションの方法。本方法は、複数のセンサから3Dシーンを表す複数のソースビュー画像およびソースビュー奥行きマップを取得することを含む。3Dシーン内の前景オブジェクトは、ソースビュー画像および/またはソースビュー奥行きマップからセグメント化される。そして少なくとも1つの前景オブジェクトを含む各ソースビュー画像およびソースビュー奥行きマップについて1つまたは複数のパッチが生成され、各パッチは1つの前景オブジェクトに対応し、パッチを生成することは、ソースビュー画像およびソースビュー奥行きマップに基づいて、パッチテクスチャ画像、パッチ奥行きマップおよびパッチ透明度マップを生成することを含む。
【特許請求の範囲】
【請求項1】
マルチビュービデオデータの生成のための奥行きセグメント化の方法であって、
複数のセンサから3Dシーンを表す複数のソースビュー画像およびソースビュー奥行きマップを取得するステップと、
前記ソースビュー画像および/または前記ソースビュー奥行きマップから前記3Dシーン中の前景オブジェクトをセグメント化するステップと、
少なくとも1つの前景オブジェクトを含む各ソースビュー画像およびソースビュー奥行きマップについて1つまたは複数のパッチを生成するステップであって、各パッチが1つの前景オブジェクトに対応し、パッチの生成が、前記ソースビュー画像および前記ソースビュー奥行きマップに基づいて、パッチテクスチャ画像、パッチ奥行きマップおよびパッチ透明度マップを生成することを含み、各パッチが、対応するソースビュー画像の当該ソースビュー画像よりも小さいセクションに基づく、ステップと、
少なくとも1つの背景奥行きマップおよび背景テクスチャデータを含む背景モデルを取得するステップと、
前記パッチテクスチャ画像、前記パッチ奥行きマップ、前記パッチ透明度マップおよび前記背景モデルに基づいてアトラスを生成するステップと、
を有する方法。
【請求項2】
前記3Dシーンの背景を表す前記3Dシーンの複数の背景奥行きマップを取得するステップをさらに有し、各背景奥行きマップは特定の向きからの前記背景の奥行きデータを含み、前景オブジェクトのセグメント化が、背景奥行きマップと対応するソースビュー奥行きマップとの間の差に基づく、請求項1に記載の方法。
【請求項3】
それぞれの対応するソースビュー奥行きマップから背景奥行きマップを減算して、それぞれの差分画像を生成するステップと、
前記差分画像を閾値処理するステップであって、閾値処理が、背景と前景オブジェクトとを区別する閾値マップを生成するために前記差分画像のピクセル値を閾値と比較する、ステップと、
奥行きステップに対応する前記ソースビュー奥行きマップ中のピクセルを特定するステップであって、奥行きステップは、奥行き閾値より大きいソースビュー奥行きマップ中の隣接する奥行き値との差により定められる、ステップと、
前記奥行きマップ中の前記奥行きステップを背景としてマーキングして、前記前景オブジェクトを互いから区別するステップと、
前記調整された閾値マップに基づいて前記前景オブジェクトの周りに境界ボックスを生成するステップと、
により前景オブジェクトを検出する、請求項1または2に記載の方法。
【請求項4】
前景オブジェクトの検出がさらに、前記境界ボックスを拡張し、それにより、前記閾値未満の前記差分マップ中の前記前景オブジェクトの領域を含める、請求項3に記載の方法。
【請求項5】
パッチ奥行きマップの全てのピクセル奥行き値が、対応する前景オブジェクトの奥行き値以下の値からなるように、前記パッチ奥行きマップの前記ピクセル奥行き値を適応させるステップをさらに有する、請求項1から4のいずれか一項に記載の方法。
【請求項6】
オブジェクト奥行き範囲内の前記パッチの前記パッチ奥行きマップを特定することに基づいて第1前景オブジェクトに対応する複数のパッチを前記パッチから特定するステップと、
前記特定されたパッチ奥行きマップを前記3Dシーン中のオブジェクト位置に対応するように修正するステップと、を有する、請求項1から5のいずれか一項に記載の方法。
【請求項7】
複数のソースビュー中のパッチ間の一貫性の測定に基づいて前記パッチをプルーニングするステップをさらに有する、請求項1から6のいずれか一項に記載の方法。
【請求項8】
1つまたは複数のパッチの生成が、ソースビュー奥行きマップ中のサブ領域を特定し、前記サブ領域中に存在する異なる奥行きの複数の奥行き面を決定し、前記サブ領域中の奥行き面毎にパッチを生成することを含み、各パッチが異なるパッチ透明度マップを有する、請求項1から7のいずれか一項に記載の方法。
【請求項9】
計算装置上で実行されて、当該計算装置に請求項1から8のいずれか一項に記載の方法の全てのステップを実行させるコンピュータプログラムコードを含む1つまたは複数のプロセッサと、
前記ソースビュー画像およびソースビュー奥行きマップを取得するように構成された複数のセンサと、を有するシステム。
【請求項10】
マルチビュービデオをレンダリングする方法であって、
複数のパッチおよび3Dシーンの背景モデルを含むアトラスを受信するステップであってと、
各パッチが1つの前景オブジェクトに対応し、
各パッチが、ソースビュー画像およびソースビュー奥行きマップから導出されたパッチテクスチャ画像、パッチ奥行きマップおよびパッチ透明度マップを有し、
各パッチが、前記ソースビュー画像より小さい対応するソースビュー画像のセクションに基づく、ステップと、
前記3Dシーン内の仮想視点を受信するステップと、
前記仮想視点の位置と、各パッチに対応する前景オブジェクトの位置との間の差に基づいて前記パッチをソートするステップと、
前記背景モデルおよびソートされた前記パッチをレンダリングするステップと、を有する方法。
【請求項11】
前記仮想視点に対する対応する前景オブジェクトの位置に基づいて前記パッチをグループ化するステップをさらに有する、請求項10に記載の方法。
【請求項12】
前記背景モデルおよびソートされた前記パッチをレンダリングする前記ステップが、
前記背景モデルをレンダリングステップと、
第1のパッチグループをワーピングおよび/またはブレンディングするステップと、
ワーピングおよび/またはブレンディングされた前記第1のパッチグループをレンダリングされた前記背景モデル上に合成するステップと、
第2のパッチグループをワーピングおよび/またはブレンディングするステップであって、前記仮想視点に対する前記第2のパッチグループに対応する前景オブジェクトの位置が、前記第1のパッチグループに対応する前景オブジェクトの位置よりも仮想視点に近い、ステップと、
ワーピングおよび/またはブレンディングされた前記第2のパッチグループを、ワーピングおよび/またはブレンディングされた前記第1のパッチグループ上に合成するステップと、
を有する、請求項11に記載の方法。
【請求項13】
処理システムを有する計算装置上で実行され、請求項1から8のいずれか一項に記載の方法、および/または、請求項10から12のいずれか一項に記載の方法を前記処理システムに実行させるコンピュータプログラムコードを有するコンピュータプログラム。
【請求項14】
請求項13のコンピュータプログラムを実行するように構成されたプロセッサ。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、マルチビュービデオの分野に関する。特に、本発明は、マルチビュービデオの生成およびマルチビュービデオのレンダリングのための奥行きセグメント化に関する。
【背景技術】
【0002】
奥行きを伴うマルチビュー画像からレンダリングする既存のアプローチは、ブレンディングを使用して複数のソースビュー(キャプチャ)カメラからのワープされたテクスチャを組み合わせる。ブレンディング演算は、ソースおよびターゲットカメラの位置/向き(例えば、光線角度差)、奥行きの大きさ、奥行きの変動、遮蔽解除、透明度および色などの変数に依存し得る。より高度な技術は、ターゲット視点におけるテクスチャを整列させるために、訓練された畳み込みニューラルネットワークを使用することもある。マルチビュー画像を記憶するためのいくつかのフォーマットがある。
【0003】
階層化奥行き画像(Layered Depth Images: LDI)は、単一の視線に沿った(1つだけではなく)奥行きピクセルのセットを記憶する。仮想視点がLDI記憶視点から離れると、遮蔽されていた表面が見えるようになる。
【0004】
マルチプレーン画像(MPI)およびマルチスフィア画像(MSI)技法は、3D空間内の平面または球面の所定のセットに対する色および透明度を構成する。そして、新しい仮想視点のために、画像は、背後から前方へのレイヤの合成を使用して構築される。
【0005】
レイヤメッシュ(Layered Mesh: LM)は、MPIおよびMSIから構築されることができ、テクスチャを有する従来のグラフィックスメッシュを表し、したがって、既存のビデオコーデックを使用するアトラス構築および送信に適している。
【発明の概要】
【発明が解決しようとする課題】
【0006】
階層化フォーマット(LDI、MPI、MSI、LM)は、明示的な遮蔽処理のために、潜在的に、より大きな視域をもたらすことができるが、これらのフォーマットは特に、リアルタイムで、マルチカメラシステムから生成することが困難である。
【0007】
Loghman Maziar et al"Segmentation-based view synthesis for multi-view video plus depth"、Multimedia Tools and Applications、Kluwer Academy Publishers Boston vol. 74, no. 5, 8 November 2013は、ソース画像からオブジェクトをセグメント化し、セグメント化されたオブジェクトを個々にワーピングすることによる画像合成のための方法を開示している。
【課題を解決するための手段】
【0008】
本発明は、請求項により規定される。
【0009】
本発明の一態様による例によれば、マルチビュービデオデータを生成するための奥行きセグメント化の方法が提供され、当該方法は、
複数のセンサからの3Dシーンを表す複数のソースビュー画像およびソースビュー奥行きマップを取得するステップと、ソースビュー画像および/またはソースビュー奥行きマップから3Dシーン内の前景オブジェクトをセグメント化するステップと、少なくとも1つの前景オブジェクトを含む各ソースビュー画像およびソースビュー奥行きマップについて1つまたは複数のパッチを生成するステップとを有し、各パッチが前景オブジェクトに対応し、パッチを生成するステップが、ソースビュー画像およびソースビュー奥行きマップに基づいてパッチテクスチャ画像、パッチ奥行きマップおよびパッチ透明度マップを生成することを含む。
【0010】
マルチビュービデオのための典型的なフォーマットは、各ピクセルの奥行き値を推定するために典型的に必要とされる複雑な分析のために、(例えば、階層化された奥行き画像、マルチプレーン画像などを)生成するためにかなりの処理能力を必要とする。例えば、これを行うためのロバストなアルゴリズムを見つけることができないことは、ディープラーニングに基づくデータ駆動型アプローチの使用の増加をもたらした。この問題は特に、データ削減のための奥行きおよびテクスチャアトラスデータの作成は各フレームに対してリアルタイムで行われなければならないので、ライブスポーツイベントなどのマルチビュービデオのブロードキャストにおいて存在する。
【0011】
したがって、本発明者は、前景オブジェクトを含むソースビュー(すなわち、画像および奥行きマップ)からパッチを「セグメント化」することを提案した。したがって、アトラスは、全てのソースビューのためのデータではなく、パッチ(およびバックグラウンド)からのデータのみを含む。各パッチは、ソースビュー画像自体よりも小さいソースビュー画像のセクションと、そのセクションの対応する奥行きおよび透明度データとに基づく。言い換えれば、各パッチは、シーンの任意の部分に対応するソースビューを使用する代わりに、シーンをレンダリングするために使用される前景オブジェクトに対応するテクスチャ、透明度、および奥行きデータを有する部分ソースビューとして機能する。パッチは、互いに重なり合うことができる。それぞれのパッチは同じサイズを有してもよく、あるいは(例えば、それらの対応する前景オブジェクトに応じて)異なるサイズを有してもよい。場合によっては、例えば、それらがソースビュー画像の同じセクションに基づく場合(たとえば、特定のセクションが2つ以上の前景オブジェクトを含む場合)、異なるパッチは同一のパッチテクスチャ画像およびパッチ奥行きマップを有し得る。
【0012】
ソースビュー画像またはソースビュー奥行きマップのいずれかから前景オブジェクトをセグメント化するための様々な方法が存在する。例えば、前景オブジェクトを検出/セグメント化するために、ソースビュー画像上でセグメンテーションアルゴリズムまたはオブジェクト検出アルゴリズムを使用することができる。代替的に、前景オブジェクトのエッジが大きい奥行き差によって定義され得るように、ソースビュー奥行きマップにおける(閾値を超える)奥行き差が計算されることができる。マルチビュービデオの場合、(ソースビュー画像またはソースビュー奥行きマップのいずれかの)フレーム間の差を使用して、前景オブジェクトの動きを検出して、前景オブジェクトを検出することができる。
【0013】
したがって、パッチは、各ソースビュー内の前景オブジェクトに対して生成されることができる。各パッチは、単一の前景オブジェクトに対応する。特に、パッチの範囲は、少なくとも部分的に、オブジェクト(またはオブジェクトの一部)の範囲によって決定され得る。しかしながら、前景オブジェクトは、2つ以上の対応するパッチを有することができる。あるいは、各前景オブジェクトが単一のパッチに関連付けられることができる。パッチは、パッチのテクスチャ/色データを含むパッチテクスチャ画像と、パッチの奥行きデータを含むパッチ奥行きマップとを有する。パッチは、パッチ内の各ピクセルの透明度値を含むパッチ透明度マップ(パッチアルファマップとも呼ばれる)も有する。
【0014】
この方法は、3Dシーンの背景を表す3Dシーンの複数の背景奥行きマップを取得することを含み、背景奥行きマップは、特定の向きからの背景の奥行きデータを含み、前景オブジェクトをセグメント化することは、背景奥行きマップと対応するソースビュー奥行きマップとの間の差に基づく。
【0015】
例えば、ソースビュー画像自体に基づいてセグメント化する場合、生成されたパッチは、奥行き境界を越えてにじむ可能性が高い。これは、符号化または後のレンダリングにおいて問題を引き起こす可能性がある。したがって、背景奥行きマップを使用することによって、前景オブジェクトをロバストにセグメント化することができ、これらの問題を回避することができる。
【0016】
各ソースビューの背景奥行きマップは、予め定義された幾何学的シーンモデルをソースビューのサブセットにフィッティングすることによって取得されることができる。例えば、背景が水平な地表面プレーンおよび垂直な背景プレーンからなると仮定すると、これらのプレーンが最初に配置され、画像ベースのマルチビューマッチング基準が最小化されるように、互いに対しておよびカメラに対してシフト/回転され得る。事前定義された幾何学的シーンをソースビューのサブセットにフィッティングした後、背景奥行きマップを各ソースビューについてレンダリングすることができる。
【0017】
背景奥行きマップは、3Dシーンの背景の奥行きデータを含む。例えば、背景奥行きマップは、異なる角度から3Dシーンを撮像する複数のカメラのビューに基づいて生成され得る。背景奥行きマップは、ソースビューを取得するために使用されるカメラとは異なるカメラのセットから生成され得る。例えば、3Dシーンがサッカー場である場合、サッカー場のサイドのカメラを使用して前景オブジェクト(すなわち、プレーヤおよびボール)を撮像することができ、サッカー場を上から見るカメラ(例えば、トップダウンカメラ)を使用して背景奥行きマップを生成することができる。
【0018】
前景オブジェクトは、ソースビュー奥行きマップと各ソースビューの背景奥行きマップとの間の差を閾値処理することによってセグメント化されることができる。このグローバル閾値の後、第2の局所的な閾値処理が、相対的な奥行きステップに基づいて、別個の接続された前景オブジェクトに適用され得る。
【0019】
訓練された人間検出アルゴリズムを使用して、前景オブジェクトを検出することができる。ボール検出器は、スポーツゲームにおいてボールを検出するために使用することができる。前景オブジェクト検出をさらに改善するために、動き推定または時間フレーム差分を使用することができる。
【0020】
本方法は、背景奥行きマップと背景テクスチャデータとを備える背景モデルを取得することをさらに含むことができる。
【0021】
本方法は、パッチテクスチャ画像、パッチ奥行きマップ、パッチ透明度マップおよび背景モデルに基づいてアトラスを生成することをさらに含むことができる。例えば、アトラスは、パッチテクスチャ画像、パッチ奥行きマップ、パッチ透明度マップ及び背景モデルを含むことができる。
【0022】
アトラスは、本質的に、様々な画像及び/又はマップ(例えば、テクスチャ、奥行き及び透明度データ)を含むデータマトリックスである。アトラス内の画像またはマップを見つけるために、各画像の「座標」(すなわち、マトリックスの列値および行値)が指定される。したがって、アトラスは複数のソースビューからのデータを含む。
【0023】
典型的には、パッチデータは全て別々にアトラスに含まれる。しかしながら、例えば、パッチ透明度マップをバイナリ(すなわち、0または1の透明度値)で定義し、奥行きマップ内の予約値を介して符号化することも可能である。
【0024】
前景オブジェクトを検出することは、ソースビュー奥行きマップからそれぞれの背景行きマップを減算して差分画像を生成することと、差分画像を閾値処理することとを含むことができ、閾値処理は、差分画像のピクセル値を閾値と比較して閾値マップを生成し、それによって背景オブジェクトと前景オブジェクトとを区別することを含むことができる。奥行きステップに対応するソースビュー奥行きマップ中のピクセルが識別され、奥行きステップは、奥行き閾値よりも大きいソースビュー奥行きマップ中の隣接する奥行き値間の差によって定義される。奥行きステップに対応する全ての奥行き値は、閾値マップにおいて調整され、それによって、前景オブジェクトを互いに区別し、調整された閾値マップに基づいて前景オブジェクトのための境界ボックスが生成される。
【0025】
差分画像を閾値処理することにより、ピクセル値「1」が前景を意味し、「0」が背景を意味するバイナリマップが得られる。前景オブジェクトを識別するために、接続されたコンポーネントが、4つ接続された又は8つ接続されたコンポーネントをラベリングするアルゴリズムを介して識別される。これを最初の閾値処理演算の直後に行うと、複数の前景オブジェクトが1つのオブジェクトとして誤って識別されることになる。これを回避するために、例えば、元のソースビュー奥行きマップの空間微分が分析される。奥行きステップが「奥行き閾値」を超える場合、バイナリマップはステップの遠い側で「0」(すなわち、背景)に設定される。結果として得られるバイナリマップが接続コンポーネントラベリングアルゴリズムに入力されると、前景オブジェクトは異なるラベルを受け取ることができる。
【0026】
パッチのサイズおよび位置は、境界ボックスのサイズおよび位置に基づき得る。
【0027】
背景奥行きマップの奥行き値は、全ての値をソースビュー奥行きマップ内に存在する前景オブジェクトから離れたゼロ(又はゼロの近く)にするために、ソースビュー奥行きマップから減算される。そして、減算されたマップは、例えば、背景に対応する奥行き値の全てをゼロ(または黒)に設定し、前景オブジェクトに対応する奥行き値の全てを1(または白色)に設定するために、「閾値」に基づいて閾値処理される。
【0028】
奥行きステップは、ソースビュー奥行きマップにおいても識別される。奥行きステップは、隣接する/隣り合うピクセルの奥行きの大きな変化に対応し、前景オブジェクトのエッジを示す。奥行きステップは、奥行き閾値よりも大きい(例えば、正規化された奥行きマップにおいて0.1よりも大きい)隣接する奥行き値間の差によって識別されることができる。
【0029】
そして、閾値マップの奥行き値は、各前景オブジェクトのエッジを強調し区別するために、奥行きステップにおいて、例えば、ゼロ(または黒)になるように調整され得る。境界ボックスは、調整された閾値マップに基づいて、各前景オブジェクトに対して生成される(例えば、調整された閾値マップ内の前景オブジェクトをセグメント化する)。
【0030】
パッチのサイズおよび位置は、境界ボックスのサイズおよび位置とすることができる。あるいは、1つの境界ボックスに対して複数のパッチを生成することができる。例えば、境界ボックス当たりのパッチの数は、境界ボックスのサイズ、前景オブジェクトのタイプ、前景オブジェクトの位置などに依存し得る。
【0031】
前景オブジェクトを検出することは、境界ボックスを拡張し、それによって、閾値未満の減算されたマップにおける前景オブジェクトの領域を含めることをさらに含み得る。
【0032】
たとえば、境界ボックスを拡張することは、ソースビュー奥行きマップと背景奥行きマップとの間の差が前景オブジェクトを含む領域について閾値未満であることに基づいてよく、境界ボックスは各前景オブジェクトが境界ボックスによって囲まれるように拡張される。
【0033】
いくつかの事例では、前景オブジェクトが背景の奥行き値に近い奥行き値を有する部分を有する場合がある。したがって、閾値処理の間、前景オブジェクトは小さく見え、境界ボックスソースビュー内の前景オブジェクトを完全には囲まない可能性がある。
【0034】
例えば、サッカー選手の足は、彼らが立っているサッカーフィールドに近い奥行きを有する。これらの場合、境界ボックスは、前景オブジェクトに対応する境界ボックスが前景オブジェクトを完全に囲むように拡張される(例えば、下方に拡張される)。
【0035】
パッチテクスチャ画像およびパッチ透明度マップを生成することは、ソースビュー画像をアルファマッティングすることに基づき得る。アルファマッティングは、画像から前景を抽出することに基づく。したがって、アルファマッティングを使用して、パッチの各ピクセルのテクスチャおよび透明度(アルファ値)を推定することができる。
【0036】
本方法は、パッチ奥行きマップのピクセル奥行き値を、パッチ奥行きマップのピクセル奥行き値の全てが、対応する前景オブジェクトの奥行き値と等しいかまたはそれよりも低い値からなるように適応させることをさらに含むことができる。
【0037】
一貫性および明瞭さのために、本出願で定義される任意の奥行きマップは、最大値(たとえば、255)が視点までの最も近い距離(すなわち、最小の奥行き値)を表し、最小値(たとえば、0)が最も遠い距離(すなわち、最大の奥行き値)を表すように構成される。奥行きマップ中のピクセルの値に関する本出願における「より小さい」または「より大きい」についてのいかなる言及も、前述の定義に関して解釈されるべきである。しかしながら、奥行きマップを表す任意の他のフォーマットも使用されることができ、当業者に知られていることに留意されたい。例えば、「0」ピクセルは最も近い距離を表し得、「1」値は最も遠い距離を表し得る。
【0038】
いくつかのパッチ奥行きマップは、対応する前景オブジェクトを遮蔽する他の前景オブジェクトからの奥行きデータを含み得る。「望ましくない」(または残された)奥行きデータは、前景オブジェクトをレンダリングするときにアーチファクトを引き起こす可能性がある。したがって、ピクセル奥行き値の全てがターゲット前景オブジェクト(すなわち、問題のパッチ奥行きマップに対応する前景オブジェクト)の奥行き値以上であるように、パッチ奥行きマップのピクセル奥行き値を適応させる(すなわち、ピクセル値を変更する)ことが有益であり得る。
【0039】
さらに、本方法は、オブジェクト奥行き範囲内の識別されたパッチのパッチ奥行きマップを識別することと、識別されたパッチ奥行きマップが3Dシーン内のオブジェクト位置に対応するように、それらを補正することとに基づいて、第1の前景オブジェクトに対応する異なるソースビューに由来する複数のパッチを識別することとをさらに含むことができる。
【0040】
たとえば、全てのビューのパッチ奥行きマップの重心位置を共通の世界空間座標系に投影することによって、パッチ奥行きマップを補正(たとえば、フィルタリング)することができる。類似の世界空間座標にマッピングする(すなわち、所与のオブジェクト間距離内の)異なるソースビューからのパッチは、おそらく、1つの同じ物理的前景オブジェクトから生じる。したがって、パッチ奥行きマップを補正することができる(すなわち、より類似した世界空間座標を有するようにする)。補正後、ソースビューへの逆投影は、パッチごとにフィルタリングされた奥行きマップをもたらす。
【0041】
本方法は、複数のソースビューにおけるパッチ間の一貫性を測定することに基づいて、パッチをプルーニングすることをさらに含み得る。例えば、本方法は、他のソースビューに十分な対応するパッチがない場合に(パッチが推定ノイズの結果として起こり得る孤立誤差であることを示す)、特定のパッチをフィルタリングして、それを除去することを含むことができる。
【0042】
これは、誤って検出された前景パッチを識別するのに役立ち得る。例えば、共通世界座標系にパッチを投影した後、パッチの最小世界空間(ユークリッド)距離よりも近い他のソースビューからのパッチの数を計算することができる。この数がパッチ数閾値(例えば、ソースビューの数の所与の割合)よりも小さい場合、パッチは廃棄される。たとえば、「前景オブジェクト」が8つのソースビューのうちの3つ未満でしか識別されない場合、その特定の前景オブジェクトのパッチは破棄される。パッチが破棄されると、アトラスでは使用されない。
【0043】
1つまたは複数のパッチを生成することは、ソースビュー奥行きマップ中のサブ領域を識別することと、サブ領域中に存在する異なる奥行きの奥行き表面の数を決定することと、サブ領域中の奥行き表面ごとにパッチを生成することとを含むことができ、各パッチは異なるパッチ透明度マップを有する。
【0044】
代替的にまたは追加として、1つまたは複数のパッチを生成することは、ソースビュー画像中のサブ領域を識別することを含むことができる。
【0045】
本発明はさらにシステムを提供し、当該システムは、コンピュータデバイス上で実行されるとコンピュータシステムに前述の方法を実行させるコンピュータプログラムコードを含む1つまたは複数のプロセッサと、ソースビュー画像およびソースビュー奥行きマップを取得するように構成された複数のセンサとを有する。
【0046】
本発明は、マルチビュービデオをレンダリングするための方法を提供し、当該方法は、
複数のパッチおよび3Dシーンの背景モデルを有するアトラスを受信するステップであって、各パッチは前景オブジェクトに対応し、各パッチが、パッチテクスチャ画像、パッチ奥行きマップ、ならびに、ソースビュー画像およびソースビュー奥行きマップから導出されたパッチ透明度マップを有する、ステップと、
3Dシーン内の仮想視点を受信するステップと、
仮想視点の位置と各パッチに対応する前景オブジェクトの位置との間の差に基づいてパッチをソートするステップと、背景モデルおよびソートされたパッチをレンダリングするステップと、を含む。
【0047】
このレンダリング方法は、仮想視点に対する対応する前景オブジェクトの位置に基づいてパッチをグループ化することをさらに含むことができる。
【0048】
背景モデルおよびソートされたパッチをレンダリングするステップは、背景モデルをレンダリングするステップと、第1のパッチグループをワーピングおよび/またはブレンドするステップと、ワーピングおよび/またはブレンドされた第1のパッチグループをレンダリングされた背景モデル上に合成するステップと、第2のパッチグループをワーピングおよび/またはブレンドするステップであって、仮想視点に対する第2のパッチグループに対応する前景オブジェクトの位置は第1のパッチグループに対応する前景オブジェクトの位置よりも仮想視点に近い、ステップと、ワーピングおよび/またはブレンドされた第2のパッチグループをワーピングおよび/またはブレンドされた第1のパッチグループ上に合成するステップとを有する。
【0049】
本方法は、アトラス内の各パッチの位置およびジオメトリと、ソースビュー画像および/またはソースビュー奥行きマップ内の各パッチの位置およびジオメトリとを含むメタデータを受信することをさらに含むことができ、パッチをレンダリングすることは位置およびジオメトリの両方に基づく。
【0050】
また、本発明は、処理システムを有するコンピューティングデバイス上で実行されると、マルチビュービデオデータの生成のための奥行きセグメント化方法及び/又はマルチビュービデオのレンダリング方法の全てのステップを処理システムに実行させるコンピュータプログラムコードを含むコンピュータプログラム製品と、前記コンピュータプログラムコードを実行するように構成されたプロセッサとを提供する。
【0051】
本発明のこれらおよび他の態様は、以下に記載される実施形態から明らかになり、これを参照して説明される。
【図面の簡単な説明】
【0052】
本発明をより良く理解し、本発明をどのように実施することができるかをより明確に示すために、単なる例として、添付の図面を参照する。
図1】マルチビュービデオのための奥行きセグメンテーションの方法を示す図。
図2】ソースビュー画像およびソースビュー奥行きマップを示す図。
図3図2の三角形オブジェクトに対応するパッチを示す図。
図4】パッチを生成するための第1のプロセスを示す図。
図5】3つの前景オブジェクトを有するソースビュー奥行きマップを示す図。
図6】単一の領域に対して生成された4つのパッチ透明度マップを示す図。
図7】アトラスからパッチグループをワープしてブレンドするステップを示す図。
図8】2つのソースビューと2つのターゲットビューを有する3Dシーンを示す図。
【発明を実施するための形態】
【0053】
本発明は、図面を参照して説明される。
【0054】
詳細な説明および特定の例は、装置、システムおよび方法の例示的な実施形態を示しているが、例示のみを目的としたものであり、本発明の範囲を限定することを意図したものではないことを理解されたい。本発明の装置、システム及び方法のこれら及び他の特徴、態様、及び利点は、以下の説明、添付の特許請求の範囲、及び添付の図面からより良く理解されるであろう。図面は単に概略的なものであり、一定の縮尺で描かれていないことを理解されたい。また、同じ参照番号が、同じまたは類似の部分を示すために、図面全体にわたって使用されることを理解されたい。
【0055】
本発明は、マルチビュービデオデータを生成するための奥行きセグメント化の方法を提供する。本方法は、複数のセンサから3Dシーンを表す複数のソースビュー画像およびソースビュー奥行きマップを取得することを含む。3Dシーン内の前景オブジェクトは、ソースビュー画像(102)および/またはソースビュー奥行きマップ(104)からセグメント化される。そして、少なくとも1つの前景オブジェクトを含む各ソースビュー画像およびソースビュー奥行きマップについて1つまたは複数のパッチが生成され、各パッチは1つの前景オブジェクトに対応し、パッチを生成することは、ソースビュー画像およびソースビュー奥行きマップに基づいて、パッチテクスチャ画像、パッチ奥行きマップ、およびパッチ透明度マップを生成することを含む。
【0056】
図1は、マルチビュービデオのための奥行きセグメンテーションの方法を示す。この方法は、マルチビュービデオをレンダリングするために必要な全てのデータを含むアトラス112を作成することに基づく。通常、複数のソースビューが、マルチビュー画像フレームをレンダリングするために必要である。各ソースビューは、通常、ソースビュー画像102とソースビュー奥行きマップ104とを有する。奥行きマップ104は、マルチビュー画像ベースのマッチングを使用して、または代替として、(ソースビューデータを取得するために使用される)マルチカメラシステムセットアップに1つまたは複数の奥行きセンサ(たとえば、レーザ奥行きセンサ)を追加し、そして各ソースビューにおいて測定された奥行きをワーピングすることによって、導出されることができ、その後、フィルタリング/穴埋めを使用して、奥行きマップを各ソースビューについて完全にすることができる。
【0057】
本発明者は、グローバルに決定された背景モデル106との差に基づいて、全てのソースビュー奥行きマップ104をセグメント化することを提案する。背景モデル106は、各ソースビューの背景奥行きマップを生成するために使用される。そして、前景オブジェクト108は、背景奥行きマップおよびソースビュー奥行きマップ104のピクセル間の相対的奥行き差に基づいてさらにセグメント化される。単一の階層表現を生成する代わりに、前景オブジェクト108のセグメント化されたパッチ110は、全てのソースビューに対して保持され、アトラス112内に一緒にパックされる。
【0058】
クライアント装置は、新しい仮想視点のz軸に沿ってパッチ110をソートすることができる。そして、ビュー合成アルゴリズムは、パッチ110にこの順序でアクセスし、これらのパッチ110が同様の奥行きを有する場合に異なるソースビューからのパッチ110をブレンドすることと、ブレンドされたビューを前に合成された出力上に合成することを交互に行うことができる。
【0059】
図2は、ソースビュー画像102およびソースビュー奥行きマップ104を示す。図2(a)はソースビュー画像102を示し、図2(b)は、ソースビュー奥行きマップ104を示す。ソースビュー画像102およびソースビュー奥行きマップ104は、背景206および2つの前景オブジェクト(すなわち、矩形202および三角形204)を含む3Dシーンのものである。図2(b)に見られるように、背景206の深さは変化し、2つのオブジェクト202および204の深さは一定のままである。矩形オブジェクト202の下側のセクションは、背景206の最も近いセクションと同様の深さを有する。
【0060】
図3は、(図1に示されるような)三角形オブジェクト204に対応する(図1に示されるような)パッチ110を示す。各パッチ110について、パッチテクスチャ画像302、パッチ奥行きマップ306、およびパッチ透明度マップ304(たとえば、アルファチャネル)が生成される。図3(a)は、三角形オブジェクト204のパッチテクスチャ画像302を示す。図3(b)は、図2の三角形オブジェクト204に対応するパッチ透明度マップ304を示し、パッチ透明度マップ304の黒い部分は完全に透明な領域を示し、白い部分は不透明な領域を示す。図3(c)は、三角形オブジェクト204のパッチ奥行きマップ306を示す。
【0061】
パッチテクスチャ画像302およびパッチ奥行きマップ306は、パッチ110に対応するセクションにおいて、ソースビュー画像102(図2)およびソースビュー奥行きマップ104(図2)からデータを直接コピーすることによって生成されることができる。透明度値は三角形オブジェクト204が存在する場所では1に、存在しない場所では0に設定することができる。
【0062】
あるいは、より正確なアルゴリズムを使用して、各パッチ110について前景色およびいわゆるアルファマッティングを使用したアルファ(透明度)を推定することができる。その場合、ピクセルiの色は、ピクセルの透明度値αに基づくローカル前景色Fと背景色Bとの以下のような線形結合であってもよい:
【数1】
【0063】
トリマップは、各パッチ110内のピクセルごとのオブジェクトコンポーネントラベルマップに基づいて構築されることができる。トリマップは、クラス「確実に前景」(α=1)、「確実に背景」(α=0)および「不確定」(αが推定される必要がある)で構成される。そして、アルファマッティングアルゴリズムが、不確定であるピクセルについてαiおよびFiの両方を推定する。
【0064】
パッチ奥行きマップ306が奥行き画像ベースのレンダリングのために使用される場合、三角形オブジェクト204は、矩形の「残部」の後ろに覆われる場合がある(例えば、図3(c)の左下の長方形の部分)。これは、この残された領域のピクセルが三角形オブジェクト204のピクセルよりもカメラに近いためである。これは、各頂点がパッチ奥行きマップ306に依存する三角形メッシュを使用してパッチ110をレンダリングするビュー合成ロジックに関係する。
【0065】
この問題を解決するために、他のパッチ110の「残された」領域が少なくともパッチ110の対応する前景オブジェクトのローカル前景よりも遠い奥行き値に変更されるように、パッチ奥行きマップ306を処理することが有利である。図3(c)の修正されたパッチ奥行きマップ308は、三角形オブジェクト204の外側の全てのピクセルを、全ての有効なオブジェクトピクセルにわたってとられる最小値に等しい奥行き値に単に設定する単純な方法を示す。この例では、修正されたパッチ奥行きマップ308全体が三角形オブジェクト204が有する一定の奥行きを受け取る。あるいは、三角形オブジェクト204に対応しない全てのピクセルが、三角形オブジェクト204に対応する任意の奥行き値よりも低い奥行き値に設定されてもよい。
【0066】
この例では、オブジェクト領域の外側であって矩形の内側の奥行きピクセルを修正するアプローチが、クライアントレンダリングシステムの設計に起因する。クライアントレンダリングアプリケーションは、典型的には、各矩形を単一の規則的なメッシュ全体としてワープする(どのピクセルが背景に対応するかを無視する)。カメラに近いオブジェクト領域の外側のピクセルは、メッシュがオブジェクト自体の上に折り返されることになる。
【0067】
あるいは、いわゆるジオメトリシェーダを使用して、レンダリング中に三角形を選択/切り取り、オブジェクトラベルを有するピクセルのみがワープされるようにすることができる。しかしながら、これは、リアルタイムレンダラの実装に関してより複雑である。
【0068】
三角形オブジェクト204の奥行きが変化しないか、またはわずかにしか変化しない場合、パッチ奥行きマップ306は、マップとして記憶される必要はなく、スカラー奥行き値がパッチ110全体について示されることができる。
【0069】
図4は、パッチ110(図1)を生成するための第1のプロセスを示す。各ソースビューは、関連する背景奥行きマップ106(図1)を有すると仮定される。スポーツスタジアムの場合、これは、スタジアムの幾何学的モデルと組み合わされた地表面モデルの奥行きマップレンダリングであってもよい。図4(a)は、2つの前景オブジェクト202および204(例えば、スポーツ選手)を有するソースビュー奥行きマップ104を示す。前景オブジェクト202および204は、推定されたソースビュー奥行きマップ104から背景モデル106の奥行きを減算し、結果を閾値処理することによって検出されることができる。図4(b)は、閾値処理されたマップ402を示す。図4(b)から分かるように、互いに遮蔽する前景オブジェクト202および204は、(バイナリ)閾値マップ402においてまだ一緒に結合している。
【0070】
結合されたオブジェクトを分離するために、奥行きステップエッジピクセルが検出され、例えばゼロに設定される。図4(c)は、奥行きステップピクセルがゼロに設定された閾値マップ404を示す。ローカル背景ピクセルのバイナリマスクは、奥行きステップの境界をゼロに設定され、ローカル前景に対応するピクセルではないことに留意されたい。これは、前景ピクセルが失われるのを防ぐために行われる。連続的に接続されたコンポーネントのラベリングが、前景オブジェクト202および204を背景206から、および互いからセグメントに分離する。図4(d)は、各オブジェクトにラベル付けされたセグメント(0としてラベル付けされた背景206、1としてラベル付けされた三角形オブジェクト204、および2としてラベル付けされた矩形オブジェクト202)を有する画像406を示す。
【0071】
そして、境界ボックス408が、各セグメントについて検出されることができる。図4(e)は、前景オブジェクト202および204のための境界ボックス408を有するソースビュー奥行きマップ104を示す。そして、各境界ボックス408は、背景206の地面の奥行きに接触する(またはその付近にある)矩形オブジェクト202のセクションを含むように、垂直下方にさらに拡張され得る。図4(f)は、拡張された境界ボックス410を有するソースビュー奥行きマップ104を示す。そして、パッチ110は、境界ボックス408および/または拡張された境界ボックス410に基づいて決定されることができる。境界ボックス408を拡張することにより、境界ボックス408は(例えば、前景オブジェクト202および204の一部が背景206に近いために)閾値化ステップでカットオフされた前景オブジェクト202および204の任意の部分をさらに囲むことができる。
【0072】
図5は、3つの前景オブジェクト202、204および502を有するソースビュー奥行きマップ104を示す。3つ全ての前景オブジェクトを含むソースビュー奥行きマップ104のサブ領域506を画定する矩形グリッド504が示されている。
【0073】
パッチ110(図1)を生成するステップのための代替的なアプローチは、図5に示されるサブ領域506などのサブ領域506を使用する。サブ領域506に存在する奥行き面の数に応じて、1つまたは複数のパッチ110が、サブ領域506に対応して構築される。図5は、サブ領域506内の全ての奥行き面(すなわち、背景206、ならびに3つの前景オブジェクト202、204および502)をモデル化するために4つのパッチが必要とされる例示的なサブ領域506を示す。
【0074】
サブ領域506ごとに複数のパッチを有することで、複数のパッチが同じパッチテクスチャ画像302、および潜在的に同じパッチ奥行きマップ304を共有することを可能にし、したがって、ブロードキャストされる必要があるデータの全体量を低減する。さらに、パッチ間の空間的関係は、各パッチの位置を規定する必要がある代わりに、(サブ領域506の)グリッドによって規定することもできる。
【0075】
背景モデル106(図1)から生成される背景奥行きマップは、前景オブジェクト108をセグメント化するために使用されることができるが、必須ではない。図5の例では、背景モデルの代わりに、ソースビュー奥行きマップ104中のピクセルの奥行き値に基づくピクセルの分類、クラスタ化および/またはビニングを使用して、それぞれのセグメントを特定し、それにより、サブ領域506ごとに複数のパッチを生成することができる。
【0076】
サブ領域506の数および位置は、たとえば、ソースビュー画像102(図1)またはソースビュー奥行きマップ104中の前景オブジェクトを検出するオブジェクト検出アルゴリズム(または同様のもの)に依存し得る。あるいは、サブ領域506の数および位置は、前景オブジェクト202、204および502の既知の位置に基づいて固定されてもよい。
【0077】
図6は、単一のサブ領域506(図5)に対して生成された4つのパッチ透明度マップを示す。4つのパッチ透明度マップ602、604、606および608は全て、図5に示されるサブ領域506のためのものであり、それぞれ異なるパッチ110(図1)に対応する。この例では、4つのパッチ110(したがって、4つのパッチ透明度マップ)は、サブ領域506に4つの奥行き面(背景および3つのオブジェクト)が存在するために、単一のサブ領域506に対して生成される。
【0078】
図6(a)は、細いオブジェクト502(図5)に対する第1のパッチ透明度マップ602を示す。図6(b)は、矩形オブジェクト202(図5)に対する第2のパッチ透明度マップ604を示す。図6(c)は、三角形オブジェクト204(図5)に対する第3のパッチ透明度マップ606を示す。図6(d)は、背景206(図5)に対する第4のパッチ透明度マップ608を示す。
【0079】
したがって、ソースビュー奥行きマップ104の領域が複数の奥行き面を含むとき、複数のパッチ110が生成され得る。それぞれの面が別個のパッチ110をもたらす。図6には透明度(アルファ)マップのみが示されているが、パッチテクスチャ画像302(図3)は、4つのパッチ110全てについて同じであるため、一度だけ記憶される必要がある。さらに、いくつかのパッチ110についてはスカラー奥行きマップで十分であり、他のパッチについては(差分)パッチ奥行きマップが必要とされ得る。
【0080】
単一の背景モデル106(ビデオスプライトテクスチャおよび奥行き)が、前景パッチ110が除去された場所が知られているという事実を考慮し、これを使用して任意のギャップを埋めることによって、ソースビューから構築され得る。例えば、複数のカメラがホッケーゲームを撮像するとき、地面および視聴者のみを含むがプレーヤは含まない単一の背景スプライト画像を生成することができる。この単一の背景スプライトは、ソースビューよりも広い視野を有する透視投影によってモデル化されることができる。背景スプライト及び奥行きは、ソースビューパッチ110と共に単一のアトラス112にパッキングされることができる(図1)。
【0081】
ビュー合成
パッチ110のビュー合成は、複数のソースビューのための同じ前景オブジェクト108のパッチテクスチャ画像302、パッチ透明度マップ304(図3)およびパッチ奥行きマップ306(図3)を含むアトラス112のデータを復号した後に開始する。例えば、前景オブジェクト108が、合計8つのソースビューのうちの5つのみで見える場合がある。背景モデル106は、3Dシーンにおいて常に最も遠いオブジェクトであることが知られているので、他の全てのパッチ110の前にレンダリングされる。
【0082】
(3Dシーンがそこから観察される位置および向きを定義する)ターゲットビューマトリクスが与えられると、パッチ110は仮想視点からの距離(z軸)に基づいて、最初に減少する順序でソートされる。そして、ソートされたパッチはパッチグループを形成し、ここで、グループ内のz座標の変動は、典型的にはパッチグループ間のz座標の変動よりも小さい。複数のソースビューからのパッチ110が仮想視点に応じて同じグループになることに留意されたい。
【0083】
そして、ビュー合成は、パッチグループをワーピングおよび/またはブレンドすることと、ブレンドされた結果を前の合成結果に合成することとを交互に行う。
【0084】
図7は、アトラス112からのパッチグループをワーピングし、ブレンドするステップを示す。アトラス112からパッチグループ内の図1に示されるパッチ110(すなわち、パッチテクスチャ画像302、パッチ透明度マップ304(図3)、およびパッチ奥行きマップ306)をフェッチした後、パッチ110は、ターゲットビューマトリクスを使用して、その関連するソースビューバッファにワープされる。そして、結果は、ターゲットビュー画像座標に直接表される。
【0085】
説明のために、パッチテクスチャ画像302およびパッチ奥行きマップ306のみがアトラス112に示されている。パッチ透明度マップ304は、同様にアトラス112に含まれていてもよく、または例えばパッチ奥行きマップ306に埋め込まれてもよい。
【0086】
各パッチ110は、その関連するソースビューバッファ702にワープされ、ソースビューバッファ702の全て(またはいくつか)は、他のパッチグループが合成されていない場合は背景モデル106(図1)上に、または(パッチグループがすでに合成されている場合には)以前に合成された画像704上に、パッチグループに対応する前景オブジェクト108を合成するために使用される。
【0087】
前景オブジェクト108(図1)を合成するために使用されるソースビューバッファ702の数は、合成中に一定のメモリ使用を維持するために固定され得る。例えば、(ターゲットビューに対するソースビューの近接度に基づいて)ソースビュー画像のうちの8つのみが合成を実行するために選択され得る。
【0088】
図8は、2つのソースビュー800と、2つのターゲットビュー808および810とを有する3Dシーンを示す。図8(a)は第1のターゲット視点808を示し、図8(b)は、第2の視点810を示す。図8は、ターゲットビュー808または810の座標に基づいてクライアント側でパッチ110(図1)をソートする必要性を示す。ターゲットビュー808および810は、仮想視点または仮想ビューと呼ばれることもある。
【0089】
図8(a)に示される第1のターゲットビュー808について、オブジェクト804および806は、最初にワープされてブレンドされる同じパッチグループに入る。オブジェクト802は、第1のターゲットビュー808の座標に最も近く、したがって、最後にワープされ、ブレンドされ、合成される。
【0090】
しかし、これは、図8(b)に示される第2のターゲットビュー810では異なる。第2のターゲットビュー810の場合、オブジェクト806がオブジェクト802および804よりも第2のターゲットビュー810に近いので、オブジェクト802および804が最初にワープされ、ブレンドされ、合成されて、オブジェクト806は最後にワープされ、合成される。
【0091】
メタデータ
メタデータもパッチ110ごとに記憶されることができる。たとえば、各パッチ110について、ソースビュー識別子、ソースビュー位置およびサイズ(u0,v, v0,v, wv, hv)、ならびにアトラス112(図1)の位置およびサイズ(u0,a, v0,a, wa, ha)が記憶され得る。
【0092】
(u0,a, v0, a)がアトラス座標における矩形パッチ110の左下隅を表すものとする。したがって、所与のパッチサイズに対してワープされた矩形内にあるアトラス座標をサンプリングするだけでよい。正規化された座標(u, v)が領域[0,1]にあるとすると、矩形の点(u, v)の正規化されたアトラス座標(ua, va)は、次のように計算することができる:
【数2】
【0093】
アトラス座標(ua, va)は頂点シェーダ段階中にパッチ奥行きマップ306(図3)内の奥行き値にアクセスし、アトラス座標をフラグメントシェーダに渡すことによって色および透明度を補間するために使用される。
【0094】
しかしながら、パッチ110を出力ビューにワープするためには、矩形ソースビュー画像102(図1)の座標を知る必要がある場合がある。正規化された座標(u, v)が領域[0,1]にあるとすると、矩形の点(u, v)の正規化されたアトラス座標(uv, vv)は、次のように計算することができる:
【数3】
【0095】
正規化された座標が使用されるので、ソースビュー画像102および/または奥行きマップは、アトラス112に記憶されたピクセルよりも少ないまたは多いピクセルを有する場合があることに留意されたい。アトラス112内の固定ピクセルバジェットを用いて、パッチ110は、常に適合するようにスケーリングされることができる。
【0096】
当業者は、本明細書に記載の如何なる方法も実行するためのプロセッサを容易に開発することができる。したがって、フローチャートの各ステップは、プロセッサによって実行される異なるアクションを表し得、処理プロセッサのそれぞれのモジュールによって実行され得る。
【0097】
上述したように、システムは、データ処理を行うために処理器を利用する。処理器は、必要とされる様々な機能を実行するために、ソフトウェア及び/又はハードウェアを用いて、様々な方法で実施される。前記処理器は通例、ソフトウェア(例えば、マイクロコード)を用いて、必要とされる機能を行うようにプログラムされる1つ以上のマイクロプロセッサを用いる。処理器は、幾つかの機能を実行するための専用ハードウェアと、他の機能を実行するための1つ以上のプログラムされるマイクロプロセッサ及び関連する回路との組合せとして実施されてもよい。
【0098】
本開示の様々な実施形態に用いられる回路の例は、これらに限定されないが、従来のマイクロプロセッサ、特定用途向け集積回路(ASIC)及びフィールドプログラマブルゲートアレイ(FPGA)を含む。
【0099】
様々な実施において、前記処理器は、例えばRAM、PROM、EPROM及びEEPROMのような揮発性及び不揮発性コンピュータメモリである1つ以上の記憶媒体に関連付けられてよい。この記憶媒体は、1つ以上の処理器及び/又は制御器上で実行されるとき、必要とされる機能を実行する1つ以上のプログラムで符号化されてもよい。様々な記憶媒体は、処理器又は制御器内に取り付けられてもよいし、又は記憶媒体に記憶される1つ以上のプログラムが処理器に読み込まれるように、搬送可能でもよい。
【0100】
開示された実施形態に対する変形例は、図面、開示、および添付の特許請求の範囲の検討から、特許請求された発明を実施する際に当業者によって理解され、実施されることができる。請求項において、単語「有する」は、他の要素又はステップを排除するものではなく、不定冠詞「a」又は「an」は、複数性を排除するものではない。
【0101】
単一のプロセッサ又は他のユニットが、請求項に列挙されるいくつかの項目の機能を果たすことができる。 コンピュータプログラムは他のハードウェアと一緒に、またはその一部として供給される光記憶媒体またはソリッドステート媒体などの適切な媒体上に記憶/配布されることができるが、インターネットまたは他の有線もしくは無線電気通信システムなどを介して、他の形態で配布されることもできる。
【0102】
「に適応する」という用語が請求項又は明細書に用いられる場合、「に適応する」という用語は、「ように構成される」と言う用語と同様であることを意味する。
【0103】
請求項におけるいかなる参照符号も、範囲を限定するものとして解釈されるべきではない。
図1
図2a)】
図2b)】
図3a)】
図3b)】
図3c)】
図4a)】
図4b)】
図4c)】
図4d)】
図4e)】
図4f)】
図5
図6a)】
図6b)】
図6c)】
図6d)】
図7
図8a)】
図8b)】
【国際調査報告】