WO2025217813A1 - Point cloud encoding method, point cloud decoding method, encoder, decoder, bitstream, and storage medium - Google Patents

Abstract

Embodiments of the present application provide a point cloud encoding method, a point cloud decoding method, an encoder, a decoder, a bitstream, and a storage medium. The point cloud decoding method comprises: determining a first parameter of a current block on the basis of at least one intersection point in a reference block, wherein the first parameter is used for indicating the number of inaccurate values among intersection point prediction values determined on the basis of the at least one intersection point; determining a second parameter on the basis of the first parameter, wherein the second parameter comprises a first value, and the first value corresponds to a plurality of values of the first parameter; determining a context model of a third parameter on the basis of the second parameter, wherein the third parameter is used for indicating whether an intersection point centroid offset value of the current block is equal to an inter-frame prediction value of the intersection point centroid offset value; and decoding the third parameter on the basis of the context model of the third parameter.

Description

Point cloud encoding and decoding methods, codecs, bitstreams, and storage media Technical Field

The present application relates to the field of point cloud encoding and decoding technology, and in particular to a point cloud encoding and decoding method, codec, bit stream and storage medium.

Background Art

Using the intersection centroid offset value can more accurately restore the shape of the point cloud. To reduce bitrate overhead when encoding and decoding the intersection centroid offset value, a context model can be used to encode and decode the intersection centroid offset value. However, encoding and decoding the intersection centroid offset value requires a large amount of context, which is not conducive to improving encoding and decoding performance.

Summary of the Invention

The present invention provides a point cloud encoding and decoding method, codec, code stream, and storage medium. The following describes various aspects of the present invention.

In a first aspect, a point cloud decoding method is provided, which is applied to a decoder, including: determining a first parameter of a current block based on at least one intersection in a reference block, the first parameter being used to indicate the number of inaccurate values in an intersection prediction value determined based on the at least one intersection; determining a second parameter based on the first parameter, the second parameter including a first value, and the first value corresponding to multiple values of the first parameter; determining a context model of a third parameter based on the second parameter, the third parameter being used to indicate whether the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value; and decoding the third parameter based on the context model of the third parameter.

In a second aspect, a point cloud encoding method is provided, which is applied to an encoder, including: determining a first parameter of a current block based on at least one intersection point in a reference block, the first parameter being used to indicate the number of inaccurate values in an intersection prediction value determined based on the at least one intersection point; determining a second parameter based on the first parameter, the second parameter including a first value, and the first value corresponding to multiple values of the first parameter; determining a context model of a third parameter based on the second parameter, the third parameter being used to indicate whether the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value; and encoding the third parameter based on the context model of the third parameter.

According to a third aspect, a decoder is provided, comprising: a first determination unit, configured to determine a first parameter of a current block based on at least one intersection in a reference block, the first parameter being used to indicate the number of inaccurate values in an intersection prediction value determined based on the at least one intersection; a second determination unit, configured to determine a second parameter based on the first parameter, the second parameter including a first value, and the first value corresponding to multiple values of the first parameter; a third determination unit, configured to determine a context model of a third parameter based on the second parameter, the third parameter being used to indicate whether the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value; and a decoding unit, configured to decode the third parameter based on the context model of the third parameter.

In a fourth aspect, a decoder is provided, comprising: a memory for storing a computer program; and a processor for executing the method of the first aspect when running the computer program.

In a fifth aspect, an encoder is provided, comprising: a first determination unit, configured to determine a first parameter of a current block based on at least one intersection in a reference block, the first parameter being used to indicate the number of inaccurate values in an intersection prediction value determined based on the at least one intersection; a second determination unit, configured to determine a second parameter based on the first parameter, the second parameter including a first value, and the first value corresponding to multiple values of the first parameter; a third determination unit, configured to determine a context model of a third parameter based on the second parameter, the third parameter being used to indicate whether the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value; and an encoding unit, configured to encode the third parameter based on the context model of the third parameter.

In a sixth aspect, an encoder is provided, comprising: a memory for storing a computer program; and a processor for executing the method of the second aspect when running the computer program.

In a seventh aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed, the method of the first aspect or the second aspect is implemented.

In an eighth aspect, a non-volatile computer-readable storage medium for storing a bit stream is provided, wherein the bit stream is generated by an encoding method using an encoder, or the bit stream is decoded by a decoding method using a decoder, wherein the decoding method is the method of the first aspect and the encoding method is the method of the second aspect.

According to a ninth aspect, a code stream is provided, comprising a code stream generated according to the method of the second aspect.

The embodiment of the present application proposes that the second parameter can be used as a parameter of the context model for determining the third parameter (which can be used to determine the intersection centroid offset value of the current block), wherein one value of the second parameter corresponds to multiple values of the first parameter. In this way, the number of index values (or values) of the second parameter is less than the number of index values of the first parameter. Compared with the method of directly using the first parameter to determine the context model of the third parameter in the related art, the context model of the third parameter determined by the second parameter can reduce the number of required context models, which is beneficial to improving the performance of encoding and decoding the third parameter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1A is a schematic diagram of a three-dimensional point cloud image.

FIG1B is a partially enlarged view of a three-dimensional point cloud image.

FIG2A is a schematic diagram of six viewing angles of a point cloud image.

FIG2B is a schematic diagram of a data storage format corresponding to a point cloud image.

FIG3 is a schematic diagram of a network architecture for point cloud encoding and decoding.

FIG4A is a schematic diagram of a composition framework of a G-PCC encoder.

FIG4B is a schematic diagram of a composition framework of a G-PCC decoder.

FIG5A is a schematic diagram of a low plane position in the Z-axis direction.

FIG5B is a schematic diagram of a high plane position in the Z-axis direction.

FIG6 is a schematic diagram of a node encoding sequence.

FIG. 7A is a schematic diagram of plane identification information.

FIG. 7B is a schematic diagram of another type of planar identification information.

FIG8 is a schematic diagram of sibling nodes of a current node.

FIG9 is a schematic diagram of calculating a centroid offset value.

FIG. 10A is a schematic diagram showing three intersection points included in a sub-block.

FIG. 10B is a schematic diagram of a triangular facet set fitted using three intersection points.

FIG. 10C is a schematic diagram of upsampling of a triangle face set.

FIG11 is a schematic diagram of a flow chart of calculating a centroid offset value.

FIG12 is a schematic diagram of the context required for decoding the Intersameflag.

FIG13 is a flow chart of the point cloud decoding method provided in an embodiment of the present application.

FIG14 is a flow chart of the point cloud encoding method provided in an embodiment of the present application.

FIG15 is a schematic diagram of a flow chart of calculating a centroid offset value provided in an embodiment of the present application.

Figure 16 is a schematic diagram of the context required for decoding the Intersameflag provided in an embodiment of the present application.

FIG17 is a schematic diagram of the structure of a decoder provided in an embodiment of the present application.

FIG18 is a schematic structural diagram of a decoder provided in another embodiment of the present application.

FIG19 is a schematic diagram of the structure of an encoder provided in one embodiment of the present application.

FIG20 is a schematic diagram of the structure of an encoder provided in another embodiment of the present application.

DETAILED DESCRIPTION

In order to enable a more detailed understanding of the features and technical contents of the embodiments of the present application, the implementation of the embodiments of the present application is described in detail below with reference to the accompanying drawings. The attached drawings are for reference only and are not used to limit the embodiments of the present application.

Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

It should also be pointed out that the terms "first\second\third" involved in the embodiments of the present application are only used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

A point cloud is a set of irregularly distributed discrete points in space that represent the spatial structure and surface properties of a three-dimensional object or scene. These points contain geometric information representing spatial location and attribute information representing the point cloud's appearance and texture. Figure 1A shows a 3D point cloud image, and Figure 1B shows a zoomed-in view of a 3D point cloud image. It can be seen that the point cloud surface is composed of densely distributed points.

In a two-dimensional image, each pixel contains information and is distributed regularly, so there's no need to record its location. However, the distribution of points in a point cloud in three-dimensional space is random and irregular, so recording the location of each point in space is necessary to fully represent the point cloud. Similar to a two-dimensional image, each location in the acquisition process has corresponding attribute information, typically an RGB color value, which reflects the object's color. For a point cloud, in addition to color information, each point's corresponding attribute information often includes reflectance values, which reflect the surface texture of the object. Therefore, point cloud data typically includes both point location information and point attribute information. Point location information can also be referred to as point geometric information. For example, point geometric information can be the point's three-dimensional coordinates (x, y, z). Point attribute information can include color information and/or reflectance. For example, reflectance can be one-dimensional reflectance information (r). Color information can be information in any color space, or it can be three-dimensional color information, such as RGB. Here, R represents red (red), G represents green (green), and B represents blue (blue). For example, color information can be luminance and chrominance (YCbCr, YUV) information. Where Y represents brightness (luma), Cb (U) represents blue color difference, Cr(V) represents red color difference.

