JP4988042B2 - 立体画像の編集方法 - Google Patents

Description

本発明は、ｎ個の部分画像(Teilbildern)ｉまたはこれら部分画像の時系列（ｎ＞１かつｉ＝１、…、ｎ）から得られる画像データからなる立体画像の編集であって、画像の編集を全体的または部分的に順次および並行の少なくとも一つで行い、個々の編集モジュールにおいて画像データを実行順序に従いかつ可変の編集パラメータに応じて編集することを通して行なうことによって、各編集モジュールは、一以上の編集ステップを行なうとともに、一つのノードに割り当てられ、編集順序がノードとの任意的な結合により決定されることによって、各ノードは、編集順序に従ってノードにリンクされ、かつデータを交換することができる編集に関する。本発明は、二次元画像の場合よりも大きいデータ量に対して編集しなければならない三次元画像の効率的な画像編集の問題に関する。

現在の最先端技術では、画像またはビデオのような画像シーケンスをコンピュータを用いて編集することができ、それによって編集状態が常に示される複数の方法が知られている。最も単純な画像編集方法の場合には、どのフィルタまたは編集モジュールをユーザが画像に適用したいのかを、ユーザが選択しなければならない。少しだけ例を挙げると、たとえば、拡散スクリーン・モジュール、シャープネス・モジュール、および色補正モジュールがある。フィルタを選択した場合、このフィルタを、すべての画像データまたは自由に規定可能なセグメント内の画像データに対して、それぞれ用いる。結果として生じる画像を計算して表示する。結果として生じる画像に対して、すべての画像データを再計算する。

最新の画像編集方法では、種々の編集モジュールを、編集順序またはバッチ処理、このような実行順序に結合することができ、そして好ましいグラフィックスとして表示する。その場合、ユーザ自身が、編集モジュールを選択してツリー構造のように組み立てても良い。その結果、編集モジュールはノードに対応する。編集モジュールまたはノードをそれぞれ、互いにリンクさせて、たとえば、複数の先行する編集モジュールからのデータが、後続する編集モジュールに流れるようにすることができる。これは、たとえば、二つの異なる画像からのデータを組み合わせて完全な画像にするべき場合である。その場合、編集モジュールを自分自身でデザインして、これをいわゆるプログラムおよび実行順序へのプラグインとして結合することもできる。二つの編集モジュールがリンクされている場合には、必要な編集ステップを、先行する編集モジュールの実行順序において最初に行なう。全体の画像データ（先の編集モジュールによって少なくとも部分的に変更されている）を次に、実行順序における先行する編集モジュール上に送信して、そこでも編集する。

画像編集に対する同様の方法が、画像シーケンスの編集においても、たとえばビデオ編集プログラムにおいても確立された。個々の画像シーケンスはストリームと言われ、二つの画像をスーパーインポーズして一つの画像にすることができるのと同様に、複数のストリームを一つのストリームに組み合わせることが、たとえば一つの画像シーケンスにサブタイトルを付けるべきときに可能である。この場合、各ストリームを他とは無関係に編集することができる。この場合にも、前述したフィルタ関数を適用することができる。このような画像シーケンスまたは画像シーケンスの組み合わせの編集が完了するとすぐに、結果がスクリーン上に表示される。編集中も、個々のステップまたは個々の画像シーケンスを別個に表示することができる。

このプロセスでは、すべての画像データを、編集パラメータにわずかでも変化があった場合に、たとえばカラー・フィルタまたは拡散スクリーンが付加された場合に再計算して、ツリー構造または実行順序に従ってそれぞれ下方に送信する。これは、パラメータの変化が起きたモジュールから開始するか、または全体的に調整可能なパラメータの始まりからそれぞれ開始して、階層に従って下方に送信する。すべての画像データを再計算して、階層に従って下方に送信する。

このような方法は、ユーザが、ビデオ・シーケンスの編集に対してグラフィックス表面を利用できるようにするものであり、特許文献１に記載されている。編集モジュールは、階層的ツリー構造における実行順序に従って図式的にまとめられる。ツリー構造には、たとえば、種々のストリームまたはラックが組み合わされるノードが含まれ、他のノードは編集モジュールを構成する。ノードはツリー構造を介して接続される。

同様の方法を用いた配置が、たとえば、特許文献２に記載されている。この場合もやはり、複数のデータ・ストリームを編集して組み合わせることができ、それによって、複数のデータ・ストリームを同時に編集することで編集を高速化することができる。このようにして、リアル・タイムの編集が可能になるはずであり、すなわち、結果をスクリーン上にただちに表示することができ、同時撮影を通して、得られた結果を遅延なしにスクリーン上に表示することができる。

