WO2025214850A1

WO2025214850A1 - Encoding and decoding the octree information

Info

Publication number: WO2025214850A1
Application number: PCT/EP2025/059017
Authority: WO
Inventors: Jonathan Gaël Yoann TAQUET; Sébastien Lasserre
Original assignee: Koninklijke Philips NV
Current assignee: Koninklijke Philips NV
Priority date: 2024-04-09
Filing date: 2025-04-02
Publication date: 2025-10-16
Anticipated expiration: 2026-10-09
Also published as: TW202545198A

Abstract

Concepts for encoding and decoding octree information are disclosed. In an encoding method, a diced point cloud frame is obtained, with a first volume having a length along a direction equal to a power of two, based on dicing a second volume of a point cloud frame along the direction to correspond a length, in the direction, of a sub-volume of the second volume to a length, in the direction, of a leaf node of an occupancy octree representing a space-partitioning of the first volume, the length of the leaf node being equal to a power of two and being greater than or equal to the length of the sub-volume; based on the first volume of the diced point cloud frame, the occupancy octree is obtained based on iteratively dividing volumes, of the first volume, that contain at least one point of the diced point cloud frame, a leaf node of the occupancy tree is occupied indicates a volume, associated with the leaf node and having a length in the direction equal to the length of the sub-volume, contains a portion of the diced point cloud frame; and in a bitstream, octree information representing the occupancy octree is encoded. Also provided are an encoder and a decoder for encoding and decoding octree information.

Description

ENCODING AND DECODING THE OCTREE INFORMATION

FIELD OF THE INVENTION

The invention relates to encoding and decoding of octree information representing occupancy tree, e.g. occupancy octree, which represents a point cloud geometry. In particular, the invention relates to dicing/undicing a point cloud and obtaining an occupancy octree based on the diced point cloud frame.

BACKGROUND OF THE INVENTION

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.

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.

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.

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.

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.

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 learningbased 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.

SUMMARY OF THE INVENTION

To improve the encoding and decoding the occupancy free, e.g. occupancy octree, representing a point cloud geometry, the present embodiments set out to remedy at least one of the drawbacks of the prior art with a method of encoding octree information, comprising obtaining a diced point cloud frame, with a first volume having a length along a direction equal to a power of two, based on dicing a second volume of a point cloud frame along the direction to correspond a length, in the direction, of a sub-volume of the second volume to a length, in the direction, of a leaf node of an occupancy octree representing a space-partitioning of the first volume, the length of the leaf node being equal to a power of two and being greater than or equal to the length of the sub-volume; obtaining, based on the first volume of the diced point cloud frame, the occupancy octree based on iteratively dividing volumes, of the first volume, that contain at least one point of the diced point cloud frame, wherein a leaf node of the occupancy tree being occupied indicates a volume, associated with the leaf node and having a length in the direction equal to the length of the sub-volume, contains a portion of the diced point cloud frame; and encoding, in a bitstream, octree information representing the occupancy octree.

Also disclosed is a method of decoding octree information, comprising decoding, from a bitstream, octree information representing an occupancy octree representing a space-partitioning of a first volume having a length along a direction equal to a power of two, wherein a leaf node of the occupancy octree being occupied indicates a volume associated with the leaf node contains a portion of a point cloud frame; and obtaining an undiced occupancy octree, representing a space-partitioning of a second volume of the point cloud frame, based on undicing the occupancy octree to correspond a length, in the direction, of a leaf node of the occupancy octree to a length, in the direction, of a sub-volume of the second volume.

Also provided is a video encoder comprising a circuit connected to a memory, wherein the circuit is arranged to obtain a diced point cloud frame, with a first volume having a length along a direction equal to a power of two, based on dicing a second volume of a point cloud frame along the direction to correspond a length, in the direction, of a sub-volume of the second volume to a length, in the direction, of a leaf node of an occupancy octree representing a space-partitioning of the first volume, the length of the leaf node being equal to a power of two and being greater than or equal to the length of the sub-volume; obtain, based on the first volume of the diced point cloud frame, the occupancy octree based on iteratively dividing volumes, of the first volume, that contain at least one point of the diced point cloud frame, wherein a leaf node of the occupancy tree being occupied indicates a volume, associated with the leaf node and having a length in the direction equal to the length of the sub-volume, contains a portion of the diced point cloud frame; and encode, in a bitstream, octree information representing the occupancy octree.

Also provided is a video decoder comprising a circuit connected to a memory, wherein the circuit is arranged to decode, from a bitstream, octree information representing an occupancy octree representing a space-partitioning of a first volume having a length along a direction equal to a power of two, wherein a leaf node of the occupancy octree being occupied indicates a volume associated with the leaf node contains a portion of a point cloud frame; and obtain an undiced occupancy octree, representing a space-partitioning of a second volume of the point cloud frame, based on undicing the occupancy octree to correspond a length, in the direction, of a leaf node of the occupancy octree to a length, in the direction, of a sub-volume of the second volume.

There is also provided a computer program product including instructions which, when the program is executed by one or more processors, causes the one or more processors to carry out all of the steps of any of the methods described above.

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.

BRIEF DESCRIPTION OF THE DRAWINGS

Examples of several of the various embodiments of the present disclosure are described herein with reference to the drawings. FIG. 1 illustrates an exemplary point cloud coding/decoding system in which embodiments of the present disclosure may be implemented.

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

FIG. 3 illustrates an example processing or scanning order for the first three level of an occupancy tree.

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

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

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.

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.

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

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 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 corresponding to a portion of a point cloud, according to some embodiments.

FIGS. 9A-B illustrate examples of voxelization.

FIG. 10 illustrates an example encoding process of occupancy bit of an occupancy word of a current node of an occupancy tree based on inter-frame prediction information, according to some embodiments.

FIG. 11 illustrates an example decoding process of occupancy bit of an occupancy word of a current node of an occupancy tree based on inter-frame prediction information, according to some embodiments.

FIGS. 12A-B illustrate examples of quantizers when the leaf node size B as well as the size of the quantization steps are both powers of two, according to some embodiments.

FIGS. 13A-B illustrate examples of the quantizing process for any leaf node size B and/or any length of the quantization step, according to some embodiments

FIGS. 14A-C illustrate examples of the quantizing process for any leaf node size B and/or any length of the quantization step, according to some embodiments.

FIGS. 15A-C illustrate examples of dequantizing distances determined between the middle position of the current edge and the centers of quantization intervals, according to some embodiments. FIG. 16 illustrates an example encoding process combining an occupancy octree encoding followed by a leaf node encoding with a leaf node length in each direction equals to a power of two, according to some embodiments.

FIG. 17 illustrates an example decoding process combining an occupancy octree decoding followed by a leaf node decoding with a leaf node length in each direction equal to powers of two, according to some embodiments.

FIG. 18 illustrates an example dicing and undicing process of a point cloud frame encompassed in a second volume, according to some embodiments.

FIG. 19 illustrates an example of the undicing of the occupancy octree, according to some embodiments.

FIG. 20 illustrates an example encoding process combining an occupancy octree encoding followed by a leaf node encoding with any leaf node length in each direction, according to some embodiments.

FIG. 21 illustrates an example decoding process combining an occupancy octree encoding followed by a leaf node encoding with any leaf node length in each direction, according to some embodiments.

FIG. 22 illustrates a flowchart of an example method for encoding from a bitstream a geometry of a point cloud, according to some embodiments.

FIG. 23 illustrates a flowchart of an example method for decoding from a bitstream a geometry of a point cloud, according to some embodiments.

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

DETAILED DESCRIPTION OF THE FIGURES

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.

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.

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.

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.

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.

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.

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).

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.

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. 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.

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.

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.

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.

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.

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. The encoder may represent or code the point cloud using an occupancy tree. 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 tree), 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.

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 subcuboid 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 free. The occupancy tree structure may continue to form in this manner for each recursive split iteration until, for example, a maximum depth level of the occupancy tree is reached or each occupied sub-cuboid has a volume corresponding to one voxel.

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 sub-cuboids 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.

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.

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. 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.

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.

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 sub-cubes 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.

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 subcubes. 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 sub-cube 304 and the occupancy word of the node corresponding to sub-cube 306.

Each of the four occupied sub-cubes 308, 310, 312, and 314 corresponds to a node in a third level of occupancy tree 300. The four occupied sub-cubes 308, 310, 312, and 314 are each further split into eight subcubes or 32 sub-cubes in total. Four third eight-bit occupancy words occW;, 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.

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.

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.

The number of possible occupancy configurations for a neighborhood of a current child cuboid may be 2^N, 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 context-based 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)).

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 2⁶ or 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 2²⁶ occupancy 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.

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).

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.

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.

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.

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.

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:

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 DR⁰ may 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 DRⁿ to an updated function DRⁿ⁺¹. The function may be defined by:

P’ = DRⁿ(P) = Pl ... Pkn® where k_n(P) 510 is the number of non-masked bits. The initialization of DR⁰ may 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 k_n(P) < k_n+i(P). The dynamic reduction function may be entirely determined by the values of k_n for all occupancy configurations p.

The visits to occupancy configurations may be tracked by a variable NV(P’) for all dynamically reduced occupancy configurations P’= DRⁿ(P). After the coding of an occupancy bit based on an occupancy configuration p^v, the corresponding number of visits NV(P^v’) may be increased by one. If this number of visits NV(P^v’) is greater than a threshold thv,

