【課題】 深さイメージに基づく３次元客体の表現装置及び方法を提供する。
【解決方法】 客体を含むオクツリーを所定個数の下位キューブに分割し、客体に対する形態情報を生成する形態情報生成部２３３０と、キューブ各々に対して参照イメージを決定する参照イメージ決定部２３２０と、参照イメージのインデックス情報を生成するインデックス生成部２３４０と、形態情報、インデックス情報及び参照イメージで構成されるオクツリーノードを生成するノード生成部２３５０と、オクツリーノードをエンコーディングしてビットストリームを出力するエンコーディング部２３６０とを含み、形態情報生成部２３３０は、分割された下位キューブの大きさが所定の基準大きさより小さくなるまで下位キューブへの分割過程を反復的に実施する。

【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一群の深さイメージに基づく表現（Ｄｅｐｔｈ Ｉｍａｇｅ−Ｂａｓｅｄ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ：ＤＩＢＲ）３次元客体表現装置及び方法に係り、より詳細には、ＭＰＥＧ−４動映像フレームワーク拡張（ＭＰＥＧ−４ Ａｎｉｍａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ ｅＸｔｅｎｔｉｏｎ：ＡＦＸ）に採用されてきたＤＩＢＲという一群のコンピュータグラフィック及びアニメーションのための３次元客体の表現装置、３次元客体の表現方法およびその記録媒体に関する。
【背景技術】
【０００２】
３次元（３−Ｄｉｍｅｎｓｉｏｎａｌ：３Ｄ）グラフィックに関する研究の初期から研究者等の窮極的な目標は実際イメージのような現実的なグラフィック画面を生成することである。したがって、伝統的なレンダリング技術分野で多角形モデル（Ｐｏｌｙｇｏｎａｌ ｍｏｄｅｌ）を利用する研究が実行され、その結果として非常に現実的な３Ｄ環境を提供するのに十分な程度にモデリング及びレンダリング技術が開発されてきた。しかし、複雑なモデルを生成するための過程は専門家の多くの努力と時間を必要とする。また、現実的で複雑な環境は莫大な量の情報を必要とし、貯蔵及び伝送において低効率を招く。
【０００３】
現在、コンピュータグラフィックにおいて３Ｄ客体表現の主要な方法は多角形モデルである。任意の形状を色相多角形の集合、すなわち、三角形により概略的に表現できる。ソフトウェアアルゴリズムの飛躍的な進歩及びグラフィックハードウェアの発展により、複雑な客体及び場面をリアルタイムでかなり現実的な静止及び動映像多角形モデルに視覚化できる。
【０００４】
しかし、他の３Ｄ表現に関する研究がここ数年間非常に活発に進んできた。現実世界の客体に対する多角形モデルを構成し難いだけでなくレンダリングの複雑性及び写真のように現実的な場面を生成するのにおいて品質が落ちるということが、このような研究が進んできた主要な理由である。
【０００５】
要求されるアプリケーションは莫大な量の多角形を必要とする。例えば、人体の詳細なモデルは数百万個の三角形を含み、これを扱うことは容易ではない。たとえ、３次元レーザースキャナーのように３次元測定技術分野での最近の進歩により収容可能なエラーを有する稠密なデータを得られるが、全体客体に対して連続的に完璧な多角形モデルを得ることは依然としてコストが多くかかって非常にむずかしい。一方、写真のような現実的な品質を得るための多角形レンダリングアルゴリズムは演算において複雑なのでリアルタイムレンダリングが不可能である。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明が解決しようとする技術的課題は、ＭＰＥＧ−４ ＡＦＸに採用されてきたＤＩＢＲと呼ばれる、一群のコンピュータグラフィックとアニメーションのための３次元表現のための深さイメージに基づくノード構造を提供するのにある。
【０００７】
本発明が解決しようとする他の技術的課題は、ＭＰＥＧ−４ ＡＦＸに採用されてきたＤＩＢＲという一群のコンピュータグラフィック及びアニメーションのための３次元表現方法をコンピュータで実行させるためのプログラムを記録したコンピュータで読み出すことができる記録媒体を提供するのにある。
【課題を解決するための手段】
【０００８】
前記技術的課題を達成するため、本発明による深さイメージに基づく３次元客体表現装置は、客体を構成するオクツリーのうち前記客体を含むオクツリーを所定個数の下位キューブに分割し、分割された下位キューブを子ノードと規定して前記客体に対する形態情報を生成する形態情報生成部と、前記キューブ各々に対して色相イメージを含む参照イメージを決定する参照イメージ決定部と、前記形態情報に対応する前記参照イメージのインデックス情報を生成するインデックス生成部と、前記形態情報、前記インデックス情報及び前記参照イメージで構成されるオクツリーノードを生成するノード生成部と、前記オクツリーノードをエンコーディングしてビットストリームを出力するエンコーディング部とを含み、前記形態情報生成部は、前記分割された下位キューブの大きさが所定の基準大きさより小さくなるまで前記下位キューブへの分割過程を反復的に実施する。
【０００９】
さらに他の本発明による深さイメージに基づく３次元客体表現装置は、ビットストリームを入力される入力部と、前記ビットストリームからオクツリーノードを抽出する第１抽出部と、前記オクツリーノードをデコーディングするデコーディング部と、前記デコーディングされたオクツリーノードからオクツリーを構成する複数のキューブに対する形態情報及び参照イメージを抽出する第２抽出部と、前記抽出された形態情報に基づいて前記抽出された参照イメージを組合わせて客体を表現する客体表現部とを含む。
【００１０】
前記他の技術的な課題を達成するための、本発明による深さイメージに基づく３次元客体表現方法は、客体を構成するオクツリーのうち前記客体を含むオクツリーを所定個数の下位キューブに分割し、分割された下位キューブを子ノードと規定して前記客体に対する形態情報を生成する段階と、前記キューブ各々に対して色相イメージを含む参照イメージを決定する段階と、前記形態情報に対応する前記参照イメージのインデックス情報を生成する段階と、前記形態情報、前記インデックス情報及び前記参照イメージで構成されるオクツリーノードを生成する段階と、前記オクツリーノードをビットストリームにエンコーディングする段階とを含み、前記形態情報生成部は、前記分割された下位キューブの大きさが所定の基準大きさより小さくなるまで前記下位キューブへの分割過程を反復的に実施する。
【００１１】
さらに他の本発明による深さイメージに基づく３次元客体表現方法は、ビットストリームを入力される段階と、前記ビットストリームからオクツリーノードを抽出する段階と、前記オクツリーノードをデコーディングする段階と、前記デコーディングされたオクツリーノードからオクツリーを構成する複数のキューブに対する形態情報及び参照イメージを抽出する段階と、前記抽出された形態情報に基づいて前記抽出された参照イメージを組合わせて客体を表現する段階とを含む。
【００１２】
本発明によれば、イメージ基盤モデルに対するレンダリング時間が多角形の場合のように形態的な複雑性に比例せず、一般的に参照及び出力イメージに存在するピクセルの数に比例する。さらに、イメージ基盤表現が現実世界の客体と場面に適用されれば数百万個の多角形を使用せずに低コストで自然的な場面の写真のような現実的なレンダリングが可能になる。
【発明の効果】
【００１３】
本発明によれば、このようなイメージ基盤表現は、色相３次元客体の完全な情報を２次元配列の集合−イメージ処理及び圧縮の公知の方法に直ちに適用できる単純で規則的な構造−でエンコーディングするので、アルゴリズムが簡単で多くの部分がハードウェアにより支援される。その上、イメージ基盤モデルに対するレンダリング時間は多角形の場合のように形態的な複雑性に比例せず、一般的に参照及び出力イメージに存在するピクセルの数に比例する。さらに、イメージ基盤表現が現実世界の客体と場面に適用されれば数百万個の多角形及び高コストの使用なしに自然な場面の写真のような現実的なレンダリングが可能になる。
【図面の簡単な説明】
【００１４】
【図１】現在の参照ソフトウェアに統合されたＩＢＲの例を示した図面である。
【図２】オクツリーの構造及び子の順序を示した図面である。
【図３】オクツリー圧縮率を示したグラフである。
【図４】ＬＤＩの投影を示した図面であり、（ａ）暗いセル（ボクセル）は１に対応し、白いセルは０に対応すし、（ｂ）（ｘ、ｄｅｐｔｈ）平面での２Ｄ切片である。
【図５】色相データの再配列後の“天使”モデルの色相成分を示した図面である。
【図６】ノード発生確率の直交不変を示した図面であり、（ａ）元来現在及び親ノードであり、（ｂ）現在及び親ノード（ｙ軸を中心に９０゜回転）である。
【図７】‘天使’、‘イナゴ’及び‘モルトン’における最適ＰＰＭ基盤方法に対する形態圧縮を示した図面である。
【図８】‘天使’、‘イナゴ’及び‘モルトン’における最適ＰＰＭ基盤方法に対する形態圧縮を示した図面である。
【図９】‘天使’、‘イナゴ’及び‘モルトン’における最適ＰＰＭ基盤方法に対する形態圧縮を示した図面である。
【図１０】‘天使’ポイントテクスチャーモデルの色相フィールドを２Ｄイメージに再配列する２つの方式を示した図面である。
【図１１】無損失形態圧縮及び損失色相圧縮の例を示した図面であり、（ａ）は元来の‘天使’モデル、（ｂ）は圧縮された‘天使’モデル、（ｃ）は元来の‘モルトン２５６’モデル、（ｄ）圧縮された‘モルトン２５６’モデルである。
【図１２】‘天使’モデルのＢＶＯモデルとＴＢＶＯモデルとを示した図面である。
【図１３】ＴＢＶＯでの付加カメラにより撮影された付加イメージを示した図面であり、（ａ）はカメラインデックスイメージ、（ｂ）は最初の付加イメージ、（ｃ）は２番目の付加イメージである。
【図１４】ＴＢＶＯストリームを記述する一例を示した図面（（ａ）ＴＢＶＯツリー構造、（ｂ）ＢＶＯノードとカメラインデックスでのオクツリー横断順序、（ｃ）結果的なＴＢＶＯストリーム）である。
【図１５】‘天使’モデルの圧縮結果を示した図面である。
【図１６】除去された天使及びモルトンモデルのイメージを示した図面である。
【図１７】‘モルトン’モデルの圧縮結果を示した図面である。
【図１８】‘椰子５１２’モデルの圧縮結果を示した図面である。
【図１９】‘ロボット５１２’モデルの圧縮結果を示した図面である。
【図２０】色相イメージと深さマップの一例を示した図面である。
【図２１】階層的な深さイメージの一例を示した図面（（ａ）客体の投影、（ｂ）階層的なピクセル）である。
【図２２】中心に見られるモデルを描写するために使われる６個のシンプルテクスチャー（色相イメージと深さマップの対）よりなるＢＴの一例を示した図面である。
【図２３】ＧＢＴの一例を示した図面（（ａ）‘椰子’モデルに対するカメラの位置、（ｂ）同じモデルに対する参照イメージ平面）である。
【図２４】２Ｄで描写されたオクツリー表現の一例を示した図面（（ａ）‘点雲’、（ｂ）対応する中間マップ）である。
【図２５】ＴＢＶＯビットストリームを記述するための擬似コードである。
【図２６】ＤＩＢＲノードの定義を示す図面である。
【図２７】深さイメージに対する視覚体積モデルを示した図面（（ａ）遠近視点、（ｂ）直交視点）である。
【図２８】シンプルテクスチャーのＯｐｅｎＧＬに基づくレンダリングの擬似コードである。
【図２９】シンプルテクスチャーで参照イメージの圧縮の一例を示した図面（（ａ）元来の参照イメージ、（ｂ）ＪＰＥＧフォーマットで修正された参照イメージ）である。
【図３０】相異なるフォーマットの“モルトン”モデルのレンダリング結果の一例を示した図面（（ａ）元来の多角形フォーマット、（ｂ）深さイメージフォーマット、（ｃ）オクツリーイメージフォーマット）である。
【図３１】レンダリングの一例を示した図面（（ａ）深さイメージフォーマットでスキャニングされた“膽星台”モデル、（ｂ）オクツリーイメージフォーマットでスキャニングされた同じモデル）である。
【図３２】“椰子”モデルのレンダリングの一例を示した図面（（ａ）元来の多角形フォーマット、（ｂ）深さイメージフォーマットの同じモデル）である。
【図３３】オクツリーイメージの“ドラゴン５１２”アニメーションからのフレームを示すレンダリングの一例を示した図面である。
【図３４】ポイントテクスチャーフォーマットの“天使４１２”モデルのレンダリングの一例を示した図面である。
【図３５】本発明によるシンプルテクスチャーによる深さイメージに基づく３次元客体表現装置に関する一実施例の構成を示したブロック図である。
【図３６】前処理部（１８２０）の詳細な構成を示したブロック図である。
【図３７】本発明によるシンプルテクスチャーによる深さイメージに基づく３次元客体表現装置に関する一実施例の遂行過程を示したフローチャートである。
【図３８】本発明によるポイントテクスチャーによる深さイメージに基づく３次元客体表現装置に関する一実施例の構成を示したブロック図である。
【図３９】本発明によるポイントテクスチャーによる深さイメージに基づく３次元客体表現方法に関する一実施例の遂行過程を示したフローチャートである。
【図４０】本発明によるオクツリーによる深さイメージに基づく３次元客体表現装置に関する一実施例の構成を示したブロック図である。
【図４１】前処理部（２３１０）の詳細な構成を示したブロック図である。
【図４２】インデックス生成部（２３４０）の詳細な構成を示したブロック図である。
【図４３】エンコーディング部（２３６０）の詳細な構成を示したブロック図である。
【図４４】第２エンコーディング部（２６３０）の詳細な構成を示したブロック図である。
【図４５】第３エンコーディング部（２６４０）の詳細な構成を示したブロック図である。
【図４６】本発明によるオクツリーによる深さイメージに基づく３次元客体表現方法に関する一実施例の遂行過程を示したブロック図である。
【図４７】参照イメージに関する前処理段階の遂行過程を示したフローチャートである。
【図４８】インデックス生成段階の遂行過程を示したフローチャートである。
【図４９】エンコーディング段階の遂行過程を示したフローチャートである。
【図５０】第２エンコーディング段階の遂行過程を示したフローチャートである。
【図５１】第３エンコーディング段階の遂行過程を示したフローチャートである。
【図５２】本発明によるオクツリーによる深さイメージに基づく３次元客体表現方法に関する他の実施例の遂行過程を示したフローチャートである。
【図５３】本発明によるオクツリーによる深さイメージに基づく３次元客体表現装置に関する他の実施例の構成を示したブロック図である。
【図５４】本発明によるオクツリーによる深さイメージに基づく３次元客体表現方法に関する他の実施例の遂行過程を示したフローチャートである。
【発明を実施するための形態】
【００１５】
本出願は米国商標特許庁に仮出願された４件の出願を基礎出願として優先権を主張して出願される。以下、本出願の優先権主張の基礎になった４件の仮出願書に記載された発明を記述する。
【００１６】
Ｉ．ＩＳＯ／ＩＥＣ ＪＴＣ １／ＳＣ ２９ＷＧ １１ 動映像及び音響のコーディング
１．序論
本文書でイメージに基づくレンダリング（ＡＦＸ Ａ８．３）に対するコア実験結果が報告される。このコア実験は、深さ情報を有するテクスチャーを利用するイメージに基づくレンダリング技術に関する。また、１０月にあったＡＦＸ ａｄｈｏｃグループ会議期間中の５７次ＭＰＥＧ会議及び議論以後、実験に基づいてノード定義に加えられたいくつかの変更が提示される。
【００１７】
２．実験結果
２．１．テストモデル
●静止客体に対して
■シンプルテクスチャーを有する深さイメージノード
◆犬
◆チラノサウルスレックス（約２０個のカメラを使用した深さイメージ）
◆テラスク（モンスター）（約２０個のカメラを使用した深さイメージ）
◆膽星台（約２０個のカメラを使用した深さイメージ）
◆椰子（約２０個のカメラを使用した深さイメージ）
■階層テクスチャーを有する深さイメージノード
◆天使
■ポイントテクスチャーを有する深さイメージノード
◆天使
■オクツリーイメージノード
◆生物
●動的客体に対して
■シンプルテクスチャーを有する深さイメージノード
◆竜
◆背景での竜
■階層テクスチャーを有する深さイメージノード
◆提供されない
■オクツリーイメージノード
◆ロボット
◆背景での竜
●今後より多くのデータ（スキャニングまたはモデリングされた）が提供されるであろう。
【００１８】
２．２．テスト結果
●シドニーで提案されたあらゆるノードはｂｌａｘｘｕｎ ｃｏｎｔａｃｔ ４．３参照ソフトウェアに統合されている。しかし、まだｃｖｓサーバーにソースが更新されていない。
●イメージに基づくレンダリング（Ｉｍａｇｅ Ｂａｓｅｄ Ｒｅｎｄｅｒｉｎｇ：ＩＢＲ）に対する動的フォーマットはそれぞれの動映像ファイルから同じキーフレームに存在するイメージが同時に与えられるように複数の動映像ファイルの間に同調される必要がある。しかし、現在の参照ソフトウェアはＭＰＥＧシステムではできるだけこのような同調能力を支援しない。したがって、現在動的フォーマットはあらゆる動的データが既にファイルに存在すると仮定することによって表面化される。暫定的にＡＶＩフォーマットの動映像ファイルがそれぞれの動的テクスチャーに使われる。
●階層文脈に対するいくつかの実験を実行した後、階層テクスチャーノードは効率的でないことが明らかになった。このようなノードは階層深さイメージに対して提案された。しかし、それを支援できるポイントテクスチャーノードがまた存在する。したがって、ノード定義で階層テクスチャーノードを削除することを提案する。
●図１は現在参照ソフトウェアに統合されたＩＢＲの例である。
【００１９】
３．ＩＢＲノード定義に対するアップデート
ＩＢＲ提案に対するシドニー会議の結論はイメージ及びカメラ情報を含むＩＢＲストリームを有さねばならず、ＩＢＲノードはそれへのリンク（ｕｒｌ）を有すればよいということである。しかし、Ｒｅｎｎｅｓで開いたａｄｈｏｇグループ会議でのＩＢＲに対する議論結果は、ＩＢＲノードとストリームいずれもイメージ及びカメラ情報を有さねばならないということである。したがって、ＩＢＲノードに対するノード定義は次のようにアップデートされる。ＩＢＲストリームの必要性はｕｒｌフィールドを説明する章で説明される。
【００２０】
【表１】

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

