JP2000089960A - デ―タ処理装置 - Google Patents

Abstract

(57)【要約】 【課題】 ストレージ及びストリームの両方をプラグイ
ンに割当てられるようにしてプラグイン設計及び動作に
かかる制約を減じる。 【解決手段】 本発明のデータ処理装置は、装置の全般
的な動作を制御するコア・オブジェクトと、該コア・オ
ブジェクトと通信するように配された複数のプラグイン
ＣＯＭオブジェクトとを有し、上記コア・オブジェクト
は、作業データの記憶及び／又は検索に用いるため、Ｃ
ＯＭストリーム・インタフェース及びＣＯＭストレージ
・インタフェースを上記プラグインＣＯＭオブジェクト
に与える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ＯＬＥシステムに
おけるデータ処理装置に関するものである。

【０００２】

【従来の技術】コンピュータ使用データ処理装置の中に
は、「コア」コンピュータ・プログラム及び必要な時に
格納できる幾つかのプログラム・モジュール又は「プラ
グイン」を利用するものがある。

【０００３】該データ処理装置の種々の部分が互いに連
絡できる１つの方法として、いわゆる「Object Linking
and Embedding」（ＯＬＥ）プロトコルがある。これ
は、１９９６年Microsoft Press 発行，David Chappell
著「Understanding Active Xand OLE 」という本に記載
されている。

【０００４】ＯＬＥシステムでは、ソフトウェア設計者
は、コンピュータ・プログラムの種々異なるセクション
をいわゆる「ＣＯＭ（Component Object Model）オブジ
ェクト」として実現できる。各ＣＯＭオブジェクトは、
各々が幾つかの「メソッド」を含む１以上の「ＣＯＭイ
ンタフェース」を支えている。メソッドは、特定の運動
を実行する機能又は手順である。ＣＯＭメソッドは、上
記ＣＯＭオブジェクトを使用するソフトウェアによって
呼び出すことができる。このシステムでは、ＣＯＭオブ
ジェクトを使用するソフトウェア（いわゆる「クライア
ント」）の他の部分は、所定のインタフェースを介して
のみそうすることができるように制約されている。即
ち、それらは、所定のＣＯＭインタフェースを介さなけ
れば、該オブジェクト内のプログラムコード又はデータ
に直接アクセスすることができない。

【０００５】この構造形式が有用なデータ処理装置の一
例として、コンピュータ使用ビデオ特殊効果装置があ
る。かような装置では、ユーザは一般に多数の使用可能
なモジュールから一連の効果モジュールを選択すること
により、或るビデオシーケンスに適用する合成特殊効果
を設定することができる。例えば、ユーザによって設定
される一連の効果には、次のようなものが含まれるであ
ろう。 （ｉ）イメージローダ（画像を格納するもの） （ii）モーショントラッカ（動きを追跡するもの） (iii) 動きの追跡とイメージローダに連動した照明効果 （iv）動きの追跡とイメージローダに連動した画像再編
成

【０００６】これらの効果の各々はプログラム・モジュ
ール又はプラグイン（ＣＯＭオブジェクト）として具現
され、データは、コア・プログラム（プラグインとの通
信が要求されるときＣＯＭインタフェース（単数又は複
数）を与えることができる１以上のオブジェクト）の全
般的制御の下にモジュール間を転送される。したがっ
て、上記コア及びプラグイン・プログラム間のインタフ
ェースはＣＯＭシステムによって定められるが、プラグ
イン設計者は一般に、そのレベルを越えて適当な方法で
それらのインタフェースの下で必要なメソッドを自由に
実施できる。

【０００７】多数のＣＯＭオブジェクトを用いるこのタ
イプのシステムでは、各オブジェクトがその作業又は結
果データを別々のデータファイルに蓄えるべきだとする
のは望ましくない、と一般に考えられている。実際に、
この議論を深めた場合、そのようにすれば、ＯＬＥシス
テムを確立させた論理の多くと合わないことが、明らか
となるであろう。代わりに、このタイプのシステムのデ
ータは、全部のオブジェクトによりただ１つのファイル
又は「複合文書」に記憶される。ただし、整理された構
造であれば、複合文書内に記憶される。

【０００８】元来、複合文書内にはファイル及びディレ
クトリ構造に似た或る構造が設けられている。ディレク
トリの均等物はいわゆる「ストレージ」であり、ファイ
ルの類似物はいわゆる「ストリーム」である。各複合文
書はルート（根）ストレージを有し、その下方にはスト
レージ及びストリームのよく知られた木構造がある。Ｃ
ＯＭストリーム・インタフェースはＣＯＭストレージ・
インタフェースより簡単であるが、勿論ストレージ・イ
ンタフェースの方がもっと柔軟性がある。

【０００９】一般に、各ＣＯＭオブジェクトを自分のス
トレージ又は自分のストリームに割当て、その中に作業
データを記憶させることができる。しかし、コア・プロ
グラムが幾つかのプラグインの動作を調整する上述のビ
デオ特殊効果プロセッサのような階層システムにおいて
は、これまで１つのストリームを各効果プラグインに割
当てるようにしていた。

【００１０】

