JP6572368B2 - 生成装置および生成方法、プログラム - Google Patents

Description

本発明は、仮想視点映像において素材データを生成する生成装置および生成方法に関する。

複数台の実カメラ映像を用いて、３次元空間内の任意の位置に配置した仮想カメラからの映像を再現する技術として、自由視点映像（仮想視点映像）技術がある。仮想視点映像技術では、被写体の３次元形状を推定することにより、任意の仮想カメラ位置からの映像を生成する。被写体のモデルデータ（３次元形状とテクスチャ画像）をユーザの所有する端末に送信することによって、ユーザのインタラクティブな操作に対応した仮想視点映像を生成することが可能である。しかし、被写体のモデルデータのデータ量は膨大であるため、モデルデータの送信は通信帯域を圧迫してしまう。送信されるデータ量を削減する方法として、形状の変化量に応じて３次元形状の構成密度を変動させる構成（特許文献１）が提案されている。

特許第５５６３５４５号公報

しかしながら、特許文献１では、形状の構成密度のみに着目しているため、ユーザにとって重要な情報が欠落する恐れがある。したがって、特許文献１のようなデータ量の削減手法は、仮想視点映像を生成するためのモデルデータを生成するのには不向きである。

本発明は、仮想視点映像を再生するための素材データを効率的にクライアントへ提供可能とすることを目的とする。

本発明の一態様による生成装置は以下の構成を有する。すなわち、
仮想視点の位置及び向きに応じた仮想視点画像を生成するために用いられる素材データを生成する生成装置であって、
複数のカメラが異なる方向から撮影領域を撮影することで得られる複数の撮影画像に基づいて複数の素材データを生成する生成手段であって、第１素材データと、前記第１素材データより品質が高い第２素材データと、を少なくとも含む複数の素材データを生成する生成手段と、
前記生成手段により生成された素材データを記憶手段に記憶させる記憶制御手段と、を有し、
前記記憶制御手段により前記記憶手段に記憶された複数の素材データのうちクライアントから得られる情報に基づいて選択された素材データは、前記クライアントに対して提供される。

本発明によれば、仮想視点映像を再生するための素材データを効率的にクライアントへ提供できる。

画像表示システムの構成と、画像処理装置の構成を示すブロック図。 表示装置の構成を示すブロック図。 画像表示システムにおけるカメラの配置を示す概要図。 仮想視点映像の送信の処理を示すフローチャート。 階層モデルデータ生成の処理を示すフローチャート。 階層モデルデータの概要を示した図。 階層モデルデータの概要を示した図。 属性データの概要を示した図。 属性データの概要を示した図。 属性データの生成処理を示すフローチャート。 モデルデータ送信処理を示すフローチャート。 表示装置のＧＵＩを示した図。 仮想視点映像の生成処理を示すフローチャート。 送信用データを示した図。 属性データの修正処理を説明する図。 属性データの修正処理の他の例を説明する図。

以下、本発明の実施形態について、図面を参照して説明する。なお、以下の実施形態は本発明を限定するものではなく、また、本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。なお、同一の構成については、同じ符号を付して説明する。

＜第１実施形態＞
第１実施形態では、ユーザ端末でのインタラクティブな仮想視点映像の再生時に必要なモデルデータの送信方法に関して説明する。ここでは、説明を簡易にするため、送信元であるサーバが単一で、受信先であるクライアントが複数存在するケースを想定する。また、ロケーションをサッカー競技が行われるスタジアム内とし、サーバである画像処理装置がスタジアム内に存在し、観客席においてユーザがクライアントである表示装置（スマートフォン、タブレットなどの端末）を操作し、仮想視点映像を閲覧するものとする。なお、本実施形態において仮想視点映像とは、仮想的に設定された視点からの映像のことを意味する。仮想視点映像に類似の用語として、自由視点映像や任意視点映像等の呼称も存在する。

図１Ａは、第１実施形態における、画像処理装置の構成例と画像表示システムの構成例を示すブロック図である。画像処理装置１００は、ＣＰＵ１０１、メインメモリ１０２、記憶部１０３、入力部１０４、表示部１０５、外部Ｉ／Ｆ部１０６、バス１０７を備える。ＣＰＵ１０１は、演算処理や各種プログラムを実行する。メインメモリ１０２は、処理に必要なプログラム、データ、作業領域などをＣＰＵ１０１に提供する。記憶部１０３は、画像処理プログラム、ＧＵＩ表示に必要な各種データ、などを格納する。記憶部１０３には、例えばハードディスクやシリコンディスク等の不揮発性メモリが用いられる。入力部１０４は、キーボードやマウス等の装置であり、サーバ管理者からの操作入力を受け付ける。表示部１０５はＧＵＩの表示を行う。外部Ｉ／Ｆ部１０６は、ＬＡＮ１０８を介してカメラ装置群や表示装置群と接続し、映像データや制御信号データ、モデルデータの送受信を行う。バス１０７は上述の各部を接続し、データ転送を行う。