両方法において、および前述したプロセスにおいて、すべての計算をプロセッサ・マザーボード上で行なう。説明した方法は、二次元画像コンテンツには適切であるが、これらの方法を三次元コンテンツに適用するとすぐに限界に達する。なぜならば、編集すべきデータ量が何倍も大きいからである。原理的には、物体の二つの光景を異なる遠近感から撮影することが、立体的な印象を伝えられる立体画像または立体画像シーケンスを形成するためには適切であるが、見る人がスクリーンの前で動くことが非常に制約される可能性がある。一般的に、複数の光景を、異なる遠近感から撮影するかまたは過去にさかのぼって形成する。通常、八つの光景を用いる。公知の最先端技術の方法によれば、３Ｄビデオ編集のリアル・タイム表示は可能ではない。すなわち、一つの作業ステップを行なった後、結果をスクリーン上に表示することができるまで、常にある程度の時間の経過が存在する。主な問題は、多くのデータ量に対処することである。

データ量を減らす試みを、特許文献３に見ることができる。ここには、複数のトラックまたはストリームからそれぞれなる画像シーケンスを編集する方法が記載されている。このようなトラックのセグメントを、編集中に削除しても、ハード・ディスクまたは記憶媒体上のデータの実際の削除はなんら行なわれないが、特定のマーキング（いわゆるポインタ）が置かれて、トラック内の対応する位置を指すことになる。

トラック自体は損なわれないため、データ管理および編集時間が単純になる。特許文献３において編集される画像シーケンスは、共通の時間軸を有するいわゆるマルチビュー・ストリーム（すなわち、画像シーケンス）に関係する。しかしながら、コンテンツは異なる可能性がある。それは、たとえば、番組中に撮影するテレビジョン画像であって、二つの画像を司会者に対して異なる遠近感から撮り、第３のカメラが聴衆を撮影する場合があるテレビジョン画像に関係する場合がある。

このようなマルチビュー・ストリームを用いる場合、各ストリームが同じ場面を、しかしながら、わずかに異なる遠近感から示すように、ストリームを作ることができる。その結果、種々の光景からなるデータ・ストリームを、取り扱い、編集し、好適なスクリーン上に立体画像として表示することができる。特許文献４に記載される方法の一つにおいては、すべての光景からなるデータ・ストリームを編集している。初期補正によってノイズを取り除いた後に、カメラ・パラメータを決定して、場面のモデルを計算する。この方法によって、個々の物体の配置の深さ（カメラ位置から見た）に関する情報が得られる。この情報から、さらなる編集ステップの後に、立体的に提示可能な画像を形成することができる。しかしながら、画像シーケンス上での送信は、編集する必要があるデータ量が原因で扱いにくく、また行なうべき計算が多すぎるために満足できるものではない。これらの計算は、立体的に提示可能な画像を形成するためには必要であるが、それらを後の段階で編集する場合には、このような図または画像シーケンスを用いることはできない。

公知の最先端技術の方法は、遅れた画像の編集に対しては、特に、立体表示またはマルチビュー・ストリームに対する画像シーケンス（画像データ上でフィルタまたは関数を用いるべきである）に対してはそれぞれほとんど適していない。なぜならば、現時点で利用可能な効率的なプロセッサを用いても、リアル・タイムで編集するという結果を生むことはできず、そのため、見る人は、本人が加えたどんな変化の効果（すなわち拡散スクリーンまたは色補正）に対しても、ある程度の時間、待機しなければならないからである。したがって、このような画像コンテンツの編集は、非常に時間がかかり、高価である。

米国特許第６７６８４９９号明細書 国際公開第９９／５２２７６号パンフレット 米国特許出願公開第２００３／０１５６８２２号明細書 国際公開第２００６／０４９３８４号パンフレット

本発明の目的は、立体的に提示可能な画像または画像シーケンスの編集を、少なくともリアル・タイムに近い編集が可能となるように、すなわち、オペレータが、調整に対して自分が加えた変化の効果を、おそらくわずかな時間遅延もなしで、特に立体表示に関して、見ることができるように行なうための方法をさらに開発することである。

前述した方法において、この問題は、実行順序において互いにリンクされた実行順序における二つのノードごとに一以上の編集パラメータに変化を加えた場合に、（ａ）実行順序において先行するノードに割り当てられた先行する編集モジュールが、実行順序において後続するノードに割り当てられた後続する編集モジュールに、現在の画像データのどのセクションが、先行する編集モジュール上での変化の影響を受けるかを送信し、（ｂ）後続する編集モジュールが、先行する編集モジュールに、変化させた編集パラメータを用いて再決定された画像データのうちどれが必要とされるかを送信し、先行する画像モジュールは、このような画像データのみを計算して、後続する編集モジュールに送信することによって、解決される。

画像データは、好ましくは、ｎ個の部分画像ｉまたはこれら部分画像の時系列（ｎ＞１かつｉ＝１、…、ｎ）からなる画像に対応するものであるが、コンピュータ・グラフィックスとして作成することが可能であるか、またはｎ回撮影された部分画像を備えるカメラ写真として記録することが可能である。両方を混合したものも可能である。すなわち、物体を部分的に実際に撮影したものと、コンピュータ・グラフィックスを利用して部分的に作成したものとを備えるマルチビュー・ストリームである。編集する際、オートデスク（登録商標）マヤ（登録商標）（Autodesk Maya）またはオートデスク（登録商標）３Ｄスタジオマックス（登録商標）（Autodesk 3D Studio MAX）のような市販のアニメーション・プログラムであるコンピュータ・グラフィックスに基づく部分画像が好適である。これらを用いて、部分画像を、カメラ位置がわずかに異なる別個の斜視図としてレンダリングする。あるいは、深さカードのｎ個の部分画像ｉのうちの一つが、表示された場面にマッチすることができる。

