JP7609509B2 - メッシュ圧縮のための境界ｕｖ２ｘｙｚインデックスの予測コーディング - Google Patents

Description

関連出願の相互参照
関連出願の相互参照本出願は、２０２３年３月２５日に出願された米国仮特許出願第６３／３２３，８７４号及び２０２２年３月１６日に出願された米国特許出願第１８／１８５，０７６号からの優先権を主張するものであり、これらの開示は、その全体が参照により本明細書に組み込まれる。

技術分野
本開示は、高度ビデオコーディング技術のセットを対象とする。より具体的には、本開示は、効率的なメッシュ圧縮のための境界頂点のＵＶ－ｔｏ－ＸＹＺ（ＵＶ２ＸＹＺ）インデックスのコーディング方法を対象とする。

３Ｄキャプチャ、モデリング、及びレンダリングにおける進歩は、いくつかのプラットフォーム及びデバイスにわたる３Ｄコンテンツのユビキタスな存在が促進された。今日では、ある大陸で赤ちゃんの最初の一歩を撮影し、祖父母が別の大陸でその子どもを見て（そしておそらく交流し）、完全な没入体験を楽しむことができる。それにもかかわらず、そのような現実性を達成するために、モデルはますます洗練され、大量のデータがそれらのモデルの作成と使用にリンクされる。３Ｄメッシュは、そのような没入型コンテンツを表すために広く使用されている。

動的メッシュシーケンスは、時間とともに変化するかなりの量の情報からなり得るので、大量のデータを必要とし得る。したがって、かかるコンテンツを格納及び伝送するために効率的な圧縮技術が要求される。メッシュ圧縮標準ＩＣ、ＭＥＳＨＧＲＩＤ、ＦＡＭＣは、以前にＭＰＥＧによって開発されて、一定の接続性及び時間変化するジオメトリ及び頂点属性を有する動的メッシュに対処した。しかしながら、これらの標準は、時間変化する属性マップ及び接続性情報を考慮していない。ＤＣＣ（Ｄｉｇｉｔａｌ Ｃｏｎｔｅｎｔ Ｃｒｅａｔｉｏｎ：デジタルコンテンツ作成）ツールは通常、そのような動的メッシュを生成する。これに対して、特にリアルタイム制約下で、一定の接続性の動的メッシュを生成することは、ボリュメトリック取得技法にとって困難である。このタイプのコンテンツは、既存の標準によってサポートされていない。ＭＰＥＧは、時間と共に変化する接続性情報及び任意選択で時間と共に変化する属性マップを有する動的メッシュを直接扱うために新たなメッシュ圧縮標準を開発することを計画している。この標準は、リアルタイム通信、ストレージ、自由視点ビデオ、ＡＲ及びＶＲなどの様々なアプリケーションのための損失性圧縮及び無損失性圧縮を対象とする。ランダムアクセス及びスケーラブル／プログレッシブコーディングなどの機能も考慮される。

以下は、本開示の１つ以上の実施形態の基本的な理解を提供するために、そのような実施形態の簡略化された概要を提示する。この概要は、全ての考察された実施形態の広範な概観ではなく、全ての実施形態の主要又は重要な要素を識別することも、いずれか又は全ての実施形態の範囲を線引きすることも意図されていない。その唯一の目的は、後に提示されるより詳細な説明の前置きとして、本開示の１つ以上の複数の実施形態のいくつかの概念を簡略化された形で提示することである。

本開示は、効率的なメッシュ圧縮のための境界頂点のＵＶ２ＸＹＺインデックスの方法を提供する。

いくつかの実施形態によれば、少なくとも１つのプロセッサによって実行される方法が提供される。方法は、エンコーダからコーディングされたビデオビットストリーム（ｃｏｄｅｄ ｖｉｄｅｏ ｂｉｔｓｔｒｅａｍ）（コード化ビデオビットストリーム）を受信するステップを含む。方法はさらに、コード化ビデオビットストリームから、ボリュメトリックオブジェクトの１つ以上の表面を記述する複数のポリゴンを備えるメッシュを取り出すステップを含む。方法はさらに、ＵＶ－ｔｏ－ＸＹＺインデックスアレイ内の別のインデックスに含まれる少なくとも１つの以前にコーディングされた値から、ＵＶ－ｔｏ－ＸＹＺインデックスアレイのインデックスの現在の値を予測するステップであって、ＵＶ－ｔｏ－ＸＹＺインデックスアレイが、メッシュに関連付けられた各２次元（２Ｄ）ＵＶ頂点をメッシュに関連付けられた３次元（３Ｄ）ＸＹＺ頂点に対応させる複数のインデックスを含む、ステップを含む。方法はさらに、ＵＶ－ｔｏ－ＸＹＺインデックスアレイのインデックスの現在の値に関連付けられた予測残差を導出するステップを含む。方法はさらに、ＵＶ－ｔｏ－ＸＹＺインデックスアレイのインデックスの予測された現在の値と導出された予測残差とに基づいて境界ＵＶ座標を再構成するステップを含む。

いくつかの実施態様によれば、装置は、プログラムコードを格納するように構成された少なくとも１つのメモリと、プログラムコードを読み込んで、プログラムコードによって命令されるように作動するように構成された少なくとも１つのプロセッサと、を備える。プログラムコードは、少なくとも１つのプロセッサに、エンコーダからコーディングされたビデオビットストリームを受信させるように構成された受信コードを含む。プログラムコードはさらに、少なくとも１つのプロセッサに、コード化ビデオビットストリームから、ボリュメトリックオブジェクトの１つ以上の表面を記述する複数のポリゴンを備えるメッシュを取り出させるように構成された取り出しコードを備える。プログラムコードはさらに、少なくとも１つのプロセッサに、ＵＶ－ｔｏ－ＸＹＺインデックスアレイ内の別のインデックスに含まれる少なくとも１つの以前にコーディングされた値から、ＵＶ－ｔｏ－ＸＹＺインデックスアレイのインデックスの現在の値を予測させるように構成された予測コードであって、ＵＶ－ｔｏ－ＸＹＺインデックスアレイが、メッシュに関連付けられた各２次元（２Ｄ）ＵＶ頂点をメッシュに関連付けられた３次元（３Ｄ）ＸＹＺ頂点に対応させる複数のインデックスを含む、予測コードを含む。プログラムコードはさらに、少なくとも１つのプロセッサに、ＵＶ－ｔｏ－ＸＹＺインデックスアレイのインデックスの現在の値に関連付けられた予測残差を導出させるように構成された導出コードを含む。プログラムコードはさらに、少なくとも１つのプロセッサに、ＵＶ－ｔｏ－ＸＹＺインデックスアレイのインデックスの予測された現在の値と導出された前記予測残差とに基づいて境界ＵＶ座標を再構成させるように構成された再構成コードを含む。