【００３０】
シンプルテクスチャーノードは単層のＩＢＲテクスチャーを定義する。
テクスチャー（ｔｅｘｔｕｒｅ）フィールドはそれぞれのピクセルに対する色相を含む平面イメージを特定する。これは多様な形態のテクスチャーノード（イメージテクスチャー、動映像テクスチャーまたはピクセルテクスチャー）のうち一つである。深さノードがＮＵＬＬであるか、深さフィールドが特定されていなければ、テクスチャーフィールドでアルファチャンネルは深さマップとして利用される。
【００３１】
【表３】

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

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

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

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

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

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

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

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

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

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

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

【０１２４】
【表１３】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０２１０】
【表２７】

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

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

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



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

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

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

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

【０２７８】
Ｓ（Ｐ）をＰのあらゆるエントリの和とすれば、計算コーダ（ここでは領域コーダ）に印加されるＮの確率がＰ（Ｎ）／Ｓ（Ｐ）として計算される。Ｓ（Ｐ）が臨界値２１６に到達すればすぐあらゆるエントリが再正規化される。Ｐでゼロ値を発生させないために他のエントリは２で割る一方、１に該当するエントリは変わらずに残る。
【０２７９】
それぞれのボクセルに対するイメージインデックスを決定するシンボルストリームは自体の確率テーブルを利用して圧縮される。上で使われた用語でそれぞれのボクセルに対するイメージインデックスを決定するシンボルストリームは一つの文脈である。ＰＴエントリはオクツリーノードに対するエントリより大きい増分で更新される。これにより確率が含まれたシンボル頻度の大きい変動に適用できる。残りはノードシンボルコーディングと差がない。
【０２８０】
ＤＩＢＲフォーマットに対するレンダリング方法はＡＦＸ標準の一部ではないが、ＤＩＢＲ客体レンダリングの簡略性、速度及び品質を得るために使われる概念は説明する必要がある。本レンダリング方法は‘レンダリング原形’として使われる小さくて扁平な色相パッチのスプラットに基づく。下に略述された２つの接近法は深さイメージとオクツリーイメージとの２つの相異なる表現に適用される。レンダリング速度を向上させるためのスプラッティングのためにＯｐｅｎＧＬ関数が採用される。それにも拘わらず、ソフトウェアレンダリングも可能であり、これにより深さイメージまたはオクツリーイメージの単純な構造を利用して計算を最適化できる。
【０２８１】
深さイメージ客体をレンダリングするために使用する方法は極めて簡単である。しかし、それはＯｐｅｎＧＬ関数に依存してハードウェア加速器によりより速く動作することを言及する必要がある。この方法で、深さを有するあらゆるピクセルはレンダリングされる単純テクスチャー及び点テクスチャーから３Ｄ点に変換され、その後、このような点で小さなポリゴン（スプラット）の位置を決定してＯｐｅｎＧＬのレンダリング関数を適用する。単純テクスチャーの場合に対するこのような過程の擬似コードが図２８に図示されている。点テクスチャーの場合は正確に同じ過程に扱われる。
【０２８２】
スプラットのサイズは点と観察者との間の距離に適するように採択されねばならない。次のような簡単な方法が使われた。まず、与えられた３Ｄ客体の閉じられたキューブを経た均一格子に細分する。スプラットのサイズは格子各々のセルに対して計算され、この値はセル内の点に対して使われる。計算は次のように実施される。
【０２８３】
【数１２】

