特許 7197716 相互運用可能な３Ｄ画像コンテンツのハンドリング

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-12-19

(45)【発行日】2022-12-27

(54)【発明の名称】相互運用可能な３Ｄ画像コンテンツのハンドリング

(51)【国際特許分類】

   H04N 13/356 20180101AFI20221220BHJP

   H04N 13/271 20180101ALI20221220BHJP

   H04N 13/268 20180101ALI20221220BHJP

   G09G 5/36 20060101ALI20221220BHJP

   G09G 5/377 20060101ALI20221220BHJP

   G09G 5/00 20060101ALI20221220BHJP

   G06T 19/00 20110101ALI20221220BHJP

【ＦＩ】

H04N13/356

H04N13/271

H04N13/268

G09G5/36 510V

G09G5/36 520N

G09G5/00 555G

G06T19/00 F

【請求項の数】 14

(21)【出願番号】P 2021542142

(86)(22)【出願日】2020-01-21

(65)【公表番号】

(43)【公表日】2022-04-21

(86)【国際出願番号】 EP2020051387

(87)【国際公開番号】W WO2020152150

(87)【国際公開日】2020-07-30

【審査請求日】2022-09-22

(31)【優先権主張番号】19153263.9

(32)【優先日】2019-01-23

(33)【優先権主張国・地域又は機関】EP

【早期審査対象出願】

(73)【特許権者】

【識別番号】514171315

【氏名又は名称】ウルトラ－デー・コーペラティーフ・ユー・アー

(74)【代理人】

【識別番号】110001173

【氏名又は名称】弁理士法人川口國際特許事務所

(72)【発明者】

【氏名】ベレンセ，ダニー

(72)【発明者】

【氏名】デ・フロート，マルク・ヨゼーヒュス・ヘラルデュス

(72)【発明者】

【氏名】カストロ・テウネ，パトリック

(72)【発明者】

【氏名】エレディア・ソリアノ，フランシスコ・ハビエル

【審査官】益戸 宏

(56)【参考文献】

【文献】特開２０１２－８５３０１（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ １３／００

Ｇ０９Ｇ ５／００

Ｇ０６Ｔ １９／００

(57)【特許請求の範囲】

【請求項1】

ディスプレイ上にアプリケーションのビューを表示するためのシステム（１００）であって、ビューが３Ｄディスプレイ（０８０）のための３Ｄ画像コンテンツを表し、システムが、
－ オペレーティングシステムを表すシステムデータおよびアプリケーション（２００）を表すアプリケーションデータを含むメモリ（１４０）と、
－ メモリと通信し、オペレーティングシステムおよびアプリケーションを実行するように構成されたプロセッササブシステム（１２０）と、
を備え、
オペレーティングシステムが、
－ アプリケーションによって生成されたビューの可視性を管理するためのウィンドウマネージャ（２２０）と、
－ ディスプレイのタイプに固有の１つ以上のディスプレイサーバコンポーネント（２５２－２５６）であって、ウィンドウマネージャから得られた可視性情報に基づいて、ビューを、ディスプレイのための表示信号（４４０－４４４）へと合成するように構成された、１つ以上のディスプレイサーバコンポーネントと、
を提供するように構成されており、
アプリケーションが、ウィンドウマネージャに、３Ｄ画像コンテンツを、ビュー構成に従って互いに対して配置構成された少なくとも２つのビューの形態で提供するように構成されており、少なくとも２つのビューが、２Ｄ画像データ（３００）を含む１次ビュー（４００）と、２Ｄ画像データの奥行きを表す３Ｄ可能化補助データ（３１０）を含む２次ビュー（４１０）とを含み、アプリケーション（２００）が、
ｉ）２次ビュー（４１０）の前に１次ビュー（４００）をスタックして、１次ビューが２次ビューをオクルージョンするビュー構成を提供することか、または
ｉｉ）１次ビューの２Ｄ画像データを含むビューポート（４３０）を示すことによってウィンドウマネージャ（２２０）に１次ビュー（４００）を提供し、ビューポートの外部に２次ビューの３Ｄ可能化補助データを配置構成することによってウィンドウマネージャに２次ビュー（４１０）を提供すること
により、ビュー構成を提供するように構成され、
ひいては、２Ｄディスプレイのための２Ｄディスプレイサーバコンポーネント（２５２）に、少なくとも２つのビューを表示信号（４４０）へと合成するとき、２次ビューの描画を省略させるかまたは２次ビューに上描きさせる、システム（１００）。

【請求項2】

アプリケーション（２００）が、１次ビュー（４００）を２次ビュー（４１０）の前にスタックするときに、１次ビュー（４００）および２次ビュー（４１０）に対して、１次ビューを２次ビューの前にスタックさせる相対的なＺ順序（４２０）を割り当てるように構成されている、請求項１に記載のシステム（１００）。

【請求項3】

アプリケーション（２００）が、１次ビュー（４００）を２次ビュー（４１０）の前にスタックするときに、１次ビュー（４００）と２次ビュー（４１０）の間にスタックされるバリアビューを提供するように構成され、バリアビューが、不透明であり、均質な画像データを含む、請求項１または２に記載のシステム（１００）。

【請求項4】

１つ以上のディスプレイサーバコンポーネントが３Ｄディスプレイのための３Ｄディスプレイサーバコンポーネント（２５４、２５６）を備え、アプリケーション（２００）が、少なくとも２つのビュー（４００、４１０）が３Ｄ画像コンテンツを表すことを３Ｄディスプレイサーバコンポーネントにシグナリングするように構成されている、請求項１から３のいずれか一項に記載のシステム（１００）。

【請求項5】

３Ｄディスプレイサーバコンポーネント（２５４、２５６）が、アプリケーションが３Ｄディスプレイサーバコンポーネントとインターフェースすることを可能にするＡＰＩ（２８４）を提供し、アプリケーション（２００）が、少なくとも２つのビュー（４００、４１０）が３Ｄ画像コンテンツを表すことを、たとえばＡＰＩを介して３Ｄディスプレイサーバコンポーネントに少なくとも２つのビューの識別子を登録することにより、ＡＰＩを介して３Ｄディスプレイサーバコンポーネントにシグナリングするように構成されている、請求項４に記載のシステム（１００）。

【請求項6】

１つ以上のディスプレイサーバコンポーネントが３Ｄディスプレイサーバコンポーネント（２５４、２５６）を備え、３Ｄディスプレイサーバコンポーネントが、アプリケーション（２００）のメタデータに基づいて、少なくとも２つのビュー（４００、４１０）が３Ｄ画像コンテンツを表すことを検出するように構成されている、請求項１から３のいずれか一項に記載のシステム（１００）。

【請求項7】

アプリケーション（２００）のメタデータがアプリケーションの識別子を含む、請求項６に記載のシステム（１００）。

【請求項8】

３Ｄディスプレイサーバコンポーネント（２５４、２５６）が、
－ １次ビューと２次ビューを、立体表示フォーマットに従って表示信号（４４４）において同時に示されるように配置構成すること、または
－ １次ビューおよび２次ビューに基づいて１つ以上のさらなるビューを生成し、１次ビューと、１つ以上のさらなるビューとを、マルチビュー表示フォーマットに従って、表示信号（４４２）において同時に配置構成すること
によって、少なくとも２つのビュー（４００、４１０）を合成するように構成されている、請求項４から７のいずれか一項に記載のシステム（１００）。

【請求項9】

３Ｄ可能化補助データ（３１０）が、２Ｄ画像データ（３００）とともに１対の立体画像を表すさらなる２Ｄ画像データ、または２Ｄ画像データの中に示されたオブジェクトの、カメラもしくは視聴者に対する距離を表す奥行き関連のデータ、のグループのうちの１つである、請求項１から８のいずれか一項に記載のシステム（１００）。

【請求項10】

請求項１から９のいずれか一項に記載のシステムを備えるディスプレイデバイス。

【請求項11】

オペレーティングシステムのウィンドウマネージャ（２２０）にアプリケーション（２００）のビューを提供する、コンピュータにより実行される方法であって、ビューが３Ｄディスプレイのための３Ｄ画像コンテンツを表し、オペレーティングシステムが、
アプリケーションによって生成されたビューの可視性を管理するように構成されたウィンドウマネージャ（２２０）と、
ディスプレイのタイプに固有の１つ以上のディスプレイサーバコンポーネント（２５２－２５６）であって、ウィンドウマネージャから得られた可視性情報に基づいて、ビューを、ディスプレイのための表示信号へと合成するように構成された、１つ以上のディスプレイサーバコンポーネントと、
を提供するように構成されており、
方法が、アプリケーションによって、ウィンドウマネージャに、３Ｄ画像コンテンツを、ビュー構成に従って互いに対して配置構成された少なくとも２つのビューの形態で提供することを含み、少なくとも２つのビューが、２Ｄ画像データを含む１次ビューと、２Ｄ画像データの奥行きを表す３Ｄ可能化補助データを含む２次ビューとを含み、前記アプリケーションによって３Ｄ画像コンテンツを提供することが、
ｉ）２次ビューの前に１次ビューをスタックして、１次ビューが２次ビューをオクルージョンするビュー構成を提供すること、または
ｉｉ）１次ビューの２Ｄ画像データを含むビューポートを示すことによって、ウィンドウマネージャに１次ビューを提供し、ビューポートの外部に２次ビューの３Ｄ可能化補助データを配置構成することによってウィンドウマネージャに２次ビューを提供すること
によって、ビュー構成を提供することを含み、
ひいては、２Ｄディスプレイのための２Ｄディスプレイサーバコンポーネントに、少なくとも２つのビューを表示信号へと合成するとき、２次ビューの描画を省略させるかまたは２次ビューに上描きさせる、コンピュータにより実行される方法。

【請求項12】

アプリケーションを表すコンピュータプログラム（５１０）を含む一時的または非一時的なコンピュータ可読媒体（５００）であって、コンピュータプログラムが、プロセッサシステムに、請求項１１に記載の方法を実施させるための命令を含む、一時的または非一時的なコンピュータ可読媒体。

【請求項13】

オペレーティングシステム上で実行されるアプリケーション（２００）のビューを合成する、コンピュータにより実行される方法であって、ビューが３Ｄディスプレイのための３Ｄ画像コンテンツを表し、オペレーティングシステムが、
アプリケーションによって生成されたビューの可視性を管理するためのウィンドウマネージャ（２２０）と、
３Ｄディスプレイのための３Ｄディスプレイサーバコンポーネント（２５４、２５６）であって、ウィンドウマネージャから得られた可視性情報に基づいて、ビューを、３Ｄディスプレイのための表示信号へと合成するように構成された３Ｄディスプレイサーバコンポーネントと、
を提供するように構成されており、
アプリケーション（２００）が、ウィンドウマネージャに、３Ｄ画像コンテンツを、ビュー構成に従って互いに対して配置構成された少なくとも２つのビューの形態で提供するように構成されており、少なくとも２つのビューが、２Ｄ画像データを含む１次ビューと、２Ｄ画像データの奥行きを表す３Ｄ可能化補助データを含む２次ビューとを含み、アプリケーション（２００）が、
ｉ）２次ビューの前に１次ビューをスタックして、１次ビューが２次ビューをオクルージョンするビュー構成を提供することか、または
ｉｉ）１次ビューの２Ｄ画像データを含むビューポートを示すことによって、ウィンドウマネージャ（２２０）に１次ビューを提供し、ビューポートの外部に２次ビューの３Ｄ可能化補助データを配置構成することによってウィンドウマネージャに２次ビューを提供すること
により、ビュー構成を提供するように構成され、
ひいては、２Ｄディスプレイのための２Ｄディスプレイサーバコンポーネントに、少なくとも２つのビューを表示信号へと合成するとき、２次ビューの描画を省略させるかまたは２次ビューに上描きさせ、
方法は、３Ｄディスプレイサーバコンポーネントによって、
－ アプリケーションから受け取られたシグナリングまたはアプリケーションのメタデータに基づいて、少なくとも２つのビューが３Ｄ画像コンテンツを表すと決定することと、
－ １次ビューおよび２次ビューを処理して、３Ｄディスプレイのための表示信号を得ることと
を含む、コンピュータにより実行される方法。

【請求項14】

３Ｄディスプレイサーバコンポーネントを表すコンピュータプログラム（５１０）を含む一時的または非一時的なコンピュータ可読媒体（５００）であって、コンピュータプログラムが、プロセッサシステムに、請求項１３に記載の方法を実施させるための命令を含む、一時的または非一時的なコンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明はディスプレイ上にアプリケーションのビューを表示するためのシステムに関し、ビューは３Ｄディスプレイのための３Ｄ画像コンテンツを表す。本発明は、アプリケーションによってウィンドウマネージャに３Ｄ画像コンテンツを提供するための、コンピュータにより実行される方法と、ディスプレイサーバコンポーネントによって、ビューが３Ｄ画像コンテンツを表すと決定するための、コンピュータにより実行される方法とに、さらに関する。

【背景技術】

【0002】

デバイス上のコンテンツを観察するときユーザに奥行き知覚を提供するための３Ｄディスプレイを備える、テレビ、デジタルフォトフレーム、タブレットおよびスマートフォンなどのディスプレイデバイスが増えている。そのために、そのような３Ｄディスプレイは、立体視に基づく奥行き知覚をユーザに提供するように、それ自体で、またはユーザによって着用された眼鏡とともに、ユーザのそれぞれの目に異なる画像を提供し得る。

【0003】

そのような３Ｄディスプレイ上に表示される３Ｄ画像コンテンツは、一般に、２Ｄ画像データと、いわゆる３Ｄ可能化補助データ（３Ｄ－ｅｎａｂｌｉｎｇ ａｕｘｉｌｉａｒｙ ｄａｔａ）とによって、表され得る。３Ｄ可能化補助データは２Ｄ画像データの奥行きを表し得る。たとえば、３Ｄ可能化補助データは、２Ｄ画像データとともに１対の立体画像を表すさらなる２Ｄ画像データ、またはカメラもしくは視聴者に対して２Ｄ画像データの中に示されたオブジェクトの距離を表す奥行き関連のデータでよい。そのような奥行き関連のデータは、奥行き値ばかりでなく、ディスパリティ値、視差値または他のタイプの奥行き関連の値をも含み得る。

【0004】

３Ｄ画像コンテンツは、オペレーティングシステム上で走るアプリケーションによって表示され得る。そのようなオペレーティングシステムは、アプリケーションによって生成されたビューの可視性を管理するためのウィンドウマネージャを提供し得る。加えて、オペレーティングシステムが提供し得る１つ以上のディスプレイサーバコンポーネントは、それぞれがディスプレイのタイプに固有のものでよく、また、ウィンドウマネージャから得られた可視性情報に基づいて、アプリケーションのビューをディスプレイのための表示信号へと合成するように構成され得る。これらのディスプレイサーバコンポーネントは、「ディスプレイサーバ」と呼ばれる単一のソフトウエアコンポーネントの各コンポーネントでよいが、それぞれが別個のディスプレイサーバをも表し得る。

【0005】

ウィンドウマネージャおよびディスプレイサーバは、別個のソフトウエアコンポーネントとして実現され得るが、単一のソフトウエアコンポーネントに結合されてよく、別のやり方で各ソフトウエアコンポーネントにわたって分割されてもよいことが留意される。具体例は、アンドロイドのオペレーティングシステムが「ＷｉｎｄｏｗＭａｎａｇｅｒ」という名のウィンドウマネージャおよび「ＳｕｒｆａｃｅＦｌｉｎｇｅｒ」という名のディスプレイサーバを提供するものである。様々な他のタイプのウィンドウマネージャおよび／またはディスプレイサーバも、たとえば他のオペレーティングシステムの一部として知られている。

【0006】

アプリケーションによって３Ｄ画像コンテンツを表示する知られているやり方には、アプリケーションが、ディスプレイサーバコンポーネントやディスプレイのタイプに対して柔軟性がないという不都合がある。すなわち、特定のアプリケーションは１つのタイプのディスプレイ（たとえば２Ｄまたは３Ｄのディスプレイ）しかサポートし得ず、または、原理的には異なるタイプのディスプレイをサポートし得るが、システムに接続されたディスプレイタイプを認識できず、手作業で構成されなければならないことがある。