ＬＡＮ１０８は有線および／または無線で構成され、画像処理装置、カメラ装置群、表示装置群、分析装置間でのデータ送受信に利用される。カメラ装置群は、複数のカメラ１２０で構成される。それぞれのカメラ１２０はＬＡＮ１０８経由で画像処理装置１００と接続されており、画像処理装置１００からの制御信号をもとに、撮影の開始と停止、カメラ設定（シャッタースピード、焦点距離、絞値など）の変更、撮影データの転送を行う。表示装置群は、複数のユーザ端末１３０（スマートフォンやタブレットなど）から構成される。それぞれのユーザ端末１３０はＬＡＮ１０８経由で画像処理装置１００と接続されており、画像処理装置１００から仮想視点映像の閲覧に必要なモデルデータを受信する。ユーザ端末１３０は、受信したモデルデータを用いて、仮想視点映像を生成し、表示する。ＬＡＮ１０８の通信帯域は有限であるため、ユーザ端末１３０が受信可能なモデルデータのサイズはユーザ数に依存する。分析装置１４０は、カメラ１２０の映像や被写体に設置した各種センサ情報を用いて、被写体のプレーの種類を分析する。なお、分析装置１４０はオプションであり、必須な構成要素ではない。なお、システム構成については、上記以外にも、様々な構成要素が存在する。例えば、ＬＡＮ１０８の代わりに、インターネットやＷＡＮなどを介して、各種デバイスが接続されるようにしても良い。また例えば、画像処理装置１００と複数のカメラ１２０と分析装置１４０がＬＡＮ１０８を介して接続されることによって画像処理システムを形成し、当該画像処理システムとユーザ端末１３０がインターネット等によって接続されるようにしても良い。

図１Ｂは、第１実施形態による、表示装置としてのユーザ端末１３０の構成を示すブロック図である。ユーザ端末１３０は、ＣＰＵ１３１、メインメモリ１３２、記憶部１３３、入力部１３４、表示部１３５、外部Ｉ／Ｆ部１３６、バス１３７を備える。ＣＰＵ１３１は、演算処理や各種プログラムを実行する。メインメモリ１３２は、処理に必要なプログラム、データ、作業領域などをＣＰＵ１３１に提供する。記憶部１３３は、仮想視点映像を生成、表示するためのプログラム、ＧＵＩ表示に必要な各種データ、などを格納する。記憶部１３３には、例えばハードディスクやシリコンディスク等の不揮発性メモリが用いられる。入力部１３４は、キーボード、マウス、タッチパネル等の装置であり、仮想視点映像を観察するユーザからの操作入力を受け付ける。表示部１３５は、仮想視点映像やＧＵＩの表示を行う。外部Ｉ／Ｆ部１３６は、ＬＡＮ１０８と接続し、例えば画像処理装置１００から送信された、仮想視点映像を再生するためのモデルデータを受信する。バス１３７は上述の各部を接続し、データ転送を行う。

図２は、複数のカメラ１２０の配置を示した図である。サッカー競技を行うフィールド２０１上に複数の被写体２０２が存在し、複数のカメラ１２０がフィールド２０１を取り囲むように配置されている。複数のカメラ１２０は主に観客席などに配置され、それぞれフィールド２０１が収まるように焦点距離と撮影方向が設定されている。

図３は、画像処理装置１００による送信までの一連の処理過程を示したフローチャートである。Ｓ３０１では、画像処理装置１００は、カメラ１２０の撮影により得られた映像を取得し、映像中の被写体ごとに、データサイズが異なる複数の階層（図５Ａにより詳述する）のモデルデータを生成する。Ｓ３０１の処理に関しては、図４にて詳述する。Ｓ３０２では、画像処理装置１００は、撮影対象となる競技の指定を受け付ける。ここでは、「サッカー」、「ラグビー」、「フィギュア」などの競技名の指定を受け付ける。Ｓ３０３では、画像処理装置１００は、Ｓ３０２で受け付けた競技の種別、分析装置１４０からのデータを基に、仮想視点映像生成に必要なモデルデータの階層が記述された属性データを生成する。図６Ａ、図６Ｂの参照により後述するように、属性データは、映像中のコンテンツの属性と要求される階層とを対応付けるデータである。Ｓ３０３の処理に関しては、図７の参照により後述する。Ｓ３０４では、画像処理装置１００は、属性データによって要求される階層のモデルデータを被写体ごとに選択して送信用モデルデータを構成し、表示装置であるユーザ端末１３０からのリクエストに応じて送信する。この送信用モデルデータの構築において、ＬＡＮ１０８の通信帯域の使用状態なども考慮される。Ｓ３０４の処理に関しては、図８の参照により後述する。

図４は、インタラクティブな仮想視点映像の生成に必要なモデルデータを複数の階層について生成する処理を示したフローチャートであり、Ｓ３０１の処理の詳細を示している。Ｓ４０１において、画像処理装置１００（ＣＰＵ１０１）は、スタジアムや観客席などの背景モデルデータを生成する。背景モデルデータは３次元形状を構築するメッシュデータと、色を再現するためのテクスチャデータから構成され、３Ｄレーザスキャナや、多視点ステレオ法などを用いて生成される。

Ｓ４０２において、ＣＰＵ１０１は、カメラ１２０に対して、撮影時の露光が適切となるようなカメラ設定の変更と、撮影開始の信号を送信する。撮影開始の信号に応じてカメラ１２０は撮影を開始し、映像データをＬＡＮ１０８経由で画像処理装置１００に転送する。画像処理装置１００は、カメラ１２０からの映像データを受信し、メインメモリ１０２上に展開する。画像処理装置１００は、映像データを、各カメラの映像フレームを同一のタイムコードごとにまとめた多視点フレームとして管理する。また、このとき、画像処理装置１００は、各カメラの位置・姿勢をStructure from Motion等の方法を用いて算出し、記憶しておく。