いくつかの実施形態によれば、非一時的コンピュータ可読記憶媒体は、少なくとも１つのプロセッサによって実行されたとき、少なくとも１つのプロセッサに、エンコーダからコード化ビデオビットストリームを受信させる命令を記憶する。命令は、少なくとも１つのプロセッサに、コード化ビデオビットストリームから、ボリュメトリックオブジェクトの１つ以上の表面を記述する複数のポリゴンを備えるメッシュを取り出させる。命令はさらに、少なくとも１つのプロセッサに、ＵＶ－ｔｏ－ＸＹＺインデックスアレイ内の別のインデックスに含まれる少なくとも１つの以前にコーディングされた値から、ＵＶ－ｔｏ－ＸＹＺインデックスアレイのインデックスの現在の値を予測させ、ＵＶ－ｔｏ－ＸＹＺインデックスアレイが、メッシュに関連付けられた各２次元（２Ｄ）ＵＶ頂点をメッシュに関連付けられた３次元（３Ｄ）ＸＹＺ頂点に対応させる複数のインデックスを含む。命令はさらに、少なくとも１つのプロセッサに、ＵＶ－ｔｏ－ＸＹＺインデックスアレイのインデックスの現在の値に関連付けられた予測残差を導出させる。命令はさらに、少なくとも１つのプロセッサに、ＵＶ－ｔｏ－ＸＹＺインデックスアレイのインデックスの予測された現在の値と導出された予測残差とに基づいて境界ＵＶ座標を再構成させる。

追加の実施形態は、以下の説明に記載され、部分的に、説明から明らかになり、及び／又は本開示の提示された実施形態の実施によって習得され得る。

開示された主題のさらなる特徴、性質、及び様々な利点は、以下の詳細な説明及び添付の図面からより明らかになるであろう。
図１は、いくつかの実施形態による、通信システムの簡略化されたブロック図を模式的に示す図である。 図２は、いくつかの実施形態による、ストリーミングシステムの簡略化されたブロック図を模式的に示す図である。 図３は、いくつかの実施形態による、ビデオエンコーダ及びデコーダの簡略化されたブロック図を模式的に示す図である。 図４は、いくつかの実施形態による、３Ｄメッシュセグメントから２ＤチャートへのＵＶパラメータ化マッピングのプロセスを示す図である。 図５は、いくつかの実施形態による、３Ｄメッシュセグメントが複数の別個のチャートにマッピングされる、異なるＵＶパラメータ化の図である。 図６は、いくつかの実施形態による、複数のチャートを伴う一般的２ＤＵＶアトラスを示す図である。 図７は、いくつかの実施形態による、２Ｄチャートにおける境界頂点を示す図である。 図８は、いくつかの実施形態による、効率的なメッシュ圧縮のために境界頂点のＵＶ２ＸＹＺインデックスをコーディングするためのプログラムによって実行されるステップを示す動作フローチャートである。 図９は、実施形態を実施するのに適したコンピュータシステムの図である。

例示的な実施形態の以下の詳細な説明は、添付の図面を参照する。異なる図面における同じ参照番号は、同じ又は類似の要素を識別することがある。

メッシュは、ボリュメトリックオブジェクトの表面を記述するいくつかのポリゴンを含み得る。３Ｄ空間内のその頂点、及び頂点がどのように接続されるかの情報は、接続性情報と称される各ポリゴンを定義することができる。任意選択で、色、法線などの頂点属性をメッシュ頂点に関連付けることができる。属性はまた、２Ｄ属性マップを用いてメッシュをパラメータ化するマッピング情報を利用することによって、メッシュの表面に関連付けられ得る。かかるマッピングは、ＵＶ座標又はテクスチャ座標と称され、メッシュ頂点に関連付けられたパラメータ座標のセットを使用して定義され得る。２Ｄ属性マップは、テクスチャ、法線、変位などの高解像度属性情報を記憶するために使用され得る。高解像度属性情報は、テクスチャマッピングやシェーディングなどのさまざまな目的に使用できる。

上述したように、３Ｄメッシュ又は動的メッシュは、時間とともに変化する（ｃｈａｎｇｉｎｇ ｏｖｅｒ ｔｉｍｅ）大量の情報から構成され得るので、大量のデータを必要とし得る。特に、境界情報はメッシュ全体のうちの重要な部分である。したがって、境界情報を効率的に圧縮するための効率的な圧縮技術が必要とされる。

本開示では、メッシュ圧縮における境界のＵＶ２ＸＹＺ（ＵＶ－ｔｏ－ＸＹＺ）インデックスアレイのコーディングのためのいくつかの方法が提案される。それらは、個々に、又は任意の形態の組み合わせによって適用され得る。本方法は、メッシュの１つのフレームのみが存在する、又はメッシュコンテンツが経時的に変化しない、静的メッシュに適用され得る。

提案された方法は、別々に又は任意の順序で組み合わせて用いられることができる。さらに、方法（又は実施形態）、エンコーダ、及びデコーダの各々は、処理回路（例えば、１つ以上のプロセッサ、又は１つ以上の集積回路）によって実装され得る。一実施例では、１つ以上のプロセッサは、非一時的コンピュータ可読記憶媒体に格納されたプログラムを実行する。

境界頂点の総数がＮであり、一意のｘｙｚ座標を持つ境界頂点の数がＭ（Ｍ≦Ｎ）であるとする。ＵＶ２ＸＹＺは長さがＮの１Ｄアレイであり、アレイ内の各要素は、一意のｘｙｚ座標に対するインデックスを示し、例えば、ｉ＝０，１，…，Ｎ－１についてＵＶ２ＸＹＺ［ｉ］∈｛０，１，…，Ｍ－１｝である。

