New contexts for centroid coding

By predicting centroid offset using neighboring node data and context-based entropy coding, the method enhances point cloud compression efficiency and reduces bit-stream size, addressing inefficiencies in current centroid coding methods.

WO2026149901A1PCT designated stage Publication Date: 2026-07-16TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)

Patent Information

Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
Filing Date
2026-01-06
Publication Date
2026-07-16

AI Technical Summary

Technical Problem

Current centroid coding methods for point cloud compression do not effectively utilize neighboring node data to predict the sign and magnitude of the centroid offset, leading to negative impacts on distortion metrics and inefficient bit-stream size.

Method used

Predict the sign and magnitude of the centroid offset using neighboring node data to enhance centroid coding, incorporating context-based entropy coding to optimize bit-stream efficiency.

Benefits of technology

Achieves significant Bjontegaard delta rate (BD-rate) gains by reducing the bit-stream size without altering the reconstruction quality, improving compression efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure EP2026050114_16072026_PF_FP_ABST
    Figure EP2026050114_16072026_PF_FP_ABST
Patent Text Reader

Abstract

A method for performing Geometry-based Point Cloud Compression (G-PCC) is provided. The method includes predicting, for a first sub-cube representing part of a point cloud, a sign and / or offset of a centroid for the sub-cube based on one or more other sub-5 cubes representing other parts of the point cloud. The method includes encoding the predicted sign and / or offset into a bitstream.
Need to check novelty before this filing date? Find Prior Art

Description

NEW CONTEXTS FOR CENTROID CODINGTECHNICAL FIELD

[0001] Disclosed are embodiments related to new contexts for centroid coding.BACKGROUND

[0002] A three-dimensional (3D) point cloud is an unstructured set of coordinates in 3D space, which is typically used to capture scene geometry and scale, i.e., to represent 3D structures from the physical world. In addition to geometry, point clouds can store additional information about the 3D points, so-called attributes. Typical attributes are color information, reflectance, normal vectors, etc. For the simplicity of presentation, the present disclosure is presented in the context of geometry compression without attributes, i.e., compressing a set of 3D points fl = (Xfe, Yk,Zk)k=1, where K is the number of points and Xk, Yk, Zkare coordinates for point k. It is noted, however, that embodiments described herein are applicable to point clouds with attributes. Typical point clouds range in size from a few kilobytes (KBs) to several gigabytes (GBs), which puts at stress any application requiring storage and / or transmission of such point clouds. Therefore, an efficient point cloud compression solution is an essential enabler for all industrial applications relying on such point clouds.

[0003] Geometry based Point Cloud Compression (G-PCC) is the current MPEG standard, and solid G-PCC (SG-PCC) also exists which targets solid dynamic point clouds. It uses octree coding to compress the geometry. Before applying this method, it is assumed that the coordinate values of the point in the point cloud have been quantized into integer coordinates and is contained within a volume D x D x D. The point cloud is then being partitioned into 8 sub-cubes with dimensions D / 2 xD / 2 x D / 2. If a sub-cube does not contain any points, it is unoccupied, and the partitioning process for this branch of the tree is terminated. This generates a tree structure (an octree) where each node can be represented using 8 bits, where each bit indicates the occupancy status of one sub-cube. This process is shown in FIGS. 1A (point cloud) and IB (octree and bits representing each node). For lossy compression, octree partitioning is stopped at a pre-determined level, generating a sparser reconstruction, and the corresponding sequence of 8-bit words is entropy coded. The example in FIGS. 1A and IB shows how the position of two points can be represented in an octree.

[0004] G-PCC also contains a module called triangle soup (trisoup), developed to favor surface point clouds, i.e., point clouds that are dense enough to capture surface structures. Just like regular octree G-PCC, this method uses octree coding to partition the point cloud into nodes (blocks having a width larger than 1). However, when using this module, the octree partitioning typically stops at a higher level in the tree, making the nodes larger. This level is pre-determined and set by the user / encoder. Instead of setting a fixed depth, the user sets a trisoup node size (an integer node size) where each node size corresponds to a depth in the octree where partitioning will stop.

