JP6742444B2 - ライブストリーミング用のバーチャルリアリティ３６０度ビデオカメラシステム - Google Patents

Description

関連出願への相互参照
本出願は、２０１６年６月７日出願の米国仮特許出願第６２／３４７，０７７号に基づく利益を主張し、上記仮特許出願の内容を参照により本明細書に援用する。

背景
ストリーミング３６０度ビデオコンテンツは、バーチャルリアリティ（ＶＲ）及び拡張現実（ＡＲ）アプリケーションのための没入型環境を提供することができる。

概要
一態様では、撮像システムが提供される。撮像システムは、環境のそれぞれの視野に基づいてビデオ画像データをキャプチャするように構成された複数のカメラを含む。複数のカメラのうちの各カメラが、通信インターフェースを介して複数のカメラのうちの近隣のカメラと通信可能に結合される。複数のカメラのうちの各カメラは、少なくとも１つのプロセッサ、及びメモリを含む。少なくとも１つのプロセッサが、メモリに格納された命令を実行して操作を実施する。操作は、それぞれの視野のビデオ画像データをキャプチャすること、及びオーバーレイ領域を決定することを含む。オーバーレイ領域が、それぞれのカメラと近隣のカメラの少なくとも１つとによってキャプチャされたビデオ画像データの重畳部分を含む。また、操作は、それぞれの視野のキャプチャされたビデオ画像データをオーバーレイ領域に基づいてトリミング及びワーピングして、それぞれの処理されたビデオ画像データを生成することも含む。

一態様では、方法が提供される。この方法は、撮像システムの複数のカメラのうちのそれぞれのカメラに関連する処理されたビデオ画像データを受信することを含む。複数のカメラのうちの各カメラは、環境のそれぞれの視野のビデオ画像をキャプチャするように構成される。処理されたビデオ画像データは、オーバーレイ領域に基づいて、トリミング及びワーピングされたビデオ画像データを含む。オーバーレイ領域は、複数のカメラのうちの少なくとも２つの近隣のカメラによってキャプチャされたビデオ画像データの重畳部分を含む。また、この方法は、ストリーミングされたビデオを、複数の通信リンクを介してクライアントデバイスに提供することも含む。ストリーミングされたビデオは、処理されたビデオ画像データに基づく。

一態様では、システムが提供される。システムは、本明細書で述べる他のそれぞれの態様の操作を行うための様々な手段を含む。

これら及び他の実施形態、態様、利点、及び代替形態は、添付図面を適宜参照しながら以下の詳細な説明を読めば当業者には明らかになろう。さらに、この概要、並びに本明細書において提供される他の記載及び図は、単に例として実施形態を例示することを意図されており、したがって多くの変形形態が可能であることを理解されたい。例えば、特許請求される実施形態の範囲内に留まりながら、構造要素及びプロセスステップを構成し直す、組み合わせる、分散する、削除する、又は他の方法で変更することができる。

図面の簡単な説明
従来のバーチャルリアリティ３６０°ビデオストリーミングパイプラインを示す図である。 従来のバーチャルリアリティ３６０°ビデオストリーミングパイプラインを示す図である。 従来のバーチャルリアリティ３６０°ビデオストリーミングパイプラインを示す図である。 従来のバーチャルリアリティ３６０°ビデオストリーミングパイプラインを示す図である。 １つの例示的実施形態による、分散型バーチャルリアリティ３６０°ビデオキャプチャ、処理、及びストリーミングシステムを示す図である。 １つの例示的実施形態によるシステムを示す図である。 １つの例示的実施形態による、独立したカメラを有するシステムを示す図である。 １つの例示的実施形態による幾何学的なカメラ配置を示す図である。 １つの例示的実施形態によるユニット間接続を示す図である。 １つの例示的実施形態によるユニット間接続を示す図である。 １つの例示的実施形態による、隣接するカメラユニットにおけるワーピング及びトリミングを示す図である。 １つの例示的実施形態による、奥行きマップを推定することによる画像フレームのワーピング及びトリミングを示す図である。 １つの例示的実施形態による、奥行きマップを推定することによる画像フレームのワーピング及びトリミングを示す図である。 １つの例示的実施形態による、グラフカットによる画像フレームのワーピング及びトリミングを示す図である。 １つの例示的実施形態による、キャプチャから消費までのライブストリームを示す図である。 １つの例示的実施形態による、キャプチャから消費までのライブストリームを示す図である。