編集パラメータは、ローカル編集パラメータに関係しても良い、ローカル編集パラメータは、先行する編集モジュール上もしくは先行する編集モジュールの一つ上で、またはグローバル編集パラメータ（実行順序全体に影響する）の周りで、直接調整される。たとえば、二つのストリームを使用し、一方は、着色されたテキストを示し、これは左から右に動いていて前景に残らなければならず、第２のストリームは背景場面を示し、これは動かないかまたはゆっくりと動くかもしくは回転し、その結果、テキストが背景に対して立体的に表示される場合、第１のストリームのテキストの色、書体、および文字列（すなわち、テキスト自体）は、ローカル編集パラメータである。これは、テキストが左から右に動く画像シーケンスに関係するため、グローバル編集パラメータは、たとえば時間ｔである。

たとえば、テキストの色を変える場合には、テキストを示すストリームのみを変えなければならない。両方のストリームを組み合わせる際には、画像データは単に、テキストが影響を及ぼす画像のセクタにおいて再決定する。他の画像データを新しく計算する必要はない。現在の技術の状況では、このようなプロセスにおけるデータおよび情報は一方向にのみ進み、ツリー内を上方から下方へ流れるが、さらに、二つのリンクされた編集モジュールは、反対方向でも通信することができる。編集パラメータを変えた場合、最初は、画像および画像データのそれぞれのうち、この編集パラメータが影響を及ぼすセクションが決定される（このことは、たとえば、少なくとも二次元のマトリックス（指標が、画像または部分画像における座標に、および指標に対する一以上の値群に対応する）に記憶されるデータに対応する）。すなわち、パラメータの変化の影響を受けるセクションである。このセクタは、後続するノードにおけるすべての編集モジュールに、連続してまたは直接的にさえ送信される。後続する編集モジュールの各々は、後続するノードに送信されたすべてのセグメントを一つのセグメントにまとめることができる。後続する編集ノード自体が、保持された画像データが、パラメータの変化の影響を受けたセクタに影響を及ぼすかどうかをチェックする。テキストの植字を変えた場合、背景場面に関係する画像データは再計算してはならない。

実行順序における最後の編集モジュールは、最初に、画像データを再計算しなければいけないか否かをチェックし、肯定される場合には、その目的に対してどのデータが必要であるかをチェックする。この情報を次に、先行する編集モジュールに渡し、そこでチェックを行なう。この先行する編集モジュールに対して必要な画像データは同じ可能性があるが、他の画像データである可能性もある。後続する編集モジュールに関する情報とともに、このデータを次に、次の先行する編集モジュールに送信することを、変化の影響を受けた第１の影響された編集モジュールが繰り返して見出されるまで（複数の第１の編集モジュールの分岐も行なわれる場合に）行ない、少なくとも新しい画像データを再計算しなければいけない。同様に、実行順序における最後の再計算が行なわれた個々の編集モジュールは必ずしも、実行順序における最後の編集モジュールではない。

後続する編集モジュールが、先行する編集モジュールに、どの画像データを再決定しなければいけないか、またはそれぞれ、どれを再決定された形態で必要とするかを通知して、その編集ステップを実行できるようにする場合、先行する編集モジュールから送られるこの画像データを再計算し、それによって、さらなる先行する編集モジュールを用いなければいけない。再計算された画像データ（これのみ）を、後続する編集モジュールに送信する。すべての画像データを再計算する必要はない。このようにして、最先端技術の場合と比べて、時間および計算能力を節約することができる。

画像データの一部またはセクションのみをそれぞれ、再計算して、後続する編集モジュールに送信する場合には、少なくとも初期データ（編集モジュールが計算用に必要とする）をこの編集モジュールが記憶するという意味が含まれる。再決定されて送信された画像データ（編集パラメータの変化によって生じる）は次に、当初の画像データの一部を上書きして、プロセス内に流れる。編集モジュールはその開始データを計算した後に、次の後続する編集モジュールに送信し、次にそれを全体的または部分的に新しくするが、要求されるかまたは必要な画像データのみをそれぞれ次の編集モジュールに送信する。

本発明の機能的な実施形態において、編集パラメータに変化を加えたときには、編集モジュールにおいてすでに処理された画像データに対して、編集モジュールにおいて選択された編集ステップのタイプに応じて記憶優先度が与えられる。これが意味するところは、編集パラメータを変えた場合には、編集に必要な入力データが部分的に記憶されるだけでなく、初期データの少なくとも変化しない部分も記憶されるということである。画像データの一部に対する明度が変化する場合には、その意味するところは、背景場面の前面で浮いている場面における種々の物体（たとえば、すでに前述したテキスト）に対する深さ情報は変化しないということである。後続する編集モジュールが深さを決定する場合には、これらのデータは再計算する必要はない。編集モジュールにおいて取られる編集ステップが、容易かつ迅速に行なうことができる演算にのみ関係する場合には、画像データの記憶領域を開放して記憶場所を優先し、これらの各時間を再計算することが有用である可能性がある。