[0005] To represent the surfaces within the trisoup nodes, vertices are determined based on the point content of a node. In the decoder, the vertices are connected to each other forming surfaces in the form of triangles. There are in the current version of the standard 3 types of vertices: edge-vertices, centroid-vertices, and face-vertices. How they are determined and signaled, will be described shortly below.

[0006] First, the edge-vertices are determined. The determination of edge-vertices is straight forward. The edge-vertices are determined to be the position where the surface desired to be represented is intersecting the edges of the node (such vertices are shown in FIG. 2A). Previous MPEG contributions explain how this process is carried out. In the decoder, the edge-vertices are then connected via a centroid node that is the arithmetic mean position of the edge-vertices, forming the triangles that the trisoup name refers to (this is shown in FIG. 2B). As shown in FIGS. 2A and 2B, the edge-vertices are the black vertices positioned on the edge of the node where the surface intersects the edge.

[0007] Only signaling the edge-vertices will limit us to a coarse geometrical representation of the surfaces. Especially for low bitrates, where the node size is large, the representation will be coarse. This is illustrated in FIGS. 3A-3C. In FIG. 3A, a curved surface within a node is represented. The curved surface would be reconstructed as a straight plane instead of an arc-shape. To ameliorate this issue, the codec has the possibility to add an offset to the centroid vertices (shown in FIG. 3B). Before calculating the length of this offset, the direction of the vector along which the offset will be shifted must be calculated. This is illustrated in FIG. 3B. For each triangle surrounding the centroid vertex, a normal will be calculated using a simple cross-product= CEtx CEl+1, ( 1 )where C is the position of the centroid and Ei is one of the edge-vertices and Ei+1is the upcoming vertex in clockwise order around the centroid. Then the offset-vector will be calculated as the average of those normal vectors( 2 )In FIGS. 3A-3C, the centroid-vertex is the hollow vertex positioned within the node.

[0008] Then the offset of the centroid vertex will be calculated as the average projected position along the offset-vector for all original points pt(not vertices) in the node that is within a certain threshold distance from the line segment that goes from the centroid to the edge of the node along in the direction of the offset-vector (shown in FIG. 4). The offset along the offset-vector is calculated aswhere k is the number of points that are within this threshold. The distance from a point pt— >to the line segment, which has direction N and which is originating in centroid C isHence, all points where dt< th is used in equation (3). This is illustrated in FIG. 4, where all points inside the dotted cylinder contribute towards the offset length.

[0009] When the offset is applied to the original centroid it causes the reconstructed node to have the geometrical shape that is illustrated in FIG. 3C. Since the direction of the centroid vertex can be calculated using only the information from the edge-vertices, the only thing that needs to be signaled to the decoder is the offset of the centroid vertex.

[0010] The centroid vertex does not solve all the problems though. Instead of the reconstruction looking like an arc, or like part of a cylinder, it looks like a pyramid (see FIG. 3C). Hence, recently within MPEG, the face-vertex was introduced to the codec. The face vertex is positioned on the face of a node, but only on the intersection of a line segment between 2 centroid vertices in adjacent nodes and the face that is the boundary between 2 nodes. Hence, the task of the encoder is to determine whether there are sufficiently many points in the surroundings of this intersection point between the line andthe face (see the larger circles in FIG. 5 A). If that is the case, for each face between 2 nodes where there is a centroid vertex activated in each node, one bit is signaled, telling the decoder whether to put a face vertex on this intersection point or not. In FIG. 5B, 2 face vertices are determined. The intersection point can be determined using the positions of the edge- and centroid-vertices, and therefore only one bit is required per face. The final reconstruction of the content of the node will look like FIG. 5C, which is significantly closer to the original arc-shape than the reconstruction in FIG. 3C In FIGS. 5A-5C, the face-vertices are the hollow and dotted vertices positioned on the faces of the node.

[0011] To clarify, the above-described process is only performed for nodes with 3 or more edge-vertices. If there only are 2 edge-vertices in a node, the vector which the centroid is offset along, is determined using the neighboring centroid-vertex and the mean position of the 2 shared edge-vertices. This process of how to determine the orientation of the non-closed surface is shown in FIGS. 6A (showing the node being processed) and FIGS. 6B (additionally showing a neighboring node). The neighboring node used to predict is the neighbor that shares the same 2 edge-vertices with the current node. For certain nodes, therefore, one must know the information from the neighboring node (namely the position of the centroid).

[0012] When decoding the point cloud, surfaces of each node are reconstructed by populating all positions for points (called voxels) that intersect the modelled triangles using raytracing. Since the reconstructed point cloud will be quantized, the position coordinates of the resulting occupied voxels will be integers. The purpose of the trisoup module is to encode the point cloud at a low bit rate without losing much accuracy. Compared to octree G-PCC, the reconstructed point cloud will be denser when using trisoup, and this extra density is typically favored by the distortion metrics used in MPEG.

[0013] REFERENCES:[1] N. Svensson, “[G-PCC] [EE13.60] [Test 2] Reconstructing Non-Closed Surfaces in Trisoup Nodes,” ISO / IEC JTC1 / SC29 / WG7 m66498, Kerner, November 2024.[2] N. Svensson, “[G-PCC] [EE13.60 related] [New] Deactivation of Centroid Vertex,” ISO / IEC JTC1 / SC29 / WG7 m70185, Antalya, November 2024.SUMMARY

[0014] Certain challenges presently exist. The current approach does not use neighboring node data to predict the sign and the magnitude of the drift of the centroid offset.Instead, it only uses internal node properties. Previous attempts to deactivate the centroid vertex [2] had shown that when doing so the reconstruction is changed, affecting the distortion metrics used in MPEG negatively, which was considered a problem by the group evaluating this technology. Using neighboring node data as described in this disclosure, one can achieve significant Bjontegaard delta rate (BD-rate) gains over the current approach.

[0015] Embodiments herein provide improvements on the existing methods, e.g., by using neighboring node data to predict the sign and magnitude of the drift of the centroid offset. For example, embodiments may calculate a plane (or planes if a node has more than one occupied neighbor) based on the edge- and centroid-vertices of the neighboring nodes. Using these planes, embodiments may then attempt to predict a position of the centroid vertex in the current node. This prediction may later be used to select context when coding the centroid offset.

[0016] Accordingly, in a first aspect there is provided a method for performing Geometry-based Point Cloud Compression (G-PCC). The method includes predicting, for a first sub-cube representing part of a point cloud, a sign and / or offset of a centroid for the subcube based on one or more other sub-cubes representing other parts of the point cloud. The method includes encoding the predicted sign and / or offset into a bitstream.

[0017] In a second aspect, a computer program is provided. The computer program includes instructions which when executed by processing circuitry of an apparatus causes the apparatus to perform the method of any one of the embodiments of the first aspect.

[0018] In a third aspect, a carrier is provided. The carrier contains the computer program of the second aspect, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium.

[0019] In a fourth aspect, an apparatus for performing Geometry-based Point Cloud Compression (G-PCC) is provided. The apparatus is configured to perform the method of any one of the embodiments of the first aspect.

[0020] Advantages of embodiments disclosed herein include providing BD-rate gains over the current anchor in MPEG. Embodiments achieves this by coding the centroid offset in a more efficient way while not changing the reconstruction.BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

[0022] FIG. 1 A illustrates a point cloud.

[0023] FIG. IB illustrates an octree of a point cloud.

[0024] FIG. 2A illustrates a surface desired to be represented and FIG. 2B illustrates a trisoup reconstruction of the surface of FIG. 2A.

[0025] FIGS. 3A and 3B illustrate a surface desired to be represented and FIG. 3C illustrates a trisoup reconstruction of the surface of FIGS. 3A and 3B.

[0026] FIG. 4 illustrates points in the node that are within a certain threshold distance from the line segment that goes from the centroid to the edge of the node along in the direction of the offset-vector.

[0027] FIGS. 5 A and 5B illustrate a surface desired to be represented and FIG. 5C illustrates a trisoup reconstruction of the surface of FIGS. 5 A and 5B.

[0028] FIGS. 6A and 6B illustrate determining the orientation of the non-closed surface.

[0029] FIG. 7 illustrates how to assess the orientation of the surface based on the decoded vertices in the neighboring nodes according to an embodiment.

[0030] FIG. 8 illustrates the 2 most right triangles in FIG 7 according to an embodiment.

[0031] FIG. 9 illustrates a case where projections of the different edge-vertices have different signs according to an embodiment.

[0032] FIG. 10 is a flowchart illustrating a process according to an embodiment.

[0033] FIG. 11 is a block diagram of an apparatus according to an embodiment.DETAILED DESCRIPTION

[0034] This disclosure focuses on the coding of the centroid-vertex. When entropy coding the centroid offset, one must code the sign as well the magnitude of the drift. When coding these properties, one uses contexts derived from already decoded data that supposedly predicts the property we are trying to code well. By doing so one can spend less bits codingthe data. The existing solution only uses internal node data to predict the sign and the magnitude of the drift.

[0035] Embodiments may use the geometrical properties of the neighboring nodes to predict what sign the centroid offset has and whether the centroid offset is zero. In the case where the sign is predicted, a bit is entropy coded telling the decoder whether to use the predicted sign or not. In the case where it is desired to code a zero offset, the magnitude of the prediction is used to select context for coding of the zero offset. In both cases, new contexts are added to the entropy coding. The method reduces the number of bits required to represent the source point cloud without affecting the reconstruction. Hence BD-rate gains are achieved by applying the method.

[0036] The intuition behind certain embodiments is that one can assess the orientation of the surface based on the decoded vertices in the neighboring nodes. Using FIG. 7 as an example: The edge-vertices and the centroid-vertex of the left node has already been decoded and the edge-vertices of the right node have also been decoded. The position of the centroid vertex of the current node (the right one) can be predicted, in this example, based on the left node.

[0037] To be able to predict from a neighboring node, certain conditions must be fulfilled in some embodiments. Firstly, in these embodiments, there should be between 3 and 5 edge-vertices in the node that is being decoded. Secondly, 2 of the edge-vertices should be positioned on the same negative face (but not same edge), bordering a node that contains 3 or more edge-vertices. Nodes in a positive direction have not yet been decoded and are not used to predict from. Thirdly, the centroid offset of the neighboring node should be 0, because if it is not, there is a chance that it might interfere with the generation of face vertices, which is likely to cause a drop in BD-rate. In some embodiments, all these conditions have to be fulfilled for there to be a projection predictor, while in other embodiments a subset of the conditions may be fulfilled for there to be a projection predictor. Different conditions may also be applied in some embodiments.

[0038] FIG. 8 shows the 2 most right triangles in FIG 7, zoomed in. The 2 edgevertices that are positioned on the face in between the nodes form, together with the centroid in the left node, the triangle ABC. The normal vector n can be calculated using the following cross product: AB x AC. The normalized vector is denoted as n. The point c is representing the arithmetic mean of the points BCD, which would have been the original position of thecentroid. The point c is then projected to the plane that is defined by the points ABC. The projected point is denoted as p. The closest distance between c and p is denoted \pc | and can be calculated according to |n ■ J4C|.

[0039] The projection proj^pc, will have two properties that can be used to code the drift with, namely a sign and a magnitude. These properties have been proven to be good predictors of the sign and whether there is a 0 offset or not. Hence, if for the current node there are a projection prediction from 1, 2 or 3 neighboring nodes, this projection prediction may be used to code the 2 properties. If there are more than one projection prediction from the neighbors, the average prediction may be used.

[0040] When coding the offset, embodiments start by coding one bit indicating whether the offset is 0 or not. This works since the O-offset-case is very common. If there is a projection predictor from the neighboring nodes, the magnitude may be integer divided by the step-size according to: \projfjpc\ / centroidStepSize. This gives an integer that may map towards a context in a context matrix containing probabilities. The intuition is that the size of the projection predictor may provide different probabilities of whether there is a 0 offset or not. To clarify, the bit that indicates whether there is a 0 offset in the current node may be coded conditionally on the magnitude of the projection predictor. In addition to this, the probability of this prediction being good or not is very much dependent on how many edgevertices there are in the current node. Hence, the context matrix may be 2 dimensional, so for each size of the projection predictor and the number of vertices in the current node, there may be a probability used to code this bit. In an embodiment, the context matrix has a size of 6x3.

