JP2004005373A - 深さイメージに基づく３次元物体を表現するためのノード構造 - Google Patents

Abstract

【課題】深さイメージに基づくノード構造を提供する。
【解決手段】一群の深さイメージに基づく表現（ＤｅｐｔｈＩｍａｇｅ−ＢａｓｅｄＲｅｐｒｅｓｅｎｔａｔｉｏｎ：ＤＩＢＲ）は深さイメージ（ＤｅｐｔｈＩｍａｇｅ）フォーマット、オクツリーイメージ（ＯｃｔｒｅｅＩｍａｇｅ）フォーマット、及びポイントテクスチャー（ＰｏｉｎｔＴｅｘｔｕｒｅ）フォーマットを有して従来の多角形３次元表現の代案として採択される。深さイメージは、客体を自体の参照イメージの集合と対応する深さマップにより表現する。オクツリーイメージは、同じデータを簡潔な参照イメージの集合とボクセルイメージに相応するインデックスのツリーである階層的オクツリー構造のボクセルモデルとに変換する。ポイントテクスチャーは、３次元客体を規則的な２次元格子上に投影することによって３次元色相点の集合で表現する。深さイメージ及びオクツリーイメージはアニメーションバージョンを有し、この時、参照イメージは動映像に取り替えられる。
【選択図】　図２６

Description

【０００１】
【発明の属する技術分野】
本発明は深さイメージに基づく３次元物体を表現するためのノード構造に係り、より詳細には、深さ情報を有するイメージにより客体を表現するためのノード構造に関する。
【０００２】
【従来の技術】
実際のイメージのような現実的なグラフィック画面を生成することは、３次元（３−Ｄｉｍｅｎｓｉｏｎａｌ：３Ｄ）グラフィックの研究者達にとって、研究開始当初からの究極目標である。
【０００３】
従って、伝統的なレンダリング技術分野において、多角形モデル（ポリゴンモデル：Ｐｏｌｙｇｏｎａｌｍｏｄｅｌ）を利用する研究が種々行われた結果、非常に現実的な３Ｄ環境を提供するのに十分な程度にモデリング技術及びレンダリング技術が開発されてきた。
【０００４】
しかしながら、複雑なモデルを生成するための過程は専門家の多くの努力と時間を必要とする。また、現実的で複雑な環境は莫大な量の情報を必要とし、貯蔵及び伝送において低効率を招く。
【０００５】
現在、コンピュータグラフィックにおいて３Ｄ客体表現の主要な方法は、多角形モデルを使用する方法である。
任意の形状は、色多角形の集合、すなわち、三角形の集合により概略的に表現できる。
ソフトウェアアルゴリズムの飛躍的な進歩及びグラフィックハードウェアの発展により、複雑な客体及び場面をリアルタイムでかなり現実的な静止及び動映像多角形モデルに視覚化できる。
【０００６】
しかし、他の方法による３Ｄ表現の研究が、ここ数年来活発に行われてきた。
これは、レンダリングの複雑さの問題や、写真のように現実的な場面を生成する場合に品質が落ちるという問題だけではなく、現実の客体をポリゴンモデルで表現しづらいという問題に起因するものである。
【０００７】
厳しい条件の場合は、莫大な量の多角形が必要となるからである。例えば、人体の詳細なモデルの場合、数百万個の三角形を必要とし、これらを扱うことは容易ではない。
たとえ、３次元レーザースキャナーのように３次元測定技術分野での最近の進歩の結果、許容可能なエラーを有する稠密なデータを得る事はできるが、全体客体に対して連続的に完壁な多角形モデルを得ることは依然としてコストが多くかかって非常にむずかしい。
一方、写真のような現実的な品質を得るための多角形レンダリングアルゴリズムは、演算が複雑となるのでリアルタイムレンダリングが不可能である。
【０００８】
【発明が解決しようとする課題】
本発明が解決しようとする技術的課題は、ＭＰＥＧ−４動映像フレームワーク拡張（ＭＰＥＧ−４ＡｎｉｍａｔｉｏｎＦｒａｍｅｗｏｒｋｅＸｔｅｎｓｉｏｎ：ＡＦＸ）に採用されてきたＤＩＢＲ（ｄｅｐｔｈｉｍａｇｅ−ｂａｓｅｄｒｅｐｒｅｓｅｎｔａｔｉｏｎｓ）と呼ばれる、一群のコンピュータグラフィックとアニメーションのための３次元表現のための深さイメージに基づくノード構造を提供することにある。
【０００９】
【課題を解決するための手段】
前記技術的課題を達成するための、本発明による深さイメージに基づくノード構造の一例は、それぞれのピクセルに対する色相を含む色相イメージが記録されるテクスチャーフィールドと、前記それぞれのピクセルに対する深さ値が記録される深さフィールドとを含む。
【００１０】
本発明による深さイメージに基づくノード構造の他の例は、イメージ平面の大きさ情報が記録される大きさフィールドと、前記イメージ平面を形成するそれぞれのピクセルに対する深さ値の解像度情報が記録される解像度フィールドと、前記それぞれのピクセルに対する複数の深さ情報が記録される深さフィールドと、前記それぞれのピクセルに対する色相情報が記録される色相フィールドとを含む。
【００１１】
本発明による深さイメージに基づくノード構造のまた他の例は、イメージ平面を眺める視点が記録される視点フィールドと、前記視点から前記イメージ平面までの視野領域が記録される視野フィールドと、前記視点から前記イメージ平面までの投影方法が記録される投影方法フィールドと、前記視点から可視領域の近い境界平面までの距離及び前記視点から遠い境界平面までの距離が記録される距離フィールドと、色相イメージが記録されるテクスチャーフィールドとを含む。
【００１２】
本発明による深さイメージに基づくノード構造のさらに他の例は、客体を含む閉じられたキューブの側面に接することができるオクツリーリーフの最大値が記録される解像度フィールドと、前記オクツリーの内部ノードの構造が記録されるオクツリーフィールドと、前記内部ノードに対応する参照イメージのインデックスが記録されるインデックスフィールドと、前記参照イメージが記録されるイメージフィールドとを含む。
【００１３】
本発明によれば、イメージ基盤モデルに対するレンダリング時間が多角形の場合のように形態的な複雑性に比例せず、一般的に参照及び出力イメージに存在するピクセルの数に比例する。さらに、イメージ基盤表現が現実世界の客体と場面に適用されれば数百万個の多角形を使用せずに低コストで自然的な場面の写真のような現実的なレンダリングが可能になる。
【００１４】
【発明の実施の形態】
本出願は米国商標特許庁に仮出願された４件の出願を基礎出願として優先権を主張して出願される。以下、本出願の優先権主張の基礎になった４件の仮出願書に記載された発明を記述する。
【００１５】
Ｉ．ＩＳＯ／ＩＥＣＪＴＣ１／ＳＣ２９ＷＧ１１動映像及び音響のコーディング
［１．序論］
以下、イメージに基づくレンダリング（ＡＦＸＡ８．３）についての主要な実験結果を説明する。
この実験は、深さ情報を有するテクスチャーを利用したイメージに基づくレンダリング技術に関するものである。また、１０月に開催されたＡＦＸａｄｈｏｃグループ会議期間中の５７次ＭＰＥＧ会議以後に行われた実験結果に基づいてノード定義に加えられたいくつかの変更を提示するものである。
【００１６】
［２．実験結果］
＜２．１．テストモデル＞
●静止客体に対して
■シンプルテクスチャーを有する深さイメージノード
◆犬
◆チラノサウルスレックス（約２０個のカメラを使用した深さイメージ）
◆テラスク（モンスター）（約２０個のカメラを使用した深さイメージ）
◆膽星台（約２０個のカメラを使用した深さイメージ）
◆椰子（約２０個のカメラを使用した深さイメージ）
■階層テクスチャーを有する深さイメージノード
◆天使
■ポイントテクスチャーを有する深さイメージノード
◆天使
■オクツリーイメージノード
◆生物
●動的客体に対して
■シンプルテクスチャーを有する深さイメージノード
◆竜
◆背景での竜
■階層テクスチャーを有する深さイメージノード
◆提供されない
■オクツリーイメージノード
◆ロボット
◆背景での竜
●今後より多くのデータ（スキャニングまたはモデリングされた）が提供されるであろう。
【００１７】
＜２．２．テスト結果＞
●シドニーで提案されたあらゆるノードはｂｌａｘｘｕｎｃｏｎｔａｃｔ４．３参照ソフトウェアに統合されている。しかし、まだｃｖｓサーバーにソースが更新されていない。
●イメージに基づくレンダリング（ＩｍａｇｅＢａｓｅｄＲｅｎｄｅｒｉｎｇ：ＩＢＲ）に対する動的フォーマットは、それぞれの動映像ファイルから同じキーフレームに存在するイメージが同時に与えられるように、複数の動映像ファイルの間に同調される必要がある。
【００１８】
しかし、現在の参照ソフトウェアは、ＭＰＥＧシステムではできるだけこのような同調能力を支援しない。
従って、現在動的フォーマットは、あらゆる動的データが既にファイルに存在すると仮定することによって表面化される。暫定的にＡＶＩフォーマットの動映像ファイルがそれぞれの動的テクスチャーに使われる。
【００１９】
●階層文脈に対するいくつかの実験を実行した後、階層テクスチャーノードは効率的でないことが明らかになった。このようなノードは階層深さイメージに対して提案された。しかし、それを支援できるポイントテクスチャーノードがまた存在する。従って、ノード定義で階層テクスチャーノードを削除することを提案する。
●図１は現在参照ソフトウェアに統合されたＩＢＲの例である。
【００２０】
［３．ＩＢＲノード定義に対するアップデート］
ＩＢＲ提案に対するシドニー会議の結論は、イメージ及びカメラ情報を含むＩＢＲストリームを有さねばならず、ＩＢＲノードはそれへのリンク（ｕｒｌ）を有すればよいということである。
しかし、Ｒｅｎｎｅｓで開催されたａｄｈｏｇグループ会議でのＩＢＲに対する議論結果は、ＩＢＲノードとストリームのいずれもがイメージ及びカメラ情報を有さねばならないということである。
従って、ＩＢＲノードに対するノード定義は次のようにアップデートされる。
なお、ＩＢＲストリームの必要性はｕｒｌフィールドを説明する章で説明される。
【００２１】
デコーダ（ビットストリーム）−ノード定義

【００２２】
深さイメージノード（ＤｅｐｔｈＩｍａｇｅｎｏｄｅ）は一つのＩＢＲテクスチャーを定義する。複数の深さイメージノードが互いに関連する場合、これらは一つのグループで処理されるので同じ変換ノードの下に位置せねばならない。
【００２３】
ｄｉＴｅｘｔｕｒｅフィールドは、深さを有するテクスチャーを特定する。このテクスチャーは、深さイメージノードに定義される領域にマッピングされる
それは、多様な形態の深さイメージテクスチャー（シンプルテクスチャーまたはポイントテクスチャー）の一つである。
【００２４】
位置（ｐｏｓｉｔｉｏｎ）及び方向（ｏｒｉｅｎｔａｔｉｏｎ）フィールドは、ローカル座標系におけるＩＢＲテクスチャーの視点の相対的位置を特定する。
方向は基本方向に対する相対的回転を特定する一方、位置は座標系の原点（０，０，０）に相対的である。
基本位置及び方向で、観察者は右側には＋Ｘ軸と垂直に＋Ｙ軸とを有する原点に向かって−Ｚ軸を見下ろしながらＺ軸上に位置する。しかし、変換階層は視点の最終位置及び方向に影響を与える。
【００２５】
ｆｉｅｌｄＯｆＶｉｅｗフィールドは、位置及び方向フィールドにより定義されたカメラ視点からの視角を特定する。最初の値は水平角を意味し、第二の値は垂直角を意味する。基本値は４５ラジアンである。
しかし、直交（ｏｒｈｏｇｏｎａｌ）フィールドが真（ＴＲＵＥ）と設定されればｆｉｅｌｄＯｆＶｉｅｗフィールドは隣接平面（ｎｅａｒＰｌａｎｅ）と遠接平面（ｆａｒＰｌａｎｅ）との幅と高さを意味する。
【００２６】
隣接平面（ｎｅａｒＰｌａｎｅ）と遠接平面（ｆａｒＰｌａｎｅ）フィールドは、視点から可視領域の隣接平面及び遠接平面までの距離を特定する。テクスチャー及び深さデータは、隣接平面、遠接平面そしてｆｉｅｌｄＯｆＶｉｅｗにより囲まれた領域を示す。深さデータは隣接平面から遠接平面までの距離で正規化される。
【００２７】
直交フィールドは、ＩＢＲテクスチャーの視覚形態を特定する。真と設定されている場合にＩＢＲテクスチャーは直交視点に基づく。そうでない場合にＩＢＲテクスチャーは遠近視点に基づく。
【００２８】
ｄｅｐｔｈＩｍａｇｅＵｒｌフィールドは付加的に次の内容を含みうる深さイメージストリームの住所を特定する。
●位置（ｐｏｓｉｔｉｏｎ）
●方向（ｏｒｉｅｎｔａｔｉｏｎ）
●ｆｉｅｌｄＯｆＶｉｅｗ
●近接平面（ｎｅａｒＰｌａｎｅ）
●遠接平面（ｆａｒＰｌａｎｅ）
●直交（ｏｒｔｈｏｇｏｎａｌ）
●ｄｉＴｅｘｔｕｒｅ（シンプルテクスチャーまたはポイントテクスチャー）
●上位フィールドのフラグオン／オフに対する１バイトヘッダ
●

【００２９】
シンプルテクスチャーノードは単層のＩＢＲテクスチャーを定義する。
テクスチャー（ｔｅｘｔｕｒｅ）フィールドは、各ピクセルに対する色相を含む平面イメージを特定する。これは多様な形態のテクスチャーノード（イメージテクスチャー、動映像テクスチャーまたはピクセルテクスチャー）のうち一つである。
深さフィールドは、テクスチャーフィールドの各画素の「深さ」を定義する。深度マップの大きさはテクスチャーフィールド画像若しくは映像のサイズと同じである。これは、多様な形態のテクスチャーノード（イメージテクスチャー、動映像テクスチャーまたはピクセルテクスチャー）のうち一つである。
深さノードがＮＵＬＬである場合若しくは深さフィールドが特定されていない場合、テクスチャーフィールドのアルファチャンネルは深さマップとして利用される。
【００３０】

【００３１】
ポイントテクスチャー（ＰｏｉｎｔＴｅｘｔｕｒｅ）ノードは複層のＩＢＲ点を特定する。
【００３２】
幅（ｗｉｄｔｈ）及び高さ（ｈｅｉｇｈｔ）フィールドはテクスチャーの幅及び高さを特定する。
【００３３】
深さ（ｄｅｐｔｈ）フィールドは横断順に投影された面で各点に対する複数の深さを特定して（正規化された座標上で）、左側下段のコーナーにある点から出発して右側に横断しながら上側にある線に移動する前に水平線で終了する。それぞれの点に対して、深さ（ピクセル）番号が先に貯蔵され、深さ番号値は次に貯蔵される。
【００３４】
色相（ｃｏｌｏｒ）フィールドは現在のピクセルの色相を定義する。順序は、それぞれの点に対する深さ（ピクセル）番号が含まれていないことを除いては、深さフィールドと同一である。
【００３５】

【００３６】
オクツリーイメージ（ｏｃｔｒｅｅｉｍａｇｅ）ノードは、オクツリー構造及びこれらの投影されたテクスチャーを定義する。全体オクツリーの閉じられたキューブの大きさは１×１×１であり、オクツリーキューブの中心はローカル座標系の原点である（０，０，０）である。
【００３７】
オクツリー解像度（ｏｃｔｒｅｅｒｅｓｏｌｕｔｉｏｎ）フィールドは、閉じられたキューブの側面にかかったオクツリーリーフの最大数を特定する。オクツリーレベルは次の式を使用してオクツリー解像度から決定される。
【００３８】
【数１】