詳細な説明
例示的な方法、デバイス、及びシステムを本明細書に述べる。「例」及び「例示的」という語は、本明細書では、「例、実例、又は例示として役立つ」ことを意味するために使用されることを理解されたい。「例」又は「例示的」であるものとして本明細書で述べる任意の実施形態又は特徴は、他の実施形態又は特徴よりも好ましい又は有利であるとは必ずしも解釈されない。本明細書で提示する主題の範囲から逸脱することなく、他の実施形態を利用することができ、他の変更を施すこともできる。

したがって、本明細書で述べる例示的実施形態は、限定するものとは意図されていない。本明細書で全般的に述べ、図面に示す本開示の態様は、多様な異なる構成で配置する、置換する、組み合わせる、分離する、及び設計することができ、それら全てが本明細書で企図される。

さらに、文脈上特に示唆されていない限り、各図に示す特徴を互いに組み合わせて使用してもよい。したがって、図面は、概して、１つ又は複数の全体的な実施形態の一態様とみなすべきであり、例示する特徴全てが各実施形態に必要というわけではないことを理解されたい。

Ｉ．概要
バーチャルリアリティ（ＶＲ）３６０°ビデオは、制作から消費までの長いパイプラインを有する。図１に、従来のバーチャルリアリティ３６０°ビデオストリーミングパイプライン１００を示す。（１）パイプライン１００は、ＶＲ３６０°カメラから始まる。ＶＲ３６０°カメラは、複数のカメラからなることが多い。これらのカメラはリグに取り付けられ、各カメラは、異なる視野角をキャプチャするように配置される。これらのカメラは、重畳する視野（ＦＯＶ）を含み、画像ステッチングによって３６０×１８０度の球状ビュー全体をカバーする。（２）全てのカメラからのデータが処理ユニットに読み込まれ、処理ユニットは、複数のビデオストリームを整列させてステッチし、１つの３６０°ストリームにする；（３）次いで、３６０°ストリームを編集することができる；（４）次いで、編集されたビデオが符号化されて、クラウドにアップロードされる；（５）次いで、ビデオは、クラウドにおいてトランスコードされ、ストリーミングの準備が整う；（６）ビデオコンテンツがクライアントに配信される；さらに（７）クライアントアプリケーションがコンテンツを受信し、それらをエンドユーザにレンダリング／表示する。

パイプラインは、実際の実装ではいくつかのコンポーネントに分かれることがある。例えば、図２に、従来のバーチャルリアリティ３６０°ビデオストリーミングパイプライン２００を示す。このパイプライン２００は、Ａ．３６０°カメラ、Ｂ．強力なコンピュータ、Ｃ．強力なクラウドサーバ、及びＤ．ＶＲヘッドセット又はスマートフォンからなる。この構成では、強力なコンピュータ（Ｃ）は、ステッチング、編集、符号化からアップロードまで、多くの高負荷な作業を行う。コンピュータが３６０°カメラから大量のデータを受信すること、ステッチング及び符号化は大きな計算量を必要とすること、ローカルストレージが、大きなデータを格納するのに十分に大きくなければならないこと、及び処理されたビデオをインターネットのクラウドにアップロードするにはかなりの時間及び帯域幅を要することに留意されたい。これらの難点により、このコンピュータは、超強力（高速Ｉ／ＩＯ、大量のメモリ、高速ＣＰＵ又はＧＰＵ、及び高速インターネット接続）にしなければならず、高価である。さらに、３６０°カメラは、より高い品質のためにより多くのカメラを含むように容易にスケールアップすることができるが、それに応じて強力なコンピュータをスケールアップすることは困難である。その結果、この解決策は通常、ライブストリーミングに十分に速くデータを処理することができない。

図３に、従来のバーチャルリアリティ３６０°ビデオストリーミングパイプライン３００を示し、このパイプライン３００では、符号化及びアップロードが専用のデバイスによって行われ、強力なコンピュータは、ビデオ編集及びステッチングのみを扱う。しかしやはり、３６０°カメラがスケールアップするにつれて、ライブストリーミングに十分に速くステッチングが行われない可能性がある；また、１つの専用デバイスは、高解像度（例えば４Ｋ、８Ｋ、１２Ｋ）ビデオをリアルタイムで符号化することができないことがある。

別の従来のバーチャルリアリティ３６０°ビデオストリーミングパイプライン４００を図４に示す。ステッチング及び符号化が、３６０°カメラにおいてハードウェア解決策で行われ、強力なコンピュータは、（必要であれば）さらなる編集及び符号化を行い、最終結果をアップロードする。この構成では、ＶＲカメラでの作業が非常に高負荷であることが多く、ビデオ品質と解像度を犠牲にしなければならないことが多い。

本発明者らは、ＶＲ３６０°ビデオキャプチャ及びライブストリーミングのための分散型インフラストラクチャを提案する。図５に、１つの例示的実施形態による、分散型バーチャルリアリティ３６０°ビデオキャプチャ、処理、及びストリーミングシステム５００を示す。システムの各カメラは、プロセッサ（ＣＰＵ、ＧＰＵ）、ストレージ、及び送信ユニットと一体化されている。したがって、各カメラは、一体型モジュールに組み込まれてもよい。このモジュールは、小さいＦＯＶに関して、画像のキャプチャ、ワーピング、ステッチング、編集、符号化、トランスコーディング、アップロードまでを行うように構成されてもよい。このＶＲ３６０°ビデオカメラシステムは、Ｋ個の一体型カメラモジュールからなる。これらのモジュールは、最良のステッチングのために互いに通信し、操作を並列に行うことができる。

各一体型カメラモジュールからのビデオは注意深くワーピングされトリミングされているので、それらをステッチし合わせるためにさらなる整列は必要とされない。クラウドにおいて比較的低い計算量で全てのビデオをステッチし合わせることを選択することができ、又は最終的な表示デバイス（例えば、ＶＲヘッドセット、スマートフォンなど）においてレンダリング中にビデオをステッチすることを選択することもできる。

ＩＩ．例示的なシステム
Ａ．一体型カメラユニット
一実施形態では、図６に示すように、カメラ、プロセッサ、ストレージ、及び送信モジュールの一体型ユニットを形成して、１つのモジュールにすることができる。すなわち、図６には、１つの例示的実施形態によるシステム６００を示す。

別の実施形態では、図７に示すように、カメラを他の構成要素から物理的に分離することができる。図７には、１つの例示的実施形態による、独立したカメラを有するシステム７００を示す。そのような配置は、ＶＲ３６０°カメラリグの正しい位置へのカメラの取付けをより簡単にすることができる。

また、各カメラユニットは、マイクロフォンを含んでいてもよく、それにより、全てのカメラユニットが合わさって、異なる方向でのサウンドを記録してストリーミングすることができる。

Ｂ．ＶＲ３６０°カメラシステムの幾何学的形状
ＶＲ３６０°カメラシステムは、様々な数のカメラからなっていてよい。これらのカメラは、所望のＦＯＶをカバーするために様々な形で幾何学的に配置することができる。図８に、１つの例示的実施形態による幾何学的なカメラ配置８００を示す。図８には、全視野をカバーする１４個のカメラユニットの例示的な幾何学的配置を示す。上部（平面１）にあるカメラ１は上方向に向いており、魚眼レンズで１００°×１００°ＦＯＶをカバーする。平面２にあるカメラ２〜７は、外方向に向き、５０°×３６０°ＦＯＶの円柱ビューをカバーし、各カメラが５０°×６５°ＦＯＶをカバーし、連続する（例えば隣接及び／又は近接する）カメラ間で５°の水平方向重畳を有する。システムの下半分（例えば、カメラ８〜１４）は、上半分に対して対称的でよい。