【0007】

たとえばランタイム中の異なるタイプのディスプレイ間の動的スイッチングをサポートするような柔軟性、または異なるタイプのディスプレイを伴うマルチディスプレイ（「マルチモニタ」とも称される）セットアップをサポートするような柔軟性が望ましい。そのようなタイプの柔軟性は「相互運用性」と称されることもある。詳細には、２Ｄ（「レガシー」）ディスプレイと３Ｄディスプレイの間のそのような相互運用性を提供することが望ましい。多くの場合、レガシー２Ｄディスプレイは、特定のアプリケーションによって生成または出力される３Ｄ画像コンテンツを再生し得るが、その場合、そのような３Ｄ画像コンテンツは２Ｄ画像の形態で再現されることになり、望ましくないであろう。たとえば、３Ｄ画像コンテンツが、並んだ２つのビューとして提供される立体コンテンツであると、２Ｄディスプレイサーバコンポーネントは、両方のビューを、２Ｄディスプレイ上に並べてレンダリングしてしまうであろう。２Ｄディスプレイ上には、両方のビューの一方を無視して１つだけをレンダリングすることが望まれるので、これは望ましくない。

【0008】

米国特許出願公開第２０１２／０９２３３５ Ａ１号は、モバイルアンドロイドのプラットフォームに基づいて、携帯用３Ｄディスプレイ機器の中のハードウェアコンポーネントの最小数を使用する一方でソフトウエアによって立体視画像信号を処理するための方法および３Ｄディスプレイ機器を説明している。アプリケーション／ミドルウェア層から１つ以上の平面画像面が生成され、第１のフレームバッファに記憶される。符号化された画像信号は、立体視画像対を表すＹＵＶ画像信号を復元するために、アプリケーション／ミドルウェア層の下で復号される。続いて、ＹＵＶ画像信号がＲＧＢ画像信号に変換され、カーネル層においてＲＧＢ画像信号の左画像と右画像が混合される。

【先行技術文献】

【特許文献】

【0009】

【文献】米国特許出願公開第２０１２／０９２３３５号明細書

【非特許文献】

【0010】

【文献】ｈｔｔｐｓ：／／ｗｉｋｉ．ａｒｃｈｌｉｎｕｘ．ｏｒｇ／ｉｎｄｅｘ．ｐｈｐ／ｗｉｎｄｏｗ＿ｍａｎａｇｅｒ

【発明の概要】

【発明が解決しようとする課題】

【0011】

本発明の目的は、ディスプレイサーバコンポーネントおよびディスプレイのタイプに対してより柔軟性のあるアプリケーションによって３Ｄ画像コンテンツを表示するやり方を提供することである。

【課題を解決するための手段】

【0012】

本発明の第１の態様によれば、ディスプレイ上にアプリケーションのビューを表示するためのシステムが提供され、ビューは３Ｄディスプレイのための３Ｄ画像コンテンツを表す。このシステムは：
－ オペレーティングシステムを表すシステムデータおよびアプリケーションを表すアプリケーションデータを含むメモリ；
－ メモリと通信し、オペレーティングシステムおよびアプリケーションを実行するように構成されたプロセッササブシステム；
を備え、
オペレーティングシステムは：
－ アプリケーションによって生成されたビューの可視性を管理するためのウィンドウマネージャ；
－ ディスプレイのタイプに固有の１つ以上のディスプレイサーバコンポーネントであって、ウィンドウマネージャから得られた可視性情報に基づいて、各ビューを、ディスプレイのための表示信号へと合成するように構成された、１つ以上のディスプレイサーバコンポーネント；
を提供するように構成されており、
アプリケーションは、ウィンドウマネージャに、３Ｄ画像コンテンツを、ビュー構成に従って互いに対して配置構成された少なくとも２つのビューの形態で提供するように構成されており、少なくとも２つのビューは、２Ｄ画像データを含む１次ビューと、２Ｄ画像データの奥行きを表す３Ｄ可能化補助データを含む２次ビューとを含み、ビュー構成は、２Ｄディスプレイのための２Ｄディスプレイサーバコンポーネントに、少なくとも２つのビューを表示信号へと合成するとき、２次ビューを省略させるかまたは２次ビューに上描きさせる。

【0013】

本発明のさらなる態様によれば、このシステムを備えるディスプレイデバイスが提供される。

【0014】

本発明のさらなる態様によれば、オペレーティングシステムのウィンドウマネージャにアプリケーションのビューを提供するための、コンピュータにより実行される方法が提供され、ビューは３Ｄディスプレイのための３Ｄ画像コンテンツを表し、オペレーティングシステムは：
アプリケーションによって生成されたビューの可視性を管理するように構成されたウィンドウマネージャ；
ディスプレイのタイプに固有の１つ以上のディスプレイサーバコンポーネントであって、ウィンドウマネージャから得られた可視性情報に基づいて、ビューを、ディスプレイのための表示信号へと合成するように構成された、１つ以上のディスプレイサーバコンポーネント
を提供するように構成されており；
方法は、アプリケーションによって、ウィンドウマネージャに、３Ｄ画像コンテンツを、ビュー構成に従って互いに対して配置構成された少なくとも２つのビューの形態で提供することを含み、少なくとも２つのビューが、２Ｄ画像データを含む１次ビューと、２Ｄ画像データの奥行きを表す３Ｄ可能化補助データを含む２次ビューとを含み、ビュー構成は、２Ｄディスプレイのための２Ｄディスプレイサーバコンポーネントに、少なくとも２つのビューを表示信号へと合成するとき、２次ビューの描画を省略させるかまたは２次ビューに上描きさせる。

【0015】

本発明のさらなる態様によれば、オペレーティングシステム上で実行されるアプリケーションのビューを合成するための、コンピュータにより実行される方法が提供され、ビューは３Ｄディスプレイのための３Ｄ画像コンテンツを表し、オペレーティングシステムは：
アプリケーションによって生成されたビューの可視性を管理するためのウィンドウマネージャ；
３Ｄディスプレイのための３Ｄディスプレイサーバコンポーネントであって、ウィンドウマネージャから得られた可視性情報に基づいて、ビューを、３Ｄディスプレイのための表示信号へと合成するように構成された３Ｄディスプレイサーバコンポーネント
を提供するように構成されており；
アプリケーションは、ウィンドウマネージャに、３Ｄ画像コンテンツを、ビュー構成に従って互いに対して配置構成された少なくとも２つのビューの形態で提供するように構成されており、少なくとも２つのビューは、２Ｄ画像データを含む１次ビューと、２Ｄ画像データの奥行きを表す３Ｄ可能化補助データを含む２次ビューとを含み、ビュー構成には、２Ｄディスプレイのための２Ｄディスプレイサーバコンポーネントに、少なくとも２つのビューを表示信号へと合成するとき、２次ビューを省略させるかまたは２次ビューに上描きさせ、
方法は、３Ｄディスプレイサーバコンポーネントによって：
－ アプリケーションから受け取られたシグナリングまたはアプリケーションのメタデータに基づいて、少なくとも２つのビューが３Ｄ画像コンテンツを表すと決定することと；
－ １次ビューおよび２次ビューを処理して、３Ｄディスプレイのための表示信号を得ることと
を含む。

【0016】

本発明のさらなる態様が提供する一時的または非一時的なコンピュータ可読媒体が含むコンピュータプログラムは、アプリケーションまたは３Ｄディスプレイサーバコンポーネントを表すものであり、プロセッサシステムにそれぞれのエンティティを表す方法を実施させるための命令を含む。

【0017】