【０２８４】
このような方法はより正確な半径計算、より複雑なスプラット、アンチエーリアシングなどにより明確に改善される。しかし、このような簡単な方法も良好な見解品質を提供する。
【０２８５】
同じ方法がオクツリーイメージのレンダリングに適用される。ここでより粗いレベルの一つでオクツリーノードがスプラットサイズの前述した計算で使われる。しかし、オクツリーイメージに対して色相情報はボクセル集合より先にマッピングされねばならない。それぞれのボクセルは対応する参照イメージインデックスを有しているので、これは非常に容易に実施される。参照イメージでピクセル位置もオクツリーストリームのパーシング過程中に把握される。オクツリーイメージボクセルの色相が決定されればすぐにスプラットサイズが算定され、ＯｐｅｎＧＬに基づいたレンダリングが前述したように使われる。
【０２８６】
ＤＩＢＲフォーマットがいくつかの３Ｄモデルに対して実施されてテストされた。モデルのうち一つ（“膽星台”）は実際に物理的な客体をスキャニングして得られ（Ｃｙｂｅｒｗａｒｅ社のカラー３Ｄスキャナーが使われた）、ほかのものは３ＤＳ−ＭＡＸデモパッケージから変換された。テストはＯｐｅｎＧＬ加速器を装着した１．８ＧＨｚ インテル（登録商標）ペンティアム（登録商標）ＩＶ上で実施された。
【０２８７】
多角形からＤＩＢＲフォーマットに変換する方法は後述し、その後、モデリング、表現、そして相異なるＤＩＢＲフォーマットの圧縮結果を記述する。大部分のデータは深さイメージ及びオクツリーイメージに関するものである。このようなフォーマットは動映像バージョンを有して効果的に圧縮されうる。提示されるモデルはいずれも直交カメラで構成された。これは直交カメラが一般的に‘小さな’客体を表現するのに適切な方法であるからである。距離がある環境の経済的なＤＩＢＲ表現のために遠近カメラが大部分使われる。
【０２８８】
ＤＩＢＲモデル生成は、十分な数のシンプルテクスチャーを得ることから始まる。現実世界の客体に対してこのようなデータがデジタルカメラとスキャニング装置から得られる一方、多角形客体に対してシンプルテクスチャーが計算される。次の段階は使用しようとするＤＩＢＲフォーマットに依存する。
【０２８９】
深さイメージは簡単に得られたシンプルテクスチャーの集合である。たとえ深さマップを圧縮された形式で貯蔵できたとしても、形態において小さな歪曲がたびたびかなり目立つので無損失圧縮だけ許容される。
【０２９０】
参照イメージは損失圧縮形式で貯蔵できるが、この場合に前処理が必要である。ＪＰＥＧ損失圧縮のような公知の方法を使用することは一般的に受容されうるが、特に、背景色相が‘客体’に散る地点である、客体と参照イメージの背景との境界による境界面の不良は生成された３次元客体画面でより目立つようになる。このような問題の解決方案は、ブロックの平均色相と強度の急速な減衰を利用して境界ブロックでイメージを背景に拡張した後、ＪＰＥＧ圧縮を適用することである。このような効果は、背景ピクセルはレンダリングに使われないため、歪曲を歪曲が影響を及ぼさない背景に‘スキージング’することと似ている。損失圧縮された参照イメージの内部境界もやはり不良をもたらすが、これは一般的にあまり目につかない。
【０２９１】
オクツリーイメージモデルを生成するために中間点基盤表現（Ｐｏｉｎｔ Ｂａｓｅｄ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ：ＰＢＲ）を使用する。ＰＢＲを構成する点の集合は、参照イメージに存在するピクセルを対応する深さマップに規定された距離により遷移することによって得られた色相を有する点の集合である。元のシンプルテクスチャーは結果的なＰＢＲが十分に正確な客体表面に対する推定を提供するように構成される。その後、ＰＢＲは図５に示したようなオクツリーイメージに変換され、このようなフォーマットにより賦課された制限を満足する新しい完全な参照イメージ集合を生成するために使われる。同時に、オクツリーボクセルに対する参照イメージインデックスを示す付加的なデータ構造ボクセルイメージインデックスが生成される。この時、参照イメージは損失フォーマットで貯蔵されねばならず、これらはまず以前の下位章で説明したように前処理される。さらに、ＴＢＶＯ構造は明白にボクセルイメージインデックスの体積をよりもっと縮めるので、重畳されるピクセルは捨てられ、これはボクセルイメージインデックスの体積をさらに縮める。元の参照イメージとＪＰＥＧフォーマットで処理された参照イメージの例が図２９に図示されている。
【０２９２】
オクツリーイメージに対する損失圧縮による品質低下は無視できるほどである。しかし、時に深さイメージ客体に対しては依然として目につく。
【０２９３】
ポイントテクスチャーモデルは、前述したように参照平面への客体投影を利用して構成される。もし、これにより十分なサンプルが生成されていなければ（これは投影ベクターにほとんど垂直の表面部分に対する場合でありうる）、付加的なシンプルテクスチャーがより多くのサンプルを提供するために構成される。得られた点の集合はその後にポイントテクスチャー構造で再構成される。
【０２９４】
いくつかの多角形モデルのデータサイズとそれらのＤＩＢＲバージョンのサイズとの比較が表３２に記載されている。モデル名称の数字は彼らの参照イメージの解像度（ピクセル単位）を意味する。表３２は静的なＤＩＢＲモデル圧縮に対する比較表であり、モデルのサイズはキロバイト単位である。
【０２９５】
【表３１】