【発明が解決しようとする課題】本発明は、単にストレ
ージ又はストリームのいずれか一方を所定の方法で全プ
ラグインに割当てることは、プラグイン・オブジェクト
の設計及び動作に余りに多くの制約を課すことになると
の認識に基き、代わりに、設計者が望めば、プラグイン
がその作業データを容易に記憶できるようにプラグイン
にストリームを割当て、同じく望めば、プラグインがそ
の作業データを複数のストリームとストレージの自己の
「ディレクトリ」配置の下で記憶できるようにプラグイ
ンにストレージを割当てられるようにしようとするもの
である。そうすれば、その選択をプラグイン設計者に任
せることができる。

【００１１】

【課題を解決するための手段】本発明によるデータ処理
装置は、装置の全般的な動作を制御するコア・オブジェ
クトと、該コア・オブジェクトと通信するように配され
た複数のプラグインＣＯＭオブジェクトとを有し、上記
コア・オブジェクトは、作業データを記憶及び／又は検
索するのに使用するため、ＣＯＭストリーム・インタフ
ェース及びＣＯＭストレージ・インタフェースを上記プ
ラグインＣＯＭオブジェクトに与えることを特徴として
いる。

【００１２】

【発明の実施の形態】以下、図面を参照して本発明を具
体的に説明する。図１は、本発明を適用できるデジタル
ビデオ特殊効果装置の概要図である。図１において、連
続する画像を表すデジタルビデオ信号は、入力インタフ
ェース（Ｉ／Ｆ）１００を介して受信されディスクアレ
イ装置１１０に記憶される。ディスクアレイ装置１１０
はまた、本効果装置により生成された処理済み画像をも
記憶し、これらは出力インタフェース１２０を介し出力
として供給される。

【００１３】中央処理ユニット（ＣＰＵ）１３０は、デ
ィスクアレイに記憶されたデータにアクセスし、ユーザ
の指令（コマンド）に従い種々のビデオ特殊効果を達成
する。ＣＰＵ１３０は、マウス及びキーボードのような
ユーザ入力装置１４０から入力を受け、作業データ及び
プログラムコードをメモリ１５０に記憶させ、出力デー
タを生成し、表示駆動部１７０を介してスクリーン１６
０に表示させる。

【００１４】本効果装置は、適当なソフトウェア、例え
ばマイクロソフト・ウィンドーズＮＴ（登録商標）オペ
レーティングシステムにより動作する汎用コンピュータ
（例えば、ＰＣ）として具現することができる。この例
では、ディスクアレイは、ウルトラＳＣＳＩデータリン
クを介してＣＰＵ１３０に接続される。

【００１５】図２は、図１の装置に使用する作動ソフト
ウェアの編成の概略を（極めて一般的な水準で）示すも
のである。このソフトウェアは、２種類のプログラムコ
ードより成り、１つは図２の左側に示すコア構造部であ
り、もう１つは図２の右側に示す種々のプラグイン部で
ある。このソフトウェアが初めに格納されると、コア構
造部は、常に存在して異なる特殊効果プロセス間で共通
する本装置の動作の各部分を制御する。これに対し、プ
ラグライン部は、個々の特殊効果（照明効果、動き追跡
効果など）に関するもので必要な時にのみ格納される。

【００１６】この配置は、現在ユーザが要求する効果モ
ジュールに関するプラグインのみをメモリに格納すれば
よいので、極めて効率のよいものである。こうすると、
想定されるすべての特殊効果に対するプログラムコード
を格納しなければならないシステムに比べて、メモリを
少なくすることができる。これはまた、装置の初期設定
をもつと迅速化し、システムを最初スタートさせる際に
プログラムコードをすべてメモリに格納する必要をなく
し、グラフエディタ（後述参照）において最初にアイコ
ンを選ぶときのコードの格納による遅延を少なくするこ
とができる。更に、この配置は、グラフエディタ及びプ
ラグインを除くコア処理のみを含むので、供給又は組込
むべき装置部品（特に、作動ソフトウェア）を減らすこ
とができる。このシステムはまた第三者又はユーザがプ
ラグイン部及びコア構造部間の決められたインタフェー
ス・プロトコルを守る限り、彼等自身のプラグインを生
成することを可能にしている。よって、ユーザは、比較
的小さなプラグイン・プログラムを書込むことにより、
注文の効果を極めて簡単に生成することができよう。

【００１７】コア構造部及びプラグイン部は、David Ch
appell著1996年Microsoft Press 発行の「Understandin
g Active X and OLE」という本に記載された、いわゆる
ＯＬＥ（Object Linking and Embedding）プロトコルを
用いて互いに伝達を行う。

【００１８】ＯＬＥシステムでは、ソフトウェア設計者
は、コンピュータ・プログラムの種々異なるセクション
をいわゆる「ＣＯＭ（Component Object Model）オブジ
ェクト」として実現できる。各ＣＯＭオブジェクトは、
各々が幾つかの「メソッド」を含む１以上の「ＣＯＭイ
ンタフェース」を支えている。メソッドは、特定の運動
を実行する機能又は手順である。ＣＯＭメソッドは、上
記ＣＯＭオブジェクトを使用するソフトウェアによって
呼び出すことができる。このシステムでは、ＣＯＭオブ
ジェクトを使用するソフトウェアの他の部分は、所定の
インタフェースを介してのみそうすることができるよう
に制約されている。即ち、それらは、所定のＣＯＭイン
タフェースを介さなければ、該オブジェクト内のプログ
ラムコード又はデータに直接アクセスすることができな
い。

【００１９】そこで、本システムでも、コア構造部はプ
ラグイン部とこれらのＣＯＭインタフェースを介して伝
達を行う（実のところ、コア構造部は、ＣＯＭインタフ
ェースを提供できる幾つかの相互連絡オブジェクトを有
するが、基本原理は同じである。）。

