以下、発明を実施するための形態(以下、「実施の形態」とする)について説明する。なお、説明を以下の順序で行う。
1.実施の形態
2.変形例
<1.実施の形態>
[画像送受信システムの構成例]
図1は、実施の形態としての画像送受信システム10の構成例を示している。この画像送受信システム10は、放送局100と、セットトップボックス(STB)200と、テレビ受信機(TV)300を有している。
セットトップボックス200およびテレビ受信機300は、HDMI(High Definition Multimedia Interface)のデジタルインタフェースで接続されている。セットトップボックス200およびテレビ受信機300は、HDMIケーブル400を用いて接続されている。セットトップボックス200には、HDMI端子202が設けられている。テレビ受信機300には、HDMI端子302が設けられている。HDMIケーブル400の一端はセットトップボックス200のHDMI端子202に接続され、このHDMIケーブル400の他端はテレビ受信機300のHDMI端子302に接続されている。
[放送局の説明]
放送局100は、ビットストリームデータBSDを、放送波に載せて送信する。放送局100は、ビットストリームデータBSDを生成する送信データ生成部110を備えている。このビットストリームデータBSDには、立体画像データ、音声データ、重畳情報のデータなどが含まれる。立体画像データは所定の伝送フォーマットを有し、立体画像を表示するための左眼画像データおよび右眼画像データを持っている。重畳情報は、一般的には、字幕、グラフィクス情報、テキスト情報などであるが、この実施の形態においては、サブタイトル(字幕)である。
「送信データ生成部の構成例」
図2は、放送局100において、送信データ生成部110の構成例を示している。この送信データ生成部110は、データ取り出し部(アーカイブ部)130と、視差情報作成部131と、ビデオエンコーダ113と、オーディオエンコーダ117と、サブタイトル発生部132と、サブタイトル処理部133と、サブタイトルエンコーダ134と、マルチプレクサ122を有している。
データ取り出し部130には、データ記録媒体130aが、例えば、着脱自在に装着される。このデータ記録媒体130aには、左眼画像データおよび右眼画像データを持つ立体画像データが記録されていると共に、この立体画像データに対応付けて、音声データおよび視差情報が記録されている。データ取り出し部130は、データ記録媒体130aから、立体画像データ、音声データ、視差情報を取り出して出力する。データ記録媒体130aは、ディスク状記録媒体、半導体メモリ等である。
データ記録媒体130aに記録されている立体画像データは、所定の伝送フォーマットの立体画像データである。立体画像データ(3D画像データ)の伝送フォーマット例を説明する。ここでは、以下の第1〜第3の伝送方式を挙げるが、これら以外の伝送方式であってもよい。また、ここでは、図3に示すように、左眼(L)および右眼(R)の画像データが、それぞれ、決められた解像度、例えば、1920×1080pのピクセルフォーマットの画像データである場合を例にとって説明する。
第1の伝送方式は、トップ・アンド・ボトム(Top & Bottom)方式で、図4(a)に示すように、垂直方向の前半では左眼画像データの各ラインのデータを伝送し、垂直方向の後半では左眼画像データの各ラインのデータを伝送する方式である。この場合、左眼画像データおよび右眼画像データのラインが1/2に間引かれることから原信号に対して垂直解像度は半分となる。
第2の伝送方式は、サイド・バイ・サイド(Side By Side)方式で、図4(b)に示すように、水平方向の前半では左眼画像データのピクセルデータを伝送し、水平方向の後半では右眼画像データのピクセルデータを伝送する方式である。この場合、左眼画像データおよび右眼画像データは、それぞれ、水平方向のピクセルデータが1/2に間引かれる。原信号に対して、水平解像度は半分となる。
第3の伝送方式は、フル・フレーム(Full Frame)方式、あるいはフレーム・シーケンシャル(FrameSequential)方式、あるいはバックワード・コンパチブル(Backward Compatible)方式で、図4(c)に示すように、左眼画像データと右眼画像データとをフレーム毎に順次切換えて伝送する方式である。
また、データ記録媒体130aに記録されている視差情報は、例えば、画像を構成するピクセル(画素)毎の視差ベクトルである。視差ベクトルの検出例について説明する。ここでは、左眼画像に対する右眼画像の視差ベクトルを検出する例について説明する。図5に示すように、左眼画像を検出画像とし、右眼画像を参照画像とする。この例では、(xi,yi)および(xj,yj)の位置における視差ベクトルが検出される。
(xi,yi)の位置における視差ベクトルを検出する場合を例にとって説明する。この場合、左眼画像に、(xi,yi)の位置の画素を左上とする、例えば4×4、8×8、あるいは16×16の画素ブロック(視差検出ブロック)Biが設定される。そして、右眼画像において、画素ブロックBiとマッチングする画素ブロックが探索される。
この場合、右眼画像に、(xi,yi)の位置を中心とする探索範囲が設定され、その探索範囲内の各画素を順次注目画素として、上述の画素ブロックBiと同様の例えば4×4、8×8、あるいは16×16の比較ブロックが順次設定されていく。
画素ブロックBiと順次設定される比較ブロックとの間で、対応する画素毎の差分絶対値の総和が求められる。ここで、図6に示すように、画素ブロックBiの画素値をL(x,y)とし、比較ブロックの画素値をR(x,y)とするとき、画素ブロックBiと、ある比較ブロックとの間における差分絶対値の総和は、Σ|L(x,y)−R(x,y)|で表される。
右眼画像に設定される探索範囲にn個の画素が含まれているとき、最終的にn個の総和S1〜Snが求められ、その中で最小の総和Sminが選択される。そして、この総和Sminが得られた比較ブロックから左上の画素の位置が(xi′,yi′)が得られる。これにより、(xi,yi)の位置における視差ベクトルは、(xi′−xi,yi′−yi)のように検出される。詳細説明は省略するが、(xj,yj)の位置における視差ベクトルについても、左眼画像に、(xj,yj)の位置の画素を左上とする、例えば4×4、8×8、あるいは16×16の画素ブロックBjが設定されて、同様の処理過程で検出される。
図2に戻って、ビデオエンコーダ112は、データ取り出し部130から取り出される立体画像データに対して、MPEG4−AVC、MPEG2、VC−1等の符号化を施し、ビデオデータストリーム(ビデオエレメンタリストリーム)を生成する。オーディオエンコーダ113は、データ取り出し部111から取り出される音声データに対して、AC3、AAC等の符号化を施し、オーディオデータストリーム(オーディオエレメンタリストリーム)を生成する。
サブタイトル発生部132は、DVB(Digital Video Broadcasting)の字幕データであるサブタイトルデータを発生する。このサブタイトルデータは、二次元画像用のサブタイトルデータである。サブタイトル発生部132は、重畳情報データ出力部を構成している。
視差情報作成部131は、データ取り出し部130から出力される視差情報、すなわちピクセル(画素)毎の視差ベクトル(水平方向視差ベクトル)に対して、ダウンサイジング処理を施し、サブタイトルデータの各ページの各リージョン領域に対応した視差ベクトルを作成する。この視差情報作成部131は、視差情報出力部を構成している。なお、サブタイトルに適用する視差情報は、ページ単位、リージョン単位、あるいはオブジェクト単位で付すことが可能である。また、この視差情報は必ずしも視差情報作成部131で生成される必要はなく、外部から別途供給される構成も可能である。
図7は、視差情報作成部131で行われるダウンサイジング処理の一例を示している。最初に、視差情報作成部134は、図7(a)に示すように、ピクセル(画素)毎の視差ベクトルを用いて、ブロック毎の視差ベクトルを求める。上述したように、ブロックは、最下層に位置するピクセル(画素)の上位層に当たり、画像(ピクチャ)領域が水平方向および垂直方向に所定の大きさで分割されることで構成される。そして、各ブロックの視差ベクトルは、例えば、そのブロック内に存在する全ピクセル(画素)の視差ベクトルから、最も値の大きな視差ベクトルが選択されることで得られる。
次に、視差情報作成部131は、図7(b)に示すように、ブロック毎の視差ベクトルを用いて、グループ(Group Of Block)毎の視差ベクトルを求める。グループは、ブロックの上位層に当たり、複数個の近接するブロックをまとめてグループ化することで得られる。図7(b)の例では、各グループは、破線枠で括られる4個のブロックにより構成されている。そして、各グループの視差ベクトルは、例えば、そのグループ内の全ブロックの視差ベクトルから、最も値の大きな視差ベクトルが選択されることで得られる。
次に、視差情報作成部131は、図7(c)に示すように、グループ毎の視差ベクトルを用いて、パーティション(Partition)毎の視差ベクトルを求める。パーティションは、グループの上位層に当たり、複数個の近接するグループをまとめてグループ化することで得られる。図7(c)の例では、各パーティションは、破線枠で括られる2個のグループにより構成されている。そして、各パーティションの視差ベクトルは、例えば、そのパーティション内の全グループの視差ベクトルから、最も値の大きな視差ベクトルが選択されることで得られる。
次に、視差情報作成部131は、図7(d)に示すように、パーティション毎の視差ベクトルを用いて、最上位層に位置するピクチャ全体(画像全体)の視差ベクトルを求める。図7(d)の例では、ピクチャ全体には、破線枠で括られる4個のパーティションが含まれている。そして、ピクチャ全体の視差ベクトルは、例えば、ピクチャ全体に含まれる全パーティションの視差ベクトルから、最も値の大きな視差ベクトルが選択されることで得られる。
このようにして、視差情報作成部131は、最下層に位置するピクセル(画素)毎の視差ベクトルにダウンサイジング処理を施して、ブロック、グループ、パーティション、ピクチャ全体の各階層の各領域の視差ベクトルを求めることができる。なお、図7に示すダウンサイジング処理の一例では、最終的に、ピクセル(画素)の階層の他、ブロック、グループ、パーティション、ピクチャ全体の4階層の視差ベクトルを求めている。しかし、階層数ならびに各階層の領域の切り方や領域の数はこれに限定されるものではない。
図2に戻って、サブタイトル処理部133は、サブタイトル発生部132で発生されたサブタイトルデータを、データ取り出し部130から取り出される立体画像データの伝送フォーマットに対応した立体画像用(三次元画像用)のサブタイトルデータに変換する。このサブタイトル処理部133は、重畳情報データ処理部を構成し、変換後の立体画像データ用のサブタイトルデータは、送信用重畳情報データを構成する。
この立体画像用のサブタイトルデータは、左眼サブタイトルのデータおよび右眼サブタイトルのデータを持っている。ここで、左眼サブタイトルのデータは、上述の立体画像データに含まれる左眼画像データに対応したデータであり、受信側において、立体画像データが持つ左眼画像データに重畳する左眼サブタイトルの表示データを発生するためのデータである。また、右眼サブタイトルのデータは、上述の立体画像データに含まれる右眼画像データに対応したデータであり、受信側において、立体画像データが持つ右眼画像データに重畳する右眼サブタイトルの表示データを発生するためのデータである。
サブタイトル処理部133は、視差情報作成部131からの各ページの各リージョン領域に対応した視差ベクトルに基づき、少なくとも、左眼サブタイトルまたは右眼サブタイトルをシフトさせて、左眼サブタイトルと右眼サブタイトルとの間に視差を付与する。このように左眼サブタイトルと右眼サブタイトルとの間に視差を付与することで、受信側においては、左眼サブタイトルと右眼サブタイトルとの間に視差を付与する処理を行わなくても、サブタイトル(字幕)の表示において、画像内の各物体との間の遠近感の整合性を最適な状態に維持できる。
また、サブタイトル処理部133は、視差情報作成部131からの各ページの各リージョン領域に対応した視差ベクトルに基づき、サブタイトル(字幕)が表示される所定数のフレーム期間の各フレームにおける左眼サブタイトルと右眼サブタイトルとの間に付与すべき視差の情報を生成する。以下、この所定数のフレーム期間の各フレームにおける視差の情報を、説明を簡単にするため、適宜、「視差情報群」と呼ぶ。この実施の形態において、視差情報群を構成する各フレームの視差の情報は、前のフレームの視差の情報に対するオフセット情報とされて、データ量が抑制される。
なお、サブタイトルデータは、PCS(page composition segment)、RSC(regioncomposition segment)、ODS(object data segment)などのセグメントにより構成されている。PCSは、ページ(page)内のリージョン(region)位置を指定する。RCSは、リージョン(Region)の大きさやオブジェクト(object)の符号化モードを指定し、また、オブジェクト(object)の開始位置を指定する。ODSは、符号化ピクセルデータ(Pixeldata)を含む。この実施の形態においては、新たなセグメントが定義され、そのセグメントに上述の視差情報群が挿入される。これにより、視差情報群は、サブタイトルデータと、セグメントタイプにより区別されることとなる。サブタイトル処理部133の処理の詳細ついては、さらに、後述する。
サブタイトルエンコーダ134は、サブタイトル処理部133から出力される立体画像用のサブタイトルデータおよび視差情報群を含むサブタイトルデータストリーム(サブタイトルエレメンタリストリーム)を生成する。マルチプレクサ122は、ビデオエンコーダ113、オーディオエンコーダ117およびサブタイトルエンコーダ134から出力される各データストリームを多重化して多重化し、ビットストリームデータ(トランスポートストリーム)BSDとしての多重化データストリームを得る。
なお、この実施の形態において、マルチプレクサ122は、サブタイトルデータストリームに、立体画像用のサブタイトルデータが含まれることを識別する識別情報を挿入する。具体的には、EIT(Event Information Table)の配下に挿入されているコンポーネント・デスクリプタ(Component_Descriptor)に、Stream_content(‘0x03’=DVB subtitles) & Component_type(for 3D target)が記述される。Component_type(for3D target)は、立体画像用のサブタイトルデータを示すために新たに定義される。
図2に示す送信データ生成部110の動作を簡単に説明する。データ取り出し部130から出力される立体画像データは、ビデオエンコーダ113に供給される。このビデオエンコーダ113では、その立体画像データに対してMPEG4−AVC、MPEG2、VC−1等の符号化が施され、符号化ビデオデータを含むビデオデータストリームが生成される。このビデオデータストリームはマルチプレクサ122に供給される。
また、データ取り出し部130から出力される音声データはオーディオエンコーダ117に供給される。このオーディオエンコーダ117では、音声データに対して、MPEG−2Audio AAC、あるいは、MPEG−4 AAC等の符号化が施され、符号化オーディオデータを含むオーディオデータストリームが生成される。このオーディオデータストリームはマルチプレクサ122に供給される。
サブタイトル発生部132では、DVBの字幕データであるサブタイトルデータ(二次元画像用)が発生される。このサブタイトルデータは、視差情報作成部131およびサブタイトル処理部133に供給される。
また、データ取り出し部130から出力される視差情報、つまりピクセル毎の視差ベクトルは視差情報作成部131に供給される。この視差情報作成部131では、ピクセル毎の視差ベクトルに対してダウンサイジング処理が施され、サブタイトルデータの各ページの各リージョン領域に対応した視差ベクトルが作成される。この各リージョンの領域に対応した視差ベクトルはサブタイトル処理部133に供給される。
サブタイトル処理部133では、サブタイトル発生部132で発生された二次元画像用のサブタイトルデータが、上述のデータ取り出し部130から取り出される立体画像データの伝送フォーマットに対応した立体画像用のサブタイトルデータに変換される。この立体画像用のサブタイトルデータは、左眼サブタイトルのデータおよび右眼サブタイトルのデータを持っている。この場合、サブタイトル処理部133では、視差情報作成部131からの各ページの各リージョン領域に対応した視差ベクトルに基づき、少なくとも、左眼サブタイトルまたは右眼サブタイトルをシフトさせて、左眼サブタイトルと右眼サブタイトルとの間に視差が付与される。あるいは、どちらか一方の眼のサブタイトルをもっており、視差情報に相当する分のオフセット位置にもう片方の眼のサブタイトル表示がなされることを意図して、片方の眼のサブタイトルに視差情報を追加して送るようなデータ生成が行われる。
また、サブタイトル処理部133では、視差情報作成部131からの各ページの各リージョン領域に対応した視差ベクトルに基づき、視差情報群(サブタイトル(字幕)が表示される所定数のフレーム期間の各フレームにおける左眼サブタイトルと右眼サブタイトルとの間に付与すべき視差の情報)が生成される。この場合、視差情報群を構成する各フレームの視差の情報は、データ量の抑制のために、前のフレームの視差の情報に対するオフセット情報とされる。
サブタイトル処理部133で得られる立体画像用のサブタイトルデータおよび視差情報群は、サブタイトルエンコーダ134に供給される。このサブタイトルエンコーダ134では、立体画像用のサブタイトルデータおよび視差情報群を含むサブタイトルデータストリームが生成される。このサブタイトルデータストリームには、立体画像用のサブタイトルデータが挿入されたPCS、RCS、ODS等のセグメントと共に、視差情報群を含む新たに定義されたセグメントが含まれる。
マルチプレクサ122には、上述したように、ビデオエンコーダ113、オーディオエンコーダ117およびサブタイトルエンコーダ134からの各データリストリームが供給される。そして、このマルチプレクサ122では、各データストリームがパケット化されて多重され、ビットストリームデータ(トランスポートストリーム)BSDとしての多重化データストリームが得られる。
図8は、トランスポートストリーム(ビットストリームデータ)の構成例を示している。このトランスポートストリームには、各エレメンタリストリームをパケット化して得られたPESパケットが含まれている。この構成例では、ビデオエレメンタリストリームのPESパケット「Video PES」、オーディオエレメンタリストリームのPESパケット「AudioPES」、サブタイトルエレメンタリストリームのPESパケット「「Subtitle PES」が含まれている。
この実施の形態において、サブタイトルエレメンタリストリーム(サブタイトルデータストリーム)には、立体画像用のサブタイトルデータが含まれる。このサブタイトルエレメンタリストリームには、PCS(page composition segment)、RCS(regioncomposition segment)、ODS(object data segment)などの従来周知のセグメントが含まれる。
図9は、PCS(page_composition_segment)の構造を示している。このPCSのセグメントタイプは、図10に示すように、「0x10」である。「region_horizontal_address」、「region_vertical_address」は、リージョン(region)の開始位置を示す。なお、RSC、ODSなどのその他のセグメントについては、その構造の図示は省略する。例えば、図10に示すように、RCSのセグメントタイプは「0x11」である。また、例えば、図10に示すように、ODSのセグメントタイプは「0x13」である。
また、このサブタイトルデータには、必要に応じて、SFI(stereo_format_indication_segment)、RCP(region_copy_segment)、OTS(offset_temporal_sequence_segment)、OSS(offset_sequence_segment)などのセグメントが含まれる。SFIは、3D拡張定義を指定する。RCPは、リージョン(Region)のコピー先の位置を定義する。OTSは、時間軸上の動的なリージョン(region)位置を制御する。OSSは、3D拡張の設定情報、視差オフセットの制御を指定する。
例えば、図10に示すように、OSSのセグメントタイプは「0x44」とされ、SFIのセグメントタイプは「0x45」とされ、RCPのセグメントタイプは「0x47」とされ、OTSのセグメントタイプは「0x48」とされる。これらのSFI、RCP、OTS、OSSの各セグメントの詳細構造については、後述する。なお、SFI、RCP、OTS、OSSをそれぞれ独立して定義することが可能である。例えば、SFIのみ、あるいはSFIとOTS、あるいは、OSSのみ存在し、それが既存のセグメントに追加されることで各々のケースに対応するものである。
また、トランスポートストリームには、PSI(Program Specific Information)として、PMT(ProgramMap Table)が含まれている。このPSIは、トランスポートストリームに含まれる各エレメンタリストリームがどのプログラムに属しているかを記した情報である。また、トランスポートストリームには、イベント単位の管理を行うSI(Serviced Information)としてのEIT(EventInformation Table)が含まれている。このEITには、番組単位のメタデータが記載される。
PMTには、プログラム全体に関連する情報を記述するプログラム・デスクリプタ(Program Descriptor)が存在する。また、このPMTには、各エレメンタリストリームに関連した情報を持つエレメンタリ・ループが存在する。この構成例では、ビデオエレメンタリ・ループ、オーディオエレメンタリ・ループ、サブタイトルエレメンタリ・ループが存在する。各エレメンタリ・ループには、ストリーム毎に、パケット識別子(PID)等の情報が配置されると共に、図示していないが、そのエレメンタリストリームに関連する情報を記述する記述子(デスクリプタ)も配置される。
EITの配下に、コンポーネント・デスクリプタ(Component_Descriptor)が挿入されている。この実施の形態において、このコンポーネント・デスクリプタに、Stream_content(‘0x03’=DVB subtitles) & Component_type(for 3D target)が記述され、サブタイトルデータストリームに立体画像用のサブタイトルデータが含まれることが識別可能とされる。この実施の形態においては、図11に示すように、配信内容を示す「component_descriptor」の「stream_content」がサブタイトル(subtitle)を示す場合に、3D用サブタイトルのフォーマットを示す情報(Component_type=0x15,0x25)が新たに定義される。
[サブタイトル処理部の処理]
図2に示す送信データ生成部110のサブタイトル処理部133の処理の詳細を説明する。このサブタイトル処理部133は、上述したように、二次元画像用のサブタイトルデータを立体画像用のサブタイトルデータに変換すると共に、サブタイトル(字幕)が表示される所定数のフレーム期間の各フレームにおける左眼サブタイトルと右眼サブタイトルとの間に付与すべき視差の情報(視差情報群)を生成する。
サブタイトル処理部133で作成されるサブタイトルデータ(視差情報群を含む)の構成は、例えば、図12に示すケースA〜Eのいずれかとされる。「ケースA」では、左眼サブタイトルのデータおよび右眼サブタイトルのデータは、同一リージョン(region)の異なるオブジェクト(object)のデータとして生成される。この「ケースA」では、図12(a)に示すように、PCS、RCS、ODS等の従来周知のセグメントと共に、新たに定義されるOTSのセグメントが用いられる。なお、図12には、従来周知のセグメントとしてPCS、RCS、ODSのセグメントのみを示しており、その他のセグメントの図示は省略している。
また、「ケースB」では、左眼サブタイトルのデータおよび右眼サブタイトルのデータは、同一のページ(page)の異なるリージョン(region)のデータとして生成される。この場合、例えば、左眼サブタイトルのデータはリージョンID(Region_id)が偶数のリージョン(region)のデータとして生成され、右眼サブタイトルのデータはリージョンID(Region_id)が奇数のリージョン(region)のデータとして生成される。この「ケースB」では、図12(b)に示すように、PCS、RCS、ODS等の従来周知のセグメントと共に、新たに定義されるSFI、OTSのセグメントが用いられる。
また、「ケースC」では、左眼サブタイトルのデータおよび右眼サブタイトルのデータは、異なるページ(page)のリージョン(region)のデータとして生成される。この場合、例えば、左眼サブタイトルのデータは、ページID(Page_id)が偶数のページ(pege)のリージョン(region)のデータとして生成される。また、右眼サブタイトルのデータは、ページID(Page_id)が奇数のページ(pege)のリージョン(region)のデータとして生成される。この「ケースC」では、図12(c)に示すように、PCS、RCS、ODS等の従来周知のセグメントと共に、新たに定義されるSFI、OTSのセグメントが用いられる。
また、「ケースD」では、左眼サブタイトルおよび右眼サブタイトルのデータのうち、一方は所定ページ(page)のリージョン(region)のデータとして生成される。また、他方はそのリージョン(region)のデータをコピーするコピーリージョン(copied_region)のデータとして生成される。この「ケースD」では、図12(d)に示すように、PCS、RCS、ODS等の従来周知のセグメントと共に、新たに定義されるRCP、OTSのセグメントが用いられる。
また、「ケースE」では、立体画像データの伝送フォーマットに応じて、左眼サブタイトルのデータおよび右眼サブタイトルのデータが生成される。例えば、伝送フォーマットがサイド・バイ・サイド方式である場合、左眼サブタイトルのデータおよび右眼サブタイトルのデータは、同一ページ(page)の同一リージョン(region)のデータとして生成される。その際、左眼サブタイトル、右眼サブタイトルに対応するリージョン内の所定位置にオブジェクトが配置されるよう設定される。また、例えば、伝送フォーマットがトップ・アンド・ボトム方式である場合、左眼サブタイトルのデータおよび右眼サブタイトルのデータは、同一のページ(page)の異なるリージョン(region)のデータとして生成される。この「ケースE」では、図12(e)に示すように、PCS、RCS、ODS等の従来周知のセグメントと共に、新たに定義されるOSSのセグメントが用いられる。
[ケースAについて]
図13は、「ケースA」の立体画像用のサブタイトルデータの作成方法を概念的に示している。ここでは、立体画像データの伝送フォーマットがサイド・バイ・サイド方式の場合について述べる。図13(a)は、二次元画像用のサブタイトルデータによるリージョン(region)を示している。
最初に、サブタイトル処理部133は、上述の二次元画像用のサブタイトルデータによるリージョン(region)のサイズを、図13(b)に示すように、サイド・バイ・サイド方式に適したサイズに変換し、そのサイズのビットマップデータを発生させる。
次に、サブタイトル処理部133は、図13(c)に示すように、サイズ変換後のビットマップデータを立体画像用のサブタイトルデータのリージョン(region)の構成要素とする。その際、各オブジェクトの開始位置(region_horizontal_address)は、左眼画像(left view )と右眼画像(right view)との視差(disparity)に相当する分(A-B= disparity/2)だけ、ずらした位置とされる。
サブタイトル処理部133は、上述したようにして、二次元画像用のサブタイトルデータを、立体画像用のサブタイトルデータに変換し、この立体画像用のサブタイトルデータに対応したPCS、RCS、ODSなどのセグメントを作成する。
図14は、「ケースA」で作成される立体画像用のサブタイトルデータによるリージョン(region)およびオブジェクト(object)の一例を示している。ここで、リージョンの開始位置は“Region_horizontal_address1”である。そして、左眼画像(leftview )側のオブジェクトに関しては、開始位置は“object_horizontal_position”であり、“Object_id=1”である。また、右眼画像(Right view )側のオブジェクトに関しては、開始位置は“object_horizontal_position2”であり、“Object_id=2”である。
図15は、「ケースA」における各セグメントの作成例(例1)を示している。この作成例において、PCS(page composition segment)では、リージョン(Region_id=0A)の開始位置(region_horizontal_address)が指定されている。また、“Region_id=0A”のRCS(region composition segment)では、“Object_id=1”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position1”が指定されている。また、この“Region_id=0A”のRCS(region composition segment)では、Object_id=2”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position2”が指定されている。なお、この作成例(例1)では、OTSのセグメントは作成されていない。
図16は、「ケースA」における各セグメントの作成例(例2)を示している。この作成例において、図15に示す作成例(例1)と同様にPCS、RCS、ODSのセグメントが作成される他に、OTS(offset_temporal_sequence_segment)のセグメントも作成される。このOTSのセグメントには、視差情報群が挿入されている。この視差情報群は、上述したように、サブタイトル(字幕)が表示される所定数のフレーム期間の各フレームにおける左眼サブタイトルと右眼サブタイトルとの間に付与すべき視差の情報である。ここで、視差情報群を構成する各フレームの視差の情報は、データ量の抑制のために、前のフレームの視差の情報に対するオフセット情報とされる。
図17は、OTS(offset_temporal_sequence_segment)の構造例(syntax)を示している。図18は、OTSの主要なデータ規定内容(semantics)を示している。この構造には、「Sync_byte」、「segment_type」、「page_id」、「segment_length」の各情報が含まれている。「segment_type」は、セグメントタイプを示す8ビットのデータであり、ここでは、OTSを示す「0x48」とされている。「segment_length」は、セグメントの長さ(サイズ)を示す8ビットのデータである。このデータは、セグメントの長さとして、「segment_length」以降のバイト数を示す。
また、「region_count」は、ページ(page)内のリージョン(region)の個数を示している。このOTSには、リージョン(region)の個数分だけ、「region_id」で区別されて、各リージョン(region)の視差情報群が挿入されている。frame_count」は、表示フレーム期間中offset_sequenceを供給するフレーム数を示すものである。
「offset_sequence」は、前のフレームの視差情報に対するオフセット情報としての2ビットの情報である。「offset_sequence=01」は、オフセット値が「+1」であることを示す。「offset_sequence=10」は、オフセット値が「−1」であることを示す。さらに、「offset_sequence=11」は、オフセット値が前のフレームから変化していないことを示す。「offset_precision」は、上述の「offset_sequence」で示すオフセット値における「1」の精度、つまりこの「1」のピクセル数を示す1ビットの情報である。「offset_precision=0」であるとき、オフセット値における「1」が1ピクセルであることを示す。また、「offset_precision=1」であるとき、オフセット値における「1」が2ピクセルであることを示す。
上述したように、サブタイトルデータストリームにOTSが含まれる場合、受信側においては、所定数のフレーム期間の各フレームにおけるオフセット値“offset_sequence”に基づいて、左眼サブタイトルと右眼サブタイトルとの間に所定の視差を付与することが可能となる。例えば、受信側においては、左眼サブタイトルと右眼サブタイトルとの間の視差を順次更新することが可能となる。
この場合、受信側においては、OTSにより、後方互換を維持して、オブジェクト開始位置“object_horizontal_position”を簡便にフレーム単位で更新することが可能となる。すなわち、“object_horizontal_position”は、フレームT0(初期フレーム)の初期位置(initial position)に対し、“offset_sequence(T)”で指定される差分量が各フレームで加えられていくことで、“Object_id”単位で更新される。これにより、サブタイトルが表示される所定数のフレーム期間において、左眼サブタイトルと右眼サブタイトルとの間の視差が順次更新される。
図19は、オブジェクト開始位置“object_horizontal_position”をフレーム単位で更新する例を示している。フレームT0(初期フレーム)において、“Object_id=1”のオブジェクト開始位置は“object_horizontal_position1(T0)”であり、“Object_id=2”のオブジェクト開始位置は“object_horizontal_position2(T0)”であるとする。
次フレームであるフレームT1のオブジェクト開始位置は、以下のように更新される。なお、このフレームT1のオフセット値は“offset_sequence(T1)”であるとする。すなわち、“Object_id=1”のオブジェクト開始位置“object_horizontal_position1(T1)”は、“object_horizontal_position1(T0)+ offset_sequence(T1)”とされる。また、“Object_id=2”のオブジェクト開始位置“object_horizontal_position2(T1)”は、“object_horizontal_position2(T0)- offset_sequence(T1)”とされる。
また、次フレームであるフレームT2のオブジェクト開始位置は、以下のように更新される。なお、このフレームT2のオフセット値は“offset_sequence(T2)”であるとする。すなわち、“Object_id=1”のオブジェクト開始位置“object_horizontal_position1(T2)”は、“object_horizontal_position1(T1)+ offset_sequence(T2)”とされる。また、“Object_id=2”のオブジェクト開始位置“object_horizontal_position2(T2)”は、“object_horizontal_position2(T1)- offset_sequence(T2)”とされる。以下、同様にして、各フレームのオブジェクト開始位置が“Object_id”単位で求められて更新される。
また、例えば、受信側においては、左眼サブタイトルと右眼サブタイトルとの間に、所定数のフレーム期間の代表値、例えば最大値、平均値等による視差を付与することが可能となる。この場合、受信側においては、各フレームのオフセット値“offset_sequence(T)”に基づいて、そのフレームまでのオフセット値の累積値が予め計算される。そして、受信側においては、各フレームの累積値のうち、最大値“Max ( offset_sequence(n) ) ”、あるいは平均値“Ave (offset_sequence(n) ) ”が、フレームT0(初期フレーム)の初期位置(initialposition)に対して加えられる。これにより、サブタイトルが表示される所定数のフレーム期間において、左眼サブタイトルと右眼サブタイトルとの間に、所定数のフレーム期間の最大値あるいは平均値による視差が付与される。
図20は、オブジェクト開始位置“object_horizontal_position”を最初に最大値“Max (offset_sequence(n) ) ”に基づいて設定し、その後はその位置を維持する例を示している。“Object_id=1”のオブジェクト開始位置の初期位置は“object_horizontal_position1”であり、“Object_id=2”のオブジェクト開始位置の初期位置は“object_horizontal_position2”であるとする。
フレームT0(初期フレーム)において、オブジェクト開始位置は、以下のように設定される。すなわち、“Object_id=1”のオブジェクト開始位置“object_horizontal_position1(T0)”は、“object_horizontal_position1 + Max ( offset_sequence(n)”に設定される。また、“Object_id=2”のオブジェクト開始位置“object_horizontal_position2(T0)”は、“object_horizontal_position2 - Max ( offset_sequence(n)”に設定される。そして、以下のフレームでは、この“Object_id=1”、“Object_id=2”のオブジェクト開始位置が維持される。
[ケースBについて]
図21は、「ケースB」の立体画像用のサブタイトルデータの作成方法を概念的に示している。ここでは、立体画像データの伝送フォーマットがサイド・バイ・サイド方式の場合について述べる。図21(a)は、二次元画像用のサブタイトルデータによるリージョン(region)を示している。
最初に、サブタイトル処理部133は、上述の二次元画像用のサブタイトルデータによるリージョン(region)のサイズを、図21(b)に示すように、サイド・バイ・サイド方式に適したサイズに変換し、そのサイズのビットマップデータを発生させる。
次に、サブタイトル処理部133は、図21(c)に示すように、サイズ変換後のビットマップデータを立体画像用のサブタイトルデータの各リージョン(region)の構成要素とする。その際、各リージョン(region)のオブジェクト(object)の開始位置(object_horizontal_position)は、左眼画像(left view )と右眼画像(right view)との視差(disparity)に相当する分(A-B= disparity/2)だけ、ずらした位置とされる。
サブタイトル処理部133は、上述したようにして、二次元画像用のサブタイトルデータを、立体画像用のサブタイトルデータに変換し、この立体画像用のサブタイトルデータに対応したPCS、RCS、ODSなどのセグメントを作成する。
図22は、「ケースB」で作成される立体画像用のサブタイトルデータによるリージョン(region)およびオブジェクト(object)の一例を示している。ここで、左眼画像(left view )側のリージョンの開始位置は、“Region_horizontal_address1”であり、オブジェクト(object)の開始位置は“object_horizontal_position1”であり、“Object_id=1”である。また、右眼画像(right view )側のリージョンの開始位置は、“Region_horizontal_address2”であり、オブジェクト(object)の開始位置は“object_horizontal_position2”であり、“Object_id=1”である。なお、この例は、左眼サブタイトルおよび右眼サブタイトルのビットマップデータとして共通のビットマップデータが使用される例である。
図23は、「ケースB」における各セグメントの作成例(例1)を示している。この作成例において、PCS(page composition segment)では、左眼画像(left view)側のリージョン(Region_id=0A)と右眼画像(right view)側のリージョン(Region_id=0B)の開始位置(region_horizontal_address)が指定されている。また、“Region_id=0A”のRCS(region composition segment)では、“Object_id=1”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position1”が指定されている。また、“Region_id=0B”のRCS(region composition segment)では、“Object_id=1”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position2”が指定されている。
図24は、「ケースB」における各セグメントの作成例(例2)を示している。なお、この作成例は、左眼サブタイトルおよび右眼サブタイトルのビットマップデータとして異なるビットマップデータの使用を可能とする例である。この作成例において、PCS(page composition segment)では、左眼画像(left view)側のリージョン(Region_id=0A)と右眼画像(right view)側のリージョン(Region_id=0B)の開始位置(region_horizontal_address)が指定されている。
また、“Region_id=0A”のRCS(region composition segment)では、“Object_id=1”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position1”が指定されている。また、“Region_id=0B”のRCS(region composition segment)では、“Object_id=2”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position2”が指定されている。
図25は、「ケースB」における各セグメントの作成例(例3)を示している。この作成例において、図23に示す作成例(例1)と同様にPCS、RCS、ODSのセグメントが作成される他に、OTS(offset_temporal_sequence_segment)のセグメントも作成される。
OTSのセグメントには、視差情報群が挿入されている。この視差情報群は、上述したように、サブタイトル(字幕)が表示される所定数のフレーム期間の各フレームにおける左眼サブタイトルと右眼サブタイトルとの間に付与すべき視差の情報である。ここで、視差情報群を構成する各フレームの視差の情報は、データ量の抑制のために、前のフレームの視差の情報に対するオフセット情報とされる。このOTSのセグメントの構造およびそれによる効果については、上述の「ケースA」で説明した通りであり、ここでは、その説明を省略する。
なお、「ケースB」では、上述の新たに定義されるSFI(stereo_format_indication_segment)のセグメントも作成される。このSFIのセグメントは、上述したように、3D拡張定義を指定する。図26は、SFIの構造例(syntax)を示している。図27は、SFIの主要なデータ規定内容(semantics)を示している。この構造には、「Sync_byte」、「segment_type」、「page_id」、「segment_length」の各情報が含まれている。「segment_type」は、セグメントタイプを示す8ビットのデータであり、ここでは、SFIを示す「0x45」とされている(図10参照)。「segment_length」は、セグメントの長さ(サイズ)を示す8ビットのデータである。このデータは、セグメントの長さとして、「segment_length」以降のバイト数を示す。
「page_composition_view_allocated」は、ページID「page_id」の数値(偶数、奇数)が左眼画像および右眼画像に割り当てられているか否かを示す1ビットデータである。「page_composition_view_allocated=1」であるとき、偶数値の「page_id」は左眼画像(left view)に割り当てられ、奇数値の「page_id」は右眼画像(right view)に割り当てられることを示す。一方、「page_composition_view_allocated=0」であるとき、ページID「page_id」に、特定の規則が存在しないことを示す。
また、「shared_region_flag」は、左眼画像および右眼画像のリージョン(region)でオブジェクト(Object)を共有するか否かを示す1ビットデータである。「shared_region_flag=1」は、左眼画像および右眼画像のリージョン(region)でオブジェクト(Object)を共有することを示す。なお、「ケースC」では、「ページID「page_id」の数値は、左眼画像(left view)を表すために偶数とされ、右眼画像(right view)を表すために奇数とされている。共通に参照されるODS内のページID「page_id」は、左眼画像(left view)および右眼画像(right view)を表す一対のページID「page_id」のうち、小さな方の数値で特定される。一方、「shared_region_flag=0」は、左眼画像および右眼画像のリージョン(region)でオブジェクト(Object)を共有しないことを示す。
また、「region_composition_view_allocated」は、リージョンID「region_id」の数値(偶数、奇数)が左眼画像および右眼画像に割り当てられているか否かを示す1ビットデータである。「region_composition_view_allocated=1」であるとき、偶数値の「region_id」は左眼画像(left view)に割り当てられ、奇数値の「region_id」は右眼画像(right view)に割り当てられることを示す。一方、「region_composition_view_allocated=0」であるとき、リージョンID「region_id」に、特定の規則が存在しないことを示す。
また、「target_stereo_format」は、サブタイトルデータがターゲットとする画像データを示す3ビットデータである。「000」は、フル・フレーム(Full Frame)方式あるいはバックワード・コンパチブル(Backward Compatible)方式の立体画像データであることを示す。また、「001」は、サイド・バイ・サイド(Side By Side)方式の立体画像データであることを示す。また、「010」は、トップ・アンド・ボトム(Top & Bottom)方式の立体画像データであることを示す。また、「111」は、立体画像データではなく、二次元画像データであることを示す。
なお、図26のSFIの構造例(syntax)において、「region_composition_view_allocated」、「shared_region_flag」および「target_stereo_format」は、「ケースB」に関係する。一方、「page_composition_view_allocated」、「shared_region_flag」および「target_stereo_format」は、「ケースC」に関係する。したがって、「ケースB」の場合、「page_composition_view_allocated=0」とされる。また、「ケースC」の場合、「region_composition_view_allocated=0」とされる。
[ケースCについて]
図28は、「ケースC」の立体画像用のサブタイトルデータの作成方法を概念的に示している。ここでは、立体画像データの伝送フォーマットがサイド・バイ・サイド方式の場合について述べる。図28(a)は、二次元画像用のサブタイトルデータによるリージョン(region)を示している。
最初に、サブタイトル処理部133は、上述の二次元画像用のサブタイトルデータによるリージョン(region)のサイズを、図28(b)に示すように、サイド・バイ・サイド方式に適したサイズに変換し、そのサイズのビットマップデータを発生させる。
次に、サブタイトル処理部133は、図28(c),(d)に示すように、サイズ変換後のビットマップデータを立体画像用のサブタイトルデータの各ページのリージョン(region)の構成要素とする。その際、各オブジェクトの開始位置(region_horizontal_address)は、左眼画像(left view )と右眼画像(right view)との視差(disparity)に相当する分(A-B= disparity/2)だけ、ずらした位置とされる。
サブタイトル処理部133は、上述したようにして、二次元画像用のサブタイトルデータを、立体画像用のサブタイトルデータに変換し、この立体画像用のサブタイトルデータに対応したPCS、RCS、ODSなどのセグメントを作成する。
図29は、「ケースC」で作成される立体画像用のサブタイトルデータによるリージョン(region)およびオブジェクト(object)の一例を示している。ここで、左眼画像(left view )側のページ(Page_id=even number)のリージョンの開始位置は、“Region_horizontal_address1”である。そして、そのオブジェクト(object)の開始位置は“object_horizontal_position1”であり、“Object_id=1”である。また、右眼画像(right view )側のページ(Page_id=odd number)のリージョンの開始位置は、“Region_horizontal_address2”である。そして、そのオブジェクト(object)の開始位置は“object_horizontal_position2”であり、“Object_id=1”である。なお、この例は、左眼サブタイトルおよび右眼サブタイトルのビットマップデータとして共通のビットマップデータが使用される例である。
図30は、「ケースC」における各セグメントの作成例(例1)を示している。この作成例において、左眼画像(left view)側のPCS(page composition segment)では、リージョン(Region_id=0A)の開始位置(region_horizontal_address1)が指定されている。また、“Region_id=0A”のRCS(region composition segment)では、“Object_id=1”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position1”が指定されている。
また、この作成例において、右眼画像(right view)側のPCS(page composition segment)では、リージョン(Region_id=0B)の開始位置(region_horizontal_address2)が指定されている。また、“Region_id=0B”のRCS(region composition segment)では、“Object_id=1”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position2”が指定されている。
図31は、「ケースC」における各セグメントの作成例(例2)を示している。この作成例は、左眼サブタイトルおよび右眼サブタイトルのビットマップデータとして異なるビットマップデータの使用を可能とする例である。この作成例において、左眼画像(left view)側のPCS(page composition segment)では、リージョン(Region_id=0A)の開始位置(region_horizontal_address1)が指定されている。また、“Region_id=0A”のRCS(region composition segment)では、“Object_id=1”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position1”が指定されている。
また、この作成例において、右眼画像(right view)側のPCS(page composition segment)では、リージョン(Region_id=0B)の開始位置(region_horizontal_address2)が指定されている。また、“Region_id=0B”のRCS(region composition segment)では、“Object_id=2”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position2”が指定されている。
図32は、「ケースC」における各セグメントの作成例(例3)を示している。この作成例は、左眼画像(left view)側および右眼画像(right view)側のPCSで、共通のRCSを参照する例である。この作成例において、左眼画像(left view)側のPCS(page composition segment)では、リージョン(Region_id=0A)のRCSが参照され、開始位置(region_horizontal_address1)が指定されている。また、右眼画像(right view)側のPCS(page composition segment)でも、リージョン(Region_id=0A)のRCSが参照され、開始位置(region_horizontal_address2)が指定されている。そして、“Region_id=0A”のRCS(region composition segment)では、“Object_id=1”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position1”が指定されている。
図33は、「ケースC」における各セグメントの作成例(例4)を示している。この作成例において、図30に示す作成例(例1)と同様にPCS、RCS、ODSのセグメントが作成される他に、OTS(offset_temporal_sequence_segment)のセグメントも作成される。
OTSのセグメントには、視差情報群が挿入されている。この視差情報群は、上述したように、サブタイトル(字幕)が表示される所定数のフレーム期間の各フレームにおける左眼サブタイトルと右眼サブタイトルとの間に付与すべき視差の情報である。ここで、視差情報群を構成する各フレームの視差の情報は、データ量の抑制のために、前のフレームの視差の情報に対するオフセット情報とされる。このOTSのセグメントの構造およびそれによる効果については、上述の「ケースA」で説明した通りであり、ここでは、その説明を省略する。
なお、「ケースC」では、上述の新たに定義されるSFI(stereo_format_indication_segment)のセグメントも作成される。このSFIのセグメントは、3D拡張定義を指定するものであり、「page_composition_view_allocated」、「region_composition_view_allocated」、「shared_region_flag」、「target_stereo_format」などの情報を含んでいる。このSFIのセグメントの構造については、上述の「ケースB」で説明した通りであり、ここでは、その説明を省略する。上述したように、「region_composition_view_allocated」は「ケースB」にのみ関係するので、ここでは、「region_composition_view_allocated=0」とされる。
[ケースDについて]
図34は、「ケースD」の立体画像用のサブタイトルデータの作成方法を概念的に示している。ここでは、立体画像データの伝送フォーマットがサイド・バイ・サイド方式の場合について述べる。図34(a)は、二次元画像用のサブタイトルデータによるリージョン(region)を示している。
最初に、サブタイトル処理部133は、上述の二次元画像用のサブタイトルデータによるリージョン(region)のサイズを、図34(b)に示すように、サイド・バイ・サイド方式に適したサイズに変換し、そのサイズのビットマップデータを発生させる。
次に、サブタイトル処理部133は、図34(c)に示すように、サイズ変換後のビットマップデータを左眼画像(left view )側のリージョン(region)および右眼画像(right view)側のコピーリージョン(Copied_region)の構成要素とする。その際、各リージョン(region)のオブジェクト(object)の開始位置(object_horizontal_position)は、左眼画像(left view)と右眼画像(right view)との視差(disparity)に相当する分(A-B= disparity/2)だけ、ずらした位置とされる。
サブタイトル処理部133は、上述したようにして、二次元画像用のサブタイトルデータを、立体画像用のサブタイトルデータに変換し、この立体画像用のサブタイトルデータに対応したPCS、RCS、ODSなどのセグメントを作成する。
図35は、「ケースD」で作成される立体画像用のサブタイトルデータによるリージョン(region,copied_region)およびオブジェクト(object)の一例を示している。ここで、左眼画像(left view )側のリージョン(region)の開始位置は、“Region_horizontal_address”であり、オブジェクト(object)の開始位置は“object_horizontal_position”であり、“Object_id=1”である。また、右眼画像(Right view )側のコピーリージョン(copied_region)の開始位置は、左眼画像(left view )側のオブジェクト(object)の開始位置から(A-B= disparity/2)だけずらされる。そのため、後述するRCP(region_copy_segment)のセグメントにおいて、“Offset_distance_horizontal=(A-B)”とされる。
この「ケースD」においては、図12に示すように、PCS、RCS、ODSのセグメントが作成される他に、RCP(region_copy_segment)およびOTS(offset_temporal_sequence_segment)のセグメントも作成される。OTSのセグメントの構造およびそれによる効果については、上述の「ケースA」で説明した通りであり、ここでは、その説明を省略する。
RCP(region_copy_segment)は、上述したように、リージョン(region)のコピー先の位置を指定する。図36は、RCP(region_copy_segment)の構造例(syntax)を示している。図37は、RCPの主要なデータ規定内容(semantics)を示している。この構造には、「Sync_byte」、「segment_type」、「page_id」、「segment_length」の各情報が含まれている。「segment_type」は、セグメントタイプを示す8ビットのデータであり、ここでは、RCPを示す「0x47」とされている(図10参照)。「segment_length」は、セグメントの長さ(サイズ)を示す8ビットのデータである。このデータは、セグメントの長さとして、「segment_length」以降のバイト数を示す。
「region_count」は、ページ(page)内のリージョンの個数を示す8ビットデータである。「copied_region_id」は、リージョン(region)のコピーで生成されたコピーリージョン(copied_region)のIDを示す8ビットデータである。
「offset_precision」は、「offset_distance_horizontal」で示すオフセット値における「1」の精度、つまりこの「1」のピクセル数を示す1ビットの情報である。「offset_precision=0」であるとき、オフセット値における「1」が1ピクセルであることを示す。また、「offset_precision=1」であるとき、オフセット値における「1」が2ピクセルであることを示す。「offset_distance_horizontal」は、左眼画像(left view)側のオブジェクトとコピーされる右眼画像(right view)側のオブジェクトとの間に付与すべき視差(A−B)を示す8ビットデータである。この「offset_distance_horizontal」は、−128〜127の範囲の値をとる。
図38は、「ケースD」における各セグメントの作成例(例1)を示している。この作成例において、PCS(page composition segment)では、左眼画像(left view)側のリージョン(Region_id=0A)の開始位置(region_horizontal_address)が指定されている。そして、“Region_id=0A”のRCS(region composition segment)では、“Object_id=1”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position”が指定されている。
また、RCP(region_copy_segment)では、“Region_id=0A”のリージョンが参照され、このリージョンをコピーすることが示されている。このRCPには、さらに、「copied_region_id」が定義されており、「offset_distance_horizontal」の情報が含まれている。
図39は、「ケースD」における各セグメントの作成例(例2)を示している。この作成例において、図38に示す作成例(例1)と同様にPCS、RCS、ODS、RCPのセグメントが作成される他に、OTS(offset_temporal_sequence_segment)のセグメントも作成される。このOTSのセグメントの構造およびその効果については、上述の「ケースA」で説明した通りであり、ここではその説明を省略する。
[ケースEについて]
「ケースE」においては、上述の図12に示すように、PCS、RCS、ODSのセグメントが作成される他に、OSS(offset_sequence_segment)のセグメントも作成される。
OSS(offset_sequence_segment)は、上述したように、3D拡張の設定情報、視差オフセットの制御を指定する。図40は、OSSの構造例(syntax)を示している。図41は、OSSの主要なデータ規定内容(semantics)を示している。この構造には、「Sync_byte」、「segment_type」、「page_id」、「segment_length」の各情報が含まれている。「segment_type」は、セグメントタイプを示す8ビットのデータであり、ここでは、RCPを示す「0x44」とされている(図10参照)。「segment_length」は、セグメントの長さ(サイズ)を示す8ビットのデータである。このデータは、セグメントの長さとして、「segment_length」以降のバイト数を示す。
「region_position_offset_allocated」は、視差オフセット値が、“region_position”に反映されているかどうかを示す1ビットデータである。「region_position_offset_allocated=1」は、視差オフセット値が“region_position”に反映されていることを示す。この場合、左眼画像(leftview)のリージョン(region)に対する右眼画像(rightview)のリージョン(region)のオフセットとして、画素単位で双方の“region_horizontal_address”に反映されている。例えば、左眼画像(leftview)のリージョン(region)の“region_id”は偶数とされ、右眼画像(right view)のリージョン(region)の“region_id”は奇数とされている。一方、「region_position_offset_allocated=0」は、視差オフセット値が“region_position”に反映されていないことを示す。
「object_position_allocated」は、視差オフセット値が、“object_horizontal_position”に反映されているかどうかを示す1ビットデータである。「object_position_allocated=1」は、視差オフセット値が、“object_horizontal_position”に反映されていることを示す。この場合、左眼画像(left view)のオブジェクト(object)に対する右眼画像(right view)のオブジェクト(object)のオフセットとして、画素単位で双方の“object_horizontal_position”に反映されている。一方、「object_position_allocated=0」は、視差オフセット値が、“object_horizontal_position”に反映されていないことを示す。
「target_stereo_format」は、サブタイトルデータがターゲットとする画像データを示す3ビットデータである。「000」は、フル・フレーム(Full Frame)方式またはバックワード・コンパチブル(Backward Compatible)方式の立体画像データであることを示す。また、「001」は、サイド・バイ・サイド(Side By Side)方式の立体画像データであることを示す。また、「010」は、トップ・アンド・ボトム(Top & Bottom)方式の立体画像データであることを示す。また、「111」は、特定の立体画像をターゲットとするわけではなく、従来の二次元画像を含む画像データ一般が対象となるという意味を含む。
「Temporal_sequence_flag」は、時間方向の更新情報が含まれるか否かを示す1ビットデータである。「Temporal_sequence_flag=1」は、時間方向の更新情報が含まれることを示す。「Temporal_sequence_flag=0」は、時間方向の更新情報が含まれていないことを示す。「region_count」は、視差情報が伝送されるリージョン(region)の個数を示す8ビットデータである。「region_id」は、視差情報が伝送されるリージョン(region)のIDを示す。「Disparity_offset」は、左眼サブタイトルと右眼サブタイトルとの間の画素単位の符号付き8ビット視差情報である。OSSには、リージョン(region)の個数分だけ、「region_id」で区別されて、「Disparity_offset」が挿入されている。
また、OSSには、「Temporal_sequence_flag=1」であるとき、リージョン(region)の個数分だけ、「region_id」で区別されて、各リージョン(region)の視差情報群が挿入されている。「frame_count」は、表示フレーム期間中offset_sequenceを供給するフレーム数を示すものである。
「offset_sequence」は、視差情報に関する、前の状態からの差分値を示し、前のフレームの視差情報に対するオフセット情報としての2ビットの情報である。「offset_sequence=01」は、オフセット値が「+1」であることを示す。「offset_sequence=10」は、オフセット値が「−1」であることを示す。さらに、「offset_sequence=11」は、オフセット値が前のフレームから変化していないことを示す。「offset_precision」は、時間方向の更新情報の値の画素精度を指定する1ビットの情報である。つまり、この「offset_precision」は、上述の「offset_sequence」で示すオフセット値における「1」の精度、つまりこの「1」が示すピクセル数を示す。「offset_precision=0」であるとき、オフセット値における「1」が1ピクセルであることを示す。また、「offset_precision=1」であるとき、オフセット値における「1」が2ピクセルであることを示す。
図42は、「ケースE(Side-by-Side)」の立体画像用のサブタイトルデータの作成方法を概念的に示している。この場合、左眼サブタイトルのデータおよび右眼サブタイトルのデータは、同一のリージョンの異なるオブジェクトのデータとして生成される。図42(a)は、二次元画像用のサブタイトルデータによるリージョン(region)を示している。
最初に、サブタイトル処理部133は、上述の二次元画像用のサブタイトルデータによるリージョン(region)のサイズを、図42(b)に示すように、サイド・バイ・サイド方式に適したサイズに変換し、そのサイズのビットマップデータを発生させる。
次に、サブタイトル処理部133は、図42(c)に示すように、サイズ変換後のビットマップデータを立体画像用のサブタイトルデータのリージョン(region)の構成要素とする。その際、各オブジェクトの開始位置(region_horizontal_address)は、左眼画像(left view )と右眼画像(right view)との視差(disparity)に相当する分(A-B= disparity/2)だけ、あるいは、(A-B = disparity) だけ、対象となる画像の左眼画像、右眼画像各々の基準位置よりずらした位置とされる。
サブタイトル処理部133は、上述したようにして、二次元画像用のサブタイトルデータを、立体画像用のサブタイトルデータに変換し、この立体画像用のサブタイトルデータに対応したPCS、RCS、ODSなどのセグメントを作成する。
図43は、「ケースE(Side-by-Side)」で作成される立体画像用のサブタイトルデータによるリージョン(region)およびオブジェクト(object)の一例を示している。ここで、リージョンの開始位置は“Region_horizontal_address”である。そして、左眼画像(left view )側のオブジェクトに関しては、開始位置は“object_horizontal_position1”であり、“Object__id=1”である。また、右眼画像(right view )側のオブジェクトに関しては、開始位置は“object_horizontal_position2”であり、“Object_id=2”である。なお、“Object_id=2”をobject_id=1 とし、左眼画像と右眼画像とで同一のobject dataを共有し、object_horizontal_positionのみを左眼画像と右眼画像とで違えることもできる。
図44は、「ケースE(Side-by-Side)」における各セグメントの作成例を示している。この場合、OSSのセグメントでは、「region_position_offset_allocated=0」、「object_position_allocated=1」、「target_stereo_format=001」に設定されている。この作成例において、PCS(page composition segment)では、リージョン(Region_id=0A)の開始位置(region_horizontal_address)が指定されている。また、“Region_id=0A”のRCS(region composition segment)では、“Object_id=1”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position1”が指定されている。また、この“Region_id=0A”のRCS(region composition segment)では、Object_id=2”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position2”が指定されている。また、この作成例において、OSS(offset_sequence_segment)では、“Region_id=0A”とされている。
図45も、「ケースE(Side-by-Side)」における各セグメントの作成例を示している。この場合、OSSのセグメントでは、「region_position_offset_allocated=0」、「object_position_allocated=1」、「target_stereo_format=001」に設定されている。この作成例において、PCS(page composition segment)では、リージョン(Region_id=0A)の開始位置(region_horizontal_address)が指定されている。また、“Region_id=0A”のRCS(region composition segment)では、“Object_id=1”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position1”が指定されている。また、この“Region_id=0A”のRCS(region composition segment)では、さらに、“Object_id=1”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position2”が指定されている。また、この作成例において、OSS(offset_sequence_segment)では、“Region_id=0A”とされている。
上述したように、OSSのセグメントには、視差情報群(オフセット値“offset_sequence”)が挿入されている。この視差情報群は、上述したように、サブタイトル(字幕)が表示される所定数のフレーム期間の各フレームにおける左眼サブタイトルと右眼サブタイトルとの間に付与すべき視差の情報である。受信側においては、所定数のフレーム期間の各フレームにおけるオフセット値“offset_sequence”に基づいて、左眼サブタイトルと右眼サブタイトルとの間に所定の視差を付与することが可能となる。例えば、受信側においては、左眼サブタイトルと右眼サブタイトルとの間の視差を順次更新することが可能となる。
この場合、受信側においては、後方互換を維持して、オブジェクト開始位置“object_horizontal_position”を簡便にフレーム単位で更新することが可能となる。すなわち、“object_horizontal_position”は、フレームT0(初期フレーム)の初期位置(initial position)に対し、“offset_sequence(T)”で指定される差分量が各フレームで加えられていくことで、“Object_id”単位で更新される。これにより、サブタイトルが表示される所定数のフレーム期間において、左眼サブタイトルと右眼サブタイトルとの間の視差が順次更新される。
図46は、オブジェクト開始位置“object_horizontal_position”をフレーム単位で更新する例を示している。フレームT0(初期フレーム)において、“Object_id=1”のオブジェクト開始位置は“object_horizontal_position1(T0)”であり、“Object_id=2”のオブジェクト開始位置は“object_horizontal_position2(T0)”であるとする。
次フレームであるフレームT1のオブジェクト開始位置は、以下のように更新される。なお、このフレームT1のオフセット値は“offset_sequence(T1)”であるとする。すなわち、“Object_id=1”のオブジェクト開始位置“object_horizontal_position1(T1)”は、“object_horizontal_position1(T0)+ offset_sequence(T1)”とされる。また、“Object_id=2”のオブジェクト開始位置“object_horizontal_position2(T1)”は、“object_horizontal_position2(T0)- offset_sequence(T1)”とされる。
また、次フレームであるフレームT2のオブジェクト開始位置は、以下のように更新される。なお、このフレームT2のオフセット値は“offset_sequence(T2)”であるとする。すなわち、“Object_id=1”のオブジェクト開始位置“object_horizontal_position1(T2)”は、“object_horizontal_position1(T1)+ offset_sequence(T2)”とされる。また、“Object_id=2”のオブジェクト開始位置“object_horizontal_position2(T2)”は、“object_horizontal_position2(T1)- offset_sequence(T2)”とされる。以下、同様にして、各フレームのオブジェクト開始位置がオブジェクト単位で求められて更新される。
また、例えば、受信側においては、左眼サブタイトルと右眼サブタイトルとの間に、所定数のフレーム期間の代表値、例えば最大値、平均値等による視差を付与することが可能となる。この場合、受信側においては、各フレームのオフセット値“offset_sequence(T)”に基づいて、そのフレームまでのオフセット値の累積値が予め計算される。そして、受信側においては、各フレームの累積値のうち、最大値“Max ( offset_sequence(n) ) ”、あるいは平均値“Ave (offset_sequence(n) ) ”が、フレームT0(初期フレーム)の初期位置(initialposition)に対して加えられる。これにより、サブタイトルが表示される所定数のフレーム期間において、左眼サブタイトルと右眼サブタイトルとの間に、所定数のフレーム期間の最大値あるいは平均値による視差が付与される。
図47は、オブジェクト開始位置“object_horizontal_position”を最初に最大値“Max (offset_sequence(n) ) ”に基づいて設定し、その後はその位置を維持する例を示している。“Object_id=1”のオブジェクト開始位置の初期位置は“object_horizontal_position1”であり、“Object_id=2”のオブジェクト開始位置の初期位置は“object_horizontal_position2”であるとする。
フレームT0(初期フレーム)において、オブジェクト開始位置は、以下のように設定される。すなわち、“Object_id=1”のオブジェクト開始位置“object_horizontal_position1(T0)”は、“object_horizontal_position1 + Max ( offset_sequence(n)”に設定される。また、“Object_id=2”のオブジェクト開始位置“object_horizontal_position2(T0)”は、“object_horizontal_position2 - Max ( offset_sequence(n)”に設定される。そして、以下のフレームでは、この“Object_id=1”、“Object_id=2”のオブジェクト開始位置が維持される。
図48は、「ケースE(Top & Bottom)」の立体画像用のサブタイトルデータの作成方法を概念的に示している。この場合、左眼サブタイトルのデータおよび右眼サブタイトルのデータは、同一のページの異なるリージョンのデータとして生成される。図48(a)は、二次元画像用のサブタイトルデータによるリージョン(region)を示している。
最初に、サブタイトル処理部133は、上述の二次元画像用のサブタイトルデータによるリージョン(region)のサイズを、図48(b)に示すように、トップ・アンド・ボトム方式に適したサイズに変換し、そのサイズのビットマップデータを発生させる。
次に、サブタイトル処理部133は、図48(c)に示すように、サイズ変換後のビットマップデータを立体画像用のサブタイトルデータのリージョン(region)の構成要素とする。その際、各オブジェクトの開始位置(region_horizontal_address)は、左眼画像(left view )と右眼画像(right view)との視差(disparity)に相当する分(A-B= disparity)だけ、ずらした位置とされる。
サブタイトル処理部133は、上述したようにして、二次元画像用のサブタイトルデータを、立体画像用のサブタイトルデータに変換し、この立体画像用のサブタイトルデータに対応したPCS、RCS、ODSなどのセグメントを作成する。
図49は、「ケースE(Top & Bottom)」で作成される立体画像用のサブタイトルデータによるリージョン(region)の一例を示している。ここで、左眼画像(left view )側のリージョンの開始位置は“Region_horizontal_address1”であり、右眼画像(rightview )側のリージョンの開始位置は“Region_horizontal_address2”である。なお、この例は、左眼サブタイトルおよび右眼サブタイトルのビットマップデータとして共通のビットマップデータが使用される例である。
図50は、「ケースE(Top & Bottom)」における各セグメントの作成例を示している。この場合、OSSのセグメントでは、「region_position_offset_allocated=1」、「object_position_allocated=0」、「target_stereo_format=010」に設定されている。
この作成例において、PCS(page composition segment)では、左眼画像(left view)側のリージョン(Region_id=0A)と右眼画像(right view)側のリージョン(Region_id=0A)の開始位置(region_horizontal_address)がそれぞれ指定されている。また、“Region_id=0A”のRCS(region composition segment)では、“Object_id=1”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position1”が指定されている。また、この作成例において、OSS(offset_sequence_segment)では、“Region_id=0A”とされている。
上述したように、OSSのセグメントには、視差情報群(オフセット値“offset_sequence”)が挿入されている。受信側においては、所定数のフレーム期間の各フレームにおけるオフセット値“offset_sequence”に基づいて、左眼サブタイトルと右眼サブタイトルとの間に所定の視差を付与することが可能となる。例えば、受信側においては、左眼サブタイトルと右眼サブタイトルとの間の視差を順次更新することが可能となる。
この場合、受信側においては、後方互換を維持して、リージョン開始位置“region_horizontal_address”を簡便にフレーム単位で更新することが可能となる。すなわち、“region_horizontal_address”は、フレームT0(初期フレーム)の初期位置(initial position)に対し、“offset_sequence(T)”で指定される差分量が各フレームで加えられていくことで、“Region_id”単位で更新される。これにより、サブタイトルが表示される所定数のフレーム期間において、左眼サブタイトルと右眼サブタイトルとの間の視差が順次更新される。
図51は、リージョン開始位置“region_horizontal_address”をフレーム単位で更新する例を示している。フレームT0(初期フレーム)において、左眼画像(left view)側のリージョン開始位置は“region_horizontal_address1(T0)”であり、右眼画像(right view)側のリージョン開始位置は“regionhorizontal_address2(T0)”であるとする。
次フレームであるフレームT1のオブジェクト開始位置は、以下のように更新される。なお、このフレームT1のオフセット値は“offset_sequence(T1)”であるとする。すなわち、左眼画像(leftview)側のリージョン開始位置“region_horizontal_address1(T1)”は、“region_horizontal_address1(T0) + offset_sequence(T1)”とされる。また、右眼画像(right view)側のリージョン開始位置“region_horizontal_address2(T1)”は、“region_horizontal_address2(T0) - offset_sequence(T1)”とされる。
また、次フレームであるフレームT2のリージョン開始位置は、以下のように更新される。なお、このフレームT2のオフセット値は“offset_sequence(T2)”であるとする。すなわち、左眼画像(leftview)側のリージョン開始位置“region_horizontal_address1(T2)”は、“region_horizontal_address1(T1) + offset_sequence(T2)”とされる。また、右眼画像(right view)側のリージョン開始位置“region_horizontal_address2(T2)”は、“region_horizontal_address2(T1) - offset_sequence(T2)”とされる。以下、同様にして、各フレームのリージョン開始位置がリージョン単位で求められて更新される。
図52は、「ケースE(Full Frame or Frame Sequential or Backward Compatible)」で作成される立体画像用のサブタイトルデータによるリージョン(region)の一例を示している。ここで、リージョンの開始位置は“Region_horizontal_address”である。なお、この方式では、左眼サブタイトルと右眼サブタイトルとの間に付与すべき視差は、左眼画像(left view)および右眼画像(right view)のリージョン(region)の開始位置に反映されておらず、OSSのセグメントで、「Disparity_offset」として、別途送信される。
図53は、「ケースE(Full Frame or or Frame Sequential Backward Compatible)」における各セグメントの作成例を示している。この場合、OSSのセグメントでは、「region_position_offset_allocated=0」、「object_position_allocated=0」、「target_stereo_format=000」に設定されている。この作成例において、PCS(page composition segment)では、リージョン(Region_id=0A)の開始位置(region_horizontal_address)が指定されている。
また、“Region_id=0A”のRCS(region composition segment)では、“Object_id=1”のODSが参照され、そのオブジェクトの開始位置“object_horizontal_position1”が指定されている。また、この作成例において、OSS(offset_sequence_segment)では、“Region_id=0A”とされている。
上述したように、OSSのセグメントには、視差情報群(オフセット値“offset_sequence”)が挿入されている。この視差情報群は、上述したように、サブタイトル(字幕)が表示される所定数のフレーム期間の各フレームにおける左眼サブタイトルと右眼サブタイトルとの間に付与すべき視差の情報である。受信側においては、所定数のフレーム期間の各フレームにおけるオフセット値“offset_sequence”に基づいて、左眼サブタイトルと右眼サブタイトルとの間に所定の視差を付与することが可能となる。例えば、受信側においては、左眼サブタイトルと右眼サブタイトルとの間の視差を順次更新することが可能となる。
この場合、受信側においては、後方互換を維持して、リージョン開始位置“region_horizontal_address”を簡便にフレーム単位で更新することが可能となる。すなわち、“region_horizontal_address”は、フレームT0(初期フレーム)の初期位置(initial position)に対し、“offset_sequence(T)”で指定される差分量が各フレームで加えられていくことで、“region_id”単位で更新される。これにより、サブタイトルが表示される所定数のフレーム期間において、左眼サブタイトルと右眼サブタイトルとの間の視差が順次更新される。
図55は、リージョン開始位置“region_horizontal_address”をフレーム単位で更新する例を示している。フレームT0(初期フレーム)において、左眼画像(left view)側のリージョン開始位置“region_horizontal_address(T0)”は、“region_horizontal_address + disparity_offset”とされる。右眼画像(right view)側には、左眼画像(left view)側のリージョン(region)のビットマップデータが、開始位置が“c0”とされてコピーされる。この場合、“c0= region_horizontal_address - disparity_offset”とされる。
次フレームであるフレームT1の左眼画像(left view)側のリージョン開始位置“region_horizontal_address(T1)”および右眼画像(right view)側のコピービットマップデータの開始位置“c1”が、以下のように更新される。なお、このフレームT1のオフセット値は“offset_sequence(T1)”であるとする。すなわち、左眼画像(leftview)側のリージョン開始位置“region_horizontal_address1(T1)”は、“region_horizontal_address1(T0) + offset_sequence(T1)”とされる。また、右眼画像(right view)側のコピービットマップデータの開始位置“c1”は、“c0 - offset_sequence(T1)”とされる。
次フレームであるフレームT2の左眼画像(left view)側のリージョン開始位置“region_horizontal_address(T2)”および右眼画像(right view)側のコピービットマップデータの開始位置“c2”が、以下のように更新される。なお、このフレームT2のオフセット値は“offset_sequence(T2)”であるとする。すなわち、左眼画像(leftview)側のリージョン開始位置“region_horizontal_address1(T2)”は、“region_horizontal_address1(T1) +offset_sequence(T2)”とされる。また、右眼画像(right view)側のコピービットマップデータの開始位置“c2”は、“c1 - offset_sequence(T2)”とされる。以下、同様にして、各フレームのリージョン開始位置がリージョン単位で求められて更新される。
図55は、「ケースE(Side-by-Side)」の場合における、OSS設定と、放送局100からセットトップボックス200を介してテレビ受信機300に至る、立体画像データおよびサブタイトルデータの流れを概略的に示している。この場合、放送局100ではサイド・バイ・サイド(Side-by-Side)方式に合わせた立体画像用のサブタイトルデータが生成される。そして、立体画像データはビデオデータストリームに含まれて送信され、サブタイトルデータはサブタイトルデータストリームに含まれて送信される。
セットトップボックス200では、サブタイトルデータに基づいて左眼サブタイトルおよび右眼サブタイトルを表示するための表示データが生成され、この表示データが立体画像データに重畳される。そして、サブタイトルの表示データが重畳された立体画像データがHDMIのデジタルインタフェースを通じて、テレビ受信機300に送信される。この場合、セットトップボックス200からテレビ受信機300への立体画像データの伝送フォーマットは、サイド・バイ・サイド(Side-by-Side)方式である。
テレビ受信機300では、セットトップボックス200から送られてくる立体画像データにデコード処理が施される。そして、サブタイトルが重畳された左眼画像および右眼画像のデータが生成され、LCD等の表示パネルに、ユーザに立体画像を認識させるための両眼視差画像(左眼画像および右眼画像)が表示される。なお、図55に示すように、放送局100から直接テレビ受信機300に至る経路も考えられる。この場合、テレビ受信機300は、例えば、セットトップボックス200と同様の処理機能部を備えている。
図56は、「ケースE(Top & Bottom)」の場合における、OSS設定と、放送局100からセットトップボックス200を介してテレビ受信機300に至る、立体画像データおよびサブタイトルデータの流れを概略的に示している。この場合、放送局100ではトップ・アンド・ボトム(Top & Bottom)方式に合わせた立体画像用のサブタイトルデータが生成される。そして、放送局100から立体画像データがビデオデータストリームに含まれて送信され、サブタイトルデータはサブタイトルデータストリームに含まれて送信される。
セットトップボックス200では、サブタイトルデータに基づいて左眼サブタイトルおよび右眼サブタイトルを表示するための表示データが生成され、この表示データが立体画像データに重畳される。そして、サブタイトルの表示データが重畳された立体画像データがHDMIのデジタルインタフェースを通じて、テレビ受信機300に送信される。この場合、セットトップボックス200からテレビ受信機300への立体画像データの伝送フォーマットは、トップ・アンド・ボトム(Top & Bottom)方式である。
テレビ受信機300では、セットトップボックス200から送られてくる立体画像データにデコード処理が施される。そして、サブタイトルが重畳された左眼画像および右眼画像のデータが生成され、LCD等の表示パネルに、ユーザに立体画像を認識させるための両眼視差画像(左眼画像および右眼画像)が表示される。なお、図56に示すように、この場合も、上述の「ケースE(Side-by-Side)」の場合と同様に、放送局100から直接テレビ受信機300に至る経路も考えられる。この場合、テレビ受信機300は、例えば、セットトップボックス200と同様の処理機能部を備えている。
図57は、「ケースE(Full Frame or Frame Sequential or Backward Compatible)」の場合における、OSS設定と、放送局100からセットトップボックス200を介してテレビ受信機300に至る、立体画像データおよびサブタイトルデータの流れを概略的に示している。この場合、放送局100ではフル・フレーム(Full Frame)方式またはバックワード・コンパチブル(BackwardCompatible)方式に合わせた立体画像用のサブタイトルデータが生成される。そして、放送局100から立体画像データがビデオデータストリームに含まれて送信され、サブタイトルデータはサブタイトルデータストリームに含まれて送信される。
セットトップボックス200では、サブタイトルデータに基づいて左眼サブタイトルおよび右眼サブタイトルを表示するための表示データが生成され、この表示データが立体画像データに重畳される。そして、サブタイトルの表示データが重畳された立体画像データがHDMIのデジタルインタフェースを通じて、テレビ受信機300に送信される。この場合、セットトップボックス200からテレビ受信機300への立体画像データの伝送フォーマットは、フレーム・パッキング(Frame Packing)方式あるいはサイド・バイ・サイド(Side-by-Side)フルビデオ(Full video)方式である。
テレビ受信機300では、セットトップボックス200から送られてくる立体画像データにデコード処理が施される。そして、サブタイトルが重畳された左眼画像および右眼画像のデータが生成され、LCD等の表示パネルに、ユーザに立体画像を認識させるための両眼視差画像(左眼画像および右眼画像)が表示される。なお、図57に示すように、この場合も、上述の「ケースE(Side-by-Side)」の場合と同様に、放送局100から直接テレビ受信機300に至る経路も考えられる。この場合、テレビ受信機300は、例えば、セットトップボックス200と同様の処理機能部を備えている。
図2に示す送信データ生成部110において、マルチプレクサ122から出力されるビットストリームデータBSDは、ビデオデータストリームとサブタイトルデータストリームとを有する多重化データストリームである。ビデオデータストリームには、立体画像データが含まれている。また、サブタイトルデータストリームには、その立体画像データの伝送フォーマットに対応した立体画像用(三次元画像用)のサブタイトルデータが含まれている。
この立体画像用のサブタイトルデータは、左眼サブタイトルのデータおよび右眼サブタイトルのデータを持っている。そのため、受信側においては、この立体画像用のサブタイトルデータに基づいて、立体画像データが持つ左眼画像データに重畳する左眼サブタイトルの表示データおよび立体画像データが持つ右眼画像データに重畳する右眼サブタイトルの表示データを容易に発生でき、処理の容易化が図られる。
[セットトップボックスの説明]
図1に戻って、セットトップボックス200は、放送局100から放送波に載せて送信されてくるビットストリームデータ(トランスポートストリーム)BSDを受信する。このビットストリームデータBSDには、左眼画像データおよび右眼画像データを含む立体画像データ、音声データが含まれている。また、ビットストリームデータBSDには、サブタイトル(字幕)を表示するための立体画像用のサブタイトルデータが含まれている。
セットトップボックス200は、ビットストリーム処理部201を有している。このビットストリーム処理部201は、ビットストリームデータBSDから、立体画像データ、音声データ、サブタイトルデータを抽出する。そして、このビットストリーム処理部201は、立体画像データ、サブタイトルデータ等を用いて、サブタイトルが重畳された立体画像データを生成する。
この場合、左眼画像に重畳する左眼サブタイトルと右眼画像に重畳する右眼サブタイトルとの間には視差が付与されたものとされる。例えば、上述したように、放送局100から送られてくる立体画像用のサブタイトルデータは、左眼サブタイトルと右眼サブタイトルとの間に視差が付与されるように生成されている。このように、左眼サブタイトルと右眼サブタイトルとの間に視差が付与されることで、ユーザは、サブタイトル(字幕)を画像の手前に認識可能とされる。
図58(a)は、画像上におけるキャプション・ユニット(字幕)の表示例を示している。この表示例では、背景と近景オブジェクトとからなる画像上に、字幕が重畳された例である。図58(b)は、背景、近景オブジェクト、字幕の遠近感を示し、字幕が最も手前に認識されることを示している。
図59(a)は、図58(a)と同じ、画像上におけるキャプション・ユニット(字幕)の表示例を示している。図59(b)は、左眼画像に重畳される左眼字幕LGIと、右眼画像に重畳される右眼字幕RGIを示している。図59(c)は、字幕が最も手前に認識されるために、左眼字幕LGIと右眼字幕RGIとの間に視差が与えられることを示している。
[セットトップボックスの構成例]
セットトップボックス200の構成例を説明する。図60は、セットトップボックス200の構成例を示している。このセットトップボックス200は、ビットストリーム処理部201と、HDMI端子202と、アンテナ端子203と、デジタルチューナ204と、映像信号処理回路205と、HDMI送信部206と、音声信号処理回路207を有している。また、このセットトップボックス200は、CPU211と、フラッシュROM212と、DRAM213と、内部バス214と、リモコン受信部215と、リモコン送信機216を有している。
アンテナ端子203は、受信アンテナ(図示せず)で受信されたテレビ放送信号を入力する端子である。デジタルチューナ204は、アンテナ端子203に入力されたテレビ放送信号を処理して、ユーザの選択チャネルに対応した所定のビットストリームデータ(トランスポートストリーム)BSDを出力する。
ビットストリーム処理部201は、上述したように、ビットストリームデータBSDから立体画像データ、音声データ、立体画像用のサブタイトルデータ(視差情報群を含む)等を抽出する。このビットストリーム処理部201は、立体画像データに対して、左眼サブタイトルおよび右眼サブタイトルの表示データを合成し、サブタイトルが重畳された表示用立体画像データを得る。また、ビットストリーム処理部201は、音声データを出力する。ビットストリーム処理部201の詳細構成は後述する。
映像信号処理回路205は、ビットストリーム処理部201で得られた表示用立体画像データに対して必要に応じて画質調整処理などを行い、処理後の表示用立体画像データをHDMI送信部206に供給する。音声信号処理回路207は、ビットストリーム処理部201から出力された音声データに対して必要に応じて音質調整処理等を行い、処理後の音声データをHDMI送信部206に供給する。
HDMI送信部206は、HDMIに準拠した通信により、例えば、非圧縮の画像データおよび音声データを、HDMI端子202から送出する。この場合、HDMIのTMDSチャネルで送信するため、画像データおよび音声データがパッキングされて、HDMI送信部206からHDMI端子202に出力される。
例えば、放送局100からの立体画像データの伝送フォーマットがサイド・バイ・サイド方式であるとき、TMDS伝送フォーマットはサイド・バイ・サイド方式とされる(図55参照)。また、例えば、放送局100からの立体画像データの伝送フォーマットがトップ・アンド・ボトム方式であるとき、TMDS伝送フォーマットはトップ・アンド・ボトム方式とされる(図56参照)。また、例えば、放送局100からの立体画像データの伝送フォーマットがフル・フレーム方式、あるいはフレーム・シーケンシャル方式、あるいはバックワード・コンパチブル方式であるとき、TMDS伝送フォーマットは、フレーム・パッキング方式あるいはサイド・バイ・サイド(フルビデオ)方式とされる(図57参照)。
CPU211は、セットトップボックス200の各部の動作を制御する。フラッシュROM212は、制御ソフトウェアの格納およびデータの保管を行う。DRAM213は、CPU211のワークエリアを構成する。CPU211は、フラッシュROM212から読み出したソフトウェアやデータをDRAM213上に展開してソフトウェアを起動させ、セットトップボックス200の各部を制御する。
リモコン受信部215は、リモコン送信機216から送信されたリモートコントロール信号(リモコンコード)を受信し、CPU211に供給する。CPU211は、このリモコンコードに基づいて、セットトップボックス200の各部を制御する。CPU211、フラッシュROM212およびDRAM213は内部バス214に接続されている。
セットトップボックス200の動作を簡単に説明する。アンテナ端子203に入力されたテレビ放送信号はデジタルチューナ204に供給される。このデジタルチューナ204では、テレビ放送信号が処理されて、ユーザの選択チャネルに対応した所定のビットストリームデータ(トランスポートストリーム)BSDが出力される。
デジタルチューナ204から出力されるビットストリームデータBSDは、ビットストリーム処理部201に供給される。このビットストリーム処理部201では、ビットストリームデータBSDから立体画像データ、音声データ、立体画像用のサブタイトルデータ(視差情報群を含む)等が抽出される。また、このビットストリーム処理部201では、立体画像データに対して、左眼サブタイトルおよび右眼サブタイトルの表示データ(ビットマップデータ)が合成され、サブタイトルが重畳された表示用立体画像データが得られる。
ビットストリーム処理部201で得られた表示用立体画像データは、映像信号処理回路205に供給される。この映像信号処理回路205では、表示用立体画像データに対して、必要に応じて画質調整処理等が行われる。この映像信号処理回路205から出力される処理後の表示用立体画像データは、HDMI送信部206に供給される。
また、ビットストリーム処理部201で得られた音声データは、音声信号処理回路207に供給される。この音声信号処理回路207では、音声データに対して、必要に応じて音質調整処理等の処理が行われる。この音声信号処理回路207から出力される処理後の音声データは、HDMI送信部206に供給される。そして、HDMI送信部206に供給された立体画像データおよび音声データは、HDMIのTMDSチャネルにより、HDMI端子202からHDMIケーブル400に送出される。
[ビットストリーム処理部の構成例]
図61は、ビットストリーム処理部201の構成例を示している。このビットストリーム処理部201は、上述の図2に示す送信データ生成部110に対応した構成となっている。このビットストリーム処理部201は、デマルチプレクサ221と、ビデオデコーダ222と、サブタイトルデコーダ223と、立体画像用サブタイトル発生部224と、ビデオ重畳部226と、オーディオデコーダ227とを有している。
デマルチプレクサ221は、ビットストリームデータBSDから、ビデオ、オーディオ、サブタイトルのパケットを抽出し、各デコーダに送る。なお、デマルチプレクサ221は、ビットストリームデータBSDに挿入されているPMT、EIT等の情報を抽出し、CPU211に送る。上述したように、EITの配下にあるコンポーネント・デスクリプタに,Stream_content(‘0x03’=DVB subtitles) & Component_type(for 3Dtarget)が記述され、サブタイトルデータストリームに立体画像用のサブタイトルデータが含まれることが識別可能とされている。したがって、CPU211は、この記述により、サブタイトルデータストリームに立体画像用のサブタイトルデータが含まれることを識別できる。
ビデオデコーダ222は、上述の送信データ生成部110のビデオエンコーダ113とは逆の処理を行う。すなわち、デマルチプレクサ221で抽出されたビデオのパケットからビデオデータストリームを再構成し、復号化処理を行って、左眼画像データおよび右眼画像データを含む立体画像データを得る。この立体画像データの伝送フォーマットは、例えば、上述の第1の伝送方式(「Top & Bottom」方式)、第2の伝送方式は(「Side By Side」方式)、第3の伝送方式(「Full Frame」方式、あるいは「Frame Sequential」方式、あるいは Backward Compatible 方式)などである(図4参照)。
サブタイトルデコーダ223は、上述の送信データ生成部110のサブタイトルエンコーダ133とは逆の処理を行う。すなわち、このサブタイトルデコーダ223は、デマルチプレクサ221で抽出されたサブタイトルのパケットからサブタイトルデータストリームを再構成し、復号化処理を行って、立体画像用のサブタイトルデータ(視差情報群を含む)を得る。
立体画像用サブタイトル発生部224は、立体画像用のサブタイトルデータに基づいて、立体画像データに重畳する左眼サブタイトルおよび右眼サブタイトルの表示データ(ビットマップデータ)を発生する。上述したように、放送局100から送られてくる立体画像用のサブタイトルデータは、左眼サブタイトルと右眼サブタイトルとの間に視差が付与されるように生成されている。そのため、立体画像用サブタイトル発生部224で発生される左眼サブタイトルおよび右眼サブタイトルの表示データは、左眼サブタイトルおよび右眼サブタイトルに視差が付与されたものとなる(図13(c)参照)。
また、立体画像用サブタイトル発生部224は、視差情報群(オフセット値“offset_sequence”)に基づいて、左眼サブタイトルと右眼サブタイトルとの間に所定の視差を付与する。この視差情報群は、上述したように、サブタイトル(字幕)が表示される所定数のフレーム期間の各フレームにおける左眼サブタイトルと右眼サブタイトルとの間に付与すべき視差の情報である。立体画像用サブタイトル発生部224において視差情報群によってどのように視差を付与するかは、例えば、工場出荷時の設定、あるいは購入後のユーザ設定等による。
例えば、立体画像用サブタイトル発生部224は、視差情報群に基づいて、左眼サブタイトルと右眼サブタイトルとの間の視差をフレーム単位で順次更新する(図19参照)。また、例えば、立体画像用サブタイトル発生部224は、視差情報群に基づいて、左眼サブタイトルと右眼サブタイトルとの間に、所定数のフレーム期間の代表値、例えば最大値、平均値等による視差を付与する(図20参照)。
ビデオ重畳部226は、ビデオデコーダ222で得られた立体画像データに対し、立体画像用サブタイトル発生部224で発生された左眼サブタイトルおよび右眼サブタイトルの表示データ(ビットマップデータ)を重畳し、表示用立体画像データVoutを得る。そして、ビデオ重畳部226は、この表示用立体画像データVoutを、ビットストリーム処理部201の外部に出力する。
また、オーディオデコーダ227は、上述の送信データ生成部110のオーディオエンコーダ117とは逆の処理を行う。すなわち、このオーディオデコーダ227は、デマルチプレクサ221で抽出されたオーディオのパケットからオーディオのエレメンタリストリームを再構成し、復号化処理を行って、音声データAoutを得る。そして、このオーディオデコーダ227は、音声データAoutを、ビットストリーム処理部201の外部に出力する。
図61に示すビットストリーム処理部201の動作を簡単に説明する。デジタルチューナ204(図60参照)から出力されるビットストリームデータBSDは、デマルチプレクサ221に供給される。このデマルチプレクサ221では、ビットストリームデータBSDから、ビデオ、オーディオおよびサブタイトルのパケットが抽出され、各デコーダに供給される。
ビデオデコーダ222では、デマルチプレクサ221で抽出されたビデオのパケットからビデオデータストリームが再構成され、さらに復号化処理が行われて、左眼画像データおよび右眼画像データを含む立体画像データが得られる。この立体画像データは、ビデオ重畳部226に供給される。
また、サブタイトルデコーダ223では、デマルチプレクサ221で抽出されたサブタイトルのパケットからサブタイトルデータストリームが再構成され、さらに復号化処理が行われて、立体画像用のサブタイトルデータ(視差情報群を含む)が得られる。このサブタイトルデータは、立体画像用サブタイトル発生部224に供給される。
立体画像用サブタイトル発生部224では、立体画像用のサブタイトルデータに基づいて、立体画像データに重畳する左眼サブタイトルおよび右眼サブタイトルの表示データ(ビットマップデータ)が発生される。この場合、立体画像用のサブタイトルデータが左眼サブタイトルと右眼サブタイトルとの間に視差が付与されるように生成されているため、表示データは左眼サブタイトルおよび右眼サブタイトルに視差が付与されたものとなる。この表示データはビデオ重畳部226に供給される。
ビデオ重畳部226では、ビデオデコーダ222で得られた立体画像データに対し、立体画像用サブタイトル発生部224で発生された左眼サブタイトルおよび右眼サブタイトルの表示データが重畳され、表示用立体画像データVoutが得られる。この表示用立体画像データVoutは、ビットストリーム処理部201の外部に出力される。
また、オーディオデコーダ227では、デマルチプレクサ221で抽出されたオーディオのパケットからオーディオエレメンタリストリームが再構成され、さらに復号化処理が行われて、上述の表示用立体画像データVoutに対応した音声データAoutが得られる。この音声データAoutは、ビットストリーム処理部201の外部に出力される。
図60に示すセットトップボックス200において、デジタルチューナ204から出力されるビットストリームデータBSDは、ビデオデータストリームとサブタイトルデータストリームとを有する多重化データストリームである。ビデオデータストリームには、立体画像データが含まれている。また、サブタイトルデータストリームには、その立体画像データの伝送フォーマットに対応した立体画像用(三次元画像用)のサブタイトルデータが含まれている。
この立体画像用のサブタイトルデータは、左眼サブタイトルのデータおよび右眼サブタイトルのデータを持っている。そのため、ビットストリーム処理部59の立体画像用サブタイトル発生部224では、この立体画像用のサブタイトルデータに基づいて、立体画像データが持つ左眼画像データに重畳する左眼サブタイトルの表示データおよび立体画像データが持つ右眼画像データに重畳する右眼サブタイトルの表示データを容易に発生でき、処理の容易化が図られる。
また、図60に示すセットトップボックス200において、ビットストリーム処理部201のサブタイトルデコーダ223で得られるサブタイトルデータには、視差情報群(オフセット値“offset_sequence”)が含まれている。そのため、立体画像用サブタイトル発生部224では、この視差情報群に基づいて、左眼サブタイトルと右眼サブタイトルとの間に所定の視差を付与できる。例えば、左眼サブタイトルと右眼サブタイトルとの間にフレーム単位で順次更新される視差を付与できる。また、例えば、左眼サブタイトルと右眼サブタイトルとの間に、所定数のフレーム期間の代表値、例えば最大値、平均値等による視差を付与できる。
[テレビ受信機の説明]
図1に戻って、テレビ受信機300は、セットトップボックス200からHDMIケーブル400を介して送られてくる立体画像データを受信する。このテレビ受信機300は、3D信号処理部301を有している。この3D信号処理部301は、立体画像データに対して、伝送方式に対応した処理(デコード処理)を行って、左眼画像データおよび右眼画像データを生成する。
[テレビ受信機の構成例]
テレビ受信機300の構成例を説明する。図62は、テレビ受信機300の構成例を示している。このテレビ受信機300は、3D信号処理部301と、HDMI端子302と、HDMI受信部303と、アンテナ端子304と、デジタルチューナ305と、ビットストリーム処理部306を有している。
また、このテレビ受信機300は、映像・グラフィック処理回路307と、パネル駆動回路308と、表示パネル309と、音声信号処理回路310と、音声増幅回路311と、スピーカ312を有している。また、このテレビ受信機300は、CPU321と、フラッシュROM322と、DRAM323と、内部バス324と、リモコン受信部325と、リモコン送信機326を有している。
アンテナ端子304は、受信アンテナ(図示せず)で受信されたテレビ放送信号を入力する端子である。デジタルチューナ305は、アンテナ端子304に入力されたテレビ放送信号を処理して、ユーザの選択チャネルに対応した所定のビットストリームデータ(トランスポートストリーム)BSDを出力する。
ビットストリーム処理部306は、図60に示すセットトップボックス200内のビットストリーム処理部201と同様の構成とされている。このビットストリーム処理部306は、ビットストリームデータBSDから立体画像データ、音声データ、キャプション・ユニットの字幕データ、視差ベクトル等を抽出する。また、このビットストリーム処理部306は、立体画像データに対して、左眼字幕、右眼字幕のデータを合成し、表示用立体画像データを生成して出力する。また、ビットストリーム処理部306は、音声データを出力する。
HDMI受信部303は、HDMIに準拠した通信により、HDMIケーブル400を介してHDMI端子302に供給される非圧縮の画像データおよび音声データを受信する。このHDMI受信部303は、そのバージョンが例えばHDMI1.4aとされており、立体画像データの取り扱いが可能な状態にある。
3D信号処理部301は、HDMI受信部303で受信された、あるいはビットストリーム処理部306で得られた立体画像データに対して、デコード処理を行って、左眼画像データおよび右眼画像データを生成する。この場合、3D信号処理部301は、ビットストリーム処理部306で得られた立体画像データに対しては、その伝送フォーマット(図4参照)に対応したデコード処理を行う。また、3D信号処理部301は、HDMI受信部303で受信された立体画像データに対しては、TMDS伝送データフォーマットに対応したデコード処理を行う。
映像・グラフィック処理回路307は、3D信号処理部301で生成された左眼画像データおよび右眼画像データに基づいて、立体画像を表示するための画像データを生成する。また、映像・グラフィック処理回路307は、画像データに対して、必要に応じて、画質調整処理を行う。また、映像・グラフィック処理回路307は、画像データに対して、必要に応じて、メニュー、番組表などの重畳情報のデータを合成する。パネル駆動回路308は、映像・グラフィック処理回路307から出力される画像データに基づいて、表示パネル309を駆動する。表示パネル309は、例えば、LCD(Liquid Crystal Display)、PDP(Plasma DisplayPanel)等で構成されている。
音声信号処理回路310は、HDMI受信部303で受信された、あるいはビットストリーム処理部306で得られた音声データに対してD/A変換等の必要な処理を行う。音声増幅回路311は、音声信号処理回路310から出力される音声信号を増幅してスピーカ312に供給する。
CPU321は、テレビ受信機300の各部の動作を制御する。フラッシュROM322は、制御ソフトウェアの格納およびデータの保管を行う。DRAM323は、CPU321のワークエリアを構成する。CPU321は、フラッシュROM322から読み出したソフトウェアやデータをDRAM323上に展開してソフトウェアを起動させ、テレビ受信機300の各部を制御する。
リモコン受信部325は、リモコン送信機326から送信されたリモートコントロール信号(リモコンコード)を受信し、CPU321に供給する。CPU321は、このリモコンコードに基づいて、テレビ受信機300の各部を制御する。CPU321、フラッシュROM322およびDRAM323は、内部バス324に接続されている。
図62に示すテレビ受信機300の動作を簡単に説明する。HDMI受信部303では、HDMI端子302にHDMIケーブル400を介して接続されているセットトップボックス200から送信されてくる、立体画像データおよび音声データが受信される。このHDMI受信部303で受信された立体画像データは、3D信号処理部301に供給される。また、このHDMI受信部303で受信された音声データは音声信号処理回路310に供給される。
アンテナ端子304に入力されたテレビ放送信号はデジタルチューナ305に供給される。このデジタルチューナ305では、テレビ放送信号が処理されて、ユーザの選択チャネルに対応した所定のビットストリームデータ(トランスポートストリーム)BSDが出力される。
デジタルチューナ305から出力されるビットストリームデータBSDは、ビットストリーム処理部306に供給される。このビットストリーム処理部306では、ビットストリームデータBSDから立体画像データ、音声データ、キャプション・ユニットの字幕データ、視差ベクトル等が抽出される。また、このビットストリーム処理部306では、立体画像データに対して、左眼字幕、右眼字幕のデータが合成され、表示用立体画像データが生成される。
ビットストリーム処理部306で生成された表示用立体画像データは、3D信号処理部301に供給される。また、このビットストリーム処理部306で得られた音声データは、音声信号処理回路310に供給される。
3D信号処理部301では、HDMI受信部303で受信された、あるいはビットストリーム処理部306で得られた立体画像データに対してデコード処理が行われて、左眼画像データおよび右眼画像データが生成される。この左眼画像データおよび右眼画像データは、映像・グラフィック処理回路307に供給される。この映像・グラフィック処理回路307では、左眼画像データおよび右眼画像データに基づいて、立体画像を表示するための画像データが生成され、必要に応じて、画質調整処理、重畳情報データの合成処理も行われる。
この映像・グラフィック処理回路307で得られる画像データはパネル駆動回路308に供給される。そのため、表示パネル309により立体画像が表示される。例えば、表示パネル309に、左眼画像データによる左眼画像および右眼画像データによる右眼画像が交互に時分割的に表示される。視聴者は、例えば、表示パネル309の表示に同期して左眼シャッタおよび右眼シャッタが交互に開くシャッタメガネを装着することで、左眼では左眼画像のみを見ることができ、右眼では右眼画像のみを見ることができ、立体画像を知覚できる。
また、音声信号処理回路310では、HDMI受信部303で受信された、あるいはビットストリーム処理部306で得られた音声データに対してD/A変換等の必要な処理が施される。この音声データは、音声増幅回路311で増幅された後に、スピーカ312に供給される。そのため、スピーカ312から表示パネル309の表示画像に対応した音声が出力される。
上述したように、図1に示す画像送受信システム10においては、放送局100(送信データ生成部201)からセットトップボックス200に、ビデオデータストリームとサブタイトルデータストリームとを有する多重化データストリームが送信される。ビデオデータストリームには、立体画像データが含まれている。また、サブタイトルデータストリームには、その立体画像データの伝送フォーマットに対応した立体画像用(三次元画像用)のサブタイトルデータが含まれている。
この立体画像用のサブタイトルデータは、左眼サブタイトルのデータおよび右眼サブタイトルのデータを持っている。そのため、セットトップボックス200においては、この立体画像用のサブタイトルデータに基づいて、立体画像データが持つ左眼画像データに重畳する左眼サブタイトルの表示データおよび立体画像データが持つ右眼画像データに重畳する右眼サブタイトルの表示データを容易に発生でき、ビットデータ処理部201の処理の容易化が図られる。
また、図1に示す画像送受信システム10においては、放送局100(送信データ生成部201)からセットトップボックス200に送信される立体画像用のサブタイトルデータは、左眼サブタイトルと右眼サブタイトルとの間に視差が付与されるように生成されている。そのため、セットトップボックス200において、立体画像用サブタイトル発生部224で発生される左眼サブタイトルおよび右眼サブタイトルの表示データは、自動的に、左眼サブタイトルおよび右眼サブタイトルに視差が付与されたものとなる。したがって、セットトップボックス200においては、左眼サブタイトルおよび右眼サブタイトルとの間に視差を付与する特別の処理を行わなくても、サブタイトル(字幕)の表示において、画像内の各物体との間の遠近感の整合性を最適な状態に維持できる。
また、図1に示す画像送受信システム10においては、放送局100(送信データ生成部201)からセットトップボックス200に送信される立体画像用のサブタイトルデータには、視差情報群(オフセット値“offset_sequence”)が含まれている。そのため、セットトップボックス200においては、この視差情報群に基づいて、左眼サブタイトルと右眼サブタイトルとの間に所定の視差を付与できる。例えば、左眼サブタイトルと右眼サブタイトルとの間にフレーム単位で順次更新される視差を付与できる。また、例えば、左眼サブタイトルと右眼サブタイトルとの間に、所定数のフレーム期間の代表値、例えば最大値、平均値等による視差を付与できる。
<2.変形例>
なお、上述実施の形態においては、画像送受信システム10が、放送局100、セットトップボックス200およびテレビ受信機300で構成されているものを示した。しかし、テレビ受信機300は、図62に示すように、セットトップボックス200内のビットストリーム処理部201と同等に機能するビットストリーム処理部306を備えている。したがって、図63に示すように、放送局100およびテレビ受信機300で構成される画像送受信システム10Aも考えられる。
また、上述実施の形態においては、立体画像データを含むデータストリーム(ビットストリームデータ)が放送局100から放送される例を示した。しかし、この発明は、このデータストリームがインターネット等のネットワークを利用して受信端末に配信される構成のシステムにも同様に適用できる。
また、上述実施の形態においては、セットトップボックス200と、テレビ受信機300とが、HDMIのデジタルインタフェースで接続されるものを示している。しかし、これらが、HDMIのデジタルインタフェースと同様のデジタルインタフェース(有線の他に無線も含む)で接続される場合においても、この発明を同様に適用できる。
また、上述実施の形態においては、重畳情報としてサブタイトル(字幕)を取り扱うものを示した。しかし、その他のグラフィクス情報、テキスト情報などの重畳情報を扱うものにも、この発明を同様に適用できる。