Encoding and decoding the geometry of a point cloud

Abstract

Concepts for encoding and decoding a point cloud geometry are disclosed. In an encoding method, a geometry of a current point cloud into a set of portions of geometry is segmented, wherein each portion of geometry comprises at least one point of the current point cloud; for each portion of geometry of the set of portions of geometry, an attribute coding mode is selected based on each portion geometry; attributes associated with each portion of geometry based on the selected attribute coding mode are encoded.

Description

[0001] ENCODING AND DECODING THE GEOMETRY OF A POINT CLOUD

[0002] FIELD OF THE INVENTION

[0003] The invention relates to coding and decoding of a point cloud representing the external surface of a 3D object. In particular, it relates to encoding / decoding of the geometry of such a point cloud.

[0004] BACKGROUND OF THE INVENTION

[0005] Traditional visual data describes an object or scene using a series of points that each comprise a position in two dimensions (x and y) and one or more optional attributes like color. Volumetric visual data adds another positional dimension to this traditional visual data. Volumetric visual data describes an object or scene using a series of points that each comprise a position in three dimensions (x, y, and z) and one or more optional attributes like color, reflectance, time stamp, etc. Compared to traditional visual data, volumetric visual data may provide a more immersive way to experience visual data.

[0006] For example, an object or scene described by volumetric visual data may be viewed from any (or multiple) angles, whereas traditional visual data may generally only be viewed from the angle in which it was captured or rendered. Volumetric visual data may be used in many applications, including Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR). Sparse volumetric visual data may be used in the automotive industry for the representation of 3D maps (cartography) or as input to assisted driving systems. In the latter use case, volumetric visual data is typically input to driving decision algorithms. In another example, volumetric visual data may be used to store valuable objects in digital form. In applications for preserving cultural heritage, the goal is to keep a representation of objects that may be threatened by natural disasters. For example, statues, vases, and temples may be entirely scanned and stored as volumetric visual data having several billions of samples. This use case for volumetric visual data may be particularly relevant for valuable objects in locations where earthquakes, tsunamis, and typhoons are frequent. Volumetric visual data may be in the form of a volumetric frame that describes an object or scene captured at a particular time instance or in the form of a sequence of volumetric frames (referred to as a volumetric sequence or volumetric video) that describes an object or scene captured at multiple different time instances.

[0007] One format for storing volumetric visual data is point clouds. A point cloud comprises a collection of points in three-dimensional (3D) space. Each point in a point cloud may comprise geometry information that indicates the point’s position in 3D space. For example, the geometry information may indicate the point’s position in 3D space using three Cartesian coordinates (x, y, and z) or using spherical coordinates (r, phi, theta) (e.g., when acquired by a rotating sensor). The positions of points in a point cloud may be quantized according to a space precision, which may be the same or different in each dimension. The quantization process may create a grid in 3D space. One or more points residing within each sub-grid volume may be mapped to the sub-grid center coordinates, referred to as voxels. A voxel (also referred to as a volumetric pixel) may be considered as a 3D extension of pixels corresponding to the 2D image grid coordinates. For example, similar to a pixel being the smallest unit when dividing the 2D space (or 2D image) into discrete, uniform (e.g., equally sized) regions, a voxel may be the smallest unit of volume when dividing 3D space into discrete, uniform regions. The sub-grid center coordinates (which correspond to voxels) may be referred to as a voxelized grid. A point in a point cloud may further comprise one or more types of attribute information. Attribute information may indicate a property of a point’s visual appearance. For example, attribute information may indicate a texture (e.g., color) of the point, a material type of the point, transparency information of the point, reflectance information of the point, a normal vector to a surface of the point, a velocity at the point, an acceleration at the point, a time stamp indicating when the point was captured, or a modality indicating how the point was captured (e.g., running, walking, or flying). In another example, a point in a point cloud may comprise light field data in the form of multiple view-dependent texture information. Light field data may be another type of optional attribute information.

[0008] The points in a point cloud may describe an object or a scene. For example, the points in a point cloud may describe the external surface and / or the internal structure of an object or scene. The object or scene may be synthetically generated by a computer or may be generated from the capture of a real-world object or scene. The geometry information of a real-world object or scene may be obtained by 3D scanning and / or photogrammetry. 3D scanning may include laser scanning, structured light scanning, and / or modulated light scanning. 3D scanning may obtain geometry information by moving one or more laser heads, structured light cameras, and / or modulated light cameras relative to an object or scene being scanned. Photogrammetry may obtain geometry information by triangulating the same feature or point in different spatially shifted 2D photographs. Point cloud data may be in the form of a point cloud frame that describes an object or scene captured at a particular time instance or in the form of a sequence of point cloud frames (referred to as a point cloud sequence or point cloud video) that describes an object or scene captured at multiple different time instances.

[0009] The data size of a point cloud frame or sequence may be too large for storage and / or transmission in many applications. For example, a single point cloud may comprise over a million points or even billions of points, where each point may comprise geometry information and one or more optional types of attribute information. The geometry information of each point may comprise three Cartesian coordinates (x, y, and z) or spherical coordinates (r, phi, theta) that are each represented, for example, using at least 10 bits per component or 30 bits in total. The attribute information of each point may comprise a texture corresponding to three color components (e.g., R, G, and B color components) that are each represented, for example, using 8-10 bits per component or 24-30 bits in total. A single point therefore comprises at least 54 bits of information in this example, with at least 30 bits of geometry information and at least 24 bits of texture. If a point cloud frame includes a million such points, each point cloud frame would require 54 million bits or 54 megabits to represent. In case of dynamic point clouds that change over time, at a frame rate of 30 frames per second, a data rate of 1.62 gigabits per second would be required to transmit the points of the point cloud sequence. Therefore, raw representations of point clouds may require a large amount of data and the practical deployment of point-cloud-based technologies may need compression technologies that enable the storage and distribution of point clouds with reasonable cost.

[0010] Encoding may be used to compress and / or reduce the data size of a point cloud frame or sequence to provide for more efficient storage and / or transmission. Decoding may be used to decompress a compressed point cloud frame or sequence for display and / or other forms of consumption (e.g., by a machine learning-based device, neural network-based device, artificial intelligence-based device, or other forms of consumption by other types of machine-based processing algorithms and / or devices). Compression of point clouds may be lossy (introducing differences relative to the original data) for the distribution to and visualization by an end-user, for example, on AR or VR glasses or any other 3D- capable device. Lossy compression may allow for a high ratio of compression but may imply a trade-off between compression and visual quality perceived by an end-user. Other frameworks, like medical applications or autonomous driving, may require lossless compression to avoid altering the results of a decision obtained based on the analysis of the transmitted and decompressed point cloud frame.

[0011] SUMMARY OF THE INVENTION

[0012] To improve the encoding and decoding the geometry of a point cloud, the present embodiments set out to remedy at least one of the drawbacks of the prior art with a method of encoding a point cloud geometry comprising: segmenting a geometry of a current point cloud into a set of portions of geometry, wherein each portion of geometry comprises at least one point of the current point cloud; selecting, for each portion of geometry of the set of portions of geometry, an attribute coding mode based on each portion geometry; and encoding attributes associated with each portion of geometry based on the selected attribute coding mode.

[0013] Also disclosed is a method of decoding a point cloud geometry, comprising: segmenting a geometry of a current point cloud into a set of portions of geometry, wherein each portion of geometry comprises at least one point of the current point cloud; selecting, for each portion of geometry of the set of portions of geometry, an attribute coding mode based on each portion geometry; and decoding attributes associated with each portion of geometry based on the selected attribute coding mode. Also disclosed is a device comprising one or more processor configured to: segment a geometry of a current point cloud into a set of portions of geometry, wherein each portion of geometry comprises at least one point of the current point cloud; select, for each portion of geometry of the set of portions of geometry, an attribute coding mode based on each portion geometry; and encode or decode attributes associated with each portion of geometry based on the selected attribute coding mode.

[0014] Also disclosed is a computer program product comprising computer program code means which, when executed on a computing device having a processing system, cause the processing system to perform all of the steps of any method described above.

[0015] The specific nature of the present embodiments as well as other objects, advantages, features and uses of the present embodiments will become evident from the following description of examples taken in conjunction with the accompanying drawings.

[0016] BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Examples of several of the various embodiments of the present disclosure are described herein with reference to the drawings.

[0018] FIG. 1 illustrates an exemplary point cloud coding / decoding system in which embodiments of the present disclosure may be implemented.

[0019] FIG. 2 illustrates the Morton order of eight sub-cuboids split from a cuboid.

[0020] FIG. 3 illustrates an example processing or scanning order for the first three levels of an occupancy tree.

[0021] FIG. 4 illustrates an example of already-coded occupancies of cuboids that may be used to code the occupancy of a current child cuboid.

[0022] FIG. 5 illustrates an example of a dynamic reduction function DR that may be used in dynamic OBUF.

[0023] FIG. 6 illustrates a flowchart of an example method for coding the occupancy (e.g., as indicated by a single bit) of a current child cuboid using dynamic OBUF.

[0024] FIG. 7 illustrates an example of an occupied cube of size NxNxN (where N > 1) that corresponds to a TriSoup node of an occupancy tree.

[0025] FIG. 8A illustrates an example cube corresponding to a TriSoup node with a number K of TriSoup vertices Vk.

[0026] FIG. 8B illustrates an example refinement to the TriSoup model by coding a centroid residual vector Cres into the bitstream such as to use C+Cres instead of C as pivoting vertex for the triangles. FIG. 8C illustrates an example of coding a centroid residual vector Cresin / from the bitstream such that an adjusted centroid C+Cresis used instead of centroid C for generating TriSoup triangles of a cuboid corresponding to a portion of a point cloud.

[0027] FIG. 9A and FIG. 9B illustrate examples of voxelization.

[0028] FIG. 10 illustrates an example process for encoding geometry and attributes of a current point cloud.

[0029] FIG. 11 illustrates an example process for encoding attributes associated with a portion of geometry of the decoded geometry.

[0030] FIG. 12 illustrates an example process for decoding geometry and attributes of a current point cloud.

[0031] FIG. 13 illustrates an example process for decoding attributes associated with a portion of geometry of the decoded geometry.

[0032] FIG. 14 illustrates an example process for determining attribute predictors of attributes associated with portion of geometry.

[0033] FIG. 15 illustrates an example process for encoding attributes based on attribute predictors associated with portion of geometry.

[0034] FIG. 16 illustrates another example process for encoding attributes based on attribute predictors associated with portion.

[0035] FIG. 17 illustrates an example process for decoding attributes based on attribute predictors associated with portion of geometry.

[0036] FIG. 18 illustrates another example process for decoding attributes based on attribute predictors associated with portion of geometry.

[0037] FIG. 19 illustrates a diagram of an example process for transforming a set ‘a’ of attributes based on a prediction transform scheme.

[0038] FIG. 20 illustrates a diagram of an example process for inverse transforming transformed coefficients based on inverse prediction transform scheme.

[0039] FIG. 21 illustrates a diagram of an example process for transforming a set ‘a’ of attributes based on a pred-lift transform scheme with prediction and update.

[0040] FIG. 22 illustrates a diagram of an example process for inverse transforming transformed coefficients based on an inverse pred-lift transform scheme with prediction and update.

[0041] FIG. 23 illustrates an example RAHT transformation applied on child nodes of an octree parent node along three successive directions.

[0042] FIG. 24 illustrates an example RAHT transformation being applied to all octree nodes at depth ‘d’ to determine DC coefficients at depth d-1 and AC coefficients. FIG. 25 illustrates an example process for encoding attributes associated with a portion of geometry of a current point cloud, according to embodiments.

[0043] FIG. 26 illustrates an example process for decoding attributes associated with a portion of geometry of a current point cloud, according to embodiments.

[0044] FIG. 1 illustrates an example process for selecting an attribute coding mode from a list of candidate attribute coding modes, according to embodiments.

[0045] FIG. 28A illustrates an example of point-to-point projection distance between a point of a portion of geometry and its nearest neighbor points of a motion compensated geometry, according to some embodiments.

[0046] FIG. 28B illustrates an example of point-to-point projection distance between a point of the reference point cloud for attributes and its nearest neighbor point of a motion compensated geometry, according to some embodiments.

[0047] FIG. 29 illustrates a flowchart of an example method for encoding attributes of a point cloud based on selected attribute coding mode, according to some embodiments.

[0048] FIG. 30 illustrates a flowchart of an example method for decoding attributes of a point cloud based on selected attribute coding mode, according to some embodiments.

[0049] FIG. 31 illustrates a block diagram of an example computer system in which embodiments of the present disclosure may be implemented.

[0050] DETAILED DESCRIPTION OF THE FIGURES

[0051] In the following description, numerous specific details are set forth in order to provide a thorough understanding of the disclosure. However, it will be apparent to those skilled in the art that the disclosure, including structures, systems, and methods, may be practiced without these specific details. The description and representation herein are the common means used by those experienced or skilled in the art to most effectively convey the substance of their work to others skilled in the art. In other instances, well-known methods, procedures, components, and circuitry have not been described in detail to avoid unnecessarily obscuring aspects of the disclosure.

[0052] References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described. Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0053] The term “computer-readable medium” includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other mediums capable of storing, containing, or carrying instruction(s) and / or data. A computer-readable medium may include a non-transitory medium in which data can be stored and that does not include carrier waves and / or transitory electronic signals propagating wirelessly or over wired connections. Examples of a non-transitory medium may include, but are not limited to, a magnetic disk or tape, optical storage media such as compact disk (CD) or digital versatile disk (DVD), flash memory, memory or memory devices. A computer-readable medium may have stored thereon code and / or machine-executable instructions that may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, or the like.

[0054] Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks (e.g., a computer-program product) may be stored in a computer-readable or machine-readable medium. A processor(s) may perform the necessary tasks.

[0055] FIG. 1 illustrates an exemplary point cloud coding system 100 in which embodiments of the present disclosure may be implemented. Point cloud coding system 100 comprises a source device 102, a transmission medium 104, and a destination device 106. Source device 102 encodes a point cloud sequence 108 into a bitstream 110 for more efficient storage and / or transmission. Source device 102 may store and / or transmit bitstream 110 to destination device 106 via transmission medium 104. Destination device 106 decodes bitstream 110 to display point cloud sequence 108 or for other forms of consumption. Destination device 106 may receive bitstream 110 from source device 102 via a storage medium or transmission medium 104. Source device 102 and destination device 106 may be any one of a number of different devices, including a cluster of interconnected computer systems acting as a pool of seamless resources (also referred to as a cloud of computers or cloud computer), a server, a desktop computer, a laptop computer, a tablet computer, a smart phone, a wearable device, a television, a camera, a video gaming console, a set-top box, a video streaming device, an autonomous vehicle, or a head mounted display. A head mounted display may allow a user to view a VR, AR, or MR scene and adjust the view of the scene based on movement of the user’s head. A head mounted display may be tethered to a processing device (e.g., a server, desktop computer, set-top box, or video gaming counsel) or may be fully self- contained.

[0056] To encode point cloud sequence 108 into bitstream 110, source device 102 may comprise a point cloud source 112, an encoder 114, and an output interface 116. Point cloud source 112 may provide or generate point cloud sequence 108 from a capture of a natural scene and / or a synthetically generated scene. A synthetically generated scene may be a scene comprising computer generated graphics. Point cloud source 112 may comprise one or more point cloud capture devices (e.g., one or more laser scanning devices, structured light scanning devices, modulated light scanning devices, and / or passive scanning devices), a point cloud archive comprising previously captured natural scenes and / or synthetically generated scenes, a point cloud feed interface to receive captured natural scenes and / or synthetically generated scenes from a point cloud content provider, and / or a processor to generate synthetic point cloud scenes.

[0057] As shown in FIG. 1, a point cloud sequence 108 may comprise a series of point cloud frames 124. A point cloud frame may describe an object or scene captured at a particular time instance. Point cloud sequence 108 may achieve the impression of motion when a constant or variable time is used to successively present point cloud frames 124 of point cloud sequence 108. A point cloud frame may comprise a collection of points 126 in 3D space. Each of points 126 may comprise geometry information that indicates the point’s position in 3D space. For example, the geometry information may indicate the point’s position in 3D space using three Cartesian coordinates (x, y, and z). One or more of points 126 may further comprise one or more types of attribute information. Attribute information may indicate a property of a point’s visual appearance. For example, attribute information may indicate a texture (e.g., color) of a point, a material type of a point, transparency information of a point, reflectance information of a point, a normal vector to a surface of a point, a velocity at a point, an acceleration at a point, a time stamp indicating when a point was captured, a modality indicating how a point was captured (e.g., running, walking, or flying). In another example, one or more of points 126 may comprise light field data in the form of multiple view-dependent texture information. Light field data may be another type of optional attribute information. Color attribute information of one or more of points 126 may comprise a luminance value and two chrominance values. The luminance value may represent the brightness (or luma component, Y) of the point. The chrominance values may respectively represent the blue and red components of the point (or chroma components, Cb and Cr) separate from the brightness. Other color attribute values are possible based on different color schemes (e.g., an RGB or monochrome color scheme).

