(57)【特許請求の範囲】
【請求項１】
マルチビューレンダリング装置において用いるためのビデオデータ信号の符号化方法であって、
第１の視点と関連付けられたシーンの第１のイメージを供給するステップと、
前記第１のイメージと関連付けられたデプスマップを供給するステップと、
デプスマップ処理、又は、前記マルチビューレンダリング装置による他の視点のための１又は複数のビューのレンダリングにおいて用いられる、メタデータを供給するステップと、
サブイメージにおいて分配されるビデオフレームを有する前記ビデオデータ信号を生成するステップと、
を有し、
前記サブイメージは、
前記第１のイメージに基づく第１のサブイメージと、
前記デプスマップに基づく第１のデプスサブイメージと、
前記第１のデプスサブイメージの色成分において符号化される前記メタデータと、
を有し、
前記メタデータは、前記メタデータにおいて変更があったか否かに関わらず、後続のビデオフレームに繰り返し挿入され、前記メタデータは、幾つかのフレームに対して正確な、又は、固定されたメタデータフレームの使用を可能にするために、前記メタデータが前のフレームから変更されたかどうかを示す変更情報を有する、方法。
【請求項２】
前記ビデオデータ信号は、輝度値及び色度値で構成され、前記デプスマップは、前記第１のデプスサブイメージの輝度値で符号化され、前記メタデータは、前記第１のデプスサブイメージの色度値で符号化される、あるいは、前記ビデオデータ信号は、Ｒ，Ｇ，Ｂ成分で構成され、前記デプスマップは、前記第１のデプスサブイメージの前記Ｒ，Ｇ，Ｂ成分のうちの第１の成分で符号化され、前記メタデータは、前記第１のデプスサブイメージの前記Ｒ，Ｇ，Ｂ成分のうちの他の成分で符号化される、請求項１記載の符号化方法。
【請求項３】
前記ビデオデータ信号に含まれる前記ビデオフレームは、各サブイメージに配置されたデータの未圧縮の二次元アレイを有する、請求項１又は２に記載の符号化方法。
【請求項４】
前記ビデオデータ信号を、１又は複数のビットシリアルデータラインを用いるインタフェースを介して、前記マルチビューレンダリング装置に送信するステップを更に有する、請求項１乃至３のいずれか１項に記載の符号化方法。
【請求項５】
前記メタデータは、全てのフィールドのための、全てのフレームのための、全ての画像のグループのための、及び／又は、全てのシーンのための、前記ビデオデータ信号に挿入される、請求項１乃至４のいずれか１項に記載の符号化方法。
【請求項６】
前記メタデータは、チェックサムを備える、請求項１乃至５のいずれか１項に記載の符号化方法。
【請求項７】
第２の視点と関連付けられたシーンの第２のイメージを供給するステップと、
前記第２のイメージと関連付けられた第２のデプスマップを供給するステップと、
前記ビデオデータ信号を生成するステップと、
を有し、
前記ビデオデータ信号は、
前記第２のイメージに基づく第２のサブイメージと、
前記第２のデプスマップに基づく第２のデプスサブイメージと、
を含む、請求項１乃至６のいずれか１項に記載の符号化方法。
【請求項８】
ビデオデータ信号の復号化方法であって、
第１の視点と関連付けられたシーンの第１のイメージと、前記第１のイメージと関連付けられたデプスマップと、デプスマップ処理、又は、マルチビューレンダリングにおいて用いられるメタデータと、を有する前記ビデオデータ信号を受信するステップであって、前記ビデオデータ信号は、サブイメージにおいて分配されるビデオフレームを有し、前記サブイメージは、前記第１のイメージに基づく第１のサブイメージと、前記デプスマップに基づく第１のデプスサブイメージと、前記第１のデプスサブイメージにおいて符号化される前記メタデータと、を有するステップと、
個別の成分へのアクセスを得るとともに、前記第１のデプスサブイメージの色成分から前記メタデータを抽出するために、前記ビデオデータ信号を分離するステップであって、前記メタデータは、前記メタデータにおいて変更があったか否かに関わらず、後続のビデオフレームに繰り返し挿入され、前記メタデータは、前記メタデータが前のフレームから変更されたかどうかを示す変更情報を有する前記分離するステップと、
前記メタデータに基づいて前記デプスマップをデプスマップ処理するステップと、前記メタデータに基づいて他の視点のための１又は複数のビューをレンダリングするステップと、の少なくとも１つを実行するステップと、
を有し、
前記方法は、幾つかのフレームに対して正確な、又は、固定されたフレームの前記変更情報に依存して前記メタデータを処理するかどうかを決定するために、前記メタデータ処理を扱うとともに前記変更情報を用いるための制御プロセスを有する、復号化方法。
【請求項９】
ビデオデータ信号を復号化するためのデコーダであって、
第１の視点と関連付けられたシーンの第１のイメージと、前記第１のイメージと関連付けられたデプスマップと、デプスマップ処理、又は、マルチビューレンダリングにおいて用いられるメタデータと、を有する前記ビデオデータ信号を受信する受信器であって、前記ビデオデータ信号は、サブイメージにおいて分配されるビデオフレームを有し、前記サブイメージは、前記第１のイメージに基づく第１のサブイメージと、前記デプスマップに基づく第１のデプスサブイメージと、前記第１のデプスサブイメージにおいて符号化される前記メタデータと、を有する前記受信器と、
個別の成分へのアクセスを得るとともに、前記第１のデプスサブイメージの色成分から前記メタデータを抽出するために、前記ビデオデータ信号を分離するデマルチプレクサであって、前記メタデータは、前記メタデータにおいて変更があったか否かに関わらず、後続のビデオフレームに繰り返し挿入され、前記メタデータは、前記メタデータが前のフレームから変更されたかどうかを示す変更情報を有する前記デマルチプレクサと、
前記メタデータに基づいて前記デプスマップをデプスマップ処理するデプスマッププロセッサと、前記メタデータに基づいて他の視点のための１又は複数のビューをレンダリングするレンダリングユニットと、の少なくとも１つと、
を有し、
前記デコーダは、幾つかのフレームに対して正確な、又は、固定されたフレームの前記変更情報に依存して前記メタデータを処理するかどうかを決定するために、前記メタデータ処理を扱うとともに前記変更情報を用いるための制御プロセッサを有する、デコーダ。
【請求項１０】
レンダリングされた１又は複数のビューを表示するマルチビューステレオスコピックディスプレイユニットを更に有する、請求項９記載のデコーダ。
【請求項１１】
任意のビデオデータ信号のいずれかを復号する、請求項９に記載のデコーダ。
【請求項１２】
プロセッサシステムに、請求項１に記載の方法を実行させるための命令を有する、コンピュータプログラム製品。
【請求項１３】
マルチビューレンダリング装置において用いられるビデオデータ信号のエンコーダであって、
第１の視点と関連付けられたシーンの第１のイメージを取得するための取得ユニットと、
前記第１のイメージと関連付けられたデプスマップを取得するための取得ユニットと、
デプスマップ処理、又は、前記マルチビューレンダリング装置による他の視点のための１又は複数のビューのレンダリングにおいて用いられる、メタデータを取得するための取得ユニットと、
サブイメージにおいて分配されるビデオフレームを有する前記ビデオデータ信号を生成するためのジェネレータと、
を有し、
前記サブイメージは、
前記第１のイメージに基づく第１のサブイメージと、
前記デプスマップに基づく第１のデプスサブイメージと、
前記第１のデプスサブイメージの色成分において符号化される前記メタデータと、
を有し、
前記メタデータは、前記メタデータにおいて変更があったか否かに関わらず、後続のビデオフレームに繰り返し挿入され、前記メタデータは、幾つかのフレームに対して正確な、又は、固定されたメタデータフレームの使用を可能にするために、前記メタデータが前のフレームから変更されたかどうかを示す変更情報を有する、エンコーダ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチビューレンダリング装置で用いるためのビデオデータ信号を符号化する方法、ビデオデータ信号を復号する方法、ビデオデータ信号、ビデオデータ信号のエンコーダ、ビデオデータ信号のデコーダ、ビデオデータ信号を符号化するための命令を有するコンピュータプログラム製品、及び、ビデオデータ信号を復号化するための命令を有するコンピュータプログラム製品に関する。
【背景技術】
【０００２】
ここ２０年で、三次元ディスプレイ技術が成熟されている。三次元（３Ｄ）ディスプレイ装置は、視聴者の目の各々に、視聴されるシーンの異なるビューを供給することによって、視聴体験に三次元（デプス）を加える。
【０００３】
結果として、我々は、現在、三次元イメージ／ビデオ信号を視聴するための様々な方法を有する。ユーザが左目及び右目に異なるイメージを与えられるメガネベースの三次元ディスプレイシステムを有することもあれば、視聴者の裸眼にシーンの三次元ビューを供給するオートステレオスコピック三次元ディスプレイシステムを有することもある。
【０００４】
メガネベースのシステムでは、アクティブ／パッシブなメガネが、視聴者の目の各々に対して、スクリーン上に表示されるような異なるイメージを分離するためのフィルタを供給する。メガネなしのシステム、又は、オートステレオスコピックシステムでは、装置は、概ね、バリア又はレンチキュラーの形式などで、レフトイメージを左目に指向するとともにライトイメージを右目に指向するための光指向手段を用いるマルチビューディスプレイである。
【０００５】
ステレオスコピックマルチビューディスプレイ装置で用いるためのコンテンツを供給するために、様々な入力フォーマットが、特に、装置インタフェースに関し、セットトップボックス、ブルーレイプレイヤなどのコンテンツ配信装置と、テレビなどのディスプレイ／レンダリング装置との間で、これまで設計されてきた。
【０００６】
これまで、ＨＤＭＩ、ＤＶＩ、又は、ディスプレイポートなどの装置インタフェースを介したビデオデータの送信のために、様々なフォーマットが定義されてきた。ステレオスコピックイメージレンダリング及びオートステレオスコピックディスプレイの導入に関し、ステレオスコピックイメージレンダリングにおいて使用するためのコンテンツを供給するための更なるニーズがある。上記フォーマットの１つが、国際公開第２００６／１３７０００号明細書に開示されており、当該明細書は、どのようにして、イメージ及びデプス情報、並びに、オプションでオクルージョンイメージ及びオクルージョンデプスが、ＨＤＭＩなどの既存の装置インタフェースを介して、マトリクス形式で送信され得るのかを記述しているフォーマットに関する。このアプローチの裏にある一般的な概念は、新しいオートステレオスコピックディスプレイ装置にコンテンツを配信するために、既存の標準化された装置インタフェースを再利用することである。
【０００７】
より近年では、ＨＤＭＩ装置インタフェースフォーマットが、以下のリンク（http://www.hdmi.org/manufacturer/specification.aspx）を用いてＨＤＭＩのウェブサイトからダウンロード利用可能である「High-Definition Multimedia Interface Specification Version 1.4a Extraction of 3D Signaling Portion」に開示されるようなステレオスコピックイメージ生成において用いるためのビデオデータを扱うためにも適合されている。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明者は、ＨＤＭＩのような既存のオーディオ／ビデオインタフェースフォーマットが、イメージ及びデプス情報を必要とするイメージベースのレンダリングのためのフォーマットに対して限られたサポートしか有さないことを発見した。例えば、ＨＤＭＩ１．４ｂでは、レフトイメージ及び関連付けられたデプスマップを送信するための基本的なサポートしかない。従って、更なる改善の余地があろう。
【課題を解決するための手段】
【０００９】
本発明者は、例えば、ステレオイメージ及び関連付けられたデプス情報の送信のためのサポートも供給する更なるフォーマットを加えることが好適であろうことに気付いた。さらに、後でより詳細に説明されるが、ソース装置からシンク装置に補助的な情報（ＳＥＩなど）を送信するために、より精巧なサポートを供給することも有用であろう。
【００１０】
本発明の第１の態様によれば、請求項１に従ったマルチビューレンダリング装置で用いるためのビデオデータ信号を符号化するための方法が供給される。
【００１１】
オプションで、ビデオ信号は、例えば、左視点及び右視点などの各視点を具備する各イメージ（第１のイメージ及び第２のイメージと称される）に基づく、２つ（又は、それ以上）のサブイメージを有していてもよい。これらのサブイメージの１つ又は両方は、デプスサブイメージをそれぞれ有していてもよい。メタデータは、各デプスサブイメージの１つ又は両方において符号化され得る。オプションで、請求項は、メタデータが色成分において符号化されることを規定しているが、メタデータは、２以上の色成分において符号化されてもよい。
【００１２】
好ましくは、ビデオデータ信号の送信に後方互換性のある態様で、デプスマップからの情報は、１又は２の他のサブイメージの輝度値において符号化され、メタデータからの情報は、１又は２の他のサブイメージの色度値において符号化される。
【００１３】
好ましくは、ビデオデータ信号を有する情報は、実質的に未圧縮の二次元データアレイを有する。
【００１４】
好ましくは、上記方法は、１又は複数のビットシリアルデータラインを用いるインタフェースを介して、ビデオデータ信号をマルチビューレンダリング装置に送信するステップを更に有する。
【００１５】
好ましくは、メタデータは、全てのフィールド、全てのフレーム、全てのピクチャグループ、及び／又は、全てのシーンのためのビデオデータ信号に挿入される。
【００１６】
好ましくは、メタデータは、チェックサムを備え、メタデータは、デコーダ側におけるデプスマップ処理又はビューレンダリングのいずれかによって用いられる。メタデータにおけるエラーの影響度は、甚大であり得る。ＲＧＢピクセルなどの未圧縮のイメージデータを送信するデータインタフェースでは、ピクセル値におけるエラーは、行き過ぎた知覚できるエラーにはつながらない。しかしながら、メタデータにおけるエラーは、レンダリングされるビューにおいて、フレームが、間違ったデプス情報に基づいて、及び／又は、間違ったレンダリング設定を用いて計算されることにつながる。この影響は、極めて甚大であり、結果として、かかるエラーの検出が、要求され、冗長性及び／又はエラー訂正符号の使用が望ましい。
【００１７】
好ましくは、メタデータは、復号化側において処理されるメタデータを扱うためのより効果的な制御プロセスの作成を促進するために、供給されるメタデータが新しいかどうかを示す鮮度情報を有する。
【００１８】
好ましくは、メタデータは、メタデータが前のフレームから変更されたかどうかを示す情報を有する。このことは、リフレッシュ／更新される必要がない、（送信されたとしても）変更しない設定において、制御プロセスがより効果的となることを可能にする。
【００１９】
好ましくは、上記方法は、ステレオデプス情報によるステレオビデオデータの符号化及び送信を扱うステップを更に有する。
【００２０】
本発明の第２の態様によれば、ビデオデータ信号が供給され、当該ビデオデータ信号５０は、請求項１０において規定されるようなマルチビューレンダリング装置で使用される。
【００２１】
本発明の第３の態様によれば、非一時的な形式で、請求項１０又は１１に記載のビデオデータ信号を有するデータ媒体が供給される。このデータ媒体は、ハードディスクドライブ又はソリッドステートドライブなどのストレージ装置の形式であってもよいし、あるいは、光ディスクの形式のデータ媒体であってもよい。
【００２２】
本発明の第４の態様によれば、請求項１３に従ったマルチビューレンダリング装置で用いるためのビデオデータ信号を復号化するための方法が供給される。
【００２３】
本発明の第５の態様によれば、請求項１５に従ったマルチビューレンダリング装置で用いるためのビデオデータ信号を復号化するためのデコーダが供給される。
【００２４】
本発明の第６の態様によれば、プロセッサシステムに、請求項１乃至９のいずれか１項に記載の方法を実行させるための命令を有するコンピュータプログラム製品が供給される。
【００２５】
本発明の第７の態様によれば、プロセッサシステムに、請求項１３又は１４に記載の方法を実行させるための命令を有するコンピュータプログラム製品が供給される。
【００２６】
本発明の第８の態様によれば、請求項２２に従ったマルチビューレンダリング装置で用いるためのビデオデータ信号のエンコーダが供給される。
【００２７】
本発明のこれらの態様及び他の態様が、以下に説明される実施形態を参照して、明らか且つ明確になるであろう。
【図面の簡単な説明】
【００２８】
【図１】図１は、ＨＤＭＩ上の２Ｄ＋デプスフォーマットの送信を概略的に表している。
【図２】図２は、ＨＤＭＩ上のステレオ＋デプスフォーマットの送信を概略的に表している。
【図３】図３は、３Ｄレンダリングチェインにおける、本発明に従ったエンコーダ、及び、本発明に従ったデコーダのブロック図である。
【図４】図４は、本発明に従った復号化方法のフローチャートを示している。
【図５Ａ】図５Ａは、本発明に従った符号化方法のフローチャートを示している。
【図５Ｂ】図５Ｂは、本発明に従った代替的な符号化方法のフローチャートを示している。
【図５Ｃ】図５Ｃは、本発明に従った他の代替的な符号化方法のフローチャートを示している。  異なる図面において同一の参照番号を有する項目は、同一の構造的特徴及び同一の機能、又は、同一の信号を有することに留意すべきである。かかる項目の機能及び／又は構造が説明されている場合、詳細な説明において、それらの繰り返しの説明は必要でない。
【発明を実施するための形態】
【００２９】
本発明者は、マルチビュー３Ｄプレゼンテーションのために意図された、ビデオ及び関連付けられたデプス情報が、利用可能なビデオフレームをビデオ及びデプスのためのサブイメージに分配することによって、ＨＤＭＩ、ＤＶＩ、及び／又は、ディスプレイポートなどの標準的な相互接続／装置インタフェースフォーマットを用いるオートステレオスコピックディスプレイに送信されることができることを発見した。
【００３０】
装置インタフェース上で典型的に用いられるイメージ情報は、Ｒ，Ｇ，Ｂ情報の少なくとも８ビット、即ち、ピクセル毎に２４ビットのサンプルを運ぶことができるように設計されており、ピクセルに関連付けられたデプスは、一般的に、ピクセル毎に完全な２４ビットを必要としないため、サブイメージにおける送信帯域幅は、最適に使用されない。
【００３１】
このため、本発明者は、デプス情報がこれらのサブイメージの輝度サンプルにおいて符号化されるような態様で、サブイメージにおいてデプス情報を送信することを望み、結果、ビュー生成プロセスを向上及び／又はガイドするように意図されたメタデータは、デプスサブイメージの色度サンプルにおいて格納され得る。（つまり、イメージ情報において、デプスサブイメージが格納される。）
【００３２】
本発明は、ＨＤＭＩ（又は、同様の）装置インタフェースからビデオ及びデプス入力信号を受信するオートステレオスコピックディスプレイに適用される。また、本発明は、ＨＤＭＩ、ＤＶＩ、ディスプレイポート、又は、他の装置インタフェースを具備するとともに、３Ｄフォーマットに基づくビデオ及びデプスのためのサポートを供給する、メディアプレーヤ、セットトップボックス、ハンドヘルド／モバイル装置、タブレット、ＰＣなどに適用される。
【００３３】
ＨＤＭＩは、コンテンツソース（メディアプレーヤ、セットトップボックス、及び、他のコンテンツソース）からシンク装置（ディスプレイ、ＴＶ、ＡＶレシーバ）に、ビデオ及びオーディオを送信するために用いられる優れた装置インタフェースフォーマットである。ＨＤＭＩ標準は、本来、最大でフルＨＤ解像度（１９２０×１０８０、及び、２０４８×１０８０）のビデオ解像度をサポートするように規定されているが、３８４０×２１６０、及び、４０９６×２１６０などの（４Ｋとしても知られている）２１６０ｐ解像度には限られたサポートを既に有し、将来における標準改正では、４Ｋフォーマットへのより広いサポートを有することが期待されている。
【００３４】
最新の利用可能なＨＤＭＩ仕様書は、バージョン１．４ｂである。特に、バージョン１．４ａは、２ビューステレオの形式で、即ち、レフトイメージ及びライトイメージのステレオ組を用いて、ステレオスコピックビデオコンテンツの送信をサポートしている。さらに、２Ｄ＋デプス、又は、イメージ＋デプスとしても知られている、レフトイメージ及び関連付けられたデプスを送信するオプションがある。
【００３５】
ビデオ及びオーディオに加えて、ＨＤＭＩは、いわゆるインフォフレーム（InfoFrame）と呼ばれる手段により、限られた量の標準化された制御及び構成データを送信することができる。特に、パーソナルコンピュータによって主に使用される、ＤＶＩ及びディスプレイポートなどの代替的なビデオ（装置）インタフェースがある。
【００３６】
マルチビュー三次元（３Ｄ）イメージレンダリングに関し、装置は、好ましくは、デプス情報及びメタデータと関連付けられた１又は複数のビューを受信する。ビデオ及びデプスのための様々な圧縮フォーマットが、とりわけ、ＩＴＵ−Ｔ（ＶＣＥＧ）、及び、ＩＳＯ／ＩＥＣ（ＭＰＥＧ）によって、現在開発中である。これらの圧縮フォーマットは、復号化プロセスにおいては必要とされないが、復号化されたイメージの最も良好なプレゼンテーションに有用となり得る補足強化情報（ＳＥＩ：supplemental enhancement information）の包含をサポートする。
【００３７】
しかしながら、従来のビデオに関する状況に反して、特に、オートステレオスコピックディスプレイ装置に関し、イメージベースのレンダリングの一部が、様々なプロプライエタリディスプレイ装置の実装をサポート可能にするために、オートステレオスコピックディスプレイ装置によって行なわれることが予想される。従来の２Ｄビデオにおける状況に反する結果として、レンダリングに関するメタデータをオートステレオスコピックディスプレイ装置に送信するためのより大きなニーズがある。特に、オートステレオスコピックディスプレイ装置におけるレンダリングプロセスを改善するために、圧縮されたストリームにおけるＳＥＩ要素として、情報を含むことが予想される。
【００３８】
本発明は、対応するデプス及び補助情報（メタデータ）を有するフルＨＤビデオビューまでを送信するため、２１６０ｐのビデオサンプルを利用することによって、上記問題を解決する。この目的を達成するために、２１６０ｐビデオフレームは、（４つのサブイメージに）４分割され、その各々は、レフトビュービデオフレーム（Ｌ）、ライトビュービデオフレーム（Ｒ）、Ｌ用デプス、及び、Ｒ用デプスの４つのコンポーネントの１つを含んでいる。デプスサブイメージでは、輝度コンポーネントのみが、デプスのために使用される。色度コンポーネントは、補助情報のために使用される。
【００３９】
要するに、従来のソリューションは、典型的に、イメージベースレンダリングのために貧弱なサポートを供給しており、即ち、より具体的には、より進化した／精巧なデプスマップのための不十分なサポートや、ビューレンダリングプロセスを向上／改善するためのメタデータ供給における全般的な不足があるように見受けられる。
【００４０】
本発明は、例えば、（ブロードキャスト受信器／デコーダ及び携帯装置を含む）スタンドアローンのメディアプレーヤとディスプレイ装置、即ち、装置インタフェースとの間で、ビデオ、デプス、及び、メタデータを送信するための相互接続フォーマットに関する。かかる相互接続フォーマットの一例は、ＨＤＭＩである。他の例は、ＤＶＩ及びディスプレイポートである。また、本発明は、例えば、ツイストペア（ＬＶＤＳ：Low voltage differential signaling）上のサブコンポーネント間など、装置内のビデオ相互接続に関する。
【００４１】
ソースコンテンツに依存して、相互接続フォーマットは、関連付けられたデプス又は相違マップ（２Ｄ＋デプス）を具備するシングルビュービデオコンポーネント、又は、１又は２の追加的なデプスコンポーネント（ステレオ＋デプス）を具備する２つのビデオビューのいずれかを含んでいてもよい。
【００４２】
当該技術分野における当業者にとっては明らかであるように、デプスは、概ね、差異に反比例するが、ディスプレイ装置における差異に対するデプスの実際のマッピングは、ディスプレイによって生成され得る差異の総量、ゼロ差異に対する特定のデプス値の割り当ての選択、許容されるクロス差異の量など、様々な設計上の選択に依存する。しかしながら、入力データを備えるデプスデータが、デプス依存態様において、イメージを曲げるために使用される。従って、差異データは、ここでは、質的に、デプスデータとして解釈される。
【００４３】
上述のように、２Ｄ＋デプスに関し、既に、ＨＤＭＩ１．４ｂ（及び１．４ａ、これらは、www.hdmi.orgから部分的にダウンロード利用可能である）におけるプログレッシブビデオのために規定されたオプションのフォーマットがある。ステレオ＋デプスは、毎秒送信可能なピクセル数における制限のため、ＨＤＭＩ１．４ｂでは送信されない。このため、より高い速度が必要であり、これは、以下、ＨＤＭＩ２．０として称される、ＨＤＭＩの将来の改訂において利用可能となることが期待されている。
【００４４】
２Ｄ＋デプスがインタフェースを介して送信される場合、テクスチャ及びデプスが、（Ｌ又はＲの）同一のビューに属する。ステレオの場合、２つのテクスチャビューは、左目ビュー（Ｌ）及び右目ビュー（Ｒ）と固定の関係を持つ。この場合、２つのデプスビューは、２つのテクスチャビューと固定された関係を持つ。ステレオにおいて、２つのデプスビューの一方が、符号化ビットストリームには存在しない場合、ＨＤＭＩフォーマットにおける関連するデプスは、全てゼロに設定され、適切なシグナリングが、補助情報（メタデータ）に含まれる。上述のように、このメタデータは、デプスピクセルの色成分において含まれる。
【００４５】
オプションの２Ｄ＋デプスフォーマットが、ＨＤＭＩ１．４ａ規格の付録Ｈにおいて既に規定されている。シンク装置は、ＥＤＩＤ情報において、ＨＤＭＩ  ＶＳＤＢを介してそのフォーマットのためのサポートを示すことができる。２Ｄ＋デプス（又は、「Ｌ＋デプス」）に関し、3D_Structure_ALL_4ビットは、１に設定されるべきである。これについては、「High-Definition Multimedia Interface Specification Version 1.4a Extraction of 3D Signaling Portion」の表Ｈ−７を参照されたい。ソースからシンクへのシグナリングは、表Ｈ−２に従って、3D_Structureフィールドを０１００（Ｌ＋デプス）に設定することによって、ＨＤＭＩベンダ特有のインフォフレームを通じてなされるべきである。このオプションは、好ましくは、ＶＩＣコード１６（１０８０ｐ６０）又は３１（１０８０ｐ５０）を有する、プログレッシブビデオに関してのみ利用可能である。
【００４６】
ＨＤＭＩは、このフォーマットをＬ＋デプスとして称しているが、２Ｄビデオコンポーネントは、メタデータに含まれる情報に依存して、レフトビュー又はライトビューのいずれかに関連付けられ得ることに留意すべきである。ＨＤＭＩ１．４ｂにおいて規定されているように、メタデータは、ビデオ＋デプス及び補助情報を送信するために使用される特定のフォーマットをシグナリングするために、デプスピクセルの色成分において含まれるべきである。
【００４７】
ＨＤＭＩ２．０は、ＨＤＭＩ１．４ｂより高いピクセルクロック周波数をサポートし、歳だい６０Ｈｚのフレームレートにおける、２１６０ｐフォーマット（３８４０×２１６０、及び、４０９６×２１６０解像度）のためのサポートを含む。２Ｄ＋デプスフォーマット及びステレオ＋デプスフォーマットは、ＨＤＭＩ２．０インタフェース上でデータを伝達するために、２１６０ｐプログレッシブフレームにおいて圧縮されてもよい。
【００４８】
２１６０ｐフォーマットは、ＨＤＭＩによって規定されるＲＧＢ又はＹＣＢＣＲピクセル符号化モードのいずれかと結合されてもよい。より高いフレームレートに関しては、ＹＣＢＣＲ４：２：０ピクセル符号化モードのみが、利用可能なオプションである。
【００４９】
以下のフレーム圧縮構成（モード）は、どのようにして、ＨＤＭＩ２１６０ｐフォーマットがビデオ＋デプスＡ〜Ｄを送信するために使用されるのかを示す例である。
Ａ．プログレッシブ  ２Ｄ＋デプス
Ｂ．インタレースド  ２Ｄ＋デプス
Ｃ．プログレッシブ  ステレオ＋デプス
Ｄ．インタレースド  ステレオ＋デプス
【００５０】
何れのモードにおいても、各アクティブラインは、アクティブラインをともに満たす、関連付けられたデプスピクセルと等しい数が続く、シングルラインのビデオ（テクスチャ）ピクセルを含む。モードは、第１のアクティブラインの第１のデプスピクセルから始まる、デプスピクセルの色成分において符号化されたメタデータにおいて示される。
【００５１】
４つのモードの各々のためのアクティブなＨＤＭＩフレーム内でのテクスチャ及びデプスサブイメージの圧縮が、図１及び図２に示されている。
【００５２】
テクスチャサブイメージは、２つの２１６０ｐＨＤＭＩビデオフォーマットの一方、即ち、１９２０ピクセル又は２０４８ピクセルにおけるアクティブラインの水平解像度の半分の水平解像度を持つ。
【００５３】
プログレッシブモードでは、テクスチャサブイメージは、１０８０ラインの垂直解像度を持つ、即ち、２１６０ｐＨＤＭＩビデオフォーマットの垂直解像度の半分である。
【００５４】
インタレースドモードでは、テクスチャサブイメージは、５４０ラインの垂直解像度を持つ、即ち、２１６０ｐＨＤＭＩビデオフォーマットの垂直解像度の４分の１である。
【００５５】
ＹＣＢＣＲ４：２：２ピクセル符号化の場合におけるサンプリング位置は、好ましくは、ＡＶＣ規格書（ISO/IEC 14496-10:2012 - Information technology - Coding of audio-visual objects - Part 10: Advanced Video Codingの６．２項参照）に従っている。デプスサブイメージは、１９２０又は２０４８ピクセルの水平解像度を持つ、即ち、２つの２１６０ｐＨＤＭＩビデオフォーマットの一方におけるアクティブラインの水平解像度の半分である。
【００５６】
プログレッシブモードでは、デプスサブイメージは、１０８０ラインの垂直解像度を持つ、即ち、２１６０ｐＨＤＭＩビデオフォーマットの垂直解像度の半分である。
【００５７】
インタレースドモードでは、デプスサブイメージは、５４０ラインの垂直解像度を持つ、即ち、２１６０ｐＨＤＭＩビデオフォーマットの４分の１である。
【００５８】
デプスサブイメージは、メタデータによって示される意味を含む、０から２５５までの範囲のデプス値を含む。
【００５９】
ＹＣＢＣＲピクセル符号化の場合、デプス値は、Ｙコンポーネントに格納されるべきである。Ｃコンポーネントは、メタデータを含む場合を除いて、０に設定されるべきである。シンク装置は、デプスのためのＹコンポーネント値にのみ依存すべきである。
【００６０】
ＲＧＢ４：４：４ピクセル符号化の場合、デプス値は、Ｒコンポーネントにおいて格納されるべきである。Ｇコンポーネント及びＢコンポーネントは、メタデータを含む場合を除いて、Ｒコンポーネントと同じ値に設定されるべきである。シンク装置は、デプスのためのＲコンポーネント値にのみ依存すべきである。
【００６１】
あるいは、ＲＧＢ４：４：４ピクセル符号化の場合、デプス値は、Ｇコンポーネントにおいて格納されるべきである。Ｒコンポーネント及びＢコンポーネントは、メタデータを含む場合を除いて、ゼロ値に設定されるべきである。シンク装置は、デプスのためのＧコンポーネント値にのみ依存すべきである。
【００６２】
コンポーネント毎に８ビットより多くのビットが使用される場合（フレームレート及びＨＤＭＩ  ＴＭＤＳクロックが許容する場合）、デプス値は、Ｙコンポーネントの最上位ビットにおいて格納されるべきである。
【００６３】
メタデータチャネルは、フレーム及びメタデータのフォーマット指標を含む。このチャネルは、各フレームにおける第１のデプスラインの第１のデプスピクセルから始まり、
るデプスピクセルに含まれるバイトのシーケンスを有し、データを伝達するために必要とされるラインと同じ数の次のラインからデプスピクセルが続く。メタデータチャネルバイトは、ＹＣＢＣＲピクセル符号化モードの１つでは、デプスサブイメージのＣコンポーネントに格納され、ＲＧＢ４：４：４ピクセル符号化モードでは、Ｇ及びＢコンポーネントに格納される。コンポーネント毎に８ビットより多くのビットが利用可能である場合（フレームレート及びＨＤＭＩ  ＴＭＤＳクロックが許容する場合）、メタデータチャネルバイトは、コンポーネントの８個の最上位ビットに格納される。
【００６４】
様々なピクセル符号化モードにおけるコンポーネントに対するメタデータバイトのマッピングが、以下の表１に示される。
【表１】
0006266761.tif 000002
表１：コンポーネントに対するメタデータバイトのマッピング
【００６５】
メタデータは、メタデータのコンテンツに変更があろうとなかろうと、毎フレームに含まれる。これによる利点は、フレームに関する情報が送信された場合に、レンダリングを開始できるようにする、一フレーム当たりのメタデータへのアクセスが可能になることである。このため、メタデータは、メタデータに変更があってもなくても、例えば、毎フレーム、毎フィールド、ピクチャのグループ毎、及び／又は、毎シーンに、繰り返し挿入されてもよい。
【００６６】
メタデータチャネルは、表２に示されるように、一連のパケットとして構成されていてもよい。
【表２】
0006266761.tif 000003
表２：メタデータチャネル構文
【００６７】
次に、メタデータチャネルパケット構文が、表３において、提案され得る。
【表３】
0006266761.tif 000004
表３：メタデータチャネルパケット構文
【００６８】
メタデータチャネルは、６４バイトのメタデータチャネルパケットのシーケンスを含む。シーケンスに含まれるパケット数は、送信されるメタデータの量に依存する。ロバスト性を改善するため、メタデータは、３回送信される。最後のメタデータチャネルパケットの後のメタデータチャネルの全てのバイトは、０に設定される。このため、ここでは、メタデータに変更がないが、メタデータは、繰り返し挿入されてもよい。
【００６９】
各６４バイトパケットは、４バイトのヘッダで始まり、次に、５６バイトのペイロード、及び、４バイトの誤り検出符号（ＥＤＣ：error detection code）を有する。実際のメタデータは、ペイロードフィールドに含まれる。
【００７０】
packet_idは、表４に従って、パケットのコンテンツを識別する。
【表４】
0006266761.tif 000005
表４：packet_id
【００７１】
特に、packet_idは、より効率的な態様でメタデータを扱うため、装置がビデオストリームを受信できるようにする。特に、packet_id 0xF3は、このデータが前回のフレームにおいて正しく受信された場合、現在のメタデータが無視されてもよいことを示す。
【００７２】
特に、レンダリングに用いるためのメタデータは、ある時点において正確なフレームであってもよく、幾つかの他のフレームのために固定されてもよい。この情報は、より効率的なメタデータ制御操作の実装において、特に有用であり得る。
【００７３】
packet_subcodeは、packet_idの最下位ビットが１に設定される場合（即ち、packet_idが、0xF1又は0F3に設定される場合）、以下の表に従って、現在のフレームのフレーム圧縮構成を示す。他の全ての場合において、packet_subcodeは、将来の使用のために予約され、０に設定されている。
【表５】
0006266761.tif 000006
表４：packet_subcode
【００７４】
packet_metadata_typeは、どのタイプのメタデータが、当該パケットのペイロードに含まれているのかを識別する。メタデータタイプは、ＩＴＵ−Ｔ又はＩＳＯ／ＩＥＣによって標準化されるように、符号化ビットストリーム、例えば、ＡＶＣ又はＨＥＶＣビットストリームに含まれる補足強化情報（ＳＥＩ）から生じる補助情報の種類を表す。メタデータタイプは、ソース装置によって生成されたメタデータのタイプに関するものであってもよい。
【００７５】
packet_countは、同一のpacket_metadata_typeを有するパケットの後のパケット数を示す。
【００７６】
なお、最後のパケットが、packet_count value＝０を含むことに留意すべきである。
【００７７】
packet_payload()は、メタデータチャネルに含まれる５６バイトの総パケットペイロードバイトストリームを伝達する。
【００７８】
１フレームに関する総パケットペイロードバイトストリームは、連続的なパケットストリームに含まれ、例えば、表５（２タイプのメタデータの場合）に表されるようなデータシーケンスを含む。
【表６】
0006266761.tif 000007
表５：packet_payload_byte_streamデータシーケンス
【００７９】
stuffing_byteは、0x00に設定される。１又は複数のスタッフィングバイトが、同じタイプから（必要であれば）端に向かってパケットペイロードを埋めるため、最後のメタデータバイトに続くバイトストリームに含まれる。パケットペイロードバイトストリームにおけるバイト数が５６バイトの倍数でない間、While文における関係式はTRUEである。
【００８０】
reserved_metadata_bytes()は、将来において定義され得る追加的なメタデータを表している。かかる追加的なデータは、（メタデータチャネルパケットを有するメタデータを配置する必要があれば）metadata_typeの値を増加させ、スタッフィングバイトの可能な包含とともに、含まれるべきである。
【００８１】
packet_edcは、パケットの最初の６０バイトから計算される誤り検出符号を含む４バイトのフィールドである。このＥＤＣは、ＩＥＥＥ  ８０２．３及びＩＴＵ−Ｔ  Ｖ．４２において定義されるような標準的なＣＲＣ−３２多項式を用いる。初期値及び最後のＸＯＲ値は、共に０である。
【００８２】
メタデータの性質
ビデオデータ信号を介して送信されるメタデータは、デプスマップ処理における使用、又は、マルチビューレンダリング装置による他の視点のための１又は複数のビューをレンダリングするためのものである。かかるメタデータは、コンテンツに依存する。メタデータは、実際のビデオデータに従って供給される。このため、メタデータは、例えば、フィールド毎、フレーム毎、ピクチャグループ毎、及び／又は、シーン毎に、実際のビデオデータに従って変化し得る。かかるメタデータは、本質的に動的であり、例えば、イメージ又はデプスデータがビデオデータの２次元マトリクスのセクションに存在することのみを示すヘッダのように静的ではない。オプションで、メタデータは、イメージベースレンダリングのための好適なレンダリング方向の符号化のためのメタデータ、イメージ情報とデプス情報との間の関係を示すメタデータ、ターゲットディスプレイに対するデプスマップ又は差異マップの再マッピングに用いるためのメタデータ、のうちの少なくとも１つを有する。かかるメタデータの様々な例が提案されている。
【００８３】
イメージベースレンダリングにおいて使用されるメタデータは、例えば、国際公開第２０１１／０３９６７９号に開示されるようなメタデータであってもよい。当該公報は、イメージベースレンダリングのための信号における好適なレンダリング方向の符号化に関する。この文書は、第１の視点から見られるシーンの第１のイメージを供給するステップと、レンダリング視点から見られるようなシーンの少なくとも１つのレンダリングされたイメージの生成を可能にするためのデプスマップなどのレンダリング情報を供給するステップと、第１の視点に関するレンダリング視点の好適な向きを定義する好適な方向指標を供給するステップと、第１のイメージ、レンダリング情報、及び、好適な方向指標を表している符号化されたデータを有するビデオデータ信号を生成するステップと、を有する、ビデオデータ信号の符号化方法を開示している。
【００８４】
好適なレンダリング方向情報は、コンテンツ依存であるメタデータであるが、更に、装置製造者が、最高のディスプレイ装置を作ることを可能にするために、オートステレオスコピックディスプレイ装置が、典型的に、ディスプレイ装置自体である場合、実際のビューレンダリングを実行する装置によって使用される必要のあるメタデータでもある。
【００８５】
あるいは、メタデータは、国際公開第２０１０／０７０５４５号に開示されるように、イメージ情報とデプス情報との間の関係を示していてもよい。再び、ストリームにおいて符号化された情報は、実際のコンテンツに依存し、レンダリングを更に改善するために、オートステレオスコピックディスプレイ装置によって使用され得る。例えば、ステレオ＋デプスコンテンツの場合、デプス情報がステレオスコピックコンテンツから抽出されたかどうか、及び／又は、デプス情報が人間援助型オーサリングに基づくものかどうかを知ることは有用であろう。後者の場合、ステレオスコピックコンテンツの差分推定に基づき低解像度のデプスマップをより高解像度のデプスマップと結合するよりも、例えば、クロスバイラテラルアップスケーリングフィルタを用いたイメージ援助型アップスケーリングを通じて、低解像度のデプスマップの解像度を増加させることが、より好適であろう。
【００８６】
または、例えば、国際公開第２０１０／０４１１７６号に開示されるように、供給されるメタデータは、ターゲットディスプレイに対するデプスマップ又は差異マップの再マッピングにおいて使用するためのメタデータであってもよい。この国際公開は、様々なターゲットディスプレイのために、コンテンツを再ターゲットするための視差変換の使用に関する。
【００８７】
かかるデプス／差異の再マッピングは、コンテンツ依存するだけでなく、データ処理がディスプレイ装置に依存する処理である。結果として、この視差変換データは、好ましくは、コンテンツ自体とともに圧縮されたフォーマットにおいて供給されるデータである。例えば、視差変換は、ストレージ装置、又は、データ媒体から読み出される、あるいは、有線／無線ネットワークから受信される、圧縮されたコンテンツに埋め込まれていてもよい。また、それは、メタデータとして追加され、ビューレンダリングのための装置に送信される。
【００８８】
図３によれば、図３は、本発明に従ったエンコーダ、及び、３Ｄレンダリングチェインにおける本発明に従ったデコーダのブロック図を示している。
【００８９】
図の左上には、エンコーダ３１０が見られる。エンコーダ３１０は、マルチビューレンダリング装置で使用するためのビデオデータ信号５０のエンコーダである。当該エンコーダ３１０は、第１の視点に関連付けられたシーンの第１のイメージ１０を取得するように構成された第１の取得ユニット３０１と、第１のイメージ１０と関連付けられたデプスマップ２０を取得するように構成された第２の取得ユニット３０２と、デプスマップ処理又はマルチビューレンダリング装置による他の視点のための１又は複数のビューのレンダリングに使用するためのメタデータ３０を取得するように構成された第３の取得ユニット３０３と、を有する。エンコーダ３１０は、ビデオデータ信号５０を生成するように構成された生成器３０４を更に有し、当該ビデオデータ信号５０は、第１のイメージ１０に基づく１又は２のサブイメージと、デプスマップ２０に基づく１又は２の他のサブイメージと、１又は２の他のサブイメージにおいて符号化されたメタデータ３０と、を有する。
【００９０】
本願を通じて、エンコーダによるデータの取得は、外部ソースからデータを受信する、エンコーダ装置によってデータを取得する、又は、エンコーダ装置によってデータを生成する、のいずれかを含むものと考えられる。
【００９１】
好ましくは、デプスマップ２０からの情報は、１又は２の他のサブイメージの輝度値において符号化され、メタデータ３０からの情報は、１又は２の他のサブイメージの色度値において符号化される。
【００９２】
より好ましくは、ビデオデータ信号に含まれる情報は、各サブイメージが配置された、実質的に未圧縮のデータの２次元アレイを有する。
【００９３】
一旦、ビデオデータ信号５０が符号化されると、ビデオデータ信号５０は、代替的に、ハードディスク、光学ディスク、又は、ソリッドステートメモリなどの不揮発性メモリストレージであり得る、ストレージ媒体７１にビデオデータ信号５０を格納可能なハンドラ７０によって操作される。しかしながら、実際には、データは、有線ネットワーク７２又は無線ネットワーク７３又はそれらの組み合わせ（図示省略）を介して、ハンドラ７０によって送信される可能性が高い。
【００９４】
次いで、ビデオデータ信号は、ビデオデータ信号５０を復号化するためのデコーダ３５０に到着する。当該デコーダは、ビデオデータ信号５０を受信するように構成された受信器３５１を有する。このとき、ビデオデータ信号は、第１の視点と関連付けられたシーンの第１のイメージ１０と、第１のイメージ１０と関連付けられたデプスマップ２０と、デプスマップ処理又は複数のビューのレンダリングにおいて使用するためのメタデータ３０とを有する。ビデオデータ信号は、次に、デマルチプレクサ３５２へ渡される。当該デマルチプレクサは、個々のコンポーネントへのアクセスを得るために、ビデオデータ信号５０を逆多重化（分離）するように構成されている。
【００９５】
さらに、デコーダ３５０は、メタデータ３０に従ってデプスマップ２０を処理するように構成されたデプスマッププロセッサ３５３、又は、レンダリングユニット３５４一方を少なくとも含む。当該レンダリングユニットは、１又は複数のビューあるいはその両方をレンダリングするように構成されている。それらのうちの少なくとも１つが、本発明において、メタデータの操作に利点を供給することができるように、存在すべきである。
【００９６】
さらに、オプションで、デコーダ３５０は、マルチビューステレオスコピックディスプレイユニット３５６を含む。このディスプレイユニットは、バリアベース又はレンチキュラーベースのマルチビューディスプレイ装置であってもよく、あるいは、レンダリングに追加的なビューが必要なマルチビューディスプレイ装置の形式であってもよい。
【００９７】
デマルチプレクサ３５２を用いてデータを逆多重化した後、メタデータは、メタデータの更なる操作のための制御プロセッサ３５５へ渡される。図４へ移ると、図４は、本発明に従った符号化方法のフローチャートを示している。当該フローチャートは、マルチビューレンダリング装置で使用するためのビデオデータ信号５０を符号化するための処理を示しており、当該方法は、第１の視点と関連付けられたシーンの第１のイメージ１０を供給するステップ４０１と、第１のイメージ１０と関連付けられたデプスマップ２０を供給するステップ４０２と、デプスマップ処理又はマルチビューレンダリング装置による他の視点のための１又は複数のビューのレンダリングにおいて使用するためのメタデータ３０を供給するステップ４０３と、を有する。さらに、上記方法は、ビデオデータ信号５０を生成するステップ４０４を有し、当該ビデオデータ信号５０は、第１のイメージ１０に基づく１又は２のサブイメージと、デプスマップ２０に基づく１又は２の他のサブイメージと、１又は２の他のサブイメージにおいて符号化されたメタデータ３０とを有する。
【００９８】
上述されるように、好ましくは、デプスマップ２０からの情報は、１又は２の他のサブイメージの輝度値において符号化され、メタデータ３０からの情報は、１又は２の他のサブイメージの色度値において符号化される。
【００９９】
さらに好ましくは、ビデオデータ信号に含まれる情報は、各サブイメージが配置された実質的に未圧縮のデータの２次元アレイを有する。
【０１００】
図５に移ると、図５は、本発明に従った復号化方法のフローチャートを示している。当該フローチャートは、ビデオデータ信号５０を復号化するための処理を概略的に示しており、当該方法は、ビデオデータ信号５０を受信するためのステップ５０１を有する。ビデオデータ信号は、図３を参照して上述したように、第１の視点と関連付けられたシーンの第１のイメージ１０と、第１のイメージ１０と関連付けられたデプスマップ２０と、デプスマップ処理又は複数のビューのレンダリングにおいて使用するためのメタデータ３０とを有している。
【０１０１】
また、上記方法は、個別のコンポーネントへのアクセスを得るために、ビデオデータ信号５０を逆多重化（分離）するためのステップ５０２を有する。逆多重化後、メタデータは、どのように更なる処理が進められるべきかを決定するために、調査される。メタデータ３０に従ってデプスマップを処理する必要がある場合、当該処理は、ステップ５０３に続く、即ち、メタデータ３０に従ったデプスマップ２０のデプスマップ処理５０３に続く。
【０１０２】
あるいは、デプスマップ処理が必要でない場合、上記処理は、メタデータ３０に従って、他の視点のための１又は複数のビューをレンダリングするステップ５０４に続く。最後に、オプションで、新たにレンダリングされたビューが、マルチビューステレオスコピックディスプレイ装置を用いて、レンダリングされたビューを実際にディスプレイするステップ５０５において使用される。
【０１０３】
特に、図５Ｂ及び図５Ｃは、本発明に従った復号化方法の他の実施形態を供給している。ここで、図５Ｂは、デプス処理のために供給されるメタデータがない実施形態、即ち、メタデータがレンダリング処理を制御するためだけに使用されるシナリオを示している。メタデータに基づくデプス処理がないため、対応するステップは、フローチャートから除去されている。
【０１０４】
同様に、図５Ｃは、レンダリング処理のために供給されるメタデータがないが、デプス処理ステップのために供給されるメタデータが常に存在する実施形態を示している。このシナリオでは、メタデータ３０に従ったビューレンダリングに関するステップ５０４は、メタデータ３０を使用しないビューレンダリングステップであるステップ５０４´に置き換えられている。
【０１０５】
当然のことながら、本発明は、コンピュータプログラム、特に、本発明を実施するために適合された、媒体に記録されたコンピュータプログラムにも拡張される。当該プログラムは、ソースコード、オブジェクトコード、部分的にコンパイルされた形式などの中間的なソースコード及びオブジェクトコードの形式、あるいは、本発明に従った方法の実施において適切に使用される任意の他の形式であってもよい。また、当然のことながら、上記プログラムは、多くの異なるアーキテクチュアル設計を有していてもよい。例えば、本発明に従った方法又はシステムの機能を実装するプログラムコードは、１又は複数のサブルーチンに分割されてもよい。
【０１０６】
これらのサブルーチン上に機能を分布させる多くの様々な態様が、当業者にとって明らかであろう。当該サブルーチンは、自己含有型のプログラムを形成するように１つの実行可能なファイルに一緒に格納されてもよい。かかる実行可能なファイルは、例えば、プロセッサ命令及び／又はインタープリタ命令（例えば、Java（登録商標）インタープリタ命令）などの、コンピュータ実行可能な命令を有していてもよい。主なプログラムは、上記サブルーチンの少なくとも１つに対する少なくとも１つの呼び出しを含む。また、上記サブルーチンは、互いを呼び出す機能を有していてもよい。コンピュータプログラム製品に関する実施形態は、上記方法の少なくとも１つの処理ステップの各々に対応するコンピュータ実行可能な命令を有する。これらの命令は、サブルーチンに分割されてもよく、及び／又は、静的又は動的にリンクされた１又は複数のファイルに格納されてもよい。
【０１０７】
コンピュータプログラム製品に関する他の実施形態は、システム及び／又は製品などの少なくとも１つの手段の各々に対応するコンピュータ実行可能な命令を有する。これらの命令は、サブルーチンに分割されてもよく、及び／又は、静的又は動的にリンクされた１又は複数のファイルに格納されてもよい。
【０１０８】
コンピュータプログラムの媒体は、プログラムを運ぶことが可能な任意のエンティティ又は装置であってもよい。例えば、上記媒体は、ＣＤ−ＲＯＭなどのＲＯＭなどのストレージ媒体、あるいは、フロッピーディスク又はハードディスクなどの磁気記録媒体を含んでいてもよい。さらに、上記媒体は、電気ケーブル、光ケーブル、無線、又は、他の手段により伝達可能な、電気信号又は光信号などの送信可能な媒体であってもよい。上記プログラムが上記信号により実現される場合、上記媒体は、かかるケーブル又は他の装置又は他の手段によって構成され得る。あるいは、上記媒体は、プログラムが埋め込まれた集積回路であってもよく、当該集積回路は、関連する方法を実行、又は、実行に際し使用されるように、適合している。
【０１０９】
上記実施形態は、本発明を限定しようとするものではなく、当該技術分野における当業者は、添付の請求項の範囲から逸脱することなく、多くの代替的な実施形態を設計可能であることに留意すべきである。請求項中、括弧内の任意の参照符号は、請求項を限定するものとして解釈されるべきではない。「有する」なる動詞及びその活用形の使用は、請求項に記載されたもの以外の要素又はステップの存在を除外しない。要素の単数形は、かかる要素が複数存在することを除外しない。本発明は、幾つかの別個の要素を有するハードウェアにより実装されてもよいし、適切にプログラムされたコンピュータにより実装されてもよい。幾つかの手段を列挙している装置請求項では、これらのうち幾つかは、全く同一のハードウェアによって実現されてもよい。特定の特徴が相互に異なる従属請求項において言及されているという単なる事実は、これらの特徴の組み合わせが好適に用いられないということを示すものではない。
【図１】
0006266761.tif 000008
【図２】
0006266761.tif 000009
【図３】
0006266761.tif 000010
【図４】
0006266761.tif 000011
【図５Ａ】
0006266761.tif 000012
【図５Ｂ】
0006266761.tif 000013
【図５Ｃ】
0006266761.tif 000014