NV(p^v’) > th_v then the number of unmasked bits k_n(P) may be increased by one for all occupancy configurations P being dynamically reduced to p^v’. Practically, this corresponds to replacing the dynamically reduced occupancy configuration p^v’ by the two new dynamically reduced occupancy configurations P°’ and p¹’ defined by p°’ = p^v’O = p^vi ... P^^O and p¹’ = p^v’l = p^vi ... P .

In other words, the number of unmasked bits has been increased by one k_n+i(P) = k_n(P) + 1 for all occupancy configurations P such that DRⁿ(P) = p^v’. The number of visits of the two new dynamically reduced occupancy configurations may then be initialized to zero:

NV(p°’) = NV(p¹’) = 0. (I)

At the start of the coding, the initial number of visits for the initial dynamic reduction function DR⁰ may be set to

NV(DR°(p)) = NV(0) = 0, and the evolution of NV on dynamically reduced occupancy configurations may now be entirely defined. When a dynamically reduced occupancy configuration p^v’ is replaced by the two new dynamically reduced occupancy configurations P°’ and P¹’, the corresponding LUT entry LUT[p^v’] may be replaced by the two new entries LUT[P°’] and LUTfP¹’] that are initialized by the context index associated with p^v’,

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

The reduction function DRⁿ may be modeled by a series of growing binary trees Tⁿ 520 whose leaf nodes 530 are the reduced occupancy configurations P’ = DRⁿ(P). The initial tree may be the single root node associated with 0 = DR°(P). The replacement of the dynamically reduced to p^v’ by p⁰’ and p¹’ corresponds to growing the tree Tⁿ from the leaf node associated with p^v’ by attaching to it two new nodes associated with P°’ and P¹’. The tree Tⁿ⁺¹ may 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).

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 trees Tⁿ 520. An alternative to the storage of the frees may be to store the array k_n[P] 510 of the number of non-masked bits.

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.

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.

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’ = DRⁿ(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.

Although not shown in FIG. 6, the encoder and/or decoder may further update the reduction function DRⁿ into DRⁿ⁺¹ and 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.

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., down-sampling, 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.

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.

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.

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.

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. A neighborhood configuration PTS is derived based on presence flags (sk) and positions (pk) of vertices of neighboring already- coded edges of the current (TriSoup) edge and the occupancy of corresponding neighboring leaf nodes. The neighborhood configuration PTS may be dynamically reduced into a reduced configuration PTS’ = DR^H(PTS) by using a dynamic OBUF scheme for TriSoup. A context index LUT[PTS’] may be obtained from the OBUF LUT and at least a part of the vertex information of the current Tri Soup edge may be entropy coded using the context (or probability model) pointed to by the context index.

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 the current TriSoup edge may be binarized. A number of bits Nb may be set for the quantization of the TriSoup vertex position (pk) along the current TriSoup edge of length N that is uniformly partitioned into 2-''^h quantization 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) of the vertex on the current TriSoup edge. 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 (pk^J)) of the vertex information.

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.

FIG. 8B illustrates a refinement to the TriSoup model by coding a centroid residual vector C_res into the bitstream such as to use C+C_res instead of C as a pivoting vertex for constructing/generating the triangles. By doing so, the vertex C+C_res 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 C_res.

FIG. 8C illustrates a more detailed example of coding a centroid residual vector C_res in/from the bitstream such that an adjusted centroid C+C_res 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+C_res 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 C x V₂C + V₂C x V₃C + — I- V_KC x V_rC ^/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 a_res along the line (C, n) 810 may be coded instead of a 3D residual vector. res C(_resn

The residual value a_res may 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 a_res 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.

In some examples, the residual value a_re_Smay 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.

In some examples, the residual value a_res may be binarized and entropy coded into the bitstream, e.g., by using a unary -based coding scheme. In some examples, the residual value a_res may be coded using a set of flags. For example, a flag fo may be coded to indicate if the residual value a_res is equal to zero. If the flag fo indicates the residual value a_res is zero, no further syntax elements may be needed. If the flag fo indicates the residual value a_res is not zero, a sign bit indicating a sign may be coded and the residual magnitude |a_res|- 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 | a_res| is equal to ‘i’. A binary entropy coder may binarize the residual value a_res into the flags f (i>0) and entropy code the binarized residual value as well as the sign bit.

In some examples, compression of the residual value a_res may 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+C_res is located between the two bounding points 820 and 821. These bounding points 820 and 821 also bounds the residual value a_res (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 a_res may be inferred. For example, if m=M=0, then residual value a_res 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 a_res is not equal to zero and its sign is known, its magnitude |a_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> 1).

In some examples, the binary entropy coder used to code the binarized residual value a_res may 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 a_res 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.

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.

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 Pstart).

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.

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:

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.

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:

0 < u, v, w

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).

Presence flags (sk) and positions (pk) of TriSoup vertices can be efficiently entropy coded using neighboring information consisting in neighboring already -coded TriSoup edges (already -coded flags and positions of TriSoup vertices) and the occupancy of neighboring leaf nodes. Similar to the coding of the occupancy binary information of the occupancy tree, a TriSoup neighborhood configuration PTS is obtained and dynamically reduced into a reduced configuration TS’ = DR"(PTS) by using a dynamic OBUF scheme dedicated to TriSoup. Then, a coder index LUT[PTS’] is obtained from the OBUF Look-Up table and at least a part of the TriSoup data is coded using the binary entropy coder pointed by the coder index.

In order to use a binary entropy coder, the TriSoup vertex position (pk) along its TriSoup edge is binarized. Typically, a number of bits Nb is set for the quantization of the position along the TriSoup edge of length N that is uniformly divided into 2^Nb quantization intervals. By doing so, the position (pk) is represented by Nb bits (pk^J,j=l,. .. ,Nb)) that are individually coded by the dynamic OBUF scheme as well as the bit corresponding to the presence flag (sk). The neighborhood information PTS, the OFUF reduction function DRⁿ and thus the coder index do depend on the nature of the coded bit (presence flag (sk), highest position bit (pk¹), second highest position bit (pk²), etc.). Practically, there are several dynamic OBUF schemes, each of them being dedicated a specific TriSoup bit of information (presence flag (sk) or position bit (pk^J)).

The neighborhood information PTS of a current TriSoup edge may be obtained from the occupancy bits of the neighboring (relative to the current TriSoup edge) leaf nodes and from the vertex presence (sk ) and position (pk ) associated with neighboring (relative to the current TriSoup edge) already-coded TriSoup edges.

In video compression, performance may be improved by using inter-frame prediction. Bitrates needed to compress inter frames are typically one to two orders of magnitude lower than bitrates of intra frames that, by definition, do not use inter-frame prediction. Point cloud data may behave differently because the 3D geometry is coded, unlike video coding where typically only the attributes (e.g., colors) are coded after projection of the 3D geometry onto a 2D plane (e.g., a camera sensor). Even if 2D-projected attributes are expected to temporally have a higher correlation than their underlying 3D geometry, it is nevertheless expected that inter-frame prediction between 3D point clouds may provide improved compression capability than intra frame prediction alone within a point cloud frame. The octree may benefit from inter-frame prediction and geometry compression gains.

FIG. 10 illustrates an example encoding process 1000 of occupancy bit of an occupancy word of a current node of an occupancy tree based on inter-frame prediction information, according to some embodiments. For example, process 1000 may be performed by an encoder (e.g., encoder 114 of FIG. 1). In some examples, blocks 1020-1050 may represent components within the encoder.

The general framework of inter frame prediction for 3D point clouds is similar to the one of video compression, as depicted in FIG. 10 for the encoding process. A current frame (image or point cloud frame 1005) is coded relative to an already-coded reference frame 1010 (image or point cloud frame). A motion search 1020 is performed from the already -coded reference frame 1010 toward the current frame 1005 such as to obtain motion vectors 1021 that represent a motion flow between the two frames 1010 and 1005. In video compression, motion vectors are 2-component (or 2D) vectors representing the motion from reference blocks of pixels to current blocks of pixels. In point cloud compression, motion vectors are 3 -component (or 3D) vectors representing the motion from reference sets of 3D points to current sets of 3D points. Motion vectors 1021 are entropy encoded 1025 into a bitstream 1050. The reference frame 1010 is motion compensated 1030 to obtain a motion compensated frame 1031. Motion compensation involves moving the pixels (respectively points) of the reference image (respectively point cloud frame) according to the 2D (respectively 3D) motion vectors. The obtained motion compensated frame is “closer” to the current frame than the reference frame in the sense that the color difference (respectively point distance) between the motion compensated frame 1031 and the current frame 1005 is, on average, smaller than between the reference frame 1010 and the current frame 1005. In a next operation, inter-frame prediction at block 1040 is performed to obtain inter predictor 1041 based on the motion compensated frame 1031. Inter predictor 1041 is then used to drive the entropy encoding (at block 1045) of current frame information 1046 into the bitstream 1050 based on inter-frame predictive information.

FIG. 11 illustrates an example decoding process 1100 of occupancy bit of an occupancy word of a current node of an occupancy free based on inter-frame prediction information, according to some embodiments. For example, process 1100 may be performed by a decoder (e.g., decoder 120 of FIG. 1). In some examples, blocks 1125, 1130, 1140, and 1145 may represent components within the decoder.

