JP7267447B2 - 点群コーディングのためのパッチデータユニットのコーディングおよび復号 - Google Patents

点群コーディングのためのパッチデータユニットのコーディングおよび復号 Download PDF

Info

Publication number
JP7267447B2
JP7267447B2 JP2021555263A JP2021555263A JP7267447B2 JP 7267447 B2 JP7267447 B2 JP 7267447B2 JP 2021555263 A JP2021555263 A JP 2021555263A JP 2021555263 A JP2021555263 A JP 2021555263A JP 7267447 B2 JP7267447 B2 JP 7267447B2
Authority
JP
Japan
Prior art keywords
patch
type
patches
index
data unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2021555263A
Other languages
English (en)
Other versions
JP2022525599A (ja
Inventor
ヴラディスラフ・ザハルチェンコ
ジエンレ・チェン
カンイン・ツァイ
Original Assignee
ホアウェイ・テクノロジーズ・カンパニー・リミテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ホアウェイ・テクノロジーズ・カンパニー・リミテッド filed Critical ホアウェイ・テクノロジーズ・カンパニー・リミテッド
Publication of JP2022525599A publication Critical patent/JP2022525599A/ja
Priority to JP2023068788A priority Critical patent/JP2023089230A/ja
Application granted granted Critical
Publication of JP7267447B2 publication Critical patent/JP7267447B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00Image coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/003D [Three Dimensional] image rendering
    • G06T15/08Volume rendering
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00Image coding
    • G06T9/001Model-based coding, e.g. wire frame
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103Selection of coding mode or of prediction mode
    • H04N19/105Selection of the reference unit for prediction within a chosen coding or prediction mode, e.g. adaptive choice of position and number of pixels used for prediction
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/20Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using video object coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • H04N19/537Motion estimation other than block-based
    • H04N19/54Motion estimation other than block-based using feature points or meshes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2207/00Indexing scheme for image analysis or image enhancement
    • G06T2207/10Image acquisition modality
    • G06T2207/10028Range image; Depth image; 3D point clouds

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Graphics (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

関連出願の相互参照
本特許出願は、参照により本明細書に組み込まれる、Vladyslav Zakharchenkoらによる、「Patch Data Unit Coding and Decoding for Point-Cloud Coding」と題する、2019年3月12日に出願された米国仮特許出願第62/817,391号の利益を主張する。
本開示は、一般に、点群コーディングに関し、具体的には、点群コーディングのための高レベル構文に関する。
点群は、娯楽産業、インテリジェント自動車ナビゲーション、地理空間調査、現実世界の物体の3次元(3D)モデル化、視覚化などを含む多種多様な用途に採用されている。点群の不均一なサンプリング幾何形状を考慮すると、そのようなデータの記憶および送信のためのコンパクトな表現が有用である。他の3D表現と比較して、不規則な点群はより一般的であり、より広範囲のセンサおよびデータ取得戦略に適用可能である。たとえば、仮想現実世界における3D表現またはテレプレゼンス環境におけるリモートレンダリングを実行するとき、仮想図形およびリアルタイム命令のレンダリングは、高密度点群データセットとして処理される。
第1の態様は、デコーダによって実施される点群コーディング(PCC)の方法に関する。方法は、デコーダの受信機により、符号化されたパッチ情報データを受信するステップと、デコーダのプロセッサにより、符号化されたパッチ情報データに対応するパッチを取得するステップであって、パッチがパッチタイプ(patch_mode)を有する、ステップと、プロセッサにより、パッチ用のパッチタイプが最後のパッチタイプであるかどうかを判定するステップと、プロセッサにより、パッチタイプが最後のパッチタイプであるとき、符号化されたパッチ情報データに対応する復元プロセスを終了するステップとを含む。
このコーディング方法を使用することにより、パッチフレームデータユニット内のパッチの柔軟な順序付けが可能になる。すなわち、異なるパッチモード(たとえば、インター、イントラ、PCMなど)有するパッチは、任意の順序でパッチフレームデータユニットに含まれてもよい。加えて、さらなるパッチがパッチフレームデータユニットに追加されてもよい。追加されたパッチは、パッチフレームデータユニットの最後、または任意のランダムなパッチインデックス位置のいずれかに追加されてもよい。コーディング技法はまた、スキップパッチデータユニットタイプ(spdu)が使用されることを可能にする。スキップパッチデータユニットは、現在のパッチデータユニット用のパッチデータユニット要素と基準パッチデータユニット用のパッチデータユニット要素が同一であるか、または容認可能な許容範囲内であるときに、現在のパッチ用のすべてのパラメータが基準パッチから継承されてもよいことを示す。コーディング技法はまた、本明細書に記載されたパッチタイプのシグナリングがパッチフレームデータユニット内のパッチのリスト全体を表すのに十分なので、一致したパッチの数を示す構文要素がシグナリングから削除されることを可能にする。さらに、コーディング技法は、パッチフレームデータユニット内のパッチの総数(たとえば、パッチフレームデータユニットのサイズ)をシグナリングする必要性を排除し、そのプロセスを特別な終端パッチタイプと置き換える。さらに、コーディング技法は、通常、パッチフレームデータユニットの最後に配置されているパルスコード化変調(PCM)パッチがPCMパッチタイプ指示と置き換えられることを可能にする。複数のPCMパッチも許容される。したがって、点群コーディングにおけるコーダ/デコーダ(別名、「コーデック」)は、現在のコーデックに対して改善される(たとえば、V-PCCにおいてパッチを符号化および復号するプロセス)。実際問題として、改善された点群コーディングプロセスは、コーディング効率を向上させることができ、これにより、点群が送信、受信、および/または閲覧されるときにより良いユーザ体験をユーザに提供する。
第2の態様は、デコーダによって実施される点群コーディング(PCC)の方法に関する。方法は、デコーダの受信機により、符号化されたパッチ情報データを受信するステップと、デコーダのプロセッサにより、符号化されたパッチ情報データに対応するパッチを取得するステップであって、パッチがパッチタイプ(patch_mode)を有する、ステップと、プロセッサにより、パッチ用のパッチタイプがスキップパッチタイプであるかどうかを判定するステップと、プロセッサにより、パッチタイプがスキップパッチタイプであるとき、パッチに対応する基準パッチインデックス(spdu_patch_index)を復号するステップと、プロセッサにより、パッチに対応する基準フレームインデックス([refFrmIdx])、およびパッチタイプがスキップパッチタイプであるときに復号された基準パッチインデックスに基づいて、パッチ用の基準インデックス(refIdx)を決定するステップと、プロセッサにより、パッチタイプがスキップパッチタイプであるときに決定された基準インデックスに基づいて、パッチの立体表現を復元するステップとを含む。
このコーディング方法を使用することにより、パッチフレームデータユニット内のパッチの柔軟な順序付けが可能になる。すなわち、異なるパッチモード(たとえば、インター、イントラ、PCMなど)有するパッチは、任意の順序でパッチフレームデータユニットに含まれてもよい。加えて、さらなるパッチがパッチフレームデータユニットに追加されてもよい。追加されたパッチは、パッチフレームデータユニットの最後、または任意のランダムなパッチインデックス位置のいずれかに追加されてもよい。コーディング技法はまた、スキップパッチデータユニットタイプ(spdu)が使用されることを可能にする。スキップパッチデータユニットは、現在のパッチデータユニット用のパッチデータユニット要素と基準パッチデータユニット用のパッチデータユニット要素が同一であるか、または容認可能な許容範囲内であるときに、現在のパッチ用のすべてのパラメータが基準パッチから継承されてもよいことを示す。コーディング技法はまた、本明細書に記載されたパッチタイプのシグナリングがパッチフレームデータユニット内のパッチのリスト全体を表すのに十分なので、一致したパッチの数を示す構文要素がシグナリングから削除されることを可能にする。さらに、コーディング技法は、パッチフレームデータユニット内のパッチの総数(たとえば、パッチフレームデータユニットのサイズ)をシグナリングする必要性を排除し、そのプロセスを特別な終端パッチタイプと置き換える。さらに、コーディング技法は、通常、パッチフレームデータユニットの最後に配置されているパルスコード化変調(PCM)パッチがPCMパッチタイプ指示と置き換えられることを可能にする。複数のPCMパッチも許容される。したがって、点群コーディングにおけるコーダ/デコーダ(別名、「コーデック」)は、現在のコーデックに対して改善される(たとえば、V-PCCにおいてパッチを符号化および復号するプロセス)。実際問題として、改善された点群コーディングプロセスは、コーディング効率を向上させることができ、これにより、点群が送信、受信、および/または閲覧されるときにより良いユーザ体験をユーザに提供する。
第2の態様自体による方法の第1の実装形態では、方法は、パッチ用のパッチタイプがイントラパッチタイプであると判定するステップと、パッチに対応するフレームインデックス([frmIdx])およびデクリメントされたパッチインデックスに基づいて、パッチ用の基準インデックス(refIdx)を決定するステップと、パッチに対応する2次元(2D)成分およびパッチに対応する3次元(3D)成分を使用してパッチを復号するステップと、復号されたパッチに基づいて立体表現を復元するステップとをさらに備える。
第2の態様自体または第2の態様の任意の前述の実装形態による方法の第2の実装形態では、方法は、パッチ用のパッチタイプがインターパッチタイプであると判定するステップと、パッチに対応する第2の基準パッチインデックス(dpdu_patch_index)を復号するステップと、パッチに対応する基準フレームインデックス([refFrmIdx])および復号された第2の基準パッチインデックスに基づいて、パッチ用の基準インデックス(refIdx)を決定するステップと、パッチに対応する2次元(2D)成分およびパッチに対応する3次元(3D)成分を使用してパッチを復号するステップと、復号されたパッチに基づいて立体表現を復元するステップとをさらに備える。
第2の態様自体または第2の態様の任意の前述の実装形態による方法の第3の実装形態では、方法は、パッチ用のパッチタイプがパルスコード変調(PCM)パッチタイプであると判定するステップと、パッチに対応するフレームインデックス([frmIdx])およびデクリメントされたパッチインデックスに基づいて、パッチ用の基準インデックス(refIdx)を決定するステップと、パッチに対応する独立したポイント用の2次元(2D)成分およびパッチに対応する独立したポイント用の3次元(3D)成分を使用してパッチを復号するステップと、復号されたパッチに基づいて立体表現を復元するステップとをさらに備える。
第2の態様自体または第2の態様の任意の前述の実装形態による方法の第4の実装形態では、方法は、符号化されたパッチ情報データに対応する入力を受信するステップであって、入力が、patch_mode、パッチインデックス、基準インデックス、フレームインデックス、および基準フレームインデックスのうちの1つまたは複数を備える、ステップをさらに備える。
第2の態様自体または第2の態様の任意の前述の実装形態による方法の第4の実装形態では、方法は、復元された立体表現に基づいて生成された画像を電子デバイスのディスプレイに表示するステップをさらに備える。
第3の態様は、デコーダによって実施される点群コーディング(PCC)の方法に関する。方法は、デコーダの受信機により、符号化されたパッチ情報データを受信するステップと、デコーダのプロセッサにより、符号化されたパッチ情報データに対応するパッチを取得するステップであって、パッチがパッチタイプ(patch_mode)を有する、ステップと、プロセッサにより、パッチ用のパッチタイプがスキップパッチタイプであるかどうかを判定するステップと、プロセッサにより、パッチタイプがスキップパッチタイプであるとき、パッチに対応する基準パッチインデックス(spdu_patch_index)を復号するステップと、プロセッサにより、パッチに対応する基準フレームインデックス([refFrmIdx])、およびパッチタイプがスキップパッチタイプであるときに復号された基準パッチインデックスに基づいて、パッチ用の基準インデックス(refIdx)を決定するステップと、プロセッサにより、パッチタイプがスキップパッチタイプであるときに決定された基準インデックスに基づいて、パッチの立体表現を復元するステップと、プロセッサにより、より多くのパッチ利用可能フラグが第1の値を有するか、または第2の値を有するかを判定するステップと、より多くのパッチ利用可能フラグが第1の値を有するとき、復元された立体表現をデコーダのメモリに記憶するステップと、プロセッサにより、より多くのパッチ利用可能フラグが第2の値を有するとき、符号化されたパッチ情報の復元プロセスを終了するステップとを含む。
このコーディング方法を使用することにより、パッチフレームデータユニット内のパッチの柔軟な順序付けが可能になる。すなわち、異なるパッチモード(たとえば、インター、イントラ、PCMなど)有するパッチは、任意の順序でパッチフレームデータユニットに含まれてもよい。加えて、さらなるパッチがパッチフレームデータユニットに追加されてもよい。追加されたパッチは、パッチフレームデータユニットの最後、または任意のランダムなパッチインデックス位置のいずれかに追加されてもよい。コーディング技法はまた、スキップパッチデータユニットタイプ(spdu)が使用されることを可能にする。スキップパッチデータユニットは、現在のパッチデータユニット用のパッチデータユニット要素と基準パッチデータユニット用のパッチデータユニット要素が同一であるか、または容認可能な許容範囲内であるときに、現在のパッチ用のすべてのパラメータが基準パッチから継承されてもよいことを示す。コーディング技法はまた、本明細書に記載されたパッチタイプのシグナリングがパッチフレームデータユニット内のパッチのリスト全体を表すのに十分なので、一致したパッチの数を示す構文要素がシグナリングから削除されることを可能にする。さらに、コーディング技法は、パッチフレームデータユニット内のパッチの総数(たとえば、パッチフレームデータユニットのサイズ)をシグナリングする必要性を排除し、そのプロセスを特別な終端パッチタイプと置き換える。さらに、コーディング技法は、通常、パッチフレームデータユニットの最後に配置されているパルスコード化変調(PCM)パッチがPCMパッチタイプ指示と置き換えられることを可能にする。複数のPCMパッチも許容される。したがって、点群コーディングにおけるコーダ/デコーダ(別名、「コーデック」)は、現在のコーデックに対して改善される(たとえば、V-PCCにおいてパッチを符号化および復号するプロセス)。実際問題として、改善された点群コーディングプロセスは、コーディング効率を向上させることができ、これにより、点群が送信、受信、および/または閲覧されるときにより良いユーザ体験をユーザに提供する。
第3の態様自体による方法の第1の実装形態では、方法は、パッチ用のパッチタイプがイントラパッチタイプであると判定するステップと、パッチに対応するフレームインデックス([frmIdx])およびデクリメントされたパッチインデックスに基づいて、パッチ用の基準インデックス(refIdx)を決定するステップと、パッチに対応する2次元(2D)成分およびパッチに対応する3次元(3D)成分を使用してパッチを復号するステップと、復号されたパッチに基づいて立体表現を復元するステップとをさらに備える。
第3の態様自体による方法の第2の実装形態では、方法は、パッチ用のパッチタイプがインターパッチタイプであると判定するステップと、パッチに対応する第2の基準パッチインデックス(dpdu_patch_index)を復号するステップと、パッチに対応する基準フレームインデックス([refFrmIdx])および復号された第2の基準パッチインデックスに基づいて、パッチ用の基準インデックス(refIdx)を決定するステップと、パッチに対応する2次元(2D)成分およびパッチに対応する3次元(3D)成分を使用してパッチを復号するステップと、復号されたパッチに基づいて立体表現を復元するステップとをさらに備える。
第3の態様自体による方法の第3の実装形態では、方法は、パッチ用のパッチタイプがパルスコード変調(PCM)パッチタイプであると判定するステップと、パッチに対応するフレームインデックス([frmIdx])およびデクリメントされたパッチインデックスに基づいて、パッチ用の基準インデックス(refIdx)を決定するステップと、パッチに対応する独立したポイント用の2次元(2D)成分およびパッチに対応する独立したポイント用の3次元(3D)成分を使用してパッチを復号するステップと、復号されたパッチに基づいて立体表現を復元するステップとをさらに備える。
第3の態様自体による方法の第4の実装形態では、方法は、符号化されたパッチ情報データに対応する入力を受信するステップであって、入力が、patch_mode、パッチインデックス、基準インデックス、フレームインデックス、および基準フレームインデックスのうちの1つまたは複数を備える、ステップをさらに備える。
第3の態様自体による方法の第5の実装形態では、方法は、復元された立体表現に基づいて生成された画像を電子デバイスのディスプレイに表示するステップをさらに備える。
第4の態様は、エンコーダによって実施される点群コーディング(PCC)の方法に関する。方法は、エンコーダの受信機により、複数のパッチの各々についてパッチタイプ(pdfu_patch_mode)を識別するパッチフレームデータユニット(pfdu)を取得するステップと、エンコーダのプロセッサにより、複数のパッチからのパッチ用のパッチタイプが最後のパッチタイプであるかどうかを判定するステップと、エンコーダのプロセッサにより、パッチタイプが最後のパッチタイプでないとき、パッチ用のパッチ情報データを符号化するステップであって、パッチ情報データがパッチ用のパッチタイプを含む、ステップと、エンコーダのプロセッサにより、パッチタイプが最後のパッチタイプに設定されたとき、パッチ用のパッチ情報データを符号化するステップであって、パッチ情報データがパッチ用の最後のパッチタイプを含む、ステップとを含む。
このコーディング方法を使用することにより、パッチフレームデータユニット内のパッチの柔軟な順序付けが可能になる。すなわち、異なるパッチモード(たとえば、インター、イントラ、PCMなど)有するパッチは、任意の順序でパッチフレームデータユニットに含まれてもよい。加えて、さらなるパッチがパッチフレームデータユニットに追加されてもよい。追加されたパッチは、パッチフレームデータユニットの最後、または任意のランダムなパッチインデックス位置のいずれかに追加されてもよい。コーディング技法はまた、スキップパッチデータユニットタイプ(spdu)が使用されることを可能にする。スキップパッチデータユニットは、現在のパッチデータユニット用のパッチデータユニット要素と基準パッチデータユニット用のパッチデータユニット要素が同一であるか、または容認可能な許容範囲内であるときに、現在のパッチ用のすべてのパラメータが基準パッチから継承されてもよいことを示す。コーディング技法はまた、本明細書に記載されたパッチタイプのシグナリングがパッチフレームデータユニット内のパッチのリスト全体を表すのに十分なので、一致したパッチの数を示す構文要素がシグナリングから削除されることを可能にする。さらに、コーディング技法は、パッチフレームデータユニット内のパッチの総数(たとえば、パッチフレームデータユニットのサイズ)をシグナリングする必要性を排除し、そのプロセスを特別な終端パッチタイプと置き換える。さらに、コーディング技法は、通常、パッチフレームデータユニットの最後に配置されているパルスコード化変調(PCM)パッチがPCMパッチタイプ指示と置き換えられることを可能にする。複数のPCMパッチも許容される。したがって、点群コーディングにおけるコーダ/デコーダ(別名、「コーデック」)は、現在のコーデックに対して改善される(たとえば、V-PCCにおいてパッチを符号化および復号するプロセス)。実際問題として、改善された点群コーディングプロセスは、コーディング効率を向上させることができ、これにより、点群が送信、受信、および/または閲覧されるときにより良いユーザ体験をユーザに提供する。
第4の態様自体による方法の第1の実装形態では、パッチタイプは、スキップパッチタイプ、インターパッチタイプ、イントラパッチタイプ、およびパルスコード変調(PCM)パッチタイプのうちの1つである。
第4の態様自体による方法の第2の実装形態では、パッチフレームデータユニットは、フレームインデックス(frmIdx)、パッチに対応する2次元(2D)成分、およびパッチに対応する3次元(3D)成分を含む。
第4の態様自体による方法の第3の実装形態では、パッチ情報データは、フレームインデックス、パッチに対応する2次元(2D)成分、およびパッチに対応する3次元(3D)成分を含む。
第4の態様自体による方法の第4の実装形態では、方法は、パッチタイプが最後のパッチタイプであるかどうかを判定するステップ、および複数のパッチからのパッチのうちの1つが最後のパッチタイプを有すると判定されるまで、複数のパッチからの後続のパッチ用のパッチ情報データを符号化するステップを反復するステップをさらに備える。
第4の態様自体による方法の第5の実装形態では、方法は、パッチ情報データのすべてが符号化された後にバイトアラインメントを実行するステップをさらに備える。
第4の態様自体による方法の第6の実装形態では、方法は、パッチ情報データのすべてが符号化された後に圧縮されたパッチフレームデータユニットを生成するステップをさらに備える。
第4の態様自体による方法の第7の実装形態では、方法は、デコーダに向けて送信するために圧縮されたパッチフレームデータユニットをエンコーダのメモリに記憶するステップをさらに備える。
第5の態様は、エンコーダによって実施される点群コーディング(PCC)の方法に関する。方法は、エンコーダの受信機により、複数のパッチの各々についてパッチフレームデータユニット(pfdu)を取得するステップと、エンコーダのプロセッサにより、複数のパッチの各々に最後のパッチフラグを追加するステップと、エンコーダのプロセッサにより、最後のパッチフラグの値に基づいて、複数のパッチからのパッチ用のパッチタイプが最後のパッチタイプであるかどうかを判定するステップと、エンコーダのプロセッサにより、パッチタイプが最後のパッチタイプでないとき、パッチ用のパッチ情報データを符号化するステップであって、パッチ情報データがパッチ用のパッチタイプおよび最後のパッチフラグを含む、ステップとを含む。
このコーディング方法を使用することにより、パッチフレームデータユニット内のパッチの柔軟な順序付けが可能になる。すなわち、異なるパッチモード(たとえば、インター、イントラ、PCMなど)有するパッチは、任意の順序でパッチフレームデータユニットに含まれてもよい。加えて、さらなるパッチがパッチフレームデータユニットに追加されてもよい。追加されたパッチは、パッチフレームデータユニットの最後、または任意のランダムなパッチインデックス位置のいずれかに追加されてもよい。コーディング技法はまた、スキップパッチデータユニットタイプ(spdu)が使用されることを可能にする。スキップパッチデータユニットは、現在のパッチデータユニット用のパッチデータユニット要素と基準パッチデータユニット用のパッチデータユニット要素が同一であるか、または容認可能な許容範囲内であるときに、現在のパッチ用のすべてのパラメータが基準パッチから継承されてもよいことを示す。コーディング技法はまた、本明細書に記載されたパッチタイプのシグナリングがパッチフレームデータユニット内のパッチのリスト全体を表すのに十分なので、一致したパッチの数を示す構文要素がシグナリングから削除されることを可能にする。さらに、コーディング技法は、パッチフレームデータユニット内のパッチの総数(たとえば、パッチフレームデータユニットのサイズ)をシグナリングする必要性を排除し、そのプロセスを特別な終端パッチタイプと置き換える。さらに、コーディング技法は、通常、パッチフレームデータユニットの最後に配置されているパルスコード化変調(PCM)パッチがPCMパッチタイプ指示と置き換えられることを可能にする。複数のPCMパッチも許容される。したがって、点群コーディングにおけるコーダ/デコーダ(別名、「コーデック」)は、現在のコーデックに対して改善される(たとえば、V-PCCにおいてパッチを符号化および復号するプロセス)。実際問題として、改善された点群コーディングプロセスは、コーディング効率を向上させることができ、これにより、点群が送信、受信、および/または閲覧されるときにより良いユーザ体験をユーザに提供する。
第5の態様自体による方法の第1の実装形態では、パッチタイプは、スキップパッチタイプ、インターパッチタイプ、イントラパッチタイプ、およびパルスコード変調(PCM)パッチタイプのうちの1つである。
第5の態様自体による方法の第2の実装形態では、パッチフレームデータユニットは、フレームインデックス(frmIdx)、パッチに対応する2次元(2D)成分、およびパッチに対応する3次元(3D)成分を含む。
第5の態様自体による方法の第3の実装形態では、パッチ情報データは、フレームインデックス、パッチに対応する2次元(2D)成分、およびパッチに対応する3次元(3D)成分を含む。
第5の態様自体による方法の第4の実装形態では、方法は、最後のパッチフラグの値に基づいて、パッチタイプが最後のパッチタイプであるかどうかを判定するステップ、および最後のパッチフラグの値に基づいて、複数のパッチからのパッチのうちの1つが最後のパッチタイプを有すると判定されるまで、複数のパッチからの後続のパッチ用のパッチ情報データを符号化するステップを反復するステップをさらに備える。
第5の態様自体による方法の第5の実装形態では、方法は、最後のパッチフラグの値に基づいて、複数のパッチからのパッチのうちの1つが最後のパッチタイプを有すると判定された後にバイトアラインメントを実行するステップをさらに備える。
第5の態様自体による方法の第6の実装形態では、方法は、パッチ情報データのすべてが符号化された後に圧縮されたパッチフレームデータユニットを生成するステップをさらに備える。
第5の態様自体による方法の第7の実装形態では、方法は、デコーダに向けて送信するために圧縮されたパッチフレームデータユニットをエンコーダのメモリに記憶するステップをさらに備える。
第6の態様は、符号化されたパッチ情報を受信するように構成された受信機と、受信機に結合されたメモリであって、メモリが命令を記憶する、メモリと、メモリに結合されたプロセッサであって、プロセッサが、符号化されたパッチ情報データに対応するパッチを取得し、パッチがパッチタイプ(patch_mode)を有し、パッチ用のパッチタイプが最後のパッチタイプであるかどうかを判定し、パッチタイプが最後のパッチタイプであるとき、符号化されたパッチ情報データに対応する復元プロセスを終了することを復号デバイスに行わせる命令を実行するように構成される、プロセッサとを含む、復号デバイスに関する。
このコーディング方法を使用することにより、パッチフレームデータユニット内のパッチの柔軟な順序付けが可能になる。すなわち、異なるパッチモード(たとえば、インター、イントラ、PCMなど)有するパッチは、任意の順序でパッチフレームデータユニットに含まれてもよい。加えて、さらなるパッチがパッチフレームデータユニットに追加されてもよい。追加されたパッチは、パッチフレームデータユニットの最後、または任意のランダムなパッチインデックス位置のいずれかに追加されてもよい。コーディング技法はまた、スキップパッチデータユニットタイプ(spdu)が使用されることを可能にする。スキップパッチデータユニットは、現在のパッチデータユニット用のパッチデータユニット要素と基準パッチデータユニット用のパッチデータユニット要素が同一であるか、または容認可能な許容範囲内であるときに、現在のパッチ用のすべてのパラメータが基準パッチから継承されてもよいことを示す。コーディング技法はまた、本明細書に記載されたパッチタイプのシグナリングがパッチフレームデータユニット内のパッチのリスト全体を表すのに十分なので、一致したパッチの数を示す構文要素がシグナリングから削除されることを可能にする。さらに、コーディング技法は、パッチフレームデータユニット内のパッチの総数(たとえば、パッチフレームデータユニットのサイズ)をシグナリングする必要性を排除し、そのプロセスを特別な終端パッチタイプと置き換える。さらに、コーディング技法は、通常、パッチフレームデータユニットの最後に配置されているパルスコード化変調(PCM)パッチがPCMパッチタイプ指示と置き換えられることを可能にする。複数のPCMパッチも許容される。したがって、点群コーディングにおけるコーダ/デコーダ(別名、「コーデック」)は、現在のコーデックに対して改善される(たとえば、V-PCCにおいてパッチを符号化および復号するプロセス)。実際問題として、改善された点群コーディングプロセスは、コーディング効率を向上させることができ、これにより、点群が送信、受信、および/または閲覧されるときにより良いユーザ体験をユーザに提供する。
第7の態様は、符号化されたパッチ情報を受信するように構成された受信機と、受信機に結合されたメモリであって、メモリが命令を記憶する、メモリと、メモリに結合されたプロセッサであって、プロセッサが、符号化されたパッチ情報データに対応するパッチを取得し、パッチがパッチタイプ(patch_mode)を有し、パッチ用のパッチタイプがスキップパッチタイプであるかどうかを判定し、パッチタイプがスキップパッチタイプであるとき、パッチに対応する基準パッチインデックス(spdu_patch_index)を復号し、パッチに対応する基準フレームインデックス([refFrmIdx])、およびパッチタイプがスキップパッチタイプであるときに復号された基準パッチインデックスに基づいて、パッチ用の基準インデックス(refIdx)を決定し、パッチタイプがスキップパッチタイプであるときに決定された基準インデックスに基づいて、パッチの立体表現を復元することを復号デバイスに行わせる命令を実行するように構成される、プロセッサとを含む、復号デバイスに関する。
この復号デバイスを使用することにより、パッチバッファ内のパッチの柔軟な順序付けが可能になる。すなわち、異なるパッチモード(たとえば、インター、イントラ、PCMなど)有するパッチは、任意の順序でパッチバッファに含まれてもよい。コーディング技法はまた、スキップパッチデータユニットタイプ(spdu)が使用されることを可能にする。スキップパッチデータユニットは、現在のパッチデータユニット用のパッチデータユニット要素と基準パッチデータユニット用のパッチデータユニット要素が同一であるか、または完全に一致するときに、現在のパッチ用のすべてのパラメータが基準パッチから継承されてもよいことを示す。コーディング技法はまた、本明細書に記載されたパッチタイプのシグナリングがパッチバッファ内のパッチのリスト全体を表すのに十分なので、一致したパッチのリストを示す構文要素がシグナリングから削除されることを可能にする。加えて、コーディング技法は、パッチバッファ内のパッチの総数(たとえば、パッチバッファのサイズ)をシグナリングし、そのプロセスを特別な終端パッチタイプと置き換える必要性を排除する。さらに、コーディング技法は、通常、パッチバッファの最後に配置されているパルスコード化変調(PCM)パッチがPCMパッチタイプ指示と置き換えられることを可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(別名、「コーデック」)は、現在のコーデックに対して改善される(たとえば、V-PCCにおいてパッチを符号化および復号するプロセス)。実際問題として、改善されたビデオコーディングプロセスは、コーディング効率を向上させることができ、これにより、ビデオが送信、受信、および/または閲覧されるときにより良いユーザ体験をユーザに提供する。
第8の態様は、符号化されたパッチ情報を受信するように構成された受信機と、受信機に結合されたメモリであって、メモリが命令を記憶する、メモリと、メモリに結合されたプロセッサであって、プロセッサが、符号化されたパッチ情報データに対応するパッチを取得し、パッチがパッチタイプ(patch_mode)を有し、パッチ用のパッチタイプがスキップパッチタイプであるかどうかを判定し、パッチタイプがスキップパッチタイプであるとき、パッチに対応する基準パッチインデックス(spdu_patch_index)を復号し、パッチに対応する基準フレームインデックス([refFrmIdx])、およびパッチタイプがスキップパッチタイプであるときに復号された基準パッチインデックスに基づいて、パッチ用の基準インデックス(refIdx)を決定し、パッチタイプがスキップパッチタイプであるときに決定された基準インデックスに基づいて、パッチの立体表現を復元し、より多くのパッチ利用可能フラグが第1の値を有するか、または第2の値を有するかを判定し、より多くのパッチ利用可能フラグが第1の値を有するとき、復元された立体表現をメモリに記憶し、より多くのパッチ利用可能フラグが第2の値を有するとき、符号化されたパッチ情報の復元プロセスを終了することを復号デバイスに行わせる命令を実行するように構成される、プロセッサとを含む、復号デバイスに関する。
このコーディング方法を使用することにより、パッチフレームデータユニット内のパッチの柔軟な順序付けが可能になる。すなわち、異なるパッチモード(たとえば、インター、イントラ、PCMなど)有するパッチは、任意の順序でパッチフレームデータユニットに含まれてもよい。加えて、さらなるパッチがパッチフレームデータユニットに追加されてもよい。追加されたパッチは、パッチフレームデータユニットの最後、または任意のランダムなパッチインデックス位置のいずれかに追加されてもよい。コーディング技法はまた、スキップパッチデータユニットタイプ(spdu)が使用されることを可能にする。スキップパッチデータユニットは、現在のパッチデータユニット用のパッチデータユニット要素と基準パッチデータユニット用のパッチデータユニット要素が同一であるか、または容認可能な許容範囲内であるときに、現在のパッチ用のすべてのパラメータが基準パッチから継承されてもよいことを示す。コーディング技法はまた、本明細書に記載されたパッチタイプのシグナリングがパッチフレームデータユニット内のパッチのリスト全体を表すのに十分なので、一致したパッチの数を示す構文要素がシグナリングから削除されることを可能にする。さらに、コーディング技法は、パッチフレームデータユニット内のパッチの総数(たとえば、パッチフレームデータユニットのサイズ)をシグナリングする必要性を排除し、そのプロセスを特別な終端パッチタイプと置き換える。さらに、コーディング技法は、通常、パッチフレームデータユニットの最後に配置されているパルスコード化変調(PCM)パッチがPCMパッチタイプ指示と置き換えられることを可能にする。複数のPCMパッチも許容される。したがって、点群コーディングにおけるコーダ/デコーダ(別名、「コーデック」)は、現在のコーデックに対して改善される(たとえば、V-PCCにおいてパッチを符号化および復号するプロセス)。実際問題として、改善された点群コーディングプロセスは、コーディング効率を向上させることができ、これにより、点群が送信、受信、および/または閲覧されるときにより良いユーザ体験をユーザに提供する。
第6、第7、および第8の態様自体による復号デバイスの第1の実装形態では、復号デバイスは、復元された立体表現に基づいて生成された画像を表示するように構成されたディスプレイをさらに備える。
第9の態様は、3次元(3D)画像を受信するように構成された受信機と、受信機に結合されたメモリであって、メモリが命令を記憶する、メモリと、メモリに結合されたプロセッサであって、プロセッサが、複数のパッチの各々についてパッチタイプ(pdfu_patch_mode)を識別するパッチフレームデータユニット(pfdu)を取得し、複数のパッチからのパッチ用のパッチタイプが最後のパッチタイプであるかどうかを判定し、パッチタイプが最後のパッチタイプでないとき、パッチ用のパッチ情報データを符号化し、パッチ情報データがパッチ用のパッチタイプを含み、パッチタイプが最後のパッチタイプに設定されたとき、パッチ用のパッチ情報データを符号化し、パッチ情報データがパッチ用の最後のパッチタイプを含む、ことを符号化デバイスに行わせる命令を実施するように構成される、プロセッサとを備える、符号化デバイスに関する。
このコーディング方法を使用することにより、パッチフレームデータユニット内のパッチの柔軟な順序付けが可能になる。すなわち、異なるパッチモード(たとえば、インター、イントラ、PCMなど)有するパッチは、任意の順序でパッチフレームデータユニットに含まれてもよい。加えて、さらなるパッチがパッチフレームデータユニットに追加されてもよい。追加されたパッチは、パッチフレームデータユニットの最後、または任意のランダムなパッチインデックス位置のいずれかに追加されてもよい。コーディング技法はまた、スキップパッチデータユニットタイプ(spdu)が使用されることを可能にする。スキップパッチデータユニットは、現在のパッチデータユニット用のパッチデータユニット要素と基準パッチデータユニット用のパッチデータユニット要素が同一であるか、または容認可能な許容範囲内であるときに、現在のパッチ用のすべてのパラメータが基準パッチから継承されてもよいことを示す。コーディング技法はまた、本明細書に記載されたパッチタイプのシグナリングがパッチフレームデータユニット内のパッチのリスト全体を表すのに十分なので、一致したパッチの数を示す構文要素がシグナリングから削除されることを可能にする。さらに、コーディング技法は、パッチフレームデータユニット内のパッチの総数(たとえば、パッチフレームデータユニットのサイズ)をシグナリングする必要性を排除し、そのプロセスを特別な終端パッチタイプと置き換える。さらに、コーディング技法は、通常、パッチフレームデータユニットの最後に配置されているパルスコード化変調(PCM)パッチがPCMパッチタイプ指示と置き換えられることを可能にする。複数のPCMパッチも許容される。したがって、点群コーディングにおけるコーダ/デコーダ(別名、「コーデック」)は、現在のコーデックに対して改善される(たとえば、V-PCCにおいてパッチを符号化および復号するプロセス)。実際問題として、改善された点群コーディングプロセスは、コーディング効率を向上させることができ、これにより、点群が送信、受信、および/または閲覧されるときにより良いユーザ体験をユーザに提供する。
第10の態様は、3次元(3D)画像を受信するように構成された受信機と、受信機に結合されたメモリであって、メモリが命令を記憶する、メモリと、メモリに結合されたプロセッサであって、プロセッサが、複数のパッチの各々についてパッチフレームデータユニット(pfdu)を取得し、複数のパッチの各々に最後のパッチフラグを追加し、最後のパッチフラグの値に基づいて、複数のパッチからのパッチ用のパッチタイプが最後のパッチタイプであるかどうかを判定し、パッチタイプが最後のパッチタイプでないとき、パッチ用のパッチ情報データを符号化し、パッチ情報データがパッチ用のパッチタイプおよび最後のパッチフラグを含む、ことを符号化デバイスに行わせる命令を実施するように構成される、プロセッサとを備える、符号化デバイスに関する。
このコーディング方法を使用することにより、パッチフレームデータユニット内のパッチの柔軟な順序付けが可能になる。すなわち、異なるパッチモード(たとえば、インター、イントラ、PCMなど)有するパッチは、任意の順序でパッチフレームデータユニットに含まれてもよい。加えて、さらなるパッチがパッチフレームデータユニットに追加されてもよい。追加されたパッチは、パッチフレームデータユニットの最後、または任意のランダムなパッチインデックス位置のいずれかに追加されてもよい。コーディング技法はまた、スキップパッチデータユニットタイプ(spdu)が使用されることを可能にする。スキップパッチデータユニットは、現在のパッチデータユニット用のパッチデータユニット要素と基準パッチデータユニット用のパッチデータユニット要素が同一であるか、または容認可能な許容範囲内であるときに、現在のパッチ用のすべてのパラメータが基準パッチから継承されてもよいことを示す。コーディング技法はまた、本明細書に記載されたパッチタイプのシグナリングがパッチフレームデータユニット内のパッチのリスト全体を表すのに十分なので、一致したパッチの数を示す構文要素がシグナリングから削除されることを可能にする。さらに、コーディング技法は、パッチフレームデータユニット内のパッチの総数(たとえば、パッチフレームデータユニットのサイズ)をシグナリングする必要性を排除し、そのプロセスを特別な終端パッチタイプと置き換える。さらに、コーディング技法は、通常、パッチフレームデータユニットの最後に配置されているパルスコード化変調(PCM)パッチがPCMパッチタイプ指示と置き換えられることを可能にする。複数のPCMパッチも許容される。したがって、点群コーディングにおけるコーダ/デコーダ(別名、「コーデック」)は、現在のコーデックに対して改善される(たとえば、V-PCCにおいてパッチを符号化および復号するプロセス)。実際問題として、改善された点群コーディングプロセスは、コーディング効率を向上させることができ、これにより、点群が送信、受信、および/または閲覧されるときにより良いユーザ体験をユーザに提供する。
第9および第10の態様自体による符号化デバイスの第1の実装形態では、符号化デバイスは、プロセッサに結合された送信機をさらに備え、送信機は、デコーダに向けて符号化されたパッチ情報データを有するビットストリームを送信するように構成される。
第11の態様は、符号化するために立体ピクチャを受信するか、または復号するためにビットストリームを受信するように構成された受信機と、受信機に結合された送信機であって、送信機が、ビットストリームをデコーダに送信するか、または復号された立体ピクチャを復元するように構成された復元デバイスに復号された立体画像を送信するように構成される、送信機と、受信機または送信機の少なくとも1つに結合されたメモリであって、メモリが命令を記憶するように構成される、メモリと、メモリに結合されたプロセッサであって、プロセッサが、メモリに記憶された命令を実行して、本明細書に開示された方法のいずれかを実行するように構成される、プロセッサとを備える、コーディング装置に関する。
このコーディング方法を使用することにより、パッチフレームデータユニット内のパッチの柔軟な順序付けが可能になる。すなわち、異なるパッチモード(たとえば、インター、イントラ、PCMなど)有するパッチは、任意の順序でパッチフレームデータユニットに含まれてもよい。加えて、さらなるパッチがパッチフレームデータユニットに追加されてもよい。追加されたパッチは、パッチフレームデータユニットの最後、または任意のランダムなパッチインデックス位置のいずれかに追加されてもよい。コーディング技法はまた、スキップパッチデータユニットタイプ(spdu)が使用されることを可能にする。スキップパッチデータユニットは、現在のパッチデータユニット用のパッチデータユニット要素と基準パッチデータユニット用のパッチデータユニット要素が同一であるか、または容認可能な許容範囲内であるときに、現在のパッチ用のすべてのパラメータが基準パッチから継承されてもよいことを示す。コーディング技法はまた、本明細書に記載されたパッチタイプのシグナリングがパッチフレームデータユニット内のパッチのリスト全体を表すのに十分なので、一致したパッチの数を示す構文要素がシグナリングから削除されることを可能にする。さらに、コーディング技法は、パッチフレームデータユニット内のパッチの総数(たとえば、パッチフレームデータユニットのサイズ)をシグナリングする必要性を排除し、そのプロセスを特別な終端パッチタイプと置き換える。さらに、コーディング技法は、通常、パッチフレームデータユニットの最後に配置されているパルスコード化変調(PCM)パッチがPCMパッチタイプ指示と置き換えられることを可能にする。複数のPCMパッチも許容される。したがって、点群コーディングにおけるコーダ/デコーダ(別名、「コーデック」)は、現在のコーデックに対して改善される(たとえば、V-PCCにおいてパッチを符号化および復号するプロセス)。実際問題として、改善された点群コーディングプロセスは、コーディング効率を向上させることができ、これにより、点群が送信、受信、および/または閲覧されるときにより良いユーザ体験をユーザに提供する。
第5の態様自体によるコーディング装置の第1の実装形態では、コーディング装置は、復元されたパッチに基づいて画像を表示するように構成されたディスプレイをさらに備える。
第12の態様は、エンコーダと、エンコーダと通信するデコーダとを備え、エンコーダまたはデコーダが、本明細書に記載された符号化デバイス、復号デバイス、またはコーディング装置を含む、システムに関する。
このコーディング方法を使用することにより、パッチフレームデータユニット内のパッチの柔軟な順序付けが可能になる。すなわち、異なるパッチモード(たとえば、インター、イントラ、PCMなど)有するパッチは、任意の順序でパッチフレームデータユニットに含まれてもよい。加えて、さらなるパッチがパッチフレームデータユニットに追加されてもよい。追加されたパッチは、パッチフレームデータユニットの最後、または任意のランダムなパッチインデックス位置のいずれかに追加されてもよい。コーディング技法はまた、スキップパッチデータユニットタイプ(spdu)が使用されることを可能にする。スキップパッチデータユニットは、現在のパッチデータユニット用のパッチデータユニット要素と基準パッチデータユニット用のパッチデータユニット要素が同一であるか、または容認可能な許容範囲内であるときに、現在のパッチ用のすべてのパラメータが基準パッチから継承されてもよいことを示す。コーディング技法はまた、本明細書に記載されたパッチタイプのシグナリングがパッチフレームデータユニット内のパッチのリスト全体を表すのに十分なので、一致したパッチの数を示す構文要素がシグナリングから削除されることを可能にする。さらに、コーディング技法は、パッチフレームデータユニット内のパッチの総数(たとえば、パッチフレームデータユニットのサイズ)をシグナリングする必要性を排除し、そのプロセスを特別な終端パッチタイプと置き換える。さらに、コーディング技法は、通常、パッチフレームデータユニットの最後に配置されているパルスコード化変調(PCM)パッチがPCMパッチタイプ指示と置き換えられることを可能にする。複数のPCMパッチも許容される。したがって、点群コーディングにおけるコーダ/デコーダ(別名、「コーデック」)は、現在のコーデックに対して改善される(たとえば、V-PCCにおいてパッチを符号化および復号するプロセス)。実際問題として、改善された点群コーディングプロセスは、コーディング効率を向上させることができ、これにより、点群が送信、受信、および/または閲覧されるときにより良いユーザ体験をユーザに提供する。
第13の態様は、符号化するために立体ピクチャを受信するか、または復号、復元、および投影するためにビットストリームを受信するように構成された受信手段と、受信手段に結合された送信手段であって、送信手段が、ビットストリームをデコーダに送信するか、または復号された画像を表示手段に送信するように構成される、送信手段と、受信手段または送信手段の少なくとも1つに結合された記憶手段であって、記憶手段が命令を記憶するように構成される、記憶手段と、記憶手段に結合された処理手段であって、処理手段が、記憶手段に記憶された命令を実行して、本明細書に開示された方法のいずれかを実行するように構成される、処理手段とを備える、コーディングのための手段に関する。
このコーディング方法を使用することにより、パッチフレームデータユニット内のパッチの柔軟な順序付けが可能になる。すなわち、異なるパッチモード(たとえば、インター、イントラ、PCMなど)有するパッチは、任意の順序でパッチフレームデータユニットに含まれてもよい。加えて、さらなるパッチがパッチフレームデータユニットに追加されてもよい。追加されたパッチは、パッチフレームデータユニットの最後、または任意のランダムなパッチインデックス位置のいずれかに追加されてもよい。コーディング技法はまた、スキップパッチデータユニットタイプ(spdu)が使用されることを可能にする。スキップパッチデータユニットは、現在のパッチデータユニット用のパッチデータユニット要素と基準パッチデータユニット用のパッチデータユニット要素が同一であるか、または容認可能な許容範囲内であるときに、現在のパッチ用のすべてのパラメータが基準パッチから継承されてもよいことを示す。コーディング技法はまた、本明細書に記載されたパッチタイプのシグナリングがパッチフレームデータユニット内のパッチのリスト全体を表すのに十分なので、一致したパッチの数を示す構文要素がシグナリングから削除されることを可能にする。さらに、コーディング技法は、パッチフレームデータユニット内のパッチの総数(たとえば、パッチフレームデータユニットのサイズ)をシグナリングする必要性を排除し、そのプロセスを特別な終端パッチタイプと置き換える。さらに、コーディング技法は、通常、パッチフレームデータユニットの最後に配置されているパルスコード化変調(PCM)パッチがPCMパッチタイプ指示と置き換えられることを可能にする。複数のPCMパッチも許容される。したがって、点群コーディングにおけるコーダ/デコーダ(別名、「コーデック」)は、現在のコーデックに対して改善される(たとえば、V-PCCにおいてパッチを符号化および復号するプロセス)。実際問題として、改善された点群コーディングプロセスは、コーディング効率を向上させることができ、これにより、点群が送信、受信、および/または閲覧されるときにより良いユーザ体験をユーザに提供する。
明確にするために、前述の実施形態のいずれか1つは、本開示の範囲内で新規の実施形態を作成するために他の前述の実施形態のいずれか1つまたは複数と組み合わされてもよい。
上記その他の特徴は、添付の図面および特許請求の範囲と併用される以下の発明を実施するための形態からより明確に理解されよう。
本開示のより完全な理解のために、ここで、添付の図面および発明を実施するための形態と併せて以下の簡単な説明を参照し、同様の参照番号は同様の部分を表す。
コンテキストモデル化技法を利用することができる例示的なコーディングシステムを示すブロック図である。 コンテキストモデル化技法を実装することができる例示的なエンコーダを示すブロック図である。 コンテキストモデル化技法を実装することができる例示的なデコーダを示すブロック図である。 各々が3次元(3D)の点群を含む点群フレームのシーケンスの図である。 2次元(2D)投影を生成するために境界ボックス上に投影された図5の3D点群のうちの1つの図である。 図5の境界ボックスからの2D投影に対応する占有マップの図である。 図5の境界ボックスからの2D投影に対応する幾何形状マップの図である。 図5の境界ボックスからの2D投影に対応する属性マップの図である。 ビデオベースの点群コーディング(V-PCC)ビットストリームの図である。 複数のフレーム用の点群シーケンスのコード化分解の図である。 図8の点群シーケンス内の点群フレームのうちの1つから抽出された単一のパッチデータユニットの図である。 図9の単一のパッチデータユニットに対応する占有マップの図である。 図9の単一のパッチデータユニットに対応する幾何形状マップの図である。 図9の単一のパッチデータユニットに対応する属性マップの図である。 2D境界ボックス内のパッチデータユニット用の2D成分の図である。 図11のパッチデータユニット用の3D成分の概略図である。 図11のパッチデータユニット用の3D成分のデータセット図である。 パッチフレームデータユニット符号化プロセスの一実施形態の図である。 最後のパッチフラグを使用するパッチフレームデータユニット符号化プロセスの一実施形態の図である。 パッチユニットタイプの説明を伴うパッチ情報データフレームの一実施形態の図である。 パッチフレームデータユニット復号プロセスの一実施形態の図である。 最後のパッチフラグを使用するパッチフレームデータユニット復号プロセスの一実施形態の図である。 デコーダによって実施される点群コーディング(PCC)の方法の一実施形態の図である。 デコーダによって実施されるPCCの方法の一実施形態の図である。 デコーダによって実施されるPCCの方法の一実施形態の図である。 エンコーダによって実施されるPCCの方法の一実施形態の図である。 エンコーダによって実施されるPCCの方法の一実施形態の図である。 コーディングデバイスの概略図である。 コーディングのための手段の一実施形態の概略図である。
1つまたは複数の実施形態の例示的な実装形態が以下に提供されるが、本開示のシステムおよび/または方法は、現在公知であるかまたは実在するかどうかにかかわらず、任意の数の技法を使用して実施されてもよいことが最初に理解されるべきである。本開示は、いかなる点でも、本明細書に例示および記載された例示的な設計および実装形態を含む、以下に例示される例示的な実装形態、図面、および技法に限定されるべきではなく、添付の特許請求の範囲およびそれらの均等物の全範囲内で修正されてもよい。
明細書および特許請求の範囲全体を通して、以下の用語は、文脈が明らかに別途指示しない限り、本明細書に明示的に関連する意味をもつ。基準パッチインデックス(たとえば、spdu_patch_index)は、[現在のパッチフレームデータユニット内の]現在のパッチデータユニットのインデックスpと[基準パッチフレームデータユニット内の]基準パッチデータユニットのインデックスとの間の差分を示す。基準インデックス(たとえば、refIdx)は、[復号されたパッチフレームデータユニットバッファ内の]前に復号されたパッチフレームデータユニット内の基準パッチデータユニットの実際のインデックスを示す。基準フレームインデックス(たとえば、refFrmIdx)は、[復号されたパッチフレームデータユニットバッファ内の]前に復号されたパッチフレームデータユニットのインデックスを示す。
ビデオコーディング規格には、国際電気通信連合電気通信標準化部門(ITU-T)H.261、国際標準化機構(ISO)/国際電気標準会議(IEC)動画専門家グループ(MPEG)-1パート2、ITU-T H.262またはISO/IEC MPEG-2パート2、ITU-T H.263、ISO/IEC MPEG-4パート2、ITU-T H.264またはISO/IEC MPEG-4パート10としても知られる高度ビデオコーディング(AVC)、およびITU-T H.265またはMPEG-Hパート2としても知られる高効率ビデオコーディング(HEVC)が含まれる。AVCは、スケーラブルビデオコーディング(SVC)、マルチビュービデオコーディング(MVC)、マルチビュービデオコーディングプラス深度(MVC+D)、および3D AVC(3D-AVC)などの拡張を含む。HEVCは、スケーラブルHEVC(SHVC)、マルチビューHEVC(MV-HEVC)、および3D HEVC(3D-HEVC)などの拡張を含む。
点群は、3D空間内のデータポイントの集合である。各データポイントは、位置(たとえば、X、Y、Z)、色(たとえば、R、G、BまたはY、U、V)、および場合によっては透明度、反射率、取得時間などの他の特性を決定するパラメータを含む。通常、クラウド内の各ポイントは、それに添えられた同じ数の属性を有する。点群は、リアルタイム3D没入型テレプレゼンス、双方向視差を用いたコンテンツ仮想現実(VR)ビューイング、3D自由視点スポーツ再生放送、地理情報システム、文化遺産、大規模3D動的マップに基づく自律ナビゲーション、および自動車アプリケーションなどの様々なアプリケーション内で使用されてもよい。
ISO/IEC動画専門家グループ(MPEG)は、実質的なコーディング効率およびネットワーク環境に対する堅牢性を有する可逆圧縮および不可逆圧縮された点群データのための点群コーディングに関する新しいコーデック規格の開発を2016年に開始した。このコーデック規格を使用すると、点群がコンピュータデータの形態として操作され、様々な記憶媒体に記憶され、既存および将来のネットワークを介して送受信され、既存および将来の放送チャネル上で配信されることが可能になる。
最近、点群コーディング(PCC)作業は、PCCカテゴリ1、PCCカテゴリ2、およびPCCカテゴリ3の3つのカテゴリに分類され、2つの別個の作業ドラフトが開発されており、1つはPCCカテゴリ2(PCC Cat2)向けであり、もう1つはPCCカテゴリ1および3(PCC Cat13)用である。MPEG出力文書N17534には、PCC Cat2に関する最新の作業ドラフト(WD)が含まれており、MPEG出力文書N17533には、PCC Cat13に関する最新のWDが含まれている。
PCC Cat2 WDにおけるPCC Cat2コーデックの設計の背後にある主な考え方は、点群データを異なるビデオシーケンスのセットとして圧縮することにより、既存のビデオコーデックを活用して動的点群の幾何形状およびテクスチャの情報を圧縮することである。詳細には、1つが点群データの幾何形状情報を表し、もう1つがテクスチャ情報を表す2つのビデオシーケンスが、ビデオコーデックを使用して生成および圧縮される。2つのビデオシーケンスを解釈するための追加のメタデータ、すなわち、占有マップおよび補助パッチ情報も、別々に生成および圧縮される。
残念ながら、PCCの既存の設計には欠点がある。たとえば、1つの時間インスタンス、すなわち、1つのアクセスユニット(AU)に関係するデータユニットは、復号順が連続していない。PCC Cat2 WDでは、AUごとのテクスチャ、幾何形状、補助情報、占有マップのデータユニットは、フレームのグループ単位でインターリーブされる。すなわち、グループ内のすべてのフレーム用の幾何形状データは一緒になっている。テクスチャデータなどについても同様であることが多い。PCC Cat13 WDでは、AUごとの幾何形状のデータユニットおよび一般属性は、PCCビットストリーム全体のレベルでインターリーブされる(たとえば、PCCビットストリーム全体と同じ長さを有するフレームのグループが1つしかないとき、PCC Cat2 WDと同じである)。1つのAUに属するデータユニットのインターリーブは、本質的に、アプリケーションシステム内のプレゼンテーション持続時間におけるフレームのグループの長さに少なくとも等しい巨大なエンドツーエンド遅延を引き起こす。
別の欠点は、ビットストリームフォーマットに関する。ビットストリームフォーマットは、0x0003のような開始コードパターンのエミュレーションを可能にし、したがって、開始コードエミュレーション防止が必要とされるMPEG-2トランスポートストリーム(TS)を介した送信には機能しない。PCC Cat2の場合、HEVCまたはAVCのいずれかが幾何形状成分およびテクスチャ成分のコーディングに使用されるとき、現在、group_of_frames_geometry_video_payload()およびgroup_of_frames_texture_video_payload()のみが、所定の位置で開始コードエミュレーション防止を有する。PCC Cat13の場合、開始コードエミュレーション防止は、ビットストリーム内のどこも適所ではない。
PCC Cat2 WDでは、幾何形状ビットストリームおよびテクスチャビットストリーム用のコーデック情報のいくつか(たとえば、コーデックのどのコーデック、プロファイル、レベルなど)は、構造group_of_frames_geometry_video_payload()およびgroup_of_frames_texture_video_payload()の複数のインスタンスに深く埋め込まれている。さらに、補助情報および占有マップ成分の復号、ならびに点群復元のための能力を示すプロファイルおよびレベルなどの情報のいくつかが欠落している。
点群コーディングに関連付けられた前述の問題のうちの1つまたは複数を解決する高レベル構文設計が提供される。以下でより詳細に説明されるように、本開示は、データユニットヘッダ(別名、PCCネットワークアクセス層(NAL)ヘッダ)内のタイプインジケータを利用して、PCC NALユニットのペイロード内のコンテンツのタイプを指定する。加えて、本開示は、フレームヘッダNALユニットのグループを利用して、フレームヘッダパラメータのグループを搬送する。フレームヘッダNALユニットのグループはまた、各々の幾何形状ビットストリームまたはテクスチャビットストリームのプロファイルおよびレベルをシグナリングするために使用されてもよい。
図1は、PCCビデオコーディング技法を利用することができる例示的なコーディングシステム10を示すブロック図である。図1に示されたように、コーディングシステム10は、宛先デバイス14によって後で復号される符号化ビデオデータを提供するソースデバイス12を含む。詳細には、ソースデバイス12は、コンピュータ可読媒体16を介して宛先デバイス14にビデオデータを提供することができる。ソースデバイス12および宛先デバイス14は、デスクトップコンピュータ、ノートブック(たとえば、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビ、カメラ、表示デバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範なデバイスのいずれかを備えてもよい。場合によっては、ソースデバイス12および宛先デバイス14は、ワイヤレス通信に対応していてもよい。
宛先デバイス14は、コンピュータ可読媒体16を介して、復号される符号化ビデオデータを受信することができる。コンピュータ可読媒体16は、ソースデバイス12から宛先デバイス14に符号化ビデオデータを移動させることが可能な任意のタイプの媒体またはデバイスを備えてもよい。一例では、コンピュータ可読媒体16は、ソースデバイス12が符号化ビデオデータをリアルタイムで宛先デバイス14に直接送信することを可能にする通信媒体を備えてもよい。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス14に送信されてもよい。通信媒体は、無線周波数(RF)スペクトルまたは1つもしくは複数の物理伝送線などの、任意のワイヤレスまたは有線の通信媒体を備えてもよい。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなどの、パケットベースネットワークの一部を形成することができる。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス12から宛先デバイス14への通信を容易にするのに有用であり得る任意の他の機器を含んでもよい。
いくつかの例では、符号化データは、出力インターフェース24からストレージデバイスに出力されてもよい。同様に、符号化データは、入力インターフェースによってストレージデバイスからアクセスされてもよい。ストレージデバイスは、ハードドライブ、Blu-ray(登録商標)ディスク、デジタルビデオディスク(DVD)、コンパクトディスク読取り専用メモリ(CD-ROM)、フラッシュメモリ、揮発性もしくは不揮発性メモリ、または符号化ビデオデータを記憶するための任意の他の適切なデジタル記憶媒体などの様々な、分散されるか、またはローカルにアクセスされるデータ記憶媒体のいずれかを含んでもよい。さらなる例では、ストレージデバイスは、ソースデバイス12によって生成された符号化ビデオを記憶することができるファイルサーバまたは別の中間ストレージデバイスに対応することができる。宛先デバイス14は、ストリーミングまたはダウンロードを介して、ストレージデバイスから記憶されたビデオデータにアクセスすることができる。ファイルサーバは、符号化ビデオデータを記憶し、その符号化ビデオデータを宛先デバイス14に送信することが可能な任意のタイプのサーバであってもよい。例示的なファイルサーバには、(たとえば、ウェブサイトのための)ウェブサーバ、ファイル転送プロトコル(FTP)サーバ、ネットワーク接続ストレージ(NAS)デバイス、またはローカルディスクドライブが含まれる。宛先デバイス14は、インターネット接続を含む任意の標準データ接続を介して符号化ビデオデータにアクセスすることができる。これには、ワイヤレスチャネル(たとえば、Wi-Fi接続)、有線接続(たとえば、デジタル加入者線(DSL)、ケーブルモデムなど)、またはファイルサーバに記憶された符号化ビデオデータへのアクセスに適した両方の組合せが含まれてもよい。ストレージデバイスからの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであってもよい。
本開示の技法は、必ずしもワイヤレスの用途または設定に限定されない。技法は、無線テレビ放送、ケーブルテレビ伝送、衛星テレビ伝送、ダイナミックアダプティブストリーミングオーバーHTTP(DASH)などのインターネットストリーミングビデオ伝送、データ記憶媒体上に符号化されたデジタルビデオ、データ記憶媒体上に記憶されたデジタルビデオの復号、または他のアプリケーションなどの、様々なマルチメディアアプリケーションのいずれかをサポートするビデオコーディングに適用されてもよい。いくつかの例では、コーディングシステム10は、単方向または双方向のビデオ伝送をサポートして、ビデオストリーミング、ビデオ再生、ビデオ放送、および/またはビデオ電話などのアプリケーションをサポートするように構成されてもよい。
図1の例では、ソースデバイス12は、立体画像を提供するように構成されたビデオソース18と、投影デバイス20と、ビデオエンコーダ22と、出力インターフェース24とを含む。宛先デバイス14は、入力インターフェース26と、ビデオデコーダ28と、復元デバイス30と、表示デバイス32とを含む。本開示によれば、ソースデバイス12のビデオエンコーダ22および/または宛先デバイス14のビデオデコーダ28は、ビデオコーディングのための技法を適用するように構成されてもよい。他の例では、ソースデバイスおよび宛先デバイスは、他の構成要素または構成を含んでもよい。たとえば、ソースデバイス12は、外部カメラなどの外部ビデオソースからビデオデータを受信することができる。同様に、宛先デバイス14は、一体化された表示デバイスを含むのではなく、外部表示デバイスとインターフェースすることができる。
図1の例示されたコーディングシステム10は、一例にすぎない。ビデオコーディングのための技法は、任意のデジタルビデオ符号化および/または復号デバイスによって実行されてもよい。本開示の技法は、一般に、コーディングデバイスによって実行されるが、技法はまた、通常、「コーデック」と呼ばれるビデオエンコーダ/デコーダによって実行されてもよい。その上、本開示の技法は、ビデオプリプロセッサによっても実行されてもよい。エンコーダおよび/またはデコーダは、グラフィックス処理装置(GPU)または同様のデバイスであってもよい。
ソースデバイス12および宛先デバイス14は、ソースデバイス12が宛先デバイス14への送信のためのコード化ビデオデータを生成するようなコーディングデバイスの単なる例である。いくつかの例では、ソースデバイス12および宛先デバイス14は、ソースデバイス12および宛先デバイス14の各々がビデオ符号化および復号構成要素を備えるように、実質的に対称に動作することができる。したがって、コーディングシステム10は、たとえば、ビデオストリーミング、ビデオ再生、ビデオ放送、またはビデオ電話のために、ビデオデバイス12、14間の単方向または双方向のビデオ伝送をサポートすることができる。
ソースデバイス12のビデオソース18は、ビデオカメラなどのビデオキャプチャデバイス、前にキャプチャされたビデオを含むビデオアーカイブ、および/またはビデオコンテンツプロバイダから立体画像もしくはビデオを受信するためのビデオフィードインターフェースを含んでもよい。さらなる代替として、ビデオソース18は、ソースビデオ、またはライブビデオ、アーカイブビデオ、およびコンピュータ生成ビデオの組合せとして、立体画像およびコンピュータグラフィックスベースのデータを生成することができる。
場合によっては、ビデオソース18がビデオカメラであるとき、ソースデバイス12および宛先デバイス14は、いわゆるカメラ電話またはビデオ電話を形成することができる。しかしながら、上述されたように、本開示に記載される技法は、一般に、ビデオコーディングに適用可能であってもよく、ワイヤレスおよび/または有線の用途に適用されてもよい。
投影デバイス20は、以下でより詳細に説明されるように、立体画像を平面(たとえば、境界ボックス)上に投影するように構成される。すなわち、投影デバイス20は、3次元(3D)画像を1つまたは複数の2次元(2D)画像に変換するように構成される。
いずれの場合も、立体画像、キャプチャされたビデオ、事前にキャプチャされたビデオ、またはコンピュータ生成ビデオは、エンコーダ22によって符号化されてもよい。次いで、符号化されたビデオ情報は、出力インターフェース24によってコンピュータ可読媒体16上に出力されてもよい。
コンピュータ可読媒体16は、ワイヤレス放送もしくは有線ネットワーク伝送などの一時的媒体、またはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、Blu-ray(登録商標)ディスク、もしくは他のコンピュータ可読媒体などの記憶媒体(すなわち、非一時的記憶媒体)を含んでもよい。いくつかの例では、ネットワークサーバ(図示せず)は、たとえばネットワーク伝送を介して、ソースデバイス12からの符号化ビデオデータを受信し、宛先デバイス14に符号化ビデオデータを提供することができる。同様に、ディスクスタンピング施設などの媒体制作施設のコンピューティングデバイスは、ソースデバイス12から符号化ビデオデータを受信し、符号化ビデオデータを含むディスクを制作することができる。したがって、コンピュータ可読媒体16は、様々な例において、様々な形態の1つまたは複数のコンピュータ可読媒体を含むと理解されてもよい。
宛先デバイス14の入力インターフェース26は、コンピュータ可読媒体16から情報を受信する。コンピュータ可読媒体16の情報は、エンコーダ22によって定義される構文情報を含んでもよく、構文情報は、デコーダ28によっても使用され、ブロックおよび他のコード化ユニット、たとえばピクチャグループ(GOP)の特性および/または処理を記述する構文要素を含む。
復元デバイス30は、以下でより詳細に説明されるように、1つまたは複数の平面画像を立体画像に変換し戻すように構成される。すなわち、復元デバイス30は、1つまたは複数の2D画像を3D画像に変換し戻すように構成される。
表示デバイス32は、立体画像または復号ビデオデータをユーザに表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプの表示デバイスなどの様々な表示デバイスのいずれかを備えてもよい。
エンコーダ22およびデコーダ28は、現在開発中の高効率ビデオコーディング(HEVC)規格などのビデオコーディング規格に従って動作することができ、HEVCテストモデル(HM)に準拠することができる。あるいは、エンコーダ22およびデコーダ28は、代替として動画専門家グループ(MPEG)-4、パート10、高度ビデオコーディング(AVC)、H.265/HEVC、またはそのような規格の拡張と呼ばれる、国際電気通信連合標準化セクタ(ITU-T)H.264規格などの、他のプロプライエタリまたは業界標準に従って動作することができる。しかしながら、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオコーディング規格の他の例には、MPEG-2およびITU-T H.263が含まれる。図1には示されていないが、いくつかの態様では、エンコーダ22およびデコーダ28は、各々オーディオエンコーダおよびオーディオデコーダと一体化されてもよく、共通のデータストリームまたは個別のデータストリームでオーディオとビデオの両方の符号化を処理するために、適切なマルチプレクサ-デマルチプレクサ(MUX-DEMUX)ユニット、または他のハードウェアおよびソフトウェアを含んでもよい。該当する場合、MUX-DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠することができる。
エンコーダ22およびデコーダ28は、各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、個別論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなどの、様々な適切なエンコーダ回路のいずれかとして実装されてもよい。技法がソフトウェアに部分的に実装されるとき、デバイスは、ソフトウェア用の命令を適切な非一時的コンピュータ可読媒体に記憶し、本開示の技法を実行するために1つまたは複数のプロセッサを使用して、ハードウェア内で命令を実行することができる。エンコーダ22およびデコーダ28の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてもよく、それらのいずれかは、それぞれのデバイス内の複合エンコーダ/デコーダ(コーデック)の一部として統合されてもよい。エンコーダ22および/またはデコーダ28を含むデバイスは、集積回路、マイクロプロセッサ、および/または携帯電話などのワイヤレス通信デバイスを備えてもよい。
図2は、ビデオコーディング技法を実施することができるエンコーダ22の一例を示すブロック図である。エンコーダ22は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実行することができる。イントラコーディングは、空間予測に依存して、所与のビデオフレームまたはビデオピクチャ内にあるビデオ内の空間冗長性を削減または除去する。インターコーディングは、時間予測に依存して、ビデオシーケンスの隣接するフレームまたはピクチャ内にあるビデオ内の時間冗長性を削減または除去する。イントラモード(Iモード)は、いくつかの空間ベースのコーディングモードのうちのいずれかを指すことができる。単方向(別名、単予測)予測(Pモード)または双予測(別名、双予測)(Bモード)などのインターモードは、いくつかの時間ベースのコーディングモードのうちのいずれかを指すことができる。
図2に示されたように、エンコーダ22は、符号化されるビデオフレーム内の現在のビデオブロックを受信する。図2の例では、エンコーダ22は、モード選択ユニット40と、基準フレームメモリ64と、加算器50と、変換処理ユニット52と、量子化ユニット54と、エントロピーコーディングユニット56とを含む。引き続き、モード選択ユニット40は、動き補償ユニット44と、動き推定ユニット42と、イントラ予測(別名、イントラ予測)ユニット46と、分割ユニット48とを含む。ビデオブロック復元のために、エンコーダ22はまた、逆量子化ユニット58と、逆変換ユニット60と、加算器62とを含む。ブロック境界をフィルタリングして、復元されたビデオからブロッキネスアーティファクトを除去するために、デブロッキングフィルタ(図2には示されず)も含まれてよい。必要に応じて、デブロッキングフィルタは、通常、加算器62の出力をフィルタリングする。デブロッキングフィルタに加えて、(ループ内またはループ後の)さらなるフィルタも使用されてよい。そのようなフィルタは簡潔にするために示されていないが、必要に応じて(ループ内フィルタとして)加算器50の出力をフィルタリングすることができる。
符号化プロセスの間、エンコーダ22は、コード化されるビデオフレームまたはビデオスライスを受信する。フレームまたはスライスは、複数のビデオブロックに分割されてもよい。動き推定ユニット42および動き補償ユニット44は、1つまたは複数の基準フレーム内の1つまたは複数のブロックに対して、受信されたビデオブロックのインター予測コーディングを実行して、時間予測を提供する。イントラ予測ユニット46は、代替として、コード化されるブロックとして同じフレームまたはスライス内の1つまたは複数の隣接ブロックに対する受信されたビデオブロックのイントラ予測コーディングを実行して、空間予測を提供することができる。エンコーダ22は、複数のコーディングパスを実行して、たとえば、ビデオデータのブロックごとに適切なコーディングモードを選択することができる。
その上、分割ユニット48は、前のコーディングパス内の前の分割方式の評価に基づいて、ビデオデータのブロックをサブブロックに分割することができる。たとえば、分割ユニット48は、最初にフレームまたはスライスを最大コーディング単位(LCU)に分割し、レート歪み分析(たとえば、レート歪み最適化)に基づいてLCUの各々をサブコーディング単位(サブCU)に分割することができる。モード選択ユニット40は、LCUをサブCUに分割したことを示す四分木データ構造をさらに生成することができる。四分木のリーフノードCUは、1つまたは複数の予測単位(PU)と、1つまたは複数の変換単位(TU)とを含んでもよい。
本開示は、HEVCのコンテキストにおけるCU、PU、もしくはTUのいずれか、または他の規格のコンテキストにおける同様のデータ構造(たとえば、H.264/AVCにおけるマクロブロックおよびそのサブブロック)を指すために、「ブロック」という用語を使用する。CUは、コーディングノード、PU、およびコーディングノードに関連付けられたTUを含む。CUのサイズは、コーディングノードのサイズに対応し、形状は正方形である。CUのサイズは、8×8ピクセルから最大64×64ピクセル以上のツリーブロックのサイズまでの範囲であってもよい。各CUは、1つまたは複数のPUおよび1つまたは複数のTUを含んでもよい。CUに関連付けられた構文データは、たとえば、CUを1つまたは複数のPUに分割することを記述することができる。分割モードは、CUがスキップモードまたはダイレクトモードで符号化されているか、イントラ予測モードで符号化されているか、またはインター予測(別名、インター予測)モードで符号化されているかによって異なってもよい。PUは、非正方形の形状に分割されてもよい。CUに関連付けられた構文データはまた、たとえば、四分木に従ってCUを1つまたは複数のTUに分割することを記述することができる。TUは、正方形または非正方形(たとえば、長方形)の形状であり得る。
モード選択ユニット40は、たとえば誤差結果に基づいて、イントラまたはインターのコーディングモードのうちの1つを選択し、結果として得られるイントラコード化ブロックまたはインターコード化ブロックを、加算器50に提供して残差ブロックデータを生成し、加算器62に提供して基準フレームとして使用するための符号化ブロックを復元する。モード選択ユニット40はまた、動きベクトル、イントラモードインジケータ、分割情報、および他のそのような構文情報などの構文情報をエントロピーコーディングユニット56に提供する。
動き推定ユニット42および動き補償ユニット44は、高度に統合されてもよいが、概念に関わる目的のために別々に示されている。動き推定ユニット42によって実行される動き推定は、ビデオブロックに関する動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在フレーム(または他のコード化ユニット)内でコード化されている現在ブロックに対する基準フレーム(または他のコード化ユニット)内にある予測ブロックに対する、現在ビデオフレームまたは現在ビデオピクチャ内にあるビデオブロックのPUの変位を示すことができる。予測ブロックは、ピクセル差分の観点から、コード化されるブロックと厳密に一致すると認められるブロックであり、これは、差分絶対値和(SAD)、差分2乗和(SSD)、または他の差分測定基準によって決定されてもよい。いくつかの例では、エンコーダ22は、基準フレームメモリ64に格納された基準ピクチャの小数ピクセル位置に関する値を計算することができる。たとえば、エンコーダ22は、基準ピクチャの1/4ピクセル位置、1/8ピクセル位置、または他の分数ピクセル位置の値を補間することができる。したがって、動き推定ユニット42は、フルピクセル位置および分数ピクセル位置に対する動き探索を実行し、分数ピクセル予測で動きベクトルを出力することができる。
動き推定ユニット42は、PUの位置を基準ピクチャの予測ブロックの位置と比較することにより、インターコード化スライス内のビデオブロックのPUに関する動きベクトルを計算する。基準ピクチャは、第1の基準ピクチャリスト(リスト0)または第2の基準ピクチャリスト(リスト1)から選択されてもよく、それらの各々は、基準フレームメモリ64に格納された1つまたは複数の基準ピクチャを識別する。動き推定ユニット42は、エントロピーコーディングユニット56および動き補償ユニット44に計算された動きベクトルを送信する。
動き補償ユニット44によって実行される動き補償は、動き推定ユニット42によって決定された動きベクトルに基づく予測ブロックの取出しまたは生成を含んでもよい。ここでも、いくつかの例では、動き推定ユニット42および動き補償ユニット44は機能的に一体化されてもよい。現在ビデオブロックのPUに関する動きベクトルを受信すると、動き補償ユニット44は、基準ピクチャリストのうちの1つにある動きベクトルが指す予測ブロックの位置を特定することができる。加算器50は、後述されるように、コード化されている現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって残差ビデオブロックを形成する。一般に、動き推定ユニット42は、輝度成分に対する動き推定を実行し、動き補償ユニット44は、輝度成分に基づいて計算された動きベクトルを色差成分と輝度成分の両方に使用する。モード選択ユニット40はまた、ビデオスライスのビデオブロックを復号する際にデコーダ28が使用するために、ビデオブロックおよびビデオスライスに関連付けられた構文要素を生成する。
イントラ予測ユニット46は、上述されたように、動き推定ユニット42および動き補償ユニット44によって実行されるインター予測の代わりに、現在ブロックをイントラ予測することができる。詳細には、イントラ予測ユニット46は、イントラ予測モードを決定して、現在ブロックを符号化するために使用することができる。いくつかの例では、イントラ予測ユニット46は、たとえば、別個の符号化パスの間、様々なイントラ予測モードを使用して現在ブロックを符号化することができ、イントラ予測ユニット46(または、いくつかの例では、モード選択ユニット40)は、テストされたモードから適切なイントラ予測モードを選択して使用することができる。
たとえば、イントラ予測ユニット46は、様々なテストされたイントラ予測モードに関してレート歪み分析を使用してレート歪み値を計算し、テストされたモードの中でも最良のレート歪み特性を有するイントラ予測モードを選択することができる。レート歪み分析は、概して、符号化ブロックと、符号化されて符号化ブロックを生成した元の符号化されていないブロックとの間の歪み(または誤差)の量、ならびに符号化ブロックを生成するために使用されたビットレート(すなわち、ビット数)を特定する。イントラ予測ユニット46は、様々な符号化ブロックに関して歪みおよびレートから比を計算して、ブロックに関してどのイントラ予測モードが最良のレート歪み値を表すかを判定することができる。
加えて、イントラ予測ユニット46は、深度モデル化モード(DMM)を使用して、深度マップの深度ブロックをコード化するように構成されてもよい。モード選択ユニット40は、たとえば、レート歪み最適化(RDO)を使用して、利用可能なDMMがイントラ予測モードおよび他のDMMモードよりも良好なコーディング結果を生成するかどうかを判定することができる。深度マップに対応するテクスチャ画像用のデータは、基準フレームメモリ64に格納されてもよい。動き推定ユニット42および動き補償ユニット44はまた、深度マップの深度ブロックをインター予測するように構成されてもよい。
ブロック用のイントラ予測モード(たとえば、従来のイントラ予測モード、またはDMMモードのうちの1つ)を選択した後、イントラ予測ユニット46は、ブロック用の選択されたイントラ予測モードを示す情報をエントロピーコーディングユニット56に提供することができる。エントロピーコーディングユニット56は、選択されたイントラ予測モードを示す情報を符号化することができる。エンコーダ22は、送信されたビットストリーム構成データを含んでもよく、そのデータは、複数のイントラ予測モードインデックステーブルおよび複数の(コードワードマッピングテーブルとも呼ばれる)修正されたイントラ予測モードインデックステーブルと、様々なブロックに関するコンテキストを符号化する定義と、最も可能性が高いイントラ予測モード、イントラ予測モードインデックステーブル、およびコンテキストの各々について使用する修正されたイントラ予測モードインデックステーブルの指示とを含んでもよい。
エンコーダ22は、コード化されている元のビデオブロックから、モード選択ユニット40からの予測データを減算することによって残差ビデオブロックを形成する。加算器50は、この減算演算を実行する1つまたは複数の構成要素を表す。
変換処理ユニット52は、離散コサイン変換(DCT)または概念的に同様の変換などの変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生成する。変換処理ユニット52は、概念的にDCTと同様の他の変換を実行することができる。ウェーブレット変換、整数変換、サブバンド変換、または他のタイプの変換が使用されることもできる。
変換処理ユニット52は、残差ブロックに変換を適用し、残差変換係数のブロックを生成する。変換は、ピクセル値領域からの残差情報を周波数領域などの変換領域に変換することができる。変換処理ユニット52は、結果として得られる変換係数を量子化ユニット54に送信することができる。量子化ユニット54は、変換係数を量子化してビットレートをさらに削減する。量子化プロセスは、係数の一部または全部に関連付けられたビット深度を削減することができる。量子化の程度は、量子化パラメータを調整することによって修正されてもよい。いくつかの例では、量子化ユニット54は、次いで、量子化変換係数を含む行列のスキャンを実行することができる。あるいは、エントロピーコーディングユニット56がスキャンを実行することができる。
量子化に続いて、エントロピーコーディングユニット56は、量子化変換係数をエントロピーコーディングする。たとえば、エントロピーコーディングユニット56は、コンテキスト適応型可変長コーディング(CAVLC)またはコンテキスト適応型バイナリ算術コーディング(CABAC)、構文ベースのコンテキスト適応型バイナリ算術コーディング(SBAC)、確率区間分割エントロピー(PIPE)コーディング、または別のエントロピーコーディング技法を実行することができる。コンテキストベースエントロピーコーディングの場合、コンテキストは隣接するブロックに基づいてもよい。エントロピーコーディングユニット56によるエントロピーコーディングに続いて、符号化ビットストリームは、別のデバイス(たとえば、デコーダ28)に送信されるか、または後で送信もしくは検索するためにアーカイブされてもよい。
逆量子化ユニット58および逆変換ユニット60は、それぞれ、逆量子化および逆変換を適用して、たとえば、基準ブロックとして後で使用するために、ピクセル領域内の残差ブロックを復元する。動き補償ユニット44は、基準フレームメモリ64のフレームのうちの1つの予測ブロックに残差ブロックを加算することによって基準ブロックを計算することができる。動き補償ユニット44はまた、復元された残差ブロックに1つまたは複数の補間フィルタを適用して、動き推定で使用するための小数ピクセル値を計算することができる。加算器62は、動き補償ユニット44によって生成された動き補償予測ブロックに復元された残差ブロックを加算して、基準フレームメモリ64に格納するための復元されたビデオブロックを生成する。復元されたビデオブロックは、後続のビデオフレーム内のブロックをインターコード化するために、動き推定ユニット42および動き補償ユニット44によって基準ブロックとして使用されてもよい。
図3は、ビデオコーディング技法を実施することができるデコーダ28の一例を示すブロック図である。図3の例では、デコーダ28は、エントロピー復号ユニット70と、動き補償ユニット72と、イントラ予測ユニット74と、逆量子化ユニット76と、逆変換ユニット78と、基準フレームメモリ82と、加算器80とを含む。デコーダ28は、いくつかの例では、エンコーダ22(図2)に関して記載された符号化パスと全体的に逆の復号パスを実行することができる。動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルに基づいて予測データを生成することができ、イントラ予測ユニット74は、エントロピー復号ユニット70から受信されたイントラ予測モードインジケータに基づいて予測データを生成することができる。
復号プロセスの間、デコーダ28は、エンコーダ22から、符号化ビデオスライスのビデオブロックを表す符号化ビデオビットストリーム、および関連する構文要素を受信する。デコーダ28のエントロピー復号ユニット70は、ビットストリームをエントロピー復号して、量子化係数、動きベクトルまたはイントラ予測モードインジケータ、および他の構文要素を生成する。エントロピー復号ユニット70は、動きベクトルおよび他の構文要素を動き補償ユニット72に転送する。デコーダ28は、ビデオスライスレベルおよび/またはビデオブロックレベルで構文要素を受信することができる。
ビデオスライスがイントラコード化(I)スライスとしてコード化されるとき、イントラ予測ユニット74は、現在のフレームまたはピクチャの前に復号されたブロックからシグナリングされたイントラ予測モードおよびデータに基づいて、現在ビデオスライスのビデオブロックに関する予測データを生成することができる。ビデオフレームがインターコード化(たとえば、B、P、またはGPB)スライスとしてコード化されるとき、動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルおよび他の構文要素に基づいて、現在ビデオスライスのビデオブロックに関する予測ブロックを生成する。予測ブロックは、基準ピクチャリストのうちの1つにある基準ピクチャのうちの1つから生成されてもよい。デコーダ28は、基準フレームメモリ82に格納された基準ピクチャに基づいて、デフォルトの構築技法を使用して基準フレームリスト、リスト0およびリスト1を構築することができる。
動き補償ユニット72は、動きベクトルおよび他の構文要素を構文解析することにより、現在ビデオスライスのビデオブロックに関する予測情報を決定し、予測情報を使用して、復号されている現在ビデオブロックに関する予測ブロックを生成する。たとえば、動き補償ユニット72は、受信された構文要素のうちのいくつかを使用して、ビデオスライスのビデオブロックをコード化するために使用される予測モード(たとえば、イントラ予測またはインター予測)、インター予測スライスタイプ(たとえば、Bスライス、Pスライス、またはGPBスライス)、スライスに関する基準ピクチャリストのうちの1つまたは複数に関する構築情報、スライスのインターコード化されたビデオブロックごとの動きベクトル、スライスのインターコード化されたビデオブロックごとのインター予測状態、および現在ビデオスライス内のビデオブロックを復号するための他の情報を特定する。
動き補償ユニット72はまた、補間フィルタに基づいて補間を実行することができる。動き補償ユニット72は、ビデオブロックの符号化の間にエンコーダ22によって使用される補間フィルタを使用して、基準ブロックの小数ピクセルに関する補間された値を計算することができる。この場合、動き補償ユニット72は、受信された構文要素からエンコーダ22によって使用される補間フィルタを決定し、補間フィルタを使用して予測ブロックを生成することができる。
深度マップに対応するテクスチャ画像用のデータは、基準フレームメモリ82に格納されてもよい。動き補償ユニット72はまた、深度マップの深度ブロックをインター予測するように構成されてもよい。
従来のコーディング技法は、パッチがパッチフレームデータユニット(別名、パッチバッファ)内でそれらのパッチモードに従って順序付けられることを必要とする。すなわち、ビデオベース点群コーディング(V-PCC)における補助情報パッチデータユニット内のパッチデータユニットタイプの表現は、すべてのパッチ関連情報がパッチフレームデータユニット内に特定の順序で配置されることを必要とする。最初に、一致したパッチデータユニットがパッチデータユニットリストに追加され、続いて不一致のパッチデータユニットが追加される。一致したパッチデータユニットは、差分コーディングを使用して符号化されてもよく(インター予測-dpdu)、不一致のパッチデータユニットは、絶対値を使用して符号化される(イントラ予測)。すなわち、すべてのインターコード化されたパッチが最初にパッチフレームデータユニット内に列挙され、続いてすべてのイントラコード化されたパッチが列挙され、以下同様である。したがって、新たなインターコード化されたパッチまたは新たなイントラコード化されたパッチをパッチフレームデータユニットに追加するために、パッチフレームデータユニット全体が必要な順序を使用して再構築されなければならず、その結果、コーディングが非効率になる。
本明細書では、パッチフレームデータユニット内のパッチの柔軟な順序付けを可能にするコーディング技法が開示される。すなわち、異なるパッチモード(たとえば、インター、イントラ、PCMなど)有するパッチは、任意の順序でパッチフレームデータユニットに含まれてもよい。コーディング技法はまた、スキップパッチデータユニットタイプ(spdu)が使用されることを可能にする。スキップパッチデータユニットは、現在のパッチデータユニット用のパッチデータユニット要素と基準パッチデータユニット用のパッチデータユニット要素が同一であるか、または完全に一致するときに、現在のパッチ用のすべてのパラメータが基準パッチから継承されてもよいことを示す。コーディング技法はまた、本明細書に記載されたパッチタイプのシグナリングがパッチフレームデータユニット内のパッチのリスト全体を表すのに十分なので、一致したパッチの数を示す構文要素がシグナリングから削除されることを可能にする。加えて、コーディング技法は、パッチフレームデータユニット内のパッチの総数(たとえば、パッチフレームデータユニットのサイズ)をシグナリングする必要性を排除し、そのプロセスを特別な終端パッチタイプと置き換える。さらに、コーディング技法は、通常、パッチフレームデータユニットの最後に配置されているパルスコード化変調(PCM)パッチがPCMパッチタイプ指示と置き換えられることを可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(別名、「コーデック」)は、現在のコーデックに対して改善される(たとえば、V-PCCにおいてパッチを符号化および復号するプロセス)。実際問題として、改善されたビデオコーディングプロセスは、コーディング効率を向上させることができ、これにより、点群が送信、受信、および/または閲覧されるときにより良いユーザ体験をユーザに提供する。
図4は、各々が点群408を含む点群フレーム402、404、406(たとえば、フレームPCC_0、フレームPCC_1、フレームPCC_4)のシーケンス400の図である。点群408は、通常の3Dグリッド上の空間の立体表現である。すなわち、点群408は3次元(3D)である。図4に示されたように、点群408は、3D空間412内に点群コンテンツ410を含む。点群コンテンツ410は、3D空間412内のポイントのセット(たとえば、ボクセル)によって表される。ボクセルは、3次元データの視覚化および分析に使用される、3次元空間内のポイントの色などの何らかの数値を表すボリューム要素である。したがって、ボクセルは、2D画像内のピクセルの3次元等価物と考えられることができる。
図4の点群408内の各ボクセルは、座標(たとえば、xyz座標)および1つまたは複数の属性(たとえば、赤/緑/青(RGB)色成分、反射率など)を有する。図4の点群コンテンツ410は人物を描写しているが、点群コンテンツ410は、実際の用途では任意の他の立体オブジェクトまたは立体画像であってもよい。
図5は、境界ボックス500上に投影された図4の点群400の図である。図5に示されたように、境界ボックス500は、その2次元(2D)の表面または平面504に投影されたパッチ502を含む。したがって、パッチ502は、3D画像の部分の2D表現である。パッチ502は、図4の点群コンテンツ410に集合的に対応する。ビデオベース点群コーディング(V-PCC)におけるデータ表現は、点群圧縮と呼ばれる場合もあり、この3Dから2Dへの変換に依存する。
V-PCCにおけるデータ表現は、たとえば、図6Aの占有マップ610、図6Bの幾何形状マップ612、および図6Cの属性マップ614を使用して、平面2D画像(たとえば、パッチ502)のセットとして記載される。
図6Aは、図5の境界ボックス500からの2D投影(たとえば、パッチ502)に対応する占有マップ610の図である。占有マップ610は、バイナリ形式でコード化される。たとえば、0は、境界ボックス600の一部分がパッチ602のうちの1つによって占有されていないことを表す。0によって表される境界ボックス600のそれらの部分は、立体表現(たとえば、点群コンテンツ410)の復元に関与しない。対照的に、1は、境界ボックス600の一部分がパッチ602のうちの1つによって占有されていることを表す。1によって表される境界ボックス600のそれらの部分は、立体表現(たとえば、点群コンテンツ410)の復元に関与する。
図6Bは、図5の境界ボックス500からの2D投影(たとえば、パッチ502)に対応する幾何形状マップ612の図である。幾何形状マップ612は、パッチ602の各々の輪郭またはトポグラフィを提供または描写する。すなわち、幾何形状マップ612は、境界ボックス600の平坦な表面(たとえば、平面504)から離れたパッチ602内の各ポイントの距離を示す。
図6Cは、図5の境界ボックス500からの2D投影(たとえば、パッチ502)に対応する属性マップ614の図である。属性マップ614は、境界ボックス600内のパッチ602内の各ポイントの属性を提供または描写する。属性マップ614内の属性は、たとえばポイントの色成分であってもよい。色成分は、RGBカラーモデル、YUVカラーモデル、または別の既知のカラーモデルに基づいてもよい。
図7は、V-PCCビットストリーム700の図である。V-PCCビットストリーム700は、点群(たとえば、図4の点群408)を復元するために必要な符号化された情報を搬送するために利用されてもよい。図示されたように、V-PCCビットストリーム700は、複数のV-PCCユニット702を含む。各V-PCCユニット702は、V-PCCユニットヘッダ704およびV-PCCユニットペイロード706を含む。V-PCCユニットヘッダ704は、V-PCCユニット702によって搬送されるV-PCCユニットペイロード706を記述する。
V-PCCユニットペイロード706は、シーケンスパラメータセット708、パッチシーケンスデータ710、占有ビデオデータ712、幾何形状ビデオデータ714、および属性ビデオデータ716(たとえば、テクスチャビデオデータ)を含む。シーケンスパラメータセット708は、点群のシーケンス(たとえば、図4の点群408を各々が含む点群フレーム402、404、406のシーケンス400)に対応するパラメータおよび情報を含む。占有ビデオデータ712、幾何形状ビデオデータ714、および属性ビデオデータ716は、点群または3D画像に対応する占有データ、幾何形状データ、および属性またはテクスチャデータを搬送する。
パッチシーケンスデータ710は、パッチ(たとえば、図5のパッチ502)のシーケンスに対応するパラメータおよび情報を含む。パッチシーケンスデータ710は、シーケンスパラメータセット720、フレームパラメータセット722、幾何形状パラメータセット724、属性パラメータセット726、幾何形状パッチパラメータセット728、属性パッチパラメータセット730、およびパッチフレーム732を含む。
シーケンスパラメータセット720は、点群シーケンスの全持続時間にわたって、または新しいシーケンスパラメータセットがビットストリーム内でシグナリングされるまで持続する2Dパッチ(たとえば、図5のパッチ502)のシーケンスに対応するパラメータおよび情報を含む。フレームパラメータセット722は、点群シーケンスの単一フレームの持続時間にわたって持続する2Dパッチのシーケンスに対応する情報を含む。幾何形状パラメータセット724は、パッチシーケンスデータの幾何形状特性の復元プロセスに対応する情報を含む。属性パラメータセット726は、パッチシーケンスデータの属性特性の復元プロセスに対応する情報を含む。幾何形状パッチパラメータセット728は、パッチシーケンスデータの幾何形状特性の復号プロセスに対応する情報を含む。属性730は、パッチシーケンスデータの属性特性の復号プロセスに対応する情報を含む。
(パッチフレームと呼ばれる)パッチフレームデータユニット732は、パッチデータユニット734のセットを含む。パッチデータユニット734は、パッチ(たとえば、パッチ502)用のパッチデータ(たとえば、パッチデータF0、…、Fk)を一括して含む。パッチデータユニット734の各々は、本明細書ではパッチモードと呼ばれるパッチタイプを有する。以下でより詳細に説明されるように、パッチモード(たとえば、patch_mode)は、コーディングプロセス中に特定のパッチがどのように処理されるべきかを示す。
図8は、複数のフレーム802用の点群シーケンス800のコード化分解の図である。図8のフレーム802は、図4の点群フレーム402、404、406と同様である。したがって、フレーム802の各々は、3D点群のための点群コンテンツ810を含む。図8の各フレーム802内の点群コンテンツ810は、点群コンテンツ810を復元するために使用される2D投影における占有マップ812、幾何形状マップ814、および属性マップ816に対応する。図示されたように、2D投影は、2つ以上の属性マップ816を含んでもよい。
図示されたように、点群シーケンス800はまた、補助情報パッチフレームデータユニット850(AUX_INF)を含む。一実施形態では、補助情報パッチフレームデータユニット850は、2Dと3D両方の境界ボックス情報(たとえば、図12のパッチ3D境界ボックス1204およびパッチ2D投影境界ボックス1208)を含む。補助情報パッチフレームデータユニット850の集合は、図7のパッチシーケンスデータ710に対応する。各補助情報パッチフレームデータユニット850は、シーケンスパラメータセット720、フレームパラメータセット722、幾何形状パラメータセット724、属性パラメータセット726、幾何形状パッチパラメータセット728、属性パッチパラメータセット730、およびパッチフレーム732を含む。一実施形態では、パッチフレーム732が補助情報パッチフレームデータユニット850に含まれ、パッチシーケンスデータ710内の残りの構成要素は任意選択である。一実施形態では、占有マップ812の集合は占有ビデオデータ712に対応し、幾何形状マップ814の集合は幾何形状ビデオデータ714に対応し、属性マップ816の集合は属性ビデオデータ716に対応する。特に、占有マップはこの画像に存在しない。補助情報パッチデータユニット850は、各々フレーム802のうちの1つの中の点群コンテンツ810に対応する。パッチデータユニット(たとえば、850)は、2D投影における占有マップ812、幾何形状マップ814、および属性マップ816に基づいて、3D点群内の点群コンテンツ810を復元するために使用または必要とされる情報を含む。
図9は、図8の点群シーケンス800内の点群フレーム802のうちの1つから抽出された単一のパッチデータユニット900の図である。単一のパッチデータユニット900は、図7のパッチフレーム732内のパッチデータユニット734または補助情報パッチフレームデータユニット850と同様である。単一のパッチデータユニット900は、周囲の3D空間902を基準にして描写されている。
図10A~図10Cは、図9の単一のパッチデータユニット900に対応する占有マップ1000、幾何形状マップ1002、および属性マップ1004の図である。占有マップ1000、幾何形状マップ1002、および属性マップ1004は、図6A~図6Cの占有マップ610、幾何形状マップ612、および属性マップ614と同様である。しかしながら、図10A~図10Cの占有マップ1000、幾何形状マップ1002、および属性マップ1004は、境界ボックス500全体からのパッチ502の集合ではなく、単一のパッチデータユニット900のみを表す。したがって、図10A~図10Cの占有マップ1000、幾何形状マップ1002、および属性マップ1004は、図9の単一のパッチデータユニット900に対応する単一のパッチ1006のみを含む。
図11は、2D境界ボックス1154内のパッチデータユニット1152用の2D成分の図である。図11のパッチデータユニット1152は、図9の単一のパッチデータユニット900と同様である。図11に示されたように、2D成分は、パッチデータユニット1152用のパッチ座標(たとえば、[u0,v0])および寸法(たとえば、Size_u0、Size_v0)を表す。これらの2D成分は、パッチデータユニット(たとえば、図7のパッチデータユニット734または図8のパッチデータユニット850)に含まれる。
図12A~図12Bは、図11のパッチデータユニット1152用の3D成分の概略図1200およびデータセット図1252である。図示されたように、概略図1200は、点群3D境界ボックス1202、パッチ3D境界ボックス1204、投影面1206、およびパッチ2D投影境界ボックス1208を含む。様々な座標(たとえば、[0,0,0])および寸法(たとえば、x、y、z、u、v、d1、u1、v1)およびベクトル(b,t,bt)は、点群3D境界ボックス1202のコンテンツをパッチ2D投影境界ボックス1208上に投影するプロセスを記述するために使用される。データセット図1252は、座標(たとえば、[0,0,0]、[u1,v1,d1])およびベクトル(たとえば、n,bt)に基づいて、(単一のパッチデータユニット900と同様である)単一のパッチデータユニット1254が投影面1206上に投影されることができる方式を描写する。これらの3D成分も、パッチデータユニット(たとえば、図7のパッチデータユニット734または図8のパッチデータユニット850)に含まれる。
パッチデータユニット(たとえば、図7のパッチデータユニット734または図8のパッチデータユニット850)は、2Dから3Dへの復元プロセスに必要な情報を含み、以下(図11を参照):
2d関連成分
U0(Patch2dShiftU)
V0(Patch2dShiftV)
Size_u0(Patch2dSizeU)
Size_v0(Patch2dSizeV)
および以下(図12A~12Bを参照):
3d関連成分:
u1 (Patch3dShiftTangentAxis)-接線軸(t)に沿った3dパッチ境界ボックスから点群境界ボックスまでの距離
v1 (Patch3dShiftBiTangentAxis)-従折線軸(bt)に沿った3dパッチ境界ボックスから点群境界ボックスまでの距離
d1 (Patch3dShiftNormalAxis)-法線軸(n)に沿った3dパッチ境界ボックスから点群境界ボックスまでの距離
n (PatchNormalAxis)-パッチ投影面に垂直な(法線)軸(境界ボックスの任意の側面が投影面にされることができる)
t (Patch3dShiftTangentAxis)-パッチ表面に接し、法線軸に垂直な軸
bt (Patch3dShiftBiTangentAxis)-法線軸および接線軸に垂直な軸
に表される。
上述されたように、従来のコーディング技法は、パッチ(図7のパッチデータユニット734)がパッチフレームデータユニット内でそれらのパッチモードに従って順序付けられることを必要とする。すなわち、V-PCCにおけるパッチフレームデータユニット内のパッチデータユニットタイプの表現は、すべてのパッチ関連情報がパッチフレームデータユニット内に特定の順序で配置されることを必要とする。最初に、一致したパッチデータユニットがパッチデータフレームに追加され、続いて不一致のパッチデータユニットが追加される。一致したパッチデータユニットは、差分コーディングを使用して符号化されてもよく(インター予測-dpdu)、不一致のパッチデータユニットは、絶対値を使用して符号化される(イントラ予測)。すなわち、すべてのインターコード化されたパッチが最初にパッチフレームデータユニット内に列挙され、続いてすべてのイントラコード化されたパッチが列挙され、以下同様である。したがって、新たなインターコード化されたパッチまたは新たなイントラコード化されたパッチをパッチフレームデータユニットに追加するために、パッチフレームデータユニット全体が必要な順序を使用して再構築されなければならず、その結果、コーディングが非効率になる。以下に詳述される方法は、これらのコーディングの非効率性を克服する。
図13は、パッチフレームデータユニット符号化プロセス1300の一実施形態である。パッチフレームデータユニット符号化プロセス1300は、図7のパッチデータユニット734などの複数のパッチデータユニットを符号化(別名、圧縮)するために利用されてもよい。パッチフレームデータユニット符号化プロセス1300は、エンコーダによって実施されてもよい。ここで、2D境界ボックス1154に対応するパッチフレームデータユニットは、パッチデータユニット1152に対応するパッチデータユニットの集合である。一実施形態では、符号化プロセス1300への入力は、パッチフレームデータユニットに対応するパッチデータユニットの集合である。
ブロック1302において、パッチフレームデータユニット(pfdu)が取得される。パッチフレームデータユニットは、エンコーダの受信機によって受信されてもよい。パッチフレームデータユニットは、パッチデータユニットの集合からなる。パッチデータユニットは、複数のパッチデータユニット(たとえば、パッチ502)の各々について、パッチタイプ(pdfu_patch_mode)を識別するか、または含む。一実施形態では、パッチタイプは、スキップ、イントラ、インター、PCM、または最後のうちの1つである。スキップパッチタイプは、現在のパッチが基準パッチと同一であることを示す。したがって、基準パッチからのパラメータは、現在のパッチをコーディングする際に使用される。イントラパッチタイプは、現在のパッチがイントラ予測を使用してコード化(別名、イントラコード化)されることを示す。インターパッチタイプは、現在のパッチがインター予測を使用してコード化(別名、インターコード化)されることを示す。PCMパッチタイプは、現在のパッチが3D点群から独立した散乱点を表すことを示す。最後のパッチタイプは、現在のパッチがコード化される最後のパッチであること、したがって、パッチフレームデータユニットの圧縮プロセスが終了または終結されるべきであることを示す。
ブロック1304において、パッチデータユニットインデックス(p)がデクリメントされる。パッチデータユニットインデックスをデクリメントすることにより、パッチデータユニットインデックスは負の値(たとえば、-1)から始まることができる。したがって、ブロック1306においてパッチデータユニットインデックスがインクリメントされると、パッチデータユニットインデックスは、ゼロから始まるように効果的に初期化される。一実施形態では、プロセス1300はまた、最初にパッチデータユニットインデックスを0に設定し、次いで、(以下で説明されるように)プロセスのループまたは反復部分が実行された後にパッチデータユニットインデックスをインクリメントすることができる。
ブロック1308において、パッチフレームデータユニット内の複数のパッチデータユニットからの現在のパッチデータユニット用のパッチデータユニットタイプが最後のパッチタイプであるかどうかの判定が行われる。現在のパッチデータユニットが最後のパッチでないとき、プロセス1300はブロック1310に進む。ブロック1310において、パッチ情報データが現在のパッチ用に符号化される。一実施形態では、パッチ情報データは、フレームインデックス(frmIdx)、パッチインデックス(p)、およびパッチタイプ(pdfu_patch_mode)、ならびに対応する2Dおよび3Dの情報を含む。ブロック1310における符号化の後、プロセス1300はブロック1306にループバックする。そこで、パッチデータユニットインデックスがインクリメントされる。パッチインデックスをインクリメントすることにより、新しい現在のパッチデータユニットが考慮される。これらのステップは、ブロック1308において現在のパッチデータユニットが最後のパッチであると判定されるまで繰り返される。
現在のパッチデータユニットが最後のパッチデータユニットであると判定されると、プロセス1300はブロック1312に進む。ブロック1312において、パッチ情報データが現在のパッチデータユニット用に符号化される。一実施形態では、パッチ情報データは、フレームインデックス(frmIdx)、パッチインデックス(p)、およびパッチタイプ(pdfu_patch_mode)を含み、最後のパッチデータユニットはパッチデータユニットに関連付けられた2Dまたは3Dの情報を有していないことが言及されるべきである。ブロック1310とは異なり、ブロック1312のパッチタイプは最後のパッチタイプとして符号化される。
ブロック1314において、バイトアラインメントプロセスが実行される。一実施形態では、バイトアラインメントは、データのバイトを所望の向きまたはサイズに編成または配置する。次いで、ブロック1316において、圧縮されたパッチフレームデータユニットが実現される。圧縮されたパッチフレームデータユニットは、デコーダに向けて送信するためにビットストリームに組み込まれてもよい。
図14は、最後のパッチフラグを使用するパッチフレームデータユニット符号化プロセス1400の一実施形態である。パッチフレームデータユニット符号化プロセス1400は、図7のパッチデータユニット734などの複数のパッチデータユニットを符号化(別名、圧縮)するために利用されてもよい。パッチフレームデータユニット符号化プロセス1400は、エンコーダによって実施されてもよい。
ブロック1402において、パッチフレームデータユニット(pfdu)が取得される。パッチフレームデータユニットは、エンコーダの受信機によって受信されてもよい。パッチフレームデータユニットは、複数のパッチデータユニット(たとえば、パッチ502)を含む。
ブロック1404において、パッチインデックス(p)がデクリメントされる。パッチインデックスをデクリメントすることにより、パッチインデックスは負の値(たとえば、-1)から始まることができる。ブロック1406において、最後のパッチフラグが複数のパッチの各々に追加される。一実施形態では、最後のパッチフラグは、pfdu_is_last_patch_flagと指定される。最後のパッチフラグは、各パッチのパッチタイプに応じて値を設定または割り当てられてもよい。たとえば、パッチフラグは、パッチ用のパッチタイプがスキップ、イントラ、インター、PCM、または最後のうちの1つであることを示すことができる。
ブロック1408において、パッチインデックスがインクリメントされて、パッチインデックスをゼロから始まるように効果的に初期化する。ブロック1410において、パッチフレームデータユニットに対応する複数のパッチデータユニットからの現在のパッチデータユニット用のパッチタイプが最後のパッチタイプであるかどうかの判定が、最後のパッチフラグの値に基づいて行われる。現在のパッチデータユニットが最後のパッチでないとき、プロセス1400はブロック1412に進む。ブロック1412において、パッチ情報データが現在のパッチデータユニット用に符号化される。一実施形態では、パッチ情報データは、フレームインデックス(frmIdx)、パッチインデックス(p)、およびパッチタイプ(pdfu_patch_mode)、ならびに対応する2Dおよび3Dの情報を含む。プロセス1400のブロック1412において、パッチタイプは、スキップ、インター、イントラ、またはPCMであってもよいが、最後ではない。ブロック1414において、最後のパッチフラグが符号化される。
ブロック1414における符号化の後、プロセス1400はブロック1408にループバックする。そこで、パッチインデックスがインクリメントされる。パッチインデックスをインクリメントすることにより、新しい現在のパッチが考慮される。これらのステップは、最後のパッチフラグの値に基づいてブロック1410において現在のパッチが最後のパッチであると判定されるまで繰り返される。
最後のパッチフラグに基づいて現在のパッチが最後のパッチであると判定されると、プロセス1400はブロック1416に進む。ブロック1416において、バイトアラインメントプロセスが実行される。次いで、ブロック1418において、圧縮されたパッチフレームデータユニットが実現される。圧縮されたパッチフレームデータユニットは、デコーダに向けて送信するためにビットストリームに組み込まれてもよい。
図15は、パッチユニットタイプの説明を伴うパッチ情報データフレーム1500の一実施形態である。パッチ情報データフレーム(パッチフレームデータユニット)1500は、図7のパッチフレーム(パッチフレームデータユニット)732と同様である。図示されたように、パッチ情報データフレーム1500は、(refFrmIdxで示された)基準パッチフレームデータユニット1502と、現在のパッチフレームデータユニット(frmIdx)1504と、パッチ情報ユニット1506とを含む。基準パッチフレームデータユニット1502は、たとえば、インター予測またはスキップ予測に関連して使用される基準フレームを含む。現在のパッチフレームデータユニット1504は、符号化または復号されている複数のパッチデータユニットを含む。パッチ情報データユニット1506は、利用可能なパッチタイプのうちの1つを有するパッチのパッチデータユニット(たとえば、パッチ502)を含む。一実施形態では、パッチデータユニットは、イントラパッチタイプ(pdu)1508、PCMパッチタイプ(ppdu)1510、インターパッチタイプ(dpdu)1512、およびスキップパッチタイプ(spdu)1514のパッチデータユニットであり得る。パッチ情報ユニット1506内に任意の数のパッチが存在することができ、パッチは任意の順序であり得る。
図16は、パッチフレームデータユニット復号プロセス1600の一実施形態である。パッチフレームデータユニット復号プロセス1600は、エンコーダによって符号化された立体画像を復号(別名、解凍)するために利用されてもよい。パッチフレームデータユニット復号プロセス1600は、エンコーダ(たとえば、エントロピー復号ユニット70)によって実施されてもよい。
ブロック1602において、符号化されたパッチ情報データが受信され読み込まれる。符号化されたパッチ情報データは、ビットストリームの一部としてデコーダの受信機によって受信されてもよい。符号化されたパッチ情報データは、エンコーダによって符号化された立体画像を復号するために必要なデータおよび情報を含む。たとえば、符号化されたパッチ情報データは、圧縮されており、パッチから立体画像(たとえば、3D点群)を復元するために必要な複数のパッチデータユニット(たとえば、パッチ502またはパッチデータユニット850)を含む。ブロック1602の一部として、プロセス1600が開始されると、複数のパッチからパッチ(たとえば、初期のパッチデータユニットまたは現在のパッチデータユニット)が取得されてもよい。
ブロック1604において、符号化されたパッチ情報データに対応する入力が受信される。一実施形態では、入力は、圧縮されたパッチのうちの1つまたは複数に対応する。一実施形態では、入力は、パッチに対応するpatch_mode、パッチインデックス、基準インデックス、フレームインデックス、および基準フレームインデックスのうちの1つまたは複数を備える。
ブロック1606において、パッチ用のパッチタイプがスキップパッチタイプであるかどうかの判定が行われる。パッチ用のパッチタイプがスキップパッチタイプであるとき、プロセス1600はブロック1608に進む。ブロック1608において、パッチに対応する基準パッチインデックス(spdu_patch_index)が復号される。すなわち、基準パッチインデックスの値が復号される。一実施形態では、spdu_patch_indexは、refFrmIdxによって示された、基準フレーム内のパッチのインデックスである。
ブロック1610において、パッチ用の基準インデックス(refIdx)が、パッチに対応する基準フレームインデックス([refFrmIdx])、およびパッチタイプがスキップパッチタイプであるときに復号された基準パッチインデックスに基づいて決定される。一実施形態では、基準パッチインデックス(RefPatchIdx)と呼ばれる場合もある基準インデックスは、以下のRefPatchIdx=predictorIdx+spdu_patch_index[frmIdx][p]に基づいて決定され、ここで、predictorIdxは予測インデックスであり、spdu_patch_indexはスキップタイプのパッチデータユニットインデックスであり、frmIdxはフレームインデックスであり、pはパッチインデックスである。一実施形態では、現在のパッチフレームデータユニットインデックス(frmIdx)およびパッチインデックス(p)内の正しいパッチデータユニットへのポインタは、パッチ用の実際の基準インデックスを見つけるために多次元配列内の適切なスポットを指す。
ブロック1612において、パッチタイプがスキップパッチタイプであるときに決定された基準インデックスに基づいてパッチが復元される。一実施形態では、パッチは以下に従って復元される。
復元:
Patch2dShiftU[frmIdx][p]=Patch2dShiftU[refIdx][RefPatchIdx]*ops_occupancy_packing_block_size
Patch2dShiftV[frmIdx][p]=Patch2dShiftV[refIdx][RefPatchIdx]*ops_occupancy_packing_block_size
Patch2dSizeU[frmIdx][p]=Patch2dSizeU[refIdx][RefPatchIdx]*ops_occupancy_packing_block_size
Patch2dSizeV[frmIdx][p]=Patch2dSizeV[refIdx][RefPatchIdx]*ops_occupancy_packing_block_size
Patch3dShiftTangentAxis[frmIdx][p]=Patch3dShiftTangentAxis[refIdx][RefPatchIdx]
Patch3dShiftBiTangentAxis[frmIdx][p]=Patch3dShiftBiTangentAxis[refIdx][RefPatchIdx]
Patch3dShiftNormalAxis[frmIdx][p]=Patch3dShiftNormalAxis[refIdx][RefPatchIdx]
PatchNormalAxis[frmIdx][p]=PatchNormalAxis[refIdx][RefPatchIdx]
PatchTangentAxis[frmIdx][p]=PatchTangentAxis[refIdx][RefPatchIdx]
PatchBiTangentAxis[frmIdx][p]=PatchBiTangentAxis[refIdx][RefPatchIdx]
PatchOrientationSwapFlag[frmIdx][p]=PatchOrientationSwapFlag[refIdx][RefPatchIdx]
PatchLod[frmIdx][p]=PatchLod[refIdx][RefPatchIdx]
PatchProjectionMode[frmIdx][p]=dpdu_projection_mode[frmIdx][p]
一実施形態では、パッチは以下に従って復元される。
復元:
Patch2dShiftU[p]=pdu_2d_shift_u[refIdx]
Patch2dShiftV[p]=pdu_2d_shift_v[refIdx]
Patch2dSizeU[p]=Patch2dSizeU[refIdx]
Patch2dSizeV[p]=Patch2dSizeV[refIdx]
Patch3dShiftT[p]=Patch3dShiftT[refIdx]
Patch3dShiftBT[p]=Patch3dShiftBT[refIdx]
Patch3dShiftN[p]=Patch3dShiftN[refIdx]
PatchNormalAxis[p]=PatchNormalAxis[refIdx]
Orientation[p]=Orientation[refIdx]
PatchLod[p]=PatchLod[refIdx]
ブロック1650において、復元されたパッチ情報データが収集され(たとえば、メモリに記憶され)、プロセス1600はブロック1602にループバックして、新しいパッチが復号されることができる。
ブロック1614において、パッチデータユニット用のパッチタイプがイントラパッチタイプであるかどうかの判定が行われる。パッチ用のパッチタイプがイントラパッチタイプであるとき、プロセス1600はブロック1616に進む。ブロック1616において、パッチデータユニット用の基準パッチデータユニットインデックス(refIdx)が、現在のフレームインデックス([frmIdx])内の(パッチおよびデクリメントされたパッチインデックスに対応する)前のパッチデータユニットに基づいて決定される。一実施形態では、現在フレーム(たとえば、パッチフレームデータユニット)が基準に使用される。
ブロック1618において、パッチは、パッチに対応する2次元(2D)成分およびパッチに対応する3次元(3D)成分を使用して復号される。一実施形態では、パッチは以下に従って復号される。
復号演算:
u0(pdu_2d_shift_u)
u1(pdu_2d_shift_v)
d_size_u0(pdu_2d_delta_size_u)
d_size_v0(pdu_2d_delta_size_v)
u1(pdu_3d_shift_tangent_axis)
v1(pdu_3d_shift_bitangent_axis)
d1(pdu_3d_shift_normaI_axis)
n(pdu_normI_axis)
swap(pdu_orientation_swap_flag)
L0D(pdu_Iod)
ブロック1620において、復号されたパッチに基づいてパッチが復元される。一実施形態では、パッチは以下に従って復号される。
復元:
Patch2dShiftU[p]=pdu_2d_shift_u[p]
Patch2dShiftV[p]=pdu_2d_shift_v[p]
Patch2dSizeU[p]=pdu_2d_delta_size_u[p]+
+Patch2dSizeU[refldx]
Patch2dSizeV[p]=pdu_2d_deIta_size_v[p]+
+Patch2dsizeV[refldx]
Patch3dShiftT[p]=pdu_3d_shift_tan[p]
Patch3dShiftBT[p]=pdu_3d_shift_bitan[p]
Patch3dShiftN[p]=pdu_shift_norm[p]
PatchNormalAxis[p]=pdu_norm_axis[p]
Orientation[p]=pdu_orientation_swap_flag[p]
PatchLod[p]=pdu_Iod[p]
ブロック1650において、復元されたパッチ情報データが収集され(たとえば、メモリに記憶され)、プロセス1600はブロック1602にループバックして、新しいパッチが復号されることができる。
ブロック1622において、パッチ用のパッチタイプがインターパッチタイプであるかどうかの判定が行われる。パッチ用のパッチタイプがインターパッチタイプであるとき、プロセス1600はブロック1624に進む。ブロック1624において、パッチに対応する基準パッチインデックス(dpdu_patch_index)が復号される。すなわち、基準パッチインデックスの値が復号される。ブロック1626において、パッチ用の基準インデックス(refIdx)が、パッチに対応する基準フレームインデックス([refFrmIdx])、および復号された基準パッチインデックスに基づいて決定される。
ブロック1628において、パッチに対応する2次元(2D)成分およびパッチに対応する3次元(3D)成分を使用してパッチが復号される。一実施形態では、パッチは以下に従って復号される。
復号演算:
d_u0(pdu_2d_shift_u)
d_u1(pdu_2d_shift_v)
d_size_u0(pdu_2d_delta_size_u)
d_size_v0(pdu_2d_delta_size_v)
d_u1(pdu_3d_shift_tangent_axis)
d_v1(pdu_3d_shift_bitangent_axis)
d_d1(pdu_3d_shift-normal_axis)
ブロック1630において、復号されたパッチに基づいてパッチが復元される。一実施形態では、パッチは以下に従って復元される。
復元:
Patch2dShiftU[p]=pdu_2d_shift_u[p]+
+Patch2dShiftU[refldx]
Patch2dShiftVf[p]=pdu_2d_shift_v[p]+
+Patch2dshiftV[refldx]
Patch2dsizeU[p]=pdu_2d_delta_size_u[p]+
+Patch2dSizeU[refldx]
Patch2dSizeV[p]=pdu_2d_delta_size_v[p]+
+Patch2dSizeV[refldx]
Patch3dShiftT[p]=pdu_3d_shift_tan[p]+
+Patch3dshiftT[refldx]
Patch3dShiftBT[p]=pdu_3d_shift_bitan[p]+
+patch3dshiftBT[refldx]
Patch3dShiftN[p]=pdu_shift_norm[p]+
+Patch3dShiftN[refldx]
PatchNormaIAxis[p]=PatchnormaIAxis[refldx]
Orientation[p]=Orientation[refldx]
PatchLod[p]=PatchLod[refldx]
ブロック1650において、復元されたパッチ情報データが収集され(たとえば、メモリに記憶され)、プロセス1600はブロック1602にループバックして、新しいパッチが復号されることができる。
ブロック1632において、パッチ用のパッチタイプがPCMパッチ(または未加工の)パッチタイプであるかどうかの判定が行われる。パッチ用のパッチタイプがPCMパッチタイプであるとき、プロセス1600はブロック1634に進む。ブロック1634において、パッチ用の基準インデックス(refIdx)が、パッチに対応するフレームインデックス([frmIdx])およびデクリメントされたパッチインデックスに基づいて決定される。
ブロック1636において、パッチに対応する2次元(2D)成分およびパッチに対応する3次元(3D)成分を使用してパッチが復号される。一実施形態では、2D成分および3D成分は以下を備える。
復号演算:
separate_video_flag(ppdu_patch…)
u0(ppdu_2d_shift_u)
u1(ppdu_2d_shift_y)
d_size_u0(ppdu_2d_delta_size_u)
d_sze_v0(ppdu_2d_delta_size_v)
PCM points(ppdu_pcm_points)
ブロック1638において、復号されたパッチに基づいてパッチが復元される。一実施形態では、パッチは以下に従って復元される。
復元:
Patch2dShiftU[p]=pdu_2d_shift_u[p]
Patch2dShiftV[p]=pdu_2d_shifty[p]
Patch2dSizeU[p]=pdu_2d_deltasize_u[p]+
+Patch2dSizeU[refIdx]
Patch2dSizeV[p]=pdu_2d_deIta_sizev[p]+
+Patch2dSizeV[refldx]
PatchPcmPoints[p]=ppdu_pcm_points[p]
ブロック1650において、復元されたパッチ情報データが収集され(たとえば、メモリに記憶され)、プロセス1600はブロック1602にループバックして、新しいパッチが復号されることができる。
ブロック1640において、パッチ用のパッチタイプが最後のパッチタイプであるかどうかの判定が行われる。パッチ用のパッチタイプが最後のパッチタイプであるとき、プロセス1600はブロック1642に進む。ブロック1642において、パッチタイプが最後のパッチタイプであるとき、符号化されたパッチ情報データに対応する復元プロセスが終了される。すなわち、復元プロセスが終了される。一実施形態では、パッチフレームデータユニット復号プロセス1600が終了される前に、最後のパッチタイプを有するパッチに含まれる任意のデータが復号されてもよい。
図17は、パッチフレームデータユニット復号プロセス1700の一実施形態である。パッチフレームデータユニット復号プロセス1700は、エンコーダによって符号化された立体画像を復号(別名、解凍)するために利用されてもよい。フレームパッチデータユニット復号プロセス1700は、エンコーダ(たとえば、エントロピー復号ユニット70)によって実施されてもよい。
ブロック1702において、符号化されたパッチ情報データが受信され読み込まれる。符号化されたパッチ情報データは、ビットストリームの一部としてデコーダの受信機によって受信されてもよい。符号化されたパッチ情報データは、エンコーダによって符号化された立体画像を復号するために必要なデータおよび情報を含む。たとえば、符号化されたパッチ情報データは、圧縮されており、パッチから立体画像(たとえば、3D点群)を復元するために必要な複数のパッチデータユニット(たとえば、パッチ502またはパッチデータユニット850)を含む。ブロック1702の一部として、プロセス1700が開始されると、複数のパッチからパッチ(たとえば、初期のパッチまたは現在のパッチ)が取得されてもよい。
ブロック1704において、符号化されたパッチ情報データに対応する入力が受信される。一実施形態では、入力は、圧縮されたパッチのうちの1つまたは複数に対応する。一実施形態では、入力は、パッチに対応するpatch_mode、パッチインデックス、基準インデックス、フレームインデックス、および基準フレームインデックスのうちの1つまたは複数を備える。
ブロック1706において、パッチ用のパッチタイプがスキップパッチタイプであるかどうかの判定が行われる。パッチ用のパッチタイプがスキップパッチタイプであるとき、プロセス1700はブロック1708に進む。ブロック1708において、パッチに対応する基準パッチインデックス(spdu_patch_index)が復号(または決定)される。すなわち、基準パッチインデックスの値が復号または決定される。
ブロック1710において、パッチ用の基準インデックス(refIdx)が、パッチに対応する基準フレームインデックス([refFrmIdx])、およびパッチタイプがスキップパッチタイプであるときに復号された基準パッチインデックスに基づいて決定される。一実施形態では、基準パッチインデックス(RefPatchIdx)と呼ばれる場合もある基準インデックスは、以下のRefPatchIdx=predictorIdx+spdu_patch_index[frmIdx][p]に基づいて決定され、ここで、predictorIdxは予測インデックスであり、spdu_patch_indexはスキップタイプのパッチデータユニットインデックスであり、frmIdxはフレームインデックスであり、pはパッチインデックスである。
ブロック1712において、パッチタイプがスキップパッチタイプであるときに決定された基準インデックスに基づいてパッチが復元される。一実施形態では、パッチは以下に従って復元される。
復元:
Patch2dShiftU[frmIdx][p]=Patch2dShiftU[refIdx][RefPatchIdx]*ops_occupancy_packing_block_size
Patch2dShiftV[frmIdx][p]=Patch2dShiftV[refIdx][RefPatchIdx]*ops_occupancy_packing_block_size
Patch2dSizeU[frmIdx][p]=Patch2dSizeU[refIdx][RefPatchIdx]*ops_occupancy_packing_block_size
Patch2dSizeV[frmIdx][p]=Patch2dSizeV[refIdx][RefPatchIdx]*ops_occupancy_packing_block_size
Patch3dShiftTangentAxis[frmIdx][p]=Patch3dShiftTangentAxis[refIdx][RefPatchIdx]
Patch3dShiftBiTangentAxis[frmIdx][p]=Patch3dShiftBiTangentAxis[refIdx][RefPatchIdx]
Patch3dShiftNormalAxis[frmIdx][p]=Patch3dShiftNormalAxis[refIdx][RefPatchIdx]
PatchNormalAxis[frmIdx][p]=PatchNormalAxis[refIdx][RefPatchIdx]
PatchTangentAxis[frmIdx][p]=PatchTangentAxis[refIdx][RefPatchIdx]
PatchBiTangentAxis[frmIdx][p]=PatchBiTangentAxis[refIdx][RefPatchIdx]
PatchOrientationSwapFlag[frmIdx][p]=PatchOrientationSwapFlag[refIdx][RefPatchIdx]
PatchLod[frmIdx][p]=PatchLod[refIdx][RefPatchIdx]
PatchProjectionMode[frmIdx][p]=dpdu_projection_mode[frmIdx][p]
一実施形態では、パッチは以下に従って復元される。
復元:
Patch2dShiftU[p]=pdu_2d_shift_u[refIdx]
Patch2dShiftV[p]=pdu_2d_shift_v[refIdx]
Patch2dSizeU[p]=Patch2dSizeU[refIdx]
Patch2dSizeV[p]=Patch2dSizeV[refIdx]
Patch3dShiftT[p]=Patch3dShiftT[refIdx]
Patch3dShiftBT[p]=Patch3dShiftBT[refIdx]
Patch3dShiftN[p]=Patch3dShiftN[refIdx]
PatchNormalAxis[p]=PatchNormalAxis[refIdx]
Orientation[p]=Orientation[refIdx]
PatchLod[p]=PatchLod[refIdx]
ブロック1760において、フラグが復号されて、考慮すべきパッチがさらに存在するかどうかを判定する。一実施形態では、フラグはmore_patches_available_flagと指定される。ブロック1762において、フラグの値が決定される。フラグが第1の値(たとえば、1)を有するとき、プロセス1700はブロック1764に進む。ブロック1764において、復元されたパッチ情報データが記憶され、プロセスはブロック1702にループバックして、新しいパッチが復号されることができる。フラグが第2の値(たとえば、0)を有するとき、プロセス1700はブロック1742に進む。ブロック1742において、パッチタイプが最後のパッチタイプであるとき、符号化されたパッチ情報データに対応する復元プロセスが終了される。すなわち、復元プロセスが終了される。
ブロック1714において、パッチデータユニット用のパッチタイプがイントラパッチタイプであるかどうかの判定が行われる。パッチ用のパッチタイプがイントラパッチタイプであるとき、プロセス1700はブロック1716に進む。ブロック1716において、パッチデータユニット用の基準パッチデータユニットインデックス(refIdx)が、現在のフレームインデックス([frmIdx])内の(パッチおよびデクリメントされたパッチインデックスに対応する)前のパッチデータユニットに基づいて決定される。
ブロック1718において、パッチに対応する2次元(2D)成分およびパッチに対応する3次元(3D)成分を使用してパッチが復号される。一実施形態では、パッチは以下に従って復号される。
復号演算:
u0(pdu_2d_shift_u)
u1(pdu_2d_shift_v)
d_size_u0(pdu_2d_delta_size_u)
d_size_v0(pdu_2d_delta_size_v)
u1(pdu_3d_shift_tangent_axis)
v1(pdu_3d_shift_bitangent_axis)
d1(pdu_3d_shift_normaI_axis)
n(pdu_normI_axis)
swap(pdu_orientation_swap_flag)
L0D(pdu_Iod)
ブロック1720において、復号されたパッチに基づいてパッチが復元される。一実施形態では、パッチは以下に従って復号される。
復元:
Patch2dShiftU[p]=pdu_2d_shift_u[p]
Patch2dShiftV[p]=pdu_2d_shift_v[p]
Patch2dSizeU[p]=pdu_2d_delta_size_u[p]+
+Patch2dSizeU[refldx]
Patch2dSizeV[p]=pdu_2d_deIta_size_v[p]+
+Patch2dsizeV[refldx]
Patch3dShiftT[p]=pdu_3d_shift_tan[p]
Patch3dShiftBT[p]=pdu_3d_shift_bitan[p]
Patch3dShiftN[p]=pdu_shift_norm[p]
PatchNormalAxis[p]=pdu_norm_axis[p]
Orientation[p]=pdu_orientation_swap_flag[p]
PatchLod[p]=pdu_Iod[p]
ブロック1760において、フラグが復号されて、考慮すべきパッチがさらに存在するかどうかを判定する。一実施形態では、フラグはmore_patches_available_flagと指定される。ブロック1762において、フラグの値が決定される。フラグが第1の値(たとえば、1)を有するとき、プロセス1700はブロック1764に進む。ブロック1764において、復元されたパッチ情報データが記憶され、プロセス1700はブロック1702にループバックして、新しいパッチが復号されることができる。フラグが第2の値(たとえば、0)を有するとき、プロセス1700はブロック1742に進む。ブロック1742において、パッチタイプが最後のパッチタイプであるとき、符号化されたパッチ情報データに対応する復元プロセスが終了される。すなわち、復元プロセスが終了される。
ブロック1722において、パッチ用のパッチタイプがインターパッチタイプであるかどうかの判定が行われる。パッチ用のパッチタイプがインターパッチタイプであるとき、プロセス1700はブロック1724に進む。ブロック1724において、パッチに対応する基準パッチインデックス(dpdu_patch_index)が復号される。すなわち、基準パッチインデックスの値が復号される。ブロック1726において、パッチ用の基準インデックス(refIdx)が、パッチに対応する基準フレームインデックス([refFrmIdx])、および復号された基準パッチインデックスに基づいて決定される。
ブロック1728において、パッチに対応する2次元(2D)成分およびパッチに対応する3次元(3D)成分を使用してパッチが復号される。一実施形態では、パッチは以下に従って復号される。
復号演算:
d_u0(pdu_2d_shift_u)
d_u1(pdu_2d_shift_v)
d_size_u0(pdu_2d_delta_size_u)
d_size_v0(pdu_2d_delta_size_v)
d_u1(pdu_3d_shift_tangent_axis)
d_v1(pdu_3d_shift_bitangent_axis)
d_d1(pdu_3d_shift-normal_axis)
ブロック1730において、復号されたパッチに基づいてパッチが復元される。一実施形態では、パッチは以下に従って復元される。
復元:
Patch2dShiftU[p]=pdu_2d_shift_u[p]+
+Patch2dShiftU[refldx]
Patch2dShiftVf[p]=pdu_2d_shift_v[p]+
+Patch2dshiftV[refldx]
Patch2dsizeU[p]=pdu_2d_delta_size_u[p]+
+Patch2dSizeU[refldx]
Patch2dSizeV[p]=pdu_2d_delta_size_v[p]+
+Patch2dSizeV[refldx]
Patch3dShiftT[p]=pdu_3d_shift_tan[p]+
+Patch3dshiftT[refldx]
Patch3dShiftBT[p]=pdu_3d_shift_bitan[p]+
+patch3dshiftBT[refldx]
Patch3dShiftN[p]=pdu_shift_norm[p]+
+Patch3dShiftN[refldx]
PatchNormaIAxis[p]=PatchnormaIAxis[refldx]
Orientation[p]=Orientation[refldx]
PatchLod[p]=PatchLod[refldx]
ブロック1760において、フラグが復号されて、考慮すべきパッチがさらに存在するかどうかを判定する。一実施形態では、フラグはmore_patches_available_flagと指定される。ブロック1762において、フラグの値が決定される。フラグが第1の値(たとえば、1)を有するとき、プロセス1700はブロック1764に進む。ブロック1764において、復元されたパッチ情報データが記憶され、プロセス1700はブロック1702にループバックして、新しいパッチが復号されることができる。フラグが第2の値(たとえば、0)を有するとき、プロセス1700はブロック1742に進む。ブロック1742において、パッチタイプが最後のパッチタイプであるとき、符号化されたパッチ情報データに対応する復元プロセスが終了される。すなわち、復元プロセスが終了される。
ブロック1732において、パッチ用のパッチタイプがPCMパッチ(または未加工の)パッチタイプであるかどうかの判定が行われる。パッチ用のパッチタイプがPCMパッチタイプであるとき、プロセス1700はブロック1734に進む。ブロック1734において、パッチ用の基準インデックス(refIdx)が、パッチに対応するフレームインデックス([frmIdx])およびデクリメントされたパッチインデックスに基づいて決定される。
ブロック1736において、パッチに対応する2次元(2D)成分およびパッチに対応する3次元(3D)成分を使用してパッチが復号される。一実施形態では、2D成分および3D成分は以下を備える。
復号演算:
separate_video_flag(ppdu_patch…)
u0(ppdu_2d_shift_u)
u1(ppdu_2d_shift_y)
d_size_u0(ppdu_2d_delta_size_u)
d_sze_v0(ppdu_2d_delta_size_v)
PCM points(ppdu_pcm_points)
ブロック1738において、復号されたパッチに基づいてパッチが復元される。一実施形態では、パッチは以下に従って復元される。
復元:
Patch2dShiftU[p]=pdu_2d_shift_u[p]
Patch2dShiftV[p]=pdu_2d_shifty[p]
Patch2dSizeU[p]=pdu_2d_deltasize_u[p]+
+Patch2dSizeU[refIdx]
Patch2dSizeV[p]=pdu_2d_deIta_sizev[p]+
+Patch2dSizeV[refldx]
PatchPcmPoints[p]=ppdu_pcm_points[p]
ブロック1760において、フラグが復号されて、考慮すべきパッチがさらに存在するかどうかを判定する。一実施形態では、フラグはmore_patches_available_flagと指定される。ブロック1762において、フラグの値が決定される。フラグが第1の値(たとえば、1)を有するとき、プロセス1700はブロック1764に進む。ブロック1764において、復元されたパッチ情報データが記憶され、プロセス1700はブロック1702にループバックして、新しいパッチが復号されることができる。フラグが第2の値(たとえば、0)を有するとき、プロセス1700はブロック1742に進む。ブロック1742において、パッチタイプが最後のパッチタイプであるとき、符号化されたパッチ情報データに対応する復元プロセスが終了される。すなわち、復元プロセスが終了される。
図18は、デコーダ(たとえば、エントロピー復号ユニット70)によって実施されるPCCの方法1800の一実施形態である。方法1800は、立体画像を復元するために、符号化ビットストリームを復号するために使用されてもよい。ブロック1802において、デコーダの受信機が符号化されたパッチ情報データを受信する。符号化されたパッチ情報は、複数のパッチ(たとえば、パッチ502)に対応する情報を含んでもよい。ブロック1804において、デコーダのプロセッサが符号化されたパッチ情報データに対応するパッチを取得する。パッチはパッチタイプ(patch_mode)を有する。パッチタイプは、たとえば、スキップ、イントラ、インター、PCM、または最後であってもよい。
ブロック1806において、デコーダのプロセッサが、パッチ用のパッチタイプが最後のパッチタイプであるかどうかを判定する。ブロック1808において、デコーダのプロセッサが、パッチタイプが最後のパッチタイプであるとき、符号化されたパッチ情報データに対応する復元プロセスを終了する。
図19は、デコーダ(たとえば、エントロピー復号ユニット70)によって実施されるPCCの方法1900の一実施形態である。方法1900は、立体画像を復元するために、符号化ビットストリームを復号するために使用されてもよい。ブロック1902において、デコーダの受信機が符号化されたパッチ情報データを受信する。符号化されたパッチ情報は、複数のパッチ(たとえば、パッチ502)に対応する情報を含んでもよい。ブロック1904において、デコーダのプロセッサが符号化されたパッチ情報データに対応するパッチを取得する。パッチはパッチタイプ(patch_mode)を有する。パッチタイプは、たとえば、スキップ、イントラ、インター、PCM、または最後であってもよい。
ブロック1906において、デコーダのプロセッサが、パッチ用のパッチタイプがスキップパッチタイプであるかどうかを判定する。ブロック1908において、デコーダのプロセッサが、パッチタイプがスキップパッチタイプであるとき、パッチに対応する基準パッチインデックス(spdu_patch_index)を復号する。ブロック1910において、デコーダのプロセッサが、パッチに対応する基準フレームインデックス([refFrmIdx])、およびパッチタイプがスキップパッチタイプであるときに復号された基準パッチインデックスに基づいて、パッチ用の基準インデックス(refIdx)を決定する。ブロック1912において、デコーダのプロセッサが、パッチタイプがスキップパッチタイプであるときに決定された基準インデックスに基づいて、パッチの立体表現を復元する。復元されると、3D画像は、ユーザのために電子デバイス(たとえば、スマートフォン、タブレット、ラップトップコンピュータなど)のディスプレイに表示されてもよい。
図20は、デコーダ(たとえば、エントロピー復号ユニット70)によって実施されるPCCの方法2000の一実施形態である。方法2000は、立体画像を復元するために、符号化ビットストリームを復号するために使用されてもよい。ブロック2002において、デコーダの受信機が符号化されたパッチ情報データを受信する。符号化されたパッチ情報は、複数のパッチ(たとえば、パッチ502)に対応する情報を含んでもよい。ブロック2004において、デコーダのプロセッサが符号化されたパッチ情報データに対応するパッチを取得する。パッチはパッチタイプ(patch_mode)を有する。パッチタイプは、たとえば、スキップ、イントラ、インター、PCM、または最後であってもよい。
ブロック2006において、デコーダのプロセッサが、パッチ用のパッチタイプがスキップパッチタイプであるかどうかを判定する。ブロック2008において、デコーダのプロセッサが、パッチタイプがスキップパッチタイプであるとき、パッチに対応する基準パッチインデックス(spdu_patch_index)を復号する。ブロック2010において、デコーダのプロセッサが、パッチに対応する基準フレームインデックス([refFrmIdx])、およびパッチタイプがスキップパッチタイプであるときに復号された基準パッチインデックスに基づいて、パッチ用の基準インデックス(refIdx)を決定する。ブロック2012において、デコーダのプロセッサが、パッチタイプがスキップパッチタイプであるときに決定された基準インデックスに基づいて、パッチの立体表現を復元する。
ブロック2014において、デコーダのプロセッサが、より多くのパッチ利用可能フラグが第1の値を有するか、または第2の値を有するかを判定する。ブロック2016において、より多くのパッチ利用可能フラグが第1の値を有するとき、復元された立体表現がデコーダのメモリに記憶される。パッチのすべてが復元されると、3D画像は、ユーザのために電子デバイス(たとえば、スマートフォン、タブレット、ラップトップコンピュータなど)のディスプレイに表示されてもよい。
ブロック2018において、デコーダのプロセッサが、より多くのパッチ利用可能数フラグが第2の値を有するとき、符号化されたパッチ情報データの復元プロセスを終了する。
図21は、エンコーダ(たとえば、エントロピー符号化ユニット56)によって実施されるPCCの方法2100の一実施形態である。方法2100は、デコーダに向けて送信するために、立体画像をビットストリームの中に符号化するために実行されてもよい。ブロック2102において、エンコーダの受信機が、複数のパッチの各々についてパッチタイプ(pdfu_patch_mode)を識別するパッチフレームデータユニット(pfdu)を取得する。ブロック2104において、エンコーダのプロセッサが、複数のパッチからのパッチ用のパッチタイプが最後のパッチタイプであるかどうかを判定する。
ブロック2106において、エンコーダのプロセッサが、パッチタイプが最後のパッチタイプでないとき、パッチ用のパッチ情報データを符号化し、パッチ情報データはパッチ用のパッチタイプを含む。ブロック2108において、エンコーダのプロセッサが、パッチタイプが最後のパッチタイプに設定されたとき、パッチ用のパッチ情報データを符号化する。パッチ情報データはパッチ用の最後のパッチタイプを含む。
一実施形態では、パッチ情報データおよび最後のパッチタイプは、デコーダに向けて送信されるビットストリームの中に符号化される。
図22は、エンコーダ(たとえば、エントロピー符号化ユニット56)によって実施されるPCCの方法2200の一実施形態である。方法2200は、デコーダに向けて送信するために、立体画像をビットストリームの中に符号化するために実行されてもよい。ブロック2202において、エンコーダの受信機が、複数のパッチの各々についてパッチフレームデータユニット(pfdu)を取得する。ブロック2204において、エンコーダのプロセッサが、複数のパッチの各々に最後のパッチフラグを追加する。
ブロック2206において、エンコーダのプロセッサが、最後のパッチフラグの値に基づいて、複数のパッチからのパッチ用のパッチタイプが最後のパッチタイプであるかどうかを判定する。ブロック2208において、エンコーダのプロセッサが、パッチタイプが最後のパッチタイプでないとき、パッチ用のパッチ情報データを符号化し、パッチ情報データはパッチ用のパッチタイプおよび最後のパッチフラグを含む。
一実施形態では、パッチタイプおよび最後のパッチタイプを含むパッチ情報データは、デコーダに向けて送信されるビットストリームの中に符号化される。
図23は、本開示の一実施形態による、コーディングデバイス2300(たとえば、エンコーダ22、デコーダ28など)の概略図である。コーディングデバイス2300は、本明細書に開示された方法およびプロセスを実施するのに適している。コーディングデバイス2300は、データを受信するための入口ポート2310および受信機ユニット(Rx)2320と、データを処理するためのプロセッサ、論理ユニット、または中央処理装置(CPU)2330と、データを送信するための送信機ユニット(Tx)2340および出口ポート2350と、データを記憶するためのメモリ2360とを備える。コーディングデバイス2300はまた、光信号または電気信号の出入口のために、入口ポート2310、受信機ユニット2320、送信機ユニット2340、および出口ポート2350に結合された、光-電気(OE)構成要素および電気-光(EO)構成要素を備えてもよい。
プロセッサ2330は、ハードウェアおよびソフトウェアによって実装される。プロセッサ2330は、1つまたは複数のCPUチップ、コア(たとえば、マルチコアプロセッサとして)、フィールドプログラマブルゲートアレイ(FPGA)、特定用途向け集積回路(ASIC)、およびデジタル信号プロセッサ(DSP)として実装されてもよい。プロセッサ2330は、入口ポート2310、受信機ユニット2320、送信機ユニット2340、出口ポート2350、およびメモリ2360と通信する。プロセッサ2330はコーディングモジュール2370を備える。コーディングモジュール2370は、上述の開示された実施形態を実装する。一実施形態では、コーディングモジュール2370は、復元された立体画像を投影するように構成された復元モジュールである。したがって、コーディングモジュール2370を含めることにより、コーディングデバイス2300の機能に実質的な改善がもたらされ、コーディングデバイス2300の異なる状態への転換がもたらされる。あるいは、コーディングモジュール2370は、メモリ2360に記憶され、かつプロセッサ2330によって実行される命令として実装される。
コーディングデバイス2300はまた、ユーザとデータをやり取りするための入力および/または出力(I/O)デバイス2380を含んでもよい。I/Oデバイス2380は、ビデオデータを表示するためのディスプレイ、オーディオデータを出力するためのスピーカなどの出力デバイスを含んでもよい。I/Oデバイス2380はまた、キーボード、マウス、トラックボールなどの入力デバイス、および/またはそのような出力デバイスと対話するための対応するインターフェースを含んでもよい。
メモリ2360は、1つまたは複数のディスク、テープドライブ、およびソリッドステートドライブを備え、プログラムが実行のために選択されたときにそのようなプログラムを記憶し、かつプログラムの実行中に読み取られた命令およびデータを記憶するために、オーバーフローデータストレージデバイスとして使用されてもよい。メモリ2360は揮発性および不揮発性であってもよく、読取り専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、3値コンテンツアドレス可能メモリ(TCAM)、および静的ランダムアクセスメモリ(SRAM)であってもよい。
図24は、コーディングのための手段2400の一実施形態の概略図である。実施形態では、コーディングのための手段2400は、コーディングデバイス2402(たとえば、エンコーダ22またはデコーダ28)に実装される。コーディングデバイス2402は受信手段2401を含む。受信手段2401は、符号化するピクチャを受信するか、または復号するビットストリームを受信するように構成される。コーディングデバイス2402は、受信手段2401に結合された送信手段2407を含む。送信手段2407は、ビットストリームをデコーダに送信するか、または復号された画像を表示手段(たとえば、I/Oデバイス2380のうちの1つ)に送信するように構成される。
コーディングデバイス2402は記憶手段2403を含む。記憶手段2403は、受信手段2401または送信手段2407の少なくとも1つに結合される。記憶手段2403は命令を記憶するように構成される。コーディングデバイス2402は処理手段2405も含む。処理手段2405は記憶手段2403に結合される。処理手段2405は、本明細書に開示された方法を実行するために記憶手段2403に記憶された命令を実行するように構成される。
一実施形態では、本明細書に開示された概念を実装するのに適した構文が提供される。
パッチフレームデータユニット(pfdu)。一実施形態では、パッチフレームデータユニットの終端を示すために、特別な終端パッチデータユニットタイプが導入される。
Figure 0007267447000001
一実施形態では、パッチフレームデータユニットの終端を示すために、各パッチデータユニットに特別な1ビット(1ビット)フラグが追加される。
Figure 0007267447000002
一実施形態では、パッチ情報データは以下の通りである。
Figure 0007267447000003
一実施形態では、元のdelta_patch_data_unit構文要素は以下の通りである。
Figure 0007267447000004
一実施形態では、追加されたskip_patch_data_unit構文要素は以下の通りである。
Figure 0007267447000005
スキップパッチデータユニットタイプが導入されたので、コード化ビットストリーム表現におけるオーバーヘッドの量が削減される。
新たに追加された要素のセマンティクスは以下の通りである。
spdu_patch_index[frmIdx][p]プラスpは、基準パッチフレームリスト内の最初のパッチフレームに対応するインデックスRefIdxを有するパッチフレーム内のパッチのインデックスPredIdxを指定する。
スキップ予測モードでコード化されたパッチデータユニット用の復号プロセスは以下の通りである。pfdu_patch_mode[frmIdx][p]がP_SKIPに等しいとき、スキップコード化パッチデータユニットを復号するためのプロセスが使用され、frmIdxおよびpがそのプロセスへの入力として使用され、そのプロセスの出力(Patch2dShiftU、Patch2dShiftV、Patch2dSizeU、Patch2dSizeV、Patch3dShiftT、Patch3dShiftBT、Patch3dShiftN、PatchNormalAxis、Orientation、PatchLod)が出力として使用される。
上記から、パッチの向きは、デフォルトの投影プロセスに対して異なってもよいことが認識されるべきである。パッチの向きは、1ビットフラグを使用して簡略化された方式でシグナリングされてもよい。デフォルトの向きと好ましい向きとの間を切り替える機構が導入される。
本開示ではいくつかの実施形態が提供されているが、開示されたシステムおよび方法は、本開示の趣旨または範囲から逸脱することなく、多くの他の特定の形態で具現化されてもよいことが理解されよう。本開示の例は、限定ではなく例示とみなされるべきであり、その意図は、本明細書に与えられた詳細に限定されるべきではない。たとえば、様々な要素または構成要素が別のシステムにおいて結合もしくは統合されてもよく、または特定の機能が省略されるか、もしくは実装されなくてもよい。
加えて、様々な実施形態において個別または別個のものとして記載および例示された技法、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステム、構成要素、技法、または方法と結合または統合されてもよい。変更、代用、および改変の他の例は当業者によって解明可能であり、本明細書に開示された趣旨および範囲から逸脱することなく行われてもよい。
10 コーディングシステム
12 ソースデバイス、ビデオデバイス
14 宛先デバイス、ビデオデバイス
16 コンピュータ可読媒体
18 ビデオソース
20 投影デバイス
22 ビデオエンコーダ
24 出力インターフェース
26 入力インターフェース
28 ビデオデコーダ
30 復元デバイス
32 表示デバイス
40 モード選択ユニット
42 動き推定ユニット
44 動き補償ユニット
46 イントラ予測ユニット
48 分割ユニット
50 加算器
52 変換処理ユニット
54 量子化ユニット
56 エントロピーコーディングユニット
58 逆量子化ユニット
60 逆変換ユニット
62 加算器
64 基準フレームメモリ
70 エントロピー復号ユニット
72 動き補償ユニット
74 イントラ予測ユニット
76 逆量子化ユニット
78 逆変換ユニット
80 加算器
82 基準フレームメモリ
400 点群シーケンス
402 点群フレーム
404 点群フレーム
406 点群フレーム
408 点群
410 点群コンテンツ
412 3D空間
500 境界ボックス
502 パッチ
504 平面
600 境界ボックス
602 パッチ
610 占有マップ
612 幾何形状マップ
614 属性マップ
700 V-PCCビットストリーム
702 V-PCCユニット
704 V-PCCユニットヘッダ
706 V-PCCユニットペイロード
708 シーケンスパラメータセット
710 パッチシーケンスデータ
712 占有ビデオデータ
714 幾何形状ビデオデータ
716 属性ビデオデータ
720 シーケンスパラメータセット
722 フレームパラメータセット
724 幾何形状パラメータセット
726 属性パラメータセット
728 幾何形状パッチパラメータセット
730 属性パッチパラメータセット
732 パッチフレームデータユニット
734 パッチデータユニット
800 点群シーケンス
802 点群フレーム
810 点群コンテンツ
812 占有マップ
814 幾何形状マップ
816 属性マップ
850 補助情報パッチフレームデータユニット
900 パッチデータユニット
902 3D空間
1000 占有マップ
1002 幾何形状マップ
1004 属性マップ
1006 パッチ
1152 パッチデータユニット
1154 2D境界ボックス
1200 概略図
1202 点群3D境界ボックス
1204 パッチ3D境界ボックス
1206 投影面
1208 パッチ2D投影境界ボックス
1252 データセット図
1254 パッチデータユニット
1300 パッチフレームデータユニット符号化プロセス
1400 パッチフレームデータユニット符号化プロセス
1500 パッチ情報データフレーム
1502 基準パッチフレームデータユニット
1504 現在のパッチフレームデータユニット
1506 パッチ情報データユニット
1508 イントラパッチタイプデータユニット(pdu)
1510 PCMパッチタイプデータユニット(ppdu)
1512 インターパッチタイプデータユニット(dpdu)
1514 スキップパッチタイプデータユニット(spdu)
1600 パッチフレームデータユニット復号プロセス
1700 パッチフレームデータユニット復号プロセス
1800 デコーダによって実施されるPCCの方法
1900 デコーダによって実施されるPCCの方法
2000 デコーダによって実施されるPCCの方法
2100 エンコーダによって実施されるPCCの方法
2200 エンコーダによって実施されるPCCの方法
2300 コーディングデバイス
2310 入口ポート
2320 受信機ユニット(Rx)
2330 プロセッサ
2340 送信機ユニット(Tx)
2350 出口ポート
2360 メモリ
2370 コーディングモジュール
2380 入力および/または出力(I/O)デバイス
2400 コーディングのための手段
2401 受信手段
2402 ビデオコーディングデバイス
2403 記憶手段
2405 処理手段
2407 送信手段

Claims (16)

  1. デコーダによって実施される点群コーディング(PCC)の方法であって、
    前記デコーダにより、符号化されたパッチ情報データを受信するステップと、
    前記デコーダにより、前記符号化されたパッチ情報データに対応するパッチを取得するステップであって、前記パッチがパッチタイプ(patch_mode)を有する、ステップと、
    前記デコーダにより、前記パッチ用の前記パッチタイプが最後のパッチタイプであるかどうかを判定するステップと、
    前記デコーダにより、前記パッチタイプが前記最後のパッチタイプであるとき、前記符号化されたパッチ情報データに対応する復元プロセスを終了するステップと
    を備える、方法。
  2. デコーダによって実施される点群コーディング(PCC)の方法であって、
    前記デコーダにより、符号化されたパッチ情報データを受信するステップと、
    前記デコーダにより、前記符号化されたパッチ情報データに対応するパッチを取得するステップであって、前記パッチがパッチタイプ(patch_mode)を有する、ステップと、
    前記デコーダにより、前記パッチ用の前記パッチタイプがインターパッチタイプであると判定するステップと、
    前記デコーダにより、前記パッチに対応する第2の基準パッチインデックス(dpdu_patch_index)を復号するステップと、
    前記デコーダにより、前記パッチに対応する基準フレームインデックス([refFrmIdx])、および復号された前記第2の基準パッチインデックスに基づいて、前記パッチ用の基準インデックス(refIdx)を決定するステップと、
    前記デコーダにより、前記パッチに対応する2次元(2D)成分および前記パッチに対応する3次元(3D)成分を使用して前記パッチを復号するステップであって、前記2次元(2D)成分および前記3次元(3D)成分が、前記パッチ用の前記基準インデックス(refIdx)に基づいて取得される、ステップと、
    前記デコーダにより、復号された前記パッチに基づいて立体表現を復元するステップと
    を備える、方法。
  3. 前記パッチ用の前記パッチタイプがイントラパッチタイプであると判定するステップと、
    前記パッチに対応するフレームインデックス([frmIdx])およびデクリメントされたパッチインデックスに基づいて、前記パッチ用の前記基準インデックス(refIdx)を決定するステップと、
    前記パッチに対応する2次元(2D)成分および前記パッチに対応する3次元(3D)成分を使用して前記パッチを復号するステップと、
    復号された前記パッチに基づいて前記立体表現を復元するステップと
    をさらに備える、請求項2に記載の方法。
  4. 前記デコーダにより、前記パッチ用の前記パッチタイプがスキップパッチタイプであると判定するステップと、
    前記デコーダにより、前記パッチタイプが前記スキップパッチタイプであるとき、前記パッチに対応する基準パッチインデックス(spdu_patch_index)を復号するステップと、
    前記デコーダにより、前記パッチに対応する前記基準フレームインデックス([refFrmIdx])、および前記パッチタイプが前記スキップパッチタイプであるときに復号された前記基準パッチインデックスに基づいて、前記パッチ用の前記基準インデックス(refIdx)を決定するステップと、
    前記デコーダにより、前記パッチタイプが前記スキップパッチタイプであるときに決定された前記基準インデックスに基づいて、前記パッチの前記立体表現を復元するステップと
    をさらに備える、請求項2または3に記載の方法。
  5. 前記パッチ用の前記パッチタイプがパルスコード変調(PCM)パッチタイプであると判定するステップと、
    前記パッチに対応するフレームインデックス([frmIdx])およびデクリメントされたパッチインデックスに基づいて、前記パッチ用の前記基準インデックス(refIdx)を決定するステップと、
    前記パッチに対応する独立したポイント用の2次元(2D)成分および前記パッチに対応する前記独立したポイント用の3次元(3D)成分を使用して前記パッチを復号するステップと、
    復号された前記パッチに基づいて前記立体表現を復元するステップと
    をさらに備える、請求項2から4のいずれか一項に記載の方法。
  6. 前記符号化されたパッチ情報データに対応する入力を受信するステップであって、前記入力が、前記patch_mode、パッチインデックス、前記基準インデックス、フレームインデックス、および基準フレームインデックスのうちの1つまたは複数を備える、ステップをさらに備える、請求項2から5のいずれか一項に記載の方法。
  7. 復元された前記立体表現に基づいて生成された画像を電子デバイスのディスプレイに表示するステップをさらに備える、請求項2から6のいずれか一項に記載の方法。
  8. 前記デコーダにより、より多くのパッチ利用可能フラグが第1の値を有するか、または第2の値を有するかを判定するステップと、
    前記より多くのパッチ利用可能フラグが前記第1の値を有するとき、復元された前記立体表現を前記デコーダのメモリに記憶するステップと、
    前記デコーダにより、前記より多くのパッチ利用可能フラグが前記第2の値を有するとき、前記符号化されたパッチ情報データの復元プロセスを終了するステップと
    をさらに備える、請求項2から6のいずれか一項に記載の方法。
  9. エンコーダによって実施される点群コーディング(PCC)の方法であって、
    前記エンコーダにより、複数のパッチの各々についてパッチタイプ(pdfu_patch_mode)を識別するパッチフレームデータユニット(pfdu)を取得するステップと、
    前記エンコーダにより、前記複数のパッチからのパッチ用の前記パッチタイプが最後のパッチタイプであるかどうかを判定するステップと、
    前記エンコーダにより、前記パッチタイプが前記最後のパッチタイプでないとき、前記パッチ用のパッチ情報データを符号化するステップであって、前記パッチ情報データが前記パッチ用の前記パッチタイプを含む、ステップと、
    前記エンコーダにより、前記パッチタイプが前記最後のパッチタイプに設定されたとき、前記パッチ用の前記パッチ情報データを符号化するステップであって、前記パッチ情報データが前記パッチ用の前記最後のパッチタイプを含む、ステップと
    を備える、方法。
  10. 前記パッチタイプが、スキップパッチタイプ、インターパッチタイプ、イントラパッチタイプ、およびパルスコード変調(PCM)パッチタイプのうちの1つである、請求項9に記載の方法。
  11. 前記パッチフレームデータユニットが、フレームインデックス(frmIdx)、前記パッチに対応する2次元(2D)成分、および前記パッチに対応する3次元(3D)成分を含む、請求項9または10に記載の方法。
  12. 前記パッチ情報データが、フレームインデックス、前記パッチに対応する2次元(2D)成分、および前記パッチに対応する3次元(3D)成分を含む、請求項9から11のいずれか一項に記載の方法。
  13. 前記パッチタイプが前記最後のパッチタイプであるかどうかを判定する前記ステップ、および前記複数のパッチからの前記パッチのうちの1つが前記最後のパッチタイプを有すると判定されるまで、前記複数のパッチからの後続のパッチ用の前記パッチ情報データを符号化する前記ステップを反復するステップをさらに備える、請求項9から12のいずれか一項に記載の方法。
  14. 復号デバイスであって、
    符号化されたパッチ情報データを受信するように構成された受信機と、
    前記受信機に結合されたメモリであって、前記メモリが命令を記憶する、メモリと、
    前記メモリに結合されたプロセッサであって、前記プロセッサが、
    前記符号化されたパッチ情報データに対応するパッチを取得し、前記パッチがパッチタイプ(patch_mode)を有し、
    前記パッチ用の前記パッチタイプが最後のパッチタイプであるかどうかを判定し、
    前記パッチタイプが前記最後のパッチタイプであるとき、前記符号化されたパッチ情報データに対応する復元プロセスを終了する
    ことを前記復号デバイスに行わせる前記命令を実行するように構成される、プロセッサと
    を備える、復号デバイス。
  15. 復号デバイスであって、
    符号化されたパッチ情報データを受信するように構成された受信機と、
    前記受信機に結合されたメモリであって、前記メモリが命令を記憶する、メモリと、
    前記メモリに結合されたプロセッサであって、前記プロセッサが、請求項2から8のいずれか一項に記載の方法を前記復号デバイスに実行させる前記命令を実行するように構成される、プロセッサと
    を備える、復号デバイス。
  16. 符号化デバイスであって、
    3次元(3D)画像を受信するように構成された受信機と、
    前記受信機に結合されたメモリであって、前記メモリが命令を含む、メモリと、
    前記メモリに結合されたプロセッサであって、前記プロセッサが、請求項9から13のいずれか一項に記載の方法を前記符号化デバイスに実行させる前記命令を実施するように構成される、プロセッサと
    を備える、符号化デバイス。
JP2021555263A 2019-03-12 2020-03-12 点群コーディングのためのパッチデータユニットのコーディングおよび復号 Active JP7267447B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2023068788A JP2023089230A (ja) 2019-03-12 2023-04-19 点群コーディングのためのパッチデータユニットのコーディングおよび復号

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201962817391P 2019-03-12 2019-03-12
US62/817,391 2019-03-12
PCT/US2020/022395 WO2020186060A1 (en) 2019-03-12 2020-03-12 Patch data unit coding and decoding for point-cloud data

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2023068788A Division JP2023089230A (ja) 2019-03-12 2023-04-19 点群コーディングのためのパッチデータユニットのコーディングおよび復号

Publications (2)

Publication Number Publication Date
JP2022525599A JP2022525599A (ja) 2022-05-18
JP7267447B2 true JP7267447B2 (ja) 2023-05-01

Family

ID=72427656

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2021555263A Active JP7267447B2 (ja) 2019-03-12 2020-03-12 点群コーディングのためのパッチデータユニットのコーディングおよび復号
JP2023068788A Pending JP2023089230A (ja) 2019-03-12 2023-04-19 点群コーディングのためのパッチデータユニットのコーディングおよび復号

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2023068788A Pending JP2023089230A (ja) 2019-03-12 2023-04-19 点群コーディングのためのパッチデータユニットのコーディングおよび復号

Country Status (8)

Country Link
US (1) US12002243B2 (ja)
EP (1) EP3932067A4 (ja)
JP (2) JP7267447B2 (ja)
KR (1) KR20210134391A (ja)
CN (2) CN113906757B (ja)
BR (1) BR112021018025A2 (ja)
SG (1) SG11202109967SA (ja)
WO (1) WO2020186060A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022061785A1 (zh) * 2020-09-25 2022-03-31 Oppo广东移动通信有限公司 点云编码方法、点云解码方法及相关装置
WO2023201450A1 (zh) * 2022-04-17 2023-10-26 Oppo广东移动通信有限公司 编解码方法、码流、编码器、解码器以及存储介质
WO2024077637A1 (zh) * 2022-10-14 2024-04-18 浙江大学 一种编解码方法、装置、编码器、解码器及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018130491A1 (en) 2017-01-13 2018-07-19 Thomson Licensing Method, apparatus and stream for immersive video format
US20180268570A1 (en) 2017-03-16 2018-09-20 Samsung Electronics Co., Ltd. Point cloud and mesh compression using image/video codecs
WO2019055963A1 (en) 2017-09-18 2019-03-21 Apple Inc. COMPRESSION OF CLOUD OF POINTS
WO2019142666A1 (ja) 2018-01-16 2019-07-25 ソニー株式会社 画像処理装置および方法
WO2020148603A1 (en) 2019-01-18 2020-07-23 Sony Corporation Point cloud coding using homography transform

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6215910B1 (en) * 1996-03-28 2001-04-10 Microsoft Corporation Table-based compression with embedded coding
US6499060B1 (en) * 1999-03-12 2002-12-24 Microsoft Corporation Media coding for loss recovery with remotely predicted data units
US7724827B2 (en) * 2003-09-07 2010-05-25 Microsoft Corporation Multi-layer run level encoding and decoding
US10607408B2 (en) * 2016-06-04 2020-03-31 Shape Labs Inc. Method for rendering 2D and 3D data within a 3D virtual environment
EP3418976A1 (en) * 2017-06-22 2018-12-26 Thomson Licensing Methods and devices for encoding and reconstructing a point cloud
US11113845B2 (en) * 2017-09-18 2021-09-07 Apple Inc. Point cloud compression using non-cubic projections and masks
US10424083B2 (en) * 2017-10-21 2019-09-24 Samsung Electronics Co., Ltd. Point cloud compression using hybrid transforms
US11012713B2 (en) * 2018-07-12 2021-05-18 Apple Inc. Bit stream structure for compressed point cloud data

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018130491A1 (en) 2017-01-13 2018-07-19 Thomson Licensing Method, apparatus and stream for immersive video format
US20180268570A1 (en) 2017-03-16 2018-09-20 Samsung Electronics Co., Ltd. Point cloud and mesh compression using image/video codecs
WO2019055963A1 (en) 2017-09-18 2019-03-21 Apple Inc. COMPRESSION OF CLOUD OF POINTS
WO2019142666A1 (ja) 2018-01-16 2019-07-25 ソニー株式会社 画像処理装置および方法
WO2020148603A1 (en) 2019-01-18 2020-07-23 Sony Corporation Point cloud coding using homography transform

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Vida Fakour Sevom et al.,Geometry-Guided 3D Data Interpolation for Projection-Based Dynamic Point Cloud Coding,2018 7th European Workshop on Visual Information Processing (EUVIP),IEEE,2018年11月26日,pp.1-6
V-PCC Codec Description,ISO/IEC JTC 1/SC 29/WG 11,N 18892,2019年11月13日,pp.1-65

Also Published As

Publication number Publication date
CN113906757A (zh) 2022-01-07
BR112021018025A2 (pt) 2021-11-23
EP3932067A4 (en) 2022-08-24
CN113906757B (zh) 2023-02-03
EP3932067A1 (en) 2022-01-05
SG11202109967SA (en) 2021-10-28
WO2020186060A1 (en) 2020-09-17
KR20210134391A (ko) 2021-11-09
JP2023089230A (ja) 2023-06-27
US12002243B2 (en) 2024-06-04
JP2022525599A (ja) 2022-05-18
US20210398324A1 (en) 2021-12-23
CN116156192A (zh) 2023-05-23

Similar Documents

Publication Publication Date Title
JP7116199B2 (ja) 点群符号化用の高レベルな構文設計
WO2019199415A1 (en) Differential coding method for patch side information
JP2023123508A (ja) ポイントクラウドコーディングにおける改善された属性レイヤとシグナリング
JP7402884B2 (ja) 点群コーディングにおける効率的なパッチ回転
US12002243B2 (en) Patch data unit coding and decoding for point-cloud coding
WO2020146341A1 (en) Point cloud bitstream structure and auxiliary information differential coding
JP7477687B2 (ja) ビデオコーディングのための変換ユニット区分方法
JP2023509513A (ja) 点群コーディングにおけるカメラパラメータのシグナリング
WO2020061149A1 (en) Patch orientation derivation and prediction

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211020

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20211020

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20221111

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20221121

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230221

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230320

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230419

R150 Certificate of patent or registration of utility model

Ref document number: 7267447

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150