[0041] If the offset is not zero, then the sign and magnitude of the offset are encoded. The sign and magnitude will only be coded if a zero offset is not coded. For the sign, instead of coding a bit indicating whether the drift is larger than 0 or not, a bit indicating whether to use the same sign as the projection predictor is coded. This is only done if there is a projection predictor at all. In one embodiment, there is just one probability in the context matrix that is used when coding this bit. However, the number of probabilities could be further extended to take different cases into consideration in other embodiments. For instance, if the magnitude of the projection predictor is smaller than a certain threshold value (for example the centroid offset step-size) a separate probability could be used, since the sign predictor may be less credible the closer to 0 the projection predictor is. One could also project all edge-vertices in the current node, that are not used to span the plane that theprojection calculation is based on, to the plane spanned by the vertices ABC. If the projections of the different edge-vertices have different signs, the centroid projection becomes less credible as a predictor since there most likely is not a plane that continues over multiple nodes. Hence, this case can be handled by a separate probability. This case is illustrated in FIG. 9. There, the rectangular plane is spanned by the vertices ABC. The 2 remaining edge-vertices (the 2 most right ones in FIG. 9) are then projected to the plane. The signs of the projections are different and hence, a third probability is used when coding the centroid sign in this case.

[0042] In some embodiments, the same context as for the zero offset coding may be used when coding the magnitude. For example, when the magnitude is coded, the calculation \projnpc\ / centroidStepSize may be used to calculate an integer that maps towards a context in a context matrix containing probabilities.

[0043] FIG. 10 illustrates a process 1000 for performing Geometry-based Point Cloud Compression (G-PCC). The process may be performed by a node (e.g., node 1100), and may start at step si 002.

[0044] Step si 002 comprises predicting, for a first sub-cube representing part of a point cloud, a sign and / or offset of a centroid for the sub-cube based on one or more other sub-cubes representing other parts of the point cloud.

[0045] Step sl004 comprises encoding the predicted sign and / or offset into a bitstream.

[0046] In some embodiments, the one or more other sub-cubes are adjacent to the first sub-cube. In some embodiments, encoding the predicted sign and / or offset into a bitstream comprises using entropy coding. In some embodiments, (i) the sub-cube has between 3 and 5 edge vertices, (ii) two of the edge-vertices are positioned on a common negative face but on different edges bordering a neighboring node that contains 3 or more edge-vertices, the neighboring node being one of the one or more other sub-cubes, and (iii) an offset of a centroid of the neighboring node is 0. In some embodiments, the one or more other subcubes comprises a plurality of other sub-cubes, and predicting the sign and / or offset if based on an average of different predictions based on each of the plurality of other sub-cubes. In some embodiments, encoding the predicted sign and / or offset into a bitstream comprises encoding a first bit indicating whether the offset is zero and encoding a second bit indicatingthe sign if the offset is not zero. In some embodiments, encoding the predicted sign and / or offset into a bitstream comprises encoding a magnitude of the offset.

[0047] Results

[0048] An embodiment of the method disclosed herein has been implemented on top of GeS-TMv8 [2] and the objective results are presented in Table 1 and 2. GeS-TMv8 is used as the anchor. The gains only come from reduction of the size of the bit-stream. The PSNR numbers are the same for the test and the anchor.

[0049] Table 1. The results of the proposed method on GeS-TM (intra).lossy geometry, lossy attributesEnd-to-End BD-AttrRate [%] Geom. BD-TotGeomRate [%]TChroma Chroma1,Luma DI Dz Cb CrCat2-A average 0,0% 0,0% 0,0% -0,3% -0,3% Cat2-B average 0,0% 0,0% 0,0% -0,5% -0,4% Cat2-C average 0,0% 0,0% 0,0% -0,5% -0,4% Overallaverage 0,0% 0,0% 0,0% -0,4% -0,3% Avg. Enc Time[%] 104%Avg. Dec Time[%] 105%

