Advanced syntax design for geometry-based point cloud compression

Abstract

An example device for decoding point cloud data includes a memory configured to store the point cloud data and one or more processors implemented in circuitry and coupled to the memory. The one or more processors are configured to determine a size of a region box and determine a size of a slice boundary box. The one or more processors are further configured to decode a slice of the point cloud data associated with the slice boundary box. The size of the region box is limited to not exceed the size of the slice boundary box.

Description

[0001] This application claims priority to the following applications: U.S. Application No. 17 / 223,789, filed April 6, 2021; U.S. Provisional Patent Application No. 63 / 006,660, filed April 7, 2020; U.S. Provisional Patent Application No. 63 / 010,550, filed April 15, 2020; and U.S. Provisional Patent Application No. 63 / 013,971, filed April 22, 2020, the entire contents of each of these applications are incorporated herein by reference. U.S. Application No. 17 / 223,789, filed April 6, 2021, claims the benefits of the following applications: U.S. Provisional Patent Application No. 63 / 006,660, filed April 7, 2020; U.S. Provisional Patent Application No. 63 / 010,550, filed April 15, 2020; and U.S. Provisional Patent Application No. 63 / 013,971, filed April 22, 2020. Technical Field

[0002] This disclosure pertains to point cloud encoding and decoding. Summary of the Invention

[0003] This disclosure typically describes some techniques for designing high-level syntaxes for geometry-based point cloud compression (G-PCC). These techniques can address several potential problems in G-PCC decoding.

[0004] In one example, this disclosure describes a method for decoding point cloud data, the method comprising: determining the size of a region box; determining the size of a slice bounding box; and decoding a slice of the point cloud data associated with the slice bounding box, wherein the size of the region box is limited to not exceeding the size of the slice bounding box.

[0005] In another example, this disclosure describes a method for decoding point cloud data, the method comprising: determining a first slice identifier (ID) of a first geometric slice associated with a frame of the point cloud data; determining a second slice ID of a second geometric slice associated with the frame of the point cloud data; determining that the second slice contains the same content as the first slice based on the second slice ID being equal to the first slice ID; and decoding the point cloud data based on the first slice ID.

[0006] In another example, this disclosure describes a method for decoding point cloud data, the method comprising: determining whether an attribute dimension is greater than 1; parsing an attribute slice header syntax element indicating an incremental quantization parameter based on the attribute dimension being greater than 1; and decoding the point cloud data based on the incremental quantization parameter.

[0007] In another example, this disclosure describes an apparatus including a memory configured to store point cloud data, and one or more processors implemented using circuitry and communicating with the memory, the one or more processors being configured to: determine the size of a region box; determine the size of a slice bounding box; and decode a slice of the point cloud data associated with the slice bounding box, wherein the size of the region box is limited to not exceeding the size of the slice bounding box.

[0008] In another example, this disclosure describes an apparatus including a memory configured to store point cloud data, and one or more processors implemented using circuitry and communicating with the memory, the one or more processors being configured to: determine a first slice identifier (ID) of a first geometric slice associated with a frame of the point cloud data; determine a second slice ID of a second geometric slice associated with the frame of the point cloud data; determine that the second slice contains the same content as the first slice based on the second slice ID being equal to the first slice ID; and decode the point cloud data based on the first slice ID.

[0009] In another example, this disclosure describes an apparatus including a memory configured to store point cloud data, and one or more processors implemented using circuitry and communicating with the memory, the one or more processors being configured to: determine whether an attribute dimension of an attribute is greater than 1; parse attribute slice header syntax elements indicating incremental quantization parameters based on the attribute dimension being greater than 1; and decode the point cloud data based on the incremental quantization parameters.

[0010] Details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will become apparent from the description, drawings, and claims. Attached Figure Description

[0011] Figure 1 This is a block diagram illustrating an example encoding and decoding system that can perform the techniques described in this disclosure.

[0012] Figure 2 This is a block diagram illustrating an example geometric point cloud compression (G-PCC) encoder.

[0013] Figure 3 This is a block diagram showing an example G-PCC decoder.

[0014] Figure 4 This is a conceptual diagram illustrating the example Level of Detail (LoD) generation process.

[0015] Figure 5 This is a conceptual diagram illustrating possible point predictions using LoD (LoD).

[0016] Figure 6 This is a conceptual diagram illustrating an example of G-PCC decoding with different LoDs.

[0017] Figure 7 This is a flowchart of example region boxes and slice bounding box techniques based on the present disclosure.

[0018] Figure 8 This is a flowchart illustrating an example slice identifier technique based on the content of this disclosure.

[0019] Figure 9 This is a flowchart illustrating an example of an incremental quantization parameter technique according to this disclosure. Detailed Implementation

[0020] In some draft standards for geometry-based point cloud compression (G-PCC), there may be high-level syntactic issues. For example, the size of a region bounding box may exceed the size of the slice containing that region. In such cases, signaling the region's width, height, and depth, which may exceed the slice size, may not add value because there are no points in the slice that extend beyond the slice's bounding box. This can unnecessarily increase signaling overhead and waste the processing power of the G-PCC encoder and decoder.

[0021] In another example, there may be no limit to the range of the syntax element indicating the size of the trisoup node. When this syntax element exceeds the size of the slice, this could result in a negative value for the variable indicating the maximum geometric octree depth, which is likely undesirable as it could lead to decoding errors.

[0022] In another example, there are no restrictions on the slice IDs that can be assigned to geometric slices. For example, two different geometric slices in a point cloud frame can be assigned the same slice ID, even if they contain different content. This is likely undesirable, as it can lead to ambiguity that causes decoding errors.

[0023] In another example, some parameters are not applicable to one-dimensional properties. However, these parameters may still exist and may still need to be signaled. This could lead to an unnecessary increase in signaling overhead and waste the processing power of the G-PCC encoder and decoder.

[0024] In another example, each slice might only be able to specify one region where incremental quantization parameters can be applied. It might be more desirable to have the flexibility to have several regions where incremental quantization parameters can be applied. Having only the ability to specify a single region where incremental quantization parameters can be applied may limit the options for encoding the point cloud in an efficient manner and / or in a way that takes into account the perceptual quality of the point cloud.

[0025] In another example, the range of values ​​for the geometry parameter set ID in the geometry slice header can be unlimited, while the range of values ​​for the geometry parameter set ID within the geometry parameter set can be limited. If the value of the geometry parameter set ID in the geometry slice header is greater than the value of the geometry parameter set ID within the geometry parameter set, this can lead to an unnecessary increase in signaling overhead and waste of the processing power of the G-PCC encoder and decoder. This situation can also cause ambiguity that results in decoding errors.

[0026] In another example, the range of values ​​for the attribute parameter set ID in the attribute slice header can be unlimited, while the range of values ​​for the attribute parameter set ID in the attribute parameter set can be limited. If the value of the attribute parameter set ID in the attribute slice header is greater than the value of the attribute parameter set ID in the attribute parameter set, this can lead to an unnecessary increase in signaling overhead and waste the processing power of the G-PCC encoder and decoder. This situation can also cause ambiguity that results in decoding errors.

[0027] According to the techniques disclosed herein, the aforementioned and other problems in high-level syntax design with G-PCC decoding can be solved as discussed in more detail below. By solving these problems, signaling overhead can be reduced, processing power can be saved, decoding errors can be reduced, and / or better point cloud reconstruction can be achieved at the decoder.

[0028] Figure 1 This is a block diagram illustrating an example encoding and decoding system 100 capable of implementing the techniques of this disclosure. The techniques of this disclosure are generally directed to the decoding (encoding and / or decoding) of point cloud data. Typically, point cloud data includes any data used for processing the point cloud. Such encoding can efficiently compress and / or decompress point cloud data.

[0029] like Figure 1 As shown, system 100 includes a source device 102 and a destination device 116. Source device 102 provides encoded point cloud data to be decoded by destination device 116. Specifically, in Figure 1In this example, source device 102 provides point cloud data to destination device 116 via computer-readable medium 110. Source device 102 and destination device 116 can include any of a wide range of devices, including desktop computers, notebook (e.g., laptop) computers, tablet computers, set-top boxes, handset phones (e.g., smartphones), televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, land or sea vehicles, spacecraft, aircraft, robots, lidar devices, satellites, and so on. In some cases, source device 102 and destination device 116 may be equipped for wireless communication.

[0030] exist Figure 1 In the example, source device 102 includes a data source 104, a memory 106, a G-PCC encoder 200, and an output interface 108. Destination device 116 includes an input interface 122, a G-PCC decoder 300, a memory 120, and a data consumer 118. According to this disclosure, the G-PCC encoder 200 of source device 102 and the G-PCC decoder 300 of destination device 116 can be configured to apply the high-level grammar-related techniques of geometry-based point cloud compression of this disclosure. Therefore, source device 102 represents an example of an encoding device, and destination device 116 represents an example of a decoding device. In other examples, source device 102 and destination device 116 may include other components or arrangements. For example, source device 102 may receive data (e.g., point cloud data) from an internal or external source. Similarly, destination device 116 may interface with an external data consumer, rather than including the data consumer in the same device.

[0031] like Figure 1 The system 100 shown is merely an example. Typically, other digital encoding and / or decoding devices can perform the high-level syntax-related techniques of this disclosure for geometric point cloud compression. Source device 102 and destination device 116 are merely examples of such devices, where source device 102 generates encoded data for transmission to destination device 116. This disclosure refers to a “decoding” device as a device that performs the decoding (encoding and / or decoding) of data. Thus, G-PCC encoder 200 and G-PCC decoder 300 represent examples of decoding devices (specifically, encoder and decoder). In some examples, source device 102 and destination device 116 can operate in a substantially symmetrical manner, such that each of source device 102 and destination device 116 includes both encoding and decoding components. Therefore, system 100 can support unidirectional or bidirectional transmission between source device 102 and destination device 116, for example, for streaming, playback, broadcasting, telephone, navigation, and other applications.

[0032] Typically, data source 104 represents the source of data (i.e., raw, unencoded point cloud data) and provides a continuous sequence of "frames" of data to G-PCC encoder 200, which encodes the data in the frames. Data source 104 of source device 102 may include point cloud capture devices, such as any of a variety of cameras or sensors (e.g., 3D scanners or light detection and ranging (LIDAR) devices), one or more video cameras, archives containing previously captured data, and / or data feed interfaces for receiving data from content providers. Alternatively or additionally, point cloud data may be computer data or other data generated from scanners, cameras, sensors, etc. For example, data source 104 may generate computer graphics-based data as source data, or a combination of real-time data, archived data, and computer-generated data. In each case, G-PCC encoder 200 encodes the captured, pre-captured, or computer-generated data. G-PCC encoder 200 may rearrange frames from the received order (sometimes referred to as "display order") to a decoding order for decoding. The G-PCC encoder 200 can generate one or more bit streams containing encoded data. The source device 102 can then output the encoded data to a computer-readable medium 110 via the output interface 108 for reception and / or retrieval via, for example, the input interface 122 of the destination device 116.

[0033] The memory 106 of source device 102 and the memory 120 of destination device 116 can represent general-purpose memory. In some examples, memory 106 and memory 120 can store raw data, such as raw data from data source 104 and raw decoded data from G-PCC decoder 300. Alternatively or additionally, memory 106 and memory 120 can store software instructions executable by, for example, G-PCC encoder 200 and G-PCC decoder 300 respectively. Although in this example memory 106 and memory 120 are shown separately from G-PCC encoder 200 and G-PCC decoder 300, it should be understood that G-PCC encoder 200 and G-PCC decoder 300 may also include internal memory for functionally similar or equivalent purposes. Furthermore, memory 106 and memory 120 can store encoded data (e.g., output from G-PCC encoder 200 and input to G-PCC decoder 300). In some examples, portions of memory 106 and memory 120 may be allocated as one or more buffers, for example, to store raw, decoded, and / or encoded data. For instance, memory 106 and memory 120 may store data representing point clouds.

[0034] Computer-readable medium 110 can represent any type of medium or device capable of transmitting encoded data from source device 102 to destination device 116. In one example, computer-readable medium 110 represents a communication medium enabling source device 102 to transmit encoded data directly to destination device 116 in real time, for example, via a radio frequency network or a computer-based network. Output interface 108 can modulate the transmitted signal, including the encoded data, according to a communication standard such as a wireless communication protocol, and input interface 122 can demodulate the received transmitted signal. The communication medium can include any wireless or wired communication medium, such as radio frequency (RF) spectrum or one or more physical transmission lines. The communication medium can form part of a packet-based network such as a local area network, wide area network, or global network (e.g., the Internet). The communication medium can include a router, switch, base station, or any other device that facilitates communication from source device 102 to destination device 116.

[0035] In some examples, source device 102 can output encoded data from output interface 108 to storage device 112. Similarly, destination device 116 can access encoded data from storage device 112 via input interface 122. Storage device 112 may include any of a variety of distributed or locally accessed data storage media (e.g., hard disk drives, Blu-ray discs, DVDs, CD-ROMs, flash memory, volatile or non-volatile memory) or any other suitable digital storage media for storing encoded data.

[0036] In some examples, source device 102 may output encoded data to file server 114 or another intermediate storage device that may store the encoded data generated by source device 102. Destination device 116 may access the stored data from file server 114 via streaming or downloading. File server 114 may be any type of server device capable of storing encoded data and sending such encoded data to destination device 116. File server 114 may represent a web server (e.g., for a website), a file transfer protocol (FTP) server, a content delivery network device, or a network attached storage (NAS) device. Destination device 116 may access the encoded data from file server 114 via any standard data connection including an internet connection. This may include a wireless channel (e.g., a Wi-Fi connection), a wired connection (e.g., a digital subscriber line (DSL), a cable modem, etc.), or a combination thereof, suitable for accessing encoded data stored on file server 114. File server 114 and input interface 122 may be configured to operate according to a streaming protocol, a download transfer protocol, or a combination thereof.

[0037] Output interface 108 and input interface 122 can represent a wireless transmitter / receiver, a modem, a wired network component (e.g., an Ethernet card), a wireless communication component operating according to any of the various IEEE 802.11 standards, or other physical components. In examples where output interface 108 and input interface 122 include wireless components, output interface 108 and input interface 122 can be configured to transmit data such as encoded data according to cellular communication standards such as 4G, 4G-LTE (Long Term Evolution), Advanced LTE, 5G, etc. In some examples where output interface 108 includes a wireless transmitter, output interface 108 and input interface 122 can be configured according to other wireless standards (e.g., the IEEE 802.11 specification, the IEEE 802.15 specification (e.g., ZigBee)). TM Bluetooth TM Standards, etc., are used to transmit data such as encoded data. In some examples, source device 102 and / or destination device 116 may include their respective system-on-chip (SoC) devices. For example, source device 102 may include an SoC device to perform functions belonging to G-PCC encoder 200 and / or output interface 108, while destination device 116 may include an SoC device to perform functions belonging to G-PCC decoder 300 and / or input interface 122.

[0038] The technology disclosed herein can be applied to encoding and decoding for any of a variety of applications, such as communication between autonomous vehicles, communication between scanners, cameras, sensors and processing devices (such as local or remote servers), geographic mapping, or other applications.

[0039] The input interface 122 of the destination device 116 receives an encoded bitstream from a computer-readable medium 110 (e.g., a communication medium, storage device 112, file server 114, etc.). The encoded bitstream may include signaling information defined by the G-PCC encoder 200 and used by the G-PCC decoder 300, such as syntax elements having values ​​describing the characteristics and / or processing of the decoding unit (e.g., a fragment, a picture, a group of pictures, a sequence, etc.). The data consumer 118 uses the decoded data. For example, the data consumer 118 may use the decoded data to determine the location of a physical object. In some examples, the data consumer 118 may include a display to present an image based on a point cloud.

[0040] The G-PCC encoder 200 and G-PCC decoder 300 can each be implemented as any of a variety of suitable encoder and / or decoder circuits, such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware, or any combination thereof. When these techniques are implemented in part in software, the device may store instructions for software in a suitable non-transitory computer-readable medium and execute these instructions in hardware using one or more processors to perform the techniques of this disclosure. Each of the G-PCC encoder 200 and G-PCC decoder 300 may be included in one or more encoders or decoders, and any one of the encoders or decoders may be integrated as part of a combined encoder / decoder (CODEC) in the respective device. Devices including the G-PCC encoder 200 and / or G-PCC decoder 300 may include one or more integrated circuits, microprocessors, and / or other types of devices.