Ｓ４０３において、ＣＰＵ１０１は、映像データから被写体群の輪郭を抽出し、Visual-hullなどの方法を用いて被写体群の３次元形状・位置を生成する。被写体群の輪郭抽出は、１台のカメラのカメラ映像の全フレームにおいて中間値フィルタを用いることで取得可能である。また、３次元形状は点群データ、もしくはボクセルデータとして出力される。本処理は、全タイムコードの多視点フレームに対して実施され、多視点フレーム単位で全被写体の形状点群データ（高密度点群による形状データ）が生成される。生成された形状点群データは記憶部１０３に保存される。

Ｓ４０４において、ＣＰＵ１０１は、Ｓ４０３で生成した形状点群データに対して、間引きを行い、残った点群をつないで面（三角形ポリゴン）を構成するメッシュ化を行い、被写体を表すメッシュを生成する。メッシュ化には、周知の技術を適用可能であり、例えばBall Pivotingなどの方法を用いることができる。ＣＰＵ１０１は、多視点フレーム単位に生成した全ての形状点群データに対してメッシュ化の処理を実行し、得られたデータ（低密度なメッシュデータ）を記憶部１０３に保存する。Ｓ４０５において、ＣＰＵ１０１は、Ｓ４０４で生成したメッシュに対して貼り付けるテクスチャデータ（被写体のテクスチャ）を生成する。被写体のテクスチャの生成には周知の技術を適用可能である。ＣＰＵ１０１は、多視点フレーム単位に生成した全てのメッシュデータに対してテクスチャを生成し、得られたデータを記憶部１０３に保存する。

Ｓ４０６において、ＣＰＵ１０１は、映像先頭のタイムコードに該当する多視点フレーム（初期フレーム）から生成されたメッシュとテクスチャを記憶部１０３から読み出し、メインメモリ１０２に展開する。Ｓ４０７において、ＣＰＵ１０１は、Ｓ４０６で読み込んだメッシュに対してメッシュを姿勢制御するためのボーンを組み込む。ボーンは図５Ｂ（ｂ）に示すように、人間の骨のような構造を持ち、関節５０２と、関節５０２同士をつなぐ骨組み５０３とを有し、メッシュ５０１の内部に格納される。ボーンはあらかじめ用意されており、メッシュに合わせてサイズや初期関節位置を変更することで、種々のメッシュに格納可能である。メッシュ５０１とボーンは連動して変形するため、関節５０２の位置を移動することによって、メッシュ５０１に様々な姿勢・動作（座る、走る、蹴るなど）を再現させることが可能である。また、各々の関節５０２の位置は骨組み５０３によって移動が制限されるため、より人間に近い動作が再現できる。

Ｓ４０８において、ＣＰＵ１０１は、カメラ映像を用いて全被写体の関節位置を推定する。関節位置の推定には周知の技術を適用することが可能である。例えば、機械学習を用い、映像上の２次元での関節位置(x(n,i,k,t), y(n,i,k,t))を取得する。ここで、０≦x＜画像の横幅、０≦y＜画像の縦幅、０≦n＜カメラ数、０≦i＜被写体数、０≦k＜関節数、０≦t＜フレーム数である。少なくとも２台以上のカメラ映像において２次元関節位置を取得後、Ｓ４０２で求めた各カメラの位置を基に三角測量を用いて３次元での関節位置(X(i,k,t), Y(i,k,t), Z(i,k,t))を取得する。このとき、X、Y、Zは３次元空間における座標値で、０≦i＜被写体数、０≦k＜関節数、０≦t＜フレーム数である。これにより、被写体の各関節の移動軌跡、すなわち、姿勢の変遷が取得される。

Ｓ４０９において、ＣＰＵ１０１は、Ｓ４０７で生成したボーンの関節位置を、Ｓ４０８で生成した３次元関節位置と多視点フレーム単位で対応付け、メッシュおよびボーンを姿勢変遷化（アニメーション化）する。これによって、メッシュとテクスチャは映像先頭の多視点フレームのデータのみ用意し、関節位置の軌跡を表す少量のアニメーションデータを付加するのみで良いので、実質的にモデルデータの時間軸方向への圧縮となり、データ量を大幅に削減できる。

Ｓ４１０では、ＣＰＵ１０１は、Ｓ４０３〜Ｓ４０９で生成したモデルデータを、図５Ａの表５ａに示す階層構造として保持する。表５ａにおいて、階層は３段階に分かれており、それぞれ、３次元形状とテクスチャから構成される。階層３は、最高階層であり、３次元形状としてＳ４０３で生成された点群データを、テクスチャとしてＳ４０２で取得されたカメラ映像を含み、データ量が最も大きく、生成される仮想視点映像の画質が最も高い。階層２は、３次元形状としてＳ４０４で生成されたメッシュデータを含み、テクスチャとしてＳ４０５で生成されたテクスチャデータを含み、データ量および生成される仮想視点映像の画質は共に中程度である。階層１は、本実施形態では、最低階層であり、３次元形状としてＳ４０６で取得されたメッシュデータとＳ４０９で取得されたアニメーションデータを含み、テクスチャとしてＳ４０６で取得されたテクスチャデータを含む。階層１のモデルデータはデータ量が最も軽いが、仮想視点映像の画質は最も低い。階層ごとに再現可能な項目を図５Ｂ（ａ）の表５ｂにまとめた。階層が下がるにつれて、表現可能な項目が減少するため、データ送信時にはコンテンツ内容に応じて、適切な階層を選択する必要がある。