[0050] Table 2. The results of the proposed method on GeS-TM (inter).lossy geometry, lossy attributesEnd-to-End BD-AttrRate [%] Geom. BD-TotGeomRate [%] i -i. ChromaLuma Chroma Cb „ DI Dz CrCat2-A average 0,0% 0,0% 0,0% 0,0% 0,0% Cat2-B average 0,0% 0,0% 0,0% -0,3% -0,3% Cat2-C average 0,0% 0,0% 0,0% -0,3% -0,2% Overallaverage 0,0% 0,0% 0,0% -0,1% -0,1% Avg. Enc Time[%] 102%Avg. Dec Time

[0051] Summary of Various EmbodimentsAl. A method for performing Geometry -based Point Cloud Compression (G-PCC), the method comprising:predicting, for a first sub-cube representing part of a point cloud, a sign and / or offset of a centroid for the sub-cube based on one or more other sub-cubes representing other parts of the point cloud; andencoding the predicted sign and / or offset into a bitstream.A2. The method of embodiment Al, wherein the one or more other sub-cubes are adjacent to the first sub-cube.A3. The method of any one of embodiments A1-A2, wherein encoding the predicted sign and / or offset into a bitstream comprises using entropy coding.A4. The method of any one of embodiments Al -A3, wherein (i) the sub-cube has between 3 and 5 edge vertices, (ii) two of the edge-vertices are positioned on a common negative face but on different edges bordering a neighboring node that contains 3 or more edge-vertices, the neighboring node being one of the one or more other sub-cubes, and (iii) an offset of a centroid of the neighboring node is 0.A5. The method of any one of embodiments A1-A4, wherein the one or more other sub-cubes comprises a plurality of other sub-cubes, and predicting the sign and / or offset if based on an average of different predictions based on each of the plurality of other sub-cubes.A6. The method of any one of embodiments A1-A5, wherein encoding the predicted sign and / or offset into a bitstream comprises encoding a first bit indicating whether the offset is zero and encoding a second bit indicating the sign if the offset is not zero.A7. The method of any one of embodiments A1-A6, wherein encoding the predicted sign and / or offset into a bitstream comprises encoding a magnitude of the offset.Bl. A computer program (1143) comprising instructions (1144) which when executed by processing circuitry (1102) of an apparatus causes the apparatus to perform the method of any one of embodiments A1-A7.B2. A carrier containing the computer program of embodiment Bl, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium (1142).Cl. An apparatus 1100 (see FIG. 11) for performing Geometry-based Point Cloud Compression (G-PCC), wherein the apparatus is configured to perform the method of any one of embodiments A1-A7.

[0052] FIG. 11 is a block diagram of an apparatus 1 ! 00 for implementing any of the embodiments disclosed herein (e.g., such as one or more of the steps shown in FIG. 10). As shown in FIG. 11, apparatus 1100 may comprise: processing circuitry (PC) 1102, which may include one or more processors (P) 1155 (e.g., one or more general purpose microprocessors and / or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed (i.e., encoder apparatus 1100 may be a distributed computing apparatus); at least one network interface 1148 (e.g., a physical interface or air interface) comprising a transmitter (Tx) 1145 and a receiver (Rx) 1147 for enabling apparatus 1100 to transmit data to and receive data from other nodes connected to a network 1110 (e.g., an Internet Protocol (IP) network) to which network interface 1148 is connected (physically or wirelessly) (e.g., network interface 1148 may be coupled to an antenna arrangement comprising one or more antennas for enabling encoder apparatus 1100 to wirelessly transmit / receive data); and a storage unit (a.k.a., “data storage system”) 1108, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. In embodiments where PC 1102 includes a programmable processor, a computer readable storage medium (CRSM) 1142 may be provided. CRSM 1142 may store a computer program (CP) 1143 comprising computer readable instructions (CRI) 1144. CRSM 1142 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI 1144 ofcomputer program 1143 is configured such that when executed by PC 1102, the CRI causes encoder apparatus 1100 to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, encoder apparatus 1100 may be configured to perform steps described herein without the need for code. That is, for example, PC 1102 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and / or software.

[0053] While various embodiments are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0054] As used herein transmitting a message “to” or “toward” an intended recipient encompasses transmitting the message directly to the intended recipient or transmitting the message indirectly to the intended recipient (i. e. , one or more other nodes are used to relay the message from the source node to the intended recipient). Likewise, as used herein receiving a message “from” a sender encompasses receiving the message directly from the sender or indirectly from the sender (i.e., one or more nodes are used to relay the message from the sender to the receiving node). Further, as used herein “a” means “at least one” or “one or more.”