[0041] The G-PCC encoder 200 and G-PCC decoder 300 can operate according to decoding standards such as the Video Point Cloud Compression (V-PCC) standard or the Geometric Point Cloud Compression (G-PCC) standard. This disclosure generally relates to the decoding (e.g., encoding and decoding) of images, including the process of encoding or decoding data. The encoded bitstream typically includes a series of values ​​for syntax elements representing decoding decisions (e.g., decoding modes).

[0042] This disclosure generally relates to "signaling" certain information (e.g., syntax elements). The term "signaling" can generally refer to transmitting values ​​for syntax elements and / or other data for decoding encoded data. That is, the G-PCC encoder 200 can signal values ​​for syntax elements in the bitstream. Typically, signaling refers to generating values ​​in the bitstream. As described above, the source device 102 can transmit the bitstream to the destination device 116 substantially in real time or not in real time, for example, when storing syntax elements in storage device 112 for later retrieval by the destination device 116.

[0043] ISO / IEC MPEG (JTC 1 / SC 29 / WG 11) is investigating the potential need to standardize point cloud coding techniques that offer significantly greater compression capabilities than current methods and will work towards creating a standard. This exploration is being conducted within a collaborative effort known as the 3D Graphics Group (3DG) to evaluate compression technology designs proposed by their experts in the field.

[0044] Point cloud compression activities can be categorized into two distinct approaches. The first approach is “Video Point Cloud Compression” (V-PCC), which segments a 3D object and projects these segments onto multiple 2D planes (represented as “patches” in a 2D frame), then further decodes these 2D planes using a traditional 2D video codec such as the High Efficiency Video Coding (HEVC) (ITU-T H.265) codec. The second approach is “Geometry-Based Point Cloud Compression” (G-PCC), which directly compresses the 3D geometry (i.e., the positions of a set of points in 3D space) and the associated attribute values ​​(for each point associated with the 3D geometry). G-PCC addresses point cloud compression in categories 1 (static point clouds) and 3 (dynamically acquired point clouds). The latest draft of the G-PCC standard can be found in G-PCC DIS, ISO / IEC JTC1 / SC29 / WG11 w19088, published in Brussels, Belgium in January 2020, and the codec description can be found in G-PCC codec specification v6, ISO / IEC JTC1 / SC29 / WG11w19091, published in Brussels, Belgium in January 2020.

[0045] A point cloud contains a set of points in 3D space and may have properties associated with those points. These properties can be color information such as R, G, B or Y, Cb, Cr, or reflection information, or other properties. Point clouds can be captured by various cameras or sensors (e.g., LiDAR sensors and 3D scanners) or can be computer-generated. Point cloud data is used in a wide variety of applications, including but not limited to: architecture (modeling), graphics (3D models for visualization and animation), and the automotive industry (LiDAR sensors for navigation aids).

[0046] The 3D space occupied by point cloud data can be enclosed by virtual bounding boxes. The positions of points within the bounding box can be represented with a certain precision; therefore, the positions of one or more points can be quantized based on this precision. At the smallest level, the bounding box is divided into voxels, the smallest spatial unit represented by a unit cube. A voxel within the bounding box can be associated with zero, one, or more points. The bounding box can be divided into multiple cubic / cuboid regions, which can be called tiles. Each tile can be decoded into one or more slices. Dividing the bounding box into slices and tiles can be based on the number of points in each division, or on other considerations (e.g., decoding a specific region into a tile). Slice regions can be further subdivided using a splitting decision similar to that in video codecs.

[0047] Figure 2 An overview of the G-PCC encoder 200 is provided. Figure 3An overview of the G-PCC decoder 300 is provided. The modules shown are logical and do not necessarily correspond one-to-one with the implementation code in the reference implementation of the G-PCC codec (i.e., the TMC13 test model software studied by ISO / IEC MPEG (JTC 1 / SC 29 / WG 11)).

[0048] In both the G-PCC encoder 200 and the G-PCC decoder 300, the point cloud locations are decoded first. Attribute decoding depends on the decoded geometry. Figure 2 and Figure 3 In the diagram, the gray shading module is the option typically used for Category 1 data. The diagonal crosshair module is the option typically used for Category 3 data. All other modules are interchangeable between Category 1 and Category 3.

[0049] For Category 3 data, the compressed geometry is typically represented as an octree at the leaf level, descending from the root down to individual voxels. For Category 1 data, the compressed geometry is typically represented by a pruned octree (i.e., an octree at the leaf level, descending from the root down to blocks larger than voxels) plus a model that approximates the surface within each leaf of the pruned octree. In this way, both Category 1 and Category 3 data share the octree decoding mechanism, while Category 1 data can also use a surface model to approximate the voxels within each leaf. The surface model used is a triangulation of 1-10 triangles per block, forming a triangular soup. Therefore, the Category 1 geometry codec is called the Trisoup geometry codec, while the Category 3 geometry codec is called the octree geometry codec.

[0050] At each node in the octree, occupancy is signaled (when not inferred) for one or more of its child nodes (up to eight nodes). Multiple neighborhoods are specified, including: (a) nodes sharing a face with the current octree node, (b) nodes sharing a face, edge, or vertex with the current octree node, and so on. Within each neighborhood, the occupancy of a node and / or its child nodes can be used to predict the occupancy of the current node or its child nodes. For points sparsely filled in some nodes of the octree, the codec also supports a direct decoding mode, where the 3D position of the point is directly encoded. A signaling flag can be sent to indicate the direct signaling mode. At the lowest level, the number of points associated with an octree node / leaf node can also be decoded.

[0051] Once the geometry is decoded, the attributes corresponding to the geometric points are also decoded. When a reconstructed / decoded geometric point corresponds to multiple attribute points, the attribute values ​​representing the reconstructed point can be derived.

[0052] There are three attribute decoding methods in G-PCC: Region Adaptive Hierarchical Transform (RAHT) decoding, interpolation-based hierarchical nearest neighbor prediction (prediction transform), and interpolation-based hierarchical nearest neighbor prediction (lifting transform) with update / lifting steps. RAHT and Lifting are typically used for Class 1 data, while prediction is typically used for Class 3 data. However, any method can be used for any data, and similar to the geometry codec in G-PCC, the attribute decoding method used for decoding the point cloud is specified in the bitstream.

[0053] Attribute decoding can be performed at the level of detail (LOD), where a more refined representation of the point cloud attributes can be obtained for each LOD. Each LOD can be specified based on a distance metric to neighboring nodes or based on the sampling distance.

[0054] At the G-PCC encoder 200, the residuals obtained from the output of the decoding method, which is an attribute, are quantized. Context-adaptive arithmetic decoding can be used to decode the quantized residuals.

[0055] exist Figure 2 In the example, the G-PCC encoder 200 may include a coordinate transformation unit 202, a color transformation unit 204, a voxelization unit 206, an attribute transfer unit 208, an octree analysis unit 210, a surface approximation analysis unit 212, an arithmetic coding unit 214, a geometric reconstruction unit 216, a RAHT unit 218, a LOD generation unit 220, a lifting unit 222, a coefficient quantization unit 224, and an arithmetic coding unit 226.

[0056] like Figure 2 As shown in the example, the G-PCC encoder 200 can receive a set of locations and a set of attributes. These locations can include the coordinates of points in the point cloud. These attributes can include information about the points in the point cloud, such as the colors associated with those points.

[0057] The coordinate transformation unit 202 can apply transformations to the coordinates of a point to transform the coordinates from the initial domain to the transformation domain. The transformed coordinates can be referred to as transformed coordinates. The color transformation unit 204 can apply transformations to transform the color information of an attribute to different domains. For example, the color transformation unit 204 can transform color information from the RGB color space to the YCbCr color space.

[0058] In addition, Figure 2In the example, voxelization unit 206 can voxelize the transformed coordinates. Voxelization of the transformed coordinates can include quantization and removal of some points in the point cloud. In other words, multiple points in the point cloud can be contained in a single "voxel," which can then be treated as a single point in some respects. Furthermore, octree analysis unit 210 can generate an octree based on the voxelized transformed coordinates. Additionally, in Figure 2 In the example, the surface approximation analysis unit 212 can analyze points to potentially determine a surface representation of the point set. The arithmetic coding unit 214 can entropy encode the syntax elements representing information about the octree and / or surface determined by the surface approximation analysis unit 212. The G-PCC encoder 200 can output these syntax elements in a geometric bitstream.

[0059] The geometric reconstruction unit 216 can reconstruct the transformed coordinates of points in the point cloud based on an octree, data indicating the surface determined by the surface approximation analysis unit 212, and / or other information. Due to voxelization and surface approximation, the number of transformed coordinates reconstructed by the geometric reconstruction unit 216 may differ from the number of original points in the point cloud. The obtained points may be referred to as reconstructed points. The attribute transfer unit 208 can transfer attributes of the original points in the point cloud to the reconstructed points in the point cloud.

[0060] Furthermore, RAHT unit 218 can apply RAHT decoding to the attributes of the reconstructed points. Alternatively or additionally, LOD generation unit 220 and lifting unit 222 can apply LOD processing and lifting to the attributes of the reconstructed points, respectively. RAHT unit 218 and lifting unit 222 can generate coefficients based on attributes. Coefficient quantization unit 224 can quantize the coefficients generated by RAHT unit 218 or lifting unit 222. Arithmetic encoding unit 226 can apply arithmetic decoding to the syntax elements representing the quantized coefficients. G-PCC encoder 200 can output these syntax elements in the attribute bitstream.

[0061] exist Figure 3 In the example, the G-PCC decoder 300 may include a geometric arithmetic decoding unit 302, an attribute arithmetic decoding unit 304, an octree synthesis unit 306, an inverse quantization unit 308, a surface approximation synthesis unit 310, a geometric reconstruction unit 312, a RAHT unit 314, a LoD generation unit 316, an inverse lifting unit 318, an inverse coordinate transformation unit 320, and an inverse color transformation unit 322.

[0062] The G-PCC decoder 300 can obtain a geometric bitstream and an attribute bitstream. The geometric arithmetic decoding unit 302 of the G-PCC decoder 300 can apply arithmetic decoding (e.g., context-adaptive binary arithmetic decoding (CABAC) or other types of arithmetic decoding) to the syntax elements in the geometric bitstream. Similarly, the attribute arithmetic decoding unit 304 can apply arithmetic decoding to the syntax elements in the attribute bitstream.

[0063] Octree synthesis unit 306 can synthesize octrees based on syntax elements parsed from the geometric bitstream. In the case of using surface approximation in the geometric bitstream, surface approximation synthesis unit 310 can determine the surface model based on syntax elements parsed from the geometric bitstream and based on the octree.

[0064] Furthermore, the geometric reconstruction unit 312 can perform reconstruction to determine the coordinates of points in the point cloud. The inverse coordinate transformation unit 320 can apply an inverse transformation to the reconstructed coordinates to transform the reconstructed coordinates (positions) of points in the point cloud from the transformation domain to the initial domain.

[0065] In addition, Figure 3 In the example, the inverse quantization unit 308 can inverse quantize attribute values. These attribute values ​​can be based on syntax elements obtained from the attribute bitstream (e.g., including syntax elements decoded by the attribute arithmetic decoding unit 304).

[0066] Depending on how the attribute values ​​are encoded, RAHT unit 314 can perform RAHT decoding to determine the color values ​​of the points in the point cloud based on the inversely quantized attribute values. Alternatively, LoD generation unit 316 and inverse lifting unit 318 can use level-of-detail techniques to determine the color values ​​of the points in the point cloud.

[0067] In addition, Figure 3 In the example, the inverse color transformation unit 322 can apply an inverse color transformation to the color value. The inverse color transformation can be the inverse operation of the color transformation applied by the color transformation unit 204 of the G-PCC encoder 200. For example, the color transformation unit 204 can transform color information from the RGB color space to the YCbCr color space. Therefore, the inverse color transformation unit 322 can transform color information from the YCbCr color space to the RGB color space.

[0068] It shows Figure 2 and Figure 3The various units help to understand the operations performed by the G-PCC encoder 200 and the G-PCC decoder 300. These units can be implemented as fixed-function circuits, programmable circuits, or a combination thereof. Fixed-function circuits refer to circuits that provide a specific function and are pre-configured for the operations that can be performed. Programmable circuits refer to circuits that can be programmed to perform various tasks and provide flexible functionality in the operations that can be performed. For example, a programmable circuit can execute software or firmware that causes the programmable circuit to operate in a manner defined by software or firmware instructions. Fixed-function circuits can execute software instructions (e.g., for receiving or outputting parameters), but the type of operation performed by a fixed-function circuit is generally immutable. In some examples, one or more of these units can be different circuit blocks (fixed-function or programmable), and in some examples, one or more of these units can be integrated circuits.

[0069] The decanonical quantization and scaling in G-PCC are now described. The raw point cloud can be represented in floating-point format or at a very high bit depth. Voxelization unit 206 can quantize and voxelize the input point cloud at a certain bit depth. For voxelization purposes, G-PCC encoder 200 can apply quantization, and scaling can be performed on the decoder side (e.g., by G-PCC decoder 300), primarily to map the decoded point cloud (e.g., in voxel units) into an application-specific physical space (i.e., physical dimension). G-PCC decoder 300 can use the syntax elements sps_source_scale_factor_numerator_minus1 and sps_source_scale_factor_denominator_minus1, with the scaling value signaled by G-PCC encoder 200 for this operation. The quantization process as a preprocessing step (before encoding) and the scaling process as a post-processing step (after decoding) do not affect the overall decoding process. Instead, the quantization and scaling processes are inherently decanonical.

[0070] sps_source_scale_factor_numerator_minus1 ue(v) sps_source_scale_factor_denominator_minus1 ue(v)

[0071] For the purposes of this disclosure, on the encoder side (e.g., G-PCC encoder 200), the point cloud before decanonical quantization will be referred to as the "unquantized point cloud," and the point cloud after decanonical quantization will be referred to as the "quantized point cloud." This quantization is independent of the quantization that may be performed by the G-PCC codec as part of the encoding or decoding process. Similarly, the output of the G-PCC decoder (e.g., G-PCC decoder 300) is referred to as the quantized point cloud; any output from decanonical scaling on the decoder side is referred to as the unquantized point cloud. Note again that the output of the G-PCC decoder (e.g., G-PCC decoder 300) can be the result of a canonical scaling operation.

[0072] Now, let's describe the bounding box in G-PCC. Similar to the concepts of width and height in images and videos, point clouds also have the concept of bounding boxes, which assume that all points in the point cloud exist within the bounding box. In other words, a bounding box is defined such that it contains all points in the point cloud.

[0073] The source bounding box is now described. When capturing or generating a point cloud, a bounding box can be specified to capture all points of the point cloud. For example, source device 102 can specify a bounding box. This bounding box can be referred to as the source bounding box. In G-PCC, Sequence Parameter Set (SPS) bounding box syntax elements (e.g., seq_bounding_box_present_flag) that can indicate the source bounding box are specified. For the purposes of this disclosure, the SPS bounding box can be referred to as the source bounding box. No units are defined in G-PCC for describing the source bounding box. Therefore, a given application can determine these units. The syntax and semantics associated with the SPS bounding box are provided below.

[0074] It is assumed (because this behavior is not defined in the G-PCC standard) that the output of the G-PCC decoder 300 will be scaled using source scaling factors (derived from `sps_source_scale_factor_numerator_minus1` and `sps_source_scale_factor_denominator_minus1`), and this (non-canonical) scaled output is contained within an SPS bounding box. For example, an application, a standalone device, or the G-PCC decoder device itself can scale the output of the G-PCC decoder 300. In some examples, the G-PCC decoder 300 can parse the scaling factor syntax element. In other examples, an application or a standalone device can parse the scaling factor syntax element.

[0075] Source bounding box related syntax

[0076]

[0077] The semantics related to the source bounding box are as follows:

[0078] A main_profile_compatibility_23bitsflag value of 1 indicates that the bitstream conforms to the main profile. A main_profile_compatibility_flag value of 0 indicates that the bitstream conforms to a profile other than the main profile.

[0079] The reserved_profile_compatibility_22 bits should be equal to 0 in bitstreams conforming to this version of the specification. Other values ​​for reserved_profile_compatibility_22 bits are reserved for future use by ISO / IEC. The decoder should ignore the value of reserved_profile_compatibility_2 bits.

[0080] A unique_point_positions_constraint_flag value of 1 indicates that in every point cloud frame pointing to the current SPS, all output points have a unique position. A unique_point_positions_constraint_flag value of 0 indicates that in any point cloud frame referencing the current SPS, two or more output points can have the same position.

[0081] Note that, for example, even if all points in each slice [sic] are unique, points in different slices within a frame may overlap. In this case, unique_point_positions_constraint_flag should be set to 0.

[0082] `level_idc` indicates that the bitstream conforms to the level specified in Annex A. The bitstream should not contain any `level_idc` value other than those specified in Annex A. Other values ​​for `level_idc` are reserved for future use by ISO / IEC.

[0083] `sps_seq_parameter_set_id` provides an identifier for SPS to be referenced by other syntax elements. In bitstreams conforming to this version of the specification, the value of `sps_seq_parameter_set_id` should be 0. Non-zero values ​​for `sps_seq_parameter_set_id` are reserved for future use by ISO / IEC.

[0084] `sps_bounding_box_present_flag` equal to 1 indicates that a bounding box exists. `sps_bounding_box_present_flag` equal to 0 indicates that the size of the bounding box is not defined.

[0085] `sps_bounding_box_offset_x`, `sps_bounding_box_offset_y`, and `sps_bounding_box_offset_z` represent the quantized x, y, and z offsets of the source bounding box in Cartesian coordinates. When these values ​​are not present, they are inferred to be 0.

[0086] sps_bounding_box_offset_log2_scale indicates a scaling factor to scale the quantized x, y, and z source bounding box offsets. When it does not exist, the value of sps_bounding_box_offset_log2_scale is inferred to be 0.

[0087] sps_bounding_box_size_width, sps_bounding_box_size_height, and sps_bounding_box_size_depth represent the width, height, and depth of the source bounding box in Cartesian coordinates.

[0088] The increment of sps_source_scale_factor_numerator_minus1 represents the scaling factor numerator of the source point cloud.

[0089] The addition of 1 to sps_source_scale_factor_denominator_minus1 indicates the scaling factor denominator of the source point cloud.

[0090] Now, let's describe the tile bounding boxes. In addition to the source bounding box, G-PCC also specifies the tile bounding box. The tile bounding box is associated with the points of the tile. The tile bounding box is signaled in the `tile_inventory()` syntax. Each `tile_inventory()` syntax structure is associated with the frame specified by `tile_frame_idx`.

[0091] Tile list syntax

[0092]

[0093] The semantics of the tile list are as follows:

[0094] The increment of 1 in num_tiles_minus1 indicates the number of tile bounding boxes present in the tile list.

[0095] tile_bounding_box_offset_x[i], tile_bounding_box_offset_y[i], and tile_bounding_box_offset_z[i] represent the x, y, and z offsets of the i-th tile in Cartesian coordinates.

[0096] tile_bounding_box_size_width[i], tile_bounding_box_size_height[i], and tile_bounding_box_size_depth[i] represent the width, height, and depth of the i-th tile in Cartesian coordinates.

[0097] Now let's describe the slice bounding box. Although no bounding box is explicitly specified for a slice, a box containing points within the slice can be specified. The specification of the slice bounding box includes the slice origin, which specifies one corner of the slice bounding box, as well as the width, height, and depth of the slice bounding box.

[0098] The Geometry Parameter Set (GPS) includes an indication of whether an explicit slice origin is signaled for a slice. If an explicit slice origin exists, the G-PCC encoder 200 can signal the scaling value associated with the GPS or Geometry Slice Header (GSH). When no explicit slice origin is signaled, the G-PCC decoder 300 infers that the slice origin is equal to (0,0,0). The slice bounding box syntax is shown below.

[0099] Slice (boundary) box related syntax

[0100]

[0101]

[0102]

[0103] The semantics related to slice (boundary) boxes are now described. The following are the semantics of the relevant syntax elements in the geometry parameter set:

[0104] `gps_geom_parameter_set_id` provides an identifier for GPS that can be referenced by other syntax elements. The value of `gps_seq_parameter_set_id` should be in the range of 0 to 15, including the endpoints.

[0105] The `gps_seq_parameter_set_id` specifies the value of `sps_seq_parameter_set_id` for the active SPS. The value of `gps_seq_parameter_set_id` should be in the range of 0 to 15, including the endpoints.

[0106] A value of 1 for `gps_box_present_flag` indicates that additional bounding box information is provided in the geometry header referencing the current GPS. A value of 0 for `gps_bounding_box_present_flag` indicates that additional bounding box information is not signaled in the geometry header.

[0107] A flag of 1 for `gps_gsh_box_log2_scale_present_flag` indicates that `gsh_box_log2_scale` is signaled in the header of each geometry slice referencing the current GPS. A flag of 0 for `gps_gsh_box_log2_scale_present_flag` indicates that `gsh_box_log2_scale` is not signaled in the header of each geometry slice, but rather in the `gps_gsh_box_log2_scale` of the current GPS for the general scaling of all slices.

[0108] gps_gsh_box_log2_scale represents the common scaling factor that references the origin of the bounding box of all slices in the current GPS.

[0109] The following is the semantics of the relevant syntax elements in the geometry slicing header:

[0110] gsh_geometry_parameter_set_id represents the value of gps_geom_parameter_set_id for the active GPS.

[0111] `gsh_tile_id` represents the tile ID value referenced by GSH. The value of `gsh_tile_id` should be in the range of 0 to XX (inclusive).

[0112] The `gsh_slice_id` identifier is used in the slice header for reference by other syntax elements. The value of `gsh_slice_id` should be in the range of 0 to XX (inclusive).

[0113] `frame_idx` specifies the log2_max_frame_idx+1 least significant bits of the nominal frame number counter. Consecutive slices with different `frame_idx` values ​​constitute parts of different output point cloud frames. Consecutive slices with the same `frame_idx` value and without intermediate frame boundary marker data units form parts of the same output point cloud frame.

[0114] `gsh_num_points` specifies the maximum number of decoded points in a slice. `gsh_num_points` being greater than or equal to the number of decoded points in a slice is a requirement for bitstream consistency.

[0115] gsh_box_log2_scale specifies the scaling factor used for the origin of the bounding box of the slice.

[0116] gsh_box_origin_x specifies the x-value of the origin of the bounding box, which is scaled by the gsh_box_log2_scale value.

[0117] gsh_box_origin_y specifies the y-value of the origin of the bounding box, scaled by the gsh_box_log2_scale value.

[0118] gsh_box_origin_z specifies the z-value of the origin of the bounding box, scaled by the gsh_box_log2_scale value.

[0119] The variables slice_origin_x, slice_origin_y, and slice_origin_z are derived as follows:

[0120] If gps_gsh_box_log2_scale_present_flag equals 0

[0121] Set originScale to equal gsh_box_log2_scale

[0122] Otherwise (gps_gsh_box_log2_scale_present_flag equals 1),

[0123] Set originScale to equal gps_gsh_box_log2_scale

[0124] If gps_box_present_flag equals 0

[0125] The values ​​of slice_origin_x, slice_origin_y, and slice_origin_z are inferred to be 0.

[0126] Otherwise (gps_box_present_flag equals 1), the following applies:

[0127] slice_origin_x=gsh_box_origin_x< <originScale

[0128] slice_origin_y=gsh_box_origin_x< <originScale

[0129] slice_origin_z=gsh_box_origin_x< <originScale

[0130] gsh_log2_max_nodesize_x specifies the bounding box size in the x-axis, i.e., MaxNodesizeXLog2, which is used as follows during the decoding process.

[0131] MaxNodeSizeXLog2=gsh_log2_max_nodesize_x

[0132] MaxNodeSizeX = 1 <MaxNodeSizeXLog2

[0133] `gsh_log2_max_nodesize_y_minus_x` specifies the bounding box size in the y-axis, which is `MaxNodesizeYLog2`. It is used during decoding as follows:

[0134] MaxNodeSizeYLog2=gsh_log2_max_nodesize_y_minus_x+MaxNodeSizeXLog2.

[0135] MaxNodeSizeY = 1 <MaxNodeSizeYLog2。

[0136] gsh_log2_max_nodesize_z_minus_y specifies the bounding box size in the z dimension, i.e., MaxNodesizeZLog2, which is used as follows during the decoding process.

[0137] MaxNodeSizeZLog2=gsh_log2_max_nodesize_z_minus_y+MaxNodeSizeYLog2

[0138] MaxNodeSizeZ = 1 <MaxNodeSizeZLog2

[0139] If gps_implicit_geom_partition_flag equals 1, then gsh_log2_max_nodesize is deduced as follows.

[0140] gsh_log2_max_nodesize=max{MaxNodeSizeXLog2,MaxNodeSizeYLog2,MaxNodeSizeZLog2}

[0141] `gsh_log2_max_nodesize` specifies the size of the root geometric octree node when `gps_implicit_geom_partition_flag` equals 0. The derivation of the variables `MaxNodeSize` and `MaxGeometryOctreeDepth` is as follows.

[0142] MaxNodeSize = 1 <gsh_log2_max_nodesize

[0143] MaxGeometryOctreeDepth=gsh_log2_max_nodesize-log2_trisoup_node_size

[0144] Then, update variables K and M as follows.

[0145]

[0146] Now, let's describe the region boxes. In addition to the bounding boxes specified above, G-PCC also supports region box signaling, which is used to indicate modified QP values ​​to attributes of a specific region of the point cloud. Typically, the QP value associated with an attribute can be specified in the attribute slice header (in addition to some syntax elements in the attribute parameter set). However, some regions of the point cloud may have special characteristics that can differ from the rest of the slice. For example, a denser region of the slice can be decoded using a finer representation (lower QP), or a sparser region can be decoded using a coarser representation (higher QP). Region boxes can be used to specify different QPs for attributes of a specific region of a slice. The syntax related to region boxes is described below.

[0147] Region box related syntax

[0148]

[0149]

[0150] The semantics related to the region bounding box are as follows:

[0151] ash_attr_parameter_set_id specifies the value of aps_attr_parameter_set_id for the active APS.

[0152] `ash_attr_sps_attr_idx` specifies the order of attribute sets in the active SPS. The value of `ash_attr_sps_attr_idx` should be in the range of 0 to `sps_num_attribute_sets` in the active SPS.

[0153] ash_attr_geom_slice_id specifies the value of gsh_slice_id in the active geometry slice header.

[0154] A flag of 1 for `ash_attr_layer_qp_delta_present_flag` indicates that the syntax elements `ash_attr_layer_qp_delta_luma` and `ash_attr_layer_qp_delta_chroma` exist in the current ASH. A flag of 0 for `ash_attr_layer_qp_delta_present_flag` indicates that the syntax elements `ash_attr_layer_qp_delta_luma` and `ash_attr_layer_qp_delta_chroma` do not exist in the current ASH.

[0155] Increasing 1 to ash_attr_num_layer_qp_minus1 indicates the layer number signaled for ash_attr_qp_delta_luma and ash_attr_qp_delta_chroma. When no signal is sent for ash_attr_num_layer_qp, the value of ash_attr_num_layer_qp is inferred to be 0. The derivation of the value of NumLayerQp is as follows:

[0156] numLayerQp=num_layer_qp_minus1+1

[0157] ash_attr_qp_delta_luma specifies the brightness increment qp from the initial slice qp in the active attribute parameter set. When no signal is sent to ash_attr_qp_delta_luma, the value of ash_attr_qp_delta_luma is inferred to be 0.

[0158] ash_attr_qp_delta_chroma specifies the chromaticity increment qp from the initial slice qp in the active attribute parameter set. When ash_attr_qp_delta_chroma is not signaled, its value is assumed to be 0.

[0159] The variables InitialSliceQpY and InitialSliceQpC are derived as follows:

[0160] InitialSliceQpY=aps_attrattr_initial_qp+ash_attr_qp_delta_luma

[0161] InitialSliceQpC=aps_attrattr_initial_qp+aps_attr_chroma_qp_offset+ash_attr_qp_delta_chroma

[0162] `ash_attr_layer_qp_delta_luma` specifies the brightness increment `qp` of `InitialSliceQpY` in each layer. When no signal is sent to `ash_attr_layer_qp_delta_luma`, the value of `ash_attr_layer_qp_delta_luma` for all layers is inferred to be 0.

[0163] `ash_attr_layer_qp_delta_chroma` specifies the chroma increment `qp` of `InitialSliceQpC` in each layer. When no signal is sent to `ash_attr_layer_qp_delta_chroma`, the value of `ash_attr_layer_qp_delta_chroma` for all layers is inferred to be 0.

[0164] The derivation of variables SliceQpY[i] and SliceQpC[i] is as follows, where i = 0…NumLayerQPNumQPLayer-1:

[0165] for(i=0; i <NumLayerQPNumQPLayer;i++){

[0166] SliceQpY[i]=InitialSliceQpY+ash_attr_layer_qp_delta_luma[i]

[0167] SliceQpC[i]=InitialSliceQpC+ash_attr_layer_qp_delta_chroma[i]

[0168] }

[0169] A flag of 1 for ash_attr_region_qp_delta_present_flag indicates that ash_attr_region_qp_delta, the origin of the region bounding box, and its size exist in the current ASH. A flag of 0 for ash_attr_region_qp_delta_present_flag indicates that ash_attr_region_qp_delta, the origin of the region bounding box, and its size do not exist in the current ASH.

[0170] `ash_attr_qp_region_box_origin_x` represents the x-offset of the region bounding box relative to `slice_origin_x`. If it does not exist, the value of `ash_attr_qp_region_box_origin_x` is inferred to be 0.

[0171] `ash_attr_qp_region_box_origin_y` represents the y-offset of the region bounding box relative to `slice_origin_y`. If it does not exist, the value of `ash_attr_qp_region_box_origin_y` is inferred to be 0.

[0172] `ash_attr_qp_region_box_origin_z` represents the z-offset of the region bounding box relative to `slice_origin_z`. If it does not exist, the value of `ash_attr_qp_region_box_origin_z` is inferred to be 0.

[0173] Set the variables RegionboxX, RegionboxY, and RegionboxZ at the origin of the specified region box to equal ash_attr_qp_region_box_origin_x, ash_attr_qp_region_box_origin_y, and ash_attr_qp_region_box_origin_z, respectively.

[0174] `ash_attr_qp_region_box_size_width` represents the width of the region bounding box. If it does not exist, the value of `ash_attr_qp_region_box_size_width` is inferred to be 0.

[0175] `ash_attr_qp_region_box_size_height` represents the height of the region bounding box. If it does not exist, the value of `ash_attr_qp_region_box_size_height` is inferred to be 0.

[0176] `ash_attr_qp_region_box_size_depth` represents the depth of the region bounding box. When it does not exist, the value of `ash_attr_qp_region_box_size_depth` is inferred to be 0.

[0177] Set the variables RegionboxWidth, RegionboxHeight, and RegionboxDepth, which specify the size of the region box, to equal ash_attr_qp_region_box_size_width, ash_attr_qp_region_box_size_height, and ash_attr_qp_region_box_size_depth, respectively.

[0178] `ash_attr_region_qp_delta` specifies the increment `qp` of `SliceQpY[i]` and `SliceQpC[i]` (where i = 0…NumLayerQPNumQPLayer-1) of the region specified by `ash_attr_qp_region_box`. If it does not exist, the value of `ash_attr_region_qp_delta` is inferred to be 0.

[0179] Set the variable RegionboxDeltaQp, which specifies the region box incremental quantization parameter, to be equal to ash_attr_region_qp_delta.

[0180] The attribute-specific parameter signaling in the Sequence Parameter Set (SPS) is now described. The G-PCC encoder 200 can signal the number of attributes associated with the point cloud in the SPS using a syntax element named `sps_num_attribute_sets`. For each attribute, the G-PCC encoder 200 can signal some attribute-specific parameters in the SPS, such as bit depth, auxiliary bit depth, attribute dimension, attribute type (color, reflectivity, frame index, etc.), and color space-related information. The corresponding syntax and semantics are shown below.

[0181]

[0182] The increment of attribute_dimension_minus1[i] by 1 specifies the number of components of the i-th attribute.

[0183] attribute_instance_id[i] specifies the instance ID of the i-th attribute.

[0184] Note: When a bitstream has two or more attributes with a value of attribute_label_four_bytes, the value of attribute_instance_id identifies that attribute. For example, it is useful for point clouds with multiple colors from different viewpoints.

[0185] The attribute_bitdepth_minus1[i] increments by 1 to specify the bit depth of the first component of the i-th attribute signal.

[0186] The attribute_secondary_bitdepth_minus1[i] increments by 1 to specify the bit depth of the auxiliary component of the i-th attribute signal.

[0187] `attribute_cicp_colour_primaries[i]` represents the chromaticity coordinates of the primary color source of the i-th attribute. The semantics are the same as those specified for code points in ISO / IEC 23091-2, `ColourPrimaries`.

[0188] `attribute_cicp_transfer_characteristics[i]` either indicates a reference photoelectric transfer characteristic function for the color attribute, or the source input linear light intensity L. c The function (nominal real value range is 0 to 1), or the reciprocal of the reference photoelectric transfer characteristic function, is used as the output linear light intensity L. o The function (nominal real value range is 0 to 1). The semantics are the same as those specified in ISO / IEC 23091-2 for code point TransferCharacteristics.

[0189] The attribute_cicp_matrix_coeffs[i] describes the matrix coefficients used to derive luminance and chrominance signals from the green, blue, and red, or Y, Z, and X primary colors. The semantics are the same as those specified in ISO / IEC 23091-2 for code points (MatrixCoefficients).

[0190] The attribute_cicp_video_full_range_flag[i] specifies the black level and range of the luminance and chrominance signals derived from the real-valued component signals of E'Y, E'PB, and E'PR or E'R, E'G, and E'B. The semantics are the same as those specified for the code point VideoFullRangeFlag in ISO / IEC 23091-2.

[0191] A value of 1 for known_attribute_label_flag[i] indicates that a signal is sent to know_attribute_label for the i-th attribute. A value of 0 for known_attribute_label_flag[i] indicates that a signal is sent to attribute_label_four_bytes for the i-th attribute.

[0192] A value of 0 for known_attribute_label[i] indicates that the attribute is color. A value of 1 for known_attribute_label[i] indicates that the attribute is reflectivity. A value of 2 for known_attribute_label[i] indicates that the attribute is frame index.

[0193] `attribute_label_four_bytes[i]` represents a known attribute type using 4-byte code. Section 7.1 describes the list of supported attributes and their relationship to `attribute_label_four_bytes[i]`.

[0194] Table 7.1—attribute_label_four_bytes

[0195] attribute_label_four_bytes[i] Attribute type 0 color 1 reflectivity 2 Frame Index 3 Material ID 4 transparency 5 conventional 6…255 reserve 256...0xffffffff not specified

[0196] The Attribute Parameter Set (APS) is now described. The G-PCC syntax allows signaling a separate set of parameters for each attribute. For example, if a point cloud has two distinct attributes associated with it (e.g., color and reflectivity), each attribute may have its own APS. The APS contains information about attribute quantization parameters (initial qp, qp offset, etc.), level of detail (LoD) generation parameters, and / or decoding tools used for attribute decoding.

[0197] The Level of Detail (LoD) structure is based on a user-specified set of Euclidean distances (d). l ) l＝0…L-1 The point cloud is divided into levels known as refinement levels (R). l ) l＝0…L-1 The non-overlapping subsets of points are used to represent the entire point cloud as the union of all refinement levels. This is achieved by taking the refinement levels R0, R1, ..., R... l The union of the values ​​yields the level of detail (LoD). l :

[0198] ·LOD0=R0

[0199] ·LOD1=LOD0∪R1…

[0200] ·LOD j =LODj-1 ∪R j …

[0201] ·LOD l+1 =LOD l ∪R l This represents the entire point cloud.

[0202] Figure 4 This is a conceptual diagram illustrating the process of generating the example Level of Detail (LoD). Figure 4 The original order of points in the point cloud is depicted in section 400. Using LoD (LoD), the order of points may change, as shown in LoD-based order 402. For example, LoD0 includes P0, P5, P4, and P2. LoD1 includes P0, P5, P4, P2, P1, P6, and P3. LoD2 includes P0, P5, P4, P2, P1, P6, P3, P9, P8, and P7, which are... Figure 4 The entire point cloud of the example.

[0203] Therefore, LoD generation provides a scalable representation of the attribute information of point clouds, where increasing the LoD level leads to a gradual increase in the detail of the attribute information. Furthermore, the G-PCC decoder 300 performs attribute decoding in LoD order; for example, it first decodes all points in LoD0 (R0), then decodes the points corresponding to refinement level R1 to generate LoD1, and this process can continue to progressively generate all LoDs. For this reason, points in a LoD layer can be predicted from points in previous LoD layers, or, if applicable, from previously decoded points in the same refinement level (e.g., EnableReferringSameLoD=1), such as... Figure 5 As shown in the image.

[0204] Figure 5 This is a conceptual diagram illustrating possible point prediction using LoD. The original order of points in the point cloud is depicted (500). Furthermore, the LoD-based order is depicted (502). For LoD, point P4 can be used to predict point P6 because point P4 is in LoD0, and is decoded before point P6, which is in LoD1. If EnableReferringSameLoD = 1, then point P1 can be used to predict point P6 because point P1 is decoded before point P6. However, if EnableReferringSameLoD = 0, point P1 can be used to predict point P6 without using it.

[0205] By using spatially scalable LoD generation, lower-resolution point clouds can be accessed as thumbnails with less decoder complexity and / or less bandwidth. When spatial scalability is required, it may be desirable to decode lower geometry and corresponding attribute bitstreams in a coordinated manner.

[0206] Figure 6 This is a conceptual diagram depicting G-PCC decoding with different LoDs. For example, to generate a full-resolution point cloud 642, the G-PCC decoder 300 can use high LoDs (e.g., LoD 606 and LoD 608) in the geometry bitstream 620 and the attribute bitstream 622. To generate a low-resolution point cloud 632, the G-PCC decoder 300 can use lower LoDs (e.g., LoD 602 ​​and LoD 604) in the partial octree bitstream 610 and the partial boosting bitstream 612.

[0207] To achieve coordinated spatial scalability, the attribute decoder can be extended (e.g., Figure 3 The attribute arithmetic decoding unit 304 decodes a lower resolution geometric point cloud (e.g., low resolution point cloud 632) from a partially decoded octree bitstream (e.g., partial octree bitstream 610), wherein the decoded position of a point in the lower resolution geometric point cloud is quantized as INT(pos / 2k)*2k.

[0208] One or more examples disclosed herein may be applied individually or in combination.

[0209] The constraints on region box size are now described. The semantics of the region box in the G-PCC draft standard allow a region box to exceed the size of the slice containing that region. The G-PCC encoder 200 can use exponential Golomb coding when signaling the region width, height, and depth. Signaling these syntax element values ​​beyond the slice dimensions may not provide any benefit to the G-PCC decoder 300 because there are no points belonging to slices outside the slice bounding box. Furthermore, the slice bounding box is a regular cuboid / cube shape, so signaling regions larger than the slice bounding box may not be beneficial for the G-PCC encoder 200. This also applies to the origin of the region box, as the origin of the region box should also be included in the slice.

[0210] Furthermore, the signaling for the region frame size allows for signaling with width, height, or depth equal to 0. However, if any of these elements is signaled as zero, the G-PCC draft standard considers the region to be empty.

[0211] According to the technology of this disclosure, constraints can be added such that the region box does not exceed the slice size, or more specifically, does not exceed the slice bounding box size. For example, the G-PCC decoder 300 can determine the size of the region box. The G-PCC decoder 300 can determine the size of the slice bounding box. The G-PCC decoder 300 can decode slices of point cloud data associated with slice bounding boxes. The size of the region box can be restricted to not exceed the size of the slice bounding box.

[0212] In some examples, constraints are added so that the original region box is contained within the slice. In other examples, constraints are added so that no points in the region box are outside the slice, or more specifically, outside the slice bounding box.

[0213] In some examples, the signaling for the region box width, height, and depth is modified so that a value of 0 is not allowed for any of these region box attributes. In other words, the G-PCC encoder 200 can signal that the region box width, height, or depth is 0 without actually signaling it.

[0214] In one example, the semantics of the syntax elements of the region box are updated so that the origin of the region box or the region box does not exceed the slice size. The changes to the G-PCC standard draft ISO / IEC JTC 1 / SC 29 / WG 11N18887 begin with... <change> Change the end marker to< / change> The deletion of the G-PCC standard draft was marked as... <delete> Delete the end marker as< / delete> .

[0215] A flag of 1 for `ash_attr_region_qp_delta_present_flag` indicates that `ash_attr_region_qp_delta`, the origin of the region bounding box, and its size exist in the current ASH. A flag of 0 for `ash_attr_region_qp_delta_present_flag` indicates that `ash_attr_region_qp_delta`, the origin of the region bounding box, and its size do not exist in the current ASH.

[0216] `ash_attr_qp_region_box_origin_x` represents the x-offset of the region bounding box relative to `slice_origin_x`. If it does not exist, the value of `ash_attr_qp_region_box_origin_x` is inferred to be 0.

[0217] `ash_attr_qp_region_box_origin_y` represents the y-offset of the region bounding box relative to `slice_origin_y`. If it does not exist, the value of `ash_attr_qp_region_box_origin_y` is inferred to be 0.

[0218] `ash_attr_qp_region_box_origin_z` represents the z-offset of the region bounding box relative to `slice_origin_z`. If it does not exist, the value of `ash_attr_qp_region_box_origin_z` is inferred to be 0.

[0219] Set the variables RegionboxX, RegionboxY, and RegionboxZ at the origin of the specified region box to equal ash_attr_qp_region_box_origin_x, ash_attr_qp_region_box_origin_y, and ash_attr_qp_region_box_origin_z, respectively.

[0220] ash_attr_qp_region_box_size_width <change> _minus1 plus 1< / change> This indicates the width of the region bounding box. If it does not exist, infer `ash_attr_qp_region_box_size_width`. <change> _minus1< / change> The value is <change> -1< / change> <delete> 0< / delete> .

[0221] ash_attr_qp_region_box_size_height <change> _minus1 plus 1< / change> This indicates the height of the region bounding box. If it does not exist, infer `ash_attr_qp_region_box_size_height`. <change> _minus1< / change> The value is <change> -1< / change> <delete> 0< / delete> .

[0222] ash_attr_qp_region_box_size_depth <change> _minus1 plus 1< / change> This indicates the depth of the region bounding box. If it does not exist, infer the depth using `ash_attr_qp_region_box_size_depth`. <change> _minus1< / change> The value is <change> -1< / change> <delete> 0< / delete> .

[0223] Set the variables RegionboxWidth, RegionboxHeight, and RegionboxDepth, which specify the size of the region box, to equal ash_attr_qp_region_box_size_width, ash_attr_qp_region_box_size_height, and ash_attr_qp_region_box_size_depth, respectively.

[0224] <change>The requirement for bitstream consistency is that all of the following conditions apply:

[0225] - If gps_implicit_geom_partition_flag equals 1, then the values ​​of (RegionboxX+RegionboxWidth), (RegionboxY+RegionboxHeight), and (RegionBoxZ+RegionboxDepth) should not exceed the slice's MaxNodeSizeX, MaxNodeSizeY, and MaxNodeSizeZ, respectively.

[0226] Otherwise (gps_implicit_geom_partition_flag equals 0), the value of each of (RegionboxX+RegionboxWidth), (RegionboxY+RegionboxHeight), and (RegionBoxZ+RegionboxDepth) should not exceed MaxNodeSize.< / change>

[0227] ash_attr_region_qp_delta specifies the increment qp of SliceQpY[i] and SliceQpC[i] of the region specified by ash_attr_qp_region_box (where i = 0…NumLayerQPNumQPLayer–1). When it does not exist, the value of ash_attr_region_qp_delta is inferred to be 0.

[0228] Set the variable RegionboxDeltaQp, which specifies the region box incremental quantization parameter, to be equal to ash_attr_region_qp_delta.

[0229] In one example, the following constraint can also be added: the requirement for bitstream consistency is that all of the following conditions apply:

[0230] If gps_implicit_geom_partition_flag equals 1, then the values ​​of RegionboxX, RegionboxY, and RegionBoxZ should not exceed the slice's MaxNodeSizeX, MaxNodeSizeY, and MaxNodeSizeZ, respectively.

[0231] Otherwise (gps_implicit_geom_partition_flag equals 0), the values ​​of RegionboxX, RegionboxY, and RegionBoxZ should not exceed MaxNodeSize.

[0232] The existence of the `tile_inventory()` syntax and the validity of `tile_id` are now described. The geometry tile header includes the syntax element `tile_id`, which refers to the identifier of the tile associated with the tile. Tile information is provided in `tile_inventory()`, including the syntax element `frame_idx`. `frame_idx` can be used to associate `tile_inventory()` with a specific frame having the same `frame_idx`. However, the existence of `tile_inventory()` for a specific frame is not guaranteed. Furthermore, when the G-PCC encoder 200 signals `frame_idx` with a fixed bit depth, more than one frame may be associated with the same `frame_idx`. The association of `tile_inventory()` with a specific frame is unclear. Additionally, when a tile references `tile_id`, the value of `tile_id` should be within a valid range.

[0233] According to the technology disclosed herein, constraints can be added specifying that the `tile_inventory()` syntax must be associated with each frame. For example, the G-PCC encoder 200 can associate the `tile_inventory()` syntax with each frame. In one example, the constraint is added such that the `tile_inventory()` syntax for each point cloud frame can be signaled, for example, by the G-PCC encoder 200. In another example, a derivation is added such that each frame with a frame index is associated with a `tile_inventory()` with an equivalent frame index value. For example, the G-PCC decoder 300 can derive the association between each frame with a frame index and a `tile_inventory()` with an equivalent frame index value.

[0234] In some examples, a constraint is added such that the value of tile_id in the geometry slice header is in the range of 0 to N (inclusive), where the value of N is 1 less than the number of tiles signaled in the tile_inventory() syntax associated with that frame.

[0235] In some examples, a constraint is added such that when no tile_inventory() syntax is signaled / associated for a frame, the value of gsh_tile_id is equal to 0 for all slices of the frame. For example, the G-PCC decoder 300 may set the value of gsh_tile_id to 0 for all slices of the frame (e.g., when no tile_inventory() syntax is signaled / associated for the frame).

[0236] Alternatively, when there is no signal notification / association of tile_inventory() for the frame, gsh_tile_id can be specified as ignored, or the bitstream can be specified as not conforming / ignored by the decoder (e.g., G-PCC decoder 300).

[0237] In one example, the tile_id is not included in the slice header syntax.

[0238] In one example, the `tile_inventory()` associated with a frame can include one or more slice IDs associated with each tile. For instance, for each tile specified in the tile inventory, a list of slice IDs specifying the slices associated with that tile can be signaled.

[0239] In one example, the following changes are made to the semantics of the tile manifest. In some examples, constraints may also be added in other parts of the codec. Changes to the G-PCC draft standard begin to be marked as... <change> Change the end marker to< / change> .

[0240] num_tiles_minus1 plus 1 specifies the number of tile bounding boxes present in the tile list.

[0241] tile_bounding_box_offset_x[i], tile_bounding_box_offset_y[i], and tile_bounding_box_offset_z[i] represent the x, y, and z offsets of the i-th tile in Cartesian coordinates.

[0242] tile_bounding_box_size_width[i], tile_bounding_box_size_height[i], and tile_bounding_box_size_depth[i] represent the width, height, and depth of the i-th tile in Cartesian coordinates.

[0243] <change>One requirement for bitstream consistency is that each frame in the point cloud has the tile_inventory() syntax.

[0244] < / change>

[0245] Alternatively, the following constraints can be added: associating the tile_inventory() syntax with each frame in the point cloud is a requirement for bitstream consistency; the associated frame also has an associated frame index frame_idx.

[0246] The following changes can be made to the semantics of the geometry slice header. Changes to the G-PCC standard draft begin with... <change> Change the end marker to< / change> .

[0247] `gsh_tile_id` specifies the tile ID referenced by GSH. The value of `gsh_tile_id` should be in the range 0 to 1, including endpoints. <change> num_tiles_minus1< / change> Within the range.

[0248] Now, let's describe multiple geometric slices within a tile. Each tile can be decoded into one or more slices. The slice bounding box is specified using the slice origin and slice box size. However, the signaling of the slice origin sent, for example, by the G-PCC encoder 200, depends on the value of the syntax element `gps_box_present_flag`. When `gps_box_present_flag` equals 0, the slice origin is inferred to be (0,0,0) by the G-PCC decoder 300. When multiple geometric slices exist within a tile, setting `gps_box_present_flag` to 0 will result in multiple slices having the same origin, which may be undesirable.

[0249] According to the techniques disclosed herein, in some examples, constraints can be added such that when multiple slices exist in a tile associated with a frame, the G-PCC encoder 200 can signal one or more syntax elements associated with the slice origin, and the G-PCC decoder 300 can parse one or more syntax elements. This constraint can be an explicit signaling constraint or an indirect bitstream consistency constraint.

[0250] In another example, the G-PCC encoder 200 can signal the slice origin regarding the canonical bounding box specified for the point cloud, and the G-PCC decoder 300 can resolve the slice origin. The canonical bounding box can be a box specified to contain all reconstructed points in the point cloud. In some examples, the canonical bounding box is the smallest box containing all reconstructed points of the point cloud frame. In some examples, the canonical bounding box is specified in the bitstream (e.g., signaled) or derived from other syntax elements (e.g., performed by the G-PCC decoder 300).

[0251] For example, a canonical bounding box can be specified by one or more of the bounding box origin and bounding box dimensions (width, height, depth).

[0252] In one example, the following constraints can be added to the semantics:

[0253] When any two geometric slices with different gsh_slice_id values ​​appear in a specific tile of a point cloud frame, the bitstream consistency requirement is that the value of gps_box_present_flag should be equal to 1.

[0254] Alternatively, the following constraints can be added to the semantics:

[0255] When two geometric slices with different gsh_slice_id values ​​exist, and the tile IDs and frame indices of the two slices are the same, the requirement for bitstream consistency is that the value of gps_box_present_flag should be equal to 1 for the GPS referenced by the two slices.

[0256] Alternatively, when there are two different geometric slices in a frame, constrain gps_box_present_flag to 1.

[0257] For example, the following constraint can be added to the semantics: when there are any two geometric slices with different gsh_slice_id values ​​in a point cloud frame, the bitstream consistency requirement is that the value of gps_box_present_flag should be equal to 1.

[0258] The Trisoup node size range is now described. When decoding locations in a point cloud using trisoup decoding, the G-PCC encoder 200 specifies the size of the nodes to be decoded using the trisoup decoding mode to the G-PCC decoder 300 using the syntax element log2_trisoup_node_size. The G-PCC encoder 200 can signal this syntax element via GPS, and the G-PCC decoder 300 can parse this syntax element. The semantics are as follows:

[0259] log2_tisoup_node_size specifies the size of the triangle node as the variable TrisoupNodeSize, as shown below.

[0260] TrisoupNodeSize = 1 <log2_trisoup_node_size

[0261] When log2_tisoup_node_size equals 0, the geometric bitstream contains only octree decoding syntax. When log2_tisoup_node_size is greater than 0, the bitstream consistency requirement is:

[0262] -inferred_direct_coding_mode_enabled_flag must be equal to 0, and

[0263] -unique_geometry_points_flag must be equal to 1.

[0264] This syntax element can also be used to determine the maximum octree encoding depth, because when using tisoup decoding, slices are decoded to a specific node size using QTBT or octree, and then tisoup encoding is performed. This is described semantically as follows:

[0265] gsh_log2_max_nodesize_x specifies the bounding box size in the x-axis, i.e., MaxNodesizeXLog2, which is used as follows during the decoding process.

[0266] MaxNodeSizeXLog2=gsh_log2_max_nodesize_x

[0267] MaxNodeSizeX = 1 <MaxNodeSizeXLog2

[0268] `gsh_log2_max_nodesize_y_minus_x` specifies the bounding box size in the y-axis, which is `MaxNodesizeYLog2`. It is used during decoding as follows:

[0269] MaxNodeSizeYLog2=gsh_log2_max_nodesize_y_minus_x+MaxNodeSizeXLog2.

[0270] MaxNodeSizeY = 1 <MaxNodeSizeYLog2。

[0271] gsh_log2_max_nodesize_z_minus_y specifies the bounding box size in the z dimension, i.e., MaxNodesizeZLog2, which is used as follows during the decoding process.

[0272] MaxNodeSizeZLog2=gsh_log2_max_nodesize_z_minus_y+MaxNodeSizeYLog2

[0273] MaxNodeSizeZ = 1 <MaxNodeSizeZLog2

[0274] If gps_implicit_geom_partition_flag equals 1, then gsh_log2_max_nodesize is exported as shown below.

[0275] gsh_log2_max_nodesize=max{MaxNodeSizeXLog2,MaxNodeSizeYLog2,MaxNodeSizeZLog2}

[0276] `gsh_log2_max_nodesize` specifies the size of the root geometry octree node when `gps_implicit_geom_partition_flag` equals 0. The variables `MaxNodeSize` and `MaxGeometryOctreeDepth` are derived as shown below.

[0277] MaxNodeSize = 1 <gsh_log2_max_nodesize

[0278] MaxGeometryOctreeDepth=gsh_log2_max_nodesize-log2_trisoup_node_size

[0279] Then, variables K and M are updated as follows.

[0280]

[0281] In the G-PCC standard draft, the range of log2_tisoup_node_size is unrestricted. When the value of log2_tisoup_node_size exceeds the slice dimension, the G-PCC decoder 300 may derive a negative MaxGeometryOctreeDepth, which is potentially undesirable. Signaling log2_tisoup_node_size values ​​greater than the slice dimension is also inefficient.

[0282] According to the techniques described in this disclosure, in some examples, constraints can be added to limit the value of `log2_tisoup_node_size` to no more than the slice dimension. In one example, the following constraint is added to the geometry slice header semantics: the value of `gsh_log2_max_nodesize` should be greater than or equal to the value of `log2_trisoup_node_size` as a bitstream consistency requirement. Alternatively, the following constraint can be added to the geometry slice header semantics: when `gps_implicit_geom_partition_flag` equals 1, the value of `log2_trisoup_node_size` should be less than or equal to `min(gsh_log2_max_nodesize_x, gsh_log2_max_nodesize_y, gsh_log2_max_nodesize_z)` as a bitstream consistency requirement; otherwise, it should be greater than or equal to `gsh_log2_max_nodesize`.

[0283] The uniqueness of the geometry slice ID is now described. A point cloud frame can be associated with more than one slice, and each slice may be associated with a geometry slice (which contains a geometry slice header). A geometry slice has an identifier `gsh_slice_id`. When the G-PCC encoder 200 signals an attribute slice, the slice contains the ID of the geometry slice associated with that attribute slice. This is signaled in the attribute slice header using the syntax element `ash_attr_geom_slice_id`.

[0284] Currently, there are no restrictions on the slice IDs that can be assigned to geometry slices. If more than one geometry slice has the same gsh_slice_id value, ambiguity may arise when an attribute slice references a geometry slice with that specific slice ID value. This behavior may be undesirable and could cause problems (e.g., decoding errors) when the G-PCC decoder 300 attempts to decode point cloud data.

[0285] According to the techniques of this disclosure, in some examples, a constraint can be added such that when two geometric slices associated with a frame have the same slice ID, the contents of the geometric slices should be identical. This constraint allows for repeated slices within a frame. Alternatively, a constraint can be added such that two geometric slices associated with a frame do not have the same slice ID value. In one example, the following constraint can be added to the geometric slice header semantics: For any two geometric slices associated with a frame and having the same gsh_slice_id value, the requirement for bitstream consistency is that the contents of the two geometric slices should be identical. This constraint can also be written as: When any geometric slice of a frame has the same gsh_slice_id value, the contents of the two geometric slices should be identical.

[0286] For example, the G-PCC decoder 300 can determine a first slice identifier (ID) of a first geometric slice associated with a frame of point cloud data. The G-PCC decoder 300 can determine a second slice ID of a second geometric slice associated with a frame of point cloud data. Based on the fact that the second slice ID equals the first slice ID, the G-PCC decoder 300 can determine that the second slice contains the same content as the first slice. The G-PCC decoder 300 can then decode the point cloud data based on the first slice ID.

[0287] In another example, the following constraint can be added: the requirement for bitstream consistency is that two geometric slices associated with a frame should not have the same `gsh_slice_id` value. In some examples, the slice ID can be defined as a combination or function of both `gsh_slice_id` and `tile_id`. For example, one of the above constraints can be modified as follows: when any two geometric slices are associated with a frame and have the same `gsh_slice_id` value and the same `gsh_tile_id` value, the requirement for bitstream consistency is that the contents of the two geometric slices should be identical.

[0288] Now, let's describe the unique location of a point. In G-PCC, a voxel in a point cloud (associated with a unique location) can be associated with one or more points. In some applications, it may be necessary to restrict a voxel to containing only one point or to indicate whether a voxel contains only one point. When the source point cloud may have more than one point associated with a voxel (or location), the points in the voxel can be combined (by averaging or other methods, and recoloring or recalculating properties for the individual points) to generate a single point for that voxel. The G-PCC bitstream can then indicate that the voxel contains only one point. There are two syntax elements in G-PCC associated with this indication.

[0289] 1) The syntax element `unique_point_positions_constraint_flag` in SPS specifies whether each position in the point cloud has a non-unique point (i.e., two or more points). The semantics of this syntax element are as follows:

[0290] A unique_point_positions_constraint_flag value of 1 indicates that all output points have unique positions in every point cloud frame referencing the current SPS. A unique_point_positions_constraint_flag value of 0 indicates that two or more output points can have the same position in any point cloud frame referencing the current SPS.

[0291] 2) The GPS syntax element `unique_geometry_points_flag` specifies whether any voxel in a slice has non-unique points. The semantics of this syntax element are as follows:

[0292] A unique_geometry_points_flag value of 1 indicates that all output points have a unique location within all slices referencing the current GPS. A unique_geometry_points_flag value of 0 indicates that two or more output points may have the same location within all slices referencing the current GPS.

[0293] When `unique_point_positions_constraint_flag` equals 1, all points in the point cloud are associated with a unique point. However, even in this case, the G-PCC encoder 200 is allowed to signal in the bitstream that `unique_geometry_points_flag` equals 0 (meaning two or more output points may be associated with the same location), which contradicts the signaling of `unique_point_positions_constraint_flag`. This could lead to inconsistent or inconsistent bitstream behavior in the decoder (e.g., G-PCC decoder 300).

[0294] According to the techniques of this disclosure, in some examples, constraints can be added such that a slice does not contain two points associated with the same location when all points in the point cloud are indicated to be associated with a unique point. In this case, signaling or otherwise providing indications that a slice may contain two points associated with the same location can also be disabled. In some examples, when the location of a point in the point cloud is specified to be unique, one or more quantization / scaling methods can be disabled, and the G-PCC encoder 200 may not signal associated syntax elements.

[0295] In one example, the following constraint can be added to the semantics of GPS: the bitstream consistency requirement is that the value of unique_geometry_points_flag should not be equal to 0 when unique_points_positions_constraint_flag is equal to 1. In one example, the constraint is worded as follows: the bitstream consistency requirement is that the value of unique_points_positions_constraint_flag (in the relevant SPS) should not be equal to 1 when the unique_geometry_points_flag (in the relevant GPS) is equal to 0 for any slice.

[0296] Now, let's describe the conditions for attribute-specific parameter signaling in SPS.

[0297] First, for each attribute, the G-PCC encoder 200 can signal four different syntax parameters: attribute_cicp_colour_primaries[i], attribute_cicp_transfer_characteristics[i], attribute_cicp_matrix_coeffs[i], and attribute_cicp_video_full_range[i], although they only apply to color attributes.

[0298] Secondly, based on the semantics of known_attribute_label_flag, known_attribute_label, and attribute_label_four_byte, the G-PCC encoder 200 can signal certain attributes in a variety of ways. For example, color attributes can be indicated using any of the following methods:

[0299] a.Known_attribute_label_flag[i]=1, known_attribute_label[i]=0(ue(v)), or

[0300] b.Known_attribute_label_flag[i]=0, attribute_label_four_bytes[i]=0(u(32))

[0301] Similarly, multiple signaling methods are also applied to reflectivity and frame index attributes. These multiple signaling methods can lead to redundant signaling, which is inefficient.

[0302] According to the technology disclosed herein, in some examples, the G-PCC encoder 200 signals four different color-related syntax elements (Clustering Iterative Closest Point (CICP) parameters) only for color attributes. The G-PCC decoder 300 can parse these syntax elements. Color attributes can include one or more of the following: RGB, YCbCr, YCoCg, ICtCp, or any other color space representation. The signaling of these syntax elements can be conditional on one or more values ​​of attribute labels / types (e.g., RGB, YCbCr, etc.).

[0303] In another example, the G-PCC encoder 200 signals a syntax element to specify whether to signal one or more CICP parameters of an attribute. The G-PCC decoder 300 can parse this syntax element. When CICP parameters are not signaled, they can be inferred to have predetermined default values. For example, when CICP parameters are not signaled, the G-PCC decoder 300 can infer default values ​​for the CICP parameters.

[0304] To remove redundancy, either of the two alternative methods can be used:

[0305] 1. When known_attribute_label_flag is zero, attribute_label_four_bytes should not contain known attributes (such as color, reflectivity, and frame index).

[0306] 2. Remove the known_attribute_label_flag and known_attribute_label syntax elements so that each attribute is represented using only attribute_label_four_bytes.

[0307] The changes to the G-PCC standard draft began to be marked as <change> Change the end marker to< / change> .

[0308]

[0309]

[0310] In one example (Example 1), the following changes can be made to the G-PCC draft standard. Changes to the G-PCC draft standard begin with the following marker: <change> Change the end marker to< / change> .

[0311] A value of 1 for known_attribute_label_flag[i] indicates that a signal is sent to know_attribute_label for the i-th attribute. A value of 0 for known_attribute_label_flag[i] indicates that a signal is sent to attribute_label_four_bytes for the i-th attribute.

[0312] A value of 0 for known_attribute_label[i] indicates that the attribute is color. A value of 1 for known_attribute_label[i] indicates that the attribute is reflectivity. A value of 2 for known_attribute_label[i] indicates that the attribute is frame index.

[0313] attribute_label_four_bytes[i] indicates: <change> The remaining attribute type is unknown, and it contains 4 bytes.< / change> Table 7.1 describes the list of supported attributes and their relationship to attribute_label_four_bytes[i].

[0314] Table 7.1—attribute_label_four_bytes

[0315] attribute_label_four_bytes[i] Attribute type <change> 0 < / change> transparency 1 conventional 2…255 reserve 256...0xffffffff not specified

[0316]

[0317]

[0318] In another example, the following changes could be made to the G-PCC draft standard. Changes to the G-PCC draft standard begin to be marked as... <change> Change the end marker to< / change> .

[0319]

[0320] In another example, the semantics of attribute_label_four_bytes can be specified as follows, with the deletion starting marker being... <delete> The end marker for deletion is< / delete> Other changes are marked as starting points. <change> The added end marker is< / change> :

[0321] attribute_label_four_bytes[i] represents <delete> known< / delete> Attribute type, with 4 byte codes <change> When known_attribute_label_flag equals 0< / change>The following table describes the list of supported attributes and their relationship to attribute_label_four_bytes[i].

[0322]

[0323]

[0324] Unique attribute tags can be specified as follows:

[0325] AttributeLabel=attribute_label_four_bytes+N

[0326] Where N is the number of specified known attribute tags (3 in the example above).

[0327] In another example (Example 2), the signaling of CICP parameters can be controlled via the flag attribute_cicp_params_present_flag[]. When the value of the flag is equal to 0, the G-PCC encoder 200 may not signal to CICP.

[0328]

[0329] <change> When `attribute_cicp_params_present_flag[i]` equals 1, it means that the syntax elements `attribute_cicp_colour_primaries[i]`, `attribute_cicp_transfer_characteristics[i]`, `attribute_cicp_matrix_coeffs[i]`, and `attribute_cicp_video_full_range_flag[i]` are signaled for the i-th attribute set. When `attribute_cicp_params_present_flag[i]` equals 0, it means that the syntax elements `attribute_cicp_colour_primaries[i]`, `attribute_cicp_transfer_characteristics[i]`, `attribute_cicp_matrix_coeffs[i]`, and `attribute_cicp_video_full_range_flag[i]` are not signaled for the i-th attribute set.< / change>

[0330] If it is determined that only the color attribute requires the CICP parameter, then there is no need to send a signaling flag; instead, the presence of the CICP parameter can be adjusted using known_attribute_label[] or attribute_label_four_bytes[]. For such an approach, the attribute label can be signaled before the CICP parameter.

[0331] We will now describe the general representation of attribute-related parameters in the Attribute Parameter Set (APS) and Attribute Slice Header (ASH). Both APS and ASH apply to all attributes. In fact, as mentioned earlier, each attribute may have its own APS and ASH. However, both APS and ASH contain syntax elements named _*_luma* and *_chroma_* (primarily used for quantization / scaling-related parameters), which are semantically inconsistent, as shown below.

[0332] Additionally, in APS, some parameters are not applicable to one-dimensional properties (e.g., reflectivity). These parameters may still exist and may still need to be signaled (e.g., via the G-PCC encoder 200). Effectively disabling the signaling values ​​for these parameters is one solution. However, this can burden bitstream consistency checks, as the decoder (e.g., the G-PCC decoder 300) may have to process all possible values ​​to ensure robust decoding.

