知財求人 - 知財ポータルサイト「IP Force」
特許7399879ほとんど無制限のディテールを有するシーンを処理するためのコーデック
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-12-08
(45)【発行日】2023-12-18
(54)【発明の名称】ほとんど無制限のディテールを有するシーンを処理するためのコーデック
(51)【国際特許分類】
G06T 9/40 20060101AFI20231211BHJP
G06T 19/00 20110101ALI20231211BHJP
【ＦＩ】
G06T9/40
G06T19/00 F
【請求項の数】
21
(21)【出願番号】P 2020561082
(86)(22)【出願日】2019-05-02
(65)【公表番号】
(43)【公表日】2021-09-02
(86)【国際出願番号】 US2019030483
(87)【国際公開番号】W WO2019213450
(87)【国際公開日】2019-11-07
【審査請求日】2022-05-02
(31)【優先権主張番号】62/665,806
(32)【優先日】2018-05-02
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】518346971
【氏名又は名称】クイッディエント・エルエルシー
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(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】
前記追加的なデータが前記データの一部のより分解能の高い表現、異なる視点からの前記シーンの少なくとも一部を表すデータ、または異なる視線で同じ視点からの前記シーンの少なくとも一部を表すデータの１つまたは複数を表す、請求項１１に記載の方法。
【請求項19】
前記要求が送信されたデータの１つまたは複数の特徴を特定し、前記１つまたは複数の特徴に応答した処理を行うことを含み、前記送信されたデータが前記処理の結果の少なくとも一部を含む、請求項１１に記載の方法。
【請求項20】
前記１つまたは複数の特徴が前記シーンに関連付けられたライティング条件を含み、前記処理が前記ライティング条件に応じて前記データを修正することを含む、請求項１９に記載の方法。
【請求項21】
記憶された命令を有するコンピュータ可読記憶媒体であって、前記命令が、コンピュータシステムの少なくとも１つのプロセッサによって実行されると、前記コンピュータシステムに、請求項１１から２０のいずれか一項に記載の方法を実行させる、コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、内容全体が参照により本明細書に組み込まれている、2018年5月2日に出願した米国仮特許出願第62/665,806号の優先権の利益を主張するものである。本出願は、2017年4月11日に出願された国際特許出願第PCT/US2017/026994号に関係しており、内容全体が本明細書に組み込まれている。
本出願は、内容全体が参照により本明細書に組み込まれている、2018年5月2日に出願した米国仮特許出願第62/665,806号の優先権の利益を主張するものである。本出願は、2017年4月11日に出願された国際特許出願第PCT/US2017/026994号に関係しており、内容全体が本明細書に組み込まれている。
【0002】
本開示は、分散型デジタルネットワークにおけるシーン表現、処理、および高速化に関する。
【背景技術】
【0003】
様々なコーデックが当技術分野においてよく知られており、これらは、一般に、高速伝送を可能にするためにデータを圧縮し、受信データを伸張するデバイスまたはプログラムである。典型的なタイプのコーデックは、動画(たとえば、MPEG、H.264)、音声(たとえば、MP3、ACC)、画像(たとえば、JPEG、PNG)、およびデータ(たとえば、PKZIP)を含み、コーデックの種類は、データのタイプをカプセル化し、データのタイプと強く結合されている。これらのタイプのコーデックはデータのタイプに限定されるアプリケーションには十分であるが、強い結合に内在するのは、制限されたエンドユーザ体験である。
【0004】
コーデックは、本質的に「ファイルベース」であり、ファイルはある種の現実のまたは合成された事前キャプチャされた感覚体験のデータ表現であり、ファイル(映画、歌、または本など)は必然的にユーザの体験をファイル作成者によって選択された体験経路に制限する。したがって、われわれは、映画を見たり、歌を聴いたり、本を読んだりすることを、作成者によって限定された実質的に順序立てられた体験の中で行っている。
【0005】
市場における技術の進歩は、データのタイプを拡大するとともにデータのタイプを体験するための手段を増やしている。データのタイプの増加は、カメラおよび距離測定デバイスなどのセンサが現実世界のシーンのシーンモデルを作成する現実世界シーン再構築(real-world scene reconstruction)としばしば呼ばれるものを含む。本発明の発明者らは、内容全体が参照により本明細書に組み込まれている2017年4月11日に出願した国際特許出願第PCT/2017/026994号、名称「Quotidian Scene Reconstruction Engine」において、シーン再構築における著しい進歩を提案している。データのタイプを体験するための手段の改善は、より高い分解能およびより優れた性能の2Dおよび3Dディスプレイ、裸眼立体視ディスプレイ、ホログラフィックディスプレイ、ならびに仮想現実(VR)ヘッドセットおよび拡張現実(AR)ヘッドセットなどのエクステンデッドリアリティデバイスおよび方法を含む。他の著しい技術的進歩は、人間がもはや現実世界の感覚情報の唯一の消費者ではなくなった、オートマトンの増殖、ならびに情報の流れおよび情報へのアクセスが新しい体験パラダイムを可能にしている、ネットワークの増殖を含む。
【0006】
新しいシーンベースのコーデックの開発のためにある種の研究がなされており、そこではデータのタイプは現実世界のシーンの再構築および/または合成シーンのコンピュータ生成である。シーンコーデックの評価については、読者は、内容全体が参照により本明細書に組み込まれている「Joint ad hoc group for digital representations of light/sound fields for immersive media applications」によって公開されているような没入型メディアアプリケーションのためのライト/サウンドフィールドのデジタル表現のためのジョイントアドホックグループのテクニカルレポートを参照されたい。
【0007】
シーンの再構築および配信には問題があり、再構築は効率的に制御可能で拡張性の高い方式で現実世界のマターフィールドおよびライトフィールド(matter and light fields)の複雑さを十分に記述する表現と表現の組織化に関して難しく、配信は人間とオートマトンを含む多数のインタラクティブクライアントにわたるアクティブで、ライブですらある、シーンモデルを管理することに関して難しく、各々が事実上数が無制限にあるシーンパースペクティブ、ディテール、およびデータタイプのいずれかを潜在的に要求しているのである。
【0008】
したがって、市場の多くの必要性および機会に対処できる効率的で柔軟なシステムを提供することによって、この技術の欠点および不備を克服する必要がある。
【先行技術文献】
【非特許文献】
【0009】
【文献】ISO/IEC JTC1/SC29/WG1N72033
【文献】ISO/IEC JTC1/SC29/WG11N16352
【発明の概要】
【発明が解決しようとする課題】
【0010】
次の簡略化された要約は、本明細書において説明されているシステムおよび/または方法のいくつかの態様の最初の基本的事項を理解してもらうためのものである。この要約は、本明細書において説明されているシステムおよび/または方法の広範な概要ではない。これは、鍵となる/決定的なすべての要素を識別すること、またはそのようなシステムおよび/または方法の範囲全体を定めることを意図されていない。後で述べる詳細な説明の前置きとして、いくつかの概念を簡略化した形式で述べることのみを目的とする。
【0011】
本明細書では、シーンコーデックを使用するシステムを支援する方法および装置が提供され、システムは、サブシーンおよびサブシーンインクリメント(subscene increment)を含む、マルチウェイ(multi-way)、ジャストインタイム(just-in-time)、必要な場合のみ(only-as-needed)の、シーンデータの提供者または消費者のいずれかである。いくつかの実施形態により、シーンコーデックを使用するシステムは、シーンの1つまたは複数のデジタルモデルを含むプレノプティックシーンデータベースを備え、表現および表現の構成は、まとめて複数のシステムがほぼ無制限に詳細なシーンを表現することができるように複数のシステムにまたがって配信可能である。システムは、最小量の新しく提供されるシーン情報によって使用可能になる最大限連続的なユーザ体験を確実するために必要な、ジャストインタイム、必要な場合のみのサブシーン、およびシーンインクリメントを提供するこれらの表現および表現の組織化を処理するための効率の高い手段をさらに備え、これらの効率の高い手段は空間処理ユニットを含む。
【課題を解決するための手段】
【0012】
いくつかの実施形態によるシステムは、実行システム機能(executive system function)さらにはユーザインターフェース機能の両方を実行するアプリケーションソフトウェアをさらに備え得る。ユーザインターフェース機能は、ユーザインターフェースを提供すること、または外部ユーザインターフェースと通信することの任意の組合せを含む。ユーザインターフェースは、シーンデータ(および関連する他のシーンデータ)に対するユーザ要求を決定するために少なくとも一部は使用される明示的および暗示的なユーザ指示を決定し、シーンデータおよびユーザの要求に応答する他のシーンデータのいずれかをユーザに提供する。
【0013】
いくつかの実施形態によるシステムは、シーンコーデックをさらに備えるものとしてよく、コーデックは、エンコーダとデコーダのいずれか一方または両方を含み、それにより、シーンデータ提供者または消費者のいずれか一方または両方であるシステムを可能になる。システムは、現実世界の実シーンデータを感知するために利用可能なセンサのいずれかと任意選択でインターフェースするか、または任意選択でセンサのいずれかを備えるものとしてよく、そのような感知されたデータはどれも、システムによって全く新しいシーンまたは既存のシーンへのインクリメントに再構築するのに利用可能であり、データを感知したいずれか1つのシステムは、データをシーン情報に再構築するか、またはシーン再構築のために他のシステムにデータをオフロードすることができ、シーン再構築を実行する他のシステムは、再構築されたサブシーンおよびシーンインクリメントを最初に感知したシステムに戻す。
【0014】
いくつかの実施形態によるコーデックは、シーンモデルおよびシーンモデルと統合されるか、またはシーンモデルと関連して保持されているかのいずれかの他のタイプの非シーンデータをサポートする。いくつかの実施形態によるコーデックは、複数のシステムのネットワーク接続をサポートし、ユーザ要求、クライアントの状態、シーン使用状況データを含む制御パケット、さらには要求されたシーンデータおよび非シーンデータ、ならびに遂行検証でクライアントが使用するための任意選択の要求識別を含むシーンデータパケットを交換するものとしてよい。一対一、一対多、および多対多のシステムネットワーク接続に対するサポートが提供されるものとしてよく、ここでもまた、どのシステムも、新しいシーンデータを感知し、新しいシーンデータを再構築し、シーンデータを提供し、シーンデータを消費することができるものとしてよい。
【0015】
いくつかの実施形態によるシステムは、再構築およびシーンデータの配信の両方における機械学習の使用に対応しており、新しいタイプの情報のキーデータロギングは、個別のシステム性能およびネットワーク接続システム性能の両方を最適化する機械学習または決定論的アルゴリズムの基礎を提供する。たとえば、シーンデータを消費するすべてのクライアントシステムの状態は、任意の存在する可能性のあるサービングシステムがクライアントの既存のシーンデータおよび非シーンデータの貴重な事前知識を有していることを確実にするために追跡される。シーンのタイプおよびシーンインスタンスを含むユーザ要求は、分類され、一意に識別される。個別のシステムは、シーン感知、シーン再構築、シーン提供、およびシーン消費に関する能力に応じて識別され、分類される。使用タイプを含むシーン使用の範囲さらにはシーン消費経路およびシーン持続時間が追跡される。分類され、追跡される情報は多種多様なので、機械学習のための貴重な新しいデータが得られ、シーンデータに対するユーザの要求は、累積学習に基づく先読み予測によってインテリジェントに拡張され、最小限度の量の新しく提供されるシーン情報で使用可能になる最大限連続的なユーザ体験をさらに確実にする。
【0016】
これらの、および他の特徴および利点は、次の図面と併せて例示的な非限定的な図解された実施形態の次の詳細な説明を参照することによってよりよく、より完全に理解されるであろう。
【図面の簡単な説明】
【0017】
【図1A】いくつかの実装形態によるシーンコーデックを使用するシステムを示すブロック図である。
【図1B】いくつかの実施形態による、エンコーダおよびデコーダの両方を含むシーンコーデックを示すブロック図である。
【図1C】いくつかの実施形態による、エンコーダを含むが、デコーダを含まない、シーンコーデックを示すブロック図である。
【図1D】いくつかの実施形態による、デコーダを含むが、エンコーダを含まない、シーンコーデックを示すブロック図である。
【図1E】いくつかの実装形態による、シーンコーデックを使用する2つ以上のシステムを接続するネットワークを示すブロック図である。
【図1F】いくつかの実施形態による、エンコーダを含むシーンコーデックを示すブロック図である。
【図1G】いくつかの実施形態による、デコーダを含むシーンコーデックを示すブロック図である。
【図2A】スイスのジュネーブから発行された2016年6月日付の技術出版物ISO/IEC JTC1/SC29/WG1N72033、ISO/IEC JTC1/SC29/WG11N16352において、没入型メディアアプリケーションのためのライト/サウンドフィールドのデジタル表現のためのジョイントアドホックグループによって説明されている、既存の最先端の「ライト/サウンドフィールド概念ワークフロー」のブロック図である。
【図2B】いくつかの実施形態による、代表的なリアルカメラによってキャプチャされ、図1Eに示されているようなネットワーク環境における図1に示されているシステムなどのシステムに提供されている現実世界のシーンの組合せブロックおよび絵図である。
【図3】いくつかの実施形態による、シーンコーデックを使用するシステムを接続する例示的なネットワークの絵図である。
【図4A】いくつかの実施形態による、屋外のシーンが見える窓のある内部の家のシーンなどの無制限またはほとんど無制限のディテールの例示的な現実世界のシーンの絵図である。
【図4B】いくつかの例示的な実施形態による、図4Aに示されているような現実世界のシーンを表す絵図であり、表現は、プレノプティックシーンデータベース内に含まれるデータの抽象的モデルビュー、さらには説明されているオブジェクトおよび説明されていないオブジェクトなどの他のオブジェクトと考えられ得る。
【図4C】いくつかの例示的な実施形態による、プレノプティックシーンデータベース内のいくつかのデータセットのブロック図である。
【図5】いくつかの実施形態による、様々なタイプのシーンモデル情報のうちのいずれかを消費しているリモートクライアントとのより大きなグローバルシーンモデルの共有を含むユースケースの流れ図である。
【図7】いくつかの実施形態による、図5および図6に類似しているユースケースの流れ図であるが、クライアントシステムが最初にシーンモデルを作成するか、または既存のシーンモデルを更新し、次いでクライアントサイドシステムおよびサーバサイドシステムの両方が各々実シーンを再構築して配信し、そうしてサブシーンおよびサブシーンへのインクリメントを決定し提供することができる実シーンのローカルシーンデータをキャプチャしている異なるケースを取り扱っている。
【図8】複合プレノプティックシーンモデルである、平凡なキッチンの合成生成画像である。
【図9】いくつかの実施形態による、体積要素(「ボクセル」)と立体角要素(「セイエル」)の2つのビューとを示す幾何学的図である。
【図10】いくつかの実施形態による、平凡なシーンのシーンモデルの俯瞰平面図を示す幾何学的図である。
【図11】いくつかの実施形態による、シーンデータベースのブロック図である。
【図12】いくつかの実施形態による、プレノプティックフィールドを表現する際に使用されるプリミティブタイプの階層を示すクラス図である。
【図13】複合プレノプティックシーンモデルである、2点が強調されている平凡なキッチンの合成生成画像である。
【図20】いくつかの実施形態による、垂直偏光の単一入射ビームに適用されるBLIFの結果を示すライトキューブの画像である。
【図21】いくつかの実施形態による、八分木の木構造を示す図である。
【図23】いくつかの実施形態による、セイエル木(saeltree)の木構造を示す図である。
【図25】いくつかの実施形態による、八分木ノードの中心に原点を有するセイエルを示す幾何学的図である。
【図26】いくつかの実施形態による、2Dの3本のセイエル木の3つのセイエルによって表される空間を示す幾何学的図である。
【図27】いくつかの実施形態による、2本のセイエル木の2つの出射セイエル、および2つのセイエルと2つの容積八分木(VLO)ボクセルとの交点を示す幾何学的図である。
【図28】いくつかの実施形態による、VLOノード上に突出する2本のセイエル木からの2つの出射セイエルの結果として生じる1つのVLOボクセルにアタッチされた新しいセイエル木の2つの入射セイエルを示す幾何学的図である。
【図29】いくつかの実施形態による、ボクセルの入射セイエル木とボクセルに関連付けられているBLIFとに基づくVLOボクセルに対して生成される新しいセイエル木からの出射セイエルを示す幾何学的図である。
【図30】いくつかの実施形態による、空間処理ユニット(SPU)の機能を示す概略図である。
【図31】いくつかの実施形態による、空間処理ユニットのライトフィールドオペレーション機能のサブ機能を示す概略図である。
【図32】いくつかの実施形態による、セイエル木の周囲立方体の6つの面のナンバリングを示す幾何学的図である。
【図33】いくつかの実施形態による、セイエル木の周囲立方体の面の四分の一の面が強調されている周囲立方体の四分の一の面を示す幾何学的な図である。
【図34】いくつかの実施形態によれる、セイエル木の周囲立方体の四分の一の面の側面図を示す幾何学的図である。
【図35】いくつかの実施形態による、最上位セイエルによって表される方向空間のセグメントの2D側面図を示す幾何学的図である。
【図36】いくつかの実施形態による、投影面へのセイエル木のセイエルの投影がセイエル木の周囲立方体の面上の配置でのその交点によってどのように表されるかを示す幾何学的図である。
【図37】いくつかの実施形態による、投影面上のセイエルの投影を維持しながらセイエル木の動きを2Dで例示する幾何学的図である。
【図38】いくつかの実施形態による、セイエル木のセイエルの投影を維持しながら投影面の動きを例示する幾何学的図である。
【図39】いくつかの実施形態によれる、投影面上のセイエルの差し渡しの幾何学的形状を示す幾何学的図である。
【図40】いくつかの実施形態による、頂部および底部の交点と投影面座標系において頂部が底部より下にあり、投影が有効でないことを示す状況(セイエルからの原点の反対側)との間の関係を示す幾何学的図である。
【図41】いくつかの実施形態による、セイエル木のセイエルを2つの部分木レベルに細分した状態と、2Dでノードによって表される空間領域とを示す幾何学的図である。
【図42】いくつかの実施形態による、サブセイエルの新しい頂部エッジまたは底部エッジとなる投影面との新しいセイエルエッジの交点の配置を示す幾何学的図である。
【図43】いくつかの実施形態による、出射セイエルが交差するVLOノードに取り付けられたセイエル木における入射セイエルの生成を引き起こすセイエル木からの出射セイエルを示す幾何学的図である。
【図44】いくつかの実施形態による、方向空間の図示されている範囲内にある2D内の前方から後方へのVLOトラバーサルシーケンス(traversal sequence)を示す幾何学的図である。
【図45】いくつかの実施形態による、シーン内へのセイエル投影における投影マスクとしての四分木の使用を2Dで例示した幾何学的図である。
【図46】いくつかの実施形態による、複数の半空間の交点によるセイエルの容積空間の構築を示す幾何学的図である。
【図47】いくつかの実施形態による、セイエルと3つのVLOノードとの間の3つの交差状況を示す幾何学的図である。
【図48】いくつかの実施形態による、セイエル木の回転の一部としてセイエルの回転を例示する幾何学的図である。
【図49】いくつかの実施形態による、セイエル木の回転中の投影面を有するセイエルエッジ間の中心点の幾何学的構成を示す幾何学的図である。
【図50】いくつかの実施形態による、セイエル木を回転させるときのエッジの回転を実行する幾何学的オペレーションを示す幾何学的図である。
【図51】いくつかの実施形態による、セイエル原点ノード、投影面のVLOノード、またはセイエルがPUSHされたときのセイエルと投影面との間の幾何学的関係の計算を示す概略図である。
【図52】いくつかの実施形態による、セイエル原点ノード、投影面のVLOノード、またはセイエルがPUSHされたときのセイエルと投影面との間の幾何学的関係の計算を示す概略図であり、セイエル原点ノードと投影面のVLOノードは同時にPUSHされる。
【図53】いくつかの実施形態による、一連のセイエル木原点、VLO、およびセイエルの一連のPUSHの結果を表にしたスプレッドシートの一部を示す表である。
【図57】いくつかの実施形態による、図53および図54のスプレッドシートに示されている反復#1の後の投影面上のセイエルとその投影との間の幾何学的関係を示す幾何学的図である(子3へのセイエル原点SLTノードのPUSH)。
【図58】いくつかの実施形態による、図53および図54のスプレッドシートに示されている反復#2の後の投影面上のセイエルとその投影との間の幾何学的関係を示す幾何学的図である(子2へのセイエル原点SLTノードのPUSH)。
【図59】いくつかの実施形態による、図53および図54のスプレッドシートに示されている反復#3の後の投影面上のセイエルとその投影との間の幾何学的関係を示す幾何学的図である(子3への投影面VLOノードのPUSH)。
【図60】いくつかの実施形態による、図53および図54のスプレッドシートに示されている反復#4の後の投影面上のセイエルとその投影との間の幾何学的関係を示す幾何学的図である(子1への投影面VLOノードのPUSH)。
【図61】いくつかの実施形態による、図53および図54のスプレッドシートに示されている反復#5の後の投影面上のセイエルとその投影との間の幾何学的関係を示す幾何学的図である(子1へのセイエルのPUSH)。
【図62】いくつかの実施形態による、図53および図54のスプレッドシートに示されている反復#6の後の投影面上のセイエルとその投影との間の幾何学的関係を示す幾何学的図である(子2へのセイエルのPUSH)。
【図63】いくつかの実施形態による、図53および図54のスプレッドシートに示されている反復#7の後の投影面上のセイエルとその投影との間の幾何学的関係を示す幾何学的図である(子0への投影面VLOノードのPUSH)。
【図64】いくつかの実施形態による、セイエル木原点が八分木ノードの中心にない場合の、一連のセイエル木原点、VLO、およびセイエルの一連のPUSHの結果を表にしたスプレッドシートの一部を示す表である。
【図66】いくつかの実施形態による、シーンコーデックのアプリケーションプログラミングインターフェース機能を示す概略図である。
【図67】いくつかの実施形態による、クエリプロセッサ機能の機能を示す概略図である。
【図68A】いくつかの実施形態による、プレノプティック投影エンジンを実装するために使用される手順のフローチャートである。
【図68B】いくつかの実施形態による、リモート伝送のためにプレノプティック八分木からサブシーンを抽出するのに使用される手順のフローチャートである。
【図69】いくつかの実施形態による、複数の視点からの画像生成を目的としてシーンデータベースからサブシーンモデルを抽出するための処理の流れ図である。
【図70】いくつかの実施形態による、クエリセイエルに光の寄与をもたらすプレノプティックプリミティブを蓄積するためのプロセスの流れ図である。
【図71】いくつかの実施形態による、媒体要素(「メディエル」)およびクエリセイエルに光の寄与をもたらすそれの寄与ライトフィールド要素(「ラディエル」)を蓄積するためのプロセスの流れ図である。
【図72】いくつかの実施形態による、分析ポータルを強調する小さな長方形の領域を有するキッチンの画像である。
【図75】一実施形態の有効性の証拠に関係する絵図である。
【図76】一実施形態の有効性の証拠に関係する絵図である。
【図77】一実施形態の有効性の証拠に関係する絵図である。
【図78】画像生成を目的とするサブシーン抽出を示す絵図である。
【発明を実施するための形態】
【0018】
次の説明では、本開示を完全に理解できるように、特定のコンポーネント例、使用シナリオのタイプなどの、多数の具体的詳細が述べられている。しかしながら、当業者には、これらの具体的詳細の一部がなくても、また一部が本明細書でも説明されている代替的実装形態により、本開示が実施され得ることは明らかであろう。他の場合には、よく知られているコンポーネントまたは方法は、本開示をいたずらにわかりにくくしないために詳しくは示されていない。したがって、述べられている具体的詳細は、例示的なものにすぎない。具体的詳細は、異なることもあり得るが、それでも本開示の精神および範囲内にあることが企図され得る。
【0019】
最小限のシーンデータを使用して複雑なユーザ要求に両方とも適合するサブシーンおよびサブシーンへのインクリメントなどの可変的に拡張し得るシーン表現を提供する一方で、継続的なサービス品質を保証する十分なバッファ(要求されたシーンデータへの拡張)を予想する「先読み」を行うための包括的なソリューションが実現される。例示的な実施形態によるコーデックは継続的シーン消費に釣り合う継続的シーン再構築を扱い、その場合、複数のエンティティは任意の時点においてシーンデータを提供するか、またはシーンデータを消費しており、シーンデータを提供することは、再構築されたシーンデータと新たに決定された実シーンの未再構築データの両方を含む。
【0020】
いくつかの例示的な実施形態において、シーン配信は、「ファイルベース」に重きを置かず(すなわち、シーン全体の情報の1対1の一方向パイプラインにあまり集中しない)、「ファイルセグメントベース」に重きを置く(すなわち、ジャストインタイムの、必要な場合のみのサブシーンおよびサブシーンインクリメント情報の多対多の双方向パイプラインにより集中する)。いくつかの例示的な実施形態におけるこの多方向構成は、自己学習し、シーンデータの提供および消費を追跡して潜在的により多くのシーンサーバおよびシーンクライアントにまたがる最適な負荷分散および共有を決定することである。例示的な実施形態におけるシーン処理は、すべてのタイプのデータの融合を考慮しており、シーンモデルは、実質的にすべての他のタイプのデータへの接続を有するインデックス作成可能、拡張可能、翻訳可能なオブジェクトであり、次いで、シーンは、様々なタイプのデータに対するコンテキストを提供し、それ自体がすべてのタイプのデータに基づき検索可能になる。
【0021】
例示的な実施形態におけるシーンは、マターフィールドおよびライトフィールドによって占有される空間および時間内の一領域として考えられ得る。いくつかの実施形態による例示的なシステムは、フリービュー、フリーマター、およびフリーライトでのシーン可視化をサポートしており、フリービューは、ユーザがシーンをセルフナビゲートすることを可能にし、フリーマターは、ユーザがシーンの客観化、定性化、定量化、拡張、および他の何らかの形の翻訳を行うことを可能にし、フリーライトは、ユーザが様々な光源のユニークなスペクトル出力さらには光強度および偏光の考慮事項すらも考慮してシーンを再キャストすることを可能にするが、これらはすべてシーンモデルのリアリズムに加わる。フリーマターおよびフリーライトの組合せは、ユーザがシーンを様々なセッティング、たとえば、冬の朝または夏の夜のプラハの都市ツアーを体験するセッティングに再コンテキスト化することを可能にする。
【0022】
シーンデータの人間視覚化は常に重要であるが、いくつかの実施形態によるコーデックは、計測、オブジェクト認識、シーン、および状況認識を含むシーンデータのタイプおよび機能の配列を提供する。シーンデータは、シーンモデル内に含まれるマターフィールドおよびライトフィールドのディテールの範囲によってのみ制限される現実世界内で決定可能なデータおよびメタデータの範囲全体を含むものとしてよく、次いで、この範囲のデータは、リアルタイムでモデル化される災害シーンの上を這うか、または飛行し、高度なオブジェクト認識を使用して特定のオブジェクトおよび人々を探索する捜索救助オートマトンなど、人間からAIシステム、オートマトンに至る、消費者の範囲に応じてフォーマットされなければならない。そのようなものとして、例示的な実施形態によるコーデックは、フリービュー、フリーマター、フリーライティング、およびフリーデータである。
【0023】
いくつかの実施形態によるコーデックは、非常に効率的なサブシーン、およびシーンのインクリメント、抽出、および挿入のための新しい装置および方法を実装し、そのような効率性の技術的改善は、関連する電力要件を伴う計算時間などのコンピュータ処理要件の著しい低減をもたらす。マルチウェイ、ジャストインタイム、必要な場合のみのシーン再構築および配信に対する市場要件が高まることが予想されることを考えると、カスタマイズされたコンピュータチップを含む新しいタイプのシーン処理ユニットが必要であり、これは、現実世界の複雑で非常に詳細なシーンの新しい表現および表現の組織化に対して最適化された新しいクラスの命令セットを埋め込むことである。
【0024】
図1Aを参照すると、いくつかの例示的な実施形態により、シーンコーデック1A01を使用するシステムのキーコンポーネントを表すブロック図が示されている。システム1A01は、シーンモデルの再構築、配信、および処理のための著しい技術的改善を提供し、実シーンは、3次元空間であると一般的には理解されるが、実シーンの空間的態様が時間の経過とともに変化し得るような第4の次元である時間を含んでもよい。シーンモデルは、実シーンの再構築、またはコンピュータ生成されたシーン、またはシーン拡張のいずれか、またはそれらの任意の組合せであってもよい。システム1A01は、グローバルシーンモデルの実質的な課題の解決に取り組むものであり、グローバルシーンモデルは、一般的に、より大きな現実世界空間を表すと理解され、エンドユーザが空間的インクリメントで達成するその体験および探索はここではサブシーンと呼ばれる。一例として、グローバル実シーンは、プラハのような主要な観光都市であり、現実世界においてプラハを探索しようとすると、かなりの量の空間的に詳細な情報を含むサブシーン全体にわたって何日間も空間的に移動することを必要とするであろう。特に、より大きな実シーンでは、シーンのエントリーポイント、横断経路、および横断経路に沿った視点の組合せが、事実上無限の量の情報を生み出し、そのため、圧縮を含むインテリジェントなシーンモデリングおよび処理が必要になる。
【0025】
以下では説明を効率的に行うことを目的として、本開示においてシーンまたはサブシーンを参照するとき、これはシーンモデルまたはサブシーンモデルであると理解されるべきであり、したがって、存在すると理解され、モデルが少なくとも部分的に導出される際のその導出元である実シーンまたは実サブシーンとは反対のものと理解されるべきである。しかしながら、ときには、本開示は、モデル化された世界と混同することなく実世界を論じるために、シーンをリアルであるとして、すなわち実世界として記述することがある。また、ビューアおよびユーザという用語は、区別することなく交換可能に使用されると理解されるべきである。
【0026】
システム1A01は、非常に効率的なリアルタイムの、またはリアルタイムに近い方式で実質的に無限のシーンへのユーザアクセスをインテリジェントに提供するように構成されている。グローバルシーンは、ローカルシーンの組合せとして考えることができ、ローカルシーンは、それほど広範囲ではないが、空間的にインクリメンタルな方式で探索されなければならない。ローカルシーンは、したがってグローバルシーンも、ユーザに対して最初にシーン情報が提示されるエントリーポイントを有することができる。シーンエントリーポイントは、本質的にサブシーンであり、たとえば、「プラハ」というグローバルシーンモデル内のシーンエントリーポイントは、「聖クレメント大聖堂のナルテックス」であり、ここでもまた、「大聖堂」サブシーンを表現するためにシステム1A01によって提供されるデータは、典型的には、「プラハ」グローバルシーンのデータ全体よりも実質的に少ないことが理解されるであろう。いくつかの例示的な実施形態において、「聖クレメント大聖堂」などの提供されるサブシーンは、システムによって、エンドユース要件を満たすのに十分な最小シーン表現であると決定される。いくつかの例示的な実施形態におけるシステムによる十分性のこの決定には、多くの利点がある。一般に、十分性の決定は、少なくとも、要求されるかまたは期待されるシーンビューイング方向に基づき様々なレベルのマターフィールドおよび/またはライトフィールドの分解能を伴うサブシーンモデル情報を提供することを含む。たとえば、より高い分解能の情報は、視覚的に遠いオブジェクトとは反対にすぐ近くのオブジェクトについて提供され得る。「ライトフィールド」という用語は、シーン内のすべての領域におけるすべての方向のライトフローを指し、「マターフィールド」という用語は、シーン内の領域を占有する物質を指す。本開示において、「ライト」または「光」という用語は、可視バンド、赤外線バンド、および紫外線バンドを含む周波数の電磁波を指す。
【0027】
さらに、いくつかの例示的な実施形態により、システム1A01は、たとえば、「先読み」シーン分解能を提供することなどの目的のために空間的バッファをサブシーンにインテリジェントに付与する。「聖クレメント大聖堂のナルテックス」サブシーンの例では、最小分解能だと、ビューアが聖クレメント大聖堂の入口に静止して立っているが、その後360度回転して、任意の方向、たとえば大聖堂に向かう方向、または大聖堂から離れる方向に見ることを予期するものになり得る。この最小分解能は、ビューアがナルテックス内で立ったままであると仮定した場合には十分であるが、ビューアが大聖堂に近づき、大聖堂に入ることを望でいる場合には、これより大聖堂の方向の分解能は最終的にサービス品質(QoS)閾値より低くなるであろう。システムは、ビューアが要求された動きを予期し、それに応答して、ビューアが自由視点を移動した場合にビューアがシーン分解能の実質的な損失を知覚しないように追加の非最小分解能を含む。現在の例では、この追加の非最小分解能は、QoS閾値でプラハのすべてを見るのに十分な分解能を含むことも可能であるが、ただし、これが延いては著しく過剰な、ほとんどの場合に未使用である、データ処理および伝送を引き起こすことになり、中断されないリアルタイムのビューア体験に悪影響を与える可能性が高いことを除く。したがって、シーンバッファの概念は、ビューアの可能性の高い横断経路、横断経路視点、および横断経路移動速度を含むすべての知られている情報に基づきある程度の追加の非最小分解能をインテリジェントに決定し、提供することである。
【0028】
システム1A01は、シーン、およびシーンを体験し、シーンへのアクセスを要求するユーザの両方に関する高度なコンテキスト認識を示し、いくつかの例示的な実施形態において、このコンテキスト認識は、機械学習、およびシステム1A01によって実行されるシーン体験ロギングの蓄積の一方または両方のアプリケーションに基づき強化される。時間の経過とともに複数のユーザによって体験されるプラハなどのグローバルシーンについて、選択されたエントリーポイント、横断経路、横断経路視点、および横断移動速度を含む、個別のユーザの少なくとも横断メトリックスのロギングは、システム1A01の機械学習コンポーネントに対する著しい情報を提供し、空間バッファのサイズを調整するのを補助し、したがって、最小(または実質的に最小)の量の提供されるシーン情報によって提供されるシーンの最大限(または実質的に最大限)連続的なユーザ体験を確実にし、この最大最小関係は、いくつかの例示的な実施形態ではシステム1A01のシーン圧縮技術の焦点となっているものである。システム1A01によって取り扱われるシーン圧縮の別の重要な態様は、現実世界のシーンを表すシーンモデルデータの新規性のある配置構成に大きく依存するシーン処理時間であり、ここでは、このデータは、プレノプティックシーンモデルと一般的に称され、プレノプティックシーンデータベース1A07に収められている。
【0029】
「プレノプティック」という用語を熟知している者は、それをシーン内の特定の点の5次元(5D)表現として認識し、そこから4πステラジアンの移動が体験されるものとしてよく、したがって、シーン内の任意の点(x、y、z)が球体の中心と考えられてよく、そこからユーザの移動が中心点から外向きの任意の方向(θ、φ)において体験され得る。ライトフィールド処理を熟知している者は、プレノプティック関数が、少なくとも当技術分野においてライトフィールドと称されるものを記述するのに有用であることも理解するであろう。本明細書において詳述されるように、本発明のいくつかの例示的な実施形態は、最小(または実質的に最小)の量の新たに提供されるシーン情報によって提供される最大限(または実質的に最大限)連続的なユーザ体験を可能にするためにシーンモデルのユーザによる実質的に5Dの横断がジャストインタイムの方式で効率的に処理され得るように実シーンのライトフィールドおよびマターフィールドの両方の新規性のある表現を実現する。
【0030】
システム1A01は、シーン再構築およびシーン配信の両方を目的としてプレノプティックシーンデータベース1A07を実質的に処理するための空間処理ユニット(SPU)1A09をさらに備える。本明細書で説明されるように、再構築は、一般的に、シーンの様々なデータ表現のうちのいずれかを増加させるために、シーンデータベースに追加する、または構築するプロセスであり、これらのデータ表現は、限定はしないが、1)たとえば、自動車のボンネットに損傷がないか検査されていることからプラハを観光のために横切ることにまで至る、実シーンの3次元体積である時空間的広がり、2)シーンを体験しているユーザに知覚可能な空間視力の限界に関するシーンの視覚的表現を少なくとも含む空間的ディテールであって、視覚的空間視力は、人間の視覚システムに応じて変わると一般的に理解され、人間ユーザによって区別可能であるおおよそ0.5から1.0分の立体角あたりのディテールの最大分解能を定義し、それにより、さらなるディテールは、ユーザがシーンエリアに近づくことによってその立体角内でシーンエリアを効果的に増加させるように空間的配置を変えない限りユーザからは実質的に知覚できない、空間的ディテール、3)知覚されたシーンを表す光の強度および色域の両方を含むライトフィールドダイナミックレンジであって、たとえば、ダイナミックレンジは、前景対背景であるとみなされるシーンの部分に対してより大きな色域を提供するようにインテリジェントに変更することができる、ライトフィールドダイナミックレンジ、4)シーンのライトフィールドの透過、吸収、および反射に対するシーン内の物質の効果を記述する光相互作用特性とともに両方の空間的特性(たとえば、表面形状)を含むマターフィールドダイナミックレンジなどである。次いで、サブシーン抽出は、プレノプティックシーンデータベース1A07内のシーンを表す様々な次元の情報に関してシーン情報の最小データセットのSPU1A09を使用するシステム1A01によるインテリジェントで効率的な決定であり、ここでもまた、この最小データセット(サブシーン)が十分なシーン分解能(たとえば、所定のQoS閾値を満たす連続性および/または分解能)を有する実質的に継続する体験を提供することは、ユーザの体験にとって最も重要である。
【0031】
システム1A01は、少なくともいくつかの実施形態では、シーン再構築のプロセス、およびサブシーン配信のプロセスのうちの1つまたは複数において機械学習を提供するためのシーンソルバー1A05を備えていてもよい。シーンソルバー1A05では、シーンのエントリーポイント、横断経路、視点、および有効シーンインクリメントペースを示す情報などの補助シーン情報は、最小または少なくとも許容可能なシーン損失で最大のシーン圧縮を提供する際に考慮され得る。
【0032】
システム1A01は、アプリケーションソフトウェア1A03によって実装されたユーザインターフェースを通じて示されている要求を受信するための要求コントローラ1A13をさらに備える。受信された要求は、シーンコーデック1A11を使用して別のネットワーク接続されたシステムと通信するために制御パケット1A17に翻訳される。したがって、システム1A01は、他のネットワーク接続されたシステム1A01によって生成された要求を受信することも可能である。受信された要求は、要求コントローラ1A13により独立して、または要求コントローラ1A13とアプリケーションソフトウェア1A03の両方の組合せで、システム1A01によって処理される。制御パケット1A17は、明示的なユーザ要求と暗黙のユーザ要求のいずれかまたは両方を含むものとしてよく、明示的な要求は、シーン(たとえば、プラハツアーの出発点としての聖クレメント大聖堂)に対する特定の利用可能なエントリーポイントを選択することなどのユーザによる意識的な決定を表し、暗黙のユーザ要求は、現在のシーンに関するユーザの頭の向きの検出(たとえば、ホログラフィックディスプレイに取り付けられているカメラセンサまたは仮想現実(VR)ヘッドセット内に用意された慣性センサによって検出されるような)などのユーザによる潜在意識における決定を表し得る。明示と暗黙のこの区別は、例示的であるが、限定的ではなく、いくつかのユーザ要求は半意識的なもの、たとえば、VRシステム内のモーションコントローラの移動によって示され得るシーンインクリメントペースである。
【0033】
シーンコーデック1A11は、制御パケット1A17内に含まれ得るユーザ要求に応答するように構成され、システム1A01がシーン提供者として機能しているときおよびその場合に、好ましくはジャストインタイムのシーンデータパケットを提供する。シーンコーデック1A11は、システム1A01がシーン消費者として機能しているときおよびその場合に、シーンデータパケット1A15を受信して、それに応答することをさらに可能にされ得る。たとえば、システム1A01は、プレノプティックシーンデータベース1A07からエンドユーザによる潜在的な消費のために提供されたシーン情報を受信する多数の他のシステム1A01に抽出されるようなシーン情報の提供者である可能性がある。プレノプティックシーンデータベース1A07内に含まれるシーン情報は、厳密には視覚情報に限定されなくてもよく、したがって、たとえば、何らかの形態の画像出力デバイスを見ているユーザによって最終的に受信される情報も、いくつかの例示的な実施形態では含まれ得る。いくつかの例示的な実施形態において、シーン情報は、シーン計量(たとえば、テーブルのサイズ)またはシーン認識(たとえば、光源の配置)などのシーンのマターフィールドおよびライトフィールドから少なくとも一部は翻訳される任意の数のメタ情報、またはマターフィールドもしくはライトフィールドではないが、マターフィールドおよびライトフィールドの任意の組合せまたは一部と関連付け可能である補助情報などの関係情報を含むこともできることが理解されるべきである。例示的な補助情報には、限定はしないが、シーンエントリーポイント、シーンオブジェクトラベル、シーン拡張、デジタルシーンサイネージなどを含む。
【0034】
システム1A01は、シーンデータパケット1A15の出力と受信のいずれかまたは両方に合わせて構成され得る。さらに、システム1A01などのシステムの間のシーンデータパケット1A15の交換は、同期的でも同質的でなく、むしろ、ユーザの要求を制御パケット1A17でもっぱら表されるものとしてまたはアプリケーションソフトウェア1A03によって提供されるユーザインターフェースもしくはアプリケーションインターフェースを通じて他の何らかの形で最大限満たすために最小限度の応答性を示すものとしてよい。特に、シーンデータパケット1A15の周期性に関して、従来のコーデックとは対照的に、シーンコーデック1A11は非同期的に動作することができ、たとえば、所与のシーンバッファサイズを有するシーンインクリメントを表すサブシーンデータは、ジャストインタイムおよび必要な場合のみの両方で、またはジャストインタイムであっても、予想される場合のみで、提供され、「必要な」は、明示的なユーザ要求による場合が多く、「予想される」は、暗黙のユーザ要求による場合が多い。特に、シーンデータパケット1A15のコンテンツ構築に関して、従来のコーデックとは対照的に、シーンコーデック1A11は、異種シーンデータパケット1A15を提供するように動作することができ、たとえば、ジャストインタイムパケットは、マターフィールド情報、ライトフィールド情報、補助情報、またはそれらの任意の翻訳のうちの任意の1つまたは任意の組合せを含む。
【0035】
また、「ユーザ」は、人に限定されず、別の自律システム1A01などの任意の要求者を含むことができることが理解される(たとえば、次に示すことになる図3に描かれているような陸上ロボット、UAV、コンピュータ、またはクラウドシステムを参照)。自律システムを熟知している者であればよく理解するように、そのような自律システムは、本質的に視覚表現情報を含むシーン表現に著しく有用であり得、たとえば、シーンの知られている画像は、プレノプティックシーンデータベース1A07内に含まれるシーンに対応するか、または類似するかのいずれかである現実世界のシーン内で自律システム1A01によってキャプチャされる視覚情報と比較するために、探して見つける作業を行う自律システム1A01によって使用可能である。さらに、そのような自律システム1A01は、非視覚情報または準視覚情報に対して好ましい用途を有することがあり、非視覚情報は、シーンおよびシーンオブジェクト計測を含み、準視覚情報は、シーン照明属性を含み得る。自律的または人間操作システム1A01のいずれかは、いくつかの例示的な実施形態において、プレノプティックシーンデータベース1A07内の可能な空間的またはさらにはオブジェクトコロケーションに対する、または少なくとも補助情報としてシーンをさらに記述することに対するシーンの非視覚的表現を収集して提供するようにも構成され得る(たとえば、シーンデータベースビューを例示する次に示す図4Cを参照)。たとえば、非視覚的表現は、体性感覚(触る)、嗅覚(臭い)、聴覚(聴く)、またはさらには味覚(味)などの他の感覚情報を含む。本開示の目的のために、視覚情報としてのシーン表現に焦点が当てられている場合、この焦点は、制限として解釈されるべきではなく、むしろ特徴として解釈されるべきであり、その場合、プレノプティックシーンデータベースは、任意の感覚情報または感覚情報の翻訳、特に人間ユーザによってしばしば要求される音声/画像データを含むことができることが少なくとも理解される。
【0036】
次に図1Bを参照すると、システム1A01のいずれかに備えられるシーンコーデック1A11のブロック図が示されており、シーンコーデック1A11は、いくつかの例示的な実施形態により、エンコーダ1B11aおよびデコーダ1B11bの両方を含む。図1Aに関連して説明されているように、エンコーダの主な機能は、シーンデータパケットを受信して処理することが可能な(たとえば、デコーダ1B11bなどのデコーダを備えることによって)、たとえば、別のシステム1A01などの、少なくとも1つの他のシステムによって受信されるように、たぶんネットワークを介して、シーンデータパケット1A15を決定して提供することである。エンコーダ1B11aは、制御パケット1A17を受信し、応答することができる。エンコーダ1B11aおよびデコーダ1B11bの両方を備えるシーンコーデック1A11を具備するシステム1A01のユースケースは、以下の次に示すことになる図7に関連して説明される。
【0037】
次に図1Cを参照すると、いくつかの例示的な実施形態により、エンコーダ1B11aのみを含む(したがって、図1Bに描かれているようなデコーダ1B11bを含まない)シーンコーデック1A11のブロック図が示されている。エンコーダ1B11aのみを含むシーンコーデック1A11を備えるシステム1A01のユースケースは、以下の次に示すことになる図5および図6に関連して説明される。
【0038】
次に図1Dを参照すると、いくつかの例示的な実施形態により、デコーダ1B11bのみを含む(したがって、図1Bに描かれているようなエンコーダ1B11aを含まない)シーンコーデック1A11のブロック図が示されている。デコーダ1B11bのみを含むシーンコーデック1A11を備えるシステム1A01のユースケースは、以下の次に示すことになる図5および図6に関連して説明される。
【0039】
次に図1Eを参照すると、2つ以上のシステム1A01を接続するためのトランスポート層を含むネットワーク1E01のブロック図が示されている。ネットワーク1E01は、任意の2つ以上のコンピューティングシステムの間で情報を伝送するための任意の手段または通信インフラストラクチャを表すものとしてよく、例示的な実施形態において、主焦点となるコンピューティングシステムはシステム1A01であるが、少なくともいくつかの実施形態では、これに限定されない。コンピュータネットワークを熟知している者であればよく理解するように、パーソナルエリアネットワーク(PAN)、ローカルエリアネットワーク(LAN)、ワイヤレスローカルエリアネットワーク(WLAN)、キャンパスエリアネットワーク(CAN)、メトロポリタンエリアネットワーク(MAN)、ワイドエリアネットワーク(WAN)、ストレージエリアネットワーク(SAN)、パッシブ光ローカルエリアネットワーク(POLAN)、エンタープライズプライベートネットワーク(EPN)、および仮想プライベートネットワーク(VPN)などのネットワークの多くの変種が現在存在しており、これらのうちの任意およびすべては、ここで説明されているネットワーク1E01の実施形態であってよい。またコンピュータネットワークを熟知している者であればよく理解するように、トランスポート層は、一般的に、ネットワークスタックにおけるプロトコルの階層化アーキテクチャにおける技術の論理的な分割であると理解され、たとえば、開放型システム間相互接続(OSI)通信モデルに関してレイヤ4と称される。本開示の目的のために、トランスポート層は、任意の2つ以上のシステム1A01によってネットワーク1E01上で交換される制御パケット1A17およびシーンデータパケット1A15などの情報を通信する機能を含む。
【0040】
なおも図1Eを参照すると、ネットワーク1E01上で通信するシステム1A01などのコンピューティングシステムは、1E05などのサーバサイド、または1E07などのクライアントサイドのいずれかに常駐するものとして参照されることが多い。典型的なサーバ-クライアントの区別は、ウェブサービス(サーバサイド)がウェブブラウザ(クライアントサイド)に提供されることに関して使用されることが最も多い。例示的な実施形態の中では、たとえば、システム1A01内のアプリケーションソフトウェア1A03がデスクトップアプリケーションまたはさらには組み込みアプリケーションなどの別の技術とは反対にWebブラウザを使用して実装されるという制限はないことが理解されるべきであり、そのようなものとして、サーバサイドおよびクライアントサイドという用語は、サーバがシーンデータパケット1A15を決定して提供する任意のシステム1A01であり、クライアントがシーンデータパケット1A15を受信して処理する任意のシステム1A01であるような最も一般的な意味で本明細書において使用されている。同様に、サーバは制御パケット1A17を受信して処理する任意のシステム1A01であり、クライアントは制御パケット1A17を決定して提供する任意のシステム1A01である。システム1A01は、サーバまたはクライアントのいずれかとして機能し得るか、または単一のシステム1A01は、サーバおよびクライアントの両方として機能し得る。したがって、ネットワーク、トランスポート層、サーバサイド、およびクライアントサイドに関して本明細書において提供されるブロック図および説明は、例示的な実施形態の制限としてではなくむしろ情報を伝えるために有用であると考えるべきである。図1Eは、システム1A01のネットワーク1E01が任意の所与時点でサーバとして機能する1つまたは複数のシステム1A01、さらには、任意の所与の時点でクライアントとして機能する1つまたは複数のシステム1A01を備えるものとして図示しており、ここでもまた、所与のシステム1A01は、シーンデータのサーバおよびシーンデータのクライアントの両方として交互にまたは実質的に同時に機能しているものとしてよいことも理解される。
【0041】
図1Eでは、いくつかの例示的な実施形態に含まれ得る、任意選択のセンサ1E09および任意選択のセンサ出力1E11も示されている。システム1A01は、たとえば、シーン再構築で使用するために他のシステム1A01からシーンデータパケット1A15を受信することなど、またはさらなるシーン処理のために他のシステム1A01にシーンデータパケット1A15を供給することなどの、有用な機能を実行するために、センサ1E09およびセンサ出力1E11のいずれも必要としないことが理解されるであろう。代替的に、システム1A01は、任意の1つまたは複数のセンサ1E09を備えることができ、これは、限定はしないが、1)強度および偏光などの光の特性のうちのいずれかについてフィルタ処理された紫外線、可視光線、または赤外線などのマルチスペクトル範囲のデータのいずれかを検出するためのイメージングセンサ、2)ライダー、飛行時間型センサ、超音波、超広帯域、マイクロ波、および他の何らかの無線周波数ベースのシステムなどの、少なくとも部分的には距離を決定するために使用することができる距離センサまたは通信センサ、さらには、3)たとえば、体性感覚(触る)、嗅覚(臭い)、聴覚(聴く)、またはさらには味覚(味)などの他の感覚情報を検出することができる非視覚センサのうちのいずれかなどである。プレノプティックシーンデータベース1A07内で表現されるべき現実世界のシーンは、典型的には、視覚データであると一般的に理解されるであろうものを含み、このデータは、必ずしも、可視スペクトルとして知られているものに限定されず、また現実世界のシーンは、今日利用可能なセンサのうちのいずれかを使用して感知することができる大量の追加情報、さらには将来のセンサによって検出可能な追加の知られているもしくは未知のデータを含むことを理解することが重要である。例示的な実施形態の精神において、そのようなすべてのセンサは、本明細書において説明されているようにシーンの再構築、配信、および処理に有用な情報を提供するものとしてよく、したがって、センサ1E07である。同様に、これらに限らないが、2D、3D、4Dの画像表示デバイスなどの現在知られているセンサ出力1E09が多数存在しており、画像表示デバイスは、同伴する1D、2D、または3Dの聴覚的出力デバイスを含むことが多い。センサ出力1E09は、視覚、聴覚、触覚、嗅覚、または味覚さえも含む任意の形態の感覚情報を提供するための現在知られている任意の将来のデバイスも含む。任意の所与のシステム1A01は、ゼロ個以上のセンサ1E07とゼロ以上のセンサ出力1E09とを備え得る。
【0042】
次に、図1Fを参照すると、いくつかの例示的な実施形態により、少なくともエンコーダ1B11aを備えるシーンコーデック1A11のエンコーダ1B11aのブロック図が示されている。シーンコーデック1A11のAPIインターフェース1F03は、API制御ホストからのアプリケーションインターフェース(API)コール1F01を受信し、応答するが、ホストは、たとえば、アプリケーションソフトウェア1A03である。API 1F03は、パケットマネージャ1F05、エンコーダ1B11a、および非プレノプティックデータ制御1F15を含む様々なコーデックコンポーネントと通信している。API 1F03は、アプリケーションソフトウェア1A03などのホストからコマンドなどの制御信号を受信することと、ホスト制御信号のいずれかに少なくとも一部は基づき1F05、1B11a、および1F15を含む様々なコーデックコンポーネントにコマンドなどの制御信号を供給すること、1F05、1B11a、1F15を含む様々なコーデックコンポーネントからコンポーネントの状態表示などの制御信号を受信すること、コンポーネントの状態表示のいずれかに少なくとも一部は基づきアプリケーションソフトウェア1A03などのホストにコーデックの状態表示などの制御信号を供給することを行う。API 1F03の主な目的は、シーンコーデック1A11を制御するための単一の相互作用ポイントを外部ホストに提供することであり、API 1F03は、たとえば、処理要素上で実行されるソフトウェア機能のセットであり、一実施形態において、API 1F03を実行するための処理要素はシーンコーデック1A11に対して排他的である。さらに、API 1F03は、ホスト1F01によりコマンドで命令された進行中プロセスを制御するための機能を実行することができ、単一のホストコマンドでAPI 1F03と1F05、1B11a、1F15を含む様々なコーデック構成要素との間で複数の信号および通信を生成する。シーンコーデック1A11の内部プロセスのうちのいずれかを実行しているときにいつでも、API 1F03は、ソフトウェアプログラミング、特にオブジェクト指向プログラミングを熟知している者であれば理解するように、API 1F03に関して実装されたインターフェース契約に少なくとも一部は基づき状態更新などの応答がホスト1F01に提供するのに必要であるかどうかを決定する。
【0043】
なおも図1Fを参照すると、様々なコンポーネント1F05、1B11a、1F15の各々は、シーンコーデック1A11によって実装される内部プロセスのいずれかに見合った制御信号およびデータを交換するために必要に応じて互いに通信している。シーンコーデック1A11の通常の動作中に、パケットマネージャ1F05は、コーデック1A11による内部処理のための1つまたは複数の制御パケット1A17を受信し、コーデック1A11による内部処理に基づき1つまたは複数のシーンデータパケット1A15を提供する。ネットワーク接続されたシステムを熟知している者であれば理解するように、一実施形態において、シーンコーデック1A11は、パケットと呼ばれる単位に分割されたデータを伝送するためのパケット交換網と称されるもの上にデータ転送プロトコルを実装し、各パケットは、パケットを記述するためのヘッダと、パケット内で伝送されるデータであるペイロードとを含む。図1Eに関連して説明されているように、例示的な実施形態は、複数のネットワーク1E01タイプ上に実装されるものとしてよく、たとえば、シーンコーデック1A01を使用する複数のシステムは、パケット交換網1E01であるインターネット上で通信している。インターネットなどのパケット交換網1E01は、TCP(伝送制御プロトコル)またはUDP(ユーザデータグラムプロトコル)などのトランスポート層1E03のプロトコルを使用する。
【0044】
TCPは、当技術分野でよく知られており、メッセージの受信確認、再送およびタイムアウト、ならびに伝送データ列の適切な順序付けなどの多くの利点を提供するが、典型的には、単一のサーバシステム1A01がデータを各単一のTCPストリームごとに単一のクライアントシステム1A01に提供する、当技術分野においてユニキャスティングと呼ばれるものに限定される。TCPを使用することで、単一のサーバシステム1A01が、伝送された制御パケット1A17およびデータパケット1A15が単一のTCP接続を形成する2つのシステム間で排他的に交換されることを理解した上で、複数のクライアントシステム1A01による複数のTCPストリームをセットアップすること、およびその逆のことがなおも可能である。UDP(ユーザデータグラムプロトコル)などの他のデータ伝送プロトコルは、当技術分野でマルチキャスティングと称されるものをサポートすること、またはブロードキャスティングと称されるものをサポートすることについて知られており、ユニキャスティングとは異なり、これらのプロトコルは、たとえば、複数のクライアントシステム1A01がシーンデータパケット1A15の同じストリームを受信することを可能にする。UDPは、クライアントによる受信時に伝送データが確認されず、パケットの送信順序が維持されないという点で制限がある。パケットマネージャ1F05は、パケット1A17および1A15を通信するためのTCPまたはUDPトランスポート層プロトコルの少なくともいずれかに基づき利用可能なデータ転送プロトコルのうちのいずれか1つを実装するように適合されてよく、新しいプロトコルが将来、利用可能になる可能性があるか、または既存のプロトコルがさらに適応される可能性があり、実施形態は、データ転送プロトコルまたはトランスポート層プロトコルの任意の単一の選択に不必要に制限されるべきではなく、むしろ、シーンコーデック1A01を使用するシステムの特定の構成を実装するために選択されたプロトコルは、特定の実施形態の多くの特徴の所望の実装に基づき選択されるべきである。
【0045】
なおも図1Fを参照すると、パケットマネージャ1F05は、たとえば、パケットのヘッダおよびペイロードのいずれかを処理することによって、各受信された制御パケット1A17を解析し、様々なタイプのパケット1A17の内容を決定するが、これは、限定はしないが、1)プレノプティックシーンデータに対するユーザ要求、2)非プレノプティックシーンデータに対するユーザ要求、3)シーンデータ使用情報、および4)クライアント状態情報を含む。パケットマネージャ1F05は、プレノプティックシーンデータに対するユーザ要求に関係する情報のいずれかをエンコーダ1B11aに提供し、エンコーダ1B11aは、プレノプティックシーンデータベース1A07にアクセスするために、少なくとも一部はクエリプロセッサ1F09を使用してユーザの要求を処理する。クエリプロセッサ1F09は、少なくとも一部は、サブシーンまたはサブシーンへのインクリメントを含む要求されたプレノプティックシーンデータを効率的に抽出するためのサブシーン抽出器1F11を備える。次いで、抽出された要求済みプレノプティックシーンデータは、要求側(クライアント)システム1A05に伝送するためのシーンパケット1A15内にペイロードとして挿入するために、パケットマネージャ1F05に提供される。一実施形態において、パケットマネージャ1F05は、好ましくは、要求されたプレノプティックシーンデータを含むシーンデータパケット1A15内に元のユーザ要求を識別するのに十分な情報をさらに挿入し、受信側クライアントシステム1A05が元のユーザ要求の指示および元の要求を遂行するために提供されたプレノプティックシーンデータの両方を受信するようにする。動作中、エンコーダ1B11a、クエリプロセッサ1F09、パケットマネージャ1F05、および特にサブシーン抽出器1F11のうちのいずれかがコーデックSPU1F13を呼び出してプレノプティックシーンデータベース1A07を効率的に処理するものとしてよく、コーデックSPU1F13は、プレノプティックシーンデータベース1A07に関する表現および表現の組織化を効率的に処理するために本明細書において説明されている様々な技術的利点を実装するように構成され得る。
【0046】
例示的な実施形態における表現は現実世界のシーンをプレノプティックシーンモデルとして表現する際に使用され、これらの表現の新規性のある組織化はプレノプティックシーンデータベース1A07において使用される。プレノプティックシーンデータベース1A07を処理するための、例示的な実施形態において、実施形態で使用される表現および組織化の組合せによる、装置および方法は、非常に大きく、複雑で詳細な現実世界のシーンを潜在的に表すプレノプティックシーンデータベースに対して効率的にクエリを実行し、次いで、要求されたサブシーンまたはサブシーンへのインクリメントを迅速に、また効率的に抽出する能力などの著しい技術的利点をもたらす。コンピュータシステムを熟知している者であれば理解するように、シーンコーデック1A11は、ソフトウェアおよびハードウェアの多くの組合せで実装でき、これは、たとえば、汎用CPU上で実行されるC++などの高水準プログラミング言語、またはFPGA(フィールドプログラマブルゲートアレイ)上で実行される組み込みプログラミング言語、またはASIC(特定用途向け集積回路)に備えられている実質的にハードコーディングされた命令セットを含む。さらに、シーンコーデック1A11のコンポーネントおよびサブコンポーネントはいずれも、ソフトウェアおよびハードウェアの異なる組合せで実装されるものとしてよく、一実施形態において、コーデックSPU1F13は、ASIC内に備えられているような実質的にハードコーティングされた命令セットとして実装される。代替的に、いくつかの実施形態では、コーデックSPU1F13の実装は、少なくともシーンコーデック1A11と通信している別個のハードウェアチップであり、事実上コーデックSPU1F13はシーンコーデック1A11の外部にある。
【0047】
コンピュータシステムを熟知している者であれば理解するように、シーンコーデック1A11は、プレノプティックシーンデータベース1A07の少なくとも一部もしくは全部、またはプレノプティックシーンモデルに最も関連するデータベース1A07のコピーされた部分を保持するためのメモリもしくは他の何らかの形のデータストレージ要素をさらに備えるものとしてよく、コピーされた部分は、たとえば、キャッシュとして当技術分野で知られているものに実装され得る。注意すべき重要なことは、プレノプティックシーンデータベース1A07がシーンコーデック1A11の外にあるように現在は表されているが、現在のシーンコーデックの代替的実施形態では、プレノプティックシーンデータベース1A07の少なくとも一部分がシーンコーデック1A11内に、さらにはエンコーダ1B11a内に維持されるということである。したがって、少なくともエンコーダを有するシーンコーデックについて現在表されているブロック図は例示的なものであり、したがって、例示的な実施形態の制限として考慮されるべきではなく、シーンコード1A11の様々なコンポーネントおよびサブコンポーネントの多くの変更形態および構成は、説明されている実施形態の精神から逸脱することなく可能であることを理解することが重要である。
【0048】
なおも図1Fを参照すると、パケットマネージャ1F05は、シーンデータ使用情報のいずれかをエンコーダ1B11aに提供し、エンコーダ1B11aは、使用情報、または使用情報に少なくとも一部は基づき計算された他の情報を、プレノプティックシーンデータベース1A07に挿入する(使用情報についてより詳細は、特に、次に示すプレノプティックデータベースデータモデルビューについては図4Cを、次に示すユースケースについては図5、図6、および図7を参照のこと)。さらに説明されているように、使用情報は、少なくとも、ユーザの要求に理想的にサービスするためのサブシーンまたはシーンインクリメントの情報範囲の決定を含む例示的な実施形態の機能を最適化する上で非常に価値がある。パケットマネージャ1F05は、クライアント状態情報のいずれかをエンコーダ1B11aにも提供し、エンコーダ1B11aは、クライアントシステム1A01から受信されたクライアント状態情報のいずれかに少なくとも一部は基づきクライアント状態1F07を維持する。シーンコーデック1A11は、複数のクライアントシステム1A01をサポートすることができ、サポートされたクライアントシステム1A01ごとに、異なるクライアント状態1F07が維持されることを理解することは重要である。特に次に示すユースケースに関連して図5、図6、および図7でさらに説明されるように、クライアント状態1F07は、エンコーダ1B11aが、クライアントシステム1F07にすでに正常に受信されており、利用可能であるプレノプティックシーンデータベース1A07情報の範囲を決定することを可能にする上で少なくとも十分である。
【0049】
いくつかのタイプの他のシーンデータ1F19(動画など)を提供するための従来のコーデックとは異なり、エンコーダ1B11aを有するシーンコーデック1A11は、プレノプティックシーンデータ1A07または他のシーンデータ1F19のうちのいずれかを要求側クライアントシステム1A01に提供する。また、従来のコーデックとは異なり、シーンコーデック1A11によって提供される少なくともプレノプティックシーンデータ1A07は、クライアントシステム1A01によって受信され、処理されるときに必ずしも完全に消費されない性質のものである。たとえば、従来のコーデックは、MPEGなどの何らかの形式で典型的にエンコードされた一連の画像フレームを含む動画をストリーミングする場合、画像のエンコードされたストリームが従来のクライアントシステムによってデコードされると、各々の次のデコードされる画像はユーザにリアルタイムで本質的に提示され、その後、デコードされた画像は本質的にさらなる価値を有しないか、またはユーザが次のデコードされた画像を提示されるときに少なくともさらなる差し迫った価値を有さず、画像のストリーム全体が受信され、デコードされ、提示されるまで、同様にして続く。
【0050】
対照的に、現在のシーンコーデック1A11は、追加の実質的な将来の価値を保持しながらクライアントシステム1A01のユーザに両方ともすぐに使用可能であるサブシーンまたはシーンインクリメントなどの少なくともプレノプティックシーンデータ1A07を提供する。少なくとも次に示すユースケースに関して図5、図6、および図7でさらに説明されるように、たとえば、エンコーダ1B11aを有するコーデック1A11は、シーンデータパケット1A15内でサーバのプレノプティックシーンデータベース1A07のいくつかの要求された部分を表すサブシーンまたはサブシーンインクリメントを伝送し、次いで、シーンデータパケット1A15は、ユーザへの即時データ提供さらにはクライアントのプレノプティックシーンデータベース1A07への挿入を含む2つの実質的に同時進行の目的のために要求側クライアントシステム1A01によって受信され、デコードされる。次いで、さらに理解されるべきことは、受信されたプレノプティックサブシーンまたはサブシーンインクリメントをクライアントデータベース1A07内に挿入することによって、挿入されたシーンデータは、次いで、サーバのプレノプティックシーンデータベース1A07からの追加のシーンデータを必要とすることなくクライアントのプレノプティックシーンデータベース1A07から直接受け取る将来の潜在的なユーザ要求に応答する際に後で使用するために利用可能にされることである。クライアントのプレノプティックシーンデータベース1A07にサブシーンまたはサブシーンインクリメントを挿入した後、クライアントシステム1A01は、次いで、提供側シーンコーデック1A11へのフィードバックとしてクライアント状態情報を提供し、クライアント状態情報は、制御パケット1A17内で提供され、解析されたクライアント状態情報は、対応するクライアント状態1F07を更新し、維持するためにエンコーダ1B11aによって使用される。
【0051】
クライアントシステム1A01に提供されるシーンデータパケット1A15のストリームに関連付けられているクライアント状態1F07を受信し、維持することによって、エンコーダ1B11aを有するコーデック1A11は、次いで、対応するクライアントシステム1A01から受信されたユーザの次の要求を満たすために必要な新しいサーバのプレノプティックシーンデータベース1A07情報の少なくとも最小の範囲を決定することができる。いくつかのユースケースでは、クライアントシステム1A01は、エンコーダ1B11aを有するシーンコーデック1A11を備える2つ以上のサーバシステム1A01からプレノプティックシーンデータを受信していることを理解することも重要である。これらのユースケースでは、クライアントシステム1A01は、好ましくは、すべてのサーバシステム1A01から受信されたシーンデータパケット1A15に基づきクライアントの状態情報の変更に関して各サーバシステム1A01に通知する。このような配置構成において、複数のサービングシステム1A01が、負荷分散状況で使用され、それにより、サービングシステム1A07すべてがまとめて単一の仮想プレノプティックシーンデータベース1A07を提供しているかのように、サービングシステム1A01のうちのいずれかのプレノプティックシーンデータベース1A07を使用して単一のクライアントシステム1A01からなされたユーザ要求を都合よく遂行することが可能である。
【0052】
なおも図1Fを参照すると、パケットマネージャ1F05は、非プレノプティックシーンデータに対するユーザ要求のうちのいずれかを非プレノプティックデータ制御1F15に提供し、非プレノプティックデータ制御1F15は、1つまたは複数の非プレノプティックデータエンコーダ1F17と通信している。非プレノプティックデータエンコーダ1F17は、他のシーンデータデータベース1F19からデータ制御1F15に他のシーンデータを提供する任意のソフトウェアまたはハードウェアコンポーネントまたはシステムを含む。いくつかの実施形態において、エンコーダ1B11aを有するコーデック1A11は、他のシーンデータデータベース1F19内に含まれるような他のシーンデータへのアクセスを必要とせず、したがって、非プレノプティックデータエンコーダ1F17へのアクセスを必要としないか、またはコーデック1A11内の非プレノプティックデータ制御1F15の実装すら必要としないことを理解することが重要である。サーバのプレノプティックシーンデータベース1A07内に含まれるようなプレノプティックシーンデータおよび他のシーンデータデータベース1F19内に含まれるような他のシーンデータの両方の何らかの組合せのエンコーディングを必要とするか、または必要とすることを予想し得るエンコーダ1B11aを有するシーンコーデック1A11の実施形態について、シーンコーデック1A11は、少なくとも一部は、任意の1つまたは複数のシーンデータパケット1A15のペイロードの少なくとも一部を決定するために非プレノプティックデータエンコーダ1F15によって提供されるような他のシーンデータを使用する。例示的な他のシーンデータ1F19は、動画、音声、グラフィックス、テキスト、または他の何らかのデジタル情報を含む、プレノプティックシーンデータベース1A07の情報(プレノプティックシーンデータベース1A07の情報の説明については特に次に示す図4Cを参照のこと)ではない任意の情報を含み、この他のデータは、制御パケット1A17内に含まれるようなクライアントシステム1A01の要求に応答するために必要であると決定される。たとえば、プレノプティックシーンデータベース1A07内のシーンは、データベース1F19に収められている他のシーンデータが、家電製品などの家の中にある物体に関係する製品動画などの、関係する動画、音声、グラフィックス、テキスト、または他の何らかのデジタル情報のいずれかを含む、売り家であってもよい。
【0053】
プレノプティックシーンデータベース1A07は、プレノプティックシーンデータのいずれかとの関連付けのために従来の動画、音声、グラフィックス、テキスト、または他の何らかの形のデジタル情報のいずれかを収めるための機能を備え(さらなる詳細については特に次に示す図4Cを参照)、したがって、エンコーダ1B11aを備えるシーンコーデック1A11は、サーバのプレノプティックシーンデータベース1A07または他のシーンデータデータベース1F19のいずれかから取り出された動画、音声、グラフィックス、テキスト、または他の何らかの形のデジタル情報などの他のデータを提供することができるということに留意することが重要である。コンピュータシステムを熟知している者であれば理解するように、異なる形態のデータを異なる形態のデータベースに収めることは有益であり、次いで、異なる形態のデータベースは、データをストレージに収め、またそこから取り出す異なる手段にあるものとしてもよく、たとえば、いくつかの手段は、データストレージコストの観点からより経済的であり、他の手段は、取り出し時間の観点からより経済的であり、したがって、当業者には、少なくともいくつかの実施形態においてプレノプティックシーンデータを任意の他のシーンデータから実質的に分離することが好ましいことは明らかであろう。
【0054】
非プレノプティックデータエンコーダ1F17は、少なくとも他のシーンデータデータベース1F19にアクセスし、データ制御1F15に提供するために少なくともいくつかの他のシーンデータを取り出すことができる任意の処理要素を備える。本発明のいくつかの実施形態において、シーンデータを他の非シーンデータと関連付ける情報は、プレノプティックシーンデータベース1A07内に維持され、それにより、非プレノプティックデータエンコーダ1F17は、好ましくは、ユーザの要求を満たすためにサーバプレノプティックシーンデータベース1A07にアクセスし、他のシーンデータ1F19のうちの何が他のシーンデータデータベース1F19から取り出されるべきかを決定する。一実施形態において、非プレノプティックデータエンコーダ1F17は、第1の形式の他の何らかのシーンデータを取り出し、第1の形式を第2の形式に翻訳し、次いで、第2の形式の翻訳されたシーンデータをデータ制御1F15に提供することができる処理要素のうちのいずれかを備える。少なくとも1つの実施形態において、第1の形式は、たとえば、非圧縮の動画、音声、グラフィックス、テキスト、または他の何らかの形のデジタル情報であり、第2の形式は、動画、音声、グラフィックス、テキスト、または他の何らかの形のデジタル情報を表すための圧縮形式のうちのいずれかである。別の実施形態において、第1の形式は、たとえば、動画、音声、グラフィックス、テキスト、または他の何らかの形のデジタル情報を表現するための第1の圧縮形式のいずれかであり、第2の形式は、動画、音声、グラフィックス、テキスト、または他の何らかの形のデジタル情報を表現するための第2の圧縮形式のいずれかである。また、少なくともいくつかの実施形態において、非プレノプティックデータエンコーダ1F17は、形式の変換なしでデータ制御1F15に提供するためにデータベース1F19から他のシーンデータを単に抽出することが予想され、抽出された他のシーンデータは、すでに圧縮形式であるか、または非圧縮形式であるかのいずれかである。
【0055】
なおも図1Fを参照すると、ユーザ要求が、たとえば、プレノプティックシーンデータのレンダリングされたビューに基づきプレノプティックシーンデータおよび他のシーンデータに対するものである可能性がある。このユースケースでは、最初のユーザ要求は、要求されたプレノプティックシーンデータを抽出し、次いで、抽出されたプレノプティックシーンデータを非プレノプティックデータ制御1F15に提供するエンコーダ1B11aにパケットマネージャ1F05によって提供される。次いで、データ制御1F15は、非プレノプティックデータを非プレノプティックデータエンコーダ1F17に提供し、これはプレノプティックシーンデータをたとえばシーンの要求されたレンダリング済みビューに翻訳することができ、次いで、他のシーンデータであるこのレンダリングされたビューは、1つまたは複数のシーンデータパケット1A15のペイロードに含めるためにデータ制御1F15に提供される。特に次に示す図1Gに関連して明らかにされるように、代替的に、抽出されたプレノプティックシーンデータは、単純に、1つまたは複数のシーンデータパケット1A15でクライアントシステム1A01に伝送されることも可能であり、次いで、クライアントシステム1A01上のデコーダ1B11bを含むコーデック1A11は、シーンデータパケット1A15で受信された抽出済みプレノプティックシーンデータを使用して、要求されたシーンビューをレンダリングする。熟慮するとわかるように、このような柔軟性により、任意の所与のユーザ要求を最も効率的に満たすための複数のオプションを伴うシーンコーデック1A11を使用する通信システムのネットワークが形成される。
【0056】
なおも図1Fを参照すると、エンコーダ1B11aを備えるシーンコーデック1A11が処理できるシーンデータの同時ストリームの数に制限はなく、エンコーダを有するコーデック1A11は、典型的には単一のデコーダ(ユニキャストと称されることが多い)または複数のデコーダ(マルチキャストもしくはブロードキャストと称されることが多い)のいずれかにデータの単一ストリームを提供する従来のエンコーダを有するコーデックとはこの点で異なることは理解されるべきである。特に、前の図1Eに関して示されているように、本発明のいくつかの例示的な実施形態は、単一のサービングシステム1A01(少なくともエンコーダ1B11aを備えるシーンコーデック1A11を含む)と複数のクライアントシステム1A01(少なくともデコーダ1B11bを備えるシーンコーデック1A11を含む)との間の1対多の関係を提供する。本発明のいくつかの実施形態は、単一のクライアントシステム1A01と複数のサービングシステム1A01との間の多対1の関係、さらには複数のサーバシステム1A01と複数のクライアントシステム1A01との間の多対多の関係も提供する。
【0057】
次に図1Gを参照すると、少なくともデコーダ1B11bを備えるシーンコーデック1A11のブロック図が示されている。図1Gにおいて説明されている要素の多くは、図1Fのものと同じか、または類似しており、したがって、あまり詳しくは説明しないことにする。前に説明したように、API制御ホスト1F01は、たとえば、シーンコーデック1A01を使用してシステム上で、またはシステムと通信しながら実行されているアプリケーションソフトウェア1A03であり、たとえば、ソフトウェア1A03は、ユーザインターフェース(UI)を完全にまたは部分的に実装するか、またはUIと通信するかのいずれかである。最終的に、人間またはオートマトンなどのユーザは、UIを使用して1つまたは複数の明示的または暗黙の指示を提供し、これらの指示は、少なくとも一部はシーンデータに対する1つまたは複数のユーザ要求1G11を決定するために使用される。一般的な意味で、ユーザ要求1G11を決定するシーンコーデック1A01を使用する任意のシステムは、本明細書ではクライアントシステム1A01と称される。これまでに説明されたように、また、特に次に示すユースケースに関連して図5、図6、および図7でさらに説明されるように、クライアントシステム1A01が、所与のユーザ要求1G11を満たすのに十分なシーンデータを有することが可能であり、望ましいことですらある。しかしながら、可能で有用なシーンデータの総体は、任意の所与のクライアントシステム1A01のキャパシティをはるかに超える可能性が高いことも理解されるべきであり、たとえば、クライアントシステム1A01を実装するためのコンピューティングプラットフォームは、モバイルコンピューティングデバイス、またはドローンもしくはロボットなどのオートマトンの中に埋め込まれたコンピューティング要素である。したがって、いくつかの例示的な実施形態は、1つまたは複数のユーザ要求1G11を決定する所与のクライアントシステム1A01が、シーンコーデック1A01を使用する任意の数の他のシステムにネットワーク1E01上でアクセスすることができ、これらの他のシステム1A01の1つまたは複数の任意のシステムは、所与のユーザ要求1G11を満たすのに十分なシーンデータにアクセスできるか、またはそのようなシーンデータを含み得ることを提供する。次いで、この図に関連してさらに説明されるように、ユーザ要求1G11は、少なくともエンコーダ1B11aを含むシーンコーデック1A11を備える別のシステム1A01にネットワーク上で通信されてもよく、この別のシステム1A01は、本明細書ではサーバシステム1A01と称され、最終的に、ユーザ要求1G11を満たすための1つまたは複数のシーンデータパケット1A15をクライアントシステム1A01に提供することになる。
【0058】
シーンコーデック1A01を使用する任意の所与のシステムが、クライアントシステム1A01のみである、またはサーバシステム1A01のみであるという機能に限定されるべき制限はなく、特に図5、図6、および図7に関連して説明されるように、所与のシステム1A01は、クライアントおよびサーバのいずれかまたは両方としていつでも動作することができ、クライアントはデコーダ1B11bを含むコーデックを備え、サーバはエンコーダ1B11aを含むコーデックを備え、それにより、デコーダ1A11bおよびエンコーダ1A11aの両方を含むコーデック1A11を備えるシステム1A01は、クライアントシステム1A01およびサーバシステム1A01の両方として機能することができる。
【0059】
なおも図1Gを参照すると、デコーダ1B11bを備えるコーデック1A11において、APIホスト1F03は、パケットマネージャ1F05、デコーダ1B11b、および非プレノプティックデータ制御1F15を含む様々なコーデックコンポーネントと通信している。パケットマネージャ1F05は、ユーザの所望のシーンデータをサーバシステム1A01と通信するのに十分な数多くの可能な様々な形態のうちのいずれかの形態のユーザ要求1G11を受信し、シーンデータは、プレノプティックシーンデータベース1A07内に含まれるシーンデータのうちのいずれか、および/または別のシーンデータデータベース1G07内に含まれる他のシーンデータのうちのいずれかを含むことと広く理解される。他のシーンデータは、動画、音声、グラフィックス、テキスト、または他の何らかの形のデジタル情報のうちのいずれかを含む。他のシーンデータは、特に補助情報として、プレノプティックシーンデータベース1A07内に収められ、プレノプティックシーンデータベース1A07から取り出されてもよい(次に示す図4Cに関する要素4C21を参照のこと)。本明細書全体を通して、本明細書では様々なデータタイプを示すための記述が用意され、これはシーンモデルと、シーンモデルの拡張、翻訳、インデックス、および使用履歴を含む補助情報とを含む、プレノプティックシーンデータベース1A07を含むものとして一般的に参照される。シーンモデルは、一般的に、マターフィールドおよびライトフィールドの両方を含み得る。
【0060】
本出願において説明されている様々なタイプのシーンデータおよび他のシーンデータを分類することが可能であることに留意すべきであり、たとえば、この分類は、GUID(グローバル一意識別子)またはUUID(普遍的一意識別子)の形をとることができる。さらに、他のシーンデータとの可能な関連付けのために実シーンをシーンモデルに再構築することについて本明細書において説明されている本発明の構造は、事実上無数の現実世界のシーンに適用可能であり、次いで、シーンモデルとして利用可能な現実世界の(またはコンピュータで生成された)シーンのタイプに対する分類を提供することもまた有用である。したがって、様々な可能なタイプのシーンモデルを表すためにGUIDまたはUUIDを割り当てることも可能である(たとえば、都市景観、建物、自動車、家など)。また、別のGUIDもしくはUUIDを使用して、自動車のタイプを「2016年型Mustang xyz」として識別するなど、シーンのタイプの特定のインスタンスを一意に識別することも可能であり得る。これもまた理解されるように、シーン情報を要求する所与のユーザを匿名のままにするか、または同様にそのユーザにGUIDまたはUUIDを割り当てることを可能にし得る。また、シーンコーデック1A01を使用する各システムが、サーバおよび/またはクライアントとして動作するかどうかにかかわらず、GUIDまたはUUIDを割り当てられることも可能である。さらに、ユーザ要求1G11を、ユーザ要求のタイプ(「新規サブシーン要求」、「サブシーンインクリメント要求」、「シーンインデックス要求」など)に分類することも可能であり、ユーザ要求のタイプおよび実際のユーザ要求の両方にGUIDまたはUUIDを割り当てることができる。
【0061】
いくつかの実施形態において、パケットマネージャに提供するためにGUIDまたはUUIDなどの1つまたは複数の識別子が特定のユーザ要求1G11とともに含まれ、次いで、パケットマネージャは1つまたは複数の追加の識別子を含むことができ、それにより、デコーダ1B11bを備えるシーンコーデック1A11によって発行される制御パケット1A17は有意義なユーザ要求分類データを含み、この分類データはいずれも、少なくとも、1)ユーザの要求にサービスするサーバシステム1A01によって維持されているプレノプティックシーンデータベース1A07、またはユーザの要求にサービスするサーバシステム1A01などの1つまたは複数のシステム1A01に一般的に利用可能にされる外部ユーザ要求データベースなどのデータベースに収め、2)ユーザ要求1G11/制御パケット1A17のルーティングまたはシーンデータ提供の負荷分散のうちのいずれかを決定するために使用可能であり、任意の1つまたは複数の要求トラフィック処理エージェントは、特にユーザ要求1G11の負荷とサーバシステム1A01の利用可能性およびネットワーク帯域幅とのバランスをとることを目的として、ネットワーク1E01上でクライアントおよびサーバシステム1A01のうちの任意の1つまたは複数のシステムと通信して制御パケット1A17の経路選択または再経路選択を行うことができ、これらはすべて、ネットワーク接続されたシステムおよびネットワークトラフィックの管理を熟知している者であれば理解するであろう。
【0062】
なおも図1Gを参照すると、一実施形態において、クライアントシステム1A01はサーバシステム1A01と単独で通信しており、クライアントシステム1A01は、制御パケット1A17内に含まれるユーザ要求1G11を提供し、サーバシステムは、ユーザ要求1G11を満たすシーンデータパケット1A15をその見返りに提供する。別の実施形態において、クライアントシステム1A01は、2つ以上のサーバシステム1A01によるサービスされる。図1Fに関連して説明されているように、サーバシステム1A01は、好ましくは、任意の要求されたシーンデータ(または他のシーンデータ)とともにシーンデータパケット1A15内の情報を識別することを含み、それにより、クライアントシステム1A01上のコーデック1A11は、クライアントシステム1A01のプレノプティックシーンデータベース1A07内に収められているか、またはクライアントシステム1A01の他のシーンデータデータベース1G07内に収められている応答された要求を含む受信されたシーンデータの状態を追跡することができる。動作中、所与のシーンデータパケット1A15は、パケットマネージャ1F05によって受信され、解析され、次いで、任意の非プレノプティックシーンデータが、非プレノプティックデータ制御に提供され、任意のプレノプティックシーンデータがデコーダ1B11bに提供され、任意のユーザ要求識別データがデコーダ1B11bに提供される。
【0063】
非プレノプティックデータ制御1F15は、他のシーンデータデータベース1G07またはクライアントシステム1A01のプレノプティックシーンデータベース1A07のいずれかに好ましくは補助情報としてデコードすることおよび/または収めることのいずれかのために任意の非プレノプティックシーンデータを非プレノプティックデータデコーダ1G05のうちの1つまたは複数に提供する(たとえば、図4Cを参照のこと)。ここでもまた、非プレノプティックシーンデータは、たとえば、動画、音声、グラフィックス、テキスト、または他の何らかの形のデジタル情報のうちのいずれかを含み、そのようなデータのデコーダは、当技術分野でよく知られており、一定のさらなる開発の下にあり、したがって、利用可能な、または利用可能になるべき非プレノプティックシーンデータデコーダのいずれかが、いくつかの実施形態によって、非プレノプティックデータデコーダ1G05として使用可能であることが理解されるべきである。
【0064】
デコーダ1B11bは、プレノプティックシーンデータを受信し、少なくとも一部は、サブシーン挿入器1G03を備えるクエリプロセッサ1G01を使用して、プレノプティックシーンデータをクライアントシステム1A01のプレノプティックシーンデータベース1A07に挿入する。図1Fに関して前に述べたように、クライアントのプレノプティックシーンデータベース1A07は、内部または外部データメモリもしくはストレージの任意の組合せとして実装されてよく、たとえば、デコーダ1B11bは、ユーザによって必要とされ、要求されることが最も予想されるクライアントのプレノプティックシーンデータベース1A07の実質的な部分を収めるための高速内部メモリを備え、そうでなければ、クライアントのプレノプティックシーンデータベース1A07の追加の部分は、デコーダ1B11bの外部に収められる(が、必ずしもデコーダ1B11bを含むシーンコーデック1A01を使用するシステムの外部ではない)。エンコーダ1B11aと同様に、動作中、デコーダ1B11b、クエリプロセッサ1G01、特にサブシーン挿入器1G03のいずれかが、プレノプティックシーンデータベース1A07を効率的に処理するためにコーデックSPU1F13を呼び出してもよく、コーデックSPU1F13は、プレノプティックシーンデータベース1A07に関する表現および表現の組織化を効率的に処理するために本明細書において説明されている様々な技術的利点を実装することを意図したものである。
【0065】
なおも図1Gを参照すると、デコーダ1B11bは、1)クライアント状態1F05を更新すること、および2)ユーザ要求が満たされたことをAPI 1F03を介してAPIホスト1F01に通知することのうちのいずれかに対するユーザ要求識別データのいずれかを受信する。デコーダ1B11bは、また、デコーダ1B11bの内部動作のうちのいずれかに基づきクライアント状態1F05を更新してもよく、クライアント状態1F05の目的は、少なくとも、利用可能なクライアントシステム1A01のプレノプティックシーンデータベース1A07および他のシーンデータデータベース1G07の現在の状態を正確に表すことを含むことを見ておくことは重要である。ユースケースに関して図5、図6、および図7でさらに詳しく説明されるように、クライアント状態1F05の情報は、利用可能なクライアントシステム1A01のプレノプティックシーンデータベース1A07および他のシーンデータデータベース1G07のうちのいずれかを使用して所与のクライアントユーザ要求がクライアントシステム1A01のローカルで満たされ得るかどうかを効率的に決定するために少なくとも部分的に使用する上でクライアントシステム1A01にとって少なくとも有用であるか、または別のサーバシステム1A01によって提供されなければならない追加のシーンデータもしくは他のシーンデータを必要とし、その場合、クライアントユーザの要求は制御パケット1A17にパッケージ化され、特定のサーバシステム1A01または負荷分散コンポーネントに伝送され、それによりユーザの要求を満たすための適切なサーバシステム1A01を選択する。クライアント状態1F05の情報は、少なくともユーザの要求を満たすのに十分な最低限の量のシーンデータまたは他のシーンデータを効率的に決定するために負荷分散コンポーネントまたは最終的に、特定のサーバシステム1A01のうちのいずれにも有用である。
【0066】
特定のユーザ要求が満たされたという指示をAPI 1F03を介して受信した後、アプリケーションソフトウェア1A03などのAPI制御ホスト1F01は、次いで、クライアントシステム1A01に、要求されたデータをユーザに提供させ、ここでもまた、ユーザは人間であるか、または自律的であるかのいずれかであり得る。動画および音声を出力するためのディスプレイで使用するフリービュー形式、またはオブジェクトへのローカル方向およびオブジェクトの外観の確認を含むシーンオブジェクト識別情報を要求したオートマトンで使用するエンコード形式などの、シーンデータおよび他のシーンデータを提供するための多くの可能な形式があると理解されるべきである。見るべき重要なことは、デコーダ1B11bを備えるコーデック1A11が、ユーザ要求1G11を1つまたは複数のサーバシステム1A01に提供し、次いで、最終的にユーザが何らかのユーザインターフェース手段を通じて何らかの形式で要求されたデータを受信するようにシーンデータパケット1A15を受信し処理する動作を行っていることである。デコーダ1B11bを備えるコーデック1A11は、現在のクライアント状態1F05を追跡する動作をしており、それにより、クライアントシステム1A01はクライアント状態1F05の情報のうちのいずれかを使用して、所与のユーザ要求がクライアントシステム1A01のローカルで満たされ得るかどうかを少なくとも一部は決定するか、または別のサーバシステム1A01によって提供されなければならないシーンまたは他のデータを必要とすることを見ることも重要である。デコーダ1B11bを備えるコーデック1A11を使用するクライアントシステム1A01は、任意選択で、特に制御パケット1A17においてエンコードされるような任意のユーザ要求1G11とともに、たとえば分類子を含む様々な可能な一意の識別子のうちの1つまたは多数を提供し、クライアントシステム1A01またはサービングシステム1A01の少なくともいずれかによる様々な可能な一意の識別子の追跡が、任意の1つまたは複数のクライアント1A01および任意の1つまたは複数のサーバ1A01の全体的性能を(機械学習を使用することなどによって)最適化するのに有用であることを見ることは、さらに重要である。エンコーダ1B11aを備えるコーデック1A11のように、デコーダ1B11bを備えるコーデック1A11は、それぞれ、様々な抽出操作および挿入操作の少なくとも実行速度を著しく向上させるためにコーデックSPU1F13にアクセスできることを見ることも重要であり、すべて本明細書においてより詳細に説明される。
【0067】
なおも図1Gに関して、デコーダ1B11bを備えるコーデック1A11がシーンデータパケットを処理するときに、処理メトリックスまたは情報のうちのいずれかが、クライアント状態1F07への変化とともに使用データとして提供され得るが、使用データは、少なくとも、所与のユーザ要求がサブシーン(売りに出されている家のシーンモデルなど)を提供することによって満たされ得るという点でユーザ要求とは異なるが、クライアントシステム1A01は、次いで、ユーザがこの提供されたシーンモデルをどのようにインタラクティブに操作するかを追跡し、たとえば、ユーザは人間であり、追跡される使用情報は、ユーザによってアクセスされたホームシーンモデル内の部屋、アクセスの持続時間、各部屋で撮影された視点などを指す。現実世界のシーンモデルおよびコンピュータで生成されたシーンモデルの任意の組合せを表す可能なシーンモデルが事実無数あるのと全く同様に、追跡することができ、例示的な実施形態の機械学習の態様にとって少なくとも価値があるであろう少なくとも非常に多くの使用分類およびその他の何らかの形の情報が存在することは理解されるべきであり、本明細書において説明されている機械学習の少なくとも1つの機能は、ユーザの要求を満たす方法を決定するときにサブシーンまたはサブシーンインクリメントの最良の情報範囲を推定することである。
【0068】
たとえば、ユーザが聖クレメント大聖堂のナルテックスなどの特定の都市の位置から始まるプラハ(特に図5を参照)などの都市の観光を要求している場合、システムは、どの程度の情報範囲で最初のナルテックスのサブシーンがユーザに提供されるかを決定しなければならず、一般に、範囲を広くとることは、ユーザにシーン消費のより大きな初期自由を許すが、一般に、範囲を狭めることで、伝送されるシーンデータを減らして応答時間を短縮できる。説明されるように、シーンの自由度は、少なくとも、フリービュー、フリーマター、およびフリーライティングを含み、たとえば、フリービューは、ナルテックスから移動して聖クレメント大聖堂に入るか、またはナルテックスから移動して通りを歩いて渡り、ターンして、聖クレメント大聖堂の仮想画像をキャプチャするなどのサブシーン内の空間的移動を含む。慎重に考察するとわかるように、提供されるサブシーンを消費するための可能なユーザ選択の各々では、必要とするマターフィールドおよびライトフィールドのデータを含む情報範囲が広がる一方となり得る。この点に関して、例示的な実施形態では、複数のユーザおよびユーザインシデントにわたってシーン使用状況を追跡することによって、蓄積された使用情報は、たとえば、ユーザによる「x」量のシーン移動を可能にするのに必要となるであろうマターフィールドまたはライトフィールドの情報範囲を推定するために本明細書において説明されている機械学習コンポーネントによって使用され得ることを提示しており、次いで、Xは、シーン移動を典型的には体験する時間のY量に関連付けることができ、それにより、システムは、すべての知られている使用状況および現在追跡されているユーザシーン移動に基づき新しいシーンデータをユーザがいつ必要とする可能性が高いかを先読みして予測することができ、次いで、そのような先読みは、より多くの新しいシーンデータがサーバシステム1A01によって提供されるように追加の(暗黙の)ユーザ要求1G11をトリガーするために自動的に使用され得る。
【0069】
図1Gには表されていないが、シーンデータパケット1A15で受信され、デコーダ1B11bを備えるコーデック1A11によって処理される任意の非プレノプティックデータまたは他のシーンデータは、適切なセンサ出力1E11(図1E参照)のうちのいずれかに直接提供され、それにより、要求されたデータを要求側ユーザに提供するものとしてもよく、たとえば、センサ出力1E11は、従来のディスプレイ、ホログラフィックディスプレイ、またはVRヘッドセットもしくはARグラスなどの拡張現実デバイスであり、直接提供されるということは、コーデック1A11から提供され、コーデック1A11によってそれぞれのデータベース1A07または1G07に最初に収められた後にプレノプティックシーンデータベース1A07または他のシーンデータデータベース1G07のいずれかから同等のシーンデータを取り出すプロセスから提供されないことを意味する。さらに、センサ出力1E11に提供されるこの非プレノプティックデータまたは他のシーンデータのうちのいずれかが、データとして記憶されていないか、またはクライアントのプレノプティックシーンデータベース1A07または他のデータベース1G17のいずれかにデータとして記憶されている可能性があり、ストレージオペレーションは、提供に先立つか、または実質的に提供と同時であるか、または提供後のいずれかであり、センサ出力1E11への提供は、代替的に、データベース1A07または1G07内の収められているデータのうちのいずれかをさらに処理することによって、達成されるものとしてよく、それにより、センサ出力1E11への提供のためにシーンデータパケット1A15で受信されたシーンデータと同等であるシーンデータを取り出すことができる。
【0070】
次に図2Aを参照すると、「Joint ad hoc group for digital representations of light/sound fields for immersive media applications」によって提供されるような「Technical report of the joint ad hoc group for digital representations of light/sound fields for immersive media applications」という表題の刊行物の13ページに提示されているようなブロック図が示されており、その内容全体が参照により組み込まれている。この刊行物は、「概念的なライト/サウンドフィールド」の処理を対象としており、図は処理フローにおける7つのステップを示している。7つのステップは、1)センサ、2)感知データ変換、3)エンコーダ、4)デコーダ、5)レンダラー、6)プレゼンテーション、および7)インタラクションコマンドを含む。処理フローは、現実世界またはコンピュータで合成されたシーンをユーザに提供することを意図されている。
【0071】
図2Bには、2π～4πフリービューディスプレイ2B19などのセンサ出力デバイスを通じて現実世界のシーン2B01に関する少なくとも視覚情報をユーザ2B17に提供するためのいくつかの例示的な実施形態の例示的なユースケースを表す組合せブロックおよび絵図が示されている。本明細書の図において、現実世界のシーン2B01は、実カメラ2B05-1および2B05-2などの1つまたは複数のセンサを用いて感知され、実カメラ2B05-1および2B05-2は、たとえば、球状の4πステラジアン全体(したがって、360×180度)を含む何らかの視野にわたって実シーン2B01を撮像することができる。2B05-1および2B05-2などの実カメラ、さらには他の現実世界のシーン2B01のセンサは、キャプチャされたシーンデータ2B07を、たとえばネットワーク1E01のサーバサイド1E05上に常駐するシステム1A01に提供する。本明細書の図において、シーンデータ2B07は性質上視覚的であるが、図1Eに関して前に説明されているように、システム1A01のセンサ1E09は、限定はしないが、2B05-1および2B05-2などの実カメラを含み、さらに、2B05-1および2B05-2などの実カメラは、4Pステラジアンカメラ(360度カメラと称されることも多い)に限定されないが、たとえば単一センサ狭視野カメラであってもよい。また、前に説明されているように、2B05-1および2B05-2などのカメラは、たとえば、紫外線、可視光線、および赤外線を含む広い範囲の周波数にわたって感知することができる。しかしながら、エンドユーザ2B17が視覚情報を見るためにこの図に示されているユースケースでは、好ましいセンサは、実カメラであるか、または複数のシーンポイントにわたって実シーンの奥行きおよび色を感知することができ、このことはすべて撮像システムを熟知している者にはよく理解されるであろう。
【0072】
なおも図2Bを参照すると、本明細書の例示的なカメラ画像を含むセンサデータ2B07は、サーバサイドシステム1A01に提供される。図1Aに関連して前に述べたように、さらに以下で次に示す図4Cに関してさらに説明されているように、実カメラ2B05-1および2B05-2などのセンサに関して追加の外部情報および固有情報もサーバサイドシステム1A01に提供されてよく、そのような情報は、たとえば、センサの配置および配向、場合によってはセンサ分解能、光学的および電子的フィルタ、キャプチャ周波数なども含む。提供された情報さらには2B07を含む画像などのキャプチャされた情報のうちのいずれかを使用して、サーバサイドシステム1A01は、好ましくは、シーンソルバー1A05およびSPU1A09と組み合わせてアプリケーションソフトウェア1A03の指示の下でプレノプティックシーンデータベース1A07においてプレノプティックシーンモデルを形成する現実世界のシーン2B01を再構築する。次に示す図4Aおよび図4Bは、2B01などの例示的な現実世界のシーン(図4A)および現実世界のシーンの抽象モデルビュー(またはプレノプティックシーンモデル)(図4B)の両方に関するさらなる情報を提供する。いくつかの実施形態により、プレノプティックシーンモデルは、1)空間的広がり、2)空間的ディテール、3)ライトフィールドのダイナミックレンジ、および4)マターフィールドのダイナミックレンジを含む様々な次元にわたって対応する現実世界のシーンのマターフィールド2B09およびライトフィールド2B11の両方を少なくともある程度の所定の分解能で記述する。
【0073】
なおも図2Bを参照すると、クライアントサイドシステム1A01とインタラクティブにやり取りするユーザ2B17は、サーバサイドシステム1A01上に収められているか、またはサーバサイドシステム1A01がアクセス可能であるプレノプティックシーンデータベース1A07内で表される現実世界のシーン2B01の少なくとも一部を見ることを要求する。好ましい実施形態において、クライアントサイドシステム1A01上で実行されるアプリケーションソフトウェア1A03は、少なくともユーザ要求を決定するためにユーザインターフェースを提示し、制御する。次に示す図5、図6、および図7は、ユーザ要求のタイプの例を取りあげている。例示的な一実施形態において、クライアントサイドシステム1A01上のアプリケーションソフトウェア1A03は、ネットワーク1E01(図1Eに示されている)上で制御パケット1A17内のユーザ要求を、たとえばサーバサイドシステム1A01上で実行されているエンコーダを有する1A11bなどのシーンコーデックに通信するためにデコーダを備える1B11bなどのシーンコーデックとインターフェースする。サーバサイドシステム1A01のアプリケーションソフトウェア1A03は、好ましくは、サーバサイドのエンコーダ1B11aと通信しており、少なくとも、プレノプティックシーンモデル内の所与のエントリーポイント(現実世界のシーン2B01内の空間的エントリーポイントと同位置にある)から空間的に開始するシーン情報を受信することに対するユーザ要求などの明示的なユーザ要求を受信する。
【0074】
要求を処理するとき、サーバサイドシステム1A01は、好ましくは、要求されたシーンエントリーポイントによって示されるように関連するサブシーンを決定し、プレノプティックシーンデータベース1A07から抽出する。抽出されたサブシーンは、好ましくは、サブシーン空間バッファをさらに備える。したがって、本例では、サブシーンは、最低限、エントリーポイントに配置される2π～4πステラジアンの視点を表す画像データを含むが、次いで、最大限、エントリーポイントおよび所与の最小時間の両方に関してユーザによるシーンの任意の予想される経路横断に対応するのに十分なデータベース1A07の追加部分を含む。たとえば、現実世界のシーンがプラハであり、エントリーポイントが聖クレメント大聖堂のナルテックスである場合、最小抽出シーンは、ユーザが大聖堂のナルテックスのところに配置される4π/2ステラジアン(半ドーム)の視点を知覚することを実質的に可能にする。しかしながら、ユーザ要求、または所与のエントリーポイントに基づくユーザの典型的な歩行速度および方向などのサーバサイドシステム1A01内でまたはサーバサイドシステム1A01に利用可能な補助情報に基づき、サーバサイドシステム1A01上で実行されているアプリケーションソフトウェア1A03は、任意の利用可能な方向のナルテックスからの30秒間の歩行をサポートするのに十分な追加のシーン分解能を提供するのに十分なサブシーンバッファを決定し得る。
【0075】
なおも図2Bを参照すると、決定され抽出されたサブシーンは、シーンストリーム2B13内の1つまたは複数のシーンデータパケット1A15(図1A参照)の通信で提供される。好ましくは、最小個数のシーンパケット1A15が、ユーザ2B17が許容可能なアプリケーション応答性を知覚するように通信され、一般に、特にシーン寸法のいずれかが増加するにつれて、特にプラハなどの少なくとも大きな国際都市シーンであれば当然であるように、プレノプティックシーンデータベース1A07全体を転送することは(たとえば、帯域幅および/または時間制限により)法外に大きいことが理解されている。プレノプティックシーンデータベースを組織化すること、および組織化されたデータベースを処理することの両方のために例示的な実施形態において使用される技術は、他の知られている技術に勝る実質的な技術的改善をもたらし、そのため、ユーザはリアルタイムまたはリアルタイムに近いシーンエントリーを体験する。
【0076】
しかしながら、ユーザが、最初にシーンを入力したときに入力されたシーンの連続的な体験を知覚することに有利な形でユーザがある程度の遅延を体験することは可能であり、また手頃であり、連続的な体験は、エントリーサブシーンバッファのサイズ、およびシーン横断の明示的にまたは暗黙のうちに表現された方向に沿った補足的なシーンインクリメントの提供の両方に直接関係する。本発明のいくつかの例示的な実施形態は、初期のエントリーポイント分解能とサブシーンバッファさらにはサブシーンインクリメントおよび分解能の周期的または非周期的なイベントベースのレートのバランスをとるための手段を提供する。このようにバランスをとることで、最小量のシーン情報でエンコードされた最大連続ユーザ体験を提供し、したがって、所定のサービス品質(QoS)レベルを満たすことができる新規性のあるシーン圧縮をもたらす。例示的なサーバサイドシステム1A01によって決定され、提供される非同期シーンストリーム2B13内で、シーンデータパケット1A15の任意の所与の伝送は、プレノプティックシーンデータベース1A07の情報の任意の形態およびタイプの任意の組合せを含むものとしてよく、たとえば、2B13-aまたは2B13-dなどの1つのシーンデータパケットは、マターフィールド2B09およびライトフィールド2B11の情報の少なくとも組合せを含むが(たとえば、2B13-aおよび2B13-dにおいてそれぞれ「M」および「L」の両方を有するものとして示されている)、その一方で、2B13-bなどの別のシーンデータパケットは、少なくともマターフィールド2B09を含まないが、一部のライトフィールド2B11を含み(たとえば、2B13-bにおいて「L」のみを有するものとして示されている)、一方、2B13-cなどの別のシーンデータパケットは、少なくとも一部のマターフィールド2B09を含むが、ライトフィールド2B11を含まない(たとえば、2B13-cにおいて「M」のみを有するものとして示されている)。
【0077】
なおも図2Bを参照すると、シーンストリーム2B13は、ネットワーク1E01のトランスポート層を介してサーバサイドシステム1A01から伝送され、クライアントサイドシステム1A01によって受信され処理される。好ましくは、シーンデータパケット1A15は、最初に、デコーダを備えるシーンコーデック1B11bによってクライアントサイドシステム1A01上で受信され、次いで、デコードされたシーンデータは、SPU1A09の機能にアクセスするアプリケーションソフトウェア1A03の指示の下で処理される。デコードされ、処理されたシーンデータは、好ましくは、クライアントサイドシステム1A01上で、ローカルプレノプティックシーンデータベース2B15を再構築し、さらには2π～4πフリービューにおけるシーンエントリーポイントなどのシーン情報を提供するために使用される。提供されるエントリーポイントフリービューは、ユーザ2B17が、少なくとも視点の配向の角度(θ,φ)さらにはシーン内のユーザの現在位置を表す空間視点配置(x,y,z)に関して視点の表示を明示的にまたは暗黙のうちに変更することを可能にする。ユーザ2B17がシーン内をさらに探索し、したがってシーン内を動き回る明示的なまたは暗黙のうちの要求を提示すると、クライアントサイドシステム1A01は、最初に、ローカルシーンデータベース2B15がサブシーンインクリメントを提供するのに十分な情報を含むかどうか、またはサーバサイドシステム1A01に対して追加のインクリメントがサーバサイドシーンデータベース1A07から抽出されることを要求すべきであるかどうかを決定する。本明細書において説明されているような適切に機能するシーン再構築、配信、および処理のシステムは、複数の考慮事項のバランスをとり、プレノプティックシーンモデル情報をプレノプティックシーンデータベース1A07に収め、プレノプティックシーンデータベース1A07から取り出すための効率的な手段を提供するユーザ2B17に対する最適なQoSをインテリジェントに決定する。
【0078】
次に図3を参照すると、様々な可能な形態を表す様々な形態のシーンコーデック1A01を使用する多数のシステムを接続するネットワーク1E01の組合せブロックおよび絵図が示されており、これらの形態は、限定はしないが、携帯電話などのパーソナルモバイルデバイス、ホログラフィックテレビなどのディスプレイデバイス、サーバなどのクラウドコンピューティングデバイス、コンピュータなどのローカルコンピューティングデバイス、陸上ロボット、ドローンなどの無人自律移動体(UAV)、およびARグラスなどの拡張現実デバイスを含む。前に説明されているように、システム1A01はすべて、シーンコーデック1A11を含み、システム1A01のうちのいずれかに含まれるコーデック1A11は、エンコーダ1B11aおよびデコーダ1B11bの両方を備えるか、エンコーダ1B11aを備えデコーダ1B11bを備えないか、またはデコーダ1B11bを備え、エンコーダ1B11aを備えないこともさらにあり得る。したがって、本明細書の図に表されているようなシステム1A01はいずれも、プレノプティックシーンデータ提供者およびプレノプティックシーンデータ消費者の両方、提供者のみ、または消費者のみであってもよい。単一のシステム1A01、たとえば、ネットワーク1E01に接続されていないコンピュータは、シーンコーデック1A01を使用するシステムを定義するものとして本明細書において説明されている機能のうちのいずれかを実行することが可能であるが、いくつかの実施形態は、2つ以上のシステム1A01がネットワーク1E01上でインタラクティブに動作することを含むものとしてよく、それにより、これらのシステムはプレノプティックシーンデータベース1A07内に再構築されるようにキャプチャされた実シーンデータ2B07のうちのいずれかを交換するか、またはプレノプティックシーンデータベース1A07シーンデータのうちのいずれかを交換している(特に、次に示すユースケースの図5、図6、図7を参照のこと)。
【0079】
次に図4Aを参照すると、屋外のシーンを見る窓がある内部の家のシーンなどの非常に高いレベルのディテール(たとえば、いくつかの場合に、無制限またはほとんど無制限のディテールと称される)の例示的な現実世界のシーン4A01の絵図が示されている。たとえば、シーン4A01は、限定はしないが、不透明オブジェクト4A03、微細構造化オブジェクト4A05、遠方オブジェクト4A07、放射オブジェクト4A09、高反射オブジェクト4A11、無特徴オブジェクト4A13、または部分的透過オブジェクト4A15のうちの任意の1つまたは任意の組合せを含む。また、表されているのは、個別に、または他の(図示されていない)システム1A01と組み合わせて、のいずれかで動作している携帯電話などのシーンコーデックを使用するシステム1A01を操作しているユーザであり、これはユーザに、たとえば、任意の数の付随する現実世界のシーン4A01の翻訳、たとえば、オブジェクト測定、ライトフィールド測定、または窓境界対不透明境界を含むシーンの一部分などのシーン境界測定とともにサブシーン画像4A17を提供する(特に次に示す図、たとえば、図4Bを参照のこと)。
【0080】
なお図4Aを参照すると、一般に、4A01などの任意の現実世界のシーンは、「シーン再構築」と称されるプロセスを介してプレノプティックシーンモデル1A07に翻訳される。前に説明されているように、また本開示の後の方でより詳細に説明されるように、SPU1A09は、シーン再構築さらには限定はしないがシーン拡張およびシーン抽出などの他のデータベース1A07の機能の両方を最も効率的に実行するための複数のオペレーションを実装し、シーン拡張は、そうでなければ対応する現実世界のシーン4A01内に必ず存在するまたは実質的に存在するということのないシーンモデルに新しいもしくは合成シーン情報を導入し、シーン抽出は、サブシーンを表すシーンモデルのいくつかの部分の決定および処理を行う。合成シーン拡張は、たとえば、木または大理石の床などの再構築された現実世界のオブジェクトのより高い分解能を提供することを含み、それにより、ビューアが所与のQoS閾値を超えるところから現実世界のオブジェクトを見るときに、ビューアは、キャプチャされた現実世界のシーンに対応する元のプレノプティックシーンモデルで表されるような現実世界再構築情報を提供される。しかしながら、ビューアが提供されたサブシーン内のオブジェクトに空間的に接近し、最終的にQoS閾値を越えると、いくつかの例示的な実施形態によるシステムは、現実世界のシーン内に元々キャプチャされることが(または存在することすら)なかった樹皮もしくは大理石の床のディテールなどの合成情報を、提示中にインテリジェントに拡張するか、または提供されたサブシーン内の拡張としてインテリジェントに含んでいる。また、前に説明されているように、シーンソルバー1A05は、一般に、シーンの再構築、拡張(QoS駆動合成など)、抽出、または他の形態のシーン処理の態様のうちのいずれかの正確さおよび精度を増大するための機械学習技術をさらに適用する任意選択の処理要素である。
【0081】
コンピュータシステムを熟知している者であれば理解するように、アプリケーションソフトウェア1A03、シーンソルバー1A05、SPU1A09、シーンコーデック1A11、および要求コントローラ1A13を含むシステムコンポーネントのうちのいずれかの組合せは、例示的な実施形態の範囲および精神から逸脱することなくコンポーネントの様々な配置構成として実装され得る機能および技術的改善を提供する。たとえば、シーンソルバー1A05の様々な新規性のある機能のうちの1つまたは複数は、アプリケーションソフトウェア1A03またはSPU1A09のいずれかに代替的に備えられる可能性があり、それにより、様々なシステムコンポーネントを記述する機能の現在説明されている概要は、例示的な実施形態の制限としてではなく、むしろ、例示的なものとして考慮されるべきであり、ソフトウェアおよびコンピュータシステムの当業者であれば、例示的な実施形態の範囲から逸脱することなくシステムコンポーネントおよびコンポーネント機能の可能な多くの変更形態を認識するであろう。
【0082】
なおも図4Aを参照すると、システム1A01による4A01などの現実世界のシーンの再構築は、現実世界のシーンのマターフィールド2B09およびライトフィールド2B11の両方に対するデータ表現の決定を含み、これらの表現、およびこれらの表現の組織化は、シーン再構築に著しい影響を及ぼすが、それ以上に重要なこととして、サブシーン抽出の処理速度を含む効率に影響を及ぼす。例示的な実施形態は、たとえば、大規模なグローバルシーンモデルをリアルタイムまたはほぼリアルタイムで体験するユーザから利用可能にすることを本質的に可能にするシーン表現およびシーン表現の組織化を提供する。図4A、図4B、および図4Cはまとめて、これらのシーン表現およびシーン表現の組織化をある程度のレベルのディテールで記述する方向に向けられており、これらはすべて、次いで、本開示の一部においてさらに詳細に説明される。
【0083】
本明細書において説明されている例示的な実施形態による技術は、マターフィールド2B09およびライトフィールド2B11の両方を記述するために階層、多重分解能、および空間的にソートされた体積データ構造を使用してもよい。これは、各ユーザの配置および視方向によって決定されるか、またはユーザのグループについて統計的に推定されるような配置、分解能、および視認性に基づき遠隔透視に必要なシーンの部分を識別することを可能にする。必要な部分だけを通信することによって、チャネル帯域幅の要件が最小にされる。体積モデルの使用も、衝突検出および物理学ベースのシミュレーション(質量プロパティが容易に計算される)などの仮想世界での高度な機能性を円滑にする。したがって、新規性のあるプレノプティックシーンモデル表現および表現の組織化への4A01などの現実世界のシーンの新規性のあるシーン再構築処理、さらにはサブシーン抽出ならびにユーザシーン相互作用監視および追跡の新規性のある処理に基づき、例示的な実施形態は、多くのユースケースの利点をもたらし、そのうちのいくつかは、次に示す図5、図6、および図7で説明され、それらの利点の1つは、自由視点ビューア体験を提供することを含む。自由視点ビューア体験では、1つまたは複数のリモートビューアは、伝送されるサブシーンに対するそれらの視点を独立して変更することができる。最大の自由視点体験、特により大規模なグローバルシーンモデルに必要とされるのは、自由視点ビューアへのシステム1A01によるジャストインタイムおよび必要な場合のみの両方の、またはとジャストインタイムおよび予想される場合のみの、サブシーン提供である。
【0084】
なおも図4Aを参照すると、4A01などの現実世界のシーンを表す画像および他の何らかの形でキャプチャされたセンサデータは、色、強度、および偏光などの光の1つまたは複数の特性を含む。このおよび他の実シーン情報を処理することによって、システム1A01は、プレノプティックシーンデータベース1A07における表現に対するマターフィールド2B09に関する形状、表面特性、材料プロパティ、および光相互作用情報を決定する。実シーンのライトフィールド2B11の分離決定および特性化は、他にもあるがとりわけシーン照明(たとえば、正反射、影)によって引き起こされる表面特性および材料プロパティの曖昧さを除去するために、マターフィールド2B09と組み合わせて使用される。シーンモデルへの現実世界のシーンの現在説明されている新規性のある処理は、透明材料、高反射表面、および日常のシーンにおける他の困難な状況を効果的にモデル化することを可能にする。たとえば、これは、シーン内の実際の照明とは独立して、物質および表面の特性の「発見」を含み、この発見ならびに付随する表現および表現の組織化は、次いで、ライトフィールド2B11とは異なるマターフィールド2B09の正確な分離および自由視点ビューアへの提供を含む新規性のあるサブシーン抽出を可能にする。
【0085】
このように、自由視点ビューイング体験では自由照明の別の重要目標を達成し、たとえば、4A01などの実シーンに対応するシーンモデルにアクセスするときに、ビューアは、おそらく「朝の日光」対「夕方の日光」で、または「利用可能なルームライトによる半月照明」ですら、シーンの自由視点ビューイングを要求することができ、好ましくはアプリケーションソフトウェア1A03によって提供されるユーザインターフェースは、テンプレート照明源のグループから新しい照明源を挿入することを可能にし、新たに指定された、または利用可能な照明源の両方は、次いで、たとえば、発光、反射、または透過の特性を変更するように修正され得る。同様に、マターフィールド2B09のプロパティおよび特性も、ビューアによって動的に変更されてよく、したがって、自由照明および自由視点とともにフリーマター(free-matter)を提供し、例示的な実施形態が実シーンのライトフィールド2B11からマターフィールド2B09のより正確な分離を可能にすることを見ることは特に重要であり、分離の精度不足は、マターフィールド2B09および/またはライトフィールド2B11のプロパティおよび特性を正確に変えることに対する最終使用体験を逆に制限することになる。本明細書において説明されているような正確なマターフィールド2B09の別の利点は、マターフィールドのオブジェクト内での干渉および衝突検出を含み、これらおよび他のライフシミュレーション機能は、質量、重量、および重心などの物質プロパティを必要とする(たとえば、物理学ベースのシミュレーションの場合)。これもまた現実世界のシーン内での物体認識を熟知している者であればよく理解するように、非常に正確なマターフィールドおよびライトフィールドは、著しい利点をもたらす。
【0086】
なおも図4Aを参照すると、実シーン4A01のマターフィールド2B09は、光が流れるか、または遮断される物質の有限体積表現であるメディエルを含み、したがって、吸収、反射、透過、および散乱の程度として特徴付け可能な様々な程度の光透過率を有する。メディエルは、シーン空間内に配置され、配向され、材料のタイプ、温度、および光とメディエルとの相互作用によって引き起こされる出射ライトフィールドに入射ライトフィールドを関係付ける双方向光相互作用機能(BLIF)などの関連プロパティを有する。光学的に、空間的に、および時間的に均質な同一配置メディエルは、触知可能な境界を有する表面を含むオブジェクトのセグメントを形成し、触知可能な境界は、一般的に、人間が触れることによって感知することができる境界であると理解されている。これらおよび他のマターフィールド2B09の特性を使用することで、図4Aに示されている様々なオブジェクトは、空間的にだけでなく、重要なのはライトフィールド(2B11)との相互作用に関しても区別され、様々な物体は、ここでもまた、不透明オブジェクト4A03、微細構造オブジェクト4A05、遠方オブジェクト4A07、放射オブジェクト4A09、高反射オブジェクト4A11、無特徴オブジェクト4A13、または部分的透過オブジェクト4A15を含む。
【0087】
次に図4Bを参照すると、図4Aに示されているような現実世界のシーン4A01を表す絵図が示されており、表現は、プレノプティックシーンデータベース1A07内に含まれるデータの抽象的なシーンモデル4B01のビューとみなすことができる。現実世界のシーン4A01のシーンモデル4B01の抽象的表現は、シーンのマターフィールド2B09およびライトフィールド2B11を備えるプレノプティックフィールド4B07を含む外側シーン境界4B03を含む。ライトフィールド2B11は、図4Aに関して説明されているように、マターフィールド2B11内の任意の数のオブジェクト、さらには、たとえば、説明されているオブジェクト4B09、説明されていない領域4B11などの他のオブジェクトと相互作用する。現実世界のシーン4A01は、たとえば、実画像4B13をキャプチャする実カメラ2B05-1などの実センサの任意の1つまたは複数によってキャプチャされるが、シーンモデル4B01は、たとえば現実世界の表現画像4A17を提供する仮想カメラ2B03を使用して画像などの現実世界のデータ表現に翻訳される。
【0088】
図4Aに示されているような不透明オブジェクト4A03、微細構造オブジェクト4A05、遠方オブジェクト4A07、放射オブジェクト4A09、高反射オブジェクト4A11、無特徴オブジェクト4A13、または部分的透過オブジェクト4A15を含むオブジェクトに加えて、いくつかの実施形態によるシステムは、説明されているオブジェクト4B09および説明されていない領域4B11の両方をさらに許容するものとしてよく、これらの一般オブジェクトおよび領域は、図4Aで説明されているようにマターフィールド2B09の特徴およびプロパティの変更形態を含んでいる。態様に重要なのは、マターフィールド2B09が、複数のタイプのオブジェクトの間の区別に十分なシーン再構築によって識別され、モデルシーン内に一意的に配置されているオブジェクトの任意の個別のタイプは、たとえば、機械学習を使用してオブジェクト認識および分類を実行し、様々な特性およびプロパティを変更して、可視化の変更(一般的には翻訳)、オブジェクトの拡張およびタグ付け(特に、図4Cに関するモデル拡張4C23およびモデルインデックス4C27を参照)、およびオブジェクト除去などのモデル提示効果を引き起こすことによってさらに処理される。オブジェクト除去とともに、オブジェクト翻訳(次に示す図4Cにおけるモデル翻訳4C25を参照)は、任意の数の幾何学的翻訳(サイズ変更および回転など)、または、たとえばオブジェクトの衝突もしくは割り当てられたオブジェクト経路、たとえば、その後床(不透明な外側シーン境界4B03)に沿って転がり壁(不透明な外側シーン境界4B03)に当たって跳ね返る機械学習を通じて分類される不透明オブジェクト4A03に基づくオブジェクトの移動すら実行するように指定され得る。
【0089】
なおも図4Bを参照すると、任意のオブジェクトの特性およびプロパティは、そうして少なくとも新しいBLIF(双方向ライトフィールド情報)を提供する、たぶん赤外線などの非可視光線周波数で撮られる、限定はしないが新しいカメラ画像などの新しい実シーンセンサデータの追加処理を通じて変更され得る。図4Aおよび図4Bに示されているようなオブジェクトタイプは、実施形態の制限ではなくむしろ例として考えられるべきであり、ソフトウェアおよびデータベースを熟知している者にとっては、データが更新され得ること、およびマターフィールドオブジェクトを形成する関連データのタグ付けが調整され得ることは明らかであり、これは、少なくとも「無特徴」対「微細構造」などのオブジェクトの命名を含むか、またはたとえば「部分的透過」対「不透明」としてオブジェクトを分類するために使用されることもあり得るオブジェクト分類閾値の変更を含む。オブジェクトタイプの他の有用な変更形態は、マターフィールド2B09およびライトフィールド2B11の一般的な他の変更形態と同様に、本開示に基づくシーン処理の技術の当業者には明らかであり、最も重要なことは、本明細書において説明されているような4A01などの現実世界のシーンの表現および表現の組織化、さらにはこれらの組合せが本明細書において説明されているような固有の機能を提供する上で有用である効率的処理であり、ここでもまた、これらの固有の機能は、少なくとも可視化のためにビューアがシーンモデルを使用する自由視点、フリーマター、およびフリーライトの体験を提供する。
【0090】
シーンモデルは、表現されたプレノプティックフィールド4B07の最も外側の広がりの境界を画定する外側シーン境界4B03も含む。図4Aに示されているキッチンまたは屋外シーン(示されていない)などの現実世界のシーンを慎重に考察すると明らかになるように、外部シーン境界4B03の近くのプレノプティックフィールドのいくつかの領域は、実質的に不透明に作用するが(キッチンの壁もしくはカウンター、または屋外シーンの濃い霧など)、(想像上の)外部シーン境界の近くの他の領域は、実質的に窓として作用し、任意のライトフィールド境界(屋外シーン内の空など)を表し得る。実シーンでは、光は、シーンモデルの外側境界に関連付けられている空間を前後に横切り得る。しかし、シーンモデルはそのような透過を許さない。むしろ、窓ライトフィールドは、実シーンにおけるライトフィールドを表すことができる(テレビが夜の月の画像を表示できるように)。シーンモデルでは、外側シーン境界4B03の近くの不透明領域は、プレノプティックフィールドの外側にある光の(実シーン内の)シーンへの実質的な透過を表しておらず、一方、外側シーン境界4B03の近くの窓領域は、プレノプティックフィールドの外側にある光の(実シーン内の)シーンへの実質的な透過を表している。いくつかの実施形態において、樹木および他の屋外の物質をプレノプティックフィールド4B07に含まれるものとして表すことが可能であり、外側シーン境界4B03は、少なくともこの物質を含むように空間的に拡大される。しかしながら、マターフィールド内のオブジェクトがなおいっそう遠くなるにつれて、オブジェクト上の特徴が視点の変更によって実質的に変化しない無視差限界と称される距離に到達するとしても、プレノプティックフィールド4B07を外側シーン境界4B03で終了させることは有益である。1つまたは複数の窓光要素4B05を使用することで、実シーンに入射するライトフィールドを、外側シーン境界4B03の部分に沿って、外側シーン境界4B03のそれらの部分におけるプレノプティックフィールド4B07が無限に延在しているかのように表現することが可能である。
【0091】
たとえば、図4Aを参照すると、シーン境界4B03、およびしたがってプレノプティックフィールド4B07も窓を越えて屋外領域にまで延長し、それによってシーンのマターフィールド内に樹木を含めるのではなく、シーン境界4B03をカウンタートップ、壁、および窓を含む媒体および物質の表現で実質的に終了させることが可能であり、次いで、窓表面を空間的に表現する外側シーン境界4B03の部分に沿って含まれる複数の窓光要素4B05が、窓ライトフィールドをプレノプティックフィールド4B07内に効果的に入射させるように追加され得る。2D、3D、および4Dライトフィールドを含む窓光要素4B05を使用することで、様々なライトフィールドの複雑化が可能である。本明細書で使用されるように、「媒体」は、いくつかの物質を含むか、または物質を全く含まない体積領域の内容を指すことに留意されたい。媒体は、同質であるか、または異質であり得る。同質媒体の例は、空っぽの空間、空気、および水を含む。異質媒体の例は、鏡の表面(一部空気および一部銀メッキされたガラス)、1枚のガラスの表面(一部空気および一部透過性ガラス)、およびパインツリーの枝(一部空気および一部有機材料)を含む体積領域の内容を含む。光は、吸収、反射、透過、および散乱を含む現象により媒体中を流れる。部分的透過性を有する媒体の例は、パインツリーの枝および1枚のガラスを含む。
【0092】
本発明のシステムの1つの例示的な使用および利点において、図4Bで説明されているような、図4Aに示されているような実シーンに対応する方式で、シーンモデル1A07は、シーン(たとえばキッチン)内に透過する時刻に基づく日光の量を推定するために使用することができ、様々なタイプの窓カバーに基づく推定された時刻の室温または季節のエネルギー節約の機会は、透過した日光の推定量に少なくとも一部は基づき計算され得る。このような計算例は、プレノプティックフィールド4B07を含むライトフィールド2B11を表すデータに少なくとも一部は基づき、そのライトフィールド表現および他のより基本的な計算法は本明細書においてより詳細に取り扱われる。ライトフィールド4B07は、すべての光の伝播がシーンに関して瞬間的なものとしてモデル化されるような準定常状態のライトフィールドとして扱われるが、本明細書において説明されているフリーライトの原理を使用して、好ましくはアプリケーションソフトウェア1A03を使用することで視覚的シーン表現の提示を通じてビューアは動的な状態のライトフィールドを体験し得るというだけで十分である。
【0093】
さらに図4Bを参照すると、たとえば、4πステラジアンまでの全体にわたるビューの画像をキャプチャすることができる、実カメラ2B05-1、さらには4πステラジアン未満の例示的な限定された視点4A17を有する仮想カメラ2B03の両方が示されている。プレノプティックシーンデータベース1A07内に記述されている対応するシーンモデル4B01を有する実シーン4A01などの任意のシーンは、それぞれ、2B05-1および2B03などの任意の数の実カメラまたは仮想カメラを備え得る。2B05-1および2B03などのカメラはいずれも、シーンモデルに関して固定されているか、またはシーンモデルに関して移動可能であると指定されてよく、移動可能なカメラは、たとえば、横断経路と関連付けられる。見ておくのが重要なのは、可動であるか固定であるかにかかわらず、視野対固定視野内で調整可能かどうかにかかわらず、任意の実カメラまたは仮想カメラの多くの可能な視点、したがって結果として得られる画像が、図4Bに関して説明されているように、シーンモデル4B01の処理によって推定され得ることである。
【0094】
次に図4Cを参照すると、プレノプティックシーンデータベース1A07の一実施形態内の主要なデータセットのブロック図が示されており、データベース1A07は、たとえば、図4Aに示されているような現実世界のシーン4A01を表すデータを収める。現実世界のシーン4A01のプレノプティックシーンデータベース1A07のデータモデルビューは、典型的には、たとえば、実カメラ2B05-1または2B05-2、または仮想カメラ2B03などのセンサ1E07を記述する内部データまたは外部データ4C07のうちのいずれかを含み、内部データおよび外部データは、センサのタイプに基づき当技術分野でよく知られており、そして、一般的に、内部プロパティは、センサのデータキャプチャおよび処理機能に関係し、外部プロパティは、典型的にはシーン局所座標系に関して、またはマターフィールド2B09およびライトフィールド2B11を含むシーンに関するセンサの空間的配置を理解することを可能にする少なくともいずれかの座標系に関してセンサの物理的な配置および配向に関係している。
【0095】
データモデルビューは、シーンモデル4C09をさらに備え、典型的にはプレノプティックフィールド4C11、オブジェクト4C13、セグメント4C15、BLIF 4C17、および特徴4C19を含む。「プレノプティックフィールド」という用語は、現在の技術の範囲内である範囲の意味を有し、さらに本開示は、プレノプティックフィールド4C11の新規性のある表現を提供し、この新規性のある表現および表現の組織化は、少なくとも一部は本明細書において説明されている技術的改善の多くの基礎となり、たとえば、最小のデータセット(サブシーン)によって使用可能になる十分なシーン分解能(したがって、QoS閾値を満たす)を有する実質的に連続する視覚的フリービュー体験を提供するジャストインタイムのサブシーン抽出を含む。したがって、本明細書において説明されている他の具体的に説明されている用語およびデータセットと同様に、この用語およびデータセットのプレノプティックフィールド4C11は、本明細書に照らして理解されるべきであり、単に現在の最先端技術を参照して理解されるべきではない。
【0096】
なおも図4Cを参照すると、プレノプティックフィールド4C11は、本明細書ではプレノプティック八分木と称される表現の組織化を含み、プレノプティック八分木は、マターフィールド2B09およびライトフィールド2B11の両方の表現を保持する。一般にシーンモデル4C09に関する表現および表現の組織化のより詳細な説明、ならびにプレノプティックフィールド4C11、オブジェクト4C13、セグメント4C15、BLIF 4C17、および特徴4C19などのシーンモデルの主要なデータセットについては、特に、本明細書の残りの部分で述べるが、一般に、本明細書において説明されているようなプレノプティック八分木表現は、マターフィールド2B09に対する2つのタイプの表現と、ライトフィールド2B11に対する1つのタイプの表現とを含む。マターフィールド2B09は、(体積的に)「媒体」タイプのマター表現と「表面」タイプのマター表現の両方を含むことが示されている。媒体タイプの表現は、光が実質的に流れる(または光が実質的に遮断される)均質または不均質な物質を記述する。これは、何もない空間を含む。光は、吸収、反射、透過、および散乱を含む現象により媒体タイプを含む媒体中を流れる。光の変化のタイプおよび程度は、プレノプティック八分木のボクセルに含まれるか、またはそれによって参照されるプロパティ値に収容される。表面タイプの表現は、物質と何もない空間(または別の媒体)との間の触知可能な(触れることができる)、(おおよそ)平面状の境界を記述し、平面状境界は、両側に媒体を含み、両側の媒体は、同じ媒体または異なる媒体であってよい(ここで、異なる媒体の表面は、「分割表面」または「分割サーフェル」と称される)。
【0097】
空間的にも時間的にも均質である同一の位置に配置されている媒体を含む表面タイプの物質は、セグメント表現4C15を形成し、次いで、同一の位置に配置されたセグメントは、オブジェクト4C13の表現を形成する。ライトフィールド2B11に対する表面タイプの物質の効果(反射、屈折など)は、表面タイプの物質に関連付けられている双方向光相互作用機能(BLIF)表現4C17によってモデル化され、BLIF表現4C17の粒度は、少なくともオブジェクト4C13を含むセグメント4C15との関連付けにまで及ぶが、特徴表現4C19との関連付けにも及び、特徴は、シーンモデル4C09によって記述された空間内に配置されているオブジェクト4C13などのエンティティにおける姿勢として参照される。シーンまたは画像中の特徴の例は、ミクロの観点からのスポットおよび輝き、またはマクロの観点からの建物をも含む。BLIF表現4C17は、ライトフィールドと材料との相互作用に基づき、材料(物質)に入射するライトフィールド2B11の変換と、材料から出射するライトフィールド2B11とを関係付ける。
【0098】
なおも図4Cを参照すると、いくつかの例示的な実施形態のうちの少なくとも1つの実施形態の主要なデータセットは、モデル拡張4C23、モデル翻訳4C25、モデルインデックス4C27、およびモデル使用履歴4C29のうちのいずれか、またはそれらの任意の組合せなどの補助情報4C21を含む。モデル拡張4C23は、そうでなければシーンモデル4C09内に含まれず、そうでなければシーンモデル4C09への変更を指定しないシーンモデル4C09のある部分に関連付けられるべき任意の追加のメタデータを含む(たとえば、モデル翻訳4C25は、シーンモデルへの帰属について何らかの数学的関数または類似のものを記述し、その帰属は、抽出されたサブシーンまたは計量などのシーンモデル解釈を変える(変更する))。
【0099】
モデル拡張表現4C09は、限定はしないが、1)たとえば、部屋の特徴、オブジェクト価格設定、または図4Aに示されている実シーンに関するオブジェクトを購入するための最寄りの店舗へのリンクを含む、テキスト、グラフィックス、URL、またはたとえば閲覧されたサブシーンへの拡張として表示される可能性のある他のデジタル情報(概念上拡張現実(AR)に類似する)を含む仮想シーン記述、2)マターフィールド2B09またはライトフィールド2B11のいずれかの一部に関連付けられる現在の温度読み取り値などのセンサ情報であって、典型的には、マターフィールド2B09またはライトフィールド2B11のいずれかに少なくとも一部は基づかず、現在知られているか、もしくはまだ知られていない将来のセンサから利用可能な任意のタイプのデータを含み、特に体性感覚(触る)、嗅覚(臭い)、聴覚(聴く)、または味覚(味)に関連付けられているデータに関係する、センサ情報、および3)マターフィールド2B09またはライトフィールド2B11のうちのいずれかを記述する計算に関係するメトリックスであって、例は、量(サイズの次元など)または品質(温度の次元など)の測定を含み、好ましくは、計算は、少なくとも一部はマターフィールド2B09またはライトフィールド2B11のうちのいずれかに基づく、メトリックスを含む。モデル拡張4C23は、シーンモデル4C09のうちのいずれかに直接関連付けられるか、またはモデル翻訳4C25もしくはモデルインデックス4C27のうちのいずれかを通じてシーンモデル4C09に間接的に関連付けられている。モデル拡張は、少なくとも一部はモデル使用履歴4C29内に含まれる任意の情報に基づくものとしてよく、たとえば、拡張は、複数のユーザにまたがるシーンモデル使用の何らかのログに記録された態様に関する最新の統計量である。
【0100】
なおも図4Cを参照すると、モデル翻訳4C25は、限定はしないが、1)シーンモデル4C09を含むマターフィールド2B09またはライトフィールド2B11のうちのいずれかに適用される幾何学的変換であって、任意のマターフィールドまたはライトフィールド要素の空間的位置を、空間的なシフト、回転、拡大、縮小などを含む新しい位置にマッピングする、幾何学的変換、2)シーンモデル4C09内のオブジェクトの動きを記述するための軌跡経路、またはマターフィールド2B09もしくはライトフィールド2B11のうちのいずれかに対する他の何らかのものなどの複合幾何学的変換、3)たとえばシーンモデルの視覚的表現を体験するビューアは必ずしもフリービュー指示を必要とすることなくシーンを通して案内されるようなシーンモデル内の仮想カメラ(2B03など)の動きおよび視点を記述するための、またはたとえば、ビューアが一方のサブシーンから別のサブシーンに位置を変える可能性があり、サブシーンはシーンモデル4C09内で空間的に同じ位置にあるか、または同じ位置にない、一組の都市ツアー目的地などの提案されたシーンモデル経路を記述するための、経路点タイミングを含む仮想シーン経路、および4)シーンモデル4C09内に含まれるデータおよびたとえば、プラハの聖クレメント大聖堂のjpeg画像を含む関連付けられている補助情報4C21のうちのいずれかの事前コンパイルを含む。モデル翻訳4C25は、シーンモデル4C09のうちのいずれかに直接関連付けられるか、またはモデル拡張4C23もしくはモデルインデックス4C27のうちのいずれかを通じてシーンモデル4C09に間接的に関連付けられている。モデル翻訳は、モデル使用履歴4C29によって参照されるものとしてよく、たとえば、所与の翻訳の使用は複数のユーザにまたがってログに記録される。
【0101】
モデルインデックス4C27は、特にシーンモデル4C09または補助情報4C21のうちのいずれかを含むシーンデータベース1A07のいずれかの部分を選択する人間または自律的ユーザインデックス要素のうちのいずれかに提示するのに有用なデータを含み、データは、限定はしないが、1)テキスト、画像、動画、音声、または他のデジタル情報のうちのいずれかを含むインデックス要素のリストであって、リスト内の各インデックス要素は、要求側ユーザ(人間または自律的)に対して抽出されるシーンデータベース1A07のサブシーンなどの少なくとも1つの部分に関連付けられている、リスト、または2)実行されるコンピュータアルゴリズムを用いてシーンデータベース1A07の一部を選択するのに有用な暗号化または非暗号化情報のうちのいずれかを含むインデックス要素のエンコードされたリストであって、たとえば、シーンコーデック1A01を使用するシステムであるリモートコンピュータは、所望のタイプのシーン情報とのアルゴリズムによる比較のためのシーン情報のタイプを含む抽出可能なシーン情報の暗号化されたモデルインデックスにアクセスし、アルゴリズムは、次いで、アルゴリズムによる比較に少なくとも一部は基づき抽出のためのシーン情報を選択する、リストを含む。所与のモデルインデックス4C27は、任意の所与のユーザ(人間または自律的)によるインデックス4C27(およびしたがって、インデックス4C27を通じてシーンモデル4C09)へのアクセスを許可もしくは拒否することに対する関連付けられている許可情報を含むものとしてよく、許可情報は、所与のユーザの許可されたタイプ、ユーザ名およびパスワードなどのアクセス資格証明書情報に関連付けられている特定の所与のユーザ、およびPayPalなどの遠隔販売取引提供者とインタラクティブにやり取りするためのリンクを含む決済または販売取引関係情報のいずれかを含む。
【0102】
モデルインデックス4C27は、シーンモデル4C09のいずれかに直接関連付けられる。モデルインデックス4C27は、モデル拡張4C23(たとえば、シーンモデルに対応する自然災害シーンなどの実シーン全体にわたって撮影された特定のタイプの現在のセンサ読み取り値)またはモデル翻訳4C25(たとえば、朝、昼間、または夕方の設定でのシーンの再照明、または特定のサブシーンにおけるシーン内への自動入力に続いて、所定の経路に従ってシーン全体にわたる自動移動)に関連付けられるか、またはその使用をトリガーされ得る。モデルインデックス4C27、またはそのインデックス要素のいずれかは、モデル使用履歴4C29のいずれかに関連付けられてよく、関連付けは、関連付けられたシーンモデル経過時間使用を有する複数のユーザ(人間または自律的)によるインデックス要素選択の統計的パーセンテージなどのモデル使用履歴4C29の任意の定式化を含むように広義に解釈され、次いで、統計的パーセンテージは、所与のモデルインデックス4C27でインデックス要素のランキングまたはプレゼンテーションを再ソートするのに使用される。
【0103】
なおも図4Cを参照すると、モデル使用履歴4C29は、ユーザが人間または自律的である場合に、ユーザの要求または指示を表すシーンコーデック1A01を使用してシステムに知られているデータのいずれかを含む。要求または指示は、限定はしないが、1)モデルインデックスおよびモデルインデックス要素の選択、2)明示的または暗黙のユーザ指示に少なくとも一部は基づくシーンモデルのフリービュー、フリーマター、またはフリーライトの調整、3)人間ユーザ追跡身体動作、表情、または可聴音を含む、ユーザの明示的または暗黙のユーザ指示のうちのいずれか、4)サブシーン内で過ごした経過時間、または少なくともサブシーンのインクリメント(シーン全体のより多くを含むような空間的増加など)を行う前、または代替的サブシーンへの切り替えの要求の前のサブシーンの提供から始まる経過時間を含むシーンモデル伝搬情報を一般化すること、または5)モデル拡張4C23(たとえば、シーンデータベース1A07の外部の情報にアクセスするためのURLの使用)もしくはモデル翻訳4C25(たとえば、都市の景観もしくは売り家であるシーンの特定のツアーを表すような予め指定されているシーン経路の使用)の使用を記録する任意の情報ロギングのうちのいずれかを含む。
【0104】
さらに、図4Cに関して、コンピュータデータベースを熟知している者であれば理解するように、現在の市場で利用可能な、または将来的に利用可能になるであろう多数のタイプのデータベース技術があり、現在説明されているプレノプティックシーンデータベース1A07は、これらの任意の数のデータベース技術で、またはこれらの技術の組合せで実装されるものとしてよいが、各技術にはトレードオフとなる利点があり、各技術は本明細書において説明されているような少なくともシーンモデル4C09の表現および表現の組織化の技術的改善によって強化される。コンピュータデータベースを熟知している者であれば、データベース1A07の一実施形態が4C11、4C13、4C15、4C17、および4C19、さらには4C23、4C25、4C27、および4C29を含む4C21を含む様々なデータセット4C07、4C09を含むものとして説明されているが、これらのデータセットに属するものとして本明細書において説明されているデータは、データセットの異なる配置構成に再編成され得るか、またはいくつかの説明されているデータセットは、例示的な実施形態の真の範囲および精神から逸脱することなく他のデータセットに分割されるか、または他のデータセットに組み合わされ得ることが認識されよう。少なくとも図4Cの提示において特には検討されていない他のデータが本明細書において説明されており、この他のデータも、プレノプティックシーンデータベース1A07内に含まれるが、本明細書の図に示されているそれらのデータセットを含まない独自のデータセットを形成してもよいことも理解されるべきである。本開示を慎重に読めば、シーンコーデック1A01を使用するシステムが有用で新規性のある機能を実行するか、または本明細書において説明されている多くの技術的改善のうちのいずれか1つを他の何らかの形で提供するために本明細書の図で説明されているデータセットのすべてがデータベース1A07内に存在しなければならないわけではないことも明らかになる。したがって、本明細書の図4Cに関して説明されているようなプレノプティックシーンデータベース1A07は、例示的な実施形態の制限としてではなく例として考慮されるべきであり、本明細書で提供される実施形態の範囲から逸脱することなく多くの変更形態が可能である。
【0105】
次に、図5、図6、および図7をまとめて参照すると、いくつかの例示的な実施形態により、シーンコーデック1A01を使用するシステムに対する一般的ユースケースの3つの変更形態を説明している一連の3つのフローチャートが示されている。3つの流れ図の各々は、ボックス、卵形、またはダイヤモンドのいずれかである一連の接続されたプロセス形状を示しており、これらのプロセス形状の各々は、例示的な実施形態において提供される技術的改善の一部を含む専用コンピュータプロセスの高水準の機能を表していることは理解されるべきであり、次いで、形状すべておよびそれらの相互接続は、まとめて、本明細書において指定されている技術的改善をさらに記述している。ダイヤモンドの形状は、一般的ユースケース内でのユーザの要求の処理に関してシステムに対する重要な分岐判定を決定する機能を表す。一般に、形状の各々は、コンピューティングデバイス上で処理するための実行可能命令セットを表すと理解され得るが、これらのコンピューティングデバイスは、複数のコアを有し、これらのコアの各々が1つもしくは複数の機能を実行する、単一のCPU、または単一もしくは複数のコアを有する複数のCPUなどの多くの可能な変更形態の任意の配置構成であるものとしてよく、これらの複数のCPUは、前に説明したように、任意のタイプのネットワーク上に分散され得る。また、前に説明されているように、本明細書において説明されている特定の新規性のある技術に対する特定のコンピュータオペレーションがあり、これらは、ハードウェア専用処理ユニットの何らかの形態、たとえば、埋め込みコードと称されることが多いコードを実行するFPGAもしくはASICまたは他のよく知られているハードウェアを使用してさらに最適化され得る。特に、いくつかの例示的な実施形態は、好ましくは、本開示において説明されている重要なプレノプティックシーン処理機能に最適化されたカスタマイズ済みデジタル回路を備える場合もある、組み込みシステム上で実行される一組のオペレーションである空間処理ユニット(SPU)1A09(図1A参照)を含む。
【0106】
なおも図5、図6および図7をまとめて参照すると、例示的な実施形態は、シーンモデルの再構築、配信、および処理のための著しい利点をもたらし、従来から、大部分のコーデックは、フリービューおよびサブシーンオンデマンドも、たとえば視覚的ではないシーンデータの伝送(シーン計量、マターフィールド、またはライトフィールドなど)も、たとえばシーンデータの異なる形態および態様を求めて同じモデルに各々がアクセスする人間ユーザおよび自律的ユーザの代わりにシーンデータのサービスすることなどの本明細書において説明される利点の多くを提供しない、映画などの、画像情報を伝送すると理解されるべきである。シーンモデルを伝送するためのいくつかのシステムがあり、これは特に仮想現実(VR)システムを含むが、典型的には、VRシステムは、図4Aに示されている現実世界のシーンなどの重要なリアリズムを欠くコンピュータモデリングに基づく。シーンモデル内に再構築された現実世界のシーンを伝送するための他のシステムがあるが、本明細書のシステムは実シーンの固有のプレノプティック八分木表現を提供し、マターフィールド2B09およびライトフィールド2B11は、既存のシステムよりも高い程度で分離され、ほかりもあるがとりわけマターフィールド2B09およびライトフィールド2B11の表現の組織化は、大きな現実世界の再構築されたシーンのリアルタイムの、またはリアルタイムに近いアクセスおよび消費を可能にする基本機能の著しい技術的改善を提供する。したがって、本発明のシステムは、実シーンの表現および表現の組織化を提供してプレノプティック八分木データベース1A07が分散型ネットワーク上でシステムが大きなグローバルシーンを処理することを可能にし、そこではシーンは間欠的または連続的な再構築を受けていることすらあり、情報の基本的な転送は、たとえば従来のコーデックなどの単なる視覚データではなく、さらには他の最新技術のシーンモデルコーデックなどの再構築されたモデル全体ですらなく、ジャストインタイムの異種、非同期のプレノプティックデータのストリームである。
【0107】
次に示す図5、6および7を参照すると明らかになるであろうが、コーディングされたシーン1A01を使用する2つ以上のシステムを使用してシーンを処理する仕方は多数あり、たとえば、第1のシステム1A01はサーバ上に置かれ、人間または自律的消費者(クライアント)のいずれかにオンデマンドでシーンモデル情報を提供し、次いで、クライアントは、第2のシステム1A01を使用してシーンモデル情報を受信し、処理する(たとえば、図5参照)。他の変更形態において、第1のシステム1A01は、最近の雹の嵐で損傷を受けた自分の車、または嵐で損傷したもしくは単純に売りに出す用意ができている自分の家など、「ローカル」対「グローバル」のシーンと考えられ得るものをキャプチャすることを望むクライアントによって使用されている。このタイプのユースケースでは、クライアントシステム1A01は、ローカルシーンの生データをキャプチャするためにシーンセンサ1E09を備えるようにさらに適合されている(特に図6を参照)。次いで、この生シーンデータは、ローカルクライアントシーンを再構築し、再構築されたサブシーンおよびサブシーンインクリメントを再送してクライアントシステム1A01に送り返す主な責任を負うサーバ上で稼動する第2のシステム1A01にネットワーク上で伝送されることが可能である。さらに他の変更形態では、共有シーン(災害現場または工業用倉庫など)でクライアントによって使用される第1のシステム1A01、およびネットワーク上で稼動する第2のシステム1A01は、両方とも、クライアントによってキャプチャされたシーンデータをサブシーンおよびシーンインクリメントに再構築する責任を共有し、次いで、これらの再構築されたサブシーンおよびシーンインクリメントは、コーデック機能を介して第1および第2のシステム1A01の間で共有され、第1のシステム1A01によってローカルでキャプチャされた共有シーンは、(第1および第2のシステム1A01の連携によって)より大きなシーンモデルにコンパイルされ、それでもまだ第3のシステム1A01との共有のためにも利用可能であり、次いで、この第3のシステムは、共有シーンのローカルにあり、生データもキャプチャするか、または第1および第2のシステム1A01の両方からリモートにあり、したがって、共有シーンからもリモートにあり得る。
【0108】
図5、図6、および図7に関してまとめて述べると、コーデック1A11のエンコーダ機能を表すいくつかの長方形の形状(図5の505、515、517、図6の505、515、517、図7の505、517)、コーデック1A11のデコーダ機能を表すいくつかの形状(図5の507、511、図6の507、511、図7の507、511)、およびアプリケーションソフト1A03を表すいくつかの形状(図5の501a、501b、503、509、513a～d、図6の501a、501b、503、509、513a～d、図7の501a、501b、503、509、513)が示されている。コンピュータシステムおよびソフトウェアアーキテクチャを熟知している者であればよく理解するように、図5、図6、および図7において形状として表される様々なオペレーションおよび機能の配備済み実施形態は、任意の1つまたは複数の機能を実行するための任意の1つまたは複数の処理要素の使用を含む、多くの変更形態を有し、たとえば、処理要素は、コーデック1A11またはアプリケーションソフトウェア1A03の機能のうちのいずれかと通信しており、サポートする組み込みプロセッサとして実行されるCPU、GPU、または本明細書で定義されているSPU1A09のうちのいずれかである。したがって、次に示す図5、図6、および図7に関する描写および仕様は、例示的な実施形態の制限としてではなく、例として考慮されるべきであり、説明されている機能は、さらに組み合わされるか、またはさらに分割されてよく、様々な組合せにおけるこれらの機能は、例示的な実施形態の範囲および精神から逸脱することなく多くの変更形態で実装され、配備され得る。また、ソフトウェアシステム、ネットワーク、従来の圧縮、シーンモデリングなどの当業者には、他のいくつかの機能は、明確にするために省略されているが、既存の知識に基づき明らかであり得る(ネットワークが使用される場合にはネットワークのタイプに応じてトランスポート層1E03の機能など)ことも明白であろう。図5、図6、および図7は、また、いくつかの接続線を他のものよりも太いものとして示しており、これらの太い接続線(図5の505～507、517～507、図6の501b～505、505～517、517～507、図7の501b～505、505～517、517～507)は、図2Bに関して一般的に説明されているストリーム2B13などのプレノプティックシーンデータベース1A07の情報の任意の組合せの伝送、または実カメラ2B05-1および2B05-2などのシーンセンサ1E09によってキャプチャされるようなシーン再構築もしくはアノテーションを目的とするシーンデータ2B07(図2B参照)の伝送を表す。
【0109】
次に図5だけを参照すると、たとえば、人間または自律的のいずれかであり、フリービュー、フリーマター、フリーライティング、計量、従来の2D、3Dもしくは4D可視化、関連する(5つの)センサ情報のいずれか、プレノプティックシーンデータベース1A07内に含まれるかもしくはプレノプティックシーンデータベース1A07に関連付けられているかのいずれかの補助情報もしくは他の何らかの形で関係するシーンモデル情報のうちのいずれかを含む本明細書において説明されているような様々なタイプのシーンモデル情報のうちのいずれかを消費しているリモートクライアントとのより大きいグローバルシーンモデルの共有を含む一実施形態の流れ図が示されている(たとえば、データベース1A07は、現在の気象条件、サポートしている動画、製品情報などの他のインターネットアクセス可能コンテンツに接続する空間シーン内に埋め込まれているURLリンクを含む)。この例示的な実施形態では、グローバルシーンモデルは、消費側クライアントからリモートにあるだけでなく、法外に大きい、したがってグローバルシーンモデル全体をクライアントに単純に転送することができないことが想定され得る。分かりやすく説明するために、図5の流れは、多くの可能性のある特定のユースケースのうちの1つ、すなわち、サーバ上で利用可能にされるシーンモデルの都市ツアーのグローバルリポジトリに関してリモートクライアントとして都市ツアーを要求する人間ユーザだけに関して説明される。
【0110】
なおも図5を参照すると、人間クライアントは、好ましくはモバイルデバイスなどのクライアントシステム1A01上で稼動するアプリケーションソフトウェア1A03によって実行されるクライアントUI(ユーザインターフェース)501を操作する。また、クライアントシステム1A01内に含まれるか、またはクライアントシステム1A01と通信しているかのいずれかであるのは、少なくとも一部はユーザ要求のうちのいずれかを決定するために使用可能である人間ユーザに関する何らかのデータを少なくとも感知するためのゼロ個またはそれ以上のセンサ1E09(図1E参照)である。例示的なセンサは、マウス、ジョイスティック、ゲームコントローラ、ウェブカメラ、運動検出器などを含み、例示的なデータは、好ましくは、視点変更および/または現在のサブシーンへの次のシーンインクリメントを決定するのを補助するために少なくとも一部はシステム1A01によって使用可能である現在進行中のシーン内の追跡される現在位置/視点に関する方向、経路、軌跡、または類似のものを含む所望のシーン移動もしくは視点変更を明示的にまたは暗黙のうちに示すデータを含み、これはこの後より詳しく手短に説明されることになる。クライアントシステム1A01は、人間ユーザ、たとえば2Dディスプレイ、VRヘッドセット、またはホログラフィックディスプレイにデータを送るための1つまたは複数のセンサ出力1E11(図1E)をさらに備える。
【0111】
本発明の例の第1のステップにおいて、人間ユーザはクライアントUI501にアクセスして、グローバル注目シーン(SOI)501aを決定し、たとえば、選択肢は、世界の主要都市を含む複数の世界中の観光地であり、たとえば、ユーザは、プラハの都市観光に参加することを選択する。オペレーション501aは通信しており、グローバルSOIオペレーション503からのシーンインデックスを決定し、提供し、たとえばユーザがプラハの仮想都市ツアーに参加することを選択した後、オペレーション503は、画像、短い動画、顧客評価、批評家評価、テキスト、ウェブサイトへのURLリンク、ホテルおよびレストラン情報、ならびにウェブサイトなどの関連補助情報とともに複数の可能なツアーのインデックス(したがって、接続された経路を有するシーンエントリーポイント、特に図4Cのモデル翻訳4C25を参照)を提供し、他のシーンインデックス情報とともにこの補助情報は、データのタイプに基づきよく知られている従来の技術およびコーデックを使用して伝送されるものとしてよく、したがって、プレノプティックストリーム2B13(図2Bを参照)に含まれる必要はない。オペレーション503は、プレノプティックシーンデータベース1A07(図2B参照)を収容するか、またはプレノプティックシーンデータベース1A07(図2B参照)へのアクセスを有するサーバサイド1E05システム1A01上で実行されることもあり得るが、オペレーション501aさらにはクライアントUI501の他の処理は、好ましくは、グローバルSOIオペレーション501b内の初期サブシーンを決定することを含む、クライアントサイド1E07システム1A01上で実行される。オペレーション501bでは、ユーザは、オペレーション503によって提供されるシーンインデックスからシーンモデルに入るためのサブシーンを検討して選択し、たとえば、ユーザは、聖クレメント大聖堂のナルテックスから始まる都市-大聖堂ツアーを選択する。
【0112】
なおも図5を参照すると、オペレーション501bは、グローバルSOIモデルオペレーション505から初期サブシーンを抽出することを通信し、ユーザの選択されたサブシーン、たとえば聖クレメント大聖堂のナルテックスの指示をオペレーション505に対して伝送する。ユーザの選択されたサブシーンに少なくとも一部は基づき、また、決定されたサブシーンバッファサイズ情報に少なくとも一部は基づき、オペレーション505は、クライアントシステム1A01に第1の独立したサブシーンとして提供するための少なくとも初期マターフィールド2B09およびライトフィールド2B11のデータのセットを決定するようにプレノプティックシーンデータベース1A07にアクセスする。一実施形態において、オペレーション505は、もっぱら、シーンコーデック1A11の機能であり、オペレーション505は、直接的にまたはアプリケーションソフトウェア1A03などの中間システムコンポーネントを通じてのいずれかでオペレーション501bと通信する。別の実施形態において、アプリケーションソフトウェア1A03は、実質的にオペレーション501bとオペレーション505との間の通信サービス以上のものを提供し、ソフトウェア1A03は、たとえば、バッファサイズを決定することを主に受け持つオペレーション505の部分を実装し、次いで、シーンコーデック1A11に様々なアプリケーションインターフェース(API)コールを呼び出すことによって初期サブシーンを抽出し、次いで伝送することをシーンコーデック1A11に行わせる。可能であり、ソフトウェアシステムを熟知した者によって理解されるこれらまたは他の可能な実施形態のいずれかにおいて、シーンコーデック1A11の一部として実行されるプロセスは、次いで、SPU1A09への様々なAPIコールを呼び出すものとしてよい。
【0113】
さらに別の実施形態において、シーンソルバー1A05は、たとえば好ましいバッファサイズを決定するときにたとえばアプリケーションソフトウェア1A03またはシーンコーデック1A11のいずれかによって呼び出され、シーンソルバー1A05は、機械学習アルゴリズムを含む決定論的または非決定論的(たとえば、統計的もしくは確率的)アルゴリズムを実行して、好ましくは少なくとも一部はデータベース1A07内に含まれる補助情報4C21(図4C参照)に基づきバッファサイズを定めるか、または予測し、補助情報4C29は、同じサブシーンまたは異なるサブシーンのいずれかにアクセスする、他のユーザの事前のクライアントセッションについてログに記録されているように事前のバッファサイズおよびシーンの動きを示すデータから少なくとも一部は基づき機械学習を行うための基礎として特に有用である。ソフトウェアシステムおよびアーキテクチャの技術を熟知している者であれば理解するように、機械学習アルゴリズムを含むこれらの同じ決定論的または非決定論的(たとえば、統計的または確率的)アルゴリズムは、シーンコーデック1A11、SPU1A09、アプリケーションソフトウェア1A03、さらには本明細書において具体的に説明されていないが、本明細書の説明に基づき明らかになるであろう他の何らかのコンポーネントの機能とすることも可能であり、たとえば、シーンコーデック1A01を使用するシステムは、たとえば現在入手可能であり、市場において知られているか、または今後知られるようになるであろう専用機械学習ハードウェアのうちのいずれかを使用して実装される別のシーン使用学習コンポーネントを備える。
【0114】
NVIDIAとして市場で知られている少なくとも1つの技術会社は、現在、「Infrastructure 3.0」と呼ばれるものの一部であり、NVIDIAによって「テンサーコア」と称されているものをさらに含む専用GPU上に実装される、「AIチップ」と称される技術を提供している。本明細書の開示は、シーンモデル、およびより具体的には、従来はシーンデータであるとは考えられていないが、むしろ、人間またはオートマトンのいずれかによってシーンモデルがあらゆる仕方でどのように使用されるかということを指向するモデル使用履歴4C29などのデータである補助情報4C21を含むプレノプティックシーンモデルの新規性のある表現および表現の組織化を提供する。機械学習を熟知している者であれば理解するように、例示的な実施形態は、シーン学習の実装に対するいくつかの新規性のあるアプローチを提供しているが、他のアプローチおよび実装形態は、特にバッファサイズの決定に関して明らかな場合があり、これらの実装形態は、一般的なコンピューティングハードウェア上で実行されるソフトウェアおよび/または専用機械学習ハードウェア上で実行されるソフトウェアであってもよく、これらのすべての解決策は、本開示の範囲および精神の範囲内にあると考えられる。
【0115】
なおも図5を参照すると、いくつかの決定されたまたは提供されたシーンエントリーポイントおよびいくつかの決定されたまたは提供されたシーンバッファサイズまたは他の何らかの形の、SOI(たとえばグローバル)シーンモデル全体から抽出されるようにサブシーンを予測可能に制限する情報に基づき少なくとも効率的な(ジャストインタイム)サブシーン抽出に関する説明がなされており、これにより空間バッファに関する抽出されたサブシーンは最小限度の量の提供されたシーン情報によってもたらされる最大限連続的なユーザ体験を実質的に確実にする。ユーザの選択されたサブシーンを表すプレノプティックシーンデータをデータベース1A07から決定した後、プレノプティックシーンデータは、データベース1A07内に含まれるマターフィールド2B09およびライトフィールド2B11のデータの任意の組合せの非同期的なジャストインタイムストリーム2B13として伝送され、ストリーム2B13は、たとえば、2π～4πフリービュー操作を人間ユーザに提供することができるセンサ出力デバイス2B19を通じてユーザ2B17に提供されるたとえば画像および対応する音声などのセンサ出力内への処理のためにシーンコーデック1A01を使用してクライアントサイド1E07システムによって受信され、出力デバイス2B19は、クライアントUI501を通じて利用可能な任意のセンサ出力デバイス1E11の具体例である。
【0116】
コーデック1A01に含まれるデコーダによってストリーム2B13を受信する第1のステップとして、クライアントSOIモデル507に次のシーンデータを挿入するための機能が実行され、その結果、サブシーンが抽出され提供されたグローバルシーンモデル(すなわち、プレノプティックシーンデータベース1A07)をミラーリングしているが同等ではないクライアントSOI(すなわち、プレノプティックシーンデータベース1A07)の再構築もしくは更新が行われる。実質的にプレノプティックシーンモデルデータを含む提供されたストリーム2B13が、クライアント(「ローカル」)データベース1A07に最初に収めることなく、またはこれまでにクライアントデータベース1A07に収めたことすらなく、要求されたユーザデータに翻訳されることが可能であり、例示的な実施形態の範囲内で考慮されることを見ることが重要であり、シーン翻訳は、たとえば、フリービューまたはユーザ要求を満たす他のシーンデータへのレンダリングおよび提示のステップを介して行われる。しかしながら、好ましく、また本明細書において著しい利点を提供することが示されているのは、クライアントデータベース1A07を最初にまたは追加して再構築することによって、またストリーム2B13をユーザフリービュー可視化などの要求シーンデータにただ翻訳するだけでないことによって、グローバルシーンモデルから実質的に独立して、または少なくとも準独立して、進行中のクライアントサイドベースのシーンデータ提供を許すことが可能であり、ここで、時々、ユーザの要求に基づきローカルクライアントシーンデータベース1A07を更新するか、またはさらに「成長」させる必要があり、そのような成長は、手短に説明されるサブシーンインクリメントを提供することと称される。
【0117】
なおも図5を参照すると、ソフトウェアシステムおよびアーキテクチャを熟知している者であれば、オペレーション507が好ましくはシーンコーデック1A11内でデコーダの一部として実装され、オペレーション507の少なくとも一部はクライアントUI501を実装するアプリケーションソフトウェア1A03によって実行されることが可能であることを理解するであろう。たとえば、アプリケーションソフトウェア1A03は、オペレーション509において、要求されたシーンデータの実際の提供の前にクライアントUI501に指示および変更を提供することを含むこともあり得る。従来のシーン処理では、オペレーション509は、要求されたデータがたとえばフリービュー可視化である場合にレンダリングと一般的に称されるものを含む。現在のレンダリング技術に関して、プレノプティックシーンデータベース1A07であることにより、例示的な実施形態は、フリーマターおよびフリーライティングのオプションを増やし、なおいっそう現実的なフリービューを提供する。ソフトウェアアーキテクチャを熟知している者によって理解され、本開示を慎重に読むことに基づき理解されるように、挿入オペレーション507および提供要求データオペレーション509は両方とも、シーン処理ユニット(SPU)1A09への様々なアプリケーションインターフェース(API)コールを呼び出し得る。従来のコーデックとは異なり、例示的な実施形態は、シーンデータのサーバにシーンデータが受信されたという確認511を行うが、これは、将来提供されるシーンインクリメントが、最初に提供された独立したサブシーンさらにはその後に提供される任意のシーンインクリメントに依存することを考慮したときに特に重要な特徴である。
【0118】
なおも図5を参照すると、クライアントSOIデータベース1A07は、オペレーション509で必要とされるSOIデータのいずれかおよびすべてを提供するのに十分であり得ることを見ることが重要である。最初の独立したサブシーンが、将来のすべてのデータ要求を満たすのに十分である範囲は、最初のサブシーンのサイズに比例し、要求されるべきシーンデータの範囲に反比例する。要求される、または予想されるシーンデータの範囲が増大するにつれ、十分なシーンバッファを有する予想初期サブシーンを伝送するための負担およびコストは、最終的には法外なものになる。たとえば、初期サブシーンが聖クレメント大聖堂のナルテックスであり、そこからユーザが大聖堂に入って大広間に立つことしか期待されていない場合、サブシーンのサイズは限られたものになり得る。しかし、ユーザが大聖堂に入るか、または通りを渡って別の建物に入ることが予想される場合、サブシーンは必然的にサイズを大きくしなければならない。したがって、例示的な実施形態では、最初のサブシーンは、インテリジェントに決定されたシーンバッファを含み、特定の量のシーンデータまでの予想ユーザ要求と、伝送されるシーンデータを最小限度に抑え、それによって知覚されるシーンまたはUIの遅れを減少させる必要性とのバランスをとると規定し、その後、システムは、明示的または暗黙のうちのユーザ指示のうちのいずれかに基づきさらなる要求もしくは予想されるさらなる要求を満たすためにグローバルモデルからサブシーンのさらなるインクリメントを伝送する備えをする。ここでもまた、好ましくは、このバランスは、機械学習および他の決定論的手法に基づいており、これは少なくとも一部は類似のユーザ要求の履歴に基づき、それにより、最大限連続的なユーザ体験が最小量の最初に提供された、およびその後徐々に増やして提供されたシーン情報によって提供される。
【0119】
様々なタイプの予測システムを熟知している者には明らかなように、「先読み」(未来への)時間が増大すると、可能なシーン移動の変更形態の数は、直線的ではなく幾何学的に、または指数関数的にすら増加する。たとえば、ユーザが聖クレメント大聖堂のナルテックスの初期サブシーンを与えられた場合、先読み時間は1分対1時間であれば、シーンバッファのサイズは少なくとも幾何学的に増加し、それにより、計算されたバッファサイズが1分間Xであれば、1時間Yのバッファサイズは60*Xよりも実質的に大きくなる。これに関して、特定の実施形態の別の重要な技術的利点は、プレノプティックシーンモデルの表現およびこれらの表現の組織化の両方が、現在知られているシーン処理技術に関して、任意の選択されたバッファサイズが与えられた場合に、任意の初期サブシーンまたはシーンインクリメントを抽出するのに必要な処理時間を著しく短縮することが示されるという点である。したがって、バランスのトレードオフの関係を慎重に考慮すると明らかであるように、サブシーンまたはシーンインクリメントの抽出および処理の両方の著しい時間短縮により、同じシステム応答時間に対してより大きな初期サブシーンバッファをサポートすることができ、またより頻繁なシーンインクリメントに有利なより小さなサブシーンインクリメントバッファをサポートすることでき、より小さなより頻繁なアプローチは、ユーザ要求の先読み時間が短縮されるように実際に伝送されたシーンデータの合計を低減する。
【0120】
なおも図5を参照すると、残りのプロセスクライアント要求オペレーション513およびログ消費オペレーション515は、初期サブシーンが現在のまたは将来の可能なユーザ要求を満たすのに十分なシーンデータを欠いていると決定されるか、または予想される場合にユーザのシーン使用を追跡し、クライアントSOIモデルのインテリジェントインクリメントを提供する。ユーザがUI501をインタラクティブに操作し、たとえば更新されたシーンデータを受信するときに、これらのインタラクションは、シーンデータの値および消費の指示を提供する。さらに、クライアントUI501は、好ましくは、ユーザが、マウス、ジョイスティック、ゲームコントローラ、またはVRヘッドセットを動かすことなどによってより多くのシーンデータに対する要求として解釈可能な指示を表現することを可能にし、それらの指示は、センサ1E09を使用して検出される。これらの使用または予想される使用のいずれか1つまたは複数の指示は、システムが、オペレーション513aとしてクライアントSOIモデル内のユーザ消費を追跡することを可能にし、追跡される使用は、モデル使用履歴4C29(図4C参照)としてサーバおよびクライアントの両方のプレノプティックシーンデータベース1A07のいずれかに保存される。
【0121】
ユーザ表示がクライアントUI501によって処理されるときに、プロセスクライアント要求オペレーション513は、ユーザ指示のいずれかがシーンデータに対する次の要求として解釈可能であるかどうか、次いでその後、次の要求が既存のローカルクライアントSOIモデル内にすでに含まれているシーンデータだけに基づき満たされ得るかどうかを決定するためのオペレーション513bを含む。次の要求が、既存のクライアントSOIモデルだけに基づき満たされ得る場合に、要求されたシーンデータは、オペレーション509によってユーザに提供される。次の要求が既存のクライアントSOIモデルだけに基づき満たされ得ない場合に、オペレーション513cは、次の要求がクライアントSOIモデル内の既存のサブシーン(または複数のサブシーン)へのインクリメントするかどうか、または次の要求が全く新しい(したがって独立した)サブシーンに対するものであるかどうかを決定する。要求が新しいサブシーンに対するものである場合、オペレーション513cは、クライアントUI501に制御を移すか、または他の何らかの方法でクライアントUI501を呼び出し、要求されている新しいサブシーンが何であるか(たとえば、セントローレンス大聖堂への切り替え)、またはユーザが全く新しいグローバルシーン(たとえば、ベニスのツアーへの切り替え)を要求している可能性があるかどうかすら、効果的に決定する。要求が新しいサブシーンではなく、現在のサブシーンへのインクリメントによる追加を必要とする方式で既存のサブシーンを探索し続けることである場合、オペレーション513dは、サブシーンに対する次のインクリメントベクトルを決定する。次のインクリメントベクトルは、時空間的広がり、空間的ディテール、ライトフィールドダイナミックレンジ、またはマターフィールドダイナミックレンジなどのシーンモデルの次元のうちのいずれかを表し、このベクトルは、ユーザの要求を満たすために最小限必要とされる新しいシーンデータの範囲を示す任意の情報である。ベクトルを決定するとき、オペレーション513dは、好ましくは、ログ消費オペレーション515によって追跡されるユーザ履歴にアクセスすることができ、(現在および他のすべての追跡されたユーザの)使用履歴とともにユーザの要求を最小限満たすように決定されたベクトルは、次のシーンインクリメントおよびインクリメントバッファサイズを推定するときにシステムによって少なくとも一部は使用するために組み合わされるものとしてよく、ここでもまた、バッファサイズは、予想される「先読み」サブシーン使用を含むように最小限満たすベクトルのシーンインクリメントを超えてシーンインクリメントを拡大する。
【0122】
なおも図5を参照すると、ソフトウェアシステムを熟知している者によって理解されるように、ユーザの指示およびシーンモデルの消費の少なくとも一部を追跡し、ログに記録するという好ましいステップを実行しながらオペレーションの他の配置構成が可能である。さらに、オペレーションの他の配置構成は、ユーザが追加のシーンデータを明示的にまたは暗黙のうちに要求しているかどうかを決定し、もしそうならば、この追加のシーンデータがクライアントシーンモデルデータベース1A07内にすでに存在しているかどうかを決定しながらも可能である。追加のシーンデータがすでに存在していないが、クライアントSOIデータベース1A07内にすでに存在しているサブシーンへの拡張である場合に次のシーンインクリメントおよびバッファサイズを決定する上でオペレーションのさらに他の配置構成が可能である。そのようなものとして、本発明の図においてクライアント要求513を処理し、消費515をログに記録するために提供されている機能は、実施形態に対する制限ではなく、例であるものとして考慮されるべきである。さらに、オペレーション513、513a、513b、513c、513d、および515はいずれも、それ自身の処理要素上で同時に実行するように実装されるか、または単一の処理要素上で順次実行するように実装されることも可能である。たとえば、ユーザ消費オペレーション513aおよび515を追跡し、ログに記録することは、要求追跡オペレーション513bおよび513cの逐次処理と並列に実行され得る。別の考察では、ログ消費オペレーション515は、クライアントSOIデータベース1A07使用履歴4C29を更新するためのクライアントシステム1A01、およびグローバルSOIデータベース1A07使用履歴4C29を更新するためのサーバシステム1A01の両方で実行されることも可能である。また、サブシーン513dに対する決定された次のインクリメントベクトルの一部または全部(バッファサイズの決定を含む)が、クライアントシステム1A01またはサーバシステム1A01のいずれかで実行されることも可能である。
【0123】
シーンモデルのユーザの使用が追跡され、集計され、クライアントシステムが、クライアントシステム1A01上に現在置かれているか、またはクライアントシステム1A01がアクセス可能なクライアントSOIモデルだけに基づき新しいシーンデータに対する要求を満たすことを最初に試みること、および追加のサブシーンインクリメントがグローバルSOIモデルから必要とされる場合に、予想される量の先読み使用および決定されたサービス品質(QoS)レベルの両方に関して最大限連続的なユーザ体験を提供するために必要な最小量のサブシーンインクリメントを決定する計算が行われ、予想される量の先読み使用の決定は追跡される使用履歴に少なくとも一部は基づくことに留意することが重要である。
【0124】
次に図6を参照すると、図5の説明に基づいて構築されているが、クライアントが既存のモデルにアクセスするのではなく、最初にシーンモデルを作成するか、または既存のシーンモデルを更新する場合の変更形態の事例に対処するいくつかの例示的な実施形態の流れ図が示されている。図5に関して、オペレーション507、509、511、513(513a、513b、513c、および513dを含む)、515、および517は、実質的に図5で説明されている通りであり、したがって、この図6に関しては最低限度の追加説明がなされる。図6の例示的なユースケースは、たとえば雹嵐で損傷した自分の車のボンネットのシーンモデルを作成(または更新)するためにシーンコーデック1A01を使用するシステムである携帯電話などのモバイルデバイスを用いて作業しているユーザである。図5、図6、および図7の流れ図の各々に、図6に関する自動車の損傷をモデル化することなどの、例示的なユースケース以外の多くのユースケースが適用可能である。たとえば、この図6のユースケースは、たとえば自宅を含む資産または不動産のうちのいずれかのシーンモデルをユーザがキャプチャすること、またはたぶん、ユーザが資産もしくは不動産のモデルをキャプチャすることを必要とする保険会社もしくは不動産業者などのエージェントである場合にも同様に適用可能である。企業および土建会社は、また、同じユースケースを使用して重要な資産または不動産のシーンモデルをキャプチャし、他の人と共有することも可能であり、これらの資産または不動産は、いかなる規模であってもよく、ほとんど無制限の視覚的ディテールを有し得る。
【0125】
なおも図6を参照すると、クライアントUI501は、図5と同様に、センサ1E09およびセンサ出力1E11の両方を備え、ユースケースにおける1つの違いは、図6で例示されているものについては、センサ1E09は、プレノプティックシーンモデルおよびデータベース1A07内に再構築されるべき資産、不動産、または他の何らかの形の実シーンを感知するための1つまたは複数のセンサを備える点である。典型的なセンサ1E09は、図2Bに示されている2B05-1および2B05-2などの1つまたは複数の実カメラであろうが、そうでなければ、複数のセンサおよびセンサのタイプのうちのいずれかであってもよい。クライアントUI501は、ユーザが新しいクライアントSOIをインスタンス化するか、または既存のクライアントSOIを選択することを可能にし、このクライアントSOIはたとえば自分の車またはさらには車のボンネットであり得る。例示的な実施形態では、たとえば、ユーザの資産、不動産、または他の何らかのシーンのいずれかのプレノプティックシーンモデルが予め存在し得ること、またはユーザが新しいシーンモデルを作成(インスタンス化)しようとしていることを規定し得る。たとえば、ユーザがレンタカー業者であり、借り手がレンタカーを走査台に返却したばかりである場合に、クライアントUI501は、業者が借り手の同意書からバーコードをスキャンし、次いで、この情報を少なくとも一部使用して、レンタル開始前の同じ車両の既存のプレノプティックシーンモデルを呼び出すことを可能にすることもあり得る。したがって、自動車は、おそらく、自律的であるがそれでもセンサ1E09として考えられるデバイスによって、再スキャンされ得、新たにスキャンされた画像または他の何らかの形で感知されたデータは、車両の既存のシーンモデルを更新するために使用可能である。
【0126】
このアプローチを使用して、前に述べたように、プレノプティックシーンは、3つの空間次元さらには時間次元も含む4つすべての次元に存在する。したがって、既存のプレノプティックシーンモデルの任意の精緻化は、元のベースラインのマターフィールドおよびライトフィールドのデータが上書きされるか、もしくは他の何らかの形で失われるようにプレノプティックシーンを恒久的に変更するか、または精緻化は、たとえば、東部標準時2019年4月25日午前10時44分のような特定の時間、またはレンタル契約書970445Aのような事象名のいずれかに関連付けられる追加の表現として組織化され得る。次いでマターフィールドおよびライトフィールドがプレノプティックシーンデータベース1A07の時間次元で組織化されるならば、次いで、1)任意の実シーンの再構築および精緻化のため前または後の時間/事象に基づきシーンデータのいずれかを作成し、2)プレノプティックシーンデータベース1A07内の2つの時点の間の違いを測定するか、または他の何らかの形で記述し、3)マターフィールドおよびライトフィールドを含むシーンモデルの任意の部分の一部または全部などの、データベース1A07の特徴のうちのいずれかによってフィルタ処理されたプレノプティックシーンデータベース1A07の変更履歴をカタログ化することが少なくとも可能である。
【0127】
ユーザがたとえば雹害を文書化して測定するために自分の車のボンネットをスキャンする例では、ユーザが車のプレノプティックシーンモデルのリモートデータベースにアクセスし、ベースラインのプレノプティックシーンなしで新しいモデルをインスタンス化するのではなく、ユーザが最初に自分の車の適切なベースラインとなるメーカーおよび型式を選択し、次いでこれをベースラインモデルの再構築および精緻化のために自分の固有のデータをスキャンするための基礎として使用することも予想される。この場合、クライアントUI501は、ユーザがたとえばベースラインモデルに関連付けられているマターフィールドを調整する、たとえば、車の色をユーザによって追加されたカスタム塗装色に変更することを可能にする、またはベースラインと固有の実シーンとの間の任意の類似するタイプの違いを可能にする、ユーザ向けのインテリジェント機能を提供することもさらに予想される。マターフィールドの任意の部分が、たとえば「車の外装」と命名されるか、またはタグ付けされ得ることがさらに予想され、このタグはモデル拡張4C23(図4Cを参照)であると考えられるような補助情報4C21である。慎重に考察すると分かるように、タグ付けされたベースラインプレノプティックシーンモデルを提供することによって、システムは、新しいカスタムシーンモデルを作成し、精緻化するための著しい手段を提供する。
【0128】
いくつかの例示的な実施形態は、ベースラインのプレノプティックシーンモデルとともに、複数のタグ付けされたプレノプティックマターフィールドおよびライトフィールドのタイプならびにインスタンスをさらに提供し、たとえば、自動車メーカーは、自動車の型式のうちのいずれかの構築に使用される様々な材料を表す様々なプレノプティックマターフィールドタイプを作成し、ここでもまた、自動車の型式は、ベースラインプレノプティックシーンとして表現される。この配置構成では、自動車の販売員は、ベースライン内に置き換える異なる材料(マターフィールド)タイプを選択するために、ベースライン車を素早く変更することができ、それによりこれらの型式の翻訳4C25(図4C参照)が、その後、探索のためのプレノプティックシーンモデル(図5の一般的ユースケースのような)としてアクセスできる。慎重な読者が理解するように、図5、図6、および図7に提示されている一般的ユースケースの各々に対して事実上無数の使用があり、本明細書において説明され、暗示され、または他の何らかの形で明らかな他のユースケースの変更形態は言うまでもなく、特に図5、図6、および図7に関して説明されているユースケースは、制限としてではなく、例として考慮されるべきである。
【0129】
なおも図6を参照すると、データベース1A07としてクライアントSOIを確立した後に、情報は、たとえば第2のサーバサイドシステム1A01に伝送され、サーバサイドでのオペレーション503は、クライアントSOIモデルに対応するグローバルSOIモデルをインスタンス化/オープンする。これから明らかになるが、グローバルモデルおよびクライアントモデルは、クライアントシステム1A01のセンサ1E09によってキャプチャされるような実質的に同一の新しいシーンモデル情報を含むように更新されるべきであるが、他の何らかの形で、グローバルモデルおよびクライアントモデルがシーンデータに関して実質的に同一であるという要件はない。好ましくは、オペレーション503は、クライアントUI501と通信しており、グローバルSOIモデルがインスタンス化されるか、または実質的にインスタンス化された後、クライアントUI501がユーザに指示し、ユーザが損傷を受けたユーザの車のボンネットの写真または動画などのシーンデータ(図2Bの2B07参照)のキャプチャを開始することを可能にする。画像などの新しいシーンデータがキャプチャされると、キャプチャされたデータは、好ましくは、画像データ用のビデオコーデックなどの適切な従来のコーデックを使用して圧縮され、伝送される。圧縮された新しいシーンデータは、サーバサイドシステム1A01に伝送され、オペレーション505は圧縮された新しいシーンデータを展開し、次いで、少なくとも一部はそのシーンデータ使用してグローバルSOIモデルを再構築または精緻化し、再構築は、完全に新しいシーンをさらに参照し、精緻化は、既存のシーン(すでに存在していたが、現在更新されている車のプレノプティックシーンモデルのような)をさらに参照する。再構築オペレーション505がグローバルシーンモデルの新しい部分を作成しているときに、サーバサイドシステム1A01オペレーション517は、クライアントサイドシステム1A01に通信されるべきグローバルSOIモデルから次のサブシーンインクリメント(新しい部分の)を提供する。新しいサブシーンインクリメントを受信した後、クライアントサイドのオペレーション507は、クライアントSOIモデルに次のシーンデータ(サブシーンインクリメント)を挿入する。慎重に考察すると分かるように、クライアントサイドシステム1A01は、サーバサイドシステム1A01がシーン再構築のすべてを行っている間にデータをキャプチャしており、シーン再構築は計算集約的であり得、サーバサイドシステム1A01はこの計算集約的なタスクをクライアントサイドシステム1A01から効果的にオフロードする。
【0130】
なおも図6を参照すると、クライアントSOIモデルが、グローバルSOIモデルから提供された(クライアントセンサデータに基づき再構築された)受信サブシーンインクリメントに基づき構築されているときに、クライアントシステム1A01は、要求されたSOIデータオペレーション509を提供し、クライアント要求513を処理することに関係する前の説明にすべて従ってUI501を通じてユーザにシーンモデル情報を提供することができる。また、前に説明したように、クライアントシステム1A01は、好ましくは、オペレーション515を通じてグローバルSOIデータベース1A07によりログに記録することについてオペレーション513aでユーザ指示および使用を追跡する。
【0131】
次に図7を参照すると、図5および図6に基づき構築されているが、クライアントが最初にシーンモデルを作成するか、または既存のシーンモデルを更新し、次いで実シーンのローカルシーンデータをキャプチャしている場合の変更形態の事例に対処するいくつかの例示的な実施形態の流れ図が示されているが、クライアントサイドシステム1A01およびサーバサイドシステム1A01は両方とも、各々、実シーンがサーバサイドシステム1A01上でのみシーンモデルに再構築された図6とは反対に、実シーンを再構築し、シーンインクリメントを提供することができる。図5に関して、オペレーション507、509、511、513(513a、513b、513c、および513dを含む)、515、および517は、実質的に図5で説明されている通りであり、したがって、この図7に関しては最低限度の追加説明がなされる。図6の説明に関して、オペレーション501(501a、501bおよびセンサ1E09、1E11を含む)さらにはオペレーション503は、実質的に図6で説明されている通りであり、したがって、この図7に関しては最低限度の追加説明がなされる。図7の例示的なユースケースは、災害救助現場のシーンモデルを作成(または更新)するためにシーンコーデック1A01を使用するシステムである産業用タブレットなどのモバイルデバイスを使用して作業するユーザである(考えられる限り多くのユーザまたは自律車両(図示せず)が、シーンセンサデータを実質的に同時にキャプチャするためにクライアント1A01として動作している)。図5、図6、および図7の流れ図の各々に、図7に関する災害現場をモデル化することなどの、例示的なユースケース以外の多くのユースケースが適用可能である。たとえば、この図7のユースケースは、工業環境での労働者、または都市環境での通勤者および歩行者などの任意の共有シーンのシーンモデルをキャプチャするユーザにも等しく適用可能である。
【0132】
なおも図7を参照すると、図6と同様に、サーバサイドシステム1A07は、クライアントサイドシステム1A07によってキャプチャされるか、または少なくとも一部はクライアントサイドシステム1A07に基づきキャプチャされているような圧縮済み生データを受信し、次いで、オペレーション505においてグローバルSOIモデルに再構築するか、または既存のグローバルSOIモデルを精緻化する。現在のユースケースは、また、サーバサイドシステム1A07上で、グローバルSOIモデルからの次のサブシーンインクリメントをクライアントサイドシステム1A01のオペレーション507に送るためのオペレーション517を含み、オペレーション507は、次いで、提供されたサブシーンインクリメントを使用して、クライアントSOIモデルを更新し、オペレーション509における要求されたSOIデータをUI501を通じてユーザに提供する。図6のユースケースとは異なり、クライアントサイドシステム1A01は、また、クライアントSOIモデルを再構築するためのオペレーション505、および次いでサーバサイドシステム1A01にサブシーンインクリメントを提供するためのオペレーション517も含み、次いで、サーバサイドシステム1A01は、グローバルSOIモデルを再構築または精緻化するための挿入オペレーション507も備える。クライアントサイドシステムおよびサーバサイドシステムは両方とも、受信され処理されたシーンデータを確認するためのオペレーション511を含む。好ましくは、サーバサイドシステム1A01とクライアントサイドシステム1A01のいずれかで稼動するアプリケーションソフトウェア1A01の指示の下で、好ましくは共有通信で、任意の所与の時間に、任意の1つまたは複数のクライアントサイドシステム1A01によってキャプチャされた、またはそのコマンドの下でキャプチャされた任意の所与の実シーンデータについて、サーバサイドシステム1A01またはクライアントサイドシステム1A01のいずれかまたは両方は、実シーンデータのうちのいずれかを再構築し、次いでまた再構築されたシーンデータをシーンインクリメントとして他のシステム1A01のうちのいずれかと共有するように、または実シーンデータのうちのいずれかを再構築せず、次いでまた他のシステム1A01のうちのいずれかによって再構築されたシーンインクリメントのうちのいずれかを受信して処理するようにそれぞれのアプリケーションソフトウェア1A01によって指令され得ることに留意することが重要である。
【0133】
このようなオペレーションの配置構成の価値は、複数のクライアントサイドシステム1A01、さらには複数のサーバサイドシステム1A01を有するより大きなユースケースにおいてなおいっそう明らかになり、コンピュータネットワークおよびサーバを熟知している者であれば、複数のシステム1A01の間で通信するアプリケーションソフトウェア1A01がシーン再構築および配信負荷分散を実行していることを理解するであろう。クライアントのうちのいくつかは、モバイルデバイス1A01を有するユーザであり、他は自律陸上システム1A01または空中システム1A01であり得る。これらの異なるタイプのクライアント1A01の各々は、異なる計算能力およびデータ伝送能力を有することが予想される。これらの個別のクライアント1A01の各々は、異なる可能性のある実シーンセンサ1E09の範囲、およびプレノプティックシーンデータに対する必要性を有することも予想される。ソフトウェア1A01の負荷分散決定は、少なくとも一部は、全体的に多数の収集されるセンサ1E09データ、シーン再構築に対する優先度、すべてのサーバサイドシステムおよびクライアントサイドシステム1A01全体にわたる計算能力の利用可能性、様々なシステム1A01の間のネットワーク1E01(図1E参照)にわたるデータ伝送能力さらにはシステムの各々によるシーンデータに対する予想されるおよびオンデマンドの要求のうちのいずれか1つまたは任意の組合せを考慮する。図5および図6のユースケースと同様に、図7のユースケースも、好ましくは、多数のクライアントサイドシステム1A01上で指示およびシーンデータ使用をキャプチャし、これらの指示および使用データを、多数のシステム1A01にわたって適切なシーンデータベース1A07のうちのいずれかにログとして記録し、例示的な実施形態の機械学習(または決定論的)コンポーネントは、次いで、すでに前に説明されている他の利点および使用があるがとりわけ、負荷分散を最適化するためにこのログに記録されたシーン使用にアクセスすることができる。また、限定はしないが、受信された生データのタイプおよび量さらにはシーン再構築処理時間の変動などのサーバサイドのシーン再構築メトリックが、クライアントサイド使用とともに追加してログに記録されることも予想され、この追加のサーバーサイドロギングは、負荷分散の必要性を決定または提供するために少なくとも一部は機械学習(または決定論的)コンポーネントによっても使用される。
シーンデータベース
シーンデータベース
【0134】
図8は、平凡な(日常の)シーンに関連付けられている重要な属性を有するキッチンシーン、すなわち、透過性のある媒体(たとえば、ガラスピッチャーおよび窓ガラス)、反射性の高い表面(たとえば、金属製の鍋)、微細構造オブジェクト(たとえば、右手の鉢植えおよび屋外の木)、無特徴表面(たとえば、キャビネットのドアおよび食器洗い機のドア)、ならびに事実上無限の体積範囲(たとえば、窓から見える屋外の空間)を示している。図8のシーンは、システムがシーンコーデック1A01を使用して様々なユースケースで処理するシーンデータベース1A07に収められ得る例示的なシーンである。そのような処理の1つの重要な態様は、シーンのプレノプティックフィールドの要素を格納する働きをするアドレッシング可能なコンテナへの体積に関する、および方向(角度)に関する空間の細分である。
【0135】
図9は、体積および方向に関する空間的コンテナの例示的な表現を示している。ボクセル901は、シーン空間の体積領域を区切るコンテナである。「セイエル」という略称で知られる立体角要素903は、セイエルの頂点を起点とする空間の角度領域を区切る(セイエル903は、その3D形状を伝えるのに役立つように2つの異なる視点から示されている)。セイエル903は有限の範囲のピラミッドとして示されているけれども、セイエルは、その原点から無限に外側へ延在し得る。実施形態において使用されるコンテナは、図9に示されている正確な形状を有していても、有していなくてもよい。たとえば、非立方体ボクセル、または正方形の断面を有しないセイエルは、使用から除外されない。ボクセルおよびセイエルの効率的な階層的配置構成に関するさらなる詳細は、図21～図65を参照して以下に示されている。
【0136】
図10は、上述の図4Bを参照して説明されている実施形態とは異なる例示的な一実施形態における平凡なシーンの例示的なシーンモデル1001の俯瞰平面図を示している。ここで説明されている実施形態は、全体的なコーデックオペレーションに対する図4Bの実施形態のより広い焦点とは反対に、サブシーンの抽出および挿入に関係する態様に的を絞っている。プレノプティックフィールド1003は、外側シーン境界1005によって囲まれている。プレノプティックフィールド1003は、モデル化されたシーンのマターフィールドおよびライトフィールドを表すプレノプティックプリミティブエンティティ(「プレノプティックプリミティブ」、または単に「プリミティブ」)を含む。プレノプティックフィールド1003は、ボクセルの1つまたは複数の一般的に階層的な配置構成によって体積に関するインデックスを付けられ、セイエルの1つまたは複数の一般的に階層的な配置構成によって方向に関するインデックスを付けられる。プレノプティックフィールド内の物質は、1027などの1つまたは複数の媒体要素(「メディエル」)として表され、各々ボクセル内に含まれる。ボクセルは、空であってもよく、その場合、ボクセルは、「void」または「void型」と言われる。外側シーン境界の外にあるボクセルはvoid型である。これらのvoidボクセルは、定義により、プレノプティックプリミティブを含まないけれども、プレノプティックプリミティブ以外のエンティティに関連付けられるように指す(指し示す)可能性がある。プレノプティックフィールド内の光は、1017などの1つまたは複数の放射要素(「ラディエル」)として表現され、各々メディエルに(メディエルを含むボクセルに)配置されているセイエル内に含まれる。
【0137】
メディエルにおけるライトフィールド(無視できるくらい小さい光相互作用のみを表すものを含む)は、4つのコンポーネントライトフィールド、すなわち、入射ライトフィールド、応答ライトフィールド、放射ライトフィールド、および窓ライトフィールドを含む。入射ライトフィールドは、注目しているメディエルに直に隣接するメディエルを含む他のメディエルから運ばれる光を表す。応答ライトフィールドは、入射光との相互作用に応答してメディエルからの出射光を表す。放射ライトフィールドは、入射光との相互作用以外の何らかの物理的プロセス(たとえば、電球など、別のエネルギー形態からの変換)に起因するメディエルから出射する光を表す。窓ライトフィールドは、プレノプティックライトフィールドの外部にある指定されていないプロセスに起因してメディエルに入射する光を表す。これの例は、プレノプティックフィールドが太陽自体を放射源として体積的に表現するのに十分遠くまで延在していないときにプレノプティックフィールドの外側シーン境界のところに注入される、日光を表す、窓ライトフィールドである。いくつかの実施形態において、窓ライトフィールドは、たとえば、一方の層における太陽からの光および別の層における月からの光を表す「窓層」と考えられる複数の窓光サブフィールドからなるものとしてよいことに留意することは重要である。メディエルは、入射ライトフィールドと相互作用するのと同じ仕方で入射窓ライトフィールドと相互作用する。BLIFに関する次の説明において、入射ライトフィールドに関する記述は、窓ライトフィールドに等しく適用される(応答ライトフィールドは、入射ライトフィールドおよび窓ライトフィールドの両方によって決定される)。
【0138】
プレノプティックフィールド1003において、メディエル1027は、すべてのメディエルと同様に、関連付けられているBLIFを有する。BLIFは、典型的には放射測定情報および/またはスペクトル情報および/または偏光情報を含む特性などの、準定常状態のライトフィールドにおける入射ラディエルおよび応答ラディエルの注目する特性の間の関係を表す。特定の例示的な実施形態のコンテキストにおいて、BLIFは、物質と光の相互作用を、分子/原子レベルでのそのような相互作用の計算集約的なモデル化に頼ることなく実用的に表現するので、有用である。非常に一般化度の高いBLIF表現において、注目する特性における応答対入射比は、適切に微細なセイエル粒度でサンプリング形態/表形式で収められ得る。実用的なときには、実施形態は、1つまたは複数の圧縮されたBLIF表現を使用してもよい。そのような表現の1つは、入射光および出射光の方向、スペクトルバンド、および入射光および応答光の偏光状態にわたってパラメータ化された、入射照度の解析関数としての応答輝度をもたらす低次元モデルである。このような低次元モデルの例は、従来の解析的BRDF、たとえばBlinn-PhongおよびTorrance-Sparrowマイクロファセット反射率モデルを含む。BLIF情報のそのような圧縮は、当業者にはよく理解されており、本発明のいくつかの実施形態では、BLIFデータを圧縮および展開するために使用される。一実施形態は、1つまたは複数のBLIFパラメータが体積シーン領域の範囲にわたって変化する、空間的(体積的に)変化するBLIFの表現を可能にし得る。
【0139】
外側シーン境界1005は、プレノプティックフィールド内のメディエルをプレノプティックフィールドの外側にあるvoidボクセルから分離する閉じた区分的に連続する2次元多様体である。voidボクセルは、内側境界1007および1009の内側に置かれる。シーンモデル1001は、外側シーン境界の外側も内側の境界の内側も光輸送を表現しない。voidボクセルに隣接して置かれているメディエルは、「境界メディエル」として知られる。境界メディエルのライトフィールドは、プレノプティックフィールド内の他のメディエルから運ばれる入射ライトフィールドに加えて、プレノプティックフィールドの外部の指定されていない現象によりプレノプティックフィールド内に入射した光を表す窓ライトフィールドを含み得る。シーン内の1つまたは複数の境界ボクセルにおける窓ライトフィールドは、一般的に、境界によって画成される区分的連続多様体上に体積的に配置される4次元ライトフィールドとして考えられ得る。
【0140】
外側シーン境界の一例は、屋外の平凡なシーンにおける空である。シーンモデルのプレノプティックフィールドでは、何らかの妥当な距離(たとえば、視差分解能限界)まで空気のメディエルが存在し、それを超えたところにvoidボクセルが存在する。たとえば、晴れた空または月の光は、外側シーン境界のところの空気メディエルの窓ライトフィールドで表現される。同様に、内側シーン境界の内側の指定されていない現象による光は、内側シーン境界に接するメディエルの窓ライトフィールドで表現される。内側シーン境界の一例は、完全な再構築が行われていない体積領域の境界である。隣接する境界メディエルの4D窓ライトフィールドは、有界void領域に関するすべての(現在)利用可能なライトフィールド情報を含む。これは、その後の再構築オペレーションがマターフィールドのモデルを発見することに成功した場合に変化するものとしてよく、これは新たに発見された(解決された)メディエルから運ばれる入射光として前の窓ライトフィールドを次に説明する前のvoid領域内に置かれる。
【0141】
プレノプティックフィールド1003に加えて、シーンモデル1001は、他のエンティティを含む。メディエル1027および他の付近の非空気メディエルは、シーンコーデック1A01を使用してシステムによって実行される表示、操作、再構築、および他の潜在的なオペレーションにおいて有用な様々なグルーピングで参照される。1つのグルーピングは特徴として知られており、そこではプレノプティックプリミティブは、注目するそれらの特性の何らかのパターンによって一緒にグループ化され、場合によっては空間的姿勢を含む。1029は、形状の特徴であり、特徴の構成メディエルが、それらの空間的配置構成のおかげでグループ化されることを意味する。一実施形態において、シーンコーデック1A01を使用するシステムは、特徴1027を何らかの目的のための突出またはバンプであるとみなすこともあり得る。1021はBLIFの特徴であり、特徴の構成メディエルが、それらの関連付けられているBLIFのパターンに基づきグループ化されることを意味する。シーンコーデック1A01を使用するシステムは、特徴1021をコントラスト境界、色境界、材料間の境界などであるとみなすこともあり得る。
【0142】
プレノプティックセグメントは、特性の何らかの集合における類似性(任意のパターンではなく)によって定義される特徴のサブタイプである。セグメント1023および1025は、この場合、各セグメントのメディエルのBLIFの一様性によって(何らかの許容範囲内で)定義されるマターフィールドセグメントである。1019などのオブジェクトは、自然言語および認知において「オブジェクト」として1人または複数の人間による認識によって定義されるマターフィールドの特徴サブタイプである。例示的なオブジェクトは、キッチンテーブル、ガラス窓、および木を含む。
【0143】
カメラ経路1011は、プレノプティックフィールド1003を観察するカメラによってトレースされる6DOF経路を表す特徴サブタイプである。カメラ経路の潜在的に有用な実施形態の態様は、運動学モデリングおよび球面線形補間(slerp)を含む。カメラ経路1011に沿った配置において、ライトフィールドが記録されるカメラ視点に1013などの焦点面が存在する。焦点面に入射するラディエルの集合は、典型的には画像と称される。例示的な実施形態は、カメラ表現をピクセル(光感知要素)の平面配列を有することに限定しない。ピクセルの他の配置構成も同様に表現可能である。焦点面1013は、オブジェクト1019を出る光を記録する。特徴は、マターフィールド、ライトフィールド、またはこれら2つの組合せにおいて定義することができる。項目1015は、ライトフィールドの例示的な特徴であり、この場合、焦点面1013におけるラディエルを含む。この場合のラディエルのパターンは、特徴を定義する。従来の画像処理の用語では、シーンコーデックを使用するシステムは、1015を画像ピクセル内の2Dパターンとして検出される特徴であるとみなすことが可能である。
【0144】
図11は、上述の図4Cを参照して説明されている実施形態とは異なる実施形態におけるシーンデータベースのブロック図である。ここで説明されている実施形態は、全体的なコーデックオペレーションに対する図4Cの実施形態のより広い焦点とは反対に、サブシーンの抽出および挿入に関係する態様に的を絞っている。シーンデータベース1101は、図示されていないエンティティが他にもあるがとりわけ、1つまたは複数のシーンモデル、BLIFライブラリ、アクティビティログ、およびカメラキャリブレーションを含む。シーンモデル1103は、1105などの1つまたは複数のプレノプティックフィールド、および1107などの特徴の集合を含み、これは潜在的にタイプセグメント(1109など)、オブジェクト(1111など)、およびカメラ経路(1113など)の特徴を含む。それに加えて、1115などの1つまたは複数のシーングラフは、プレノプティックフィールド内のエンティティを指す。シーングラフは、プレノプティックフィールド内に現在顕在化していない解析的エンティティも指し得る。シーングラフは、参照されているエンティティ間の、空間的および他の何らかの、関係を定義するノードの階層に配置構成される。複数のプレノプティックフィールドおよび/またはシーングラフは、典型的には、シーンコーデックを使用するシステムがある適切な時点において共通の時空間参照フレームにそれらを登録することを予想している場合に特定の単一のシーンモデル内に一緒に存在する。この予想がない場合、複数のプレノプティックフィールドおよび/またはシーングラフは、典型的には、別々のシーンモデル内に存在することになる。
【0145】
BLIFライブラリ1119は、BLIFモデル(表現)を保持する。上で説明されているように、シーンデータベースは、BLIFを、分光偏光出射入射比から効率的な低次元パラメトリックモデルまでの様々な形態で収めるものとしてよい。BLIFライブラリ1119は、マターフィールドに存在し得る媒体の光相互作用特性および他の特性を表す材料サブライブラリ1125を含む。材料ライブラリ1125内のエントリの例は、誘電体、金属、木材、石、霧、空気、水、および宇宙空間の近真空を含む。BLIFライブラリ1119は、媒体の粗さ特性を表す粗さサブライブラリ1127も含む。粗さライブラリ1127内のエントリの例は、様々な表面マイクロファセット分布、サンドペーパーのグリットカテゴリ、および体積散乱媒体中の不純物の分布を含む。プレノプティックフィールド内のメディエルは、BLIFライブラリのエントリを参照し得るか、またはどのBLIFライブラリにも含まれない「ローカルで」定義されたBLIFを有し得る。
【0146】
アクティビティログ1121は、感知(撮像を含む)アクティビティのログ1129、処理アクティビティ(エンコード、デコード、および再構築に関係するアクティビティを含む)のログ1131、および他の関連するアクティビティ/事象を保持する。カメラキャリブレーション1123は、シーンモデル上の撮像、表示、または他の分析オペレーションに使用されるカメラのキャリブレーションに関係する補正パラメータおよび他のデータを保持する。
【0147】
図12は、プレノプティックフィールドにあるプリミティブエンティティのタイプの階層のクラス図1200を示している。ルートプレノプティックプリミティブ1201は、メディエル1203およびラディエル1205というサブタイプを有する。メディエル1203は、特定のボクセルに収容されるように解決されたマターフィールド内の媒体を表す。同質メディエル1209は、媒体が何らかの許容範囲内で注目する1つまたは複数の特性におけるそのボクセル全体を通して一様であるメディエルである。同質メディエル1211の例は、適切に一様な固体ガラス、空気、水、および霧を含む。異質メディエル1211は、注目する特性においてそのような一様性を有しないメディエルである。
【0148】
サーフェル1225は、区分的連続2次元多様体によって分離された異なる媒体の2つの異なる領域を有する異質メディエルである。多様体は、法線ベクトルによって表される平均的空間的配向を有し、例示的な一実施形態において、多様体とサーフェルを含むボクセルの体積中心との間の最も近い接近点によって表される空間的オフセットを有する。サーフェル1225のサブタイプは、単純サーフェル1227および分割サーフェル1229を含む。単純サーフェル1227は、そのスーパータイプのサーフェル1225について説明したのと同様である。単純サーフェル1227の例は、壁の表面、ガラス彫刻の表面、および穏やかな水面を含む。分割サーフェル1229については、メディエル内サーフェル境界の一方の側で、メディエルは、それに加えて、別の区分的連続2次元多様体によって分離された2つの部分領域に分割される。分割サーフェル1229の一例は、黒の正方形と白の正方形とが交わるチェスボード表面の領域である。
【0149】
滑らかに変化するメディエル1211は、注目する1つまたは複数の特性がメディエルの体積範囲にわたって滑らかに変化する媒体を表す。空間的に変化するBLIFは、典型的には、滑らかに変化するメディエル1211の体積全体にわたって光相互作用特性の滑らかな変化を表すために採用されることになるであろう。滑らかに変化するメディエル1219の例は、滑らかなカラーグラデーションでペイントされた表面、および地表面の霧の薄い層がその上のより澄んだ空気に取って代わられる領域を含む。
【0150】
ラディエル1205は、特定のセイエルに含まれるように解決されたシーンのライトフィールド内の光を表す。ラディエル1205は、等方性ラディエル1213および異方性ラディエル1215というサブタイプを有する。等方性ラディエル1213は、ラディエルの方向範囲にわたって、放射測定または分光もしくは偏光などの、注目する1つまたは複数の特性が一様である光を表す。異方性ラディエル1215は、注目する特性のそのような一様性のない光を表す。分割ラディエル1221は、区分的連続1次元多様体(曲線)によって分離される異なる光含有量の2つの異なる領域を有する異方性ラディエルである。分割ラディエル1221の一例は、高度にコリメートされた光ビームのエッジを含むラディエルである。滑らかに変化するラディエル1223は、注目する1つまたは複数の特性がラディエルの方向範囲にわたって滑らかに変化する光を表す。滑らかに変化するラディエル1223の一例は、出射角が垂直から離れてシフトするにつれて放射輝度の減少を示すラップトップ画面のピクセルからの光である。
【0151】
図13に示されている画像は、平凡なシーン、すなわち実世界のキッチン、のコンピュータ化モデルのレンダリングである。次の図および説明で使用するために、キッチンシーンの2つの3D点が図13に示されている。点1302は、キッチンのオープンスペース内の典型的な点である(その配置を明確にするために、床への垂直な点線が示されている)。点1304は、大理石カウンターの表面上の1つ点である。
【0152】
本明細書において説明されている例示的な実施形態は、図13に示されているようなシーンを写実的に表現することができる。これは、例示的な実施形態による技術が、シーンのマターフィールドだけでなく、ライトフィールドとそれに加えて2つの間の相互作用もモデル化するからである。空間の体積領域を出入りする光は、空間を表す領域内の指定された点に入射するか、またはそこから出射する1つまたは複数のラディエルによって表される。したがって、ラディエルの集合は、「点」ライトフィールドまたはPLFと呼ばれる。PLFの入射光および出射光は、代表点を中心とする「周囲」立方体上の指定された領域と交差する1つまたは複数のラディエルによって表される。
【0153】
これは、光が、面上に表示される、立方体表面を通過し、中心点に行き来する立方体を表示することによって可視化することができる。このような「光立方体」は、図14の画像中で1401である。これは図13の点1302を中心とする。この光立方体は、点1302に入る入射光を示している。したがって、立方体の表面上の一点または領域に示される光の強度は、立方体の中心である点1302とも交差するその点または領域を通過するキッチン(またはその先)のアイテムおよび光源からの光である。図15は、光立方体1401の6つの追加の外部ビューを示す。光立方体は、立方体の内部からも見ることができる。図16、図17、および図18の画像は、光立方体1401の内部からの様々なビューを示している。
【0154】
光立方体は、ある点、すなわち出射PLFから出てくる光を可視化するためにも使用することができる。このような光立方体は、点1304、すなわち、画像13に示されているようなキッチン内の大理石カウンター上の点に対する、図19に示されている1902である。立方体の表面は、立方体の面または立方体の面上の領域と交差する点から出てくる光を示している。これは、周囲の球体上に配置されるすべての方向からストローを通して一点を見ているようなものとなる。光立方体の下半分の表面は黒色であることに留意されたい。これは、PLFの中心が不透明な材料(この場合は大理石)の表面にあるからである。カウンターの内部の方向の点を出る光はなく、したがってそれらの方向は光立方体の中では黒い。
【0155】
光立方体は、他の現象を可視化するためにも使用できる。図20の画像は、光立方体2001を示している。これは、入射PLFに基づき射出PLFを生成する際のBLIF機能の役割を示している。この場合、入射光は、入射光素子(ラディエル)2002における垂直偏光の単一ビームである。この単一の光ビームから結果として得られる出射光は、光立方体2001の面上に示されている。使用されているBLIFの詳細に基づき、出射光の複雑なパターンは、光立方体2001で示されているように出現する。
【0156】
いくつかの例示的な実施形態は、モデル化されたシーンにおける光の輸送および物質との相互作用を計算するための技術を提供する。空間情報を伴うこれらの計算および他の計算は、空間処理ユニットすなわちSPUで実行される。これは、2つのタイプのデータ構造から構成されるプレノプティック八分木を使用する。第1のものは八分木である。一例は、図21および図22に示されているような体積八分木2101である。8方向分割階層木構造が、有限立方体ユニバース内の空間の立方体領域を表現するために使用される。木構造の最上位に、ユニバース2203を正確に表すレベル0のルートノード2103がある。ルートノードには、レベル1のノード2105などの8つの子ノードを有する。これはボクセル2205、すなわち、ユニバースを正確に満たす8個のサイズが等しい互いに素の立方体のうちの1つを表す。このプロセスは、空間を細分する同じ方法で次のレベルへと続く。たとえば、レベル2のノード2107は、立方体空間2207を表している。プレノプティック八分木の八分木部分は、「体積八分木」またはVLOと称されることになる。
【0157】
プレノプティック八分木で使用される第2のデータ構造は、セイエル木である。セイエルは、「立体角要素」であり、「原点」から投影する方向空間の領域を表すために使用される。これは、典型的には、ラディエル、原点からの出射光またはセイエルによって表される方向から原点に当たる入射光のためのコンテナとして使用される。セイエル木は、典型的には、原点(たとえば、ボクセル)の周りの体積空間の何らかの領域に対する方向空間を表す。
【0158】
セイエルによって表される空間は、立方体の面上の正方形領域によって決定される。この立方体は、「周囲立方体」であり、セイエル木の原点を中心とする。この立方体は、任意のサイズをとることができ、セイエル木を囲むか、制限する。これは、単純に、セイエル木内のセイエルの特定の幾何学的形状を指定し、その各々は原点から無制限の距離まで延在する(が、典型的には、プレノプティック八分木によって表される体積内でのみ使用される)。八分木に似ているが、セイエル木は、ノードがセイエルを表す階層木構造である。
【0159】
セイエル木2301は、図23および図24に例示されている。ルートノード2303はレベル0にあり、その原点、すなわち周囲立方体2403の中心にある点から出てくるすべての方向を表す。セイエルおよびセイエル木は、原点から延在する無制限の容積空間を取り囲むが、これらは、典型的には、通常そのVLOのユニバースであるそのプレノプティック八分木のユニバース内でのみ定義され、使用可能である。図23に見ると分かるように、セイエル木のルートノードは6つの子を持ち、以下の部分木のすべてのノードは4つの子を有する(または子なし)。ノード2305は、ルートの可能な6つの子ノードのうちの1つである(1つだけが示されている)。ノード2305はレベル1にあり、セイエル木の周囲の立方体の面2405と交差する原点から投影するすべての空間を表す。セイエル木の中心がユニバースの中心にあるときに、その定義面はユニバースの面になることに留意されたい。セイエル木が異なる配置にあるときに、その原点はプレノプティック八分木内の別の配置にあり、その周囲立方体は原点を中心として移動する。それはもはやユニバースではない。原点に関するセイエルの方向を決定するだけなので、原点を中心として有する任意のサイズの任意の立方体であり得る。
【0160】
次のレベルの細分では、ノード2307は、ノード2305の4つのレベル2子ノードのうちの1つであり、ユニバースの関連する面の4分の1である面正方形2407を表す。レベル3において、ノード2309は、正方形2407を4つの等しい正方形に分割したもののうちの1つ(面2405の16分の1)である面正方形2409によって定義される方向空間を表す。セイエル木の階層性は、点4101を原点とするセイエル木4100について図41において2Dで以下に例示されている。ノード4102は、セイエル木のレベルnにある非ルートノードである(ルートは6つの子ノードを有する)。これは、方向空間4103のセグメントを表す。次のレベルダウンでは、4つのレベルn+1ノード4104のうち2つのノードは、2つのセイエル4105を表す(他の2つのノードは、他の2つの3Dを表す)。レベルn+2では、ノード4106は2Dにおいて4つの領域4107を表す(3Dでは16個)。プレノプティック八分木で使用されるセイエル木は、SLTと称される。
【0161】
八分木の場合と同様に、部分木内のプロパティがノードに付けられたプロパティによって十分に表現されている場合には、セイエルの細分は終了する(部分木はない)ことに留意されたい。これは、十分なレベルの分解能に達した場合、または他の理由から当てはまる。セイエル木は、八分木と同様に、たくさんの仕方で表現することができる。ノードは、典型的には、一方向リンク(親から子へ)または双方向リンク(親から子へ、子から親へ)で接続される。いくつかの場合において、八分木またはセイエル木の部分木は、同じ木構造内で複数回使用できる(技術的には、この場合には、グラフ構造になる)。したがって、同じ部分木を指す複数の親ノードを有することによって記憶域を節約することができる。
【0162】
図25は、プレノプティック八分木2501内の1つのVLOと3つのSLTの組合せを示している。全体的な構造は、立方体のボクセル2505がレベル1のVLOノードによって表され、ボクセル2502がレベル2のVLOノードによって表されるVLOの構造である。セイエル2507は、VLOユニバースの中心(レベル0)に原点を有するレベル3のセイエルである。しかしながら、セイエル2503は異なる原点を有する。これは、その周囲立方体として使用されるレベル1のVLOノードの中心に配置される。それの定義する正方形は周囲立方体の面の4分の1であるので、それはレベル2のセイエルである。
【0163】
単一のVLOではなく、上で説明されているように、プレノプティック八分木は、同じユニバースを共有し、典型的には集合オペレーションを使用して組み合わされる複数のオブジェクトまたはプロパティを表す複数のVLOから構成され得る。これらは画像内の層のようなものである。このようにして、空間の同じ領域に対してプロパティの複数の集合が定義され、必要に応じて表示され使用され得る。複数のセイエル木内のセイエルは、原点が同じ点であり、ノードが同じアライメントを有している場合に、同じ仕方で組み合わされ得る。これは、たとえば、必要に応じて組み合わせることができる光の複数の波長を維持するために使用され得る。
【0164】
プレノプティック八分木内のSLTおよびVLOは、SLTがプレノプティック八分木内の異なる点に配置された原点を有し、VLOのノード中心に必ずしも位置するとは限らないことを除き、同じ座標系を有し、同じユニバースを有する。したがって、SLTの周囲立方体は、プレノプティック八分木内のVLOまたは複数のVLOと同じ配向になっているが、必ずしもVLOユニバースまたは他のノードと正確に一致するとは限らない。
【0165】
プレノプティック投影エンジンによって計算されるような、プレノプティック八分木における透視プレノプティック投影(または単に「投影」)の使用は、図26に(2Dで)例示されている。プレノプティック八分木2600は、VLOに付けられた3つのSLTを含む。SLT A2601は、点2602に原点を有する。SLT A2601から、1つのセイエル2603が、正のx方向および正のy方向に、プレノプティック八分木を通って投影して示されている。SLT B2604は、プレノプティック八分木内に投影しているセイエル2606を有し、SLT C2607は、別の方向に投影しているセイエル2608を有する。
【0166】
これは、VLOボクセル2710を含む2つのVLOボクセルが示されている図27に続く。SLT A2601のセイエル2603およびSLT B2604のセイエル2606は、出射セイエルである。これは、それらがそれぞれの原点の中心から発せられる光を表していることを意味する。各SLTに対して1つのセイエルのみが示されている。使用時に、典型的には、各SLTの原点から投影する、様々な分解能の多くのセイエルが存在する。この場合、2つのセイエルは2つのVLOノードを通過する。SLT C2607は、2つのVLOノードのいずれかと交差するセイエルを有しておらず、図27には示されていない。
【0167】
動作時に、SLTセイエルとVLOノードとの交差の結果、何らかの分解能限界(たとえば、空間分解能および角度分解能)に達するまで、セイエルおよびVLOノードの細分がなされる。典型的な状況において、セイエルの投影がデータの特性および要求プロセスの即時の必要性によって決定されるあるレベルの分解能でVLOノードのサイズに近似するまで細分が行われる。
【0168】
図28において、ボクセル2710に当たる出射光の一部は、セイエル2603を介して点2602から、またセイエル2606を介してSLT2604の原点からキャプチャされる。光をキャプチャできる仕方は多数あり、アプリケーションに依存する。ボクセル2710に当たるこの光は、入射SLT D2810によって表される。これは、光がボクセル上に当たったときに生成されるか、またはすでに存在する場合には既存のものに追加され得る。この場合の結果は、2つの入射セイエル2811および2806である。これは現在、光がノードの中心に当たることによって表されるように、光がボクセルに当たることを表している。
【0169】
プレノプティック八分木におけるSLTの代表的な使用法は、入射SLTによって表されるような、ボクセルに入る光を使用して、ボクセルから出てくる出射光を計算することである。図29はこれを例示している。ボクセル2710について知られているか、または想定されているBLIF機能は、第2のSLT、すなわち出射SLTを生成するために使用される。これは、出射SLT D2910である。その原点は、セイエルD2810と同じ点にある。したがって、シーン内の複数の配置からの出射光は、入射SLTでキャプチャされたボクセルに当たる光とともに外側に投影され、次いで、そのボクセルに対する出射SLTを計算するために使用されている。
【0170】
いくつかの例示的な実施形態により、プレノプティック八分木の生成および動作におけるSPUの機能は、図30に示されている。SPU3001は、オペレーションモジュール3003、幾何学的形状モジュール3005、形状変換モジュール3007、画像生成モジュール3009、空間フィルタ処理モジュール3011、表面抽出モジュール3013、モルフォロジーオペレーションモジュール3015、接続性モジュール3017、質量プロパティモジュール3019、登録モジュール3021、およびライトフィールドオペレーションモジュール3023の集合などのモジュールの集合を含み得る。八分木上のSPUモジュール3003、3005、3007、3009、3011、3013、3015、3017、3019、および3021のオペレーションは、一般的に知られており、当業者には理解されている。当業者は、そのようなモジュールが、ソフトウェアおよびハードウェアを含む多くの仕方で実装され得ることを理解している。
【0171】
SPU機能のうちいくつかは、プレノプティック八分木およびSLTに適用するように拡張されている。集合オペレーションモジュール3003を、SLTに作用するように修正することは、八分木上のノード集合オペレーションの簡単な拡張である。複数のSLTのノードは、同じセイエル(方向空間の領域)を表さなければならない。次いで、ノードは同じ順序でトラバースされ、SLTに含まれる関連プロパティを操作アルゴリズムに提供する。文献においてよく知られているように、一方のSLT内の終端ノードは、八分木と同様に、「Full-Node Push」(FNP)オペレーションを使用して、他方のSLT内の部分木と照合される。
【0172】
SLTの性質上、SLTに適用されるときに、幾何学的形状3005プロセスのオペレーションは制限される。たとえば、プレノプティック八分木内の1つの点での入射または出射セイエルは、一般に、別の原点で同じにならないという点で翻訳は適用されない。言い換えれば、ある点でのライトフィールドは、通常、別の点のものとは異なり、その点で再計算されなければならない。ライトフィールドオペレーションモジュール3023で実行されるセイエル補間および外挿のライトフィールドオペレーションは、これを遂行する。これが必要とされない例外は、同じ照明が領域全体に適用されるときである(たとえば、視差境界を越えたところからの照明)。そのような場合に、領域内の任意の点で同じSLTが単純に使用され得る。
【0173】
機能3005内の幾何学的スケーリングも、SLTには適用されない。個別のセイエルは、無限に延びる方向を表しており、スケーリングできるサイズを有していない。プロセス3005によって実行される幾何学的回転は、以下で説明されている方法を使用してSLTに適用することができる。
【0174】
膨張および浸食などの3015におけるモルフォロジーオペレーションは、それらの限界を、たとえば、オーバーラップ照明に拡張することによってSLT内のセイエルに適用することができる。これは、SLTの周囲立方体の面上にサイズ過小またはサイズ過大の長方形を使用することによって実施することができる。いくつかの状況において、接続性機能3017は、照明などのプロパティを含むセイエルがそれらと交差することを示すプロパティをVLOノードに追加することによって、SLTの組み込みのために拡張され得る。次いで、これは、投影プロパティ(たとえば、特定の光源によって照明される材料、または空間内の特定の点からは見えない材料)との特定の関係を有する接続されたコンポーネントを識別するために接続性と共に使用され得る。
【0175】
ライトフィールドオペレーションプロセッサ3023のオペレーションは、図31に示されているように特定のオペレーションに分割される。位置不変ライトフィールド生成モジュール3101は、視差境界を越えたところからの光に対するSLTを生成するために使用され、したがって、視差境界が有効である領域内のどこでも使用することができる。光は、(たとえば、画像から)サンプリングされるか、または現実世界(たとえば、太陽もしくは月)のモデリングから、もしくは視差境界を越えるオブジェクトおよび材料のコンピュータ化されたモデルから、合成的に生成されてもよい。
【0176】
出射ライトフィールド生成モジュール3103は、プレノプティック八分木シーンモデル内の特定の点に配置されているSLTの形態の点ライトフィールド情報を生成するために使用される。これは、サンプリングされた照明からのものであるか、または合成的に生成され得る。たとえば、いくつかの場合において、画像内のピクセル値は、表面上の配置まで遡ってもよい。次いで、この照明は、画像のカメラ視点の方向でその配置に付けられている(またはそれらに寄与する)1つまたは複数の出射セイエルとして表面の点に付けられる。
【0177】
出射/入射ライトフィールド処理モジュール3105は、「クエリ」ポイントと呼ばれるシーン内の点(たとえば、オブジェクト上の点)に対する入射SLTを生成するために使用される。それがすでに存在しているのではない場合、点に対してSLTが生成され、そのセイエルは、シーンに投影することによって照明情報を入力される。その方向の第1の物質が見つかると、その出射セイエルは、開始点に投影され戻る照明に関する情報についてアクセスされる。注目している方向にセイエルが存在しない場合、隣接するセイエルにアクセスして、おそらく知られているかまたは予想されるBLIF機能の助けを借りて、照明値の補間または外挿された集合を生成する。このプロセスは、クエリポイントにおける入射SLTに含まれる他のセイエルに対して継続する。したがって、入射SLTは、方向のすべてまたは方向の部分集合からクエリポイントに着地する光の推定をモデル化する(たとえば、表面のクエリポイントを含む不透明オブジェクトの内部からの光は必要でない場合がある)。
【0178】
次いで、入射/出射ライトフィールド処理モジュール3107は、おそらくモジュール3105によって生成された、その点における入射SLTに基づきある点で出射SLTを生成するために使用され得る。出射SLTは、典型的には、入射SLTに適用されるBLIF機能を使用して計算される。ライトフィールドオペレーションモジュール3123に含まれるサブモジュールのオペレーションは、以下に示されているセイエル投影およびセイエル回転方法を採用する。
【0179】
図32は、セイエル木の周囲立方体3210を示している。SLTの周囲立方体の6つの正方形の面には、1から6までの番号が付けられている。座標系の原点は、SLTユニバースの中心に配置されている。面0 3200は、-x軸と交差するSLT面である(図では隠れている)。面1 3201は+x軸と交差する面であり、面2 3202は-y軸と交差する面である(隠されている)。面3 3203は+y軸と交差し、面4 3204は-z軸(隠されている)と交差し、面5 3205は+zと交差する。
【0180】
SLTにおけるレベル0は、SLTの原点(4πのステラジアン)を囲む球体の領域全体を表すセイエルのすべてを含む。SLTのレベル1では、6つのセイエルが6つの面のうちの1つと正確に交差する。レベル2では、各セイエルは面の4分の1を表す。図33は、面5 3205の番号付けを例示している。4分の1面0 3300は-x、-y方向にあり、4分の1面#1 3301は+x、-y方向にあり、4分の1面2 3302は-x、+y方向にあり、4分の1面3 3303は+x、+y方向にある。次に、図33で強調されているように、+x、+y、+z方向にある面3 3303の4分の1面に焦点を当てる。図34は、+z軸から原点を見たときの面5 3205を示している。この視点から、4分の1面3401は、4分の1面の正方形のエッジである垂直線として見られる。
【0181】
レベル2の4分の1面と交差するセイエルは頂部セイエルと呼ばれる。面毎に6つの面と、4つの4分の1面があるので、合計24個の頂部セイエルがある。3Dでは、頂部セイエルはSLTの原点と交差する4つの平面によって囲まれている空間であり、その各々はレベル2の4分の1面のエッジと交差する。2Dでは、これは3401などの4分の1面の中心および両端と交差する2本の光線に減らされる。頂部セイエルの例は、原点3501を有する図35の3502である。
【0182】
セイエルは、たとえば、光投影を表すために使用することができる空間の領域である。これらは、体積空間を囲む平面によって決定される。技術的には、これらは、無制限の高さの斜め(または非右)の長方形ピラミッドである。2Dでは、平面は光線として現れる。たとえば、光線3601は、図36に示されている。これは、SLT原点3602を起点とする。特定の光線は、原点、およびセイエルの周囲立方体の1つの面(この場合はx軸に垂直)に平行な平面(2Dにおける線)である投影平面3603との交点によって定義される。投影平面は、典型的には、VLO内のノードに付けられており、セイエルがそのノードと交差するかどうかを決定するために使用され、適切であるときに、照明計算を実行するために使用される。交点3604、t(tx,ty)は、投影平面3603の原点3605、通常はそれが付けられているVLOの中心、および投影平面の原点3605から、3606、tyである交点3604までの距離によって決定される。光線3601とセイエル面3607との交点3608は、点「a」3608である。示されている場合において、原点からx方向の面までの距離は1であるので、x-y平面内の光線の傾きは、したがって、点3608のy値、ayとなる。
【0183】
SLTはユニバースの特定の点、つまり原点に固定される。アンカー点は、明示的に定義された点であり、関連する投影情報がその点についてカスタム計算される。または、ここで説明されているように、SLT原点はユニバースの中心から始まり、VLO PUSHオペレーションを使用して、投影面(同様の仕方であちこち移動する)との幾何学的な関係を維持しながら、アンカー点まで移動することができる。これは、複数のSLTがVLOノードに付けられ、SLT中心を特定するために八分木がトラバースされるときに簡略化された投影計算を共有することも可能であるいう利点を有する。SLT中心を特定するVLO八分木は、1つの統合されたデータセットであるプレノプティック八分木内の物質を表すノードも含む。
【0184】
プレノプティック八分木投影を実装するときに、個別の24個の頂部セイエルは別個のプロセッサで独立して処理され得る。VLOのメモリアクセス帯域幅を削減するために、各そのようなプロセッサは半空間生成器の集合を有することができる。これらは、ローカルで(各頂部セイエルプロセッサに対して)VLOと交差するセイエルのピラミッドを構築するために使用される。したがって、VLOメモリへの不必要な要求は排除される。
【0185】
最下位レベルのVLOノードの中心は、SLT原点として使用することができる。または、より高い精度が必要な場合には、幾何学的計算のために計算された投影補正を用いてノード中心に関するオフセットを指定され得る。
【0186】
次に、SLTは、STLの原点を位置決めするためにVLOをトラバースする(オフセット補正の有無にかかわらず)ことによってプレノプティック八分木内に位置決めされる。ユニバースの中心に付けられた投影面に関するSTLの投影情報は、VLOのルートノードに対してセットアップされ、次いで、SLT原点の配置までPUSH毎に更新される。図37において、SLTの中心(図示せず)は、VLOルートノード(レベル1のVLOノード3701のみが示されている)の中心である点3702に置かれている。SLTを移動するために、中心3702は、VLOノードのPUSHで移動される。示されている場合において、これは+x方向および+y方向のVLO子ノードへの移動である。したがって、これは、+x方向および+y方向のレベル1ノード中心3703に移動する(この頂部セイエルに対して)。元の光線3704(セイエルのいずれかのエッジを表す)は、したがって、PUSHの後に3705となる。この新しい光線の傾きは、元の光線3704の傾きと同じままであるが、投影面3706との交点は移動する。投影面3707の原点に関する、元の交点3708、t(tx,ty)は、3709、t'(t'x,t'y)に移動する。したがって、投影面のx座標はtxのままであるが、tyの値はt'yに変化する。
【0187】
yのステップは、新しい原点へのステップと光線の傾きとを考慮して計算される。レベル1のVLOノードのエッジは、3701についてex3710によって示されるように1である。エッジの大きさは軸のすべての方向で同一であるが、トラバース中に方向が異なるので、それらは別々の値として維持される。y値はey3711である。VLO PUSHが発生すると、新しいエッジ値e'x3712およびe'y3713は元の値の半分になる。このPUSHオペレーションについて図に示されているように、次のとおりである。
e'x=ex/2および
e'y=ey/2
e'x=ex/2および
e'y=ey/2
【0188】
新しい交点3709がy方向に移動するが、これはe'y3713による原点のy値の移動に、エッジの傾きを掛けた、SLT原点のx値、3712e'xの移動を加えたことによる。
t'y=ty+e'y-slope*e'x
t'y=ty+e'y-slope*e'x
【0189】
この計算は、様々な仕方で行うことができる。たとえば、毎回積を実行するのではなく、VLOユニバースの傾きとエッジの積がシフトレジスタ内に保持しておき、各VLO PUSHについて、右シフトオペレーションを用いて2で除算することができる。これは、投影面上にセイエルの投影を維持したまま、VLOに対するPUSHオペレーションによってSLTの中心が移動され得ることを示している。
【0190】
次のオペレーションは、SLTとの幾何学的関係を維持しながら投影面を移動させる。投影面は、典型的には、一般にVLOの異なるレベルにある異なるVLOノードの中心に付けられる。投影面が付けられているノードが細分されるときに、投影面およびその原点は、ユニバース内を移動する。これは、図38に示されている。投影面3802は、レベル1のVLOノード3801へのPUSHが行われたときに、VLOルートノードの中心に付けられる。投影面3802は、新たな配置に移動して、投影面3803となる。投影面原点は、ユニバースの中心3804から子ノードの中心である点3805に移動する。元のセイエルエッジ光線交点3806、t(tx,ty)は、新しい投影面3803上の新しい交点3807、t'(t'x,t'y)に移動する。上記のように、ノード3801のxエッジ、3810exは、PUSHで2分割され3812e'xとなる。yエッジ3811eyも、2分割されて3813e'yとなる。これは次のように計算される。
e'x=ex/2および
e'y=ey/2
e'x=ex/2および
e'y=ey/2
【0191】
新しい原点に関する、交点のy成分は次のようになる。
t'y=ty-e'y+slope*e'x
t'y=ty-e'y+slope*e'x
【0192】
e'yの減算が行われるのは、投影面の原点が3804から3805に+方向に移動したからである。そして、ここでもまた、傾きを乗算されたエッジは、シフトレジスタ内にあり、各PUSHについて右シフトで2分割され得る。実際の投影方法の詳細に応じて、同じ木構造内の2つの経路(SLT原点および投影面)が別々にPUSHとPOPを行うことができる場合に傾き値は別々に計算される必要がある。たとえば、SLT配置八分木構造は、VLOトラバースが始まる前に最下位レベルまでトラバースされ、次いで、いくつかのレジスタを再利用するものとしてよい。
【0193】
「スパン」は、(1次元での)セイエルの限界を定義する2つの光線の間の投影面内の線分である。これは、セイエル3902をホストするレベル1ノード3901について図39に示されている。これは、SLTの原点、3903、「頂部」エッジ3904、および「底部」エッジ3905の3点によって定義される。エッジは、点3907に原点を有する投影面3906と交差する場所によって定義される。交点は、頂部エッジについては点t3909であり、底部エッジについては点b3910である。
【0194】
セイエルは、底部エッジと頂部エッジの間で、SLT原点から外へのみ定義される。原点の他方の側では定義されない。処理中に、この状況は、4003に原点を置くセイエル4002を含むレベル1のVLOノード4001に対して図40に示されているようなセイエルについて検出され得る。投影面4004は、SLT原点の他方の側に移動し、セイエルが存在しない4005となる。byオフセット値はb'y4006となり、tyオフセット値は4007t'yとなる。移動後、頂部オフセット値は、底部オフセット値より低くなり、セイエルが定義されていないことを示す。これは、もはや、投影面上に投影しないが、幾何学的関係が計算され維持されている間は、原点の他方の側に戻るまで、VLOノードとの交点オペレーションに対する使用はサスペンドされる必要がある。
【0195】
セイエルは、新しい頂部および底部のオフセットを計算することによってセイエルPUSHオペレーションを使用して4つのサブセイエルに細分される。セイエル細分プロセスは、上で説明されているように図41に例示されている。図42は、原点4203、頂部点t、4204、および底部点b、4205によって定義されるセイエルをホストするレベル1のVLOノード4201を示している。セイエルがPUSHしている子に応じて(通常、PUSH時に実行される幾何学的計算に基づく)、新しいサブセイエルは、上側サブセイエルまたは下側サブセイエルであり得る。上側サブセイエルは、原点4203、頂部点4204、頂部点4204と底部点4205との間の中心である点4206によって定義される。示されている場合において、下側サブセイエルは、原点4203、元の底部点b4205、および新しい頂部点t'4206によって定義されるPUSHの結果である。新しい頂部点tの値t'は、次のように計算される。
t'y=(ty+by)/2
t'y=(ty+by)/2
【0196】
新しい底部エッジは元のエッジと同じであり、同じ傾きを有する。t'で定義された頂部エッジは、新しい傾き、slope_t'を有し、これは次のように計算できる。
slope_t'=(slope_t+slope_b)/2
slope_t'=(slope_t+slope_b)/2
【0197】
特定のレベルのすべてのセイエルは同じ面の面積を有しているが、原点が面の面積に関して移動するので同じ立体角の面積を表さない。これは、あるレベルの各セイエルについて面上の長方形のエッジを移動することによって補正され得る。これにより照明の計算が単純化されるが、幾何学的計算はより複雑になる。好ましい方法では、SLT「テンプレート」が使用される。これは、SLTと同時にトラバースされる静的な事前に計算された「影」SLTである。光投影については、照明伝達計算で使用する各セイエルに対する立体領域の正確な測定値を含む。
【0198】
セイエルは、空間内の点、SLTの中心(典型的には、点によって表される空間)への入射またはそこから出る出射照明を表す。プレノプティック八分木は、多くの仕方で光輸送において採用することができるが、好ましい方法は、最初に、VLOの中心にあるSLTの原点で幾何学的変数を初期化することである。次いで、幾何学的関係は、SLTがユニバース内のその配置に移動されるときに維持される。次いで、VLOは、ルートから開始し、SLTの原点から前後(FTB)の順序で、トラバースされ、セイエルの、原点からの方向に進む。このようにして、何らかの形で典型的には物質を含む、VLOノードは、セイエル原点からの距離の一般的な順序で遭遇し、それに応じて処理される。一般に、これは、異なる方向グループ内のセイエル(頂部セイエル)の集合を考慮するために複数回実行される必要があり得る。
【0199】
VLOが、SLT原点から投影するセイエルに対応するFTB順序でトラバースされるときに、遭遇した第1の(光と)相互作用するVLOマターノードは、次いで、必要とされる次のステップを決定するために調査される。たとえば、セイエルからの照明は、セイエルからの照明の一部または全部を除去し、それまたはそれの一部を物質を含むVLOノードに付けられているセイエルに付けることによって、VLOノードに伝達されることが決定され得る。これは、典型的には、VLOノードに付けられた入射SLTである。伝達は、ライトフィールドをサンプリングする画像から生成される可能性のあるプロパティからであり得る。または、照明源に付けられた出射セイエルからであってもよい。入射照明は、表面の光相互作用特性のモデルとともに使用されて、たとえば、既存のまたは新規作成されたセイエルに付けられる出射光を決定し得る。
【0200】
図43に示されているように、VLOノード4301に付けられている出射セイエルからVLOノード4302に付けられている入射セイエルへのセイエル間の伝達が行われる。伝達は、その原点を4304とする出射セイエル4303の投影がVLOノード4302に関して適切なサイズであり、典型的には、その中心を囲むときに開始される。そうでなければ、出射セイエルまたは入射SLTを含むVLOノード(またはその両方)は細分され、結果として生じる部分木について状況が再調査される。
【0201】
伝達が行われる場合、入射セイエル木4305内の、原点-原点セグメント4307に沿った対蹠セイエルは、次いで、何らかのセイエル分解能でアクセスされるか、または生成される。VLOノードが大きすぎる場合、必要に応じて細分され、投影の相対的サイズを増加させる。入ってくるセイエルが大きすぎる場合、典型的には投影のサイズを小さくするように細分される。
【0202】
特定のトラバースシーケンスは、VLOノード訪問のFTB順序付けを達成するために使用される。これは、VLOノード4401のトラバースについて図44に示されている。セイエルは4403にある原点を有し、エッジ(頂部および底部)は4分の1円(3次元では8番目の球体)領域4404(底部エッジ限界4405と頂部エッジ限界4406との間)と交差する。エッジ4407は、この範囲内の典型的なエッジである。シーケンス0から3 4408は、VLOノード4401においてFTBシーケンスを生成する。他のシーケンスは、他の範囲に対して使用される。3Dでは、8つの子ノードの等価なトラバースシーケンスがある。VLOにより、トラバースは再帰的に適用される。トラバースシーケンス順序付けは、複数のシーケンスが領域に対してFTBトラバースを生成することができるという点で一意的でない。
【0203】
セイエルが細分されるときに、いくつかのアルゴリズムでは、遭遇する物質含有VLOノードによって消費された(たとえば、吸収または反射された)光を含むセイエルを追跡する必要がある。八分木画像生成の場合と同様に、四分木が「使用済み」のセイエルをマークするために使用される。これは、図45に例示されており、4503に原点を有するセイエル4502はVLOノード4501上に投影されている。四分木4504(エッジが示されているだけ)は、アクティブでないか、または以前に部分的にまたは完全に使用されているセイエル木内のセイエルを追跡するために使用される。
【0204】
複数のプロセッサが、異なるセイエル上で同時に動作することも可能である。たとえば、24個のプロセッサが各々異なる頂部セイエルおよびその子孫の投影を計算することが可能である。これは、プレノプティック八分木、特にVLOを保持するメモリに大きな帯域幅を要求する可能性がある。SLT中心木は、典型的には、各プロセッサに対して合成的に生成されるものとしてよく、頂部セイエルおよびその子孫は別個のメモリセグメントに分割され得るが、VLOメモリは複数のセイエル処理ユニットからアクセスされることになる。
【0205】
上で指摘されているように、メモリ帯域幅要件は、各ユニットに対する半空間生成器の集合を使用して低減されることも可能である。2Dにおける図46に示されているように、半空間八分木は、セイエルの辺を定義する2つのエッジ(3Dでは4つの平面)に対してローカルで(各プロセッサ内で)生成されることになる。エッジ4602は、頂部セイエルエッジである。その下の領域は半空間4603である。エッジ4604は、上側半空間4605を定義する底部エッジである。セイエルの空間は、2Dでは、2つの半空間4606の交点である。3Dでは、セイエルの体積は、4つの体積占有半空間の交点である。
【0206】
次いで、ローカルセイエル形状八分木は、VLOと交差するであろうマスクとして使用されることになる。ローカル生成八分木内のノードが空であった場合、メモリ内のVLO八分木はアクセスされる必要はない。図47では、これは、上位レベルVLOノード4701がその部分木内の複数の下位レベルのノードを含むことによって例示されている。ノードA、4703は、セイエル4702と完全に素であり、アクセスされる必要はない。セイエル4702は、ノードB、4704の空間の一部を占有する。VLOメモリは、アクセスされる必要があるだろうが、0、2、3などのその子ノードはいずれも、セイエルと素であり、したがって、メモリアクセスは必要ない。ノードC4705は完全にセイエルによって囲まれているので、それとその子孫ノードは処理のために必要である。それらは、必要に応じてVLOメモリからアクセスする必要がある。メモリアクセスの問題は、8つのレベル1八分木ノードに対応する8つのセグメントでVLOメモリをインターリーブすることによって、また他の仕方で低減され得る。
【0207】
「フロンティア」は、ここでは、等しい距離かまたはそれ以上の距離にあるものがその領域内のどの点でも視差を示さないようなプレノプティック八分木内のある領域からの距離にある表面として定義される。したがって、特定の方向から来る光は、そのプレノプティック八分木領域内の配置に関係なく変化しない。フロンティアを越えて来た光については、プレノプティック八分木全体に対する単一SLTが使用され得る。オペレーションにおいて、指定された点について、入射SLTは、外向き投影からの点について蓄積される。そのようなすべての照明が決定されたときに(フロンティア内からのすべての照明)、そのような照明がどれも見つからないセイエルについては、フロンティアSLTからのセイエルはそのプロパティを決定するために使用される。プレノプティック八分木を越えているがフロンティア内にある照明は、たとえば、プレノプティック八分木の面上のSLTによって表現され得る(単一のSLTではない)。
【0208】
BLIFなどの表面プロパティを使用する計算などの多くのオペレーションでは、SLTを回転させることが重要な場合がある。これは、2Dにおける図48に例示されており、同様の方式で3Dに拡張することができる。4801は、セイエル4804を含む元のVLOノードである。ノード4802は、それから生成される、4804の回転バージョンであるセイエル4805を含む回転VLOノードである。2つのSLTは、VLO中心点4803である同じ原点を共有する。アルゴリズムは、元のセイエルおよびサブセイエルから、新しい、回転されたセイエルおよびサブセイエルを生成する。これは、元のすべてのセイエルに対して行われ得るか、またはたとえば、プレノプティックマスク、もしくはここで使用されているように単に「マスク」は、典型的には何らかの理由で必要とされないことから新しいSLTにおいていくつかのセイエルの生成をブロックするために使用され得る(たとえば、表面点から、不透明な立体への方向、いくつかの方向が出射光にほとんどまたは全く寄与しない鏡面に対してBLIFなどの必要とされない方向)。マスクは、注目するプロパティ値を指定してもよい(たとえば、何らかの指定された閾値以下の放射輝度値を有するセイエルを無視する)。図に示されているように、新しいSLT周囲立方体の面(2Dのエッジ)は、4806などの投影面(2Dの線)となる。新しいSLT内のスパンは、元のSLTセイエルの投影である。
【0209】
図49は、新しいセイエルの頂部エッジと回転した投影面4902との交点である、点t(tx,ty)4901を示している。同様に、点b(bx,by)4903は、底部エッジの交点である。これらは、新しいSLTのセイエルにおけるエッジ/面スパンの端点に対応する。これらは、SLT八分木ユニバースの端または隅から始まる。次いで、これらは必要に応じて細分される。示されているように、中心点4904は現在、新しい頂部点t'になり、次のとおりである。
t'x=(tx+bx)/2および
t'y=(ty+by)/2
t'x=(tx+bx)/2および
t'y=(ty+by)/2
【0210】
頂部点と底部点の間のxの距離はdx4905で、PUSH毎に2分割される。yの変化はdy4906で、PUSH毎に2分割される。各細分に対する差はエッジの傾きの関数となり、これもPUSH毎に2分割される。このタスクは、細分化されるとともに新しいセイエル上に投影される元のSLT内にあるセイエルを追跡するタスクである。底部レベル(方向空間内の最高の分解能)では、処理中に必要とされるノードについて、元のセイエルのプロパティ値は新しいセイエルの値を計算するために使用される。これは、最大の投影を有するセイエルから値を選択するか、または何らかの加重平均もしくは計算値を選択することによって行うことができる。
【0211】
図50は、スパン情報がどのように維持されるかを示している。元のセイエルは、頂部エッジ5005および底部エッジ(図示せず)を境界としている。点tからtoriginalまでの距離、yは、開始時に計算され、その後、細分化が続くとともに維持される。これは、図ではdt5010である。また、点bから点boriginal(図示せず)までの同等の距離、yもある。この計算の目的は、新しい点t、つまり点bから関連する元のエッジまでの距離を計算することである。これは、図の中の新しい頂部点t'5004である。同等の方法を使用して、点b'に対する底部距離の生成を取り扱うことができる。
【0212】
この計算は、元のセイエルのエッジおよび投影エッジの傾き(3Dの平面)の2つの傾きを扱う。いずれの場合も、xのステップに対するyの距離変化量、dx/2、この場合は5014は、傾きによって決定され、各PUSHで2分割される値である。これらの2つの値は、シフトレジスタに保持され得る。これらの値は、開始時に初期化され、次いで、PUSHおよびPOPオペレーションにおいてに必要に応じてシフトされる。
【0213】
図に示されているように、新しいオフセット距離dt'5004は、最初に、dx/2のステップ5014に対する投影エッジに沿った移動、またはこの場合には「a」5009の値を決定することによって計算され得る。次いで、これは、新しい頂部点t'から、元の頂部エッジとの元の垂直交点までの距離を決定するために使用できる。これは、図中の「e」5011の値であり、a-dtに等しい。他の部分は、元のセイエルの頂部エッジ上の元の交点から、頂部エッジ上の新しい交点までの、yにおける距離である。この距離は、エッジの傾き×dx/2、すなわち図中で「c」5007である。新しい距離、dt'5006は、このようにして、和e+cとなる。
【0214】
これを3Dに拡張するときに、新しい次元における傾き情報は、2D SLT回転の直截的な拡張であるz方向のステップに対する追加値を計算するために使用する必要がある。
【0215】
SLTは、上位ノードが子孫ノードよりも大きい体積の空間に対する方向を表すという点で階層構造である。親ノードのSLT中心は、この体積中にあるが、一般に、その子ノードのうちのいずれかの中心と一致することはない。SLTがたとえば画像から生成される場合、画像に対して四分木が生成され得る。次いで、これは、複数のレベルの分解能でノード中心においてSLT上に投影され得る。
【0216】
他の場合には、上位レベルは下位レベルから導出される。SLT縮小は、低レベルのセイエルに含まれる情報から上位のセイエルに対する値を生成するために使用されるプロセスである。これは、平均値、最小値、および最大値を生成することが可能である。それに加えて、被覆の尺度(たとえば、値を有するサブセイエル内の方向空間のパーセンテージ)が計算され、場合によっては蓄積され得る。いくつかの実装形態において、1つまたは複数の「特性ベクトル」が使用され得る。それらは、セイエルの何らかのプロパティがある意味で空間的にバランスが取れている方向である。
【0217】
SLTがローカルで平面状の表面上にあるか、またはその近くにあると仮定されることが多い。もし知られていれば、ローカル表面法線ベクトルは、全体として、SLTについて表現することができ、縮小プロセスにおける値を改善するために使用することができる。
【0218】
いくつかの状況において、特に照明勾配が大きい場合には、改善された縮小プロセスは、低レベルのセイエルを平面(たとえば、SLT空間を通って表面の知られている平面に平行)または表面に投影し、表面上で結果をフィルタ処理し(たとえば、より大きい親セイエルの中心について補間する)、次いで新しい値をSLTに投影して戻すことであろう。機械学習(ML)は、以前の訓練セットに基づき照明を分析し、縮小プロセスを改善するために採用され得る。
【0219】
光と相互作用する物質を含む体積領域を表す空間内の点の出射SLTは、ライトフィールドサンプル(たとえば、画像)から組み立てられ得る。様々な方向の照明を決定するのに十分な情報がある場合、表現された材料に対するBLIFを推定(または「発見」)することが可能であり得る。これは、入射SLTが推定できる場合に円滑にされ得る。BLIF発見に、MLが使用され得る。たとえば、2次元配列(2つの角度)のSLTに対するセイエル照明値を含む「画像」が積み重ねられ(複数のSLTから)、BLIFを認識するために使用することが可能である。
【0220】
SLT補間は、SLTの他のセイエルの何らかの集合における値に基づき未知のセイエルに対する値を決定するプロセスである。これが行える様々な方法がある。BLIFが知られているか、推定できるか、または発見できる場合、これは、他のセイエルから未知のセイエル値をインテリジェントに推定するために使用できる。
【0221】
光源は、しばしば、実または合成照明を表すために使用することができる。理想的な点光源は、典型的には、おそらく全方向に一様な照明を有する、単一のSLTによって表現することができる。封入された点光源または指向性光源は、ブロックされた方向の照明を防ぐためにマスクSLTを使用して表現することができる。平行光源は、八分木を生成するための「照明」の幾何学的押し出しを使用して表現することができる。押し出しは、たとえば、非一様な照明(たとえば、画像)の直交投影を表すことも可能である。
【0222】
可能なプレノプティック八分木投影プロセッサが図51に示されている。これは、プレノプティック八分木内のVLOノードへのSLTの投影を実装する。3つのPUSHオペレーション、すなわち、PUSH Center(SLTの中心を子ノードにPUSH)、PUSH VLO(VLOノードを子ノードにPUSH)、PUSH Sael(親セイエルを子にPUSH)を実行することができる。POPオペレーションは、ここでは明示的には含まれていない。各オペレーションの開始時にレジスタのすべてがスタックにPUSHされ、単にPOPして出すことが想定されている。代替的に、特定のPUSHオペレーション(値ではない)のみがスタックに収められ、PUSH計算を反転させることによってPOPを実行し元に戻すことができる。
【0223】
プロセッサは、x=1で面に向かって投影される「頂部」セイエルに使用される。このユニットは、x-y平面内で投影計算を実行する。複製ユニットが、y-z平面でコンピュータ計算を行う。
【0224】
オペレーションを簡単にするために、すべてのSLT中心PUSHオペレーションが最初に実行され、それによりSLTをその配置に置く(投影幾何学的形状を維持しながら)。2つのデルタレジスタが再初期化され、次いで、VLO PUSHオペレーションが実行される。次いで、SLT PUSHオペレーションが実行される。これらのオペレーションは、たとえば、デルタレジスタを複製することによって同時に実行することができる。
【0225】
上側レジスタ5101は、投影面上の投影セイエルの上側面のy配置(この場合、面1に平行)を維持する。下側レジスタ5102は、下側平面のy配置を維持する。デルタシフトレジスタは、傾き値、すなわち、上側面に対するDelta_U5103および下側面に対するDelta_L5104を保持する。これらは、可能な最低レベルまでPUSHした後にPOPオペレーションが実行されるときに精度を維持するのに十分な数の「lev」(レベルを意味する)ビットを右に有する。デルタレジスタは、x-y平面内で関連する平面の傾きで初期化される。これは、1のxにおけるステップに対するyの変化を含む。PUSH毎に(SLT中心またはVLO)、1だけ右にシフトされる。したがって、これはx方向の子ノードへのステップに対するyの変化量となる。
【0226】
エッジシフトレジスタは、VLOノードのエッジの距離を維持する。これらは、VLOトラバース中のノードのエッジに対するVLO_Edge5105である。SLT_Edge5106は、プレノプティック八分木内のセイエルを特定するためのトラバース中のVLOノードに対するものである。この2つは、典型的には、VLO内で異なるレベルにある。エッジレジスタは、また、精度を維持するために「lev」ビットを右に有する。他の要素は、選択器(5107および5108)と、5個の加算器(5110、5111、5112、5113、5114)である。選択器および加算器は、以下の規則に従って信号AからDによって制御される。結果は、VLO細分信号5109である。
【0227】
SLT投影ユニットのオペレーションは、様々な仕方で実装され得る。たとえば、特定の実装形態におけるクロック速度が十分に低い場合、プロセッサのインスタンスは、単一のクロックサイクルで複数のレベル移動を実行することができるPUSHオペレーションのカスケードを形成するように直列構成で複製され得る。
【0228】
VLOおよびSLTのPUSHオペレーションが同時に実行できるような代替的設計が図52に示されている。2つの新しいデルタレジスタ、V_Delta_U5214(VLOデルタ、上側に対する)とVLOデルタに対するV_Delta_L5215が追加されている。図51におけるデルタレジスタは、SLTプッシュオペレーションにのみ現在は使用される。これは、現在は、S_Delta_U5203およびS_Delta_L5204である。
【0229】
図51におけるプロセッサの起動状況が図56に示されている。頂部セイエル5602は、ユニバース5603の原点(0,0)にある。面1に平行な、投影面は、同じ点と交差し、その原点は同じ点にある。象限子番号付け5610およびサブセイエル番号付け5611に留意されたい。
【0230】
レジスタは次のように初期化されてる。
Upper=Lower=0(上側エッジおよび下側エッジの両方が原点で投影面と交差する。)
Delta_U=1(上側エッジ傾き=1)
Delta_L=0(下側エッジ傾き=0)
VLO_edge=SLT_edge=1(両方ともレベル1ノードのエッジ距離の開始)
Upper=Lower=0(上側エッジおよび下側エッジの両方が原点で投影面と交差する。)
Delta_U=1(上側エッジ傾き=1)
Delta_L=0(下側エッジ傾き=0)
VLO_edge=SLT_edge=1(両方ともレベル1ノードのエッジ距離の開始)
【0231】
投影ユニットは次のように働く。
SLT Center PUSH
・SLT_edgeおよびDelta_Uを右に1ビットだけシフトする
・SLT子0または2について:Aは+、そうでなければ-
・SLT子0または1について:Cは-、そうでなければ+
・Bは0である
・Dは1である
・Eはno-loadである(Delta_UおよびDelta_Lレジスタは変化しない)
VLO Node PUSH
・VLO_EdgeおよびDelta_Uを右に1ビットだけシフトする
・VLO子0または2について:Aは-、そうでなければ+
・VLO子0または1について:Bは+、そうでなければ-
・Cは0である
・Dは1である
・Eはno-loadである
SLT Sael PUSH
・新しいセイエルは上側である:Dは1、そうでなければ0
・Eはloadである
SLT Center PUSH
・SLT_edgeおよびDelta_Uを右に1ビットだけシフトする
・SLT子0または2について:Aは+、そうでなければ-
・SLT子0または1について:Cは-、そうでなければ+
・Bは0である
・Dは1である
・Eはno-loadである(Delta_UおよびDelta_Lレジスタは変化しない)
VLO Node PUSH
・VLO_EdgeおよびDelta_Uを右に1ビットだけシフトする
・VLO子0または2について:Aは-、そうでなければ+
・VLO子0または1について:Bは+、そうでなければ-
・Cは0である
・Dは1である
・Eはno-loadである
SLT Sael PUSH
・新しいセイエルは上側である:Dは1、そうでなければ0
・Eはloadである
【0232】
SLTの中心を、プレノプティックノードの中心以外の点に配置することが望ましい場合がある。これは、たとえば、ノードによって表される空間内のローカル立方体体積の中心ではなく、何らかの基礎構造の特定の点に代表点を配置するために使用され得る。または、点光源に対する特定の配置をとすることも可能である。
【0233】
これは、投影プロセッサの初期化にSLT配置を組み込むことによって行うことができる。これは、上側の傾きが1から始まり、下側の傾きが0から始まるので、簡素化される。したがって、初期頂部投影面交点はyにあるが、セイエル中心のy値からx値を引いた値になる。底部値はセイエル中心のy値となる。
【0234】
次いで、投影の計算は前と同じように進む。SLTのノード中心への最終PUSHでオフセットのシフト値を追加することは可能であるが、これは一般的には望ましくなく、SLT中心PUSHとVLO PUSHが同時に行われるときに少なくともそうではない。スパン値は、訪問する次のSVO子を選択するために使用されるので、VLOトラバース時に正しいスパンが必要になる。
【0235】
3つのタイプの多数のPUSHに対するレジスタ値は、図53および図54におけるExcelスプレッドシートに含まれている。行5の2つのオフセット値は、計算を簡単にするために0に設定されている。使用されるExcel式は、図55に示されている(読みやすくなるように行と列を反転させている)。オフセット値は、行5に配置されている(xに対してはF5、yに対してはH5)。
【0236】
スプレッドシートの値は、幾何学的図を用いてわかりやすくなるように浮動小数点形式である。実際のプロセッサでは、レジスタは整数演算のみを使用して整数にスケーリングされ得る。スプレッドシートの列は次の通りである。
A.反復(逐次的回数のPUSHオペレーション)
B.SLT PUSH(SLT中心子ノードにPUSHされる)
C.VLO PUSH(VLO中心子ノードにプッシュされる)
D.Sael PUSH(セイエル子にプッシュされる)
E.SLT To Lev(PUSH後のSLT配置の新しいレベル)
F.VLO To Lev(PUSH後のVLOノードの新しいレベル)
G.Sael To Lev(PUSH後のセイエルの新しいレベル)
H.SLT Edge(SLTの中心を特定するために使用される八分木内のノードのサイズ)
I.SLT Step x(SLT中心点を特定するときの子へのPUSHのxにおける現在のステップ。子の数に依存する。)
J.SLT Step y(SLT中心点を特定するときの子へのPUSHのyにおける現在のステップ。子の数に依存する。大きさは、符号がプッシュされる子の数に依存することを除きSLT Step xと同じである。)
K.SLTx(SLTの位置を特定するために使用されるノードの現在の中心のx配置)
L.SLTy(SLTの位置を特定するために使用されるノードの現在の中心のy配置)
M.VLO Edge(VLO内でのPUSH時の現在のノードの長さ)
N.VLO Step x(VLO子ノードへの移動のためのxにおける現在のステップサイズ。符号は子の数に依存する。)
O.VLO Step y(VLO子ノードへの移動のためのyにおける現在のステップサイズ。この実装ではVLO Step xと同じ大きさだが、符号は子の数に依存する。)
P.VLO x(VLOノードの中心のxにおける配置)
Q.VLO y(VLOノードの中心のyにおける配置)
R.TOP Slope(セイエルの頂部(上側)エッジの傾き。注:これは実際の傾きであり、現在のxステップサイズに対する値ではない。)
S.BOT Slope(セイエルの底部(下側)エッジの傾き。注:これは実際の傾きであり、現在のxステップサイズに対する値ではない。)
T.t_y(投影面上のスパンの終点の頂部(上側)y値)
U.b_y(投影面上のスパンの終点の底部(下側)y値)
V.comp_t_y(t_yと比較するために独立して計算されたt_yの値)
W.comp_b_y(b_yと比較するために独立して計算されたb_yの値)
X.Notes(反復に関するコメント)
A.反復(逐次的回数のPUSHオペレーション)
B.SLT PUSH(SLT中心子ノードにPUSHされる)
C.VLO PUSH(VLO中心子ノードにプッシュされる)
D.Sael PUSH(セイエル子にプッシュされる)
E.SLT To Lev(PUSH後のSLT配置の新しいレベル)
F.VLO To Lev(PUSH後のVLOノードの新しいレベル)
G.Sael To Lev(PUSH後のセイエルの新しいレベル)
H.SLT Edge(SLTの中心を特定するために使用される八分木内のノードのサイズ)
I.SLT Step x(SLT中心点を特定するときの子へのPUSHのxにおける現在のステップ。子の数に依存する。)
J.SLT Step y(SLT中心点を特定するときの子へのPUSHのyにおける現在のステップ。子の数に依存する。大きさは、符号がプッシュされる子の数に依存することを除きSLT Step xと同じである。)
K.SLTx(SLTの位置を特定するために使用されるノードの現在の中心のx配置)
L.SLTy(SLTの位置を特定するために使用されるノードの現在の中心のy配置)
M.VLO Edge(VLO内でのPUSH時の現在のノードの長さ)
N.VLO Step x(VLO子ノードへの移動のためのxにおける現在のステップサイズ。符号は子の数に依存する。)
O.VLO Step y(VLO子ノードへの移動のためのyにおける現在のステップサイズ。この実装ではVLO Step xと同じ大きさだが、符号は子の数に依存する。)
P.VLO x(VLOノードの中心のxにおける配置)
Q.VLO y(VLOノードの中心のyにおける配置)
R.TOP Slope(セイエルの頂部(上側)エッジの傾き。注:これは実際の傾きであり、現在のxステップサイズに対する値ではない。)
S.BOT Slope(セイエルの底部(下側)エッジの傾き。注:これは実際の傾きであり、現在のxステップサイズに対する値ではない。)
T.t_y(投影面上のスパンの終点の頂部(上側)y値)
U.b_y(投影面上のスパンの終点の底部(下側)y値)
V.comp_t_y(t_yと比較するために独立して計算されたt_yの値)
W.comp_b_y(b_yと比較するために独立して計算されたb_yの値)
X.Notes(反復に関するコメント)
【0237】
第1の列内の初期化値(第1の列内の「(start)」)。値は、上でリストされている(図56nに示されている)とおりである。次いで、その後に、SLT中心、VLO、およびSLTセイエルを伴うPUSHオペレーションの14回の反復が行われる。最初の7回の反復は、図56～図63に幾何学的に示されている。
【0238】
最初の2回の反復は、SLT PUSHに続く、2回のVLO PUSH、次いで2回のセイエルPUSHである。次いで、この後、2回のVLO PUSH(反復7および8)、1回のSLT PUSH(反復9)、そして最後にVLO PUSHが行われる。
【0239】
反復#1の結果は図57に示されているが、これはVLOルートから子3へのSLT PUSHである。レベル1のVLOノード5701において、セイエル5702は、VLOの原点5706からレベル2の子3の中心、点5703に移動される。新しいセイエル原点の配置は(0.5,0.5)である。投影面5707は同じ場所に留まり、傾きは変化しない(底部エッジ5704に対して0、頂部エッジ5705に対して1)。
【0240】
反復#2は、図58に示され、これは子2へのSLT PUSHである。これは、レベル2の子2へのものであり、したがって異なる方向に加えて、ステップが前の距離の半分であることを除き、最後のオペレーションと類似している。ノード5801では、セイエル5802は、(0.25, 0.75)の点5803に移動される。底部エッジ5804の傾きは0のままであり、頂部エッジ5805の傾きは1のままである。投影面5807は同じ配置のままである。投影面との頂部エッジの交点は、底部交点より下にある(図示せず)。したがって、この時点では、セイエルは実際には投影平面と交差しておらず、投影は非アクティブである。
【0241】
反復#3は、ルートVLOノードから子3(レベル1)へのVLO PUSHである。これは、図59に示されている。VLOノード5901では、セイエル5902は移動しない。しかし、投影面5907は、VLOルートノードの中心からレベル1の子3の中心、点5906に移動する。現在、投影平面の原点は、子3の中心である、この点に移動していることに留意されたい。投影平面が移動しその原点が変化するので、投影平面との5902のエッジの交点が再計算される。
【0242】
反復#4は、図60に示されている。これは子1へのVLO PUSHである。セイエル6002は移動しないが、投影平面6007は移動し、したがって、底部エッジ6004と頂部エッジ6005との交点が再計算されなければならない。投影平面は、6006を新しい原点として+x方向に移動する。エッジの傾きは変化しない。
【0243】
図61は、反復#5、子1へのセイエルPUSHを例示している。セイエル6102の原点は変更されないが、2つのサブセイエルに分割され、そのうちの下側のセイエルは保持される。底部エッジ6104は同じままであるが、新しい頂部エッジ6105は移動し、したがって、投影面とのその交点は前の頂部と底部との交点の中間、または投影面原点から0.75の距離のところに来る。底部距離は0.5のままである。底部の傾きは0のままであるが、頂部の傾きは0.5の平均の傾きまで減少する。
【0244】
反復#6は、図62に示されている。これは子2へのセイエルPUSHである。ここでもまた、セイエル6202は、上側のセイエルが保持された状態で2つのサブセイエルに分割される。したがって、頂部エッジは、同じ傾きを有して同じままである。底部エッジは投影面の原点から離れて上方に移動し、その傾きは0と0.5または0.25の平均にリセットされる。
【0245】
反復#7は、図63に示されている。オペレーションは子0へのVLOプッシュである。投影平面は-x方向に移動し、その原点は-x方向および-y方向に移動する。セイエル6302は同じ配置にとどまり、エッジは、投影平面との交点が移動に対応するように変更されることを除き変更されない。
【0246】
Excelスプレッドシートシミュレーションは、SLT中心オフセットをゼロ以外の値に設定して再実行された(行5では、セルF5のxオフセット値に対して0.125、H5のyに対して0.0625)。結果は、図64および図65のスプレッドシートに示されている。
【0247】
体積技術は、シーン内、VLO、の、オブジェクトを含む、物質を表現するために使用される。また、これらは、SLTを使用してシーン内の光(ライトフィールド)を表現するためにも使用される。上で説明されているように、高品質な可視化および他の用途に必要な情報は、シーン再構築エンジン(SRE)を用いて現実世界のシーンから取得され得る。これは、合成生成されるオブジェクト(SPU形状変換モジュール3007によって生成される)と組み合わされ、複合シーンを形成することができる。いくつかの例示的な実施形態における技術は、SPU3001内の物質および光の両方ならびにそれらの相互作用について階層的、多重分解能、および空間的にソートされた体積データ構造を使用する。これは、たとえば、各ユーザの配置および閲覧方向によって決定されるか、またはユーザのグループに対して統計的に推定されるような、配置、分解能、可視性、および他の特性に基づき、遠隔使用に必要なシーンの部分を高速に識別することを可能にする。他の場合では、アプリケーションは、他の考慮事項に基づきデータベースの部分集合を要求し得る。必要な部分だけを通信することによって、チャネル帯域幅の要件が最小にされる。体積モデルの使用も、衝突検出(たとえば、集合オペレーションモジュール3003を使用して)および物理学ベースのシミュレーション(たとえば、質量プロパティモジュール3019によって容易に計算される質量プロパティ)などの仮想世界における高度な機能性を円滑にする。
【0248】
アプリケーションによっては、SREによって、または複数のSREによって別々に生成されるマターフィールドモデルとライトフィールドモデルとを組み合わせて、たとえば、1人もしくは複数のユーザ(たとえば、離れた場所のアリーナに配置されたミュージシャンまたはダンサー)による遠隔可視化およびインタラクションのための複合シーンモデルを形成することが望ましい場合がある。照明および材料プロパティがモデル化されているので、一方のシーンからの照明は、他方のシーンにおける照明を置き換えるために適用することができ、ビューアが一様に照らされているシーンを体験することを保証する。ライトフィールドオペレーションモジュール3023は、画像生成モジュール3009が画像を生成している間に照明を計算するために使用することができる。
【0249】
シーングラフまたは他のメカニズムが、個別のシーン要素間の空間関係を表現するために使用される。1つまたは複数のSREは、プレノプティックシーンデータベース1A07に保存される現実世界モデルを生成し得る。それに加えて、他の形式(プレノプティック八分木ではない)で表現される他の現実世界モデルまたは合成空間モデルがデータベースに収められる。これは、形状変換モジュール3007によってプレノプティック八分木表現に容易に変換され得るほとんどどのような表現であってもよい。これは、多角形モデル、パラメトリックモデル、ソリッドモデル(たとえば、CSG(空間領域構成法)または境界表現)などを含む。SPU3001の機能は、モデルが変化するか、または要件が変化した場合(たとえば、ビューアがオブジェクトに近づき、より高い分解能の変換が必要になった場合)に、変換を1回または複数回実行することである。
【0250】
ライトフィールドおよび材料プロパティに加えて、SREは、シーン内の多種多様な追加特性を発見することもできる。これは、たとえば、以前に取得されたモデルまたは合成されたモデルをシーンに組み込むことを可能にするために使用され得るシーン内の視覚的属性を認識するために使用することが可能である。たとえば、リモートビューアが視覚的にオブジェクトに近づきすぎて、現実世界(たとえば、木)からSREによって取得されたものよりも高い分解能を必要とする場合である。代替的モデル(たとえば、パラメトリック樹皮)は、ユーザに対してより高い分解能の視覚情報を生成するために滑らかに「スイッチイン」することが可能である。
【0251】
3001におけるSPUモジュールは、多くの場合にユーザの要求に応答するなどしてシーングラフがアプリケーションプログラムによって修正されるときに、アプリケーション要件を達成するようにモデルを変換し、操作するために使用され得る。この、および他のSPU空間オペレーションは、高度な機能を実装するために使用することができる。これは、集合オペレーションモジュール3003によって計算されるような干渉および衝突検出に加えて、SPU質量プロパティモジュール3019によって計算されるような質量、重量、および重心などの質量プロパティを必要とする特徴を含む。したがって、プレノプティックシーンデータベース内のモデルは、ユーザおよびアプリケーションプログラムによって決定されるようなリアルタイムシーン変化を反映するように修正される。
【0252】
物質(VLO)および光(SLT)の両タイプの情報は、空間の選択された領域(SLTの場合は方向空間)および指定されたレベルの分解能(SLTの場合は角度分解能)についてアクセスされ、伝送され得る。それに加えて、プロパティ値は、典型的には、ノードの部分木内のプロパティを表す木構造内の低分解能ノード(木内の上位ノード)に収められる。これは、たとえば、八分木ノードの部分木内の色の平均値もしくは最小値/最大値、またはセイエル木ノードの部分木内の照明の何らかの代表的尺度であり得る。
【0253】
リモートプロセス(たとえば、1人または複数のユーザ)の必要性に応じて、シーンモデルの必要な部分集合のみが伝送される必要がある。見るために、これは、典型的には、他の領域より高い分解能でモジュール3009によって現在見られている(または見られると予想される)シーンの部分について高分解能情報を送信することを意味する。より高い分解能の情報は、視覚的に遠方にあるオブジェクトよりも近くにあるオブジェクトについて伝送される。追跡または予測される動きは、必要とされるシーンの部分を予想するために使用されることになる。これらは、高い優先度で転送される。3009における八分木モデルの高度画像生成方法は、シーンがレンダリングされるときに閉塞した領域を決定することができる。これは、必要とされていないか、またはより低いレベルの忠実度で表現され得るシーンの領域(将来に見る可能性があることを考慮する)を示している。この選択的伝送機能は、コーデックの固有の部分である。様々な分解能におけるシーンの一部のみがストレージからアクセスされ、伝送される。制御情報は、リモートユーザとの同期を維持するために必要に応じて転送される。
【0254】
多数のリモートビューアが同時に動いているときに、それらのビューイングパラメータは、伝送優先度を設定するために要約され得る。代替的手段は、おそらく経験に基づき、確率的に予想されるビューア選好をモデル化することであろう。シーン全体のモデルのバージョンは、何らかの、おそらくは限られた、分解能レベルで、すべてのビューアから常に利用可能なので、予想されないビューは、それでも結果として、シーンのビューであるが、画質は低レベルになる。
【0255】
画像生成に必要な情報は、一般にソースシーンモデルデータベースの部分集合であるローカルデータベース内に維持される。シーンの構成は、ソースにおけるグローバルシーングラフの部分集合であってよいローカルシーングラフによって制御される。したがって、特に大きな「仮想世界」については、ローカルシーングラフは、オブジェクトおよびライトフィールド情報、ならびにユーザから見えるか、もしくは潜在的に見える、またはアプリケーションにとって重要であり得る(たとえば、ユーザの体験)他のアイテムのみを維持し得る。
【0256】
シーンサーバとクライアントとの間で通信される情報は、制御情報、およびプレノプティック八分木の形態のモデルの一部と、おそらくは他のモデル(たとえば、他の形式の形状、BLIF機能)からなる。プレノプティック八分木は、VLOの形態のマターフィールドとSLTの形態のライトフィールドとを含む。各々が階層的で、多重分解能の、空間的にソートされた体積木構造である。これは、それらがモデリング空間の指定された領域によって、空間領域によって指定され得る可変分解能(セイエル木については方向空間)で、アクセスされることを可能にする。シーン空間内の各ユーザの配置、見る方向、および必要とされる分解能(典型的には、見る方向の視点からの距離に基づく)と予測される将来の変化は、こうして、伝送される必要があるシーンの部分集合、および様々な考慮事項(たとえば、視点がどれだけ遠く速く移動できるか、通信チャネルの帯域幅特性、シーンの様々なセクションに対する画質の相対的重要性)に基づく各々に対する優先度を決定するために使用することができる。
【0257】
リモートサイトで専用にできる計算能力に応じて、通信チャネルのサーバサイドに関連付けられている機能は、リモートサイトで実装することができる。これは、たとえば、マターモデル(VLO)が、チャネル上でも伝送されるのではなく、リモートサイトにそこに再構築されたライトフィールド情報(SLT)とともに伝送されることだけを可能にする。潜在的な通信効率は、もちろん、状況の詳細に依存する。固体材料の単純なモデルをリモートサイトに伝送し、続いて、ローカルでライトフィールドを計算して表示することは、ライトフィールド情報全部を伝送することよりも効率的であり得る。これは、特にシーン内の静的オブジェクトに当てはまることもあり得る。その一方で、形状が変化するか、または複雑な動きをするオブジェクトは、要求に応じて、ライトフィールドSLTのみを伝送すると都合がよい場合がある。
【0258】
プレノプティック八分木では、SLTは、シーン内の空間における何らかの配置(または、いくつかの場合において、シーンを越える配置)での5D階層表現である。5次元は、すべてのセイエルが交わる中心の3つの位置成分(x,y,z)に、セイエルを定義する2つの角度を加えたものである。セイエル木は、VLOボクセルの中心に配置されるか、またはボクセル内のどこかに指定され得る。したがって、VLOノードは、プロパティによって定義されるように、物質を含み、任意選択で、セイエル木も含むことができる。実質的に非不透明(透過性)媒体を含み、シーン境界(voidボクセル)に隣接している空間内のボクセルは、いくつかの実施形態において「窓」ボクセルと称され得る。
【0259】
セイエルの集合は、シーン内の複数の点(たとえば、同じ反射特性を有する表面上の近くの点)で類似するものとしてよい。このような場合には、異なる中心を有するセイエルの集合は、中心配置から独立して表現され得る。複数の中心点について同一である場合、それらは複数の中心配置から参照され得る。差が十分に小さい場合、複数の集合は、1つのモデルセイエルまたはモデルセイエルの集合からの偏差の個々の集合によって表現され得る。または、それらは、事前に計算された基底関数の集合に係数を適用することによって生成され得る(たとえば、主成分分析を用いて代表データセットから生成されたセイエルデータセット)。それに加えて、他の変換は、中心の周りの回転などによって、単一のセイエルモデルを特定の集合に修正するために使用することができる。点光源などの、いくつかのタイプのSLTは、単にモデルに追加の配置を与えるだけで複製され得る(補間または外挿を必要としない)。
【0260】
シーンコーデックは、データソースおよびデータシンクがあるデータフローモードで動作する。一般に、これは要求/応答対の形態をとる。要求は、応答が生成される(たとえば、現在の状態)ローカルコーデックに向かれるか、またはリモートコーデックに伝送されてアクションが実行されそこで応答が返され要求されたアクションの結果を提供するものとしてよい。
【0261】
要求および応答はシーンコーデックのアプリケーションプログラミングインターフェース(API)を通じて通信される。基本コーデックAPI6601のコア機能は、図66にまとめられている。コーデックは、動作パラメータモジュール6603を通じて初期化される。この機能は、コーデックの動作モード、制御パラメータ、およびステータスを指定するか、または読み出すために使用され得る。別のシーンコーデックへのリンクが確立された後、この機能は、特定の許可を与えられている場合に、リモートコーデックを制御し、それにクエリを実行するためにも使用され得る。
【0262】
コーデックAPI確立リンクモジュール6605は、トリガーされると、指定されたリモートシーンコーデックへの通信リンクの確立を試みる。これは、典型的には、通信動作パラメータ(プロトコル、資格情報、予想されるネットワーク帯域幅など)を確立するための「ハンドシェイク」シーケンスを開始する。成功した場合、両方のコーデックが、通信オペレーションの準備ができていることを呼び出しルーチンに報告する。
【0263】
次のステップは、シーンセッションを確立することである。これは、APIオープンシーンモジュール6607を通じて設定される。これは、リモートシーンデータベースにアクセスまたは更新するためにリモートサイド、およびさらには多くの場合にローカルサイドの両方でシーンデータベースへのリンクを確立することを伴う。たとえば、リモートシーンデータベースからローカルサブシーンデータベースを構築するか、またはローカルシーンデータベースをリモートシーンデータベースと同時に更新する。
【0264】
シーンまたは複数のシーンへの接続が確立されると、シーンデータベースにアクセスして変更するために、2つのコードAPIモジュールが使用され得る。リモートシーンアクセスモジュール6609は、通信チャネルにまたがってサブシーンの移動を伴わないリモートシーンに関する情報および変更を要求するために使用される。ローカルシーンデータベース上で実行されるオペレーションは、ローカルシーンアクセスモジュール6611を使用して実行される。サブシーンの移動を伴うシーンデータベースクエリは、クエリプロセッサモジュール6613を用いて実行される。コーデックによって実行されるすべてのアクションは、セッションログモジュール6615によって記録される。
【0265】
クエリプロセッサモジュール6613の主な機能は、リモートシーンデータベースからのサブシーンを伝送すること、またはそれに組み込まれる(またはそれから削除される)サブシーンを要求することである。これは、たとえば、プレノプティック八分木ノードの状態に関する質問、質量プロパティの計算の要求などを伴い得る。これは、典型的には、サブシーン抽出、ならびにプレノプティック八分木の圧縮され、シリアル化され、おそらく暗号化されているサブツリーおよび関連情報の伝送を伴う。抽出されるべきサブシーンは、典型的には、空間領域、体積空間領域、もしくは方向空間領域、またはその両方の領域を結果としてもたらすことができるシーングラフの何らかの形態で指定された幾何学的形状、八分木、および他の幾何学的エンティティの集合として定義される。それに加えて、体積空間または方向空間の様々な領域において必要とされる分解能が指定される(たとえば、レンダリング状況において視点から減少する)。また、余計な情報を送信しないように情報のタイプも指定される。いくつかの状況において、サブシーン抽出は、何らかの形態の空間クエリを実行するために使用することができる。たとえば、ある領域のサブシーン抽出を実行するがレベル0までしか実行しないという要求は、単一のノードを返し、これがNULLであることがわかれば、その領域には物質がないことを示す。これは、また、プレノプティックシーン内の特定の特徴を探索するように拡張することも可能である。
【0266】
クエリプロセッサモジュール6613のサブ機能が図67に示されている。これは、ステータス&プロパティクエリモジュール6703からなる。これは、書き込みを実行する能力、または中にどのようなプロパティが存在しているか、または新しいプロパティが定義できるか、などのプレノプティックシーンに関する情報を取得するために使用される。サブシーンマスク制御モジュールは、何らかの形態のサブシーン抽出要求を受け入れ、要求を遂行するためのマスクプランを構築する。これは、典型的には、プランサブシーンマスクモジュール6705によって計画されたように要求側システムにサブシーンをインクリメンタルに送信する進化型マスクの集合である。
【0267】
サブシーンマスク生成器6707は、シーンデータベースからノードを選択するために使用されるプレノプティック八分木マスクを構築して要求側システムに返送する。これは、抽出のために次のマスクを継続的に構築する。サブシーン抽出モジュール6709は、マスクによって決定されたとおりにノードを選択するためにシーンプレノプティック八分木のトラバースを実行する。次いで、それらは、シリアル化され、さらに処理され、次いで、要求側システムに伝送されるパケットのストリーム内に入力される。サブシーン挿入器モジュール6711は要求システムによって使用され、それによりプレノプティックノード要求の伝送されたストリームを使用してシーンモデルのローカルサブツリーを修正する。
【0268】
コーデックは、サブシーン抽出またはサブシーン挿入、またはその両方を実行し得る。一方のみが実装されている場合、他方のみに必要なモジュールや機能はなくしてもよい。したがって、エンコーダのみのユニットは、サブシーン抽出器6709を必要とするが、サブシーン挿入器6711を必要としない。デコーダのみのユニットは、サブシーン挿入器モジュール6711を必要とするが、サブシーン抽出器モジュール6709を必要としない。
【0269】
上で説明されているように、プレノプティックシーンモデルからサブシーンを抽出することは、即時または目先の可視化または他の用途のために必要なシーンデータベースの部分のみをクライアントに効率的に伝送することを可能にする。いくつかの実施形態において、シーンデータベースには、プレノプティック八分木が使用される。このようなデータ構造の特性は、サブシーンの効率的抽出を円滑にする。
【0270】
様々なタイプの情報が、補助データ構造において、別個のデータベースにおいて、または何らかの他の仕方で、別個のVLOとして、またはプレノプティック八分木内の八分木またはセイエル木ノードに含まれるか、または付けられるプロパティとして、のいずれかでプレノプティック八分木に含まれ得る。初期サブシーン抽出要求では、クライアントが必要とする情報のタイプを指定する。これは、サービスされるアプリケーションに特有の様々な仕方で行われ得る。
【0271】
次は、クライアントがVRまたはARヘッドセットなどのディスプレイデバイスによるリモートビューイングのためにサブシーン抽出を要求している場合の使用例である。大きなプレノプティック八分木は、サーバサイドに保持される。画像を生成するためには部分集合だけがクライアントサイドにあればよい。ここでは、プレノプティック八分木マスクが一例として使用される。これを達成するために他の多くの方法が使用され得る。マスクは、集合オペレーションを使用してプレノプティック八分木内のノードを選択するために使用されるプレノプティック八分木の一形態である。たとえば、大きな八分木のサブセクションは、より小さな八分木マスクと交差オペレーションとを使って選択することができる。2つの八分木は、全く同じユニバースおよび配向を共有する。2つの木はルートノードから同時にトラバースされる。占有ノードとしても存在しない大きい八分木内のノードはいずれも、単にメモリ内でスキップされて無視される。これらは単にトラバース内に現れないだけである。これらは事実上消えてしまう。このようにして、ノードの部分集合は、トラバースによって選択され、伝送のためにシリアル化され得る。次いで、この部分集合は、受信側で再作成され、ローカルプレノプティック八分木に適用される。この概念は、セイエル木に容易に拡張できる。
【0272】
次に、インクリメンタルマスクを使用してマスクの概念が拡張される。したがって、開始マスクは、受信側に伝送する追加のノードを選択するために増加もしくは減少、または他の何らかの形の修正を行われ得る。マスクは、様々な仕方でこの目的のために修正され得る。膨張および浸食のモルフォロジーオペレーションは、SPUモルフォロジーオペレーションモジュール3015を使用して適用することができる。幾何学的形状は、SPU形状変換モジュール3007およびSPU集合オペレーションモジュール3003を使用して変換することによって追加されるか、またはマスクの一部を除去するために使用され得る。典型的には、新しいマスクは古いマスクから差し引かれ、インクリメンタルマスクを生成することになる。これらを使用することで、大きなシーンモデルをトラバースし、受信側で追加されるか、または他の何らかの形で処理されるシリアル化され、伝送されるべき新しいノードを特定する。状況に応じて、反対の減算を実行され、それにより古いマスクから新しいマスクが差し引かれ、除去されるべきノードの集合を決定する。これは、シリアル化され直接伝送されて、受信側で除去を行うことができる(サブシーン抽出を伴わない)。受信側でも同様の方法が使用され、何らかの理由で不要になったノードを除去し(たとえば、ビューアが移動し、一部の領域では高分解能情報はもはや不要である)、現在のマスクへの変更をサーバサイドに通知することができる。
【0273】
プレノプティック投影エンジン(PPE)の目的は、プレノプティックシーンモデル内の一方の配置から他方の配置へ効率的に光を投影し、結果として光伝達をもたらすことである。これは、たとえば、出射点ライトフィールド(PLF)によって表される光源から、メディエルに付けられた入射PLFに向かうものであってよい。または、これは入射PLFであり、その結果出射光が出射PLFに加えられるものとしてよい。
【0274】
プレノプティック投影は、投影プロセスを効率的に実行するために空間的にソートされる階層的多重分解能木構造を利用する。次のような3つの木構造が使用される。(1)メディエルを保持するVLOまたは体積八分木(これは単一の八分木とみなされるが、UNIONで合併された複数の八分木であってもよい)。(2)SOOまたはセイエル木原点八分木、これはプレノプティック八分木内のセイエル木の原点を含む八分木である。および(3)SLT、プレノプティック八分木内のいくつかのセイエル木(原点配置はSOO内である)。
【0275】
プレノプティック投影エンジンは、各SLTの原点から始まる前後シーケンスでSLT内のセイエルをVLO内のノードに投影する。セイエルがメディエルノードと交差するときに、投影のサイズは、媒体ボクセルのサイズと比較される。分析は、現在必要とされている空間または角度分解能、その上のメディエルおよびセイエル投影の相対的サイズ、木構造内の低いレベルでのより高い分解能の情報の存在、および他の要因などの多くの要因に基づき行われる。必要な場合、メディエルもしくはセイエルのいずれかまたはその両方が、その子によって表される領域に細分され得る。次いで、より高い分解能で同じ分析が継続する。
【0276】
細分プロセスが完了すると、光伝達が行われ得る。セイエル木内のセイエルは、たとえば、結果として、メディエルに付けられたセイエル木内のセイエルまたは複数のセイエルの作成もしくは修正をもたらし得る。典型的なアプリケーションでは、入射ラディエル情報は、メディエルに付けられた入射PLFに蓄積されてよい。入射SLTが十分に入れられたときに、メディエルに対するBLIFが適用されてよく、その結果、メディエルに対する出射PLFが得られる。
【0277】
投影プロセスは、トラバースで訪問された各VLOノードに付けられた投影面へのセイエルの投影を維持することによって動作する。投影面は、投影されるセイエルが属する頂部セイエルに応じて、軸に対して垂直である。
【0278】
このプロセスは、VLOおよびSOO木構造をユニバースの中心から開始することによって始まる。したがって、SOO内の配置は、ユニバースの中心から始まる。それは、適用された任意のマスクおよび任意の指定されたトラバースシーケンスによって決定されるように、投影されるべき最初のSLTの配置までトラバースされる。投影平面は、第1のセイエルに応じて、適切な軸に垂直な、ユニバースの原点を通る平面として始まる。動作時に、3つのすべてが定義され、すべての頂部セイエルの方向を考慮して追跡され得る。
【0279】
プレノプティック投影エンジンの主な機能は、VLOがトラバースされるときに、メディエルに付けられた投射面へのセイエル投影である斜めピラミッド投影の投影を継続的に維持することである。これは、始めに幾何学的形状を初期化し、次いで3つのツリー構造がトラバースされ、典型的には、すべてのSLTのすべてにおけるすべてのセイエルをシーン内に投影するとともにそれを維持し続けることによってことによって行われる。これは、このプロセスの間に、またはそれ以降に作成されたときにさらにトラバースされる可能性のある追加のSLTを作成するものとしてよい。
【0280】
したがって、この方法の典型的な流れは、木構造を初期化し、次いで一連のTOO PUSHオペレーションを使用してTOOをトラバースし最初のSLTをその原点に配置し、各ステップに対する投影幾何学的形状を維持することである。次に、VLOは、最初のSLTの原点を囲むようにトラバースされる。次に、VLOは、前から後への順序でトラバースされ、SLTの原点から、頂部セイエルの方向に、距離が増大する一般的な順序でノードを訪問する。VLOの各PUSHで、ノードに接続されている投影面への投影は、セイエルがVLOノードと交差し続けているかどうかを確認するためチェックされる。交差していなければ、すべての部分木はトラバースで無視される。
【0281】
メディエルVLOノードに遭遇した場合、上で概要を述べたように分析により実行する次のアクションを決定し、典型的にはVLOおよび/またはSLTの部分木を訪問することを伴う。完了すると、木は、次のセイエルが同じ仕方で投影され得る場所までPOPされて戻る。最初のまたはそれ以降のSLTの最終セイエルが処理されてしまうと、木構造は、次のSLTの処理が開始できる点までPOPされる。このプロセスは、すべてのSLTにおけるすべてのセイエルが処理されるか、または祖先セイエルの処理が行われたので処理の必要をなくされるまで継続する。
【0282】
全体的な手順は、図68Aのプレノプティック投影エンジンのフローチャートに示されている。これは、多くの可能な手順のうちのサンプル手順である。プロセスは、オペレーション68A02における投影メカニズムの初期化から始まる。上で提示されているように、VLOトラバースは、そのルートから始まる。したがって、注目する投影面は、ユニバースの中心に付けられる(3つが実際に追跡され得る)。SSOも、そのルートに初期化される。したがって、初期SLT点は、ユニバースの原点から始まり、SLTの原点にPUSHされる。訪問されるべき初期セイエルは、頂部セイエル0である。
【0283】
オペレーション68A04では、SOO木構造は、PUSHオペレーションを使用してプレノプティック八分木ユニバース内の次のSLTの原点までトラバースされる。最初の使用において、これはユニバースの原点からとなる。ほかのときには、最後のオペレーションが中止したところからである。現在のVLO投影面(初回にユニバースの中心に付けられている)に付けられた投影面上への現在の頂部セイエルの投影は、次のSLTの原点に到達するように各オペレーションに対して維持される。SOO内に追加のSLTがない場合(典型的にはルートノードからのPOPへの試みによって検出される)、決定オペレーション68A06は、オペレーションを終了し、要求ルーチンに制御を返す。
【0284】
そうでない場合、オペレーション68A08は、現在のSLTのセイエルを、最初の非ヌルノード(非voidボクセル)であるラディエルを表すセイエルまでトラバースする。ここでもまた、セイエルと投影面との間の投影幾何学的形状は維持される。ラディエルを有するセイエルが残っていない場合、制御は決定オペレーション68A10によってオペレーション68A04に戻され、次のSLTを見つけてトラバースする。
【0285】
セイエルが投影される必要がある場合、オペレーション68A12は、現在のSLTの原点を囲むノードまでVLO木をトラバースする。基本的には、セイエル投影がその投影面とのVLOノード交点と交差する投影面を有する最初のVLOノードを見つける。そのようなVLOノードが見つからない場合、決定オペレーション68A14によって制御がオペレーション68A08に返され、処理されるべき次のセイエルに進む。セイエルの投影がノードと交差しない場合、制御は、決定オペレーション68A16によってオペレーション68A12に戻され、調査されるべき次のVLOノードに進む。
【0286】
そうでない場合、制御は、現在の投影面上の現在のセイエルの投影が分析されるオペレーション68A18に渡される。そのようなものに対する現在の規則が満たされている場合、制御は、決定オペレーション68A20によって、放射輝度伝達または再サンプリングが行われるオペレーション68A22に渡される。これは、一般的に、おそらくはセイエルの放射輝度の分散に基づき、十分なレベルの分解能が達成されたこと、投影のサイズが、ある意味で、VLOノードのサイズに匹敵することを意味する。いくつかの場合において、そのノードに付けられた(必要に応じて作成される)SLT内の適切なセイエルへの一部または全部の放射輝度の伝達が行われる。他の場合には、放射輝度は、ノード内で何らかの他の仕方により使用され得る。
【0287】
分析により、より高いレベルの分解能がセイエルまたはVLOノードに必要であると決定された場合、オペレーション68A24は、VLOノードが細分される必要があるかどうかを決定する。そうであれば、制御はオペレーション68A26に渡され、PUSHを実行する。状況に関する情報は、典型的には、後ですべての兄弟ノードを訪問するためにオペレーションスタックにPUSHされる。そうでない場合、制御は、現在のセイエルの細分の必要性が処理される決定68A28に渡される。そうであれば、制御は、セイエルPUSHが実行されるオペレーション68A30に渡される。そうでなければ、現在のVLOノードへのセイエル投影は、追加の処理を必要とせず、制御はオペレーション68A12に戻され、調査のために次のVLOノードにトラバースし、放射輝度の可能な伝達を行う。
【0288】
プレノプティック八分木からのサブシーン抽出の一般的な流れは、図68Bのフローチャートに示されている。プロセスは、サブシーン要求が受信されたときに開始する。初期ステップ68B02は、ヌルサブシーンマスクを初期化する。これは、典型的には、単一ノードプレノプティック八分木および関係パラメータである。次いで、要求は、ステップ68B04で分析される。画像生成状況については、これは、シーン内でのビューアの3D配置および見る方向を含むことが可能である。追加情報は、視野、画面解像度、および他のビューイングおよび関係パラメータであろう。
【0289】
次いで、見ることについては、これは、最初の画像に対する初期視錐台を定義するために使用されることになる。これは、幾何学的形状として表現され、SPU形状変換モジュール3007を使用して八分木に変換され得る。他の状況では、セイエル木が生成され、各ピクセルが結果としてセイエルを形成し得る。視点からの距離は、マスクデータ構造の一部として組み込まれるか、または他の何らかの仕方で計算される(たとえば、サブシーン抽出時にオンザフライで計算される距離)。これはサブシーン抽出時に使用され、伝送のために選択されるべきシーンモデル(体積空間または方向空間)の分解能を決定する。
【0290】
モジュール68B04によるこの分析から、一連のサブシーンマスクに対するプランが作成される。一般的な戦略は、結果としてビューアに対する使用可能な画像を非常に素早く形成する受信側の初期サブシーンモデルを生成するマスクから開始することである。これは、たとえば、伝送のためにより小さい初期データセットを求める低分解能要求を有することが可能である。次のステップは、典型的には、徐々に分解能が高まるディテールを追加していくことである。そして、ビューイングクライアントからの要求の中の情報は、ビューイングの必要性の将来の変化を予想するために使用され得る。これは、たとえば、ビューアの指向性および回転運動の方向および速度を含むことが可能である。これは、将来の予想される必要性を考慮してマスクを拡張するために使用される。これらの拡張は、将来のマスク変更のための予定されたステップに組み込まれる。
【0291】
このプランは次にオペレーション68B06に渡され、プランにおける現在のステップによって定義されるようなサブシーンマスクが完全なプレノプティックシーンモデルと交差する。次いで、プレノプティック八分木の特定のトラバースの結果として得られるノードは、集められて要求側プログラムに伝送できるようにシリアル形式にされる。ノードの圧縮、暗号化、および他の処理オペレーションは、伝送のために渡される前に実行され得る。
【0292】
次のフローオペレーションは、次の要求を受け入れる68B08によって実行される決定である。これが新しいサブシーンについて、現在のサブシーンマスクおよびプランを修正することによって対応できないものである場合、現在のマスクプランは破棄され、オペレーション68B02で新しいサブシーンマスクが初期化される。その一方で、要求が決定オペレーション68B10で決定されるような、現在のプランですでに予想されているサブシーンに対するものである場合、オペレーション68B12でプランの次のステップが実行される。サブシーンマスクは修正され、制御がオペレーション68B06に戻され、次のサブシーン抽出を実装する。決定68B10によりサブシーンマスクの終了に遭遇した場合、決定オペレーション68B14によって決定されるような新しいサブシーン抽出要求が存在すれば、次の要求は、オペレーション68B02で新しいサブシーンマスクを開始するために使用される。新しい要求が保留されていない場合、サブシーン抽出動作68B00は、新しい要求が到着するまで待機状態に置かれる。
【0293】
図69は、一実施形態において、シーン内の複数の視点からの画像を生成するためのシーンデータベースからサブシーン(モデル)を抽出するプロセス6900の流れ図である。第1のステップであるオペレーション6901は、完全なシーンモデルを含むデータベースへの接続を確立するオペレーションであり、そこからサブシーンが抽出される。オペレーション6903において、出力される新しいサブシーンは、プリミティブがないプレノプティックフィールドを有するように初期化される。言い換えると、この時点では、サブシーン内にマターフィールドもライトフィールドも存在しない。オペレーション6905において、各視点における仮想カメラの6DOFの姿勢、固有パラメータ、および画像寸法を含む画像生成パラメータに基づき、「クエリセイエル」の集合が決定される。クエリセイエルは、完全シーンのSLT内のあるレベルで定義されたセイエルであり、このセイエルは、クエリセイエルの立体角体積内に置かれるプレノプティックプリミティブに対するシーンに空間的にクエリ(プローブ)を実行するために使用される。クエリセイエルの集合は、典型的には、視点毎のセイエルの集合の合併である。視点毎のセイエルの集合は、典型的には、各画像ピクセルが少なくとも1つのクエリセイエルに含まれるようにFOV(カメラの視錐台)を覆う。クエリセイエルは、シーン内の様々な距離に置かれるプリミティブのサイズにマッチするように適応的にサイズを決められ得る。クエリセイエルの集合は、また、FOVの緊密な合併よりもわずかに大きい、またははるかに大きい5Dプレノプティック空間を覆うように意図的に作られてもよい。このような非最小プレノプティック被覆に対する1つの例示的な理由は、プロセス6900が画像生成のためにクライアントによって使用される仮想カメラの6DOF経路を予想することが可能であることである。
【0294】
オペレーション6907において、プレノプティックフィールド内のプリミティブは、プロセス7000を使用して各クエリセイエルを完全シーン内に投影することによって新しいサブシーン内に蓄積され、これにより一般的にライトフィールドが画像生成パラメータによって指定された目標精度に解決されるように投影の再帰的連鎖が引き起こされる。目標精度は、放射、スペクトル、および偏光の目標精度の表現を含み得る。プロセス7000の説明は、図70を参照しつつ以下に述べられる。
【0295】
オペレーション6909において、プロセス6900は、蓄積されたプリミティブの部分集合をサブシーン内に保持するように決定する。この決定の詳細は、オペレーション6915の説明において以下に述べられる。単純ではあるが実用的な一事例において、プリミティブは、サブシーン要求の画像生成パラメータで指定されたカメラFOVのうちの1つの内側に少なくとも一部は入る場合に、プリミティブが保持される。オペレーション6911において、サブシーンの外側シーン境界は、FOVの少なくとも1つに部分的にまたは完全に含まれる蓄積されたプリミティブを少なくとも囲むように定義される。注目するラディエルは、オペレーション6913において定義されている外側シーン境界上に投影される。この投影は、一般に、境界の内側および外側の両方のシーン領域から行われ得る。境界ライトフィールドは、一般的に、境界に隣接する境界メディエルのところで窓ライトフィールドとして実現される。
【0296】
オペレーション6915において、プロセス6900は、現在のユースケースおよびQoS閾値に対して適切なようにサブシーンをさらに単純化する。サブシーンデータサイズを最小化することが重要であるときに、サブシーン単純化の顕著な一例は、BLIF相互作用の結果、または他のメディエルからの輸送(投影)の結果生じるメディエルのラディエルの完全なまたは部分的な除去である。つまり、窓または放射ライトフィールドの一部でないラディエルを除去することによって、サブシーンはより「正準」形式になり、特に圧縮されたBLIF表現が使用されるときには、典型的には非正準形式よりもデータサイズが小さくなる。本明細書のコンテキストにおいて、シーンモデルのプレノプティックフィールドの正準表現(「正準形式」)は、ユースケースに依存する実用的な何らかの程度で、ライトフィールドの非窓部分および非放射部分に最小量の収められているライトフィールド情報を含むものである。これは、マターフィールド(メディエルBLIFを含む)ならびに窓および放射ライトフィールドラディエルの十分に正確な表現を収めることによって達成される。次いで、必要なときに、総準定常状態ライトフィールドの他の部分は、たとえば、後述の以下の図70および図71を参照しつつ説明されているようなプロセスによって計算することができる。
【0297】
ある程度の単純化(圧縮)は、サブシーン抽出クライアントの必要性に合わせてBLIF表現を適応させることによって達成可能である。クライアントがサブシーンの画像を生成することを意図しているこの例では、たとえば、自動車の表面の光沢のあるBLIFでは、1つの視点からは木が非常に込み入って反射し、別の視点からは空の均質なパッチだけが反射され得る。第2の視点のみがオペレーション6905における画像生成パラメータに含まれる場合、よりコンパクトなBLIF表現は、そのスペキュラーローブの精度は低いが、サブシーンモデルでは十分であり得る。
【0298】
多くのユースケースにおいて、サブシーンデータが疎らであることは、抽出されたサブシーンの体積範囲を最小化することよりも重要な目標であり得ることに留意されたい。オペレーション6905で指定された視点に応じて、サブシーンのマターフィールドは、大半が、視点の合併の方を向いている部分的なオブジェクトおよび表面「シェル」からなるものとしてよい。BLIF圧縮に加えて、プレノプティックプリミティブではない他のシーンモデルエンティティは、サブシーンモデルのデータサイズを最小にするために圧縮、適応的リサンプリング、再パラメータ化などが行われ得る。一般的に、抽出されたサブシーンのライトフィールドおよびBLIFデータは、そのマターフィールドに類似する疎らさを有することが予想される。
【0299】
サブシーンのデータサイズを最小にするという目標とは反対に、他の潜在的目標も存在する。たとえば、画像生成時間を短縮することは、サーバ対クライアントネットワークスループットは高いが、クライアントによるコンピューティングキャパシティが限られているユースケースでは望ましい場合がある。3Dゲームまたはバーチャルツアーでは、クライアントは、限られた計算コストで高い表示フレームレートを維持することを目的として、代わりにより多くのライトフィールド情報を「焼き込んだ」あまり正準ではないサブシーンを望むこともあり得る。以下に説明されている図70および図71に関係する別の例では、クエリセイエルに間接的に寄与するだけのプリミティブが、出力サブシーンに含まれることもあり得る。要求されたFOVに間接的に反射する強い光源は、予期しない視点からの画像内にその効果を忠実に再現することを目的として放射ライトフィールドを有する実際のメディエルとして含まれることもあり得る。簡略化された後、抽出されたサブシーンは、オペレーション6917で所望のシーンデータベースに出力され、処理6900を終了する。プロセス6900で示されているオペレーションの順序は、他の実施形態では異なることもあり得ることに留意されたい。
【0300】
図70は、一実施形態において、シーンのプレノプティックフィールドに投影された指定クエリセイエルに直接的または間接的に光を与える(1つまたは複数の)プレノプティックプリミティブを蓄積するプロセス7000の流れ図を示している。このコンテキストにおいて、「蓄積する」は、値、参照、ハンドル、または他の好適な手段によって、蓄積されたプリミティブをサブシーンに収めることを意味する。クエリセイエルは、図21～図65を参照して上で説明されている仕組みを使用して、オペレーション7001においてプレノプティックフィールドに投影される。オペレーション7003において、プロセス7000は、クエリセイエルに直接的に光を与える第1のメディエルを決定し、「第1」の意味は、ユースケースに依存するシーンプリミティブの優先順序によって決定される。典型的な例示的な順序付けは、クエリセイエルの原点に近い位置にあるメディエル(投影がセイエルの原点から外に向かって進んでいると考えられるときに先に遭遇したメディエル)に高い優先度を与える。他の優先順位付けも可能であり、たとえば、特定のアプリケーション固有の属性を有するメディエル(たとえば、注目するスペクトル帯域の光を与える可能性の高いメディエル)が他のメディエルよりも優先されるような優先順位付けも可能である。複数のメディエルが等しい優先度(同点)を有する場合、実施形態に同点のメディエルを並列処理するのに十分な並列計算能力がない場合に何らかの同点を破る基準が採用されるであろう。
【0301】
オペレーション7005において、プロセス7000は、プロセス7100を使用して、現在のメディエルおよびクエリセイエルに寄与するそのラディエルを蓄積する。オペレーション7007において、プロセス7000は、現在のメディエルがクエリセイエル全体の範囲を角度的に定めているかどうかをチェックする。もしそうであれば、プロセス7000は終了する。もしそうでなければ、プロセス7000は、オペレーション7009においてクエリセイエルをメディエルによって範囲を定められたサブセイエルとメディエルによって範囲を定められていないサブセイエルとに細分する。1つまたは複数のSLTレベルでのサブセイエルへの細分は、何らかの停止基準に到達した時点で停止する。典型的な停止基準は、目標ライトフィールド精度の達成、および時間、計算、またはデータサイズのバジェットの枯渇を含む。オペレーション7011において、メディエルによって範囲を定められていないクエリサブセルは、オペレーション7001にフィードバックされ、プロセス7000の次の反復(末尾再帰)を効果的に呼び出す。
【0302】
図71は、一実施形態において、クエリセイエルに光を与える単一のメディエルおよびそのラディエルを蓄積するプロセス7100の流れ図であり、「蓄積する」は、プロセス7000を参照しつつ上で与えられた意味を有する。オペレーション7101において、メディエルそれ自体が蓄積される。オペレーション7103において、プロセス7100は、メディエルの出力ラディエルのうちのどれがクエリセイエルに寄与するかを決定する。これは、典型的には、セイエルを含むラディエルがクエリセイエルとプレノプティックに重なるかどうか、すなわち、クエリセイエルおよびラディエルのセイエルが各々他方の原点を含むかどうかによって決定される。オペレーション7105において、プロセス7100は、寄与する出力ラディエルが、メディエルのライトフィールドに、7100を呼び出した呼び出しプロセス(たとえば、次にこの例におけるプロセス6900からその目標精度要件を得る、プロセス7000)によって指定された精度で、すでに収められているかどうかをチェックする。オペレーション7105が肯定的な答えをもたらす場合、プロセス7100は、オペレーション7115でそれらのラディエルを蓄積することへ進む。オペレーション7105が否定的な答えをもたらす場合、プロセス7100は、オペレーション7107で入力されたラディエルの必要な集合を決定することへ進む。この決定は、メディエルのBLIFの影響を大きく受ける。たとえば、狭いスペキュラーローブを有するBLIFは、入射ラディエルのより高い精度/分解能が入射スペキュラーローブの方向に必要であることを示す。より広いローブは、必要とされる入射ラディエルの精度のより等方的な分布を示している。
【0303】
本明細書のコンテキストにおいて、「出力」ラディエルは、クエリセイエルに向かって下流に向けられたラディエルであり、「入力」ラディエルは、上流に向けられたラディエルである。メディエルの場合、入力ラディエルおよび出力ラディエルは、そのBLIFマッピングの反対側にある。クエリセイエルが空気に接する不透明なサーフェルに到達する例示的な場合において、出力ラディエルはサーフェルから出射するが、入力ラディエルはサーフェルに入射する。クエリセイエルが透過性メディエル内から起こる例示的な場合において(たとえば、ガラスの塊の内部からの画像を生成する)、出力ラディエルはメディエルに入射し、入力ラディエルはメディエルから出射する。
【0304】
オペレーション7109において、プロセス7100は、必要とされる入力ラディエルがすでに(必要とされる精度で)メディエルのライトフィールドに収められているかどうかをチェックする。もしそうであれば、各寄与出力ラディエルは、オペレーション7113において、入力ラディエルにメディエルのBLIFを適用することによって計算される。そうでない場合、プロセス7100は、プロセス7000を(多くの場合、再帰的に)呼び出し、オペレーション7009において、シーン内に、要求された各入力ラディエルに対するクエリセイエルを投影する。制御が、7000への潜在的に深く再帰的な呼び出しから戻った後、フローは、7109の肯定分岐と同様にオペレーション7113に進む。オペレーション7113においてメディエルのBLIFを適用することによって寄与出力ラディエルを計算した後、プロセス7100は、次いで、7105の肯定分岐と同様に、オペレーション7115で出力ラディエルを蓄積する。プロセス7100は、7115で蓄積の後に終了する。オペレーション7113は、いくつかの例示的な実施形態において、必要な場合にメディエルのBLIFを推定するか、または精緻化するためにシーンソルバー(再構築)プロセスを呼び出すことが可能であることに留意されたい。これについては、ここでさらに詳細に説明しない。
【0305】
プロセス7000および7100の非常に多くのインスタンス(呼び出し)は、適切な実施形態において並列に進行することができ、たとえば、多数のディスクリートロジックコアを有するFPGAコンピューティングファブリックを含む。並列性の程度にかかわらず、プロセス7000において連続クエリセイエルが投影されると再帰はより浅くなる傾向がある。この傾向は、各クエリセイエルの投影が一般的にオペレーション7113および7115において入射および応答ラディエルの計算および保存(キャッシングとして潜在的に実装される)をもたらすので存在する。したがって、後のクエリセイエルによるプロセス7100の呼び出しにおいて、7105および7109の肯定分岐はより頻繁に続くことになり、より浅い再帰をもたらす。プロセス6900のコンテキストにおいて、再帰的セイエル投影の連鎖(スタック)のこの深-浅シーケンスは、サブシーンのプレノプティックフィールドにおける準定常状態のライトフィールドのかなり高速な計算と考えることができる。また、サブシーンライトフィールド情報のこの埋め込みは、いくつかの実施形態において、上流および下流の両方向で進行し有益である。たとえば、知られている(または発見された)強力な光源からの光は、重いセイエルクエリ活動を体験するようなシーン領域へ下流に輸送され得る。これは、上流に向けられたクエリセイエルが注目する領域に到達する前に起こり、到達した後は、より浅い再帰深度をもたらすであろう。また、プロセス7000および7100の様々なオペレーションは、たとえば、ハードウェアアクセラレーションリソースが利用可能になったときに後で処理するためにリストに入れておく延期方式で実行され得ることにも留意されたい。
【0306】
図69を参照して上で説明したプレノプティックフィールド表現の正準形式に関して、シーンモデルが、所望の正準度を達成するために必要な十分に正確なマターフィールドおよびBLIF情報を欠いているときに、シーンコーデック1A01を使用するシステムは、一般的に、必要なマターフィールド情報を供給するために、たとえば、マターフィールドを高い精度で解決するという指定目標により、シーンソルバー1A05を呼び出すことができる。いくつかの例示的な実施形態において、シーンコーデック1A01を使用するシステムは、特にサーバとして動作するときに、新しいライトフィールドデータが供給されるときに(たとえば、カメラを備えるクライアントシステムからの新しい画像)、ライトフィールド情報がサーバのシーンデータベース内の適切なプレノプティックフィールドへのマターフィールド表現に速やかに伝搬されるようにソルバー1A05を継続的に実行することも可能である。
【0307】
一実施形態におけるサブシーン挿入オペレーションに関して、サブシーン挿入器モジュール6711は、シーン表現のプレノプティック八分木レベルで(入ってくるサブシーンが挿入されるプレノプティック八分木のローカル部分木を修正することによって)サブシーン挿入を処理する。シーンモデル1001およびシーンデータベース1101レベルの表現において、サブシーン挿入(インクリメンタルサブシーン挿入を含む)は、プレノプティックフィールドのマージ、シーングラフのマージ、特徴-プリミティブマッピングの変更(特徴のセグメントおよびオブジェクトサブタイプを含む)、およびBLIFライブラリのマージを含むオペレーションも伴い得る。いくつかの例示的なユースケースにおいて、プレノプティックフィールドのマージは、マージされたプレノプティックフィールドの注目する領域における準定常状態ライトフィールドの、プロセス7000および7100を使用する、再計算をトリガーし得る。
【0308】
本明細書の特定の実施形態の別の新規性のある態様は、「分析ポータル」である。これは、プレノプティックシーンモデルのレンダリングをもたらす表現およびプロセスの詳細の視覚的提示を提供するメカニズムである。そのようなポータルは、また、プレノプティックシーンおよびレンダリングの要素およびパラメータを追加、除去、変更、または編集するために使用され得る。ポータルは、どのような形状であってもよい。たとえば、長方形の2D窓は、ポータルの「後ろ」にあるすべてのものの詳細を表示するように描画され得る。また、調査される体積空間を制限する3D内の領域であってもよい。これは、視認性を高め、理解を深めるために、2D窓と組み合わせることができる。このようなポータルは、必要に応じてインタラクティブに修正することができる(たとえば、拡大、回転)。それに加えて、ビューアは、ポータルに関して移動することができる。たとえば、ポータルを通じて「飛ぶ」ことができ、次いで、ポータルドメイン内を動き回り、そこから分析シーンを見ることができる。分析ポータルは、また、使用のきっかけとなる何らかの状況または事象の発生を強調するために自動的に生成され得るという点でもスマートであり得る。この方式で複数のポータルが作成され、おそらくは理解を深められるように視覚的または他の仕方でリンクされ得る。
【0309】
分析ポータルは、図8のキッチンである図72の画像に例示されている。これは、小さな長方形の領域7202を有するキッチン画像を示している。図73は、キッチンの拡大画像を示している。長方形は、ストーブの近くのカウンター上に置かれている金属製の鍋の底の一部を囲んでいるようにより明確に見える。この中には、分析ポート7304のビューがある。これは、個々のプリミティブ要素が大きく拡大されて示されている3D長方形領域である。マターフィールドおよびライトフィールドの表現、ならびに結果として画像をもたらすそれらの相互作用は複雑であり、画像それ自体から直接分析し理解することは難しい。シーン要素のタイプおよび表示特性(たとえば、スケール係数)、ならびに要素がどのようにレンダリングされるか(たとえば、ワイヤーフレーム対シェード)を指定することによって、表示される情報は、ビューアの即時の必要性に合わせて手直しすることができる。
【0310】
領域7302内の分析ポータル7304は、図74に示されている。分析ポータルは、鍋の表面7404とカウンターの表面7405との3次元長方形領域の交点を示す黒色エッジによって示されている。鍋を表すボクセル7406および大理石のカウンターを表すボクセル7408などの、スケールアップされた個々のボクセルが見える。この場合、これらはワイヤーフレームの立方体として示されている。カウンターの一部を表すサーフェル7410などのボクセルに含まれるサーフェルが示されている。また、サーフェルのいくつかの上の代表的な点が小さい白色の球体として図示され、これは表面上のその点でローカル法線ベクトルの方向に延在する。点7412は一例である。
【0311】
分析ポータルを使用することで、現実的なシーンレンダリングにおける視覚的特徴または異常を結果としてもたらす表現およびメカニズムの理解を深めることができる。しかし、これらは、相互作用して画像を生成するマターフィールドおよびライトフィールドの要素を表示することを越える、多くのアプリケーションをサポートすることも可能である。これは、動的シーンおよび関連する物理学ならびに制御パラメータの修正の結果についての理解を深めることも含む。これは、研究および教育学上の利用、さらにはその先へと広がることであろう。
【0312】
図75、図76、および図77は、高非ランバート表面のマターフィールドおよびライトフィールドを表現し再構築する際のいくつかの実施形態の有用性を実証するために、例示的な実施形態によって生成された経験的データを示している。図75および図76の場合において、実施形態は、浅い人工的な凹みを含む黒色表面および白色表面を再構築した。再構築された3D表面形状は、最先端の光学3Dデジタイザによって実行された参照再構築と有利に比較される。図77の場合、実施形態は、自然な雹による凹みを含むいくつかの車体パネルを再構築した。再構築結果は、一般的に、専門検査機器を使用して訓練を受けた検査員によって評価された凹みの配置およびサイズと一致している。これらの経験的結果は、従来の写真測量法を使用してそのような領域を再構築する際に必要とされるような高非ランバートであり、厳密に局在化された外観特徴を欠いている表面領域に対する有用で正確なオペレーションを実証している。本アプローチを使用して表現可能で再構築可能なシーンの他の特性は、表面の凹み、高い自己遮蔽、近接している複数の媒体タイプ、金属媒体、透過性媒体(ガラスを含む)、投影、光源の明るい反射、移動物体、および媒体の異質集合体を含む環境全体を含む。
【0313】
図75を参照すると、4個の浅い凹みが、アルミニウム試験パネルの領域7501内に人為的に導入されている。この領域は、その後、黒く塗装された。小さな点注釈7502は、凹みの1つの中心位置を示している。本アプローチの評価のための信頼できる参照再構築を作成するために、防眩スプレーパウダーが未塗装パネルに塗布され、次いで、計量グレードの光学3Dデジタイザ、GOM ATOS Triple Scan IIIでスキャンされた。
【0314】
リファレンススキャンが完了した後、防眩パウダーを除去し、黒色スプレー塗料を薄く3回塗った。これは、低拡散反射率(たとえば、1%未満)の表面の、実施形態による再構築を実証するために行われた。黒色塗装パネルが三脚に取り付けられ、パネルの中心からおおよそ0.5メートルの平均距離のところで偏光カメラ(たとえばPX 3200-R)の12個の内向き視点から撮像された。内向きの視点に加えて、周囲環境の86枚の追加の外向き画像が記録された。これは、凹み領域に入射するライトフィールドをサンプリングして再構築するために行われた。7511は、内向き画像(頂部2)および外向き画像(底部2)の部分集合である。本アプローチを使用することで、半球状の入射ライトフィールドが、凹み領域内の表面配置、たとえば7502のところで再構築された。再構築されたライトフィールド(入射および出射)の定量化された特性は、入射光の半球内の各ラディエルのラジオメトリックパワー、偏光状態、およびスペクトル情報を含んでいた。例示的な実施形態において、パネル表面のBLIFは、凹み領域の3D形状外形を発見するために使用された。
【0315】
例示的な実施形態において、本アプローチは、C++およびMATLAB(登録商標)ソフトウェア実装環境を組み合わせて実現された。再構築された表面の空間的に低周波数バージョンは、より高い周波数の凹み幾何学的形状を大きくフィルタ処理して取り除くことを意図して計算された。次いで、この低周波数表面は、凹みがない場合に存在する表面である「公称」表面の推定値として使用される。公称表面は、詳細な再構築から差し引かれ、公称表面に対する各表面配置の凹み深さを示す2D凹みマップが得られた。
【0316】
図75を参照すると、3D表面プロット7521は、本アプローチの例示的な実施形態によって生成された凹み領域再構築と、最先端の光学3Dデジタイザによって生成された再構築との比較である。各再構築の平均凹み値をその凹みマップから減算することによって、単純な垂直アライメントが実行された。2つの凹みマップ間のRMS偏差は約21ミクロンである。2Dプロット7531は、4つの再構築された凹みのうちの1つを通る凹み値の断面図である。凹み断面の間のRMS偏差は約8ミクロンである。この例示的な実施形態における、本アプローチは、このようにして、最新の計測グレードの光学3Dデジタイザとほぼ同等の3D表面形状精度をもたらすことがわかった。
【0317】
図76を参照すると、黒色の凹み領域の再構築作業の後、凹み領域7601に白色塗料を3回薄く塗ったことがわかる。これは、黒く塗られた場合と比較して、かなり高い拡散反射率(たとえば、>20%)を有する表面上での本アプローチによる再構築を実証するために行われた。シーン再構築のアプローチで偏光特性が使用されるときに、白い表面の場合は、より暗い外観の表面に比べて反射光をあまり強く偏光させない傾向があるので特に目立つ。白色領域の再構築シナリオの撮像および再構築プロセスは、すべての重要な点で黒色領域で使用されたプロセスと類似していた。3D表面プロット7611で可視化された比較は、約45ミクロンのRMS偏差を有する。より大きな精度は、実施形態では、シーンモデルパラメータ、ライトフィールド要素、カメラ補正、およびシーン内の媒体の光学的相互作用パラメータにおける系統的誤差を低減することによって達成可能である。
【0318】
黒い凹みおよび白い凹みの再構築の精度は、4個の凹みを含む体積シーン領域がX、Y、およびZ方向に約50ミリメートル延在しているので、1000分の1の部分(よりよい)として相対的な用語で表現され得る。絶対RMS偏差を、再構築された領域の直線的な広がりで割ると、相対RMS偏差を示す比率が得られる。以下の表は,黒い凹みと白い凹みの再構築の場合に対する経験的データを含む。
【0319】
【表1】
【0320】
図77を参照すると、合計数量17の、車体パネル7701および追加のパネルが準備され、明るいライトフィールド7711内に配置され、偏光カメラを使用して撮像された。ライトフィールド7711は、照明の任意の正確な構造または分布を有するように設計されていなかった。その主目的は、暗い表面仕上げを有するパネルを撮像する際に、非常に長いカメラ露光時間を避けることができるような十分な光量を提供することであった。パネルの撮像された集合は、拡散反射と偏光挙動の両極端にある黒色と白色とを含む塗装色の範囲にわたっている。撮像は、試験パネルの撮像シナリオを参照して上で説明されているように、内向きカメラ視点および外向きカメラ視点を含んでいた。
【0321】
例示的な実施形態における撮像オペレーションに続いて、各パネルは、車両の雹害評価について専門的に訓練された検査員によって検査され、注釈7721が付けられた。検査員が業界標準検査ランプおよび他の機器を使用して判断した様々な大きさの凹みを示すために、異なる色のステッカーがパネルに貼られた。各パネル表面領域は、本アプローチを用いて再構築され、より大きなコード化された光学的ターゲット(四角いステッカー)の助けを借りて、検査員の物理的な注釈と共通7731の空間的な参照フレーム内で解決された。再構築された凹みマップは、検査員の注釈と突き合わせて比較され7741、その結果が以下の表にまとめられている。
【0322】
【表2】
【0323】
図78は、画像生成を目的とするサブシーン抽出の例示的な場合7800を示す。抽出の目的は、サーフェルを保持する比較的粗いボクセル、ならびにさらに太陽および近い空からの光を表す窓ライトフィールドを保持する境界ボクセルとともに示されている、描写されているシーンモデルの画像をヘッドマウントディスプレイ7805の画面で再現することを可能にするサブシーンを伝送することである。ディスプレイ7805の最上段のピクセル7801は、表現された太陽の窓ライトフィールドから直接日光を受ける。ディスプレイ7805の中段のピクセル7803は、図示されている地上のサーフェルから反射された日光を受ける。サブシーン抽出中のプロセス6900、7000、および7100において、2つのピクセル7801および7803を覆う1つまたは複数のクエリセイエルは、図示されている両方の光輸送経路に遭遇する。中間のピクセル7803がたまたま頂部ピクセル7801よりも早くクエリをトリガーした場合、窓ライトフィールドの中の日光を表す境界メディエルに、2つのプレノプティック投影の間接的な連鎖を介して到達する可能性がある。その代わりに、頂部ピクセル7801が中間ピクセル7803よりも早くクエリをトリガーした場合、その同じ境界ボクセルは、ピクセル7801から境界ボクセルへの単一の投影を介して直接到達し得る。シーンが(シーンモデルの「正準」形式に関係する)地上サーフェルに対する十分に正確なBLIF情報を含んでいた場合、同じピクセル内容は、クエリセイエル処理の順序に関係なく結果をもたらす。
【0324】
本明細書において説明されている例において、説明を目的として、限定はしないが、説明されている技術の理解を促すために、特定のノード、機能的エンティティ、技術、プロトコル、標準などの特定の詳細が記載されている。当業者には、他の実施形態が以下で説明されている特定の詳細を別にして実施され得ることは明らかであろう。他の場合には、不必要な詳細で説明を曖昧にしないように、よく知られている方法、デバイス、技術などの詳細な説明は省略されている。個々の機能ブロックが図示されている。当業者であれば、それらのブロックの機能は、個別のハードウェア回路を使用して、適切にプログラムされたマイクロプロセッサまたは汎用コンピュータと連携してソフトウェアプログラム命令およびデータを使用して、特定用途向け集積回路(ASIC)を使用して、および/または1つもしくは複数のデジタルシグナルプロセッサ(DSP)を使用して、実装され得ることを理解するであろう。ソフトウェアプログラム命令およびデータは、コンピュータ可読記憶媒体に記憶されていてもよく、命令がコンピュータまたは他の好適なプロセッサ制御によって実行されたときに、コンピュータまたはプロセッサがそれらの機能を実行する。データベースは、本明細書ではテーブルとして示されている場合があるけれども、データを記憶し、操作するために、他の形式(リレーショナルデータベース、オブジェクトベースモデル、および/または分散データベースを含む)が使用されてもよい。
【0325】
プロセスステップ、アルゴリズム、または同様のものは、特定の順序で説明されるか、または請求され得るけれども、そのようなプロセスは、異なる順序で働くようにも構成され得る。言い換えれば、明示的に説明または請求され得るステップの任意のシーケンスまたは順序は、必ずしもステップがその順序で実行されることの要件であることを示すものではない。本明細書において説明されているプロセスのステップは、可能な任意の順序で実行され得る。さらに、いくつかのステップは、同時でなく生じると説明されるか、または暗示されるにも関わらず同時に実行されてもよい(たとえば、一方のステップは他方のステップの後に記述されるので)。さらに、図面内の指示によるプロセスの例示は、例示されているプロセスが他の変更形態および修正形態を除くことを暗示せず、例示されているプロセスまたはそのステップのいずれも技術に必要であることを暗示せず、例示されているプロセスが好ましいことを暗示しない。
【0326】
上述のプロセッサ、メモリ、ネットワークインターフェース、I/Oインターフェース、およびディスプレイは、コンピューティングデバイスのための様々な異なる機能を実行するように構成されているハードウェアデバイス(たとえば、電子回路または回路の組合せ)であるか、またはそれらを含む。
【0327】
いくつかの実施形態において、プロセッサの各々またはいずれかは、たとえば、シングルもしくはマルチコアプロセッサ、マイクロプロセッサ(たとえば、中央演算処理装置もしくはCPUと称され得る)、デジタルシグナルプロセッサ(DSP)、DSPコアと関連するマイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、またはシステムオンチップ(SOC)(たとえば、CPUおよびメモリ、ネットワーキングインターフェース、および同様のものなどの他のハードウェアコンポーネントを含む集積回路)であるか、またはそれらを含む。および/またはいくつかの実施形態において、これらのプロセッサ604のうちの各々またはいずれかは、x86またはAdvanced RISC Machine(ARM)などの命令セットアーキテクチャを使用する。
【0328】
いくつかの実施形態では、メモリデバイスの各々またはいずれかは、ランダムアクセスメモリ(RAM)(ダイナミックRAM(DRAM)またはスタティックRAM(SRAM)など)、フラッシュメモリ(たとえば、NANDもしくはNOR技術に基づく)、ハードディスク、光磁気媒体、光媒体、キャッシュメモリ、レジスタ(たとえば、命令を保持する)、またはデータおよび/もしくは命令(たとえば、プロセッサ上でもしくはプロセッサによって実行されるソフトウェア)の不揮発性もしくは不揮発性記憶装置への記憶を実行する他のタイプのデバイスであるか、またはそれらを含む。メモリデバイスは、不揮発性コンピュータ可読記憶媒体の例である。
【0329】
いくつかの実施形態において、ネットワークインターフェースデバイスの各々またはいずれかは、1つまたは複数の回路(ベースバンドプロセッサおよび/または有線もしくは無線トランシーバなど)を含み、1つまたは複数の有線通信技術(たとえば、イーサネット(IEEE802.3)および/または無線通信技術(Bluetooth、WiFi(IEEE 802.11)、GSM、CDMA2000、UMTS、LTE、LTE-Advanced(LTE-A)、および/または他の短距離、中距離、および/または長距離無線通信技術など)のための第1層、第2層、および/または上位層を実装する。トランシーバは、送信機および受信機のための回路を備え得る。送信機および受信機は、共通のハウジングを共有してもよく、送信および受信を実行するためにハウジング内に回路の一部または全部を共有してもよい。いくつかの実施形態において、トランシーバの送信機および受信機は、共通の回路を共有していなくてもよく、および/または同じハウジングまたは別個のハウジング内にあってもよい。
【0330】
いくつかの実施形態において、IOインターフェースにおけるディスプレイインターフェースの各々またはいずれかは、プロセッサ104からデータを受信し、受信したデータに基づき(たとえば、ディスクリートGPU、集積化GPU、グラフィカル処理を実行するCPU、もしくは同様のものを介して)対応する画像データを生成し、および/または(たとえば。高品位マルチメディアインターフェース(HDMI(登録商標))、DisplayPortインターフェース、ビデオグラフィックスアレイ(VGA)インターフェース、デジタルビデオインターフェース(DVI)、または同様のもの)生成された画像データを表示デバイスに出力し、画像データを表示する1つまたは複数の回路であるか、またはそれらを含む。代替的に、またはそれに加えて、いくつかの実施形態において、ディスプレイインターフェースの各々またはいずれかは、たとえば、ビデオカード、ビデオアダプタ、またはグラフィックスプロセッシングユニット(GPU)であるか、またはそれらを含む。
【0331】
いくつかの実施形態において、I/Oインターフェースのユーザ入力アダプタの各々またはいずれかは、コンピューティングデバイスに含まれるか、コンピューティングデバイスに取り付けられるか、または他の何らかの形でコンピューティングデバイスと通信している1つまたは複数のユーザ入力デバイスからユーザ入力データを受信して処理し、受信した入力データに基づきデータをプロセッサに出力する1つまたは複数の回路であるか、またはそれらを含む。代替的に、またはそれに加えて、いくつかの実施形態において、ユーザ入力アダプタの各々またはいずれかは、たとえば、PS/2インターフェース、USBインターフェース、タッチスクリーンコントローラ、または同様のものであるか、またはそれらを含み、および/またはユーザ入力アダプタは、たとえば、キーボード、マウス、トラックパッド、タッチスクリーンなどのユーザ入力デバイスからの入力を円滑にする。
【0332】
様々な形態のコンピュータ可読媒体/伝送は、データ(たとえば、命令のシーケンス)をプロセッサに搬送することに関与し得る。たとえば、データは、(i)メモリからプロセッサに送出され、(ii)任意のタイプの伝送媒体(たとえば、有線、ワイヤレス、光など)を介して搬送され、(iii)イーサネット(またはIEEE802.3)、ATP、Bluetooth、およびTCP/IP、TDMA、CDMA、3Gなどの多数の形式、標準、またはプロトコルに従ってフォーマットされ、および/または伝送され、および/または(iv)当技術分野でよく知られている様々な仕方のいずれかでプライバシーを確保するか、または不正行為を防止するために暗号化されるものとしてよい。
【0333】
本明細書で使用されているように、システム、サブシステム、サービス、プログラムされた論理回路、または同様の用語は、ソフトウェア、ハードウェア、ファームウェア、および/または同様のものの好適な任意の組合せとして実装され得ることが理解されるであろう。また、本明細書における記憶装置ロケーションは、ディスクドライブデバイス、メモリロケーション、ソリッドステートドライブ、CD-ROM、DVD、テープバックアップ、ストレージエリアネットワーク(SAN)システム、および/または他の適切な有形のコンピュータ可読記憶媒体の好適な任意の組合せであってよいことも理解されるであろう。また、本明細書で説明されている技術は、コンピュータ可読記憶媒体上に有形なものとして記憶され得るプロセッサ実行命令を有することによって達成され得ることも理解されるであろう。
【0334】
本明細書において使用されているように、「非一時的コンピュータ可読記憶媒体」という用語は、レジスタ、キャッシュメモリ、ROM、半導体メモリデバイス(たとえば、D-RAM、S-RAM、または他のRAM)、フラッシュメモリ、ハードディスク、磁気光学媒体などの磁気媒体、CD-ROM、DVD、もしくはブルーレイディスクのような光学媒体、または非一時的電子データストレージの他のタイプのデバイスを含む。「非一時的コンピュータ可読記憶媒体」という用語には、一時的な伝搬する電磁信号を含まない。
【0335】
本明細書において、アクションが実行「され得る」、「できる」、「されてもよい」、または「される可能性がある」、所与のコンテキストに特徴またはコンポーネントが含まれるか、または適用可能であることが「あり得る」、「できる」、「あってもよい」、または「可能性がある」、所与の項目が所与の属性を「有し得る」、「有してもよい」、「有することができる」、または「有する可能性がある」ことが説明されているとき、または「し得る」、「してもよい」、「できる」、または「可能性がある」という言い回しを伴う類似の語句が使用される場合には必ず、所与のアクション、特徴、コンポーネント、属性などは、少なくとも1つの実施形態において存在するが、必ずしもすべての実施形態に存在するわけではないことは理解されるべきである。
【0336】
本発明は、最も実用的で、好ましい実施形態であると現在考えられているものに関して説明されているが、本発明は、開示されている実施形態に限定されず、却って、付属の請求項の精神および範囲内に含まれるさまざまな修正形態および同等の配置構成を対象とすることを意図されていることが理解されることになる。
【符号の説明】
【0337】
0,1,2,3 子
1A01 システム
1A03 アプリケーションソフトウェア
1A05 シーンソルバー
1A07 プレノプティックシーンデータベース
1A09 空間処理ユニット(SPU)
1A11 シーンコーデック
1A13 要求コントローラ
1A15 シーンデータパケット
1A17 制御パケット
1B11a エンコーダ
1B11b デコーダ
1E01 ネットワーク
1E03 トランスポート層
1F05 パケットマネージャ
1E09 センサ
1E11 センサ出力
1F01 アプリケーションインターフェース(API)コール
1F03 APIインターフェース
1F05 パケットマネージャ
1F07 クライアント状態
1F09 クエリプロセッサ
1F11 サブシーン抽出器
1F13 コーデックSPU
1F15 非プレノプティックデータ制御
1F17 非プレノプティックデータエンコーダ
1F19 シーンデータ
1G01 クエリプロセッサ
1G03 サブシーン挿入器
1G07 シーンデータデータベース
1G11 ユーザ要求
2B01 現実世界のシーン
2B05-1および2B05-2 実カメラ
2B07 シーンデータ
2B09 マターフィールド
2B11 ライトフィールド
2B13 シーンストリーム
2B17 ユーザ
2B19 2π～4πフリービューディスプレイ
4A01 現実世界のシーン
4A03 不透明オブジェクト
4A05 微細構造化オブジェクト
4A07 遠方オブジェクト
4A09 放射オブジェクト
4A11 高反射オブジェクト
4A13 無特徴オブジェクト
4A15 部分的透過オブジェクト
4A17 現実世界の表現画像
4B01 シーンモデル
4B03 外側シーン境界
4B05 窓光要素
4B07 プレノプティックフィールド
4B09 説明されているオブジェクト
4B11 説明されていない領域
4B13 実画像
4C09 シーンモデル
4C11 プレノプティックフィールド
4C13 オブジェクト
4C15 セグメント
4C17 BLIF
4C19 特徴
4C21 要素
4C23 モデル拡張
4C25 モデル翻訳
4C27 モデルインデックス
4C29 モデル使用履歴
501 クライアントUI
501a グローバル注目シーン(SOI)
501b グローバルSOIオペレーション
505,507,509,513a,513b,513c,513d,517 オペレーション
513 プロセスクライアント要求オペレーション
515 ログ消費オペレーション
604 プロセッサ
901 ボクセル
903 立体角要素
1001 シーンモデル
1003 プレノプティックフィールド
1005 外側シーン境界
1007および1009 内側境界
1011 カメラ経路
1013 焦点面
1019 オブジェクト
1023および1025 セグメント
1027 特徴
1101 シーンデータベース
1103 シーンモデル
1115 シーングラフ
1107 特徴
1105 プレノブティックフィールド
1109 セグメント
1111 オブジェクト
1113 カメラ経路
1119 BLIFライブラリ
1121 アクティビティログ
1123 カメラキャリブレーション
1125 材料サブライブラリ
1127 粗さサブライブラリ
1129,1131 ログ
1200 クラス図
1201 ルートプレノプティックプリミティブ
1203 メディエル
1205 ラディエル
1209 同質メディエル
1211 異質メディエル
1213 等方性ラディエル
1215 異方性ラディエル
1219 メディエル
1221 分割ラディエル
1223 滑らかに変化するラディエル
1225 サーフェル
1227 単純サーフェル
1229 分割サーフェル
1302,1304 点
1401,2001 光立方体
2002 入射光素子(ラディエル)
2101 体積八分木
2103 ルートノード
2105,2107 ノード
2203 ユニバース
2205 ボクセル
2207 立方体空間
2301 セイエル木
2303 ルートノード
2305,2307,2309 ノード
2403 周囲立方体
2405 面
2407,2409 面正方形
2501 プレノプティック八分木
2502 ボクセル
2503 セイエル
2505 ボクセル
2600 プレノプティック八分木
2601 SLT A
2602 点
2603 セイエル
2604 SLT B
2606 セイエル
2607 SLT C
2608 セイエル
2710 VLOボクセル
2811,2806 入射セイエル
2810 入射SLT D
2910 出射SLT D
3001 SPU
3003 オペレーションモジュール
3005 幾何学的形状モジュール
3007 形状変換モジュール
3009 画像生成モジュール
3011 空間フィルタ処理モジュール
3013 表面抽出モジュール
3015 モルフォロジーオペレーションモジュール
3017 接続性モジュール
3019 質量プロパティモジュール
3021 登録モジュール
3023 ライトフィールドオペレーションモジュール
3101 位置不変ライトフィールド生成モジュール
3103 出射ライトフィールド生成モジュール
3105 出射/入射ライトフィールド処理モジュール
3107 入射/出射ライトフィールド処理モジュール
3200 面0
3201 面1
3202 面2
3203 面3
3204 面4
3205 面5
3300 4分の1面0
3301 4分の1面#1
3302 4分の1面2
3303 4分の1面3
3210 周囲立方体
3601 光線
3602 SLT原点
3603 投影平面
3604 交点
3605 原点
3607 セイエル面
3608 交点
3701 VLOノード
3702 点
3703 レベル1ノード中心
3704 光線
3706 投影面
3707 投影面
3709 交点
3710 ex
3711 ex
3712 e'x
3713 e'y
3708 交点
3801 レベル1のVLOノード
3802,3803 投影面
3804 中心
3805 点
3806 元のセイエルエッジ線交点
3807 交点
3901 レベル1ノード
3902 セイエル
3904 「頂部」エッジ
3905 「底部」エッジ
3906 投影面
3907 点
3909 点t
3910 点b
4001 レベル1のVLOノード
4002 セイエル
4004 投影面
4006 b'y
4100 セイエル木
4101 点
4102 ノード
4103 方向空間
4104 レベルn+1ノード
4105 セイエル木
4106 ノード
4107 領域
4201 レベル1のVLOノード
4203 原点
4204 頂部点t
4205 底部点b
4206 点
4301,4302 VLOノード
4303 出射セイエル
4305 入射セイエル木
4307 原点-原点セグメント
4401 VLOノード
4404 領域
4405 底部エッジ限界
4406 頂部エッジ限界
4407 エッジ
4408 シーケンス0から3
4501 VLOノード
4502 セイエル
4504 四分木
4602 エッジ
4603 半空間
4604 エッジ
4605 上側半空間
4606 半空間
4701 上位レベルVLOノード
4702 セイエル
4703 ノードA
4704 ノードB
4705 ノードC
4802 ノード
4803 VLO中心点
4804,4805 セイエル
4901 点t(tx,ty)
4902 投影面
4903 点b(bx,by)
4904 中心点
4905 dx
4906 dy
5004 頂部点t'
5005 頂部エッジ
5006 dt'
5007 「c」
5009 「a」
5010 dt
5011 「e」
5101 上側レジスタ
5102 下側レジスタ
5103 Delta_U
5104 Delta_L
5105 VLO_Edge
5106 SLT_Edgee
5109 VLO細分信号
5214 V_Delta_U
5215 V_Delta_L
5203 S_Delta_U
5204 S_Delta_L
5602 頂部セイエル
5603 ユニバース
5610 象限子番号付け
5611 サブセイエル番号付け
5701 VLOノード
5702 セイエル
5703 点
5704 底部エッジ
5705 頂部エッジ
5706 原点
5707 投影面
5801 ノード
5802 セイエル
5803 点
5804 底部エッジ
5805 頂部エッジ
5807 投影面
5901 VLOノード
5902 セイエル
5906 点
5907 投影面
6002 セイエル
6004 底部エッジ
6005 頂部エッジ
6007 投影平面
6302 セイエル
6601 基本コーデックAPI
6603 動作パラメータモジュール
6605 コーデックAPI確立リンクモジュール
6607 APIオープンシーンモジュール
6609 リモートシーンアクセスモジュール
6611 ローカルシーンアクセスモジュール
6613 クエリプロセッサモジュール
6615 セッションログモジュール
6703 ステータス&プロパティクエリモジュール
6705 プランサブシーンマスクモジュール
6707 サブシーンマスク生成器
6709 サブシーン抽出モジュール
6711 サブシーン挿入器モジュール
68A02,68A04,68A06,68A08,68A12,68A18,68A22,68A24,68A26,68A30,68B06,68B12,6901,6905,6907,6909,6911,6913,6915,6917,7001,7005,7007,7009,7011,7101,7103,7105,7107,7109,7113,7115 オペレーション
68A10,68A14,68A16,68A20,68B10,68B14 決定オペレーション
68A28 決定
68B02 初期ステップ
68B04 ステップ
6900,7000,7100 プロセス
7202 小さな長方形の領域
7304 分析ポート
7404 鍋の表面
7405 カウンターの表面
7406,7408 ボクセル
7410 サーフェル
7501 領域
7502 小さな点注釈
7521,7611 3D表面プロット
7531 2Dプロット
7601 凹み領域
7701 車体パネル
7711 明るいライトフィールド
7721 注釈
7731 共通
7800 場合
7801,7803 ピクセル
7805 ヘッドマウントディスプレイ
1A01 システム
1A03 アプリケーションソフトウェア
1A05 シーンソルバー
1A07 プレノプティックシーンデータベース
1A09 空間処理ユニット(SPU)
1A11 シーンコーデック
1A13 要求コントローラ
1A15 シーンデータパケット
1A17 制御パケット
1B11a エンコーダ
1B11b デコーダ
1E01 ネットワーク
1E03 トランスポート層
1F05 パケットマネージャ
1E09 センサ
1E11 センサ出力
1F01 アプリケーションインターフェース(API)コール
1F03 APIインターフェース
1F05 パケットマネージャ
1F07 クライアント状態
1F09 クエリプロセッサ
1F11 サブシーン抽出器
1F13 コーデックSPU
1F15 非プレノプティックデータ制御
1F17 非プレノプティックデータエンコーダ
1F19 シーンデータ
1G01 クエリプロセッサ
1G03 サブシーン挿入器
1G07 シーンデータデータベース
1G11 ユーザ要求
2B01 現実世界のシーン
2B05-1および2B05-2 実カメラ
2B07 シーンデータ
2B09 マターフィールド
2B11 ライトフィールド
2B13 シーンストリーム
2B17 ユーザ
2B19 2π～4πフリービューディスプレイ
4A01 現実世界のシーン
4A03 不透明オブジェクト
4A05 微細構造化オブジェクト
4A07 遠方オブジェクト
4A09 放射オブジェクト
4A11 高反射オブジェクト
4A13 無特徴オブジェクト
4A15 部分的透過オブジェクト
4A17 現実世界の表現画像
4B01 シーンモデル
4B03 外側シーン境界
4B05 窓光要素
4B07 プレノプティックフィールド
4B09 説明されているオブジェクト
4B11 説明されていない領域
4B13 実画像
4C09 シーンモデル
4C11 プレノプティックフィールド
4C13 オブジェクト
4C15 セグメント
4C17 BLIF
4C19 特徴
4C21 要素
4C23 モデル拡張
4C25 モデル翻訳
4C27 モデルインデックス
4C29 モデル使用履歴
501 クライアントUI
501a グローバル注目シーン(SOI)
501b グローバルSOIオペレーション
505,507,509,513a,513b,513c,513d,517 オペレーション
513 プロセスクライアント要求オペレーション
515 ログ消費オペレーション
604 プロセッサ
901 ボクセル
903 立体角要素
1001 シーンモデル
1003 プレノプティックフィールド
1005 外側シーン境界
1007および1009 内側境界
1011 カメラ経路
1013 焦点面
1019 オブジェクト
1023および1025 セグメント
1027 特徴
1101 シーンデータベース
1103 シーンモデル
1115 シーングラフ
1107 特徴
1105 プレノブティックフィールド
1109 セグメント
1111 オブジェクト
1113 カメラ経路
1119 BLIFライブラリ
1121 アクティビティログ
1123 カメラキャリブレーション
1125 材料サブライブラリ
1127 粗さサブライブラリ
1129,1131 ログ
1200 クラス図
1201 ルートプレノプティックプリミティブ
1203 メディエル
1205 ラディエル
1209 同質メディエル
1211 異質メディエル
1213 等方性ラディエル
1215 異方性ラディエル
1219 メディエル
1221 分割ラディエル
1223 滑らかに変化するラディエル
1225 サーフェル
1227 単純サーフェル
1229 分割サーフェル
1302,1304 点
1401,2001 光立方体
2002 入射光素子(ラディエル)
2101 体積八分木
2103 ルートノード
2105,2107 ノード
2203 ユニバース
2205 ボクセル
2207 立方体空間
2301 セイエル木
2303 ルートノード
2305,2307,2309 ノード
2403 周囲立方体
2405 面
2407,2409 面正方形
2501 プレノプティック八分木
2502 ボクセル
2503 セイエル
2505 ボクセル
2600 プレノプティック八分木
2601 SLT A
2602 点
2603 セイエル
2604 SLT B
2606 セイエル
2607 SLT C
2608 セイエル
2710 VLOボクセル
2811,2806 入射セイエル
2810 入射SLT D
2910 出射SLT D
3001 SPU
3003 オペレーションモジュール
3005 幾何学的形状モジュール
3007 形状変換モジュール
3009 画像生成モジュール
3011 空間フィルタ処理モジュール
3013 表面抽出モジュール
3015 モルフォロジーオペレーションモジュール
3017 接続性モジュール
3019 質量プロパティモジュール
3021 登録モジュール
3023 ライトフィールドオペレーションモジュール
3101 位置不変ライトフィールド生成モジュール
3103 出射ライトフィールド生成モジュール
3105 出射/入射ライトフィールド処理モジュール
3107 入射/出射ライトフィールド処理モジュール
3200 面0
3201 面1
3202 面2
3203 面3
3204 面4
3205 面5
3300 4分の1面0
3301 4分の1面#1
3302 4分の1面2
3303 4分の1面3
3210 周囲立方体
3601 光線
3602 SLT原点
3603 投影平面
3604 交点
3605 原点
3607 セイエル面
3608 交点
3701 VLOノード
3702 点
3703 レベル1ノード中心
3704 光線
3706 投影面
3707 投影面
3709 交点
3710 ex
3711 ex
3712 e'x
3713 e'y
3708 交点
3801 レベル1のVLOノード
3802,3803 投影面
3804 中心
3805 点
3806 元のセイエルエッジ線交点
3807 交点
3901 レベル1ノード
3902 セイエル
3904 「頂部」エッジ
3905 「底部」エッジ
3906 投影面
3907 点
3909 点t
3910 点b
4001 レベル1のVLOノード
4002 セイエル
4004 投影面
4006 b'y
4100 セイエル木
4101 点
4102 ノード
4103 方向空間
4104 レベルn+1ノード
4105 セイエル木
4106 ノード
4107 領域
4201 レベル1のVLOノード
4203 原点
4204 頂部点t
4205 底部点b
4206 点
4301,4302 VLOノード
4303 出射セイエル
4305 入射セイエル木
4307 原点-原点セグメント
4401 VLOノード
4404 領域
4405 底部エッジ限界
4406 頂部エッジ限界
4407 エッジ
4408 シーケンス0から3
4501 VLOノード
4502 セイエル
4504 四分木
4602 エッジ
4603 半空間
4604 エッジ
4605 上側半空間
4606 半空間
4701 上位レベルVLOノード
4702 セイエル
4703 ノードA
4704 ノードB
4705 ノードC
4802 ノード
4803 VLO中心点
4804,4805 セイエル
4901 点t(tx,ty)
4902 投影面
4903 点b(bx,by)
4904 中心点
4905 dx
4906 dy
5004 頂部点t'
5005 頂部エッジ
5006 dt'
5007 「c」
5009 「a」
5010 dt
5011 「e」
5101 上側レジスタ
5102 下側レジスタ
5103 Delta_U
5104 Delta_L
5105 VLO_Edge
5106 SLT_Edgee
5109 VLO細分信号
5214 V_Delta_U
5215 V_Delta_L
5203 S_Delta_U
5204 S_Delta_L
5602 頂部セイエル
5603 ユニバース
5610 象限子番号付け
5611 サブセイエル番号付け
5701 VLOノード
5702 セイエル
5703 点
5704 底部エッジ
5705 頂部エッジ
5706 原点
5707 投影面
5801 ノード
5802 セイエル
5803 点
5804 底部エッジ
5805 頂部エッジ
5807 投影面
5901 VLOノード
5902 セイエル
5906 点
5907 投影面
6002 セイエル
6004 底部エッジ
6005 頂部エッジ
6007 投影平面
6302 セイエル
6601 基本コーデックAPI
6603 動作パラメータモジュール
6605 コーデックAPI確立リンクモジュール
6607 APIオープンシーンモジュール
6609 リモートシーンアクセスモジュール
6611 ローカルシーンアクセスモジュール
6613 クエリプロセッサモジュール
6615 セッションログモジュール
6703 ステータス&プロパティクエリモジュール
6705 プランサブシーンマスクモジュール
6707 サブシーンマスク生成器
6709 サブシーン抽出モジュール
6711 サブシーン挿入器モジュール
68A02,68A04,68A06,68A08,68A12,68A18,68A22,68A24,68A26,68A30,68B06,68B12,6901,6905,6907,6909,6911,6913,6915,6917,7001,7005,7007,7009,7011,7101,7103,7105,7107,7109,7113,7115 オペレーション
68A10,68A14,68A16,68A20,68B10,68B14 決定オペレーション
68A28 決定
68B02 初期ステップ
68B04 ステップ
6900,7000,7100 プロセス
7202 小さな長方形の領域
7304 分析ポート
7404 鍋の表面
7405 カウンターの表面
7406,7408 ボクセル
7410 サーフェル
7501 領域
7502 小さな点注釈
7521,7611 3D表面プロット
7531 2Dプロット
7601 凹み領域
7701 車体パネル
7711 明るいライトフィールド
7721 注釈
7731 共通
7800 場合
7801,7803 ピクセル
7805 ヘッドマウントディスプレイ
【図1A】
【図1B】
【図1C】
【図1D】
【図1E】
【図1F】
【図1G】
【図2A】
【図2B】
【図3】
【図4A】
【図4B】
【図4C】
【図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】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39】
【図40】
【図41】
【図42】
【図43】
【図44】
【図45】
【図46】
【図47】
【図48】
【図49】
【図50】
【図51】
【図52】
【図53】
【図54】
【図55】
【図56】
【図57】
【図58】
【図59】
【図60】
【図61】
【図62】
【図63】
【図64】
【図65】
【図66】
【図67】
【図68A】
【図68B】
【図69】
【図70】
【図71】
【図72】
【図73】
【図74】
【図75】
【図76】
【図77】
【図78】
