特表 2024-527269 マルチオブジェクト表面画像（ＭＵＬＴＩ ＯＢＪＥＣＴ ＳＵＲＦＡＣＥ ＩＭＡＧＥ：ＭＯＳＩ）フォーマット

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-07-24

(54)【発明の名称】マルチオブジェクト表面画像（ＭＵＬＴＩ ＯＢＪＥＣＴ ＳＵＲＦＡＣＥ ＩＭＡＧＥ：ＭＯＳＩ）フォーマット

(51)【国際特許分類】

   G06T 15/00 20110101AFI20240717BHJP

【ＦＩ】

G06T15/00 501

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023578063

(86)(22)【出願日】2022-07-12

(85)【翻訳文提出日】2023-12-19

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

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

(87)【国際公開日】2023-01-19

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

(32)【優先日】2021-07-14

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】590000248

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

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

【住所又は居所原語表記】Ｈｉｇｈ Ｔｅｃｈ Ｃａｍｐｕｓ ５２， ５６５６ ＡＧ Ｅｉｎｄｈｏｖｅｎ，Ｎｅｔｈｅｒｌａｎｄｓ

(74)【代理人】

【識別番号】100122769

【弁理士】

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

(74)【代理人】

【識別番号】100163809

【弁理士】

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

(74)【代理人】

【識別番号】100145654

【弁理士】

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

(72)【発明者】

【氏名】フェアカンプ クリスティアーン

(72)【発明者】

【氏名】ウィレムス アンディー

(57)【要約】

マルチビュー画像データを処理する方法。この方法は複数のセンサからソースビューデータを取得することを含み、ソースビューデータは1つまたは複数のオブジェクトを有するシーンのソーステクスチャデータおよびソース奥行きデータを含む。シーン内の1つまたは複数のオブジェクトの位置が取得され、オブジェクトのうちの少なくとも1つのために仮想シーン内にレイヤのスタックが生成され、仮想シーン内のレイヤのスタックの位置は、シーン内の対応するオブジェクトの位置に基づく。レイヤのスタックを生成することは、複数のレイヤを生成することを含み、各レイヤは対応するオブジェクトのテクスチャデータおよび透明度データを含む。

【特許請求の範囲】

【請求項1】

マルチビュー画像データを処理する方法であって、
複数のセンサからソースビューデータを取得するステップであって、前記ソースビューデータは、２つ以上のオブジェクトを伴うシーンのソーステクスチャデータおよびソース奥行きデータを含む、ステップと、
前記シーン中の少なくとも２つの前記オブジェクトの位置を取得するステップと、
位置が取得された前記２つ以上のオブジェクトのために仮想シーン中にレイヤの２つ以上のスタックを生成するステップと、
を有し、
レイヤの各スタックは異なるオブジェクトに対応し、
前記仮想シーン中のレイヤの各スタックの位置は前記シーン中の対応する前記オブジェクトの位置の基づき、
レイヤの各スタックを生成するステップが複数のレイヤを生成するステップを含み、各レイヤが、対応するオブジェクトのテクスチャデータおよび透明度データを含む、方法。

【請求項2】

前記仮想シーンにおけるレイヤの前記スタックの向きが、
前記シーン中の対応するオブジェクトの位置、
前記シーン中の対応するオブジェクトの向き、
対応するオブジェクトのジオメトリ、
対応するオブジェクトの先験的な知識、
前記複数のセンサの１つまたは複数の位置、
前記複数のセンサの１つまたは複数の向き、および
意図される観察ゾーンの位置、
のうちの１つまたは複数に基づく、請求項１に記載の方法。

【請求項3】

レイヤのスタックに対応する前記レイヤの形状が、
前記シーン中の対応するオブジェクトの位置、
前記シーン中の対応するオブジェクトの向き、
対応するオブジェクトのジオメトリ、
対応するオブジェクトの先験的な知識、
のうちの１つまたは複数に基づく、請求項１または２に記載の方法。

【請求項4】

前記シーン中の１つまたは複数のオブジェクトの位置の取得が、
前記シーンの背景の背景奥行きデータを含み、それにより前記背景の位置を含む前記シーンの背景モデルを取得すること、
前記ソース奥行きデータから前記背景奥行きデータを減算すること、
減算されたデータから前景オブジェクトを検出すること、および
前記仮想シーンにおける前記前景オブジェクトの位置を決定すること、
に基づき、
前記オブジェクトの位置が、前記背景の位置および前記前景オブジェクトの位置に基づく、
請求項１から３のいずれか一項に記載の方法。

【請求項5】

１つまたは複数の前記オブジェクトのためのレイヤの１つまたは複数の追加のスタックを生成し、それにより、レイヤの前記スタックおよびレイヤの前記追加のスタックの少なくとも１つを用いてターゲット観察空間中の任意の点から観察されたときに前記オブジェクトが十分に見えるようにするステップをさらに有し、第１のオブジェクトのためのレイヤの追加のスタックが、当該第１のオブジェクトのためのレイヤの前記スタックとは異なる向きを有し、ターゲット観察空間が、観察者がそこから前記仮想シーンを観察することができる前記仮想シーン中のサブ空間を定める、
請求項１から４のいずれか一項の方法。

【請求項6】

第１のオブジェクトの対応するレイヤの第１のスタックが、レイヤの当該第１のスタック中のレイヤが第２の異なるオブジェクトに対応するレイヤの第２のスタックのレイヤと交差するように生成される、請求項１から５のいずれか一項に記載の方法。

【請求項7】

既知のオブジェクトのセット中の各々の既知のオブジェクトのデータアロケーションを受信するステップと、
前記既知のオブジェクトの前記データアロケーションに基づいて第１の解像度および／または第１のフレームレートで前記既知のオブジェクトのためのレイヤのスタック中の前記レイヤを記憶するステップと、
をさらに有する、請求項１から６のいずれか一項に記載の方法。

【請求項8】