[0055] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.

[0056] Certain embodiments are also described in the attached appendix.

Claims

CLAIMS1. A method for performing Geometry -based Point Cloud Compression (G-PCC), the method comprising:predicting (si 002), for a first sub-cube representing part of a point cloud, a sign and / or offset of a centroid for the sub-cube based on one or more other sub-cubes representing other parts of the point cloud; andencoding (si 004) the predicted sign and / or offset into a bitstream.

2. The method of claim 1, wherein the one or more other sub-cubes are adjacent to the first sub-cube.

3. The method of any one of claims 1-2, wherein encoding the predicted sign and / or offset into a bitstream comprises using entropy coding.

4. The method of any one of claims 1-3, wherein (i) the sub-cube has between 3 and 5 edge vertices, (ii) two of the edge-vertices are positioned on a common negative face but on different edges bordering a neighboring node that contains 3 or more edge-vertices, the neighboring node being one of the one or more other sub-cubes, and (iii) an offset of a centroid of the neighboring node is 0.

5. The method of any one of claims 1-4, wherein the one or more other sub-cubes comprises a plurality of other sub-cubes, and predicting the sign and / or offset if based on an average of different predictions based on each of the plurality of other sub-cubes.

6. The method of any one of claims 1-5, wherein encoding the predicted sign and / or offset into a bitstream comprises encoding a first bit indicating whether the offset is zero and encoding a second bit indicating the sign if the offset is not zero.

7. The method of any one of claims 1-6, wherein encoding the predicted sign and / or offset into a bitstream comprises encoding a magnitude of the offset.

8. A computer program (1143) comprising instructions (1144) which when executed by processing circuitry (1102) of an apparatus causes the apparatus to perform the method of any one of claims 1-7.

9. A carrier containing the computer program of claim 8, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium (1142).

10. An apparatus (1100) for performing Geometry-based Point Cloud Compression (G-PCC), wherein the apparatus is configured to:predict, for a first sub-cube representing part of a point cloud, a sign and / or offset of a centroid for the sub-cube based on one or more other sub-cubes representing other parts of the point cloud; andencode the predicted sign and / or offset into a bitstream.

11. The apparatus of claim 10, wherein the one or more other sub-cubes are adjacent to the first sub-cube.

12. The apparatus of any one of claims 10-11, wherein encoding the predicted sign and / or offset into a bitstream comprises using entropy coding.

13. The apparatus of any one of claims 10-12, wherein (i) the sub-cube has between 3 and 5 edge vertices, (ii) two of the edge-vertices are positioned on a common negative face but on different edges bordering a neighboring node that contains 3 or more edge-vertices, the neighboring node being one of the one or more other sub-cubes, and (iii) an offset of a centroid of the neighboring node is 0.

14. The apparatus of any one of claims 10-13, wherein the one or more other subcubes comprises a plurality of other sub-cubes, and predicting the sign and / or offset if based on an average of different predictions based on each of the plurality of other sub-cubes.

15. The apparatus of any one of claims 10-14, wherein encoding the predicted sign and / or offset into a bitstream comprises encoding a first bit indicating whether the offset is zero and encoding a second bit indicating the sign if the offset is not zero.1616. The apparatus of any one of claims 10-15, wherein encoding the predicted sign and / or offset into a bitstream comprises encoding a magnitude of the offset.