上記の方策は、ウィンドウマネージャに、少なくとも２つのビュー、すなわち、２Ｄ画像データを含む１次ビュー、および２Ｄ画像データの奥行きを表す３Ｄ可能化補助データを含む２次ビューの形態で、３Ｄ画像コンテンツを提供するアプリケーションを伴う。ここと他のどこかで、「ビュー」という用語は、「ビューオブジェクト」とも称され得、グラフィカルユーザインターフェースの基本ビルディングブロックを指し得る。一般的には、ビューは、アプリケーションのコンテンツを表示するスクリーン上の矩形のエリアを表す。たとえば、アンドロイドでは、そのようなビューはパブリッククラス「ビュー」によって表され得、ｉＯＳでは、そのようなビューは「ビューオブジェクト」などによって表され得る。多くのオペレーティングシステムでは、アプリケーションの「ウィンドウ」は１つ以上のビューを含み得、そのため、ビューは別個のウィンドウによって表される必要はないことが留意される。

【0018】

したがって、１次ビューは、写真（静止画像）、ビデオフレーム、コンピュータレンダリングなどによって生成された画像などの画像を示してよく、一方、３Ｄ可能化補助データが前記画像の奥行きを表し得る。２Ｄ画像データおよび３Ｄ可能化補助データによって３Ｄ画像コンテンツを表す概念は、それ自体知られている。そのような補助データは、限定はしないが、２Ｄ画像データとともに１対の立体画像を表すさらなる２Ｄ画像データ、またはカメラもしくは視聴者に対する、２Ｄ画像データの中に示されたオブジェクトの距離を表す奥行き関連のデータを含む、様々な形態をとり得る。

【0019】

したがって、アプリケーションは、２Ｄ画像データに対する別個のビューおよび３Ｄ可能化補助データに対する別個のビューを作成し得る。ビューは、ビュー構成に従って、たとえば空間的な意味において互いに対して相互に配置構成される。そのようなビュー構成は、アプリケーションによって定義され、および／または提供されてよく、たとえばアプリケーションのウィンドウの内部で、少なくとも両方のビューの相対位置を定義する１つ以上のパラメータによって表され得る。たとえば、ビュー構成は所定のビュー構成でよい。たとえば、アンドロイドでは、パラメータはパブリッククラス「ＲｅｌａｔｉｖｅＬａｙｏｕｔ」パラメータでよく、これにしたがって、ビューの位置が互いに関連して記述され得る。このように構成された相対位置が、次いで、アプリケーションによって、引数として特定のＲｅｌａｔｉｖｅＬａｙｏｕｔを有する関数Ｓｅｔ．ＣｏｎｔｅｎｔＶｉｅｗを使用して提供され得る。

【0020】

オペレーティングシステムおよび／またはウィンドウマネージャのタイプに応じて様々な他の機構が存在し、１次ビューおよび２次ビューに関するビュー構成を定義し、および／または提供するために有利に使用され得ることが理解されよう。

【0021】

上記の方策によれば、アプリケーションは、２Ｄディスプレイのための、たとえば「レガシー」ディスプレイサーバコンポーネントといった２Ｄディスプレイサーバコンポーネントが、少なくとも２つのビューを表示信号へと合成するとき、２次ビューの描画を省略するかまたは２次ビューに上描きするように、ビュー構成を特に定義し、および／または提供する。そのため、２Ｄディスプレイサーバコンポーネントは３Ｄ可能化補助データを表示することを省略して、むしろ２Ｄ画像データ（のみ）を表示することになる。「表示信号」という用語は、ここおよび下記では、それ自体知られているものとすることができる、ディスプレイサーバコンポーネントによってディスプレイに固有のやり方でフォーマットされた信号を指し得る。表示信号は、たとえばディスプレイに固有のやり方でフォーマットされた出力バッファにおける出力画像として生成される。

【0022】

非限定的な例は、２次ビューの前に１次ビューをスタックして、ビュー構成として１次ビューが２次ビューをオクルージョンするビュー構成を提供するようにアプリケーションが構成され得るものである。そのようなビューのスタッキングは、実際にはパブリッククラス「ＲｅｌａｔｉｖｅＬａｙｏｕｔ」のデフォルト挙動でよく、アプリケーションは、１次ビューが２次ビューの前に、逆ではなくスタックされることだけを保証すればよい。これは、たとえば、特に２次ビューの前に１次ビューがスタックされる、両方のビューに相対的な、Ｚ順序を割り当てる、アプリケーションによって行われてよい。パブリッククラス「ＲｅｌａｔｉｖｅＬａｙｏｕｔ」の例を再び参照して、これは、アプリケーションまたはプログラマがビューの適切な列挙順序を選ぶこと、または関数ｖｉｅｗ．ｓｅｔＺ（ｆｌｏａｔ）を使用することなどを伴い得る。

【0023】

２Ｄディスプレイサーバコンポーネントは、オペレーティングシステムにおいて存在し、アクティブであるなら、２次ビューが１次ビューによってオクルージョンされると決定したときには、２次ビューに上描きするか、または２次ビューの描画を省略してよい。

【0024】

同時に、３Ｄディスプレイサーバコンポーネントは、オペレーティングシステムにおいて存在し、アクティブであるなら、たとえばアプリケーションから受け取られたシグナリングまたはアプリケーションのメタデータに基づいて、少なくとも２つのビューが３Ｄ画像コンテンツを表すと決定し得る。３Ｄディスプレイサーバコンポーネントは、１次ビューおよび２次ビューが３Ｄ画像コンテンツを表すと識別すると、次いで、３Ｄディスプレイのための表示信号を得るように、それ自体知られているやり方で１次ビューおよび２次ビューを処理し得る。そのため、３Ｄディスプレイサーバコンポーネントは、２次ビューに上描きするのではなく、たとえば、表示信号において、１次ビューに加えて２次ビューを並べて配置構成してよい。

【0025】

上記の方策は、アプリケーションによって３Ｄ画像コンテンツを出力する、後方互換性のあるやり方を提供するものである。すなわち、「レガシー」２Ｄディスプレイサーバコンポーネントが１次ビューを示す一方で、３Ｄディスプレイサーバコンポーネントが、２次ビューにおける３Ｄ可能化補助データにアクセスして、２Ｄ画像データおよび３Ｄ可能化補助データを適切に処理し得る。

【0026】

これは、２Ｄディスプレイサーバコンポーネントにばかりなく、アプリケーションによって提供された少なくとも２つのビューが３Ｄ画像コンテンツを表すことを決定するようには構成されていない他の（「レガシー」）タイプのディスプレイサーバコンポーネントにも、後方互換性を提供し得る。そのようなレガシーディスプレイサーバコンポーネントは、前述の２Ｄディスプレイサーバコンポーネントばかりでなく、レガシー３Ｄディスプレイサーバコンポーネントと、ストリーミングするかまたはキャスティングするＭｉｒａｃａｓｔなどのサーバとをも含み得る。アプリケーションが、どのタイプのディスプレイサーバコンポーネントが存在し、アクティブであるかを検出し、アプリケーションの出力を相応に調節することの必要性がなくなるという、さらに別の利点がある。アプリケーションの出力を相応に調節することは、異なるタイプのディスプレイサーバコンポーネントが存在しアクティブであるマルチディスプレイのコンテキストでも不可能であろう。

【0027】

上記および下記において、ペレーティングシステムがウィンドウマネージャならびに／あるいは１つ以上のディスプレイサーバコンポーネントを「確立する」かまたは「提供する」ように構成されているオことに対するあらゆる言及が、オペレーティングシステムが、オペレーティングシステムにより、またはオペレーティングシステムを使用して、前記ソフトウエアコンポーネントが実行されることを可能にするように構成されていることを参照し得ることが留意される。いくつかの実施形態では、オペレーティングシステムは、ウィンドウマネージャおよび／またはディスプレイサーバを備え得る。他の実施形態では、ウィンドウマネージャおよび／またはディスプレイサーバは、オペレーティングシステムとは別々に提供され得るソフトウエアコンポーネントでよい。

【0028】

アプリケーションは、２次ビューの前に１次ビューをスタックして、ビュー構成として１次ビューが２次ビューをオクルージョンするビュー構成を提供するように構成され得る。たとえば、アプリケーションは、１次ビューおよび２次ビューに対して、１次ビューを２次ビューの前にスタックさせる相対的Ｚ順序を割り当てるように構成され得る。

【0029】