【０２９６】
参照イメージは高品質ＪＰＥＧで貯蔵される一方、深さイメージで深さマップはＰＮＧフォーマットで貯蔵される。表３２のデータは深さイメージモデルのサイズが得られた多角形モデルのサイズより常に小さいことではないといういことを示す。しかし、オクツリーイメージにより提供された圧縮は大体はるかに大きい。これは深さマップを一つの効率的に圧縮されたオクツリーデータ構造に統合した結果であるだけでなく、参照イメージから冗長ピクセルを除去する精巧な前処理の結果である。一方、深さイメージ構造は‘椰子’のような複雑な客体を難しい前処理なしに表現するための簡単で汎用的な手段を提供する。
【０２９７】
表３３はオクツリーイメージの特定データを示し、このようなフォーマットに対して開発された圧縮効率の概念を説明する。表のエントリは、オクツリーとボクセルイメージインデックス成分を構成するモデルの圧縮された部分と圧縮されていない部分とのデータサイズである。このような部分の減少は２から２．５倍まで変わる。表３３で“椰子”モデルは表３２での“椰子”モデルと同じものではない（次の下位章の図面参照）。表３３には、オクツリーイメージフォーマットでのオクツリーとボクセルイメージインデックスフィールドとの比較結果が記載されている。また、ファイルサイズはキロバイト単位で四捨五入した。
【０２９８】
【表３２】

