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
【発明の属する技術分野】
本発明はディジタル・ビデオ信号処理装置におけるキャッシングに関する。
【0002】
【従来の技術】
ビデオ特殊効果装置等のビデオ信号処理装置においては、一つのビデオ・シーケンスの複数の画像に対してディジタル信号処理が適用される。
そのようなシステムの一例において、ユーザは、沢山の適用可能なモジュールから一連の効果モジュールを選択することによって、或ビデオ・シーケンスに適用すべき複合特殊効果を設定することができる。例えば、ユーザによって設定される一連の(又は「有向非循環グラフ」の)効果は、下記のことを含む。即ち、
(i) 画像ロード手段
(ii) 動き追跡手段
(iii)動き追跡及び画像ロードにリンクされた照明効果
(iv) 動き追跡及び画像ロードにリンクされた画像の再配列
【0003】
特殊効果が選択され、全てのパラメータが定義されると、「描写(rendering )操作が行われなければならない。描写は、設定された処理操作に従って、出力画像、出力ビデオ・シーケンス又は或画像内の動きベクトル又は位置等の中間データ・タイプを形成する一連の画像を生成する処理である。例えば、照明効果は、ビデオ・シーケンスに適用されるコンピュータ発生スポットライトに対するソース及び行く先位置をユーザが選ぶことを含むであろう。
【0004】
これらの位置が定義されると、次の作業は、各出力画像の各ピクセルの色及び輝度を決定するために定義された照明効果を適用することによって、出力シーケンスにおける各画像を描写することである。
【0005】
【発明が解決しようとする課題】
現行の処理システムを使えば、描写は非常に時間を費やし、典型的な場合、或ビデオ・シーケンスの各画像を描写するために(そのシーケンスの長さによるが)数秒から多時間の時間がかかる。ユーザが経験する遅延を軽減するためには、処理パラメータ及びその複合効果における幾つか又は全部の処理動作に対する(描写された画像または動き追跡効果の場合の動きベクトル等の他の結果データ)結果がキャッシュ(隠し保存)される。
本発明は、描画に要する時間を短縮し、一度描画したもので再利用できるものは新たに描画することのないように保存し、かつ、保存のためのメモリを有効に活用することを課題とする。
【0006】
【課題を解決するための手段】
本発明は、上記課題を解決するために下記の手段を備えたビデオ信号処理装置を提供する。即ち、画像又はデータの形で対応する処理結果を発生するために1つのビデオ信号からなる複数の画像に相次ぐビデオ信号処理動作が適用されるビデオ信号処理装置であって、キャッシュされたアイテム及びビデオ信号処理動作と関連する処理結果として保存するためのキャッシュ保存手段と、新たにキャッシュされるべきアイテムのためのキャッシュ・スペースを提供するために現在キャッシュされているアイテムを削除する手段であって、動きベクトルデータが画像データよりも長い間キャッシュの中に留められるように動作する削除手段と、を備えるビデオ信号処理装置を提供する。本発明は、また上記の手段によって表されるステップを含むビデオ信号処理方法も提供する。
【0007】
本発明は、上記に参照した3クラスのデータのキャッシュ・スペースを認識する。即ち、パラメータ・データ、イメージ(画像)データ、及び動きベクトルである。画像データは、一般に、他の2つのクラスのデータよりも広大なキャッシュ・スペースを占領する。しかしながら、動きベクトルデータは描写のためになおも長時間をとり、キャッシュの中に留めておく価値がある。
【0008】
それ故、本発明においては、動きベクトルデータは、画像データに優先して留められる。従って、この動きベクトルデータは長期にわたりキャッシュから適用でき、或画像をキャッシュするのに要するスペースに比べてほんの少量のキャッシュ保存スペースを犠牲にするだけである。現実に、少なくとも装置の特定の動作セッションの間、動きベクトルデータがキャッシュから決してフラッシュされないことが望ましい。
【0009】
結果をキャッシュする主な理由は、有向非循環グラフにおける或特定の位置での効果が変えられると、例えばパラメータが変えられると、その変えられた効果が再描写されなければならない時、有向非循環グラフにおける先行効果がキャッシュから直接再使用できるからである。
【0010】
これによって、例えば、もしユーザが新しいセットのパラメータを試みたがその結果が好ましくなく最新の変化がなされる前にその装置の前回の作業状態に戻したければ、その操作を非常に素早く「不履行」にすることもできる。処理パラメータを再入力し、装置がその結果の画像を再描画する代わりにそれらがキャッシュから即座に検索されるようにできる。
【0011】
キャッシュは有限の容量を持つので、キャッシュされるニュー・アイテム(新規事項)のために使える余地を作るためには、時々このキャッシュはクリアされなければならない。一般に、キャッシュ中の最小の最近使われたアイテムが捨てられる。
【0012】
【発明の実施の形態】
ここで、添付図面を参照して、例示のみとして、本発明の実施の形態を説明する。
連続するビデオ画像を含む、或ディジタル・ビデオ信号が入力インターフェース100で受信されディスク・アレイ装置110に保存される。このディスク・アレイ装置110はこの装置によって生成されたどんな手作り画像も保存し、これらは、出力インターフェース120を介して出力へ供給できる。
【0013】
中央処理ユニット130は、ユーザ・コマンドに応じてこのディスク・アレイ装置に保存されたデータにアクセスして、種々のビデオ特殊効果を実行する。CPU130は、マウスやキーボード等のユーザ入力装置140からの入力を受け取り、メモリ150にワーキング・データ及びプログラム・コードを保存し、ディスプレイ・ドライバー(表示装置駆動装置)170を介して表示スクリーン160上に出力用データを発生する。
【0014】
この装置は、例えば Microsoft Windows NT (商標名)オペレーティング・システムの下で適正なソフトで動く汎用コンピュータ(例えば、PC)として実装できる。本実施形態においては、ディスク・アレイはウルトラSCSIデータ・リンクを介してCPU130に接続される。
【0015】
図2は、図1の装置のための動作ソフトウエアの(非常に一般的レベルで)組織化を図解したものである。このソフトウエアは、2つのカテゴリーのプログラム・コードとして配列されている。即ち、図2の左手に示されたコア・フレームワークと、図2の右手に示された種々のプラグインである。このソフトウエアが最初にロードされると、コア・フレームワークが何時も存在し、異なった特殊効果処理の間で共有された装置の動作部分を制御する。
【0016】
これと対照的に、プラグインは、(照明効果、動き追跡効果等々の)個別の特殊効果と関係し必要な時だけロードされる。
これは非常に効率の良い装置である。何故ならば、ユーザによって現在要求された効果モジュールに関係するプラグインだけがメモリにロードされればよいからである。これによって、可能な特殊効果の全てに対してプログラム・コードがロードされなければならないシステムと比べてメモリの節約になる。これによって、装置の初期化が速くなり、システムが最初にスタートする時にメモリに全てのプログラム・コードをロードする必要性を避け、グラフ・エディタにおいてアイコンが最初に選択された時にコード・ローディングを通した如何なる遅延も減らすことができる。
【0017】
更に又、この装置(配列)は、供給されインストールされる装置のサブセット(特に、動作ソフトウエア)が削減でき、グラフ・エディタ及びコア処理だけを含みプラグインを持たないようにできる。このシステムはまた、第三者またはユーザに対して、プラグインとコア・フレームワークの間の規定のインターフェース・プロトコルに留まる限り、彼ら自身のプラグインを作ることを許す。従って、ユーザは、比較的小さなプラグイン・プログラムを書くことにより注文効果を非常に簡単に作ることができる。
【0018】
このコア・フレームワークとプラグインは、いわゆる「オブジェクト・リンキング及び埋込」(OLE)プロトコルを使ってお互いに通信する。これについては、「Understanding ActiveX and OLE 」、David Chappell,Microsoft Press, 1996に説明されている。
【0019】
OLEシステムにおいては、ソフトウエア設計者は、コンピュータプログラムの異なったセクションを「COM(Component Object Model)オブジェクト」として実現できる。各COMオブジェクトは、1以上のCOMインターフェースをサポートし、各々沢山の「メソッド」を含む。或メソッドは関数または詳細動作を遂行する手順である。COMのメソッドはそのCOMオブジェクトを使うソフトウエアによって呼び出すことができる。このシステムは制限されているから、COMオブジェクトを使うソフトウエアの他の部分は定義されたインターフェースを介してのみそうすることができる。従って、定義されたCOMインターフェースを介する以外にそのオブジェクト内部のプログラム・コードまたはデータに直接アクセスすることはできない。
【0020】
そこで、本システムにおいては、コア・フレームワークはこれらのCOMインターフェースを介してプラグインと通信する。(事実、コア・フレームワークはCOMインターフェースを提供することのできる沢山の相互通信オブジェクトを含む。)
【0021】
図3は、オペレーティング・ソフトウエアの組織を図2に示したよりもずっと詳細に図示したものである。図3においては、線図は4つの四角に分けられている。左上の四角は、いわゆるビュー・ウインドウ310を示し、右上の四角は効果ユーザ・インターフェース(UI)320を示し、右下の四角は、関連するパラメータデータ(PD)を有する効果サーバー330を示し、左下の四角は、オブジェクト・マネージャー350、描画マネージャ352、変化マネージャ358と一緒にグラフを含むコア・プロセッサ340を示す。
【0022】
左下の四角と右下の四角の間のインターフェースの所に、Window NT レジストリーの部分を形成するメタ・データベース354があり、効果アイコンを含むパレット356およびデフォルト・パラメータ値がある。このメタ・データベース354は、図11を参照して、パレットは図6〜9を参照して更に詳しく説明する。
【0023】
コア・プロセッサ340内には、リンクされた一連の個別特殊効果を有するグラフ、実際には「有向非循環グラフ」がある。各効果は、グラフの中に、それが使えるようになるとすぐにその効果出力を保存するための関連したキャッシュ(C)を有するプロクシー効果(PE)として表される。それによって、例えばもしそのチェイン(連鎖)において高い方の効果が変わると、その効果の連鎖の中の効果からデータを再使用できるようにする。各プロクシー効果は夫々の効果サーバー330と関連付けられている。
【0024】
オブジェクト・マネージャー350は、そのシステム内のアクティブ・オブジェクトの寿命とメモリ・マネージメントを制御する責任がある。描写マネージャー352は描画作業の開始、進行、優先化、及び停止を制御する。変化マネージャー358は不履行/再履行情報および変化をシステムの種々の部分へ通知することを制御する。
【0025】
図3の基本的な部分は、左手の2つの四角(左上及び左下)がコア・フレームワークの特色に関係し、如何なる特定の効果にも特定されない。これらのオブジェクトは、どの特定の特殊効果をユーザが実施しようと望むかに関わらずメモリーにロードされる。右手の2つの四角(右上及び右下)はプラグインに関係する。各プラグインは、そのプラグインによって遂行される効果に関連する処理を実行するサーバー330と、その効果に関係するユーザ・インターフェース・コントロール(実際には、ビューア・ウインドウ310の表示用)を提供するユーザ・インターフェース320を持つ。
【0026】
図3においては同様な上から下への分割がある。上方の2つの四角(左上及び右上)は特殊効果に関連したユーザ・インターフェース・コントロールに関係し、下方の2つの四角(左下及び右下)はそれらの効果を実施するために遂行される処理または組織に関する。
【0027】
ビューア・ウインドウは、ユーザに、その装置によって実行するために作り上げた一連の効果における或特定の効果の出力及びそれに対するパラメータを見る機会を与える。それゆえ、ユーザによってビューア・ウインドウが開かれると、或効果の出力が発生されるか、もし適用できれば、キャッシュ・ストアから検索されなければならない。
【0028】
複数のCOMオブジェクトを採用したこのタイプのシステムにおいては、各オブジェクトがその仕事又は結果データを別のデータファイルに保存する(ような)ことは一般には望ましくないと考えられる。事実、そのような装置(配列)はOLEシステムの設定につながる多くの理由付けに反している。その代わりに、このタイプのシステムにおけるデータは、単一ファイル又は「複合ドキュメント」における全てのオブジェクトによって保存されるが、その複合ドキュメント内部の順序付けされた構造を使って行われる。
【0029】
基本的には、複合ドキュメントの内側では、ファイル及びディレクトリ構造に類似した構造が準備される。ディレクトリに等しいものは、いわゆる「保存」であり、ファイルに類似のものは、いわゆる「ストリーム」である。各複合ドキュメントはルート保存を含み、その下にお馴染みの保存とストリームのトリー構造がある。このCOMストリーム・インターフェースはCOM保存インターフェースよりももっと簡単であるが、勿論この保存インターフェースはもっと柔軟性がある。
【0030】
一般に、各COMオブジェクトは、そのワーキング・データを保存するそれ自身の保存装置又はそれ自身のストリームに割り当てることができる。しかしながら、コア340が沢山のプラグインの動作を調整する本ビデオ特殊効果処理装置等の階級システムにおいては、前のシステムに使われている装置(配列)は各効果プラグインにストリームを割り当てる。
【0031】
それに比べて、本実施形態においては、保存装置又はストリームのどちらかをプラグインに単純に割り当てるとプラグイン・オブジェクトの設計及び動作に制約が多すぎることが認識される。それに代えて、コアとプラグインの間のインターフェース定義において、各プラグインは、(プラグイン設計者に望ましければ、そのワーキング・データを直接に保存できるように)ストリームと(もし望ましければ、そのワーキング・データをそれ自身の「ディレクトリ」配列のストリーム及び保存装置に保存するように)保存装置との間で選択できる。この選択は、プラグイン設計者がプラグイン・プログラム・コードを作ることによって前もって作られる。
【0032】
以降の説明において、種々のオブジェクトの間の通信プロトコルは図4及び5と関連して説明する。コア・プログラム340のグラフ・エディタ部分が、複合効果を形成するために個々の効果の連鎖を設立するのに使われる方法は、図6〜9と関係して説明する。ビューア・ウインドウ及びそれらの効果UI320(複数個ある)との相互作用は図10を参照して説明する。
【0033】
図4は、図3の装置における更新された効果パラメータの伝搬を図示している。
この状況の一例は、ユーザが照明特殊効果を設定するということであり、そこでは画像に光源の効果が加わる。光源は、その画像に関するユーザ定義可能なソース及び目的位置を有する。もし、ユーザがこれらの位置の1つを変えたいならば、現在描写されている出力のどれでもその効果から無効(invalidate)にし、図3の異なった四角に示された種々のオブジェクトの間で変化を伝搬させる必要がある。この処理は図4に示されている。
【0034】
図4を参照すると、ユーザはビューウインドウ310(図10参照)を介して変化されたパラメータを実際に入力する。このビューア・ウインドウは特定の効果UI320と関連付けられており、それが個々の効果に関係するプラグインの部分になる。(事実、1以上の効果に対して単1ビュー・ウインドウを関連させることができ、全ての効果がビューア・ウインドウを任意の特定の時間に開く必要はなく、この検討のために図3の簡単化された装置(配列)が維持される。
このプラグインはコアに対して「エディット開始(about to edit )」を発行する。
【0035】
変更を行った後、プラグインはコアに対して「変化有り(change occurred )」通知を発行する。これは、一連の動作を含むかそれらを開始するか又はその両方を行う。最初のステップ401として、ビューア・ウインドウは効果UI320に更新されたパラメータを通信する。この効果UI320は対応する効果サーバー330に「セット」命令を発行し、効果サーバー330内部のパラメータ保存装置に改訂された値をセットする。これは図4のステップ402である。
【0036】
ステップ403において、効果サーバー330はコア340に「undo/redo 」オブジェクトを書き、変化前と後のパラメータの(効果サーバーにおける)レコードを指すハンドル又はポインターの詳細を提供する。このundo/redo オブジェクトの受領に応答して、ステップ404でコアは全てのビューア・ウインドウに対してパラメータが変更されたこと及び或キャッシュされたデータ出力が無効にできることを伝える。この通知は、パラメータ変化が起こったビューア・ウインドウに特有なものではない。
【0037】
ステップ405では、各ビューア・ウインドウは、その処理パラメータの更新を要求している対応する効果UI320にメッセージを発行する。ステップ406で、その効果UI320は、その新しいパラメータを得るために対応する効果サーバーに対して get コマンド(命令)を発行し、ステップ407で効果UI320にその新しいパラメータが返される。この効果UIはステップ408でビューアウインドウに表示のためその変化を伝搬する。
【0038】
一般に、処理パラメータが変化した時、1つ以上の効果の出力を再描画することを必要とする結果になる。図5は、再描画コマンドが装置を通って伝搬される方法を図解しており、図4の処理から続く。
ステップ502では、ビューア・ウインドウは再描画マネージャー(管理部)に再描画コマンドを発行する。この描画管理部(マネージャー)は対応する効果サーバー330に再描画コマンドを発行する。効果サーバーが画像の再描写を終わった時、コア340に「終了」メッセージを発行する。このコアはステップ505でビューア・ウインドウにこれを通信する。そしてステップ506及び507でビューア・ウインドウは効果UI320と相互作用して再描画された効果出力を表示する。
【0039】
数個のビューア・ウインドウが開かれており、数個のフレームが関心のある領域(これは、テストの目的で、全てのビデオ・クリップのサブセットとしてユーザによって定義できる)にある時、複数の画像が、処理リソース(資源)を割り当てるための下記の優先順位に従って、複数の同時作業として描かれる。
(i)ユーザによって現在ビュー用に表示されている画像(1つ又は複数);
(ii)関心のある出力順序の最初と最後の画像;
(iii)関心のある出力順序の残りの画像
【0040】
詳細の他のレベルとして、描画マネージャ−が効果サーバーに再描画コマンドを発行する前に、この描画マネージャーは「描画準備(prepare to render )」メッセージを発行してその順序(シーケンス)の中のどの画像が描画されるべきなのかを詳細指定する。
【0041】
この効果サーバーは、その「依存性」、即ち描画マネージャーによる要求が実行できる前には必須であるそれらの描画された画像の通知に関して応答する。
これらは、もう一つの効果(例えば、有向非循環グラフにおけるすぐ前の効果)によって描かれた画像であるかもしれないし、その効果自体によって描かれた画像かもしれない。この後の場合は動き追跡の例で起こり得るが、そこでは、画像5を描画するために、動き追跡は画像4に対するそれ自身の描写された出力を必要とする。
【0042】
効果サーバーから戻って受信されたメッセージに応答して、この描画マネージャーはそれらの画像を要求している「描画準備」メッセージを送り、依存トリーが終わるまでそうし続ける。
各段階において、この効果プロクシーは、要求された画像又は描画された出力がキャッシュされたか否かをチェックし、描画マネージャ−に通知する。
【0043】
そこで、例えば、もし描画準備メッセージが画像5を詳細指定する動き追跡部に送られると、それが画像4に対する描画された出力を要求することに応答するかもしれない。描画マネージャーは、画像4に対する動き追跡部にメッセージを描く準備を送る。また、この動き追跡部はそれが画像3等を要求することを示すために応答する。この方法で、要求される画像(画像5)が描かれる前に必要な描画作業のリストが作り上げられる。キャッシュに保持された描画された出力は描画マネージャーの作業リストには含まれていない。
【0044】
或効果が先行する効果の描画された出力を要求するところでは同じことが起こり、そのようにして一連の効果を下方にたどる。
この処理の終わりに、描画マネージャ−が、その依存する画像が全て描写されるまで現在要求されている画像が描かれないように逆の順序で行われる必要な作業の全てをセットする。
【0045】
最適化として、この描画マネージャーはグラフから各効果に対する入力が何であるかを検出できる。それゆえ、この効果サーバーは、単純に「この効果に対する入力の全てが要求されている」というために、予め定められたコード(例えば、null応答)を送ることができる。
【0046】
更に他の拡張として、各効果サーバーが描画マネージャーに、その出力が隣接画像の間で同じであるか否かを通知する目的で同じプロトコルが使える。これの簡単な例は(固定)パラメーター・プラグインであり、出力は不変(invariant)である。更に他の例は、出力が既に準備されていてキャッシュされているので、連続する出力が同一であるか否かについて直接の検出ができるという任意の他の効果である。
【0047】
そのような通知に応答して、この描画マネージャーは、後ほど有向非循環グラフにある効果サーバー上に情報を送る。そこで、その効果サーバーは、(もし適正であれば)或範囲の画像の中の1つだけを描画し、その入力が同じに留まっていれば他の画像に対してその出力を繰り返すことができる。
【0048】
図6はグラフ編集ウインドウ600及びパレット・ウインドウ610を図示する。これらは、コア340の制御の下に表示スクリーン160上に表示される。
パレット・ウインドウ600は、沢山のアイコン620を含み、各々がマップされ、その効果のためにそのシステム上にプラグインが存在するところの異なった可能な効果を表している。マウス・コントロールを使えば、ユーザはこれらのアイコンをスクロール可能なグラフ・ウインドウ610にドラッグできる。これらのアイコンはユーザによってグラフ・ウインドウの中に相互に関連して配列され論理リンク630とリンクできる。これについては、ウインドウ中にグラフ状の線で示してある。
【0049】
リンク630は、或効果の出力を後続効果の入力へ送ることを表しており、(この実施形態において)グラフの底部からそのグラフ・ウインドウの頂部に向かう方向を常に持つ。それゆえ、図6に示された例では、その出力を照明効果650に送る画像ローダー・アイコン640を持つことを表している。
ユーザがグラフ・ウインドウの中にグラフィカル・リンクを設定すると、コア340は論理リンクを設定して、描画された出力が1効果プラグインからもう1つへ送られる方法を決定する。
【0050】
図7を参照して、グラフィカル・リンクが作られる方法を説明する。この論理リンクは、図9を参照して説明する。
図7において、ユーザは(例えばマウス・クリックを使って)照明効果を選択し、今、アイコン650からマウス・ポインター730に向けて方向付けされた可動グラフィカル・ライン720を持つ。
マウス・ポインターが混合効果アイコン700に近ずくにつれて、その混合アイコンは拡大し、または拡大された710で囲まれ、境界740の底部に2つの入力ポートを示す。
【0051】
マウス・ポインターが入力ポートの1つに近づくと、グラフィカル・ライン720がその入力ポイント上にポンと動き、マウス・クリックすると定位置に固定できる。これによって、効果650と効果700の間の論理的及びグラフィカル接続を設立する。
こうした論理的及びグラフィカルな接続が設立されると、ユーザはそのグラフ・ウインドウの効果アイコンのリンクされたグループ800をボックス化できる。
【0052】
ここで、ボックス化とは、コンピュータ・マウスを使って標準の方法でそのグループの周りにボックスを描くことを意味する。(これが実施される1つの方法は、そのボックスの左上隅でクリックし保持することであり、マウスを右下隅にドラッグし、マウス・ボタンを解放する。これは複数のスクリーン・オブジェクトを選択する標準の方法である)。
【0053】
ユーザは、そのリンクされたグループの効果をパレット領域にドラッグすることができる。これは、その入力からグループに形成された1セットの入力を有し、出力からそのグループに形成された1セットの出力を有する新しい複合アイコン810を作る。論理用語で言えば、効果アイコン810が或特定のプラグインにマップされる代わりに、特定の方法で相互接続された1つのリンクされたグループのプラグインにマップされる。
【0054】
複合効果アイコン810は、ユーザによってグラフを設計する際に使われるパレットの部分を形成する。その後、もしユーザが複合アイコン810を使うことを望むならば、それを単純にグラフ・ウインドウ上の場所にドラッグする。好ましくは、この効果アイコン810はグラフ・ウインドウ上では単一アイコンとして留まるが、他の実施においては、それは元のグループ800へと拡張できる。
【0055】
さらに他の変形として、単一アイコンとしてその圧縮形で表示することができるが、元のグループのアイコン800を表示するためユーザが拡張ボタンをクリックできるように「拡張」ボタンを使って表示される。少なくとも、アイコン810によって提供される複合効果は元のグループ800のコピーである。
【0056】
図9はこのプロセスの下位にあるデータ保存部を図解したものである。図9において、アイコン850はパレット領域600のパレット・アイコン620からグラフ・エディタ領域610にドラッグされている。
【0057】
パレット領域600と関連して、図3に示されたパレット356に保存されるものに、ルート860及びそのルートから依存する個別データ項目870を有するトリー(樹枝構造)として配列されたデータ構造がある。効果875等の複合効果の場合を除いて、各データ・アイテム870は1効果アイコン620を表す。
ここでは、その効果を形成する効果アイコン(3a、3b)は、そのデータ・アイテム875から依存するサブ・ストラクチャで配列されている。
【0058】
グラフ・エディタ領域に効果を格納するために、類似のデータ構造が存在する。
ここでは、ルート880はそれに依存する1つの効果885を持つものとして示されている。もし、沢山の効果がグラフ・エディタ領域に一緒にグループ化されパレットにドラッグされれば、それらはストラクチャー875に類似した更に他の複合効果ストラクチャーを形成する。
【0059】
図10は、ビューア・ウインドウを図示したものである。このビューア・ウインドウは画像表示領域900、種々のプロパティー・ページ910、効果コントロール920(ここでは、照明効果の例における位置指定+印として示してある。)、及び「ボタン・バー」930を含む。
ビューア・ウインドウの基本レイアウトは、コア・フレームワークによって設定され、効果から効果への標準である。しかしながら、プロパティ・ページ910を使って調整できる特定のアイテムは、或特定の効果に対応する効果UI320によって設定される。この効果UIはコントロール920に対する表示の詳細も提供する。
【0060】
示された例においては、+印920は照明効果におけるライトのソース位置又はターゲット位置を決定する。ユーザはコンピュータ・マウスを使ってこの+印をドラッグすることができる。+印をドラッグすると、そのコントロールに関連するパラメータ(x,y)値を変えるので、図4の手順(パラメータ値の更新)が開始される。
【0061】
その手順の最後の部分で、ステップ408において、この効果UIは訂正されたパラメータ値をビューア・ウインドウに発行する。その段階で、+印はその新しい位置において再描画される。それゆえ、ユーザの目には、それはドラッグによって+印がその究極位置に動いたように映るが、実際にはドラッギング動作はパラメータを更新したのであり、図4に示されたルートによって、+印の動きとなったのである。
【0062】
図11は、動作ソフトウエアの最初の配列を図示する。これは、装置の特定の動作セッションにおいて、いかなる描写も行われる前の状況を表している。
プラグインは、「ダイナミック・ロード・ライブラリーDLLとしてウインド・オペレーティング・システム下で実施される。DLLは、一般にプログラム・コード、データ、およびサブルーチン・ライブラリーを含むことのできる大きなファイルである。
【0063】
従来は、DLLは、メモリを節約するために、及びシステム性能を改善するために、そのDLLによって扱われる特定のプロセスの実行又は開始のために初めて必要になった時にメモリにロードされた。本実施形態においては、メモリを節約しシステム性能を改善するというこのアイデアは一歩進められている。
【0064】
或効果アイコンがパレット領域から最初に取り出される時、従来は、その効果に対応するDLLがメモリにロードされて、コア340にビルドされるべきグラフのための充分な情報(例えば、他の効果アイコンとの相互接続性)を提供する。
本実施形態においては、その効果のためのDLLはその段階ではロードされない。その代わりに、その効果を表す、いわゆる「メタ・データ」1000がロードされる。このメタ・データはコアに他の効果(例えば、沢山の入力及び出力)と当該効果との相互接続性を定義する情報を提供する。これによって、コアがいかなるDLLもロードする必要なしにグラフをビルドアップできるようにし、それらが絶対的に必要になるまで大きなファイルをロードしないでメモリを節約する。
【0065】
もし、或効果と関係してビューア・ウインドウが開かれると、または、もし何らかの他の手段によってその複合効果が実行されると、DLLはロードされ、そのメタ・データは捨てられるか無視される。
図12〜14は、システムのオートメーションを(他にも増して)容易にする効果プラグインの特色を示している。
【0066】
図12は、以前に提案された効果プラグインを図示する。この効果は画像情報(「クリップ」1300として示されている)をとり、3つの処理パラメータP1,P2,P3(照明位置等)を基にして活動する。図12のプラグインにおいては、パラメータ値は、プラグイン内部に、即ち、プラグインの一部として書かれた注文プログラム・コードによってセットされる。
このことが、パラメータ(例えば、パラメータが時間によって変化するアニメーションシステム、又は照明位置等のパラメータが動き追跡部等の他の効果によって変えられる装置において)の全体の制御を非常に困難にしており、効果プラグイン内部及びしばしば効果プラグインの複数バージョン内に追加コードを要求する。
図13は、本発明の実施形態に従う、もう1つのアプローチを図示する。ここでは、各パラメータは、別のプラグイン1320によって定義され、それらは上記グラフ・エディタにおいて効果間のリンクが定義されているのと同じ方法で「主」効果プラグイン1330にリンクされる。事実、上に説明されたことは全プロセスの簡略化であり、この簡略化はその段階では説明を助けるためになされている。
【0067】
パラメータ・プラグインは、例えば「オフ・ザ・ページ」グラフ・エディット及びパレットにおけるスクリーン位置の所にそれらを表示することにより、通常はユーザから隠されている。もし、或効果が、自蔵、非アニメーション化で動作させられるならば、(即ち、他の効果からパラメータをインポートしなければ)、主効果ビューア・ウインドウを使う各パラメータ・プラグイン1320に対してパラメータがセットされる。
【0068】
もし、パラメータが他の効果出力、例えば、動き追跡効果によって提供される位置値によって定義されるべきであれば、要求される全ては、主効果プラグイン1330と切断すべき適正なパラメータ・プラグイン1320の間の論理リンク及び開始されている動き追跡効果へのリンクに対してである。このシステムがアニメーションにおいて如何に手助けになるかを理解するために図14を参照する。
【0069】
図14において、初め図3に示されたコアとプラグインの間の左右の分割を示す。図14の左手側には、「主」効果サーバー1350に対してプロクシー効果(PE)1340が準備されている。パラメータ・プラグイン1320の各々に対しても、プロクシー効果1360が準備されている。
【0070】
これらのプロクシー効果1360はプロクシー効果1340よりもずっと簡単な性質からなり、プロクシー効果1360とパラメータ・プラグイン1320の間の通信は、プロクシー効果1340と効果サーバー1350間の通信プロトコルの簡略化されたサブセットを使う。
【0071】
実際には、プロクシー効果1360は単一データ値(非アニメーション化システムにおいて)、またはアニメーション・システムにおいては複数値のリストとすることができる。アニメート化されたシステムにおいては、値のリストは、「キー・フレーム」値、即ち、線形もしくはユーザ定義の非線形補間に従ってコアによって補間される中間値を備えた、順序配列された特定の複数画像に対するデータ値セットとすることができる。それゆえ、アニメーションは、各プラグイン内に注文のアニメーション・ソフトウエアを書く必要なしで特定の簡単で都合のよい方法で、設定できる。
【0072】
この記述を、効果の間の依存性について前に与えられた記述と関係付ければ、描写マネージャーからの「描写準備」メッセージが効果サーバー1350で受信された時、それは、その出力が準備できる前にその入力の全てを要求するということをいうために応答できる。この効果入力には勿論パラメータ・プラグインが含まれるので、次の段階は、描画マネージャーが各パラメータ・プラグインに描写準備メッセージを送ることである。
【0073】
もしパラメータ・プラグインが単一値を含み、または現在の画像がキー・フレームならば、このパラメータ・プラグインは動作時に適正なパラメータを準備する用意ができている。しかしながら、もしそのパラメータ・プラグインがアニメーション・データを含み、現在の画像がキー・フレームではないならば、このパラメータはその効果で使われる前に最初に補間されなければならない。
【0074】
図15は、システム・キャッシュ1100を図示する。これは全キャッシュ領域のビューであり、事実前に説明したとおり、キャッシュは夫々のプロクシー効果に関連した複数の個別キャッシュとしても見ることができるが、メモリ資源がそのような個別キャッシュの間で動的に割り当てられるので図15の表現も有効である。
このキャッシュはシステム・メモリ150に準備され、効果(例えば、動き追跡効果の場合に動きベクトル)からの画像1110及び非画像描写出力1130を保存することができる。
【0075】
キャッシュという考え方は、有向非循環グラフにおける各効果の描写された出力(これが画像であるか否かにかかわらず)を保存することである。この方法でもし或効果がその有向非循環グラフの中の特定の位置で変えられれば、その位置の下の効果は新しい出力を準備するために再描写される必要がない。その代わりに、キャッシュされた出力が再使用される。もう一つの利益は、パラメータ変化がなされた前後で(開いているビューア・ウインドウにかかる)複数の特定の効果の出力を保存することにより、undo/redo (不履行/再履行)動作を援助しスピードアップすることである。
【0076】
対応するパラメータ変化も同様に保存されるので、このパラメータ変化は、キャッシュ・メモリ1100から適正なマテリアルを単純にロードすることにより不履行または再履行できる。これは、変化が起きた時に効果サーバーによって書かれたundo/redo オブジェクトの制御の下におかれている。
【0077】
画像は、動きベクトルのような単純データよりもずっと多くのメモリ・スペースをとる。多分100万倍もの多くのメモリ・スペースをとる。それゆえ、本実施形態においては、そのキャッシュ・メモリが容量いっぱいに近づき、かつ他の画像が保存されようとしているとき、そのキャッシュの中の最も古い(最近読み出されていない)画像を削除して、新たに保存する画像のための余地をつくる。しかしながら、キャッシュ中の他のデータ、パラメータ値、非画像描写出力等は、装置の動作セッション中には削除されない。何故ならば、それは画像と比べて小量のメモリ・スペースを消費するからである。この情報は、1つの動作セッションを通じてその情報が有効に留まる限り、再使用、不履行/再履行動作、のために使うことができる。
【0078】
実行に際しては、慣例によってフラッシュ可能としてセットされている画像データ・アイテム、および非フラッシュとしてセットされている非画像アイテムと一緒に、1つのデータ・アイテムがフラッシュできるか否かをプラグインが詳細指定することは後に残しておくことができる。
【0079】
図16は、コア340と効果サーバーの間で非同期・同期の変換を行う変換器1200を示す。
このコンバータ1200は、「to do」待ち行列、即ち行うべき描画作業のリストの形で描画マネージャーから非同期再描画命令を受信する。
一つの作業が終了すると、「終了」メッセージがコンバータ1200から描画マネージャ−に戻される。
コンバータ1200はこの非同期作業要求を受け取って適正なソフトウエア・プラグインに同期リクエストを発行する。これは、インターフェース1200がソフトウエア・プラグインに制御スレッド(ウインドウ用語)を送り、該プラグインは作業が終了するまでそのスレッドのコントロールを保持する。
【0080】
その後のみ、そのソフトウエア・プラグインはインターフェースにスレッドを戻す。インターフェースはコアに「終了」メッセージを発行することによって応答する。
初期化の際に、コアは各プラグインに(又はそのプラグインに関連したメタデータ)に応答指令を出してそのプラグインが同期または非同期通信ができるか否かを決定する。この方法の動作にはハードウエア・アクセレレータがもっと良く適合するので、もし、ハードウエア・プラグイン(例えば、特定の方法で描写するための周辺カード)または、できれば異なったマシン上で動作する、非同期ソフトウエア・プラグインが、或ソフトウエア・プラグインの代わりにインストールされれば、そのプラグインは非同期インターフェースによって(実際、描写を開始する描写マネージャーが非同期的に働く)コアと相互作用する。
それゆえ、この場合には、コンバータ1200はバイパスされる。
このコンバータは、コアの一部又は各関連するプラグインの一部として実装される。
従って、2つの部分のソフトウエアの間にコンバータ1200を提供する直感に反したステップによって、専用のハードウエアに後でグレード・アップするために効率的なハードウエア・インターフェースが準備される。
【0081】
【発明の効果】
本発明のビデオ信号処理装置は、
キャッシュ・メモリを使って、そこに有向非循環グラフ(方向性を有し回転した時に元に戻らないような形状の画像)を保存することにより、ある種の変化に対しては新しい出力を準備するために再描写する必要がなくなる。
【0082】
また、このキャッシュ・メモリにパラメータ変化がなされた前後で(開いているビューア・ウインドウにかかる)複数の特定の(特殊)効果の出力を保存することにより、undo/redo (不履行/再履行)動作を行うことができるので、装置のスピードアップを図ることができる。
【0083】
動きベクトルのような単純データよりもずっと多くのメモリ・スペースをとる画像データについてはメモリの容量いっぱいに近づき、かつ他の画像が保存されようとしているときに、削除して、新たに保存する画像のための余地をつくるようにするが、キャッシュ中の他のデータ、パラメータ値、非画像描写出力等は、装置の動作セッション中には削除されないようにして、メモリを有効使用することができる。
【図面の簡単な説明】
【図1】ディジタル・ビデオ特殊効果装置のブロック図である。
【図2】図1の装置の動作ソフトウエアの組織ブロック図である。
【図3】図1の装置にたいする動作ソフトウエアの組織を更に詳しく示すブロック図である。
【図4】図1の装置における更新された効果パラメータの伝搬を示す線図である。
【図5】図1の装置における再描画命令の伝搬を示す線図である。
【図6】エディット・ウインドウ及びパレット・ウインドウの線図である。
【図7】エディット動作を説明するための線図である。
【図8】複合効果アイコンの構築を示す線図である。
【図9】複合効果のファイル構造を示す線図である。
【図10】ビュー・ウインドウを示す線図である。
【図11】動作ソフトウエアの初期配列を示す線図である。
【図12】前回提案された効果プラグインを示すブロック図である。
【図13】効果プラグインの新形式を示すブロック図である。
【図14】図13の効果サーバーと効果プラグインのためのプロクシー(代理)効果の間の関係を示す線図である。
【図15】システム・キャッシュを示す線図である。
【図16】プラグイン・インターフェースを示すブロック図である。
【符号の説明】
1100・・・システム・キャッシュ、 1110・・・画像保存、
1130・・・非画像描写出力
Claims (3)
- 1つのビデオ信号を形成する複数の画像に対して、連続するビデオ信号処理動作が適用されて画像又はデータの形で対応する処理結果を発生するビデオ信号処理装置であって、
キャッシュされたアイテム及びビデオ信号処理動作と関連する処理結果として、保存するためのキャッシュ保存手段と、
新たにキャッシュされるべきアイテムのためのキャッシュ・スペースを提供するために現在キャッシュされているアイテムを削除する手段であって、動きベクトルデータが画像データよりも長い間キャッシュの中に留められるように動作する削除手段と、を備えたビデオ信号処理装置。 - 請求項1に記載の装置において、
上記削除手段がキャッシュから上記動きベクトルデータを削除しないように動作するようにしたビデオ信号処理装置。 - 1つのビデオ信号を形成する複数の画像に対して、連続するビデオ信号処理動作を適用して画像又はデータの形で対応する処理結果を発生するビデオ信号処理方法であって、
キャッシュされたアイテム及びビデオ信号処理動作と関連する処理結果として保存するステップと、
新たにキャッシュされるべきアイテムのためのキャッシュ・スペースを提供するために現在キャッシュされているアイテムを削除することにより、動きベクトルデータが画像データよりも長い間キャッシュの中に留められるようにするステップと、を含むビデオ信号処理方法。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB9816759A GB2341068B (en) | 1998-07-31 | 1998-07-31 | Caching in digital video processing apparatus |
GB9816759:6 | 1998-07-31 |
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 |
US6639595B1 (en) | 2000-08-23 | 2003-10-28 | Nintendo Co., Ltd. | Achromatic lighting in a graphics system and method |
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 |
US6937245B1 (en) | 2000-08-23 | 2005-08-30 | Nintendo Co., Ltd. | Graphics system with embedded frame buffer having reconfigurable pixel formats |
US6664962B1 (en) | 2000-08-23 | 2003-12-16 | Nintendo Co., Ltd. | Shadow mapping in a low cost graphics system |
US6999100B1 (en) | 2000-08-23 | 2006-02-14 | Nintendo Co., Ltd. | Method and apparatus for anti-aliasing in a graphics system |
US6606689B1 (en) | 2000-08-23 | 2003-08-12 | Nintendo Co., Ltd. | Method and apparatus for pre-caching data in audio memory |
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 |
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 |
US20120166953A1 (en) * | 2010-12-23 | 2012-06-28 | Microsoft Corporation | Techniques for electronic aggregation of information |
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 |
US10645294B1 (en) | 2019-05-06 | 2020-05-05 | 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 |
US11054973B1 (en) | 2020-06-01 | 2021-07-06 | 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 | 니혼 호오소오 고오카이 | 디지탈 영상신호 처리장치 |
GB2278250B (en) * | 1990-08-31 | 1995-03-15 | Canon Kk | 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 |
DE69225544T2 (de) | 1991-08-13 | 1998-12-03 | Xerox Corp | Elektronische Bilderzeugung |
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 | 株式会社Screenホールディングス | 錠剤印刷装置および錠剤印刷方法 |
-
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 JP JP21558399A patent/JP4166376B2/ja not_active Expired - Fee Related
- 1999-07-29 US US09/363,481 patent/US6529200B2/en 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 |
---|---|
JP2000092390A (ja) | 2000-03-31 |
GB2341068B (en) | 2002-11-06 |
GB2341068A (en) | 2000-03-01 |
KR20000012133A (ko) | 2000-02-25 |
KR100722701B1 (ko) | 2007-06-04 |
US6529200B2 (en) | 2003-03-04 |
EP0977122A3 (en) | 2000-05-31 |
US20030001827A1 (en) | 2003-01-02 |
GB9816759D0 (en) | 1998-09-30 |
EP0977122A2 (en) | 2000-02-02 |
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 |