任意選択で、アプリケーションは、１次ビューと２次ビューの間にスタックされたバリアビューを提供するように構成され、バリアビューは、不透明であり、均質な画像データを含む。１次ビューは、部分的に透光性に定義されること、またはディスプレイサーバコンポーネントによって部分的に透光性のものとして扱われることがある。たとえば、１次ビューの２Ｄ画像データは、局所的透明性を提供するために、それ自体知られているＲＧＢＡタプルを含んでよい。そのため、２Ｄディスプレイサーバコンポーネントは、依然として２次ビューを用いて１次ビューに上描きしてよいが、１次ビューの（部分的に）透光性が、２次ビューを依然として部分的に可視にさせるため、１次ビューにおける２Ｄ画像データの表示が乱される可能性がある。そのような乱れを回避するかまたは低減するために、たとえば１次ビューのＺ順序と２次ビューのＺ順序との間のＺ順序を選択することにより、１次ビューと２次ビューの間にバリアビューが提供されスタックされ得る。２次ビューがバリアビューによってオクルージョンされるように、２Ｄディスプレイサーバコンポーネントによるビュー合成中に、アプリケーションによって、不透明、たとえば非透光性であるようにバリアビューが生成される。２Ｄ画像データを１次ビューに重ね合わせる際のいかなる乱れも低減するように、均質の画像データを含むようにバリアビューがさらに生成される。たとえば、バリアビューは、均質な黒、ダークグレーまたはライトグレーでよい。

【0030】

アプリケーションは：
－ １次ビューの２Ｄ画像データを含むビューポートを示すことによって、ウィンドウマネージャに１次ビューを提供し；
－ ビューポートの外部に２次ビューの３Ｄ可能化補助データを配置構成することによってウィンドウマネージャに２次ビューを提供する
ように構成され得る。

【0031】

２次ビューの前に１次ビューをスタックすることに対して、様々な代替形態が存在する。たとえば、１次ビューは、たとえばバッファの中に１次ビューの２Ｄ画像データを含むビューポートをウィンドウマネージャに示すことによってウィンドウマネージャに提供され得る。３Ｄ可能化補助データは、ビューポートの外部で、たとえばビューポートの外部の同一のバッファ、または異なるバッファの中に配置構成されてよい。それゆえに、「レガシー」ディスプレイサーバコンポーネントは、ビューポートに示されるように１次ビューを描画してよいが、２次ビューは、ビューポートの外部に配置されているので描画するのを省略してよい。

【0032】

任意選択で、１つ以上のディスプレイサーバコンポーネントは、３Ｄディスプレイのための３Ｄディスプレイサーバコンポーネントを備え、アプリケーションは、少なくとも２つのビューが３Ｄ画像コンテンツを表すことを３Ｄディスプレイサーバコンポーネントにシグナリングするように構成される。オペレーティングシステムにおいて３Ｄディスプレイのための３Ｄディスプレイサーバコンポーネントが存在し、アクティブであれば、アプリケーションは、２つのビューが３Ｄ画像コンテンツを表すことを３Ｄディスプレイサーバコンポーネントにシグナリングし得る。たとえば、３Ｄディスプレイサーバコンポーネントは、アプリケーションが３Ｄディスプレイサーバコンポーネントとインターフェースすることを可能にするためのアプリケーションプログラミングインターフェース（ＡＰＩ）を提供し得、アプリケーションは、少なくとも２つのビューが３Ｄ画像コンテンツを表すことを、たとえばＡＰＩを介して３Ｄディスプレイサーバコンポーネントに少なくとも２つのビューの識別子を登録することにより、ＡＰＩを介して、３Ｄディスプレイサーバコンポーネントにシグナリングするように構成され得る。加えて、またはその代わりに、３Ｄディスプレイサーバコンポーネントは、アプリケーションの識別子などのアプリケーションのメタデータに基づいて、少なくとも２つのビューが３Ｄ画像コンテンツを表すことを検出するように構成され得る。そのため、３Ｄディスプレイサーバコンポーネントは、少なくとも２つのビューが３Ｄ画像コンテンツを表すことを学習し、それにしたがって、２つのビューにおける画像（データ）を処理し得る。

【0033】

任意選択で、３Ｄディスプレイサーバコンポーネントは、１）１次ビューと２次ビューとが、立体表示フォーマットに従って表示信号において同時に示されるように配置構成すること、または２）１次ビューおよび２次ビューに基づいて１つ以上のさらなるビューを生成し、１次ビューと、１つ以上のさらなるビューとを、マルチビュー表示フォーマットに従って、表示信号において同時に配置構成することによって、少なくとも２つのビューを合成するように構成される。上記のオプションは、３Ｄディスプレイサーバコンポーネントが、１次ビューおよび２次ビューを処理して３Ｄディスプレイのための表示信号を得るための、それ自体知られているやり方を定義するものである。第１のオプションは、立体コンテンツ（たとえば、左画像を表す２Ｄ画像データ、右画像を表す３Ｄ可能化補助データ）に適用可能であり得、ビュー合成は、上下の（ｔｏｐ－ｂｏｔｔｏｍ）立体フォーマットに従って、またはたとえばラインベースで空間的にインターリーブして、両方のビューを、たとえば並べて同時に示すことを伴い得る。第２のオプションは、いわゆるマルチビューコンテンツに適用可能であり得、マルチビューコンテンツでは、３Ｄ可能化補助データが奥行きマップなどの奥行き関連のコンテンツを表し、１次ビューに示されたものに加えて、シーンの代替のビューポイントを表す１つ以上のさらなるビューをレンダリングするために、いわゆるビューレンダリング技術またはビューシンセシス技術が使用される。異なるタイプの３Ｄ表示フォーマットの間の変換が知られていることが留意される。そのため、ビューは、３Ｄ可能化補助コンテンツのタイプに関係なく、所望の表示フォーマットを得るように処理され得る。たとえば、アプリケーションが立体コンテンツを出力する場合、３Ｄディスプレイサーバコンポーネントは、両画像の間のディスパリティを推定し、ディスパリティマップを使用して、マルチビューディスプレイのための１つ以上のさらなるビューをレンダリングし得る。反対に、アプリケーションが３Ｄ可能化補助コンテンツとして奥行きマップを提供する場合には、ディスプレイサーバコンポーネントは、第２の画像をビューレンダリングして、出力として立体コンテンツを提供する。

【0034】

本発明の前述の実施形態、実装形態、および／または任意選択の態様のうちの２つ以上が、有効と考えられる任意のやり方で組み合わされ得ることが当業者には諒解されよう。

【0035】

対応するシステムの説明された修正形態および変形形態に対応する、任意のコンピュータにより実行される方法および／または任意のコンピュータプログラム製品の修正形態および変形形態が、当業者によって本説明を基に実行され得、逆の場合も同じである。

【0036】

本発明のこれらの態様および他の態様は、以下で説明される実施形態から明らであり、これらを参照することによって解明されよう。

【図面の簡単な説明】

【0037】

【図1】アプリケーション、ウィンドウマネージャおよびいくつかのディスプレイサーバコンポーネントの間の相互作用の図式的概観であり、アプリケーションは、ウィンドウマネージャに対して、３Ｄ画像コンテンツを、２Ｄ画像データを含む１次ビューと３Ｄ可能化補助データを含む２次ビューとの形態で提供し、それぞれのディスプレイサーバコンポーネントは、アプリケーションのビューを、ウィンドウマネージャから得られた可視性情報に基づいて、それぞれのタイプのディスプレイ上で表示するための表示信号へと合成するように構成されている。

【図2A】２次ビューの前に１次ビューをスタックするアプリケーションの結果を示す図であり、２Ｄディスプレイのための２Ｄディスプレイサーバコンポーネントに、２つのビューを表示信号へと合成するとき、２次ビューの描画を省略させるかまたは２次ビューに上描きさせる。

【図2B】ウィンドウマネージャに対して１次ビューの２Ｄ画像データを含むビューポートを示すアプリケーションを示す図であり、一方、２次ビューの３Ｄ可能化補助データはビューポートの外部に配置される。