The general framework of inter-frame prediction for 3D point clouds is similar to the one of video compression, as depicted in FIG. 11 for the decoding process. FIG. 11 illustrates a decoding process that decodes a bitstream 1050 encoded by the encoding method of FIG. 10 to obtain a decoded current frame 1110. Motion vectors 1121 are entropy decoded (1125) from the bitstream 1050. An already -coded reference frame 1110 is motion compensated (1130) using the decoded motion vectors 1121 to obtain a motion compensated frame 1131. Then, inter-frame prediction (at block 1140) is performed to obtain inter predictor 1041 based on the motion compensated frame 1031. Inter predictor 1041 is then used to drive the entropy decoding (e.g., at block 1145) of current frame information 1046 from the bitstream 1050. Finally, the decoded current frame 1110 is obtained based on the decoded current frame information.

In video coding, inter residuals are constructed as the difference of colors, pixel per pixel, between a current block of pixels belonging to the current frame (here image) and a co-located compensated block of pixels belonging to the motion compensated frame (here image). Inter residuals are then arrays of color differences that have typically small magnitude and thus may be efficiently compressed. Inter residuals based on the current frame 1005 and the motion-compensated frame 1031 may be entropy coded (encoded/decoded). Inter residuals may carry more compressible information than the current frame itself or the current frame that has undergone an intra prediction process. Therefore, the entropy coding (e.g., at block 1045 or block 1145) may be more efficient such as to obtain a bitstream 1050 with reduced size compared to a bitstream obtained by coding the current frame 1005 that has not benefited from inter-frame prediction.

In point cloud compression, there is no such concept as the “difference” between two sets of points and the concept of inter residual cannot be straightforwardly generalized to point clouds. For prediction of an occupancy tree, e.g. occupancy octree, representing a point cloud geometry, the concept of inter residual may be replaced by conditional entropy coding where conditional information for performing conditional entropy coding is constructed based on a motion-compensated point cloud frame. This may be extended to the framework of dynamic OBUF.

When coding the geometry of a point cloud frame using an occupancy tree (e.g., an occupancy octree), the inter predictor takes the form of inter-frame prediction information used as input to the dynamic OBUF process that selects an entropy coder to code an occupancy bit associated with a current node of the occupancy tree.

The motion field between trees (e.g., occupancy octrees) may be made of 3D motion vectors associated with 3D prediction units (PU) that have may include at least a part of one or several volumes (cuboids) associated with nodes at some depth of the occupancy tree. The motion compensation may be performed volume per volume based on the 3D motion vectors to obtain a motion-compensated point cloud per PU. The inter-frame prediction information of a current volume associated with a current node of the occupancy tree may be obtained based on the presence of at least one point of a motion-compensated point frame in the current volume.

As described hereinabove in relation with FIG. 6, a current occupancy bit of an octree may be coded by an entropy coder selected by the output of a dynamic OBUF LUT of coder indices that takes a neighborhood configuration P as input. The neighborhood configuration may be constructed using intraframe prediction information based on already-coded occupancy bits associated with neighboring volumes relative to the current volume associated with the current node whose occupancy is signaled by the current occupancy bit.

The construction of the neighborhood configuration P may be extended using inter-frame prediction information. An inter predictor occupancy bit may be defined for a current occupancy bit as a bit representative of the presence of at least one point of a motion-compensated point cloud frame within the current volume. In the case that motion compensation is efficient, a strong correlation between the current occupancy bit and the inter predictor occupancy bit may exist because the current and motion-compensated point cloud frames should be close to each other. Practically, using the inter predictor occupancy bit as a bit of the neighborhood configuration P may lead to better compression performance of the octree (e.g., dividing the size of the octree bitstream by a factor two).

The TriSoup scheme (such as defined for example in GPCCv2 and GeS-TM under development in MPEG SC29/WG7) may benefit from the motion-compensated frame obtained during the octree coding performed before the TriSoup coding. Inter predictors of the presence and position of TriSoup vertices may be obtained based on the motion-compensated point cloud frame. Basically, these predictors may be obtained based on the “intersection” of the motion-compensated point cloud frame with the edges of the TriSoup nodes. Predictors of the centroid residual values may also be obtained.

Therefore, the entropy coding of TriSoup vertices and centroid residual values may be performed by using these inter predictors. For example, inter predictors may constitute a part of a contextual information Pinter input of a dynamic OBUF instance that codes a TriSoup syntax element. In another example, a context may be selected based on inter predictors and the selected context may be used by an entropy coder like CABAC to obtain a probability used to arithmetically entropy code a TriSoup syntax element.

The positions of TriSoup vertices along edges of TriSoup nodes may be quantized before being coded. Quantization of the positions of Tri Soup vertices to a restricted number of possible positions along edges leads to a lower bitrate of coding of the positions with the drawback of higher distortion between the TriSoup model made of triangles based on the TriSoup vertices and the original point cloud geometry. Nevertheless, quantization of TriSoup vertices often leads to an improved tradeoff bitrate vs. distortion and better compression capabilities.

The TriSoup scheme (such as defined for example in GPCCv2 and GeS-TM under development in MPEG SC29/WG7) have limited quantization capabilities that impose that the size B of a TriSoup node as well as the size of the quantization steps used for quantizing the positions of TriSoup vertices along TriSoup edges to be both powers of two.

FIGS. 12A-B illustrate examples of a quantizer when the TriSoup node size B as well as the size of the quantization steps are both powers of two.

FIG. 12A illustrates edges 1200 of length B=8 belonging to TriSoup nodes of size 8x8x8. FIG. 12B illustrates edges 1201 of length B=4 belonging to TriSoup nodes of size 4x4x4. A parameter Nb signals the number of quantization bits allowed for signaling the quantized positions of the TriSoup vertices along edges. Quantization is uniform over edges and quantization steps cannot be smaller than a voxel. Consequently, for TriSoup nodes having size B=2^N, the number Nb of quantization bits must be smaller than N. FIG. 12A illustrates the quantization process for Nb = 3, 2, 1 and 0 when B=8; and FIG. 12B illustrates the quantization process for Nb = 2, 1 and 0 when B=4.

Edges are represented by segments [-0.5, B-0.5], By definition, points 1210 (white circles) of the point cloud geometry have integral coordinates (xv,yv,zv) and are associated with 3D voxels being cubes of size Ixlxl centered at (xv,yv,zv). The edges (1200, 1201) are divided uniformly into a number 2^Nb of quantization intervals 1220 each of same length 2^{N Nb} for Nb < N. The quantization intervals are associated with codewords 1230 belonging to the set {0; . . . ; 2^Nb -1}. The position pk of a TriSoup vertex along an edge k (1200,1201) is a value in the segment [-0.5, B-0.5] that is quantized into a codeword pk,Nb associated with the quantization interval this value belongs to. Dequantized positions 1240 (gray dots) obtained from codewords P Nb may be the middle of the quantization interval associated with the codewords pk,Nb.

