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