特表 2024-546508 リアルタイムマルチソースビデオパイプライン

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-12-24

(54)【発明の名称】リアルタイムマルチソースビデオパイプライン

(51)【国際特許分類】

   G06T 1/20 20060101AFI20241217BHJP

   G06T 3/147 20240101ALI20241217BHJP

   G06T 1/60 20060101ALI20241217BHJP

   H04N 21/431 20110101ALI20241217BHJP

【ＦＩ】

G06T1/20 A

G06T3/147

G06T1/60 450D

H04N21/431

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024538230

(86)(22)【出願日】2022-12-21

(85)【翻訳文提出日】2024-08-14

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

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

(87)【国際公開日】2023-06-29

(31)【優先権主張番号】63/292,758

(32)【優先日】2021-12-22

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】596130705

【氏名又は名称】キヤノン ユーエスエイ，インコーポレイテッド

【氏名又は名称原語表記】ＣＡＮＯＮ Ｕ．Ｓ．Ａ．，ＩＮＣ

(74)【代理人】

【識別番号】110003281

【氏名又は名称】弁理士法人大塚国際特許事務所

(72)【発明者】

【氏名】デニー， ブラッドリー

【テーマコード（参考）】

5B047

5B057

5C164

【Ｆターム（参考）】

5B047EA07

5B047EB07

5B057AA20

5B057BA02

5B057CA01

5B057CA08

5B057CA12

5B057CA16

5B057CB01

5B057CB08

5B057CB12

5B057CB16

5B057CC01

5B057CD02

5B057CD03

5B057CE17

5B057CH02

5B057CH05

5B057DB02

5B057DB06

5B057DB09

5B057DC16

5C164FA10

5C164MA02S

5C164UB88P

