Reduced Memory Coding

Abstract

One or more methods, apparatus, computer-readable media, and systems for implementing coding techniques to reduce the number of possible occupancy configurations in a neighborhood of a sub-cuboid. A constraint for implementing such coding techniques can be a large memory footprint. The memory footprint can be reduced by using a simplified tree structure.

Description

[Background technology]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 438,071, filed January 10, 2023. The above-referenced application is incorporated herein by reference in its entirety.

[0002] An object or scene can be described using volumetric visual data consisting of a series of points. The points can be stored in a point cloud format, which includes a collection of points in three-dimensional space. Point clouds can be very large in data size, so transmitting and processing point cloud data can require data compression schemes specifically designed for the unique characteristics of point cloud data. Summary of the Invention

[0003] The following summary provides a simplified overview of certain features. It is not an extensive overview and is not intended to identify key or critical elements.

[0004] Coding (e.g., encoding, decoding) can be used to compress and decompress point cloud frames or sequences for efficient storage and transmission. A point cloud coding system may consist of a source device that encodes a point cloud sequence into a bitstream and a destination device that decodes the bitstream. A coder (e.g., source device or destination device) may represent a point cloud using an occupancy tree and divide the point cloud into cuboids and subcuboids. The amount (e.g., number) of possible occupancy configurations for a current cuboid, associated with the cuboid's spatial neighbors, may be quite large. Coding techniques can be used to reduce the amount (e.g., number) of possible occupancy configurations by using a lookup table of context indexes. However, such local coding techniques (e.g., dynamic optimal binary coders with on-the-fly updates) may result in a memory footprint that exceeds the size of the cache memory, which may adversely affect non-cached memory traffic. The memory footprint can be reduced by using a simplified tree structure.

[0005] These and other features and advantages are described in more detail below. [Brief explanation of the drawings]

[0006] Certain features are illustrated by way of example, and not by way of limitation, in the accompanying drawings in which like numerals refer to like elements and in which:

[0007] [Figure 1] FIG. 1 illustrates an exemplary point cloud coding system. [Figure 2] Figure 2 shows the Morton order of eight sub-rectangles divided from a rectangular prism. [Figure 3] FIG. 3 shows an example of an occupancy tree scan order. [Figure 4] FIG. 4 shows an example of a neighborhood of cuboids for entropy coding the occupancy of a child cuboid. [Figure 5]FIG. 5 shows an example of a dynamic shrinking function (DR) that can be used in a dynamic OBUF. [Figure 6] FIG. 6 shows an exemplary method for coding the occupancy of a rectangular prism using dynamic OBUFs. [Figure 7] FIG. 7 shows an example of an occupancy cuboid corresponding to a TriSoup node in the occupancy tree. [Figure 8A] FIG. 8A shows an exemplary cuboid corresponding to a TriSoup node. [Figure 8B] FIG. 8B shows an exemplary refinement to the TriSoup model. [Figure 9] FIG. 9 shows an example of voxelization. [Figure 10A] FIG. 10A shows an example of a rectangular parallelepiped. [Figure 10B] FIG. 10B shows an example of a rectangular parallelepiped. [Figure 11A] FIG. 11A shows a TriSoup edge that can be used to entropy code the current TriSoup edge. [Figure 11B] FIG. 11B shows a TriSoup edge that can be used to entropy code the current TriSoup edge. [Figure 11C] FIG. 11C shows a TriSoup edge that can be used to entropy code the current TriSoup edge. [Figure 12A] FIG. 12A shows an example of a simplified OBUF tree. [Figure 12B] FIG. 12B shows an example of a simplified OBUF tree. [Figure 12C] FIG. 12C shows an example of a simplified OBUF tree. [Figure 13] FIG. 13 shows an example of a hybrid OBUF tree. [Figure 14A] FIG. 14A shows an example of an OBUF memory footprint. [Figure 14B] FIG. 14B shows an example of an OBUF memory footprint. [Figure 15]FIG. 15 shows an exemplary OBUF tree and buffer. [Figure 16] FIG. 16 shows an exemplary common buffer shared by an OBUF tree. [Figure 17] FIG. 17 shows an example of a leaf-based tree. [Figure 18] FIG. 18 shows an exemplary buffer. [Figure 19A] FIG. 19A shows an example of an OBUF memory footprint. [Figure 19B] FIG. 19B shows an example of an OBUF memory footprint. [Figure 20A] FIG. 20A shows an example of how to encode and decode the vertex information of the current edge. [Figure 20B] FIG. 20B shows an example of how to encode and decode the vertex information of the current edge. [Figure 21] FIG. 21 shows an example of a computer system that may use any of the embodiments described herein. [Figure 22] FIG. 22 illustrates exemplary elements of a computing device that may be used to implement any of the various devices described herein. DETAILED DESCRIPTION OF THE INVENTION

[0008] The accompanying drawings and description provide examples. It should be understood that the examples shown in the drawings and / or description are non-exclusive, and that the features shown and described may be practiced in other examples. Examples are provided for the operation of a point cloud or point cloud sequence encoding or decoding system. More specifically, the techniques disclosed herein may relate to point cloud compression used in encoding and / or decoding devices and / or systems.

[0009] At least some visual data may describe an object or scene using a series of points. Each point may include a two-dimensional (x and y) position and one or more optional attributes, such as color. Volumetric visual data may add another positional dimension to this visual data. Volumetric visual data may describe an object or scene using a series of points, each including a three-dimensional (x, y, and z) position and one or more optional attributes, such as color, reflectance, timestamp, etc. Volumetric visual data may, for example, provide a more immersive way to experience the visual data compared to at least some visual data. For example, an object or scene described by volumetric visual data can be viewed from any angle (or multiple angles), whereas traditional visual data is generally only viewable from the angle at which it was captured or rendered.

[0010] Volumetric visual data can be used in many applications, including augmented reality (AR), virtual reality (VR), and mixed reality (MR). Sparse volumetric visual data can be used in the automotive industry for representing three-dimensional (3D) maps (e.g., cartography) or as input to advanced driver assistance systems. For advanced driver assistance systems, volumetric visual data can typically be input into driving decision algorithms. Volumetric visual data can be used to preserve valuable objects in digital form. In applications for preserving cultural heritage, the goal can be to preserve representations of objects that may be threatened by natural disasters. For example, statues, vases, and temples can be scanned in their entirety and stored as volumetric visual data with billions of samples. This use case for volumetric visual data can be particularly relevant for valuable objects in locations where earthquakes, tsunamis, and typhoons occur frequently. Volumetric visual data can take the form of volumetric frames. A volumetric frame can describe an object or scene captured at a specific time instance. Volumetric visual data may take the form of a sequence of volumetric frames (called a volume sequence or volumetric video), which may describe an object or scene captured at multiple different instances in time.

[0011] Volumetric visual data can be stored in various formats. One format for storing volumetric visual data is a point cloud. A point cloud can include a collection of points in 3D space. Each point in the point cloud can include geometric shape information that indicates the point's location in 3D space. For example, the geometric shape information can indicate the point's location in 3D space using three Cartesian coordinates (x, y, z) and / or spherical coordinates (r, phi, theta) (e.g., when acquired by a rotational sensor). The locations of points in the point cloud can be quantified according to spatial precision. The spatial precision can be the same or different in each dimension. The quantization process can generate a grid in 3D space. One or more points residing within each subgrid volume can be mapped to subgrid center coordinates called voxels. A voxel can be considered a 3D extension of a pixel corresponding to a 2D image grid coordinate. Points in the point cloud can further include one or more types of attribute information. The attribute information can indicate characteristics of the point's visual appearance. The attribute information may indicate, for example, the texture (e.g., color) of the point, the material type of the point, transparency information of the point, reflectance information of the point, a normal vector to the surface of the point, the velocity of the point, the acceleration at the point, a timestamp indicating when the point was captured, or a modality (e.g., running, walking, or flying) indicating how the point was captured. Points in the point cloud may include light field data in the form of multiple view-dependent texture information. The light field data may be another type of arbitrary attribute information.

[0012] The points in the point cloud may describe an object or scene. The points in the point cloud may, for example, describe the exterior surface and / or interior structure of the object or scene. The object or scene may be synthetically generated by a computer. The object or scene may be generated from capturing a real-world object or scene. Geometry information of a real-world object or scene may be obtained by 3D scanning and / or photogrammetry. 3D scanning may include different types of scanning, such as laser scanning, structured light scanning, and / or modulated light scanning. 3D scanning may obtain the geometry information. 3D scanning may obtain the geometry information, for example, by moving one or more laser heads, structured light cameras, and / or modulated light cameras relative to the object or scene being scanned. Photogrammetry may obtain the geometry information. Photogrammetry may obtain the geometry information, for example, by triangulating the same features or points in different spatially shifted 2D photographs. Point cloud data may take the form of a point cloud frame. A point cloud frame may describe an object or scene captured at a particular time instance. Point cloud data may take the form of a sequence of point cloud frames, which may also be referred to as a point cloud sequence or a point cloud video, which may describe an object or scene captured at multiple different instances of time.

[0013] The data size of a point cloud frame or point cloud sequence may be too large for storage and / or transmission in many applications. A single point cloud may, for example, contain more than one million points, or even more than one billion points. Each point may include geometric shape information and one or more types of attribute information. The geometric shape information for each point may include, for example, three Cartesian coordinates (x, y, and z) and / or spherical coordinates (r, phi, theta), each represented using at least 10 bits per component or a total of 30 bits. The attribute information for each point may include texture corresponding to multiple (e.g., three) color components (e.g., R, G, B color components). Each color component may be represented using, for example, 8 to 10 bits per component or a total of 24 to 30 bits. For example, one point may consist of at least 54 bits of information, including at least 30 bits of geometric shape information and at least 24 bits of texture. If a point cloud frame contains 1 million such points, each point cloud frame may require 54 million bits or 54 megabits to represent. For a dynamic point cloud that changes over time, a data rate of 1.32 gigabits per second may be required to transmit (e.g., transmit) the points of a point cloud sequence at a frame rate of 30 frames per second. Thus, a raw representation of a point cloud may require a large amount of data, and practical deployment of point cloud-based technologies may require compression techniques that enable the storage and distribution of point clouds at a reasonable cost.

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

[0015] FIG. 1 shows an exemplary point cloud coding (e.g., encoding and / or decoding) system 100. The point cloud coding system 100 may include a source device 102, a transmission medium 104, and a destination device 106. The source device 102 may encode a point cloud sequence 108 into a bitstream 110 for more efficient storage and / or transmission. The source device 102 may store and / or transmit (e.g., transmit) the bitstream 110 to the destination device 106 via the transmission medium 104. The destination device 106 may decode the bitstream 110 to display the point cloud sequence 108 or for other forms of consumption (e.g., further analysis, storage, etc.). The destination device 106 may receive the bitstream 110 from the source device 102 via the storage or transmission medium 104. The source device 102 and the destination device 106 may include any number of different devices. The source device 102 and the destination device 106 may include, for example, a cluster of interconnected computer systems that act as a seamless pool of resources (also called a cloud of computers or cloud computing), a server, a desktop computer, a laptop computer, a tablet computer, a smartphone, a wearable device, a television, a camera, a video game console, a set-top box, a video streaming device, a vehicle (e.g., an autonomous vehicle), or a head-mounted display. The head-mounted display may allow a user to view a VR, AR, or MR scene and adjust the view of the scene based on the user's head movements. The head-mounted display may be connected (e.g., tethered) to a processing device (e.g., a server, desktop computer, set-top box, video game console, etc.) or may be completely self-contained.

[0016] The source device 102 may include a point cloud source 112, an encoder 114, and an output interface 116. The source device 102 includes the point cloud source 112, the encoder 114, and the output interface 116, for example, to encode the point cloud sequence 108 into a bitstream 110. The point cloud source 112 may provide (e.g., generate) the point cloud sequence 108, for example, from the capture of natural scenes and / or synthetically generated scenes. The synthetically generated scenes may be scenes including computer-generated graphics. The point cloud source 112 may include one or more point cloud capture devices, a point cloud archive containing previously captured natural scenes and / or synthetically generated scenes, a point cloud feed interface for receiving the captured natural scenes and / or synthetically generated scenes from a point cloud content provider, and / or a processor for generating the synthesized point cloud scene. The point cloud capture device may include, for example, one or more laser scanning devices, structured light scanning devices, modulated light scanning devices, and / or passive scanning devices.

[0017] A point cloud sequence 108 is composed of a series of point cloud frames 124 (e.g., the example shown in FIG. 1 ). A point cloud frame may describe an object or scene captured at a particular time instance. The point cloud sequence 108 may achieve the impression of motion by sequentially presenting the point cloud frames 124 of the point cloud sequence 108 using a constant or variable time. A point cloud frame may include a collection of points (e.g., voxels) 126 in 3D space. Each point 126 may include geometric shape information that indicates the point's location in 3D space. The geometric shape information may indicate the point's location in 3D space using, for example, three Cartesian coordinates (x, y, and z). One or more of the points 126 may further include one or more types of attribute information. The attribute information may indicate characteristics of the point's visual appearance. The attribute information may indicate, for example, the texture (e.g., color) of the point, the material type of the point, transparency information of the point, reflectance information of the point, a normal vector relative to the surface of the point, the velocity of the point, the acceleration at the point, a timestamp indicating when the point was captured, and a modality (e.g., running, walking, or flying) indicating how the point was captured. One or more of the points 126 may include light field data, for example, in the form of multiple view-dependent texture information. The light field data may be any other type of attribute information. The color attribute information of one or more of the points 126 may include a luminance value and two color difference values. The luminance value may represent the luminance (e.g., luma component, Y) of the point. The color difference values ​​may represent the blue and red components (e.g., chroma components, Cb and Cr) of the point, respectively, separate from its brightness. The other color attribute values ​​may be represented based on a different color scheme (e.g., RGB or monochrome color scheme).