Ｓ４１１において、分析装置１４０が存在する場合、ＣＰＵ１０１は、分析装置１４０から取得した分析データである被写体のプレー情報（シュート、パス、クリアなどのプレー内容）と、モデルデータを紐づける。これにより、例えば、シュート時の、所望の階層の３次元形状とテクスチャデータを抽出する処理などが実施可能となる。以上の処理により、階層構造を持つモデルデータの生成が完了する。

図６Ａ、図６Ｂは、モデルデータの圧縮に必要となる、属性データを説明した図である。本実施形態では、属性データには、競技属性、エリア属性、試合属性の３種類が存在し、圧縮効果の大きさは、試合属性＞エリア属性＞競技属性の順となる。各属性データには、仮想視点映像生成に要求されるモデルデータの階層（要求階層）が記述されており、競技属性、エリア属性、試合属性の順に、より細かく要求階層が分類されている。

競技属性には、図６Ａ（ａ）の表６ａに示されるようにコンテンツの属性としての競技の種類ごとに要求階層が記述されている。例えば、アメリカンフットボール（アメフト）では、選手がヘルメットを被っており、顔が隠蔽されているため、テクスチャの要求階層は低い。一方で、フィギュアスケートやサッカーでは、選手の顔や表情をはっきり見たいというニーズがあるため、テクスチャへの要求階層が高い。また、３次元形状に関して、アメフトやサッカーでは選手のプレー位置が重要であり、形状の詳細さや動きの滑らかさに対するニーズが低いため、要求階層は低い。一方、フィギュアスケートでは、演技時の動きが重要であるため、３次元形状の要求階層は高くなる。このように、競技ごとに３次元形状とテクスチャ各々で要求階層を決定し、高い方をその競技の要求階層と定義する。

エリア属性は、図６Ａ（ｃ）の表６ｃに示されるように、それぞれの競技の競技場について、コンテンツの属性としてのエリア（競技場の一部）ごとに要求階層が記述されている。例えば、サッカーでは、図６Ａ（ｂ）に示すように、ゴール前であるエリア０、１は注目されるプレーの発生率が高いため、要求階層が最も高い。コーナーキック等が発生するエリア２が次に要求階層が高く、エリア０、１、２以外の領域の要求階層は低い。なお、図６Ａ（ｂ）ではエリア２が１か所にのみ示されているが、実際はフィールドの４隅にエリア２が設定される。以上を踏まえて、エリアの領域情報とそれに対応する要求階層を図６Ａ（ｃ）の表６ｃのように記述し、これをサッカーのエリア属性とする。一方、フィギュアスケートのように、被写体がどの領域で注目するプレーを行うのかを絞り込めない競技では、エリア属性を定義しない。

試合属性では、図６Ｂの表６ｄに示すように、コンテンツの属性としてエリア、タイムコードが用いられ、エリア、タイムコードごとに要求階層が記述されている。例えば、サッカーの場合、分析装置１４０からどのようなプレー（シュートなど）がどのタイムコードで発生したかが取得できる。そのため、注目度の高いプレーが発生したタイムコード（期間）において要求階層を高め、それ以外のタイムコードでは要求階層を低下させるなどの処置により、圧縮効率を高めることが可能である。なお、試合属性の生成には分析装置１４０が必須であるため、分析装置１４０が接続されていない場合は、試合属性は定義できない。

図７は、属性データを生成する処理を示したフローチャートであり、Ｓ３０３の処理の詳細を示している。Ｓ７０１において、ＣＰＵ１０１は、コンテンツにエリア属性が定義されているか否かを判断する。ＹＥＳの場合はＳ７０２に、ＮＯの場合はＳ７０４にそれぞれ処理が進む。Ｓ７０２において、ＣＰＵ１０１は、コンテンツに試合属性が定義されているか否かを判断する。ＹＥＳの場合はＳ７０３に、ＮＯの場合はＳ７０５にそれぞれ処理が進む。試合属性が存在する場合（Ｓ７０１、Ｓ７０２でＹＥＳ）、Ｓ７０３において、ＣＰＵ１０１は、属性データとして試合属性を選択する。エリア属性が存在しない場合（Ｓ７０１でＮＯ）、Ｓ７０４において、ＣＰＵ１０１は、属性データとして競技属性を選択する。エリア属性が存在するが試合属性が存在しない場合（Ｓ７０１でＹＥＳ、Ｓ７０２でＮＯ）、Ｓ７０５において、ＣＰＵ１０１は、属性データとしてエリア属性を選択する。Ｓ７０６では、選択された属性を基に、図６Ａ，図６Ｂに示した表６ａ、６ｃ、６ｄのような属性データを生成する。例えば、コンテンツにエリア属性としてエリア０，１，２の範囲を示す座標（例えば、(x0,y0)〜(x1,y1)など）が定義されている場合、ＣＰＵ１０１はこれを用いて表６ｃのような属性データを生成する。また、コンテンツにエリア属性に加えて注目度の高いプレーが発生したタイムコードが含まれている場合、ＣＰＵ１０１は、表６ｄのような属性データを生成する。

