JP5891425B2

JP5891425B2 - 追体験映像を提供することができる映像提供装置、映像提供方法、映像提供プログラム

Info

Publication number: JP5891425B2
Application number: JP2012539527A
Authority: JP
Inventors: ジェルマーノライクセンリング; 朋子片山; 大戸　英隆; 英隆大戸; 宣輝富永
Original assignee: Panasonic Intellectual Property Management Co Ltd
Current assignee: Panasonic Intellectual Property Management Co Ltd
Priority date: 2011-03-03
Filing date: 2012-02-29
Publication date: 2016-03-23
Anticipated expiration: 2032-02-29
Also published as: CN102812497B; CN102812497A; US20130071012A1; WO2012117729A1; US9020241B2; JPWO2012117729A1

Description

本発明は、画像合成技術の技術分野に属する。

画像合成技術とは、背景画像のどの位置に前景画像を合成すべきかを解析して、好適な位置を選び、前景画像を背景画像に合成する技術である。ここで、ユーザが個人的に撮影した写真を前景画像として選び、その撮影地点のストリートビューを背景画像として選んで合成に供した場合、その撮影時の雰囲気をユーザに追体験させるような合成映像をユーザに提供することが可能になる。
具体的にいうと、現在、インターネット上ではストリートビュー検索サービスというものが運営されていて、かかるサービスでは、世界的に収集された背景画像がサーバ内に蓄積されている。かかる背景画像のうち、所望のものをダウンロードして、ユーザが撮影した人物に合成すれば、その撮影当時の雰囲気を様々なアングルで再現することができる。このように、ストリートビュー検索サービスを前提にして、ユーザの個人写真の撮影時の追体験を行わせる機能を追体験機能という。

US6,711,293B1

追体験機能の更なる発展形として、立体視写真である前景画像と、立体視ストリートビューである背景画像との合成を実現しようとする動向がある。ここで立体視の実現には、デプス画像を用いて右目画像、左目画像という2つの視点画像を生成するものと、撮影時に右目画像、左目画像という2つの視点画像を得るものとがあり、これらは、画像中に表れる建造物の奥行きが異なっている。つまり地球上の同一場所を撮影したとしても、カメラが得る建造物や人物の奥行きは異なるから、写真と、ストリートビューとを合成すると人物と建造物との奥行き感がチグハグなものになり、見るに耐えない立体視画像が得られることになる。ここで、特許文献１に記載された特徴点抽出を行い、前景画像と、背景画像とで平面的な位置合わせをすることも考えられるが、背景画像と、写真とでデプス画像が全く異なりストリートビューの手前に写真が大きく飛出したり、またストリートビューの奥に写真が食い込んだりするような場合は、たとえ特許文献１の技術により平面的な位置関係を整合させたとしても、上記チグハグ感による視覚上の不整合は拭いきれない。

本発明の目的は、全く異なる条件で撮影された前景画像を、背景画像に合成する場合でも、違和感のない立体視画像を作成することができる映像提供装置を提供することである。

背景画像はストリートビュー、前景画像は写真であるとの仮定下で技術的課題を提示したが、この仮定は、上記技術的課題を説明するにあたって、身近な題材を選んだに過ぎず、本願で対象としている技術的課題は、背景画像、前景画像が上記の例であるケースに限定されない。上記技術的課題は、何等かの奥行き感が異なる二枚の画像を合成する技術を工業製品に応用するにあたって本願の技術分野の当業者が直面する、視覚上の不整合の解消全般が本願の技術的課題である。

上記課題を解決することができる映像提供装置は、
背景画像データを三次元モデリング空間における立体モデルの内側表面に貼り付けた上で、前景画像データを合成する映像提供装置であって、
前景画像データ及び背景画像データの特徴点を抽出する抽出手段と、
前景画像データの特徴点と、背景画像データの特徴点とのペアをサーチして、これらのペアを利用することにより、前景画像データを背景画像データの内部に投影するための変換行列を得るマッチング手段と、
前景画像データに対応するデプス前景データに対して、マッチング手段が得た変換行列に基づく変換を施す変換手段と、
変換がなされたデプス前景データをベースにしたデプスベースドレンダリングを、前景画像データに施すことにより、前景画像データに対応する2以上の視点画像データを得るデプスベースドレンダリング手段と、
前景画像データに対応する2以上の視点画像データと、背景画像データに対応する2以上の視点画像データとの合成を行う合成手段と
を備えることを特徴とする。

前景画像を、背景画像に射影するための変換行列を得て、この変換行列に従い、前景画像のデプス画像を変換するので、前景画像のデプス画像に示される奥行きは、背景画像の奥行きと整合がとれたものになる。このように変換がなされた前景画像のデプス画像に基づき2以上の視点画像を作成すれば、背景画像から異様に飛び出たり、前景画像が背景画像から異様に遠ざかるという不自然な立体感は発生しえない。よって適切な立体視効果を奏するような合成映像を作成することができる。

上述したような立体視再生時におけるチグハグ感が発生しないので、追体験提供という新しいネットワークサービスを展開させることができる。また、かかる機能をテレビ、レコーダー、カムコーダ、デジタルカメラといった家電製品にもたせることで家電製品の高付加価値を図ることができる。

かかる課題解決手段を具備した映像提供装置の発明は、本願の特許請求の範囲における最初の請求項である請求項１に記載されている。ここで、この映像提供装置の発明に、別の発明特定事項を追加したり、また、このシステムの発明の発明特定事項を上位概念のものから下位概念のものに置き換えることで、上記再生装置の発明に、更なる効果を奏させることができる。これら、発明特定事項の追加、発明特定事項の下位概念化のバリエーションには以下のものがあり、これらのバリエーションは、請求項２以下の従属請求項に請求項に区分けして記載されている。

任意的であるが、前記前景画像データ上のある特徴点f (xf , yf)と、特徴点f(xf,yf)に対応する背景画像データの特徴点F(XF,YF)、及び、特徴点F(XF,YF)のデプス値ZFをX,Y,Z座標として以下の数１の数式に適用することで変換行列Ｈを得てもよい。

かかる行列の導出は、OPEN-GL等、既存のCG右目画像を用いて実現することができるから、デジタル家電への実装が容易になる。

任意的であるが、前記映像提供装置は更に、立体視カメラによって撮影された写真画像データを取得する取得手段を備え、撮影された写真画像データには、右目写真データ、左目写真データがあり、
前記変換手段は更に、
背景画像データの撮影方向と、各写真画像の撮影方向とを比較することにより右目写真データ、左目写真データのうちどちらを基点画像にするかの決定を行い、
前記前景画像データは、右目写真データ、左目写真データのうち基点画像データとして決定されたものでもよい。

背景画像の撮影方向と、各写真画像の撮影方向とを比較することにより右目写真データ、左目写真データのうちどちらを基点画像にするかの決定を行うので、写真の撮影方向が、ストリートビューの８方向と異なっていることに起因する違和感を最小化することができる。

任意的であるが、前記映像提供装置は、
右目写真データ、左目写真データから写真についてのデプス画像を生成するデプス画像生成手段を備え、
変換手段による変換がなされるデプス前景データとは、デプス画像生成手段によって生成されたデプス画像でもよい。前景画像を取得したカメラにデプス画像を取得する機能が存在しなくても、好適なデプス画像を得ることができる。

任意的であるが、前記デプスベースドレンダリング手段は、
左目写真データ、右目写真データのうち、基点画像ではないものの画素の座標を、デプス前景データに示される奥行きに基づき水平方向にシフトすることにより、画像データの再生成を行い、
前記2以上の視点画像データは、
左目写真データ及び右目写真データのうち、基点画像データではないものと、再生成された画像データとから構成されてもよい。

前景画像に対応する2以上の視点画像の生成は、デプスイメージベースドレンダリング(DIBR)を実現することができるソフトウェア、ハードウェアを用いて実現することができる。

任意的であるが、映像提供装置には、探索を行うべき特徴点がとるべき奥行きの許容レベルが予め定められており、
前記マッチング手段は、
立体ストリートビュー視点にマッチングするための特徴点を前景画像データからサーチするにあたって、奥行き分布の中心が許容レンジ外となる特徴点を排除して背景画像データにおける特徴点、及び、前景画像データにおける特徴点のうち奥行き分布の中心が許容レンジ内となる特徴点同士でマッチングを行ってもよい。

空の雲を構成する画素等、遠方に存在する画素は、マッチングから除外される。前景画像における雲と、背景画像における雲に整合させるような誤った位置合わせは発生し得ないので、変換行列の取得を高精度に行うことができる。

任意的であるが、前記映像提供装置は、地球上の地理的情報を用いてカレント視点位置を指定した画像取得要求を画像収集サーバに送信する送信手段と、
画像取得要求に対する応答として、画像収集サーバから送信されてくるストリートビューファイルを受信する受信手段とを備え、
前記背景画像データは、受信したストリートビューファイルに存在してもよい背景画像は、地球上の地理的情報を用いた画像取得要求に応じて送信されるので、ユーザは家屋の中に居ながら、世界中の好きな場所の光景をサーバからダウンロードしてこれを自分の写真に合成させることができる。かかるサービスにより世界中を旅行したような仮想体験をユーザに経験させることができる。

任意的であるが前記映像提供装置は、記録媒体をアクセスして立体写真ファイルを読み出す読出手段を備え、
前記立体写真ファイルは、左目写真データ及び右目写真データと、地理的情報とを含み、
前記変換手段は更に、
背景画像データの撮影方向と、各写真画像の撮影方向とを比較することにより右目写真データ、左目写真データのうちどちらを基点画像にするかの決定を行い、
前記前景画像データは、右目写真データ、左目写真データのうち基点画像データとして決定されたものであり、
前記送信手段は、
立体写真ファイルに存在する地理的情報を用いてカレント視点位置を指定する画像取得要求を作成して、画像収集サーバに送信し、
画像収集サーバから送信されてくるストリートビューファイルは、画像取得要求に含まれる地理的情報と合致する撮影地属性を有してもよい。写真ファイルに存在する地理的情報をキーワードとして背景画像の検索をサーバに行わせ、所望のストリートビューファイルを取得するので、映像提供装置がデジタルテレビに組み込まれる場合、デジタルテレビと、立体視カメラとを連携させた新規なサービスが可能になる。これにより、デジタルテレビと、立体視カメラとをセットで販売する場合に、競合商品との差別化が可能になる。

任意的であるが背景画像は視点周囲画像であり、画像取得要求における地理的情報に対応する地理的位置から周囲を見渡した場合の光景を表してもよい。ユーザは、視点周辺画像に現れる範囲で、自由に視線を変化させることができ、追体験機能の充実化を図ることができる。

立体視グローバルビュー検索サービスの全体構成を示す。ストリートビューの対象となる仮想空間を模式的に示す図である。複数の背景画像が横並びに貼りつけられた球面モデルの内側表面を表す。三次元モデリング空間において立体視再生時に作成される2つの球面モデルを示す。球体の内側表面に貼りつけられた背景画像から多視点画像を作成する過程を示す。左シフト後の全周囲画像、右シフト後の全周囲画像が貼りつけられた状態の球面モデルを示す。左目用テクスチャ、右目用テクスチャの配置を示す。前景画像と、背景画像との合成を示す。追体験映像の一例を示す。ストリートビューナビの画面構成の一例を示す。実施の形態１におけるデータフローの例を示す図である。実施の形態1における映像提供装置の内部構成を示す図である。制御部４による追体験GUIの一例と、スライドショーにおける個々の表示とを示す。実施の形態１における立体写真ファイルのデータ構造およびデータ例、JPEG圧縮された左目画像データ、右目画像データ、デプス画像を示す。実施の形態１における立体ストリートビュー視点ファイルのデータ構造およびデータ例を示す。デプス画像中に現れた家屋、及び、特徴量記述子２０１のデータ構造およびデータ例を示す。特徴マッチングの対象となる写真、背景画像の一例である。特徴点の一例、写真Bを背景Aに当てはめる変形の過程と、その結果とを示す。前景画像のデプス画像と、背景画像のデプス画像とを示すと共に、マッチング結果を考慮した背景画像と、前景画像とのレンダリングの過程を示す。追体験処理のメインフローである。写真及びストリートビューの特徴点抽出手順を示すフローチャートである。写真及びストリートビューについてのマッチング及びデプス画像変換の処理手順を示すフローチャートである。映像提供装置のハードウェア構成図である。 GPUの内部構成を示す図である。球面モデルと、テクスチャとの対応付け、及び、テクスチャマッピングを実現するためのAPI呼出しの記述例である。デプス画像メモリにおいて座標(x,y)に存在する画素Pix(x,y)と、座標(x,y)に存在する画素の奥行きDepth(x,y)とを示す。画素レベルのシフトにより、左目テクスチャ、右目テクスチャにおいてどのような視差がもたらされるかを示す。