ＵＶ２ＸＹＺは、各セグメントがチャートのＵＶ２ＸＹＺインデックスを含むセグメントに分離され得る。

ＵＶ２ＸＹＺのアレイを無損失でコーディングする複数の方法がある。

図１～図２を参照して、本開示のエンコーディング構造及びデコーディング構造を実装するための本開示の実施形態が説明される。

図１は、本開示の一実施形態による通信システム１００の簡略化されたブロック図を示す。システム１００は、ネットワーク１５０を介して相互接続された少なくとも２つの端末１１０、１２０を含み得る。データの一方向伝送のために、第１端末１１０は、ネットワーク１５０を介して他の端末１２０に伝送するためのローカル位置で、メッシュを含むビデオデータをコーディングし得る。第２端末１２０は、ネットワーク１５０から他方の端末のコーディングされたビデオデータを受信し、コーディングされたデータをデコードし、復元されたビデオデータを表示することができる。一方向性データ伝送は、メディア提供アプリケーション等において一般的であり得る。

図１は、例えば、テレビ会議中に発生し得るコーディングビデオの双方向伝送をサポートするために設けられた第２端末ペア１３０、１４０を示す。データの双方向伝送のために、各端末１３０，１４０は、ネットワーク１５０を介して他方の端末に伝送するために、ローカル位置で捕捉されたビデオデータをコーディングし得る。各端末１３０，１４０はまた、他の端末によって送信されたコーディングビデオデータを受信することができ、コーディングビデオデータをデコードすることができ、復元されたビデオデータをローカル表示装置に表示することができる。

図１において、端末１１０～１４０は、サーバ、パーソナルコンピュータ、及びスマートフォン、及び／又は任意の他のタイプの端末であり得る。。例えば、端末１１０～１４０は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤ、及び／又は専用のテレビ会議装置であることができる。ネットワーク１５０は、例えば、有線及び／又は無線通信ネットワークを含む、端末１１０～１４０間でコーディングされたビデオデータを伝達する任意の数のネットワークを表す。通信ネットワーク１０５は、回線交換チャネル及び／又はパケット交換チャネルでデータを交換することができる。代表的なネットワークには、テレコミュニケーションネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク及び／又はインターネットが含まれる。本説明の目的のためには、以下に説明しない限り、ネットワーク１５０のアーキテクチャ及びトポロジーは本発明の動作には重要ではない可能性がある。

図２は、開示された主題のアプリケーションの例として、ストリーミング環境におけるビデオエンコーダ及びデコーダの配置を示す。開示された主題は、例えば、ビデオ会議、デジタルＴＶや、ＣＤ、ＤＶＤ、メモリースティック等を含むデジタルメディアへの圧縮ビデオの保存等を含む、他のビデオ対応アプリケーションと共に使用され得る

図２に示すように、ストリーミングシステム２００は、ビデオソース２０１及びエンコーダ２０３を含むキャプチャサブシステム（２１３）を含み得る。ストリーミングシステム２００は、少なくとも１つのストリーミングサーバ２０５及び／又は少なくとも１つのストリーミングクライアント２０６をさらに含み得る。

ビデオソース２０１は、例えば、３Ｄメッシュ及び３Ｄメッシュに関連付けられたメタデータを含むストリーム２０２を作成することができる。ビデオソース２０１は、例えば、３Ｄセンサ（例えば、深度センサ）又は３Ｄ撮像技術（例えば、（１つ以上の）デジタルカメラ）と、３Ｄセンサ又は３Ｄ撮像技術から受信したデータを使用して３Ｄメッシュを生成するように構成されたコンピューティングデバイスとを含み得る。エンコードされたビデオビットストリームと比較して高いデータ量を有し得るサンプルストリーム２０２は、ビデオソース２０１に結合されたエンコーダ２０３によって処理され得る。エンコーダ２０３は、以下でより詳細に説明するように、開示される主題の態様を可能にするか又は実装するために、ハードウェア、ソフトウェア、又はそれらの組合せを含み得る。エンコーダ２０３はまた、エンコードされたビデオビットストリーム２０４を生成し得る。圧縮されていないストリーム２０２と比較してより低いデータ量を有し得るエンコードされたビデオビットストリーム２０４は、将来の使用のためにストリーミングサーバ２０５上に記憶され得る。１つ以上のストリーミングクライアント２０６は、ストリーミングサーバ２０５にアクセスして、エンコードされたビデオビットストリーム２０４のコピーであり得るビデオビットストリーム２０９を取り出すことができる

ストリーミングクライアント２０６は、ビデオデコーダ２１０及びディスプレイ２１２を含むことができる。ビデオデコーダ２１０は、例えば、エンコードされたビデオビットストリーム２０４の入力コピーであるビデオビットストリーム２０９をデコードし、ディスプレイ２１２又は他のレンダリングデバイス（図示せず）上でレンダリング可能な出力ビデオサンプルストリーム２１１を作成することができる。いくつかのストリーミングシステムでは、ビデオビットストリーム２０４、２０９は、特定のビデオコーディング／圧縮標準に従ってエンコードされることができる。

図３は、エンコーダ及びデコーダを使用する動的メッシュ圧縮及びメッシュ再構成のためのフレームワーク３００の例示的な図である。入力メッシュの各フレームは、一連の動作、例えば、追跡、再メッシュ化、パラメータ化、ボクセル化によって前処理され得る。これらの動作は、エンコーダのみであることができ、それらがデコードプロセスの一部ではない可能性がある。その後、２Ｄ ＵＶアトラスを有するメッシュを得ることができ、メッシュの各頂点は、２Ｄアトラス上に１つ以上の関連付けられたＵＶ座標を有する。その後、メッシュは、２Ｄアトラス上でサンプリングすることによって、占有マップ、幾何学マップ、及び属性マップを含む、複数のマップに変換され得る。その後、これらの２Ｄマップは、ＨＥＶＣ、ＶＶＣ、ＡＶ１、ＡＶＳ３などの任意のビデオ／画像コーデックによってコーディングされ得る。デコーダ側では、メッシュは、デコードされた２Ｄマップから再構成され得る。再構成されたメッシュに対して任意の後処理及びフィルタリングを適用することもできる。他のメタデータは、３Ｄメッシュ再構成の目的のためにデコーダ側にシグナリングされ得る。占有マップは、各チャートの境界頂点がシグナリングされる場合、デコーダ側から推測され得る。