図８は、モデルデータを表示装置に送信する処理過程を示したフローチャートであり、Ｓ３０４の詳細を示している。Ｓ８０１において、ＣＰＵ１０１は、サーバである画像処理装置１００をクライアントである表示装置（ユーザ端末１３０）からのリクエスト待機状態にする。Ｓ８０２において、仮想視点映像の視聴者であるユーザによるユーザ端末１３０への所定の操作に応じて、ユーザ端末１３０（ＣＰＵ１３１）は、映像再生用のアプリケーションを起動する。Ｓ８０３において、ユーザ端末１３０（ＣＰＵ１３１）は、ユーザが視聴したいコンテンツを選択する。コンテンツ選択にはアプリケーションが用いられる。映像再生用のアプリケーションの起動後、ユーザ端末１３０（ＣＰＵ１３１）は、図９に示されるようなコンテンツ選択ウィンドウ９０１を表示部１３５に表示する。ユーザは所望のアイコン９０２をタッチすることで、所望のコンテンツを選択することができる。コンテンツが選択されると、ユーザ端末１３０（ＣＰＵ１３１）は、画像処理装置１００に対してモデルデータをダウンロードするリクエストを送信する。その際、ユーザ端末１３０（ＣＰＵ１３１）は、ユーザ端末１３０が備える表示装置（表示部１３５）のディスプレイ解像度、ＣＰＵ１３１やＧＰＵのスペック情報も画像処理装置１００に送信する。

なお、ユーザ端末１３０は、コンテンツ選択ウィンドウ９０１を表示するために、画像処理装置１００から選択対象となるコンテンツのリストを取得しておく。リストに掲載されているコンテンツの各々は、時間的に連続した１まとまりの多視点フレームに対応する。例えば、プレー内容（分析装置１４０による分析結果）に基づいて、そのプレーが発生した近辺のタイムコードを含む一連の多視点フレームにより１つのコンテンツが生成されてもよい。例えば、ステップＳ４１１で説明したように、プレー情報ごとに、紐づけられたモデルデータを１つのコンテンツとしてもよい。或いは、例えば、試合の前半の多視点フレームと後半の多視点フレームで別々のコンテンツが生成されてもよい。なお、各コンテンツには、プレー内容とその発生位置に基づいて自動的に設定された仮想カメラの位置、姿勢（方向）が定義されていてもよい。

画像処理装置１００は、Ｓ８０１で、ユーザ端末１３０から送信対象のコンテンツのリクエストを受け付けると、Ｓ８０４以降の処理により、送信対象とする階層を決定し、決定された階層のモデルデータを送信する。まず、Ｓ８０４では、画像処理装置１００のＣＰＵ１０１が通信回線の空き状況を取得する。Ｓ８０５において、ＣＰＵ１０１は、ユーザ端末１３０から受信したスペック情報から、モデルデータのスペック階層を設定する。例えば、ＣＰＵやＧＰＵの性能がローエンドであれば、処理負荷の高い階層３や階層２のモデルデータを処理できないので、スペック階層を階層１に設定する。また、ディスプレイ解像度が低い場合は、階層間の差異が認識しにくいので、スペック階層を階層２以下（すなわち階層１または階層２）に設定する。Ｓ８０６では、ＣＰＵ１０１は、Ｓ８０５で設定されたたスペック階層が階層１であるか否かを判断する。階層１である場合は、処理はＳ８１１に進み、それ以外の場合は、処理はＳ８０７に進む。

Ｓ８０７において、ＣＰＵ１０１は、Ｓ３０３で生成された属性データを用いて送信用モデルデータを生成する。送信用モデルデータは、図１１に示すように、タイムコードごとに生成される。図１１（ａ）はタイムコード０番目における送信用データである。データ構造を記述するヘッダ部と、背景モデルデータ、被写体モデルデータから構成され、被写体ごと（選手ごと）に要求階層に応じた階層のデータを保持する。ただし、全ての被写体が最低階層である階層１のモデルデータを必ず保持するものとする。これは、後述する仮想視点映像生成時に利用するためである。図１１（ｂ）はタイムコード１番目の送信用データを示す。背景モデルデータは重複するため、削減されている。また、各被写体のモデルデータの階層も属性データに合わせて変更されている。これらを全タイムコード分つなぎ合わせたものが、送信用モデルデータとなる。このとき、要求階層がスペック階層よりも上位の階層である場合、その要求階層をスペック階層まで引き下げる。このように表示装置（ユーザ端末１３０の表示部１３５）の能力に基づいて送信用モデルデータを構成するモデルデータの階層が制限される。

Ｓ８０８では、ＣＰＵ１０１は、Ｓ８０４で取得した通信回線の空き状況と、Ｓ８０７で生成した送信用モデルデータのサイズから、送信用モデルデータを送信可能であるかを判断する。通信可能と判断された（ＹＥＳ）場合、処理はＳ８１４に進み、通信できないと判断された（ＮＯ）場合、処理はＳ８０９に進む。Ｓ８０９において、ＣＰＵ１０１は、属性データに記述されている要求階層を１段階低下させて送信用モデルデータを生成する。例えば、図６Ａ（ｃ）の表６ｃのエリア０の要求階層は３から２に、エリア２の要求階層は２から１に低下させる。ただし、要求階層が１である場合は、それ以上低下させない。Ｓ８１０では、ＣＰＵ１０１は、Ｓ８０４で取得した通信回線の空き状況とＳ８０９で生成した送信用モデルデータのサイズから、送信用モデルデータを送信可能であるかを判断する。送信可能な場合、処理はＳ８１４に進み、送信可能でない場合、処理はＳ８１１に進む。Ｓ８１１では、ＣＰＵ１０１はすべての要求階層を１に設定して送信用モデルデータを生成する。Ｓ８１２では、ＣＰＵ１０１は、Ｓ８０４で取得した通信回線の空き状況と、Ｓ８１１で生成した送信用データのサイズから、送信用モデルデータを送信可能であるかを判断する。ＹＥＳの場合、処理はＳ８１４に進み、ＮＯの場合、処理はＳ８１３に進む。Ｓ８１３では、ＣＰＵ１０１は、通信回線に空き容量が出るまで（他のユーザが通信を完了するまで）待機する。Ｓ８１４では、送信用モデルデータを画像処理装置１００から表示装置（ユーザ端末１３０）に送信する。