上記課題解決手段を具備した映像提供装置の発明は、ストリートビューを再生するためのデジタル家電機器として実施することができ、集積回路の発明は、当該デジタル家電機器に組込まれるシステムLSIとして実施することができる。映像提供方法の発明は、このデジタル家電機器で実現される時系列手順として実施することができる。映像提供プログラムの発明は、コンピュータ読み取り可能な非一時的記録媒体に記録され、デジタル家電機器にインストールされる実行形式プログラムとして実施することができる。映像提供装置の説明に先立ち、映像提供装置の使用環境である立体視グローバルビュー検索サービスの全体構成について説明する。

図１は、立体視グローバルビュー検索サービスの全体構成を示す。グローバルビュー収集サーバ１００１は、世界中から収集された背景画像を、デプスデータ、地形データと対応付けて格納しているサーバであり、クライアント装置からの要求に応じて視点周囲画像を、デプス画像、地形データと共に送信する。背景画像は、専用の撮影車両の走向中に撮影されたものである。デプスデータは、その撮影時に取得したランドマークの奥行きを示す。更に視点周囲画像とは、グローバルビュー収集サーバ１００１に対して送信した画像取得要求における地理的情報に対応する地理的位置から周囲を見渡した場合の光景を表すものである。視点周囲画像は例えば90度、120度、180度、360度といった比較的広い視野を見渡せる画像であり、特に、360度の視野を見渡せる視点周囲画像をパノラマ画像または全周囲画像と称することもある。説明の便宜上、以降の説明において視点周囲画像は360度の視野を見渡せるパノラマ画像、つまり全周囲画像であると仮定する。この撮影車両は、複数のカメラを具備していて、複数のカメラで、車両が存在する場所を、縦４×横７の背景画像により表す。デプス画像は、デプスデータにおけるランドマークの奥行きを、画素の輝度によって表したものであり、背景画像の奥行きを表す。つまりデプス画像の個々の画素は、背景画像の個々の画素を奥行きを示す奥行き情報になる。

クライアント装置１００２は、デジタルテレビ等、ネットワーク対応の家電機器であり、サーバに対してダウンロード要求mg1を送信し、全周囲画像mg2、デプス画像mg3を受信する。この全周囲画像を用いて、3Dストリートビューを実行する。かかるダウンロード要求は、緯度、経度、標高の情報を含み地球上の任意の場所の全周囲画像の送信を要求することができる。

眼鏡１００３は、ユーザが立体視でのストリートビューの視聴を希望する場合に、ユーザによって着用される。ここでの立体視は、多視点画像群により実現されるものである。ここで多視点画像群とは、左目画像、右目画像、中央、右斜上画像、右斜下画像、左斜上画像、左斜下画像というように、2以上の視点に対応する視点画像によって立体視を実現する視点画像の集合体である。多視点画像群の全てのバリエーションについて説明を行うとすると説明が煩雑になるので、以降の説明において、多視点画像群は、必要最低限の視点画像の組み、つまり、左目画像、右目画像の組みからなるステレオ画像群であるとして進める。

図２は、ストリートビュー立体視システムを模式的に示す図である。本図の上半分はモデルが存在する仮想空間であり、下半分は、クライアント装置１００２、眼鏡１００３が存在する現実空間である。

まず仮想空間について説明する。仮想空間とは、立体モデルの幾何学形状を規定する三次元座標を配置するための座標系にて規定される三次元モデリング空間である。立体モデルの形状は問わない。円柱、円錐、三角錐、楕円体等、どのような形状の三次元モデルでもよいが、説明の便宜のため、以降の説明は、球面モデルとして説明を行う。立体モデルである球体の中心は、カメラの位置である。簡単のため、球面モデルは1つのみをえがいているが、立体視時には、左目用、右目用のそれぞれについての球面モデルが存在する。図中のカメラCLは、球面モデルの中心から右側にpだけ隔てた位置に配置されるカメラである。カメラCRは、球面モデルの中心から左側にpだけ隔てた位置に配置されるカメラである。これらカメラCL、CRは、左目撮影時、右目撮影行為時における球面モデルの中心位置になる。

この立体モデルの斜め上には、縦４×横７の背景画像を結合した全周囲画像が配置される。全周囲画像には、右目用の全周囲画像m1と、左目用の全周囲画像m2とがあり、右目用テクスチャと、左目用テクスチャとでは、三次元モデリング空間における配置位置が異なる。本図では、球面モデルの上半分のみを描いているが、実際は下半分も存在する。また全周囲画像についても、上半分のみを描いているが、実際は下半分も存在する。

次に球面モデルについて説明する。球体の内側表面には、右目用テクスチャの貼付け範囲m4、左目用テクスチャの貼付け範囲m5が存在する。球面モデルにおける貼付け範囲とは、球面モデルにおいて、4つ又は3つの交点にて規定されるグリッドのことである。かかるグリッドは、球面モデルの曲率を有し、球面モデルの極座標を頂点とした三角形ストリップの一部又は全部として定義される。テクスチャマッピングにあたっては、図形タイプを三角形ストリップとして、背景画像が格納されたテキストバッファ座標との対応付けをすることで、グラフィクス描画を実行する。テクスチャの手前には、表示面が存在し、この表示面にはビューポートmg6が定義される。ビューポートは、三次元モデリング空間のうち、表示に供される部分を規定するものである。このビューポートに投影される映像が、再生に供されることになる。ビューポートは、左目の投影範囲、右目の投影範囲が交差する場所に存在している。つまりビューポートは、左目用と、右目用とで共通の位置に配置される。

球面モデルの内側に貼付けられるテクスチャは全周囲画像であるから、３６０°の全周囲を見渡せることになる。三次元モデリング空間における球面モデルをメルカトル図形に展開すれば、全周囲画像になる。半球体における縦２×横７のグリッドの個数は、全周囲画像における縦２×横７の背景画像の個数と一致する。つまり全周囲画像における個々の背景画像をテクスチャに変換して、球面モデルの個々のグリッドに貼付けるというテクスチャマッピングを行う。

以上が仮想空間についての説明である。続いて、現実空間について説明する。

本図では、立体モデルである球体の真下にクライアント装置１００２と、眼鏡１００３を着用したユーザの顔とを描いている。クライアント装置１００２の表示画面は、球面モデル内のビューポートの真下に存在する。また眼鏡１００３は、カメラCL,CRの真下よりやや奥に存在する。これは、ユーザの右目、左目はカメラCL,CRの位置となるので、眼鏡１００３はこれの近くに配置せねばならないからである。

上述したように、カメラCL、CRの位置がユーザの右目、左目に該当し、ビューポートがクライアント装置１００２の画面に該当するから、クライアント装置１００２と、ユーザとの間に立体視画像が出現する。仮想空間において、家屋は平面的に表現されていたが、現実空間において家屋は、クライアント装置１００２の画面から飛出す形になっている。

図３は、球面内側に貼りつけられたテクスチャを、球面モデル中心から視聴した状態を示す。図３は、複数の背景画像が横並びに貼りつけられた球面モデルの内側表面を表す。図３では、正面には近代的な教会が配置され、右手側に滑り台が存在する。これらは球体の内側表面に貼りつけられたものであるから、断面円の中心にカメラを配置した場合、これを全周囲から取り囲むように背景画像が配置されることになる。この球面モデルに貼付けられたテクスチャは、地球上の緯度、経度、標高から定まる視点位置に伴い変化する。つまり映像提供装置は、視点位置の変更操作がユーザによってなされた場合、地球上の地理的情報（緯度、経度、標高等）から定まるカレント視点位置を更新して、更新後のカレント視点位置に合致した全周囲画像をダウンロードし、この全周囲画像を球面モデルに貼付けて、再描画を行う。

図２の球面モデルは、球面モデルの中心にカメラが存在していたが、これは平面視のためのカメラ位置であり、立体視のカメラ位置は異なる。立体視時には、球面モデル中心からpだけ隔てられた位置にカメラを配置することで球面モデルが2つ得られる。図４は、三次元モデリング空間において立体視再生時に作成される2つの球面モデルを示す。図４（ａ）は、左目用の球面モデルであり、横7枚の背景画像を横方向に結合した画像に対してDIBRを実行することで作成された左目画像が内側に貼付けられている。

図４（ｂ）は、（ａ）の画像に対してデプス画像をベースにしたデプスベースドレンダリングを実行することで作成された右目画像であり、横7枚の背景画像を横方向に結合した画像に対して、デプス画像をベースにしたデプスベースドレンダリングを実行することで作成された右目画像が内側に貼付けられている。

全周囲画像を構成する横７枚の画像を、画像A,B,C,D,E,F,Gとする。この画像A〜Gから右目用テクスチャ、左目用テクスチャをどのように作成するかについて説明する。図５は、この球体の内側表面に貼りつけられた背景画像から多視点画像を作成する過程を示す。（ａ）は、球体内側表面を分割することで得られた7つの分割領域に、全周囲画像を構成する横7枚の画像のうち、A、B、C、D、Eという5枚の背景画像をA→B→C→D→Eの順序で貼りつける一例を示す。図５（ａ）の画像A、画像B、画像C、画像D、画像Eについて説明する。画像AにおいてDIBRによるシフトで座標が変化する画素の集りを、AL、AM、ARとしている。画像BにおいてDIBRによるシフトで座標が変化する画素の集りを、BL、BM、BR、画像CにおいてDIBRによるシフトで座標が変化する画素の集りを、CL、CM、CRとしている。画像DにおいてDIBRによるシフトで座標が変化する画素の集りを、DL、DM、DR、画像EにおいてDIBRによるシフトで座標が変化する画素の集りを、EL、EM、ERとしている。これらの画素群は画像において"Ｖ"の形状をなしている。

左目用テクスチャの作成では、画像A〜Eを結合してDIBRを実行する。これにより左端部分の画素が、表示領域外になるから、図５（ａ）における画素集合BL,CL,DL,EL,FLを、隣接する画像である画像A,B,C,D,Eの右側の端部に追加する。この結果が、図５（ｂ）である。図５（ｂ）に示すように左目用テクスチャは、画素群AM,AR,BLを含む画像A(L)、画素群BM,BR,CLを含む画像B(L)、画素群CM,CR,DLからなる画像C(L)、画素群DM,DR.ELを含む画像D(L)、画素群EM,ER,FLを含む画像E(L)から構成されることになる。紙面上の都合から、図５では画像F、Gについては図示を省略しているが画像F、Gについても本図と同様の処理がなされる。

右目用テクスチャの作成では、画像A〜Eを結合してDIBRを実行する。これにより右端部分の画素が、表示領域外になるから、図５（ａ）における画素集合GR,AR,BR,CR,DRを、隣接する画像である画像A,B,C,D,Eの側の左側の端部に追加する。この結果が図５（ｃ）である。図５（ｃ）に示すように右目用テクスチャは、画素群GR,AL,Amを含む画像A(R)、画素群AR,BL,Bmを含む画像B(R)、画素群BR,CL,Cmからなる画像C(R)、画素群CR,DL,Dmを含む画像D(R)、画素群DR,EL,Emを含む画像E(R)から構成されることになる。

図６（ａ）は、図５（ｂ）の左シフト後の画素が球面内側に貼りつけられた場合のテクスチャを示す。図６（ｂ）は、図５（ｃ）の右シフト後の画素が球面内側に貼りつけられた場合のテクスチャを示す。

図７（ａ）は、図１の三次元モデリング空間において、左目用テクスチャ、右目用テクスチャと、ビューポートとの関係を示す。図７（ａ）は、左目用テクスチャの配置である。本図において、左目用カメラの視線ベクトルの先に、左目用テクスチャが配置され、左目用テクスチャが球面モデル内側に貼付けられる。これによりビューポートに該当する部分が表示に供されることになる。図７（ｂ）は、右目用テクスチャの配置である。本図において、右目用カメラの視線ベクトルの先に、右目用テクスチャが配置され、右目用テクスチャが球面モデル内側に貼付けられる。これによりビューポートに該当する部分が表示に供されることになる。

