Implementation of efficient edgebreaker spiral reversi

Abstract

Systems and methods for reverse edgebreaker coding of triangle mesh information. Handles in meshes. In a mesh decoding method according to an exemplary embodiment, a bitstream representing the connectivity of a triangle mesh encoded using edgebreaker coding is obtained. Information indicating the direction of the connectivity encoding is read from the bitstream information. A parameter representing the number of triangles in the triangle mesh is read from the bitstream. Using the parameter representing the number of triangles in the triangle mesh, the connectivity of the triangle mesh is reconstructed from the bitstream.

Description

Technology Field

[0001] Cross-reference

[0002] This application claims priority to European patent application No. 24305005.1, filed on January 2, 2024, titled "Efficient Edgebreaker Spiral Reversi Implementation," the entirety of which is incorporated herein by reference. Background Technology

[0003] Under the MPEG V-Mesh (now renamed V-DMC) CfP, a solution proposed by Apple was selected to serve as the basis for the MPEG V-Mesh Test Model(TM). This proposal is described in "m59281 - [V-CG] Apple's Dynamic Mesh Coding CfP Response" by K. Mammou, J. Kim, A. Tourapis, and D. Podborski, Apple Inc, 2022. An overview of mesh encoding and decoding is illustrated in Figures 1 and 2, respectively. Figure 1 illustrates the MPEG™ intra-frame encoding process. Figure 2 illustrates the MPEG™ intra-frame decoding process. The test model uses a static mesh coder for encoding the base mesh for some frames, and the base mesh is subsequently subdivided to obtain an approximation of the original mesh.

[0004] Up to v3.0, the V-Mesh test model encoded the base mesh using the Google Draco implementation of the latest mesh encoder named edgebreaker, and more specifically, its spiral reversi variant adapted to operate on corner tables (CT). Edgebreaker is described, for example, in J. Rossignac's "Edgebreaker: Connectivity compression for triangle meshes," GVU center, Georgia Institute of Technology, 1999 (“Rossignac (1999)”); and in J. Rossignac's "3D compression made simple: Edgebreaker with ZipandWrap on a corner-table," in Proceedings International Conference on Shape Modeling and Applications, Genova, Italy, 2001 (“Rossignac (2001)”). The spiral reversi transformation is described in "Spirale Reversi: Reverse decoding of the Edgebreaker encoding" by M. Isenburg and J. Snoeyink in Computational Geometry, vol. 20, pp. 39-52, 2001 ("Isenburg & Snoeyink (2001)").

[0005] Note that Rossignac (1999) originally decoded in a forward manner and operated on the mesh's half-edge representation. Later, Rossignac (1999) proposed a modified version that still decoded in a forward manner but ran on the mesh's corner table representation, which led to a very compact algorithm. Spiral Reversi, described by Isenburg & Snoeyink (2001), proposes an extension of Rossignac (1999) that still runs on the half-edge representation but performs decoding in a reverse manner, which is O(n²) compared to Rossignac (1999). 2 This leads to decoding in O(n) in one pass, which is better performance than the worst-case time complexity of ) and Rossignac (2001) (O(n) but multiple passes).

[0006] For the standardization of V-DMC, it is desirable to provide an MPEG alternative implementation of Edgebreaker that can be used in test model reference software and can be extended / specified as needed. InterDigital was responsible for producing the first version of the software. The version adopted for TM v3.0 is described in detail in the following MPEG contributions: "m62603 - [V-DMC][EE4.4] Edgebreaker base mesh codec integration" by J.-E. Marvie and O. Mocquard, MPEG meeting 142, Antalya, 2023; and "m63344 - [V-DMC][EE4.4]-an-efficient-Edgebreaker-implementation" by J.-E. Marvie and O. Mocquard, MPEG meeting 142, Antalya. This software is further described in European Patent Application No. 23305505.2 filed on April 6, 2023. In that application, specific adaptations of a forward edge breaker are presented, operating on a corner table designed to support V-Mesh™ requirements as well as associated bitstream syntax. Further extensions are described in the following European patent applications:

[0007] European patent application No. 23305941.9 filed on June 14, 2023 (describing the coding of per-face attributes).

[0008] European patent application No. 23306154.8 filed on July 7, 2023 (describing an alternative vertex tour).

[0009] European Patent Application No. 23306155.5 filed on July 7, 2023 (describes prediction-degree-based motion estimation).

[0010] European patent application No. 23306292.6 filed on July 26, 2023 (describing surface-specific property optimization).

[0011] For some meshes, particularly large meshes with regular topology (vertex valence is an average of 6 neighbors), certain extensions (known as valence-driven encoding), such as those described in A. Szymczak’s “Optimized Edgebreaker encoding for large and regular triangle meshes,” The Visual Computer, vol. 19, pp. 271-278, 2003, can be used to better encode CLERS tables. However, this solution is configured for the reverse version of edgebreakers. The first version of the reverse version is presented by Isenburg & Snoeyink (2001), which works for half-edge data structures. Later, a version that operates on corner table data structures and supports surfaces having holes and handles was presented by T. Lewiner, H. Lopes, J. Rossignac and AW Vieira in "Efficient Edgebreaker for Surfaces of Arbitrary Topology," in Proceedings, 17th Brazilian Symposium on Computer Graphics and Image Processing, 2004 ("Lewiner et al. (2004)").

[0012] A mesh encoding method according to an exemplary embodiment comprises: encoding the connectivity of a triangle mesh in a bitstream using edgebreaker coding; signaling information in the bitstream indicating the direction of the connectivity encoding; and signaling a parameter in the bitstream indicating the number of triangles in the triangle mesh in response to a determination that the information indicates reverse edgebreaker coding.

[0013] In some embodiments, the method further includes the step of signaling a parameter indicating the number of encoded CLERS symbols separately from a parameter indicating the number of triangles in a triangle mesh.

[0014] In some embodiments, the method further includes the step of signaling a parameter in a bitstream representing the number of starting positions in a mesh in response to a determination that the information represents reverse edgebreaker coding.

[0015] Some embodiments further include the step of signaling a parameter in a bitstream representing the number of connected components having boundaries within a triangle mesh in response to a determination that the information represents reverse edgebreaker coding.

[0016] A mesh decoding method according to some embodiments comprises: acquiring a bitstream representing the connectivity of a triangle mesh encoded using edgebreaker coding; reading information from the bitstream representing the direction of the connectivity encoding; reading a parameter from the bitstream representing the number of triangles in the triangle mesh in response to a determination that the information represents reverse edgebreaker coding; and reconstructing the connectivity of the triangle mesh from the bitstream using the parameter representing the number of triangles in the triangle mesh.

[0017] Some embodiments further include the step of reading from a bitstream a parameter representing the number of encoded CLERS symbols, which may be separate from a parameter representing the number of triangles in a triangle mesh.

[0018] Some embodiments further include the step of reading a parameter from a bitstream representing the number of starting positions in a mesh in response to a determination that the information represents reverse edgebreaker coding.

[0019] Some embodiments further include the step of reading from a bitstream a parameter representing the number of connected components having boundaries within a triangle mesh in response to a determination that the information represents reverse edgebreaker coding.

[0020] An apparatus according to some embodiments comprises one or more processors, and the apparatus is configured to perform any one of the methods described herein.

[0021] An apparatus according to some embodiments includes at least one processor and a computer-readable medium storing instructions for performing any one of the methods described herein.

[0022] A computer-readable medium according to some embodiments stores instructions for performing any one of the methods described herein.

[0023] A computer-readable medium according to some embodiments stores a mesh encoded according to any one of the methods described herein.

[0024] A signal according to some embodiments conveys a mesh encoded according to any one of the methods described herein. Brief explanation of the drawing

