JP4166376B2 - ディジタル・ビデオ信号処理装置及び方法 - Google Patents
ディジタル・ビデオ信号処理装置及び方法 Download PDFInfo
- Publication number
- JP4166376B2 JP4166376B2 JP21558399A JP21558399A JP4166376B2 JP 4166376 B2 JP4166376 B2 JP 4166376B2 JP 21558399 A JP21558399 A JP 21558399A JP 21558399 A JP21558399 A JP 21558399A JP 4166376 B2 JP4166376 B2 JP 4166376B2
- Authority
- JP
- Japan
- Prior art keywords
- effect
- video signal
- plug
- signal processing
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T1/00—General purpose image data processing
- G06T1/60—Memory management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- G06F12/0888—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches using selective caching, e.g. bypass
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T11/00—2D [Two Dimensional] image generation
- G06T11/60—Editing figures and text; Combining figures or text
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Processing Or Creating Images (AREA)
- Studio Circuits (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Controls And Circuits For Display Device (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はディジタル・ビデオ信号処理装置におけるキャッシングに関する。
【０００２】
【従来の技術】
ビデオ特殊効果装置等のビデオ信号処理装置においては、一つのビデオ・シーケンスの複数の画像に対してディジタル信号処理が適用される。
そのようなシステムの一例において、ユーザは、沢山の適用可能なモジュールから一連の効果モジュールを選択することによって、或ビデオ・シーケンスに適用すべき複合特殊効果を設定することができる。例えば、ユーザによって設定される一連の（又は「有向非循環グラフ」の）効果は、下記のことを含む。即ち、
（ｉ） 画像ロード手段
（ｉｉ） 動き追跡手段
（ｉｉｉ）動き追跡及び画像ロードにリンクされた照明効果
（ｉｖ） 動き追跡及び画像ロードにリンクされた画像の再配列
【０００３】
特殊効果が選択され、全てのパラメータが定義されると、「描写（rendering ）操作が行われなければならない。描写は、設定された処理操作に従って、出力画像、出力ビデオ・シーケンス又は或画像内の動きベクトル又は位置等の中間データ・タイプを形成する一連の画像を生成する処理である。例えば、照明効果は、ビデオ・シーケンスに適用されるコンピュータ発生スポットライトに対するソース及び行く先位置をユーザが選ぶことを含むであろう。
【０００４】
これらの位置が定義されると、次の作業は、各出力画像の各ピクセルの色及び輝度を決定するために定義された照明効果を適用することによって、出力シーケンスにおける各画像を描写することである。
【０００５】
【発明が解決しようとする課題】
現行の処理システムを使えば、描写は非常に時間を費やし、典型的な場合、或ビデオ・シーケンスの各画像を描写するために（そのシーケンスの長さによるが）数秒から多時間の時間がかかる。ユーザが経験する遅延を軽減するためには、処理パラメータ及びその複合効果における幾つか又は全部の処理動作に対する（描写された画像または動き追跡効果の場合の動きベクトル等の他の結果データ）結果がキャッシュ（隠し保存）される。
本発明は、描画に要する時間を短縮し、一度描画したもので再利用できるものは新たに描画することのないように保存し、かつ、保存のためのメモリを有効に活用することを課題とする。
【０００６】
【課題を解決するための手段】
本発明は、上記課題を解決するために下記の手段を備えたビデオ信号処理装置を提供する。即ち、画像又はデータの形で対応する処理結果を発生するために１つのビデオ信号からなる複数の画像に相次ぐビデオ信号処理動作が適用されるビデオ信号処理装置であって、キャッシュされたアイテム及びビデオ信号処理動作と関連する処理結果として保存するためのキャッシュ保存手段と、新たにキャッシュされるべきアイテムのためのキャッシュ・スペースを提供するために現在キャッシュされているアイテムを削除する手段であって、動きベクトルデータが画像データよりも長い間キャッシュの中に留められるように動作する削除手段と、を備えるビデオ信号処理装置を提供する。本発明は、また上記の手段によって表されるステップを含むビデオ信号処理方法も提供する。
【０００７】
本発明は、上記に参照した３クラスのデータのキャッシュ・スペースを認識する。即ち、パラメータ・データ、イメージ（画像）データ、及び動きベクトルである。画像データは、一般に、他の２つのクラスのデータよりも広大なキャッシュ・スペースを占領する。しかしながら、動きベクトルデータは描写のためになおも長時間をとり、キャッシュの中に留めておく価値がある。
【０００８】
それ故、本発明においては、動きベクトルデータは、画像データに優先して留められる。従って、この動きベクトルデータは長期にわたりキャッシュから適用でき、或画像をキャッシュするのに要するスペースに比べてほんの少量のキャッシュ保存スペースを犠牲にするだけである。現実に、少なくとも装置の特定の動作セッションの間、動きベクトルデータがキャッシュから決してフラッシュされないことが望ましい。
【０００９】
結果をキャッシュする主な理由は、有向非循環グラフにおける或特定の位置での効果が変えられると、例えばパラメータが変えられると、その変えられた効果が再描写されなければならない時、有向非循環グラフにおける先行効果がキャッシュから直接再使用できるからである。
【００１０】
これによって、例えば、もしユーザが新しいセットのパラメータを試みたがその結果が好ましくなく最新の変化がなされる前にその装置の前回の作業状態に戻したければ、その操作を非常に素早く「不履行」にすることもできる。処理パラメータを再入力し、装置がその結果の画像を再描画する代わりにそれらがキャッシュから即座に検索されるようにできる。
【００１１】
キャッシュは有限の容量を持つので、キャッシュされるニュー・アイテム（新規事項）のために使える余地を作るためには、時々このキャッシュはクリアされなければならない。一般に、キャッシュ中の最小の最近使われたアイテムが捨てられる。
【００１２】
【発明の実施の形態】
ここで、添付図面を参照して、例示のみとして、本発明の実施の形態を説明する。
連続するビデオ画像を含む、或ディジタル・ビデオ信号が入力インターフェース１００で受信されディスク・アレイ装置１１０に保存される。このディスク・アレイ装置１１０はこの装置によって生成されたどんな手作り画像も保存し、これらは、出力インターフェース１２０を介して出力へ供給できる。
【００１３】
中央処理ユニット１３０は、ユーザ・コマンドに応じてこのディスク・アレイ装置に保存されたデータにアクセスして、種々のビデオ特殊効果を実行する。ＣＰＵ１３０は、マウスやキーボード等のユーザ入力装置１４０からの入力を受け取り、メモリ１５０にワーキング・データ及びプログラム・コードを保存し、ディスプレイ・ドライバー（表示装置駆動装置）１７０を介して表示スクリーン１６０上に出力用データを発生する。
【００１４】
この装置は、例えば Microsoft Windows NT （商標名）オペレーティング・システムの下で適正なソフトで動く汎用コンピュータ（例えば、ＰＣ）として実装できる。本実施形態においては、ディスク・アレイはウルトラＳＣＳＩデータ・リンクを介してＣＰＵ１３０に接続される。
【００１５】
図２は、図１の装置のための動作ソフトウエアの（非常に一般的レベルで）組織化を図解したものである。このソフトウエアは、２つのカテゴリーのプログラム・コードとして配列されている。即ち、図２の左手に示されたコア・フレームワークと、図２の右手に示された種々のプラグインである。このソフトウエアが最初にロードされると、コア・フレームワークが何時も存在し、異なった特殊効果処理の間で共有された装置の動作部分を制御する。
【００１６】
これと対照的に、プラグインは、（照明効果、動き追跡効果等々の）個別の特殊効果と関係し必要な時だけロードされる。
これは非常に効率の良い装置である。何故ならば、ユーザによって現在要求された効果モジュールに関係するプラグインだけがメモリにロードされればよいからである。これによって、可能な特殊効果の全てに対してプログラム・コードがロードされなければならないシステムと比べてメモリの節約になる。これによって、装置の初期化が速くなり、システムが最初にスタートする時にメモリに全てのプログラム・コードをロードする必要性を避け、グラフ・エディタにおいてアイコンが最初に選択された時にコード・ローディングを通した如何なる遅延も減らすことができる。
【００１７】
更に又、この装置（配列）は、供給されインストールされる装置のサブセット（特に、動作ソフトウエア）が削減でき、グラフ・エディタ及びコア処理だけを含みプラグインを持たないようにできる。このシステムはまた、第三者またはユーザに対して、プラグインとコア・フレームワークの間の規定のインターフェース・プロトコルに留まる限り、彼ら自身のプラグインを作ることを許す。従って、ユーザは、比較的小さなプラグイン・プログラムを書くことにより注文効果を非常に簡単に作ることができる。
【００１８】
このコア・フレームワークとプラグインは、いわゆる「オブジェクト・リンキング及び埋込」（ＯＬＥ）プロトコルを使ってお互いに通信する。これについては、「Understanding ActiveX and OLE 」、David Chappell,Microsoft Press, 1996に説明されている。
【００１９】
ＯＬＥシステムにおいては、ソフトウエア設計者は、コンピュータプログラムの異なったセクションを「ＣＯＭ（Component Object Model）オブジェクト」として実現できる。各ＣＯＭオブジェクトは、１以上のＣＯＭインターフェースをサポートし、各々沢山の「メソッド」を含む。或メソッドは関数または詳細動作を遂行する手順である。ＣＯＭのメソッドはそのＣＯＭオブジェクトを使うソフトウエアによって呼び出すことができる。このシステムは制限されているから、ＣＯＭオブジェクトを使うソフトウエアの他の部分は定義されたインターフェースを介してのみそうすることができる。従って、定義されたＣＯＭインターフェースを介する以外にそのオブジェクト内部のプログラム・コードまたはデータに直接アクセスすることはできない。
【００２０】
そこで、本システムにおいては、コア・フレームワークはこれらのＣＯＭインターフェースを介してプラグインと通信する。（事実、コア・フレームワークはＣＯＭインターフェースを提供することのできる沢山の相互通信オブジェクトを含む。）
【００２１】
図３は、オペレーティング・ソフトウエアの組織を図２に示したよりもずっと詳細に図示したものである。図３においては、線図は４つの四角に分けられている。左上の四角は、いわゆるビュー・ウインドウ３１０を示し、右上の四角は効果ユーザ・インターフェース（ＵＩ）３２０を示し、右下の四角は、関連するパラメータデータ（ＰＤ）を有する効果サーバー３３０を示し、左下の四角は、オブジェクト・マネージャー３５０、描画マネージャ３５２、変化マネージャ３５８と一緒にグラフを含むコア・プロセッサ３４０を示す。
【００２２】
左下の四角と右下の四角の間のインターフェースの所に、Window NT レジストリーの部分を形成するメタ・データベース３５４があり、効果アイコンを含むパレット３５６およびデフォルト・パラメータ値がある。このメタ・データベース３５４は、図１１を参照して、パレットは図６〜９を参照して更に詳しく説明する。
【００２３】
コア・プロセッサ３４０内には、リンクされた一連の個別特殊効果を有するグラフ、実際には「有向非循環グラフ」がある。各効果は、グラフの中に、それが使えるようになるとすぐにその効果出力を保存するための関連したキャッシュ（Ｃ）を有するプロクシー効果（ＰＥ）として表される。それによって、例えばもしそのチェイン（連鎖）において高い方の効果が変わると、その効果の連鎖の中の効果からデータを再使用できるようにする。各プロクシー効果は夫々の効果サーバー３３０と関連付けられている。
【００２４】
オブジェクト・マネージャー３５０は、そのシステム内のアクティブ・オブジェクトの寿命とメモリ・マネージメントを制御する責任がある。描写マネージャー３５２は描画作業の開始、進行、優先化、及び停止を制御する。変化マネージャー３５８は不履行／再履行情報および変化をシステムの種々の部分へ通知することを制御する。
【００２５】
図３の基本的な部分は、左手の２つの四角（左上及び左下）がコア・フレームワークの特色に関係し、如何なる特定の効果にも特定されない。これらのオブジェクトは、どの特定の特殊効果をユーザが実施しようと望むかに関わらずメモリーにロードされる。右手の２つの四角（右上及び右下）はプラグインに関係する。各プラグインは、そのプラグインによって遂行される効果に関連する処理を実行するサーバー３３０と、その効果に関係するユーザ・インターフェース・コントロール（実際には、ビューア・ウインドウ３１０の表示用）を提供するユーザ・インターフェース３２０を持つ。
【００２６】
図３においては同様な上から下への分割がある。上方の２つの四角（左上及び右上）は特殊効果に関連したユーザ・インターフェース・コントロールに関係し、下方の２つの四角（左下及び右下）はそれらの効果を実施するために遂行される処理または組織に関する。
【００２７】
ビューア・ウインドウは、ユーザに、その装置によって実行するために作り上げた一連の効果における或特定の効果の出力及びそれに対するパラメータを見る機会を与える。それゆえ、ユーザによってビューア・ウインドウが開かれると、或効果の出力が発生されるか、もし適用できれば、キャッシュ・ストアから検索されなければならない。
【００２８】
複数のＣＯＭオブジェクトを採用したこのタイプのシステムにおいては、各オブジェクトがその仕事又は結果データを別のデータファイルに保存する（ような）ことは一般には望ましくないと考えられる。事実、そのような装置（配列）はＯＬＥシステムの設定につながる多くの理由付けに反している。その代わりに、このタイプのシステムにおけるデータは、単一ファイル又は「複合ドキュメント」における全てのオブジェクトによって保存されるが、その複合ドキュメント内部の順序付けされた構造を使って行われる。
【００２９】
基本的には、複合ドキュメントの内側では、ファイル及びディレクトリ構造に類似した構造が準備される。ディレクトリに等しいものは、いわゆる「保存」であり、ファイルに類似のものは、いわゆる「ストリーム」である。各複合ドキュメントはルート保存を含み、その下にお馴染みの保存とストリームのトリー構造がある。このＣＯＭストリーム・インターフェースはＣＯＭ保存インターフェースよりももっと簡単であるが、勿論この保存インターフェースはもっと柔軟性がある。
【００３０】
一般に、各ＣＯＭオブジェクトは、そのワーキング・データを保存するそれ自身の保存装置又はそれ自身のストリームに割り当てることができる。しかしながら、コア３４０が沢山のプラグインの動作を調整する本ビデオ特殊効果処理装置等の階級システムにおいては、前のシステムに使われている装置（配列）は各効果プラグインにストリームを割り当てる。
【００３１】
それに比べて、本実施形態においては、保存装置又はストリームのどちらかをプラグインに単純に割り当てるとプラグイン・オブジェクトの設計及び動作に制約が多すぎることが認識される。それに代えて、コアとプラグインの間のインターフェース定義において、各プラグインは、（プラグイン設計者に望ましければ、そのワーキング・データを直接に保存できるように）ストリームと（もし望ましければ、そのワーキング・データをそれ自身の「ディレクトリ」配列のストリーム及び保存装置に保存するように）保存装置との間で選択できる。この選択は、プラグイン設計者がプラグイン・プログラム・コードを作ることによって前もって作られる。
【００３２】
以降の説明において、種々のオブジェクトの間の通信プロトコルは図４及び５と関連して説明する。コア・プログラム３４０のグラフ・エディタ部分が、複合効果を形成するために個々の効果の連鎖を設立するのに使われる方法は、図６〜９と関係して説明する。ビューア・ウインドウ及びそれらの効果ＵＩ３２０（複数個ある）との相互作用は図１０を参照して説明する。
【００３３】
図４は、図３の装置における更新された効果パラメータの伝搬を図示している。
この状況の一例は、ユーザが照明特殊効果を設定するということであり、そこでは画像に光源の効果が加わる。光源は、その画像に関するユーザ定義可能なソース及び目的位置を有する。もし、ユーザがこれらの位置の１つを変えたいならば、現在描写されている出力のどれでもその効果から無効（invalidate）にし、図３の異なった四角に示された種々のオブジェクトの間で変化を伝搬させる必要がある。この処理は図４に示されている。
【００３４】
図４を参照すると、ユーザはビューウインドウ３１０（図１０参照）を介して変化されたパラメータを実際に入力する。このビューア・ウインドウは特定の効果ＵＩ３２０と関連付けられており、それが個々の効果に関係するプラグインの部分になる。（事実、１以上の効果に対して単１ビュー・ウインドウを関連させることができ、全ての効果がビューア・ウインドウを任意の特定の時間に開く必要はなく、この検討のために図３の簡単化された装置（配列）が維持される。
このプラグインはコアに対して「エディット開始（about to edit ）」を発行する。
【００３５】
変更を行った後、プラグインはコアに対して「変化有り（change occurred ）」通知を発行する。これは、一連の動作を含むかそれらを開始するか又はその両方を行う。最初のステップ４０１として、ビューア・ウインドウは効果ＵＩ３２０に更新されたパラメータを通信する。この効果ＵＩ３２０は対応する効果サーバー３３０に「セット」命令を発行し、効果サーバー３３０内部のパラメータ保存装置に改訂された値をセットする。これは図４のステップ４０２である。
【００３６】
ステップ４０３において、効果サーバー３３０はコア３４０に「undo/redo 」オブジェクトを書き、変化前と後のパラメータの（効果サーバーにおける）レコードを指すハンドル又はポインターの詳細を提供する。このundo/redo オブジェクトの受領に応答して、ステップ４０４でコアは全てのビューア・ウインドウに対してパラメータが変更されたこと及び或キャッシュされたデータ出力が無効にできることを伝える。この通知は、パラメータ変化が起こったビューア・ウインドウに特有なものではない。
【００３７】
ステップ４０５では、各ビューア・ウインドウは、その処理パラメータの更新を要求している対応する効果ＵＩ３２０にメッセージを発行する。ステップ４０６で、その効果ＵＩ３２０は、その新しいパラメータを得るために対応する効果サーバーに対して get コマンド（命令）を発行し、ステップ４０７で効果ＵＩ３２０にその新しいパラメータが返される。この効果ＵＩはステップ４０８でビューアウインドウに表示のためその変化を伝搬する。
【００３８】
一般に、処理パラメータが変化した時、１つ以上の効果の出力を再描画することを必要とする結果になる。図５は、再描画コマンドが装置を通って伝搬される方法を図解しており、図４の処理から続く。
ステップ５０２では、ビューア・ウインドウは再描画マネージャー（管理部）に再描画コマンドを発行する。この描画管理部（マネージャー）は対応する効果サーバー３３０に再描画コマンドを発行する。効果サーバーが画像の再描写を終わった時、コア３４０に「終了」メッセージを発行する。このコアはステップ５０５でビューア・ウインドウにこれを通信する。そしてステップ５０６及び５０７でビューア・ウインドウは効果ＵＩ３２０と相互作用して再描画された効果出力を表示する。
【００３９】
数個のビューア・ウインドウが開かれており、数個のフレームが関心のある領域（これは、テストの目的で、全てのビデオ・クリップのサブセットとしてユーザによって定義できる）にある時、複数の画像が、処理リソース（資源）を割り当てるための下記の優先順位に従って、複数の同時作業として描かれる。
（ｉ）ユーザによって現在ビュー用に表示されている画像（１つ又は複数）；
（ｉｉ）関心のある出力順序の最初と最後の画像；
（ｉｉｉ）関心のある出力順序の残りの画像
【００４０】
詳細の他のレベルとして、描画マネージャ−が効果サーバーに再描画コマンドを発行する前に、この描画マネージャーは「描画準備（prepare to render ）」メッセージを発行してその順序（シーケンス）の中のどの画像が描画されるべきなのかを詳細指定する。
【００４１】
この効果サーバーは、その「依存性」、即ち描画マネージャーによる要求が実行できる前には必須であるそれらの描画された画像の通知に関して応答する。
これらは、もう一つの効果（例えば、有向非循環グラフにおけるすぐ前の効果）によって描かれた画像であるかもしれないし、その効果自体によって描かれた画像かもしれない。この後の場合は動き追跡の例で起こり得るが、そこでは、画像５を描画するために、動き追跡は画像４に対するそれ自身の描写された出力を必要とする。
【００４２】
効果サーバーから戻って受信されたメッセージに応答して、この描画マネージャーはそれらの画像を要求している「描画準備」メッセージを送り、依存トリーが終わるまでそうし続ける。
各段階において、この効果プロクシーは、要求された画像又は描画された出力がキャッシュされたか否かをチェックし、描画マネージャ−に通知する。
【００４３】
そこで、例えば、もし描画準備メッセージが画像５を詳細指定する動き追跡部に送られると、それが画像４に対する描画された出力を要求することに応答するかもしれない。描画マネージャーは、画像４に対する動き追跡部にメッセージを描く準備を送る。また、この動き追跡部はそれが画像３等を要求することを示すために応答する。この方法で、要求される画像（画像５）が描かれる前に必要な描画作業のリストが作り上げられる。キャッシュに保持された描画された出力は描画マネージャーの作業リストには含まれていない。
【００４４】
或効果が先行する効果の描画された出力を要求するところでは同じことが起こり、そのようにして一連の効果を下方にたどる。
この処理の終わりに、描画マネージャ−が、その依存する画像が全て描写されるまで現在要求されている画像が描かれないように逆の順序で行われる必要な作業の全てをセットする。
【００４５】
最適化として、この描画マネージャーはグラフから各効果に対する入力が何であるかを検出できる。それゆえ、この効果サーバーは、単純に「この効果に対する入力の全てが要求されている」というために、予め定められたコード（例えば、ｎｕｌｌ応答）を送ることができる。
【００４６】
更に他の拡張として、各効果サーバーが描画マネージャーに、その出力が隣接画像の間で同じであるか否かを通知する目的で同じプロトコルが使える。これの簡単な例は（固定）パラメーター・プラグインであり、出力は不変（ｉｎｖａｒｉａｎｔ）である。更に他の例は、出力が既に準備されていてキャッシュされているので、連続する出力が同一であるか否かについて直接の検出ができるという任意の他の効果である。
【００４７】
そのような通知に応答して、この描画マネージャーは、後ほど有向非循環グラフにある効果サーバー上に情報を送る。そこで、その効果サーバーは、（もし適正であれば）或範囲の画像の中の１つだけを描画し、その入力が同じに留まっていれば他の画像に対してその出力を繰り返すことができる。
【００４８】
図６はグラフ編集ウインドウ６００及びパレット・ウインドウ６１０を図示する。これらは、コア３４０の制御の下に表示スクリーン１６０上に表示される。
パレット・ウインドウ６００は、沢山のアイコン６２０を含み、各々がマップされ、その効果のためにそのシステム上にプラグインが存在するところの異なった可能な効果を表している。マウス・コントロールを使えば、ユーザはこれらのアイコンをスクロール可能なグラフ・ウインドウ６１０にドラッグできる。これらのアイコンはユーザによってグラフ・ウインドウの中に相互に関連して配列され論理リンク６３０とリンクできる。これについては、ウインドウ中にグラフ状の線で示してある。
【００４９】
リンク６３０は、或効果の出力を後続効果の入力へ送ることを表しており、（この実施形態において）グラフの底部からそのグラフ・ウインドウの頂部に向かう方向を常に持つ。それゆえ、図６に示された例では、その出力を照明効果６５０に送る画像ローダー・アイコン６４０を持つことを表している。
ユーザがグラフ・ウインドウの中にグラフィカル・リンクを設定すると、コア３４０は論理リンクを設定して、描画された出力が１効果プラグインからもう１つへ送られる方法を決定する。
【００５０】
図７を参照して、グラフィカル・リンクが作られる方法を説明する。この論理リンクは、図９を参照して説明する。
図７において、ユーザは（例えばマウス・クリックを使って）照明効果を選択し、今、アイコン６５０からマウス・ポインター７３０に向けて方向付けされた可動グラフィカル・ライン７２０を持つ。
マウス・ポインターが混合効果アイコン７００に近ずくにつれて、その混合アイコンは拡大し、または拡大された７１０で囲まれ、境界７４０の底部に２つの入力ポートを示す。
【００５１】
マウス・ポインターが入力ポートの１つに近づくと、グラフィカル・ライン７２０がその入力ポイント上にポンと動き、マウス・クリックすると定位置に固定できる。これによって、効果６５０と効果７００の間の論理的及びグラフィカル接続を設立する。
こうした論理的及びグラフィカルな接続が設立されると、ユーザはそのグラフ・ウインドウの効果アイコンのリンクされたグループ８００をボックス化できる。
【００５２】
ここで、ボックス化とは、コンピュータ・マウスを使って標準の方法でそのグループの周りにボックスを描くことを意味する。（これが実施される１つの方法は、そのボックスの左上隅でクリックし保持することであり、マウスを右下隅にドラッグし、マウス・ボタンを解放する。これは複数のスクリーン・オブジェクトを選択する標準の方法である）。
【００５３】
ユーザは、そのリンクされたグループの効果をパレット領域にドラッグすることができる。これは、その入力からグループに形成された１セットの入力を有し、出力からそのグループに形成された１セットの出力を有する新しい複合アイコン８１０を作る。論理用語で言えば、効果アイコン８１０が或特定のプラグインにマップされる代わりに、特定の方法で相互接続された１つのリンクされたグループのプラグインにマップされる。
【００５４】
複合効果アイコン８１０は、ユーザによってグラフを設計する際に使われるパレットの部分を形成する。その後、もしユーザが複合アイコン８１０を使うことを望むならば、それを単純にグラフ・ウインドウ上の場所にドラッグする。好ましくは、この効果アイコン８１０はグラフ・ウインドウ上では単一アイコンとして留まるが、他の実施においては、それは元のグループ８００へと拡張できる。
【００５５】
さらに他の変形として、単一アイコンとしてその圧縮形で表示することができるが、元のグループのアイコン８００を表示するためユーザが拡張ボタンをクリックできるように「拡張」ボタンを使って表示される。少なくとも、アイコン８１０によって提供される複合効果は元のグループ８００のコピーである。
【００５６】
図９はこのプロセスの下位にあるデータ保存部を図解したものである。図９において、アイコン８５０はパレット領域６００のパレット・アイコン６２０からグラフ・エディタ領域６１０にドラッグされている。
【００５７】
パレット領域６００と関連して、図３に示されたパレット３５６に保存されるものに、ルート８６０及びそのルートから依存する個別データ項目８７０を有するトリー（樹枝構造）として配列されたデータ構造がある。効果８７５等の複合効果の場合を除いて、各データ・アイテム８７０は１効果アイコン６２０を表す。
ここでは、その効果を形成する効果アイコン（３ａ、３ｂ）は、そのデータ・アイテム８７５から依存するサブ・ストラクチャで配列されている。
【００５８】
グラフ・エディタ領域に効果を格納するために、類似のデータ構造が存在する。
ここでは、ルート８８０はそれに依存する１つの効果８８５を持つものとして示されている。もし、沢山の効果がグラフ・エディタ領域に一緒にグループ化されパレットにドラッグされれば、それらはストラクチャー８７５に類似した更に他の複合効果ストラクチャーを形成する。
【００５９】
図１０は、ビューア・ウインドウを図示したものである。このビューア・ウインドウは画像表示領域９００、種々のプロパティー・ページ９１０、効果コントロール９２０（ここでは、照明効果の例における位置指定＋印として示してある。）、及び「ボタン・バー」９３０を含む。
ビューア・ウインドウの基本レイアウトは、コア・フレームワークによって設定され、効果から効果への標準である。しかしながら、プロパティ・ページ９１０を使って調整できる特定のアイテムは、或特定の効果に対応する効果ＵＩ３２０によって設定される。この効果ＵＩはコントロール９２０に対する表示の詳細も提供する。
【００６０】
示された例においては、＋印９２０は照明効果におけるライトのソース位置又はターゲット位置を決定する。ユーザはコンピュータ・マウスを使ってこの＋印をドラッグすることができる。＋印をドラッグすると、そのコントロールに関連するパラメータ（ｘ，ｙ）値を変えるので、図４の手順（パラメータ値の更新）が開始される。
【００６１】
その手順の最後の部分で、ステップ４０８において、この効果ＵＩは訂正されたパラメータ値をビューア・ウインドウに発行する。その段階で、＋印はその新しい位置において再描画される。それゆえ、ユーザの目には、それはドラッグによって＋印がその究極位置に動いたように映るが、実際にはドラッギング動作はパラメータを更新したのであり、図４に示されたルートによって、＋印の動きとなったのである。
【００６２】
図１１は、動作ソフトウエアの最初の配列を図示する。これは、装置の特定の動作セッションにおいて、いかなる描写も行われる前の状況を表している。
プラグインは、「ダイナミック・ロード・ライブラリーＤＬＬとしてウインド・オペレーティング・システム下で実施される。ＤＬＬは、一般にプログラム・コード、データ、およびサブルーチン・ライブラリーを含むことのできる大きなファイルである。
【００６３】
従来は、ＤＬＬは、メモリを節約するために、及びシステム性能を改善するために、そのＤＬＬによって扱われる特定のプロセスの実行又は開始のために初めて必要になった時にメモリにロードされた。本実施形態においては、メモリを節約しシステム性能を改善するというこのアイデアは一歩進められている。
【００６４】
或効果アイコンがパレット領域から最初に取り出される時、従来は、その効果に対応するＤＬＬがメモリにロードされて、コア３４０にビルドされるべきグラフのための充分な情報（例えば、他の効果アイコンとの相互接続性）を提供する。
本実施形態においては、その効果のためのＤＬＬはその段階ではロードされない。その代わりに、その効果を表す、いわゆる「メタ・データ」１０００がロードされる。このメタ・データはコアに他の効果（例えば、沢山の入力及び出力）と当該効果との相互接続性を定義する情報を提供する。これによって、コアがいかなるＤＬＬもロードする必要なしにグラフをビルドアップできるようにし、それらが絶対的に必要になるまで大きなファイルをロードしないでメモリを節約する。
【００６５】
もし、或効果と関係してビューア・ウインドウが開かれると、または、もし何らかの他の手段によってその複合効果が実行されると、ＤＬＬはロードされ、そのメタ・データは捨てられるか無視される。
図１２〜１４は、システムのオートメーションを（他にも増して）容易にする効果プラグインの特色を示している。
【００６６】
図１２は、以前に提案された効果プラグインを図示する。この効果は画像情報（「クリップ」１３００として示されている）をとり、３つの処理パラメータＰ１，Ｐ２，Ｐ３（照明位置等）を基にして活動する。図１２のプラグインにおいては、パラメータ値は、プラグイン内部に、即ち、プラグインの一部として書かれた注文プログラム・コードによってセットされる。
このことが、パラメータ（例えば、パラメータが時間によって変化するアニメーションシステム、又は照明位置等のパラメータが動き追跡部等の他の効果によって変えられる装置において）の全体の制御を非常に困難にしており、効果プラグイン内部及びしばしば効果プラグインの複数バージョン内に追加コードを要求する。
図１３は、本発明の実施形態に従う、もう１つのアプローチを図示する。ここでは、各パラメータは、別のプラグイン１３２０によって定義され、それらは上記グラフ・エディタにおいて効果間のリンクが定義されているのと同じ方法で「主」効果プラグイン１３３０にリンクされる。事実、上に説明されたことは全プロセスの簡略化であり、この簡略化はその段階では説明を助けるためになされている。
【００６７】
パラメータ・プラグインは、例えば「オフ・ザ・ページ」グラフ・エディット及びパレットにおけるスクリーン位置の所にそれらを表示することにより、通常はユーザから隠されている。もし、或効果が、自蔵、非アニメーション化で動作させられるならば、（即ち、他の効果からパラメータをインポートしなければ）、主効果ビューア・ウインドウを使う各パラメータ・プラグイン１３２０に対してパラメータがセットされる。
【００６８】
もし、パラメータが他の効果出力、例えば、動き追跡効果によって提供される位置値によって定義されるべきであれば、要求される全ては、主効果プラグイン１３３０と切断すべき適正なパラメータ・プラグイン１３２０の間の論理リンク及び開始されている動き追跡効果へのリンクに対してである。このシステムがアニメーションにおいて如何に手助けになるかを理解するために図１４を参照する。
【００６９】
図１４において、初め図３に示されたコアとプラグインの間の左右の分割を示す。図１４の左手側には、「主」効果サーバー１３５０に対してプロクシー効果（ＰＥ）１３４０が準備されている。パラメータ・プラグイン１３２０の各々に対しても、プロクシー効果１３６０が準備されている。
【００７０】
これらのプロクシー効果１３６０はプロクシー効果１３４０よりもずっと簡単な性質からなり、プロクシー効果１３６０とパラメータ・プラグイン１３２０の間の通信は、プロクシー効果１３４０と効果サーバー１３５０間の通信プロトコルの簡略化されたサブセットを使う。
【００７１】
実際には、プロクシー効果１３６０は単一データ値（非アニメーション化システムにおいて）、またはアニメーション・システムにおいては複数値のリストとすることができる。アニメート化されたシステムにおいては、値のリストは、「キー・フレーム」値、即ち、線形もしくはユーザ定義の非線形補間に従ってコアによって補間される中間値を備えた、順序配列された特定の複数画像に対するデータ値セットとすることができる。それゆえ、アニメーションは、各プラグイン内に注文のアニメーション・ソフトウエアを書く必要なしで特定の簡単で都合のよい方法で、設定できる。
【００７２】
この記述を、効果の間の依存性について前に与えられた記述と関係付ければ、描写マネージャーからの「描写準備」メッセージが効果サーバー１３５０で受信された時、それは、その出力が準備できる前にその入力の全てを要求するということをいうために応答できる。この効果入力には勿論パラメータ・プラグインが含まれるので、次の段階は、描画マネージャーが各パラメータ・プラグインに描写準備メッセージを送ることである。
【００７３】
もしパラメータ・プラグインが単一値を含み、または現在の画像がキー・フレームならば、このパラメータ・プラグインは動作時に適正なパラメータを準備する用意ができている。しかしながら、もしそのパラメータ・プラグインがアニメーション・データを含み、現在の画像がキー・フレームではないならば、このパラメータはその効果で使われる前に最初に補間されなければならない。
【００７４】
図１５は、システム・キャッシュ１１００を図示する。これは全キャッシュ領域のビューであり、事実前に説明したとおり、キャッシュは夫々のプロクシー効果に関連した複数の個別キャッシュとしても見ることができるが、メモリ資源がそのような個別キャッシュの間で動的に割り当てられるので図１５の表現も有効である。
このキャッシュはシステム・メモリ１５０に準備され、効果（例えば、動き追跡効果の場合に動きベクトル）からの画像１１１０及び非画像描写出力１１３０を保存することができる。
【００７５】
キャッシュという考え方は、有向非循環グラフにおける各効果の描写された出力（これが画像であるか否かにかかわらず）を保存することである。この方法でもし或効果がその有向非循環グラフの中の特定の位置で変えられれば、その位置の下の効果は新しい出力を準備するために再描写される必要がない。その代わりに、キャッシュされた出力が再使用される。もう一つの利益は、パラメータ変化がなされた前後で（開いているビューア・ウインドウにかかる）複数の特定の効果の出力を保存することにより、undo/redo （不履行／再履行）動作を援助しスピードアップすることである。
【００７６】
対応するパラメータ変化も同様に保存されるので、このパラメータ変化は、キャッシュ・メモリ１１００から適正なマテリアルを単純にロードすることにより不履行または再履行できる。これは、変化が起きた時に効果サーバーによって書かれたundo/redo オブジェクトの制御の下におかれている。
【００７７】
画像は、動きベクトルのような単純データよりもずっと多くのメモリ・スペースをとる。多分１００万倍もの多くのメモリ・スペースをとる。それゆえ、本実施形態においては、そのキャッシュ・メモリが容量いっぱいに近づき、かつ他の画像が保存されようとしているとき、そのキャッシュの中の最も古い（最近読み出されていない）画像を削除して、新たに保存する画像のための余地をつくる。しかしながら、キャッシュ中の他のデータ、パラメータ値、非画像描写出力等は、装置の動作セッション中には削除されない。何故ならば、それは画像と比べて小量のメモリ・スペースを消費するからである。この情報は、１つの動作セッションを通じてその情報が有効に留まる限り、再使用、不履行／再履行動作、のために使うことができる。
【００７８】
実行に際しては、慣例によってフラッシュ可能としてセットされている画像データ・アイテム、および非フラッシュとしてセットされている非画像アイテムと一緒に、１つのデータ・アイテムがフラッシュできるか否かをプラグインが詳細指定することは後に残しておくことができる。
【００７９】
図１６は、コア３４０と効果サーバーの間で非同期・同期の変換を行う変換器１２００を示す。
このコンバータ１２００は、「ｔｏ ｄｏ」待ち行列、即ち行うべき描画作業のリストの形で描画マネージャーから非同期再描画命令を受信する。
一つの作業が終了すると、「終了」メッセージがコンバータ１２００から描画マネージャ−に戻される。
コンバータ１２００はこの非同期作業要求を受け取って適正なソフトウエア・プラグインに同期リクエストを発行する。これは、インターフェース１２００がソフトウエア・プラグインに制御スレッド（ウインドウ用語）を送り、該プラグインは作業が終了するまでそのスレッドのコントロールを保持する。
【００８０】
その後のみ、そのソフトウエア・プラグインはインターフェースにスレッドを戻す。インターフェースはコアに「終了」メッセージを発行することによって応答する。
初期化の際に、コアは各プラグインに（又はそのプラグインに関連したメタデータ）に応答指令を出してそのプラグインが同期または非同期通信ができるか否かを決定する。この方法の動作にはハードウエア・アクセレレータがもっと良く適合するので、もし、ハードウエア・プラグイン（例えば、特定の方法で描写するための周辺カード）または、できれば異なったマシン上で動作する、非同期ソフトウエア・プラグインが、或ソフトウエア・プラグインの代わりにインストールされれば、そのプラグインは非同期インターフェースによって（実際、描写を開始する描写マネージャーが非同期的に働く）コアと相互作用する。
それゆえ、この場合には、コンバータ１２００はバイパスされる。
このコンバータは、コアの一部又は各関連するプラグインの一部として実装される。
従って、２つの部分のソフトウエアの間にコンバータ１２００を提供する直感に反したステップによって、専用のハードウエアに後でグレード・アップするために効率的なハードウエア・インターフェースが準備される。
【００８１】
【発明の効果】
本発明のビデオ信号処理装置は、
キャッシュ・メモリを使って、そこに有向非循環グラフ（方向性を有し回転した時に元に戻らないような形状の画像）を保存することにより、ある種の変化に対しては新しい出力を準備するために再描写する必要がなくなる。
【００８２】
また、このキャッシュ・メモリにパラメータ変化がなされた前後で（開いているビューア・ウインドウにかかる）複数の特定の（特殊）効果の出力を保存することにより、undo/redo （不履行／再履行）動作を行うことができるので、装置のスピードアップを図ることができる。
【００８３】
動きベクトルのような単純データよりもずっと多くのメモリ・スペースをとる画像データについてはメモリの容量いっぱいに近づき、かつ他の画像が保存されようとしているときに、削除して、新たに保存する画像のための余地をつくるようにするが、キャッシュ中の他のデータ、パラメータ値、非画像描写出力等は、装置の動作セッション中には削除されないようにして、メモリを有効使用することができる。
【図面の簡単な説明】
【図１】ディジタル・ビデオ特殊効果装置のブロック図である。
【図２】図１の装置の動作ソフトウエアの組織ブロック図である。
【図３】図１の装置にたいする動作ソフトウエアの組織を更に詳しく示すブロック図である。
【図４】図１の装置における更新された効果パラメータの伝搬を示す線図である。
【図５】図１の装置における再描画命令の伝搬を示す線図である。
【図６】エディット・ウインドウ及びパレット・ウインドウの線図である。
【図７】エディット動作を説明するための線図である。
【図８】複合効果アイコンの構築を示す線図である。
【図９】複合効果のファイル構造を示す線図である。
【図１０】ビュー・ウインドウを示す線図である。
【図１１】動作ソフトウエアの初期配列を示す線図である。
【図１２】前回提案された効果プラグインを示すブロック図である。
【図１３】効果プラグインの新形式を示すブロック図である。
【図１４】図１３の効果サーバーと効果プラグインのためのプロクシー（代理）効果の間の関係を示す線図である。
【図１５】システム・キャッシュを示す線図である。
【図１６】プラグイン・インターフェースを示すブロック図である。
【符号の説明】
１１００・・・システム・キャッシュ、 １１１０・・・画像保存、
１１３０・・・非画像描写出力
【発明の属する技術分野】
本発明はディジタル・ビデオ信号処理装置におけるキャッシングに関する。
【０００２】
【従来の技術】
ビデオ特殊効果装置等のビデオ信号処理装置においては、一つのビデオ・シーケンスの複数の画像に対してディジタル信号処理が適用される。
そのようなシステムの一例において、ユーザは、沢山の適用可能なモジュールから一連の効果モジュールを選択することによって、或ビデオ・シーケンスに適用すべき複合特殊効果を設定することができる。例えば、ユーザによって設定される一連の（又は「有向非循環グラフ」の）効果は、下記のことを含む。即ち、
（ｉ） 画像ロード手段
（ｉｉ） 動き追跡手段
（ｉｉｉ）動き追跡及び画像ロードにリンクされた照明効果
（ｉｖ） 動き追跡及び画像ロードにリンクされた画像の再配列
【０００３】
特殊効果が選択され、全てのパラメータが定義されると、「描写（rendering ）操作が行われなければならない。描写は、設定された処理操作に従って、出力画像、出力ビデオ・シーケンス又は或画像内の動きベクトル又は位置等の中間データ・タイプを形成する一連の画像を生成する処理である。例えば、照明効果は、ビデオ・シーケンスに適用されるコンピュータ発生スポットライトに対するソース及び行く先位置をユーザが選ぶことを含むであろう。
【０００４】
これらの位置が定義されると、次の作業は、各出力画像の各ピクセルの色及び輝度を決定するために定義された照明効果を適用することによって、出力シーケンスにおける各画像を描写することである。
【０００５】
【発明が解決しようとする課題】
現行の処理システムを使えば、描写は非常に時間を費やし、典型的な場合、或ビデオ・シーケンスの各画像を描写するために（そのシーケンスの長さによるが）数秒から多時間の時間がかかる。ユーザが経験する遅延を軽減するためには、処理パラメータ及びその複合効果における幾つか又は全部の処理動作に対する（描写された画像または動き追跡効果の場合の動きベクトル等の他の結果データ）結果がキャッシュ（隠し保存）される。
本発明は、描画に要する時間を短縮し、一度描画したもので再利用できるものは新たに描画することのないように保存し、かつ、保存のためのメモリを有効に活用することを課題とする。
【０００６】
【課題を解決するための手段】
本発明は、上記課題を解決するために下記の手段を備えたビデオ信号処理装置を提供する。即ち、画像又はデータの形で対応する処理結果を発生するために１つのビデオ信号からなる複数の画像に相次ぐビデオ信号処理動作が適用されるビデオ信号処理装置であって、キャッシュされたアイテム及びビデオ信号処理動作と関連する処理結果として保存するためのキャッシュ保存手段と、新たにキャッシュされるべきアイテムのためのキャッシュ・スペースを提供するために現在キャッシュされているアイテムを削除する手段であって、動きベクトルデータが画像データよりも長い間キャッシュの中に留められるように動作する削除手段と、を備えるビデオ信号処理装置を提供する。本発明は、また上記の手段によって表されるステップを含むビデオ信号処理方法も提供する。
【０００７】
本発明は、上記に参照した３クラスのデータのキャッシュ・スペースを認識する。即ち、パラメータ・データ、イメージ（画像）データ、及び動きベクトルである。画像データは、一般に、他の２つのクラスのデータよりも広大なキャッシュ・スペースを占領する。しかしながら、動きベクトルデータは描写のためになおも長時間をとり、キャッシュの中に留めておく価値がある。
【０００８】
それ故、本発明においては、動きベクトルデータは、画像データに優先して留められる。従って、この動きベクトルデータは長期にわたりキャッシュから適用でき、或画像をキャッシュするのに要するスペースに比べてほんの少量のキャッシュ保存スペースを犠牲にするだけである。現実に、少なくとも装置の特定の動作セッションの間、動きベクトルデータがキャッシュから決してフラッシュされないことが望ましい。
【０００９】
結果をキャッシュする主な理由は、有向非循環グラフにおける或特定の位置での効果が変えられると、例えばパラメータが変えられると、その変えられた効果が再描写されなければならない時、有向非循環グラフにおける先行効果がキャッシュから直接再使用できるからである。
【００１０】
これによって、例えば、もしユーザが新しいセットのパラメータを試みたがその結果が好ましくなく最新の変化がなされる前にその装置の前回の作業状態に戻したければ、その操作を非常に素早く「不履行」にすることもできる。処理パラメータを再入力し、装置がその結果の画像を再描画する代わりにそれらがキャッシュから即座に検索されるようにできる。
【００１１】
キャッシュは有限の容量を持つので、キャッシュされるニュー・アイテム（新規事項）のために使える余地を作るためには、時々このキャッシュはクリアされなければならない。一般に、キャッシュ中の最小の最近使われたアイテムが捨てられる。
【００１２】
【発明の実施の形態】
ここで、添付図面を参照して、例示のみとして、本発明の実施の形態を説明する。
連続するビデオ画像を含む、或ディジタル・ビデオ信号が入力インターフェース１００で受信されディスク・アレイ装置１１０に保存される。このディスク・アレイ装置１１０はこの装置によって生成されたどんな手作り画像も保存し、これらは、出力インターフェース１２０を介して出力へ供給できる。
【００１３】
中央処理ユニット１３０は、ユーザ・コマンドに応じてこのディスク・アレイ装置に保存されたデータにアクセスして、種々のビデオ特殊効果を実行する。ＣＰＵ１３０は、マウスやキーボード等のユーザ入力装置１４０からの入力を受け取り、メモリ１５０にワーキング・データ及びプログラム・コードを保存し、ディスプレイ・ドライバー（表示装置駆動装置）１７０を介して表示スクリーン１６０上に出力用データを発生する。
【００１４】
この装置は、例えば Microsoft Windows NT （商標名）オペレーティング・システムの下で適正なソフトで動く汎用コンピュータ（例えば、ＰＣ）として実装できる。本実施形態においては、ディスク・アレイはウルトラＳＣＳＩデータ・リンクを介してＣＰＵ１３０に接続される。
【００１５】
図２は、図１の装置のための動作ソフトウエアの（非常に一般的レベルで）組織化を図解したものである。このソフトウエアは、２つのカテゴリーのプログラム・コードとして配列されている。即ち、図２の左手に示されたコア・フレームワークと、図２の右手に示された種々のプラグインである。このソフトウエアが最初にロードされると、コア・フレームワークが何時も存在し、異なった特殊効果処理の間で共有された装置の動作部分を制御する。
【００１６】
これと対照的に、プラグインは、（照明効果、動き追跡効果等々の）個別の特殊効果と関係し必要な時だけロードされる。
これは非常に効率の良い装置である。何故ならば、ユーザによって現在要求された効果モジュールに関係するプラグインだけがメモリにロードされればよいからである。これによって、可能な特殊効果の全てに対してプログラム・コードがロードされなければならないシステムと比べてメモリの節約になる。これによって、装置の初期化が速くなり、システムが最初にスタートする時にメモリに全てのプログラム・コードをロードする必要性を避け、グラフ・エディタにおいてアイコンが最初に選択された時にコード・ローディングを通した如何なる遅延も減らすことができる。
【００１７】
更に又、この装置（配列）は、供給されインストールされる装置のサブセット（特に、動作ソフトウエア）が削減でき、グラフ・エディタ及びコア処理だけを含みプラグインを持たないようにできる。このシステムはまた、第三者またはユーザに対して、プラグインとコア・フレームワークの間の規定のインターフェース・プロトコルに留まる限り、彼ら自身のプラグインを作ることを許す。従って、ユーザは、比較的小さなプラグイン・プログラムを書くことにより注文効果を非常に簡単に作ることができる。
【００１８】
このコア・フレームワークとプラグインは、いわゆる「オブジェクト・リンキング及び埋込」（ＯＬＥ）プロトコルを使ってお互いに通信する。これについては、「Understanding ActiveX and OLE 」、David Chappell,Microsoft Press, 1996に説明されている。
【００１９】
ＯＬＥシステムにおいては、ソフトウエア設計者は、コンピュータプログラムの異なったセクションを「ＣＯＭ（Component Object Model）オブジェクト」として実現できる。各ＣＯＭオブジェクトは、１以上のＣＯＭインターフェースをサポートし、各々沢山の「メソッド」を含む。或メソッドは関数または詳細動作を遂行する手順である。ＣＯＭのメソッドはそのＣＯＭオブジェクトを使うソフトウエアによって呼び出すことができる。このシステムは制限されているから、ＣＯＭオブジェクトを使うソフトウエアの他の部分は定義されたインターフェースを介してのみそうすることができる。従って、定義されたＣＯＭインターフェースを介する以外にそのオブジェクト内部のプログラム・コードまたはデータに直接アクセスすることはできない。
【００２０】
そこで、本システムにおいては、コア・フレームワークはこれらのＣＯＭインターフェースを介してプラグインと通信する。（事実、コア・フレームワークはＣＯＭインターフェースを提供することのできる沢山の相互通信オブジェクトを含む。）
【００２１】
図３は、オペレーティング・ソフトウエアの組織を図２に示したよりもずっと詳細に図示したものである。図３においては、線図は４つの四角に分けられている。左上の四角は、いわゆるビュー・ウインドウ３１０を示し、右上の四角は効果ユーザ・インターフェース（ＵＩ）３２０を示し、右下の四角は、関連するパラメータデータ（ＰＤ）を有する効果サーバー３３０を示し、左下の四角は、オブジェクト・マネージャー３５０、描画マネージャ３５２、変化マネージャ３５８と一緒にグラフを含むコア・プロセッサ３４０を示す。
【００２２】
左下の四角と右下の四角の間のインターフェースの所に、Window NT レジストリーの部分を形成するメタ・データベース３５４があり、効果アイコンを含むパレット３５６およびデフォルト・パラメータ値がある。このメタ・データベース３５４は、図１１を参照して、パレットは図６〜９を参照して更に詳しく説明する。
【００２３】
コア・プロセッサ３４０内には、リンクされた一連の個別特殊効果を有するグラフ、実際には「有向非循環グラフ」がある。各効果は、グラフの中に、それが使えるようになるとすぐにその効果出力を保存するための関連したキャッシュ（Ｃ）を有するプロクシー効果（ＰＥ）として表される。それによって、例えばもしそのチェイン（連鎖）において高い方の効果が変わると、その効果の連鎖の中の効果からデータを再使用できるようにする。各プロクシー効果は夫々の効果サーバー３３０と関連付けられている。
【００２４】
オブジェクト・マネージャー３５０は、そのシステム内のアクティブ・オブジェクトの寿命とメモリ・マネージメントを制御する責任がある。描写マネージャー３５２は描画作業の開始、進行、優先化、及び停止を制御する。変化マネージャー３５８は不履行／再履行情報および変化をシステムの種々の部分へ通知することを制御する。
【００２５】
図３の基本的な部分は、左手の２つの四角（左上及び左下）がコア・フレームワークの特色に関係し、如何なる特定の効果にも特定されない。これらのオブジェクトは、どの特定の特殊効果をユーザが実施しようと望むかに関わらずメモリーにロードされる。右手の２つの四角（右上及び右下）はプラグインに関係する。各プラグインは、そのプラグインによって遂行される効果に関連する処理を実行するサーバー３３０と、その効果に関係するユーザ・インターフェース・コントロール（実際には、ビューア・ウインドウ３１０の表示用）を提供するユーザ・インターフェース３２０を持つ。
【００２６】
図３においては同様な上から下への分割がある。上方の２つの四角（左上及び右上）は特殊効果に関連したユーザ・インターフェース・コントロールに関係し、下方の２つの四角（左下及び右下）はそれらの効果を実施するために遂行される処理または組織に関する。
【００２７】
ビューア・ウインドウは、ユーザに、その装置によって実行するために作り上げた一連の効果における或特定の効果の出力及びそれに対するパラメータを見る機会を与える。それゆえ、ユーザによってビューア・ウインドウが開かれると、或効果の出力が発生されるか、もし適用できれば、キャッシュ・ストアから検索されなければならない。
【００２８】
複数のＣＯＭオブジェクトを採用したこのタイプのシステムにおいては、各オブジェクトがその仕事又は結果データを別のデータファイルに保存する（ような）ことは一般には望ましくないと考えられる。事実、そのような装置（配列）はＯＬＥシステムの設定につながる多くの理由付けに反している。その代わりに、このタイプのシステムにおけるデータは、単一ファイル又は「複合ドキュメント」における全てのオブジェクトによって保存されるが、その複合ドキュメント内部の順序付けされた構造を使って行われる。
【００２９】
基本的には、複合ドキュメントの内側では、ファイル及びディレクトリ構造に類似した構造が準備される。ディレクトリに等しいものは、いわゆる「保存」であり、ファイルに類似のものは、いわゆる「ストリーム」である。各複合ドキュメントはルート保存を含み、その下にお馴染みの保存とストリームのトリー構造がある。このＣＯＭストリーム・インターフェースはＣＯＭ保存インターフェースよりももっと簡単であるが、勿論この保存インターフェースはもっと柔軟性がある。
【００３０】
一般に、各ＣＯＭオブジェクトは、そのワーキング・データを保存するそれ自身の保存装置又はそれ自身のストリームに割り当てることができる。しかしながら、コア３４０が沢山のプラグインの動作を調整する本ビデオ特殊効果処理装置等の階級システムにおいては、前のシステムに使われている装置（配列）は各効果プラグインにストリームを割り当てる。
【００３１】
それに比べて、本実施形態においては、保存装置又はストリームのどちらかをプラグインに単純に割り当てるとプラグイン・オブジェクトの設計及び動作に制約が多すぎることが認識される。それに代えて、コアとプラグインの間のインターフェース定義において、各プラグインは、（プラグイン設計者に望ましければ、そのワーキング・データを直接に保存できるように）ストリームと（もし望ましければ、そのワーキング・データをそれ自身の「ディレクトリ」配列のストリーム及び保存装置に保存するように）保存装置との間で選択できる。この選択は、プラグイン設計者がプラグイン・プログラム・コードを作ることによって前もって作られる。
【００３２】
以降の説明において、種々のオブジェクトの間の通信プロトコルは図４及び５と関連して説明する。コア・プログラム３４０のグラフ・エディタ部分が、複合効果を形成するために個々の効果の連鎖を設立するのに使われる方法は、図６〜９と関係して説明する。ビューア・ウインドウ及びそれらの効果ＵＩ３２０（複数個ある）との相互作用は図１０を参照して説明する。
【００３３】
図４は、図３の装置における更新された効果パラメータの伝搬を図示している。
この状況の一例は、ユーザが照明特殊効果を設定するということであり、そこでは画像に光源の効果が加わる。光源は、その画像に関するユーザ定義可能なソース及び目的位置を有する。もし、ユーザがこれらの位置の１つを変えたいならば、現在描写されている出力のどれでもその効果から無効（invalidate）にし、図３の異なった四角に示された種々のオブジェクトの間で変化を伝搬させる必要がある。この処理は図４に示されている。
【００３４】
図４を参照すると、ユーザはビューウインドウ３１０（図１０参照）を介して変化されたパラメータを実際に入力する。このビューア・ウインドウは特定の効果ＵＩ３２０と関連付けられており、それが個々の効果に関係するプラグインの部分になる。（事実、１以上の効果に対して単１ビュー・ウインドウを関連させることができ、全ての効果がビューア・ウインドウを任意の特定の時間に開く必要はなく、この検討のために図３の簡単化された装置（配列）が維持される。
このプラグインはコアに対して「エディット開始（about to edit ）」を発行する。
【００３５】
変更を行った後、プラグインはコアに対して「変化有り（change occurred ）」通知を発行する。これは、一連の動作を含むかそれらを開始するか又はその両方を行う。最初のステップ４０１として、ビューア・ウインドウは効果ＵＩ３２０に更新されたパラメータを通信する。この効果ＵＩ３２０は対応する効果サーバー３３０に「セット」命令を発行し、効果サーバー３３０内部のパラメータ保存装置に改訂された値をセットする。これは図４のステップ４０２である。
【００３６】
ステップ４０３において、効果サーバー３３０はコア３４０に「undo/redo 」オブジェクトを書き、変化前と後のパラメータの（効果サーバーにおける）レコードを指すハンドル又はポインターの詳細を提供する。このundo/redo オブジェクトの受領に応答して、ステップ４０４でコアは全てのビューア・ウインドウに対してパラメータが変更されたこと及び或キャッシュされたデータ出力が無効にできることを伝える。この通知は、パラメータ変化が起こったビューア・ウインドウに特有なものではない。
【００３７】
ステップ４０５では、各ビューア・ウインドウは、その処理パラメータの更新を要求している対応する効果ＵＩ３２０にメッセージを発行する。ステップ４０６で、その効果ＵＩ３２０は、その新しいパラメータを得るために対応する効果サーバーに対して get コマンド（命令）を発行し、ステップ４０７で効果ＵＩ３２０にその新しいパラメータが返される。この効果ＵＩはステップ４０８でビューアウインドウに表示のためその変化を伝搬する。
【００３８】
一般に、処理パラメータが変化した時、１つ以上の効果の出力を再描画することを必要とする結果になる。図５は、再描画コマンドが装置を通って伝搬される方法を図解しており、図４の処理から続く。
ステップ５０２では、ビューア・ウインドウは再描画マネージャー（管理部）に再描画コマンドを発行する。この描画管理部（マネージャー）は対応する効果サーバー３３０に再描画コマンドを発行する。効果サーバーが画像の再描写を終わった時、コア３４０に「終了」メッセージを発行する。このコアはステップ５０５でビューア・ウインドウにこれを通信する。そしてステップ５０６及び５０７でビューア・ウインドウは効果ＵＩ３２０と相互作用して再描画された効果出力を表示する。
【００３９】
数個のビューア・ウインドウが開かれており、数個のフレームが関心のある領域（これは、テストの目的で、全てのビデオ・クリップのサブセットとしてユーザによって定義できる）にある時、複数の画像が、処理リソース（資源）を割り当てるための下記の優先順位に従って、複数の同時作業として描かれる。
（ｉ）ユーザによって現在ビュー用に表示されている画像（１つ又は複数）；
（ｉｉ）関心のある出力順序の最初と最後の画像；
（ｉｉｉ）関心のある出力順序の残りの画像
【００４０】
詳細の他のレベルとして、描画マネージャ−が効果サーバーに再描画コマンドを発行する前に、この描画マネージャーは「描画準備（prepare to render ）」メッセージを発行してその順序（シーケンス）の中のどの画像が描画されるべきなのかを詳細指定する。
【００４１】
この効果サーバーは、その「依存性」、即ち描画マネージャーによる要求が実行できる前には必須であるそれらの描画された画像の通知に関して応答する。
これらは、もう一つの効果（例えば、有向非循環グラフにおけるすぐ前の効果）によって描かれた画像であるかもしれないし、その効果自体によって描かれた画像かもしれない。この後の場合は動き追跡の例で起こり得るが、そこでは、画像５を描画するために、動き追跡は画像４に対するそれ自身の描写された出力を必要とする。
【００４２】
効果サーバーから戻って受信されたメッセージに応答して、この描画マネージャーはそれらの画像を要求している「描画準備」メッセージを送り、依存トリーが終わるまでそうし続ける。
各段階において、この効果プロクシーは、要求された画像又は描画された出力がキャッシュされたか否かをチェックし、描画マネージャ−に通知する。
【００４３】
そこで、例えば、もし描画準備メッセージが画像５を詳細指定する動き追跡部に送られると、それが画像４に対する描画された出力を要求することに応答するかもしれない。描画マネージャーは、画像４に対する動き追跡部にメッセージを描く準備を送る。また、この動き追跡部はそれが画像３等を要求することを示すために応答する。この方法で、要求される画像（画像５）が描かれる前に必要な描画作業のリストが作り上げられる。キャッシュに保持された描画された出力は描画マネージャーの作業リストには含まれていない。
【００４４】
或効果が先行する効果の描画された出力を要求するところでは同じことが起こり、そのようにして一連の効果を下方にたどる。
この処理の終わりに、描画マネージャ−が、その依存する画像が全て描写されるまで現在要求されている画像が描かれないように逆の順序で行われる必要な作業の全てをセットする。
【００４５】
最適化として、この描画マネージャーはグラフから各効果に対する入力が何であるかを検出できる。それゆえ、この効果サーバーは、単純に「この効果に対する入力の全てが要求されている」というために、予め定められたコード（例えば、ｎｕｌｌ応答）を送ることができる。
【００４６】
更に他の拡張として、各効果サーバーが描画マネージャーに、その出力が隣接画像の間で同じであるか否かを通知する目的で同じプロトコルが使える。これの簡単な例は（固定）パラメーター・プラグインであり、出力は不変（ｉｎｖａｒｉａｎｔ）である。更に他の例は、出力が既に準備されていてキャッシュされているので、連続する出力が同一であるか否かについて直接の検出ができるという任意の他の効果である。
【００４７】
そのような通知に応答して、この描画マネージャーは、後ほど有向非循環グラフにある効果サーバー上に情報を送る。そこで、その効果サーバーは、（もし適正であれば）或範囲の画像の中の１つだけを描画し、その入力が同じに留まっていれば他の画像に対してその出力を繰り返すことができる。
【００４８】
図６はグラフ編集ウインドウ６００及びパレット・ウインドウ６１０を図示する。これらは、コア３４０の制御の下に表示スクリーン１６０上に表示される。
パレット・ウインドウ６００は、沢山のアイコン６２０を含み、各々がマップされ、その効果のためにそのシステム上にプラグインが存在するところの異なった可能な効果を表している。マウス・コントロールを使えば、ユーザはこれらのアイコンをスクロール可能なグラフ・ウインドウ６１０にドラッグできる。これらのアイコンはユーザによってグラフ・ウインドウの中に相互に関連して配列され論理リンク６３０とリンクできる。これについては、ウインドウ中にグラフ状の線で示してある。
【００４９】
リンク６３０は、或効果の出力を後続効果の入力へ送ることを表しており、（この実施形態において）グラフの底部からそのグラフ・ウインドウの頂部に向かう方向を常に持つ。それゆえ、図６に示された例では、その出力を照明効果６５０に送る画像ローダー・アイコン６４０を持つことを表している。
ユーザがグラフ・ウインドウの中にグラフィカル・リンクを設定すると、コア３４０は論理リンクを設定して、描画された出力が１効果プラグインからもう１つへ送られる方法を決定する。
【００５０】
図７を参照して、グラフィカル・リンクが作られる方法を説明する。この論理リンクは、図９を参照して説明する。
図７において、ユーザは（例えばマウス・クリックを使って）照明効果を選択し、今、アイコン６５０からマウス・ポインター７３０に向けて方向付けされた可動グラフィカル・ライン７２０を持つ。
マウス・ポインターが混合効果アイコン７００に近ずくにつれて、その混合アイコンは拡大し、または拡大された７１０で囲まれ、境界７４０の底部に２つの入力ポートを示す。
【００５１】
マウス・ポインターが入力ポートの１つに近づくと、グラフィカル・ライン７２０がその入力ポイント上にポンと動き、マウス・クリックすると定位置に固定できる。これによって、効果６５０と効果７００の間の論理的及びグラフィカル接続を設立する。
こうした論理的及びグラフィカルな接続が設立されると、ユーザはそのグラフ・ウインドウの効果アイコンのリンクされたグループ８００をボックス化できる。
【００５２】
ここで、ボックス化とは、コンピュータ・マウスを使って標準の方法でそのグループの周りにボックスを描くことを意味する。（これが実施される１つの方法は、そのボックスの左上隅でクリックし保持することであり、マウスを右下隅にドラッグし、マウス・ボタンを解放する。これは複数のスクリーン・オブジェクトを選択する標準の方法である）。
【００５３】
ユーザは、そのリンクされたグループの効果をパレット領域にドラッグすることができる。これは、その入力からグループに形成された１セットの入力を有し、出力からそのグループに形成された１セットの出力を有する新しい複合アイコン８１０を作る。論理用語で言えば、効果アイコン８１０が或特定のプラグインにマップされる代わりに、特定の方法で相互接続された１つのリンクされたグループのプラグインにマップされる。
【００５４】
複合効果アイコン８１０は、ユーザによってグラフを設計する際に使われるパレットの部分を形成する。その後、もしユーザが複合アイコン８１０を使うことを望むならば、それを単純にグラフ・ウインドウ上の場所にドラッグする。好ましくは、この効果アイコン８１０はグラフ・ウインドウ上では単一アイコンとして留まるが、他の実施においては、それは元のグループ８００へと拡張できる。
【００５５】
さらに他の変形として、単一アイコンとしてその圧縮形で表示することができるが、元のグループのアイコン８００を表示するためユーザが拡張ボタンをクリックできるように「拡張」ボタンを使って表示される。少なくとも、アイコン８１０によって提供される複合効果は元のグループ８００のコピーである。
【００５６】
図９はこのプロセスの下位にあるデータ保存部を図解したものである。図９において、アイコン８５０はパレット領域６００のパレット・アイコン６２０からグラフ・エディタ領域６１０にドラッグされている。
【００５７】
パレット領域６００と関連して、図３に示されたパレット３５６に保存されるものに、ルート８６０及びそのルートから依存する個別データ項目８７０を有するトリー（樹枝構造）として配列されたデータ構造がある。効果８７５等の複合効果の場合を除いて、各データ・アイテム８７０は１効果アイコン６２０を表す。
ここでは、その効果を形成する効果アイコン（３ａ、３ｂ）は、そのデータ・アイテム８７５から依存するサブ・ストラクチャで配列されている。
【００５８】
グラフ・エディタ領域に効果を格納するために、類似のデータ構造が存在する。
ここでは、ルート８８０はそれに依存する１つの効果８８５を持つものとして示されている。もし、沢山の効果がグラフ・エディタ領域に一緒にグループ化されパレットにドラッグされれば、それらはストラクチャー８７５に類似した更に他の複合効果ストラクチャーを形成する。
【００５９】
図１０は、ビューア・ウインドウを図示したものである。このビューア・ウインドウは画像表示領域９００、種々のプロパティー・ページ９１０、効果コントロール９２０（ここでは、照明効果の例における位置指定＋印として示してある。）、及び「ボタン・バー」９３０を含む。
ビューア・ウインドウの基本レイアウトは、コア・フレームワークによって設定され、効果から効果への標準である。しかしながら、プロパティ・ページ９１０を使って調整できる特定のアイテムは、或特定の効果に対応する効果ＵＩ３２０によって設定される。この効果ＵＩはコントロール９２０に対する表示の詳細も提供する。
【００６０】
示された例においては、＋印９２０は照明効果におけるライトのソース位置又はターゲット位置を決定する。ユーザはコンピュータ・マウスを使ってこの＋印をドラッグすることができる。＋印をドラッグすると、そのコントロールに関連するパラメータ（ｘ，ｙ）値を変えるので、図４の手順（パラメータ値の更新）が開始される。
【００６１】
その手順の最後の部分で、ステップ４０８において、この効果ＵＩは訂正されたパラメータ値をビューア・ウインドウに発行する。その段階で、＋印はその新しい位置において再描画される。それゆえ、ユーザの目には、それはドラッグによって＋印がその究極位置に動いたように映るが、実際にはドラッギング動作はパラメータを更新したのであり、図４に示されたルートによって、＋印の動きとなったのである。
【００６２】
図１１は、動作ソフトウエアの最初の配列を図示する。これは、装置の特定の動作セッションにおいて、いかなる描写も行われる前の状況を表している。
プラグインは、「ダイナミック・ロード・ライブラリーＤＬＬとしてウインド・オペレーティング・システム下で実施される。ＤＬＬは、一般にプログラム・コード、データ、およびサブルーチン・ライブラリーを含むことのできる大きなファイルである。
【００６３】
従来は、ＤＬＬは、メモリを節約するために、及びシステム性能を改善するために、そのＤＬＬによって扱われる特定のプロセスの実行又は開始のために初めて必要になった時にメモリにロードされた。本実施形態においては、メモリを節約しシステム性能を改善するというこのアイデアは一歩進められている。
【００６４】
或効果アイコンがパレット領域から最初に取り出される時、従来は、その効果に対応するＤＬＬがメモリにロードされて、コア３４０にビルドされるべきグラフのための充分な情報（例えば、他の効果アイコンとの相互接続性）を提供する。
本実施形態においては、その効果のためのＤＬＬはその段階ではロードされない。その代わりに、その効果を表す、いわゆる「メタ・データ」１０００がロードされる。このメタ・データはコアに他の効果（例えば、沢山の入力及び出力）と当該効果との相互接続性を定義する情報を提供する。これによって、コアがいかなるＤＬＬもロードする必要なしにグラフをビルドアップできるようにし、それらが絶対的に必要になるまで大きなファイルをロードしないでメモリを節約する。
【００６５】
もし、或効果と関係してビューア・ウインドウが開かれると、または、もし何らかの他の手段によってその複合効果が実行されると、ＤＬＬはロードされ、そのメタ・データは捨てられるか無視される。
図１２〜１４は、システムのオートメーションを（他にも増して）容易にする効果プラグインの特色を示している。
【００６６】
図１２は、以前に提案された効果プラグインを図示する。この効果は画像情報（「クリップ」１３００として示されている）をとり、３つの処理パラメータＰ１，Ｐ２，Ｐ３（照明位置等）を基にして活動する。図１２のプラグインにおいては、パラメータ値は、プラグイン内部に、即ち、プラグインの一部として書かれた注文プログラム・コードによってセットされる。
このことが、パラメータ（例えば、パラメータが時間によって変化するアニメーションシステム、又は照明位置等のパラメータが動き追跡部等の他の効果によって変えられる装置において）の全体の制御を非常に困難にしており、効果プラグイン内部及びしばしば効果プラグインの複数バージョン内に追加コードを要求する。
図１３は、本発明の実施形態に従う、もう１つのアプローチを図示する。ここでは、各パラメータは、別のプラグイン１３２０によって定義され、それらは上記グラフ・エディタにおいて効果間のリンクが定義されているのと同じ方法で「主」効果プラグイン１３３０にリンクされる。事実、上に説明されたことは全プロセスの簡略化であり、この簡略化はその段階では説明を助けるためになされている。
【００６７】
パラメータ・プラグインは、例えば「オフ・ザ・ページ」グラフ・エディット及びパレットにおけるスクリーン位置の所にそれらを表示することにより、通常はユーザから隠されている。もし、或効果が、自蔵、非アニメーション化で動作させられるならば、（即ち、他の効果からパラメータをインポートしなければ）、主効果ビューア・ウインドウを使う各パラメータ・プラグイン１３２０に対してパラメータがセットされる。
【００６８】
もし、パラメータが他の効果出力、例えば、動き追跡効果によって提供される位置値によって定義されるべきであれば、要求される全ては、主効果プラグイン１３３０と切断すべき適正なパラメータ・プラグイン１３２０の間の論理リンク及び開始されている動き追跡効果へのリンクに対してである。このシステムがアニメーションにおいて如何に手助けになるかを理解するために図１４を参照する。
【００６９】
図１４において、初め図３に示されたコアとプラグインの間の左右の分割を示す。図１４の左手側には、「主」効果サーバー１３５０に対してプロクシー効果（ＰＥ）１３４０が準備されている。パラメータ・プラグイン１３２０の各々に対しても、プロクシー効果１３６０が準備されている。
【００７０】
これらのプロクシー効果１３６０はプロクシー効果１３４０よりもずっと簡単な性質からなり、プロクシー効果１３６０とパラメータ・プラグイン１３２０の間の通信は、プロクシー効果１３４０と効果サーバー１３５０間の通信プロトコルの簡略化されたサブセットを使う。
【００７１】
実際には、プロクシー効果１３６０は単一データ値（非アニメーション化システムにおいて）、またはアニメーション・システムにおいては複数値のリストとすることができる。アニメート化されたシステムにおいては、値のリストは、「キー・フレーム」値、即ち、線形もしくはユーザ定義の非線形補間に従ってコアによって補間される中間値を備えた、順序配列された特定の複数画像に対するデータ値セットとすることができる。それゆえ、アニメーションは、各プラグイン内に注文のアニメーション・ソフトウエアを書く必要なしで特定の簡単で都合のよい方法で、設定できる。
【００７２】
この記述を、効果の間の依存性について前に与えられた記述と関係付ければ、描写マネージャーからの「描写準備」メッセージが効果サーバー１３５０で受信された時、それは、その出力が準備できる前にその入力の全てを要求するということをいうために応答できる。この効果入力には勿論パラメータ・プラグインが含まれるので、次の段階は、描画マネージャーが各パラメータ・プラグインに描写準備メッセージを送ることである。
【００７３】
もしパラメータ・プラグインが単一値を含み、または現在の画像がキー・フレームならば、このパラメータ・プラグインは動作時に適正なパラメータを準備する用意ができている。しかしながら、もしそのパラメータ・プラグインがアニメーション・データを含み、現在の画像がキー・フレームではないならば、このパラメータはその効果で使われる前に最初に補間されなければならない。
【００７４】
図１５は、システム・キャッシュ１１００を図示する。これは全キャッシュ領域のビューであり、事実前に説明したとおり、キャッシュは夫々のプロクシー効果に関連した複数の個別キャッシュとしても見ることができるが、メモリ資源がそのような個別キャッシュの間で動的に割り当てられるので図１５の表現も有効である。
このキャッシュはシステム・メモリ１５０に準備され、効果（例えば、動き追跡効果の場合に動きベクトル）からの画像１１１０及び非画像描写出力１１３０を保存することができる。
【００７５】
キャッシュという考え方は、有向非循環グラフにおける各効果の描写された出力（これが画像であるか否かにかかわらず）を保存することである。この方法でもし或効果がその有向非循環グラフの中の特定の位置で変えられれば、その位置の下の効果は新しい出力を準備するために再描写される必要がない。その代わりに、キャッシュされた出力が再使用される。もう一つの利益は、パラメータ変化がなされた前後で（開いているビューア・ウインドウにかかる）複数の特定の効果の出力を保存することにより、undo/redo （不履行／再履行）動作を援助しスピードアップすることである。
【００７６】
対応するパラメータ変化も同様に保存されるので、このパラメータ変化は、キャッシュ・メモリ１１００から適正なマテリアルを単純にロードすることにより不履行または再履行できる。これは、変化が起きた時に効果サーバーによって書かれたundo/redo オブジェクトの制御の下におかれている。
【００７７】
画像は、動きベクトルのような単純データよりもずっと多くのメモリ・スペースをとる。多分１００万倍もの多くのメモリ・スペースをとる。それゆえ、本実施形態においては、そのキャッシュ・メモリが容量いっぱいに近づき、かつ他の画像が保存されようとしているとき、そのキャッシュの中の最も古い（最近読み出されていない）画像を削除して、新たに保存する画像のための余地をつくる。しかしながら、キャッシュ中の他のデータ、パラメータ値、非画像描写出力等は、装置の動作セッション中には削除されない。何故ならば、それは画像と比べて小量のメモリ・スペースを消費するからである。この情報は、１つの動作セッションを通じてその情報が有効に留まる限り、再使用、不履行／再履行動作、のために使うことができる。
【００７８】
実行に際しては、慣例によってフラッシュ可能としてセットされている画像データ・アイテム、および非フラッシュとしてセットされている非画像アイテムと一緒に、１つのデータ・アイテムがフラッシュできるか否かをプラグインが詳細指定することは後に残しておくことができる。
【００７９】
図１６は、コア３４０と効果サーバーの間で非同期・同期の変換を行う変換器１２００を示す。
このコンバータ１２００は、「ｔｏ ｄｏ」待ち行列、即ち行うべき描画作業のリストの形で描画マネージャーから非同期再描画命令を受信する。
一つの作業が終了すると、「終了」メッセージがコンバータ１２００から描画マネージャ−に戻される。
コンバータ１２００はこの非同期作業要求を受け取って適正なソフトウエア・プラグインに同期リクエストを発行する。これは、インターフェース１２００がソフトウエア・プラグインに制御スレッド（ウインドウ用語）を送り、該プラグインは作業が終了するまでそのスレッドのコントロールを保持する。
【００８０】
その後のみ、そのソフトウエア・プラグインはインターフェースにスレッドを戻す。インターフェースはコアに「終了」メッセージを発行することによって応答する。
初期化の際に、コアは各プラグインに（又はそのプラグインに関連したメタデータ）に応答指令を出してそのプラグインが同期または非同期通信ができるか否かを決定する。この方法の動作にはハードウエア・アクセレレータがもっと良く適合するので、もし、ハードウエア・プラグイン（例えば、特定の方法で描写するための周辺カード）または、できれば異なったマシン上で動作する、非同期ソフトウエア・プラグインが、或ソフトウエア・プラグインの代わりにインストールされれば、そのプラグインは非同期インターフェースによって（実際、描写を開始する描写マネージャーが非同期的に働く）コアと相互作用する。
それゆえ、この場合には、コンバータ１２００はバイパスされる。
このコンバータは、コアの一部又は各関連するプラグインの一部として実装される。
従って、２つの部分のソフトウエアの間にコンバータ１２００を提供する直感に反したステップによって、専用のハードウエアに後でグレード・アップするために効率的なハードウエア・インターフェースが準備される。
【００８１】
【発明の効果】
本発明のビデオ信号処理装置は、
キャッシュ・メモリを使って、そこに有向非循環グラフ（方向性を有し回転した時に元に戻らないような形状の画像）を保存することにより、ある種の変化に対しては新しい出力を準備するために再描写する必要がなくなる。
【００８２】
また、このキャッシュ・メモリにパラメータ変化がなされた前後で（開いているビューア・ウインドウにかかる）複数の特定の（特殊）効果の出力を保存することにより、undo/redo （不履行／再履行）動作を行うことができるので、装置のスピードアップを図ることができる。
【００８３】
動きベクトルのような単純データよりもずっと多くのメモリ・スペースをとる画像データについてはメモリの容量いっぱいに近づき、かつ他の画像が保存されようとしているときに、削除して、新たに保存する画像のための余地をつくるようにするが、キャッシュ中の他のデータ、パラメータ値、非画像描写出力等は、装置の動作セッション中には削除されないようにして、メモリを有効使用することができる。
【図面の簡単な説明】
【図１】ディジタル・ビデオ特殊効果装置のブロック図である。
【図２】図１の装置の動作ソフトウエアの組織ブロック図である。
【図３】図１の装置にたいする動作ソフトウエアの組織を更に詳しく示すブロック図である。
【図４】図１の装置における更新された効果パラメータの伝搬を示す線図である。
【図５】図１の装置における再描画命令の伝搬を示す線図である。
【図６】エディット・ウインドウ及びパレット・ウインドウの線図である。
【図７】エディット動作を説明するための線図である。
【図８】複合効果アイコンの構築を示す線図である。
【図９】複合効果のファイル構造を示す線図である。
【図１０】ビュー・ウインドウを示す線図である。
【図１１】動作ソフトウエアの初期配列を示す線図である。
【図１２】前回提案された効果プラグインを示すブロック図である。
【図１３】効果プラグインの新形式を示すブロック図である。
【図１４】図１３の効果サーバーと効果プラグインのためのプロクシー（代理）効果の間の関係を示す線図である。
【図１５】システム・キャッシュを示す線図である。
【図１６】プラグイン・インターフェースを示すブロック図である。
【符号の説明】
１１００・・・システム・キャッシュ、 １１１０・・・画像保存、
１１３０・・・非画像描写出力
Claims (3)
- １つのビデオ信号を形成する複数の画像に対して、連続するビデオ信号処理動作が適用されて画像又はデータの形で対応する処理結果を発生するビデオ信号処理装置であって、
キャッシュされたアイテム及びビデオ信号処理動作と関連する処理結果として、保存するためのキャッシュ保存手段と、
新たにキャッシュされるべきアイテムのためのキャッシュ・スペースを提供するために現在キャッシュされているアイテムを削除する手段であって、動きベクトルデータが画像データよりも長い間キャッシュの中に留められるように動作する削除手段と、を備えたビデオ信号処理装置。 - 請求項１に記載の装置において、
上記削除手段がキャッシュから上記動きベクトルデータを削除しないように動作するようにしたビデオ信号処理装置。 - １つのビデオ信号を形成する複数の画像に対して、連続するビデオ信号処理動作を適用して画像又はデータの形で対応する処理結果を発生するビデオ信号処理方法であって、
キャッシュされたアイテム及びビデオ信号処理動作と関連する処理結果として保存するステップと、
新たにキャッシュされるべきアイテムのためのキャッシュ・スペースを提供するために現在キャッシュされているアイテムを削除することにより、動きベクトルデータが画像データよりも長い間キャッシュの中に留められるようにするステップと、を含むビデオ信号処理方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9816759:6 | 1998-07-31 | ||
| GB9816759A GB2341068B (en) | 1998-07-31 | 1998-07-31 | Caching in digital video processing apparatus |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000092390A JP2000092390A (ja) | 2000-03-31 |
| JP4166376B2 true JP4166376B2 (ja) | 2008-10-15 |
Family
ID=10836535
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP21558399A Expired - Fee Related JP4166376B2 (ja) | 1998-07-31 | 1999-07-29 | ディジタル・ビデオ信号処理装置及び方法 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US6529200B2 (ja) |
| EP (1) | EP0977122A3 (ja) |
| JP (1) | JP4166376B2 (ja) |
| KR (1) | KR100722701B1 (ja) |
| GB (1) | GB2341068B (ja) |
Families Citing this family (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7119813B1 (en) | 2000-06-02 | 2006-10-10 | Nintendo Co., Ltd. | Variable bit field encoding |
| US6999100B1 (en) | 2000-08-23 | 2006-02-14 | Nintendo Co., Ltd. | Method and apparatus for anti-aliasing in a graphics system |
| US6937245B1 (en) | 2000-08-23 | 2005-08-30 | Nintendo Co., Ltd. | Graphics system with embedded frame buffer having reconfigurable pixel formats |
| US6606689B1 (en) | 2000-08-23 | 2003-08-12 | Nintendo Co., Ltd. | Method and apparatus for pre-caching data in audio memory |
| US6664958B1 (en) | 2000-08-23 | 2003-12-16 | Nintendo Co., Ltd. | Z-texturing |
| US6980218B1 (en) | 2000-08-23 | 2005-12-27 | Nintendo Co., Ltd. | Method and apparatus for efficient generation of texture coordinate displacements for implementing emboss-style bump mapping in a graphics rendering system |
| US6664962B1 (en) | 2000-08-23 | 2003-12-16 | Nintendo Co., Ltd. | Shadow mapping in a low cost graphics system |
| US6639595B1 (en) | 2000-08-23 | 2003-10-28 | Nintendo Co., Ltd. | Achromatic lighting in a graphics system and method |
| US6697074B2 (en) | 2000-11-28 | 2004-02-24 | Nintendo Co., Ltd. | Graphics system interface |
| FR2840424B1 (fr) * | 2002-05-30 | 2004-09-03 | Thomson Licensing Sa | Procede et dispositif de fragmentation de donnees multimedia |
| US9066199B2 (en) | 2007-06-28 | 2015-06-23 | Apple Inc. | Location-aware mobile device |
| US8385946B2 (en) | 2007-06-28 | 2013-02-26 | Apple Inc. | Disfavored route progressions or locations |
| US8108144B2 (en) | 2007-06-28 | 2012-01-31 | Apple Inc. | Location based tracking |
| KR20100026739A (ko) * | 2008-09-01 | 2010-03-10 | 삼성전자주식회사 | 표시 장치 및 그 구동 방법 |
| US8379098B2 (en) * | 2010-04-21 | 2013-02-19 | Apple Inc. | Real time video process control using gestures |
| US20120166953A1 (en) * | 2010-12-23 | 2012-06-28 | Microsoft Corporation | Techniques for electronic aggregation of information |
| US9436685B2 (en) | 2010-12-23 | 2016-09-06 | Microsoft Technology Licensing, Llc | Techniques for electronic aggregation of information |
| US9679404B2 (en) | 2010-12-23 | 2017-06-13 | Microsoft Technology Licensing, Llc | Techniques for dynamic layout of presentation tiles on a grid |
| US9715485B2 (en) | 2011-03-28 | 2017-07-25 | Microsoft Technology Licensing, Llc | Techniques for electronic aggregation of information |
| CN102799422B (zh) * | 2011-05-23 | 2016-03-30 | 深圳市快播科技有限公司 | 数字视频中的拖拽截屏方法 |
| US8612491B2 (en) * | 2011-10-25 | 2013-12-17 | The United States Of America, As Represented By The Secretary Of The Navy | System and method for storing a dataset of image tiles |
| US11770601B2 (en) | 2019-05-06 | 2023-09-26 | Apple Inc. | User interfaces for capturing and managing visual media |
| US10674072B1 (en) | 2019-05-06 | 2020-06-02 | Apple Inc. | User interfaces for capturing and managing visual media |
| US11706521B2 (en) | 2019-05-06 | 2023-07-18 | Apple Inc. | User interfaces for capturing and managing visual media |
| US11039074B1 (en) | 2020-06-01 | 2021-06-15 | Apple Inc. | User interfaces for managing media |
| US11212449B1 (en) | 2020-09-25 | 2021-12-28 | Apple Inc. | User interfaces for media capture and management |
| US11778339B2 (en) | 2021-04-30 | 2023-10-03 | Apple Inc. | User interfaces for altering visual media |
| US11539876B2 (en) | 2021-04-30 | 2022-12-27 | Apple Inc. | User interfaces for altering visual media |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS62126478A (ja) * | 1985-11-27 | 1987-06-08 | Toshiba Corp | イメ−ジプロセツサ |
| NL8601938A (nl) | 1986-07-28 | 1988-02-16 | Philips Nv | Opspaninrichting voor het op een aandrijfspil opspannen van een optische plaat. |
| KR920001287B1 (ko) | 1988-02-12 | 1992-02-10 | 니혼 호오소오 고오카이 | 디지탈 영상신호 처리장치 |
| GB2247597B (en) * | 1990-08-31 | 1995-03-08 | Canon Res Ct Europe Ltd | Image processing |
| US5191645A (en) * | 1991-02-28 | 1993-03-02 | Sony Corporation Of America | Digital signal processing system employing icon displays |
| US5263136A (en) * | 1991-04-30 | 1993-11-16 | Optigraphics Corporation | System for managing tiled images using multiple resolutions |
| EP0528631B1 (en) | 1991-08-13 | 1998-05-20 | Xerox Corporation | Electronic image generation |
| GB2262365B (en) * | 1991-12-10 | 1995-08-09 | Sony Broadcast & Communication | Apparatus and methods for designing,analyzing or simulating signal processing functions |
| US5974508A (en) * | 1992-07-31 | 1999-10-26 | Fujitsu Limited | Cache memory system and method for automatically locking cache entries to prevent selected memory items from being replaced |
| US5557759A (en) * | 1995-06-07 | 1996-09-17 | International Business Machines Corporation | Video processor with non-stalling interrupt service |
| US6012126A (en) * | 1996-10-29 | 2000-01-04 | International Business Machines Corporation | System and method for caching objects of non-uniform size using multiple LRU stacks partitions into a range of sizes |
| US6058456A (en) * | 1997-04-14 | 2000-05-02 | International Business Machines Corporation | Software-managed programmable unified/split caching mechanism for instructions and data |
| US6272598B1 (en) * | 1999-03-22 | 2001-08-07 | Hewlett-Packard Company | Web cache performance by applying different replacement policies to the web cache |
| JP6357351B2 (ja) * | 2014-05-28 | 2018-07-11 | 株式会社Ｓｃｒｅｅｎホールディングス | 錠剤印刷装置および錠剤印刷方法 |
-
1998
- 1998-07-31 GB GB9816759A patent/GB2341068B/en not_active Expired - Fee Related
-
1999
- 1999-07-26 EP EP99305901A patent/EP0977122A3/en not_active Withdrawn
- 1999-07-29 US US09/363,481 patent/US6529200B2/en not_active Expired - Fee Related
- 1999-07-29 JP JP21558399A patent/JP4166376B2/ja not_active Expired - Fee Related
- 1999-07-31 KR KR1019990031539A patent/KR100722701B1/ko not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| GB2341068B (en) | 2002-11-06 |
| US20030001827A1 (en) | 2003-01-02 |
| GB9816759D0 (en) | 1998-09-30 |
| GB2341068A (en) | 2000-03-01 |
| KR20000012133A (ko) | 2000-02-25 |
| US6529200B2 (en) | 2003-03-04 |
| JP2000092390A (ja) | 2000-03-31 |
| KR100722701B1 (ko) | 2007-06-04 |
| EP0977122A2 (en) | 2000-02-02 |
| EP0977122A3 (en) | 2000-05-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4166376B2 (ja) | ディジタル・ビデオ信号処理装置及び方法 | |
| KR100652466B1 (ko) | 디지털 이미지 처리 장치 | |
| JP4299924B2 (ja) | ビデオ特殊効果装置 | |
| JP4299925B2 (ja) | データ処理装置 | |
| KR100663655B1 (ko) | 데이터 처리 방법 및 데이터 처리 장치 | |
| KR100652463B1 (ko) | 비디오 처리 장치 및 비디오 처리 방법 | |
| US6791552B2 (en) | Digital video processing | |
| KR100652465B1 (ko) | 비디오 특수 효과 장치 | |
| US6801225B1 (en) | Data storage in ole systems |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060307 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070518 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080304 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080521 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080708 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080730 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110808 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120808 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |