JP2024519664A - インター予測を使用するジオメトリポイントクラウド圧縮（ｇｐｃｃ）平面モードの性能改善 - Google Patents

Abstract

ポイントクラウドを処理するための例示的なデバイスが、ポイントクラウドの少なくとも一部分を記憶するように構成されたメモリと、回路中に実装された１つまたは複数のプロセッサとを含み、１つまたは複数のプロセッサは、ポイントクラウドの参照ブロックの平面情報を取得することと、参照ブロックの平面情報に基づいて、コンテキストを決定することと、コンテキストに基づいて、現在のノードが平面モードを使用してコーディングされるかどうかを示すシンタックス要素をコンテキスト適応型コーディングすることと、現在のノードが平面モードを使用してコーディングされることに基づいて、平面モードを使用して現在のノードをコーディングすることとを行うように構成される。

Description

[0001]本出願は、その各々の内容全体が参照により本明細書に組み込まれる、２０２２年４月１４日に出願された米国特許出願第１７／６５９，２１９号と、２０２１年４月１６日に出願された米国仮出願第６３／１７６，０９８号との優先権を主張する。２０２２年４月１４日に出願された米国特許出願第１７／６５９，２１９号は、２０２１年４月１６日に出願された米国仮出願第６３／１７６，０９８号の利益を主張する。

[0002]本開示は、ポイントクラウド符号化および復号に関する。

[0003]本開示の技法を実施し得る例示的な符号化および復号システムを示すブロック図。 [0004]例示的なジオメトリポイントクラウド圧縮（Ｇ－ＰＣＣ）エンコーダを示すブロック図。 [0005]例示的なＧ－ＰＣＣデコーダを示すブロック図。 [0006]ＩｎｔｅｒＥＭのための例示的な動き推定技法を示すフローチャート。 [0007]ローカルノード動きベクトルの推定のための例示的な技法を示すフローチャート。 [0008]本開示の１つまたは複数の技法とともに使用され得る例示的なレンジ測定システム（range-finding system）を示す概念図。 [0009]本開示の１つまたは複数の技法が使用され得る例示的な車両ベースのシナリオを示す概念図。 [0010]本開示の１つまたは複数の技法が使用され得る例示的なエクステンデッドリアリティシステムを示す概念図。 [0011]本開示の１つまたは複数の技法が使用され得る例示的なモバイルデバイスシステムを示す概念図。 [0012]バイナリ算術コーディングにおけるレンジ更新プロセスを示す概念図。 バイナリ算術コーディングにおけるレンジ更新プロセスを示す概念図。 [0013]バイナリ算術コーディングにおける出力プロセスを示す概念図。 [0014]Ｇ－ＰＣＣエンコーダ中のコンテキスト適応型バイナリ算術コーダを示すブロック図。 [0015]Ｇ－ＰＣＣデコーダ中のコンテキスト適応型バイナリ算術コーダを示すブロック図。 [0016]本開示の１つまたは複数の態様による、ポイントクラウドのポイントを予測する例示的な技法を示す流れ図。

[0017]概して、本開示は、現在開発されているジオメトリポイントクラウド圧縮（Ｇ－ＰＣＣ）規格についてなど、インター予測を使用するポイントクラウドのノードをコーディングするための技法について説明する。しかしながら、例示的な技法は、Ｇ－ＰＣＣ規格に限定されない。ノードの参照ブロックは、推定された動き情報（回転および並進）を使用する動き補償によって導出され得る。動き情報の良好な推定が、現在のノードと参照ノードとの間の、占有、平面情報など、ジオメトリ構造に関する高相関につながり得る。したがって、参照ノードのこのジオメトリ情報を利用することが、現在のノードのコーディング性能を改善し得る。本開示は、現在のノードの平面情報のコーディングにおいて参照ブロックの情報を利用するためのいくつかの技法を含む。概して、この情報は、平面コーディングモードのためのノードの適格性、平面フラグおよび平面インデックスをコーディングする際のコンテキストの選択において使用され得る。

[0018]本開示の１つまたは複数の技法によれば、Ｇ－ＰＣＣコーダは、ポイントクラウドの少なくとも一部分を記憶するように構成されたメモリと、回路中に実装された１つまたは複数のプロセッサとを含み得、１つまたは複数のプロセッサは、ポイントクラウドの参照ブロックの平面情報を取得することと、参照ブロックの平面情報に基づいて、コンテキストを決定することと、コンテキストに基づいて、現在のノードが平面モードを使用してコーディングされるかどうかを示すシンタックス要素をコンテキスト適応型コーディングすることと、現在のノードが平面モードを使用してコーディングされることに基づいて、平面モードを使用して現在のノードをコーディングすることとを行うように構成される。

[0019]一例では、ポイントクラウドを処理する方法は、ポイントクラウドの参照ブロックの平面情報を取得することと、参照ブロックの平面情報に基づいて、コンテキストを決定することと、コンテキストに基づいて、現在のノードが平面モードを使用してコーディングされるかどうかを示すシンタックス要素をコンテキスト適応型コーディングすることと、現在のノードが平面モードを使用してコーディングされることに基づいて、平面モードを使用して現在のノードをコーディングすることとを含む。

[0020]別の例では、コンピュータ可読記憶媒体は、１つまたは複数のプロセッサによって実行されたとき、１つまたは複数のプロセッサに、ポイントクラウドの参照ブロックの平面情報を取得することと、参照ブロックの平面情報に基づいて、コンテキストを決定することと、コンテキストに基づいて、現在のノードが平面モードを使用してコーディングされるかどうかを示すシンタックス要素をコンテキスト適応型コーディングすることと、現在のノードが平面モードを使用してコーディングされることに基づいて、平面モードを使用して現在のノードをコーディングすることとを行わせる命令を記憶する。

[0021]１つまたは複数の例の詳細が添付の図面および以下の説明に記載されている。他の特徴、目的、および利点は、説明、図面、および特許請求の範囲から明らかになろう。

[0022]図１は、本開示の技法を実施し得る例示的な符号化および復号システム１００を示すブロック図である。本開示の技法は、概して、ポイントクラウドデータをコーディング（符号化および／または復号）すること、すなわち、ポイントクラウド圧縮をサポートすることを対象とする。概して、ポイントクラウドデータは、ポイントクラウドを処理するための任意のデータを含む。コーディングは、ポイントクラウドデータを圧縮および／または解凍する際に効果的であり得る。

[0023]図１に示されているように、システム１００は、ソースデバイス１０２と宛先デバイス１１６とを含む。ソースデバイス１０２は、宛先デバイス１１６によって復号されるべき符号化されたポイントクラウドデータを提供する。詳細には、図１の例では、ソースデバイス１０２は、コンピュータ可読媒体１１０を介して宛先デバイス１１６にポイントクラウドデータを提供する。ソースデバイス１０２および宛先デバイス１１６は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、スマートフォンなどの電話ハンドセット、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイス、地上車両または海洋車両、宇宙船、航空機、ロボット、ＬＩＤＡＲデバイス、衛星などを含む、広範囲のデバイスのいずれかを備え得る。いくつかの場合には、ソースデバイス１０２および宛先デバイス１１６は、ワイヤレス通信のために装備され得る。

[0024]図１の例では、ソースデバイス１０２は、データソース１０４と、メモリ１０６と、Ｇ－ＰＣＣエンコーダ２００と、出力インターフェース１０８とを含む。宛先デバイス１１６は、入力インターフェース１２２と、Ｇ－ＰＣＣデコーダ３００と、メモリ１２０と、データコンシューマー１１８とを含む。本開示によれば、ソースデバイス１０２のＧ－ＰＣＣエンコーダ２００および宛先デバイス１１６のＧ－ＰＣＣデコーダ３００は、現在のノード（たとえば、現在のブロック）の平面情報のコーディングにおいて参照ブロックの情報を利用することに関係する本開示の技法を適用するように構成され得る。したがって、ソースデバイス１０２は符号化デバイスの一例を表すが、宛先デバイス１１６は復号デバイスの一例を表す。他の例では、ソースデバイス１０２および宛先デバイス１１６は、他の構成要素または構成を含み得る。たとえば、ソースデバイス１０２は、内部ソースまたは外部ソースからデータ（たとえば、ポイントクラウドデータ）を受信し得る。同様に、宛先デバイス１１６は、同じデバイス中にデータコンシューマーを含むのではなく、外部データコンシューマーとインターフェースし得る。

[0025]図１に示されているシステム１００は一例にすぎない。概して、他のデジタル符号化および／または復号デバイスが、現在のノードの平面情報のコーディングにおいて参照ブロックの情報を利用することに関係する本開示の技法を実施し得る。ソースデバイス１０２および宛先デバイス１１６は、ソースデバイス１０２が宛先デバイス１１６への送信のためのコーディングされたデータを生成するようなデバイスの例にすぎない。本開示は、データのコーディング（符号化および／または復号）を実施するデバイスとして「コーディング」デバイスに言及する。したがって、Ｇ－ＰＣＣエンコーダ２００およびＧ－ＰＣＣデコーダ３００は、コーディングデバイス、特に、それぞれエンコーダおよびデコーダの例を表す。いくつかの例では、ソースデバイス１０２および宛先デバイス１１６は、ソースデバイス１０２および宛先デバイス１１６の各々が符号化構成要素および復号構成要素を含むように、実質的に対称的に動作し得る。したがって、システム１００は、たとえば、ストリーミング、再生、ブロードキャスティング、電話通信、ナビゲーション、および他の用途のために、ソースデバイス１０２と宛先デバイス１１６との間の一方向または双方向送信をサポートし得る。

[0026]概して、データソース１０４は、データ（すなわち、生の符号化されていないポイントクラウドデータ）のソースを表し、データの連続した一連の「フレーム」をＧ－ＰＣＣエンコーダ２００に提供し得、Ｇ－ＰＣＣエンコーダ２００は、フレームについてのデータを符号化する。ソースデバイス１０２のデータソース１０４は、様々なカメラまたはセンサーのいずれか、たとえば、３Ｄスキャナまたは光検出および測距（ＬＩＤＡＲ）デバイス、１つまたは複数のビデオカメラ、以前にキャプチャされたデータを含んでいるアーカイブ、ならびに／あるいはデータコンテンツプロバイダからデータを受信するためのデータフィードインターフェースなど、ポイントクラウドキャプチャデバイスを含み得る。代替または追加として、ポイントクラウドデータは、スキャナ、カメラ、センサーまたは他のデータからコンピュータ生成され得る。たとえば、データソース１０４は、ソースデータとしてコンピュータグラフィックスベースのデータを生成し得るか、または、ライブデータ、アーカイブされたデータ、およびコンピュータ生成されたデータの組合せを作り出し得る。各場合において、Ｇ－ＰＣＣエンコーダ２００は、キャプチャされたデータ、プリキャプチャされたデータ、またはコンピュータ生成されたデータを符号化する。Ｇ－ＰＣＣエンコーダ２００は、フレームを、（「表示順序」と呼ばれることがある）受信順序から、コーディングするためのコーディング順序に並べ替え得る。Ｇ－ＰＣＣエンコーダ２００は、符号化されたデータを含む１つまたは複数のビットストリームを生成し得る。ソースデバイス１０２は、次いで、たとえば、宛先デバイス１１６の入力インターフェース１２２による受信および／または取出しのために、符号化されたデータを出力インターフェース１０８を介してコンピュータ可読媒体１１０上に出力し得る。

[0027]ソースデバイス１０２のメモリ１０６および宛先デバイス１１６のメモリ１２０は、汎用メモリを表し得る。いくつかの例では、メモリ１０６およびメモリ１２０は、生データ、たとえば、データソース１０４からの生データと、Ｇ－ＰＣＣデコーダ３００からの生の復号されたデータとを記憶し得る。追加または代替として、メモリ１０６およびメモリ１２０は、たとえば、それぞれ、Ｇ－ＰＣＣエンコーダ２００およびＧ－ＰＣＣデコーダ３００によって実行可能なソフトウェア命令を記憶し得る。メモリ１０６およびメモリ１２０は、この例ではＧ－ＰＣＣエンコーダ２００およびＧ－ＰＣＣデコーダ３００とは別個に示されているが、Ｇ－ＰＣＣエンコーダ２００およびＧ－ＰＣＣデコーダ３００は、機能的に同様のまたは等価な目的で内部メモリをも含み得ることを理解されたい。さらに、メモリ１０６およびメモリ１２０は、符号化されたデータ、たとえば、Ｇ－ＰＣＣエンコーダ２００からの出力、およびＧ－ＰＣＣデコーダ３００への入力を記憶し得る。いくつかの例では、メモリ１０６およびメモリ１２０の部分は、たとえば、生の、復号された、および／または符号化されたデータを記憶するために、１つまたは複数のバッファとして割り振られ得る。たとえば、メモリ１０６およびメモリ１２０は、ポイントクラウドを表すデータを記憶し得る。

[0028]コンピュータ可読媒体１１０は、ソースデバイス１０２から宛先デバイス１１６に、符号化されたデータをトランスポートすることが可能な任意のタイプの媒体またはデバイスを表し得る。一例では、コンピュータ可読媒体１１０は、ソースデバイス１０２が、たとえば、無線周波数ネットワークまたはコンピュータベースのネットワークを介して、符号化されたデータを宛先デバイス１１６にリアルタイムで直接送信することを可能にするための通信媒体を表す。出力インターフェース１０８は、符号化されたデータを含む送信信号を変調し得、入力インターフェース１２２は、ワイヤレス通信プロトコルなどの通信規格に従って、受信された送信信号を復調し得る。通信媒体は、無線周波数（ＲＦ）スペクトルまたは１つまたは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなど、パケットベースのネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス１０２から宛先デバイス１１６への通信を容易にするために有用であり得る任意の他の機器を含み得る。

[0029]いくつかの例では、ソースデバイス１０２は、符号化されたデータを出力インターフェース１０８から記憶デバイス１１２に出力し得る。同様に、宛先デバイス１１６は、入力インターフェース１２２を介して記憶デバイス１１２からの符号化されたデータにアクセスし得る。記憶デバイス１１２は、ハードドライブ、Ｂｌｕ－ｒａｙ（登録商標）ディスク、ＤＶＤ、ＣＤ－ＲＯＭ、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは符号化されたデータを記憶するための任意の他の好適なデジタル記憶媒体など、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。

[0030]いくつかの例では、ソースデバイス１０２は、ソースデバイス１０２によって生成された符号化されたデータを記憶し得るファイルサーバ１１４または別の中間記憶デバイスに、符号化されたデータを出力し得る。宛先デバイス１１６は、ストリーミングまたはダウンロードを介してファイルサーバ１１４からの記憶されたデータにアクセスし得る。ファイルサーバ１１４は、符号化されたデータを記憶し、その符号化されたデータを宛先デバイス１１６に送信することが可能な任意のタイプのサーバデバイスであり得る。ファイルサーバ１１４は、（たとえば、ウェブサイトのための）ウェブサーバ、ファイル転送プロトコル（ＦＴＰ）サーバ、コンテンツ配信ネットワークデバイス、またはネットワーク接続ストレージ（ＮＡＳ）デバイスを表し得る。宛先デバイス１１６は、インターネット接続を含む任意の標準的なデータ接続を通してファイルサーバ１１４からの符号化されたデータにアクセスし得る。これは、ファイルサーバ１１４に記憶された符号化されたデータにアクセスするのに好適であるワイヤレスチャネル（たとえば、Ｗｉ－Ｆｉ（登録商標）接続）、ワイヤード接続（たとえば、デジタル加入者回線（ＤＳＬ）、ケーブルモデムなど）、またはその両方の組合せを含み得る。ファイルサーバ１１４と入力インターフェース１２２とは、ストリーミング送信プロトコル、ダウンロード送信プロトコル、またはそれらの組合せに従って動作するように構成され得る。

