JP2000149058A

JP2000149058A - ビデオ特殊効果装置

Info

Publication number: JP2000149058A
Application number: JP21558799A
Authority: JP
Inventors: Antony James Gould; ジェームズグールド，アントニー; Richard Daniel Foster; ダニエルフォスタ，リチャード
Original assignee: Sony United Kingdom Ltd
Current assignee: Sony Europe BV United Kingdom Branch
Priority date: 1998-07-31
Filing date: 1999-07-29
Publication date: 2000-05-30
Anticipated expiration: 2019-07-29
Also published as: GB2340358A; GB2340358B; GB9816762D0; JP4299924B2; US6469723B1

Abstract

(57)【要約】【課題】連結した効果をユーザが作成したとき、それ
らを後日使用するため１つのグループとして記憶し検索
できるようにする。【解決手段】本発明のビデオ特殊効果装置は、複数の
ビデオ特殊効果処理モジュールと、表示スクリーンと、
前記モジュールを表すアイコンを表示する同スクリーン
のパレット領域と、同スクリーンのグラフ領域と、アイ
コンをパレット領域からグラフ領域に移しアイコンを連
結して複合ビデオ特殊効果処理を表示するユーザ操作手
段と、グラフ領域の連結されたアイコングループをパレ
ット領域に移すユーザ操作手段とを具え、該グループは
パレット領域で１つの複合処理アイコンとして表示され
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ビデオ特殊効果装
置に関するものである。

【０００２】

【従来の技術】ビデオ特殊効果装置においては、ユーザ
は一般に、多数の使用可能なモジュールの中から一連の
効果モジュールを選択することにより、ビデオシーケン
スに適用しようとする複合特殊効果を設定することがで
きる。例えば、ユーザが設定する一連（「有向非繰返し
グラフ（directed acyclic graph）」）の効果には、（ｉ）イメージローダ（画像の格納）（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) 関心のある出力ビデオシーケン
スの残りの画像

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００７０】

【発明の効果】以上説明したとおり、本発明によれば、
連結した効果をユーザが作成したとき、それらを後日使
用するため１つのグループとして記憶し検索できる便利
な方法を得ることができる。

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【符号の説明】

１６０‥‥表示スクリーン、６００‥‥パレット領域、
６１０‥‥グラフ領域、６２０‥‥モジュール・スクリ
ーン・アイコン、１４０‥‥ユーザ操作可能手段、８０
０‥‥連結されたスクリーン・アイコンのグループ、８
１０‥‥複合処理スクリーン・アイコン

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｇ０６Ｆ 15/74 ３３０Ｄ (72)発明者フォスタ，リチャードダニエルイギリス国ハンプシャー，フォーディングブリッジ，マーティン，マーティンクロスコテージ

Claims

【特許請求の範囲】

【請求項１】複数のビデオ特殊効果処理モジュール
と、表示スクリーンと、上記ビデオ特殊効果処理モジュールを表すモジュール・
スクリーン・アイコンを表示する、上記表示スクリーン
上のパレット領域と、上記表示スクリーン上のグラフ領域と、上記スクリーン・アイコンを上記パレット領域から上記
グラフ領域に移動させ、該スクリーン・アイコンを互い
に図形的に連結させて、複合ビデオ特殊効果処理の表示
を作成するためのユーザ操作可能手段と、上記グラフ領域に表示された２以上の連結されたスクリ
ーン・アイコンのグループを選択し、そのグループを上
記パレット領域に転送するためのユーザ操作可能手段と
を具え、上記グループは、上記パレット領域では、１つの複合処
理スクリーン・アイコンとして表示されることを特徴と
するビデオ特殊効果装置。
【請求項２】上記パレット領域から上記グラフ領域に
転送された複合処理スクリーン・アイコンは、上記グラ
フ領域において単一のアイコンとして表示される請求項
１の装置。
【請求項３】上記パレット領域から上記グラフ領域に
転送された複合処理スクリーン・アイコンは、上記グラ
フ領域においてアイコンのグループとして表示される請
求項１の装置。
【請求項４】複合処理スクリーンの表示を上記グラフ
領域におけるアイコンのグループと該グラフ領域におけ
る単一のアイコンとのどちらかに変えるためのユーザ操
作可能制御手段を有する請求項２又は３の装置。