【０２９９】
レンダリング速度に関するデータを提示する。“椰子５１２”の深さイメージのレンダリング速度は約２ｆｐｓ（ｆｒａｍｅ ｐｅｒ ｓｅｃｏｎｄ）である（２１個の単純テクスチャーであることに注目）。大きさが５１２である参照イメージを有してテストされた他の静的モデルは５〜６ｆｐｓでレンダリングされる。レンダリング速度は場面の複雑度に従属的ではなく参照イメージの数と解像度に大部分従属的であることに注目せねばならない。これは多角形表現に対する重要な長所であり、特に動映像の場合に一層そうである。動映像オクツリーイメージの“ドラゴン５１２”は秒当たり２４フレームで視覚化される。圧縮結果は次の通りである。
【０３００】
−オクツリーとボクセルイメージインデックス成分の圧縮されたサイズ：９１０ＫＢ（各々６９６ＫＢ及び２１４ＫＢ）
−圧縮されたＡＶＩフォーマットの６個の参照ビデオストリーム：１３７０ＫＢ
−全体データ容量：２２８０ＫＢ
【０３０１】
“天使２５６”の深さイメージモデルが図２２に図示されている。図３０〜図３４は、いくつかの他のＤＩＢＲと多角形モデルを示す。図３０は“モルトン”モデルの多角形及び深さイメージの外観を比較した図面である。深さイメージモデルはＪＰＥＧフォーマットの参照イメージを使用し、レンダリングは前述された最も簡単なスプラッティングにより実施されるが、イメージ品質はかなり良好である。図３１は、スキャニングされた“膽星台”モデルの２つの異なるバージョンを比較した図面である。モデルの上段部分にある黒い点は入力データの不良に起因する。図１５は、２１個のシンプルテクスチャーよりなるより複雑な“椰子”モデルを示す。たとえ単純化されたスプラッティングを実行した結果として、一般的にリーフが３ＤＳ−ＭＡＸの元のイメージより広くなったが、良好な品質を示す。
【０３０２】
最後に、図３３は、“ドラゴン５１２”オクツリーイメージアニメーションから３Ｄフレームを示す。図３４は、ポイントテクスチャーフォーマットが優秀な品質のモデルを提供できることを示す。
【０３０３】
以下、図３５ないし図５４を参照して本発明による深さイメージに基づく３次元客体の表現装置及び方法の望ましい実施例について詳細に説明する。
【０３０４】
図３５は、本発明による深さイメージに基づく３次元客体の表現装置に関する一実施例の構成を示すブロック図である。図３５を参照すれば、深さイメージに基づく３次元客体の表現装置１８００は視点情報生成部１８１０、前処理部１８２０、第１イメージ生成部１８３０、第２イメージ生成部１８４０、ノード生成部１８５０、及びエンコーディング部１８６０で構成される。
【０３０５】
視点情報生成部１８１０は少なくとも一つ以上の視点情報を生成する。視点情報は客体に対するイメージ平面を規定する複数のフィールドで構成される。視点情報を構成するフィールドは位置フィールド、方向フィールド、視野フィールド、投影方法フィールド、及び距離フィールドを含む。
【０３０６】
位置フィールド及び方向フィールド各々にはイメージ平面を眺める位置及び方向が記録される。位置フィールドに記録される位置は、イメージが存在する座標系の原点に対する相対的な位置であり、方向フィールドに記録される方向は所定の基準方向に対する相対的な回転量である。視野フィールドには位置からイメージ平面までの視野の幅と高さが記録される。
【０３０７】
投影方法フィールドには、位置及び方向により特定される視点からイメージ平面までの視野が水平角と垂直角で表示される直交投影方法と、視点からイメージ平面までの視野が幅と高さで表示される遠近投影方法のうち選択された投影方法が記録される。直交投影方法が選択された場合に視野フィールドに記録される視野の幅と高さは各々イメージ平面の幅と高さであり、遠近投影方法が選択された場合に視野フィールドに記録される視野の幅と高さは各々視点からイメージ平面に至る視線により形成される水平角及び垂直角である。
【０３０８】
距離フィールドには、位置及び方向により特定される視点から近い境界平面までの距離と遠い境界平面までの距離とが記録される。距離フィールドにより深さ情報の領域が規定される。
【０３０９】
第１イメージ生成部１８３０は、視点情報に対応して客体を構成するそれぞれのピクセル点の色相情報に基づいて色相イメージを生成する。アニメーション客体を生成するビデオフォーマットの場合に深さ情報及び色相情報は複数のイメージフレーム列である。第２イメージ生成部１８４０は視点情報に対応して客体を構成するそれぞれのピクセル点の深さ情報に基づいて深さイメージを生成する。ノード生成部１８５０は視点情報、視点情報に対応する色相イメージ及び深さイメージで構成されたイメージノードを生成する。
【０３１０】
前処理部１８２０は、色相イメージで客体と背景との境界に位置するピクセルを前処理する。図３６には前処理部１８２０の詳細な構成が図示されている。図３６を参照すれば、前処理部１８２０は拡散部１９１０と圧縮部１９２０とを有する。拡散部１９１０は、ブロックの平均色相と急速な強度の減衰を利用してブロックの境界に位置するピクセルの色相を背景に拡散する。圧縮部１９２０は、ブロックに基づいた圧縮を行って歪曲を背景に放出する。エンコーディング部１８６０は生成されたイメージノードをエンコーディングしてビットストリームを出力する。
【０３１１】
図３７は、本発明による深さイメージに基づく３次元客体の表現方法に関する一実施例の遂行過程を示すフローチャートである。図３７を参照すれば、視点情報生成部１８１０は客体を眺める視点に対する視点情報を生成する（Ｓ２０００）。第１イメージ生成部１８３０は、視点情報に対応して客体を構成するそれぞれのピクセル点の色相情報に基づいて色相イメージを生成する（Ｓ２０１０）。第２イメージ生成部１８４０は視点情報に対応して客体を構成するそれぞれのピクセル点の深さ情報に基づいて深さイメージを生成する（Ｓ２０２０）。ノード生成部１８５０は、視点情報、視点情報に対応する深さイメージ及び色相イメージで構成されるイメージノードを生成する（Ｓ２０３０）。
【０３１２】
拡散部１９１０は、ブロックの境界に位置するピクセルの色相を背景に拡散する（Ｓ２０４０）。圧縮部１９２０はブロックに基づいた圧縮により歪曲を背景に放出する（Ｓ２０５０）。エンコーディング部１８６０はイメージノードをエンコーディングしてビットストリームを出力する（Ｓ２０６０）。
【０３１３】
図３５ないし図３７を参照して説明した深さイメージに基づく３次元客体の表現装置及び方法は、シンプルテクスチャー（ＳｉｍｐｌｅＴｅｘｔｕｒｅ）による客体表現に適用され、シンプルテクスチャーの構造は図２６に図示されている。
図３８は、本発明による深さイメージに基づく３次元客体の表現装置に対する他の実施例の構成を示すブロック図である。
【０３１４】
図３８を参照すれば、深さイメージに基づく３次元客体の表現装置２１００はサンプリング部２１１０、視点情報生成部２１２０、平面情報生成部２１３０、深さ情報生成部２１４０、色相情報生成部２１５０、及びノード生成部２１６０で構成される。
【０３１５】
サンプリング部２１１０は、客体を参照平面に投射してイメージ平面に対するサンプルを生成する。イメージ平面に対するサンプルは色相イメージ及び深さイメージで構成されたイメージ対で構成される。
【０３１６】
視点情報生成部２１２０は、客体を眺める視点に関する視点情報を生成する。視点情報は客体に対するイメージ平面を規定する複数のフィールドで構成される。視点情報を構成するフィールドは位置フィールド、方向フィールド、視野フィールド、投影方法フィールド、及び距離フィールドを含む。
【０３１７】
位置及び方向フィールドには各々イメージ平面を眺める位置及び方向が記録される。位置及び方向により視点が特定される。視野フィールドには視点からイメージ平面までの視野の幅と高さが記録される。投影方法フィールドには視点からイメージ平面までの視野が水平角と垂直角で表示される直交投影方法と、視点からイメージ平面までの視野が幅と高さで表示される遠近投影方法とのうち選択された投影方法が記録される。距離フィールドには視点から近い境界平面までの距離と、遠い境界平面までの距離とが記録される。距離フィールドにより深さ情報の領域が規定される。
【０３１８】
平面情報生成部２１３０は、視点情報に対応するイメージ平面に対するサンプルから得られた点集合で構成されるイメージ平面の幅、高さ、及び深さを規定する平面情報を生成する。平面情報は複数のフィールドで構成される。平面情報を構成するフィールドはイメージ平面の幅が記録される第１フィールド、イメージ平面の高さが記録される第２フィールド、及び深さ情報の解像度が記録される深さ解像度フィールドを含む。
【０３１９】
深さ情報生成部２１４０は、イメージ平面の各点に投射された客体のあらゆる投射点に対する深さが記録された深さ情報列を生成する。色相情報生成部２１５０はそれぞれの投射点に対する色相情報列を生成する。深さ情報列には投射点の数とそれぞれの投射点の深さ値とが順次に記録され、色相情報列には投射点各々に対する深さ値に対応する色相値が順次に記録される。
【０３２０】
ノード生成部２１６０はイメージ平面に対応する平面情報、深さ情報列及び色相情報列で構成されるノードを生成する。
【０３２１】
図３９は、本発明による深さイメージに基づく３次元客体の表現方法に関する他の実施例の遂行過程を示すフローチャートである。図３９を参照すれば、視点情報生成部２１２０は客体を眺める視点に関する視点情報を生成する（Ｓ２２００）。平面情報生成部２１３０は視点情報に対応してイメージ平面の幅、高さ、及び深さを規定する平面情報を生成する（Ｓ２２１０）。サンプリング部２１１０は客体をイメージ平面に投影して平面に対するサンプルを生成する（Ｓ２２２０）。Ｓ２２２０段階はイメージ平面に対するより多くのサンプルを提供するために遂行され、イメージ平面が十分な場合には遂行されない。
【０３２２】
深さ情報生成部２１４０は、イメージ平面の各点に投射された客体のあらゆる投射点に対する深さが記録された深さ情報列を生成する（Ｓ２２３０）。色相情報生成部２１５０はそれぞれの投射点に対する色相情報列を生成する（Ｓ２２４０）。ノード生成部２１６０はイメージ平面に対応する平面情報、深さ情報列及び色相情報列で構成されるノードを生成する（Ｓ２２５０）。
【０３２３】
図３８及び図３９を参照して説明した深さイメージに基づく３次元客体の表現装置及び方法は、ポイントテクスチャー（ＰｏｉｎｔＴｅｘｔｕｒｅ）による客体表現に適用される。ポイントテクスチャーの構造は図２６に図示されている。
【０３２４】
図４０は、本発明による深さイメージに基づく３次元客体の表現装置に対するさらに他の実施例の構成を示すブロック図である。図４０を参照すれば、深さイメージに基づく３次元客体の表現装置２３００は前処理部２３１０、参照イメージ決定部２３２０、形態情報生成部２３３０、インデックス生成部２３４０、ノード生成部２３５０、及びエンコーディング部２３６０で構成される。
【０３２５】
前処理部２３１０は参照イメージを前処理する。前処理部２３１０の詳細な構成が図４１に図示されている。図４１を参照すれば、前処理部２３１０は拡散部２４１０及び圧縮部２４２０を有する。拡散部２４１０は、ブロックの平均色相と急速な強度の減衰を利用して参照イメージで客体と背景との境界に位置するピクセルの色相を背景に拡散する。圧縮部２４２０は、参照イメージに対してブロックに基づいた圧縮を行って歪曲を背景に放出する。
【０３２６】
参照イメージ決定部２３２０は、形態情報生成部２３３０により分割されたキューブ各々に対して色相イメージを含む参照イメージを決定する。参照イメージは、視点情報と視点情報に対応する色相イメージとで構成される深さイメージノードである。この時、視点情報は前記客体に対するイメージ平面を規定する複数のフィールドで構成される。視点情報を構成するそれぞれのフィールドは前述した通りであるので詳細な説明は省略する。一方、深さイメージノードに含まれる色相イメージはシンプルテクスチャーまたはポイントテクスチャーになりうる。
【０３２７】
形態情報生成部２３３０は客体を含むオクツリーを８個の下位キューブに分割し、分割された下位キューブを子ノードと規定して客体に対する形態情報を生成する。形態情報生成部２３３０は、分割された下位キューブのサイズが所定の基準サイズより小さくなるまで下位キューブへの分割過程を反復的に実施する。形態情報はキューブの側面に沿って存在するオクツリーリーフの最大個数が記録される解像度フィールド、オクツリーの内部ノードの構造を示す配列が記録されるオクツリーフィールド、及びオクツリーの内部ノードに対応される参照イメージのインデックスが記録されるインデックスフィールドを含む。
【０３２８】
インデックス生成部２３４０は、形態情報に対応する参照イメージのインデックス情報を生成する。図４２にはインデックス生成部２３４０の詳細な構成が図示されている。図４２を参照すれば、インデックス生成部２３４０は色相点生成部２５１０、ＰＢＲ生成部２５２０、イメージ変換部２５３０、及びインデックス情報生成部２５４０を有する。
【０３２９】
色相点生成部２５１０は、参照イメージに存在するピクセルを対応する深さマップに規定された距離だけ移動させて色相点を生成する。ＰＢＲ生成部２５２０は色相点の集合により中間的なＰＢＲイメージを生成する。イメージ変換部２５３０は、ＰＢＲイメージをそれぞれの点に対応するキューブにより表現したイメージのオクツリーイメージに変換する。インデックス情報生成部２５４０は、それぞれのキューブに対応する参照イメージのインデックス情報を生成する。
【０３３０】
ノード生成部２３５０は、形態情報、インデックス情報及び参照イメージで構成されるオクツリーノードを生成する。
【０３３１】
エンコーディング部２３６０は、オクツリーノードをエンコーディングしてビットストリームを出力する。エンコーディング部２３６０の詳細な構成が図４３に図示されている。図４３を参照すれば、エンコーディング部２３６０は文脈決定部２６１０、第１エンコーディング部２６２０、第２エンコーディング部２６３０、及び第３エンコーディング部２６４０、シンボルバイト記録部２６５０、及びイメージインデックス記録部２６６０で構成される。
【０３３２】
文脈決定部２６１０は、オクツリーノードに対するエンコーディング回数に基づいてオクツリーの現在ノードに対する文脈を決定する。第１エンコーディング部２６２０は、２２個のエントリを保有した一つの確率テーブルを維持しながら０−文脈モデル及び算術エンコーディングを利用して最初のノードから５１２個のノードをエンコーディングする。第１エンコーディング部２６２０は均一な分布からエンコーディングを始める。
【０３３３】
第２エンコーディング部２６３０は、親ノードを文脈として使用しながら１−文脈モデル及び算術エンコーディングを利用して５１２番目ノードから２０４８番目ノードまでのノードをエンコーディングする。第２エンコーディング部２６３０は０−文脈モデルから１−文脈モデルへの転換時、０−文脈モデルの確率テーブルをあらゆる１−文脈モデルの確率テーブルに複写する。図４４には第２エンコーディング部２６３０の詳細な構成が図示されている。
【０３３４】
図４４を参照すれば、第２エンコーディング部２６３０は確率検索部２７１０、算術コーダ２７２０、及びテーブル更新部２７３０で構成される。確率検索部２７１０は、文脈に対応する確率テーブルから文脈での現在ノードの発生確率を検索する。算術コーダ２７２０は検索された確率を含む確率列によりオクツリーを圧縮する。テーブル更新部２７３０は、現在文脈での現在ノードの発生頻度に所定の増分（例えば、１）を加えて確率テーブルを更新する。
【０３３５】
第３エンコーディング部２６４０は、親ノード及び子ノードのパターンを文脈として使用しながら２−文脈モデル及び算術コーディングを利用して２０４８番目以後のノードをエンコーディングする。第３エンコーディング部２６４０は１−文脈モデルから２−文脈モデルへの転換時、親ノードパターンに対する１−文脈モデルの確率テーブルを同じ親ノードパターンでのそれぞれの位置に対応する２−文脈モデルの確率テーブルに複写する。図４５には、第３エンコーディング部２６４０の詳細な構成が図示されている。
【０３３６】
図４５を参照すれば、第３エンコーディング部２６４０は第１検索部２８１０、第１検出部２８２０、第２検索部２８３０、パターン生成部２８４０、第２検出部２８５０、算術コーダ２８６０、及びテーブル更新部２８７０で構成される。
【０３３７】
第１検索部２８１０は、現在ノードの親ノードを検索する。第１検出部２８２０は、検索された親ノードが属するクラスを検出して親ノードを検出されたクラスの標準ノードに変換する変換を検出する。第２検索部２８３０は、親ノードに検出された変換を適用して現在ノードがマッピングされている変換された親ノードで現在ノードの位置を検索する。パターン生成部２８４０は、現在ノードに検出された変換を適用して検出されたクラスと現在ノードの位置インデックスとの結合に該当するパターンを生成する。第２検出部２８５０は、検出されたクラスと位置とで構成される組合わせに対応する確率テーブルのエントリから必要な確率を検出する。算術コーダ２８６０は、第２検出部２８５０から入力された確率列によりオクツリーを圧縮する。テーブル更新部２８７０は、現在文脈での現在ノードの発生頻度に所定の増分（例えば、１）を加えて確率テーブルを更新する。
【０３３８】
シンボルバイト記録部２６５０は、現在ノードがリーフノードではない場合に現在ノードに対応するシンボルバイトをビットストリームに記録する。その後、現在ノードのあらゆる子ノードが同じ参照イメージインデックスを有しており、現在ノードの親ノードが“未定の”参照イメージインデックスを有していれば、イメージインデックス記録部２６６０は現在ノードの下位ノードに対して同じ参照イメージインデックスをビットストリームに記録する。もし、現在ノードの子ノードが相異なる参照イメージインデックスを有していれば、イメージインデックス記録部２６６０は、現在ノードの下位ノードに対して“未定の”参照イメージインデックスを記録する。
【０３３９】
図４６は、本発明による深さイメージに基づく３次元客体の表現方法に関する他の実施例の実施過程を示すフローチャートである。図４６を参照すれば、形態情報生成部２３３０は、客体を含むオクツリーを下位キューブに分割して客体に対する形態情報を生成する（Ｓ２９００）。形態情報は、キューブの側面に沿って存在するオクツリーリーフの最大個数が記録される解像度フィールド、オクツリーの内部ノードの構造を表す配列が記録されるオクツリーフィールド、及びオクツリーの内部ノードに対応される参照イメージのインデックスが記録されるインデックスフィールドで構成される。内部ノード各々はバイトで表現され、内部ノードに属する子ノードに対する下位子ノードの存在如何はバイトを構成するビット列に記録されるノード情報により表現される。下位キューブへの分割過程は、分割されたキューブのサイズが所定の基準サイズ（この値は実験的に決定できる）より大きければ分割されたキューブを再び８個に分割する（Ｓ２９１０）。
【０３４０】
参照イメージ決定部２３２０は、分割されたキューブ各々に対して色相イメージを含む参照イメージを決定する（Ｓ２９２０）。参照イメージは、視点情報と、視点情報に対応する色相イメージとで構成される深さイメージノードである。視点情報の構成は前述した通りである。一方、参照イメージに対して前処理過程が行われうる。
【０３４１】
図４７は、参照イメージに対する前処理過程のフローチャートである。図４７を参照すれば、ブロックの平均色相と急速な強度の減衰を利用して参照イメージで客体と背景との境界に位置するピクセルの色相を背景に拡散する（Ｓ３０００）。そして、参照イメージに対してブロックに基づいた圧縮を行って歪曲を背景に放出する（Ｓ３０１０）。
【０３４２】
インデックス生成部２３４０は、形態情報に対応する参照イメージのインデックス情報を生成する（Ｓ２９３０）。図４８には、インデックス生成段階の遂行過程が図示されている。図４８を参照すれば、色相点生成部２５１０は参照イメージに存在するピクセルを対応する深さマップに規定された距離だけ移動させて色相点を生成する（Ｓ３１００）。ＰＢＲ生成部２５２０は、色相点の集合により中間的なＰＢＲイメージを生成する（Ｓ３１１０）。イメージ変換部２５３０は、ＰＢＲイメージをそれぞれの点に対応するキューブにより表現したイメージのオクツリーイメージに変換する（Ｓ３１２０）。インデックス情報生成部２５４０はそれぞれのキューブに対応する参照イメージのインデックス情報を生成する（Ｓ３１３０）。
【０３４３】
ノード生成部２３５０は、形態情報、インデックス情報、及び参照イメージで構成されるオクツリーノードを生成する（Ｓ２９４０）。
【０３４４】
エンコーディング部２３６０は、オクツリーノードをエンコーディングしてビットストリームを出力する（Ｓ２９５０）。
【０３４５】
図４９は、エンコーディング段階の遂行過程を示すフローチャートである。図４９を参照すれば、文脈決定部２６１０は、オクツリーノードに対するエンコーディング回数に基づいてオクツリーの現在ノードに対する文脈を決定する（Ｓ３２００）。現在ノードが５１２番目以下の場合に（Ｓ３２１０）、０−文脈モデル及び算術コーディングを利用して第１エンコーディング段階を遂行する（Ｓ３２２０）。現在ノードが５１２番目を超過すれば（Ｓ３２１０）、現在ノードに対する文脈を決定した後（Ｓ３２３０）、２０４８番目ノードに到達するまで１−文脈モデル及び算術コーディングを利用して第２エンコーディング段階を遂行する（Ｓ３２４０）。現在ノードが２０４８番目を超過すれば（Ｓ３２５０）、現在ノードに対する文脈を決定した後（Ｓ３２６０）、２−文脈モデル及び算術コーディングを利用して第３エンコーディング段階を遂行する（Ｓ３２７０）。
【０３４６】
この時、０−文脈は文脈と独立的であり、１−文脈は親ノードのクラスである。一方、クラスの全体個数は２２であり、基本変換により生成される直交変換Ｇにより連結される時、二つのノードが同じクラスに属する。基本変換は次の通りである。
【０３４７】
【数１３】