図８は、前景画像と、背景画像との合成を示す。（ａ）は、題材となる前景画像、これは近代的な教会を背にして新郎、新婦が向かい合っているという内容のスナップ写真である。この近代的な教会は、背景画像にも存在するので、教会の輪郭線形状は、前景画像及び背景画像の共通の特徴となる。図８（ｂ）は、前景画像と、背景画像とのマッチングを示す。かかるマッチングにより、背景画像、前景画像の対応関係を示す変換行列ができるから、かかる行列に従い、前景画像のデプス画像を変換した上でDIBRを行えば背景画像と違和感がない合成画像が得られることになる。

この図８の合成を前提として、追体験が可能になる。図９は、画面合成の一例を示す。視線vw１は、眼鏡１００３によって右目が遮光された場合の映像の入射を示す。視線vw2は、眼鏡１００３によって左目が遮光された場合の映像の入射を示す。このvw１により左目画像が視聴されることになる。またvw2により右目画像が視聴されることになる。眼鏡１００３を着用することによりユーザは、右目画像、左目画像を交互に視聴することになり、立体視画像が再生される。図９の画像は、変換行列に従いビューポートに得られた前景画像と、背景画像とを合成することで得られる立体視画像である。球面体内部に貼りつけられた複数の背景画像を背にして人物が表示されるので、臨場感が高い立体視映像が得られる。以上のように、写真のグローバル位置に合致した全周囲画像をサーバから取得すれば、その写真に合致した全周囲画像に写真を合成することができる。

またストリートビューには、UIオブジェクトを合成することができる。図１０は、UIオブジェクトが合成されたストリートビューを示す。方向ナビuiは、カレントの視線方向を視覚的に表示する。インディケータir1,ir2は、カレントの視点位置が存在する地名(loss-Less City
central park)や建造物の名称(CABAC church)を表す。十字ボタンbn2は、カレント視点位置を変更させる場合において、その進行方向の選択を受け付けるものである。ズームアップボタンbn3は、視点位置、視線方向をそのままにして、表示内容の拡大・縮小操作を受け付けるものである。アングルボタンbn4は、カレント視線方向の右旋回、左旋回の指定を受け付けるものである。これらのGUIは、リモコンのキーに割り当てられるので、リモコンに対する操作により、ストリートビューにおける移動、回転といった制御が可能になる。以上がグローバルビュー検索サービスについての説明である。

(実施の形態１)
実施の形態１は、前景画像である写真を、背景画像に合成するための改良に関する。実施形態１における映像提供装置の説明に先立ち、本実施形態の映像提供装置で実現すべきデータフローについて説明しておく。

図１１は、実施の形態１におけるデータフローの例を示す図である。このデータフローは、処理対象となる画像と、その処理の内容とを表すものである。本図では、データフローにおける個々の処理内容に、df1〜df9という参照符号を付している。この図１１のデータフローで特徴的なのは、写真についてのデプス画像生成に先立ち、全周囲画像９０Ｌと、写真データ６０Ｌとの特徴点マッチングdf7がなされていること、そして、写真画像６０Ｒ、６０Ｌに対するDIBRで得られたデプス画像に対して、マッチング結果に応じたデプス変換df9が施されていることである。以下、これらの参照符号に従い、映像提供装置におけるデータフローを説明する。

「SVに対するDIBR」df1は、全周囲画像９０Cとデプス画像９０Dとに対するDIBR処理であり、第二の全周囲画像９０Rを生成する。

「右目球面へのマッピング」df2は、DIBRにより得られた右目用テクスチャについてのテクスチャマッピングを行い、ビューポート変換を行って、右目ビューポート画像９０Ｒ'を得る処理である。

「右目SVと、右目写真との合成」df3は、DIBRで得られた右目ビューポート画像90R'と、写真の右目画像60Rとを合成して合成画像150Rを得る処理である。

「写真のDIBR」df4とは、写真デプス６０Dと、右目写真６０Rとに対してDIBR処理を行い、左目写真６０Ｌ'を得る処理である。

「左目球面へのマッピング」df5は、DIBRにより得られた左目用テクスチャ９０Lについてのテクスチャマッピングを行い、左目ビューポート画像９０Ｌ'を得る処理である。

「左目SVと、左目写真との合成」df6は、写真の左目画像60L'と、左目ビューポート画像90L'とを合成して、合成映像150Lを得る処理である。

以降のdf7〜df9は、本データフローにおいて特徴的な処理である。

「特徴点マッチング」df7は、全周囲画像９０Lと、左目写真６０Lとの間での特徴点マッチング処理である。

「デプス生成」df8とは、左目写真６０Lと右目写真６０Rとに対するデプス生成である。

「マッチングに応じたデプス画像生成」df9は、デプス生成df8で生成されたデプス画像に対して、マッチングに応じた変換を施すことで、写真デプス６０Dを生成するというものである。以上が実施形態１における映像提供装置のデータフローについての説明である。このデータフローを具現化するための映像提供装置の具体的な構成要素について説明する。

（映像提供装置の内部構成）
図１２は、実施の形態1における映像提供装置の内部構成を示す図である。本図に示すように、本図に示すように、映像提供装置はネットワークインターフェース１a、入力インタフェース１b、ビルトインメディア１c、ファイルシステム２、UOモジュール３、制御部４、描画部５、左目写真プレーンメモリ６a、右目写真プレーンメモリ６b、左目ビューポートメモリ７a、右目ビューポートメモリ７b、合成部８a,b、立体出力モジュール９から構成される。本図において、ドラム記号はストレージを意味し、菱形記号はメモリデバイスを意味する。

＜ネットワークインターフェース１a＞
ネットワークインターフェース１aは、映像提供装置の外部と通信を行うためのものであり、インターネットでアクセス可能なサーバにアクセスしたり、ローカルネットワークで接続されたサーバにアクセスしたりすることが可能である。たとえば、インターネット上に公開された追体験コンテンツのダウンロードに用いられたりすることができる。ネットワークインターフェース１aは、要求送信部、応答受信部を具備している。要求送信部は、地球上のカレント視点位置を指定した画像取得要求をグローバルビュー収集サーバ１００１に送信する。ここで要求送信部は、立体写真ファイルが読み出された際、入力インターフェース１bを通じて読み出された立体写真ファイル、及び、ビルドインメディア１cから読み出された立体写真ファイルに存在する地理的情報を用いてカレント視点位置を指定する画像取得要求を作成して、グローバルビュー収集サーバ１００１に送信する。

応答受信部は、画像取得要求に対する応答として、グローバルビュー収集サーバ１００１から送信されてくる立体ストリートビュー視点ファイルを受信する。グローバルビュー収集サーバ１００１から送信されてくる立体ストリートビュー視点ファイルは画像取得要求に含まれる地理的情報と合致する撮影地属性を有している。

＜入力インタフェース１b＞
入力インタフェース１bとは、たとえば可搬性を有する外部機器からの入力インタフェースであり、好適にはSDカードスロットおよびスロットに装着されたリムーバブルメディアから写真ファイルを読み取るためのメモリーカードI/Fである。スロットにSDカードなどのリムーバブルメディアを装着すると、リムーバブルメディアと映像提供装置とが電気的に接続され、メモリーカードI/Fを利用して、半導体メモリに記録されたデータを電気信号に変換して読み出すことが可能となる。

＜ビルトインメディア１c＞
ビルトインメディア１cは、例えば再生装置に内蔵されたハードディスクドライブ、メモリなどの書き込み可能な記録媒体であり、立体ストリートビュー視点ファイル、立体視写真ファイルが蓄積される。

＜ファイルシステム２＞
ファイルシステム２は、ネットワークインターフェース１aを通じた通信および、入力インタフェース１bを通じた読み書きおよび、ビルトインメディア１cへの読み書きの制御を行う。また、入力インタフェース１bなどのメディア装脱通知を行う。特にファイルシステム２は読出部を含み、入力インターフェース１bを通じて立体写真ファイルを読み出したり、ビルドインメディア１cから立体写真ファイルを読み出す。

＜UOモジュール３＞
UOモジュール３は、GUIに対するユーザオペレーションを受け付ける。好適には赤外線リモコンを受信するためのモジュールである。

＜制御部４＞
制御部４は、GUI画面に対するユーザ操作に応じて、描画部の制御を行う。ユーザにとって身近なGUI画面の局面から制御部４による制御内容を補足する。図１３（ａ）は、実施の形態１における制御部４による追体験GUIを示す図である。追体験GUIは、ファイルの一覧表示３０２のそれぞれに、記録日付(Date)３０３と、チェックボックス３０１とを対応付けたものである。本図では、Photo1,mpo,Phto2.mpo,Phto3.mpo,Photo6.mpoといった複数のファイルがサムネールに対応付けられて一覧表示に供されている。これらには、撮影日付(2011/2/12 10:22,2011/2/12 10:25)と、チェックボックス３０１とが対応付けられていて、チェックボックスでチェックされたものが追体験の対象になる。チェックボックスは、立体視写真ファイルに対するスライドショー要否を指定するものである。このGUIの下側には、スライドショーの開始指示を受け付けるためのボタン３０４が存在する。

図１３（ｂ）は、スライドショーにおける個々の表示を示す。この表示では、グローバルビュー収集サーバから取得した全周囲画像を背景にして、写真４０２が表示されることがわかる。本図において、サムネールsn1,sn2,sn3,sn4は、追体験機能において、表示が可能な写真を一覧させるものである。スキップボタンsk1は、前後の写真に合成の対象を切り替える操作を受け付けるものである。以上のGUI画面に従い、描画部５に対して描画制御を行うことで、制御部４は対話的な操作環境を実現する。以上が制御部４についての説明である。

＜描画部５＞
描画部５は、制御部４の制御に応じて、ファイルシステム２からデータを読み取り、写真プレーンメモリ６a,bおよびビューポートメモリ７a,bへ描画を行う。

＜左目写真プレーンメモリ６a＞
左目写真メモリ６aは、左目用の写真画像を格納するメモリである。

＜右目写真プレーンメモリ６b＞
右目写真メモリ６bは、右目用の写真画像を格納するメモリである。

＜左目ビューポートメモリ７a＞
左目ビューポートメモリ７aは、左目用のビューポート画像を格納するメモリである。

＜右目ビューポートメモリ７b＞
右目ビューポートメモリ７bは、右目用のビューポート画像を格納するメモリである。

＜合成部８a,b＞
合成部８a,bは、左目ビューポートメモリの格納内容と、左目写真メモリの格納内容とを合成し、右目ビューポートメモリの格納内容と、右目写真メモリの格納内容とを合成する。

＜立体出力モジュール９＞
立体出力モジュール９は、合成部８a,bによりレイヤ合成がなされたメモリの格納内容を表示装置（図示せず）へ出力する。好適にはHDMI1.4トランスミッタおよびHDMI出力コネクタである。

以上が映像提供装置の全体構成の説明である。以上の構成要素のうち描画部５は、映像提供装置の中核をなす構成であり、本実施形態で特に重要な役割を担う。この描画部５の内部構成に焦点をあてて、描画部の内部構成を更に詳しく説明する。

図１２に示すように、描画部は、立体写真管理モジュール１１、写真デコーダ１２、写真メモリ１３a,b、写真デプス生成器１４、写真デプスメモリ１５、立体SV管理モジュール１６、SVデコーダ１７、SVメモリ１８、SVデプスデコーダ１９、SVデプスメモリ２０、SVDIBR部２１、テクスチャメモリ２２a,b、写真特徴点抽出器２３、SV特徴点抽出器２４、立体マッチングモジュール２５、デプス変換部２６、写真デプスバッファ２７、写真DIBR部２８、CG処理部３０(頂点処理部３１、レンダリング処理部３２、テクスチャマッピング処理部３３、画素処理部３４を含む)から構成される。

＜立体写真管理モジュール１１＞
立体写真管理モジュール１１はファイルシステム２から立体写真ファイルを読み取り、解析を行う。