[0025] Figure 1 is a flowchart illustrating an overview of the MPEG test model intra-frame encoding process. Figure 2 is a flowchart illustrating an overview of the MPEG test model intra-frame decoding process. Figure 3 is a flowchart illustrating an example of a complete edgebreaker mesh codec. The top row is the encoding line, and the bottom row is the decoding line. FIG. 4 illustrates exemplary source code for an encoding procedure according to an exemplary embodiment. FIG. 5 illustrates exemplary source code for a decoding procedure according to an exemplary embodiment. FIG. 6 illustrates exemplary source code for a topology encoding procedure according to an exemplary embodiment. FIG. 7 illustrates a procedure compressComponent according to an exemplary embodiment. Figure 8 illustrates the procedure writeBoundary, which passes through the boundary of _b (a corner given as a parameter) and writes each vertex once in order. FIG. 9 illustrates a procedure checkHandle according to an exemplary embodiment. FIG. 10 illustrates the procedure writeVertex according to an exemplary embodiment. FIG. 11 illustrates a procedure topoPrepass according to an exemplary embodiment. FIG. 12 illustrates a procedure spiraleReversi according to one embodiment. FIG. 13 illustrates a procedure readBoundary according to an exemplary embodiment. FIG. 14 illustrates a procedure closeStar according to an exemplary embodiment. FIG. 15 illustrates a procedure readVertex according to one embodiment. FIG. 16 illustrates the procedure postReindex according to an exemplary embodiment. FIG. 17 illustrates the procedure encodeAttributesWithMainIndexTable according to an exemplary embodiment. FIG. 18 illustrates the procedure encodeAttributesWithPrediction according to an exemplary embodiment. FIG. 19 illustrates the procedure encodeAttributesWithAuxiliaryIndexTable according to an exemplary embodiment. FIG. 20 illustrates an AUX_UV_ENCODE statement to be copied to FIG. 19 according to an exemplary embodiment. FIG. 21 illustrates a first part of the procedure posEncodeWithPrediction according to an exemplary embodiment. FIG. 22 illustrates a second part of the procedure posEncodeWithPrediction according to an exemplary embodiment. FIG. 23 illustrates a first part of the procedure uvEncodeWithPrediction according to an exemplary embodiment. FIG. 24 illustrates a second part of the procedure uvEncodeWithPrediction according to an exemplary embodiment. FIG. 25 illustrates a procedure predictUV for encoding according to an exemplary embodiment. FIG. 26 illustrates a procedure decodeAttributesWithMainIndexTable according to an exemplary embodiment. FIG. 27 illustrates the procedure decodeAttributesWithPredition according to an embodiment. FIG. 28 illustrates a first part of the procedure decodeAttributesWithAuxiliaryIndexTable according to an exemplary embodiment. FIG. 29 illustrates a second part of the procedure decodeAttributesWithAuxiliaryIndexTable according to an exemplary embodiment. FIG. 30 illustrates a third part of the procedure decodeAttributesWithAuxiliaryIndexTable according to an exemplary embodiment. FIG. 31 illustrates an AUX_UV_DECODE statement to be copied to FIG. 30 according to an exemplary embodiment. FIG. 32 illustrates a first part of the procedure posDecodeWithPredictions according to an exemplary embodiment. FIG. 33 illustrates a second part of the procedure posDecodeWithPredictions according to an exemplary embodiment. FIG. 34 illustrates a first part of the procedure uvDecodeWithPrediction according to an exemplary embodiment. FIG. 35 illustrates a second part of the procedure uvDecodeWithPrediction according to an exemplary embodiment. FIG. 36 illustrates a procedure predictUV for decoding according to an exemplary embodiment. FIG. 37 illustrates a first part of the procedure encodePerFaceAttributes according to an exemplary embodiment. FIG. 38 illustrates a second part of the procedure encodePerFaceAttributes according to an exemplary embodiment. FIG. 39 illustrates a first part of the procedure decodePerFaceAttributes according to an exemplary embodiment. FIG. 40 illustrates a second part of the procedure decodePerFaceAttributes according to an exemplary embodiment. FIG. 41 illustrates the procedure applyIndexDeduplicatePerFan used for per-fan deduplications according to some embodiments of an exemplary embodiment. FIG. 42 illustrates code used in delta coding of a handles table within a serialize method according to an exemplary embodiment. FIG. 43 illustrates code used in delta coding of a handles table within an unserialize method according to an exemplary embodiment. FIG. 44 illustrates a modification to the serialize method, particularly the parts related to duplicates, as implemented in some embodiments. FIG. 45 illustrates a modification of the unserialize method, particularly the parts related to duplicates, as implemented in some embodiments. FIG. 46 illustrates a modification to the unserialize method, particularly the parts related to the arithmetic decoding of duplicates, as implemented in some embodiments. FIG. 47 is a block diagram of an example of a system in which various aspects and embodiments are implemented. Specific details for implementing the invention

[0026] Overview of Mesh Coding.

[0027] FIG. 1 is a schematic block diagram of a mesh encoding process in which some embodiments may be implemented. A source mesh model (302) is provided to the mesh encoding process as an input mesh M(i). The source mesh model (302) is associated with a source texture map (304) provided to the encoding process as an input texture map A(i). The input mesh is decimated at 306 to generate a base mesh m(i) having a reduced number of vertices, and a UV atlas for the base mesh is generated at 308. The base mesh is quantized at 310 and encoded at 312, and the compressed base mesh data is multiplexed into a dynamic mesh bitstream at 314. The compressed base mesh data is reconstructed in an encoder to generate a base mesh m'(i) reconstructed by a static mesh decoder (316). The reconstructed base mesh is subdivided at 318 by adding new vertices. A subdivision surface fitting process is performed in 320 by determining a set of displacements d(i) that deform the vertices of the subdivision base mesh to correspond more closely to the surfaces defined by the input mesh M(i) by comparing the subdivision base mesh with the input mesh M(i). These displacements can be updated in 322 to updated displacements d'(i) based on the difference between the original base mesh m(i) and the reconstructed base mesh m'(i). These updated displacements are encoded using a wavelet transform (324) that generates wavelet coefficients e'(i), which are quantized in 326 and packed into an image format in 328. In 330, a series of time-varying images representing the wavelet coefficients can be encoded using conventional video encoding techniques, and in 314, the encoded video can be multiplexed with data representing the compressed base mesh.In the encoder, displacements from the encoded video are reconstructed through image unpacking (329), inverse quantization (331), and inverse wavelet transform (332) to generate a set of reconstructed displacements d(i). The reconstructed base mesh M''(i) is obtained through inverse quantization of the reconstructed quantized base mesh m'(i) at 334, and the reconstructed base mesh M''(i) is subdivided at 336. At 338, a reconstructed modified mesh DM(i) is generated by applying the set of reconstructed displacements d''(i) to the reconstructed base mesh m'(i). The reconstructed modified mesh DM(i) is used as a destination mesh model (340) for attribute transfer (341).

[0028] Using the reconstructed deformed mesh DM(i) (destination mesh model (340)), input mesh M(i) (source mesh model (302)), and input texture map A(i) (source texture map (304)), an attribute transfer process is performed to provide attribute values ​​for the destination texture map A'(i) associated with the reconstructed deformed mesh DM(i). Pixels within texture map A'(i) that are not associated with any triangle of the reconstructed deformed mesh DM(i) can be filled using a padding process (342). A color space conversion (344) can be performed, and a series of time-varying texture maps A'(i) can be encoded using conventional video encoding techniques (346), and the encoded video can be multiplexed into a bitstream (350) along with data representing the base mesh and displacements compressed in 314. Patch information (348) can also be multiplexed into the bitstream.

[0029] FIG. 2 illustrates an example of a mesh decoder. The mesh decoder demultiplexes different sub-bitstreams from, for example, a V3C bitstream. The sub-bitstreams may include a sub-bitstream representing a static mesh, a sub-bitstream representing displacements, and one or more sub-bitstreams representing attributes. In the example of FIG. 2, the displacements sub-bitstream is exemplified as being decoded by a video decoder, but different decoder configurations may be used depending on the parameters received within the bitstream, as discussed in more detail below. For example, the decoder may be configured to use an arithmetic decoder instead of a video decoder for coding the displacements. Additionally, if video coding is used, different decoder configurations may use different video codecs (such as AVC, HEVC, VVC, etc.).

[0030] Overview of exemplary embodiments.

[0031] The present disclosure describes an implementation of a reverse version of edgebreaker coding, comprising adaptations included to operate on all sequences of V-Mesh CTCs. In addition to encoding / decoding the mesh topology, the present disclosure also describes apparatuses and methods for attribute prediction and arithmetic coding. This reverse version provides compression performance results for MPEC CTCs that are up to 6% better than the forward version, having faster encoding / decoding runtimes.

[0032] Some embodiments use topology encoding and decoding techniques as described in Lewiner et al. (2004). In these embodiments, there is no need to handle virtual points and table restarts. This enables simplification of several functional blocks of the system, such as attribute prediction, post-reindexing, alternative vertex traversal, adaptation of per-face attributes extension, and support for vertex deduplication.

[0033] The flowchart of FIG. 3 provides an overview of an edgebreaker mesh codec according to some embodiments. The top row is the encoding line, and the bottom row is the decoding line. Exemplary commented source code for different function blocks is provided in this disclosure. Exemplary modifications to V3C syntax are further provided in this specification. As illustrated in FIG. 3, an exemplary edgebreaker encoder performs preprocessing (102) of the mesh to accommodate, for example, non-manifold surfaces or to quantize attributes. In 104, the encoder performs connectivity coding using edgebreakers to generate a CLERS table representing connectivity. In 106, the encoder performs prediction of the attributes of the mesh. The prediction may proceed in a topology-based order determined by the edgebreaker encoding. Alternatively, prediction may proceed using different orders, such as depth-first traversal or vertex-degree-based traversal. In 108, alternate traversal is performed. The encoder may signal information in the bitstream indicating which type of traversal is used for attribute prediction. The encoder may test different traversal types (e.g., topology-based traversal types and one or more alternate traversal types) and encode the mesh using whichever traversal type provides the best performance (e.g., maximum compression). In 110, entropy coding of the CLERS table, other information regarding the mesh's topology (e.g., handle information), and / or attribute residuals is performed. The bitstream containing this entropy-encoded information may be stored for later use or transmitted to the encoder without intermediate storage.