本発明の特別な好ましい実施形態においては、編集ステップを、少なくとも部分的にまたは好ましくは、グラフィックス・カード上で行なう。そうすることで、編集モジュールの編集ステップを行なう演算が、グラフィックス・カードに対するグラフィックス・コマンドとして変換されるため、特別な要求に従う。現在のところ、これらは特に、オープンＧＬ２．０標準であり、加えてピクセル・シェーダー・モデル３およびオープンＧＬシェーディング言語１．０の少なくとも一つまたは適切なものを、グラフィックス・カード上で実施しなければならない。先行開発または関連の関数ライブラリ（ここでは述べていない）を、用いることもできる。これには、さらなる優位性として、編集を当初の画像形式（通常、各チャネル当たり８ビット色深度であるＲＧＢアルファ）とは無関係に行なえるという点がある。グラフィックス・カードによって、用いるべき計算フォーマットが内部的に決定される。

明らかにより高品質の他のフォーマットも可能である。たとえば、各色チャネルに対して１０ビット深さであるＲＧＢアルファ、または１６／３２ビット浮動少数点フォーマットである。ＲＧＢ以外の他の色空間または他のフォーマットでさえ、それぞれ用いることができる。たとえば、発光および他のデータを記憶するものである。演算処理にグラフィックス・カードを含むことも、編集パラメータの変化の結果をスクリーン上でほとんどリアル・タイムで見ることができて対話型編集が容易になることに寄与する。パラメータが非常に大きく変化する場合、および結果として生じる画像を得るために多くの中間画像を計算しなければならない場合には、計算において特定の中間結果画像を除外することもできるであろう（フレーム・ドロッピング）。グラフィックス・カード上ですべての演算処理を移すことはしないが、グラフィックス・カードのプロセッサとマザーボード上のプロセッサとを確実に等しく用いることも、道理にかなっているであろう。

編集モジュールと実行順序との取り扱いを、スクリーン上に表示することが好都合である。ユーザは、ただちに実行順序を見ることができ、たとえばドラッグ・アンド・ドロップ機能を用いることによって編集モジュールを加えるかまたは取り除き、新しいノードを実行順序内に作成することができる。

本発明の方法を用いれば、多くの編集パラメータを用いたり、変更したりすることが可能になる。そうすることで、編集パラメータの多くが特定の編集モジュールに結合される。画像およびビデオ処理において長い間すでに用いられている典型的な編集モジュールは、たとえば、拡散または高解像度レンズである。このレンズでは、説明した機能が画像データおよび画素にそれぞれ適用される。色に影響するモジュール（たとえば、画素を、直接、色に割り当てることができるか、または選択した色空間に従って割り当てることができる）においては、彩度、灰色調、または色調も変えることができる。さらなる編集モジュールを表示することもできる。たとえば、スーパーインポーズ機能、混合機能とともにモジュール（数学関数を表示することができる）、テキスト・レンダリング（ある特定のテキストをスクリーン上に、植字および他の属性に関して説明した仕方で表示することができる）、幾何学的な形状または行を作成するモジュール、ならびに最後に二次元から三次元画像データへの変換もである。これらの編集モジュールの多くを、ローカル編集パラメータ（たとえば、色相、彩度、ガウス関数に基づく拡散スクリーンに対する半径など）に割り当てる。他の関数パラメータはグローバル編集パラメータである。

実際上は、指標ｉ（セクション１〜ｎから部分画像を指定する）を、編集パラメータとして用いる。部分画像ｉを（自動的にまたはユーザを通して）選択したら、これを好ましくは、第１のスクリーン上に表示する。部分画像自体は二次元である。したがって二次元の観察に適したスクリーンが適している。この場合、部分画像を見ることができるのは、その部分画像が実行順序の終わりに現れたとき、またはその部分画像が他の部分画像と組み合わされて立体画像になる前であり、あるいは（編集モジュールを選択したときに）その部分画像がこのノード上に表示されるような方法においてもその部分画像を見ることができる。

本発明の好ましい実施形態においては、ｎ個の部分画像ｉからなる画像を第２のスクリーン上に立体的に表示する。そのようにして、ユーザの目の前には常に全体的な結果がある。第２のスクリーンは、三次元観察に適している。それは、三次元観察に対して単独で用いることができるが、二次元観察と三次元観察との間で切り換えることもできる。第１および第２のスクリーンを、三次元表示用に少なくとも部分的に構成されている一つの共通の表示内に組み込むことも可能である。その場合に、第２のスクリーンは、一以上の公知のプロセスによる三次元表示に適している。たとえば、少しだけ例を挙げると、その表示は、メガネ無用バリアまたはフィルタ配列プロセスｍ、レンズ状プロセス、メガネに基づくプロセス、または時系列的なプロセスを用いて行なわれる。

