Patent Grant
11625866
This disclosure relates generally to compression and decompression of volumetric data, such as point cloud data, comprising a plurality of points, each having associated spatial and/or attribute information.
Various types of sensors, such as light detection and ranging (LIDAR) systems, 3-D-cameras, 3-D scanners, etc. may capture data indicating positions of points in three dimensional space, for example positions in the X, Y, and Z planes. Also, such systems may further capture attribute information in addition to spatial information for the respective points, such as color information (e.g. RGB values), intensity attributes, reflectivity attributes, motion related attributes, modality attributes, or various other attributes. In some circumstances, additional attributes may be assigned to the respective points, such as a time-stamp when the point was captured. Points captured by such sensors may make up a “point cloud” or other type of volumetric data comprising a set of points each having associated spatial information and/or one or more associated attributes. In some circumstances, a point cloud may include thousands of points, hundreds of thousands of points, millions of points, or even more points. Also, in some circumstances, volumetric data may be generated, for example in software, as opposed to being captured by one or more sensors. In either case, such volumetric data may include large amounts of data and may be costly and time-consuming to store and transmit.
In some embodiments, a system includes one or more sensors configured to capture points that collectively make up a volumetric data set, such as a point cloud, wherein each of the points comprises spatial information identifying a spatial location of the respective point and/or attribute information defining one or more attributes associated with the respective point. The system also include an encoder configured to compress the spatial and/or attribute information for the points. The encoder is configured to partition the plurality of points of the point cloud into an octree comprising a plurality of cubes and sub-cubes at different levels of the octree, wherein respective ones of the cubes comprises eight sub-cubes. Additionally, the encoder is configured to, for at least some of the nodes of the octree further encode spatial information for the at least some nodes using a predictive tree structure. Alternatively, the encoder may be configured to organize points using a predictive tree structure that includes one or more octrees stemming from nodes of the predictive tree. For example, a point cloud comprising points in three dimensional space may be encoded as a predictive tree that joins a plurality of octrees into a structure that collectively represents the spatial information of the point cloud. Also, in some embodiments, adaptive octree models may be used that permit coding of non-cubic volumes, which may result in some nodes of the octree having four or two sub-volumes (e.g. cuboids).
In some embodiments, an encoder as described above may further encode duplicate points that reside at a same or similar spatial location in 3D space. In some embodiments, in order to encode duplicate points, an encoder may signal a number of duplicate points for a respective node of a predictive tree, a node of an octree, or a node of a structure that incorporates both octree(s) and predictive tree(s). For example, instead of encoding multiple predictive trees to define two points that share the same spatial location in 3D space, an encoder may encode a single predictive tree that defines the location of the node and may further signal a number of points that reside at the spatial location (e.g. two points, three points, etc.). In some embodiments, it may be more efficient from a compression and signaling perspective to signal a quantity of duplicate points at a given node as opposed to signaling an additional predictive tree or additional octree nodes that have the same spatial location as another point of a signaled predictive tree or octree node.
In some embodiments, a method may include signaling spatial information for volumetric data, such as that of a point cloud, using a combination of predictive trees and octrees, as discussed above and herein. Also the method may include signaling duplicative points for nodes of the predictive tree or octree, as discussed above and herein. In some embodiments, a method may include a decoder receiving compressed volumetric data that has been compressed using a combination octree and predictive tree structure and/or signaled duplicate points as discussed above and herein, wherein the decoder uses the compressed volumetric data to reconstruct a three-dimensional geometry of the volumetric data, such as a geometry of a point cloud.
In some embodiments, a non-transitory computer readable medium stores program instructions, that when executed by one or more processors, cause the one or more processor to encode or decode volumetric data using a combination of predictive trees and octrees and/or signaled duplicate points, as described herein.
Various examples are described herein in terms of a point cloud. However, the encoder/encoding techniques and the decoder/decoding techniques described herein may be applied to various other types of 3D volumetric content representations, including meshes, three-degree of freedom plus (3DOF+) scenes or as alternatively referred to in some contexts as MPEG MIV material, lightfields, or other types of six-degree of freedom (6DOF) content.
This specification includes references to “one embodiment” or “an embodiment.” The appearances of the phrases “in one embodiment” or “in an embodiment” do not necessarily refer to the same embodiment. Particular features, structures, or characteristics may be combined in any suitable manner consistent with this disclosure.
“Comprising.” This term is open-ended. As used in the appended claims, this term does not foreclose additional structure or steps. Consider a claim that recites: “An apparatus comprising one or more processor units . . . .” Such a claim does not foreclose the apparatus from including additional components (e.g., a network interface unit, graphics circuitry, etc.).
“Configured To.” Various units, circuits, or other components may be described or claimed as “configured to” perform a task or tasks. In such contexts, “configured to” is used to connote structure by indicating that the units/circuits/components include structure (e.g., circuitry) that performs those task or tasks during operation. As such, the unit/circuit/component can be said to be configured to perform the task even when the specified unit/circuit/component is not currently operational (e.g., is not on). The units/circuits/components used with the “configured to” language include hardware—for example, circuits, memory storing program instructions executable to implement the operation, etc. Reciting that a unit/circuit/component is “configured to” perform one or more tasks is expressly intended not to invoke 35 U.S.C. § 112(f), for that unit/circuit/component. Additionally, “configured to” can include generic structure (e.g., generic circuitry) that is manipulated by software and/or firmware (e.g., an FPGA or a general-purpose processor executing software) to operate in manner that is capable of performing the task(s) at issue. “Configure to” may also include adapting a manufacturing process (e.g., a semiconductor fabrication facility) to fabricate devices (e.g., integrated circuits) that are adapted to implement or perform one or more tasks.
“First,” “Second,” etc. As used herein, these terms are used as labels for nouns that they precede, and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.). For example, a buffer circuit may be described herein as performing write operations for “first” and “second” values. The terms “first” and “second” do not necessarily imply that the first value must be written before the second value.
“Based On.” As used herein, this term is used to describe one or more factors that affect a determination. This term does not foreclose additional factors that may affect a determination. That is, a determination may be solely based on those factors or based, at least in part, on those factors. Consider the phrase “determine A based on B.” While in this case, B is a factor that affects the determination of A, such a phrase does not foreclose the determination of A from also being based on C. In other instances, A may be determined based solely on B.
As data acquisition and display technologies have become more advanced, the ability to capture volumetric data, such as point clouds, comprising thousands or millions of points in 2-D or 3-D space, such as via LIDAR systems, has increased. Also, the development of advanced display technologies, such as virtual reality or augmented reality systems, has increased potential uses for volumetric data, such as point clouds. However, point cloud files are often very large and may be costly and time-consuming to store and transmit. For example, communication of point clouds over private or public networks, such as the Internet, may require considerable amounts of time and/or network resources, such that some uses of point cloud data, such as real-time uses, may be limited. Also, storage requirements of point cloud files may consume a significant amount of storage capacity of devices storing the point cloud files, which may also limit potential applications for using point cloud data.
In some embodiments, an encoder may be used to generate a compressed point cloud to reduce costs and time associated with storing and transmitting large point cloud files. In some embodiments, a system may include an encoder that compresses attribute information and/or spatial information (also referred to herein as geometry information) of a point cloud file such that the point cloud file may be stored and transmitted more quickly than non-compressed point clouds and in a manner such that the point cloud file may occupy less storage space than non-compressed point clouds. In some embodiments, compression of spatial information and/or attributes of points in a point cloud may enable a point cloud to be communicated over a network in real-time or in near real-time. For example, a system may include a sensor that captures spatial information and/or attribute information about points in an environment where the sensor is located, wherein the captured points and corresponding attributes make up a point cloud. The system may also include an encoder that compresses the captured point cloud spatial and attribute information. The compressed spatial and attribute information of the point cloud may be sent over a network in real-time or near real-time to a decoder that decompresses the compressed spatial and attribute information of the point cloud. The decompressed point cloud may be further processed, for example to make a control decision based on the surrounding environment at the location of the sensor. The control decision may then be communicated back to a device at or near the location of the sensor, wherein the device receiving the control decision implements the control decision in real-time or near real-time. In some embodiments, the decoder may be associated with an augmented reality system and the decompressed spatial and/or attribute information may be displayed or otherwise used by the augmented reality system. In some embodiments, compressed attribute information for a point cloud may be sent with compressed spatial information for points of the point cloud. In other embodiments, spatial information and attribute information may be separately encoded and/or separately transmitted to a decoder.
In some embodiments, a system may include a decoder that receives one or more point cloud files comprising compressed attribute information via a network from a remote server or other storage device that stores the one or more point cloud files. For example, a 3-D display, a holographic display, or a head-mounted display may be manipulated in real-time or near real-time to show different portions of a virtual world represented by point clouds. In order to update the 3-D display, the holographic display, or the head-mounted display, a system associated with the decoder may request point cloud files from the remote server based on user manipulations of the displays, and the point cloud files may be transmitted from the remote server to the decoder and decoded by the decoder in real-time or near real-time. The displays may then be updated with updated point cloud data responsive to the user manipulations, such as updated point attributes.
In some embodiments, a system, may include one or more LIDAR systems, 3-D cameras, 3-D scanners, etc., and such sensor devices may capture spatial information, such as X, Y, and Z coordinates for points in a view of the sensor devices. In some embodiments, the spatial information may be relative to a local coordinate system or may be relative to a global coordinate system (for example, a Cartesian coordinate system may have a fixed reference point, such as a fixed point on the earth, or may have a non-fixed local reference point, such as a sensor location).
In some embodiments, such sensors may also capture attribute information for one or more points, such as color attributes, reflectivity attributes, velocity attributes, acceleration attributes, time attributes, modalities, and/or various other attributes. In some embodiments, other sensors, in addition to LIDAR systems, 3-D cameras, 3-D scanners, etc., may capture attribute information to be included in a point cloud. For example, in some embodiments, a gyroscope or accelerometer, may capture motion information to be included in a point cloud as an attribute associated with one or more points of the point cloud. For example, a vehicle equipped with a LIDAR system, a 3-D camera, or a 3-D scanner may include the vehicle's direction and speed in a point cloud captured by the LIDAR system, the 3-D camera, or the 3-D scanner. For example, when points in a view of the vehicle are captured they may be included in a point cloud, wherein the point cloud includes the captured points and associated motion information corresponding to a state of the vehicle when the points were captured.
In some embodiments, attribute information may comprise string values, such as different modalities. For example attribute information may include string values indicating a modality such as “walking”, “running”, “driving”, etc. In some embodiments, an encoder may comprise a “string-value” to integer index, wherein certain strings are associated with certain corresponding integer values. In some embodiments, a point cloud may indicate a string value for a point by including an integer associated with the string value as an attribute of the point. The encoder and decoder may both store a common string value to integer index, such that the decoder can determine string values for points based on looking up the integer value of the string attribute of the point in a string value to integer index of the decoder that matches or is similar to the string value to integer index of the encoder.
In some embodiments, an encoder compresses and encodes spatial information of a point cloud in addition to compressing attribute information for attributes of the points of the point cloud. For example, to compress spatial information a combination predictive tree and octree may be generated wherein, respective occupied/non-occupied states of each cube and/or sub-cube of the octree are encoded. For some nodes instead of encoding additional lower level octree sub-cubes, a predictive tree may be encoded for the node. Alternatively a predictive tree may predict a set of occupied nodes of the predictive tree and points that occupy respective ones of the nodes may further be defined in 3D space by respective octrees corresponding to respective ones of the occupied nodes of the predictive tree. Additionally, in some embodiments, an encoder may signal a number of duplicate points for a given point. This may be more efficient than generating redundant octree and/or predictive tree structures to define two points that have the same or similar spatial locations in 3D space.
In some embodiments, an encoder and/or decoder may determine a neighborhood occupancy configuration for a given cube of an octree that is being encoded or decoded. The neighborhood occupancy configuration may indicate occupancy states of neighboring cubes that neighbor the given cube being encoded. For example, a cube with for which neighboring cubes are occupied is more likely to also include occupied sub-cubes than a cube for which neighboring cubes are un-occupied.
System 100 includes sensor 102 and encoder 104. Sensor 102 captures a point cloud 110 comprising points representing structure 106 in view 108 of sensor 102. For example, in some embodiments, structure 106 may be a mountain range, a building, a sign, an environment surrounding a street, or any other type of structure. In some embodiments, a captured point cloud, such as captured point cloud 110, may include spatial and attribute information for the points included in the point cloud. For example, point A of captured point cloud 110 comprises X, Y, Z coordinates and attributes 1, 2, and 3. In some embodiments, attributes of a point may include attributes such as R, G, B color values, a velocity at the point, an acceleration at the point, a reflectance of the structure at the point, a time stamp indicating when the point was captured, a string-value indicating a modality when the point was captured, for example “walking”, or other attributes. The captured point cloud 110 may be provided to encoder 104, wherein encoder 104 generates a compressed version of the point cloud (compressed point cloud information 112) that is transmitted via network 114 to decoder 116. In some embodiments, a compressed version of the point cloud, such as compressed point cloud information 112, may be included in a common compressed point cloud that also includes compressed spatial information for the points of the point cloud or, in some embodiments, compressed spatial information and compressed attribute information may be communicated as separate files.
In some embodiments, encoder 104 may be integrated with sensor 102. For example, encoder 104 may be implemented in hardware or software included in a sensor device, such as sensor 102. In other embodiments, encoder 104 may be implemented on a separate computing device that is proximate to sensor 102.
At 150, a volumetric data set, such as a point cloud, is partitioned into an octree comprising cubes and sub-cubes for at least a first level of the octree.
At 152, it is determined whether occupied ones of the cubes are to be further partitioned into sub-cubes, for example each cube may be partitioned into eight child sub-cubes. In some embodiments, each cube or sub-cube of an octree may be referred to herein as a node or sub-node of the octree. Also relationships between nodes and sub-nodes may be referred to herein as child nodes, parent nodes, grandparent nodes etc. For example a parent node (e.g. cube) may be partitioned into eight child nodes (e.g. sub-cubes). Also each child node may be further partitioned into eight grandchild nodes, etc. However, not every node occupied by two or more points may be further partitioned. For example for some nodes it may be determined that better coding efficiency may be achieved by defining the positions of the points in the occupied node using a predictive tree instead of using further octree nodes. Thus, at 154, it is determined whether respective ones of the occupied nodes or sub-nodes of the octree are to have their points encoded using a predictive tree.
At 156, occupancy information is generated for the occupied sub-cubes determined to be further partitioned. Also at 156, predictive tree information is generated for the occupied sub-cubes for which it was determined to define the location of the points of the occupied sub-cubes using a predictive tree structure.
At 158, it is determined if there are additional octree levels to encode, if so the process reverts to 152 and repeats for the next octree level. If not, at 160, the generated octree occupancy information and the generated predictive tree structures are encoded, for example using an arithmetic encoder or a Golomb encoder, as a few examples. At 162, the encoded geometry information is sent or stored for later use in reconstructing the geometry of the compressed point cloud.
Octree coding is a method that represents a sparse geometry by encoding the structure of an octree. The octree has a known depth, and therefore represents a cube of a known volume, e.g. (2{circumflex over ( )}d){circumflex over ( )}3. By construction, each octree node has between one and eight child nodes (e.g. sub-cubes). The position of a point is encoded as the path through the octree. Each node of the tree contains a bitmap representing which child nodes are present. This bitmap is called the occupancy map, or occupancy information for a node.
Since the occupied state of a child node (e.g. sub-cube) is binary (present vs not present), it is not possible to predict occupancy by subtraction of a prediction. Instead, the occupancy map is encoded in a bit-serial manner using a context adaptive arithmetic entropy coder. Contexts may be selected by the following means:
For example,
In sparse regions, octree coding may not efficiently encode geometry. For example, for nodes (e.g. cubes or sub-cubes of an octree) with only a single occupied child, instead of coding an 8 bin occupancy map, a three bin child index may be coded instead. If a point is isolated, it may be preferable to directly code the remaining position since compression efficiency may be low (since there is no means to select contexts) and processing costs may be significantly reduced by early termination of the subtree.
In order to avoid signaling a termination flag in every node, a node may only contain an early termination flag if it is suitably isolated as determined by the 6-neighbours and parent occupancy. Such a node may be said to use an Inferred Direct Coding Mode (IDCM).
A predictive tree geometry coder that encodes spatial information using a predictive tree structure may represent point locations as nodes in a tree. The tree may be traversed depth-first, with each node having the following properties:
For example, prediction modes of a predictive tree geometry coder may include:
However, in some embodiments, to improve encoding efficiency and/or latency of encoding/decoding spatial information for a point cloud, the octree method and the predictive tree method may be combined.
For example, in some embodiments, one or more predictive trees may be used to refine an octree leaf node, irrespective of how the leaf mode is selected.
For an octree with maximum depth (height) H, each octree node represents a cube volume of size (2{circumflex over ( )}(H−D)){circumflex over ( )}3, where D is the tree depth (level) at which the node resides. The root node represents a volume of (2{circumflex over ( )}H){circumflex over ( )}3. A leaf node is a node that, for whatever reason, is not further subdivided. Depending upon the exact octree representation, a leaf node may appear at any depth of the octree. By construction, the existence of an octree node implies that it is occupied (e.g. at least one point is present within its volume).
In some embodiments, an octree encoding method and a predictive tree encoding method may be combined such that predictive coding is performed to generate one or more predictive trees within (or associated with) one or more octree leaf nodes. In some embodiments, all or only some leaf nodes of an octree may be further refined by a predictive tree coding scheme. For example,
In some embodiments, an octree encoding method is used to partially encode a point cloud volume. For example, for a cubic volume of size (2{circumflex over ( )}H){circumflex over ( )}3, the first N, with N<H, octree levels are first coded. Subsequently, the resulting leaf nodes are further refined using a predictive tree coding scheme.
In some embodiments, each octree node identified as being an IDCM node is, instead of having a directly coded remaining position, further refined by a predictive tree coding scheme.
An octree may provide a means to quantize the represented position information in a uniform or non-uniform manner. This may be called in-tree, or in-loop position quantization or scaling. Each position may be quantized by a step size, and only the quantized information may be encoded. During reconstruction, after decoding the quantized point position, the quantized position may be scaled by a scale factor. If the step size is sufficiently large, multiple points may be merged into a single coarser position. The quantization step size may be specified or determined on a per-node basis, or for a set of nodes. In some embodiments, the octree leaf nodes generated by in-tree quantization may be further refined using a predictive tree coder.
In some embodiments, a leaf node of an octree may be encoded, wherein an encoder conditionally chooses the refinement method employed. For example, a flag may be set to indicate if only a limited number of points are present in the leaf, in which case a direct coding mode may be used instead. Other embodiments may conditionally enable the predictive tree coding scheme based upon the local geometry around the leaf node, or around one or more of its ancestor nodes, or alternatively upon the type of leaf node (e.g., inferred direct coding mode vs. quantized leaf).
In some embodiments, octree leaf nodes encoded using inferred direct coding (IDCM) are excluded from further refinement by a predictive tree coder.
Some octree coding schemes may include explicit support for handling duplicate points, that is, multiple points with the same position. Since an octree structure cannot represent the same position twice, information is added to leaf nodes to indicate that a reconstructed point is to be repeated (duplicated) a certain number of times. When combining octree leaf nodes with a predictive tree coding scheme, the duplicate point count may not be signaled by the octree leaf node, rather, this may be handled by the predictive tree since the predictive tree is capable of representing more than one distinct point.
For a leaf node that employs predictive tree coding, one or more predictive coding trees may be signaled. For example, in some embodiments, the predictive tree may be constrained to lie within the bounds of the octree node. In such an embodiment, the binarisation of the residual magnitude may be limited to the size of the leaf node. For example,
In other embodiments, the predictive tree may be allowed to exceed the bounds of the octree node within which it resides. In such an embodiment, an encoder may use such a scheme to merge points from neighboring nodes into a single prediction tree and avoid signaling that the neighboring nodes are occupied. This may be of benefit when one node contains a large number of points that just spill into the neighboring node, where instead of having to code two independent trees in neighboring nodes, a single tree is encoded. In some embodiments, the binarization of the residual magnitude may be limited to a size slightly larger than the octree node, thereby permitting some points from neighboring nodes to be merged, while maintaining compression efficiency in the residual magnitude representation.
For example,
Also
In some embodiments, different octree nodes may include independently determined predictive trees. For example, an independent predictive tree coding scheme may be informed of the number of output points that are to be produced by the set of predictive trees. After completing each predictive tree, if the total number of reconstructed points is not reached, a new tree may be implicitly started.
Signaling the number of points represented by the predictive trees refining an octree leaf node may be inefficient for compression, especially since the tree traversal (representation) is self-terminating. If only a single predictive tree is allowed per node then no node level point count information is sent. If multiple predictive trees are to be permitted, after coding each tree a single entropy coded flag may be signaled to indicate if the node is complete or if at least one additional tree follows.
Ordinarily, the first point (node) in the predictive coding tree must use the PCM mode (since there are no parent nodes to predict from). The PCM mode is effectively a prediction from (0,0,0). While it is possible to use the (0,0,0) position as the origin of each tree, it does not make full use of the information encoded in the octree. Each node of the octree represents a position quantized by 2{circumflex over ( )}(H−D); this is sometimes called a partial position, or the position of the node at depth D.
In some embodiments, the scaled quantized position of the node (or some value associated with it) may be used as an offset to be applied to all positions reconstructed from the predictive coding trees present within the node. If pN is the quantized node position, Ps={Ps[0], . . . Ps[n]} may be the predictive coding tree outputs, and f(pN) may be a function that describes the position of the local origin for the predictive coding tree. If so, then the reconstructed point positions associated with the octree leaf node are Ps[i]+f(pN).
In some embodiments, f(pN) may be pN*2{circumflex over ( )}(N−D), describing the position of the ‘bottom left’ corner of the node relative to the octree origin.
In some embodiments, f(pN) may be pN*2{circumflex over ( )}(N−D)+2{circumflex over ( )}(N−D−1), describing the center of the node relative to the octree origin.
In some embodiments, f(pN) may be pN*2{circumflex over ( )}(N−D)+NeighBias, where the centroid for the node is determined by the occupancy of neighboring octree nodes.
In some embodiments, points using the PCM mode may instead be predicted from f(Pn), rather than (0,0,0). This may avoid the need to apply an offset to each point position as an additional operation. It should be noted that in systems using integer arithmetic, these two embodiments may not be equivalent.
In some embodiments, the first point may be encoded using the PCM mode predicted from f(Pn), the second point may be encoded using one of the PCM modes that uses a prediction from a different value of f(Pn). In such an embodiment the n'th PCM point may use a prediction different from all previous values of f(Pn). The rationale for such a design is that the predictive tree can represent the local geometry around the initial origin. A second tree should be somehow disconnected from the first (otherwise its points can be represented in the first tree). Therefore the value of the PCM origin should change. One such design would use the octree node center for the first, each of the eight node corners for the next eight uses, etc.
In some embodiments, the entropy coders associated with the predictive tree may be retained for use by subsequent trees generated by the same octree. Alternatively, the context state associated with the coders may be reset at the start of each node, or octree level. A flag may be used to indicate if the context state should be reset.
In an octree-only or predictive-tree-only coding scheme, the encoded tree representation will typically form a contiguous stream of entropy coded symbols. When the two schemes are combined, it may be necessary to further take into account how the data for each scheme should be multiplexed together.
In some embodiments, as soon as a leaf node is identified with predictive tree data present, the predictive tree data may be immediately multiplexed into the coded symbol stream. However, this may result in inefficiency for an implementation (especially a decoder) which may have to save the octree decoding state and switch tasks to decoding the predictive tree data for the leaf node, before resuming the octree decoding. (This task switching is necessary since the only way to skip over a chunk of arithmetically coded symbols is to decode them according to their syntax and semantics). Switching tasks increases the implementation state requirements and may reduce the effective data/instruction locality due to cache effects arising from interleaving the two workloads.
In some embodiments, an alternative to interleaving the data on a per-node basis is to separate the octree and predictive trees into different phases. In the first phase (octree processing), leaf nodes that use predictive tree coding are recorded. After octree coding is complete, each leaf node is processed in turn to encode or decode the corresponding predictive tree(s). In effect all the octree entropy coded symbols are contiguous (ignoring any other coded data that may be multiplexed with the octree data such as attribute data), and are followed by the contiguous entropy coded predictive tree symbols.
In some embodiments, a balance between the two extremes (per-node interleaving vs. sequential processes) may involve interleaving on a per octree level basis. Wherein, any leaf nodes encountered during the coding of an octree level are recorded and deferred for predictive tree coding until the end of the level.
In some embodiments, the encoded predictive tree data may reside in a different entropy encoded sub stream than the octree occupancy information. Pointers, embedded length fields, or other external means may identify the start of each sub stream. The sub streams may then be encoded or decoded independently in a parallel manner. One such arrangement is to put predictive tree data into a separate slice/dependent slice/entropy slice/data unit.
An efficient octree coder makes extensive use of contextualization to entropy code node occupancy information. One such example is, for a breadth-first tree traversal, contextualization based upon the occupancy of neighboring nodes. For example, a node surrounded by four occupied neighbors left, right, front and back, is likely to have a different occupancy to a node that just has a single occupied neighbor.
In the context of a combined octree and predictive tree encoder, it may be desirable to allow information determined from the predictive tree to inform the neighbor determination process of the octree. Such a feature may be available if the predictive tree data of an octree node is decoded during octree reconstruction due to causality. In order to make the neighborhood information available, the reconstructed points from the predictive tree(s) must be converted into an octree representation and inserted into the octree being decoded. This is performed by recursively determining occupancy until all levels of the subtree are represented. The new octree subtree is marked as a not-to-be-decoded node and inserted into the octree to replace the originating node. Such a process may be interleaved with normal octree decoding in a similar manner to octree construction. The first level occupancy is determined and child nodes are added to the queue (fifo) of nodes to be processed. Each time a not-to-be-decoded node is encountered by the octree traversal process (e.g. removed from the queue/fifo) its child occupancy is determined without decoding any further information.
In some embodiments, instead of including predictive trees in octree nodes, the reverse may be performed. For example, for a point cloud with sparse and dense regions, a predictive tree may be used to create a structure defining relationships between the dense regions and the respective dense regions may be defined using separate octree at leaf nodes of the predictive tree. In some embodiments, whether or not to encode a given region using an octree structure or a predictive tree structure may be determined based on respective point densities of the regions. For example, regions with point densities less than a threshold density may be encoded using a predictive tree structure, while other regions with point densities greater than the threshold density may be encoded using an octree structure.
For example, while octree coding can be an efficient means to compress dense geometry information, it comes at the price of latency, especially if the tree is represented or traversed in a breadth-first manner. For instance, in order to code the occupancy map of the root node, it is necessary to know the occupancy of the eight children. For any unoccupied child, this is not knowable without observing all points in the point cloud. In contrast, a predictive tree coder is capable of representing points in acquisition order with an encoder defined latency depending upon the tree construction, enabling bounded low-latency applications. If a predictive tree coder is used to refine the leaf nodes of the octree, then the system as a whole retains the high latency characteristics of the octree. An alternative construction is to use the predictive tree coder first to represent the root node positions of multiple octrees (one octree per predictive tree node).
In some embodiments, for a point cloud comprising P-bit position information, the first M common bits of each position may be coded using a predictive tree coder. Each M-bit position produced by the predictive tree coder may further be refined into a set of output points by an octree with a root node at the same M-bit position. In some embodiments each predictive tree node may indicate the number of M-bits it represents, thereby controlling the extent of the octree refining that node. It should be understood that the values of P and M may vary for each of the x, y, and z position components. For example, a point cloud representing the internal structure of a building may contain a combination of dense regions (walls) and sparse voids (rooms). Such a point cloud may be more efficiently coded by encoding each wall using a non-cubic octree that is narrow, wide and high, while the location of the wall in the room is encoded using the predictive tree.
In other embodiments, the predictive tree coder may represent the full P-bit position of a subset of the point cloud points, called seed points. An M-bit octree is constructed around each seed position, such that the octree contains the seed position. In order to avoid coding inefficiency, some embodiments can infer that octree nodes spatially containing the seed position must be occupied and can avoid signaling any corresponding occupancy information. In some embodiments, it can be inferred that octree nodes spatially adjacent to a node containing the seed position are adjacent to an occupied node, even though occupancy information indicating the nodes presence has not been signaled.
Also in some embodiments other combinations of predictive trees and octrees may be combined. For example a “sandwich” type model may use a predictive tree at a high level that includes octrees at leaf nodes of the predictive tree. Additionally, leaf nodes of the octree may include lower level predictive trees for the respective leaf nodes of the octree.
In another embodiment, a predictive tree coding layer may exist between two octree coding layers, in effect, replacing a number of octree levels in a single octree. In some embodiments, the octree levels subsequent to the predictive tree coding layer comprise a single logical octree. To use the octree of
Duplicate Points
For sequences with large numbers of duplicate points (e.g. point residing at the same or similar spatial location) inefficiency may be reduced by adding a per-node count of the number of duplicate points. This may be signaled using an exp-golomb code (or another code depending upon the expected distribution of duplicate points, for example, a first arithmetically encoded flag may be signaled to indicate if there is at least one duplicate point, and if there is at least one duplicate point, the number of duplicate points minus one is encoded). During reconstruction a decoder may insert the duplicate points into the output buffer and ensure that the indices of any duplicate points are not used as prediction of subsequent tree nodes.
In some embodiments, an encoder may identify duplicate points in various ways. If points are expected to arrive in order, for example in Morton order, or capture order, duplicate points can be expected to be sequential in the stream. In such a case, at the start of processing each input point, the encoder looks ahead for duplicate points (possibly within a window for low-latency cases).
Signaling the duplicate count for each node is easy to parse, but means that each node has the overhead of signaling a duplicate count (even if it the zero symbol can be compressed well due to efficient entropy coding). An alternative approach may only present the duplicate count syntax element when particular conditions are met as follows. If the node uses DPCM (direct pulse code modulation) prediction (e.g. uses a single parent for prediction) and has a zero residual, the duplicate count is sent. The effect of this is that duplicate points require two nodes for signaling. The first indicates the initial point, the second indicates the duplicate count.
In some embodiments, the conditionality on the zero residual is removed, and instead, all nodes using dpcm prediction may signal the duplicate point count.
In some embodiments, the node with a positive duplicate point count is considered as a terminal (leaf) node of the prediction tree and may not be used for further prediction. In these embodiments, it is not necessary to signal the child count.
In some embodiments, the duplicate point count may only be present in the first child node. For example, if four points are to be encoded, three of which have identical positions, the tree is constructed as a first node (that contains no duplicate point count) with two child nodes, the first child contains a duplicate point count, and the second child does not. In another embodiment, the duplicate point count (when present) is the first value signaled in a node and conditionality is only upon the node being a first child. This may be of benefit if the cost of signaling the mode information is greater than the cost of signaling the duplicate point count for first child nodes.
In some embodiments, instead of being contextualized on the DPCM prediction mode, a dedicated prediction mode may be used that indicates the duplicate point count without a residual.
In embodiments where octree coding refines the output of a predictive tree coder, only a single octree needs to be represented by each predictive tree node and the ability for the predictive coder to explicitly signal a duplicate point count is disabled.
Encoder 602 may be a similar encoder as encoder 104 illustrated in
In some embodiments, a spatial encoder, such as spatial encoder 604, may compress spatial information associated with points of a point cloud, such that the spatial information can be stored or transmitted in a compressed format. In some embodiments, a spatial encoder, such as spatial encoder 604, may utilize octrees and/or predictive trees to compress spatial information for points of a point cloud as discussed in more detail herein.
In some embodiments, compressed spatial information may be stored or transmitted with compressed attribute information or may be stored or transmitted separately. In either case, a decoder receiving compressed attribute information for points of a point cloud may also receive compressed spatial information for the points of the point cloud, or may otherwise obtain the spatial information for the points of the point cloud.
An octree/predictive tree generator, such as octree/predictive tree generator 610, may utilize spatial information for points of a point cloud to generate an octree that subdivides a point cloud into cubes and sub-cubes. Furthermore the octree may include one or more predictive trees. Or, a predictive tree may include one or more octrees.
A prediction/correction evaluator, such as prediction/correction evaluator 606 of encoder 602, may determine predicted attribute values for points of a point cloud based on an inverse distance interpolation method using attribute values of the K-nearest neighboring points of a point for whom an attribute value is being predicted. The prediction/correction evaluator may also compare a predicted attribute value of a point being evaluated to an original attribute value of the point in a non-compressed point cloud to determine an attribute correction value. In some embodiments, a prediction/correction evaluator, such as prediction/correction evaluator 606 of encoder, 602 may adaptively adjust a prediction strategy used to predict attribute values of points in a given neighborhood of points based on a measurement of the variability of the attribute values of the points in the neighborhood.
An outgoing data encoder, such as outgoing data encoder 608 of encoder 602, may encode attribute correction values and assigned attribute values included in a compressed attribute information file for a point cloud. In some embodiments, an outgoing data encoder, such as outgoing data encoder 608, may select an encoding context for encoding a value, such as an assigned attribute value or an attribute correction value, based on a number of symbols included in the value. In some embodiments, values with more symbols may be encoded using an encoding context comprising Golomb exponential encoding, whereas values with fewer symbols may be encoded using arithmetic encoding. In some embodiments, encoding contexts may include more than one encoding technique. For example, a portion of a value may be encoded using arithmetic encoding while another portion of the value may be encoded using Golomb exponential encoding. In some embodiments, an encoder, such as encoder 602, may include a context store, such as context store 616, that stores encoding contexts used by an outgoing data encoder, such as outgoing data encoder 608, to encode attribute correction values and assigned attribute values.
In some embodiments, an encoder, such as encoder 602, may also include an incoming data interface, such as incoming data interface 614. In some embodiments, an encoder may receive incoming data from one or more sensors that capture points of a point cloud or that capture attribute information to be associated with points of a point cloud. For example, in some embodiments, an encoder may receive data from an LIDAR system, 3-D-camera, 3-D scanner, etc. and may also receive data from other sensors, such as a gyroscope, accelerometer, etc. Additionally, an encoder may receive other data such as a current time from a system clock, etc. In some embodiments, such different types of data may be received by an encoder via an incoming data interface, such as incoming data interface 614 of encoder 602.
In some embodiments, an encoder, such as encoder 602, may further include a configuration interface, such as configuration interface 612, wherein one or more parameters used by the encoder to compress a point cloud may be adjusted via the configuration interface. In some embodiments, a configuration interface, such as configuration interface 612, may be a programmatic interface, such as an API. Configurations used by an encoder, such as encoder 602, may be stored in a configuration store, such as configuration store 618.
In some embodiments, an encoder, such as encoder 602, may include more or fewer components than shown in
Decoder 620 may be a similar decoder as decoder 116 illustrated in
A decoder, such as decoder 620, may receive an encoded compressed point cloud and/or an encoded compressed attribute information file for points of a point cloud. For example, a decoder, such as decoder 620, may receive a compressed attribute information file and/or a compressed spatial information file. The compressed attribute information file and/or compressed spatial information file may be received by a decoder via an encoded data interface, such as encoded data interface 626. The encoded compressed point cloud may be used by the decoder to determine spatial information for points of the point cloud. For example, spatial information of points of a point cloud included in a compressed point cloud may be generated by a spatial decoder, such as spatial decoder 622. In some embodiments, a compressed point cloud may be received via an encoded data interface, such as encoded data interface 626, from a storage device or other intermediary source, wherein the compressed point cloud was previously encoded by an encoder, such as encoder 104. In some embodiments, an encoded data interface, such as encoded data interface 626, may decode spatial information. For example the spatial information may have been encoded using various encoding techniques as described herein.
A prediction evaluator of a decoder, such as prediction evaluator 624, may select a starting point of a minimum spanning tree based on an assigned starting point included in a compressed attribute information file. In some embodiments, the compressed attribute information file may include one or more assigned values for one or more corresponding attributes of the starting point. In some embodiments, a prediction evaluator, such as prediction evaluator 624, may assign values to one or more attributes of a starting point in a decompressed model of a point cloud being decompressed based on assigned values for the starting point included in a compressed attribute information file. A prediction evaluator, such as prediction evaluator 624, may further utilize the assigned values of the attributes of the starting point to determine attribute values of neighboring points. For example, a prediction evaluator may select a next nearest neighboring point to the starting point as a next point to evaluate, wherein the next nearest neighboring point is selected based on a shortest distance to a neighboring point from the starting point in the minimum spanning tree. Note that because the minimum spanning tree is generated based on the same or similar spatial information at the decoder as was used to generate a minimum spanning tree at an encoder, the decoder may determine the same evaluation order for evaluating the points of the point cloud being decompressed as was determined at the encoder by identifying next nearest neighbors in the minimum spanning tree.
A decoder, such as decoder 620, may provide a decompressed point cloud generated based on a received compressed point cloud and/or a received compressed attribute information file to a receiving device or application via a decoded data interface, such as decoded data interface 628. The decompressed point cloud may include the points of the point cloud and attribute values for attributes of the points of the point cloud. In some embodiments, a decoder may decode some attribute values for attributes of a point cloud without decoding other attribute values for other attributes of a point cloud. For example, a point cloud may include color attributes for points of the point cloud and may also include other attributes for the points of the point cloud, such as velocity, for example. In such a situation, a decoder may decode one or more attributes of the points of the point cloud, such as the velocity attribute, without decoding other attributes of the points of the point cloud, such as the color attributes.
In some embodiments, the decompressed point cloud and/or decompressed attribute information file may be used to generate a visual display, such as for a head mounted display. Also, in some embodiments, the decompressed point cloud and/or decompressed attribute information file may be provided to a decision making engine that uses the decompressed point cloud and/or decompressed attribute information file to make one or more control decisions. In some embodiments, the decompressed point cloud and/or decompressed attribute information file may be used in various other applications or for various other purposes.
Example Applications for Point Cloud Compression and Decompression
In some embodiments, a sensor, such as sensor 102, an encoder, such as encoder 104 or encoder 202, and a decoder, such as decoder 116 or decoder 220, may be used to communicate point clouds in a 3-D application. For example, a sensor, such as sensor 102, at 702 may capture a 3D image and at 704, the sensor or a processor associated with the sensor may perform a 3D reconstruction based on sensed data to generate a point cloud.
At 706, an encoder such as encoder 104 or 202 may compress the point cloud and at 708 the encoder or a post processor may packetize and transmit the compressed point cloud, via a network 710. At 712, the packets may be received at a destination location that includes a decoder, such as decoder 116 or decoder 220. The decoder may decompress the point cloud at 714 and the decompressed point cloud may be rendered at 716. In some embodiments a 3-D application may transmit point cloud data in real time such that a display at 716 represents images being observed at 702. For example, a camera in a canyon may allow a remote user to experience walking through a virtual canyon at 716.
In some embodiments, point clouds may be generated in software (for example as opposed to being captured by a sensor). For example, at 802 virtual reality or augmented reality content is produced. The virtual reality or augmented reality content may include point cloud data and non-point cloud data. For example, a non-point cloud character may traverse a landscape represented by point clouds, as one example. At 804, the point cloud data may be compressed and at 806 the compressed point cloud data and non-point cloud data may be packetized and transmitted via a network 808. For example, the virtual reality or augmented reality content produced at 802 may be produced at a remote server and communicated to a VR or AR content consumer via network 808. At 810, the packets may be received and synchronized at the VR or AR consumer's device. A decoder operating at the VR or AR consumer's device may decompress the compressed point cloud at 812 and the point cloud and non-point cloud data may be rendered in real time, for example in a head mounted display of the VR or AR consumer's device. In some embodiments, point cloud data may be generated, compressed, decompressed, and rendered responsive to the VR or AR consumer manipulating the head mounted display to look in different directions.
In some embodiments, point cloud compression as described herein may be used in various other applications, such as geographic information systems, sports replay broadcasting, museum displays, autonomous navigation, etc.
Example Computer System
Various embodiments of a point cloud encoder or decoder, as described herein may be executed in one or more computer systems 900, which may interact with various other devices. Note that any component, action, or functionality described above with respect to
In various embodiments, computer system 900 may be a uniprocessor system including one processor 910, or a multiprocessor system including several processors 910 (e.g., two, four, eight, or another suitable number). Processors 910 may be any suitable processor capable of executing instructions. For example, in various embodiments processors 910 may be general-purpose or embedded processors implementing any of a variety of instruction set architectures (ISAs), such as the x86, PowerPC, SPARC, or MIPS ISAs, or any other suitable ISA. In multiprocessor systems, each of processors 910 may commonly, but not necessarily, implement the same ISA.
System memory 920 may be configured to store point cloud compression or point cloud decompression program instructions 922 and/or sensor data accessible by processor 910. In various embodiments, system memory 920 may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), nonvolatile/Flash-type memory, or any other type of memory. In the illustrated embodiment, program instructions 922 may be configured to implement an image sensor control application incorporating any of the functionality described above. In some embodiments, program instructions and/or data may be received, sent or stored upon different types of computer-accessible media or on similar media separate from system memory 920 or computer system 900. While computer system 900 is described as implementing the functionality of functional blocks of previous Figures, any of the functionality described herein may be implemented via such a computer system.
In one embodiment, I/O interface 930 may be configured to coordinate I/O traffic between processor 910, system memory 920, and any peripheral devices in the device, including network interface 940 or other peripheral interfaces, such as input/output devices 950. In some embodiments, I/O interface 930 may perform any necessary protocol, timing or other data transformations to convert data signals from one component (e.g., system memory 920) into a format suitable for use by another component (e.g., processor 910). In some embodiments, I/O interface 930 may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard, for example. In some embodiments, the function of I/O interface 930 may be split into two or more separate components, such as a north bridge and a south bridge, for example. Also, in some embodiments some or all of the functionality of I/O interface 930, such as an interface to system memory 920, may be incorporated directly into processor 910.
Network interface 940 may be configured to allow data to be exchanged between computer system 900 and other devices attached to a network 985 (e.g., carrier or agent devices) or between nodes of computer system 900. Network 985 may in various embodiments include one or more networks including but not limited to Local Area Networks (LANs) (e.g., an Ethernet or corporate network), Wide Area Networks (WANs) (e.g., the Internet), wireless data networks, some other electronic data network, or some combination thereof. In various embodiments, network interface 940 may support communication via wired or wireless general data networks, such as any suitable type of Ethernet network, for example; via telecommunications/telephony networks such as analog voice networks or digital fiber communications networks; via storage area networks such as Fibre Channel SANs, or via any other suitable type of network and/or protocol.
Input/output devices 950 may, in some embodiments, include one or more display terminals, keyboards, keypads, touchpads, scanning devices, voice or optical recognition devices, or any other devices suitable for entering or accessing data by one or more computer systems 900. Multiple input/output devices 950 may be present in computer system 900 or may be distributed on various nodes of computer system 900. In some embodiments, similar input/output devices may be separate from computer system 900 and may interact with one or more nodes of computer system 900 through a wired or wireless connection, such as over network interface 940.
As shown in
Those skilled in the art will appreciate that computer system 900 is merely illustrative and is not intended to limit the scope of embodiments. In particular, the computer system and devices may include any combination of hardware or software that can perform the indicated functions, including computers, network devices, Internet appliances, PDAs, wireless phones, pagers, etc. Computer system 900 may also be connected to other devices that are not illustrated, or instead may operate as a stand-alone system. In addition, the functionality provided by the illustrated components may in some embodiments be combined in fewer components or distributed in additional components. Similarly, in some embodiments, the functionality of some of the illustrated components may not be provided and/or other additional functionality may be available.
Those skilled in the art will also appreciate that, while various items are illustrated as being stored in memory or on storage while being used, these items or portions of them may be transferred between memory and other storage devices for purposes of memory management and data integrity. Alternatively, in other embodiments some or all of the software components may execute in memory on another device and communicate with the illustrated computer system via inter-computer communication. Some or all of the system components or data structures may also be stored (e.g., as instructions or structured data) on a computer-accessible medium or a portable article to be read by an appropriate drive, various examples of which are described above. In some embodiments, instructions stored on a computer-accessible medium separate from computer system 900 may be transmitted to computer system 900 via transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as a network and/or a wireless link. Various embodiments may further include receiving, sending or storing instructions and/or data implemented in accordance with the foregoing description upon a computer-accessible medium. Generally speaking, a computer-accessible medium may include a non-transitory, computer-readable storage medium or memory medium such as magnetic or optical media, e.g., disk or DVD/CD-ROM, volatile or non-volatile media such as RAM (e.g. SDRAM, DDR, RDRAM, SRAM, etc.), ROM, etc. In some embodiments, a computer-accessible medium may include transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as network and/or a wireless link
The methods described herein may be implemented in software, hardware, or a combination thereof, in different embodiments. In addition, the order of the blocks of the methods may be changed, and various elements may be added, reordered, combined, omitted, modified, etc. Various modifications and changes may be made as would be obvious to a person skilled in the art having the benefit of this disclosure. The various embodiments described herein are meant to be illustrative and not limiting. Many variations, modifications, additions, and improvements are possible. Accordingly, plural instances may be provided for components described herein as a single instance. Boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of claims that follow. Finally, structures and functionality presented as discrete components in the example configurations may be implemented as a combined structure or component. These and other variations, modifications, additions, and improvements may fall within the scope of embodiments as defined in the claims that follow.
This application claims benefit of priority to U.S. Provisional Application Ser. No. 62/959,099, entitled “GEOMETRY ENCODING USING OCTREES AND PREDICTIVE TREES”, filed Jan. 9, 2020, and which is incorporated herein by reference in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5793371 | Deering | Aug 1998 | A |
| 5842004 | Deering | Nov 1998 | A |
| 5867167 | Deering | Feb 1999 | A |
| 5870094 | Deering | Feb 1999 | A |
| 5905502 | Deering | May 1999 | A |
| 5933153 | Deering | Aug 1999 | A |
| 6018353 | Deering | Jan 2000 | A |
| 6028610 | Deering | Feb 2000 | A |
| 6088034 | Deering | Jul 2000 | A |
| 6188796 | Kadono | Feb 2001 | B1 |
| 6215500 | Deering | Apr 2001 | B1 |
| 6239805 | Deering | May 2001 | B1 |
| 6256041 | Deering | Jul 2001 | B1 |
| 6307557 | Deering | Oct 2001 | B1 |
| 6429867 | Deering | Aug 2002 | B1 |
| 6459428 | Burk et al. | Oct 2002 | B1 |
| 6459429 | Deering | Oct 2002 | B1 |
| 6522326 | Deering | Feb 2003 | B1 |
| 6522327 | Deering | Feb 2003 | B2 |
| 6525722 | Deering | Feb 2003 | B1 |
| 6525725 | Deering | Feb 2003 | B1 |
| 6531012 | Ishiyama | Mar 2003 | B2 |
| 6559842 | Deering | May 2003 | B1 |
| 6603470 | Deering | Aug 2003 | B1 |
| 6628277 | Deering | Sep 2003 | B1 |
| 6747644 | Deering | Jun 2004 | B1 |
| 6858826 | Mueller et al. | Feb 2005 | B2 |
| 7071935 | Deering | Jul 2006 | B1 |
| 7110617 | Zhang et al. | Sep 2006 | B2 |
| 7215810 | Kaufman et al. | May 2007 | B2 |
| 7373473 | Bukowski et al. | May 2008 | B2 |
| 7679647 | Stavely et al. | Mar 2010 | B2 |
| 7737985 | Torzewski et al. | Jun 2010 | B2 |
| 7961934 | Thrun et al. | Jun 2011 | B2 |
| 8022951 | Zhirkov et al. | Sep 2011 | B2 |
| 8040355 | Burley | Oct 2011 | B2 |
| 3055070 | Bassi et al. | Nov 2011 | A1 |
| 8264549 | Tokiwa et al. | Sep 2012 | B2 |
| 8411932 | Liu et al. | Apr 2013 | B2 |
| 8520740 | Flachs | Aug 2013 | B2 |
| 8566736 | Jacob | Oct 2013 | B1 |
| 8643515 | Cideciyan | Feb 2014 | B2 |
| 8780112 | Kontkanen et al. | Jul 2014 | B2 |
| 8805097 | Ahn et al. | Aug 2014 | B2 |
| 8884953 | Chen et al. | Nov 2014 | B2 |
| 9064311 | Mammou et al. | Jun 2015 | B2 |
| 9064331 | Yamashita | Jun 2015 | B2 |
| 9171383 | Ahn et al. | Oct 2015 | B2 |
| 9191670 | Karczewicz | Nov 2015 | B2 |
| 9199641 | Ferguson et al. | Dec 2015 | B2 |
| 9214042 | Cai et al. | Dec 2015 | B2 |
| 9223765 | Alakuijala | Dec 2015 | B1 |
| 9234618 | Zhu et al. | Jan 2016 | B1 |
| 9256980 | Kirk | Feb 2016 | B2 |
| 9292961 | Korchev | Mar 2016 | B1 |
| 9300321 | Zalik et al. | Mar 2016 | B2 |
| 9317965 | Krishnaswamy et al. | Apr 2016 | B2 |
| 9412040 | Feng | Aug 2016 | B2 |
| 9424672 | Zavodny | Aug 2016 | B2 |
| 9430837 | Fujiki | Aug 2016 | B2 |
| 9530225 | Nieves | Dec 2016 | B1 |
| 9532056 | Jiang et al. | Dec 2016 | B2 |
| 9613388 | Loss | Apr 2017 | B2 |
| 9621775 | Ng et al. | Apr 2017 | B2 |
| 9633146 | Plummer et al. | Apr 2017 | B2 |
| 9678963 | Hernandez Londono et al. | Jun 2017 | B2 |
| 9729169 | Kalevo | Aug 2017 | B2 |
| 9734595 | Lukac et al. | Aug 2017 | B2 |
| 9753124 | Hayes | Sep 2017 | B2 |
| 9787321 | Hemmer et al. | Oct 2017 | B1 |
| 9800766 | Tsuji | Oct 2017 | B2 |
| 9836483 | Hickman | Dec 2017 | B1 |
| 9972129 | Michel et al. | May 2018 | B2 |
| 10089312 | Tremblay et al. | Oct 2018 | B2 |
| 10108867 | Vallespi-Gonzalez | Oct 2018 | B1 |
| 10223810 | Chou et al. | Mar 2019 | B2 |
| 10259164 | Bader | Apr 2019 | B2 |
| 10277248 | Lee | Apr 2019 | B2 |
| 10372728 | Horhammer et al. | Aug 2019 | B2 |
| 10395419 | Godzaridis | Aug 2019 | B1 |
| 10462485 | Mammou et al. | Oct 2019 | B2 |
| 10467756 | Arlinsky et al. | Nov 2019 | B2 |
| 10546415 | Petkov | Jan 2020 | B2 |
| 10559111 | Sachs | Feb 2020 | B2 |
| 10587286 | Flynn | Mar 2020 | B1 |
| 10607373 | Mammou et al. | Mar 2020 | B2 |
| 10659816 | Mammou et al. | May 2020 | B2 |
| 10699444 | Mammou et al. | Jun 2020 | B2 |
| 10715618 | Bhaskar | Jul 2020 | B2 |
| 10762667 | Mekuria | Sep 2020 | B2 |
| 10783668 | Sinharoy et al. | Sep 2020 | B2 |
| 10789733 | Mammou et al. | Sep 2020 | B2 |
| 10805646 | Tourapis et al. | Oct 2020 | B2 |
| 10861196 | Mammou et al. | Dec 2020 | B2 |
| 10867413 | Mammou et al. | Dec 2020 | B2 |
| 10869059 | Mammou et al. | Dec 2020 | B2 |
| 10897269 | Mammou et al. | Jan 2021 | B2 |
| 10909725 | Mammou et al. | Feb 2021 | B2 |
| 10909726 | Mammou et al. | Feb 2021 | B2 |
| 10909727 | Mammou et al. | Feb 2021 | B2 |
| 10911787 | Tourapis et al. | Feb 2021 | B2 |
| 10939123 | Li | Mar 2021 | B2 |
| 10939129 | Mammou | Mar 2021 | B2 |
| 10977773 | Hemmer | Apr 2021 | B2 |
| 10984541 | Lim | Apr 2021 | B2 |
| 11010907 | Bagwell | May 2021 | B1 |
| 11010928 | Mammou et al. | May 2021 | B2 |
| 11012713 | Kim et al. | May 2021 | B2 |
| 11017566 | Tourapis et al. | May 2021 | B1 |
| 11017591 | Oh | May 2021 | B2 |
| 11044478 | Tourapis et al. | Jun 2021 | B2 |
| 11044495 | Dupont | Jun 2021 | B1 |
| 11057564 | Johnson et al. | Jul 2021 | B2 |
| 11095908 | Dawar | Aug 2021 | B2 |
| 11113845 | Tourapis et al. | Sep 2021 | B2 |
| 11122102 | Oh | Sep 2021 | B2 |
| 11122279 | Joshi | Sep 2021 | B2 |
| 11132818 | Mammou et al. | Sep 2021 | B2 |
| 11200701 | Aksu | Dec 2021 | B2 |
| 11202078 | Tourapis et al. | Dec 2021 | B2 |
| 11202098 | Mammou et al. | Dec 2021 | B2 |
| 11212558 | Sugio | Dec 2021 | B2 |
| 11240532 | Roimela | Feb 2022 | B2 |
| 11252441 | Tourapis et al. | Feb 2022 | B2 |
| 11276203 | Tourapis et al. | Mar 2022 | B2 |
| 11284091 | Tourapis et al. | Mar 2022 | B2 |
| 11321928 | Melkote Krishnaprasad | May 2022 | B2 |
| 11363309 | Tourapis et al. | Jun 2022 | B2 |
| 11386524 | Mammou et al. | Jul 2022 | B2 |
| 11398058 | Zakharchenko | Jul 2022 | B2 |
| 11450030 | Mammou | Sep 2022 | B2 |
| 11503367 | Yea | Nov 2022 | B2 |
| 20020181741 | Masukura | Dec 2002 | A1 |
| 20040217956 | Besl et al. | Nov 2004 | A1 |
| 20060133508 | Sekiguchi | Jun 2006 | A1 |
| 20070098283 | Kim et al. | May 2007 | A1 |
| 20070160140 | Fujisawa | Jul 2007 | A1 |
| 20080050047 | Bashyam | Feb 2008 | A1 |
| 20080154928 | Bashyam | Jun 2008 | A1 |
| 20080225116 | Kang | Sep 2008 | A1 |
| 20090016598 | Lojewski | Jan 2009 | A1 |
| 20090027412 | Burley | Jan 2009 | A1 |
| 20090087111 | Noda et al. | Apr 2009 | A1 |
| 20090285301 | Kurata | Nov 2009 | A1 |
| 20100104157 | Doyle | Apr 2010 | A1 |
| 20100104158 | Shechtman et al. | Apr 2010 | A1 |
| 20100106770 | Taylor | Apr 2010 | A1 |
| 20100166064 | Perlman | Jul 2010 | A1 |
| 20100208807 | Sikora | Aug 2010 | A1 |
| 20100260429 | Ichinose | Oct 2010 | A1 |
| 20100260729 | Cavato et al. | Oct 2010 | A1 |
| 20100296579 | Panchal et al. | Nov 2010 | A1 |
| 20110010400 | Hayes | Jan 2011 | A1 |
| 20110107720 | Oakey | May 2011 | A1 |
| 20110142139 | Cheng | Jun 2011 | A1 |
| 20110182477 | Tamrakar | Jul 2011 | A1 |
| 20120124113 | Zalik et al. | May 2012 | A1 |
| 20120188344 | Imai | Jul 2012 | A1 |
| 20120246166 | Krishnaswamy et al. | Sep 2012 | A1 |
| 20120300839 | Sze et al. | Nov 2012 | A1 |
| 20120314026 | Chen et al. | Dec 2012 | A1 |
| 20130034150 | Sadafale | Feb 2013 | A1 |
| 20130094777 | Nomura et al. | Apr 2013 | A1 |
| 20130106627 | Cideciyan | May 2013 | A1 |
| 20130156101 | Lu | Jun 2013 | A1 |
| 20130195352 | Nystad | Aug 2013 | A1 |
| 20130202197 | Reeler | Aug 2013 | A1 |
| 20130321418 | Kirk | Dec 2013 | A1 |
| 20130322738 | Oh | Dec 2013 | A1 |
| 20130329778 | Su et al. | Dec 2013 | A1 |
| 20140036033 | Takahashi | Feb 2014 | A1 |
| 20140098855 | Gu et al. | Apr 2014 | A1 |
| 20140125671 | Vorobyov et al. | May 2014 | A1 |
| 20140176672 | Lu | Jun 2014 | A1 |
| 20140198097 | Evans | Jul 2014 | A1 |
| 20140204088 | Kirk et al. | Jul 2014 | A1 |
| 20140294088 | Sung et al. | Oct 2014 | A1 |
| 20140334557 | Schierl et al. | Nov 2014 | A1 |
| 20150003723 | Huang et al. | Jan 2015 | A1 |
| 20150092834 | Cote et al. | Apr 2015 | A1 |
| 20150139560 | DeWeert et al. | May 2015 | A1 |
| 20150160450 | Ou et al. | Jun 2015 | A1 |
| 20150186744 | Nguyen et al. | Jul 2015 | A1 |
| 20150268058 | Samarasekera et al. | Sep 2015 | A1 |
| 20160035081 | Stout et al. | Feb 2016 | A1 |
| 20160071312 | Laine et al. | Mar 2016 | A1 |
| 20160086353 | Lukac et al. | Mar 2016 | A1 |
| 20160100151 | Schaffer et al. | Apr 2016 | A1 |
| 20160142697 | Budagavi et al. | May 2016 | A1 |
| 20160165241 | Park | Jun 2016 | A1 |
| 20160286215 | Gamei | Sep 2016 | A1 |
| 20160295219 | Ye et al. | Oct 2016 | A1 |
| 20170039765 | Zhou et al. | Feb 2017 | A1 |
| 20170063392 | Kalevo | Mar 2017 | A1 |
| 20170118675 | Booh | Apr 2017 | A1 |
| 20170155402 | Karkkainen | Jun 2017 | A1 |
| 20170155922 | Yoo | Jun 2017 | A1 |
| 20170214943 | Cohen et al. | Jul 2017 | A1 |
| 20170220037 | Berestov | Aug 2017 | A1 |
| 20170243405 | Brandt et al. | Aug 2017 | A1 |
| 20170249401 | Ckart et al. | Aug 2017 | A1 |
| 20170323617 | Yang | Nov 2017 | A1 |
| 20170337724 | Gervais | Nov 2017 | A1 |
| 20170347100 | Chou et al. | Nov 2017 | A1 |
| 20170347120 | Chou et al. | Nov 2017 | A1 |
| 20170347122 | Chou et al. | Nov 2017 | A1 |
| 20170358063 | Chen | Dec 2017 | A1 |
| 20180018786 | Jakubiak | Jan 2018 | A1 |
| 20180053324 | Cohen et al. | Feb 2018 | A1 |
| 20180063543 | Reddy | Mar 2018 | A1 |
| 20180075622 | Tuffreau et al. | Mar 2018 | A1 |
| 20180189982 | Laroche et al. | Jul 2018 | A1 |
| 20180191957 | Miller et al. | Jul 2018 | A1 |
| 20180192061 | He | Jul 2018 | A1 |
| 20180253867 | Laroche | Sep 2018 | A1 |
| 20180260416 | Elkaim | Sep 2018 | A1 |
| 20180268570 | Budagavi | Sep 2018 | A1 |
| 20180308249 | Nash et al. | Oct 2018 | A1 |
| 20180330504 | Karlinsky et al. | Nov 2018 | A1 |
| 20180338017 | Mekuria | Nov 2018 | A1 |
| 20180342083 | Onno et al. | Nov 2018 | A1 |
| 20180365898 | Costa | Dec 2018 | A1 |
| 20190018730 | Charamisinau et al. | Jan 2019 | A1 |
| 20190020880 | Wang | Jan 2019 | A1 |
| 20190026956 | Gausebeck | Jan 2019 | A1 |
| 20190045157 | Venshtain | Feb 2019 | A1 |
| 20190081638 | Mammou et al. | Mar 2019 | A1 |
| 20190087978 | Tourapis et al. | Mar 2019 | A1 |
| 20190087979 | Mammou et al. | Mar 2019 | A1 |
| 20190088004 | Lucas et al. | Mar 2019 | A1 |
| 20190108655 | Lasserre | Apr 2019 | A1 |
| 20190114504 | Vosoughi et al. | Apr 2019 | A1 |
| 20190114809 | Vosoughi et al. | Apr 2019 | A1 |
| 20190114830 | Bouazizi | Apr 2019 | A1 |
| 20190116257 | Rhyne | Apr 2019 | A1 |
| 20190116357 | Tian et al. | Apr 2019 | A1 |
| 20190122393 | Sinharoy | Apr 2019 | A1 |
| 20190089987 | Won et al. | May 2019 | A1 |
| 20190139266 | Budagavi et al. | May 2019 | A1 |
| 20190141248 | Hubert | May 2019 | A1 |
| 20190156519 | Mammou et al. | May 2019 | A1 |
| 20190156520 | Mammou et al. | May 2019 | A1 |
| 20190195616 | Cao et al. | Jun 2019 | A1 |
| 20190197739 | Sinharoy | Jun 2019 | A1 |
| 20190199995 | Yip et al. | Jun 2019 | A1 |
| 20190204076 | Nishi et al. | Jul 2019 | A1 |
| 20190262726 | Spencer et al. | Aug 2019 | A1 |
| 20190289306 | Zhao | Sep 2019 | A1 |
| 20190304139 | Joshi et al. | Oct 2019 | A1 |
| 20190311502 | Mammou et al. | Oct 2019 | A1 |
| 20190313110 | Mammou et al. | Oct 2019 | A1 |
| 20190318488 | Lim | Oct 2019 | A1 |
| 20190318519 | Graziosi et al. | Oct 2019 | A1 |
| 20190340306 | Harrison | Nov 2019 | A1 |
| 20190341930 | Pavlovic | Nov 2019 | A1 |
| 20190371051 | Dore et al. | Dec 2019 | A1 |
| 20190392651 | Graziosi | Dec 2019 | A1 |
| 20200005518 | Graziosi | Jan 2020 | A1 |
| 20200013235 | Tsai et al. | Jan 2020 | A1 |
| 20200020132 | Sinharoy et al. | Jan 2020 | A1 |
| 20200020133 | Najaf-Zadeh et al. | Jan 2020 | A1 |
| 20200021847 | Kim et al. | Jan 2020 | A1 |
| 20200027248 | Verschaeve | Jan 2020 | A1 |
| 20200043220 | Mishaev | Feb 2020 | A1 |
| 20200045344 | Boyce et al. | Feb 2020 | A1 |
| 20200104976 | Mammou et al. | Apr 2020 | A1 |
| 20200105024 | Mammou et al. | Apr 2020 | A1 |
| 20200107022 | Ahn et al. | Apr 2020 | A1 |
| 20200107048 | Yea | Apr 2020 | A1 |
| 20200111237 | Tourapis et al. | Apr 2020 | A1 |
| 20200137399 | Li et al. | Apr 2020 | A1 |
| 20200151913 | Budagavi | May 2020 | A1 |
| 20200153885 | Lee | May 2020 | A1 |
| 20200195946 | Choi | Jun 2020 | A1 |
| 20200204808 | Graziosi | Jun 2020 | A1 |
| 20200217937 | Mammou et al. | Jul 2020 | A1 |
| 20200219285 | Faramarzi et al. | Jul 2020 | A1 |
| 20200219288 | Joshi | Jul 2020 | A1 |
| 20200219290 | Tourapis et al. | Jul 2020 | A1 |
| 20200228836 | Schwarz et al. | Jul 2020 | A1 |
| 20200244993 | Schwarz et al. | Jul 2020 | A1 |
| 20200260063 | Hannuksela | Aug 2020 | A1 |
| 20200273208 | Mammou et al. | Aug 2020 | A1 |
| 20200273258 | Lasserre et al. | Aug 2020 | A1 |
| 20200275129 | Deshpande | Aug 2020 | A1 |
| 20200279435 | Kuma | Sep 2020 | A1 |
| 20200286261 | Faramarzi et al. | Sep 2020 | A1 |
| 20200288171 | Hannuksela et al. | Sep 2020 | A1 |
| 20200294271 | Ilola | Sep 2020 | A1 |
| 20200302571 | Schwartz | Sep 2020 | A1 |
| 20200302578 | Graziosi | Sep 2020 | A1 |
| 20200302621 | Kong | Sep 2020 | A1 |
| 20200302651 | Flynn | Sep 2020 | A1 |
| 20200302655 | Oh | Sep 2020 | A1 |
| 20200359035 | Chevet | Nov 2020 | A1 |
| 20200359053 | Yano | Nov 2020 | A1 |
| 20200366941 | Sugio et al. | Nov 2020 | A1 |
| 20200374559 | Fleureau et al. | Nov 2020 | A1 |
| 20200380765 | Thudor et al. | Dec 2020 | A1 |
| 20200396489 | Flynn | Dec 2020 | A1 |
| 20200413096 | Zhang | Dec 2020 | A1 |
| 20210005006 | Oh | Jan 2021 | A1 |
| 20210006805 | Urban et al. | Jan 2021 | A1 |
| 20210006833 | Tourapis et al. | Jan 2021 | A1 |
| 20210012536 | Mammou et al. | Jan 2021 | A1 |
| 20210012538 | Wang | Jan 2021 | A1 |
| 20210014293 | Yip | Jan 2021 | A1 |
| 20210021869 | Wang | Jan 2021 | A1 |
| 20210027505 | Yano et al. | Jan 2021 | A1 |
| 20210029381 | Zhang et al. | Jan 2021 | A1 |
| 20210056732 | Han | Feb 2021 | A1 |
| 20210084333 | Zhang | Mar 2021 | A1 |
| 20210090301 | Mammou et al. | Mar 2021 | A1 |
| 20210097723 | Kim et al. | Apr 2021 | A1 |
| 20210097725 | Mammou et al. | Apr 2021 | A1 |
| 20210097726 | Mammou et al. | Apr 2021 | A1 |
| 20210099701 | Tourapis et al. | Apr 2021 | A1 |
| 20210103780 | Mammou et al. | Apr 2021 | A1 |
| 20210104014 | Kolb, V | Apr 2021 | A1 |
| 20210104073 | Yea et al. | Apr 2021 | A1 |
| 20210104075 | Mammou et al. | Apr 2021 | A1 |
| 20210104077 | Zakharchenko et al. | Apr 2021 | A1 |
| 20210105022 | Flynn et al. | Apr 2021 | A1 |
| 20210105493 | Mammou et al. | Apr 2021 | A1 |
| 20210105504 | Hur et al. | Apr 2021 | A1 |
| 20210112281 | Wang | Apr 2021 | A1 |
| 20210118190 | Mammou et al. | Apr 2021 | A1 |
| 20210119640 | Mammou et al. | Apr 2021 | A1 |
| 20210142522 | Li | May 2021 | A1 |
| 20210150765 | Mammou | May 2021 | A1 |
| 20210150766 | Mammou et al. | May 2021 | A1 |
| 20210150771 | Huang | May 2021 | A1 |
| 20210158608 | Boggs et al. | May 2021 | A1 |
| 20210166432 | Wang | Jun 2021 | A1 |
| 20210166436 | Zhang | Jun 2021 | A1 |
| 20210168386 | Zhang | Jun 2021 | A1 |
| 20210183112 | Mammou et al. | Jun 2021 | A1 |
| 20210183113 | Han et al. | Jun 2021 | A1 |
| 20210185331 | Mammou et al. | Jun 2021 | A1 |
| 20210195162 | Chupeau et al. | Jun 2021 | A1 |
| 20210201541 | Lasserre | Jul 2021 | A1 |
| 20210203989 | Wang | Jul 2021 | A1 |
| 20210211724 | Kim et al. | Jul 2021 | A1 |
| 20210217139 | Yano | Jul 2021 | A1 |
| 20210217203 | Kim et al. | Jul 2021 | A1 |
| 20210217206 | Flynn | Jul 2021 | A1 |
| 20210218969 | Lasserre | Jul 2021 | A1 |
| 20210218994 | Flynn | Jul 2021 | A1 |
| 20210233281 | Wang et al. | Jul 2021 | A1 |
| 20210248784 | Gao | Aug 2021 | A1 |
| 20210248785 | Zhang | Aug 2021 | A1 |
| 20210256735 | Tourapis et al. | Aug 2021 | A1 |
| 20210258610 | Iguchi | Aug 2021 | A1 |
| 20210264640 | Mammou et al. | Aug 2021 | A1 |
| 20210264641 | Iguchi | Aug 2021 | A1 |
| 20210266597 | Kim et al. | Aug 2021 | A1 |
| 20210281874 | Lasserre | Sep 2021 | A1 |
| 20210295569 | Sugio | Sep 2021 | A1 |
| 20210319593 | Flynn | Oct 2021 | A1 |
| 20210337121 | Johnson et al. | Oct 2021 | A1 |
| 20210383576 | Olivier | Dec 2021 | A1 |
| 20210400280 | Zaghetto | Dec 2021 | A1 |
| 20210407147 | Flynn | Dec 2021 | A1 |
| 20210407148 | Flynn | Dec 2021 | A1 |
| 20220030258 | Zhang | Jan 2022 | A1 |
| 20220084164 | Hur | Mar 2022 | A1 |
| 20220101555 | Zhang | Mar 2022 | A1 |
| 20220116659 | Pesonen | Apr 2022 | A1 |
| 20220164994 | Joshi | May 2022 | A1 |
| Number | Date | Country |
|---|---|---|
| 309618 | Oct 2019 | CA |
| 10230618 | Jan 2012 | CN |
| 104408689 | Mar 2015 | CN |
| 106651942 | May 2017 | CN |
| 108632607 | Oct 2018 | CN |
| 2533213 | Dec 2012 | EP |
| 3429210 | Jan 2019 | EP |
| 3496388 | Jun 2019 | EP |
| 3614674 | Feb 2020 | EP |
| 3751857 | Dec 2020 | EP |
| 200004506 | Jan 2000 | WO |
| 2013022540 | Feb 2013 | WO |
| 2017156462 | Sep 2017 | WO |
| 2018050725 | Mar 2018 | WO |
| 2018094141 | May 2018 | WO |
| 2019011636 | Jan 2019 | WO |
| 2019013430 | Jan 2019 | WO |
| 2019076503 | Apr 2019 | WO |
| 2019078696 | Apr 2019 | WO |
| 2019093834 | May 2019 | WO |
| 2019129923 | Jul 2019 | WO |
| 2019135024 | Jul 2019 | WO |
| 2019143545 | Jul 2019 | WO |
| 2019194522 | Oct 2019 | WO |
| 2019199415 | Oct 2019 | WO |
| 20190197708 | Oct 2019 | WO |
| 2019069711 | Nov 2019 | WO |
| 2020012073 | Jan 2020 | WO |
| 2020066680 | Feb 2020 | WO |
| Entry |
|---|
| Stefan Gumhold et al., “Predictive Point-Cloud Compression”, dated Jul. 31, 2005, pp. 1-7. |
| Pierre-Marie Gandoin et al, “Progressive Lossless Compression of Arbitrary Simplicial Complexes”, Dated Jul. 1, 2002, pp. 1-8. |
| Ruwen Schnabel et al., “Octree-based Point-Cloud Compression”, Eurographics Symposium on Point-Based Graphics, 2006, pp. 1-11. |
| Yuxue Fan et al., “Point Cloud Compression Based on Hierarchical Point Clustering”, Signal and Information Processing Association Annual Summit and Conference (APSIPA), IEEE, 2013, pp. 1-7. |
| Kammert, et al., “Real-time Compression of Point Cloud Streams”, 2012 IEEE International Conference on Robotics and Automation, RiverCentre, Saint Paul, Minnesota, USA, May 14-18, 2012, pp. 778-785. |
| Garcia, et al., “Context-Based Octree Coding for Point Cloud Video”, 2017 IEEE International Conference on Image Processing (ICIP), 2017, pp. 1412-1416. |
| Merry et al., Compression of dense and regular point clouds, Proceedings of the 4th international conference on Computer graphics, virtual reality, visualisation and interaction in Africa (pp. 15-20). ACM. (Jan. 2006). |
| Lustosa et al., Database system support of simulation data, Proceedings of the VLDB Endowment 9.13 (2016): pp. 1329-1340. |
| Hao Liu, et al., “A Comprehensive Study and Comparison of Core Technologies for MPEG 3D Point Cloud Compression”, arXiv:1912.09674v1, Dec. 20, 2019, pp. 1-17. |
| Styliani Psomadaki, “Using a Space Filing Curve For The Management of Dynamic Point Cloud Data in a Relational DBMS”, Nov. 2016, pp. 1-158. |
| Remi Cura et al, “Implicit Lod for Processing and Classification in Point Cloud Servers”, dated Mar. 4, 2016, pp. 1-18. |
| Yan Huang et al, Octree-Based Progressive Geometry Coding of Point Clouds, dated Jan. 1, 2006, pp. 1-10. |
| Khaled Mammou, et al., “G-PCC codec description v1”, International Organisation for Standardisation, ISO/IEC JTC1/SC29/WG11, Oct. 2018, pp. 1-32. |
| “V-PCC Codec Description”, 127. MPEG Meeting; Jul. 8, 2019-Jul. 12, 2019; Gothenburg; (Motion Picture Expert Group or ISO/IEC JTC1/SC29/WG), dated Sep. 25, 2019. |
| G-PPC Codec Description, 127. MPEG Meeting; Jul. 8, 2019-Jul. 12, 2019; Gothenburg; (Motion Picture Expert Group or ISO/IEC JTC1/SC29/WG),dated Sep. 6, 2019. |
| Jianqiang Liu et al, “Data-Adaptive Packing Method for Compresssion of Dynamic Point Cloud Sequences”, dated Jul. 8, 2019, pp. 904-909. |
| Jorn Jachalsky et al, “D4.2.1 Scene Analysis with Spatio-Temporal”, dated Apr. 30, 2013, pp. 1-60. |
| Lasserre S et al, “Global Motion Compensation for Point Cloud Compression in TMC3”, dated Oct. 3, 2018, pp. 1-28. |
| D. Graziosi et al, “An overview of ongoing point cloud compression standardization activities: video-based (V-PCC) and geometry-based (G-PCC)” Asipa Transactions on Signal and Information Processing, vol. 9, dated Apr. 30, 2020, pp. 1-17. |
| “Continuous improvement of study text of ISO-IEC CD 23090-5 Video-Based Point Cloud Compression” dated May 8, 2019, pp. 1-140. |
| Mehlem D. et al, “Smoothing considerations for V-PCC”, dated Oct. 2, 2019, pp. 1-8. |
| Flynn D et al, “G-PCC Bypass coding of bypass bins”, dated Mar. 21, 2019, pp. 1-3. |
| Sharman K et al, “CABAC Packet-Based Stream”, dated Nov. 18, 2011, pp. 1-6. |
| Lasserre S et al, “On bypassed bit coding and chunks”, dated Apr. 6, 2020, pp. 1-3. |
| David Flynn et al, “G-pcc low latency bypass bin coding”. dated Oct. 3, 2019, pp. 1-4. |
| Chuan Wang, et al., “Video Vectorization via Tetrahedral Remeshing”, IEEE Transactions on Image Processing, vol. 26, No. 4, Apr. 2017, pp. 1833-1844. |
| Keming Cao, et al., “Visual Quality of Compressed Mesh and Point Cloud Sequences”, IEEE Access, vol. 8, 2020. pp. 171203-171217. |
| W. Zhu, et al., “Lossless point cloud geometry compression via binary tree partition and intra prediction,” 2017 IEEE 19th International Workshop on Multimedia Signal Prcoessing (MMSP), 2017, pp. 1-6, doi: 1.1109/MMSP.2017.8122226 (Year 2017). |
| Jang et al., Video-Based Point-Cloud-Compression Standard in MPEG: From Evidence Collection to Committee Draft [Standards in a Nutshell], IEEE Signal Processing Magazine, Apr. 2019, pp. 1-6. |
| Pragyana K. Mishra, “Image and Depth Coherent Surface Description”, Doctoral dissertation, Carnegie Mellon University, The Robotics Institute, Mar. 2005, pp. 1-152. |
| Robert Cohen, “CE 3.2 point-based prediction for point loud compression”, dated Apr. 2018, pp. 1-6. |
| Jang et al., Video-Based Point-Cloud-Compression Standard in MPEG: From Evidence Collection to Committee Draft [Standards in a Nutshell], IEEE Signal Processing Magazine, Apr. 2019. |
| Ekekrantz, Johan, et al., “Adaptive Cost Function for Pointcloud Registration,” arXiv preprint arXiv: 1704.07910 (2017), pp. 1-10. |
| Vincente Morell, et al., “Geometric 3D point cloud compression”, Copyright 2014 Elsevier B.V. All rights reserved, pp. 1-18. |
| U.S. Appl. No. 17/523,826, filed Nov. 10, 2021, Mammou, et a. |
| Chou, et al., “Dynamic Polygon Clouds: Representation and Compression for VR/AR”, ARXIV ID: 1610.00402, Published Oct. 3, 2016, pp. 1-28. |
| U.S. Appl. No. 17/804,477, filed May 27, 2022, Khaled Mammou, et al. |
| Jingming Dong, “Optimal Visual Representation Engineering and Learning for Computer Vision”, Doctoral Dissertation, UCLA, 2017, pp. 1-151. |
| Khaled Mammou et al, “Working Draft of Point Cloud Coding for Category 2 (Draft 1)”, dated Apr. 2018, pp. 1-38. |
| Khaled Mammou et al , “Input Contribution”, dated Oct. 8, 2018, pp. 1-42. |
| Benjamin Bross et al, “High Effeciency Video Coding (HEVC) Text Specification Draft 8”, dated Jul. 23, 2012, pp. 1-86. |
| JunTaek Park et al, “Non-Overiapping Patch Packing in TMC2 with HEVC-SCC”, dated Oct. 8, 2018, pp. 1-6. |
| Ismael Daribo, et al., “Efficient Rate-Distortion Compression on Dynamic Point Cloud for Grid-Pattern-Based 3D Scanning Systems”, 3D Research 3.1, Springer, 2012, pp. 1-9. |
| Cohen Robert A et al, “Point Cloud Attribute Compression Using 3-D Intra Prediction and Shape-Adaptive Transforms”, dated Mar. 30, 2016, pp. 141-150. |
| Sebastian Schwarz, et al., “Emerging MPEG Standards for Point Cloud Compression”, IEEE Journal on Emerging and Selected Topics In Circuits and Systems, vol. 9, No. 1, Mar. 2019, pp. 133-148. |
| Li Li, et al., Efficient Projected Frame Padding for Video-based Point Cloud Compression, IEEE Transactions on Multimedia, doi: 10.100/TMM.2020.3016894, 2020, pp. 1-14. |
| Lujia Wang, et al., “Point-cloud Compression Using Data Independent Method—A 3D Discrete Cosine Transform Approach”, in Proceedings of the 2017 IEEE International Conference on Information and Automation (ICIA), Jul. 2017, pp. 1-6. |
| Yiting Shao, et al., “Attribute Compression of 3D Point Clouds Using Laplacian Sparsity Optimized Graph Transform”, 2017 IEEE Visual Communications and Image Processing (VCIP), IEEE, 2017, p. 1-4. |
| Siheng Chen, et al., “Fast Resampling of 3D Point Clouds via Graphs”, arX1v:1702.06397v1, Feb. 11, 2017, pp. 1-15. |
| Nahid Sheikhi Pour, “Improvements for Projection-Based Point Cloud Compression”, MS Thesis, 2018, pp. 1-75. |
| Robert Skupin, et al., “Multiview Point Cloud Filtering for Spatiotemporal Consistency”, VISAPP 2014—International Conference on Computer Vision Theory and Applications, 2014, pp. 531-538. |
| Bin Lu, et al., “Massive Point Cloud Space Management Method Based on Octree-Like Encoding”, Arabian Journal forScience Engineering, https://doi.org/10.1007/s13369-019-03968-7, 2019, pp. 1-15. |
| Wikipedia, “k-d tree”, Aug. 1, 2019, Retrieved from URL: https://en.wikipedia.org/w.indec.php?title=Kd_tree&oldid=908900837, pp. 1-9. |
| “David Flynn et al., “G-PCC: A hierarchical geometry slice structure”, MPEG Meeting, Retrieved from http://phenix.intevry.fr/mpeg/doc_end_user/documents/131_Online/wg11/m54677-v1-m54677_vl.zip, Jun. 28, 2020, pp. 1-9”. |
| ““G-PCC Future Enchancements”, MPEG Metting, Oct. 7-11, 2019, (Motion Picture Expert Group of ISO/IECJTC1/SC29-WG11), Retrieved from http://phenix.int-evry.fr/mpeg/doc_end_user/documents/128_Geneva/wg11/w18887.zipw18887/w18887 on Dec. 23, 2019, pp. 1-30”. |
| Miska M. Hannuksela, “On Slices and Tiles”, JVET Meeting, The Joint Video Exploration Team of ISO/IEC, Sep. 25, 2018, pp. 1-3. |
| David Flynn, “International Organisation for Standardisation Organisation International De Normalisation ISO/IEC JTC1/SC29/WG11 Coding of Moving Pictures and Audio”, dated Apr. 2020. pp. 1-9. |
| R. Mekuria, et al., “Design, Implementation and Evaluation of a Point Cloud Codec for Tele-Immersive Video”, IEEE Transactions on Circuits and Systems for Video Technology 27.4, 2017, pp. 1-14. |
| Jae-Kyun, et al., “Large-Scale 3D Point Cloud Compression Using Adaptive Radial Distance Prediction in Hybrid Coordinate Domains”, IEEE Journal of Selected Topics in Signal Processing, vol. 9, No. 3, Apr. 2015, pp. 1-14. |
| Tim Golla et al., “Real-time Point Cloud Compression”, IROS, 2015, pp. 1-6. |
| Dong Liu, et al., “Three-Dimensional Point-Cloud Plus Patches: Towards Model-Based Image Coding in the Cloud”, 2015 IEEE International Conference on Multimedia Big Data, IEEE Computer Society, pp. 395-400. |
| Tilo Ochotta et al, “Image-Based Surface Compression”, dated Sep. 1, 2008, pp. 1647-1663. |
| U.S. Appl. No. 17/691,754, filed Mar. 10, 2022, Khaled Mammou. |
| U.S. Appl. No. 17/718,647, filed Apr. 12, 2022, Alexandros Tourapis, et al. |
| Number | Date | Country | |
|---|---|---|---|
| 20210217206 A1 | Jul 2021 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62959099 | Jan 2020 | US |