For example, a point cloud generated using laser measurement principles can include both its 3D coordinate information and its reflectivity. For another example, a point cloud generated using photogrammetry principles can include both its 3D coordinate information and its 3D color information. For another example, a point cloud generated using a combination of laser measurement and photogrammetry principles can include both its 3D coordinate information, its reflectivity value, and its 3D color information.

Figures 2A and 2B show a point cloud image and its corresponding data storage format. Figure 2A provides six viewing angles of the point cloud image, while Figure 2B consists of a file header and data. The header includes the data format, data representation type, the total number of points in the point cloud, and the content represented by the point cloud. For example, the point cloud is in ".ply" format, represented by ASCII code, with a total of 207,242 points. Each point has 3D coordinate information (x, y, z) and 3D color information (r, g, b).

Point clouds can be divided into the following categories according to the acquisition method:

Static point cloud: the object is stationary and the device that acquires the point cloud is also stationary;

Dynamic point cloud: The object is moving, but the device that obtains the point cloud is stationary;

Dynamic point cloud acquisition: The device used to acquire the point cloud is in motion.

For example, point clouds can be divided into two categories according to their usage:

Category 1: Machine perception point cloud, which can be used in scenarios such as autonomous navigation systems, real-time inspection systems, geographic information systems, visual sorting robots, and disaster relief robots;

Category 2: Human eye perception point cloud, which can be used in point cloud application scenarios such as digital cultural heritage, free viewpoint broadcasting, 3D immersive communication, and 3D immersive interaction.

Point clouds can flexibly and conveniently express the spatial structure and surface properties of three-dimensional objects or scenes. Moreover, since point clouds are obtained by directly sampling real objects, they can provide a strong sense of reality while ensuring accuracy. Therefore, they are widely used, including virtual reality games, computer-aided design, geographic information systems, automatic navigation systems, digital cultural heritage, free viewpoint broadcasting, three-dimensional immersive remote presentation, and three-dimensional reconstruction of biological tissues and organs.

Point clouds are primarily collected through computer generation, 3D laser scanning, and 3D photogrammetry. Computers can generate point clouds of virtual 3D objects and scenes; 3D laser scanning can obtain point clouds of static real-world 3D objects or scenes, generating millions of point clouds per second; and 3D photogrammetry can obtain point clouds of dynamic real-world 3D objects or scenes, generating tens of millions of point clouds per second. These technologies reduce the cost and time required to acquire point cloud data while improving data accuracy. While changes in point cloud data acquisition methods have made it possible to acquire large amounts of point cloud data, the processing of this massive amount of 3D point cloud data is facing bottlenecks due to storage space and transmission bandwidth constraints, as application demands grow.

For example, taking a point cloud video with a frame rate of 30 frames per second (fps), each frame contains 700,000 points, and each point has coordinate information (xyz, float) and color information (RGB, uchar). Therefore, the data volume of a 10-second point cloud video is approximately 0.7 million × (4 bytes × 3 + 1 byte × 3) × 30 fps × 10 seconds = 3.15 GB, where 1 byte is 10 bits. For a 1280 × 720 2D video with a YUV sampling format of 4:2:0 and a frame rate of 30 fps, the data volume for 10 seconds is approximately 1280 × 720 × 12 bits × 30 frames × 10 seconds, which is approximately 0.39 GB. A 10-second two-view 3D video has a data volume of approximately 0.39 × 2 = 0.78 GB. This shows that the data volume of a point cloud video far exceeds that of 2D and 3D videos of the same length. Therefore, in order to better realize data management, save server storage space, and reduce the transmission traffic and transmission time between the server and the client, point cloud compression has become a key issue in promoting the development of the point cloud industry.

That is to say, since the point cloud is a collection of massive points, storing the point cloud not only consumes a lot of memory, but is also not conducive to transmission. There is also not enough bandwidth to support direct transmission of the point cloud at the network layer without compression. Therefore, the point cloud needs to be compressed.

Currently, point cloud coding frameworks that can compress point clouds include the geometry-based point cloud compression (G-PCC) codec framework or the video-based point cloud compression (V-PCC) codec framework provided by the Moving Picture Experts Group (MPEG), or the AVS-PCC codec framework provided by AVS. The G-PCC codec framework can be used to compress the first type of static point clouds and the third type of dynamically acquired point clouds, and can be based on the Point Cloud Compression Test Platform (Test Model Compression 13, TMC13). The V-PCC codec framework can be used to compress the second type of dynamic point clouds, and can be based on the Point Cloud Compression Test Platform (Test Model Compression 2, TMC2). Therefore, the G-PCC codec framework is also called the Point Cloud Codec TMC13, and the V-PCC codec framework is also called the Point Cloud Codec TMC2.

An embodiment of the present application provides a network architecture of a point cloud encoding and decoding system including a decoding method and an encoding method. FIG3 is a schematic diagram of a network architecture of a point cloud encoding and decoding system provided by an embodiment of the present application. As shown in FIG3 , the network architecture includes one or more electronic devices 13 to 1N and a communication network 01, wherein the electronic devices 13 to 1N can perform video interaction through the communication network 01. During the implementation process, the electronic device can be various types of devices with point cloud encoding and decoding functions. For example, the electronic device can include a mobile phone, a tablet computer, a personal computer, a personal digital assistant, a navigator, a digital phone, a video phone, a television, a sensor device, a server, etc., which is not limited by the embodiment of the present application. Among them, the decoder or encoder in the embodiment of the present application can be the above-mentioned electronic device.

Among them, the electronic device in the embodiment of the present application has a point cloud encoding and decoding function, generally including a point cloud encoder (ie, encoder) and a point cloud decoder (ie, decoder).

The following describes the related technologies using the G-PCC codec framework and the AVS codec framework as examples.

As you can understand, in the point cloud G-PCC codec framework, the point cloud data to be encoded is first divided into multiple slices (slices, also called strips). In each slice, the geometric information of the point cloud and the attribute information corresponding to each point are encoded separately.

Figure 4A shows a schematic diagram of the G-PCC encoder architecture. As shown in Figure 4A, during the geometry encoding process, the geometric information is transformed so that the entire point cloud is contained within a bounding box. Quantization is then performed. This quantization step primarily serves a scaling purpose. Due to quantization rounding, the geometric information of some point clouds becomes identical. Parameters are then used to determine whether to remove duplicate points. This process of quantization and removing duplicate points is also known as voxelization. The bounding box is then partitioned into an octree or a prediction tree is constructed. During this process, arithmetic coding is performed on the points within the leaf nodes of the partition to generate a binary geometry bitstream. Alternatively, arithmetic coding is performed on the intersections (vertex) of the partition (surface fitting based on the intersections) to generate a binary geometry bitstream. During the attribute encoding process, after the geometry encoding is completed and the geometric information is reconstructed, color conversion is performed to convert the color information (i.e., attribute information) from the RGB color space to the YUV color space. The reconstructed geometry information is then used to recolor the point cloud so that the unencoded attribute information corresponds to the reconstructed geometry information. Attribute encoding is mainly performed on color information. In the process of color information encoding, there are three main transformation methods. The first two methods rely on the level of detail (LOD) division, which are distance-based lifting transformation and prediction transformation respectively. The third method is to directly perform RAHT. All three methods will convert color information from the spatial domain to the frequency domain, and obtain high-frequency coefficients and low-frequency coefficients through transformation. Finally, the coefficients are quantized and then arithmetic coding is performed on the quantized coefficients to generate a binary attribute bit stream.

Figure 4B shows a schematic diagram of the composition framework of a G-PCC decoder. As shown in Figure 4B, for the acquired binary bit stream, the geometric bit stream and attribute bit stream in the binary bit stream are first decoded independently. When decoding the geometric bit stream, the geometric information of the point cloud is obtained through arithmetic decoding-reconstruction of the octree/reconstruction of the prediction tree-reconstruction of the geometry-coordinate inverse conversion; when decoding the attribute bit stream, the attribute information of the point cloud is obtained through arithmetic decoding-inverse quantization-LOD partitioning/RAHT-color inverse conversion, and the point cloud data to be encoded (i.e., the output point cloud) is restored based on the geometric information and attribute information.