球よりも小さいＦＯＶが望まれる場合、又は個々のカメラそれぞれがより大きいＦＯＶを有する場合、より少数のカメラを実装してもよい。カメラ間のより大きい重畳が望まれる場合（例えば、より簡単なステッチングや、より大きい冗長性のために）、又は個々のカメラそれぞれがより小さいＦＯＶを有する場合、より多くのカメラを実装してもよい。

１つの例示的実施形態では、各平面に沿って（例えば各視点に）一対のカメラを配置して、全ての視野に関する立体視を提供することができる。

また、本開示は３６０°ビデオに関わる例を提供するが、３６０°未満の視野を有するビデオを提供するために同じ方法及びシステムを適用することができる。

Ｃ．カメラユニット間の相互接続
本明細書で提案されるＶＲ３６０°カメラシステムでは、各カメラユニットは、ビデオフレームを処理して、異なるカメラからのフレームを出力し、それらを直接ステッチして球状ビューを形成することができ、又はステッチした後に少量のさらなる処理で球状ビューを形成することができる。そのようなシナリオでは、各カメラは、画像処理（例えばワーピング及び／又はトリミング）を行うために、その近隣のカメラユニット（例えば近隣のカメラ）から情報を受信する必要がある。

一実施形態では、これらのカメラユニットは、図９Ａに示すように、有線又は無線通信インターフェース（例えば、BLUETOOTH（登録商標）、BLUETOOTH（登録商標） LOW ENERGY、WiFi、又は別の種類の通信プロトコル）を介して互いに直接接続される。図９Ａに、ユニット間接続を示す。別の実施形態では、図９Ｂに示すように有線又は無線通信インターフェースを介して各カメラユニットを中央ハブデバイスに接続することができる。この相互接続により、カメラユニットは、ランタイム時に各カメラユニットでのそれぞれの画像処理に関する情報を交換することが可能になる。

一実施形態では、全てのカメラの幾何学的位置を事前に較正することができ、これにより、ランタイム中のカメラ間の通信をなくすことができる。これは、ステッチング品質を犠牲にしてシステムを単純化する。例えば、高品質のステッチングは、カメラの幾何学的配置と、撮像された被写体の空間的位置との両方の結果として得られる。

バッテリは、一体型ユニットに含まれていても含まれていなくてもよい。例えば、撮像システムは、外部から電力供給されてもよい。追加として又は代替として、バッテリは、撮像システムにいくらかの電力又は全ての電力を供給することができる。

１つの例示的実施形態では、アップロードプロセスを高速化するように又は容易化の助けとなるように、ＶＲカメラシステムとクラウドサーバとの間の通信リンク及びハードウェアアーキテクチャにネットワークデバイスを組み込むことができる。

ＩＩＩ．例示的な方法
Ａ．カメラ同期
本明細書で提案されたＶＲ３６０°カメラシステムにおける各カメラユニットは、球状ビューの一部をキャプチャする。各カメラからの画像をステッチし合わせて３６０°画像フレーム（及び３６０°ビデオ）にするためには、各カメラユニットにおける画像キャプチャを同期させる必要がある。カメラシステムクロックは、カメラ間の通信に基づいて同期させることができる。追加として又は代替として、カメラがビデオをキャプチャしている間に同期フラッシュが発光されてもよい。そのようなシナリオでは、同期フラッシュをキャプチャするそれぞれのビデオデータからのフレームを見つけることによって、カメラを同期させることができる。追加として又は代替として、（例えばカメラのビデオキャプチャを同時に停止することにより）最後のビデオクリップを分析することによってカメラを同期させることができる。

全てのカメラが同期されている場合、任意の所与の時点ｔに関して、ターゲット３６０°ビデオにおいて、ｔに最も近い各ビデオクリップでの１つのフレームを特定し、それらをステッチし合わせることができる。ここで、より良い平滑性のために、時間次元において線形補間を使用してもよい。

Ｂ．ビデオステッチングのためのワーピングとトリミング
１．背景
ビデオステッチングの難しさは、１）レンズ歪；及び２）カメラ間の視野差に起因することがある。レンズ歪は、ランタイム前又はランタイム時に行うことができるカメラ較正によってほぼ補正することができる。カメラの視野差はシーンに依存し、ビデオがキャプチャされているときにカメラの重畳を使用して対処することができる。