【００２０】図３は、図２に示したものよりずっと詳細
に作動ソフトウェアの編成を示すものである。図３は、
４つの象限に分割されている。左上の象限はいわゆるビ
ューワーウィンドー３１０を示し、右上の象限は効果ユ
ーザインタフェース（ＵＩ）３２０を示し、右下の象限
は、関連するパラメータデータ（ＰＤ）を有する「効果
サーバ」３３０を示し、左下の象限は、オブジェクトマ
ネージャ３５０、描画マネージャ３５２及び変更マネー
ジャ３５８と共にグラフを含むコア・プロセッサ３４０
を示す。左下と右下の象限の間のインタフェースには、
ウィンドーズＮＴレジストリの一部をなすメタ・データ
ベース３５４と、効果アイコンを含むパレット３５６
と、省略パラメータ値とがある。メタ・データベース３
５４については図１１を参照してあとで説明する。パレ
ット３５６については図６〜９を参照して後述する。

【００２１】コア・プロセッサ３４０内には、個々の特
殊効果を続けて連結した「グラフ」、即ち「有向非繰返
しグラフ」がある。各効果は、グラフ内でプロキシ（代
理）効果（ＰＥ）として表示されている。各ＰＥは、効
果の出力が得られると直ちにこれを記憶するキャッシュ
（Ｃ）を有するので、例えば一連の効果の中で重要な効
果に関連するパラメータが変化した場合、一連の効果の
中の効果からデータを再使用することができる。各プロ
キシ効果は、夫々の効果サーバ３３０と対応している。

【００２２】オブジェクトマネージャ３５０は、システ
ム内で用いるオブジェクトの存続期間やメモリ処理を制
御する責任をもつ。描画マネージャ３５２は、描画タス
クの開始、進行、優先順位の指定及び停止を制御する。
変更マネージャ３５８は、情報の取消し／やり直し及び
システム各部への変更の連絡を制御する。

【００２３】図３は、基本的に、左側の２つの象限（左
上及び左下）がどの効果にも関係しないというコア構造
部の機能的特徴を示すように分割されている。これらの
オブジェクトは、ユーザがどの特殊効果を実施しようと
望んでいるかに関係なく、メモリに格納される。右側の
２つの象限（右上及び右下）は、プラグイン部に関係す
る。各プラグインは、そのプラグインによって実施され
る効果に関連した処理を行うサーバ３３０と、その効果
に関するユーザインタフェース制御（実際は、ビューワ
ーウィンドー３１０における表示制御）を行うユーザイ
ンタフェース（ＵＩ）３２０とを有する。

【００２４】図３には同様の上下に分ける分割線があ
り、これにより、２つの上方の象限（左上及び右上）は
特殊効果に関連するユーザインタフェース制御に関係
し、２つの下方の象限（左下及び右下）はそれらの効果
を実施するために行う処理や編成に関係していることを
示す。

【００２５】ビューワーウィンドー３１０は、本装置に
よって実行するために作成された一連の効果のうち特定
の効果の出力及びそれの制御パラメータを観察する機会
をユーザに与えるものである。即ち、ユーザがビューワ
ーウィンドーを開くと、或る効果の出力が生成される
か、或いは可能な場合キャッシュ・メモリから検索され
る。

【００２６】多数のＣＯＭオブジェクトを使用するこの
タイプのシステムでは、各オブジェクトがその作業又は
結果のデータを別々のデータファイルに蓄えるべきだと
するのは望ましくない、と一般に考えられている。実
際、そのようにすると、ＯＬＥシステムを確立させた論
理の多くと合わないようである。代わりに、このタイプ
のシステムのデータは、全部のオブジェクトによりただ
１つのファイル又は「複合文書」に記憶される。ただ
し、順序付けされた構造であれば、複合文書内に記憶さ
れる。

【００２７】元来、複合文書内にはファイル及びディレ
クトリ構造に似た或る構造が設けられている。ディレク
トリの均等物はいわゆる「ストレージ」であり、ファイ
ルの類似物はいわゆる「ストリーム」である。各複合文
書はルート（根）ストレージを有し、その下方にはスト
レージ及びストリームのよく知られた木構造がある。Ｃ
ＯＭストリーム・インタフェースはＣＯＭストレージ・
インタフェースより簡単であるが、勿論ストレージ・イ
ンタフェースの方がもっと柔軟性がある。

【００２８】一般に、各ＣＯＭオブジェクトを自分のス
トレージ又は自分のストリームに割り当て、その中に作
業データを記憶させることができる。しかし、コア・プ
ロセッサ３４０が幾つかのプラグインの動作を調整する
本ビデオ特殊効果プロセッサのような階層システムにお
いては、これまで１つのストリームを各効果プラグイン
に割当てるようにしていた。

【００２９】これに対し、本実施態様では、単にストレ
ージ又はストリームのいずれか一方をプラグインに割当
てることは、プラグイン・オブジェクトの設計及び動作
に余りに多くの制約を課すことになると認識されてい
て、代わりに、コア構造部とプラグイン部との間のイン
タフェース定義において、各プラグインは、プラグイン
設計者が望む場合、その作業データを容易に記憶できる
ように１つのストリームを選択でき、同じく望む場合、
複数のストリームとストレージの自己の「ディレクト
リ」配置の下でその作業データを記憶できるように１つ
のストレージを選択できるようになっている。この選択
は、プラグイン・プログラムコードを作成するプラグイ
ン設計者によって予め行われる。