図３に示すように、フレームワーク３００は、エンコーダ３０１及びデコーダ３５１を含むことができる。エンコーダ３０１は、１つ以上の入力メッシュ３０５、ＵＶアトラス３１０を有する１つ以上のメッシュ、占有マップ３１５、幾何学マップ３２０、属性マップ３２５、及びメタデータ３３０を含むことができる。デコーダ３５１は、デコードされた占有マップ３３５、デコードされた幾何学マップ３４０、デコードされた属性マップ３４５、デコードされたメタデータ３５０、及び再構成されたメッシュ３６０を含み得る。

本開示の一態様によれば、入力メッシュ３０５は１つ以上のフレームを含み得、１つ以上のフレームの各々は、一連の動作によって前処理され、ＵＶアトラス３１０を有するメッシュを生成するために使用され得る。一例として、前処理動作は、追跡、パラメータ化、再メッシュ化、ボクセル化などを含んでもよく、これらに限定されなくてもよい。いくつかの実施形態では、前処理動作は、エンコーダ側でのみ実行され、デコーダ側では実行されなくてもよい。

ＵＶアトラス３１０を有するメッシュは、２Ｄメッシュであり得る。ＵＶアトラスを有する２Ｄメッシュは、メッシュの各頂点が２Ｄアトラス上のＵＶ座標に関連付けられ得るメッシュであり得る。ＵＶアトラス３１０を有するメッシュは、処理され、サンプリングに基づいて複数のマップに変換され得る。一例として、ＵＶアトラス３１０は、ＵＶアトラスを有する２Ｄメッシュのサンプリングに基づいて、処理され、占有マップ、幾何学マップ、及び属性マップに変換され得る。生成された占有マップ３３５、幾何学マップ３４０、及び属性マップ３４５は、適切なコーデック（たとえば、ＨＶＥＣ、ＶＶＣ、ＡＶ１など）を使用してエンコードされ、デコーダに送信され得る。いくつかの実施形態では、メタデータ（例えば、接続性情報など）もデコーダに送信され得る。

一態様によれば、デコーダ３５１は、エンコードされた占有マップ、幾何学マップ、及び属性マップをエンコーダから受信することができる。デコーダ３５１は、本明細書で説明する実施形態に加えて、適切な技法及び方法を使用して、占有マップ、幾何学マップ、及び属性マップをデコードすることができる。一実施形態において、デコーダ３５１は、デコードされた占有マップ３３５、デコードされた幾何学マップ３４０、デコードされた属性マップ３４５、及びデコードされたメタデータ３５０を生成し得る。入力メッシュ３０５は、１つ以上の再構成フィルタ及び技法を使用して、デコードされた占有マップ３３５、デコードされた幾何学マップ３４０、デコードされた属性マップ３４５、及びデコードされたメタデータ３５０に基づいて、再構成されたメッシュ３６０に再構成され得る。いくつかの実施形態では、メタデータ３３０はデコーダ３５１に直接送信されることができ、デコーダ３５１はメタデータを使用して、デコードされた占有マップ３３５、デコードされた幾何学マップ３４０、及びデコードされた属性マップ３４５に基づいて再構成されたメッシュ３６０を生成し得る。再メッシュ化、パラメータ化、追跡、ボクセル化などを含むがこれらに限定されないポストフィルタリング技法も、再構成されたメッシュ３６０に適用することができる。

いくつかの実施形態では、３Ｄメッシュは、いくつかのセグメント（又はパッチ／チャート）に区分され得る。各セグメントは、それらの幾何学、属性、及び接続性情報に関連付けられた接続された頂点のセットを含み得る。図４に示すように、ＵＶパラメータ化プロセスは、メッシュセグメントを２Ｄ ＵＶアトラス内の２Ｄチャート上にマッピングする。メッシュセグメント内の各頂点には、２Ｄ ＵＶアトラス内の２Ｄ ＵＶ座標が割り当てられる。２Ｄチャートの頂点は、それらの３Ｄ チャートのカウンターパートとして接続されたコンポーネントを形成する。各頂点の幾何学又はジオメトリ（ｇｅｏｍｅｔｒｙ）、属性、及び接続性情報は、それらの３Ｄカウンターパートからも継承され得る。

３Ｄメッシュセグメントは、複数の別個の２Ｄチャートにマッピングされ得る。この場合、３Ｄにおける頂点は、２ＤＵＶアトラスにおける複数の頂点に対応することができる。図５に示されるように、同じ３Ｄメッシュセグメントは、２Ｄ ＵＶアトラスにおいて、単一チャートの代わりに２つの２Ｄチャートにマッピングされる。３Ｄ頂点ｖ_１及びｖ_４は２つの２Ｄ対応をそれぞれ有する。

３Ｄメッシュの一般的な２Ｄ ＵＶアトラスは、図６に示されるような複数のチャートから成ることができ、各チャートは、それらの３Ｄ幾何学、属性、及び接続性情報に関連付けられた複数の（通常、３つ以上の）頂点を含み得る。

境界頂点は、２Ｄ ＵＶ空間において定義される。図７に示すように、塗りつぶされた頂点は、連結コンポーネント（パッチ／チャート）の境界エッジ上にあるので、境界頂点である。境界エッジは、エッジが１つの三角形内にのみ現れるかどうかをチェックすることによって決定され得る。境界頂点の以下の情報は重要であり、ビットストリームにおいてシグナリングされるべきである。
＊ ジオメトリ情報、即ち、３Ｄ ｘｙｚ座標。
＊ ２Ｄ ＵＶ座標。

図５に示すように、３Ｄにおける境界頂点が２ＤＵＶアトラスにおける複数の頂点に対応する場合、３ＤＸＹＺから２ＤＵＶへのマッピングは１対複数であってもよい。したがって、ＵＶ－ｔｏ－ＸＹＺ（又はＵＶ２ＸＹＺと呼ばれる）インデックスが、マッピング関数を示すためにシグナリングされ得る。ＵＶ２ＸＹＺは、各２Ｄｕｖ頂点を３Ｄｘｙｚ頂点に対応させるインデックスの１Ｄアレイである。