[0018] The encoder 114 may encode the point cloud sequence 108 into the bitstream 110. To encode the point cloud sequence 108, the encoder 114 may use one or more lossless or lossy compression techniques to reduce redundant information in the point cloud sequence 108. To encode the point cloud sequence 108, the encoder 114 may use one or more prediction techniques to reduce redundant information in the point cloud sequence 108. The redundant information is information that may be predicted in the decoder 120 and may not need to be transmitted (e.g., transmitted) to the decoder 120 for accurate decoding of the point cloud sequence 108. For example, the Motion Picture Expert Group (MPEG) introduced the 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 compressed point cloud frames, as well as the decoder operations for reconstructing the compressed point cloud frames from the bitstream. During the standardization of G-PCC, reference software (ISO / IEC Standard 23090-21: Reference Software for G-PCC) was developed to encode the geometric shape and attribute information of a point cloud frame. To encode the geometric shape information of a point cloud frame, the G-PCC reference software encoder may perform voxelization. The G-PCC reference software encoder may perform voxelization, for example, by quantifying the positions of points within a point cloud. Quantifying the positions of points within a point cloud may generate a grid in 3D space. The G-PCC reference software encoder may map points to the center coordinates of subgrid volumes (e.g., voxels) within which their quantized positions reside. The G-PCC reference software encoder may perform geometric shape analysis using an occupancy tree to compress the geometric shape information. The G-PCC reference software encoder may entropy encode the results of the geometric shape analysis to further compress the geometric shape information.To encode the attribute information of the point cloud, the G-PCC reference software encoder may use transform tools such as a domain adaptive hierarchical transform (RAHT), a predictive transform, and / or a lifting transform. The lifting transform may be built on top of the predictive transform. The lifting transform may include an additional update / lifting step. The lifting transform and the predictive transform may be referred to as a predictive / lifting transform or a "pred lift." The encoder 114 may operate in the same or similar manner as the encoder provided by the G-PCC reference software.

[0019] The output interface 116 may be configured to write and / or store the bitstream 110 on the transmission medium 104. The bitstream 110 may be sent (e.g., transmitted) to the destination device 106. Additionally or alternatively, the output interface 116 may be configured to send (e.g., transmit), upload, and / or stream the bitstream 110 to the destination device 106 via the transmission medium 104. The output interface 116 may include a wired and / or wireless transmitter configured to send (e.g., transmit), upload, and / or stream the bitstream 110 according to one or more proprietary, open-source, and / or standardized communication protocols. The one or more proprietary, open source, and / or standardized communications protocols may include, for example, 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, Third Generation Partnership Project (3GPP) standards, Institute of Electrical and Electronics Engineers (IEEE) standards, Internet Protocol (IP) standards, Wireless Application Protocol (WAP) standards, and / or other communications protocols.

[0020] The transmission medium 104 may include wireless, wired, and / or computer-readable media. For example, the transmission medium 104 may include one or more wires, cables, air interfaces, optical disks, flash memory, and / or magnetic memory. Additionally or alternatively, the transmission medium 104 may include one or more networks (e.g., the Internet) or file servers configured to store and / or transmit (e.g., transmit) encoded video data.

[0021] The destination device 106 can decode the bitstream 110 into a point cloud sequence 108 for display or other use. The destination device 106 may include one or more of an input interface 118, a decoder 120, and / or a point cloud display 122. The input interface 118 may be configured to read the bitstream 110 stored on the transmission medium 104. The bitstream 110 may be stored on the transmission medium 104 by the source device 102. Additionally or alternatively, the input interface 118 may be configured to receive, download, and / or stream the bitstream 110 from the source device 102 over the transmission medium 104. The input interface 118 may include a wired and / or wireless receiver configured to receive, download, and / or stream the bitstream 110 according to one or more proprietary, open source, standardized, and / or other communication protocols. Examples of protocols include 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, Third Generation Partnership Project (3GPP) standards, Institute of Electrical and Electronics Engineers (IEEE) standards, Internet Protocol (IP) standards, and Wireless Application Protocol (WAP) standards.

[0022] The decoder 120 may decode the point cloud sequence 108 from the encoded bitstream 110. The decoder 120 may operate in the same or similar manner as, for example, the decoder provided by the G-PCC reference software. The decoder 120 may decode a point cloud sequence that approximates the point cloud sequence 108. The decoder 120 may decode a point cloud sequence that approximates the point cloud sequence 108 due to, for example, lossy compression of the point cloud sequence 108 by the encoder 114 and / or errors introduced into the encoded bitstream 110 when, for example, transmission to the destination device 106 occurred.

[0023] The point cloud display 122 may display the point cloud sequence 108 to a user. The point cloud display 122 may include, for example, a cathode ray 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 the point cloud sequence 108.

[0024] The point cloud coding (e.g., encoding / decoding) system 100 is presented as an example and not as a limitation. Point cloud coding systems different from the point cloud coding system 100 and / or modified versions of the point cloud coding system 100 may perform the methods and processes described herein. For example, the point cloud coding system 100 may include other components and / or configurations. The point cloud source 112 may be external to the source device 102, for example. The point cloud display 122 may be external to the destination device 106, for example, or may be omitted entirely (if the point cloud sequence 108 is intended for consumption by a machine and / or storage device). The source device 102 may further include a point cloud decoder, for example. The destination device 106 may include a point cloud encoder, for example. For example, the source device 102 may be configured to further receive an encoded bitstream from the destination device 106. Receiving the encoded bitstream from the destination device 106 may support bidirectional point cloud transmission between the devices.

[0025] As described herein, the encoder may quantify the location of points within a point cloud according to a spatial precision, which may be the same or different in each dimension of the point. The quantization process may generate a grid in 3D space. The encoder may map any point that resides within each subgrid volume to a subgrid center coordinate called a voxel. A voxel may be considered a 3D extension of a pixel that corresponds to a 2D image grid coordinate.

[0026] The encoder may represent or code the voxelized point cloud. The encoder may represent or code the voxelized point cloud using, for example, an occupancy tree. For example, the encoder may divide an initial volume or cuboid containing the voxelized point cloud into subcuboids. The initial volume or cuboid may be referred to as a bounding box. The cuboid may be, for example, a rectangular parallelepiped. The encoder may recursively divide each subcuboid that contains at least one point of the point cloud. The encoder may not further divide a subcuboid that does not contain at least one point of the point cloud. A subcuboid that contains at least one point of the point cloud may be referred to as an occupied subcuboid. A subcuboid that does not contain at least one point of the point cloud may be referred to as an unoccupied subcuboid. The encoder may divide an occupied subcuboid into, for example, two subcuboids (to form a binary tree), four subcuboids (to form a quadtree), or eight subcuboids (to form an octree). The encoder may divide the occupied sub-cuboid to obtain further sub-cuboids. The sub-cuboids may have the same size and shape at a given depth level of the occupancy tree. For example, the sub-cuboids may have the same size and shape at a given depth level of the occupancy tree if the encoder divides the occupied sub-cuboid along a plane that passes through the center of the edge of the sub-cuboid.

[0027] The initial volume or cuboid containing the voxelized point cloud may correspond to the root node of the occupancy tree. Each occupied subcuboid split from the initial volume may correspond to a node (of the root node) at a second level of the occupancy tree. Each occupied subcuboid split from an occupied subcuboid at the second level may correspond to a node at a third level of the occupancy tree (the node off the occupied subcuboid at the second level from which it was split). The occupancy tree structure may continue to be formed in this manner for each recursive splitting iteration, for example, until some maximum depth level of the occupancy tree is reached or until each occupied subcuboid has a volume corresponding to one voxel.

[0028] Each non-leaf node in the occupancy tree may include or be associated with an occupancy word that represents the occupancy state of the cuboid corresponding to the node. A node in the occupancy tree corresponding to a cuboid divided into eight sub-cuboids may include or be associated with a one-byte occupancy word. Each bit (called an occupancy bit) of the one-byte occupancy word may represent or indicate the occupancy of a different one of the eight sub-cuboids. Each occupied sub-cuboid may be represented or indicated by a binary "1" in the one-byte occupancy word. Each unoccupied sub-cuboid may be represented or indicated by a binary "0" in the one-byte occupancy word. Occupied and unoccupied sub-cuboids may be represented or indicated by opposite one-bit binary values ​​in the one-byte occupancy word (e.g., a binary "0" representing or indicating an occupied sub-cuboid and a binary "1" representing or indicating an unoccupied sub-cuboid).

[0029] Each bit of the occupancy word may represent or indicate the occupancy of a different one of the eight sub-rectangles. Each bit of the occupancy word may represent or indicate the occupancy of a different one of the eight sub-rectangles, for example, according to the so-called Morton order. The least significant bit of the occupancy word may represent or indicate, for example, the occupancy of a first sub-rectangle of the eight sub-rectangles, for example, according to Morton order. The second least significant bit of the occupancy word may represent or indicate, for example, the occupancy of a second sub-rectangle of the eight sub-rectangles, for example, according to Morton order, etc.

[0030] Figure 2 shows an example Morton order. More specifically, Figure 2 shows the Morton order of eight sub-rectangles 202-216 divided from a rectangular prism 200. The sub-rectangles 202-216 are labeled based on their Morton order, with child node 202 coming first and child node 216 coming last. The Morton order for the sub-rectangles 202-216 is a local lexicographic order in xyz.

[0031] The geometry of the voxelized point cloud can be represented by and determined from the initial volumes and occupancy words of the nodes in the occupancy tree. The encoder may send (e.g., transmit) the initial volumes and occupancy words of the nodes in the occupancy tree in a bitstream to a decoder to reconstruct the point cloud. The encoder may entropy encode the occupancy words. For example, the encoder may entropy encode the occupancy words before transmitting the initial volumes and occupancy words of the nodes in the occupancy tree. The encoder may encode occupancy bits of the occupancy words of the nodes corresponding to the cuboid. For example, the encoder may encode occupancy bits of the occupancy words of the nodes corresponding to the cuboid based on one or more occupancy bits of the occupancy words of other nodes corresponding to cuboids that are adjacent to or spatially close to the cuboid of the occupancy bit being encoded.

[0032] The encoder and / or decoder may code (e.g., encode and / or decode) the occupied bits of the occupied words according to a scan order. The scan order may also be referred to as a scanning order. For example, the encoder and / or decoder may scan the occupation tree in breadth-first order. All occupied words of nodes at a given depth (e.g., level) in the occupation tree may be scanned. All occupied words of nodes at a given depth (e.g., level) in the occupation tree may be scanned before scanning the occupied words of nodes at the next depth (e.g., level). Within a given depth, the encoder and / or decoder may scan the occupied words of the nodes in Morton order. Within a given node, the encoder and / or decoder may also scan the occupied bits of the occupied words of the node in Morton order.

[0033] FIG. 3 illustrates an exemplary scan order. FIG. 3 illustrates an example scan order (e.g., breadth-first order as described herein) of an occupancy tree 300. More specifically, FIG. 3 illustrates an example scan order of the first three levels of the occupancy tree 300. In FIG. 3, a cuboid (e.g., cuboid) 302 corresponding to the root node of the occupancy tree 300 may be divided into eight sub-cuboids (e.g., sub-cuboids). Two sub-cuboids 304 and 306 of the eight sub-cuboids may be occupied. The other six sub-cuboids of the eight sub-cuboids may be unoccupied. According to Morton order, the first 8-bit occupancy word occW 1,1 is constructed to represent the occupied word of the root node. The first 8-bit occupied word (e.g., occW 1,1 ) can represent or indicate the occupancy of a sub-rectangle of eight sub-rectangles in the Morton order. For example, the first 8-bit occupancy word occW 1,1 The least significant occupancy bit of the first occupancy word occW can represent or indicate the occupancy of the first of the eight sub-occupancies in the Morton order. 1,1 The second least significant occupied bit of represents or indicates the occupation of the second of the eight sub-cuboids in the Morton order or the like.

[0034] Each of the occupied subcuboids (e.g., the two occupied subcuboids 304 and 306) may correspond to a node off the root node of the second level of the occupancy tree 300. Each of the occupied subcuboids (e.g., the two occupied subcuboids 304 and 306) may be further divided into eight subcuboids. For example, one of the subcuboids 308 of the eight subcuboids divided from the subcube 304 may be occupied, while the other seven subcuboids may be unoccupied. Three of the eight subcuboids divided from the subcube 306, namely, subcuboids 310, 312, and 314, may be occupied, while the other five subcuboids of the eight subcuboids divided from the subcube 306 may be unoccupied. Two second 8-bit occupancy words occW 2,1 and occW 2,2are constructed in this order to represent the occupancy words of the nodes corresponding to sub-cuboid 304 and sub-cuboid 306, respectively.

[0035] Each of the occupied sub-cuboids (e.g., the four occupied sub-cuboids 308, 310, 312, and 314) may correspond to a third-level node in the occupancy tree 300. Each of the occupied sub-cuboids (e.g., the four occupied sub-cuboids 308, 310, 312, and 314) may be further divided into eight sub-cuboids, or a total of 32 sub-cuboids. Four third-level 8-bit occupancy words occW 3,1 , occW 3,2 , occW 3,3 , and occW 3,4 are constructed in this order to represent the occupancy words of the nodes corresponding to sub-cuboid 308, the occupancy words of the nodes corresponding to sub-cuboid 310, the occupancy words of the nodes corresponding to sub-cuboid 312, and the occupancy words of the nodes corresponding to sub-cuboid 314, respectively.

[0036] The occupancy words of the exemplary occupancy tree 300 may be entropy coded (e.g., entropy encoded by an encoder and / or entropy decoded by a decoder), for example, according to a scan order (e.g., Morton order) discussed herein. The occupancy words of the exemplary occupancy tree 300 may be entropy coded (e.g., entropy encoded by an encoder and / or entropy decoded by a decoder), for example, according to a scan order (e.g., Morton order) discussed herein. 1,1 From occW 3,4The scan order discussed herein may be a breadth-first scan order. The occupied words of all nodes having the same depth (or level) as the current parent node may already be entropy coded, for example, if the occupied words of the current child node belonging to the current parent node are entropy coded. For example, the occupied words of all nodes having the same depth (e.g., level) as the current child node and having a lower Morton order than the current child node may already have been entropy coded. Some of the already coded occupied words may be used to entropy code the occupied words of the current child node. The already coded occupied words of adjacent parent and / or child nodes may be used, for example, to entropy code the occupied words of the current child node. It is possible that the occupied bits of an occupied word having a lower Morton order than a particular occupied bit have already been entropy coded, and for example, if a particular occupied bit of an occupied word of a current child node is coded (e.g., entropy coded), it may be used to code the occupied bit of the occupied word of the current child node.

[0037] 4 shows an example of a neighborhood of cuboids for entropy coding the occupancy of a child cuboid. More specifically, FIG. 4 shows an example of a neighborhood of cuboids with already coded occupancy bits. The neighborhood of cuboids with already coded occupancy bits can be used to entropy code the occupancy bits of the current child cuboid 400. The neighborhood of cuboids with already coded occupancy bits can be determined, for example, based on a scan order of an occupancy tree representing the geometric shape of the cuboid in FIG. 4 described herein. For a current child cuboid, the cuboid neighborhood may include one or more of: a cuboid close to the current child cuboid, a cuboid sharing a vertex with the current child cuboid, a cuboid sharing an edge with the current child cuboid, a cuboid sharing a face with the current child cuboid, a parent cuboid close to the current child cuboid, a parent cuboid sharing a vertex with the current child cuboid, a parent cuboid sharing an edge with the current child cuboid, a parent cuboid sharing a face with the current child cuboid, a parent cuboid close to the current parent cuboid, a parent cuboid sharing a vertex with the current parent cuboid, a parent cuboid sharing an edge with the current parent cuboid, a parent cuboid sharing a face with the current parent cuboid, etc. As shown in FIG. 4 , a current child cuboid 400 may belong to a current parent cuboid 402. According to the scan order of the occupancy words and occupancy bits of the nodes of the occupancy tree, the occupancy bits of the four child cuboids 404, 406, 408, and 410 belonging to the same current parent cuboid 402 have already been coded. The occupancy bits of the child cuboid 412 of the preceding parent cuboid have already been coded. The occupancy bits of the parent cuboid 414, whose child occupancy bits have not yet been coded, have already been coded. Therefore, the occupancy bits of the current child cuboid 400 can be coded using the already coded occupancy bits of the cuboids 404, 406, 408, 410, 412, and 414.

[0038] The number (e.g., quantity) of possible occupancy configurations (e.g., one or more sets of occupancy words and / or occupancy bits) for the neighborhood of the current child cuboid is 2 NN may be the number (e.g., quantity) of cuboids in the neighborhood of the current child cuboid that have already coded occupancy bits. The neighborhood of the current child cuboid may include several tens of cuboids. The neighborhood of the current child cuboid (e.g., several tens of cuboids) consists of 26 neighboring parent cuboids that share faces, edges, and / or vertices with the parent cuboid of the current child cuboid and several neighboring child cuboids that share faces, edges, or vertices with the current child cuboid. The occupancy configuration of the neighborhood of the current child cuboid may be limited to a subset of neighboring cuboids or may have billions of possible occupancy configurations, making its direct use impractical. The encoder and / or decoder may use the occupancy configuration of the neighborhood of the current child cuboid to select a context (e.g., a probability model) from a set of contexts for a binary entropy coder (e.g., a binary arithmetic coder) that encodes the occupancy bits of the current child cuboid. 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)).

[0039] The encoder and / or decoder may use several methods to reduce the neighborhood occupancy of the current child cuboid to a practical number (e.g., quantity) of reduced neighborhood occupancy configurations. 6 , i.e., 64 occupancy configurations can be reduced to 9 occupancy configurations. The occupancy configurations can be reduced by using geometric invariances. The occupancy score of the current child cuboid is 2x the occupancy score of its 26 neighboring parent cuboids. 26 A score can be obtained from each occupancy configuration. The score can be further reduced to a ternary occupancy prediction (e.g., "predicted-occupied," "uncertain," or "predicted-unoccupied") by using a score threshold. The number (e.g., quantity) of neighboring occupied child cuboids and the number (e.g., quantity) of neighboring unoccupied child cuboids can be used instead of the individual occupancies of these child cuboids.

[0040] An encoder and / or decoder using / employing one or more of the methods described herein can reduce the number (e.g., quantity) of possible occupancy configurations in the neighborhood of the current child cuboid to a more manageable number (e.g., several thousand). It is observed that instead of directly linking the reduction in the number (e.g., quantity) of contexts (e.g., probabilistic models) to the reduction in occupancy configurations, another mechanism, namely, an optimal binary coder with on-the-fly updates (OBUF), can be used. The encoder and / or decoder can implement an OBUF to limit the number (e.g., quantity) of contexts to a lower number (e.g., 32 contexts).

[0041] The OBUF may use a limited number (e.g., 32) of contexts (e.g., probability models). The number (e.g., quantity) of contexts in the OBUF may be a fixed number (e.g., a fixed quantity). The contexts used by the OBUF may be ordered and referenced by a context index (e.g., a context index ranging from 0 to 31), with a "1" associated with the lowest virtual probability to the highest virtual probability. A context index lookup table (LUT) may be initialized at the beginning of the point cloud coding process. The LUT may initially point to a context with a median virtual probability for coding a "1" for all inputs. The LUT may initially point to a context with a median virtual probability for coding a "1" among the limited number (e.g., quantity) of contexts for all inputs. This LUT may take as input an occupancy configuration in the neighborhood of the current child cuboid and output a context index associated with the occupancy configuration. The LUT may have the same number of entries as the reduced occupancy configuration (e.g., approximately several thousand entries). Coding the occupancy bit of the current child cuboid may include determining a reduced occupancy configuration of the current child node, obtaining a context index using the reduced occupancy configuration as an entry into the LUT, coding the occupancy bit of the current child cuboid using the context pointed to (or indicated by) the context index, and updating the LUT entry corresponding to the reduced occupancy configuration based on, for example, the value of the coded occupancy bit of the current child cuboid. For example, if a binary "0" (e.g., indicating that the current child cuboid is unoccupied) is coded, the LUT entry may be decreased to a lower context index value. For example, if a binary "1" (e.g., indicating that the current child cuboid is occupied) is coded, the LUT entry may be increased to a higher context index value. The context index update process may be based on a theoretical model of optimal distributions for hypothetical probabilities associated with a limited number (e.g., quantity) of contexts.This virtual probability may be fixed by the model and may differ from the internal probability of the context that may evolve when, for example, the coding of the data bits occurs. The evolution of the internal context may follow a well-known process similar to that of CABAC.

[0042] The encoder and / or decoder may implement a "dynamic OBUF" scheme, which allows the encoder and / or decoder to handle a much larger number (e.g., quantity) of occupancy configurations for, for example, the neighborhood of the current child cuboid than a typical OBUF. Using a larger number (e.g., quantity) of occupancy configurations for the neighborhood of the current child cuboid can improve compression and keep complexity within reasonable limits. By using an occupancy tree compressed by OBUF, the encoder and / or decoder may achieve lossless compression performance as good as 1 bit per point (bpp) for coding dense point cloud geometries. The encoder and / or decoder may implement a dynamic OBUF to further reduce the bitrate, potentially by more than 25%, down to 0.7 bpp.

[0043] The OBUF may not be able to accept as input a variety of reduced occupancy configurations for the neighborhood of the current child cuboid, and useful correlations may be lost. The OBUF may increase the size of the context index LUT to handle a larger variety of occupancy configurations for the neighborhood of the current child cuboid. Such an increase may dilute statistics and worsen compression performance. For example, if the LUT has millions of entries and the point cloud has hundreds of thousands of points, most entries will never be visited (e.g., looked up, accessed, etc.). In some instances, many entries may be visited only a few times, and their associated context indexes may not be updated enough times to reflect any meaningful correlation between occupancy configuration values ​​and the occupancy probability of the current child cuboid. A dynamic OBUF may be implemented to mitigate the dilution of statistics due to an increase in the number (e.g., quantity) of occupancy configurations in the neighborhood of the current child cuboid. This mitigation is achieved by "dynamic shrinking" of occupancy configurations in the dynamic OBUF.

[0044] A dynamic OBUF may add an additional step of shrinking the occupancy configurations in the neighborhood of the current child cuboid, for example, before using the context index LUT. This step may be called dynamic shrinking because it evolves based on the progress of the point cloud coding, or more precisely, based on the occupancy configurations already visited (e.g., looked up in the LUT).

[0045] As described herein, many possible occupancy configurations may potentially be related to the neighborhood of the current child cuboid, but only a subset may be visited when coding the point cloud. This subset may characterize the type of point cloud. For example, most of the visited occupancy configurations may indicate occupied neighboring cuboids of the current child cuboid, for example, when an AR or VR dense point cloud is coded. On the other hand, most of the visited occupancy configurations may indicate only a few occupied neighboring cuboids of the current child cuboid, for example, when a sparse point cloud acquired by a sensor is coded. The role of dynamic shrinking may be to obtain a more accurate correlation based on the most frequently visited occupancy configurations, for example, by refraining from (e.g., actively reducing) other occupancy configurations that are much less frequently visited. Dynamic shrinking may be updated on the fly. For example, when coding occupancy data, dynamic shrinking may be updated on the fly, for example, after each visit of an occupancy configuration (e.g., lookup in a LUT).

[0046] 5 shows an example of a dynamic shrinking function DR that can be used in a dynamic OBUF. The dynamic shrinking function DR is a function of bit β of the occupancy configuration 500. j , which consists of K bits.

number

number

[0047] A visit to an occupied configuration (e.g., an instance of a lookup in the LUT) is performed for all dynamically reduced occupied configurations β'=DR n (β) can be tracked by a variable NV(β'). The corresponding number (e.g., quantity) of visits NV(β V ') is, for example, the occupied configuration β V After each instance of coding the occupied bits based on , the number (e.g., quantity) of visits NV(β V ') is the threshold th as shown in the following formula V If the number of unmasked bits (e.g., quantity) k is greater than n (β) is β V ' can be increased by 1 for all occupancy configurations β that dynamically shrink to '.

number

number

number

number

number