【００３９】
オクツリーフィールドは、オクツリー内部ノードの集合を特定する。それぞれの内部ノードはバイトにより表現される。
このようなバイトのｉ番目ビットの「１」は、内部ノードのｉ番目の子に対して子ノードが存在することを意味する。
一方、「０」は子ノードが存在しないことを意味する。
オクツリー内部ノードの順序は、オクツリーの幅優先横断順序にならねばならない。内部ノードの８個の子の順序が図２に示されている。
【００４０】
オクツリーイメージ（ｏｃｔｒｅｅｉｍａｇｅｓ）フィールドは、ｄｉＴｅｘｔｕｒｅフィールドに対してシンプルテクスチャーを有する深さイメージノードの集合を特定する。しかし、深さイメージに対する隣接平面、遠接平面フィールド及びシンプルテクスチャーで深さフィールドは使われない。
【００４１】
ｏｃｔｒｅｅＵｒｌフィールドは次のような内容を有するオクツリーイメージストリームの住所を特定する。
●フラグに対するヘッダ
●オクツリー解像度
●オクツリー
●オクツリーイメージ（複数の深さイメージノード）
■隣接平面は使われない
■遠接平面は使われない
■ｄｉＴｅｃｔｕｒｅ→深さを有していないシンプルテクスチャー
【００４２】
ＩＩ．ＩＳＯ／ＩＥＣＪＴＣ１／ＳＣ２９ＷＧ１１動映像及び音響のコーディング
【００４３】
［１．序論］
以下、ＩＢＲ（ＡＦＸＡ８．３）に対する主要な実験結果を説明する。
この実験は、深さ情報を有するテクスチャーを利用したＩＢＲ技術に関するものである。また、１０月に開催されたＡＦＸａｄｈｏｃグループ会議期間中の５７次ＭＰＥＧ会議及び議論以後の実験に基づいてノード定義に加えられたいくつかの変更が提示するものである。
【００４４】
［２．ｏｃｔｒｅｅＵｒｌに対するストリーミングフォーマット］
＜２．１．ストリームフォーマット＞
オクツリーイメージノードは、オクツリーイメージストリームの住所を特定するｏｃｔｒｅｅＵｒｌフィールドを含む。このストリームは付加的に次のような内容を含むことができる。
●フラグに対するヘッダ
●オクツリー解像度
●オクツリー
●オクツリーイメージ（複数の深さイメージノード）
■隣接平面は使われない
■遠接平面は使われない
■ｄｉＴｅｘｔｕｒｅ→深さを持っていないシンプルテクスチャー
【００４５】
オクツリーフィールドはオクツリー内部ノード集合を特定する。それぞれの内部ノードはバイトにより表現される。このようなバイトのｉ番目ビットの「１」は、内部ノードのｉ番目の子に対して子ノードが存在することを意味する。
一方、「０」は、子ノードが存在しないことを意味する。オクツリー内部ノードの順序はオクツリーの幅優先横断順序にならねばならない。内部ノードの８つの子の順序が図２に示されている。
【００４６】
オクツリーイメージノードのオクツリーフィールドは簡単なフォーマットである。しかし、このフィールドは、効率的なストリーミングのために、さらに圧縮しても良い。
【００４７】
次に、オクツリーイメージノードのオクツリーフィールドに対する圧縮方案を記述する。
【００４８】
＜２．２．オクツリーフィールドに対する圧縮方案＞
ＤＩＢＲのオクツリー表現において、データは形態成分を表現するオクツリーフィールドで構成される。
オクツリーは閉じられたキューブ内に存在する点の集合であり、客体表面を完全に表現する。
圧縮された表現から形態の同一でない再生はかなり目立つアーチファクトを生じる。従って、形態は情報の損失なしに圧縮されねばならない。
【００４９】
＜２．２．１．オクツリー圧縮＞
深さ優先横断オクツリー形態で表現されるオクツリーフィールドの圧縮のために、部分マッチングによる予測（ＰｒｅｄｉｃｔｉｏｎｂｙＰａｒｔｉａｌＭａｔｃｈｉｎｇ：ＰＰＭ）接近の一部概念を利用した無損失圧縮方法を開発した。
【００５０】
この方法における主要な思想は、“文脈”と呼ばれるいくつかの以前シンボルによる次のシンボルの“予測”（すなわち、確率推定）である。
それぞれの文脈に対して、文脈に存在する各シンボルの推定発生確率を示す確率テーブルが存在する。
この確率テーブルは、領域コーダと呼ばれる算術コーダと一緒に使用される。
【００５１】
この方法の主要な特性は、以下の２点である。
１．子ノードに対する文脈として親ノードを使用する。
２．文脈の数を減らすために‘直交不変’推定を使用する。
【００５２】
第２の思想は‘親−子’ノードの対に対する‘遷移確率’は直交変換（回転及び対称）の下で通常的に不変という観察に基づくものである。
【００５３】
このような仮定は添付１に記述されている。
このような仮定により、極端に多くの確率テーブルを必要とせずに、複雑な文脈が使用可能となる。
順に、これによりデータサイズ及び速度面でかなり良好な結果を得られる。多くの文脈を使用するほど推定された確率がより明確になり、従って、コードがより簡潔になる。
【００５４】
コーディングは、文脈モデルによる確率テーブルの生成及び更新過程である。
提案された方法で、文脈はオクツリー構造の親−子階層においてモデリングされる。
まず、内部下位分割した後に、下位キューブの発生を表すビットを有するバイトノードと、シンボルを定義する。
従って、オクツリーでそれぞれのノードはシンボルになることができ、それらの数値は０〜２５５になる。確率テーブル（ＰｒｏｂａｂｉｌｉｓｔｉｃＴａｂｌｅ：ＰＴ）は２５６個の整数値を含む。
全体変数の和により割られたｉ番目変数値（０≦ｉ≦２５５）は、ｉ番目シンボル発生頻度（確率推定）と同一である。
確率文脈テーブル（ＰｒｏｂａｂｉｌｉｓｔｉｃＣｏｎｔｅｘｔＴａｂｌｅ：ＰＣＴ）はＰＴの集合である。シンボルの確率はＰＴの一つから決定される。特定のＰＴの数は文脈に依存する。ＰＣＴの例が表１に示されている。
下記表１は、ＰＣＴの成分を示す表である。
【００５５】
【表１】

【００５６】
コーダは次のように動作する。コーダはまず０−文脈モデルを使用する（すなわち、総てのシンボルに対して一つのＰＴを使用し、均一分布から始まって、新しくコーディングされたシンボルの次にＰＴを更新する）。
【００５７】
ツリーは深さ優先順序で横断される。十分な資料が収集されれば（実験的に発見値は５１２個のコーディングされたシンボルである）、コーダは１−文脈モデルに転換する。１−文脈モデルは次のように特定された２７個の文脈を有する。
【００５８】
対称及び座標軸に対して９０゜回転（添付２参照）を含む３２個の固定された直交変換集合を想定すれば、
これらの下位キューブに対する積層パターンによってシンボルを分類できる。
われらの方法によれば、ここではグループと呼ばれる次のような特性を有する２７個のシンボル集合が存在する。２個のシンボルは同じグループに属すればこのような固定された変換のうち一つにより連結される。
【００５９】
バイト表記において、グループは２７個の数字の集合（添付２参照）により表現される。
確率テーブルＰＴは、（２５６個のテーブルが存在する場合は）親ノード自体には依存しない。むしろ親ノードが属するグループ（図２で親シンボルと命名された）に依存すると考える。（従って、２７個のテーブル）。
転換時、総ての文脈に対する確率テーブルＰＴは、０−文脈ＰＴのコピー対して設定される。そして、２７個の確率テーブルＰＴはコーディングの際に更新される。
【００６０】
２０４８個（さらに他の発見値）のシンボルが１−文脈モデルにコーディングされた後、文脈として対（親シンボル、ノードシンボル）を使用する２−文脈モデルに転換する。
ノードシンボルは、単純に親ノードにおける現在ノードの位置である。従って、２−文脈モデルに対して２７×８個の文脈が存在する。
このようなモデルへの転換時、それぞれの文脈に対して得られた確率テーブルＰＴは、このような文脈の各ノード‘内部に存在する’に対して使われ、この時点から独立的に更新される。
【００６１】
技術的により詳細に説明すれば、１−文脈及び２−文脈モデルに対するエンコーディングは以下のようにして進行する。
現在シンボルの文脈（すなわち、親ノード）に対して、これらのグループが決定される。このグループの決定はテーブル検索により実施される（形態分析はプログラム開発段階で実施される）。
【００６２】
そして、属するグループの成分の中の（全部任意に選択された）成分について、文脈を‘標準’にする直行変換を行う。
同様の変換が、シンボル自体にも適用される（このような演算もテーブル検索として実施され、あらゆる可能な結合に対するあらゆる計算はもちろん事前に実施される）。
事実上、この計算は、シンボルの文脈を含むグループについての確率テーブルＰＴに存在する現在のシンボルの正確な位置の計算である。
そして、対応する確率が領域コーダに入力される。
【００６３】
すなわち、親シンボルとサブノードポジションとが与えられると、グループＩＤと、ＰＣＴにおける確率テーブルＰＴの位置を識別する文脈ＩＤ（ＣｏｎｔｅｘｔＩＤ）が決定される。
確率テーブルＰＴにおける確率分布そして文脈ＩＤは、領域コーダに入力される。
エンコーディング後、ＰＣＴは次のエンコーディングでの使用のために更新される。
領域コーダはビットの代りにバイトに再正規化する算術コーディングの変形であり、従って、算術符号法より０．０１％低い圧縮率を有すると共に、２倍も速く動作することに注目せねばならない。
【００６４】
デコーディング手順は本質的にエンコーディング手順の逆である。これは文脈決定、確率更新等において正確に同じ方法を使用するので、説明する必要がない完全に標準的な手順である。
【００６５】
＜２．３．テスト結果＞
図３は、静止及び動的モデルに対する本接近法の比較のためのテーブルである（横軸は圧縮率を表示する）。オクツリー圧縮率は元来オクツリーの大きさと比較して約１．５〜２倍で変わり、一般的な目的の無損失圧縮性能（ＲＡＲプログラムのようなＬｅｍｐｅｌ−Ｚｉｖ基盤）が約３０％良好である。
【００６６】
［３．ｄｅｐｔｈＩｍａｇｅＵｒｌに対するストリーミングフォーマット］
＜３．１．ストリームフォーマット＞
深さイメージノードは、深さイメージストリームのアドレスを特定するｄｅｐｔｈＩｍａｇｅＵｒｌフィールドを含む。このストリームは、次のような内容を付加的に含むことができる。
【００６７】
●下のフィールドのオン／オフフラグのための１バイトヘッダ
●位置（ｐｏｓｉｔｉｏｎ）
●方向（ｏｒｉｅｎｔａｔｉｏｎ）
●ｆｉｅｌｄＯｆＶｉｅｗ
●隣接平面（ｎｅａｒＰｌａｎｅ）
●遠接平面（ｆａｒＰｌａｎｅ）
●直交（ｏｒｔｈｏｇｏｎａｌ）
●ｄｉＴｅｘｔｕｒｅ（シンプルテクスチャーまたはポイントテクスチャー）
【００６８】
深さイメージノードのｄｉＴｅｘｔｕｒｅに使われるポイントテクスチャーノードの定義は次の通りである。

【００６９】
ポイントテクスチャー（ＰｏｉｎｔＴｅｘｔｕｒｅ）ノードはＩＢＲ点に対する複数の層を定義する。
幅（ｗｉｄｔｈ）と高さ（ｈｅｉｇｈｔ）フィールドとはテクスチャーの幅と高さとを特定する。
深さ（ｄｅｐｔｈ）フィールドは、
左側下部コーナーに存在する点から出発して、上位線に移動する前に右側に横断して水平線で終了する横断
投影面の各点（正規化された座標）の複数の深さを特定する。
【００７０】
それぞれの点に対して、深さ（ピクセル）の番号がまず貯蔵され、深さ値の番号が次に貯蔵される。
色相（ｃｏｌｏｒ）フィールドは現在のピクセルの色相を特定する。
順序はそれぞれの点に対して深さ（ピクセル）の番号が含まれないということを除いては深さフィールドと同一である。
【００７１】
ポイントテクスチャーに対する深さ及び色相フィールドは処理されていないフォーマットであり、このようなフィールドの大きさはかなり大きいはずである。従って、このようなフィールドは効率的なストリーミングのために圧縮される必要がある。次の章は、ポイントテクスチャーノードのフィールドに対する圧縮方案を記述する。
【００７２】
＜３．２．ポイントテクスチャーに対する圧縮方案＞
＜３．２．１．深さフィールドの圧縮＞
ポイントテクスチャーノードの深さフィールドは、単純に‘区分された閉じられたキューブ’に存在する点の集合である。底面を投影面と仮定する。
モデルに対してｍ×ｎ×１大きさの格子が与えられ、点がこの格子のセル（オクツリーの場合にこれらをボクセルと称する）の中心に位置する場合、占有されたボクセルは「１」に、空いているボクセルは「０」と想定できる。
【００７３】
それにより、ビット（ｍ×ｎ×１ビット）の結果集合は、バイトストリームで構成される。これは深さが８である層と投影面（深さの大きさが８の倍数ではない場合に、必要ならば０である最後のバイト層を保護しながら）における一般的な順序（“列方向”）により深さ（投影面に垂直の）方向に存在するボクセルを横断することによって達成される。
【００７４】
従って、点の集合を８ビットグレースケールイメージの積層（多様な１６ビットイメージ）として考えられる。ボクセルとビットに対応する図が図４（ａ）に示されている。
【００７５】
例えば、図４（ｂ）で黒色四角形は客体上の点に対応する。水平面は投影面である。
高さが１６である‘スライス’を仮定し、列をバイトとする。すなわち、図面で表示された点の上に存在する列は、値「１８」と「１」を有する２バイトスタック（または１６−ｂｉｔｕｎｓｉｇｎｅｄｉｎｔｅｇｅｒ２７４）を表す。
もし、このような方式で得られたバイトの集合に最適のＰＰＭ基盤圧縮方法を適用すれば良好な結果を得られる。しかし、単純な１−文脈方法をここに直接適用すれば（もちろん直交不変または階層的な文脈はここに使用できない）、これは多少低級な圧縮を招く。
【００７６】
下記表２は、ＬＤＩ形態表現の他の形態−ＢＶＯＣ、最適ＰＰＭ圧縮手段により圧縮された上のバイトアレイ、及び現在使われた圧縮手段により圧縮された同じアレイに対して要求される体積テーブルである（単位：Ｋｂｙｔｅｓ）。
【００７７】
【表２】

【００７８】
＜３．２．２．色相フィールド圧縮＞
ポイントテクスチャーノードの色相フィールドは、客体の点に起因した色相の集合である。
オクツリーの場合とは異なり、色相フィールドは深さフィールドと一対一対応関係にある。
概念は、色相データを公知の損失技術の一つにより圧縮されうる一つのイメージで表現することである。このようなイメージで最も重要なのは、オクツリーまたは深さイメージの場合における参照イメージよりはるかに小さいということであり、これはこのような接近法の実質的な動機である。イメージは多様な自然的な順序で深さ点をスキャニングして得られる。
【００７９】
まず、ＬＤＩ（ポイントテクスチャー）に対するオリジナルの貯蔵フォーマットにより記録されたスキャニング順序−形態の‘深さ優先’スキャニング−を考慮する。
多重ピクセルが、単純なピクセルと同じく自然的な順序で投影面にわたってスキャニングされ、同じ多重ピクセル内部の点が深さ方向にスキャニングされる。
このようなスキャニング順序は色相の１Ｄアレイ（１次ｎｏｎｚｅｒｏ多重ピクセル、２次ｎｏｎｚｅｒｏ多重ピクセル）を生成する。
【００８０】
深さが把握されてからすぐ点の色相は連続的にこのようなアレイから再生成されうる。
イメージ圧縮方法を適用できるようにするために、このような長いストリングを２Ｄアレイに一対一マッピングせねばならない。これは多様な方法により実施できる。
【００８１】
色相ストリングが８×８ブロックで配列される時、下のテストで使われた接近法はいわゆる“ブロック単位スキャン”である。結果イメージは図５に示されている。
【００８２】
このようなイメージの圧縮は標準ＪＰＥＧを含む色々な方法により実施される。少なくともこのような形態の色相スキャンに対して［５］に記述されたテクスチャー圧縮方法を使用する時、もっと良好な結果が得られることが立証された。
【００８３】
このような方法はそれぞれの８×８ブロックに対する適応ローカルパレタイジングに基づく。ここには、８倍圧縮及び１２倍圧縮（ピクセル当り２４ビットである‘ｒａｗ’ｔｒｕｅ−ｃｏｌｏｒＢＭＰフォーマットと比較した場合）の２つのモードがある。
このような形態のイメージでこのような方法の成功はそのパレット特性から正確に説明されうる。パレット特性により前面と背面とから点を混合することによって発生する地域的な色相変化を明確に考慮できる（これは“天使”の場合とはかなり異なりうる）。最適スキャンに対する調査の目的はこのような変化をできるだけ最大限度に減らすことである。
【００８４】
＜３．３．テスト結果＞
オリジナルのフォーマット及び圧縮されたフォーマットにおけるモデル例が添付３に図示されている。
他のモデル（イナゴ）は非常に良好な一方、一部のモデル（すなわち、天使）の品質は圧縮後に依然として満足するほどではない。しかし、このような問題は適切なスキャニングで解決できると考えられる。
【００８５】
はなはだしくは１２倍圧縮モードが利用されることもあるので、全体的な圧縮はかなり増加する。最後に、無損失圧縮は形態圧縮で最適ＰＰＭ基盤結果に接近するために改善できる。
ここに圧縮率に対するテーブルを提示する。
【００８６】
【表３】

【００８７】
＜４．結論＞
本文書には深さイメージに基づく表現に対する主要な実験結果（ＡＦＸＡ８．３）が記述されている。ＤＩＢＲストリームが紹介されたが、ＤＩＢＲストリームはＤＩＢＲノードのｕｒｌフィールドを通じて連結される。このようなストリームはそれぞれのアイテムを選択的なものにするためのフラグと共にＤＩＢＲノードに存在するあらゆるアイテムで構成される。また、オクツリー及びポイントテクスチャーデータの圧縮が検討された。
【００８８】
≪添付１≫
＜ＢＶＯ圧縮アルゴリズムにおいて文脈直交不変の形態的意味＞
直交不変の概念の例が図６に図示されている。垂直軸を中心に時計回り方向に９０°回転すると仮定する。ノードとそれの以前親ノードに対する任意の積層パターンと回転後のノードを仮定する。それにより、２つの相異なるパターンが同じパターンとして取扱われうる。
【００８９】
≪添付２≫
＜グループと変換＞
１．３２個の固定された直交変換
各変換は５ビットワードにより特定される。ビット組合わせは、以下のような基本変換で構成される（すなわち、ｋ番目ビットが１であれば対応する変換が実施される）。
●１番目ビット−ｘ及びｙ軸を交換
●２番目ビット−ｙ及びｚ軸を交換
●３番目ビット−ｙ−ｚ平面に対称
●４番目ビット−ｘ−ｚ平面に対称
●５番目ビット−ｘ−ｙ平面に対称
【００９０】
＜２．２７グループ＞
それぞれのグループに対してここにグループの順序とそれの要素のｎｏｎｚｅｒｏビット数を提示する。これらはボクセル設定時にＮｕｍｂｅｒＯｆＧｒｏｕｐ、ＱｕａｎｔｉｔｙＯｆＧｒｏｕｐ、及びＮｕｍｂｅｒＯｆＦｉｌｌＢｉｔｓに記録される。
【００９１】
【表４】

【００９２】
＜３．シンボル及び変換＞
それぞれのシンボルｓに対してグループｇが属するインデックスとそれをグループの‘標準’要素として取扱う変換ｔの値とを提示する。
シンボルの２進番号は次のようにボクセル２進座標にマッピングされる。番号のｉ番目ビットは２進座標ｘ＝ｉ、ｙ＝ｉ（１≪１）、そしてｚ＝ｉ（１≪２）を有する。
【００９３】
【表５】