＜写真デコーダ１２＞
写真デコーダ１２は、JPEGデコーダであり、立体写真ファイルに含まれる圧縮左目画像５０４と圧縮右目画像５０５の展開を行う。処理対象のデータ構造の局面から写真デコーダ１２の処理内容を補足する。デコードの対象となる立体視対応の写真データは、MPOファイルに格納されている。MPO(Multi picture object)ファイルとは、任天堂株式会社の3DS、富士フィルム FinePix REAL 3D W1およびW3カメラにより撮影可能なファイルであり、JPEGファイルを2つの格納する。図１４（ａ）は、立体写真ファイルのデータ構造を示す。図１４（ａ）は、実施の形態１における立体写真ファイル５０１のデータ構造およびデータ例を示す図である。立体写真ファイルは撮影日５０２、サイズ５０３、圧縮左目画像５０４、圧縮右目画像５０５を含み、また撮影地に関する地理的情報として地理的緯度５０６、経度５０７、標高５０８、方角５０９、傾斜５１０のデータを有する。撮影日５０２は、撮影が行われた日付を示す。サイズ５０３は、画像の縦と横のサイズを示す。圧縮左目画像５０４は、JPEG形式で圧縮されたデータである。圧縮右目画像５０５は、JPEG形式で圧縮されたデータである。地理的情報である緯度５０６、経度５０７、標高５０８は撮影したときの位置を示す。方角５０９、傾斜５１０は撮影したときの方向を示す。撮影のための立体カメラは二つのレンズを備え、左側のレンズと右側のレンズよりそれぞれ左目画像の例６Lと右目画像の例６Rを圧縮してさらに付加情報をつけて立体写真ファイルとして記録する。本図に示すように、撮影地の緯度、経度、標高、方角を示すので、これらを用いれば、背景画像である全周囲画像とのマッチングを正しく行うことができる。図１４（ｂ）は、JPEG圧縮された左目画像データ、右目画像データを示す。このような厳密なマッチングが可能な立体写真ファイルを写真デコーダ１２はデコード対象にすることができる。以上が写真デコーダ１２についての説明である。

＜左目写真メモリ１３a,右目写真メモリ１３b＞
右目写真メモリ１３a、左目写真メモリ１３bのペアは、写真デコーダ１２より展開された左目画像と右目画像とを格納する。

＜スイッチ１３ｃ＞
スイッチ１３ｃは、写真メモリ１３a,bのうち、基点画像となるものを写真DIBR実行部２８に出力する。

＜写真デプス生成器１４＞
写真デプス生成器１４は写真デコーダ１２より展開された左目画像および右目画像を解析し、デプス画像を生成する。図１４（ｃ）は、図１４（ｂ）における左目画像の例６０Lと右目画像の例６０Rから生成されるデプス画像を示す。奥行きは輝度であらわされ、色が薄くなるにつれてピクセルが近いことを意味する。黒色はある閾値より遠い、白色はある閾値より近い距離を示す。

＜写真デプスメモリ１５＞
写真デプスメモリ１５は、写真デプス生成器１４より生成されたデプス画像を格納するメモリである。

＜立体SV管理モジュール１６＞
立体SV管理モジュール１６はファイルシステム２から立体ストリートビュー視点ファイルを読み取り、解析を行う。

＜SVデコーダ１７＞
SVデコーダ１７はJPEGデコーダであり、立体ストリートビュー視点ファイルに格納された圧縮メルカトル画像８０２の展開を行い、当該展開で得られた非圧縮の全周囲画像データをSVメモリ１９に格納する。立体ストリートビュー視点ファイルとは、地球上の任意の地点での視点を再現するファイルであり、地球上のその視点における撮影地属性に、全周囲画像である圧縮メルカトル画像と、対応するデプス画像である圧縮メルカトルデプスとを対応付けたファイルである。ここでの撮影地属性とは、緯度、経度、標高、方角、傾斜である。処理対象のデータ構造の局面からSVデコーダ１７の処理内容を補足する。図１５は、実施の形態１における立体ストリートビュー視点ファイルのデータ構造およびデータ例を示す。図１５において、立体ストリートビュー視点ファイルに格納されている圧縮メルカトル画像は、メルカトル図法により作成された全周囲画像をJPEG形式で圧縮符号化したデータであり、これをデコードすることにより全周囲画像が得られる。図１５（ａ）は、立体視ストリートビュー視点ファイルのデータ構造を示す。立体視ストリートビュー視点ファイルは、立体写真ファイルと共通のデータ構造をもっているので、ある写真に最適な立体視ストリートビュー視点ファイルを検索する際、データベースに存在する立体ストリートビュー視点ファイルのうち、撮影地属性として同一の緯度、経度、標高をもつものサーチすれば、立体写真ファイルに整合する立体視ストリートビュー視点ファイルを早期に発見することができる。このようなサーチで発見された立体ストリートビュー視点ファイル内の全周囲画像が、SVデコーダ１７によるデコードの対象である。図１５（ｂ）は実施の形態１における立体視ストリートビュー視点ファイル８０１に格納されている圧縮メルカトルデプス８０２の一例を示す図である。全周囲画像９０Cは全方位から撮影し、メルカトル図法により作成された画像である。以上のように、全周囲画像(メルカトル画像)は、立体ストリートビュー視点ファイルに格納され、ストリートビューという単位で扱われるから、本明細書では、全周囲画像(メルカトル画像)を"ストリートビュー(SV)"と総称するものとする。以上がSVデコーダ１７についての説明である。

＜SVメモリ１８＞
SVメモリ１８は、SVデコーダ１７より展開された全周囲画像５１１を格納するメモリである。

＜SVデプスデコーダ１９＞
SVデプスデコーダ１９は、PNGデコーダであり、立体視ストリートビュー視点ファイル８０１に含まれる圧縮メルカトルデプス８０３の展開を行いSVデプスメモリ２０に格納する。図１５（ｃ）は、デプス画像９０Dの一例を示す。デプス画像９０Dは全周囲画像９０Cに対する奥行きを示す画像である。奥行きは輝度であらわされ、明るくなるにつれてピクセルが撮影場所に近いことを意味する。黒色は無限遠、白色は撮影場所（距離ゼロ）を示す。

＜SVデプスメモリ２０＞
SVデプスメモリ２０は、SVデプスデコーダ１９のデコードで得られた非圧縮のデプス画像を格納するメモリである。

＜ストリートビューDIBR実行部２１＞
ストリートビューDIBR実行部２１は、デプス画像をベースにしたDIBR処理を、全周囲画像に対して施し、他視点の全周囲画像を生成する。DIBR（Depth Image Based Rendering、もしくはDepth Image
Based Representations）とは、デプス画像（デプスマップ）を元に、ベース画像から各画素を左右にシフトして他の視点からの視点画像を生み出す処理のことである。ベースの全周囲画像を左目用に割り当てる場合、生成する視差画像（すなわち右目用の画像）上の画素は、ベースの画素に対し右にシフトすれば、3D空間上で奥側に移動し、ベースの画素に対し左にシフトすれば、3D空間上で手前に移動することになる。これは、いわゆる人間の目の輻輳角の差によって生み出される立体知覚によるものであり、ベースの左目画像に対し、右目画像上の画素を左にシフトすると輻輳角が小さくなり、いわゆる寄り目状態となるため、その画素で表現される物体が手前に位置するように知覚される。反対に、ベースの左目画像に対し、右目画像上の画素を右にシフトすると輻輳角が大きくなり、その画素で表現される物体が奥に位置するように知覚される。よって、デプス画像で示される各画素の奥行き値に応じ、ベースの左目画像の各画素を左右にシフトすれば、対応する立体視可能な右目画像を生成することができる。

＜左目テクスチャメモリ２２a,右目テクスチャメモリ２２b＞
右目テクスチャメモリ２２a、左目テクスチャメモリ２２bのペアは、ストリートビューDIBR実行部２１がDIBRを行うことで得られた左目テクスチャと、右目テクスチャとを格納する。

＜写真特徴点抽出器２３＞
写真特徴点抽出器２３は、左目写真メモリ１３aに格納された写真データ、及び、右目写真メモリ１３bに格納された写真データから特徴点の抽出を行い、特徴点７０１の生成を行う。

＜SV特徴点抽出器２４＞
SV特徴点抽出器２４は写真特徴点抽出器２３と同様に、全周囲画像の特徴点抽出を行った後、デプス画像でのデプス探索レンジによる特徴点の除外を行い、その後、残った特徴点を利用して全周囲画像データと、写真データとのマッチングを行う。マッチングの結果、立体写真と全周囲画像データとの立体的な関係を示す変換行列を導く。

＜立体マッチングモジュール２５＞
立体マッチングモジュール２５は、写真特徴点抽出器２３より生成された特徴点７０１と、SV特徴点抽出器２４より生成された特徴点７０１とのマッチングを行い、立体写真と、ストリートビューである全周囲画像との立体的な相対位置関係を表す変換行列の生成を行う。

＜デプス変換部２６＞
デプス変換部２６は、立体マッチングモジュール２５が得た変換行列を用いて、写真デプスメモリ１５に格納された写真デプスを変換して、変換後の写真デプスを写真デプスバッファ２７に書き込む。

＜写真デプスバッファ２７＞
写真デプスバッファ２７には、デプス変換部２６による変換が施された写真デプスが格納される。

＜写真DIBR実行部２８＞
写真DIBR実行部２８は、写真メモリ１３a,bに格納された写真のうち、スイッチ１３ｃによって選択されたもの(基点画像)に対して、写真デプスをベースにしたDIBRを施す。その処理結果となる左目写真データ、右目写真データを左目写真プレーンメモリ６a、右目写真プレーンメモリ６bに書き込む。

＜CG処理部３０＞
CG処理部３０は、モデリングデータを構成する三次元座標を三次元モデリング空間に配置して、その三次元モデリング空間における三次元座標をビューポートに投影する処理を行う。かかる処理には、座標・視野変換、照度計算(テクスチャマッピング処理)、ビューポート処理がある
＜座標変換部３１＞
座標変換部３１は、視点をカメラにし、カメラの方向やズームレベルを指定することにより、立体物を投影するスクリーンを決定する。その後、球面モデルのモデリングデータを規定する三次元座標を三次元モデリング空間におけるワールド座標に変換する。ここでの座標変換は、三次元モデリング空間におけるカメラ位置を原点とし、カメラから見た座標系でのワールド座標に、モデリングデータを規定する三次元座標を変換するというものである。

＜照度計算部３２＞
照度計算部３２は、三次元モデリング空間において設定された光源位置から照射される光を立体物に当てたときの各頂点における照度の計算を行う。

＜テクスチャマッピング部３３＞
テクスチャマッピング部３３は、三次元モデリング空間上に左目用と右目用の２つの球体を用意し、背景画像を変換することで得られた2以上の左目用テクスチャ、右目用テクスチャを三次元モデリング空間における球体モデルの内側表面にマッピングする。

＜ビューポート変換部３４＞
ビューポート変換部３４は、ディスプレイの解像度等を含んだディスプレイ情報に従い、三次元モデリング空間における3次元座標の頂点座標を2次元のスクリーン座標に変換することでビューポート画像の抽出を行う。抽出される画像には、左目ビューポート画像、右目ビューポート画像があり、ビューポート変換部はこれらを、それぞれ左目プレーンメモリ６、右目プレーンメモリ７に出力する。位置方向判定部２から描画制御部５に行われる指示が、カレント視点位置に変化はなく、カレント視線方向のみの変化であった場合、テクスチャマッピング部はテクスチャマッピング処理をスキップし、ビューポート変換部のみがカレント視線方向変化に伴うビューポートの再抽出及びプレーンメモリへの再出力のみを行う。

以上が映像提供装置の内部構成についての説明である。これで、映像提供装置の内部構成の説明を終える。内部構成図に示した構成要素のうち写真特徴点抽出器２３、SV特徴点抽出器２４、立体マッチングモジュール２５は、本願のために新規に創作した構成要素であり、上記技術的課題の解決のための工夫が存在する。これら新規の構成要素以外は、既存のデジタル家電機器としての機能を担保するための一般的要素に過ぎない。以降、新規に創作した構成要素(写真特徴点抽出器２３、SV特徴点抽出器２４、立体マッチングモジュール２５)を詳細に説明する。以下の詳細解説は、上記の構成要素の説明に具体的な画像の例を当てはめたものである。

＜マッチングに用いるべき特徴点＞
写真特徴点抽出器２３、SV特徴点抽出器２４が抽出すべき特徴点について説明する。