[0048] The corresponding LUT entry LUT[β V '] is β V Two new entries are initialized by the coder index associated with 0 '] and LUT[β 1 ']. The corresponding LUT entry LUT[β V '] is, for example, the dynamically reduced occupancy configuration β V ' is dynamically reduced to a new two-occupancy configuration β 0 ' and β 1 ', then β V Two new entries are initialized by the coder index associated with 0 '] and LUT[β 1 '] and then evolve separately. The evolution of the coder index LUT on the dynamically reduced occupancy configuration can be fully defined.

number

[0049] Reduction Function DR nis the occupancy configuration β'=DR in which the leaf node 530 is reduced. n (β) is a set of growing binary trees T n 520. The initial tree can be modeled by 0=DR 0 There can be a single root node associated with (β). V The dynamically reduced part to β 0 ' and β 1 ' is replaced by β V From the leaf node associated with ', for example, β 0 ' and β 1 ' by adding two new nodes associated with the tree T n This can be equivalent to growing a tree. n+1 may be obtained by this growth. The number of visits (e.g., quantity) NV and the LUT of context indexes may be defined on the leaf nodes and may evolve with the growth of the tree through equations (I) and (II).

[0050] A practical implementation of the dynamic OBUF is given by the arrays NV[β'] and LUT[β'] of context indices, and the tree T n 520. An alternative to storing the tree is to store an array k of the number of unmasked bits (e.g., quantity). n [β] 510 can be stored.

[0051] A limitation for implementing a dynamic OBUF may be its memory footprint. In some applications, millions of occupied configurations may actually be handled, and the approximately 20-bit β that configures the entry configuration β into the reduction function DR may be used. i Each bit β i may correspond to the occupancy state of the neighboring cuboids of the current child cuboid, or the set of neighboring cuboids of the current child cuboid.

[0052] The higher (e.g., more significant) bit β i (e.g., β0, β1, etc.) may be the first bit to be unmasked. i(e.g., β0, β1, etc.) may be the first bits to be unmasked, for example, during the evolution of the dynamic reduction function DR. i The order of the neighborhood-based information stored in can affect compression performance. The neighboring information is ordered from high (e.g., highest) to low priority, and in this order, the bits β are sorted from high to low weight. i The priority may be, from most important to least important, the occupancy of a set of adjacent neighboring child cuboids, then the occupancy of adjacent neighboring child cuboids, then the occupancy of adjacent neighboring parent cuboids, then the occupancy of non-adjacent adjacent child nodes, and finally the occupancy of non-adjacent adjacent parent nodes. Adjacent nodes that share a face with the current child node may also have a higher priority than adjacent nodes that share an edge (but not a face) with the current child node. Adjacent nodes that share an edge with the current child node may have a higher priority than adjacent nodes that share only a vertex with the current child node.

[0053] FIG. 6 illustrates an exemplary method for coding the occupancy of a cuboid using a dynamic OBUF. More specifically, FIG. 6 illustrates an example method for coding the occupancy bits of a current child cuboid using a dynamic OBUF. One or more steps of FIG. 6 may be performed by an encoder and / or a decoder (e.g., encoder 114 and / or decoder 120 in FIG. 1). For example, all or part of the flowchart may be implemented by a coder (e.g., encoder 114 and / or decoder 120 in FIG. 1), the example computer system 2000 in FIG. 20, and / or the example computing device 2130 in FIG. 21.

[0054] In step 602, an occupancy configuration (e.g., occupancy configuration β) of the current child cuboid may be determined. The occupancy configuration (e.g., occupancy configuration β) of the current child cuboid may be determined, for example, based on the occupancy bits of previously coded cuboids in the neighborhood of the current child cuboid. In step 604, the occupancy configuration (e.g., occupancy configuration β) may be dynamically reduced. The occupancy configuration may be calculated, for example, using a dynamic reduction function DR n For example, the occupancy configuration β can be dynamically reduced using the reduced occupancy configuration β′=DR n (β). In step 606, the context index may be looked up, for example, in a look-up table (LUT). For example, the encoder and / or decoder may search for the context index LUT[β'] in the LUT of the dynamic OBUF. In step 608, a context (e.g., a probability model) may be selected. For example, the context (e.g., a probability model) pointed to by the context index is selected. In step 610, the occupancy of the current child cuboid may be entropy coded. For example, the occupancy bits of the current child cuboid may be entropy coded (e.g., arithmetic coded), for example, based on the context.

[0055] Although not shown in FIG. 6, the encoder and / or decoder may update the reduction function and / or update the context index. For example, the encoder and / or decoder may update the reduction function DR based on, for example, the occupancy bits of the current child cuboid. n DR n+1 and / or update the context index LUT[β']. The method of Figure 6 may be repeated for additional or all child cuboids of a parent cuboid corresponding to a node in the occupancy tree in a scan order, such as the scan order described herein with respect to Figure 3.

[0056] In general, occupancy trees are lossless compression techniques. Occupancy trees can be adapted to provide lossy compression, for example by modifying the point cloud on the encoder side (downsampling, removing points, moving points, etc.). Lossy compression performance may be weak. Lossy compression can be a useful lossless compression method for dense point clouds.

[0057] One approach to lossy compression of point cloud geometry is to set the maximum depth of the occupancy tree so that a minimum volume size of one voxel is not reached, and instead stop at a larger volume size (e.g., an NxNxN rectangular parallelepiped (e.g., cube), where N>1). The geometry of the points belonging to each occupied leaf node associated with the larger volume can then be modeled. This approach may be particularly suitable for dense, smooth point clouds that can be locally modeled by a smooth function, e.g., a plane or a polynomial. The coding cost may be the cost of the occupancy tree plus the cost of a local model of each occupied leaf node.

[0058] A scheme for modeling the geometry of points belonging to each occupied leaf node associated with a volume size larger than one voxel may use a set of triangles as a local model. The scheme may be called a "TriSoup" scheme. TriSoup is an abbreviation for "triangle soup" because connections between triangles cannot be part of the model. An occupied leaf node of the occupation tree corresponding to a cuboid with a volume larger 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 stores an existence flag (s) for each TriSoup edge of its corresponding occupied cuboid. k ) TriSoup edge existence flag (s k ) is a TriSoup vertex (V k ) on a TriSoup edge. At most one TriSoup vertex (V k) can be on the TriSoup edge. Each vertex (V k ), the TriSoup node corresponding to the occupied cuboid is the vertex along the TriSoup edge (V k ) position (p k ) may further include.

[0059] In addition to the occupancy word of the occupancy tree, the encoder may entropy encode the TriSoup vertex presence flag and the position of each TriSoup edge belonging to a TriSoup node of the occupancy tree. The decoder may similarly entropy decode the occupancy word of the occupancy tree, as well as the TriSoup vertex presence flag and the position of each TriSoup edge belonging to a TriSoup node of the occupancy tree.

[0060] FIG. 7 shows an example of an occupied cuboid (e.g., cube) 700. More specifically, FIG. 7 shows an example of an occupied cuboid (e.g., cube) 700 of size NxNxN (N>1) that corresponds to a TriSoup node in an occupancy tree. The occupied cuboid 700 may include edges (e.g., TriSoup edges 710-721). The TriSoup node corresponding to the occupied cuboid 700 stores an existence flag (s k). For example, the presence flag for TriSoup edge 714 may indicate that TriSoup vertex V1 is present on TriSoup edge 714. The presence flag for TriSoup edge 715 may indicate that TriSoup vertex V2 is present on TriSoup edge 715. The presence flag for TriSoup edge 716 may indicate that TriSoup vertex V3 is present on TriSoup edge 716. The presence flag for TriSoup edge 717 may indicate that TriSoup vertex V4 is present on TriSoup edge 717. The presence flags for the remaining TriSoup edges may each indicate that the TriSoup vertex is not present on the corresponding TriSoup edge. The TriSoup node corresponding to occupied cuboid 700 may further include the location of each TriSoup vertex that is present along one of its TriSoup edges 710-721. More specifically, the TriSoup node corresponding to occupied cuboid 700 may include a position p1 of TriSoup vertex V1, a position p2 of TriSoup vertex V2, a position p3 of TriSoup vertex V3, and a position p4 of TriSoup vertex V4.

[0061] 8A shows an example of a rectangular parallelepiped (e.g., cube) 800 corresponding to a TriSoup node. The rectangular parallelepiped 800 is a TriSoup vertex V k Within the cuboid 800, the TriSoup triangles may correspond to TriSoup nodes with a number K of TriSoup vertices V k A TriSoup triangle can be constructed from, for example, a TriSoup vertex V if there are at least three (K≧3) TriSoup vertices on the TriSoup edge of the rectangular solid 800. k For example, with respect to FIG. 8A, there may be four TriSoup vertices and a TriSoup triangle may be constructed. A TriSoup triangle is constructed from the TriSoup vertices V k The main direction may be determined and the vertex V kmay be ordered by rotating around this direction, and the following K TriSoup triangles may be constructed: V1V2C, V2V3C,..., V K V1C. The main direction may be chosen from among three directions, each parallel to an axis in 3D space, to increase or maximize the 2D surface of the triangle, for example, if the triangle projects along the main direction, so that the main direction is more or less perpendicular to the local surface defined by the points of the point cloud belonging to the TriSoup node.

[0062] FIG. 8B shows an example fine-tuning for a TriSoup model. The TriSoup model can be fine-tuned by coding the centroid survivor values. res can be coded into the bitstream. res For example, use C+C instead of C as the pivot vertex of the triangle. res C+C as the pivot vertices of the triangle. res By using res may be closer to a point in the point cloud than the centroid C, which reduces the reconstruction error and thereby res This allows for lower distortion at the cost of a small increase in the bit rate required for coding.

[0063] FIG. 9 shows an example of voxelization. Voxelization may refer to the reconstruction of a decoded point cloud from a set of TriSoup triangles. Voxelization may be performed by ray tracing for each triangle individually. Voxelization may be performed by ray tracing for each triangle individually, for example, before removing overlapping points between voxelized triangles. As shown in FIG. 9, a ray 900 may be launched parallel to one of three axes in 3D space. The ray 900 may point to an integer coordinate P start The intersection point P of the ray 900 with the TriSoup triangle 901 belonging to the rectangular parallelepiped 902 corresponding to the TriSoup node int (if any) may be rounded to obtain the decoded point. This intersection point Pint can be found using, for example, the Moller-Trumbore algorithm.

[0064] Existence flag (s k ) and existence flag (s k ) indicates the existence of a vertex, the current TriSoup edge position (p k ) can be entropy coded. k ) and position (p k ) may be individually or collectively referred to as vertex information or TriSoup vertex information. k ), and existence flags (s k ) indicates the existence of a vertex, the current TriSoup edge position (p k ) can be entropy coded, for example, based on the already coded presence flags and the positions of the TriSoup edges adjacent to the current TriSoup edge. k ) and existence flag (s k ) indicates the existence of a vertex, the current TriSoup edge position (p k ) may additionally or alternatively be entropy coded. The current TriSoup edge presence flag (s k ) and position (p k ) may additionally or alternatively be entropy coded, for example, based on the occupancy of cuboids adjacent to the current TriSoup edge. Similar to the entropy coding of the occupancy bits of the occupancy tree, the configuration β TS (Neighborhood configuration β TS ), and then use, for example, TriSoup's dynamic OBUF scheme to obtain the reduced configuration β TS '=DR n (β TS ) can be dynamically reduced to the context index LUT[β TS'] may be obtained from the OBUF LUT. At least a portion of the vertex information of the current TriSoup edge may be entropy coded using the context (e.g., a probability model) pointed to by the context index.

[0065] The TriSoup vertex position (p k ) (if present) can be binarized. The TriSoup vertex positions (p k ) (if present) may be binarized, for example, using a binary entropy coder, to entropy code at least some of the vertex information of the current TriSoup edge. k ) is quantized using the number of bits (e.g., quantity) N b A TriSoup edge of length N can be set to 2 Nb By doing so, the TriSoup vertex positions (p k ) can be individually encoded by a dynamic OBUF scheme. b bits(p k j , j=1,...,N b ), and existence flags (s k ) can be represented by bits corresponding to the neighborhood configuration β TS , OBUF reduction function DR n , and therefore the context index depends on the nature of the coded bits (e.g., presence flag (s k ), the highest bit (p k 1 ), the second highest bit p k 2 There are several possible dynamic OBUF schemes, each of which depends on a specific bit of information in the vertex information (e.g., existence flag (s k ) or position bit (p k j ))) is exclusive to this site.

[0066] 10A and 10B show exemplary cuboids. Specifically, FIGS. 10A and 10B show 12 cuboids 1000-1003, 1010-1013, and 1020-1023, each having a volume that intersects with the current TriSoup edge E to be entropy coded. The current TriSoup edge E may be an edge of the cuboids 1000-1003. The start point of the current TriSoup edge E may intersect with the cuboids 1010-1013. The end point of the current TriSoup edge E may intersect with the cuboids 1020-1023. The neighborhood configuration β of the current TriSoup edge E is calculated using one or more occupied bits of the 12 cuboids 1000-1003, 1010-1013, and 1020-1023. TS can be determined.

[0067] TriSoup edges may be oriented from start to end according to the orientation of one of the three axes in 3D space along which they are parallel. The overall ordering of TriSoup edges may be defined as a lexicographical order over the set (e.g., start, end). Vertex information associated with TriSoup edges may be encoded according to the order of the TriSoup edges. The causal neighborhood of a current TriSoup edge may be obtained from already encoded TriSoup edges that are close to the current TriSoup edge.

[0068] 11A, 11B, and 11C show TriSoup edges that may be used to entropy code a current TriSoup edge. 11A, 11B, and 11C show TriSoup edges (E' and E'') that may be used to entropy code a current edge E. In some instances, five TriSoup edges (E' and E'') may be used to entropy code the current edge E. The five TriSoup edges are: - an edge E' that is parallel to the current TriSoup edge E and has an end point equal to the start point of the current TriSoup edge E; - four edges E'' that are perpendicular to the current TriSoup edge E and have a start point or end point equal to the start point of the current TriSoup edge E. Depending on the direction of the current TriSoup edge E, any two (FIG. 11C for direction z), three (FIG. 11B for direction y), or four (FIG. 11A for direction x) of the four perpendicular TriSoup edges may already be coded, and their vertex information is used to construct a neighborhood configuration β for the current TriSoup edge E. TS The TriSoup edge E′ may already be coded for each direction of the current TriSoup edge E, and its vertex information may be coded independently of its direction to form a neighborhood configuration β TS can be used to construct

[0069] Neighborhood configuration β of the current TriSoup edge E TS can be obtained from one or more of the occupied bits of the cuboid and / or the vertex information of the neighboring already coded TriSoup edges. For example, the neighborhood configuration β of the current TriSoup edge E TS can be obtained from one or more of the 12 occupied bits of the 12 rectangular parallelepipeds shown in Figures 10A and 10B, and the vertex information of up to five adjacent already coded TriSoup edges (E' and E'') shown in Figures 11A, 11B, and 11C.

[0070] The occupancy bits of the octree and bits indicating the presence and / or location of TriSoup vertices may comprise the majority of the bitstream of the compressed representation of the point cloud geometry. These bits can be compressed using an OBUF scheme, which selects an entropy coder (or probability / context model) followed by entropy coding (e.g., encoding, decoding). The entropy coding can be performed using a coder such as CABAC (e.g., an arithmetic entropy coder). The OBUF scheme can be the bottleneck of the overall codec, where throughput can be related to the computational speed of the OBUF scheme and the entropy coder.

[0071] A trade-off between memory footprint and complexity may be considered, for example, when an OBUF algorithm is implemented. Considering that the OBUF scheme may be the source of a major codec bottleneck, the speed of the OBUF implementation may be prioritized over the memory footprint of the OBUF implementation. By doing so, the OBUF scheme may have no or little adverse effect on slowing down the codec throughput.

[0072] As shown in Figure 5, the selection of an entropy coder (or probability / context model) by the dynamic OBUF process is performed at some stage 'n' of the evolution of the dynamic OBUF by its associated tree T n For example, as shown with respect to FIG. 5, the neighborhood configuration β=β1,...,β K When 500 is equal to β=1001010, the implementation of the OBUF algorithm is n One may follow tree branches 1, then 0, then 0 until reaching a leaf of tree T n The leaves are dynamically reduced to the configuration β'=DR nThis may correspond to (β)=100. A coder index IDX(β') may be attached to each leaf of the tree. A volume (e.g., number) of visits NV(β') may also be attached to each leaf of the tree. The coder index may indicate a probabilistic model or context for implementing CABAC. This implementation of dynamic OBUF assumes that only the variables IDX(β') and NV(β') are associated with the tree T n The memory footprint can be low because the tree is stored for the leaves of the tree. However, when, for example, an update phase of a dynamic OBUF occurs, the tree itself needs to be stored and grown. This can be obtained with a reasonable memory footprint by some compact tree representation. In a particular example, for a tree T n The computational cost of reaching the leaves of can be problematic. For example, a neighborhood configuration may have up to 20 bits of information (i.e., K=20), and obtaining the coder (or probability / context model) index IDX(β') may require up to 20 unpredictable branching operations, which slows down the dynamic OBUF process and may lead to throughput that cannot meet typical codec requirements.