レイヤの前記スタックのためのメタデータを生成するステップをさらに有し、前記メタデータが、
レイヤの前記スタックの位置、
レイヤの前記スタックの向き、
レイヤの前記スタック中のレイヤの数、
レイヤ間の間隔、
前記レイヤのタイプおよび／または形状、ならびに
レイヤの前記スタックのダイナミクス、
のうちの１つまたは複数を含む、請求項１から７のいずれか一項に記載の方法。

【請求項9】

前記ソーステクスチャデータが複数のソースビュー画像を有し、レイヤの前記テクスチャデータおよび透明度データの生成が、前記ソースビュー画像からのテクスチャデータに基づく、請求項１から８のいずれか一項に記載の方法。

【請求項10】

前記ソースビューデータが前記シーンのテクスチャ画像および前記ソーステクスチャデータを有し、前記ソース奥行きデータが、前記テクスチャ画像に奥行き推定を実行することにより取得される、請求項１から９のいずれか一項に記載の方法。

【請求項11】

２つ以上のオブジェクトを伴うシーンを描写するマルチビュー画像データをレンダリングする方法であって、
仮想シーンのためのレイヤの２つ以上のスタックを受信するステップであって、レイヤの各スタックが異なるオブジェクトに対応し、前記仮想シーンにおけるレイヤの各スタックの位置が前記シーン中の対応するオブジェクトの位置に基づき、レイヤの各スタックが複数のレイヤを含み、各レイヤが対応するオブジェクトのテクスチャデータおよび透明度データを有する、ステップと、
前記仮想シーン内のターゲット視点を受信するステップと、
前記ターゲット視点に基づいてレイヤの前記スタックをレンダリングするステップと、
を有する方法。

【請求項12】

レイヤの前記スタックをレンダリングするステップが、レイヤの各スタックから前記ターゲット視点までの距離が減少する順序で実行され、レイヤの各スタック中の前記レイヤのレンダリングが、各レイヤの位置と前記ターゲット視点の位置との間の距離に基づいて減少する順序である、請求項１１に記載の方法。

【請求項13】

処理システムを有する計算装置により実行され、前記処理システムに請求項１から１２のいずれか一項に記載の方法を実行させるコンピュータプログラムコードを含むコンピュータプログラム。

【請求項14】

請求項１３に記載のコンピュータプログラムを実行するように構成されたプロセッサ。

【請求項15】

２つ以上のオブジェクトを伴うシーンを描写するマルチビュー画像フレームデータを含むビットストリームであって、前記ビットストリームはビデオビットストリームを有し、前記ビデオビットストリームは、前記シーン中の２つ以上のそれぞれのオブジェクトのための仮想空間におけるレイヤの２つ以上のスタックを含み、
前記仮想シーン中のレイヤの各スタックの位置は、前記シーン中のそれぞれのオブジェクトの位置に基づき、
レイヤの各スタックは複数のレイヤを有し、各レイヤは、対応するオブジェクトのテクスチャデータおよび透明度データを有する、ビットストリーム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、マルチビュー画像のフォーマットの分野に関する。特に、本発明は、マルチビュー画像フレームデータのためのフォーマットの処理及びレンダリングに関する。

【背景技術】

【0002】

奥行きを伴うマルチビュー画像からレンダリングする既存のアプローチは、ブレンディングを使用して複数のソースビュー(キャプチャ)カメラからのワープされたテクスチャを組み合わせる。ブレンディング演算は、ソースおよびターゲットカメラの位置/向き(例えば、光線角度差)、奥行きの大きさ、奥行きの変動、遮蔽解除、透明度および色などの変数に依存し得る。いくつかの技法は、ターゲット視点内のテクスチャを位置合わせするために、訓練された畳み込みニューラルネットワークを使用することがある。マルチビュー画像を記憶するためのいくつかのフォーマットがある。

【0003】

マルチプレーン画像(MPI)およびマルチスフィア画像(MSI)技法は、3D空間内の平面または球面の所定のセットに対する色および透明度を構成する。そして、新しい仮想視点のために、画像は、背後から前方へのレイヤの合成を使用して構築される。

【0004】

最近、MPI及びMSIは、マルチビュービデオを表現するための3D画像フォーマットとして普及している。MPIおよびMSIフォーマットは、或る点からの様々な奥行き（平面）または距離（球体）に位置する透明度を有する複数のカラー画像からなる。新しい仮想視点を作成するとき、カラーのレイヤは互いに対してシフトされ、そして色は一緒に合成される。

【0005】

MPIおよびMSIフォーマットはマルチビュービデオを表すのに適しているように見えるが、いくつかの問題が残されている。例えば、これらのフォーマットは、典型的には多くの（＞100）フレームサイズ、RGBA(すなわち、色および透明度）、奥行きレイヤからなり、それによって、ピクセルデータ関連サイズを低減するのではなく、元のマルチビューキャプチャピクセルデータ関連サイズを自動的に拡張する。したがって、リアルタイムストリーミングを可能にするために、特定のデータレート低減ステップが必要とされる。

【0006】

JP2019046077Aは、指定された視点方向に応じた方向を有する複数の面を設定することにより、少ないメモリリソースで少ない計算量で自由視点ビデオをコンピュータで合成することができるビデオ合成装置を開示する。

【発明の概要】

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

【0007】

MPIおよびMSIフォーマットは共に、観測されたシーンに関係なく、所定の固定された位置にレイヤを配置する。さらに、これらのレイヤは、典型的には空間にわたって均一に分布する（時にはキャプチャシステムから離れたところよりもキャプチャシステムの近くで密度が高い）。実際には、あらゆる場所へのレイヤの配置がゴーストオブジェクトの導入を引き起こす可能性が高い。例えば、近年の研究は、MPIが、空いた空間の大きな領域からなる現実シーンに対してオーバーパラメータ化されることを示している。この問題に対する提案された解決策は、レイヤ上のスパース性を強制することである。しかしながら、レイヤ上にスパース性を強制することは、シーン内のオブジェクトの視覚的品質を低下させ得る。

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

【0008】

本発明は、請求項により規定される。

【0009】

本発明の一態様による実施例によれば、マルチビュー画像データを処理するための方法が提供され、この方法は:
複数のセンサからソースビューデータを取得するステップであって、ソースビューデータは、2つ以上のオブジェクトを有するシーンのソーステクスチャデータおよびソース奥行きデータを含む、ステップと、
シーン内の2つ以上のオブジェクトの位置を取得するステップと、
オブジェクトのうちの少なくとも2つについて、仮想シーン内のレイヤの2つ以上のスタックを生成するステップとを有し、
レイヤの各スタックは異なるオブジェクトに対応し、仮想シーンにおけるレイヤの各スタックの位置はシーンにおける対応するオブジェクトの位置に基づいており、レイヤの各スタックを生成するステップは、複数のレイヤを生成するステップであって、各レイヤが対応するオブジェクトのテクスチャデータおよび透明度データを含む、ステップを含む。

【0010】

典型的には、マルチビュー画像へのレイヤ化アプローチは、仮想シーン内で離間されたレイヤ（平面）を使用する。レイヤの間隔は、通常、一定であるか、またはターゲット視点からの距離に基づく。しかしながら、本発明者らは、これらのフォーマットが記憶および送信のために大量のデータを使用することを認識しており、したがって、（例えば、特にリアルタイム放送のためには）常に適切であるとは限らないことがある。例えば、ほとんどのレイヤは、透明度が100%の、したがって記憶されなければならないもののオブジェクトについての有用なデータを何ら含まないかなりの数のピクセルを有する。

【0011】

したがって、本発明者らは、各オブジェクトについてレイヤのスタックを生成するが、シーン内でオブジェクトが存在する位置においてレイヤのスタックを仮想シーン内で配置することを提案する。このようにして、レイヤはほとんど、オブジェクトのそば（またはオブジェクトの近くに）配置され、100%の透明度を有するピクセルの数は大幅に低減され得る。これは、シーン内のオブジェクトの位置を取得することから可能である。

【0012】

オブジェクトの位置は、ソーステクスチャデータおよび/またはソース奥行きデータのセグメント化から取得することができる。訓練された機械学習アルゴリズムを使用して、オブジェクトの位置を検出することもできる。オブジェクトの位置を得るための他の方法は、当業者に知られている。例えば、サッカーの試合では、サッカー場およびスタジアムの位置をユーザが生成した3Dモデルから取得することができ、プレーヤおよびボールの位置はオブジェクト検出アルゴリズムから取得されることができる。

【0013】

代替として、オブジェクトは、グラフィックスエンジンによってシーン内で生成されることができ、したがって、オブジェクトの位置は、そのオブジェクトがグラフィックスエンジンによってシーン内で生成された場所から知られる。

【0014】

レイヤのスタックの位置は、例えば、レイヤのスタックの中心を定義する3D座標と、スタックのサイズおよび/または幾何学的形状とによって定義されることができる。あるいは、レイヤのスタックの位置は、レイヤのスタック中の任意のレイヤの任意のピクセル、レイヤの数およびレイヤの間隔によって定義されることができる。レイヤ内の各ピクセルはRGBA(すなわち、色および透明度）を有することができる。

【0015】

何らかの薄いまたは半透明のオブジェクト（例えば、サッカーゴールネット）は、テクスチャメッシュまたは奥行きフォーマットを有するマルチビューからの複数のワープされたテクスチャの混合としてよりも、透明レイヤとしてより良好に表現され得る（すなわち、より高い画質をもたらす）。この結果、異なるフォーマット（例えば、メッシュ、奥行きを有するマルチビュー、及びMOSI）が空間的に組み合わされてシーンを記述するシステム全体が得られる。少なくとも関連するテクスチャ/奥行きマップおよびアルファマップデータが、伝送のための単一のビデオファイル中に一緒にパックされ得ることに留意されたい。このようなハイブリッド形式のシナリオでは、パックされたビデオテクスチャアトラスのどこに何があるかをメタデータが示すことができる。

【0016】

それぞれの位置におけるオブジェクトを表すレイヤのスタックに関連する特定のフォーマットは、マルチオブジェクトサーフェスイメージング（MOSI）フォーマットと呼ばれることがある。

【0017】

仮想シーン内のレイヤのスタックの向きは、シーン内の対応するオブジェクトの位置、シーン内の対応するオブジェクトの向き、対応するオブジェクトのジオメトリ、対応するオブジェクトの先験的な知識、複数のセンサのうちの1つもしくは複数の位置、複数のセンサのうちの1つもしくは複数の向き、および意図される観察ゾーンの位置のうちの1つまたは複数に基づき得る。

【0018】

オブジェクトの向きは、ソースビューデータ（すなわち、オブジェクトの位置、向き、および/またはジオメトリ）から測定することができる。例えば、細長いオブジェクトの場合、スタック内のレイヤは、細長いオブジェクトによって画定される軸と平行に（または平行に近いように）生成され得る。

【0019】

あるいは、オブジェクトの向きは既知であってもよい。例えば、サッカーフィールドの方向は変化しないので、いかなる視点からも常に知られている。

【0020】

シーン（およびシーン内のオブジェクト）がグラフィックスエンジンによって生成される場合、オブジェクト（または複数のセンサ）の位置、ジオメトリおよび向きは、グラフィックスエンジンから取得されることができる。

【0021】

レイヤのスタック内のレイヤが平面である場合、平面の向きは、それらの法線が観察ゾーンの平均観察方向に平行になるように選択されることができる。

【0022】

意図された観察ゾーンは、視聴者が移動する（および許容可能な画質を得る）と想定される6自由度（6DoF）領域（すなわち、位置および向き）であってもよい。それは、所与の観察ゾーンをキャプチャするように設計された（すなわち、カメラの数、視野、位置/向きに依存する）センサキャプチャ設定に関する。

【0023】

レイヤのスタックに対応するレイヤの形状は、シーン内の対応するオブジェクトの位置、シーン内の対応するオブジェクトの向き、対応するオブジェクトのジオメトリ、および対応するオブジェクトの先験的な知識のうちの1つまたは複数に基づき得る。

【0024】

レイヤのスタックの形状は、例えば、球形、円筒形または矩形であってもよい。スタックの形状は、スタックを構成するレイヤの形状に基づいてもよい。レイヤは、対応するレイヤのスタックの形状に応じて、円筒形シェル、球形シェル、または平面であってもよい。例えば、サッカーボールは対応するスタック内の球状レイヤから利益を得ることができ、一方、サッカーフィールドは、対応するスタック内の平面レイヤから利益を得ることができる。

【0025】

純粋にグラフィックスエンジンベースのワークフローでは、レイヤの形状は、縮小または拡張されたオブジェクト表面からなることができ、これらは真の表面ジオメトリの法線ベクトルに沿って縮小または拡張されている。グラフィックスエンジンのレンダリング/エクスポートスクリプトは、オブジェクトのMOSIフォーマットを生成することができる。

【0026】

シーン内の1つまたは複数のオブジェクトの位置を取得することは、シーンの背景の背景奥行きデータを含み、それによって背景の位置を含みシーンの背景モデルを取得し、、ソース奥行きデータから背景奥行きデータを減算し、減算されたデータにおいて前景オブジェクトを検出し、仮想シーン内の前景オブジェクトの位置を決定することに基づくことができ、オブジェクトの位置は、背景の位置および前景オブジェクトの位置に基づく。

【0027】

本方法は、1つまたは複数のオブジェクトのための1つまたは複数の追加のレイヤスタックを生成するステップをさらに含み、それによって、レイヤのスタックまたはレイヤの追加のスタックのうちの少なくとも1つを使用して、ターゲット観察空間中の任意の点から見たときにオブジェクトを完全に視認可能にし、第1のオブジェクトのためのレイヤの追加のスタックは、第1のオブジェクトのためのレイヤのスタックとは異なる向きを有し、ターゲット観察空間は仮想シーン中のサブ空間を定義し、そこから観察者が仮想シーンを観察することができる。

【0028】

レイヤのスタックの形状に応じて、レイヤのテクスチャデータをレンダリングすることは、特定の角度から見たときにオブジェクトが完全に見えることを妨げる可能性があるアーチファクトを生成する場合がある。例えば、平面レイヤが平面レイヤに平行な軸から観察される場合、レイヤのテクスチャデータが完全には観察者には見えない可能性がある。同様に、円筒状のレイヤが上方から見られる場合、テクスチャデータは完全には見えない可能性がある。

【0029】

したがって、観察者が仮想シーンを観察することができるターゲット観察空間を定義することができる。レイヤのスタック内のレイヤのテクスチャデータがターゲット観察空間内の1つまたは複数の点から見えない場合、オブジェクトがターゲット観察空間内でアーチファクトなしで常に見えるように、対応するオブジェクトに対してレイヤの追加のスタックが生成されることができる（たとえば、異なる向きおよび/または形状）。レイヤの追加のスタックは、同じオブジェクトのレイヤの「元の」スタックとは異なる向きを有する。例えば、レイヤの追加のスタック内のレイヤは、レイヤのスタック内のレイヤに対して直交していてもよく、またはほぼ直交していてもよい（例えば、70度と110度との間）。

【0030】

第1のオブジェクトに対応するレイヤの第1のスタックは、レイヤの第1のスタック内のレイヤが第2の異なるオブジェクト（たとえば、背景オブジェクト）に対応するレイヤの第2のスタック内のレイヤと交差するように生成され得る。

【0031】

サッカー選手を表すレイヤのスタックがサッカーフィールドを表すレイヤのスタックと交差していない場合、仮想シーンが特定の角度から見られるとき、サッカー選手は、サッカーフィールドの上に浮いているように見えるだろう。したがって、レイヤの両方のスタックを交差させることは、仮想シーンが「不自然」に見えないことを確実にする。交差するレイヤのセクションは、例えば、レンダリングされるときにブレンドされてもよい。

【0032】

本方法は、既知のオブジェクトのセット内の各々の既知のオブジェクトのためのデータ割り当てを受信するステップと、既知のオブジェクトのためのデータ割り当てに基づいて、第1の解像度および/または第1のフレームレートで、既知のオブジェクトのためのレイヤのスタック内にレイヤを記憶するステップとをさらに備え得る。

【0033】

マルチビュー画像フレームをブロードキャストするとき、通常、ブロードキャストに使用されるネットワークのタイプ（例えば、4G、5Gなど）に基づいて、各フレームのサイズに制限がある。したがって、全てのオブジェクトがネットワークの制限内に収まることを保証するために、各オブジェクトにデータ割り当てを与えることができる。

【0034】

例えば、背景オブジェクト（例えば、サッカーフィールド）のための各レイヤは比較的低いフレームレート（例えば、10 fps）を有する8kフレームに記憶されることができるが、前景オブジェクト（例えば、サッカーボール）は比較的高いフレームレート（例えば、30 fps）を有する4kフレームに記憶される。

【0035】

本方法は、レイヤのスタックのためのメタデータを生成することをさらに含むことができ、このメタデータは、レイヤのスタックの位置、レイヤのスタックの向き、レイヤのスタック内のレイヤの数、レイヤ間の間隔、レイヤのタイプおよび/または形状、ならびにレイヤのスタックのダイナミクスのうちの1つまたは複数を含む。

【0036】

さらに、レイヤ間の間隔は、レイヤのスタックの位置の関数とすることができる。

【0037】

レイヤのスタックのダイナミクスは、スタックの任意の時間符号化を指す。例えば、レイヤのスタックのグローバル位置または向きは、時間とともに変化し得る。代替的に、スタックの間隔またはスタック内のレイヤの数は、例えば、オブジェクトが平均観察位置からさらに離れて移動し、したがって少ないルックアラウンド効果しかモデル化する必要がないとき、経時的に変更することができる。

【0038】

ソーステクスチャデータは、複数のソースビュー画像を含むことができ、レイヤのためのテクスチャデータおよび透明度データの生成は、ソースビュー画像からのテクスチャデータに基づく。

【0039】

ソースビュー画像からテクスチャデータおよび透明度データを生成することは、当業者に知られている。例えば、テクスチャデータおよび透明度データを生成することは、各ソースビュー画像を仮想シーン上に投影することを含み、ソースビュー画像内の各ソースピクセルは仮想シーン内の対応する位置を有する。レイヤの各々のために、それは、各ソースビュー画像中の各ソースピクセルについて、仮想シーン中のソースピクセルに最も近いレイヤ中のピクセルである近位ピクセルと、近位ピクセルとソースピクセルとの間のソース-レイヤ間距離と、ソース-レイヤ間距離に基づく重みとを決定することをさらに含むことができる。レイヤ中のレイヤピクセルごとに、そのレイヤピクセルに対応する重みと、対応するレイヤピクセルのソース-レイヤ間距離を見つけるために使用されたソースピクセルの各々のソース色値とに基づいて、ターゲット色値を生成することができる。

【0040】

代替的に、重みは、ソースカメラからソースピクセルまでのベクトルと、ターゲット平面に直交し、ターゲットピクセルにおいてそれと交差するベクトルとの間の角度に基づいて決定されることができる（すなわち、ターゲット平面は透視投影の代わりに平行投影に本質的に対応する）。

【0041】

レイヤのテクスチャおよび透明度データの検索は、ソースビュー画像に基づいてレイヤの各ピクセルに対して実行されることができる。各ソースビュー画像は仮想シーン上に投影され、各ソースビュー画像の各ピクセルに最も近いレイヤ内のピクセル（すなわち、近位ピクセル）が見つけられる（すなわち、ソースピクセル）。ソースピクセルと対応する近位レイヤピクセルとの間の距離は、レイヤピクセルに対するソースピクセルの寄与の重要度/重みの推定値を与える。例えば、レイヤから遠いソースピクセルはレイヤのピクセルに関連する色値を含む可能性が低く、一方、より近いソースピクセルはより関連する可能性が高い。

【0042】

所与のレイヤにおけるソースピクセルと対応する近位ピクセルとの間の距離（すなわち、ソース-レイヤ間距離）を使用して、重みを決定することができる。そして、重みを使用して、例えば、各ソースピクセルの色を対応する重みで重み付けし、重み付けされたソース色値の合計を求めることによって、ターゲットピクセルのターゲット色値を生成することができる。代替として、最も高い重み値を有するソースビューピクセルが、レイヤピクセルの色のために使用される。他の代替のサンプリングスキームも採用され得る。

【0043】

ソースビューデータはシーンのテクスチャ画像を備え得、ソーステクスチャデータおよびソース奥行きデータはテクスチャ画像に対して奥行き推定を実行することによって取得され得る。

【0044】

本発明はまた、2つ以上のオブジェクトを有するシーンを描写するマルチビュー画像データをレンダリングするための方法を提供し、この方法は、
仮想シーンのためのレイヤの2つ以上のスタックを受信するステップであって、レイヤの各スタックは異なるオブジェクトに対応し、仮想シーン内のレイヤの各スタックの位置はシーン内の対応するオブジェクトの位置に基づいており、レイヤの各スタックは複数のレイヤを有し、各レイヤは対応するオブジェクトのためのテクスチャデータおよび透明度データを有する、ステップと、
仮想シーン内のターゲット視点を受信するステップと、ターゲット視点に基づいてレイヤのスタックをレンダリングするステップとを有する。

【0045】

本方法は、レイヤのスタックの位置と仮想シーン内のターゲット視点の位置との間の距離に基づいてレイヤのスタックをソートすることをさらに含むことができる。

【0046】

レイヤのスタックのレンダリングは、レイヤの各スタックからターゲット視点までの距離の降順で実行されてもよく、レイヤの各スタック中のレイヤのレンダリングは各レイヤの位置とターゲット視点の位置との間の距離に基づいて降順である。

【0047】

本発明はまた、処理システムを有する計算装置上で実行され、当該処理システムに、マルチビューデータを処理およびレンダリングする上述の方法のステップのすべてを実行させるコンピュータプログラムコード手段を含むコンピュータプログラム製品を提供する。このコードを実行するためのプロセッサも提供される。

【0048】

本発明はまた、2つ以上のオブジェクトを有するシーンを描写するマルチビュー画像フレームデータを含むビットストリームを提供し、当該ビットストリームはビデオビットストリームを有し、このビデオビットストリームは、シーン内の少なくとも2つの反復オブジェクトのための仮想シーン内のレイヤの2つ以上のスタックを含み、レイヤの各スタックは異なるオブジェクトに対応し、仮想シーンにおけるレイヤの各スタックの位置はシーンにおけるそれぞれのオブジェクトの位置に基づいており、レイヤの各スタックは複数のレイヤを備え、各レイヤは対応するオブジェクトのテクスチャデータおよび透明度データを有する。

【0049】

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

【図面の簡単な説明】

【0050】

本発明をより良く理解し、本発明をどのように実施することができるかをより明確に示すために、単なる例として、添付の図面を参照する。

【図1】MPIおよびMSIフォーマットを示す図。

【図2】マルチオブジェクト表面画像（MOSI）フォーマットを示す図。

【図3】交差する2つのレイヤのスタックを示す図。

【図4】レイヤの2つのスタックおよびレイヤの追加のスタックを有するシーンを示す図。

【図5】すべてのレイヤが平行であるMOSIフォーマットの例を示す図。

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

【0051】

本発明は、図面を参照して説明される。

【0052】

詳細な説明および特定の例は、装置、システムおよび方法の例示的な実施形態を示しているが、例示のみを目的としたものであり、本発明の範囲を限定することを意図したものではないことを理解されたい。本発明の装置、システム及び方法のこれら及び他の特徴、態様、及び利点は、以下の説明、添付の特許請求の範囲、及び添付の図面からより良く理解されるであろう。図面は単に概略的なものであり、一定の縮尺で描かれていないことを理解されたい。また、同じ参照番号が、同じまたは類似の部分を示すために、図面全体にわたって使用されることを理解されたい。

【0053】

本発明は、マルチビュー画像データを処理する方法を提供する。この方法は、複数のセンサからソースビューデータを取得することを含み、ソースビューデータは1つまたは複数のオブジェクトを有するシーンのソーステクスチャデータおよびソース奥行きデータを含む。シーン内のオブジェクトのうちの1つまたは複数の位置が取得され、オブジェクトのうちの少なくとも1つのために仮想シーン内のレイヤのスタックが生成され、仮想シーン内のレイヤのスタックの位置はシーン内の対応するオブジェクトの位置に基づく。レイヤのスタックを生成することは、複数のレイヤを生成することを含み、各レイヤは対応するオブジェクトのテクスチャデータおよび透明度データを含む。

【0054】

図1は、MPIおよびMSIフォーマットの図を示す。図1（a）は、MPIフォーマットにおけるレイヤ102の図を示す。この例では、レイヤ102は、それらが視点104からどれだけ離れているかに関して離間している。MPIのレイヤ102は、ピクセル毎のRGBA(すなわち色および透明度）データを含む互いに平行な平面であり、各レイヤ102間の間隔は、視点からの奥行きに対して定義される（すなわちz方向）。

【0055】

図1（b）は、MSIフォーマットにおけるレイヤ102の図を示す。MPIフォーマットと同様に、レイヤ102は、それらが中心視点106からどれだけ離れているかに関して離間している。レイヤ102は形状が球形であり、中心に視点106を持ち、レイヤ102の間隔は例えば、前のより近いレイヤ102の半径（ｒ方向）に対して定義される。

【0056】

あるいは、図1（a）および/または図1（b）のレイヤ102は、一定のまたは任意の間隔を有することができる。

【0057】

図の複雑さを低減するために、参照番号は、図における全てのレイヤ102については提供されない。

【0058】

図2にMOSI(multi object surface image)フォーマットを示す。4つの異なるオブジェクトに対応する、レイヤの4つのスタック202が図2に示されている。スタック202aはシーンの背景に対応し、スタック202bはシーンの地面に対応し、スタック202cおよび202dは、地面上に立っている2つのオブジェクトに対応する。

【0059】

背景および地面スタック202aおよび202bは、それぞれ3つのレイヤ102を有する平面スタックである。スタック202ごとのレイヤ102の数は、使用される処理システム、および/またはMOSIフォーマットの意図される使用に依存し得る。3つのレイヤ10は、純粋に例示を目的として図2に示されている。

【0060】

スタック202cは地上のオブジェクト（例えば、サッカーフィールドのサッカー選手）に対応し、円筒状のスタックである。スタック202c内のレイヤ102は中空円筒である。スタック202dも地上のオブジェクトに対応するが、スタック202dはレイヤ102が平面である平面スタックである。

【0061】

スタック202の形状の選択（例えば、平面、円筒形または球形）は、シーン内のオブジェクトの位置および/または対応するオブジェクトのジオメトリに依存し得る。例えば、スタック202は、オブジェクトの表面の形状を有するレイヤ202を有することができ、したがって、スタック202は、オブジェクトの形状を有することになる。

【0062】

レイヤの各スタック202の位置は、シーンのジオメトリに直接関連する。言い換えれば、シーン内のオブジェクトの位置は、仮想シーン内のレイヤの対応するスタック202の位置を定義する。

【0063】

本発明は、シーン内のオブジェクトのセットのためのマルチオブジェクト表面画像（MOSI）を生成することを提案する。シーンのジオメトリに無関係な予め定義された奥行きレイヤ102を作成する代わりに、提案されたMOSIフォーマットは、オブジェクトが実際に位置する位置の周りのレイヤのスタック202に3D表面（平面、円筒、球）を集中させる。このようにして、シーンのジオメトリに関する事前知識が使用される。したがって、MOSIフォーマットは、キャプチャされたシーンの特定のジオメトリに適応する。

【0064】

MOSIフォーマットはピクセルレートに関してよりコンパクトであり、シーン要素から遠く離れてゴーストオブジェクトが発生する可能性は低い。このよりコンパクトなMOSIフォーマットはまた、新しいビューを合成するときに、より高速であり得る。

【0065】

MPIおよびMSIフォーマットと同様に、各ピクセルのRGBAデータをレイヤ102に記憶することが提案される。しかしながら、MOSIフォーマットは、シーン内でオブジェクトが存在する先験的に知られた位置に対応する空間内の異なる位置を有するレイヤの複数のスタック202を作成する。MPIおよびMSIと同様に、MOSIにおける個々のレイヤ102もまた、色および透明度情報からなる。

【0066】

MPIおよびMSIの場合、最終画像を生成するためのフォーマットからのレンダリングは、いわゆる「オーバー」演算子を用いたアルファ合成を使用して、後方から前方へと行われる。提案されたMOSIフォーマットの場合、これはスタック202内でも行われるが、スタック202間では行われない。MOSIフォーマットでは、スタック202が3D空間内の所与のオブジェクトに対応する。レンダリングの前に、スタック202は、視点に対するそれらの位置に基づいてソートされることができる。次いで、スタック202は、視点からの奥行き順序が減少するように、次々に描写されることができる。

【0067】

以下の手順は、キャプチャされたマルチビュー画像から始まるMOSIスタック202の幾何学的位置を定義するための方法を説明する。この例は、アリーナのサイドからキャプチャされるような典型的なスポーツシーンのためのものである:
- スポーツフィールドのサイドから、複数のカメラ（例えば、16台のカメラ）で画像をキャプチャする;
- 平面フィッティングを実行して、地表面および背景の平面パラメータを決定する;
- フィッティングされた接地面の周囲に高さ方向に10センチメートルの間隔で5つのレイヤ102を有する第1のスタック202を配置する;
- 背景の平均距離で5メートルの間隔で5つのレイヤを有する第2のスタック202を作成する;
- 隣接ビューとの画像マッチングを使用して各ビューについて奥行き推定を実行し、それによって、フィッティングされた地面および背景モデルを使用して、結果として生じる奥行き値を制約する;
- 推定された奥行きマップから、フィッティングされた地表面背景を含む奥行きマップを減算し、これを閾値処理を使用してバイナリ前景オブジェクトマスクに変換する。バイナリマスクは例えば、スポーツ選手及びボールを含むことができる;
- バイナリマスクを使用して、可変位置を持つ可変数の矩形を検出する;
-（プレイヤーのサイズをカバーするように）20cmの間隔を空けて矩形内に平均深さに オブジェクトごとに5 つの平面を配置することによって、可変数の更なるスタック202 を作成する。

【0068】

ビュー間の奥行き推定ステップは、3D点群をキャプチャするために別個のレーザスキャナ（または奥行きセンサ）がマルチカメラシステムセットアップに追加されるときに省略され得る。その場合、上記のアルゴリズムは、シーン内のオブジェクトに相関する点群内の点の密集したクラスタにレイヤのスタック202が配置されることになる点で変更される。

【0069】

MOSIフォーマットのためのレイヤのスタック202が定義されたので、以下のステップを使用して、入力としてキャプチャされたマルチビューカメラ画像（すなわち、ソースビュー）を使用して、すべてのスタック202内の各レイヤ102のRGBAテクスチャを作成することができる:
- すべてのソースビューiをすべての表面j（つまり、すべてのレイヤ） に投影し、ソースビューi中の3Dピクセル位置から表面jまでの最短距離に依存するターゲットピクセルごとの重みw_ij(u, v)を計算する。距離が小さいほど、重みが大きくなる。例えば以下のとおりである。

【数1】

ここで、x_i(m, n)はソースiの奥行きマップから導出されたソースビュー画像座標(m, n)における3D点位置であり、x_j(m, n)はターゲット表面j上にある最も近い点であり、kは定数パラメータ（例えば、値1/10を有する）であり、(u, v)は表面jのテクスチャに関連する色および透明度を含むターゲットテクスチャ座標である;
- すべての表面jについて、すべてのソースビューにわたってターゲットテクスチャ座標(u, v)ごとの重みを累積する:

【数2】

- すべての表面jについて、すべてのソースビューにわたってターゲットテクスチャ座標(u, v)あたりの重み×色の積を累積する:

【数3】

- すべての表面jについて、テクスチャ座標(u, v)の最終的な色値c_j(u, v)を次のように計算する:

【数4】

- すべての表面jについて、テクスチャ座標(u, v)の最終的な透明度値α_j(u, v)を次のように計算する:

【数5】

ここで、N_iはソースビューの数である。

【0070】

上記の手順の代替例として、重みw_ij(u, v)は、奥行き差のみならず、表面jの位置を使用して計算される、より基本的な色マッチ誤差項に基づいて、計算されることができる。より具体的には、対応するテクスチャ座標(u, v)を有する表面j上にある3D点がN_i個の色値を取り出すためにソースビューにマッピングされ得る。

【0071】

これらの色値の統計量を使用してw_ij(u, v)を計算することができる。例えば、所与のソースビューiについて、色差が取り出された色値の平均から大きく変動する場合、重みw_ij(u, v)は、ソースビュjーにおいて3D点x_iが遮られている可能性が高いという理由で、比較的低い値に自動的に設定される。色の分散または色の一般的なヒストグラムなどの他の統計量を使用してw_ij(u, v)を決定することができる。

【0072】

MOSIフォーマットの品質をさらに改善するために、ディープラーニングを適用して、レイヤ102の色および/または透明度ピクセル値を生成することができる。その場合、何らかの形のグランドトゥルースが必要になることがある。このグラウンドトゥルースは、MOSIフォーマットを直接生成することができるグラフィックスエンジンから生じ得るか、または、元のソースビュー自体をグラウンドトゥルースとして使用するために更なるレンダリングステップが実行され得る。後者は、レンダリング演算が線形演算であり、したがって微分可能であり、したがってニューラルネットワークにおけるバックプロパゲーションに適しているので、可能である。

【0073】

静的なスタック202は、スポーツグラウンド、ゴール又はスタジアム背景などの静的なシーンオブジェクトに対してこれらを配置するようにエディタにおいてハンドチューニングすることができる。

【0074】

図3は、交差する2つのレイヤスタック202を示す。交差しないスタック202に起因してアーチファクトが発生する可能性がある。したがって、スタック202が重なるように配置されることが有利であり得る。スタック202は、オブジェクトが地面上に浮いているように見えることを回避するために、交差してもよい。

【0075】

例えば、サッカーフィールドの地表面はオーバーコンポジットを使用して下から上へとレンダリングされることができ、次いで、垂直に配向されたスタック（例えば、サッカー選手）が、オーバーコンポジットを使用して後ろから前にレンダリングされることができる。このアプローチは、レイヤの特別な混合を必要としない。2つのスタックのわずかな交差（例えば、少なくとも1つのピクセル）が、ギャップを避けるためだけに必要とされ得る。

【0076】

図4は、レイヤの2つのスタック202と、レイヤの追加のスタック402とを有するシーンを示す。レイヤの追加のスタック402は、レイヤのスタック202eと同一であるが、スタック202fの法線の周りで90度回転されている。スタック202fはシーン内の地面を表し、スタック202eは、地面上のオブジェクトを表す。追加のスタック402は202eと同じオブジェクトを表すが、レイヤ102はスタック202e内のレイヤ102とは異なる配向を有する。

【0077】

たとえば、場合によっては、いくつかのMOSIスタック202をターゲット視点404に従属させることも必要である。例えば、平面スタックによって表されるスポーツフィールドのグラウンドは全ての周囲を見るのに適しているが、これは平面スタックとして表される場合のスポーツプレーヤにとっては当てはまらない。

【0078】

図4には、2つのターゲット視点404aおよび404bが示されている。観察者が視点404aからシーンを見ているとき、シーン内の対応するオブジェクトを示すためにスタック202eが使用されることができる。しかしながら、観察者が視点404bからシーンを見ているとき、スタック202eは対応するオブジェクトを表すのに適しておらず（例えば、レイヤ102間のギャップが見える）、追加のスタック402が適している。

【0079】

追加のスタック402は、異なるターゲット視点404に対して、および/または、観察者がそこからシーンを見ることができるシーン内の空間に基づいて、生成され得る。

【0080】

図5は、全てのレイヤ102が平行であるMOSIフォーマットの一例を示す。図5は、オブジェクトの位置に対応する不規則なレイヤ102の間隔を示す。レイヤのスタック202は、オブジェクト502の奥行きのところまたはその付近に配置される。この形式のMOSIフォーマットは、シーンおよびオブジェクト情報に対応するMPIの修正である。可変のレイヤ間隔は、オブジェクト検出プロセスにおける不確実性を考慮するのに有用であり得る。

【0081】

パッキング:
シーンのジオメトリへの依存に起因して、典型的なMOSIピクセルデータサイズ（各テクスチャマップが1つのレイヤ102に対応するテクスチャマップにわたって合計されるピクセルの総数）は、MPIおよびMSIに必要とされるものよりもはるかに小さい。

【0082】

しかしながら、すべてのスタック202内のレイヤ102のRGBAピクセル値は、HEVCのようなビデオエンコーダを使用して圧縮され得るように、依然として既存の2K、4Kまたは8Kフレームサイズにパッキングされる必要がある。

【0083】

低い計算コストによる解決策は、撮像されているシーンに応じて、パッキングフォーマットをアプリオリに定義することである。たとえば、サッカーゲームの場合、地面に対応するスタック202およびスタジアム背景に対応するスタック202は,単一の4Kビデオフレームにパッキングされることができ、時間的ピクセルレートを低減するために、より低いフレームレートが使用される。

【0084】

一方、サッカー選手は、第2のビデオにまとめてパッキングされることができ、ここで、最大数の選手（例えば、22人）のテクスチャサイズは、ターゲット視点に近い選手をより高い解像度でパッキングされることができるように変化させることができる。一部の領域は、シーンに入る可能性のある予期しないオブジェクト用に予約されることができる。オブジェクトを失うことがないように常に結果に適合するように、スタック202ごとのテクスチャマップの解像度スケーリングが適用されることができる。以上の議論は、多くの場合、他の動的イベント（例えば、他のスポーツイベント）にも適用され得ることに留意されたい。

【0085】

メタデータ:
クライアント装置がパッキングされたビデオを正しく解釈するために、使用されたパッキング方法に加えて、MOSIスタック202の幾何学的パラメータを記述するメタデータが必要とされ得る。特に、単一のスタック202のメタデータは、以下のうちの１つまたは複数を含む：
- スタック202の位置及び/又は向き;
- スタック202内のレイヤ102の数;
- スタック202内のレイヤ102の間隔パラメータ（例えば、規則的 - スカラー距離、または、不規則的 - 距離関数）;
- スタック202のタイプおよび/または形状（例えば、平面、球形、円筒形、カスタムなど）;
- スタック202のダイナミクス（すなわち、スタックの時間パラメータ）

【0086】

当業者は、本明細書に記載の如何なる方法も実行するためのプロセッサを容易に開発することができる。したがって、フローチャートの各ステップは、プロセッサによって実行される異なるアクションを表し得、処理プロセッサのそれぞれのモジュールによって実行され得る。

【0087】

上述したように、システムは、データ処理を行うために処理器を利用する。処理器は、必要とされる様々な機能を実行するために、ソフトウェア及び/又はハードウェアを用いて、様々な方法で実施される。前記処理器は通例、ソフトウェア(例えば、マイクロコード)を用いて、必要とされる機能を行うようにプログラムされる1つ以上のマイクロプロセッサを用いる。処理器は、幾つかの機能を実行するための専用ハードウェアと、他の機能を実行するための1つ以上のプログラムされるマイクロプロセッサ及び関連する回路との組合せとして実施されてもよい。

【0088】

本開示の様々な実施形態に用いられる回路の例は、これらに限定されないが、従来のマイクロプロセッサ、特定用途向け集積回路(ASIC)及びフィールドプログラマブルゲートアレイ(FPGA)を含む。

【0089】

様々な実施において、前記処理器は、例えばRAM、PROM、EPROM及びEEPROMのような揮発性及び不揮発性コンピュータメモリである1つ以上の記憶媒体に関連付けられてよい。この記憶媒体は、1つ以上の処理器及び/又は制御器上で実行されるとき、必要とされる機能を実行する1つ以上のプログラムで符号化されてもよい。様々な記憶媒体は、処理器又は制御器内に取り付けられてもよいし、又は記憶媒体に記憶される1つ以上のプログラムが処理器に読み込まれるように、搬送可能でもよい。

【0090】

開示された実施形態に対する変形例は、図面、開示、および添付の特許請求の範囲の検討から、特許請求された発明を実施する際に当業者によって理解され、実施されることができる。請求項において、単語「有する」は、他の要素又はステップを排除するものではなく、不定冠詞「a」又は「an」は、複数性を排除するものではない。

【0091】

単一のプロセッサ又は他のユニットが、請求項に列挙されるいくつかの項目の機能を果たすことができる。

【0092】

特定の手段が相互に異なる従属請求項に記載されているという単なる事実は、これらの手段の組み合わせが有利に使用されることができないことを示すものではない。

【0093】

コンピュータプログラムは他のハードウェアと一緒に、またはその一部として供給される光記憶媒体またはソリッドステート媒体などの適切な媒体上に記憶/配布されることができるが、インターネットまたは他の有線もしくは無線電気通信システムなどを介して、他の形態で配布されることもできる。

【0094】

「に適応する」という用語が請求項又は明細書に用いられる場合、「に適応する」という用語は、「ように構成される」と言う用語と同様であることを意味する。

【0095】

請求項におけるいかなる参照符号も、範囲を限定するものとして解釈されるべきではない。

【図1(a)】

【図1(b)】

【図2】

【図3】

【図4】

【図5】

【国際調査報告】