【００３０】以下の説明において、種々のオブジェクト
間の通信プロトコルについては図４及び図５に関連して
説明し、コア・プログラム３４０のグラフエディタ部を
用いて個々の効果を連結し、複合効果を作る方法につい
ては図６〜図９を参照して説明し、ビューワーウィンド
ー及びそれと効果ユーザインタフェース（ＵＩ）３２０
との対話については、図１０を参照して説明する。

【００３１】図４は、図３の配置における更新された効
果パラメータの伝播状態を模式的に示す。この伝播状態
は、ユーザが「照明」特殊効果を設定し、光源の効果が
画像に加えられる場合の例である。光源は、ユーザが定
めるソースと画像に関する行先位置とを有する。ユーザ
がこれらの位置の１つを変えたいと望む場合、現在該効
果から描画されている出力を無効とし、その変化を図３
の異なる象限に示す種々のオブジェクトに伝達させる必
要がある。この処理過程を図４に示す。

【００３２】図４において、ユーザは、変更されたパラ
メータをビューワーウィンドー３１０を介して実際に書
入れる（図１０参照）。ビューワーウィンドーは特定の
効果ユーザインタフェース３２０と対応しており、この
インタフェースはまた個々の効果に関する各プラグイン
の一部をなす。（実のところ、１つのビューワーウィン
ドーを１より多い効果と対応させることができ、任意の
特定時間に開かれるビューワーウィンドーをすべての効
果がもつには及ばないが、都合上図３の簡略化された配
置に基いて説明する。）プラグインは、「これより編集
に入る（aboutto edit)」との通知をコア側に発する。

【００３３】上記の変更が行われた後、プラグインは
「変更発生」メッセージを発する。これにより、一連の
動作が発生及び／又は開始される。最初のステップ４０
１で、ビューワーウィンドーは更新されたパラメータを
効果ＵＩ３２０に伝達する。効果ＵＩ３２０は、「セッ
ト」コマンドを対応する効果サーバ３３０に発し、修正
された値を効果サーバ３３０内のパラメータ・メモリに
セットさせる。このステップを図４の４０２で示す。

【００３４】ステップ４０３で、効果サーバ３３０は、
「取消し／やり直し」オブジェクトをコア・プロセッサ
３４０の中に書込んで、変更の前後におけるパラメータ
の（効果サーバ内の）記録を指し示すハンドル又はポイ
ンタの詳細を供給する。この「取消し／やり直し」オブ
ジェクトを受取ると、ステップ４０４で、コア側は、パ
ラメータが変更され幾つかのキャッシュされたデータ出
力が無効になるかも知れないという通知を全ビューワー
ウィンドーに流す。この通知は、パラメータの変更が行
われたビューワーウィンドーに限定されない。

【００３５】ステップ４０５で、各ビューワーウィンド
ーは、対応する効果ＵＩ３２０にその処理パラメータの
更新を要求するメッセージを発する。ステップ４０６
で、効果ＵＩ３２０は、「ゲット」コマンドを対応する
効果サーバに発して新しいパラメータを得させる。新し
いパラメータは、ステップ４０７で効果ＵＩ３２０に返
送される。効果ＵＩはそれから、ステップ４０８でビュ
ーワーウィンドーにその変化を伝えて表示させる。

【００３６】一般に、処理パラメータが変わると、１つ
以上の効果出力の描画をやり直す必要が生じる。図５
は、描画し直しコマンドが装置内を伝播する様子を示
し、これは図４の処理から引き続いて起こる。

【００３７】ステップ５０２ではビューワーウィンドー
は描画し直しコマンドを描画マネージャ３５２に発す
る。すると、描画マネージャは描画し直しコマンドを対
応する効果サーバ３３０に発する。効果サーバは、画像
の作り直しを終えると、「終了」メッセージをコア・プ
ロセッサ３４０に発する。コア側は、ステップ５０５で
これをビューワーウィンドーに知らせ、ステップ５０６
及び５０７で、ビューワーウィンドーは効果ＵＩ３２０
と対話し描画し直した効果出力を表示する。

【００３８】数個のビューワーウィンドーが開き、数個
のフレームが関心の域（これは、テスト目的でユーザが
ビデオクリップ全体の部分集合として決めることができ
る。）内にある場合、処理資源をとっておくため次の優
先順に従い多数の同時発生タスクとして画像が描かれ
る。 （ｉ）ユーザが観察するために現在表示されている単数
又は複数の画像、（ii）関心のある出力シーケンスの最
初と最後の画像、(iii) 関心のある出力ビデオシーケン
スの残りの画像

【００３９】更に細かい段階として、描画マネージャ
は、効果サーバに描画し直しコマンドを発する前に、シ
ーケンス内のどの画像を描画すべきかを指定する「描画
準備」メッセージを発する。効果サーバは、これに応じ
てその「依存性」を、即ち描画マネージャから要求され
る前に必要となる描画像を作成しなければならないこと
を通知する。これらの画像は、他の効果（例えば、非繰
返し有向グラフにおける直ぐ前の効果）により描画され
るものか、或いはその効果自体によって描画されるもの
かも知れない。この後者の例は、モーショントラッカの
場合に起りうる。即ち、例えば、画像５を描くためにモ
ーショントラッカが画像４に対する自分の描画出力を必
要とする場合である。