【０３４８】
図５０は、第２エンコーディング段階の遂行過程を示すフローチャートである。図５０を参照すれば、確率検索部２７１０は文脈に対応する確率テーブルから文脈での現在ノードの発生確率を検索する（Ｓ３３００）。算術コーダ２７２０は検索された確率を含む確率列によりオクツリーを圧縮する（Ｓ３３１０）。テーブル更新部２７３０は現在文脈での現在ノードの発生頻度に所定の増分（例えば、１）を加えて確率テーブルを更新する（Ｓ３３２０）。
【０３４９】
図５１は、第３エンコーディング段階の遂行過程を示すフローチャートである。図５１を参照すれば、第１検索部２８１０は現在ノードの親ノードを検索する（Ｓ３４００）。第１検出部２８２０は、検索された親ノードが属するクラスを検出して親ノードを検出されたクラスの標準ノードに変換する変換を検出する（Ｓ３４１０）。第２検索部２８３０は、親ノードに検出された変換を適用して現在ノードがマッピングされている変換された親ノードで前記現在ノードの位置を検索する（Ｓ３４２０）。パターン生成部２８４０は、現在ノードに検出された変換を適用して検出されたクラスと現在ノードの位置インデックスとの結合に当たるパターンを生成する（Ｓ３４３０）。第２検出部２８５０は検出されたパターンに対応する確率テーブルのエントリから必要な確率を検出する（Ｓ３４４０）。算術コーダ２８６０は第２検出部２８５０から入力された確率列によりオクツリーを圧縮する（Ｓ３４５０）。テーブル更新部２８７０は現在文脈での現在ノードの発生頻度に所定の増分（例えば、１）を加えて確率テーブルを更新する（Ｓ３４６０）。
【０３５０】
図５２は、エンコーディング段階で遂行されるオクツリーノードに対するビットストリームの生成過程を示すフローチャートである。図３５を参照すれば、現在ノードがリーフノードではない場合（Ｓ３５００）、シンボルバイト記録部２６５０は現在ノードに対応するシンボルバイトをビットストリームに記録して（Ｓ３５１０）Ｓ３５２０段階に進む。現在ノードがリーフノードであれば、Ｓ３５１０段階を遂行せずに直ちにＳ３５２０段階に進む。
【０３５１】
現在ノードのあらゆる子ノードが同じ参照イメージインデックスを有しており、現在ノードの親ノードが“未定の”参照イメージインデックスを有していれば（Ｓ３５２０）、イメージインデックス記録部２６６０は、現在ノードの下位ノードに対して同じ参照イメージインデックスをビットストリームに記録する（Ｓ３５３０）。もし、現在ノードの子ノードが相異なる参照イメージインデックスを有していれば（Ｓ３５２０）、イメージインデックス記録部２６６０は現在ノードの下位ノードに対して“未定の”参照イメージインデックスを記録する（Ｓ３５４０）。
【０３５２】
図５３は、本発明による深さイメージに基づく３次元客体の表現装置に関するさらに他の実施例の構成を示すブロック図であり、図５４は、本発明による深さイメージに基づく３次元客体の表現方法に関するさらに他の実施例の遂行過程を示すフローチャートである。
【０３５３】
図５３及び図５４を参照すれば、本発明による深さイメージに基づく３次元客体の表現装置３６００は入力部３６１０、第１抽出部３６２０、デコーディング部３６３０、第２抽出部３５４０、及び客体表現部３６５０で構成される。
【０３５４】
入力部３６１０は外部装置からビットストリームを入力される（Ｓ３７００）。第１抽出部３６２０は入力されたビットストリームからオクツリーノードを抽出する（Ｓ３７１０）。
【０３５５】
デコーディング部３６３０は抽出されたオクツリーノードをデコーディングする（Ｓ３７２０）。デコーディング部３６３０は文脈決定部、第１デコーディング部、第２デコーディング部、及び第３デコーディング部を具備する。デコーディング部３６３０を構成するそれぞれの構成要素は図４３ないし図４５そして図４９ないし図５２を参照して説明したエンコーディング部の対応する構成要素と同一なので詳細な説明は省略する。
【０３５６】
第２抽出部３６４０は、デコーディングされたオクツリーノードからオクツリーを構成する複数のキューブに対する形態情報及び参照イメージを抽出する（Ｓ３７３０）。客体表現部３６５０は、抽出された形態情報に対応する抽出された参照イメージを組合わせて客体を表現する（Ｓ３７４０）。
【０３５７】
本発明はまたコンピュータで読出しできる記録媒体にコンピュータが読めるコードとして具現することが可能である。コンピュータが読出しできる記録媒体は、コンピュータシステムによって読めるデータが貯蔵されるあらゆる記録装置を含む。コンピュータが読出しできる記録媒体の例には、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フレキシブルディスク、光データ貯蔵装置などがあり、またキャリヤウェーブ（例えば、インターネットを通した伝送）の形態に具現されるものも含む。またコンピュータが読出しできる記録媒体は、ネットワークで連結されたコンピュータシステムに分散されて分散方式でコンピュータが読めるコードが貯蔵されて実行される。
【０３５８】
以上、本発明の望ましい実施例について図示及び説明したが、本発明は前述した特定の望ましい実施例に限定されず、特許請求の範囲で請求する本発明の要旨を外れずに、当業者であれば、誰でも多様な変形実施が可能であることはもちろんであり、そのような変更は特許請求の範囲の記載範囲内にある。
【符号の説明】
【０３５９】
２３００ 深さイメージに基づく３次元客体の表現装置
２３２０ 参照イメージ決定部
２３３０ 形態情報生成部
２３４０ インデックス生成部
２３５０ ノード生成部
２３６０ エンコーディング部

【特許請求の範囲】
【請求項１】
客体を含むオクツリーの各ノードである下位キューブを子ノードと規定して前記客体に対する形態情報を生成する形態情報生成部と、
前記キューブ各々に対して時点情報と前記時点情報に対応する色相イメージを含む参照イメージを決定する参照イメージ決定部と、
前記形態情報に対応する前記参照イメージのインデックス情報を生成するインデックス生成部と、
前記形態情報、前記インデックス情報及び前記参照イメージで構成されるオクツリーノードを生成するノード生成部と、
前記オクツリーノードをエンコーディングしてビットストリームを出力するエンコーディング部と、を含み、
前記形態情報生成部は、前記下位キューブの大きさが所定の基準大きさより小さくなるまで前記下位キューブへの分割過程を反復的に実施することを特徴とする深さイメージに基づく３次元客体の表現装置であって、
前記エンコーディング部は、
前記オクツリーノードに対するエンコーディング回数に基づいてオクツリーの現在ノードに対して以前ノードによる次のノードの予測のための文脈を決定する文脈決定部と、
所定個数のエントリを保有した一つの確率テーブルを維持しながら０−文脈モデル及び算術エンコーディングを利用して最初のノードから第１所定個数のノードをエンコーディングする第１エンコーディング部と、
親ノードを文脈として使用しながら１−文脈モデル及び算術エンコーディングを利用して前記第１所定個数以後のノードから第２所定個数のノードをエンコーディングする第２エンコーディング部と、
前記親ノード及び子ノードのパターンを文脈として使用しながら２−文脈モデル及び算術コーディングを利用して前記第２所定個数以後の残りのノードをエンコーディングする第３エンコーディング部と、を含むことを特徴とする深さイメージに基づく３次元客体の表現装置。
【請求項２】
深さイメージに基づく３次元客体の表現装置が、
客体を含むオクツリーの各ノードである下位キューブを子ノードと規定して前記客体に対する形態情報が形態情報生成部により生成される段階と、
前記キューブ各々に対して時点情報と前記時点情報に対応する色相イメージを含む参照イメージが参照イメージ決定部により決定される段階と、
前記形態情報に対応する前記参照イメージのインデックス情報がインデックス生成部により生成される段階と、
前記形態情報、前記インデックス情報、及び前記参照イメージで構成されるオクツリーノードがノード生成部により生成される段階と、
エンコーディング部により前記オクツリーノードをビットストリームにエンコーディングする段階とを含み、
前記形態情報生成段階は、前記下位キューブのサイズが所定の基準サイズより小さくなるまで前記下位キューブへの分割過程を反復的に実施する深さイメージに基づく３次元客体の表現方法であって、
前記エンコーディング段階は、
前記オクツリーノードに対するエンコーディング回数に基づいて前記オクツリーの現在ノードに対して以前ノードによる次のノードの予測のための文脈を決定する段階と、
所定個数のエントリを保有した一つの確率テーブルを維持しながら０−文脈モデル及び算術エンコーディングを利用して最初のノードから第１所定個数のノードをエンコーディングする第１エンコーディング段階と、
親ノードを文脈として使用しながら１−文脈モデル及び算術エンコーディングを利用して前記第１所定個数以後のノードから第２所定個数のノードをエンコーディングする第２エンコーディング段階と、
前記親ノード及び子ノードのパターンを文脈として使用しながら２−文脈モデル及び算術コーディングを利用して前記第２所定個数以後の残りのノードをエンコーディングする第３エンコーディング段階と、を含むことを特徴とする深さイメージに基づく３次元客体の表現方法。
【請求項３】
ビットストリームを入力される入力部と、
前記ビットストリームからオクツリーノードを抽出する第１抽出部と、
前記オクツリーノードをデコーディングするデコーディング部と、
前記デコーディングされたオクツリーノードからオクツリーを構成する複数のキューブに対する形態情報及び参照イメージを抽出する第２抽出部と、
前記抽出された形態情報に基づいて前記抽出された参照イメージを組合わせて客体を表現する客体表現部とを含む深さイメージに基づく３次元客体の表現装置であって、
前記デコーディング部は、
前記オクツリーノードに対するエンコーディング回数に基づいて前記オクツリーの現在ノードに対して以前ノードによる次のノードの予測のための文脈を決定する文脈決定部と、
所定個数のエントリを保有した一つの確率テーブルを維持しながら０−文脈モデル及び算術デコーディングを利用して最初のノードから第１所定個数のノードをデコーディングする第１デコーディング部と、
親ノードを文脈として使用しながら１−文脈モデル及び算術デコーディングを利用して前記第１所定個数以後のノードから第２所定個数のノードをデコーディングする第２デコーディング部と、
前記親ノード及び子ノードのパターンを文脈として使用しながら２−文脈モデル及び算術デコーディングを利用して前記第２所定個数以後の残りのノードをデコーディングする第３デコーディング部と、を含むことを特徴とする深さイメージに基づく３次元客体の表現装置。
【請求項４】
深さイメージに基づく３次元客体の表現装置が、
入力部によりビットストリームが入力される段階と、
第１抽出部により前記ビットストリームからオクツリーノードが抽出される段階と、
デコーディング部により前記オクツリーノードがデコーディングされる段階と、
前記デコーディングされたオクツリーノードからオクツリーを構成する複数のキューブに対する形態情報及び参照イメージが第２抽出部により抽出される段階と、
客体表現部により前記抽出された形態情報に基づいて前記抽出された参照イメージを組合わせて客体が表現される段階と、を含む深さイメージに基づく３次元客体の表現方法であって、
前記デコーディング段階は、
前記オクツリーノードに対するエンコーディング回数に基づいて前記オクツリーの現在ノードに対して以前ノードによる次の ノードの予測のための文脈を決定する段階と、
所定個数のエントリを保有した一つの確率テーブルを維持しながら０−文脈モデル及び算術デコーディングを利用して最初ノードから第１所定個数のノードをデコーディングする第１デコーディング段階と、
親ノードを文脈として使用しながら１−文脈モデル及び算術デコーディングを利用して前記第１所定個数以後のノードから第２所定個数のノードをデコーディングする第２デコーディング段階と、
前記親ノード及び子ノードのパターンを文脈として使用しながら２−文脈モデル及び算術デコーディングを利用して前記第２所定個数以後の残りのノードをデコーディングする第３デコーディング段階と、を含むことを特徴とする深さイメージに基づく３次元客体の表現方法。

【図２】

【図３】

【図４】

【図６】

【図１４】

【図２１】

【図２４】

【図２５】

【図２６】

【図２７】

【図２８】

【図３５】

【図３６】

【図３７】

【図３８】

【図３９】

【図４０】

【図４１】

【図４２】

【図４３】

【図４４】

【図４５】

【図４６】

【図４７】

【図４８】

【図４９】

【図５０】

【図５１】

【図５２】

【図５３】

【図５４】

【図１】

【図５】

【図７】

【図８】

【図９】

【図１０】

【図１１】

【図１２】

【図１３】

【図１５】

【図１６】

【図１７】

【図１８】

【図１９】

【図２０】

【図２２】

【図２３】

【図２９】

【図３０】

【図３１】

【図３２】

【図３３】

【図３４】

【公開番号】特開２０１０−２１８５８８（Ｐ２０１０−２１８５８８Ａ）
【公開日】平成２２年９月３０日（２０１０．９．３０）
【国際特許分類】
【出願番号】特願２０１０−１５７３４３（Ｐ２０１０−１５７３４３）
【出願日】平成２２年７月９日（２０１０．７．９）
【分割の表示】特願２００６−２０４０１４（Ｐ２００６−２０４０１４）の分割
【原出願日】平成１４年１１月２７日（２００２．１１．２７）
【出願人】（３９００１９８３９）三星電子株式会社 (8,520)
【氏名又は名称原語表記】ＳＡＭＳＵＮＧ　ＥＬＥＣＴＲＯＮＩＣＳ　ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】４１６，Ｍａｅｔａｎ−ｄｏｎｇ，Ｙｅｏｎｇｔｏｎｇ−ｇｕ，Ｓｕｗｏｎ−ｓｉ，Ｇｙｅｏｎｇｇｉ−ｄｏ　４４２−７４２（ＫＲ）
【Ｆターム（参考）】