It should be noted that, as shown in FIG4A or FIG4B , the current geometric coding and decoding of G-PCC can be divided into octree-based geometric coding and decoding (marked by a dotted box) and prediction tree-based geometric coding and decoding (marked by a dotted box).

For octree geometry encoding (OctGeomEnc), octree geometry encoding includes: first, coordinate conversion of the geometric information so that all point clouds are contained in a bounding box. Then quantization is performed. This step of quantization mainly plays a role of scaling. Due to the quantization rounding, the geometric information of some points is the same. The parameters are used to decide whether to remove duplicate points. The process of quantization and removal of duplicate points is also called voxelization. Next, the bounding box is continuously divided into trees (such as octrees, quadtrees, binary trees, etc.) in the order of breadth-first traversal, and the placeholder code of each node is encoded. In related technologies, a company proposed an implicit geometric division method. First, the bounding box of the point cloud is calculated. Assuming _dx > _dy > _dz , the bounding box corresponds to a cuboid. During geometric partitioning, binary tree partitioning is first performed along the x-axis, resulting in two child nodes. Quadtree partitioning is then performed along the x- and y-axes until the condition _dx = _dy > _dz is satisfied, resulting in four child nodes. When _dx = _dy = _dz is finally satisfied, octree partitioning is performed until the resulting leaf node is a 1×1×1 unit cube. The points in the leaf node are encoded to generate a binary bitstream. Two parameters, K and M, are introduced during the binary/quadtree/octree partitioning process. Parameter K indicates the maximum number of binary/quadtree partitions to be performed before octree partitioning. Parameter M indicates the minimum block side length of ^2M corresponding to the binary/quadtree partitioning. At the same time, K and M must satisfy the following conditions: Assuming d _max = max(d _x , _dy , d _z ) and d _min = min(d _x , _dy , d _z ), parameter K satisfies: K ≥ d _max - d _min ; parameter M satisfies: M ≥ d _min . Parameters K and M satisfy these conditions because, during the current G-PCC implicit geometric partitioning process, the priority is binary tree, quadtree, and octree. When the node block size does not meet the binary tree or quadtree requirements, the node is partitioned using the octree until the minimum leaf node unit is 1×1×1. Octree-based geometric information encoding can effectively encode point cloud geometry by leveraging the correlation between adjacent points in space. However, for relatively flat nodes or those with planar characteristics, plane coding can further improve the performance of point cloud geometry encoding.

Exemplarily, Figure 5A and Figure 5B provide a kind of plane position schematic diagram.Wherein, Figure 5A shows a kind of low plane position schematic diagram in the Z-axis direction, and Figure 5B shows a kind of high plane position schematic diagram in the Z-axis direction.As shown in Figure 5A, here (a), (a0), (a1), (a2), (a3) all belong to the low plane position in the Z-axis direction. Taking (a) as an example, it can be seen that the four child nodes occupied in the current node are all located at the low plane position of the current node in the Z-axis direction, so it can be considered that the current node belongs to a Z plane and is a low plane in the Z-axis direction. Similarly, as shown in Figure 5B, here (b), (b0), (b1), (b2), (b3) all belong to the high plane position in the Z-axis direction. Taking (b) as an example, it can be seen that the four child nodes occupied in the current node are located at the high plane position of the current node in the Z-axis direction, so it can be considered that the current node belongs to a Z plane and is a high plane in the Z-axis direction.

Furthermore, taking (a) in FIG5A as an example, the performance of octree coding and plane coding is compared. FIG6 provides a schematic diagram of the node coding order, that is, the node coding is performed in the order of 0, 1, 2, 3, 4, 5, 6, and 7 as shown in FIG6. Here, if the octree coding method is used for (a) in FIG5A, the placeholder information of the current node is represented as: 10101010. However, if the plane is used, the placeholder information of the current node is represented as: 10101010. Coding method, first of all, it is necessary to encode an identifier to indicate that the current node is a plane in the Z-axis direction, and secondly, if the current node is a plane in the Z-axis direction, it is also necessary to represent the plane position of the current node; secondly, it is only necessary to encode the placeholder information of the low plane node in the Z-axis direction (i.e., the placeholder information of the four child nodes 0, 2, 4, and 6). Therefore, based on the plane coding method, the current node is encoded, and only 6 bits (bits) need to be encoded, which can reduce the representation of 2 bits compared to the octree coding of the related technology. Based on this analysis, plane coding has more obvious coding performance than octree coding. Therefore, for an occupied node, if the plane coding method is used for encoding in a certain dimension, it is first necessary to represent the plane identification (planarMode) and plane position (PlanePos) information of the current node in the dimension, and secondly, the placeholder information of the current node is encoded based on the plane information of the current node. For example, Figure 7A shows a schematic diagram of plane identification information. As shown in Figure 7A , the plane is a low plane in the Z-axis direction; accordingly, the plane identification information has a value of true or 1, i.e., planarMode_ _Z = true; and the plane position information is a low plane (low), i.e., PlanePosition_ _Z = low. Figure 7B shows another schematic diagram of plane identification information. As shown in Figure 7B , the plane is not a plane in the Z-axis direction; accordingly, the plane identification information has a value of false or 0, i.e., planarMode_ _Z = false.

Note that for PlaneMode_ _i , 0 indicates that the current node is not a plane in the i-axis direction, while 1 indicates that the current node is a plane in the i-axis direction. If the current node is a plane in the i-axis direction, then for PlanePosition_ _i , 0 indicates that the current node is a plane in the i-axis direction and the plane position is low, while 1 indicates that the current node is a high plane in the i-axis direction. i represents the coordinate dimension, which can be the X-axis, Y-axis, or Z-axis direction, so i = 0, 1, or 2.

The octree-based geometric information coding mode only has an efficient compression rate for points that are correlated in space. For points that are isolated in the geometric space, the use of the direct coding model (DCM) can greatly reduce the complexity. For all nodes in the octree, the use of DCM is not indicated by flag information, but is inferred from the parent node and neighbor information of the current node. There are three ways to determine whether the current node is eligible for DCM encoding, as follows:

(1) The current node has no sibling child nodes, that is, the parent node of the current node has only one child node, and the parent node of the parent node of the current node has only two occupied child nodes, that is, the current node has at most one neighbor node.

(2) The parent node of the current node has only one child node, the current node, and the six neighbor nodes that share a face with the current node are all empty nodes.

(3) The number of sibling nodes of the current node is greater than 1.

For example, Figure 8 provides a schematic diagram of IDCM encoding. If the current node does not meet the DCM encoding requirements, it will be divided into octrees. If it meets the DCM encoding requirements, the number of points contained in the node will be further determined. If the number of points is less than a threshold (e.g., 2), the node will be DCM-encoded; otherwise, the octree division will continue. When the DCM encoding mode is applied, it is first necessary to encode whether the current node is a true isolated point, i.e., IDCM_flag. When IDCM_flag is true, the current node is encoded using DCM; otherwise, octree encoding is still used. When the current node meets the DCM encoding requirements, the DCM encoding mode of the current node needs to be encoded. Currently, there are two DCM modes: (a) only one point exists (or multiple points, but they are duplicate points); (b) contains two points. Finally, the geometric information of each point needs to be encoded. Assuming that the side length of the node is ^2d , encoding each component of the node's geometric coordinates requires d bits, and this bit information is directly encoded into the bitstream. It should be noted here that when encoding the lidar point cloud, the three-dimensional coordinate information can be predictively encoded by using the lidar acquisition parameters, thereby further improving the encoding performance of the geometric information.

It is important to note that when partitioning nodes into leaf nodes, the number of duplicate points in the leaf nodes must be encoded in the case of lossless geometric coding. Ultimately, the placeholder information for all nodes is encoded to generate a binary bitstream. Furthermore, G-PCC currently introduces a plane coding mode. During the geometric partitioning process, it determines whether the child nodes of the current node are in the same plane. If the child nodes of the current node meet the condition of being in the same plane, the child nodes of the current node are represented by that plane.

