知財求人 - 知財ポータルサイト「IP Force」
▶ コーヒレント・ロジックス・インコーポレーテッドの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-01-10
(45)【発行日】2023-01-18
(54)【発明の名称】任意の世界ビューの生成
(51)【国際特許分類】
G06T 15/20 20110101AFI20230111BHJP
G06T 19/00 20110101ALI20230111BHJP
H04N 7/18 20060101ALI20230111BHJP
【ＦＩ】
G06T15/20 500
G06T19/00 A
H04N7/18 J
【請求項の数】
18
(21)【出願番号】P 2021506937
(86)(22)【出願日】2019-09-25
(65)【公表番号】
(43)【公表日】2021-12-16
(86)【国際出願番号】 US2019052926
(87)【国際公開番号】W WO2020068960
(87)【国際公開日】2020-04-02
【審査請求日】2021-02-15
(31)【優先権主張番号】62/737,050
(32)【優先日】2018-09-26
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】505000815
【氏名又は名称】コーヒレント・ロジックス・インコーポレーテッド
(74)【代理人】
【識別番号】100098394
【弁理士】
【氏名又は名称】山川 茂樹
(74)【代理人】
【識別番号】100064621
【弁理士】
【氏名又は名称】山川 政樹
(72)【発明者】
【氏名】ブランズ，マイケル・ダブリュ
(72)【発明者】
【氏名】ハント，マーティン・エイ
(72)【発明者】
【氏名】シッダヤ，マンジュナート・エイチ
【審査官】村松 貴士
(56)【参考文献】
【文献】特開２０１７－０６８８２６（ＪＰ，Ａ）
【文献】国際公開第２０１８／１０２９９０（ＷＯ，Ａ１）
【文献】米国特許出願公開第２０１４／０２７８０６５（ＵＳ，Ａ１）
【文献】特開２０１２－２２７９１３（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１７／０１９５５６４（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｔ １／００ － １９／２０
Ｈ０４Ｎ ７／１８
(57)【特許請求の範囲】
【請求項1】
出力画像を描画するための方法であって、異なる第１の場所から各入力画像が得られる複数の前記入力画像を受信するステップと、
前記出力画像を描画するための、第２の場所を備えるビュー明細事項を受信するステップと、
前記複数の入力画像および前記ビュー明細事項に少なくとも一部は基づき前記出力画像を投影面に描画するステップであって、前記出力画像は、前記第２の場所から見たときの領域の画像を備え、前記第２の場所は、前記第１の場所の各々と異なり、前記複数の入力画像および前記ビュー明細事項に少なくとも一部は基づき前記出力画像を描画する前記ステップは、
前記出力画像の複数の画素ブロックごとに、
それぞれの前記画素ブロックの外周に沿った複数の画素と前記入力画像の１つまたは複数の各々の対応する複数の画素との間のマッピングを決定するステップを備えるステップと、
出力画像を表示装置上に表示するステップと
を備えるステップと、
表示装置上に前記出力画像を表示するステップと
を備え、
前記複数の入力画像および前記ビュー明細事項に少なくとも一部は基づき前記出力画像を描画する前記ステップは、
前記出力画像の複数の画素ブロックごとに、
前記１つまたは複数の入力画像ごとに、
前記入力画像の前記対応する画素の外周内部に配置された画素から前記出力画像内のそれぞれの画素への投影マッピングを遂行するステップ
をさらに備え、
前記投影マッピングは、それぞれの前記画素ブロックの前記外周に沿った前記複数の画素と前記１つまたは複数の入力画像の前記対応する複数の画素との間のマッピングに少なくとも一部は基づき、
前記複数の画素ブロックの各々のサイズは、前記投影マッピングにより導入される画像歪みの程度と、前記出力画像を描画する前記ステップに関連する計算資源とを均衡させるように選択され、
より小さな前記画素ブロックのサイズは、前記画像歪みの程度を低減し、一方で、所望の待ち時間で前記出力画像を描画するためにより多数の並列の計算資源を必要とする、
方法。
【請求項2】
連続したそれぞれの前記複数の入力画像に基づき、リアル・タイム・ビデオを作り出すために前記表示装置上にリアルタイムで表示される連続した前記出力画像を反復して描画するステップをさらに備える、請求項１に記載の方法。
【請求項3】
前記投影面を決定するステップをさらに備え、
前記複数の入力画像に少なくとも一部は基づき前記出力画像を描画する前記ステップは、前記投影面の上に前記複数の入力画像の画素をマッピングするステップと、前記出力画像の画素に前記投影面上の場所をマッピングするステップとを備える、
請求項１に記載の方法。
【請求項4】
前記第１の場所を取り囲む部位に関係がある測距情報を決定するステップをさらに備え、前記投影面を決定する前記ステップは、前記測距情報に少なくとも一部は基づき遂行される、
請求項３に記載の方法。
【請求項5】
前記第１の場所は、車両上の場所であり、前記投影面は、前記車両を取り囲む水平部分、および前記水平部分を取り巻く垂直部分を備える、請求項３に記載の方法。
【請求項6】
前記車両の現在の速度に少なくとも一部は基づき前記水平部分のサイズを決定するステップをさらに備え、
前記車両のより速い現在の速度は、前記車両のより遅い現在の速度よりも広い水平部分を決定する、
請求項５に記載の方法。
【請求項7】
前記投影面の前記水平部分は、前記車両を取り囲む楕円状ディスクを備え、前記投影面の前記垂直部分は、前記楕円状ディスクを取り巻く楕円状円筒を備え、
前記投影面は、前記楕円状ディスクおよび前記楕円状円筒を滑らかに連結する中間領域をさらに備える、
請求項５に記載の方法。
【請求項8】
前記楕円状ディスクの長軸は、前記車両の前方から前記車両の後方に伸び、前記楕円状ディスクの短軸は、前記車両の左側から前記車両の右側に伸びる、
請求項７に記載の方法。
【請求項9】
前記第１の場所を取り囲む環境の幾何学的配置を決定するステップをさらに備え、
前記投影面は、前記第１の場所を取り囲む前記環境を近似するＢ－スプライン表面を備える、
請求項１に記載の方法。
【請求項10】
前記それぞれの画素ブロックの前記外周に沿った前記複数の画素は、前記それぞれの画素ブロックの４隅の画素を備える、請求項１に記載の方法。
【請求項11】
１つまたは複数の第２のビュー明細事項を指定するユーザ入力を受信するステップと、前記１つまたは複数の第２のビュー明細事項および前記複数の入力画像に少なくとも一部は基づき１つまたは複数の第２の出力画像を描画するステップと、
前記表示装置上に前記１つまたは複数の第２の出力画像を表示するステップと
をさらに備える、請求項１に記載の方法。
【請求項12】
前記出力画像の少なくとも１つの部分は、前記複数の入力画像のうち２つ以上の入力画像から供給され、前記出力画像の前記少なくとも１つの部分を描画する前記ステップは、前記複数の入力画像のうち前記２つ以上の入力画像からの寄与を融合するステップを備える、請求項１に記載の方法。
【請求項13】
融合する前記ステップは、前記出力画像の前記少なくとも１つの部分の投影場所に前記２つ以上の入力画像の前記第１の場所が近いことに少なくとも一部は基づき重み付けされる、請求項１２に記載の方法。
【請求項14】
前記融合するステップは、前記２つ以上の入力画像の間にある照明の不一致を補正する、請求項１２に記載の方法。
【請求項15】
前記ビュー明細事項は、前記第２の場所にある原点から測定した方位角、
前記第２の場所にある前記原点から測定した極角、
視界、
投影面深度、
１つまたは複数の投影面パラメータ、
画素解像度、および
融合幅
のうち１つまたは複数をさらに備える、請求項１に記載の方法。
【請求項16】
非一時的コンピュータ可読記憶媒体であって、１つまたは複数のプロセッサにより実行されたとき、コンピューティングシステムに、異なる第１の場所から各入力画像が得られる複数の前記入力画像を受信するステップと、
出力画像を描画するための、第２の場所を備えるビュー明細事項を受信するステップと、
投影面を決定するステップと、
前記複数の入力画像、前記ビュー明細事項、および前記投影面に少なくとも一部は基づき出力画像を描画するステップと
を実行させるプログラム命令を備え、
前記出力画像は、前記第２の場所から見たときの領域の画像を備え、前記第２の場所は、前記第１の場所の各々と異なり、前記複数の入力画像および前記ビュー明細事項に少なくとも一部は基づき前記出力画像を描画する前記ステップは、
前記出力画像の複数の画素ブロックごとに、
それぞれの前記画素ブロックの外周に沿った複数の画素と前記入力画像の１つまたは複数の各々の対応する複数の画素との間のマッピングを決定するステップ
を備え、
前記複数の入力画像および前記ビュー明細事項に少なくとも一部は基づき前記出力画像を描画する前記ステップは、
前記出力画像の複数の画素ブロックごとに、
前記１つまたは複数の入力画像ごとに、
前記入力画像の前記対応する画素の外周内部に配置された画素から前記出力画像内のそれぞれの画素への投影マッピングを遂行するステップ
をさらに備え、
前記投影マッピングは、前記それぞれの画素ブロックの前記外周に沿った前記複数の画素と前記１つまたは複数の入力画像の前記対応する複数の画素との間のマッピングに少なくとも一部は基づき、
前記複数の画素ブロックの各々のサイズは、前記投影マッピングにより導入される画像歪みの程度と、前記出力画像を描画する前記ステップに関連する計算資源とを均衡させるように選択され、
より小さな前記画素ブロックのサイズは、前記画像歪みの程度を低減し、一方で、所望の待ち時間で前記出力画像を描画するためにより多数の並列の計算資源を必要とする、
非一時的コンピュータ可読記憶媒体。
【請求項17】
前記プログラム命令は、前記１つまたは複数のプロセッサにより前記コンピューティングシステムに、前記第１の場所を取り囲む環境の幾何学的配置を決定するステップを実行させる
ようにさらに実行可能であり、
前記投影面は、前記第１の場所を取り囲む前記環境を近似するＢ－スプライン表面を備える、
請求項１６に記載の非一時的コンピュータ可読記憶媒体。
【請求項18】
コンピューティングシステムであって、１つまたは複数のメモリと、
前記１つまたは複数のメモリに結合した１つまたは複数のプロセッサと
を備え、
前記１つまたは複数のメモリは、前記１つまたは複数のプロセッサにより実行されたとき、前記コンピューティングシステムに、
異なる第１の場所から各入力画像が得られる複数の前記入力画像を受信するステップと、
出力画像を描画するための、第２の場所を備えるビュー明細事項を受信するステップと、
前記複数の入力画像および前記ビュー明細事項に少なくとも一部は基づき前記出力画像を描画するステップと
を実行させるプログラム命令を記憶し、
前記出力画像は、前記第２の場所から見たときの領域の画像を備え、前記第２の場所は、前記第１の場所の各々と異なり、
前記出力画像を描画するために、前記コンピューティングシステムは、前記出力画像の複数の画素ブロックごとに、
それぞれの前記画素ブロックの外周に沿った複数の画素と前記入力画像の１つまたは複数の各々の対応する複数の画素との間のマッピングを決定し、
前記１つまたは複数の入力画像ごとに、
前記入力画像の前記対応する画素の外周内部に配置された画素から前記出力画像内のそれぞれの画素への投影マッピングを遂行する
ように構成され、
前記投影マッピングは、それぞれの前記画素ブロックの前記外周に沿った前記複数の画素と前記１つまたは複数の入力画像の前記対応する複数の画素との間のマッピングに少なくとも一部は基づき、
前記複数の画素ブロックの各々のサイズは、前記投影マッピングにより導入される画像歪みの程度と、前記出力画像を描画する前記ステップに関連する計算資源とを均衡させるように選択され、
より小さな前記画素ブロックのサイズは、前記画像歪みの程度を低減し、一方で、所望の待ち時間で前記出力画像を描画するためにより多数の並列の計算資源を必要とする、
コンピューティングシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の分野は、一般に透視図生成および画像描画に関する。
【背景技術】
【0002】
多くのタイプの車両は、運転、ナビゲーション、または他のタスクを支援するために、１つまたは複数のカメラを利用して、車両の周りの画像および／またはビデオを取り込む、表示する、および／または記録する。追加で、他の可能性の中でも監視、セキュリティ、または娯楽のために、多様な実用的用途で広範囲にカメラを採用して、特定の環境の画像および／またはビデオを記録する。しかしながら、実際的な理由で、画像またはビデオを記録することが望ましい特定の場所にカメラを設置することは困難であることがある、または法外な費用がかかることがある。したがって、本分野で改善が望まれる。
【発明の概要】
【発明が解決しようとする課題】
【0003】
複数の入力画像から出力画像を描画するための、任意の世界ビューシステムおよび方法のさまざまな実施形態について記述し、この場合、出力画像は、入力画像を得た複数の場所の各々と異なる場所に対応する透視図から得られる。
【課題を解決するための手段】
【0004】
いくつかの実施形態では、複数の入力画像を受信し、各入力画像を異なる第１の場所から得る。出力画像を描画するためのビュー明細事項を受信してもよく、ビュー明細事項は、少なくとも第２の場所を含む。いくつかの実施形態では、世界座標フレームで３つの空間座標（たとえば（ｘ，ｙ，ｚ））により第１の場所および第２の場所をそれぞれ指定してよい。ビュー明細事項は、方位角および／または極角を含む姿勢明細事項、視界（たとえば、ズームまたは拡大）、投影面深度、１つまたは複数の投影面パラメータ、画素解像度、および融合幅のうち１つまたは複数をさらに含んでよい。
【0005】
第２の場所は、第１の場所の各々と異なってよい。複数の入力画像およびビュー明細事項に少なくとも一部は基づき出力画像を描画してよく、出力画像は、第２の場所から見たときの領域の画像を含んでよい。たとえば、第２の場所は、出力画像を描画するために使用する「仮想の場所」であってよく、たとえカメラは「仮想の場所」に配置されなくともよい。
【0006】
いくつかの実施形態では、投影面を決定し、複数の入力画像に少なくとも一部は基づき出力画像を描画するステップは、投影面の上に複数の入力画像の画素をマッピングするステップ、および出力画像の画素に投影面上の場所をマッピングするステップを含む。複数の入力画像を取得するために使用するカメラの周囲を近似するように投影面を決定してよい。
【0007】
いくつかの実施形態では、複数の入力画像およびビュー明細事項に少なくとも一部は基づき出力画像を描画するステップは、出力画像の複数の画素ブロックごとに、それぞれの画素ブロックの外周に沿った複数の画素と入力画像の１つまたは複数の各々の対応する複数の画素との間のマッピングを決定するステップを含む。たとえば、それぞれの画素ブロックの外周に沿った複数の画素は、正方形の画素ブロックの４隅の画素であってよい。１つまたは複数の入力画像ごとに、および出力画像の複数の画素ブロックごとに、入力画像の対応する画素の外周の内部に配置された画素から出力画像内のそれぞれの画素への投影マッピングを遂行してよく、前記投影マッピングは、それぞれの画素ブロックの外周に沿った複数の画素と１つまたは複数の入力画像の対応する複数の画素との間のマッピングに少なくとも一部は基づいてよい。
【0008】
出力画像を表示装置上に表示してよい。いくつかの実施形態では、連続したそれぞれの複数の入力画像に基づき、連続した出力画像を反復して描画してよく、連続した出力画像を表示装置上にリアルタイムで表示して、リアル・タイム・ビデオを作り出す。出力画像および／または出力ビデオは、（たとえば、さらに処理するために）別のアプリケーションへの入力の役割を果たしてよく、および／または出力を記憶媒体に記憶してよい。
【0009】
この要約は、本文書で記述する主題のいくつかについて概要を提供することを意図したものである。したがって、上述の特徴は実施例でしかなく、本明細書で記述する主題の範囲または精神を狭くすると解釈されるべきでは決してないことが認識されよう。本明細書で説明する主題の他の特徴、様態、および利点は、以下の発明を実施するための形態、図面、および特許請求の範囲から明らかになるであろう。
【0010】
以下の図面と併せて好ましい実施形態についての以下の詳細な記述を考慮するとき、本発明のよりよい理解を得ることがある。
【図面の簡単な説明】
【0011】
【図1】いくつかの実施形態による先進運転支援システム（Ａｄｖａｎｃｅｄ Ｄｒｉｖｅｒ Ａｓｓｉｓｔａｎｃｅ Ｓｙｓｔｅｍ、ＡＤＡＳ）プラットフォームの概略図である。
【図2A】いくつかの実施形態による、車両に取り付けた４つのカメラから得た未加工のカメラデータの例示である。
【図3】いくつかの実施形態による、複数の入力画像から出力画像を描画するための方法を例示する流れ図である。
【図4】いくつかの実施形態による、投影面を決定するための方法を例示する流れ図である。
【図5】いくつかの実施形態による、ブロックごとの出力画像描画を遂行するための方法を例示する流れ図である。
【図6】いくつかの実施形態による、複数の入力画像から得られる出力画像を較正および描画するステップのための、高水準のデータの流れを例示する概略図である。
【図7】いくつかの実施形態による、等角ピンホールカメラ投影モデルの例示である。
【図8】いくつかの実施形態による、ピンホール・カメラ・モデルを使用する、未加工の等角（魚眼）レンズ画像および再投影画像の例示である。
【図9】いくつかの実施形態による、世界座標フレームでの物点から像点への投影の例示である。
【図10】いくつかの実施形態による、ビュー像点からソース画像への再投影の例示である。
【図11】いくつかの実施形態による、基平面上での物点の深さの例示である。
【図12】いくつかの実施形態による、乗用車の周りの円筒状投影面モデルの例示である。
【図13】いくつかの実施形態による、２つの魚眼ソース画像にマッピングしたビュー画像ブロックのグリッドを例示する。
【図14】いくつかの実施形態による、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔｉｆｉｃａｔｉｏｎ）ファイルフォーマットでのＢｌｏｃｋＩｎｆｏに関するコード構造を例示する擬似コードである。
【図15】いくつかの実施形態による、Ｃ／Ｃ＋＋構造としてＢｌｏｃｋＩｎｆｏに関するコード構造を例示する擬似コードである。
【図16】いくつかの実施形態による、ＪＳＯＮファイルフォーマットでのＣａｍＤａｔａに関するコード構造を例示する擬似コードである。
【図17】いくつかの実施形態による、世界座標フレームの公称配向の下向きの例示である。
【図18】いくつかの実施形態による、ＪＳＯＮファイルフォーマットでのＶｉｅｗＳｐｅｃに関するコード構造を例示する擬似コードである。
【図19】いくつかの実施形態による、乗用車上のカメラに対する方位角および高度角の例示である。
【図20】いくつかの実施形態による、カメラ較正処理から得られる第１の検証画像を例示する。
【図21】いくつかの実施形態による、カメラ較正処理から得られる第２の検証画像を例示する。
【図22】いくつかの実施形態による、３つのソースカメラから描画した後方ビュー出力画像である。
【図23】いくつかの実施形態による、２チップ設計のための資源割当てを例示する並列処理ハードウェア図である。
【図24】いくつかの実施形態による、チップ３のための資源割当てを例示する並列処理ハードウェア図である。
【図25】いくつかの実施形態による３チップ設計に関する概略のデータ流れ図である。
【図26】いくつかの実施形態による、チップ１およびチップ２に関する概略のデータ流れ図である。
【図27】いくつかの実施形態による、デモザイク（ｄｅｍｏｓａｉｃ）・グループ・セルの内部構造の概略図である。
【図28】いくつかの実施形態による、チップ３に関する概略のデータ流れ図である。
【図29】いくつかの実施形態による、測光アラインメントに関する概略のデータ流れ図である。
【図30】いくつかの実施形態による、マルチ・プロセッサ・システム（ｍｕｌｔｉ－ｐｒｏｃｅｓｓｏｒ ｓｙｓｔｅｍ、ＭＰＳ）の一実施形態を例示する構成図である。
【図31】いくつかの実施形態による、ＭＰＳ接続方式の一実施形態を例示する構成図である。
【図32】いくつかの実施形態による、ＭＰＳ機構の一実施形態を例示するより詳細な図である。
【発明を実施するための形態】
【0012】
本発明は、さまざまな修正形態および代替形態が可能であるが、それらの具体的実施形態について、図面で例として示し、本明細書で詳細に記述する。しかしながら、それらの実施形態に対する図面および詳細な記述は、開示する特定の形態に本発明を限定することを意図するものではなく、それどころか、本発明は、添付の特許請求の範囲により規定されるような本発明の精神および範囲に入るすべての修正形態、均等物、および代替形態を包含することが意図されることを理解されたい。
【0013】
参照による組込み
以下の参照事項は、あたかも本明細書にあらゆる点で完全に示されているかのように、全体が参照により本明細書に組み入れられる。
以下の参照事項は、あたかも本明細書にあらゆる点で完全に示されているかのように、全体が参照により本明細書に組み入れられる。
【0014】
用語
以下は、本出願で使用する用語の解説である。
以下は、本出願で使用する用語の解説である。
【0015】
記憶媒体－さまざまなタイプのメモリ装置または記憶装置のいずれか。用語「記憶媒体」は、インストール媒体、たとえば、ＣＤ－ＲＯＭ、フロッピーディスク、もしくはテープ装置；ＤＲＡＭ、ＤＤＲ ＲＡＭ、ＳＲＡＭ、ＥＤＯ ＲＡＭ、Ｒａｍｂｕｓ ＲＡＭなどのようなコンピュータ・システム・メモリもしくはランダム・アクセス・メモリ；またはハードドライブなどの磁気媒体、光学記憶装置、もしくはＲＯＭ、ＥＰＲＯＭ，フラッシュなどのような不揮発性メモリを含むことが意図される。記憶媒体は、同様に他のタイプのメモリも、またはそれらの組合せを備えてよい。それに加えて、記憶媒体は、プログラムを実行する第１のコンピュータ内に配置されてよい、および／またはインターネットなどのネットワークを介して第１のコンピュータに接続する第２の異なるコンピュータ内に配置されてよい。第２の異なるコンピュータ内に配置される実例では、第２のコンピュータは、実行するために第１のコンピュータにプログラム命令を提供してもよい。用語「記憶媒体」は、異なる場所に、たとえば、ネットワークを介して接続される異なるコンピュータに常駐してよい２つ以上の記憶媒体を含んでよい。
【0016】
キャリア媒体－上述のような記憶媒体、ならびにバス、ネットワーク、および／または電気信号もしくは光信号などの信号を伝達する他の物理的伝送媒体などの物理的伝送媒体。
【0017】
プログラム可能ハードウェア要素－プログラム可能な相互接続または有線接続された相互接続を介して接続された多数のプログラム可能機能ブロックを備えるさまざまなハードウェア機器を含む。例は、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ），ＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）、ＦＰＯＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｏｂｊｅｃｔ Ａｒｒａｙ）、およびＣＰＬＤ（Ｃｏｍｐｌｅｘ ＰＬＤ）を含む。プログラム可能能機能ブロックは、微細なもの（組合せ論理またはルック・アップ・テーブル）から粗大なもの（算術論理演算装置またはプロセッサコア）までの範囲に及んでよい。プログラム可能ハードウェア要素はまた、「再構成可能論理」とも呼ばれることがある。
【0018】
特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ、ＡＳＩＣ）－この用語は、その通常の意味の広さを完全に有することが意図される。ＡＳＩＣは、構成単位としてプログラム可能プロセッサコアを含有してよいが、用語ＡＳＩＣは、汎用プログラム可能装置というよりはむしろ特定用途のためにカスタマイズされた集積回路を含むことが意図される。携帯電話プロセッサ、ＭＰ３プレーヤチップ、および多くの他の単一機能ＩＣは、ＡＳＩＣの例である。ＡＳＩＣは、通常はＶｅｒｉｌｏｇまたはＶＨＤＬなどのハードウェア記述言語で記述される。
【0019】
プログラム－用語「プログラム」は、その通常の意味の広さを完全に有することが意図される。用語「プログラム」は、１）メモリに記憶されてよい、プロセッサにより実行可能なソフトウェアプログラム、または２）プログラム可能ハードウェア要素またはＡＳＩＣを構成するために使用可能なハードウェア構成プログラムを含む。
【0020】
ソフトウェアプログラム－用語「ソフトウェアプログラム」は、その通常の意味の広さを完全に有することが意図され、記憶媒体に記憶して、プロセッサにより実行してよい、任意のタイプのプログラム命令、コード、スクリプト、および／もしくはデータ、またはそれらの組合せを含む。代表的ソフトウェアプログラムは、テキストベースのプログラミング言語、たとえば、Ｃ、Ｃ＋＋、ＰＡＳＣＡＬ、ＦＯＲＴＲＡＮ、ＣＯＢＯＬ、ＪＡＶＡ、アセンブラ言語などのような命令型言語もしくは手続き型言語で書かれたプログラム；グラフィカルプログラム（グラフィカルプログラミング言語で書かれたプログラム）；アセンブラ言語プログラム；機械語にコンパイルされたプログラム；スクリプト；および他のタイプの実行可能ソフトウェアを含む。ソフトウェアプログラムは、何らかの手法で相互運用する２つ以上のソフトウェアプログラムを備えてよい。
【0021】
ハードウェア構成プログラム－プログラム可能ハードウェア要素またはＡＳＩＣをプログラムまたは構成するために使用することができるネットリストまたはビットファイルなどのプログラム。
【0022】
コンピュータシステム－パーソナル・コンピュータ・システム（ＰＣ）、メインフレーム・コンピュータ・システム、ワークステーション、ネット家電、インターネット家電、携帯情報端末（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ、ＰＤＡ）、グリッド・コンピューティング・システム、もしくは他の機器、または機器の任意の組合せを含む、さまざまなタイプのコンピューティングシステムまたは処理システムのいずれか。一般に、用語「コンピュータシステム」を広く規定して、記憶媒体から得られる命令を実行する少なくとも１つのプロセッサを有する任意の機器（または機器の組合せ）を包含することができる。
【0023】
自動的に－ユーザ入力が動作または活動を直接指定または遂行することなく、コンピュータシステム（たとえば、コンピュータシステムが実行するソフトウェア）または機器（回路、プログラム可能ハードウェア要素、ＡＳＩＣなど）により遂行される動作または活動を指す。したがって、用語「自動的に」は、ユーザが動作を直接遂行するための入力を提供する、ユーザが動作を手動で遂行する、または指定することとは対照をなす。自動手順は、ユーザが提供する入力により開始されてよいが、「自動的に」遂行される後続の動作は、ユーザにより指定されない、すなわち、「手動で」遂行されず、この場合、ユーザは、遂行すべき各活動を指定する。たとえば、ユーザが各フィールドを選択し、情報を指定する入力を提供することにより（たとえば、情報をタイプし、チェックボックス、ラジオボタン選択などを選択することにより）電子式フォームに必要事項を書き入れることは、たとえコンピュータシステムがユーザの活動に応答してフォームを更新することがあっても、フォームに必要事項を手動で書き入れることになる。コンピュータシステムは、フォームに必要事項を自動的に書き入れてよく、この場合、どのユーザ入力もフィールドへの回答を指定することなく、コンピュータシステム（たとえば、コンピュータシステム上で実行されるソフトウェア）は、フォームのフィールドを分析し、フォームに書き込む。上記に示したように、ユーザは、フォームの自動書込みを起動してよいが、フォームを実際に書き込むことには関与しない（たとえば、ユーザは、フィールドへの回答を手動で指定するのではなく、むしろ、フィールドは自動的に完成される）。本明細書は、ユーザが行った活動に応答して動作が自動的に行われるさまざまな例を提供する。
【0024】
【表1】
【0025】
詳細な説明
はじめに
本明細書の実施形態は、まるで浮遊しているような仮想カメラが取得したように環境の仮想描画ビデオを合成するために、多数のカメラから得た画像および／またはビデオのフレームの多視点幾何学的変換を利用する任意の世界ビュー描画出力画像および／またはビデオを作り出すためのシステムおよび方法を提示する。いくつかの実施形態では、この仮想カメラは、ｘ、ｙ、ｚの位置、方位角および高度姿勢、ならびに視野角を含む６つの自由度を有してよい。有利には、仮想カメラは、多数のカメラの場所の各々と異なる位置に配置されてよい。それに加えて、出力画像および／またはビデオを描画するために使用する投影面は、動的であってよく、仮想カメラの周りの対象物に至る距離推定値に連結されてよい。超音波測距センサもしくはミリ波測距センサ、レーダ、ライダ（ｌｉｄａｒ）のような距離測定センサを用いて、またはビデオフレームに適用するコンピュータビジョン技法を使用して、距離推定値を得てよい。本明細書の実施形態を車両先進運転支援システム（ＡＤＡＳ）、ドローンビデオ取得、オフィスもしくは家庭の環境、または多数のカメラを用いる他のプラットフォームのためなどのさまざまな用途で採用してよい。
はじめに
本明細書の実施形態は、まるで浮遊しているような仮想カメラが取得したように環境の仮想描画ビデオを合成するために、多数のカメラから得た画像および／またはビデオのフレームの多視点幾何学的変換を利用する任意の世界ビュー描画出力画像および／またはビデオを作り出すためのシステムおよび方法を提示する。いくつかの実施形態では、この仮想カメラは、ｘ、ｙ、ｚの位置、方位角および高度姿勢、ならびに視野角を含む６つの自由度を有してよい。有利には、仮想カメラは、多数のカメラの場所の各々と異なる位置に配置されてよい。それに加えて、出力画像および／またはビデオを描画するために使用する投影面は、動的であってよく、仮想カメラの周りの対象物に至る距離推定値に連結されてよい。超音波測距センサもしくはミリ波測距センサ、レーダ、ライダ（ｌｉｄａｒ）のような距離測定センサを用いて、またはビデオフレームに適用するコンピュータビジョン技法を使用して、距離推定値を得てよい。本明細書の実施形態を車両先進運転支援システム（ＡＤＡＳ）、ドローンビデオ取得、オフィスもしくは家庭の環境、または多数のカメラを用いる他のプラットフォームのためなどのさまざまな用途で採用してよい。
【0026】
いくつかの実施形態では、車両または他の対象物の周辺に位置決めした多数のカメラから合成した仮想視点を操作者が制御できるようにする単一透視図の中に多数のカメラビューを組み合わせる。この合成ビューは、多数の個々のカメラのストリームを、個々のカメラから得られる歪みおよび照明を補正した画像のシームレスな融合に統合してよい。それに加えて、ユーザは、透視図視点または仮想視点を指定して、たとえば車両上方からの下向きビューを表示してよい。
【0027】
いくつかの実施形態では、ＨｙｐｅｒＸ（登録商標）技術などの並列処理アーキテクチャを利用して、マルチ・モード・センサ・データを取り入れて運転者および乗用車システムに情報を提供するアルゴリズムを実行する高い計算費用に対応してよい。有利には、仮想的な任意の世界ビューを描画して、動的仮想カメラの位置および動的投影面を伴う３６０°サラウンドビューを提供する。いくつかの実施形態による、任意の世界ビューシステムの構成要素間の機能関係の概念図を図１に示す。有利には、本明細書のいくつかの実施形態は、車両自体の構造により、または運転者の周りの全方向を物理的に仮想化する能力により、車両の周りのビューが制約されるときに運転者が安全な手法で車両を動作させるのを支援するシステムを生み出す。本明細書では、いくつかのデジタル・ビデオ・カメラから取得したビデオデータを車両または他の対象物の周りのビューの仮想視点を表す描画ビデオ表示に変換するための方法およびシステムについて記述する。いくつかの実施形態では、１つまたは複数の描画出力画像は、（たとえば、さらに処理するための）別のアプリケーションへの入力の役割を果たしてよい、および／またはメモリまたは他のタイプの記憶媒体に記憶されてよい。
【0028】
図３－出力画像描画の流れ図
図３は、いくつかの実施形態による、複数の入力画像から出力画像を描画するための方法を例示する流れ図である。いくつかの実施形態では、多重カメラシステムに連結したプロセッサを備えるコンピュータシステムにより、記述する方法を遂行してよい。記述する方法を遂行するためのプログラム命令を記憶していてよい１つまたは複数の非一時的コンピュータ可読記憶媒体にプロセッサを連結してよい。いくつかの実施形態では、第５節でより詳細に記述するように、プロセッサは、計算ステップの待ち時間を低減するために利用してよい並列処理ハードウェアシステムであってよい。さまざまな実施形態では、図示する方法の要素のいくつかを、同時に遂行してよい、図示するのと異なる順序で遂行してよい、他の方法要素と置換してよい、または省略してよい。また、追加の方法の要素を望み通りに遂行してよい。図示するように、方法は以下のように動作してよい。
図３は、いくつかの実施形態による、複数の入力画像から出力画像を描画するための方法を例示する流れ図である。いくつかの実施形態では、多重カメラシステムに連結したプロセッサを備えるコンピュータシステムにより、記述する方法を遂行してよい。記述する方法を遂行するためのプログラム命令を記憶していてよい１つまたは複数の非一時的コンピュータ可読記憶媒体にプロセッサを連結してよい。いくつかの実施形態では、第５節でより詳細に記述するように、プロセッサは、計算ステップの待ち時間を低減するために利用してよい並列処理ハードウェアシステムであってよい。さまざまな実施形態では、図示する方法の要素のいくつかを、同時に遂行してよい、図示するのと異なる順序で遂行してよい、他の方法要素と置換してよい、または省略してよい。また、追加の方法の要素を望み通りに遂行してよい。図示するように、方法は以下のように動作してよい。
【0029】
３０２で、複数の入力画像を受信し、異なる第１の場所から複数の入力画像の各入力画像を得る。換言すれば、異なる第１の場所に配置されたカメラまたは別のタイプの画像取得機器により各入力画像を得てよく、その結果、複数の入力画像は、複数のそれぞれの第１の場所に対応する。乗用車、トラック、飛行機、もしくは船などの車両、ドローン、家具、または任意の他のタイプの対象物のさまざまな場所にカメラを搭載してよい。複数のカメラは、それぞれ自身の場所、配向、および／または視界を有してよく、複数のカメラのさまざまなカメラの視界は、部分的に重なってよい。
【0030】
３０４で、出力画像を描画するためのビュー明細事項を受信する。ユーザ入力に応答してビュー明細事項を受信してよい。たとえば、ユーザは、出力画像を描画する際に使用するためにコンピューティングシステムに提供してよいビュー明細事項の１つまたは複数のパラメータを決定するための入力を提示してよい。ビュー明細事項は、出力画像を描画するための第２の場所を含んでよく、第２の場所は、第１の場所の各々と異なってよい。一例として、複数の入力画像が（たとえば、図２Ａに例示するように）車両上の４つの異なる第１の場所から得た４つの入力画像を含む場合、第２の場所は、車両の上方に、または車両の外側の別の場所に配置されてよい。ビュー明細事項は、出力画像を描画する際に使用するための１つまたは複数の追加パラメータをさらに指定してよく、方位角、極角、視界、投影面深度、１つまたは複数の投影面パラメータ、画素解像度、および／または融合幅を含むがそれらに限定されない。原点が第２の場所にある球座標系で方位角および極角を測定することが意図されることが留意される。それにより、方位角および極角は、第２の場所の透視図から出力画像を描画するためのビュー配向を指定してよい。視界は、出力画像の立体角および／または拡大率を指定してよい。さらに、ビュー明細事項は、出力画像の画素解像度（たとえば、１２８０×７２０、１９２０×１０８０、または他の解像度）、および／または重なりのある異なる入力画像のいくつかの部分から得られる出力画像への寄与を融合するための融合幅を指定してよい。投影面深度は、出力画像を描画するために使用する投影面の１つまたは複数の深度パラメータを指定してよい。たとえば、投影面が楕円状円筒である実施形態については、ビュー明細事項は、楕円状円筒の長軸および短軸のうち一方または両方を指定してよい。１つまたは複数の投影面パラメータは、異なるサイズ、形状、投影面に関する事前設定をさらに指定してよい。あるいは以下でより詳細に記述するように、コンピューティングシステムにより投影面を自動的に決定してよい。
【0031】
それぞれの連続した複数の入力画像に基づき連続した出力画像を描画して、出力ビデオを作り出す実施形態については、ユーザがビュー明細事項を動的に改変して、出力ビデオの１つまたは複数のパラメータをリアルタイムで変更してよい。たとえば、ユーザは、第２の場所および／または視点方向などの、ビュー明細事項の１つまたは複数のパラメータを調節して、出力ビデオの視点をリアルタイムで滑らかに改変してよい。これは、一例として、ユーザが駐車手順の間にビュー明細事項の１つまたは複数のパラメータを変更することにより出力ビデオの透視図を改変してよい駐車シナリオで有利であることがある。
【0032】
いくつかの実施形態では、１つまたは複数の第２のビュー明細事項を指定するユーザ入力をさらに受信し、１つまたは複数の第２のビュー明細事項および複数の入力画像に少なくとも一部は基づき１つまたは複数の第２の出力画像を描画する。換言すれば、単一組の入力画像データを使用して、第１のビュー明細事項および第２のビュー明細事項により記述される異なる視点から複数の異なる出力画像を描画してよい。１つまたは複数の第２の出力画像を第１の出力画像（すなわち、第１のビュー明細事項から作り出された出力画像）と同じ表示装置上に表示してよい、または１つまたは複数の異なる表示装置上に表示してよい。
【0033】
３０６で、複数の入力画像およびビュー明細事項に少なくとも一部は基づき出力画像を描画してよい。出力画像は、第２の場所から見たときの、ビュー明細事項の１つまたは複数の他のパラメータによる領域の画像である。いくつかの実施形態では、図４を参照して以下でより詳細に記述するように、投影面にさらに基づき出力画像を描画する。追加で、または代わりに、図５を参照して以下でより詳細に記述するように、ブロックごとに出力画像を描画してよい。有利には、複数の入力画像のいずれかの視点とも異なる視点（すなわち、ビュー明細事項の他の可能性のある性質の中でも、場所、方位角、および／または極角）から出力画像を描画してよい。
【0034】
いくつかの実施形態では、複数の入力画像のうち２つ以上の入力画像から出力画像の少なくとも一部分を供給し、出力画像の少なくとも一部分を描画するステップは、複数の入力画像のうち２つ以上の入力画像からの寄与を融合するステップを含む。たとえば、入力画像のうち２つは、それらの視界で部分的に重なってよく、その結果、重なりの部位の内部にある、これらの入力画像の両方から得られる画素は、出力画像の対応する部分に寄与してよい。
【0035】
いくつかの実施形態では、出力画像の少なくとも一部分の投影場所に２つ以上の入力画像の第１の場所が近いことに少なくとも一部は基づき、融合に重み付けする。たとえば、入力画像のうち２つがそれらのそれぞれの視界の一部分の中で重なるとき、重なりの部位の投影場所が、２つの入力画像の各々を得た第１の場所からどれだけ遠く離れているかを決定してよい。この例では、投影場所により近い第１の場所から得た入力画像が、さらに遠い第１の場所から得たその他の入力画像よりも大きな重みを与えられるように、出力画像の対応する部分への２つの入力画像の寄与を重み付けしてよい。追加で、または代わりに、融合は、２つ以上の入力画像間の照明の不一致を補正してよい。
【0036】
３０８で、出力画像を表示装置上に表示する。表示装置は、出力画像を描画するコンピューティング機器と並べて置かれてよい、または互いに遠隔にあり、ネットワークを介して接続されてよい。いくつかの実施形態では、表示装置を車両内部に設置して、車両の運転者または操作者にＡＤＡＳサービスを提供してよい。あるいは、表示装置は、車両から遠隔に配置されてよく、車両を遠隔で運転する、または動作させるように構成された機器の内部に備わってよい。
【0037】
いくつかの実施形態では、連続したそれぞれの複数の入力画像に基づき連続した出力画像を反復して描画してよく、連続した出力画像を表示装置上にリアルタイムで表示して、リアル・タイム・ビデオを作り出す。換言すれば、図３を参照して記述する方法は、複数の入力画像から描画した単一出力画像について記載するが、その一方で、複数の入力ビデオから出力ビデオを作り出すためのいくつかの実施形態の範囲に入り、本明細書で記述する方法は、ビデオのフレームごとに反復される。
【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】
両方のカテゴリで機能を適用する一般的取り組み方法は、多数のビューの幾何形状の基本原理を使用して、所望の機能性を達成するためにある。いくつかの実施形態では、モデルは、ＯｐｅｎＣＶなどのオープン・ソース・ライブラリを使用して、画像の投影変換を発見および適用するための機能の多くを実装してよい。
【0063】
図６は、いくつかの実施形態による、モデルに含まれる２つのグループの処理に関するデータ流れ図を例示する。図の上部は、較正セットおよびビュー明細事項ごとに一度、オフラインで遂行してよいステップの第１のグループである。描画ブロックパラメータのアレイは、所望のビュー明細事項ごとに生成され、カメラから得られる各組の画像入力に対して遂行してよい動作の第２のグループに利用可能になってよい。
【0064】
３．１ 較正機能およびビュー生成機能
乗用車の上にカメラを設置した後に一度、校正機能を遂行してよい。乗用車に対する仮想カメラの位置および配向を含んでよいビュー明細事項ごとに一度、ビュー生成機能を遂行してよい。これらの機能の出力は、１つのカメラから４つ（または５つ以上）のカメラまでの画像サンプルを使用して、規定されたビューを反復して生成して、ビデオ出力を形成してよい１組のパラメータであってよい。校正機能およびビュー生成機能は、標準的コンピュータ上で作動するオフライン処理であってよい。
乗用車の上にカメラを設置した後に一度、校正機能を遂行してよい。乗用車に対する仮想カメラの位置および配向を含んでよいビュー明細事項ごとに一度、ビュー生成機能を遂行してよい。これらの機能の出力は、１つのカメラから４つ（または５つ以上）のカメラまでの画像サンプルを使用して、規定されたビューを反復して生成して、ビデオ出力を形成してよい１組のパラメータであってよい。校正機能およびビュー生成機能は、標準的コンピュータ上で作動するオフライン処理であってよい。
【0065】
３．１．１ 魚眼歪み補正
画像の投影変換の概念は、基本的なピンホール・カメラ・モデルなどの、基礎となる投影カメラに基づいてよい。このモデルでは、光線は、中心点から直線状像平面を通って世界の中の対象物まで伸びる。世界の中の対象物の位置を、光線が像平面と交差する地点により表してよい。
画像の投影変換の概念は、基本的なピンホール・カメラ・モデルなどの、基礎となる投影カメラに基づいてよい。このモデルでは、光線は、中心点から直線状像平面を通って世界の中の対象物まで伸びる。世界の中の対象物の位置を、光線が像平面と交差する地点により表してよい。
【0066】
投影カメラモデルは、図７に示すように、直線状像平面と湾曲した魚眼画像表面の両方を通過する光線を描くことにより、魚眼レンズ画像と対応する直線状表現の間のマッピングを理解する基礎を提供する（この文書の図では、画像の２Ｄユークリッド部位を表す１次元で、すなわち直線で像平面を描く。同次画像座標および世界の対象物の３Ｄ空間を表す２次元で、中央投影カメラの光線を描く）。
【0067】
異なる種類の魚眼レンズがいくつかある。いくつかの実施形態で使用するレンズは、等距離モデルとも呼ばれる等角投影モデルに従うと仮定され、次式により表される。
ｒF＝ｆFθ 式（１）
式中、ｒFは、魚眼画像表面内での主軸から像点までの距離であり、θは、光線と主軸の間の角度であり、ｆFは、焦点距離に似ている。
ｒF＝ｆFθ 式（１）
式中、ｒFは、魚眼画像表面内での主軸から像点までの距離であり、θは、光線と主軸の間の角度であり、ｆFは、焦点距離に似ている。
【0068】
ピンホール・カメラ・モデルについては、対応する式は以下である。
ｒP＝ｆPｔａｎθ 式（２）
上式は、θを通して魚眼ソース画像からその直線状表現へのマッピングを提供する。このモデルは、ソース画像が投影幾何形状変換に関与するときはいつでもこのマッピングを使用してよい。等角魚眼歪み補正の例を図８に示す。図８Ａは、等角（魚眼）歪み（１８０°の視界）を伴うソース画像を示し、図８Ｂは、ピンホール・カメラ・モデル（１２０°の視界）を使用する再投影を示す。本明細書で使用するとき、「ソース画像」は、図３～図５を参照して記述する入力画像と同義語であると理解されてよい。
ｒP＝ｆPｔａｎθ 式（２）
上式は、θを通して魚眼ソース画像からその直線状表現へのマッピングを提供する。このモデルは、ソース画像が投影幾何形状変換に関与するときはいつでもこのマッピングを使用してよい。等角魚眼歪み補正の例を図８に示す。図８Ａは、等角（魚眼）歪み（１８０°の視界）を伴うソース画像を示し、図８Ｂは、ピンホール・カメラ・モデル（１２０°の視界）を使用する再投影を示す。本明細書で使用するとき、「ソース画像」は、図３～図５を参照して記述する入力画像と同義語であると理解されてよい。
【0069】
３．１．２ カメラ較正
カメラ較正機能は、世界座標系に対するカメラの位置および配向を見いだしてよい。処理への入力は、図１３に示すようなチェス盤パターンの画像であってよい。以下のステップを遂行してよい。
カメラ較正機能は、世界座標系に対するカメラの位置および配向を見いだしてよい。処理への入力は、図１３に示すようなチェス盤パターンの画像であってよい。以下のステップを遂行してよい。
【0070】
１．歪んでいない（直線状の）入力画像内でチェス盤の隅の画素の場所を識別する。これをｃｖ：：ｆｉｎｄＣｈｅｓｓｂｏａｒｄＣｏｒｎｅｒｓ（）機能を使用して行ってよい。
【0071】
２．ユーザは、対応するチェス盤の隅の場所を世界座標で示すアレイを提供する。
【0072】
３．歪んでいないソース画像の中に世界座標を再度投影してよいように、回転行列Ｒソースおよび並進ベクトルＴソースに関して数値的に解く。これをｃｖ：：ｓｏｌｖｅＰｎＰ（）機能を使用して行ってよい。
【0073】
４．カメラ較正処理の成功の尺度である、画素単位での平均再投影誤差を報告する。
【0074】
再投影方程式を以下のように記述してよい。
Ｘソース＝ＲソースＸ世界＋Ｔソース 式（３）
Ｘソース＝ＫＸソース 式（４）
Ｘソース＝ＲソースＸ世界＋Ｔソース 式（３）
Ｘソース＝ＫＸソース 式（４）
【0075】
式中、
【0076】
【数1】
【0077】
は、世界座標フレームでのチェス盤の隅の位置であり、
Ｘソース は、ソースカメラ座標フレームでの同じ地点であり、
Ｋは、ソース像平面の焦点距離および主点パラメータについて記述する固有カメラ行列であり、
Ｘソース＝ｓ（ｕ、ｖ、１）T は、ソース画像の画素位置である。
Ｘソース は、ソースカメラ座標フレームでの同じ地点であり、
Ｋは、ソース像平面の焦点距離および主点パラメータについて記述する固有カメラ行列であり、
Ｘソース＝ｓ（ｕ、ｖ、１）T は、ソース画像の画素位置である。
【0078】
再投影方程式を図９にグラフで示す。回転行列Ｒソースは、世界座標フレームをカメラ座標フレームの配向に回転させ、一方で、並進ベクトルＴソースは、ピンホールカメラの光学的中心であってよいカメラの中心に世界座標の原点を移動させる。ＲソースおよびＴソースは、世界でのカメラの位置および配向を記述するのに十分である。
【0079】
画素位置ｘおよび固有カメラ較正行列Ｋは、ソース画像の直線状表現に関係があってよいことに留意されたい。次いで、魚眼レンズマッピング機能を使用して、チェス盤の隅に対応する、魚眼ソース画像内の実際の画素位置を決定してよい。
【0080】
カメラ較正機能は、カメラの外在的較正パラメータである回転行列Ｒソースおよび並進ベクトルＴソースを提供する。これらのパラメータを用いて、世界座標フレームからソース画像の中に任意の地点Ｘ世界＝（ｘ、ｙ、ｚ）T を投影することが可能であってよい。これは、以下でより詳細に記述するように、ビューの任意の仮想地点に基づき新しい画像を作成するための基礎を提供してよい。
【0081】
乗用車にカメラを取り付けると、これらの外在的較正パラメータを固定してよい。カメラごとに回転行列Ｒソースおよび並進ベクトルＴソースを見いだすために、カメラ較正処理を一度遂行してよい。カメラの相対的な位置および配向が変化しない限り、これらのパラメータを使用して、同じ１組のソースカメラを使用して乗用車の周りの任意の数のビューを生成してよい。
【0082】
３．１．３ 投影変換
いくつかの実施形態では、第３．１．２節で記述するように、投影方程式で世界座標と較正画像の間で投影変換を利用する。世界の対象物の位置は、ｚ軸が地面に対して垂直に配向されてよい世界座標フレームで既知であってよい。投影変換は、カメラ座標フレームの配向に座標フレームを回転させ、次いでカメラの中心まで原点を移動させる並進を加えるステップを含んでよい。その場合、世界の対象物に関する変換された３Ｄ座標を、世界の対象物の画素位置をもたらす、画像の投影面内の同次座標として解釈してよい。
いくつかの実施形態では、第３．１．２節で記述するように、投影方程式で世界座標と較正画像の間で投影変換を利用する。世界の対象物の位置は、ｚ軸が地面に対して垂直に配向されてよい世界座標フレームで既知であってよい。投影変換は、カメラ座標フレームの配向に座標フレームを回転させ、次いでカメラの中心まで原点を移動させる並進を加えるステップを含んでよい。その場合、世界の対象物に関する変換された３Ｄ座標を、世界の対象物の画素位置をもたらす、画像の投影面内の同次座標として解釈してよい。
【0083】
図１０に示すように、ソース画像から得た画像サンプルを使用していくつかの仮想カメラ位置に関する新しいビューを作成するステップは、２つの投影変換を伴ってよい。第一に、ビュー画像内の各画素の位置は、世界座標フレーム内の対象物の位置に投影されてよい。本明細書で使用するとき、「ビュー画像」は、図３～図５を参照して記述した「出力画像」と同義語であると理解されてよい。第二に、その世界の地点をソース画像内の画素位置に戻して再投影してよい。
【0084】
１．ビュー画像からソース画像へのマッピングを、以下の一連のステップにより記述してよい。
【0085】
【数2】
【0086】
をビュー画像座標フレームでの何らかの画素位置に関する同次表現であるとする。ｚがその画素で画像を提供する世界の対象物の実際の深度になるように、特定の地点の値を選んでよい。
【0087】
２．ビュー座標フレームから世界座標フレームに軸を回転させる。
【0088】
３．Ｐビュー（世界座標フレームでのビューカメラの位置）を加算することにより、ビューカメラの中心から世界の原点に原点を移動させる。
【0089】
【数3】
【0090】
４．世界座標フレームから画像座標フレームに軸を回転させる。
【0091】
５．世界の原点から画像カメラの中心に原点を移動させる。
Ｘソース＝ＲソースＸ世界＋Ｔソース 式（６）
Ｘソース＝ＲソースＸ世界＋Ｔソース 式（６）
【0092】
式の組合せは、ソース画像からビュー画像内の画素に関するサンプル値をどこで得るべきかを示す。
【0093】
【数4】
【0094】
投影幾何学では、Ｘビューは、カメラの中心から伸びて、Ｘビューで世界の対象物上に衝突する光線を表す。この光線が像平面を通過する画素位置での画像の色は、Ｘビューでの世界の対象物の色である。対象物の深度を、Ｘビューのｚ成分として規定してよい。ＴソースおよびＰビューの値は世界座標単位であるので、ＴソースおよびＰビューを加算するその後のステップからＸビューを世界座標単位にスケール変更することが望ましいことがある。回転行列Ｒソースおよび
【0095】
【数5】
【0096】
は直交行列であることに留意されたい。これらの回転行列は単位なしであり、これらの回転行列により変換されたベクトルの長さを変えない。
【0097】
３．１．４ 世界の対象物に関する表面モデル
いくつかの実施形態では、任意のビューカメラの中心から対象物の深度を決定することは、自明ではないことがある。世界の中の対象物の３次元モデルを利用して、１つまたは複数のソース画像から事実上または容易には得られないことがある投影面を得てよい。
いくつかの実施形態では、任意のビューカメラの中心から対象物の深度を決定することは、自明ではないことがある。世界の中の対象物の３次元モデルを利用して、１つまたは複数のソース画像から事実上または容易には得られないことがある投影面を得てよい。
【0098】
ビュー生成アルゴリズムは、２つの交差する表面を伴うハイブリッド表面モデルを利用してよい。世界の対象物は、この表面上にあると仮定されてよい。深度を計算する機能は、表面モデルを用いて画像画素を表す光線間の交点としてＸビューを計算するステップを伴ってよい。
【0099】
画素位置から始まる数学的方程式として、最初にこの位置を同次表現で表してよい。
【0100】
【数6】
【0101】
次いで、逆固有カメラ行列Ｋを適用する。
【0102】
【数7】
【0103】
その後の動作のためにＸビューを適切にスケール変更するように、Ｘビューのｚ成分が、ビューカメラから得られる対象物の深度になるように、スケーリング因子ｓを見いだしてよい。実際は、ピンホール・カメラ・モデルに関する固有カメラ行列Ｋは、ビューカメラから得られる対象物の深度にｓが等しくなるようなものであってよい。
【0104】
乗用車の周りの世界がｚ＝０で基平面であると仮定される実施形態について、深度の計算を式１１に示す。これらの実施形態では、ビューカメラ明細事項は、地面の上の何らかの高さＰビュー｜zでのカメラの位置Ｐビュー、および高度θ＋φを含み、ここでは、θは、ビュー主軸と＋ｚ軸の間の角度であり、φは、ビュー主軸と画像光線の間の角度である。
【0105】
Ｘビューに対する光線の長さは、
【0106】
【数8】
【0107】
であり、深度は、ビューカメラ主軸に沿ったこの長さの成分である。
【0108】
【数9】
【0109】
基平面表面モデルは、上から見た乗用車の周りのビューに関してうまく機能するが、水平線の上に物点を含むビューに関して望ましくないことがある。前景内の垂直な対象物もまた、水平基平面表面モデルを仮定する描画されたビューで歪むことがある。ビューの高度が上昇して、水平線に接近するにつれ、ビュー内のより多くの対象物は、他の可能性の中でもとりわけ建築物、植生、他の車両、および／または人々などの垂直な表面を表すことがある。
【0110】
いくつかの実施形態では、円筒状投影面モデルを導入して、垂直ではない主軸を伴うビューに関するより現実的な描画を提供する。このモデルは、図１２に示すように、少し離れた距離で乗用車を包む垂直な表面の上に物点があると仮定する。円筒の主軸は、乗用車の中心を通ってｚ方向に伸びてよい。
【0111】
任意の世界ビューシステムは、円筒状の表面が乗用車からどれだけ遠く離れているかに関する仮定を行ってよいが、多くの事例では、描画されたビューは、この距離が世界の対象物までの実際の距離とどれだけ厳密に調和するかに強く依存しなくてよい。いくつかの実施形態では、円筒のサイズは、乗用車が移動している速度に連結されてよい。制止している乗用車は、隣接する障害物をより正確に描画するためにより短い距離を使用してよいが、一方で、移動している乗用車で描画されたビューは、より現実的により大きな円筒寸法を仮定していてよい。
【0112】
いくつかの実施形態は、仮想カメラの中心からカメラの主軸に向けて（ｘ、ｙ）平面内で伸びる光線の交差を見いだすことによって動作する。その場合、任意の垂直成分を考慮するように光線の長さ増大させてよく、その結果、仮定した物点Ｘビューを円筒表面上に得る。
【0113】
（ｘ、ｙ）平面内の円筒状境界の形状は、楕円形であってよく、長軸は乗用車の長さに沿って配向し、短軸は幅に沿って配向する。ビュー明細事項の一部として、ユーザは、乗用車の縁部から円筒状表面までの距離を表す単一の表面深度値を指定してよい。
【0114】
ビュー生成機能は、ハイブリッド実装で基平面表面モデルと円筒状表面モデルの両方を採用してよい。両方のモデルを使用して、ビューカメラの中心から得られる所与の光線に関する深度を計算してよく、より小さな値を選んでよい。両方のモデルが深度に関してほぼ等しい値を提供する場合、半径機能は、減少した値を計算してよい。結果は、平坦な底部、乗用車を取り囲む垂直な側面、および垂直な側面の間にある滑らかな丸みのついた境界面を伴うくぼみの形状で仮定された世界の対象物表面であってよい。
【0115】
仮定した円筒寸法が実際の世界の対象物までの距離よりも短い場合、ハイブリッドモデルは、描画された画像に興味深い効果を引き起こすことがある。たとえば、乗用車の近くにある対象物は、期待された透視図で描画されることがあるが、遠く離れた地点は、魚眼レンズ効果を示すことがある。半径機能は、描画された画像内のこれらの部位の間の遷移が滑らかであることをもたらす。
【0116】
３．１．５ ソース画像からビュー画像への区画ごとの線形変換
前節は、次式のようにマップ関数として要約されることがある、任意の視点に関してソース画像（すなわち、入力画像）画素をビュー画像（すなわち、出力画像）にマッピングする投影変換について概要を述べている。
Ｘソース＝ＲマップＸビュー＋Ｔマップ 式（１２）
ｘ＝ＫＸソース 式（１３）
前節は、次式のようにマップ関数として要約されることがある、任意の視点に関してソース画像（すなわち、入力画像）画素をビュー画像（すなわち、出力画像）にマッピングする投影変換について概要を述べている。
Ｘソース＝ＲマップＸビュー＋Ｔマップ 式（１２）
ｘ＝ＫＸソース 式（１３）
【0117】
上式は、ピンホール・カメラ・モデルによればソース画像内の画素位置ｘ＝ｓ（ｕ、ｖ、１）Tをもたらしてよい。最終ステップとして、第３．１．１節で記述する非線形マッピングを適用して、当初の魚眼ソース画像内の画素位置を得てよい。
【0118】
ビュー画像のあらゆる画素に関してマップ関数を評価することが可能であることがあるが、これは、あらゆるビューに関して大量のマッピング情報をもたらすことがある。これに対処して、描画時間および計算負荷を低減するために、いくつかの実施形態では、出力ビュー画像を画素ブロック（たとえば、１６×１６の画素ブロック、または別のサイズもしくは形状の画素ブロック）のグリッドに分割してよく、各ブロックの隅に関してだけマップ関数を評価してよい。図１３は、ビュー画像内の１６×１６のグリッドに対応する、２つの魚眼ソース画像での１組のブロックを示す。例示するように、白いブロックをビュー画像にマッピングし、灰色のブロックを別のソース画像から得られるブロックと融合して、ビュー画像にマッピングし、黒いブロックは、代わりによりよいソース画像を使用してよいので、ビュー画像で使用されない。赤い痕跡は、２つのソース画像間の融合領域の中心線を示す。ハイブリッド表面モデルは、地面の上にあると仮定される、乗用車に近い地点、および乗用車を取り囲む円筒の表面上にあると仮定される、より遠くにある地点を伴って見ることができてよい。
【0119】
出力ブロックごとにアフィン変換の係数を計算して、ソース画像サンプルをビュー画像の中にワープさせてよい。一般的投影変換を３×３行列の乗算演算として実装してよいが、アフィン変換は、より少ない自由度を伴う特殊事例であることがあり、変換行列の最後の行を使用する必要がないことがある。したがって、各出力ブロック内の画素に関するマッピングは、次式に還元されてよい。
【0120】
【数10】
【0121】
わずか６つの値を利用して、出力ブロックごとにアフィン変換を記述し、各ビュー画像ブロックの４隅のソース画像位置は、値ａ11、…、ａ23を解くための十分な情報を提供する。
【0122】
ビュー画像位置をソース画像にマッピングする機能は、魚眼レンズ歪みに対する較正を含むとき、非線形になることがある。アフィン変換は、線形であってよく、一般的投影変換よりも制限的であってよいが、１６×１６の出力ブロックごとに別個に適用されてよいので、出力ビューを描画するのに十分であることがある。前記の別の方法では、レンズ歪みの程度は、出力画像を分割する画素ブロックのサイズと共に増大することがある。より小さな画素ブロックサイズはより大きな計算負荷に変換されるので、１６×１６の画素ブロックサイズは、十分に小さな歪みの度合いを導入することと資源を処理することの間で望ましい均衡を提示することがある。これは、基礎になる非線形マッピングへの、区画ごとの近似を形成する。いくつかの実施形態は、描画するための計算とリアルタイム描画システムでのブロックマッピング情報のための記憶領域要件を均衡させてよい。
【0123】
３．１．６ 融合比の計算
ソースカメラ上の魚眼レンズは、１８０°の視界を提供してよい。いくつかの実施形態では、隣接するカメラが取得した画像の間にかなりの重なりが存在してよいように、４つの基本方向を向く４つのカメラが存在する。
ソースカメラ上の魚眼レンズは、１８０°の視界を提供してよい。いくつかの実施形態では、隣接するカメラが取得した画像の間にかなりの重なりが存在してよいように、４つの基本方向を向く４つのカメラが存在する。
【0124】
いくつかの実施形態では、どのソースカメラがビュー画像内の各ブロックに寄与するかを決定するために、融合比計算を使用してよい。ビュー画像内の所与のブロックの場所について、対応するソース画像および魚眼画像の中心からの距離に基づき、距離指標を計算してよい。２つのソースに関して計算した距離指標が、隣接するブロックの距離指標以上である場合、２つのソース間の中心線上に存在するとしてビュー画像ブロックを識別してよい。この指標は、最も高い解像度を有する各画像の中心に最も近いソースサンプルのほう好むという影響を及ぼしてよい。
【0125】
いくつかの実施形態では、各ソース画像は、描画されたビュー画像に出現すべきではないソースサンプルを不適格と判定するための排除境界を含んでよい。ソース画像ブロックが排除境界に近い場合、中心線を排除境界から離して移動させるようにソース画像ブロックの距離指標を調節してよい。
【0126】
ビュー画像内の中心線ブロックを識別した後、隣接するブロックに、中心線からの距離に基づき融合比の値を割り当ててよい。２つのソース画像から得られる、寄与するブロックからビューブロックが構成される場合、ビューブロック自体の画像中心は、０．５～１．０の間の融合比を割り当てられてよく、一方では、その他のソースブロックは、小さい方の相補的値を割り当てられてよい（たとえば、その他のソースブロックは、より近いブロックに割り当てられた値を１から減算した加重値を割り当てられてよい）。
【0127】
融合比計算は、カメラ較正機能およびビュー生成機能の最後のステップであってよい。いくつかの実施形態では、重なるビュー画像ブロックの比は、描画機能に関して各ビューを規定する１組のパラメータに含まれてよい。
【0128】
３．２ 描画機能
いくつかの実施形態では、任意の世界ビュー例証システムの描画機能を反復して遂行して、所与のビュー明細事項に関して出力ビデオを作り出してよい。いくつかの実施形態では、描画機能は、仮想統合表示システム（ｖｉｓｕａｌ ｉｎｔｅｇｒａｔｅｄ ｄｉｓｐｌａｙ ｓｙｓｔｅｍ、ＶＩＤＳ）プラットフォーム上で、リアルタイムで作動してよいＨｙｐｅｒＸ（登録商標）アプリケーションなどの並列処理システムを通して実装されてよい。
いくつかの実施形態では、任意の世界ビュー例証システムの描画機能を反復して遂行して、所与のビュー明細事項に関して出力ビデオを作り出してよい。いくつかの実施形態では、描画機能は、仮想統合表示システム（ｖｉｓｕａｌ ｉｎｔｅｇｒａｔｅｄ ｄｉｓｐｌａｙ ｓｙｓｔｅｍ、ＶＩＤＳ）プラットフォーム上で、リアルタイムで作動してよいＨｙｐｅｒＸ（登録商標）アプリケーションなどの並列処理システムを通して実装されてよい。
【0129】
また、いくつかの実施形態では、描画機能のモデル実装を利用してよい。モデル実装は、標準的コンピュータ上で作動してよく、単一フレームに対して機能し、任意の世界ビューアルゴリズムを評価するためのプラットフォームを提供してよい。モデルの機能は、リアルタイムＨｙｐｅｒＸ（登録商標）と密接に関係があるので、モデルはまた、ＨｙｐｅｒＸ（登録商標）アプリケーションの開発を支援するための試験ベクトルを提供してよい。
【0130】
描画機能の入力は、所与の視点に関して出力画像の１６×１６のブロックごとに１組のパラメータを含んでよい。４つのカメラから得られるソース画像はまた、描画機能への入力の役割を果たしてよい。
【0131】
３．２．１ デモザイク
いくつかの実施形態では、単一ＣＣＤデジタルカメラから得られるカラー画像を、赤、緑、および青のサンプルのモザイクを形成する色フィルタアレイであってよいベイヤー（Ｂａｙｅｒ）フィルタを通して取得してよい。デモザイク機能は、画素あたり１つのサンプル値を、完全な赤、緑、および青のカラープレーンを表す、画素あたり３つの値に変換してよい。
いくつかの実施形態では、単一ＣＣＤデジタルカメラから得られるカラー画像を、赤、緑、および青のサンプルのモザイクを形成する色フィルタアレイであってよいベイヤー（Ｂａｙｅｒ）フィルタを通して取得してよい。デモザイク機能は、画素あたり１つのサンプル値を、完全な赤、緑、および青のカラープレーンを表す、画素あたり３つの値に変換してよい。
【0132】
リアルタイムの任意の世界ビューＨｙｐｅｒＸ（登録商標）システムでは、ビュー画像内の各１６×１６の画素ブロックに対応するソース画像ブロックにデモザイク機能を適用してよい。ソース画像ブロックは、アフィン変換適用後に結果として得られるビュー画像ブロックよりも小さくても、大きくてもよいサイズを伴う長方形の形状を有してよい。長方形の入力ブロックは、ビュー画像ブロックごとに使用するソース画像サンプルを完全に包含するので、「バウンディングボックス」と呼ばれることがある。図１１に示すブロックのグリッドを参照すると、バウンディングボックスは、各ソース画像ブロックを完全に包含する直角の長方形であってよい。
【0133】
さまざまな実施形態では、異なるデモザイク方法を選んでよい。バウンディングボックスが１０００画素以下である場合、従来のデモザイクアルゴリズムを適用してよい。いくつかの実施形態では、各画素の場所で、色が欠落した２つのサンプルを補完してよい。
【0134】
１０００～４０００ワードの間のバウンディングボックスについては、ダウン・ダンプリング・デモザイク・アルゴリズムを使用してよい。各画素サンプルを対応する色の隣接するサンプルの加重平均として計算して、フィルタ動作でフィルタリング、ダウンサンプリング、および補完を完了してよい。入力バウンディングボックスに対して出力バウンディングボックスを垂直および水平に２分の１だけ縮小してよい。アフィン変換係数を事前に補完して、縮小されたバウンディングボックスを考慮してよい。
【0135】
ダウン・サンプリング・デモザイク法は、リアルタイムの任意の世界ビューにより処理されてよい入力ブロックサイズの範囲を拡張する。デモザイク動作の出力は、対応する１６×１６のビュー画像ブロックを描画するのに十分大きなソース画像サンプルのブロックであってよい。
【0136】
３．２．２ ワープおよびブロック平均
いくつかの実施形態では、ワープ関数を採用して、アフィン変換を適用する。入力は、デモザイク関数から得られる、画素あたり３サンプルを伴うソース画像ブロックであってよく、出力は、１６×１６のビュー画像ブロックであってよい。
いくつかの実施形態では、ワープ関数を採用して、アフィン変換を適用する。入力は、デモザイク関数から得られる、画素あたり３サンプルを伴うソース画像ブロックであってよく、出力は、１６×１６のビュー画像ブロックであってよい。
【0137】
ブロック画素位置ごとに、バウンディングボックス内部の対応する画素位置を次式のように計算してよい。
【0138】
【数11】
【0139】
式中、係数ａ11、…、ａ23は、ビュー生成機能により計算された１組のパラメータの一部であってよい。位置
【0140】
【数12】
【0141】
は、ｕおよびｖの整数値に制約されない実数値の位置であってよく、その結果、その位置に関する赤、緑、および青のサンプル値を補完してよい。双一次補完を使用してよい。
【0142】
入力ブロックをビュー画像ブロックにワープすることに加えて、ビュー画像ブロック全体にわたって平均した赤、緑、および青のサンプル値を計算してよい。以下の第３．２．３節に記述する測光アラインメント機能により、ブロック平均値を使用してよい。
【0143】
３．２．３ 測光アラインメント
異なる照明条件が、異なる方向から車両の方を向くことに応答して、異なるカメラが露光および絞りの設定を独立して自動的に調節するのを保証するために、測光アラインメントシステムを利用してよい。２つのソース画像が、重なるブロックをビュー画像に提供する場合、その結果得られる融合された領域は、２つのソース画像の測光特性が互いに調和するように調節した場合、より自然に見えることがある。
異なる照明条件が、異なる方向から車両の方を向くことに応答して、異なるカメラが露光および絞りの設定を独立して自動的に調節するのを保証するために、測光アラインメントシステムを利用してよい。２つのソース画像が、重なるブロックをビュー画像に提供する場合、その結果得られる融合された領域は、２つのソース画像の測光特性が互いに調和するように調節した場合、より自然に見えることがある。
【0144】
図１３Ａおよび図１３Ｂは、多数の入力画像による重なりを例証する。例示するように、ミッドグレーの境界を伴うソース画像ブロックは、ビュー画像の重なる融合領域内にある。測光アラインメントは、ソース画像の色を等しくして、描画されたビュー画像内の継ぎ目が消えるようにするのに役立つことがある。
【0145】
いくつかの実施形態では、２つのソース画像間で、重なる領域内でブロック平均サンプル値を比較してよい。同じ場所に配置されたブロック内のサンプル値を最適に等しくなるように、ソース画像ごとに大域利得補正値を計算してよい。赤、緑、および青のカラープレーンごとに、別個の利得値を計算してよい。ビュー画像全体にわたって収集したブロック平均値を使用して、４つのソース画像に関して最大１２までの利得値を計算してよい。
【0146】
先行する１組のソース画像に関して計算した利得値を、現在のビュー画像内の画像サンプルのすべてに適用してよい。対応する色およびソース画像に関する利得値を各サンプル値に単に積算してよい。
【0147】
３．２．４ 融合
いくつかの実施形態では、描画処理の最終ステップを利用して、異なるカメラソースから、重なるビュー画像を融合する。大部分のビュー画像ブロックは、単一ソース画像から得られるサンプルだけを含み、融合機能は、これらのブロックについてはパススルー機能であってよい。残りのビュー画像ブロックについては、赤、緑、および青の値を、２つの画像ソースから得られる２つの同じ場所に位置する描画されたブロックの加重平均として画素ごとに組み合わせてよい。
いくつかの実施形態では、描画処理の最終ステップを利用して、異なるカメラソースから、重なるビュー画像を融合する。大部分のビュー画像ブロックは、単一ソース画像から得られるサンプルだけを含み、融合機能は、これらのブロックについてはパススルー機能であってよい。残りのビュー画像ブロックについては、赤、緑、および青の値を、２つの画像ソースから得られる２つの同じ場所に位置する描画されたブロックの加重平均として画素ごとに組み合わせてよい。
【0148】
第３．１．６節に記述するように、融合のために使用する加重値をビュー生成処理で計算した。単一ビュー画像ブロックに寄与する２つの加重値は、合計して１になってよい。
【0149】
融合機能の出力は、１組のソースカメラから得られるソース画像サンプルが存在するブロック位置に関する１組の１６×１６のビュー画像ブロックであってよい。ビュー画像内のいくつかのブロック位置は、どのソースカメラにもマッピングされないことがあり、これらのブロックは描画されないことがある。
【0150】
外部メモリ内のフレーム画像の中に出力ブロックを合成してよい。別個のタスクは、ＶＩＤＳプラットフォームのＤＶＩ出力を通して提示するために外部メモリからラインごとにビュー画像を読み出す責任を負ってよい。
【0151】
４． ソフトウェア
いくつかの実施形態では、１つから４つまでのソース画像から得られる画像サンプルに基づき所与の視点に関する単一画像を描画するために、一緒に作動する４つのソフトウェアの形をとる任意の世界ビューシステムを提供してよい。各プログラムは、独立に構築され、作動してよいが、一緒に作動可能にする共通の１組の構成およびパラメータのファイルを共有してよい。
いくつかの実施形態では、１つから４つまでのソース画像から得られる画像サンプルに基づき所与の視点に関する単一画像を描画するために、一緒に作動する４つのソフトウェアの形をとる任意の世界ビューシステムを提供してよい。各プログラムは、独立に構築され、作動してよいが、一緒に作動可能にする共通の１組の構成およびパラメータのファイルを共有してよい。
【0152】
４．１ パラメータおよび構成のファイル
モデル・ソフトウェア・アプリケーション・スイート内のプログラムは、多くのパラメータを利用して、ソースカメラ、所望のビュー、および描画されるビュー画像内の各１６×１６のブロックまたはタイルに関する情報について記述してよい。プログラムのすべては、パラメータファイルからこれらのパラメータを取り込んでよく、いくつかの実施形態では、コマンド・ライン・オプションは一般に使用されない。
モデル・ソフトウェア・アプリケーション・スイート内のプログラムは、多くのパラメータを利用して、ソースカメラ、所望のビュー、および描画されるビュー画像内の各１６×１６のブロックまたはタイルに関する情報について記述してよい。プログラムのすべては、パラメータファイルからこれらのパラメータを取り込んでよく、いくつかの実施形態では、コマンド・ライン・オプションは一般に使用されない。
【0153】
４．１．１ ＢｌｏｃｋＩｎｆｏ
ブロックレベルのパラメータは、ＢｌｏｃｋＩｎｆｏと呼ばれ、第３．１節に記述するビュー生成動作と第３．２節に記述する描画動作の間の橋渡しになる。これらのパラメータは、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔｉｆｉｃａｔｉｏｎ）フォーマットファイルに包含されてよい。ＪＳＯＮは、人間が読むことができてよいがソフトウェアもまた容易に取り入れてよい共通のウェブ・アプリケーション・プログラミング慣行から借用した軽量なデータ交換フォーマットであってよい。
ブロックレベルのパラメータは、ＢｌｏｃｋＩｎｆｏと呼ばれ、第３．１節に記述するビュー生成動作と第３．２節に記述する描画動作の間の橋渡しになる。これらのパラメータは、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔｉｆｉｃａｔｉｏｎ）フォーマットファイルに包含されてよい。ＪＳＯＮは、人間が読むことができてよいがソフトウェアもまた容易に取り入れてよい共通のウェブ・アプリケーション・プログラミング慣行から借用した軽量なデータ交換フォーマットであってよい。
【0154】
ある例のＢｌｏｃｋＩｎｆｏ構造を図１４に示し、パラメータについて以下の表２で説明する。
【0155】
【表2】
【0156】
所与のビュー明細事項に関してビュー画像内のあらゆるブロックについて記述するブロック・パラメータ・セットのすべてを包含するファイルの中でＢｌｏｃｋＩｎｆｏ構造体を使用してよい。
【0157】
デモザイクモデルおよびリアルタイムの任意の世界ビューＨｙｐｅｒＸ（登録商標）システムは、図１５に示すようなＣまたはＣ＋＋構造体としてフォーマットされたＢｌｏｃｋＩｎｆｏパラメータを使用してよい。これは、人間が読むことができなくてよいが、ソフトウェアで取り扱うのに効率的であることがあるバイナリフォーマットであってよい。
【0158】
４．１．２ ＣａｍＤａｔａ
いくつかの実施形態では、ＣａｍＤａｔａ構成ファイルをＪＳＯＮフォーマットで利用してよい。ＣａｍＤａｔａ構成ファイルは、ビュー生成機能により使用されなくてよく、描画するために必要ではなくてよい。ｃａｍｅｒａ＿ｃａｌｉｂｒａｔｅプログラムは、入力と出力の両方としてＣａｍＤａｔａファイルを使用してよく、一方では、ｖｉｅｗ＿ｇｅｎｅｒａｔｅプログラムは、入力としてＣａｍＤａｔａファイルを使用してよい。ある例のＣａｍＤａｔａファイルは、図１６に示され、表２に示すように、３つのセクションを含む。例示するように、第１のセクションは、カメラ較正に必要な最小の１組のパラメータを包含する。第２のセクションは、カメラ較正処理の結果であるビュー生成に必要なパラメータを追加する。第３のセクションは、ただ人間の読み手だけのための情報であってよく、どのプログラムによっても使用されなくてよい。ＣａｍＤａｔａファイルを読み出すソフトウェアが使用する機能は、存在するファイルをできるだけ読み出すので、第２のセクションおよび第３のセクション内の任意の未知のパラメータは、ファイルから単に省かれててよいことに留意されたい。
いくつかの実施形態では、ＣａｍＤａｔａ構成ファイルをＪＳＯＮフォーマットで利用してよい。ＣａｍＤａｔａ構成ファイルは、ビュー生成機能により使用されなくてよく、描画するために必要ではなくてよい。ｃａｍｅｒａ＿ｃａｌｉｂｒａｔｅプログラムは、入力と出力の両方としてＣａｍＤａｔａファイルを使用してよく、一方では、ｖｉｅｗ＿ｇｅｎｅｒａｔｅプログラムは、入力としてＣａｍＤａｔａファイルを使用してよい。ある例のＣａｍＤａｔａファイルは、図１６に示され、表２に示すように、３つのセクションを含む。例示するように、第１のセクションは、カメラ較正に必要な最小の１組のパラメータを包含する。第２のセクションは、カメラ較正処理の結果であるビュー生成に必要なパラメータを追加する。第３のセクションは、ただ人間の読み手だけのための情報であってよく、どのプログラムによっても使用されなくてよい。ＣａｍＤａｔａファイルを読み出すソフトウェアが使用する機能は、存在するファイルをできるだけ読み出すので、第２のセクションおよび第３のセクション内の任意の未知のパラメータは、ファイルから単に省かれててよいことに留意されたい。
【0159】
【表3】
【0160】
いくつかの実施形態では、ｔａｒｇｅｔＰｏｓｉｔｉｏｎパラメータは、図１７に例示する世界座標フレームに基づいてよい。乗用車の中心は、ｘ－ｙ軸の原点に必ずしもなくてよいが、カメラ較正動作は、軸方向が、図示されているようなものであることを仮定する。具体的には、いくつかの実施形態では、－ｙ軸方向は、乗用車の前方から前へ伸びてよい。
【0161】
４．１．３ ＶｉｅｗＳｐｅｃ
ＶｉｅｗＳｐｅｃは、仮想カメラに関する所望の視点について記述する。このビューを「生成するステップ」は、ＶｉｅｗＳｐｅｃで指定されたビューを描画するために使用するＢｌｏｃｋＩｎｆｏ構造体のファイルを作り出すステップを伴う。いくつかの実施形態では、ＶｉｅｗＳｐｅｃファイルは、ビュー生成処理だけで使用されてよく、リアルタイム描画システムにより必要とされなくてよい。
ＶｉｅｗＳｐｅｃは、仮想カメラに関する所望の視点について記述する。このビューを「生成するステップ」は、ＶｉｅｗＳｐｅｃで指定されたビューを描画するために使用するＢｌｏｃｋＩｎｆｏ構造体のファイルを作り出すステップを伴う。いくつかの実施形態では、ＶｉｅｗＳｐｅｃファイルは、ビュー生成処理だけで使用されてよく、リアルタイム描画システムにより必要とされなくてよい。
【0162】
【0163】
【表4】
【0164】
４．２ ソフトウェア構成要素
任意の世界ビューシステムに関するモデルソフトウェアは、２つのライブラリおよびいくつかのコマンド・ライン・アプリケーションを含んでよい。ライブラリは、ビュー生成および描画アルゴリズムの機能の多くを実装してよい。アプリケーションは、ライブラリの機能を呼び出して、高水準の一連の動作およびファイルＩ／Ｏを取り扱うコードを追加してよい。
任意の世界ビューシステムに関するモデルソフトウェアは、２つのライブラリおよびいくつかのコマンド・ライン・アプリケーションを含んでよい。ライブラリは、ビュー生成および描画アルゴリズムの機能の多くを実装してよい。アプリケーションは、ライブラリの機能を呼び出して、高水準の一連の動作およびファイルＩ／Ｏを取り扱うコードを追加してよい。
【0165】
４．２．１ ＯｐｅｎＣＶ（登録商標）ライブラリ
ＯｐｅｎＣＶ（登録商標）は、コンピュータ・ビジョン・アプリケーションをサポートするオープン・ソース・ライブラリ機能である。ＯｐｅｎＣＶ（登録商標）は、すべての標準プラットフォーム用にパッケージ化された形態で利用可能であり、１組の中心的な基本データ型および機能を提供する。たとえば、投影幾何学を伴う動作のすべては、たとえベクトルおよび行列を伴う線形代数方程式を表しても、簡単な数学的演算としてＣ＋＋で表現される。ビューブロックごとにアフィン変換を見いだすために使用する特異値分解（ｓｉｎｇｕｌａｒ ｖａｌｕｅ ｄｅｃｏｍｐｏｓｉｔｉｏｎ、ＳＶＤ）アルゴリズムなどのいくつかの機能はかなり複雑であり、ＯｐｅｎＣＶ（登録商標）を使用することは、モデルの効率的実装に利益となることがある。いくつかの実装形態では、任意の世界ビューモデルは、ＯｐｅｎＣＶ（登録商標）のＣ＋＋ ＡＰＩのバージョン２．４を使用する。
ＯｐｅｎＣＶ（登録商標）は、コンピュータ・ビジョン・アプリケーションをサポートするオープン・ソース・ライブラリ機能である。ＯｐｅｎＣＶ（登録商標）は、すべての標準プラットフォーム用にパッケージ化された形態で利用可能であり、１組の中心的な基本データ型および機能を提供する。たとえば、投影幾何学を伴う動作のすべては、たとえベクトルおよび行列を伴う線形代数方程式を表しても、簡単な数学的演算としてＣ＋＋で表現される。ビューブロックごとにアフィン変換を見いだすために使用する特異値分解（ｓｉｎｇｕｌａｒ ｖａｌｕｅ ｄｅｃｏｍｐｏｓｉｔｉｏｎ、ＳＶＤ）アルゴリズムなどのいくつかの機能はかなり複雑であり、ＯｐｅｎＣＶ（登録商標）を使用することは、モデルの効率的実装に利益となることがある。いくつかの実装形態では、任意の世界ビューモデルは、ＯｐｅｎＣＶ（登録商標）のＣ＋＋ ＡＰＩのバージョン２．４を使用する。
【0166】
４．２．２ ＡｒｔｈｒｏＣＶライブラリ
いくつかの実装形態では、ＡｒｔｈｒｏＣＶライブラリは、モデルアルゴリズムの機能の多くを包含する。ＡｒｔｈｒｏＣＶライブラリは、ＯｐｅｎＣＶ（登録商標）から得られる、より基本的機能よりも任意の世界ビューアプリケーションに特有な共通機能にアクセスするアプリケーションのためのＣ＋＋アプリケーション・プログラミング・インタフェース（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ、ＡＰＩ）を表す。たとえば、等角（魚眼）カメラモデルとピンホール・カメラ・モデル（第３．１．１節）の間でのソース画像サンプルのマッピングは、ＡｒｔｈｒｏＣＶ（登録商標） ＡＰＩの一部であってよいＣ＋＋クラスであってよい。
いくつかの実装形態では、ＡｒｔｈｒｏＣＶライブラリは、モデルアルゴリズムの機能の多くを包含する。ＡｒｔｈｒｏＣＶライブラリは、ＯｐｅｎＣＶ（登録商標）から得られる、より基本的機能よりも任意の世界ビューアプリケーションに特有な共通機能にアクセスするアプリケーションのためのＣ＋＋アプリケーション・プログラミング・インタフェース（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ、ＡＰＩ）を表す。たとえば、等角（魚眼）カメラモデルとピンホール・カメラ・モデル（第３．１．１節）の間でのソース画像サンプルのマッピングは、ＡｒｔｈｒｏＣＶ（登録商標） ＡＰＩの一部であってよいＣ＋＋クラスであってよい。
【0167】
ＡｒｔｈｒｏＣＶ（登録商標）ライブラリは、単一の共有オブジェクトライブラリとして、すなわち、Ｗｉｎｄｏｗｓ（登録商標）についてはａｒｔｈｒｏｃｖ．ｄｌｌ、またはＬｉｎｕｘ（登録商標）についてはｌｉｂａｒｔｈｒｏｃｖ．ｓｏとして提供されてよい。
【0168】
４．２．３ デモザイク
いくつかの実施形態では、デモザイクプログラムは、単一ＣＣＤカメラが取得した画像を変換する独立型プログラムであってよい。機能への入力は、色サンプルの、ベイヤーモザイクを伴う未加工の２値画像であってよい。一例として、未加工の２値画像が画素あたり１０ビットを包含する場合、出力は、あらゆる画素位置に関して画素ファイルあたり３２ビットであってよく、１０ビットの赤、緑、および青のサンプルを伴う。
いくつかの実施形態では、デモザイクプログラムは、単一ＣＣＤカメラが取得した画像を変換する独立型プログラムであってよい。機能への入力は、色サンプルの、ベイヤーモザイクを伴う未加工の２値画像であってよい。一例として、未加工の２値画像が画素あたり１０ビットを包含する場合、出力は、あらゆる画素位置に関して画素ファイルあたり３２ビットであってよく、１０ビットの赤、緑、および青のサンプルを伴う。
【0169】
いくつかの実施形態では、画像ファイルを変換するために、デモザイクプログラムは、
ｄｅｍｏｓａｉｃ －ｉｍａｇｅ ｂｌｏｃｋｉｎｆｏ＿ｉｍａｇｅ＿ａｌｉｇｎｍｅｎｔ．ｂｉｎ ｂａｙｅｒＩｎｐｕｔＦｉｌｅ．ｒａｗ ｏｕｔｆｉｌｅ．ｒａｗ
を起動してよい。ここで、ｂｌｏｃｋｉｎｆｏ＿ｉｍａｇｅ＿ａｌｉｇｎｍｅｎｔ．ｂｉｎは、ベイヤー・パターン・アラインメントを含むソース画像を記述する単一の２値ＢｌｏｃｋＩｎｆｏパラメータセットを包含する。
ｄｅｍｏｓａｉｃ －ｉｍａｇｅ ｂｌｏｃｋｉｎｆｏ＿ｉｍａｇｅ＿ａｌｉｇｎｍｅｎｔ．ｂｉｎ ｂａｙｅｒＩｎｐｕｔＦｉｌｅ．ｒａｗ ｏｕｔｆｉｌｅ．ｒａｗ
を起動してよい。ここで、ｂｌｏｃｋｉｎｆｏ＿ｉｍａｇｅ＿ａｌｉｇｎｍｅｎｔ．ｂｉｎは、ベイヤー・パターン・アラインメントを含むソース画像を記述する単一の２値ＢｌｏｃｋＩｎｆｏパラメータセットを包含する。
【0170】
追加のオープン・ソース・ユーティリティを用いてデモザイクプログラムを包み込んで．ｐｇｍ（ｐｏｒｔａｂｌｅ ｇｒａｙ ｍａｐ）および．ｐｎｇ（ｐｏｒｔａｂｌｅ ｇｒａｐｈｉｃｓ ｆｏｒｍａｔ、移植性のあるグラフィックスフォーマット）などの他の標準画像フォーマットとの間で変換するシェルスクリプトを提供してよい。
【0171】
４．２．４ カメラ較正
いくつかの実施形態によるカメラ較正機能について、第３．１．２節で上記に記述した。カメラ較正の結果は、世界座標フレームでのカメラの位置および配向を示す回転行列および並進ベクトルであってよい。
いくつかの実施形態によるカメラ較正機能について、第３．１．２節で上記に記述した。カメラ較正の結果は、世界座標フレームでのカメラの位置および配向を示す回転行列および並進ベクトルであってよい。
【0172】
乗用車の上にカメラを設置した後、カメラごとにカメラ較正を一度遂行してよい。カメラにより、チェス盤較正標的を包含する画像を取得してよい。カメラおよび標的のパラメータを第４．１．２節および表２に記述するように、ＣａｍＤａｔａ構成ファイルのセクション１で指定してよい。
【0173】
その後、カメラ較正は、
ｃａｍｅｒａ＿ｃａｌｉｌｂｒａｔｅ ｃａｍ０．ｊｓｏｎ
を起動してよい。
ｃａｍｅｒａ＿ｃａｌｉｌｂｒａｔｅ ｃａｍ０．ｊｓｏｎ
を起動してよい。
【0174】
プログラムは、いくつかの実施形態によれば、セクション２およびセクション３で更新したパラメータを用いてカメラ構成ファイルを書き直してよい。いくつかの実施形態では、プログラムはまた、正しい動作を検証するために２つの画像を表示してよい。第１の画像のある例は、図２０に示され、魚眼レンズの視界の円形境界が識別される当初のソース画像であってよい。ソフトウェアは、画像データの等角（魚眼）カメラモデルの表現とピンホール・カメラ・モデルの表現の間で正確なマッピングを生成するため使用してよい、円形画像の中心および半径を自動的に発見してよい。第１の検証画像はまた、ＣａｍＤａｔａ構成ファイルで指定した排除境界を示してよい。
【0175】
第２の検証画像のある例は、図２１に例示され、魚眼レンズ歪みを補正した後の較正標的を示す。例示するように、画像内でチェス盤画像の隅を自動的に検出する。較正プログラムは、これらの隅を使用して、カメラの位置および配向を解決する。
【0176】
ｃａｍｅｒａ＿ｃａｌｉｂｒａｔｅプログラムは、ソース画像に戻して再投影された、世界座標フレームでのチェス盤の隅の場所の平均誤差である再投影誤差を報告してよい。再投影誤差の単位は、ソース画像のピンホールカメラ表現では画素であってよい。いくつかの実施形態では、ほぼ１画素以下の再投影誤差が望ましいことがある。
【0177】
多数のカメラを使用して、任意のビューに関する融合ビュー画像を形成してよい。ビュー生成アルゴリズムは、較正後、互いに固定した相対的な位置および配向を維持するカメラに依存することがある。したがって、地上の１つの場所で乗用車を駐車しながら、すべてのカメラに関する較正画像を取得することが望ましいことがある。
【0178】
４．２．５ ビュー生成
いくつかの実施形態では、単一プログラムは、第３．１．３節～第３．１．６節に記述するビュー生成動作のすべてを包含する。入力は、仮想カメラの位置、配向、サイズ、および視界を提供するＶｉｅｗＳｐｅｃ構成ファイル（第４．１．３節を参照のこと）であってよい。出力は、描画された画像内のあらゆる１６×１６のタイルに関するＢｌｏｃｋＩｎｆｏパラメータセットを包含するファイルであってよい。このファイルは、リアルタイムビュー描画システムへの入力であってよい。
いくつかの実施形態では、単一プログラムは、第３．１．３節～第３．１．６節に記述するビュー生成動作のすべてを包含する。入力は、仮想カメラの位置、配向、サイズ、および視界を提供するＶｉｅｗＳｐｅｃ構成ファイル（第４．１．３節を参照のこと）であってよい。出力は、描画された画像内のあらゆる１６×１６のタイルに関するＢｌｏｃｋＩｎｆｏパラメータセットを包含するファイルであってよい。このファイルは、リアルタイムビュー描画システムへの入力であってよい。
【0179】
ＢｌｏｃｋＩｎｆｏパラメータセットは、コマンドラインで提供される、できるだけ多くのカメラ、たとえば最大４つまでのカメラからソース画像データを参照してよい。たとえば、所与のビューに関するＢｌｏｃｋＩｎｆｏパラメータのファイルを作成するために、以下のコマンドを使用してよい。
ｖｉｅｗ＿ｇｅｎｅｒａｔｅ ｔｏｐ＿ｄｏｗｎ＿ｖｉｅｗ．ｊｓｏｎ ｃａｍ１＿ｆｒｏｎｔ．ｊｓｏｎ ｃａｍ２＿ｒｅａｒ．ｊｓｏｎ ｃａｍ３＿ｌｅｆｔ．ｊｓｏｎ ｃａｍ４＿ｒｉｇｈｔ．ｊｓｏｎ
ここで、ｖｉｅｗ０．ｊｓｏｎは、ＶｉｅｗＳｐｅｃ構成ファイルであり、コマンドライン上のその他のファイルは、ＣａｍＤａｔａ構成ファイルである。任意の数のＣａｍＤａｔａ構成ファイルを指定してよく（この実施形態では、最大４つまで）、ＣａｍＤａｔａ構成ファイルは、コマンドライン上で任意の順序であってよい。
ｖｉｅｗ＿ｇｅｎｅｒａｔｅ ｔｏｐ＿ｄｏｗｎ＿ｖｉｅｗ．ｊｓｏｎ ｃａｍ１＿ｆｒｏｎｔ．ｊｓｏｎ ｃａｍ２＿ｒｅａｒ．ｊｓｏｎ ｃａｍ３＿ｌｅｆｔ．ｊｓｏｎ ｃａｍ４＿ｒｉｇｈｔ．ｊｓｏｎ
ここで、ｖｉｅｗ０．ｊｓｏｎは、ＶｉｅｗＳｐｅｃ構成ファイルであり、コマンドライン上のその他のファイルは、ＣａｍＤａｔａ構成ファイルである。任意の数のＣａｍＤａｔａ構成ファイルを指定してよく（この実施形態では、最大４つまで）、ＣａｍＤａｔａ構成ファイルは、コマンドライン上で任意の順序であってよい。
【0180】
いくつかの実施形態では、ｖｉｅｗ＿ｇｅｎｅｒａｔｅは、動作するとき、出力ビュー画像で使用するブロックの重なりを伴う、各ＣａｍＤａｔａ構成ファイルに対応するソース画像を示す。図１３Ａおよび図１３Ｂは、これらの注釈付きソース画像のある例を示す。例示するように、薄い色のブロックをビュー画像にマッピングし、灰色のブロックを別のソース画像からのブロックと融合させて、ビュー画像にマッピングし、羊羹色のブロックは、代わりによりよいソース画像を使用してよいので、ビュー画像で使用されない。一連の印は、図１３Ａおよび図１３Ｂの２つのソース画像間の融合領域を示す。
【0181】
４．２．６ ビュー描画
いくつかの実施形態では、ｖｉｅｗ＿ｒｅｎｄｅｒプログラムを第３．２節に記述する描画処理全体のモデル実装として利用する。
いくつかの実施形態では、ｖｉｅｗ＿ｒｅｎｄｅｒプログラムを第３．２節に記述する描画処理全体のモデル実装として利用する。
【0182】
ｖｉｅｗ＿ｇｅｎｅｒａｔｅにより作り出されるＢｌｏｃｋＩｎｆｏパラメータファイルは、多数のカメラ情報源から所与のビューを描画する方法の、ブロックごとの完全な記述であってよい。コマンドライン上で利用される唯一の追加データは、ソース画像のｃａｍｅｒａＩｄ値に加えてソース画像自体のファイル名であってよい。
【0183】
ある例のコマンドラインは、
ｖｉｅｗ＿ｒｅｎｄｅｒ ｂｌｏｃｋｉｎｆｏ．ｊｓｏｎ １ ｆｒｏｎｔ＿ｃ．ｐｎｇ ２ ｒｅａｒ＿ｃ．ｐｎｇ ３ ｌｅｆｔ＿ｃ．ｐｎｇ ４ ｒｉｇｈｔ＿ｃ．ｐｎｇ
であり、ここで、ファイル引数は、ｖｉｅｗ＿ｇｅｎｅｒａｔｅにより作り出されるＢｌｏｃｋＩｎｆｏパラメータファイルであってよい。次の引数は、その生成されたビューで使用したカメラのすべてに関する１対の｛ｃａｍｅｒａＩｄ，ｓｏｕｒｃｅＩｍａｇｅ｝である。
ｖｉｅｗ＿ｒｅｎｄｅｒ ｂｌｏｃｋｉｎｆｏ．ｊｓｏｎ １ ｆｒｏｎｔ＿ｃ．ｐｎｇ ２ ｒｅａｒ＿ｃ．ｐｎｇ ３ ｌｅｆｔ＿ｃ．ｐｎｇ ４ ｒｉｇｈｔ＿ｃ．ｐｎｇ
であり、ここで、ファイル引数は、ｖｉｅｗ＿ｇｅｎｅｒａｔｅにより作り出されるＢｌｏｃｋＩｎｆｏパラメータファイルであってよい。次の引数は、その生成されたビューで使用したカメラのすべてに関する１対の｛ｃａｍｅｒａＩｄ，ｓｏｕｒｃｅＩｍａｇｅ｝である。
【0184】
この機能モデルは、ビデオレートで作動しているカメラから得られる実況の取得により最大４つまでのソース画像が提供されるシステムのためにあってよいので、画像ファイル名は、較正用に提供されるファイルと同じである必要がなくてよい。しかしながら、各画像ファイルは、同じカメラが取得した較正画像と同じｃａｍｅｒａＩｄに関連づけられることが望ましいことがある。
【0185】
図２２は、描画されたビューのある例である。画像の中央の欠けたブロックは、乗用車自体が４つのカメラから地面のビューを遮断することによりもたらされた。画像の残りの部分は、３つのカメラから得られるデータから構成されてよく、３つのカメラの間で融合された遷移を伴う。たとえ第４のカメラをコマンドラインで指定していたことがあるとしても、第４のカメラの画像サンプルは、ＶｉｅｗＳｐｅｃ構成が記述する視界の範囲内にない場合、描画された画像で使用されないことがある。
【0186】
５． 並列プロセッサシステム設計
以下の節は、いくつかの実施形態による、任意の世界ビューシステムおよび方法のビュー描画部分のための設計について概要を述べる。設計は、４つのＧｉｇＥ Ｖｉｓｉｏｎカメラ入力およびＤＶＩ表示装置用の直接出力を含むＨｙｐｅｒＸ（登録商標）開発システム内のＨｙｐｅｒＸ（登録商標） ｈｘ３１００プロセッサに基づいてよい、または別のタイプの並列処理ハードウェアシステムに基づいてよい。
以下の節は、いくつかの実施形態による、任意の世界ビューシステムおよび方法のビュー描画部分のための設計について概要を述べる。設計は、４つのＧｉｇＥ Ｖｉｓｉｏｎカメラ入力およびＤＶＩ表示装置用の直接出力を含むＨｙｐｅｒＸ（登録商標）開発システム内のＨｙｐｅｒＸ（登録商標） ｈｘ３１００プロセッサに基づいてよい、または別のタイプの並列処理ハードウェアシステムに基づいてよい。
【0187】
５．１ 機能分析
機能分析は、上記の第３．２節で記述するように、ビュー描画アルゴリズムの計算動作を考慮してよい。この場合、機能を遂行するために何プロセッササイクルを利用してよいかに関する推定値を提供してよい基本動作数を機能ごとに推定してよい。ビュー画像の１ブロックを取り扱う機能ごとのサイクルカウントを理解することにより、システムがどれだけ多くのプロセッサ要素を利用して、リアルタイムで作動させて、特定のフレームレート（たとえば、１秒あたり３０または６０フレーム）で特定の解像度（たとえば、１４４０×９００または他の解像度）のビュー画像を作り出すかを示すことが可能である。
機能分析は、上記の第３．２節で記述するように、ビュー描画アルゴリズムの計算動作を考慮してよい。この場合、機能を遂行するために何プロセッササイクルを利用してよいかに関する推定値を提供してよい基本動作数を機能ごとに推定してよい。ビュー画像の１ブロックを取り扱う機能ごとのサイクルカウントを理解することにより、システムがどれだけ多くのプロセッサ要素を利用して、リアルタイムで作動させて、特定のフレームレート（たとえば、１秒あたり３０または６０フレーム）で特定の解像度（たとえば、１４４０×９００または他の解像度）のビュー画像を作り出すかを示すことが可能である。
【0188】
いくつかの実施形態による、任意の世界ビュー描画機能の主要な計算ステップについて以下の節で記述する。以下の例示的な１組の明細事項によれば、処理でのステップごとのブロックスループット要件は、標的ビュー画像のサイズおよびフレームレートに基づいてよい。
【0189】
５．１．１ デモザイク
いくつかの実施形態では、デモザイクアルゴリズムのために（たとえば、第３．２．１節に記述するように）２つの機能カーネルを利用してよく、一方の機能カーネルは、ベイヤー・モザイク・パターンで、緑の場所で赤および青の画素を補完するためにあり、第２の機能カーネルは、青／赤の場所で緑および赤／青の画素を補完するためにある。
いくつかの実施形態では、デモザイクアルゴリズムのために（たとえば、第３．２．１節に記述するように）２つの機能カーネルを利用してよく、一方の機能カーネルは、ベイヤー・モザイク・パターンで、緑の場所で赤および青の画素を補完するためにあり、第２の機能カーネルは、青／赤の場所で緑および赤／青の画素を補完するためにある。
【0190】
次に、デモザイク処理のためのブロックサイズに関して仮定を行ってよい。これは、単一出力の１６×１６のブロックを描画するために使用するソース画像データのバウンディングボックスであってよい。分析は、ブロックごとに、最悪の場合を想定した１０００サンプルのサイズを仮定した。バウンディングボックスのサイズが１０００～４０００サンプルの間である場合、代わりのダウン・サンプリング・デモザイク・アルゴリズムを使用してよいことを想記されたい。
【0191】
５．１．２ ワーパ（ｗａｒｐｅｒ）
ワーパ機能は、第３．２．２節に記述するように、ソース画像サンプルの長方形ブロックから得られる１６×１６のビューブロックの２５６画素を計算してよい。機能の２つの部分は、アフィン変換を適用して、入力サンプルブロック内の（非整数の）位置を得るステップ、およびその位置に基づき入力サンプルを補完するステップを含んでよい。測光アラインメントアルゴリズムで使用するために、ブロック平均の赤、緑、および青の値もまたワーパ内で計算してよい。
ワーパ機能は、第３．２．２節に記述するように、ソース画像サンプルの長方形ブロックから得られる１６×１６のビューブロックの２５６画素を計算してよい。機能の２つの部分は、アフィン変換を適用して、入力サンプルブロック内の（非整数の）位置を得るステップ、およびその位置に基づき入力サンプルを補完するステップを含んでよい。測光アラインメントアルゴリズムで使用するために、ブロック平均の赤、緑、および青の値もまたワーパ内で計算してよい。
【0192】
５．１．３ 測光アラインメント
測光アラインメントアルゴリズム（第３．２．３節）を２つのセルの中に実装してよく、一方のセルは、利得推定のためにあり、他方のセルは、利得値を適用して、カラーサンプル値を調節してよい利得補正であってよい。利得推定セルは、自乗差の合計を計算し、しきい値機能を適用して、調和が不完全なブロックを不適格と判定する。各フレームの終わりで、利得推定セルはまた、記憶した自乗差値の合計を伴う連立方程式を解く。
測光アラインメントアルゴリズム（第３．２．３節）を２つのセルの中に実装してよく、一方のセルは、利得推定のためにあり、他方のセルは、利得値を適用して、カラーサンプル値を調節してよい利得補正であってよい。利得推定セルは、自乗差の合計を計算し、しきい値機能を適用して、調和が不完全なブロックを不適格と判定する。各フレームの終わりで、利得推定セルはまた、記憶した自乗差値の合計を伴う連立方程式を解く。
【0193】
５．１．４ 融合
融合されたビューブロックは、サンプル値に寄与する２つのソース画像を有する１つの融合されたビューブロックであってよい。この例示的実施形態では、ビュー画像ブロックの２０％は融合されると仮定され、残りの８０％は融合されない。融合計算は、融合されるビューブロックだけに適用されてよい。他のブロックは、単に単一入力から出力にコピーされてよい。
融合されたビューブロックは、サンプル値に寄与する２つのソース画像を有する１つの融合されたビューブロックであってよい。この例示的実施形態では、ビュー画像ブロックの２０％は融合されると仮定され、残りの８０％は融合されない。融合計算は、融合されるビューブロックだけに適用されてよい。他のブロックは、単に単一入力から出力にコピーされてよい。
【0194】
５．２ アーキテクチャ考慮事項
本節は、システム設計に制約を課すことがあるさまざまなアーキテクチャ考慮事項を列挙し、ハードウェアプラットフォームの詳細および高水準の機能明細事項を含む。いくつかの実施形態では、任意の世界ビューシステムは、自身の機能を遂行して、これらの考慮事項により記述される要件を満たしてよい。前節による機能分析と共にこれらの考慮事項は、システム設計の性能を決定する重要な要因となることがある。
本節は、システム設計に制約を課すことがあるさまざまなアーキテクチャ考慮事項を列挙し、ハードウェアプラットフォームの詳細および高水準の機能明細事項を含む。いくつかの実施形態では、任意の世界ビューシステムは、自身の機能を遂行して、これらの考慮事項により記述される要件を満たしてよい。前節による機能分析と共にこれらの考慮事項は、システム設計の性能を決定する重要な要因となることがある。
【0195】
５．２．１ 高水準の機能明細事項
アーキテクチャ考慮事項である高水準の機能明細事項は、システムの標的入力／出力および計算スループットを決定する明細事項であってよい。いくつかの実施形態では、任意の世界ビューシステム要件文書で以下の明細事項を確立してよい。
アーキテクチャ考慮事項である高水準の機能明細事項は、システムの標的入力／出力および計算スループットを決定する明細事項であってよい。いくつかの実施形態では、任意の世界ビューシステム要件文書で以下の明細事項を確立してよい。
【0196】
例証システムは、ユーザが選択した車両のビューを表示するビデオモニタを提供してよい。表示装置は、公称解像度１４４０×９００を有してよく、ＤＶＩ信号方式インタフェースを有してよい。
【0197】
例証システムは、カメラから少なくとも３０ｆｐｓのレートで画像を取得し、同じレートで表示装置へのフレームを処理してよい。表示装置の実際のリフレッシュレートは、より高くてよいが、システムが処理する内容の更新レートは、少なくとも３０ｆｐｓであってよい。
【0198】
５．２．２ ハードウェアプラットフォーム
いくつかの実施形態では、任意の世界ビューアプリケーションのための計算プラットフォームは、チップ１、チップ２、およびチップ３というラベルのついた３つのＨｙｐｅｒＸ（登録商標）プロセッサを装備したＨｙｐｅｒＸ（登録商標）開発システムであってよい。チップ１およびチップ２はそれぞれ、図２３に示すように、ＵＤＰ／ＩＰパケットを送受信するＨｙｐｅｒＸ（登録商標）セルの形をとるソフトウェアドライバを含むギガビット・イーサネット・インタフェースを伴うボード上に提供されてよい。ソフトウェアＩ／Ｏドライバセルは、ＧｉｇＥ Ｖｉｓｉｏｎ画像伝送プロトコルをサポートしてよく、各チップは、２つのカメラからビデオを同時に受信してよい。
いくつかの実施形態では、任意の世界ビューアプリケーションのための計算プラットフォームは、チップ１、チップ２、およびチップ３というラベルのついた３つのＨｙｐｅｒＸ（登録商標）プロセッサを装備したＨｙｐｅｒＸ（登録商標）開発システムであってよい。チップ１およびチップ２はそれぞれ、図２３に示すように、ＵＤＰ／ＩＰパケットを送受信するＨｙｐｅｒＸ（登録商標）セルの形をとるソフトウェアドライバを含むギガビット・イーサネット・インタフェースを伴うボード上に提供されてよい。ソフトウェアＩ／Ｏドライバセルは、ＧｉｇＥ Ｖｉｓｉｏｎ画像伝送プロトコルをサポートしてよく、各チップは、２つのカメラからビデオを同時に受信してよい。
【0199】
図１９ チップ１およびチップ２の資源
いくつかの実施形態では、チップ１およびチップ２はそれぞれ、以下の追加能力および資源を有してよい。
いくつかの実施形態では、チップ１およびチップ２はそれぞれ、以下の追加能力および資源を有してよい。
【0200】
１．それぞれサイズが少なくとも１２８ＭＢの４つの外部メモリ
【0201】
２．生帯域幅（ｒａｗ ｂａｎｄｗｉｄｔｈ）が１２５ＭＷ／秒の、左側の隣接に至る２つのＬＶＤＳ Ｉ／Ｏインタフェース
【0202】
３．生帯域幅が１２５ＭＷ／秒の、右側の隣接に至る２つのＬＶＤＳ Ｉ／Ｏインタフェース
【0203】
４．５００ＭＨｚに設定されたコアクロック
【0204】
５．ギガビット・イーサネット・ドライバ・セルのために使用するのよりも少ない１００のプロセッサ要素および１２１のデータ・メモリ・ルータ
【0205】
図２４に示す第３のチップは、ビデオ出力用ＤＶＩインタフェースを伴うボード上に提供される。ソフトウェアビデオ出力ドライバセルを提供して、チップ３上で作動しているＨｙｐｅｒＸ（登録商標）アプリケーションからボード上のハードウェア・ライン・ドライバを通して標準的ＤＶＩコンピュータモニタに至る直接接続を可能にしてよい。
【0206】
いくつかの実施形態では、チップ３は、以下の追加能力および資源を有してよい。
【0207】
１．それぞれサイズが少なくとも１２８ＭＢの３つの利用可能な外部メモリ
【0208】
２．生帯域幅が１２５ＭＷ／秒の、右側の隣接に至る２つのＬＶＤＳ Ｉ／Ｏインタフェース
【0209】
３．４２５ＭＨｚに設定されたコアクロック（このレートは、１４４０×９００×６０ｆｐｓのＤＶＩ出力のために使用される）
【0210】
４．ＤＶＩ出力ドライバセルのために使用するのよりも少ない１００のプロセッサ要素および１２１のデータ・メモリ・ルータ
【0211】
６． チップ設計
前節は、ビデオレートでビュー画像をリアルタイムで描画するための任意の世界ビューシステムのためのシステム設計について記述している。第３．２節は、描画システムが遂行してよいアルゴリズムについて記述し、第４．２．６節は、アルゴリズムのためのソフトウェアモデルを提供している。高水準性の性能明細事項について第５．２．１節で記述し、標的プラットフォームについて第５．２．２節で記述している。
前節は、ビデオレートでビュー画像をリアルタイムで描画するための任意の世界ビューシステムのためのシステム設計について記述している。第３．２節は、描画システムが遂行してよいアルゴリズムについて記述し、第４．２．６節は、アルゴリズムのためのソフトウェアモデルを提供している。高水準性の性能明細事項について第５．２．１節で記述し、標的プラットフォームについて第５．２．２節で記述している。
【0212】
さまざまな実施形態では、この適用例のためのシステム設計に対する解決手段が２つ以上あってよく、異なる解決手段は、実装の詳細が変動する。本節で記述する特定の解決手段は、明細事項を満たして、さらにまたセル再利用および設計の保守性という一般的な工学的目標もサポートするように設計された。
【0213】
６．１ ３チップ設計
いくつかの実施形態では、開発プラットフォームにより課されるアーキテクチャ上の制約は、２つの異なるチップの各々で２つのカメラからビデオを受信することであることがある。これはまた、２つのチップ間で描画処理の主要な計算作業を等しく分割することを好都合にすることがある。いくつかの実施形態では、これは、図２５に示すように、高水準作業負荷分割を通して達成されてよい。例示するように、右から左へと、ＨＸ１およびＨＸ２というラベルのついたチップ１およびチップ２でビデオを受信および処理してよい。各チップ上での処理は、４つのカメラすべてから得られるビデオサンプルへのアクセスを利用してよいので、２つのチップは、直接受信しなかったビデオデータを交換してよい。
いくつかの実施形態では、開発プラットフォームにより課されるアーキテクチャ上の制約は、２つの異なるチップの各々で２つのカメラからビデオを受信することであることがある。これはまた、２つのチップ間で描画処理の主要な計算作業を等しく分割することを好都合にすることがある。いくつかの実施形態では、これは、図２５に示すように、高水準作業負荷分割を通して達成されてよい。例示するように、右から左へと、ＨＸ１およびＨＸ２というラベルのついたチップ１およびチップ２でビデオを受信および処理してよい。各チップ上での処理は、４つのカメラすべてから得られるビデオサンプルへのアクセスを利用してよいので、２つのチップは、直接受信しなかったビデオデータを交換してよい。
【0214】
ＨＸ３というラベルのついた第３のチップは、部分的に処理されたビューブロックを第１の２つのチップから受信してよく、描画処理を完了して、ビデオフレームをＤＶＩ表示装置に送信してよい。
【0215】
次節では、３チップの内部設計についてより詳細に記述する。
【0216】
６．２ チップ１およびチップ２の設計
図２６は、いくつかの実施形態による、チップ１およびチップ２に関するデータフロー設計を示す。例示するように、カメラデータのためのＧｉｇＥ Ｖｉｓｉｏｎ入力は、図の右上にある。処理ネットワークは、以下の要素のうち１つまたは複数を含んでよい。
図２６は、いくつかの実施形態による、チップ１およびチップ２に関するデータフロー設計を示す。例示するように、カメラデータのためのＧｉｇＥ Ｖｉｓｉｏｎ入力は、図の右上にある。処理ネットワークは、以下の要素のうち１つまたは複数を含んでよい。
【0217】
１．入力画像を脱パケット化し（ｄｅｐａｃｋｅｔｉｚｅ）、入力画像をＤＤＲ外部メモリに書き込むための２つの並列パス
【0218】
２．外部メモリに記憶する４つのカメラストリームを、すなわち、ローカル・イーサネット・インタフェースからの２つのカメラストリームおよびその他のチップからの２つのカメラストリームを考慮するＭｅｍＳｖｒ３セルおよびＭｅｍＳｖｒＥｘｔ３セル
【0219】
３．異なるＤＤＲ外部メモリに記憶され、セル生成により読み出されるＢｌｏｃｋＩｎｆｏパラメータ
【0220】
４．ブロックごとに各ＢｌｏｃｋＩｎｆｏパラメータで指定されるようなバウンディングボックスを読み出すＩｎｐｕｔＲｅａｄｅｒ
【0221】
５．いくつかのデモザイクセルを含むデモザイクグループ
【0222】
６．いくつかのワーパセルを含むワーパグループ
【0223】
７．異なるサイズのＢｌｏｃｋＩｎｆｏに起因するブロック処理レートの変動を吸収するための、いくつかの通信チャネル上に含まれるＦＩＦＯ
【0224】
８．チップ３に送信される、ビュー画像ブロックのストリームであってよい、チップ１およびチップ２からの出力
【0225】
６．２．１ デモザイクグループ
ｄｅｍｏｓａｉｃ＿ｇｒｏｕｐセルは、２つの入力および１つの出力を伴う単一セルであってよい。デモザイクグループの内部には、いくつかのデモザイクセル、および作業負荷分配専用の他のＰＥが存在する。いくつかの実施形態による、ｄｅｍｏｓａｉｃ＿ｇｒｏｕｐセルの内部構造を図２７に示す。ワーパグループは、ただ１つの単一入力を伴うことを除き、類似の構造を有してよい。
ｄｅｍｏｓａｉｃ＿ｇｒｏｕｐセルは、２つの入力および１つの出力を伴う単一セルであってよい。デモザイクグループの内部には、いくつかのデモザイクセル、および作業負荷分配専用の他のＰＥが存在する。いくつかの実施形態による、ｄｅｍｏｓａｉｃ＿ｇｒｏｕｐセルの内部構造を図２７に示す。ワーパグループは、ただ１つの単一入力を伴うことを除き、類似の構造を有してよい。
【0226】
６．３ チップ３の設計
チップ３は、図２８に示すように、チップ１およびチップ２からビューブロックのストリームを受信する。ストリームは、出力画像内のビュー画像すべてを測光アラインメントのために一緒に考慮してよいように、単一ストリームに合併されてよい。チップ３上のセルに関する機能分析は、セルが機能あたり２つ以上または３つ以上のＰＥを必要としなくてよいことを示す（第５．１．３節および第５．１．４節を参照のこと）。
チップ３は、図２８に示すように、チップ１およびチップ２からビューブロックのストリームを受信する。ストリームは、出力画像内のビュー画像すべてを測光アラインメントのために一緒に考慮してよいように、単一ストリームに合併されてよい。チップ３上のセルに関する機能分析は、セルが機能あたり２つ以上または３つ以上のＰＥを必要としなくてよいことを示す（第５．１．３節および第５．１．４節を参照のこと）。
【0227】
測光アラインメント複合セルの出力は、ビューブロックの最終形態ではビューブロックのストリームであってよい。外部メモリ内のフレームバッファにブロックを書き込んでよい。次いで、ＤＶＩ出力セルを通して表示するために、描画された完成フレームをラインごとに外部メモリから読み出してよい。
【0228】
６．３．１ 測光アラインメント複合セル
いくつかの実施形態では、チップ３内の画像処理機能のすべては、図２９に示す測光アラインメント複合セルにより包含されてよい。機能は、第３．２．３節、第３．２．４節、第５．１．３節、および第５．１．４節に記述するように、利得推定、利得補正、および融合を含んでよい。
いくつかの実施形態では、チップ３内の画像処理機能のすべては、図２９に示す測光アラインメント複合セルにより包含されてよい。機能は、第３．２．３節、第３．２．４節、第５．１．３節、および第５．１．４節に記述するように、利得推定、利得補正、および融合を含んでよい。
【0229】
６．４ システムの設計目標
任意の世界ビューシステムのために描画されたビュー画像を作り出してよいシステム設計は、２つ以上存在してよい。前の図および段落で記述した特定の設計は、ＨｙｐｅｒＸ（登録商標）技術に基づく最も高度な並列実装に共通の、いくつかの一般的な設計目標を満たすように選ばれた。しかしながら、これらの特有の設計パラメータは、例示することだけを意図され、本明細書で記述する実施形態を実装するために他の設計パラメータおよびシステムを利用することは、本開示の範囲に入ることが理解される。
任意の世界ビューシステムのために描画されたビュー画像を作り出してよいシステム設計は、２つ以上存在してよい。前の図および段落で記述した特定の設計は、ＨｙｐｅｒＸ（登録商標）技術に基づく最も高度な並列実装に共通の、いくつかの一般的な設計目標を満たすように選ばれた。しかしながら、これらの特有の設計パラメータは、例示することだけを意図され、本明細書で記述する実施形態を実装するために他の設計パラメータおよびシステムを利用することは、本開示の範囲に入ることが理解される。
【0230】
６．４．１ 局所化
前のいくつか節で遂行される異なる機能を異なるセルに分割してよい。外部メモリ・インタフェース・セルなどのいくつかのセルは、主として計算のためにではなくデータ移動のためにあってよい。局所化は、選ばれた設計分解の重要な目標（たとえば、多くのセルの間でのアルゴリズム分割）であってよい。局所化は、設計でその他のセルが遂行している機能の知識なしに各セルが自身の機能を行ってよいことを意味すると解釈されてよい。セルが自身のタスクを遂行するために利用してよい唯一の情報を自身の入力上で受信してよく、セルは、下流のセルが下流のセルのタスクを行うために利用する作業結果だけを送信してよい。
前のいくつか節で遂行される異なる機能を異なるセルに分割してよい。外部メモリ・インタフェース・セルなどのいくつかのセルは、主として計算のためにではなくデータ移動のためにあってよい。局所化は、選ばれた設計分解の重要な目標（たとえば、多くのセルの間でのアルゴリズム分割）であってよい。局所化は、設計でその他のセルが遂行している機能の知識なしに各セルが自身の機能を行ってよいことを意味すると解釈されてよい。セルが自身のタスクを遂行するために利用してよい唯一の情報を自身の入力上で受信してよく、セルは、下流のセルが下流のセルのタスクを行うために利用する作業結果だけを送信してよい。
【0231】
任意の世界ビューシステムでの局所化のある例は、セルがビューブロックを処理しているときにセルの作業負荷がどのフレームに属しているかを多くのセルが設計の際にわかっていないという点に認められてよい。セルの機能は、あらゆるブロックについて同じであってよい。必要に応じてフレーム境界を追跡して、外部メモリ内のフレームポインタを更新することは、他のセルの責任であってよい。
【0232】
システム内のセルのインタフェースは、設計で良好な局所化が存在するかどうかを例証することがある。セルごとのインタフェースが、簡単であると言っても差し支えないほどに簡単である場合、局所化は良好であってよい。簡単なインタフェースは、いくつかの他の設計分解と比較して、作業負荷あたり最小の入力データサイズおよび出力データサイズを伴う少数の入力ポートおよび出力ポートを有してよい。
【0233】
設計が局所化を重要視することにより、設計の中で、および他の設計で、再利用可能である傾向がある簡単なセルがもたらされることがある。さまざまな実施形態によれば、デモザイクグループおよびワーパグループは、設計の中でのセル再利用の例であり、外部メモリインタフェースは、多くの設計で再利用されてよいセルのある例である。
【0234】
６．４．２ フィードフォワード
いくつかの実施形態では、設計で各セルが上流のセルからデータを受信し、データに対して自身の機能を遂行し、次いで下流のセルに結果を送信することを意味すると解釈されてよいフィードフォワード設計を利用してよい。この設計は、設計でセルが上流のセルにデータを送り返すなどの明示的フィードバック通信を有しなくてよい。
いくつかの実施形態では、設計で各セルが上流のセルからデータを受信し、データに対して自身の機能を遂行し、次いで下流のセルに結果を送信することを意味すると解釈されてよいフィードフォワード設計を利用してよい。この設計は、設計でセルが上流のセルにデータを送り返すなどの明示的フィードバック通信を有しなくてよい。
【0235】
純粋にフィードフォワードな設計は、フロー制御および性能に関する簡単なモデルを有してよい。任意の世界ビューシステムの所望のスループットは、毎秒３０フレームであってよく、これは、特定のブロック処理レートに変換されてよい。設計であらゆるセルが自身の機能を所望のレートで遂行することができる場合、設計全体はまた、設計にフィードバックパスがまったく存在しない限り性能目的を達成してよい。フロー制御モデルを個々のセルそれぞれの内部で局所化してよく、各セルは、所望のレートで各セルに作業負荷を供給する各セルの上流の隣接に、および所望のレートで各セルの結果を受け入れる下流の隣接に、単に依存してよい。
【0236】
６．４．３ 分散制御
いくつかの実施形態では、分散制御の原理は、任意の大規模計算にスケール変更するＨｙｐｅｒＸ（登録商標）技術に基づく並列処理用途に有利であることがある。分散制御は、セルが自身の命令を上流の隣接からだけ受信して、下流の隣接だけに命令を送信することを意味すると解釈されてよい。いくつかの実施形態では、分散制御は、局所化のある様態であってよい。
いくつかの実施形態では、分散制御の原理は、任意の大規模計算にスケール変更するＨｙｐｅｒＸ（登録商標）技術に基づく並列処理用途に有利であることがある。分散制御は、セルが自身の命令を上流の隣接からだけ受信して、下流の隣接だけに命令を送信することを意味すると解釈されてよい。いくつかの実施形態では、分散制御は、局所化のある様態であってよい。
【0237】
分散制御の反対は、大域制御であって、この場合、設計で星形または他のタイプの通信トポロジを介してさまざまな他のセルに命令を送信している側にコントローラセルが存在してよい。分散制御に伴う問題は、同期であると言ってよい。たとえば、大域制御セルは、命令をいつ送信すべきであるか。設計の一部は、位置の間の処理のパイプラインに起因してビデオフレーム内の別の位置と異なる位置を処理していてよい。分散処理を用いれば、設計範囲内の時間オフセットは、それほど重要ではないことがあり、考慮する必要がないことがある。
【0238】
任意の世界ビューシステムでの分散制御のある例は、一方はソース画像のための、他方は表示画像のための、２組のフレームバッファに見られることがある。一方のフレームから次のフレームに進む判定をライタ（ｗｒｉｔｅｒ）セルおよびリーダセルでローカルに取り扱ってよい。有利には、これは、いくつかの実施形態では、ソース画像バッファと表示画像バッファの間のフレーム同期を調整することなく達成されてよい。
【0239】
ＭＰＳシステム概観
以下の段落は、いくつかの実施形態による、ＨｙｐｅｒＸ（登録商標）アーキテクチャまたは別のタイプのマルチ・プロセッサ・システム（ｍｕｌｔｉ－ｐｒｏｃｅｓｓｏｒ ｓｙｓｔｅｍ、ＭＰＳ）などのＭＰＳのためのハードウェア構成に関する詳細を追加で補充する。
以下の段落は、いくつかの実施形態による、ＨｙｐｅｒＸ（登録商標）アーキテクチャまたは別のタイプのマルチ・プロセッサ・システム（ｍｕｌｔｉ－ｐｒｏｃｅｓｓｏｒ ｓｙｓｔｅｍ、ＭＰＳ）などのＭＰＳのためのハードウェア構成に関する詳細を追加で補充する。
【0240】
マルチ・プロセッサ・システム（ＭＰＳ）および関連する方法のさまざまな実施形態について記述する。マルチ・プロセッサ・システム（ＭＰＳ）は、複数の処理要素（ｐｒｏｃｅｓｓｉｎｇ ｅｌｅｍｅｎｔ、ＰＥ）を含むシステムとして規定されてよい。ＭＰＳは、ＰＥの間に散在した複数のメモリを有してよい、または代わりに単一の共用メモリを有してよい。本明細書で使用するとき、用語「処理要素」は、プロセッサもしくはＣＰＵ（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、中央処理装置）、マイクロプロセッサ、またはプロセッサコアを指す。ＭＰＳは、任意の数の２つ以上のＰＥを含んでよいが、いくつかのＭＰＳは、典型的には１つの汎用プロセッサ（ｇｅｎｅｒａｌ ｐｕｒｐｏｓｅ ｐｒｏｃｅｓｓｏｒ、ＧＰＰ）だけ、または数少ないＧＰＰを含む従来のコンピュータシステムよりもかなり多くのＰＥを含んでよいことが留意される。たとえば、いくつかのＭＰＳは、４、８、１６、３２、または６４のＰＥを含んでよい（他の例は、たとえば１２、数１００、または数１０００のＰＥさえ含む）。いくつかの実施形態では、大規模ＭＰＳに適したＰＥは、低電力消費の目的のためにＰＥが特殊な構成であるために、従来のコンピュータシステムが使用する汎用プロセッサよりもエネルギー効率がよいことがある。
【0241】
ＭＰＳはまた、ＰＥおよび／またはメモリを相互接続する相互接続ネットワーク（ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ ｎｅｔｗｏｒｋ、ＩＮ）を含んでよい。ＰＥおよびメモリは、円形の次元（たとえば、ループまたはリング）を含む１つ、２つ、３つ、またはより多くの次元で相互接続されてよい。より高次元のＭＰＳを、より低次元の製作媒体の上にマッピングすることができる。たとえば、４次元（ｆｏｕｒ ｄｉｍｅｎｓｉｏｎａｌ、４Ｄ）ハイパーキューブの形状を伴うＭＰＳを、ケイ素集積回路（ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ、ＩＣ）チップの３Ｄ積層の上に、または単一の２Ｄチップの上に、または計算ユニットの１Ｄラインの上にさえマッピングすることができる。また、低次元ＭＰＳをより高次元の媒体にマッピングすることができる。たとえば、計算ユニットの１Ｄラインを、ＩＣチップの２Ｄ平面の上にサーペンタイン形状で配置する、またはチップの３Ｄ積層の中に渦巻状に巻くことができる。ＭＰＳは、多数のタイプの計算ユニット、ならびにプロセッサおよびメモリの散在した配列を含んでよい。また、広い意味でＭＰＳに含まれるのは、ＭＰＳの階層配列またはネストされた配列であり、特に、さらにまたより深い階層構造を有してよい１つまたは複数のＭＰＳをＩＣチップが包含する、相互接続されたＩＣチップから構成されるＭＰＳである。
【0242】
本明細書で使用するとき、用語ＭＰＳは、比較的均質な１組のプロセッサだけではなく、汎用の異質の集合体と、いわゆる「プラットフォームＩＣ」チップ上に集積された専用プロセッサの両方に適用される。プラットフォームＩＣチップは、典型的には、共用メモリおよびおそらくはオン・チップ・ネットワークと相互接続された数少ないプロセッサから多くのプロセッサまで包含してよい。ＭＰＳと「プラットフォームＩＣ」チップの間に差があっても、なくてもよい。しかしながら、「プラットフォームＩＣ」チップは、特有の垂直市場で特有の技術的要件に対処するためにマーケティングされてよい。
【0243】
一般に、ＭＰＳ用メモリを階層の形に組織化してよく、高速メモリが最上部にあり、より遅いが、より大容量のメモリが階層の下の各段階にある。ＭＰＳでは、階層の最上部にあるサポートメモリ（ｓｕｐｐｏｒｔｉｎｇ ｍｅｍｏｒｙ、ＳＭ）を各ＰＥの近くに配置してよい。各サポートメモリを、命令だけまたはデータだけを保持するように専用化してよい。特定のＰＥ用サポートメモリは、そのＰＥ専用であってよい、または他のＰＥと共用されてよい。
【0244】
メモリ階層をさらに下ると、各ＰＥに近接するサポートメモリのビット容量よりも何倍も大きいビット容量を伴う半導体同期ダイナミック・ランダム・アクセス・メモリ（ｓｙｎｃｈｒｏｎｏｕｓ ｄｙｎａｍｉｃ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＳＤＲＡＭ）などの、より大規模な共用メモリが存在してよい。ＳＤＲＡＭを別個のＩＣチップ上に、またはＰＥおよびサポートメモリに由来するチップ上に配置して、ＳＤＲＡＭの製作を特殊化してよい。メモリ階層をさらに下ると、フラッシュメモリ、磁気ディスク、および光ディスクなどの他のタイプのメモリが存在してよい。
【0245】
ソフトウェアプログラムを用いてＭＰＳをプログラムして、特有の機能を達成してよい。ＭＰＳ内のＰＥの１つまたは複数により機能の各々を実行してよい。多くの場合、多数のプログラムをＭＰＳ上で互いに同時に実行してよい。プログラムは、一緒に実行され、互いに通信して、より複雑な機能を遂行してよい、または並列処理技法を採用することにより、より簡単な機能をより高速に遂行してよい。ＰＥ間のそのような調整を、本明細書では協同処理と呼ぶ。
【0246】
ＭＰＳは、データおよびコマンドの関連供給源が入力データおよびコマンドを提供することができ、かつ無視できるほど十分に短い待ち時間で結果を提供することができるよりも高速に入力データおよびコマンドを受け入れることができるほど十分に高速にアプリケーションまたはプログラムを実行してよい。そのようなアプリケーションを、リアルタイムで遅延のない動作または「リアル・タイム・アプリケーション」と呼ぶ。関連入力データ（またはコマンド）を、「リアル・タイム・データ」（または「リアル・タイム・コマンド」）と呼ぶことがある。たとえば、ＭＰＳは、入力信号を介してリアル・タイム・データを受信してよい。アプリケーション、プログラム、または機能のうち１つまたは複数は、入力信号を処理し、場合によっては１つまたは複数のプログラムに基づき、修正された、または追加のリアル・タイム・データを伴う出力信号を作り出してよい。
【0247】
図３０－ＭＰＳのブロック図および外観
図３０は、マルチ・プロセッサ・システム（ＭＰＳ）の一実施形態を例示する構成図である。例示する実施形態では、ＭＰＳ１０は、複数の処理要素（ＰＥ）と、データおよび命令を互いに通信するように連結された、動的に構成可能なコミュニケータまたは動的に構成可能な通信要素と呼ばれることもある複数のデータ・メモリ・ルータ（ｄａｔａ ｍｅｍｏｒｙ ｒｏｕｔｅｒ、ＤＭＲ）とを含む。本明細書で使用するとき、ＰＥはまた、ＰＥノードと呼ばれることもあり、ＤＭＲはまた、ＤＭＲノードと呼ばれることもある。
図３０は、マルチ・プロセッサ・システム（ＭＰＳ）の一実施形態を例示する構成図である。例示する実施形態では、ＭＰＳ１０は、複数の処理要素（ＰＥ）と、データおよび命令を互いに通信するように連結された、動的に構成可能なコミュニケータまたは動的に構成可能な通信要素と呼ばれることもある複数のデータ・メモリ・ルータ（ｄａｔａ ｍｅｍｏｒｙ ｒｏｕｔｅｒ、ＤＭＲ）とを含む。本明細書で使用するとき、ＰＥはまた、ＰＥノードと呼ばれることもあり、ＤＭＲはまた、ＤＭＲノードと呼ばれることもある。
【0248】
処理システム（ＭＰＳ）１０は、現在はＧＰＭＣ、ＤＳＰ、ＦＰＧＡ、またはＡＳＩＣを使用するさまざまなシステムおよびアプリケーションのいずれでも使用されてよい。したがって、たとえば、処理システム１０は、さまざまなタイプのコンピュータシステム、または計算を必要とする他の機器のいずれでも使用されてよい。企図される一実施形態では、デジタルビデオ表示システムで信号処理機器として処理システム１０を使用する。
【0249】
一実施形態では、ＰＥは、データを操作するように構成された１つまたは複数の算術論理演算装置（ａｒｉｔｈｍｅｔｉｃ－ｌｏｇｉｃ ｕｎｉｔ、ＡＬＵ）、ＡＬＵを制御するように構成された１つまたは複数の命令処理ユニット（ｉｎｓｔｒｕｃｔｉｏｎ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＩＰＵ）、命令またはデータを保持するように構成された１つまたは複数のメモリ、ならびにさまざまな種類のマルチプレクサおよび復号器を含んでよい。そのような実施形態は、いくつかのポート（「プロセッサポート」）を含んでよく、ＤＭＲに接続するように構成されてよいポートがあれば、他のＰＥに接続するように構成されてよいポートもある。
【0250】
一実施形態では、ＤＭＲは、データおよび命令を保持するように構成された１つまたは複数のランダム・アクセス・メモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＲＡＭ）と、構成可能なコントローラと、クロスバスイッチなどのネットワークスイッチと、レジスタと、マルチプレクサとを含んでよい。そのような実施形態は、複数のポートを含んでよく、ＰＥに接続するように構成されてよいポート（本明細書ではＰＥタイプのポートと呼ばれる）があれば、ＤＭＲに接続するように構成されてよいポート（本明細書ではＤＭＲタイプのポートと呼ばれる）もある。任意の所与のポートでは、ＤＭＲとの間で接続するために構成されていようがＰＥとの間で接続するように構成されていようが、特定のクロックサイクルでそのような所与のポートを通して転送可能なデータの量は、さまざまな実施形態で変わってよいことが留意される。たとえば、一実施形態では、クロックサイクルあたり１ワードのデータを転送するように所与のポートを構成してよいのに対して、別の実施形態では、クロックサイクルあたり多数のワードのデータを転送するように所与のポートを構成してよい。さらに別の実施形態では、所与のポートは、時分割多重などの技法を採用して、多数のクロックサイクルにわたり１ワードのデータを転送してよく、それにより、ポートを備える物理接続の数は低減される。
【0251】
ＭＰＳ１０の一実施形態では、各ＰＥは、命令用に確保された小規模ローカルメモリを含んでよく、非常に少ないローカルデータ記憶領域を含んでよい。そのような実施形態では、各ＰＥに隣接するＤＭＲは、所与のＰＥにオペランドを提供するように構成されてよい。特定の実施形態では、多くのＰＥ命令については、所与のＰＥは、１クロックサイクル内に、隣接するＤＭＲからオペランドを読み出し、ＡＬＵ動作を実行し、所与の隣接するＤＭＲにＡＬＵの結果を記憶してよい。それにより、１つのＰＥから得られるＡＬＵの結果は、実行直後のクロックサイクルでいくつかの他のＰＥに利用可能になってよい。この方式で結果を作り出すことにより、隣接するＰＥの実行が密接に調和可能に、または「密結合」可能になってよい。
【0252】
本明細書で使用するとき、所与のＤＭＲまたはＰＥの観点から、隣接するＤＭＲまたはＰＥは、特定の待ち時間の範囲内に所与のＤＭＲまたはＰＥからアクセスすることができるＤＭＲまたはＰＥを指す。いくつかの実施形態では、隣接関係の範囲を規定する待ち時間は、たとえばクロック速度などの要因に応じて変動してよい。さらに、いくつかの実施形態では、多数の隣接度を規定してよく、隣接度は、異なるアクセス待ち時間に対応してよい。たとえば、一実施形態では、「最も近い隣接」を、データを要求する同じクロックサイクルの間にデータを供給することができる機器と規定してよく、「次に最も近い隣接」を、データ要求後の１クロックサイクル以内にデータを供給することができる機器と規定してよいなどである。他の実施形態では、他の指標を使用して、隣接関係を定量化してよいことが企図される。
【0253】
所与のＭＰＳの実施形態では、いくつかのＤＭＲおよびＰＥは、他のＤＭＲおよびＰＥに論理的に近接してよい。本明細書で使用するとき、「論理的に近接した」は、一方のＤＭＲと別のＤＭＲ、または一方のＤＭＲと一方のＰＥなど、２つの機器間の関係を指し、その結果、一方の機器の１つまたは複数のポートは、介在するＤＭＲまたはＰＥを通過することなく他方の機器の対応するポートに直接接続される。さらに、所与のＭＰＳの実施形態では、いくつかのＤＭＲおよびＰＥは、他のＤＭＲおよびＰＥに物理的に近接してよい。本明細書で使用するとき、「物理的に近接した」は、一方のＤＭＲと別のＤＭＲ、または一方のＤＭＲと一方のＰＥなど、２つの機器間の関係を指し、その結果、他のどのＤＭＲもＰＥも、２つの機器の間に物理的に配置されない。
【0254】
いくつかのＭＰＳの実施形態では、論理的および／または物理的に近接するＤＭＲおよびＰＥなどの機器はまた、隣接している、または隣接機器である。しかしながら、いくつかの実施形態では、所与の機器間の論理的近接および／または物理的近接は、所与の機器間の隣接関係または特定の程度の隣接関係を必然的に伴うわけではないことが留意される。たとえば、一実施形態では、一方のＤＭＲは、かなり距離を離して配置した別のＤＭＲに直接接続されてよい。そのような対は、論理的に近接しているが、物理的に近接しておらず、一方のＤＭＲから他方のＤＭＲへの信号伝播時間は、大きすぎて、隣接の待ち時間要件を満足させることができないことがある。同様に、一実施形態では、一方のＤＭＲは、別のＤＭＲに物理的に近接しているが、別のＤＭＲに直接接続されず、したがって、別のＤＭＲに論理的に近接していないことがある。一方のＤＭＲから他方のＤＭＲへのアクセスは、１つまたは複数の中間ノードを横断し、結果として得られる通過遅延は、大きすぎて、隣接の待ち時間要件を満足させることができないことがある。
【0255】
ＭＰＳ１０の所与の実施形態の技術および実装に応じて、ＤＭＲの複数のポートの特有の数だけではなくＤＭＲメモリのサイズも、全体の所望の実行速度およびＤＭＲのサイズと均衡をとってよい。たとえば、ＤＭＲの一実施形態は、４つのＰＥタイプのポート、４つのＤＭＲタイプのポート、および４Ｋワードのメモリを含んでよい。そのようなＤＭＲの実装形態は、直接メモリアクセス（ｄｉｒｅｃｔ ｍｅｍｏｒｙ ａｃｃｅｓｓ、ＤＭＡ）の仕組みを提供するように構成されてよい。ＤＭＡの仕組みは、ＰＥが結果を計算している間、所与のＤＭＲが他のＤＭＲとの間で、またはＭＰＳ１０の外部の場所との間で、データを効率的にコピーできるようにしてよい。
【0256】
ＭＰＳ１０の一実施形態では、いくつかの異なる方法の１つで、ＤＭＲ間でデータおよび命令を転送してよい。ＭＰＳ１０内のすべてのメモリに直列バスを提供してよく、そのようなバスを使用して、外部メモリからＭＰＳ１０を初期化してよい、またはＭＰＳデータ構造の試験をサポートしてよい。短距離転送については、所与のＰＥをプログラムして、所与のＰＥの隣接ＤＭＲ間でデータを直接移動させてよい。より長い距離にわたりデータまたは命令を転送するために、ＤＭＲのネットワーク内で通信経路を動的に作成し、消滅させてよい。
【0257】
そのようなより長い距離をデータ転送するために、ＭＰＳ１０内部で相互接続されたＤＭＲのネットワークは、通信経路用切替えルーティング機構（ｓｗｉｔｃｈｅｄ ｒｏｕｔｉｎｇ ｆａｂｒｉｃ、ＳＲＦ）を構成してよい。そのような実施形態では、ＳＲＦ内の通信経路を管理するための方法が少なくとも２つ存在してよい。第１の方法は、大域プログラミングによるものであり、そこでは、パスは、ソフトウェア制御により（たとえば、人間のプログラマにより、またはルーティング能力を有するコンパイラにより）選択されてよく、命令は、クロスバを適切にプログラムするＤＭＲ構成コントローラの中に符号化されてよい。経路を作成するために、その経路に沿ったあらゆるＤＭＲは、特定のルーティング機能を用いて明示的にプログラムされてよい。経路が頻繁に作成され、消滅させられる動的環境では、多数のクロスバ構成コードを必要とすることがあり、さらにまた、コードの記憶領域は、潜在的に制限されたＤＭＲのＲＡＭ資源を消費することがある。
【0258】
通信経路を管理するための第２の方法は、「ワームホールルーティング」と呼ばれる。ワームホールルーティングを実装するために、各ＤＭＲは、１組のステアリング（ｓｔｅｅｒｉｎｇ）機能と、ＳＲＦを通して、メッセージと呼ばれるワードのシーケンスの進行を停止および再開させる仕組みとを含んでよい。ステアリング機能は、すべての通信経路により共通に使用され、再利用されてよいので、ＤＭＲのＲＡＭを占有してよい構成コードの量は、上述の大域プログラミング法よりもはるかに少なくてよい。ワームホールルーティング法では、ソフトウェア制御を依然として使用して、経路が使用する特定のリンクを選択するが、経路作成（本明細書ではセットアップとも呼ばれる）および消滅／リンク解放（本明細書では解体（ｔｅａｒｄｏｗｎ）とも呼ばれる）の処理は、ソフトウェアの介在を最小にしてハードウェアの形で実装されてよい。
【0259】
経路上でデータワードが損失する可能性を回避するために、ＭＰＳ１０のある実施形態は、経路に沿って受信側と送信側の間でフロー制御を実装してよい。フロー制御は、伝送側の対応する受信側がデータをもはや受信することができない場合に伝送側を停止させてよく、かつ伝送側の対応する受信側がデータを受信する準備ができたときに伝送側を再開してよい仕組みを指す。経路上でのデータの流れを停止および再開させることは、ワームホールルーティングでメッセージの進行を停止および再開させることと多くの類似点があるので、一体化した方式で両者を組み合わせてよい。
【0260】
一実施形態では、ＭＰＳ１０は、均一なアレイの形で一緒に接続された、同一であってよい複数のＰＥおよび同一であってよい複数のＤＭＲを含んでよい。均一なアレイでは、ＰＥの大多数は、同一であってよく、ＰＥの大多数の各々は、ＭＲへの接続を同数有してよい。また、均一なアレイでは、ＤＭＲの大多数は、同一であってよく、ＤＭＲの大多数の各々は、他のＤＭＲおよびＰＥへの接続を同数有してよい。ＰＥおよびＤＭＲは、ＭＰＳの一実装形態では、実質的に均質な方式で散在してよい。本明細書で使用するとき、実質的に均質な散在は、ＤＭＲに対するＰＥの比がアレイの副領域の大部分にわたり不変な配列を指す。
【0261】
実質的に均質な方式で配列された均一なアレイは、予測可能な相互接続パターンを提供する、およびソフトウェアモジュールをアレイ全体にわたって再利用可能にするなど、ある種の有利な特性を有してよい。一実施形態では、均一なアレイは、ＰＥおよびＤＭＲの少数のインスタンスを設計および試験することを可能にすることがある。この場合、ＤＭＲおよびＰＥを備えるユニットを製作し、次いでそのようなユニットを複数回反復する、または「タイルのように並べる」ことにより、システムを組み立ててよい。そのような取り組み方法は、共通のシステム要素を再利用することによって設計および試験の費用を安くすることがある。
【0262】
ＰＥおよびＤＭＲの構成可能な性質は、多種多様の非均一な挙動を、物理的に均一なアレイ上で行うようにプログラムできるようにすることがあることもまた留意される。しかしながら、ある代替実施形態ではさらにまた、規則的もしくは不規則なアレイの形に、またはランダムな方法でさえ接続されてよい非均一なＤＭＲおよびＰＥのユニットを用いてＭＰＳ１０を形成してもよい。一実施形態では、たとえば集積回路（ＩＣ）、セラミック基板、またはプリント回路基板（ｐｒｉｎｔｅｄ ｃｉｒｃｕｉｔ ｂｏａｒｄ、ＰＣＢ）上に回路トレースとしてＰＥおよびＤＭＲの相互接続を実装してよい。しかしながら、代替実施形態では、そのような相互接続は、たとえば電磁エネルギー（すなわち、無線または光のエネルギー）用導波管、無線（すなわち、導波管なし）エネルギー、粒子（電子ビームなど）、または分子上の電位など、さまざまな小型通信リンクのいずれであってもよい。
【0263】
単一集積回路上にＭＰＳ１０を実装してよい。一実施形態では、複数のＭＰＳ集積回路を組み合わせて、より大きなシステムを作り出してよい。ＭＰＳ１０の所与の実施形態は、ケイ素集積回路（Ｓｉ－ＩＣ）技術を使用して実装されてよく、そのような技術の特有の特性の原因となるさまざまな特徴を採用してよい。たとえば、Ｓｉ－ＩＣチップ上の回路を、薄い平面に閉じ込めてよい。それに応じて、ＭＰＳ１０の所与の実施形態は、図３０に例示するような、ＰＥおよびＤＭＲの２次元アレイを採用してよい。しかしながら、ＰＥおよびＤＭＲの異なる配列を含むＭＰＳの代替実施形態が企図される。
【0264】
さらに、Ｓｉ－ＩＣ上の利用可能な配線密度は、そのようなチップの間よりもはるかに高いことがあり、各チップは、チップ上の信号およびチップ外の信号とインタフェースをとる周辺の特殊な入力／出力（Ｉ／Ｏ）回路を有してよい。それに応じて、ＭＰＳ１０の所与の実施形態は、チップのコア内にＰＥおよびＤＭＲの均一なアレイと、チップの周辺に沿った、修正されたＰＥ／ＤＭＲユニットとから構成される少し非均一なアレイを採用してよい。しかしながら、異なる配列、および均一なＰＥ／ＤＭＲユニットと修正されたＰＥ／ＤＭＲユニットの組合せを含むＭＰＳの代替実施形態が企図される。
【0265】
また、Ｓｉ－ＩＣ回路が遂行する計算動作は、熱を生じさせることがあり、その熱は、ＩＣパッケージングにより取り除かれてよい。ＩＣパッケージングが大きくなることにより、追加空間を必要とすることがあり、ＩＣパッケージングを通した相互作用およびＩＣパッケージングの周りの相互接続は、パス長に比例する遅延を招くことがある。したがって、上記で指摘したように、非常に大規模なＭＰＳは、多数のチップを相互接続することにより構築されてよい。そのような多数のチップのＭＰＳの実施形態のプログラミングは、チップ間信号遅延がチップ内信号遅延よりもはるかに大きくなることを考慮してよい。
【0266】
所与のＳｉ－ＩＣのＭＰＳ１０の実装形態では、単一チップ上に実装してよいＰＥおよびＤＭＲの最大数は、所与のＳｉ－ＩＣ技術で可能な小型化、および各ＰＥおよびＤＭＲの複雑性により決定されてよい。そのようなＭＰＳの実装形態では、ＰＥおよびＤＭＲの回路の複雑性は、目標とするレベルの計算スループットの達成を条件として最小化されてよい。そのように最小化されたＰＥおよびＤＭＲを、本明細書では簡素化されたと呼ぶことがある。ＭＰＳ１０の一実施形態では、ＰＥに関して目標とするスループットのレベルは、同じＳｉ－ＩＣ技術で作られた最良のデジタル・シグナル・プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ、ＤＳＰ）の算術実行ユニットのレベルに匹敵してよい。しかしながら、目標とするＰＥスループットに関する代替基準を使用してよい他のＭＰＳの実施形態が企図される。
【0267】
いくつかの実施形態では、ＭＰＳ１０は、ＤＳＰおよびＦＰＧＡのアーキテクチャが有する最良の特徴を採用してよい。ＤＳＰと同様に、ＭＰＳ１０は、多数の処理ユニットおよびオン・チップ・メモリを伴う、プログラム可能なチップであってよい。しかしながら、ＤＳＰと比べて、ＭＰＳ処理ユニットは簡素化されてよく、さらに多くのＭＰＳ処理ユニットが存在してよく、ＭＰＳ処理ユニットは、ＭＰＳ処理ユニット間のデータ移動の帯域幅だけではなく、チップ上およびチップ外のデータ移動の帯域幅も最大にする新規な方法で相互接続されてよい。ＤＳＰよりも多くの処理ユニットを有することにより、ＭＰＳ１０は、単位時間あたりより多くの積算を行うことができるようになり、簡素化された処理ユニットは、エネルギー使用を最小にすることがある。内部並列処理を有する多くのＤＳＰは、バス指向アーキテクチャであってよい。いくつかの実施形態では、ＭＰＳ１０は、バスを含むのではなく、むしろバス指向アーキテクチャよりも著しく高い全帯域幅を提供してよいＳＲＦ内に埋め込まれたＤＭＲ内などに、隣接する共有ローカルメモリを含んでよい。
【0268】
ＦＰＧＡの取り組み方法と比較して、いくつかのＭＰＳの実施形態は、より粗い粒状であってよい。たとえば、ＭＰＳの一実施形態では、演算は自然な語長（たとえば、１６ビット）を有してよく、計算は、自然な語長の倍数のデータを使用して遂行する場合、最も効率的であってよい。いくつかのＭＰＳの実施形態では、ＰＥおよびＤＭＲは、ＦＰＧＡで実現される等価な構造より高密度あってよく、その結果、より短い平均配線長、より低い配線容量、およびより少ないエネルギー使用がもたらされることがある。ＦＰＧＡの実装とは対照的に、いくつかのＭＰＳの実施形態では、ＭＰＳ内のあらゆるＡＬＵは、プロセッサ（すなわち、ＰＥ）の一部であってよく、それにより、オペランドのフェッチ、およびＤＭＲ内の周囲の高速メモリへ結果を書き戻すのが容易になることがある。ＡＬＵに関するタイミングおよびクロックスキューの問題、フェッチ動作、および書き戻し動作は、ＩＣチップを設計する間に一度解決すればよく、ＦＰＧＡの実装で特有なように、新しいアプリケーションごとに再度解決する必要はない。
【0269】
ＭＰＳのトポロジおよび通信
図３０に例示するＭＰＳ１０は、図示するように、ＰＥ間にＤＭＲを散在させることにより、高速メモリへの十分な接続をＰＥに供給してよい。そのような配列は、分離した（すなわち、散在していない）配列に比べて所与のＰＥがＤＭＲ内のメモリにアクセスするために必要とされる時間を低減することがあり、本明細書では散在グリッド配列と呼ばれることがある。図３０の実施形態では、ＰＥ対ＤＭＲの比はおおよそ１：１である。しかしながら、ＰＥ対ＤＭＲの異なる比を含んでよい、ＭＰＳの他の実施形態が企図される。
図３０に例示するＭＰＳ１０は、図示するように、ＰＥ間にＤＭＲを散在させることにより、高速メモリへの十分な接続をＰＥに供給してよい。そのような配列は、分離した（すなわち、散在していない）配列に比べて所与のＰＥがＤＭＲ内のメモリにアクセスするために必要とされる時間を低減することがあり、本明細書では散在グリッド配列と呼ばれることがある。図３０の実施形態では、ＰＥ対ＤＭＲの比はおおよそ１：１である。しかしながら、ＰＥ対ＤＭＲの異なる比を含んでよい、ＭＰＳの他の実施形態が企図される。
【0270】
異なるタイプおよび数の接続を使用する多くの可能な接続方式が存在してよいので、ＤＭＲとＰＥの間の接続を図３０に明示的に示していない。
【0271】
図３１－ＭＰＳ接続方式
図３１は、ＭＰＳ接続方式の一実施形態を例示する構成図である。ＭＰＳ接続方式２０は、複数のＤＭＲおよびＰＥを含み、図３０のＭＰＳの一部分を例証するものであってよい。ＭＰＳ接続方式２０では、各ＰＥは、４つの隣接ＤＭＲに接続され、一方では、各ＤＭＲは、４つの隣接ＰＥだけではなく４つの隣接ＤＭＲにも接続される。したがって、ＭＰＳ接続方式２０は、上記で論じたＰｌａｎａｒＡ接続方式を例証するものであってよい。
図３１は、ＭＰＳ接続方式の一実施形態を例示する構成図である。ＭＰＳ接続方式２０は、複数のＤＭＲおよびＰＥを含み、図３０のＭＰＳの一部分を例証するものであってよい。ＭＰＳ接続方式２０では、各ＰＥは、４つの隣接ＤＭＲに接続され、一方では、各ＤＭＲは、４つの隣接ＰＥだけではなく４つの隣接ＤＭＲにも接続される。したがって、ＭＰＳ接続方式２０は、上記で論じたＰｌａｎａｒＡ接続方式を例証するものであってよい。
【0272】
ＭＰＳ接続方式２０で広帯域幅ポートをサポートするために、ポート間の接続（ＰＥからＤＭＲまたはＤＭＲからＤＭＲ）は、短い（すなわち、隣接に限定された）ワード幅であってよく、接続のデータ部分の電気伝導体（線）の数は、ＡＬＵオペランドで使用するビットの数と同じであってよいことを意味する。ＰＥからＤＭＲへの接続は、アドレス線を含んでよい。ＤＭＲからＤＭＲへの接続は、アドレス線を必ずしも有していなくてよいが、フロー制御用の線を有してよい。
【0273】
ＰＥノードを簡単に保つことにより、大規模アレイ（たとえば、ＭＰＳの一実施形態では、１６行×１６列＝２５６ＰＥ）を適度の費用で単一のＶＬＳＩ ＩＣ上に載せてよい。適切なＶＬＳＩ技術は、ケイ素または他の半導体でバイポーラトランジスタありまたはなしの相補型金属酸化膜半導体（ｃｏｍｐｌｅｍｅｎｔａｒｙ ｍｅｔａｌ－ｏｘｉｄｅ ｓｅｍｉｃｏｎｄｕｃｔｏｒ、ＣＭＯＳ）電界効果トランジスタを含んでよいが、それに限定されない。
【0274】
いくつかのＭＰＳの実施形態では、ノード間通信は、プログラマの制御を受けてよい。ＭＰＳでは、各ＰＥは、隣接するＤＭＲとデータ／命令を通信し、任意選択で、続けてそれらのＤＭＲを通して他のＤＭＲおよびＰＥに伝達してよい。これは、短距離にわたり少量のデータを伝達するのに非常に効果的である。しかしながら、より大規模なデータブロックまたはより長い距離については、ＤＭＡエンジンを使用してデータを移動させることは、より効率的であり、したがって、ＡＬＵ演算を遂行できるようにＰＥを解放する。
【0275】
より長い距離のブロック移動については、いくつかのＭＰＳの実施形態は、ＰＥを関与させることなくＤＭＲ間のメモリ間転送のための手段を提供してよい。ＰＥは、隣接ＤＭＲ内のＤＭＲタイプのポートに、そのようなポートに関連する特殊なＳＭアドレスを通して間接的にアクセスしてよい。これにより、ＰＥは、メッセージを送信するための新しい経路を作成し、後でそのような経路を破棄できるようになってよい、または代わりにメッセージを受信できるようになってよい。ＰＥはまた、転送すべきデータのブロックを隣接ＤＭＲ内のＳＭバッファに保存し、次いでＤＭＡ動作をそのような動作に関連する特殊なＳＭアドレスを通して開始するよう隣接ＤＭＲに指示してよい。これにより、ＰＥは、隣接ＤＭＲがデータのＤＭＡ転送を調和させながら他のタスクに進むことができるようになってよい。
【0276】
ＭＰＳのさまざまな実施形態は、有用なアルゴリズムを実行するための有利な環境を提供してよい。（たとえば、画像データを分析するための）関心のあるアルゴリズムをＡＬＵの流れ図の中に分割してよい。多数のフィードバックパス／フィードフォワードパスを含む木、格子、またはどんな任意のネットワークとしてもＭＰＳアレイの上に各流れ図をマッピングしてよい。いくつかのＰＥおよびＤＭＲを組み合わせることにより、１つのＡＬＵの有限な精度を拡張して、マルチワードの精度の結果を得てよい。流れ図をＭＰＳにマッピングするとき、ノード間の距離に比例するＰＥ／ＤＭＲノード間通信遅延が生じることがある。また、マッピングは、通信キューが大きい場合、または再構成が頻繁にある場合、各ノードでメモリをより多く必要とすることがある。通信遅延、キューイング、および再構成を考慮にいれてよい注意深いプログラミングにより、これらの要因を補償してよい。
【0277】
シストリック（ｓｙｓｔｏｌｉｃ）アルゴリズムは、ＭＰＳのさまざまな実施形態に特に効果的にマッピングしてよいアルゴリズムのクラスを表す。シストリックアルゴリズムは、行列演算、画像処理、および信号処理で多様な用途のために開発されてきた。シストリックアルゴリズムでは、多くのプロセッサは、同期して協同して困難な計算を遂行してよい。理想的アルゴリズム実装では、各プロセッサは、アルゴリズを必要とする限り何度も何度も同じ動作（または小さな動作ループ）を遂行してよく、データは、データワードの生産および消費を均衡させて、隣接する接続によりプロセッサのネットワークを通して流れてよい。次いで、生産された各中間結果データワードが後続の計算により直ちに消費される場合、必要とされるメモリ量を最小にしてよい。シストリックアルゴリズムの利点は、簡素化されたプロセッサを使用し、メモリ要件を最小にし、標準的で費用がかからないＶＬＳＩ技術を使用して高い算術演算レートを達成する能力を含んでよい。
【0278】
ＭＰＳの実施形態は、チップあたり多くのプロセッサを、ならびにＳＩＭＤシステムおよび分散ＭＩＭＤシステムなどの他のクラスのシステムの動作をエミュレートするように構成されてよい総体的ＭＩＭＤアーキテクチャを有してよい。いくつかの実施形態では、ＭＰＳは、チップの異なる部位で異なるアルゴリズムを同時に作動させてよい。また、電力を節約するために、いくつかの実施形態では、プログラマは、少なくともいくつかのＰＥおよびＤＭＲへのクロックを選択的に有効にし、無効にすることができる。したがって、未使用のＰＥおよびＤＭＲを無効にしてよい。
【0279】
ＰＥ／ＤＭＲの機構
図３２は、ＭＰＳ機構の一実施形態を例示するより詳細な図である。図３２では、各ＰＥは、メモリリクエストおよびメッセージを伝達してよい４つのＤＭＲにより取り囲まれている。各ＤＭＲは、チップＩ／Ｏポートに近接してよい、機構の縁部近くにある場所を除き、４つの他のＤＭＲにより取り囲まれている。各ＤＭＲは、隣接するＤＭＲまたはチップＩ／Ｏポートと通信して、通信経路をセットアップして、前記経路上でメッセージを送信／受信してよい。
図３２は、ＭＰＳ機構の一実施形態を例示するより詳細な図である。図３２では、各ＰＥは、メモリリクエストおよびメッセージを伝達してよい４つのＤＭＲにより取り囲まれている。各ＤＭＲは、チップＩ／Ｏポートに近接してよい、機構の縁部近くにある場所を除き、４つの他のＤＭＲにより取り囲まれている。各ＤＭＲは、隣接するＤＭＲまたはチップＩ／Ｏポートと通信して、通信経路をセットアップして、前記経路上でメッセージを送信／受信してよい。
【0280】
ＭＰＳの動作
図３３は、図３２のアーキテクチャ例と調和する９×９のＤＭＲアレイ（円形）と共に均一に散在した８×８のＰＥアレイ（正方形）から構成される、ある例のＭＰＳを例示する。ＰＥに割り当てるタスクの中にプログラムをコンパイルしてよい。第１の例のプログラムを、タスクＩＤ＝６２でコンパイルして、アレイの左上隅にある特有のＰＥに割り当てた。変数（ｕ，ｖ，ｗ）は、プログラム・ソース・コード内で宣言した通信変数であり、近接するＤＭＲ内の特有のメモリアドレスに割り当てられ、ｕおよびｖは、Ｉ／Ｏポート用バッファであり、ｗは、タスクＩＤ＝６２の関連するＤＭＲとのチップ上でのネットワーク通信用バッファである。第２の例のプログラムを、タスクＩＤ＝７１でコンパイルして、アレイの内部にある特有のＰＥに割り当てた。変数ｘは、宣言された通信変数であり、図示するＤＭＲに割り当てられる。変数ｘに関連する通信経路は、タスクＩＤ＝７１の割り当てられたＤＭＲから他のＤＭＲを経由して最上部の行にあるＩ／Ｏポートまで伸びている。図示するように、２つの例のプログラムは、互いに通信しないが、タスク７１に別の通信変数を追加し、タスク７１のＤＭＲとタスク６２に近接するＤＭＲ内の変数ｗとの間の経路を追加することにより、容易に通信するようにできる。
図３３は、図３２のアーキテクチャ例と調和する９×９のＤＭＲアレイ（円形）と共に均一に散在した８×８のＰＥアレイ（正方形）から構成される、ある例のＭＰＳを例示する。ＰＥに割り当てるタスクの中にプログラムをコンパイルしてよい。第１の例のプログラムを、タスクＩＤ＝６２でコンパイルして、アレイの左上隅にある特有のＰＥに割り当てた。変数（ｕ，ｖ，ｗ）は、プログラム・ソース・コード内で宣言した通信変数であり、近接するＤＭＲ内の特有のメモリアドレスに割り当てられ、ｕおよびｖは、Ｉ／Ｏポート用バッファであり、ｗは、タスクＩＤ＝６２の関連するＤＭＲとのチップ上でのネットワーク通信用バッファである。第２の例のプログラムを、タスクＩＤ＝７１でコンパイルして、アレイの内部にある特有のＰＥに割り当てた。変数ｘは、宣言された通信変数であり、図示するＤＭＲに割り当てられる。変数ｘに関連する通信経路は、タスクＩＤ＝７１の割り当てられたＤＭＲから他のＤＭＲを経由して最上部の行にあるＩ／Ｏポートまで伸びている。図示するように、２つの例のプログラムは、互いに通信しないが、タスク７１に別の通信変数を追加し、タスク７１のＤＭＲとタスク６２に近接するＤＭＲ内の変数ｗとの間の経路を追加することにより、容易に通信するようにできる。
【0281】
本開示の実施形態は、さまざまな形態のいずれかで実現されてよい。たとえば、いくつかの実施形態では、本発明は、コンピュータ実装方法、コンピュータ可読記憶媒体、またはコンピュータシステムとして実現されてよい。他の実施形態では、ＡＳＩＣなどの１つまたは複数のカスタム設計ハードウェア素子を使用して本発明を実現してよい。他の実施形態では、ＦＰＧＡなどの１つまたは複数のプログラム可能ハードウェア要素を使用して本発明を実現してよい。
【0282】
いくつかの実施形態では、非一時的コンピュータ可読媒体は、プログラム命令および／またはデータを記憶するように構成されてよく、この場合、プログラム命令は、コンピュータシステムにより実行された場合、方法を、たとえば、本明細書に記述する方法の実施形態のいずれか、または本明細書に記述する方法の実施形態の任意の組合せ、または本明細書に記述する方法の実施形態のいずれかからなる任意のサブセット、またはそのようなサブセットの任意の組合せをコンピュータシステムに遂行させる。
【0283】
いくつかの実施形態では、コンピューティング機器は、プロセッサ（または１組のプロセッサ）および記憶媒体を含むように構成されてよく、この場合、記憶媒体は、プログラム命令を記憶し、この場合、プロセッサは、記憶媒体からプログラム命令を読み出し、実行するように構成され、この場合、プログラム命令は、本明細書に記述するさまざまな方法の実施形態のいずれか（または本明細書に記述する方法の実施形態の任意の組合せ、または本明細書に記述する方法の実施形態のいずれかからなる任意のサブセット、またはそのようなサブセットの任意の組合せ）を実装するように実行可能である。機器は、さまざまな形態のいずれかで実現されてよい。
【0284】
具体的実施形態について上記に記述してきたが、これらの実施形態は、特定の特徴に関して単一の実施形態だけについて記述している場合でさえ、本開示の範囲を限定することを意図するものではない。本開示で提供する特徴の例は、特に指定のない限り、制限的ではなく、例示的であることが意図される。上記の記述は、本開示の恩恵を受ける当業者に明らかなように、そのような代替形態、修正形態、および均等物を包含することが意図される。
【0285】
本開示の範囲は、（明示的に、または暗示的に）本明細書で開示する任意の特徴もしくは特徴の組合せ、またはそれらの任意の一般化を、それが本明細書で対処する問題のいずれか、もしくはすべてを軽減してもしなくても含む。したがって、本出願（またはその優先権を主張する出願）の手続き中に、任意のそのような特徴の組合せに対して、新しい請求項を考案してもよい。詳細には、添付の特許請求の範囲を参照すると、従属クレームからの特徴は、独立クレームの特徴と組み合わせられてよく、それぞれの独立クレームに由来する特徴は、添付の特許請求の範囲に列挙された具体的組合せだけではなく、任意の適切な手法で組み合わせられてよい。
【図1】
【図2A】
【図2B】
【図2C】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8A】
【図8B】
【図9】
【図10】
【図11】
【図12】
【図13A】
【図13B】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】