[0333] The APS and ASH syntax elements are shown below:

[0334]

[0335]

[0336]

[0337] According to the technology disclosed herein, in some examples, for semantic consistency, *_luma_* and *_chroma_* can be replaced with *_* (NULL) and *_secondary_*, respectively. It should be noted that this only changes the naming of the syntax elements and does not change their functional meaning. Additionally, the G-PCC encoder 200 can signal in the APS whether the attribute dimension is greater than 1, which can remove the presence of unnecessary syntax elements. (Note that this mechanism is already applied in ASH because the attribute dimension can be read from the SPS. However, for APS, the same information cannot be read from the SPS because this would lead to dependencies between parameter sets, which may be undesirable). The G-PCC encoder 200 can signal in the APS whether the attribute dimension is greater than 1 as a flag.

[0338] In some examples, a condition can be added that the value of the flag should not contradict the value of the number of attribute dimensions that are signaling the attribute (e.g., if the flag is equal to 1, then the flag indicates that there are more than one attribute dimension; therefore, the flag should not be equal to 1 when the number of attributes is less than or equal to 1).

[0339] In one example, the flag `aps_attr_dimension_gtl` should be equal to 1 when the attribute dimension is greater than 1. In another example, signaling for a syntax element indicating an auxiliary incremental QP (e.g., `ash_attr_qp_delta_secondary`) can be conditional on the number of attribute dimensions being greater than 1. For example, the G-PCC decoder 300 can determine whether the attribute dimension is greater than 1. Based on the attribute dimension being greater than 1, the G-PCC decoder 300 can parse the attribute slice header syntax element indicating the incremental quantization parameters. The G-PCC decoder 300 can then decode point cloud data based on the incremental quantization parameters.

[0340] The following changes can be made to the G-PCC draft standard. Changes to the G-PCC draft standard begin with [marking information missing]. <change> Change the end marker to< / change> .

[0341]

[0342]

[0343]

[0344] Now, let's describe `region_qp_delta_signaling`. In ASH, a flag indicates whether `region_qp_delta` exists, and another syntax element indicates the value of `region_qp_delta`. However, if `region_qp_delta_present_flag` is true, the value of `region_qp_delta` should be non-zero.

[0345] Furthermore, according to the draft G-PCC standard, each slice may only specify one region that can use incremental QP. However, allowing multiple such regions instead of just one could be more flexible. The bounding boxes of these regions may or may not overlap. In this case, a point may belong to multiple bounding boxes (in the case of overlap), and incremental QP based on the lowest region index can be used, or incremental QP based on the nearest neighbor point can be used.

[0346] According to the technology disclosed herein, in one example, instead of signaling region_qp_delta, the G-PCC encoder 200 can signal region_qp_delta_abs_minus1 (amplitude) and region_qp_delta_sign. The following changes can be made to the G-PCC draft standard. Changes to the G-PCC draft standard begin to be marked as... <change> Change the end marker to< / change> .

[0347]

[0348] In another example, `ash_attr_num_regions_qp_delta` specifies the number of regions to which deltaQP will be applied. The value of `ash_attr_num_regions_qp_delta` can range from 0 to N, including the endpoints, where N can be a predetermined value (e.g., 4 or 8). The following changes can be made to the G-PCC draft standard. Changes to the G-PCC draft standard begin with the marker... <change> Change the end marker to< / change> .

[0349]

[0350] The LoD parameters are now described when encoding a point cloud with multiple attributes. When spatial scalability is required, the `lifting_scalability_enabled_flag` should be true for all attributes. In the G-PCC draft standard, this flag is encoded independently for each attribute, and this requirement is not necessarily followed every time. Furthermore, as a corollary, both attributes should use the same transformation, such as a lifting transformation, e.g., `attr_coding_type == 2`. This restriction is not present in the G-PCC draft standard.

[0351] Additionally, in typical use cases, LoD generation parameters are shared across all attributes (as in G-PCC common test conditions), but the G-PCC encoder 200 can signal the LoD generation parameters individually for each attribute. Signaling these parameters multiple times is inefficient because it increases the bit budget for typical use cases.

[0352] According to the technology disclosed herein, in one example, to provide a way to share LoD parameters (if applicable), a common LoD parameter set (CPS) can be defined, where the G-PCC encoder 200 can define the common LoD parameters. At the APS level, if an attribute needs to use different LoD parameters, the G-PCC encoder 200 can override the common LoD parameters. The following changes can be made to the G-PCC draft standard. Changes to the G-PCC draft standard begin with the following marker: <change> Change the end marker to< / change> .

[0353]

[0354]

[0355] When the overlay flag is not present in the APS, the G-PCC decoder 300 can determine that the corresponding parameter is equal to the corresponding CPS parameter. Furthermore, the attribute encoding type and the scalability enhancement enable flag should be the same for APS and CPS with different attributes.

[0356] The semantics of the syntax elements in the CPS listed above are similar to those currently defined in the APS, and apply to all attributes referencing the CPS.

[0357] In one example, the G-PCC encoder 200 can signal the CPS ID in the APS or ASH to specify the CPS corresponding to a particular attribute. The G-PCC decoder 300 can then parse the CPS ID. In another example, the G-PCC encoder 200 can only signal the CPS ID in the APS if aps_lod_parameters_override_flag equals 0.

[0358] In some examples, the signaling of `aps_lod_parameters_override_flag` can be controlled by a higher-level indication (e.g., `aps_lod_parameters_override_present_flag`) signaled in the SPS by the G-PCC encoder 200. When the higher-level indication specifies not to signal `aps_lod_parameters_override_flag`, the G-PCC encoder 200 may not explicitly signal the APS LoD parameters in the APS. The G-PCC decoder 300 can derive the APS LoD parameters from the CPS to be used for attributes.

[0359] In another example, the G-PCC encoder 200 can signal the LoD attribute parameter set, which is expected to contain LoD information of point cloud attributes. The G-PCC decoder 300 can parse the LoD information. When boost scalability is used for any attribute encoded using attrcoding type=2 (predictive boost), all attributes encoded using attr_coding_type=2 (predictive boost) can be encoded using boost scalability. The parameter set can be referenced through the attribute slice header. The changes to APS and the new LoD parameter set in the G-PCC draft standard are shown below, with the changes displayed... <change> and< / change> Between, delete is displayed <delete> and< / delete> between:

[0360]

[0361]

[0362] <change>aps_lod_parameter_set_id specifies the value of aps_lod_parameter_set_id for the active LoD parameter set. The value of aps_lod_parameter_set_id should be in the range of 0 to 15, including the endpoint.

[0363] When attr_coding_type equals 1, the value of lift_scalability_enabled_flag in the LoD parameter set referenced by aps_common_lod_parameter_set_id should be equal to 0.

[0364] When two or more attributes relate to a corresponding APS with attr_coding_type equal to 2, the value of lifting_scalability_enabled_flag should be the same as the LoD parameter set pointed to by aps_lod_parameter_set_id of the corresponding APS.< / change>

[0365] Alternatively, the following constraint can be added to the G-PCC standard draft: the value of lifting_scalability_enabled_flag should be the same for all properties of the point cloud.

[0366]

[0367] The semantics of all syntax elements in the LoD parameter set can be the same as those in the APS, except that they apply to attributes referencing the LoD parameter set. Other changes include:

[0368] <change>The `lod_parameter_set_id` provides an identifier for LPS to be referenced by other syntax elements. The value of `lod_parameter_set_id` should be in the range of 0 to 15, including the endpoint.

[0369] A value of 0 for `lps_extension_flag` indicates that the `lps_extension_data_flag` syntax element does not exist in the LPS syntax structure. In bitstreams conforming to this version of the specification, `lps_extension_flag` should be equal to 0. The value 1 for `lps_extension_flag` is reserved for future use by ISO / IEC. The decoder should ignore all `lps_extension_data_flag` syntax elements in the LPS syntax structure that have a value of 1 after `lps_extension_flag`.

[0370] The `lps_extension_data_flag` flag can have any value. Its presence and value do not affect the consistency of the decoder with the configuration file specified in this version of the specification. Decoders conforming to this version of the specification should ignore all `lps_extension_data_flag` syntax elements.

[0371] < / change>

[0372] Now we discuss geometric slices of the reference parameter set. In the G-PCC standard draft, a geometric slice contains `gsh_geometry_parameter_set_id`, which is the ID of the GPS referenced by that slice. There is no restriction on the range of values ​​for `gsh_geometry_parameter_set_id`. The value of `gps_geom_parameter_set_id` (a separate syntax element in the GPS, not GSH) ranges from 0 to 15, including the endpoints.

[0373] Furthermore, it allows each geometric tile in a point cloud frame / tile to reference any GPS (because each geometric tile in a frame / tile can signal any valid value of `gsh_geometry_parameter_set_id`). While there may be some special use cases that require this flexibility, it is meaningless for most typical cases. This flexibility also forces decoders (e.g., the G-PCC decoder 300) to perform consistency checks to test all possible combinations (different values ​​of the GPS syntax element from different GPS sources referenced by the same frame). This increases the cost for decoder manufacturers.

[0374] According to the technology disclosed herein, in one example, a restriction can be added that the value of gsh_geometry_parameter_set_id should be in the range of 0 to 15 (inclusive). For example, the G-PCC encoder 200 can encode the value of gsh_geometry_parameter_set_id in the range of 0 to 15, inclusive of the endpoint.

[0375] In some examples, when there is more than one geometric tile in a tile, a restriction can be added that each such tile should reference the same GPS. In one example, when there is more than one geometric tile in a frame, a restriction can be added that each such tile should reference the same GPS. In another example, when there is more than one geometric tile in a point cloud sequence / bitstream, a restriction can be added that each such tile should reference the same GPS. The G-PCC encoder 200 can apply these restrictions.

[0376] In one example, the range of values ​​for gsh_geometry_parameter_set_id is specified, and geometric tiles in the same frame are restricted from referencing the same GPS.

[0377] gsh_geometry_parameter_set_id specifies the value of gps_geom_parameter_set_id for the active GPS. <change>The value of gsh_geometry_parameter_set_id should be in the range of 0 to 15, including the endpoints.

[0378] When more than one geometry slice is associated with a frame, the value of gsh_geometry_parameter_set_id should be the same for all geometry slices associated with that frame.< / change>

[0379] Alternatively, the following could be added to the G-PCC draft standard: When more than one geometry tile is associated with a tile, the value of gsh_geometry_parameter_set_id should be the same for all geometry tiles associated with that tile.

[0380] Now we discuss attribute slices that reference parameter sets. In the G-PCC draft standard, an attribute slice contains `ash_attr_parameter_set_id`, which is the identifier of the APS that the slice references. There is no restriction on the range of values ​​for `ash_attr_parameter_set_id`. The value of `aps_attr_parameter_set_id` (a separate syntax element in the APS, not ASH) is in the range of 0 to 15, including the endpoints.

[0381] Furthermore, according to the G-PCC standard draft, each attribute slice (of a specific attribute) in a point cloud frame / tile is allowed to reference any APS (because each attribute slice in a frame / tile can signal any valid value of ash_attr_parameter_set_id). While there may be some special use cases that require this flexibility, it is meaningless for most typical cases. This flexibility also forces decoders (e.g., the G-PCC decoder 300) to perform consistency checks to test all possible combinations (different values ​​of APS syntax elements in different APSs referenced by the same frame). This increases the cost for decoder manufacturers.

[0382] According to the technology disclosed herein, in one example, a restriction can be added such that the value of ash_attr_parameter_set_id should be in the range of 0 to 15, including the endpoint. For example, the G-PCC encoder 200 can encode the value of ash_attr_parameter_set_id to be in the range of 0 to 15.

[0383] When more than one attribute tile with the same attribute exists within a tile (e.g., ash_attr_sps_attr_idx), a restriction can be added that each such tile should refer to the same GPS. In one example, when multiple attribute tiles with the same attribute exist within a frame (e.g., ash_attr_sps_attr_idx), a restriction can be added that each such tile should reference the same GPS. In another example, when more than one attribute tile with the same attribute exists within a point cloud sequence / bitstream (e.g., ash_attr_sps_attr_idx), a restriction can be added that each such tile should reference the same GPS. The G-PCC encoder 200 can apply these restrictions.

[0384] In one example, the range of values ​​for ash_attr_parameter_set_id is specified, and attribute slices (with the same attribute type or index) within the same frame are restricted from referencing the same APS.

[0385] The `ash_attr_parameter_set_id` specifies the value of `aps_attr_parameter_set_id` for the active APS. The value of `ash_attr_parameter_set_id` should be in the range of 0 to 15, including the endpoint.

[0386] <change>When more than one attribute slice is associated with a frame, the value of ash_attr_parameter_set_id should be the same for all attribute slices associated with that frame that have the same ash_attr_sps_attr_idx value.< / change>

[0387] Alternatively, the following could be added to the G-PCC draft standard: When more than one attribute tile is associated with a tile, the value of ash_attr_parameter_set_id should be the same for all attribute tiles associated with a tile that has the same ash_attr_sps_attr_idx value.

[0388] Figure 7This is a flowchart illustrating example region box and slice bounding box techniques according to this disclosure. The G-PCC decoder 300 can determine the size of the region box (700). For example, the G-PCC decoder 300 can parse syntax elements indicating the region box size. The G-PCC decoder 300 can determine the size of the slice bounding box (702). For example, the G-PCC decoder 300 can parse syntax elements indicating the slice bounding box size. The G-PCC decoder 300 can decode slices of point cloud data associated with the slice bounding box (704). For example, the G-PCC decoder 300 can decode slices within the slice bounding box. The size of the region bounding box can be restricted to not exceed the size of the slice bounding box. For example, ensuring that the size of the region bounding box does not exceed the size of the slice bounding box can be a bitstream consistency requirement. In some examples, the size of the region box is constrained such that no point within the region box is outside the slice bounding box.

[0389] Figure 8 This is a flowchart illustrating an example slice identifier technique according to this disclosure. The G-PCC decoder 300 can determine a first slice ID (800) of a first geometric slice associated with a frame of point cloud data. For example, the G-PCC decoder 300 can parse the syntax elements of the first slice ID indicating the first geometric slice of the frame. The G-PCC decoder 300 can determine a second slice ID (802) of a second geometric slice associated with a frame of point cloud data. For example, the G-PCC decoder 300 can parse the syntax elements of the second slice ID indicating the second geometric slice of the frame. Based on the fact that the second slice ID is equal to the first slice ID, the G-PCC decoder 300 can determine that the second slice contains the same content as the first slice (804). For example, a bitstream consistency requirement could be that if the first geometric slice of a frame of point cloud data has the same slice ID as the second geometric slice of that frame, then the content of the first and second geometric slices is the same. The G-PCC decoder 300 can decode the point cloud data based on the first slice ID (806). For example, the G-PCC decoder 300 can decode both the first and second geometric slices based on the first slice ID.

[0390] Figure 9This is a flowchart illustrating an example of an incremental quantization parameter technique according to this disclosure. The G-PCC decoder 300 can determine whether the attribute dimension of an attribute is greater than 1 (900). For example, the G-PCC decoder 300 can parse syntax elements indicating whether the attribute dimension in the sequence parameter set is greater than 1. Based on the attribute dimension being greater than 1, the G-PCC decoder 300 can parse attribute slice header syntax elements indicating incremental quantization parameters (902). For example, the G-PCC decoder 300 can parse ash_attr_qp_delta_secondary (or ash_attr_qp_delta_chroma) in the attribute slice header. The G-PCC decoder 300 can decode point cloud data based on incremental quantization parameters (904). In some examples, as part of determining whether the attribute dimension is greater than 1, the G-PCC decoder 300 can parse syntax elements in the sequence parameter set.

[0391] In some examples, the G-PCC decoder 300 can determine the slice dimension, parse the trisoup node size syntax element indicating the node size to be decoded in trisoup decoding mode, and decode the point cloud data based on the node size. In these examples, the value of the trisoup node size syntax element can be restricted to not exceeding the slice dimension.

[0392] In some examples, the G-PCC decoder 300 can parse attribute slice header syntax elements indicating the application of incremental quantization parameters to several regions, and decode point cloud data based on said regions. In these examples, the values ​​of the attribute slice header syntax elements can be restricted to the range of 0 to N, where N is a predetermined value (e.g., 4 or 8 or some other value). The number of regions can be decoded using exponential Golomb codes (e.g., ue(v)).