Ｓ８１５では、ユーザ端末１３０（ＣＰＵ１３１）がモデルデータを受信する。Ｓ８１６では、ＣＰＵ１３１が、受信したモデルデータを用いて仮想視点映像を生成し、表示部１３５に再生する。ユーザ端末１３０においてアプリケーションを実行しているＣＰＵ１３１は、画像処理装置１００からモデルデータを受信すると、図９（ｂ）に示されるような仮想視点ウィンドウ９０３に遷移する。仮想視点ウィンドウ９０３では、選手モデルデータ９０４、背景モデルデータ９０５が表示されており、画面へのタッチ操作等に応じて任意のカメラ位置／方向／画角で映像を表示することが可能である。また、タイムコードスライダバー９０６を用いて、任意のタイムコードの映像に移動することも可能である。以下、図１０を参照して、仮想視点映像の生成に関して説明する。

図１０は、ユーザ端末１３０による仮想視点映像生成の処理を説明したフローチャートであり、Ｓ８１６の詳細を示している。Ｓ１００１では、ＣＰＵ１３１は、ユーザのタッチ操作に合わせた仮想カメラの位置、方向、画角を設定する。Ｓ１００２では、ＣＰＵ１３１は、階層１のモデルデータを用いて、設定された仮想カメラの位置、方向、画角における映像生成を行う（映像１）。映像生成は、周知のコンピュータグラフィックスの技術を用いることで実施可能である。

Ｓ１００３では、ＣＰＵ１３１は、送信されたモデルデータに階層２のモデルデータが存在するか否かを判断する。ＹＥＳの場合、処理はＳ１００４に進み、ＮＯの場合、処理はＳ１００５に進む。Ｓ１００４において、ＣＰＵ１３１は、階層２のモデルデータを用いて、設定された仮想カメラの位置、方向、画角における映像生成を行う（映像２）。Ｓ１００５において、ＣＰＵ１３１は、送信されたモデルデータに階層３のモデルデータが存在するか否かを判断する。ＹＥＳの場合、処理はＳ１００６に進み、ＮＯの場合、処理はＳ１００７に進む。Ｓ１００６では、ＣＰＵ１３１は、階層３のモデルデータを用いて、設定された仮想カメラの位置、方向、画角における映像生成を行う（映像３）。

Ｓ１００７では、ＣＰＵ１３１は、連続するタイムコード間（前タイムコードと現タイムコード）で選手モデルの階層に差異があるかを判断する。これは、例えば、タイムコード０では選手２の階層が１であるが、タイムコード１では階層が３になるようなケースである。差異がある場合、処理はＳ１００８に進み、差異がない場合、処理はＳ１００９に進む。Ｓ１００８では、ＣＰＵ１３１は、映像１と映像２、３を合成（たとえばアルファブレンディング）して被写体映像を生成する。これは、タイムコード間で階層に差異がある場合、画質が急激に変動することを防ぐためである。一方、Ｓ１００９では、ＣＰＵ１３１は、映像１の被写体領域を高画質の映像２または映像３で置換して被写体映像を生成する。Ｓ１０１０では、ＣＰＵ１３１は、背景モデルをレンダリングして背景映像を生成する。Ｓ１０１１では、ＣＰＵ１３１は、被写体映像と背景映像を合成し、仮想視点映像を生成する。なお、Ｓ１００７において、タイムコード０では選手２の階層が２であるが、タイムコード１では階層が１になるようなケース（連続するタイムコードにおいて階層が低下するケース）では、差異がないと判断している。このようなケースでは、被写体の重要度が低下しており、画質が急激に変化しても問題がないためである。なお、上記では階層１の映像から階層２または３の映像に変化した場合に映像の合成を行うようにし、他の場合には合成を行わないようにしたが、これに限られるものではない。例えば、被写体のモデルデータの階層が変化した場合に変化前の階層の被写体映像と変化後の階層の被写体映像を合成するようにしてもよい。

以上説明したように、第１実施形態の画像処理装置によれば、被写体ごとの３次元のモデルデータが複数の階層で生成され、競技や実試合の分析結果などのコンテンツの特性を基に被写体の重要度が決定される。そして、重要度に応じて送信用モデルデータを構成するモデルデータの階層が設定されるので、インタラクティブ操作に対応した仮想視点映像のためのモデルデータを適切に生成し、且つ、効率よく送信することができる。

＜第２実施形態＞
第２実施形態では、被写体の競技への関与度と注目度、ユーザの嗜好性から属性データを修正する構成に関して説明する。なお、第１実施形態と重複するシステム、処理の説明は省略する。

