JP2000092390A - ディジタル・ビデオ信号処理装置及び方法 - Google Patents

Abstract

(57)【要約】 【課題】 １つのビデオ信号を形成する複数の画像に対
して、連続するビデオ信号処理動作が適用されて画像又
はデータの形で対応する処理結果を発生するビデオ信号
処理装置において、描画速度を速くすること。 【解決手段】 キャッシュされたアイテム及びビデオ信
号処理動作と関連する処理結果として保存するためのキ
ャッシュ保存手段と、新たにキャッシュされるべきアイ
テムのためのキャッシュ・スペースを提供するために現
在キャッシュされているアイテムを削除する手段であっ
て、非画像処理結果が画像の形の処理結果よりも長い間
キャッシュの中に留められるように動作する削除手段
と、を設ける。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はディジタル・ビデオ
信号処理装置におけるキャッシングに関する。

【０００２】

【従来の技術】ビデオ特殊効果装置等のビデオ信号処理
装置においては、一つのビデオ・シーケンスの複数の画
像に対してディジタル信号処理が適用される。そのよう
なシステムの一例において、ユーザは、沢山の適用可能
なモジュールから一連の効果モジュールを選択すること
によって、或ビデオ・シーケンスに適用すべき複合特殊
効果を設定することができる。例えば、ユーザによって
設定される一連の（又は「有向非循環グラフ」の）効果
は、下記のことを含む。即ち、 （ｉ） 画像ロード手段 （ｉｉ） 動き追跡手段 （ｉｉｉ）動き追跡及び画像ロードにリンクされた照明
効果 （ｉｖ） 動き追跡及び画像ロードにリンクされた画像
の再配列

【０００３】特殊効果が選択され、全てのパラメータが
定義されると、「描写（rendering）操作が行われなけ
ればならない。描写は、設定された処理操作に従って、
出力画像、出力ビデオ・シーケンス又は或画像内の動き
ベクトル又は位置等の中間データ・タイプを形成する一
連の画像を生成する処理である。例えば、照明効果は、
ビデオ・シーケンスに適用されるコンピュータ発生スポ
ットライトに対するソース及び行く先位置をユーザが選
ぶことを含むであろう。

【０００４】これらの位置が定義されると、次の作業
は、各出力画像の各ピクセルの色及び輝度を決定するた
めに定義された照明効果を適用することによって、出力
シーケンスにおける各画像を描写することである。

【０００５】

【発明が解決しようとする課題】現行の処理システムを
使えば、描写は非常に時間を費やし、典型的な場合、或
ビデオ・シーケンスの各画像を描写するために（そのシ
ーケンスの長さによるが）数秒から多時間の時間がかか
る。ユーザが経験する遅延を軽減するためには、処理パ
ラメータ及びその複合効果における幾つか又は全部の処
理動作に対する（描写された画像または動き追跡効果の
場合の動きベクトル等の他の結果データ）結果がキャッ
シュ（隠し保存）される。本発明は、描画に要する時間
を短縮し、一度描画したもので再利用できるものは新た
に描画することのないように保存し、かつ、保存のため
のメモリを有効に活用することを課題とする。

【０００６】

【課題を解決するための手段】本発明は、上記課題を解
決するために下記の手段を備えたビデオ信号処理装置を
提供する。即ち、画像又はデータの形で対応する処理結
果を発生するために１つのビデオ信号からなる複数の画
像に相次ぐビデオ信号処理動作が適用されるビデオ信号
処理装置であって、キャッシュされたアイテム及びビデ
オ信号処理動作と関連する処理結果として保存するため
のキャッシュ保存手段と、新たにキャッシュされるべき
アイテムのためのキャッシュ・スペースを提供するため
に現在キャッシュされているアイテムを削除する手段で
あって、非画像処理結果が画像の形の処理結果よりも長
い間キャッシュの中に留められるように動作する削除手
段と、を備えるビデオ信号処理装置を提供する。本発明
は、また上記の手段によって表されるステップを含むビ
デオ信号処理方法も提供する。

【０００７】本発明は、上記に参照した３クラスのデー
タのキャッシュ・スペースを認識する。即ち、パラメー
タ・データ、イメージ（画像）データ、及び非画像結果
データ（例えば、動きベクトル）である。画像データ
は、一般に、他の２つのクラスのデータよりも広大なキ
ャッシュ・スペースを占領する。しかしながら、非画像
結果データは描写のためになおも長時間をとり、キャッ
シュの中に留めておく価値がある。

【０００８】それ故、本発明においては、非画像結果デ
ータは、画像結果データに優先して留められる。従っ
て、この非画像結果データは長期にわたりキャッシュか
ら適用でき、或画像をキャッシュするのに要するスペー
スに比べてほんの少量のキャッシュ保存スペースを犠牲
にするだけである。現実に、少なくとも装置の特定の動
作セッションの間、非画像結果データがキャッシュから
決してフラッシュされないことが望ましい。

【０００９】結果をキャッシュする主な理由は、有向非
循環グラフにおける或特定の位置での効果が変えられる
と、例えばパラメータが変えられると、その変えられた
効果が再描写されなければならない時、有向非循環グラ
フにおける先行効果がキャッシュから直接再使用できる
からである。

【００１０】これによって、例えば、もしユーザが新し
いセットのパラメータを試みたがその結果が好ましくな
く最新の変化がなされる前にその装置の前回の作業状態
に戻したければ、その操作を非常に素早く「不履行」に
することもできる。処理パラメータを再入力し、装置が
その結果の画像を再描画する代わりにそれらがキャッシ
ュから即座に検索されるようにできる。