撮影時期が大きく異なる、立体写真と、全周囲画像とのマッチングを行う場合、できるだけ時期が異なっても不変な特徴点を使ってマッチングをする。特徴点を構成する画素は、明暗分布をなしている。この明暗分布の中心をなす輝度が、予め定められた許容レンジ(デプス探索レンジ)の範囲内であるか範囲外であるかによって、特徴点をマッチングの対象とするかどうかを決める。レンジの外に、明暗分布の中心をもつ特徴点は、マッチングから除外すべきである。例えば、背景画像のうち無限遠を表すような画素は、その輝度が0に近いものになる。かかる特徴点は、その輝度が0に近いものになり、かかる明暗分布の中心は、デプス探索レンジのレンジ外になるから、特徴点算出から除外する。こうすることでマッチングの精度を高めることができる。

立体写真において、距離が近すぎるものは多くの場合は立体写真の対象となる人物などであることが多い。また、距離が遠すぎるものは多くの場合は空などであることが多い。近すぎず、遠すぎず、画素における明暗分布の中心がデプス探索レンジ内に収まる特徴点だけを使うことで、より正確なマッチングを行うことが可能である。

たとえば上記の写真デプス画像60Dの例においては、近くにある人物や、遠くにある空を除外し、建物や地面による正確なマッチングを行うことができる。

顔認識技術を応用することも可能である。たとえば、人物の顔を認識して、その顔の特徴点をレンジとし、顔より近い部分をレンジ外に設定する。こうすることで、顔に近い部分の特徴点はマッチングから排除されることになり、精度を上げることができる。また、特徴点の中心だけに限定して比較を行ったのは、コンピューティングパワーを重視したためである。

特徴量抽出は特にコンピューティングパワーを必要とする処理であり、左目画像・右目画像のどちらかひとつだけで処理することにより処理全体の時間を短縮し、ユーザに画像を出力するまでの応答時間を短縮することができる。また、左側で撮影された場合に立体ストリートビュー視点に最も近い画像は右目画像であり、右目画像を基点に特徴量およびデプスを生成することにより精度を上げることができる。また、基点となる画像を先にデコードすることにより、特徴量抽出している間にデコードに使われるハードウェアリソースを基点ではない画像のデコードに使うことができ、並列処理により高速化に期待できる。

精度を上げるためには特徴点の半径を考慮した式を用いた平準化式によりデプス画像を平準化することもできる。この平準化式は、特徴点の面積全体での中心との距離に応じて明暗分布を変化させるものである。こうして、平準化されたデプス画像をデプス探索レンジにすれば、マッチングに適した特徴点を選び抜くことができる。以上がマッチングに用いる特徴点についての説明である。続いて、特徴点記述子の詳細について説明する。

＜特徴点記述子＞
写真特徴点抽出器２３、SV特徴点抽出器２４による抽出結果として出力される特徴点記述子について説明する。

図１６（ａ）は、デプス画像中に現れた家屋を拡大して示している。本図では家屋の正面の部分、側面の部分、窓の部分のそれぞれが異なる輝度を有しており、これらの輝度の違いを異なるハッチングパターンで示している。かかるデプス画像において、輝度変化が大きい場所、つまり家屋の輪郭線にあたる部分から特徴点が抽出されることになる。図中の丸記号は、特徴点として抽出される画素の集りを示す。特徴点抽出の結果は、特徴点記述子によって表現される。図１６（ｂ）は、実施の形態１における特徴量記述子７０１のデータ構造およびデータ例を示す図である。特徴量記述子７０１は中心７０２、半径７０３、方向７０４、特徴量７０５のデータから構成される。中心７０２は特徴量記述子７０１が対象となる画像における相対的な中心点を示す。半径７０３は特徴量記述子７０１が対象となる画像における相対的な半径を示す。方向７０４は特徴量記述子７０１が対象となる画像においてスペクトル分布がどういう方向を向いているかを示す。特徴量７０５は、特徴点の値を示す。特徴量は複数の画像で探索することにより、似ている画像を導くことができる。

以上が写真特徴点抽出器２３、SV特徴点抽出器２４として実装すべき特徴点抽出処理の詳細な解説である。続いて、立体マッチングモジュール２５として実装すべき処理の詳細解説を行う
立体マッチングモジュール２５が写真と、背景画像とのマッチングをどのように行うかについて説明する。以降の説明では、図１７に示すような背景A、写真Bを用いる。図１７は、特徴マッチングの対象となる写真、背景画像の一例である。本図における背景A、写真Bは、パリの凱旋門前の光景を撮影したものであり、撮影された日時は違うものだが、写り込んでいる店舗の建造物は同一物である。このように、同一建造物が存在するので、背景A、写真Bについては、回転・移動を伴う変換を写真に対して施すことにより、写真Bを背景Aに整合するものに変化させることができる。この回転・移動は、背景A、写真Bにおける特徴点を整合させることでなされる。

特徴点は、円状の画素の集合体として画像上に現れる。図１８（ａ）は、特徴点の一例を示す。これらの背景A、写真Bの特徴点のうち、背景Aにおける特徴点F1と、写真Bにおける特徴点f1、背景Aにおける特徴点F2と、写真Bにおける特徴点f2、背景Aにおける特徴点F3と、写真Bにおける特徴点f3がそれぞれ、もっとも類似性が高いものとする。こうすることで、背景Aと、写真Bとについて特徴点のペアを求めることができる。既存アルゴリズムを使って各々の特徴点を出した後、最小二乗法により特徴点ペアを見つける。そして写真Bを矩形Cに変形するような行列Hを求める。

図１８（ｂ）は、立体マッチングモジュール２５が写真Bを背景Aに当てはめるにあたっての変形の過程と、その結果とを示す。図１８（ｂ）の左側は、変形の過程である。下側の背景Aにおける矩形Ｃの枠は、上側の写真Bを下側の背景Aに当てはめるにあたって、背景Aのどのような位置・形状に、変形させればよいかという変形の基準を示す。本図に示すように、写真Bを背景Aに当てはめるには、矩形Ｃの枠の形状に、写真Bを変形させればよい。互いに整合し合う特徴点ペアが3つ以上あれば、上記回転・移動を可能とする行列、即ち、ホモグラフィ行列Ｈが求まる。

このような変形を経て、写真Bが当てはめられた結果が、図１８（ｂ）の右側である。ここで、写真Bは、ホモグラフィ行列Hにより,矩形Ｃで囲まれる平面
に投影される。

その後、写真BのデプスマップMfに対し、ホモグラフィ行列Hによる射影を行いMf 'を得る。こうすることで、背景Aに投影した後の写真Ｂのデプスを求めることができる。

ホモグラフィ行列について説明する。例えば、三次元モデリング空間上のある点Q(X,Y,Z)が何らかの平面上にあるとする。そして、それを別の平面へ投影し、その点がq(x,y)である場合、qと、Qとの間には以下の数２の数式の関係が成立する。

ここで、上記数式において「s」はスケール係数であり、「H」はホモグラフィ行列
である。以下、ホモグラフィ行列について説明する。ホモグラフィ行列は「回転、並行移動」の要素、「投影変換」の要素という2つの要素から成り立つ。

ここで、回転・並行の要素をもつ行列を「W = [Rt]」投影変換の要素をもつ行列をM（カメラの内部行列）とすると、以下の数３の数式が成立する。

ストリートビューについては、マッチングがなされた特徴点のZ座標として、デプス画像における対応画素の奥行きTfを使用することができる。このTfをz座標として「課題を解決するための手段」の爛に示した数１の数式に適用すれば、これらの数式を満たす行列Hを導き出すことができる。

具体的には、写真Ｂ上のある特徴点f(xf , yf)と、特徴点fに対応する背景A上の特徴点F(XF,YF) 及び、特徴点(XF,YF)に対応するデプス値ZFを上記数１の数式に適用することで行列Hを導きだす。変換行列の生成は、OpenCVにおけるリファレンスの1つである、cvFindHomography() を利用することができる。関数 cvFindHomography は，2枚の画像間の射影変換行列 H=||hij|| を求める。API呼び出しの書式は以下の通りである。

void cvFindHomography( const CvMat* src#points,
const CvMat* dst#points,
CvMat* homography );
第１引数であるsrc#pointsは、1枚目の画像上の座標を示す。第２引数であるdst#pointsは、2枚目の画像上の座標を示す。homographyは、戻り値として出力される3×3ホモグラフィ行列（平面射影変換行列）である。以上が変換行列についての説明である。続いて、デプス画像の詳細について説明する。

デプス画像における各画素の輝度は通常、８ビットで表現され、一ピクセルに対して０（最も遠い）〜２５５（最も近い）の範囲内のデプスが与えられる。マッチングの対象となる特徴点は、上限、下限、上限及び下限の何れかを切り捨て、残った範囲のデプスを持つピクセルを中心とする特徴点に限定することでなされる。上限及び下限を対象とした場合、０と２５５を切り捨て、１〜２５４の間のデプスを持つピクセルを中心とする特徴点を、マッチング範囲として限定する。これによりマッチング精度を上げることができる。

立体マッチングモジュール２５による処理結果として、デプス画像のマッピングがどのようになされるかを説明する。図１９は、デプス画像のマッピングの概念を模式的に示す図である。写真のデプス画像は、８ビット、０〜２５５の間の値により表現される。SVデプスは８ビット、０〜２５５の間の値により表現される。マッチングに利用された特徴点のデプスを元に、全体のデプスのマッピングを行う。これは、DIBRで行われるピクセルのシフト量を抑制するためである。

図１９（ａ）は、前景画像である写真データのデプス画像と、背景画像である全周囲画像データのデプス画像とを示す。これら2つのデプス画像は、マッピング対象になる。図中のハッチングは、奥行きの範囲である。これらのうち、菱型の範囲、丸の範囲、四角形の範囲は、建造物がなす奥行きの範囲である。前景画像と、背景画像とでは、建造物がなす奥行きの範囲がそれぞれ異なっている。これら前景画像のデプス画像に対して、上記ホモグラフィ行列による変換がなされると、図１９（ａ）の下段のようなマッピング結果が得られる。背景画像の菱形の範囲と、前景画像の菱形の範囲とは大体同じになり、また、背景画像の丸の範囲と、前景画像の丸の範囲とが大体同じ、背景画像の四角形の範囲と、前景画像の四角形の範囲とが同じになっていることがわかる。以上のようなマッチング結果に基づく変換で、背景画像に現れた建造物の輝度範囲と、前景画像に現れた建造物の輝度範囲とは、大体同じになり、背景画像と、前景画像とを合成した際の違和感は解消される。

図１９（ａ）下段の右側は、安全ガイドラインを示す。奥行き範囲におけるスケール全体のうち、上限及び下限を除いた中間部分が、安全ガイドラインに定められた奥行きとなる。この安全ガイドラインに従った補正により、菱型よりも上の部分、四角形よりも下の部分が除外されることになる。

図１９（ｂ）は、マッチング結果を考慮した背景画像と、前景画像とのレンダリングの過程を示す。上段は、写真のデプス画像であり、人物像の部分の奥行きが3の輝度になっている。中段は、写真であり、個人写真、背景画像のそれぞれの部分を奥行きを示している。ここで、個人写真の奥行きは3であり、建物の奥行きは2、空の奥行きはー3である。上記の奥行き範囲のマッピングにより、0〜ー3の部分は除外され、+3〜0の部分がストリートビューの奥行きとして有効化される。ここで、+3の奥行きをもつ人物の部分は、ストリートビューには存在しないからこの人物の特徴点は、ストリートビューの特徴点とのマッチングには用いられない。ー3の奥行きをもつ背景は、ストリートビューに存在するが、この部分の奥行きは、変換で除外されているため、ストリートビューの特徴点とのマッチングには用いられない。2の奥行きをもつ建造物は、ストリートビューにも写真にも存在するので移動、回転、拡縮を通じて写真の構造物が背景画像の構造物に合致するようにホモグラフィ変換を施す。

この変換を示す変換行列を得て、写真のデプス画像を変換した上、写真についてのDIBRを実行すれば、図１９（ｂ）の下段のような合成映像が得られる。

写真に対応するデプス画像を全周囲画像に対応するデプス画像に射影した上、DIBRを行っているので、画素シフト量が極端にならず、見苦しい立体視画像が作られることはない。3D座標系の演算が発生しないので描画の高速化及び省ハードウェア化を図ることができる。

＜CPU上での動作を前提としたソフトウェア実装＞
本実施形態に係る映像提供装置は、上述したような映像提供装置における各構成要素を、ASIC等のハードウェア集積素子で具現化することで工業的に生産することができる。このハードウェア集積素子に、CPU、コードROM、RAMといった汎用的なコンピュータシステムのアーキテクチャを採用する場合、上述したような各構成要素の処理手順をコンピュータコードで記述したプログラムをコードROMに予め組みこんでおき、ハードウェア集積素子内のCPUに、このプログラムの処理手順を実行させねばならない。