個々の画像に適用されるものは、原理的には、画像シーケンス（たとえば、デジタル・ビデオ）にも適用される。その場合には、このシーケンスにおける画像として割り当てる時間ｔを、編集パラメータとして使用し、任意的に部分画像の指標ｉも用いる。時間ｔおよび部分画像ｉを選択すると、関連する部分画像が第１のスクリーン上に投影される。また、ｎ個の部分画像ｉからなる画像を、時間ｔにおいて、立体的に、時間ｔにおいて、立体表示に適した第２のスクリーン上に表示することができる。また、このスクリーンを、表示の二次元モードと三次元のモードとの間で切り換えることもでき、さらに第１のスクリーンと統合して共通の表示にすることもできる。

本発明によれば、三次元画像または三次元画像シーケンスをそれぞれ表示することが優位である。なぜならば、編集パラメータを変えたときに必要な演算処理の数が非常に少なくなるからである。またグラフィックス・カードが、編集ステップの計算を行なうには好ましい。このようにして、オペレータに対するフィードバックに関してわずかな時間遅延もほとんどない。

本発明の別の好ましい実施形態においては、ユーザが編集モジュールを選択したときに、画像および一以上の部分画像ｉの少なくとも一つを、編集モジュールにとって利用可能な画像データからまとめる。すなわち、最終結果ではなく画像を、この編集モジュールにおいて利用可能なときに表示し、その結果、後続する編集ステップの影響が隠されるようにする。その結果、一以上の部分画像の少なくとも一つを第１のスクリーン上に表示し、部分画像ｉからまとめた画像を第２のスクリーン上に立体的に表示する。

前述した特徴および後に説明する特徴は、本明細書で述べる組み合わせで利用できるだけでなく、他の組み合わせでまたはそのままで、本発明の範囲を逸脱することなく利用できることが理解される。

以下は、添付の図面を用いた本発明のより詳細な典型的な説明であり、図面においても本発明に不可欠の特徴が開示されている。図面には以下のことが示されている。

画像処理に対して用いることができる配置の構造を示す図。 画像を編集中のスクリーンを示す図。 図２に示す実行順序の連結された編集モジュールを示す図。

図１に、最初に、ｎ個の部分画像ｉまたはこのような部分画像の時系列からなる画像データから作られる立体画像（ｎ＞１かつｉ＝１、…、ｎ）を編集することができる配置を示す。その結果、画像の編集を全体的または部分的に順次および並行の少なくとも一つで行うことができ、それによって、画像データが、実行順序に従ってかつ調整可能な編集パラメータに応じて、個々の編集モジュールにおいて編集される。このような配置は、たとえば、コンピュータ１からなることができ、それによって、これは、たとえば強力なＰＣまたは強力なノートブックとすることができる。コンピュータ１は、必須の構成要素としてマザーボード２を備え、マザーボード２上には、ランダム・アクセス・メモリ・モジュールも配置されている。画像および画像シーケンスの少なくとも一つは、編集する前および後に、ハード・ディスク３上または等価な読取可能および書き込み可能な記憶媒体上に記憶される。必要に応じてハード・ディスク３を、画像データを一時的に記憶するために用いることもでき、これは、たとえば編集状態が一時的な記憶を必要とする場合である。グラフィックス・カード４は、この構成の別の必須の構成要素である。グラフィックス・カード４は、好ましくは、二つのスクリーン５ａおよび５ｂに対する出口を有する。そのうちスクリーン５ａは、二次元表示および任意的に三次元表示に適しており、スクリーン５ｂは三次元表示に適している。スクリーン５ａおよび５ｂは、グラフィックス・カード４の出口に、データ・ライン６ａおよび６ｂを介して接続されている。

図２に、スクリーン５ａのセグメントを示す。それに関して、必須ではない図形要素（たとえば演算に必要）は図示しておらず、図１の場合と同様に、通常、コンピュータの一部である付加的な構成要素も図示していない。スクリーン５ａは、半分に再分割されている。スクリーンの右半分７上には実行順序が表示され、左半分８上には、一以上の部分画像または画像全体を、二次元または三次元表示で窓９内に示すことができる。また、窓９は、スクリーン５ｂ上に表示することもできる（それが合成立体画像を示す場合）。

右半分７に表示された実行順序には、複数の編集モジュール１０、１１、１２、１３、１４、１５および１６が示されている。ノード内では、画像の編集が全体的または部分的に順次および並行の少なくとも一つで行なわれる。その結果、画像データの編集が、個々の編集モジュールにおいて、実行順序に従っておよび調整可能な編集パラメータに応じて行なわれる。その結果、各編集モジュールでは一以上の編集ステップが行なわれる。さらに、各編集モジュールをノードに割り当て、この割り当ては絶対的である。実行順序は、ユーザまたはプログラムによる指定ごとにノードをリンクすることによって決定される。リンケージは選択可能である。