第１実施形態では、競技の種類、エリア、重要なプレー等の発生イベントを用いて、各被写体のモデルデータの重要性を判断し、使用する階層を決定した。第２実施形態では、さらに被写体である選手の注目度（例えば、有名選手か否か）、ユーザの嗜好性（例えば、好きな選手か否か）、競技への関与度（例えば、ボールとの距離）を用いて要求階層を変更する。図１２（ａ）において、表１２ａは、注目度、嗜好性、関与度に基づく階層の変更例を示している。ボールと選手との距離である関与度は、ＣＰＵ１０１が、映像データを解析して自動的に取得する。注目度、嗜好性は、ユーザ端末１３０上の所定のユーザインターフェースを介してユーザが設定した内容である。ユーザによる設定は、ユーザ端末１３０から通信により画像処理装置１００へ通知される。表１２ａの要求階層の欄は、属性データに基づいて決定された各被写体のモデルデータの階層の例である。また、表１２ａのＳ１２０１、Ｓ１２０３の欄に記載された階層は、それぞれ、図１２（ｂ）のフローチャートのＳ１２０１、Ｓ１２０３において、注目度、嗜好性、関与度に基づいて変更された後の階層を示している。

図１２（ｂ）は、図３のＳ３０３において属性データを生成した後に、各被写体（選手）について行う階層の変更処理を説明したフローチャートである。Ｓ１２０１において、画像処理装置１００のＣＰＵ１０１は、表１２ａ中の注目度と嗜好性に基づいて、各選手の階層を変更する。例えば、注目度、嗜好性がともに低い選手については、要求階層を１つ下げる、注目度と嗜好性がともに高い選手については要求階層を最高階層にするといった、あらかじめ設定されたルールに従って階層が変更される。本例では、選手Ｎは要求階層が階層１であったが、注目度、嗜好性が高いため、階層を３に引き上げている。一方、選手１は要求階層が階層２であったが、注目度、嗜好性が低いため、階層を１に引き下げている。

Ｓ１２０２では、ＣＰＵ１０１は、変動前後で送信用モデルデータのサイズが増加するか否かを判断する。ＹＥＳの場合はＳ１２０３に進み、ＮＯの場合は処理を終了する。Ｓ１２０３では、送信用モデルデータのサイズを下げるため、表１２ａの関与度（ボールとの距離）に応じて、階層を引き下げる。例えば、選手２はＳ１２０１後において階層３であったが、ボールとの距離が離れているため、競技への関与度が低いと判断し、階層２に引き下げる。

以上説明したように、第２実施形態によれば、被写体ごとに生成された複数の階層のモデルデータから使用する階層を選択するにおいて、被写体の注目度、ユーザの嗜好性、競技への関与度というような、個々の被写体に関する属性が考慮される。結果、より適切な送信用モデルデータを生成することができ、インタラクティブ操作に対応した仮想視点映像のためのモデルデータを効率よく送信することができる。なお、上記では、個々の被写体に関する属性として、関与度、注目度、嗜好性を例示したが、これらに限られるものではない。また、Ｓ１２０１では注目度と嗜好性の両方を考慮したが、いずれか一方を考慮する構成であってもよい。

＜第３実施形態＞
第２実施形態では、個々の被写体に設定される属性に基づいて要求階層を変更する構成を説明した。第３実施形態では、３次元モデルデータをストリーム送信する際に、仮想カメラの位置、姿勢、画角に応じて要求階層を変更し、送信用モデルデータを最適化する構成に関して説明する。なお、第１実施形態、第２実施形態と重複するシステム、処理の説明は省略する。

ストリーム送信では、画像処理装置１００からタイムコードＭのモデルデータを送信し、表示装置で受信・再生を行う。その後、ユーザ端末１３０から仮想カメラの位置・姿勢をフィードバックし、それを基に、画像処理装置１００はタイムコードＭ＋１のモデルデータを送信する。このような処理を順次繰り返すことにより、全データの受信を待たずに、表示装置でインタラクティブな仮想視点映像再生が可能である。このとき、前タイムコードの仮想カメラ位置・姿勢を考慮することにより、より最適な階層を選択することが可能である。

図１３（ａ）は、あるタイムコードＭでの仮想カメラの位置／姿勢／画角を表している。このとき、仮想カメラの画角内および画角内に近い選手は、次のタイムコードにおいても映像に含まれる可能性が高い。一方、画角内から遠く離れた選手は、映像に含まれる可能性が低い。また、仮想カメラとの距離が離れている場合は画質として階層間の差異が発生しにくい。これらの項目をまとめると図１３（ｂ）の表１３ｂのようになる。なお、表１３ｂにおいては、属性データに基づいて設定された要求階層が図１３（ｃ）の処理（ステップＳ１３０１、Ｓ１３０３）により変更される例が示されている。

図１３（ｃ）は、ストリーミング中に階層調整を行う処理を説明したフローチャートである。Ｓ１３０１において、ＣＰＵ１０１は、各選手がカメラの画角内（〇）か否（×）か、もしくは画角に近い領域に存在するか（△）、という項目と、仮想カメラと選手間の距離とを用いて、要求階層を変更する。例えば、選手Ｎは要求階層が１であったが、画角内に近く、仮想カメラとの距離が短いため、階層を３に引き上げる。一方、選手２は要求階層が３であったが、仮想カメラとの距離が長いため、階層を２に引き下げる。

Ｓ１３０２では、ＣＰＵ１０１は、変更の前後で送信用データのサイズが増加するか否かを判断する。ＹＥＳの場合、処理はＳ１３０３に進み、ＮＯの場合は処理を終了する。Ｓ１３０３では、ＣＰＵ１０１は、サイズを下げるため、仮想カメラの移動速度と、仮想カメラと選手間の距離に応じて、階層を引き下げる。なお、仮想カメラの移動速度は前フレームおよびそれ以前のフレームにおける位置姿勢の変化量に基づいて計算される。例えば、仮想カメラの移動速度が高速の場合を考える。このとき、選手２はＳ１３０１後において階層２であったが、仮想カメラとの距離が離れているため、映像内をかなり高速に移動することになる。そのため、階層ごとの画質の差異はほとんど発生しないと判断し、階層１に引き下げる。