[0031]出力インターフェース１０８と入力インターフェース１２２とは、ワイヤレス送信機／受信機、モデム、ワイヤードネットワーキング構成要素（たとえば、イーサネット（登録商標）カード）、様々なＩＥＥＥ８０２．１１規格のいずれかに従って動作するワイヤレス通信構成要素、または他の物理的構成要素を表し得る。出力インターフェース１０８と入力インターフェース１２２とがワイヤレス構成要素を備える例では、出力インターフェース１０８と入力インターフェース１２２とは、４Ｇ、４Ｇ－ＬＴＥ（登録商標）（ロングタームエボリューション）、ＬＴＥアドバンスト、５Ｇなど、セルラー通信規格に従って、符号化されたデータなどのデータを転送するように構成され得る。出力インターフェース１０８がワイヤレス送信機を備えるいくつかの例では、出力インターフェース１０８と入力インターフェース１２２とは、ＩＥＥＥ８０２．１１仕様、ＩＥＥＥ８０２．１５仕様（たとえば、ＺｉｇＢｅｅ（登録商標））、Ｂｌｕｅｔｏｏｔｈ（登録商標）規格など、他のワイヤレス規格に従って、符号化されたデータなどのデータを転送するように構成され得る。いくつかの例では、ソースデバイス１０２および／または宛先デバイス１１６は、それぞれのシステムオンチップ（ＳｏＣ）デバイスを含み得る。たとえば、ソースデバイス１０２は、Ｇ－ＰＣＣエンコーダ２００および／または出力インターフェース１０８に起因する機能を実施するためのＳｏＣデバイスを含み得、宛先デバイス１１６は、Ｇ－ＰＣＣデコーダ３００および／または入力インターフェース１２２に起因する機能を実施するためのＳｏＣデバイスを含み得る。

[0032]本開示の技法は、自律車両間の通信、スキャナ、カメラ、センサー、およびローカルサーバまたはリモートサーバなどの処理デバイスの間の通信、地理的マッピング、あるいは他の用途など、様々な用途のいずれかをサポートする符号化および復号に適用され得る。

[0033]宛先デバイス１１６の入力インターフェース１２２は、コンピュータ可読媒体１１０（たとえば、通信媒体、記憶デバイス１１２、ファイルサーバ１１４など）から符号化されたビットストリームを受信する。符号化されたビットストリームは、コーディングされたユニット（たとえば、スライス、ピクチャ、ピクチャグループ、シーケンスなど）の特性および／または処理を記述する値を有するシンタックス要素など、Ｇ－ＰＣＣデコーダ３００によっても使用される、Ｇ－ＰＣＣエンコーダ２００によって定義されるシグナリング情報を含み得る。データコンシューマー１１８は、復号されたデータを使用する。たとえば、データコンシューマー１１８は、物理的物体のロケーションを決定するために、復号されたデータを使用し得る。いくつかの例では、データコンシューマー１１８は、ポイントクラウドに基づいて像を提示するためのディスプレイを備え得る。

[0034]Ｇ－ＰＣＣエンコーダ２００およびＧ－ＰＣＣデコーダ３００は各々、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、など、様々な好適なエンコーダおよび／またはデコーダ回路のいずれか、あるいはそれらの任意の組合せとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、本開示の技法を実施するために、好適な非一時的コンピュータ可読媒体にソフトウェアのための命令を記憶し、１つまたは複数のプロセッサを使用してその命令をハードウェアで実行し得る。Ｇ－ＰＣＣエンコーダ２００およびＧ－ＰＣＣデコーダ３００の各々は、１つまたは複数のエンコーダまたはデコーダ中に含まれ得、それらのいずれかは、それぞれのデバイス中の複合エンコーダ／デコーダ（コーデック）の一部として統合され得る。Ｇ－ＰＣＣエンコーダ２００および／またはＧ－ＰＣＣデコーダ３００を含むデバイスは、１つまたは複数の集積回路、マイクロプロセッサ、および／または他のタイプのデバイスを備え得る。

[0035]Ｇ－ＰＣＣエンコーダ２００およびＧ－ＰＣＣデコーダ３００は、ビデオポイントクラウド圧縮（Ｖ－ＰＣＣ）規格またはジオメトリポイントクラウド圧縮（Ｇ－ＰＣＣ）規格などのコーディング規格に従って動作し得る。本開示は、概して、データを符号化または復号するプロセスを含むためにピクチャのコーディング（たとえば、符号化および復号）に言及することがある。符号化されたビットストリームは、概して、コーディング決定（たとえば、コーディングモード）を表すシンタックス要素についての一連の値を含む。

[0036]本開示は、概して、シンタックス要素などのある情報を「シグナリング」することに言及することがある。「シグナリング」という用語は、概して、符号化されたデータを復号するために使用されるシンタックス要素および／または他のデータについての値の通信を指すことがある。すなわち、Ｇ－ＰＣＣエンコーダ２００は、ビットストリームにおいてシンタックス要素についての値をシグナリングし得る。概して、シグナリングは、ビットストリームにおいて値を生成することを指す。上述のように、ソースデバイス１０２は、宛先デバイス１１６による後の取出しのためにシンタックス要素を記憶デバイス１１２に記憶するときに起こり得る、ビットストリームを、実質的にリアルタイムで、またはリアルタイムではなく、宛先デバイス１１６にトランスポートし得る。

[0037]ＩＳＯ／ＩＥＣ ＭＰＥＧ（ＪＴＣ１／ＳＣ２９／ＷＧ１１）は、現在の手法の圧縮能力を大幅に上回る圧縮能力をもつポイントクラウドコーディング技術の規格化の潜在的な必要性を研究しており、その規格を作成することをターゲットにする。そのグループは、この分野の専門家によって提案された圧縮技術設計を評価するために、３次元グラフィックスチーム（３ＤＧ）として知られる協力的取り組みにおいて、この探究活動に関して協働している。

[0038]ポイントクラウド圧縮アクティビティは、２つの異なる手法に分類される。第１の手法は、「ビデオポイントクラウド圧縮」（Ｖ－ＰＣＣ）であり、これは、３Ｄ物体をセグメント化し、（２Ｄフレーム中で「パッチ」として表される）複数の２Ｄ平面中にセグメントを投影し、それらはさらに、高効率ビデオコーディング（ＨＥＶＣ）（ＩＴＵ－Ｔ Ｈ．２６５）コーデックなどのレガシー２Ｄビデオコーデックによってコーディングされる。第２の手法は、「ジオメトリベースのポイントクラウド圧縮」（Ｇ－ＰＣＣ）であり、これは、３Ｄジオメトリ、すなわち、３Ｄ空間内のポイントのセットの位置と、（３Ｄジオメトリに関連付けられた各ポイントについて）関連付けられた属性値とを直接圧縮する。Ｇ－ＰＣＣは、カテゴリー１（静的ポイントクラウド）とカテゴリー３（動的に収集されたポイントクラウド）の両方におけるポイントクラウドの圧縮に対処する。Ｇ－ＰＣＣ規格の最近のドラフトは、Ｇ－ＰＣＣ ＤＩＳ、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１ ｗ１９０８８、ブリュッセル、ベルギー、２０２０年１月において入手可能であり、コーデックの説明は、Ｇ－ＰＣＣ Ｃｏｄｅｃ Ｄｅｓｃｒｉｐｔｉｏｎ ｖ６、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１ ｗ１９０９１、ブリュッセル、ベルギー、２０２０年１月において入手可能である。

[0039]ポイントクラウドは、３Ｄ空間内のポイントのセットを含んでおり、ポイントに関連付けられた属性を有し得る。属性は、Ｒ、Ｇ、Ｂ、または、Ｙ、Ｃｂ、Ｃｒなどの色情報、あるいは反射率情報、あるいは他の属性であり得る。ポイントクラウドは、ＬＩＤＡＲセンサーおよび３Ｄスキャナなどの様々なカメラまたはセンサーによってキャプチャされ得、また、コンピュータ生成され得る。ポイントクラウドデータは、限定はしないが、建築（モデリング）、グラフィックス（視覚化およびアニメーションのための３Ｄモデル）、および自動車産業（ナビゲーションを助けるために使用されるＬＩＤＡＲセンサー）を含む様々な用途において使用される。

[0040]ポイントクラウドデータによって占有される３Ｄ空間は、仮想バウンディングボックスによって囲まれ得る。バウンディングボックス中のポイントの位置は、ある精度によって表され得、したがって、１つまたは複数のポイントの位置は、その精度に基づいて量子化され得る。最小レベルでは、バウンディングボックスは、単位立方体によって表される空間の最小単位であるボクセルに分割される。バウンディングボックス中のボクセルは、０個、１つ、または２つ以上のポイントに関連付けられ得る。バウンディングボックスは、タイルと呼ばれることがある複数の立方体／直方体領域に分割され得る。各タイルは、１つまたは複数のスライスにコーディングされ得る。バウンディングボックスの、スライスおよびタイルへの区分は、各区分中のポイントの数に基づき得るか、または他の考慮事項（たとえば、特定の領域がタイルとしてコーディングされ得る）に基づき得る。スライス領域は、ビデオコーデックにおけるものと同様の分割決定を使用してさらに区分され得る。

[0041]図２は、Ｇ－ＰＣＣエンコーダ２００の概要を提供する。図３は、Ｇ－ＰＣＣデコーダ３００の概要を提供する。図示されたモジュールは論理的であり、Ｇ－ＰＣＣコーデック、すなわち、ＩＳＯ／ＩＥＣ ＭＰＥＧ（ＪＴＣ１／ＳＣ２９／ＷＧ１１）によって研究されたＴＭＣ１３テストモデルソフトウェアの参照実装において実装されたコードに必ずしも１対１に対応するとは限らない。

[0042]Ｇ－ＰＣＣエンコーダ２００とＧ－ＰＣＣデコーダ３００の両方において、ポイントクラウド位置が最初にコーディングされる。属性コーディングは、復号されたジオメトリに依存する。図２および図３において、グレーの影付きモジュールは、カテゴリー１のデータのために典型的に使用されるオプションである。斜線付きのモジュールは、カテゴリー３のデータのために典型的に使用されるオプションである。他のすべてのモジュールは、カテゴリー１とカテゴリー３との間で共通である。

[0043]カテゴリー３のデータの場合、圧縮されたジオメトリは、典型的に、ルートから個々のボクセルのリーフレベルに至るオクツリーとして表される。カテゴリー１のデータの場合、圧縮されたジオメトリは、典型的に、プルーニングされたオクツリー（すなわち、ルートからボクセルよりも大きいブロックのリーフレベルまでのオクツリー）と、プルーニングされたオクツリーの各リーフ内の表面を近似するモデルとによって表される。このようにして、カテゴリー１のデータとカテゴリー３のデータの両方がオクツリーコーディング機構を共有するが、カテゴリー１のデータは、さらに、各リーフ内のボクセルを表面モデルで近似し得る。使用される表面モデルは、ブロック当たり１～１０個の三角形を備える三角形分割であり、三角形スープ（triangle soup）をもたらす。したがって、カテゴリー１のジオメトリコーデックは、Ｔｒｉｓｏｕｐジオメトリコーデックとして知られており、カテゴリー３のジオメトリコーデックは、オクツリージオメトリコーデックとして知られている。

[0044]オクツリーの各ノードにおいて、その子ノード（８つまでのノード）のうちの１つまたは複数について、占有率がシグナリングされる（推測されない場合）。（ａ）現在のオクツリーノードと面を共有するノード、（ｂ）現在のオクツリーノードと面、辺または頂点を共有するノードなどを含む複数の近傍が指定される。各近傍内で、ノードおよび／またはその子の占有率が、現在のノードまたはその子の占有率を予測するために使用され得る。オクツリーのいくつかのノードにおいてまばらに分布するポイントについて、コーデックはまた、ポイントの３Ｄ位置が直接符号化される直接コーディングモードをサポートする。直接モードがシグナリングされることを示すために、フラグがシグナリングされ得る。最低レベルにおいて、オクツリーノード／リーフノードに関連付けられたポイントの数もコーディングされ得る。

[0045]ジオメトリがコーディングされると、ジオメトリポイントに対応する属性がコーディングされる。１つの再構成された／復号されたジオメトリポイントに対応する複数の属性ポイントがあるとき、再構成されたポイントを表す属性値が導出され得る。

[0046]Ｇ－ＰＣＣには、３つの属性コーディング方法、すなわち、領域適応階層変換（ＲＡＨＴ）コーディング、補間ベースの階層最近傍予測（予測変換）、および更新／リフティングステップを伴う補間ベースの階層最近傍予測（リフティング変換）がある。ＲＡＨＴおよびリフティングは、典型的に、カテゴリー１のデータのために使用されるが、予測は、典型的に、カテゴリー３のデータのために使用される。しかしながら、いずれの方法も任意のデータのために使用され得、ちょうどＧ－ＰＣＣにおけるジオメトリコーデックの場合のように、ポイントクラウドをコーディングするために使用される属性コーディング方法は、ビットストリームにおいて指定される。

[0047]属性のコーディングは、詳細レベル（ＬＯＤ）において行われ得、各詳細レベルとともに、ポイントクラウド属性のより細かい表現が取得され得る。各詳細レベルは、近隣ノードからの距離メトリックに基づいて、またはサンプリング距離に基づいて指定され得る。

[0048]Ｇ－ＰＣＣエンコーダ２００において、属性についてのコーディング方法の出力として取得された残差が量子化される。残差は、現在のポイントの近傍にあるポイントに基づいておよび前に符号化されたポイントの属性値に基づいて導出された予測から属性値を減算することによって取得され得る。量子化された残差は、コンテキスト適応算術コーディングを使用してコーディングされ得る。

[0049]図２の例では、Ｇ－ＰＣＣエンコーダ２００は、座標変換ユニット２０２と、色変換ユニット２０４と、ボクセル化ユニット２０６と、属性転送ユニット２０８と、オクツリー分析ユニット２１０と、表面近似分析ユニット２１２と、算術符号化ユニット２１４と、ジオメトリ再構成ユニット２１６と、ＲＡＨＴユニット２１８と、ＬＯＤ生成ユニット２２０と、リフティングユニット２２２と、係数量子化ユニット２２４と、算術符号化ユニット２２６とを含み得る。

[0050]図２の例に示されているように、Ｇ－ＰＣＣエンコーダ２００は、ポイントクラウドにおけるポイントの位置のセットと属性のセットとを取得し得る。Ｇ－ＰＣＣエンコーダ２００は、データソース１０４（図１）からポイントクラウドにおけるポイントの位置のセットと属性のセットとを取得し得る。位置は、ポイントクラウドにおけるポイントの座標を含み得る。属性は、ポイントクラウドにおけるポイントに関連付けられた色など、ポイントクラウドにおけるポイントに関する情報を含み得る。Ｇ－ＰＣＣエンコーダ２００は、ポイントクラウドにおけるポイントの位置の符号化された表現を含むジオメトリビットストリーム２０３を生成し得る。Ｇ－ＰＣＣエンコーダ２００は、属性のセットの符号化された表現を含む属性ビットストリーム２０５をも生成し得る。

[0051]座標変換ユニット２０２は、座標を初期領域から変換領域に変換するために、ポイントの座標に変換を適用し得る。本開示は、変換された座標を変換座標と呼ぶことがある。色変換ユニット２０４は、属性の色情報を異なる領域に変換するために変換を適用し得る。たとえば、色変換ユニット２０４は、色情報をＲＧＢ色空間からＹＣｂＣｒ色空間に変換し得る。

[0052]さらに、図２の例では、ボクセル化ユニット２０６は、変換座標をボクセル化し得る。変換座標のボクセル化は、量子化とポイントクラウドのいくつかのポイントを除去することとを含み得る。言い換えれば、ポイントクラウドの複数のポイントは、単一の「ボクセル」内に包含され得、これは、その後、いくつかの観点において１つのポイントとして扱われ得る。さらに、オクツリー分析ユニット２１０は、ボクセル化された変換座標に基づいてオクツリーを生成し得る。さらに、図２の例では、表面近似分析ユニット２１２は、ポイントのセットの表面表現を潜在的に決定するためにポイントを分析し得る。算術符号化ユニット２１４は、表面近似分析ユニット２１２によって決定されたオクツリーおよび／または表面の情報を表すシンタックス要素をエントロピー符号化し得る。Ｇ－ＰＣＣエンコーダ２００は、ジオメトリビットストリーム２０３においてこれらのシンタックス要素を出力し得る。ジオメトリビットストリーム２０３は、算術的に符号化されていないシンタックス要素を含む他のシンタックス要素をも含み得る。

[0053]ジオメトリ再構成ユニット２１６は、オクツリー、表面近似分析ユニット２１２によって決定された表面を示すデータ、および／または他の情報に基づいて、ポイントクラウドにおけるポイントの変換座標を再構成し得る。ジオメトリ再構成ユニット２１６によって再構成された変換座標の数は、ボクセル化および表面近似のために、ポイントクラウドのポイントの元の数とは異なり得る。本開示は、得られたポイントを再構成されたポイントと呼ぶことがある。属性転送ユニット２０８は、ポイントクラウドの元のポイントの属性をポイントクラウドの再構成されたポイントに転送し得る。