図２において、ノードおよび編集モジュールは、描かれた矩形によって同様に符号表示されている。リンケージは、描かれた接続ラインに従って行なわれる。したがって、編集モジュール１３は、たとえば、その入力側において編集モジュール１１および１２とリンクされ、その出口側において編集モジュール１４とリンクされる。他方で、編集モジュール１６は他のモジュールとは何らリンクされていないが、ユーザは、編集モジュール１６を、最上部から最下部へと実行されるツリー構造内に対話式に挿入することができる。その結果、ユーザは、編集モジュールを対話式に選択することができるとともに、編集モジュールにとって利用可能な画像データに従って、画像および一以上の部分画像ｉの少なくとも一つをまとめることができる。その結果、一以上の部分画像ｉがスクリーン５ａの窓９内に表示され、画像がスクリーン５ｂ上に立体的に表示される。あるいは、実行順序の終わり（この場合には、編集モジュール１５の出口）において最終的な結果を表示するだけというのも可能である。同じことが、画像の時系列が存在する場合に当てはまる。この場合、時間ｔを画像に割り当て、付加的にｉも編集パラメータとして用いる。時間ｔおよび部分画像ｉを選択した場合、対応する部分画像が窓９内に示され、結果として生じる時間ｔにおける全体画像がスクリーン５ｂ上に表示される。さらに、各ノードは、実行順序に従ってそれがリンクされるノードとデータを交換することができる。

本実施形態において、示した実行順序は、場面の前景を左から右に飛ぶテキストを規定するものである。したがって、三次元表示に加えて、テキストが規定した速度で左から右に動き、その一方で、特定の消滅点に関連して、背景場面がより遅い速度で右から左に動くかまたは回転もしくは静止することをそれぞれ行なうことが必要である。テキストの必須の属性は、編集モジュール１１において決定される。これらの属性としては、とりわけ、テキスト自体、フォントの色、フォント、および深さ情報が挙げられる。その結果、編集モジュール１１のデータから作成される画像シーケンスは、着色されたテキストのみを表示する。背景場面に関する情報は、編集モジュール１０において利用可能である。編集モジュール１０および１１の両方が、たとえば、それらのデータをハード・ディスクから読むことができる。また本例では、時間的な画像シーケンスではあるが、事前に編集されているため、この画像シーケンスに加えるべき変化はない画像シーケンスも表わす。

編集モジュール１０は、その画像データを編集モジュール１２に送信する。この編集モジュールでは、たとえば背景の色合いを編集することができる。その後、編集モジュール１２および１１からの画像データが、別の編集モジュール１３に送信される。編集モジュール１３では、両方の編集モジュールの画像データが組み合わせられる。すなわち、画像データを深さ情報に従ってスーパーインポーズして、新しい全体画像が作成される。その結果、閲覧者が部分画像ｉのみを選択すると、窓９内の結果は、この部分画像ｉに関してのみ表示される。しかしながら、すべての部分画像ｉが相互に連結されているため（それらには、たとえば、同じ光景の異なる深さを示す異なる角度またはレイヤ画像から取り込まれた同じ場面の異なる光景を含むことができる）、この情報に基づいて画像全体を計算することがいつでも可能である。画像は次に、スクリーン５ｂ上に表示される。したがって、部分画像にのみ変化を加える場合には、たとえばテキストの色を変える場合には、これらの変化を自動的に他の部分画像に移すことができる。しかしながら、これらの計算は、バックグラウンドで行なわれ、任意選択のみである。

画像データを組み合わせた後で、編集モジュール１３は画像データを編集モジュール１４に送信する。編集モジュール１４では、たとえばガウシアン・ソフト・フォーカス・レンズを画像全体に適用するか、またはコントラストの強調、エッジの強調などを行なうことができる。次に、編集モジュール１４において編集した画像データが別の最後の編集モジュール１５に送信される。編集モジュール１５では、画像シーケンスのデータがハード・ディスク上に書き込まれる。

説明したモジュールは、単に例として選択されたものである。画像およびビデオ編集において通常使用されるよう別の編集モジュールも、当然のことながら用いることができる。また、二次元コンテンツを三次元コンテンツに変換するモジュールを組み込むことも想到され得る。さらに、すべての一般的な入力および出力フォーマットを適用することができる。少しだけ述べると、これらに含まれるのは、静止画像の場合に、たとえばｂｍｐ−、ｊｐｇ−、ｇｉｆ−、ｐｎｇ−、ｒｉａ−、ｔｇａ−、ｔｉｆｆ−、およびｏｐｅｎ−ｅｘｒフォーマットであり、ビデオ・ファイルの場合に、たとえばａｖｉ−、ｍｐｅｇ２−、およびｍｐｅｇ４−フォーマットであり、それぞれの場合に、マルチ・ストリーム・フォーマットとしても含まれる。

