Coordinate transformation for geometric point cloud compression

Abstract

The point cloud encoder and the point cloud decoder are configured to convert Cartesian coordinates of points of the point cloud data to spherical coordinates. The spherical coordinates comprise a radius, an azimuth angle value and a laser ID (Identity). The point cloud encoder and the point cloud decoder may perform a conversion for the azimuth angle value using a variable shift value using a fixed point implementation based on the number of bits used to code the azimuth angle.

Description

[0001] This application claims priority to U.S. Patent Application No. 18 / 350,887, filed on July 12, 2023, and U.S. Provisional Patent Application No. 63 / 389,322, filed on July 14, 2022, the entire contents of which are incorporated herein by reference. U.S. Patent Application No. 18 / 350,887, filed on July 12, 2023, claims the benefit of U.S. Provisional Patent Application No. 63 / 389,322, filed on July 14, 2022. Technical Field

[0002] The present disclosure relates to point cloud encoding and decoding. Background Art

[0003] A point cloud is a collection of points in a three-dimensional space. These points can correspond to points on an object in the three-dimensional space. Therefore, a point cloud can be used to represent the physical content of the three-dimensional space. Point clouds can have utility in a wide variety of situations. For example, a point cloud can be used in the context of an autonomous vehicle to represent the location of an object on a road. In another example, a point cloud can be used in the context of representing the physical content of an environment in order to locate virtual objects in an augmented reality (AR) or mixed reality (MR) application. Point cloud compression is a process for encoding and decoding point clouds. Encoding a point cloud can reduce the amount of data required to store and send the point cloud. Summary of the invention

[0004] In general, this disclosure describes techniques for processing point cloud data. More specifically, this disclosure describes techniques for deriving azimuth angles from Cartesian coordinates for motion compensation of inter prediction in predictive geometric coding.

[0005] According to the technology of the present disclosure, the G-PCC encoder and the G-PCC decoder may be configured to derive an azimuth value from Cartesian coordinates using a fixed-point implementation, which includes applying a variable scaling factor (or variable shift). In some examples, the fixed-point implementation may also include applying an offset value associated with the scaling factor (shift) before applying the scaling (shift). Generally speaking, a G-PCC encoder or a G-PCC decoder may use a fixed-point implementation to derive an azimuth value of a point from the Cartesian coordinates of the point, which includes applying a variable scaling factor, and optionally includes applying an offset value before applying the scaling. In one example, the G-PCC encoder and the G-PCC decoder may derive the variable scaling factor (shift) to be applied based on the number of bits used to decode the azimuth value.

[0006] By using a variable shift value (and therefore a scaling factor) based on the number of bits used to decode the azimuth, the disclosed technique enables a more accurate conversion of Cartesian coordinates to azimuth values ​​in a fixed-point implementation. Using a fixed shift value, as opposed to the variable value disclosed herein, may result in inaccurate derivation of the azimuth value and increased coding efficiency.

[0007] In one example, the present disclosure describes a device configured to process point cloud data, the device comprising a memory and one or more processors coupled to the memory, the one or more processors being configured to: derive an azimuth value of a point based on Cartesian coordinates of the point using a fixed-point implementation, wherein the fixed-point implementation includes applying a variable shift value; and decode the point cloud data based on the azimuth value.

[0008] In another example, the present disclosure describes a method of processing point cloud data, the method comprising: deriving an azimuth value of a point from Cartesian coordinates of the point using a fixed-point implementation, wherein the fixed-point implementation includes applying a variable shift value; and decoding the point cloud data based on the azimuth value.

[0009] In another example, the present disclosure describes a non-transitory computer-readable storage medium that stores instructions that, when executed, cause one or more processors configured to process point cloud data to: derive an azimuth value of a point based on Cartesian coordinates of the point using a fixed-point implementation, wherein the fixed-point implementation includes applying a variable shift value; and decode the point cloud data based on the azimuth value.

[0010] In another example, the present disclosure describes an apparatus configured to process point cloud data, the apparatus comprising: a component for deriving an azimuth value of a point from Cartesian coordinates of the point using a fixed-point implementation, wherein the fixed-point implementation includes applying a variable shift value; and a component for decoding the point cloud data based on the azimuth value.

[0011] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 is a block diagram illustrating an example encoding and decoding system that may perform the techniques of this disclosure.

[0013] Figure 2 is a block diagram illustrating an example Geometric Point Cloud Compression (G-PCC) encoder.

[0014] Figure 3 is a block diagram illustrating an example G-PCC decoder.

[0015] Figure 4 is a conceptual diagram illustrating an example octree splitting for geometry coding.

[0016] Figure 5 A more detailed example Figure 2 Block diagram of an example geometry encoding unit.

[0017] Figure 6 A more detailed example Figure 2 Block diagram of an example attribute encoding unit.

[0018] Figure 7 A more detailed example Figure 3 Block diagram of an example geometry decoding unit.

[0019] Figure 8 A more detailed example Figure 3 Block diagram of an example attribute decoding unit.

[0020] Fig. 9 is a conceptual diagram illustrating an example of a prediction tree.

[0021] Fig. 10A and Fig. 10B is a conceptual diagram illustrating an example of a rotating light detection and ranging (LIDAR) acquisition model.

[0022] Fig.11 is a conceptual diagram illustrating an example of inter-frame prediction of a current point based on a point in a reference frame.

[0023] Fig.12 is a flow chart illustrating the operation of a G-PCC decoder.

[0024] Fig.13 is a conceptual diagram illustrating an example of an additional inter-frame predictor point obtained from a first point having an azimuth angle greater than the inter-frame predictor point.

[0025] Fig.14 is a flow chart illustrating an example motion compensation technique.

[0026] Fig.15 is a flow chart illustrating an example encoding technique of the present disclosure.

[0027] Fig.16 is a flow chart illustrating an example decoding technique of the present disclosure.

[0028] Fig.17 is a conceptual diagram illustrating an example ranging system that may be used with one or more techniques of this disclosure.

[0029] Fig.18is a conceptual diagram illustrating an example vehicle-based scenario in which one or more techniques of this disclosure may be used.

[0030] Fig.19 is a conceptual diagram illustrating an example extended reality system in which one or more techniques of this disclosure may be used.

[0031] Fig. 20 is a conceptual diagram illustrating an example mobile device system in which one or more techniques of this disclosure may be employed. DETAILED DESCRIPTION

[0032] When decoding point cloud data in some coding modes (such as inter prediction with angle mode for predictive geometric coding), the point cloud encoder and decoder can perform a Cartesian to spherical transformation on the coordinates of the points of the point cloud. Given the position (x, y, z) of a point in a Cartesian coordinate system, the point cloud encoder and decoder can use a floating point implementation to calculate the corresponding radius and azimuth in a spherical coordinate system. In other examples, the point cloud encoder and decoder can use a fixed point implementation to perform the Cartesian to spherical transformation. The processing of operations with real numbers is often challenging because floating point operations often vary with both hardware and software. For ease of deployment and to eliminate any ambiguity of floating point operations, fixed point operations are generally preferred in hardware implementations.

[0033] Floating-point operations typically use dedicated hardware or algorithms and handle overflow, underflow, and rounding errors. Fixed-point operations, on the other hand, can be performed using standard integer arithmetic, but may require additional considerations such as scaling and loss of precision. In general, floating-point operations are computationally more complex but benefit from dedicated hardware units, while fixed-point operations are simpler and require fewer resources.

[0034] Motion compensation for inter prediction in predictive geometric coding (e.g., G-PCC coding) may include steps to convert the coordinates of a point from Cartesian coordinates (e.g., (x, y, z)) to spherical coordinates (e.g., radius, azimuth, and laser ID (r, φ, i)). In one example, the G-PCC encoder and the G-PCC decoder may be configured to perform a Cartesian to Spherical conversion using a software tool (which uses floating point operations). However, some examples of G-PCC use fixed-point / integer implementations during attribute coding to convert from Cartesian coordinates to spherical coordinates (e.g., using the convertXyzToRpl tool). However, the fixed-point convertXyzToRpl technique is not directly applicable to all situations because the convertXyzToRpl technique uses a fixed scaling factor and offset. When azimuth values ​​are coded at different bit depths, the use of a fixed scaling factor results in inaccurate values ​​of the azimuth, which in turn affects the performance of inter prediction.

[0035] According to the technology of the present disclosure, the G-PCC encoder and the G-PCC decoder may be configured to derive an azimuth value from Cartesian coordinates using a fixed-point implementation, which includes applying a variable scaling factor (or variable shift). In some examples, the fixed-point implementation may also include applying an offset value associated with the scaling factor (shift) before applying the scaling (shift). Generally speaking, a G-PCC encoder or a G-PCC decoder may use a fixed-point implementation to derive an azimuth value of a point from the Cartesian coordinates of the point, which includes applying a variable scaling factor, and optionally includes applying an offset value before applying the scaling. In one example, the G-PCC encoder and the G-PCC decoder may derive the variable scaling factor (shift) to be applied based on the number of bits used to decode the azimuth value.

[0036] By using a variable shift value (and therefore a scaling factor) based on the number of bits used to decode the azimuth, the disclosed technique enables more accurate conversion of Cartesian coordinates to azimuth values ​​in a fixed-point implementation. In contrast to the variable value of the disclosed technique, the use of a fixed shift value may result in inaccurate derivation of the azimuth value during conversion, and thus may result in inaccuracies in the decoding process and / or reduced decoding efficiency.

[0037] Figure 1 is a block diagram illustrating an example encoding and decoding system 100 that can perform the techniques of the present disclosure. The techniques of the present disclosure are generally related to decoding (encoding and / or decoding) point cloud data, that is, supporting point cloud compression. Generally speaking, point cloud data includes any data used to process point clouds. The decoding can be effective in compressing and / or decompressing point cloud data.

[0038] like Figure 1 As shown, the system 100 includes a source device 102 and a destination device 116. The source device 102 provides encoded point cloud data to be decoded by the destination device 116. Figure 1 In the example of , source device 102 provides point cloud data to destination device 116 via computer-readable medium 110. Source device 102 and destination device 116 may include any of a wide range of devices, including desktop computers, notebook (i.e., laptop) computers, tablet computers, set-top boxes, telephone handsets (such as smartphones), televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, ground or sea vehicles, spacecraft, aircraft, robots, LIDAR devices, satellites, etc. In some cases, source device 102 and destination device 116 may be equipped for wireless communication.

[0039] exist Figure 1In the example of , the source device 102 includes a data source 104, a memory 106, a G-PCC encoder 200, and an output interface 108. The destination device 116 includes an input interface 122, a G-PCC decoder 300, a memory 120, and a data consumer 118. According to the present disclosure, the G-PCC encoder 200 of the source device 102 and the G-PCC decoder 300 of the destination device 116 may be configured to apply the techniques related to coordinate transformation in G-PCC of the present disclosure. Therefore, the source device 102 represents an example of an encoding device, and the destination device 116 represents an example of a decoding device. In other examples, the source device 102 and the destination device 116 may include other components or arrangements. For example, the source device 102 may receive data (e.g., point cloud data) from an internal source or an external source. Similarly, the destination device 116 can be connected to an external data consumer without including the data consumer in the same device.

[0040] As will be described in more detail below, the G-PCC encoder 200 and the G-PCC decoder 300 may be configured to decode the point cloud data using the techniques of the present disclosure (including techniques for converting the Cartesian coordinates of a point to spherical coordinates using a fixed-point implementation). In one example of the present disclosure, the G-PCC encoder 200 and the G-PCC decoder 300 may be configured to: derive an azimuth value of a point from the Cartesian coordinates of the point using a fixed-point implementation, wherein the fixed-point implementation includes applying a variable shift value; and decode the point cloud data based on the azimuth value.

[0041] like Figure 1 The system 100 shown is only an example. In general, other digital encoding and / or decoding devices may perform the techniques related to coordinate conversion in G-PCC disclosed herein. The source device 102 and the destination device 116 are only examples of such devices, wherein the source device 102 generates decoded data for sending to the destination device 116. The present disclosure refers to a "decoding" device as a device that performs decoding (e.g., encoding and / or decoding) of data. Therefore, the G-PCC encoder 200 and the G-PCC decoder 300 represent examples of decoding devices, specifically, encoders and decoders, respectively. In some examples, the source device 102 and the destination device 116 can be operated in a substantially symmetrical manner, so that each of the source device 102 and the destination device 116 includes a coding component and a decoding component. Therefore, the system 100 can support one-way or two-way transmission between the source device 102 and the destination device 116, for example, for streaming, playback, broadcasting, telephone, navigation and other applications.

[0042] Generally speaking, the data source 104 represents the source of the data (i.e., the original, unencoded point cloud data), and can provide a series of sequential "frames" of data to the G-PCC encoder 200, which encodes the data of the frames. The data source 104 of the source device 102 may include a point cloud capture device such as any of a variety of cameras or sensors (e.g., a 3D scanner or a light detection and ranging (LIDAR) device, one or more cameras), an archive containing previously captured data, and / or a data feed interface for receiving data from a data content provider. Alternatively or additionally, the point cloud data may be computer-generated from a scanner, camera, sensor, or other data. For example, the data source 104 may generate computer-graphics-based data as source data, or generate a combination of real-time data, archived data, and computer-generated data. In each case, the G-PCC encoder 200 encodes the captured data, pre-captured data, or computer-generated data. The G-PCC encoder 200 may rearrange the frames from the received order (sometimes referred to as "display order") to a decoding order for decoding. G-PCC encoder 200 may generate one or more bitstreams including encoded data. Source device 102 may then output the encoded data onto computer-readable medium 110 via output interface 108 for receipt and / or retrieval by input interface 122 of destination device 116, for example.

[0043] The memory 106 of the source device 102 and the memory 120 of the destination device 116 can represent general purpose memory. In some examples, the memory 106 and the memory 120 can store original data, for example, original data from the data source 104 and original decoded data from the G-PCC decoder 300. Additionally or alternatively, the memory 106 and the memory 120 can store software instructions that can be executed by, for example, the G-PCC encoder 200 and the G-PCC decoder 300, respectively. Although the memory 106 and the memory 120 are shown as being separated from the G-PCC encoder 200 and the G-PCC decoder 300 in this example, it should be understood that the G-PCC encoder 200 and the G-PCC decoder 300 may also include internal memory for functionally similar or equivalent purposes. In addition, the memory 106 and the memory 120 can store encoded data, for example, output from the G-PCC encoder 200 and input to the G-PCC decoder 300. In some examples, portions of memory 106 and memory 120 may be allocated as one or more buffers, eg, for storing raw decoded and / or encoded data.For example, memory 106 and memory 120 may store data representing a point cloud.

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

[0045] In some examples, source device 102 may output the encoded data from output interface 108 to storage device 112. Similarly, destination device 116 may access the 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, such as a hard drive, Blu-ray disc, DVD, CD-ROM, flash memory, volatile or non-volatile memory, or any other suitable digital storage medium for storing encoded data.

[0046] In some examples, source device 102 may output the 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 the encoded data and sending the 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 of the two suitable for accessing the encoded data stored on file server 114. File server 114 and input interface 122 may be configured to operate according to a streaming transmission protocol, a download transmission protocol, or a combination thereof.

[0047] Output interface 108 and input interface 122 may represent wireless transmitters / receivers, modems, wired networking components (e.g., Ethernet cards), wireless communication components that operate 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 may be configured to communicate data (such as encoded data) according to a cellular communication standard (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 may be configured to communicate data (such as encoded data) according to a cellular communication standard such as IEEE 802.11 specifications, IEEE 802.15 specifications (e.g., ZigBee TM ), Bluetooth TM The source device 102 and / or the destination device 116 may include a corresponding system-on-chip (SoC) device. For example, the source device 102 may include a SoC device for performing the functionality attributed to the G-PCC encoder 200 and / or the output interface 108, and the destination device 116 may include a SoC device for performing the functionality attributed to the G-PCC decoder 300 and / or the input interface 122.

[0048] The techniques of this disclosure may be applicable to encoding and decoding to support any of a variety of applications, such as communications between autonomous vehicles, communications between scanners, cameras, sensors, and processing devices such as local or remote servers, geographic mapping, or other applications.

[0049] The input interface 122 of the destination device 116 receives the encoded bitstream from the computer-readable medium 110 (e.g., a communication medium, a storage device 112, a file server 114, etc.). The encoded bitstream may include signaling information defined by the G-PCC encoder 200 and also used by the G-PCC decoder 300, such as syntax elements with values ​​describing characteristics and / or processing of coded units (e.g., slices, pictures, groups of pictures, sequences, 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 for presenting an image based on a point cloud.

[0050] The G-PCC encoder 200 and the G-PCC decoder 300 can each be implemented as any of various suitable encoder and / or decoder circuit systems, 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 the technology is partially implemented in software, the device can store instructions for the software in an appropriate non-transitory computer-readable medium, and use one or more processors to execute the instructions in hardware to perform the technology of the present disclosure. Each of the G-PCC encoder 200 and the G-PCC decoder 300 may be included in one or more encoders or decoders, any of which may be integrated as part of a combined encoder / decoder (CODEC) in a corresponding device. A device including the G-PCC encoder 200 and / or the G-PCC decoder 300 may include one or more integrated circuits, microprocessors, and / or other types of devices.

[0051] The G-PCC encoder 200 and the G-PCC decoder 300 may operate in accordance with a coding standard such as the Video Point Cloud Compression (V-PCC) standard or the Geometric Point Cloud Compression (G-PCC) standard. The present disclosure may generally relate to the coding (e.g., encoding and decoding) of a picture, thereby including the process of encoding or decoding data. The encoded bitstream typically includes a series of values ​​for syntax elements that represent coding decisions (e.g., coding modes).

[0052] The present disclosure may generally relate to "signaling" certain information (such as syntax elements). The term "signaling" may generally refer to the communication of values ​​for syntax elements and / or other data used to decode the encoded data. That is, the G-PCC encoder 200 may signal values ​​for syntax elements in the bitstream. Generally, signaling refers to generating values ​​in the bitstream. As noted above, the source device 102 may transmit the bitstream to the destination device 116 in substantially real time or in non-real time (such as may occur when storing syntax elements to the storage device 112 for later retrieval by the destination device 116).

[0053] ISO / IEC MPEG (JTC 1 / SC 29 / WG 11) and more recently ISO / IEC MPEG 3DG (JTC 1 / SC29 / WG 7) are working on the standardization of point cloud coding techniques with compression capabilities significantly exceeding current approaches. MPEG is working on this exploration in a collaboration called the 3D Graphics Group (3DG) to evaluate compression technology designs proposed by experts in the field.

[0054] Point cloud compression activities are categorized into two different approaches. The first approach is "Video Point Cloud Compression" (V-PCC), which segments 3D objects and projects these segments into multiple 2D planes (which are represented as "patches" in 2D frames), which are further decoded by legacy 2D video codecs 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 3D geometry (i.e., the positions of a set of points in 3D space) and associated attribute values ​​(for each point associated with the 3D geometry). G-PCC addresses the compression of point clouds in both category 1 (static point clouds) and category 3 (dynamically acquired point clouds). The latest draft of the G-PCC standard can be found in ISO / IECFDIS23090-9 Geometry-based point cloud compression text (ISO / IEC JTC 1 / SC29 / WG 7m55637, Telecommunications Conference, October 2020), and a description of the codec can be found in the G-PCC codec description (ISO / IEC JTC 1 / SC29 / WG7MDS20983, Telecommunications Conference, October 2021).

[0055] A point cloud includes a collection of points in 3D space and may have attributes associated with the points. The attributes may be color information such as R, G, B or Y, Cb, Cr, or reflectivity information, or other attributes. Point clouds may be captured by various cameras or sensors (such as LIDAR sensors and 3D scanners), and may also be computer-generated. Point cloud data is used in a variety of applications, including but not limited to architecture (modeling), graphics (3D models for visualization and animation), and the automotive industry (LIDAR sensors to aid navigation).

[0056] The 3D space occupied by the point cloud data can be surrounded by a virtual bounding box. The position of a point in the bounding box can be represented by a certain precision; therefore, the position of one or more points can be quantized based on the precision. At the smallest level, the bounding box is divided into voxels, which are the smallest spatial units represented by a unit cube. A voxel in a bounding box can be associated with zero, one, or more than one point. The bounding box can be divided into multiple cubic / cuboid regions, which can be referred to as tiles. Each tile can be decoded into one or more slices. The division of the bounding box into slices and tiles can be based on the number of points in each partition, or based on other considerations (for example, a particular area can be decoded as a tile). The slice area can be further divided using split decisions similar to those in video codecs.

[0057] 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 implemented code. Figure 2 In the example of , the G-PCC encoder 200 may include a geometry encoding unit 250 and an attribute encoding unit 260. In general, the geometry encoding unit 250 is configured to encode the positions of points in the point cloud frame to produce a geometry bitstream 203. The attribute encoding unit 260 is configured to encode the attributes of the points of the point cloud frame to produce an attribute bitstream 205. As will be explained below, the attribute encoding unit 260 may also use the positions and the encoded geometry (e.g., reconstruction) from the geometry encoding unit 250 to encode the attributes.

[0058] exist Figure 3 In the example of , the G-PCC decoder 300 may include a geometry decoding unit 350 and an attribute decoding unit 360. In general, the geometry encoding unit 350 is configured to decode the geometry bitstream 203 to recover the position of the points in the point cloud frame. The attribute decoding unit 360 is configured to decode the attribute bitstream 205 to recover the attributes of the points of the point cloud frame. As will be explained below, the attribute decoding unit 360 can also use the position of the decoded geometry structure (e.g., reconstruction) from the geometry decoding unit 350 to encode the attribute.

[0059] In both the G-PCC encoder 200 and the G-PCC decoder 300, the point cloud positions are first decoded. The attribute decoding depends on the decoded geometry. Figures 5 to 8 In , coding units with vertical hashing are an option commonly used for category 1 data. Diagonal cross-hatched coding units are an option commonly used for category 3 data. All other modules are common between category 1 and category 3.

[0060] For geometry, there are two different types of decoding techniques: octree and prediction tree decoding. For category 3 data, the compressed geometry is typically represented as an octree from the root to the leaf level of individual voxels. For category 1 data, the compressed geometry is typically represented by a pruned octree (i.e., an octree from the root to the leaf level of blocks larger than a voxel) plus a model that approximates the surface within each leaf of the pruned octree. In this way, both category 1 data and category 3 data share the octree decoding mechanism, while category 1 data can additionally use a surface model to approximate the voxels within each leaf. The surface model used is a triangulation that includes 1-10 triangles per block, forming a triangle soup. Therefore, category 1 geometry codecs are called Trisoup geometry codecs, while category 3 geometry codecs are called Octree geometry codecs.

[0061] At each node of the octree, occupancy is signaled for one or more of its child nodes (up to eight nodes) (when not inferred). Multiple neighborhoods are specified, including (a) nodes that share faces with the current octree node, (b) nodes that share faces, edges, or vertices with the current octree node, etc. Within each neighborhood, the occupancy of the node and / or its child nodes can be used to predict the occupancy of the current node or its child nodes. For points that are sparsely populated in certain nodes of the octree, the codec also supports a direct decoding mode in which the 3D position of the point is encoded directly. A flag can be signaled to indicate that the direct mode is signaled. At the lowest level, the number of points associated with the octree node / leaf node can also be decoded.

[0062] Figure 4 4 is a conceptual diagram illustrating an example octree splitting for geometric coding. At each node of the octree 400, the G-PCC encoder 200 may signal the occupancy of one or more (e.g., up to eight nodes) of the child nodes of the node to the G-PCC decoder 300 (when the G-PCC decoder 300 does not infer the occupancy). A plurality of neighborhoods are specified, including (a) nodes that share a face with the current octree node, (b) nodes that share a face, edge, or vertex with the current octree node, etc. In each neighborhood, the occupancy of the current node or the child nodes of the node can be predicted using the occupancy of the node and / or the child nodes of the node. For points that are sparsely populated in some nodes of the octree, the codec also supports a direct decoding mode in which the 3D position of the point is directly encoded. The G-PCC encoder 200 may signal a flag to indicate that a direct mode has been signaled. At the lowest level, the number of points associated with the octree node / leaf node may also be decoded.

[0063] Once the geometry is decoded, the attributes corresponding to the geometry point are decoded. When there are multiple attribute points corresponding to one reconstructed / decoded geometry point, the attribute value representing the reconstructed point can be derived.

[0064] 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 with an update / lifting step (lifting transform). RAHT and lifting are typically used for class 1 data, while prediction is typically used for class 3 data. However, either method can be used for any data, and just like the geometry codec in G-PCC, the attribute decoding method used to decode point clouds is specified in the bitstream.

[0065] The encoding of the attributes can be performed in levels of detail (LOD), where each level of detail provides a more refined representation of the point cloud attributes. Each level of detail can be specified based on a distance metric to neighboring nodes or based on a sampling distance.

[0066] At the G-PCC encoder 200, the residual obtained as the output of the attribute coding method can be quantized. The residual can be obtained by subtracting the attribute value from a prediction derived based on points in the neighborhood of the current point and based on the attribute value of the previously encoded point. The quantized residual can be decoded using context adaptive arithmetic coding.

[0067] Figure 5 A more detailed example Figure 2 2 is a block diagram of an example of a geometry encoding unit 250. The geometry encoding unit 250 may include a coordinate transformation unit 202, a voxelization unit 206, a prediction tree construction unit 207, an octree analysis unit 210, a surface approximation analysis unit 212, an arithmetic coding unit 214, and a geometry reconstruction unit 216.

[0068] like Figure 5 As shown in the example of , the geometry encoding unit 250 can obtain a set of positions of points in the point cloud. In one example, the geometry encoding unit 250 can obtain a set of positions of points in the point cloud from the data source 104 ( Figure 1 ) obtains a set of positions and a set of attributes of points in the point cloud. The positions may include coordinates of the points in the point cloud. The geometry encoding unit 250 may generate a geometry bitstream 203 including encoded representations of the positions of the points in the point cloud.

[0069] The coordinate transformation unit 202 may apply a transformation to the coordinates of the point to transform the coordinates from the initial domain to the transformed domain. The present disclosure may refer to the transformed coordinates as transformed coordinates. The voxelization unit 206 may voxelize the transformed coordinates. Voxelization of the transformed coordinates may include quantizing and removing some points in the point cloud. In other words, multiple points in the point cloud may be grouped within a single "voxel", which may then be considered as one point in some aspects.

[0070] The prediction tree construction unit 207 may be configured to generate a prediction tree based on the voxelized transformed coordinates. The prediction tree construction unit 207 may be configured to perform any of the prediction tree coding techniques described above in an intra prediction mode or an inter prediction mode. In order to perform prediction tree coding using inter prediction, the prediction tree construction unit 207 may access points of previously encoded frames from the geometry reconstruction unit 216. The dotted line from the geometry reconstruction unit 216 shows the data path when performing inter prediction. The arithmetic coding unit 214 may entropy encode the syntax elements representing the encoded prediction tree.

[0071] In some examples, the prediction tree construction unit 207 may include a coordinate conversion unit 209. The coordinate conversion unit 209 may be configured to encode the point cloud data using the technology of the present disclosure, including converting the Cartesian coordinates of the point into spherical coordinates using a fixed-point implementation. In one example of the present disclosure, the G-PCC encoder 200 may be configured to: derive an azimuth value of the point from the Cartesian coordinates of the point using a fixed-point implementation, wherein the fixed-point implementation includes applying a variable shift value; and encode the point cloud data based on the azimuth value.

[0072] Instead of performing prediction tree-based coding, the geometry coding unit 250 may perform octree-based coding. The octree analysis unit 210 may generate an octree based on the voxelized transformed coordinates. The surface approximation analysis unit 212 may analyze the points to potentially determine a surface representation of a set of the points. The arithmetic coding unit 214 may entropy encode syntax elements representing information of the octree and / or the surface determined by the surface approximation analysis unit 212. The geometry coding unit 250 may output these syntax elements in the geometry bitstream 203. The geometry bitstream 203 may also include other syntax elements, including syntax elements that are not arithmetically coded.

[0073] Octree-based coding may be performed as an intra prediction technique or an inter prediction technique. To perform octree coding using inter prediction, the octree analysis unit 210 and the surface approximation analysis unit 212 may access points of previously encoded frames from the geometry reconstruction unit 216. The dashed line from the geometry reconstruction unit 216 shows the data path when performing inter prediction.

[0074] The geometric reconstruction unit 216 may reconstruct the transformed coordinates of the points in the point cloud based on the octree, the prediction tree, the 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 be different from the number of original points in the point cloud. The present disclosure may refer to the resulting points as reconstructed points.

[0075] Figure 6 A more detailed example Figure 2 2 is a block diagram of an example of an attribute encoding unit 260 of the invention. The attribute encoding unit 250 may include a color transform unit 204, an attribute transfer unit 208, a RAHT unit 218, a LoD generation unit 220, a lifting unit 222, a coefficient quantization unit 224, an arithmetic coding unit 226, and an attribute reconstruction unit 228. The attribute encoding unit 260 may encode attributes of points of a point cloud to generate an attribute bitstream 205 including an encoded representation of the set of attributes. The attributes may include information about the points in the point cloud, such as a color associated with the points in the point cloud.

[0076] The color transform unit 204 may apply a transform of the color information of the attribute to a different domain. For example, the color transform unit 204 may transform the color information from the RGB color space to the YCbCr color space. The attribute transfer unit 208 may transfer the attributes of the original point in the point cloud to the reconstructed point in the point cloud. The attribute transfer unit 208 may use the original position of the point and the position generated from the attribute encoding unit 250 (e.g., from the geometry reconstruction unit 216) for the transfer.

[0077] The RAHT unit 218 may apply RAHT coding to the attributes of the reconstruction point. In some examples, according to RAHT, the attributes of the block of 2x2x2 point positions are obtained and transformed in one direction to obtain four low-frequency nodes (L) and four high-frequency nodes (H). Subsequently, the four low-frequency nodes (L) are transformed in the second direction to obtain two low-frequency nodes (LL) and two high-frequency nodes (LH). The two low-frequency nodes (LL) are transformed in the third direction to obtain one low-frequency node (LLL) and one high-frequency node (LLH). The low-frequency node LLL corresponds to the DC coefficient, and the high-frequency nodes H, LH and LLH correspond to the AC coefficient. The transformation in each direction may be a 1-D transformation with two coefficient weights. The low-frequency coefficients may be obtained as coefficients for the next higher-level 2x2x2 block for the RAHT transform, and the AC coefficients may be encoded without change; such transformations continue until the top root node. The weights to be used for these coefficients are calculated using a tree traversal for encoding from top to bottom; the transformation order is from bottom to top. These coefficients may then be quantized and coded.

[0078] Alternatively or additionally, the LoD generation unit 220 and the lifting unit 222 may apply LoD processing and lifting to the attributes of the reconstructed points, respectively. LoD generation is used to split the attributes into different refinement levels. Each refinement level provides a refinement of the attributes of the point cloud. The first refinement level provides a rough approximation and contains few points; subsequent refinement levels typically contain more points, and so on. The refinement levels can be constructed using a distance-based metric, or one or more other classification criteria (e.g., subsampling from a specific order) can also be used. Therefore, all reconstructed points can be included in the refinement level. Each level of detail is generated by taking the union of all points up to a specific refinement level: for example, LoD1 is obtained based on refinement level RL1, LoD2 is obtained based on RL1 and RL2...LoDN is obtained by the union of RL1, RL2...RLN. In some cases, LoD generation may be followed by a prediction scheme (e.g., a predictive transform) in which the attributes associated with each point in the LoD are predicted based on a weighted average of previous points and the residual is quantized and entropy decoded. The lifting scheme is built on top of the predictive transform mechanism, in which update operators are used to update coefficients and adaptive quantization of coefficients is performed.

[0079] The RAHT unit 218 and the lifting unit 222 may generate coefficients based on these attributes. The coefficient quantization unit 224 may quantize the coefficients generated by the RAHT unit 218 or the lifting unit 222. The arithmetic coding unit 226 may apply arithmetic coding to the syntax elements representing the quantized coefficients. The G-PCC encoder 200 may output these syntax elements in the attribute bitstream 205. The attribute bitstream 205 may also include other syntax elements, including syntax elements that are not arithmetically coded.

[0080] Similar to the geometry coding unit 250, the attribute coding unit 260 may encode the attribute using intra-frame prediction or inter-frame prediction techniques. The above description of the attribute coding unit 260 generally describes intra-frame prediction techniques. In other examples, the RAHT unit 215, the LoD generation unit 220, and / or the lifting unit 222 may also use attributes from previously encoded frames to further encode the attributes of the current frame. In this regard, the attribute reconstruction unit 228 may be configured to reconstruct the encoded attributes and store these encoded attributes for possible future use in inter-frame prediction encoding. The dotted line from the attribute reconstruction unit 228 shows the data path when performing inter-frame prediction.

[0081] Figure 7 A more detailed example Figure 3 The geometry decoding unit 350 may be configured to perform the same operations as those performed by Figure 5 The process is the inverse of the process performed by the geometry encoding unit 250. The geometry decoding unit 350 receives the geometry bitstream 203 and generates the positions of the points of the point cloud frame. The geometry decoding unit 350 may include a geometry arithmetic decoding unit 302, an octree synthesis unit 306, a prediction tree synthesis unit 307, a surface approximation synthesis unit 310, a geometry reconstruction unit 312 and an inverse coordinate transformation unit 320.

[0082] Geometry decoding unit 350 may receive geometry bitstream 203. Geometry arithmetic decoding unit 302 may apply arithmetic decoding (eg, context adaptive binary arithmetic coding (CABAC) or other types of arithmetic decoding) to syntax elements in geometry bitstream 203.

[0083] The octree synthesis unit 306 may synthesize an octree based on syntax elements parsed from the geometry bitstream 203. Starting from the root node of the octree, the occupancy of each of the eight child nodes at each octree level is signaled in the bitstream. When the signaling indicates that a child node at a particular octree level is occupied, the occupancy of the child nodes of that child node is signaled. The signaling of the nodes at each octree level is signaled before proceeding to the subsequent octree level.

[0084] At the final level of the octree, each node corresponds to a voxel position; when a leaf node is occupied, one or more points may be designated as occupied at the voxel position. In some instances, due to quantization, some branches of the octree may terminate earlier than the final level. In such cases, a leaf node is considered an occupied node that has no child nodes. In an instance where surface approximation is used in the geometry bitstream 203, the surface approximation synthesis unit 310 may determine a surface model based on syntax elements parsed from the geometry bitstream 203 and based on the octree.

[0085] Octree-based coding may be performed as an intra-prediction technique or an inter-prediction technique. To perform octree coding using inter-prediction, the octree synthesis unit 306 and the surface approximation synthesis unit 310 may access points of previously decoded frames from the geometry reconstruction unit 312. The dashed line from the geometry reconstruction unit 312 shows the data path when performing inter-prediction.

[0086] The prediction tree synthesis unit may synthesize a prediction tree based on syntax elements parsed from the geometry bitstream 203. The prediction tree synthesis unit 307 may be configured to synthesize the prediction tree using any of the techniques described above, including using intra prediction techniques or both intra prediction techniques. To perform prediction tree coding using inter prediction, the prediction tree synthesis unit 307 may access points of previously decoded frames from the geometry reconstruction unit 312. The dashed line from the geometry reconstruction unit 312 shows the data path when performing inter prediction.

[0087] In some examples, the prediction tree synthesis unit 307 may include a coordinate conversion unit 309. The coordinate conversion unit 309 may be configured to decode the point cloud data using the techniques of the present disclosure, including converting the Cartesian coordinates of the point into spherical coordinates using a fixed-point implementation. In one example of the present disclosure, the G-PCC decoder 300 may be configured to: derive an azimuth value of the point from the Cartesian coordinates of the point using a fixed-point implementation, wherein the fixed-point implementation includes applying a variable shift value; and decode the point cloud data based on the azimuth value.

[0088] In addition, the geometric reconstruction unit 312 can perform reconstruction to determine the coordinates of the points in the point cloud. For each position at a leaf node of the octree, the geometric reconstruction unit 312 can reconstruct the node position by using the binary representation of the leaf node in the octree. At each corresponding leaf node, the number of points at the corresponding leaf node is signaled; this indicates the number of duplicate points at the same voxel position. When geometric quantization is used, the point position is scaled to determine the reconstructed point position value.

[0089] The inverse transform coordinate unit 320 can apply an inverse transform to the reconstructed coordinates to convert the reconstructed coordinates (positions) of the points in the point cloud from the transform domain back to the original domain. The positions of the points in the point cloud can be in the floating point domain, but the point positions in the G-PCC codec are decoded in the integer domain. The inverse transform can be used to convert these positions back to the original domain.

[0090] Figure 8 A more detailed example Figure 3 The attribute decoding unit 360 may be configured to perform the same Figure 6 The attribute decoding unit 360 receives the attribute bitstream 205 and generates the attributes of the points of the point cloud frame. The attribute decoding unit 356 may include an attribute arithmetic decoding unit 304, an inverse quantization unit 308, an inverse RAHT unit 314, a LoD generation unit 316, an inverse lifting unit 318, an inverse transformation color unit 322 and an attribute reconstruction unit 328.

[0091] The attribute arithmetic decoding unit 304 may apply arithmetic decoding to the syntax elements in the attribute bitstream 205. The inverse quantization unit 308 may inverse quantize the property value. The property value may be based on the syntax elements obtained from the attribute bitstream 205 (eg, including the syntax elements decoded by the attribute arithmetic decoding unit 304).

[0092] Depending on how the attribute value is encoded, the inverse RAHT unit 314 may perform RAHT decoding to determine the color value of a point in the point cloud based on the inverse quantized attribute value. RAHT decoding is performed from the top to the bottom of the tree. At each level, the component values ​​are derived using the low-frequency coefficients and high-frequency coefficients derived from the inverse quantization process. At the leaf node, the derived value corresponds to the attribute value of the coefficient. The weight derivation process of the point is similar to the process used at the G-PCC encoder 200. Alternatively, the LoD generation unit 316 and the inverse lifting unit 318 may use a detail level-based technique to determine the color value of a point in the point cloud. The LoD generation unit 316 decodes each LoD, thereby giving a progressively finer representation of the attribute of the point. In the case of a predictive transform, the LoD generation unit 316 derives a prediction of the point from the weighted sum of the points previously reconstructed in the same LoD or previously in the previous LoD. The LoD generation unit 316 may add the prediction to the residual (which is obtained after inverse quantization) to obtain the reconstructed value of the attribute. When a lifting scheme is used, the LoD generation unit 316 may also include an update operator to update the coefficients used to derive the property value. In this case, the LoD generation unit 316 may also apply inverse adaptive quantization.

[0093] In addition, Figure 8In the example of , the inverse color transform unit 322 may apply an inverse color transform to the color value. The inverse color transform may be the inverse of the color transform applied by the color transform unit 204 of the encoder 200. For example, the color transform unit 204 may transform the color information from the RGB color space to the YCbCr color space. Accordingly, the inverse color transform unit 322 may transform the color information from the YCbCr color space to the RGB color space.

[0094] The attribute reconstruction unit 328 may be configured to store attributes from previously decoded frames. Attribute decoding may be performed as an intra prediction technique or an inter prediction technique. To perform attribute decoding using inter prediction, the inverse RAHT unit 314 and the LoD generation unit 316 may access attributes of previously decoded frames from the attribute reconstruction unit 328. The dashed line from the attribute reconstruction unit 328 shows the data path when performing inter prediction.

[0095] Figures 5 to 8 Various units are illustrated to assist in understanding the operations performed by the G-PCC encoder 200 and the G-PCC decoder 300. The units may be implemented as fixed-function circuits, programmable circuits, or a combination thereof. A fixed-function circuit refers to a circuit that provides a specific functionality and is pre-set for the operations that can be performed. A programmable circuit refers to a circuit that can be programmed to perform various tasks and provide flexible functionality on the operations that can be performed. For example, a programmable circuit may execute software or firmware that causes the programmable circuit to operate in a manner defined by the instructions of the software or firmware. A fixed-function circuit may execute software instructions (e.g., to receive parameters or output parameters), but the type of operation performed by the fixed-function circuit is generally immutable. In some examples, one or more of the units in the unit may be different circuit blocks (fixed-function or programmable), and in some examples, one or more of the units in the unit may be an integrated circuit.

[0096] Predictive Geometric Decoding

[0097] Predictive geometry coding (e.g., see G-PCC codec description) was introduced as an alternative to octree geometry coding, where nodes are arranged in a tree structure (which defines the prediction structure), and various prediction strategies are used to predict the coordinates of each node in the tree relative to its predictor. Prediction tree coding may be more efficient for coding sparse content than octree coding. Fig. 9An example of a prediction tree is shown as a directed graph with arrows pointing in the direction of the prediction. The horizontal hash node is the root vertex and has no predictors; the cross-hatched node has two children; the diagonal hash node has 3 children; the non-hashed node has one child, and the vertical hash nodes are leaf nodes, and these nodes have no children. Each node except the root node has only one parent node.

[0098] Fig. 9 5 is a conceptual diagram illustrating an example of a prediction tree. Node 500 is the root vertex and has no predictors. Nodes 502 and 504 have two children. Node 506 has 3 children. Nodes 508, 510, 512, 514, and 516 are leaf nodes, and these have no children. The remaining nodes each have one child. Each node except the root node 500 has only one parent node.

[0099] Four prediction strategies are specified for each node based on its parent node (p0), grandparent node (p1), and great-grandparent node (p2):

[0100] No forecast / Zero forecast(0)

[0101] Incremental prediction (p0)

[0102] Linear prediction (2*p0–p1)

[0103] Parallelogram prediction (p0+p1–p2)

[0104] In the above, the values ​​of p0, p1, and p2 may represent the (x, y, z) position of each of the nodes (e.g., points). The G-PCC encoder 200 may employ any algorithm to generate the prediction tree; the algorithm used is determined based on the application / use case and several strategies may be used. Some strategies are described in the G-PCC codec description.

[0105] For each node, the residual coordinate values ​​(eg, in each of the x, y, z directions) are decoded in the bitstream starting from the root node in a depth-first manner. For example, the G-PCC encoder 200 may decode the residual coordinate values ​​in the bitstream.

[0106] Predictive geometry decoding may be particularly useful for Category 3 (LIDAR acquired) point cloud data (eg, for low latency applications).

[0107] Angular modes for predictive geometry decoding

[0108] Fig. 10A and Fig. 10Bis a conceptual diagram illustrating an example of a rotating LIDAR acquisition model. Angular modes can be used in predictive geometric coding, where characteristics of the LIDAR sensor can be used to more efficiently decode the prediction tree. The coordinates of the position are converted to the (r, φ, i) (radius, azimuth, and laser index (ID)) domain 600, and prediction is performed in this domain 600 (e.g., the residual is decoded in the r, φ, i domain). Due to errors in rounding, the decoding in r, φ, i is not lossless, so a second set of residuals corresponding to Cartesian coordinates may be decoded. A description of the encoding and decoding strategies for angular modes for predictive geometric coding is reproduced below from the G-PCC codec description.

[0109] This technique focuses on point clouds acquired using a rotating LIDAR model. Here, the LIDAR 602 has N lasers (e.g., N=16, 32, 64) rotating around the Z axis according to an azimuth angle φ. Each laser may have a different elevation angle θ(i) i＝1...N and height Assume that laser i hits point M with FIG. 10A to FIG. 10B The coordinate system shown in is defined by the Cartesian integer coordinates (x, y, z).

[0110] This technique models the position of M using three parameters (r, φ, i), calculated as follows:

[0111]

[0112] φ=atan2(y,x)

[0113]

[0114] In the above equation, r is the radius, φ is the azimuth angle, θ is the elevation angle, and i is the laser ID.

[0115] More precisely, this technique uses a quantized version of (r, φ, i) represented by These three integers and i are calculated as follows:

[0116]

[0117]

[0118]

[0119] Among them (q r , o r ) and (q φ , o φ ) are controlled separately and The precision of the quantization parameter. sign(t) is a function that returns 1 if t is positive, otherwise it returns (-1). |t| is the absolute value of t.

[0120] To avoid reconstruction mismatches due to the use of floating point operations, andtan(θ(i)) i＝1...N The values ​​of are precomputed and quantized as follows:

[0121]

[0122]

[0123] in and (q θ , o θ ) are controlled separately and The quantization parameter of the accuracy.

[0124] The reconstructed Cartesian coordinates are obtained as follows:

[0125]

[0126]

[0127]

[0128] where app_cos(.) and app_sin(.) are approximations of cos(.) and sin(.). The calculations may be performed using fixed-point representation, lookup tables, and / or linear interpolation.

[0129] Note that due to various reasons such as quantization, approximation, model inaccuracy, or model parameter inaccuracy, Might be different from (x,y,z).

[0130] Let x ,re y ,re z ) is the reconstruction residual defined as follows:

[0131]

[0132]

[0133]

[0134] Using this technique, the G-PCC encoder 200 can proceed as follows:

[0135] 1) Model parameters and And the quantization parameter q r , q θ and q φ to encode.

[0136] 2) Applying geometric prediction scheme to represent

[0137] New predictors that take advantage of the characteristics of LIDAR can be introduced. For example, the rotation speed of the LIDAR scanner around the z-axis is usually constant. Therefore, the G-PCC encoder 200 can predict the current

[0138]

[0139] in,

[0140] (δ ψ (k)) k＝1...K is a set of possible speeds that the G-PCC encoder 200 can use. The index k can be explicitly written to the bitstream or can be inferred from the context based on a deterministic strategy applied by both the G-PCC encoder 200 and the G-PCC decoder 300, and n(j) is the number of points skipped, which can be explicitly written to the bitstream or can be inferred from the context based on a deterministic strategy applied by both the G-PCC encoder 200 and the G-PCC decoder 300. n(j) is also referred to herein as a "phi multiplication factor". Note that in some examples, the phi multiplication factor is used only with the incremental predictor.

[0141] 3) Use each node pair to reconstruct the residual (re x ,re y ,re z ) for encoding.

[0142] The G-PCC decoder 300 may proceed as follows:

[0143] 1) Model parameters and And the quantization parameter q r , q θ and q φ to decode.

[0144] 2) According to the geometric prediction scheme, the Decode the parameters.

[0145] 3) Calculate the reconstruction coordinates as described above

[0146] 4) Residual (re x ,rey ,re z ) to decode.

[0147] As discussed in the next section, the reconstruction residual (re x ,re y ,re z ) to support lossy compression.

[0148] 5) Calculate the original coordinates (x, y, z) as follows:

[0149]

[0150]

[0151]

[0152] Lossy compression can be achieved by applying quantization to the reconstructed residual (re x ,re y ,re z ) or by discarding points.

[0153] The quantized reconstruction residual can be calculated as follows:

[0154]

[0155]

[0156]

[0157] Among them (q x , o x ), (q y , o y ) and (q z , o z ) are respectively controlled and For example, the G-PCC encoder 200 or the G-PCC decoder 300 may calculate a quantized residual.

[0158] The G-PCC encoder 200 and the G-PCC decoder 300 may use trellis quantization to further improve RD (rate-distortion) performance results.

[0159] The quantization parameter can be varied at sequence / frame / slice / block level to achieve region-adaptive quality and / or for rate control purposes.

[0160] Several other improvements to predictive geometry have been proposed. A summary of improvements related to the present disclosure is presented herein.

[0161] Inter prediction for predictive geometric coding

[0162] Predictive geometric coding uses a prediction tree structure to predict the position of a point. When angular coding is enabled, the x, V, z coordinates are transformed into radius, azimuth, and laser ID, and residuals can be signaled in these three coordinates and x, V, z dimensions. Intra-frame prediction for radius, azimuth, and laser ID can be one of four modes, and the predictor is a node classified as a parent node, a grandfather node, and a great-grandfather node in the prediction tree relative to the current node. Predictive geometric coding as designed in G-PCC version 1 is an intra-frame coding tool because it only uses points in the same frame for prediction. Additionally, using points from previously decoded frames can provide better predictions and therefore provide better compression performance.

[0163] For inter prediction, it was initially proposed to predict the radius of a point from a reference frame. For each point in the prediction tree, the G-PCC decoder 300 can determine whether the point is inter predicted or intra predicted. For example, the G-PCC encoder 200 can indicate such inter prediction or intra prediction through a flag that the G-PCC encoder 200 can signal in the bitstream. When intra prediction is performed, the intra prediction mode of predictive geometric decoding is used. When inter prediction is used, the azimuth and laser ID are still predicted using intra prediction, while the radius is predicted from the point in the reference frame that has the same laser ID as the current point and the azimuth closest to the current azimuth.

[0164] In addition to radius prediction, a further variation of the technique implements inter-frame prediction of azimuth and laser ID. When inter-coding is applied, the radius, azimuth, and laser ID of the current point are predicted based on points located near the azimuth position of previously decoded points in the reference frame. In addition, separate context sets are used for inter-frame prediction and intra-frame prediction.

[0165] Fig.11 is a conceptual diagram illustrating an example of inter-frame prediction of a current point based on a point in a reference frame. Extending inter-frame prediction to azimuth, radius, and laser ID includes the following steps, which may be performed, for example, by the G-PCC decoder 300:

[0166] 1) For a given point (eg, the current point curPoint 700 in the current frame 704), select a previously decoded point (prevDecP0 702).

[0167] 2) Select a location in the reference frame 708 that has the same scaled azimuth and laser ID as prevDecP0 702 (eg, refFrameP0 706 ).

[0168] 3) In the reference frame 708, find the first point (interPredPt 710) whose azimuth is greater than the azimuth of refFrameP0 706. interPredPt 710 may also be referred to as the "next" inter-frame predictor.

[0169] Fig.12 is a flow chart illustrating the operation of a G-PCC decoder. Fig.12 The decoding flow associated with the "inter_flag" signaled for each point is illustrated. The G-PCC decoder 300 may determine whether the inter-frame flag is true (e.g., equal to 1) (800). If the inter-frame flag is true (the "yes" path from box 800), the G-PCC decoder 300 may select a previously decoded point in decoding order using the radius, azimuth, and laser ID (802). The G-PCC decoder 300 may derive the quantized phi of the selected previously decoded point (e.g., prevDecP0702), i.e., Q(phi) (e.g., a quantized value of the azimuth) (804). The G-PCC decoder 300 may check the reference frame (e.g., Fig.11 The G-PCC decoder 300 may then use interPredPt 710 as the inter-frame prediction factor for the current point curPoint 700 (808). The G-PCC decoder 300 may then multiply the increment phi by a factor (e.g., n(j)×δ as described above) to obtain a point in the reference frame 708) where the quantized phi value of such point is greater than Q(phi), which may result in interPredPt 710 (806). The G-PCC decoder 300 may then use interPredPt 710 as the inter-frame prediction factor for the current point curPoint 700 (808). φ (k)) is added to the main residual (810).

[0170] If the inter flag is false (e.g., equal to 0) ("No" path from block 800), the G-PCC decoder 300 may select an intra prediction candidate (812) and apply intra prediction. The G-PCC decoder 300 may then add the incremental phi multiplication factor to produce the primary residual (810).

[0171] Additional predictor candidates

[0172] Fig.13 is a conceptual diagram illustrating an example of an additional inter-frame predictor point obtained from a first point having an azimuth angle greater than the inter-frame predictor point. In the above-mentioned inter-frame prediction technique for predictive geometry, when inter-frame decoding is applied by, for example, the G-PCC decoder 300, the radius, azimuth angle, and laser ID of the current point are predicted based on points located near the collocated azimuth position in the reference frame using the following steps:

[0173] 1) For a given point (e.g., current point, current point 900), select a previously decoded point (e.g., previously decoded point

[0174] 902),

[0175] 2) selecting a location in reference frame 908 (e.g., reference point 906) that has the same scaled azimuth and laser ID as a previously decoded point (e.g., previously decoded point 902),

[0176] 3) Select a position in the reference frame 908 (inter-frame prediction point 910) from the first point having an azimuth angle greater than a position in the reference frame 908 having an azimuth angle and laser ID with the same scale as a previously decoded point (e.g., previously decoded point 902) to be used as an inter-frame prediction point.

[0177] This technique adds the ability to find Fig.13 The additional inter prediction factor point 912 is obtained by first point of greater azimuth than the inter prediction factor point shown (e.g., inter prediction point 910). Additional signaling is used to indicate which prediction factor is selected if the G-PCC encoder 200 has applied inter coding. For example, the G-PCC encoder 200 may signal to the G-PCC decoder 300 which prediction factor is selected. The additional inter prediction point may also be referred to as a "NextNext" inter prediction factor.

[0178] Improved inter-frame prediction flag decoding

[0179] In some examples, an improved context selection algorithm may be applied to code the inter prediction flag.The inter prediction flag values ​​of five previously coded points may be used to select the context of the inter prediction flag in predictive geometry coding.

[0180] Global Motion Compensation

[0181] Fig.14 is a flow chart illustrating an example motion compensation technique. When global motion (GM) parameters are available, inter-frame prediction can be applied using a reference frame (which uses the GM parameters for motion compensation). The GM parameters may include rotation parameters and / or translation parameters. Typically, global motion compensation is applied in the Cartesian domain; in some cases, global motion compensation may also be performed in the spherical domain. Depending on which domain the reference frame is stored in and in which domain the reference frame is compensated, one or more of a Cartesian to spherical domain conversion or a spherical to Cartesian domain conversion may be applied. For example, when applying motion compensation, the G-PCC encoder 200 and the G-PCC decoder 300 may apply a coordinate domain conversion.

[0182] For example, Fig.14As shown, when the reference frame is stored in the spherical domain and motion compensation is performed in the Cartesian domain, the G-PCC encoder 200 and the G-PCC decoder 300 may first apply a spherical->Cartesian translation 1000. Then, for the reference frame in the Cartesian domain, the G-PCC encoder 200 and the G-PCC decoder 300 may apply motion compensation 1002 to obtain a compensated reference frame in the Cartesian domain. The G-PCC encoder 200 and the G-PCC decoder 300 may then apply a Cartesian->spherical translation 1004 before outputting and / or storing the compensated reference frame in the spherical domain. In such a case, the compensated reference frame can be used for inter-frame prediction.

[0183] Given a position (x, y, z) in a Cartesian coordinate system, the G-PCC encoder 200 and the G-PCC decoder 300 may calculate the corresponding radius and azimuth using a floating point implementation, such as the CartesianToSpherical conversion function shown below:

[0184] int64_t r0=int64_t(std::round(hypot(xyz[0],xyz[1])));

[0185] auto phi0=std::round((atan2(xyz[1],xyz[0]) / (2.0*M_PI))*scalePhi);

[0186] Where int64_t is a signed integer type with 64 bits, where r0 is the derived radius value in the spherical domain, xyz[0] is the x-coordinate of the point in the Cartesian domain, xyz[1] is the y-coordinate of the point in the Cartesian domain, M_PI is the value of pi (π), phi0 is the derived azimuth value in the spherical domain, scalePhi is a scaling factor that can be modified for different rate points in a lossy configuration, and round is a rounding function. std::function() is used to employ different functions from the standard library. For example, round() is used to round up the value in the argument, hypot() returns the hypotenuse (i.e., the square root of the sum of the squares of the passed arguments), auto is used to infer the type of phi0 based on the type of the defined value, the atan2 function returns the inverse tangent, and isqrt is the integer square root of the passed argument. In one example, when decoding the geometry losslessly, a maximum value of 24 bits is used for the azimuth. An example fixed-point implementation of radius and azimuth is the convertXyZToRpl function shown below. In the example fixed-point implementation below, xLaser and yLaser are derived scaled values ​​of xyz[0] and xyz[1], respectively. The values ​​of xLaser and yLaser represent the x- and y-coordinates of a point in the compensated point cloud in the Cartesian domain.

[0187] radius:

[0188]

[0189] Azimuth:

[0190]

[0191] Here, dst is a variable with three values ​​dst[0], dst[1], and dst[2], storing the radius, azimuth, and laser ID, respectively.

[0192] Coordinate transformation

[0193] The processing of operations with real numbers is often challenging because floating point operations often vary with both hardware and software. For ease of deployment and to eliminate any ambiguity with floating point operations, fixed point operations are often preferred.

[0194] Floating point arithmetic and fixed point arithmetic are two approaches to numerical computation in computer systems, including compression systems such as G-PCC encoder 200 and G-PCC decoder 300. In some examples, floating point numbers represent a subset of real numbers using integers with fixed precision (referred to as significant digits) that are scaled by integer exponents of a fixed base, thereby providing a wide range of values ​​with variable precision. Fixed point numbers, on the other hand, use a fixed number of bits to represent numbers and have a limited range and precision.

[0195] Floating-point operations typically use dedicated hardware or algorithms and handle overflow, underflow, and rounding errors. Fixed-point operations, on the other hand, can be performed using standard integer arithmetic, but may require additional considerations such as scaling and loss of precision. In general, floating-point operations are computationally more complex but benefit from dedicated hardware units, while fixed-point operations are simpler and require fewer resources.

[0196] Motion compensation for inter prediction in predictive geometric coding (e.g., G-PCC coding) may include a step of converting the coordinates of a point from Cartesian coordinates (e.g., (x, y, z)) to spherical coordinates (e.g., (r, φ, i)), as described above. In one example, the G-PCC encoder 200 and the G-PCC decoder 300 may be configured to perform a Cartesian to Spherical conversion using a software tool (which uses floating point operations). However, some examples of G-PCC use fixed-point / integer implementations to convert from Cartesian coordinates to spherical coordinates (convertXyzToRpl) during attribute coding. However, the fixed-point convertXyzToRpl technique is not directly applicable to all situations because the convertXyzToRpl technique uses a fixed scaling factor and offset. When azimuth values ​​are decoded at different bit depths, the use of a fixed scaling factor results in inaccurate values ​​of the azimuth, which in turn affects the performance of inter prediction.

[0197] According to the technology of the present disclosure, the G-PCC encoder 200 and the G-PCC decoder 300 may be configured to derive an azimuth value from Cartesian coordinates using a fixed-point implementation, which includes applying a variable scaling factor (or variable shift). In some examples, the fixed-point implementation may also include applying an offset value associated with the scaling factor (shift) before applying scaling (shift). Generally speaking, the G-PCC encoder 200 or the G-PCC decoder 300 may use a fixed-point implementation to derive an azimuth value of a point from the Cartesian coordinates of the point, which includes applying a variable scaling factor, and optionally includes applying an offset value before applying scaling. In one example, the G-PCC encoder 200 and the G-PCC decoder 300 may derive the variable scaling factor (shift) to be applied based on the number of bits used to decode the azimuth value.

[0198] In one example, the fixed-point implementation for deriving the radius from the Cartesian coordinates of the point is the same as the fixed-point implementation in the convertXyzToRpl technique described above. However, the fixed-point implementation used by the G-PCC encoder 200 and the G-PCC decoder 300 in the azimuth derivation is updated as follows (e.g., a fixed-point implementation with a variable scaling factor / shift).

[0199] Azimuth:

[0200]

[0201] The G-PCC encoder 200 and the G-PCC decoder 300 may first use the following function to determine a temporary (tmp) value of the azimuth angle in radians scaled to a particular bit depth: int64_t tmp=iatan2(yLaser, xLaser). The G-PCC encoder 200 and the G-PCC decoder 300 may then use the following function to determine the inverse of pi (invPi): invPi=std::round(((1<<24)+0.) / M_PI). In some examples, the PCC encoder 200 and the G-PCC decoder 300 may be configured to store and use a hard-coded value of pi rather than determining the value of the inverse of pi.

[0202] The G-PCC encoder 200 and the G-PCC decoder 300 may also determine the shift value (sh) using the following function: int sh = 44 - (azimLog2 - 1). The shift value sh is based on the variable azimLog2, which indicates the number of bits used to decode the azimuth value. Therefore, the shift value indicates a scaling factor. For example, the scaling factor is 1 / (2 sh). The G-PCC encoder 200 and the G-PCC decoder 300 may also determine an offset value (off) based on the determined shift value using the following function: int off=1<<(sh-1).

[0203] The G-PCC encoder 200 and the G-PCC decoder 300 may determine the azimuth value phi0 based on the temporary azimuth value (tmp) in radians, the inverse of pi (invPi), the offset (off), the shift value (sh), and the number of bits used to decode the azimuth value. For example, the G-PCC encoder 200 and the G-PCC decoder 300 use the following function to determine the azimuth value phi0: auto phi0 = (((tmp+3294199)*invPi+off)>>sh)-(1<<(azimLog2-1)). 3294199 is the value of pi with 20-bit precision.

[0204] In some examples, the number of bits used to decode the azimuth value can be derived from another syntax element signaled in the bitstream by the G-PCC encoder 200. For example, for different rate points, different numbers of bits can be used to decode the azimuth value. The number of bits can be 24, in which case the azimuth value can take the value [-8388608, 8388607]. This example can be used in lossless conditions. In lossy conditions, fewer bits (e.g., 20 bits) can be used to decode the azimuth.

[0205] A more compact way of expressing the derivation of the azimuth angle is given below:

[0206] int64_t tmp=iatan2(yLaser,xLaser);

[0207] int sh = 44 - (azimLog2 - 1);

[0208] int off = 1 << (sh-1);

[0209] auto phi0=(((tmp+3294199)*5340354+off)>>sh)-(1<<(azimLog2-1)); / / invPi=5340354

[0210] By using a variable shift value (and therefore a scaling factor) based on the number of bits used to decode the azimuth, the disclosed technique enables more accurate conversion of Cartesian coordinates to azimuth values ​​in a fixed-point implementation. In contrast to the variable value of the disclosed technique, the use of a fixed shift value may result in inaccurate derivation of the azimuth value during conversion, and thus may result in inaccuracies in the decoding process and / or reduced decoding efficiency.

[0211] Fig.15 is a flow chart illustrating an example encoding technique of the present disclosure. Fig.15 The technique may be performed by one or more units of the G-PCC encoder 200 (including the prediction tree construction unit 207 of the geometry coding unit 250).

[0212] In one example of the present disclosure, the G-PCC encoder 200 may derive an azimuth value of a point from the Cartesian coordinates of the point using a fixed-point implementation, wherein the fixed-point implementation includes applying a variable shift value (1500). The G-PCC encoder 200 may then encode the point cloud data based on the azimuth value (1502). In one example, to further encode the point cloud data based on the azimuth value, the G-PCC encoder 200 may determine a radius value of the point based on the Cartesian coordinates of the point; determine a laser ID of the point; and perform predictive geometric encoding of the point using the radius value, the azimuth value, and the laser ID.

[0213] In one example, to derive the azimuth value using the fixed-point implementation, the G-PCC encoder 200 may derive the variable shift value based on the number of bits used to code the azimuth value. For example, the G-PCC encoder 200 may derive the variable shift value according to the following function: sh=44-(azimLog2-1), where sh is the variable shift value and azimLog2 is the number of bits used to code the azimuth value. In some examples, the G-PCC encoder 200 may encode a syntax element indicating the value of azimLog2.

[0214] In order to use a fixed-point implementation, the G-PCC encoder 200 may apply an offset associated with the variable shift value before applying the variable shift value. For example, the G-PCC encoder 200 may derive the offset associated with the variable shift value according to the following function: off=1<<(sh–1), where off is the offset and sh is the variable shift value.

[0215] In another example, in order to derive the azimuth value of the point based on the Cartesian coordinates of the point using the fixed-point implementation, the G-PCC encoder 200 may derive a temporary azimuth value based on the x and y Cartesian coordinates of the point; derive the variable shift value based on the number of bits used to decode the azimuth value; derive an offset based on the variable shift value; and derive the azimuth value based on the temporary azimuth value, the variable shift value, the offset, and the number of bits used to decode the azimuth value.

[0216] Fig.16 is a flow chart illustrating an example decoding technique of the present disclosure. Fig.16The technique may be performed by one or more units of the G-PCC decoder 300 (including the prediction tree synthesis unit 307 of the geometry decoding unit 350).

[0217] In one example of the present disclosure, the G-PCC decoder 300 may use a fixed-point implementation to derive an azimuth value of a point based on the Cartesian coordinates of the point, wherein the fixed-point implementation includes applying a variable shift value (1600). The G-PCC decoder 300 may then decode the point cloud data based on the azimuth value (1602). In one example, to further decode the point cloud data based on the azimuth value, the G-PCC decoder 300 may determine a radius value of the point based on the Cartesian coordinates of the point; determine a laser ID of the point; and perform predictive geometric decoding on the point using the radius value, the azimuth value, and the laser ID.

[0218] In one example, to derive the azimuth value using the fixed-point implementation, the G-PCC decoder 300 may derive the variable shift value based on the number of bits used to code the azimuth value. For example, the G-PCC decoder 300 may derive the variable shift value according to the following function: sh=44-(azimLog2-1), where sh is the variable shift value and azimLog2 is the number of bits used to code the azimuth value. In some examples, the G-PCC decoder 300 may decode a syntax element indicating the value of azimLog2.

[0219] In order to use a fixed-point implementation, the G-PCC decoder 300 may apply an offset associated with the variable shift value before applying the variable shift value. For example, the G-PCC decoder 300 may derive the offset associated with the variable shift value according to the following function: off=1<<(sh–1), where off is the offset and sh is the variable shift value.

[0220] In another example, in order to derive the azimuth value of the point according to the Cartesian coordinates of the point using the fixed-point implementation, the G-PCC decoder 300 may derive a temporary azimuth value based on the x and y Cartesian coordinates of the point; derive the variable shift value based on the number of bits used to decode the azimuth value; derive an offset based on the variable shift value; and derive the azimuth value based on the temporary azimuth value, the variable shift value, the offset, and the number of bits used to decode the azimuth value.