[0054]さらに、ＲＡＨＴユニット２１８は、再構成されたポイントの属性にＲＡＨＴコーディングを適用し得る。いくつかの例では、ＲＡＨＴの下で、４つの低（Ｌ）周波数ノードと４つの高（Ｈ）周波数ノードとを取得するために、２×２×２ポイント位置のブロックの属性がとられ、１つの方向に沿って変換される。その後、４つの低周波数ノード（Ｌ）は、２つの低（ＬＬ）周波数ノードと２つの高（ＬＨ）周波数ノードとを取得するために、第２の方向において変換される。２つの低周波数ノード（ＬＬ）は、１つの低（ＬＬＬ）周波数ノードと１つの高（ＬＬＨ）周波数ノードとを取得するために、第３の方向に沿って変換される。低周波数ノードＬＬＬは、ＤＣ係数に対応し、高周波数ノードＨ、ＬＨ、およびＬＬＨは、ＡＣ係数に対応する。各方向における変換は、２つの係数重みをもつ１－Ｄ変換であり得る。低周波数係数は、ＲＡＨＴ変換の次のより高いレベルのための２×２×２ブロックの係数としてとられ得、ＡＣ係数は、変更なしに符号化され、そのような変換は、上部ルートノードまで続く。符号化のためのツリートラバーサルは、それらの係数のために使用されるべき重みを計算するために上部から下部へ使用され、変換順序は、下部から上部へ、である。それらの係数は、次いで、量子化され、コーディングされ得る。

[0055]代替または追加として、ＬＯＤ生成ユニット２２０およびリフティングユニット２２２は、再構成されたポイントの属性に、それぞれＬＯＤ処理およびリフティングを適用し得る。ＬＯＤ生成が、属性を異なる改良レベルに分割するために使用される。各改良レベルは、ポイントクラウドの属性の改良を提供する。第１の改良レベルは、粗い近似を提供し、少数のポイントを含んでおり、後続の改良レベルは、典型的に、より多くのポイントを含んでおり、以下同様である。改良レベルは、距離ベースのメトリックを使用して構成され得るか、または１つまたは複数の他の分類基準（たとえば、特定の順序からのサブサンプリング）をも使用し得る。したがって、すべての再構成されたポイントが、改良レベル中に含まれ得る。各詳細レベルが、特定の改良レベルまでのすべてのポイントの集合（union）をとることによって作り出され、たとえば、ＬＯＤ１が、改良レベルＲＬ１に基づいて取得され、ＬＯＤ２が、ＲＬ１およびＲＬ２に基づいて取得され、．．．ＬＯＤＮが、ＲＬ１、ＲＬ２、．．．ＲＬＮの集合によって取得される。いくつかの場合には、ＬＯＤ生成の後に、予測方式（たとえば、予測変換）が続き得、ここで、ＬＯＤにおける各ポイントに関連する属性が、先行するポイントの重み付き平均から予測され、残差が量子化およびエントロピーコーディングされる。リフティング方式は、予測変換機構の上に構築され、ここで、係数を更新するために更新オペレータ（update operator）が使用され、係数の適応量子化が実施される。

[0056]ＲＡＨＴユニット２１８およびリフティングユニット２２２は、属性に基づいて係数を生成し得る。係数量子化ユニット２２４は、ＲＡＨＴユニット２１８またはリフティングユニット２２２によって生成された係数を量子化し得る。算術符号化ユニット２２６は、量子化係数を表すシンタックス要素に算術コーディングを適用し得る。Ｇ－ＰＣＣエンコーダ２００は、属性ビットストリーム２０５においてこれらのシンタックス要素を出力し得る。属性ビットストリーム２０５は、算術的に符号化されていないシンタックス要素を含む他のシンタックス要素をも含み得る。

[0057]図３の例では、Ｇ－ＰＣＣデコーダ３００は、ジオメトリ算術復号ユニット３０２と、属性算術復号ユニット３０４と、オクツリー合成ユニット３０６と、逆量子化ユニット３０８と、表面近似合成ユニット３１０と、ジオメトリ再構成ユニット３１２と、ＲＡＨＴユニット３１４と、ＬｏＤ生成ユニット３１６と、逆リフティングユニット３１８と、逆変換座標ユニット３２０と、逆変換色ユニット３２２とを含み得る。

[0058]Ｇ－ＰＣＣデコーダ３００は、ジオメトリビットストリーム２０３と属性ビットストリーム２０５とを取得し得る。デコーダ３００のジオメトリ算術復号ユニット３０２は、算術復号（たとえば、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）または他のタイプの算術復号）をジオメトリビットストリーム２０３中のシンタックス要素に適用し得る。同様に、属性算術復号ユニット３０４は、算術復号を属性ビットストリーム２０５中のシンタックス要素に適用し得る。

[0059]オクツリー合成ユニット３０６は、ジオメトリビットストリーム２０３からパースされたシンタックス要素に基づいてオクツリーを合成し得る。オクツリーのルートノードで開始すると、各オクツリーレベルにおける８つの子ノードの各々の占有が、ビットストリームにおいてシグナリングされる。そのシグナリングが、特定のオクツリーレベルにおける子ノードが占有されることを示すとき、この子ノードの子の占有がシグナリングされる。各オクツリーレベルにおけるノードのシグナリングは、後続のオクツリーレベルに進む前にシグナリングされる。オクツリーの最終レベルにおいて、各ノードがボクセル位置に対応し、リーフノードが占有されるとき、１つまたは複数のポイントが、ボクセル位置において占有されることが指定され得る。いくつかの事例では、オクツリーのいくつかの分岐が、量子化により最終レベルよりも前に終了し得る。そのような場合、リーフノードは、子ノードを有しない占有されたノードと見なされる。表面近似がジオメトリビットストリーム２０３において使用される事例では、表面近似合成ユニット３１０は、ジオメトリビットストリーム２０３からパースされたシンタックス要素に基づいて、またオクツリーに基づいて、表面モデルを決定し得る。

[0060]さらに、ジオメトリ再構成ユニット３１２は、ポイントクラウドにおけるポイントの座標を決定するために再構成を実施し得る。オクツリーのリーフノードにおける各位置について、ジオメトリ再構成ユニット３１２は、オクツリーにおけるリーフノードのバイナリ表現を使用することによって、ノード位置を再構成し得る。各それぞれのリーフノードにおいて、それぞれのリーフノードにおけるポイントの数がシグナリングされ、これは、同じボクセル位置における重複ポイントの数を示す。ジオメトリ量子化が使用されるとき、ポイント位置は、再構成されたポイント位置値を決定するためにスケーリングされる。

[0061]逆変換座標ユニット３２０は、ポイントクラウドにおけるポイントの再構成された座標（位置）を変換領域から初期領域に再びコンバートするために、再構成された座標に逆変換を適用し得る。ポイントクラウドにおけるポイントの位置は、浮動小数点領域におけるものであり得るが、Ｇ－ＰＣＣコーデックにおけるポイント位置は、整数領域においてコーディングされる。逆変換は、位置を元の領域にコンバートするために使用され得る。

[0062]さらに、図３の例では、逆量子化ユニット３０８は、属性値を逆量子化し得る。属性値は、（たとえば、属性算術復号ユニット３０４によって復号されたシンタックス要素を含む）属性ビットストリーム２０５から取得されたシンタックス要素に基づき得る。

[0063]属性値がどのように符号化されるかに応じて、ＲＡＨＴユニット３１４は、逆量子化された属性値に基づいて、ポイントクラウドのポイントについての色値を決定するためにＲＡＨＴコーディングを実施し得る。ＲＡＨＴ復号が、ツリーの上部から下部へ行われる。各レベルにおいて、逆量子化プロセスから導出された低周波数係数および高周波数係数が、成分値を導出するために使用される。リーフノードにおいて、導出された値は、それらの係数の属性値に対応する。ポイントについての重み導出プロセスは、Ｇ－ＰＣＣエンコーダ２００において使用されるプロセスと同様である。代替的に、ＬＯＤ生成ユニット３１６および逆リフティングユニット３１８は、詳細レベルベースの技法を使用してポイントクラウドのポイントについての色値を決定し得る。ＬＯＤ生成ユニット３１６は、ポイントの属性の漸進的により細かい表現を与える各ＬＯＤを復号する。予測変換を用いて、ＬＯＤ生成ユニット３１６は、前のＬＯＤにおけるものである、または同じＬＯＤにおいて前に再構成された、ポイントの重み付き和からポイントの予測を導出する。ＬＯＤ生成ユニット３１６は、属性の再構成された値を取得するために、（逆量子化の後に取得された）残差に予測を追加し得る。リフティング方式が使用されるとき、ＬＯＤ生成ユニット３１６は、属性値を導出するために使用される係数を更新するための更新オペレータをも含み得る。ＬＯＤ生成ユニット３１６は、この場合、逆適応量子化をも適用し得る。

[0064]さらに、図３の例では、逆変換色ユニット３２２は、色値に逆色変換を適用し得る。逆色変換は、エンコーダ２００の色変換ユニット２０４によって適用された色変換の逆であり得る。たとえば、色変換ユニット２０４は、色情報をＲＧＢ色空間からＹＣｂＣｒ色空間に変換し得る。したがって、逆色変換ユニット３２２は、色情報をＹＣｂＣｒ色空間からＲＧＢ色空間に変換し得る。

[0065]図２および図３の様々なユニットは、エンコーダ２００およびデコーダ３００によって実施される動作の理解を支援するために示されている。ユニットは、固定機能回路、プログラマブル回路、またはそれらの組合せとして実装され得る。固定機能回路は、特定の機能を提供する回路を指し、実施され得る動作に関してあらかじめ設定される。プログラマブル回路は、様々なタスクを実施するように、および実施され得る動作においてフレキシブルな機能を提供するようにプログラムされ得る回路を指す。たとえば、プログラマブル回路は、ソフトウェアまたはファームウェアの命令によって定義された様式でプログラマブル回路を動作させるソフトウェアまたはファームウェアを実行し得る。固定機能回路は、（たとえば、パラメータを受信するかまたはパラメータを出力するために）ソフトウェア命令を実行し得るが、固定機能回路が実施する動作のタイプは、概して不変である。いくつかの例では、ユニットのうちの１つまたは複数は、別個の回路ブロック（固定機能またはプログラマブル）であり得、いくつかの例では、ユニットのうちの１つまたは複数は、集積回路であり得る。

[0066]（Ｓｅｂａｓｔｉｅｎ Ｌａｓｓｅｒｒｅ、Ｄａｖｉｄ Ｆｌｙｎｎ、「[GPCC] Planar mode in octree-based geometry coding」、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＭＰＥＧ／ｍ４８９０６、イェーテボリ、スウェーデン、２０１９年７月）で最初に提案された平面コーディングモードは、ジュネーブ、スイスにおける第１２８回ＭＰＥＧ会議において採択された（「Ｓｅｂａｓｔｉｅｎ Ｌａｓｓｅｒｒｅ、Ｊｏｎａｔｈａｎ Ｔａｑｕｅｔ、「[GPCC] CE13.22 report on planar coding mode」、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＭＰＥＧ／ｍ５０００８、ジュネーブ、スイス、２０１９年１０月）。（Ｓｅｂａｓｔｉｅｎ Ｌａｓｓｅｒｒｅ、Ｊｏｎａｔｈａｎ Ｔａｑｕｅｔ、「[GPCC][CE 13.22 related] An improvement of the planar coding mode」、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＭＰＥＧ／ｍ５０６４２、ジュネーブ、スイス、２０１９年１０月、以下では「ｍ５０６４２」）で最初に提案された角度コーディングモードは、ブリュッセル、ベルギーにおける第１２９回ＭＰＥＧ会議において採択され（Ｓｅｂａｓｔｉｅｎ Ｌａｓｓｅｒｒｅ、Ｊｏｎａｔｈａｎ Ｔａｑｕｅｔ、「[GPCC] CE 13.22 report on angular mode」、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＭＰＥＧ／ｍ５１５９４、ブリュッセル、ベルギー、２０２０年１月、以下では「ｍ５１５９４」）、典型的なＬＩＤＡＲセンサーのセンサー特性を使用することによって平面モードのコーディング効率を向上させる。角度コーディングモードは、平面モードとともに随意に使用され、典型的なＬＩＤＡＲセンサー中でレーザービームを検知する位置および角度についての知識を採用することによって垂直（vertical）（ｚ）平面位置シンタックス要素のコーディングを改善する。さらに、角度コーディングモードは、ＩＤＣＭでの垂直ｚ位置ビットのコーディングを改善するために随意に使用され得る。別個の寄稿（Ｇｅｅｒｔ Ｖａｎ ｄｅｒ Ａｕｗｅｒａ、Ｂａｐｐａｄｉｔｙａ Ｒａｙ、Ｌｏｕｉｓ Ｋｅｒｏｆｓｋｙ、Ａｄａｒｓｈ Ｋ．Ｒａｍａｓｕｂｒａｍｏｎｉａｎ、Ｍａｒｔａ Ｋａｒｃｚｅｗｉｃｚ、「[GPCC][New Proposal] Angular mode simplifications and HLS refinements」、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＭＰＥＧ／ｍ５３６９３、遠隔会議（以前はアルプバッハ会議）、２０２０年４月）では、角度コーディングモードのコンテキスト導出が簡略化され、センサーデータパラメータのＨＬＳコーディングがより効率的にされた。以下のセクションにおける角度モードの記述は、元のＭＰＥＧ寄稿文書［ｍ５０６４２、ｍ５１５９４］と、ＧＰＣＣ ＤＩＳテキスト（Ｇ－ＰＣＣ ＤＩＳ、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１ ｗ１９６１７、遠隔会議、２０２０年１１月、以下では「ＧＰＣＣ ＤＩＳ」）とに基づく。

[0067]（Ｓｅｂａｓｔｉｅｎ Ｌａｓｓｅｒｒｅ、Ｊｏｎａｔｈａｎ Ｔａｑｕｅｔ、「[GPCC] [CE13.22 related] The azimuthal coding mode」、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＭＰＥＧ／ｍ５１５９６、ブリュッセル、ベルギー、２０２０年１月、以下では「ｍ５１５９６」）において最初に提案された方位角コーディングモードは、第１３０回ＭＰＥＧ遠隔会議において採択された（Ｓｅｂａｓｔｉｅｎ Ｌａｓｓｅｒｒｅ、Ｊｏｎａｔｈａｎ Ｔａｑｕｅｔ、「[GPCC] [CE 13.22] Report on azimuthal coding mode」、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＭＰＥＧ／ｍ５２９５８、遠隔会議（以前はアルプバッハ会議）、２０２０年４月、以下では「ｍ５２９５８」）。方位角コーディングモードは、角度モードと同様であり、角度モードを平面モードの（ｘ）および（ｙ）平面位置シンタックス要素のコーディングに拡大し、ＩＤＣＭでのｘまたはｙ位置ビットのコーディングを改善する。第１３１回ＭＰＥＧ遠隔会議における別個の寄稿（Ｇｅｅｒｔ Ｖａｎ ｄｅｒ Ａｕｗｅｒａ、Ｂａｐｐａｄｉｔｙａ Ｒａｙ、Ａｄａｒｓｈ Ｋ．Ｒａｍａｓｕｂｒａｍｏｎｉａｎ、Ｍａｒｔａ Ｋａｒｃｚｅｗｉｃｚ、「[GPCC][New Proposal] Planar and azimuthal coding mode simplifications」、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＭＰＥＧ／ｍ５４６９４、遠隔会議、２０２０年７月、以下では「ｍ５４６９４」）では、方位角モードにおいて使用されるコンテキストの数が著しく低減された。

[0068]注：「角度モード」は、以下のセクションでは方位角モードをも指すことがある。

[0069]平面コーディングモードに関係する仕様が、以下のようにＧＰＣＣ ＤＩＳにおいて要約される。
８．２．３．１ 平面コーディングモードについてのノードの適格性
ＸＸＸ 分割および再配置
［ＸＸＸ、このプロセスは、ｉｓ＿ｐｌａｎａｒ＿ｆｌａｇを復号した後の平面レート更新がなくなっている］
占有平面の明示的コーディングは、ＸＸＸの確率を条件とする。
ｋ＝０．．２について要素ＰｌａｎａｒＲａｔｅ［ｋ］をもつアレイＰｌａｎａｒＲａｔｅは、ノードの占有がｋ番目の軸に直角な単一の平面を形成する確率の推定値である。
変数ＬｏｃａｌＤｅｎｓｉｔｙは、ノード中の占有された子の平均数の推定値である。
変数ＮｕｍＮｏｄｅｓＵｎｔｉｌＰｌａｎａｒＵｐｄａｔｅは、ＰｌａｎａｒＲａｔｅとＬｏｃａｌＤｅｎｓｉｔｙとを更新する前にパースされることになるノードの数をカウントする。
［ＸＸＸ エントロピー状態継続］
ｇｅｏｍｅｔｒｙ＿ｏｃｔｒｅｅシンタックス構造をパースすることの開始時に、ＰｌａｎａｒＲａｔｅとＬｏｃａｌＤｅｎｓｉｔｙとは、以下のように初期化される：