１つのカメラユニットからのフレームは、その近隣のカメラユニットからのフレームと重畳する。図１０に、異なるカメラユニットからの２つのフレームを示す。重畳する領域は、赤い長方形でマークされている。これらの重畳領域を使用して、フレームをワーピング及びトリミングする。そのようなワーピング及び／又はトリミングが個々のフレームに対して行われた後、図示するようにフレームをシームレスにステッチすることができる。

重畳領域の情報は、様々な形で送信することができる。１）（図１０に赤い長方形で示すような）取り得る最大のオーバーレイ領域をその近隣のカメラユニットに送信することができる；２）これらの領域で特徴点（例えば、ＳＩＦＴ（スケール不変特徴変換）点）を検出し、これらの特徴点をその近隣のカメラユニットに送信することができる；３）画素の重畳領域と検出された特徴点との両方を送信することができる；４）フレームごとに、又はフレームの周期的若しくは非周期的な間隔にわたってこれらの情報を送信することができる。例えば、重畳領域に関する情報は、キャプチャされたシーンが（例えば画像ヒストグラム又は別の画像測定基準に基づいて）閾値量だけ変化したのに応答して、及び／又は既知の重畳領域付近の特徴が閾値距離を超えて移動したのに応答して、近隣のカメラに送信することができる。

２．カメラユニットごとのビデオワーピング及びトリミング
図１１Ａ及び１１Ｂに、１つの例示的実施形態による、奥行きマップを推定することによる画像フレームのワーピング及びトリミングを示す。図１１Ａ及び１１Ｂには、５つのカメラが３６０°視野内に一様に分布し、それぞれが９０°ＦＯＶをカバーする２Ｄビューの例を示す。一方法では、各カメラユニットは、中心点の視点から７２°の最終的な画像の生成を担い、したがって、５つのカメラからの全てのフレームを組み合わせて、単一の視点Ｏからの３６０°の１フレームが生成される。各カメラユニットの担当するＦＯＶは較正中に予め決定される。

図１１Ｂに示すように、視点Ａからの画像Ｆ１と、それぞれ点Ｂ及びＣからの近隣のカメラからの画像Ｆ２及びＦ３とを用いて、単一の視点Ｏから画像を生成する様々な方法がある。例示的なプロセスを図１１Ｂに示す。

１．Ｆ１とＦ２の間で、Ｆ１、Ｐ１の最も右の画素に関する視差を計算し、次いでこの画素の奥行きを推測する。

２．Ｆ１とＦ３の間で、Ｆ１、Ｐ２の最も左の画素に関する視差を計算し、次いでこの画素の奥行きを推測する。

３．Ｆ１内の他の画素の奥行きを推定し、Ｐ１及びＰ２の奥行きの線形補間を使用する。

４．全ての画素の奥行きが推定されると、視点Ｏに関して、ターゲットの７２°にＦ１をマッピングし直すことができる。

ターゲット画像を生成するために奥行きを明示的に計算する必要はない。別の例示的な解決策を図１２に示す。図１２には、１つの例示的実施形態による、グラフカットによる画像フレームのワーピング及びトリミングを示す。

１．点Ａからのフレーム（２）ごとに、重畳し得る領域を取得する。例えば、視点Ｃ及びＡからの領域Ｗ及びＵ、並びに視点Ａ及びＢからの領域Ｐ及びＱである。

２．重畳領域の対ごとに、（４）及び（５）に示したように、ＷとＵの間、及びＰとＱの間の不連続性を最小にする最良のカットを見つける。多くのグラフカットアルゴリズムが文献で提案されている。

３．（６）に示したように、フレーム１から、領域Ｗ及び領域Ｑをトリミングし、次いで、残りの領域を水平方向にワーピングして、矩形の画像にする。

４．実際には、各フレームは、その近隣のカメラとの４つの重畳領域を有することがある。その結果、フレーム１は、（７）に示したように４方向でトリミングすることができる（Ｗ、Ｖ、Ｑ、Ｙ）。次いで、残りの領域は、水平方向及び垂直方向にワーピングされて、最終的な長方形の画像にされる。

５．全てのカメラからのトリミング及びワーピングされたフレームは、より少量のステッチングアーチファクトで球状ビュー全体をカバーする。

一実施形態では、時間的な平滑性のために、重畳領域間の最良のカットを見つけるときに、さらなる平滑性制約（例えば、エッジアライメント、動き補償、カラー／形状マッチング、トーンマッピング、露出補正などを行う）を課してもよい。

この処理は、フレームごとに、又はフレームの周期的若しくは非周期的な間隔にわたって行うことができる。グラフカット（例えばトリミング及びワーピング）は、画像処理期間の間のそれぞれの画像の推定移動速度及び／又は他の変化に基づいて補間されてもよい。

Ｃ．データストレージ
各カメラユニットからのビデオデータは、即座にローカルストレージに保存されてもよく、又はローカルストレージへの保存前に（前のセッションで述べたように）まずトリミング及びワーピングされてもよい。

ローカルストレージ内の１つのファイルに保存する前に、ビデオデータを符号化することもできる（例えば、Ｈ．２６４、ＶＰ８、ＶＰ９など）。また、ビデオデータは、後のストリーミング（例えば、ＨＬＳ、ＤＡＳＨ）のためにローカルストレージ内の一連の小さなトランクファイルに符号化されてもよい。

Ｄ．ビデオデータのアップロードとライブストリーム
ローカルストレージに保存するか否かにかかわらず、処理されたビデオデータは、リアルタイムでクラウドにアップロードすることができる。図１３に示す一例では、ビデオデータが小さなトランクに符号化されると、各トランクを即座にクラウドにアップロードすることができる。図１３には、１つの例示的実施形態による、キャプチャから消費までのライブストリーム１３００を示す。

この場合、クラウドは、様々なストリーミングプロトコル（例えば、ＨＬＳ、ＤＡＳＨなど）を介して複数のユーザにブロードキャストすることが可能であり得る。

ＶＲ３６０°カメラシステムは、いくつかのカメラユニットからなることに留意されたい。図１３に示すように、各ユニットが、１つのデータストリームをクラウドにアップロードする。クラウドストリームサーバ内にメタデータを作成して、ＶＲ３６０°カメラシステムの幾何学的情報及び他のビデオメタデータ（例えば、フレームレート、解像度、ビデオフォーマット、ビデオ／オーディオコーデックなど）を記述することができる。

１．クライアントアプリケーションでのストリーム及びステッチング
まず、クライアントデバイス上のアプリケーションが、ストリームサーバからメタデータを取得し、次いでビデオトランクの全ての必要なリストに接続する。このアプリケーションは、必要に応じて、所要のビデオトランクをストリーミング及び同期し、それらをステッチし合わせて、スクリーンにレンダリングするように設計されており、したがってエンドユーザにＶＲ３６０°ビデオを提供する。１つの適用可能な解決策が、２０１６年４月８日出願の米国仮特許出願第６２／３２０，４５１号に記載されている。

２．クラウド上でステッチし、次いでクライアントアプリケーションにストリーミングする
全てのカメラユニットからのビデオデータをクラウド上でステッチすることもできる。アップロード前に全てのデータが既に整列されているので、ステッチングのための計算は比較的少なく、リアルタイムで行うことができる。ステッチング後、ステッチされたビデオデータは、通常のビデオストリームであるように見え、これは、通常のストリーミングプロトコル（例えば、ＨＬＳ、ＤＡＳＨなど）を介してクライアントデバイスにストリーミングすることができる。

３．クラウドステッチングとクライアントステッチングを組み合わせる
クラウド上で低解像度の３６０°ビデオをステッチし、クライアントアプリケーションにおいて高解像度の３６０°ビデオをステッチすることもできる。クラウド上での計算を少なく済ますために、ＶＲ３６０°カメラシステムにおける各カメラユニットは、図１４に示すように、２つの一連のトランク、すなわち１つの高解像度トランク及び１つの低解像度トランクをクラウドにアップロードすることができる。図１４には、１つの例示的実施形態による、キャプチャから消費までのライブストリーム１４００を示す。

