IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ クゥアルコム・インコーポレイテッドの特許一覧

特表2024-519664インター予測を使用するジオメトリポイントクラウド圧縮(GPCC)平面モードの性能改善
<>
  • 特表-インター予測を使用するジオメトリポイントクラウド圧縮(GPCC)平面モードの性能改善 図1
  • 特表-インター予測を使用するジオメトリポイントクラウド圧縮(GPCC)平面モードの性能改善 図2
  • 特表-インター予測を使用するジオメトリポイントクラウド圧縮(GPCC)平面モードの性能改善 図3
  • 特表-インター予測を使用するジオメトリポイントクラウド圧縮(GPCC)平面モードの性能改善 図4
  • 特表-インター予測を使用するジオメトリポイントクラウド圧縮(GPCC)平面モードの性能改善 図5
  • 特表-インター予測を使用するジオメトリポイントクラウド圧縮(GPCC)平面モードの性能改善 図6
  • 特表-インター予測を使用するジオメトリポイントクラウド圧縮(GPCC)平面モードの性能改善 図7
  • 特表-インター予測を使用するジオメトリポイントクラウド圧縮(GPCC)平面モードの性能改善 図8
  • 特表-インター予測を使用するジオメトリポイントクラウド圧縮(GPCC)平面モードの性能改善 図9
  • 特表-インター予測を使用するジオメトリポイントクラウド圧縮(GPCC)平面モードの性能改善 図10A
  • 特表-インター予測を使用するジオメトリポイントクラウド圧縮(GPCC)平面モードの性能改善 図10B
  • 特表-インター予測を使用するジオメトリポイントクラウド圧縮(GPCC)平面モードの性能改善 図11
  • 特表-インター予測を使用するジオメトリポイントクラウド圧縮(GPCC)平面モードの性能改善 図12
  • 特表-インター予測を使用するジオメトリポイントクラウド圧縮(GPCC)平面モードの性能改善 図13
  • 特表-インター予測を使用するジオメトリポイントクラウド圧縮(GPCC)平面モードの性能改善 図14
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-05-21
(54)【発明の名称】インター予測を使用するジオメトリポイントクラウド圧縮(GPCC)平面モードの性能改善
(51)【国際特許分類】
   G06T 9/00 20060101AFI20240514BHJP
   G06T 17/00 20060101ALI20240514BHJP
   G01S 17/89 20200101ALI20240514BHJP