汎用的なコンピュータシステムのアーキテクチャを採用する場合、ソフトウェア実装で必要となる処理手順について説明する。図２０は、追体験処理のフローチャートである。本フローチャートは、最上位の処理、つまり、メインルーチンに該当するものであり、本フローチャートの下位のフローチャートとして、図２１、図２２のフローチャートが存在する。以下、メインルーチンにおける処理手順について説明する。

ステップＳ１において写真ファイルのサムネールを一覧表示し、ステップＳ２、ステップＳ３のループに移行する。ステップＳ２は、チェックボックスに表示指定がなされたかの判定であり、表示指定がなされれば、表示指定がされた写真をスライドショーの対象にして(ステップＳ４)、ステップＳ２、ステップＳ３のループに戻る。

ステップＳ３は、スライドショー開始指示がなされたかどうかの判定である。ここでは、ユーザが「Start
Slideshow」ボタンを押下するまで待機する。「Start Slideshow」ボタンの押下がなされれば、ユーザにより選択された立体画像ごとにステップＳ５ーステップＳ６のループを行う。以降、ステップＳ５−ステップＳ６のループを実行する。このループは、スライドショーの対象になる写真のそれぞれについて、ステップＳ７〜ステップＳ１３の処理を実行するというものである。

ステップＳ７において、スライドショーの対象となる立体写真ファイルに存在する地理的情報（緯度、経度、標高、方角）を用いて画像の取得要求を作成し、かかる取得要求をグローバルビュー収集サーバ１００１に送信する。ステップＳ８において、送信した取得要求に対応する応答として送信される立体ストリートビュー視点ファイルの受信待ちを行い、かかる立体ストリートビュー視点ファイルを受信すれば、ステップＳ９において、写真及びストリートビューについての特徴点抽出を行う。ステップＳ１０では、写真及びストリートビューのマッチング及びデプス画像変換を実行する。ステップＳ１１では、写真のデプス画像及びストリートビューのデプス画像の個々の画素の奥行きに応じたシフト量で写真及びストリートビューに対するDIBRを実行する。その後、ステップＳ１２で待機時間の経過待ちを行い、ステップＳ１３では脱通知がなされたかどうかを判定する。脱通知がなされなければステップＳ６に移行して次の写真についての処理を行う。ステップＳ１３がYesであれば、ステップＳ５−ステップＳ６のループを抜ける。

図２１は、写真及びストリートビューの特徴点抽出手順を示すフローチャートである。

まず対象の立体写真を取得し解析を行う（ステップS２１）。立体写真の緯度と経度と最も近い立体ストリートビュー視点を取得し解析を行う（ステップS２２）。立体写真と立体ストリートビュー視点の相対関係を比較（ステップS２３）し、右側で撮影されたのか、左側で撮影されたのかを判断する（ステップS２４）。具体的に立体ストリートビュー視点の位置から立体写真の位置への方角から、立体写真ファイルの方角を引き算した値が１８０度〜３６０度の間であれば、左側で撮影され、値が０度〜１８０度の間であれば右側で撮影されたと判断できる。

左側で撮影されたと判断した場合、右目画像を先にデコード（ステップS２５）し、特徴点を抽出（ステップS２６）する。その後左目画像をデコード（ステップS２７）し、左目画像を基点に写真デプス生成（ステップS２８）を行う。

右側で撮影されたと判断した場合、左目画像を先にデコード（ステップS２９）し、特徴点を抽出（ステップS３０）する。その後右目画像をデコード（ステップS３１）し、右目画像を基点に写真デプス生成（ステップS３２）を行い、デプス探索レンジを確定する(ステップS３３)。その後、基点となる写真から1つ以上の特徴点を抽出して(ステップS３４)、ステップＳ３５〜ステップＳ３６のループを実行する。このループは、基点となる写真における全ての特徴点について、ステップＳ３７−ステップＳ３８の処理を繰り返すものである。ステップＳ３７は、対象となる特徴点の中心となるデプスが、デプス探索レンジの範囲内かどうかの判定であり、もしそうであれば、ステップＳ３８において、対象となる特徴点を除外する。これにより後段のマッチングで利用しないようにする。

図２２は、写真及びストリートビューについてのマッチング及びデプス画像変換の処理手順を示すフローチャートである。ステップＳ５１では、背景Ａと写真Bとに対して既存アルゴリズムを使用して特徴点デプス画像を抽出し、ステップＳ５２において最小二乗法により背景Aと、写真Bとで特徴点のペアをサーチする。ステップＳ５３では、写真Ｂを表す平面を矩形Ｃで囲まれる平面に投影するにあたって、写真Ｂを矩形Ｃに変形するようなホモグラフィ行列を求める。ステップＳ５４では、最大値と最低値の視差が大きく、輻輳角のディスパリティが大きくなりすぎないように、安全領域に収まるようにデプス画像の補正を行う。ステップＳ５５では、写真Bのデプス画像Mfに対してホモグラフィ行列Hによる射影を行うことで投影後の写真のデプスMf'を得る。

マッチングの結果、マッチングに利用された特徴点および、立体写真と立体ストリートビュー視点の立体的な関係を示す変換行列が導かれる。

以上のように本実施形態によれば、マッチングがなされた特徴点のデプスを活用しデプスのマッピングを確定することにより、立体表示をしても違和感のない奥行きによって、立体ストリートビュー視点ファイルにおける全周囲画像と、立体写真ファイルにおける前景画像との合成映像を再生することができる。

また、全体のデプスを抑制することで、違和感のない奥行き間を維持しながら、長時間視聴しても疲れない立体視表示をすることが可能である。更に、デプスと画像を射影した状態でDIBR処理をすることで、立体視表示をしても立体感が強すぎることなく、立体写真を鑑賞することが可能である。

(実施の形態２)
本実施形態は、これまでの実施形態で述べた映像提供装置をどのようなハードウェア構成で実現するかを開示する。

まず初めに、CG処理部についてのハードウェア構成を説明する。図２３は、CG処理部のハードウェア構成を示す。本図に示すように映像提供装置は、インターフェイス２０１、ビデオデコーダ回路２０２、テクスチャメモリ２０３、コードROM２０４、CPU２０５、ワークメモリ２０６、GPU２０７、フレームメモリ２０８から構成される。

インターフェイス２０１は、ビルドインメディアやリムーバブルメディアのドライブとのインターフェイスである。

ビデオデコーダ２０２は、インターフェイス２０１を通じて読み出された背景画像やデプス画像をデコードする専用回路である。

テクスチャメモリ２０３は、ビデオデコーダ回路２０２のデコードで得られた非圧縮の背景画像を格納する。

コードROM２０４は、これまでのフローチャートで述べたプログラムを構成するコード列を格納している。

CPU２０５は、コードROM２０４に格納されたコード列を読み出し、処理することで、これまでの実施形態で述べた処理を実現する。

ワークメモリ２０６は、コードROM２０４が処理を行う際に、変数や配列の格納場所として使用される。

GPU２０７は、テクスチャマッピング等のグラフィクス処理のための専用処理回路である。

フレームメモリ２０８は、GPU２０７が処理のために使用するメモリである。

図２４は、GPUの内部構成を示す図である。

Xステージボード８００は、X（Transformation, Xformation)ステージでの処理を実現するものであり、HIP８０１、GED８０２、ディスプレイリストキャッシュ８０３、SIMDチップ８０４a,b,c,dを具備している。X（Transformation）ステージの処理は、おおまかに言うと二つある。一つは、三次元の各頂点データ(x, y, z)を二次元のスクリーン座標に変換する処理、二つ目は、各頂点に関して、光源や材質情報をもとに明るさ（色）を計算する照光（lighting）計算処理である。この二つ（Transformation and
Lighting）の処理を総称してT&L 処理あるいはTnL
処理と呼ぶ。

HIP（Host Interface Processor）８０１は、入力のOpenGLAPIコールを解釈して演算処理に適した形式に変換するASIC（Application Specific Integrated Circuit）である。

GED（GeometryElement
Distributor）８０２は、各頂点データを、４つある次段のSIMDチップのうち処理待ちの状態にあるものに振り分ける役割を果たす。

ディスプレイリストキャッシュ８０３は、OpenGLAPIコールをグループ化したディスプレイリストを格納しておくキャッシュメモリである。よく使う一連のOpenGLAPIコールをディスプレイリストにしておくと、CPU からXステージボードに転送するデータ量を大幅に減らすことができる。

SIMDチップ８０４a,b,c,dは、ASIC で実現された1 チップのプロセッサで、FPU（浮動小数点演算ユニット）を3 系統持ち、マイクロコード格納用のキャッシュとデータキャッシュを備えている。一つのFPU には二つの演算器が含まれている。一つは通常の浮動小数点ALU（ArithmeticLogic Unit）で、もう一つは浮動小数点乗算器である。本ボードではこのSIMDチップを4 個搭載している。FPU
は12 系統が並列で動作するため、同時に12 個の頂点データ(x, y, z)の処理を並列で行うことができる。

SIMDチップでの処理内容（座標変換や照光計算のアルゴリズム）は、マイクロコードによって記述されている。演算回路はチップ上のキャッシュに記憶されたマイクロコードにしたがって動作する。マイクロコードはシステム起動時にキャッシュにロードされる。SIMDチップでの演算結果はFIFO（First-In
First-Out）メモリに集められ、Xステージボード全体の出力としてTriangle Bus と呼ばれるバスに転送される。各頂点データは、スクリーン座標系上の座標(x, y)と奥行き情報z、照光計算の結果である(r, g, b)、透明度情報のa、法線ベクトル(nx, ny, nz)、それとテクスチャ座標(s, t)を含む。

また、次のS ステージでの計算効率をよくするための前処理も本ボードで行われる。代表的な前処理はとして裏面カリングがある。裏面カリングは、ウィンドウ座標系に変換したときに裏向きになっている三角形を検出し、そのような三角形については頂点データをTriangle Bus に出力しないようにする処理である。以上がX ステージボードの処理である。

Sステージボード８０５について説明する。Sステージボード８０５は4 種類のASIC チップ（TG８０６, PG８０７, TF８０８, IMP８０９）から構成される。S（Scan conversion）ステージでの処理は、三角形の内部の各画素を塗りつぶすラスタライズ処理、隠面消去処理やステンシルマスク処理、霧の効果の処理などが含まれる。

ラスタライズ処理において重要な機能が、球面ストリップに全周囲画像を貼りつけるというテクスチャマッピングである。テクスチャマッピングでは、明るさ(r, g, b)を補間で求める代わりに、テクスチャ座標(s, t)を補間した結果からテクスチャメモリに格納されているテクスチャ画像のアドレスを計算して適切な画素を読み出し、その明るさ(r, g, b)をフラグメントの明るさデータとする。

Sステージボードの入力は、XステージボードからTriangle Bus を通じて与えられる三角形各頂点におけるフラグメント形式のデータ（スクリーン座標(x, y, z)、テクスチャ座標(s, t)、明るさ(r, g,b)、透明度a、法線ベクトル(nx,
ny, nz)）である。

TG（Texture Generator）チップ
８０６は、三角形の塗りつぶしを行い、画素ごとのテクスチャ座標(s, t)の補間結果を出力し、テクスチャメモリのアドレスを生成してテクスチャ画素（テクセル(texel)と呼ばれる）をTF（Texture
Filter）に渡す。

PG（Pixel Generator）チップ８０７では、ラスタライズ処理、すなわち三角形の塗りつぶし処理を行い画素ごとの明るさ(r, g, b)などの補間を行う。

TF(Texture Filter)チップ８０８は、PG の出力結果すなわちシェーディングされた明るさとテクスチャメモリの出力（テクセル）とを合成し、画素ごとのフラグメントをIMP（ImageMemory Processor）に渡す。

IMP(IMage Proccer)８０９は、ピクセル処理フローを実現するプロセッサで、霧処理、アンチエイリアシング、アルファテスト、ステンシルテスト、デプステスト、ブレンディング、マスキング、書込バッファ選択といったピクセル処理を行い、処理結果をフレームメモリ２０８に書き込む。

Dステージボード８１２は、Dステージの処理を行うボードであり、XMAP８１３、VOC８１４を具備している。