[0221] Fig.17 is a conceptual diagram illustrating an example ranging system 1700 that can be used with one or more of the techniques for coordinate conversion in G-PCC disclosed herein. Fig.17In the example of , ranging system 1700 includes illuminator 1702 and sensor 1704. Illuminator 1702 may emit light 1706. In some examples, illuminator 1702 may emit light 1706 as one or more laser beams. Light 1706 may be at one or more wavelengths, such as infrared wavelengths or visible light wavelengths. In other examples, light 1706 is not a coherent laser. When light 1706 encounters an object (such as object 1708), light 1706 produces return light 1710. Return light 1710 may include backscattered light and / or reflected light. Return light 1710 may pass through lens 1711, which guides return light 1710 to produce an image 1712 of object 1708 on sensor 1704. Sensor 1704 generates signal 1714 based on image 1712. Image 1712 may include points (e.g., as represented by Fig.17 A collection of points (represented by the small dots in image 1712).

[0222] In some examples, illuminator 1702 and sensor 1704 may be mounted on a rotating structure so that illuminator 1702 and sensor 1704 capture a 360-degree view of the environment (e.g., a rotating LIDAR sensor). In other examples, ranging system 1700 may include one or more optical components (e.g., mirrors, collimators, diffraction gratings, etc.) that enable illuminator 1702 and sensor 1704 to detect objects within a certain range (e.g., up to 360 degrees). Although Fig.17 The example shows only a single illuminator 1702 and sensor 1704, but the ranging system 1700 may include multiple sets of illuminators and sensors.

[0223] In some examples, the illuminator 1702 generates a structured light pattern. In such examples, the ranging system 1700 may include a plurality of sensors 1704 on which respective images of the structured light pattern are formed. The ranging system 1700 may use differences between the images of the structured light pattern to determine the distance to an object 1708 from which the structured light pattern is backscattered. When the object 1708 is relatively close to the sensor 1704 (e.g., 0.2 meters to 2 meters), the ranging system based on structured light may have a high level of accuracy (e.g., accuracy in the sub-millimeter range). This high level of accuracy may be useful in facial recognition applications such as unlocking a mobile device (e.g., a mobile phone, a tablet computer, etc.) and for security applications.

[0224] In some examples, ranging system 1700 is a time-of-flight (ToF) based system. In some examples where ranging system 1700 is a ToF based system, illuminator 1702 generates pulses of light. In other words, illuminator 1702 can modulate the amplitude of emitted light 1706. In such examples, sensor 1704 detects return light 1710 from the pulses of light 1706 generated by illuminator 1702. Ranging system 1700 can then determine the distance to object 1708 from which light 1706 is backscattered based on the delay between when light 1706 is emitted and when it is detected and the known speed of light in air. In some examples, illuminator 1702 can modulate the phase of emitted light 1706 instead of (or in addition to) modulating the amplitude of emitted light 1706. In such an example, sensor 1704 may detect the phase of return light 1710 from object 1708 and determine the distance to a point on object 1708 using the speed of light and based on the time difference between when illuminator 1702 generates light 1706 at a particular phase and when sensor 1704 detects return light 1710 at that particular phase.

[0225] In other examples, the point cloud may be generated without using the illuminator 1702. For example, in some examples, the sensor 1704 of the ranging system 1700 may include two or more optical cameras. In such examples, the ranging system 1700 may use the optical cameras to capture a stereoscopic image of an environment including the object 1708. The ranging system 1700 may include a point cloud generator 1716 that may calculate differences between locations in the stereoscopic images. The ranging system 1700 may then use these differences to determine the distance to the locations shown in the stereoscopic images. Based on these distances, the point cloud generator 1716 may generate a point cloud.

[0226] Sensor 1704 may also detect other properties of object 1708, such as color and reflectivity information. Fig.17 In the example of , the point cloud generator 1716 can generate a point cloud based on the signal 1714 generated by the sensor 1704. The ranging system 1700 and / or the point cloud generator 1716 can form a data source 104 ( Figure 1 ). Therefore, the point cloud generated by the ranging system 1700 can be encoded and / or decoded according to any of the techniques in the present disclosure. Inter-frame prediction and residual prediction as described in the present disclosure can reduce the size of the encoded data.

[0227] Fig.18 is a conceptual diagram illustrating an example vehicle-based scenario in which one or more of the techniques for coordinate conversion in G-PCC of the present disclosure may be used. Fig.18 In the example of FIG. 1 , vehicle 1800 includes ranging system 1802. Ranging system 1802 can be used to Fig.17Although Fig.18 Although not shown in the example of FIG. 1 , vehicle 1800 may also include a data source (such as data source 104 ( Figure 1 )) and a G-PCC encoder (such as G-PCC encoder 200 ( Figure 1 )).exist Fig.18 In the example of FIG. 1 , a range finding system 1802 emits laser beams 1804 that are reflected from pedestrians 1806 or other objects on the road. A data source of vehicle 1800 may generate a point cloud based on the signals generated by range finding system 1802. A G-PCC encoder of vehicle 1800 may encode the point cloud to generate a bitstream 1808, such as a geometry bitstream ( Figure 2 ) and attribute bitstream ( Figure 2 ). Inter-frame prediction and residual prediction as described in the present disclosure can reduce the size of the geometry bitstream. The bitstream 1808 may include significantly fewer bits than the unencoded point cloud obtained by the G-PCC encoder.

[0228] The output interface of the vehicle 1800 (eg, the output interface 108 ( Figure 1 )) can send a bitstream 1808 to one or more other devices. The bitstream 1808 may include significantly fewer bits than the unencoded point cloud obtained by the G-PCC encoder. Therefore, the vehicle 1800 can send the bitstream 1808 to other devices faster than the unencoded point cloud data. Additionally, the bitstream 1808 may require less data storage capacity on the device.

[0229] exist Fig.18 In the example of FIG. 1 , vehicle 1800 may send a bitstream 1808 to another vehicle 1810. Vehicle 1810 may include a G-PCC decoder, such as G-PCC decoder 300 ( Figure 1 ). The G-PCC decoder of vehicle 1810 may decode bitstream 1808 to reconstruct the point cloud. Vehicle 1810 may use the reconstructed point cloud for various purposes. For example, vehicle 1810 may determine that pedestrian 1806 is on the road ahead of vehicle 1800 based on the reconstructed point cloud, and therefore begin to slow down, for example, even before the driver of vehicle 1810 realizes that pedestrian 1806 is on the road. Thus, in some examples, vehicle 1810 may perform autonomous navigation operations based on the reconstructed point cloud.

[0230] Additionally or alternatively, the vehicle 1800 may send a bitstream 1808 to a server system 1812. The server system 1812 may use the bitstream 1808 for various purposes. For example, the server system 1812 may store the bitstream 1808 for subsequent reconstruction of the point cloud. In this example, the server system 1812 may use the point cloud along with other data (e.g., vehicle telemetry data generated by the vehicle 1800) to train an autonomous driving system. In other examples, the server system 1812 may store the bitstream 1808 for subsequent reconstruction for an accident forensic investigation.

[0231] Fig.19 is a conceptual diagram illustrating an example extended reality system in which one or more of the techniques for coordinate conversion in G-PCC of the present disclosure may be used. Extended reality (XR) is a term used to cover a range of technologies including augmented reality (AR), mixed reality (MR), and virtual reality (VR). Fig.19 In the example of FIG. 1 , user 1900 is located in a first location 1902. User 1900 wears an XR headset 1904. As an alternative to the XR headset 1904, user 1900 may use a mobile device (e.g., a mobile phone, a tablet computer, etc.). XR headset 1904 includes a depth detection sensor, such as a range finding system, that detects the position of a point on an object 1906 at location 1902. A data source for XR headset 1904 may use a signal generated by the depth detection sensor to generate a point cloud representation of object 1906 at location 1902. XR headset 1904 may include a G-PCC encoder (e.g., Figure 1 The G-PCC encoder 200 is configured to encode the point cloud to generate a bitstream 1908. Inter-frame prediction and residual prediction as described in the present disclosure can reduce the size of the bitstream 1908.

[0232] The XR headset 1904 may send a bitstream 1908 to an XR headset 1910 worn by a user 1912 at a second location 1914 (e.g., via a network, such as the Internet). The XR headset 1910 may decode the bitstream 1908 to reconstruct a point cloud. The XR headset 1910 may use the point cloud to generate an XR visualization (e.g., an AR visualization, an MR visualization, a VR visualization) representing the object 1906 at the location 1902. Thus, in some examples, such as when the XR headset 1910 generates a VR visualization, the user 1912 may have a 3D immersive experience of the location 1902. In some examples, the XR headset 1910 may determine the location of a virtual object based on the reconstructed point cloud. For example, the XR headset 1910 may determine that the environment (e.g., location 1902) includes a flat surface based on the reconstructed point cloud, and then determine that a virtual object (e.g., a cartoon character) is to be positioned on the flat surface. The XR headset 1910 may generate an XR visualization in which the virtual object is located at the determined location. For example, the XR headset 1910 may show a cartoon character sitting on the flat surface.

[0233] Fig. 20 is a conceptual diagram illustrating an example mobile device system in which one or more of the techniques for coordinate conversion in G-PCC of the present disclosure may be used. Fig. 20 In an example of FIG. 1 , a mobile device 2000 (e.g., a wireless communication device) such as a mobile phone or tablet computer includes a ranging system (e.g., a LIDAR system) that detects the location of points on an object 2002 in the environment of the mobile device 2000. A data source of the mobile device 2000 may use a signal generated by a depth detection sensor to generate a point cloud representation of the object 2002. The mobile device 2000 may include a G-PCC encoder (e.g., Figure 1 The G-PCC encoder 200 is configured to encode the point cloud to generate a bitstream 2004. Fig. 20In an example, the mobile device 2000 may send a bitstream to a remote device 2006 (such as a server system or other mobile device). Inter-frame prediction and residual prediction as described in the present disclosure may reduce the size of the bitstream 2004. The remote device 2006 may decode the bitstream 2004 to reconstruct the point cloud. The remote device 2006 may use the point cloud for various purposes. For example, the remote device 2006 may use the point cloud to generate an environmental map of the mobile device 2000. For example, the remote device 2006 may generate an internal map of a building based on the reconstructed point cloud. In another example, the remote device 2006 may generate an image (e.g., computer graphics) based on the point cloud. For example, the remote device 2006 may use the points in the point cloud as vertices of a polygon, and use the color attributes of the points as the basis for coloring the polygon. In some examples, the remote device 2006 may use the reconstructed point cloud for facial recognition or other security applications.

[0234] The examples in various aspects of this disclosure may be used alone or in any combination.

[0235] This disclosure includes the following non-limiting terms.

[0236] Clause 1A. A method of processing point cloud data, the method comprising: deriving an azimuth angle value from Cartesian coordinates in fixed-point arithmetic, the fixed-point arithmetic comprising applying a variable scaling factor; and decoding the point cloud data based on the azimuth angle.

[0237] Clause 2A. The method of Clause 1A, further comprising applying an offset value associated with the variable scaling factor prior to applying the variable scaling factor.

[0238] Clause 3A. The method of Clause 2A, wherein the offset associated with the variable scaling factor is derived as 1<<(sh−1), where sh is a shift value.

[0239] Clause 4A. The method of any of clauses 1A to 3A, wherein the variable scaling factor is based on a number of bits used to encode the azimuth angle value.

[0240] Clause 5A. The method of clause 4A, wherein the number of bits used to decode the azimuth angle value is a value of azimLog2.

[0241] Clause 6A. The method of clause 5A, wherein the variable scaling factor is 1 / (2 sh ), where sh is the shift value.

[0242] Clause 7A. The method of any of clauses 1A to 4A, wherein the number of bits used to code the azimuth angle value is derived from a syntax element signaled in a bitstream.

[0243] Clause 8A. The method of clause 7A, wherein decoding the point cloud data based on the azimuth angle is lossless, and wherein the number of bits used to decode the azimuth angle value is 24.

[0244] Clause 9A. The method of clause 7A, wherein decoding the point cloud data based on the azimuth angle is lossy, and wherein the number of bits used to decode the azimuth angle value is less than 24.

[0245] Clause 10A. The method of any of Clauses 1A to 9A, further comprising generating the point cloud.

[0246] Clause 11A. An apparatus for processing a point cloud, the apparatus comprising one or more means for performing the method of any of Clauses 1A to 10A.

[0247] Clause 12A. The apparatus of Clause 11A, wherein the one or more components include one or more processors implemented in circuitry.

[0248] Clause 13A. The apparatus of any of Clauses 11A or 12A, further comprising a memory for storing the data representing the point cloud.

[0249] Clause 14A. The apparatus of any of clauses 11A to 13A, wherein the apparatus comprises a decoder.

[0250] Clause 15A. The apparatus of any of Clauses 11A to 14A, wherein the apparatus comprises an encoder.

[0251] Clause 16A. The apparatus of any of Clauses 11A to 15A, further comprising means for generating the point cloud.

[0252] Clause 17A. The apparatus of any of Clauses 11A to 16A, further comprising a display for presenting an image based on the point cloud.

[0253] Clause 18A. A computer-readable storage medium having stored thereon instructions that, when executed, cause one or more processors to perform the method of any of clauses 1A to 9A.

[0254] Item 1B. A device configured to process point cloud data, the device comprising: a memory; and one or more processors, the one or more processors coupled to the memory, the one or more processors configured to: derive an azimuth value of a point based on the Cartesian coordinates of the point using a fixed-point implementation, wherein the fixed-point implementation includes applying a variable shift value; and decode the point cloud data based on the azimuth value.

[0255] Clause 2B. The apparatus of clause 1B, wherein to derive the azimuth value using the fixed-point implementation, the one or more processors are further configured to derive the variable shift value based on a number of bits used to decode the azimuth value.

[0256] Clause 3B. An apparatus according to clause 2B, wherein, in order to derive the variable shift value, the one or more processors are further configured to: derive the variable shift value according to the following function: sh = 44-(azimLog2-1), wherein sh is the variable shift value and azimLog2 is the number of bits used to decode the azimuth value.

[0257] Clause 4B. The apparatus of clause 3B, wherein the one or more processors are further configured to: decode a syntax element indicating a value of azimLog2.

[0258] Clause 5B. An apparatus as described in any of Clauses 1B to 4B, wherein to use the fixed point implementation, the one or more processors are further configured to: apply an offset associated with the variable shift value before applying the variable shift value.

[0259] Clause 6B. An apparatus as described in Clause 5B, wherein the one or more processors are further configured to: derive the offset associated with the variable shift value according to the following function: off=1<<(sh-1), where off is the offset and sh is the variable shift value.

[0260] Clause 7B. An apparatus according to any one of clauses 1B to 6B, wherein in order to use the fixed point to implement the deriving of the azimuth value of the point based on the Cartesian coordinates of the point, the one or more processors are further configured to: derive a temporary azimuth value based on the x and y Cartesian coordinates of the point; derive the variable shift value based on the number of bits used to decode the azimuth value; derive an offset based on the variable shift value; and derive the azimuth value based on the temporary azimuth value, the variable shift value, the offset and the number of bits used to decode the azimuth value.

[0261] Clause 8B. An apparatus according to any one of clauses 1B to 7B, wherein in order to further decode the point cloud data based on the azimuth value, the one or more processors are further configured to: determine a radius value of the point based on the Cartesian coordinates of the point; determine a laser ID of the point; and perform predictive geometric decoding on the point using the radius value, the azimuth value and the laser ID.

[0262] Clause 9B. An apparatus according to any one of clauses 1B to 8B, wherein in order to decode the point cloud data, the one or more processors are further configured to decode the point cloud data, and the apparatus further includes: a display configured to display the point cloud data.

[0263] Clause 10B. An apparatus according to any one of clauses 1B to 8B, wherein in order to decode the point cloud data, the one or more processors are further configured to encode the point cloud data, and the apparatus further includes: a LiDAR sensor, wherein the LiDAR sensor is configured to capture the point cloud data.

[0264] Clause 11B. A method of processing point cloud data, the method comprising: deriving an azimuth value of a point from Cartesian coordinates of the point using a fixed-point implementation, wherein the fixed-point implementation includes applying a variable shift value; and decoding the point cloud data based on the azimuth value.

[0265] Clause 12B. The method of clause 11B, wherein deriving the azimuth angle value using the fixed point implementation further comprises deriving the variable shift value based on a number of bits used to decode the azimuth angle value.

[0266] Clause 13B. The method of clause 12B, wherein deriving the variable shift value comprises deriving the variable shift value according to the following function: sh=44-(azimLog2-1), wherein sh is the variable shift value and azimLog2 is the number of bits used to decode the azimuth value.

[0267] Clause 14B. The method of clause 13B, further comprising: decoding a syntax element indicating a value of azimLog2.

[0268] Clause 15B. The method of any of Clauses 11B to 14B, wherein the fixed-point implementation further comprises applying an offset associated with the variable shift value prior to applying the variable shift value.

[0269] Clause 16B. The method of Clause 15B, further comprising: deriving the offset associated with the variable shift value according to the following function: off=1<<(sh−1), where off is the offset and sh is the variable shift value.

[0270] Clause 17B. A method according to any one of clauses 11B to 16B, wherein using the fixed point to implement deriving the azimuth value of the point based on the Cartesian coordinates of the point includes: deriving a temporary azimuth value based on the x and y Cartesian coordinates of the point; deriving the variable shift value based on the number of bits used to decode the azimuth value; deriving an offset based on the variable shift value; and deriving the azimuth value based on the temporary azimuth value, the variable shift value, the offset, and the number of bits used to decode the azimuth value.

[0271] Clause 18B. A method according to any one of clauses 11B to 17B, wherein decoding the point cloud data based on the azimuth value also includes: determining a radius value of the point based on the Cartesian coordinates of the point; determining a laser ID of the point; and performing predictive geometric decoding on the point using the radius value, the azimuth value, and the laser ID.

[0272] Clause 19B. The method of any one of clauses 11B to 18B, wherein deciphering comprises decoding, the method further comprising: displaying the point cloud data.

[0273] Clause 20B. The method of any one of clauses 11B to 18B, wherein decoding comprises encoding, the method further comprising: capturing the point cloud data.

[0274] Item 21B. A non-transitory computer-readable storage medium storing instructions that, when executed, cause one or more processors configured to process point cloud data to: derive an azimuth value of a point based on the Cartesian coordinates of the point using a fixed-point implementation, wherein the fixed-point implementation includes applying a variable shift value; and decode the point cloud data based on the azimuth value.

[0275] Clause 22B. A non-transitory computer-readable storage medium as described in Clause 21B, wherein, to further use the fixed-point implementation to derive the azimuth value, the instructions further cause the one or more processors to: derive the variable shift value based on the number of bits used to decode the azimuth value.

[0276] Clause 23B. A non-transitory computer-readable storage medium according to clause 22B, wherein, in order to derive the variable shift value, the instructions further cause the one or more processors to: derive the variable shift value according to the following function: sh = 44-(azimLog2-1), wherein sh is the variable shift value and azimLog2 is the number of bits used to decode the azimuth value.

[0277] Clause 24B. The non-transitory computer-readable storage medium of any of Clauses 21B to 23B, wherein to use the fixed-point implementation, the instructions further cause the one or more processors to: apply an offset associated with the variable shift value prior to applying the variable shift value.

[0278] Clause 25B. A non-transitory computer-readable storage medium as described in any one of clauses 21B to 24B, wherein in order to use the fixed-point implementation to derive the azimuth value of the point based on the Cartesian coordinates of the point, the instructions further cause the one or more processors to: derive a temporary azimuth value based on the x and y Cartesian coordinates of the point; derive the variable shift value based on the number of bits used to decode the azimuth value; derive an offset based on the variable shift value; and derive the azimuth value based on the temporary azimuth value, the variable shift value, the offset, and the number of bits used to decode the azimuth value.

[0279] Clause 26B. A device configured to process point cloud data, the device comprising: a component for deriving an azimuth value of a point based on the Cartesian coordinates of the point using a fixed-point implementation, wherein the fixed-point implementation includes applying a variable shift value; and a component for decoding the point cloud data based on the azimuth value.

[0280] Clause 27B. The apparatus of Clause 26B, wherein the means for deriving the azimuth angle value using the fixed point implementation further comprises means for deriving the variable shift value based on a number of bits used to decode the azimuth angle value.

[0281] Clause 28B. An apparatus according to clause 27B, wherein the means for deriving the variable shift value comprises: means for deriving the variable shift value according to the following function: sh=44-(azimLog2-1), wherein sh is the variable shift value and azimLog2 is the number of bits used to decode the azimuth value.

[0282] Clause 29B. The apparatus of any of Clauses 26B to 28B, wherein the fixed-point implementation further comprises means for applying an offset associated with the variable shift value prior to applying the variable shift value.

[0283] Clause 30B. An apparatus according to any one of clauses 26B to 29B, wherein the means for implementing the use of the fixed point to derive the azimuth value of the point based on the Cartesian coordinates of the point comprises: means for deriving a temporary azimuth value based on the x and y Cartesian coordinates of the point; means for deriving the variable shift value based on the number of bits used to decode the azimuth value; means for deriving an offset based on the variable shift value; and means for deriving the azimuth value based on the temporary azimuth value, the variable shift value, the offset and the number of bits used to decode the azimuth value.

[0284] It should be appreciated that, according to examples, certain actions or events of any of the techniques described herein may be performed in a different order, may be added, combined, or omitted entirely (e.g., not all actions or events described are necessary to implement the technique). In addition, in some examples, actions or events may be performed concurrently (e.g., through multithreading, interrupt processing, or multiple processors) rather than sequentially.

[0285] In one or more examples, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality may be stored as one or more instructions or codes on a computer-readable medium or sent via 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, which includes, for example, any medium that facilitates the transfer of a computer program from one place to another according to a communication protocol. Thus, a computer-readable medium may generally correspond to (1) a non-transient tangible computer-readable storage medium, or (2) a communication medium such as a signal or carrier wave. A data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, codes, and / or data structures for implementing the techniques described in the present disclosure. A computer program product may include a computer-readable medium.

[0286] By way of example and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices or other magnetic storage devices, flash memory, or any other medium that can be used to store the desired program code in the form of instructions or data structures and can be accessed by a computer. In addition, any connection is appropriately referred to as a computer-readable medium. For example, if the instruction is sent from a website, server or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL) or wireless technology (such as infrared, radio and microwave), the coaxial cable, fiber optic cable, twisted pair, DSL or wireless technology (such as infrared, radio and microwave) is included in the definition of the medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals or other transient media, but are instead directed to non-transient tangible storage media. As used herein, disks and optical disks include compact discs (CDs), laser optical disks, optical optical disks, digital versatile discs (DVDs), floppy disks and blue-ray discs, wherein disks usually reproduce data magnetically, while optical disks reproduce data optically using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0287] Instructions may 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 circuit systems. Therefore, the terms "processor" and "processing circuit system" as used herein may refer to any of the aforementioned structures or any other structure suitable for implementing the techniques described herein. In addition, in some aspects, the functionality described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated into a combined codec. In addition, these techniques may be fully implemented in one or more circuits or logic elements.

[0288] The techniques of the present disclosure may be implemented in a variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC), or a set of ICs (e.g., a chipset). Various components, modules, or units are described in the present disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require implementation by different hardware units. Specifically, as described above, the various units may be combined in a codec hardware unit, or the various units may be provided by a collection of interoperable hardware units (including one or more processors as described above) in combination with appropriate software and / or firmware.

