JP4299925B2 - データ処理装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、、データ処理装置に関するものである。
【０００２】
【従来の技術】
種々のマイクロソフト・ウィンドーズ（登録商標）オペレーティング・システムの専門用語を使用すると、プログラム・モジュール又はプラグインが「ダイナミック・ロード・ライブラリ」即ち「ＤＬＬ」として設けられることがある。ＤＬＬは一般に、プログラムコード、データ及びサブルーチン・ライブラリを格納できる大きなファイルである。それらは、現在のプログラムを実行するのに必要な場合にメモリに格納される。
【０００３】
この構造形式が有用となるデータ処理装置の一例として、コンピュータ使用ビデオ特殊効果装置がある。かような装置では、ユーザが一般に、多数の使用可能なモジュールから一連の効果モジュールを選択することにより、ビデオシーケンスに適用する合成特殊効果を設定できるようになっている。例えば、ユーザにより設定される一連の効果には、次のようなものが含まれるであろう。
（ｉ）イメージローダ（画像の格納）
（ii）モーショントラッカ（動きの追跡）
(iii) 動きの追跡に連動した照明効果
（iv）動きの追跡に連動した画像再編成
【０００４】
これらの効果の各々はプログラムモジュール又はプラグインとして具現され、データは、コア・プログラムの全般的制御の下にモジュール間を転送される。コア・プログラム・オブジェクト及びプラグイン・オブジェクト間のインタフェースは同期インタフェースであるので、プログラム制御（実際は、マルチタスキング環境、いわゆる「スレッド」で）はプラグインに回送され、そこでその処理タスクが実行される。制御はその時にのみコア・プログラムに返送され、そのスレッドを用いて他の処理が再開される。
【０００５】
【発明が解決しようとする課題】
本発明は、一方では、ソフトウェア・プラグインと同期したインタフェースを認めるデータ処理装置を提供することと、他方では、将来それらのプラグインの幾つかと代わる専用のハードウェア・ユニットの使用への改良の可能性を認めることとの間の潜在的矛盾を認め、これを解決しようとするものである。
【０００６】
この種の専用ハードウェア・ユニット、特に描画デバイスは、一般に非同期インタフェースを使用する。（実のところ、ソフトウェア・プラグインの中には非同期インタフェースを使用できるものもある。）したがって、本発明は、ただ１つのシステム内に非同期及び同期プラグイン・インタフェースの両方を設けるという反直観的手段を含むものである。
【０００７】
【課題を解決するための手段】
本発明によるデータ処理装置では、コア・プログラム・オブジェクトが、データ処理タスクを実行する動作ができる複数のプラグイン・プログラム・オブジェクト及び／またはハードウェア・デバイスと対話して、それらの動作を制御する装置であって、上記コア・プログラム・オブジェクトは、上記データ処理タスクを実行させる非同期の要求を発生し、上記プラグイン・プログラム・オブジェクトのうち上記データ処理装置で作動しているプラグイン・プログラム・オブジェクトに対しては、上記非同期の要求を非同期／同期コンバータを介して同期要求として送り、上記プラグイン・プログラム・オブジェクトのうち上記データ処理装置とは異なる機械で作動しているプラグイン・プログラム・オブジェクト及び上記ハードウェア・デバイスに対しては、上記非同期の要求を上記非同期／同期コンバータを介さずに送る。
【０００８】
【発明の実施の形態】
以下、図面を参照して本発明を具体的に説明する。
図１は、本発明を適用できるデジタルビデオ特殊効果装置の概要図である。図１において、連続する画像を表すデジタルビデオ信号は、入力インタフェース（Ｉ／Ｆ）１００を介して受信されディスクアレイ装置１１０に記憶される。ディスクアレイ装置１１０はまた、本効果装置により生成された処理済み画像をも記憶し、これらは出力インタフェース１２０を介し出力として供給される。
【０００９】
中央処理ユニット（ＣＰＵ）１３０は、ディスクアレイに記憶されたデータにアクセスし、ユーザの指令（コマンド）に従い種々のビデオ特殊効果を達成する。ＣＰＵ１３０は、マウス及びキーボードのようなユーザ入力装置１４０から入力を受け、作業データ及びプログラムコードをメモリ１５０に記憶させ、出力データを生成し、表示駆動部１７０を介してスクリーン１６０に表示させる。
【００１０】
本効果装置は、適当なソフトウェア、例えばマイクロソフト・ウィンドーズＮＴ（登録商標）オペレーティングシステムにより動作する汎用コンピュータ（例えば、ＰＣ）として具現することができる。この例では、ディスクアレイは、ウルトラＳＣＳＩデータリンクを介してＣＰＵ１３０に接続される。
【００１１】
図２は、図１の装置に使用する作動ソフトウェアの編成の概略を（極めて一般的な水準で）示すものである。
このソフトウェアは、２種類のプログラムコードより成り、１つは図２の左側に示すコア構造部であり、もう１つは図２の右側に示す種々のプラグイン部である。このソフトウェアが初めに格納されると、コア構造部は、常に存在して異なる特殊効果プロセス間で共通する本装置の動作の各部分を制御する。これに対し、プラグライン部は、個々の特殊効果（照明効果、動き追跡効果など）に関するもので必要な時にのみ格納される。
【００１２】
この配置は、現在ユーザが要求する効果モジュールに関するプラグインのみをメモリに格納すればよいので、極めて効率のよいものである。こうすると、想定されるすべての特殊効果に対するプログラムコードを格納しなければならないシステムに比べて、メモリを少なくすることができる。これはまた、装置の初期設定をもつと迅速化し、システムを最初スタートさせる際にプログラムコードをすべてメモリに格納する必要をなくし、グラフエディタ（後述参照）において最初にアイコンを選ぶときのコードの格納による遅延を少なくすることができる。更に、この配置は、グラフエディタ及びプラグインを除くコア処理のみを含むので、供給又は組込むべき装置部品（特に、作動ソフトウェア）を減らすことができる。このシステムはまた第三者又はユーザがプラグイン部及びコア構造部間の決められたインタフェース・プロトコルを守る限り、彼等自身のプラグインを生成することを可能にしている。よって、ユーザは、比較的小さなプラグイン・プログラムを書込むことにより、注文の効果を極めて簡単に生成することができよう。
【００１３】
コア構造部及びプラグイン部は、David Chappell著1996年Microsoft Press 発行の「Understanding Active X and OLE」という本に記載された、いわゆるＯＬＥ（Object Linking and Embedding）プロトコルを用いて互いに伝達を行う。
【００１４】
ＯＬＥシステムでは、ソフトウェア設計者は、コンピュータ・プログラムの種々異なるセクションをいわゆる「ＣＯＭ（Component Object Model）オブジェクト」として実現できる。各ＣＯＭオブジェクトは、各々が幾つかの「メソッド」を含む１以上の「ＣＯＭインタフェース」を支えている。メソッドは、特定の運動を実行する機能又は手順である。ＣＯＭメソッドは、上記ＣＯＭオブジェクトを使用するソフトウェアによって呼び出すことができる。このシステムでは、ＣＯＭオブジェクトを使用するソフトウェアの他の部分は、所定のインタフェースを介してのみそうすることができるように制約されている。即ち、それらは、所定のＣＯＭインタフェースを介さなければ、該オブジェクト内のプログラムコード又はデータに直接アクセスすることができない。
【００１５】
そこで、本システムでも、コア構造部はプラグイン部とこれらのＣＯＭインタフェースを介して伝達を行う（実のところ、コア構造部は、ＣＯＭインタフェースを提供できる幾つかの相互連絡オブジェクトを有するが、基本原理は同じである。）。
【００１６】
図３は、図２に示したものよりずっと詳細に作動ソフトウェアの編成を示すものである。図３は、４つの象限に分割されている。左上の象限はいわゆるビューワーウィンドー３１０を示し、右上の象限は効果ユーザインタフェース（ＵＩ）３２０を示し、右下の象限は、関連するパラメータデータ（ＰＤ）を有する「効果サーバ」３３０を示し、左下の象限は、オブジェクトマネージャ３５０、描画マネージャ３５２及び変更マネージャ３５８と共にグラフを含むコア・プロセッサ３４０を示す。左下と右下の象限の間のインタフェースには、ウィンドーズＮＴレジストリの一部をなすメタ・データベース３５４と、効果アイコンを含むパレット３５６と、省略パラメータ値とがある。メタ・データベース３５４については図１１を参照してあとで説明する。パレット３５６については図６〜９を参照して後述する。
【００１７】
コア・プロセッサ３４０内には、個々の特殊効果を続けて連結した「グラフ」、即ち「有向非繰返しグラフ」がある。各効果は、グラフ内でプロキシ（代理）効果（ＰＥ）として表示されている。各ＰＥは、効果の出力が得られると直ちにこれを記憶するキャッシュ（Ｃ）を有するので、例えば一連の効果の中で重要な効果に関連するパラメータが変化した場合、一連の効果の中の効果からデータを再使用することができる。各プロキシ効果は、夫々の効果サーバ３３０と対応している。
【００１８】
オブジェクトマネージャ３５０は、システム内で用いるオブジェクトの存続期間やメモリ処理を制御する責任をもつ。描画マネージャ３５２は、描画タスクの開始、進行、優先順位の指定及び停止を制御する。変更マネージャ３５８は、情報の取消し／やり直し及びシステム各部への変更の連絡を制御する。
【００１９】
図３は、基本的に、左側の２つの象限（左上及び左下）がどの効果にも関係しないというコア構造部の機能的特徴を示すように分割されている。これらのオブジェクトは、ユーザがどの特殊効果を実施しようと望んでいるかに関係なく、メモリに格納される。右側の２つの象限（右上及び右下）は、プラグイン部に関係する。各プラグインは、そのプラグインによって実施される効果に関連した処理を行うサーバ３３０と、その効果に関するユーザインタフェース制御（実際は、ビューワーウィンドー３１０における表示制御）を行うユーザインタフェース（ＵＩ）３２０とを有する。
【００２０】
図３には同様の上下に分ける分割線があり、これにより、２つの上方の象限（左上及び右上）は特殊効果に関連するユーザインタフェース制御に関係し、２つの下方の象限（左下及び右下）はそれらの効果を実施するために行う処理や編成に関係していることを示す。
【００２１】
ビューワーウィンドー３１０は、本装置によって実行するために作成された一連の効果のうち特定の効果の出力及びそれの制御パラメータを観察する機会をユーザに与えるものである。即ち、ユーザがビューワーウィンドーを開くと、或る効果の出力が生成されるか、或いは可能な場合キャッシュ・メモリから検索される。
【００２２】
多数のＣＯＭオブジェクトを使用するこのタイプのシステムでは、各オブジェクトがその作業又は結果のデータを別々のデータファイルに蓄えるべきだとするのは望ましくない、と一般に考えられている。実際、そのようにすると、ＯＬＥシステムを確立させた論理の多くと合わないようである。代わりに、このタイプのシステムのデータは、全部のオブジェクトによりただ１つのファイル又は「複合文書」に記憶される。ただし、順序付けされた構造であれば、複合文書内に記憶される。
【００２３】
元来、複合文書内にはファイル及びディレクトリ構造に似た或る構造が設けられている。ディレクトリの均等物はいわゆる「ストレージ」であり、ファイルの類似物はいわゆる「ストリーム」である。各複合文書はルート（根）ストレージを有し、その下方にはストレージ及びストリームのよく知られた木構造がある。ＣＯＭストリーム・インタフェースはＣＯＭストレージ・インタフェースより簡単であるが、勿論ストレージ・インタフェースの方がもっと柔軟性がある。
【００２４】
一般に、各ＣＯＭオブジェクトを自分のストレージ又は自分のストリームに割り当て、その中に作業データを記憶させることができる。しかし、コア・プロセッサ３４０が幾つかのプラグインの動作を調整する本ビデオ特殊効果プロセッサのような階層システムにおいては、これまで１つのストリームを各効果プラグインに割当てるようにしていた。
【００２５】
これに対し、本実施態様では、単にストレージ又はストリームのいずれか一方をプラグインに割当てることは、プラグイン・オブジェクトの設計及び動作に余りに多くの制約を課すことになると認識されていて、代わりに、コア構造部とプラグイン部との間のインタフェース定義において、各プラグインは、プラグイン設計者が望む場合、その作業データを容易に記憶できるように１つのストリームを選択でき、同じく望む場合、複数のストリームとストレージの自己の「ディレクトリ」配置の下でその作業データを記憶できるように１つのストレージを選択できるようになっている。この選択は、プラグイン・プログラムコードを作成するプラグイン設計者によって予め行われる。
【００２６】
以下の説明において、種々のオブジェクト間の通信プロトコルについては図４及び図５に関連して説明し、コア・プログラム３４０のグラフエディタ部を用いて個々の効果を連結し、複合効果を作る方法については図６〜図９を参照して説明し、ビューワーウィンドー及びそれと効果ユーザインタフェース（ＵＩ）３２０との対話については、図１０を参照して説明する。
【００２７】
図４は、図３の配置における更新された効果パラメータの伝播状態を模式的に示す。
この伝播状態は、ユーザが「照明」特殊効果を設定し、光源の効果が画像に加えられる場合の例である。光源は、ユーザが定めるソースと画像に関する行先位置とを有する。ユーザがこれらの位置の１つを変えたいと望む場合、現在該効果から描画されている出力を無効とし、その変化を図３の異なる象限に示す種々のオブジェクトに伝達させる必要がある。この処理過程を図４に示す。
【００２８】
図４において、ユーザは、変更されたパラメータをビューワーウィンドー３１０を介して実際に書入れる（図１０参照）。ビューワーウィンドーは特定の効果ユーザインタフェース３２０と対応しており、このインタフェースはまた個々の効果に関する各プラグインの一部をなす。（実のところ、１つのビューワーウィンドーを１より多い効果と対応させることができ、任意の特定時間に開かれるビューワーウィンドーをすべての効果がもつには及ばないが、都合上図３の簡略化された配置に基いて説明する。）プラグインは、「これより編集に入る（about to edit)」との通知をコア側に発する。
【００２９】
上記の変更が行われた後、プラグインは「変更発生」メッセージを発する。これにより、一連の動作が発生及び／又は開始される。最初のステップ４０１で、ビューワーウィンドーは更新されたパラメータを効果ＵＩ３２０に伝達する。効果ＵＩ３２０は、「セット」コマンドを対応する効果サーバ３３０に発し、修正された値を効果サーバ３３０内のパラメータ・メモリにセットさせる。このステップを図４の４０２で示す。
【００３０】
ステップ４０３で、効果サーバ３３０は、「取消し／やり直し」オブジェクトをコア・プロセッサ３４０の中に書込んで、変更の前後におけるパラメータの（効果サーバ内の）記録を指し示すハンドル又はポインタの詳細を供給する。この「取消し／やり直し」オブジェクトを受取ると、ステップ４０４で、コア側は、パラメータが変更され幾つかのキャッシュされたデータ出力が無効になるかも知れないという通知を全ビューワーウィンドーに流す。この通知は、パラメータの変更が行われたビューワーウィンドーに限定されない。
【００３１】
ステップ４０５で、各ビューワーウィンドーは、対応する効果ＵＩ３２０にその処理パラメータの更新を要求するメッセージを発する。ステップ４０６で、効果ＵＩ３２０は、「ゲット」コマンドを対応する効果サーバに発して新しいパラメータを得させる。新しいパラメータは、ステップ４０７で効果ＵＩ３２０に返送される。効果ＵＩはそれから、ステップ４０８でビューワーウィンドーにその変化を伝えて表示させる。
【００３２】
一般に、処理パラメータが変わると、１つ以上の効果出力の描画をやり直す必要が生じる。図５は、描画し直しコマンドが装置内を伝播する様子を示し、これは図４の処理から引き続いて起こる。
【００３３】
ステップ５０２ではビューワーウィンドーは描画し直しコマンドを描画マネージャ３５２に発する。すると、描画マネージャは描画し直しコマンドを対応する効果サーバ３３０に発する。効果サーバは、画像の作り直しを終えると、「終了」メッセージをコア・プロセッサ３４０に発する。コア側は、ステップ５０５でこれをビューワーウィンドーに知らせ、ステップ５０６及び５０７で、ビューワーウィンドーは効果ＵＩ３２０と対話し描画し直した効果出力を表示する。
【００３４】
数個のビューワーウィンドーが開き、数個のフレームが関心の域（これは、テスト目的でユーザがビデオクリップ全体の部分集合として決めることができる。）内にある場合、処理資源をとっておくため次の優先順に従い多数の同時発生タスクとして画像が描かれる。
（ｉ）ユーザが観察するために現在表示されている単数又は複数の画像、
（ii）関心のある出力シーケンスの最初と最後の画像、
(iii) 関心のある出力ビデオシーケンスの残りの画像
【００３５】
更に細かい段階として、描画マネージャは、効果サーバに描画し直しコマンドを発する前に、シーケンス内のどの画像を描画すべきかを指定する「描画準備」メッセージを発する。効果サーバは、これに応じてその「依存性」を、即ち描画マネージャから要求される前に必要となる描画像を作成しなければならないことを通知する。これらの画像は、他の効果（例えば、非繰返し有向グラフにおける直ぐ前の効果）により描画されるものか、或いはその効果自体によって描画されるものかも知れない。この後者の例は、モーショントラッカの場合に起りうる。即ち、例えば、画像５を描くためにモーショントラッカが画像４に対する自分の描画出力を必要とする場合である。
【００３６】
効果サーバから返送された該メッセージを受取ると、描画マネージャは、それらの画像を求める「描画準備」メッセージを送る。以下、従属ツリーが終わるまで同様のことが行われる。
各階段において、プロキシ効果は、要求された画像又は描画出力がキャッシュに記憶されたかどうかをチェックし、描画マネージャに知らせる。
【００３７】
そこで、例えば、画像５を指定する描画準備メッセージがモーショントラッカに送られると、モーショントラッカは、これに応答して画像４に対する自己の描画出力を要求していることを告げる。すると、描画マネージャは、画像４に対する描画準備メッセージをモーショントラッカに送る。モーショントラッカは、これに応答して画像３を要求していることを示す。以下同様である。こうして、所要画像（画像５）が描画される前に必要な描画ジョブのリストが作成される。キャッシュに記憶されている描画出力は、描画マネージャのジョブのリストには含まれない。
【００３８】
或る効果が前の効果の描画出力を必要とする場合には同じことが起こり、同様に一連の効果を前にさかのぼる。
この過程が終わると、描画マネージャは、現在要求されている画像が、それの依存する画像がすべて描かれるまでは描かないように逆の順序で、要求されたすべてのジョブを進めてゆく。
【００３９】
最適化の条件として、描画マネージャは、各効果への入力が何であるかを前記グラフから検出するのがよい。そして、効果サーバは、所定のコードを送り（例えば、ゼロ応答）簡単に「この効果に対する入力はすべて要求済み」と告げるとよい。
【００４０】
更に、各効果サーバから、その出力が隣り合う画像と同じであるかどうかを描画マネージャに知らせうるように、同じプロトコルを使用するとよい。これの簡単な例は、その出力が不変である場合の（一定）パラメータ・プラグインである。更なる例は、どれか他の効果の出力が既に準備されキャッシュに記憶されていて、連続する出力が同一かどうかを容易に検出できる場合である。かような通知に応答して、描画マネージャは、有向非繰返しグラフで後の他の効果サーバにその情報を送る。すると、その効果サーバは、（適当ならば）一連の画像の１つだけを描画し、入力が変わらない他の画像に対してその出力を繰返す。
【００４１】
図６は、グラフ・エディタ・ウィンドー６１０とパレット・ウィンドー６００を示す概略図である。これらは、コア・プロセッサ３４０の制御の下に表示スクリーン１６０に表示される。
パレット・ウィンドー６００は幾つかのアイコン６２０を含み、これらの各々は、考えられる種々の効果の１つにマッピングされ、それらの効果を表している。本システムには、各効果に対するプラグインが存在する。ユーザは、マウスを用いてこれらのアイコンをスクロール可能なグラフ・ウィンドー６１０に「引き込む」ことができる。ユーザは、グラフ・ウィンドー内にこれらのアイコンを配置し、該ウィンドー内で図形線として示す論理リンク６３０で互いに連結することができる。
【００４２】
論理リンク６３０は、或る効果の出力を次の効果の入力へ送ることを表し、（この具体例では）常にグラフ・ウィンドーの下から上の方への向きをもつ。即ち、図６の例は、イメージローダ（Ｉ／Ｌ）アイコン６４０の出力を照明効果６５０に送ることを示す。
【００４３】
ユーザがグラフ・ウィンドー内に上記の図形線を描くと、コア・プロセッサ３４０は、論理リンクを設定して描画出力が或る効果プラグインから他のプラグインに送られる経路を決定する。
これより、図７を参照して図形線を作成する方法を説明する。それから、図８を参照して論理リンクを説明する。
【００４４】
図７において、ユーザが照明効果を（例えば、マウスのクリックで）選択すると、アイコン６５０からマウスポインタ７３０に向かう動かせる図形線７２０が得られる。マウスポインタが混合効果アイコン７００に近づくと、その混合効果アイコンが拡大され、即ち拡大線７１０に囲まれ、その最下部に２つの入力ポート７４０が現れる。マウスポインタが入力ポートの一方に近づくと、図形線７２０はその入力ポートに飛びつき、マウスクリックで所定場所に固定される。これにより、効果６５０と効果７００の間に論理的及び図形的な連結が確立される。
【００４５】
これらの論理的及び図形的な連結が確定されると、ユーザは、グラフ・ウィンドー内で効果アイコンが連結されたグループ８００を「箱に入れる」ことができる（図８）。ここで、「箱に入れる」とは、コンピュータ・マウスを使って標準的な方法で上記グループの周りに箱を描くことである。（これを実現する１つの方法は、箱の左上隅でクリックして保持し、マウスを右下隅に引き、これからマウスボタンを放すことである。これは、複数の画面のオブジェクトを選択する標準的方法である。）
【００４６】
ユーザはそれから、連結された効果のグループをパレット領域に引き込むことができる。これにより、該グループの入力から形成される一連の入力と、該グループの出力から形成される一連の出力とを有する新しい複合効果アイコン８１０が作成される。論理的にいえば、効果アイコン８１０は、特定のプラグインにマッピングされないで、特定の方法で相互連結されたプラグインの連結グループにマッピングされる。
【００４７】
複合効果アイコン８１０は、それからパレット・ウィンドーの一部となり、ユーザによりグラフの設計に使用される。ユーザがあとで複合アイコン８１０を利用したい場合、単にそれをグラフ・ウィンドーの適所に引き込むだけでよい。効果アイコン８１０は、グラフ・ウィンドー上でも１つのアイコンのままであるのがよいが、他の具体例では元のグループ８００に引き伸ばすこともある。或いはまた、１つのアイコンとして圧縮した形で表示してもよい。ただし、ユーザが引き伸ばしボタンをクリックして元のアイコン・グループ８００を観察できるように、引き伸ばしボタン付きの表示とするのがよい。いずれにしても、アイコン８１０によって与えられる複合効果は、元のグループ８００のコピーである。
【００４８】
図９は、この方法の根底にあるデータメモリを示す。図９において、アイコン８５０は、パレット領域６００におけるパレットアイコン６２０からグラフ・エディタ領域６１０に引き込まれたものである。
パレット領域６００について述べると、図３に示したパレット３５６には、ルート（根）８６０及び該ルートからぶら下がる個々のデータ項目８７０を有するツリー（木）のように配置されたデータ構造が記憶される。各データ項目８７０は、１つの効果アイコン６２０を表すが、効果８７５のような複合効果の場合は別である。この場合、その効果を形成する効果アイコン（３ａ，３ｂ）は、そのデータ項目８７５からぶら下がる下部構造として配置される。
【００４９】
グラフ・エディタ領域には、効果を記憶する類似のデータ構造が存在する。ここでは、ただ１つの効果８８５がぶら下がったルート８８０が示されている。グラフ・エディタ領域において幾つかの効果をグループとして一緒に集めパレットに引き込む場合、それらは更に、構造８７５に似た複合効果構造となる。
【００５０】
図１０は、ビューワーウィンドーの概略図である。ビューワーウィンドーは、画像表示領域９００、種々の「属性ページ」９１０、効果制御部９２０（ここでは、照明効果の例における位置決め十字線を示す。）及び「バーボタン」９３０を具えている。
ビューワーウィンドーの基本配置は、コア構造部によって設定され、効果ごとに基準となるものである。ただし、属性ページ９１０を用いて調整できる個々の項目は、特定の効果に対応する効果ユーザインタフェース（ＵＩ）３２０によって設定される。効果ＵＩ３２０はまた、制御部９２０に対する表示の細目を与える。
【００５１】
図示の例では、十字線９２０は、照明効果における光のソース又は目標位置を決定する。ユーザは、コンピュータ・マウスを用いて十字線を移動させることができる。十字線を移動させると、当該制御に関連するパラメータ（ｘ，ｙ）値が変わり、図４の手順（パラメータ値の更新）が開始される。その手順の最後のステップ４０８（図４）で、効果ＵＩは訂正されたパラメータ値をビューワーウィンドーに発する。その段階で、十字線はその新しい位置に再表示される。したがって、ユーザには移動操作が十字線を最終の位置に動かしたように見えるが、実のところは、移動操作がパラメータを図４に示す経路によって更新させ、その結果十字線の移動が生じたのである。
【００５２】
図１１は、作動ソフトウェアの初期の配置を模式的に示すものである。これは、本装置の特定の動作期間において何等かの描画を行う前の状態を表す。
プラグインは、「ダイナミック・ロード・ライブラリー（ＤＬＬ）」のようなウィンドーズ・オペレーティング・システムによって実現できる。ＤＬＬは一般に、プログラムコード、データ及びサブルーチン・ライブラリを含む大きなファイルである。従来、記憶を保存し、システムの性能を改善するために、ＤＬＬによって取扱われる特定の処理の実行又は開始のため最初に必要なときにＤＬＬをメモリに格納していた。この具体例では、記憶保存及びシステム性能改善のこのアイディアを、更に一歩進めて用いる。
【００５３】
即ち、パレット領域から１つの効果アイコンを最初に取出すとき、従来は、その効果に対応するＤＬＬをメモリに格納して、コア・プロセッサ３４０にグラフを作成するための十分な情報（例えば、他の効果アイコンとの相互連絡性）を提供していた。
【００５４】
この具体例では、当該効果に対するＤＬＬをその段階では格納しない。その代わりに、該効果を表すいわゆる「メタデータ」１０００を格納する。このメタデータは、コア・プロセッサに、該効果と他の効果との相互連絡性を定める情報（例えば、入力と出力の数）を提供する。これにより、コア・プロセッサは何もＤＬＬを格納することなくグラフを作成することができ、それらが絶対に必要となるまで大きなファイルを格納しないので、メモリの節約になる。
【００５５】
ビューワーウィンドーが或る効果に関連して開かれているか、又は複合効果が他の手段によって実行されている場合は、ＤＬＬが格納され、メタデータは破棄されるか又は無視される。
図１２〜１４は、特に本システムの自動化を容易にする効果プラグインの機能的特徴を模式的に示すものである。
【００５６】
図１２は、以前に提案されたプラグインの模式図である。この効果プラグインは、画像情報（「クリップ」１３００として示す。）を受けて、３つの処理パラメータＰ１，Ｐ２及びＰ３（照明位置など）に基いて動作する。図１２のプラグインでは、パラメータ値は、プラグイン内に、即ちプラグインの一部として書かれた注文プログラムコードにより設定される。このため、例えば、パラメータが時間と共に変化する動画システムや、照明位置のようなパラメータが、モーショントラッカのような他の効果によって変化する装置では、効果プラグイン内に余分なコードを加えたものや、多数の効果プラグインを複合したものがしばしば必要となり、パラメータの総合的な制御が極めて難しくなる。
【００５７】
図１３は、本発明の実施形態による他の方法を示す模式図である。ここで、各パラメータは、「主」効果プラグイン１３３０に連結された別々のプラグイン１３２０により、効果間の連結が上述のグラフ・エディタにおいて定められたのと同様にして定められる。実のところ、上述の説明はプロセス全体を簡略化して行ったものであるが、簡略化は説明を助けるためである。
【００５８】
パラメータ・プラグインは、例えば、グラフ・エディタ及びパレットにおける「ページから離れた」スクリーン位置にそれらを表示することにより、通常はユーザから隠されている。
そこで、或る効果を自己充足の非動画式に（即ち、他の効果からパラメータ値を移入することなく）作動させようとする場合、主効果のビューワーウィンドーを用いて各パラメータ・プラグイン１３２０に対するパラメータを設定する。
【００５９】
パラメータを他の効果の出力、例えば動き追跡効果によって与えられる位置の値により決めようとする場合、主効果プラグイン１３３０と適切なパラメータ・プラグイン１３２０との間の論理リンクを切り離し、動き追跡効果とのリンクを開始させればよい。
この方式が動画化にいかに役立つかを理解するために、図１４を参照する。
【００６０】
図１４は、最初に図３に示したコア側とプラグイン側の間を左右に分けた各部分を示す。図１４の左側には、１つのプロキシ効果（ＰＥ）１３４０が「主」効果サーバ１３５０に対して設けられている。また、複数のプロキシ効果１３６０がパラメータ・プラグイン１３２０の各々に対して設けられる。これらのプロキシ効果１３６０は、プロキシ効果１３４０よりずっと簡単なものであり、プロキシ効果１３６０とパラメータ・プラグイン１３２０との間の通信は、プロキシ効果１３４０と効果サーバ１３５０との間の通信プロトコルの簡略化された部分集合を使用して行う。
【００６１】
実際のところ、プロキシ効果１３６０は単一のデータ値（非動画システムの場合）でよく、或いは動画システムではそれらの値のリストでもよい。動画システムでは、データ値のリストは「キーフレーム」値、即ち連続する個々の画像のために設定されたデータ値として表現でき、間に介在する値は、線形もしくはユーザが決めた非線形補間に従ってコア側により補間される。よって、動画を、各プラグイン内に注文動画ソフトウェアを書込むことなく、特に簡単で便利な方法で作成することができる。
【００６２】
この説明を先に効果間の依存性について述べた説明と結びつけると、描画マネージャから「描画準備」メッセージを効果サーバ１３５０が受取ったとき、それに応答して、出力を供給する前にその入力が全部必要である、と告げることができる。効果の入力には勿論パラメータ・プラグインが含まれるので、次の段階で描画マネージャは描画準備メッセージを各パラメータ・プラグインに送ることになるであろう。パラメータ・プラグインが単一の値しか含まないか、或いは現在の画像がキーフレームであれば、パラメータ・プラグインは直ちに適切なパラメータを描画時に供給することができる。しかし、パラメータ・プラグインが動画データを含み、現在の画像がキーフレームでなければ、パラメータはまず補間してから効果に使用しなければならない。
【００６３】
図１５は、システム・キャッシュ１１００の模式図である。これは全キャッシュ領域の概略図であり、実のところ、先に述べたように、キャッシュはまた、夫々のプロキシ効果に対応した複数の個々のキャッシュと見ることもできる。しかし、かような個々のキャッシュにメモリ資源が動的に割当てられるので、図１５の表示も正しいものである。
【００６４】
キャッシュは、システム・メモリ１５０の中に設けられ、画像１１１０及び効果からの非画像描画出力１１３０（例えば、動き追跡効果の場合の動きベクトル）を記憶することができる。
【００６５】
キャッシュの意図は、有向非繰返しグラフ内の各効果の描画出力（これが画像であるかどうかに拘らず）を記憶することである。こうすると、或る効果の有向非繰返しグラフにおける特定の位置が変更された場合、その位置よりあとの効果を描画し直して新しい出力を供給する必要がなくなる。代わりに、キャッシュされている出力を再使用できる。更なる利点は、特定の効果（開かれたビューワーウィンドーに表示されたもの）の出力をパラメータ変更の前後に記憶することにより、取消し／やり直し動作を助け動作の速度を早めることである。対応するパラメータ変更も記憶されるので、キャッシュメモリ１１００から適切な素材を格納することにより、パラメータの変更を簡単に取消したり、やり直したりすることができる。これは、変更が行われたときに効果サーバによって書込まれた取消し／やり直しオブジェクトの制御の下に行われる。
【００６６】
画像は、動きベクトルのような簡単なデータ値よりはるかに大きなメモリ空間、恐らく百万倍のメモリ空間を占める。したがって、この具体例では、キャッシュメモリが容量の限界に近づいている状態で他の画像を記憶しようとするときは、最も前にアクセスしたキャッシュ内の画像を削除して、新しく記憶する画像のための空間を作る。ただし、キャッシュ内の他のデータ、パラメータ値や非画像描画出力などは、画像に比べるとほんの僅かのメモリ空間しか使わないので、本装置の動作期間中は削除しない。よって、この情報は、該情報が動作期間を通じて有効である限り、再使用又は取消し／やり直し動作に使用できる。
【００６７】
実際には、データ項目を洗い流せるかどうかをプラグインに指定させるようにすることができる。即ち、画像データ項目は取決めにより洗い流せるものと設定し、非画像データ項目は洗い流せないものと設定することができる。
【００６８】
図１６は、コア・プロセッサ３４０及び効果サーバ３３０間の非同期／同期コンバータ（プラグイン・インタフェース）１２００の模式図である。
コンバータ１２００は、描画マネージャから非同期再描画コマンドを、「行うべき」列、即ち行うべき描画ジョブのリストの形で受取る。１つのジョブが終わると、「終了」メッセージがコンバータ１２００から描画マネージャに返送される。
コンバータ１２００は、非同期のジョブ要求を受け、同期要求を適切なソフトウェア・プラグインに発する。これは、インタフェース１２００が制御「スレッド」（ウィンドーズ用語）をソフトウェア・プラグインに回送することを意味し、これが、該ジョブが完了するまで該スレッドの制御を保持することになる。その時のみ、ソフトウェア・プラグインが該スレッドをインタフェースに返送し、該インタフェースが「終了」メッセージをコア側に発して応答する。
【００６９】
初期設定の際、コア・プロセッサは、各プラグイン（又はむしろ当該プラグインに関連するメタデータ）に問合せて、該プラグインが同期又は非同期通信を処理できるかどうかを決定する。ハードウェア・プラグイン（例えば、特定の方法で描画するための周辺カード）又は恐らく異なる機械で作動している非同期ソフトウェア・プラグインをソフトウェア・プラグインの代わりに組込めば、ハードウェア・アクセラレータはこのような動作に極めてよく適しているので、該プラグインはコア側（実のところ、非同期的に描画タスクを開始する描画マネージャ）と非同期インタフェースを介して対話を行う。したがって、この場合、コンバータ１２００は迂回される。
【００７０】
コンバータは、コア側の一部として又は各関連プラグインの一部として実施してもよい。
よって、コンバータ１２００を２つのソフトウェアの間に設けるという反直観的な方法により、将来専用ハードウェアに改良される効率的なハードウェア・インタフェースが提供される。
【００７１】
【発明の効果】
以上説明したとおり、本発明によれば、コア・プログラム・オブジェクトがデータ処理タスクを実行できる複数のプラグイン・プログラム・オブジェクトと対話してそれらの動作を制御するデータ処理装置を得ることができる。
【図面の簡単な説明】
【図１】デジタルビデオ特殊効果装置の概略図である。
【図２】図１の装置の作動ソフトウェアの編成を示す概略図である。
【図３】図１の装置の作動ソフトウェアの編成の詳細を示す模式図である。
【図４】図１の装置における更新された効果パラメータの伝播状態を示す模式図である。
【図５】図１の装置における再描画コマンドの伝播状態を示す模式図である。
【図６】グラフ・エディタ・ウィンドー及びパレット・ウィンドーを示す概略図である。
【図７】グラフ編集動作の例を示す説明図である。
【図８】複合効果アイコンの作成例を示す説明図である。
【図９】複合効果のファイル構造を示す模式図である。
【図１０】ビューワーウィンドーの概略図である。
【図１１】作動ソフトウェアの初期配置を示す模式図である。
【図１２】以前に提案された効果プラグインの模式図である。
【図１３】新しい形式の効果プラグインの模式図である。
【図１４】図１３の効果プラグインにおける効果サーバとプロキシ効果との関係を示す模式図である。
【図１５】システム・キャッシュを示す概略図である。
【図１６】プラグイン・インタフェースを示す概略図である。
【符号の説明】
１２００‥‥非同期／同期コンバータ、１３４０‥‥コア・プログラム・オブジェクト、１３５０‥‥プラグイン・プログラム・オブジェクト

Claims (3)

1. コア・プログラム・オブジェクトが、データ処理タスクを実行する動作ができる複数のプラグイン・プログラム・オブジェクト及び／またはハードウェア・デバイスと対話して、それらの動作を制御するデータ処理装置であって、
   上記コア・プログラム・オブジェクトは、上記データ処理タスクを実行させる非同期の要求を発生し、上記プラグイン・プログラム・オブジェクトのうち上記データ処理装置で作動しているプラグイン・プログラム・オブジェクトに対しては、上記非同期の要求を非同期／同期コンバータを介して同期要求として送り、上記プラグイン・プログラム・オブジェクトのうち上記データ処理装置とは異なる機械で作動しているプラグイン・プログラム・オブジェクト及び上記ハードウェア・デバイスに対しては、上記非同期の要求を上記非同期／同期コンバータを介さずに送る
   データ処理装置。
2. 上記非同期／同期コンバータは、上記コア・プログラム・オブジェクトの一部として実施される
   請求項１の装置。
3. 上記非同期／同期コンバータは、上記プラグイン・プログラム・オブジェクトのうち上記データ処理装置で作動している各プラグイン・プログラム・オブジェクトの一部として実施される
   請求項１の装置。

Images