XMAP(Pixel Mapping Asic)８１３は、Pixel
Bus から画像データを受け取り、必要に応じてルックアップテーブルで変換し、また、カーソルの表示も行ってVideo
Packet Bus に画像データを乗せる。各VOCは、自分の担当する矩形領域が記述されたVOF データに従って画像を拾い、DA コンバータでビデオ信号に変換する。

VOC(Video Output Channel)回路８１４は、画像を拡大する出力回路、拡大画像の画質を良くするためのフィルタリング回路もあり、表示処理中に負荷が重くなったら動的に粗い解像度で描画し、ハードウェア拡大して元通りに表示する。Dステージボードでは最大8つの出力チャネルがあり、そのほかにHDMI出力エンコーダを備えている。

次に、上述したようなハードウェア構成のGPUに対して、どのような制御をソフトウェアで指示すべきかについて説明する。

図２５の上側は、球面モデルと、テクスチャとの対応付けを模式的に示す。この上側は球面モデルを構成するグリッド、右側はテクスチャを格納するテクスチャバッファの格納内容を示す。左側の球面モデルは、横方向にＷ個に分割され、それぞの分割部分にテクスチャが貼付けられることになる。本実施形態において、テクスチャマッピングの対象となる図形タイプを、三角形ストリップとし、この三角形ストリップの全部又は一部をテクスチャマッピングの対象とする。この三角形ストリップの全部又は一部は、頂点グリッドとして規定される。具体的にいうと、T1、T2、T3からなるグリッドがテクスチャマッピングの対象になり、T3,T4,T5,T6からなるグリッドが1つのテクスチャマッピングの対象になる。これらのグリッドを構成する交点の座標を、インデックスとして指定した上で、テクスチャマッピングを行う。

図２５の下側は、テクスチャマッピングを実現するためのOPEN-GLにおけるAPI呼出しの記述例である。

『glVertexPointer(3, GL#FLOAT, 0, g#v);』は、三次元モデリング空間におけるグリッドの各交点の座標群を頂点群として格納するものである。引き数の"３"は、三次元モデリング空間の次元数であり、GL#FOLATは、座標群のそれぞれの座標の型が浮動小数点形式であることを示す。

『glTexCoordPointer(2, GL#FLOAT, 0, g#uv);』は、三次元モデリング空間におけるグリッドに対応したテクスチャの座標群g#uvをテクスチャ座標値として格納するためのAPI呼出しである。

『for(I=0;i<W;i++)』は、横方向のW個の座標のそれぞれについて、glDrawElementsの呼出しを繰り返すループ構造として規定される。

『glDrawElements(GL#TRIANGLE#STRIP,(H + 1) * 2,
GL#UNSIGNED#SHORT,getStaticData()->g#index[i]);』について説明する。このAPI呼出しの第１引き数は、3Dモデルの図形タイプが三角形ストリップ(GL#Triangle#Stirp)であることを指定している。第２引き数は、頂点数の指定であり、（縦分割数Ｈ＋１）×２の数値を指定している。GL#UNSIGNED#SHORTは、頂点を格納したindexの型が符号無しのshort形式であることを示す。g#index[W]は、描画順番を決めたインデックス配列であり、個々の配列要素としてグリッド交点の頂点座標が格納される。g#indexの配列要素として格納されている頂点座標に従った描画を実行することにより、テクスチャマッピングがなされることになる。

先ず始めに、DIBRを実現するためのハードウェア構成(SVメモリ１８、ストリートビューDIBR実行部２１、右目写真メモリ１３a、左目写真メモリ１３b、写真DIBR実行部２８のハードウェア構成)について説明する。

SVメモリ１８は、複数のラインメモリからなり、SVデータは、ラインメモリを構成する３２ビット長の記憶素子にそれぞれ格納される。そしてSVデータの画面上の座標は、例えばSVメモリにおけるラインメモリのアドレスであるROWアドレスと、ラインメモリにおける記憶素子の相対アドレスであるCOLUMNアドレスとの組みに対応する。
以上がSVメモリ１８についての説明である。続いて、ストリートビューDIBR実行部２１のハードウェア構成について説明する。

ストリートビューDIBR実行部２１は、ストリートビューを左目SVと、ストリートビューデプス画像とに対してDIBRを施し、右目ストリートビューを作成する。上述したようにストリートビューの画面上の座標は、ストリートビューのラインメモリを指示するROWアドレスと、そのラインメモリにおける記憶素子を指示するCOLUMNアドレスとの組みに対応するので、ストリートビューメモリの記憶素子を指示するCOLUMNアドレスを、ストリートビューデプスにおける対応画素の奥行きに対応する視差に相当するアドレスだけ、増減させれば、反対の視線についてのストリートビューを得ることができる。ストリートビューデプスにおける対応画素の奥行きに対応する視差Xだけ、
ストリートビューのX座標を変更することで左目SVを作成したい場合、SVメモリ１８からテクスチャメモリ２２aへのコピー時において、そのコピー先となる記憶素子を指示するCOLUMNアドレスを、画素数Xに相当するアドレスだけ前に調整しておく。このようなアドレス調整を前提にしてコピーを実行すれば、左目ストリートビューの座標は、左方向にシフトすることになる。よってストリートビューDIBR実行部２１は、左目SVについては、アドレス調整を伴うコピー処理でSVメモリ１８からテクスチャメモリ２２aへのコピーを実行することで、ストリートビューデプスをベースにしたDIBRを実行する。

ストリートビューのX座標を変更することで右目SVを作成したい場合、SVメモリ１８からテクスチャメモリ２２ｂへのコピー時において、そのコピー先となる記憶素子を指示するCOLUMNアドレスを、画素数Xに相当するアドレスだけ後に調整しておく。このようなアドレス調整を前提にしてコピーを実行すれば、右目ストリートビューの座標は、右方向にシフトすることになる。よってストリートビューDIBR実行部２１は、右目SVについては、アドレス調整を伴うコピー処理でSVメモリ１８からテクスチャメモリ２２bへのコピーを実行することで、ストリートビューデプスをベースにしたDIBRを実行する。

以上がストリートビューDIBR実行部２１についての説明である。続いて、右目写真メモリ１３a、左目写真メモリ１３bの詳細について説明する。

右目写真メモリ１３a、左目写真メモリ１３bも、複数のラインメモリからなり、写真データを構成する画素は、ラインメモリを構成する３２ビット長の記憶素子にそれぞれ格納される。そして写真データの画面上の座標は、例えばビデオプレーンにおけるラインメモリのアドレスであるROWアドレスと、ラインメモリにおける記憶素子の相対アドレスであるCOLUMNアドレスとの組みに対応する。以上が右目写真メモリ１３a、左目写真メモリ１３bについての説明である。写真DIBR実行部２８についても、同様のアドレス調整付きのコピーを行えば、写真に対するDIBRを実行することができる。

次に、ストリートビューDIBR実行部２１、写真DIBR実行部２８がシフトを行うにあたってのシフト量を、ハードウェアでどのように決定するかについて説明する。代表としてストリートビューDIBR実行部２１について説明する。ストリートビューDIBR実行部２１は、SVメモリ１８から横512×縦512の画素からなる画像データを取り出し、また、SVデプスメモリ２０から横512×縦512の画素からなるデプス画像を取り出して、この横512×縦512のデプス画像をベースにして横512×縦512の画素の集りに対するDIBRを実行する。画素シフトを実行するにあたって、どのような視差を各画素に設定するかを述べる。デプス画像の座標(x,y)に存在する画素において、視点からの奥行きがDepth(x,y)である場合、デプス画像において座標(x,y)に存在する輝度Y(x,y)から奥行きDepth(x,y)への変換は、例えば、以下の数式に基づいてすることができる。

(数式)
Y(x,y)＝255-(log(Depth(x,y)+1)×100)

こうして求めた奥行きDepth(x,y)を、ディスプレイの画面サイズに応じた画素数offset(x,y)に変換することで画素の輝度を適切な視差に変換することができる。

DIBRでは、画像を構成する複数の画素のうち、任意の座標(x,y)に位置するものの座標を水平方向に移動するにあたって、対応するデプス画像において座標(x,y)に存在する画素の輝度Y(x,y)によって導かれる奥行きDepth(x,y)から、その座標(x,y)に固有のoffset(Depth(x,y),y)を求めて、このoffset(Depth(x,y),y)を移動量として使用することで他視点からの視点画像を得る。図２６（ａ）は、デプス画像において座標(x,y)に存在する画素の奥行きDepth(x,y)を示す。Depth(x,y)は、図２６（ｂ）におけるPix(x,y)と位置的に対応する。図２６（ｂ）は、画像メモリにおいて座標(x,y)に存在する画素Pix(x,y)を示す。図２６（ｃ）は、左目テクスチャを生成するにあたって、画素Pix(x,y)がどれだけシフトするかを示す。図２６（ｃ）では、SV画像メモリ１８において、Pix(x,y)は水平方向にOffset(Depth(x,y))だけ変位している。そのため、Pix(x+Offset(Depth(x,y))、y)に位置することになる。Offset(Depth(x,y))とは、全周囲画像において、x,y座標に一意なオフセットであり、デプス画像における対応画素の輝度によるDepth(x,y)から設定される。

2以上の視点画像を作成するにあたって、画素が水平方向にどれだけ変位するかは、画像の画素毎に異なることになる。デプス画像における画素の輝度レベルと、シフト量である画素数との対応付けは上記数式から導くことができる。その対応付けの一例として、図２６（ｃ）のように設定することができる。

図２６（ｃ）は、Y(x,y)における０〜２５５の輝度範囲と、１画素〜１６画素の単位のオフセットとの対応付けを示す。本図では、0〜63の輝度範囲に0〜2画素の範囲のオフセットを、64〜127の輝度範囲に3〜4画素の範囲のオフセットを割り当て、128〜191の輝度範囲に5〜8画素のオフセットを、192〜255の輝度に9〜16画素のオフセットを割り当てるものである。つまり明るい部分の輝度範囲に割り当てるべき視差を大きくし、暗い部分の輝度範囲に割り当てるべき視差を小さくするという非線形な対応付けがなされている。

図２７は、画素レベルのシフトにより、左目テクスチャ、右目テクスチャにおいてどのような視差がもたらされるかを示す。図２７（ａ）はデプス画像、図２７（ｂ）は左目テクスチャメモリの格納内容、図２７（ｃ）は、右目テクスチャメモリの格納内容を示す。

Pix(x1,y)は、図２７（ｂ）において並ぶ3つのビルのうち、一番手前のビルの画素である。Pix(x2,y)は、3つのビルのうち２番目のビルの画素である。Pix(x3,y)は、3つのビルのうち3番目のものの画素である。

図２７（ａ）は、デプス画像の一例であり、左目テクスチャにおける画素Pix(x1,y)、Pix(x2,y)、Pix(x3,y)に与えられる奥行きを示す。Depth(x1,y)は、左目テクスチャにおけるPix(x1,y)の奥行きを示す。Depth(x2,y)は、左目テクスチャにおけるPix(x2,y)の奥行きを示す。Depth(x3,y)は、左目テクスチャにおけるPix(x3,y)の奥行きを示す。

図２７（ｃ）の下側は、DIBRにおいて各画素に与えられるオフセットを示す。Offset(Depth(x1,y),y)は、左目テクスチャにおけるPix(x1,y)に与えられるオフセットを示す。Offset(Depth(x2,y),y)は、左目テクスチャにおけるPix(x2,y)に与えられるオフセット、Offset(Depth(x3,y),y)は、左目テクスチャにおけるPix(x3,y)に与えられるオフセットを示す。本図に示すように、Depth(x1,y)>Depth(x2,y)>Depth(x3,y)の関係があるから、一番手前にあるビルを構成する画素に対して一番大きな視差が与えられ画面から大きく飛出すことになる。

以上のようにDIBRでは、デプス画像における対応画素の輝度に応じて画素の変位量は異なるものになるから、算術演算器を用いて、デプス画像における各画素の輝度からオフセットを算出すれば、ハードウェア素子により、ストリートビューDIBR実行部２１、写真DIBR実行部２８を実装することができる。

＜備考＞
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的であり、実施する者の主観によることは留意されたい。

（視点周囲画像の範囲増減）
各実施形態では、横7枚の背景画像を横方向に結合することで得られる全周囲画像を対象にして説明を進めたが、横方向の画像の結合数を減少することで、視点から見渡せるストリートビューの範囲を変更してもよい。上記実施形態の全周囲画像は、横7枚の背景画像で360°の視野を網羅するから、一枚の背景画像で網羅される範囲は、52°(≒365°/7)である。よって、2枚の画像を結合した場合、104°(≒52°×2)の範囲を見渡すことができ、3枚の画像を結合した場合、156°(≒52×3)の範囲を見渡すことができる。このように、ストリートビュー収集サーバや映像提供装置で横方向の画像の結合数を変化させることにより、視点周囲画像の規模を変化させ、テクスチャマッピング処理やテクスチャにおける視差算出等の負荷を軽減することもできる。

（ラインスキャン回路による実現性）
またDIBRをラインスキャン回路で実現することができる。ラインスキャン回路とは、フレームメモリに格納された一画面分の画素(1920×1080)の集りを横1920画素ずつ読み出してデジタル映像信号に変換するハードウェア素子である。かかるラインスキャン回路は、１行分の画素データを格納しうるライン画素メモリと、フィルタ回路、パラレル／シリアル変換を行う変換回路によって実現することができる。上述したようにDIBRは、デプス画像の個々の画素の輝度を視差に変換して画素のシフトを行う処理である。ラインメモリに読み出された全周囲画像の一ライン分の画素の座標を、全周囲画像に対するデプス画像における対応するラインの奥行きに応じた画素数だけ横方向に移動すれば、デプス画像における個々の示される奥行きをもたらす他視点からの視点画像を作成することができる。

（デプス画像のバリエーション）
圧縮メルカトルデプス画像８０３は、メルカトル画像に対する奥行きを示す画像をPNG形式で圧縮されたデータとしたが奥行きは圧縮ノイズが目立ってしまうため、PNG形式などのロスレス形式で圧縮することが望ましい。なお、立体ストリートビュー視点８０１における圧縮メルカトルデプス画像８０３はデータが冗長であるため、PNG形式での圧縮以外にも周囲の地形データおよび、圧縮メルカトル画像８０２と地形データとの関係を示すデータを備えるようにしてもよい。なお立体ストリートビュー視点８０１をインターネットで送受信をする場合、圧縮メルカトル画像は分割し複数のファイルに分けるようにすると、ダウンロード途中の状態でも表示が可能となる以外に、SVデコーダ２１８とSV特徴点抽出器の処理を並列に行うことができ、全体的に高速に処理することができる。

（集積回路の実施形態）
第１実施形態に示した再生装置のハードウェア構成のうち、記録媒体のドライブ部や、外部とのコネクタ等、機構的な部分を排除して、論理回路や記憶素子に該当する部分、つまり、論理回路の中核部分をシステムLSI化してもよい。システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも1つのLSIのような外形構造を複数個のベアチップに持たせたものはマルチチップモジュールと呼ばれるが、このようなものも、システムLSIに含まれる。

ここでパッケージの種別に着目するとシステムLSIには、QFP(クッド
フラッドアレイ)、PGA(ピングリッドアレイ)という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステムLSIである。

これらのピンは、電源供給やグランド、他の回路とのインターフェイスとしての役割を担っている。システムLSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システムLSIにおけるこれらのピンに、他の回路を接続することにより、システムLSIは、再生装置の中核としての役割を果たす。
（左目画像、右目画像のどちらかを処理することの技術的意義）
なお立体写真のDIBRにおいて、立体写真を手前におくことで立体写真を引き立たせることができ、さらに見やすい追体験を実現することができる。

なお本実施の形態は立体写真について説明をしたが、動画も同様に適応できる。動画の場合は動画の一フレームを静止画とみなして処理するとよい。

（数式に基づく演算の具体化）
これまでの実施形態では、数式に基づく演算処理を開示したが、これらの数式は、数学的な概念を意味するのではなく、あくまでも、コンピュータ上で実行される数値演算を意味するものなので、当然のことながら、コンピュータに実現させるための、必要な改変が加えられることはいうまでもない。例えば、数値を、整数型、固定少数点型、浮動小数点型で扱うための飽和演算や正値化演算が施されてよいことはいうまでもない。更に、各実施形態に示した、数式に基づく演算処理のうち、定数との乗算は、定数ROMを用いたROM乗算器で実現することができる。定数ROMには、被乗数と定数との積の値はあらかじめ計算されて格納されている。例えば、被乗数が16ビット長である場合、この被乗数は、4ビット毎に四つに区切られ、この4ビット部分と定数との積、つまり、定数の0〜15の倍数が上記の定数ROMに格納されている。上記の一区切りの4ビットと定数16ビットとの積は20ビット長であり、上記の四つの定数が同一のアドレスに格納されるので、20×4＝80ビット長が一語のビット長となる。以上述べたように、ROM乗算器での実現が可能であるので、本明細書でいうところの"演算処理"は、純粋な算術演算のみを意味するのではなく、ROM等の記録媒体に格納された演算結果を、被演算子の値に応じて読み出すという、記録媒体の読み出しをも包含する。

（プログラムの実施形態）
各実施形態に示したプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。

記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。

コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。

ここで生成されたオブジェクトプログラムは、各実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVA(TM)バイトコードというように、様々な種類がある。プログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップを実現してもよい。

オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。かかるコンピュータプログラムを非一時的なコンピュータ読取可能な記録媒体に記録してユーザに提供してよい。

（立体視再生のバリエーション）
立体視再生時において一枚の全周囲画像から左目テクスチャ、右目テクスチャを作成するとしたが、この全周囲画像を左目テクスチャとしてもちいて、右目テクスチャのみを作成してもよい。同様に、全周囲画像を左目テクスチャとしてもちいて、右目テクスチャのみを作成してもよい。この場合、立体視再生時におけるカメラ位置と比較して、2×pだけ隔てられた位置を右目カメラの配置位置とし、かかる配置位置にカメラを配置することで上述したような座標変換、テクスチャマッピング、ビューポート変換を実行すればよい。

本発明にかかる映像提供装置は、製造産業において経営的に、また継続的および反復的に製造し、販売することができる。特に、写真コンテンツの制作と再生に携わる民生機器産業において利用できる。

１a ネットワークインターフェース
１b 入力インターフェイス
１c ビルトインメディア
２ファイルシステム
３ UOモジュール
４制御部
５描画部

Claims

背景画像データを三次元モデリング空間における立体モデルの内側表面に貼り付けた上で、前景画像データを合成する映像提供装置であって、
前景画像データ及び背景画像データの特徴点を抽出する抽出手段と、
前景画像データの特徴点と、背景画像データの特徴点とのペアをサーチして、これらのペアを利用することにより、前景画像データを背景画像データの内部に投影するための変換行列を得るマッチング手段と、
前景画像データに対応するデプス前景データに対して、マッチング手段が得た変換行列に基づく変換を施す変換手段と、
変換がなされたデプス前景データをベースにしたデプスベースドレンダリングを、前景画像データに施すことにより、前景画像データに対応する2以上の視点画像データを得るデプスベースドレンダリング手段と、
前景画像データに対応する2以上の視点画像データと、背景画像データに対応する2以上の視点画像データとの合成を行う合成手段と
を備えることを特徴とする映像提供装置。
前記前景画像データ上のある特徴点f (xf , yf)と、特徴点f(xf,yf)に対応する背景画像データの特徴点F(XF,YF)、及び、特徴点F(XF,YF)のデプス値ZFをX,Y,Z座標として以下の数１の数式に適用することで変換行列Ｈを得る

ことを特徴とする請求項１記載の映像提供装置。
前記映像提供装置は更に、立体視カメラによって撮影された写真画像データを取得する取得手段を備え、撮影された写真画像データには、右目写真データ、左目写真データがあり、
前記変換手段は更に、
背景画像データの撮影方向と、各写真画像の撮影方向とを比較することにより右目写真データ、左目写真データのうちどちらを基点画像にするかの決定を行い、
前記前景画像データは、右目写真データ、左目写真データのうち基点画像データとして決定されたものである
ことを特徴とする請求項１記載の映像提供装置。
前記映像提供装置は、
右目写真データ、左目写真データから写真についてのデプス画像を生成するデプス画像生成手段を備え、
変換手段による変換がなされるデプス前景データとは、デプス画像生成手段によって生成されたデプス画像である
ことを特徴とする請求項３記載の映像提供装置。
前記デプスベースドレンダリング手段は、
左目写真データ、右目写真データのうち、基点画像ではないものの画素の座標を、デプス前景データに示される奥行きに基づき水平方向にシフトすることにより、画像データの再生成を行い、
前記2以上の視点画像データは、
左目写真データ及び右目写真データのうち、基点画像データではないものと、再生成された画像データとから構成される
ことを特徴とする請求項３記載の映像提供装置。
映像提供装置には、探索を行うべき特徴点がとるべき奥行きの許容レベルが予め定められており、
前記マッチング手段は、
立体ストリートビュー視点にマッチングするための特徴点を前景画像データからサーチするにあたって、奥行き分布の中心が許容レンジ外となる特徴点を排除して背景画像データにおける特徴点、及び、前景画像データにおける特徴点のうち奥行き分布の中心が許容レンジ内となる特徴点同士でマッチングを行うことを特徴とする請求項１に記載の映像提供装置。
前記映像提供装置は、地球上の地理的情報を用いてカレント視点位置を指定した画像取得要求を画像収集サーバに送信する送信手段と、
画像取得要求に対する応答として、画像収集サーバから送信されてくるストリートビューファイルを受信する受信手段とを備え、
前記背景画像データは、受信したストリートビューファイルに存在する
ことを特徴とする請求項１記載の映像提供装置。
前記映像提供装置は、記録媒体をアクセスして立体写真ファイルを読み出す読出手段を備え、
前記立体写真ファイルは、左目写真データ及び右目写真データと、地理的情報とを含み、
前記変換手段は更に、
背景画像データの撮影方向と、各写真画像の撮影方向とを比較することにより右目写真データ、左目写真データのうちどちらを基点画像にするかの決定を行い、
前記前景画像データは、右目写真データ、左目写真データのうち基点画像データとして決定されたものであり、
前記送信手段は、
立体写真ファイルに存在する地理的情報を用いてカレント視点位置を指定する画像取得要求を作成して、画像収集サーバに送信し、
画像収集サーバから送信されてくるストリートビューファイルは、画像取得要求に含まれる地理的情報と合致する撮影地属性を有する
ことを特徴とする請求項７記載の映像提供装置。
背景画像は視点周囲画像であり、画像取得要求における地理的情報に対応する地理的位置から周囲を見渡した場合の光景を表す
ことを特徴とする請求項８記載の映像提供装置。
背景画像データを三次元モデリング空間における立体モデルの内側表面に貼り付けた上で、前景画像データを合成する映像提供方法であって、
前景画像データ及び背景画像データの特徴点を抽出する抽出ステップと、
前景画像データの特徴点と、背景画像データの特徴点とのペアをサーチして、これらのペアを利用することにより、前景画像データを背景画像データの内部に投影するための変換行列を得るマッチングステップと、
前景画像データに対応するデプス前景データに対して、マッチングステップが得た変換行列に基づく変換を施す変換ステップと、
変換がなされたデプス前景データをベースにしたデプスベースドレンダリングを、前景画像データに施すことにより、前景画像データに対応する2以上の視点画像データを得るデプスベースドレンダリングステップと、
前景画像データに対応する2以上の視点画像データと、背景画像データに対応する2以上の視点画像データとの合成を行う合成ステップと
を含むことを特徴とする映像提供方法。
背景画像データを三次元モデリング空間における立体モデルの内側表面に貼り付けた上で、前景画像データを合成する処理をコンピュータに実行させる映像提供プログラムであって、
前景画像データ及び背景画像データの特徴点を抽出する抽出ステップと、
前景画像データの特徴点と、背景画像データの特徴点とのペアをサーチして、これらのペアを利用することにより、前景画像データを背景画像データの内部に投影するための変換行列を得るマッチングステップと、
前景画像データに対応するデプス前景データに対して、マッチングステップが得た変換行列に基づく変換を施す変換ステップと、
変換がなされたデプス前景データをベースにしたデプスベースドレンダリングを、前景画像データに施すことにより、前景画像データに対応する2以上の視点画像データを得るデプスベースドレンダリングステップと、
前景画像データに対応する2以上の視点画像データと、背景画像データに対応する2以上の視点画像データとの合成を行う合成ステップと
をコンピュータに実行させることを特徴とする映像提供プログラム。