【FI】
G06T9/00 100
G06T17/00
G01S17/89
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023561841
(86)(22)【出願日】2022-04-15
(85)【翻訳文提出日】2023-10-06
(86)【国際出願番号】 US2022071733
(87)【国際公開番号】W WO2022221867
(87)【国際公開日】2022-10-20
(31)【優先権主張番号】63/176,098
(32)【優先日】2021-04-16
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】17/659,219
(32)【優先日】2022-04-14
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】595020643
【氏名又は名称】クゥアルコム・インコーポレイテッド
【氏名又は名称原語表記】QUALCOMM INCORPORATED
(74)【代理人】
【識別番号】110003708
【氏名又は名称】弁理士法人鈴榮特許綜合事務所
(72)【発明者】
【氏名】ファン・バン、ルオン
(72)【発明者】
【氏名】ファン・デル・オーウェラ、ゲールト
(72)【発明者】
【氏名】ラマスブラモニアン、アダルシュ・クリシュナン
(72)【発明者】
【氏名】レイ、バッパディティア
(72)【発明者】
【氏名】カルチェビチ、マルタ
【テーマコード(参考)】
5B080
5J084
【Fターム(参考)】
5B080AA13
5B080AA14
5B080AA17
5B080BA00
5B080CA00
5J084AA04
5J084AA05
5J084AC02
5J084AD01
5J084BA03
5J084BB01
5J084BB21
5J084CA03
(57)【要約】
ポイントクラウドを処理するための例示的なデバイスが、ポイントクラウドの少なくとも一部分を記憶するように構成されたメモリと、回路中に実装された1つまたは複数のプロセッサとを含み、1つまたは複数のプロセッサは、ポイントクラウドの参照ブロックの平面情報を取得することと、参照ブロックの平面情報に基づいて、コンテキストを決定することと、コンテキストに基づいて、現在のノードが平面モードを使用してコーディングされるかどうかを示すシンタックス要素をコンテキスト適応型コーディングすることと、現在のノードが平面モードを使用してコーディングされることに基づいて、平面モードを使用して現在のノードをコーディングすることとを行うように構成される。
【特許請求の範囲】
【請求項1】
ポイントクラウドを処理するためのデバイスであって、前記デバイスが、
前記ポイントクラウドの少なくとも一部分を記憶するように構成されたメモリと、
回路中に実装された1つまたは複数のプロセッサと
を備え、前記1つまたは複数のプロセッサは、
前記ポイントクラウドの参照ブロックの平面情報を取得することと、
前記参照ブロックの前記平面情報に基づいて、コンテキストを決定することと、
前記コンテキストに基づいて、現在のノードが平面モードを使用してコーディングされるかどうかを示すシンタックス要素をコンテキスト適応型コーディングすることと、
前記現在のノードが前記平面モードを使用してコーディングされることに基づいて、前記平面モードを使用して前記現在のノードをコーディングすることと
を行うように構成された、デバイス。
【請求項2】
前記現在のノードが前記平面モードを使用してコーディングされるかどうかを示す前記シンタックス要素が、is_planar_flagシンタックス要素を備える、請求項1に記載のデバイス。
【請求項3】
前記コンテキストが第1のコンテキストであり、ここにおいて、前記1つまたは複数のプロセッサは、
前記現在のノードが前記平面モードを使用してコーディングされると決定することに応答して、
参照平面に基づいて第2のコンテキストを決定することと、
前記第2のコンテキストに基づいて、前記現在のノードのための平面を示すシンタックス要素をコンテキスト適応型コーディングすることと
を行うようにさらに構成され、
ここにおいて、前記平面モードを使用して前記現在のノードをコーディングするために、前記1つまたは複数のプロセッサが、前記平面に基づいて前記現在のノードをコーディングするように構成された、
請求項1に記載のデバイス。
【請求項4】
前記現在のノードのための前記平面を示す前記シンタックス要素が、plane_positionシンタックス要素を備える、請求項3に記載のデバイス。
【請求項5】
前記参照平面に基づいて前記第2のコンテキストを決定するために、前記1つまたは複数のプロセッサが、以下の式に従ってコンテキストインデックスを決定するように構成され、
【数1】
ここにおいて、ctxIdxが前記コンテキストインデックスであり、axisIdxが軸インデックスであり、adjPlaneCtxIncが、調整された平面コンテキスト増分であり、distCtxIncが距離コンテキスト増分であり、prevPlaneが前の平面であり、RefPlane[axisIdx]が前記参照平面である、
請求項3に記載のデバイス。
【請求項6】
前記1つまたは複数のプロセッサが、
参照平面に基づいて、前記現在のノードのための角度コンテキストを決定することと、
前記角度コンテキストに基づいて、前記現在のノードのための平面を決定することと
を行うように構成され、
ここにおいて、前記平面モードを使用して前記現在のノードをコーディングするために、前記1つまたは複数のプロセッサが、前記平面に基づいて前記現在のノードをコーディングするように構成された、
請求項1に記載のデバイス。
【請求項7】
前記1つまたは複数のプロセッサは、
参照平面に基づいて、前記現在のノードのための方位角コンテキストを決定することと、
前記方位角コンテキストに基づいて、前記現在のノードのための平面を決定することと
を行うように構成され、
ここにおいて、前記平面モードを使用して前記現在のノードをコーディングするために、前記1つまたは複数のプロセッサが、前記平面に基づいて前記現在のノードをコーディングするように構成された、
請求項1に記載のデバイス。
【請求項8】
前記方位角コンテキストを決定するために、前記1つまたは複数のプロセッサが、以下の式に従って前記方位角コンテキストを決定するように構成され、
【数2】
ここにおいて、contextAzimuthalが前記方位角コンテキストであり、contextAnglePhiが、方位角コンテキストを導出するために使用される中間値であり、RefPlane[axisIdx]が前記参照平面である、
請求項7に記載のデバイス。
【請求項9】
前記1つまたは複数のプロセッサは、
前記現在のノードが平面コピーモードを使用してコーディングされるかどうかを示すシンタックス要素をコーディングすることと、
前記現在のノードが前記平面コピーモードを使用してコーディングされる場合、参照ノードから前記現在のノードの平面情報をコピーすることと
を行うようにさらに構成された、請求項1に記載のデバイス。
【請求項10】
前記平面情報をコピーするために、前記1つまたは複数のプロセッサが、
前記現在のノードの平面位置として前記参照ノードの平面位置を利用する
ように構成された、請求項9に記載のデバイス。
【請求項11】
前記現在のノードが前記平面コピーモードを使用してコーディングされるかどうかを示す前記シンタックス要素が、バイナリフラグを備える、請求項9に記載のデバイス。
【請求項12】
スピニングLIDARセンサー
をさらに備え、ここにおいて、前記1つまたは複数のプロセッサが、前記スピニングLIDARセンサーによって生成されたデータに基づいて前記ポイントクラウドを生成するように構成された、請求項1に記載のデバイス。
【請求項13】
前記デバイスが、前記スピニングLIDARセンサーを含む車両である、請求項12に記載のデバイス。
【請求項14】
前記デバイスが、ワイヤレス通信デバイスである、請求項1に記載のデバイス。
【請求項15】
ポイントクラウドデータをコーディングする方法であって、前記方法は、
前記ポイントクラウドの参照ブロックの平面情報を取得することと、
前記参照ブロックの前記平面情報に基づいて、コンテキストを決定することと、
前記コンテキストに基づいて、現在のノードが平面モードを使用してコーディングされるかどうかを示すシンタックス要素をコンテキスト適応型コーディングすることと、
前記現在のノードが前記平面モードを使用してコーディングされることに基づいて、前記平面モードを使用して前記現在のノードをコーディングすることと
を備える、方法。
【請求項16】
前記現在のノードが前記平面モードを使用してコーディングされるかどうかを示す前記シンタックス要素が、is_planar_flagシンタックス要素を備える、請求項15に記載の方法。
【請求項17】
前記コンテキストが第1のコンテキストであり、前記方法は、前記現在のノードが前記平面モードを使用してコーディングされると決定することに応答して、
参照平面に基づいて第2のコンテキストを決定することと、
前記第2のコンテキストに基づいて、前記現在のノードのための平面を示すシンタックス要素をコンテキスト適応型コーディングすることと
をさらに備え、
ここにおいて、前記平面モードを使用して前記現在のノードをコーディングすることが、前記平面に基づいて前記現在のノードをコーディングすることを備える、
請求項15に記載の方法。
【請求項18】
前記現在のノードのための前記平面を示す前記シンタックス要素が、plane_positionシンタックス要素を備える、請求項17に記載の方法。
【請求項19】
前記参照平面に基づいて前記第2のコンテキストを決定することが、以下の式に従ってコンテキストインデックスを決定することを備え、
【数3】
ここにおいて、ctxIdxが前記コンテキストインデックスであり、axisIdxが軸インデックスであり、adjPlaneCtxIncが、調整された平面コンテキスト増分であり、distCtxIncが距離コンテキスト増分であり、prevPlaneが前の平面であり、RefPlane[axisIdx]が前記参照平面である、
請求項17に記載の方法。
【請求項20】
参照平面に基づいて、前記現在のノードのための角度コンテキストを決定することと、
前記角度コンテキストに基づいて、前記現在のノードのための平面を決定することと
をさらに備え、
ここにおいて、前記平面モードを使用して前記現在のノードをコーディングすることが、前記平面に基づいて前記現在のノードをコーディングすることを備える、
請求項15に記載の方法。
【請求項21】
参照平面に基づいて、前記現在のノードのための方位角コンテキストを決定することと、
前記方位角コンテキストに基づいて、前記現在のノードのための平面を決定することと
をさらに備え、
ここにおいて、前記平面モードを使用して前記現在のノードをコーディングすることが、前記平面に基づいて前記現在のノードをコーディングすることを備える、
請求項15に記載の方法。
【請求項22】
前記方位角コンテキストを決定することが、以下の式に従って前記方位角コンテキストを決定することを備え、
【数4】
ここにおいて、contextAzimuthalが前記方位角コンテキストであり、contextAnglePhiが、方位角コンテキストを導出するために使用される中間値であり、RefPlane[axisIdx]が前記参照平面である、
請求項21に記載の方法。
【請求項23】
実行されたとき、1つまたは複数のプロセッサに、
ポイントクラウドの参照ブロックの平面情報を取得することと、
前記参照ブロックの前記平面情報に基づいて、コンテキストを決定することと、
前記コンテキストに基づいて、現在のノードが平面モードを使用してコーディングされるかどうかを示すシンタックス要素をコンテキスト適応型コーディングすることと、
前記現在のノードが前記平面モードを使用してコーディングされることに基づいて、前記平面モードを使用して前記現在のノードをコーディングすることと
を行わせる命令を記憶するコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
[0001]本出願は、その各々の内容全体が参照により本明細書に組み込まれる、2022年4月14日に出願された米国特許出願第17/659,219号と、2021年4月16日に出願された米国仮出願第63/176,098号との優先権を主張する。2022年4月14日に出願された米国特許出願第17/659,219号は、2021年4月16日に出願された米国仮出願第63/176,098号の利益を主張する。
【0002】
[0002]本開示は、ポイントクラウド符号化および復号に関する。
【図面の簡単な説明】
【0003】
図1】[0003]本開示の技法を実施し得る例示的な符号化および復号システムを示すブロック図。
図2】[0004]例示的なジオメトリポイントクラウド圧縮(G-PCC)エンコーダを示すブロック図。
図3】[0005]例示的なG-PCCデコーダを示すブロック図。
図4】[0006]InterEMのための例示的な動き推定技法を示すフローチャート。
図5】[0007]ローカルノード動きベクトルの推定のための例示的な技法を示すフローチャート。
図6】[0008]本開示の1つまたは複数の技法とともに使用され得る例示的なレンジ測定システム(range-finding system)を示す概念図。
図7】[0009]本開示の1つまたは複数の技法が使用され得る例示的な車両ベースのシナリオを示す概念図。
図8】[0010]本開示の1つまたは複数の技法が使用され得る例示的なエクステンデッドリアリティシステムを示す概念図。
図9】[0011]本開示の1つまたは複数の技法が使用され得る例示的なモバイルデバイスシステムを示す概念図。
図10A】[0012]バイナリ算術コーディングにおけるレンジ更新プロセスを示す概念図。
図10B】バイナリ算術コーディングにおけるレンジ更新プロセスを示す概念図。
図11】[0013]バイナリ算術コーディングにおける出力プロセスを示す概念図。
図12】[0014]G-PCCエンコーダ中のコンテキスト適応型バイナリ算術コーダを示すブロック図。
図13】[0015]G-PCCデコーダ中のコンテキスト適応型バイナリ算術コーダを示すブロック図。
図14】[0016]本開示の1つまたは複数の態様による、ポイントクラウドのポイントを予測する例示的な技法を示す流れ図。
【発明の概要】
【0004】
[0017]概して、本開示は、現在開発されているジオメトリポイントクラウド圧縮(G-PCC)規格についてなど、インター予測を使用するポイントクラウドのノードをコーディングするための技法について説明する。しかしながら、例示的な技法は、G-PCC規格に限定されない。ノードの参照ブロックは、推定された動き情報(回転および並進)を使用する動き補償によって導出され得る。動き情報の良好な推定が、現在のノードと参照ノードとの間の、占有、平面情報など、ジオメトリ構造に関する高相関につながり得る。したがって、参照ノードのこのジオメトリ情報を利用することが、現在のノードのコーディング性能を改善し得る。本開示は、現在のノードの平面情報のコーディングにおいて参照ブロックの情報を利用するためのいくつかの技法を含む。概して、この情報は、平面コーディングモードのためのノードの適格性、平面フラグおよび平面インデックスをコーディングする際のコンテキストの選択において使用され得る。
【0005】
[0018]本開示の1つまたは複数の技法によれば、G-PCCコーダは、ポイントクラウドの少なくとも一部分を記憶するように構成されたメモリと、回路中に実装された1つまたは複数のプロセッサとを含み得、1つまたは複数のプロセッサは、ポイントクラウドの参照ブロックの平面情報を取得することと、参照ブロックの平面情報に基づいて、コンテキストを決定することと、コンテキストに基づいて、現在のノードが平面モードを使用してコーディングされるかどうかを示すシンタックス要素をコンテキスト適応型コーディングすることと、現在のノードが平面モードを使用してコーディングされることに基づいて、平面モードを使用して現在のノードをコーディングすることとを行うように構成される。
【0006】
[0019]一例では、ポイントクラウドを処理する方法は、ポイントクラウドの参照ブロックの平面情報を取得することと、参照ブロックの平面情報に基づいて、コンテキストを決定することと、コンテキストに基づいて、現在のノードが平面モードを使用してコーディングされるかどうかを示すシンタックス要素をコンテキスト適応型コーディングすることと、現在のノードが平面モードを使用してコーディングされることに基づいて、平面モードを使用して現在のノードをコーディングすることとを含む。
【0007】
[0020]別の例では、コンピュータ可読記憶媒体は、1つまたは複数のプロセッサによって実行されたとき、1つまたは複数のプロセッサに、ポイントクラウドの参照ブロックの平面情報を取得することと、参照ブロックの平面情報に基づいて、コンテキストを決定することと、コンテキストに基づいて、現在のノードが平面モードを使用してコーディングされるかどうかを示すシンタックス要素をコンテキスト適応型コーディングすることと、現在のノードが平面モードを使用してコーディングされることに基づいて、平面モードを使用して現在のノードをコーディングすることとを行わせる命令を記憶する。
【0008】
[0021]1つまたは複数の例の詳細が添付の図面および以下の説明に記載されている。他の特徴、目的、および利点は、説明、図面、および特許請求の範囲から明らかになろう。
【発明を実施するための形態】
【0009】
[0022]図1は、本開示の技法を実施し得る例示的な符号化および復号システム100を示すブロック図である。本開示の技法は、概して、ポイントクラウドデータをコーディング(符号化および/または復号)すること、すなわち、ポイントクラウド圧縮をサポートすることを対象とする。概して、ポイントクラウドデータは、ポイントクラウドを処理するための任意のデータを含む。コーディングは、ポイントクラウドデータを圧縮および/または解凍する際に効果的であり得る。
【0010】
[0023]図1に示されているように、システム100は、ソースデバイス102と宛先デバイス116とを含む。ソースデバイス102は、宛先デバイス116によって復号されるべき符号化されたポイントクラウドデータを提供する。詳細には、図1の例では、ソースデバイス102は、コンピュータ可読媒体110を介して宛先デバイス116にポイントクラウドデータを提供する。ソースデバイス102および宛先デバイス116は、デスクトップコンピュータ、ノートブック(すなわち、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、スマートフォンなどの電話ハンドセット、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイス、地上車両または海洋車両、宇宙船、航空機、ロボット、LIDARデバイス、衛星などを含む、広範囲のデバイスのいずれかを備え得る。いくつかの場合には、ソースデバイス102および宛先デバイス116は、ワイヤレス通信のために装備され得る。
【0011】
[0024]図1の例では、ソースデバイス102は、データソース104と、メモリ106と、G-PCCエンコーダ200と、出力インターフェース108とを含む。宛先デバイス116は、入力インターフェース122と、G-PCCデコーダ300と、メモリ120と、データコンシューマー118とを含む。本開示によれば、ソースデバイス102のG-PCCエンコーダ200および宛先デバイス116のG-PCCデコーダ300は、現在のノード(たとえば、現在のブロック)の平面情報のコーディングにおいて参照ブロックの情報を利用することに関係する本開示の技法を適用するように構成され得る。したがって、ソースデバイス102は符号化デバイスの一例を表すが、宛先デバイス116は復号デバイスの一例を表す。他の例では、ソースデバイス102および宛先デバイス116は、他の構成要素または構成を含み得る。たとえば、ソースデバイス102は、内部ソースまたは外部ソースからデータ(たとえば、ポイントクラウドデータ)を受信し得る。同様に、宛先デバイス116は、同じデバイス中にデータコンシューマーを含むのではなく、外部データコンシューマーとインターフェースし得る。
【0012】
[0025]図1に示されているシステム100は一例にすぎない。概して、他のデジタル符号化および/または復号デバイスが、現在のノードの平面情報のコーディングにおいて参照ブロックの情報を利用することに関係する本開示の技法を実施し得る。ソースデバイス102および宛先デバイス116は、ソースデバイス102が宛先デバイス116への送信のためのコーディングされたデータを生成するようなデバイスの例にすぎない。本開示は、データのコーディング(符号化および/または復号)を実施するデバイスとして「コーディング」デバイスに言及する。したがって、G-PCCエンコーダ200およびG-PCCデコーダ300は、コーディングデバイス、特に、それぞれエンコーダおよびデコーダの例を表す。いくつかの例では、ソースデバイス102および宛先デバイス116は、ソースデバイス102および宛先デバイス116の各々が符号化構成要素および復号構成要素を含むように、実質的に対称的に動作し得る。したがって、システム100は、たとえば、ストリーミング、再生、ブロードキャスティング、電話通信、ナビゲーション、および他の用途のために、ソースデバイス102と宛先デバイス116との間の一方向または双方向送信をサポートし得る。
【0013】
[0026]概して、データソース104は、データ(すなわち、生の符号化されていないポイントクラウドデータ)のソースを表し、データの連続した一連の「フレーム」をG-PCCエンコーダ200に提供し得、G-PCCエンコーダ200は、フレームについてのデータを符号化する。ソースデバイス102のデータソース104は、様々なカメラまたはセンサーのいずれか、たとえば、3Dスキャナまたは光検出および測距(LIDAR)デバイス、1つまたは複数のビデオカメラ、以前にキャプチャされたデータを含んでいるアーカイブ、ならびに/あるいはデータコンテンツプロバイダからデータを受信するためのデータフィードインターフェースなど、ポイントクラウドキャプチャデバイスを含み得る。代替または追加として、ポイントクラウドデータは、スキャナ、カメラ、センサーまたは他のデータからコンピュータ生成され得る。たとえば、データソース104は、ソースデータとしてコンピュータグラフィックスベースのデータを生成し得るか、または、ライブデータ、アーカイブされたデータ、およびコンピュータ生成されたデータの組合せを作り出し得る。各場合において、G-PCCエンコーダ200は、キャプチャされたデータ、プリキャプチャされたデータ、またはコンピュータ生成されたデータを符号化する。G-PCCエンコーダ200は、フレームを、(「表示順序」と呼ばれることがある)受信順序から、コーディングするためのコーディング順序に並べ替え得る。G-PCCエンコーダ200は、符号化されたデータを含む1つまたは複数のビットストリームを生成し得る。ソースデバイス102は、次いで、たとえば、宛先デバイス116の入力インターフェース122による受信および/または取出しのために、符号化されたデータを出力インターフェース108を介してコンピュータ可読媒体110上に出力し得る。
【0014】
[0027]ソースデバイス102のメモリ106および宛先デバイス116のメモリ120は、汎用メモリを表し得る。いくつかの例では、メモリ106およびメモリ120は、生データ、たとえば、データソース104からの生データと、G-PCCデコーダ300からの生の復号されたデータとを記憶し得る。追加または代替として、メモリ106およびメモリ120は、たとえば、それぞれ、G-PCCエンコーダ200およびG-PCCデコーダ300によって実行可能なソフトウェア命令を記憶し得る。メモリ106およびメモリ120は、この例ではG-PCCエンコーダ200およびG-PCCデコーダ300とは別個に示されているが、G-PCCエンコーダ200およびG-PCCデコーダ300は、機能的に同様のまたは等価な目的で内部メモリをも含み得ることを理解されたい。さらに、メモリ106およびメモリ120は、符号化されたデータ、たとえば、G-PCCエンコーダ200からの出力、およびG-PCCデコーダ300への入力を記憶し得る。いくつかの例では、メモリ106およびメモリ120の部分は、たとえば、生の、復号された、および/または符号化されたデータを記憶するために、1つまたは複数のバッファとして割り振られ得る。たとえば、メモリ106およびメモリ120は、ポイントクラウドを表すデータを記憶し得る。
【0015】
[0028]コンピュータ可読媒体110は、ソースデバイス102から宛先デバイス116に、符号化されたデータをトランスポートすることが可能な任意のタイプの媒体またはデバイスを表し得る。一例では、コンピュータ可読媒体110は、ソースデバイス102が、たとえば、無線周波数ネットワークまたはコンピュータベースのネットワークを介して、符号化されたデータを宛先デバイス116にリアルタイムで直接送信することを可能にするための通信媒体を表す。出力インターフェース108は、符号化されたデータを含む送信信号を変調し得、入力インターフェース122は、ワイヤレス通信プロトコルなどの通信規格に従って、受信された送信信号を復調し得る。通信媒体は、無線周波数(RF)スペクトルまたは1つまたは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなど、パケットベースのネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス102から宛先デバイス116への通信を容易にするために有用であり得る任意の他の機器を含み得る。
【0016】
[0029]いくつかの例では、ソースデバイス102は、符号化されたデータを出力インターフェース108から記憶デバイス112に出力し得る。同様に、宛先デバイス116は、入力インターフェース122を介して記憶デバイス112からの符号化されたデータにアクセスし得る。記憶デバイス112は、ハードドライブ、Blu-ray(登録商標)ディスク、DVD、CD-ROM、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは符号化されたデータを記憶するための任意の他の好適なデジタル記憶媒体など、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。
【0017】
[0030]いくつかの例では、ソースデバイス102は、ソースデバイス102によって生成された符号化されたデータを記憶し得るファイルサーバ114または別の中間記憶デバイスに、符号化されたデータを出力し得る。宛先デバイス116は、ストリーミングまたはダウンロードを介してファイルサーバ114からの記憶されたデータにアクセスし得る。ファイルサーバ114は、符号化されたデータを記憶し、その符号化されたデータを宛先デバイス116に送信することが可能な任意のタイプのサーバデバイスであり得る。ファイルサーバ114は、(たとえば、ウェブサイトのための)ウェブサーバ、ファイル転送プロトコル(FTP)サーバ、コンテンツ配信ネットワークデバイス、またはネットワーク接続ストレージ(NAS)デバイスを表し得る。宛先デバイス116は、インターネット接続を含む任意の標準的なデータ接続を通してファイルサーバ114からの符号化されたデータにアクセスし得る。これは、ファイルサーバ114に記憶された符号化されたデータにアクセスするのに好適であるワイヤレスチャネル(たとえば、Wi-Fi(登録商標)接続)、ワイヤード接続(たとえば、デジタル加入者回線(DSL)、ケーブルモデムなど)、またはその両方の組合せを含み得る。ファイルサーバ114と入力インターフェース122とは、ストリーミング送信プロトコル、ダウンロード送信プロトコル、またはそれらの組合せに従って動作するように構成され得る。
【0018】
[0031]出力インターフェース108と入力インターフェース122とは、ワイヤレス送信機/受信機、モデム、ワイヤードネットワーキング構成要素(たとえば、イーサネット(登録商標)カード)、様々なIEEE802.11規格のいずれかに従って動作するワイヤレス通信構成要素、または他の物理的構成要素を表し得る。出力インターフェース108と入力インターフェース122とがワイヤレス構成要素を備える例では、出力インターフェース108と入力インターフェース122とは、4G、4G-LTE(登録商標)(ロングタームエボリューション)、LTEアドバンスト、5Gなど、セルラー通信規格に従って、符号化されたデータなどのデータを転送するように構成され得る。出力インターフェース108がワイヤレス送信機を備えるいくつかの例では、出力インターフェース108と入力インターフェース122とは、IEEE802.11仕様、IEEE802.15仕様(たとえば、ZigBee(登録商標))、Bluetooth(登録商標)規格など、他のワイヤレス規格に従って、符号化されたデータなどのデータを転送するように構成され得る。いくつかの例では、ソースデバイス102および/または宛先デバイス116は、それぞれのシステムオンチップ(SoC)デバイスを含み得る。たとえば、ソースデバイス102は、G-PCCエンコーダ200および/または出力インターフェース108に起因する機能を実施するためのSoCデバイスを含み得、宛先デバイス116は、G-PCCデコーダ300および/または入力インターフェース122に起因する機能を実施するためのSoCデバイスを含み得る。
【0019】
[0032]本開示の技法は、自律車両間の通信、スキャナ、カメラ、センサー、およびローカルサーバまたはリモートサーバなどの処理デバイスの間の通信、地理的マッピング、あるいは他の用途など、様々な用途のいずれかをサポートする符号化および復号に適用され得る。
【0020】
[0033]宛先デバイス116の入力インターフェース122は、コンピュータ可読媒体110(たとえば、通信媒体、記憶デバイス112、ファイルサーバ114など)から符号化されたビットストリームを受信する。符号化されたビットストリームは、コーディングされたユニット(たとえば、スライス、ピクチャ、ピクチャグループ、シーケンスなど)の特性および/または処理を記述する値を有するシンタックス要素など、G-PCCデコーダ300によっても使用される、G-PCCエンコーダ200によって定義されるシグナリング情報を含み得る。データコンシューマー118は、復号されたデータを使用する。たとえば、データコンシューマー118は、物理的物体のロケーションを決定するために、復号されたデータを使用し得る。いくつかの例では、データコンシューマー118は、ポイントクラウドに基づいて像を提示するためのディスプレイを備え得る。
【0021】
[0034]G-PCCエンコーダ200およびG-PCCデコーダ300は各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、など、様々な好適なエンコーダおよび/またはデコーダ回路のいずれか、あるいはそれらの任意の組合せとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、本開示の技法を実施するために、好適な非一時的コンピュータ可読媒体にソフトウェアのための命令を記憶し、1つまたは複数のプロセッサを使用してその命令をハードウェアで実行し得る。G-PCCエンコーダ200およびG-PCCデコーダ300の各々は、1つまたは複数のエンコーダまたはデコーダ中に含まれ得、それらのいずれかは、それぞれのデバイス中の複合エンコーダ/デコーダ(コーデック)の一部として統合され得る。G-PCCエンコーダ200および/またはG-PCCデコーダ300を含むデバイスは、1つまたは複数の集積回路、マイクロプロセッサ、および/または他のタイプのデバイスを備え得る。
【0022】
[0035]G-PCCエンコーダ200およびG-PCCデコーダ300は、ビデオポイントクラウド圧縮(V-PCC)規格またはジオメトリポイントクラウド圧縮(G-PCC)規格などのコーディング規格に従って動作し得る。本開示は、概して、データを符号化または復号するプロセスを含むためにピクチャのコーディング(たとえば、符号化および復号)に言及することがある。符号化されたビットストリームは、概して、コーディング決定(たとえば、コーディングモード)を表すシンタックス要素についての一連の値を含む。
【0023】
[0036]本開示は、概して、シンタックス要素などのある情報を「シグナリング」することに言及することがある。「シグナリング」という用語は、概して、符号化されたデータを復号するために使用されるシンタックス要素および/または他のデータについての値の通信を指すことがある。すなわち、G-PCCエンコーダ200は、ビットストリームにおいてシンタックス要素についての値をシグナリングし得る。概して、シグナリングは、ビットストリームにおいて値を生成することを指す。上述のように、ソースデバイス102は、宛先デバイス116による後の取出しのためにシンタックス要素を記憶デバイス112に記憶するときに起こり得る、ビットストリームを、実質的にリアルタイムで、またはリアルタイムではなく、宛先デバイス116にトランスポートし得る。
【0024】
[0037]ISO/IEC MPEG(JTC1/SC29/WG11)は、現在の手法の圧縮能力を大幅に上回る圧縮能力をもつポイントクラウドコーディング技術の規格化の潜在的な必要性を研究しており、その規格を作成することをターゲットにする。そのグループは、この分野の専門家によって提案された圧縮技術設計を評価するために、3次元グラフィックスチーム(3DG)として知られる協力的取り組みにおいて、この探究活動に関して協働している。
【0025】
[0038]ポイントクラウド圧縮アクティビティは、2つの異なる手法に分類される。第1の手法は、「ビデオポイントクラウド圧縮」(V-PCC)であり、これは、3D物体をセグメント化し、(2Dフレーム中で「パッチ」として表される)複数の2D平面中にセグメントを投影し、それらはさらに、高効率ビデオコーディング(HEVC)(ITU-T H.265)コーデックなどのレガシー2Dビデオコーデックによってコーディングされる。第2の手法は、「ジオメトリベースのポイントクラウド圧縮」(G-PCC)であり、これは、3Dジオメトリ、すなわち、3D空間内のポイントのセットの位置と、(3Dジオメトリに関連付けられた各ポイントについて)関連付けられた属性値とを直接圧縮する。G-PCCは、カテゴリー1(静的ポイントクラウド)とカテゴリー3(動的に収集されたポイントクラウド)の両方におけるポイントクラウドの圧縮に対処する。G-PCC規格の最近のドラフトは、G-PCC DIS、ISO/IEC JTC1/SC29/WG11 w19088、ブリュッセル、ベルギー、2020年1月において入手可能であり、コーデックの説明は、G-PCC Codec Description v6、ISO/IEC JTC1/SC29/WG11 w19091、ブリュッセル、ベルギー、2020年1月において入手可能である。
【0026】
[0039]ポイントクラウドは、3D空間内のポイントのセットを含んでおり、ポイントに関連付けられた属性を有し得る。属性は、R、G、B、または、Y、Cb、Crなどの色情報、あるいは反射率情報、あるいは他の属性であり得る。ポイントクラウドは、LIDARセンサーおよび3Dスキャナなどの様々なカメラまたはセンサーによってキャプチャされ得、また、コンピュータ生成され得る。ポイントクラウドデータは、限定はしないが、建築(モデリング)、グラフィックス(視覚化およびアニメーションのための3Dモデル)、および自動車産業(ナビゲーションを助けるために使用されるLIDARセンサー)を含む様々な用途において使用される。
【0027】
[0040]ポイントクラウドデータによって占有される3D空間は、仮想バウンディングボックスによって囲まれ得る。バウンディングボックス中のポイントの位置は、ある精度によって表され得、したがって、1つまたは複数のポイントの位置は、その精度に基づいて量子化され得る。最小レベルでは、バウンディングボックスは、単位立方体によって表される空間の最小単位であるボクセルに分割される。バウンディングボックス中のボクセルは、0個、1つ、または2つ以上のポイントに関連付けられ得る。バウンディングボックスは、タイルと呼ばれることがある複数の立方体/直方体領域に分割され得る。各タイルは、1つまたは複数のスライスにコーディングされ得る。バウンディングボックスの、スライスおよびタイルへの区分は、各区分中のポイントの数に基づき得るか、または他の考慮事項(たとえば、特定の領域がタイルとしてコーディングされ得る)に基づき得る。スライス領域は、ビデオコーデックにおけるものと同様の分割決定を使用してさらに区分され得る。
【0028】
[0041]図2は、G-PCCエンコーダ200の概要を提供する。図3は、G-PCCデコーダ300の概要を提供する。図示されたモジュールは論理的であり、G-PCCコーデック、すなわち、ISO/IEC MPEG(JTC1/SC29/WG11)によって研究されたTMC13テストモデルソフトウェアの参照実装において実装されたコードに必ずしも1対1に対応するとは限らない。
【0029】
[0042]G-PCCエンコーダ200とG-PCCデコーダ300の両方において、ポイントクラウド位置が最初にコーディングされる。属性コーディングは、復号されたジオメトリに依存する。図2および図3において、グレーの影付きモジュールは、カテゴリー1のデータのために典型的に使用されるオプションである。斜線付きのモジュールは、カテゴリー3のデータのために典型的に使用されるオプションである。他のすべてのモジュールは、カテゴリー1とカテゴリー3との間で共通である。
【0030】
[0043]カテゴリー3のデータの場合、圧縮されたジオメトリは、典型的に、ルートから個々のボクセルのリーフレベルに至るオクツリーとして表される。カテゴリー1のデータの場合、圧縮されたジオメトリは、典型的に、プルーニングされたオクツリー(すなわち、ルートからボクセルよりも大きいブロックのリーフレベルまでのオクツリー)と、プルーニングされたオクツリーの各リーフ内の表面を近似するモデルとによって表される。このようにして、カテゴリー1のデータとカテゴリー3のデータの両方がオクツリーコーディング機構を共有するが、カテゴリー1のデータは、さらに、各リーフ内のボクセルを表面モデルで近似し得る。使用される表面モデルは、ブロック当たり1~10個の三角形を備える三角形分割であり、三角形スープ(triangle soup)をもたらす。したがって、カテゴリー1のジオメトリコーデックは、Trisoupジオメトリコーデックとして知られており、カテゴリー3のジオメトリコーデックは、オクツリージオメトリコーデックとして知られている。
【0031】
[0044]オクツリーの各ノードにおいて、その子ノード(8つまでのノード)のうちの1つまたは複数について、占有率がシグナリングされる(推測されない場合)。(a)現在のオクツリーノードと面を共有するノード、(b)現在のオクツリーノードと面、辺または頂点を共有するノードなどを含む複数の近傍が指定される。各近傍内で、ノードおよび/またはその子の占有率が、現在のノードまたはその子の占有率を予測するために使用され得る。オクツリーのいくつかのノードにおいてまばらに分布するポイントについて、コーデックはまた、ポイントの3D位置が直接符号化される直接コーディングモードをサポートする。直接モードがシグナリングされることを示すために、フラグがシグナリングされ得る。最低レベルにおいて、オクツリーノード/リーフノードに関連付けられたポイントの数もコーディングされ得る。
【0032】
[0045]ジオメトリがコーディングされると、ジオメトリポイントに対応する属性がコーディングされる。1つの再構成された/復号されたジオメトリポイントに対応する複数の属性ポイントがあるとき、再構成されたポイントを表す属性値が導出され得る。
【0033】
[0046]G-PCCには、3つの属性コーディング方法、すなわち、領域適応階層変換(RAHT)コーディング、補間ベースの階層最近傍予測(予測変換)、および更新/リフティングステップを伴う補間ベースの階層最近傍予測(リフティング変換)がある。RAHTおよびリフティングは、典型的に、カテゴリー1のデータのために使用されるが、予測は、典型的に、カテゴリー3のデータのために使用される。しかしながら、いずれの方法も任意のデータのために使用され得、ちょうどG-PCCにおけるジオメトリコーデックの場合のように、ポイントクラウドをコーディングするために使用される属性コーディング方法は、ビットストリームにおいて指定される。
【0034】
[0047]属性のコーディングは、詳細レベル(LOD)において行われ得、各詳細レベルとともに、ポイントクラウド属性のより細かい表現が取得され得る。各詳細レベルは、近隣ノードからの距離メトリックに基づいて、またはサンプリング距離に基づいて指定され得る。
【0035】
[0048]G-PCCエンコーダ200において、属性についてのコーディング方法の出力として取得された残差が量子化される。残差は、現在のポイントの近傍にあるポイントに基づいておよび前に符号化されたポイントの属性値に基づいて導出された予測から属性値を減算することによって取得され得る。量子化された残差は、コンテキスト適応算術コーディングを使用してコーディングされ得る。
【0036】
[0049]図2の例では、G-PCCエンコーダ200は、座標変換ユニット202と、色変換ユニット204と、ボクセル化ユニット206と、属性転送ユニット208と、オクツリー分析ユニット210と、表面近似分析ユニット212と、算術符号化ユニット214と、ジオメトリ再構成ユニット216と、RAHTユニット218と、LOD生成ユニット220と、リフティングユニット222と、係数量子化ユニット224と、算術符号化ユニット226とを含み得る。
【0037】
[0050]図2の例に示されているように、G-PCCエンコーダ200は、ポイントクラウドにおけるポイントの位置のセットと属性のセットとを取得し得る。G-PCCエンコーダ200は、データソース104(図1)からポイントクラウドにおけるポイントの位置のセットと属性のセットとを取得し得る。位置は、ポイントクラウドにおけるポイントの座標を含み得る。属性は、ポイントクラウドにおけるポイントに関連付けられた色など、ポイントクラウドにおけるポイントに関する情報を含み得る。G-PCCエンコーダ200は、ポイントクラウドにおけるポイントの位置の符号化された表現を含むジオメトリビットストリーム203を生成し得る。G-PCCエンコーダ200は、属性のセットの符号化された表現を含む属性ビットストリーム205をも生成し得る。
【0038】
[0051]座標変換ユニット202は、座標を初期領域から変換領域に変換するために、ポイントの座標に変換を適用し得る。本開示は、変換された座標を変換座標と呼ぶことがある。色変換ユニット204は、属性の色情報を異なる領域に変換するために変換を適用し得る。たとえば、色変換ユニット204は、色情報をRGB色空間からYCbCr色空間に変換し得る。
【0039】
[0052]さらに、図2の例では、ボクセル化ユニット206は、変換座標をボクセル化し得る。変換座標のボクセル化は、量子化とポイントクラウドのいくつかのポイントを除去することとを含み得る。言い換えれば、ポイントクラウドの複数のポイントは、単一の「ボクセル」内に包含され得、これは、その後、いくつかの観点において1つのポイントとして扱われ得る。さらに、オクツリー分析ユニット210は、ボクセル化された変換座標に基づいてオクツリーを生成し得る。さらに、図2の例では、表面近似分析ユニット212は、ポイントのセットの表面表現を潜在的に決定するためにポイントを分析し得る。算術符号化ユニット214は、表面近似分析ユニット212によって決定されたオクツリーおよび/または表面の情報を表すシンタックス要素をエントロピー符号化し得る。G-PCCエンコーダ200は、ジオメトリビットストリーム203においてこれらのシンタックス要素を出力し得る。ジオメトリビットストリーム203は、算術的に符号化されていないシンタックス要素を含む他のシンタックス要素をも含み得る。
【0040】
[0053]ジオメトリ再構成ユニット216は、オクツリー、表面近似分析ユニット212によって決定された表面を示すデータ、および/または他の情報に基づいて、ポイントクラウドにおけるポイントの変換座標を再構成し得る。ジオメトリ再構成ユニット216によって再構成された変換座標の数は、ボクセル化および表面近似のために、ポイントクラウドのポイントの元の数とは異なり得る。本開示は、得られたポイントを再構成されたポイントと呼ぶことがある。属性転送ユニット208は、ポイントクラウドの元のポイントの属性をポイントクラウドの再構成されたポイントに転送し得る。
【0041】
[0054]さらに、RAHTユニット218は、再構成されたポイントの属性にRAHTコーディングを適用し得る。いくつかの例では、RAHTの下で、4つの低(L)周波数ノードと4つの高(H)周波数ノードとを取得するために、2×2×2ポイント位置のブロックの属性がとられ、1つの方向に沿って変換される。その後、4つの低周波数ノード(L)は、2つの低(LL)周波数ノードと2つの高(LH)周波数ノードとを取得するために、第2の方向において変換される。2つの低周波数ノード(LL)は、1つの低(LLL)周波数ノードと1つの高(LLH)周波数ノードとを取得するために、第3の方向に沿って変換される。低周波数ノードLLLは、DC係数に対応し、高周波数ノードH、LH、およびLLHは、AC係数に対応する。各方向における変換は、2つの係数重みをもつ1-D変換であり得る。低周波数係数は、RAHT変換の次のより高いレベルのための2×2×2ブロックの係数としてとられ得、AC係数は、変更なしに符号化され、そのような変換は、上部ルートノードまで続く。符号化のためのツリートラバーサルは、それらの係数のために使用されるべき重みを計算するために上部から下部へ使用され、変換順序は、下部から上部へ、である。それらの係数は、次いで、量子化され、コーディングされ得る。
【0042】
[0055]代替または追加として、LOD生成ユニット220およびリフティングユニット222は、再構成されたポイントの属性に、それぞれLOD処理およびリフティングを適用し得る。LOD生成が、属性を異なる改良レベルに分割するために使用される。各改良レベルは、ポイントクラウドの属性の改良を提供する。第1の改良レベルは、粗い近似を提供し、少数のポイントを含んでおり、後続の改良レベルは、典型的に、より多くのポイントを含んでおり、以下同様である。改良レベルは、距離ベースのメトリックを使用して構成され得るか、または1つまたは複数の他の分類基準(たとえば、特定の順序からのサブサンプリング)をも使用し得る。したがって、すべての再構成されたポイントが、改良レベル中に含まれ得る。各詳細レベルが、特定の改良レベルまでのすべてのポイントの集合(union)をとることによって作り出され、たとえば、LOD1が、改良レベルRL1に基づいて取得され、LOD2が、RL1およびRL2に基づいて取得され、...LODNが、RL1、RL2、...RLNの集合によって取得される。いくつかの場合には、LOD生成の後に、予測方式(たとえば、予測変換)が続き得、ここで、LODにおける各ポイントに関連する属性が、先行するポイントの重み付き平均から予測され、残差が量子化およびエントロピーコーディングされる。リフティング方式は、予測変換機構の上に構築され、ここで、係数を更新するために更新オペレータ(update operator)が使用され、係数の適応量子化が実施される。
【0043】
[0056]RAHTユニット218およびリフティングユニット222は、属性に基づいて係数を生成し得る。係数量子化ユニット224は、RAHTユニット218またはリフティングユニット222によって生成された係数を量子化し得る。算術符号化ユニット226は、量子化係数を表すシンタックス要素に算術コーディングを適用し得る。G-PCCエンコーダ200は、属性ビットストリーム205においてこれらのシンタックス要素を出力し得る。属性ビットストリーム205は、算術的に符号化されていないシンタックス要素を含む他のシンタックス要素をも含み得る。
【0044】
[0057]図3の例では、G-PCCデコーダ300は、ジオメトリ算術復号ユニット302と、属性算術復号ユニット304と、オクツリー合成ユニット306と、逆量子化ユニット308と、表面近似合成ユニット310と、ジオメトリ再構成ユニット312と、RAHTユニット314と、LoD生成ユニット316と、逆リフティングユニット318と、逆変換座標ユニット320と、逆変換色ユニット322とを含み得る。
【0045】
[0058]G-PCCデコーダ300は、ジオメトリビットストリーム203と属性ビットストリーム205とを取得し得る。デコーダ300のジオメトリ算術復号ユニット302は、算術復号(たとえば、コンテキスト適応型バイナリ算術コーディング(CABAC)または他のタイプの算術復号)をジオメトリビットストリーム203中のシンタックス要素に適用し得る。同様に、属性算術復号ユニット304は、算術復号を属性ビットストリーム205中のシンタックス要素に適用し得る。
【0046】
[0059]オクツリー合成ユニット306は、ジオメトリビットストリーム203からパースされたシンタックス要素に基づいてオクツリーを合成し得る。オクツリーのルートノードで開始すると、各オクツリーレベルにおける8つの子ノードの各々の占有が、ビットストリームにおいてシグナリングされる。そのシグナリングが、特定のオクツリーレベルにおける子ノードが占有されることを示すとき、この子ノードの子の占有がシグナリングされる。各オクツリーレベルにおけるノードのシグナリングは、後続のオクツリーレベルに進む前にシグナリングされる。オクツリーの最終レベルにおいて、各ノードがボクセル位置に対応し、リーフノードが占有されるとき、1つまたは複数のポイントが、ボクセル位置において占有されることが指定され得る。いくつかの事例では、オクツリーのいくつかの分岐が、量子化により最終レベルよりも前に終了し得る。そのような場合、リーフノードは、子ノードを有しない占有されたノードと見なされる。表面近似がジオメトリビットストリーム203において使用される事例では、表面近似合成ユニット310は、ジオメトリビットストリーム203からパースされたシンタックス要素に基づいて、またオクツリーに基づいて、表面モデルを決定し得る。
【0047】
[0060]さらに、ジオメトリ再構成ユニット312は、ポイントクラウドにおけるポイントの座標を決定するために再構成を実施し得る。オクツリーのリーフノードにおける各位置について、ジオメトリ再構成ユニット312は、オクツリーにおけるリーフノードのバイナリ表現を使用することによって、ノード位置を再構成し得る。各それぞれのリーフノードにおいて、それぞれのリーフノードにおけるポイントの数がシグナリングされ、これは、同じボクセル位置における重複ポイントの数を示す。ジオメトリ量子化が使用されるとき、ポイント位置は、再構成されたポイント位置値を決定するためにスケーリングされる。
【0048】
[0061]逆変換座標ユニット320は、ポイントクラウドにおけるポイントの再構成された座標(位置)を変換領域から初期領域に再びコンバートするために、再構成された座標に逆変換を適用し得る。ポイントクラウドにおけるポイントの位置は、浮動小数点領域におけるものであり得るが、G-PCCコーデックにおけるポイント位置は、整数領域においてコーディングされる。逆変換は、位置を元の領域にコンバートするために使用され得る。
【0049】
[0062]さらに、図3の例では、逆量子化ユニット308は、属性値を逆量子化し得る。属性値は、(たとえば、属性算術復号ユニット304によって復号されたシンタックス要素を含む)属性ビットストリーム205から取得されたシンタックス要素に基づき得る。
【0050】
[0063]属性値がどのように符号化されるかに応じて、RAHTユニット314は、逆量子化された属性値に基づいて、ポイントクラウドのポイントについての色値を決定するためにRAHTコーディングを実施し得る。RAHT復号が、ツリーの上部から下部へ行われる。各レベルにおいて、逆量子化プロセスから導出された低周波数係数および高周波数係数が、成分値を導出するために使用される。リーフノードにおいて、導出された値は、それらの係数の属性値に対応する。ポイントについての重み導出プロセスは、G-PCCエンコーダ200において使用されるプロセスと同様である。代替的に、LOD生成ユニット316および逆リフティングユニット318は、詳細レベルベースの技法を使用してポイントクラウドのポイントについての色値を決定し得る。LOD生成ユニット316は、ポイントの属性の漸進的により細かい表現を与える各LODを復号する。予測変換を用いて、LOD生成ユニット316は、前のLODにおけるものである、または同じLODにおいて前に再構成された、ポイントの重み付き和からポイントの予測を導出する。LOD生成ユニット316は、属性の再構成された値を取得するために、(逆量子化の後に取得された)残差に予測を追加し得る。リフティング方式が使用されるとき、LOD生成ユニット316は、属性値を導出するために使用される係数を更新するための更新オペレータをも含み得る。LOD生成ユニット316は、この場合、逆適応量子化をも適用し得る。
【0051】
[0064]さらに、図3の例では、逆変換色ユニット322は、色値に逆色変換を適用し得る。逆色変換は、エンコーダ200の色変換ユニット204によって適用された色変換の逆であり得る。たとえば、色変換ユニット204は、色情報をRGB色空間からYCbCr色空間に変換し得る。したがって、逆色変換ユニット322は、色情報をYCbCr色空間からRGB色空間に変換し得る。
【0052】
[0065]図2および図3の様々なユニットは、エンコーダ200およびデコーダ300によって実施される動作の理解を支援するために示されている。ユニットは、固定機能回路、プログラマブル回路、またはそれらの組合せとして実装され得る。固定機能回路は、特定の機能を提供する回路を指し、実施され得る動作に関してあらかじめ設定される。プログラマブル回路は、様々なタスクを実施するように、および実施され得る動作においてフレキシブルな機能を提供するようにプログラムされ得る回路を指す。たとえば、プログラマブル回路は、ソフトウェアまたはファームウェアの命令によって定義された様式でプログラマブル回路を動作させるソフトウェアまたはファームウェアを実行し得る。固定機能回路は、(たとえば、パラメータを受信するかまたはパラメータを出力するために)ソフトウェア命令を実行し得るが、固定機能回路が実施する動作のタイプは、概して不変である。いくつかの例では、ユニットのうちの1つまたは複数は、別個の回路ブロック(固定機能またはプログラマブル)であり得、いくつかの例では、ユニットのうちの1つまたは複数は、集積回路であり得る。
【0053】
[0066](Sebastien Lasserre、David Flynn、「[GPCC] Planar mode in octree-based geometry coding」、ISO/IEC JTC1/SC29/WG11 MPEG/m48906、イェーテボリ、スウェーデン、2019年7月)で最初に提案された平面コーディングモードは、ジュネーブ、スイスにおける第128回MPEG会議において採択された(「Sebastien Lasserre、Jonathan Taquet、「[GPCC] CE13.22 report on planar coding mode」、ISO/IEC JTC1/SC29/WG11 MPEG/m50008、ジュネーブ、スイス、2019年10月)。(Sebastien Lasserre、Jonathan Taquet、「[GPCC][CE 13.22 related] An improvement of the planar coding mode」、ISO/IEC JTC1/SC29/WG11 MPEG/m50642、ジュネーブ、スイス、2019年10月、以下では「m50642」)で最初に提案された角度コーディングモードは、ブリュッセル、ベルギーにおける第129回MPEG会議において採択され(Sebastien Lasserre、Jonathan Taquet、「[GPCC] CE 13.22 report on angular mode」、ISO/IEC JTC1/SC29/WG11 MPEG/m51594、ブリュッセル、ベルギー、2020年1月、以下では「m51594」)、典型的なLIDARセンサーのセンサー特性を使用することによって平面モードのコーディング効率を向上させる。角度コーディングモードは、平面モードとともに随意に使用され、典型的なLIDARセンサー中でレーザービームを検知する位置および角度についての知識を採用することによって垂直(vertical)(z)平面位置シンタックス要素のコーディングを改善する。さらに、角度コーディングモードは、IDCMでの垂直z位置ビットのコーディングを改善するために随意に使用され得る。別個の寄稿(Geert Van der Auwera、Bappaditya Ray、Louis Kerofsky、Adarsh K.Ramasubramonian、Marta Karczewicz、「[GPCC][New Proposal] Angular mode simplifications and HLS refinements」、ISO/IEC JTC1/SC29/WG11 MPEG/m53693、遠隔会議(以前はアルプバッハ会議)、2020年4月)では、角度コーディングモードのコンテキスト導出が簡略化され、センサーデータパラメータのHLSコーディングがより効率的にされた。以下のセクションにおける角度モードの記述は、元のMPEG寄稿文書[m50642、m51594]と、GPCC DISテキスト(G-PCC DIS、ISO/IEC JTC1/SC29/WG11 w19617、遠隔会議、2020年11月、以下では「GPCC DIS」)とに基づく。
【0054】
[0067](Sebastien Lasserre、Jonathan Taquet、「[GPCC] [CE13.22 related] The azimuthal coding mode」、ISO/IEC JTC1/SC29/WG11 MPEG/m51596、ブリュッセル、ベルギー、2020年1月、以下では「m51596」)において最初に提案された方位角コーディングモードは、第130回MPEG遠隔会議において採択された(Sebastien Lasserre、Jonathan Taquet、「[GPCC] [CE 13.22] Report on azimuthal coding mode」、ISO/IEC JTC1/SC29/WG11 MPEG/m52958、遠隔会議(以前はアルプバッハ会議)、2020年4月、以下では「m52958」)。方位角コーディングモードは、角度モードと同様であり、角度モードを平面モードの(x)および(y)平面位置シンタックス要素のコーディングに拡大し、IDCMでのxまたはy位置ビットのコーディングを改善する。第131回MPEG遠隔会議における別個の寄稿(Geert Van der Auwera、Bappaditya Ray、Adarsh K.Ramasubramonian、Marta Karczewicz、「[GPCC][New Proposal] Planar and azimuthal coding mode simplifications」、ISO/IEC JTC1/SC29/WG11 MPEG/m54694、遠隔会議、2020年7月、以下では「m54694」)では、方位角モードにおいて使用されるコンテキストの数が著しく低減された。
【0055】
[0068]注:「角度モード」は、以下のセクションでは方位角モードをも指すことがある。
【0056】
[0069]平面コーディングモードに関係する仕様が、以下のようにGPCC DISにおいて要約される。
8.2.3.1 平面コーディングモードについてのノードの適格性
XXX 分割および再配置
[XXX、このプロセスは、is_planar_flagを復号した後の平面レート更新がなくなっている]
占有平面の明示的コーディングは、XXXの確率を条件とする。
k=0..2について要素PlanarRate[k]をもつアレイPlanarRateは、ノードの占有がk番目の軸に直角な単一の平面を形成する確率の推定値である。
変数LocalDensityは、ノード中の占有された子の平均数の推定値である。
変数NumNodesUntilPlanarUpdateは、PlanarRateとLocalDensityとを更新する前にパースされることになるノードの数をカウントする。
[XXX エントロピー状態継続]
geometry_octreeシンタックス構造をパースすることの開始時に、PlanarRateとLocalDensityとは、以下のように初期化される:
【0057】
【数1】
【0058】
各geometry_octree_nodeシンタックス構造をパースすることの開始時に、NumNodesUntilPlanarUpdateは、減分される。NumNodesUntilPlanarUpdateが0よりも小さい場合、PlanarRateとLocalDensityとは、以下のように更新される。
【0059】
占有された兄弟ノードの数が、決定され、LocalDensity推定値を更新するために使用される。
【0060】
【数2】
【0061】
次の更新までのノードの数は、以下の通りである。
【0062】
【数3】
【0063】
親ノードの占有情報は、各軸に沿って、単一の占有された平面の存在を決定し、対応する平面確率推定値PlanarRate[k]を更新するために使用される。
【0064】
【数4】
【0065】
各geometry_octree_nodeシンタックス構造をパースすることの開始時に、各軸について、現在のノードが平面情報をシグナリングするために適格であるかどうかが決定される。このプロセスの出力は、k=0..2について要素PlanarEligible[k]をもつアレイPlanarEligibleである。
最初に、PlanarRateは、表18に従って可能性が最も高いものから最も低いものへの3つの平面の順序planeOrder[k]を決定するために使用される。
次いで、PlanarEligibleは、以下のように設定される。
【0066】
【数5】
【0067】
【表1】
【0068】
シンタックス要素が、ビットストリーム中にシグナリングされ得る:
1に等しいis_planar_flag[axisIdx]は、現在のノードの子の位置が、axisIdx番目の軸に直角な単一の平面を形成することを示す。0に等しいis_planar_flag[axisIdx]は、存在するとき、現在のノードの子の位置が、axisIdx番目の軸に直角な両方の平面を占有することを示す。
is_planar_flagをコーディングするためのコンテキストインデックス(ctxIdx)が、GPCC DISにおける表37において指定され、ここで、それは、axisIdxに等しく設定される。
8.2.3.2 軸に沿った最も近接したノードを追跡するバッファ
アレイPlanarPrevPos、PlanarPlane、IsPlanarNodeは、シンタックス要素plane_positionのためのctxIdxの決定において使用するために前に復号されたジオメトリツリーノードに関する情報を記録する。geometry_planar_enabled_flagが0に等しいか、またはplanar_buffer_disabled_flagが1に等しいとき、アレイは復号プロセスによって使用されない。
このプロセスでは、変数axisIdxが、3つのコーディングされた軸のうちの1つを表すために使用され、変数axisPosは、axisIdx番目の軸に沿ったノードの位置を表す。axisPosの値は、0..0x3fffのレンジ内にある。
値IsPlanarNode[axisIdx][axisPos]をもつアレイIsPlanarNodeは、axisPosに等しいaxisIdx番目の位置成分をもつ最も最近復号されたノードがaxisIdx番目の軸に直角な平面中の平面であるのかどうかを示す。
axisPosに等しいaxisIdx番目の位置成分をもつ最も最近復号されたノードの最大位置成分を記憶する値PlanarPrevPos[axisIdx][axisPos]をもつアレイPlanarPrevPos。
値PlanarPlane[axisIdx][axisPos]をもつアレイPlanarPlaneは、axisPosに等しいaxisIdx番目の位置成分をもつ最も最近復号されたノードのためのplane_position[axisIdx]の値を示す。
各ジオメトリツリーレベルの開始時に、アレイPlanarPrevPosおよびIsPlanarNodeの各要素が0に初期化される。
XXX パラメータchildIdxおよびaxisIdxをもつ各geometry_planar_mode_dataシンタックス構造を復号した後に、アレイPlanarPrevPos、PlanarPlaneおよびIsPlanarNodeが以下のように更新される。
【0069】
axisIdx番目の軸に沿った位置を表す変数axisPosは、以下のように導出される。
【0070】
【数6】
【0071】
ノードに対応するアレイエントリは、以下のように更新される。
【0072】
【数7】
【0073】
8.2.3.3 シンタックス要素plane_positionのためのctxIdxの決定
このプロセスへの入力は、以下の通りである。
【0074】
平面に垂直な(normal to)軸を識別する変数axisIdx、および
ジオメトリツリーレベル内の現在のノードの位置(sN,tN,vN)。
このプロセスの出力は、変数ctxIdxである。
変数neighOccupiedは、両方ともaxisIdx番目の軸に沿った現在のノードに隣接するノードがあるのかどうかを示す。それは以下のように導出される:XXX
【0075】
【数8】
【0076】
planar_buffer_disabled_flagが1に等しいとき、ctxIdxの値は、adjPlaneCtxIncに等しく設定され、さらなる処理は、このプロセスによって実施されない。そうでない場合、この項の残りが適用される。
変数axisPosは、axisIdx番目の軸に沿った現在のノードの14個の最下位位置ビットを示す。
【0077】
【数9】
【0078】
変数distは、現在のノードと、axisIdx番目の軸に沿ったaxisPosの同じ値をもつ最も最近復号された[Ed.復号されたはおそらく間違った用語である?]ノード位置との間の距離を表す。それは以下のように導出される。
【0079】
【数10】
【0080】
コンテキストインデックスctxIdxは、以下のように導出される。
【0081】
【数11】
【0082】
8.2.3.4 水平面位置のコーディングのためのplanePosIdxAzimuthalSおよびplanePosIdxAzimuthalTの決定
[Ed.これが上記のctxIdxとどのように相互作用するかを修正する。NB:ctxIdxは平面非依存でない]
plane_position[0]の算術コーディングのためのplanePosIdxAngularS、およびplane_position[1]の算術コーディングのためのplanePosIdxAngularTの決定は、以下のように取得される。
geometry_angular_enabled_flagが0に等しいとき、planePosIdxAzimuthalSとplanePosIdxAzimuthalTの両方の値は、planePosIdxに等しく設定される。そうでない場合、以下が適用される。
【0083】
【数12】
【0084】
plane_position[2]の算術コーディングのためのcontextAngularの決定は、XREFで説明されるように実施される。
8.2.3.5 垂直面位置のコーディングのためのplanePosIdxAngularの決定
[Ed.これが上記のctxIdxとどのように相互作用するかを修正する。NB:ctxIdxは平面独立していない]
plane_position[2]の算術コーディングのためのplanePosIdxAngularの決定は、以下のように取得される。
geometry_angular_enabled_flagが0に等しいとき、planePosIdxAngularの値は、planePosIdxに等しく設定される。そうでない場合、以下が適用される。
【0085】
【数13】
【0086】
plane_position[2]の算術コーディングのためのcontextAngularの決定は、セクション8.2.4.4で説明されるように実施される。
GPCC DISにおける角度および方位角モード
角度モードシンタックス
角度コーディングモードが任意のコーディング効率の利益を有するために必要とされるLidarレーザーセンサー情報を搬送するシンタックス要素は、表2においてイタリック体である。これらのシンタックス要素のセマンティクスは、GPCC DISにおいて以下のように指定される。
1に等しいgeometry_planar_enabled_flagは、平面コーディングモードがアクティブ化されることを示す。0に等しいgeometry_planar_enabled_flagは、平面コーディングモードがアクティブ化されないことを示す。存在しないとき、geometry_planar_enabled_flagは0であると推測される。
geom_planar_th[i]は、0..2のレンジ内のiについて、平面コーディングモードが効率的であるためのi番目に可能性の高い方向に沿った平面コーディングモードについてのアクティブ化のしきい値の値を指定する。geom_planar_th[i]は、0..127のレンジ内の整数である。
geom_idcm_rate_minus1は、ノードが直接コーディングのために適格であり得るレートを指定する。存在しないとき、geom_idcm_rate_minus1は31であると推測される。
アレイIdcmEnableMaskは、以下のように導出される。
【0087】
【数14】
【0088】
1に等しいgeometry_angular_enabled_flagは、角度コーディングモードがアクティブ化されることを示す。0に等しいgeometry_angular_enabled_flagは、角度コーディングモードがアクティブ化されないことを示す。
1に等しいgeom_slice_angular_origin_present_flagは、スライス相対角度原点(slice relative angular origin)がジオメトリスライスヘッダ中に存在することを指定する。0に等しいgeom_slice_angular_origin_present_flagは、角度原点がジオメトリスライスヘッダ中に存在しないことを指定する。存在しないとき、geom_slice_angular_origin_present_flagは0であると推測される。
geom_angular_origin_bits_minus1+1は、シンタックス要素geom_angular_origin_xyz[k]のビット単位の長さである。
geom_angular_origin_xyz[k]は、角度コーディングモードの処理において使用される原点の(x,y,z)座標のk番目の成分を指定する。存在しないとき、k=0..2の場合geom_angular_origin_xyz[k]の値は0であると推測される。
geom_angular_azimuth_scale_log2およびgeom_angular_radius_scale_log2は、カルテシアン座標への変換中に球状座標系を使用してコーディングされた位置をスケーリングするために使用されるファクタを指定する。
geom_angular_azimuth_step_minus1+1は、方位角の単位変化を指定する。角度予測ツリーコーディングにおいて使用される差分予測残差は、geom_angular_azimuth_step_minus1+1の倍数として部分的に表され得る。geom_angular_azimuth_step_minus1の値は、(1<<geom_angular_azimuth_scale_log2)よりも小さいものとする。
numbers_lasers_minus1+1は、角度コーディングモードのために使用されるレーザーの数を指定する。
laser_angle_init、およびi=0..number_lasers_minus1の場合のlaser_angle_diff[i]は、第1および第2のコーディングされた軸によって定義される水平面に対するi番目のレーザーの仰角の正接を指定する。
i=0..number_lasers_minus1の場合のアレイLaserAngle[i]は、以下のように導出される。
【0089】
【数15】
【0090】
i=1..number_lasers_minus1の場合のLaserAngle[i]の値が、LaserAngle[i-1]よりも大きいかまたはそれに等しいものとすることが、ビットストリーム適合の要件である。
laser_correction_init、およびi=1..number_lasers_minus1の場合のlaser_correction_diff[i]は、GeomAngularOrigin[2]に対するi番目のレーザー位置の、第2の内部軸に沿った補正を指定する。
laser_phi_per_turn_init_minus1、およびi=1..number_lasers_minus1の場合のlaser_phi_per_turn_diff[i]は、角度コーディングモードの処理において使用される原点に位置する回転検知システムのi番目のレーザーによって生成されたサンプルの数を指定する。
i=1..number_lasers_minus1の場合のアレイLaserCorrection[i]およびLaserPhiPerTurn[i]は、以下のように導出される。
【0091】
【数16】
【0092】
i=0..number_lasers_minus1の場合のLaserPhiPerTurn[i]の値が0でないものとすることが、ビットストリーム適合の要件である。
i=0..number_lasers_minus1の場合のアレイDeltaPhi[i]およびInvDeltaPhi[i]は、以下のように導出される。
【0093】
【数17】
【0094】
1に等しいplanar_buffer_disabled_flagは、バッファを使用して最も近いノードを追跡することが、平面モードフラグおよび平面位置を平面モードでコーディングするプロセスにおいて使用されないことを示す。0に等しいplanar_buffer_disabled_flagは、バッファを使用して最も近いノードを追跡することが使用されることを示す。存在しないとき、planar_buffer_disabled_flagは!geometry_planar_enabled_flagであると推測される。
【0095】
【表2-1】
【表2-2】
【表2-3】
【表2-4】
【0096】
平面モードおよび直接モードのデータシンタックスは、それぞれ、表3および表4中に含まれる。
【0097】
【表3-1】
【表3-2】
【0098】
【表4】
【0099】
8.2.4.1 ノードについての角度適格性の導出プロセス
XXX 入力/出力
geometry_angular_enabled_flagが0に等しい場合、angular_eligibleは0に等しくなるように設定される。
そうでない場合、以下が適用される。
レーザー間の最小角距離を指定する変数deltaAngleは、以下のように導出される。
【0100】
【数18】
【0101】
最後に、angular_eligibleは以下のように導出される。[Ed、sNchildは確認する必要がある]
【0102】
【数19】
【0103】
8.2.4.2 ノードに関連付けられたレーザーインデックスlaserIndexの導出プロセス
XXX 入力/出力
角度適格性angular_eligibleが0に等しい場合、laserIndexインデックスはプリセット値UNKOWN_LASERに設定される。
そうではなく、角度適格性angular_eligibleが1に等しい場合、8.2.5.1で説明されるプロセスの継続として以下が適用される。
第1に、Lidarからの現在のノードの半径方向距離の逆数rInvが、以下のように決定される。
【0104】
【数20】
【0105】
次いで、角度theta32は以下のように決定される。
【0106】
【数21】
【0107】
[Ed XXX:laserIndex[Parent]は無意味であり、別の状態アレイを追加する必要がある]
最後に、角度適格性および関連付けられたレーザーが、親ノードParentに基づいて以下のように決定される。
【0108】
【数22】
【0109】
8.2.4.3 平面コーディングモードのためのコンテキストcontextAzimuthalSおよびcontextAzimuthalTの導出プロセス
XXX 入力/出力
8.2.5.2で説明されるプロセスの継続として以下が適用される。
第1に、2つの角度が、角度原点に対するノード位置から推論される
【0110】
【数23】
【0111】
第2に、方位角予測子が、アレイphiBufferから取得される
【0112】
【数24】
【0113】
2つの方位角コンテキストが以下のように初期化される
【0114】
【数25】
【0115】
次いで、予測子predPhiが0x80000000に等しくない場合、2つの方位角コンテキストを改良するために以下が適用される
【0116】
【数26】
【0117】
8.2.4.4 平面コーディングモードのためのコンテキストcontextAngularの導出プロセス
XXX 入力/出力
レーザーインデックスlaserIndexがUNKOWN_LASERに等しい場合、contextAngularはプリセット値UNKOWN_CONTEXTに設定される。そうではなく、レーザーインデックスlaserIndexがUNKOWN_LASERに等しくない場合、8.2.5.2で説明されるプロセスの継続として以下が適用される。
第1に、下側平面および上側平面に対する2つの角度差thetaLaserDeltaBotおよびthetaLaserDeltaTopが決定される。
【0118】
【数27】
【0119】
次いで、角度コンテキストが2つの角度差から推論される。
【0120】
【数28】
【0121】
[0070]GPCCの動き予測。G-PCC InterEMソフトウェア(G-PCCにおけるインター予測のための探究モデル、ISO/IEC JTC1/SC29 WG11 N18096、マカオ、中国、2018年10月)に関与する2つの種類の動き、グローバル動き行列およびローカルノード動きベクトルがある。グローバル動きパラメータは、予測(参照)フレームにおける(ローカル動きモードが適用されているポイントを除く)すべてのポイントに対して適用されることになる回転行列および並進ベクトルとして定義される。オクツリーのノードのローカルノード動きベクトルは、予測(参照)フレームにおけるノード内のポイントに対してのみ適用される動きベクトルである。InterEMにおける動き推定アルゴリズムの詳細が以下で説明される。
【0122】
[0071]図4は、InterEMのための例示的な動き推定技法を示すフローチャートである。入力予測(参照)フレームと現在フレームとが与えられると、グローバル動きがグローバルスケールにおいて最初に推定される。予測に対してグローバル動きを適用した後に、ローカル動きが、オクツリーにおけるより細かいスケールのノードレベルにおいて推定される。最後に、推定されたローカルノード動きが、動き補償において適用される。
【0123】
[0072]上記の技法の詳細が以下で説明される。
【0124】
[0073]グローバル動き行列および並進ベクトルを推定するための方法。図5は、ローカルノード動きベクトルの推定のための例示的な技法を示すフローチャートである。図5に示されているように、動きベクトルは、再帰的様式で推定される。最良の好適な動きベクトルを選定するために使用されるコスト関数は、レートひずみコストに基づき得る。
【0125】
[0074]現在のノードが8つの子に分割されない場合、現在のノードと予測ノードとの間の最低コストを生じ得る動きベクトルが決定される。現在のノードが8つの子に分けられた場合、動き推定アルゴリズムが適用され、分割条件下での総コストが、各子ノードの推定されたコスト値を加算することによって取得される。分離すべきなのか、分離すべきでないのかの決定は、分割することと分割しないこととの間のコストを比較することによって到達され、分割される場合、各サブノードは、それのそれぞれの動きベクトルを割り当てられ(または、それの子にさらに分割され得)、分割されない場合、現在のノードは、動きベクトルを割り当てられる。
【0126】
[0075]動きベクトル推定の性能に影響を及ぼす2つのパラメータは、ブロックサイズ(BlockSize)と最小予測ユニットサイズ(MinPUSize)とである。BlockSizeは、動きベクトル推定を適用するためのノードサイズの上限を定義し、MinPUSizeは、下限を定義する。
【0127】
[0076]上記で説明された技法は、1つまたは複数の欠点を提示し得る。ノードの参照ブロックは、推定された動き情報(回転および並進)を使用する動き補償によって導出される。動き情報の良好な推定が、現在のノードと参照ノードとの間の、占有、平面情報など、ジオメトリ構造に関する高相関につながる。したがって、参照ノードのこのジオメトリ情報を利用することが、現在のノードのコーディング性能を改善することになる。本開示の1つまたは複数の技法によれば、G-PCCコーダ(たとえば、G-PCCエンコーダ200またはG-PCCデコーダ300)が、現在のノードの平面情報のコーディングにおいて参照ブロックの情報を利用し得る。一例として、G-PCCコーダは、平面コーディングモードのためのノードの適格性、平面フラグおよび平面インデックスをコーディングする際のコンテキストの選択において参照ブロックの情報を利用し得る。本文書で開示される1つまたは複数の技法は、独立してまたは組み合わされて適用され得る。
【0128】
[0077]インター予測を使用するノードの平面適格性。一例では、PlanarRateは、参照ブロックの平面情報に依存するファクタ(R)によって更新され得る。この例では、GPCC DISにおけるセクション8.2.3.1におけるPlanarRateは、以下として指定され得る(追加が太字イタリック体で示されている)。
親ノードの占有情報は、各軸に沿って、単一の占有された平面の存在を決定し、対応する平面確率推定値PlanarRate[k]を更新するために使用される。
【0129】
【数29】
【0130】
ここで、R[k]は、参照ブロックがk番目の方向において平面モードであるかどうかに依存するスケーリングファクタである。一例では、参照ブロックがk番目の方向において平面である場合、R[k]は1よりも高く設定され得る。そうでない場合、R[k]は1よりも低く設定され得る。
【0131】
[0078]別の例では、PlanarEligibleは、参照ブロックが平面でない場合、許容されないことがある。
次いで、PlanarEligibleは、以下のように設定される。
【0132】
【数30】
【0133】
[0079]代替的に、参照平面レート(PlanarRateRef)が参照ブロックの平面性に基づいて別々に決定され得る。さらに、平面モードのための現在のノードの適格性が、参照平面レートをしきい値と比較することに基づいて決定され得る。たとえば:
[0080]次いで、PlanarEligibleは、以下のように設定される。
【0134】
【数31】
【0135】
[0081]いくつかの場合には、平面インデックス位置は、参照ノードの平面インデックス位置に基づいて導出される。いくつかの場合には、この決定は、しきい値比較に基づき得る。
【0136】
[0082]平面コピーモード(PCM)。G-PCCコーダが、現在のノードと参照ノードとがすべての方向において同じ平面モードを共有するかどうかを示すために、ビットストリームにおいてフラグ(PCMフラグ)をシグナリングし得る(たとえば、k=0..2)。このフラグが1であるとき、デコーダは、各方向について平面フラグを復号する必要がないことがあり、デコーダは、参照ノードにおける対応する値のみを使用する(たとえば、平面フラグは、参照ノードからコピーされ得る)。フラグが0であるとき、各方向における平面フラグはシグナリングされ得る。
【0137】
[0083]さらなるレベルのPCMフラグにおいて、それは、現在のノードと参照ノードとが平面位置インデックスを共有するかどうかをも示し得る。この例では、PCMフラグが1である場合、k番目の方向において、デコーダは、平面位置インデックスを復号する必要がなく、デコーダは、同じk番目の方向において参照ブロックにおける平面インデックスを使用し得る。
【0138】
[0084]いくつかの例では、PCMフラグは、条件付きでシグナリングされ得る。たとえば、参照ブロックの占有は0であり、PCMフラグは、シグナリングされないことがあり、0であるように暗黙的に設定され得る。いくつかの例では、スライスヘッダまたはSPSヘッダ中のフラグが、PCMモードをアクティブ化または非アクティブ化するために定義され得る。
【0139】
[0085]インター予測を使用する平面フラグのシグナリングにおけるコンテキスト選択。平面フラグ(is_planar_flag)をシグナリングするための3つのコンテキストがあり得る。インデックスの選択は、単に、方向インデックス(axisIdx)によって選択される。本開示の1つまたは複数の技法によれば、平面フラグを符号化するためのコンテキストは、参照ノードの平面モードを使用して拡張され得る。拡張の一例が以下のように説明され得る。
このプロセスへの入力は、以下の通りである。
【0140】
- 現在のノードの子を識別する変数childIdx、
- 平面に垂直な軸を識別する変数axisIdx、および
- ジオメトリツリーレベル内の現在のノードの位置(sN,tN,vN)。
このプロセスの出力は、変数ctxIdxである。ctxIdxの値は、(2*axisIdx+PlanarModeRef[axisIdx])に等しく設定され、さらなる処理は実施されない。
【0141】
[0086]この例では、PlanarModeRef[axisIdx]は、参照ノードがaxisIdx方向において平面であるかどうかを示す。
【0142】
[0087]インターモードを使用するシンタックス要素plane_positionのためのCtxIdx決定。GPCC DISでは、plane_positionを符号化するために使用されるコンテキストインデックスは、以下のように、axisIdx、近傍占有に基づく平面位置予測、同じバッファ行インデックスにおける最も近いすでにコーディングされたノードがisPlanar、planePosition、距離測度を含んでいると決定するためのバッファルックアップ、の関数である(セクション8.2.3.3)。
コンテキストインデックスctxIdxは、以下のように導出される。
【0143】
【数32】
【0144】
[0088]本開示の一例では、参照ブロックの占有および平面モードが、平面位置コーディングのコンテキストインデックスを決定するための追加のパラメータとして使用され得る。
【0145】
[0089]PlanarModeRefおよびRefPlaneを、参照ブロックにおける平面モードおよび平面位置とする。
【0146】
[0090]PlanarModeRef[axisIdx]が0である場合、RefPlane[axisIdx]は、-1に等しく設定される。
【0147】
[0091]一例では、RefPlane[axisIdx]は、prevPlaneを置換するために使用され得る。
【0148】
【数33】
【0149】
[0092]別の例では、ctxIdxは以下のように更新され得る。
【0150】
【数34】
【0151】
ここで、Nは、axisIdx、adjPlaneCtxInc、distCtxInc、およびprevPlaneのみを使用してサポートされたコンテキストの数である。現在のドラフトGPCC DISでは、Nは36である。
【0152】
[0093]別の例では、参照ブロックの占有および平面位置は、コンテキストを導出するための近傍占有を置換するために使用され得る。
【0153】
[0094]また別の例では、平面フラグのためのコンテキストインデックスは、以下のように、参照ブロックの方向インデックスおよび平面モードのみを使用して導出され得る。
【0154】
【数35】
【0155】
[0095]インター予測を使用する平面コーディングモードのためのコンテキストcontextAngularの導出プロセス。Mを、平面位置をコーディングするためにcontextAngularのためにサポートされるコンテキストの数とする。contextAngularがセクション3.3.5の場合のように導出された後に、それは、参照ブロックの平面モードおよび平面位置を使用して更新され得る。
【0156】
[0096]一例では、セクション3.3.5におけるcontextAngularは、以下のように更新され得る。
【0157】
[0097]いくつかの場合には、PlanarModeRef[axisIdx]が0である場合、RefPlane[axisIdx]は、-1に等しく設定される。contextAngular値は、以下のように割り当てられ得る。
次いで、角度コンテキストが2つの角度差から推論される。
【0158】
【数36】
【0159】
[0098]別の例では、PlanarModeRef[axisIdx]が0である場合、RefPlane[axisIdx]は、0に等しく設定される。
【0160】
[0099]contextAngular値は、以下のように割り当てられ得る。
次いで、角度コンテキストが2つの角度差から推論される。
【0161】
【数37】
【0162】
[0100]平面コーディングモードのためのインター予測と組み合わせられたコンテキストcontextAzimuthalSおよびcontextAzimuthalTの導出プロセス。
【0163】
[0101]8.2.4.3においてコンテキストcontextAzimuthalSおよびcontextAzimuthalTが導出された後に、それらは、インター参照ブロックの平面モードの使用とともに更新され得る。
【0164】
[0102]いくつかの場合には、PlanarModeRef[axisIdx]が0である場合、RefPlane[axisIdx]は、-1に等しく設定される。以下の修正が行われ得る。
【0165】
【数38】
【0166】
[0103]いくつかの場合には、PlanarModeRef[axisIdx]が0である場合、RefPlane[axisIdx]は、0に等しく設定される。以下の修正が行われ得る。
【0167】
【数39】
【0168】
[0104]インター予測を用いたコンテキスト占有コーディング。
【0169】
[0105]InterEMのための参照ソフトウェアでは、占有ビットのためのコンテキスト導出は、以下のように導出される。
【0170】
【数40】
【0171】
[0106]上記の計算では、インター予測(ctxInter)に関連付けられたコンテキストは、!!mappedPred、bitPred、bitPredStrongの和である。本開示の1つまたは複数の技法によれば、ctxIdxMapIdxは、次のように修正され得る。
【0172】
【数41】
【0173】
[0107]動きベースしきい値。しきい値が、動きベクトル/動きパラメータに基づいて定義され得、このしきい値は、本文書で開示される1つまたは複数の決定において使用され得る。
【0174】
[0108]たとえば、しきい値は、回転(たとえば、回転の角度)または並進(たとえば、並進の大きさ)に関連付けられた大きさ/パラメータに基づいて決定され得、回転に関連付けられた角度がxであり、並進の大きさがyである場合、しきい値は、xおよびyの関数として導出され得る(たとえば、線形結合a*x+b*y、ここで、aおよびbは固定値である)。
【0175】
[0109]他の代替形態では、各軸に関連付けられたしきい値は、別々に導出され得、たとえば、軸に関連付けられた並進は、軸に関連付けられたしきい値を導出するために使用され得る。
【0176】
[0110]しきい値に基づいて、1つまたは複数の決定が行われ得る。たとえば、ポイントがゼロ動きに関連付けられ、ゼロ動きに関連付けられたしきい値が、(PCMに関して上記で説明されたように)ノードの平面適格性を決定するために使用され得、ポイントに関連付けられた動きがより大きいとき、異なるしきい値が平面適格性決定のために使用され得る。
【0177】
[0111]別の例では、しきい値(または動きパラメータ)が特定の固定値を超えるとき、本文書で開示される1つまたは複数の決定が無効にされ得る。
【0178】
[0112]異なる決定のために、異なるしきい値が使用され得る。しきい値はまた、ビットストリーム中でシグナリングされ得る。
【0179】
[0113]本開示の様々な態様における例は、個別にまたは任意の組合せで使用され得る。
【0180】
[0114]図6は、本開示の1つまたは複数の技法とともに使用され得る例示的なレンジ測定システム700を示す概念図である。図6の例では、レンジ測定システム700は、照明器702とセンサー704とを含む。照明器702は、光706を放出し得る。いくつかの例では、照明器702は、1つまたは複数のレーザービームとして光706を放出し得る。光706は、赤外波長または可視光波長など、1つまたは複数の波長におけるものであり得る。他の例では、光706は、コヒーレントなレーザー光ではない。光706が、物体708など、物体に遭遇したとき、光706は、戻り光710をもたらす。戻り光710は、後方散乱光および/または反射光を含み得る。戻り光710は、センサー704上に物体708の画像712をもたらすように戻り光710を向けるレンズ711を通過し得る。センサー704は、画像712に基づいて信号714を生成する。画像712は、(たとえば、図6の画像712中のドットによって表される)ポイントのセットを備え得る。
【0181】
[0115]いくつかの例では、照明器702およびセンサー704は、照明器702およびセンサー704が環境の360度視野をキャプチャするように、スピニング構造物上に搭載され得る(たとえば、スピニングLIDARセンサー)。他の例では、レンジ測定システム700は、照明器702およびセンサー704が特定のレンジ内(たとえば、360度まで)の物体のレンジを検出することを可能にする1つまたは複数の光学構成要素(たとえば、ミラー、コリメータ、回折格子など)を含み得る。図6の例は、単一の照明器702およびセンサー704のみを示すが、レンジ測定システム700は、照明器およびセンサーの複数のセットを含み得る。
【0182】
[0116]いくつかの例では、照明器702は、構造化された光パターンを生成する。そのような例では、レンジ測定システム700は、構造化された光パターンのそれぞれの画像が形成される複数のセンサー704を含み得る。レンジ測定システム700は、構造化された光パターンが後方散乱する物体708までの距離を決定するために、構造化された光パターンの画像間の視差を使用し得る。構造化された光ベースのレンジ測定システムは、物体708がセンサー704に比較的近い(たとえば、0.2メートル~2メートル)とき、高レベルの精度(たとえば、サブミリメートルレンジの精度)を有し得る。この高レベルの精度は、モバイルデバイス(たとえば、モバイルフォン、タブレットコンピュータなど)のロック解除などの顔認識用途において、およびセキュリティ用途のために有用であり得る。
【0183】
[0117]いくつかの例では、レンジ測定システム700は、飛行時間(ToF)ベースのシステムである。レンジ測定システム700がToFベースのシステムであるいくつかの例では、照明器702は、光のパルスを生成する。言い換えれば、照明器702は、放出された光706の振幅を変調し得る。そのような例では、センサー704は、照明器702によって生成された光706のパルスからの戻り光710を検出する。レンジ測定システム700は、次いで、光706が放出され検出されたときと空気中の既知の光速との間の遅延に基づいて光706が後方散乱する物体708までの距離を決定し得る)。いくつかの例では、放出された光706の振幅を変調する代わりに(またはそれに加えて)、照明器702は、放出された光706の位相を変調し得る。そのような例では、センサー704は、物体708からの戻り光710の位相を検出し、光速を使用して、および照明器702が特定の位相で光706を生成したときとセンサー704が特定の位相で戻り光710を検出したときとの間の時間差に基づいて、物体708上のポイントまでの距離を決定し得る。
【0184】
[0118]他の例では、ポイントクラウドは、照明器702を使用することなく生成され得る。たとえば、いくつかの例では、レンジ測定システム700のセンサー704は、2つまたはそれ以上の光学カメラを含み得る。そのような例では、レンジ測定システム700は、物体708を含む環境のステレオ画像をキャプチャするために光学カメラを使用し得る。レンジ測定システム700は、ステレオ画像中のロケーション間の視差を計算し得るポイントクラウド生成器716を含み得る。レンジ測定システム700は、次いで、ステレオ画像に示されたロケーションまでの距離を決定するために視差を使用し得る。これらの距離から、ポイントクラウド生成器716は、ポイントクラウドを生成し得る。
【0185】
[0119]センサー704はまた、色および反射率情報など、物体708の他の属性を検出し得る。図6の例では、ポイントクラウド生成器716は、センサー704によって生成された信号714に基づいてポイントクラウドを生成し得る。レンジ測定システム700および/またはポイントクラウド生成器716は、データソース104(図1)の一部を形成し得る。したがって、レンジ測定システム700によって生成されたポイントクラウドは、本開示の技法のいずれかに従って符号化および/または復号され得る。
【0186】
[0120]図7は、本開示の1つまたは複数の技法が使用され得る例示的な車両ベースのシナリオを示す概念図である。図7の例では、車両800が、レンジ測定システム802を含む。レンジ測定システム802は、図107に関して説明される様式で実装され得る。図7の例には示されていないが、車両800はまた、データソース104(図1)などのデータソースと、G-PCCエンコーダ200(図1)などのG-PCCエンコーダとを含み得る。図7の例では、レンジ測定システム802は、歩行者806または道路内の他の物体から反射するレーザービーム804を放出する。車両800のデータソースは、レンジ測定システム802によって生成された信号に基づいてポイントクラウドを生成し得る。車両800のG-PCCエンコーダは、ジオメトリビットストリーム(図2)および属性ビットストリーム(図2)などのビットストリーム808を生成するために、ポイントクラウドを符号化し得る。ビットストリーム808は、G-PCCエンコーダによって取得された符号化されていないポイントクラウドよりもはるかに少ないビットを含み得る。
【0187】
[0121]車両800の出力インターフェース(たとえば、出力インターフェース108(図1))は、ビットストリーム808を1つまたは複数の他のデバイスに送信し得る。ビットストリーム808は、G-PCCエンコーダによって取得された符号化されていないポイントクラウドよりもはるかに少ないビットを含み得る。したがって、車両800は、符号化されていないポイントクラウドデータよりも迅速にビットストリーム808を他のデバイスに送信することが可能であり得る。さらに、ビットストリーム808は、より少ないデータ記憶容量を必要とし得る。
【0188】
[0122]図7の例では、車両800は、ビットストリーム808を別の車両810に送信し得る。車両810は、G-PCCデコーダ300(図1)などのG-PCCデコーダを含み得る。車両810のG-PCCデコーダは、ポイントクラウドを再構成するためにビットストリーム808を復号し得る。車両810は、様々な目的で、再構成されたポイントクラウドを使用し得る。たとえば、車両810は、歩行者806が車両800の前方の道路におり、したがって、たとえば、歩行者806が道路にいることを車両810の運転者が了解する前でも、減速を開始することを、再構成されたポイントクラウドに基づいて決定し得る。したがって、いくつかの例では、車両810は、再構成されたポイントクラウドに基づいて、自律ナビゲーション動作を実施し得る。
【0189】
[0123]追加または代替として、車両800は、ビットストリーム808をサーバシステム812に送信し得る。サーバシステム812は、様々な目的でビットストリーム808を使用し得る。たとえば、サーバシステム812は、ポイントクラウドの後続の再構成のためにビットストリーム808を記憶し得る。この例では、サーバシステム812は、自律運転システムを訓練するために他のデータ(たとえば、車両800によって生成された車両テレメトリデータ)とともにポイントクラウドを使用し得る。他の例では、サーバシステム812は、科学捜査的事故調査のための後続の再構成のためにビットストリーム808を記憶し得る。
【0190】
[0124]図8は、本開示の1つまたは複数の技法が使用され得る例示的なエクステンデッドリアリティシステムを示す概念図である。エクステンデッドリアリティ(XR:extended reality)は、拡張現実(AR)と、複合現実(MR)と、仮想現実(VR)とを含む技術の範囲をカバーするために使用される用語である。図8の例では、ユーザ900が、第1のロケーション902に位置する。ユーザ900は、XRヘッドセット904を装着する。XRヘッドセット904の代替として、ユーザ900は、モバイルデバイス(たとえば、モバイルフォン、タブレットコンピュータなど)を使用し得る。XRヘッドセット904は、ロケーション902における物体906上のポイントの位置を検出する、レンジ測定システムなどの深度検出センサーを含む。XRヘッドセット904のデータソースは、ロケーション902における物体906のポイントクラウド表現を生成するために、深度検出センサーによって生成された信号を使用し得る。XRヘッドセット904は、ビットストリーム908を生成するためにポイントクラウドを符号化するように構成されたG-PCCエンコーダ(たとえば、図1のG-PCCエンコーダ200)を含み得る。
【0191】
[0125]XRヘッドセット904は、第2のロケーション914においてユーザ912によって装着されたXRヘッドセット910に(たとえば、インターネットなどのネットワークを介して)ビットストリーム908を送信し得る。XRヘッドセット910は、ポイントクラウドを再構成するためにビットストリーム908を復号し得る。XRヘッドセット910は、ロケーション902における物体906を表すXR視覚化(たとえば、AR、MR、VR視覚化)を生成するためにポイントクラウドを使用し得る。したがって、いくつかの例では、XRヘッドセット910がVR視覚化を生成するときなど、ユーザ912は、ロケーション902の3D没入型体験を有し得る。いくつかの例では、XRヘッドセット910は、再構成されたポイントクラウドに基づいて仮想物体の位置を決定し得る。たとえば、XRヘッドセット910は、再構成されたポイントクラウドに基づいて、環境(たとえば、ロケーション902)が平坦な表面を含むと決定し、次いで、仮想物体(たとえば、漫画のキャラクタ)が平坦な表面上に配置されるべきであると決定し得る。XRヘッドセット910は、仮想物体が決定された位置にあるXR視覚化を生成し得る。たとえば、XRヘッドセット910は、平坦な表面に座っている漫画のキャラクタを示し得る。
【0192】
[0126]図9は、本開示の1つまたは複数の技法が使用され得る例示的なモバイルデバイスシステムを示す概念図である。図9の例では、モバイルフォンまたはタブレットコンピュータなどのモバイルデバイス1000(たとえば、ワイヤレス通信デバイス)は、モバイルデバイス1000の環境における物体1002上のポイントの位置を検出する、LIDARシステムなどのレンジ測定システムを含む。モバイルデバイス1000のデータソースは、物体1002のポイントクラウド表現を生成するために、深度検出センサーによって生成された信号を使用し得る。モバイルデバイス1000は、ビットストリーム1004を生成するためにポイントクラウドを符号化するように構成されたG-PCCエンコーダ(たとえば、図1のG-PCCエンコーダ200)を含み得る。図9の例では、モバイルデバイス1000は、サーバシステムまたは他のモバイルデバイスなどのリモートデバイス1006にビットストリームを送信し得る。リモートデバイス1006は、ポイントクラウドを再構成するためにビットストリーム1004を復号し得る。リモートデバイス1006は、様々な目的でポイントクラウドを使用し得る。たとえば、リモートデバイス1006は、モバイルデバイス1000の環境のマップを生成するためにポイントクラウドを使用し得る。たとえば、リモートデバイス1006は、再構成されたポイントクラウドに基づいて建物の内部のマップを生成し得る。別の例では、リモートデバイス1006は、ポイントクラウドに基づいて像(たとえば、コンピュータグラフィックス)を生成し得る。たとえば、リモートデバイス1006は、ポイントクラウドのポイントを多角形の頂点として使用し、ポイントの色属性を多角形に陰影を付けるための基礎として使用し得る。いくつかの例では、リモートデバイス1006は、顔認識または他のセキュリティ用途のために再構成されたポイントクラウドを使用し得る。
【0193】
[0127]図10Aおよび図10Bは、ビンnにおけるこのプロセスの例を示す。図10Aの例201では、あるコンテキスト状態(σ)を与えられれば、ビンnにおけるレンジは、LPS(pσ)の確率によって与えられるRangeMPSとRangeLPSとを含む。例201は、ビンnの値がMPSに等しいときのビンn+1におけるレンジの更新を示す。この例では、低は同じままであるが、ビンn+1におけるレンジの値は、ビンnにおけるRangeMPSの値に低減される。図10Bの例203は、ビンnの値がMPSに等しくない(すなわち、LPSに等しい)ときのビンn+1におけるレンジの更新を示す。この例では、低は、ビンnにおけるRangeLPSのより低いレンジ値に動かされる。さらに、ビンn+1におけるレンジの値は、ビンnにおけるRangeLPSの値に低減される。
【0194】
[0128]いくつかの例では、レンジは9ビットで表され、低は10ビットで表され得る。レンジ値および低値を十分な精度で維持するための再正規化プロセスがある。レンジが256よりも小さいときはいつでも、再正規化が行われる。したがって、レンジは、再正規化の後、常に256に等しいかまたはそれよりも大きい。レンジの値と低の値とに応じて、BACは、ビットストリームに「0」または「1」を出力するか、または将来の出力のために保持するために(BO:未解決ビット(bits-outstanding)と呼ばれる)内部変数を更新する。図11は、レンジに応じたBAC出力の例を示す。たとえば、レンジおよび低が、あるしきい値(たとえば、512)を上回るとき、ビットストリームに「1」が出力される。レンジおよび低が、あるしきい値(たとえば、512)を下回るとき、ビットストリームに「0」が出力される。レンジおよび下側が、あるしきい値間にあるとき、ビットストリームに何も出力されない。代わりに、BO値が増分され、次のビンが符号化される。
【0195】
[0129]上記で説明されたように、算術コーディング方法は、高い圧縮効率を提供するために使用され得る。これは、最初に、2値化と呼ばれるプロセスを使用して非バイナリシンタックス要素をバイナリ表現(たとえば、0、1)に変換することによって達成され得る。得られた変換されたエントリは、ビンまたはビンストリングと呼ばれる。これらのビンまたはビンストリングは、次いで、算術コーディングプロセスに供給される。図11は、例示的なコンテキスト適応型バイナリ算術コーディング(CABAC)符号化段を示す。例示的なCABAC符号化段は、図2のG-PCCエンコーダ200の算術符号化ユニット214および/または算術符号化ユニット226によってなど、G-PCCエンコーダにおいて実装され得る。
【0196】
[0130]G-PCCのいくつかの例では、コンテキスト適応型バイナリ算術コーディング(CABAC)は、2値化プロセスを通してビンを生成するために使用され得る。各コーディングされたビン値について、適切なコンテキストモデルが選択される。これらのコンテキストモデルは、ビン確率値に基づいて各ビン値を出力ビットに符号化するために使用される。CABACエンジンは、ビンが0または1と同程度の確率があるとき、コンテキストモデル化およびビン符号化をバイパスする。これは、以下で説明されるバイパスコーディング段である。そうでない場合、適切なコンテキストモデルが、ビン値が符号化されるときに指定され、ビン値の確率に基づいてモデル化する。コンテキストは、エンコーダがより多くのビンを符号化するにつれて、適応される。最後に、コンテキストコーディングされたビン値または生ビットストリームが、デコーダに送信されるかまたはさもなければ提供される。
【0197】
[0131]図12は、本開示の技法による、CABACを実施するように構成され得る例示的な算術符号化ユニット214のブロック図である。シンタックス要素1180が算術符号化ユニット214に入力される。シンタックス要素がすでにバイナリ値シンタックス要素(たとえば、フラグ、または0および1の値のみを有する他のシンタックス要素)である場合、2値化のステップはスキップされ得る。シンタックス要素が非バイナリ値シンタックス要素(たとえば、1または0以外の値を有し得るシンタックス要素)である場合、非バイナリ値シンタックス要素はバイナライザ1200によって2値化される。バイナライザ1200は、バイナリ決定のシーケンスへの非バイナリ値シンタックス要素のマッピングを実施する。これらのバイナリ決定は、しばしば「ビン」と呼ばれる。たとえば、変換係数レベルでは、レベルの値は連続するビンに分けられ得、各ビンは、係数レベルの絶対値がある値よりも大きいか否かを示す。たとえば、(有意性フラグと呼ばれることがある)ビン0は、変換係数レベルの絶対値が0よりも大きいか否かを示す。ビン1は、変換係数レベルの絶対値が1よりも大きいか否かを示す、などである。各非バイナリ値シンタックス要素について、一意のマッピングが作成され得る。
【0198】
[0132]バイナライザ1200によって生成された各ビンは、算術符号化ユニット214のバイナリ算術コーディング側に供給される。すなわち、非バイナリ値シンタックス要素の所定のセットについて、各ビンタイプ(たとえば、ビン0)が次のビンタイプ(たとえば、ビン1)の前にコーディングされる。コーディングは、通常モードまたはバイパスモードのいずれかで実施され得る。バイパスモードでは、バイパス符号化エンジン1260が、固定確率モデルを使用して、たとえば、ゴロム-ライスまたは指数ゴロムコーディングを使用して、算術コーディングを実施する。バイパスモードは、概して、より予測可能なシンタックス要素のために使用される。
【0199】
[0133]通常モードでのコーディングは、CABACを実施することを伴う。通常モードCABACは、ビンの値の確率が、前にコーディングされたビンの値を与えられれば予測可能である場合に、ビン値をコーディングするためのものである。ビンがLPSである確率がコンテキストモデラ1220によって決定される。コンテキストモデラ1220は、ビン値とコンテキストのための確率状態(たとえば、LPSの値と、LPSが発生する確率とを含む確率状態σ)とを出力する。コンテキストは、一連のビンのための初期コンテキストであり得るか、または前にコーディングされたビンのコーディングされた値に基づいて決定され得る。コンテキストの識別情報が、変数ctxIncの値(前のコンテキストに適用すべき増分を表すctxIncの値など、コンテキスト増分)に基づいて表され、および/または決定され得る。上記で説明されたように、コンテキストモデラ1220は、受信されたビンがMPSであったのかLPSであったのか否かに基づいて状態を更新し得る。コンテキストおよび確率状態σがコンテキストモデラ1220によって決定された後、通常符号化エンジン1240はビン値に対してBACを実施する。
【0200】
[0134]図13は、本開示の技法による、CABACを実施するように構成され得る例示的な算術復号ユニット302のブロック図である。図13の算術復号ユニット302は、図12で説明された算術符号化ユニット214の様式とは逆の様式でCABACを実施する。ビットストリーム2180からのコーディングされたビットが算術復号ユニット302に入力される。コーディングされたビットは、それらが通常モードを使用してエントロピーコーディングされたのか、バイパスモードを使用してエントロピーコーディングされたのかに基づいて、コンテキストモデラ2200またはバイパス復号エンジン2220のいずれかに供給される。コーディングされたビットがバイパスモードでコーディングされた場合、バイパス復号エンジンは、たとえば、バイナリ値シンタックス要素または非バイナリシンタックス要素のビンを取り出すために、ゴロム-ライスまたは指数ゴロム復号を使用することになる。
【0201】
[0135]コーディングされたビットが通常モードでコーディングされた場合、コンテキストモデラ2200はコーディングされたビットのための確率モデルを決定し得、通常復号エンジン2240は、非バイナリ値シンタックス要素のビン(または、バイナリ値の場合、シンタックス要素自体)を生成するために、コーディングされたビットを復号し得る。コンテキストおよび確率状態σがコンテキストモデラ2200によって決定された後に、通常復号エンジン2240は、ビン値を復号するためにBACを実施する。言い換えれば、通常復号エンジン2240は、コンテキストの確率状態を決定し、前にコーディングされたビンと現在のレンジとに基づいてビン値を復号し得る。ビンを復号した後に、コンテキストモデラ2200は、ウィンドウサイズと復号されたビンの値とに基づいてコンテキストの確率状態を更新し得る。
【0202】
[0136]図14は、本開示の1つまたは複数の態様による、ポイントクラウドのポイントを予測する例示的な技法を示す流れ図である。図14の技法は、図2のG-PCCエンコーダ200など、G-PCCコーダによって実施され得る。しかしながら、図3のG-PCCデコーダ300など、他のデバイスが図14の技法を実施し得る。
【0203】
[0137]G-PCCエンコーダ200は、ポイントクラウドの参照ブロックの平面情報を取得し得る(1402)。たとえば、G-PCCエンコーダ200の算術符号化ユニット214は、参照ブロックが特定の方向において平面モードを使用してコーディングされるかどうかを決定し得る(たとえば、参照ブロック/ノードがaxisIdx方向において平面であるかどうかを示し得る、PlanarModeRef[axisIdx])。
【0204】
[0138]G-PCCエンコーダ200は、参照ブロックの平面情報に基づいて、コンテキストを決定し得る(1404)。たとえば、算術コーディングユニット214は、参照ブロックの平面情報に基づいてコンテキストインデックス(ctxIdx)を決定し得る。一例として、算術コーディングユニット214は、ctxIdxを(2*axisIdx+PlanarModeRef[axisIdx])として決定し得る。
【0205】
[0139]G-PCCエンコーダ200は、コンテキストに基づいて、現在のノードが平面モードを使用してコーディングされるかどうかを示すシンタックス要素をコンテキスト適応型コーディングし得る(1406)。たとえば、算術符号化ユニット214は、ctxIdxに基づいて現在のノードのためのis_planar_flagシンタックス要素のコンテキスト適応型バイナリ算術コーディング(CABAC)を実施し得る。上述のように、1に等しいis_planar_flagシンタックス要素は、現在のノードの子の位置が、axisIdx番目の軸に直角な単一の平面を形成することを示し得る。0に等しいis_planar_flag[axisIdx]は、存在するとき、現在のノードの子の位置が、axisIdx番目の軸に直角な両方の平面を占有することを示し得る。
【0206】
[0140]G-PCCエンコーダ200は、現在のノードが平面モードを使用してコーディングされることに基づいて、平面モードを使用して現在のノードをコーディングし得る(1408)。たとえば、G-PCCエンコーダ200は、単一の平面を形成するものとして現在のノードの子をコーディングし得る。
【0207】
[0141]いくつかの例では、現在のノードが平面モードを使用してコーディングされる場合、算術コーディングユニット214は、参照平面に基づいて第2のコンテキストを決定し、第2のコンテキストに基づいて、現在のノードのための平面を示すシンタックス要素をコンテキスト適応型コーディングし得る。現在のノードのための平面を示すシンタックス要素は、plane_positionシンタックス要素であり得る。いくつかの例では、参照平面に基づいて第2のコンテキストを決定するために、算術コーディングユニット214は、以下の式、すなわち、ctxIdx=(12×axisIdx+4×adjPlaneCtxInc+2×distCtxInc+prevPlane+3)+(RefPlane[axisIdx]+1)×Nに従ってコンテキストインデックスを決定し得、ここにおいて、ctxIdxはコンテキストインデックスであり、axisIdxは軸インデックスであり、adjPlaneCtxIncは、調整された平面コンテキスト増分であり、distCtxIncは距離コンテキスト増分であり、prevPlaneは前の平面であり、RefPlane[axisIdx]は参照平面である。
【0208】
[0142]いくつかの例では、算術コーディングユニット214は、参照平面に基づいて、現在のノードのための角度コンテキストを決定し、角度コンテキストに基づいて、現在のノードのための平面を決定し得る。平面モードを使用して現在のノードをコーディングするために、G-PCCエンコーダ200は、平面に基づいて現在のノードをコーディングし得る。
【0209】
[0143]いくつかの例では、算術コーディングユニット214は、参照平面に基づいて、現在のノードのための方位角コンテキストを決定し、方位角コンテキストに基づいて、現在のノードのための平面を決定し得る。平面モードを使用して現在のノードをコーディングするために、G-PCCエンコーダ200は、平面に基づいて現在のノードをコーディングし得る。いくつかの例では、方位角コンテキストを決定するために、算術コーディングユニット214は、以下の式、すなわち、contextAzimuthal=contextAnglePhi+8×(RefPlane[axisIdx]+1)に従って方位角コンテキストを決定し得、ここにおいて、contextAzimuthalは方位角コンテキストであり、contextAnglePhiは、方位角コンテキストを導出するために使用される中間値であり、RefPlane[axisIdx]は参照平面である。複数の方位角コンテキストが、contextAzimuthalSとcontextAzimuthalTとを含む、contextAnglePhiに基づいて導出され得る。
【0210】
[0144]いくつかの例では、現在のノードは、平面コピーモード(PCM)を使用して選択的にコーディングされ得る。たとえば、G-PCCエンコーダ200は、参照ノードから現在のノードについて平面情報をコピーすべきかどうかを決定し得る。G-PCCエンコーダ200は、現在のノードがPCMを使用してコーディングされるか否かをシグナリングし得る。たとえば、算術コーディングユニット214は、現在のノードが平面コピーモードを使用してコーディングされるかどうかを示す、バイナリフラグ(たとえば、PCM_flag)など、シンタックス要素をコーディングし得る。現在のノードが平面コピーモードを使用してコーディングされる場合、G-PCCデコーダ300は、参照ノードから現在のノードの平面情報をコピーし得る。たとえば、G-PCCデコーダ300は、現在のノードの平面位置として参照ノードの平面位置を利用し得る。同様に、現在のノードが平面コピーモードを使用してコーディングされない場合、G-PCCエンコーダ200は、ビットストリームから現在のノードのための平面情報を符号化し得る(およびG-PCCデコーダ300がそれを復号し得る)。このようにして、PCMは、コーディング効率を改善し得る。
【0211】
[0145]以下の番号付けされた条項は、本開示の1つまたは複数の態様を示し得る。
【0212】
[0146]条項1A. ポイントクラウドデータをコーディングする方法であって、方法が、ポイントクラウドデータの参照ブロックの平面情報を取得することと、取得された平面情報に基づいて、ポイントクラウドデータの現在のブロックをコーディングすることとを備える、方法。
【0213】
[0147]条項2A. ポイントクラウドデータの現在のブロックをコーディングすることは、現在のブロックの現在の方向について、参照ブロックが現在の方向において平面モードを使用してコーディングされるかどうかに少なくとも部分的に基づいて平面レートを決定することを備える、条項1Aに記載の方法。
【0214】
[0148]条項3A. ポイントクラウドデータの現在のブロックをコーディングすることは、参照ブロックが平面であるかどうかに基づいて、現在のブロックが平面適格であるかどうかを決定することを備える、条項1Aに記載の方法。
【0215】
[0149]条項4A. コーディングされたビットストリームにおいて、現在のブロックと参照ブロックとがすべての方向において同じ平面モードを共有するかどうかを示す値を有するシンタックス要素をコーディングすることをさらに備える、条項1Aに記載の方法。
【0216】
[0150]条項5A. コーディングされたビットストリームにおいて、現在のブロックと参照ブロックとが同じ平面位置インデックスを共有するかどうかを示す値を有するシンタックス要素をコーディングすることをさらに備える、条項1Aに記載の方法。
【0217】
[0151]条項5A. ポイントクラウドデータの現在のブロックをコーディングすることは、参照ブロックが平面であるかどうかに基づいて、現在のブロックの平面フラグのコンテキスト適応型コーディングのためのコンテキストを決定することを備える、条項1Aに記載の方法。
【0218】
[0152]条項6A. ポイントクラウドデータの現在のブロックをコーディングすることが、参照ブロックの平面位置の平面モードに基づいて、現在のブロックのための角度コンテキストを決定することを備える、条項1Aに記載の方法。
【0219】
[0153]条項7A. ポイントクラウドを処理するためのデバイスであって、デバイスが、条項1Aから6Aのいずれかに記載の方法を実施するための1つまたは複数の手段を備える、デバイス。
【0220】
[0154]条項8A. 1つまたは複数の手段が、回路中に実装された1つまたは複数のプロセッサを備える、条項7Aに記載のデバイス。
【0221】
[0155]条項9A. ポイントクラウドを表すデータを記憶するためのメモリをさらに備える、条項7Aまたは8Aのいずれかに記載のデバイス。
【0222】
[0156]条項10A. デバイスがデコーダを備える、条項7Aから9Aのいずれかに記載のデバイス。
【0223】
[0157]条項11A. デバイスがエンコーダを備える、条項7Aから10Aのいずれかに記載のデバイス。
【0224】
[0158]条項12A. ポイントクラウドを生成するためのデバイスをさらに備える、条項7Aから11Aのいずれかに記載のデバイス。
【0225】
[0159]条項13A. ポイントクラウドに基づいて像を提示するためのディスプレイをさらに備える、条項7Aから12Aのいずれかに記載のデバイス。
【0226】
[0160]条項14A. 命令を記憶したコンピュータ可読記憶媒体であって、命令が、実行されたとき、1つまたは複数のプロセッサに、条項1Aから6Aのいずれかに記載の方法を実施させる、コンピュータ可読記憶媒体。
【0227】
[0161]例に応じて、本明細書で説明された技法のうちのいずれかのいくつかの行為またはイベントは、異なるシーケンスで実施され得、追加、マージ、または完全に除外され得る(たとえば、すべての説明された行為またはイベントが、技法の実践のために必要であるとは限らない)ことを認識されたい。その上、いくつかの例では、行為またはイベントは、連続的にではなく、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通して同時に実施され得る。
【0228】
[0162]1つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され、ハードウェアベース処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応する、コンピュータ可読記憶媒体を含み得るか、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含み得る。このようにして、コンピュータ可読媒体は、概して、(1)非一時的である有形コンピュータ可読記憶媒体、あるいは(2)信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明された技法の実装のための命令、コードおよび/またはデータ構造を取り出すために、1つまたは複数のコンピュータまたは1つまたは複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であり得る。コンピュータプログラム製品はコンピュータ可読媒体を含み得る。
【0229】
[0163]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM(登録商標)、CD-ROMまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは、命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用されるディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)およびBlu-rayディスク(disc)を含み、ここで、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザーで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲に含まれるべきである。
【0230】
[0164]命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、あるいは他の等価な集積またはディスクリート論理回路など、1つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用される「プロセッサ」および「処理回路」という用語は、上記の構造、または本明細書で説明された技法の実装に好適な任意の他の構造のいずれかを指し得る。さらに、いくつかの態様では、本明細書で説明された機能は、符号化および復号のために構成された専用ハードウェアおよび/またはソフトウェアモジュール内に提供されるか、あるいは複合コーデックに組み込まれ得る。また、本技法は、1つまたは複数の回路または論理要素で十分に実装され得る。
【0231】
[0165]本開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置で実装され得る。本開示では、開示される技法を実施するように構成されたデバイスの機能的態様を強調するために、様々な構成要素、モジュール、またはユニットが説明されたが、それらの構成要素、モジュール、またはユニットは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上記で説明されたように、様々なユニットが、好適なソフトウェアおよび/またはファームウェアとともに、上記で説明された1つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作可能なハードウェアユニットの集合によって提供され得る。
【0232】
[0166]様々な例が説明された。これらおよび他の例は以下の特許請求の範囲内に入る。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10A
図10B
図11
図12
図13
図14
【国際調査報告】