[0034] In step 112, the decoder performs entropy decoding on the received bitstream, including appropriate entropy decoding of the CLERS table, handle information, and / or attribute residual information. In step 114, the decoder reconstructs the topology or connectivity of the mesh using the CLERS table and related information. In step (116), the decoder performs attribute prediction and correction using an appropriate traversal type corresponding to the traversal type used by the encoder (which can be signaled in the bitstream). If the traversal type is an alternative traversal type, the decoder performs an appropriate alternative traversal in step 118. If the traversal type is based on the topology of the mesh reconstructed in step 114, an alternative traversal is not required. In step 120, post-processing is performed, for example, to regenerate manifold structures, dequantize attributes, and perform post-indexing.

[0035] Exemplary source code for the encoding high-level procedure encode is depicted in Fig. 4. It performs preprocessing, connectivity coding, and attribute prediction. Entropy coding and encoding according to V3C syntax are performed in a method named serialize, the relevant parts of which are described below.

[0036] Exemplary code for the decoding high-level procedure decode is depicted in FIG. 5. Following the parsing of the bitstream and arithmetic decoding (executed by the method unserialize, which is presented in part), it performs decoding of connectivity (procedures topoPrepass and spiraleReversi), decoding of attributes, and optional post-processing.

[0037] In these two high-level procedures, the addition and removal of virtual points (also known as dummy points) used in some implementations to handle holes within the surface are no longer necessary and are therefore removed.

[0038] Exemplary embodiments implement topology coding and decoding techniques as described in Lewiner et al. (2004). Exemplary implementations for encoding and decoding are provided below.

[0039] The procedure encodeTopology (see FIG. 6) is the entry point for the topology encoding part. As shown in bold in FIG. 6, exemplary embodiments store the information ccStartCorners and processedCorners. These are later used to perform traversal for attribute prediction and post-reindexing. Exemplary embodiments also encode some UV coordinates for which a complete pass for the locations was previously performed. Thus, some exemplary embodiments encode all attributes in successive ordered passes after topology encoding. (The same order can be used for decoding.) An exemplary order is as follows:

[0040] 1. Topology encoding.

[0041] 2. Encoding of location attributes (defines the main index table).

[0042] 3. Optionally encode UV attributes using the main index table,

[0043] 4. Or optionally encode UV attributes using a secondary index table.

[0044] 5. Optional encoding of face-specific attributes.

[0045] Passes that follow the topology order use the table processedCorners. Otherwise, the order can be reconfigured using a predefined traversal method such as the table ccStartCorners (which stores the first corner of each connected component - CC -) and one or more of the vertex traversal methods described in European Patent Application No. 23306154.8.

[0046] The procedure encodeTopology first encodes all connected components (CCs) that have boundaries and then encodes all connected components that do not have boundaries. For each connected component, it calls the procedure compressComponent (see FIG. 7) with a start corner as a parameter. This procedure uses an edge breaker spiraling method to traverse all triangles of the connected component and generates CLERS symbols that are written to the end of the oClers table of symbols. In this embodiment, the component start corners are retained in memory but do not need to be written to the bitstream. The procedure encodeTopology differs from the procedure of Lewiner et al. (2004) by storing the corners processed while traversing the triangles of the connected component.

[0047] For each connected component with a boundary, the procedure encodeTopology first encodes the first boundary of the connected component (by calling procedure writeBoundary(ov.n(c))) before calling procedure compressComponent, which will encode the other boundaries of the connected component if any 'S' cases are encountered during triangle traversal.

[0048] The procedure writeBoundary illustrated in FIG. 8 differs from the corresponding procedure disclosed in Lewiner et al. (2004) in that for each new boundary, a unique Id is generated between -3 and -infinity. Each opposite corner of the boundary corner is marked with this 1d. Note that -1 and -2 are values ​​reserved for other purposes in this embodiment, which is why we start at -3.

[0049] For topology handles, holes (boundaries) are marked using handles (pairs of integers for reconnecting faces). Boundary source corners are stored as negative integers (starting from -3). Some additional precautions are taken when storing corner IDs in handle tables. The checkHandle procedure of this disclosure differs from the procedure of Lewiner et al. (2004) as depicted in FIG. 9. In the new statement below:

[0050] if (br != 0 && br != 1 && br != -1)

[0051] br == -1 means the right corner is invalid, br == 1 means the right triangle is visited but not on the 'S' symbol, and br == 0 means the right triangle has not yet been visited. In each of these cases, we do not want to save to the handle table. The corresponding tests are performed for the left corners.

[0052] The procedure writeVertex stores vertex attributes for additional predictions. In exemplary embodiments, if the prediction option for the attributes is off, they are stored directly in the table for AC coding. Otherwise, the corner IDs given as parameters are appended to the end of the table writtenCorners, which is used later when using topology traversal for attribute predictions. For alternative traversals, such as prediction degree or depth traversals, there is no need to push IDs, and the writeVertex procedure performs nothing.

[0053] The procedures topoPrepass (see FIG. 11) and spiraleReversi (Fig. 12) are two steps of the topology decoding part. In some embodiments, the procedure topoPrepass may be skipped (in exchange for additional data in the bitstream). It is used to prepare a final CLERS table containing special P symbols that terminate connected components without boundaries. These symbols are implicitly recovered from the rest of the chain. Subsequently, spiraleReversi traverses the chain in a single pass to decode the topology.

[0054] In exemplary embodiments, the topoPrepass procedure is configured to manage handles appropriately. The exemplary embodiments additionally populate a table of corner indices, ccStartCorners, to track the first corner of each connected component. This table is later used for predictions using traversals other than spiral traversal (e.g., vertex degree traversal).

[0055] In exemplary embodiments, the spiraleReversi method is configured to store the processing order of corners (table processedCorners) and the reading order of corners (table readCorners). These two tables are later used when performing successive traversals for attribute predictions using the spiral order (i.e., not the vertex degree). readBoundary (Fig. 13) is also configured to update the readCorners table. The closeStar method operates as described in Lewiner et al. (2004). The readVertex method is configured to consume attributes only when the predictions are off. Otherwise, the predictions are read and computed later during some other passes.

[0056] In an exemplary embodiment, once the topology is decoded, some or all of the following steps are performed (see FIG. 5):

[0057] 1. Decode the attributes using the main index table.

[0058] 2. If present, decode the attributes using the secondary index table.

[0059] 3. Decode the surface-specific attributes.

[0060] 4. Complete duplicate removal if necessary.

[0061] 5. If the option is on (or off for v-dmc), inverse quantize the attributes of the corner table (CT) mesh.

[0062] 6. If the option is on, re-index the topology.

[0063] 7. Convert the decoded corner table back into a set of triangles.

[0064] An exemplary procedure postReindex for performing topology re-indexing is shown in FIG. 16. Compared to the forward implementation, this is simplified because there is no need to handle dummy points or manage multiple table starts. Instead, only startCorners are used. Corner tables do not need to be finalized with appropriate (shifted) indexes because their indexes are already valid. Decoding of attributes is performed by steps 1 through 3.

[0065] Vertex-specific attributes using the main index table. Encoding and decoding of attributes using the main index table are initiated, where appropriate, by the procedure encodeAttributesWithMainIndexTable (Fig. 17) or decodeAttributesWithMainIndexTable (Fig. 26). These procedures use a selection of traversal methods from the topology order (EB) or a vertex degree traversal (DEGREE), but any other traversal, such as DEPTH, may be used alternatively. Note that in the case of EB, the traversal order is the order contained in the writtenCorners table filled during the topology traversal. In the case of DEGREE, the traversal may be performed using a vertex degree traverser as described in EP 23306154.8 for each starting corner of each connected component (the table of ccStartCorners generated during the topology stages).

[0066] Using the appropriate traversal table, the encodeAttributeWithPrediction(traversal) or decodeAttributeWithPrediction(traversal) procedure is called as appropriate. The attribute prediction method calls the position predictor posEncodeWithPrediction(c) or posDecodeWithPrediction(c) for each corner of the traversal given as a parameter. Once all positions are predicted, the same operation is performed on the UV coordinates by optionally calling uvEncodeWithPrediction or uvDecodeWithPrediction for each corner of the traversal given as a parameter (if UVs use the main index). This operation will be performed as additional passes for any other attributes using the main index table, such as normal vectors, colors, etc.

[0067] In decoding, some traversal tables are scanned in reverse because the topology traversal algorithm is performed in reverse. Therefore, the parameter "reverse" of the decodeAttributesWithPredition procedure is set to true when using EB traversal and to false when using DEGREE traversal.

[0068] Exemplary embodiments may perform a process of managing deduplicates in a manner different from the TMv6 method. In TMv6, locations and attributes are processed in the same pass, whereas here, separate passes are used, which can lead to better predictions of attributes. Therefore, the structure of the algorithm is reorganized, and to skip predictions for duplicate vertices due to non-manifold issues during preprocessing, a Boolean for each corner, which is set by the first pass (location pass) and used by any other subsequent passes (e.g., UV prediction when using the main index in our implementation), is stored in a table named predictCorner (see Fig. 3).

[0069] Vertex attributes using a secondary index table. Encoding or decoding of attributes using an auxiliary index table is initiated by the procedure encodeAttributesWithAuxiliaryIndexTable (Fig. 19) or decodeAttributesWithAuxiliaryIndexTable (Figs. 28 to 30) where appropriate.