【００９４】
≪添付３≫
＜ポイントテクスチャー圧縮画面出力＞
最適ＰＰＭ基盤方法に対する形態圧縮図面が図７〜図９に示されている。
【００９５】
ＩＩＩ．深さ映像基盤表現に対する主要な実験結果
【００９６】
［１．序論］
以下、深さ映像基盤表現（ＤｅｐｔｈＩｍａｇｅ−ＢａｓｅｄＲｅｐｒｅｓｅｎｔａｔｉｏｎ：ＤＩＢＲ）（ＡＦＸＡ８．３）に対する主要な実験結果を説明する。
この実験は、深さ情報を有するテクスチャーを利用した深さ基盤イメージ表現ノードに関するものである。
ノードはパッタヤ（Ｐａｔｔａｙａ）で開催された会議で受容され、委員会草案に対する提案に含まれている。しかし、オクツリーノードと深さイメージノードとを通したこのような情報のストリーミングは依然として進行中にある。ストリーミングフォーマットは、オクツリーイメージノードに対するオクツリーフィールド及びポイントテクスチャーノードに対する深さ／色相フィールドの圧縮を含む。
【００９７】
［２．ＤＩＢＲフォーマット圧縮］
ここでリンクを持っていないオクツリーデータ構造の効率的な新しい無損失圧縮技術を開示する。これにより既に簡潔な表現の体積を実験により約１．５〜２倍減らすことができる。また、エントロピーコーディングと特化されたブロック基盤テクスチャー圧縮方法とを結合した中間ボクセル表現を使用するいくつかのポイントテクスチャーフォーマットに対する無損失及び損失圧縮技術を提案する。
【００９８】
＜２．１．オクツリーイメージ圧縮＞
オクツリーイメージでオクツリーイメージフィールドとオクツリーフィールドとは個別的に圧縮される。
開示された方法は、オクツリーイメージに対しては一定程度の可視的に収容される歪曲が許容される一方で、オクツリーフィールドは損失なしに圧縮されねばならないという概念に基づいて開発された。
オクツリーイメージフィールドは、ＭＰＥＧ−４イメージ圧縮手段（静的モデルに対する）または動映像圧縮道具（動的モデルに対する）により圧縮される。
【００９９】
＜２．１．１．オクツリーフィールド圧縮＞
オクツリー圧縮は、非常に簡略でリンクを持っていない２進ツリー表現の圧縮を扱っているため、オクツリーイメージ圧縮の最も重要な部分である。
しかし、実験で後述される方法は、このような構造の体積を大体元来の半分に縮めた。動的なオクツリーイメージバージョンで、オクツリーフィールドはそれぞれの３Ｄフレームに対して個別的に圧縮される。
【０１００】
＜２．１．１．１．文脈モデル＞
圧縮はデータの形態的特性を明確に使用する多様な適応算術符号法（ａｒｉｔｈｍｅｔｉｃｃｏｄｉｎｇ）（‘領域エンコーダ’で実行される［３］［４］）により実施される。
オクツリーはバイトストリームである。それぞれのバイトはツリーのノード（すなわち、サブキューブ）を示し、バイトのビットは内部的な分割後のサブキューブの占有を示す。ビットパターンはノードの積層パターンと呼ばれる。提案された圧縮アルゴリズムは次のような方式でバイトを一つずつ処理する。
【０１０１】
●現在バイトに対する文脈決定
●このような文脈で現在バイトの発生‘確率’（正規化された頻度）を文脈に対応する‘確率テーブル’（ＰＴ）から検索
●領域エンコーダに確率値提供
●現在文脈で現在バイト発生の頻度に１を足して現在ＰＴ更新（必要時、作業実行後に再正規化、下の詳細な説明を参照）
【０１０２】
従って、コーディングは文脈モデルによるＰＴの生成及び更新過程である。文脈基盤適応算術コーディング技術で（‘部分マッチングによる予測’のように）、シンボル文脈は一般的にいくつかの前置シンボル列である。しかし、われらの場合、オクツリー構造及びデータの形態的特性を活用することによって圧縮効率が増進される。開示された接近法はオクツリー圧縮の問題において明確に新しい２つのアイディアに基づく。
【０１０３】
Ａ．現在ノードに対して、文脈はそれの親ノードまたは｛親ノード、親ノードに位置した現在ノード｝で構成された対のうち一つであり、
【０１０４】
Ｂ．特定の親ノードにおいて特定の形態的位置で与えられたノード発生‘確率’は任意の直交（回転または対称のような）変換集合に対して不変であると仮定する。
ｘ−ｚ平面上で−９０゜回転する変換Ｒに対する仮定‘Ｂ’は図６に示されている。‘Ｂ’の裏面に存在する基本的な概念は、特定な形態の親ノードにおいて特定な形態の子ノードの発生確率は単にこれらの相対的な位置に依存するということである。このような仮定はＰＴの分析による実験で立証された。これにより、過度に多くのＰＴを保有せずに複雑な文脈を使用できる。順に、これによりデータサイズ及び速度面でかなり良好な結果を得られる。複雑な文脈を使用するほど推定された確率がより明確になり、従ってコードがより簡潔になることに注目せねばならない。
【０１０５】
これから変換集合を紹介する。確率分布は不変であると仮定する。われらの状況に適用するために、このような変換は閉じられたキューブを維持しなければならない。ユークリッド空間での直交変換の集合Ｇを考慮する。直交変換は、３個の基本変換（生成子）ｍ_１、ｍ_２、及びｍ_３の任意の番号及び順序上のあらゆる成分により得られる。
【０１０６】
【数２】

【０１０７】
ここで、ｍ_１及びｍ_２は各々ｘ＝ｙ及びｙ＝ｚ平面への投影であり、ｍ_３はｘ＝０平面への投影である。投影により生成されたグループ理論の典型的な結果のうち一つはＧが４８個の個別的な直交変換を含み、ある意味ではキューブを自体的に取る直交変換の最大グループである（いわゆる、ｃｏｘｅｔｅｒｇｒｏｕｐ）。例えば、図６に示された回転子Ｒは生成子を通じて次のように表現される。
【０１０８】
【数３】

【０１０９】
ここで、‘・’との行列乗算である。
【０１１０】
オクツリーノードに適用されたＧからの変換は、相異なる下位キューブの積層パターンを有するノードを算出する。これによりノードの下位キューブの積層パターンによってノードを分類できる。グループ理論言語を使用する時、Ｇはオクツリーノードのあらゆる積層パターンに対する集合として作用すると言及する。計算によれば、２２個の個別的なクラス（またグループ理論でオービットと称される）が存在する。そして、定義によりＧからの変換により連結されるならば、二つのノードが同じクラスに属する。一つのクラスで要素番号は１から２４まで多様であり、常に４８の除数である。
【０１１１】
仮定‘Ｂ’の実質的な重要性は、ＰＴが親ノードその自体に従属的でなく、単に親ノードが属するクラスに従属的であるということである。親基盤文脈に対して２５６個のテーブルがありえるが、前者の場合に親−子位置基盤文脈に対して付加的な２５６×８＝２０４８個のテーブルが必要である一方、後者の場合に親−クラス基盤文脈に対して２２個のテーブルと２２×８１７６個のテーブルとが必要であるということに注目せねばならない。従って、相対的に少数のＰＴを有して同等に複雑な文脈を使用することが可能である。作成されたＰＴは下記表６に記載された形態をとることができる。
【０１１２】
【表６】

【０１１３】
＜２．１．１．２．エンコーディング手順＞
ＰＴに対する統計をより正確にするために、エンコーディング手順の３つの過程で相異なる方式が収集される。
【０１１４】
●‘０−文脈モデル’とされている最初の段階で文脈を全く使用せず、均一な分布から出発して２５６個のエントリを保有した一つのＰＴを維持する。
●最初の５１２個のノード（実験的に発見された番号）がエンコーディングされてすぐ、親ノードを文脈として使用する‘１−文脈モデル’に転換する。転換時、０−文脈ＰＴはあらゆる２２個の文脈に対するＰＴに複写される。
●次の２０４８個のノード（他の発見値）がエンコーディングされた後、‘２−文脈モデル’に転換する。この瞬間に親パターンの１−文脈ＰＴは同じ親パターンでそれぞれの位置に対するＰＴに複写される。
【０１１５】
このようなアルゴリズムの核心は、現在バイトに該当文脈及び確率を決定することである。これは次のように実施される。それぞれのクラスで‘標準要素’と呼ばれる一つの要素を固定する。可能な２５６個のノードが属するクラス及びこのような特定ノードをそれのクラスの標準要素として取扱うＧから事前に計算された変換を示すマップテーブル（ＣｌａｓｓＭａｐＴａｂｌｅ：ＣＭＴ）を貯蔵する。従って、現在ノードＮの確率を決定するために次のような段階を実行する。
【０１１６】
●現在ノードの親Ｐを検索する。
●Ｐが属するＣＭＴからクラスを導出し、Ｐを該当クラスの標準ノードとして取扱う変換Ｔを導出する。クラス番号はｃという。
●ＰにＴを適用し、現在ノードＮがマッピングされている標準ノードで子の位置ｐを検索する。
●ＮにＴを適用すれば、新しく得られた積層パターンＴＮはクラスｃの標準ノードで位置ｐに存在する。
●クラス位置組合わせ（ｃ，ｐ）に対応するＰＴのエントリＴＮから必要な確率を導出する。
【０１１７】
１−文脈モデルに対して、前述した段階は明らかな方式で変更される。あらゆる変換は事前に計算されてルックアップテーブルで実施されることはいうまでもない。
ノードＮのデコーディング過程でその親Ｐは既にデコーディングされているので、変換Ｔは公知のものであることに注目せねばならない。デコーディング過程であらゆる段階は対応するエンコーディング段階と完全に類似している。
最後に、確率更新手順を略述する。Ｐを任意の文脈に対する確率テーブルという。このような文脈でノードＮの発生確率に対応するＰのエントリをＰ（Ｎ）と命名する。われらの作業において、Ｐ（Ｎ）は整数であり、それぞれのＮの発生後にＰ（Ｎ）は次のように更新される。
Ｐ（Ｎ）＝Ｐ（Ｎ）Ｐ＋Ａ
【０１１８】
ここで、Ａは相異なる文脈モデルに対して１から４まで典型的に変わる整数増分パラメータである。Ｓ（Ｐ）をＰのあらゆるエントリの和とすれば、計算コーダ（ここでは領域コーダ）に印加されるＮの確率がＰ（Ｎ）／Ｓ（Ｐ）として計算される。Ｓ（Ｐ）が臨界値２１６に到達すれば、まもなくあらゆるエントリが再正規化される。Ｐでゼロ値が発生しないようにするために他のエントリは２で割る一方、１に該当するエントリは変わらずに残っている。
【０１１９】
＜２．２．ポイントテクスチャー圧縮＞
ポイントテクスチャーノードは圧縮される二つのフィールド、すなわち、深さフィールドと色相フィールドとを含む。ポイントテクスチャーデータ圧縮の主な難点は次のような要件に起因する。
【０１２０】
●このような形式の形態表現において歪曲はかなり目立つので、形態は損失なしに圧縮されねばならない。
●色相情報はいかなる自然的な２Ｄ構造を持っていないため、イメージ圧縮技術を即刻適用できない。
【０１２１】
本章でポイントテクスチャーモデル圧縮に対する３つの方法を提案する。
●標準ノード表現に対する無損失圧縮
●低解像度ノード表現に対する無損失圧縮
●低解像度ノード表現に対する無損失形態圧縮及び損失色相圧縮
【０１２２】
このような方法は客体技術の忠実度に対する３つのレベルに対応する。第１の方法は、深さ情報を元来の３２ビット正確度まで貯蔵せねばならないということを想定する。しかし、実質的に深さ情報はたびたび品質の損傷なしにはるかに少ないビット数により量子化できる。
【０１２３】
特に、ポイントテクスチャーモデルが多角形モデルから変換される時、量子化解像度は望ましい出力スクリーンの解像度だけでなく元来モデルが有している視覚的な精密さの実際サイズによって選択される。この場合、８〜１１ビットで要件が満たされ、深さ値は初期にこのような低解像度フォーマットに貯蔵される。
【０１２４】
第２の方法は、このような‘低解像度’表現に対する無損失圧縮を扱う。ここで、核心的なのは、相対的に少ないビット数（標準３２ビットと比較して）でもモデルの中間ボクセル表現ができ、このような中間ボクセル表現は情報に対する実質的な損失なしに深さフィールドを圧縮できるようにするということである。２つの場合において、色相情報は色相データが補助的な２Ｄイメージで配列された後、損失なしに圧縮されてＰＮＧフォーマットに貯蔵される。
【０１２５】
最後に、第３の方法は、形態の無損失圧縮と色相データの損失圧縮とを結合することによってより高い圧縮が可能にする。後者は［６］に開示された特化されたブロック基盤テクスチャー圧縮技術により実施される。このような方法が次の下位３章で詳細に開始される。
【０１２６】
＜２．２．１．標準ノード表現に対する無損失ポイントテクスチャー圧縮＞
これは次のように動作する簡単な無損失コーディング方法である。
●深さフィールドは、オクツリーフィールド圧縮で使われたものと類似した適応領域コーダにより圧縮される。このフォーマットに対して、ＰＴがそれぞれの１−シンボル文脈に対して維持され、文脈は単純に以前バイトであるバージョンを使用する。従って、２５６ＰＴが使われる。深さフィールドはバイトストリームと見なされ、形態構造は明白に使われない。
●色相フィールドは平面実色相イメージに変換された後、圧縮される。ポイントテクスチャーモデルで点の色相は、まず臨時的な１Ｄアレイに深さフィールドでの深さ値のように同じ順序で記録される。モデルで全体点の個数をＬとすれば、ｌ・ｌ≧Ｌが最も小さな整数になるｌを計算し、辺が１である四角形イメージでこのようなｌｏｎｇ‘ストリング’色相値を包む（必要時、検定ピクセルによりさらに包む）。次に、このようなイメージはＭＰＥＧ−４無損失イメージ圧縮道具により圧縮される。本接近でＰｏｒｔａｂｌｅＮｅｔｗｏｒｋＧｒａｐｈｉｃｓ（ＰＮＧ）フォーマットが使われる。‘天使’モデルからこのような方式により得られたイメージが図１０（ａ）に図示されている。
【０１２７】
＜２．２．２．低解像度ノード表現に対する無損失ポイントテクスチャー圧縮＞
多くの場合に深さ情報に対する１６−ビット解像度はかなり良好である。実際に、深さにおいて解像度はモデルが可視化されるスクリーンの解像度に対応されねばならない。相異なる点においてモデル深さの小さな変化がピクセルのサイズよりはるかに小さなスクリーン面での変位を導出する場合に、深さにおいてより低い解像度を使用することが当然であり、モデルはたびたび深さ値が８〜１１ビットのフォーマットで表現される。そのようなモデルは大体適当な空間格子上で深さと色相値とを分離させることによって他のフォーマット、すなわち、多角形モデルから得られる。
【０１２８】
そのような減少された解像度表現はそれ自体が３２ビットの深さを有する標準モデルの圧縮形式と見なされうる。しかし、そのようなモデルに対する中間ボクセル空間を使用するより簡単な表現が存在する。実際に、モデルの点は，区別段階により決定された空間を有する均一な空間格子のノードに属するものと見なされうる。このような観察結果を利用してより低い解像度ポイントテクスチャーの深さと色相フィールドとは次のように圧縮される。
【０１２９】
●以前の方法でのように、色相フィールドは無損失イメージ圧縮技術により圧縮される。
●深さフィールドはまずボクセル表現に変換され、次に以前下位章で記述された多様な領域コーダにより圧縮される。
【０１３０】
中間ボクセルモデルは次のように生成される。モデルの深さ解像度ｓによってｗｉｄｔｈ×ｈｅｉｇｈｔ×２^ｓの大きさを有する分離されたボクセル空間を想定する（幅と高さパラメータはポイントテクスチャー定義に説明されている）。本提案で、全体として可能な巨大なボクセル空間を扱う必要がなく、‘薄い’断面だけ扱えばよい。投影面で行−列は（ｒ、ｃ）と称し、深さ座標はｄという。‘スライス’｛ｃ＝定数｝（すなわち、垂直面によるモデルの断面）をボクセル表現に変換する。スライスを投影面に平行した‘列’に沿ってスキャニングして、（ｒ，ｃ）に投影された深さ値ｄを有するモデルの点が存在すればボクセル（ｒ，ｃ，ｄ）を‘ブラック’と設定する。このような過程が図４に図示されている。
【０１３１】
スライスは生成されてからすぐ１−文脈領域コーダにより圧縮され、次のスライスに対する圧縮が始まる。このような方式で非常に大きいアレイを扱うことを避けうる。ＰＴは、それぞれの新しいスライスに対して初期化されない。広い領域のモデルに対してボクセルの小さな部分だけが黒色であり、これにより多少高い圧縮率が得られる。圧縮の解除は記述された過程を逆にすることにより実施される。
【０１３２】
このような方法及びオクツリー表現による圧縮の比較が３章に示されている。しかし、規則的でないイメージは歪曲なしに大きく圧縮されないため、全体的なモデルの圧縮率は色相フィールドにより決定される。次の下位章で無損失形態圧縮技術と損失色相圧縮技術との結合について考慮する。
【０１３３】
＜２．２．３．低解像度ポイントテクスチャー表現に対する無損失形態圧縮及び損失色相圧縮＞
以前の方法のように、この方法は深さフィールドをボクセル表現に変換した後、適応１−文脈領域コーダにより圧縮する。色相フィールドはまた２Ｄイメージでマッピングされる。しかし、３Ｄ空間にある近い点を２Ｄイメージ平面にある隣接した点にマッピングするためにマッピングを構成しようとする。その後、特化されたテクスチャー圧縮方法（適応ブロックパーティション（ＡｄａｐｔｉｖｅＢｌｏｃｋＰａｒｔｉｔｉｏｎ：ＡＢＰ））が結果イメージに適用される。該当アルゴリズムの主な段階は次の通りである。
【０１３４】
１．ポイントテクスチャーモデルの４個の連続的な‘垂直平面’の‘スライス’をボクセル表現に変換する。
２．得られたｗｉｄｔｈ×４×２^ｓボクセルアレイを次によりスキャンする。
【０１３５】
●投影面に平行した‘列’に沿って４×４×４ボクセル下位キューブの垂直‘平面’を投影面に最も近い列から列順に横断する（すなわち、通常的な２Ｄアレイ横断順序）。
【０１３６】
●オクツリーイメージノード下位キューブ横断で使われたものと類似した順序でそれぞれの４×４×４内部のボクセルを横断する。
３．このような横断順序で互いに出合うモデルの点の色相を補助１Ｄアレイに記録する。
４．得られた色相アレイを２Ｄイメージに再配列する。
５．連関性のある６４個の色相サンプルが８−ｂｙ−８ピクセルブロックに列方向に配列され、次いで次の６４個のサンプルが隣接した８−ｂｙ−８ピクセルアレイに配列される。
６．得られたイメージをＡＢＰ技術により圧縮する。
【０１３７】
このような３Ｄアレイスキャニング及びその結果の２Ｄイメージへのマッピング方法は次を考慮して選択される。４×４×４下位キューブ及び８×８イメージブロックは同数のサンプルを含んでいることに注目せねばならない。
【０１３８】
いくつかの連続的にスキャニングされた下位キューブが８×８ブロックを満たすのに十分な色相サンプルを含めば、このようなブロックがある程度均一化されて圧縮解除後の歪曲は３Ｄモデル上でほとんど認識できないほどである可能性が高い。ＡＢＰアルゴリズムはローカルパレッティング［２９］のアシストで互いに独立的に８×８ブロックを圧縮する。テストで、最終的な３ＤモデルでＡＢＰ圧縮により導入された歪曲はＪＰＥＧより非常に小さい。このようなアルゴリズムを選ぶまた他の理由は、圧縮解除速度が非常に速いということである（元来計画されたことに比べて）。圧縮率は８と１２の二つの値を有することができる。ポイントテクスチャー圧縮アルゴリズムで圧縮率は８に固定される。
【０１３９】
しかし、このアルゴリズムはあらゆる場合に適用できるのではない。たとえ色相フィールド（図１０（ｂ））からこの方式により得られたイメージは‘自然的な’スキャニング順序に対するものよりもっと均一であっても、時に２Ｄ８×８ブロックは３Ｄ空間で距離に対応する色相サンプルを含む。この場合、損失ＡＢＰ方法はモデルの距離部分を形成する色相を混合でき、これは圧縮解除後に地域的な、しかし認識可能な歪曲を招来する。
【０１４０】
しかし、多くのモデルに対してこのアルゴリズムは良好に機能する。図１１に良好でない場合（‘天使’モデル）と良好な場合（‘モルトン２５６’モデル）とを図示した。二つの場合においてモデル体積の減少は約７倍である。
【０１４１】
＜３．テスト結果＞
この章では、２つの相異なるフォーマット−オクツリーイメージ及びポイントテクスチャー−を有する‘天使’と‘モルトン２５６’の２つのモデルを比較した結果を示す。それぞれのモデルに対する参照イメージの寸法は２５６×２５６ピクセルである。
＜３．１．ポイントテクスチャー圧縮＞
テーブル３ないしテーブル５に相異な圧縮方法の結果が与えられている。この実験に対するモデルは８ビットの深さフィールドを有するモデルから得られた。深さ値は３２ビットの深さ値でのビット分布をより均一化して‘真の’３２ビット値にある程度近づくように２^２１＋１の量子化段階を使用して（１，２^３０）領域にかけて拡張された。
【０１４２】
この方法から高い圧縮率が期待されない。体積減少は典型的な実色相イメージの無損失圧縮については同じ順序である。データの形態特性はこの方法により捉えられないので、圧縮された深さ及び色相フィールドは比較する程の大きさである。
【０１４３】
なお、‘真の’深さ解像度をとる時にいかほど多くの同じモデルが損失なしに圧縮されうるかを説明する。以前の場合とは異なり、深さフィールドは約５〜６倍損失なしに圧縮される。これは形態データ冗長をはるかに多く言及させる中間ボクセル表現に起因する。実際に、ボクセルの小さな部分だけ黒色である。しかし、圧縮されていないモデルのサイズは３２ビットの場合より小さいため、色相フィールド圧縮率は全体圧縮率を決定するが、これは３２ビットの場合よりはるかに小さい（出力ファイルも同じく小さいが）。従って、少なくとも深さフィールドだけ良好に圧縮できるものが望ましい。
【０１４４】
第３のモデルはこのためにＡＢＰと呼ばれる損失圧縮技術を使用する。この方法はもっと高い圧縮を与える。しかし、あらゆる損失圧縮技術のように、このモデルは一定の場合に望ましくないアーチファクトを招来する。このような場合が発生する客体の例は‘天使’モデルである。
モデルの点をスキャニングする過程で空間的に距離がある点は同じ２Ｄイメージブロックに引き込まれる。このようなモデルの離れている点で色相は大きい差がありうる。
【０１４５】
一方、再構成された色相が自体の３Ｄ位置に再入力された後、標準ＪＰＥＧにより発生した歪曲は絶対的に受容されないために、地域的なパレタイジングによりぼう大なほとんどのブロックを正確に圧縮できる。しかし、同じ方法により圧縮された‘モルトン２５６’モデルの可視品質はかなり良好であり、これは実験での大部分のモデルに該当する。
【０１４６】
テーブル３．３２ビット深さフィールドに対する無損失ポイントテクスチャー圧縮（バイト）。
【０１４７】
【表７】