【００４０】効果サーバから返送された該メッセージを
受取ると、描画マネージャは、それらの画像を求める
「描画準備」メッセージを送る。以下、従属ツリーが終
わるまで同様のことが行われる。各階段において、プロ
キシ効果は、要求された画像又は描画出力がキャッシュ
に記憶されたかどうかをチェックし、描画マネージャに
知らせる。

【００４１】そこで、例えば、画像５を指定する描画準
備メッセージがモーショントラッカに送られると、モー
ショントラッカは、これに応答して画像４に対する自己
の描画出力を要求していることを告げる。すると、描画
マネージャは、画像４に対する描画準備メッセージをモ
ーショントラッカに送る。モーショントラッカは、これ
に応答して画像３を要求していることを示す。以下同様
である。こうして、所要画像（画像５）が描画される前
に必要な描画ジョブのリストが作成される。キャッシュ
に記憶されている描画出力は、描画マネージャのジョブ
のリストには含まれない。

【００４２】或る効果が前の効果の描画出力を必要とす
る場合には同じことが起こり、同様に一連の効果を前に
さかのぼる。この過程が終わると、描画マネージャは、
現在要求されている画像が、それの依存する画像がすべ
て描かれるまでは描かないように逆の順序で、要求され
たすべてのジョブを進めてゆく。

【００４３】最適化の条件として、描画マネージャは、
各効果への入力が何であるかを前記グラフから検出する
のがよい。そして、効果サーバは、所定のコードを送り
（例えば、ゼロ応答）簡単に「この効果に対する入力は
すべて要求済み」と告げるとよい。

【００４４】更に、各効果サーバから、その出力が隣り
合う画像と同じであるかどうかを描画マネージャに知ら
せうるように、同じプロトコルを使用するとよい。これ
の簡単な例は、その出力が不変である場合の（一定）パ
ラメータ・プラグインである。更なる例は、どれか他の
効果の出力が既に準備されキャッシュに記憶されてい
て、連続する出力が同一かどうかを容易に検出できる場
合である。かような通知に応答して、描画マネージャ
は、有向非繰返しグラフで後の他の効果サーバにその情
報を送る。すると、その効果サーバは、（適当ならば）
一連の画像の１つだけを描画し、入力が変わらない他の
画像に対してその出力を繰返す。

【００４５】図６は、グラフ・エディタ・ウィンドー６
１０とパレット・ウィンドー６００を示す概略図であ
る。これらは、コア・プロセッサ３４０の制御の下に表
示スクリーン１６０に表示される。パレット・ウィンド
ー６００は幾つかのアイコン６２０を含み、これらの各
々は、考えられる種々の効果の１つにマッピングされ、
それらの効果を表している。本システムには、各効果に
対するプラグインが存在する。ユーザは、マウスを用い
てこれらのアイコンをスクロール可能なグラフ・ウィン
ドー６１０に「引き込む」ことができる。ユーザは、グ
ラフ・ウィンドー内にこれらのアイコンを配置し、該ウ
ィンドー内で図形線として示す論理リンク６３０で互い
に連結することができる。

【００４６】論理リンク６３０は、或る効果の出力を次
の効果の入力へ送ることを表し、（この具体例では）常
にグラフ・ウィンドーの下から上の方への向きをもつ。
即ち、図６の例は、イメージローダ（Ｉ／Ｌ）アイコン
６４０の出力を照明効果６５０に送ることを示す。

【００４７】ユーザがグラフ・ウィンドー内に上記の図
形線を描くと、コア・プロセッサ３４０は、論理リンク
を設定して描画出力が或る効果プラグインから他のプラ
グインに送られる経路を決定する。これより、図７を参
照して図形線を作成する方法を説明する。それから、図
８を参照して論理リンクを説明する。

【００４８】図７において、ユーザが照明効果を（例え
ば、マウスのクリックで）選択すると、アイコン６５０
からマウスポインタ７３０に向かう動かせる図形線７２
０が得られる。マウスポインタが混合効果アイコン７０
０に近づくと、その混合効果アイコンが拡大され、即ち
拡大線７１０に囲まれ、その最下部に２つの入力ポート
７４０が現れる。マウスポインタが入力ポートの一方に
近づくと、図形線７２０はその入力ポートに飛びつき、
マウスクリックで所定場所に固定される。これにより、
効果６５０と効果７００の間に論理的及び図形的な連結
が確立される。

【００４９】これらの論理的及び図形的な連結が確定さ
れると、ユーザは、グラフ・ウィンドー内で効果アイコ
ンが連結されたグループ８００を「箱に入れる」ことが
できる（図８）。ここで、「箱に入れる」とは、コンピ
ュータ・マウスを使って標準的な方法で上記グループの
周りに箱を描くことである。（これを実現する１つの方
法は、箱の左上隅でクリックして保持し、マウスを右下
隅に引き、これからマウスボタンを放すことである。こ
れは、複数の画面のオブジェクトを選択する標準的方法
である。）

【００５０】ユーザはそれから、連結された効果のグル
ープをパレット領域に引き込むことができる。これによ
り、該グループの入力から形成される一連の入力と、該
グループの出力から形成される一連の出力とを有する新
しい複合効果アイコン８１０が作成される。論理的にい
えば、効果アイコン８１０は、特定のプラグインにマッ
ピングされないで、特定の方法で相互連結されたプラグ
インの連結グループにマッピングされる。