図面に示した特定の構成は、限定とみなすべきではない。他の実施形態は、所与の図に示した各要素をより多数又はより少数含んでいてもよいことを理解されたい。さらに、例示した要素のいくつかを組み合わせてよく、又は省略してもよい。さらにまた、例示的実施形態は、図面に示していない要素を含んでいてもよい。

情報の処理を表すステップ又はブロックは、本明細書で述べた方法又は技法の特定の論理的機能を行うように構成することができる回路に対応し得る。代替として又は追加として、情報の処理を表すステップ又はブロックは、モジュール、セグメント、又はプログラムコードの一部（関連データを含む）に対応し得る。プログラムコードは、方法又は技法における特定の論理的機能又は作用を実施するためにプロセッサによって実行可能な１つ又は複数の命令を含むことができる。プログラムコード及び／又は関連データは、ディスク、ハードドライブ、又は他の記憶媒体を含むストレージデバイスなど、任意のタイプのコンピュータ可読媒体に記憶することができる。

また、コンピュータ可読媒体は、非一時的なコンピュータ可読媒体、例えば、レジスタメモリ、プロセッサキャッシュ、及びランダムアクセスメモリ（ＲＡＭ）など短期間だけデータを記憶するコンピュータ可読媒体も含むことができる。また、コンピュータ可読媒体は、より長期間にわたってプログラムコード及び／又はデータを記憶する非一時的なコンピュータ可読媒体を含むこともできる。したがって、コンピュータ可読媒体は、例えば、読み出し専用メモリ（ＲＯＭ）、光ディスク又は磁気ディスク、コンパクトディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）など、二次的又は永続的長期ストレージを含むことができる。また、コンピュータ可読媒体は、任意の他の揮発性又は不揮発性記憶システムでもよい。コンピュータ可読媒体は、例えばコンピュータ可読記憶媒体、又は有形記憶デバイスとみなすことができる。

様々な例及び実施形態を開示してきたが、他の例及び実施形態も当業者には明らかであろう。開示した様々な例及び実施形態は、例示の目的であり、限定とは意図されず、本発明の真の範囲は添付の特許請求の範囲によって示される。

Claims (21)

1. 環境のそれぞれの視野に基づいてビデオ画像データをキャプチャするように構成された複数のカメラを備える撮像システムであって、前記複数のカメラのうちの各カメラが、１つ又は複数の通信インターフェースを介して前記複数のカメラのうちの近隣のカメラと通信可能に結合され、前記複数のカメラのうちの各カメラが、少なくとも１つのプロセッサ及びメモリを備え、前記少なくとも１つのプロセッサが、メモリに格納された命令を実行して操作を実施し、前記操作が、
   前記それぞれの視野のビデオ画像データをキャプチャすること、
   オーバーレイ領域を決定することであって、前記オーバーレイ領域が、前記それぞれのカメラと前記近隣のカメラの少なくとも１つとによってキャプチャされたビデオ画像データの重畳部分を含むこと、並びに
   前記それぞれの視野の前記キャプチャされたビデオ画像データを前記オーバーレイ領域に基づいてトリミング及びワーピングして、それぞれの処理されたビデオ画像データを生成すること
   を含む撮像システム。
2. 前記オーバーレイ領域を決定することが、前記通信インターフェースを介して、前記近隣のカメラのうちの少なくとも１つからオーバーレイ情報を受信することを含む、請求項１に記載の撮像システム。
3. 前記操作が、前記通信インターフェースを介して、前記オーバーレイ領域を示す情報を前記近隣のカメラのうちの少なくとも１つに送信することをさらに含む、請求項１に記載の撮像システム。
4. 前記操作が、前記処理されたビデオ画像データをリアルタイムでサーバにアップロードすることをさらに含む、請求項１に記載の撮像システム。
5. 前記操作が、
   前記通信インターフェースを介して、時間基準を示す情報を受信すること、及び
   前記時間基準に基づいて少なくとも１つの操作を行うこと
   をさらに含む、請求項１に記載の撮像システム。
