(57)【要約】 【課題】  データの３Ｄ＋Ｆ符号化及び三次元レンダリングのための新規なシステム及びフォーマットを提供する。【解決手段】  第１及び第２の２Ｄ画像を結合することにより融合ビュー２Ｄ画像及び生成ベクトルを生成し、前記融合ビュー２Ｄ画像は第１及び第２の２Ｄ画像の要素に関連する情報を包含し、前記生成ベクトルは、第１及び第２の２Ｄ画像を回復するために融合ビュー２Ｄ画像の要素に対して実行されるべき動作を示す。本発明によれば、高品位な工業規格画像品質を提供しつつ、従来技術に比べて一層低い電力消費量で３Ｄレンダリングが可能になる。【選択図】  図３
2012522285.tif 000002
【特許請求の範囲】
【請求項１】
(a)第１のデータセットを受信するステップと、
(b)第２のデータセットを受信するステップと、
(c)第１のデータセットと第２のデータセットを結合することによりデータの融合セットと関連生成ベクトル(generating-vectors)とを生成するステップと、
前記融合データセットは、前記第１のデータセット及び前記第２のデータセットの要素に関連する情報を包含し、
前記生成ベクトルは、前記第１のデータセット及び前記第２のデータセットを回復するために融合データセットの要素に対して実行されるべき操作を示す、
(d)融合データセットと前記生成ベクトルとを相互に関連して格納するステップと、
からなることを特徴とするデータ格納方法。
【請求項２】
(a)第１の視角からのシーン（情景）の第１の２次元（２Ｄ）画像を受信するステップと、
(b)第２の視角からのシーンの第２の２Ｄ画像を受信するステップと、
(c)前記第１の２Ｄ画像と前記第２の２Ｄ画像を結合することにより、融合ビュー２Ｄ画像と関連生成ベクトルとを生成するステップと、
前記融合ビュー２Ｄ画像は、前記第１の２Ｄ画像及び前記第２の２Ｄ画像の要素に関連する情報を包含し、前記生成ベクトルは、前記第１の２Ｄ画像及び前記第２の２Ｄ画像を回復するために、前記融合ビュー２Ｄ画像の要素に対して実行されるべき操作を示す、
(d)前記融合ビュー２Ｄ画像及び前記生成ベクトルとを相互に関連して格納するステップと、
からなることを特徴とするデータの符号化方法。
【請求項３】
(a)第１の２Ｄ画像及び第２の２Ｄ画像の要素に関連する情報を包含する融合ビュー２Ｄ画像を提供するステップと、
(b)前記融合ビュー２Ｄ画像に関連する生成ベクトルを提供するステップと、
前記生成ベクトルは、前記第１の２Ｄ画像及び第２の２Ｄ画像をレンダリングするために、前記融合ビュー２Ｄ画像の要素に対して実行されるべき操作を示す、
(c)前記融合ビュー２Ｄ画像及び生成ベクトルを用いて、前記第１の２Ｄ画像をレンダリングするステップと、
からなることを特徴とするデータの復号化方法。
【請求項４】
(D) 前記第２の２Ｄ画像をレンダリングするステップを更に包含する
ことを特徴とする請求項３に記載の方法。
【請求項５】
(a)１個以上のプロセッサを含有する処理システムと、
前記処理システムは、
(i)第１のデータセットを受信し、
(ii)第２のデータセットを受信し、
(iii)前記第１のデータセット及び第２のデータセットを結合することにより、融合データセット及び関連生成ベクトルを生成し、
前記融合データセットは、前記第１のデータセット及び第２のデータセットの要素に関連する情報を包含し、前記生成ベクトルは、前記第１のデータセット及び第２のデータセットを回復するために、前記融合データセットの要素に対して実行されるべき操作を示す、
ように構成されており、
(b)前記融合データセットと生成ベクトルとを相互に関連して格納するように構成されている格納モジュールと、
からなる
ことを特徴とするデータの格納システム
【請求項６】
前記データは、Ｈ．２６４フォーマットである
ことを特徴とする請求項５に記載のシステム。
【請求項７】
前記データは、ＭＰＥＧ４フォーマットである
ことを特徴とする請求項５に記載のシステム。
【請求項８】
(a)１個以上のプロセッサを含有する処理システムと、
前記処理システムは、
(i)第１の視角からのシーン（情景）の第１の２次元（２Ｄ）画像を受信し、
(ii)第２の視角からのシーンの第２の２Ｄ画像を受信し、
(iii)第１の２Ｄ画像と第２の２Ｄ画像を結合することにより融合ビュー２Ｄ画像と関連生成ベクトルとを生成し、
前記融合ビュー２Ｄ画像は、前記第１の２Ｄ画像及び第２の２Ｄ画像の要素に関連する情報を包含し、前記生成ベクトルは、前記第１の２Ｄ画像及び第２の２Ｄ画像を回復するために、前記融合ビュー２Ｄ画像の要素に対して実行されるべき操作を示す、
ように構成されており、
(b)前記融合ビュー２Ｄ画像及び生成ベクトルとを相互に関連して格納するように構成されている格納モジュールと、
からなる
ことを特徴とするデータの符号化システム。
【請求項９】
(a)１個以上のプロセッサを含有する処理システムからなり、
前記処理システムは、
(i)第１の２Ｄ画像及び第２の２Ｄ画像の要素に関連する情報を包含する融合ビュー２Ｄ画像を提供し、
(ii)前記融合ビュー２Ｄ画像に関連する生成ベクトルを提供し、
前記生成ベクトルは、前記第１の２Ｄ画像及び第２の２Ｄ画像をレンダリングするために、前記融合ビュー２Ｄ画像の要素に対して実行されるべき操作を示す、
(iii)前記融合ビュー２Ｄ画像及び前記生成ベクトルを用いて、前記第１の２Ｄ画像をレンダリングする、
ように構成されている、
ことを特徴とするデータの復号化システム。
【請求項１０】
(a)１個以上のプロセッサを含有する処理システムと、
前記処理システムは、
(i)第１の２Ｄ画像及び第２の２Ｄ画像の要素に関連する情報を包含する融合ビュー２Ｄ画像を提供し、そして
(ii)融合ビュー２Ｄ画像に関連する生成ベクトルを提供し、
前記生成ベクトルは、第１の２Ｄ画像及び第２の２Ｄ画像をレンダリングするために融合ビュー２Ｄ画像の要素に対して実行されるべき操作を示す、
するように構成されており、
(b)前記処理システムに対して操作的に結合されたディスプレイモジュールと、
前記ディスプレイモジュールは、
(i)融合ビュー２Ｄ画像及び生成ベクトルを用いて、前記第１の２Ｄ画像をレンダリングし、
(ii)第１の２Ｄ画像を表示する、
ように構成されている、
からなることを特徴とするデータの処理システム。
【請求項１１】
前記ディスプレイモジュールは、
(i)前記融合ビュー２Ｄ画像及び生成ベクトルを用いて、前記第２の２Ｄ画像をレンダリングし、
(ii)前記第２の２Ｄ画像を表示する、
ように更に構成されている
ことを特徴とする請求項１０に記載のシステム。
【請求項１２】
前記ディスプレイモジュールは、レンダリングを実行するように構成された集積回路を包含する
ことを特徴とする請求項１０に記載のシステム。
【請求項１３】
前記ディスプレイモジュールは、前記融合ビュー２Ｄ画像及び前記生成ベクトルを用いて前記第１の２Ｄ画像をレンダリングするために、一次元コピーマシンを有するように構成された集積回路を包含する
ことを特徴とする請求項１０に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータビジョン及びグラフィックスに関し、特に、三次元符号化及びレンダリングのための、特にモバイルデバイス（例、携帯電話）用のシステム及びフォーマットに関する。
【背景技術】
【０００２】
三次元（３Ｄ）立体視技術は近代的なビデオ技術における次世代革命として述べることが出来る。立体視は三次元の視覚認知であり、特にシーン（情景）の２個の別々の画像を得て、そしてこれらの画像を３Ｄ認知ができるように結合する。３Ｄ表現の基礎としての立体視のアイディアは１８００年代からあった。しかし、技術的障壁のために殆ど普及しなかった。一つの見解として、現在の過剰な二次元（２Ｄ）撮像技術は、３Ｄ撮像への折衷案として見られる。現在、莫大な研究開発が３Ｄ撮像に集中している。最近の進歩として次ぎのものが挙げられる。
(1)立体視用のメガネを着用すること無く、ユーザが３Ｄのステレオ及びマルチビュー画像を見ることを可能にする３Ｄ実体鏡学的ＬＣＤディスプレー。
(2)３Ｄムービーシアターが一層普遍的になりつつある(Pixar, Disney 3D及びIMAX)。
(3)３Ｄプログラムのテレビ放送計画の増大。
(4)３Ｄムービー（例えば、アヴァター(Avatar)）はひときわ優れた人気のある成功を納めた。
【０００３】
多くの分野及びアプリケーションで３Ｄ画像技術の取り込みが計画されている。３Ｄテレビ、３Ｄスマートフォン、３Ｄタブレットが巨大な消費者マーケットがある。現在、高品位（ＨＤ）テレビ（ＨＤＴＶ）は、ビデオ品質の基準である。印象的なＬＣＤ解像度（７２０ｐ）を有するＨＤスマートフォンがモバイルマーケットに出現している。３Ｄ画像技術はＨＤテレビに新たな次元をもたらすであろう。
【０００４】
本明細書において、３Ｄ立体視画像技術、３Ｄ立体視、３Ｄ画像技術は、特に断らない限り互換的に使用する。３Ｄ立体視は、２Ｄ画像技術に比較してコンテンツ情報の品質のダブリングの基本的問題を内包し、格納及び伝送帯域要件をダブリングに置き換える。従って、３Ｄ画像技術のために必要な情報を、好ましくは１／２以下まで減らす方法が開発されつつある。
【０００５】
図１を参照する。図１は一般的な３Ｄコンテンツ及び技術チェーンのブロック図である。ステージ１００において、一般的にコンテンツ又は３Ｄコンテンツと呼ばれるソース３Ｄ画像技術情報（例えば、３Ｄムービー）は、コンテンツプロバイダー１１０により生成される。３Ｄ情報の減縮は、符号化ステージ（この場合は３Ｄ符号化ステージ）１０２において、一般的に、符号化アルゴリズムと呼ばれるアルゴリズムにより行われる。３Ｄ符号化アルゴリズムの目的は、ソースフォーマットの所定量のソース３Ｄ画像技術情報を符号化フォーマット（画像フォーマットとも呼ばれる）の減縮情報に変換することである。本明細書において、符号化された３Ｄコンテンツは符号化情報と呼ばれる。
【０００６】
符号化（エンコーディング）は一般的に伝送前に行われる。アプリケーションサーバー１１２において、オフラインで行われる。格納用のコンテンツの符号化を行うのは、アイチユーン(Itunes)、ユーチューブ(YouTube)などであり、格納された符号化情報をオンデンマンド(on-demand)で伝送可能になる。
【０００７】
ステージ１０４において、通信サービスプロバイダー（本例では、セルラーオペレーター）１１４による伝送（例えば、第４世代“４Ｇ”ワイヤレス通信規格による伝送）後、符号化情報は、受信装置１２０により復号化（デコーディング）させ、ディスプレイ用にレンダリングさせなければならない。受信装置１２０は、ユーザデバイス又はクライアントデバイスとも呼ばれる。復号化は、符号化情報を符号化フォーマットからレンダリングに適したフォーマットに変換することを含む。レンダリングは、復号化情報からディスプレイ上に表示されるべき３Ｄコンテンツの十分な情報を生成することを含む。３Ｄ立体視のために、２つのビュー（一般的に、ユーザの左目及び右目にそれぞれ関連してレフトビュー及びライトビューと呼ばれる）を生成しなければならない。
下記で詳細に説明するように、復号化及びレンダリング・ステージ１０６は、従来、携帯電話内のアプリケーションプロセッサで、製造業者１１６により実行される。符号化フォーマット、アプリケーション、受信装置に応じて、復号化及びレンダリングは、別々のステージで行われるか又は或る程度まで一緒に行われる。立体視を実現するために、オリジナル３Ｄコンテンツのレフトビュー及びライトビューの両方ともレンダリングし、そして、ユーザが眺めるために、ディスプレイ１０８に送信しなければならない。ディスプレイは一般的に、ディスプレイ製造業者１１８により提供され、また、ユーザデバイス内に一体化されている。
【０００８】
現在開発されている最も一般的なレンダリング技術は２Ｄ＋深度(Depth)画像（「奥行き画像」ともいう）フォーマットに基づく。これはＭＰＥＧフォーラムでプロモートされている。２Ｄ＋深度画像フォーマットの基本原理は、第１のビュー（例えば、ライトビュー）の２Ｄ画像と深度画像との組合せである。２Ｄ＋深度画像フォーマットの復号化は、第１のビュー（例えば、ライトビュー）から第２のビュー（例えば、レフトビュー）を生成するために、受信装置で複雑なアルゴリズム（これと共に高電力要件）が必要である。
【０００９】
３Ｄ画像技術アーキテクチャ、符号化、フォーマット、復号化、レンダリング及びディスプレイに関する背景及び参照のために、従来の２Ｄ及び２Ｄ＋深度フォーマットについて説明する。再び図１を参照する。２Ｄ＋深度フォーマットは、基本的に符号化ステージ１０２と復号化及びレンダリングステージ１０６において実行する。前記のように、２Ｄ＋深度画像フォーマットの基本原理は、第１のビューの２Ｄ画像と深度画像との組合せである。一般的に、２Ｄ画像は２つのビューのうちの何れか一方（例えば、レフトビュー又はライトビュー）若しくは２つのビューのうちの何れか一方のビューに近いビュー（例えば、センタービュー）である。この２Ｄ画像は、深度マップ(depth map)を使用すること無しに見ることができ、コンテンツのノーマルな２Ｄビューを示す。「深度マップ(depth map)」とは、２５６階調のモノトーンの映像を用いて、奥行き情報を表現する映像フォーマットである。
【００１０】
図２Ａを参照する。３次元物体のセンタービューの２Ｄ画像において、物体２００，２０２及び２０４は、それぞれ観察者から遠く離れている。図２Ｂを参照する。これは単純化された深度画像である。観察者から物体までの深度（距離）は、グレイスケール画像として示されている。物体２１０、２１２、２１４のグレイ色調は、異なる点によるブロック図で示される関連ポイントの深度を表す。
【００１１】
図３を参照する。代表的な２Ｄアーキテクチャのブロック図である。携帯電話アーキテクチャをビデオプレイバック（また、ビデオストリーミングにも適用可能である）のプロセスフローチャートの一例として使用する。符号化情報（この場合には、圧縮ビデオパケット）を、アプリケーションプロセッサ３０４内のビデオデコーダ（復号器）３０２によりメモリカード３００から読み出し、外部バスインターフェース３０６を介してビデオデコーダメモリ３０８（一般的に、アプリケーションプロセッサに対する外部専用メモリ）に送信する。符号化情報（ビデオパケット）は、ビデオデコーダ３０２により復号化され、ディスプレイインターフェース３１０に送信される復号化フレームを生成する。復号化は典型的には復元を含む。ビデオパケットがＨ．２６４フォーマットである場合、ビデオデコーダ３０２はＨ．２６４デコーダであり、デルタデータ（従前フレームと現行フレームとの間の相違に関する情報）を用いて新規なフレームを生成するために、メモリ３０８内に格納された従前フレーム（この場合、ダブルフレームバッファとしての構成も含む）からパケットを読み出す。Ｈ．２６４復号化フレームは、後続の符号化パケットを復号化するのに使用される、ダブルフレームバッファ内に格納するためのメモリ３０８にも送信される。
【００１２】
復号化フレームは、ディスプレイシステム３２２内のディスプレイシステムインターフェース３１２を介して、アプリケーションプロセッサ３０４内のディスプレイインターフェース３１０から（例えば、ＭＩＰＩ  ＤＳＩインターフェースを介して）ディスプレイコントローラ３１４（この場合、ＬＣＤコントローラ）に送信され、復号化フレームをディスプレイメモリ３２０内に格納する。ディスプレイメモリ３２０から、ＬＣＤコントローラ３１４は、ディスプレイドライバ３１６を介して復号化フレームをディスプレイ３１８に送信する。ディスプレイ３１８は、復号化フレームをユーザに提供するための特定のデバイス及びアプリケーションに適するように、構成されており、これにより、ユーザは所望のコンテンツを眺めることができる。
【００１３】
場合により、２Ｄアーキテクチャは、サービスプロバイダー通信モジュール３３０を包含することもできる。この場合、セルラフォンは、セルラフォンサービスに無線周波数（ＲＦ）フロントエンドを提供する。場合により、ユーザ通信モジュールは、ユーザにローカル通信（例えば、ブルートゥース又はＷｉ−Ｆｉ）を提供することもできる。サービスプロバイダー及びユーザ通信の両方ともユーザデバイスにコンテンツを提供するために使用できる。
【００１４】
図４を参照する。図４は、ユーザデバイスへのビデオのプロセスフロー（処理流れ）に関する代表的な２Ｄ＋深度アーキテクチャのブロック図である。携帯電話アーキテクチャを一例として再度使用する。一般的に、２Ｄ＋深度のプロセスフロー（処理流れ）は、２Ｄの処理流れと類似しているが、大量のデータを処理しなければないこと及び立体視画像技術用のレフトビュー及びライトビューの両方を生成するために、追加処理が必要である点で顕著に相違する。
【００１５】
符号化情報は、メモリカード３００から読み出される。この場合、各フレームに付随する２個の２Ｄ画像を包含する（前記のように、一方の２Ｄ画像は第１のビューであり、他方の２Ｄ画像は深度画像（奥行き画像）である）。復号化フレーム（復元）を生成するために、ビデオデコーダ及び３Ｄレンダリングモジュール４０２により符号化情報は復号化される。ビデオデコーダ３０２（図３参照）が復号化を一度だけ行う２Ｄプレイバックと異なり、２Ｄ＋深度プレイバックの場合、ビデオデコーダ４０２は、各フレームについて復号化を２回（すなわち、２Ｄ画像についての復号化を１回また深度マップについての復号化を１回、計２回）行わなければならない。ビデオパケットがＨ．２６４フォーマットである場合、深度マップは圧縮されたグレイスケール２Ｄ画像であり、深度マップの復号化のために、ビデオデコーダ及び３Ｄレンダリングメモリ４０８において、追加的なダブルバッファが必要である。メモリ４０８は通常、アプリケーションプロセッサの外部専用メモリとして実装されており、この場合、メモリ３０８のサイズの１．５倍の容量を有する。復号化フレームを処理し、立体視に必要なレフトビューとライトビューをレンダリングするために、ビデオデコーダ４０２はハードウエアレンダリングマシン（図示されていない）を包含する。
【００１６】
各フレームについてレンダリングされたレフトビュー及びライトビューは、ディスプレイシステム３２２内のディスプレイシステムインターフェース３１２を介してアプリケーションプロセッサ３０４内のディスプレイインターフェース３１０から、ディスプレイコントローラ３１４（この場合、ＬＣＤコントローラ）に送信される。前記の２Ｄプレイバックと比べて、２倍量のデータが送信されるので、通信チャネルは動作のための一層高い帯域幅と電力を必要とする。更に、ＬＣＤコントローラは１個ではなく２個のビューを処理するので、高帯域幅と高電力を必要とする。各ビューはディスプレイメモリ４２０に格納される。このメモリ４２０は、類似の２Ｄディスプレイメモリ３２０（図３参照）のサイズの２倍の容量を有することができる。ディスプレイメモリ４２０から、ＬＣＤコントローラ３１４は、ディスプレイドライバ３１６を介して復号化フレームを３Ｄディスプレイ４１８に送信する。出力分析を行った結果、２Ｄ＋深度処理には、２Ｄ処理に比較して、名目的に５０％超の電力と２倍量の帯域幅と２倍程度までのメモリ容量が必要であった。
【００１７】
図３及び図４の説明から明らかなように、２Ｄ処理から２Ｄ＋深度（奥行き）処理へユーザデバイスを更新するには、デバイス内の多数の箇所を大幅に変更しなければならない。特に、新規なハードウエア（例えば、追加のメモリと新たなビデオデコーダ及び新たな実行可能コード（一般的に、ソフトウェアと呼ばれている）など）が、アプリケーションプロセッサ３０４に対して必要である。２Ｄ＋深度の増大した電力消費量を最小化するために、これらの新規ハードウエアが必要である。
【００１８】
第１のビュー（例えば、ライトビュー）から第２のビュー（例えば、レフトビュー）を生成するために、２Ｄ＋深度画像フォーマットの復号化は、受信装置について複雑なアルゴリズム（及び付随的な高電力要件）が必要である。複雑なレンダリングアルゴリズムは幾何学的計算（例えば、レフト及びライトビューのレンダリングに使用され得る左及び右画像間の不均衡の計算）を含むことができる。レンダリングされた画像の幾つかの部分は右目からのみ又は左目からのみ見ることが出来る。第２の画像内に見ることが出来ない第１の画像部分は閉塞されるべきと言われる。従って、レンダリング処理を行いながら、レンダリングされる全てのピクセル（画素）は閉塞についてテストされなければならない。これに対して、２Ｄ画像で見ることが出来ないピクセルはオーバーヘッド情報からレンダリングされなければならない。これはレンダリング処理を複雑にし、しかも時間がかかる。更に、２Ｄ＋深度内に符号化されたコンテンツに応じて、大量のオーバーヘッド情報を符号化情報と共に伝送しなければならないこともある。
【００１９】
３Ｄ画像技術に関する前記の従来技術の説明から明らかなように、アーキテクチャ実装要件は受信装置にとって重要である。特に、携帯型モバイルデバイス（例えば、スマートフォン）の場合、従来の３Ｄ画像技術アーキテクチャは、ハードウエア複雑性、デバイスサイズ、電力消費量及びハードウエアコスト（一般的に、「部品表(BoM)」と呼ばれる）に直接的影響を有する。
【発明の概要】
【発明が解決しようとする課題】
【００２０】
従って、従来技術に比べて電力消費量が少なく、しかも高品位な工業規格画像品質を提供できるユーザデバイスにおいて、３Ｄレンダリングを容易にする新規なシステムとフォーマットの開発が強く求められている。更に、従来のユーザデバイスに対するハードウエア変更が最少の実装を容易にするシステム、好ましくは現存の２Ｄハードウエアアーキテクチャへの実装を容易にするシステムの開発が強く望まれている。
【課題を解決するための手段】
【００２１】
上記の課題を解決するために本発明は、
(a)第１のデータセットを受信するステップと、
(b)第２のデータセットを受信するステップと、
(c)第１のデータセットと第２のデータセットを結合することによりデータの融合セットと関連生成ベクトル(generating-vectors)とを生成するステップと、
前記融合データセットは第１のデータセット及び第２のデータセットの要素に関連する情報を包含し、前記生成ベクトルは、第１のデータセット及び第２のデータセットを回復するために融合データセットの要素に対して実行されるべき操作を示す、
(d)融合データセットと生成ベクトルとを相互に関連して格納するステップと、
からなるデータ格納方法を提供する。
【００２２】
上記の課題を解決するために本発明は、
(a)第１の視角からのシーン（情景）の第１の２次元（２Ｄ）画像を受信するステップと、
(b)第２の視角からのシーンの第２の２Ｄ画像を受信するステップと、
(c)第１の２Ｄ画像と第２の２Ｄ画像を結合することにより融合ビュー２Ｄ画像と関連生成ベクトルとを生成するステップと、
前記融合ビュー２Ｄ画像は第１の２Ｄ画像及び第２の２Ｄ画像の要素に関連する情報を包含し、前記生成ベクトルは、第１の２Ｄ画像及び第２の２Ｄ画像を回復するために融合ビュー２Ｄ画像の要素に対して実行されるべき操作を示す、
(d)融合ビュー２Ｄ画像及び生成ベクトルとを相互に関連して格納するステップと、
からなるデータの符号化方法を更に提供する。
【００２３】
上記の課題を解決するために本発明は、
(a)第１の２Ｄ画像及び第２の２Ｄ画像の要素に関連する情報を包含する融合ビュー２Ｄ画像を提供するステップと、
(b)融合ビュー２Ｄ画像に関連する生成ベクトルを提供するステップと、
前記生成ベクトルは、第１の２Ｄ画像及び第２の２Ｄ画像をレンダリングするために融合ビュー２Ｄ画像の要素に対して実行されるべき操作を示す、
(c)融合ビュー２Ｄ画像及び生成ベクトルを用いて、少なくとも第１の２Ｄ画像をレンダリングするステップと、
からなるデータの復号化方法を更に提供する。
【００２４】
選択的実施態様において、前記方法は第２の２Ｄ画像をレンダリングするステップを更に包含する。
【００２５】
上記の課題を解決するために本発明は、
(a)１個以上のプロセッサを含有する処理システムと、
前記処理システムは、第１のデータセットを受信し、第２のデータセットを受信し、前記第１のデータセット及び第２のデータセットを結合することにより融合データセット及び関連生成ベクトルを生成するように構成されており、
前記融合データセットは、第１のデータセット及び第２のデータセットの要素に関連する情報を包含し、前記生成ベクトルは、第１のデータセット及び第２のデータセットを回復するために融合データセットの要素に対して実行されるべき操作を示す、
(b)格納モジュールと、
前記格納モジュールは、融合データセットと生成ベクトルとを相互に関連して格納するように構成されている、
からなるデータの格納システムを更に提供する。
【００２６】
選択的実施態様において、前記システムは、データをＨ．２６４フォーマットで格納する。
【００２７】
上記の課題を解決するために本発明は、
(a)１個以上のプロセッサを含有する処理システムと、
前記処理システムは、第１の視角からのシーン（情景）の第１の２次元（２Ｄ）画像を受信し、第２の視角からのシーンの第２の２Ｄ画像を受信し、第１の２Ｄ画像と第２の２Ｄ画像を結合することにより融合ビュー２Ｄ画像と関連生成ベクトルとを生成するように構成されており、
前記融合ビュー２Ｄ画像は第１の２Ｄ画像及び第２の２Ｄ画像の要素に関連する情報を包含し、前記生成ベクトルは、第１の２Ｄ画像及び第２の２Ｄ画像を回復するために融合ビュー２Ｄ画像の要素に対して実行されるべき操作を示す、
(b)格納モジュールと、
前記格納モジュールは融合ビュー２Ｄ画像及び生成ベクトルとを相互に関連して格納するように構成されている、
からなるデータの符号化システムを更に提供する。
【００２８】
上記の課題を解決するために本発明は、
(a)１個以上のプロセッサを含有する処理システム、
前記処理システムは、第１の２Ｄ画像及び第２の２Ｄ画像の要素に関連する情報を包含する融合ビュー２Ｄ画像を提供し、融合ビュー２Ｄ画像に関連する生成ベクトルを提供し、そして、融合ビュー２Ｄ画像及び生成ベクトルを用いて、少なくとも第１の２Ｄ画像をレンダリングするように構成されており、
前記生成ベクトルは、第１の２Ｄ画像及び第２の２Ｄ画像をレンダリングするために融合ビュー２Ｄ画像の要素に対して実行されるべき操作を示す、
からなるデータの復号化システムを更に提供する。
【００２９】
上記の課題を解決するために本発明は、
(a)１個以上のプロセッサを含有する処理システムと、
前記処理システムは、第１の２Ｄ画像及び第２の２Ｄ画像の要素に関連する情報を包含する融合ビュー２Ｄ画像を提供し、そして融合ビュー２Ｄ画像に関連する生成ベクトルを提供するように構成されており、
前記生成ベクトルは、第１の２Ｄ画像及び第２の２Ｄ画像をレンダリングするために融合ビュー２Ｄ画像の要素に対して実行されるべき操作を示す、
(b)前記処理システムに対して操作的に結合されたディスプレイモジュールと、
前記ディスプレイモジュールは、融合ビュー２Ｄ画像及び生成ベクトルを用いて、少なくとも第１の２Ｄ画像をレンダリングし、そして第１の２Ｄ画像を表示するように構成されている、
からなるデータの処理システムを更に提供する。
【００３０】
選択的実施態様において、前記ディスプレイモジュールは、融合ビュー２Ｄ画像及び生成ベクトルを用いて、第２の２Ｄ画像をレンダーし、そして第２の２Ｄ画像を表示するように構成されている。更に別の選択的実施態様において、前記ディスプレイモジュールは、レンダリングを実行するように構成された集積回路を包含する。
【図面の簡単な説明】
【００３１】
【図１】従来技術３Ｄコンテンツ及びテクノロジーチェーンのブロック図である。
【図２Ａ】従来技術の３次元の物体のセンタービューの２Ｄ画像である。
【図２Ｂ】従来技術の単純化された深度画像である。
【図３】代表的な２Ｄアーキテクチャのブロック図である。
【図４】ユーザデバイスにおけるビデオの処理流れに関する代表的な２Ｄ＋深度アーキテクチャのブロック図である。
【図５】３Ｄ＋Ｆコンテンツ及びテクノロジーチェーンのブロック図である。
【図６】融合２Ｄビューのブロック図である。
【図７】３Ｄ＋Ｆを使用するレンダリングのブロック図である。
【図８】ユーザデバイスにおけるビデオの処理流れに関する３Ｄ＋Ｆアーキテクチャのブロック図である。
【図９】３Ｄ＋Ｆを使用するレンダリングのアルゴリズムの流れ図である。
【図１０】表を符号化する生成ベクトルの一例の概要図である。
【発明を実施するための形態】
【００３２】
以下、本発明の実施の形態について、以下詳述する。
【００３３】
本発明のシステムの原理及び操作は添付図面と下記の説明を熟読することにより十分に理解可能である。本発明はデータの符号化及び３次元レンダリングのためのシステム及びフォーマットである。本発明のシステムは高品位な工業規格画像品質を提供しつつ、従来技術に比べて低い電力使用量で３Ｄレンダリングを促進する。本発明のシステムの特徴は、２個の２Ｄ画像源（特に、３Ｄコンテンツのレフトビュー及びライトビュー）の単一２Ｄ画像への符号化と、第１及び第２の２Ｄ画像の回復のために単一２Ｄ画像の要素に対して実行されるべき操作を示す生成ベクトルである。この単一２Ｄ画像は「融合ビュー」又は「片目ビュー」として知られている。また、生成ベクトルは符号化に対応する情報であり、「フュージョン情報」として知られている。この符号化生成ベクトルは、３Ｄ＋Ｆフュージョンと呼ばれ、また、符号化アルゴリズム、復号化アルゴリズム、フォーマット及びアーキテクチャは一般的に、３Ｄ＋Ｆと呼ばれる。「Ｆ」は「フュージョン情報」を示す。生成ベクトルは一般的操作（例えば、フィルタリング及び制御）をサポートするが、特に、生成ベクトルは、レフトビュー又はライトビュー内の全要素をレンダリングするために、複写と補間操作だけを用いて、融合ビューから融合ビュー２Ｄ画像の復号化を促進する。
【００３４】
本発明の別の特徴は、従来技術がアプリケーションプロセッサ内で実行していたのに対して、ディスプレイモジュール内における実行を促進することである。この特徴により、２Ｄユーザに３Ｄ＋Ｆを実行する新規な３Ｄディスプレイを供給することによる変更無しに、現存の２Ｄハードウエアを維持出来る程度にまで、アプリケーションプロセッサに対するハードウエア変更を最小化することができる。
【００３５】
本発明では、画像は一般的に、情報含有データストラクチャである。画像に対する参照も特に断らない限り、一般的データストラクチャに対する参照として解釈できる。本明細書における説明を明確にするために、本発明はセルラネットワーク及び携帯電話に関して記述する。しかし、これらの記載は単なる一例であり、本発明は様々な類似アーキテクチャについても実行可能であり、また、３Ｄ画像技術に関する同様な要件を伴うその他のアプリケーションでも実行可能である。
【００３６】
本発明のシステムは高品位な工業規格画像品質を提供しつつ、従来技術に比べて低い電力使用量で３Ｄレンダリングを促進する。電力消費量分析結果は、４．３インチディスプレイスマートフォンで７２０ｐ解像度を有するＨＤＴＶビデオ３Ｄプレイバックの代表的アプリケーションについて、従来技術の２Ｄプレイバックの電力消費量と比較した場合、３Ｄ＋Ｆの電力消費量ペナルティは１％であることを示した。これに対して、従来技術の２Ｄ＋深度フォーマット及びレンダリングスキームの電力消費量ペナルティは５０％（最良ケース）であった。
【００３７】
図５を参照する。図５は図１に関して説明したモデルと同様な、３Ｄ＋Ｆコンテンツ及びテクノロジーチェーンのブロック図である。アプリケーションサーバ５１２において、（コンテンツ１００の）３Ｄ符号化５０２は３Ｄ＋Ｆフォーマット（この場合は、符号化情報に関する３Ｄ＋Ｆビデオフォーマット）に符号化される。一般的に、アプリケーションサーバは、リソースの強力又は複雑な処理を実行するための大電力、処理及び帯域幅リソースにアクセスする。３Ｄ＋Ｆの特徴は、プロセスの強力なタスクをサーバーサイド（例えば、アプリケーションサーバー）に委任し、そして、クライアントサイド（例えば、ユーザデバイス）での処理を単純化する。３Ｄ＋Ｆ符号化情報は従来技術の２Ｄ符号化情報と類似しており、（例えば、セルラオペレータ１１４による従来技術の４Ｇ規格１０４を用いて）受信装置１２０に送信できる。３Ｄ＋Ｆは高品位な工業規格画像品質を容易にし、これらは通常の２Ｄ画像技術に近い帯域幅で送信できる。
【００３８】
通常の２Ｄ画像がフォンマニュファクチャラーズ１１６により復号化（復元）される方法と同様な方法により、３Ｄ＋Ｆ符号化情報の融合ビュー２Ｄ画像部分はアプリケーションプロセッサ５０６において復号化される。２Ｄ＋深度フォーマットと異なり、アプリケーションプロセッサ５０６において３Ｄ＋Ｆについてはレンダリングは行われない。復号化融合ビュー２Ｄ情報と関連生成ベクトルは、ディスプレイモジュール５０８に送信される。ディスプレイモジュール５０８において、レフトビュー及びライトビューをレンダリングし、これらのビューを表示するために３Ｄ＋Ｆ情報が使用される。前記のように、ディスプレイは一般的に、ディスプレイマニュファクチャラーズ５１８により提供され、かつ、ユーザデバイス内に組み込まれている。
【００３９】
３Ｄ＋Ｆの特徴は、従来の２Ｄユーザに（３Ｄ＋Ｆレンダリングを実行する）３Ｄディスプレイモジュールを提供することにより、２Ｄユーザデバイスの残りのハードウエア構成要素を変更することなく、３Ｄユーザデバイスの設計を容易にすることである。これは、時間節約、コスト、設計に関する複雑性、試験、集積化、適合性、相互運用性及び市場に出るまでの時間などの点でユーザデバイス製造業者に巨大な利益を与える可能性を有する。ディスプレイモジュールにおける３Ｄ＋Ｆレンダリングの或る衝撃は、アプリケーションプロセッサにおける従来の２Ｄ＋深度レンダリングと対照的に、電力消費量が低減されることである。
【００４０】
３Ｄ＋Ｆフォーマットは、融合ビュー部分と生成ベクトル部分の２個の構成要素を包含する。図６を参照する。図６は、融合２Ｄビューのブロック図である。融合ビュー６２０は、人間の脳が２つの画像から一つの画像を引き出すのと同様に、単一の片目ビューとして知られている融合ビューを引き出すために情景のレフトビュー６００とライトビュー６１０を相関させることにより得られる。本明細書において、このプロセスはフュージョンとして知られている。レフトビュー及びライトビューの何れもそれぞれのビューに関する情報だけを包含しているが、融合ビューはレフトビュー及びライトビューを効率的にレンダリングするために必要な全ての情報を含有している。本明細書において、「情景（シーン）」という用語は、一般的に、眺められているものを意味する。情景は１個以上の物体又は眺められている場所を含むことができる。情景は視角と呼ばれる位置から眺められる。立体視の場合、それぞれ異なる視角からの２つのビューが使用される。人間の正確な立体視は各目により捕捉された一つのビューを使用する。技術的に、異なる位置の２個の画像捕捉デバイス（例えば、ビデオカメラ）は立体視のために２つの異なる視角から画像を提供する。
【００４１】
一例として、（この場合は単一物体の）情景のレフトビュー６００は、左視角からの物体の正面６０６と物体の左側面６０２を包含する。ライトビュー６１０は、右視角からの物体の正面６１６と物体の右側面６１４を包含する。融合ビュー６２０は、物体の左側面６２２の情報と、物体の右側面６２４の情報と、物体の正面６２６の情報を包含する。融合ビューの物体左側面６２２の情報はレフトビュー情報６０２だけを包含し、融合ビューの物体右側面６２４の情報はライトビュー情報６１４だけを包含しているが、物体の正面６２６の情報は、左正面６０６と右正面６１６の両方からの情報を包含する。
【００４２】
特に、融合ビューは下記の特徴を有する。
(1)融合ビュー内に閉塞要素が存在しない。本明細書において、「要素」と言う用語は画像の有意な最少輪郭を意味する。通常、要素はピクセル（画素）であるが、アプリケーション又は画像コンテンツに応じて、多角形又は領域であることもできる。本明細書では説明の明確化と容易化のために「ピクセル」という用語をしばしば使用する。レフト又はライトビュー内の全てのピクセルは、融合ビューからレフト又はライトビュー内の正確な位置までの対応するピクセルをコピー（場合により２回以上のコピー）することによりレンダリングされる。
(2)融合ビューを生成するために必要な処理アルゴリズムは人間の脳が画像を処理するやり方と同様に働く。従って、ピクセルの光と影などのような問題は排除される。
【００４３】
生成される融合ビューのタイプはアプリケーションに応じて変化する。或るタイプの融合ビューは元々のレフトビュー及びライトビューよりも多くのピクセルを包含する。これは図６について説明された事例である。この場合、レフト又はライトビュー内の全ての閉塞ピクセルは融合ビュー内に統合される。この場合、融合ビューがユーザにより眺められるべきものであったら、そのビューはコンテンツの歪められた２Ｄビューである。別のタイプの融合ビューは元々のレフトビュー又はライトビューと概ね同じ情報量を有する。この融合ビューは、レフトビュー又はライトビュー内の閉塞ピクセルの一部を両ビュー内の可視ピクセルと混合（補間又はフィルタリング）することにより生成させることができる。この場合、融合ビューがユーザにより眺められるべきものであったら、このビューはコンテンツの正常な２Ｄビューを示すであろう。本発明の３Ｄ＋Ｆは、前記の両方のタイプの融合ビューの何れにも使用でき、また、アプリケーションに応じて別のタイプの融合ビューにも使用できる。符号化アルゴリズムは好ましくはレンダリングされるビューの品質を最適化するように設計されるべきである。２つのビュー内の可視ピクセルと混合すべき閉塞ピクセルの部分の選択及び混合操作の選択は合成により分析プロセス内で実行できる。例えば、連続的にモニターされる被レンダリング画像品質の関数としてピクセル及び操作が最適に選択されるプロセスを使用することにより実行できる。
【００４４】
一般的に、良好な品質の融合ビューの生成は、実行のために大量の電力を必要とする一層複雑なフュージョンアルゴリズムが必要である。ユーザデバイス（例えば、図５の受信装置１２０）で必要とされる電力を最小にする要請のために、フュージョンはアプリケーションサーバー（例えば、図５の部材５１２）で実行できる。フュージョンを実行するアルゴリズムは当業者に公知である。従って、一般的に、ステレオマッチングのアルゴリズムを用いて行われる。この記載に基づき、当業者は特定のアプリケーション用の適当なフュージョンアルゴリズムを選択し、そして、３Ｄ＋Ｆのための関連生成ベクトルを生成するために必要に応じてフュージョンアルゴリズムを改変することができる。
【００４５】
３Ｄ＋Ｆフォーマットの第２の構成要素は生成ベクトル部分である。生成ベクトル部分は大量の生成ベクトルを包含するが、一層単純化するために単に「生成ベクトル」と呼ぶ。レフトビュー及びライトビューのそれぞれを生成するために、レフト生成ベクトルとライト生成ベクトルの２つのタイプの生成ベクトルが存在する。
【００４６】
生成ベクトルの第１の要素はランレングス(run-length)数である。これは生成数(generating number, GN)と呼ばれている。生成数は、レフト又はライトビューを生成する場合に、融合ビュー内のピクセルに対する操作（下記で定義する）を何回繰り返すべきかを示すために使用される。操作は下記で説明するように生成操作コードにより特定される。
【００４７】
生成ベクトルの第２の要素は生成操作コード(generating operation code, GOC) である。これは単に「生成操作」又は「操作」と呼ばれることもある。生成操作コードは、如何なるタイプの操作（例えば、関数又はアルゴリズム）を関連ピクセルに対して実行すべきかを示す。操作はアプリケーションに応じて変化させることができる。好ましい処理（インプリメンテーション）において、少なくとも下記の操作が利用できる。
(1)コピー。融合ビューから、生成されている（レフト又はライト）ビューへのコピー。ＧＮがｎに等しい場合、ピクセルはｎ回コピーされる。
(2)閉塞。ピクセルの閉塞。例えば、生成されているビュー内にピクセルを生成させない。ＧＮがｎに等しい場合、ｎ個のピクセルが生成されない。これは、融合ビューからｎ個のピクセルが、生成されているビュー内に閉塞されていることを意味する。
(3)次ぎのラインへ行く。現行ラインは完了され、次ぎのラインの生成を開始する。
(4)次のフレームに行く。現行フレームは完了され、次ぎのフレームの生成を開始する。
【００４８】
追加及び選択的操作の一例として、コピー及びフィルターが含まれる。ピクセルがコピーされ、次いで、周囲ピクセルにより平滑化される。この操作は、撮像品質を改善するために使用できるが、フィルタリング無しに得られた品質も一般的に受容可能である。
【００４９】
一般的に、生成ベクトルは均一にランダムに分布されていない。この分布は、例えば、ハフマン(Huffmann)符号化又は同様な別のタイプのエントロピー符号化方法を使用して生成ベクトルを効率的に符号化させることを可能にする。更に、一般的に、レフト及びライトビューの類似性により、レフト及びライトビュー生成ベクトルはかなりの程度の相関性を有する。従って、レフト生成ベクトル及びライト生成ベクトルは連帯的に一つのコードに符号化させることができる。生成ベクトルを効率的に符号化できる能力は、従来の２Ｄ画像技術における帯域幅要件と概ね等しい３Ｄ＋Ｆ帯域幅要件を容易にする。
【００５０】
図７を参照する。図７は３Ｄ＋Ｆを用いるレンダリングのブロック図である。融合２Ｄビュー（単一片目ビューとも呼ばれる）７２０を関連生成ベクトルと共に併用し、シーン（情景）のレフトビュー７００とライトビュー７１０をレンダリングする。融合ビュー７２０は、物体の左側面７２２の情報と、物体の右側面７２４の情報と、物体の正面７２６の情報と、物体の上面７２８の情報を包含する。生成ベクトルは、シーン（情景）のレフトビュー７００及びライトビュー７１０の部分をレンダリングするために、融合ビュー７２０のどの要素に対してどのような操作を実行すべきかを含有する。前記のように、３Ｄ＋Ｆの特徴は、レンダリングが融合ビューからの要素（閉塞を含む）のコピーだけを用いて実行することができ、これによりレフト及びライトビューをレンダリングすることができる。一例として、物体の左側面７０２のレフトビューをレンダリングするために、物体の左側面７２２の融合ビューの要素がコピーされる。物体の左側面７１２のライトビューをレンダリングするために、物体の左側面７２２の融合ビューの要素のサブセット（部分集合）がコピーされる。同様に、物体の右側面７０４のレフトビューをレンダリングするために、物体の右側面７２４の融合ビューの要素のサブセットがコピーされる。また、物体の右側面７１４のライトビューをレンダリングするために、物体の右側面７２４の融合ビューの要素がコピーされる。
【００５１】
物体の上面７０８のレフトビューをレンダリングするために、物体の上面７２８の融合ビューの要素の第１のサブセットをコピーし、物体の上面７１８のライトビューをレンダリングするために、物体の上面７２８の融合ビューの要素の第２のサブセットをコピーした。同様に、物体の正面７０６のレフトビューをレンダリングするために、物体の正面７２６の融合ビューの要素の第１のサブセットをコピーし、物体の正面７１６のライトビューをレンダリングするために、物体の正面７２６の融合ビューの要素の第２のサブセットをコピーした。
【００５２】
３Ｄ＋Ｆの好ましいインプリメンテーションは融合ビューから元々のレフト及びライトビューをレンダリングすることであるが、３Ｄ＋Ｆは元々のレフト及びライトビューをレンダリングすることに限定されない。例えば、３Ｄ＋Ｆは元々の視角以外の角度からのビューをレンダリングするため及びシーンの多数のビューをレンダリングするためにも使用される。或るインプリメンテーションでは、（例えば、図５の符合５１２で示されるようなアプリケーションサーバーにおける）融合操作は２セット以上の生成ベクトルを生成し、各生成ベクトルセットはシーンの１個以上の２Ｄ画像をを生成する。別のインプリメンテーションでは、１個以上の別の生成ベクトルセットを生成するために、（例えば、図５の符合１２０で示されるような受信装置において）生成ベクトルを処理することが出来、生成された各生成ベクトルはその後１個以上の別の２Ｄ画像をレンダリングするために使用される。
【００５３】
図９を参照する。図９は３Ｄ＋Ｆを用いてレンダリングするアルゴリズムの流れ図である。一例として、融合ビューと生成ベクトルを併用してレフト及びライトビューのレンダリングについて説明する。融合ビューからレフトビュー及びライトビューのピクセルを生成することは、融合ビュー画像から一度に一ラインを処理（一般的に、ライン−バイ−ライン処理として知られている）することにより実行できるプロセスである。融合ビュー内のＭ個のラインが存在するものと仮定する。ｍ＝［１，Ｍ］の変数を代入する。次ぎに、ラインｍについて、融合ビューのｍ番目のラインにＮ（ｍ）個のピクセルが存在する。Ｎ（ｍ）は各ラインについて同一である必要はない。ブロック９００において、変数ｍを１に設定する。そして、ブロック９０２において、変数ｎを１に設定する。ブロック９０４はダイアグラムにおける明瞭化のためのものである。ブロック９０６において、ｇｏｃＬ（ｎ）は融合ビューにおけるｎ番目のピクセル（Ｆｕｓｅｄ（ｎ））を入力する操作であり、レフトビューに対するポインタ（Ｌｅｆｔ＿ｐｔｒ）は最後の生成ピクセルをポインティングする。Ｌｅｆｔ＿ｐｔｒは操作により更新させることができる。同様に、ブロック９０８において、ｇｏｃＲ（ｎ）は融合ビューにおけるｎ番目のピクセル（Ｆｕｓｅｄ（ｎ））を入力する操作であり、ライトビューに対するポインタ（Ｒｉｇｈｔ＿ｐｔｒ）は最後の生成ピクセルをポインティングする。Ｒｉｇｈｔ＿ｐｔｒは操作により更新させることができる。前記に説明した基本的操作に加えて、その他の操作例としてＦＩＲフィルタ及びＩＩＲフィルタ等も包含する。ブロック９１０において、ラインに関するピクセルの全てが必ずしも操作されなかった場合、ブロック９１２において、処理は次ぎのピクセルに移動し、そして、処理はブロック９０４で継続される。さもなければ、ブロック９１４において、処理すべきラインが更に存在する場合、ブロック９１６において、処理は次のラインに移動する。ブロック９１４から、画像内の全てのラインが処理された場合、ブロック９１８において、適用可能であれば、処理は次ぎの画像について継続される。
【００５４】
融合ビューから（レフト又はライト）ビューをレンダリングする更に具体的な一例について、（図９の説明と首尾一貫して）融合ビューの要素についてライン毎に進められる処理として説明する。次ぎのように、ｇｏｃＲ（ｎ）及びｇｏｃＬ（ｎ）の操作は生成ベクトルから同定される。
【００５５】
「Ｌｅｔ  ＧＶ（ｉ）」は、例えば、所定のビューに関する所定のライン（例えば、ラインｍ，  ｍ＝１，．．．Ｍ）の復号化生成ベクトル（ＧＶ）である。（同様な説明は両方のビューについて適用される。）
【００５６】
生成ベクトルは例えば、操作（ｏｐ）及び生成数（ｇｎ）に置き換えて記載することができる。
ｏｐ＝ＧＶ（ｉ）．ｇｏｃ  （１）
ｇｎ＝ＧＶ（ｉ）．ＧＮ    （２）
ｆｏｒ（ｉ＝１，．．．ｋ）／／ｋはラインにおける生成ベクトルの個数を示す
ｏｐ＝ＧＶ（ｉ）．ｇｏｃ  （１）
ｇｎ＝ＧＶ（ｉ）．ＧＮ    （２）
ｆｏｒ（ｋ＝１，．．．ｇｎ）
ｇｏｃ＝ｏｐについて図９の内部ループを実行
ｅｎｄ／／ｆｏｒ（ｋ＝１，．．．ｇｎ）
ｅｎｄ／／ｆｏｒ（ｉ＝１，．．．ｋ）
【００５７】
前記説明は単一のピクセルに対する操作に関して明瞭化のために説明したが、３Ｄ＋Ｆは要素のブロックと同様に、多数の要素に対する操作もサポートする。前記アルゴリズムは好ましいインプリメンテーションであるが、当業者ならば本明細書の記載に基づき、特定のアプリケーションについて好適なアルゴリズムを実行することができるであろう。
【００５８】
レンダリングのために使用できる操作の一例として、下記の疑似コードにより詳述する。
・ＣｏｐｙＰ：ピクセルをピクセルへコピー
コール：Ｐｉｘｅｌ＿ｐｔｒ＝ＣｏｐｙＰ［融合Ｉｎｐｕｔ（ｎ），Ｐｉｘｅｌ＿ｐｔｒ］
入力：
融合Ｉｎｐｕｔ（ｎ）：（ｍ番目のラインにおける）融合ビューのｎ番目のピクセル
Ｐｉｘｅｌ＿ｐｔｒ：レフト又はライトビュー上のポインタ（最後に生成される）
処理：
融合Ｉｎｐｕｔ（ｎ）をＰｉｘｅｌ＿ｐｔｒ＋１へコピー
出力：
更新Ｐｉｘｅｌ＿ｐｔｒ＝Ｐｉｘｅｌ＿ｐｔｒ＋１
・ＣｏｐｙＰｔｏＢｌｏｃｋ：ピクセルをピクセルのブロックへコピー
コール：Ｐｉｘｅｌ＿ｐｔｒ＝ＣｏｐｙＰｔｏＢｌｏｃｋ［融合Ｉｎｐｕｔ（ｎ），Ｐｉｘｅｌ＿ｐｔｒ，ＢｌｏｃｋＬｅｎｇｔｈ］
入力：
融合Ｉｎｐｕｔ（ｎ）：（ｍ番目のラインにおける）融合ビューのｎ番目のピクセル
Ｐｉｘｅｌ＿ｐｔｒ：レフト又はライトビュー上のポインタ（最後に生成される）
ＢｌｏｃｋＬｅｎｇｔｈ：ブロック長
処理：
融合Ｉｎｐｕｔ（ｎ）をＰｉｘｅｌ＿ｐｔｒ＋１，Ｐｉｘｅｌ＿ｐｔｒ＋２，．．．Ｐｉｘｅｌ＿ｐｔｒ＋ＢｌｏｃｋＬｅｎｇｔｈへコピー
出力：
更新Ｐｉｘｅｌ＿ｐｔｒ＝Ｐｉｘｅｌ＿ｐｔｒ＋ＢｌｏｃｋＬｅｎｇｔｈ
・ＯｃｃｌｕｄｅＰ：ピクセルを閉塞
コール：ＯｃｃｌｕｄｅＰ［融合Ｉｎｐｕｔ（ｎ）］
入力：
融合Ｉｎｐｕｔ（ｎ）：（ｍ番目のラインにおける）融合ビューのｎ番目のピクセル
Ｐｉｘｅｌ＿ｐｔｒ：レフト又はライトビュー上のポインタ（最後に生成される）
ａ：重み
処理：
ａ＊融合Ｉｎｐｕｔ（ｎ）をＰｉｘｅｌ＿ｐｔｒ＋１へコピー
出力：
更新Ｐｉｘｅｌ＿ｐｔｒ＝Ｐｉｘｅｌ＿ｐｔｒ＋１
・補間及びコピー：融合ビューの２つのピクセルを補間し、コピー
コール：ＩｎｔｅｒｐｏｌａｔｅＡｎｄＣｏｐｙ［融合Ｉｎｐｕｔ（ｎ），Ｐｉｘｅｌ＿ｐｔｒ，ａ］
入力：
融合Ｉｎｐｕｔ（ｎ）：（ｍ番目のラインにおける）融合ビューのｎ番目のピクセル
Ｐｉｘｅｌ＿ｐｔｒ：レフト又はライトビュー上のポインタ（最後に生成される）
ａ：重み
処理：
ａ＊融合Ｉｎｐｕｔ（ｎ）＋（１−ａ）＊融合Ｉｎｐｕｔ（ｎ＋１）をＰｉｘｅｌ＿ｐｔｒ＋１へコピー
出力：
更新Ｐｉｘｅｌ＿ｐｔｒ＝Ｐｉｘｅｌ＿ｐｔｒ＋１
【００５９】
図１０を参照する。図１０は生成ベクトル符号化テーブルの一例を示す表図である。好ましいインプリメンテーションは、生成ベクトルの高冗長性のため、生成ベクトルをエントロピー符号化により符号化することである。冗長性は、画像内の一般的な隣接ピクセルがしばしば同一又は類似の距離を有し、その結果、融合ビューとレンダリングされたビューとの間の不均衡は隣接ピクセルについて同一又は類似であるという事実から生じる。エントロピー符号化は例えば、ハフマン(Huffman)符号化である。図１０において、前記に記載の操作リストを用いて、ハフマン符号化は一層少ないビット数で最も頻度の高い操作を符号化する。
【００６０】
前記のように、生成ベクトルの様々なインプリメンテーションが可能であり、従って、現在説明している実施例はコードの論理に基づく単なる一例である。生成ベクトルの一層最適なコードを開発できることは予見される。コードを生成する或るオプションは、好ましくは画像コンテンツについて最適化されたコンテンツに基づく異なる生成ベクトル符号化テーブルを使用することを包含する。別の選択的なインプリメンテーションでは、テーブルを処理中（例えば、ビデオプレイバックの開始時点）に構成させることができる。
【００６１】
図８を参照する。図８はユーザデバイスにおけるビデオの処理流れに関する３Ｄ＋Ｆアーキテクチャのブロック図であり、一例として携帯電話を再度使用する。一般的に、３Ｄ＋Ｆの処理流れは、図３において説明した２Ｄに関する処理流れに類似している。前記のように、従来のアプリケーションプロセッサ３０４ハードウエア及びメモリ（ビデオデコーダメモリ３０８及びディスプレイメモリ３２０の両方）を３Ｄ＋Ｆの実行に使用できる。アーキテクチャの顕著な相違点は、ディスプレイシステム３２２内で追加の３Ｄ＋Ｆレンダリングモジュール８４０と３Ｄディスプレイ８１８を使用することである。
【００６２】
符号化情報（本例では圧縮ビデオパケット及び関連３Ｄ＋Ｆ生成ベクトル）は、アプリケーションプロセッサ３０４内のビデオデコーダ８０２を介してメモリカード３００から読み出され、そして、外部バスインターフェース３０６を介してビデオデコーダメモリ３０８に送信される。従来の２Ｄ画像技術を同様に、３Ｄ＋Ｆも復号化すべき２Ｄ画像のストリームを１個だけ含有する。従って、ビデオデコーダメモリ３０８は２Ｄと３Ｄ＋Ｆが概ね同じサイズであることを必要とする。符号化情報（本例ではビデオパケット）はビデオデコーダ８０２により復号化され、復号化フレームを生成する。この復号化フレームはディスプレイインターフェース３１０に送信される。ビデオパケットがＨ．２４６フォーマットである場合、処理は前記のようにして行われる。
【００６３】
復号化フレーム及び関連３Ｄ＋Ｆ情報（生成ベクトル）はアプリケーションプロセッサ３０４内のディスプレイインターフェース３１０から、ディスプレイシステム３２２内のディスプレイシステムインターフェース３１２を介して、ディスプレイコントローラ３１４（本例では、ＬＣＤコントローラ）に送信され、ディスプレイコントローラ３１４はディスプレイメモリ３２０内に復号化フレームを格納する。ディスプレイシステム３２２は、図５の符合５０８の部材に関連して説明したように、レフト及びライトビューをレンダリングし、レンダリングする。従来の２Ｄ画像技術と同様に、３Ｄ＋Ｆは２Ｄ画像（フレーム）の復号化ストリームを１個だけ含有する。従って、ディスプレイメモリ３２０は、２Ｄと３Ｄ＋Ｆが概ね同じサイズであることを必要とする。ディスプレイメモリ３２０から、ＬＣＤコントローラ３１４は復号化フレームと関連生成ベクトルを３Ｄ＋Ｆレンダリングモジュール８４０へ送信する。生成ベクトルが圧縮されている場合、復元はディスプレイシステム３２２内、好ましくは３Ｄ＋Ｆレンダリングモジュール８４０内で実行できる。３Ｄ＋Ｆレンダリングモジュール８４０における生成ベクトルの復元は、従来の２Ｄアーキテクチャに対する３Ｄ＋Ｆのインプリメンテーションを更に容易にする。前記のように、レフトビュー及びライトビューをレンダリングするために、２Ｄ画像は生成ベクトルと共に使用され、これらはディスプレイドライバ３１６を介して３Ｄディスプレイ８１８に送信される。復号化フレームをユーザに提供し、そして、ユーザが所望のコンテンツを立体視で眺めることを可能にするため、３Ｄディスプレイ８１８は特定のデバイス及びアプリケーションに適切なように構成されている。
【００６４】
これらの実施態様における各種のモジュール、処理及び構成部品類は、当業者に公知なように、ハードウエア、ファームウェア、ソフトウェア又はこれらの組合せとして実装することができる。３Ｄ＋Ｆレンダリングの好ましいインプリメンテーションでは、集積回路（ＩＣ）チップを包含する。別の好ましいインプリメンテーションでは、３Ｄ＋Ｆレンダリングモジュール８４０は、他のディスプレイシステム３２２機能を提供するチップ上のＩＣ構成部品として実装される。更に別の好ましい実施態様では、基底のＶＬＳＩＣ（大規模集積回路）インプリメンテーションは簡単な一次元（１Ｄ）コピーマシンである。特別なロジックを必要とする２Ｄ＋深度と異なり、１Ｄコピーマシンは当業者に公知である。
【００６５】
以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。特許請求の範囲の構成要素の後に記載した括弧内の番号は、図面の部品番号に対応し、発明の容易なる理解の為に付したものであり、発明を限定的に解釈するために用いてはならない。また、同一番号でも明細書と特許請求の範囲の部品名は必ずしも同一ではない。これは上記した理由による。用語「又は」に関して、例えば「Ａ又はＢ」は、「Ａのみ」、「Ｂのみ」ならず、「ＡとＢの両方」を選択することも含む。特に記載のない限り、装置又は手段の数は、単数か複数かを問わない。
【符号の説明】
【００６６】
１００  コンテンツ作成（３Ｄムービー）
１０２  ３Ｄ符号化（エンコーディング）（２Ｄ＋深度ビデオフォーマット）
１０４  ビデオ伝送（４Ｇ規格）
１０６  レフトビュー及びライトビューの復号化及びレンダリング（アプリケーションプロセッサ内）
１０８  ディスプレイ（スマートホンディスプレイモジュール）
１１０  コンテンツプロバイダー
１１２  アプリケーションサーバー
１１４  セルラーオペレータ
１１６  フォーンマニュファクチャー
１１８  ディスプレイマニュファクチャー
１２０  受信装置
図３
３００  メモリカード
３０２  ビデオデコーダ
３０４  アプリケーションプロセッサ
３０６  外部バスインターフェース
３０８  ビデオデコーダメモリ（２Ｄサイズ）
３１０  ディスプレイインターフェース
３１２  ディスプレイシステムインターフェース
３１４  ＬＣＤコントローラ
３１６  ディスプレイドライバ
３１８  ディスプレイ
３２０  ディスプレイメモリ（２Ｄサイズ）
３２２  ディスプレイシステム
３３０  サービスプロバイダー通信モジュール
３３２  ユーザ通信モジュール
３３４  任意モジュール
図４
４０２  ビデオデコーダ（３Ｄレンダリング）
４０８  ビデオデコーダ及び３Ｄレンダリングメモリ（１．５ｘ２Ｄサイズ）
４１８  ディスプレイ
４２０  ディスプレイメモリ（２Ｄサイズの２倍以下）
５０２  ３Ｄ符号化（３Ｄ＋Ｆビデオフォーマット）
５０６  ２Ｄ部分の復号化（アプリケーションプロセッサ内）
５０８  レフトビュー及びライトビューのレンダリング及びレンダリング（スマートフォンディス
プレイモジュール）
５１２  アプリケーションサーバー
５１８  ディスプレイマニュファクチャラーズ
６００  情景のレフトビュー
６０２  物体の左側面
６０６  物体の正面
６１０  情景のライトビュー
６１４  物体の右側面
６１６  物体の正面
６２０  融合ビュー
６２２  物体の左側面
６２４  物体の右側面
６２６  物体の正面
７００  シーン（情景）のレフトビュー
７０２  物体の左側面
７０４  物体の右側面
７０６  物体の正面
７０８  物体の上面
７１０  シーン（情景）のライトビュー
７１２  物体の左側面
７１４  物体の右側面
７１６  物体の正面
７１８  物体の上面
７２０  融合２Ｄビュー
７２２  物体の左側面
７２４  物体の右側面
７２６  物体の正面
７２８  物体の上面
８０２  ビデオデコーダ
８１８  ディスプレイ
８４０  ３Ｄ＋Ｆレンダリング
９００  ｍ＝１（ｍはライン番号）
９０２  ｎ＝１（ｎは融合ビューびｎ番目のピクセル）
９０６  Left_ptr=gocL(n)[融合(n), Left_ptr]
９０８  Right_ptr=gocR(n)[融合(n), Right_ptr]
９１０  n=N(m)?
９１２  n=n+1
９１４  m=M?
９１６  m=m+1(次ぎのラインの生成開始)
９１８  次ぎのメッセージに行け
図１０
操        作                                  生成数(GN)    ハフマンコード
ゼロ・ディスプレイスメントによるCopyP
（すなわち、ピクセルをPixel_ptr+1へコピー）         １            １１１
ゼロ・ディスプレイスメントによるCopyP
（すなわち、ピクセルをPixel_ptr+1へコピー）         ２            ０１０
ゼロ・ディスプレイスメントによるCopyP
（すなわち、ピクセルをPixel_ptr+1へコピー）         ３            ０００
ゼロ・ディスプレイスメントによるCopyP
（すなわち、ピクセルをPixel_ptr+1へコピー）         ４            １１０１
１ポジティブ・ディスプレイスメントによるCopyP
（すなわち、ピクセルをPixel_ptr+2へコピー）         １            １０１０
１ネガティブ・ディスプレイスメントによるCopyP
（すなわち、ピクセルをPixel_ptrへコピー）           １             １０００
occludeP(NOP)                                      １             ０１１１
CopytoBlock，ブロック長=2                           １             ００１０
CopytoBlock，ブロック長=3                           １             １０１１
CopytoBlock，ブロック長=4                           １             ０１１０
occludeP(NOP)                                      ２             １１００１
occludeP(NOP)                                      ３             ００１１０
【図１】
2012522285.tif 000003
【図２Ａ】
2012522285.tif 000004
【図２Ｂ】
2012522285.tif 000005
【図３】
2012522285.tif 000006
【図４】
2012522285.tif 000007
【図５】
2012522285.tif 000008
【図６】
2012522285.tif 000009
【図７】
2012522285.tif 000010
【図８】
2012522285.tif 000011
【図９】
2012522285.tif 000012
【図１０】
2012522285.tif 000013
【国際調査報告】
2012522285.tif 000014