編集パラメータを変えた場合には、すでに編集した画像データを、編集モジュールにおいて記憶させることができ、好ましくは、編集モジュールにおいて行なうべき編集ステップのタイプに従って記憶させる。たとえば、ユーザが部分画像ｉ間で複数回切り換える場合、これは特に優位である。なぜならば、以前に編集した部分画像の画像データは、部分画像間の切り換えを行なった場合には、再計算しなくても良いからである。同じことが、先行するノードにおける編集モジュールにも当てはまる。現在選択されている編集モジュールにおけるローカル編集パラメータを変えた場合、先行する編集モジュールの画像データは再計算する必要がない。たとえば、編集モジュール１３においてテキストの位置を変える場合、編集モジュール１０、１１および１２はそれらの画像データを保持するため、これらの再計算は、編集モジュール１３が要求しても行なう必要はない。

図３に、図２の実行順序のセグメントを示す。図３は、移すべきデータ量をどのように最適化または最小限にして、特に、スクリーン５ｂ上に表示する３Ｄビデオ・シーケンスのリアル・タイム編集を可能にするかを説明する働きをする。編集モジュール間の通信が両方向において可能である。一以上の編集パラメータが変わる場合、たとえばディスプレイ時間ｔが変わる場合、または別の部分画像ｉを選択する場合、あるいは編集モジュール１２において背景の色合いを変える場合には、実行順序において相互に連結された二つのノードごとに、実行順序内の先行するノードに割り当てられた先行する編集モジュールが、実行順序内の後続するノードに割り当てられた後続する編集モジュールに、先行する編集モジュールにとって利用可能な画像データのセグメントのうちどれが、編集パラメータの変化の影響を受けるかを送信する。後続する編集モジュールにおいて画像データを再決定するために、後続する編集モジュールは、先行する編集モジュールに、変えた編集パラメータを用いて新たに計算された画像データのうちどれを、後続する編集モジュールがその編集ステップを実行するために必要とするかを通知する。先行する編集モジュールは、この画像データのみを再計算して、後続する編集モジュールに送信する。また、後続する編集モジュールが画像データを必要としない場合には、先行する編集モジュールに対して送信は行なわれない。

たとえば、編集モジュール１１における編集パラメータである場合に、図の前景に渡って飛ぶと想定されるテキストのフォントの色を赤から緑に変えると、たとえば編集モジュール１１は、編集モジュール１３に、編集モジュール１１に従ってテキストが配置される画像または部分画像の領域全体が、この変化の影響を受けることを通知する。編集モジュール１３において画像データを再計算する間またはその前に、編集モジュール１３は、編集モジュール１１に、テキストの色の指定が変更された画像の領域に対する再計算された画像データを編集モジュール１３が必要とすることを通知して、画像の組み合わせにおいてこれを正しく考慮するようにする。領域サイズは可変であり、編集モジュール１３において作成される合成画像においてテキストが部分的にカバーされる場合、結果的により小さくなることもできる。先行するモジュールは、要求される領域に対して画像データを再決定する必要があるだけである。したがって、編集モジュール１３および１４も互いに通信する。編集モジュール１３が編集モジュール１４に、どの領域が変化の影響を受けるかを通知した後に、編集モジュール１４は編集モジュール１３に、この領域からの画像データのうちどれを、すなわちどの部分領域を、編集モジュール１４が再び必要とするかを通知する。この例では、ソフト・フォーカス・レンズが画像データ全体に影響する。しかしながら、画像データが再送信されない場合、および編集モジュール１４において画像データの再計算が行なわれない場合には、編集モジュール１４におけるテキストは依然として当初の色で現れる。編集モジュール１２から編集モジュール１３に送信される画像データを、再計算する必要はない。

それに関して、編集ステップを、グラフィックス・カード上で少なくとも部分的に行なうことができる。このようにして、プロセスの速度をさらに上げること、およびユーザに対するリアル・タイムな印象をさらに向上させることができる。こうするために、編集モジュールからの演算を、グラフィックス・カード用のグラフィックス命令に変換する。したがって、グラフィックス・カードは、要求される標準（たとえばオープンＧＬ２．０標準など）に適合しなければならない。グラフィックス・カードを組み込んでいる場合、編集ステップを、当初の画像形式（一般的には、それぞれ８ビット色深度であるＲＧＢ−アルファ）とは無関係に行なうことができる。計算するために、フォーマットとして、グラフィックス・カードの構造を最適なレベルで用いるものおよびより高い確度をもたらすものを用いることができる。たとえば、それぞれ１０ビット色深度であるＲＧＢアルファまたは１６／３２ビットの浮動少数点フォーマットである。たとえば、発光を記憶するフォーマットも可能である。その結果、すべての編集ステップをグラフィックス・カード上で行なわなければいけないわけではなく、単純で一般的な演算を依然として、上流、並列、または下流のプロセッサ上で行なって、付加的なコンピューティング資源を分別良く用いることができる。