以上説明したように、第３実施形態によれば、ユーザ端末において指定されている仮想カメラの位置／姿勢／画角を基に被写体の階層が変更されるので、仮想カメラの状態に応じて適切な送信用モデルデータを生成することができる。なお上記の実施形態では、被写体ごとにデータサイズが異なる複数の階層のモデルデータを生成する例を中心に説明した。しかし、複数の被写体のうち、１又は複数の特定の被写体についてのみ複数の階層のモデルデータを生成するようにしても良い。

＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１００：画像処理装置、１０１：ＣＰＵ、１０２：メインメモリ、１０３：記憶部、１０４：入力部、１０５：表示部、１０６：外部Ｉ／Ｆ部、１０８：ＬＡＮ、１２０：カメラ、１３０：ユーザ端末、１４０：分析装置

Claims (16)

1. 仮想視点の位置及び向きに応じた仮想視点画像を生成するために用いられる素材データを生成する生成装置であって、
   複数のカメラが異なる方向から撮影領域を撮影することで得られる複数の撮影画像に基づいて複数の素材データを生成する生成手段であって、第１素材データと、前記第１素材データより品質が高い第２素材データと、を少なくとも含む複数の素材データを生成する生成手段と、
   前記生成手段により生成された素材データを記憶手段に記憶させる記憶制御手段と、を有し、
   前記記憶制御手段により前記記憶手段に記憶された複数の素材データのうちクライアントから得られる情報に基づいて選択された素材データは、前記クライアントに対して提供されることを特徴とする生成装置。
2. 前記生成装置が前記記憶手段を有することを特徴とする請求項１に記載の生成装置。
3. 前記素材データには、前記仮想視点画像に含まれるオブジェクトの３次元形状を表す３次元形状データが含まれることを特徴とする請求項１又は２に記載の生成装置。
4. 前記素材データには、前記仮想視点画像に含まれるオブジェクトのテクスチャデータが含まれることを特徴とする請求項１乃至３の何れか１項に記載の生成装置。
5. 前記素材データには、前記仮想視点画像に含まれるオブジェクトの３次元形状を表す３次元形状データと、前記仮想視点画像のうちオブジェクトの領域とは異なる背景領域の３次元形状を表す３次元形状データと、が含まれることを特徴とする請求項１乃至４の何れか１項に記載の生成装置。
6. 前記第１素材データは、オブジェクトの３次元形状をメッシュにより表す３次元形状データであり、前記第２素材データは、前記オブジェクトの３次元形状を点群又はボクセルにより表す３次元形状データであることを特徴とする請求項１乃至５の何れか１項に記載の生成装置。
7. 前記クライアントへ提供すべき素材データを、前記クライアントから得られる情報と、前記複数のカメラによる撮影対象の種類に関する情報と、に基づいて決定する決定手段を有することを特徴とする請求項１乃至６の何れか１項に記載の生成装置。
8. 前記撮影対象の種類に関する情報は、前記複数のカメラにより撮影される競技の種類に関する情報、前記複数のカメラにより撮影されるエリアの種類に関する情報、及び、前記複数のカメラにより撮影されるプレーの種類に関する情報のうち、何れか１つを含むことを特徴とする請求項７に記載の生成装置。
9. 前記クライアントへ提供すべき素材データを、前記クライアントから得られる情報と、前記生成装置と前記クライアントとを接続する通信回線の空き状況に基づいて決定する決定手段を有することを特徴とする請求項１乃至８の何れか１項に記載の生成装置。
10. 前記クライアントから得られる情報には、前記クライアントが有するプロセッサ及びディスプレイの能力のうち、少なくとも何れか一方に関する情報が含まれることを特徴とする請求項１乃至９の何れか１項に記載の生成装置。
11. 複数のオブジェクトのうち、第１オブジェクトと第２オブジェクトとで異なる品質の素材データを提供すべきことを前記クライアントから得られる情報に応じて決定する決定手段を有することを特徴とする請求項１乃至１０の何れか１項に記載の生成装置。
12. 前記素材データとしての３次元形状データの品質は、３次元形状を表すための要素の密度により規定されることを特徴とする請求項１乃至１１の何れか１項に記載の生成装置。
13. 仮想視点の位置及び向きに応じた仮想視点画像を生成するために用いられる素材データを生成する生成装置が行う生成方法であって、
    複数のカメラが異なる方向から撮影領域を撮影することで得られる複数の撮影画像に基づいて複数の素材データを生成する生成工程であって、第１素材データと、前記第１素材データより品質が高い第２素材データと、を少なくとも含む複数の素材データを生成する生成工程と、
    前記生成工程により生成された素材データを記憶手段に記憶させる記憶制御工程と、を有し、
    前記記憶制御工程により前記記憶手段に記憶された複数の素材データのうちクライアントから得られる情報に基づいて選択された素材データは、前記クライアントに対して提供されることを特徴とする生成方法。
14. 前記生成装置が前記記憶手段を有することを特徴とする請求項１３に記載の生成方法。
15. 前記素材データには、前記仮想視点画像に含まれるオブジェクトの３次元形状を表す３次元形状データが含まれることを特徴とする請求項１３又は１４に記載の生成方法。
16. コンピュータを請求項１乃至１２の何れか１項に記載の生成装置の各手段として動作させるためのプログラム。

Images