【００１１】キャッシュは有限の容量を持つので、キャ
ッシュされるニュー・アイテム（新規事項）のために使
える余地を作るためには、時々このキャッシュはクリア
されなければならない。一般に、キャッシュ中の最小の
最近使われたアイテムが捨てられる。

【００１２】

【発明の実施の形態】ここで、添付図面を参照して、例
示のみとして、本発明の実施の形態を説明する。連続す
るビデオ画像を含む、或ディジタル・ビデオ信号が入力
インターフェース１００で受信されディスク・アレイ装
置１１０に保存される。このディスク・アレイ装置１１
０はこの装置によって生成されたどんな手作り画像も保
存し、これらは、出力インターフェース１２０を介して
出力へ供給できる。

【００１３】中央処理ユニット１３０は、ユーザ・コマ
ンドに応じてこのディスク・アレイ装置に保存されたデ
ータにアクセスして、種々のビデオ特殊効果を実行す
る。ＣＰＵ１３０は、マウスやキーボード等のユーザ入
力装置１４０からの入力を受け取り、メモリ１５０にワ
ーキング・データ及びプログラム・コードを保存し、デ
ィスプレイ・ドライバー（表示装置駆動装置）１７０を
介して表示スクリーン１６０上に出力用データを発生す
る。

【００１４】この装置は、例えば Microsoft Windows N
T （商標名）オペレーティング・システムの下で適正な
ソフトで動く汎用コンピュータ（例えば、ＰＣ）として
実装できる。本実施形態においては、ディスク・アレイ
はウルトラＳＣＳＩデータ・リンクを介してＣＰＵ１３
０に接続される。

【００１５】図２は、図１の装置のための動作ソフトウ
エアの（非常に一般的レベルで）組織化を図解したもの
である。このソフトウエアは、２つのカテゴリーのプロ
グラム・コードとして配列されている。即ち、図２の左
手に示されたコア・フレームワークと、図２の右手に示
された種々のプラグインである。このソフトウエアが最
初にロードされると、コア・フレームワークが何時も存
在し、異なった特殊効果処理の間で共有された装置の動
作部分を制御する。

【００１６】これと対照的に、プラグインは、（照明効
果、動き追跡効果等々の）個別の特殊効果と関係し必要
な時だけロードされる。これは非常に効率の良い装置で
ある。何故ならば、ユーザによって現在要求された効果
モジュールに関係するプラグインだけがメモリにロード
されればよいからである。これによって、可能な特殊効
果の全てに対してプログラム・コードがロードされなけ
ればならないシステムと比べてメモリの節約になる。こ
れによって、装置の初期化が速くなり、システムが最初
にスタートする時にメモリに全てのプログラム・コード
をロードする必要性を避け、グラフ・エディタにおいて
アイコンが最初に選択された時にコード・ローディング
を通した如何なる遅延も減らすことができる。

【００１７】更に又、この装置（配列）は、供給されイ
ンストールされる装置のサブセット（特に、動作ソフト
ウエア）が削減でき、グラフ・エディタ及びコア処理だ
けを含みプラグインを持たないようにできる。このシス
テムはまた、第三者またはユーザに対して、プラグイン
とコア・フレームワークの間の規定のインターフェース
・プロトコルに留まる限り、彼ら自身のプラグインを作
ることを許す。従って、ユーザは、比較的小さなプラグ
イン・プログラムを書くことにより注文効果を非常に簡
単に作ることができる。

【００１８】このコア・フレームワークとプラグイン
は、いわゆる「オブジェクト・リンキング及び埋込」
（ＯＬＥ）プロトコルを使ってお互いに通信する。これ
については、「Understanding ActiveX and OLE 」、Da
vid 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 (4)

【特許請求の範囲】
1. 【請求項１】 １つのビデオ信号を形成する複数の画像
   に対して、連続するビデオ信号処理動作が適用されて画
   像又はデータの形で対応する処理結果を発生するビデオ
   信号処理装置であって、 キャッシュされたアイテム及びビデオ信号処理動作と関
   連する処理結果として、保存するためのキャッシュ保存
   手段と、 新たにキャッシュされるべきアイテムのためのキャッシ
   ュ・スペースを提供するために現在キャッシュされてい
   るアイテムを削除する手段であって、非画像処理結果が
   画像の形の処理結果よりも長い間キャッシュの中に留め
   られるように動作する削除手段と、を備えたビデオ信号
   処理装置。
2. 【請求項２】請求項１に記載の装置において、上記削除
   手段がキャッシュから非画像処理結果を削除しないよう
   に動作するようにしたビデオ信号処理装置。
3. 【請求項３】 請求項１又は２に記載の装置において、
   キャッシュから処理パラメータを削除しないように動作
   させるようにしたビデオ信号処理装置。
4. 【請求項４】 １つのビデオ信号を形成する複数の画像
   に対して、連続するビデオ信号処理動作を適用して画像
   又はデータの形で対応する処理結果を発生するビデオ信
   号処理方法であって、 キャッシュされたアイテム及びビデオ信号処理動作と関
   連する処理結果として保存するステップと、 新たにキャッシュされるべきアイテムのためのキャッシ
   ュ・スペースを提供するために現在キャッシュされてい
   るアイテムを削除することにより、非画像処理結果が画
   像の形の処理結果よりも長い間キャッシュの中に留めら
   れるようにするステップと、を含むビデオ信号処理方
   法。