6. 前記操作が、前記ビデオ画像データをキャプチャしている間に、前記環境の視野内で同期フラッシュをキャプチャすることをさらに含み、前記時間基準が前記同期フラッシュを含む、請求項５に記載の撮像システム。
7. 前記操作が、前記ビデオ画像データをキャプチャしている間に、前記複数のカメラのうちの各カメラに関するビデオ画像データキャプチャを同時に中断することをさらに含む、請求項５に記載の撮像システム。
8. 前記操作が、ビデオ画像データの前記重畳部分内の重畳する画素の部分を決定することをさらに含み、前記オーバーレイ領域を決定することが、重畳する画素の前記部分に基づく、請求項１に記載の撮像システム。
9. 前記操作が、ビデオ画像データの前記重畳部分内の少なくとも１つの画像特徴点を決定することをさらに含み、前記オーバーレイ領域を決定することが、前記画像特徴点に基づく、請求項１に記載の撮像システム。
10. 前記少なくとも１つの画像特徴点が、少なくとも１つのＳＩＦＴ(structure invariant function transfer; 構造不変関数伝達)点を含む、請求項９に記載の撮像システム。
11. 前記撮像システムが、１４個の面を有する３次元物体を備え、前記複数のカメラが、各面に沿って配置された少なくとも１つのカメラを備える、請求項１に記載の撮像システム。
12. 前記複数のカメラのうちの各カメラが、少なくとも１つのマイクロフォンを備える、請求項１に記載の撮像システム。
13. 撮像システムの複数のカメラのうちのそれぞれのカメラに関連する処理されたビデオ画像データを受信することであって、前記複数のカメラのうちの各カメラが、環境のそれぞれの視野のビデオ画像をキャプチャするように構成され、前記処理されたビデオ画像データが、オーバーレイ領域に基づいて、トリミング及びワーピングされたビデオ画像データを備え、前記オーバーレイ領域が、前記複数のカメラのうちの少なくとも２つの近隣のカメラによってキャプチャされたビデオ画像データの重畳部分を含むこと、並びに
    ストリーミングされたビデオを、複数の通信リンクを介してクライアントデバイスに提供することであって、前記ストリーミングされたビデオが、前記処理されたビデオ画像データに基づくこと
    を含む方法。
14. 前記処理されたビデオ画像データの低解像度表現をステッチして低解像度３６０度ビデオ画像データを提供することをさらに含み、前記ストリーミングされたビデオが、前記低解像度３６０度ビデオ画像データを含む、請求項１３に記載の方法。
15. 前記処理されたビデオ画像データをステッチして高解像度３６０度ビデオ画像データを提供することをさらに含み、前記ストリーミングされたビデオが、前記高解像度３６０度ビデオ画像データを含む、請求項１３に記載の方法。
16. 前記クライアントデバイスにメタデータを提供することをさらに含み、前記メタデータが、前記撮像システムに関連する前記複数のカメラの幾何学的配置に関する情報を含む、請求項１３に記載の方法。
17. 前記ストリーミングされたビデオが、ストリーミング通信プロトコルに従って提供され、前記ストリーミング通信プロトコルが、HTTP Live Streaming（ＨＬＳ）又はDynamic Active Streaming over HTTP（ＤＡＳＨ）の少なくとも一方を含む、請求項１３に記載の方法。
18. 時間基準を示す情報を受信すること、及び
    前記時間基準に基づいて、隣接する視野からの前記処理されたビデオ画像データをステッチすること
    をさらに含む、請求項１３に記載の方法。
19. 前記処理されたビデオ画像データをステッチすることが、前記時間基準に基づいて、処理されたビデオ画像を、隣接する処理されたビデオ画像の時間補間表現とステッチすることを含む、請求項１８に記載の方法。
20. 前記クライアントデバイスが、３６０度ビデオ画像データを提供するために、前記ストリーミングされたビデオの少なくとも一部をステッチするように構成される、請求項１３に記載の方法。
21. 前記処理されたビデオ画像データを受信することが、クラウドサーバシステムによって行われる、請求項１３に記載の方法。