[0070] The encodeAttributesWithAuxiliaryIndexTable or decodeAttributesWithAuxiliaryIndexTable procedures follow the same general structure as the corresponding procedures encodeSeparateIndexAttributes or decodeSeparateIndexAttributes from the forward solution implemented in TMv6. One difference is that TMv6 calls the procedures component by component, whereas the exemplary embodiments described herein perform the iteration in a single call. Additionally, the exemplary embodiments no longer test for virtual points during UV seam definition, but a statement is added to detect boundaries using an opposite table to skip UV seam definition. Since there is no need to define a seam when it is on a boundary, savings are achieved by not pushing it into the isSeam table.

[0071] Once the seams are properly defined, exemplary embodiments call the uvEncodeWithPrediction procedure for each corner of the selected iteration order (EB, DEGREE, DEPTH, ...).

[0072] Attribute predictions by vertex. In exemplary embodiments, the prediction of vertex positions is performed by the procedures posEncodeWithPrediction (Figs. 21 and 22) and posDecodeWithPrediction (Figs. 32 and 33).

[0073] In TMv6, predictions for a given corner involve searching multiple parallelograms by rotating around the vertex of this corner to compute the predictions. When a neighboring corner is detected as a dummy point, it is skipped so as not to interfere with the prediction. As seen in the topology section, exemplary embodiments mark boundaries instead of using dummy points. Predictions use these boundaries. For each corner, the associated vertex is connected to a full triangle fan or, if on a boundary, a partial triangle fan. In an exemplary embodiment, the search of parallelograms for a given corner thus starts at the right corner and rotates around the associated vertex until it reaches a boundary or back to that corner. It then rotates in a different direction until it reaches another boundary or c.

[0074] If at least one parallelogram is found, it is used for prediction (if available, more than one parallelogram may be used), and the residuals are pushed to the oVertices table; otherwise, delta coding with the next corner is used if already predicted, and delta coding with the previous corner is used otherwise. For arithmetic coding, it would be beneficial to store the delta values ​​in a separate table dedicated to deltas. In the current version, these are also pushed to the oVertices table.

[0075] Exemplary embodiments use a different fallback (Case 3), which is as follows: if the corners are at the start but are near the already predicted outer boundary, use this for delta prediction and push to oVertices. The same applies in that pushing to a specific table for delta residuals provides an advantage in AC coding.

[0076] Exemplary embodiments fall back by pushing a new start in global coordinates to the osVertices table. Typically, this occurs only when c is the first corner of the new connected component.

[0077] Arithmetic coding of the tables oVertices (predicted positions) and osVertices (start positions) can be performed using techniques as described in TMV6.0.

[0078] The posDecodeWithPrediction procedure can be used to reconstruct location values ​​from predictions.

[0079] In some embodiments, the prediction of vertex UV coordinates is performed by the procedures uvEncodeWithPrediction (Figs. 23 and 24) and uvDecodeWithPrediction (Figs. 34 and 35), which perform a search for valid predictors around corners in the same way as for positions, and two predictUV procedures (Figs. 25 and 36) which actually calculate min-stretch predictions.

[0080] These four methods take a reference to the index table (tcIndices) to be used for predictions as a parameter. This allows the use of prediction mechanisms for attributes that use a main index table and attributes that use a secondary index table. Then, the general algorithm is simplified compared to one of TMv6, which performs a specific algorithm for each type of index table.

[0081] In exemplary embodiments, the prediction of UV coordinates includes checking whether a minimum stretch is possible regardless of the corners before falling back to the delta, then to the boundary, then to the start in the global coordinates of UV space. This makes it possible to use UV predictions for some corners that are the start in relation to position prediction. This does not apply to the forward version of TMv6, which systematically sets the start for the first corner of the connected component, then the delta for the next two corners, and then the minimum stretch predictions for the other corners.

[0082] Attributes per surface. A technique for coding face-specific attributes in TMv6 is disclosed in European Patent Application No. 23305941.9. The exemplary embodiments described herein are simplified because there is no longer a need to handle virtual points. The exemplary embodiments are also adapted to handle boundaries using an inverse table. The procedures encodePerFaceAttributes (Figs. 37 and 38) and decodePerFaceAttributes (Figs. 39 and 40) are presented with additions indicated in bold. For example, when examining neighbors to find support for predictions, the exemplary embodiments also test the inverse table for negative values ​​to check for the presence of boundaries. Thanks to the coding of boundaries with negative integers in the corner table, the overall complexity is consequently reduced.

[0083] Arithmetic encoding and decoding.The general schema for coding and decoding different tables is the same as that presented in TMv6.0. Exemplary embodiments provide modified coding of handles. In exemplary embodiments, the handle table is used not only to code the handles but also to code boundaries using negative integer values ​​for the first pair of handle values ​​(see FIG. 11). The AC coding model from TMv6 is no longer so simple because it is also necessary to code the sign. In some embodiments, handles are coded as delta values, as shown in FIGs. 42 and 43.

[0084] In an exemplary embodiment, the mesh coding header syntax includes a parameter representing a mesh codec type, such as the parameter mesh_codec_type. The parameter may take values ​​having identifiers such as CODEC_TYPE_FORWARD for a forward codec or CODEC_TYPE_REVERSE for a reverse codec type.

[0085] In an exemplary embodiment, the mesh position coding payload syntax (such as that of Section I.8.3.7 of V-DMC) can be implemented as follows:

[0086]

[0087]

[0088]

[0089] Mesh position coding payloads can have the following semantics:

[0090] mesh_vertex_count Specifies the number of vertices within the decoded mesh. (mesh_vertex_count may not include virtual points inserted during topology reconstruction and removed during the subsequent mesh cleaning phase.)

[0091] mesh_triangle_count Specifies the number of triangles in the decoded mesh.

[0092] mesh_clers_count Specifies the number of encoded CLERS symbols. (The first symbol in the symbol sequence for each connected component is not coded. After topology reconstruction, the number of triangles is (mesh_clers_count + mesh_cc_count). After mesh cleanup, an unspecified number of triangles connected to virtual points are removed.)

[0093] mesh_cc_count Specifies the number of connected components included in the coded mesh. In the case of mesh_codec_type=CODEC_TYPE_REVERSE, mesh_cc_count Specifies the number of connected components with boundaries included in the coded mesh (the number of components without boundaries is inferred from CLERS parsing). (If the first positions of the connected components are duplicates of previously encoded indices, the absolute number of coded positions may be less than mesh_cc_count.)

[0094] mesh_position_start_count Specifies the number of starting positions.

[0095] mesh_virtual_vertex_count specifies the number of virtual vertices inserted to close holes in the reconstructed topology.

[0096] mesh_virtual_index_delta[i] specifies the difference between the values ​​of the i-th virtual point index and the (i-1)-th virtual point index when i is greater than 0. When i is equal to 0, mesh_virtual_index_delta

[0000] specifies the value of the index of the first virtual point.

[0097] mesh_cc_with_handles_countSpecifies the number of connected components that have a non-zero handle count.

[0098] mesh_handles_cc_offset[i] When i is greater than 0, specifies the difference between the index of the i-th connected component with a non-zero handle count and the value of the (i-1)-th connected component with a non-zero handle count. When i is equal to 0, mesh_handles_cc_offset

[0000] specifies the index of the first connected components with a non-zero handle count.

[0099] mesh_handles_count[i] Specifies the number of handles included in the i-th connected component that has a non-zero handle count.

[0100] mesh_handle_index_first_delta[i] specifies the difference between the triangle index of the first corner of the i-th handle and the first corner of the (i-1)-th handle when i is greater than 0. When i is equal to 0, mesh_handle_index_first_delta

[0000] specifies the triangle index of the first corner of the first handle.

[0101] mesh_handle_index_second_delta[i] specifies the difference between the triangle index of the second corner of the i-th handle and the second corner of the (i-1)-th handle when i is greater than 0. When i is equal to 0, mesh_handle_index_second_delta

[0000] specifies the triangle index of the second corner of the first handle.

[0102] mesh_coded_handle_index_second_shift_size specifies the size in bytes of an arithmetic-coded sequence of mesh_handle_index_second_shift values, including final byte alignment.

[0103] mesh_handle_index_second_shift[i]Specifies the shift to apply when calculating the corner index associated with the i-th handle destination. (Handle indices are relative to triangle / face indices because the associated corner indices can be implicitly inferred. The corner index of the first handle follows (3 * T + 0). The corner index of the second handle follows (3 * T + 1) or (3 * T + 2). mesh_handle_index_second_shift[i] is used to distinguish between these two cases.)

[0104] mesh_coded_clers_symbol_size Specifies the size in bytes of the arithmetic-coded sequence of CLERS symbols, including final byte alignment. (Explicitly specifying mesh_coded_clers_symbols_size enables the parsing and decoding of CLERS symbols to proceed in parallel.

[0105] mesh_clers_symbol[i] specifies the value of the i-th CLERS symbol. The values ​​are interpreted as specified by the table below:

[0106]

[0107] mesh_position_start[i][j] specifies the value of the j-th component at the first position of the i-th connected component as an unsigned integer coded using mesh_position_bit_depth_minus1 + 1 bit.

[0108] mesh_coded_position_residuals_size Specifies the size in bytes of the arithmetic-coded sequence of position residuals, including final byte alignment. (Explicitly specifying mesh_coded_position_residuals_size enables the parsing and decoding of position prediction residuals to proceed in parallel.)

[0109] mesh_position_residual[i][j] specifies the value of the prediction residual associated with the j-th component of the i-th predicted position.

[0110] Serialization / Deserialization. In an exemplary embodiment, the unserialize method is called after syntax parsing and before the decode method is called. This completes arithmetic decoding and sets some other global variables that cannot be inferred during syntax parsing. Compared to the corresponding method from TMv6, the unserialize method according to the exemplary embodiment has some or all of the following features:

[0111] Code sections associated with virtual points are removed as unnecessary.

[0112] The parts related to duplicate removal in the serialize method (Fig. 43) and unserialize method (Figs. 44 and 45) are modified.

[0113] The global variables nV and nUV are calculated as follows after the arithmetic decoding of iVertices, isVertices, iUVCoords, and isUVCoords is performed as follows, where nV is the total number of decoded positions and nUV is the total number of decoded UV coordinates:

[0114] nV = iVertices.size() + isVertices.size();

[0115] const auto recUv = iUVCoords.size() + isUVCoords.size();

[0116] nUV = hasSeparateUvIndex ? recUv : (recUv ? nV : 0);

[0117] The global variable NumPositionStart is mesh_cc_count Instead mesh_position_start_count It is set to this, and the reason is mesh_cc_count This is because it represents only the components with boundaries, not the entire set of connected components. New from syntax mesh_position_start_count is used to find the values ​​of absolute positions.

[0118] Exemplary embodiments may primarily use syntax according to the V-DMC (Video-based dynamic mesh coding) working draft, even with some modifications. For example, in some embodiments, the syntax allows signaling that the mesh is of the inverse type. For example, mesh_codec_type It can be signaled with the name CODEC_TYPE_REVERSE. As shown in the syntax proposed above, the reverse mesh_codec_type In the case of =CODEC_TYPE_REVERSE, parameters mesh_triangle_count and mesh_position_start_count is included in the syntax. In forward codecs, these parameters are inferred by other means, but they cannot be inferred in the same way in the reverse version. Parameters mesh_cc_count It can be signaled in the syntax for both forward and reverse codecs, but the meaning of the parameter may differ for the two cases as described above.

[0119] As additionally shown in the exemplary syntax above, reverse mesh_codec_type In the case of =CODEC_TYPE_REVERSE

[0120] - Information related to virtual points is removed.

[0121] - Information related to the AC coding of the handles is removed.

[0122] - parameters mesh_triangle_count and mesh_position_start_countis signaled.

[0123] In reverse mode, mesh_attribute starts are stored under any circumstances. This is because the uv predictor may have some predictions regarding the start positions, making further inference impossible. Therefore, the uv start array does not have the same size as the position start array.

[0124] The presented software code is C++ code (sometimes simplified).

[0125] math:

[0126] - dvec2 is a mathematical 2D vector of C / C++ double values ​​(64-bit floating-point).

[0127] - vec2 is a mathematical 2D vector of C / C++ float values ​​(32-bit floating-point).

[0128] - std::sqrt returns the mathematical square root of the parameter.

[0129] - std::round returns the mathematical rounding of the parameter to the nearest integer.

[0130] Data Structures:

[0131] - std::vector <float>name; is an array of floats named name. Float can be replaced with another type such as vec2, and then the following methods will all operate on vec2 values ​​instead of floats.

[0132] - name[i] dereferences the array name at index i.

[0133] - name.push_back(v) adds a new element of value v to the end of array name by increasing the size of array name by 1 element.

[0134] - name.reserve(n) reserves some memory for the vector name, but its number of valid elements name.size() does not change. Such memory pre-allocation prevents multiple memory reallocations for multiple calls to name.push_back().

[0135] - name.assign(n,v) resizes the array name to contain n elements and sets all values ​​to v. v is optional, and if not provided, a default value is used.

[0136] - name.resize(n, v) resizes the array name to contain n elements and sets the new values ​​to v. The existing values ​​remain unchanged. v is optional, and if not provided, the default value is used.

[0137] Corner table (named ov or _ovTable):

[0138] - ov.t(c) returns the triangle index of the corner at index c if c is valid (i.e., within [0,NB_CORNERS]), and -1 otherwise.

[0139] - ov.n(c) returns the index of the next corner of index c if c is valid (i.e., within [0,NB_CORNERS]), and -1 otherwise.

[0140] - ov.p(c) returns the index of the previous corner of index c if c is valid (if it is within [0,NB_CORNERS]), and -1 otherwise.

[0141] - ov.o(c) returns the index of the opposite corner of index c if c is valid (if it is within [0,NB_CORNERS]), and -1 otherwise.

[0142] FIG. 4 illustrates exemplary source code for an encoding procedure according to an exemplary embodiment.

[0143] FIG. 5 illustrates exemplary source code for a decoding procedure according to an exemplary embodiment.

[0144] FIG. 6 illustrates exemplary source code for a topology encoding procedure according to an exemplary embodiment. FIG. 6 illustrates a topology encoding procedure named encodeTopology. Compared to the procedure named Compress in Lewiner et al. (2004), the encoding procedure of FIG. 6 includes additional features such as recording the starting corners of connected components and recording the corner processing order. These features are illustrated in bold in FIG. 6.

[0145] FIG. 7 illustrates the procedure compressComponent. Compared to the corresponding procedure in Lewiner et al. (2004), this procedure includes additional features such as recording each corner in a processed corner table.

[0146] Figure 8 illustrates the procedure writeBoundary, which passes through the boundary of _b (a corner given as a parameter) and writes each vertex in order once. Features of particular interest are exemplified in bold.

[0147] FIG. 9 illustrates a procedure checkHandle according to an exemplary embodiment. Features of particular interest are illustrated in bold.

[0148] FIG. 10 illustrates the procedure writeVertex according to an exemplary embodiment.

[0149] FIGS. 11 to 16 illustrate topology decoding procedures according to one embodiment.

[0150] FIG. 11 illustrates a procedure topoPrepass according to an exemplary embodiment.

[0151] FIG. 12 illustrates a procedure spiraleReversi according to one embodiment.

[0152] FIG. 13 illustrates a procedure readBoundary according to an exemplary embodiment.

[0153] FIG. 14 illustrates a procedure closeStar according to an exemplary embodiment.

[0154] FIG. 15 illustrates a procedure readVertex according to one embodiment.

[0155] FIG. 16 illustrates the procedure postReindex according to an exemplary embodiment.

[0156] FIGS. 17 to 25 illustrate procedures related to attribute prediction for encoding according to exemplary embodiments.

[0157] FIG. 17 illustrates the procedure encodeAttributesWithMainIndexTable according to an exemplary embodiment.

[0158] FIG. 18 illustrates the procedure encodeAttributesWithPrediction according to an exemplary embodiment.

[0159] FIG. 19 illustrates the procedure encodeAttributesWithAuxiliaryIndexTable according to an exemplary embodiment.

[0160] FIG. 20 illustrates an AUX_UV_ENCODE statement to be copied to FIG. 19 according to an exemplary embodiment.

[0161] FIG. 21 illustrates a first part of the procedure posEncodeWithPrediction according to an exemplary embodiment.

[0162] FIG. 22 illustrates a second part of the procedure posEncodeWithPrediction according to an exemplary embodiment.

[0163] FIG. 23 illustrates a first part of the procedure uvEncodeWithPrediction according to an exemplary embodiment.

[0164] FIG. 24 illustrates a second part of the procedure uvEncodeWithPrediction according to an exemplary embodiment.

[0165] FIG. 25 illustrates a procedure predictUV for encoding according to an exemplary embodiment.

[0166] FIGS. 26 to 36 illustrate attribute prediction procedures for decoding according to exemplary embodiments.

[0167] FIG. 26 illustrates a procedure decodeAttributesWithMainIndexTable according to an exemplary embodiment.

[0168] FIG. 27 illustrates the procedure decodeAttributesWithPredition according to an embodiment.

[0169] FIG. 28 illustrates a first part of the procedure decodeAttributesWithAuxiliaryIndexTable according to an exemplary embodiment.

[0170] FIG. 29 illustrates a second part of the procedure decodeAttributesWithAuxiliaryIndexTable according to an exemplary embodiment.

[0171] FIG. 30 illustrates a third part of the procedure decodeAttributesWithAuxiliaryIndexTable according to an exemplary embodiment.

[0172] FIG. 31 illustrates an AUX_UV_DECODE statement to be copied to FIG. 30 according to an exemplary embodiment.

[0173] FIG. 32 illustrates a first part of the procedure posDecodeWithPredictions according to an exemplary embodiment.

[0174] FIG. 33 illustrates a second part of the procedure posDecodeWithPredictions according to an exemplary embodiment.

[0175] FIG. 34 illustrates a first part of the procedure uvDecodeWithPrediction according to an exemplary embodiment.

[0176] FIG. 35 illustrates a second part of the procedure uvDecodeWithPrediction according to an exemplary embodiment.

[0177] FIG. 36 illustrates a procedure predictUV for decoding according to an exemplary embodiment.

[0178] FIG. 37 illustrates a first part of the procedure encodePerFaceAttributes according to an exemplary embodiment.

[0179] FIG. 38 illustrates a second part of the procedure encodePerFaceAttributes according to an exemplary embodiment.

[0180] FIG. 39 illustrates a first part of the procedure decodePerFaceAttributes according to an exemplary embodiment.

[0181] FIG. 40 illustrates a second part of the procedure decodePerFaceAttributes according to an exemplary embodiment.

[0182] FIG. 41 illustrates the procedure applyIndexDeduplicatePerFan used for deduplication per fan according to some embodiments.

[0183] FIG. 42 illustrates code used in delta coding of a handle table within a serialize method according to an exemplary embodiment.

[0184] FIG. 43 illustrates code used in delta coding of a handle table within an unserialize method according to an exemplary embodiment.

[0185] FIG. 44 illustrates modifications to the serialize method, particularly those related to duplicates, as implemented in some embodiments. Compared to the forward version, exemplary embodiments of the present disclosure remove code indicated by strikethrough and include code indicated by bold.

[0186] FIG. 45 illustrates modifications to the unserialize method, particularly those related to duplicates, as implemented in some embodiments. Compared to the forward version, exemplary embodiments of the present disclosure remove code marked with a strikethrough and include code marked in bold.

[0187] FIG. 46 illustrates modifications to the unserialize method, particularly those related to the arithmetic decoding of duplicates, as implemented in some embodiments. Compared to the forward version, exemplary embodiments of the present disclosure remove code indicated by strikethrough and include code indicated in bold.

[0188] Exemplary embodiments enable the use of edgebreaker spiral reversi within the MPEG EB and V3C syntax of V-DMC.

[0189] Exemplary embodiments enable the use of efficient vertex-specific predictions with edgebreaker spiral reversi and boundary management.

[0190] Exemplary embodiments enable the use of efficient faceId predictions with edgebreaker spiral reversi and boundary management.

[0191] Exemplary embodiments of reverse encoding and decoding systems and methods as described herein are considered to have lower complexity implementations than corresponding forward implementations. This reduction in complexity can further increase the feasibility of hardware-based codec implementations.

[0192] The exemplary embodiments were found to lead to more efficient encoding (while the acquired sizes are generally similar, a gain of 1% to 6% is achieved in the C0 conditions of V-DMC CTCs (the condition with the highest mesh density to be coded)). The exemplary embodiments were tested on 290 models in a large dataset and were found to perform encoding and decoding about 1% faster than the corresponding forward codec. The exemplary embodiments allow for a possible implementation of valence-driven encoding.

[0193] Exemplary system hardware.

[0194] Exemplary embodiments of encoders and / or decoders (collectively coders) configured to implement the embodiments described herein may be implemented using systems such as the system of FIG. 47. FIG. 47 is a block diagram of an example of a system in which various aspects and embodiments are implemented. The system (1000) may be implemented as a device comprising various components described below and configured to perform one or more of the aspects described in this document. Examples of such devices include, but are not limited to, various electronic devices such as personal computers, laptop computers, smartphones, tablet computers, digital multimedia set-top boxes, digital television receivers, personal video recording systems, connected consumer electronics, and servers. The elements of the system (1000) may be implemented, alone or in combination, as a single integrated circuit (IC), multiple ICs, and / or discrete components. For example, in at least one embodiment, the processing and encoder / decoder elements of the system (1000) are distributed across a number of ICs and / or discrete components. In various embodiments, the system (1000) is communicably coupled to one or more other systems or other electronic devices, for example, via a communication bus or via dedicated input and / or output ports. In various embodiments, the system (1000) is configured to implement one or more of the embodiments described herein.

[0195] The system (1000) includes at least one processor (1010) configured to execute instructions loaded therein to implement, for example, the various embodiments described in this document. The processor (1010) may include embedded memory, an input / output interface, and various other circuit components as known in the art. The system (1000) includes at least one memory (1020) (e.g., a volatile memory device and / or a non-volatile memory device). The system (1000) includes a storage device (1040) that may include non-volatile memory and / or volatile memory, including but not limited to EEPROM (Electrically Erasable Programmable Read-Only Memory), ROM (Read-Only Memory), PROM (Programmable Read-Only Memory), RAM (Random Access Memory), DRAM (Dynamic Random Access Memory), SRAM (Static Random Access Memory), flash, magnetic disk drive and / or optical disk drive. The storage device (1040) may include, as non-limiting examples, an internal storage device, an attached storage device (including detachable and non-detachable storage devices), and / or a network-accessible storage device.

[0196] The system (1000) includes, for example, an encoder / decoder module (1030) configured to process data to provide encoded video or decoded video, and the encoder / decoder module (1030) may include its own processor and memory. The encoder / decoder module (1030) represents a module(s) that may be included in a device to perform encoding and / or decoding functions. As is known, the device may include one or both of an encoding module and a decoding module. Additionally, the encoder / decoder module (1030) may be implemented as a separate element of the system (1000) as is known to a person skilled in the art, or may be integrated within the processor (1010) as a combination of hardware and software.

[0197] Program code to be loaded into a processor (1010) or an encoder / decoder (1030) to perform the various embodiments described in this document may be stored in a storage device (1040) and subsequently loaded into memory (1020) for execution by the processor (1010). According to various embodiments, one or more of the processor (1010), memory (1020), storage device (1040), and encoder / decoder module (1030) may store one or more of various items during the execution of the processes described in this document. Such stored items may include, but are not limited to, input video, decoded video or parts of decoded video, bitstreams, matrices, variables, and intermediate or final results from the processing of equations, formulas, operations, and operation logic.

[0198] In some embodiments, memory within the processor (1010) and / or encoder / decoder module (1030) is used to store instructions and provide working memory for processing required during encoding or decoding. However, in other embodiments, memory outside the processing device (e.g., the processing device may be either the processor (1010) or the encoder / decoder module (1030)) is used for one or more of these functions. The external memory may be memory (1020) and / or storage device (1040), e.g., dynamic volatile memory and / or non-volatile flash memory. In some embodiments, the external non-volatile flash memory is used to store, for example, the operating system of a television. In at least one embodiment, high-speed external dynamic volatile memory, such as RAM, is used as working memory for video coding and decoding operations, such as MPEG-2 (MPEG refers to Moving Picture Experts Group, MPEG-2 is also referred to as ISO / IEC 13818, 13818-1 is also known as H.222, and 13818-2 is also known as H.262), HEVC (HEVC refers to High Efficiency Video Coding, also known as H.265 and MPEG-H Part 2), or VVC (Versatile Video Coding, a new standard being developed by the Joint Video Experts Team (JVET)).

[0199] Inputs to the elements of the system (1000) may be provided through various input devices as shown in block (1130). These input devices include, but are not limited to, (i) an RF part that receives an RF (radio frequency) signal transmitted over the air by, for example, a broadcaster, (ii) a component (COMP) input terminal (or a set of COMP input terminals), (iii) a USB (Universal Serial Bus) input terminal, and / or (iv) an HDMI (High Definition Multimedia Interface) input terminal. Other examples include composite video.

[0200] In various embodiments, the input devices of block (1130) have their respective input processing elements as known in the art. For example, the RF portion may be associated with elements suitable for (i) selecting a desired frequency (also referred to as selecting a signal or band-limiting a signal to a frequency band), (ii) downconverting the selected signal, (iii) band-limiting again to a narrower frequency band to select a signal frequency band that may be referred to as a channel in certain embodiments, (iv) demodulating the downconverted and band-limited signal, (v) performing error correction, and (vi) demultiplexing to select a desired data packet stream. The RF portion of various embodiments includes one or more elements for performing these functions, e.g., frequency selectors, signal selectors, band-limiters, channel selectors, filters, downconverters, demodulators, error correctors, and demultiplexers. The RF section may include a tuner that performs various such functions, for example, including down-converting the received signal to a lower frequency (e.g., intermediate frequency or near-baseband frequency) or to the baseband. In one set-top box embodiment, the RF section and its associated input processing element perform frequency selection by receiving, filtering, down-converting, and filtering the RF signal transmitted over a wired (e.g., cable) medium to a desired frequency band. Various embodiments rearrange the order of the elements described above (and others), remove some of these elements, and / or add other elements that perform similar or different functions. Adding elements may include inserting elements between existing elements, such as inserting amplifiers and analog-to-digital converters.In various embodiments, the RF portion includes an antenna.

[0201] Additionally, USB and / or HDMI terminals may include their own interface processors for connecting the system (1000) to other electronic devices via the USB and / or HDMI connections. It should be understood that various modes of input processing, such as Reed-Solomon error correction, may be implemented as needed, for example, within a separate input processing IC or within the processor (1010). Similarly, modes of USB or HDMI interface processing may be implemented as needed within separate interface ICs or within the processor (1010). The demodulated, error-corrected, and demultiplexed stream is provided to various processing elements, including a processor (1010) and an encoder / decoder (1030) that operate in combination with memory and storage elements to process the data stream as needed for presentation on an output device, for example.

[0202] Various elements of the system (1000) may be provided within an integrated housing. Within the integrated housing, the various elements may be interconnected using an internal bus as known in the art, such as a suitable connection arrangement (1140), including, for example, an I2C (Inter-IC) bus, wiring, and printed circuit boards, and may transmit data between them.

[0203] The system (1000) includes a communication interface (1050) that enables communication with other devices through a communication channel (1060). The communication interface (1050) may include, but is not limited to, a transceiver configured to transmit and receive data through the communication channel (1060). The communication interface (1050) may include, but is not limited to, a modem or a network card, and the communication channel (1060) may be implemented, for example, within a wired and / or wireless medium.

[0204] In various embodiments, data is streamed to or otherwise provided to the system (1000) using a wireless network, such as a Wi-Fi network, e.g., IEEE 802.11 (IEEE stands for Institute of Electrical and Electronics Engineers). Wi-Fi signals in these embodiments are received through a communication interface (1050) and a communication channel (1060) adapted for Wi-Fi communication. The communication channel (1060) in these embodiments is typically connected to an access point or router that provides access to external networks, including the Internet, to enable streaming applications and other over-the-top communication. Other embodiments provide streamed data to the system (1000) using a set-top box that transmits data via the HDMI connection of the input block (1130). Still other embodiments provide streamed data to the system (1000) using the RF connection of the input block (1130). As described above, various embodiments provide data in a non-streaming manner. Additionally, various embodiments use wireless networks other than Wi-Fi, for example, cellular networks or Bluetooth networks.

[0205] The system (1000) can provide output signals to various output devices, including a display (1100), speakers (1110), and other peripheral devices (1120). The display (1100) of various embodiments includes, for example, one or more of a touchscreen display, an OLED (organic light-emitting diode) display, a curved display, and / or a foldable display. The display (1100) may be for a television, tablet, laptop, cell phone (mobile phone), or other device. The display (1100) may also be integrated with other components (for example, as in a smartphone) or be separate (for example, as an external monitor for a laptop). The other peripheral devices (1120) include, in various examples of the embodiments, one or more of a standalone digital video disc (or digital versatile disc) (for both terms, a DVR), a disc player, a stereo system, and / or a lighting system. Various embodiments use one or more peripheral devices (1120) that provide functions based on the output of the system (1000). For example, a disc player performs the function of playing the output of the system (1000).

[0206] In various embodiments, control signals are communicated between the system (1000) and the display (1100), speakers (1110), or other peripheral devices (1120) using signaling such as AV.Link, CEC (Consumer Electronics Control), or other communication protocols that enable device-to-device control with or without user intervention. Output devices may be communicably coupled to the system (1000) through dedicated connections via their respective interfaces (1070, 1080, and 1090). Alternatively, output devices may be connected to the system (1000) using a communication channel (1060) via a communication interface (1050). The display (1100) and speakers (1110) may be integrated into a single unit with other components of the system (1000) within an electronic device, for example, a television. In various embodiments, the display interface (1070) includes a display driver, such as, for example, a timing controller (T Con) chip.

[0207] The display (1100) and speaker (1110) may alternatively be separate from one or more of the other components, for example, if the RF portion of the input (1130) is part of a separate set-top box. In various embodiments where the display (1100) and speakers (1110) are external components, the output signal may be provided through dedicated output connections, for example, including HDMI ports, USB ports, or COMP outputs.

[0208] The embodiments may be performed by computer software implemented by the processor (1010), by hardware, or by a combination of hardware and software. As a non-limiting example, the embodiments may be implemented by one or more integrated circuits. The memory (1020) may be any type suitable for the technical environment and, as a non-limiting example, may be implemented using any suitable data storage technology such as an optical memory device, a magnetic memory device, a semiconductor-based memory device, fixed memory, and removable memory. The processor (1010) may be any type suitable for the technical environment and, as a non-limiting example, may include one or more of microprocessors, general-purpose computers, special-purpose computers, and multi-core architecture-based processors.

[0209] Additional embodiments.

[0210] A mesh encoding method according to an exemplary embodiment comprises: encoding the connectivity of a triangle mesh in a bitstream using edgebreaker coding; signaling information in the bitstream indicating the direction of the connectivity encoding; and signaling a parameter in the bitstream indicating the number of triangles in the triangle mesh in response to a determination that the information indicates reverse edgebreaker coding.

[0211] In some embodiments, the method further includes the step of signaling a parameter indicating the number of encoded CLERS symbols separately from a parameter indicating the number of triangles in a triangle mesh.

[0212] In some embodiments, the method further includes the step of signaling a parameter in a bitstream representing the number of starting positions in a mesh in response to a determination that the information represents reverse edgebreaker coding.

[0213] Some embodiments further include the step of signaling a parameter in a bitstream representing the number of connected components having boundaries within a triangle mesh in response to a determination that the information represents reverse edgebreaker coding.

[0214] A mesh decoding method according to some embodiments comprises: acquiring a bitstream representing the connectivity of a triangle mesh encoded using edgebreaker coding; reading information from the bitstream representing the direction of the connectivity encoding; reading a parameter from the bitstream representing the number of triangles in the triangle mesh in response to a determination that the information represents reverse edgebreaker coding; and reconstructing the connectivity of the triangle mesh from the bitstream using the parameter representing the number of triangles in the triangle mesh.

[0215] Some embodiments further include the step of reading from a bitstream a parameter representing the number of encoded CLERS symbols, which may be separate from a parameter representing the number of triangles in a triangle mesh.

[0216] Some embodiments further include the step of reading a parameter from a bitstream representing the number of starting positions in a mesh in response to a determination that the information represents reverse edgebreaker coding.

[0217] Some embodiments further include the step of reading from a bitstream a parameter representing the number of connected components having boundaries within a triangle mesh in response to a determination that the information represents reverse edgebreaker coding.

[0218] An apparatus according to some embodiments comprises one or more processors, and the apparatus is configured to perform any one of the methods described herein.

[0219] An apparatus according to some embodiments includes at least one processor and a computer-readable medium storing instructions for performing any one of the methods described herein.

[0220] A computer-readable medium according to some embodiments stores instructions for performing any one of the methods described herein.

[0221] A computer-readable medium according to some embodiments stores a mesh encoded according to any one of the methods described herein.

[0222] A signal according to some embodiments conveys a mesh encoded according to any one of the methods described herein.

[0223] The present disclosure describes various aspects, including tools, features, embodiments, models, approaches, etc. Many of these aspects are described specifically and, at least to show individual characteristics, are described in a manner that may often sound restrictive. However, this is for the sake of clarity of description and does not limit the scope of the present disclosure and its aspects. In practice, all different aspects may be combined and interchanged to provide additional aspects. Furthermore, aspects may also be combined and interchanged with aspects described in prior applications.

[0224] The embodiments described and considered in this disclosure may be implemented in many different forms. While some embodiments are specifically illustrated, other embodiments are also considered, and the discussion of specific embodiments does not limit the scope of implementations. At least one of the embodiments generally relates to mesh encoding and decoding, and at least one other embodiment generally relates to transmitting a bitstream that is generated or encoded. These and other embodiments may be implemented as a method, an apparatus, a computer-readable storage medium storing instructions for encoding or decoding mesh data according to any one of the described methods, and / or a computer-readable storage medium storing a bitstream generated according to any one of the described methods.

[0225] Various methods are described herein, and each of the methods comprises one or more steps or actions to achieve the described method. Unless a specific order of steps or actions is required for the proper operation of the method, the order and / or use of specific steps and / or actions may be modified or combined. Additionally, terms such as “first,” “second,” etc., may be used in various embodiments to modify elements, components, steps, actions, etc., such as “first decoding” and “second decoding.” The use of these terms does not imply an order of the modified actions unless specifically required. Thus, in this example, the first decoding does not need to be performed prior to the second decoding, and may occur, for example, prior to the second decoding, during the second decoding, or within a time period overlapping with the second decoding.

[0226] For example, various numerical values ​​may be used in this disclosure. Specific values ​​are for illustrative purposes only, and the described embodiments are not limited to these specific values.

[0227] The embodiments described herein may be performed by computer software implemented by a processor or other hardware, or by a combination of hardware and software. By non-limiting example, the embodiments may be implemented by one or more integrated circuits. The processor may be any type suitable for the technical environment and, by non-limiting example, may include one or more of a microprocessor, a general-purpose computer, a special-purpose computer, and a processor based on a multi-core architecture.

[0228] When a drawing is presented as a flowchart, it should be understood that the drawing also provides a block diagram of the corresponding device. Similarly, when a drawing is presented as a block diagram, it should be understood that the drawing also provides a flowchart of the corresponding method / process.

[0229] The implementations and aspects described herein may be implemented, for example, as methods or processes, devices, software programs, data streams, or signals. Even if discussed only in the context of a single form of implementation (e.g., discussed only as a method), implementations of the features discussed may also be implemented in other forms (e.g., devices or programs). Devices may be implemented, for example, in appropriate hardware, software, and firmware. Methods may be implemented, for example, in processors, referring to general processing devices, including, for example, computers, microprocessors, integrated circuits, or programmable logic devices. Processors also include communication devices, such as, for example, computers, cell phones, portable / personal handheld terminals (“PDAs”), and other devices that facilitate the communication of information between end users.

[0230] References to "one embodiment," "an embodiment," "one implementation," or "an implementation," as well as other variations thereof, mean that the specific features, structures, characteristics, etc. described in relation to the embodiment are included in at least one embodiment. Accordingly, appearances of phrases such as "in one embodiment," "in an embodiment," "in one implementation," or "in an implementation," as well as any other variations, appearing in various places throughout this disclosure, do not all necessarily refer to the same embodiment.

[0231] Additionally, the present disclosure may refer to "determining" various information. Determining information may include, for example, estimating information, calculating information, predicting information, or retrieving information from memory.

[0232] Furthermore, the present disclosure may refer to "accessing" various information. Accessing information may include, for example, receiving information, retrieving information (for example, from memory), storing information, moving information, copying information, calculating information, determining information, predicting information, or estimating information.

[0233] Additionally, the present disclosure may refer to "receiving" various types of information. Receiving is intended as a broad term, as in "accessing." Receiving information may include, for example, accessing information or retrieving information (for example, from memory). Furthermore, "receiving" may typically be involved in some way during operations such as, for example, storing information, processing information, transmitting information, moving information, copying information, erasing information, calculating information, determining information, predicting information, or estimating information.

[0234] For example, in the cases of "A / B", "A and / or B", and "at least one of A and B", it should be understood that the use of any of " / ", "and / or", and "at least one of" is intended to encompass the selection of only the first enumerated option (A), the selection of only the second enumerated option (B), or the selection of both options (A and B). As an additional example, in the cases of "A, B, and / or C" and "at least one of A, B, and C", these phrases are intended to encompass the selection of only the first enumerated option (A), the selection of only the second enumerated option (B), the selection of only the third enumerated option (C), the selection of only the first and second enumerated options (A and B), the selection of only the first and third enumerated options (A and C), the selection of only the second and third enumerated options (B and C), or the selection of all three options (A, B, and C). This can be expanded as many times as the number of listed items.

[0235] Additionally, as used herein, the word “signal” refers, among other things, to inform a corresponding decoder of something. For example, in certain embodiments, the encoder signals a specific parameter among a plurality of parameters for region-based filter parameter selection for de-artifact filtering. In this way, in one embodiment, the same parameter is used on both the encoder side and the decoder side. Thus, for example, the encoder may transmit the specific parameter to the decoder so that the decoder can use the same specific parameter (explicit signaling). Conversely, if the decoder already possesses the specific parameter as well as other parameters, signaling may be used without transmission simply to enable the decoder to know and select the specific parameter (implicit signaling). Bit savings are realized in various embodiments by avoiding the transmission of any actual functions. It should be understood that signaling can be achieved in various ways. For example, in various embodiments, one or more syntax elements, flags, etc. are used to signal information to a corresponding decoder. Although the foregoing relates to the verb form of the word "signaling," the word "signal" may also be used as a noun in this specification.

[0236] Implementations may generate various signals formatted to convey information that may be stored or transmitted, for example. The information may include, for example, instructions for performing a method, or data generated by one of the described implementations. For example, the signal may be formatted to convey a bitstream of the described embodiment. Such a signal may be formatted, for example, as an electromagnetic wave (e.g., using a radio frequency portion of the spectrum) or as a baseband signal. Formatting may include, for example, encoding a data stream and modulating a carrier using the encoded data stream. The information conveyed by the signal may be, for example, analog or digital information. The signal may be transmitted via various different wired or wireless links, as is known. The signal may be stored on a processor-readable medium.

[0237] A number of embodiments have been described. Features of these embodiments may be provided alone or in any combination across various claim categories and types. Furthermore, the embodiments may include one or more of the following features, devices, or aspects, alone or in any combination across various claim categories and types:

[0238] A bitstream or signal containing one or more of the described syntax elements or their variations.

[0239] A bitstream or signal comprising a syntax that conveys information generated according to any one of the described embodiments.

[0240] Generating and / or transmitting and / or receiving and / or decoding a bitstream or signal containing one or more of the described syntax elements or variations thereof.

[0241] Generating and / or transmitting and / or receiving and / or decoding according to any one of the described embodiments.

[0242] A method, process, device, medium storing instructions, medium storing data, or signal according to any one of the described embodiments.

[0243] Various hardware elements of one or more of the described embodiments are referred to as “modules” that carry out (i.e., perform, execute, etc.) the various functions described herein in relation to their respective modules. As used herein, a module includes hardware considered suitable for a given implementation (e.g., one or more processors, one or more microprocessors, one or more microcontrollers, one or more microchips, one or more application-specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), one or more memory devices). It should be noted that each described module may also include executable instructions to perform one or more functions described as being performed by the respective module, and that such instructions may take or include the form of hardware (i.e., hardwired) instructions, firmware instructions, software instructions, etc., and may be stored in any suitable non-transient computer-readable medium or medium, such as commonly referred to as RAM, ROM, etc.

