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