【図3】アンドロイドオペレーティングシステムのための特定の実施形態を示す図である。

【図4】ディスプレイ上にアプリケーションのビューを表示するためのシステムを示す図である。

【図5】命令データを含むコンピュータ可読媒体を示す図である。

【発明を実施するための形態】

【0038】

異なる図において同一の参考番号を有するアイテムは、同一の構造的特徴および同一の機能を有するか、または同一の信号であることに留意されたい。そのようなアイテムの機能および／または構造が説明されたときには、発明を実施するための形態において繰り返し説明する必要はない。

【0039】

参照記号のリスト
以下の参考記号のリストは、図面の解釈を容易にするために提供されるものであり、請求項を制限するようには解釈されないものとする。
０８０ （３Ｄ）ディスプレイ
１００ アプリケーションのビューを表示するためのシステム
１２０ プロセッササブシステム
１２２ データ通信
１４０ メモリ
１４２ データ通信
１６０ 大容量記憶装置
１６２ データ通信
１８０ 表示出力
１８２ 表示データ
２００ アプリケーション
２１０ バッファ
２１２ バッファ
２１４ バッファ
２２０ ウィンドウマネージャ
２４０ ディスプレイサーバ
２５２ ２Ｄディスプレイサーバコンポーネント
２５４ ３Ｄ（マルチビュー）ディスプレイサーバコンポーネント
２５６ ３Ｄ（立体）ディスプレイサーバコンポーネント
２６０ アンドロイドＢＳＰ
２６２ アンドロイドのＷｉｎｄｏｗＭａｎａｇｅｒ
２６４ アンドロイドのＳｕｒｆａｃｅＦｌｉｎｇｅｒ
２８０ サービスプロセス
２８２ 拡張子（Ｈｏｏｋ）
２８４ サービスＡＰＩ
３００ ２Ｄ画像データ
３１０ ３Ｄ可能化補助データ
４００ １次ビュー、２Ｄビュー
４１０ ２次ビュー、３Ｄ可能化補助ビュー
４２０ Ｚ順序
４３０ ビューポート
４４０ ２Ｄディスプレイのための表示信号
４４２ ３Ｄ（マルチビュー）ディスプレイのための表示信号
４４４ ３Ｄ（立体）ディスプレイのための表示信号
５００ コンピュータ可読媒体
５１０ 命令データ

【0040】

図１は、オペレーティングシステムのソフトウエアコンポーネントまたはオペレーティングシステム上で走るソフトウエアコンポーネント、すなわち、アプリケーション２００、ウィンドウマネージャ２２０およびディスプレイサーバ２４０の図式的概観を示すものであり、ディスプレイサーバ２４０は、例として、２Ｄディスプレイのための２Ｄディスプレイサーバコンポーネント２５２（図１では「２Ｄ合成」のラベルが付いている）と、マルチビュー３Ｄディスプレイのための３Ｄディスプレイサーバコンポーネント２５４（「２Ｄ＋３Ｄ補助合成」のラベルが付いている）と、立体３Ｄディスプレイのための別の３Ｄディスプレイサーバコンポーネント２５６（「２Ｄ＋３Ｄ補助合成 ＋ 立体出力」のラベルが付いている）とを備えるものとして示されている。引き続き図１を参照しながら図２Ａを参照して、ディスプレイサーバコンポーネント２５２－２５６の各々のビュー合成が以下でさらに説明される。

【0041】

図１に見られるように、アプリケーション２００は、２Ｄ画像データ３００および付随の３Ｄ可能化補助データ３１０を、たとえばソリッドステートドライブもしくはハードディスクなどの大容量記憶デバイス（図１には示されていない）から、またはローカルエリアネットワークもしくは広域ネットワーク（これも図１には示されていない）からストリーミングするやり方で、受け取るかまたは取得し得る。特定の例では、２Ｄ画像データ３００と３Ｄ可能化補助データ３１０がともに、３Ｄ画像または３Ｄビデオの３Ｄビデオフレーム（映画または短いビデオクリップなど）を表し得る。さらに別の例では、アプリケーションは、たとえば出力として立体画像あるいは画像および付随の奥行きマップを提供するコンピュータレンダリング技術によって、２Ｄ画像データ３００および３Ｄ可能化補助データ３１０を生成し得る。さらに別の例では、アプリケーション２００は、２Ｄ画像データ３００を受け取るか取得し、たとえばその部分はそれ自体知られている奥行き推定技術を使用して、３Ｄ可能化補助データを生成し得る。

【0042】

アプリケーション２００は、次いで、２Ｄ画像データ３００を含む２Ｄビュー４００を生成し得る。２Ｄビュー４００は「１次ビュー」とも称される。ここで、「含む」という用語は、２Ｄビュー４００が通常は２Ｄ画像データ３００を示すことを指すが、たとえばウィンドウマネージャ２２０によって課せられる２Ｄビュー４００の可視性の制限を被ることがある。アプリケーション２００は、３Ｄ可能化補助データを含む３Ｄ可能化補助ビュー４１０をさらに生成し得る。３Ｄ可能化補助ビュー４１０は「２次ビュー」とも称される。たとえば、両方のビュー４００、４１０のデータは、たとえばバッファオブジェクトとしてそれぞれのバッファ２１０、２１２に記憶されてよく、または同一のバッファの中に別個のバッファオブジェクト（図１には示されていない）として記憶されてもよい。アプリケーション２００は、たとえばａｎｄｒｏｉｄ．ｖｉｅｗ．ＷｉｎｄｏｗＭａｎａｇｅｒクラスのａｄｄＶｉｅｗ（）を使用して、ウィンドウマネージャ２２０に両方のビュー４００、４１０を提供し得る。ウィンドウマネージャは、アプリケーションのビューの可視性を全体的に管理し得る。たとえば、他のアクティブなアプリケーションがある場合には、ビュー４００、４１０は、大部分が見えるか、あるいは、たとえば別のアプリケーションのビューによってオクルージョンされることにより、またはビュー４００、４１０が「最小化されること」を含むアプリケーション２００のウィンドウによって、ほとんど見えなくなるか、決定され得る。

【0043】

１次ビュー４００と２次ビュー４１０は、これらの少なくとも２つのビューを表示信号へと合成するとき２Ｄディスプレイのための２Ｄディスプレイサーバコンポーネントに２次ビューの描画を省略させるかまたは２次ビューに上描きさせるビュー構成に従って、アプリケーションによって互いに配置構成される。たとえば図２Ａおよび図２Ｂを参照しながら解明されたように、そのようなビュー構成を定義するかまたは提供するための様々なやり方がある。

【0044】

図２Ａは、アプリケーションが、２次ビュー４１０の前に１次ビュー４００をスタックし、それによって２次ビュー４１０をオクルージョンすることの結果を示すものである。図２Ａは、解説のために、１次ビュー４００の下にある２次ビュー４１０を示すように、斜視の全体像を示していることが留意される。しかしながら、ディスプレイサーバコンポーネントは、１次ビュー４００を全体的または少なくとも実質的に全体的に考慮に入れ、２次ビュー４１０をオクルージョンする。たとえば、２次ビュー４１０は、２次ビュー４１０を１次ビュー４００の後に置くアプリケーションによって、Ｚ順序を割り当てられてよい。同時に、２次ビュー４１０の場所およびサイズは、２次ビュー４１０が１次ビュー４００によって（実質的に）全体的にオクルージョンされるように選ばれ得る。たとえば、両方のビュー４００、４１０は、たとえばアプリケーションのウィンドウ（図２Ａでは明示的には示されていない）において、同じ場所およびサイズを割り当てられ得る。次いで、スタックされたビュー４００、４１０は、たとえばスタックされたビュー４００、４１０が３Ｄ画像コンテンツを表すと決定することができないディスプレイサーバコンポーネントである「レガシー」ディスプレイサーバコンポーネントに、２つのビューを表示信号へと合成するときに１次ビュー４００により２次ビュー４１０に上描きさせて、それにより２次ビューをオクルージョンする。

【0045】