[0244] Although features and elements are described above in specific combinations, each feature or element may be used alone or in any combination with other features and elements. Additionally, the methods described herein may be implemented as computer programs, software, or firmware contained in a computer-readable medium for execution by a computer or processor. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer in conjunction with software.< / float>

Claims

Claim 1 A mesh encoding method comprising: encoding the connectivity of a triangle mesh in a bitstream using edgebreaker coding; signaling information indicating the direction of the connectivity encoding in the bitstream; and signaling a parameter indicating the number of triangles in the triangle mesh in the bitstream. Claim 2 A mesh encoding device comprising one or more processors, wherein the one or more processors are configured to perform at least: a step of encoding the connectivity of a triangle mesh in a bitstream using edgebreaker coding; a step of signaling information indicating the direction of the connectivity encoding in the bitstream; and a step of signaling a parameter indicating the number of triangles in the triangle mesh in the bitstream. Claim 3 A method or apparatus of claim 1 or claim 2, further comprising the step of signaling a parameter representing the number of encoded CLERS symbols separately from a parameter representing the number of triangles in the triangle mesh. Claim 4 A method or apparatus according to claim 1 or claim 3 dependent on claim 1, or an apparatus according to claim 2 or claim 3 dependent on claim 2, further comprising the step of signaling a parameter in the bitstream indicating the number of starting positions within the mesh. Claim 5 A method or apparatus according to claim 1 or claims 3 and 4 dependent on claim 1, or an apparatus according to claim 2 or claims 3 and 4 dependent on claim 2, further comprising the step of signaling in the bitstream a parameter representing the number of connection components having boundaries within the triangle mesh. Claim 6 A method or apparatus according to claim 1 or claims 3 through 5 dependent on claim 1, or an apparatus according to claim 2 or claims 3 through 5 dependent on claim 2, wherein information indicating the number of virtual vertices is not signaled in the bitstream. Claim 7 A method or apparatus of claim 1 or claims 3 through 6 dependent on claim 1, or of claim 2 or apparatus of claims 3 through 6 dependent on claim 2, wherein information identifying indices of virtual vertices is not signaled in the bitstream. Claim 8 A mesh decoding method comprising: acquiring a bitstream representing the connectivity of a triangle mesh encoded using edgebreaker coding; reading information representing the direction of the connectivity encoding from the bitstream; reading a parameter representing the number of triangles in the triangle mesh from the bitstream; and reconstructing the connectivity of the triangle mesh from the bitstream using the parameter representing the number of triangles in the triangle mesh. Claim 9 A mesh decoding device comprising one or more processors, wherein the one or more processors are configured to perform at least: a step of acquiring a bitstream representing the connectivity of a triangle mesh encoded using edgebreaker coding; a step of reading information representing the direction of the connectivity encoding from the bitstream; a step of reading a parameter representing the number of triangles in the triangle mesh from the bitstream; and a step of reconstructing the connectivity of the triangle mesh from the bitstream using the parameter representing the number of triangles in the triangle mesh. Claim 10 A method or apparatus of claim 8 or of claim 9, further comprising the step of reading a parameter representing the number of encoded CLERS symbols from the bitstream. Claim 11 A method or apparatus according to claim 8 or claim 10 dependent on claim 8, or an apparatus according to claim 9 or claim 10 dependent on claim 9, further comprising the step of reading a parameter representing the number of starting positions within the mesh from the bitstream. Claim 12 A method or apparatus according to claim 8 or the method of claims 10 and 11 dependent on claim 8, or the apparatus according to claim 9 or the apparatus of claims 10 and 11 dependent on claim 9, further comprising the step of reading from the bitstream a parameter representing the number of connection components having boundaries within the triangle mesh. Claim 13 A method of claim 8 or of claims 10 through 12 dependent on claim 8, or an apparatus of claim 9 or of claims 10 through 12 dependent on claim 9, wherein information indicating the number of virtual vertices is not read from the bitstream. Claim 14 A method of claim 8 or of claims 10 through 13 dependent on claim 8, or an apparatus of claim 9 or of claims 10 through 13 dependent on claim 9, wherein information identifying indices of virtual vertices is not read from the bitstream. Claim 15 A signal comprising: information encoding the connectivity of a triangle mesh in a bitstream using edgebreaker coding; information indicating the direction of the connectivity encoding; and a parameter indicating the number of triangles in the triangle mesh.

Images