For octree-based geometric decoding, the decoder follows a breadth-first traversal. Before decoding each node's occupancy information, it first uses the reconstructed geometric information to determine whether the current node is for plane decoding or IDCM decoding. If the current node meets the requirements for plane decoding, it first decodes the plane identifier and plane position information of the current node. Then, based on the plane information, it decodes the current node's occupancy information. If the current node meets the requirements for IDCM decoding, it first decodes whether the current node is a true IDCM node. If so, it continues to parse the DCM decoding mode of the current node, then obtains the number of points in the current DCM node, and finally decodes the geometric information of each point. For nodes that do not meet either plane decoding or DCM decoding requirements, the current node's occupancy information is decoded. By continuously parsing in this way, the placeholder code of each node is obtained, and the node is continuously partitioned until a 1×1×1 unit cube is obtained. The number of points contained in each leaf node is parsed, and the geometrically reconstructed point cloud information is finally recovered.

For triangle soup (trisoup)-based geometric information coding, geometric partitioning must also be performed first in the trisoup-based geometric information coding framework. However, unlike geometric information coding based on binary trees, quadtrees, and octrees, this method does not require step-by-step partitioning of the point cloud into unit cubes with side lengths of 1×1×1. Instead, the partitioning stops when the sub-blocks (blocks) have a side length of W. Based on the surface formed by the distribution of the point cloud in each block, the surface and the twelve edges of the block are obtained. The vertex coordinates of each block are encoded in sequence to generate a binary code stream.

After encoding/decoding up to twelve vertices, in order to more accurately restore the shape of the point cloud, the centroid offset of the intersection of the cube is encoded/decoded. In the process of encoding the centroid offset of the intersection, the centroid of up to twelve vertices (intersections) is first calculated, denoted as C _mean . At the encoding end, the centroid C is calculated using the actual point cloud set of the cube, as follows: is the normal vector of the centroid, as shown in Figure 9. α is the intersection centroid offset, which needs to be encoded and decoded. The resulting point cloud triangles are CV ₁ V ₂ , CV ₂ V ₃ , CV ₃ V ₄ , and CV ₄ V ₁ . These triangles are used to restore the point cloud.

For trisoup-based point cloud geometry reconstruction, the decoding end first decodes vertex coordinates to complete triangle reconstruction. This process is shown in Figures 10A, 10B, and 10C. The block shown in Figure 10A contains three intersection points (v1, v2, v3). The set of triangles formed by these three intersection points in a certain order is called a triangle soup, or trisoup, as shown in Figure 10B. Afterwards, sampling is performed on this set of triangles, and the resulting sampled points are used as the reconstructed point cloud within the block, as shown in Figure 10C.

The intersection point centroid offset value α can be obtained by decoding at the decoding end. The following describes in detail the process of decoding the intersection point centroid offset value α at the decoding end.

The decoding end can decode up to twelve intersections in the current block to obtain the up to twelve intersections. The up to twelve intersections are then compared with the up to twelve intersections in the reference block (or decoded block) to determine the qualitySKIP of the predicted inaccuracy of up to twelve intersections in the current block. qualitySKIP is used to indicate the number of predicted inaccurate values of up to twelve intersections. If qualitySKIP is less than K, it means that the up to twelve intersections of the current block are predicted more accurately, and the intersection centroid offset value of the current block is most likely equal to the intersection centroid offset value of the reference block. If qualitySKIP is less than K, possibleSKIP can be recorded as 1. The intersection centroid offset value of the reference block is also called the inter-frame prediction value driftSKIP of the intersection centroid offset value. driftSKIP can be obtained by previously decoding the reference block. The reference block can be the previous block of the current block. Of course, the reference block can also be other blocks.

If possibleSKIP is 1, the Intersameflag flag is decoded to determine whether the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value. If the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value, decoding ends; if the intersection centroid offset value of the current block is not equal to the inter-frame prediction value of the intersection centroid offset value, subsequent decoding continues.

For example, if the value of Intersameflag is 1, it means that the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value; if the value of Intersameflag is 0, it means that the intersection centroid offset value of the current block is not equal to the inter-frame prediction value of the intersection centroid offset value.

Similarly, the intersection centroid offset value α may also be encoded in the above manner at the encoding end.

In order to reduce the bit stream overhead of the Intersame Flag, the Intersame Flag may be encoded and decoded using arithmetic coding. When encoding and decoding the Intersame Flag, the context model may be used to encode and decode the Intersame Flag.

The context model of Intersameflag can be determined based on qualitySKIP and driftSKIP. For example: Intersameflag = decode(ctxtMemOctree.ctxDriftSKIP[qualitySKIP][driftSKIP==0]).

The framework for decoding Intersameflag is shown in Figure 11. First, calculate qualitySKIP. Determine whether qualitySKIP is less than K. If qualitySKIP < K, then possibleSKIP = 1; if qualitySKIP ≥ K, then possibleSKIP = 0. If possibleSKIP = 1, decode Intersameflag; if possibleSKIP is not equal to 1, decode the intersection centroid offset value of the current block through other methods. If Intersameflag = 1, the intersection centroid offset value of the current block is equal to driftSKIP. If Intersameflag is not equal to 1, decode the intersection centroid offset value of the current block through other methods.

When decoding the Intersame Flag, the parameters qualitySKIP and driftSKIP are required. qualitySKIP corresponds to 12 index values, 0 to 11; driftSKIP == 0 corresponds to two index values, 0 and 1. Therefore, decoding the Intersame Flag requires a total of 12 * 2 = 24 contexts, as shown in Figure 12. Using this method to decode the Intersame Flag results in a large number of contexts, which can affect codec performance.

Based on this, an embodiment of the present application provides a point cloud encoding method, including: determining a first parameter of a current block based on at least one intersection in a reference block, the first parameter being used to indicate the number of inaccurate values in an intersection prediction value determined based on the at least one intersection; determining a second parameter based on the first parameter, the second parameter including a first value, and the first value corresponding to multiple values of the first parameter; determining a context model of a third parameter based on the second parameter, the third parameter being used to indicate whether the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value; encoding the third parameter based on the context model of the third parameter.

An embodiment of the present application also provides a point cloud decoding method, including: determining a first parameter of a current block based on at least one intersection in a reference block, the first parameter being used to indicate the number of inaccurate values in an intersection prediction value determined based on the at least one intersection; determining a second parameter based on the first parameter, the second parameter including a first value, and the first value corresponding to multiple values of the first parameter; determining a context model of a third parameter based on the second parameter, the third parameter being used to indicate whether the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value; and decoding the third parameter based on the context model of the third parameter.

Considering that the probabilities corresponding to multiple values in the first parameter (such as qualitySKIP) are approximately equal, the applicant proposes that the second parameter can be used as a parameter of the context model for determining the third parameter (such as Intersameflag), wherein one value of the second parameter corresponds to multiple values of the first parameter. In this way, the number of index values (or values) of the second parameter is less than the number of index values of the first parameter. In the related art, the context model of the third parameter is determined directly using the first parameter. The context model of the third parameter is determined by the second parameter, which can reduce the number of required context models and is conducive to improving the performance of encoding and decoding the third parameter.

The following first describes in detail the point cloud decoding method of the embodiment of the present application with examples.

Figure 13 is a flow chart of the point cloud decoding method provided in an embodiment of the present application. The method shown in Figure 13 can be applied to a decoder. The point cloud decoding method shown in Figure 13 can be used to decode the geometric information of a point cloud. In some implementations, the decoding method can be applied to a trisoup-based decoding method. In some implementations, the decoding method is based on a geometry-based solid content test model (GES-TM). GES-TM is a coding and decoding framework proposed for dense point clouds (such as point clouds collected in augmented reality (AR) or virtual reality (VR) scenes).

13 , in step S1310 , a first parameter of a current block is determined according to at least one intersection point in a reference block.

The at least one intersection point may be an intersection point between a point cloud in the reference block and the 12 edges of the reference block. The number of the at least one intersection point is greater than 0 and less than or equal to 12. The at least one intersection point may be obtained by decoding the reference block. The reference block may be a decoded block. The reference block may be a reference block in the trisoup-based encoding and decoding method described above. The reference block may also be referred to as a block.

The first parameter may be used to indicate the number of inaccurate values in the intersection point prediction value determined based on at least one intersection point. The first parameter may be, for example, the qualitySKIP described above (of course, the first parameter may also be represented by any other letters and/or numbers). The value of the first parameter may be 0 to 11, or in other words, the value of the first parameter may be an integer greater than or equal to 0 and less than or equal to 11.

