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

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

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

<>
  • 特表-没入型ビデオの前処理 図1
  • 特表-没入型ビデオの前処理 図2a)
  • 特表-没入型ビデオの前処理 図2b)
  • 特表-没入型ビデオの前処理 図3
  • 特表-没入型ビデオの前処理 図4
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-03-27
(54)【発明の名称】没入型ビデオの前処理
(51)【国際特許分類】
   H04N 21/234 20110101AFI20240319BHJP
   H04N 19/85 20140101ALI20240319BHJP
   H04N 19/597 20140101ALI20240319BHJP
   H04N 23/60 20230101ALI20240319BHJP
   H04N 21/24 20110101ALI20240319BHJP
【FI】
H04N21/234
H04N19/85
H04N19/597
H04N23/60 300
H04N23/60 500
H04N21/24
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023555720
(86)(22)【出願日】2022-03-09
(85)【翻訳文提出日】2023-09-12
(86)【国際出願番号】 EP2022056053
(87)【国際公開番号】W WO2022194641
(87)【国際公開日】2022-09-22
(31)【優先権主張番号】21163214.6
(32)【優先日】2021-03-17
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.BLUETOOTH
2.ANDROID
(71)【出願人】
【識別番号】590000248
【氏名又は名称】コーニンクレッカ フィリップス エヌ ヴェ
【氏名又は名称原語表記】Koninklijke Philips N.V.
【住所又は居所原語表記】High Tech Campus 52, 5656 AG Eindhoven,Netherlands
(74)【代理人】
【識別番号】100122769
【弁理士】
【氏名又は名称】笛田 秀仙
(74)【代理人】
【識別番号】100163809
【弁理士】
【氏名又は名称】五十嵐 貴裕
(74)【代理人】
【識別番号】100145654
【弁理士】
【氏名又は名称】矢ヶ部 喜行
(72)【発明者】
【氏名】クローン バルト
(72)【発明者】
【氏名】ファレカムプ クリスティアーン
【テーマコード(参考)】
5C122
5C159
5C164
【Fターム(参考)】
5C122DA02
5C122DA44
5C122FH10
5C122FH11
5C122FH14
5C122GC37
5C122GC52
5C122GC75
5C122HA13
5C122HA35
5C122HA86
5C122HA89
5C122HB01
5C122HB05
5C159MA00
5C159PP03
5C159TA60
5C159TB08
5C159TC48
5C159UA02
5C159UA05
5C164GA03
5C164SB01P
5C164SB41P
5C164SC04S
5C164YA21
5C164YA24
(57)【要約】
没入型ビデオへと処理する前に没入型ビデオデータを準備する方法を提供する。この方法は、1つまたは複数の画像領域を含むシーンの1つまたは複数の画像を含む没入型ビデオデータを受信し、画像領域のうちの少なくとも1つの関連度係数を取得し、関連度係数は観察者に対する画像領域の相対的重要性を示す。没入型ビデオデータは、領域データの1つまたは複数のセットに分離され、領域データの各セットは1つまたは複数の画像領域のデータに対応し、画像領域の関連度係数に基づいて、画像領域に対応する領域データのセットが外部処理ユニットに送信されるビットレートが選択される。
【特許請求の範囲】
【請求項1】
没入型ビデオへと処理する前に没入型ビデオデータを準備する方法であって、
2つ以上のカメラグループからシーンの1つまたは複数の画像を含む没入型ビデオデータを受信するステップであって、前記没入型ビデオデータは1つまたは複数の画像領域を有し、各画像領域は1つのカメラグループに対応する、ステップと、
前記画像領域の少なくとも1つのための関連度係数を取得するステップであって、前記関連度係数は観察者に対する前記画像領域の相対的重要度を示し、画像領域の前記関連度係数は、対応するカメラグループとカメラグループの階層とに基づいてバイアスされる、ステップと、
前記没入型ビデオデータを領域データの1つまたは複数のセットに分離するステップであって、領域データの各セットは1つまたは複数の画像領域のデータに対応する、ステップと、
画像領域の前記関連度係数に基づいて、当該画像領域に対応する領域データの前記セットが外部処理ユニットに送信される際のビットレートを選択するステップと、を有する方法。
【請求項2】
領域データのセットの前記ビットレートを選択するステップが、
前記外部処理ユニットに領域データの当該セット送信しないことを選択すること、
領域データの当該セットが送信されるフレームレートを選択すること、
領域データの当該セットの空間解像度を選択すること、
領域データの当該セットのための量子化パラメータを選択すること、および/または
領域データの当該セット中の画像をクロッピングすること、
により実現される、請求項1に記載の方法。
【請求項3】
前記没入型ビデオデータを領域データの1つまたは複数のセットに分離するステップが、
前記没入型ビデオデータをデータのブロックに分離すること、
前記ブロックに存在するデータに対応する画像領域で各ブロックにラベル付けすること、および、
前記ラベルに基づいて領域データのセットに画像領域データの前記ブロックをグループ分けすること、を含む、請求項1または2に記載の方法。
【請求項4】
前記没入型ビデオデータが送信されることができる最大ネットワークビットレートを取得するステップをさらに有し、領域データのセットが送信されるビットレートを選択するステップが、前記最大ネットワークビットレートにさらに基づく、請求項1から3のいずれか一項に記載の方法。
【請求項5】
領域データのセットの各々の前記関連度係数、および/または、当てはまる場合、前記ビットレートが前記最大ネットワークビットレートを下回るように選択される態様を含む関連度メタデータを生成するステップをさらに有する、請求項3に記載の方法。
【請求項6】
関連度係数を取得するステップが、前記外部処理ユニットから関連度指標を受信することにさらに基づく、請求項1から5のいずれか一項に記載の方法。
【請求項7】
処理システムを備える計算装置により実行され、請求項1から6のいずれか一項に記載の方法の全てのステップを前記処理システムに実行させる、コンピュータプログラム。
【請求項8】
没入型ビデオへと処理する前に没入型ビデオデータを準備するためのシステムであって、
1つまたは複数のカメラグループを有する撮像システムであって、各カメラグループがシーンの少なくとも1つまたは複数の画像を含む没入型ビデオデータを取得するように構成され、前記シーンが1つまたは複数の画像領域を有する、撮像システムと、
前記カメラグループから前記没入型ビデオデータを受信し、
前記画像領域のうちの少なくとも1つに対して、観察者に対する前記画像領域の相対的重要度を示す関連度係数であって、画像領域の前記関連度係数は対応するカメラグループおよび前記カメラグループの階層に基づいてバイアスされる、前記関連度係数を決定し、
領域データの各セットが1つまたは複数の画像領域のデータに対応するように、前記没入型ビデオデータを領域データの1つまたは複数のセットに分離し、
画像領域の前記関連度係数に基づいて、当該画像領域に対応する領域データの前記セットが外部処理ユニットに送信されるビットレートを選択するように構成される1つまたは複数のプロセッサと、
を有するシステム。
【請求項9】
前記1つまたは複数のプロセッサが、
前記外部処理ユニットに領域データの当該セット送信しないことを選択すること、
領域データの当該セットが送信されるフレームレートを選択すること、
領域データの当該セットの空間解像度を選択すること、
領域データの当該セットのための量子化パラメータを選択すること、および/または
領域データの当該セット中の画像をクロッピングすること、
により領域データのセットの前記ビットレートを選択するように構成される、
請求項8に記載のシステム。
【請求項10】
前記1つまたは複数のプロセッサが、
前記没入型ビデオデータをデータのブロックに分離すること、
前記ブロックに存在するデータに対応する画像領域で各ブロックにラベル付けすること、および、
前記ラベルに基づいて領域データのセットに画像領域データの前記ブロックをグループ分けすることにより、前記没入型ビデオデータを領域データの1つまたは複数のセットに分離するように構成される、請求項8または9に記載のシステム。
【請求項11】
前記1つまたは複数のプロセッサが、前記没入型ビデオデータが送信されることができる最大ビットレートを受信するようにさらに構成され、領域データのセットが送信される前記ビットレートの選択が、前記最大ビットレートにさらに基づく、請求項8から10のいずれか一項に記載のシステム。
【請求項12】
前記1つまたは複数のプロセッサが、域データのセットの各々の前記関連度係数、および/または、当てはまる場合、前記ビットレートが前記最大ネットワークビットレートを下回るように選択される態様を含む関連度メタデータを生成するようにさらに構成される、請求項8から11のいずれか一項に記載のシステム。
【請求項13】
前記1つまたは複数のプロセッサが、前記外部処理プロセッサから関連度指標を受信することに基づいて関連度係数を取得するようにさらに構成される、請求項8から12のいずれか一項に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、没入型ビデオ放送の分野に関する。特に、本発明は、外部処理ユニットに送信される前に没入型ビデオデータを準備することに関する。
【背景技術】
【0002】
没入型ビデオは、概して、没入型6自由度(6DoF)体験を、典型的には複数の観察者に提供するためにキャプチャされるマルチビュー(テクスチャ、奥行き、およびメタデータ)ビデオに関する。
【0003】
ライブイベントの場合、テクスチャ情報が物理的カメラから取得され、奥行き情報がステレオ/マルチビュー奥行き推定を使用してテクスチャ情報から作成することができる(ただし、取得システムは飛行時間カメラまたはLIDARなどの測距センサを含むこともできる)。スポーツスタジアムの幾何学形状などの先験的な3Dモデル情報もまた、符号化され、テクスチャマップおよび奥行きマップを用いて送信され得る。メタデータは、カメラ固有パラメータおよび外部パラメータ、ならびに/または奥行き量子化およびセマンティックカメララベルなどの他のパラメータを含み得る。このメタデータの大部分は、カメラ較正およびマルチビュー位置合わせなどの処理を使用して推定される。
【0004】
現在の没入型ビデオ用テストモデル(TMIV)は、マルチビュー没入型ビデオ(MIV)仕様の現在のバージョンに準拠したエンコーダおよびデコーダ/レンダラの実装を含む。TMIVエンコーダは、画素のプルーニングおよびアトラスへのパッチのパッキングを含むが、奥行き推定、カメラ較正およびマルチビュー位置合わせを除外する。MIVアトラスは、HEVC(High Efficiency Video Coding)またはVVC(Versatile Video Coding)などのレガシー2Dビデオコーデックを使用して符号化されることができ、そのための効率的なハードウェア符号化ソリューションが市場で利用可能である。
【0005】
一般的なアイデアは、クライアントネットワークリンクおよびデバイスに関する要件を低減するために、サーバ上でビットストリームを間引いて、クライアントへの遅延を小さくすることである。例えば、没入型ビデオビットストリームがそれぞれが観察位置のボリュームに対応する複数のサブビットストリームから構成される場合、観察者の視点に基づいて、これらのうちの幾つかしかクライアントに送信されない。これは空間アクセスと呼ばれる。間引きの別の例は、ビデオデータの時間的解像度を低減することであり(時間アクセスと呼ばれることもある)、ネットワークまたはクライアントデバイスの性能に基づいて使用され得る。これは、一般的には、適応ストリーミングと呼ばれ、事実上すべてのビデオストリーミングサービスで使用されている。
【0006】
没入型ビデオの場合、(観察者によって自由に選択される)視点が欠落した情報を有する状況を回避するために十分なカメラでシーンをキャプチャすることが重要である。これをディスオクルージョンという。加えて、シーンが鏡面反射、金属物体、煙、火などの非ランバート効果を含むとき、光照射野は、少数のビューから正確に再構成することができない。最後に、奥行き値が推定され、量子化され、符号化されるとき、仮想ビューポートが最も近いカメラ視点から比較的遠いとき、奥行き誤差は、平均的な観察者にとって特に妨害となるビュー合成誤差へと伝播する。
【0007】
多くのカメラを有することに関する問題は,すべてのカメラにわたる総解像度(すなわち、総サンプルレート)が、利用可能な5Gまたは衛星アップリンク帯域幅によって事実上制限されることである。
【0008】
オンサイト没入型ビデオコーディングを実行することは、帯域幅要件を低下させるが、処理ユニットの輸送および設置コストのために高価であり、カメラの数に合わせてうまくスケーリングしない。理想的には、カメラのグループごとに小さな処理ユニットがあり、処理ユニットおよびアップリンクはネットワークスイッチを介して接続される。このようにすると、より多くのカメラを追加することは、より多くの同じ小さいハードウェアユニットをプラグインすることを伴うだけである。
【発明の概要】
【発明が解決しようとする課題】
【0009】
オンサイト処理ユニットに関する問題は、画素プルーニングおよび潜在的なパッチパッキングが画素冗長性をテストするための3D再構成に起因して計算的に高価であることである。TMIVにおけるアプローチは、ビュー合成と、基本ビュー内の保存された画素のすべての追加ビューへの混合とを含む。GPUノードでさえ、このアプローチは、奥行き推定、プルーニングおよびパッキング演算を連鎖させるので、問題がある。これは、レイテンシを増加させ、奥行き推定をクラウドにオフロードする機会を排除する。
【0010】
具体的な問題は、プルーニングマスクの集約であり、これは、レイテンシを大幅に増加させる。例えば、アンカー構成のTMIVは、プルーニングマスクを集約するために32フレームをバッファし、ビデオフレームのこのイントラ期間全体のパッキングを一度に決定する。これはアトラスデータを低減し、ビデオ符号化レート歪み特性を改善するが、レイテンシも増加させる。
【0011】
ある程度のレイテンシは許容可能であるが、同じ世帯への没入型ビデオおよび2Dビデオ送信が実質的に異なる遅延を有するときに問題になる。32フレームは1秒以下の遅延にしかならないが、典型的なブロードキャストチェーンには累積遅延がある。
【0012】
低品質(高量子化)で全ビューまたはいくつかのビューを符号化することも、(符号化単位境界に起因する)ブロックアーチファクトが奥行き推定を正確に実行することを困難にするので、良好な解決策ではない。したがって、例えばクラウドに送信される前に没入型ビデオデータを前処理する改善された方法が必要とされている。
【0013】
Igor D D Curcio: "[OMAF] Update on sub-picture segment priority ranks for graceful degradation: simulation results and signaling" 127. MPEG MEETING; 20190708 - 20190712; GOTHENBURG; (MOTION PICTURE EXPERT GROUP OR ISO/IEC JTC1/SC29/WG11) 3 July 2019は、ビューポートに依存するストリーミングの演算において、帯域幅管理を支援し、グレースフルな(graceful)劣化を可能にするために、セグメント優先順位のシグナリングを提案する。
【0014】
米国特許出願公開第2018/332317(A1)号は、異なる重要度メトリックを有する異なる部分を有する仮想現実または拡張現実シーンのビデオを開示している。
【課題を解決するための手段】
【0015】
本発明は、請求項により規定される。
【0016】
本発明の一態様による例によれば、没入型ビデオへと処理する前に没入型ビデオデータを準備する方法が提供され、当該方法は、
シーンの1つまたは複数の画像を含む没入型ビデオデータを受信するステップであって、当該シーンが1つまたは複数の画像領域を含む、ステップと、
前期画像領域のうちの少なくとも1つのための関連度係数を取得するステップであって当該関連度係数が観察者に対する画像領域の相対的重要度を示す、ステップと、
没入型ビデオデータを領域データの1つまたは複数のセットに分離するステップあって、領域データの各セットが1つまたは複数の画像領域のデータに対応する、ステップと、
画像領域の関連度係数に基づいて、その画像領域に対応する領域データのセットが外部処理ユニットへと送信される際のビットレートを選択するステップとを有する。
【0017】
没入型ビデオの生成は、比較的大量のいわゆる没入型ビデオデータ(例えば、異なる位置からの複数のビデオフィード)および複雑な処理を必要とする。したがって、たとえば、没入型ビデオでライブイベントを放送することは、豊富な計算資源を必要とする。しかしながら、通常、そのような計算資源をライブイベントに持って行くことは非現実的であり、したがって、没入型ビデオデータは通常、没入型ビデオの生成のためにクラウドサービス(すなわち、外部処理ユニット)に送信される。
【0018】
没入型ビデオデータをクラウドサービスに送信することは、没入型ビデオデータが送信されるネットワークの帯域幅によって制限される。例えば、5Gは毎秒約20ギガビット(Gbit/s)のピーク制限を有するが、標準的な5G速度は通常、毎秒約100~400メガビット(Mbit/s)である。毎秒30フレーム(fps)の4Kビデオは(使用される圧縮に依存して)約20~50Mbit/sを必要とし、没入型ビデオデータは、没入型ビデオを生成するために複数のビデオフィードを必要とする。
【0019】
すべての没入型ビデオデータをネットワークに適合させるために、没入型ビデオデータをクラウドサービスに送信する前に没入型ビデオデータを前処理することも可能であるが、典型的な前処理の方法は、没入型ビデオデータがクラウドサービスに到達するレイテンシを増加させ、したがって、観察者が没入型ビデオを受信するレイテンシを増加させる。
【0020】
本発明者らは、没入型ビデオの特定の部分が観察者にとって他の部分ほど重要/関連性がなく(例えば、サッカー試合のプレーヤはフィールド上の草よりも重要である)、したがって、より重要でない(あまり関連性がない)部分に対して、より少ない量のデータを送信すればよいことを認識した。
【0021】
没入型ビデオデータは、典型的には、シーンを撮像する複数のカメラからの画像及びビデオフィードを含む。例えば、シーンは、複数のプレーヤを有するサッカーフィールドであってもよい。シーン内の画像領域が識別され、関連度係数が画像領域の少なくともいくつかに与えられる。例えば、フィールド上のプレーヤに「関連度が高い」係数を与えることができ、背景/空に「関連度があまり高くない」係数を与えることができ、フィールドに「関連度がない」係数を与えることができる。関連度係数は、没入型ビデオ内に存在することになる既知の画像領域について、オペレータから取得されることができる。
【0022】
関連度係数を決定する方法は、没入型ビデオデータを取得するカメラの階層を有することを含む。階層内の一次カメラについては、すべてのピクセルが関連すると見なすことができる。二次カメラ(例えば、物理的に一次カメラの間)について、関連度はテクスチャ、動きおよび/または色分析を使用して推定されることができる。画像領域が異なる近くのカメラから完全に予測され得ない(すなわち、補間/レンダリングされ得ない)場合、その画像領域は、高い関連度を有し得る。しかしながら、品質が低下した状態でしか予測することができない場合、画素は何らかの関連性を有し、完全に予測することができる場合、その画素は関連性を有さない。
【0023】
没入型ビデオデータは、「領域データのセット」へと分離されることができる。これらのセットは、1つ(または複数)の画像領域を含む没入型ビデオデータからの画像/ビデオのクロップされたバージョンとすることができる。画像領域の関連度係数に基づいて、領域データのセットに割り当てられるビットレートは、例えば、公称ビットレートまたは最大ビットレートと比較して低減されたビットレートとして選択され得る。例えば、サッカーフィールドのプレーヤの例に戻ると、背景/空に関するデータのセットは(例えば、30 fpsの代わりに1fpsで背景/空のビデオを送信することによって)低減されたビットレートで送信され得る。さらに、フィールドに関連するデータのセットは、没入型ビデオをレンダリングするときにフィールドのモデルが使用される場合には送信されなくてもよい。プレーヤは「高い関連度」係数を有するので、プレーヤのフル解像度60fpsビデオを送信することができる。領域データのセットは、例えば、それぞれの画像領域をセグメント化し、没入型ビデオデータ内に含まれる画像を、セグメント化された画像領域のみを含むようにクロッピング/プルーニングすることによって取得されることができる。画像のクロッピングおよび/またはプルーニングはまた、領域データのセットに必要なビットレートを低減することができる。
【0024】
本方法は、没入型ビデオデータ中の1つまたは複数の画像領域を検出することをさらに含み得る。
【0025】
没入型ビデオの「準備」は、没入型ビデオの「前処理」と呼ばれることもある。
【0026】
領域データのセットのビットレートを選択することは、領域データのセットを外部処理ユニットに送信しないことを選択すること、領域データのセットが送信されるフレームレートを選択すること、領域データのセットの空間解像度を選択すること、領域データのセットのための量子化パラメータを選択すること、および/または、領域データのセット内の画像をクロッピングすることにより実施されることができる。
【0027】
送信されるべきデータのセットのビットレートを設定するための、特に公称(最大)値と比較してビットレートを低減するための様々な方法が存在する。たとえば、ビデオのフレームレートを低減することは、1秒当たりに送信されるフレームの数を低減し、したがって、ビットレートを低減する。空間解像度を低減すること、クロッピングおよび/またはプルーニングも送信されるビットの数を低減することができる。
【0028】
没入型ビデオデータを領域データの1つまたは複数のセットに分離することは、没入型ビデオデータをデータのブロックに分離すること、ブロック内に存在するデータに対応する画像領域で各ブロックをラベル付けすること、ラベルに基づいて画像領域データのブロックを領域データのセットにグループ化することを含むことができる。
【0029】
例えば、ビデオからの各フレームは64×64画素のブロックに分割(すなわち分離)することができる。各ブロックは例えば、ブロック内に存在する画像領域に分類器またはセグメンテーションアルゴリズムを使用して、ラベル付けされることができる。したがって、画像領域を含むブロックのグループを使用して、領域データのセットを定義することができる。
【0030】
本方法は。没入型ビデオデータが送信され得る最大ネットワークビットレートを取得することをさらに含むことができ、領域データのセットが送信されるビットレートを選択することは、この最大ネットワークビットレートにさらに基づく。
【0031】
本方法は、領域データのセットの各々の関連度係数、および/または、当てはまる場合、最大ネットワークビットレートを下回るようにビットレートが選択される態様を含む関連度メタデータを作成することをさらに含むことができる。
【0032】
没入型ビデオデータのさらなる処理に応じて、没入型ビデオデータに対して行われた任意の準備(または前処理)の情報を取得する必要がある場合がある。したがって、各画像領域に与えられる関連度係数、および領域データのセットのビットレートがどのように低減されたかを記述するメタデータを作成することが有益であり得る。
【0033】
関連度係数を取得することは、外部処理ユニットから関連度指標を受信することに基づき得る。たとえば、没入型ビデオデータのすべては、常に可能である可能性が高い非常に低いフレームレート(たとえば、1fps)で最初にアップリンクされ得る。クラウド(すなわち、外部処理ユニット)内の奥行き推定器は、プレーヤがスポーツフィールド上のどこにいるかを認識し、関連する画像領域を定義するためにこれらの境界ボックスをマークすることができる。この情報は、没入型ビデオデータをクラウドに送信したキャプチャコンピュータに返送されことができ、したがって、プレーヤを追跡し始めることができる。
【0034】
また、本発明は、関連度係数を有する没入型ビデオデータを処理するための方法を提供し、この方法は、
撮像システムから没入型ビデオデータを受信するステップであって、この没入型ビデオデータは領域データの1つまたは複数のセットを含み、領域データの各セットは1つまたは複数の画像領域に対応する、ステップ、
画像領域の少なくとも1つに対する関連度係数を受信するステップ、
没入型ビデオデータおよび関連度係数に基づいて奥行きマップを決定するステップ、没入型ビデオデータおよび奥行きマップに基づいて没入型ビデオを生成するステップ、没入型ビデオを放送するステップを含む。
【0035】
例えば、スポーツフィールドを表すグランドプレーンおよび遠い背景プレーンを没入型ビデオデータにフィットさせることができる。この背景モデルは静的であると仮定されることができ、したがって、初期奥行きモデルを生成するために使用されることができる。奥行きサーチアルゴリズムは、所与の距離メトリックを使用して、値がモデルに「近い」ままであるように制約されるので、奥行き値をより迅速に見つけることができる。
【0036】
関連度係数を有する没入型ビデオデータを処理するための方法はさらに、没入型ビデオにおける画像領域の観察統計を累積するステップ、画像領域の観察統計に基づいて、画像領域のうちの少なくとも1つに対する関連度指標を決定するステップ、前記関連度指標を前記撮像システムに送信するステップを含み、前記関連度指標は、前記対応する画像領域に対する前記関連度係数を適応させる際に使用するためのものである。
【0037】
本発明はまた、処理システムを有するコンピューティング装置上で実行されると、処理システムに、前述の方法のいずれか1つの全てのステップを実行させるコンピュータプログラムコード手段を含むコンピュータプログラム製品を提供する。
【0038】
また、本発明は、没入型ビデオへと処理する前に没入型ビデオデータを準備するためのシステムを提供し、当該システムは、
1つまたは複数のカメラグループを備える撮像システムであって、各カメラグループは、シーンの少なくとも1つまたは複数の画像を含む没入型ビデオデータを取得するように構成され、シーンは1つまたは複数の画像領域を含む、撮像システムと、
カメラグループから没入型ビデオデータを受信し、
画像領域のうちの少なくとも1つに対して、観察者に対する画像領域の相対的重要度を示す関連度係数を決定し、
領域データの各セットが1つまたは複数の画像領域のデータに対応するように、没入型ビデオデータを領域データの1つまたは複数のセットに分離し、
画像領域の関連度係数に基づいて、画像領域に対応する領域データのセットが外部処理ユニットに送信されるビットレートを選択するように構成された1つ以上のプロセッサとを有する。
【0039】
領域データのセットのビットレートを選択することは:
領域データのセットを外部処理ユニットに送信しないことを選択すること;
領域データのセットが送信されるフレームレートを選択すること;
領域データのセットの空間解像度を選択すること;
領域データのセットのための量子化パラメータを選択すること;および/または、
領域データのセット内の画像をクロッピングすることにより実現される。
【0040】
没入型ビデオデータを領域データの1つまたは複数のセットに分離することは、没入型ビデオデータをデータのブロックに分離すること、ブロック内に存在するデータに対応する画像領域で各ブロックをラベル付けすること、ラベルに基づいて画像領域データのブロックを領域データのセットにグループ化することを含むことができる。
【0041】
1つまたは複数のプロセッサは、没入型ビデオデータが送信されることができる最大ビットレートを受信するようにさらに構成されることができ、領域データのセットが送信されるべきビットレートの選択は、この最大ビットレートにさらに基づく。
【0042】
1つまたは複数のプロセッサは、領域データのセットの各々の関連度係数、および/または、当てはまる場合、ビットレートが最大ネットワークビットレートを下回るように選択される方法を含む関連度メタデータを作成するようにさらに構成されることができる。
【0043】
1つまたは複数のプロセッサは、外部処理ユニットから関連度指標を受信することに基づいて、関連度係数を取得するようにさらに構成され得る。
【0044】
本発明のこれらおよび他の態様は、以下に記載される実施形態から明らかになり、これを参照して説明される。
【図面の簡単な説明】
【0045】
本発明をより良く理解し、本発明をどのように実施することができるかをより明確に示すために、単なる例として、添付の図面を参照する。
図1】没入型ビデオデータを準備する方法を示すフローチャート。
図2】前処理前後のシーンの画像フレームの一例を示す図。
図3】プリプロセッサに接続されたカメラのグループを示す図。
図4】没入型ビデオデータの作成方法を示す図。
【発明を実施するための形態】
【0046】
本発明は、図面を参照して説明される。
【0047】
詳細な説明および特定の例は、装置、システムおよび方法の例示的な実施形態を示しているが、例示のみを目的としたものであり、本発明の範囲を限定することを意図したものではないことを理解されたい。本発明の装置、システム及び方法のこれら及び他の特徴、態様、及び利点は、以下の説明、添付の特許請求の範囲、及び添付の図面からより良く理解されるであろう。図面は単に概略的なものであり、一定の縮尺で描かれていないことを理解されたい。また、同じ参照番号が、同じまたは類似の部分を示すために、図面全体にわたって使用されることを理解されたい。
【0048】
本発明は、没入型ビデオへと処理する前に没入型ビデオデータを準備する方法を提供する。この方法は、1つまたは複数の画像領域を含むシーンの1つまたは複数の画像を含む没入型ビデオデータを受信すること、画像領域のうちの少なくとも1つの関連度係数を取得することとを含み、関連度係数は観察者に対する画像領域の相対的重要度を示す。没入型ビデオデータは、領域データの1つまたは複数のセットに分離され、領域データの各セットは1つまたは複数の画像領域のデータに対応し、画像領域の関連度係数に基づいて、当該画像領域に対応する領域データのセットが外部処理ユニットに送信されるビットレートが選択される。
【0049】
図1は、没入型ビデオデータ102を作成する方法を示すフローチャートである。この方法は、フル奥行き推定、プルーニング、および外部処理ユニット114(例えば、クラウドサービス、サーバなど)へのコーディングを延期しながら、多数のカメラでスケーラブルである没入型ビデオデータ102のオンサイト前処理(すなわち準備)を実行することに基づく。没入型ビデオデータ102は、レンダリング、符号化等が行われる前に完全な没入型ビデオを作成するために必要とされるデータである。
【0050】
没入型ビデオデータ102は、同じシーンを撮像するカメラのセットから取得される。カメラのセットはより小さいカメラグループに分割され、各カメラグループからの没入型ビデオデータ102は別々に前処理される。
【0051】
各カメラグループからの没入型ビデオデータ102は、領域データのセット104にさらに分割される。領域データのこれらのセット104は、シーンの異なる画像領域に対する没入型ビデオデータ102に対応する。画像領域は、シーンの異なる領域及び/又は視野角である。例えば、シーン内の各オブジェクトは、異なる画像領域に対応することができる。異なるカメラグループからキャプチャされた画像フレームは、たとえ同じオブジェクトを撮像していても、異なる画像領域に対応する。
【0052】
そして、関連度係数106が、(少なくとも1つの)画像領域について取得される。関連度係数106は、例えば、ユーザ入力によって、および/または画像フレームの分析によって部分的に取得され得る。分析のほとんどは、色、テクスチャ、およびモーション(例えば、それは動きがある場合に重要である)などの適切なビュー内の低レベルの画像情報に基づくことができる。
【0053】
関連度係数106は、カメラグループの階層に基づく。階層は、バイアスされたサブセットの没入型ビデオデータ102が概して他のカメラグループよりも関連性が高い(例えば、関連度係数が高い)と見なされるように、カメラグループのサブセットの関連度係数106をバイアスする。
【0054】
画像領域についての関連度係数106に基づいて、プリプロセッサ108は、領域データのセット104のうちの各々についてビットレートを選択する。より関連度の高い画像領域については、対応するセット104がより高いビットレートで(したがって、より高い品質で)送信されることができ、一方、より関連度の低い画像領域はより低いビットレートで送信されることができる。ビットレートを選択することは、例えば、画像フレームのフレームレートを低減すること、解像度を低減すること、画像フレームをプルーニングすること、画像フレームをクロップすることなどによって実行され得る。
【0055】
プルーニングの結果は、ピクセルに「保存」または「プルーニング」のラベルを割り当てることである。これは、テクスチャを黒またはグレーに設定すること、または別個のマップを有することとして実装され得る。ピクセルプルーニングラベルは、カメラグループのプリプロセッサ間でオンサイトで送信されることができる。
【0056】
領域データ104のセットは、カメラグループ毎にパックされ、符号化され、その結果、複数のサブビットストリームが得られ、それらは次いで、外部処理ユニット114へのアップリンク上で単一のビットストリームにマージされる。説明のために、別個のサブビットストリームは、領域データ104aおよび104cのセットのための矢印110aおよび110cとして示され、矢印110の幅は各セット104のために選択された相対ビットレートを示す。この場合、第1のセット104aは「あまり関連性がない」関連度係数106を有する画像領域であり、したがって、セット104aは比較的低いビットレートで送信される。第2のセット104bは関連度係数106が「関連しない」画像領域であり、したがって、ビットレートは0に設定され(すなわち送信されず)、したがって矢印は示されない。第3のセット104cは、関連度係数106「非常に関連性がある」画像領域のものであり、したがって、最大ビットレートで送信され得る。第3の矢印112は、外部処理ユニット114に送信されている没入型ビデオデータ102(および領域データのセット104)のメタデータを示す。
【0057】
好ましくは、セット104にわたるサンプリングレート/ビットレート割り当てを改善するために、何らかの低帯域幅の、レイテンシに影響されないビュー間情報が存在する。たとえば、フレームの第1グループを符号化した後、フレームの第2グループが符号化されている間に情報がセット間で共有される、パイプライン手法が採用され得る。次いで、この情報を使用して、フレームの第3グループのセットにわたるビットレート割り当てを最適化することができる。
【0058】
送信される没入型ビデオデータは、外部処理ユニット114における更なるプルーニング、パッキング及びビデオ符号化に適している。オンサイト前処理の目的は、品質を過度に劣化させることなく、または過度のレイテンシを引き起こすことなく、アップリンクを通るビデオを絞り込むために十分にビュー間冗長性を低減することである。
【0059】
フル没入型ビデオコーディングチェーンを実行する外部処理ユニット114(たとえば、サーバ、クラウドサービスなど)は、サンプリングレート/ビットレート割り当てを最適化するために、パラメータをオンサイトプリプロセッサ108に送り返すことができる。したがって、外部処理ユニット114は、前処理された没入型ビデオデータを完全に処理/レンダリング/符号化し、没入型ビデオを放送することができる。
【0060】
「送信された」および「伝送された」という表現は、プリプロセッサ108から外部処理ユニット114へのデータの転送に使用され、一方、「放送」という表現は、外部処理ユニット114から没入型ビデオの観察者への没入型ビデオの転送に使用される。
【0061】
図2は、前処理の前後のシーンの画像フレーム202の一例を示す。図2aは、2つのオブジェクト208、フィールド206および背景204を有するシーンの画像フレーム202を示す。図2bは、シーン内のオブジェクト208に対応する画像領域210を示す。他の画像領域210(図2には図示せず)は、背景204を含む画像領域210と、フィールド206を含む画像領域210とを含むことができる。図2に示されるシーンは、プレーヤ(すなわち、オブジェクト208)を有するスポーツフィールド(すなわち、フィールド206)の簡略化されたモデルである。
【0062】
背景204は、通常、シーンの他の領域と比較してあまり重要ではなく、したがって、背景204の関連度係数106は比較的低い可能性が高い。したがって、背景204に対応する画像領域210は、低時間周波数で(たとえば、1秒に1回)、イントラコード化ビデオフレームまたはJPEG画像として送信され得る。低い「フレームレート」は、背景204に対応する画像領域210を伝送/送信するのに必要なビットレートを著しく低減する。
【0063】
同様に、フィールド206は、通常、あまり重要ではなく、比較的一定のままである可能性が高い。例えば、フィールド206はサーバでモデル化されることができ、したがって、送信される必要はない(すなわち、ビットレート=0)。
【0064】
プレーヤ208は、シーンの最も重要である部分である可能性が最も高い。図2bでは、プレーヤ208が検出され、シーンから矩形としてセグメント化される。したがって、プレーヤ208を含む画像領域210は、たとえば30Hzまたは60Hzの圧縮ビデオを使用して送信されることができる。
【0065】
フィールド206が送信されず、サーバでモデル化されている場合、サーバでプレーヤの影を追加することができる。
【0066】
スポーツシーンのキャプチャされた画像フレームは、例えば、プレーヤ208を含む画像領域210については30Hzのビデオとして、背景204については0.1Hzの(JPEG)画像として符号化されることができる。現在のボードレベルのコンピュータは、ビデオエンコーダと静止画像エンコーダの両方を同時に実行することができる。GPUからCPUへの最大転送限界内に留まるために、静止画像キャプチャ符号化は、イントラ符号化されたフレームではなく、予測されたフレームに常に整合され得る。シーンがあまり動的でない(たとえば、プレーヤ208がいない)領域において画素ブロックを一定のYCbCrタプルに設定することは、シーンの高周波数画像部分(すなわち、フィールド206および背景204)にあまりビットが費やされないので、アップリンクビットレートを大幅に低減することができる。
【0067】
背景およびフィールドに対する関連度係数の選択は、画像フレーム202がそれから取得されたカメラグループにさらに依存する。画像フレーム202が階層が高いカメラグループに対応する場合、画像フレーム全体がフルフレームレートでパックされ、送信され得る。画像フレーム202が階層の低いカメラグループに対応する場合、背景およびフィールドは、フルフレームレートでパックされない(またはパックされない)ことがある。
【0068】
図3は、プリプロセッサ108に接続されたカメラ302のグループを示す。各カメラ302の視野304が示されている。視野304が交差する領域306は、このグループ内の2つ以上のカメラ302によってキャプチャされるシーンの領域を示す。各カメラ302はそれらが属するカメラグループおよびカメラグループの階層に基づいて、例えば、一次カメラまたは二次カメラとしてラベル付けされることができる。一次カメラは交差する視野304を有しておらず、したがって、一次カメラからの画像フレームのすべてはコンテンツにかかわらず「関連する」とラベル付けされ得る。一次カメラは、それら全てが異なる画像領域210を撮像するが、全体としてはそれらがシーンの全てを撮像するように、配置されることができる。
【0069】
画像領域210は、どのカメラ302がその画像を撮像したかに基づくカメラグループに対応する。例えば、3つのカメラ302がプレーヤがいないスポーツフィールドのセクションを撮像している場合、画像フレームは、それぞれ、一次カメラによってキャプチャされたか、二次カメラによってキャプチャされたかに基づいて、画像領域210「背景1」および「背景2」に分類され得る。プレーヤがいないので、セクション全体は関連性がない可能性が高く、したがって、画像領域「背景2」は送信されない可能性があり、一方、画像領域「背景1」は、低いフレームレートで送信され得る。
【0070】
代替的に、3つのカメラ302が多くのプレーヤを有するスポーツフィールドのセクションを撮像している場合、画像領域210「プレーヤ1」および「プレーヤ2」の両方が高ビットレートで送信され得る。
【0071】
前処理は、少なくとも1つのカメラ302を有するカメラグループごとに実行される。画像領域を検出するための分析のほとんどは、適切なビュー内画像情報に基づく。この情報は、例えば、動きの量、空間周波数分析、色モデル、前景/背景モデル、ニューラルネットワークもしくは(例えば、人間を検出するための)任意の他の学習されたフィルタ、および/または、ドメイン特有の知識(例えば、「緑色」はフィールド)に基づくことができる。
【0072】
特定のカメラキャプチャ、ハードウェア、および符号化モードを使用することもできる。例えば、カメラ302は、カメラ302の視野304において何が起こるかに応じて、データの送信を完全に停止し、後でデータの再送信を開始することができる。この場合、画像フレームは、例えば、異なる一定のフレームレートではなく、不規則な時間インターバルで符号化され得る。
【0073】
例えば、スポーツフィールド上のすべてのプレーヤがフィールドの遠い側にいる場合、より少ないカメラ302が必要とされる。例えば、空間セットアップにおける1つおきのカメラ302は、特定の画像領域210が必要とされない(すなわち、フィールドの片側にプレーヤがいない)ときにキャプチャを停止することができ、プレーヤが特定の画像領域に近づき、したがってより高い空間密度が必要とされると再び開始する。
【0074】
いくつかのセンサは、複数の関心領域(AOI)センサ読み出しを可能にする。より少ないまたはより小さいAOIを直接キャプチャすることは、より少ない画素データを送信することをもたらす。センサが1つまたは複数のAOIにクロップされる場合、センサ自体を使用してこれらのクロップを制御することは不可能である。その情報は、別のカメラ、ドメイン知識、または人間のオペレータなどの別のソースから導出される必要がある。
【0075】
異なる解像度および/またはフレームレートで複数のビデオおよび/または画像を符号化することができる多くのエンコーダ実施が存在する。たとえば、Raspberry Piなどのボードレベルのコンピュータは、ビデオ(H.264)と画像(JPEG)の同時符号化をサポートしている。30HzのH.264ビデオは、この場合、スポーツシーンにおけるプレーヤの矩形画像領域210を含むことができ、静止JPEGファイルは、背景を更新するために10秒毎に書き出されることができる。他のシステムでは、低フレームレートでイントラフレーム専用ビデオ符号化を使用することが有益であり得る。基板エンコーダチップを有するハイエンドGPUはまた、異なるフレームレート、フレーム解像度、およびフレームレートを有する複数のビデオの同時符号化を可能にする。動的シーンコンテンツに応じて、データは、符号化されている多くのビデオのうちの1つまたは複数に割り当てられ得る。
【0076】
好ましくは、いくつかのビュー間情報が、異なる画像領域210の関連度係数106を決定するために利用可能である。たとえば、疎い奥行きマップを作成するために、顕著な特徴点を近くのビューと照合することができる。推定された3Dシーンモデルまたはエキスパートが提供する3Dシーンモデルを使用して関連度係数106を決定することもできる。ピクセル/レートの割り当てを最適化するために、画像/符号化統計の交換もあり得る。
【0077】
さらに、カメラごとの設定は、フレームキャプチャを同期する目的のためにすでに存在する可能性が高い(処理ノードおよび)物理ケーブルを介して、直接の近隣に通信され得る。あるいは、ミリ秒のレイテンシは必要とされないので、BluetoothまたはWi-Fiを使用して、セットアップにおいてカメラ302間で符号化戦略を交換することができる。
【0078】
決定された(または例えば、サーバから取得された)関連度係数106に基づいて、各々のカメラグループは、カメラビューを適切なサイズの領域データ104のセットにタイルアップして、セット104を無視すること、セット104をフル解像度でパックすること、セット104を低減されたフレームレートでパックすること、および/またはセット104を低減された空間解像度でパックすることを、セット104ごとに決定することができる。
【0079】
前処理された情報は、クラウドサービス/サーバにおける更なるプルーニング、パッキング及びビデオ符号化に適している。オンサイト前処理の目的は、品質を過度に劣化させることなく、または過度のレイテンシを引き起こすことなく、アップリンクを介する没入型ビデオデータ102を絞り込むのに十分なようにビュー間冗長性を低減することである。
【0080】
実際には、カメラフィード(ビデオ)がブロックに分離されることができる。適切なブロックサイズは、(HEVCの場合)典型的には64×64ピクセルである最大符号化ユニットである。そして、各ブロックは、ブロックのコンテンツに基づいて領域データ104のセットに割り当てられることができる(例えば、ブロックは、プレーヤ、背景またはフィールドに対応する)。
【0081】
各ブロックの関連度は、それが割り当てられるセット104の関連度に基づいて推定されることもできる。前述のように、カメラのサブセットについて、これらのカメラからのすべてのブロックは、すべての角度がキャプチャされることを確実にするために関連性があるとラベル付けされ得る。これらは、基本ビューまたは一次ビューと呼ばれることができる。例えば、シーンの各角度を少なくとも1つのカメラ302によってカバーすることができ、(1つのカメラ302からの)少なくとも1つのビューが各角度について「関連する」と分類されることができる。いくつかのブロックは完全に冗長であると推定され、全く符号化されない(たとえば、2つ以上のカメラ302が特定の角度をカバーする場合、1つまたは2つのビューのみが必要とされ得る)。
【0082】
他のブロックは静的背景であると推定されることができ、完全な空間解像度であるが、より低い時間分解能(たとえば、60Hzから15Hzまで下がる)で符号化される。これは、静的背景のビットレートがそれほど高くないので、主に複雑さ(サンプリングレート)を低減するためである。他のブロックは、空間ディテールが少ないので、より低い空間解像度でコーディングされ得る。ブロックの関連度は、近くのブロックの関連度に基づいて上下に修正されることもできる。
【0083】
等しいフレームレートのブロックは、アトラスに結合され、ビデオコーデックを使用して符号化され得る。次いで、複数のグループの複数の符号化されたアトラスを、アップリンクに適した単一のビットストリームに組み合わせることができる。
【0084】
関連度係数106に関するメタデータがクライアントに送信されると、クラウドトランス符号化およびクライアントレンダリングを改善することができる。例えば、クライアントがビデオフレームの一部が事実上、低いフレームレートであることを知っていると、奥行き推定、プルーニング、レンダリング動作は、フレームのサブセットについてスキップされ得る。
【0085】
オンサイト(すなわち、カメラ32が位置する場所)ではビデオビットストリームがどのように構築されたかが詳細に分かるのであろうが、クライアントは標準的なビデオデコーダおよびAPI(例えば、Qualcomm、Android)を使用することができ、この情報は、例えば更なる処理のためにサーバに送信されたときに失われることがある。パッチまたはアトラスごとに「時間的サブサンプリング」または「動き度合い」などのいくつかの情報を通信することによって、所与の計算複雑度でより良好な観察体験を提供することができる。
【0086】
一例では、奥行き推定器がビュー間のマッチングのための所与のバジェットを有するとき、このメタデータは所与のコスト(たとえば、クラウドコンピューティング料金)でより高い奥行き品質をもたらすことができるマッチングをより良くターゲットにするのに役立ち得る。
【0087】
メタデータは、関連度係数106に基づく決定の結果(たとえば、低いフレームレート)を含むことができ、そのための何らかの動機(高いモーション、人間、前景など)も含み得る。メタデータはパッチレベル上にあってもよいし、低解像度マップとして送信されてもよい。これらのマップが十分に小さい場合、例えば、4K×2Kフレームに対して64×32ブロックである場合、これらは、SEIメッセージまたは他の形態の高レベルシンタックスの形態で送信され得る。代替的に、これらのマップは、可逆ビデオ符号化によって小さいサブフレームを使用してビデオデータに統合され得る。
【0088】
一部のビデオコーデックでは、ビデオフレームの領域を個別に符号化し、異なる設定を使用することができる。これらのビデオコーデックは、通常、これらの別個のビットストリームを単一のビデオフレームとビットストリームとに結合することもできる。HEVCの場合、動き制約タイルセット(MCTS)があり、VVCの場合、より柔軟な概念であるサブピクチャがある。これらの技術は、異種の設定での並列符号化を可能にするので有利である。
【0089】
ほとんどのステレオおよびマルチビュー奥行き推定器は、候補視差ベクトル(またはスカラー)がテストされて、例えば絶対差の和(SAD)値などのマッチング誤差が得られるマッチングステップを含む。真の視差ベクトルは物理的原点を有し、実数である。しかしながら、復号されたビデオデータ上の視差を推定するとき、整数個の符号化ブロックである視差ベクトルに向かうバイアスが存在する。
【0090】
現在、HEVCなどの最新のビデオコーデックは複数のブロックサイズを有するが、いくつかのブロッキングアーチファクトが依然として観察される可能性があり、残りのテクスチャが制限されているとき、これは依然として奥行き推定器をだますことがある。
【0091】
復号されたビデオ上で動作する奥行き推定器は、関与するビューの局所的な符号化構造を考慮に入れ、ブロックエッジ上でのアラインメントに向かうバイアスを補正することによって、改善され得る。
【0092】
代替的に、奥行き推定器は様々な量子化レベルを処理するように最適化されることができ、マッチングは量子化パラメータ(QP)によって影響される。最新のビデオコーデックでは、QPパラメータはフレーム間で変更でき、フレーム内でも変更できる。
【0093】
(適切な複雑さの)ニュートラルネットワーク、または同様の機械学習ソリューションは、高品質ピクセルプルーナの出力を予測するように訓練されることができる。このネットワークは、許容閾値(失敗よりも誤警報を好む)を有し、割り当てられた関連度係数106に基づいて没入型ビデオデータ102のいくつかを異なる画像領域210に事前プルーニングすることによる前処理ステップの一部として使用されることができ、一方、完全なプルーナはクラウド内で動作し、より多くのピクセルを削ることができる。
【0094】
オンライントレーニングのために、ニューラルネットワークは、完全なプルーナの隣のクラウド内で実行することもできる。次いで、ニューラルネットワークのための改善された係数が、ニューラルネットワークを含むオンサイトプリプロセッサに(定期的に)送信され得る。これにより、ニューラルネットワークは、固有の又は変化する局所的条件に対する性能を改善することができる。
【0095】
機械学習がなくても、サーバは、クロッピング情報をオンサイトプリプロセッサ108に送り返して、アップリンクを介して送信されるピクセルの数を減らすことができ、それによって、後続のフレームのためのより低い量子化パラメータを可能にする。
【0096】
さらに、サーバは、それぞれの画像領域210のビットレートの選択を改善するためにオンサイトプリプロセッサ108に送り返されことができるパラメータを生成するために使用されることができる観察統計を受信および/または蓄積するように装備されてもよい。ほとんどのまたはどの観察者も特定のカメラビューの領域を観察しないとき、この領域は安全にクロッピングされ得る。わずかな観察者がその方向を見るとき、ピクセルデータは、低減された品質で別のビューからレンダリングされ得る。
【0097】
図4に没入型ビデオデータの作成方法を示す。ステップ402において、2つ以上のカメラグループからのシーンの1つ以上の画像を含む没入型ビデオデータが受信される。没入型ビデオデータは1つまたは複数の画像領域を有し、各画像領域はカメラグループに対応する。一般に、没入型ビデオデータは最初にカメラグループに分割されることができ、各カメラグループのデータは、画像領域にさらに再分割されることができる。例えば、カメラグループは、(上述したように)一次カメラと二次カメラの2つのグループで形成されることができる。1つのカメラグループには、1つ以上のカメラが含まれる。
【0098】
カメラグループは、他のカメラグループよりも「関連する」又は重要な視覚データを含むカメラグループの階層を有する。実際には、カメラグループの階層は、送信されたデータから完全な品質の没入型ビデオを生成するために十分な情報が送信されることを保証しながら、処理へと送信される冗長データの量が低減されることを保証することを意味する。
【0099】
これを達成するために、ステップ404において、画像領域のうちの少なくとも1つについて関連度係数が取得される。関連度係数は、観察者に対する画像領域の相対的重要度を示す。さらに、画像領域の関連度係数は、対応するカメラグループおよびカメラグループの階層に基づく。言い換えれば、関連度係数は、画像領域が関連性を有するかどうかを、それがどのカメラグループから得られたか、および観察者に対する相対的重要度の2つのファクタに基づいて考慮する。画像領域がそこから取得されたカメラグループは関連度係数のバイアスとして機能するが、相対的重要度が関連度係数をさらに決定する。
【0100】
そして、ステップ406において、没入型ビデオデータは領域データのセットに分離される。領域データの各セットは、1つまたは複数の画像領域のデータに対応する。例えば、領域データのセットは各カメラグループに対して提供されることができ、又は、領域データのセットは同じ関連度係数を有する画像領域に対して提供されることができる。
【0101】
そして、ステップ408において、領域データのセットのビットレートが選択され、そのビットレートで、領域データのセットが外部処理ユニットに送信される。ビットレートは、領域データのセット内の対応する画像領域の関連度係数に依存する。ビットレートの選択の実施は、前述のように多くの方法で実行されることができる。したがって、関連度係数に基づくビットレートの選択は、階層内で高いカメラグループからの画像領域がより高いビットレート(すなわち、より良い品質)で送信されることを可能にし、一方、階層内で低いカメラグループからの画像領域は、関連度係数がそうでないこと(例えば、画像領域が視覚的に重要なデータを含む)を指示しない限り、低いビットレート(すなわち、より低い品質)で送信され得る。
【0102】
カメラグループの実際の階層は、撮像システム内の各カメラが異なるグループを形成することができるか、またはカメラのすべてが2つのグループに分割されることができるので、幾分任意である。一般に、「関連する」または「重要である」データのすべてが、この準備方法のために、事前にプルーニングされたり、品質が著しく低下したりしないことが重要である。しかしながら、当業者によって理解されるように、「関連する」または「重要である」データは非常に主観的であり、視点に依存する。また、撮像システムが何を撮像しようとしているかにも依存する。
【0103】
階層の目的は、他のカメラグループに対する冗長データを含むことができるカメラグループを示すことである。冗長データを有することが分かったカメラグループは、階層の下位に配置されることができる。
【0104】
当業者は、本明細書に記載の如何なる方法も実行するためのプロセッサを容易に開発することができる。したがって、フローチャートの各ステップは、プロセッサによって実行される異なるアクションを表し得、処理プロセッサのそれぞれのモジュールによって実行され得る。
【0105】
上述したように、システムは、データ処理を行うために処理器を利用する。処理器は、必要とされる様々な機能を実行するために、ソフトウェア及び/又はハードウェアを用いて、様々な方法で実施される。前記処理器は通例、ソフトウェア(例えば、マイクロコード)を用いて、必要とされる機能を行うようにプログラムされる1つ以上のマイクロプロセッサを用いる。処理器は、幾つかの機能を実行するための専用ハードウェアと、他の機能を実行するための1つ以上のプログラムされるマイクロプロセッサ及び関連する回路との組合せとして実施されてもよい。
【0106】
本開示の様々な実施形態に用いられる回路の例は、これらに限定されないが、従来のマイクロプロセッサ、特定用途向け集積回路(ASIC)及びフィールドプログラマブルゲートアレイ(FPGA)を含む。
【0107】
様々な実施において、前記処理器は、例えばRAM、PROM、EPROM及びEEPROMのような揮発性及び不揮発性コンピュータメモリである1つ以上の記憶媒体に関連付けられてよい。この記憶媒体は、1つ以上の処理器及び/又は制御器上で実行されるとき、必要とされる機能を実行する1つ以上のプログラムで符号化されてもよい。様々な記憶媒体は、処理器又は制御器内に取り付けられてもよいし、又は記憶媒体に記憶される1つ以上のプログラムが処理器に読み込まれるように、搬送可能でもよい。
【0108】
開示された実施形態に対する変形例は、図面、開示、および添付の特許請求の範囲の検討から、特許請求された発明を実施する際に当業者によって理解され、実施されることができる。
【0109】
請求項において、単語「有する」は、他の要素又はステップを排除するものではなく、不定冠詞「a」又は「an」は、複数性を排除するものではない。
【0110】
単一のプロセッサ又は他のユニットが、請求項に列挙されるいくつかの項目の機能を果たすことができる。
【0111】
特定の手段が相互に異なる従属請求項に記載されているという単なる事実は、これらの手段の組み合わせが有利に使用されることができないことを示すものではない。
【0112】
コンピュータプログラムは他のハードウェアと一緒に、またはその一部として供給される光記憶媒体またはソリッドステート媒体などの適切な媒体上に記憶/配布されることができるが、インターネットまたは他の有線もしくは無線電気通信システムなどを介して、他の形態で配布されることもできる。
【0113】
「に適応する」という用語が請求項又は明細書に用いられる場合、「に適応する」という用語は、「ように構成される」と言う用語と同様であることを意味する。
【0114】
請求項におけるいかなる参照符号も、範囲を限定するものとして解釈されるべきではない。
図1
図2a)】
図2b)】
図3
図4
【国際調査報告】