【０１４８】
テーブル４．低解像度ノード表現に対する無損失ポイントテクスチャー圧縮（バイト）
【０１４９】
【表８】

【０１５０】
テーブル５．低解像度ポイントテクスチャーに対する無損失形態及び損失色相圧縮（バイト）
【０１５１】
【表９】

【０１５２】
＜３．２．オクツリーイメージ圧縮＞
テーブル６は、２つのテストモデルに対する圧縮及び圧縮されていないオクツリー成分の大きさを示す。このようなフィールドの減少は約１．６〜１．９倍であることが分かる。
しかし、はなはだしくは８ビットの深さフィールドを有している圧縮されていないポイントテクスチャーモデルと比較してもオクツリーイメージははるかに簡単である。
【０１５３】
テーブル７には圧縮率が７．２と１１．２と示されている。これは、オクツリーイメージへの変換なしに圧縮されうるポイントテクスチャー（各々６．７と６．８倍）より高い。しかし、既述したようにオクツリーイメージは不完全な色相情報を含むことができ、’天使’モデルの場合がこれに該当する。このような場合に、３Ｄ色相補間が使われる。
【０１５４】
整理すれば、上に提示された実験は改善された圧縮道具の効率を立証すると結論づけられる。与えられたモデルに対する最適の道具選択は、モデルの形態的複雑性、色相分布特性、要求されるレンダリング速度及び他の要因に依存する。
【０１５５】
テーブル６．オクツリーイメージモデルとこれらの成分に対する４．１．２．節に開示された方法によって与えられた圧縮率（Ｋｂｙｔｅｓで四捨五入したファイルサイズ）
【０１５６】
【表１０】

【０１５７】
テーブル７．同じモデルに対する圧縮されていないポイントテクスチャー（８ビットの深さフィールド）と圧縮されたオクツリーイメージ表現（Ｋｂｙｔｅｓで四捨五入したファイルサイズ）
【０１５８】
【表１１】

【０１５９】
５．ＩＳＯ／ＩＥＣ１４４９６−１／ＰＤＡＭ４の研究に対する意見
次の改正案をＩＳＯ／ＩＥＣ１４４９６−１／ＰＤＡＭ４（Ｎ４６２７）の研究に提出した後、改正されたＩＳＯ／ＩＥＣ１４４９６−１／ＰＤＡＭ４の研究がＩＳＯ／ＩＥＣ１４４９６−１／ＰＤＡＭ４に結合されねばならない。
【０１６０】
＜６．５．３．１．１節　技術＞
問題：直交の基本値は最も一般的に使われる値でなければならない。
解決：直交フィールドの基本値を次のように“ＦＡＬＳＥ”から“ＴＲＵＥ”に取り替える。
提案された改正案：

【０１６１】
＜６．５．３．１．１節　技術＞
問題：ＤＩＢＲストリーミングはＡＦＸに対して均一なストリーミング方法で実施されねばならない。
解決：ＤｅｐｔｈＩｍａｇｅＵｒｌフィールドを深さイメージノードから除去する。
提案された改正案：

【０１６２】
＜６．５．３．１．２節　社説＞
問題：‘正規化された（ｎｏｒｍａｌｉｚｅｄ）’という用語は現在文脈で深さフィールドに適用されるものとして、誤りである。
解決：第５段落で、‘正規化された’を‘スケールされた’に変更する。
提案された改正案：
ｎｅａｒＰｌａｎｅとｆａｒＰｌａｎｅフィールドは視点から可視領域の隣接平面及び遠接平明までの距離を特定する。テクスチャー及び深さデータは隣接平面、遠接平面そしてｆｉｅｌｄＯｆＶｉｅｗにより囲まれた領域を示す。深さデータは隣接平面から遠接平面までの距離にスケールされる。
【０１６３】
＜６．５．３．１．２節　技術＞
問題：ＤＩＢＲストリーミングはＡＦＸに対して均一なストリーミング方法で実施される。
解決：ｄｅｐｔｈＩｍａｇｅＵｒｌフィールドに対する説明を削除する（第７段落及びそれ以下）
【０１６４】
＜６．５．３．２．２節　社説＞
問題：深さフィールドの意味が不完全に特定された。
解決：３番目段落の長さフィールド定義を次のように変更する。
提案された改正案：
深さフィールドはテクスチャーフィールドにあるそれぞれのピクセルに対する深さを特定する。深さマップのサイズはイメージまたはテクスチャーフィールドの動映像と同じサイズでなければならない。
【０１６５】
深さフィールドは多様な形態のテクスチャーノード（イメージテクスチャー、動映像テクスチャーまたはピクセルテクスチャー）のうち一つであり、ここで、グレースケールイメージを表現するノードだけ許容される。深さフィールドが特定されていなければ、テクスチャーフィールドにあるアルファチャンネルが深さマップとして使われる。深さマップが深さフィールドまたはアルファチャンネルを通じて特定されていなければ、結果は規定されない。
【０１６６】
深さフィールドによりモデルの３Ｄ点で視点を通過して隣接平面及び遠接平面に平行した平面までの実際的な距離を計算できる。
【０１６７】
【数４】

【０１６８】
ここで、ｄは深さ値であり、ｄ_ｍａｘは許容可能な深さ値の最大値である。モデルの点に対してｄ＞０であると仮定する。ここで、遠接平面に対応するｄは１であり、隣接平面に対応するｄはｄ_ｍａｘである。
【０１６９】
ｄが点と平面との距離であるため、この公式は遠近及び直交ケース両方に対して有効である。ｄ_ｍａｘはそれぞれのピクセルに対して使われるビットにより表現されうる最も大きいｄ値である。
（１）深さは深さフィールドを通じて特定され、深さ値ｄはグレースケールと同一である。
（２）深さがテクスチャーフィールドを通じて定義されたイメージでのアルファチャンネルを通じて特定されれば、深さ値ｄはアルファチャンネル値と同一である。
【０１７０】
深さ値はまたモデルに属する点を表すために使われる。ｄが０でない点だけがモデルに属する。
動的深さイメージに基づくモデルに対して、ｄｉＴｅｘｔｕｒｅとしてシンプルテクスチャーを有する深さイメージだけ使われる。
【０１７１】
シンプルテクスチャーの各々は次の方法のうち一つでアニメ化されうる。
（１）深さフィールドは上の条件を満足する静止イメージであり、テクスチャーフィールドは任意の動映像テクスチャーである。
（２）深さフィールドは深さフィールドで上の条件を満足する任意の動映像テクスチャーであり、テクスチャーフィールドは静止イメージである。
（３）深さ及びテクスチャーは動映像テクスチャーであり、深さフィールドは上の条件を満足する。
（４）深さフィールドは使われず、深さ情報はテクスチャーフィールドをアニメ化する動映像テクスチャーのアルファチャンネルから導出される。
【０１７２】
＜６．５．３．３．２節　社説＞
問題：深さフィールドの意味が不完全に特定された。
解決：深さフィールド定義（第３段落）を提案された改正案に取り替える。
提案された改正案：
深さ値の形態的意味及びシンプルテクスチャーに対して採択されたそれらの解釈におけるあらゆる約束はここに同じく適用する。
深さフィールドは投影面に存在するそれぞれの点に対する複数の深さを特定し、横断順序において遠接平面（上を参照）と見なされ、左側下段コーナーにある点から出発して右側に横断しながら上側にある線に移動する前に水平線で終了する。それぞれの点に対して、深さ（ピクセル）番号が先に貯蔵され、深さ番号値は次に貯蔵される。
【０１７３】
＜６．５．３．４．１節Ｈ．１　技術＞
問題：オクツリーフィールドに対して使われたフィールドタイプであるＳＦストリングは矛盾する値を導出することがある。
解決：オクツリーフィールドに対するフィールドタイプをＮＦＩｎｔ３２に変更する。
提案された改正案：
６．５．３．４．１節で、

Ｈ．１節で、オクツリーに対するテーブルのオクツリー列を次のように変更する。
【０１７４】
【表１２】

【０１７５】
＜６．５．３．４．１節　技術＞
問題：ＤＩＢＲストリーミングはＡＦＸに対する均一なストリーミング方法により実施されねばならない。
解決：オクツリーイメージノードからｏｃｔｒｅｅＵｒｌフィールドを削除する。
提案された改正案：

【０１７６】
＜６．５．３．４．２節　社説＞
問題：オクツリー解像度（ｏｃｔｒｅｅｒｅｓｏｌｕｔｉｏｎ）フィールド定義（第２段落）は誤解を招く。
解決：‘許容される（ａｌｌｏｗｅｄ）’という単語を追加して説明を改正する。
提案された改正案：
オクツリー解像度フィールドは閉じられたキューブの側面に沿う最大に許容されるオクツリーリーフの数を特定する。オクツリーレベルは次の式を使用してオクツリー解像度から決定できる。
【０１７７】
【数５】

【０１７８】
＜６．５．３．４．２節　技術＞
問題：ＤＩＢＲストリーミングはＡＦＸに対して均一なストリーミング方法により実施されねばならない。
解決：ｏｃｔｒｅｅＵｒｌフィールドの説明（第５段落とそれ以下）を削除する。
提案された改正案：
【０１７９】
＜６．５．３．４．２節　社説＞
問題：オクツリーイメージの動映像化が不完全に記述された。
解決：６．５．３．４．２節の末尾にオクツリーイメージ動映像化を記述する段落を追加する。
提案された修正案：
オクツリーイメージの動映像化は、単に深さフィールドの代わりにオクツリーフィールドを使用することにのみ差があるだけで、上に記述された深さイメージに基づく動映像に対する最初の３つの方法と同じ接近法により実施さうる。
＜　　　Ｈ．１節　技術　＞
問題：ポイントテクスチャーノードにおいて深さデータの領域が将来の応用に対しては小さすぎる。多くのグラフィック道具は自体のｚ−バッファに対して２４ビットまたは３６ビットの深さを許容する。しかし、ポイントテクスチャーにおいて深さフィールドは１６ビットである［０，６５５３５］の領域を有する。
解決：Ｈ．１節で、ポイントテクスチャーに対するテーブルの深さ列の領域を次のように変更する。
【０１８０】
【表１３】

【０１８１】
ＩＶ．ＩＳＯ／ＩＥＣＪＴＣ１／ＳＣ２９／ＷＧ１１　動映像及び音響のコーディング
【０１８２】
［１．序論］
本文書で深さ映像基盤表現（ＤｅｐｔｈＩｍａｇｅ−ＢａｓｅｄＲｅｐｒｅｓｅｎｔａｔｉｏｎ：ＤＩＢＲ）（ＡＦＸＡ８．３）においてオクツリーイメージ（ＯｃｔｒｅｅＩｍａｇｅ）の改善が記述される。オクツリーイメージノードはＰａｔｔａｙａで開催された会議で受容され、委員会草案に対する提案に含まれている。しかし、客体形状の閉鎖によっていくつかの特別な場合にはレンダリング品質が満足するほどではないと観察された。本文書には、ストリーミングのためのオクツリーイメージノードの圧縮方法だけでなく、オクツリーイメージノードの改善されたバージョン−構造化された２進体積オクツリー（ＴｅｘｔｕｒｅｄＢｉｎａｒｙＶｏｌｕｍｅｔｒｉｃＯｃｔｒｅｅ：ＴＢＶＯ）−が開示される。
【０１８３】
［２．構造化された２進体積オクツリー（ＴＢＶＯ）］
＜２．１．ＴＢＶＯ概観＞
ＴＢＶＯの目標は、２進体積オクツリー（ＢｉｎａｒｙＶｏｌｕｍｅｔｉｃＯｃｔｒｅｅ：ＢＶＯ）の改善として速い視覚化が可能なより柔軟な表現／圧縮フォーマットを考案することである。これは、ＢＶＯに基づいていくつかの付加的な情報を貯蔵することによって達成される。ＢＶＯに基づいた表現はオクツリー構造及び参照イメージ集合で構成される。一方、ＴＢＶＯに基づいた表現はＢＶＯオクツリー構造及び参照イメージ集合、そしてカメラインデックスで構成される。
【０１８４】
ＢＶＯ視覚化の主な問題はレンダリング時にそれぞれのボクセルに対応するカメラインデックスを決定せねばならないということである。このために、カメラへの投影を考慮する必要があるだけでなく、逆光を採択する過程を考慮する必要がある。最小限ボクセルが見られる所からカメラの存在を決定せねばならない。
結果的に、特定のカメラに投影されるあらゆるボクセルを探さねばならない。しかし、ブルートフォース接近法を使用するならばこのような過程は非常に遅い。われらは客体形状の大部分に対して速くて正確にこれを実行するアルゴリズムを開発した。しかし、いかなるカメラによっても見られないボクセルについては依然としていくつかの問題点が存在する。
【０１８５】
それぞれのボクセルに系統的な色相を貯蔵することが可能な解決法になりうる。しかし、この場合、圧縮する色相情報においていくつかの問題点がある。すなわち、ボクセル色相をイメージフォーマットとして分類してそれを圧縮すれば、隣接するボクセルの色相相関関係が破壊されて圧縮率が満足するほどではない。
【０１８６】
ＴＢＶＯで、このような問題はあらゆるボクセルに対してカメラ（イメージ）インデックスを貯蔵することによって解決される。カメラインデックスは一般的に大きいボクセルグループに対して同一であり、これにより付加的な情報の経済的な貯蔵のためのオクツリー構造の使用が可能である。このようなモデルに対する実験で平均的に単に１５％の体積増加が観察されたことに注目する必要がある。モデリングは多少複雑であるが、より柔軟な方式の任意の形状を有する客体を表現できる。
【０１８７】
ＢＶＯに比べてＴＢＶＯの長所はレンダリングがより単純でもっと速いということであり、実質的に客体形状に加わる制限がないということである。
【０１８８】
＜２．２．ＴＢＶＯの例＞
本節で、ＴＢＶＯ表現の有効性及び核心的な要素を示す典型的な例を示す。図１２（ａ）に“天使”に対するＢＶＯモデルが図示されている。
【０１８９】
通常的な６要素構造のＢＶＯを利用すれば、胴体と翼の一部がいかなるカメラによっても観察されず、これにより描写されたイメージは多くの可視的な‘クラック’を有する。同じモデルのＴＢＶＯ表現で全部８個のカメラが使われる（箱の６面に各々にあるカメラと２個の付加的なカメラ）。
【０１９０】
図１３（ａ）にはカメラインデックスのイメージが図示されている。他の色相は他のカメラインデックスを意味する。付加的なカメラはキューブの内部に位置し、前面と背面を垂直に注視する。付加的なカメラのイメージ面が図１３（ｂ）及び図１３（ｃ）に図示されている。結果的に、図１２（ｂ）に示すように、モデルに対する連続的できれいなレンダリング結果を得るようになる。
【０１９１】
＜２．３．圧縮されていないＴＢＶＯストリーム描写＞
２５５個のカメラで十分であり、インデックスのために１バイトまで割り当てることを提案する。ＴＢＶＯストリームはシンボルストリームである。あらゆるＴＢＶＯシンボルはＢＶＯシンボルまたは構造化されたシンボルである。構造化されたシンボルはカメラインデックスを意味し、カメラインデックスは特定の番号または“未定の”コードになりうる。以下、“未定の”コードは“？”と表示する。
【０１９２】
ＴＢＶＯストリームは幅優先順序で横断する。われらがＢＶＯを有していてあらゆるリーフボクセルがカメラ番号を有している場合にＴＢＶＯストリームの記述方法について説明する。これはモデリング段階で実施されねばならない。ＴＢＶＯストリームはリーフノードを含んでいるあらゆるＢＶＯノード（ＢＶＯシンボルを有していない）を幅優先順序で横断する。次の擬似コードはストリームを完壁に記述する。

【０１９３】
以上の過程によれば、図１４（ａ）に示されたＴＢＶＯツリーに対するシンボルストリームが図１４（ｂ）に示されたように得られる。しかし、実質的なストリームにおいて３つの値（２個のカメラと定義されていないコード）だけ表現する必要があるので、それぞれの構造化されたシンボルはただ２ビットだけ必要である。
【０１９４】
＜２．４．ＴＢＶＯ圧縮＞
オクツリーイメージノードでオクツリーイメージとオクツリーフィールドとは個別的に圧縮される。開示された方法は、オクツリーイメージに対しては一定程度の可視的に受け入れられる歪曲が許容されるのに対し、オクツリーフィールドは損失なしに圧縮されねばならないという概念に基づいて開発された。
【０１９５】
＜２．４．１．オクツリーイメージフィールド圧縮＞
オクツリーイメージフィールドはＭＰＥＧ−４で許容されるＭＰＥＧ−４イメージ圧縮（静的モデルに対する）手段または映像圧縮道具（動的モデルに対する）により圧縮される。われらの接近で、われらはオクツリーイメージに対してＪＰＥＧフォーマットを使用した（それぞれの構造を維持させながら３Ｄ視覚化に必要な点だけＪＰＥＧイメージの’少量化’と命名した一定の前処理を実行した後；すなわち、３Ｄレンダリング段階で使われない与えられた構造の一部は所望する分だけ概略的に圧縮されうる）。
【０１９６】
＜２．４．２．オクツリーフィールド圧縮＞
オクツリー圧縮は、既に非常に簡略でリンクのない２進ツリー表現の圧縮を取扱っているゆえに、オクツリーイメージ圧縮の最も重要な部分である。しかし、実験で後述される方法はこのような構造の体積を元の約半分に減少させた。動的のオクツリーイメージバージョンで、オクツリーフィールドはそれぞれの３Ｄフレームに対して個別的に圧縮される。
【０１９７】
＜２．４．２．１．文脈モデル＞
圧縮はデータの形態的特性を明確に使用する多様な適応算術コーディング（‘領域エンコーダ’で実行される）により実施される。オクツリーはバイトストリームである。それぞれのバイトはツリーのノード（すなわち、下位キューブ）を示し、バイトのビットは内部的な分割後の下位キューブの占有を示す。ビットパターンはノードの積層パターンと呼ばれる。開示された圧縮アルゴリズムは次のような方式でバイトを一つずつ処理する。
【０１９８】
●現在バイトに対する文脈決定
●このような文脈で現在バイトの発生‘確率’（正規化された頻度）を文脈に対応する‘確率テーブル’（ＰＴ）から検索
●領域エンコーダで確率値提供
●現在文脈で現在バイト発生の頻度に１を足して現在ＰＴ更新（必要時、作業隨行後に再正規化、下の詳細な説明を参照）
【０１９９】
従って、コーディングは文脈モデルによるＰＴの生成及び更新過程である。文脈に基づく適応算術コーディング技術で（‘部分マッチングによる予測’のように）、シンボル文脈は一般的にいくつかの前置シンボル列である。しかし、私たちの場合、オクツリー構造及びデータの形態的特性を活用することによって圧縮効率を高める。開示された接近法はオクツリー圧縮の問題において明確に新しい２つのアイディアに基づく。
【０２００】
Ａ．現在ノードに対し、文脈はそれの親ノードまたは｛親ノード、親ノードに位置した現在ノード｝で構成された対のうち一つであり、
Ｂ．特定の親ノードにおいて特定の形態的位置で与えられたノード発生‘確率’は任意の直交（回転または対称のような）変換集合に対して不変であると仮定する。
【０２０１】
ｘ−ｚ平面上で−９０゜回転する変換Ｒに対する仮定‘Ｂ’は図５に示されている。‘Ｂ’の裏面に存在する基本的な概念は、特定な形態の親ノードにおいて特定な形態の子ノードの発生確率は単にこれらの相対的な位置に依存するということである。このような仮定はＰＴの分析による実験で立証された。
【０２０２】
これにより、過度に多くのＰＴを保有せずに複雑な文脈を使用できる。順に、これによりデータサイズ及び速度面でかなり良好な結果を得られる。複雑な文脈を使用するほど推定された確率がより明確になり、従ってコードがより簡潔になることに注目せねばならない。
【０２０３】
さて、変換集合を紹介する。確率分布は不変であると仮定する。われらの状況に適用するために、このような変換は閉じられたキューブを維持しなければならない。ユークリッド空間での直交変換の集合Ｇを考慮する。直交変換は、３個の基本変換（生成子）ｍ_１、ｍ_２、及びｍ_３の任意の番号及び順序上のあらゆる成分により得られる。
【０２０４】
【数６】

【０２０５】
ここで、ｍ_１及びｍ_２は各々ｘ＝ｙ及びｙ＝ｚ平面への投影であり、ｍ_３はｘ＝０平面への投影である。投影により生成されたグループ理論の典型的な結果のうち一つはＧが４８個の個別的な直交変換を含み、ある意味ではキューブを自体的に取る直交変換の最大グループである（いわゆる、ｃｏｘｅｔｅｒｇｒｏｕｐ［２７］）。例えば、図６に示された回転子Ｒは生成子を通じて次のように表現される。
【０２０６】
【数７】

【０２０７】
ここで、‘・’との行列乗算である。
オクツリーノードに適用されたＧからの変換は、相異なる下位キューブの積層パターンを有するノードを算出する。これによりノードの下位キューブの積層パターンによってノードを分類できる。グループ理論言語を使用する時［５］、Ｇはオクツリーノードのあらゆる積層パターンに対する集合として作用すると言及する。計算によれば、２２個の個別的なクラス（また、グループ理論でオービットと称される）が存在する。
【０２０８】
そして、定義によりＧからの変換により連結されるならば、二つのノードが同じクラスに属する。一つのクラスで要素番号は１から２４まで多様であり、常に４８の除数である。
仮定‘Ｂ’の実質的な重要性は、ＰＴが親ノードそれ自体に従属的でなく、単に親ノードが属するクラスに従属的であるということである。親基盤文脈に対して２５６個のテーブルがありえるが、前者の場合に親−子位置基盤文脈に対して付加的な２５６×８＝２０４８個のテーブルが必要である一方、後者の場合に親−クラス基盤文脈に対して２２個のテーブルと２２×８１７６個のテーブルとが必要であるということに注目せねばならない。従って、相対的に少数のＰＴを有して同等に複雑な文脈を使用することが可能である。作成されたＰＴはテーブルＩに記載された形態をとることができる。
【０２０９】
【表１４】

【０２１０】
＜２．４．２．２．エンコーディング手順＞
ＰＴに対する統計をより正確にするために、エンコーディング手順の３つの過程で相異なる方式が収集される。
●‘０−文脈モデル’とされる最初の段階で文脈を全く使用せず、均一な分布から出発して２５６個のエントリを保有した一つのＰＴを維持する。
●最初の５１２個のノード（実験的に発見された番号）がエンコーディングされてすぐ、親ノードを文脈として使用する‘１−文脈モデル’に転換する。転換時、０−文脈ＰＴはあらゆる２２個の文脈に対するＰＴに複写される。
●次の２０４８個のノード（他の発見値）がエンコーディングされた後、‘２−文脈モデル’に転換する。この瞬間に親パターンの１−文脈ＰＴは同じ親パターンでそれぞれの位置に対するＰＴに複写される。
【０２１１】
このようなアルゴリズムの核心は、現在バイトに該当文脈及び確率を決定することである。これは次のように実施される。それぞれのクラスで‘標準要素’と呼ばれる一つの要素を固定する。可能な２５６個のノードが属するクラス及びこのような特定ノードをそれのクラスの標準要素として取扱うＧから事前に計算された変換を示すマップテーブル（ＣｌａｓｓＭａｐＴａｂｌｅ：ＣＭＴ）を貯蔵する。従って、現在ノードＮの確率を決定するために次のような段階を実行する。
【０２１２】
●現在ノードの親Ｐを検索する。
●Ｐが属するＣＭＴからクラスを導出し、Ｐを該当クラスの標準ノードとして取扱う変換Ｔを導出する。クラス番号はｃという。
●ＰにＴを適用し、現在ノードＮがマッピングされている標準ノードで子の位置ｐを検索する。
●ＮにＴを適用すれば、新しく得られた積層パターンＴＮはクラスｃの標準ノードで位置ｐに存在する。
●クラス位置組合わせ（ｃ，ｐ）に対応するＰＴのエントリＴＮから必要な確率を導出する。
【０２１３】
１−文脈モデルに対して、前述した段階は明らかな方式で変更される。あらゆる変換は事前に計算されてルックアップテーブルで実施されることはいうまでもない。
ノードＮのデコーディング過程でその親Ｐは既にデコーディングされているので、変換Ｔは公知のものであることに注目せねばならない。デコーディング過程であらゆる段階は対応するエンコーディング段階と完全に類似している。
最後に、確率更新手順を略述する。Ｐを任意の文脈に対する確率テーブルという。このような文脈でノードＮの発生確率に対応するＰのエントリをＰ（Ｎ）と命名する。われらの作業において、Ｐ（Ｎ）は整数であり、それぞれのＮの発生後にＰ（Ｎ）は次のように更新される。
【０２１４】
【数８】

【０２１５】
ここで、Ａは相異なる文脈モデルに対して１から４まで典型的に変わる整数増分パラメータである。Ｓ（Ｐ）をＰのあらゆるエントリの和とすれば、計算コーダ（ここでは領域コーダ）に印加されるＮの確率がＰ（Ｎ）／Ｓ（Ｐ）として計算される。Ｓ（Ｐ）が臨界値２１６に到達すれば、まもなくあらゆるエントリが再正規化される。Ｐでゼロ値が発生しないようにするために他のエントリは２で割る一方、１に該当するエントリは変わらずに残っている。
【０２１６】
＜２．４．２．３．‘カメラノード’のエンコーディング＞
それぞれのボクセルに対する構造（カメラ）番号を決定するシンボルストリームは自体に固有なＰＴを使用して圧縮される。先に使用した用語上ではそれは単一文脈を保有する。ＰＴエントリはオクツリーノードに対するエントリより大きい増加分を有して更新される。残りはノードシンボルコーディングと差がない。
【０２１７】
＜２．５．ＴＢＶＯ圧縮及びレンダリングの結果＞
ＴＢＶＯ圧縮の結果が図１５、１７ないし１９に示されている。圧縮されたサイズは圧縮されたＢＶＯと比較される。３番目の列で括弧内の数字は圧縮された形態的な体積である。一方、最初の数字はＴＢＶＯ基盤の圧縮モデル（すなわち、構造が考慮された）の総体積である。可視的な歪曲の大きさ面で、ＬＤＩ→（Ｔ）ＢＶＯ→ＬＤＩ変換後に色相差を測定するためにＰＳＮＲが計算された。圧縮されたモデルのサイズは、あらゆる構造（最小化されたＪＰＥＧで貯蔵された、２．４．１．参照）のサイズさと圧縮された形態サイズとの和である。ＴＢＶＯの場合に圧縮された形態はカメラ情報も含む。ＴＢＶＯのＰＳＮＲはＢＶＯと比較する時にかなり改善される。
【０２１８】
ＴＢＶＯはＢＶＯより速いレンダリングを得る。“天使”モデルにおいて、ＢＶＯのフレームレートは７．５ｆｐｓである一方、ＴＢＶＯ−１２のフレームレートは１０．８ｆｐｓである。“モルトン”モデルにおいて、ＢＶＯのフレームレートは２．１ｆｐｓ（セレロン（登録商標）８５０ＭＨｚ）である一方、ＴＢＶＯ−１２のフレームレートは３．０ｆｐｓである。他の一方、レンダリングは動的なＴＢＶＯでもっと速く実施されることが観察された。“ドラゴン”モデルにおいて、ＢＶＯのフレームレートは２９ｆｐｓ（ペンティアムＩＶ（登録商標）で１．８ＧＨｚ）である一方、ＴＢＶＯ−１２のフレームレートは７３ｆｐｓである。
【０２１９】
ＴＢＶＯフォーマットは相当な柔軟性を提供する。例えば、図１５には１２個のカメラを使用する２つの方式（ＴＢＶＯ−１２及びＴＢＶＯ−（６＋６））が図示されている。ＴＢＶＯ−１２は６個のＢＶＯカメラ（キューブ面）とキューブの中心で面と平行するように撮影した６個のイメージを使用する。（６＋６）テクスチャーは６個のＢＶＯカメラを使用し、それから、これらカメラにより眺望可能なすべてのボクセルと、同じ６個のカメラにより眺望可能な“写真”部分を除去する（‘ｐｅｅｌ’）。このようなイメージの例が図１６に図示されている。
【０２２０】
ＢＶＯとＴＢＶＯ−６天使モデル間の質（本質的及びＰＳＮＲ値）において大きな差を注目せねばならない。たとえ同じカメラ位置が使われたとしても、ＴＢＶＯはいなかるカメラからも観察されないボクセルを含むあらゆるボクセルにカメラ番号を割り当てることができる。
これら番号は元の色相と最も一致するように選択される（すなわち、直接的な可視性とは関係なくそれぞれの地点に対してあらゆる‘カメラ’イメージで最上の色相一致が選択される。天使の場合、これは優れた結果を与える）。
【０２２１】
また、６個と１２個のカメラを使用した場合間の非常に適切な‘形態’（すなわちＢＶＯ＋カメラ）体積差に注目せねばならない。実際に、付加的なカメラは通常的に少ない領域を担当するので、これらの識別はまれであり、これらの構造は貧弱である（そしてよく圧縮される）。これら全ては‘天使’だけでなく下のあらゆるモデルにも適用される。
【０２２２】
＜２．６．ノード定義＞

【０２２３】
オクツリーイメージ（ＯｃｔｒｅｅＩｍａｇｅ）ノードは対応するカメラインデックスアレイ及びオクツリーイメージ集合が存在するオクツリー構造のＴＢＶＯ構造を定義する。
オクツリーイメージ（Ｏｃｔｒｅｅｉｍａｇｅｓ）フィールドはｄｉＴｅｘｔｕｒｅフィールドに対してシンプルテクスチャー（ＳｉｍｐｌｅＴｅｘｔｕｒｅ）を有する深さイメージ（ＤｅｐｔｈＩｍａｇｅ）ノード集合を特定する。これらシンプルテクスチャー（ＳｉｍｐｌｅＴｅｘｔｕｒｅ）ノードで深さフィールドは使われない。
【０２２４】
直交（ｏｒｔｈｏｇｒａｐｈｉｃ）フィールドは深さイメージ（ＤｅｐｔｈＩｍａｇｅ）ノードに対して真（ＴＲＵＥ）でなければならない。シンプルテクスチャー（ＳｉｍｐｌｅＴｅｘｔｕｒｅ）各々に対してテクスチャーフィールドは客体または位置及び方向に対応する深さイメージ（ＤｅｐｔｈＩｍａｇｅ）フィールドで特定の直交カメラにより得られるような客体視点（例えば、カメラ面による客体の断面）の部分の色相情報を貯蔵する。
【０２２５】
それぞれのカメラに対応する客体の部分はモデル生成段階で割当てられる。位置（ｐｏｓｉｔｉｏｎ）、方向（ｏｒｉｅｎｔａｔｉｏｎ）、及びテクスチャー（ｔｅｘｔｕｒｅ）値を利用した客体分割は、カメラの数（または、同一に含まれるオクツリーイメージの数字）を減らすと同時に、任意の選択された位置で暫定的に捕捉可能なあらゆる客体部分を含むために実施される。方向（ｏｒｉｅｎｔａｔｉｏｎ）フィールドは、カメラの視覚ベクターは単に一つの０でない成分（すなわち、閉じられたキューブ面のうち一つに垂直の成分）を有し、シンプルテクスチャー（ＳｉｍｐｌｅＴｅｘｔｕｒｅ）イメージの側面は閉じられたキューブの対応する面と平行するという条件を満足せねばならない。
【０２２６】
オクツリー（ｏｃｔｒｅｅ）フィールドは客体形態を完全に記述する。形態は与えられた客体を構成するボクセル集合で表現される。オクツリーはツリー型のデータ構造であり、該当データ構造でそれぞれのノードはバイトにより表現される。このようなバイトのｉ番目ビットの１は内部ノードのｉ番目の子に対して子ノードが存在するということを意味する。一方、０は子ノードが存在しないことを意味する。オクツリー内部ノードの順序はオクツリーの幅優先横断順序でなければならない。内部ノードの８個の子順序が図４（ｂ）に図示されている。全体オクツリーの閉じられたキューブのサイズは１×１×１であり、オクツリーキューブの中心は特定の座標系の原点（０，０，０）である。
【０２２７】
カメラＩＤ（ｃａｍｅｒａＩＤ）フィールドはボクセルに割当てられたカメラインデックスのアレイを含む。レンダリング段階でオクツリーリーフに起因した色相は、特定のインデックスを有するオクツリーイメージの一つにリーフを垂直に投影することによって決定される。インデックスはオクツリー方式で貯蔵される。
【０２２８】
もし、特定のカメラが特定のノードに含まれたあらゆるリーフに対して使われるならば、カメラインデックスを含むノードはストリームに入力される。そうでない場合、固定された’追加的な下位分割’コードを含むノードが入力されるが、これはカメラインデックスが現在ノード（同じ反復的な形態で）の子下位ノードに対して個別的に特定されることを意味する。もし、カメラＩＤ（ｃａｍｅｒａＩＤ）が空いているならばＢＶＯの場合と同じくカメラインデックスはレンダリング段階が進む間に決定される。
【０２２９】
オクツリー解像度（ｏｃｔｒｅｅｒｅｓｏｌｕｔｉｏｎ）フィールドは、閉じられたキューブの側面に沿う最大の許容可能なオクツリーリーフの数を特定する。オクツリーのレベルは次の式を利用してオクツリー解像度から決定される。
【０２３０】
＜２．７．ビットストリーム定義＞
＜２．７．１．オクツリー圧縮＞
＜２．７．１．１．概観＞
【０２３１】
深さ基盤イメージ表現においてオクツリーイメージノードはオクツリー構造及びそれの投影されたテクスチャーを定義する。オクツリーイメージアレイに貯蔵されているそれぞれのテクスチャーはシンプルテクスチャーを有する深さイメージノードを通じて定義される。オクツリーイメージノードの他のフィールドはオクツリー圧縮により圧縮されることができる。
【０２３２】
＜２．７．１．２．オクツリー＞
＜２．７．１．２．１．文法＞

【０２３３】
＜２．７．１．２．２．意味＞
オクツリーの圧縮されたストリームはｏｃｔｒｅｅ＿ｆｒａｍｅ＿ｓｔａｒｔ＿ｃｏｄｅの次に来るオクツリーヘッダ及び一つ以上のオクツリーフレームを含む。ｏｃｔｒｅｅ＿ｆｒａｍｅ＿ｓｔａｒｔ＿ｃｏｄｅの値は常に０ｘ０００００１Ｃ８である。この値はストリームのルック−アヘッドパーシングにより検出される。
【０２３４】
＜２．７．１．３．オクツリーヘッダ＞
＜２．７．１．３．１．文法＞

【０２３５】
＜２．７．１．３．２．意味＞
このようなクラスはオクツリー圧縮に対してヘッダ情報を読み出す。
ｏｃｔｒｅｅＲｅｓｏｌｕｔｉｏｎＢｉｔｓにより長さが表現されるｏｃｔｒｅｅＲｅｓｏｌｕｔｉｏｎはオクツリーイメージノードのオクツリー解像度フィールドの値を含む。
【０２３６】
ｎｕｍＯｆＴｅｘｔｕｒｅｓはｔｅｘｔｕｒｅＮｕｍＢｉｔｓの長さであり、オクツリーイメージノードで使われるテクスチャー（またはカメラ）の番号を記述する。この値はオクツリーの各ノードに対するカメラＩＤの演算コーディングに使われる。ｔｅｘｔｕｒｅＮｕｍＢｉｔｓの値が０ならば、構造シンボルはルートノードのｃｕｒＴｅｘｕｒｅを２５５と設定することによりコーディングされない。
【０２３７】
＜２．７．１．４．オクツリーフレーム＞
＜２．７．１．４．文法＞

【０２３８】
＜２．７．１．４．２．意味＞
このクラスは幅優先横断順序で一つのオクツリーフレームを読み出す。レベル０の最初のノードから出発して現在レベルのあらゆるノードを読み出した後、次のレベルのノード数はそれぞれのノードシンボルであらゆる１をカウントすることによって把握される。次のレベルで、ノードの数（ｎＮｏｄｅｓＩｎＣｕｒＬｅｖｅｌ）はストリームから読み出される。
【０２３９】
それぞれのノードをデコーディングする時、２．７．１．６節に開示されたように適切なｃｏｎｔｅｘｔＩＣが付与される。
もし、現在ノード（ｃｕｒＴｅｘｔｕｒｅ）に対するテクスチャー（またはカメラ）ＩＤが親ノードにより定義されていないならば、テクスチャーＩＤもｔｅｘｔｕｒｅＣｏｎｔｅｘｔＩＤにより定義されているテクスチャーＩＤに対する文脈を使用してストリームから読み出す。もし、０でない値が得られれば（ｔｅｘｔｕｒｅＩＤが定義されていれば）、この値はまたつながるレベルであらゆる子ノードに適用される。あらゆるノードをデコーディングした後、ｔｅｘｔｕｒｅＩＤは依然として相変らずｔｅｘｔｕｒｅＩＤ値が割当てられていないオクツリーのリーフノードに割当てられる。
【０２４０】
＜２．７．１．５．適応算術デコーディング＞
この章ではｃｏｎｔｅｘｔＩＤによってＣ＋＋型の文法表現を使用してオクツリー圧縮に使われた適応算術コーダを記述する。ａａ＿ｄｅｃｏｄｅ（）はｃｕｍｕｌ＿ｆｒｅｑ［］関数である。ＰＣＴは２．７．１．６節に記述されたようなＰＣＴのアレイである。

【０２４１】
＜２．７．１．６．デコーディング手順＞
デコーディング手順の全体的な構造は２．７．１．５節に開示されている（また前述したエンコーディング手順を参考）。これは算術的にエンコーディングされた（圧縮された）ＴＢＶＯモデルを構成するビットストリームからＴＢＶＯノードを獲得する方法を示す。
【０２４２】
デコーディング手順の各段階で、文脈番号（すなわち、使用する確率インデックス）及びＰＴ自体を更新せねばならない。あらゆるＰＴの集合（整数アレイ）を確率モデル（Ｐｒｏｂａｂｉｌｉｓｔｉｃｍｏｄｅｌ）と称する。ｉ番目ＰＴのｊ番目成分（成分の和で割られた）はｉ番目文脈でｊ番目シンボルの発生確率を推定する。
【０２４３】
ＰＴの更新手順は次の通りである。まず、ＰＴはあらゆるエントリが１になるように初期化される。シンボルをデコーディングする前に文脈番号（ＣｏｎｔｅｘｔＩＤ）が選択されねばならない。ＣｏｎｔｅｘｔＩＤは下の２．７．１．６．１．節及び２．７．１．６．２節で指摘されたように以前にデコーディングされたデータから決定される。ＣｏｎｔｅｘｔＩＤが得られれば２進算術デコーダを使用してシンボルをデコーディングする。次に、デコーディングされたシンボル周波数に適応段階を付加してＰＴを更新する。全体（積算された）テーブル成分の和が積算臨界値より大きくなれば正規化が実施される（２．７．１．５．１．参照）。
【０２４４】
＜２．７．１．６．１．テクスチャーシンボルの文脈モデリング＞
テクスチャーシンボルは一つの文脈だけでモデリングされる。これは単に一つのＰＴが使われることを意味する。このテーブルのサイズはｎｕｍＯｆＴｅｘｔｕｒｅｓの数に一つを加えたものと同じである。先ず、このテーブルは全部１に初期化される。許容可能なエントリ値の最大値は２５６と設定される。適応段階は３２と設定される。このようなパラメータ値の組合わせによりテクスチャー番号をかなり可変的なストリームに適用することができる。
【０２４５】
＜２．７．１．６．２．ノードシンボルの文脈モデリング＞
２５６個の相異なるノードシンボルが存在し、それぞれのシンボルは２×２×２２進ボクセルアレイを表現する。対応するシンボルを互いに変換させる３Ｄ直交変換がこのようなアレイに適用される。
座標軸に対して９０＊ｎ゜（ｎ＝０，１，２，３）だけ回転及び対称させる４８個の固定された直交変換集合を想定すれば、このような行列は次のように数字順に与えられる。

【０２４６】
同じクラスに属すればこのような変換により２個のシンボルが連結されるようにクラスと呼ばれる２２個のシンボル集合が存在する。コーディング方法は次のようなＰＣＴを生成する。シンボルのＣｏｎｔｅｘｔＩＤは親が属するクラスの番号または組合わせられた番号（親クラス、親ノードで現在ノード位置）と同一である。これにより意味のある統計値を得るのに必要な時間を縮めながら文脈の数をかなり減少させることができる。
【０２４７】
それぞれのクラスに対して、一つの基本シンボルが決定され（テーブル９参照）、それぞれのシンボルに対してクラスの基本シンボルとして取扱う直交変換が事前に計算される（実際にエンコーディング／デコーディング手順でルックアップテーブルが使われる）。シンボルに対してＣｏｎｔｅｘｔＩＤが決定された後、任意のシンボルに、そのシンボルの親を基本成分として取扱うようにする逆変換（すなわち、逆行列）が適用される。テーブル１０にはそれぞれのシンボルに対する文脈と対応される直接変換が与えられている。
【０２４８】
【表１５】

【０２４９】
テーブル９．それぞれのクラスに対する基本シンボルの例
【０２５０】
文脈モデルは既にデコーディングされたシンボル等の番号Ｎに依存する。
Ｎ＜５１２に対して単に一つの文脈だけ存在する。ＰＴは全部１に初期化される。ＰＴでシンボルの数は２５６である。適応段階では２である。最大蓄積頻度は８１９２である。
【０２５１】
５１２≦Ｎ＜２５６０（＝２０４８＋５１２）に対して１−文脈（文脈番号が一つのパラメータという意味でクラスの番号）モデルが使われる。このモデルは２２個のＰＣＴを使用する。ＣｏｎｔｅｘｔＩＤはデコーディングされたノードの親が属するクラスの番号である。親が子より先にデコーディングされるため、この番号はいつもルックアップテーブル（テーブル１０参照）から決定できる。２２個のＰＣＴ各々は以前段階から得られたＰＣＴにより初期化される。各ＰＴでシンボルの数は２５６である。適応段階では３である。最大蓄積周波数はまた８１９２である。シンボルはデコーディングされた後、上で定義された直交逆変換を利用して変換される。直交変換番号は、現在ノードシンボルの親と同じノードシンボルＩＤを有するテーブル１０でさがすことができる。
【０２５２】
２５６０個のシンボルがデコーディングされれば、デコーダは２−文脈（次に説明されたように文脈番号が二つのパラメータで構成されるという意味で）に転換する。このモデルは１７６個（＝２２＊８、すなわち、８個の位置による２２個のクラス）のＰＣＴを使用する。ここでＣｏｎｔｅｘｔＩＤは親クラス及び親ノードでの現在ノードの位置に依存する。このモデルに対する初期ＰＴはそれの文脈にのみ依存する。あらゆる８位置ＰＣＴは以前段階で与えられたクラスに対して得られたＰＣＴのクローンである。それぞれのＰＴでシンボルの数は２５６である。適応段階では４である。最大蓄積頻度はまた８１９２である。
【０２５３】
シンボルはデコーディングされた後、以前モデルのように直交逆変換（テーブル１０に与えられた一つ）を利用して変換される。
それぞれのクラスに対する基本成分の形態はテーブル１０を使用して容易に得ることができる。基本成分は正確に変換ＩＤが０（番号０は同じ変換に割当てられる）に対するシンボルである。
テーブル１０．ノードシンボル、シンボルのクラス番号及びシンボルをこのようなクラスの固定された基本成分とする直交変換に対する結合ルックアップテーブル
【０２５４】
【表１６】

【表１７】

【表１８】

【０２５５】
以下、本発明による深さイメージに基づく３次元客体表現装置及び方法で使われるＭＰＥＧ−４ノード規定及びオクツリーイメージフォーマットの圧縮方法についてより詳細に説明する。
【０２５６】
本発明は、大部分イメージと深さマップに基づいた効果的で、かつ効率的な表現を提供し、前述した利点を全的に利用する一群のデータ構造−深さイメージに基づく表現（ＤＩＢＲ）−を開示する。また、主要なＤＩＢＲフォーマット−シンプルテクスチャー、ポイントテクスチャー、及びオクツリーイメージ−を簡略に説明する。
【０２５７】
図２０は色相イメージと深さマップの一例を示した図面であり、図２１は階層的な深さイメージ（Ｌａｙｅｒｅｄｄｅｐｔｈｉｍａｇｅ：ＬＤＩ）の一例を示した図面（（ａ）客体の投影、（ｂ）階層的なピクセル））である。
シンプルテクスチャーはイメージ、対応する深さマップ、そしてカメラ説明（カメラの位置、方向及び形態、直交または遠近）で構成されたデータ構造である。一つのシンプルテクスチャーの表現容量はビルディングの正面のような客体に制限される。深さマップを有する正面イメージにより実質的な角度領域で正面視点を再構成できる。
【０２５８】
しかし、参照イメージがビルディング面の潜在的にみえることができるあらゆる部分を含む場合に、適切な位置に配置されたカメラにより生成されたシンプルテクスチャーの集合で全体ビルディングを表現できる。もちろん、これは木、人体、自動車にも適用される。さらに、シンプルテクスチャーの集合は３Ｄ動映像データを取扱うためのかなり自然な手段を提供する。この場合、参照イメージは参照ビデオストリームと共に再配置される。それぞれの３Ｄフレームに対する深さマップはこのようなビデオストリームのアルファチャンネル値によるか、分離されたグレースケールビデオストリームにより表現される。このような形態の表現で、イメージは損失圧縮フォーマットのように、たとえばＪＰＥＧに貯蔵されうる。これは色相情報の量を大きく減少させ、特に動映像の場合にそうである。しかし、形態情報（深さマップ）は損失なしに圧縮されねばならず、これは貯蔵容量の全体的な減少に影響を及ぼす。
【０２５９】
複雑な形態の客体の場合、時には当然な数の参照イメージで可視的な面全体を覆うことが容易ではない。その場合に望ましい表現はポイントテクスチャーである。このフォーマットも参照イメージ及び深さマップを保有するが、この場合、二つには多重値が付与される。カメラにより提供されたそれぞれの視線（直交または遠近）、あらゆる線の交差点に対して色相及び距離が客体と共に貯蔵される。交差点の数は線ごとに異なる。いくつかのポイントテクスチャーよりなる集合は複雑な客体の場合にも非常に詳細な表現を提供する。しかし、このフォーマットはシンプルテクスチャーの２Ｄ規則性の大部分に欠けていて自然なイメージ基盤圧縮形態を有することができない。同じ理由で、このフォーマットは単に静止客体に対して使われる。
【０２６０】
オクツリーイメージフォーマットは、‘大部分の２次元’シンプルテクスチャーと‘大部分の３次元’ポイントテクスチャーとの中間位置を占有する。オクツリーイメージは色相成分はイメージの集合で表現される一方、客体の形態をオクツリー構造の体積表現（閉じられたキューブの一般的な２進分割の階層的に構成されたボクセルに貯蔵する。
【０２６１】
このフォーマットはまた、それぞれのリーフボクセルに対して色相を含む参照イメージのインデックスを貯蔵する付加的なオクツリー形態のデータ構造を含む。オクツリーイメージのレンダリング段階で、リーフボクセルの色相はそれを対応する参照イメージに垂直に投影することによって決定される。オクツリーイメージの形態部分に対して効率的な圧縮方法が開発された。多様な適応文脈に基づく算術コーディングが存在する。
【０２６２】
ここで、文脈はデータの形態的特性を明確に利用して構成される。損失圧縮参照イメージと共に圧縮を利用することによってオクツリーイメージは空間的に非常に効率的な表現になる。シンプルテクスチャーのようにオクツリーイメージは参照イメージの代りに参照ビデオストリームを有し、二つの付加的な形態を表現するオクツリーに対するストリーム及びそれぞれの３Ｄフレームに対応するイメージ当たりボクセルを有するアニメーションバージョンを有する。
【０２６３】
ＤＩＢＲ群の新しいバージョンのＭＰＥＧ−４標準のために開発されてきたし、ＭＰＥＧ−４ＡＦＸに含まれるように採択された。ＡＦＸは総合的なＭＰＥＧ−４環境のためのより向上した特徴を提供し、関連のあるアニメーションコンテンツに対して再使用可能な構造（現存のＭＰＥＧ−４構造を利用できる）を算出する共用できる道具の集合を含む。それぞれのＡＦＸツールはＢＩＦＳ（ＢｉｎａｒｙＦｏｒｍａｔｆｏｒＳｃｅｎｅｓ）ノード、総合的なストリーム、及び音響−映像ストリームとの互換性を示す。
【０２６４】
ＡＦＸの現バージョンは提案するＤＩＢＲだけでなく動映像に対する高級レベル描写（すなわち、動映像に基づいた骨格と皮膚）、向上したレンダリング（すなわち、手順的なテクスチャーマッピング、光フィールドマッピング）、簡略な表現（すなわち、ＮＵＲＢＳ曲面、ソリッド表現、下位分割曲面）、低伝送率アニメーション（すなわち、キーフレームアニメーション圧縮）等で構成される。
【０２６５】
ＤＩＢＲフォーマットは、ユーザーに特定の作業に最も適した柔軟な道具を提供して、以前に提案された他のアイディアの長所と結合するように考案された。例えば、非動映像シンプルテクスチャー及びポイントテクスチャーは知られたフォーマットの特別な場合である一方、オクツリーイメージは全く新しい表現である。しかし、ＭＰＥＧ−４状況で、３つの基本ＤＩＢＲフォーマットはいずれもビルディングブロックと見なされることができ、ＭＰＥＧ−４構造によりこれらを結合することは、本文献で提案されたイメージ基盤表現の多くを包括するだけでなく新しいフォーマットを構成するにあたって相当な潜在力を付与する。
【０２６６】
以下、深さイメージに基づく表現を説明する。
前述された概念及び発明者が開発したいくつかを考慮して次のＭＰＥＧ−４ＡＦＸに使用するためのシンプルテクスチャー、ポイントテクスチャー、そしてオクツリーイメージのようなイメージ基盤フォーマットの集合を提案した。シンプルテクスチャー及びオクツリーイメージはアニメーションバージョンを有する。
【０２６７】
シンプルテクスチャーは深さイメージと結合された一つのイメージである。シンプルテクスチャーは緩和テクスチャーに相応する一方、ポイントテクスチャーはＬＤＩに相応する。
【０２６８】
ブロック構成時、シンプルテクスチャー及びポイントテクスチャーに基づいてＭＰＥＧ−４構造を使用する多様な表現を生成できる。公式的な規定は後述し、ここでは結果を形態的に記述する。
深さイメージ構造は結合されるボックス、空間上の位置及びいくつかの他の情報と共にシンプルテクスチャーまたはポイントテクスチャーを規定する。深さイメージ集合は変換ノードと呼ばれる一つの構造の下に統合され、これにより多様な有用な表現を生成できる。これらのうち二つが最も広く使われ、これらは特定のＭＰＥＧ−４名称を有してはいないが、実務上これらをボックステクスチャー（ＢｏｘＴｅｘｔｕｒｅ：ＢＴ）及び一般化されたボックステクスチャー（ＧｅｎｅｒａｌｉｚｅｄＢｏｘＴｅｘｔｕｒｅ：ＧＢＴ）と称する。
【０２６９】
ＢＴは客体または場面の結合キューブに対応する６個のシンプルテクスチャーの集合である一方、ＧＢＴは共に両立する３Ｄ表現を提供する任意個数のシンプルテクスチャーの集合である。ＢＴの例が図２２に図示されている。図２２には、参照イメージ、深さマップ、そして結果的な３Ｄ客体が図示されている。ＢＴは増加するワーピングアルゴリズムにより描写されることができるが、ＧＢＴにも適用可能な他の方法を使用する。ＧＢＴ表現の例は図２３に図示されている。図２３で複雑な客体である椰子を表現するために２１個のシンプルテクスチャーが使われる。
【０２７０】
例えば、統合メカニズムにより同じ客体または同じ客体の一部を表現するために他のカメラを有するいくつかのＬＤＩを使用できることに注目せねばならない。従って、イメージ基盤客体と同じデータ構造、ＬＤＩツリーセル、サーフェル基盤ツリー構造は、いずれも場面の構造にシンプルテクスチャーとポイントテクスチャーの位置及び解像度を適用するにおいてはるかに強い柔軟性を提供するこのようなフォーマットの特別な場合である。
【０２７１】
次に構造化された２進体積オクツリー（ＴｅｘｔｕｒｅｄＢｉｎａｒｙＶｏｌｕｍｅｔｒｉｃＯｃｔｒｅｅ：ＴＢＶＯ）について説明する。
より柔軟な表現及び速いレンダリングを有する多重解像度形態及びテクスチャーを利用するためにＴＢＶＯに基づいたオクツリーイメージ表現が開発された。ＴＢＶＯの目標は２進体積オクツリー（ＢｉｎａｒｙＶｏｌｕｍｅｔｉｃＯｃｔｒｅｅ：ＢＶＯ）の改善として速い視覚化が可能なより柔軟な表現／圧縮フォーマットを考案することである。ＴＢＶＯは形態を表現するＢＶＯ、参照イメージ集合、及びオクツリーノードに対応するイメージインデックスなどの３つの主な成分で構成される。
【０２７２】
ＢＶＯ形式の形態情報は、通常的なオクツリー方式で大きなセルに結合された規則的に離れている２進（占有または非占有）ボクセルの集合である。このような表現は、深さを有するピクセル各々が３次元空間で固有な点を規定するので、深さイメージデータから’点雲’形式の媒介子を通じて容易に得られることができる。点雲のＢＶＯへの変換は図２４に図示されている。
【０２７３】
類似の過程により多角形モデルをＢＶＯに変換できる。ＢＶＯのテクスチャー情報は参照イメージから得られる。参照イメージは与えられたカメラ位置と方向とでのボクセルのテクスチャーである。従って、ＢＶＯ自体は参照イメージと共にモデル表現を提供する。しかし、それぞれのＢＶＯリーフに対する参照イメージインデックスを貯蔵する付加的な構造は、より速い視覚化及び良好な品質を可能にしたことが明らかになった。
【０２７４】
ＢＶＯ視覚化の主要な問題は、レンダリング中にそれぞれのボクセルの対応するカメラインデックスを決定せねばならないということである。このために少なくともボクセルが見えるカメラの存在を決定しなければならない。もし、単純計算方法を使用すればこのような手順は非常に遅い。このような問題の上に、いかなるカメラによっても見えないボクセルに対しては依然としていくつかの難しさが存在し、これは描写されたイメージに望ましくない雑音をもたらす。
【０２７５】
それぞれのボクセルに対して明確な色相を貯蔵することが可能な解決策になりうる。しかし、この場合、色相情報を圧縮するにおいていくつかの問題点がある。すなわち、ボクセル色相をイメージフォーマットでグループ化し、それを圧縮すれば隣接するボクセルの色相関連性が破壊されて圧縮率が満足できなくなる。
【０２７６】
ＴＢＶＯでこのような問題は、あらゆるボクセルに対するイメージインデックスを貯蔵することによって解決される。インデックスは大体大きいボクセルグループに対して同一であり、これにより付加的な情報の経済的な貯蔵のためのオクツリー構造を使用できる。モデルに対する実験で、ＢＶＯと参照イメージだけを使用する表現に比べて平均的にただ１５％の体積が増加することと観察された。このようなモデリングはややより複雑であるが、より柔軟な方法で任意の形態の客体を表現できる。
【０２７７】
スプラットのサイズはボクセルのサイズから容易に算出されるので、ＴＢＶＯはスプラットを持ってレンダリングするための非常に便利な表現である。ボクセル色相は参照イメージとボクセルのイメージインデックスを使用して容易に決定される。
【０２７８】
次に、ＴＢＶＯのストリーミングについて説明する。
２５５個のカメラで十分であると仮定し、インデックスに対して１バイトまで割り当てる。ＴＢＶＯストリームはシンボルストリームである。あらゆるＴＢＶＯシンボルはＢＶＯシンボルまたはテクスチャーシンボルである。テクスチャーシンボルはカメラインデックスを称し、カメラインデックスは“規定されていない”特定の番号またはコードである。
【０２７９】
以下、“規定されていない”コードを‘？’とする。ＴＢＶＯストリームは幅優先順序で横断する。ＢＶＯを有しており、あらゆるリーフボクセルがイメージインデックスである場合にＴＢＶＯストリームの記述方法について説明する。これはモデリング段階で実施されねばならない。ＴＢＶＯストリームはリーフノードを含んでいるあらゆるＢＶＯノード（ＢＶＯシンボルを有していない）を幅優先順序で横断する。図２５にはストリームを完壁に記述する擬似コードが図示されている。
【０２８０】
ＴＢＶＯビットストリームの技術に対する例が図１４に図示されている。図１４（ａ）に示されたＴＢＶＯツリーに対するシンボルストリームは手順によって図１４（ｃ）に示されたように得られる。この例で、テクスチャーシンボルはバイトで表現される。しかし、実際的なストリームでは３個の値（２個のカメラと規定されていないコード）だけ表現すればよいので、それぞれのテクスチャーシンボルは単に３ビットだけ必要である。
【０２８１】
次に、ＤＩＢＲアニメーションについて説明する。
アニメーションバージョンはＤＩＢＲフォーマットの二つ−シンプルテクスチャーとオクツリーイメージだけを含む深さイメージ−に対して規定される。データサイズは３Ｄアニメーションにおいて重要な問題のうち一つである。ビデオストリームは自然と動映像バージョンに結合されうるので実質的なデータ減少を提供するこのような特定のフォーマットを選択する。
【０２８２】
深さイメージに対して、アニメーションは参照イメージをＭＰＥＧ−４動映像テクスチャーに取り替えることによって実施される。高品質損失映像圧縮は算出される３Ｄ客体の外形に深刻に影響を及ぼさない。深さマップを参照映像ストリームのアルファチャンネルに無損失モードに近く貯蔵されうる。レンダリング段階であらゆる参照イメージのようにフレームが受信されて圧縮が解除された後に３Ｄフレームが描写される。
【０２８３】
オクツリーイメージのアニメーションは似ている。参照イメージはＭＰＥＧ−４動映像テクスチャーにより代替されて新しいオクツリーストリームが現れる。
【０２８４】
次に、ＭＰＥＧ−４ノードを定義する。
ＤＩＢＲフォーマットはＭＰＥＧ−４ＡＦＸノード定義に詳細に記述されている。深さイメージは、シンプルテクスチャー（ＳｉｍｐｌｅＴｅｘｔｕｒｅ）またはポイントテクスチャー（ＰｏｉｎｔＴｅｘｔｕｒｅ）に対する円錐視点パラメータを決定するフィールドを含む。オクツリーイメージノードは形態と参照イメージフォーマットの集合が規定されたＴＢＶＯ形態で客体を表現する。場面に独立的な情報はＤＩＢＲデータ構造の特別なフィールドに貯蔵され、これによりＤＩＢＲ客体の相互作用を場面の残りの部分で補正できる。ＤＩＢＲノードの定義は図２６に図示されている。
【０２８５】
図２７は、深さイメージの空間的な配置を示した図面である。図９に各フィールドの意味が記載されている。深さイメージノードは一つのＤＩＢＲ客体を規定する。複数の深さイメージノードが互いに関連されている時、これらはグループで処理され、従って同じ変換ノードの下に位置せねばならない。ｄｉＴｅｘｔｕｒｅフィールドは深さを有するテクスチャー（シンプルテクスチャーまたはポイントテクスチャー）を特定し、これは深さイメージノードに規定された領域にマッピングされる。
【０２８６】
オクツリーイメージノードはオクツリー構造及びそれの投影されたテクスチャーを定義する。オクツリー解像度フィールドは閉じられたキューブの側面に沿うオクツリーリーフの最大個数を特定する。オクツリーフィールドはオクツリー内部ノードの集合を定義する。それぞれの内部ノードはバイトで表現される。このようなバイトのｉ番目ビットの１は内部ノードのｉ番目の子に対して子ノードが存在するということを意味する。
【０２８７】
一方、０は子ノードが存在しないことを意味する。オクツリー内部ノードの順序はオクツリーの幅優先横断順序でなければならない。内部ノードの８個の子順序が図１４（ｂ）に図示されている。ボクセルイメージインデックスフィールドはボクセルに割当てられたイメージインデックスの配列を含む。レンダリング段階で、オクツリーリーフに起因した色相はリーフを特定のインデックスを有するイメージに垂直に投影することによって決定される。インデックスはオクツリーと同じ形式で貯蔵される。
【０２８８】
もし、特定のイメージが特定のボクセルに含まれたあらゆるリーフに対して使われるならば、イメージのインデックスはストリームに入力される。そうでない場合に固定された’追加的な下位分割’コードが入力され、これはイメージインデックスが現在ボクセルの子各々に対して個別的に規定されることを意味する（同一に反復される形態に）。もし、ボクセルイメージインデックスが空いているならばイメージインデックスはレンダリング段階で決定される。イメージフィールドは、ｄｉＴｅｘｔｕｒｅフィールドに対して単純テクスチャーを有する深さイメージノードの集合を特定する。しかし、深さイメージノードの隣接平面（ｎｅａｒＰｌａｎｅ）と遠接平面（ｆａｒＰｌａｎｅ）フィールド、そして単純テクスチャーノードでの深さフィールドは使われない。
【０２８９】
ＤＩＢＲフォーマットに対するレンダリング方法はＡＦＸ標準の一部ではないが、ＤＩＢＲ客体レンダリングの簡略性、速度及び品質を得るために使われる概念は説明する必要がある。本レンダリング方法は‘レンダリング原形’として使われる小さくて扁平な色相パッチのスプラットに基づく。下に略述された２つの接近法は深さイメージとオクツリーイメージとの２つの相異なる表現に適用される。レンダリング速度を向上させるためのスプラッティングのためにＯｐｅｎＧＬ関数が採用される。それにも拘わらず、ソフトウェアレンダリングも可能であり、これにより深さイメージまたはオクツリーイメージの単純な構造を利用して計算を最適化できる。
【０２９０】
深さイメージ客体をレンダリングするために使用する方法は極めて簡単である。しかし、それはＯｐｅｎＧＬ関数に依存してハードウェア加速器によりもっと速く動作することを言及する必要がある。この方法で、深さを有するあらゆるピクセルはレンダリングされる単純テクスチャー及び点テクスチャーから３Ｄ点に変換され、その後、このような点で小さなポリゴン（スプラット）の位置を決定してＯｐｅｎＧＬのレンダリング関数を適用する。単純テクスチャーの場合に対するこのような過程の擬似コードが図２８に図示されている。点テクスチャーの場合は正確に同じ過程で扱われる。
【０２９１】
スプラットのサイズは点と観察者との間の距離に適するように採択されねばならない。次のような簡単な方法が使われた。まず、与えられた３Ｄ客体の閉じられたキューブを経た均一格子に細分する。スプラットのサイズは格子各々のセルに対して計算され、この値はセル内の点に対して使われる。計算は次のように実施される。
−ＯｐｅｎＧＬによりセルをスクリーンにマッピングする。
−投影の最も大きい対角線の長さＬを計算する（ピクセル単位）。
−Ｄ（スプラット径）をＣ・Ｌ／Ｎと算定する。
ここで、Ｎはセル面当り点個数の平均であり、Ｃは約１．３の発見定数である。
【０２９２】
このような方法はより正確な半径計算、より複雑なスプラット、アンチエーリアシングなどにより明確に改善される。しかし、このような簡単な方法も良好な見解品質を提供する。
同じ方法がオクツリーイメージのレンダリングに適用される。ここでより粗いレベルの一つでオクツリーノードがスプラットサイズの前述した計算で使われる。しかし、オクツリーイメージに対して色相情報はボクセル集合に先にマッピングされねばならない。それぞれのボクセルは対応する参照イメージインデックスを有しているので、これは非常に容易に実施される。参照イメージでピクセル位置もオクツリーストリームのパーシング過程中に把握される。オクツリーイメージボクセルの色相が決定されてすぐスプラットサイズが算定され、ＯｐｅｎＧＬに基づいたレンダリングが前述したように使われる。
【０２９３】
ＤＩＢＲフォーマットがいくつかの３Ｄモデルに対して実施されてテストされた。モデルのうち一つ（“膽星台”）は実際に物理的な客体をスキャニングして得られ（Ｃｙｂｅｒｗａｒｅ社のカラー３Ｄスキャナーが使われた）、ほかのものは３ＤＳ−ＭＡＸデモパッケージから変換された。テストはＯｐｅｎＧＬ加速器を装着した１．８ＧＨｚインテルペンティアムＩＶ（登録商標）上で実施された。
多角形からＤＩＢＲフォーマットに変換する方法は以後に記述し、その後、モデリング、表現、そして相異なるＤＩＢＲフォーマットの圧縮結果を記述する。大部分のデータは深さイメージ及びオクツリーイメージに関するものである。このようなフォーマットは動映像バージョンを有して効果的に圧縮されることができる。提示されるモデルはいずれも直交カメラで構成された。これは直交カメラは一般的に‘小さな’客体を表現するのに適切な方法であるからである。距離がある環境の経済的なＤＩＢＲ表現のために遠近カメラが大部分使われる。
【０２９４】
ＤＩＢＲモデル生成は、十分な数のシンプルテクスチャーを得ることから始まる。現実世界の客体に対してこのようなデータがデジタルカメラとスキャニング装置から得られる一方、多角形客体に対してシンプルテクスチャーが計算される。次の段階は使用しようとするＤＩＢＲフォーマットに依存する。
深さイメージは簡単に得られたシンプルテクスチャーの集合である。たとえ深さマップを圧縮された形式で貯蔵できたとしても、形態において小さな歪曲がたびたびかなり目立つので無損失圧縮だけ許容される。
【０２９５】
参照イメージは損失圧縮形式で貯蔵できるが、この場合に前処理が必要である。ＪＰＥＧ損失圧縮のような公知の方法を使用することは一般的に収容できるが、特に、背景色相が‘客体’に散る地点である、客体と参照イメージの背景との境界による境界面の雑音は生成された３次元客体画面でより目立つようになる。このような問題の解決方案は、ブロックの平均色相と強度の急速な減衰を利用して境界ブロックでイメージを背景に拡張した後、ＪＰＥＧ圧縮を適用することである。このような効果は、背景ピクセルはレンダリングに使われないため、歪曲を歪曲が影響を及ぼさない背景に‘スキージング’することと似ている。損失圧縮された参照イメージの内部境界もやはり雑音をもたらすが、これは一般的にあまり目につかない。
【０２９６】
オクツリーイメージモデルを生成するために中間点基盤表現（ＰｏｉｎｔＢａｓｅｄＲｅｐｒｅｓｅｎｔａｔｉｏｎ：ＰＢＲ）を使用する。ＰＢＲを構成する点の集合は、参照イメージに存在するピクセルに対応する深さマップに規定された距離により遷移することによって得られた色相を有する点の集合である。元のシンプルテクスチャーは結果的なＰＢＲが十分に正確な客体表面に対する推定を提供するように構成される。
【０２９７】
その後、ＰＢＲは図２４に示したようなオクツリーイメージに変換され、このようなフォーマットにより賦課された制限を満足する新しい完全な参照イメージ集合を生成するために使われる。同時に、オクツリーボクセルに対する参照イメージインデックスを示す付加的なデータ構造ボクセルイメージインデックスが生成される。この時、参照イメージは損失フォーマットで貯蔵されねばならず、これらはまず以前下位章で説明したように前処理される。さらに、ＴＢＶＯ構造は明白にボクセルイメージインデックスの体積をよりもっと縮めるので、重畳されるピクセルは捨てられ、これはボクセルイメージインデックスの体積をさらに縮める。元の参照イメージとＪＰＥＧフォーマットで処理された参照イメージの例が図２９に図示されている。
【０２９８】
オクツリーイメージに対する損失圧縮による品質低下は無視できるほどである。しかし、時に深さイメージ客体に対しては依然として目につく。
ポイントテクスチャーモデルは、前述したように参照平面への客体投影を利用して構成される。もし、これにより十分なサンプルが生成されていなければ（これは投影ベクターにほとんど垂直の表面部分に対する場合でありうる）、付加的なシンプルテクスチャーがより多くのサンプルを提供するために構成される。得られた点の集合はその後にポイントテクスチャー構造で再構成される。
【０２９９】
レンダリング速度に関するデータを提示する。“椰子５１２”の深さイメージのレンダリング速度は約２ｆｐｓ（ｆｒａｍｅｐｅｒｓｅｃｏｎｄ）である（２１個の単純テクスチャーであることに注目）。大きさが５１２である参照イメージを有してテストされた他の静的モデルは５〜６ｆｐｓでレンダリングされる。レンダリング速度は場面の複雑度に従属的ではなく参照イメージの数と解像度とに大部分従属的であることに注目せねばならない。これは多角形表現に対する重要な長所であり、特に動映像の場合にもっとそうである。動映像オクツリーイメージの“ドラゴン５１２”は秒当たり２４フレームで視覚化される。
【０３００】
“天使２５６”の深さイメージモデルが図２２に図示されている。図３０〜図３４は、いくつかの他のＤＩＢＲと多角形モデルを示す。図３０は“モルトン”モデルの多角形及び深さイメージの外観を比較した図面である。深さイメージモデルはＪＰＥＧフォーマットの参照イメージを使用し、レンダリングは前述された最も簡単なスプラッティングにより実施されるが、イメージ品質はかなり良好である。
【０３０１】
図３１は、スキャニングされた“膽星台”モデルの２つの異なるバージョンを比較した図面である。モデルの上段部分にある黒い点は入力データの雑音に起因する。図３２は、２１個のシンプルテクスチャーよりなるより複雑な“椰子”モデルを示す。たとえ単純化されたスプラッティングを実行したとしても、その結果、一般的にリーフが３ＤＳ−ＭＡＸの元のイメージより広くなり、また良好な品質を示す。
【０３０２】
最後に、図３３は、“ドラゴン５１２”オクツリーイメージアニメーションから３Ｄフレームを示す。図３４は、ポイントテクスチャーフォーマットが優秀な品質のモデルを提供できることを示す。
本発明による深さイメージに基づくノードは、シンプルテクスチャーノード、ポイントテクスチャーノード、深さイメージノード、及びオクツリーイメージノードを含む。深さイメージノードは深さ情報と色相イメージとより構成される。色相イメージはシンプルテクスチャーノード及びポイントテクスチャーノードのうち選択される。
【０３０３】
客体を６個の観察視点（正面、後面、平面、背面、左面、及び右面）から注視する時、客体は６対のシンプルテクスチャーノードにより表現できる。シンプルテクスチャーノードの構造は図２６に図示されている。
図２６を参照すれば、シンプルテクスチャーノードはそれぞれのピクセルに対する色相を含む色相イメージが記録されるテクスチャーフィールド及びそれぞれのピクセルに対する深さ値が記録される深さフィールドで構成される。シンプルテクスチャーノードは断層のイメージ基盤表現（ＩｍａｇｅＢａｓｅｄＲｅｐｒｅｓｅｎｔａｔｉｏｎ：ＩＢＲ）テクスチャーを定義する。ここで、テクスチャーは色相を有する平面イメージを意味する。
【０３０４】
テクスチャーフィールドには、イメージを構成するそれぞれのピクセルの色相を含む平面イメージが記録される。深さフィールドにはイメージを構成するそれぞれのピクセルに対する深さ値が記録される。深さフィールドに記録されている深さ値の集合はテクスチャーフィールドに記録されている平面イメージに対応する深さイメージを形成する。ここで深さイメージは深さ値によってグレースケールで表現された平面イメージである。動映像客体を生成するビデオフォーマットの場合に深さ情報及び色相情報は複数のイメージフレーム列である。
【０３０５】
テクスチャーフィールドに記録されている平面イメージ（すなわち、色相を有するイメージ）と深さフィールドに記録されている平面イメージ（すなわち、グレースケールで表現されたイメージ）とはシンプルテクスチャーノードを構成する。図１には、正面視点に対するシンプルテクスチャーノードにより表現された“モルトン”客体が図示されている。結論的に、客体は６個の視点に対して生成されたイメージ対である６個のシンプルテクスチャーノードにより表現される。図２２には、６個のシンプルテクスチャーノードにより表現された“天使”客体が図示されている。
【０３０６】
一方、色相イメージがポイントテクスチャーノードで構成される。図２１には客体を参照平面（この場合、客体から一定距離離れて客体の後面と面する平面）に投影することによって生成されるポイントテクスチャーが図示されている。
【０３０７】
ポイントテクスチャーノードの構造は図２６に図示されている。
図２６を参照すれば、ポイントテクスチャーノードは大きさフィールド、解像度フィールド、深さフィールド、及び色相フィールドで構成される。大きさフィールドにはイメージ平面の大きさ情報が記録される。大きさフィールドはイメージ平面の幅と高さとが記録される幅フィールド及び高さフィールドで構成される。イメージ平面の大きさは参照平面に投影された客体全体を含む大きさで設定される。
【０３０８】
解像度フィールドには客体の深さに対する解像度情報が記録される。例えば、解像度フィールドに８が記録されている場合に客体の深さは参照平面との距離を基準に２５６段階で表現される。
【０３０９】
深さフィールドにはイメージ平面を形成するそれぞれのピクセルに対する複数の深さ情報が記録される。深さ情報は、イメージ平面に投射されたピクセルの数とそれぞれのピクセルの深さ値とが順次に記録された行列である。色相フィールドにはイメージ平面に投射されたそれぞれのピクセルに対する色相情報が記録される。色相情報は、イメージ平面に投射されたピクセル各々に対する深さ値に対応する色相値が順次に記録された行列である。
深さイメージノードを構成する視点情報は視点フィールド、視野フィールド、投影方法フィールド、及び距離フィールドを含む。
【０３１０】
視点フィールドにはイメージ平面を眺める視点が記録される。視点フィールドは視点の位置と方向が記録される位置フィールドと方向フィールドとを有する。位置フィールドに記録される位置は、イメージ平面が存在する座標系の原点に対する相対的な位置である。また、方向フィールドに記録される方向は所定の基準方向に対する相対的な回転量である。
【０３１１】
視野フィールドには視点からイメージ平面までの視野領域が記録される。投影方法フィールドには視点からイメージ平面までの投影方法が記録される。本発明で投影方法は、視野領域が幅と高さで表示される直交投影方法と、視野領域が水平角と垂直角とで表示される遠近投影方法とのうち選択される。直交投影方法が選択された場合に（すなわち、投影方法フィールドがＴＲＵＥと設定された場合）視野領域の幅と長さは各々イメージ平面の幅と高さであり、遠近投影方法が選択された場合に視野領域の幅と高さは各々視点からイメージ平面に至る視線により形成される水平角と垂直角とである。
【０３１２】
距離フィールドには、視点から近い境界平面までの距離と、視点から遠い境界平面までの距離とが記録される。距離フィールドは、視点から隣接平面までの距離が記録されるフィールド（ｎｅａｒＰｌａｎｅ）と遠接平面までの距離が記録されるフィールド（ｆａｒＰｌａｎｅ）とで構成される。距離フィールドにより深さ情報の領域が規定される。
【０３１３】
図３５（ａ）及び図３５（ｂ）には、各々シンプルテクスチャーノード及びポイントテクスチャーノードを有する深さイメージノードにより客体を表現する時、各ノードの対応関係が図示されている。
【０３１４】
図３５（ａ）を参照すれば、客体は６個の視点に対応する深さイメージノードの組合わせにより表現される。それぞれの深さイメージノードは視点情報とシンプルテクスチャーノードとで構成される。シンプルテクスチャーノードは色相イメージと深さイメージとの対で構成される。
【０３１５】
図３５（ｂ）を参照すれば、客体は一つの深さイメージノードにより表現される。深さイメージノードの構成は前述した通りである。ポイントテクスチャーノードは、客体が投射された平面に関する情報が記録される平面情報、イメージ平面に投射された客体の各点の深さ情報及び色相情報で構成される。
【０３１６】
オクツリーイメージノードは、客体全体を含むボクセルを構成する内部ノード等の構造及び参照イメージにより客体を表現する。オクツリーイメージノードの構成が図２６に図示されている。
【０３１７】
図２６を参照すれば、オクツリーイメージノードはオクツリー解像度フィールド、オクツリーフィールド、インデックスフィールド、及びイメージフィールドで構成される。
【０３１８】
オクツリー解像度フィールドには客体全体を含む閉じられたキューブの側面に接することができるオクツリーリーフの最大値が記録される。オクツリーフィールドにはオクツリーの内部ノードの構造が記録される。内部ノードは客体全体を含む閉じられたキューブを分割した下位キューブに対するノードである。閉じられたキューブは８個の下位キューブに分割され、それぞれの下位キューブは既設定されている大きさになるまで反復的に８個の下位キューブに再分割される。
【０３１９】
３回の分割がなされた場合に第２分割された下位キューブに対するノードを現在ノードとすれば、第１分割された下位キューブに対するノード及び第３分割された下位キューブに対するノードは各々現在ノードに対して親ノード及び子ノードと称する。８個の分割された下位キューブの順序は幅優先順位により順位番号が付与される。図１４には、下位キューブに対する順位番号付与方式が図示されている。内部ノード各々はバイトで表現され、内部ノードに属する子ノードに対する下位子ノードの存在如何はバイトを構成するビット列に記録されるノード情報により表現される。
【０３２０】
インデックスフィールドには内部ノード各々に対応する参照イメージのインデックスが記録される。イメージフィールドにはインデックスフィールドに記録されたインデックスに該当する参照イメージが記録される。参照イメージは深さイメージノードであり、深さイメージノードの構造は前述した通りである。
【０３２１】
図３６には、オクツリーイメージノードにより客体を表現する時、該当オクツリーイメージノードの構成が図示されている。
図３６を参照すれば、オクツリーイメージノードはビットラッパー（Ｂｉｔｗｒａｐｐｅｒ）によりカプセル化されている。それぞれのビットラッパーは一つのオクツリーイメージノードを含んでいる。シンプルテクスチャーノードで客体を表現する場合にオクツリーイメージノードは６個の深さイメージノードを有しており、それぞれの深さイメージノードにはシンプルテクスチャーノードが含まれている。これと異なり、ポイントテクスチャーノードで客体を表現する場合にはオクツリーイメージノードは１個の深さイメージノードを有する。
【０３２２】
本発明はまたコンピュータで読み出すことができる記録媒体にコンピュータが読み出すことができるコードとして具現することが可能である。コンピュータが読み出すことができる記録媒体はコンピュータシステムによって読み出されるデータが貯蔵されるあらゆる記録装置を含む。コンピュータが読み出すことができる記録媒体の例にはＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ貯蔵装置などがあり、またキャリヤウェーブ（例えばインターネットを通した伝送）の形態で具現されるものも含む。また、コンピュータが読み出すことができる記録媒体は、ネットワークで連結されたコンピュータシステムに分散されて分散方式でコンピュータが読み出すことができるコードが貯蔵されて実行される。
【０３２３】
【発明の効果】
本発明によれば、このようなイメージ基盤表現は、色相３Ｄ客体の完全な情報を２次元イメージの集合−イメージ処理及び圧縮などの公知の方法に直ちに適用できる単純で規則的な構造−でエンコーディングするため、アルゴリズムが簡単で多くの部分でハードウェアにより支援されうる。その上に、イメージ基盤モデルに対するレンダリング時間は、ポリゴンの場合のように形態的な複雑性に比例せずに一般的に参照及び出力イメージに存在するピクセルの数に比例する。さらに、イメージ基盤表現が現実世界の客体と場面とに適用されれば数百万個の多角形及び高コストを使用せずに自然的な場面の写真のような現実的なレンダリングが可能になる。
以上、本発明の望ましい実施例について図示して説明したが、本発明は前述した特定の望ましい実施例に限定されず、特許請求の範囲で請求する本発明の要旨を外れずに当業者であれば多様な変形実施が可能であることはもちろん、そのような変更は特許請求の範囲に記載された範囲内にある。
【図面の簡単な説明】
【図１】現在の参照ソフトウェアに統合されたＩＢＲの例を示した図面である。
【図２】オクツリーの構造及び子の順序を示した図面である。
【図３】オクツリー圧縮率を示したグラフである。
【図４】ＬＤＩの投影を示した図面であり、（ａ）暗いセル（ボクセル）は１に対応し、白いセルは０に対応すし、（ｂ）（ｘ、ｄｅｐｔｈ）平面での２Ｄ切片である。
【図５】色相データの再配列後の“天使”モデルの色相成分を示した図面である。
【図６】ノード発生確率の直交不変を示した図面であり、（ａ）元来現在及び親ノードであり、（ｂ）現在及び親ノード（ｙ軸を中心に９０゜回転）である。
【図７】‘天使’、‘イナゴ’及び‘モルトン’における最適ＰＰＭ基盤方法に対する形態圧縮を示した図面である。
【図８】‘天使’、‘イナゴ’及び‘モルトン’における最適ＰＰＭ基盤方法に対する形態圧縮を示した図面である。
【図９】‘天使’、‘イナゴ’及び‘モルトン’における最適ＰＰＭ基盤方法に対する形態圧縮を示した図面である。
【図１０】‘天使’ポイントテクスチャーモデルの色相フィールドを２Ｄイメージに再配列する２つの方式を示した図面である。
【図１１】無損失形態圧縮及び損失色相圧縮の例を示した図面であり、（ａ）は元来の‘天使’モデル、（ｂ）は圧縮された‘天使’モデル、（ｃ）は元来の‘モルトン２５６’モデル、（ｄ）圧縮された‘モルトン２５６’モデルである。
【図１２】‘天使’モデルのＢＶＯモデルとＴＢＶＯモデルとを示した図面である。
【図１３】ＴＢＶＯでの付加カメラにより撮影された付加イメージを示した図面であり、（ａ）はカメラインデックスイメージ、（ｂ）は最初の付加イメージ、（ｃ）は２番目の付加イメージである。
【図１４】ＴＢＶＯストリームを記述する一例を示した図面（（ａ）ＴＢＶＯツリー構造、（ｂ）ＢＶＯノードとカメラインデックスでのオクツリー横断順序、（ｃ）結果的なＴＢＶＯストリーム）である。
【図１５】‘天使’、‘モルトン’、‘椰子５１２’及び‘ロボット５１２’モデルの圧縮結果を示した図面である。
【図１６】除去された天使及びモルトンモデルのイメージを示した図面である。
【図１７】‘天使’、‘モルトン’、‘椰子５１２’及び‘ロボット５１２’モデルの圧縮結果を示した図面である。
【図１８】
【図１９】‘天使’、‘モルトン’、‘椰子５１２’及び‘ロボット５１２’モデルの圧縮結果を示した図面である。
【図２０】色相イメージと深さマップの一例を示した図面である。
【図２１】階層的な深さイメージの一例を示した図面（（ａ）客体の投影、（ｂ）階層的なピクセル）である。
【図２２】中心に見られるモデルを描写するために使われる６個のシンプルテクスチャー（色相イメージと深さマップの対）よりなるＢＴの一例を示した図面である。
【図２３】ＧＢＴの一例を示した図面（（ａ）‘椰子’モデルに対するカメラの位置、（ｂ）同じモデルに対する参照イメージ平面）である。
【図２４】２Ｄで描写されたオクツリー表現の一例を示した図面（（ａ）‘点雲’、（ｂ）対応する中間マップ）である。
【図２５】ＴＢＶＯビットストリームを記述するための擬似コードである。
【図２６】ＤＩＢＲノードの定義を示す図面である。
【図２７】深さイメージに対する視覚体積モデルを示した図面（（ａ）遠近視点、（ｂ）直交視点）である。
【図２８】シンプルテクスチャーのＯｐｅｎＧＬに基づくレンダリングの擬似コードである。
【図２９】シンプルテクスチャーで参照イメージの圧縮の一例を示した図面（（ａ）元来の参照イメージ、（ｂ）ＪＰＥＧフォーマットで修正された参照イメージ）である。
【図３０】相異なるフォーマットの“モルトン”モデルのレンダリング結果の一例を示した図面（（ａ）元来の多角形フォーマット、（ｂ）深さイメージフォーマット、（ｃ）オクツリーイメージフォーマット）である。
【図３１】レンダリングの一例を示した図面（（ａ）深さイメージフォーマットでスキャニングされた“膽星台”モデル、（ｂ）オクツリーイメージフォーマットでスキャニングされた同じモデル）である。
【図３２】“椰子”モデルのレンダリングの一例を示した図面（（ａ）元来の多角形フォーマット、（ｂ）深さイメージフォーマットの同じモデル）である。
【図３３】オクツリーイメージの“ドラゴン５１２”アニメーションからのフレームを示すレンダリングの一例を示した図面である。
【図３４】ポイントテクスチャーフォーマットの“天使４１２”モデルのレンダリングの一例を示した図面である。
【図３５】（ａ）（ｂ）は、各々シンプルテクスチャーノード及びポイントテクスチャーノードを有する深さイメージノードにより客体を表現する時の各ノードの対応関係を示した図面である。
【図３６】オクツリーイメージノードにより客体を表現する時の該当オクツリーイメージノードの構成を示した図面である。

Claims (19)

1. それぞれのピクセルに対する色相を含む色相イメージが記録されるテクスチャーフィールドと、
   前記それぞれのピクセルに対する深さ値が記録される深さフィールドとを含むことを特徴とする深さイメージに基づく３次元客体を表現するためのノード構造。
2. 動映像客体を生成するビデオフォーマットの場合に前記深さ情報及び前記色相情報は複数のイメージフレーム列であることを特徴とする請求項１に記載の深さイメージに基づく３次元客体を表現するためのノード構造。
3. イメージ平面の大きさ情報が記録される大きさフィールドと、
   前記イメージ平面を形成するそれぞれのピクセルに対する深さ値の解像度情報が記録される解像度フィールドと、
   前記それぞれのピクセルに対する複数の深さ情報が記録される深さフィールドと、
   前記それぞれのピクセルに対する色相情報が記録される色相フィールドとを含むことを特徴とする深さイメージに基づく３次元客体を表現するためのノード構造。
4. 前記深さ情報は、前記イメージ平面に投射された前記ピクセルの数及びそれぞれのピクセルの深さ値が順次に記録された行列であり、
   前記色相情報は、前記投射されたピクセルそれぞれに対する前記深さ値に対応する色相値が順次に記録された行列であることを特徴とする請求項３に記載の深さイメージに基づく３次元客体を表現するためのノード構造。
5. イメージ平面を眺める視点が記録される視点フィールドと、
   前記視点から前記イメージ平面までの視野領域が記録される視野フィールドと、
   前記視点から前記イメージ平面までの投影方法が記録される投影方法フィールドと、
   前記視点から可視領域の近い境界平面までの距離及び前記視点から遠い境界平面までの距離が記録される距離フィールドと、
   色相イメージが記録されるテクスチャーフィールドとを含むことを特徴とする深さイメージに基づく３次元客体を表現するためのノード構造。
6. 前記視点フィールドは、
   前記視点の位置が記録される位置フィールドと、
   前記視点の方向が記録される方向フィールドとを含み、
   前記位置は前記イメージ平面が存在する座標系の原点に対する相対的な位置であり、前記方向は所定の基準方向に対する相対的な回転量であることを特徴とする請求項５に記載の深さイメージに基づく３次元客体を表現するためのノード構造。
7. 前記投影方法は、前記視野領域が幅と高さとで表示される直交投影方法及び前記視野領域が水平角と垂直角とで表示される遠近投影方法を含むことを特徴とする請求項５に記載の深さイメージに基づく３次元客体を表現するためのノード構造。
8. 前記直交投影方法が選択された場合に前記視野領域の幅と高さとは各々前記イメージ平面の幅と高さであり、
   前記遠近投影方法が選択された場合に、前記視野領域の幅と高さとは各々前記視点から前記イメージ平面に至る視線により形成される水平角及び垂直角であることを特徴とする請求項７に記載の深さイメージに基づく３次元客体を表現するためのノード構造。
9. 動映像客体を生成するビデオフォーマットの場合に、前記深さ情報及び前記色相情報は複数のイメージフレーム列であることを特徴とする請求項５に記載の深さイメージに基づく３次元客体を表現するためのノード構造。
10. 前記色相イメージは、それぞれのピクセルに対する色相を含む平面イメージ及び前記それぞれのピクセルに対する深さ値で構成されるシンプルテクスチャーであることを特徴とする請求項５に記載の深さイメージに基づく３次元客体を表現するためのノード構造。
11. 前記色相イメージは、前記色相イメージの大きさ情報、前記色相イメージに対する深さ解像度情報、前記色相イメージを形成するそれぞれのピクセルに対する複数の深さ情報、及び前記それぞれのピクセルに対する色相情報で構成されるポイントテクスチャーであることを特徴とする請求項５に記載の深さイメージに基づく３次元客体を表現するためのノード構造。
12. 前記深さ情報は、前記イメージ平面に投射された前記ピクセルの数及びそれぞれのピクセルの深さ値が順次に記録された行列であり、
    前記色相情報は、前記投射されたピクセルそれぞれに対する前記深さ値に対応する色相値が順次に記録された行列であることを特徴とする請求項１１に記載の深さイメージに基づく３次元客体を表現するためのノード構造。
13. 客体を含む閉じられたキューブの側面に接することができるオクツリーリーフの最大値が記録される解像度フィールドと、
    前記オクツリーの内部ノードの構造が記録されるオクツリーフィールドと、
    前記内部ノードに対応する参照イメージのインデックスが記録されるインデックスフィールドと、
    前記参照イメージが記録されるイメージフィールドとを含むことを特徴とする深さイメージに基づく３次元客体を表現するためのノード構造。
14. 前記内部ノードそれぞれはバイトで表現され、前記内部ノードに属する子ノードに対する下位子ノードの存在如何は前記バイトを構成するビット列に記録されるノード情報により表現されることを特徴とする請求項１３に記載の深さイメージに基づく３次元客体を表現するためのノード構造。
15. 前記参照イメージは、視点情報及び前記視点情報に対応する色相イメージで構成される深さイメージノードであることを特徴とする請求項１３に記載の深さイメージに基づく３次元客体を表現するためのノード構造。
16. 前記視点情報は、
    イメージ平面を眺める視点が記録される視点フィールドと、
    前記視点から前記イメージ平面までの視野領域が記録される視野フィールドと、
    前記視点から前記イメージ平面までの投影方法が記録される投影方法フィールドとを含むことを特徴とする請求項１５に記載の深さイメージに基づく３次元客体を表現するためのノード構造。
17. 前記視点フィールドは、
    前記視点の位置が記録される位置フィールドと、
    前記視点の方向が記録される方向フィールドとを含み、
    前記位置は、前記イメージ平面が存在する座標系の原点に対する相対的な位置であり、前記方向は、所定の基準方向に対する相対的な回転量であることを特徴とする請求項１６に記載の深さイメージに基づく３次元客体を表現するためのノード構造。
18. 前記投影方法は前記視野領域が幅と高さとで表示される直交投影方法であり、
    前記視野領域の幅と高さとは各々前記イメージ平面の幅と高さであることを特徴とする請求項１６に記載の深さイメージに基づく３次元客体を表現するためのノード構造。
19. 前記色相イメージは、それぞれのピクセルに対する色相を含む平面イメージ及び前記それぞれのピクセルに対する深さ値で構成されるシンプルテクスチャーであることを特徴とする請求項１５に記載の深さイメージに基づく３次元客体を表現するためのノード構造。

Images