各ｇｅｏｍｅｔｒｙ＿ｏｃｔｒｅｅ＿ｎｏｄｅシンタックス構造をパースすることの開始時に、ＮｕｍＮｏｄｅｓＵｎｔｉｌＰｌａｎａｒＵｐｄａｔｅは、減分される。ＮｕｍＮｏｄｅｓＵｎｔｉｌＰｌａｎａｒＵｐｄａｔｅが０よりも小さい場合、ＰｌａｎａｒＲａｔｅとＬｏｃａｌＤｅｎｓｉｔｙとは、以下のように更新される。

占有された兄弟ノードの数が、決定され、ＬｏｃａｌＤｅｎｓｉｔｙ推定値を更新するために使用される。

次の更新までのノードの数は、以下の通りである。

親ノードの占有情報は、各軸に沿って、単一の占有された平面の存在を決定し、対応する平面確率推定値ＰｌａｎａｒＲａｔｅ［ｋ］を更新するために使用される。

各ｇｅｏｍｅｔｒｙ＿ｏｃｔｒｅｅ＿ｎｏｄｅシンタックス構造をパースすることの開始時に、各軸について、現在のノードが平面情報をシグナリングするために適格であるかどうかが決定される。このプロセスの出力は、ｋ＝０．．２について要素ＰｌａｎａｒＥｌｉｇｉｂｌｅ［ｋ］をもつアレイＰｌａｎａｒＥｌｉｇｉｂｌｅである。
最初に、ＰｌａｎａｒＲａｔｅは、表１８に従って可能性が最も高いものから最も低いものへの３つの平面の順序ｐｌａｎｅＯｒｄｅｒ［ｋ］を決定するために使用される。
次いで、ＰｌａｎａｒＥｌｉｇｉｂｌｅは、以下のように設定される。

シンタックス要素が、ビットストリーム中にシグナリングされ得る：
１に等しいｉｓ＿ｐｌａｎａｒ＿ｆｌａｇ［ａｘｉｓＩｄｘ］は、現在のノードの子の位置が、ａｘｉｓＩｄｘ番目の軸に直角な単一の平面を形成することを示す。０に等しいｉｓ＿ｐｌａｎａｒ＿ｆｌａｇ［ａｘｉｓＩｄｘ］は、存在するとき、現在のノードの子の位置が、ａｘｉｓＩｄｘ番目の軸に直角な両方の平面を占有することを示す。
ｉｓ＿ｐｌａｎａｒ＿ｆｌａｇをコーディングするためのコンテキストインデックス（ｃｔｘＩｄｘ）が、ＧＰＣＣ ＤＩＳにおける表３７において指定され、ここで、それは、ａｘｉｓＩｄｘに等しく設定される。
８．２．３．２ 軸に沿った最も近接したノードを追跡するバッファ
アレイＰｌａｎａｒＰｒｅｖＰｏｓ、ＰｌａｎａｒＰｌａｎｅ、ＩｓＰｌａｎａｒＮｏｄｅは、シンタックス要素ｐｌａｎｅ＿ｐｏｓｉｔｉｏｎのためのｃｔｘＩｄｘの決定において使用するために前に復号されたジオメトリツリーノードに関する情報を記録する。ｇｅｏｍｅｔｒｙ＿ｐｌａｎａｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇが０に等しいか、またはｐｌａｎａｒ＿ｂｕｆｆｅｒ＿ｄｉｓａｂｌｅｄ＿ｆｌａｇが１に等しいとき、アレイは復号プロセスによって使用されない。
このプロセスでは、変数ａｘｉｓＩｄｘが、３つのコーディングされた軸のうちの１つを表すために使用され、変数ａｘｉｓＰｏｓは、ａｘｉｓＩｄｘ番目の軸に沿ったノードの位置を表す。ａｘｉｓＰｏｓの値は、０．．０ｘ３ｆｆｆのレンジ内にある。
値ＩｓＰｌａｎａｒＮｏｄｅ［ａｘｉｓＩｄｘ］［ａｘｉｓＰｏｓ］をもつアレイＩｓＰｌａｎａｒＮｏｄｅは、ａｘｉｓＰｏｓに等しいａｘｉｓＩｄｘ番目の位置成分をもつ最も最近復号されたノードがａｘｉｓＩｄｘ番目の軸に直角な平面中の平面であるのかどうかを示す。
ａｘｉｓＰｏｓに等しいａｘｉｓＩｄｘ番目の位置成分をもつ最も最近復号されたノードの最大位置成分を記憶する値ＰｌａｎａｒＰｒｅｖＰｏｓ［ａｘｉｓＩｄｘ］［ａｘｉｓＰｏｓ］をもつアレイＰｌａｎａｒＰｒｅｖＰｏｓ。
値ＰｌａｎａｒＰｌａｎｅ［ａｘｉｓＩｄｘ］［ａｘｉｓＰｏｓ］をもつアレイＰｌａｎａｒＰｌａｎｅは、ａｘｉｓＰｏｓに等しいａｘｉｓＩｄｘ番目の位置成分をもつ最も最近復号されたノードのためのｐｌａｎｅ＿ｐｏｓｉｔｉｏｎ［ａｘｉｓＩｄｘ］の値を示す。
各ジオメトリツリーレベルの開始時に、アレイＰｌａｎａｒＰｒｅｖＰｏｓおよびＩｓＰｌａｎａｒＮｏｄｅの各要素が０に初期化される。
ＸＸＸ パラメータｃｈｉｌｄＩｄｘおよびａｘｉｓＩｄｘをもつ各ｇｅｏｍｅｔｒｙ＿ｐｌａｎａｒ＿ｍｏｄｅ＿ｄａｔａシンタックス構造を復号した後に、アレイＰｌａｎａｒＰｒｅｖＰｏｓ、ＰｌａｎａｒＰｌａｎｅおよびＩｓＰｌａｎａｒＮｏｄｅが以下のように更新される。

ａｘｉｓＩｄｘ番目の軸に沿った位置を表す変数ａｘｉｓＰｏｓは、以下のように導出される。

ノードに対応するアレイエントリは、以下のように更新される。

８．２．３．３ シンタックス要素ｐｌａｎｅ＿ｐｏｓｉｔｉｏｎのためのｃｔｘＩｄｘの決定
このプロセスへの入力は、以下の通りである。

平面に垂直な（normal to）軸を識別する変数ａｘｉｓＩｄｘ、および
ジオメトリツリーレベル内の現在のノードの位置（ｓＮ，ｔＮ，ｖＮ）。
このプロセスの出力は、変数ｃｔｘＩｄｘである。
変数ｎｅｉｇｈＯｃｃｕｐｉｅｄは、両方ともａｘｉｓＩｄｘ番目の軸に沿った現在のノードに隣接するノードがあるのかどうかを示す。それは以下のように導出される：ＸＸＸ

ｐｌａｎａｒ＿ｂｕｆｆｅｒ＿ｄｉｓａｂｌｅｄ＿ｆｌａｇが１に等しいとき、ｃｔｘＩｄｘの値は、ａｄｊＰｌａｎｅＣｔｘＩｎｃに等しく設定され、さらなる処理は、このプロセスによって実施されない。そうでない場合、この項の残りが適用される。
変数ａｘｉｓＰｏｓは、ａｘｉｓＩｄｘ番目の軸に沿った現在のノードの１４個の最下位位置ビットを示す。

変数ｄｉｓｔは、現在のノードと、ａｘｉｓＩｄｘ番目の軸に沿ったａｘｉｓＰｏｓの同じ値をもつ最も最近復号された［Ｅｄ．復号されたはおそらく間違った用語である？］ノード位置との間の距離を表す。それは以下のように導出される。

コンテキストインデックスｃｔｘＩｄｘは、以下のように導出される。

８．２．３．４ 水平面位置のコーディングのためのｐｌａｎｅＰｏｓＩｄｘＡｚｉｍｕｔｈａｌＳおよびｐｌａｎｅＰｏｓＩｄｘＡｚｉｍｕｔｈａｌＴの決定
［Ｅｄ．これが上記のｃｔｘＩｄｘとどのように相互作用するかを修正する。ＮＢ：ｃｔｘＩｄｘは平面非依存でない］
ｐｌａｎｅ＿ｐｏｓｉｔｉｏｎ［０］の算術コーディングのためのｐｌａｎｅＰｏｓＩｄｘＡｎｇｕｌａｒＳ、およびｐｌａｎｅ＿ｐｏｓｉｔｉｏｎ［１］の算術コーディングのためのｐｌａｎｅＰｏｓＩｄｘＡｎｇｕｌａｒＴの決定は、以下のように取得される。
ｇｅｏｍｅｔｒｙ＿ａｎｇｕｌａｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇが０に等しいとき、ｐｌａｎｅＰｏｓＩｄｘＡｚｉｍｕｔｈａｌＳとｐｌａｎｅＰｏｓＩｄｘＡｚｉｍｕｔｈａｌＴの両方の値は、ｐｌａｎｅＰｏｓＩｄｘに等しく設定される。そうでない場合、以下が適用される。

ｐｌａｎｅ＿ｐｏｓｉｔｉｏｎ［２］の算術コーディングのためのｃｏｎｔｅｘｔＡｎｇｕｌａｒの決定は、ＸＲＥＦで説明されるように実施される。
８．２．３．５ 垂直面位置のコーディングのためのｐｌａｎｅＰｏｓＩｄｘＡｎｇｕｌａｒの決定
［Ｅｄ．これが上記のｃｔｘＩｄｘとどのように相互作用するかを修正する。ＮＢ：ｃｔｘＩｄｘは平面独立していない］
ｐｌａｎｅ＿ｐｏｓｉｔｉｏｎ［２］の算術コーディングのためのｐｌａｎｅＰｏｓＩｄｘＡｎｇｕｌａｒの決定は、以下のように取得される。
ｇｅｏｍｅｔｒｙ＿ａｎｇｕｌａｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇが０に等しいとき、ｐｌａｎｅＰｏｓＩｄｘＡｎｇｕｌａｒの値は、ｐｌａｎｅＰｏｓＩｄｘに等しく設定される。そうでない場合、以下が適用される。

ｐｌａｎｅ＿ｐｏｓｉｔｉｏｎ［２］の算術コーディングのためのｃｏｎｔｅｘｔＡｎｇｕｌａｒの決定は、セクション８．２．４．４で説明されるように実施される。
ＧＰＣＣ ＤＩＳにおける角度および方位角モード
角度モードシンタックス
角度コーディングモードが任意のコーディング効率の利益を有するために必要とされるＬｉｄａｒレーザーセンサー情報を搬送するシンタックス要素は、表２においてイタリック体である。これらのシンタックス要素のセマンティクスは、ＧＰＣＣ ＤＩＳにおいて以下のように指定される。
１に等しいｇｅｏｍｅｔｒｙ＿ｐｌａｎａｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、平面コーディングモードがアクティブ化されることを示す。０に等しいｇｅｏｍｅｔｒｙ＿ｐｌａｎａｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、平面コーディングモードがアクティブ化されないことを示す。存在しないとき、ｇｅｏｍｅｔｒｙ＿ｐｌａｎａｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇは０であると推測される。
ｇｅｏｍ＿ｐｌａｎａｒ＿ｔｈ［ｉ］は、０．．２のレンジ内のｉについて、平面コーディングモードが効率的であるためのｉ番目に可能性の高い方向に沿った平面コーディングモードについてのアクティブ化のしきい値の値を指定する。ｇｅｏｍ＿ｐｌａｎａｒ＿ｔｈ［ｉ］は、０．．１２７のレンジ内の整数である。
ｇｅｏｍ＿ｉｄｃｍ＿ｒａｔｅ＿ｍｉｎｕｓ１は、ノードが直接コーディングのために適格であり得るレートを指定する。存在しないとき、ｇｅｏｍ＿ｉｄｃｍ＿ｒａｔｅ＿ｍｉｎｕｓ１は３１であると推測される。
アレイＩｄｃｍＥｎａｂｌｅＭａｓｋは、以下のように導出される。

１に等しいｇｅｏｍｅｔｒｙ＿ａｎｇｕｌａｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、角度コーディングモードがアクティブ化されることを示す。０に等しいｇｅｏｍｅｔｒｙ＿ａｎｇｕｌａｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、角度コーディングモードがアクティブ化されないことを示す。
１に等しいｇｅｏｍ＿ｓｌｉｃｅ＿ａｎｇｕｌａｒ＿ｏｒｉｇｉｎ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、スライス相対角度原点（slice relative angular origin）がジオメトリスライスヘッダ中に存在することを指定する。０に等しいｇｅｏｍ＿ｓｌｉｃｅ＿ａｎｇｕｌａｒ＿ｏｒｉｇｉｎ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、角度原点がジオメトリスライスヘッダ中に存在しないことを指定する。存在しないとき、ｇｅｏｍ＿ｓｌｉｃｅ＿ａｎｇｕｌａｒ＿ｏｒｉｇｉｎ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは０であると推測される。
ｇｅｏｍ＿ａｎｇｕｌａｒ＿ｏｒｉｇｉｎ＿ｂｉｔｓ＿ｍｉｎｕｓ１＋１は、シンタックス要素ｇｅｏｍ＿ａｎｇｕｌａｒ＿ｏｒｉｇｉｎ＿ｘｙｚ［ｋ］のビット単位の長さである。
ｇｅｏｍ＿ａｎｇｕｌａｒ＿ｏｒｉｇｉｎ＿ｘｙｚ［ｋ］は、角度コーディングモードの処理において使用される原点の（ｘ，ｙ，ｚ）座標のｋ番目の成分を指定する。存在しないとき、ｋ＝０．．２の場合ｇｅｏｍ＿ａｎｇｕｌａｒ＿ｏｒｉｇｉｎ＿ｘｙｚ［ｋ］の値は０であると推測される。
ｇｅｏｍ＿ａｎｇｕｌａｒ＿ａｚｉｍｕｔｈ＿ｓｃａｌｅ＿ｌｏｇ２およびｇｅｏｍ＿ａｎｇｕｌａｒ＿ｒａｄｉｕｓ＿ｓｃａｌｅ＿ｌｏｇ２は、カルテシアン座標への変換中に球状座標系を使用してコーディングされた位置をスケーリングするために使用されるファクタを指定する。
ｇｅｏｍ＿ａｎｇｕｌａｒ＿ａｚｉｍｕｔｈ＿ｓｔｅｐ＿ｍｉｎｕｓ１＋１は、方位角の単位変化を指定する。角度予測ツリーコーディングにおいて使用される差分予測残差は、ｇｅｏｍ＿ａｎｇｕｌａｒ＿ａｚｉｍｕｔｈ＿ｓｔｅｐ＿ｍｉｎｕｓ１＋１の倍数として部分的に表され得る。ｇｅｏｍ＿ａｎｇｕｌａｒ＿ａｚｉｍｕｔｈ＿ｓｔｅｐ＿ｍｉｎｕｓ１の値は、（１＜＜ｇｅｏｍ＿ａｎｇｕｌａｒ＿ａｚｉｍｕｔｈ＿ｓｃａｌｅ＿ｌｏｇ２）よりも小さいものとする。
ｎｕｍｂｅｒｓ＿ｌａｓｅｒｓ＿ｍｉｎｕｓ１＋１は、角度コーディングモードのために使用されるレーザーの数を指定する。
ｌａｓｅｒ＿ａｎｇｌｅ＿ｉｎｉｔ、およびｉ＝０．．ｎｕｍｂｅｒ＿ｌａｓｅｒｓ＿ｍｉｎｕｓ１の場合のｌａｓｅｒ＿ａｎｇｌｅ＿ｄｉｆｆ［ｉ］は、第１および第２のコーディングされた軸によって定義される水平面に対するｉ番目のレーザーの仰角の正接を指定する。
ｉ＝０．．ｎｕｍｂｅｒ＿ｌａｓｅｒｓ＿ｍｉｎｕｓ１の場合のアレイＬａｓｅｒＡｎｇｌｅ［ｉ］は、以下のように導出される。