[0073] Other implementations of dynamic OBUFs can be used based on different tradeoffs, e.g., increased speed, but at the price of a larger memory footprint. The increased speed can only be achieved if the memory itself is fast enough to access the randomly accessed data in memory, e.g., IDX(β'). For a CPU-based implementation of dynamic OBUFs, this may imply that the OBUF memory footprint cannot exceed the size of the processor's cache memory. For hardware implementations, high-speed random-access memory may be expensive and cannot be scaled beyond a certain limit for cost and implementation reasons. The upper limit of random-access memory may be in the range of a few megabits (MB) for both implementations.

[0074] A fast implementation of dynamic OBUFs is size 2 KThe OBUF process may rely on three large arrays, k[], IDX[], and NV[], where K is the amount (e.g., number) of bits in the neighborhood configuration β that are used as input to the OBUF process. There are the same number of entries in these three arrays for every possible value of the neighborhood configuration β.

[0075] Using the first array k[], construct β=β1,...,β K From the reduced configuration β'=β1,..., βkn(β) The value k[β] is obtained by multiplying k[β] by K-β kn(β) The reduced configuration β′ may be obtained by a simple bit shift operation, where β′ may be right-padded by k[β] zeros, e.g., to have K bits as β.

number

[0076] The second array IDX[] may contain the coder index and the selection of the entropy coder (or probability / context model) that may be obtained through the index.

number

[0077] The third array NV[] may include the amount (e.g., number) of visits of the reduced configuration. The amount (e.g., number) of visits may be increased for the visited reduced configuration β′. The amount (e.g., number) of visits may be incremented for the visited reduced configuration β′, for example, after coding of the bits.

number

number

number

number

number

number

[0078] The concept of primary and secondary context information, i.e., CI1 and CI2, can be introduced. The primary context information CI1 can be fully utilized if, for example, the secondary context information CI2 can be input to a dynamic OBUF scheme such that a coder index idx is found based on the reduction of CI1 and CI2. Assuming that CI1 has K1 bits and CI2 has K2 bits, a coder index idx indexed by CI1, which takes CI2 as input, can be found. K1 OBUF Tree T n CI1 This can be considered equivalent to splitting the configuration β into two parts β=(CI1, CI2) for a total bit length K=K1+K2. Furthermore, this can be considered equivalent to using a single OBUF scheme for the entire β. For example, a single OBUF scheme can start with an array k[] initialized to K2 and not initialized to K. This can result in the first K1 bits not being masked.

[0079] Initializing the array k[]~K2 means that the quantity (e.g., number) of operations is 2. K Instead, the quantity of the action (e.g., the number) is equal to 2 K2 This may have a positive effect on the complexity of updating this array, since it may result in a bound equal to K2. K2 may be lower than the value (e.g., 10), and the update operation may be fast enough to be performed between two calls of the same dynamic OBUF instance. This may support a dynamic OBUF (including updates) that is computationally low in complexity and fast.

[0080] The large arrays k[], IDX[], and NV[] are of size 2 where K can be as high as 20. K A typical value for K may be, for example, 18, which is 3 x 2 per instance of a dynamic OBUF. 18This can result in many array elements (e.g., on the order of one million). There can be several instances of dynamic OBUFs, e.g., one for each of the eight occupied bits of the eight child nodes of a parent node in an octree structure. This can result in tens of millions of array elements. The memory footprint associated with these instances of dynamic OBUFs can be too large to allow the local coding process to stay in cache memory, which can lead to coding speed performance being adversely affected by non-cached memory traffic. Reducing the dynamic OBUF memory footprint can be achieved by reducing the size of the OBUF tree T. n This can be achieved by simplifying the deeper parts of the OBUF tree (e.g., further from the root node). The amount (e.g., number) of array elements may be reduced to achieve a memory footprint that allows the OBUF scheme to be processed entirely within a fast memory (e.g., cache memory).

[0081] 12A, 12B, and 12C show examples of simplified OBUF trees. The dynamic OBUF process creates an OBUF tree T n We can take an input configuration β consisting of 3 bits β = β1 β2 β3 (e.g., input configuration β1 200) such that the size 2 K =2 3 Instead of using three arrays k[], IDX[], and NV[] for β = 8, two scalar values ​​k and NV can be used instead, and only one single array IDX[] may be needed. The value k may be common to all configurations β and may indicate the amount (e.g., number) of bits to be dropped for any configuration β to obtain a reduced configuration β'. The coder index may be obtained by: where the array IDX[] may have the same role as in the unsimplified tree structure described herein.

number

number

number

[0082] The simplified tree approach is to create three arrays k 3*2 for the unsimplified tree containing [], IDX[], and NV[] K By using a single array IDX[] instead of IDX[], the memory footprint can be reduced by a factor of three.

[0083] OBUF Tree T nUsing a fully simplified tree from the root node of d may result in loss of compression performance because visit statistics may not be well tracked. A hybrid approach may be used by combining a non-simplified tree with a simplified tree. A non-simplified tree (e.g., a leaf-by-leaf grown tree) is used to grow a tree up to a threshold depth d. lpl may be used for depths lower than d, and the simplified tree is lpl It can be used at greater depths than

[0084] 13 illustrates an example of a hybrid OBUF tree. More specifically, FIG. 13 illustrates an example hybrid unsimplified and simplified OBUF tree. As shown in FIG. 13, for example, a leaf-wise tree is composed of 0 (e.g., the root node) and d lpl may be used for depth d between d and d, and the simplified tree is lpl The simplified tree can be lpl It may cover a depth of ∼K. The simplified tree may have a maximum depth of

number

[0085] Therefore, the size of the two arrays k[] and NV[] is 2 K instead of 2 dlpl The intermediate leaf unit structure β lpl is the entry configuration β to d simp It can be obtained by dropping bits.

number

number

number

[0086] Figures 14A and 14B show example OBUF memory footprints. More specifically, two example memory footprints, including leaf-wise and simplified OBUF trees, are described with respect to two tables, as shown in Figures 14A and 14B. The tables show the footprints of OBUFs used to code the eight occupancy bits of eight child nodes of a parent node belonging to an octree that represents the geometry of a point cloud.

[0087] As shown in Figures 14A and 14B, there may be 15 instances of OBUF for two base cases, namely "full" and "sparse," which are selected depending on the presence (or absence) of close occupied neighbors of the current octree node. In the "sparse" case, the 7 sibling occupied bits are known to be unoccupied, and no OBUF instance is required for the 8th "sparse" bit, so the 8th occupied bit may be inferred to be "occupied." The sizes K1 and K2 of the first and second context information CI1 and CI2 that make up configuration β may depend on each OBUF instance. The depth d of the simplified tree attached to the leaf-wise tree is simp Depends on the implementation. For example, see the first implementation shown in Figure 14A. A simplified tree is not used, so in this implementation, d simp = 0. In the second example shown in FIG. 14B, a simplified tree with depth equal to 3 is used, and therefore in this second example d simp =3.

[0088] The amount of elements (e.g., number) is 2 for the array IDX[]. K =2 K1 *2 K2 For two arrays k[] and NV[], dlpl =2 K-dsimp Each array element may be an 8-bit unsigned integer, such that the memory footprint is one byte per element. The tables in Figures 14A and 14B show the footprint of each array for each OBUF instance, and these footprints are summed to obtain a total footprint, e.g., "Total Intra" 1400, as shown in Figure 14A. This sum may correspond to octree intra-coding. For inter-coding, there may be four modes of coding: "Intra," "Inter-Prediction Unoccupied," "Inter-Prediction Weakly Occupied," and "Inter-Prediction Strongly Occupied." The footprint may then be multiplied by four, which may correspond to "Total Inter" 1410, converted to megabytes (MB), as shown by element 1420 in Figure 14A.

[0089] The footprint is, for example, when a simplified tree is not used (e.g., as shown in Figure 14A, d simp =0), the footprint may be 23.9 MB, for example, if a simplified tree is used (e.g., as shown in Figure 14B, d simp = 3), it may be 10.0 MB. The compression loss due to a simplified tree of depth 3 may be 0.4%, but for example, simp If increases, it can grow rapidly.

[0090] By using a simplified OBUF tree, the memory footprint of the two arrays k[] and NV[] may be reduced to almost zero. The size of the array IDX[] is the quantity (e.g., number) of possible configurations β. K Therefore, the use of a simplified OBUF tree may allow a three-fold reduction in memory footprint without changing the asymmetric behavior of the footprint with respect to the amount (e.g., number) of configurations. This use of a simplified OBUF tree may result in a footprint on the order of 10 MB, which may be large for cache memory.

[0091] Further reducing the memory footprint as a function of the quantity (e.g., number) of possible configurations β not only allows for easier implementation of the codec, but may also provide a better tradeoff between compression (driven by the quantity (e.g., number) of possible configurations β) and ease of implementation (driven by the memory footprint). By reversing this approach for a given memory footprint, more configurations may be used, which may result in better compression.

[0092] To achieve this improvement, O(2 K) can be important to obtain better memory footprint asymmetric behavior. Figure 15 shows an example OBUF tree and buffer. As shown in Figure 15, lpl The simplified OBUF tree used from can be replaced by a buffer (or buffer array) 1500 consisting of buffer elements 1510, each of which can represent a buffer tree 1520 with a total depth equal to:

number

[0093] The depth d of the leaf-wise tree 1530 lpl A leaf node (e.g., leaf node 1540) at may indicate or point to a buffer element (e.g., point 1550), and can be a series of nodes in the leaf-wise tree up to a maximum depth K. A buffer element can be a series of nodes in the leaf-wise tree up to a maximum depth K, for example, by inserting a buffer tree 1560 associated with the pointed-to buffer element into the leaf node 1540.

[0094] Figure 16 shows an example common buffer shared by OBUF trees. As shown in Figure 16, a buffer may be a common buffer (e.g., common buffer 1600) shared by several leaf-based OBUF trees (e.g., OBUF trees 1610, 1611, and 1612). The leaf-based OBUF trees 1610, 1611, and 1612 share the same depth d. plp , but with the same depth d of tree continuation by buffer elements buff at a common point. The leaf nodes of some leaf-wise OBUF trees may indicate (e.g., point to) buffer elements of the common buffer 1600.

[0095] 17 shows an example of a leaf-wise tree. More specifically, the sequential process of the leaf-wise tree with buffer elements is described herein with respect to FIG. 17, and the example is for K=5, d lpl = 2, and dbuff = 3. The configuration β can be reduced to a reduced configuration β′ after a leaf-wise tree as discussed herein. This tree has a maximum depth d as an entry configuration, as follows: lpl can be considered as a tree of

number

number

[0096] The process of determining the coder index idx is k lpl [β lpl The node associated with β' may depend on the value of k lpl [β lpl ]>0, it cannot be a leaf node of the deepest leaf-wise tree. The node associated with β' does not have to be a leaf node of the deepest leaf-wise tree, and its index is idx=IDX lpl [β']. Leaf-wise tree update (i.e., array k lpl [], IDX lpl [], and NV lpl [ ]) may be performed as discussed herein (eg, as discussed herein with respect to FIG. 13).

[0097] A buffer element index may be obtained, for example, when k lpl [β lpl ]=0, it can be obtained.

number

[0098] Buffer configuration β buff is the last d of the entry configuration β buff The buffer configuration β can be obtained as bits. buff can be obtained, for example, by a masking operation.

number

number

number

[0099] The memory footprint may be given by adding (eg, compounding) the memory footprint of the tree per leaf (eg, one per OBUF instance) and the memory footprint of the buffer. OBUF and N buffer For a NOBUF instance of a buffer element, the total memory footprint can be:

number

[0100] It may be necessary to store the buffer element index buffElemIdx[β']. The buffer element index buffElemIdx[β'] is a buffer of size 2 dlpl The fourth array buffElemIdx[] of size 2 dlpl Storing the buffer element index buffElemIdx[β'] in the fourth array buffElemIdx[] may change the first factor (e.g., 3) in the above memory footprint formula to a different factor (e.g., a factor of 4). This factor change can be avoided by hiding the value of buffElemIdx[β'] in an existing array.

[0101] The buffer element index buffElemIdx[β'] is, for example, k lpl [β lpl ] = 0. Two values ​​NV lpl [β lpl ] and IDX lpl [β lpl ], for example, if the buffer element index buffElemIdx[β'] is k lpl [β lpl ] = 0, it cannot be used by the leaf-wise tree representation. The buffer element index buffElemIdx[β'] is a function of two values ​​NV lpl [β lpl ] and IDX lpl [β lpl]. The buffer element index can be hidden as follows, for example, if 8-bit unsigned integers are used for the array elements, thereby hiding up to 16 bits of the buffer element index, which may be a sufficient size:

number

[0102] In some implementations of point cloud codecs, such as software-based or hardware-based implementations, the underlying hardware can be designed using the maximum available memory size. This size can be designed to meet the worst-case scenario of the codec's memory footprint. Unfortunately, the proposed buffer can grow to a somewhat undefined amount (e.g., number) of buffer elements. An a priori upper bound can be determined from thresholds on the amount (e.g., number) of points in the point cloud and the amount (e.g., number) of visited NVs, but this approach to determining the upper bound can be a gross approximation that may largely overestimate practical bounds.

[0103] Figure 18 shows an example buffer. The syntax element bufferSize may be used to signal and fix the maximum amount (e.g., number) of elements in the buffer. As a result, the buffer element index Bidx may belong to the range [0, bufferSize], as shown in Figure 18. The buffer memory footprint may correspond to:

number

[0104] Determining a buffer element index Bidx for a leaf node of the leaf-wise tree of an OBUF instance may be performed as described herein. The global variable lastBidx may represent the index of the buffer element immediately after the last attached buffer element to any leaf node of the leaf-wise tree is updated. The global variable lastBidx may be updated after each attachment, for example, by incrementing by one. The variable may be initialized to zero at the start of coding and may therefore point to the first buffer element. The buffer element index Bidx may be taken as equal to lastBidx, for example, when performing an attachment of a buffer element to a leaf node of the leaf-wise tree, and lastBidx may be incremented by one. By incrementing the variable lastBidx by one, the buffer may be fully used "from left to right." All buffer elements in the range [0; lastBidx] may be attached to leaf nodes of the leaf-wise tree of an OBUF instance, but buffer elements with indices equal to or greater than lastBidx may not yet be attached.

[0105] Setting the buffer size bufferSize may cause the index lastBidx to be incremented beyond bufferSize-1, which may result in the display (e.g., pointing) of an invalid buffer element. This problem may be solved by implementing the buffer as a rolling buffer and looping from the end of the buffer to the beginning of the buffer. The index lastBidx may be looped back by being reset to zero or some other value in the range [0, bufferSize], for example, when the index lastBidx is incremented to be equal to bufferSize.

[0106] A buffer element may be attached to more than one leaf node of a leaf-wise tree of an OBUF instance, for example, if a rolling buffer is used. This can impair compression performance if these two trees have mismatched statistics. For example, a bit equal to 1 indicates, for example, a buffer configuration β buff If comes from the first OBUF instance, it can be coded as 0. A bit equal to 0 is, for example, a buffer configuration β buff If comes from the second OBUF instance, it can be coded almost completely. The buffer elements can see alternate codings of 0 and 1 without good common statistics, and the coder index IDX B [][] can poorly model a signal, coding it as either a 0 or a 1, by "averaging" these common statistics to a probability close to 0.5.

[0107] Already used buffer elements may be attached to statistically suitable (at least second) leaf nodes, for example, after rolling the buffer. Blind incrementation of the lastBidx index may not achieve this goal. The evolution of the index lastBidx may be changed, for example, after rolling the buffer.

[0108] Statistically matching buffer elements can be searched for within some search range of buffer indices. The range of buffer indices is the range [lastBidx;lastBidx+N search ] may correspond to N search may define the size of the search range. 検索 can correspond to a variety of different values. 検索 An example value of IDX can be 10 or 20. The coder index of the leaf node to which the buffer element is attached is IDX. lpl [β ’ ]=IDX lpl [β lpl ], and β ’ is an array IDX that represents the leaf-wise tree to which the leaf node belongs. lplFor , several configurations β can be obtained. buff can also be obtained from the configuration β. The compatible buffer element (or the most compatible buffer element) is the coder index distance |IDX lpl [β ’ ]-IDX B [b][β buff ]|, where b can be a buffer index belonging to the search range. Then, the buffer index Bidx of the matching leaf node opt may be given by the following formula:

number

[0109] A buffer element may be initialized, for example, when the buffer element is attached to a leaf node of a leaf-wise tree. dbuff Array IDX with B Let all values ​​of [Bidx][] be a common value IDX equal to the coder index associated with the leaf node. lpl [β ’ ]=IDX lpl [β lpl This can be done by setting

[0110] Array IDX B The evolution of [Bidx][] may be performed, for example, after each coding of a bit by a coder (e.g., an entropy coder) selected by a tree of buffer elements. The selected coder may be a coder for some buffer configuration β buff For the coder index IDX B [Bidx][β buff]. B [Bidx][β buff ] may evolve, for example, when bits are coded.

[0111] Third array NV lpl The brackets [ ] may include the amount (e.g., number) of visits of the reduced configuration. The amount (e.g., number) of visits may be increased for the visited reduced configuration β′, for example, when bits are coded. The amount (e.g., number) of visits may be increased for the visited reduced configuration β′.

number

[0000] is not equal to zero, the reduced configuration β' can be updated to split into two new reduced configurations β'0 and β'1. The values ​​of the two new reduced configurations can be the following

[0000] and

[0000] .

number

number

number

number

number

[0112] 19A and 19B show examples of OBUF memory footprints. More specifically, FIGS. 19A and 19B show two tables illustrating two examples of OBUF memory footprints according to the simplified OBUF tree described herein. The two tables shown in FIGS. 19A and 19B show the OBUF memory footprints for a simplified tree depth d simp is the buffer depth d common to all OBUF instances. buff 14A and 14B, except that the memory footprint of the buffer 1902 is replaced by bufferSize 1900, and one buffer 1901 of size bufferSize elements is added. * 2 dbuff The total footprint 1910 of the tree in leaf units may be given by dlpl =2 K-dbuff Three arrays k lpl [], IDX lpl [], and NV lpl The total memory footprint 1920 may be the sum of the buffer footprint 1902 and the leaf-wise tree footprint 1910.

[0113] The table shown in FIG. 19A shows the buffer depth d buff19A shows an example with ≠4 and a large buffer (with 20,000 elements) that rarely rolls back to its first element due to the size of the buffer. Compared to the table shown in Figure 14B, the OBUF memory footprint of the example shown in Figure 19A is reduced from 10 MB to 1.8 MB. The observed compression performance shows only a 0.1% increase in bitrate.

[0114] The table shown in FIG. 19B shows the buffer depth d buff 19B shows an example with 1000 elements, 1000 elements, and a smaller buffer (with 4000 elements) that, due to its smaller size, can roll back to its first element more frequently. Compared to the table shown in Figure 14B, the OBUF memory footprint of the example shown in Figure 19B is reduced from 10 MB to 0.9 MB. The observed compression performance shows a 0.7% increase in bitrate.

[0115] The point cloud encoder and decoder may use the same method to construct and process buffers in order to maintain their synchronization in the selection of entropy coders (or equivalently their associated probability or context models). Thus, the encoder and decoder may have the same buffer size and implement the same rolling method, as described herein. For example, both the encoder and decoder may use bufferSize, d buff , and / or N search The same values ​​can be used for the syntax elements bufferSize, d buff , and / or N search may be coded (e.g., encoded) into a bitstream by an encoder. buff , and / or N search may be coded (eg, decoded) from the bitstream by a decoder, for example, to ensure synchronization.

[0116] Syntax elements bufferSize, d buff and / or N searchThe codec profile / level information can be set via the codec "profile" or "level", which can be defined by the codec specification. A decoder can obtain the codec profile / level information by several means, for example, from the encoded bitstream. The decoder can obtain the codec profile / level information to ensure the use of the same profile / level as the encoder. Each codec profile / level is defined by the syntax elements bufferSize, β buff and / or N search You can define the value of

[0117] 20A illustrates an example method for coding vertex information of a current edge. More specifically, FIG. 20A illustrates a flowchart 2000 of example method steps for encoding vertex information of a current edge. One or more steps of example flowchart 2000 may be performed by encoder 114 as described herein with respect to FIG. 1.

[0118] In step 2002, the encoder can determine a neighborhood configuration of a first edge (or first TriSoup edge) of a TriSoup node of the point cloud. The neighborhood configuration can be determined, for example, based on the already coded presence flags and positions (of the current TriSoup vertex) of the TriSoup edge. The neighborhood configuration can correspond to configuration β described with respect to Figures 15, 16, 17, and 18.

[0119] In step 2004, the encoder may index a first buffer element index array. The encoder may index the first buffer element index array based on the quantity (e.g., number) of symbols in the first portion of the neighborhood configuration to be masked. The encoder may index the first buffer element index array based on the first portion of the neighborhood configuration to determine a first index for a range of coder indices within the buffer array. With reference to Figures 15, 16, 17, and 18 herein, the first portion of the neighborhood configuration may be β lpl and the amount (e.g., number) of symbols in the first portion of the neighborhood structure that are masked may correspond to k lpl [β lpl ], and the first buffer element index array may correspond to buffElemIdx[] (or the array NV lpl [] and IDX lpl The first index may correspond to Bidx, and the buffer array may correspond to array IDX. B One-dimensional version of [] or array IDX B It can correspond to either the two-dimensional version of [][].

[0120] The first buffer element index array may be indexed, for example, based on the quantity (e.g., number) of symbols in the first portion of the neighborhood configuration that are masked being equal to zero. The buffer array may be a one-dimensional array, and the index of the range of coder indices may indicate the starting position of the range of coder indices within the buffer array. The buffer array may be a two-dimensional array, and indexing the buffer array to determine the coder index may include indexing a first dimension of the buffer array using a first index for the range of coder indices and a second dimension of the buffer array using a second portion of the neighborhood configuration. The memory associated with the range of coder indices may be a buffer element of the buffer array (e.g., buffer element 1550 described herein with respect to FIG. 15).

[0121] A first index for a range of coder indices in the buffer array may be determined based on the incremented global variable. The global variable may be incremented, for example, after a buffer element of the buffer array is attached to a leaf node of the OBUF instance. The global variable may be reinitialized to a starting value, for example, if the global variable is incremented a number of times (e.g., times). The number of times (e.g., times) the global variable is incremented may be equal to the number of buffer elements (e.g., times) in the buffer array. The starting value may be zero. The global variable may correspond to lastBidx described with respect to Figures 15, 16, 17, and 18.

[0122] A first index for a range of coder indexes in the buffer array may be determined. The first index for the range of coder indexes in the buffer array may be determined, for example, after a global variable is reinitialized to a starting value. The first index for the range of coder indexes in the buffer array may be determined, for example, based on a distance of the first coder index to a second coder index. The first coder index may be associated with a first portion of a neighborhood configuration. The second coder index may be stored in a buffer element of the buffer array at an index associated with the second portion of the neighborhood configuration. The second coder index may be determined to have the smallest distance to the first coder index among coder indexes of multiple buffer elements of the buffer array associated with the second portion of the neighborhood configuration. The amount (e.g., number) of the multiple buffer elements may be determined, for example, based on a search range size. The search range size may be transmitted (e.g., transmitted) by the encoder across the bitstream and / or received by the decoder from the bitstream.

[0123] In step 2006, the encoder may index the buffer array. The encoder may index the buffer array to determine a coder index. The encoder may index the buffer array to determine a coder index based on a first index for a range of coder indices and a second portion of the neighborhood configuration. With reference to Figures 15-18 described herein, the second portion of the neighborhood configuration may be β buff and the code index may correspond to idx=IDX B [(Bidx< <d buff )+β buff ] or idx=IDX B [Bidx][β buff ] can correspond to either

[0124] In step 2008, the encoder may select a context or a probability model for coding the vertex information of the first edge. The encoder may select a context or a probability model for coding the vertex information of the first edge based on, for example, a coder index.

[0125] In step 2010, the encoder may code (e.g., entropy encode) the vertex information of the first edge. The encoder may code (e.g., entropy encode) the vertex information of the first edge based on, for example, a context or a probability model (e.g., the context or probability model selected in step 2008). The encoder may further transmit, in the bitstream, an indication of the size of the buffer array. The indication of the size of the buffer array may include an indication of the quantity (e.g., number) of buffer elements in the buffer array and the depth of each of the buffer elements in the buffer array. The indication of the size of the buffer array may include an indication of a codec profile or codec level. The first buffer element index array may include a coder index array of the leaf-by-tree and an amount (e.g., number) of visitation arrays of the leaf-by-tree.

[0126] One or more method steps of flowchart 2000 may be used by an encoder to entropy encode occupancy bits of an occupancy tree used to represent or code a point cloud as described herein. Additionally or alternatively, one or more method steps of flowchart 2000 may be used by an encoder to entropy encode vertex information of a TriSoup edge. The encoder may encode a point cloud frame by using the first occupancy bits or vertex information.

[0127] 20B illustrates an example of a method for decoding vertex information of a current edge. More specifically, FIG. 20B illustrates a flowchart 2020 of example method steps for encoding vertex information of a current edge. One or more steps of the example flowchart 2020 may be performed by the decoder 120 as described herein with respect to FIG. 1.

[0128] In step 2022, the decoder can determine a neighborhood configuration of the first edge (or first TriSoup edge) of a TriSoup node of the point cloud. The neighborhood configuration can be determined, for example, based on the already coded presence flags and the position (of the current TriSoup vertex) of the TriSoup edge. The neighborhood configuration can correspond to configuration β described with respect to Figures 15, 16, 17, and 18.

[0129] In step 2024, the decoder may index the first buffer element index array. The decoder may index the first buffer element index array based on the quantity (e.g., number) of symbols in the first portion of the neighborhood configuration to be masked. The decoder may index the first buffer element index array based on the first portion of the neighborhood configuration to determine a first index for a range of coder indices within the buffer array. With reference to Figures 15, 16, 17, and 18 herein, the first portion of the neighborhood configuration may be lpl and the amount (e.g., number) of symbols in the first portion of the neighborhood structure that are masked may correspond to k lpl [β lpl ], and the first buffer element index array may correspond to buffElemIdx[] (or the array NV lpl [] and IDX lpl The first index may correspond to Bidx, and the buffer array may correspond to array IDX. B One-dimensional version of [] or array IDX B It can correspond to either the two-dimensional version of [][].

[0130] The first buffer element index array may be indexed, for example, based on the quantity (e.g., number) of symbols in the first portion of the neighborhood configuration that are masked being equal to zero. The buffer array may be a one-dimensional array, and the index of the range of coder indices may indicate the starting position of the range of coder indices within the buffer array. The buffer array may be a two-dimensional array, and indexing the buffer array to determine the coder index may include indexing a first dimension of the buffer array using a first index for the range of coder indices and a second dimension of the buffer array using a second portion of the neighborhood configuration. The memory associated with the range of coder indices may be a buffer element of the buffer array (e.g., buffer element 1550 described herein with respect to FIG. 15).

[0131] A first index for a range of coder indices in the buffer array may be determined based on the incremented global variable. The global variable may be incremented, for example, after a buffer element of the buffer array is attached to a leaf node of the OBUF instance. The global variable may be reinitialized to a starting value, for example, if the global variable is incremented a number of times (e.g., times). The number of times (e.g., times) the global variable is incremented may be equal to the number of buffer elements (e.g., times) in the buffer array. The starting value may be zero. The global variable may correspond to lastBidx described with respect to Figures 15, 16, 17, and 18.

[0132] A first index for a range of coder indexes in the buffer array may be determined. The first index for the range of coder indexes in the buffer array may be determined, for example, after a global variable is reinitialized to a starting value. The first index for the range of coder indexes in the buffer array may be determined, for example, based on a distance of the first coder index to a second coder index. The first coder index may be associated with a first portion of a neighborhood configuration. The second coder index may be stored in a buffer element of the buffer array at an index associated with the second portion of the neighborhood configuration. The second coder index may be determined to have the smallest distance to the first coder index among coder indexes of multiple buffer elements of the buffer array associated with the second portion of the neighborhood configuration. The amount (e.g., number) of the multiple buffer elements may be determined, for example, based on a search range size. The search range size may be transmitted (e.g., transmitted) by the encoder across the bitstream and / or received by the decoder from the bitstream.

[0133] In step 2026, the decoder may index the buffer array. The decoder may index the buffer array to determine a coder index. The decoder may index the buffer array to determine a coder index based on a first index for a range of coder indices and a second portion of the neighborhood configuration. With reference to Figures 15-18 described herein, the second portion of the neighborhood configuration may be β buff and the code index may correspond to idx=IDX B [(Bidx< <d buff )+β buff ] or idx=IDX B [Bidx][β buff ] can correspond to either

[0134] In step 2028, the decoder may select a context or a probability model for coding the vertex information of the first edge. The decoder may select a context or a probability model for coding the vertex information of the first edge based on, for example, a coder index.

[0135] In step 2030, the decoder may code (e.g., entropy decode) the vertex information of the first edge. The decoder may code (e.g., entropy decode) the vertex information of the first edge based on, for example, a context or a probability model (e.g., the context or probability model selected in step 2008). The decoder may further send and / or receive, in the bitstream, an indication of the size of the buffer array. The indication of the size of the buffer array may include an indication of the quantity (e.g., number) of buffer elements in the buffer array and the depth of each of the buffer elements in the buffer array. The indication of the size of the buffer array may include an indication of a codec profile or codec level. The first buffer element index array may include a coder index array of the leaf-by-tree and an amount (e.g., number) of visit arrays of the leaf-by-tree.

[0136] One or more method steps of flowchart 2000 may be used by a decoder to entropy code (e.g., decode) occupancy bits of an occupancy tree used to represent or code a point cloud as described herein. Additionally or alternatively, one or more method steps of flowchart 2000 may be used by a decoder to entropy decode vertex information of a TriSoup edge. The decoder may decode the point cloud frame by using the first occupancy bits or vertex information.

[0137] 21 illustrates an exemplary computer system capable of implementing embodiments of the present disclosure. For example, as shown in FIG. 21, an exemplary computer system 2100 may implement one or more of the methods described herein. For example, various devices and / or systems described herein (e.g., FIGS. 1, 2, and 3) may be implemented in the form of one or more computer systems 2100. Furthermore, each of the steps of the flowcharts illustrated in the present disclosure may be implemented on one or more computer systems 2100.

[0138] The computer system 2100 may include one or more processors, such as a processor 2104. The processor 2104 may be a special purpose processor, a general purpose processor, a microprocessor, and / or a digital signal processor. The processor 2104 may be connected to a communications infrastructure 2102 (e.g., a bus or network). The computer system 2100 may also include a main memory 2106 (e.g., random access memory (RAM)) and / or a secondary memory 2108.

[0139] The secondary memory 2108 may include a hard disk drive 2110 and / or a removable storage drive 2112 (e.g., a magnetic tape drive, an optical disk drive, and / or the like). The removable storage drive 2112 may read from and / or write to a removable storage unit 2116. The removable storage unit 2116 may include a magnetic tape, an optical disk, and / or the like. The removable storage unit 2116 may be read by and / or written to the removable storage drive 2112. The removable storage unit 2116 may include a computer-usable storage medium having computer software and / or data stored therein.

[0140] The secondary memory 2108 may include other similar means for allowing computer programs or other instructions to be loaded into the computer system 2100. Such means may include a removable storage unit 2118 and / or an interface 2114. Examples of such means may include a program cartridge and / or cartridge interface (such as a video game device), a removable memory chip (e.g., an erasable programmable read-only memory (EPROM) or a programmable read-only memory (PROM)), and associated sockets, thumb drives and universal serial bus (USB) ports, and / or other removable storage units 2118 and interfaces 2114 that may allow software and / or data to be transferred from the removable storage unit 2118 to the computer system 2100.

[0141] Computer system 2100 may include a communications interface 2120. The communications interface 2120 may allow software and data to be transferred between computer system 2100 and external devices. Examples of communications interface 2120 may include a modem, a network interface (e.g., an Ethernet card), a communications port, etc. The software and / or data transferred via communications interface 2120 may be in the form of signals, which may be electronic, electromagnetic, optical, and / or other signals that can be received by communications interface 2120. The signals may be provided to communications interface 2120 via communications path 2122. Communications path 2122 may transmit signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, a radio frequency (RF) link, and / or other communications channels.

[0142] The computer system 2100 may include one or more sensors 2124. The sensors 2124 may measure and / or detect one or more physical quantities. The sensors 2124 may convert the measured or detected physical quantities into electrical signals in digital and / or analog form. For example, the sensors 2124 may include an eye-tracking sensor for tracking a user's eye movements. The display of the point cloud may be updated based on the user's eye movements. In another example, the sensors 2124 may include a head-tracking sensor (e.g., a gyroscope) for tracking a user's head movements. The display of the point cloud may be updated based on the user's head movements. In yet another example, the sensors 2124 may include a camera sensor for taking photographs and / or a 3D scanning device (e.g., a laser scanning, structured light scanning, and / or modulated light scanning device). The 3D scanning device may acquire geometric shape information by moving one or more laser heads, structured light, and / or modulated light cameras relative to the object or scene being scanned. The geometric shape information may be used to construct a point cloud.

[0143] Computer program medium and / or computer-readable medium may be used to refer to tangible (e.g., non-transitory) storage media, such as removable storage units 2116 and 2118, or a hard disk installed in hard disk drive 2110. These computer program products may be means for providing software to computer system 2100. Computer programs (also called computer control logic) may be stored in main memory 2106 and / or secondary memory 2108. Computer programs may be received via communications interface 2120. When executed, these computer programs may enable computer system 2100 to implement one or more exemplary embodiments of the present disclosure, as discussed herein. In particular, when executed, the computer programs may enable processor 2104 to perform processes of the present disclosure, such as any of the methods described herein. Thus, these computer programs may represent controllers of computer system 2100.

[0144] 22 shows exemplary elements of a computing device that may be used to implement any of the various apparatuses described herein, including, for example, a source device (e.g., 102), an encoder (e.g., 114), a destination device (e.g., 106), a decoder (e.g., 120), and / or any computing device described herein. The computing device 2230 may include one or more processors 2231 that may execute instructions stored in random access memory (RAM) 2233, removable media 2234 (e.g., a universal serial bus (USB) drive, a compact disc (CD) or digital versatile disc (DVD), or a floppy disk drive), or any other desired storage medium. Instructions may also be stored on an attached (or internal) hard drive 2235. Computing device 2230 may also include a security processor (not shown) that may execute instructions of one or more computer programs to monitor processes running on processor 2231 and any process requesting access to any hardware and / or software components of computing device 2230 (e.g., ROM 2232, RAM 2233, removable media 2234, hard drive 2235, device controller 2237, network interface 2239, GPS 2241, Bluetooth interface 2242, WiFi interface 2243, etc.). Computing device 2230 may include one or more output devices such as a display 2236 (e.g., a screen, display device, monitor, television, etc.) and may include one or more output device controllers 2237, such as a video processor. There may also be one or more user input devices 2238, such as a remote control, keyboard, mouse, touch screen, microphone, etc. Computing device 2230 may also include one or more network interfaces, such as network interface 2239, which may be a wired interface, a wireless interface, or a combination of the two.The network interface 2239 may provide an interface through which the computing device 2230 communicates with a network 2240 (e.g., a RAN, or any other network). The network interface 2239 may include a modem (e.g., a cable modem), and the external network 2240 may include a communications link, an external network, a home network, a provider's wireless, coaxial, fiber, or hybrid fiber / coaxial distribution system (e.g., a DOCSIS network), or any other desired network. Additionally, the computing device 2230 may include a location detection device such as a global positioning system (GPS) microprocessor 2241, which may be configured to receive and process global positioning signals and, with possible assistance from external servers and antennas, determine the geographic location of the computing device 2230.

[0145] While the example of FIG. 22 may be a hardware configuration, the components shown may be implemented as software. Changes may be made to add, remove, combine, divide, etc. components of computing device 2230 as desired. Furthermore, components may be implemented using basic computing devices and components, and the same components (e.g., processor 2231, ROM storage 2232, display 2236, etc.) may be used to implement any of the other computing devices and components described herein. For example, the various components described herein may be implemented using a computing device having components such as a processor that executes computer-executable instructions stored on a computer-readable medium, as shown in FIG. 22. Some or all of the entities described herein may be software-based and coexist on a common physical platform (e.g., a requesting entity may be a separate software process and program from a dependent entity, both of which may run as software on a common computing device).

[0146] Various features are highlighted below in a set of numbered clauses or paragraphs. These features are not to be construed as limiting the invention or inventive concept, but are provided merely as highlighting some of the features described herein, without implying the importance or relevance of any particular order of such features.

[0147] Article 1A. A method comprising determining a neighborhood configuration of first occupancy bits indicating occupancy of a sub-cuboid associated with a point cloud frame.

[0148] Article 1B. The method of clause 1A, wherein the method further includes indexing a first buffer element index array using the first portion of the neighborhood configuration based on an amount of symbols in the first portion of the neighborhood configuration to determine a first index associated with a range of coder indices in the buffer array.

[0149] Article 1C. The method of clause 1B, wherein the method further includes indexing the buffer array to determine the coder index based on a first index associated with the range of coder indices and a second portion of the neighborhood configuration.

[0150] Article 1D. The method of clause 1C, wherein the method further comprises decoding the first occupied bit based on a context associated with the coder index. References herein to clause 1 may refer to one or each of clauses 1A, 1B, 1C, and 1D.

[0151] Article 2. 10. The method of claim 1, further comprising decoding the point cloud frame using the first occupied bits.

[0152] Article 3. 3. The method of any one of clauses 1-2, further comprising indexing the first buffer element index array based on an amount of symbols in the first portion of the neighborhood configuration being equal to zero.

[0153] Article 4. 3. The method of any one of clauses 1-2, wherein the index associated with the range of coder indices indicates the starting position of the range of coder indices within the buffer array.

[0154] Article 5. 4. The method of any one of clauses 1-3, wherein the buffer array is a two-dimensional array, and wherein indexing the buffer array further comprises indexing a first dimension of the buffer array using a first index for a range of coder indexes and indexing a second dimension of the buffer array using a second portion of the neighborhood configuration.

[0155] Article 6. 6. The method of any one of clauses 1-5, further comprising receiving, in the bitstream, an indication of the size of the buffer array.

[0156] Article 7. 7. The method of clause 6, wherein the indication of the size of the buffer array includes an indication of the quantity of buffer elements in the buffer array and the depth of each of the buffer elements in the buffer array.

[0157] Article 8. 7. The method of clause 6, wherein the indication of the size of the buffer array includes an indication of a codec profile or codec level.

[0158] Article 9. 9. The method of any one of clauses 1 to 8, wherein the first buffer element index array includes a leaf-wise tree coder index array and a leaf-wise tree amount of visit array.

[0159] Article 10. A computing device comprising one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the computing device to perform the method of any one of clauses 1 to 9.

[0160] Article 11. A system comprising: a first computing device configured to perform the method described in any one of clauses 1 to 9; and a second computing device configured to encode a first occupied bit based on a context associated with a coder index.

[0161] Article 12. A computer-readable medium storing instructions that, when executed, cause the method of any one of clauses 1-9 to be performed.

[0162] Article 13A. A method comprising determining a neighborhood configuration of a first edge indicative of an occupancy of a sub-cuboid associated with the point cloud frame.

[0163] Article 13B. The method of clause 13A, wherein the method further includes indexing a first buffer element index array using the first portion of the neighborhood configuration based on an amount of symbols in the first portion of the neighborhood configuration to determine a first index associated with a range of coder indices in the buffer array.

[0164] Article 13C. The method of clause 13B, wherein the method further includes indexing the buffer array to determine the coder index based on a first index associated with the range of coder indices and a second portion of the neighborhood configuration.

[0165] Article 13D. The method of clause 13C, wherein the method further comprises decoding vertex information of the first edge based on a context associated with the coder index. References herein to clause 13 may refer to one or each of clauses 13A, 13B, 13C, and 13D.

[0166] Article 14. 14. The method of claim 13, further comprising: determining a second edge neighborhood configuration; and indexing a first buffer element index array using the first portion of the second edge neighborhood configuration based on an amount of symbols in the first portion of the second edge neighborhood configuration to determine a second index associated with a range of coder indices in the buffer array.

[0167] Article 15. 15. The method of any one of clauses 13-14, further comprising decoding the point cloud frame using the vertex information, wherein the first index and the second index are the same.

[0168] Article 16. 16. The method of any one of clauses 13-15, wherein the first buffer element index array is for a first optimal binary coder with on-the-fly updates (OBUF) instance.

[0169] Article 17. 17. The method of any one of clauses 13 to 16, further comprising: determining a first index associated with a range of coder indices in the buffer array based on a global variable, the global variable being incremented after a buffer element of the buffer array is attached to a leaf node of the optimal binary coder with on-the-fly update (OBUF) instance.

[0170] Article 18. 18. The method of any one of clauses 13-17, further comprising setting the global variable to a starting value after the global variable has been incremented a number of times equal to the amount of buffer elements in the buffer array.

[0171] Article 19. 19. The method of any one of clauses 13 to 18, further comprising determining a first index associated with a range of coder indices in the buffer array based on a distance of a first coder index associated with a first portion of the neighborhood configuration to a second coder index stored in a buffer element of the buffer array at an index associated with a second portion of the neighborhood configuration.

[0172] Article 20. A computing device comprising one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the computing device to perform the method of any one of clauses 13 to 19.

[0173] Article 21. A system comprising: a first computing device configured to perform the method of any one of clauses 13 to 19; and a second computing device configured to encode a first occupied bit based on a context associated with a coder index.

[0174] Article 22. A computer readable medium storing instructions that, when executed, cause a computer to perform the method of any one of clauses 13 to 19.

[0175] Article 23A. A method comprising determining a neighborhood configuration indicative of occupancy of a sub-cuboid associated with a point cloud frame.

[0176] Article 23B. The method of clause 23A, wherein the method further includes indexing a first buffer element index array using the first portion of the neighborhood configuration based on an amount of symbols in the first portion of the neighborhood configuration to determine a first index associated with a range of coder indices in the buffer array.

[0177] Article 23C. The method of clause 23B, wherein the method further includes indexing the buffer array to determine the coder index based on a first index associated with the range of coder indices and a second portion of the neighborhood configuration.

[0178] Article 23D. The method of clause 23C, wherein the method further comprises encoding the first occupied bit based on a context associated with the coder index. References herein to clause 23 may refer to one or each of clauses 23A, 23B, 23C, and 23D.

[0179] Article 24. 24. The method of claim 23, further comprising encoding the point cloud frame using first occupied bits, and wherein determining a neighborhood configuration further comprises determining a neighborhood configuration of the first occupied bits.

[0180] Article 25. 25. The method of any one of clauses 23-24, wherein determining a neighborhood configuration further comprises determining a neighborhood configuration of a first edge.

[0181] Article 26. 26. The method of claim 25, further comprising: determining a second edge neighborhood configuration; and indexing a second buffer element index array using the first portion of the second edge neighborhood configuration based on an amount of symbols in the first portion of the second edge neighborhood configuration to determine a second index for a range of coder indices in the buffer array.

[0182] Article 27. A computing device comprising one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the computing device to perform the method of any one of clauses 23 to 26.

[0183] Article 28. A system comprising: a first computing device configured to perform the method of any one of clauses 23 to 26; and a second computing device configured to decode a first occupied bit based on a context associated with the coder index.

[0184] Article 29. A computer readable medium storing instructions that, when executed, cause a computer to perform the method of any one of clauses 23 to 26.

[0185] Article 30. 27. The method of any one of clauses 1-9, 13-19, or 23-26, wherein the first index and the second index are the same.

[0186] Article 31. 31. The method of any one of clauses 1-9, 13-19, 23-26, or 30, wherein the first buffer element index array is for a first optimal binary coder with on-the-fly updates (OBUF) instance, and the second buffer element index array is for a second OBUF instance different from the first OBUF instance.

[0187] Article 32. 32. The method of any one of clauses 1-9, 13-19, 23-26, or 30-31, wherein the starting value is zero.

[0188] Article 33. The method of any one of clauses 1-9, 13-19, 23-26, or 30-32, wherein the second coder index is determined to have the smallest distance to the first coder index among the coder indexes of a plurality of buffer elements of the buffer array associated with the second portion of the neighborhood configuration.

[0189] Article 34. 34. The method of any one of clauses 1-9, 13-19, 23-26, or 30-33, wherein the amount of the plurality of buffer elements is determined based on a search range size.

[0190] Article 35. The method of any one of clauses 1-9, 13-19, 23-26, or 30-34, wherein the search range size is transmitted / received across the bitstream.

[0191] Article 36. 36. The method of any one of clauses 1-9, 13-19, 23-26, or 30-35, wherein the vertex information of the first edge includes a vertex presence flag of the first edge.

[0192] Article 37. 37. The method of any one of clauses 1-9, 13-19, 23-26 or 30-36, wherein the vertex information of the first edge comprises a vertex position of the first edge.

[0193] Article 38. 38. The method of any one of clauses 1-9, 13-19, 23-26, or 30-37, wherein a buffer element of the buffer array comprises memory associated with a range of coder indices.

[0194] A computing device may perform a method including a plurality of operations. The computing device may determine a neighborhood configuration of first occupancy bits indicating occupancy of a sub-cuboid associated with a point cloud frame. The computing device may index a first buffer element index array using the first portion of the neighborhood configuration to determine a first index associated with a range of coder indexes in a buffer array based on a quantity of symbols in the first portion of the neighborhood configuration, index the buffer array to determine a coder index based on the first index associated with the range of coder indexes, a second portion of the neighborhood configuration, and decode the first occupancy bits based on a context associated with the coder index. The computing device may decode the point cloud frame using the first occupancy bits. The computing device may index a first buffer element index array based on the amount of symbols in the first portion of the neighborhood configuration being equal to zero, wherein an index associated with the range of coder indices indicates a starting position of the range of coder indices within the buffer array, wherein the buffer array may be a two-dimensional array, and wherein indexing the buffer array may further include indexing a first dimension of the buffer array using the first index for the range of coder indices and indexing a second dimension of the buffer array using the second portion of the neighborhood configuration, and wherein a buffer element of the buffer array may include a memory associated with the range of coder indices.The computing device may receive in the bitstream an indication of the size of the buffer array, the indication of the size of the buffer array may include an indication of the quantity of buffer elements in the buffer array and the depth of each of the buffer elements in the buffer array, the indication of the size of the buffer array may include an indication of a codec profile or a codec level, the first buffer element index array may include a leaf-wise tree coder index array and a leaf-wise tree visitation array, the first index and the second index may be the same, the first buffer element index array may be for a first optimal binary coder with on-the-fly updates (OBUF) instance, and the second buffer element index array may be for a second OBUF instance that may be different from the first OBUF instance, the starting value may be zero, the second coder index may be determined to have a minimum distance to the first coder index among the coder indexes of multiple buffer elements of a buffer array associated with a second portion of the neighborhood configuration, the amount of multiple buffer elements may be determined based on a search range size, the search range size may be transmitted / received across the bitstream, the vertex information of the first edge may include a vertex presence flag for the first edge, the vertex information of the first edge may include a vertex position for the first edge, and the buffer elements of the buffer array may include memory associated with a range of coder indices. The computing device may include one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the computing device to perform the described methods, additional operations, and / or include additional elements. A system may include a first computing device configured to perform the described methods, additional operations, and / or include additional elements, and a second computing device configured to encode the first occupancy bit based on a context associated with the coder index.The computer-readable medium may store instructions that, when executed, perform the methods described, cause additional actions, and / or include additional elements.

[0195] A computing device may perform a method including a plurality of operations. The computing device may determine a neighborhood configuration of a first edge indicating an occupancy of a sub-cuboid associated with the point cloud frame. The computing device may index a first buffer element index array using the first portion of the neighborhood configuration based on an amount of symbols in the first portion of the neighborhood configuration to determine a first index associated with a range of coder indexes in the buffer array. The computing device may index the buffer array to determine a coder index based on the first index associated with the range of coder indexes and a second portion of the neighborhood configuration, and may decode vertex information of the first edge based on a context associated with the coder index. The computing device may use the vertex information to decode the point cloud frame. The computing device may determine a second edge neighborhood configuration, and may index a first buffer element index array using the first portion of the second edge neighborhood configuration based on an amount of symbols in the first portion of the second edge neighborhood configuration to determine a second index associated with a range of coder indices in the buffer array, where the first index and the second index may be the same, and the first buffer element index array may be for a first optimal binary coder with on-the-fly updates (OBUF) instance. The computing device may determine that the first index associated with the range of coder indices in the buffer array is determined based on a global variable, where the global variable may be incremented after a buffer element of the buffer array is attached to a leaf node of the optimal binary coder with on-the-fly updates (OBUF) instance. The computing device may set the global variable to a starting value after incrementing the global variable a number of times equal to the amount of buffer elements in the buffer array.The computing device may determine a first index associated with a range of coder indexes in the buffer array based on a distance of a first coder index associated with a first portion of the neighborhood configuration to a second coder index stored in a buffer element of the buffer array, the first index and the second index may be the same, the first buffer element index array may be for a first optimal binary coder (OBUF) instance with on-the-fly updates, and the second buffer element index array may be for a second OBUF instance that may be different from the first OBUF instance. The first coder index may be for a BUF instance, and the starting value may be zero; the second coder index may be determined to have the smallest distance to the first coder index among the coder indexes of multiple buffer elements of a buffer array associated with the second portion of the neighborhood configuration; the amount of multiple buffer elements may be determined based on a search range size; the search range size may be transmitted / received across the bitstream; the vertex information of the first edge may include a vertex presence flag for the first edge; the vertex information of the first edge may include a vertex position for the first edge; and the buffer elements of the buffer array include memory associated with a range of coder indexes. The computing device may include one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the computing device to perform the described methods, additional operations, and / or include additional elements. The system may include a first computing device configured to perform the described methods, additional operations, and / or include additional elements, and a second computing device configured to encode the first occupancy bit based on a context associated with the coder index. The computer-readable medium may store instructions that, when executed, perform the methods described, cause additional actions, and / or include additional elements.

[0196] A computing device may perform a method including a plurality of operations. The computing device may determine a neighborhood configuration indicating an occupancy of a sub-cuboid associated with a point cloud frame. The computing device may index a first buffer element index array using the first portion of the neighborhood configuration based on a quantity of symbols in a first portion of the neighborhood configuration to determine a first index associated with a range of coder indices in the buffer array, index the buffer array based on the first index associated with the range of coder indices and a second portion of the neighborhood configuration to determine a coder index, and encode a first occupancy bit based on a context associated with the coder index. The computing device may encode the point cloud frame using the first occupancy bit, and determining the neighborhood configuration may further include determining a neighborhood configuration of the first occupancy bit, and determining the neighborhood configuration may further include determining a neighborhood configuration of the first edge.The computing device may determine a second edge neighborhood configuration, and based on an amount of symbols in a first portion of the second edge neighborhood configuration, may index a second buffer element index array using the first portion of the second edge neighborhood configuration to determine a second index for a range of coder indices in the buffer array, where the first index and the second index may be the same, and the first buffer element index array may be for a first optimal binary coder with on-the-fly updates (OBUF) instance, and the second buffer element index array may be for a second OBUF instance that may be different from the first OBUF instance. The first coder index may be for an instance, and the starting value may be zero; the second coder index may be determined to have the smallest distance to the first coder index among the coder indexes of multiple buffer elements of a buffer array associated with the second portion of the neighborhood configuration; the amount of multiple buffer elements may be determined based on a search range size; the search range size may be transmitted / received across the bitstream; the vertex information of the first edge may include a vertex presence flag for the first edge; the vertex information of the first edge may include a vertex position for the first edge; and the buffer elements of the buffer array may include memory associated with a range of coder indices. The computing device may include one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the computing device to perform the described methods, additional operations, and / or include additional elements. The system may include a first computing device configured to perform the described methods, additional operations, and / or include additional elements, and a second computing device configured to decode the first occupied bit based on a context associated with the coder index. The computer-readable medium may store instructions that, when executed, perform the methods described, cause additional actions, and / or include additional elements.

[0197] One or more examples herein may be described as a process, which may be depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, and / or a block diagram. A flowchart may describe operations as a sequential process, but one or more operations may be performed in parallel or simultaneously. The order of operations shown may be rearranged. A process may terminate when its operations are completed, but may have additional steps not shown in the 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 may correspond to a return of the function to the calling function or the main function.

[0198] The operations described herein 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 (e.g., computer program product) to perform the necessary tasks may be stored on a computer-readable or machine-readable medium. A processor may perform the necessary tasks. Features of the present disclosure may be implemented in hardware using, for example, hardware components such as application-specific integrated circuits (ASICs) and gate arrays. Implementation of hardware state machines to perform the functions described herein will also be apparent to those skilled in the art.

[0199] One or more features described herein may be implemented in computer-usable data and / or computer-executable instructions, such as one or more program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor or other data processing device within a computer. Computer-executable instructions may be stored on one or more computer-readable media, such as hard disks, optical disks, removable storage media, solid-state memory, RAM, etc. The functionality of the program modules may be combined or distributed as desired. Functionality may be implemented in whole or in part in firmware or hardware equivalents, such as integrated circuits, field programmable gate arrays (FPGAs), etc. Particular data structures may be used to more efficiently implement one or more features described herein, and such data structures are contemplated within the scope of the computer-executable instructions and computer-usable data described herein. Computer-readable media may include, but are not limited to, portable or non-portable storage devices, optical storage devices, and various other media capable of storing, containing, or carrying instructions and / or data. The computer-readable medium may include non-transitory media on which data may be stored and which do not include carrier waves and / or transitory electronic signals propagated via wireless or wired connections. Examples of non-transitory media include, but are not limited to, magnetic disks or tapes, optical storage media such as compact disks (CDs) or digital versatile disks (DVDs), flash memory, memory or memory devices. The computer-readable medium may store code and / or machine-executable instructions, which may represent procedures, functions, subprograms, programs, routines, subroutines, modules, software packages, classes, 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, etc.

[0200] A non-transitory tangible computer-readable medium may include instructions executable by one or more processors configured to cause the operations described herein. An article of manufacture may include a non-transitory tangible computer-readable machine-accessible medium encoded with instructions for enabling programmable hardware to cause a device (e.g., an encoder, decoder, transmitter, receiver, etc.) to perform the operations described herein. A device, or one or more devices, such as in a system, may include one or more processors, memory, interfaces, and / or the like.

[0201] Communications described herein may be determined, generated, sent, and / or received using any amount of messages, information elements, fields, parameters, values, indications, information, bits, and / or the like. While one or more examples may be described herein using any of the terms / phrases message, information element, field, parameter, value, indication, information, bit, and / or the like, those skilled in the art will understand that such communications may be implemented using any one or more of these terms, including other such terms. For example, one or more parameters, fields, and / or information elements (IEs) may include one or more information objects, values, and / or any other information. An information object may include one or more other objects. At least some (or all) parameters, fields, IEs, and / or the like may be used and may be interchangeable depending on the context. Where meanings or definitions are given, such meanings or definitions are controlling.

[0202] One or more elements of the examples described herein may be implemented as a module. A module may be an element that performs a defined function and / or has a defined interface to other elements. A module may be implemented in hardware, software combined with hardware, firmware, wetware (e.g., hardware with biological components), or a combination thereof, all of which may be behaviorally equivalent. For example, a module may be implemented as a software routine written in a computer language configured to run on a hardware machine (e.g., C, C++, Fortran, Java, Basic, Matlab, etc.) or Simulink, Stateflow, GNU Octave, or LabVIEW MathScript. Additionally or alternatively, it may be possible to implement a module using physical hardware incorporating discrete or programmable analog, digital, and / or quantum hardware. Examples of programmable hardware include computers, microcontrollers, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and / or complex programmable logic devices (CPLDs). Computers, microcontrollers, and / or microprocessors may be programmed using languages ​​such as assembly, C, C++, etc. FPGAs, ASICs, and CPLDs are often programmed using hardware description languages ​​(HDLs) such as Verilog or Verilog Hardware Description Language (VHDL), which allow for the construction of connections between the less functional internal hardware modules of the programmable device. The techniques described above can be used in combination to achieve a functionally modular result.

[0203] One or more of the operations described herein may be conditional. For example, one or more operations may be performed if certain criteria are met, such as by a computing device, a communications device, an encoder, a decoder, a network, a combination of the above, and / or the like. Exemplary criteria may be based on one or more conditions of device configuration, traffic load, initial system setup, packet size, traffic characteristics, a combination of the above, and / or the like. Various examples may be used when one or more criteria are met. It may be possible to implement any part of the examples described herein in any order and based on any condition.

[0204] While examples are described above, features and / or steps of these examples may be combined, divided, omitted, rearranged, revised, and / or extended in any desired manner. Various changes, modifications, and improvements will readily occur to those skilled in the art. Such changes, modifications, and improvements, although not expressly described herein, are intended to be part of this specification and are intended to be within the spirit and scope of the description herein. Accordingly, the foregoing description is illustrative only and not limiting.

Claims

1. 1. A method comprising: determining a neighborhood configuration of first occupancy bits indicating occupancy of a sub-cuboid associated with the point cloud frame; indexing a first buffer element index array using the first portion of the neighborhood configuration based on an amount of symbols in the first portion of the neighborhood configuration to determine a first index associated with a range of coder indices within the buffer array; indexing the buffer array; the first index associated with the range of coder indices; and determining a coder index based on a second portion of the neighborhood structure; and decoding the first occupied bit based on a context associated with the coder index.

2. The method of claim 1 , further comprising: decoding the point cloud frame using the first occupied bits.

3. The method of claim 1 , further comprising indexing the first buffer element index array based on a quantity of the symbols in the first portion of the neighborhood configuration being equal to zero.

4. The method of any one of claims 1 to 3, wherein the index associated with the range of coder indices indicates the starting position of the range of coder indices within the buffer array.

5. the buffer array is a two-dimensional array, and indexing the buffer array comprises: indexing a first dimension of the buffer array using the first index for the range of coder indices; The method of any one of claims 1 to 4, further comprising: indexing a second dimension of the buffer array using the second portion of the neighborhood configuration.

6. The method of any one of claims 1 to 5, further comprising receiving, in a bitstream, an indication of the size of the buffer array.

7. The indication of the size of the buffer array is: the amount of buffer elements in the buffer array; and 7. The method of claim 6, including indicating the depth of each of said buffer elements in said buffer array.

8. The method of claim 6 , wherein the indication of the size of the buffer array comprises an indication of a codec profile or a codec level.

9. the first buffer element index array comprising: A coder index array for the leaf-wise tree; and an amount of visitation array of the leaf-by-leaf tree.

10. 10. The method of claim 1, further comprising: determining the first index associated with the range of coder indices in the buffer array based on a global variable, the global variable being determined such that the global variable is incremented after a buffer element of the buffer array is attached to a leaf node of an optimal binary coder with on-the-fly update (OBUF) instance.

11. 11. The method of claim 10, further comprising setting the global variable to a starting value after the global variable has been incremented an amount of times equal to the amount of buffer elements in the buffer array.

12. 12. The method of claim 1, further comprising determining the first index associated with the range of coder indices in the buffer array based on a distance of a first coder index associated with the first part of the neighborhood configuration to a second coder index stored in a buffer element of the buffer array at an index associated with the second part of the neighborhood configuration.

13. 1. A computing device, comprising: one or more processors; a memory storing instructions that, when executed by said one or more processors, cause said computing device to perform a method according to any one of claims 1 to 12.

14. 1. A system comprising: a first computing device configured to perform the method of any one of claims 1 to 12; a second computing device configured to encode the first occupied bits based on a context associated with the coder index.

15. A computer readable medium storing instructions that, when executed, cause performance of the method of any one of claims 1 to 12.

Images