(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】

【図1】図１は、本開示における画像処理アルゴリズムを示す。

【0011】

【図2】図２は、本開示における画像処理アルゴリズムを示す。

【0012】

【図3】図３は、本開示におけるハードウェア構成を示す。

【0013】

図全体にわたって、特に記載しない場合、同じ参照符号および文字は、図示された実施形態の同様の特徴、要素、構成要素または部分を示すために使用される。更に、主題開示を図を参照して詳細に説明するが、それは例示的実施形態に関連して行われる。添付の特許請求の範囲によって定義される主題開示の真の範囲および趣旨から逸脱することなく、説明された例示的実施形態に変更および修正を加えることができることが意図されている。

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

【0014】

本開示の例示的実施形態を、添付図面を参照して以下に詳細に説明する。以下の例示的実施形態は、本開示を実現するための単なる一例であり、本開示が適用される装置の個々の構造および様々な条件に応じて適切に修正または変更されることができることに留意されたい。このように、本開示は、決して以下の例示的実施形態に限定されるものではなく、以下に説明する図および実施形態に従って、説明する実施形態は、例として以下に説明する状況以外の状況においても適用／実施することができる。

【0015】

本開示は、１つまたは複数のビデオソースまたは画像ソースを取り込み、提供されたレイアウトに従ってビデオストリームに構成するマルチソースビデオ処理パイプラインについて説明する。本システムは、ターゲットの出力合成画像に予め定められたレイアウトと解像度を有利に使用するため、このように、これらの予め定められた特徴により、画像／ビデオのレンダリングを実行するために必要な演算の大部分は事前に計算することができることを可能にし、実行時（フレーム間）の演算はリアルタイム処理のオーバーヘッドを最小限にするように最小化することができる。これにより、画像処理コストが有利に削減され、ビデオデータストリームがコンピューティングデバイスによってレンダリングされる速度が向上する。

【0016】

本開示は、複数の画像ソース（リアルタイムのビデオ、静止画像、またはその組み合わせ）を単一の出力データストリームにコンパイルする画像処理アルゴリズムを提供し、これにより、画像は、表示デバイス上のユーザインタフェース内に出力及び表示される時、予め定められたレイアウトで提供される。アルゴリズムは、命令を実行するようにプロセッサ（ＣＰＵ）を構成するコンピュータ実行可能な命令のセットとして具現化される。アルゴリズムは、ラップトップ、デスクトップ、またはサーバコンピュータなど、コンピューティングデバイスが１つまたは複数の撮像デバイスから画像データを取得できる限り、いかなるコンピューティングデバイス上に存在してもよい。以下に、例示的アルゴリズムについて記載する。

【0017】

図１は、表示デバイス上でレンダリングされる画像パイプラインを作成するための画像処理アルゴリズムの例示的実施形態を示す。最初に、Ｓ１０１において、アルゴリズムは、単一の合成表示へと合成すべき所望の１つまたは複数の画像ソースを追加することにより、新しいビデオパイプラインを作成する。１つまたは複数の画像ソースには、１つの動的な画像コンテンツと静的なコンテンツが含まれる。例示的なタイプの動的なコンテンツには、ユーザが表示デバイスに表示されているウィンドウから情報を選択し、その情報を他のコンピューティングデバイスに利用可能にさせるような場合にコンピューティングデバイスの画面共有機能から共有されるビデオストリームおよび／または画像が含まれるが、これらに限定されない。いくつかの実施形態では、ビデオストリームは、撮像デバイス（例えばカメラ－静止画像または動画）によって撮像されているライブキャプチャビデオデータストリームを含む。他の実施形態では、ビデオストリームは、後で使用するためにメモリに保存されていた予め記録されたビデオであってもよい。新たに作成されるビデオパイプラインの画像ソースの１つとして含まれる可能性のある静的コンテンツには、撮像デバイスによって撮像された静止画像が含まれる。一実施形態では、静止画像は、ビデオデータストリームなどの別のタイプの画像ソースの上に重畳されるオーバーレイ画像として提供されるものである。他の実施形態では、静的なコンテンツはアルファチャネルを含む透かしまたは他のタイプの静止画像も含むことができ、それにより、アルファブレンド処理が実行され、静止画像の全てがビデオなどの他の画像ソースの上にあるディスプレイで視認出来ることを可能にする。

【0018】

Ｓ１０２では、１つまたは複数の画像ソースから、最終的に表示用に出力されるビデオストリーム内の特定のレイアウトに従ってこれらのソースを識別して処理するために、レイアウト情報が指定される。ソースは、（ａ）出力（ターゲット）ビデオストリームに配置されるソース画像座標内の領域、（ｂ）ソースが配置される出力（ターゲット）ビデオストリーム内の領域、（ｃ）オーバーレイがソースの１つである場合、どの画像ソースが互いの上に重なってレンダリングされるかを識別する、ソースのターゲットにおけるＺオーダー、（ｄ）ソース画像を、ターゲットビデオフレームに配置／レンダリングする前に、左から右（またはその逆）にフリップし、回転することを指定する、ソースに適用される回転とフリップのステータス、のうちの１つまたは複数を含むレイアウトを指定してもよい。

【0019】

いくつかの実施形態では、ソースのレイアウト情報は、ターゲットフレームに配置されるソース画像のクロップ矩形を記述するソース矩形と、ソースが配置されるべき相対座標（０．０から１．０まで）で、ターゲット画像バッファ内の矩形の位置を記述するターゲット矩形と、ターゲットフレームで見たときのソースの向きとを含む。ソースレイアウトは、ソースレイアウト情報を構成するパラメータに新しい値を生成するいくつかの関数によって変更されることができる。例えば、ソースは、（ａ）時計回りに９０度回転する、（ｂ）反時計回りに９０度回転する、（ｃ）左から右にフリップする、（ｄ）上から下にフリップする、（ｅ）デルタｘおよびデルタｙだけポジションを移動する、（ｆ）ターゲットフレームにおさまる（ソースのアスペクト比を保ちながら、最高の解像度でターゲットフレームにソース全体が表示されるように、必要に応じて上部または側部の境界線に合わせておさまる）ようにリサイズする、（ｇ）ターゲットフレームを満たすようにリサイズする（アスペクト比を保ちながらソースでウィンドウを満たすことで、ターゲットのアスペクト比がソースのアスペクト比と一致しない場合に、ソースの上下が表示されないように、または左右の側部が表示されないようにさせる）、（ｈ）アスペクト比を保ちながらパーセント単位でリサイズする、（ｉ）ソースを元のサイズにリサイズし、ターゲットフレームの中心に配置する、（ｊ）新しいソース矩形に従ってソースをクロップする（ターゲット矩形を適切に更新する）、（ｋ）ソースのクロップを解除する、などのオペレーションを受けてもよいが、これらに限定されるものではない。

【0020】

Ｓｏｕｒｃｅ Ｌａｙｏｕｔクラスは、ソースピクセルからターゲットピクセルへの変換を計算するメカニズムも提供する。これらの変換は、１つの座標空間から別の座標空間への２次元回転および２次元平行移動に相当する２次元変換として表される。２次元変換は次のようにパラメータ化できる。

【数1】

ここにおいて、行列のパラメータは行列Ｄ、Ｓ、Ｒ、およびＦで計算でき、行列Ｄは平行移動行列、

【数2】

Ｓはスケーリング行列、

【数3】

Ｒは回転行列、

【数4】

Ｆはフリップ変換（左から右）、

【数5】

である。スケーリングパラメータがゼロでない場合、変換結果は反転可能であり、以下に記載するように順方向と逆方向のピクセルマッピングを都合が良いように計算してもよい。

【0021】

Ｓ１０３では、アルゴリズムは、すべてのソースストリームを含む出力ビデオストリームを生成し、提供されたレイアウトに従ってビデオストリームをコンパイルして、ターゲットビデオフレームのピクセルマッピングを事前に計算する。Ｓ１０３では、ストリームのコンパイルは、ターゲットピクセルを別々のタイプのターゲットピクセルに分離してもよい。第１のタイプのターゲットピクセルには、純粋に静的なコンテンツからなるピクセルが含まれ、これは、フレーム間で決して変化することのない画像ソースからのピクセルであり、ターゲット画像バッファ（複数可）に１回だけレンダリングされればよく、ビデオの各フレームに対して更新される必要がない。第２のタイプのターゲットピクセルは、動的なコンテンツで構成されたピクセルである。これらのピクセルはフレーム間で変化する可能性があり、フレームごとに呼び出されるレンダリング関数を介して繰り返しレンダリングされる。第３のタイプのターゲットピクセルは、動的なコンテンツと静的なコンテンツの組み合わせである。第３のタイプのターゲットピクセルには、静的なコンテンツ（例えば、透かしやオーバーレイ画像）とアルファブレンド処理された動的なコンテンツ（例えば、動画）を含むピクセルが含まれる。特定の実施形態では、第３のタイプと第２のタイプのターゲットピクセルが一緒に組み合わされる。第４のタイプは、動的および／または静的なコンテンツの１つまたは複数のピクセルとアルファブレンド処理された動的なコンテンツのピクセルを含む。

【0022】

コンパイルされたビデオストリームパイプラインは、リスト内の各ターゲットピクセルについて、ソースピクセル（複数可）に戻るターゲットピクセルのピクセルマッピングを保存する。一実施形態では、マッピングは適切なソース（Ｚオーダーが最も高いソース）の最近傍のピクセルをマッピングする情報を含む。別の実施形態では、マッピングはソースピクセルのターゲットピクセルへのバイリニア補間法に使用される４つの最近傍およびそれらの関連する重み付けをマッピングする情報を含む。別の実施形態では、マッピングは、他の補間方法（例えば、バイキュービック法またはランチョス法）に使用される追加のソースピクセルおよびそれらに関連する重み付けをマッピングするための情報を含むことができる。

【0023】

今やビデオデータストリームが適切なソースからターゲットへのマッピング情報を用いて生成されたので、バッファは、Ｓ１０４で初期化され、表示デバイスでの表示のために出力され通信されるビデオデータストリームの連続するフレームを受信する。いくつかの実施形態では、複数のバッファが使用されてもよく、それにより、１つのバッファが更新されることが出来る一方、以前にレンダリングされたバッファがビデオのコンシューマによって読み取られ得る。１つまたは複数のバッファは、静的なコンテンツに関連するピクセルをレンダリングする（１回のみ）と共にいかなるコンテンツにも関連しない他のすべてのピクセルをクリア（一定の色に設定）する場合もある、バッファ初期化関数を使用して初期化される。

【0024】

Ｓ１０５では、１つまたは複数のバッファ内のビデオフレームが、表示デバイスでの表示のために指定されたレイアウトで動的にレンダリングされる。そうする際に、ビデオ通話のフレームごとに、すべての動的なコンテンツの出力ピクセルをレンダリングするＲｅｎｄｅｒ関数が呼び出される。いくつかの実施形態では、動的なコンテンツと透かしのピクセルのアルファブレンド処理を実行して視認できる透かしを出力するピクセルに２回目のパスを実行するために、２回目のレンダリング操作が実行される。出力ピクセルごとのレンダリングは独立しているため、ターゲットフレーム内の出力ピクセルのレンダリングは、独立したスレッドまたはＧＰＵコアを介して実行されてもよい。

【0025】

ターゲットフレームをレンダリングするとき、ソース画像のバッファは読み取り専用状態でマークされるように取得されてもよい。このようにして、動的な入力バッファは、ソースからレンダリングされた全てのデータが同じフレームから発生していることを保証するために、それらが読まれている間、更新がロックされてもよい。一度読み取りが完了すると、バッファはレンダラによって解放され、バッファの読込回数（要求された読込インスタンスの数）が減算される。情報は同時にイメージバッファに書き込んでもよいが、イメージバッファは読み書きのために別のバッファを有するべきである。（例えば、レンダリングのために）リードアクセスを要求するスレッド／プロセスは、ライトアクセスで保持されてはいないイメージバッファ内の直近の更新されたバッファを取得する。（フレームを更新するために）ライトアクセスを要求するスレッド／プロセスは、現在書き込み中でも読み取り中でもないいずれかのバッファを取得する。

【0026】

図１に関して上述したような例示的なレンダリング動作では、２次元変換がソースレイアウトに基づいて決定され、高度な補間モード（バイリニア補間法など）が使用される場合、各ターゲットピクセルから適切なソースピクセルの最近傍（複数可）へのピクセルマッピングを、ソースピクセルへの適切な重み付けとともに計算することが出来る。いくつかの実施形態では、バイリニア補間法に使用されるべきピクセルに対応する重み付けとともに、各ターゲットピクセルに対して４つの最も近いソースピクセルが見出される。ターゲットピクセルの逆変換マップに最も近いソースピクセルは、「最近傍」である。このピクセルは、バイリニア補間法によって４つの最近傍の加重平均を行う際に、最も高い重みを有する。

【0027】

例えば、３バイトのピクセル［Ｒ，Ｇ，Ｂ］からなるサイズ１００ｘ１００のソース画像（例えば３番目のソース）を考える。オフセット６０００のターゲットピクセルに対応する４つの最近傍のソースピクセルが有するソースバッファのオフセットが［３０，３３，３３０，３３３］で、対応する重みが［０．１，０．３，０．１５，０．４５］である場合、ソース画像内の最近傍のソースピクセルのオフセットは、最も高い重みを持つため、３３３となる。いくつかの実施形態では、レンダリングされる各ターゲットピクセルのために、ターゲットピクセルのオフセット（上記の例では６０００）、最も近い４つのソースピクセルのオフセット（上記の例では［３０，３３，３３０，３３３］）、最も近い４つのソースピクセルの重み（上記の例では［０．１，０．３，０．１５，０．４５］）、およびソース画像のバッファＩＤ（上記の例では３番目のソースになるため３）が保存される。これにより、画像のレンダリング処理速度が向上する。他の実施形態では、最も高く重み付けされた画素のインデックスが保存され、次の行およびそれぞれの近傍ピクセルに対する差が保存される。［ｐ１，ｐ２，ｐ３，ｐ４］を４つのソースピクセルのインデックスとし、ｐ１を最近傍ピクセル、ｐ２をｐ１に隣接する行のピクセル、ｐ３をｐ１次のピクセル（ｐ１と同じ行）、ｐ４をｐ２の次のピクセル（同じ行）とする。その場合、ｄｒ＝ｐ２ーｐ１、ｄｃ＝ｐ３ーｐ１として［ｐ１，ｄｒ，ｄｃ］が格納され得る。さらに、ピクセルインデックスｐ１は相対的に大きな数の可能性がある一方、ｄｒは最大でもピクセルの１行分の＋／－の大きさであるために相対的に小さく、ｄｃの値は＋／－１である。上記の例では、［３２ビットの符号なし整数としての３３３（最も高く重み付けされたピクセル）、－３００（１６ビットの符号付き整数としての行オフセット）、－３（８ビットの符号付き整数として）］を保存してもよく、これらの値を用いてｐ１，ｐ２，ｐ３，ｐ４をコンパクトに保存し効率的に復元することができる。さらに、いくつかの実施形態では、重みを符号なし整数（たとえば８ビット整数）として記憶する。この場合、４バイトが重み付けの保存に使用されてもよい。もちろん、重みの合計は２５６になるべきで、最後の重みは推認できるので、３バイトが使用されてもよい。１つの重みが２５６の場合、ピクセルのマッピングを、重み［２５５，１，０，０］を有する［ｐ１，ｐ１，ｘ，ｙ］に変更することができ、ここで、ｘとｙの値が重要ではない。

【0028】

追加の実施形態は、最近傍（例えば、最も高い重みを担持しているソースピクセル）が最初にリストされることを保証するように、最近傍ピクセルおよび重みのリストを並べ替える。上記の例では、最初と最後のエントリを入れ替えることにより、ソースオフセットを［３３３，３３，３３０，３０］、重みを［０．４５．０．３，０．１５，０．１］に変更する。このように、ソースオフセットリストの最初のピクセルは常に最近傍ピクセルを表すため、レンダリング処理は追加演算なしでバイリニア補間法または最近傍補間法のいずれかを使用することができる。

【0029】

このことにより、レンダリングループは、以下に述べられているように、ソースピクセルのルックアップおよび重み付けがクイックになるように、これによって最適化される。バイリニア補間法を使用しているＮ個のターゲットピクセルへの例示的なレンダリングループを以下に示す。これから、このピクセルレンダリングループ中に発生する演算の総数が最小化され、ほとんどの演算がパイプラインコンパイルの時には事前に計算済みであることが明らかである。このプロセスの間、更新される各出力先ピクセルについて、出力先ピクセルへの参照が、ソースをターゲットピクセルにマッピングするピクセルマッピング情報に関する情報とともに取得される。ピクセルマッピング情報の取得において、ソース情報に基づいて、ピクセルソースの画像バッファへのポインタが取得され、読み出される。ソースピクセルのインデックス［ｐ１，ｐ２，ｐ３，ｐ４］とピクセルの重み［ｗ１，ｗ２，ｗ３，ｗ４］が取り出され、ピクセルの各チャネル（例えば、赤、緑、青、およびアルファチャネル）ごとに、出力先チャネルは、各対応するソースピクセルのインデックスに対応するそのピクセルの重みを乗じた合計に等しく設定される。

【0030】

最近傍補間を使用するＮ個のターゲットピクセルに対する別の例示的なレンダリングループを以下に示す。本実施形態では、このピクセルレンダリングのループにおいて、メモリのインデックス付け以外の演算は生じない。本実施形態では、更新すべき各出力先ピクセルについて、出力先ピクセルへの参照がそのピクセルのマッピング情報とともに取得する。ピクセルソースの画像バッファへのポインタは、ソース情報に基づいて取り出されおよび読み込まれ、ピクセルの各チャネル（例えば、赤、緑、青、およびアルファチャネル）ごとに、出力先のチャネルは、ソースピクセルのインデックスに等しく設定される。

【0031】

上記の２つの例示的なレンダリングループは、事前に計算された同様のｐｉｘｅｌＩｎｆｏ情報を有利に使用する。最初の手法は２つ目の手法よりも演算コストが高いが、４つのピクセルの加重平均によってより多くのレンダリング時間の演算を必要とする、より良い品質のバイリニア補間法を提供する。２つ目の例では、常に最初に列挙されたピクセルオフセットである最近傍ピクセルを使用する。しかし、上述した１つ目または２つ目の例のいずれも、ソースからターゲットピクセルへの事前計算された演算およびマッピングに依存することによって、現在のコンパイルアルゴリズムに対して異なる利点を提供する。

【0032】

上記のアルゴリズムは例として提供されている。ピクセルをマルチバイトオブジェクト（例えば、３２ビットピクセルなど）として扱い、３２ビットを、バイトごと（チャネルごと）ではなく、同時に処理することで、演算をさらに高速化することが出来る。いくつかの実施形態では、上記のアルゴリズムは、単一入力／複数データ命令（ＳＩＭＤ）を使用して具現化される。さらに他の実施形態では、ＧＰＵを介してこれらのタスクを並列に実行する。例示的なアルゴリズムは、４つのソースピクセル（各３２ビット）を１２８ビットレジスタ（各チャネルに１バイト）にｕｉｎｔ８（８ビット符号なし整数）としてロードさせる。

[[r1,g1,b1,a1],[r2,g2,b2,a2],[r3,g3,b3,a3],[r4,g4,b4,a4]]

符号なしバイトは、符号なし１６ビットの符号なし整数に変換され、ｕｎｉｔ１６として新しい２５６ビットレジスタに格納される。３２ビットの重みベクトル［Ｘ，Ｘ，Ｘ，［ｗ１，ｗ２，ｗ３，ｗ４］］は、１２８ビットレジスタにロードされ、重みは以下のように１２８ビットに展開される：

[[0,0,0,w1],[0,0,0,w2],[0,0,0,w3],[0,0,0,w4]]

８ビットの重みを有する各３２ビットの整数は０ｘ０１０１０１０１と乗算され、次のように展開される。

[[w1,w1,w1,w1],[w2,w2,w2,w2],[w3,w3,w3,w3],[w4,w4,w4,w4]]

これはさらにｕｎｉｔ１６として展開され、各ショートは以下のように乗算され、下位１６ビットは次のように保たれる。

[[w1*r1, w1*g1, w1*b1, w1*a1],[w2*r2, ....]=[[wp1],[wp2],[wp3],[wp4]]

その後、６４ビットのワードを水平的に追加する（例えば、４つの連続する６４ビットの整数を合計する）［［ｗｐ１＋ｗｐ２＋ｗｐ３＋ｗｐ４］］。この例示的な実施形態では、４つの最近傍ピクセルは、一連の特殊な１２８ビットおよび２５６ビット命令を介して予め定められた重み付けに従って重み付けされ、これによって、多くの演算が同時に実行される。

【0033】

別の実施形態によれば、上述のように実行されたレンダリング処理は、レンダリング処理が実行されなければならない優先度に基づくレンダリングタスクのリストに従って実行されてもよい。これは図３に示されており、図３は、実行されるレンダリング方法に従って、レンダリングの優先度およびソースレンダリングによって編成されたフレームレンダリングパイプラインを示している。このパイプラインは、ビデオフレームレンダリングをピクセルマッピングタスクの１つまたは複数のリスト（時折同種の場合もある）に分解し、ここで、各ピクセルマッピングタスクは、ターゲット出力フレーム内の１つまたは複数のピクセルをレンダリングするために必要なデータと操作を含む。

【0034】

一例として、ターゲット出力フレームピクセルは、ソース画像からの複数のピクセルの線形な組み合わせであってもよい。使用されるソースピクセルの組み合わせまたは重みは、マッピングタスクのために事前に計算されてもよい。一例として、ターゲットピクセルは、ターゲットピクセルの赤チャネルが対応する４つのソースピクセルの赤チャネルの平均となるように、等しい重み付けを用いて、ソース画像内の４つの最近傍ピクセルの平均としてもよい。この例では、各ターゲットピクセルの重み付けは４分の１である。しかし、一般的には重み付けは様々で不均等であってもよいが、基本的に重み付けの合計は１になる。同様に、重み付けは４つのソースピクセルの緑チャネル、青チャネルに、そして時折アルファチャネルに、適用される。結果は以下の通りである。

ｒ＿ｔａｒｇｅｔ＝（ｒ１＋ｒ２＋ｒ３＋ｒ４）／４
ｇ＿ｔａｒｇｅｔ＝（ｇ１＋ｇ２＋ｇ３＋ｇ４）／４
ｂ＿ｔａｒｇｅｔ＝（ｂ１＋ｂ２＋ｂ３＋ｂ４）／４
α＿ｔａｒｇｅｔ＝（α１＋α２＋α３＋α４）／４

【0035】

このフレームワークに従って、バイリニア補間法は、各ピクセルマッピングの重み付けを適切に選択することによって達成してもよい。同じソースに由来し、同じマッピング手法（例えば、最近傍マッピング、バイリニアマッピング、バイキュービックマッピング、並列実行によって実装されたマッピングなど）に従う全てのターゲットピクセルは、マッピングタスクリストに配置されてもよい。また、マッピングタスクリストのコレクションは、並列プロセッサおよびベクトル化データ処理を実行可能なプロセッサから構成されるシステムが、ビデオレンダリングタスクを効率的に実行することができ得るように、編成されてもよい。同じ優先度のタスクは、一般的に独立したタスクとして形成され、互いに依存しないが、しかし、より高い優先度のタスクに依存する可能性がある。同じ優先度のタスクは互いに独立しているため（例えば、独立した出力ピクセルの各操作および各修正）、これらのタスクは演算ＣＰＵコアまたはＧＰＵコアにわたって分散させることが出来る。例えば、プロセッサに４つのコアがある場合、４つのタスクは全て異なる出力先ピクセル（異なるメモリ位置）を修正しているため、４つのタスクが同時に実行されることができる。

【0036】

さらに、ターゲット出力フレーム内のピクセルをレンダリングするとき、いくつかのピクセルは、複数のソースからのピクセルを組み合わせることができ得る。例えば、１つまたは複数のターゲットピクセルは、複数のソースピクセルのアルファブレンド処理を介して構成されてもよく、これらのソースピクセルは、いくつかの補間スキームに従ってソースピクセルの重み付けを含んでもよい。これらの場合、ピクセルを段階的にレンダリングし、最も低いｚオーダーを伴うソースを起点に、指定されたｚオーダーまたはソースに従って、部分的に透明なソースをより低いｚオーダーのピクセルの「上に」レンダリングすると、しばしば有利な場合がある。この場合、半透明のピクセルを前のレンダリングの上にレンダリングする前に、ピクセルのすべてのより低いｚオーダー部分を最初にレンダリングする仕組みをシステムに提供することが出来る。

【0037】

これは図２に示されており、それによって、第１のリスト２０１がそれに関連付けられた第１の優先レベル２０２を有するように示されている。この例に示すように、このレンダリングタスクリストは、同じレンダリング方法に従って各々がレンダリングされるソース２０３ａ、２０３ｂ、２０３ｃからの画像をそれぞれ含む。ソース２０３ａからの画像はそれに関連付けられた３つのレンダリングタスクを有しており、一方、ソース２０３ｂおよび２０３ｃからの画像はそれに関連付けられた２つと１つのレンダリングタスクを有する。さらに図２は、第２のリスト２１０に関連付けられた第２の優先レベル２１１を有する第２のリスト２１０も示す。この例に示すように、このレンダリングタスクリスト２１０は、同じレンダリング方法に従って各々がレンダリングされるソース２１３ａ、２１３ｂ、２１３ｃからの画像をそれぞれ含む。ソース２１３ａからの画像はそれに関連付けられた３つのレンダリングタスクを有しており、一方、ソース２１３ｂおよび２１３ｃからの画像はそれに関連付けられた２つと１つのレンダリングタスクを有する。上記のタスク割り当て構造では、同種の（方法による）マッピングタスクが優先度および入力ソースに従って編成される。最も高い優先度のレンダリングを用いて、フレームレンダリングの開始が始まる。レンダリングの優先度を定義することによって、システムは、次に最も高い優先度のレンダリングが実行される前に、すべてのより高い優先度のレンダリングが実行されることを保証する。これは、レンダリングされてより高い優先度のレンダリングを介して得られた結果にブレンドされる、若干の透明度（ピクセルのアルファチャネルで指定される）を有するコンテンツのレンダリングを可能とする。選択された優先度に対する各ソースベースのタスクリスト（これらは他のすべてのピクセルマッピングタスクから独立しているため、並行して実行することができる）に関して、決定されたマッピング方法が以前にレンダリングされたコンテンツとブレンドするためにソースのアルファチャネルを使用しているかどうかを伴って、ソースからターゲットへのマッピング方法が決定される。各タスクは、例えば、ＧＰＵのようなスレッド処理または並列処理を介して、独立したターゲットピクセルのマッピングを司るため、ピクセルレンダリングは、アルファブレンド処理の使用およびピクセルレンダリングを並列に実行できるようなマッピング方法に従って実行される。他の実施形態では、ピクセルレンダリングは、ベクトル化処理を使用して、レッド、グリーン、ブルー、およびアルファチャネルを並列に処理することもでき得る。または、それは、ベクトル化処理を介して複数のピクセルを１つの操作で処理してもよい。図２に示した様々なタスクリストを解析及び処理するこのプロセスは、いかなる優先度の低いリストも存在しなくなるまで繰り返される。そのときに、レンダリングは停止する。

【0038】

特定のソースビデオに関連付けられ得る様々なレンダリングタスクに関して、これらのタスクを実装するいくつかの異なる実施形態が存在する。一実施形態では、レンダリングタスクは最近傍補間法であってもよく、タスクは、最も近いソースピクセルマッピングへのソースピクセルオフセットを含む。

【0039】

別の実施形態では、レンダリングタスクはバイリニア補間法であってもよく、これにより、タスクは、ソース画像内の４つの最近傍オフセットと、少なくとも、最初の３つの最近傍の３つの重み（全てのピクセルが一定の合計の重み付けで構成されるように、重みは一般的に合計で固定数になるため、４番目の重みは黙示されている）を含む。重みは浮動小数点数または整数で指定できる。一実施形態では、重みは０から２５６の間の数として与えられ、重みの総和は２５６である。さらに、全ての重みの合計が２５６で最初の重みが重みの最大値である場合に、最初の重みが０になることはないので、いくつかの実施形態は、最も高い重みを有するピクセルを最初に格納することで、２５６という最初の重みが０として格納されることを可能にする。したがって、４つの重みを３２ビット（重みあたり８ビット、重みは４つ）としてメモリ内に格納してもよい。他の実施形態では、４つの重みは４つの１６ビット短整数として格納される。更に他の実施形態では、重みは、ソース画像内の対応する４つの最近傍ピクセルの４つまでの各チャネルについて、０から２５６の間の１６ビットの短整数で提供される。したがって、重みは１６個の１６ビット整数として与えられ、

w = [w0, w0, w0, w0, w1, w1, w1, w1, w2, w2, w2, w2, w3, w3, w3, w3]

合計２５６ビットである。このような方法で重みを保存することはメモリ効率が良くない一方、いくつかの実施形態は、以下でさらに説明するように、この構造を使用してピクセルのリアルタイム処理を最適化する。

【0040】

いくつかの構成では、マッピングデバイスのプロセッサは、シングルインストラクション・マルチプルデータ（ｓｉｎｇｌｅ ｉｎｓｔｒｕｃｔｉｏｎ ｍｕｌｔｉｐｌｅ ｄａｔａ）演算をサポートすることができる。たとえば、２５６ビット演算をサポートするいくつかのプロセッサもある。そのような実施形態の１つは、各ピクセルチャネルを以下の形式の１６ビットのワードとして格納するように、４つのソースピクセルを２５６ビットのレジスタにロードする。

p = [r0, g0, b0, a0, r1, g1, b1, a1, r2, g2, b2, a2, r3, g3, b3, a3] = [q0, q1, q2, q3]

ここでのｑｉは、各ピクセルチャネルをｉ番目のピクセルの１６ビットとして６４ビット連接したものである。各１６ビット単位でｐとｗを乗算すると、以下が生成される。

p*w = [w0*r0, w0*g0, w0*b0, w0*a0, w1*r1, …]

この実施形態では、いかなる重みの最大値も２５６または０ｘ１００（１６進数）であり、各ピクセルチャネルの値は０から２５５（１６進数で０ｘ００から０ｘｆｆ）であるため、乗算の結果が１６ビットの境界をオーバーフローすることはない。ｐ＊ｗを計算し、要素を６４ビットの符号なし整数として総和すると、以下のように決定される。

x = sum_64(p*w) = [w0*r0+w1*r1+w2*r2+w3*r3, w0*g0+w1*g1+w2*g2+w3*g3, …]

ピクセルの重み付けの合計が２５６を超えず、各ピクセルチャネルの値が２５５を超えないため、この６４ビットの符号なし整数の総和は、１６ビットの符号なし整数の４つの合計を効果的に実行する。したがって、加算が１６ビットの境界を操越する可能性は存在しない。上記の合計には、８ビットでシフトされた最終的なピクセルチャネルの値（合計の重みである２５６を乗じたもの）が含まれる。つまり、６４ビットの符号なし整数ｘの１つ目、３つ目、５つ目、７つ目のバイトを選択すると、対象のｒ，ｇ，ｂ，ａチャネルが８ビット単位で返される。大きなＣＰＵレジスタ（この場合は２５６ビット）を使ってピクセルチャネルを同時に処理することで、標準的なプログラミング方法を介してよりも、より効率的に演算を実行することができる。

【0041】

別の実施形態では、レンダリングタスクは、追加のソースピクセルと重みを計算するバイキュービック補間法を含む。例えば、バイキュービック補間法は、バイキュービック補間法を介して出力先ピクセル値を推定するために、１６個の最も近いソースピクセルの位置と１６個の重みを記憶することができる。ソースピクセルのオフセットと重みは、バイリニアピクセルのオフセットと重みが前もって計算された方法と同様の方法で予め計算されてもよい。

【0042】

別の実施形態では、レンダリングタスクはアルファブレンド処理（最近傍、バイリニア、またはバイキュービック）を含む。アルファブレンド処理が使用されることをソースが指定する場合、タスクは最初に補間ピクセルを計算し、その後、より高い優先度でレンダリングされた既存のピクセル値に対してピクセルをアルファブレンド処理するために、アルファチャネルを使用する。

【0043】

他のレンダリングタスクは、一度ピクセル値が計算されると適用されるピクセル画像調整を含む。このような調整では、明るさ、コントラスト、彩度、及び色相を変更することができる。これらの調整は、ピクセルのルックアップテーブル、または、ピクセル値の現在の中間値を考慮して行う結果のピクセル値のリアルタイム演算を介して、一般的に行われる。これらの調整には、各マッピングごとのメモリ要件を有さないが、しかし、共通に使用されるピクセルルックアップテーブルやピクセル値変換パラメータのストレージが一般的に要求される。ピクセル調整は、ピクセル調整がなされる前に全ての前提条件となるピクセル値の演算が既に実行されているようにするために、一般的に最も低い優先度で行われる。

【0044】

別のレンダリングタスクは、静的なコンテンツのレンダリングであり、これによって、時として、レンダリングされたピクセルは、例えば背景画像のような静的なコンテンツから生成されることがある。ターゲットフレームピクセルが静的なコンテンツ（例えば、フレーム間で変化しない入力など）にのみ依存する場合、これらのピクセルは出力バッファ内で一度のみレンダリングされてもよい。これらのピクセルは毎フレーム更新する必要はない。ただし、画像調整が適用された場合は、新しいピクチャ設定に従って、静的な入力のマッピングを更新する必要がある。したがって、レンダリングタスクは、さらに出力フレームに問い合わせて（内部フレームフラグに従って）、フレームの静的なコンテンツが最新かどうかを判断してもよい。そうでないときは、フレームがダーティ（ｄｉｒｔｙ）または「古い」とマークされると、レンダリングタスクは静的なコンテンツを更新する。これが適切に作動するためには、処理パイプラインは、レンダリングプロセスが任意の与えられたフレームについて静的なコンテンツを再描画する必要があるかどうかを判断できるようにするために、内部バッファをダーティー（ｄｉｒｔｙ）としてマークするタイミングを出力フレームに伝えなければならない。これは、それぞれの静止画像情報に関連付けられた期限切れ情報を提供することによって実行され、最終的にレンダリングされるものが、時刻と画像ソースの観点から適切であることを保証する。

【0045】

図３は、上述した画像処理アルゴリズムを実行し、上述した本開示を実施する際に使用することができる装置３００を表す例示的なハードウェアを示す。本装置は、ＣＰＵ３０１、ＲＡＭ３０２、ＲＯＭ３０３、入力部３０４、外部インタフェース３０５、及び出力部３０６を含む。ＣＰＵ３０１は、ＲＡＭ３０２またはＲＯＭ３０３に記憶されたコンピュータプログラム（ＣＰＵによって実行可能な１つまたは複数の一連の記憶された命令）およびデータを使用して装置３００を制御する。ここで、本装置は、ＣＰＵ３０１とは異なる１つまたは複数の専用ハードウェアまたはグラフィック処理装置（ＧＰＵ）を含んでもよく、ＧＰＵまたは専用ハードウェアは、ＣＰＵ３０１による処理の一部を実行してもよい。専用ハードウェアの例としては、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル・ゲートアレイ（ＦＰＧＡ）、デジタルシグナルプロセッサ（ＤＳＰ）などが存在する。ＲＡＭ３０２は、ＲＯＭから読み出されたコンピュータプログラムまたはデータ、外部インタフェース３０５を介して外部から供給されたデータなどを一時的に記憶する。本明細書で説明するアプリケーションでは、外部インタフェース３０５は、複数の画像ソースから画像データの形式で情報を受信する。一実施形態では、撮像デバイス３０７が特定の画像キャプチャ領域に従って画像データをキャプチャし、キャプチャされた画像を外部インタフェース３０５を介して装置３００に提供する。撮像デバイス３０７は一般的に記載されているが、撮像デバイスは、リアルタイムのビデオ画像（および音声）または静止画像、またはその両方をキャプチャするように構成されたカメラであることが理解される。別の実施形態では、画像ソース３０８が設けられ、装置３００は外部インタフェース３０５を介して、画像ソース３０８から予め記録された画像データを取得することができる。例えば、画像ソースは、そこに保存した予め記録された画像データを有する外部ストレージであってもよい。別の例では、画像ソース３０８は、他のコンピュータなどの外部装置で実行されている特定のアプリケーションからの出力であってもよく、そのコンピュータのユーザは、他のユーザに共有するために、ユーザのコンピュータに表示されているウィンドウまたはユーザインタフェースを選択した。外部インタフェース３０５は、ＰＣ、スマートフォン、カメラなどの外部デバイスと通信を行う。ＲＯＭ３０３は、変更される必要がなく、装置の基本動作を制御することが可能な、コンピュータプログラムおよびデータを記憶する。入力部３０４は、例えば、ジョイスティック、ジョグダイヤル、タッチパネル、キーボード、マウスなどで構成され、ユーザの操作を受信し、ＣＰＵ３０１に様々な指示を入力する。外部デバイスとの通信は、ローカルエリアネットワーク（ＬＡＮ）ケーブル、シリアルデジタルインタフェース（ＳＤＩ）ケーブル、ＷＩＦＩ接続などを用いて有線で実行されてもよいし、アンテナを介して無線で実行されてもよい。出力部３０６は、例えば、情報の表示が表示デバイス３０９に提供されるようにしてそこにグラフィカルユーザインタフェース（ＧＵＩ）を表示する表示部から構成される。出力部３０６には、さらにスピーカなどの音声出力部も含まれる。出力部３０６はまた、ネットワーク接続を含んでもよく、それによって、図１および図２で説明した映像処理実施形態から生成されたビデオストリームが遠隔システムに送信される。

【0046】

本開示の範囲には、１つまたは複数のプロセッサによって実行された時、１つまたは複数のプロセッサに、本明細書に記載された本発明の１つまたは複数の実施形態を実行させる命令を記憶する、非一時的なコンピュータ可読媒体が含まれる。コンピュータ可読媒体の例には、ハードディスク、フロッピーディスク、光磁気ディスク（ＭＯ）、コンパクトディスク・リードオンリーメモリ（ＣＤ－ＲＯＭ）、コンパクトディスク・レコーダブル（ＣＤーＲ）、ＣＤ－リライタブル（ＣＤ－ＲＷ）、デジタル多用途ディスクＲＯＭ（ＤＶＤ－ＲＯＭ）、ＤＶＤ－ＲＡＭ、ＤＶＤ－ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性メモリカード、及びＲＯＭが含まれる。コンピュータが実行可能な命令を、ネットワークを介してダウンロードされるようにすることで、コンピュータ可読記録媒体に供給することもできる。

【0047】

本発明の１つまたは複数の態様を記載する本開示の文脈における（特に以下の特許請求の範囲の文脈における）「ａ」および「ａｎ」および「ｔｈｅ」および類似の言及物の使用は、本明細書において別段に示されたり、文脈によって文脈的に明らかに矛盾したりする場合を除き、単数形および複数形の両方をカバーするものと解釈される。用語「～を有する（ｈａｖｉｎｇ）」、「～を含む、～が含まれる（ｃｏｍｐｒｉｓｉｎｇ、ｉｎｃｌｕｄｉｎｇ、ｃｏｎｔａｉｎｉｎｇ）」は、特に別段に断りのない限り、オープンエンドの用語（すなわち、「～を含むが、～に限定されない」という意味）として解釈される。本明細書における値の範囲の記載は、本明細書において別段に示されない限り、単に、範囲内に入る各個別の値を個別に参照するための簡単な方法としての役割を果たすことを意図したものであり、各個別の値は、本明細書に個別に記載されているかのように本明細書に組み込まれる。本明細書に記載されるすべての方法は、本明細書において別段に示されたり、文脈によって別段に明らかに矛盾したりする場合を除き、任意の適切な順序で実施することができる。本明細書で提供されたいずれかおよびすべての例、または例示的な文言（例えば、「など」）の使用は、単に本明細書で開示される主題をより良く明瞭にすることを意図しており、別段の請求がない限り、本開示に由来するあらゆる発明の範囲を限定するものではない。明細書のいかなる文言も、何らかの非請求要素が必須であるように示すものと解釈されるべきではない。

【0048】

本開示は、様々な実施形態の形態で組み込むことができ、本明細書で記載するのはそのうちの少量にすぎないことが理解されよう。これらの実施形態のバリエーションは、上記の説明を読めば当業者にとって明らかになるであろう。従って、本開示およびそこから導かれるあらゆる発明は、適用可能な法律により許可されるように、本明細書に添付された特許請求の範囲に記載された主題のすべての変更および均等物を含む。さらに、本明細書に別段に示されたり、文脈によって別段に明らかに矛盾したりする場合を除き、上述した要素の全ての可能なバリエーションにおける上述した要素のあらゆる組み合わせは、本開示に含まれる。

【図1】

【図2】

【図3】

【国際調査報告】