ｉ＝１．．ｎｕｍｂｅｒ＿ｌａｓｅｒｓ＿ｍｉｎｕｓ１の場合のＬａｓｅｒＡｎｇｌｅ［ｉ］の値が、ＬａｓｅｒＡｎｇｌｅ［ｉ－１］よりも大きいかまたはそれに等しいものとすることが、ビットストリーム適合の要件である。
ｌａｓｅｒ＿ｃｏｒｒｅｃｔｉｏｎ＿ｉｎｉｔ、およびｉ＝１．．ｎｕｍｂｅｒ＿ｌａｓｅｒｓ＿ｍｉｎｕｓ１の場合のｌａｓｅｒ＿ｃｏｒｒｅｃｔｉｏｎ＿ｄｉｆｆ［ｉ］は、ＧｅｏｍＡｎｇｕｌａｒＯｒｉｇｉｎ［２］に対するｉ番目のレーザー位置の、第２の内部軸に沿った補正を指定する。
ｌａｓｅｒ＿ｐｈｉ＿ｐｅｒ＿ｔｕｒｎ＿ｉｎｉｔ＿ｍｉｎｕｓ１、およびｉ＝１．．ｎｕｍｂｅｒ＿ｌａｓｅｒｓ＿ｍｉｎｕｓ１の場合のｌａｓｅｒ＿ｐｈｉ＿ｐｅｒ＿ｔｕｒｎ＿ｄｉｆｆ［ｉ］は、角度コーディングモードの処理において使用される原点に位置する回転検知システムのｉ番目のレーザーによって生成されたサンプルの数を指定する。
ｉ＝１．．ｎｕｍｂｅｒ＿ｌａｓｅｒｓ＿ｍｉｎｕｓ１の場合のアレイＬａｓｅｒＣｏｒｒｅｃｔｉｏｎ［ｉ］およびＬａｓｅｒＰｈｉＰｅｒＴｕｒｎ［ｉ］は、以下のように導出される。

ｉ＝０．．ｎｕｍｂｅｒ＿ｌａｓｅｒｓ＿ｍｉｎｕｓ１の場合のＬａｓｅｒＰｈｉＰｅｒＴｕｒｎ［ｉ］の値が０でないものとすることが、ビットストリーム適合の要件である。
ｉ＝０．．ｎｕｍｂｅｒ＿ｌａｓｅｒｓ＿ｍｉｎｕｓ１の場合のアレイＤｅｌｔａＰｈｉ［ｉ］およびＩｎｖＤｅｌｔａＰｈｉ［ｉ］は、以下のように導出される。

１に等しいｐｌａｎａｒ＿ｂｕｆｆｅｒ＿ｄｉｓａｂｌｅｄ＿ｆｌａｇは、バッファを使用して最も近いノードを追跡することが、平面モードフラグおよび平面位置を平面モードでコーディングするプロセスにおいて使用されないことを示す。０に等しいｐｌａｎａｒ＿ｂｕｆｆｅｒ＿ｄｉｓａｂｌｅｄ＿ｆｌａｇは、バッファを使用して最も近いノードを追跡することが使用されることを示す。存在しないとき、ｐｌａｎａｒ＿ｂｕｆｆｅｒ＿ｄｉｓａｂｌｅｄ＿ｆｌａｇは！ｇｅｏｍｅｔｒｙ＿ｐｌａｎａｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇであると推測される。

平面モードおよび直接モードのデータシンタックスは、それぞれ、表３および表４中に含まれる。

８．２．４．１ ノードについての角度適格性の導出プロセス
ＸＸＸ 入力／出力
ｇｅｏｍｅｔｒｙ＿ａｎｇｕｌａｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇが０に等しい場合、ａｎｇｕｌａｒ＿ｅｌｉｇｉｂｌｅは０に等しくなるように設定される。
そうでない場合、以下が適用される。
レーザー間の最小角距離を指定する変数ｄｅｌｔａＡｎｇｌｅは、以下のように導出される。

最後に、ａｎｇｕｌａｒ＿ｅｌｉｇｉｂｌｅは以下のように導出される。［Ｅｄ、ｓＮｃｈｉｌｄは確認する必要がある］

８．２．４．２ ノードに関連付けられたレーザーインデックスｌａｓｅｒＩｎｄｅｘの導出プロセス
ＸＸＸ 入力／出力
角度適格性ａｎｇｕｌａｒ＿ｅｌｉｇｉｂｌｅが０に等しい場合、ｌａｓｅｒＩｎｄｅｘインデックスはプリセット値ＵＮＫＯＷＮ＿ＬＡＳＥＲに設定される。
そうではなく、角度適格性ａｎｇｕｌａｒ＿ｅｌｉｇｉｂｌｅが１に等しい場合、８．２．５．１で説明されるプロセスの継続として以下が適用される。
第１に、Ｌｉｄａｒからの現在のノードの半径方向距離の逆数ｒＩｎｖが、以下のように決定される。

次いで、角度ｔｈｅｔａ３２は以下のように決定される。

［Ｅｄ ＸＸＸ：ｌａｓｅｒＩｎｄｅｘ［Ｐａｒｅｎｔ］は無意味であり、別の状態アレイを追加する必要がある］
最後に、角度適格性および関連付けられたレーザーが、親ノードＰａｒｅｎｔに基づいて以下のように決定される。

８．２．４．３ 平面コーディングモードのためのコンテキストｃｏｎｔｅｘｔＡｚｉｍｕｔｈａｌＳおよびｃｏｎｔｅｘｔＡｚｉｍｕｔｈａｌＴの導出プロセス
ＸＸＸ 入力／出力
８．２．５．２で説明されるプロセスの継続として以下が適用される。
第１に、２つの角度が、角度原点に対するノード位置から推論される

第２に、方位角予測子が、アレイｐｈｉＢｕｆｆｅｒから取得される

２つの方位角コンテキストが以下のように初期化される

次いで、予測子ｐｒｅｄＰｈｉが０ｘ８０００００００に等しくない場合、２つの方位角コンテキストを改良するために以下が適用される

８．２．４．４ 平面コーディングモードのためのコンテキストｃｏｎｔｅｘｔＡｎｇｕｌａｒの導出プロセス
ＸＸＸ 入力／出力
レーザーインデックスｌａｓｅｒＩｎｄｅｘがＵＮＫＯＷＮ＿ＬＡＳＥＲに等しい場合、ｃｏｎｔｅｘｔＡｎｇｕｌａｒはプリセット値ＵＮＫＯＷＮ＿ＣＯＮＴＥＸＴに設定される。そうではなく、レーザーインデックスｌａｓｅｒＩｎｄｅｘがＵＮＫＯＷＮ＿ＬＡＳＥＲに等しくない場合、８．２．５．２で説明されるプロセスの継続として以下が適用される。
第１に、下側平面および上側平面に対する２つの角度差ｔｈｅｔａＬａｓｅｒＤｅｌｔａＢｏｔおよびｔｈｅｔａＬａｓｅｒＤｅｌｔａＴｏｐが決定される。

次いで、角度コンテキストが２つの角度差から推論される。

[0070]ＧＰＣＣの動き予測。Ｇ－ＰＣＣ ＩｎｔｅｒＥＭソフトウェア（Ｇ－ＰＣＣにおけるインター予測のための探究モデル、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９ ＷＧ１１ Ｎ１８０９６、マカオ、中国、２０１８年１０月）に関与する２つの種類の動き、グローバル動き行列およびローカルノード動きベクトルがある。グローバル動きパラメータは、予測（参照）フレームにおける（ローカル動きモードが適用されているポイントを除く）すべてのポイントに対して適用されることになる回転行列および並進ベクトルとして定義される。オクツリーのノードのローカルノード動きベクトルは、予測（参照）フレームにおけるノード内のポイントに対してのみ適用される動きベクトルである。ＩｎｔｅｒＥＭにおける動き推定アルゴリズムの詳細が以下で説明される。

[0071]図４は、ＩｎｔｅｒＥＭのための例示的な動き推定技法を示すフローチャートである。入力予測（参照）フレームと現在フレームとが与えられると、グローバル動きがグローバルスケールにおいて最初に推定される。予測に対してグローバル動きを適用した後に、ローカル動きが、オクツリーにおけるより細かいスケールのノードレベルにおいて推定される。最後に、推定されたローカルノード動きが、動き補償において適用される。

[0072]上記の技法の詳細が以下で説明される。

[0073]グローバル動き行列および並進ベクトルを推定するための方法。図５は、ローカルノード動きベクトルの推定のための例示的な技法を示すフローチャートである。図５に示されているように、動きベクトルは、再帰的様式で推定される。最良の好適な動きベクトルを選定するために使用されるコスト関数は、レートひずみコストに基づき得る。

[0074]現在のノードが８つの子に分割されない場合、現在のノードと予測ノードとの間の最低コストを生じ得る動きベクトルが決定される。現在のノードが８つの子に分けられた場合、動き推定アルゴリズムが適用され、分割条件下での総コストが、各子ノードの推定されたコスト値を加算することによって取得される。分離すべきなのか、分離すべきでないのかの決定は、分割することと分割しないこととの間のコストを比較することによって到達され、分割される場合、各サブノードは、それのそれぞれの動きベクトルを割り当てられ（または、それの子にさらに分割され得）、分割されない場合、現在のノードは、動きベクトルを割り当てられる。

[0075]動きベクトル推定の性能に影響を及ぼす２つのパラメータは、ブロックサイズ（ＢｌｏｃｋＳｉｚｅ）と最小予測ユニットサイズ（ＭｉｎＰＵＳｉｚｅ）とである。ＢｌｏｃｋＳｉｚｅは、動きベクトル推定を適用するためのノードサイズの上限を定義し、ＭｉｎＰＵＳｉｚｅは、下限を定義する。

[0076]上記で説明された技法は、１つまたは複数の欠点を提示し得る。ノードの参照ブロックは、推定された動き情報（回転および並進）を使用する動き補償によって導出される。動き情報の良好な推定が、現在のノードと参照ノードとの間の、占有、平面情報など、ジオメトリ構造に関する高相関につながる。したがって、参照ノードのこのジオメトリ情報を利用することが、現在のノードのコーディング性能を改善することになる。本開示の１つまたは複数の技法によれば、Ｇ－ＰＣＣコーダ（たとえば、Ｇ－ＰＣＣエンコーダ２００またはＧ－ＰＣＣデコーダ３００）が、現在のノードの平面情報のコーディングにおいて参照ブロックの情報を利用し得る。一例として、Ｇ－ＰＣＣコーダは、平面コーディングモードのためのノードの適格性、平面フラグおよび平面インデックスをコーディングする際のコンテキストの選択において参照ブロックの情報を利用し得る。本文書で開示される１つまたは複数の技法は、独立してまたは組み合わされて適用され得る。

[0077]インター予測を使用するノードの平面適格性。一例では、ＰｌａｎａｒＲａｔｅは、参照ブロックの平面情報に依存するファクタ（Ｒ）によって更新され得る。この例では、ＧＰＣＣ ＤＩＳにおけるセクション８．２．３．１におけるＰｌａｎａｒＲａｔｅは、以下として指定され得る（追加が太字イタリック体で示されている）。
親ノードの占有情報は、各軸に沿って、単一の占有された平面の存在を決定し、対応する平面確率推定値ＰｌａｎａｒＲａｔｅ［ｋ］を更新するために使用される。

ここで、Ｒ［ｋ］は、参照ブロックがｋ番目の方向において平面モードであるかどうかに依存するスケーリングファクタである。一例では、参照ブロックがｋ番目の方向において平面である場合、Ｒ［ｋ］は１よりも高く設定され得る。そうでない場合、Ｒ［ｋ］は１よりも低く設定され得る。

[0078]別の例では、ＰｌａｎａｒＥｌｉｇｉｂｌｅは、参照ブロックが平面でない場合、許容されないことがある。
次いで、ＰｌａｎａｒＥｌｉｇｉｂｌｅは、以下のように設定される。

[0079]代替的に、参照平面レート（ＰｌａｎａｒＲａｔｅＲｅｆ）が参照ブロックの平面性に基づいて別々に決定され得る。さらに、平面モードのための現在のノードの適格性が、参照平面レートをしきい値と比較することに基づいて決定され得る。たとえば：
[0080]次いで、ＰｌａｎａｒＥｌｉｇｉｂｌｅは、以下のように設定される。

[0081]いくつかの場合には、平面インデックス位置は、参照ノードの平面インデックス位置に基づいて導出される。いくつかの場合には、この決定は、しきい値比較に基づき得る。

[0082]平面コピーモード（ＰＣＭ）。Ｇ－ＰＣＣコーダが、現在のノードと参照ノードとがすべての方向において同じ平面モードを共有するかどうかを示すために、ビットストリームにおいてフラグ（ＰＣＭフラグ）をシグナリングし得る（たとえば、ｋ＝０．．２）。このフラグが１であるとき、デコーダは、各方向について平面フラグを復号する必要がないことがあり、デコーダは、参照ノードにおける対応する値のみを使用する（たとえば、平面フラグは、参照ノードからコピーされ得る）。フラグが０であるとき、各方向における平面フラグはシグナリングされ得る。

[0083]さらなるレベルのＰＣＭフラグにおいて、それは、現在のノードと参照ノードとが平面位置インデックスを共有するかどうかをも示し得る。この例では、ＰＣＭフラグが１である場合、ｋ番目の方向において、デコーダは、平面位置インデックスを復号する必要がなく、デコーダは、同じｋ番目の方向において参照ブロックにおける平面インデックスを使用し得る。

[0084]いくつかの例では、ＰＣＭフラグは、条件付きでシグナリングされ得る。たとえば、参照ブロックの占有は０であり、ＰＣＭフラグは、シグナリングされないことがあり、０であるように暗黙的に設定され得る。いくつかの例では、スライスヘッダまたはＳＰＳヘッダ中のフラグが、ＰＣＭモードをアクティブ化または非アクティブ化するために定義され得る。

[0085]インター予測を使用する平面フラグのシグナリングにおけるコンテキスト選択。平面フラグ（ｉｓ＿ｐｌａｎａｒ＿ｆｌａｇ）をシグナリングするための３つのコンテキストがあり得る。インデックスの選択は、単に、方向インデックス（ａｘｉｓＩｄｘ）によって選択される。本開示の１つまたは複数の技法によれば、平面フラグを符号化するためのコンテキストは、参照ノードの平面モードを使用して拡張され得る。拡張の一例が以下のように説明され得る。
このプロセスへの入力は、以下の通りである。

－ 現在のノードの子を識別する変数ｃｈｉｌｄＩｄｘ、
－ 平面に垂直な軸を識別する変数ａｘｉｓＩｄｘ、および
－ ジオメトリツリーレベル内の現在のノードの位置（ｓＮ，ｔＮ，ｖＮ）。
このプロセスの出力は、変数ｃｔｘＩｄｘである。ｃｔｘＩｄｘの値は、（２＊ａｘｉｓＩｄｘ＋ＰｌａｎａｒＭｏｄｅＲｅｆ［ａｘｉｓＩｄｘ］）に等しく設定され、さらなる処理は実施されない。

[0086]この例では、ＰｌａｎａｒＭｏｄｅＲｅｆ［ａｘｉｓＩｄｘ］は、参照ノードがａｘｉｓＩｄｘ方向において平面であるかどうかを示す。

[0087]インターモードを使用するシンタックス要素ｐｌａｎｅ＿ｐｏｓｉｔｉｏｎのためのＣｔｘＩｄｘ決定。ＧＰＣＣ ＤＩＳでは、ｐｌａｎｅ＿ｐｏｓｉｔｉｏｎを符号化するために使用されるコンテキストインデックスは、以下のように、ａｘｉｓＩｄｘ、近傍占有に基づく平面位置予測、同じバッファ行インデックスにおける最も近いすでにコーディングされたノードがｉｓＰｌａｎａｒ、ｐｌａｎｅＰｏｓｉｔｉｏｎ、距離測度を含んでいると決定するためのバッファルックアップ、の関数である（セクション８．２．３．３）。
コンテキストインデックスｃｔｘＩｄｘは、以下のように導出される。

[0088]本開示の一例では、参照ブロックの占有および平面モードが、平面位置コーディングのコンテキストインデックスを決定するための追加のパラメータとして使用され得る。

[0089]ＰｌａｎａｒＭｏｄｅＲｅｆおよびＲｅｆＰｌａｎｅを、参照ブロックにおける平面モードおよび平面位置とする。