The TriSoup vertex information of Trisoup vertex along the current edge (k) is then made of the (decoded) presence flag (sQ of the TriSoup edge (k) and the dequantized position (pDQ,k) of TriSoup vertex on the TriSoup edge (k).

It has been proposed to obtain better granularity for TriSoup node size B and for quantization of vertex positions over TriSoup edges by introducing a particular quantization process for the TriSoup edges. This particular quantization process can handle any length of edges (and thus allows for any size B of TriSoup node) and uniform quantization by intervals of any length.

FIGS. 13A-B and FIGS. 14A-C illustrate the quantizing process for any TriSoup node size B and/or any length of the quantization step.

In FIG. 13A, the edge (k) is represented by a thick line 1300. The edge (k) has length B that is any integral number not necessarily a power of two. Without loss of generality, it is assumed that the edge (k) is a segment [-0.5; B-0.5] along the coordinate axis parallel to the edge (k). Points 1310 of the point cloud in a TriSoup node that neighbors the edge (k) (line 1300) have integral coordinate between 0 and B-l along the axis. For example, in the case of cubic TriSoup nodes, points in the TriSoup node may belong to the grid {0; . . . ; B-l}³ within the cube [-0.5; B-0.5]³ defining the volume of the TriSoup node. The middle position 1320 of the edge (k) (line 1300) has coordinate (B-l)/2 in the segment [-0.5; B-0.5] defining the edge (k). The edge (k) (linel300) is thus split into two equal parts: a left half edge 1330 and a right half edge 1331. The left half edge 1330 is defined by the segment [-0.5; B/2-0.5[ starting from the lower bound (-0,5) of the edge (k) (line 1300) and ending at the middle position (B/2-0,5) of the edge (k) (line 1300). The right half edge 1331 is defined by the segment [B/2-0.5; B-0.5] starting from the middle position (B/2-0.5) of the edge (k) (line 1300) and ending at the upper bound (B-0.5) of the edge (k) (line 1300).

A TriSoup vertex located on the edge (k) (line 1300) has coordinate (p_k) in the segment [-0.5; B-0.5], Quantizing the position (pQ of Tri Soup vertex according to some embodiments of the present disclosure firstly involves determining whether a position (p_k) of the TriSoup vertex is on a first half or a second half of the current edge (k). Therefore, the bit (bt) indicates if the TriSoup vertex position (p_k) belongs to either the left half edge 1330 (for example, bi_r = 0) or the right half edge 1331 (for example, bir = 1).

Secondly, a distance (d_p) is determined between the middle position 1321 of the edge (k) (line 1300) as illustrated by FIG. 13B and the position (p_k) of the TriSoup vertex and the distance (d_P) is quantized as illustrated in FIGS. 14A-C.

In FIG. 13B, the distance (d_p) belongs to an interval of definition defined as a segment [0; B/2] illustrated by a thick line 1340. The lower bound 0 represents the middle position 1321 of the edge.

For example, the distance d_p may be determined as the absolute difference between the middle position 1321 of the current edge (k) and the position (p_k) of the TriSoup vertex: d_P = | p_k - (B-l)/2|

Assuming the position (p_k) of the TriSoup vertex has been determined by points of the point cloud belonging to TriSoup nodes intersecting entirely the edge (k) (line 1300), the distance (d_p) is not higher than B/2-0.5 corresponding to the farthest points 1311 from the middle position 1321 of the edge (k).

FIGS. 14A-C illustrate examples of quantizing the distance (d_p). The distance (d_p) is quantized for three examples of quantization step Q_s 1400 (FIG. 14A), 1401 (FIG. 14B) and 1402 (FIG. 14C). For example, the segment [0; B/2] over which the distance (d_p) may be uniformly partitioned into quantization intervals, starting from its lower bound 0 until a last interval of quantization 1410 (FIG. 14A), 1411 (FIG. 14B) and 1412 (FIG. 14C) containing the upper bound B/2-0.5. The distance (d_p) between the middle position 1421 and the position (pQ of the TriSoup vertex may then be quantized into N_s quantization intervals [0, Q_s], [Q_s, 2Q_S], . . . , [(N_S-1)Q_S, N_SQ_S]. A codeword may be associated with each interval [kQ_s, (k+l)Q_s],

The codeword C_p,k indicating the distance (d_p) from the middle position of the current edge (k) and the position (pQ of the TriSoup vertex is associated with the quantization interval the distance (d_p) belongs to.

The distance (d_p) may be quantized into the codeword C_p,k associated with the quantization interval the distance (d_p) belongs to.

The number N_s of possible codewords may thus be determined as the unique integer that fulfills the equalities (N_S-1)Q_S < d_p <N_SQ_S.

The position (p0 of the TriSoup vertex belonging to a TriSoup edge is thus quantized into a bit bir and a codeword C _p,k for a given quantization step Q_s.

FIGS. 15A-C illustrate examples of dequantizing distances determined between the middle position of the current edge and the centers of quantization intervals.

FIG. 15 A illustrates the dequantizing of distances dDQ,k as the centers of the quantization intervals such that: dDQ.k(C_P.k, Qs) = (C_P,k + 0.5) Qs

Once the dequantization distance dDQ,k is obtained, the dequantized position pDQ,k of the TriSoup vertex is determined by the formula

PDQ.k = (B-l)/2 - dDQ,k if blr = 0, PDQ.k = (B-l)/2 + dDQ,k if blr = 1.

Determining the distance dDQ,k associated with the last quantization interval [(N_S-1)Q_S, N_SQ_S[ based on the center of the last interval may not be optimal as illustrated in FIG. 15B. The distance d_p may only belong to the subinterval 1520 (vertical stripes) at the left of the coordinate B/2 - 0.5 and not to the subinterval 1521 (horizontal stripes) at the right of the coordinate B/2 - 0.5. The dequantized distance dDQ,k (1511) of the last quantization interval may thus belong to the left subinterval [(N_s-1) Q_s, B/2 - 0.5],

For example, the dequantized distance dDQ,k (1511) of the last quantization interval may be the middle position of the left subinterval [(N_s-1) Q_s, B/2 - 0.5], i.e. d_DQ,k(N_s-l, Q_s) = ((Ns-1) Q_s + B/2 - 0.5 )/2.

It has been observed from statistics on the positions of TriSoup vertices that the distribution of distances (d_p) tends to peak near the bound B/2 - 0.5. Consequently, the distance dDQ,k (1512, FIG. 15C) of the last interval of quantization may be located at the right of the middle position of the left subinterval [(N_s-1) Qs, B/2 - 0.5], For example, the distance dDQ,k (1312) may be obtained by d_DQ(N_s-l, Q_s) = ( (N_s-1) Q_s+ 3*(B/2 - 0.5) )/4.

FIG. 16 and FIG. 17 show an encoding process and a decoding process, respectively, of an example implementation of lossy coding the geometry of a point cloud.

FIG. 16 illustrates an encoding process 1600 that combines an occupancy octree encoding (e.g., at block 1610) followed by a leaf node encoding (e.g., at block 1620) where leaf node lengths in each direction (e.g., each dimension of cuboid corresponding to the leaf node) are powers of two. 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.

In particular, each leaf node of the occupancy octree may be associated with a cuboid having the same edge length S in all directions. The cuboid has a size equal to (S)³, i.e., the edge length of the cuboid equals 2^N in each of the three directions (e.g., each of the three dimensions of the cuboid).

In particular, leaf nodes of the occupancy octree may be associated with cuboids having all same edge length S being equal to a same power of two.

The encoding process encodes information representing the geometry of a point cloud frame 1611 (e.g., also referred to as a point cloud) into a bitstream (1690).

At block 1610, an occupancy octree is encoded by encoding octree information (1613) into the bitstream (1690).

The occupancy octree is determined based on a point cloud frame (1611) and a root node size (1612) defining, typically, a volume (e.g., a cube or a cuboid) having a length equal to a power of two (2^N) in each direction. A root node size equal to (2^N)³ indicates the associated volume is a cube having a length edge equal to 2^N. The volume associated with the root node encompasses the point cloud frame (1611) and is associated with the root node of the occupancy octree.

The occupancy octree is determined by dividing each occupied (i.e., that contains at least one point of the point cloud frame 1611 in its associated volume) node into 8 child-nodes associated with volumes, having all the same size, that partition equally the volume associated with the each occupied node. By doing so, all volumes (e.g., cubes or cuboids) associated with nodes of the occupancy octree have edge lengths that are powers of two in each direction.

The division of occupied nodes is performed until some fixed maximum depth (or equivalently some fixed minimum size of volumes) is reached. The occupied leaf nodes become leaf nodes (1615) that contain, by definition, each a portion (1614) of the point cloud frame in their associated volumes.

At block 1620, a leaf node encoding scheme encodes, based on the point cloud per leaf node (1614) and leaf nodes (1615), leaf node information (1621) into the bitstream (1690).

For example, leaf node information (1621) may be TriSoup node information when the geometry of the portion of the point cloud contained in the volumes associated with the leaf node is encoded by a TriSoup scheme. Occupied leaf nodes are then TriSoup nodes. For each TriSoup node of the occupancy tree, TriSoup node information comprises 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 information. In a variant, the TriSoup node information may further comprise a residual value a_res per TriSoup node.

Leaf node information (1621) represents the geometry of the portion (1614) of the point cloud frame contained in each of the leaf nodes (1615).

The octree information (1613), encoded into the bitstream (1690), may include at least the occupancy information signaling whether or not each node of the occupancy octree is occupied (i.e., that contains at least one point of the point cloud frame 1611 in its associated volume).

Improved compression of the octree information (1613) may be obtained by using a reference point cloud frame (1632) (e.g., also referred to as a reference point cloud) to predict the occupancy information. The reference point cloud frame (1632) may typically be an already -coded point cloud frame, i.e., a point cloud frame that is before the point cloud frame 1611 in the point cloud sequence 108 (FIG. 1).

In a variant of the encoding process 1600, at block 1630, motion vectors (1633) are searched for each prediction unit (PU) from the reference point cloud frame (1632) to the portion (1631) of the point cloud frame (1611) in the PU.

Each PU contains motion vectors (1633) representative of the 3D local motion in the PU from the reference point cloud frame (1632) to the portion (1631) of the point cloud frame (1611) in the PU. PU structure and motion vectors (1633) are also encoded in the bitstream (1690) as part of the octree information (1613).

At block 1640, for each PU, a motion-compensated point cloud (1642) is obtained by motion compensation of the reference point cloud frame (1632) according to motion vectors (1633) associated with the PU.

In the variant, at block 1610, prediction of occupancy of the nodes of the occupancy octree is obtained from the motion-compensated point clouds (1642) associated with the PUs (inter predictor occupancy bit, block 1040 of FIG. 10) and leads to more efficient entropy encoding of the occupancy information part of the octree information (1613) (e.g., block 1045 of FIG. 10).

In the variant, at block 1620, the leaf node encoding scheme encodes, based on the point cloud per leaf node (1614), leaf nodes (1615) and motion-compensated point cloud per leaf node (1616), leaf node information (1621) into the bitstream (1690).

A leaf node belongs to a PU and the motion-compensated point cloud (1616) for the leaf node is the motion-compensated point cloud (1642) associated with the PU. The motion-compensated point cloud per leaf node (1616) may be correlated with the point cloud per leaf node (1614) and the use of this correlation leads to more efficient entropy encoding of the leaf node information (1621).

FIG. 17 illustrates an example decoding process 1700 combining an occupancy octree decoding followed by a leaf node decoding with a leaf node length in each direction equal to powers of two, according to some embodiments. The process of FIG. 17 may include the same operations (shown as having the same labeled blocks) as those described in FIG. 16. Different from the process of FIG. 16, the process of FIG. 17 includes block 1710 and 1720. For example, process 1700 may be performed by a decoder (e.g., decoder 120 of FIG. 1). In some examples, blocks 1710 and 1720 may represent components within the encoder.

In particular, each leaf node of the occupancy octree may be associated with a cuboid having same edge length S in all directions, i.e. a cuboid having a size equal to (S)³, i.e. the edge length of the cuboid equals 2^N in each of the three directions.

The decoding process 1700 decodes information representing the geometry of a point cloud from a bitstream (1690) to obtain a decoded point cloud (1721) (e.g., also referred to as reconstructed point cloud or decoded/reconstructed point cloud frame). The bitstream (1690) may be obtained from the encoding method of FIG. 16.

At block 1710, an occupancy octree is constructed by decoding octree information (1613) from the bitstream (1690).

The occupancy octree is constructed based on the root node size (1612).

A volume, (e.g. a cube or cuboid) having the root node size, encompasses the point cloud (1721) and is associated with the root node of the occupancy octree.

The occupancy octree is constructed by dividing the root node into 8 child-nodes associated with volumes, having all same size, that partition equally the volume associated with the root node and then, based on the decoded octree information (1613), by dividing each occupied (i.e., as indicated by the decoded octree information (1613)) node into 8 child-nodes associated with volumes, having all same size, that partition equally the volume associated with the each occupied node. By doing so, all volumes (e.g., cubes or cuboids) associated with nodes of the occupancy octree have edge lengths that are powers of two in each direction. Based on the decoded octree information (1613), the occupancy octree is constructed until some fixed maximum depth (or equivalently some fixed minimum size of volumes) is reached.

The octree information (1613), decoded from the bitstream (1690), may include at least the occupancy information signaling whether or not each octree node is occupied (i.e., that contains at least one point of the point cloud 1721 to be decoded in its associated volume). At block 1720, a leaf node decoding scheme decodes leaf node information (1621) from the bitstream (1690) for each occupied leaf nodes (1615) of the occupancy octree (constructed at block 1710). Based on the decoded leaf node information (1621), the geometry of the portion of the decoded point cloud (1721) contained in each of the occupied leaf node (1615) of the occupancy octree is decoded.

For example, leaf node information (1621) may be TriSoup node information when the geometry of the portion of the point cloud contained in the volumes associated with the leaf node is encoded by a TriSoup scheme. Occupied leaf nodes are then TriSoup nodes. For each TriSoup node of the occupancy tree, the TriSoup node information comprises 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 information. In a variant, the TriSoup node information may further comprise a residual value a_res per TriSoup node.

Decoding of improved compression of the octree information (1613) may be obtained by using a reference point cloud frame (1632) to predict the occupancy information. The reference point cloud frame (1632) is typically an already-coded point cloud frame, i.e. a point cloud frame that is before the point cloud frame 1611 in the point cloud sequence 108 (FIG. 1).

In a variant of the decoding process, prediction units PU and motion vectors (1633) are decoded from the bitstream (1690). Each PU contains motion vectors (1633) representative of the 3D local motion in the PU from the reference point cloud frame (1632) to the portion (1631) of the point cloud frame (1611) in the PU.

At block 1640, for each PU, a motion-compensated point cloud (1642) is obtained by motion compensation of the reference point cloud frame (1632) according to the decoded motion vectors (1633) associated with the PU.

At block 1710, prediction of occupancy of the nodes of the occupancy octree is obtained from the motion-compensated point clouds (1642) associated with the PUs (inter predictor occupancy bit, block 1140 of FIG. 11) and leads to more efficient entropy decoding of the occupancy information part of the octree information (1613) (e.g., block 1145 of FIG. 11).

At block 1720, the leaf node decoding scheme decodes, based on the motion-compensated point cloud per leaf node (1616), leaf node information (1621) from the bitstream (1690) for each occupied leaf nodes (1615) of the occupancy octree (constructed at block 1710).

A leaf node belongs to a PU and the motion-compensated point cloud (1616) for the leaf node is the motion-compensated point cloud (1642) associated with the PU.

In the implementations of lossy coding of point cloud geometry, as described above with respect to FIGS. 16 and 17, due to the root node size being a power of two and the equal division of volumes into subvolumes, all volumes associated with occupancy octree nodes have a size that is a power of two in each direction. This allows for a very efficient bit-based implementation of the occupancy octree encoding and decoding. Having leaf node (e.g., TriSoup) node size S not being a power of two would lead to a root node of size 2^N*S, which is not a power of two, and lead to inefficient occupancy octree coding (1610, 1710) implementations. In some examples, for the TriSoup scheme, the TriSoup coding process (1620, 1720) may transparently handle TriSoup node sizes not being powers of two by implementing versatile quantization of TriSoup vertices on edges (e.g., as described in FIGS. 13A-B, 14A-C and 15). Therefore, efficient octree implementation remains an impediment towards the practical implementation of a leaf node scheme (e.g., TriSoup scheme) capable of handling any leaf node size S.

Embodiments of the present disclosure relate to dicing a point cloud and obtaining an occupancy octree based on the diced point cloud frame. This dicing scheme allows encoding/decoding octree information representing an occupancy octree whose nodes have sizes powers of two and leaf node information corresponding to leaf nodes of an undiced occupancy octree having any size, e.g., equal or not equal to powers of two.

FIG. 18 illustrates an example dicing and undicing process of a point cloud frame encompassed in a second volume 1820, according to some embodiments. In FIG. 18 and for illustration purposes only, the point cloud frame of three-dimensional (3D) points is represented as a set of two-dimensional (2D) points. The dicing and undicing process is applied to the 3D points being represented by 2D points. Block circles in FIG. 18 represent possible positions of points of the point cloud frame, i.e., some (occupied) block circles correspond to positions of points of the point cloud frame and others (unoccupied block circles) not. Block circles are typically located at the center of voxels.

The second volume 1820 may be divided into sub-volumes 1821 having each a length S in a same direction. A sub-volume 1821 may be a cuboid and in particular a cube of size S*S*S. In FIG. 18, the point cloud frame is divided into 3x3 sub-volumes of size 6x6.

A sub-volume containing at least one point of the point cloud frame may correspond to a volume associated with an occupied leaf node of an occupancy octree. The occupied leaf node may then be considered as being a TriSoup node and the geometry of the at least one point in the sub-volume may then be encoded by a TriSoup scheme.

When the length S of a sub-volume associated with an occupied leaf node of an occupancy octree (1822) is not a power of two, the occupied leaf node may be a TriSoup node and the geometry of the points contained in the sub-volume may be encoded using a TriSoup scheme. But, as explained above, encoding/decoding the occupancy octree with leaf node having size not equal to a power of two is not efficient.

Embodiments of the present disclosure relate to obtaining a diced point cloud frame, with a first volume (1810) having a length (2^S2*M) along a direction (e.g., a dimension of first volume 1810) equal to a power of two (M=3 in FIG. 18 for illustration only, but M should be a power of two M=2^N to ensure that the length is a power of two) based on dicing the second volume (1820) along the direction to correspond (e.g., map, convert, transform) a length (S), in the direction, of a sub-volume (1821) of the second volume 1820 to a length (2^s2), in the direction, of a leaf node 1811 of an occupancy octree representing a space-partitioning of the first volume (1810). The length of the leaf node (2^s2) equals to a power of two and is greater than or equal to the length of the sub-volume (2^S2> S).

Embodiments of the present disclosure further relate to obtaining, based on the first volume (1810) of the diced point cloud frame, an occupancy octree (1813) based on iteratively dividing (e.g., N times) volumes, of the first volume (1810), that contains at least one point of the diced point cloud frame. An occupied leaf node of the occupancy free indicates a volume 1812 (grey shaded area in FIG. 18), associated with the leaf node and having a length (S) in the direction equal to the length of the sub-volume, contains a portion of the diced point cloud frame. The octree information representing the occupancy octree having leaf nodes with size equal to powers of two (i.e., size is 2^s2) is then encoded, in a bitstream.

In some embodiments, two at the power S2 may be the smallest power of two greater than or equal to S.

2^S2-1< S < 2^S2

The coding and undicing the (diced) occupancy octree is equivalent to directly coding the occupancy octree having leaf node having lengths not equal to powers of two, but can be more easily implemented. This equivalence is because the dicing/undicing operations preserve the occupancy of the nodes of the octrees. Therefore, the occupancy information of a diced occupancy octree is the same as the occupancy information of the undiced occupancy octree.

Embodiments of the present disclosure allow for coding a point cloud with any size S of leaf nodes (e.g., TriSoup nodes) while maintaining the efficiency of the encoding/decoding of the occupancy octree by coding a diced occupancy octree whose nodes have lengths equal to powers of two in each direction. Furthermore, the dicing/undicing processes are simple and do not impact the overall complexity of the coding scheme.

In some embodiments, the octree information is encoded in the bitstream based on an inter predictor derived based on a reference point cloud frame.

In some embodiments, the inter predictor is based on a diced motion-compensated reference point cloud frame derived by dicing a motion-compensated reference point cloud frame from the length of the subvolume to the length of leaf node.

In some embodiments, the motion-compensated reference point cloud frame is derived by motion compensating the reference point cloud frame according to a motion field.

In some embodiments, the motion field is derived based on motion search between an undiced point cloud frame and the reference point cloud frame.

In some embodiments, the undiced point cloud frame is derived by undicing the diced point cloud frame from the length of the leaf node to the length of the sub-volume. In some embodiments, the motion field is represented by motion vectors in prediction units associated with occupied leaf nodes of the occupancy octree.

In some embodiments, a motion vector associated with a prediction unit is derived based on a portion of a portion of the undiced point cloud frame belonging to the prediction unit and a portion of the point cloud frame belonging to the prediction unit.

In some embodiments, the encoding method further comprises encoding, in the bitstream, the motion vectors and prediction units.

In some embodiments, the encoding process further comprises encoding leaf node data representing the geometry of the point cloud frame contained in volumes associated with occupied leaf nodes of the occupancy tree based on an undiced point cloud frame and an undiced occupancy free.

In some embodiments, the undiced point cloud frame is derived by undicing the diced point cloud frame from the length of the leaf node to the length of the sub-volume.

In some embodiments, the undiced occupancy octree is derived by undicing the occupancy octree from the length of the leaf node to the length of the sub-volume.

In some embodiments, encoding of leaf node data is birther based on leaf node inter predictor derived based on an undiced motion-compensated point cloud frame.

In some embodiments, the undiced motion-compensated point cloud frame is derived by undicing the diced motion-compensated reference point cloud frame.

Embodiments of the present disclosure fiirther relate to a method comprising decoding, from a bitstream, octree information representing an occupancy octree representing a space-partitioning of a first volume having a length along a direction equal to a power of two, wherein a leaf node of the occupancy octree being occupied indicates a volume associated with the leaf node contains a portion of a point cloud frame. The method further includes obtaining an undiced occupancy octree, representing a space-partitioning of a second volume of the point cloud frame, based on undicing the occupancy octree to correspond a length, in the direction, of a leaf node of the occupancy octree to a length, in the direction, of a sub-volume of the second volume.

In some embodiments, the octree information is decoded from the bitstream based on an inter predictor derived based on a reference point cloud frame.

In some embodiments, the inter predictor is based on the diced motion-compensated reference point cloud frame derived by dicing a motion-compensated reference point cloud frame from the length of the subvolume to the length of the leaf node.

In some embodiments, the motion field is represented by motion vectors in prediction units associated with occupied leaf nodes of the occupancy octree. In some embodiments, the motion vectors and the prediction units are decoded from the bitstream.

In some embodiments, the decoding method further includes decoding leaf node data representing the geometry of the point cloud contained in volumes associated with occupied leaf nodes of the occupancy tree based on an undiced occupancy tree.

In some embodiments, the decoding of leaf node data is further based on a leaf node inter predictor derived based on an undiced motion-compensated point cloud frame.

In some embodiments, the undiced motion-compensated point cloud frame is derived by undicing a diced motion-compensated reference point cloud frame.

In some embodiments, the diced motion-compensated reference point cloud frame is derived by dicing a motion-compensated reference point cloud frame from the length of the sub-volume to the length of the leaf node.

In some embodiments, the motion-compensated reference point cloud frame is derived by motion compensating a reference point cloud frame according to a motion field.

In some embodiments, the motion field is represented by motion vectors in prediction units associated with occupied leaf nodes of the occupancy octree.

In some embodiments, the decoding method further comprises decoding, from the bitstream, the motion vectors and the prediction units.

In some embodiments, dicing the point cloud frame from the length of the sub-volume to the length of the leaf node comprises processing each coordinate of each point of the point cloud frame into a new coordinate of the point of the diced point cloud frame by calculating a quotient and a remainder of a coordinate of the point of the point cloud frame relative to a division of the coordinate by the length of the sub-volume; and obtaining the new coordinate as a concatenation of the remainder for the lowest bits and the quotient for the higher bits, the number of lowest bits being equal to the length of the leaf node.

In some embodiments, undicing the diced point cloud frame from the length of the leaf node to the length of the sub-volume comprises processing each coordinate of each point of the diced point cloud frame into a new coordinate of the point of the point cloud frame by obtaining a first part as the lowest bits of a coordinate of the point of the diced point cloud frame and a second part as the higher bits of the coordinate of the point of the diced point cloud frame, the number of lowest bits being equal to the length of the leaf node; and obtaining the new coordinate of the point of the point cloud as a sum of the first part and the second part multiplied by the length of the sub-volume.

In some embodiments, dicing the motion-compensated point cloud frame from the length of the subvolume to the length of the leaf node comprises processing each coordinate of each point of the motion- compensated point cloud frame into a new coordinate of the point of the diced motion-compensated point cloud frame by calculating a quotient and a remainder of a coordinate of the point of the motion-compensated point cloud frame relative to a division of the coordinate by the length of the sub-volume, and obtaining the new coordinate as a concatenation of the remainder for the lowest bits and the quotient for the higher bits, the number of lowest bits being equal to the length of the leaf node. In some embodiments, dicing the motion- compensated point cloud frame from the length of the sub-volume to the length of the leaf node comprises processing a coordinate of at least one point of the motion-compensated point cloud frame into a new coordinate of the at least one point of the diced motion-compensated point cloud frame by calculating a quotient and a remainder of a coordinate of the at least one point of the motion-compensated point cloud frame relative to a division of the coordinate by the length of the sub-volume, obtaining a new coordinate of the at least one point of the motion-compensated point cloud frame as a concatenation of the remainder for the lowest bits and the quotient for the higher bits, the number of lowest bits being equal to the length of the leaf node.

In some embodiments, undicing the diced motion-compensated point cloud frame from the length of the leaf node to the length of sub-volume comprises processing each coordinate of each point of the diced motion-compensated point cloud frame into a new coordinate of the point of the point cloud frame by obtaining a first part as the lowest bits of a coordinate of the point of the diced motion-compensated point cloud frame and a second part as the higher bits of the coordinate of the point of the diced motion- compensated point cloud frame, the number of lowest bits being equal to the length of the leaf node; and obtaining the new coordinate of the point of the motion-compensated point cloud as a sum of the first part and the second part multiplied by the length of the sub-volume.

In some embodiments, undicing the occupancy octree from the length of the leaf node to the length of the sub-volume comprises processing each node position of the occupancy octree into a new node position of the undiced occupancy octree by obtaining a first part as the lowest bits and a second part as the higher bits of the position of the node of the occupancy node, the number of lowest bits being equal to the length of the leaf node; obtaining the new node position as a sum of the first part and the second part multiplied by the length of the sub-volume; and setting the length of the new node in the direction equals to the length of the subvolume in the direction.

In some embodiments, leaf node data is encoded as TriSoup node data.

In some embodiments, the length of the leaf node indicates a length in a direction of the volumes associated with the leaf nodes of the occupancy octree.

In some embodiments, the length of the sub-volume is a length in a direction of the sub-volumes associated with the leaf nodes of the occupancy octree.

In some embodiments, the length of the leaf node is the same for each direction. In some embodiments, the length of the sub-volume is the same for each direction. In some embodiments, wherein the length of the leaf node is obtained by expanding the length of the sub-volume in a same direction.

In some embodiments, the length of the leaf node in a direction of a volume equals the smallest power of two greater than or equals to the length of the sub-volume of the volume in the same direction.

In some embodiments, the occupancy octree represents the presence of at least one point of the diced point cloud frame in volumes associated with its leaf nodes.

In some embodiments, the occupancy octree represents the presence of at least one point of the point cloud frame in volumes associated with its leaf nodes.

In some embodiments, volumes are cuboids and sub-volumes are sub-cuboids.

In some embodiments, the point cloud frame in the second volume (1820) is diced into the diced point cloud in the first volume (1810) by transforming independently all coordinates Xi of each point P of the point cloud frame into diced coordinates x’i by, firstly, computing the quotient x/S and the remainder Xi%S of the coordinates Xi and, secondly, concatenating the remainder into the S2 lower bits of the new coordinates x’i and the quotient into higher bits.

X’i = ((xi/S) « S₂) + (xi%S) (1)

By doing so, S³-sized blocks of 2D points of the point cloud when the sub-volume are cube of size S*S*S are transformed into (l«S2)³-sized blocks of points whose only the lower S³-sizedpart may be occupied.

Undicing a diced point cloud is the inverse operation of dicing, i.e. dicing and then undicing a point cloud frame provides the same point cloud frame.

In some embodiments, undicing diced coordinates x’i into undiced coordinates Xi is performed by, firstly, obtaining separately the first S2 bits x’i &(( 1«S2)- 1) of the diced coordinates, by using a mask for example, and the higher bits x’i >>82 and, secondly, computing the sum of the higher bits multiplied by S and the lower bits:

Xi = (xi » S₂)*S + (x’i&((l«S₂)-l)) (2)

In other words, undicing is the inverse operation of dicing.

Dicing and undicing a point cloud frame is based on the parameters S and S2.

FIG. 19 illustrates an example of the undicing of the occupancy octree (1813), according to some embodiments.

The occupancy octree (1822) may be obtained by undicing the occupancy octree (1813) based on the parameters S and S2.

The occupancy octree (1813) may be undiced into the occupancy octree 1822 by modifying the node sizes from 2^s2 to S and by transforming the node coordinates (e.g., the position of the lower comer) independently on a representation of the point cloud frame. Basically, the S³-sized sub-parts of the (1«S2)³- sized leaf nodes are glued together to form the leaf nodes of the occupancy octree (1822). In some embodiments, the occupancy octree (1813) (diced occupancy octree) is undiced into the occupancy octree (1822) (undiced occupancy octree) by independently transforming the node coordinates x\ of the occupancy octree (1813) into node coordinates Xi of the occupancy octree (1822) by, firstly, obtaining separately the first S2 bits x\ &(( 1 <<82)- 1) of the node coordinates x’ by using a mask for example and the higher bits x’i >>82 and, secondly, computing the sum of the higher bits multiplied by S and the lower bits (equation 2).

Point cloud and octree dicing can be generalized to leaf nodes, e.g. TriSoup nodes, beyond cubic size S*S*S=S³. Let us consider cuboid leaf nodes having size 01*02* 03.

In some embodiments, dicing a point cloud frame is then given by x’i = ((Xi/Oi) « S_2>1) + (Xi% Oi) (3) and undicing of a diced point cloud and occupancy octree is given by

Xi = (xi » S₂,_I)*o_I + (x’i&((l«S₂,i)-l)) (4) where Oi and 82,1 are parameter such that Oi < 2^s21.

The undicing process is simplified as it involves only bitwise operations, additions and multiplications. The dicing process is more complex as it also involves a division and a modulo operation.

In some examples, the dicing process may be simplified. In some embodiment, the point cloud frame in the second volume (1820) is diced into the diced point cloud in the first volume (1810) by transforming independently all coordinates x; of each point P of the point cloud frame into diced coordinates x’i by: di = X1/01 , x’i = Xi + di * ((1 « S₂) + S)

The division to obtain di can be easily implemented because the range of values for the o,'s is limited, for example between 4 and 32. Therefore, this division can be replaced by a multiplication by LUT elements where the LUT precomputes the division over the limited range with some ‘b’ bits of precision.

Di = Xi * LUT[oi] » b

FIG. 20 illustrates an example encoding process 2000 combining an occupancy octree encoding followed by a leaf node encoding with any leaf node length S (or 01, o₂, 03) in each direction, according to some embodiments. The process 2000 may include the same operations (shown as having the same labeled blocks) as those described in FIG. 16. Different from the process 1600 of FIG. 16, the process 2000 includes blocks 2010-2060. For example, process 2000 may be performed by an encoder (e.g., encoder 114 of FIG. 1). In some examples, blocks 2010-2060 may represent components within the encoder.

The root node size 1612 may be any value equal or not to a power of two. For example, the root node size may equal to 2^N*S.

At block 2010, the root node size 1612 is expanded to an expanded root node size 2011 equals to a power of two. The length of the root node of the occupancy octree in each direction is then a power of two 2N*2^S2 The values S and S2 may be parameters of the dicing and undicing processes.

At block 2020, a diced point cloud frame 2021 is obtained by dicing the point cloud frame 1611 according to the parameters S and S2 such that S < 2^s2.

For example, S2 may be the smallest power of two greater than or equal to S.

At block 1610, the diced point cloud frame 2021 undergoes the occupancy octree encoding process such that the octree information (1613) encoded in the bitstream (1690) represents the diced point cloud frame (2021) and equivalently represents, as discussed above, the point cloud frame (1611). The occupancy octree (2043) is determined based on the expanded root node size 2011 and has nodes associated with volumes all having sizes equal to powers of two.

Occupancy octree encoding (block 1610) involves an occupancy octree that have nodes associated with volumes all having sizes equal to powers of two. The encoding process can thus be efficiently implemented as in prior art.

At block 2050, both the occupancy octree (2043) and the portions of the diced point cloud frame (2021) belonging to the occupied leaf nodes of the occupancy octree (2043) are undiced according to the parameter S and S2 to obtain leaf nodes (LN, 1615) and portions (1614) of the point cloud frame 1611 belonging to leaf nodes (1615).

At block 1620, the leaf node encoding scheme encodes, based on the point cloud per leaf node (1614) and leaf nodes (1615), leaf node information (1621) into the bitstream (1690).

Improved compression of the octree information (1613) may be obtained by using a reference point cloud frame (1632) to predict the occupancy information.

In a variant of the encoding process 2000, at block 2030, an undiced point cloud per PU (2031) is obtained by undicing diced point cloud per PU according to parameters S and S2.

The undiced point cloud frame per PU is derived from the diced point cloud frame 2021 and definition of PU.

In the variant, at block 1630, a motion vector (1633) is searched for each prediction unit (PU) from the reference point cloud frame (1632) to the undiced point cloud per PU (2031).

Undicing the diced point cloud per PU is necessary because a motion search between a diced point cloud and a non-diced point cloud would not lead to correct motion vectors.

In the variant, at block 1640, for each PU, a motion-compensated point cloud (1642) is obtained by motion compensation of the reference point cloud frame (1632) according to motion vectors (1633) associated with the PU.

In the variant, at block 2040, diced motion-compensated point cloud per PU (2041) is obtained by dicing the motion-compensated point cloud 1642, per PU, according to parameters S and S2.

In the variant, at block 1610, prediction of occupancy of the nodes of the occupancy octree (2043) is obtained from the diced motion-compensated point clouds (2041) associated with the PUs (inter predictor occupancy bit, block 1040 of FIG. 10) and leads to more efficient entropy encoding of the occupancy information part of the octree information representing occupancy octree (2043) (e.g., block 1045 of FIG. 10).

Dicing the motion-compensated point cloud 1642, per PU, is necessary because occupancy prediction of the occupancy octree (2043) by a non-diced motion-compensated point cloud would be inaccurate.

In the variant, at block 2060, the portions of the diced motion-compensated point cloud (2042) belonging to the occupied leaf nodes of the occupancy octree (2043) are undiced according to the parameter S and S2 to obtain portions (2044) of the motion-compensated point cloud frame belonging to leaf nodes (1615).

In the variant, at block 1620, the leaf node encoding scheme encodes, based on the point cloud per leaf node (1614), leaf nodes (1615) and motion-compensated point cloud per leaf node (2044), leaf node information (1621) into the bitstream (1690).

Undicing the portions of the diced motion-compensated point cloud (2042) ensures consistency between inter prediction within the leaf node encoding (block 1620).

By adding the dicing/undicing blocks (2010-2060 of FIG. 20), any size S (or oi, o₂, 03) of leaf nodes can be processed by a leaf node coding scheme supporting any length of leaf nodes in a direction such as a TriSoup encoding scheme.

The encoding process 2000 combines the efficiency of implementation and the versatility in leaf node sizes.

FIG. 21 illustrates an example decoding process 2100 combining an occupancy octree encoding followed by a leaf node encoding with any leaf node length S (or 01, o₂, 03) in each direction, according to some embodiments.

The process 2100 may include the same operations (shown as having the same labeled blocks) as those described in FIG. 17. Different from the process 1700 of FIG. 17, the process 2100 includes blocks 2040 and 2110. For example, process 2100 may be performed by a decoder (e.g., decoder 120 of FIG. 1). In some examples, blocks 2040-2110 may represent components within the decoder.

The decoding process 2100 decodes a bitstream (1690) generated by the encoding process 2000 of FIG. 20.

At block 1710, an occupancy octree (2043) is constructed by decoding octree information (1613) from the bitstream (1690). The occupancy octree (2043) has nodes associated with volumes all having sizes equal to powers of two.

At block 2110, an undiced occupancy octree is obtained by undicing the occupancy octree (2043) according to parameters S and S2. Occupied leaf nodes (LN, 1615) of the undiced occupancy octree have a length S (or 01, o₂, 03) in at least one direction. At block 1720, the leaf node decoding scheme decodes leaf node information (1621) from the bitstream (1690) for each occupied leaf nodes (1615) of the undiced occupancy octree. Based on the decoded leaf node information (1621), the geometry of the portion of the decoded point cloud (1721) contained in each of the occupied leaf node (1615) of the undiced occupancy octree is decoded.

Occupancy octree decoding (block 1710) involves an occupancy octree that have nodes associated with volumes all having sizes equal to powers of two. The decoding process can thus be efficiently implemented as in prior art.

By adding the dicing/undicing blocks (2040, 2110 of FIG. 21), any size S (or oi, o₂, 03) of leaf nodes can be processed by a leaf node coding scheme supporting any length of leaf nodes in a direction such as a TriSoup encoding scheme.

The decoding process 2100 combines the efficiency of implementation and the versatility in leaf node sizes.

Decoding of improved compression of the octree information (1613) may be obtained by using a reference point cloud frame (1632) to predict the occupancy information.

In the variant, at block 2040, diced motion-compensated point cloud per PU (2041) is obtained by dicing the motion-compensated point cloud per PU 1642 according to parameters S and S2.

In the variant, at block 1710, prediction of occupancy of the nodes of the occupancy octree (2043) is obtained from the diced motion-compensated point clouds per PU (2041) (inter predictor occupancy bit, block 1040 of FIG. 10) and leads to more efficient entropy decoding of the occupancy information part of the octree information (1613) (e.g., block 1045 of FIG. 10). The occupancy octree (2043) has nodes associated with volumes all having sizes equal to powers of two.

Dicing the motion-compensated point cloud per PU (1642) is necessary because occupancy prediction of the occupancy octree (2043) by a non-diced motion-compensated point cloud would be inaccurate.

In the variant, at block 1720, the leaf node decoding scheme decodes, based on the leaf nodes (1615) and motion-compensated point cloud per leaf node (2044), leaf node information (1621) from the bitstream (1690). Undicing the portions of the diced motion-compensated point cloud (2042) ensures consistency between inter prediction within the leaf node encoding (block 1720).

By adding the dicing/undicing blocks (2040 and 2060 of FIG. 21), any size S (or oi, o₂, 03) of leaf nodes can be processed by a leaf node coding scheme supporting any length of leaf nodes in a direction such as a TriSoup encoding scheme.

FIG. 22 illustrates a flowchart of an example method for encoding in a bitstream the geometry of a point cloud, according to some embodiments. For example, method 2200 may be performed by an encoder (e.g., encoder 114 of FIG. 1).

At block 2210, a diced point cloud frame, with a first volume having a length along a direction equal to a power of two, is obtained based on dicing a second volume of a point cloud frame along the direction to correspond a length, in the direction, of a sub-volume of the second volume to a length, in the direction, of a leaf node of an occupancy octree representing a space-partitioning of the first volume, the length of the leaf node being equal to a power of two and being greater than or equal to the length of the sub-volume.

At block 2220, the occupancy octree is obtained based on the first volume of the diced point cloud frame and based on iteratively dividing volumes, of the first volume, that contain at least one point of the diced point cloud frame. A leaf node of the occupancy tree being occupied indicates a volume, associated with the leaf node and having a length in the direction equal to the length of the sub-volume, contains a portion of the diced point cloud frame.

At block 2230, octree information representing the occupancy octree encoding is encoded in a bitstream.

FIG. 23 illustrates a flowchart of an example method for decoding from a bitstream a geometry of a point cloud, according to some embodiments. For example, method 2300 may be performed by a decoder (e.g., decoder 120 of FIG. 1).

At block 2310, octree information is decoded from a bitstream. The octree information represents an occupancy octree representing a space-partitioning of a first volume having a length along a direction equal to a power of two. A leaf node of the occupancy octree being occupied indicates a volume associated with the leaf node contains a portion of a point cloud frame.

At block 2320, an undiced occupancy octree is obtained. The undiced occupancy octree represents a space-partitioning of a second volume of the point cloud frame, based on undicing the occupancy octree to correspond a length, in the direction, of a leaf node of the occupancy octree to a length, in the direction, of a sub-volume of the second volume.

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 special-purpose 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 2400 is shown in FIG. 24. Blocks depicted in the figures above, such as the blocks in FIGS. 1, 6, 10, 11, 16, 17, 20-22 may execute on one or more computer systems 2400. Furthermore, each of the steps of the flowcharts depicted in the present disclosure may be implemented on one or more computer systems 2400. When more than one computer system 2400 is used to implement embodiments of the present disclosure, the computer systems 2400 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 2400 may form a “cloud” of computers.

Computer system 2400 includes one or more processors, such as processor 2404. Processor 2404 may be, for example, a special purpose processor, general purpose processor, microprocessor, or digital signal processor. Processor 2404 may be connected to a communication infrastructure 2402 (for example, a bus or network). Computer system 2400 may also include a main memory 2406, such as random access memory (RAM), and may also include a secondary memory 2408.

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

In alternative implementations, secondary memory 2408 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 2400. Such means may include, for example, a removable storage unit 2418 and an interface 2414. 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 2418 and interfaces 2414 which allow software and data to be transferred from removable storage unit 2418 to computer system 2400.

Computer system 2400 may also include a communications interface 2420. Communications interface 2420 allows software and data to be transferred between computer system 2400 and external devices. Examples of communications interface 2420 may include a modem, a network interface (such as an Ethernet card), a communications port, etc. Software and data transferred via communications interface 2420 are in the form of signals which may be electronic, electromagnetic, optical, or other signals capable of being received by communications interface 2420. These signals are provided to communications interface 2420 via a communications path 2422. Communications path 2422 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.

Computer system 2400 may also include one or more sensor(s) 2424. Sensor(s) 2424 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) 2424 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) 2424 may include a head tracking sensor to 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) 2424 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.

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 2416 and 2418 or a hard disk installed in hard disk drive 2410. These computer program products are means for providing software to computer system 2400. Computer programs (also called computer control logic) may be stored in main memory 2406 and/or secondary memory 2408. Computer programs may also be received via communications interface 2420. Such computer programs, when executed, enable computer system 2400 to implement the present disclosure as discussed herein. In particular, the computer programs, when executed, enable processor 2404 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 2450.

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 octree information, comprising: obtaining a diced point cloud frame, with a first volume having a length along a direction equal to a power of two, based on dicing a second volume of a point cloud frame along the direction to correspond a length, in the direction, of a sub-volume of the second volume to a length, in the direction, of a leaf node of an occupancy octree representing a space-partitioning of the first volume, the length of the leaf node being equal to a power of two and being greater than or equal to the length of the sub-volume; obtaining, based on the first volume of the diced point cloud frame, the occupancy octree based on iteratively dividing volumes, of the first volume, that contain at least one point of the diced point cloud frame, wherein a leaf node of the occupancy free being occupied indicates a volume, associated with the leaf node and having a length in the direction equal to the length of the sub-volume, contains a portion of the diced point cloud frame; and encoding, in a bitstream, octree information representing the occupancy octree.

2. The method of claim 1, wherein the octree information is encoded in the bitstream based on an inter predictor derived based on a reference point cloud frame, and the inter predictor is based on a diced motion-compensated reference point cloud frame derived by dicing a motion-compensated reference point cloud frame from the length of the sub-volume to the length of leaf node.

3. The method of claim 2, wherein the motion-compensated reference point cloud frame is derived by motion compensating the reference point cloud frame according to a motion field, and the motion field is derived based on motion search between an undiced point cloud frame and the reference point cloud frame.

4. The method of claim 1, further comprising encoding leaf node data representing the geometry of the point cloud frame contained in volumes associated with occupied leaf nodes of the occupancy free based on an undiced point cloud frame and an undiced occupancy free, wherein the undiced point cloud frame is derived by undicing the diced point cloud frame from the length of the leaf node to the length of the sub-volume, and the undiced occupancy octree is derived by undicing the occupancy octree from the length of the leaf node to the length of the sub-volume.

5. A method of decoding octree information, comprising: decoding, from a bitstream, octree information representing an occupancy octree representing a spacepartitioning of a first volume having a length along a direction equal to a power of two, wherein a leaf node of the occupancy octree being occupied indicates a volume associated with the leaf node contains a portion of a point cloud frame; and obtaining an undiced occupancy octree, representing a space-partitioning of a second volume of the point cloud frame, based on undicing the occupancy octree to correspond a length, in the direction, of a leaf node of the occupancy octree to a length, in the direction, of a sub-volume of the second volume.

6. The method of claim 5, wherein the octree information is decoded from the bitstream based on an inter predictor derived based on a reference point cloud frame.

7. The method of claim 6, wherein the inter predictor is based on a diced motion-compensated reference point cloud frame derived by dicing a motion-compensated reference point cloud frame from the length of the sub-volume to the length of the leaf node.

8. The method of claim 7, wherein the motion-compensated reference point cloud frame is derived by motion compensating the reference point cloud frame according to a motion field.

9. The method of claim 5, further comprising decoding leaf node data representing the geometry of the point cloud contained in volumes associated with occupied leaf nodes of the occupancy tree based on an undiced occupancy free, and wherein the undiced occupancy octree is derived by undicing the occupancy octree from the length of the leaf node to the length of the sub-volume.

10. The method of claim 9, wherein the decoding of leaf node data is further based on a leaf node inter predictor derived based on an undiced motion-compensated point cloud frame.

11. The method of claim 2 or 7, wherein dicing the motion-compensated point cloud frame from the length of the sub-volume to the length of the leaf node comprises processing a coordinate of at least one point of the motion-compensated point cloud frame into a new coordinate of the at least one point of the diced motion-compensated point cloud frame by: calculating a quotient and a remainder of a coordinate of the at least one point of the motion- compensated point cloud frame relative to a division of the coordinate by the length of the sub-volume, obtaining a new coordinate of the at least one point of the motion-compensated point cloud frame as a concatenation of the remainder for the lowest bits and the quotient for the higher bits, the number of lowest bits being equal to the length of the leaf node.

12. The method of claim 4 or 9, wherein undicing the occupancy octree from the length of the leaf node to the length of the sub-volume comprises processing each node position of the occupancy octree into a new node position of the undiced occupancy octree by: obtaining a first part as the lowest bits and a second part as the higher bits of the position of the node of the occupancy node, the number of lowest bits being equal to the length of the leaf node; obtaining the new node position as a sum of the first part and the second part multiplied by the length of the sub-volume; and setting the length of the new node in the direction equals to the length of the sub-volume in the direction.

13. A computer program product including instructions which, when the program is executed by one or more processors, causes the one or more processors to carry out all of the steps according to any of claims 1 to 12.

14. A video encoder comprising a circuit connected to a memory, wherein the circuit is arranged to: obtain a diced point cloud frame, with a first volume having a length along a direction equal to a power of two, based on dicing a second volume of a point cloud frame along the direction to correspond a length, in the direction, of a sub-volume of the second volume to a length, in the direction, of a leaf node of an occupancy octree representing a space-partitioning of the first volume, the length of the leaf node being equal to a power of two and being greater than or equal to the length of the sub-volume; obtain, based on the first volume of the diced point cloud frame, the occupancy octree based on iteratively dividing volumes, of the first volume, that contain at least one point of the diced point cloud frame, wherein a leaf node of the occupancy tree being occupied indicates a volume, associated with the leaf node and having a length in the direction equal to the length of the sub-volume, contains a portion of the diced point cloud frame; and encode, in a bitstream, octree information representing the occupancy octree.

15. A video decoder comprising a circuit connected to a memory, wherein the circuit is arranged to: decode, from a bitstream, octree information representing an occupancy octree representing a spacepartitioning of a first volume having a length along a direction equal to a power of two, wherein a leaf node of the occupancy octree being occupied indicates a volume associated with the leaf node contains a portion of a point cloud frame; and obtain an undiced occupancy octree, representing a space-partitioning of a second volume of the point cloud frame, based on undicing the occupancy octree to correspond a length, in the direction, of a leaf node of the occupancy octree to a length, in the direction, of a sub-volume of the second volume.