いくつかの実施形態では、ＵＶ－ｔｏ－ＸＹＺインデックスは、ＵＶ－ｔｏ－ＸＹＺインデックスアレイのインデックスであり得、これは、１つ以上の２ＤＵＶ座標から１つ以上の３ＤＸＹＺ座標へのマッピング関数を示す複数の要素を含み得る。例えば、アレイ内の要素は、特定のＵＶ座標に対応する１つ以上の一意のＸＹＺ座標へのインデックスを示すことができる。

いくつかの実施形態では、予測コーディングが適用される。ＵＶ２ＸＹＺの現在の値は、ＵＶ２ＸＹＺアレイ内の以前にコーディングされた値から予測される。現在の予測値ＵＶ２ＸＹＺ［ｉ］を、ＵＶ２ＸＹＺ_ｐ［ｉ］と表す。

一実施形態では、ＵＶ２ＸＹＺ［ｉ］の現在の値は、ＵＶ２ＸＹＺにおいて以前にコーディングされた値から予測され、例えばＵＶ２ＸＹＺ_ｐ［ｉ］＝ＵＶ２ＸＹＺ［ｉ－１］である。

別の実施形態では、ＵＶ２ＸＹＺ［ｉ］の現在の値が予測を有さない場合、予測子は定数値として設定され得る。例えば、チャートにおけるＵＶ２ＸＹＺの第１値は、適切な予測子を有さない場合があり、したがって、ＵＶ２ＸＹＺ_ｐ［０］は、０に設定され得る。

別の実施形態では、ＵＶ２ＸＹＺ［ｉ］の現在の値は複数の予測子を有し得る。この場合、予測子候補リストは、どの予測子が使用されるかを示すためにシグナリングされるインデックスを用いて確立され得る。一例では、最後の２つのコーディングされたＵＶ２ＸＹＺ値が、かかる候補リストを形成するために使用され得る。２つの予測子のうちのどちらがＵＶ２ＸＹＺ［ｉ］の現在の値を予測するために使用されるかを示すために、１ビットインデックスがシグナリングされる。

別の実施形態では、ＵＶ２ＸＹＺ［ｉ］の現在の値は複数の予測子を有し得る。この場合、これらの予測子の何らかの加重平均が予測のために使用され得る。例えば、全ての予測子の平均が使用される。

元のＵＶ２ＸＹＺと予測子との間の予測残差、即ち、ＵＶ２ＸＹＺ_ｄ［ｉ］＝ＵＶ２ＸＹＺ［ｉ］－ＵＶ２ＸＹＺ_ｐ［ｉ］は、その後、エントロピーコーデックによって無損失な方法でコーディングされ得る。

一実施形態において、予測残差は、固定長コーディングによってコーディングされる。ビット長は、全てのチャートについて高レベルシンタックステーブルにおいてコーディングされるか、又は各チャートについて異なるようにコーディングされ得る。

他の実施形態では、予測残差は、ユーナリーコーディングによってコーディングされる。

他の実施形態では、予測残差は、指数ゴロムコーディングによってコーディングされる。

他の実施形態では、予測残差は、以下のシンタックス表１に示されるようなシンタックス要素によってコーディングされ得る。

１つ以上の例では、変数ｐｒｅｄｉｃｔｉｏｎ＿ｒｅｓｉｄｕａｌ＿ｓｉｇｎは、予測残差の符号ビット（ｓｉｇｎ ｂｉｔ）を特定し得る。１つ以上の例では、変数ｐｒｅｄｉｃｔｉｏｎ＿ｒｅｓｉｄｕａｌ＿ａｂｓ＿ｅｑ１は、予測残差の絶対値が１に等しいか否かを特定し得る。１つ以上の例では、変数ｐｒｅｄｉｃｔｉｏｎ＿ｒｅｓｉｄｕａｌ＿ａｂｓ＿ｍｉｎｕｓ２は、予測残差の絶対値マイナス２を特定することができる。

１つ以上の実施形態によれば、デコーダ側で、ＵＶ２ＸＹＺの予測残差は、以下のように、上記のシンタックス要素から導出され得る：

その後、元のＵＶ２ＸＹＺ値は、ＵＶ２ＸＹＺ［ｉ］＝ＵＶ２ＸＹＺ_ｄ［ｉ］＋ＵＶ２ＸＹＺ_ｐ［ｉ］によって回復され得る。

別の実施形態では、予測残差は、以下のシンタックス表２に示されるようなシンタックス要素によってコーディングされ得る。

１つ以上の例では、変数ｐｒｅｄｉｃｔｉｏｎ＿ｒｅｓｉｄｕａｌ＿ｅｑ１は、予測残差が１に等しいか否かを特定し得る。１つ以上の例では、変数ｐｒｅｄｉｃｔｉｏｎ＿ｒｅｓｉｄｕａｌ＿ｅｑ＿ｍｉｎｕｓ１は、予測残差が－１に等しいか否かを特定し得る。１つ以上の例では、変数ｐｒｅｄｉｃｔｉｏｎ＿ｒｅｓｉｄｕａｌ＿ｓｉｇｎは、予測残差の符号ビットを特定し得る。１つ以上の例では、変数ｐｒｅｄｉｃｔｉｏｎ＿ｒｅｓｉｄｕａｌ＿ａｂｓ＿ｍｉｎｕｓ２は、予測残差の絶対値マイナス２を特定し得る。

１つ以上の実施形態によれば、デコーダ側で、ＵＶ２ＸＹＺの予測残差は、以下のように、上記のシンタックス要素から導出され得る。

その後、元のＵＶ２ＸＹＺは、ＵＶ２ＸＹＺ［ｉ］＝ＵＶ２ＸＹＺ_ｄ［ｉ］＋ＵＶ２ＸＹＺ_ｐ［ｉ］によって回復され得る。

頂点ストレージの性質に起因して、隣り合う頂点のインデックスをＵＶ２ＸＹＺアレイに割り当てるとき、隣り合うＵＶ２ＸＹＺ値は、概して、１によるインデックス差を有する。しばしば、ある範囲に対して、単調な増加又は減少傾向を示す。したがって、ＵＶ２ＸＹＺアレイは、一般的な方法として以下の形式で表すことができる：
（ａ，ａ＋１，ａ＋２，．．．，ａ＋ｎ_ａ，）（ｂ，ｂ－１，ｂ－２，．．．．，ｂ－ｎ_ｂ）（ｃ，ｃ＋１，ｃ＋２，．．．．，ｃ＋ｎ_ｃ），．．．
ここで、いくつかのサブ配列に分けることができる。各シーケンスは、＋１又は－１のステップを有する連続インデックスからなる。