[0289] Various examples have been described. These and other examples are within the scope of the following claims.

Claims

1. A device configured to process point cloud data, the device comprising: Memory; and one or more processors, the one or more processors coupled to the memory, the one or more processors configured to: deriving an azimuth value of a point from Cartesian coordinates of the point using a fixed point implementation, wherein the fixed point implementation includes applying a variable shift value; and The point cloud data is decoded based on the azimuth value.

2. The apparatus of claim 1 , wherein to derive the azimuth value using the fixed-point implementation, the one or more processors are further configured to: The variable shift value is derived based on a number of bits used to decode the azimuth value.

3. The apparatus of claim 2, wherein to derive the variable shift value, the one or more processors are further configured to: The variable shift value is derived according to the following function: sh=44-(azimLog2-1), where sh is the variable shift value and azimLog2 is the number of bits used to decode the azimuth value.

4. The apparatus of claim 3, wherein the one or more processors are further configured to: A syntax element indicating the value of azimLog2 is coded.

5. The apparatus of claim 1 , wherein to use the fixed-point implementation, the one or more processors are further configured to: An offset associated with the variable shift value is applied prior to applying the variable shift value.

6. The apparatus of claim 5, wherein the one or more processors are further configured to: The offset associated with the variable shift value is derived according to the following function: off=1<<(sh−1), where off is the offset and sh is the variable shift value.

7. The apparatus of claim 1 , wherein to implement the derivation of the azimuth value of the point from the Cartesian coordinates of the point using the fixed point, the one or more processors are further configured to: deriving a temporary azimuth value based on the x and y Cartesian coordinates of the point; deriving the variable shift value based on a number of bits used to decode the azimuth value; deriving an offset based on the variable shift value; as well as The azimuth value is derived based on the temporary azimuth value, the variable shift value, the offset, and the number of bits used to decode the azimuth value.

8. The apparatus of claim 1, wherein to decode the point cloud data further based on the azimuth value, the one or more processors are further configured to: Determine a radius value of the point according to the Cartesian coordinates of the point; determining a laser ID for the point; and Predictive geometric coding is performed on the point using the radius value, the azimuth value, and the laser ID.

9. The apparatus according to claim 1, wherein in order to decode the point cloud data, the one or more processors are further configured to decode the point cloud data, the apparatus further comprising: A display is configured to display the point cloud data.

10. The apparatus according to claim 1, wherein in order to decode the point cloud data, the one or more processors are further configured to encode the point cloud data, the apparatus further comprising: A LiDAR sensor is configured to capture the point cloud data.

11. A method for processing point cloud data, the method comprising: deriving an azimuth value of a point from Cartesian coordinates of the point using a fixed-point implementation, wherein the fixed-point implementation includes applying a variable shift value; as well as The point cloud data is decoded based on the azimuth value.

12. The method of claim 11, wherein deriving the azimuth angle value using the fixed-point implementation further comprises: The variable shift value is derived based on a number of bits used to decode the azimuth value.

13. The method of claim 12, wherein deriving the variable shift value comprises: The variable shift value is derived according to the following function: sh=44-(azimLog2-1), where sh is the variable shift value and azimLog2 is the number of bits used to decode the azimuth value.

14. The method according to claim 13, further comprising: A syntax element indicating the value of azimLog2 is coded.

15. The method of claim 11, wherein the fixed-point implementation further comprises applying an offset associated with the variable shift value prior to applying the variable shift value.

16. The method according to claim 15, further comprising: The offset associated with the variable shift value is derived according to the following function: off=1<<(sh−1), where off is the offset and sh is the variable shift value.

17. The method of claim 11, wherein using the fixed point to implement deriving the azimuth value of the point from the Cartesian coordinates of the point comprises: deriving a temporary azimuth value based on the x and y Cartesian coordinates of the point; deriving the variable shift value based on a number of bits used to decode the azimuth value; deriving an offset based on the variable shift value; as well as The azimuth value is derived based on the temporary azimuth value, the variable shift value, the offset, and the number of bits used to decode the azimuth value.

18. The method of claim 11, wherein decoding the point cloud data based on the azimuth value further comprises: Determine a radius value of the point according to the Cartesian coordinates of the point; determining a laser ID of the point; as well as Predictive geometric coding is performed on the point using the radius value, the azimuth value, and the laser ID.

19. The method of claim 11, wherein the decoding comprises decoding, the method further comprising: The point cloud data is displayed.

20. The method of claim 11, wherein decoding comprises encoding, the method further comprising: The point cloud data is captured.

21. A non-transitory computer-readable storage medium storing instructions that, when executed, cause one or more processors configured to process point cloud data: deriving an azimuth value of a point from Cartesian coordinates of the point using a fixed point implementation, wherein the fixed point implementation includes applying a variable shift value; and The point cloud data is decoded based on the azimuth value.

22. The non-transitory computer-readable storage medium of claim 21, wherein to further use the fixed-point implementation to derive the azimuth angle value, the instructions further cause the one or more processors to: The variable shift value is derived based on a number of bits used to decode the azimuth value.

23. The non-transitory computer-readable storage medium of claim 22, wherein to derive the variable shift value, the instructions further cause the one or more processors to: The variable shift value is derived according to the following function: sh=44-(azimLog2-1), where sh is the variable shift value and azimLog2 is the number of bits used to decode the azimuth value.

24. The non-transitory computer-readable storage medium of claim 21, wherein to use the fixed-point implementation, the instructions further cause the one or more processors to: An offset associated with the variable shift value is applied prior to applying the variable shift value.

25. The non-transitory computer-readable storage medium of claim 21, wherein to derive the azimuth value of the point from the Cartesian coordinates of the point using the fixed point implementation, the instructions further cause the one or more processors to: deriving a temporary azimuth value based on the x and y Cartesian coordinates of the point; deriving the variable shift value based on a number of bits used to decode the azimuth value; deriving an offset based on the variable shift value; as well as The azimuth value is derived based on the temporary azimuth value, the variable shift value, the offset, and the number of bits used to decode the azimuth value.

26. An apparatus configured to process point cloud data, the apparatus comprising: means for deriving an azimuth value of a point from Cartesian coordinates of the point using a fixed point implementation, wherein the fixed point implementation comprises applying a variable shift value; and Means for decoding the point cloud data based on the azimuth value.

27. The apparatus of claim 26, wherein the means for deriving the azimuth angle value using the fixed point implementation further comprises: Means for deriving the variable shift value based on a number of bits used to decode the azimuth angle value.

28. The apparatus of claim 27, wherein the means for deriving the variable shift value comprises: Means for deriving the variable shift value according to the following function: sh=44-(azimLog2-1), wherein sh is the variable shift value and azimLog2 is the number of bits used to decode the azimuth value.

29. The apparatus of claim 26, wherein the fixed-point implementation further comprises means for applying an offset associated with the variable shift value prior to applying the variable shift value.

30. The apparatus of claim 26, wherein the means for implementing, using the fixed point, deducing the azimuth value of the point from the Cartesian coordinates of the point comprises: means for deriving a temporary azimuth value based on the x and y Cartesian coordinates of the point; means for deriving the variable shift value based on a number of bits used to decode the azimuth value; means for deriving an offset based on the variable shift value; and Means for deriving the azimuth angle value based on the temporary azimuth angle value, the variable shift value, the offset, and the number of bits used to decode the azimuth angle value.

Images