JP4832975B2 - 深さイメージに基づく3次元客体を表現するためのノード構造を記憶させた、コンピュータで読み出し可能な記録媒体 - Google Patents
深さイメージに基づく3次元客体を表現するためのノード構造を記憶させた、コンピュータで読み出し可能な記録媒体 Download PDFInfo
- Publication number
- JP4832975B2 JP4832975B2 JP2006203922A JP2006203922A JP4832975B2 JP 4832975 B2 JP4832975 B2 JP 4832975B2 JP 2006203922 A JP2006203922 A JP 2006203922A JP 2006203922 A JP2006203922 A JP 2006203922A JP 4832975 B2 JP4832975 B2 JP 4832975B2
- Authority
- JP
- Japan
- Prior art keywords
- field
- image
- depth
- recorded
- texture
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T9/00—Image coding
- G06T9/40—Tree coding, e.g. quadtree, octree
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T15/00—3D [Three Dimensional] image rendering
- G06T15/10—Geometric effects
- G06T15/20—Perspective computation
- G06T15/205—Image-based rendering
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T17/00—Three dimensional [3D] modelling, e.g. data description of 3D objects
- G06T17/005—Tree description, e.g. octree, quadtree
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T9/00—Image coding
- G06T9/001—Model-based coding, e.g. wire frame
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multimedia (AREA)
- Geometry (AREA)
- Computer Graphics (AREA)
- Computing Systems (AREA)
- Software Systems (AREA)
- Processing Or Creating Images (AREA)
- Image Generation (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
Description
任意の形状は、色多角形の集合、すなわち、三角形の集合により概略的に表現できる。
ソフトウェアアルゴリズムの飛躍的な進歩及びグラフィックハードウェアの発展により、複雑な客体及び場面をリアルタイムでかなり現実的な静止及び動映像多角形モデルに視覚化できる。
これは、レンダリングの複雑さの問題や、写真のように現実的な場面を生成する場合に品質が落ちるという問題だけではなく、現実の客体をポリゴンモデルで表現しづらいという問題に起因するものである。
たとえ、3次元レーザースキャナーのように3次元測定技術分野での最近の進歩の結果、許容可能なエラーを有する稠密なデータを得る事はできるが、全体客体に対して連続的に完壁な多角形モデルを得ることは依然としてコストが多くかかって非常にむずかしい。
一方、写真のような現実的な品質を得るための多角形レンダリングアルゴリズムは、演算が複雑となるのでリアルタイムレンダリングが不可能である。
[1.序論]
以下、イメージに基づくレンダリング(AFX A8.3)についての主要な実験結果を説明する。
この実験は、深さ情報を有するテクスチャーを利用したイメージに基づくレンダリング技術に関するものである。また、10月に開催されたAFX adhocグループ会議期間中の57次MPEG会議以後に行われた実験結果に基づいてノード定義に加えられたいくつかの変更を提示するものである。
<2.1.テストモデル>
●静止客体に対して
■シンプルテクスチャーを有する深さイメージノード
◆犬
◆チラノサウルスレックス(約20個のカメラを使用した深さイメージ)
◆テラスク(モンスター)(約20個のカメラを使用した深さイメージ)
◆膽星台(約20個のカメラを使用した深さイメージ)
◆椰子(約20個のカメラを使用した深さイメージ)
■階層テクスチャーを有する深さイメージノード
◆天使
■ポイントテクスチャーを有する深さイメージノード
◆天使
■オクツリーイメージノード
◆生物
●動的客体に対して
■シンプルテクスチャーを有する深さイメージノード
◆竜
◆背景での竜
■階層テクスチャーを有する深さイメージノード
◆提供されない
■オクツリーイメージノード
◆ロボット
◆背景での竜
●今後より多くのデータ(スキャニングまたはモデリングされた)が提供されるであろう。
●シドニーで提案されたあらゆるノードはblaxxun contact 4.3参照ソフトウェアに統合されている。しかし、まだcvsサーバーにソースが更新されていない。
●イメージに基づくレンダリング(Image Based Rendering:IBR)に対する動的フォーマットは、それぞれの動映像ファイルから同じキーフレームに存在するイメージが同時に与えられるように、複数の動映像ファイルの間に同調される必要がある。
従って、現在動的フォーマットは、あらゆる動的データが既にファイルに存在すると仮定することによって表面化される。暫定的にAVIフォーマットの動映像ファイルがそれぞれの動的テクスチャーに使われる。
●図1は現在参照ソフトウェアに統合されたIBRの例である。
IBR提案に対するシドニー会議の結論は、イメージ及びカメラ情報を含むIBRストリームを有さねばならず、IBRノードはそれへのリンク(url)を有すればよいということである。
しかし、Rennesで開催されたadhogグループ会議でのIBRに対する議論結果は、IBRノードとストリームのいずれもがイメージ及びカメラ情報を有さねばならないということである。
従って、IBRノードに対するノード定義は次のようにアップデートされる。
なお、IBRストリームの必要性はurlフィールドを説明する章で説明される。
それは、多様な形態の深さイメージテクスチャー(シンプルテクスチャーまたはポイントテクスチャー)の一つである。
方向は基本方向に対する相対的回転を特定する一方、位置は座標系の原点(0,0,0)に相対的である。
基本位置及び方向で、観察者は右側には+X軸と垂直に+Y軸とを有する原点に向かって−Z軸を見下ろしながらZ軸上に位置する。しかし、変換階層は視点の最終位置及び方向に影響を与える。
しかし、直交(orhogonal)フィールドが真(TRUE)と設定されればfieldOfViewフィールドは隣接平面(nearPlane)と遠接平面(farPlane)との幅と高さを意味する。
●位置(position)
●方向(orientation)
●fieldOfView
●近接平面(nearPlane)
●遠接平面(farPlane)
●直交(orthogonal)
●diTexture(シンプルテクスチャーまたはポイントテクスチャー)
● 上位フィールドのフラグオン/オフに対する1バイトヘッダ
●
テクスチャー(texture)フィールドは、各ピクセルに対する色相を含む平面イメージを特定する。これは多様な形態のテクスチャーノード(イメージテクスチャー、動映像テクスチャーまたはピクセルテクスチャー)のうち一つである。
深さフィールドは、テクスチャーフィールドの各画素の「深さ」を定義する。深度マップの大きさはテクスチャーフィールド画像若しくは映像のサイズと同じである。これは、多様な形態のテクスチャーノード(イメージテクスチャー、動映像テクスチャーまたはピクセルテクスチャー)のうち一つである。
深さノードがNULLである場合若しくは深さフィールドが特定されていない場合、テクスチャーフィールドのアルファチャンネルは深さマップとして利用される。
このようなバイトのi番目ビットの「1」は、内部ノードのi番目の子に対して子ノードが存在することを意味する。
一方、「0」は子ノードが存在しないことを意味する。
オクツリー内部ノードの順序は、オクツリーの幅優先横断順序にならねばならない。内部ノードの8個の子の順序が図2に示されている。
●フラグに対するヘッダ
●オクツリー解像度
●オクツリー
●オクツリーイメージ(複数の深さイメージノード)
■隣接平面は使われない
■遠接平面は使われない
■diTecture→深さを有していないシンプルテクスチャー
以下、IBR(AFX A8.3)に対する主要な実験結果を説明する。
この実験は、深さ情報を有するテクスチャーを利用したIBR技術に関するものである。また、10月に開催されたAFX adhocグループ会議期間中の57次MPEG会議及び議論以後の実験に基づいてノード定義に加えられたいくつかの変更が提示するものである。
<2.1.ストリームフォーマット>
オクツリーイメージノードは、オクツリーイメージストリームの住所を特定するoctreeUrlフィールドを含む。このストリームは付加的に次のような内容を含むことができる。
●フラグに対するヘッダ
●オクツリー解像度
●オクツリー
●オクツリーイメージ(複数の深さイメージノード)
■隣接平面は使われない
■遠接平面は使われない
■diTexture→深さを持っていないシンプルテクスチャー
一方、「0」は、子ノードが存在しないことを意味する。オクツリー内部ノードの順序はオクツリーの幅優先横断順序にならねばならない。内部ノードの8つの子の順序が図2に示されている。
DIBRのオクツリー表現において、データは形態成分を表現するオクツリーフィールドで構成される。
オクツリーは閉じられたキューブ内に存在する点の集合であり、客体表面を完全に表現する。
圧縮された表現から形態の同一でない再生はかなり目立つアーチファクトを生じる。従って、形態は情報の損失なしに圧縮されねばならない。
深さ優先横断オクツリー形態で表現されるオクツリーフィールドの圧縮のために、部分マッチングによる予測(Prediction by Partial Matching:PPM)接近の一部概念を利用した無損失圧縮方法を開発した。
それぞれの文脈に対して、文脈に存在する各シンボルの推定発生確率を示す確率テーブルが存在する。
この確率テーブルは、領域コーダと呼ばれる算術コーダと一緒に使用される。
1.子ノードに対する文脈として親ノードを使用する。
2.文脈の数を減らすために‘直交不変’推定を使用する。
このような仮定により、極端に多くの確率テーブルを必要とせずに、複雑な文脈が使用可能となる。
順に、これによりデータサイズ及び速度面でかなり良好な結果を得られる。多くの文脈を使用するほど推定された確率がより明確になり、従って、コードがより簡潔になる。
提案された方法で、文脈はオクツリー構造の親−子階層においてモデリングされる。
まず、内部下位分割した後に、下位キューブの発生を表すビットを有するバイトノードと、シンボルを定義する。
従って、オクツリーでそれぞれのノードはシンボルになることができ、それらの数値は0〜255になる。確率テーブル(Probabilistic Table:PT)は256個の整数値を含む。
全体変数の和により割られたi番目変数値(0≦i≦255)は、i番目シンボル発生頻度(確率推定)と同一である。
確率文脈テーブル(ProbabilisticContextTable:PCT)はPTの集合である。シンボルの確率はPTの一つから決定される。特定のPTの数は文脈に依存する。PCTの例が表1に示されている。
下記表1は、PCTの成分を示す表である。
これらの下位キューブに対する積層パターンによってシンボルを分類できる。
われらの方法によれば、ここではグループと呼ばれる次のような特性を有する27個のシンボル集合が存在する。2個のシンボルは同じグループに属すればこのような固定された変換のうち一つにより連結される。
確率テーブルPTは、(256個のテーブルが存在する場合は)親ノード自体には依存しない。むしろ親ノードが属するグループ(図2で親シンボルと命名された)に依存すると考える。(従って、27個のテーブル)。
転換時、総ての文脈に対する確率テーブルPTは、0−文脈PTのコピー対して設定される。そして、27個の確率テーブルPTはコーディングの際に更新される。
ノードシンボルは、単純に親ノードにおける現在ノードの位置である。従って、2−文脈モデルに対して27×8個の文脈が存在する。
このようなモデルへの転換時、それぞれの文脈に対して得られた確率テーブルPTは、このような文脈の各ノード‘内部に存在する’に対して使われ、この時点から独立的に更新される。
現在シンボルの文脈(すなわち、親ノード)に対して、これらのグループが決定される。このグループの決定はテーブル検索により実施される(形態分析はプログラム開発段階で実施される)。
同様の変換が、シンボル自体にも適用される(このような演算もテーブル検索として実施され、あらゆる可能な結合に対するあらゆる計算はもちろん事前に実施される)。
事実上、この計算は、シンボルの文脈を含むグループについての確率テーブルPTに存在する現在のシンボルの正確な位置の計算である。
そして、対応する確率が領域コーダに入力される。
確率テーブルPTにおける確率分布そして文脈IDは、領域コーダに入力される。
エンコーディング後、PCTは次のエンコーディングでの使用のために更新される。
領域コーダはビットの代りにバイトに再正規化する算術コーディングの変形であり、従って、算術符号法より0.01%低い圧縮率を有すると共に、2倍も速く動作することに注目せねばならない。
図3は、静止及び動的モデルに対する本接近法の比較のためのテーブルである(横軸は圧縮率を表示する)。オクツリー圧縮率は元来オクツリーの大きさと比較して約1.5〜2倍で変わり、一般的な目的の無損失圧縮性能(RARプログラムのようなLempel−Ziv基盤)が約30%良好である。
<3.1.ストリームフォーマット>
深さイメージノードは、深さイメージストリームのアドレスを特定するdepthImageUrlフィールドを含む。このストリームは、次のような内容を付加的に含むことができる。
●位置(position)
●方向(orientation)
●fieldOfView
●隣接平面(nearPlane)
●遠接平面(farPlane)
●直交(orthogonal)
●diTexture(シンプルテクスチャーまたはポイントテクスチャー)
幅(width)と高さ(height)フィールドとはテクスチャーの幅と高さとを特定する。
深さ(depth)フィールドは、
左側下部コーナーに存在する点から出発して、上位線に移動する前に右側に横断して水平線で終了する横断
投影面の各点(正規化された座標)の複数の深さを特定する。
色相(color)フィールドは現在のピクセルの色相を特定する。
順序はそれぞれの点に対して深さ(ピクセル)の番号が含まれないということを除いては深さフィールドと同一である。
<3.2.1.深さフィールドの圧縮>
ポイントテクスチャーノードの深さフィールドは、単純に‘区分された閉じられたキューブ’に存在する点の集合である。底面を投影面と仮定する。
モデルに対してm×n×1大きさの格子が与えられ、点がこの格子のセル(オクツリーの場合にこれらをボクセルと称する)の中心に位置する場合、占有されたボクセルは「1」に、空いているボクセルは「0」と想定できる。
高さが16である‘スライス’を仮定し、列をバイトとする。すなわち、図面で表示された点の上に存在する列は、値「18」と「1」を有する2バイトスタック(または16−bit unsigned integer 274)を表す。
もし、このような方式で得られたバイトの集合に最適のPPM基盤圧縮方法を適用すれば良好な結果を得られる。しかし、単純な1−文脈方法をここに直接適用すれば(もちろん直交不変または階層的な文脈はここに使用できない)、これは多少低級な圧縮を招く。
ポイントテクスチャーノードの色相フィールドは、客体の点に起因した色相の集合である。
オクツリーの場合とは異なり、色相フィールドは深さフィールドと一対一対応関係にある。
概念は、色相データを公知の損失技術の一つにより圧縮されうる一つのイメージで表現することである。このようなイメージで最も重要なのは、オクツリーまたは深さイメージの場合における参照イメージよりはるかに小さいということであり、これはこのような接近法の実質的な動機である。イメージは多様な自然的な順序で深さ点をスキャニングして得られる。
多重ピクセルが、単純なピクセルと同じく自然的な順序で投影面にわたってスキャニングされ、同じ多重ピクセル内部の点が深さ方向にスキャニングされる。
このようなスキャニング順序は色相の1Dアレイ(1次nonzero多重ピクセル、2次nonzero多重ピクセル)を生成する。
イメージ圧縮方法を適用できるようにするために、このような長いストリングを2Dアレイに一対一マッピングせねばならない。これは多様な方法により実施できる。
このような形態のイメージでこのような方法の成功はそのパレット特性から正確に説明されうる。パレット特性により前面と背面とから点を混合することによって発生する地域的な色相変化を明確に考慮できる(これは“天使”の場合とはかなり異なりうる)。最適スキャンに対する調査の目的はこのような変化をできるだけ最大限度に減らすことである。
オリジナルのフォーマット及び圧縮されたフォーマットにおけるモデル例が添付3に図示されている。
他のモデル(イナゴ)は非常に良好な一方、一部のモデル(すなわち、天使)の品質は圧縮後に依然として満足するほどではない。しかし、このような問題は適切なスキャニングで解決できると考えられる。
ここに圧縮率に対するテーブルを提示する。
本文書には深さイメージに基づく表現に対する主要な実験結果(AFX A8.3)が記述されている。DIBRストリームが紹介されたが、DIBRストリームはDIBRノードのurlフィールドを通じて連結される。このようなストリームはそれぞれのアイテムを選択的なものにするためのフラグと共にDIBRノードに存在するあらゆるアイテムで構成される。また、オクツリー及びポイントテクスチャーデータの圧縮が検討された。
<BVO圧縮アルゴリズムにおいて文脈直交不変の形態的意味>
直交不変の概念の例が図6に図示されている。垂直軸を中心に時計回り方向に90°回転すると仮定する。ノードとそれの以前親ノードに対する任意の積層パターンと回転後のノードを仮定する。それにより、2つの相異なるパターンが同じパターンとして取扱われうる。
<グループと変換>
1.32個の固定された直交変換
各変換は5ビットワードにより特定される。ビット組合わせは、以下のような基本変換で構成される(すなわち、k番目ビットが1であれば対応する変換が実施される)。
●1番目ビット−x及びy軸を交換
●2番目ビット−y及びz軸を交換
●3番目ビット−y−z平面に対称
●4番目ビット−x−z平面に対称
●5番目ビット−x−y平面に対称
それぞれのグループに対してここにグループの順序とそれの要素のnonzeroビット数を提示する。これらはボクセル設定時にNumberOfGroup、QuantityOfGroup、及びNumberOfFillBitsに記録される。
それぞれのシンボルsに対してグループgが属するインデックスとそれをグループの‘標準’要素として取扱う変換tの値とを提示する。
シンボルの2進番号は次のようにボクセル2進座標にマッピングされる。番号のi番目ビットは2進座標x=i、y=i(1≪1)、そしてz=i(1≪2)を有する。
<ポイントテクスチャー圧縮画面出力>
最適PPM基盤方法に対する形態圧縮図面が図7〜図9に示されている。
以下、深さ映像基盤表現(Depth Image−Based Representation:DIBR)(AFX A8.3)に対する主要な実験結果を説明する。
この実験は、深さ情報を有するテクスチャーを利用した深さ基盤イメージ表現ノードに関するものである。
ノードはパッタヤ(Pattaya)で開催された会議で受容され、委員会草案に対する提案に含まれている。しかし、オクツリーノードと深さイメージノードとを通したこのような情報のストリーミングは依然として進行中にある。ストリーミングフォーマットは、オクツリーイメージノードに対するオクツリーフィールド及びポイントテクスチャーノードに対する深さ/色相フィールドの圧縮を含む。
ここでリンクを持っていないオクツリーデータ構造の効率的な新しい無損失圧縮技術を開示する。これにより既に簡潔な表現の体積を実験により約1.5〜2倍減らすことができる。また、エントロピーコーディングと特化されたブロック基盤テクスチャー圧縮方法とを結合した中間ボクセル表現を使用するいくつかのポイントテクスチャーフォーマットに対する無損失及び損失圧縮技術を提案する。
オクツリーイメージでオクツリーイメージフィールドとオクツリーフィールドとは個別的に圧縮される。
開示された方法は、オクツリーイメージに対しては一定程度の可視的に収容される歪曲が許容される一方で、オクツリーフィールドは損失なしに圧縮されねばならないという概念に基づいて開発された。
オクツリーイメージフィールドは、MPEG−4イメージ圧縮手段(静的モデルに対する)または動映像圧縮道具(動的モデルに対する)により圧縮される。
オクツリー圧縮は、非常に簡略でリンクを持っていない2進ツリー表現の圧縮を扱っているため、オクツリーイメージ圧縮の最も重要な部分である。
しかし、実験で後述される方法は、このような構造の体積を大体元来の半分に縮めた。動的なオクツリーイメージバージョンで、オクツリーフィールドはそれぞれの3Dフレームに対して個別的に圧縮される。
圧縮はデータの形態的特性を明確に使用する多様な適応算術符号法(arithmeticcoding)(‘領域エンコーダ’で実行される[3][4])により実施される。
オクツリーはバイトストリームである。それぞれのバイトはツリーのノード(すなわち、サブキューブ)を示し、バイトのビットは内部的な分割後のサブキューブの占有を示す。ビットパターンはノードの積層パターンと呼ばれる。提案された圧縮アルゴリズムは次のような方式でバイトを一つずつ処理する。
●このような文脈で現在バイトの発生‘確率’(正規化された頻度)を文脈に対応する‘確率テーブル’(PT)から検索
●領域エンコーダに確率値提供
●現在文脈で現在バイト発生の頻度に1を足して現在PT更新(必要時、作業実行後に再正規化、下の詳細な説明を参照)
x−z平面上で−90゜回転する変換Rに対する仮定‘B’は図6に示されている。‘B’の裏面に存在する基本的な概念は、特定な形態の親ノードにおいて特定な形態の子ノードの発生確率は単にこれらの相対的な位置に依存するということである。このような仮定はPTの分析による実験で立証された。これにより、過度に多くのPTを保有せずに複雑な文脈を使用できる。順に、これによりデータサイズ及び速度面でかなり良好な結果を得られる。複雑な文脈を使用するほど推定された確率がより明確になり、従ってコードがより簡潔になることに注目せねばならない。
PTに対する統計をより正確にするために、エンコーディング手順の3つの過程で相異なる方式が収集される。
●最初の512個のノード(実験的に発見された番号)がエンコーディングされてすぐ、親ノードを文脈として使用する‘1−文脈モデル’に転換する。転換時、0−文脈PTはあらゆる22個の文脈に対するPTに複写される。
●次の2048個のノード(他の発見値)がエンコーディングされた後、‘2−文脈モデル’に転換する。この瞬間に親パターンの1−文脈PTは同じ親パターンでそれぞれの位置に対するPTに複写される。
●Pが属するCMTからクラスを導出し、Pを該当クラスの標準ノードとして取扱う変換Tを導出する。クラス番号はcという。
●PにTを適用し、現在ノードNがマッピングされている標準ノードで子の位置pを検索する。
●NにTを適用すれば、新しく得られた積層パターンTNはクラスcの標準ノードで位置pに存在する。
●クラス位置組合わせ(c,p)に対応するPTのエントリTNから必要な確率を導出する。
ノードNのデコーディング過程でその親Pは既にデコーディングされているので、変換Tは公知のものであることに注目せねばならない。デコーディング過程であらゆる段階は対応するエンコーディング段階と完全に類似している。
最後に、確率更新手順を略述する。Pを任意の文脈に対する確率テーブルという。このような文脈でノードNの発生確率に対応するPのエントリをP(N)と命名する。われらの作業において、P(N)は整数であり、それぞれのNの発生後にP(N)は次のように更新される。
P(N)=P(N)P+A
ポイントテクスチャーノードは圧縮される二つのフィールド、すなわち、深さフィールドと色相フィールドとを含む。ポイントテクスチャーデータ圧縮の主な難点は次のような要件に起因する。
●色相情報はいかなる自然的な2D構造を持っていないため、イメージ圧縮技術を即刻適用できない。
●標準ノード表現に対する無損失圧縮
●低解像度ノード表現に対する無損失圧縮
●低解像度ノード表現に対する無損失形態圧縮及び損失色相圧縮
これは次のように動作する簡単な無損失コーディング方法である。
●深さフィールドは、オクツリーフィールド圧縮で使われたものと類似した適応領域コーダにより圧縮される。このフォーマットに対して、PTがそれぞれの1−シンボル文脈に対して維持され、文脈は単純に以前バイトであるバージョンを使用する。従って、256PTが使われる。深さフィールドはバイトストリームと見なされ、形態構造は明白に使われない。
●色相フィールドは平面実色相イメージに変換された後、圧縮される。ポイントテクスチャーモデルで点の色相は、まず臨時的な1Dアレイに深さフィールドでの深さ値のように同じ順序で記録される。モデルで全体点の個数をLとすれば、l・l≧Lが最も小さな整数になるlを計算し、辺が1である四角形イメージでこのようなlong‘ストリング’色相値を包む(必要時、検定ピクセルによりさらに包む)。次に、このようなイメージはMPEG−4無損失イメージ圧縮道具により圧縮される。本接近でPortable Network Graphics(PNG)フォーマットが使われる。‘天使’モデルからこのような方式により得られたイメージが図10(a)に図示されている。
多くの場合に深さ情報に対する16−ビット解像度はかなり良好である。実際に、深さにおいて解像度はモデルが可視化されるスクリーンの解像度に対応されねばならない。相異なる点においてモデル深さの小さな変化がピクセルのサイズよりはるかに小さなスクリーン面での変位を導出する場合に、深さにおいてより低い解像度を使用することが当然であり、モデルはたびたび深さ値が8〜11ビットのフォーマットで表現される。そのようなモデルは大体適当な空間格子上で深さと色相値とを分離させることによって他のフォーマット、すなわち、多角形モデルから得られる。
●深さフィールドはまずボクセル表現に変換され、次に以前下位章で記述された多様な領域コーダにより圧縮される。
以前の方法のように、この方法は深さフィールドをボクセル表現に変換した後、適応1−文脈領域コーダにより圧縮する。色相フィールドはまた2Dイメージでマッピングされる。しかし、3D空間にある近い点を2Dイメージ平面にある隣接した点にマッピングするためにマッピングを構成しようとする。その後、特化されたテクスチャー圧縮方法(適応ブロックパーティション(Adaptive Block Partition:ABP))が結果イメージに適用される。該当アルゴリズムの主な段階は次の通りである。
2.得られたwidth×4×2sボクセルアレイを次によりスキャンする。
3.このような横断順序で互いに出合うモデルの点の色相を補助1Dアレイに記録する。
4.得られた色相アレイを2Dイメージに再配列する。
5.連関性のある64個の色相サンプルが8−by−8ピクセルブロックに列方向に配列され、次いで次の64個のサンプルが隣接した8−by−8ピクセルアレイに配列される。
6.得られたイメージをABP技術により圧縮する。
この章では、2つの相異なるフォーマット−オクツリーイメージ及びポイントテクスチャー−を有する‘天使’と‘モルトン256’の2つのモデルを比較した結果を示す。それぞれのモデルに対する参照イメージの寸法は256×256ピクセルである。
<3.1.ポイントテクスチャー圧縮>
テーブル3ないしテーブル5に相異な圧縮方法の結果が与えられている。この実験に対するモデルは8ビットの深さフィールドを有するモデルから得られた。深さ値は32ビットの深さ値でのビット分布をより均一化して‘真の’32ビット値にある程度近づくように221+1の量子化段階を使用して(1,230)領域にかけて拡張された。
モデルの点をスキャニングする過程で空間的に距離がある点は同じ2Dイメージブロックに引き込まれる。このようなモデルの離れている点で色相は大きい差がありうる。
テーブル6は、2つのテストモデルに対する圧縮及び圧縮されていないオクツリー成分の大きさを示す。このようなフィールドの減少は約1.6〜1.9倍であることが分かる。
しかし、はなはだしくは8ビットの深さフィールドを有している圧縮されていないポイントテクスチャーモデルと比較してもオクツリーイメージははるかに簡単である。
解決:直交フィールドの基本値を次のように“FALSE”から“TRUE”に取り替える。
提案された改正案:
解決:DepthImageUrlフィールドを深さイメージノードから除去する。
提案された改正案:
解決:第5段落で、‘正規化された’を‘スケールされた’に変更する。
提案された改正案:
nearPlaneとfarPlaneフィールドは視点から可視領域の隣接平面及び遠接平明までの距離を特定する。テクスチャー及び深さデータは隣接平面、遠接平面そしてfieldOfViewにより囲まれた領域を示す。深さデータは隣接平面から遠接平面までの距離にスケールされる。
解決:depthImageUrlフィールドに対する説明を削除する(第7段落及びそれ以下)
解決:3番目段落の長さフィールド定義を次のように変更する。
提案された改正案:
深さフィールドはテクスチャーフィールドにあるそれぞれのピクセルに対する深さを特定する。深さマップのサイズはイメージまたはテクスチャーフィールドの動映像と同じサイズでなければならない。
(1)深さは深さフィールドを通じて特定され、深さ値dはグレースケールと同一である。
(2)深さがテクスチャーフィールドを通じて定義されたイメージでのアルファチャンネルを通じて特定されれば、深さ値dはアルファチャンネル値と同一である。
動的深さイメージに基づくモデルに対して、diTextureとしてシンプルテクスチャーを有する深さイメージだけ使われる。
(1)深さフィールドは上の条件を満足する静止イメージであり、テクスチャーフィールドは任意の動映像テクスチャーである。
(2)深さフィールドは深さフィールドで上の条件を満足する任意の動映像テクスチャーであり、テクスチャーフィールドは静止イメージである。
(3)深さ及びテクスチャーは動映像テクスチャーであり、深さフィールドは上の条件を満足する。
(4)深さフィールドは使われず、深さ情報はテクスチャーフィールドをアニメ化する動映像テクスチャーのアルファチャンネルから導出される。
解決:深さフィールド定義(第3段落)を提案された改正案に取り替える。
提案された改正案:
深さ値の形態的意味及びシンプルテクスチャーに対して採択されたそれらの解釈におけるあらゆる約束はここに同じく適用する。
深さフィールドは投影面に存在するそれぞれの点に対する複数の深さを特定し、横断順序において遠接平面(上を参照)と見なされ、左側下段コーナーにある点から出発して右側に横断しながら上側にある線に移動する前に水平線で終了する。それぞれの点に対して、深さ(ピクセル)番号が先に貯蔵され、深さ番号値は次に貯蔵される。
解決:オクツリーフィールドに対するフィールドタイプをNFInt32に変更する。
提案された改正案:
6.5.3.4.1節で、
H.1節で、オクツリーに対するテーブルのオクツリー列を次のように変更する。
解決:オクツリーイメージノードからoctreeUrlフィールドを削除する。
提案された改正案:
解決:‘許容される(allowed)’という単語を追加して説明を改正する。
提案された改正案:
オクツリー解像度フィールドは閉じられたキューブの側面に沿う最大に許容されるオクツリーリーフの数を特定する。オクツリーレベルは次の式を使用してオクツリー解像度から決定できる。
解決:octreeUrlフィールドの説明(第5段落とそれ以下)を削除する。
提案された改正案:
解決:6.5.3.4.2節の末尾にオクツリーイメージ動映像化を記述する段落を追加する。
提案された修正案:
オクツリーイメージの動映像化は、単に深さフィールドの代わりにオクツリーフィールドを使用することにのみ差があるだけで、上に記述された深さイメージに基づく動映像に対する最初の3つの方法と同じ接近法により実施さうる。
問題:ポイントテクスチャーノードにおいて深さデータの領域が将来の応用に対しては小さすぎる。多くのグラフィック道具は自体のz−バッファに対して24ビットまたは36ビットの深さを許容する。しかし、ポイントテクスチャーにおいて深さフィールドは16ビットである[0,65535]の領域を有する。
解決:H.1節で、ポイントテクスチャーに対するテーブルの深さ列の領域を次のように変更する。
本文書で深さ映像基盤表現(Depth Image−Based Representation:DIBR)(AFX A8.3)においてオクツリーイメージ(OctreeImage)の改善が記述される。オクツリーイメージノードはPattayaで開催された会議で受容され、委員会草案に対する提案に含まれている。しかし、客体形状の閉鎖によっていくつかの特別な場合にはレンダリング品質が満足するほどではないと観察された。本文書には、ストリーミングのためのオクツリーイメージノードの圧縮方法だけでなく、オクツリーイメージノードの改善されたバージョン−構造化された2進体積オクツリー(Textured Binary Volumetric Octree:TBVO)−が開示される。
<2.1.TBVO概観>
TBVOの目標は、2進体積オクツリー(Binary Volumetic Octree:BVO)の改善として速い視覚化が可能なより柔軟な表現/圧縮フォーマットを考案することである。これは、BVOに基づいていくつかの付加的な情報を貯蔵することによって達成される。BVOに基づいた表現はオクツリー構造及び参照イメージ集合で構成される。一方、TBVOに基づいた表現はBVOオクツリー構造及び参照イメージ集合、そしてカメラインデックスで構成される。
結果的に、特定のカメラに投影されるあらゆるボクセルを探さねばならない。しかし、ブルートフォース接近法を使用するならばこのような過程は非常に遅い。われらは客体形状の大部分に対して速くて正確にこれを実行するアルゴリズムを開発した。しかし、いかなるカメラによっても見られないボクセルについては依然としていくつかの問題点が存在する。
本節で、TBVO表現の有効性及び核心的な要素を示す典型的な例を示す。図12(a)に“天使”に対するBVOモデルが図示されている。
255個のカメラで十分であり、インデックスのために1バイトまで割り当てることを提案する。TBVOストリームはシンボルストリームである。あらゆるTBVOシンボルはBVOシンボルまたは構造化されたシンボルである。構造化されたシンボルはカメラインデックスを意味し、カメラインデックスは特定の番号または“未定の”コードになりうる。以下、“未定の”コードは“?”と表示する。
オクツリーイメージノードでオクツリーイメージとオクツリーフィールドとは個別的に圧縮される。開示された方法は、オクツリーイメージに対しては一定程度の可視的に受け入れられる歪曲が許容されるのに対し、オクツリーフィールドは損失なしに圧縮されねばならないという概念に基づいて開発された。
オクツリーイメージフィールドはMPEG−4で許容されるMPEG−4イメージ圧縮(静的モデルに対する)手段または映像圧縮道具(動的モデルに対する)により圧縮される。われらの接近で、われらはオクツリーイメージに対してJPEGフォーマットを使用した(それぞれの構造を維持させながら3D視覚化に必要な点だけJPEGイメージの’少量化’と命名した一定の前処理を実行した後;すなわち、3Dレンダリング段階で使われない与えられた構造の一部は所望する分だけ概略的に圧縮されうる)。
オクツリー圧縮は、既に非常に簡略でリンクのない2進ツリー表現の圧縮を取扱っているゆえに、オクツリーイメージ圧縮の最も重要な部分である。しかし、実験で後述される方法はこのような構造の体積を元の約半分に減少させた。動的のオクツリーイメージバージョンで、オクツリーフィールドはそれぞれの3Dフレームに対して個別的に圧縮される。
圧縮はデータの形態的特性を明確に使用する多様な適応算術コーディング(‘領域エンコーダ’で実行される)により実施される。オクツリーはバイトストリームである。それぞれのバイトはツリーのノード(すなわち、下位キューブ)を示し、バイトのビットは内部的な分割後の下位キューブの占有を示す。ビットパターンはノードの積層パターンと呼ばれる。開示された圧縮アルゴリズムは次のような方式でバイトを一つずつ処理する。
●このような文脈で現在バイトの発生‘確率’(正規化された頻度)を文脈に対応する‘確率テーブル’(PT)から検索
●領域エンコーダで確率値提供
●現在文脈で現在バイト発生の頻度に1を足して現在PT更新(必要時、作業隨行後に再正規化、下の詳細な説明を参照)
B.特定の親ノードにおいて特定の形態的位置で与えられたノード発生‘確率’は任意の直交(回転または対称のような)変換集合に対して不変であると仮定する。
オクツリーノードに適用されたGからの変換は、相異なる下位キューブの積層パターンを有するノードを算出する。これによりノードの下位キューブの積層パターンによってノードを分類できる。グループ理論言語を使用する時[5]、Gはオクツリーノードのあらゆる積層パターンに対する集合として作用すると言及する。計算によれば、22個の個別的なクラス(また、グループ理論でオービットと称される)が存在する。
仮定‘B’の実質的な重要性は、PTが親ノードそれ自体に従属的でなく、単に親ノードが属するクラスに従属的であるということである。親基盤文脈に対して256個のテーブルがありえるが、前者の場合に親−子位置基盤文脈に対して付加的な256×8=2048個のテーブルが必要である一方、後者の場合に親−クラス基盤文脈に対して22個のテーブルと22×8176個のテーブルとが必要であるということに注目せねばならない。従って、相対的に少数のPTを有して同等に複雑な文脈を使用することが可能である。作成されたPTはテーブルIに記載された形態をとることができる。
PTに対する統計をより正確にするために、エンコーディング手順の3つの過程で相異なる方式が収集される。
●‘0−文脈モデル’とされる最初の段階で文脈を全く使用せず、均一な分布から出発して256個のエントリを保有した一つのPTを維持する。
●最初の512個のノード(実験的に発見された番号)がエンコーディングされてすぐ、親ノードを文脈として使用する‘1−文脈モデル’に転換する。転換時、0−文脈PTはあらゆる22個の文脈に対するPTに複写される。
●次の2048個のノード(他の発見値)がエンコーディングされた後、‘2−文脈モデル’に転換する。この瞬間に親パターンの1−文脈PTは同じ親パターンでそれぞれの位置に対するPTに複写される。
●Pが属するCMTからクラスを導出し、Pを該当クラスの標準ノードとして取扱う変換Tを導出する。クラス番号はcという。
●PにTを適用し、現在ノードNがマッピングされている標準ノードで子の位置pを検索する。
●NにTを適用すれば、新しく得られた積層パターンTNはクラスcの標準ノードで位置pに存在する。
●クラス位置組合わせ(c,p)に対応するPTのエントリTNから必要な確率を導出する。
ノードNのデコーディング過程でその親Pは既にデコーディングされているので、変換Tは公知のものであることに注目せねばならない。デコーディング過程であらゆる段階は対応するエンコーディング段階と完全に類似している。
最後に、確率更新手順を略述する。Pを任意の文脈に対する確率テーブルという。このような文脈でノードNの発生確率に対応するPのエントリをP(N)と命名する。われらの作業において、P(N)は整数であり、それぞれのNの発生後にP(N)は次のように更新される。
それぞれのボクセルに対する構造(カメラ)番号を決定するシンボルストリームは自体に固有なPTを使用して圧縮される。先に使用した用語上ではそれは単一文脈を保有する。PTエントリはオクツリーノードに対するエントリより大きい増加分を有して更新される。残りはノードシンボルコーディングと差がない。
TBVO圧縮の結果が図15、17ないし19に示されている。圧縮されたサイズは圧縮されたBVOと比較される。3番目の列で括弧内の数字は圧縮された形態的な体積である。一方、最初の数字はTBVO基盤の圧縮モデル(すなわち、構造が考慮された)の総体積である。可視的な歪曲の大きさ面で、LDI→(T)BVO→LDI変換後に色相差を測定するためにPSNRが計算された。圧縮されたモデルのサイズは、あらゆる構造(最小化されたJPEGで貯蔵された、2.4.1.参照)のサイズさと圧縮された形態サイズとの和である。TBVOの場合に圧縮された形態はカメラ情報も含む。TBVOのPSNRはBVOと比較する時にかなり改善される。
これら番号は元の色相と最も一致するように選択される(すなわち、直接的な可視性とは関係なくそれぞれの地点に対してあらゆる‘カメラ’イメージで最上の色相一致が選択される。天使の場合、これは優れた結果を与える)。
オクツリーイメージ(Octreeimages)フィールドはdiTextureフィールドに対してシンプルテクスチャー(SimpleTexture)を有する深さイメージ(DepthImage)ノード集合を特定する。これらシンプルテクスチャー(SimpleTexture)ノードで深さフィールドは使われない。
<2.7.1.オクツリー圧縮>
<2.7.1.1.概観>
<2.7.1.2.1.文法>
オクツリーの圧縮されたストリームはoctree_frame_start_codeの次に来るオクツリーヘッダ及び一つ以上のオクツリーフレームを含む。octree_frame_start_codeの値は常に0x000001C8である。この値はストリームのルック−アヘッドパーシングにより検出される。
<2.7.1.3.1.文法>
このようなクラスはオクツリー圧縮に対してヘッダ情報を読み出す。
octreeResolutionBitsにより長さが表現されるoctreeResolutionはオクツリーイメージノードのオクツリー解像度フィールドの値を含む。
<2.7.1.4.文法>
このクラスは幅優先横断順序で一つのオクツリーフレームを読み出す。レベル0の最初のノードから出発して現在レベルのあらゆるノードを読み出した後、次のレベルのノード数はそれぞれのノードシンボルであらゆる1をカウントすることによって把握される。次のレベルで、ノードの数(nNodesInCurLevel)はストリームから読み出される。
もし、現在ノード(curTexture)に対するテクスチャー(またはカメラ)IDが親ノードにより定義されていないならば、テクスチャーIDもtextureContextIDにより定義されているテクスチャーIDに対する文脈を使用してストリームから読み出す。もし、0でない値が得られれば(textureIDが定義されていれば)、この値はまたつながるレベルであらゆる子ノードに適用される。あらゆるノードをデコーディングした後、textureIDは依然として相変らずtextureID値が割当てられていないオクツリーのリーフノードに割当てられる。
この章ではcontextIDによってC++型の文法表現を使用してオクツリー圧縮に使われた適応算術コーダを記述する。aa_decode()はcumul_freq[]関数である。PCTは2.7.1.6節に記述されたようなPCTのアレイである。
デコーディング手順の全体的な構造は2.7.1.5節に開示されている(また前述したエンコーディング手順を参考)。これは算術的にエンコーディングされた(圧縮された)TBVOモデルを構成するビットストリームからTBVOノードを獲得する方法を示す。
テクスチャーシンボルは一つの文脈だけでモデリングされる。これは単に一つのPTが使われることを意味する。このテーブルのサイズはnumOfTexturesの数に一つを加えたものと同じである。先ず、このテーブルは全部1に初期化される。許容可能なエントリ値の最大値は256と設定される。適応段階は32と設定される。このようなパラメータ値の組合わせによりテクスチャー番号をかなり可変的なストリームに適用することができる。
256個の相異なるノードシンボルが存在し、それぞれのシンボルは2×2×22進ボクセルアレイを表現する。対応するシンボルを互いに変換させる3D直交変換がこのようなアレイに適用される。
座標軸に対して90*n゜(n=0,1,2,3)だけ回転及び対称させる48個の固定された直交変換集合を想定すれば、このような行列は次のように数字順に与えられる。
N<512に対して単に一つの文脈だけ存在する。PTは全部1に初期化される。PTでシンボルの数は256である。適応段階では2である。最大蓄積頻度は8192である。
それぞれのクラスに対する基本成分の形態はテーブル10を使用して容易に得ることができる。基本成分は正確に変換IDが0(番号0は同じ変換に割当てられる)に対するシンボルである。
テーブル10.ノードシンボル、シンボルのクラス番号及びシンボルをこのようなクラスの固定された基本成分とする直交変換に対する結合ルックアップテーブル
シンプルテクスチャーはイメージ、対応する深さマップ、そしてカメラ説明(カメラの位置、方向及び形態、直交または遠近)で構成されたデータ構造である。一つのシンプルテクスチャーの表現容量はビルディングの正面のような客体に制限される。深さマップを有する正面イメージにより実質的な角度領域で正面視点を再構成できる。
前述された概念及び発明者が開発したいくつかを考慮して次のMPEG−4 AFXに使用するためのシンプルテクスチャー、ポイントテクスチャー、そしてオクツリーイメージのようなイメージ基盤フォーマットの集合を提案した。シンプルテクスチャー及びオクツリーイメージはアニメーションバージョンを有する。
深さイメージ構造は結合されるボックス、空間上の位置及びいくつかの他の情報と共にシンプルテクスチャーまたはポイントテクスチャーを規定する。深さイメージ集合は変換ノードと呼ばれる一つの構造の下に統合され、これにより多様な有用な表現を生成できる。これらのうち二つが最も広く使われ、これらは特定のMPEG−4名称を有してはいないが、実務上これらをボックステクスチャー(BoxTexture:BT)及び一般化されたボックステクスチャー(Generalized Box Texture:GBT)と称する。
より柔軟な表現及び速いレンダリングを有する多重解像度形態及びテクスチャーを利用するためにTBVOに基づいたオクツリーイメージ表現が開発された。TBVOの目標は2進体積オクツリー(Binary Volumetic Octree:BVO)の改善として速い視覚化が可能なより柔軟な表現/圧縮フォーマットを考案することである。TBVOは形態を表現するBVO、参照イメージ集合、及びオクツリーノードに対応するイメージインデックスなどの3つの主な成分で構成される。
255個のカメラで十分であると仮定し、インデックスに対して1バイトまで割り当てる。TBVOストリームはシンボルストリームである。あらゆるTBVOシンボルはBVOシンボルまたはテクスチャーシンボルである。テクスチャーシンボルはカメラインデックスを称し、カメラインデックスは“規定されていない”特定の番号またはコードである。
アニメーションバージョンはDIBRフォーマットの二つ−シンプルテクスチャーとオクツリーイメージだけを含む深さイメージ−に対して規定される。データサイズは3Dアニメーションにおいて重要な問題のうち一つである。ビデオストリームは自然と動映像バージョンに結合されうるので実質的なデータ減少を提供するこのような特定のフォーマットを選択する。
DIBRフォーマットはMPEG−4 AFXノード定義に詳細に記述されている。深さイメージは、シンプルテクスチャー(SimpleTexture)またはポイントテクスチャー(PointTexture)に対する円錐視点パラメータを決定するフィールドを含む。オクツリーイメージノードは形態と参照イメージフォーマットの集合が規定されたTBVO形態で客体を表現する。場面に独立的な情報はDIBRデータ構造の特別なフィールドに貯蔵され、これによりDIBR客体の相互作用を場面の残りの部分で補正できる。DIBRノードの定義は図26に図示されている。
−OpenGLによりセルをスクリーンにマッピングする。
−投影の最も大きい対角線の長さLを計算する(ピクセル単位)。
−D(スプラット径)をC・L/Nと算定する。
ここで、Nはセル面当り点個数の平均であり、Cは約1.3の発見定数である。
同じ方法がオクツリーイメージのレンダリングに適用される。ここでより粗いレベルの一つでオクツリーノードがスプラットサイズの前述した計算で使われる。しかし、オクツリーイメージに対して色相情報はボクセル集合に先にマッピングされねばならない。それぞれのボクセルは対応する参照イメージインデックスを有しているので、これは非常に容易に実施される。参照イメージでピクセル位置もオクツリーストリームのパーシング過程中に把握される。オクツリーイメージボクセルの色相が決定されてすぐスプラットサイズが算定され、OpenGLに基づいたレンダリングが前述したように使われる。
(登録商標)上で実施された。
多角形からDIBRフォーマットに変換する方法は以後に記述し、その後、モデリング、表現、そして相異なるDIBRフォーマットの圧縮結果を記述する。大部分のデータは深さイメージ及びオクツリーイメージに関するものである。このようなフォーマットは動映像バージョンを有して効果的に圧縮されることができる。提示されるモデルはいずれも直交カメラで構成された。これは直交カメラは一般的に‘小さな’客体を表現するのに適切な方法であるからである。距離がある環境の経済的なDIBR表現のために遠近カメラが大部分使われる。
深さイメージは簡単に得られたシンプルテクスチャーの集合である。たとえ深さマップを圧縮された形式で貯蔵できたとしても、形態において小さな歪曲がたびたびかなり目立つので無損失圧縮だけ許容される。
ポイントテクスチャーモデルは、前述したように参照平面への客体投影を利用して構成される。もし、これにより十分なサンプルが生成されていなければ(これは投影ベクターにほとんど垂直の表面部分に対する場合でありうる)、付加的なシンプルテクスチャーがより多くのサンプルを提供するために構成される。得られた点の集合はその後にポイントテクスチャー構造で再構成される。
本発明による深さイメージに基づくノードは、シンプルテクスチャーノード、ポイントテクスチャーノード、深さイメージノード、及びオクツリーイメージノードを含む。深さイメージノードは深さ情報と色相イメージとより構成される。色相イメージはシンプルテクスチャーノード及びポイントテクスチャーノードのうち選択される。
図26を参照すれば、シンプルテクスチャーノードはそれぞれのピクセルに対する色相を含む色相イメージが記録されるテクスチャーフィールド及びそれぞれのピクセルに対する深さ値が記録される深さフィールドで構成される。シンプルテクスチャーノードは断層のイメージ基盤表現(Image Based Representation:IBR)テクスチャーを定義する。ここで、テクスチャーは色相を有する平面イメージを意味する。
図26を参照すれば、ポイントテクスチャーノードは大きさフィールド、解像度フィールド、深さフィールド、及び色相フィールドで構成される。大きさフィールドにはイメージ平面の大きさ情報が記録される。大きさフィールドはイメージ平面の幅と高さとが記録される幅フィールド及び高さフィールドで構成される。イメージ平面の大きさは参照平面に投影された客体全体を含む大きさで設定される。
深さイメージノードを構成する視点情報は視点フィールド、視野フィールド、投影方法フィールド、及び距離フィールドを含む。
図36を参照すれば、オクツリーイメージノードはビットラッパー(Bitwrapper)によりカプセル化されている。それぞれのビットラッパーは一つのオクツリーイメージノードを含んでいる。シンプルテクスチャーノードで客体を表現する場合にオクツリーイメージノードは6個の深さイメージノードを有しており、それぞれの深さイメージノードにはシンプルテクスチャーノードが含まれている。これと異なり、ポイントテクスチャーノードで客体を表現する場合にはオクツリーイメージノードは1個の深さイメージノードを有する。
Claims (7)
- 記録媒体に記録されたコンピュータが読み出すことができるコードを読み出して具現する3次元客体表現装置において3次元客体を表現する3次元客体表現方法であって、
該3次元客体を複数の異なる視点から注視した2次元平面イメージ毎に、
前記2次元平面イメージを注視する視点の情報が記録される視点フィールドと、
前記視点から前記2次元平面イメージまでの視野領域が記録される視野フィールドと、
前記視点から前記2次元平面イメージまでの投影方法が記録される投影方法フィールドと、
前記視点から可視領域の近い境界平面までの距離及び前記視点から遠い境界平面までの距離が記録される距離フィールドと、
深さを有するテクスチャを定義するディテクスチャーフィールドとが設けられたデータの集合により前記3次元客体を表現し、
前記ディテクスチャーフィールドは、
前記2次元平面イメージを形成する各ピクセルに対する色相情報を含む色相イメージが記録されるテクスチャーフィールドと、
前記2次元平面イメージを形成する各ピクセルに対する深さ情報が記録された深さフィールドを含み、
前記深さフィールドに記録されている深さ情報の集合は前記深さ情報によってグレースケールで表現された2次元平面イメージに対応する深さイメージを形成し、
前記3次元客体が動映像客体である場合、前記深さ情報は静止イメージフレームであり、前記色相情報は複数のイメージフレーム列であることを特徴とする3次元客体表現方法。 - 前記視点フィールドは、
前記視点の位置が記録される位置フィールドと、
前記視点の方向が記録される方向フィールドとを含み、
前記位置は前記2次元平面イメージが存在する座標系の原点に対する相対的な位置であり、前記方向は所定の基準方向に対する相対的な回転量であることを特徴とする請求項1に記載の3次元客体表現方法。 - 前記投影方法は、前記視野領域が幅と高さとで表示される直交投影方法及び前記視野領域が水平角と垂直角とで表示される遠近投影方法を含むことを特徴とする請求項1に記載の3次元客体表現方法。
- 前記直交投影方法が選択された場合に前記視野領域の幅と高さとは各々前記2次元平面イメージの幅と高さに対応し、
前記遠近投影方法が選択された場合に、前記視野領域の水平角と垂直角は各々前記視点から前記2次元平面イメージに至る視線により水平面と垂直面とで形成される水平角及び垂直角であることを特徴とする請求項3に記載の3次元客体表現方法。 - 記録媒体に記録されたコンピュータが読み出すことができるコードを読み出して具現する3次元客体表現装置において3次元客体を表現する3次元客体表現方法であって、
前記3次元客体を複数の異なる視点から注視した2次元平面イメージ毎に、
前記2次元平面イメージを注視する視点の情報が記録される視点フィールドと、
前記視点から前記2次元平面イメージまでの視野領域が記録される視野フィールドと、
前記視点から前記2次元平面イメージまでの投影方法が記録される投影方法フィールドと、
前記視点から可視領域の近い境界平面までの距離及び前記視点から遠い境界平面までの距離が記録される距離フィールドと、
深さを有するテクスチャーを定義するディテクスチャーフィールドと、が設けられたデータの集合により前記3次元客体を表現し、
前記ディテクスチャーフィールドは、
前記2次元平面イメージを形成する各ピクセルに対する色相情報を含む色相イメージが記録されるテクスチャーフィールドと、
前記2次元平面イメージを形成する各ピクセルに対する深さ情報が記録された深さフィールドを含み、
前記深さフィールドに記録されている深さ情報の集合は前記深さ情報によってグレースケールで表現された2次元平面イメージに対応する深さイメージを形成し、
前記3次元客体が動映像客体である場合、前記色相情報は静止イメージフレームであり、前記深さ情報は複数のイメージフレーム列であることを特徴とする3次元客体表現方法。 - 記録媒体に記録されたコンピュータが読み出すことができるコードを読み出して具現する3次元客体表現装置において3次元客体を表現する3次元客体表現方法であって、
前記3次元客体を複数の異なる視点から注視した2次元平面イメージ毎に、
前記2次元平面イメージを注視する視点の情報が記録される視点フィールドと、
前記視点から前記2次元平面イメージまでの視野領域が記録される視野フィールドと、
前記視点から前記2次元平面イメージまでの投影方法が記録される投影方法フィールドと、
前記視点から可視領域の近い境界平面までの距離及び前記視点から遠い境界平面までの距離が記録される距離フィールドと、
深さを有するテクスチャーを定義するディテクスチャーフィールドとが設けられたデータの集合により前記3次元客体を表現し、
前記ディテクスチャーフィールドは、
前記2次元平面イメージを形成する各ピクセルに対する色相情報を含む色相イメージが記録されるテクスチャーフィールドと、
前記2次元平面イメージを形成する各ピクセルに対する深さ情報が記録された深さフィールドを含み、
前記深さフィールドに記録されている深さ情報の集合は前記深さ情報によってグレースケールで表現された2次元平面イメージに対応する深さイメージを形成し、
前記3次元客体が動映像客体である場合、前記色相情報及び深さ情報は複数のイメージフレーム列であることを特徴とする3次元客体表現方法。 - 記録媒体に記録されたコンピュータが読み出すことができるコードを読み出して具現する3次元客体表現装置において3次元客体を表現する3次元客体表現方法であって、
前記3次元客体を複数の異なる視点から注視した2次元平面イメージ毎に、
前記2次元平面イメージを注視する視点の情報が記録される視点フィールドと、
前記視点から前記2次元平面イメージまでの視野領域が記録される視野フィールドと、
前記視点から前記2次元平面イメージまでの投影方法が記録される投影方法フィールドと、
前記視点から可視領域の近い境界平面までの距離及び前記視点から遠い境界平面までの距離が記録される距離フィールドと、
深さを有するテクスチャーを定義するディテクスチャーフィールドとが設けられたデータの集合により前記3次元客体を表現し、
前記ディテクスチャーフィールドは、
前記2次元平面イメージの幅(width)情報が記録される幅フィールドと、
前記2次元平面イメージの高さ(height)情報が記録される高さフィールドと、
前記2次元平面イメージを形成する各ピクセルに対する深さ情報の解像度が記録される解像度フィールドと、
前記2次元平面イメージを形成する各ピクセルに対する深さ情報が記録される深さフィールドと、
前記2次元平面イメージを形成する各ピクセルに対する色相情報が記録される色相フィールドとを含み、
前記深さ情報は前記イメージ平面に投射された前記ピクセルの数とそれぞれのピクセルに対する深さ情報が順次に記録された行列であり、
前記色相情報は前記イメージ平面に投射されたピクセルそれぞれに対応する色相情報が順次に記録された行列であることを特徴とする3次元客体表現方法。
Applications Claiming Priority (10)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US33316701P | 2001-11-27 | 2001-11-27 | |
US60/333,167 | 2001-11-27 | ||
US36254502P | 2002-03-08 | 2002-03-08 | |
US60/362,545 | 2002-03-08 | ||
US37656302P | 2002-05-01 | 2002-05-01 | |
US60/376,563 | 2002-05-01 | ||
US39530402P | 2002-07-12 | 2002-07-12 | |
US60/395,304 | 2002-07-12 | ||
KR2002-067971 | 2002-11-04 | ||
KR10-2002-0067971A KR100450823B1 (ko) | 2001-11-27 | 2002-11-04 | 깊이 이미지 기반 3차원 물체의 표현을 위한 노드 구조 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002344742A Division JP2004005373A (ja) | 2001-11-27 | 2002-11-27 | 深さイメージに基づく3次元物体を表現するためのノード構造 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2009251395A Division JP2010033594A (ja) | 2001-11-27 | 2009-10-30 | 深さイメージに基づく3次元客体を表現するための三次元客体表現方法 |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2006286024A JP2006286024A (ja) | 2006-10-19 |
JP2006286024A5 JP2006286024A5 (ja) | 2007-09-06 |
JP4832975B2 true JP4832975B2 (ja) | 2011-12-07 |
Family
ID=27532387
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002344742A Pending JP2004005373A (ja) | 2001-11-27 | 2002-11-27 | 深さイメージに基づく3次元物体を表現するためのノード構造 |
JP2006203922A Expired - Fee Related JP4832975B2 (ja) | 2001-11-27 | 2006-07-26 | 深さイメージに基づく3次元客体を表現するためのノード構造を記憶させた、コンピュータで読み出し可能な記録媒体 |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002344742A Pending JP2004005373A (ja) | 2001-11-27 | 2002-11-27 | 深さイメージに基づく3次元物体を表現するためのノード構造 |
Country Status (4)
Country | Link |
---|---|
EP (1) | EP1321893B1 (ja) |
JP (2) | JP2004005373A (ja) |
CN (1) | CN1218282C (ja) |
CA (1) | CA2413058C (ja) |
Families Citing this family (42)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100434545B1 (ko) | 2002-03-15 | 2004-06-05 | 삼성전자주식회사 | 홈네트워크로 연결된 가전기기들을 제어하는 방법 및 장치 |
KR100519780B1 (ko) | 2004-02-17 | 2005-10-07 | 삼성전자주식회사 | 3차원 체적 데이터 부호화/복호화 방법 및 장치 |
KR100695142B1 (ko) | 2004-03-08 | 2007-03-14 | 삼성전자주식회사 | 적응적 2의 n 제곱 진트리 생성방법 및 이를 이용한 3차원 체적 데이터 부호화/복호화 방법 및 장치 |
CN1681330B (zh) * | 2004-03-08 | 2010-07-21 | 三星电子株式会社 | 自适应2n叉树生成方法及3D体数据编码和解码方法和设备 |
KR100571846B1 (ko) * | 2004-12-16 | 2006-04-17 | 삼성전자주식회사 | 3차원 영상의 계층적 구조에 기반한 적응적 랜더링 장치및 방법과 그 방법을 수행하기 위한 컴퓨터 프로그램을저장하는 컴퓨터로 읽을 수 있는 기록매체 |
WO2006109980A1 (en) * | 2005-04-11 | 2006-10-19 | Samsung Electronics Co., Ltd. | Depth image-based representation method for 3d object, modeling method and apparatus, and rendering method and apparatus using the same |
KR100707206B1 (ko) * | 2005-04-11 | 2007-04-13 | 삼성전자주식회사 | 3차원 객체의 깊이영상 기반 표현 방법 및 이를 이용한모델링 및 렌더링 방법 및 장치 |
JP4650751B2 (ja) * | 2005-12-16 | 2011-03-16 | 株式会社Ihi | 三次元形状データの位置合わせ方法と装置 |
CN101331380B (zh) * | 2005-12-16 | 2011-08-03 | 株式会社Ihi | 三维形状数据的存储/显示方法和装置以及三维形状的计测方法和装置 |
DE112006003363B4 (de) * | 2005-12-16 | 2016-05-04 | Ihi Corporation | Verfahren und Vorrichtung zur Identifizierung der Eigenposition, und Verfahren und Vorrichtung zur Messung einer dreidimensionalen Gestalt |
WO2008022055A1 (en) * | 2006-08-11 | 2008-02-21 | Siemens Product Lifecycle Management Software Inc. | Visual file representation |
US9070178B2 (en) | 2006-08-11 | 2015-06-30 | Siemens Product Lifecycle Management Software Inc. | Method and system for organizing topology elements for better compression |
JP5380792B2 (ja) * | 2007-06-15 | 2014-01-08 | 株式会社Ihi | 物体認識方法および装置 |
US9641822B2 (en) | 2008-02-25 | 2017-05-02 | Samsung Electronics Co., Ltd. | Method and apparatus for processing three-dimensional (3D) images |
JP2011029998A (ja) * | 2009-07-27 | 2011-02-10 | Sony Corp | 画像記録装置、画像記録方法、及びプログラム |
US7961910B2 (en) | 2009-10-07 | 2011-06-14 | Microsoft Corporation | Systems and methods for tracking a model |
US8564534B2 (en) | 2009-10-07 | 2013-10-22 | Microsoft Corporation | Human tracking system |
US8963829B2 (en) | 2009-10-07 | 2015-02-24 | Microsoft Corporation | Methods and systems for determining and tracking extremities of a target |
CN102469248B (zh) * | 2010-11-12 | 2016-03-02 | 华晶科技股份有限公司 | 影像拍摄装置及其影像合成方法 |
CN102542601A (zh) * | 2010-12-10 | 2012-07-04 | 三星电子株式会社 | 一种用于3d对象建模的设备和方法 |
US9521418B2 (en) | 2011-07-22 | 2016-12-13 | Qualcomm Incorporated | Slice header three-dimensional video extension for slice header prediction |
US11496760B2 (en) | 2011-07-22 | 2022-11-08 | Qualcomm Incorporated | Slice header prediction for depth maps in three-dimensional video codecs |
US9288505B2 (en) | 2011-08-11 | 2016-03-15 | Qualcomm Incorporated | Three-dimensional video with asymmetric spatial resolution |
US9485503B2 (en) | 2011-11-18 | 2016-11-01 | Qualcomm Incorporated | Inside view motion prediction among texture and depth view components |
KR102366842B1 (ko) | 2013-04-08 | 2022-02-24 | 돌비 인터네셔널 에이비 | Lut를 인코딩하는 방법, lut를 디코딩하는 방법 및 대응하는 장치들 |
CN105205839B (zh) * | 2015-09-06 | 2018-03-30 | 哈尔滨工业大学 | 一种基于色彩退化的有限调色板生成方法 |
GB2558314B (en) * | 2017-01-02 | 2020-07-29 | Canon Kk | Improved attribute mapping to encode and decode 3D models |
EP3429207A1 (en) * | 2017-07-13 | 2019-01-16 | Thomson Licensing | A method and apparatus for encoding/decoding a colored point cloud representing the geometry and colors of a 3d object |
SG10201706752XA (en) * | 2017-08-17 | 2019-03-28 | Iko Pte Ltd | Systems and methods for analyzing cutaneous conditions |
CN109559343B (zh) * | 2017-09-27 | 2021-04-30 | 北京京东尚科信息技术有限公司 | 用于容器的图像处理方法和装置 |
US10089796B1 (en) * | 2017-11-01 | 2018-10-02 | Google Llc | High quality layered depth image texture rasterization |
KR101862677B1 (ko) * | 2018-03-06 | 2018-05-31 | (주)휴톰 | 3차원 탄성 모델 렌더링 방법, 장치 및 프로그램 |
WO2019132167A1 (ko) * | 2017-12-28 | 2019-07-04 | (주)휴톰 | 3차원 탄성 모델 렌더링 방법, 장치 및 프로그램 |
CN111566703B (zh) | 2018-01-17 | 2023-10-20 | 索尼公司 | 图像处理装置和方法 |
JP7348078B2 (ja) | 2018-02-08 | 2023-09-20 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ | 三次元データ符号化方法、三次元データ復号方法、三次元データ符号化装置、及び三次元データ復号装置 |
WO2019198636A1 (ja) | 2018-04-10 | 2019-10-17 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ | 三次元データ符号化方法、三次元データ復号方法、三次元データ符号化装置、及び三次元データ復号装置 |
EP3554082A1 (en) | 2018-04-11 | 2019-10-16 | InterDigital VC Holdings, Inc. | A method and device for coding the geometry of a point cloud |
CN108986205B (zh) * | 2018-06-08 | 2023-05-26 | 广州虎牙信息科技有限公司 | 一种绘制体素模型的方法、装置、设备和存储介质 |
CN111610751B (zh) * | 2020-05-21 | 2023-07-28 | 天津工业大学 | 过点集nurbs插值曲线的插值误差多次细分迭代计算方法 |
CN113342999B (zh) * | 2021-05-07 | 2022-08-05 | 上海大学 | 一种基于多层跳序树结构的变分辨率点云简化方法 |
US20230186500A1 (en) * | 2021-12-10 | 2023-06-15 | Varjo Technologies Oy | Image-based environment reconstruction |
CN117341206B (zh) * | 2023-10-08 | 2024-03-29 | 南京林业大学 | 一种基于八叉树的支撑结构生成方法 |
-
2002
- 2002-11-27 EP EP02258158A patent/EP1321893B1/en not_active Expired - Fee Related
- 2002-11-27 JP JP2002344742A patent/JP2004005373A/ja active Pending
- 2002-11-27 CA CA2413058A patent/CA2413058C/en not_active Expired - Fee Related
- 2002-11-27 CN CN 02159594 patent/CN1218282C/zh not_active Expired - Fee Related
-
2006
- 2006-07-26 JP JP2006203922A patent/JP4832975B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
CA2413058C (en) | 2012-01-17 |
JP2006286024A (ja) | 2006-10-19 |
CN1218282C (zh) | 2005-09-07 |
EP1321893A3 (en) | 2005-01-05 |
EP1321893A2 (en) | 2003-06-25 |
CA2413058A1 (en) | 2003-05-27 |
EP1321893B1 (en) | 2011-11-09 |
JP2004005373A (ja) | 2004-01-08 |
CN1430183A (zh) | 2003-07-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4832975B2 (ja) | 深さイメージに基づく3次元客体を表現するためのノード構造を記憶させた、コンピュータで読み出し可能な記録媒体 | |
JP3957620B2 (ja) | 深さイメージ基盤3次元客体を表現するための装置及び方法 | |
KR100450823B1 (ko) | 깊이 이미지 기반 3차원 물체의 표현을 위한 노드 구조 | |
RU2237283C2 (ru) | Устройство и способ представления трехмерного объекта на основе изображений с глубиной | |
RU2237284C2 (ru) | Способ генерирования структуры узлов, предназначенных для представления трехмерных объектов с использованием изображений с глубиной | |
KR100519780B1 (ko) | 3차원 체적 데이터 부호화/복호화 방법 및 장치 | |
EP1431919B1 (en) | Method and apparatus for encoding and decoding three-dimensional object data by using octrees | |
US7263236B2 (en) | Method and apparatus for encoding and decoding three-dimensional object data | |
Xu et al. | Introduction to point cloud compression | |
Levkovich-Maslyuk et al. | Depth image-based representation and compression for static and animated 3-D objects | |
CA2514655C (en) | Apparatus and method for depth image-based representation of 3-dimensional object | |
WO2023144445A1 (en) | A method, an apparatus and a computer program product for video encoding and video decoding | |
CA2517842A1 (en) | Node structure for representing 3-dimensional objects using depth image | |
US20230171427A1 (en) | Method, An Apparatus and a Computer Program Product for Video Encoding and Video Decoding | |
WO2023001623A1 (en) | V3c patch connectivity signaling for mesh compression | |
WO2023047021A2 (en) | A method, an apparatus and a computer program product for video encoding and video decoding | |
WO2024012765A1 (en) | A method, an apparatus and a computer program product for video encoding and video decoding | |
Bayakovski et al. | Depth Image-based Representations and Compression for Static and Animated 3D Objects | |
CH et al. | 7_, Decoder |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060726 |
|
RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20070417 |
|
RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20070419 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070719 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090630 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20090930 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20091005 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20091030 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20100209 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100430 |
|
A911 | Transfer of reconsideration by examiner before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20100520 |
|
A912 | Removal of reconsideration by examiner before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20101008 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20110921 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140930 Year of fee payment: 3 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
LAPS | Cancellation because of no payment of annual fees |