したがって、ＵＶ２ＸＹＺアレイは、ランレングス方向のタプルとして表され、コーディングされ得る：
（ａ，ｎ_ａ，１），（ｂ，ｎ_ｂ，－１），（ｃ，ｎ_ｃ，１），．．．

１つ以上の例では、ＵＶ２ＸＹＺアレイは、｛１００，１０１，１０２、９９，９８，９７，９６，１０３，１０４｝であり得る。上記の形式では、このアレイは、等価的に（１００，２，１）、（９９，３，－１）、（１０３，１，１）と書くことができる。

１つ以上の実施形態によれば、（ＲＵＮ，ＬＥＮ，ＤＩＲ）のタプルは、次のように定義することができる。変数ＲＵＮは、ランにおける開始インデックスであり得る。変数ＬＥＮは、ランの長さから１を引いたものであり得る。変数ＤＩＲは、ランの方向（例えば、増加に対して１、減少に対して－１）であり得る。１つ以上の例では、タプルは異なる方法でコーディングされ得る。例えば、変数ＲＵＮは、固定長によってコーディングされ得、ここで、ビット長は、一意のｘｙｚ境界頂点の数（たとえば［ｌｏｇ_２Ｍ］）。１つ以上の例では、変数ＬＥＮは、固定長によってコーディングされ得、ここで、ビット長は、現在チャート中のｕｖ境界頂点の数によって決定され得る（たとえば、［ｌｏｇ_２Ｎ_ｊ］）、ここでＮ_ｊは、ｊ^ｔｈチャート内のｕｖ境界頂点の数である。１つ以上の例では、変数ＤＩＲは、１ビットバイパスコーディングによってコーディングされ得る。別の実施形態では、ＤＩＲは、コンテキストを用いた算術コーディングによってコーディングされ得る。

ＵＶ２ＸＹＺは境界ループであるので、ランが線形アレイの２つの端部によって分割されることが起こる。例えば、（ａ＋２，ａ＋３，ａ＋４，ａ，ａ＋１）は、最初と最後の要素が接続されているので、単一のタプルであるはずである。しかし、アルゴリズムは、２つのラン、即ち、（ａ＋２，２，１）及び（ａ，１，１）を有すると考えることができる。

エンコーダは、その後、ＵＶ２ＸＹＺが分割ランを有しないことを確実にするためにインデックスを再順序付けすることができ、例えば、上記のアレイは、（ａ，ａ＋１，ａ＋２，ａ＋３，ａ＋４）として再順序付けすることができ、その後、それは、単一タプル（ａ，４，１）によって表され得る。境界ＵＶ及び境界ＸＹＺは、この場合に対応して再順序付けされるべきである。

図８は、効率的なメッシュ圧縮のために境界頂点のＵＶ２ＸＹＺインデックスをコーディングするための例示的なプロセス８００のフローチャートである。いくつかの実装形態では、図８の１つ以上のプロセスブロックは、上記で説明した要素のいずれかによって実行され得る。

図８に示されているように、プロセス８００は、エンコーダにおいてコード化ビデオビットストリームを受信するステップを含み得る（ブロック８１０）。

図８にさらに示されるように、プロセス８００は、コード化ビデオビットストリームから動的メッシュを取り出すステップを含み得る（ブロック８２０）。

図８にさらに示されるように、プロセス８００は、ＵＶ－ｔｏ－ＸＹＺインデックスアレイ内の少なくとも１つの以前にコーディングされた値からＵＶ－ｔｏ－ＸＹＺインデックスアレイを予測するステップを含み得る（ブロック８３０）。

図８にさらに示すように、プロセス８００は、ＵＶ－ｔｏ－ＸＹＺインデックスアレイに関連付けられた予測残差を導出するステップを含み得る（ブロック８４０）。

図８にさらに示すように、プロセス８００は、予測されたＵＶ－ｔｏ－ＸＹＺインデックスアレイ及び導出された予測残差に基づいて境界ＵＶ座標を再構成することを含み得る（ブロック８５０）。

図８はプロセス８００の例示的なブロックを示しているが、いくつかの実装形態では、プロセス８００は、図８に示されているブロックよりも追加のブロック、より少ないブロック、異なるブロック、又は異なるように配置されたブロックを含み得る。さらに又はあるいは、プロセス８００のブロックのうちの２つ以上は、並行して実施され得る。

上述の技法は、コンピュータ可読命令を使用してコンピュータソフトウェアとして実装され、１つ以上のコンピュータ可読記憶媒体に物理的に記憶され得る。例えば、図９は、本開示の特定の実施形態を実装するのに適したコンピュータシステム９００を示す。

コンピュータソフトウェアは、コンピュータ中央処理装置（ＣＰＵ）、グラフィックス処理装置（ＧＰＵ）などによって、直接、又は解釈、マイクロコード実行などを介して実行され得る命令を含むコードを作成するために、アセンブリ、コンパイル、リンク、又は同様の機構にかけられ得る任意の適切な機械コード又はコンピュータ言語を使用してコード化され得る。

命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットデバイス等を含む、種々のタイプのコンピュータ又はその構成要素上で実行され得る。

コンピュータシステム９００について図９に示される構成要素は例であり、本開示の実施形態を実装するコンピュータソフトウェアの使用又は機能の範囲に関していかなる限定も示唆するものではない。また、コンポーネントの構成は、コンピュータシステム９００の非限定的な実施形態に示されるコンポーネントのいずれか１つ又は組合せに関して何らかの依存関係又は要件を有するものとして解釈されるべきではない。