【００５１】複合効果アイコン８１０は、それからパレ
ット・ウィンドーの一部となり、ユーザによりグラフの
設計に使用される。ユーザがあとで複合アイコン８１０
を利用したい場合、単にそれをグラフ・ウィンドーの適
所に引き込むだけでよい。効果アイコン８１０は、グラ
フ・ウィンドー上でも１つのアイコンのままであるのが
よいが、他の具体例では元のグループ８００に引き伸ば
すこともある。或いはまた、１つのアイコンとして圧縮
した形で表示してもよい。ただし、ユーザが引き伸ばし
ボタンをクリックして元のアイコン・グループ８００を
観察できるように、引き伸ばしボタン付きの表示とする
のがよい。いずれにしても、アイコン８１０によって与
えられる複合効果は、元のグループ８００のコピーであ
る。

【００５２】図９は、この方法の根底にあるデータメモ
リを示す。図９において、アイコン８５０は、パレット
領域６００におけるパレットアイコン６２０からグラフ
・エディタ領域６１０に引き込まれたものである。パレ
ット領域６００について述べると、図３に示したパレッ
ト３５６には、ルート（根）８６０及び該ルートからぶ
ら下がる個々のデータ項目８７０を有するツリー（木）
のように配置されたデータ構造が記憶される。各データ
項目８７０は、１つの効果アイコン６２０を表すが、効
果８７５のような複合効果の場合は別である。この場
合、その効果を形成する効果アイコン（３ａ，３ｂ）
は、そのデータ項目８７５からぶら下がる下部構造とし
て配置される。

【００５３】グラフ・エディタ領域には、効果を記憶す
る類似のデータ構造が存在する。ここでは、ただ１つの
効果８８５がぶら下がったルート８８０が示されてい
る。グラフ・エディタ領域において幾つかの効果をグル
ープとして一緒に集めパレットに引き込む場合、それら
は更に、構造８７５に似た複合効果構造となる。

【００５４】図１０は、ビューワーウィンドーの概略図
である。ビューワーウィンドーは、画像表示領域９０
０、種々の「属性ページ」９１０、効果制御部９２０
（ここでは、照明効果の例における位置決め十字線を示
す。）及び「バーボタン」９３０を具えている。ビュー
ワーウィンドーの基本配置は、コア構造部によって設定
され、効果ごとに基準となるものである。ただし、属性
ページ９１０を用いて調整できる個々の項目は、特定の
効果に対応する効果ユーザインタフェース（ＵＩ）３２
０によって設定される。効果ＵＩ３２０はまた、制御部
９２０に対する表示の細目を与える。

【００５５】図示の例では、十字線９２０は、照明効果
における光のソース又は目標位置を決定する。ユーザ
は、コンピュータ・マウスを用いて十字線を移動させる
ことができる。十字線を移動させると、当該制御に関連
するパラメータ（ｘ，ｙ）値が変わり、図４の手順（パ
ラメータ値の更新）が開始される。その手順の最後のス
テップ４０８（図４）で、効果ＵＩは訂正されたパラメ
ータ値をビューワーウィンドーに発する。その段階で、
十字線はその新しい位置に再表示される。したがって、
ユーザには移動操作が十字線を最終の位置に動かしたよ
うに見えるが、実のところは、移動操作がパラメータを
図４に示す経路によって更新させ、その結果十字線の移
動が生じたのである。

【００５６】図１１は、作動ソフトウェアの初期の配置
を模式的に示すものである。これは、本装置の特定の動
作期間において何等かの描画を行う前の状態を表す。プ
ラグインは、「ダイナミック・ロード・ライブラリー
（ＤＬＬ）」のようなウィンドーズ・オペレーティング
・システムによって実現できる。ＤＬＬは一般に、プロ
グラムコード、データ及びサブルーチン・ライブラリを
含む大きなファイルである。従来、記憶を保存し、シス
テムの性能を改善するために、ＤＬＬによって取扱われ
る特定の処理の実行又は開始のため最初に必要なときに
ＤＬＬをメモリに格納していた。この具体例では、記憶
保存及びシステム性能改善のこのアイディアを、更に一
歩進めて用いる。

【００５７】即ち、パレット領域から１つの効果アイコ
ンを最初に取出すとき、従来は、その効果に対応するＤ
ＬＬをメモリに格納して、コア・プロセッサ３４０にグ
ラフを作成するための十分な情報（例えば、他の効果ア
イコンとの相互連絡性）を提供していた。

【００５８】この具体例では、当該効果に対するＤＬＬ
をその段階では格納しない。その代わりに、該効果を表
すいわゆる「メタデータ」１０００を格納する。このメ
タデータは、コア・プロセッサに、該効果と他の効果と
の相互連絡性を定める情報（例えば、入力と出力の数）
を提供する。これにより、コア・プロセッサは何もＤＬ
Ｌを格納することなくグラフを作成することができ、そ
れらが絶対に必要となるまで大きなファイルを格納しな
いので、メモリの節約になる。

【００５９】ビューワーウィンドーが或る効果に関連し
て開かれているか、又は複合効果が他の手段によって実
行されている場合は、ＤＬＬが格納され、メタデータは
破棄されるか又は無視される。図１２〜１４は、特に本
システムの自動化を容易にする効果プラグインの機能的
特徴を模式的に示すものである。