[0393] In some examples, the G-PCC decoder 300 can parse the geometry slice header syntax element that indicates a geometry parameter set identifier. In these examples, the value of the geometry slice header syntax element is restricted to a range of 0 to 15, including the endpoints. In some examples, the G-PCC decoder can further decode the point cloud data based on the geometry parameter set identified by the geometry parameter set identifier.

[0394] In some examples, the G-PCC decoder 300 can parse the attribute slice header syntax element that indicates the attribute parameter set identifier. In these examples, the value of the attribute slice header syntax element can be restricted to a range of 0 to 15, including the endpoints. In some examples, the G-PCC decoder can further decode the point cloud data based on the attribute parameter set identified by the attribute parameter set identifier.

[0395] Examples from various aspects of this disclosure may be used individually or in any combination.

[0396] This disclosure includes the following examples.

[0397] Clause 1. A method for decoding point cloud data, the method comprising: limiting a region box to a size not exceeding that of a slice bounding box; and decoding a slice of the point cloud data associated with the slice bounding box.

[0398] Clause 2. The method according to Clause 1, wherein the restriction on the region box includes: restricting the region box such that no point in the region box is outside the slice bounding box.

[0399] Clause 3. The method described in Clause 1 or 2 further includes: avoiding signaling a value of 0 for the width, height, or depth of the region frame.

[0400] Clause 4. A method for decoding point cloud data, the method comprising: associating a tile_inventory() syntax element with a frame of the point cloud data; and decoding the frame based on the tile_inventory() syntax element.

[0401] Clause 5, the method described in Clause 4, further includes: signaling the tile_inventory() syntax element.

[0402] Clause 6. The method according to Clause 4, wherein associating the tile_inventory() syntax element with the frame comprises: determining whether a frame index associated with the frame has a value equivalent to the tile_inventory() syntax element; and associating the tile_inventory() syntax element with the frame based on the fact that the frame index has a value equivalent to the tile_inventory() syntax element.

[0403] Clause 7. The method according to any combination of Clauses 4-6 further comprises: constraining the value of tile_id in the geometry slice header to a range of 0 to N (inclusive), wherein the value of N is less than 1 than the number of tiles signaled in the tile_inventory() syntax element associated with the frame.

[0404] Clause 8. A method for decoding point cloud data, the method comprising: determining whether multiple slices exist in a tile associated with a frame; determining one or more syntax elements based on the existence of multiple slices in the tile; and decoding the point cloud data based on the syntax elements.

[0405] Clause 9. The method according to Clause 8 further includes: determining whether two geometric slices have different gsh_slice_id values ​​for the tile; and determining that the value of gps_box_present_flag is 1 based on the fact that the two geometric slices have different gsh_slice_id values.

[0406] Clause 10. The method according to Clause 8 further includes: determining whether two geometric slices have different gsh_slice_id values ​​and the same tile ID and the same frame index; and determining that the value of gps_box_present_flag is 1 based on the fact that the two geometric slices have different gsh_slice_id values, the same tile ID and the same frame index.

[0407] Clause 11. A method for decoding point cloud data, the method comprising: determining a slice dimension; limiting the value of log2_tisoup_node_size to no more than the slice dimension; and decoding the point cloud data based on the log2_tisoup_node_size.

[0408] Clause 12, the method according to Clause 11, wherein the value of gsh_log2_max_nodesize is greater than or equal to the value of log2_tisoup_node_size.

[0409] Clause 13. The method described in Clause 11, wherein when gps_implicit_geom_partition_flag equals 1, the value of the log2_trisoup_node_size syntax element is less than or equal to min(gsh_log2_max_nodesize_x, gsh_log2_max_nodesize_y, gsh_log2_max_nodesize_z), and otherwise is greater than or equal to gsh_log2_max_nodesize.

[0410] Clause 14. A method for decoding point cloud data, the method comprising: determining whether two geometric slices associated with a frame of the point cloud data have the same slice ID; restricting the two geometric slices to having the same content based on the fact that the two geometric slices have the same slice ID; and decoding the point cloud data based on the restriction.

[0411] Clause 15. A method for decoding point cloud data, the method comprising: determining whether two geometric slices are associated with the same frame; restricting the two geometric slices to have the same slice ID value based on the fact that the two geometric slices are associated with the same frame; and decoding the point cloud data based on each slice ID.

[0412] Clause 16. A method for decoding point cloud data, the method comprising: determining whether all points in the point cloud are associated with a corresponding unique point; restricting a slice to contain two points associated with the same location based on the fact that all points in the point cloud are associated with a corresponding unique point; and decoding the point cloud data based on the restriction.

[0413] Clause 17, the method described in Clause 16, further includes: restricting the signaling of a syntax element that indicates a slice containing two points associated with the same location.

[0414] Clause 18. A method for decoding point cloud data, the method comprising: determining a color-related syntax element; signaling the color-related syntax element of a color attribute; preventing the use of the color-related syntax element for other purposes; and decoding the point cloud data based on the color-related syntax element.

[0415] Clause 19. The method described in Clause 18 further includes: determining whether known_attribute_label_flag is 0; based on known_attribute_label_flag being 0, excluding known attributes in attribute_label_four_bytes.

[0416] Clause 20, the method described pursuant to Clause 18, further includes: representing each attribute only in attribute_label_four_bytes.

[0417] Clause 21. A method for decoding point cloud data, the method comprising: determining whether an attribute dimension is greater than 1; based on the attribute dimension being greater than 1, sending a signal to a set of attribute parameters to notify a flag; and based on the flag, decoding the point cloud data.

[0418] Clause 22. The method described in Clause 21 further includes: restricting the value of the flag to a value that does not conflict with the number of attribute dimensions used to signal the attribute.

[0419] Clause 23. A method for decoding point cloud data, the method comprising: avoiding signaling region_qp_delta; signaling region_qp_delta_abs_minus1 and region_qp_delta_sign; and decoding the point cloud data based on region_qp_delta_abs_minus1 and region_qp_delta_sign.

[0420] Clause 24. The method described in Clause 23 further includes: determining the number of regions to which deltaQP will be applied; and concurrently signaling a syntax element indicating the number of regions to which deltaQP will be applied.

[0421] Clause 25. A method for decoding point cloud data, the method comprising: providing a common level of detail (LoD) parameter set (CPS); determining LoD syntax elements; and decoding the point cloud data based on the LoD syntax elements.

[0422] Clause 25.5, the method according to Clause 25, wherein, based on the LoD syntax element being equal to 2, all properties decoded with the LoD syntax element being equal to 2 are decoded to have improved scalability.

[0423] Clause 26. The method according to Clause 25 further includes: determining whether an overriding flag exists in the Attribute Parameter Set (APS); and determining, based on the absence of an overriding flag in the APS, that a Common Parameter Set (CPS) parameter is equal to the corresponding APS parameter.

[0424] Clause 27. The method described in accordance with Clause 25 or 26 further includes: determining that the attribute encoding type and the enhancement scalability enable flag are equal for the APS and the CPS.

[0425] Clause 28. The method described in any combination of Clauses 25-27 further includes: signaling an indication of the CPS ID corresponding to the attribute.

[0426] Clause 29, the method described in Clause 28, wherein the CPS ID is in one of the APS or Attribute Slice Header (ASH).

[0427] Clause 30, the method described in accordance with Clause 28 or 29, further includes: determining whether aps_lod_parameters_override_flag is equal to 0; and signaling the CPS ID based on the fact that aps_lod_parameters_override_flag is equal to 0.

[0428] Clause 31. The method described in any combination of Clauses 25-30 further includes: determining whether aps_lod_parameters_override_flag was not signaled; avoiding signaling APS parameters based on the absence of signaling aps_lod_parameters_override_flag; and deriving parameters from the CPS for use in the attribute.

[0429] Clause 31.1, a method for decoding point cloud data, the method comprising: determining whether there is more than one geometric slice in a tile; restricting each geometric slice in the tile to refer to the same GPS based on the presence of more than one geometric slice in the tile; and decoding the point cloud data based on the GPS.

[0430] Clause 31.2, a method for decoding point cloud data, the method comprising: determining whether there is more than one attribute tile in a tile; restricting each geometric tile in the tile to refer to the same GPS based on the presence of more than one attribute tile; and decoding the point cloud data based on the GPS.

[0431] Clause 32. The method described under any one of Clauses 1-31.2 further includes: generating the point cloud.

[0432] Clause 33. An apparatus for processing point clouds, the apparatus comprising: one or more units for performing the method described in any one of Clauses 1-32.

[0433] Clause 34. The device according to Clause 33, wherein the one or more units include one or more processors implemented in a circuit.

[0434] Clause 35. The device according to any one of Clauses 33 or 34 further includes: a memory for storing the data representing the point cloud.

[0435] Clause 36. The device described in any one of Clauses 33-35, wherein the device includes a decoder.

[0436] Clause 37. The device according to any one of Clauses 33-36, wherein the device includes an encoder.

[0437] Clause 38. The apparatus described in any one of Clauses 33-37 further includes: an apparatus for generating the point cloud.

[0438] Clause 39. The device according to any one of Clauses 33-38 further includes: a display for presenting an image based on the point cloud.

[0439] Clause 40. A computer-readable storage medium having instructions stored thereon, which, when executed, cause one or more processors to perform the method described in any one of Clauses 1-32.

[0440] Clause 41. A method for decoding point cloud data, the method comprising: determining the size of a region bounding box; determining the size of a slice bounding box; and decoding a slice of the point cloud data associated with the slice bounding box, wherein the size of the region bounding box is limited to not exceeding the size of the slice bounding box.

[0441] Clause 42. The method according to Clause 41, wherein the size of the region box is limited such that no point within the region box is outside the slice bounding box.

[0442] Clause 43. The method according to Clause 41 or 42 further includes: determining the slice dimension; parsing a trisoup node size syntax element indicating the size of a node decoded in trisoup decoding mode; and decoding the point cloud data based on the size of the node, wherein the value of the trisoup node size syntax element is restricted to not exceeding the slice dimension.

[0443] Clause 44. The method according to any combination of Clauses 41-43 further comprises: parsing attribute slice header syntax elements indicating that incremental quantization parameters will be applied to a plurality of regions; and decoding the point cloud data based on the plurality of regions, wherein the values ​​of the attribute slice header syntax elements are restricted to the range of 0 to N, where N is a predetermined value.

[0444] Clause 45. The method according to any combination of clauses 41-44 further comprises: parsing a geometry slice header syntax element indicating a geometry parameter set identifier, wherein the value of the geometry slice header syntax element is restricted to a range of 0 to 15 including endpoints, and wherein the decoding of the point cloud data is further based on a geometry parameter set identified by the geometry parameter set identifier.

[0445] Clause 46. The method according to any combination of Clauses 41-45 further comprises: parsing an attribute slice header syntax element that indicates an attribute parameter set identifier, wherein the value of the attribute slice header syntax element is restricted to a range of 0 to 15 including endpoints, wherein the decoding of the point cloud data is further based on the attribute parameter set identified by the attribute parameter set identifier.

[0446] Clause 47. A method for decoding point cloud data, the method comprising: determining a first slice identifier (ID) of a first geometric slice associated with a frame of the point cloud data; determining a second slice ID of a second geometric slice associated with the frame of the point cloud data; determining, based on the second slice ID being equal to the first slice ID, that the second slice contains the same content as the first slice; and decoding the point cloud data based on the first slice ID.

[0447] Clause 48. The method according to Clause 47 further includes: determining the slice dimension; parsing a trisoup node size syntax element indicating the size of a node decoded in trisoup decoding mode; and decoding the point cloud data based on the size of the node, wherein the value of the trisoup node size syntax element is restricted to not exceeding the slice dimension.

[0448] Clause 49. The method according to Clause 47 or 48 further comprises: parsing attribute slice header syntax elements indicating that incremental quantization parameters will be applied to several regions; and decoding the point cloud data based on said several regions, wherein the values ​​of the attribute slice header syntax elements are restricted to the range of 0 to N, where N is a predetermined value.

[0449] Clause 50, the method according to any combination of clauses 47-49, further comprises: parsing a geometry slice header syntax element indicating a geometry parameter set identifier, wherein the value of the geometry slice header syntax element is restricted to a range of 0 to 15 including endpoints, and wherein the decoding of the point cloud data is further based on a geometry parameter set identified by the geometry parameter set identifier.

[0450] Clause 51, the method according to any combination of clauses 47-50, further comprising: parsing an attribute slice header syntax element indicating an attribute parameter set identifier, wherein the value of the attribute slice header syntax element is restricted to a range of 0 to 15 including endpoints, and wherein the decoding of the point cloud data is further based on an attribute parameter set identified by the attribute parameter set identifier.

[0451] Clause 52. A method for decoding point cloud data, the method comprising: determining whether the attribute dimension of an attribute is greater than 1; parsing an attribute slice header syntax element indicating an incremental quantization parameter based on the attribute dimension being greater than 1; and decoding the point cloud data based on the incremental quantization parameter.

[0452] Clause 53. The method according to Clause 52, wherein determining whether the attribute dimension is greater than 1 includes: parsing the syntax elements in the sequence parameter set.

[0453] Clause 54. The method according to Clause 52 or 53 further comprises: determining the slice dimension; parsing a trisoup node size syntax element indicating the size of a node decoded in trisoup decoding mode; and decoding the point cloud data based on the size of the node, wherein the value of the trisoup node size syntax element is restricted to not exceeding the slice dimension.

[0454] Clause 55, the method according to any combination of Clauses 52-54, further comprising: parsing attribute slice header syntax elements indicating that incremental quantization parameters will be applied to a plurality of regions; and decoding the point cloud data based on said plurality of regions, wherein the values ​​of the attribute slice header syntax elements are restricted to the range of 0 to N, where N is a predetermined value.

[0455] Clause 56. The method according to any combination of clauses 52-55 further comprises: parsing a geometry slice header syntax element indicating a geometry parameter set identifier, wherein the value of the geometry slice header syntax element is restricted to a range of 0 to 15 including endpoints, and wherein the decoding of the point cloud data is further based on a geometry parameter set identified by the geometry parameter set identifier.

[0456] Clause 57. The method according to any combination of Clauses 52-56 further comprises: parsing an attribute slice header syntax element that indicates an attribute parameter set identifier, wherein the value of the attribute slice header syntax element is restricted to a range of 0 to 15 including endpoints, wherein the decoding of the point cloud data is further based on the attribute parameter set identified by the attribute parameter set identifier.

[0457] Clause 58. An apparatus for decoding point cloud data, the apparatus comprising: a memory configured to store point cloud data; and one or more processors implemented in a circuit and coupled to the memory, the one or more processors being configured to: determine the size of a region box; determine the size of a slice bounding box; and decode a slice of the point cloud data associated with the slice bounding box, wherein the size of the region box is limited to not exceeding the size of the slice bounding box.

[0458] Clause 59. The device according to Clause 58, wherein the size of the region box is limited such that no point within the region box is outside the slice boundary box.

[0459] Clause 60. The apparatus according to Clause 58 or 59, wherein the one or more processors are further configured to: determine the slice dimension; parse a trisoup node size syntax element indicating the size of a node decoded in trisoup decoding mode; and decode the point cloud data based on the size of the node, wherein the value of the trisoup node size syntax element is restricted to not exceeding the slice dimension.

[0460] Clause 61. The device according to any combination of clauses 58-60, wherein the one or more processors are further configured to: parse attribute slice header syntax elements indicating that incremental quantization parameters will be applied to several regions; and decode the point cloud data based on the several regions, wherein the values ​​of the attribute slice header syntax elements are restricted to the range of 0 to N, where N is a predetermined value.

[0461] Clause 62. The device according to any combination of clauses 58-61, wherein the one or more processors are further configured to: parse a geometry slice header syntax element indicating a geometry parameter set identifier, wherein the value of the geometry slice header syntax element is restricted to a range of 0 to 15 including endpoints, and wherein the decoding of the point cloud data by the one or more processors is further based on a geometry parameter set identified by the geometry parameter set identifier.

[0462] Clause 63. The device according to any combination of clauses 58-62, wherein the one or more processors are further configured to: parse an attribute slice header syntax element indicating an attribute parameter set identifier, wherein the value of the attribute slice header syntax element is restricted to a range of 0 to 15 including endpoints, and wherein the decoding of the point cloud data by the one or more processors is further based on an attribute parameter set identified by the attribute parameter set identifier.