The first parameter can be determined based on a relationship between at least one intersection point in the reference block and at least one intersection point in the current block. For example, if intersection point 1 in the reference block is the same as intersection point 1 in the current block, the predicted value of intersection point 1 in the current block is accurate; if intersection point 1 in the reference block is different from intersection point 1 in the current block, the predicted value of intersection point 1 in the current block is inaccurate. The first parameter can be determined by comparing at least one intersection point in the reference block with at least one intersection point in the current block.

Continuing to refer to FIG. 13 , in step S1320 , the second parameter is determined according to the first parameter.

The second parameter may be a newly defined parameter. For example, the second parameter may be represented by Index_New (of course, the second parameter may also be represented by any other letters and/or numbers).

The second parameter may include a first value, and the first value corresponds to multiple values of the first parameter. In other words, when the value of the first parameter is any one of the multiple values, the value of the second parameter is the first value. In some implementations, the probabilities (or probability distributions) corresponding to the multiple values are equal or approximately equal. Therefore, the contexts indexed by the multiple values can be simplified to one to reduce the number of contexts.

The embodiments of the present application do not specifically limit the multiple values. For example, the multiple values may be values within the first value range among the values of the first parameter. The multiple values may be continuous values. Alternatively, the multiple values may be discontinuous values or scattered values.

The first value range may include some or all values from 1 to 11. For example, the first value range may be 1 to 11. For another example, the first value range may be P to 11, where P is an integer greater than 1, and P may be, for example, 2, 3, 4, or 5. For another example, the first value range may be 1 to Q, where Q is an integer less than 11 and greater than 1, and Q may be, for example, 10, 9, 8, or 7.

The first value can be, for example, 0 or 1, thereby reducing the complexity of encoding and decoding. Taking the first value as 0 as an example, when the value of the first parameter is any one of multiple values, the value of the second parameter is 0. Taking the first value as 1 as an example, when the value of the first parameter is any one of multiple values, the value of the second parameter is 1.

Taking multiple values of 1 to 11 as an example, when the value of the first parameter is 1 to 11, the value of the second parameter is 0 or 1.

In some implementations, the second parameter also includes a second value. This second value may correspond to a value other than the aforementioned multiple values of the first parameter. For example, the second value corresponds to one of the values of the first parameter, and this one value may be any value other than the aforementioned multiple values. This one value may be, for example, 0. For example, if the first value corresponds to a value between 1 and 11 of the first parameter, then the value of the first parameter corresponding to the second value is 0. In other words, the first value and the second value of the second parameter may correspond to all values of the first parameter.

The second value can be 1 or 0. The first value is different from the second value. If the first value is 0, the second value is 1; if the first value is 1, the second value is 0.

The relationship between the value of the first parameter and the value of the second parameter can be implemented by a function or a mapping table, and this embodiment of the present application does not specifically limit this. For example, the second parameter can be determined based on the first parameter and the first mapping relationship. The first mapping relationship can be used to indicate the mapping relationship between the value of the first parameter and the value of the second parameter. By indicating the relationship between the value of the first parameter and the value of the second parameter through a mapping table, the running speed of the codec can be improved.

Continuing to refer to FIG. 13 , in step S1330 , a context model of the third parameter is determined based on the second parameter.

The third parameter may be used to indicate whether the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value. The third parameter may be the Intersameflag described above (of course, the third parameter may also be represented by any other letters and/or numbers).

The inter-frame prediction value of the intersection centroid offset value may be a centroid offset value obtained by prediction. The inter-frame prediction value of the intersection centroid offset value may be an intersection centroid offset value of a reference block.

If the value of the third parameter is 1, it means that the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value; if the value of the third parameter is 0, it means that the intersection centroid offset value of the current block is not equal to the inter-frame prediction value of the intersection centroid offset value. Alternatively, if the value of the third parameter is 0, it means that the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value; if If the value of the three parameters is 1, it means that the intersection centroid offset value of the current block is not equal to the inter-frame prediction value of the intersection centroid offset value.

The third parameter may be determined based on a context model. In other words, the third parameter may be decoded based on the context model. The context model of the third parameter is related to the second parameter.

In some implementations, the context model of the third parameter may be determined based on the second parameter and the fourth parameter. The fourth parameter may be used to indicate an inter-frame prediction value of the intersection centroid offset value. The fourth parameter may be, for example, the driftSKIP described above (of course, the fourth parameter may also be represented by any other letters and/or numbers).

In some implementations, the context model for the third parameter may be determined based on the second parameter and whether the fourth parameter is 0. If the second parameter has two values, and whether the fourth parameter is 0 corresponds to the two values, then the number of contexts for the third parameter is 2*2=4, which is 20 fewer than the 24 contexts in the traditional solution, significantly reducing the number of contexts.

In some implementations, the third parameter is decoded only when the value of the fifth parameter satisfies the first condition, and the value of the fifth parameter is determined based on the value of the first parameter. The fifth parameter may be, for example, the possibleSKIP described above (of course, the fifth parameter may also be represented by any other letters and/or numbers). By decoding the third parameter only when the first condition is satisfied, unnecessary decoding operations can be avoided, thereby improving codec performance.

The first condition may include that the value of the fifth parameter is 1. If the value of the fifth parameter is 1, the decoder decodes the third parameter; if the value of the fifth parameter is not 1, such as the value of the fifth parameter is 0, the decoder does not decode the third parameter.

In some implementations, if the value of the first parameter is less than the first threshold, the value of the fifth parameter is 1. The first threshold may be, for example, K. If the value of the first parameter is less than K, the value of the fifth parameter is 1. K is an integer less than or equal to 12. K may be, for example, 6 or 12.

Continuing to refer to FIG. 13 , in step S1340 , the third parameter is decoded according to the context model of the third parameter.

The decoder may use arithmetic decoding to decode the third parameter according to the context model to determine the value of the third parameter. If the value of the third parameter is 1, the centroid offset value of the current block is determined to be the inter-frame prediction value of the centroid offset value; if the value of the third parameter is 0, the centroid offset value of the current block is determined not to be the inter-frame prediction value of the centroid offset value. If the centroid offset value of the current block is not the inter-frame prediction value of the centroid offset value, the decoder may use other methods to determine the centroid offset value of the current block.

In some implementations, the decoder may determine the reconstructed values of the point cloud within the current block based on the intersection points in the current block.

The above describes in detail the point cloud decoding method provided by the embodiment of the present application in conjunction with Figure 13. The following describes in detail the point cloud encoding method provided by the embodiment of the present application in conjunction with Figure 14.

Figure 14 is a flow chart of the point cloud encoding method provided in an embodiment of the present application. The point cloud encoding method of Figure 14 can be applied to an encoder. The point cloud encoding method shown in Figure 14 can be used to encode the geometric information of a point cloud. In some implementations, the encoding method can be applied to a trisoup-based encoding method. In some implementations, the encoding method is based on a geometry-based solid content test model (GES-TM). GES-TM is a coding and decoding framework proposed for dense point clouds (such as point clouds collected in augmented reality (AR) or virtual reality (VR) scenes).

14 , in step S1410 , a first parameter of a current block is determined according to at least one intersection point in a reference block.

The at least one intersection point may be an intersection point between a point cloud in the reference block and the 12 edges of the reference block. The number of the at least one intersection point is greater than 0 and less than or equal to 12. The at least one intersection point may be obtained by decoding the reference block. The reference block may be a decoded block. The reference block may be a reference block in the trisoup-based encoding and decoding method described above. The reference block may also be referred to as a block.

The first parameter may be used to indicate the number of inaccurate values in the intersection point prediction value determined based on at least one intersection point. The first parameter may be, for example, the qualitySKIP described above (of course, the first parameter may also be represented by any other letters and/or numbers). The value of the first parameter may be 0 to 11, or in other words, the value of the first parameter may be an integer greater than or equal to 0 and less than or equal to 11.

The first parameter can be determined based on a relationship between at least one intersection point in the reference block and at least one intersection point in the current block. For example, if intersection point 1 in the reference block is the same as intersection point 1 in the current block, the predicted value of intersection point 1 in the current block is accurate; if intersection point 1 in the reference block is different from intersection point 1 in the current block, the predicted value of intersection point 1 in the current block is inaccurate. The first parameter can be determined by comparing at least one intersection point in the reference block with at least one intersection point in the current block.

Continuing to refer to FIG. 14 , in step S1420 , the second parameter is determined according to the first parameter.

The second parameter may be a newly defined parameter. For example, the second parameter may be represented by Index_New (of course, the second parameter may also be represented by any other letters and/or numbers).

