(57)【要約】【課題】提供されたＢＩＦＳソースやツールなどを利用して、シーンに静止画や動画を埋め込む場合、ＢＩＦＳソースの提供者の意図に合った大きさのオブジェクトを用意する必要がある。【解決手段】ＢＩＦＳソース解釈モジュール７０４およびノード名称抽出モジュール７０５により、シーンを符号化するためのシーン記述７０３から任意のノード名を定義する予約語によって定義されたノード名を抽出し、抽出したノード名からオブジェクトのサイズ情報７０８、および、オブジェクトの実体の位置を示すＵＲＬ情報７１１を抽出し、抽出したサイズ情報７０８およびＵＲＬ情報７１１に基づき、参照すべきオブジェクト７０９の大きさを変更する。【選択図】    図１０
2005045400.tif 000002
【特許請求の範囲】
【請求項１】
オブジェクトベース符号化に関連するオブジェクトを生成するオブジェクト生成方法であって、
シーンを符号化するためのシーン記述から、任意のノード名を定義する予約語によって定義されたノード名を抽出し、
抽出したノード名からオブジェクトのサイズに関する情報、および、オブジェクトの実体の位置を示す情報を抽出し、
抽出した位置情報およびサイズ情報に基づき、参照すべきオブジェクトの大きさを変更することを特徴とするオブジェクト生成方法。
【請求項２】
前記ノード名はオブジェクトの大きさを与える文字列を含むことを特徴とする請求項１に記載されたオブジェクト生成方法。
【請求項３】
前記ノード名はキーワード文字列、オブジェクトの大きさを与える文字列、および、それら文字列を区切る区切り文字を有することを特徴とする請求項１に記載されたオブジェクト生成方法。
【請求項４】
前記ノード名には、そのノード名が一意であることを保証するための文字列が付加されることを特徴とする請求項１に記載されたオブジェクト生成方法。
【請求項５】
前記ノード名は、その一部もしくは全部がエンコードされていることを特徴とする請求項１に記載されたオブジェクト生成方法。
【請求項６】
前記オブジェクトベース符号化はＭＰＥＧ−４に適合または準拠することを特徴とする請求項１から請求項５の何れかに記載されたオブジェクト生成方法。
【請求項７】
情報処理装置を制御して、請求項１から請求項６の何れかに記載されたオブジェクトの生成を実行することを特徴とするプログラム。
【請求項８】
請求項７に記載されたプログラムが記録されたことを特徴とする記録媒体。
【請求項９】
オブジェクトベース符号化に関連するオブジェクトを生成するオブジェクト生成装置であって、
シーンを符号化するためのシーン記述から、任意のノード名を定義する予約語によって定義されたノード名を抽出する第一の抽出手段と、
抽出したノード名からオブジェクトのサイズに関する情報、および、オブジェクトの実体の位置を示す情報を抽出する第二の抽出手段と、
抽出した位置情報およびサイズ情報に基づき、参照すべきオブジェクトの大きさを変更する変更手段とを有することを特徴とするオブジェクト生成装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はオブジェクト生成装置およびその方法に関し、例えば、シーン記述により画面中に配置すべき静止画、動画、コンピュータグラフィクスなどのオブジェクトの生成に関する。
【０００２】
【従来の技術】
ディジタルデータ処理能力の向上と通信技術の発展によって、いわゆるマルチメディアを簡単に表現することができるようになり、複数の静止画、動画、音声、ベクトルグラフィクスなどを用いた複雑な表現が一般的になった。このような複合的なマルチメディア（あるいはマルチオブジェクト）表現の方法として、オブジェクトベース符号化方式がある。この具体的な例が、ＭＰＥＧ−４システムと呼ばれる標準規格（ＩＳＯ／ＩＥＣ１４４９６−１）である（例えば、非特許文献１参照）。
【０００３】
ＩＳＯ／ＩＥＣ１４４９６−１では、ＭＰＥＧ−４のオーディオビジュアルオブジェクトを空間にどのように配置して表示すべきかを示す、ＢＩＦＳ  （Ｂｉｎａｒｙ  Ｆｏｒｍａｔｆｏｒ  Ｓｃｅｎｅｓ）と呼ばれるバイナリ形式が規格化されている。ＢＩＦＳは、オブジェクト記述子（Ｏｂｊｅｃｔ  Ｄｅｓｃｒｉｐｔｏｒ）およびその特殊な形式である初期オブジェクト記述子（Ｉｎｉｔｉａｌ  Ｏｂｊｅｃｔ  Ｄｅｓｃｒｉｐｔｏｒ）、さらに、音声や映像をエンコードしたＭＰＥＧ−４ビジュアルやＭＰＥＧ−４オーディオの定義によるビットストリームとともに、複合化されたいわゆるマルチメディアのシーンを合成する。
【０００４】
ＢＩＦＳは、その定義の根底にＶＲＭＬ  （ＩＳＯ／ＩＥＣ１４７７２−１  Ｖｉｒｔｕａｌ  Ｒｅａｌｉｔｙ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ）を使用したもので、ＶＲＭＬを拡張したものと考えてよい。
【０００５】
規格の詳細はＩＳＯ／ＩＥＣ１４４９６−１に定義されているので、ここでは説明しないが、以下では、発明の本質をより簡潔に説明するため、ＶＲＭＬを基本としたＢＩＦＳの表現をＢＩＦＳソースとよび、テキスト形式で表現する。ＢＩＦＳのテキスト表現には、ＸＭＴ  （Ｅｘｔｅｎｓｉｂｌｅ  ＭＰＥＧ−４  Ｔｅｘｔｕａｌ  ｆｏｒｍａｔ）とよばれるＸＭＬ形式の表現があり、以下では、このようなＸＭＴによる表現も含めて、明示的にＸＭＴと表現している場合を除き、ＢＩＦＳソースとする。すなわち、ＢＩＦＳソースは、オブジェクトベース符号化方式において、オブジェクトの配置や動作を定義するシーンを符号化するためのシーン記述方式の具体的な例である。
【０００６】
図１から３は、ＶＲＭＬを基本としたＢＩＦＳソースの記述例を示す図である。
【０００７】
先頭に記述された「＃ＶＲＭＬ  Ｖ２．０  ｕｔｆ８」はコメントで、ＶＲＭＬの規約上定められたものであって発明と直接関係はないが、一般的な記述法の例として記述されている。なお「ｕｔｆ８」は、ＩＳＯ１０６４６を基準とするＵＴＦ−８エンコーディングによる国際文字の指定である。
【０００８】
図４は、図１から３に示すＢＩＦＳソースをエンコードした場合に、その結果として期待される表示の効果を模式的に示す図である。以下では、図１から３のＢＩＦＳソースの例と図４を用いて詳細に説明する。
【０００９】
図１に示す二つ目のコメント行「＃  −−−  背景画像  −−−」以下は、背景の静止画像を示し、ｕｒｌで指定されるオブジェクト「ｂａｃｋｇｒｏｕｎｄ．ＪＰＧ」が図４に示す背景画２０１になる。
【００１０】
同様に、三つ目のコメント行「＃  −−−  静止画：画像１  −−−」以下は図４に示す静止画２０２に、四つ目のコメント行「＃  −−−  動画：画像２  −−−」以下は図４に示す動画２０３にそれぞれ対応する。
【００１１】
図２に示すコメント行「＃  −−−  動作  −−−」と、図３に示すコメント行「＃  −−−  イベント間の接続  −−−」以下の記述は、ポインティングデバイスによってオブジェクトが選択された際の動作などをそれぞれ定義し、例えば、図４の拡大エリア２０４に、選択されたオブジェクトが拡大表示される、といった動作を定義する。
【００１２】
以下では、図１から３のＢＩＦＳソース例についてごく簡単に説明する。
【００１３】
まず、Ｇｒｏｕｐ  ｛  …  ｝の部分は、表示されるシーン全体をグルーピングするノードを示す。次のｃｈｉｌｄｒｅｎ  ［  …  ］はグループの子ノードの集合を示し、次のＴｒａｎｓｆｏｒｍ２Ｄ  ｛  …  ｝で最初のノードの座標変換を表す。
【００１４】
Ｔｒａｎｓｆｏｒｍ２Ｄは、さらに子ノードを保持し、Ｓｈａｐｅ  ｛  …  ｝によって特定のオブジェクトをシーンに取り込む。これは、Ｓｈａｐｅで指定されたオブジェクトをＴｒａｎｓｆｏｒｍ２Ｄによってシーン中の座標にマッピングすることと等価である。Ｓｈａｐｅは、さらにａｐｐｅａｒａｎｃｅ  Ａｐｐｅａｒａｎｃｅ  ｛  …  ｝とｇｅｏｍｅｔｒｙ  Ｂｉｔｍａｐ  ｛  …  ｝を保持し、前者はＳｈａｐｅの視覚特性、後者はその具体的な表示を指定する。視覚特性としては、ｔｅｘｔｕｒｅ  ＩｍａｇｅＴｅｘｔｕｒｅ  ｛  …  ｝によって具体的な画像オブジェクトを指定し、そのオブジェクトを示すｕｒｌが記述される。ｓｃａｌｅやｔｒａｎｓｌａｔｉｏｎはそれぞれ倍率と座標を記述する。
【００１５】
ここで着目すべき点は、Ｔｒａｎｓｆｏｒｍ２Ｄとｇｅｏｍｅｔｒｙに記述されたｓｃａｌｅやｔｒａｎｓｌａｔｉｏｎの値である。ｓｃａｌｅの値は、ＲＯＵＴＥコマンドにより、オブジェクト選択時から一定の時間で、選択されたオブジェクトの拡大と縮小を行う。その動作は、例えばＤＥＦ  ＰＩＣ１ＳＣＡＬＥ（図２）で定義されたＰｏｓｉｔｉｏｎＩｎｔｅｒｐｏｌａｔｏｒ２Ｄ  ｛  …  ｝によって値が変化することで行われる。この例では、縦横が０．５（半分）から１．０（等倍）へと変化し、さらに元の０．５へと戻される。
【００１６】
同様に、ｔｒａｎｓｌａｔｉｏｎの値も変化してオブジェクトの位置が変更される。ｔｒａｎｓｌａｔｉｏｎは、対象になるオブジェクトの平行移動を意味し、この値が変化することによって、オブジェクトの位置が移動する。
【００１７】
以上では、何ら具体的な説明なしに、オブジェクトという言葉を使って説明を行ったが、このオブジェクトの位置と大きさについてより詳しく説明するため、さらに具体的な表現を用いることにする。
【００１８】
図１から３に示すＢＩＦＳソースでは、我々が目にする具体的なオブジェクトとして、背景画のｂａｃｋｇｒｏｕｎｄ．ＪＰＧ、静止画のｐｉｃｔｕｒｅ１．ｉｍｇ、および、動画のｐｉｃｔｕｒｅ２．ｍｏｖｉｅが使用されている。これらのオブジェクトは、ｕｒｌの記述の後にＵＲＬ  （Ｕｎｉｆｏｒｍ  ＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）形式で記述される。この表記は、よく知られたＲＦＣに定義されたものであり、かつ、ＶＲＭＬの定義形式であるので、ここでは詳しく説明しない。
【００１９】
これら三つのオブジェクトは、この例では、ｂａｃｋｇｒｏｕｎｄ．ＪＰＧが横５１２ピクセル×縦３８４ピクセル、ｐｉｃｔｕｒｅ１．ｉｍｇおよびｐｉｃｔｕｒｅ２．ｍｏｖｉｅが横３２０ピクセル×縦２４０ピクセルと仮定されている。上述したｓｃａｌｅは、拡大縮小の割合を示すから、各オブジェクトは、１．０（等倍）で表現された後、それらを包含する領域としての背景画ｂａｃｋｇｒｏｕｎｄ．ＪＰＧを除き、初期値で０．５、すなわち半分のサイズに縮小される。背景画ｂａｃｋｇｒｏｕｎｄ．ＪＰＧはそのままのサイズであるが、静止画と動画は、半分に縮小され、初期段階のサイズは横１６０ピクセル×縦１２０ピクセルである。また、縮小された静止画と動画の位置は、ｔｒａｎｓｌａｔｉｏｎによって座標（１６８、７６）と座標（１６８、−７６）に指定されるため、表示領域の右上と右下に移動される。
【００２０】
このようにして、図４に示すような具体的な位置表現が行われる。注意すべきことは、このようなＢＩＦＳソースによって定義された表示の効果は、ｔｅｘｔｕｒｅ内のｕｒｌで指定されたオブジェクトの絶対的な大きさを何ら規定しない状態で表現されることである。ＩＳＯ／ＩＥＣ１４４９６−１の定義は、その原型となったＶＲＭＬの定義と同様に、その座標系に、いわゆる右手系のデカルト三次元座標を使用し、表現されるテクスチャは、元の大きさに対する比率でのみ表現される。そのため、明示的に、この座標系の中に有限の大きさで定義されるオブジェクトを配置して、そのオブジェクトにテクスチャを貼り付けるといった記述を行わない限り、そのオブジェクトが表示される大きさは、オブジェクトしか知り得ないことになる。
【００２１】
図１から３に示すＢＩＦＳソースの例では、背景画２０１が横５１２ピクセル×縦３８４ピクセルで、かつ、静止画２０２が横６４０ピクセル×縦４８０ピクセルである場合、背景画２０１は、その位置は静止画２０２と完全には重ならないとは言え、いわゆるオーバラップされた状態になり隠されてしまう。このような表示は、おそらく図１から３に示すＢＩＦＳソースの作成者の意図とは異なる。言い換えれば、ＢＩＦＳソースの作成者は、表示されるオブジェクトの絶対的な大きさを認識してソースを記述しているから意図した表現が行われる。この例では、ＢＩＦＳソースの作成者は、背景画２０１を横５１２ピクセル×縦３８４ピクセル、静止画２０２と動画２０３を横３２０ピクセル×縦２４０ピクセルと認識していて、それによりＢＩＦＳソースの作成者の意図が正しく表現される。
【００２２】
ここまでは、図１から３に示すＢＩＦＳソースの例に従い、オブジェクトの配置を中心に説明したが、ＩＳＯ／ＩＥＣ１４４９６−１の定義によれば、そのＢＩＦＳの表示領域については、ＤｅｃｏｄｅｒＣｏｎｆｉｇＤｅｓｃｒｉｐｔｏｒ（復号器設定記述子）内のＤｅｃｏｄｅｒＳｐｅｃｉｆｉｃＩｎｆｏ（復号器固有情報）に保持されるＢＩＦＳＣｏｎｆｉｇにおいて定義される。ＢＩＦＳＣｏｎｆｉｇの定義は次のようなものである。
2005045400.tif 000003
【００２３】
もし、ｈａｓＳｉｚｅが真（ｔｒｕｅ）にセットされていれば（すなわちビットが立っていれば）、ｐｉｘｅｌＷｉｄｔｈとｐｉｘｅｌＨｅｉｇｈｔによって、表示される具体的な表現（シーン）の領域サイズが指定されることになる。
【００２４】
このように、エンコードされたビットストリーム中にサイズが指定されることにより、ＢＩＦＳソースで指示された表現は、さらに、その表示領域が指定されることになる。
【００２５】
このようにして、ＢＩＦＳソースもしくはシーン記述と、これに記述されないビットストリーム中のデータ表現により、複数のオブジェクトが複雑に表現された、いわゆるマルチメディアのシーンを自在に表現することが可能である。
【００２６】
上述したように、ＢＩＦＳソースの作成者は、オブジェクトの配置と動作に関する定義、すなわちシーン記述を、シーン記述から参照される静止画や動画などの外部参照オブジェクトのサイズなどを予め判断し、意図した状態になるように設計しなければならない。しかし、現実には、それでも不充分な場合がある。任意のあらゆる参照オブジェクトに対して意図が反映されるようにシーン記述を設計することは、全く不可能であるとは言えないが、そのためには、シーン記述であるＢＩＦＳソースの作成者の充分な配慮が必須である。例えば、図１から３に例示したＢＩＦＳソースは、横３２０×縦２４０ピクセルのオブジェクトを参照する場合、図４に示すような表示が行われ得る。しかし、オブジェクトのサイズが異なれば、極端な場合、参照されるオブジェクトのほんの一部が表示されるだけになる。
【００２７】
また、ＢＩＦＳソースの作成者が予め特定の意図をもったＢＩＦＳソースを作成し、しかる後、第三者が参照されるオブジェクトを入れ替えると、ＢＩＦＳソースの意図どおりに表現されない場合がある。この問題は、例えばＭＰＥＧ−４の規格をよく知るデザイナがある意図をもってＢＩＦＳソースを設計し、しかる後、エンコードされたＢＩＦＳやＢＩＦＳソースと、ＢＩＦＳを生成するエンコーダを含むＭＰＥＧ−４データの簡易生成ツールを提供するといった場合に顕著に現れる。このような場合、提供されたＢＩＦＳやＢＩＦＳソース、あるいは、ツールなどを利用して、その利用者が欲する静止画や動画を埋め込むといったことが想定されるが、その利用者は、提供者の意図に合った大きさのオブジェクトを予め準備しなければならない。
【００２８】
上記の問題に対処するため、ＢＩＦＳソースに期待するオブジェトのサイズなどをコメントとして埋め込む手法や、提供するツールに期待するオブジェトのサイズへの変換機能を埋め込む、といったことが行われる。しかし、これらの手法は、ツールに固有の機能でのみ実現されたり、利用者がＢＩＦＳソースを読んで独自に判断する必要が生じるなど、不便である。また、ツールに固有の機能で実現する場合は、ＢＩＦＳ（もしくはＢＩＦＳソース）に独自の拡張を施したり、ＢＩＦＳとは異なる別情報を用意したりする必要があり、さらに互換性の問題も発生する。
【００２９】
【非特許文献１】
ＩＳＯ／ＩＥＣ  １４４９６−１
【００３０】
【発明が解決しようとする課題】
本発明は、上述の問題を個々にまたはまとめて解決するもので、シーン記述の意図に合うオブジェクトの生成を目的とする。
【００３１】
【課題を解決するための手段】
本発明は、前記の目的を達成する一手段として、以下の構成を備える。
【００３２】
本発明は、オブジェクトベース符号化に関連するオブジェクトを生成する際に、シーンを符号化するためのシーン記述から、任意のノード名を定義する予約語によって定義されたノード名を抽出し、抽出したノード名からオブジェクトのサイズに関する情報、および、オブジェクトの実体の位置を示す情報を抽出し、抽出した位置情報およびサイズ情報に基づき、参照すべきオブジェクトの大きさを変更することを特徴とする。
【００３３】
【発明の実施の形態】
以下、本発明にかかる実施形態の画像処理を図面を参照して詳細に説明する。
【００３４】
第１実施形態は、任意のノード名称を定義する予約語によって定義する、外部参照オブジェクトに関わるノード名称の文字列を、期待されるオブジェクトの縦横のサイズ（大きさ）の値を付加した文字列として作成する。これにより、予めＢＩＦＳソース中に、期待されるオブジェクトサイズ情報を記述しておくことで、サイズ情報に基づき該当する外部参照オブジェクトの大きさを変更し、ＢＩＦＳ作成者が意図したサイズでオブジェクトを表現するＭＰＥＧ−４データを生成する。
【００３５】
第１実施形態において説明するＭＰＥＧ−４データ生成装置は、オブジェクトベース符号化によるＩＳＯ／ＩＥＣ１４４９６  （ＭＰＥＧ−４）に関するオブジェクトデータ生成装置である。ここで説明するＭＰＥＧ−４データ生成装置は、細部においては異なる構成で表現される場合もあるが、ハードウェアで構成しても、コンピュータ装置にソフトウェアを供給するなどしてソフトウェアで構成しても実現可能で、その構成要素は、本発明の本質に合致する限り、組み替え、統合、再配置が可能である。
【００３６】
なお、以下の説明では、簡略化のため、図１から３に示したＢＩＦＳソースと、図４に示した期待される表示の効果を説明の前提にする。
【００３７】
【第１実施形態】
上述したように、ＢＩＦＳソースが例えばＶＲＭＬを基本とした表現で記述されるものとすると、特定のオブジェクトを貼り付ける部分は、例えば図５に示すように記述される。図１から３に示したＢＩＦＳソースの例では、Ｓｈａｐｅで記述されたノードを、その配置を行うＴｒａｎｓｆｏｒｍ２Ｄノードの子ノードとして記述したが、図５には、とくに説明に必要な部分のみを取り出して示す。
【００３８】
図６はＢＩＦＳソースの一例を示す図で、「ＤＥＦ」は、ＶＲＭＬにおいて任意のノード名称を定義する予約語である。ＢＩＦＳソースの解釈モジュールは、ＤＥＦによって定義された名称を参照する場合に備えて、これを保持する。
【００３９】
図７はＢＩＦＳソース記述方式におけるノード名称の作成方法を説明する図である。
【００４０】
この例のノードの名称は、キーワードになる文字列と、ＢＩＦＳ作成者が意図したオブジェクトの表示サイズの情報を基に作成される。キーワードには、文字列「ＰＬＡＣＥＨＯＬＤＥＲ」が使用されている。また、ＢＩＦＳ作成者が意図したオブジェクトの表示サイズは、キーワード文字列「ＰＬＡＣＥＨＯＬＤＥＲ」の直後に、縦横のサイズを示す二つの値を区切り文字「＿」（アンダスコア）を使って記述されている。図７に示す「＿３２０＿２４０」は縦２４０×横３２０ピクセルを示す。このように、ノード名称は、特定の文字列、期待する縦および横の大きさ、並びに、区切り文字から構成される。
【００４１】
なお、ノード名称の作成方法のうち、キーワード文字列および区切り文字の種類は、発明の本質ではなく、変更が可能である。また、キーワード文字列とサイズ情報の並び順も同様に、発明の本質ではなく、たとえ前後が逆であっても構わない。すなわち、ＤＥＦで定義するノード名称に、キーワード文字列とＢＩＦＳ作成者の期待するオブジェクトサイズを含むことが重要である。
【００４２】
ＢＩＦＳソースの文法上、ＤＥＦで定義するノード名称は、その名称の有効なスコープがグローバルであることなどにより、規格上一意に定めなければならないが、これは例えば次の方法で解決することができる。
【００４３】
図８はノード名称を一意に定める方法の一例を示す図である。
【００４４】
図８に示す例では、作成しようとするノード名称が重複する場合、新たに作成するノード名称のキーワードに一意の数を文字列として付加する。これにより、ノード名称の重複を防ぎ、一意性を保つ。例えば、作成しようとするノード名称「ＰＬＡＣＥＨＯＬＤＥＲ＿３２０＿２４０」と同名のノードが既に存在する場合、キーワード文字列の後ろに数字「１」を付加して、文字列「ＰＬＡＣＥＨＯＬＤＥＲ１＿３２０＿２４０」をノード名称にする。もし、以降もノード名称が重複する場合は、付加する数字をインクリメントして「ＰＬＡＣＥＨＯＬＤＥＲ２＿３２０＿２４０」のようなノード名称にすればよい。
【００４５】
以下では、この方法によってノード名称が定義されたＢＩＦＳソースを例に説明する。
【００４６】
［構成］
図９は、ソフトウェアでＭＰＥＧ−４データ生成装置を構成する場合のコンピュータ装置の構成例を示すブロック図である。
【００４７】
ＣＰＵ  １０１は、ＲＯＭ  １０２やハードディスク（ＨＤ）１０９に記憶されたデータや制御プログラム、オペレーティングシステム（ＯＳ）、ＭＰＥＧ−４データ生成用のアプリケーションプログラムなどに従い、ＲＡＭ  １０３、操作部１０４、モニタ１０６などを制御して、ＭＰＥＧ−４データ生成にかかわる各種の制御や処理を行う。
【００４８】
ＲＡＭ  １０３は、ＣＰＵ  １０１が各種プログラムを実行するための作業領域、操作部１０４から入力されるデータなどの一時保存領域である。
【００４９】
操作部１０４は、マウスやキーボードなどで、ＭＰＥＧ−４データ生成にかかわる各種の制御や処理の設定データなどを、ユーザが入力するためのものである。
【００５０】
モニタ１０６は、ＣＲＴやＬＣＤなどで、画像処理結果や、操作部１０４による操作の際のユーザインタフェイス画面などが表示される。
【００５１】
ネットワークインタフェイスカード（ＮＩＣ）１０８は、ＢＩＦＳデータ、ＭＰＥＧ−４データ、オブジェクトを含む各種データをネットワークを介して他のコンピュータ装置とやり取りするための通信インタフェイスである。
【００５２】
なお、図９には示さないが、操作部１０４、モニタ１０６、ＮＩＣ  １０８およびＨＤ  １０９は、それぞれ所定のインタフェイスを介して、ホストコンピュータのシステムバス１１０に接続されている。
【００５３】
図１０はＭＰＥＧ−４データ生成装置の機能構成例を示すブロック図である。
【００５４】
図１０において、ＢＩＦＳソースエディタモジュール７０１は、ユーザ操作７０２により、ＢＩＦＳソース７０３を作成する。なお、ＢＩＦＳソースエディタモジュール７０１は、説明状記載さするが、第１実施形態には必ずしも必要ではない。
【００５５】
ＢＩＦＳソース解釈モジュール７０４は、予め作成されたＢＩＦＳソース７０３を読み込み、その内容を解釈する。このようなＢＩＦＳソースの解釈を行うモジュールは、ＭＰＥＧ−４の規格としてＩＳＯより出版されているリファレンスコードをはじめ、様々な形で一般に使用されている。
【００５６】
ノード名称抽出モジュール７０５は、外部参照オブジェクトに関わるＤＥＦによって定義されたノード名称およびノードをＢＩＦＳソース７０３から抽出する。サイズ情報抽出モジュール７０７は、ノード名称の文字列からサイズ情報７０８を抽出する。ＵＲＬ情報抽出モジュール７１０は、抽出されたノードにかかるＵＲＬ指定された外部の参照オブジェクト７０９の実体の位置を示すＵＲＬ情報７１１を抽出する。
【００５７】
オブジェクトトランスコーダモジュール７１２は、入力される動画や静止画のオブジェクト７０９を指定された大きさに変換した参照オブジェクトデータ７１４を生成する。このようなトランスコーダもまた、様々な形で一般に使用されている。
【００５８】
ＢＩＦＳエンコーダモジュール７０６は、ＢＩＦＳソースもしくはＢＩＦＳソースを解釈した結果を入力として、ＢＩＦＳデータ７１３を生成する。ＢＩＦＳソース解釈モジュール７０４と同様に、ＩＳＯより出版されているリファレンスコードをはじめとして、様々な形で一般に使用されている。
【００５９】
ＭＰＥＧ−４データ生成モジュール７１５は、最終的に有効なＭＰＥＧ−４データ７１６を生成する。
【００６０】
なお、上記のモジュール群は、どれ一つを取っても一般的に使用されているモジュールであり、それ自体は発明の本質ではない。本発明の本質は、これらのモジュールとその機能の組み合わせにある。
【００６１】
［動作］
図１１はＭＰＥＧ−４データ生成装置の動作を説明するフローチャートである。
【００６２】
まず、ＣＰＵ  １０１は、ＢＩＦＳソース７０３を読み込み、ＢＩＦＳソース解釈モジュール７０４によりＢＩＦＳソース７０３を解釈する（Ｓ８１）。一般に、ＢＩＦＳ解釈モジュール７０４は、内部的にＢＩＦＳソースに記載されたいわゆるシーングラフをメモリ（ＲＡＭ  １０３など）上に展開する。あるいは、ＢＩＦＳソースに記載された内容に従って内部的にイベントを発生させ、イベントドリブンにその処理関数を呼び出す場合もある。
【００６３】
次に、ノード名称抽出モジュール７０５により、ＤＥＦで定義され、かつ、キーワードになる文字列を含むノード名称およびそのノードを抽出する（Ｓ８２）。図１２はノード名称の抽出処理例を示す図である。この例では、予め定義されたキーワード「ＰＬＡＣＥＨＯＬＤＥＲ」が含まれるノード名称の「ＰＬＡＣＥＨＯＬＤＥＲ＿３２０＿２４０」およびそのノードが抽出される。
【００６４】
次に、サイズ情報抽出モジュール７０７により、抽出されたノード名称の文字列を分解して、オブジェクトのサイズ情報７０８を抽出する（Ｓ８３）。図１３はサイズ情報７０８の抽出処理例を示す図である。この例では、ノード名称「ＰＬＡＣＥＨＯＬＤＥＲ＿３２０＿２４０」から、区切り文字「＿」を目印に「３２０」および「２４０」というサイズ情報が取得される。
【００６５】
次に、ＵＲＬ情報抽出モジュール７１０により、抽出したノードが参照するノードおよびそれ以下のノードを検索し、外部の参照オブジェクト７０９自体の位置を示すＵＲＬ情報７１１を抽出する（Ｓ８４）。図１４はＵＲＬ情報７１１の抽出処理例を示す図である。この例では、抽出したノード「ＰＬＡＣＥＨＯＬＤＥＲ＿３２０＿２４０」にかかるノード「Ｓｈａｐｅ」の子ノードであるノード「ＩｍａｇｅＴｅｘｔｕｒｅ」までノードを辿った後、ＵＲＬ情報７１１として「ｐｉｃｔｕｒｅ１．ｉｍｇ」が抽出される。
【００６６】
また、図１５は、ＤＥＦによって定義されるノードが、外部参照オブジェクトの位置情報を記述するノードを参照するＢＩＦＳソースの例を示す図である。この場合も、図１４の例と同様に、ＵＲＬ情報の検索は可能で、ＵＲＬ情報抽出モジュール７１０をそのまま利用することができる。
【００６７】
ステップＳ８３およびＳ８４で抽出されたサイズ情報７０８およびＵＲＬ情報７１１は、オブジェクトトランスコーダモジュール７１２に渡され、動画や静止画の参照オブジェクト７０９は指定サイズに変換される（Ｓ８５）。すなわち、オブジェクトトランスコーダモジュール７１２は、ＵＲＬ情報７１１に基づき、ＢＩＦＳソースの利用者が実際に使用したいオブジェクトを読み込み、サイズ情報７０８に基づき、必要であれば、参照オブジェクト７０９を変換して、指定されたサイズの参照オブジェクトデータ７１４を出力する。勿論、もし、オブジェクトトランスコーダモジュール７１２に入力される参照オブジェクト７０９のサイズが、サイズ情報７０８が示すサイズと同じであれば、変換処理を行う必要はない。
【００６８】
オブジェクト変換処理（Ｓ８５）が行われると、参照オブジェクト７０９のサイズ変換が行われ、ＢＩＦＳソースの作成者の意図に合った大きさのオブジェクトが生成されることになる。例えば「ｐｉｃｔｕｒｅ１．ｉｍｇ」がＪＰＥＧ画像であり、ＢＩＦＳソースの作成者の意図したサイズが縦２４０×横３２０ピクセルで、ＢＩＦＳソースの利用者が使用する参照オブジェクトが縦４８０×横６４０ピクセルの画像であれば、参照オブジェクト７０９は縦横１／２に縮小された縦２４０×横３２０ピクセルの画像に変換される。もし、このサイズ変換が実行されなければ、ＢＩＦＳソース作成者の意図とは異なる縦横二倍のオブジェクトが表示される場合がある。
【００６９】
なお、ステップＳ８２からＳ８５の処理は、ステップＳ８６の判定によって、ＢＩＦＳソース７０３が終了するまで繰り返し実行される。また、オブジェクト変換処理（Ｓ８５）は、ＵＲＬ情報の抽出処理（Ｓ８４）の直後に位置しくなくとも、ＢＩＦＳデータ生成処理（Ｓ８７）の直前に行ってもよい。
【００７０】
ＢＩＦＳソース７０３が終了すると、ＢＩＦＳエンコーダモジュール７０６により、ＢＩＦＳソース解釈モジュール７０４の解釈に従ってＢＩＦＳソース７０３からＢＩＦＳデータ７１３をエンコード出力する（Ｓ８７）。
【００７１】
そして最終的に、ＭＰＥＧ−４データ生成モジュール７１５により、ＢＩＦＳソースの作成者の意図に合うように、参照オブジェクト７０９から変換された参照オブジェクトデータ７１４と、ＢＩＦＳデータ７１３とから有効なＭＰＥＧ−４データ７１６が生成される（Ｓ８８）。
【００７２】
【第２実施形態】
以下、本発明にかかる第２実施形態の画像処理を説明する。なお、第２実施形態において、第１実施形態と略同様の構成については、同一符号を付して、その詳細説明を省略する。
【００７３】
第２実施形態は、期待されるオブジェクトサイズ情報をエンコードした文字列を使い、任意のノード名称を定義する予約語によってノード名称を定義し、予めＢＩＦＳソースの中にサイズ情報を記述することで、第１実施形態と同様、ＢＩＦＳソースの作成者が意図したサイズでオブジェクトを表現するＭＰＥＧ−４データを生成するものである。
【００７４】
任意のノード名称を定義する予約語によって定義されるノード名称から、期待されるオブジェクトの縦横のサイズを取得し、外部参照オブジェクトの大きさを変更する点において、第２実施形態は第１実施形態と類似するが、記述するサイズ情報をエンコードすることで、サイズ情報を利用者から隠蔽して、縦横のサイズ以外の方法で表現したいといった要求、規格上名称に要求される一意性のためのより柔軟な配慮、といった利便性を生む、副次的な効果も期待される。
【００７５】
第２実施形態は、期待されるオブジェクトのサイズ情報をエンコードした文字列を使い、「ＤＥＦ」によってノード名称を定義し、予めＢＩＦＳソースの中にサイズ情報を記述することで、ＢＩＦＳソースの作成者が意図するサイズでオブジェクトを表現するＭＰＥＧ−４データを生成する。
【００７６】
第２実施形態で、第１実施形態と異なる点は、オブジェクトのサイズ情報をエンコードする点で、ノード名称の作成方法およびサイズ情報抽出モジュール７０７の処理が異なるものになる。これ以外は、すべて第１実施形態と同じで、ＭＰＥＧ−４データ生成装置も、第１実施形態で説明した図９および図１０の構成がそのまま利用することができる。
【００７７】
以下、第１実施形態と異なる、ノード名称の作成方法およびサイズ情報抽出モジュール７０７の処理を詳細に説明する。
【００７８】
図１６はＢＩＦＳソースの例を示す図、図１７から図１９はノード名称の作成例を説明する図である。
【００７９】
ノード名称は、キーワード、オブジェクトのサイズ情報および区切り文字を使って作成するが、オブジェクトのサイズ情報をエンコードすることが第１実施形態と異なる。
【００８０】
図１７はオブジェクトのサイズ情報をエンコードする方法例を示すフローチャートである。この例では、オブジェクトのサイズ情報を表す縦・横の数値を四桁の１６進数に変換し（Ｓ９１）、横サイズを上位四桁、縦サイズを下位四桁とする八桁の１６進数（に対応する文字列）を作成する（Ｓ９２）エンコードを行う。
【００８１】
図１８は、このエンコードを具体的に示す図である。縦２４０×横３２０ピクセルを表す数値「２４０」および「３２０」をそれぞれ四桁の１６進数「００Ｆ０」および「０１４０」に変換し、これをつないで「０１４０００Ｆ０」という文字列を作成する。
【００８２】
図１９はエンコードしたオブジェクトのサイズ情報を使ってノード名称を作成する処理を説明する図である。この例では、縦２４０×横３２０ピクセルというサイズ情報、キーワード「ＰＬＡＣＥＨＯＬＤＥＲ」および区切り文字「＿」を使用して、ノード名称「ＰＬＡＣＥＨＯＬＤＥＲ＿０１４０００Ｆ０」を作成する。なお、作成するノード名称を一意に定める処理は、第１実施形態と同様の手法が使えることはいうまでもない。
【００８３】
図２０および図２１はサイズ情報抽出モジュール７０７の動作を説明する図である。
【００８４】
サイズ情報抽出モジュール７０７は、ノード名称の文字列を分解し、オブジェクトのサイズ情報を抽出する。第１実施形態と異なるのは、サイズ情報の抽出の際にデコード処理が必要な点である。サイズ情報抽出モジュール７０７は、ノード名称の文字列からサイズ情報を示す文字列を抽出した後、この文字列をデコードしてサイズ情報を抽出する。
【００８５】
図２０はノード名称からサイズ情報を抽出する具体例を示す図である。この例では、サイズ情報抽出モジュール７０７により、ノード名称の文字列から文字列「０１４０００Ｆ０」を抽出し、この文字列をデコードして、縦２４０×横３２０ピクセルのサイズ情報を得る。つまり、抽出した文字列の上位四桁を１０進数に変換して横のサイズとして解釈し（Ｓ７１）、下位四桁を１０進数に変換して縦のサイズとして解釈する（Ｓ７２）。
【００８６】
なお、オブジェクトのサイズ情報のエンコード方法として、１０進数を１６進数に変換する手法を説明したが、これに限られるわけではない。また、より強固な暗号化ルーチンを用いるなどしても、本質には影響しない。このようなエンコードを行うことで、オブジェクトに期待する大きさをＢＩＦＳソースの利用者に明確にせず、隠蔽することにより、ＢＩＦＳソースの作成者の著作物としての保護を行うといった副次的な効果も期待される。例えば、上に説明した文字列「０１４０００Ｆ０」は、簡単な処理にも関わらず、オブジェクトの大きさそのものを、それから読み取ることは容易ではない。
【００８７】
また、第１実施形態で説明したように、名称の一意性という点でも副次的な効果が期待できる。簡単には、定義名の発現順序に従い、文字列にその順序番号を付加することで、文字列の長さを変えずに一意性を保持することも可能である。この場合、ＢＩＦＳソースからサイズ情報を抽出する際に、逆に順序番号を引いておけばよい。
【００８８】
さらに、エンコードおよびデコード処理が期待する「大きさ」として、縦と横の大きさを使用することを暗黙のうちに前提としたが、縦の大きさと縦横比の組み合わせなどを使用してもよい。あるいは、予め定められた絶対的な大きさに対する縦横比でもよい。これらの指定方法を使用した例の詳細は、方法が単純であるため、詳細な説明は省略する。
【００８９】
このように、ＢＩＦＳソースの作成者が期待するオブジェクトのサイズ情報が何らかの形で符号化されていたとしても、ＢＩＦＳソースに記述することが可能で、第１実施形態と同様に、ＢＩＦＳソースの作成者が意図するサイズでオブジェクトを表現するＭＰＥＧ−４データを生成することができる。
【００９０】
【変形例】
上記の実施形態においては、ＢＩＦＳソース７０３が参照するオブジェクト７０９のＵＲＬと、それと置き換えられるオブジェクトトランスコーダ７１２が出力するサイズ変換後の参照オブジェクトデータ７１４の関連については、何ら説明しなかった。しかし、このような関連付けは、アプリケーションプログラムの制御によって、様々に実現可能なものである。例えば、参照オブジェクト７０９のＵＲＬと置き換えられる参照オブジェクトデータ７１４の対応リストを何らかの形式で保持することで、これは容易に実現される。あるいは、ＵＲＬ情報７１１を取り出した後、ＢＩＦＳソース７０３を解釈した結果のデータに含まれる参照オブジェクト７０９のＵＲＬを、変換後の参照オブジェクトデータ７１４のＵＲＬに変更してもよい。あるいは、ＢＩＦＳソース７０３に含まれる参照オブジェクト７０９のＵＲＬ自体を書き換えることによっても実現可能である。さらに、ＵＲＬはオブジェクトを格納するファイルを示すとは限らず、オブジェクトのビットストリームを参照するＩＤである可能性もあり、このような場合には、ＵＲＬを書き換えずとも何ら矛盾しない場合もある。
【００９１】
また、本発明によるＭＰＥＧ−４データ生成装置は、必ずしも上に説明した様々なモジュールが独立したモジュールでなくても動作することは明らかである。このもっとも簡単な例は、ＢＩＦＳソース解釈モジュール７０４とＢＩＦＳエンコーダモジュール７０６に顕著である。これら二つのモジュールは、サイズ情報７０８およびＵＲＬ情報７１１の取出機能が実現されていれば、一つのモジュールとして実装可能である。本発明の本質は、ＢＩＦＳソース７０３に含まれる参照オブジェクト７０９を、ＢＩＦＳ作成者が意図したサイズに変換し、参照オブジェクトデータ７１４を生成する機能を一連の処理によって行うことにより実現され、各モジュールの独立性はその本質ではない。
【００９２】
このように、ＩＳＯ／ＩＥＣ１４４９６−１の定義に矛盾しない方法によって、期待されるオブジェクトの幅と高さをＢＩＦＳソースに記述し、これを解釈することによって、予め作成済み、あるいは、参照されるオブジェクトが未解決のＢＩＦＳソースであっても、オブジェクトが決定されたときに、参照されるオブジェクトに期待される幅と高さを利用して、ＢＩＦＳソースの作成者の意図に合う表現にすることができる。
【００９３】
なお、ＭＰＥＧ−４データ生成装置とそのモジュール構成は、必ずしもパーソナルコンピュータ上で動作するアプリケーションプログラムの分野に限定されるものではない。ＭＰＥＧ−４データ生成装置は、ディジタルカメラやカムコーダ、携帯電話、ディジタルレコーダなどのハードウェア機器に適用可能してもよい。
【００９４】
さらに、本発明は複数の機器（例えばホストコンピュータ、インタフェイス機器、スキャナ、プリンタなど）から構成されるシステムに適用しても、一つの機器（例えば携帯電話）からなる装置に適用してもよい。ＭＰＥＧ−４データ生成装置を構成するモジュールが、複数の機器に分散されているとしても、適当な通信機能やデータ共有などによりそれらが対話的に通信可能であれば、それら複数の機器が本発明を構成する。あるいは、複数の機器の一部がインターネットやその他の通信機能によって離れた場所にあってもよい。
【００９５】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００９６】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００９７】
本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。
【００９８】
【発明の効果】
以上説明したように、本発明によれば、シーン記述の意図に合うオブジェクトを生成することができる。
【図面の簡単な説明】
【図１】ＶＲＭＬを基本としたＢＩＦＳソースの記述例を示す図、
【図２】ＶＲＭＬを基本としたＢＩＦＳソースの記述例を示す図、
【図３】ＶＲＭＬを基本としたＢＩＦＳソースの記述例を示す図、
【図４】図１から３に示すＢＩＦＳソースをエンコードした場合に、その結果として期待される表示の効果を模式的に示す図、
【図５】第１実施形態におけるＢＩＦＳソースの例を示す図、
【図６】ＢＩＦＳソースの一例を示す図、
【図７】ＢＩＦＳソース記述方式におけるノード名称の作成方法を説明する図、
【図８】ノード名称を一意に定める方法の一例を示す図、
【図９】ソフトウェアでＭＰＥＧ−４データ生成装置を構成する場合のコンピュータ装置の構成例を示すブロック図、
【図１０】ＭＰＥＧ−４データ生成装置の機能構成例を示すブロック図、
【図１１】ＭＰＥＧ−４データ生成装置の動作を説明するフローチャート、
【図１２】ノード名称の抽出処理例を示す図、
【図１３】サイズ情報の抽出処理例を示す図、
【図１４】ＵＲＬ情報の抽出処理例を示す図、
【図１５】ＤＥＦによって定義されるノードが、外部参照オブジェクトの位置情報を記述するノードを参照するＢＩＦＳソースの例を示す図、
【図１６】ＢＩＦＳソースの例を示す図、
【図１７】ノード名称の作成例を説明する図、
【図１８】ノード名称の作成例を説明する図、
【図１９】ノード名称の作成例を説明する図、
【図２０】サイズ情報抽出モジュールの動作を説明する図、
【図２１】サイズ情報抽出モジュールの動作を説明する図である。
【図１】
2005045400.tif 000004
【図２】
2005045400.tif 000005
【図３】
2005045400.tif 000006
【図４】
2005045400.tif 000007
【図５】
2005045400.tif 000008
【図６】
2005045400.tif 000009
【図７】
2005045400.tif 000010
【図８】
2005045400.tif 000011
【図９】
2005045400.tif 000012
【図１０】
2005045400.tif 000013
【図１１】
2005045400.tif 000014
【図１２】
2005045400.tif 000015
【図１３】
2005045400.tif 000016
【図１４】
2005045400.tif 000017
【図１５】
2005045400.tif 000018
【図１６】
2005045400.tif 000019
【図１７】
2005045400.tif 000020
【図１８】
2005045400.tif 000021
【図１９】
2005045400.tif 000022
【図２０】
2005045400.tif 000023
【図２１】
2005045400.tif 000024