【００６０】図１２は、以前に提案されたプラグインの
模式図である。この効果プラグインは、画像情報（「ク
リップ」１３００として示す。）を受けて、３つの処理
パラメータＰ１，Ｐ２及びＰ３（照明位置など）に基い
て動作する。図１２のプラグインでは、パラメータ値
は、プラグイン内に、即ちプラグインの一部として書か
れた注文プログラムコードにより設定される。このた
め、例えば、パラメータが時間と共に変化する動画シス
テムや、照明位置のようなパラメータが、モーショント
ラッカのような他の効果によって変化する装置では、効
果プラグイン内に余分なコードを加えたものや、多数の
効果プラグインを複合したものがしばしば必要となり、
パラメータの総合的な制御が極めて難しくなる。

【００６１】図１３は、本発明の実施形態による他の方
法を示す模式図である。ここで、各パラメータは、
「主」効果プラグイン１３３０に連結された別々のプラ
グイン１３２０により、効果間の連結が上述のグラフ・
エディタにおいて定められたのと同様にして定められ
る。実のところ、上述の説明はプロセス全体を簡略化し
て行ったものであるが、簡略化は説明を助けるためであ
る。

【００６２】パラメータ・プラグインは、例えば、グラ
フ・エディタ及びパレットにおける「ページから離れ
た」スクリーン位置にそれらを表示することにより、通
常はユーザから隠されている。そこで、或る効果を自己
充足の非動画式に（即ち、他の効果からパラメータ値を
移入することなく）作動させようとする場合、主効果の
ビューワーウィンドーを用いて各パラメータ・プラグイ
ン１３２０に対するパラメータを設定する。

【００６３】パラメータを他の効果の出力、例えば動き
追跡効果によって与えられる位置の値により決めようと
する場合、主効果プラグイン１３３０と適切なパラメー
タ・プラグイン１３２０との間の論理リンクを切り離
し、動き追跡効果とのリンクを開始させればよい。この
方式が動画化にいかに役立つかを理解するために、図１
４を参照する。

【００６４】図１４は、最初に図３に示したコア側とプ
ラグイン側の間を左右に分けた各部分を示す。図１４の
左側には、１つのプロキシ効果（ＰＥ）１３４０が
「主」効果サーバ１３５０に対して設けられている。ま
た、複数のプロキシ効果１３６０がパラメータ・プラグ
イン１３２０の各々に対して設けられる。これらのプロ
キシ効果１３６０は、プロキシ効果１３４０よりずっと
簡単なものであり、プロキシ効果１３６０とパラメータ
・プラグイン１３２０との間の通信は、プロキシ効果１
３４０と効果サーバ１３５０との間の通信プロトコルの
簡略化された部分集合を使用して行う。

【００６５】実際のところ、プロキシ効果１３６０は単
一のデータ値（非動画システムの場合）でよく、或いは
動画システムではそれらの値のリストでもよい。動画シ
ステムでは、データ値のリストは「キーフレーム」値、
即ち連続する個々の画像のために設定されたデータ値と
して表現でき、間に介在する値は、線形もしくはユーザ
が決めた非線形補間に従ってコア側により補間される。
よって、動画を、各プラグイン内に注文動画ソフトウェ
アを書込むことなく、特に簡単で便利な方法で作成する
ことができる。

【００６６】この説明を先に効果間の依存性について述
べた説明と結びつけると、描画マネージャから「描画準
備」メッセージを効果サーバ１３５０が受取ったとき、
それに応答して、出力を供給する前にその入力が全部必
要である、と告げることができる。効果の入力には勿論
パラメータ・プラグインが含まれるので、次の段階で描
画マネージャは描画準備メッセージを各パラメータ・プ
ラグインに送ることになるであろう。パラメータ・プラ
グインが単一の値しか含まないか、或いは現在の画像が
キーフレームであれば、パラメータ・プラグインは直ち
に適切なパラメータを描画時に供給することができる。
しかし、パラメータ・プラグインが動画データを含み、
現在の画像がキーフレームでなければ、パラメータはま
ず補間してから効果に使用しなければならない。

【００６７】図１５は、システム・キャッシュ１１００
の模式図である。これは全キャッシュ領域の概略図であ
り、実のところ、先に述べたように、キャッシュはま
た、夫々のプロキシ効果に対応した複数の個々のキャッ
シュと見ることもできる。しかし、かような個々のキャ
ッシュにメモリ資源が動的に割当てられるので、図１５
の表示も正しいものである。

【００６８】キャッシュは、システム・メモリ１５０の
中に設けられ、画像１１１０及び効果からの非画像描画
出力１１３０（例えば、動き追跡効果の場合の動きベク
トル）を記憶することができる。

【００６９】キャッシュの意図は、有向非繰返しグラフ
内の各効果の描画出力（これが画像であるかどうかに拘
らず）を記憶することである。こうすると、或る効果の
有向非繰返しグラフにおける特定の位置が変更された場
合、その位置よりあとの効果を描画し直して新しい出力
を供給する必要がなくなる。代わりに、キャッシュされ
ている出力を再使用できる。更なる利点は、特定の効果
（開かれたビューワーウィンドーに表示されたもの）の
出力をパラメータ変更の前後に記憶することにより、取
消し／やり直し動作を助け動作の速度を早めることであ
る。対応するパラメータ変更も記憶されるので、キャッ
シュメモリ１１００から適切な素材を格納することによ
り、パラメータの変更を簡単に取消したり、やり直した
りすることができる。これは、変更が行われたときに効
果サーバによって書込まれた取消し／やり直しオブジェ
クトの制御の下に行われる。