コンピュータシステム９００は、特定のヒューマンインタフェース入力デバイスを含み得る。このようなヒューマンインタフェース入力デバイスは、例えば、触覚入力（例えば、キーストローク、スイッピング、データグローブの動き）、音声入力（例えば、音声、拍手）、視覚入力（例えば、ジェスチャ）、嗅覚入力（図示せず）を介して、一人又は複数の人間ユーザによる入力に応答し得る。また、ヒューマンインターフェースデバイスは、オーディオ（スピーチ、音楽、周囲音など）、画像（スキャン画像、静止画像カメラから得られる写真画像など）、ビデオ（２次元ビデオ、立体ビデオを含む３次元ビデオなど）など、必ずしも人間による意識的な入力に直接関連しない特定のメディアをキャプチャするために使用されてもよい。

入力ヒューマンインターフェースデバイスには、次のものが１つ以上含まれ得る（それぞれ１つのみ表されている）：キーボード９０１、マウス９０２、トラックパッド９０３、タッチスクリーン９１０、データグローブ、ジョイスティック９０５、マイクロフォン９０６、スキャナ９０７、カメラ９０８。

コンピュータシステム９００はまた、特定のヒューマンインタフェース出力デバイスを含み得る。かかるヒューマンインタフェース出力デバイスは、例えば、触覚出力、音、光、及び嗅覚／味覚を通して、１人又は複数の人間ユーザの感覚を刺激し得る。かかるヒューマンインターフェースデバイス出力デバイスには、触覚出力デバイスが含むことができ（たとえば、タッチスクリーン９１０、データグローブ、又はジョイスティック９０５による触覚フィードバックであるが、入力デバイスとして機能しない触覚フィードバックデバイスであることもできる）。例えば、かかるデバイスは、オーディオ出力デバイス（例えば、スピーカー９０９、ヘッドホン（図示せず））、視覚出力デバイス（例えば、ＣＲＴスクリーン、ＬＣＤスクリーン、プラズマスクリーン、ＯＬＥＤスクリーンを含むスクリーン９１０など、それぞれタッチスクリーン入力機能を備えるか又は備えない、それぞれ触覚フィードバック機能を備えるか又は備えない、ーそのうちのいくつかは、ステレオグラフィック出力などの手段を介して、２次元の視覚的出力又は３次元以上の出力を出力できる場合がある：バーチャルリアリティグラス（図示せず）、ホログラフィックディスプレイ、及びスモークタンク（図示せず））、プリンタ（図示せず）などであり得る。

コンピュータシステム９００はまた、人間がアクセス可能な記憶デバイスと、それらのアクセス可能な媒体と、を含むことができ、媒体は、例えば、ＣＤ／ＤＶＤ又は同様の媒体９２１を有するＣＤ／ＤＶＤ ＲＯＭ／ＲＷ９２０を含む光媒体、ＵＳＢメモリ９２２、リムーバブルハードドライブ又はソリッドステートドライブ９２３、テープ及びフロッピー（登録商標）ディスク（図示せず）などのレガシー磁気媒体、セキュリティドングル（図示せず）等の専用ＲＯＭ／ＡＳＩＣ／ＰＬＤベースのデバイスなどの関連する媒体と、を含むこともできる。

当業者はまた、現在開示されている主題に関連して使用される「コンピュータ可読記憶媒体」という用語は、伝送媒体、搬送波、又は他の一時的な信号を包含しないことを理解されたい。

コンピュータシステム９００はまた、１つ以上の通信ネットワークへのインターフェースデバイスを含むことができる。ネットワークは、例えば、無線、有線、光であり得る。ネットワークは、さらに、ローカル、広域、大都市、車両及び工業、リアルタイム、遅延耐性等であり得る。ネットワークの例としては、イーサネット、無線ＬＡＮ、ＧＳＭ、３Ｇ、４Ｇ、５Ｇ、ＬＴＥ等を含むセルラーネットワーク、ケーブルＴＶ、衛星ＴＶ、及び地上放送ＴＶ、ＣＡＮＢｕｓを含む産業用及び車両用を含む。特定のネットワークは、一般に、特定の汎用データポート又は周辺バス９４９（例えば、コンピュータシステム９００のＵＳＢポートなど）に取り付けられる外部ネットワークインターフェースアダプタを必要とし、他のものは、一般に、以下で説明するように、システムバスへの取り付けによってコンピュータシステム９００のコアに統合される（例えば、ＰＣコンピュータシステムへのイーサネット（登録商標）インターフェース又はスマートフォンコンピュータシステムへのセルラーネットワークインターフェース）。これらのネットワークのいずれかを使用して、コンピュータシステム９００は、他のエンティティと通信することができる。かかる通信は、単方向の受信のみ通信（例えば、放送テレビ）、単方向送信のみ通信（例えば、特定のＣＡＮバスデバイスへのＣＡＮバス）、又は、例えばローカル又は広域デジタルネットワークを使用する他のコンピュータシステムへの、双方向通信であることができる。かかる通信は、クラウドコンピューティング環境９５５との通信を含むことができる。特定のプロトコル及びプロトコルスタックは、上述のように、それらのネットワーク及びネットワークインタフェースの各々で使用されることができる。

前述のヒューマンインターフェースデバイス、人間がアクセス可能な記憶デバイス、及びネットワークインタフェース９５４は、コンピュータシステム９００のコア９４０に接続されることができる。

コア９４０は、１つ以上の中央処理ユニット（ＣＰＵ）９４１、グラフィックス処理ユニット（ＧＰＵ）９４２、フィールドプログラマブルゲートエリア（ＦＰＧＡ）９４３の形態の専用プログラマブル処理デバイス、特定のタスクのためのハードウェアアクセラレータ９４４等を含むことができる。これらのデバイスは、読出し専用メモリ（ＲＯＭ）９４５、ランダムアクセスメモリ９４６、内部大容量ストレージ、例えば内部非ユーザアクセス可能ハードドライブ、ＳＳＤ等９４７と共に、システムバス９４８を介して接続され得る。
いくつかのコンピュータシステムでは、システムバス９４８は、追加のＣＰＵ、ＧＰＵ等による拡張を可能にするために、１つ以上の物理プラグの形態でアクセス可能である。周辺デバイスは、コアのシステムバス９４８に直接接続するか、又は周辺バス９４９を介して接続することができる。周辺バスのアーキテクチャは、ＰＣＩ、ＵＳＢ等を含む。グラフィックアダプタ９５０は、コア９４０に含まれ得る。