[0058] Encoder 114 may encode point cloud sequence 108 into bitstream 110. To encode point cloud sequence 108, encoder 114 may apply one or more lossy compression techniques and / or prediction techniques to reduce redundant information in point cloud sequence 108. Redundant information is information that may be predicted at a decoder and therefore may not be needed to be transmitted to the decoder for accurate decoding of point cloud sequence 108. For example, Motion Picture Expert Group (MPEG) introduced a geometry -based point cloud compression (G-PCC) standard (ISO / IEC standard 23090-9: Geometry -based point cloud compression). G-PCC specifies the encoded bitstream syntax and semantics for transmission and / or storage of a compressed point cloud frame and the decoder operation for reconstructing the compressed point cloud frame from the bitstream. During standardization of G-PCC, a reference software (ISO / IEC standard 23090-21: Reference Software for G-PCC) was developed to encode the geometry and attribute information of a point cloud frame. To encode geometry information of a point cloud frame, the G-PCC reference software encoder may perform voxelization by quantizing positions of points in a point cloud, which creates a grid in 3D space. The G-PCC reference software encoder may map the points to the center coordinates of the sub-grid volume (or voxel) that their quantized locations reside. The G-PCC reference software encoder may perform geometry analysis using an occupancy tree to compress the geometry information. The G-PCC reference software encoder may entropy encode the result of the geometry analysis to further compress the geometry information. To encode attribute information of a point cloud, the G-PCC reference software encoder may apply a transform tool, such as Region Adaptive Hierarchical Transform (RAHT), the Predicting Transform, and / or the Lifting Transform. The Lifting Transform may be built on top of the Predicting Transform but with an extra update / lifting step. Consequently, these two transforms may be referred to as Predicting / Lifting Transform or pred lift. Encoder 114 may operate in a same or similar manner to an encoder provided by the G-PCC reference software.

[0059] Output interface 116 may be configured to write and / or store bitstream 110 onto transmission medium 104 for transmission to destination device 106. In addition, or alternatively, output interface 116 may be configured to transmit, upload, and / or stream bitstream 110 to destination device 106 via transmission medium 104. Output interface 116 may comprise a wired and / or wireless transmitter configured to transmit, upload, and / or stream bitstream 110 according to one or more proprietary and / or standardized communication protocols, such as Digital Video Broadcasting (DVB) standards, Advanced Television Systems Committee (ATSC) standards, Integrated Services Digital Broadcasting (ISDB) standards, Data Over Cable Service Interface Specification (DOCSIS) standards, 3rd Generation Partnership Project (3GPP) standards, Institute of Electrical and Electronics Engineers (IEEE) standards, Internet Protocol (IP) standards, and Wireless Application Protocol (WAP) standards.

[0060] Transmission medium 104 may comprise a wireless, wired, and / or computer readable medium. For example, transmission medium 104 may comprise one or more wires, cables, air interfaces, optical discs, flash memory, and / or magnetic memory. In addition or alternatively, transmission medium 104 may comprise one more networks (e.g., the Internet) or file servers configured to store and / or transmit encoded video data.

[0061] To decode bitstream 110 into point cloud sequence 108 for display or other forms of consumption, destination device 106 may comprise an input interface 118, a decoder 120, and a point cloud display 122. Input interface 118 may be configured to read bitstream 110 stored on transmission medium 104 by source device 102. In addition, or alternatively, input interface 118 may be configured to receive, download, and / or stream bitstream 110 from source device 102 via transmission medium 104. Input interface 118 may comprise a wired and / or wireless receiver configured to receive, download, and / or stream bitstream 110 according to one or more proprietary and / or standardized communication protocols, such as those mentioned above.

[0062] Decoder 120 may decode point cloud sequence 108 from encoded bitstream 110. For example, decoder 120 may operate in a same or similar manner to a decoder provided by G-PCC reference software. In some examples, decoder 120 may decode a point cloud sequence that approximates point cloud sequence 108 due to, for example, lossy compression of point cloud sequence 108 by encoder 114 and / or errors introduced into encoded bitstream 110 during transmission to destination device 106.

[0063] Point cloud display 122 may display point cloud sequence 108 to a user. Point cloud display 122 may comprise a cathode rate tube (CRT) display, a liquid crystal display (LCD), a plasma display, a light emitting diode (LED) display, a 3D display, a holographic display, a head mounted display, or any other display device suitable for displaying point cloud sequence 108.

[0064] It should be noted that point cloud coding / decoding system 100 is presented by way of example and not limitation. In the example of FIG. 1, point cloud coding / decoding system 100 may have other components and / or arrangements. For example, point cloud source 112 may be external to source device 102. Similarly, point cloud display 122 may be external to destination device 106 or omitted altogether where point cloud sequence is intended for consumption by a machine and / or storage device. In another example, source device 102 may further comprise a point cloud decoder and destination device 106 may comprise a point cloud encoder. In such an example, source device 102 may be configured to further receive an encoded bit stream from destination device 106 to support two-way point cloud transmission between the devices.

[0065] As mentioned above, an encoder may quantize the positions of points in a point cloud according to a space precision, which may be the same or different in each dimension of the points. The quantization process may create a grid in 3D space. The encoder may map any points residing within each sub-grid volume to the sub-grid center coordinates, referred to as a voxel (or a volumetric pixel). A voxel may be considered as a 3D extension of pixels corresponding to 2D image grid coordinates.

[0066] The encoder may represent or code the point cloud using an occupancy free. For example, the encoder may split the initial volume or cuboid (also referred to as a bounding box) containing the point cloud into sub-cuboids. The encoder may then recursively split each sub-cuboid that contains at least one point of the point cloud. The encoder may not further split sub-cuboids that do not contain at least one point of the point cloud. A sub-cuboid that contains at least one point of the point cloud may be referred to as an occupied sub-cuboid. A sub-cuboid that does not contain at least one point of the point cloud may be referred to as an unoccupied sub-cuboid. The encoder may split an occupied cuboid into, for example, two sub-cuboids (to form a binary free), four sub-cuboids (to form a quadtree), or eight sub-cuboids (to form an octree). The encoder may split an occupied cuboid to obtain sub-cuboids all with the same size and shape at a given depth level of the occupancy tree by splitting following a plane passing through the middle of edges of the cuboid.

[0067] The initial volume or cuboid containing the point cloud may correspond to the root node of the occupancy tree. Each occupied sub-cuboid, split from the initial volume / cuboid, may correspond to a node (of the root node) in a second level of the occupancy tree. Each occupied sub-cuboid, split from an occupied sub-cuboid in the second level, may correspond to a node (off the occupied sub-cuboid in the second level from which it was split) in a third level of the occupancy tree. The occupancy free structure may continue to form in this manner for each recursive split iteration until, for example, a maximum depth level of the occupancy free is reached or each occupied sub-cuboid has a volume corresponding to one voxel.

[0068] Each non-leaf node of the occupancy tree may comprise or be associated with an occupancy word representing an occupancy state of the cuboid corresponding to the node. For example, a node of the occupancy tree corresponding to a cuboid that is split into 8 sub-cuboids may comprise or be associated with a 1-byte occupancy word. Each bit (referred to as an occupancy bit) of the 1-byte occupancy word may represent or indicate the occupancy of a different one of the eight sub-cuboids. Occupied sub-cuboids may be represented or indicated by a binary value of 1 in the 1-byte occupancy word and unoccupied subcuboids may be represented or indicated by a binary value of 0 in the 1-byte occupancy word. In other examples, occupied and un-occupied sub-cuboids may be represented or indicated by opposite 1 -bit binary values in the 1-byte occupancy word.

[0069] Each bit of an occupancy word may represent or indicate the occupancy of a different one of the eight sub-cuboids following the so-called Morton order. For example, the least significant bit of an occupancy word may represent or indicate the occupancy of a first one of the eight sub-cuboids following the Morton order, the second least significant bit of an occupancy word may represent or indicate the occupancy of a second one of the eight sub-cuboids following the Morton order, etc.

[0070] FIG. 2 illustrates the Morton order of eight sub-cuboids 202-216 split from a cuboid 200. Subcuboids 202-216 are labeled based on their Morton order, with child node 202 being the first in Morton order and child node 216 being the last in Morton order. The Morton order for sub-cuboids 202-216 is a local lexicographic order in xyz.

[0071] The geometry of the point cloud is represented by, and therefore may be determined from, the initial volume and the occupancy words of the nodes in the occupancy tree. The encoder may therefore transmit the initial volume and the occupancy words of the nodes in the occupancy tree in a bitstream to a decoder for reconstructing the point cloud. Before transmitting the initial volume and the occupancy words of the nodes in the occupancy tree, the encoder may entropy encode the occupancy words. For example, the encoder may encode an occupancy bit of an occupancy word of a node corresponding to a cuboid, based on one or more occupancy bits of occupancy words of other nodes corresponding to cuboids that are adjacent or spatially close to the cuboid of the occupancy bit being encoded.

[0072] An encoder and / or decoder may code occupancy bits of occupancy words in sequence of a scan order. For example, an encoder and / or decoder may scan an occupancy tree in breadth-first order: all the occupancy words of the nodes of a given depth (or level) within the occupancy tree may be scanned before scanning the occupancy words of the nodes of the next depth (or level). Within a depth, the encoder and / or decoder may scan the occupancy words of nodes in the Morton order. Within a node, the encoder and / or decoder may scan the occupancy bits of the occupancy word of the node further in the Morton order.

[0073] FIG. 3 illustrates an example of this scanning order for the first three levels of an occupancy tree 300. At each level of occupancy tree 300, a plurality of cuboids (e.g., cubes) are generated. In FIG. 3, a cube 302 corresponding to the root node of occupancy tree 300 is divided into eight sub-cubes. Two subcubes 304 and 306 of the eight sub-cubes are occupied, while the other six sub-cubes are unoccupied. Following the Morton order, a first eight-bit occupancy word occWi.i is constructed to represent the occupancy word of the root node. The least significant occupancy bit of the first eight-bit occupancy word occWi.i represents or indicates the occupancy of the first sub-cube of the eight sub-cubes in Morton order, the second least significant occupancy bit of the first eight-bit occupancy word occWi.i represents or indicates the occupancy of the second sub-cube of the eight sub-cubes in Morton order, etc.

[0074] Each of the two occupied sub-cubes 304 and 306 corresponds to a node off the root node in a second level of occupancy tree 300. The two occupied sub-cubes 304 and 306 are each further split into eight sub-cubes. One of the sub-cubes 308 of the eight sub-cubes split from sub-cube 304 is occupied, while the other seven sub-cubes are unoccupied. Three of the sub-cubes 310, 312, and 314 of the eight sub-cubes split from sub-cube 306 are occupied, while the other five sub-cubes of the eight sub-cubes split from sub-cube 306 are unoccupied. Two second eight-bit occupancy words occW2,i and occW2,2 are constructed in this order to respectively represent the occupancy word of the node corresponding to subcube 304 and the occupancy word of the node corresponding to sub-cube 306.

[0075] Each of the four occupied sub-cubes 308, 310, 312, and 314 corresponds to a node in a third level of occupancy free 300. The four occupied sub-cubes 308, 310, 312, and 314 are each further split into eight sub-cubes or 32 sub-cubes in total. Four third eight-bit occupancy words occWs.i, occW3.2, occW , and occW3,4 are constructed in this order to respectively represent the occupancy word of the node corresponding to sub-cube 308, the occupancy word of the node corresponding to sub-cube 310, the occupancy word of the node corresponding to sub-cube 312, and the occupancy word of the node corresponding to sub-cube 314.

[0076] Following the scanning order discussed above, the occupancy words of this exemplary occupancy tree 300 may be entropy coded (e.g., entropy encoded by an encoder and entropy decoded by a decoder) as the succession of the seven occupancy words occWi.i to occW3,4. As a consequence of the breadth-first scanning order, when entropy coding the occupancy word of a current child node belonging to a current parent node, the occupancy words of all nodes having the same depth (or level) as the current parent node have already been entropy coded. In addition, the occupancy words of all nodes having the same depth (or level) as the current child node and having a lower Morton order than the current child node have also already been entropy coded. Part of these already coded occupancy words may be used to entropy code the occupancy word of the current child node. For example, the already coded occupancy words of neighboring parent and child nodes may be used to entropy code the occupancy word of the current child node. When entropy coding a particular occupancy bit of the occupancy word of the current child node, the occupancy bits of the occupancy word having a lower Morton order than the particular occupancy bit have also already been entropy coded and may be used to code the occupancy bit of the occupancy word of the current child node.

[0077] FIG. 4 illustrates an example neighborhood of cuboids with already-coded occupancy bits that may be used to entropy code the occupancy bit of a current child cuboid 400. The neighborhood of cuboids with already-coded occupancy bits may be determined based on the scanning order of an occupancy tree representing the geometry of the cuboids in FIG. 4 as discussed above. As illustrated in FIG. 4, current child cuboid 400 belongs to a current parent cuboid 402. Following the scanning order of the occupancy words and occupancy bits of nodes of the occupancy tree, the occupancy bits of four child cuboids 404, 406, 408, and 410, belonging to the same current parent cuboid 402, have already been coded. Also, the occupancy bit of child cuboids 412 of preceding parent cuboids have already been coded. Furthermore, the occupancy bits of parent cuboids 414, for which the occupancy bits of child cuboids have not already been coded, have already been coded. Therefore, the already -coded occupancy bits of cuboids 404, 406, 408, 410, 412, and 414 may be used to code the occupancy bit of the current child cuboid 400.

[0078] The number of possible occupancy configurations for a neighborhood of a current child cuboid may be 2N, where N is the number of cuboids in the neighborhood of the current child cuboid with already -coded occupancy bits. The neighborhood of the current child cuboid may comprise several dozens of cuboids, among them the 26 adjacent parent cuboids sharing a face, an, edge, or a vertex with the parent cuboid of the current child cuboid and also several adjacent child cuboids (with occupancy bits already coded) sharing a face, an edge, or a vertex with the current child cuboid. Even limited to a subset of the adjacent cuboids, the occupancy configuration for a neighborhood of the current child cuboid may have billions of possible occupancy configurations making its direct use impractical. The occupancy configuration for a neighborhood of the current child cuboid may be used by an encoder and / or decoder to select the context (or equivalently the probability model), among a set of contexts, of a binary entropy coder (e.g., binary arithmetic coder) that codes the occupancy bit of the current child cuboid. The contextbased binary entropy coding may be similar to the Context Adaptive Binary Arithmetic Coder (CABAC) used in MPEG-H Part 2 (also known as High Efficiency Video Coding (HEVC)).

[0079] Several methods may be used by an encoder and / or decoder to reduce the occupancy configurations for a neighborhood of a current child cuboid being coded to a practical number of reduced occupancy configurations. Firstly, the 26or 64 occupancy configurations of the six adjacent parent cuboids sharing a face with the parent cuboid of the current child cuboid may be reduced to 9 occupancy configurations by using geometry invariance. Secondly, an occupancy score for the current child cuboid may be obtained from the 226occupancy configurations of the 26 adjacent parent cuboids. The score may be further reduced into a ternary occupancy prediction (“predicted occupied”, “unsure”, “predicted unoccupied”) by applying score thresholds. Thirdly, the number of occupied and the number of unoccupied adjacent child cuboids may be used instead of the individual occupancies of these child cuboids.

[0080] An encoder and / or decoder employing one or more of the above methods may reduce the number of possible occupancy configurations for a neighborhood of a current child cuboid to a more manageable number (e.g., a few thousands). However, it has been observed that instead of associating a reduced number of contexts (or probability models) directly to the reduced occupancy configurations, another mechanism may be used, namely Optimal Binary Coders with Update on the Fly (OBUF). An encoder and / or decoder may implement OBUF to limit the number of contexts to a lower number (e.g., 32 contexts).

[0081] OBUF may use a limited number (e.g., 32) of contexts that may be fixed. These contexts may be ordered, referred to by a context index (e.g., a context index in the range of 0 to 31), and associated from a lowest virtual probability to a highest virtual probability to code a 1. A Look-Up Table (LUT) of context indices may be initialized at the beginning of a point cloud coding process. For example, the LUT may initially point to a context (e.g., context with context index 15), among the limited number of contexts, with the median virtual probability to code a 1 for all input. This LUT may take an occupancy configuration for a neighborhood of current child cuboid as input and output the context index associated with the occupancy configuration. Consequently, the LUT may have as many entries as reduced occupancy configurations (e.g., around a few thousand). The coding of the occupancy bit of a current child cuboid may follow the steps of determining the reduced occupancy configuration of the current child node, obtaining a context index by applying the reduced occupancy configuration as an entry to the LUT, coding the occupancy bit of the current child cuboid by using the context pointed to (or indicated) by the context index, and finally updating the LUT entry corresponding to the reduced occupancy configuration depending on the value of the coded occupancy bit of the current child cuboid. If a binary 0 (e.g., indicating the current child cuboid is unoccupied) is coded, the LUT entry may be decreased to a lower context index value, and if a binary 1 (e.g., indicating the current child cuboid is occupied) is coded, the LUT entry may be increased to a higher context index value. The update process of the context index may be based on a theoretical model of optimal distribution for virtual probabilities associated with the limited number of contexts. This virtual probability for a context may be fixed by a model and may be different from the internal probability of the context that evolves during the coding of bits of data. The evolution of the internal context may follow a well-known process similar to the process in CABAC.

[0082] An encoder and / or decoder may implement a “dynamic OBUF” scheme that may handle a much larger number of occupancy configurations for a neighborhood of a current child cuboid than can be handled by general OBUF, while maintaining complexity within reasonable bounds. The use of a larger number of occupancy configurations for a neighborhood of a current child cuboid may lead to improved compression capabilities. By using an occupancy tree compressed by OBUF, an encoder and / or decoder may reach a lossless compression performance as good as 1 bit per point (bpp) for coding the geometry of dense point clouds. An encoder and / or decoder may implement dynamic OBUF to potentially further reduce the bitrate by more than 25% to 0.7 bpp. OBUF may not take as input a large variety of reduced occupancy configurations for a neighborhood of a current child cuboid, thus potentially leading to a loss of useful correlation. The size of the LUT of context indices may be increased to handle more various occupancy configurations for a neighborhood of a current child cuboid as input. However, by doing so, statistics may be diluted, and compression performance may be reduced. For example, if the LUT has millions of entries and the point cloud has a hundred thousand points, then most of the entries are never visited. Worse yet, many entries may be visited only a few times and their associated context indices may not be updated enough times to reflect any meaningful correlation between the occupancy configuration value and the probability of occupancy of the current child cuboid. Dynamic OBUF may be implemented to mitigate the dilution of statistics due to the increase in the number of occupancy configurations for a neighborhood of a current child cuboid. This mitigation is performed by a “dynamic reduction” of occupancy configurations in dynamic OBUF.

[0083] Dynamic OBUF may add an extra step of reduction of occupancy configurations for a neighborhood of a current child cuboid before applying the LUT of context indices. This step may be called a dynamic reduction because it evolves based on the progress of the coding of the point cloud or, more precisely, based on already visited occupancy configurations.

[0084] As discussed above, many possible occupancy configurations for a neighborhood of a current child cuboid are potentially involved but only a subset may be visited during the coding of a point cloud. This subset may characterize the type of the point cloud. For example, when coding AR or VR dense point clouds, most of the visited occupancy configurations may exhibit occupied adjacent cuboids of a current child cuboid. On the other hand, when coding sensor-acquired sparse point clouds, most of the visited occupancy configurations may exhibit only a few occupied adjacent cuboids of a current child cuboid. The role of the dynamic reduction may be to obtain a more precise correlation based on the most visited occupancy configuration while putting aside (or reducing aggressively) other occupancy configurations that are much less visited. The dynamic reduction may be updated on-the-fly, as detailed below, after each visit of an occupancy configuration during the coding of occupancy data.

[0085] FIG. 5 illustrates an example of a dynamic reduction function DR that may be used in dynamic OBUF. The dynamic reduction function DR may be obtained by masking bits PJ of occupancy configurations 500:

[0086] P = Pi ... PK made of K bits. The size of the mask may decrease when occupancy configurations are visited a certain number of times. The initial dynamic reduction function DR0may mask all bits for all occupancy configurations such that it is a constant function DR°(P) = 0 for all occupancy configurations p. After each coding of an occupancy bit, the dynamic reduction function may evolve from a function DRnto an updated function DRn+1. The function may be defined by:

[0087] P’ = DRn( ) = l ... Pkn® where kn(P) 510 is the number of non-masked bits. The initialization of DR0may correspond to ko(P)=O, and the natural evolution of the reduction function towards finer statistics may lead to an increasing number of non-masked bits kn(P) < kn+i(P). The dynamic reduction function may be entirely determined by the values of knfor all occupancy configurations p.

[0088] The visits to occupancy configurations may be tracked by a variable NV(P’) for all dynamically reduced occupancy configurations P’= DRn(P). After the coding of an occupancy bit based on an occupancy configuration pv, the corresponding number of visits NV(Pv’) may be increased by one. If this number of visits NV(Pv’) is greater than a threshold thv,

[0089] NV(pv’) > thvthen the number of unmasked bits kn(P) may be increased by one for all occupancy configurations P being dynamically reduced to pv’. Practically, this corresponds to replacing the dynamically reduced occupancy configuration pv’ by the two new dynamically reduced occupancy configurations P°’ and p1’ defined by p0’ = PV’O = pvi ... P ^O and P1’ = Pv’ l = pvi ... PVP)1.

[0090] In other words, the number of unmasked bits has been increased by one kn+i (P) = kn(P) + 1 for all occupancy configurations P such that DRn(P) = pv’. The number of visits of the two new dynamically reduced occupancy configurations may then be initialized to zero:

[0091] NV(p°’) = NV(p1’) = o. (i)

[0092] At the start of the coding, the initial number of visits for the initial dynamic reduction function DR0may be set to

[0093] NV(DR°(p)) = NV(0) = 0, and the evolution of NV on dynamically reduced occupancy configurations may now be entirely defined.

[0094] When a dynamically reduced occupancy configuration pv’ is replaced by the two new dynamically reduced occupancy configurations P°’ and p1’, the corresponding LUT entry LUT[pv’] may be replaced by the two new entries LUT[P°’] and LUTfP1’] that are initialized by the context index associated with pv’,

[0095] LUT[p0’] = LUT[p”] = LUT[pv’], (II) and then evolve separately. The evolution of the LUT of context indices on dynamically reduced occupancy configurations may thus be entirely defined.

[0096] The reduction function DRnmay be modeled by a series of growing binary trees Tn520 whose leaf nodes 530 are the reduced occupancy configurations P’ = DRn(P). The initial tree may be the single root node associated with 0 = DR°(P). The replacement of the dynamically reduced to pv’ by p0’ and p1’ corresponds to growing the tree Tnfrom the leaf node associated with pv’ by attaching to it two new nodes associated with p0’ and p1’. The free Tn+1may be obtained by this growth. The number of visits NV and the LUT of context indices may be defined on the leaf nodes and evolve with the growth of the tree through equations (I) and (II).

[0097] In some examples, dynamic OBUF may be practically implemented by storage of the array NV[P’] and the LUT[P’] of context indices, as well as the frees Tn520. An alternative to the storage of the trees may be to store the array kn[P] 510 of the number of non-masked bits.

[0098] A limitation for implementing dynamic OBUF may be its memory footprint. In some applications, a few million occupancy configurations may be practically handled, leading to about 20 bits Pi constituting an entry configuration P to the reduction function DR. Each bit Pi may correspond to the occupancy status of a neighboring cuboid of a current child cuboid or a set of neighboring cuboids of a current child cuboid.

[0099] Higher bits Pi (e.g., Po, Pi, etc.) may be the first bits to be unmasked during the evolution of the dynamic reduction function DR. Therefore, the order of neighbor-based information put in the bits Pi may impact the compression performance. In some examples, neighboring information may be ordered from highest priority to lower priority and put in this order into the bits p from higher to lower weight. For example, the priority may be, from the most important to the least important, occupancy of sets of adjacent neighboring child cuboids, then occupancy of adjacent neighboring child cuboids, then occupancy of adjacent neighboring parent cuboids, then occupancy of non-adjacent neighboring child nodes, and finally occupancy of non-adjacent neighboring parent nodes. Adjacent nodes sharing a face with the current child node may also have higher priority than adjacent nodes sharing an edge or, worse, only a vertex with the current child node.

[0100] FIG. 6 illustrates a flowchart of an exemplary method for coding the occupancy bit of a current child cuboid using dynamic OBUF. The method of the flowchart begins at block 602. At block 602, an encoder and / or decoder may determine the occupancy configuration p of already-coded cuboids in a neighborhood of the current child cuboid. At block 604, the encoder and / or decoder may dynamically reduce the occupancy configuration P into a reduced occupancy configuration P’ = DRn(P). At block 606, the encoder and / or decoder may lookup context index LUT[P’] in the LUT of the dynamic OBUF. At block 608, the encoder and / or decoder may select the context (or probability model) pointed to by the context index. At block 610, the encoder and / or decoder may entropy code (e.g., arithmetic code) the occupancy bit of the current child cuboid based on the context. Thus, the occupancy bit of the current child cuboid may be coded based on occupancy bits of the already-coded cuboids neighboring the current child cuboid .

[0101] Although not shown in FIG. 6, the encoder and / or decoder may further update the reduction function DRninto DRn+1and update the context index LUT[P’] based on the occupancy bit of the current child cuboid. In addition, the method of FIG. 6 may be repeated for additional or all child cuboids of parent cuboids corresponding to nodes of the occupancy tree in a scan order, such as the scan order discussed above with respect to FIG. 3.

[0102] In general, the occupancy tree is a lossless compression technique. The occupancy tree may be adapted to provide lossy compression by modifying the point cloud on the encoder side (e.g., downsampling, removing points, moving points, etc.) but the lossy compression performance may be reduced / weak. However, the use of the occupancy tree as a lossless compression technique may be very useful for dense point clouds.

[0103] One approach to lossy compression for point cloud geometry may be to set the maximum depth of the occupancy tree to not reach the smallest volume size of one voxel but instead to stop at a bigger volume size (e.g., NxNxN cubes, where N > 1). The geometry of the points belonging to each occupied leaf node associated with the bigger volumes may then be modeled. This approach may be particularly suited for dense and smooth point clouds that may be locally modeled by smooth functions like planes or polynomials. The coding cost may become the cost of the occupancy tree plus the cost of the local model in each of the occupied leaf nodes.

[0104] A scheme for modeling the geometry of the points belonging to each occupied leaf node, associated with a volume size larger than one voxel, may use sets of triangles as local models. This scheme may be referred to as the “TriSoup” scheme. TriSoup is short for “Triangle Soup” because the connectivity between triangles may not be part of the models. An occupied leaf node, of an occupancy tree, that corresponds to a cuboid with a volume greater than one voxel may be referred to as a TriSoup node. An edge belonging to at least one cuboid corresponding to a TriSoup node may be referred to as a TriSoup edge. A TriSoup node may comprise a presence flag (sk) for each TriSoup edge of its corresponding occupied cuboid. A presence flag (sk) of a TriSoup edge may indicate (a presence of or) whether a TriSoup vertex (Vk) is present or not on the TriSoup edge. At most one TriSoup vertex (Vk) may be present on a TriSoup edge. For each vertex (Vk) present on a TriSoup edge of an occupied cuboid, the TriSoup node corresponding to the occupied cuboid may further comprise a position (pk) of the vertex (Vk) along the TriSoup edge.

[0105] In addition to the occupancy words of an occupancy tree, an encoder may entropy encode, for each TriSoup node of the occupancy tree, a TriSoup vertex presence flag (and a position of a TriSoup vertex, if present, along a TriSoup edge) of each TriSoup edge belonging to the TriSoup node. A decoder may similarly entropy decode the TriSoup vertex presence flags and positions of each TriSoup vertex along a respective TriSoup edge belonging to a TriSoup node of the occupancy tree, in addition to the occupancy words of the occupancy tree. FIG. 7 illustrates an example of an occupied cube 700 of size NxNxN (where N > 1) that corresponds to a TriSoup node of an occupancy tree. Occupied cube 700 comprises TriSoup edges 710- 721. The TriSoup node, corresponding to occupied cube 700, comprises a presence flag (sk) for each TriSoup edge of TriSoup edges 710-721. The presence flag of TriSoup edge 714 indicates that a TriSoup vertex Vi is present on TriSoup edge 714. The presence flag of TriSoup edge 715 indicates that a TriSoup vertex V2 is present on TriSoup edge 715. The presence flag of TriSoup edge 716 indicates that a TriSoup vertex V3 is present on TriSoup edge 716. The presence flag of TriSoup edge 717 indicates that a TriSoup vertex V4 is present on TriSoup edge 718. The presence flags of the remaining TriSoup edges each indicates that a TriSoup vertex is not present on their corresponding TriSoup edge. The TriSoup node, corresponding to occupied cube 700, further comprises a position (pk) for each TriSoup Vertex present along one of its TriSoup edges 710-721. More specifically, the TriSoup node (corresponding to occupied cube 700) further comprises a position pi for TriSoup vertex Vi, a position p2 for TriSoup vertex V2, a position ps for TriSoup vertex V3, and a position p4 for TriSoup vertex V4. The TriSoup vertices may be shared among TriSoup nodes along TriSoup edge(s) in common.

[0106] In some examples, a presence flag (sk) and, if the presence flag (sk) indicates the presence of a vertex, a position (pk) (the presence flag (sk) and position (pk) individually or collectively referred to as vertex information) of the vertex along a current TriSoup edge may be entropy coded based on already- coded presence flags and positions (of present TriSoup vertices) of TriSoup edges that neighbor the current TriSoup edge. A presence flag (sk) and, if the presence flag (sk) indicates the presence of a vertex, a position (pk) on (e.g., indicating a position of the vertex along) a current TriSoup edge may be additionally or alternatively entropy coded based on occupancies of cuboids that neighbor the current TriSoup edge. Similar to the entropy coding of the occupancy bits of the occupancy tree, a configuration PTS for a neighborhood (also referred to as a neighborhood configuration TS) of a current TriSoup edge may be obtained and dynamically reduced into a reduced configuration PTS’ = DRn(PTS) by using a dynamic OBUF scheme for TriSoup. A context index LUTfPTS’] may be obtained from the OBUF LUT and at least a part of the vertex information of the current TriSoup edge may be entropy coded using the context (or probability model) pointed to by the context index.

[0107] In order to use a binary entropy coder to entropy code at least part of the vertex information of the current TriSoup edge, the TriSoup vertex position (pk) (if present) along its TriSoup edge may be binarized. A number of bits Nb may be set for the quantization of the TriSoup vertex position (pk) along the TriSoup edge of length N that is uniformly divided into 2Nbquantization intervals. By doing so, the TriSoup vertex position (pk) may be represented by Nb bits (pkj, j=l,...,Nb) that may be individually coded by the dynamic OBUF scheme as well as the bit corresponding to the presence flag (sk). The neighborhood configuration PTS, the OBUF reduction function DRn, and thus the context index may depend on the nature / characteristic / property of the coded bit (presence flag (sk), highest position bit (pki), second highest position bit (pk2), etc.). Therefore, there may be several dynamic OBUF schemes implemented, with each dedicated to a specific bit of information (presence flag (sk) or position bit (pkJ)) of the vertex information.

[0108] FIG.8A illustrates a cuboid 800 (e.g., a cube) corresponding to a TriSoup node with a number K of TriSoup vertices Vk. Within cuboid 800, TriSoup triangles may be constructed from the TriSoup vertices Vk if at least three (K>3) TriSoup vertices are present on the TriSoup edges of cuboid 800. In the example of FIG. 8A, 4 TriSoup vertices are present and therefore TriSoup triangles are constructed. The TriSoup triangles may be constructed around the centroid vertex C defined as the mean of the TriSoup vertices Vk. In some examples, to construct the TriSoup triangles, a dominant direction may first be determined, then vertices Vk may be ordered by turning around this direction, and finally the following K TriSoup triangles (listed as triples of vertices) are constructed: V1V2C, V2V3C, ..., VKVIC. The dominant direction may be chosen among the three directions parallel to the axis of the 3D space to increase or maximize the 2D surface of the triangles when projected along the dominant direction. By doing so, the dominant direction may be somewhat perpendicular to a local surface defined by the points of the point cloud belonging to the TriSoup node.

[0109] FIG. 8B illustrates a refinement to the TriSoup model by coding a centroid residual vector Cres into the bitstream such as to use C+Cres instead of C as a pivoting vertex for constructing / generating the triangles. By doing so, the vertex C+Cres may be closer to the points of the point cloud than the centroid C used to model the points, which reduces the reconstruction error and leads to lower distortion at the cost of a small increase in bitrate needed for coding Cres.

[0110] FIG. 8C illustrates a more detailed example of coding a centroid residual vector Cres in / from the bitstream such that an adjusted centroid C+Cres is used instead of centroid C for generating TriSoup triangles of a cuboid 800 (corresponding to a TriSoup node) corresponding to a portion of a point cloud, according to some embodiments. For example, the triangles may be generated based on adjusted centroid C+Cres and adjacent pairs of vertices of an ordering of the vertices V1-V4, determined as described above with respect to FIG. 8A. Further, as described above, the TriSoup triangles of the cuboid may be voxelized at the decoder to generate voxels representing (or modeling) the portion, of the point cloud, corresponding to the cuboid. A unit vector n (i.e., also referred to as a normalized vector) may be determined as a normalized mean vector of normal vectors to the triangles (V1V2C, V2V3C, ... , VKVIC) constructed by centroid C and pairs of the vertices of the cuboid by pivoting around the centroid C (e.g., as described in FIG. 8A). For example, the unit vector n may be determined as the normalized vector based on a mean of cross-products representing areas of the triangles (V-jC x V2C + V2C x V3C + — I- VKC x V^ C / K. For example, the unit vector n may be determined by dividing the mean vector (n) by the norm (or length) of the mean vector (i.e., n = n / ||n||). A value resulting from each cross product is equal to an area of a parallelogram formed by the two vectors in the cross product. Therefore, the value may be representative of an area of a triangle formed by the two vectors because the area of the triangle is equal to half of the value. Accordingly, since the vector n indicates a direction of the triangles (e.g., TriSoup triangles) representing (e.g., modeling) the portion of the point cloud, the vector n may be indicative of the direction normal to a local surface representative of the portion of the point cloud. In some examples, to maximize the effect of the centroid residual while minimizing its coding cost, a one-component residual aresalong the line (C, n) 810 may be coded instead of a 3D residual vector.

[0111] The residual value aresmay be determined by the encoder as the intersection between the current point cloud and the line (C, n), which is along the same direction of the normalized vector n. For example, a set of points, of the portion of the point cloud, closest (e.g., within a threshold distance, a threshold number of points) to the line may be determined. The set of points may be projected on the line and the residual value ares may be determined as the mean component along the line of the projected points. In some examples, the mean may be determined as a weighted mean whose weights depend on the distance of the set of points from the line. For example, a point from the set closer to the line may have a higher weight than another point from the set farther from the line.

[0112] In some examples, the residual value areSmay be quantized. For example, it may be quantized by a uniform quantization function having quantization step similar to the quantization precision of the TriSoup vertices Vk. By doing so, the quantization error may be maintained to be uniform over all vertices Vk and C+Cres such that the local surface is uniformly approximated.

[0113] In some examples, the residual value ares may be binarized and entropy coded into the bitstream, e.g., by using a unary -based coding scheme. In some examples, the residual value aresmay be coded using a set of flags. For example, a flag fo may be coded to indicate if the residual value aresis equal to zero. If the flag fo indicates the residual value aresis zero, no further syntax elements may be needed. If the flag fo indicates the residual value aresis not zero, a sign bit indicating a sign may be coded and the residual magnitude |ares|- 1 may be coded using an entropy code. For example, the residual magnitude may be coded using a unary coding scheme that codes successive flags f (i> 1 ) indicating if the residual value magnitude |ares | is equal to ‘i’. A binary entropy coder may binarize the residual value aresinto the flags f (i>0) and entropy code the binarized residual value as well as the sign bit.

[0114] In some examples, compression of the residual value aresmay be improved by determining bounds as shown in FIG. 8C. As shown, the line (C, n) 810 intersects the current cuboid 800 (corresponding to a TriSoup node) at two bounding points 820 and 821 and the encoder may impose that the adjusted centroid vertex C+Cres is located between the two bounding points 820 and 821. These bounding points 820 and 821 also bound the residual value ares(which may be quantized) as belonging to an integral interval [m, M] where m < 0 < M. By doing so, some bits of the binarized residual value aresmay be inferred. For example, if m=M=0, then residual value ares is necessarily equal to zero. In another example, if m=0<M, then the sign bit is necessarily positive. More generally, if the residual value aresis not equal to zero and its sign is known, its magnitude |res| may be determined to be bounded by either |m| or M such that the magnitude may be coded by a truncated unary coding scheme that may infer the value of the last of successive flags f (i>l).

[0115] In some examples, the binary entropy coder used to code the binarized residual value aresmay be a context-adaptive binary arithmetic coder (CABAC) such that the probability model (also referred to as a context or an entropy coder) used to code at least one bit (e.g., f or sign bit) of the binarized residual value ares are updated depending on precedingly coded bits. In some examples, the probability model of the binary entropy coder may be determined based on contextual information such as the values of the bounds m and M, the position of vertices Vk, or the size of the cuboid. In some examples, the selection of the probability model (i.e., also referred equivalently as an entropy coder or context) may be performed by a dynamic OBUF scheme with the contextual information described above as inputs.

[0116] The reconstruction of a decoded point cloud from the set of TriSoup triangles may be referred to as “voxelization” and may be performed, e.g., by ray tracing or rasterization, for each triangle individually before duplicate voxels from the voxelized triangles are removed.

[0117] FIG. 9A illustrates an example of voxelization using ray tracing, according to some embodiments. For example, ray-triangle intersection algorithms, such as the Moller-Trumbore algorithm, rely on launching rays to determine whether rays intersect with TriSoup triangles and if so, at what points of the TriSoup triangles. Rays may be launched from integral coordinates that correspond to the centers of voxels. As illustrated by FIG. 9A, rays such as ray 900 may be launched parallel to one of the three coordinate axes of the 3D space, starting from integral coordinates (sometimes referred to as integer coordinates) such as an origin point 905 (shown as origin or starting point Pstan).

[0118] An intersection point 904 (shown as Pint), if any, between ray 900 and a TriSoup triangle 901 belonging to a cube 902, corresponding to a TriSoup node, may be rounded (e.g., quantized) to obtain a decoded point corresponding to a voxel. For example, a ray, launched parallel to a coordinate axis in 3D space, may intersect a TriSoup triangle if and only if the projection, along the ray direction, of the center of a voxel belongs to the TriSoup triangle. In other words, the ray may be determined to intersect the TriSoup triangle if the point of intersection corresponds to the center of the voxel. In some examples, this intersection may be determined by applying a ray -triangle intersection algorithm (e.g., tracing or ray casting technique) such as the Moller-Trumbore algorithm to generate voxels representing the triangle. Ray tracing techniques such as the Moller-Trumbore algorithm is based on generating, with respect to a triangle, barycentric coordinates of points of intersection between rays and a plane of the triangle. Then, points of the triangle may be determined from the barycentric coordinates.

[0119] FIG. 9B illustrates an example of voxelization using barycentric coordinates (u, v, w) of a point 912 (P) relative to a TriSoup triangle 910 having vertices labeled A, B, and C in the 3D space, according to some embodiments. In some examples, point 912 may be determined as an intersection between a ray and a plane of TriSoup triangle 910 (e.g., containing or passing through the three vertices A, B, and C of TriSoup triangle 910). For example, the ray may be launched parallel to one of the three coordinate axes in 3D space. In some examples, this intersection point 912 may be uniquely represented as a sum of the three vertices of TriSoup triangle 910:

[0120] P= nA + vB + wC under the condition u + v + w = 1. Therefore, any point P of the plane (containing TriSoup triangle 910) has unique coordinates (u,v,w) in the barycentric coordinate system. A point with barycentric coordinates (u,v,w) includes an ordered triple of numbers u, v, and w. A point with barycentric coordinates (u,v,w) that sum to 1 (i.e., u + v + w = 1) is known as homogeneous barycentric coordinates or normalized barycentric coordinates. The barycentric coordinates of the intersection point with respect to TriSoup triangle 910 may be determined using, e.g., the well-known Moller-Trumbore algorithm.

[0121] By converting points with Cartesian coordinates in 3D space to homogeneous barycentric coordinates, the three vertices A, B, C of TriSoup triangle 910 have respective barycentric coordinates A(l,0,0), B(0,l,0) and C(0,0,l). In some examples, the convex hull (i.e., TriSoup triangle 910) of the three vertices A, B, and C is equal to the set of all points such that the barycentric coordinates u, v, and w is each greater than or equal to zero:

[0122] 0 < u, v, w

[0123] Therefore, in some examples, the intersection point may be determined to belong to TriSoup triangle 910 based on the intersection point having barycentric coordinates with an ordered triple of values that is each greater than or equal to zero. Relatedly, if at least one of barycentric coordinates (i.e., one of u, v, or w) is negative or less than 0, then the intersection point may be determined to not belong to TriSoup triangle because it will be on the plane, but not on an edge or within the TriSoup triangle. In some examples, a point determined to belong to TriSoup triangle 910 may be the ray intersecting TriSoup triangle 910 (e.g., within or at an edge of TriSoup triangle 910).

[0124] Attribute coding is a process to code attributes of a current point cloud, e.g., attributes associated with the geometry of the current point cloud. Attributes coding may be performed globally on the decoded (e.g., reconstructed) geometry of a current point cloud but such global coding induces high memory traffic and footprint as well as high computation complexity. A two-pass encoding / decoding on the geometry and then on the attributes, after completion of geometry encoding / decoding, is required and induces even higher memory traffic and footprint as well as overall latency before outputting geometry and attributes of a first point of the decoded point cloud.

[0125] Attribute Coding Units (ACU) has been introduced to enable local coding of attributes. ACU may be determined by segmenting an overall decoded geometry (1013) of a current point cloud (1011) into a set of ACUs. Each ACU comprises (e.g., contains) a portion of geometry of the decoded geometry (1013), which indicates 3D positions in the 3D space of a subset of points of the decoded geometry (e.g., as decoded by the decoder or encoded and then decoded by the encoder). As used herein, points of the decoded geometry may refer to voxels, as described above.

[0126] The attributes encoding / decoding is then localized to portions of the overall decoded geometry (1013) and the attribute coding of each ACU (associated with each portion of geometry of the current point) may be processed locally. Memory traffic and footprint as well as computation complexity are then reduced compared to global attribute coding.

[0127] For example, the geometry of the current point cloud may be restricted to a subset of nodes of the occupancy tree and the restricted geometry and the associated attributes may be encoded / decoded locally by segmenting the restricted geometry into ACUs.

[0128] For example, the 3D space encompassing a point cloud may be split into regions defined by subsets of nodes of the occupancy tree. The geometry of a first region of the 3D space may be encoded to obtain a first part of the decoded geometry of the current pint cloud that is segmented into a first set of ACUs that are attribute encoded. Then, the geometry of a second region of the 3D space may be encoded to obtain a second part of the decoded geometry of the current point cloud that is segmented into a second set of ACUs that are attribute encoded, etc. The memory footprint and traffic are thus limited within a few regions, due to some neighborhood prediction between regions, and the latency of the point cloud codec is reduced to the time needed for encoding geometry and attributes of a few regions. Smaller regions will lead to smaller memory footprint and traffic, and to shorter latency.

[0129] FIG. 10 illustrates an example process 1000 for encoding geometry and attributes of a current point cloud (1011).

[0130] For example, process 1000 may be performed by an encoder (e.g., encoder 114 of FIG. 1). In some examples, blocks 1010-1030 may represent components within the encoder.

[0131] The current point cloud (1011) may be a point cloud frame of a sequence of point cloud frames of a dynamic point cloud.

[0132] At block 1010, an encoder may encode into a bitstream (1090) a geometry information (1012) representative of the geometry of the current point cloud (1011). The encoder may obtain a decoded (e.g., reconstructed) geometry (1013) of the point cloud (1011) as discussed above. At block 1020, the encoder may determine at least one portion of geometry (1022) of the decoded geometry (1013). Each portion of geometry (1022) comprises a subset of points of the decoded geometry (1013), e.g., comprising positions in the 3D space of the subset of points.

[0133] In some examples, the decoded geometry (1013) may be segmented into a set of ACUs, and each ACU of the set of ACUs comprises a respective portion of geometry (1022) of the decoded geometry (1013),

[0134] For example, the encoder may further encode, in the bitstream (1090), portion information (1021), for example, as part of the attribute information (1032).

[0135] For example, the portion information (1021) may indicate segmentation selections of the decoded geometry (1013) into the set of ACUs, e.g., the portion information (1021) indicates how the decoded geometry (1013) is segmented into the set of ACUs.

[0136] Attributes of the current point cloud (1011), e.g., attributes associated with the points of the current point cloud, are typically coded after the coding (e.g., including encoding and / or decoding) of the underlying geometry has been performed. If the geometry coding is a lossless coding (e.g., by using an octree scheme), the encoder has direct access to the attribute values associated with the decoded geometry. The attributes associated with each point of the current point cloud are the attributes associated with the corresponding point of the decoded geometry (1013).

[0137] In some examples, if the geometry coding is a lossy coding (e.g., by using a TriSoup scheme), the decoded geometry (1013) differs from the geometry of the current point cloud. In these examples, the attributes (10111) of the current point cloud may be mapped by the encoder from the geometry of the current point cloud (1011) to the decoded geometry (1013) such as to determine mapped attributes (1031) associated with the decoded geometry (1013). For example, the mapped attributes are assigned to each point of the decoded geometry (1013).

[0138] At block 1025, the encoder may determine mapped attributes (1031) of the decoded geometry (1013) by mapping the attributes (10111) of the current point cloud (1011) to the decoded geometry (1013).

[0139] As discussed above, attributes may indicate a property of a point’s visual appearance such as texture, color, material, transparency, reflectance, time stamp, velocity, etc. For attributes that are colors, this attribute mapping performed by the encoder is known as a recoloring process because the colors of the original geometry are used to color (e.g., recolor) the decoded geometry.

[0140] In some examples, attributes comprise colors and the mapped attributes may be determined based on recoloring the attributes.

[0141] In some examples, mapped attributes may be determined based on a k nearest neighbor (KNN) search algorithm (e.g., using a space partitioning algorithm such as a KD Tree search, a Ball / metric Tree search, brute force search, etc.) to determine nearest points from the geometry of the current point cloud (1011) to the decoded geometry (1013). For example, a mapped attribute of a point of the decoded geometry (1013) may be the average attribute values associated with the nearest points of the current point cloud (1011) relative to the point of the decoded geometry (1013).

[0142] In some examples, when the geometry compression is lossless, the decoded geometry (1013) is the same as the geometry of the current point cloud (1011). In these examples, the attribute mapping associates attributes of each point of the current point cloud (1011) to the same point of the decoded geometry (1013).

[0143] At block 1030, the encoder may encode, in the bitstream (1090), the mapped attributes (1031) associated with each portion of geometry (1022). For example, the attributes of points associated with a portion of geometry (1022) may be encoded before encoding the attributes of points belonging to another portion of the decoded geometry (1013). Thus, attribute encoding may be performed locally. The encoder may encode attribute information (1032) representing the encoded attributes.

[0144] For example, attributes associated with portions of the decoded geometry (1013) are encoded based on a scanning order. The encoder may thus distinguish between already coded / decoded portions of the decoded geometry (1013), i.e., portions of the decoded geometry (1013) whose attributes have been encoded / decoded, from other portions of the decoded geometry (1013) whose attributes have not been encoded / decoded yet.

[0145] FIG. 11 illustrates an example process 1100 for encoding attributes associated with a portion of geometry (1022) of the decoded geometry (1013).

[0146] For example, process 1100 may be performed by an encoder (e.g., encoder 114 of FIG. 1). In some examples, blocks 1110-1130 may represent components within the encoder.

[0147] The process 1100 comprises operations of block 1030 that encodes, in a bitstream 1190, mapped attributes (1031) associated with the portion of geometry (1022) as attribute information (1032).

[0148] At block 1110, an encoder selects an attribute coding mode (1112) for encoding the attributes of the portion of geometry (1022). The encoder may further encode, in the bitstream (1190), mode information (1042) that indicates the selected attribute coding mode (1112).

[0149] For example, the attribute information (1032) encoded in bitstream 1190 may comprise the mode information (1042).

[0150] For example, the encoder may select an attribute coding mode from a list of intra and inter coding modes based on applying an Rate-Distortion Optimization (RDO).

[0151] For example, the mode information (1042) may indicate either an intra-prediction attribute mode (intra mode) or an inter-prediction attribute mode (inter mode). At block 1120, the encoder determine attribute predictors (1124) of attributes associated with the portion of geometry (1022). For example, for each point of the portion of geometry (1022), one respective attribute predictor is determined for predicting the attribute associated with that point.

[0152] When an inter coding mode is selected, the encoder may obtain, at block 1120, attribute predictors (1124) from an inter-prediction attribute parametric model based on Motion Vector (MV) Field (1121), reference point cloud for attributes (1122) and the portion of geometry (1022). Parameters of the interprediction attribute parametric model may be set by the selected attribute coding mode (1112).

[0153] When the intra coding mode is selected, the encoder may determine, at block 1120, attribute predictors (1124) from an intra-prediction attribute parametric model based on at least one already -coded portions (1123) of the decoded geometry (1013). Parameters of the intra-prediction attribute parametric model may be set by the selected attribute coding mode (1112).

[0154] At block 1130, the encoder encodes, in the bitstream (1190), the mapped attributes (1031) associated with the portion of geometry (1022) based on the attributes predictors (1124) as attribute information (1032).

[0155] FIG. 12 illustrates an example process 1200 for decoding geometry and attributes of a current point cloud.

[0156] For example, process 1200 may be performed by a decoder (e.g., decoder 120 of FIG. 1). In some examples, blocks 1210-1230 may represent components within the decoder.

[0157] The decoded point cloud may be a point cloud frame of a sequence of point cloud frames of a dynamic point cloud. The decoded point cloud may comprise decoded geometry (1212) and decoded attributes (1233), each decoded attribute (1233) being associated with one point of the decoded geometry (1212).

[0158] At block 1210, a decoder may obtain a decoded geometry (1212) by decoding geometry information (1211) from a bitstream (1290) as discussed above. For example, the bitstream (1290) is generated by the encoding method of FIG. 10.

[0159] At block 1220, the decoder may determine at least one portion of the decoded geometry (1212).

[0160] For example, the decoded geometry (1212) may be segmented into a set of ACUs and each ACU of the set of ACUs comprises a respective portion of geometry (1222) of the decoded geometry (1212), e.g., comprising positions in the 3D space of a subset of points of the decoded geometry (1212).

[0161] For example, the decoder may further decode, from the bitstream (1290), portion information (1221), for example from part of the attribute information (1232).

[0162] For example, the portion information (1221) may indicate segmentation selections of the decoded geometry (1212) into the set of ACUs, e.g., the portion information (1221) indicates how the decoded geometry (1212) is segmented into the set of ACUs. At block 1230, the decoder may obtain decoded attributes (1233) associated with each portion of geometry (1212) by decoding attribute information (1232). For example, the attributes of points associated with a portion of geometry (1222) may be decoded before decoding the attributes of points belonging to another portion of the decoded geometry (1212).

[0163] For example, attributes associated with portions of the decoded geometry (1212) are decoded according to a scanning order. The decoder may thus distinguish between already decoded portions of the decoded geometry (1212), e.g., portions of the decoder geometry (1212) whose attributes have been decoded, from other portions of the decoded geometry (1212) whose attributes have not been yet decoded.

[0164] FIG. 13 illustrates an example process 1300 for decoding attributes associated with a portion of geometry (1222) of the decoded geometry (1212).

[0165] For example, process 1300 may be performed by a decoder (e.g., decoder 120 of FIG. 1). In some examples, blocks 1310-1330 may represent components within the decoder.

[0166] The process 1300 comprises operations of block 1230 that obtains decoded attributes (1233) associated with portion of geometry (1222) by decoding attribute information (1232) from the bitstream 1290.

[0167] At block 1310, a decoder selects an attribute coding mode ( 1311) for decoding the attributes of the portion of geometry (1222). The decoder may further decode, from the bitstream (1290), mode information (1231) that indicates the selected attribute coding mode (1311).

[0168] For example, the mode information (1231) may indicate either intra-prediction attribute mode or inter-prediction attribute mode.

[0169] At block 1320, the decoder determines attribute predictors (1324) of attributes associated with the portion of geometry (1222). For example, for each point of the portion of geometry (1222), one respective attribute predictor is determined for predicting the attribute associated with that point.

[0170] When an inter coding mode is selected, the decoder may obtain, at block 1320, attribute predictors (1324) from an inter-prediction attribute parametric model based on Motion Vector (MV) Field (1321), reference point cloud for attributes (1322) and the portion of geometry (1222). Parameters of the interprediction attribute parametric model may be set by the selected attribute coding mode (1311).

[0171] For example, FIGS. 28A and 28B described below shows two examples of the inter-prediction attribute parametric model that may be applied to project attributes of the reference point cloud for attributes (1322) onto the portion of geometry (1222) to determine attribute predictors (1324) for attributes of points / vertices of the portion of geometry (1222).

[0172] When the intra coding mode is selected, the decoder may determine, at block 1320, attribute predictors (1324) from an intra-prediction attribute parametric model based on at least one already -coded portions (1323) of the decoded geometry (1222). Parameters of the intra-prediction attribute parametric model may be set by the selected attribute coding mode (1311).

[0173] At block 1330, the decoder decodes attribute information (1232) from the bitstream (1290) and obtains the decoded attributes (1233) associated with the portion of geometry (1222) based on the decoded attribute information and the attributes predictors (1324).

[0174] FIG. 14 illustrates an example process 1400 for determining attribute predictors (1431) of attributes associated with a portion of geometry (1421).

[0175] For example, process 1400 may be performed by an encoder (e.g., encoder 114 of FIG. 1) or a decoder (e.g., decoder 120 of FIG. 1). In some examples, blocks 1410-1430 may represent components within the encoder or the decoder.

[0176] The process 1400 is performed identically at both the encoder and the decoder to determine same attribute predictors (1431). The operations of FIG. 14 may be performed separately by the encoder and the decoder.

[0177] Blocks 1410-1420 relate to a process for determining inter-prediction based attribute predictors and block 1430 relates to a process for determining intra-prediction based attribute predictors.

[0178] In some examples, the process for determining inter-prediction based attribute predictors corresponds to block 1120 of FIG. 11 when the selected attribute coding mode (1112) indicates an interprediction attribute mode (inter mode) and to block 1320 of FIG. 13 when the selected attribute coding mode (1112) indicates an inter-prediction attribute mode (inter mode). The process for determining intraprediction based attribute predictors corresponds to block 1120 of FIG. 11 when the selected attribute coding mode (1112) indicates an intra -prediction attribute mode (intra mode) and to block 1320 of FIG. 13 when the selected attribute coding mode (1112) indicates an intra -prediction attribute mode (intra mode).

[0179] For example, the portion of geometry (1421) may be a portion of geometry (1022) such as a portion of the decoded geometry (1013) of FIG. 10 and the attribute predictors (1431) are attribute predictors (1124) of FIG. 11. For example, the portion of geometry (1421) may be the portion (1222) of the decoded geometry (1212) of FIG. 12 and the attribute predictors (1431) are the attribute predictors (1324) of FIG. 13. Reference point cloud for attributes (1411) may correspond to the reference point cloud for attributes (1122) of FIG. 11 and the reference point cloud for attributes (1322) of FIG. 13.

[0180] Blocks 1410-1420 show operations of the process for determining inter-prediction based attribute predictors. The process obtains projected attributes (1422) of the decoded geometry (1013, 1212). Specifically, part of projected attributes (1422) are used as attribute predictors (1431) for attributes associated with points of portion of geometry (1421). As further explained below, in some examples, the process for determining inter-prediction based attribute predictors performs motion compensation of the geometry of the reference point cloud for attributes (1411) to generate a motion compensated geometry (1413).

[0181] In these implementations, reference point cloud for attributes (1411) may correspond to reference point cloud for attributes (1122) of FIG. 11 and reference point cloud for attributes (1322) of FIG. 13.

[0182] At block 1410, the encoder or decoder obtains the motion compensated geometry (1413) by performing motion compensation of the geometry of the reference point cloud for attributes (1411) based on MV field (1412) that corresponds to MV field (1121) of FIG. 11 and MV field (1321) of FIG. 13.

[0183] The encoder may obtain the MV field (1121) by performing a motion search such as that MV field (1121) approximates the 3D motion field of attributes from the reference point cloud for attributes (1411) to the attributes of the current point cloud (1011). The motion search is typically an iterative method that tests locally multiple candidate motion vectors, and selects the candidate motion vector, among the candidate motion vectors, that minimizes a distortion (e.g., cost) between the attributes of the current point cloud (1011) and attributes of the motion compensated geometry (1413) using the candidate motion vector.

[0184] In some embodiments, the distortion, used by the motion search, for a point of the current point cloud (1011) may be determined by comparing the attribute of this point and the attribute of (one of) its closest neighbor in the motion compensated geometry.

[0185] The encoder may encode an information that indicates the reference point cloud for attributes (1411) among multiple candidate reference point cloud for attributes. The encoder may further encode the MV field (1121) as geometry information (1012). The decoder may obtain the reference point cloud for attributes (1411) and MV field (1321) by decoding geometry information (1211) and attribute information (1232) from the bitstream (1290).

[0186] At block 1420, the encoder / decoder determines projected attributes (1422) associated with the decoded geometry (1013, 1212) based on attributes of the reference point cloud for attributes (1411).

[0187] Projected attributes (1422) and attributes of the decoded geometry (1013, 1212) belong to the same geometry and the prediction of the attributes portion of geometry (1022, 1222) based on the projected attributes is much more efficient because the geometry discrepancy has been removed.

[0188] In some examples, the encoder / decoder may generate (e.g., build or configure) an attributes projection model that may be generated from a motion compensated geometry (1413). The attribute projection model may be used to perform attribute projection associated with the motion compensated geometry (1413). For example the motion compensated geometry (1413) is obtained by performing motion compensation of the geometry of the reference point cloud for attributes (1411) and the attribute projection determines a projection of the motion compensated geometry (1413) onto the decoded geometry (1421). For example, the motion compensated geometry (1413) is obtained by performing motion compensation of the decoded geometry (1421) and the attribute projection determines a projection of the motion compensated geometry (1413) onto the geometry of the reference point cloud for attributes (Mi l).

[0189] In other words, since points of motion compensated geometry (1413) represent motion compensated points of reference point cloud for attributes (1411) (or decoded geometry (1421), points of motion compensated geometry (1413) may correspond respectively to points of decoded geometry (1421) (or reference point cloud for attributes (1411), respectively). Therefore, the result of the attributes projection process at block 1420 may be a form of projection of attributes of reference point cloud for attributes (1411) (after applying MV field 1412) onto decoded geometry (1013, 1212).

[0190] In some examples, the attribute projection model may be a data structure used to efficiently perform attributes projection onto a specific position of a point. For example, the data structure may be a spatial- partitioning data structure such as a tree data structure (e.g., a KD tree or an octree). In some examples, the data structure is used to search for a set of one or more points Npts, belonging to the motion compensated geometry (1413), with positions in the neighborhood of a particular point p from the decoded geometry (1421) according to an example and from reference point cloud for attributes 1411 according to another example. In some examples, the set of points Nptsmay be determined to be within the neighborhood for point p based on distances of the set of points Nptsfrom the point p being within or less than a threshold value. The threshold value may be a predetermined value or computed by the encoder and signaled to the decoder in the bitstream. In some other examples, the set of points Nptsmay be determined as a number (or quantity) of points with positions that are closest to the point p. The number may be a predetermined quantity or computed by the encoder and signaled to the decoder in the bitstream. The distance may be a Manhattan distance (i.e., LI norm), an Euclidean distance (i.e., L2 norm), Chebyshev distance (i.e., L-infinity or L<» norm), or a Minkowski distance.

[0191] The attributes values associated with each point within the set of points Nptsmay be used at block 1420 for determining projected attributes values for the point p. For example, the projected attributes values may be attribute predictors of attributes for the point p. In some examples, a value of each attribute of point p may be predicted or projected based on values of corresponding attributes (with the same type as the each attribute) of the set of one or more points Npts.

[0192] In some examples, a projected attribute (e.g., attribute predictor) for the point p may be determined as an average of the attribute values, of the set of one or more points Npts, weighted by respective distance between the points Nptsand the point p. The distance may be a Manhattan distance (i.e., LI norm), an Euclidean distance (i.e., L2 norm), Chebyshev distance (i.e., L-infinity or L<» norm), or a Minkowski distance. For example, the projected attributes representing the attribute predictors for the point p may be determined to be the corresponding values of the attributes of the point from the motion compensated geometry (1413) closest to the point p. These examples enable faster projection because only one point is searched and selected from motion compensated geometry (1413) to determine an attributes predictor for point p from decoded geometry (1013, 1212).

[0193] At block 1430, the encoder / decoder may determine attribute predictors (1431) for the portion of geometry (1022, 1222) based on intra-prediction attribute mode using at least one already-coded portions (1432).

[0194] For example, the already-coded portions (1432) may be the already-coded portions (1123) of FIG. 11 or the already -coded portions (1323) of FIG. 13.

[0195] The encoder / decoder may generate (e.g., determine) the intra-prediction attribute mode based on the intra mode (selected attribute coding mode 1112, 1311).

[0196] For example, the attribute predictors (1431) may be obtained by extrapolating at least one attribute associated with at least one already -coded portions (1432).

[0197] For example, the intra mode (selected attribute coding mode (1112, 1311) may indicate that the at least one already-coded portion (1432) may comprise at least one spatial neighbor portion of the portion of geometry (1421).

[0198] In some examples, the portion of geometry (1421) is encompassed by a current ACU and the spatial neighbor portion of the portion of geometry (1421) may comprise points encompassed by an ACU having a part of its boundary overlapping with at least a portion of a boundary of the current ACU. For example, when ACU have cuboid shape, boundary may be defined as faces, edges and vertices of the cuboid. Sharing a part of the boundary may be defined as having a common face, a common edge or a common edge.

[0199] In some examples, the intra mode (selected attribute coding mode 1112, 1311) may indicate that the attribute predictors (1431) may be obtained based on extrapolation of at least one attribute associated with the at least one spatial neighbor portion of the portion of geometry (1421).

[0200] For example, extrapolation of at least one attribute associated with the at least one spatial neighbor portion of the portion of geometry (1421) may be determined by fitting a 3D attribute model for the at least one attribute associated with the at least one spatial neighbor portion of the portion of geometry (1421), and by extending (e.g., extrapolating) the fitted 3D attribute model to the portion of geometry (1421). A 3D attribute model may take spatial coordinates as input and provide modeled attributes as output; model parameters are fit (e.g., learned) on at least one attribute associated with the at least one spatial neighbor portion of the portion of geometry (1421). In some examples, the intra mode (selected attribute coding mode 1112, 1311) may indicate attribute predictors (1431) are determined based on averages of attributes associated with the spatial neighbor portion of the portion of geometry (1421).

[0201] In some examples, the intra mode (selected attribute coding mode 1112, 1311) may indicate attribute predictors (1431) are determined based on maximum of attributes associated with the spatial neighbor portion of the portion of geometry (1421).

[0202] In some examples, the intra mode (selected attribute coding mode 1112, 1311) may indicate a spatial direction along which the spatial neighbor portion of the portion of geometry (1421) are selected.

[0203] In some examples, the intra mode (selected attribute coding mode 1112, 1311) may indicate a maximum number of spatial neighbor portion of the portion of geometry (1421) are selected.

[0204] In some examples, the intra mode (selected attribute coding mode 1112, 1311) may indicate a maximum distance between the spatial neighbor portion of the portion of geometry (1421) and the portion of geometry (1421). For example, the maximum distance may be between any point of the geometry (1421) and any other point of the portion of geometry (1421).

[0205] In some examples, the intra mode (selected attribute coding mode 1112, 1311) may indicate an index of a list of indices, each index indicating one of the above intra-prediction attribute modes or one of their combinations.

[0206] FIG. 15 illustrates an example process 1500 for encoding attributes based on attribute predictors (1124) associated with portion of geometry (1022).

[0207] For example, process 1500 may be performed by an encoder (e.g., encoder 114 of FIG. 1). In some examples, blocks 1510-1530 may represent components within the encoder.

[0208] The encoder may determine residual attributes (1511) by subtracting the attribute predictors (1124) from the mapped attributes (1031) associated with portion of geometry (1022).

[0209] At block 1510, the encoder may determine transformed coefficients (1512) by applying 3D transform to the residual attributes (1511) based on portion of geometry (1022).

[0210] At block 1520, the encoder may determine quantized residual attributes or quantized coefficients (1521) by quantizing the residual attributes (1511) or the transformed coefficients (1512) respectively.

[0211] At block 1530, the encoder may entropy encode the residual attributes (1511) or the transformed coefficients (1512) or the quantized residual attributes or the quantized coefficients (1521) as attribute information (1032).

[0212] FIG. 16 illustrates another example process 1600 for encoding attributes based on attribute predictors (1124) associated with portion of geometry (1022).

[0213] For example, process 1600 may be performed by an encoder (e.g., encoder 114 of FIG. 1). In some examples, blocks 1610-1640 may represent components within the encoder. At block 1610, the encoder may determine attribute coefficients (1611) by applying a 3D transform to the attribute predictors (1124) based on portion of geometry (1022).

[0214] At block 1620, the encoder may determine mapped attribute coefficients (1621) by applying 3D transform to the mapped attributes (1031) based on portion of geometry (1022).

[0215] The encoder may determine residual coefficients (1631) by subtracting the attribute coefficients (1611) from the mapped attribute coefficients (1621).

[0216] At block 1630, the encoder may determine quantized coefficients (1641) by quantizing the residual coefficients (1631).

[0217] At block 1640, the encoder may entropy encode the residual coefficients (1631) or the quantized coefficients (1641) as attribute information (1032).

[0218] FIG. 17 illustrates an example process 1700 for decoding attributes based on attribute predictors (1324) associated with portion of geometry (1222).

[0219] For example, process 1700 may be performed by a decoder (e.g., decoder 120 of FIG. 1). In some examples, blocks 1710-1730 may represent components within the decoder.

[0220] At block 1710, the decoder may entropy decode from the bitstream (1290) quantized coefficients (1711) from attribute information (1232).

[0221] At block 1720, the encoder may determine residual coefficients (1721) by inverse quantizing the quantized coefficients (1711).

[0222] In some examples, the decoder may entropy decode from the bitstream (1290) residual coefficients (1721) from the bitstream (1290).

[0223] At block 1730, the decoder may determine residual attributes (1731) by applying inverse 3D transform to the residual coefficients (1721) based on portion of geometry (1222).

[0224] The decoder may determine decoded attributes (1233) by adding the residual attributes (1731) with the attribute predictors (1324).

[0225] FIG. 18 illustrates another example process 1800 for decoding attributes based on attribute predictors (1324) associated with portion of geometry (1222).

[0226] For example, process 1800 may be performed by a decoder (e.g., decoder 120 of FIG. 1). In some examples, blocks 1810-1840 may represent components within the decoder.

[0227] At block 1810, the decoder may entropy decode from the bitstream (1290) quantized coefficients (1811) from attribute information (1232).

[0228] At block 1820, the decoder may determine residual coefficients (1821) by inverse quantizing the quantized coefficients (1811).

[0229] In some examples, the decoder may entropy decode from the bitstream (1290) residual coefficients (1821). At block 1830, the decoder may determine attribute coefficients (1831) by applying 3D transform to the attribute predictors (1324) based on the portion of geometry (1222).

[0230] The decoder may determine decoded attribute coefficients (1841) by adding the residual coefficients (1821) with the attribute coefficients (1831).

[0231] At block 1840, the decoder may determine decoded attributes (1233) by applying an inverse 3D transform to the decoded attribute coefficients (1841) based on portion of geometry (1222).

[0232] In some examples (e.g., used in G-PCC), there are two 3D transforms that may be used / selected for transforming residual attributes (1511) of FIG. 15, mapped attributes (1031) and attribute predictors (1124) of FIG. 16 and attribute predictors (1324) of FIG. 18, namely the prediction with lifting transform (“pred-liff ’) scheme and the region-adaptive hierarchical transform (“RAHT”) scheme. Inverse 3D transforms of these two 3D transforms may be used / selected for inverse transforming residual coefficients (1721) of FIG. 17 and decoded attributes coefficients (1841) of FIG. 18.

[0233] In some examples, the pred-lift scheme first performs a decomposition of the portion of geometry (1022, 1222) into Levels of Details (also known as LoD). For a set (S) of all points (e.g., points) of the portion of geometry (1022, 1222), the set is decomposed into disjoint subsets S1such that S = Uf=o S1- By doing so, L levels of details are defined as a tower of portion geometries

[0234] S° c S° U S1c ••• c S° U ... U SL~ = S where the set S° of points is the first (e.g., coarsest) level of details, and the set S° U ... u SL-1of points is the L* (e.g., finest) level of details.

[0235] Attributes aj are associated with the points Sj of the set S of all points of the portion of geometry (1022, 1222). Considering subsets a0, . . . , aL 1of attributes, attributes a) of a subset a1are associated with the points Sj of the subset S1Therefore, the i* level of details (5° U ... U S1-1) has associated attributes comprising the concatenation of attributes of subsets a0, . . . , a1 1. The set ‘a’ of all attributes may be partitioned into subsets a0, . . . , aL 1.

[0236] FIGS. 19-22 illustrate examples of diagrams 1900-2200 of example prediction transform scheme and pred-lift scheme. The prediction transform scheme may be a variation of pred-lift scheme without update operations. These 3D transform schemes are examples of wavelet transforms that converts (e.g., transforms) attribute values into wavelet coefficients that may be more efficiently compressed than the original attribute values. In some examples, these wavelet coefficients may represent values of residual attributes, which may be smaller and more efficiently compressed than the values of the original attributes. Therefore, the residual attributes may be referred to as and / or comprise wavelet coefficients (or alternatively transform / transformed coefficients) resulting from application of the prediction transform scheme. As will be further described below, the prediction and pred-lift schemes generally operate using prediction for and between levels of details of attributes. In some examples, at the encoder, attributes at a higher (e.g., finer) level of detail may be predicted based on attributes at a lower (e.g., coarser) level of detail. For example, each level of detail starting from the highest level may be successively predicted based on lower level(s) of detail. The decoder may perform inverse operations such that attributes at a lower level of detail are predicted and reconstructed based on residual attributes of higher level (s) of detail. For example, each level of detail starting from the lowest level may be successively predicted and reconstructed based on higher level(s) of detail. Although the examples shown in FIGS. 19-22 show three levels of details (LoDs), it should be understood that the processes may be extended and iteratively performed for more LoDs.

[0237] FIG. 19 illustrates a diagram of an example process 1900 for transforming a set ‘a’ of attributes based on a prediction transform scheme.

[0238] For example, process 1900 may be performed by an encoder (e.g., encoder 114 of FIG. 1) or a decoder (e.g., decoder 120 of FIG. 1). In some examples, blocks 1910-1960 may represent components within the encoder or the decoder.

[0239] In this example, the set ‘a’ of attributes may be residual attributes (1511) of FIG. 15, mapped attributes (1031), attribute predictors (1124) of FIG. 16 or attribute predictors (1324) of FIG. 18.

[0240] In this example, the set ‘a’ of attributes may be transformed using prediction for and between three (L=3) levels of details, from a first level to a third level. At block 1910, an encoder may split a set ‘a’ of attributes into a first set of attributes comprising the attributes of the subset a2and a second set of attributes comprising the attributes of the two subsets a0and a1. At block 1920, the encoder or the decoder may determine predictive values of the attributes of the first set of attributes (a2) from the attributes of the second set of attributes (a0and a1). At block 1930, the encoder or the decoder may determine first residual values ‘res a2’ by subtracting the predictive values from the attributes of the first set of attributes (a2).

[0241] In some examples, the operations at blocks 1920-1930 may be iteratively applied to each successively lower (e.g., coarser) LoD. For example, at block 1940, the encoder or the decoder may split the second set of attributes (a0and a1) into third and fourth sets of attributes. The third set of attributes comprises the attributes of the subsets a1and the fourth set of attributes comprises the attributes of the subset a0. At block 1950, the encoder or the decoder may determine predictive values of the attributes of the third set of attributes (a1) from the attributes of the fourth set of attributes (a0). At block 1960, the encoder or the decoder may determine second residual values ‘res a1’ by subtracting predictive values from the attributes of the third set (a1). For example, the attributes of the subset a0, the first residual value ‘res a2’, and the second residual value ‘res a1’ may be transformed coefficients (1512) of FIG. 15, attributes coefficients (1611), mapped attributes coefficients (1621) of FIG. 16 or attributes coefficients (1831) of FIG. 18.

[0242] In some examples, the encoder or the decoder may perform intra prediction of a current attribute a°j of the subset a0to be coded based on already -coded attributes of the subset a0to improve the compression efficiency of the attributes of the subset a0.

[0243] FIG. 20 illustrates a diagram of an example process 2000 for inverse transforming transformed coefficients based on inverse prediction transform scheme.

[0244] For example, process 2000 may be performed by a decoder (e.g., decoder 120 of FIG. 1). In some examples, blocks 2020-2070 may represent components within the decoder.

[0245] In this example, a set ‘a’ of attributes is obtained by using prediction between three (L=3) levels of details, from a first level to a third level. The set ‘a’ of attributes is obtained by inverse transforming the first residual values ‘res a2’, the second residual values ‘res a1’ and attributes of a fourth set of attributes (a0) that may be obtained by the process 1900 of FIG. 19. For example, the set ‘a’ of attributes may be the residual attributes (1731) of FIG. 17 or decoded attributes (1233) of FIG. 18.

[0246] For example, the first residual values ‘res a2’, the second residual values ‘res a1’ and attributes of a fourth set of attributes (a0) may be residual attributes (1731) of FIG. 17 or residual coefficients (1821) of FIG. 18.

[0247] At block 2020, similar to block 1950, the decoder may determine predictive values of the attributes of a third set of attributes (a1) from the decoded attributes of the fourth set of attributes (a0). At block 2030, the decoder may determine decoded attributes of the third set of attributes (a1) by adding the predictive values to the decoded first residual values ‘res a1’.

[0248] In some examples, the operations at blocks 2020-2030 may be iteratively applied to each successively higher (e.g., finer) LoD. For example, at block 2040, inverse of block 1940, the decoder may determine a second set of attributes (a0and a1) by merging the third set of attributes (a1) and the fourth set of attributes (a0). At block 2050, similar to block 1920, the decoder may determine predictive values of the attributes of a first set of attributes (a2) from the attributes of the second set of attributes (a0and a1). At block 2060, the decoder may determine decoded attributes of the first set of attributes (a2) by adding the predictive values to the decoded second residual values ‘res a2’. At block 2070, inverse of block 1910, the decoder may determine the set ‘a’ of attributes by merging the first set of attributes (a2) and the second set of attributes (a0and a1).

[0249] FIG. 21 illustrates a diagram of an example process 2100 for transforming a set ‘a’ of attributes based on a pred-lift transform scheme with prediction and update. For example, process 2100 may be performed by an encoder (e.g., encoder 114 of FIG. 1) or a decoder (e.g., decoder 120 of FIG. 1). In some examples, blocks 2110-2190 may represent components within then encoder or the decoder.

[0250] In this example, the set ‘a’ of attributes may be residual attributes (1511) of FIG. 15, mapped attributes (1031), attribute predictors (1124) of FIG. 16 or attribute predictors (1324) of FIG. 18.

[0251] In this example, the set ‘a’ of attributes may be transformed using prediction between three (L=3) levels of details, from a first level to a third level. At block 2110, similar to block 1910, the encoder or the decoder may split a set ‘a’ of attributes into a first set of attributes comprising the attributes of the subset a2and a second set of attributes comprising the attributes of the two subsets a0and a1. At block 2120, similar to block 1920, the encoder or the decoder may determine predictive values of the attributes of the first set of attributes (a2) from the attributes of the second set of attributes (a0and a1). At block 2130, similar to block 1930, the encoder or the decoder may determine first residual values ‘res a2’ by subtracting predictive values from the attributes of the first set of attributes (a2).

[0252] At block 2175, the encoder or the decoder may determine update attribute values from the first residual values ‘res a2’. For example, the encoder or the decoder may determine an update attribute value based on a first residual value. For example, the update attribute value may be determined as the first residual value multiplied by a scaling factor (e.g., 'A, !4, 1 / 8, etc.). At block 2180, the encoder or the decoder may update attribute values ‘up a0’ and ‘up a1’ of the second set of attributes (a0and a1) by adding the update attribute values to the attribute values of the second set of attributes (a0and a1).

[0253] In some examples, the operations at blocks 2120, 2130, 2175, and 2180 may be iteratively applied to each successively lower (e.g., coarser) LoD. For example, at block 2140, the encoder may split the second set of attributes (a0and a1) into a third and fourth set of attributes. The third set of attributes comprises the updated attribute values ‘up a1’ of the subset a1and the fourth set of attributes comprises the updated attribute values ‘up a0’ of the subset a0. At block 2150, the encoder or the decoder may determine predictive values of the updated attribute values ‘up a1’ of the third set of attributes (a1) from the updated attribute values ‘up a0’ of the fourth set of attributes (a0). At block 2160, the encoder or the decoder may determine third residual values ‘res up a1’ by subtracting predictive values from the updated attribute values ‘up a1’ of the third set of attributes (a1). At block 2185, the encoder or the decoder may determine update attribute values from the third residual values ‘res up a1’.At block 2190, the encoder may determine further updated attribute values ‘up up a0’ of the fourth set of attributes (a0) by adding the update attribute values to the updated attribute values ‘up a°‘ of the fourth set of attributes (a0).

[0254] For example, the first residual values ‘res a2’, third residual values ‘res up a1’ and further updated attribute values ‘up up a0’ of the fourth set of attributes may be transformed coefficients (1512) of FIG. 15, attributes coefficients (1611), mapped attributes coefficients (1621) of FIG. 16 or attributes coefficients (1831) of FIG. 18.

[0255] In some examples, the encoder or the decoder may perform intra prediction of a current further updated attribute values ‘up up a°j‘ to be coded based on already-coded attributes of the fourth set of attributes to improve the compression efficiency of the further updated attribute values ‘up up a0’ of the fourth set of attributes.

[0256] FIG. 22 illustrates a diagram of an example process for inverse transforming transformed coefficients based on an inverse pred-lift transform scheme with prediction and update.

[0257] For example, process 2200 may be performed by a decoder (e.g., decoder 120 of FIG. 1). In some examples, blocks 2220-2290 may represent components within the decoder.

[0258] In this example, a set ‘a’ of attributes is obtained by using prediction between three (L=3) levels of details, from a first level to a third level. The set ‘a’ of attributes is obtained by inverse transforming the first residual values ‘res a2’, third residual values ‘res up a1’ and further updated attribute values ‘up up a0’ of the fourth set of attributes that may be obtained by the process 2100 of FIG. 21. For example, the set ‘a’ of attributes may be the residual attributes (1731) of FIG. 17 or decoded attributes (1233) of FIG. 18.

[0259] For example, the first residual values ‘res a2’, the third residual values ‘res up a1’ and further updated attribute values ‘up up a0’ of a fourth set of attributes (a0) may be residual coefficients (1721) of FIG. 17 or residual coefficients (1821) of FIG. 18.

[0260] At block 2275, similar to block 2185, the decoder may determine update attribute values from the decoded third residual values ‘res up a1’. For example, the decoder may determine an update attribute value based on the third residual values. For example, the update attribute value may be determined as the third residual values multiplied by a scaling factor (e.g., 1 , 14, 1 / 8, etc.).

[0261] At block 2280, the decoder may determine updated attribute values ‘up a0’ of the fourth set of attributes (a0) by subtracting the update attribute values from the decoded further updated attribute values ‘up up a0’ of the fourth set of attributes (a0). At block 2220, similar to block 2150, the decoder may determine predictive values of the updated attribute values ‘up a1of a third set of attributes (a1) from the updated attribute values ‘up a0’ of the fourth set of attributes (a0). At block 2230, the decoder may determine updated attribute values ‘up a1of the third set of attributes (a1) by adding the predictive values to the decoded third residual values ‘res up a1’. At block 2240, inverse of block 2140, the decoder may determine a second set of attributes (a0and a1) by merging the third set of attributes (a1) and the fourth set of attributes (a0). The second set of attributes (a0and a1) comprises updated attribute values ‘up a0’ and updated attribute values ‘up a1’. At block 2285, similar to block 2175, the decoder may determine update attribute values from the decoded first residual values ‘res a2’. In some examples, the operations at blocks 2220, 2230, 2240, 2275, and 2280 may be iteratively applied to each successively higher (e.g., finer) LoD. For example, at block 2290, the decoder may determine attribute values ‘a0’ and attribute values ‘a1’ of the second set of attributes (a0and a1) by subtracting the update attribute values from the updated attribute values ‘up a0’ and from updated attribute values ‘up al’ of the second set of attributes (a0and a1). At block 2250, similar to block 2120, the decoder may determine predictive values of the attributes of a first set of attributes (a2) from the attributes of the second set of attributes (a0and a1). At block 2260, the decoder may determine decoded attributes of the first set of attributes (a2) by adding the predictive values to the decoded second residual values ‘res a2’. At block 2270, inverse of block 2110, the decoder may determine the set ‘a’ of attributes by merging the first set of attributes (a2) and the second set of attributes (a0and a1).

[0262] In some examples, pred-lift schemes may be similar to the well-known so-called lifting scheme applied to wavelets in image coding. Adding update steps, as in the pred-lift scheme, may provide better compression performance in combination with the prediction steps.

[0263] In some examples, instead of using the pred-lift scheme, attributes may be transformed using the RAHT scheme that is based on the iterative use of a two-point transform. In the framework of point cloud attribute coding, the two-point RAHT transform is to be understood as being applied to two sets Ai and A2 of attributes having respectively wi and W2 number of attributes and respective associated coefficients CAI and CA2 representative of the sum of attribute values over their respective set divided by the square root of the number of attributes.

[0264] The two-point RAHT transform depends on the weights wi and W2 and is defined by a 2x2 matrix as follows

[0265] When applied to the two coefficients CAI and CA2, two new coefficients DC and AC are determined.

[0266] As illustrated below, the above property (*) on coefficients still holds for the DC coefficient.

[0267] — CA1UA2

[0268] The two-point RAHT transform may be applied iteratively to DC coefficients. This is the RAHT iterative method. Once determined, AC coefficients do not undergo any further transformation. At the start of the RAHT iterative method, there are as many initial sets A! of attributes as there are points in the coded geometry S. Each initial set A! of attributes thus contains one attribute (wi=l) and the coefficient CAI is equal to the value of this one attribute, thus fulfilling the property (*). By induction, the property (*) holds for all subsequent DC coefficients determined after iterative application of the two point RAHT transform.

[0269] Therefore, at any stage of the RAHT iterative method, determined coefficients are the union of a set of DC coefficients fulfilling the property (*) and a set of AC coefficients. The RAHT iterative method may continue until DC coefficients are depleted and only one DC coefficient is left. In this case, this one DC coefficient is equal to CA where A is the set of all attributes to be transformed. The RAHT iterative method may a priori follow any order among pairs of DC coefficients.

[0270] For example, the attributes to be transformed may be residual attributes (1511), attribute predictors (1124), mapped attributes (1031) or attribute predictors (1324) and the one obtained DC coefficient CA may be transformed coefficients (1 12), attributes coefficients (1611), mapped attributes coefficients (1621) or attributes coefficients (1831) respectively.

[0271] The two-point inverse RAHT transform may be defined by a 2x2 matrix as follows and is applied to DC and AC coefficients such as to obtain back the two coefficients CAI and CA2

[0272] The inverse iterative RAHT method applies the inverse two-point RAHT to DC and AC coefficient in reverse order relative to their obtention by the iterative RAHT method. At the end of the inverse iterative RAHT method, coefficients CAI associated with the initial sets Ai of attributes are obtained. These coefficients CAI are equal to the values of the one attributes associated with the initial sets A

[0273] For example, attributes associated with the initial sets A! may be the residual attributes (1731) or decoded attributes (1233).

[0274] In some examples (e.g., such as in G-PCC), the RAHT iterative method follows an octree as a specific iterative order. Basically, the up to eight DC coefficients associated with the up to eight occupied child nodes of a parent node in the octree undergo a cascade of two-point RAHT transformations until one DC coefficient remains, together with up to seven AC coefficients. This one DC coefficient is pushed at parent node level and the method is repeated at upper octree depth until the root node is reached.

[0275] FIG. 23 illustrates an example RAHT transformation applied on child nodes of an octree parent node along three successive directions.

[0276] The parent node 2300 has five occupied child nodes with associated coefficients Ci and weights Wi. A first RAHT transformation 2310 is performed along a first direction 2311. If there are two adjacent occupied child nodes 2313 along this direction, they undergo a two-point RAHT transform to determine a new DC coefficient 2314 and an AC coefficient 2315 pushed to a set 2350 of AC coefficients. If there is only one occupied child node 2316 along this direction, the node is left as is and its DC coefficient is kept 2317. By doing so, the child nodes are collapsed along the first direction to determine a new set 2319 of nodes, here a set of three nodes, with associated new DC coefficients. Then, a second RAHT transformation 2320 is performed along a second direction 2321 in a similar way to determine child nodes 2322, that have been collapsed along the first two directions 2311 and 2321, together with AC coefficients 2323 pushed to the set 2350 of AC coefficients. Finally, a third RAHT transformation 2330 is performed along a third direction 2331 in a similar way to determine a unique child node 2332, resulting from the collapse along all three directions, together with AC coefficients 2333 pushed to the set 2350 of AC coefficients.

[0277] The unique collapsed child node 2332 has an associated DC coefficient that is pushed to the parent node as illustrated in FIG. 24.

[0278] FIG. 24 illustrates an example RAHT transformation being applied to all octree nodes at depth ‘d’ to determine DC coefficients at depth d- 1 and AC coefficients. Occupied nodes 2400 of an octree at depth d are illustrated. These nodes undergo a RAHT transformation along the three directions such as to push DC coefficients up to their occupied parent nodes 2410 belonging to the octree at depth d-1. For example, the three DC coefficients of the child nodes 2401 undergo a RAHT transformation along the three directions to determine a unique DC coefficient associated with their parent node 2411 and two AC coefficients 2421 pushed to a set 2420 of AC coefficients. By performing this method for all occupied nodes 2400 of the octree at depth d, the DC coefficients associated with occupied nodes of the octree at depth d are transformed into DC coefficients associated with occupied nodes 2410 of the octree at depth d-1 and a set 2420 of AC coefficients.

[0279] This bottom-up method may be repeated depth per depth until reaching the minimum depth (the root node) and the result of the RAHT transformation over the complete octree is a set of coefficients comprising a unique DC coefficient and a set of (many) AC coefficients.

[0280] The RAHT transformation method typically starts from the highest depth where occupied child nodes correspond to a unique point (voxel) of the coded point cloud S associated with a unique attribute among the set ‘a’ of attributes. The DC coefficient at highest depth is thus set as the value of the unique attribute associated with each occupied node and the weights ‘w’ are set to 1.

[0281] The inverse RAHT method on an octree is a top-down method from the root node down to the last depth made of leaf nodes that contain each only one point of the point cloud, thus only one associated attribute. The DC coefficients of occupied nodes 2410 of the octree at depth d-1 are inverse transformed into DC coefficients of occupied nodes 2400 of the octree at depth d by applying the inverse two-point RAHT transform to the DC coefficient of each of the occupied node of the octree at depth d- 1 and to the related AC coefficients from set 2420 of AC coefficients. The inverse two-point RAHT transform is applied along the three directions, in reverse order, such as to invert the node transformation process of FIG. 23. By doing so, DC coefficients of the leaf nodes are obtained, and their values correspond to the attributes associated with the unique point of each of the leaf nodes. Like geometry coding of a point cloud, coding of attributes associated with the points of a current point cloud may benefit from inter frame prediction using a motion compensated point cloud. The motion compensated point cloud inherits naturally attributes from a reference point cloud that has been motion compensated: during motion, points keep their associated attributes. The motion compensated attributes, e.g., the attributes associated with the points of the motion compensated point cloud, may be used to better compress the attributes of the coded geometry of the current point cloud.

[0282] Inter pred-lift scheme may use motion compensated attributes which are easily used in the pred-lift scheme by plugging them to the blocks 1610, 1620, 1730, 1830 and 1840. For example, attributes a1of the set S1of points may be predicted not only by attributes of the subsets a0, . . . , a1 1of the lower level of details S° U ... U S1-1, but also by motion compensated attributes of a set amterassociated with points of a motion compensated point cloud Smter. Practically, the prediction step may be performed based on attributes of subsets a0, . . . , a1 1and of a set amterof an augmented lower level of details S° U ... u S1-1U inter

[0283] Consequently, the encoder and / or decoder may determine predictive values of the attributes of the fourth set of attributes (subset a0of the coarsest level of details 5°) from the motion compensated attributes of the set amterassociated with the points of a motion compensated point cloud Smter, and the encoder and / or decoder may subtract the predictive values from the attributes of the fourth set of attributes to determine residual values ‘res a0’. The encoder may encode the residual values ‘res a0’ into the bitstream instead of the attributes of the fourth set of attributes.

[0284] Inter RAHT scheme may be used in the blocks 1610, 1620, 1730, 1830 and 1840. Inter RAHT scheme uses inter prediction for predicting the values of the DC and the AC coefficients determined by the RAHT iterative method. Because the generation of DC and AC coefficients follows an octree, it is essential to maintain, as much as possible, a common attribute octree structure for both the portion of geometry (1022, 1222) and a motion compensated portion of geometry. A common bounding box encompassing both portion geometries may be determined, and an octree partitioning may be performed, from a root node associated with the common bounding box, for both portion geometries. This leads to two octree partitioning that are different when the point geometries are not equal, which is likely. The two octrees have a common subtree starting from the root node. On this subtree, occupied node topology is the same and a common set of DC and AC coefficients is determined for both portion geometries. Thus, the subset of DC and AC coefficients associated with nodes of the common subtree and determined from the attributes of the portion of geometry (1022, 1222) may be predicted from DC and AC coefficients determined from the attributes of the motion compensated portion of geometry. Practically, the encoder and / or decoder may determine coefficient residual values by subtracting the DC and AC coefficients determined from the attributes of the motion compensated portion of geometry from the DC and AC coefficients associated with nodes of the common subtree and determined from the attributes of the portion of geometry (1022, 1222).

[0285] The DC and AC coefficients that are not associated with nodes of the common subtree may not be predicted and may be transformed directly in a similar way as performed for the case without inter prediction.

[0286] Alternatively, instead of predicting AC coefficients, predicted DC coefficients of the portion of geometry (1022, 1222) may be determined at some depth, assuming both the octree of the portion of geometry (1022, 1222) and the octree of the motion compensated portion of geometry have a same occupancy of a node at this depth. The predicted DC coefficients may be determined from their co-located DC coefficients of the motion compensated portion of geometry. DC residual values may be determined by subtracting the predicted DC coefficients from the DC coefficients of the portion of geometry (1022, 1222). The RAHT transformation then goes up in the octree starting from DC residual values replacing the DC coefficients of the portion of geometry (1022, 1222).

[0287] A RAHT scheme process that does not use information from a reference point cloud different from the current point cloud is called an intra RAHT scheme. Infra prediction may be performed between DC and AC coefficients of an infra RAHT scheme. For example, so-called inter-depth prediction within portion of geometry (1022, 1222) has been integrated into the RAHT scheme of GPCC. The inter-depth prediction mechanism predicts the DC coefficients associated with nodes of the octree at depth d by using interpolation of DC coefficients associated with nodes of the octree at lower depth d-1.

[0288] In some implementations of point cloud coding, the selection (block 1110) of the attribute coding mode (1112) by the process 1100 is performed by a Rate-Distortion Optimization (RDO) such as to select the attribute coding mode (1112) as being a candidate attribute coding mode with a smallest cost (Cmode) from a list of candidate attribute coding modes. The cost (Cmode) of a candidate attribute coding mode may be computed as a Lagrange cost, which is a combination of a bitrate Rmode and a distortion Dmode as Cmode = Dmode + X* Rmode, where / _>0 is a fixed Lagrange parameter. The bitrate Rmode may be obtained for a candidate attribute coding mode as being a sum of bitrates caused by coding both the mode information (1042) and the attribute information (1032) in the bitstream (1190). The distortion may be obtained for the candidate attribute coding mode by comparing the attributes associated with portion of geometry (1022) against decoded attributes (1233) associated with the portion of geometry (1222) obtained based on the candidate attribute coding mode. RDO may put in competition many candidate attribute coding modes including several interprediction based attribute coding modes and several intra-prediction based attribute coding modes as discussed above.

[0289] An inter-prediction based attribute coding mode is an attribute coding mode using attribute predictors obtained based on an inter-prediction attribute mode as discussed above.

[0290] An intra-prediction based attribute coding mode is an attribute coding mode using attribute predictors obtained based on an intra-prediction attribute mode as discussed above.

[0291] In video compression, a list of intra-prediction and inter-prediction based candidate coding modes may depend on the size (e.g., 4x4, 8x8, 16x16, etc.) of the block of pixels to be coded. The cost of coding the selected intra-prediction or inter-prediction based candidate coding modes, as mode information, is shared by all the pixels of the block. Therefore, bigger blocks have more pixels that support this cost, and the list of intra-prediction and inter-prediction based candidate coding modes can be set longer for bigger blocks.

[0292] As opposed to video, not all voxels of a portion of geometry of a current point cloud (e.g., encompassed by an ACU) are occupied by points of the portion of geometry (1022). Moreover, the portion of geometry (1022) is not determined only by the size of a volume encompassing the portion geometry (1022) (e.g., an ACU size). For examples, one point may belong to a big volume or many points may belong to a smaller volume. Consequently, determining a list of candidate attribute coding modes based only on the size of a volume encompassing the portion of geometry (1022), as performed in video coding, is not efficient in terms of coding performance.

[0293] Embodiments of the present disclosure are related to an approach for improving compression of attributes associated with portion of geometry by selecting attribute coding mode for coding said attributes based on the portion of geometry. Attributes associated with the portion of geometry are then encoded / decoded based on the selected attribute coding mode.

[0294] The attribute coding mode for coding attributes associated with a portion of geometry is thus selected according to characteristics of the portion of geometry to improve coding performance of those attributes.

[0295] FIG. 25 illustrates an example process 2500 for encoding attributes associated with a portion of geometry (2522) of a current point cloud, according to embodiments.

[0296] The current point cloud may be a point cloud frame of a sequence of point cloud frames of a dynamic point cloud.

[0297] For example, the geometry of the current point cloud may be a decoded geometry obtained by coding and decoding a geometry of a point cloud to be coded as discussed above. The portion geometry (2522) is then a portion of the decoded geometry. For example, the attributes of the current point cloud may be mapped attributes (2531) obtained by mapping the attributes of the point cloud to be coded onto the decoded geometry.

[0298] For example, the process of FIG. 25 may be performed by an encoder (e.g., encoder 114 of FIG. 1). The process of FIG. 25 may include the same operations (shown as having the same labeled blocks) as those described in FIG. 11. Different from the process of FIG. 11, the process 2500 of FIG. 25 replaces block 1110 of FIG. 11 by block 2510.

[0299] In some examples, block 2510 may represent components within the encoder.

[0300] The process 2500 comprises operations of block 1030 that encodes, in a bitstream (2590), mapped attributes (2531) associated with the portion of geometry (2522) as attribute information (2532) and, possibly mode information (2542).

[0301] At block 2610, the encoder selects an attribute coding mode (2511) for the portion geometry (2522) based on the portion geometry (2522).

[0302] In some embodiments, the encoder further may encode, in the bitstream (2590), mode information (2542) indicating the selected attribute coding mode (2511) for the portion of geometry (2522).

[0303] For example, the geometry of the current point cloud may be segmented into a set of portions of geometry (2522). For example, the geometry of the current point cloud may be segmented into a set of ACUs and each ACU may be associated with a volume comprising one of the portion geometry (2522) of the set of portions of geometry. An attribute coding mode (2511) may be selected per portion of geometry (2522) and attributes associated with each portion of geometry (2522) of the set of portions of geometry may be encoded based on the corresponding selected attribute coding mode (2511). The mode information (2542) may then indicate the selected attribute coding mode (2511) for each portion of geometry (2522) of the set of portions of geometry. For example, when the portion of geometry (2522) is encompassed by a volume associated with an ACU, the mode information indicating the selected attribute coding mode (2511) for the portion of geometry (2522) may be encoded as information relative to the ACU.

[0304] In some embodiments, the encoder may select the attribute coding mode (2511) for the portion geometry (2522) based on the portion geometry (2522) and reference point cloud for attributes (1122).

[0305] In some embodiments, the encoder may select the attribute coding mode (2511) for the portion geometry (2522) based on the portion geometry (2522) and mapped attributes (2531).

[0306] FIG. 26 illustrates an example process 2600 for decoding attributes associated with a portion of geometry (2622), according to embodiments.

[0307] For example, portion of geometry (2622) is a portion of a geometry of a current point cloud that may be a point cloud frame of a sequence of point cloud frames of a dynamic point cloud.

[0308] The portion geometry (2622) may be a portion of a decoded geometry obtained by decoding information from the bitstream (2690) as discussed above. For example, the process of FIG. 26 may be performed by a decoder (e.g., decoder 120 of FIG. 1). The process of FIG. 26 may include the same operations (shown as having the same labeled blocks) as those described in FIG. 13. Different from the process of FIG. 13, the process 2600 of FIG. 26 replaces block 1310 of FIG. 13 by block 2610.

[0309] In some examples, block 2610 may represent components within the decoder.

[0310] The process 2600 comprises operations of block 1230 that obtains decoded attributes (2633) associated with portion of geometry (2622) by decoding attribute information (2632) from the bitstream (2690) and possibly mode information (2631).

[0311] At block 2610, the decoder selects an attribute coding mode (2611) for the portion geometry (2622) based on the portion geometry (2622).

[0312] In some embodiments, the decoder may obtain the selected attribute coding mode (2611) by decoding the mode information (2631) from the bitstream (2690). For example, the bitstream (2690) may be obtained by the process 2500, where the mode information (2631) may indicate one attribute coding mode selected based on a portion of geometry (2522) of the set of portions of geometry.

[0313] For example, the geometry of the current point cloud may be segmented into a set of portions of geometry (2622). For example, the geometry of the current point cloud may be segmented into a set of ACUs and each ACU may be associated with a volume comprising one of the portion geometry (2622) of the set of portions of geometry. An attribute coding mode (2611) may be selected per portion of geometry (2622) and attributes associated with each portion of geometry (2622) of the set of portions of geometry may be decoded based on the corresponding selected attribute coding mode (2611). The mode information (2631) may then indicate the selected attribute coding mode (2611) for each portion of geometry (2622) of the set of portions of geometry. For example, when the portion of geometry (2622) is encompassed by a volume associated with an ACU, the mode information indicating the selected attribute coding mode (2611) for the portion of geometry (2622) may be decoded as information relative to the ACU.

[0314] In some embodiments, the decoder may select the attribute coding mode (2611) for the portion geometry (2622) based on the portion geometry (2622) and reference point cloud for attributes (1322).

[0315] In some embodiments, the selecting (at blocks 2510, 2610), for a portion of geometry (2522, 2622), an attribute coding mode (2511 , 2611) may be based on a number of points of the portion of geometry (2522, 2622).

[0316] In some embodiments, the selecting (2510, 2610), for a portion of geometry (2522, 2622), an interprediction based attribute coding mode as being the selected attribute coding mode (2511, 2611) may be based on projection information based on a comparison of the portion of geometry (2522, 2622) with a geometry of a reference point cloud for attributes (1122, 1322).

[0317] For example, the projection information may comprise indication of a distance of projection. For example, the selecting the inter-prediction attribute coding mode is based on a comparison of the distance of projection with a threshold.

[0318] For example, the encoder may encode, in the bitstream (2590), the threshold as part of mode information (2542).

[0319] For example, the decoder may decode, from the bitstream (2690), the threshold as part of mode information (2631).

[0320] In some embodiments, the attribute coding mode (2511, 2611) may be selected from a list of candidate attribute coding modes.

[0321] FIG. 1 illustrates an example process 2700 for selecting an attribute coding mode from a list of candidate attribute coding modes, according to embodiments.

[0322] For example, the process of FIG. 27 may be performed by an encoder (e.g., encoder 114 of FIG. 1) or a decoder (e.g., decoder 120 of FIG. 1).

[0323] The process 2700 comprises operations of block 2710 that determines a list of candidate attribute coding modes (2712) based on a portion of geometry (2711) and block 2720 that selects one candidate attribute coding mode (2721) from the list of candidate attribute coding modes (2712). The operations of blocks 2710 and 2720 may be operations of blocks 2510 and 2610.

[0324] For example, the selected candidate attribute coding mode (2721) may be the selected attribute coding mode (2511) of FIG. 25 or the selected attribute coding mode (2611) of FIG. 26. The portion of geometry (2711) may be the portion of geometry (2522) or portion of geometry (2622). The reference point cloud (2713) may be the reference point cloud for attributes (1122) of FIG. 25 or the reference point cloud for attributes (1322) of FIG. 26.

[0325] In some examples, blocks 2710 and 2720 may represent components within the decoder.

[0326] At block 2710, the encoder or the decoder determines the list of candidate attribute coding modes (2712) based on the portion of geometry (2711).

[0327] At block 2720, the encoder or the decoder selects a candidate attribute coding mode (2721) from the list of candidate attribute coding modes (2712).

[0328] In some embodiments, the determining (block 2710) the list of candidate attribute coding modes (2712) is based on a number of points of the portion of geometry (2711).

[0329] In some embodiments, the determining (block 2710) the list of candidate attribute coding modes (2712) comprises including an inter-prediction based attribute coding mode in the list of candidate attribute coding modes (2712) based on projection information obtained by comparing the portion of geometry (2711) with a geometry of the reference point cloud for attributes (2713).

[0330] For example, the projection information comprises indication of a distance of projection. For example, the including an inter-prediction based attribute coding mode in the list of candidate attribute coding mode (2712) may be based on a comparison of the distance of projection with a threshold.

[0331] For example, the encoder may encode, in the bitstream (2590), the threshold as part of mode information (2542).

[0332] For example, the decoder may decode, from the bitstream (2690), the threshold as part of mode information (2631).

[0333] In some embodiments, the list of candidate attribute coding modes (2712) may be obtained by pruning an initial list of candidate attribute coding modes (2714).

[0334] In some embodiments, the initial list of candidate attribute coding modes (2714) may comprise at least one intra-prediction based attribute coding mode.

[0335] In some embodiments, the initial list of candidate attribute coding modes (2714) may comprise at least one inter-prediction based attribute coding mode.

[0336] In some embodiments, the initial list of candidate attribute coding modes (2714) may comprise at least one intra-prediction based attribute coding mode and at least one inter-prediction based attribute coding mode.

[0337] In some embodiments, the pruning the initial list of candidate attribute coding modes (2714) may be based on projection information obtained by comparing the portion of geometry (2711) with a geometry of the reference point cloud for attributes (2713).

[0338] For example, the projection information may comprise indication of a distance of projection.

[0339] For example, the pruning of the initial list of candidate attribute coding modes (2714) may be based on a comparison of the distance of projection with a threshold.

[0340] For example, the encoder may encode, in the bitstream (2590), the threshold as part of mode information (2542).

[0341] For example, the decoder may decode, from the bitstream (2690), the threshold as part of mode information (2631).

[0342] In some embodiments, the pruning of the initial list of candidate attribute coding modes (2714) may be based on the portion of the geometry (2711).

[0343] In some embodiments, the pruning of the initial list of candidate attribute coding modes (2714) may be based on the number of points of the portion of the geometry (2711).

[0344] For example, the initial list of candidate attribute coding modes (2714) may comprise intra-prediction based coding modes predicting attributes associated with the portion of geometry (2711) by extrapolating attributes from at least one neighboring portion of geometry of the set of portions of geometry along different spatial directions and wherein the number of intra-prediction based coding modes in the list of candidate attribute coding modes (2712) may be based on the number of points of the portion of the geometry (2711).

[0345] For example, the pruning the initial list of candidate attribute coding modes (2714) may be based on a comparison of the number of points of the portion geometry (2711) with a threshold.

[0346] For example, the list of candidate attribute coding modes (2714) may comprise only light-weight candidate coding modes when the number of points of the portion geometry (2711) is below the threshold.

[0347] For example, the encoder may encode, in the bitstream (2590), the threshold as part of mode information (2542).

[0348] For example, the decoder may decode, from the bitstream (2690), the threshold as part of mode information (2631).

[0349] For example, one light-weight candidate coding mode may be an intra-prediction based attribute coding mode predicting attributes associated with the portion of geometry (2711) by calculating an average or a maximum of attributes from at least one neighboring portion of geometry of the set of portions of geometry.

[0350] For example, one light-weight candidate coding mode may be an attribute skip mode indicating the attributes associated with points of the portion of geometry (2711) equal attribute predictors based on corresponding projected attributes based on attributes of the reference point cloud for attributes (2713).

[0351] For example, the projected attributes are obtained as discussed in FIG. 14.

[0352] In some embodiments, the mode information (2542, 2631) may be entropy encoded / decoded in / from the bitstream (2590, 2690) based on the set of portions of geometry.

[0353] When the mode information (2542, 2631) is a binary value, the mode information is directly entropy encoded / decoded by a context-adaptive entropy coder using contexts.

[0354] When the mode information (2542, 2631) is not a binary value, the mode information (2542, 2631) may be binarized into a set of bits and each bit of the set of bits may be entropy encoded / decoded by a context-adaptive entropy coder using contexts.

[0355] In some embodiments, the entropy encoding / decoding the mode information (or a bit of the set of bits representing the mode information) may comprise selecting a context from a set of contexts based on the portion of the geometry (2522, 2622).

[0356] For example, the context may be selected from a set of contexts based on the number of points of the portion of geometry (2522, 2622).

[0357] For example, the context may be selected from a set of contexts based on projection information based on a comparison of the portion of geometry (2711) with a geometry of the reference point cloud for attributes (2713). For example, the projection information may comprise indication of a distance of projection and the selecting of a context from the set of contexts may be based on a comparison of the distance of projection with a threshold.

[0358] For example, the encoder may encode, in the bitstream (2590), the threshold as part of mode information (2542).

[0359] For example, the decoder may decode, from the bitstream (2690), the threshold as part of mode information (2631).

[0360] In some embodiments, at block 2510 of FIG. 25, the selecting, for the portion of geometry (2522), the attribute coding mode (2511) from the list of candidate attribute coding modes (2712), may be based on projection information obtained by comparing the portion of geometry (2522) with a geometry of the reference point cloud for attributes (2513) and attribute projection quality evaluated between the attributes associated with the portion of geometry (2522), i.e., mapped attributes (2531), and corresponding projected attributes based on attributes of the reference point cloud for attributes (2513).

[0361] For example, the projected attributes are obtained as discussed in FIG. 14.

[0362] For example, the projection information may comprise indication of a distance of projection.

[0363] In some embodiments, the selecting (at block 2510), for the portion of geometry (2522), the attribute coding mode (2511) from the list of candidate attribute coding modes (2712), may be based on rate / distortion optimization such as a candidate attribute coding mode with a smallest cost (Cmode) is selected from the list of candidate attribute coding modes (2712).

[0364] For example, the distortion Dmode of the rate / distortion optimization may be based on the distance of projection and / or the attribute projection quality.

[0365] For example, the bitrate Rmode of the rate / distortion optimization is evaluated as being a number of bits require to encode all information used to obtain attributes associated with the portion of geometry.

[0366] In some embodiments, the projected attributes may be obtained by projection of attributes of a motion compensated geometry onto the portion of geometry (2711) and the motion compensated geometry may be obtained by motion compensation of the geometry of the reference point cloud for attributes (2713), e.g., as described above with respect to FIG. 28A.

[0367] In some embodiments, the projected attributes may be obtained by projection of attributes of a motion compensated geometry onto the geometry of the reference point cloud for attributes (2713) and the motion compensated geometry may be obtained by motion compensation of the portion geometry (2711), e.g., as described above with respect to FIG. 28B.

[0368] In some embodiments, the distance of projection may be based on point-to-point projection distances calculated for all the points of the portion of geometry (2522, 2622, 2711). In some embodiments, the distance of projection may be an average or a maximum of the point-to- point projection distances.

[0369] In some embodiments, each point-to-point projection distance may be calculated between one point of the portion geometry (2522, 2622, 2711) and its nearest neighbor point of a first motion compensated geometry obtained by performing motion compensation of the geometry of the reference point cloud for attributes (1122, 1322, 2713).

[0370] In some embodiments, the first motion compensated geometry may be obtained by motion compensation of the geometry of the reference point cloud for attributes based on MV field.

[0371] FIG. 28A illustrates an example of point-to-point projection distance between a point of a portion of the decoded geometry (2812) and its nearest neighbor points of a motion compensated geometry (2804), according to some embodiments.

[0372] The motion compensated geometry (2804) is obtained by motion compensation of the reference point cloud for attributes (2813) based on MV field (2811).

[0373] In some examples, the reference point cloud for attributes (2813) may be the reference point cloud for attributes (1122, 1322, 2713). The portion of the decoded geometry (2812) may be the portion of geometry (2522, 2622, 2711).

[0374] For example, MV field (2811) may include a set of motion vectors including a motion vector (MV) used to translate reference point (2815) (rl) of the reference point cloud for attributes (2813) to a reference point (2814) (rl’) of the motion compensated geometry (2804). Then the nearest point of the motion compensated geometry (2804), which may include reference point (2814), in a neighborhood of the point (2816) of the portion of geometry (2812) may be selected in a search (2818) by minimizing a point-to- point projection distance between each candidate point of the motion compensated geometry (2804) in the neighborhood of the point (2816) and the point (2816). As described above, discontinuities of the motion compensated geometry (2804) may be introduced due to MV field (2811) which may not provide a granular translation of points. For example, MV field (2811) may include one MV applied to reference point cloud for attribute (2813) or an MV determined for a set of cuboids or per cuboid of reference point cloud for attributes (2813), but not per point of reference point cloud for attributes (2813) due to high complexity. Also since search (2818) is performed on points of the motion compensated geometry (2804), the entirely of the motion compensated geometry (2804) needs to be generated and maintained before search (2818) for each point of decoded geometry (2812) can be performed.

[0375] For example, the point-to-point projection distance may be calculated between a point of the portion of the decoded geometry (2812) and its nearest neighbor point of a motion compensated geometry (2804). In some embodiments, each point-to-point projection distance may be a difference between a point of the reference point cloud for attributes (2813) and its nearest neighbor point of a motion compensated geometry (2924).

[0376] For example, the motion compensated geometry (2924) may be obtained by performing motion compensation of the portion of the decoded geometry (2812).

[0377] In some embodiments, the second motion compensated geometry is obtained by motion compensation of the geometry of the current point cloud based on MV field.

[0378] FIG. 28B illustrates an example of point-to-point projection distance between a point (2832) of the reference point cloud for attributes (2813) and its nearest neighbor point of a motion compensated geometry (2824), according to some embodiments.

[0379] The motion compensated geometry (2824) is obtained by motion compensation of the decoded geometry (2812) based on MV field (2821). For example, MV field (2821) may include a motion vector (- MV) that is the inverse (e.g., having an opposite sign) as that in MV field (2811).

[0380] For example, point (2816) of the decoded geometry (2812) may be translated by a motion vector (- MV) of MV field (2820) to determine a motion-compensated position for point (2816) and shown as point (2826) (p ’ ) of the motion compensated geometry (2824). The nearest point of the motion compensated geometry (2824), which may include point (2826), in a neighborhood of the point (2832) of the reference point cloud for attributes (2813) may be selected in a search (2828) by minimizing a point-to-point projection distance between each candidate point of the motion compensated geometry (2824) in the neighborhood of the point (2832) and the point (2832) of the reference point cloud for attributes (2813).

[0381] In some embodiments, the attribute projection quality may be determined based on a comparison of the mapped attributes and the corresponding projected attributes. The attribute projection quality determining may be performed by the comparison of attributes expressed on a same geometry (i.e., the decoded geometry (2812)) to avoid any geometry discrepancy. In some examples, the attribute projection quality may be based on differences between compared attributes. An attribute may be represented as a vector, so an attribute difference may be computed as an attribute distance between vectors representing attributes that are compared. Thus, attribute distance and attribute difference are used interchangeably herein.

[0382] In some embodiments, the attribute projection quality may be based on point-to-point attribute distances calculated for the set of points of the portion of geometry.

[0383] In some embodiments, the attribute projection quality may be an average or a maximum of the point- to-point attributes distances. For example, a point-to-point attribute distance may be a difference between attributes associated with a point of the set of points of the portion of geometry and corresponding projected attributes associated with this point.

[0384] FIG. 29 illustrates a flowchart 2900 of an example method for encoding attributes of a point cloud based on selected attribute coding mode, according to some embodiments.

[0385] At block 2910, a geometry of a current point cloud is segmented into a set of portions of geometry, each portion of geometry comprising at least one point of the current point cloud.

[0386] At block 2920, for each portion of geometry of the set of portions of geometry, an attribute coding mode is selected based on the each portion geometry.

[0387] At block 2930, attributes associated with the each portion of geometry are encoded based on the selected attribute coding mode.

[0388] FIG. 30 illustrates a flowchart 3000 of an example method for decoding attributes of a point cloud based on selected attribute coding mode, according to some embodiments.

[0389] At block 3010, a geometry of a current point cloud is segmented into a set of portions of geometry, each portion of geometry comprising at least one point of the current point cloud.

[0390] At block 3020, for each portion of geometry of the set of portions of geometry, an attribute coding mode is selected based on the each portion geometry.

[0391] At block 3030, attributes associated with the each portion of geometry are decoded based on the selected attribute coding mode.

[0392] Embodiments of the present disclosure may be implemented in hardware using analog and / or digital circuits, in software, through the execution of instructions by one or more general purpose or specialpurpose processors, or as a combination of hardware and software. Consequently, embodiments of the disclosure may be implemented in the environment of a computer system or other processing system. An example of such a computer system 3100 is shown in FIG. 31. Blocks depicted in the figures above, such as the blocks in FIGS. 1, 6, 10-14, 17-19, and 21-22 may execute on one or more computer systems 3100. Furthermore, each of the steps of the flowcharts depicted in this disclosure may be implemented on one or more computer systems 3100. When more than one computer system 3100 is used to implement embodiments of the present disclosure, the computer systems 3100 may be interconnected by one or more networks to form a cluster of computer systems that may act as a single pool of seamless resources. The interconnected computer systems 3100 may form a “cloud” of computers.

[0393] Computer system 3100 includes one or more processors, such as processor 3104. Processor 3104 may be, for example, a special purpose processor, general purpose processor, microprocessor, or digital signal processor. Processor 3104 may be connected to a communication infrastructure 3102 (for example, a bus or network). Computer system 3100 may also include a main memory 3106, such as random access memory (RAM), and may also include a secondary memory 3108.

[0394] Secondary memory 3108 may include, for example, a hard disk drive 3110 and / or a removable storage drive 3112, representing a magnetic tape drive, an optical disk drive, or the like. Removable storage drive 3112 may read from and / or write to a removable storage unit 3116 in a well-known manner. Removable storage unit 3116 represents a magnetic tape, optical disk, or the like, which is read by and written to by removable storage drive 3112. As will be appreciated by persons skilled in the relevant art(s), removable storage unit 3116 includes a computer usable storage medium having stored therein computer software and / or data.

[0395] In alternative implementations, secondary memory 3108 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 3100. Such means may include, for example, a removable storage unit 3118 and an interface 3114. Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a thumb drive and USB port, and other removable storage units 3118 and interfaces 3114 which allow software and data to be transferred from removable storage unit 3118 to computer system 3100.

[0396] Computer system 3100 may also include a communications interface 3120. Communications interface 3120 allows software and data to be transferred between computer system 3100 and external devices. Examples of communications interface 3120 may include a modem, a network interface (such as an Ethernet card), a communications port, etc. Software and data transferred via communications interface 3120 are in the form of signals which may be electronic, electromagnetic, optical, or other signals capable of being received by communications interface 3120. These signals are provided to communications interface 3120 via a communications path 3122. Communications path 3122 carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link, and other communications channels.

[0397] Computer system 3100 may also include one or more sensor(s) 3124. Sensor(s) 3124 may measure or detect one or more physical quantities and convert the measured or detected physical quantities into an electrical signal in digital and / or analog form. For example, sensor(s) 3124 may include an eye tracking sensor to track the eye movement of a user. Based on the eye movement of a user, a display of a point cloud may be updated. In another example, sensor(s) 3124 may include a head tracking sensor to the track the head movement of a user. Based on the head movement of a user, a display of a point cloud may be updated. In yet another example, sensor(s) 3124 may include a camera sensor for taking photographs and / or a 3D scanning device, like a laser scanning, structured light scanning, and / or modulated light scanning device. 3D scanning devices may determine geometry information by moving one or more laser heads, structured light, and / or modulated light cameras relative to the object or scene being scanned. The geometry information may be used to construct a point cloud.

[0398] As used herein, the terms “computer program medium” and “computer readable medium” are used to refer to tangible storage media, such as removable storage units 3116 and 3118 or a hard disk installed in hard disk drive 3110. These computer program products are means for providing software to computer system 3100. Computer programs (also called computer control logic) may be stored in main memory 3106 and / or secondary memory 3108. Computer programs may also be received via communications interface 3120. Such computer programs, when executed, enable the computer system 3100 to implement the present disclosure as discussed herein. In particular, the computer programs, when executed, enable processor 3104 to implement the processes of the present disclosure, such as any of the methods described herein. Accordingly, such computer programs represent controllers of the computer system 3100.

[0399] In another embodiment, features of the disclosure may be implemented in hardware using, for example, hardware components such as application-specific integrated circuits (ASICs) and gate arrays. Implementation of a hardware state machine to perform the functions described herein will also be apparent to persons skilled in the relevant art(s).

Claims

CLAIMS:

1. A method of encoding a point cloud geometry, comprising: segmenting a geometry of a current point cloud into a set of portions of geometry, wherein each portion of geometry comprises at least one point of the current point cloud; selecting, for each portion of geometry of the set of portions of geometry, an attribute coding mode based on each portion geometry; and encoding attributes associated with each portion of geometry based on the selected attribute coding mode.

2. A method of decoding a point cloud geometry, comprising: segmenting a geometry of a current point cloud into a set of portions of geometry, wherein each portion of geometry comprises at least one point of the current point cloud; selecting, for each portion of geometry of the set of portions of geometry, an attribute coding mode based on each portion geometry; and decoding attributes associated with each portion of geometry based on the selected attribute coding mode.

3. The method of claim 1 or 2, wherein the step of selecting, for a portion of geometry, an attribute coding mode is performed based on a number of points of the portion of geometry.

4. The method of claim 1 or 2, further comprising the step of: selecting, for a portion of geometry, an inter-prediction based attribute coding mode as being the selected attribute coding mode based on projection information based on a comparison of the portion of geometry with a geometry of a reference point cloud for attributes.

5. The method of claim 1 or 2, wherein the attribute coding mode is selected from a list of candidate attribute coding modes.

6. The method of claim 5, wherein the list of candidate attribute coding modes is obtained by pruning an initial list of candidate attribute coding modes.

7. The method of claim 6, wherein the initial list of candidate attribute coding modes comprises at least one intra-prediction based attribute coding mode.

8. The method of claim 6, wherein the initial list of candidate attribute coding modes comprises at least one inter-prediction based attribute coding mode.

9. The method of claim 6, wherein the pruning the initial list of candidate attribute coding modes is based on projection information based on a comparison of the portion of geometry with a geometry of a reference point cloud for attributes.

10. The method of claim 6, wherein the pruning of the initial list of candidate attribute coding modes is based on the portion of the geometry or the number of points of the portion of the geometry.

11. The method of claim 10, wherein the list of candidate attribute coding modes comprises only lightweight candidate coding modes when the number of points of the portion geometry is below the threshold, and the light-weight candidate coding mode is attribute skip mode indicating the attributes associated with points of the portion of geometry equal attribute predictors based on corresponding projected attributes.

12. The method of claim 5, wherein selecting, for the portion of geometry, the attribute coding mode from the list of candidate attribute coding modes, is based on projection information based on a comparison of the portion of geometry with a geometry of a reference point cloud for attributes and attribute projection quality evaluated between the attributes associated with the portion of geometry and corresponding projected attributes based on attributes of the reference point cloud for attributes.

13. The method of claim 1 or 2, wherein the segmenting the geometry of the current point cloud comprises obtaining a set of Attribute Coding Units (ACUs), each ACU being associated with a volume comprising one of the portion geometry of the set of portions of geometry.

14. A device comprising one or more processor configured to: segment a geometry of a current point cloud into a set of portions of geometry, wherein each portion of geometry comprises at least one point of the current point cloud;select, for each portion of geometry of the set of portions of geometry, an attribute coding mode based on each portion geometry; and encode or decode attributes associated with each portion of geometry based on the selected attribute coding mode.

15. A computer program product comprising computer program code means which, when executed on a computing device having a processing system, cause the processing system to perform all of the steps of the method according to any of claims 1 to 13.

Images