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