[0090]ＰｌａｎａｒＭｏｄｅＲｅｆ［ａｘｉｓＩｄｘ］が０である場合、ＲｅｆＰｌａｎｅ［ａｘｉｓＩｄｘ］は、－１に等しく設定される。

[0091]一例では、ＲｅｆＰｌａｎｅ［ａｘｉｓＩｄｘ］は、ｐｒｅｖＰｌａｎｅを置換するために使用され得る。

[0092]別の例では、ｃｔｘＩｄｘは以下のように更新され得る。

ここで、Ｎは、ａｘｉｓＩｄｘ、ａｄｊＰｌａｎｅＣｔｘＩｎｃ、ｄｉｓｔＣｔｘＩｎｃ、およびｐｒｅｖＰｌａｎｅのみを使用してサポートされたコンテキストの数である。現在のドラフトＧＰＣＣ ＤＩＳでは、Ｎは３６である。

[0093]別の例では、参照ブロックの占有および平面位置は、コンテキストを導出するための近傍占有を置換するために使用され得る。

[0094]また別の例では、平面フラグのためのコンテキストインデックスは、以下のように、参照ブロックの方向インデックスおよび平面モードのみを使用して導出され得る。

[0095]インター予測を使用する平面コーディングモードのためのコンテキストｃｏｎｔｅｘｔＡｎｇｕｌａｒの導出プロセス。Ｍを、平面位置をコーディングするためにｃｏｎｔｅｘｔＡｎｇｕｌａｒのためにサポートされるコンテキストの数とする。ｃｏｎｔｅｘｔＡｎｇｕｌａｒがセクション３．３．５の場合のように導出された後に、それは、参照ブロックの平面モードおよび平面位置を使用して更新され得る。

[0096]一例では、セクション３．３．５におけるｃｏｎｔｅｘｔＡｎｇｕｌａｒは、以下のように更新され得る。

[0097]いくつかの場合には、ＰｌａｎａｒＭｏｄｅＲｅｆ［ａｘｉｓＩｄｘ］が０である場合、ＲｅｆＰｌａｎｅ［ａｘｉｓＩｄｘ］は、－１に等しく設定される。ｃｏｎｔｅｘｔＡｎｇｕｌａｒ値は、以下のように割り当てられ得る。
次いで、角度コンテキストが２つの角度差から推論される。

[0098]別の例では、ＰｌａｎａｒＭｏｄｅＲｅｆ［ａｘｉｓＩｄｘ］が０である場合、ＲｅｆＰｌａｎｅ［ａｘｉｓＩｄｘ］は、０に等しく設定される。

[0099]ｃｏｎｔｅｘｔＡｎｇｕｌａｒ値は、以下のように割り当てられ得る。
次いで、角度コンテキストが２つの角度差から推論される。

[0100]平面コーディングモードのためのインター予測と組み合わせられたコンテキストｃｏｎｔｅｘｔＡｚｉｍｕｔｈａｌＳおよびｃｏｎｔｅｘｔＡｚｉｍｕｔｈａｌＴの導出プロセス。

[0101]８．２．４．３においてコンテキストｃｏｎｔｅｘｔＡｚｉｍｕｔｈａｌＳおよびｃｏｎｔｅｘｔＡｚｉｍｕｔｈａｌＴが導出された後に、それらは、インター参照ブロックの平面モードの使用とともに更新され得る。

[0102]いくつかの場合には、ＰｌａｎａｒＭｏｄｅＲｅｆ［ａｘｉｓＩｄｘ］が０である場合、ＲｅｆＰｌａｎｅ［ａｘｉｓＩｄｘ］は、－１に等しく設定される。以下の修正が行われ得る。

[0103]いくつかの場合には、ＰｌａｎａｒＭｏｄｅＲｅｆ［ａｘｉｓＩｄｘ］が０である場合、ＲｅｆＰｌａｎｅ［ａｘｉｓＩｄｘ］は、０に等しく設定される。以下の修正が行われ得る。

[0104]インター予測を用いたコンテキスト占有コーディング。

[0105]ＩｎｔｅｒＥＭのための参照ソフトウェアでは、占有ビットのためのコンテキスト導出は、以下のように導出される。

[0106]上記の計算では、インター予測（ｃｔｘＩｎｔｅｒ）に関連付けられたコンテキストは、！！ｍａｐｐｅｄＰｒｅｄ、ｂｉｔＰｒｅｄ、ｂｉｔＰｒｅｄＳｔｒｏｎｇの和である。本開示の１つまたは複数の技法によれば、ｃｔｘＩｄｘＭａｐＩｄｘは、次のように修正され得る。

[0107]動きベースしきい値。しきい値が、動きベクトル／動きパラメータに基づいて定義され得、このしきい値は、本文書で開示される１つまたは複数の決定において使用され得る。

[0108]たとえば、しきい値は、回転（たとえば、回転の角度）または並進（たとえば、並進の大きさ）に関連付けられた大きさ／パラメータに基づいて決定され得、回転に関連付けられた角度がｘであり、並進の大きさがｙである場合、しきい値は、ｘおよびｙの関数として導出され得る（たとえば、線形結合ａ＊ｘ＋ｂ＊ｙ、ここで、ａおよびｂは固定値である）。

[0109]他の代替形態では、各軸に関連付けられたしきい値は、別々に導出され得、たとえば、軸に関連付けられた並進は、軸に関連付けられたしきい値を導出するために使用され得る。

[0110]しきい値に基づいて、１つまたは複数の決定が行われ得る。たとえば、ポイントがゼロ動きに関連付けられ、ゼロ動きに関連付けられたしきい値が、（ＰＣＭに関して上記で説明されたように）ノードの平面適格性を決定するために使用され得、ポイントに関連付けられた動きがより大きいとき、異なるしきい値が平面適格性決定のために使用され得る。

[0111]別の例では、しきい値（または動きパラメータ）が特定の固定値を超えるとき、本文書で開示される１つまたは複数の決定が無効にされ得る。

[0112]異なる決定のために、異なるしきい値が使用され得る。しきい値はまた、ビットストリーム中でシグナリングされ得る。

[0113]本開示の様々な態様における例は、個別にまたは任意の組合せで使用され得る。

[0114]図６は、本開示の１つまたは複数の技法とともに使用され得る例示的なレンジ測定システム７００を示す概念図である。図６の例では、レンジ測定システム７００は、照明器７０２とセンサー７０４とを含む。照明器７０２は、光７０６を放出し得る。いくつかの例では、照明器７０２は、１つまたは複数のレーザービームとして光７０６を放出し得る。光７０６は、赤外波長または可視光波長など、１つまたは複数の波長におけるものであり得る。他の例では、光７０６は、コヒーレントなレーザー光ではない。光７０６が、物体７０８など、物体に遭遇したとき、光７０６は、戻り光７１０をもたらす。戻り光７１０は、後方散乱光および／または反射光を含み得る。戻り光７１０は、センサー７０４上に物体７０８の画像７１２をもたらすように戻り光７１０を向けるレンズ７１１を通過し得る。センサー７０４は、画像７１２に基づいて信号７１４を生成する。画像７１２は、（たとえば、図６の画像７１２中のドットによって表される）ポイントのセットを備え得る。

[0115]いくつかの例では、照明器７０２およびセンサー７０４は、照明器７０２およびセンサー７０４が環境の３６０度視野をキャプチャするように、スピニング構造物上に搭載され得る（たとえば、スピニングＬＩＤＡＲセンサー）。他の例では、レンジ測定システム７００は、照明器７０２およびセンサー７０４が特定のレンジ内（たとえば、３６０度まで）の物体のレンジを検出することを可能にする１つまたは複数の光学構成要素（たとえば、ミラー、コリメータ、回折格子など）を含み得る。図６の例は、単一の照明器７０２およびセンサー７０４のみを示すが、レンジ測定システム７００は、照明器およびセンサーの複数のセットを含み得る。

[0116]いくつかの例では、照明器７０２は、構造化された光パターンを生成する。そのような例では、レンジ測定システム７００は、構造化された光パターンのそれぞれの画像が形成される複数のセンサー７０４を含み得る。レンジ測定システム７００は、構造化された光パターンが後方散乱する物体７０８までの距離を決定するために、構造化された光パターンの画像間の視差を使用し得る。構造化された光ベースのレンジ測定システムは、物体７０８がセンサー７０４に比較的近い（たとえば、０．２メートル～２メートル）とき、高レベルの精度（たとえば、サブミリメートルレンジの精度）を有し得る。この高レベルの精度は、モバイルデバイス（たとえば、モバイルフォン、タブレットコンピュータなど）のロック解除などの顔認識用途において、およびセキュリティ用途のために有用であり得る。

[0117]いくつかの例では、レンジ測定システム７００は、飛行時間（ＴｏＦ）ベースのシステムである。レンジ測定システム７００がＴｏＦベースのシステムであるいくつかの例では、照明器７０２は、光のパルスを生成する。言い換えれば、照明器７０２は、放出された光７０６の振幅を変調し得る。そのような例では、センサー７０４は、照明器７０２によって生成された光７０６のパルスからの戻り光７１０を検出する。レンジ測定システム７００は、次いで、光７０６が放出され検出されたときと空気中の既知の光速との間の遅延に基づいて光７０６が後方散乱する物体７０８までの距離を決定し得る）。いくつかの例では、放出された光７０６の振幅を変調する代わりに（またはそれに加えて）、照明器７０２は、放出された光７０６の位相を変調し得る。そのような例では、センサー７０４は、物体７０８からの戻り光７１０の位相を検出し、光速を使用して、および照明器７０２が特定の位相で光７０６を生成したときとセンサー７０４が特定の位相で戻り光７１０を検出したときとの間の時間差に基づいて、物体７０８上のポイントまでの距離を決定し得る。

[0118]他の例では、ポイントクラウドは、照明器７０２を使用することなく生成され得る。たとえば、いくつかの例では、レンジ測定システム７００のセンサー７０４は、２つまたはそれ以上の光学カメラを含み得る。そのような例では、レンジ測定システム７００は、物体７０８を含む環境のステレオ画像をキャプチャするために光学カメラを使用し得る。レンジ測定システム７００は、ステレオ画像中のロケーション間の視差を計算し得るポイントクラウド生成器７１６を含み得る。レンジ測定システム７００は、次いで、ステレオ画像に示されたロケーションまでの距離を決定するために視差を使用し得る。これらの距離から、ポイントクラウド生成器７１６は、ポイントクラウドを生成し得る。

[0119]センサー７０４はまた、色および反射率情報など、物体７０８の他の属性を検出し得る。図６の例では、ポイントクラウド生成器７１６は、センサー７０４によって生成された信号７１４に基づいてポイントクラウドを生成し得る。レンジ測定システム７００および／またはポイントクラウド生成器７１６は、データソース１０４（図１）の一部を形成し得る。したがって、レンジ測定システム７００によって生成されたポイントクラウドは、本開示の技法のいずれかに従って符号化および／または復号され得る。

[0120]図７は、本開示の１つまたは複数の技法が使用され得る例示的な車両ベースのシナリオを示す概念図である。図７の例では、車両８００が、レンジ測定システム８０２を含む。レンジ測定システム８０２は、図１０７に関して説明される様式で実装され得る。図７の例には示されていないが、車両８００はまた、データソース１０４（図１）などのデータソースと、Ｇ－ＰＣＣエンコーダ２００（図１）などのＧ－ＰＣＣエンコーダとを含み得る。図７の例では、レンジ測定システム８０２は、歩行者８０６または道路内の他の物体から反射するレーザービーム８０４を放出する。車両８００のデータソースは、レンジ測定システム８０２によって生成された信号に基づいてポイントクラウドを生成し得る。車両８００のＧ－ＰＣＣエンコーダは、ジオメトリビットストリーム（図２）および属性ビットストリーム（図２）などのビットストリーム８０８を生成するために、ポイントクラウドを符号化し得る。ビットストリーム８０８は、Ｇ－ＰＣＣエンコーダによって取得された符号化されていないポイントクラウドよりもはるかに少ないビットを含み得る。

[0121]車両８００の出力インターフェース（たとえば、出力インターフェース１０８（図１））は、ビットストリーム８０８を１つまたは複数の他のデバイスに送信し得る。ビットストリーム８０８は、Ｇ－ＰＣＣエンコーダによって取得された符号化されていないポイントクラウドよりもはるかに少ないビットを含み得る。したがって、車両８００は、符号化されていないポイントクラウドデータよりも迅速にビットストリーム８０８を他のデバイスに送信することが可能であり得る。さらに、ビットストリーム８０８は、より少ないデータ記憶容量を必要とし得る。

[0122]図７の例では、車両８００は、ビットストリーム８０８を別の車両８１０に送信し得る。車両８１０は、Ｇ－ＰＣＣデコーダ３００（図１）などのＧ－ＰＣＣデコーダを含み得る。車両８１０のＧ－ＰＣＣデコーダは、ポイントクラウドを再構成するためにビットストリーム８０８を復号し得る。車両８１０は、様々な目的で、再構成されたポイントクラウドを使用し得る。たとえば、車両８１０は、歩行者８０６が車両８００の前方の道路におり、したがって、たとえば、歩行者８０６が道路にいることを車両８１０の運転者が了解する前でも、減速を開始することを、再構成されたポイントクラウドに基づいて決定し得る。したがって、いくつかの例では、車両８１０は、再構成されたポイントクラウドに基づいて、自律ナビゲーション動作を実施し得る。

[0123]追加または代替として、車両８００は、ビットストリーム８０８をサーバシステム８１２に送信し得る。サーバシステム８１２は、様々な目的でビットストリーム８０８を使用し得る。たとえば、サーバシステム８１２は、ポイントクラウドの後続の再構成のためにビットストリーム８０８を記憶し得る。この例では、サーバシステム８１２は、自律運転システムを訓練するために他のデータ（たとえば、車両８００によって生成された車両テレメトリデータ）とともにポイントクラウドを使用し得る。他の例では、サーバシステム８１２は、科学捜査的事故調査のための後続の再構成のためにビットストリーム８０８を記憶し得る。

[0124]図８は、本開示の１つまたは複数の技法が使用され得る例示的なエクステンデッドリアリティシステムを示す概念図である。エクステンデッドリアリティ（ＸＲ：extended reality）は、拡張現実（ＡＲ）と、複合現実（ＭＲ）と、仮想現実（ＶＲ）とを含む技術の範囲をカバーするために使用される用語である。図８の例では、ユーザ９００が、第１のロケーション９０２に位置する。ユーザ９００は、ＸＲヘッドセット９０４を装着する。ＸＲヘッドセット９０４の代替として、ユーザ９００は、モバイルデバイス（たとえば、モバイルフォン、タブレットコンピュータなど）を使用し得る。ＸＲヘッドセット９０４は、ロケーション９０２における物体９０６上のポイントの位置を検出する、レンジ測定システムなどの深度検出センサーを含む。ＸＲヘッドセット９０４のデータソースは、ロケーション９０２における物体９０６のポイントクラウド表現を生成するために、深度検出センサーによって生成された信号を使用し得る。ＸＲヘッドセット９０４は、ビットストリーム９０８を生成するためにポイントクラウドを符号化するように構成されたＧ－ＰＣＣエンコーダ（たとえば、図１のＧ－ＰＣＣエンコーダ２００）を含み得る。

[0125]ＸＲヘッドセット９０４は、第２のロケーション９１４においてユーザ９１２によって装着されたＸＲヘッドセット９１０に（たとえば、インターネットなどのネットワークを介して）ビットストリーム９０８を送信し得る。ＸＲヘッドセット９１０は、ポイントクラウドを再構成するためにビットストリーム９０８を復号し得る。ＸＲヘッドセット９１０は、ロケーション９０２における物体９０６を表すＸＲ視覚化（たとえば、ＡＲ、ＭＲ、ＶＲ視覚化）を生成するためにポイントクラウドを使用し得る。したがって、いくつかの例では、ＸＲヘッドセット９１０がＶＲ視覚化を生成するときなど、ユーザ９１２は、ロケーション９０２の３Ｄ没入型体験を有し得る。いくつかの例では、ＸＲヘッドセット９１０は、再構成されたポイントクラウドに基づいて仮想物体の位置を決定し得る。たとえば、ＸＲヘッドセット９１０は、再構成されたポイントクラウドに基づいて、環境（たとえば、ロケーション９０２）が平坦な表面を含むと決定し、次いで、仮想物体（たとえば、漫画のキャラクタ）が平坦な表面上に配置されるべきであると決定し得る。ＸＲヘッドセット９１０は、仮想物体が決定された位置にあるＸＲ視覚化を生成し得る。たとえば、ＸＲヘッドセット９１０は、平坦な表面に座っている漫画のキャラクタを示し得る。