【００７０】画像は、動きベクトルのような簡単なデー
タ値よりはるかに大きなメモリ空間、恐らく百万倍のメ
モリ空間を占める。したがって、この具体例では、キャ
ッシュメモリが容量の限界に近づいている状態で他の画
像を記憶しようとするときは、最も前にアクセスしたキ
ャッシュ内の画像を削除して、新しく記憶する画像のた
めの空間を作る。ただし、キャッシュ内の他のデータ、
パラメータ値や非画像描画出力などは、画像に比べると
ほんの僅かのメモリ空間しか使わないので、本装置の動
作期間中は削除しない。よって、この情報は、該情報が
動作期間を通じて有効である限り、再使用又は取消し／
やり直し動作に使用できる。

【００７１】実際には、データ項目を洗い流せるかどう
かをプラグインに指定させるようにすることができる。
即ち、画像データ項目は取決めにより洗い流せるものと
設定し、非画像データ項目は洗い流せないものと設定す
ることができる。

【００７２】図１６は、コア・プロセッサ３４０及び効
果サーバ３３０間の非同期／同期コンバータ（プラグイ
ン・インタフェース）１２００の模式図である。コンバ
ータ１２００は、描画マネージャから非同期再描画コマ
ンドを、「行うべき」列、即ち行うべき描画ジョブのリ
ストの形で受取る。１つのジョブが終わると、「終了」
メッセージがコンバータ１２００から描画マネージャに
返送される。コンバータ１２００は、非同期のジョブ要
求を受け、同期要求を適切なソフトウェア・プラグイン
に発する。これは、インタフェース１２００が制御「ス
レッド」（ウィンドーズ用語）をソフトウェア・プラグ
インに回送することを意味し、これが、該ジョブが完了
するまで該スレッドの制御を保持することになる。その
時のみ、ソフトウェア・プラグインが該スレッドをイン
タフェースに返送し、該インタフェースが「終了」メッ
セージをコア側に発して応答する。

【００７３】初期設定の際、コア・プロセッサは、各プ
ラグイン（又はむしろ当該プラグインに関連するメタデ
ータ）に問合せて、該プラグインが同期又は非同期通信
を処理できるかどうかを決定する。ハードウェア・プラ
グイン（例えば、特定の方法で描画するための周辺カー
ド）又は恐らく異なる機械で作動している非同期ソフト
ウェア・プラグインをソフトウェア・プラグインの代わ
りに組込めば、ハードウェア・アクセラレータはこのよ
うな動作に極めてよく適しているので、該プラグインは
コア側（実のところ、非同期的に描画タスクを開始する
描画マネージャ）と非同期インタフェースを介して対話
を行う。したがって、この場合、コンバータ１２００は
迂回される。

【００７４】コンバータは、コア側の一部として又は各
関連プラグインの一部として実施してもよい。よって、
コンバータ１２００を２つのソフトウェアの間に設ける
という反直観的な方法により、将来専用ハードウェアに
改良される効率的なハードウェア・インタフェースが提
供される。

【００７５】

【発明の効果】以上説明したとおり、本発明によれば、
ストレージ及びストリームの両方をプラグインに割当て
られるようにしてプラグイン設計及び動作にかかる制約
を減じることができる。

【図面の簡単な説明】

【図１】デジタルビデオ特殊効果装置の概略図である。

【図２】図１の装置の作動ソフトウェアの編成を示す概
略図である。

【図３】図１の装置の作動ソフトウェアの編成の詳細を
示す模式図である。

【図４】図１の装置における更新された効果パラメータ
の伝播状態を示す模式図である。

【図５】図１の装置における再描画コマンドの伝播状態
を示す模式図である。

【図６】グラフ・エディタ・ウィンドー及びパレット・
ウィンドーを示す概略図である。

【図７】グラフ編集動作の例を示す説明図である。

【図８】複合効果アイコンの作成例を示す説明図であ
る。

【図９】複合効果のファイル構造を示す模式図である。

【図１０】ビューワーウィンドーの概略図である。

【図１１】作動ソフトウェアの初期配置を示す模式図で
ある。

【図１２】以前に提案された効果プラグインの模式図で
ある。

【図１３】新しい形式の効果プラグインの模式図であ
る。

【図１４】図１３の効果プラグインにおける効果サーバ
とプロキシ効果との関係を示す模式図である。

【図１５】システム・キャッシュを示す概略図である。

【図１６】プラグイン・インタフェースを示す概略図で
ある。

Claims (3)

【特許請求の範囲】
1. 【請求項１】 データ処理装置であって、 該装置の全般的な動作を制御するコア・オブジェクト
   と、 該コア・オブジェクトと通信するように配された複数の
   プラグインＣＯＭオブジェクトとを有し、 上記コア・オブジェクトは、作業データを記憶及び／又
   は検索するのに使用するため、ＣＯＭストリーム・イン
   タフェース及びＣＯＭストレージ・インタフェースを上
   記プラグインＣＯＭオブジェクトに与えることを特徴と
   するデータ処理装置。
2. 【請求項２】 上記装置はビデオ特殊効果装置である請
   求項１の装置。
3. 【請求項３】 上記プラグイン・オブジェクトの幾つか
   又はすべてが夫々のビデオ特殊効果機能を定める請求項
   ２の装置。