The second parameter may include a first value, and the first value corresponds to multiple values of the first parameter. In other words, when the value of the first parameter is any one of the multiple values, the value of the second parameter is the first value. In some implementations, the probabilities (or probability distributions) corresponding to the multiple values are equal or approximately equal. Therefore, the contexts indexed by the multiple values can be simplified to one to reduce the number of contexts.

The embodiments of the present application do not specifically limit the multiple values. For example, the multiple values may be values within the first value range among the values of the first parameter. The multiple values may be continuous values. Alternatively, the multiple values may be discontinuous values or scattered values.

The first value range may include some or all of the values from 1 to 11. For example, the first value range may be 1 to 11. For another example, the first value range may be P to 11, where P is an integer greater than 1, and P may be 2, 3, 4, or 5, for example. For another example, the first value range may be It can be 1 to Q, where Q is an integer smaller than 11 and larger than 1. For example, Q can be 10, 9, 8, or 7.

The first value can be, for example, 0 or 1, thereby reducing the complexity of encoding and decoding. Taking the first value as 0 as an example, when the value of the first parameter is any one of multiple values, the value of the second parameter is 0. Taking the first value as 1 as an example, when the value of the first parameter is any one of multiple values, the value of the second parameter is 1.

Taking multiple values of 1 to 11 as an example, when the value of the first parameter is 1 to 11, the value of the second parameter is 0 or 1.

In some implementations, the second parameter also includes a second value. This second value may correspond to a value other than the aforementioned multiple values of the first parameter. For example, the second value corresponds to one of the values of the first parameter, and this one value may be any value other than the aforementioned multiple values. This one value may be, for example, 0. For example, if the first value corresponds to a value between 1 and 11 of the first parameter, then the value of the first parameter corresponding to the second value is 0. In other words, the first value and the second value of the second parameter may correspond to all values of the first parameter.

The second value can be 1 or 0. The first value is different from the second value. If the first value is 0, the second value is 1; if the first value is 1, the second value is 0.

The relationship between the value of the first parameter and the value of the second parameter can be implemented by a function or a mapping table, and this embodiment of the present application does not specifically limit this. For example, the second parameter can be determined based on the first parameter and the first mapping relationship. The first mapping relationship can be used to indicate the mapping relationship between the value of the first parameter and the value of the second parameter. By indicating the relationship between the value of the first parameter and the value of the second parameter through a mapping table, the running speed of the codec can be improved.

Continuing to refer to FIG. 14 , in step S1430 , a context model of the third parameter is determined based on the second parameter.

The third parameter may be used to indicate whether the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value. The third parameter may be the Intersameflag described above (of course, the third parameter may also be represented by any other letters and/or numbers).

The inter-frame prediction value of the intersection centroid offset value may be a centroid offset value obtained by prediction. The inter-frame prediction value of the intersection centroid offset value may be an intersection centroid offset value of a reference block.

If the value of the third parameter is 1, it indicates that the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value; if the value of the third parameter is 0, it indicates that the intersection centroid offset value of the current block is not equal to the inter-frame prediction value of the intersection centroid offset value. Alternatively, if the value of the third parameter is 0, it indicates that the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value; if the value of the third parameter is 1, it indicates that the intersection centroid offset value of the current block is not equal to the inter-frame prediction value of the intersection centroid offset value.

The third parameter may be determined based on a context model. In other words, the third parameter may be encoded based on the context model. The context model of the third parameter is related to the second parameter.

In some implementations, the context model of the third parameter may be determined based on the second parameter and the fourth parameter. The fourth parameter may be used to indicate an inter-frame prediction value of the intersection centroid offset value. The fourth parameter may be, for example, the driftSKIP described above (of course, the fourth parameter may also be represented by any other letters and/or numbers).

In some implementations, the context model for the third parameter may be determined based on the second parameter and whether the fourth parameter is 0. If the second parameter has two values, and whether the fourth parameter is 0 corresponds to the two values, then the number of contexts for the third parameter is 2*2=4, which is 20 fewer than the 24 contexts in the traditional solution, significantly reducing the number of contexts.

In some implementations, the encoding of the third parameter is performed when the value of the fifth parameter satisfies the first condition, and the value of the fifth parameter is determined based on the value of the first parameter. The fifth parameter can be, for example, the possibleSKIP described above (of course, the fifth parameter can also be represented by any other letters and/or numbers). By encoding the third parameter when the first condition is satisfied, some unnecessary encoding operations can be avoided, which is beneficial to improving codec performance.

The first condition may include that the value of the fifth parameter is 1. If the value of the fifth parameter is 1, the encoder encodes the third parameter; if the value of the fifth parameter is not 1, such as the value of the fifth parameter is 0, the encoder does not encode the third parameter.

In some implementations, if the value of the first parameter is less than the first threshold, the value of the fifth parameter is 1. The first threshold may be, for example, K. If the value of the first parameter is less than K, the value of the fifth parameter is 1. K is an integer less than or equal to 12. K may be, for example, 6 or 12.

14 , in step S1440 , the third parameter is encoded according to the context model of the third parameter. The encoder may encode the third parameter according to the context model using arithmetic coding.

The following examples are used to describe the embodiments of the present application in more detail. It should be noted that the examples below are only intended to help those skilled in the art understand the embodiments of the present application, rather than to limit the embodiments of the present application to the specific numerical values or specific scenarios illustrated. It is apparent that those skilled in the art can make various equivalent modifications or changes based on the examples given below, and such modifications or changes also fall within the scope of the embodiments of the present application.

In related art, when decoding the intersection centroid offset value, when decoding the intersameflag flag, the context model indexed by the qualitySKIP value (0 to 11) is redundant. Since the probability distribution of qualitySKIP values other than 0 (1 to 11) is approximate, the context models indexed by qualitySKIP values other than 0 (1 to 11) can be simplified to one. This application proposes an optimization algorithm for reducing the context model, which can be achieved without compromising performance or time complexity.

The improvement proposed in this application is to convert qualitySKIP into a new index value Index_New when decoding the Intersameflag flag. This is because the probability distribution of qualitySKIP is not 0 (1 to 11) is approximate, so the original 12 contexes (0 to 11, a total of 12) can be reduced to 2 contexes (such as 0 is 1, 1 to 11 are another), to reduce the number of contexts on the decoding end without affecting performance and time complexity.

Intersameflag=decode(ctxtMemOctree.ctxDriftSKIP[Index_New][driftSKIP==0])

The index values required for decoding Intersameflag are Index_New and driftSKIP==0.

Method 1:

If 0<=quantitySKIP<K-1, then Index_New=0, otherwise Index_New=1.

The pseudo code is as follows:

If 0<=quantitySKIP<K-1:

Index_New=0

Else

Index_New=1

Take K = 2 as an example. If K is 2, the following solutions are available.

If quantitySKIP==0, then Index_New=0, otherwise Index_New=1.

The pseudo code is as follows:

If quantitySKIP == 0:

Index_New=0

Else (i.e. quantitySKIP is any value from 1 to 11)

Index_New=1

The context used to decode the Intersameflag is:

Index_New--》2 index values;

driftSKIP == 0 --》2 index values.

Intersameflag=decode(ctxtMemOctree.ctxDriftSKIP[Index_New][driftSKIP==0])

The method requires a total of 2*2=4 contexts, which is 20 fewer contexts than the related art (24 contexts).

Method 2:

Method 2 uses a look-up table, that is, the relationship between the value of qualitySKIP and the value of Index_New can be realized through a mapping table.

The mapping table between Index_New and qualitySKIP is:

TABLE_QUANLITY_CONTEX＝[0,1,1,1,1,1,1,1,1,1,1,1] or [1,0,0,0,0,0,0,0,0,0,0,0];

Index_New=TABLE_QUANLITY_CONTEX[qualitySKIP].

The context used to decode the Intersameflag is:

Index_New--》2 index values;

driftSKIP == 0 --》2 index values.

Intersameflag=decode(ctxtMemOctree.ctxDriftSKIP[Index_New][driftSKIP==0])

Method 2 requires a total of 2*2=4 contexts, which is 20 fewer contexts than the related art (24 contexts).

Figure 15 shows a framework diagram for decoding the intersection centroid offset value, and Figure 16 shows a framework diagram for the context required for decoding Intersameflag. The framework diagram shown in Figure 15 is similar to the framework shown in Figure 11. First, calculate qualitySKIP. Determine whether qualitySKIP is less than K. If qualitySKIP＜K, possibleSKIP＝1; if qualitySKIP≥K, possibleSKIP＝0. If possibleSKIP＝1, decode Intersameflag; if possibleSKIP is not equal to 1, decode the intersection centroid offset value of the current block by other methods. If Intersameflag＝1, the intersection centroid offset value of the current block is equal to driftSKIP. If Intersameflag is not equal to 1, decode the intersection centroid offset value of the current block by other methods.