この概念は、「明示的上描き」と称されることもあり、「明示的上描き」において、出力画像は多数回更新される。１次ビュー４００が（半）透明である場合、１次ビュー４００と２次ビュー４１０の間に、黒色かそうでなければ不透明で均質のバリアビューが挿入されてよい。ここで、「間に挿入される」は、バリアビューを、１次ビュー４００の後、しかし２次ビュー４１０の前に置くＺ順序をバリアビューが有することを指すものであり、バリアビューは、好ましくは、１次ビュー４００および／または２次ビュー４１０と同じ場所およびサイズを有する。あるいは、ディスプレイサーバコンポーネントは、２次ビュー４１０がオクルージョンされると決定し得る場合には、２次ビュー４１０の描画を全体的に省略してもよい。

【0046】

「レガシー」ディスプレイサーバコンポーネントに上描きさせるために、アプリケーションによって生成されるビュー４００、４１０は、アプリケーションによる合成最適化をバイパスするために、オペレーティングシステムによってのみ構成され得るタイプでよいことが留意される。たとえば、アンドロイドでは、これは、ビュー４００、４１０が「ＳｕｒｆａｃｅＶｉｅｗ」タイプのビューであることによって達成され得る。

【0047】

引き続き図１および図２Ａを参照して、３Ｄディスプレイサーバコンポーネント２５４、２５６は、図２Ａのスタックされたビュー４００、４１０が３Ｄ画像コンテンツを表すと決定するように構成され得る。また、後に図３を参照しながら解明されるように、これは、たとえばアプリケーション２００から受け取られたシグナリングまたはアプリケーション２００のメタデータに基づいて決定され得る。それゆえに、３Ｄディスプレイサーバコンポーネント２５４、２５６は、３Ｄディスプレイのための表示信号を得るように１次ビュー４００および２次ビュー４１０を処理し得る。処理および合成の様々なやり方は、３Ｄ処理および３Ｄディスプレイの当技術においてそれ自体知られている。

【0048】

図１は２つの非限定的な例を示すものである。第１の例によれば、３Ｄディスプレイサーバコンポーネント２５４は、ビューレンダリング技術またはビューシンセシス技術を使用することにより、２Ｄ画像データからマルチビューディスプレイのための表示信号４４２を生成し、また、３Ｄ可能化補助データを使用して、例として図１の「Ｘ」、「Ｙ」および「Ｚ」とラベルを付けられた他の２Ｄ画像の形態の２Ｄ画像データによって示されるシーンの他のビューポイントを生成するように構成され得る。そのようなビューポイントは「ビュー」と称されることも多い（そのため「ビューレンダリング」および「ビューシンセシス」という名称もある）が、アプリケーションビュー４００、４１０と混同されるべきではない。ビューレンダリングまたはビューシンセシスのタイプは、３Ｄ可能化補助データ３１０のタイプに依存し得るが、通常は、２Ｄ画像データで示されたオブジェクトのカメラまたは視聴者に対する距離を表す奥行き関連のデータを使用する。３Ｄ可能化補助データ３１０が、むしろ２Ｄ画像データとともに１対の立体画像を表すさらなる２Ｄ画像データを表す場合には、そのような奥行き関連のデータは、最初に、たとえばそれ自体知られているディスパリティ推定技術を使用して、対の立体画像から生成されてよい。

【0049】

３Ｄディスプレイサーバコンポーネント２５４は、次いで、図１において「２Ｄ」とラベルを付けられた、１次ビュー４００の２Ｄ画像データのモザイク状の合成と、この例では３つのさらなるビュー（ポイント）Ｘ、ＹおよびＺである他のビュー（ポイント）の２Ｄ画像データとを作成し得る。次いで、表示信号４４２は、出力画像信号として３Ｄマルチビューディスプレイに提供されてよく、そこで、３Ｄマルチビューディスプレイは、異なるビュー（ポイント）の画像データを使用して、シーンを３Ｄでレンダリングしてよい。

【0050】

空間のモザイク状の合成の代わりに、様々な他の知られているタイプのマルチビュー合成が使用され得ることが留意される。たとえば、ビューは空間的および／または時間的にインターリーブされ得る。ビューポイントに加えて、またはその代わりに、他のデータが表示信号に提供されてもよい。たとえば、３Ｄ可能化補助データ自体が、表示信号、および／または透明度情報および／またはオクルージョン情報において提供され得る。別の例は、表示信号が、少なくとも２つのビューから生成されたポイントクラウドまたは３Ｄメッシュなどを含み得るものである。一般に、表示信号は、単一のものばかりでなく、たとえばデュアルＤｉｓｐｌａｙＰｏｒｔといった多数の独立したデータチャネルおよび／またはケーブルによってディスプレイに提供され得ることが留意される。

【0051】

第２の例によれば、３Ｄディスプレイサーバコンポーネント２５６は、立体表示のための表示信号４４４を生成するように構成され得る。このビュー合成は、３Ｄ可能化補助データ３１０のタイプに応じて、異なる形態をとり得る。たとえば、３Ｄ可能化補助データ３１０は、さらなる２Ｄ画像データを表し、これは２Ｄ画像データとともに１対の立体画像を表す。この場合、２Ｄ画像データ３００が左画像を表し、さらなる２Ｄ画像データ３１０が右画像を表すなら、３Ｄディスプレイサーバコンポーネント２５６は、これらの画像を、並んでフォーマットされた表示信号４４４へと合成し得る。空間的および／または時間的立体ビュー合成の様々な他の知られているタイプも、代わりに使用され得ることが留意される。しかしながら、３Ｄ可能化補助データ３１０が、２Ｄ画像データに示されたオブジェクトのカメラまたは視聴者に対する距離を表す奥行き関連のデータを表す場合には、前述のビューレンダリング技術またはビューシンセシス技術を使用して、さらなる２Ｄ画像データ（たとえば右画像）が生成され得る。

【0052】

図２Ｂは、ビュー構成に従って１次ビュー４００と２次ビュー４１０を互いに配置構成するアプリケーションのさらなる例を示すものであり、これは、２Ｄディスプレイのための２Ｄディスプレイサーバコンポーネントに、少なくとも２つのビューを表示信号へと合成するとき、ビュー構成によって、２次ビューの描画を省略させるかまたは２次ビューに上描きさせる。すなわち、この例では、アプリケーションは、ウィンドウマネージャに対して、１次ビュー４００の２Ｄ画像データを含むビューポート４３０を示す。たとえば、ビューポート４３０は、バッファ２１４（一般に特定の物理的バッファというよりむしろ論理的バッファであるバッファを指す「バッファオブジェクト」でよい）に対して定義され得る。図２Ｂにも示されているように、２次ビュー４１０の３Ｄ可能化補助データが、次いで、バッファ２１４におけるビューポート４３０の外部に配置され得て、「レガシー」ディスプレイサーバコンポーネントに２次ビュー４１０の描画を省略させる。あるいは、２次ビュー４１０の３Ｄ可能化補助データは、ビューポート４３０の外部に、異なるやり方で、たとえば異なるバッファに配置され得る。

【0053】

図３は、アンドロイドオペレーティングシステムの特定の実施形態を示すものである。繰り返しになるが、アプリケーション２００は、２Ｄ画像データ３００および３Ｄ可能化補助データ３１０を回復するかまたは取得し、２Ｄ画像データを含む１次ビュー４００と、３Ｄ可能化補助データを含む２次ビュー４１０とを提供するように示されている。図３は、２次ビュー４１０の上にスタックされた１次ビュー４００を示すが、「レガシー」ディスプレイサーバコンポーネントに、２次ビュー４１０に上描きさせるかまたは２次ビュー４１０の描画を省略させるように、両方のビューが互いに違った風に配置構成されることもある。これは、図１に示されたビューにも適用される。

【0054】

図３の例では、アプリケーション２００は２次ビュー４１０を全画面表示のものとして提供し、２次ビュー４１０の上に１次ビュー４００を配置構成し得る。

【0055】