ＣＰＵ９４１、ＧＰＵ９４２、ＦＰＧＡ９４３、及びアクセラレータ９４４は、組み合わされて、上述のコンピュータコードを構成することができる特定の命令を実行することができる。そのコンピュータコードは、ＲＯＭ９４５又はＲＡＭ９４６に格納されることができる。移行データは、ＲＡＭ９４６に格納されることもできるが、永久データは例えば内部大容量ストレージ９４７に格納されことができる。１つ以上のＣＰＵ９４１、ＧＰＵ９４２、大容量ストレージ９４７、ＲＯＭ９４５、ＲＡＭ９４６等と密接に関連付けることができるキャッシュメモリを使用することによって、メモリデバイスのいずれかへの高速記憶及び検索を可能にすることができる。

コンピュータ可読記憶媒体は、各種のコンピュータ実施動作（ｃｏｍｐｕｔｅｒ－ｉｍｐｌｅｍｅｎｔｅｄ ｏｐｅｒａｔｉｏｎｓ）を実行するためにその上のコンピュータコードを有することができる。媒体及びコンピュータコードは、本開示の目的のために特別に設計及び構築されたものであってもよく、又はコンピュータソフトウェア分野の当業者によく知られ、利用可能な種類のものであってもよい。

限定ではなく、例として、アーキテクチャ９００を有するコンピュータシステム、具体的にはコア９４０は、（１つ以上の）プロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、アクセラレータなどを含む）が１つ以上の有形のコンピュータ可読記憶媒体において具現化されたソフトウェアを実行する結果として機能を提供することができる。かかるコンピュータ可読記憶媒体は、上記で紹介したようなユーザアクセス可能な大容量ストレージ、ならびにコア内部大容量ストレージ９４７又はＲＯＭ９４５などの非一時的な性質のコア９４０の特定のストレージに関連付けられた媒体であり得る。本開示の様々な実施形態を実装するソフトウェアは、そのようなデバイス内に記憶され、コア９４０によって実行され得る。コンピュータ読取可能媒体は、特定のニーズに応じて、１つ以上のメモリデバイス又はチップを含むことができる。ソフトウェアは、コア９４０及びその中の具体的にプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ等を含む）に、ＲＡＭ９４６に記憶されたデータ構造を定義し、ソフトウェアによって定義されたプロセスにしたがって、かかるデータ構造を変更することを含む、本明細書に記載された特定のプロセス又は特定の部分を実行させることができる。付加的に又は代替的に、コンピュータシステムは、回路（例えば、アクセラレータ９４４）内に配線された、又は他の方法で具現化されたロジックの結果として、機能性を提供することができ、これは、本明細書に記載される特定のプロセス又は特定のプロセスの特定の部分を実行するために、ソフトウェアの代わりに、又はソフトウェアと共に動作することができる。ソフトウェアへの言及は、論理を含み、また、必要に応じて、その逆も可能である。コンピュータ読取り可能媒体への参照は、実行のためのソフトウェアを記憶する（集積回路（ＩＣ）等の）回路、実行のためのロジックを具体化する回路、又は適切な場合にはその両方を含むことができる。本開示は、ハードウェア及びソフトウェアの任意の適切な組み合わせを包含する。

本開示は、いくつかの非限定的な実施形態を説明してきたが、本開示の範囲内に入る変更、置換、及び様々な代用等価物が存在する。したがって、当業者は、本明細書に明示的に示されていないか又は記載されていないが、本発明の原理を実施し、したがってその概念及び範囲内にある多数のシステム及び方法を創造することができることが理解されよう。

Claims (9)

1. デコーダ内の少なくとも１つのプロセッサによって実行される方法であって：
   エンコーダからコーディングされたビデオビットストリーム（コード化ビデオビットストリーム）を受信するステップと；
   前記コード化ビデオビットストリームから、ボリュメトリックオブジェクトの１つ以上の表面を記述する複数のポリゴンを備えるメッシュを取り出すステップと；
   ＵＶ－ｔｏ－ＸＹＺインデックスアレイ内の別のインデックスに含まれる少なくとも１つの以前にコーディングされた値から、前記ＵＶ－ｔｏ－ＸＹＺインデックスアレイのインデックスの現在の値を予測するステップであって、前記ＵＶ－ｔｏ－ＸＹＺインデックスアレイが、前記メッシュに関連付けられた各２次元（２Ｄ）ＵＶ頂点を前記メッシュに関連付けられた３次元（３Ｄ）ＸＹＺ頂点に対応させる複数のインデックスを含む、ステップと；
   前記ＵＶ－ｔｏ－ＸＹＺインデックスアレイの前記インデックスの前記現在の値に関連付けられた予測残差を導出するステップと；
   前記ＵＶ－ｔｏ－ＸＹＺインデックスアレイの前記インデックスの予測された前記現在の値と導出された前記予測残差とに基づいて境界ＵＶ座標を再構成するステップと、を含む
   方法。
2. 前記予測残差は、固定長コーディングによってコーディングされる、
   請求項１記載の方法。
3. 前記予測残差は、指数ゴロムコーディングによってコーディングされる、
   請求項１記載の方法。
4. 前記予測残差は、ユーナリーコーディングによってコーディングされる、
   請求項１記載の方法。
5. 前記予測残差が、前記予測残差の大きさ及び符号を特定する前記コード化ビデオビットストリーム中に含まれる１つ以上のシンタックス要素によってコーディングされる、
   請求項１記載の方法。
6. 前記ＵＶ－ｔｏ－ＸＹＺインデックスアレイは、ランレングス方向のタプルとしてコーディングされる、
   請求項１記載の方法。
7. 前記ＵＶ－ｔｏ－ＸＹＺインデックスアレイが境界ループである、
   請求項１記載の方法。
8. プログラムコードを格納するように構成された少なくとも１つのメモリと、
   前記プログラムコードを読み込んで、前記プログラムコードによって命令されたように動作するように構成された少なくとも１つのプロセッサと、を備える装置であって、
   前記プログラムコードは、前記少なくとも１つのプロセッサに、請求項１乃至７いずれか１項記載の方法を実行させるように構成されている、
   装置。
9. 命令を備えるプログラムであって、前記命令は、少なくとも１つのプロセッサで実行されるときに、前記少なくとも１つのプロセッサに、請求項１乃至７いずれか１項記載の方法を実行させる、
   プログラム。