16 , the context model of Intersameflag can be determined based on Index_New and driftSKIP == 0. Since Index_New includes 2 values and driftSKIP == 0 corresponds to 2 values, the number of contexts required to decode Intersameflag is 4, which can greatly reduce the context required to decode Intersameflag.

Tables 1 and 2 show the test results for Method 1 and Method 2, respectively. As can be seen from Tables 1 and 2, the solution of this application has almost no impact on energy and time complexity, but reduces 20 contexts on the decoding end. When decoding the intersection centroid offset value α, the number of contexts shared by the related art solutions is 73. Using the solution of this application, the number of contexts used by Method 1 or Method 2 is 53, equivalent to a 27% reduction in the number of contexts.

This application uses a new indexing method when decoding the intersection centroid offset value, converting the qualitySKIP index into a new index Index_New. The new indexing method can reduce the number of contexts without affecting performance and time complexity.

Table 1

Table 2

The method embodiment of the present application is described in detail above in conjunction with Figures 1 to 16 . The device embodiment of the present application is described in detail below in conjunction with Figures 17 to 20 . It should be understood that the description of the method embodiment corresponds to the description of the device embodiment. Therefore, for parts not described in detail, reference can be made to the above method embodiment.

FIG17 is a schematic diagram of the structure of a decoder provided by an embodiment of the present application. As shown in FIG17 , the decoder 1700 may include a first determining unit 1710 , a second determining unit 1720 , a third determining unit 1730 , and a decoding unit 1740 .

The first determining unit 1710 is configured to determine a first parameter of the current block according to at least one intersection point in the reference block, where the first parameter is used to indicate the number of inaccurate values in the intersection prediction value determined based on the at least one intersection point.

The second determining unit 1720 is configured to determine a second parameter according to the first parameter, where the second parameter includes a first value, and the first value corresponds to multiple values of the first parameter.

The third determination unit 1730 is configured to determine a context model of a third parameter based on the second parameter, where the third parameter is used to indicate whether the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value.

The decoding unit 1740 is configured to decode the third parameter according to the context model of the third parameter.

In some implementations, the multiple values are values of the first parameter that are within a first value range.

In some implementations, the first value range includes some or all of the values from 1 to 11.

In some implementations, the first value is 0 or 1.

In some implementations, the second parameter further includes a second value, and the second value corresponds to one of the values of the first parameter.

In some implementations, the value of the first parameter corresponding to the second value is 0.

In some implementations, the second value is 1 or 0.

In some implementations, the second parameter is determined based on the first parameter and a first mapping relationship, where the first mapping relationship is used to indicate a mapping relationship between a value of the first parameter and a value of the second parameter.

In some implementations, the context model is determined based on the second parameter and a fourth parameter, and the fourth parameter is used to indicate an inter-frame prediction value of the intersection centroid offset value.

In some implementations, the decoding of the third parameter is performed when the value of the fifth parameter satisfies the first condition, and the value of the fifth parameter is determined based on the value of the first parameter.

In some implementations, the first condition is that the value of the fifth parameter is 1.

In some implementations, if the value of the first parameter is less than a first threshold, the value of the fifth parameter is 1.

In some implementations, the decoder further includes a fourth determination unit configured to determine a reconstructed value of the point cloud within the current block based on the intersection point in the current block.

It is understandable that in the embodiments of the present application, a "unit" may be a part of a circuit, a part of a processor, a part of a program or software, etc., and of course it may be a module or a non-modular one. Moreover, the various components in this embodiment may be integrated into a processing unit. Alternatively, each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional modules.

If the integrated unit is implemented in the form of a software functional module and is not sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this embodiment, or the part that contributes to the existing technology, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) or a processor to execute all or part of the steps of the method described in this embodiment. The aforementioned storage medium includes various media that can store program code, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

Therefore, an embodiment of the present application provides a computer-readable storage medium, which is applied to the decoder 1700. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the decoding method described in any one of the aforementioned embodiments.

Based on the composition of the above-mentioned decoder 1700 and the computer-readable storage medium, refer to Figure 18, which shows a specific hardware structure diagram of the encoder 1800 provided in an embodiment of the present application. As shown in Figure 18, the encoder 1800 may include: a communication interface 1810, a memory 1820 and a processor 1830; each component is coupled together through a bus system 1840. It can be understood that the bus system 1840 is used to achieve connection and communication between these components. In addition to the data bus, the bus system 1840 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, various buses are labeled as bus system 1840 in Figure 18. Among them,

Communication interface 1810, used for sending and receiving signals when sending and receiving information with other external network elements;

Memory 1820, for storing computer programs;

Processor 1830 is configured to, when running the computer program, perform the following: determining a first parameter of a current block based on at least one intersection in a reference block, the first parameter being used to indicate the number of inaccurate values in an intersection prediction value determined based on the at least one intersection; determining a second parameter based on the first parameter, the second parameter including a first value, and the first value corresponding to multiple values of the first parameter; determining a context model of a third parameter based on the second parameter, the third parameter being used to indicate whether the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value; and decoding the third parameter based on the context model of the third parameter.

It is understood that the memory 1820 in the embodiment of the present application can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM), and direct RAM bus RAM (DRRAM). The memory 1820 of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

Processor 1830 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by hardware integrated logic circuits or software instructions in processor 1830. The above-mentioned processor 1830 can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The various methods, steps, and logic block diagrams disclosed in the embodiments of this application can be implemented or executed. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in conjunction with the embodiments of this application can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium mature in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory 1820 , and the processor 1830 reads the information in the memory 1820 and completes the steps of the above method in combination with its hardware.

It is understood that the embodiments described in this application can be implemented using hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described in this application, or a combination thereof. For software implementation, the technology described in this application can be implemented by modules (such as processes, functions, etc.) that perform the functions described in this application. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or outside the processor.

Optionally, as another embodiment, the processor 1830 is further configured to execute the aforementioned embodiment when running the computer program. The decoding method according to any one of claims 1 to 6.

FIG19 is a schematic diagram of the structure of an encoder provided by an embodiment of the present application. As shown in FIG19 , the encoder 1900 includes a first determination unit 1910 , a second determination unit 1920 , a third determination unit 1930 , and an encoding unit 1940 .

The first determining unit 1910 is configured to determine a first parameter of the current block according to at least one intersection point in the reference block, where the first parameter is used to indicate the number of inaccurate values in the intersection prediction value determined based on the at least one intersection point.

The second determining unit 1920 is configured to determine a second parameter according to the first parameter, where the second parameter includes a first value, and the first value corresponds to multiple values of the first parameter.

The third determination unit 1930 is configured to determine a context model of a third parameter based on the second parameter, where the third parameter is used to indicate whether the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value.

The encoding unit 1940 is configured to encode the third parameter according to the context model of the third parameter.

In some implementations, the multiple values are values of the first parameter that are within a first value range.

In some implementations, the first value range includes some or all of the values from 1 to 11.

In some implementations, the first value is 0 or 1.

In some implementations, the second parameter further includes a second value, and the second value corresponds to one of the values of the first parameter.

In some implementations, the value of the first parameter corresponding to the second value is 0.

In some implementations, the second value is 1 or 0.

In some implementations, the second parameter is determined based on the first parameter and a first mapping relationship, where the first mapping relationship is used to indicate a mapping relationship between a value of the first parameter and a value of the second parameter.

In some implementations, the context model is determined based on the second parameter and a fourth parameter, and the fourth parameter is used to indicate an inter-frame prediction value of the intersection centroid offset value.

In some implementations, the encoding of the third parameter is performed when the value of the fifth parameter satisfies the first condition, and the value of the fifth parameter is determined based on the value of the first parameter.

In some implementations, the first condition is that the value of the fifth parameter is 1.

In some implementations, if the value of the first parameter is less than a first threshold, the value of the fifth parameter is 1.

It is understandable that in the embodiments of the present application, a "unit" can be a portion of a circuit, a portion of a processor, a portion of a program or software, etc., and of course it can also be a module, or it can be non-modular. Moreover, the various components in this embodiment can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into a single unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional modules.