図３は、ウィンドウマネージャ２６２と、Ａｎｄｒｏｉｄ Ｂｏａｒｄ Ｓｕｐｐｏｒｔ Ｐａｃｋａｇｅ（ＢＳＰ）２６０の一部であり得るＳｕｒｆａｃｅＦｌｉｎｇｅｒ ２６４とをさらに示す。ＳｕｒｆａｃｅＦｌｉｎｇｅｒ ２６４は、アプリケーションビューを処理し、３Ｄディスプレイのためのビュー合成を実施するかまたは少なくとも可能にすることにより、３Ｄディスプレイサーバコンポーネントの少なくとも一部分を具現し得る。

【0056】

アプリケーション２００のスタックされたビュー４００、４１０が３Ｄ画像コンテンツを表すことを、３Ｄディスプレイサーバコンポーネント２６４が決定するのを可能にするための様々なやり方がある。図３の例では、アプリケーション２００は、サービスＡＰＩ ２８４を介してサービスプロセス２８０を用いて３Ｄ画像コンテンツを表すために、スタックされたビュー４００、４１０を登録してよく、サービスプロセス２８０は、拡張子（「ｈｏｏｋ」）２８２によって３Ｄディスプレイサーバコンポーネント２６４と通信することができる。したがって、３Ｄディスプレイサーバコンポーネントは、アプリケーションのスタックされたビュー４００、４１０が３Ｄ画像コンテンツを表すと通知され得、それにしたがってビューを処理し得る。３Ｄディスプレイサーバコンポーネントが、アプリケーションのビューが３Ｄ画像コンテンツを表すと決定するのを可能にするように、サービスプロセス２８０が意図的に提供され得る。

【0057】

アンドロイドを参照しながら説明してきたが、上記の方策は、特定のオペレーティングシステムのためのアプリケーションを開発する当業者によって様々な他のタイプのオペレーティングシステムに適用され得るものである。たとえば、＊－ｎｉｘベースのオペレーティングシステム（Ｌｉｎｕｘ、ＢＳＤ、Ｕｎｉｘなど）については、多岐にわたるウィンドウマネージャ（ｈｔｔｐｓ：／／ｗｉｋｉ．ａｒｃｈｌｉｎｕｘ．ｏｒｇ／ｉｎｄｅｘ．ｐｈｐ／ｗｉｎｄｏｗ＿ｍａｎａｇｅｒを参照されたい）ならびに様々なカスタマイズ可能なディスプレイサーバ（たとえばＸ１１、Ｗａｙｌａｎｄベースのもの、Ｍｉｒ、ＤｉｒｅｃｔＦｂ）が存在する。ＭａｃＯＳまたはｉＯＳ（Ｑｕａｒｔｚ）については、Ｑｕａｒｔｚウィンドウサービスは、説明されたようなウィンドウサーバの機能性の少なくとも一部分を提供し得、Ｑｕａｒｔｚディスプレイサービス／Ｑｕａｒｔｚ合成サービス／ＸＱｕａｒｔｚは、説明されたようなディスプレイサーバコンポーネントのディスプレイサーバの機能性の少なくとも一部分を提供するように構成され得る。マイクロソフトＷｉｎｄｏｗｓについては、Ｄｅｓｋｔｏｐ Ｗｉｎｄｏｗ Ｍａｎａｇｅｒが、説明されたようなウィンドウサーバの機能性の少なくとも一部分を提供し得、ＧＤＩグラフィックスデバイスインターフェースは、説明されたようなディスプレイサーバまたはディスプレイサーバコンポーネントの機能性の少なくとも一部分を提供するように構成され得る。

【0058】

図４は、ディスプレイ０８０上にアプリケーションのビューを表示するためのシステム１００を示すものである。そのようなシステム１００は、たとえば図１－図３を参照しながら本明細書の中で説明されたようなオペレーティングシステムおよびアプリケーションを走らせるように構成され得る。システム１００は、オペレーティングシステムを表すシステムデータおよびアプリケーションを表すアプリケーションデータを含み得るメモリ１４０を備え得る。システム１００がさらに備え得るプロセッササブシステム１２０は、データ通信１４２によってメモリと通信し、オペレーティングシステムおよびアプリケーションを実行するように構成されている。例として、システム１００は、システム１００に接続されたディスプレイ０８０に対して表示データ１８２を出力するための表示出力を備えるようにさらに示される。表示データは、ディスプレイサーバコンポーネントによって生成された表示信号など、プロセッサシステム１２０の視覚化された出力を表し得、この視覚化された出力は、データ通信１２２を介して表示出力１８０に提供され得る。例として、システム１００は、２Ｄ画像データおよび３Ｄ可能化補助データを記憶し得る大容量記憶装置１６０を備えるようにさらに示され、このデータは、プロセッササブシステムによってデータ通信１６２を介してアクセスされ得る。

【0059】

一般に、システムは、たとえばセットトップボックス、パーソナルコンピュータ、ゲーミングコンソールまたは（３Ｄ）ディスプレイに接続可能な類似のデバイスといった個別のデバイスの中に、またはこの個別のデバイスとして具現され得る。あるいは、システムは、たとえばスマートフォン、タブレットデバイス、テレビ、ディスプレイ、モニタなどの（３Ｄ）ディスプレイを備えるディスプレイデバイスの中に、またはこのディスプレイデバイスとして具現され得る。一般に、本システムはデバイスまたは機器によって実現され得る。デバイスまたは機器は、適切なソフトウエアを実行する１つ以上の（マイクロ）プロセッサを備え得る。機能の機能性を実装するソフトウエアは、ダウンロードされたものであってよく、および／または、たとえばＲＡＭなどの揮発性メモリもしくはＦｌａｓｈなどの不揮発性メモリといった対応する１つまたは複数のメモリに記憶されてもよい。あるいは、システムの機能は、たとえばフィールドプログラマブルゲートアレイ（ＦＰＧＡ）といったプログラマブル論理の形態で、または特定用途向け集積回路（ＡＳＩＣ）として、またはその他のタイプの回路もしくは回路の組合せとして、デバイスまたは機器に実現され得る。

【0060】

本明細書で説明されたソフトウエアコンポーネントのうち任意のものが、たとえば実行可能コードといったコンピュータのための命令によって表され得、コンピュータのための命令は、たとえば機械可読の物理的マークの一続きの形態５１０で、および／または、たとえば磁気的または光学的な性質または値といった様々な電気的な性質または値を有する一連の要素として、コンピュータ可読媒体５００に記憶され得る。実行可能コードは、一時的または非一時的に記憶されてよい。コンピュータ可読媒体の例は、メモリデバイス、光記憶デバイス、オンラインソフトウェアなどを含む。図５は光ディスク５００を示すものである。たとえば、コンピュータ可読媒体５００は、本明細書で説明されるようなアプリケーション、および／または恐らくオペレーティングシステムの一部としてのディスプレイサーバコンポーネントを記憶し得る。

【0061】

前述の実施形態は本発明を限定することなく説明するものであり、当業者なら多くの代替実施形態を設計し得るはずであることに留意されたい。

【0062】

請求項では、括弧内におかれたあらゆる参照記号が、請求項を制限するものとして解釈されることはないものとする。「備える」という動詞およびその語形変化の使用は、請求項において明示されたもの以外の要素またはステップとの存在を除外するものではない。要素に先立つ冠詞「１つの（ａ）」または「１つの（ａｎ）」は、そのような要素が複数存在することを除外するものではない。「少なくとも１つの」などの表現は、要素のリストまたはグループに先行するとき、リストまたはグループからの要素のすべてまたはいくらかのサブセットの選択を表す。たとえば「Ａ、Ｂ、およびＣのうち少なくとも１つ」という表現は、Ａのみ、Ｂのみ、Ｃのみ、ＡとＢの両方、ＡとＣの両方、ＢとＣの両方、あるいはＡ、Ｂ、およびＣのすべて、を含むものと理解されたい。本発明は、いくつかの別個の要素を含むハードウェアおよび適切にプログラムされたコンピュータによって実行され得る。いくつかの手段を列挙するデバイス請求項では、これらの手段のうちのいくつかはハードウェアの全く同一のアイテムによって具現されてよい。互いに異なる従属請求項においてある特定の方策が詳述されているという単なる事実は、これらの方策の組合せが有利に使用され得ないことを示すわけではない。

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5】