[0126]図９は、本開示の１つまたは複数の技法が使用され得る例示的なモバイルデバイスシステムを示す概念図である。図９の例では、モバイルフォンまたはタブレットコンピュータなどのモバイルデバイス１０００（たとえば、ワイヤレス通信デバイス）は、モバイルデバイス１０００の環境における物体１００２上のポイントの位置を検出する、ＬＩＤＡＲシステムなどのレンジ測定システムを含む。モバイルデバイス１０００のデータソースは、物体１００２のポイントクラウド表現を生成するために、深度検出センサーによって生成された信号を使用し得る。モバイルデバイス１０００は、ビットストリーム１００４を生成するためにポイントクラウドを符号化するように構成されたＧ－ＰＣＣエンコーダ（たとえば、図１のＧ－ＰＣＣエンコーダ２００）を含み得る。図９の例では、モバイルデバイス１０００は、サーバシステムまたは他のモバイルデバイスなどのリモートデバイス１００６にビットストリームを送信し得る。リモートデバイス１００６は、ポイントクラウドを再構成するためにビットストリーム１００４を復号し得る。リモートデバイス１００６は、様々な目的でポイントクラウドを使用し得る。たとえば、リモートデバイス１００６は、モバイルデバイス１０００の環境のマップを生成するためにポイントクラウドを使用し得る。たとえば、リモートデバイス１００６は、再構成されたポイントクラウドに基づいて建物の内部のマップを生成し得る。別の例では、リモートデバイス１００６は、ポイントクラウドに基づいて像（たとえば、コンピュータグラフィックス）を生成し得る。たとえば、リモートデバイス１００６は、ポイントクラウドのポイントを多角形の頂点として使用し、ポイントの色属性を多角形に陰影を付けるための基礎として使用し得る。いくつかの例では、リモートデバイス１００６は、顔認識または他のセキュリティ用途のために再構成されたポイントクラウドを使用し得る。

[0127]図１０Ａおよび図１０Ｂは、ビンｎにおけるこのプロセスの例を示す。図１０Ａの例２０１では、あるコンテキスト状態（σ）を与えられれば、ビンｎにおけるレンジは、ＬＰＳ（ｐ_σ）の確率によって与えられるＲａｎｇｅＭＰＳとＲａｎｇｅＬＰＳとを含む。例２０１は、ビンｎの値がＭＰＳに等しいときのビンｎ＋１におけるレンジの更新を示す。この例では、低は同じままであるが、ビンｎ＋１におけるレンジの値は、ビンｎにおけるＲａｎｇｅＭＰＳの値に低減される。図１０Ｂの例２０３は、ビンｎの値がＭＰＳに等しくない（すなわち、ＬＰＳに等しい）ときのビンｎ＋１におけるレンジの更新を示す。この例では、低は、ビンｎにおけるＲａｎｇｅＬＰＳのより低いレンジ値に動かされる。さらに、ビンｎ＋１におけるレンジの値は、ビンｎにおけるＲａｎｇｅＬＰＳの値に低減される。

[0128]いくつかの例では、レンジは９ビットで表され、低は１０ビットで表され得る。レンジ値および低値を十分な精度で維持するための再正規化プロセスがある。レンジが２５６よりも小さいときはいつでも、再正規化が行われる。したがって、レンジは、再正規化の後、常に２５６に等しいかまたはそれよりも大きい。レンジの値と低の値とに応じて、ＢＡＣは、ビットストリームに「０」または「１」を出力するか、または将来の出力のために保持するために（ＢＯ：未解決ビット（bits-outstanding）と呼ばれる）内部変数を更新する。図１１は、レンジに応じたＢＡＣ出力の例を示す。たとえば、レンジおよび低が、あるしきい値（たとえば、５１２）を上回るとき、ビットストリームに「１」が出力される。レンジおよび低が、あるしきい値（たとえば、５１２）を下回るとき、ビットストリームに「０」が出力される。レンジおよび下側が、あるしきい値間にあるとき、ビットストリームに何も出力されない。代わりに、ＢＯ値が増分され、次のビンが符号化される。

[0129]上記で説明されたように、算術コーディング方法は、高い圧縮効率を提供するために使用され得る。これは、最初に、２値化と呼ばれるプロセスを使用して非バイナリシンタックス要素をバイナリ表現（たとえば、０、１）に変換することによって達成され得る。得られた変換されたエントリは、ビンまたはビンストリングと呼ばれる。これらのビンまたはビンストリングは、次いで、算術コーディングプロセスに供給される。図１１は、例示的なコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）符号化段を示す。例示的なＣＡＢＡＣ符号化段は、図２のＧ－ＰＣＣエンコーダ２００の算術符号化ユニット２１４および／または算術符号化ユニット２２６によってなど、Ｇ－ＰＣＣエンコーダにおいて実装され得る。

[0130]Ｇ－ＰＣＣのいくつかの例では、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）は、２値化プロセスを通してビンを生成するために使用され得る。各コーディングされたビン値について、適切なコンテキストモデルが選択される。これらのコンテキストモデルは、ビン確率値に基づいて各ビン値を出力ビットに符号化するために使用される。ＣＡＢＡＣエンジンは、ビンが０または１と同程度の確率があるとき、コンテキストモデル化およびビン符号化をバイパスする。これは、以下で説明されるバイパスコーディング段である。そうでない場合、適切なコンテキストモデルが、ビン値が符号化されるときに指定され、ビン値の確率に基づいてモデル化する。コンテキストは、エンコーダがより多くのビンを符号化するにつれて、適応される。最後に、コンテキストコーディングされたビン値または生ビットストリームが、デコーダに送信されるかまたはさもなければ提供される。

[0131]図１２は、本開示の技法による、ＣＡＢＡＣを実施するように構成され得る例示的な算術符号化ユニット２１４のブロック図である。シンタックス要素１１８０が算術符号化ユニット２１４に入力される。シンタックス要素がすでにバイナリ値シンタックス要素（たとえば、フラグ、または０および１の値のみを有する他のシンタックス要素）である場合、２値化のステップはスキップされ得る。シンタックス要素が非バイナリ値シンタックス要素（たとえば、１または０以外の値を有し得るシンタックス要素）である場合、非バイナリ値シンタックス要素はバイナライザ１２００によって２値化される。バイナライザ１２００は、バイナリ決定のシーケンスへの非バイナリ値シンタックス要素のマッピングを実施する。これらのバイナリ決定は、しばしば「ビン」と呼ばれる。たとえば、変換係数レベルでは、レベルの値は連続するビンに分けられ得、各ビンは、係数レベルの絶対値がある値よりも大きいか否かを示す。たとえば、（有意性フラグと呼ばれることがある）ビン０は、変換係数レベルの絶対値が０よりも大きいか否かを示す。ビン１は、変換係数レベルの絶対値が１よりも大きいか否かを示す、などである。各非バイナリ値シンタックス要素について、一意のマッピングが作成され得る。

[0132]バイナライザ１２００によって生成された各ビンは、算術符号化ユニット２１４のバイナリ算術コーディング側に供給される。すなわち、非バイナリ値シンタックス要素の所定のセットについて、各ビンタイプ（たとえば、ビン０）が次のビンタイプ（たとえば、ビン１）の前にコーディングされる。コーディングは、通常モードまたはバイパスモードのいずれかで実施され得る。バイパスモードでは、バイパス符号化エンジン１２６０が、固定確率モデルを使用して、たとえば、ゴロム－ライスまたは指数ゴロムコーディングを使用して、算術コーディングを実施する。バイパスモードは、概して、より予測可能なシンタックス要素のために使用される。

[0133]通常モードでのコーディングは、ＣＡＢＡＣを実施することを伴う。通常モードＣＡＢＡＣは、ビンの値の確率が、前にコーディングされたビンの値を与えられれば予測可能である場合に、ビン値をコーディングするためのものである。ビンがＬＰＳである確率がコンテキストモデラ１２２０によって決定される。コンテキストモデラ１２２０は、ビン値とコンテキストのための確率状態（たとえば、ＬＰＳの値と、ＬＰＳが発生する確率とを含む確率状態σ）とを出力する。コンテキストは、一連のビンのための初期コンテキストであり得るか、または前にコーディングされたビンのコーディングされた値に基づいて決定され得る。コンテキストの識別情報が、変数ｃｔｘＩｎｃの値（前のコンテキストに適用すべき増分を表すｃｔｘＩｎｃの値など、コンテキスト増分）に基づいて表され、および／または決定され得る。上記で説明されたように、コンテキストモデラ１２２０は、受信されたビンがＭＰＳであったのかＬＰＳであったのか否かに基づいて状態を更新し得る。コンテキストおよび確率状態σがコンテキストモデラ１２２０によって決定された後、通常符号化エンジン１２４０はビン値に対してＢＡＣを実施する。

[0134]図１３は、本開示の技法による、ＣＡＢＡＣを実施するように構成され得る例示的な算術復号ユニット３０２のブロック図である。図１３の算術復号ユニット３０２は、図１２で説明された算術符号化ユニット２１４の様式とは逆の様式でＣＡＢＡＣを実施する。ビットストリーム２１８０からのコーディングされたビットが算術復号ユニット３０２に入力される。コーディングされたビットは、それらが通常モードを使用してエントロピーコーディングされたのか、バイパスモードを使用してエントロピーコーディングされたのかに基づいて、コンテキストモデラ２２００またはバイパス復号エンジン２２２０のいずれかに供給される。コーディングされたビットがバイパスモードでコーディングされた場合、バイパス復号エンジンは、たとえば、バイナリ値シンタックス要素または非バイナリシンタックス要素のビンを取り出すために、ゴロム－ライスまたは指数ゴロム復号を使用することになる。

[0135]コーディングされたビットが通常モードでコーディングされた場合、コンテキストモデラ２２００はコーディングされたビットのための確率モデルを決定し得、通常復号エンジン２２４０は、非バイナリ値シンタックス要素のビン（または、バイナリ値の場合、シンタックス要素自体）を生成するために、コーディングされたビットを復号し得る。コンテキストおよび確率状態σがコンテキストモデラ２２００によって決定された後に、通常復号エンジン２２４０は、ビン値を復号するためにＢＡＣを実施する。言い換えれば、通常復号エンジン２２４０は、コンテキストの確率状態を決定し、前にコーディングされたビンと現在のレンジとに基づいてビン値を復号し得る。ビンを復号した後に、コンテキストモデラ２２００は、ウィンドウサイズと復号されたビンの値とに基づいてコンテキストの確率状態を更新し得る。

[0136]図１４は、本開示の１つまたは複数の態様による、ポイントクラウドのポイントを予測する例示的な技法を示す流れ図である。図１４の技法は、図２のＧ－ＰＣＣエンコーダ２００など、Ｇ－ＰＣＣコーダによって実施され得る。しかしながら、図３のＧ－ＰＣＣデコーダ３００など、他のデバイスが図１４の技法を実施し得る。

[0137]Ｇ－ＰＣＣエンコーダ２００は、ポイントクラウドの参照ブロックの平面情報を取得し得る（１４０２）。たとえば、Ｇ－ＰＣＣエンコーダ２００の算術符号化ユニット２１４は、参照ブロックが特定の方向において平面モードを使用してコーディングされるかどうかを決定し得る（たとえば、参照ブロック／ノードがａｘｉｓＩｄｘ方向において平面であるかどうかを示し得る、ＰｌａｎａｒＭｏｄｅＲｅｆ［ａｘｉｓＩｄｘ］）。

[0138]Ｇ－ＰＣＣエンコーダ２００は、参照ブロックの平面情報に基づいて、コンテキストを決定し得る（１４０４）。たとえば、算術コーディングユニット２１４は、参照ブロックの平面情報に基づいてコンテキストインデックス（ｃｔｘＩｄｘ）を決定し得る。一例として、算術コーディングユニット２１４は、ｃｔｘＩｄｘを（２＊ａｘｉｓＩｄｘ＋ＰｌａｎａｒＭｏｄｅＲｅｆ［ａｘｉｓＩｄｘ］）として決定し得る。

[0139]Ｇ－ＰＣＣエンコーダ２００は、コンテキストに基づいて、現在のノードが平面モードを使用してコーディングされるかどうかを示すシンタックス要素をコンテキスト適応型コーディングし得る（１４０６）。たとえば、算術符号化ユニット２１４は、ｃｔｘＩｄｘに基づいて現在のノードのためのｉｓ＿ｐｌａｎａｒ＿ｆｌａｇシンタックス要素のコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）を実施し得る。上述のように、１に等しいｉｓ＿ｐｌａｎａｒ＿ｆｌａｇシンタックス要素は、現在のノードの子の位置が、ａｘｉｓＩｄｘ番目の軸に直角な単一の平面を形成することを示し得る。０に等しいｉｓ＿ｐｌａｎａｒ＿ｆｌａｇ［ａｘｉｓＩｄｘ］は、存在するとき、現在のノードの子の位置が、ａｘｉｓＩｄｘ番目の軸に直角な両方の平面を占有することを示し得る。

[0140]Ｇ－ＰＣＣエンコーダ２００は、現在のノードが平面モードを使用してコーディングされることに基づいて、平面モードを使用して現在のノードをコーディングし得る（１４０８）。たとえば、Ｇ－ＰＣＣエンコーダ２００は、単一の平面を形成するものとして現在のノードの子をコーディングし得る。

[0141]いくつかの例では、現在のノードが平面モードを使用してコーディングされる場合、算術コーディングユニット２１４は、参照平面に基づいて第２のコンテキストを決定し、第２のコンテキストに基づいて、現在のノードのための平面を示すシンタックス要素をコンテキスト適応型コーディングし得る。現在のノードのための平面を示すシンタックス要素は、ｐｌａｎｅ＿ｐｏｓｉｔｉｏｎシンタックス要素であり得る。いくつかの例では、参照平面に基づいて第２のコンテキストを決定するために、算術コーディングユニット２１４は、以下の式、すなわち、ｃｔｘＩｄｘ＝（１２×ａｘｉｓＩｄｘ＋４×ａｄｊＰｌａｎｅＣｔｘＩｎｃ＋２×ｄｉｓｔＣｔｘＩｎｃ＋ｐｒｅｖＰｌａｎｅ＋３）＋（ＲｅｆＰｌａｎｅ［ａｘｉｓＩｄｘ］＋１）×Ｎに従ってコンテキストインデックスを決定し得、ここにおいて、ｃｔｘＩｄｘはコンテキストインデックスであり、ａｘｉｓＩｄｘは軸インデックスであり、ａｄｊＰｌａｎｅＣｔｘＩｎｃは、調整された平面コンテキスト増分であり、ｄｉｓｔＣｔｘＩｎｃは距離コンテキスト増分であり、ｐｒｅｖＰｌａｎｅは前の平面であり、ＲｅｆＰｌａｎｅ［ａｘｉｓＩｄｘ］は参照平面である。

[0142]いくつかの例では、算術コーディングユニット２１４は、参照平面に基づいて、現在のノードのための角度コンテキストを決定し、角度コンテキストに基づいて、現在のノードのための平面を決定し得る。平面モードを使用して現在のノードをコーディングするために、Ｇ－ＰＣＣエンコーダ２００は、平面に基づいて現在のノードをコーディングし得る。

[0143]いくつかの例では、算術コーディングユニット２１４は、参照平面に基づいて、現在のノードのための方位角コンテキストを決定し、方位角コンテキストに基づいて、現在のノードのための平面を決定し得る。平面モードを使用して現在のノードをコーディングするために、Ｇ－ＰＣＣエンコーダ２００は、平面に基づいて現在のノードをコーディングし得る。いくつかの例では、方位角コンテキストを決定するために、算術コーディングユニット２１４は、以下の式、すなわち、ｃｏｎｔｅｘｔＡｚｉｍｕｔｈａｌ＝ｃｏｎｔｅｘｔＡｎｇｌｅＰｈｉ＋８×（ＲｅｆＰｌａｎｅ［ａｘｉｓＩｄｘ］＋１）に従って方位角コンテキストを決定し得、ここにおいて、ｃｏｎｔｅｘｔＡｚｉｍｕｔｈａｌは方位角コンテキストであり、ｃｏｎｔｅｘｔＡｎｇｌｅＰｈｉは、方位角コンテキストを導出するために使用される中間値であり、ＲｅｆＰｌａｎｅ［ａｘｉｓＩｄｘ］は参照平面である。複数の方位角コンテキストが、ｃｏｎｔｅｘｔＡｚｉｍｕｔｈａｌＳとｃｏｎｔｅｘｔＡｚｉｍｕｔｈａｌＴとを含む、ｃｏｎｔｅｘｔＡｎｇｌｅＰｈｉに基づいて導出され得る。