If the integrated unit is implemented as a software functional module and is not sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this embodiment, or the portion that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) or a processor to execute all or part of the steps of the method described in this embodiment. The aforementioned storage medium includes various media that can store program code, such as a USB flash drive, a mobile hard drive, ROM, RAM, a magnetic disk, or an optical disk.

Therefore, an embodiment of the present application provides a computer-readable storage medium, which is applied to the encoder 1900. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the decoding method described in any one of the aforementioned embodiments.

Based on the composition of the above-mentioned encoder 1900 and the computer-readable storage medium, refer to Figure 20, which shows a specific hardware structure diagram of the encoder 2000 provided in an embodiment of the present application. As shown in Figure 20, the encoder 2000 may include: a communication interface 2010, a memory 2020 and a processor 2030; each component is coupled together through a bus system 2040. It can be understood that the bus system 2040 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 2040 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, various buses are labeled as bus systems 2040 in Figure 20. Among them,

Communication interface 2010, used for sending and receiving signals when sending and receiving information with other external network elements;

Memory 2020, for storing computer programs;

Processor 2030 is used to, when running the computer program, perform the following: determining a first parameter of the current block based on at least one intersection in the reference block, the first parameter being used to indicate the number of inaccurate values in the intersection prediction value determined based on the at least one intersection; determining a second parameter based on the first parameter, the second parameter including a first value, and the first value corresponding to multiple values of the first parameter; determining a context model of a third parameter based on the second parameter, the third parameter being used to indicate whether the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value; and encoding the third parameter based on the context model of the third parameter.

It is understood that the memory 2020 in the embodiment of the present application can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be ROM, PROM, EPROM, EEPROM or flash memory. The volatile memory can be RAM, which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as SRAM, DRAM, SDRAM, DDRSDRAM, ESDRAM, SLDRAM and DRRAM. The memory described in this application The memory 2020 of the systems and methods is intended to comprise, without being limited to, these and any other suitable types of memory.

Processor 2030 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method may be completed by hardware integrated logic circuits or software instructions within processor 2030. Processor 2030 may be a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component. It may implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application may be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules within the decoding processor. The software modules may be located in a storage medium known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 220. Processor 2030 reads information from memory 220 and, in conjunction with its hardware, completes the steps of the above method.

It is understood that the embodiments described herein can be implemented with hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more ASICs, DSPs, DSPDs, PLDs, FPGAs, general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or a combination thereof. For software implementation, the technology described herein can be implemented by modules (e.g., processes, functions, etc.) that perform the functions described herein. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or outside the processor.

Optionally, as another embodiment, the processor 2030 is further configured to execute the encoding method described in any one of the aforementioned embodiments when running the computer program.

An embodiment of the present application also provides a computer-readable storage medium, which is a non-volatile computer-readable storage medium for storing a bit stream. The bit stream can be generated by an encoding method of an encoder, or the bit stream can be decoded by a decoding method of a decoder, wherein the decoding method can be the decoding method described in any of the foregoing embodiments, and the encoding method can be the encoding method described in any of the foregoing embodiments.

It should be noted that, in this application, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.

The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims (32)

A point cloud decoding method, applied to a decoder, comprising: determining a first parameter of the current block according to at least one intersection point in the reference block, the first parameter being used to indicate a number of inaccurate values in an intersection prediction value determined based on the at least one intersection point; determining a second parameter based on the first parameter, wherein the second parameter includes a first value, and the first value corresponds to multiple values of the first parameter; Determine a context model of a third parameter according to the second parameter, wherein the third parameter is used to indicate whether the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value; The third parameter is decoded according to the context model of the third parameter. The method according to claim 1, wherein the multiple values are values of the first parameter that are within a first value range. The method according to claim 2, wherein the first value range includes some or all values from 1 to 11. The method according to claim 1, wherein the first value is 0 or 1. The method according to claim 1, wherein the second parameter further includes a second value, and the second value corresponds to one of the values of the first parameter. The method according to claim 5, wherein the value of the first parameter corresponding to the second value is 0. The method according to claim 5, wherein the second value is 1 or 0. The method according to claim 1, wherein the second parameter is determined based on the first parameter and a first mapping relationship, and the first mapping relationship is used to indicate a mapping relationship between the value of the first parameter and the value of the second parameter. The method according to claim 1, wherein the context model is determined based on the second parameter and a fourth parameter, and the fourth parameter is used to indicate the inter-frame prediction value of the intersection centroid offset value. The method according to claim 1, wherein the decoding of the third parameter is performed when the value of the fifth parameter satisfies the first condition, and the value of the fifth parameter is determined based on the value of the first parameter. The method according to claim 10, wherein the first condition is that the value of the fifth parameter is 1. The method according to claim 10, wherein if the value of the first parameter is less than a first threshold, the value of the fifth parameter is 1. The method according to claim 1, further comprising: A reconstructed value of the point cloud in the current block is determined according to the intersection point in the current block. A point cloud encoding method, applied to an encoder, comprising: determining a first parameter of the current block according to at least one intersection point in the reference block, the first parameter being used to indicate a number of inaccurate values in an intersection prediction value determined based on the at least one intersection point; determining a second parameter based on the first parameter, wherein the second parameter includes a first value, and the first value corresponds to multiple values of the first parameter; Determine a context model of a third parameter according to the second parameter, wherein the third parameter is used to indicate whether the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value; The third parameter is encoded according to the context model of the third parameter. The method according to claim 14, wherein the multiple values are values of the first parameter that are within a first value range. The method according to claim 15, wherein the first value range includes some or all values from 1 to 11. The method according to claim 14, wherein the first value is 0 or 1. The method according to claim 14, wherein the second parameter further includes a second value, and the second value corresponds to one of the values of the first parameter. The method according to claim 18, wherein the value of the first parameter corresponding to the second value is 0. The method according to claim 18, wherein the second value is 1 or 0. The method according to claim 14, wherein the second parameter is determined based on the first parameter and a first mapping relationship, and the first mapping relationship is used to indicate a mapping relationship between the value of the first parameter and the value of the second parameter. The method according to claim 14, wherein the context model is determined based on the second parameter and a fourth parameter, and the fourth parameter is used to indicate the inter-frame prediction value of the intersection centroid offset value. The method according to claim 14, wherein the encoding of the third parameter is performed when the value of the fifth parameter satisfies the first condition, and the value of the fifth parameter is determined based on the value of the first parameter. The method according to claim 23, wherein the first condition is that the value of the fifth parameter is 1. The method according to claim 23, wherein if the value of the first parameter is less than a first threshold, the value of the fifth parameter is 1. A decoder comprising: a first determining unit configured to determine a first parameter of the current block according to at least one intersection point in the reference block, wherein the first parameter is used to indicate a number of inaccurate values in an intersection prediction value determined based on the at least one intersection point; a second determining unit configured to determine a second parameter according to the first parameter, wherein the second parameter includes a first value, and the first value corresponds to multiple values of the first parameter; a third determining unit configured to determine a context model of a third parameter according to the second parameter, wherein the third parameter is used to indicate whether the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value; A decoding unit is configured to decode the third parameter according to a context model of the third parameter. A decoder comprising: memory for storing computer programs; A processor, configured to execute the method according to any one of claims 1 to 13 when running the computer program. An encoder comprising: a first determining unit configured to determine a first parameter of the current block according to at least one intersection point in the reference block, wherein the first parameter is used to indicate a number of inaccurate values in an intersection prediction value determined based on the at least one intersection point; a second determining unit configured to determine a second parameter according to the first parameter, wherein the second parameter includes a first value, and the first value corresponds to multiple values of the first parameter; a third determining unit configured to determine a context model of a third parameter according to the second parameter, wherein the third parameter is used to indicate whether the intersection centroid offset value of the current block is equal to the inter-frame prediction value of the intersection centroid offset value; The encoding unit is configured to encode the third parameter according to the context model of the third parameter. An encoder comprising: memory for storing computer programs; A processor, configured to perform the method according to any one of claims 14 to 25 when running the computer program. A non-volatile computer-readable storage medium storing a bitstream, wherein the bitstream is generated by an encoding method using an encoder, or the bitstream is decoded by a decoding method using a decoder, wherein the decoding method is the method according to any one of claims 1 to 13, and the encoding method is the method according to any one of claims 14 to 25. A code stream, comprising a code stream generated by the method according to any one of claims 14 to 25. A computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed, the method according to any one of claims 1 to 13, or 14 to 25 is implemented.