[0463] Clause 64. An apparatus for decoding point cloud data, the apparatus comprising: a memory configured to store point cloud data; and one or more processors implemented in a circuit and coupled to the memory, the one or more processors being configured to: determine a first slice identifier (ID) of a first geometric slice associated with a frame of the point cloud data; determine a second slice ID of a second geometric slice associated with the frame of the point cloud data; determine, based on the second slice ID being equal to the first slice ID, that the second slice contains the same content as the first slice; and decode the point cloud data based on the first slice ID.

[0464] Clause 65. The apparatus according to Clause 64, wherein the one or more processors are further configured to: determine the slice dimension; parse a trisoup node size syntax element indicating the size of a node decoded in trisoup decoding mode; and decode the point cloud data based on the size of the node, wherein the value of the trisoup node size syntax element is restricted to not exceeding the slice dimension.

[0465] Clause 66. The device according to Clause 64 or 65, wherein the one or more processors are further configured to: parse attribute slice header syntax elements indicating that incremental quantization parameters will be applied to several regions; and decode the point cloud data based on the several regions, wherein the values ​​of the attribute slice header syntax elements are restricted to the range of 0 to N, where N is a predetermined value.

[0466] Clause 67. The device according to any combination of Clauses 64-66, wherein the one or more processors are further configured to: parse a geometry slice header syntax element indicating a geometry parameter set identifier, wherein the value of the geometry slice header syntax element is restricted to a range of 0 to 15 including endpoints, and wherein the decoding of the point cloud data by the one or more processors is further based on a geometry parameter set identified by the geometry parameter set identifier.

[0467] Clause 68. The device according to any combination of Clauses 64-67, wherein the one or more processors are further configured to: parse an attribute slice header syntax element indicating an attribute parameter set identifier, wherein the value of the attribute slice header syntax element is restricted to a range of 0 to 15 including endpoints, and wherein the decoding of the point cloud data by the one or more processors is further based on an attribute parameter set identified by the attribute parameter set identifier.

[0468] Clause 69. An apparatus for decoding point cloud data, the apparatus comprising: a memory configured to store point cloud data; and one or more processors implemented in a circuit and coupled to the memory, the one or more processors being configured to: determine whether an attribute dimension of an attribute is greater than 1; parse an attribute slice header syntax element indicating incremental quantization parameters based on the attribute dimension being greater than 1; and decode the point cloud data based on the incremental quantization parameters.

[0469] Clause 70, the device according to Clause 69, wherein, as part of determining whether the attribute dimension is greater than 1, the one or more processors are configured to parse syntactic elements in the sequence parameter set.

[0470] Clause 71. The device according to Clause 69 or 70, wherein the one or more processors are further configured to: determine the slice dimension; parse a trisoup node size syntax element indicating the size of a node decoded in trisoup decoding mode; and decode the point cloud data based on the size of the node, wherein the value of the trisoup node size syntax element is restricted to not exceeding the slice dimension.

[0471] Clause 72. The device according to any combination of Clauses 69-71, wherein the one or more processors are further configured to: parse attribute slice header syntax elements indicating that incremental quantization parameters will be applied to several regions; and decode the point cloud data based on the several regions, wherein the values ​​of the attribute slice header syntax elements are restricted to the range of 0 to N, where N is a predetermined value.

[0472] Clause 73. The device according to any combination of clauses 69-72, wherein the one or more processors are further configured to: parse a geometry slice header syntax element indicating a geometry parameter set identifier, wherein the value of the geometry slice header syntax element is restricted to a range of 0 to 15 including endpoints, and wherein the decoding of the point cloud data by the one or more processors is further based on a geometry parameter set identified by the geometry parameter set identifier.

[0473] Clause 74. The device according to any combination of clauses 69-73, wherein the one or more processors are further configured to: parse an attribute slice header syntax element indicating an attribute parameter set identifier, wherein the value of the attribute slice header syntax element is restricted to a range of 0 to 15 including endpoints, and wherein the decoding of the point cloud data by the one or more processors is further based on an attribute parameter set identified by the attribute parameter set identifier.

[0474] It should be recognized that, based on the examples, certain actions or events of any technique described herein may be performed in a different order, may be added, combined, or omitted entirely (e.g., not all described actions or events are necessary for implementing the technique). Furthermore, in some examples, actions or events may be performed concurrently rather than sequentially, for example, through multithreading, interrupt handling, or multiple processors.

[0475] In one or more examples, the described functionality may be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions may be stored on a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. A computer-readable medium may include a computer-readable storage medium, which corresponds to a tangible medium such as a data storage medium or a communication medium, wherein a communication medium includes any medium that facilitates, for example, the transfer of a computer program from one place to another according to a communication protocol. In this way, a computer-readable medium may generally correspond to: (1) a non-transitory tangible computer-readable storage medium; or (2) a communication medium such as a signal or carrier waveform. A data storage medium may be any available medium accessible to one or more computers or one or more processors to obtain instructions, code, and / or data structures for implementing the techniques described in this disclosure. Computer program products may include computer-readable media.

[0476] For example, but not limitingly, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disc storage, disk storage or other magnetic storage devices, flash memory, or any other medium capable of storing desired program code in the form of instructions or data structures and accessible by a computer. Furthermore, any connection may be appropriately referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, wireless, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, wireless, and microwave are included in the definition of medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waveforms, signals, or other temporary media, but rather refer to non-temporary tangible storage media. As used herein, disks and optical discs include compact optical discs (CDs), laser discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs, where disks typically magnetically copy data, while optical discs optically copy data using lasers. The above combinations should also be included within the scope of protection of computer-readable media.

[0477] Instructions can be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Therefore, as used herein, the terms "processor" and "processing circuitry" can refer to the foregoing structures or any other structures suitable for implementing the techniques described herein. Furthermore, in some aspects, the functionality described herein can be provided in dedicated hardware and / or software modules configured to implement encoding and decoding, or incorporated into combined codecs. Moreover, these techniques can be fully implemented in one or more circuit or logic elements.

[0478] The techniques disclosed herein can be implemented using a wide variety of devices or apparatuses, including wireless handheld devices, integrated circuits (ICs), or a set of ICs (e.g., chipsets). Various components, modules, or units are described in this disclosure to emphasize functional aspects of a device configured to perform the disclosed techniques, but they do not necessarily need to be implemented by separate hardware units. Rather, as described above, the individual units can be combined in a codec hardware unit or provided through a cooperating set of hardware units (including one or more processors as described above) combined with appropriate software and / or firmware.

[0479] Various examples are described. These and other examples fall within the scope of protection of the appended claims.

Claims

1. A method for decoding point cloud data, the method comprising: Determine a first slice identifier (ID) for a first geometric slice associated with a frame of the point cloud data, wherein the first geometric slice includes first content; Determine a second slice ID of a second geometric slice associated with the frame of the point cloud data, wherein the second geometric slice includes second content; Based on the fact that the second slice ID is equal to the first slice ID, it is determined that the first content contained in the first slice is the same as the second content contained in the second slice; as well as The point cloud data is decoded based on the first slice ID.

2. The method according to claim 1, further comprising: Determine the slice dimensions; Parse the trisoup node size syntax element that indicates the size of the node to be decoded in trisoup decoding mode; as well as Based on the size of the node, the point cloud data is decoded. Specifically, the value of the trisoup node size syntax element is restricted to not exceeding the slice dimension.

3. The method according to claim 1, further comprising: Parse the attribute slice header syntax elements of several regions that indicate the application of incremental quantization parameters; as well as Based on the aforementioned regions, the point cloud data is decoded. The value of the attribute slice header syntax element is restricted to the range of 0 to N, where N is a predetermined value.

4. The method according to claim 1, further comprising: Parse the geometry slice header syntax element that indicates the geometry parameter set identifier. The values ​​of the geometric slice header syntax elements are restricted to a range of 0 to 15, including the endpoints, and the decoding of the point cloud data is further based on a set of geometric parameters identified by the geometric slice header syntax elements.

5. The method according to claim 1, further comprising: Parse the attribute slice header syntax elements that indicate the attribute parameter set identifier. The values ​​of the attribute slice header syntax elements are restricted to a range of 0 to 15, including the endpoints, and the decoding of the point cloud data is further based on the attribute parameter set identified by the attribute parameter set identifier.

6. The method according to claim 1, further comprising: Determine the size of the region bounding box; Determine the dimensions of the slice bounding box; as well as Decode the third slice of the point cloud data associated with the slice bounding box. The size of the region box is limited to not exceeding the size of the slice boundary box.

7. The method according to claim 6, wherein, The size of the region box is restricted such that no point within the region box is outside the slice boundary box.

8. The method according to claim 6, further comprising: Determine the slice dimensions; Parse the trisoup node size syntax element that indicates the size of the node to be decoded in trisoup decoding mode; as well as Based on the size of the node, the point cloud data is decoded. Specifically, the value of the trisoup node size syntax element is restricted to not exceeding the slice dimension.

9. The method according to claim 6, further comprising: Parse the attribute slice header syntax elements of several regions that indicate the application of incremental quantization parameters; as well as Based on the aforementioned regions, the point cloud data is decoded. The value of the attribute slice header syntax element is restricted to the range of 0 to N, where N is a predetermined value.

10. The method of claim 6, further comprising: Parse the syntax elements of the geometric slice header that identify the set of geometric parameters. The values ​​of the geometric slice header syntax elements are restricted to a range of 0 to 15, including the endpoints, and the decoding of the point cloud data is further based on a set of geometric parameters identified by the geometric slice header syntax elements.

11. The method of claim 6, further comprising: Parse the attribute slice header syntax elements that identify the attribute parameter set. The value of the attribute slice header syntax element is restricted to a range of 0 to 15, including the endpoints, and the decoding of the point cloud data is further based on the set of attribute parameters identified by the attribute slice header syntax element.

12. The method according to claim 1, further comprising: Determine if the attribute dimension is greater than 1; Based on the fact that the attribute dimension is greater than 1, the attribute slice header syntax element indicating the incremental quantization parameter is parsed. as well as The point cloud data is decoded based on the incremental quantization parameters.

13. The method according to claim 12, wherein, Determining whether the attribute dimension is greater than 1 includes parsing the syntax elements in the sequence parameter set.

14. The method of claim 12, further comprising: Determine the slice dimensions; Parse the trisoup node size syntax element that indicates the size of the node to be decoded in trisoup decoding mode; as well as Based on the size of the node, the point cloud data is decoded. Specifically, the value of the trisoup node size syntax element is restricted to not exceeding the slice dimension.

15. The method of claim 12, further comprising: The attribute slice header syntax elements of several regions that indicate the application of the incremental quantization parameters are parsed; as well as Based on the aforementioned regions, the point cloud data is decoded. The value of the attribute slice header syntax element is restricted to the range of 0 to N, where N is a predetermined value.

16. The method of claim 12, further comprising: Parse the geometry slice header syntax element that indicates the geometry parameter set identifier. The values ​​of the geometric slice header syntax elements are restricted to a range of 0 to 15, including the endpoints, and the decoding of the point cloud data is further based on a geometric parameter set identified by the geometric parameter set identifier.

17. The method of claim 12, further comprising: Parse the attribute slice header syntax elements that indicate the attribute parameter set identifier. The values ​​of the attribute slice header syntax elements are restricted to a range of 0 to 15, including the endpoints, and the decoding of the point cloud data is further based on the attribute parameter set identified by the attribute parameter set identifier.

18. An apparatus for decoding point cloud data, the apparatus comprising: A memory configured to store the point cloud data; as well as One or more processors are implemented in the circuit and coupled to the memory, the one or more processors being configured to: Determine a first slice identifier (ID) for a first geometric slice associated with a frame of the point cloud data, wherein the first geometric slice includes first content; Determine a second slice ID of a second geometric slice associated with the frame of the point cloud data, wherein the second geometric slice includes second content; Based on the fact that the second slice ID is equal to the first slice ID, it is determined that the first content contained in the first slice is the same as the second content contained in the second slice; as well as The point cloud data is decoded based on the first slice ID.

19. The device according to claim 18, wherein, The one or more processors are further configured to: Determine the slice dimensions; Parse the trisoup node size syntax element that indicates the node size decoded in trisoup decoding mode; and Based on the size of the node, the point cloud data is decoded. Specifically, the value of the trisoup node size syntax element is restricted to not exceeding the slice dimension.

20. The device according to claim 18, wherein, The one or more processors are further configured to: Parse the attribute slice header syntax elements that indicate the application of incremental quantization parameters to several regions; and Based on the aforementioned regions, the point cloud data is decoded. The value of the attribute slice header syntax element is restricted to the range of 0 to N, where N is a predetermined value.

21. The device according to claim 18, wherein, The one or more processors are further configured to: Parse the geometry slice header syntax element that indicates the geometry parameter set identifier. The values ​​of the geometric slice header syntax elements are restricted to a range of 0 to 15, including endpoints, and the decoding of the point cloud data by the one or more processors is further based on a geometric parameter set identified by the geometric parameter set identifier.

22. The device according to claim 18, wherein, The one or more processors are further configured to: Parse the attribute slice header syntax elements that indicate the attribute parameter set identifier. The values ​​of the attribute slice header syntax elements are restricted to a range of 0 to 15, including the endpoints, and the decoding of the point cloud data by the one or more processors is further based on an attribute parameter set identified by the attribute parameter set identifier.

23. The device of claim 18, wherein the one or more processors are configured to: Determine the size of the region bounding box; Determine the dimensions of the slice bounding box; and Decode the third slice of the point cloud data associated with the slice bounding box. in, The size of the region box is limited to not exceeding the size of the slice boundary box.

24. The device according to claim 23, wherein, The size of the region box is restricted such that no point within the region box is outside the slice boundary box.

25. The device according to claim 23, wherein, The one or more processors are further configured to: Determine the slice dimensions; Parse the trisoup node size syntax element that indicates the node size decoded in trisoup decoding mode; and Based on the size of the node, the point cloud data is decoded. Specifically, the value of the trisoup node size syntax element is restricted to not exceeding the slice dimension.

26. The device according to claim 23, wherein, The one or more processors are further configured to: Parse the attribute slice header syntax elements that indicate the application of incremental quantization parameters to several regions; and Based on the aforementioned regions, the point cloud data is decoded. The value of the attribute slice header syntax element is restricted to the range of 0 to N, where N is a predetermined value.

27. The device according to claim 23, wherein, The one or more processors are further configured to: Parse the syntax elements of the geometric slice header that identify the set of geometric parameters. The values ​​of the geometric slice header syntax elements are restricted to a range of 0 to 15, including endpoints, and the decoding of the point cloud data by the one or more processors is further based on a set of geometric parameters identified by the geometric slice header syntax elements.

28. The device according to claim 23, wherein, The one or more processors are further configured to: Parse the attribute slice header syntax elements that indicate the attribute parameter set identifier. The values ​​of the attribute slice header syntax elements are restricted to a range of 0 to 15, including the endpoints, and the decoding of the point cloud data by the one or more processors is further based on an attribute parameter set identified by the attribute parameter set identifier.

29. The device of claim 18, wherein the one or more processors are configured to: Determine if the attribute dimension is greater than 1; Based on the attribute dimension being greater than 1, the attribute slice header syntax elements indicating incremental quantization parameters are parsed; and The point cloud data is decoded based on the incremental quantization parameters.

30. The device according to claim 29, wherein, As part of determining whether the attribute dimension is greater than 1, the one or more processors are configured to parse the syntax elements in the sequence parameter set.

31. The device according to claim 29, wherein, The one or more processors are further configured to: Determine the slice dimensions; Parse the trisoup node size syntax element that indicates the node size decoded in trisoup decoding mode; and Based on the size of the node, the point cloud data is decoded. Specifically, the value of the trisoup node size syntax element is restricted to not exceeding the slice dimension.

32. The device according to claim 29, wherein, The one or more processors are further configured to: Parse the attribute slice header syntax elements that indicate the application of incremental quantization parameters to several regions; and Based on the aforementioned regions, the point cloud data is decoded. The value of the attribute slice header syntax element is restricted to the range of 0 to N, where N is a predetermined value.

33. The device according to claim 29, wherein, The one or more processors are further configured to: Parse the geometry slice header syntax element that indicates the geometry parameter set identifier. The values ​​of the geometric slice header syntax elements are restricted to a range of 0 to 15, including endpoints, and the decoding of the point cloud data by the one or more processors is further based on a geometric parameter set identified by the geometric parameter set identifier.

34. The device according to claim 29, wherein, The one or more processors are further configured to: Parse the attribute slice header syntax elements that indicate the attribute parameter set identifier. The values ​​of the attribute slice header syntax elements are restricted to a range of 0 to 15, including the endpoints, and the decoding of the point cloud data by the one or more processors is further based on an attribute parameter set identified by the attribute parameter set identifier.

Images