[0001] 本発明は、例えば、3D環境をシミュレートするために使用され得るコンテンツなど、コンテンツの取り込み、ストリーミング、および/または再生を行うための方法および装置に関する。
[0002] 没入型の体験を提供するように意図された表示デバイスは、通常、ユーザが自分の頭を回転させて、表示されるシーン中の対応する変化を体験できるようにする。ヘッドマウントディスプレイは、時には360度の視聴をサポートするが、その場合、ユーザは、ヘッドマウントディスプレイを装着しながら向きを変えることができ、シーンは、ユーザの頭部位置が変化すると、変化して表示される。
[0003] このようなデバイスを用いると、ユーザには、前方を見ているときはカメラ位置の正面で取り込まれたシーンが提示され、またユーザが完全に向きを変えたときには、カメラ位置の背後で取り込まれたシーンが提示されるはずである。ユーザは、任意の所与の時間に、自分の頭を後ろに向けることができるが、ユーザの視界は、任意の所与の時間に、限られた視界を知覚する人間の能力の性質により、通常、120度またはそれ以下に制限される。
[0004] 360度のビューをサポートするために、複数のカメラを使用して360度のシーンが取り込まれ得るが、画像は、視聴のために利用可能にされるべき360度のシーンを生成するために組み合わされる。
[0005] 360度ビューは、特定の時間点に表示される画像を決定するために使用される視野角を変更する機会がユーザにない、通常のテレビジョンおよび多くの他の映像アプリケーションのために通常取り込まれ、符号化された単純な前方ビューよりもかなり多くの画像データを含むことを理解されたい。
[0006] ストリーミングされるコンテンツに関連付けられた、例えば、ネットワークデータ制約などの送信制約を考えると、コンテンツを受信し、対話をすることを求めるすべての顧客に対して、フル高精細映像で完全な360度ビューをストリーミングすることは可能ではない可能性がある。このことは、コンテンツが、3D視聴効果を可能にするために左眼および右眼ビューに対応するように意図された画像コンテンツを含む立体視コンテンツである場合、特にそうである。
[0007] 立体視カメラ装備の場合、例えば、魚眼カメラレンズなどの広角レンズが、広いビューイング領域を取り込むために使用され得る。一般的なレンズ幾何形状は知られているかもしれないが、製作時の差は、異なる光学特性を有する異なるレンズを生ずる可能性がある。例えば、レンズの単一バッチで生産された2つの魚眼レンズは、異なる光学的な欠点を有する可能性がある。立体視画像取り込みの場合、別々の左眼および右眼のビューは、通常、カメラ対の別々のカメラを用いて取り込まれる。左眼画像および右眼画像を取り込むために使用されるカメラのそれぞれの上でレンズが異なることになるので、カメラの光学系における差は、左眼画像と右眼画像の間のカメラ間隔から予想されるものを超えて、シーン領域の取り込まれた画像に差を生ずることになる。画像が、個々のレンズの実際の幾何形状ではなく、意図されたレンズ幾何形状を考慮して処理された場合、このような差が、レンダリング(rendering)時に画像内に残ることになる左眼画像および右眼画像における歪みを生ずる可能性がある。
[0008] 立体視システムの場合、左眼画像と右眼画像の間の差は、通常、人間の視聴者により、奥行き情報を提供するものとして解釈される。残念ながら、カメラレンズ差に起因する左眼画像と右眼画像の間の意図しない差は、ユーザに、不適切な奥行き手がかりを提供し、および/または他の画像歪みを生ずることになる。
[0009] 上記の論議を考慮すると、立体視システムおよび/または他のタイプのシステムで使用され得るカメラレンズにより画像の中に導入された歪みの、例えば、再生システムのユーザにより知覚され得る画像品質への影響を低減する、または最小化することのできる方法および装置が求められていることを理解されたい。
[0010] カメラレンズにより導入された歪みの影響を低減する、および/または最小化するための方法および装置が述べられる。ストリーミング装置が記載される。再生装置もまた記載される。本方法および装置は、例えば、レンズ製作時の欠点、または通常の製作変動に起因する歪みが、シーン領域の左眼および右眼ビューを取り込むために使用されるレンズ間の差を生ずる可能性のある立体視システムで使用するのに特によく適している。
[0011] 様々な特徴は、360度のビューイング領域に対応する映像または他のコンテンツの配信、例えば、ストリーミングをサポートするのによく適した方法および装置を対象としているが、本技法は、完全な360度ビューをカバーしない領域の立体視画像を取り込むシステムで使用するのによく適している。本発明の方法および装置は、データ送信制約が、360度のコンテンツの配信を、例えば、最良品質のコーディングおよび最高のサポートされたフレームレートを用いるなど、最大のサポートされた品質レベルで配信するのを困難にする可能性のある、立体視画像コンテンツおよび/または他の画像コンテンツをストリーミングするのに特によく適している。しかし、本方法は、立体視コンテンツに限定されない。
[0012] 様々な実施形態では、魚眼レンズを有するカメラが使用される。魚眼レンズは、広いパノラマ的画像、または半球画像を生成するように意図された、強い視覚的歪みを生成する広角または超広角レンズである。残念ながら、魚眼レンズの使用による歪みは、レンズの不完全さ、および/または、カメラ内のセンサに対するレンズの位置間の差から、レンズごとに、および/または、カメラごとに変化する可能性がある。魚眼レンズは、後に、球または他の3Dでシミュレートされた環境上にマップされる、または投影され得る大きな画像領域を取り込むのによく適しているが、カメラごとに導入された歪みは、魚眼レンズを有するカメラにより取り込まれた画像を高い信頼性で使用することを困難にする、または、異なるレンズにより取り込まれた画像を共に見るのを困難にする可能性がある。
[0013] 別々の左眼画像および右眼画像が取り込まれ、次いで、3D効果を生成するための再生中に視聴者に提示される立体視画像の場合、左眼画像および右眼画像を取り込むために使用されるカメラ間の歪みおよび差は問題であり、および/または、対処されないままである場合、その立体視画像の品質を低下させるおそれがある。
[0014] 様々な実施形態では、例えば、較正プロセスの部分としてカメラ歪み情報が生成される。較正情報は、魚眼レンズを含むカメラでは、おそらく、また通常、カメラごとに存在する。このように、個々のカメラ歪みは、それらがカメラレンズまたはセンサによりレンズ位置決めに導入されたかどうかにかかわらず、検出され得る。時には補正メッシュと呼ばれることのある1組の補正情報が、較正情報に基づいて生成され、いくつかの実施形態では、再生デバイスへと伝達される。このように、カメラ歪みに対する補正は、画像の符号化および/または送信前に行われるのとは反対に、再生デバイスで実施され得る。再生デバイスは、個々のカメラによって導入された歪みを補正する、および/または、補償するために、補正情報、例えば、補正メッシュを使用する。補正が再生デバイスに実装されて、未補正画像を符号化し、送信できるようにすることにより、左眼画像および右眼画像を取り込むために使用されたレンズの差、および/または、意図されたレンズの幾何形状からの差により導入された歪みをなくす、または低減する試みにおいて、取り込まれた画像が送信前に処理された場合に画像符号化中に生ずるおそれのある画像アーティファクトの意図しない増幅が回避される。
[0015] 補正情報の組は、レンズに依存しているため、カメラごとに再生デバイスに伝達される。補正情報は、同じシーン領域に対応する左眼と右眼画像の両方に対して使用され得るテクスチャマップと呼ばれることのあるUVマップを修正するために使用される1組の情報の形態をとってもよく、またいくつかの実施形態ではその形態をとる。UVマッピングは、3Dオブジェクト上に、テクスチャまたはテクスチャマップと呼ばれることのある画像を投影するプロセスのことである。様々な実施形態では、カメラにより取り込まれた復号画像が、環境の3Dモデルの対応する部分に対するテクスチャマップとして使用される。「X」、「Y」、および「Z」は、モデル空間における3Dオブジェクトの軸を示すためにすでに使用されているため、文字「U」および「V」が、2Dテクスチャの軸を示す。UV座標は、面(face)ごとに適用される、例えば、少なくともいくつかの実施形態では、UVマップにおける面は、3Dモデルにおける面と1対1の対応関係を有する。
[0016] したがって、いくつかの実施形態では、左眼画像のレンダリングは、左眼カメラにより導入された歪みを考慮に入れた、左眼カメラに対応するメッシュ補正情報と、左眼画像と右眼画像の両方に使用されるUVマップと、レンダリングされているシーン領域に対応する環境の3Dメッシュモジュールとの使用を含む。3DメッシュモジュールおよびUVマップは、左眼画像および右眼画像のレンダリングに共通のものである。補正情報はレンズに依存しており、したがって、別々の左眼および右眼補正情報が提供される。補正情報は、補正情報が対応する、カメラによって導入された歪みを考慮に入れて、UVマップにおけるノードの位置がどのように変更されるべきかを示す情報を含むことができ、いくつかの実施形態では、その情報を含む。いくつかの実施形態では、補正情報は、共通のUVマップにおいてノードを特定する情報と、2次元画像を3Dモデル上にマップするために、ノード位置がどのくらいシフトされるべきかを示す情報とを含む。したがって、いくつかの実施形態では、補正マップは、共通のUVマップと、個々のレンズ歪みを考慮に入れた、望ましいレンズ依存UVマップとの間の差を示す。左眼画像のレンダリング中に、再生デバイスは、共通のUVマップと、左眼画像に対応する、例えば、補正メッシュなどの補正情報とを考慮して、受信された左眼画像を3Dモデルにマップする。右眼画像のレンダリング中に、再生デバイスは、共通のUVマップと、右眼画像に対応する、例えば、補正メッシュなどの補正情報とを考慮して、受信された右眼画像を3Dモデルにマップする。
[0017] 理解されるように、レンダリングは、様々な方法で、補正情報をUVマップにおける情報に適用することができる。左眼画像および右眼画像のそれぞれに対する補正情報を用いて、修正されたUVマップが、左眼画像および右眼画像のそれぞれについて生成され、修正されたUVマップを有する共通のUVマップが、左眼画像および右眼画像をレンダリングするために使用されるが、他の実施形態では、補正は、必要に応じてレンダラ(renderer)により実施される。例えば、いくつかの実施形態では、受信された情報に基づいて、また環境のどの部分がレンダリングされているか、UVマップのどのノードが、実施されているレンダリングに関連しているか、および、何の補正がこれらのノードに適用可能であるかに基づいて、レンダラが決定するようなレンダリングプロセス中に、修正情報が、共通のUVマップにおける1つまたは複数のノードに適用される。例えば、3Dモデルのセグメントがレンダリングされているとき、レンダリングされているそのセグメントに対応するUVマップにおけるノードは、受信された補正情報に基づいて補正することができ、次いで、例えば、補正されたUVノード情報に基づいて特定された受信画像のセグメントなどの部分が、レンダリングされている3Dモデルのセグメントに適用される。重要ではない再生中に補正情報が適用される特定の方法で補正情報を適用するために、様々な他の手法が同様に、レンダラによって使用され得る。
[0018] 例えば、メッシュ補正情報などの補正情報をカメラごとに提供することにより、適用されるべき補正情報は、UVマップまたは3Dモデルの変更を必要とすることなく、コンテンツを供給するカメラにおける変化が生じたときは常に変更され得る。したがって、カメラに依存している補正情報の伝達は、立体視対の左眼画像と右眼画像の両方のレンダリングに共通であり得るUVマップおよび/または3Dモデル情報の伝達から分離され得る。
[0019] 様々な実施形態では、補正情報は、UVマップにおける個々のノードを特定するノード位置、および、そのノードに対応するオフセットの組の形態で伝達される。例えば、UVマップにおけるノードは、UVマップにおけるノードがUV空間内でどのくらいシフトされるべきかを示す、U座標およびV座標のそれぞれについて示されるオフセットを用いて、その(U、V)座標により特定されることができる。様々な実施形態では、3Dモデルにおけるノードに対して使用される1つまたは複数のUVマップにおけるノードの1対1のマッピングが存在するため、ノードのU、V座標は、修正すべきUVマップのノードを特定し、同時に、3Dマップにおける対応するノードを特定する。
[0020] 画像を3Dモデルへとレンダリングするプロセスの部分として、様々な画像に対応するコンテンツが組み合わされるので、どの復号された画像が、表示されるコンテンツを提供するかを制御するために、マスクが使用され得る。マスクは、復号された画像部分のレンダリングされる画像への相対的な寄与を制御する1組のアルファブレンド係数として実装され得る。例えば、3Dモデルのセグメントに対応するために、補正されたUVマップにより決定されたセグメントは、ブレンド係数に依存する量だけ、表示されるセグメントに寄与することになる。異なるコンテンツストリームは、1つのストリームのコンテンツが表示されるかどうか、または、複数のストリームのコンテンツが、レンダリングプロセスの部分としてブレンドされるのかをブレンド係数が決定して、モデルの同じセグメントに対応することができる。マスクされるべき復号された画像の部分に対応するアルファ係数をゼロに設定することにより、それは、レンダリング処理の部分として表示される画像に寄与することはない。いくつかの実施形態では、異なるストリームのコンテンツが重複する可能性があるが、どのコンテンツストリームが、3D環境のレンダリングされた部分に寄与されるかを制御するために、マスキングが使用される。したがって、1つのシーン領域に対応するコンテンツを提供するように意図されたコンテンツストリームは、それらが、異なるコンテンツストリームから取得された画像からレンダリングされるシーン領域と重複するコンテンツを含むとき、レンダリング中にマスクされ得る。
[0021] いくつかの実施形態では、マスキングまたはブロッキングが使用され得るが、コンテンツを重複させる様々な方向に対応するカメラからのコンテンツが、おそらく共にブレンドされ得る、または、いくつかの実施形態では共にブレンドされる場合、1つまたは複数のエッジ部に沿ってブレンディングが使用される。このようなシステムでは、左眼画像コンテンツは、エッジ部に沿って、他のストリームからの左眼コンテンツとブレンドされ、一方、右眼画像コンテンツは、エッジ部に沿って他のストリームからの右眼画像コンテンツとブレンドされる。したがって、隣接するシーン領域に対応する画像コンテンツを提供するストリームは、エッジ部に沿って共にブレンドされ得るが、一方で、他の部分は、ブレンディングを回避するためにマスクされ得る。
[0022] 3D環境のメッシュモデル、および、1つまたは複数の対応するUVマップは、カメラメッシュ補正情報とは異なる回数で伝達されてもよく、また時には伝達される。カメラメッシュ補正情報は、例えば、再生デバイスが、新しいカメラ対からのコンテンツを供給される少し前に、環境の一部に対応するコンテンツを供給するために使用されているカメラ対の変更に応じて送信され得る。代替的に、複数の補正メッシュは、特定の時間にどの補正情報が使用されるべきかを特定する、再生デバイスに送られる情報とともに、再生デバイスに伝達され、記憶される。このように、補正情報のどの組が所与の時間に提供されるべきかを決定するために再生デバイスによって供給され、使用される単なるインジケータを用いて、再生デバイスによって使用される補正メッシュは、コンテンツを供給するために使用されるカメラ対における変更があるごとに送信される必要はない。
[0023] 3Dモデルが、多数のノードを含む場合、補正は、すべてのノードに対して必要ではない可能性がある。このような場合、左眼画像および右眼画像のそれぞれについてのメッシュ補正情報の組は、UVマップにおけるノードのサブセットを特定する情報を含み、また補正が実施されるべきノードのサブセットについてのノード位置補正情報を提供することができる。したがって、メッシュ補正情報は、UVマップ、および、3Dモデルの対応する部分におけるノードの完全な組に対してより、少ないノードに対するエントリを含むことができる。
[0024] 3Dモデルは、3D空間における環境を表現する。取り込まれたフレームは、レンズ幾何形状に基づいて歪んでいる。メッシュ補正情報は、レンズ対の個々のレンズ間の差を考慮に入れないUVモデルに対応するUVマップを考慮して、受信された復号された画像フレームをどのように3Dモデルの頂点(vertices)にマップするかをレンダラに伝えることにより、各カメラアングルについてのレンズ歪みを補正するために使用される。したがって、補正情報を使用することは、レンズ歪みが取り込まれた画像において反映されるカメラ取り込みドメインからの画像の3Dモデルのドメインへのより正確な変換を容易にする。
[0025] 送信側でレンズ歪みを補償するために画像を処理するのではなく、再生デバイスで補正を実施することは、3Dモデルに対応するUVマップが基づいており、次いで送信のために符号化される2D正距円筒図法(equi-rectangular)の幾何形状へと、取り込まれた画像がまず歪むのを防止するのに役立つ。取り込まれた画像の2D正距円筒図法の幾何形状への符号化前の変換は、特に、損失の大きい画像符号化が送信前に行われる場合における画像処理の部分として、再生デバイスによる受信の前に、エッジ部の周辺における画像データの損失を生ずる可能性がある。
[0026] 様々な実施形態では、3D環境は、画像を取り込む1つまたは複数のカメラが位置する環境を表すために使用される三角形のメッシュをもった球であると推定される。本発明は、球形の3Dモデルの文脈で説明されるが、それは球形の3Dモデルに限定されることなく、他の形状のモデルに対しても使用され得る。
[0027] 例えば、いくつかの実施形態では、3D環境がマップされ、3D環境情報が、再生デバイスに伝達され、元の画像が取り込まれた講堂、競技場、または他の環境の実際の物理的な形状を考慮に入れて、再生中に画像をレンダリングするために使用される3Dデフォルト環境メッシュを修正するために使用される。3D環境マップは、カメラ装備からの、したがって、画像を取り込むために使用されたカメラからの、画像が取り込まれる環境の壁、または他の周囲面までの距離に関する情報を含むことができる。距離情報は、画像が取得された実際の環境に基づいて、環境をシミュレートし、再生画像を調整するために、再生中に使用されるメッシュのグリッド点に一致することができ、時には一致する。
[0028] 様々な実施形態では、映像コンテンツが取得される環境の3Dモデル、および/または、その環境に対応する3D次元情報が生成され、および/または、アクセスされる。環境におけるカメラ位置が文書化される。複数の別々のカメラ位置が、環境内に存在し得る。例えば、別々のエンドゴールのカメラ位置、および、1つまたは複数のミッドフィールドのカメラ位置が、実時間のカメラ送りを取り込むためにサポートされ、使用され得る。
[0029] 3Dモジュールおよび/または他の3D情報が、映像を1人または複数のユーザにストリーミングするために使用されるサーバ、または、画像取り込みデバイスに記憶される。
[0030] 3Dモジュールは、例えば、画像レンダリングおよび合成機能を有する顧客建物内デバイスなど、ユーザの再生デバイスに提供される。顧客建物内デバイスは、例えば、ヘッドマウントディスプレイを介して、顧客建物内デバイスのユーザに表示される環境の3D表現を生成する。
[0031] 様々な実施形態では、任意の所与の時間に、完全な360度より少ない環境が、個々の顧客建物内デバイスにストリーミングされる。顧客建物内デバイスは、ユーザ入力に基づいて、どのカメラ送りがストリーミングされるべきかを示す。ユーザは、顧客建物内デバイスの部分である、またはそれに取り付けられた入力デバイスにより、区画(court)および/またはカメラ位置を選択することができる。
[0032] いくつかの実施形態では、180度の映像ストリームが、コンテンツのストリーミングを担うサーバおよび/またはビデオカメラから、例えば、ライブ、実時間、または、ほぼ実時間のストリームで、顧客の再生デバイスに送信される。再生デバイスは、ユーザの頭部位置と、したがって、予想される再生デバイスのユーザが、再生デバイスにより生成される3D環境内で見ているビューイング領域とを監視する。顧客建物内デバイスは、見られている3D環境の一部のために利用可能な場合、映像を提示し、映像コンテンツは、ビデオコンテンツのないときに提示されるシミュレートされた3D環境を置き換える、またはその代替形態として表示される。再生デバイスのユーザが、自分の頭を回転させると、ユーザに提示される環境の部分は、例えば、ストリーミングされるなど、再生デバイスに供給される映像コンテンツからのものであり、他の部分は、3Dモデルから合成して生成されたものである、および/または、映像コンテンツとは異なる時間に取り込まれた前に供給された画像コンテンツである。
[0033] したがって、再生デバイスは、競技、音楽コンサート、または他のイベントが、なお継続している間に、例えば、正面180度カメラビューに対応する、例えば、ストリーミングにより供給される映像を表示することができ、3D環境の後方部分および/または側方部分は、完全に合成的に、または異なる時間に環境の側方もしくは後方領域の画像コンテンツからのいずれかにより生成される。
[0034] ユーザは、ストリーミングコンテンツを提供するサーバに、位置の変化を知らせることによって、カメラ位置の間を選択することができるが、ストリーミングコンテンツを提供するサーバは、ストリーミングされていない3D環境の部分のための合成環境を生成するのに有用な情報を提供することができる。
[0035] 例えば、いくつかの実施形態では、複数の後方および側方ビューが、異なる時間に、例えば、コンテンツの一部をストリーミングする前に、または、より早い時点で、取り込まれる。画像は、再生デバイスにバッファされる。コンテンツを提供するサーバは、映像ストリームで供給されていない環境部分の合成のために、1組の非実時間シーンもしくは画像のうちのどれが使用されるべきかを、再生デバイスに知らせることができ、またいくつかの実施形態では知らせる。例えば、カメラ位置の後ろで座っているコンサート参加者の画像、および、立っているコンサート参加者の他の画像が、再生デバイスに供給され、記憶され得る。サーバは、特定の時間点において、記憶された画像データのどの組が使用されるべきかを知らせることができる。したがって、観客が立っているとき、サーバは、画像合成中に、背景の180度ビューのために、立っている観衆に対応する画像が使用されるべきであることを知らせることができ、一方、観客が座っているとき、サーバは、3Dカメラ環境の側方または後方部分を合成する場合に、座っている観客に対応する画像もしくは画像合成情報を使用すべきであることを、顧客建物内デバイスに示すことができる。
[0036] 少なくともいくつかの実施形態では、画像取り込み中に、3D環境中の1つまたは複数の位置のそれぞれにおけるカメラの方向が追跡される。顧客建物内デバイスによりシミュレートされるために、前にモデル化された、および/または、マップされた3D環境に対して、取り込まれた画像、例えば、ライブ画像の整列、および/または、他のマッピングを容易にするために、環境内におけるマーカおよび/または、識別点が使用され得る。
[0037] 合成の環境部分と、実際のもの(ストリーミングされるビデオ)とをブレンドすることは、没入型の映像体験を提供する。例えば、環境が以前にモデル化されていない場合など、映像が利用できないときに、環境をシミュレートするために使用される3D情報を作成するように、3D光度測定法(3d photometry)を用いて、環境が測定され、もしくはモデル化されることができ、また時には測定もしくはモデル化される。
[0038] 決定された場所における現実世界の空間における基準マーカの使用は、以前に生成された3Dモデルを用いて、映像の較正と整列を支援する。
[0039] 各カメラの位置的な追跡は、映像が取り込まれると実施される。場所に対するカメラ位置情報は、例えば、X、Y、Z、および度で示すヨー角をマップする、(したがって、各カメラがどこを指しているかを知る)。こうすることは、取り込まれた画像が、環境のどの部分に対応しているかの容易な検出を可能とし、また、取り込まれた映像と共に再生デバイスに伝達されたとき、再生装置が、ユーザへの再生など、画像の提示中に再生デバイスにより生成された合成環境にビデオ取り込みを自動的に重ねることを可能にする。ストリーミングされるコンテンツは、360度より少ないビュー、例えば、カメラ位置の正面における領域の取り込まれた180度ビューに限定され得る。視聴者が周りを見まわすと、後方に向いたとき、シミュレートされた背景(黒い空間ではなく)を、また正面を向いたときは映像を見ることになる。
[0040] 合成環境は、対話的にすることができ、いくつかの実施形態では対話的である。いくつかの実施形態では、仮想的な3D環境内で、ユーザの友人と競技を見ることができるように、複数の実際の視聴者、例えば、異なる顧客建物内デバイスのユーザがシミュレートされた環境に含まれ、ユーザが競技場に実際にいるように見える。
[0041] ユーザの画像は、顧客建物内デバイスに含まれる、または取り付けられたカメラによって取り込まれ、サーバに供給され、シミュレートされた環境を生成における使用のために、他のユーザ、例えば、グループのメンバーに提供することができ、またいくつかの実施形態では提供される。ユーザ画像は、実時間画像である必要はないが、おそらく実時間画像とすることができる。
[0042] 本方法は、実時間で、またはほぼ実時間で、コンテンツを符号化し、提供するために使用され得るが、このような実時間用途に限定されない。実時間およびほぼ実時間の符号化と複数のユーザへのストリーミングをサポートできることを考慮すると、本明細書に記載された方法および装置は、スポーツイベント、コンサート、および/または、個人が、イベントを見て、ステージもしくはフィールドだけを観察するのではなく、向きを変えて、例えば、競技場もしくは観客など、環境のビューを理解できるようにすることを好む他の会場のシーンをストリーミングするのによく適している。360度のビューイングおよび3Dをサポートすることにより、本発明の方法および装置は、存在するならば、および、ユーザの頭が左右もしくは後方に向けられるならばそうである可能性があるが、向きを変えて、様々な視野角からシーンを観察する自由度をもって3D没入型の体験をユーザに提供するように意図されたヘッドマウントディスプレイとともに使用するのによく適している。
[0043] 図1は、コンテンツを取り込み、ストリーミングし、合成された環境において、1人または複数のユーザにコンテンツを一緒に出力するために使用され得る、本発明のいくつかの実施形態に従って実装される例示的なシステムを示す。
[0044] 図2Aは、例えば、区分されていない完全な360度の立体視シーンなど、例示的な立体視シーンを示す。
[0045] 図2Bは、例示的な一実施形態に従って、3つの例示的なシーンへと区分されている例示的な立体視シーンを示す。
[0046] 図2Cは、例示的な一実施形態に従って、4つのシーンへと区分されている例示的な立体視シーンを示す。
[0047] 図3は、例示的な一実施形態に従って、例示的な360度の立体視シーンを符号化する例示的なプロセスを示す。
[0048] 図4は、入力画像部分が、同じ入力画像部分の異なる符号化バージョンを生成するために、様々な符号化器を用いてどのように符号化されるかを示す例を示す。
[0049] 図5は、3つの部分へと区分されている入力立体視シーンの記憶された符号化された部分を示す。
[0050] 図6は、図1のシステムを用いて実施される例示的な実施形態に従って、コンテンツをストリーミングする例示的な方法のステップを示す流れ図である。
[0051] 図7は、本発明の特徴に従って、コンテンツを符号化し、ストリーミングするために使用され得る例示的なコンテンツ配信システム符号化機能を示す。
[0052] 図8は、図7のシステムによりストリーミングされたコンテンツを受信し、復号し、表示するために使用され得る例示的なコンテンツ再生デバイスを示す。
[0053] 図9は、流れ図の形態で、また、図1で示されたシステムによって実装され得る例示的な一実施形態に従って実装される、カメラ較正、画像符号化、およびコンテンツストリーミング方法の第1の部分を示す。
[0054] 図10は、図9の流れ図によって呼び出され得るカメラ較正サブルーチンを示す。
[0055] 図11は、図9で示される流れ図によって呼び出され得る画像取り込みおよびコンテンツストリーミングサブルーチンを示す。
[0056] 図12は、例示的な一実施形態に従って、図1のシステムで使用され得る再生デバイスまたはシステムを動作させる方法を示す。
[0057] 図13は、空のビューを取り込むために、空に向けられた1つまたは複数のカメラと共に、360度の視界のうちの異なる120度セクタに対応する左眼画像および右眼画像を取り込むための複数のカメラ対を含むカメラ装備を示す。
[0058] 図14は、再生動作の部分として、取り込まれた画像が投影され得る完全な球形のビュー/環境を作成するために、異なるカメラビューに対応する5つの異なる環境メッシュマップがどのように組み合わされ得るかを示す。
[0059] 図15は、球形のシミュレートされた環境を作成するための、図15で示された5つのメッシュの完全な組立体視を示す。
[0060] 図16は、図13で示されたカメラ装備のセクタに対応する、魚眼レンズを備えた、左眼カメラおよび右眼カメラにより取り込まれた左眼視画像と右眼視画像とを示す。
[0061] 図17は、図16の左眼視画像および右眼視画像が、符号化されて1つまたは複数の再生デバイスに送信される前に、どのように画像の縁が切り落とされる(crop)のかを示す。
[0062] 図18は、ユーザに提示されるべき3Dシミュレートされたメッシュ環境の一部にマッピングおよび表示するために、画像がさらに処理される前に、再生デバイスに送信された取り込まれた画像への歪みに対する補正において使用されるように、個々のカメラについて生成され、再生デバイスへと送信され得る例示的な補正メッシュを示す。
[0063] 図19は、例えば、カメラ装備のセクタの左右のカメラ対の一方のカメラに対応する画像など、補正メッシュが対応するカメラにより取り込まれた画像に補正メッシュを適用することを示す。
[0064] 図20は、個々の対応する補正マップにより補正された後、図13で示されたカメラ装備のセクタに対応する左眼画像および右眼画像の対を示す。
[0065] 図21は、図20で示された画像の1つが、例えば、投影されるなど、環境メッシュ上に適用されている、カメラ装備の1つのセクタに対応する環境メッシュモデルを示す。
[0066] 図22は、球の形態の完全な3D環境をシミュレートするために、カメラ装備のセクタの各々に対応するカメラ、ならびに、カメラ装備の空および地面カメラにより取り込まれた画像の適用を示す。
[0067] 図23Aは、例示的な実施形態に従って、画像コンテンツを提供する例示的な方法のステップを示す流れ図の第1の部分である。
[0068] 図23Bは、例示的な実施形態に従って、画像コンテンツを提供する例示的な方法のステップを示す流れ図の第2の部分である。
[0069] 図23は、例示的な実施形態に従って、画像コンテンツを提供する方法の流れ図を示す図23Aおよび図23Bの組合せを備える。
[0070] 図24Aは、例示的な実施形態に従って、例示的なコンテンツ再生方法のステップを示す流れ図の第1の部分である。
[0071] 図24Bは、例示的な実施形態に従って、例示的なコンテンツ再生方法のステップを示す流れ図の第2の部分である。
[0072] 図24は、例示的な実施形態に従って、画像コンテンツを提供するコンテンツ再生方法の流れ図を示す図24Aおよび図24Bの組合せを備える。
[0073] 図25は、いくつかの実施形態における例示的なコンテンツ再生方法の部分として実装され得る画像レンダリングサブルーチンのステップを示す流れ図である。
詳細な説明
[0074] 図1は、本発明のいくつかの実施形態に従って実装される例示的なシステム100を示している。システム900は、顧客建物内に位置する1つまたは複数の顧客デバイス、例えば、再生デバイス/コンテンツ再生装置への、コンテンツ配信、例えば、イメージングコンテンツ(imaging content)の配信をサポートする。システム900は、例示的な画像取り込みデバイス102と、コンテンツ配信システム104と、通信ネットワーク105と、複数の顧客建物内106、・・・、110とを含む。画像取り込みデバイス102は、立体視画像の取り込みをサポートする。画像取り込みデバイス102は、本発明の特徴に従って、イメージングコンテンツを取り込み、処理する。通信ネットワーク105は、例えば、光ファイバ−同軸(HFC:hybrid fiber-coaxial)ネットワーク、衛星ネットワーク、および/または、インターネットとすることができる。
[0075] コンテンツ配信システム104は、画像処理/較正/符号化装置112と、例えば、ストリーミングサーバなどのコンテンツ配信デバイス114とを含む。画像処理/較正/符号化装置112は、カメラ較正プロセス中に取り込まれた1つまたは複数の目標画像および/またはグリッドパターンに基づくカメラ較正と、較正されたカメラにより導入された歪みを補償するために再生デバイスにより使用され得る歪み補正もしくは補償メッシュの生成と、例えば、取り込まれた画像の縁の切落としおよび符号化などの処理と、再生デバイスに供給され、レンダリング/画像再生プロセスで使用され得る、較正および/または環境情報をコンテンツ配信デバイス114に供給することと、を含む様々な機能を実施することを担当する。コンテンツ配信デバイス114は、サーバとして実装されることができ、以下で論じられるように、配信デバイスは、3D環境をシミュレートするのに使用され得る、画像較正情報、任意選択の環境情報、およびカメラ装備102によって取り込まれた1つまたは複数の画像をもったコンテンツを求める要求に応答する。画像および/またはコンテンツのストリーミングは、見る人の頭部位置、および/または、画像のソースになるカメラ装備102に対応するイベントにおける位置のユーザ選択などのフィードバック情報に応じ得る、また、時には応じる。例えば、ユーザは、センターラインに位置するカメラ装備から、フィールドゴールに位置するカメラ装備へと画像間を選択する、もしくは切り換えることができ、シミュレートされる3D環境およびストリーミングされる画像は、ユーザにより選択されたカメラ装備に対応するものに変更される。したがって、単一のカメラ装備102が図1で示されているが、複数のカメラ装備がシステム中に存在し、スポーツまたは他のイベントで異なる物理的場所に位置することができ、ユーザは、様々な位置間を切り換えることが可能であり、またユーザ選択は、再生デバイス122からコンテンツサーバ114に伝達されることを理解されたい。別々のデバイス112、114が、画像処理およびコンテンツ配信システム104で示されているが、システムは、様々な機能を実施するための別々のハードウェアを含む、または異なるソフトウェアもしくはハードウェアモジュールにより制御されるが、単一のプロセッサで、もしくはプロセッサ上で実施される様々な機能を備えた単一のデバイスとして実施され得ることを理解されたい。
[0076] 符号化装置112は、本発明に従って、画像データを符号化するための1つまたは複数のエンコーダを含むことができる、またいくつかの実施形態では含む。エンコーダは、異なるデータレートを有する符号化されたバージョンを生成するために、シーンの異なる部分を符号化し、および/または、シーンの所与の部分を符号化するように、並列に使用され得る。複数のエンコーダを並列に使用することは、実時間の、またはほぼ実時間のストリーミングがサポートされる場合、特に有用であり得る。
[0077] コンテンツストリーミングデバイス114は、符号化された画像コンテンツを、例えば、通信ネットワーク105上で1つまたは複数の顧客デバイスに配信するために、符号化されたコンテンツを、例えば、送信するなど、ストリーミングするように構成される。ネットワーク105を介して、コンテンツ配信システム104は、通信ネットワーク105を横切るリンク120により図に示されるように、顧客建物内106、110に位置するデバイスとで、情報を送り、および/または情報を交換することができる。
[0078] 図1の例では、符号化装置112およびコンテンツ配信サーバは、別々の物理的デバイスとして示されているが、いくつかの実施形態では、それらは、コンテンツを符号化し、ストリーミングする単一のデバイスとして実装される。符号化プロセスは、3D、例えば、立体視の画像符号化プロセスとすることができ、その場合、3D画像ビューイングがサポートされ得るように、シーン部分の左眼視および右眼視に対応する情報が符号化されて、符号化された画像データに含まれる。使用される特定の符号化方法は、本用途には重要なものではなく、広範囲のエンコーダが、符号化装置112として、または符号化装置112を実装するために使用され得る。
[0079] 各顧客建物内106、110は、例えば、コンテンツストリーミングデバイス114によりストリーミングされたイメージングコンテンツを復号し、および、再生/表示するための復号装置など、複数のデバイス/再生装置を含むことができる。顧客建物内1 106は、表示デバイス124に接続された復号装置/再生デバイス122を含むが、一方、顧客建物内N 110は、表示デバイス128に接続された復号装置/再生デバイス126を含む。いくつかの実施形態では、表示デバイス124、128は、ヘッドマウント立体視表示デバイスである。
[0080] 様々な実施形態では、復号装置122、126は、対応する表示デバイス124、128上にイメージングコンテンツを提示する。復号装置/再生装置122、126は、コンテンツ配信システム104から受信されたイメージングコンテンツを復号し、復号されたコンテンツを用いてイメージングコンテンツを生成し、表示デバイス124、128上にイメージングコンテンツ、例えば、3D画像コンテンツをレンダリングすることのできるデバイスであり得る。復号装置/再生デバイス122、126のいずれも、図8で示される復号装置/再生デバイス800として使用され得る。図8で示されるものなどのシステム/再生デバイスは、復号装置/再生デバイス122、126のいずれとしても使用され得る。
[0081] 図2Aは、例示的な立体視シーン200、例えば、区分されていない完全な360度の立体視シーンを示している。立体視シーンは、単一のビデオ取り込みプラットフォーム、またはカメラ取付け台に搭載されることの多い複数のカメラ、例えば、ビデオカメラ、から取り込まれた画像データを組み合わせた結果である。
[0082] 図2Bは、例示的な立体視シーン200の区分されたバージョン250を示しており、ここで、シーンは、例示的な一実施形態に従って、例えば、正面の180度部分、左後方の90度部分、および、右後方の90度部分など、3つの(N=3)例示的な部分へと区分されている。
[0083] 図2Cは、例示的な一実施形態に従って、4つの(N=4)部分へと区分されている例示的な立体視シーン200の他の区分されたバージョン280を示している。
[0084] 図2Bおよび図2Cは、2つの例示的な区分を示しているが、他の区分も可能であることを理解されたい。例えば、シーン200は、12個(n=12)の30度部分へと分けることができる。このような実施形態では、各区分を個々に符号化するのではなく、複数の区分が共にグループ化されて、グループとして符号化される。区分の異なるグループがユーザに与えられ、ストリーミングされることができ、各グループのサイズは、シーンの合計度数の点では同じであるが、ユーザの頭部位置、例えば、0から360度の尺度で測定された視野角、に応じてストリーミングされ得る画像の異なる部分に対応する。
[0085] 図3は、例示的な一実施形態に従って、例示的な360度の立体視シーンを符号化する例示的なプロセスを示す。図3で示される方法300への入力は、例えば、シーンの360度ビューを取り込むように配置された複数のカメラにより取り込まれた360度の立体視画像データを含む。例えば、立体視映像などの立体視画像データは、様々な既知のフォーマットのいずれかとすることができ、また大部分の実施形態では、3D体験を可能にするために使用される左眼画像および右眼画像データを含む。本方法は、特に立体視ビデオによく適しているが、本明細書で述べられる技法および方法は、例えば、360度もしくは小さなシーン領域など、2D画像に適用することも可能である。
[0086] ステップ304で、シーンデータ302は、例えば、異なるビューイング方向に対応するN個のシーン領域など、異なるシーン領域に対応するデータへと区分される。例えば、図2Bで示されたものなどの一実施形態では、360度のシーン領域が、3つの区分に、すなわち、90度部分に対応する左後方部分、正面の180度部分、および右後方の90度部分へと分けられる。異なる部分は、異なるカメラにより取り込まれ得るが、それは必ずしも必要なことではなく、実際に、360度のシーンは、図2Bおよび図2Cで示されるように、N個のシーン領域へと分割される前に、複数のカメラから取り込まれたデータから構成され得る。
[0087] ステップ306で、異なるシーン部分に対応するデータは、本発明に従って符号化される。いくつかの実施形態では、各シーン部分は、各部分ごとに複数の可能なビットレートストリームをサポートするために、複数のエンコーダによって、独立して符号化される。ステップ308で、符号化されたシーン部分は、顧客の再生デバイスへとストリーミングするために、例えば、コンテンツ配信104に記憶される。
[0088] 図4は、例えば、シーンの180度正面部分など、入力画像部分が、同じ入力画像部分の異なる符号化バージョンを生成するために、様々なエンコーダを用いてどのように符号化されるかを示す例を示している図面400である。
[0089] 図面400で示されるように、例えば、シーンの180度正面部分など、入力シーン部分402が、符号化のために複数のエンコーダに供給される。その例では、画像コンテンツの様々なデータレートストリームをサポートするための符号化されたデータを生成するために、入力データを、異なる解像度で、異なる符号化技法を用いて符号化するK個の異なるエンコーダがある。複数のK個のエンコーダは、高精細(HD)エンコーダ1 404と、標準精細(SD)エンコーダ2 406と、低減されたフレームレートのSDエンコーダ3 408と、・・・、高圧縮の低減されたフレームレートSDエンコーダK 410とを含む。
[0090] HDエンコーダ1 404は、高ビットレートのHD符号化画像412を生成するために、フル高精細(HD)符号化を実施するように構成される。SDエンコーダ2 406は、入力画像のSD符号化バージョン2 414を生成するために、低解像度の標準精細符号化を実施するように構成される。低減されたフレームレートのSDエンコーダ3 408は、入力画像の低減されたレートのSD符号化バージョン3 416を生成するために、低減されたフレームレートの低解像度SD符号化を実施するように構成される。低減されたフレームレートは、例えば、符号化のためにSDエンコーダ2 406によって使用されるフレームレートの半分とすることができる。高圧縮の低減されたフレームレートSDエンコーダK 410は、入力画像の高圧縮の低減されたレートのSD符号化バージョンK 420を生成するために、高圧縮を用いて、低減されたフレームレートの低解像度SD符号化を実施するように構成される。
[0091] したがって、空間および/または時間解像度の制御は、異なるデータレートのデータストリームを生成するために使用することができ、また、データ圧縮レベルなどの他のエンコーダ設定の制御は、1つまたは複数の所望のデータレートを用いてシーン部分に対応するデータストリームを生成するために、単独で、または、空間および/または時間解像度の制御に加えて使用され得ることを理解されたい。
[0092] 図5は、3つの例示的な部分へと区分されている、入力された立体視シーンの記憶された符号化された部分500を示す。記憶された符号化された部分は、コンテンツ配信システム104に、例えば、メモリにおけるデータ/情報として、記憶され得る。立体視シーンの記憶された符号化された部分500は、符号化された部分の3つの異なる組を含み、ここで、各部分は、異なるシーン領域に対応し、また各組は、対応するシーン部分の複数の異なる符号化されたバージョンを含む。各符号化されたバージョンは、符号化されたビデオデータのバージョンであり、したがって、符号化されている複数のフレームを表す。映像である各符号化されたバージョン510,512、516は、複数の時間期間に対応していること、また、ストリーミングするとき、再生される時間期間に対応する、例えば、フレームなどのその部分は、送信目的で使用されることを理解されたい。
[0093] 図4に関して上に示され、上述されたように、例えば、正面、後方のシーン部分など、各シーン部分は、同じシーン部分のK個の異なるバージョンを生成するために、複数の異なるエンコーダを用いて符号化され得る。所与の入力されたシーンに対応する各エンコーダの出力は、組として共にグループ化され、記憶される。符号化されたシーン部分の第1の組502は、正面180度のシーン部分に対応し、正面180度のシーンの符号化バージョン1 510と、符号化バージョン2 512と、・・・、符号化バージョンK 516とを含む。符号化されたシーン部分の第2の組504は、例えば、90度の左後方シーン部分など、シーン部分2に対応し、90度の左後方シーン部分の符号化バージョン1 520と、符号化バージョン2 522と、・・・、90度の左後方シーン部分の符号化バージョンK 526とを含む。同様に、符号化されたシーン部分の第3の組506は、例えば、90度の右後方シーン部分など、シーン部分3に対応し、また90度の右後方シーン部分の符号化バージョン1 530と、符号化バージョン2 532と、・・・、90度の右後方シーン部分の符号化バージョンK 536とを含む。
[0094] 360度シーンの様々な異なる記憶された符号化部分は、顧客の再生デバイスに送るために、様々な異なるビットレートのストリームを生成するために使用され得る。
[0095] 図6は、例示的な実施形態に従って、画像コンテンツを提供する例示的な方法のステップを示す流れ図600である。流れ図600の方法は、いくつかの実施形態では、図1で示された取り込みシステムを用いて実装される。
[0096] 方法は、ステップ602で、例えば、配信システムの電源が投入され、初期化されて開始する。方法は、開始ステップ602からステップ604へと進む。ステップ604で、コンテンツ配信システム104、例えば、システム104内のサーバ114は、コンテンツを求める要求、例えば、以前に符号化された番組、または、いくつかの場合には、例えば、イベントがなお継続している間に、実時間もしくはほぼ実時間で符号化され、ストリーミングされるライブイベントを求める要求、を受信する。
[0097] 要求に応じて、ステップ604で、サーバ114は、配信のために利用可能なデータレートを決定する。データレートは、サポートされるデータレートを示す、要求内に含まれた情報から、および/または、要求しているデバイスにコンテンツを配信するために利用可能な最大帯域幅を示すネットワーク情報などの他の情報から決定され得る。理解されるように、利用可能なデータレートは、ネットワーク負荷に応じて変化する可能性があり、また、コンテンツがストリーミングされている時間期間中に変化する可能性もある。変化は、ユーザデバイスにより報告され得るか、または、ネットワークが、使用されているデータレートをサポートするには困難であることを示す、パケットが落とされているか、もしくは望ましい時間量を超えて遅延していること、あるいは、現在利用可能なデータレートが、使用するのに利用可能であると決定された元のデータレートよりも低いことを示すメッセージや信号から検出され得る。
[0098] 動作は、ステップ608からステップ608に進み、ここで、例えば、要求時における現在の頭部位置など、コンテンツを求める要求が初期化されるユーザデバイスの現在の頭部位置は0度位置になる。0度、または前方を見る位置は、いくつかの実施形態では、再初期化を行うことを知らせる再生デバイスを用いて、ユーザにより再初期化され得る。時間経過に伴う、ユーザの頭部位置、および/または、例えば、元の頭部位置に対するユーザの頭部位置の変化は、コンテンツ配信システム104に報告され、更新された位置が、コンテンツ配信決定を行うために、以下で論ずるように使用される。
[0099] 動作は、ステップ608からステップ610へと進み、要求されたコンテンツに対応する360度シーンの部分が、再生デバイスを初期化するために送られる。少なくともいくつかの実施形態では、初期化は、例えば、360度のシーンがN個の部分へと分割された場合はN個の部分といった、シーンデータの完全な360度の組を送ることを含む。
[0100] ステップ610の初期化の結果、再生デバイスは、360度の可能なビューイング領域の異なる部分のそれぞれに対応するシーンデータを有することになる。したがって、再生デバイスのユーザが、突然後方を向いた場合、ユーザが自分の頭を回転させる前に見ていた部分と同じように更新された最新のものではないとしても、少なくともいくつかのデータが、ユーザに表示するために利用可能になる。
[0101] 動作は、ステップ610からステップ612およびステップ622へと進む。ステップ622は、全体(global)更新期間ごとに少なくとも1回、360度シーン全体の更新されたバージョンを再生デバイスが受信することを確実にするために使用される、全体シーン更新経路に対応する。ステップ610で初期化されると、待機ステップ622で、所定の時間期間の間、全体更新プロセスが遅延される。次いで、ステップ624で、360度シーン更新が行われる。破線の矢印613は、ステップ622に対応する支援期間中に、シーン部分が再生デバイスに伝達されたことに関する情報が伝達されることを表している。ステップ624で、360度シーンの全体が送信され得る。しかし、いくつかの実施形態では、ステップ624ですべての部分は送信されない。いくつかの実施形態では、待機期間622中に更新されたシーン部分は、それらが、ユーザの頭部位置に基づいてシーンの少なくともいくつかの部分を送る通常のストリーミングプロセス中にすでにリフレッシュされているので、ステップ624で行われる更新から除外される。
[0102] 動作は、ステップ624から待機ステップ622へと戻り、次の全体更新の前に待機が行われる。ステップ622で使用される待機期間を調整することにより、異なる全体リフレッシュレートがサポートされ得ることを理解されたい。いくつかの実施形態では、コンテンツサーバは、提供されるシーンコンテンツのタイプに基づいて、待機期間、したがって、全体基準期間を選択する。主なアクションが前方を向いた領域で生じ、リフレッシュする理由の1つが屋外の照明状態の可能な変化であるスポーツイベントの場合には、待機期間は、例えば、分または複数分のオーダーであるなど、比較的長くてよい。異なる歌が演奏されて、高い頻度で観客のアクションや行動が変化し得るロックコンサートの場合には、ユーザが、正面ステージのビューイング領域で進行していることに加えて、向きを変えて観客の反応を見て、観客に起こっていることを感じ取ることを望むので、全体リフレッシュレートは、スポーツイベントのためよりも高くなり得、時には高い。
[0103] いくつかの実施形態では、全体基準期間は、ストリーミングされている表示部分に応じて変更される。例えば、スポーツイベントの競技部分の間には、全体リフレッシュレートは比較的低くすることができるが、イベントにおける、もしくは再生デバイスによりイベントを見ている人が前方の主領域から自分の頭部を回転させる可能性がより高い、タッチダウン後の瞬間の間、または、タイムアウトもしくは休憩時間中には、全体基準レートは、ステップ622で使用される、例えば、リフレッシュ期間の制御など、待機を減らすことにより増加され得る、またいくつかの実施形態では増加される。
[0104] 全体リフレッシュプロセスが、ステップ622および624を参照して記載されてきたが、シーンの部分の通常の供給が記載される。理解されるように、シーンまたはシーン部分の通常のリフレッシュは、少なくとも1つの部分について起こり、データレートは、サポートされるビデオフレームレートで許容される。したがって、例えば、自分の頭部が向いていることが示されている部分など、少なくとも1つのフレーム部分に関して、利用可能なデータレートが十分であると仮定すると、完全なビデオストリーミングフレームレートで供給されることになる。
[0105] ステップ612で、シーン部分は、ユーザの、例えば、視野角など、示された頭部位置に基づいて提供されるように選択される。選択された部分は、例えば、周期的に、再生デバイスへと、例えば、ストリーミングされるなど、送信される。その部分に対応するデータがストリーミングされるレートは、いくつかの実施形態では、ビデオフレームレートに依存する。例えば、少なくとも1つの選択された部分は、サポートされる完全なフレームレートでストリーミングされることになる。ステップ612で、通常、少なくとも1つのシーン部分が選択されるが、例えば、ユーザが面しているシーン部分、ならびに、最も近い次のシーン部分など、複数のシーン部分が選択される。利用可能なデータレートが、複数のフレーム部分の伝達をサポートするのに十分である場合、また、さらなる追加のシーン部分が選択されて供給され得る。
[0106] ステップ612で、ストリーミングされるべきシーン部分が選択された後、動作は、ステップ614へと進み、ここで、選択されたストリーム部分の符号化されたバージョンが、例えば、利用可能なデータレートおよびユーザの見ている位置に基づいて選択される。例えば、現在報告された頭部により示された、ユーザが面しているシーン部分のフルレートの高解像度バージョンが、ストリーミングされ得る、また通常ストリーミングされることになる。現在の頭部位置の左および/または右への1つ以上のシーン部分が、現在見られていないシーン領域を送信するのに必要な帯域幅の量を低減する、より低い解像度で、低い時間レートで、または、他の符号化手法を用いてストリーミングされるために選択され得る。隣接するシーン部分の符号化されたバージョンの選択は、現在見ているシーン部分の高品質バージョンが送信された後にストリーミングする帯域幅の量に依存することになる。現在見られていないシーン部分は、より低い解像度の符号化されたバージョンとして、または、フレーム間の時間距離のより大きい符号化されたバージョンとして送られ得るが、利用可能な十分な帯域幅がある場合、フル解像度の高品質バージョンが、周期的に、または、高い頻度で送られ得る。
[0107] ステップ616で、選択されたシーン部分の選択された符号化されたバージョンが、コンテンツを要求した再生デバイスに送られる。したがって、ステップ616で、例えば、複数の連続するフレームに対応する立体視ビデオコンテンツなど、1つまたは複数の部分に対応する符号化されたコンテンツが、再生デバイスへとストリーミングされる。
[0108] 動作は、ステップ616からステップ618へと進み、ユーザの現在の頭部位置を示す情報が受信される。この情報は、再生デバイスから、周期的に、および/または、頭部位置の変化の検出に応じて送られ得る。頭部位置の変化に加えて、利用可能なデータレートにおける変化は、どのコンテンツがストリーミングされるかに影響を与え得る。動作は、ステップ618から620へと進み、再生デバイスへのコンテンツ配信のために使用され得る現在のデータレートの決定が行われる。したがって、コンテンツ配信システムは、要求しているデバイスへのストリーミングをサポートするのに利用可能な帯域幅の量における変化を検出することができる。
[0109] 動作は、ステップ620からステップ612へと進み、例えば、番組もしくはイベントが終了するなど、コンテンツが完全に配信されるまで、または、コンテンツを要求した再生デバイスからセッションが終了されることを示す信号が受信されるまで、あるいは、頭部位置更新が検出されるなどの再生デバイスからの期待された信号が受信されず、再生デバイスがもはやコンテンツサーバ114と通信状態にないことを示すまで、ストリーミングは継続する。
[0110] 上述の方法で配信されるシーンデータから、再生デバイスは、ユーザが急に自分の頭部を回転させた場合に表示するために、それに利用可能な各シーン部分に対応する少なくともいくつかのデータを有する。これは、多くの人々にとって見ている位置の快適ではない変化であるため、ユーザが、非常に短い期間内に自分の頭部を完全に回転させることはまれであることを理解されたい。したがって、完全な360度のシーンが、常には送信されないかもしれないが、任意の所与に時間に見られる可能性が最も高いシーン部分(複数可)の高品質バージョンが、ユーザにストリーミングされ、利用可能にすることができる。
[0111] 符号化プロセスは、個々のユーザのそれぞれに対して別々にコンテンツを符号化することを必要とせずに、シーンのN個の部分が、異なるユーザに対して異なって送信され、処理されることを可能にするので、コンテンツ配信システム104は、多数の同時ユーザをサポートすることができる。したがって、スポーツまたは他のイベントの実時間の、またはほぼ実時間のストリーミングを可能にするための実時間符号化をサポートするために、いくつかの並列エンコーダが使用され得るが、使用されるエンコーダの数は、コンテンツがストリーミングされる再生デバイスの数よりもはるかに少ない傾向がある。
[0112] コンテンツの部分が、360度ビューに対応する部分として記載されているが、シーンは、垂直の次元も有する空間の平坦化されたバージョンを表すことができる、またいくつかの実施形態では表していることを理解されたい。再生デバイスは、例えば、空間など、3D環境のモデルを用いてシーン部分をマップし、垂直の見ている位置に対して調整することができる。したがって、本出願で論じられる360度は、ユーザが、自分の注視レベルを保持しながら、自分の視野角を左または右に変化させたかのごとく、水平に相対する頭部位置を指す。
[0113] 図7は、本発明の特徴に従って、コンテンツを符号化し、ストリーミングするために使用され得る符号化機能を備えた例示的なコンテンツ配信システム700を示す。
[0114] システムは、本発明の特徴に従って、符号化、記憶、ならびに、送信および/またはコンテンツ出力を実施するために使用され得る。いくつかの実施形態では、システム700またはその要素は、図6および図23に示されたプロセスに対応する動作を実施する。コンテンツ配信システム700は、図1のシステム104として使用され得る。図7で示されるシステムは、コンテンツの符号化、処理、およびストリーミングのために使用されるが、システム700は、また、処理されたおよび/または復号された画像データを復号して、例えば、操作者に表示する能力を含み得ることを理解されたい。
[0115] システム700は、ディスプレイ702と、入力デバイス704と、入力/出力(I/O)インターフェース706と、プロセッサ708と、ネットワークインターフェース710と、メモリ712とを含む。システム700の様々な構成要素は、システム700の構成要素間でデータが伝達され得るようにするバス709を介して共に結合される。
[0116] メモリ712は、例えば、ルーチンなど、様々なモジュールを含み、モジュールは、プロセッサ708により実行されたとき、本発明に従って、区分、符号化、記憶、および、ストリーミング/送信および/または出力動作を実施するようにシステム700を制御する。
[0117] メモリ712は、例えば、ルーチンなど、様々なモジュールを含み、モジュールは、プロセッサ707により実行されたとき、本発明に従って、没入型の立体視映像取得、符号化、記憶、および、送信および/または出力方法を実装するように、コンピュータシステム700を制御する。メモリ712は、制御ルーチン714と、区分モジュール706と、エンコーダ(複数可)718と、検出モジュール719と、ストリーミングコントローラ720と、例えば、シーンの360度立体視映像などの受信された入力画像732と、符号化されたシーン部分734と、タイミング情報736と、環境メッシュモデル738と、UVマップ(複数可)740と、第1の補正メッシュ情報742、第2の補正メッシュ情報744、第3の補正メッシュ情報746、第4の補正メッシュ情報748、第5の補正メッシュ情報750、および第6の補正メッシュ情報752を含む複数の補正メッシュ情報の組と、を含む。いくつかの実施形態では、モジュールは、ソフトウェアモジュールとして実装される。他の実施形態では、モジュールは、例えば、個々の回路として、ハードウェアで実施され、各モジュールは、モジュールが対応する機能を実施するための回路として実装される。さらに他の実施形態では、モジュールは、ソフトウェアとハードウェアの組合せを用いて実装される。
[0118] 制御ルーチン714は、システム700の動作を制御するためのデバイス制御ルーチンと通信ルーチンとを含む。区分モジュール716は、本発明の特徴に従って、シーンの受信された立体視360度バージョンを、N個のシーン部分へと区分するように構成される。
[0119] エンコーダ(複数可)718は、本発明の特徴に従って、例えば、シーンの360度バージョンおよび/または1つまたは複数のシーン部分などの受信された画像コンテンツを符号化するように構成された複数のエンコーダを含むことができる、またいくつかの実施形態では含む。いくつかの実施形態では、エンコーダ(複数可)は、複数のエンコーダを含み、各エンコーダは、所与のビットレートストリームをサポートするために、立体視シーン、および/または、区分されたシーン部分を符号化するように構成される。したがって、いくつかの実施形態では、各シーン部分は、各シーンに対する複数の異なるビットレートストリームをサポートするために、複数のエンコーダを用いて符号化され得る。エンコーダ(複数可)718の出力は、例えば、再生デバイスなどの顧客デバイスへとストリーミングするために、メモリに記憶される符号化されたシーン部分734である。符号化されたコンテンツは、ネットワークインターフェース710を介して、1つまたは複数の異なるデバイスへとストリーミングされ得る。
[0120] 検出モジュール719は、例えば、第1の立体視カメラ対などの現在のカメラ対からのコンテンツをストリーミングすることから、例えば、第2もしくは第3の立体視カメラ対などの他のカメラ対への、ネットワーク制御された切換えを検出するように構成される。すなわち、検出モジュール719は、システム700が、例えば、第1の立体視カメラ対などの所与の立体視カメラ対により取り込まれた画像を用いて生成されたコンテンツストリームのストリーミングから、他のカメラ対により取り込まれた画像を用いて生成されたコンテンツストリームのストリーミングへと切り換えたかどうかを検出する。いくつかの実施形態では、検出モジュールは、例えば、再生デバイスが、以前に参加されていたコンテンツとは異なるコンテンツストリームに参加されたことを示す、ユーザ再生デバイスからの信号を検出するなど、第1の立体視カメラ対からのコンテンツを含む第1のコンテンツストリームを受信することから、第2の立体視カメラ対からのコンテンツを含む第2のコンテンツストリームを受信することへのユーザ制御された変更を検出するようにさらに構成される。ストリーミングコントローラ720は、例えば、通信ネットワーク105上で、符号化された画像コンテンツを1つまたは複数の顧客デバイスに配信するために、符号化されたコンテンツのストリーミングを制御するように構成される。様々な実施形態では、流れ図600および/または流れ図2300の様々なステップは、ストリーミングコントローラ720の要素によって実装される。
[0121] ストリーミングコントローラ720は、要求処理モジュール722と、データレート決定モジュール724と、現在の頭部位置決定モジュール726と、選択モジュール728と、ストリーミング制御モジュール730とを含む。要求処理モジュール722は、顧客再生デバイスからのイメージングコンテンツを求める受信された要求を処理するように構成される。コンテンツを求める要求は、様々な実施形態では、ネットワークインターフェース710における受信器により受信される。いくつかの実施形態では、コンテンツを求める要求は、要求する再生デバイスの身元を示す情報を含む。いくつかの実施形態では、コンテンツを求める要求は、顧客再生デバイスによりサポートされるデータレートと、例えば、ヘッドマウントディスプレイの位置などのユーザの現在の頭部位置とを含むことができる。要求処理モジュール722は、さらなるアクションをとるために、受信された要求を処理し、取り出された情報をストリーミングコントローラ720の他の要素に提供する。コンテンツを求める要求は、データレート情報と、現在の頭部位置情報とを含むことができるが、様々な実施形態では、再生デバイスによりサポートされるデータレートは、ネットワークテスト、および、システム700と再生デバイスとの間の他のネットワーク情報交換から決定され得る。
[0122] データレート決定モジュール724は、イメージングコンテンツを顧客デバイスにストリーミングするために使用され得る利用可能なデータレートを決定するように構成される、例えば、複数の符号化されたシーンがサポートされるので、コンテンツ配信システム700は、コンテンツを複数のデータレートで顧客デバイスにストリーミングすることをサポートすることができる。データレート決定モジュール724は、システム700からのコンテンツを要求する再生デバイスによりサポートされるデータレートを決定するようにさらに構成される。いくつかの実施形態では、データレート決定モジュール724は、ネットワーク測定に基づいて、画像コンテンツの配信のために利用できるデータレートを決定するように構成される。
[0123] 現在の頭部位置決定モジュール726は、再生デバイスから受信された情報から、現在の視野角、および/または、例えば、ヘッドマウントディスプレイの位置などのユーザの現在の頭部位置を決定するように構成される。いくつかの実施形態では、再生デバイスは、現在の頭部位置情報をシステム700に定期的に送り、現在の頭部位置決定モジュール726は、現在の視野角および/または現在の頭部位置を決定するために、情報を受け取り、処理する。
[0124] 選択モジュール728は、ユーザの現在の視野角/頭部位置情報に基づいて、360度のシーンのどの部分を再生デバイスにストリーミングするべきかを決定するように構成される。選択モジュール728は、コンテンツのストリーミングをサポートするために利用可能なデータレートに基づいて、決定されたシーン部分の符号化されたバージョンを選択するようにさらに構成される。
[0125] ストリーミング制御モジュール730は、本発明の特徴に従って、様々なサポートされたデータレートで、例えば、360度の立体視シーンの複数の部分などの画像コンテンツのストリーミングを制御するように構成される。いくつかの実施形態では、ストリーミング制御モジュール730は、再生デバイスにおけるシーンメモリを初期化するために、コンテンツを要求する再生デバイスに、360度の立体視シーンのN個の部分をストリーミングするのを制御するように構成される。様々な実施形態では、ストリーミング制御モジュール730は、決定されたシーン部分の選択された符号化されたバージョンを、例えば、決定されたレートで、定期的に送るように構成される。いくつかの実施形態では、ストリーミング制御モジュール730は、例えば、毎分1回などの時間間隔に従って、360度のシーンの更新を再生デバイスに送るようにさらに構成される。いくつかの実施形態では、360度シーンの更新を送ることは、完全な360度の立体視シーンのN個のシーン部分、または、N−X個のシーン部分を送ることを含み、ここにおいて、Nは、完全な360度の立体視シーンが区分された部分の合計数であり、Xは、再生デバイスに最近送られた選択されたシーン部分を表す。いくつかの実施形態では、ストリーミング制御モジュール730は、最初に初期化のためにN個のシーン部分を送った後、360度シーンの更新を送る前に所定時間の間待機する。いくつかの実施形態では、360度シーンの更新を送信することを制御するためのタイミング情報は、タイミング情報736に含まれる。いくつかの実施形態では、ストリーミング制御モジュール730は、リフレッシュ間隔の間に再生デバイスに送信されていないシーン部分を特定し、リフレッシュ間隔の間に再生デバイスに送信されなかった特定されたシーン部分の更新されたバージョンを送信するようにさらに構成される。
[0126] 様々な実施形態では、ストリーミング制御モジュール730は、各リフレッシュ期間中に少なくとも1回、再生デバイスが、前記シーンの360度バージョンを完全にリフレッシュできるようにするために、定期的に、N個の部分のうちの少なくとも十分な数を再生デバイスに伝達するように構成される。
[0127] いくつかの実施形態では、ストリーミングコントローラ720は、例えば、ネットワークインターフェース710内の送信器を介して、例えば、図13で示されたものなどの立体視カメラ対のカメラなどの1つまたは複数のカメラによって取り込まれた画像コンテンツから生成された符号化された画像を含む立体視コンテンツストリーム(例えば、符号化されたコンテンツストリーム734)を送信するよう、システム700を制御するように構成される。いくつかの実施形態では、ストリーミンコントローラ720は、画像コンテンツをレンダリングするのに使用される環境メッシュモデル738を、1つまたは複数の再生デバイスに送信するよう、システム700を制御するように構成される。いくつかの実施形態では、ストリーミングコントローラ720は、第1の立体視カメラ対により取り込まれた画像の部分を、画像レンダリング動作の部分として、環境メッシュモデルの一部にマッピングするのに使用されるように、第1のUVマップを、再生デバイスへと送信するようさらに構成される。
[0128] 様々な実施形態では、ストリーミングコントローラ720は、例えば、第1、第2、第3、第4、第5、第6の補正メッシュ情報などの1つまたは複数の組の補正メッシュ情報を再生デバイスに提供する(例えば、ネットワークインターフェース710における送信器を介して送信する)ようにさらに構成される。いくつかの実施形態では、第1の補正メッシュ情報は、第1の立体視カメラ対の第1のカメラにより取り込まれた画像コンテンツをレンダリングするのに使用され、第2の補正メッシュ情報は、第1の立体視カメラ対の第2のカメラにより取り込まれた画像コンテンツをレンダリングするのに使用され、第3の補正メッシュ情報は、第2の立体視カメラ対の第1のカメラにより取り込まれた画像コンテンツをレンダリングするのに使用され、第4の補正メッシュ情報は、第2の立体視カメラ対の第2のカメラにより取り込まれた画像コンテンツをレンダリングするのに使用され、第5の補正メッシュ情報は、第3の立体視カメラ対の第1のカメラにより取り込まれた画像コンテンツをレンダリングするのに使用され、第6の補正メッシュ情報は、第3の立体視カメラ対の第2のカメラにより取り込まれた画像コンテンツをレンダリングするのに使用される。いくつかの実施形態では、ストリーミングコントローラ720は、第2の立体視カメラ対により取り込まれたコンテンツが、第1の立体視カメラ対からのコンテンツに代えて、再生デバイスへとストリーミングされたとき、第3および第4の補正メッシュ情報が使用されるべきであることを、例えば、制御信号を送ることにより、再生デバイスに示すようにさらに構成される。いくつかの実施形態では、ストリーミングコントローラ720は、i)前記第1の立体視カメラ対から前記第2の立体視対へのストリーミングコンテンツからのネットワーク制御切換え、または、ii)前記第1の立体視カメラ対からのコンテンツを含む第1のコンテンツストリームを受信することから、第2の立体視カメラ対からの符号化されたコンテンツを含む第2のコンテンツストリームを受信することへのユーザ制御変更、を検出モジュール719が検出することに応じて、第3および第4の補正メッシュ情報が使用されるべきであることを再生デバイスに示すようにさらに構成される。
[0129] メモリ712は、環境メッシュモデル738と、UVマップ(複数可)740と、第1の補正メッシュ情報742、第2の補正メッシュ情報744、第3の補正メッシュ情報746、第4の補正メッシュ情報748、第5の補正メッシュ情報750、および第6の補正メッシュ情報752を含む補正メッシュ情報の組とをさらに含む。システムは、画像コンテンツのレンダリングに使用するために、環境メッシュモデル738を1つまたは複数の再生デバイスに提供する。UVマップ(複数可)740は、画像レンダリング動作の部分として、第1の立体視カメラ対により取り込まれた画像の部分を、環境メッシュモデル738の一部にマッピングするために使用される少なくとも第1のUVマップを含む。第1の補正メッシュ情報742は、第1の立体視カメラ対の前記第1のカメラの第1のレンズの1つまたは複数の光学特性の測定に基づいて生成された情報を含み、また、第2の補正メッシュは、第1の立体視カメラ対の前記第2のカメラの第2のレンズの1つまたは複数の光学特性の測定に基づいて生成された情報を含む。いくつかの実施形態では、第1および第2の立体視カメラ対は、前方視方向に対応するが、ストリーミングのためにコンテンツが取り込まれている領域またはイベント場所における異なる場所に対応する。
[0130] いくつかの実施形態では、プロセッサ708は、流れ図600および/または2300で論じられるステップに対応する様々な機能を実施するように構成される。いくつかの実施形態では、プロセッサは、様々な機能を実施しするために、メモリに記憶されたルーチンおよび情報を使用し、また、本発明の方法に従って動作させるようにシステム700を制御する。一実施形態では、プロセッサ708は、第1の補正メッシュ情報と第2の補正メッシュ情報とを再生デバイスに提供するようシステムを制御するように構成され、第1の補正メッシュ情報は、第1のカメラにより取り込まれた画像コンテンツをレンダリングするのに使用するためのものであり、第2の補正メッシュ情報は、第2のカメラにより取り込まれた画像コンテンツをレンダリングするのに使用するためのものである。いくつかの実施形態では、第1の立体視カメラ対は第1の方向に対応しており、プロセッサは、第1および第2のカメラにより取り込まれた画像コンテンツから生成された符号化された画像を含む立体視コンテンツストリームを送信するよう、システム700を制御するようにさらに構成される。いくつかの実施形態では、プロセッサ708は、画像コンテンツをレンダリングするのに使用されるべき環境メッシュモデルを再生デバイスに送信するようにさらに構成される。いくつかの実施形態では、プロセッサ708は、画像レンダリング動作の部分として、第1の立体視カメラ対により取り込まれた画像の部分を、環境メッシュモデルの一部にマップするために使用されるべき第1のUVマップを、再生デバイスに送信するようにさらに構成される。いくつかの実施形態では、プロセッサ708は、第3の補正メッシュ情報と第4の補正メッシュ情報を再生デバイスに提供するようにシステム700を制御するようさらに構成され、第3の補正メッシュ情報は、第2の立体視カメラ対の第1のカメラにより取り込まれた画像コンテンツをレンダリングするのに使用するためのものであり、第4の補正メッシュ情報は、第2の立体視カメラ対の第2のカメラにより取り込まれた画像コンテンツをレンダリングするのに使用するためのものである。いくつかの実施形態では、プロセッサ708は、第2のカメラ対により取り込まれたコンテンツが、第1のカメラ対からのコンテンツに代えて再生デバイスにストリーミングされるとき、第3および第4の補正メッシュ情報が使用されるべきであることを再生デバイスに示す(例えば、ネットワークインターフェース710を介して送信する)ように、システム700を制御するようさらに構成される。いくつかの実施形態では、プロセッサ708は、i)第1の立体視カメラ対から第2の立体視対へ、ストリーミングコンテンスからのネットワーク制御切換え、または、ii)第1の立体視カメラ対からのコンテンツを含む第1のコンテンツストリームを受信することから、第2の立体視カメラ対からの符号化されたコンテンツを含む第2のコンテンツストリームを受信することへのユーザ制御変更、をシステムが検出することに応答して、第3および第4の補正メッシュ情報が使用されるべきであることを再生デバイスに示すように、システム700を制御するようにさらに構成される。いくつかの実施形態では、プロセッサ708は、第5および第6の補正メッシュ情報を再生デバイスに提供するように、システム700を制御するようさらに構成され、第5の補正メッシュ情報は、第3の立体視カメラ対の第1のカメラにより取り込まれた画像コンテンツをレンダリングするのに使用するためのものであり、第6の補正メッシュ情報は、第3の立体視カメラ対の第2のカメラにより取り込まれた画像コンテンツをレンダリングするのに使用するためのものである。
[0131] 図8は、本発明に従って実施されるコンピュータシステム/再生デバイス800を示しており、それは、図1および図7で示されたものなど、コンテンツ配信システムから受信されたイメージングコンテンツを受信し、復号し、記憶し、表示するために使用され得る。再生デバイスは、ヘッドマウントディスプレイ805とすることのできるOCULUS RIFT(登録商標)VR(仮想現実)ヘッドセットなどの3Dヘッドマウントディスプレイと共に使用され得る。デバイス800は、受信された符号化された画像データを復号して、顧客に表示するための3D画像コンテンツを生成する能力を含む。いくつかの実施形態では、再生デバイスは、家庭またはオフィスなどの顧客建物内の場所に設けられるが、画像取り込みサイトにも同様に設けられ得る。デバイス800は、本発明に従って、信号の受信、復号、表示、および/または他の動作を実施することができる。
[0132] デバイス800は、ディスプレイ802と、表示デバイスインターフェース803と、入力デバイス804と、入力/出力(I/O)インターフェース806と、プロセッサ808と、ネットワークインターフェース810と、メモリ812とを含む。再生デバイス800の様々な構成要素は、システム800の構成要素間でデータが伝達されることを可能にするバス809を介して共に接続される。いくつかの実施形態では、ディスプレイ802は、破線の枠を用いて図示された任意選択の要素として含まれているが、いくつかの実施形態では、例えば、ヘッドマウント立体視表示デバイスなどの外部の表示デバイス805が、表示デバイスインターフェース803を介して再生デバイスに接続され得る。
[0133] I/Oインターフェース806を介して、システム800は、他のデバイスと信号および/または情報を交換するために外部デバイスに接続され得る。いくつかの実施形態では、I/Oインターフェース806を介して、システム800は、外部デバイスから情報および/または画像を受信し、情報および/または画像を外部デバイスに出力することができる。いくつかの実施形態では、インターフェース806を介して、システム800は、例えば、ハンドヘルドコントローラなどの外部コントローラに接続され得る。
[0134] 例えば、CPUなどのプロセッサ808は、本発明に従って動作させるようシステム800を制御するために、メモリ812におけるルーチン814とモジュールとを実行し、記憶された情報を使用する。プロセッサ808は、システム800の一般的な動作全体を制御することを担当する。様々な実施形態では、プロセッサ1108は、再生システム800により実施されるものとして論じられてきた機能を実施するように構成される。
[0135] ネットワークインターフェース810を介して、システム800は、例えば、通信ネットワーク105などの通信ネットワーク上で、様々な外部デバイスに/から、信号および/または情報(例えば、シーンに対応する符号化された画像および/または映像コンテンツを含む)を伝達し、および/または受信する。いくつかの実施形態では、システムは、コンテンツ配信システム700から、ネットワークインターフェース810を介して、1つまたは複数の異なるカメラにより取り込まれた符号化された画像を含む1つまたは複数のコンテンツストリームを受信する。受信されたコンテンツストリームは、例えば、符号化された画像824などの受信された符号化されたデータとして記憶され得る。いくつかの実施形態では、インターフェース810は、第1のカメラにより取り込まれた画像コンテンツを含む第1の符号化された画像と、第2のカメラに対応する第2の符号化された画像とを受信するように構成される。ネットワークインターフェース810は、受信および送信動作がそれを介して実施される受信器と送信器とを含む。いくつかの実施形態では、インターフェース810は、第1の補正メッシュ情報842と、第2の補正メッシュ情報844と、第3の補正メッシュ情報846と、第4の補正メッシュ情報848と、第5の補正メッシュ情報850と、第6の補正メッシュ情報852とを含む複数の異なるカメラに対応する補正メッシュ情報を受信するように構成され、それらは、次いでメモリ812に記憶される。さらに、いくつかの実施形態では、インターフェース810を介して、システムは、1つまたは複数のマスク(複数可)832と、環境メッシュモデル838と、UVマップ(複数可)840とを受信し、それらは次いでメモリ812に記憶される。
[0136] メモリ812は、例えば、ルーチンなどの様々なモジュールを含み、モジュールは、プロセッサ808により実行されたとき、本発明に従って復号および出力動作を行うように再生デバイス800を制御する。メモリ812は、制御ルーチン814と、コンテンツを求める要求生成モジュール816と、頭部位置および/または視野角決定モジュール818と、復号器モジュール820と、3D画像生成モジュールとも呼ばれる立体視画像レンダリングエンジン822と、決定モジュールと、受信された符号化された画像コンテンツ824、復号された画像コンテンツ826、360度の復号されたシーンバッファ828、生成された立体視コンテンツ830、マスク(複数可)832、環境メッシュモデル838、UVマップ(複数可)840を含むデータ/情報と、第1の補正メッシュ情報842、第2の補正メッシュ情報844、第3の補正メッシュ情報846、第4の補正メッシュ情報848、第5の補正メッシュ情報850、および第6の補正メッシュ情報852を含む複数の受信された補正メッシュ情報の組と、を含む。
[0137] 制御ルーチン814は、デバイス800の動作を制御するためのデバイス制御ルーチンと通信ルーチンとを含む。要求生成モジュール816は、コンテンツを提供するようにコンテンツ配信システムに送るために、コンテンツを求める要求を生成するように構成される。コンテンツを求める要求は、様々な実施形態では、ネットワークインターフェース810を介して送られる。頭部位置および/または視野角決定モジュール818は、現在の視野角、および/または、例えば、ヘッドマウントディスプレイの位置などのユーザの現在の頭部位置を決定し、決定された位置および/または視野角情報をコンテンツ配信システム700に報告するように構成される。いくつかの実施形態では、再生デバイス800は、現在の頭部位置情報をシステム700に定期的に送る。
[0138] 復号器モジュール820は、例えば、復号された画像826などの復号された画像データを作成するように、コンテンツ配信システム700から受信された符号化された画像コンテンツ824を復号するように構成される。復号された画像データ826は、復号された立体視シーンおよび/または復号されたシーン部分を含むことができる。いくつかの実施形態では、復号器820は、第1の復号された画像を生成するために第1の符号化された画像を復号し、第2の復号された画像を生成するために第2の受信された符号化された画像を復号するように構成される。復号された第1および第2の画像は、記憶された復号された画像826に含まれる。
[0139] 3D画像レンダリングエンジン822は、ディスプレイ802および/または表示デバイス805上でユーザに表示するために、本発明の特徴に従って、レンダリング動作(例えば、復号された画像826、環境メッシュモデル838、UVマップ(複数可)840、マスク832、および補正メッシュ情報などの、受信されたおよび/またはメモリ812内に記憶されたコンテンツおよび情報を用いて)を実施し、3D画像を生成する。生成された立体視画像コンテンツ830は、3D画像生成エンジン822の出力である。様々な実施形態では、レンダリングエンジン822は、表示用の第1の画像を生成するために、第1の補正情報842と、第1の復号された画像と、環境メッシュモデル838とを用いて、第1のレンダリング動作を実施するように構成される。様々な実施形態では、レンダリングエンジン822は、表示用の第2の画像を生成するために、第2の補正情報844と、第2の復号された画像と、環境メッシュモデル838とを用いて、第2のレンダリング動作を実施するようにさらに構成される。いくつかのこのような実施形態では、レンダリングエンジン822は、第1および第2のレンダリング動作を実施するために、第1のUVマップ(受信されたUVマップ(複数可)840に含まれる)を使用するようにさらに構成される。第1の補正情報は、第1のカメラのレンズによって第1の画像に導入された歪みを補償するために第1のレンダリング動作が実施されたとき、第1のUVマップにおけるノード位置に対して行われる補正に関する情報を提供し、第2の補正情報は、第2のカメラのレンズによって第2の画像に導入された歪みを補償するために第2のレンダリング動作が実施されたとき、第1のUVマップにおけるノード位置に対して行われる補正に関する情報を提供する。いくつかの実施形態では、レンダリングエンジン822は、第1のレンダリング動作の部分として、第1の画像の部分を環境メッシュモデルの表面に適用するとき、第1のレンダリング動作の部分として、第1の画像の部分が、異なる視界に対応する第1の画像の部分とどのように組み合わされるかを決定するために、第1のマスク(マスク(複数可)832に含まれる)を使用するようにさらに構成される。いくつかの実施形態では、レンダリングエンジン822は、第2のレンダリング動作の部分として、第2の画像の部分を環境メッシュモデルの表面に適用するとき、第2のレンダリング動作の部分として、第2の画像の部分が、異なる視界に対応する第2の画像の部分とどのように組み合わされるかを決定するために、第1のマスクを使用するようにさらに構成される。生成された立体視画像コンテンツ830は、第1および第2のレンダリング動作の結果として生成された第1および第2の画像(例えば、左眼ビューおよび右眼ビューに対応する)を含む。いくつかの実施形態では、異なる視界に対応する第1の画像の部分は、空または地面の視界に対応する。いくつかの実施形態では、第1の画像は、前方視界に対応する左眼画像であり、異なる視界に対応する第1の画像は、前方視界に隣接する側方視界に対応する第3のカメラにより取り込まれた左眼画像である。いくつかの実施形態では、第2の画像は、前方視界に対応する右眼画像であり、異なる視界に対応する第2の画像は、前方視界に隣接する側方視界に対応する第4のカメラにより取り込まれた右眼画像である。したがって、レンダリングエンジン822は、3D画像コンテンツ830をディスプレイへとレンダリングする。いくつかの実施形態では、再生デバイス800の操作者は、入力デバイス804により1つまたは複数のパラメータを制御し、および/または、例えば、3Dシーンを表示するために選択するなど、実施されるべき動作を選択することができる。
[0140] ネットワークインターフェース810は、再生デバイスが、ストリーミングデバイス114からコンテンツを受信し、および/または、イベントにおける特定の見る位置の選択を示すビューヘッド位置および/または位置(カメラ装備)選択などの情報を伝達することを可能にする。いくつかの実施形態では、復号器820は、モジュールとして実装される。このような実施形態では、実行されたとき、復号器モジュール820は、受信された画像が復号されるようにするが、一方、3D画像レンダリングエンジン822は、本発明に従って画像のさらなる処理を行わせ、表示プロセスの部分として、任意選択で、画像を共に連結(stitch)させる。
[0141] いくつかの実施形態では、インターフェース810は、例えば、第3、第4、第5、および第6のメッシュ補正情報などの複数の異なるカメラに対応する追加のメッシュ補正情報を受信するようにさらに構成される。いくつかの実施形態では、レンダリングエンジン822は、第4のカメラに対応する画像をレンダリングするとき、第4のカメラに対応するメッシュ補正情報(例えば、第4のメッシュ補正情報848)を使用するようにさらに構成され、第4のカメラは、複数の異なるカメラのうちの1つである。決定モジュール823は、カメラで取り込まれた画像コンテンツのどれがレンダリング動作で使用されているかに基づいて、または、受信されたコンテンツストリームに対応する画像をレンダリングするときに、どのメッシュ補正情報が使用されるべきかを示すサーバからの標示に基づいて、レンダリング動作を実施するとき、レンダリングエンジン822によってどのメッシュ補正情報が使用されるべきかを決定するように構成される。いくつかの実施形態では、決定モジュール823は、レンダリングエンジン822の部分として実装され得る。
[0142] いくつかの実施形態では、図7のメモリ712および図8のメモリ812で示されたモジュールおよび/または要素は、ソフトウェアモジュールとして実装される。他の実施形態では、モジュールおよび/または要素は、メモリ内に含まれて示されているが、例えば、各要素が、その要素に対応する機能を実施するための回路として実装される個々の回路として、ハードウェアで実施される。さらに他の実施形態では、モジュールおよび/または要素は、ソフトウェアとハードウェアの組合せを用いて実施される。
[0143] 図7および図8でメモリに含まれるように示されるが、システム700および800に含まれて示される要素は、対応するデバイスの、例えば、個々の回路としてプロセッサ内にある、例えば、コンテンツ配信システムの場合にはプロセッサ708内にある、再生システム800の場合にはプロセッサ808内にあるハードウェアにおいて全体に実装されることができ、いくつかの実施形態ではそのように実装される。他の実施形態では、要素のいくつかは、対応するプロセッサ708および808内で、例えば、回路として実施されるが、他の要素は、例えば、プロセッサの外部の、プロセッサに接続された回路として実装される。理解されるように、プロセッサ上でのモジュールの集積レベル、および/または、プロセッサの外部にあるいくつかのモジュールを用いることは、設計選択の1つであり得る。代替的に、回路として実装されるのではなく、要素のすべて、もしくはいくつかのものは、ソフトウェアで実装され、メモリに記憶されることができ、ソフトウェアモジュールは、モジュールが、例えば、プロセッサ708および808などのそれらのそれぞれのプロセッサにより実行されるとき、モジュールに対応する機能を実装するために、システム700および800それぞれの動作を制御する。さらに他の実施形態では、様々な要素は、ハードウェアとソフトウェアの組合せとして実装され、例えば、プロセッサの外部の回路がプロセッサに入力を与え、それは、次いで、ソフトウェアの制御下で、モジュールの機能の一部を実施するように動作する。
[0144] 図7および図8の実施形態のそれぞれで、例えば、コンピュータなどの単一のプロセッサとして示されているが、プロセッサ708および808のそれぞれは、例えば、コンピュータなどの1つまたは複数のプロセッサとして実装され得ることを理解されたい。メモリ712および812内の1つまたは複数の要素が、ソフトウェアモジュールとして実装される場合、モジュールはコードを含み、コードは、対応するシステムのプロセッサ(例えば、プロセッサ708および808)により実行されたとき、プロセッサを、モジュールに対応する機能を実装するように構成する。図7および図8で示される様々なモジュールがメモリに記憶される実施形態では、メモリは、プロセッサなどの少なくとも1つのコンピュータに、モジュールが対応する機能を実装させるための、例えば、各モジュールのための個々のコードなどのコードを備えるコンピュータが読み取り可能な媒体を備えるコンピュータプログラム製品である。
[0145] 完全にハードウェアベースの、または、完全にソフトウェアベースのモジュールが使用され得る。しかし、例えば、回路で実装されるモジュールなど、ソフトウェアとハードウェアとの任意の組合せが、機能を実装するために使用され得ることを理解されたい。理解されるように、図7で示されたモジュールは、例えば、流れ図600、1100、および2300に図示されおよび/または記載されたものなどの本発明の方法の対応するステップの機能を実施するために、システム700、または、プロセッサ708などのその中の要素を制御しおよび/または構成する。同様に、図8で示されたモジュールは、例えば、流れ図1200、2400、および2500で図示されおよび/または記載されたものなどの本発明の方法の対応するステップの機能を実施するために、システム800、または、プロセッサ808などのその中の要素を制御しおよび/または構成する。
[0146] 図9は、流れ図の形で、カメラ較正、画像符号化、およびコンテンツストリーミング方法900の第1の部分を示している。例示的な方法は、図1で示されたシステム104により実装され得る、またいくつかの実施形態では実施される。図9で示される方法は、カメラ装備102の各カメラについて、画像処理較正および符号化デバイス112により実施される。
[0147] 方法は、例えば、イベントサイトなどで、カメラが最初にシステム104に接続されたとき、ステップ902で開始する。ステップ904で、カメラ較正動作が、カメラ較正サブルーチンの呼び出しにより開始される。カメラ較正サブルーチンは、装備102の各カメラについて呼び出され、立体視対の左カメラおよび右カメラが、個々に較正される。
[0148] ここで、図10を簡単に参照すると、ステップ904で呼び出され得る例示的な較正サブルーチン1000が図示されている。カメラ較正ルーチンは、それが呼び出されたとき、ステップ1002で開始する。動作は、開始ステップ1002からステップ1004へと進み、例えば、グリッド上の、または、その近傍にある1つまたは複数の既知の固定されたサイズのオブジェクトを用いて較正されるために、カメラからの固定された既知の距離に位置する較正グリッドなど、1つまたは複数の既知のオブジェクトの画像が撮られる。動作は、次いで、ステップ1008に進み、較正グリッドおよび/またはオブジェクトに対応する取り込まれた1つまたは複数の画像が、較正中であるカメラにより導入された歪みを検出するように処理される。次いで、ステップ1010で、較正測定および検出された画像歪みから、歪み補正メッシュが生成される。補正メッシュは、カメラおよびカメラの部分として含まれる魚眼レンズにより導入された1つまたは複数の歪みを逆転させる(reverse)、または低減するために、画像補正動作の部分として、取り込まれた画像に適用されることができる。メッシュは、取り込まれた画像の「平坦化(flattening)」と考えられ得るものが、画像取り込みプロセスの部分として導入された歪みおよび/または湾曲(curving)を逆転することを可能にする。較正中の個々のカメラについて歪み補正メッシュが作成されると、それは、将来使用するために、および/または、再生デバイスに送信するために記憶され、そして、再生デバイスは、以下で記載されるように、画像の部分を表示する前に、または、シミュレートされた環境に画像を適用する前に、取り込まれた画像に導入された歪みを補正するためにメッシュを使用することができる。
[0149] いくつかの実施形態では、補正メッシュは、補正メッシュにおける位置が、レギュラーメッシュにおけるノード位置とは異なっている各ノード点についてのオフセット情報を用いて、一様なレギュラーメッシュにおけるノードのノード位置を示すメッシュ情報の組として実装される。このような実施形態は、特に、環境の3Dメッシュモデルの対応する部分に画像をマップするためのUVマップがレギュラーな構造を有する場合に有用である。例えば、平坦な画像を球などの3DメッシュモデルにマップするためのUVマップとして使用され得るメッシュを示す図20を考えてみる。交差する線は、図20で示されるレギュラーメッシュにおけるノードを表す。図19で示された補正メッシュは、UVマップとして使用され得る図20で示されたレギュラーメッシュに対応するノードを含む。UVマップは、少なくともいくつかの実施形態において3Dモデルのノードに対応するノードを備えた2Dマップを指す。UVマップは、テクスチャと呼ばれることもある2D画像のどのセクションを、3Dモデルの対応するセクション上にラップする(wrap)のかを決定するために使用され得る。
[0150] 図19で示される補正メッシュは、1組のノードおよびオフセット情報について表現され得る。Uは通常X軸であるものに相当し、Vは通常Y軸であるものに相当する、情報の補正メッシュの組におけるノードについて含まれるUおよびV座標は、指示されたUおよびV座標で生じる図20のレギュラーメッシュにおける対応するノードを特定するためのノード識別子として働く。したがって、図20で示されるレギュラーメッシュにおけるノードのU座標およびV座標は、補正メッシュにおける対応するノードを特定するために使用され得、補正メッシュ情報の組に含まれるオフセット情報は、図20で示された対応するノードのU座標およびV座標が、図19におけるノードの位置になるためにはどのくらい変更されるべきかを示す。ノードについてのオフセット情報は、図20で示されたレギュラーUVマップの対応するノードの位置にそれを置くためには、ノード位置がどのくらい補正され、または調整されなければならないかを示すので、「補正情報(correction information)」と考えられ得る。
[0151] 図19は単一の補正メッシュを示すが、補正メッシュはカメラに依存しており、したがって、画像を取り込む各々のカメラについてメッシュ補正情報の別々の組が与えられ、別々の補正メッシュは、立体視カメラ対の左カメラおよび右カメラのそれぞれについて生成されることを理解されたい。図20で示されるレギュラーUVマップはカメラレンズの歪みに依存しないので、同じUVマップが、立体視画像対の左眼画像と右眼画像の両方のために使用され得、またいくつかの実施形態ではそのように使用される。
[0152] 画像を取り込んだ特定のカメラレンズにより導入された歪みを除去するために、左眼もしくは右眼カメラに対応する復号された歪んだ画像が補正されると、それは、図21で表されたレンダリングステップの部分として、左眼画像および右眼画像ビューについて同じであり得る、またはいくつかの実施形態では同じであるレギュラーUVマップを用いて、環境の3Dモデルに適用され得る。
[0153] しかし、いくつかの実施形態では、1つまたは複数の歪み補正された画像の生成は省略され、レンダリング画像は、復号された歪んだカメラビューから3Dメッシュモデルに直接マップするために、補正メッシュ情報の組に含まれたオフセット情報と共に、レギュラーUVマップにおけるノードの位置に関する情報を用いることを理解されたい。したがって、歪み補正された画像の生成は、本発明の理解を容易にするために示されているが、本発明に対して何ら重要ではなく、歪み補正および3Dモジュールへのマッピングが1つの処理動作で行われて、省略されることができる。
[0154] 図10を再度参照して、較正情報に基づいてカメラのためにステップ1004で補正メッシュが生成され、動作は、戻りステップであるステップ1012へと進む。
[0155] 理解されるように、図10で示される較正プロセスは、立体視コンテンツのストリーミングをサポートするために使用され得るカメラ装備102および/または他のカメラ装備の各カメラのために実施されることになり、補正メッシュが、各カメラについて生成され、記憶される。例えば、競技場において、複数のカメラ装備が、様々な場所に配置され得る。再生デバイスに画像を供給するために使用されるカメラ装備は、例えば、どのカメラ位置が、所与の時間に、例えば、主なアクションの最良のビューを提供するかについての編集者の決定に基づいて、サーバ側で切り換えることができる、または、イベントにおける現在のカメラ装備のビューから、異なるカメラ装備の眺望からのアクションを見ることに切り換える要求を伝える再生デバイスのユーザにより切り換えることができる。いずれの場合においても、コンテンツサーバが、コンテンツを再生デバイスに供給するために使用されているカメラ装備および/またはカメラ対を切り換えたとき、コンテンツサーバは、再生デバイスが、コンテンツを供給していたカメラ対に対応する補正情報の組を使用することから、切換えが行われた新しいカメラ位置からコンテンツを供給することになる新しいカメラ対に対応するメッシュ補正情報を用いることへと切り換えるべきであることを、再生デバイスに信号伝達し得る、および、しばしば信号伝達する。
[0156] 補正メッシュは、UVマップにおけるすべてのノードに対する情報を含むことができるが、いくつかの場合には、レンズ歪みは、UVマップにおける1つまたは複数のノードに関して補正を必要としない可能性がある。このような場合、再生デバイスに送信された補正メッシュ情報の組は、補正メッシュ情報が対応するカメラにより取り込まれた画像の3Dモデルの部分に対応するUVマップと同じ位置において歪み補正メッシュで生じるノードについての情報を除外することができる。
[0157] 較正サブルーチン1000への呼び出しの後、ステップ906で、特定の補正メッシュ情報が対応するカメラによって取り込まれる画像コンテンツとともに、または、先だって再生デバイスに供給されるために、プロセスにより作成された、例えば、ノード位置およびオフセット値の形態の補正メッシュ情報の組などの補正メッシュは、メモリに記憶され、ストリーミングデバイス114に利用可能になる。
[0158] 動作は、ステップ906から、任意選択のステップであるステップ906へと進む。ステップ908で、3D環境マップは、カメラ装備の場所からの環境の距離測定を行うことにより生成される。このような距離測定は、例えば、LIDAR、および/または、他の距離測定技法を用いて行われ得る。
[0159] 環境測定は、イベントに先行することができ、将来の使用および/または配布のためにメモリに記憶され得る。例えば、アリーナが1回測定され、次いで、同じ開催地、すなわち、アリーナについて、多くの異なるイベントで取り込まれるコンテンツをストリーミングまたは供給するとき、その測定が使用される。
[0160] このような測定がない場合、環境は、デフォルトサイズの球であると再生デバイスにより推定され得る、および、いくつかの実施形態において推定される。環境測定は、カメラ装備、したがって装備102に設けられたカメラから、環境をシミュレートするために使用されるグリッドメッシュの点に対応する環境における様々な点までの距離に関する情報を提供する。距離測定に基づいて、シミュレートされたメッシュ環境におけるグリッド点は、見る人の場所としての役割を持つ中心点から、遠くに外れるように、または、より近づくように移動され得る。したがって、三角形を用いてモデル化される環境を反映するために使用されるメッシュグリッドやデフォルト形状としての球状は、シミュレートされている環境の実際の測定された形状を反映させるために、伸長される、または、その他の形で変更され得る。
[0161] ステップ908が実施されたときに実施されるステップ910では、ステップ908で測定された環境を表す情報が記憶される。記憶された環境測定情報は、再生デバイスにストリーミングされる、または、その他伝達されるべき画像を取り込むために使用されるカメラ装備102を取り囲む環境形状をシミュレートするために使用されるメッシュにおける諸地点までの距離を調整するために使用され得る、カメラ装備102から壁もしくは他の周囲のオブジェクトまでの距離を含む。
[0162] 構成された装備102のカメラと収集された環境情報を用いて、それが使用される場合、動作は、ステップ912に進むことを介して、例えば、図11で示されたルーチン1100などの画像取り込みおよびコンテンツストリーミングサブルーチンへと進む。画像取り込みは、取り込まれているイベントの継続期間中続き、いくつかの実施形態では、実時間ストリーミングがイベントの間サポートされ、非実時間のコンテンツ配信およびストリーミングが、イベントの完了後にサポートされる。
[0163] 画像取り込みおよびコンテンツストリーミングサブルーチンを示す図11は、図9で示された流れ図により呼び出され得るが、ここで詳細に述べられる。図11で示された方法1100は、例えば、スポーツイベントまたは音楽演奏などのイベントに対応する画像などの画像を取り込むときであるカメラ較正後に、ルーチンが呼び出されるステップ1102で開始する。
[0164] 開始ステップ1102から、動作は、複数の経路に沿って進み、経路は、ステップ1114、1104、1106、1108、1110、1112を伴い、それは、並列に、および、任意選択で非同期に実施され得る。
[0165] 画像取り込みプロセスの理解を容易にするために、ここで、図13で示された例示的なカメラ装備への参照がなされる。カメラ装備1300は、図1のシステムの装備102として使用され得、それぞれが3つのセクタのうちの異なる1つに対応する複数の立体視カメラ対を含む。第1の立体視カメラ対1301は、第1のカメラ対の場所に位置する人の左眼および右眼で見られるものに相当する画像を取り込むように意図された左眼カメラ1302(例えば、第1のカメラ)と、右カメラ1304(例えば、第2のカメラ)とを含む。第2の立体視カメラ対1305は、第2のセクタに対応し、左および右カメラ1306、1308を含み、一方、第3の立体視カメラ対1309は、第3のセクタに対応し、左および右カメラ1310、1312を含む。各カメラは、支持構造1318において固定位置に設けられる。上方を向いているカメラ1314もまた含まれる。図13では見ることのできない下方を向いているカメラが、カメラ1314の下に含まれ得る。いくつかの実施形態では、立体視カメラ対が、上方および下方画像の対を取り込むために使用されるが、他の実施形態では、単一の上方カメラおよび単一の下方カメラが使用される。さらに他の実施形態では、下方画像は、装備の設置以前に取り込まれ、イベントの継続期間の間、静止した地面画像として使用される。このような手法は、地面ビューがイベント中に有意には変化することがないと考えると、多くの用途で満足すべきものになる傾向がある。
[0166] 装備1300のカメラの出力が、図11の方法により取り込まれ、処理されるが、ここでさらに論じる。図11で示される画像取り込みステップは、通常、画像を取り込むためにカメラ装備102のカメラを動作させることにより実施されるが、画像の符号化は、ストリーミング要求に応じてエンコーダ112により実施され、コンテンツのストリーミングはストリーミングサーバ114により実施される。
[0167] 下方画像取り込みおよび処理に関する図11の第1の経路では、ステップ1114で、例えば、装備102の下など、地面の画像が取り込まれる。これは、装備が下方に向いているカメラを含む場合、装置の設置以前に、または、イベント中に行うことができる。ステップ1114から、動作はステップ1144へと進み、ステップ1145で符号化する前に、取り込まれた画像は縁が切り落とされる。符号化された地面画像は、次いで、コンテンツを求める要求を待って記憶され、その要求には、ステップ1146で、1つまたは複数の符号化された画像を、要求しているデバイスに供給することによって応答され得る。
[0168] ステップ1104で開始する、図11で示される第2の処理経路は、コンテンツを求める要求を処理し、それに応答することに関する。ステップ1104で、例えば、コンテンツサーバ114により、コンテンツを求める要求のための監視が行われる。ステップ1128で、例えば、顧客建物内106に設けられたデバイス122などの再生デバイスから、コンテンツを求める要求が受信される。
[0169] コンテンツ要求に応じて、再生デバイスは、ステップ1130で、ストリーミングされる画像における補正歪みである情報、および/または、他のレンダリングに関連する情報が提供される。ステップ1130で送信された歪み補正情報は、例えば、再生デバイスへと、コンテンツストリームにおいて画像を供給できるカメラごとに1つなど、1つまたは複数の歪み補正メッシュの形態であることができる。いくつかの実施形態では、画像を供給する装備102の各カメラについて提供されるカスタムの歪み補正メッシュ情報を伴って、歪み補正メッシュ情報が、再生デバイスに送信され得、また、いくつかの実施形態では、送信される。したがって、3セクタのカメラ対と、上方のカメラ対と、下方を向いているカメラ対とを有する装備の場合、合計10の歪み補正メッシュが、例えば、カメラごとに1つのメッシュなど、装備のカメラによって取り込まれた画像に対して使用するために、再生デバイスに伝達される。ノード位置が特定され、歪み補正情報の組においてオフセット情報がノードごとに提供されて、歪み補正情報は、上記で論じたように、カメラにより取り込まれた領域に対応するUVマップに対応する情報を含むことができる。対応するUVマップにおけるノード位置に一致する歪み補正メッシュにおけるノードについて、ノードは歪み補正メッシュにおいて、UVマップと同じ位置に生じるので、指定されるべきオフセットが何もないとき、情報は除外され得る。
[0170] 図18は、魚眼レンズを有する対応するカメラにより導入された歪みを補償するために使用され得る例示な補正メッシュ1800を示す。歪み補正メッシュは、カメラに依存しており、通常、イベントの持続期間中は変化することはないので、歪み補正メッシュは繰り返して送られる必要はないが、イベントに関連付けられたコンテンツストリーミングの開始前に、または開始時に、再生デバイスにより、バッファされる、および/または、その他の形で記憶され得る。しかし、画像を供給するために使用されるカメラ装備が、例えば、別のカメラ場所が、主要なアクションのより良好なビューを提供するという理由など、イベント中に変わり得る場合、複数の異なるカメラ装備のカメラについての歪み補正情報は、再生デバイスへと送信されることができ、再生デバイスは、復号されて、所与の時間に3Dモデルにその画像がマッピングされるカメラに対応する歪み補正情報を使用することに留意されたい。再生デバイスは、再生デバイスにより受信された特定の送信された画像について、所与の時間に、どの歪み補正マップを使用すべきかを信号で知らされ得る、および/または、再生デバイスは、ユーザの見ている方向に基づいて、どの歪み補正情報の組を使用すべきか、および、ユーザにより選択されたカメラ位置から知られ得る、所与の時間にどのカメラ装備がコンテンツを提供しているかを決定することができる。例えば、ユーザは、中心フィールド位置からイベントを見るように選択することができ、その場合、中心フィールドにあるカメラ装備が、レンダリングに使用される画像を供給することになる。
[0171] ステップ1130から、動作はステップ1132へと進み、ステップ1132は、環境マップが生成された場合、および/または、所定のデフォルト設定とは異なる可能性のある他の環境情報が、再生中に、測定された3D環境をシミュレートするために使用されるように再生デバイスに供給される場合に実施される。
[0172] したがって、ステップ1128および1130により、コンテンツを要求する再生デバイスは、3D環境をシミュレートするのに必要な情報、および/または、マスク情報、および/または、どのカメラフィードおよび/または画像ストリームがシミュレートされる3D環境のどの部分に対応するかを示す情報などの、3D環境をレンダリングし、シミュレートするのに必要になり得る他の情報を提供される。
[0173] 補正メッシュに加えてステップ1128で伝達され得るマスクおよび/または画像組合せ情報は、図14で示される画像部分の組合せを可能にする情報を含む。マスク情報は、アルファ値の組の形態とすることができ、アルファ値は、いくつかの実施形態では、マスクが適用される画像の部分が、3Dモデルへと表示される画像に寄与するか否かを制御するために、各画像セグメントのために提供される。
[0174] 図13のカメラ装備が使用される場合、セクタのそれぞれは、カメラ装備位置に対して知られた120度ビューイング領域に対応しており、異なるセクタの対からの取り込まれた画像は、シミュレートされた3D環境への画像の知られたマッピングに基づいて、共に継ぎ合わされる。セクタのカメラにより取り込まれた各画像の120度部分が通常使用されるが、カメラは、約180度のビューイング領域に対応する、より広い画像を取り込む。したがって、取り込まれた画像は、3D環境シミュレーションの部分として、再生デバイスにおけるマスキングの対象となり得る。図14は、装備102のる装備もカメラ対に対応する環境メッシュ部分を用いて、どのようにして3D球形環境がシミュレートされ得るかを示す複合図1400である。1つのメッシュ部分が、装備102のセクタのそれぞれについて示されており、空メッシュは、方カメラビューに関して使用され、また、地面メッシュは、下方を向いているカメラにより取り込まれた地面画像のために使用されることを注記する。頂部および底部画像についてのマスクが本来は丸いが、シーン領域の頂部および底部が頂部および底部カメラそれぞれによって供給されるということを考えて、セクタ画像に適用されるマスクは切り取られる。
[0175] 組み合わされたとき、異なるカメラに対応するメッシュ全体は、図15で示されるように球形メッシュになる。メッシュは、単一の眼画像用に示されるが、それは、立体視画像対が取り込まれた場合、左眼画像と右眼画像の両方のために使用されることに留意されたい。
[0176] 図14で示されるタイプのメッシュおよびマスキング情報は、ステップ1130で、再生デバイスに伝達され得るが、時にはそのように伝達される。伝達される情報は、装備の構成に応じて変化することになる。例えば、多数のセクタが使用されるとすれば、各セクタに対応するマスクは、120度よりも小さなビューイング領域に対応するはずであり、3を超える環境グリッドが、球の直径をカバーするために必要である。
[0177] ステップ1132で再生デバイスに任意選択で送信された環境マップ情報が示される。環境マップ情報は任意選択のものであり、このような情報が伝達されない場合には、環境は、デフォルトサイズの球であると想定され得る。複数の異なるデフォルトサイズの球がサポートされる場合、どのサイズの球が使用されるべきかに関する指示子が、ステップ1132で、再生デバイスに伝達され得、時にはそのように伝達される。
[0178] 動作は、ステップ1132からストリーミングステップ1146へと進む。
[0179] 画像取り込み動作は、特に、カメラ装備102により取り込まれ得る3セクタのそれぞれに関するイベント中は継続中に実施され得る。したがって、カメラ装備の第1、第2、および第3のセクタに対応するステップ1106、1108、および1110で開始する処理経路は、それらの内容の点で類似する。
[0180] ステップ1106で、例えば、ステップ1116での左眼画像、および、ステップ1118での右眼画像などの画像を取り込むために、カメラの第1のセクタ対が動作される。図16は、ステップ1106で取り込まれ得る例示的な画像対を示す。次いで、ステップ1134で、取り込まれた画像は縁が切り落とされ、ステップ1146においてストリーミングのために利用可能になる前に、ステップ1136で符号化される。図17は、ステップ1134で行われることのできるような、図16の画像の縁を切り落とした例示的な結果を示す。
[0181] 画像取り込み、縁の切り落とし、および符号化は、ステップ1136からステップ1106に戻る矢印で示されるように、望ましいフレームレートで、継続中に繰り返される。
[0182] ステップ1108で、例えば、ステップ1120における左眼画像、および、ステップ1122における右眼画像などの画像を取り込むために、カメラの第2のセクタ対が動作される。取り込まれた画像は、次いで、ステップ1138で縁が切り落とされ、ステップ1146においてストリーミングに利用可能になる前に、ステップ1139で符号化される。ステップ1139からステップ1108に戻る矢印により示されるように、画像取り込みは、望ましいフレームレートで、継続中に繰り返される。
[0183] ステップ1110で、例えば、ステップ1124における左眼画像、および、ステップ1126における右眼画像などの画像を取り込むために、カメラの第3のセクタ対が動作される。取り込まれた画像は、次いで、ステップ1140で縁を切り落とされ、ステップ1146においてストリーミングに利用可能になる前に、ステップ1141で符号化される。ステップ1141からステップ1110に戻る矢印により示されるように、画像取り込みは、望ましいフレームレートで、継続中に繰り返される。
[0184] ステップ1112で、カメラ装備102の頂部カメラにより、空画像が取り込まれる。次いで、ステップ1142で、画像は、縁が切り取られ、ステップ1146においてストリーミングに利用可能になる前に、1143で符号化される。地面および空の画像の取り込みは、セクタ画像取り込みと同様に、望ましい場合は継続中に実施されることができ、また、例えば、取り込まれている左眼画像および右眼画像と共になど、立体視的に取り込まれ得る。図11では、空および地面ビューの例示的な立体視画像取り込みがデータ低減のため回避されるが、それは、これらの画像が、カメラ装備の正面120セクタに対応し得る前方の正面ビューよりも多くの場合に重要性が低い傾向があるためである。しかし、いくつかの実施形態では、立体視の空および地面ビューが取り込まれて、実時間で更新される。
[0185] 異なるセクタに対応する複数のカメラビューが取り込まれるが、画像の取り込みレートは、すべてのセクタに対して同じである必要のないことに留意されたい。例えば、主に演じられている(プレイがされている)フィールドなどに対応する正面を向いているセクタは、他のセクタ、および/または、頂部(空)および底部(地面)ビューに対応するカメラよりも高速のフレームレートで画像を取り込むことができる。
[0186] ステップ1146で、コンテンツを要求している再生デバイスには、1つまたは複数の取り込まれた画像を供給され、再生デバイスは、次いで、取り込まれた画像を処理し、3D環境をシミュレートするために使用することができる。
[0187] コンテンツを求める要求に応じてコンテンツが供給されるいくつかの実施形態では、ステップ1146は、例えば、再生デバイスがコンテンツストリームを求める要求を送信するのに応じて、要求しているデバイスごとに実施される。その結果、異なるデバイスは、見る人の頭部位置、または、イベントにおける選択された見る位置に応じて、異なるカメラセクタに、または、異なるカメラ装備にさえも対応する異なるコンテンツを供給され得る。このような、見ている位置の情報は、ステップ1148で監視され、頭部位置に変化があった場合、または、例えば、ミッドフィールドまたはエンドゾーンなどの見る位置などのユーザにより選択される見る位置の変化があった場合、定期的に再生デバイスから受信され得る。他の実施形態では、コンテンツは、ブロードキャストまたはマルチキャストであり、デバイスは、例えば、ユーザの現在の頭部位置により、または、現在ユーザによって選択されているカメラ位置を、単独で、もしくは、頭部位置情報と組み合わせることにより、所与の時間点でアクセスすることを望むコンテンツを含むコンテンツストリームに接続される。したがって、頭部位置および/またはユーザにより選択されたカメラ位置に関する情報がコンテンツサーバに伝達される場合、コンテンツサーバは、個々のユーザの再生デバイスからの情報に基づいて、画像コンテンツをストリーミングすることができる。ブロードキャストにおいて、サーバは、異なるカメラ対および/またはカメラ装備に対応するコンテンツをストリーミングすることができ、また再生デバイスは、どのブロードキャストまたはマルチキャストコンテンツストリームを、任意の所与に時間に、受信し、処理するかを選択することができる。メッシュ補正情報は、コンテンツストリームにおいて送信される画像を供給するカメラのためのコンテンツストリームにおいて、または、再生デバイスで利用可能な1つまたは複数のコンテンツストリームにおいて受信され得る画像のレンダリングに関連する情報を受信するために再生デバイスによって使用され得る制御または他のチャネル上での帯域外に含まれ得る。
[0188] ステップ1150で、要求しているデバイスが、見る位置をサーバに提供する実施形態では、見る人の頭部位置情報に応じて画像ストリーミングが制御される。例えば、ユーザが、環境のビューイングセクタ1からビューイングセクタ2へと変更した場合、ステップ1150で行われた変更の結果として、ステップ1146は、セクタ1に代えてセクタ2に対応するコンテンツをユーザにストリーミングするよう変更され得る。すべてのセクタに対応する画像がユーザにストリーミングされてもよいが、帯域幅利用の観点から、ストリームの数を、示された視野角をサポートするのに必要なものに限定することは、帯域幅管理および利用の観点から望ましいことに留意されたい。複数のコンテンツストリームがブロードキャストまたはマルチキャストされ、再生デバイスが、例えば、受信するために、どのストリームに接続するのかを選択する場合、ステップ1150は、実施される必要はない。
[0189] 理解されるように、例えば、ライブイベントに関連する主なアクションの点が、1つのカメラ装備に対応する視界から、他のカメラ装備の視界へと移動したときなど、特定の時間点でコンテンツを供給するために使用されるカメラ装備は切り換えられ得る。例えば、フットボールアクションが、スタジアムの一方のエンドから、他方のエンドへと移動したとき、放送者は、最良のビューが競技全体を通して放送されるように、異なるカメラ装備からコンテンツを供給するように選択することができる。このような場合、放送者は、どのカメラ装備が、送信されているコンテンツストリームでコンテンツを提供するかに関する切換えを制御することができる。コンテンツストリームでコンテンツを供給するために使用されるカメラにおいて切換えが行われるとき、所与の時間に画像を供給するカメラに対応する補正メッシュ情報を使用するように、コンテンツストリームを受信する再生デバイスに変更を信号で知らせることは有用である。ステップ1151で、使用される補正メッシュが、ストリーミングされている画像を提供するソースカメラに適合するように、再生デバイスが、どの補正メッシュが使用されるべきかを切り換えるべきであることを示す信号が、再生デバイスに送られる。例えば、再生デバイスは、サーバが、第1のカメラ対に対応する画像をストリーミングすることから、第2のカメラ対に対応する画像を再生デバイスにストリーミングすることに切り換えたとき、第1のカメラ対に対応する補正メッシュを使用することから、第2のカメラ対に対応する補正メッシュを使用することに切り換えるように信号で知らせる。
[0190] 再生デバイスからのフィードバック情報の受信をすると、そのような情報がサーバに提供される実施形態では、画像のストリーミングが、イベントに持続期間の間継続される、または、ユニキャストのコンテンツ配信の場合、再生デバイスとのセッションが終了するまで継続する。
[0191] コンテンツを配信し、どの補正メッシュを使用すべきかに関する情報を提供する継続中のプロセスは、コンテンツストリーミングが継続して続けられることを示すステップ1151からステップ1146に戻る矢印によって表されるが、ステップ1146からステップ1151までは、画像が取り込まれ、ストリーミングされると反復して実施され、画像取り込み、符号化、およびストリーミングステップが、継続して繰り返される。
[0192] いくつかの実施形態では、システム104により実施される画像取り込み、符号化および送信プロセスについて説明してきたが、例えば、図8で示されるデバイス122またはデバイス800など、例示的な再生デバイスの動作が、ここで、図12を参照して述べられる。
[0193] 図12は、例示的な一実施形態に従って図1のシステムで使用され得る、再生デバイスまたはシステムを動作させる方法1200を示している。方法1200は、開始ステップ1202で開始する。ステップ1204で、再生デバイスは、コンテンツを求める要求を、例えば、図1のストリーミングサーバに送信する。再生デバイスは、次いで、ステップ1206で、図11のステップ1128、1130、および1132で送信され得る、また時には送信される情報を含む様々な情報を受信する。例えば、ステップ1126で、再生デバイスは、そこから画像部分が受信され得る各カメラのそれぞれについての補正メッシュを指定する情報を受信することができ、また時には受信し、さらに、カメラ出力に関して使用されるべき画像マスク情報が、例えば、環境マップなどのシミュレートされる環境に関する情報および/またはシミュレートされた3D環境を生成するために使用すべき、もしくは使用され得る異なるカメラ出力に対応する環境メッシュ部分についての情報などの他の情報と共に受信され得る。したがって、ステップ1206で、再生デバイスは、図18で示された例示的な補正メッシュなどの、各カメラについての補正メッシュと共に、図14で示されたメッシュおよびマスク情報を受信することができる。
[0194] ステップ1206で受信された情報は、必要に応じて、使用するためにメモリに記憶され得る。
[0195] 動作は、ステップ1206からステップ1208へと進み、例えば、再生デバイスに取り付けられたヘッドマウントディスプレイから、見る人の頭部位置が受信されるか、または、頭部位置は、再生デバイスにより視覚的に、または、その他の形で頭部位置を追跡することにより決定される。ステップ1209で、見る人の頭部位置が与えられるとするとストリーミングされるべき適切なカメラ画像を選択するために使用され得る情報をコンテンツサーバに提供するために、見る人の頭部位置がコンテンツサーバに送信される。
[0196] ステップ1210で、見る人に選択された頭部位置が、例えば、ユーザ制御入力を介して、再生デバイスにより受信される。この入力は、例えば、カメラ装備が設けられた、例えば、ミッドフィールドの見る位置や1つまたは複数のエンドフィールドもしくはゴールの見る位置などの複数の異なるイベントの見る人の位置の間で、ユーザが選択可能とされる実施形態で受信され得る。
[0197] ステップ1211で、見る人に選択された位置が、サーバに伝達される。ステップ1208およびステップ1209は、定期的に、または、報告すべき見る人の頭部位置における変化があるときは常に繰り返される。ステップ1210およびステップ1211は、定期的に行われ得るが、例えば、スポーツイベントまたはコンサートにおける異なる座席に対応するなど、ユーザが異なる位置に切り換えることを望む決定を行ったとき、通常、ユーザの制御下で実施される。
[0198] ステップ1209およびステップ1211は、帯域幅を浪費せず、すべてのカメラ出力を再生デバイスに送信しなければならないことを回避するために、再生デバイスに供給するカメラ出力ストリームのサブセットを選択するためにサーバにより使用され得る情報を、サーバに提供することを理解されたい。
[0199] 継続中に実施されるステップ1213で、例えば、図17で示されるものなどのセクタの左眼画像および右眼画像の例示的な復号された画像を生成するために、装備102の1つまたは複数のカメラに対応する符号化された画像が受信され、復号される。
[0200] 動作は、ステップ1214からステップ1215に進み、復号された画像に対応するマスクが、復号された画像に適用される。適用され得るマスクは、図14で示されており、マスクは、マスキングを受ける対象である画像が対応する3D環境の一部に応じて適用される。ステップ1215におけるマスキングの後、復号された画像に対応する補正メッシュが、補正された画像を作成するために適用される。図19は、処理されている画像を取り込んだカメラにより導入された歪みを反転または補償するために使用される変形動作の部分として、図18で示された補正メッシュの画像への例示的な適用を示す。
[0201] 図20は、図19で示された画像に補正メッシュを適用した結果を示す。理解されるように、補正メッシュは、立体視画像対の左眼画像と右眼画像の両方に適用されることになる。したがって、図20では、例えば、画像を取り込むために使用された左眼カメラおよび右眼カメラのそれぞれに対応する補正メッシュを使用することにより、対の両方の画像が、補正されていることが示されている。
[0202] 復号された画像の補正の後、いくつかの実施形態では、補正された画像の関連する部分は、360度のシミュレートされた環境の対応するビューイング領域部分にマップされる。マッピングは、3Dビューイング体験を提供するために表示され得る別々の右眼画像と左眼画像とを生成するために、左眼画像および右眼画像について実施される。補正画像のシミュレートされた環境グリッドへの適用の前に画像が取り込まれる環境をより正確に反映するように、マッピングは、任意選択で、デフォルトの環境グリッドを歪ませるために環境マップ情報を使用することができる。左眼画像および右眼画像について実施されるステップ1214、1215、および1216が別々のステップとして記載されるが、それらは、単一のレンダリング動作へと組み合わせることができ、その場合、レンダリングエンジンは、マスク情報と、特定の眼の画像に対応するメッシュ補正情報と、使用されている3Dメッシュモジュールに画像をマップするために使用される未補正のUVマップにおけるノードの位置を示すUVマップ情報とを使用することを理解されたい。このように、利用可能な複数の入力を用いることにより、レンダリングエンジンは、復号された左眼画像および右眼画像の別個の補正されたバージョンを生成することを必要とせず、復号された左眼画像および右眼画像データを、3Dメッシュモジュールの対応する部分へと直接マップすることができる。これは、望ましい場合、画像の部分が、連続して処理され、レンダリングされることを可能にする。この手法は、左眼画像のどの部分が3Dモデルにマップされるべきかを決定するためにマスクを使用し、および、出力される左眼画像を生成するために、左眼画像を供給したカメラに対応するメッシュ補正情報と、復号された左眼画像が、どのように環境の3Dメッシュモデルにマップされるべきかを決定するためのUVマップとの組合せを使用して、復号された左眼画像から表示するための左眼画像を生成するレンダリングエンジンを用いたいくつかの実施形態で使用される。同じレンダリング手法が、右眼画像のどの部分が3Dモデルにマップされるべきかを決定するためにマスクを使用し、右眼画像のためのカメラに依存するメッシュ補正情報と、表示のための右眼出力画像を生成するために、復号された右眼画像が、どのように環境の3Dメッシュモデルにマップされるべきかを決定するためのUVマップとの組合せを使用して、復号された右眼画像から表示するために右眼画像をレンダリングするこのような実施形態で使用される。メッシュ補正情報はカメラに依存するので、左眼画像および右眼画像をレンダリングするために、異なるメッシュ補正情報が使用される。しかし、レンダリングに使用されるUVマップおよび3Dモデルは、レンダリングされる画像をどのカメラが取り込んだかに依存しないので、同じUVマップおよび3Dモデルが、左眼画像と右眼画像の両方をレンダリングするために使用ことができ、またいくつかの実施形態では使用する。
[0203] ステップ1120で、いくつかの実施形態では、3Dビューイング体験を有する画像のビューが得られる奥行き情報を提供する左眼画像と右眼画像の差をもった、別々の左眼画像および右眼画像が出力されることを理解されたい。レンズに依存する歪みに対する補正を、コンテンツをストリーミングするサーバではなく、再生デバイスで実施することにより、画像を取り込むのに使用された個々のレンズにより導入された歪みを除去する試みにおいて、符号化に先立ち画像が前処理される実装形態と比較して、エッジ部が良好に保存され、符号化アーティファクトが回避される。
[0204] 図21は、第1のセクタに対応する画像部分の、3Dビューイング環境を表す球の対応する120度部分へのマッピングを示している。
[0205] ステップ1216で、360度環境の異なる部分に対応する画像が、例えば、頭部位置に応じて、連続するビューイング領域を見る人に提供するために必要とされる範囲を組み合わされる。例えば、ステップ1218で、見る人が、2つの120度セクタの交差部分を見ている場合、各セクタに対応する画像部分が見られ、シミュレートされている3D環境全体における各画像の知られた角度および位置に基づいて、見る人に一緒に提示される。画像の外観および生成は、立体視実装形態の場合に、眼ごとに1つの2つの別々の画像が生成されるように、左眼および右眼ビューのそれぞれについて実施される。
[0206] 図22は、360度ビューイング環境を作成するために、複数の、復号され、補正され、および、縁が切り落とされた画像が、どのように共にマップされ、見えることができ、また時には見えるかを示す。
[0207] ステップ1220で、マップされた画像は、ユーザにより見るために、表示デバイスへと出力される。理解されるように、表示される画像は、受信された画像に基づいて、および/または、頭部位置またはユーザに選択された見る人の位置の変化のため、時間が経過すると変化することになり、立体視画像の場合、別々の左眼画像および右眼画像が、ユーザの左眼および右眼のそれぞれに対して別個の表示のために生成される。
[0208] 図23は、例示的な実施形態に従って、画像コンテンツを提供する例示的な方法のステップを示す流れ図2300である。流れ図2300の方法は、カメラ装備102/1300により取り込まれた画像コンテンツを受信できるコンテンツ配信システム104/700により実装される。
[0209] 方法はステップ2302で開始し、例えば、配信システムに電源が投入され、初期化される。方法は、ステップ2302から2304に進む。ステップ2304で、コンテンツ配信システム700は、メモリに、画像コンテンツを取り込むために使用された1つまたは複数の立体視カメラ対、例えば、画像取り込み装置102/1300で使用されるカメラ対、についてのメッシュ補正情報を記憶する。いくつかの実施形態では、メッシュ補正情報を記憶するステップ2304は、ステップ2306、2308、2310、2312、2314、および、2316のうちの1つまたは複数のものを含む。ステップ2306では、第1の立体視カメラ対の第1のカメラのための第1の補正情報が記憶される。ステップ2308で、第1の立体視カメラ対の第2のカメラのための第2の補正メッシュ情報が記憶される。いくつかの実施形態では、第1の立体視カメラ対は、画像取り込み装置102/1300の部分であり、第1の方向に対応する。ステップ2310で、第2の立体視カメラ対の第1のカメラのための第3のメッシュ補正情報が記憶される。ステップ2312で、第2の立体視カメラ対の第2のカメラのための第4の補正メッシュ情報が記憶される。ステップ2314で、第3の立体視カメラ対の第1のカメラのための第5のメッシュ補正情報が記憶される。ステップ2316で、第3の立体視カメラの第2のカメラための第5の補正メッシュ情報が記憶される。
[0210] 動作は、ステップ2304からステップ2318へと進む。ステップ2318で、サーバ(例えば、システム700でストリーミングコントローラ720として実装され得るストリーミングサーバ114)は、画像コンテンツをレンダリングするのに使用される環境メッシュモデルを、例えば、1つまたは複数のコンテンツレンダリングおよび再生デバイスに送信するように動作される。動作は、ステップ2318からステップ2320に進む。ステップ2320で、サーバは、画像レンダリング動作の部分として、1つまたは複数の立体視カメラ対により取り込まれた画像部分を環境メッシュモデルの部分にマップするために使用される1つまたは複数のUVマップを、再生デバイスに送信するように動作される。いくつかの実施形態では、サーバは、画像レンダリング動作の部分として、第1の立体視カメラ対により取り込まれた画像の部分を環境メッシュモデルの一部にマップするために使用される第1のUVマップを送信するように動作される。
[0211] 動作は、ステップ2320からステップ2322へと進む。ステップ2322で、第1の立体視カメラ対の第1および第2のカメラにより取り込まれた画像コンテンツから生成され、符号化された画像を含む立体視コンテンツストリームが、再生デバイスに送信される。動作は、ステップ2322からステップ2324へと進む。ステップ2324で、コンテンツ配信システムは、第1の補正メッシュ情報と第2の補正メッシュ情報とを再生デバイスに提供し、第1の補正メッシュ情報は、第1のカメラにより取り込まれた画像コンテンツをレンダリングすることに使用するためのものであり、第2の補正メッシュ情報は、第2のカメラにより取り込まれた画像コンテンツをレンダリングすることに使用するためのものである。
[0212] 動作は、ステップ2324から接続点A2326を経由して、ステップ2328へと進む。ステップ2328で、コンテンツ配信システムは、第3および第4の補正メッシュ情報の組を再生デバイスに提供し、第3の補正メッシュ情報は、第2の立体視カメラ対の第1のカメラによって取り込まれた画像コンテンツをレンダリングすることに使用するためのものであり、第4の補正メッシュ情報は、第2の立体視カメラ対の第2のカメラによって取り込まれた画像コンテンツをレンダリングすることに使用するためのものである。いくつかの実施形態では、第1および第2の立体視カメラ対は、前方視方向に対応するが、コンテンツがストリーミングのために取り込まれている領域またはイベント場所における異なる場所に対応する。動作は、ステップ2328からステップ2330に進む。ステップ2330で、コンテンツ配信システムは、第5および第6の補正メッシュ情報を再生デバイスに提供し、第5の補正メッシュ情報は、第3の立体視カメラ対の第1のカメラによって取り込まれた画像コンテンツをレンダリングすることに使用するためのものであり、第6の補正メッシュ情報は、第3の立体視カメラ対の第2のカメラによって取り込まれた画像コンテンツをレンダリングすることに使用するためのものである。
[0213] 動作は、ステップ2330から任意選択である2332に進む。ステップ2332で、システム700は、第1の立体視カメラ対により取り込まれたコンテンツが、再生デバイスにストリーミングされたとき、第1および第2の補正メッシュ情報が使用されるべきであることを再生デバイスに示す。その標示は、再生デバイスに送られたコンテンツストリーム内にあることができ、または、システム700からの別の制御信号によることもできる。いくつかの実施形態では、第1のカメラ対のカメラによって取り込まれた画像コンテンツを含んだコンテンツストリームが、1つまたは複数の再生デバイスに送られるべきデフォルトのコンテンツストリームとして使用される。しかし、これは変更されることができ、他の立体視カメラ対により取り込まれた画像コンテンツを伝達するコンテンツストリームが、異なる時間に再生デバイスに提供され得る。いくつかの実施形態では、複数の立体視カメラ対(例えば、第1、第2、第3の立体視カメラ対)により取り込まれた画像コンテンツを伝達するコンテンツストリームが、再生デバイスに提供され、再生デバイスは、次いで、所与の時間にどのストリーム(複数可)に接続すべきかを選択することができる。動作は、ステップ2332からステップ2334および2336へと進み、それらのステップは、並列に、独立して実施される。いくつかの実施形態では、ステップ2334およびステップ2336は、2つの異なる代替形態であり、2つのステップのうちの一方だけが実施される。ステップ2334で、第1の立体視カメラ対から第2の立体視カメラ対に、コンテンツをストリーミングすることからのネットワークで制御された切換えが検出され、例えば、以前に提供されていた第1の立体視カメラ対からではなく、第2の立体視カメラ対に対応するコンテンツ送りが再生デバイスに提供されることを示す。動作は、ステップ2334からステップ2338へと進む。
[0214] ステップ2336で、第1の立体視カメラ対からのコンテンツを含む第1のコンテンツストリームを受信することから、第2の立体視カメラ対からの符号化されたコンテンツを含む第2のコンテンツストリームを受信することへのユーザに制御された変更が、システム700により検出される。動作は、ステップ2336からステップ2338へと進む。
[0215] ステップ2338で、システムは、第2のカメラ対により取り込まれたコンテンツが、第1のカメラ対からのコンテンツに代えて再生デバイスにストリーミングされるとき、および/または、第2のカメラ対により取り込まれたコンテンツが、再生デバイスによるレンダリングおよび再生のために使用されているとき、第3および第4の補正メッシュ情報が使用されるべきであることを再生デバイスに示す。いくつかの実施形態では、ステップ2338は、破線枠により示されるように、任意選択のものである。このような実施形態では、ステップ2334および2336に関して論じられたものなどの切換えを検出すると、ステップ2338に関して記載されたような標示は、システム700により提供されない。このような実施形態では、再生デバイスは、どのカメラ対のコンテンツストリームのために、どの補正メッシュ情報の組を使用すべきかに関して解決するために、補正メッシュ情報とカメラ対の間のマッピングを知っている。
[0216] 動作は、ステップ2338からステップ2340およびステップ2342へと進む。いくつかの実施形態では、ステップ2340およびステップ2342は、2つの異なる代替形態であり、2つのステップの一方だけが実施される。ステップ2340で、第2の立体視カメラ対から第3の立体視カメラへのコンテンツをストリーミングすることからのネットワークで制御された切換えが検出され、例えば、以前に提供されていた第2の立体視カメラ対からのものではなく、第3の立体視カメラ対に対応するコンテンツ送りが、再生デバイスに提供されるべきであることを示す。動作は、ステップ2340からステップ2342へと進む。
[0217] ステップ2342で、第2の立体視カメラ対からのコンテンツを含むコンテンツストリームを受信することから、第3の立体視カメラ対からのコンテンツを含むコンテンツストリームを受信することへの、ユーザに制御された変更が、システム700により検出される。動作は、ステップ2342から、いくつかの実施形態では任意選択のものであるステップ2344へと進む。
[0218] ステップ2344で、システムは、第3のカメラ対により取り込まれたコンテンツが再生デバイスにストリーミングされるとき、および/または、第3のカメラ対により取り込まれたコンテンツが再生デバイスによりレンダリングおよび再生するために使用されているとき、第5および第6の補正メッシュ情報が、レンダリングを行うために使用されるべきであることを、再生デバイスに示す。
[0219] 図24は、例えば、立体視再生方法の部分として、左眼画像および右眼画像をレンダリングし、表示するために、例えば、図8で示されたデバイス800などのコンテンツ再生デバイスなどのコンテンツ再生デバイスを動作させる方法2400を示す。立体視再生の場合、異なる左眼画像および右眼画像がユーザに表示され、例えば、いくつかの場合、ディスプレイの異なる部分が使用されて、ユーザの左眼が左眼画像を見て、右眼が右眼画像を見るような方法で、左眼画像および右眼画像を提示する。
再生中にどのようにして画像が生成されるかの理解を容易にするので、再生方法の論議中に、図14への参照が行われる。
[0220] 方法は、例えば、再生ルーチンが再生デバイスのプロセッサにより実行されるとき、ステップ2402で開始する。動作は、ステップ2402からステップ2404へと進む。ステップ2404で、再生デバイスは、異なる視界に対応するメッシュを備えた、例えば、3Dメッシュモデルなどの環境モデルを受信する。例えば、受信されたメッシュは、前方正面ビューに対応するメッシュ(0ビューメッシュ)と、左後方ビューに対応するメッシュ(1−ビューメッシュ)と、右後方ビューに対応するメッシュ(2−ビューメッシュ)とを含むことができ、また時には含む。前方メッシュビューおよび後方ビューメッシュに加えて、3Dモデルは、空(頂部)メッシュと、底部(地面)メッシュモデルとを含むことができる。使用されるメッシュに対応する画像コンテンツは、テクスチャとして使用することができ、異なるストリームでなど、別々に送られ得、時には別々に送られる。ステップ2406で、3Dモデルが記憶される。動作は、ステップ2406からステップ2408へと進み、1つまたは複数のUVマップ、例えば、3Dモデルの一部を形成する各メッシュに1つのUVマップが対応して、再生デバイスにより受信される。例えば、いくつかの実施形態では、ステップ2408で、複数のUVマップが、画像を環境モデルにマップするために使用されるべく受信される。UVマップの各面は、3Dメッシュモデルの面に対応し、同じ視界に対応する画像コンテンツとUVマップとの3Dモデルの対応する部分へのマッピングを制御するために使用される。このようなマッピングは、レンダリングエンジンによって実装され得、いくつかの実施形態では実施される。UVマップは図14に示されないが、各メッシュ部分に対応するUVマップがある。例えば、ステップ2408で、前方正面ビューUVマップと、右後方ビューUVマップと、左後方ビューUVマップと、頂部ビューUVマップと、底部ビューUVマップとが受信される。UVマップおよびモデルは、レンズの欠陥、または、立体視対のレンズ間の製造許容差により生じ得る差に依存しないので、単一のUVマップが、見る方向に対応する左眼画像と右眼画像の両方のために使用され得る。
[0221] ステップ2410で、受信されたUVマップは、例えば、受信された画像部分を、テクスチャとして環境の3Dモデルの表面にラッピングする(wrapping)のを容易にするため、画像レンダリングで使用するために、記憶される。
[0222] 動作は、ステップ2410から2412へと進む。ステップ2412で、1つまたは複数のマスクが受信される。例えば、いくつかの実施形態では、複数のマスク、カメラによって取り込まれ得る異なる視界のそれぞれについて1つのマスク、が、ステップ2408で受信される。例えば、取り込まれ得る頂部、前方、底部、左後方、および、右後方の視界のそれぞれのための別々のマスクを示す図14を考える。マスクは、実施され得るレンダリングまたはブレンド動作中に画像の組合せを制御するアルファ値の組として実装され得る。フレームの中心における画像部分がラップされるテクスチャとして使用され、マスクされる領域が3Dモデルの対応する部分上にラップされるテクスチャに寄与しないように、アルファ値は、マスクされる領域についてゼロに設定されることができる。
[0223] マスクは、ステップ2414で記憶される。動作は、ステップ2414から2416へと進む。ステップ2416で、例えば、環境モデルの表面へのテクスチャとしての適用のための画像を供給できるカメラ毎に1組のメッシュ補正情報など、メッシュ補正情報の複数の組が受信される。上記で述べるように、メッシュ補正情報は、カメラレンズに依存しており、個々のカメラレンズにより導入された歪みを考慮に入れる。メッシュ補正情報は、適用されているメッシュ補正情報として、同じ視界に対応するUVマップにおける値または情報への調整を行うために適用されるべきUVマップ変更情報を含むことができ、いくつかの実施形態では含む。したがって、メッシュ補正情報は、レンダリングの間に実装される、カメラにより取り込まれた画像からの3Dモデルへのマッピングをカスタマイズすることができ、UVマップが生成されたときに考慮されていない歪みが補償され得る。一実施形態では、ステップ2416では、メッシュ補正情報がある。立体視カメラ対は、正面、右後方、および、左後方のビューを取り込むために使用され、したがって、ステップ2416で、立体視カメラ対あたり2つのカメラが使用されて、使用される6個のカメラのそれぞれについて補正メッシュが受信され。いくつかの実施形態では、頂部および底部ビューは、立体視で取り込まれない。頂部および底部ビューが立体視である場合、別々の補正メッシュが、使用される左眼および右眼カメラのそれぞれのために受信される。ステップ2416では、特定のこの例において、頂部および底部ビューが立体視で取り込まれないものと想定して、頂部ビューメッシュ補正情報の1組および底部ビューメッシュ補正情報の1組だけが述べられる。したがって、ステップ2416で、例えば、前方を見ている立体視カメラ対の左眼カメラなどの第1のカメラに対応する第1の補正情報が受信される。ステップ2416で、また、第2のメッシュ補正情報が受信され、第2のメッシュ補正情報は、いくつかの実施形態では、前方を見ている立体視カメラ対の右眼カメラに対応する。ステップ2416で、複数の異なるカメラに対応する追加のメッシュ補正情報を受信することができ、また時には受信する。
[0224] 画像を供給するために、異なる度に、異なるカメラ装備が使用され得ることを理解されたい。このような場合、ステップ2416で、メッシュ補正情報は、異なるカメラ装備のカメラに対して受信される。レンダリング中に、メッシュ補正情報のどの組が使用されるかは、コンテンツを供給したどのカメラがレンダリングのために使用されているかに依存する。コンテンツストリームにおいてどのカメラが画像コンテンツを供給したかに関する情報は、再生デバイスが、画像を取り込んだカメラに対応する補正メッシュを特定できるように、ビデオコンテンツストリームに含まれ得る。いくつかの実施形態では、コンテンツを提供するサーバは、所与の時間に、どの補正メッシュを使用すべきかを再生デバイスに指示する信号を、再生デバイスに送り、サーバは、コンテンツを供給するためにどのカメラ(複数可)が使用されるかに関して変更がなされたときに、再生デバイスが補正情報の1つの組を使用することから、補正情報の他の組へと切り換えるべきであることを示す。
[0225] ステップ2418で、受信された補正メッシュは、再生デバイスに記憶される。したがって、ステップ2418では、複数の異なるカメラに対応する追加のメッシュ補正情報が、他の受信されたメッシュ補正情報と共に記憶され得る。補正メッシュ情報および他の情報が記憶されると、記憶された情報は、必要に応じてアクセスされ、レンダリングエンジンに供給され得る。
[0226] 動作はステップ2418から接続点2420を経由してステップ2422へと進む。ステップ2422で、各視界に対応する少なくとも1つの画像が受信される。これらは、最初に画像バッファに在留し、初期3Dビューを生成するために使用されるデフォルト画像とすることができる。
[0227] ステップ2424で、受信された画像は復号され、次いで、ステップ2426で、画像は、例えば、レンダリング動作での使用のために記憶される。画像が受信されると、初期の画像は、より最近の画像と置き換えることができる。理解されるように、環境の異なるセクションに対応する画像は、異なるレートで更新され得る、すなわち、受信され得る。
[0228] 動作はステップ2426からステップ2428に進み、ユーザの頭部位置、例えば、見る方向などが、例えば、ヘッドマウントディスプレイにおけるセンサからの情報に基づいて決定される。いくつかの実施形態では、頭部位置は、ステップ2430で示されるように、コンテンツを再生デバイスに供給するサーバに報告される。しかし、他の実施形態では、頭部位置情報は報告されないが、どのブロードキャストまたはマルチキャストコンテンツストリームを受信すべきかを決定する、および/または、3D環境のどの部分が所与の時間に再生デバイス上でユーザに表示されるべきかを決定するために、再生システムによって使用される。
[0229] 動作はステップ2428もしくはステップ2430(実装される場合)から、ステップ2432へと進む。ステップ2432で、再生デバイスは、例えば、1つまたは複数のコンテンツストリームなどの画像を受信する。例えば、コンテンツサーバから、受信されたコンテンツストリームは、1つまたは複数の視界に対応する画像を伝達する。一実施形態では、ステップ2432で、前方を見ている立体視対の、例えば、左眼カメラなど、第1のカメラにより取り込まれた画像コンテンツを含む第1の符号化された画像が、第1の立体視対の第2の(右)カメラにより取り込まれた第2の画像と共に受信される。このような実施形態では、ステップ2432で、第1の立体視カメラ対の例えば、右眼カメラなどの第2のカメラにより取り込まれたコンテンツを含む第2の符号化された画像も受信される。コンテンツストリームの受信は、再生デバイスが特定のコンテンツストリームを要求し、ユニキャスト配信によりコンテンツを受信した結果であることができ、または、再生デバイスがアリーナもしくは他の3D環境におけるスポーツ競技などのイベントに対応する画像を提供する1つまたは複数のストリームのマルチキャストまたはブロードキャストを受信した結果であることができる。
[0230] 動作はステップ2432からステップ2434へと進む。必ずしもすべてではないが、いくつかの実施形態で実施されるステップ2434で、再生デバイスは、再生デバイスに供給されている画像について、メッシュ補正情報のどの組または複数の組を使用すべきかを示す情報を受信する。メッシュ補正指示情報は、レンダリング中に、画像の特定された組を使用するとき、メッシュ補正情報の特定の組として使用するためのコマンドもしくは命令の形をとる、あるいは、再生デバイスが、受信されている画像のソースであるカメラに対応するメッシュ補正情報の組を特定し、使用できるように、供給されている画像がどのカメラで取り込まれたかに関する標示の形をとることができる。
[0231] 動作は、ステップ2434からステップ2436へと進み、受信された画像が復号される。したがって、第1のカメラからの第1の符号化された画像が受信された場合、第1の符号化された画像は、ステップ2436で、第1の復号された画像を生成するために復号される。理解されるように、立体視画像コンテンツの場合、左眼画像および右眼画像が受信され、立体視フレームごとに復号され得る。したがって、ステップ2436で、例えば、第1の立体視対の第2のカメラからの第2の画像などの右眼画像が同様に復号される。ステップ2438で、3D環境モデルの表面に適用されるテクスチャとしての使用のために、復号された画像は記憶される。
[0232] 動作は、ステップ2438からステップ2440へと進み、例えば、ユーザの検出された頭部位置により示されたユーザの視界に対応するなど、左眼画像および右眼画像をレンダリングすることにおいて、どの復号された画像および補正マップ情報を使用すべきかに関して決定がなされる。通常、同じ時刻に対応する画像がレンダリングにおいて使用されることになるが、異なる視界に対応する画像が異なる時間に受信される場合、3Dモデル全体の一部に対応するフレームの、例えば、最後に受信されたバージョンなどのより古いバージョンが、完全な画像がレンダリングされ得るように、ユーザの主要な視界内でより最近受信されたフレームと組み合わせて使用され得る。
[0233] いくつかの実施形態では、左眼画像および右眼画像は別々にレンダリングされるが、ユーザの左眼がレンダリングされた左眼画像を見て、ユーザの右眼がレンダリングされた右眼画像を見るように、それらが立体視フレーム対として共にユーザに表示され得る場合であってさえでもある。ステップ2442で、例えば、図25で示されるように、左眼画像をレンダリングするために、レンダリングルーチンへの呼び出しが行われる。
[0234] 左眼画像をレンダリングすることの部分として、ステップ2508で、レンダリング画像は、例えば、左眼画像などの表示のための第1の画像を生成するために、第1のメッシュ補正情報と、例えば、前方左眼画像などの第1の復号された画像と、環境メッシュモデルとを用いてレンダリング動作を実施することができる。加えて、第1のマスクは、当該第1のレンダリング動作の部分として、当該第1の画像の部分が、異なる視界に対応する他の画像の部分とどのように組み合わされるかを決定するために使用され得る。例えば、異なるカメラから得られた画像が重複する場合、重複する画像の1つまたは複数の部分が、レンダリング動作の部分として当該第1の画像の部分を環境メッシュモジュールの表面に適用することによって生成されている画像への寄与しないようにするために、マスクが使用され得る。ゼロのアルファ値が、メッシュに適用されるべきでない画像の部分のために割り当てられ、使用され、それにより、その寄与がゼロになるようにレンダリングすることができる。
[0235] レンダリングされている立体視画像対の右眼画像をレンダリングするため、ステップ2444で、右眼画像をレンダリングするために、レンダリングルーチンへの呼び出しが行われる。したがって、ステップ2444で、第2のレンダリング動作が、表示のための第2の画像を生成するため、メッシュ補正情報の第2の組と、第2の復号された画像と、環境メッシュモジュールとを用いて実施される。視界の左眼画像に使用されるのと同じマスクが、同じ視界に対応する右眼ビューのためのレンダリング中に使用され得る。したがって、いくつかの実施形態では、左眼画像をレンダリングするために使用される第1のマスクは、右眼画像をレンダリングするために使用される第2のレンダリング動作の部分として、前記第2の画像の部分が、異なる、例えば、重複する、視界に対応する第2の画像の部分とどのように組み合わされるかを決定するために使用される。
[0236] 理解されるように、時間の経過と共に、図24および図25のステップは、数回繰り返される。後の反復は、例えば、第1の立体視対と同じ、または異なるカメラ装備上にある異なる立体視カメラ対に対応する第4および第5のカメラなど、異なるカメラからの画像の使用を含んでよい。したがって、ステップ2444が第2の時間、または後の時間に実施される場合、第4のカメラに対応する画像をレンダリングするときに第4のカメラに対応するメッシュ補正情報を求めることを含むことができ、また時には含むが、その場合、前記第4のカメラは、そのための補正メッシュ情報が受信される複数の異なるカメラのうちの1つとすることができ、また時にはそうである。
[0237] 次いで、ステップ2446で、左眼画像および右眼画像が、ディスプレイを用いてユーザに表示され、それは、ユーザの左眼が左眼画像を見て、またユーザの右眼が右眼画像を見る結果となる。
[0238] 動作は、ステップ2446からステップ2428へと進み、追加の画像が受信され、処理され得るようにし、ユーザは、例えば、イベントの持続期間にわたり、継続して立体視画像が提供される。
[0239] ここで、図25で示される画像レンダリングルーチン2500が論じられる。ルーチンは、左眼画像および右眼画像をレンダリングするために呼び出され得る。レンダリングされる左眼画像および右眼画像の対は、ユーザにより見られたとき、ユーザが異なる左眼画像および右眼画像を見ることにより、奥行き感を担うことになる立体視フレームを表す。
[0240] レンダリングルーチン2500は、例えば、ルーチン2400により、画像をレンダリングするために呼び出されたとき、ステップ2502で開始する。ステップ2504で、レンダリングエンジン822などのレンダリングエンジンは、例えば、異なる視界に対応する複数のメッシュモデルと、異なる視界に対応するUVマップと、異なる視界に対応するマスクとを備える3Dメッシュモデルなどの環境モデルをロードされる。レンダラにロードされる情報は、UVマップを除く様々な情報の要素を示している図14の文脈で容易に理解され得る。上記で論じたように、この情報は、左眼画像と右眼画像の両方をレンダリングするために使用されることができ、立体視カメラの対の個々のカメラレンズに特有のものである歪みに依存しない可能性がある。
[0241] ロードされた環境モデルおよびUVマップをもって、動作はステップ2506へと進む。ステップ2506では、レンダリングエンジンは、カメラに依存する環境メッシュ補正情報が供給される。したがって、ステップ2506で、レンダリングエンジンは、レンダリング動作で使用される画像部分を取り込むために使用されたカメラに対応する補正メッシュ情報が供給される。例えば、左眼画像がレンダリングされる場合、ステップ2506で、レンダリングエンジンは、環境の左眼画像部分を取り込んだカメラに対応するメッシュ補正情報を受信する。同様に、右眼画像がレンダリングされる場合、ステップ2506で、レンダリングエンジンは、環境の右眼画像部分を取り込んだカメラに対応するメッシュ補正情報を受信する。特定の視界について単一のカメラが使用されたとしたら、その単一のカメラに対応する歪み補正メッシュが、左眼ビューと右眼ビューの両方をレンダリングするために使用される。
[0242] いくつかの実施形態では、ステップ2506は、レンダリング動作で使用されている画像コンテンツをどのカメラが取り込んだかに基づいて、または、受信されたコンテンツストリームに対応する画像をレンダリングするときに、どのメッシュ補正情報が使用されるべきかを示すサーバからの標示に基づいて、レンダリング動作を実施するときにどのメッシュ補正情報を使用すべきかを決定することを含む。
[0243] 3Dモデルの異なる部分に対応する画像がロードされると、ステップ2508で、メッシュ補正情報の受信された組に含まれるメッシュ補正情報により補正されて、UVマップ情報に基づいて3Dモデルの表面に画像の部分を適用することにより出力画像を生成するために、レンダリングエンジンは動作される。例えば、UVマップにおける、例えば、ノードなど、頂点(vertex)の位置は、レンダリングプロセスの部分として3D環境モデルの表面にテクスチャをラップするために使用される前に、受信された補正情報に従って調整され得る。レンダリング中に、受信された画像のどの部分がラッピング動作において使用されるかを決定するために、受信されたマスクが使用される。ゲームシステムで使用されるものなどのレンダリングエンジンは、記載された入力および補正情報に基づいてレンダリングを実装するために使用され得る。
[0244] ステップ2508で実施されるレンダリング動作は、生成されるべき立体視画像対の左眼画像および右眼画像のそれぞれについて実施されるレンダリング動作でもって、左眼画像または右眼画像が環境の3Dモデルの表面にラップされるかどうかに応じて、ユーザの示された視界に対応する左眼または右眼出力画像を作成する。
[0245] ステップ2508で生成された画像が、ステップ2510で表示のために出力される。ステップ2512は停止ステップとして示されているが、これは、単に、画像のレンダリングが完了したことを示しており、レンダリングルーチン2500は、例えば、一度に1つの画像など、必要に応じて左眼画像および右眼画像をレンダリングするために複数回呼び出され得ることを理解されたい。
[0246] ステップは、例示的な順序で示されているが、多くの場合、ステップの順序は、動作に悪影響を与えることなく、変更され得ることを理解されたい。したがって、ステップの例示的な順序が適正な動作のために必要でない限り、ステップの順序は、限定されることのない、例示的なものであると見なされるべきである。
[0247] いくつかの実施形態は、立体視ビデオを符号化し、圧縮するために、コンピュータまたは他のデバイスを制御するための、例えば、コンピュータで実行可能な命令など、ソフトウェア命令の組を包含する非一時的なコンピュータが読み出し可能な媒体を対象とする。他の実施形態は、再生装置側で、ビデオを復号し、解凍するようにコンピュータまたは他のデバイスを制御するための、例えば、コンピュータで実行可能な命令など、ソフトウェア命令の組を包含するコンピュータが読み出し可能な媒体を対象とする。符号化および圧縮が、可能な別々の動作として述べられているが、符号化は、圧縮を実施するために使用されることができ、したがって、符号化は、いくつかの場合、圧縮を含むことができることを理解されたい。同様に、復号は、解凍を含むことができる。
[0248] 様々な実施形態の技法は、ソフトウェア、ハードウェア、および/または、ソフトウェアとハードウェアの組合せを用いて実装され得る。様々な実施形態は、例えば、画像データ処理システムなどの装置に向けられている。様々な実施形態は、また、例えば、画像データを処理する方法などの方法に向けられている。様々な実施形態は、また、方法の1つまたは複数のステップを実装するようにマシンを制御するためのマシンが読み取り可能な命令を含む、例えば、ROM、RAM、CD、ハードディスクなどの、コンピュータなどの非一時的なマシンが読み取り可能な媒体に向けられている。
[0249] 本発明の様々な特徴は、モジュールを用いて実装される。このようなモジュールは、ソフトウェアモジュールとして実装されることができ、いくつかの実施形態では、ソフトウェアモジュールとして実装される。他の実施形態では、モジュールは、ハードウェアで実装される。さらに他の実施形態では、モジュールは、ソフトウェアとハードウェアの組合せを用いて実装される。いくつかの実施形態では、モジュールは、個々の回路として実装され、各モジュールは、そのモジュールが対応する機能を実施するための回路として実装される。異なるモジュールが、例えば、ハードウェアでのいくつか、ソフトウェアでのいくつか、および、ハードウェアとソフトウェアの組合せを用いるいくつかなど、異なって実装されるいくつかの実施形態を含む、広範囲な様々の実施形態が企図される。ルーチンおよび/またはサブルーチン、または、このようなルーチンによって実施されるステップのいくつかは、汎用のプロセッサ上で実行されるソフトウェアとは対照的に、専用のハードウェアに実装され得ることにも留意されたい。このような実施形態は、本発明の範囲内に留まる。上述の方法、または、方法ステップの多くは、上述の方法のすべて、または、部分を実施するために、例えば、追加のハードウェアを有する、もしくは有しない汎用コンピュータなどのマシンを制御するように、例えば、RAM、フロッピー(登録商標)ディスクなどのメモリデバイスなどのマシンが読み取り可能な媒体に含まれる、ソフトウェアなどのマシンが実行可能な命令を用いて実装され得る。したがって、他のこともある中で、本発明は、例えば、プロセッサや関連するハードウェアなどのマシンに、上記で述べた方法(複数可)のステップの1つまたは複数のものを実施させるために、マシンが実行可能な命令を含むマシンが読み出し可能な媒体に向けられる。
[0250] 上記で述べた様々な実施形態の方法および装置に関する数多くの追加の変形形態が、上の記載に鑑みて当業者には明らかであろう。そのような変形形態も、本範囲に含まれるものと見なされるべきである。