編集パラメータの変化の後に、後続するノードにおける編集モジュールが、先行するノードからの新しい画像データを必要としない場合には、後続するノードは、先行するノードにおける編集モジュールに通知を送らないため、先行するノードにおける画像データの再計算もない。たとえば、これは、スクリーンに渡って飛ぶテキストがほぼ中央で停止するため、アニメーション時間（編集パラメータｔ）の変化がなく、再計算も必要ではない場合であり得る。編集パラメータをモジュールにおいてまたは全体的に変えた場合、各編集モジュールは、それが計算した画像データのうちどれが変化しているかを決定して、後続する編集モジュールすべてに繰り返し通知する。その後、後続する編集モジュールはそれぞれ、変化した画像データのうちどれを必要とするかを決定する。後続する編集モジュールはすべて、先行するモジュールすべてに対して、後続する編集モジュールがどういう新しいデータを必要とするのかを繰り返して通知する。この意味するところは、各ノードにおいて、先行するノードを特定する情報、また先行するノードのうちどれが、現在のノードにおいて利用可能な画像データに影響する可能性があるかを特定する情報が利用可能であるということである。この情報は、ユーザによる実行順序の構成によって、さらに編集モジュールの前述した機能によって、自動的に導き出される。新しいノードを編集モジュールとともに挿入した場合、この情報は、個々の編集モジュールによって更新される。

編集モジュールにおける編集パラメータが変わると、可能な後続するノードがすべて決定され、これらのノードに割り当てられた編集モジュールにおいて、画像データがその妥当性を保つか失うかが決定される。その結果、すべての画像データがその妥当性を失い、そのため完全な再計算が必要となることもあり得る。たとえば、これは、画像シーケンスのアニメーション時間ｔが大きく急増した場合であり得る。

前述した方法によって、３Ｄ画像データおよび３Ｄビデオ・シーケンスを編集すること、および編集結果または個々の編集ステップにリアル・タイムで追従することができる。こうして、立体的に表示可能な画像および画像シーケンスの画像編集の効率が著しく向上する。

１…コンピュータ、２…マザーボード、３…ハード・ディスク、４…グラフィックス・カード、５ａ，５ｂ…スクリーン、６ａ，６ｂ…データ・ライン、７…スクリーンの右半分、８…スクリーンの左半分、９…窓、１０〜１６…編集モジュール。

Claims (9)

1. ｎ個の部分画像ｉまたはこれら部分画像の時系列（ｎ＞１かつｉ＝１、…、ｎ）からなる画像データから作成される立体画像を編集するための方法であって、
   前記立体画像の編集を全体的または部分的に順次および並行の少なくとも一つで行なうことによって、実行順序に従ってかつ調整可能な編集パラメータに応じて、個々の編集モジュールにおいて前記画像データの編集が実行され、各編集モジュールが一以上の編集ステップを実行し、前記実行順序が前記編集モジュールの選択可能なリンクによって決定され、
   各編集モジュールが、前記実行順序に従ってリンクされた編集モジュールとデータを交換する、方法において、
   前記実行順序において相互にリンクされた二つの編集モジュールごとに一以上の編集パラメータに変化を加えた場合に、
   ａ）先行する編集モジュールが、後続する編集モジュールに、前記先行する編集モジュールにとって利用可能な前記画像データのセグメントのうちどれが変化の影響を受けるかを送信し、
   ｂ）前記後続する編集モジュールが、前記先行する編集モジュールに、変化させた編集パラメータに従って再決定された画像データのうちどの部分が、その編集ステップを実行するのに必要であるかを送信し、
   ｃ）前記先行する編集モジュールが、工程（ｂ）で送信された画像データの部分のみを再計算して、前記後続する編集モジュールに送信することを特徴とする方法。
2. 編集パラメータが変化した場合、前記編集モジュールにおいてすでに編集された前記画像データを、前記編集モジュールにおいて行なうべき編集ステップのタイプに従って記憶することを特徴とする請求項１に記載の方法。
3. 前記編集ステップがグラフィックス・カード上で少なくとも部分的に実行されることを特徴とする請求項２に記載の方法。
4. 前記編集モジュールおよび前記実行順序を一つのスクリーン上に表示することを特徴とする請求項１〜３の何れか一項に記載の方法。
5. ｉを編集パラメータとして使用し、部分画像ｉが選択された場合に、第１のスクリーン上に部分画像ｉを表示することを特徴とする請求項１〜４の何れか一項に記載の方法。
6. ｎ個の部分画像ｉからまとめた合成画像を第２のスクリーン上に立体的に表示することを特徴とする請求項５に記載の方法。
7. 部分画像が時系列である場合には、一つの画像に割り当てた時間ｔとｉとを編集パラメータとして使用し、時間ｔと部分画像ｉとが選択された場合には、対応する部分画像を第１のスクリーン上に表示することを特徴とする請求項１〜４の何れか一項に記載の方法。
8. 時間ｔにおいてｎ個の部分画像ｉからまとめた合成画像を第２のスクリーン上に立体的に表示することを特徴とする請求項７に記載の方法。
9. ユーザが編集モジュールを選択した場合には、画像および一以上の部分画像ｉの少なくとも一つを、編集モジュールにとって利用可能な画像データからまとめることによって、画像および一以上の部分画像ｉの少なくとも一つを第１のスクリーン上に表示し、画像を第２のスクリーン上に立体的に表示することを特徴とする請求項１〜８の何れか一項に記載の方法。

Images