[0144]いくつかの例では、現在のノードは、平面コピーモード（ＰＣＭ）を使用して選択的にコーディングされ得る。たとえば、Ｇ－ＰＣＣエンコーダ２００は、参照ノードから現在のノードについて平面情報をコピーすべきかどうかを決定し得る。Ｇ－ＰＣＣエンコーダ２００は、現在のノードがＰＣＭを使用してコーディングされるか否かをシグナリングし得る。たとえば、算術コーディングユニット２１４は、現在のノードが平面コピーモードを使用してコーディングされるかどうかを示す、バイナリフラグ（たとえば、ＰＣＭ＿ｆｌａｇ）など、シンタックス要素をコーディングし得る。現在のノードが平面コピーモードを使用してコーディングされる場合、Ｇ－ＰＣＣデコーダ３００は、参照ノードから現在のノードの平面情報をコピーし得る。たとえば、Ｇ－ＰＣＣデコーダ３００は、現在のノードの平面位置として参照ノードの平面位置を利用し得る。同様に、現在のノードが平面コピーモードを使用してコーディングされない場合、Ｇ－ＰＣＣエンコーダ２００は、ビットストリームから現在のノードのための平面情報を符号化し得る（およびＧ－ＰＣＣデコーダ３００がそれを復号し得る）。このようにして、ＰＣＭは、コーディング効率を改善し得る。

[0145]以下の番号付けされた条項は、本開示の１つまたは複数の態様を示し得る。

[0146]条項１Ａ． ポイントクラウドデータをコーディングする方法であって、方法が、ポイントクラウドデータの参照ブロックの平面情報を取得することと、取得された平面情報に基づいて、ポイントクラウドデータの現在のブロックをコーディングすることとを備える、方法。

[0147]条項２Ａ． ポイントクラウドデータの現在のブロックをコーディングすることは、現在のブロックの現在の方向について、参照ブロックが現在の方向において平面モードを使用してコーディングされるかどうかに少なくとも部分的に基づいて平面レートを決定することを備える、条項１Ａに記載の方法。

[0148]条項３Ａ． ポイントクラウドデータの現在のブロックをコーディングすることは、参照ブロックが平面であるかどうかに基づいて、現在のブロックが平面適格であるかどうかを決定することを備える、条項１Ａに記載の方法。

[0149]条項４Ａ． コーディングされたビットストリームにおいて、現在のブロックと参照ブロックとがすべての方向において同じ平面モードを共有するかどうかを示す値を有するシンタックス要素をコーディングすることをさらに備える、条項１Ａに記載の方法。

[0150]条項５Ａ． コーディングされたビットストリームにおいて、現在のブロックと参照ブロックとが同じ平面位置インデックスを共有するかどうかを示す値を有するシンタックス要素をコーディングすることをさらに備える、条項１Ａに記載の方法。

[0151]条項５Ａ． ポイントクラウドデータの現在のブロックをコーディングすることは、参照ブロックが平面であるかどうかに基づいて、現在のブロックの平面フラグのコンテキスト適応型コーディングのためのコンテキストを決定することを備える、条項１Ａに記載の方法。

[0152]条項６Ａ． ポイントクラウドデータの現在のブロックをコーディングすることが、参照ブロックの平面位置の平面モードに基づいて、現在のブロックのための角度コンテキストを決定することを備える、条項１Ａに記載の方法。

[0153]条項７Ａ． ポイントクラウドを処理するためのデバイスであって、デバイスが、条項１Ａから６Ａのいずれかに記載の方法を実施するための１つまたは複数の手段を備える、デバイス。

[0154]条項８Ａ． １つまたは複数の手段が、回路中に実装された１つまたは複数のプロセッサを備える、条項７Ａに記載のデバイス。

[0155]条項９Ａ． ポイントクラウドを表すデータを記憶するためのメモリをさらに備える、条項７Ａまたは８Ａのいずれかに記載のデバイス。

[0156]条項１０Ａ． デバイスがデコーダを備える、条項７Ａから９Ａのいずれかに記載のデバイス。

[0157]条項１１Ａ． デバイスがエンコーダを備える、条項７Ａから１０Ａのいずれかに記載のデバイス。

[0158]条項１２Ａ． ポイントクラウドを生成するためのデバイスをさらに備える、条項７Ａから１１Ａのいずれかに記載のデバイス。

[0159]条項１３Ａ． ポイントクラウドに基づいて像を提示するためのディスプレイをさらに備える、条項７Ａから１２Ａのいずれかに記載のデバイス。

[0160]条項１４Ａ． 命令を記憶したコンピュータ可読記憶媒体であって、命令が、実行されたとき、１つまたは複数のプロセッサに、条項１Ａから６Ａのいずれかに記載の方法を実施させる、コンピュータ可読記憶媒体。

[0161]例に応じて、本明細書で説明された技法のうちのいずれかのいくつかの行為またはイベントは、異なるシーケンスで実施され得、追加、マージ、または完全に除外され得る（たとえば、すべての説明された行為またはイベントが、技法の実践のために必要であるとは限らない）ことを認識されたい。その上、いくつかの例では、行為またはイベントは、連続的にではなく、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通して同時に実施され得る。

[0162]１つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、１つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され、ハードウェアベース処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応する、コンピュータ可読記憶媒体を含み得るか、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含み得る。このようにして、コンピュータ可読媒体は、概して、（１）非一時的である有形コンピュータ可読記憶媒体、あるいは（２）信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明された技法の実装のための命令、コードおよび／またはデータ構造を取り出すために、１つまたは複数のコンピュータまたは１つまたは複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であり得る。コンピュータプログラム製品はコンピュータ可読媒体を含み得る。

[0163]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ－ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは、命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用されるディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）およびＢｌｕ－ｒａｙディスク（disc）を含み、ここで、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザーで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲に含まれるべきである。

[0164]命令は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、あるいは他の等価な集積またはディスクリート論理回路など、１つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用される「プロセッサ」および「処理回路」という用語は、上記の構造、または本明細書で説明された技法の実装に好適な任意の他の構造のいずれかを指し得る。さらに、いくつかの態様では、本明細書で説明された機能は、符号化および復号のために構成された専用ハードウェアおよび／またはソフトウェアモジュール内に提供されるか、あるいは複合コーデックに組み込まれ得る。また、本技法は、１つまたは複数の回路または論理要素で十分に実装され得る。

[0165]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置で実装され得る。本開示では、開示される技法を実施するように構成されたデバイスの機能的態様を強調するために、様々な構成要素、モジュール、またはユニットが説明されたが、それらの構成要素、モジュール、またはユニットは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上記で説明されたように、様々なユニットが、好適なソフトウェアおよび／またはファームウェアとともに、上記で説明された１つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作可能なハードウェアユニットの集合によって提供され得る。

[0166]様々な例が説明された。これらおよび他の例は以下の特許請求の範囲内に入る。

Claims (23)

1. ポイントクラウドを処理するためのデバイスであって、前記デバイスが、
   前記ポイントクラウドの少なくとも一部分を記憶するように構成されたメモリと、
   回路中に実装された１つまたは複数のプロセッサと
   を備え、前記１つまたは複数のプロセッサは、
   前記ポイントクラウドの参照ブロックの平面情報を取得することと、
   前記参照ブロックの前記平面情報に基づいて、コンテキストを決定することと、
   前記コンテキストに基づいて、現在のノードが平面モードを使用してコーディングされるかどうかを示すシンタックス要素をコンテキスト適応型コーディングすることと、
   前記現在のノードが前記平面モードを使用してコーディングされることに基づいて、前記平面モードを使用して前記現在のノードをコーディングすることと
   を行うように構成された、デバイス。
2. 前記現在のノードが前記平面モードを使用してコーディングされるかどうかを示す前記シンタックス要素が、ｉｓ＿ｐｌａｎａｒ＿ｆｌａｇシンタックス要素を備える、請求項１に記載のデバイス。
3. 前記コンテキストが第１のコンテキストであり、ここにおいて、前記１つまたは複数のプロセッサは、
   前記現在のノードが前記平面モードを使用してコーディングされると決定することに応答して、
   参照平面に基づいて第２のコンテキストを決定することと、
   前記第２のコンテキストに基づいて、前記現在のノードのための平面を示すシンタックス要素をコンテキスト適応型コーディングすることと
   を行うようにさらに構成され、
   ここにおいて、前記平面モードを使用して前記現在のノードをコーディングするために、前記１つまたは複数のプロセッサが、前記平面に基づいて前記現在のノードをコーディングするように構成された、
   請求項１に記載のデバイス。
4. 前記現在のノードのための前記平面を示す前記シンタックス要素が、ｐｌａｎｅ＿ｐｏｓｉｔｉｏｎシンタックス要素を備える、請求項３に記載のデバイス。
5. 前記参照平面に基づいて前記第２のコンテキストを決定するために、前記１つまたは複数のプロセッサが、以下の式に従ってコンテキストインデックスを決定するように構成され、
   

   

   ここにおいて、ｃｔｘＩｄｘが前記コンテキストインデックスであり、ａｘｉｓＩｄｘが軸インデックスであり、ａｄｊＰｌａｎｅＣｔｘＩｎｃが、調整された平面コンテキスト増分であり、ｄｉｓｔＣｔｘＩｎｃが距離コンテキスト増分であり、ｐｒｅｖＰｌａｎｅが前の平面であり、ＲｅｆＰｌａｎｅ［ａｘｉｓＩｄｘ］が前記参照平面である、
   請求項３に記載のデバイス。
6. 前記１つまたは複数のプロセッサが、
   参照平面に基づいて、前記現在のノードのための角度コンテキストを決定することと、
   前記角度コンテキストに基づいて、前記現在のノードのための平面を決定することと
   を行うように構成され、
   ここにおいて、前記平面モードを使用して前記現在のノードをコーディングするために、前記１つまたは複数のプロセッサが、前記平面に基づいて前記現在のノードをコーディングするように構成された、
   請求項１に記載のデバイス。
7. 前記１つまたは複数のプロセッサは、
   参照平面に基づいて、前記現在のノードのための方位角コンテキストを決定することと、
   前記方位角コンテキストに基づいて、前記現在のノードのための平面を決定することと
   を行うように構成され、
   ここにおいて、前記平面モードを使用して前記現在のノードをコーディングするために、前記１つまたは複数のプロセッサが、前記平面に基づいて前記現在のノードをコーディングするように構成された、
   請求項１に記載のデバイス。
8. 前記方位角コンテキストを決定するために、前記１つまたは複数のプロセッサが、以下の式に従って前記方位角コンテキストを決定するように構成され、
   

   

   ここにおいて、ｃｏｎｔｅｘｔＡｚｉｍｕｔｈａｌが前記方位角コンテキストであり、ｃｏｎｔｅｘｔＡｎｇｌｅＰｈｉが、方位角コンテキストを導出するために使用される中間値であり、ＲｅｆＰｌａｎｅ［ａｘｉｓＩｄｘ］が前記参照平面である、
   請求項７に記載のデバイス。
9. 前記１つまたは複数のプロセッサは、
   前記現在のノードが平面コピーモードを使用してコーディングされるかどうかを示すシンタックス要素をコーディングすることと、
   前記現在のノードが前記平面コピーモードを使用してコーディングされる場合、参照ノードから前記現在のノードの平面情報をコピーすることと
   を行うようにさらに構成された、請求項１に記載のデバイス。
10. 前記平面情報をコピーするために、前記１つまたは複数のプロセッサが、
    前記現在のノードの平面位置として前記参照ノードの平面位置を利用する
    ように構成された、請求項９に記載のデバイス。
11. 前記現在のノードが前記平面コピーモードを使用してコーディングされるかどうかを示す前記シンタックス要素が、バイナリフラグを備える、請求項９に記載のデバイス。
12. スピニングＬＩＤＡＲセンサー
    をさらに備え、ここにおいて、前記１つまたは複数のプロセッサが、前記スピニングＬＩＤＡＲセンサーによって生成されたデータに基づいて前記ポイントクラウドを生成するように構成された、請求項１に記載のデバイス。
13. 前記デバイスが、前記スピニングＬＩＤＡＲセンサーを含む車両である、請求項１２に記載のデバイス。
14. 前記デバイスが、ワイヤレス通信デバイスである、請求項１に記載のデバイス。
15. ポイントクラウドデータをコーディングする方法であって、前記方法は、
    前記ポイントクラウドの参照ブロックの平面情報を取得することと、
    前記参照ブロックの前記平面情報に基づいて、コンテキストを決定することと、
    前記コンテキストに基づいて、現在のノードが平面モードを使用してコーディングされるかどうかを示すシンタックス要素をコンテキスト適応型コーディングすることと、
    前記現在のノードが前記平面モードを使用してコーディングされることに基づいて、前記平面モードを使用して前記現在のノードをコーディングすることと
    を備える、方法。
16. 前記現在のノードが前記平面モードを使用してコーディングされるかどうかを示す前記シンタックス要素が、ｉｓ＿ｐｌａｎａｒ＿ｆｌａｇシンタックス要素を備える、請求項１５に記載の方法。
17. 前記コンテキストが第１のコンテキストであり、前記方法は、前記現在のノードが前記平面モードを使用してコーディングされると決定することに応答して、
    参照平面に基づいて第２のコンテキストを決定することと、
    前記第２のコンテキストに基づいて、前記現在のノードのための平面を示すシンタックス要素をコンテキスト適応型コーディングすることと
    をさらに備え、
    ここにおいて、前記平面モードを使用して前記現在のノードをコーディングすることが、前記平面に基づいて前記現在のノードをコーディングすることを備える、
    請求項１５に記載の方法。
18. 前記現在のノードのための前記平面を示す前記シンタックス要素が、ｐｌａｎｅ＿ｐｏｓｉｔｉｏｎシンタックス要素を備える、請求項１７に記載の方法。
19. 前記参照平面に基づいて前記第２のコンテキストを決定することが、以下の式に従ってコンテキストインデックスを決定することを備え、
    

    

    ここにおいて、ｃｔｘＩｄｘが前記コンテキストインデックスであり、ａｘｉｓＩｄｘが軸インデックスであり、ａｄｊＰｌａｎｅＣｔｘＩｎｃが、調整された平面コンテキスト増分であり、ｄｉｓｔＣｔｘＩｎｃが距離コンテキスト増分であり、ｐｒｅｖＰｌａｎｅが前の平面であり、ＲｅｆＰｌａｎｅ［ａｘｉｓＩｄｘ］が前記参照平面である、
    請求項１７に記載の方法。
20. 参照平面に基づいて、前記現在のノードのための角度コンテキストを決定することと、
    前記角度コンテキストに基づいて、前記現在のノードのための平面を決定することと
    をさらに備え、
    ここにおいて、前記平面モードを使用して前記現在のノードをコーディングすることが、前記平面に基づいて前記現在のノードをコーディングすることを備える、
    請求項１５に記載の方法。
21. 参照平面に基づいて、前記現在のノードのための方位角コンテキストを決定することと、
    前記方位角コンテキストに基づいて、前記現在のノードのための平面を決定することと
    をさらに備え、
    ここにおいて、前記平面モードを使用して前記現在のノードをコーディングすることが、前記平面に基づいて前記現在のノードをコーディングすることを備える、
    請求項１５に記載の方法。
22. 前記方位角コンテキストを決定することが、以下の式に従って前記方位角コンテキストを決定することを備え、
    

    

    ここにおいて、ｃｏｎｔｅｘｔＡｚｉｍｕｔｈａｌが前記方位角コンテキストであり、ｃｏｎｔｅｘｔＡｎｇｌｅＰｈｉが、方位角コンテキストを導出するために使用される中間値であり、ＲｅｆＰｌａｎｅ［ａｘｉｓＩｄｘ］が前記参照平面である、
    請求項２１に記載の方法。
23. 実行されたとき、１つまたは複数のプロセッサに、
    ポイントクラウドの参照ブロックの平面情報を取得することと、
    前記参照ブロックの前記平面情報に基づいて、コンテキストを決定することと、
    前記コンテキストに基づいて、現在のノードが平面モードを使用してコーディングされるかどうかを示すシンタックス要素をコンテキスト適応型コーディングすることと、
    前記現在のノードが前記平面モードを使用してコーディングされることに基づいて、前記平面モードを使用して前記現在のノードをコーディングすることと
    を行わせる命令を記憶するコンピュータ可読記憶媒体。

Images