Predictive coding of boundary UV2XYZ indices for mesh compression

Abstract

A method and apparatus comprising: receiving a coded video bitstream from an encoder; extracting from the coded video bitstream a mesh comprising a plurality of polygons describing one or more surfaces of a volumetric object; predicting a current value of an index of the UV-to-XYZ index array from at least one previously coded value contained in another index in a UV-to-XYZ index array, the UV-to-XYZ index array comprising a plurality of indices that correspond each two-dimensional (2D) UV vertex associated with the mesh to a three-dimensional (3D) XYZ vertex associated with the mesh; deriving a prediction residual associated with the current value of the index of the UV-to-XYZ index array; and reconstructing border UV coordinates based on the predicted current value of the index of the UV-to-XYZ index array and the derived prediction residual.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority from U.S. Provisional Patent Application No. 63 / 323,874, filed March 25, 2023, and U.S. Patent Application No. 18 / 185,076, filed March 16, 2022, the disclosures of which are incorporated by reference in their entireties herein.

[0002] Technical Field This disclosure is directed to a set of advanced video coding techniques. More specifically, this disclosure is directed to a method for coding UV-to-XYZ (UV2XYZ) indices of boundary vertices for efficient mesh compression. [Background technology]

[0003] Advances in 3D capture, modeling, and rendering have facilitated the ubiquitous presence of 3D content across several platforms and devices. Today, we can film a baby's first steps on one continent while grandparents watch (and possibly interact with) that child on another continent, enjoying a fully immersive experience. Nevertheless, to achieve such realism, models become increasingly sophisticated, and large amounts of data are linked to the creation and use of those models. 3D meshes are widely used to represent such immersive content.

[0004] Dynamic mesh sequences may consist of a significant amount of time-varying information and therefore may require a large amount of data. Therefore, efficient compression techniques are required to store and transmit such content. Mesh compression standards IC, MESHGRID, FAMC were previously developed by MPEG to address dynamic meshes with constant connectivity and time-varying geometry and vertex attributes. However, these standards do not consider time-varying attribute maps and connectivity information. Digital Content Creation (DCC) tools usually generate such dynamic meshes. In contrast, generating dynamic meshes with constant connectivity, especially under real-time constraints, is challenging for volumetric acquisition techniques. This type of content is not supported by existing standards. MPEG plans to develop a new mesh compression standard to directly handle dynamic meshes with time-varying connectivity information and optionally time-varying attribute maps. The standard targets lossy and lossless compression for various applications such as real-time communication, storage, free viewpoint video, AR and VR. Features such as random access and scalable / progressive coding are also considered. Summary of the Invention

[0005] The following presents a simplified summary of one or more embodiments of the present disclosure in order to provide a basic understanding of such embodiments. This summary is not an extensive overview of all discussed embodiments, and is not intended to identify key or critical elements of all embodiments or to delineate the scope of any or all embodiments. Its sole purpose is to present some concepts of one or more embodiments of the present disclosure in a simplified form as a prelude to the more detailed description that is presented later.

[0006] This disclosure provides a method for UV2XYZ indexing of boundary vertices for efficient mesh compression.

[0007] According to some embodiments, a method is provided that is executed by at least one processor. The method includes receiving a coded video bitstream from an encoder. The method further includes extracting a mesh from the coded video bitstream, the mesh comprising a plurality of polygons that describe one or more surfaces of a volumetric object. The method further includes predicting a current value of an index of the UV-to-XYZ index array from at least one previously coded value included in another index in the UV-to-XYZ index array, the UV-to-XYZ index array including a plurality of indexes that correspond each two-dimensional (2D) UV vertex associated with the mesh to a three-dimensional (3D) XYZ vertex associated with the mesh. The method further includes deriving a prediction residual associated with the current value of the index of the UV-to-XYZ index array. The method further includes reconstructing a border UV coordinate based on the predicted current value of the index of the UV-to-XYZ index array and the derived prediction residual.

[0008] According to some implementations, an apparatus comprises at least one memory configured to store program code and at least one processor configured to read the program code and operate as instructed by the program code. The program code includes a receiving code configured to cause the at least one processor to receive a coded video bitstream from an encoder. The program code further includes a retrieval code configured to cause the at least one processor to retrieve a mesh comprising a plurality of polygons describing one or more surfaces of a volumetric object from the coded video bitstream. The program code further includes a prediction code configured to cause the at least one processor to predict a current value of an index of the UV-to-XYZ index array from at least one previously coded value included in another index in the UV-to-XYZ index array, the UV-to-XYZ index array including a plurality of indices that correspond each two-dimensional (2D) UV vertex associated with the mesh to a three-dimensional (3D) XYZ vertex associated with the mesh. The program code further includes a derivation code configured to cause the at least one processor to derive a prediction residual associated with the current value of the index of the UV-to-XYZ index array. The program code further includes reconstruction code configured to cause the at least one processor to reconstruct border UV coordinates based on a predicted current value of an index of a UV-to-XYZ index array and the derived prediction residual.

[0009] According to some embodiments, a non-transitory computer-readable storage medium stores instructions that, when executed by at least one processor, cause the at least one processor to receive a coded video bitstream from an encoder. The instructions cause the at least one processor to retrieve a mesh from the coded video bitstream, the mesh comprising a plurality of polygons that describe one or more surfaces of a volumetric object. The instructions further cause the at least one processor to predict a current value of an index of the UV-to-XYZ index array from at least one previously coded value included in another index in the UV-to-XYZ index array, the UV-to-XYZ index array including a plurality of indexes that correspond each two-dimensional (2D) UV vertex associated with the mesh to a three-dimensional (3D) XYZ vertex associated with the mesh. The instructions further cause the at least one processor to derive a prediction residual associated with the current value of the index of the UV-to-XYZ index array. The instructions further cause the at least one processor to reconstruct a border UV coordinate based on the predicted current value of the index of the UV-to-XYZ index array and the derived prediction residual.

[0010] Additional embodiments will be set forth in the description that follows, and in part will be obvious from the description, and / or may be learned by practice of the presented embodiments of the present disclosure. [Brief description of the drawings]

[0011] Further features, nature and various advantages of the disclosed subject matter will become more apparent from the following detailed description and the accompanying drawings. [Figure 1] FIG. 1 is a schematic diagram illustrating a simplified block diagram of a communication system, according to some embodiments. [Diagram 2] FIG. 2 is a schematic diagram illustrating a simplified block diagram of a streaming system, according to some embodiments. [Diagram 3]FIG. 3 is a schematic diagram illustrating a simplified block diagram of a video encoder and decoder according to some embodiments. [Figure 4] FIG. 4 is a diagram illustrating the process of UV parameterization mapping from a 3D mesh segment to a 2D chart according to some embodiments. [Diagram 5] FIG. 5 is an illustration of different UV parameterizations where a 3D mesh segment is mapped to multiple separate charts, according to some embodiments. [Figure 6] FIG. 6 is a diagram illustrating a generic 2D UV atlas with multiple charts according to some embodiments. [Figure 7] FIG. 7 is a diagram illustrating bound vertices in a 2D chart according to some embodiments. [Figure 8] FIG. 8 is an operational flowchart illustrating steps performed by a program for coding UV2XYZ indices of boundary vertices for efficient mesh compression, according to some embodiments. [Figure 9] FIG. 9 is a diagram of a computer system suitable for implementing embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] The following detailed description of the exemplary embodiments refers to the accompanying drawings, in which the same reference numbers in different drawings may identify the same or similar elements.

[0013] A mesh may include a number of polygons that describe the surface of a volumetric object. Its vertices in 3D space and information on how the vertices are connected may define each polygon, referred to as connectivity information. Optionally, vertex attributes such as color, normal, etc. may be associated with the mesh vertices. Attributes may also be associated with the surface of the mesh by utilizing mapping information that parameterizes the mesh with a 2D attribute map. Such mapping may be defined using a set of parameter coordinates, referred to as UV coordinates or texture coordinates, associated with the mesh vertices. The 2D attribute map may be used to store high-resolution attribute information such as texture, normal, displacement, etc. The high-resolution attribute information may be used for various purposes such as texture mapping and shading.

[0014] As mentioned above, a 3D mesh or a dynamic mesh may require a large amount of data since it may consist of a large amount of information that changes over time. In particular, the boundary information is an important part of the entire mesh. Therefore, an efficient compression technique is needed to efficiently compress the boundary information.

[0015] In this disclosure, several methods are proposed for coding of boundary UV-to-XYZ index arrays in mesh compression. They can be applied individually or in any form of combination. The methods can be applied to static meshes, where only one frame of the mesh exists or where the mesh content does not change over time.

[0016] The proposed methods can be used separately or in combination in any order. Furthermore, each of the methods (or embodiments), the encoder, and the decoder can be implemented by a processing circuit (e.g., one or more processors, or one or more integrated circuits). In one embodiment, the one or more processors execute a program stored on a non-transitory computer-readable storage medium.

[0017] Let the total number of boundary vertices be N, and the number of boundary vertices with unique x,y,z coordinates be M, where M≦N. UV2XYZ is a 1D array of length N, where each element in the array indicates an index to a unique x,y,z coordinate, e.g., UV2XYZ[i]∈{0,1,…,M-1} for i=0,1,…,N-1.

[0018] The UV2XYZ may be separated into segments, with each segment containing the UV2XYZ index of a chart.

[0019] There are several ways to losslessly code a UV2XYZ array.

[0020] 1-2, an embodiment of the present disclosure for implementing the encoding and decoding structures of the present disclosure will be described.

[0021] FIG. 1 shows a simplified block diagram of a communication system 100 according to one embodiment of the present disclosure. The system 100 may include at least two terminals 110, 120 interconnected via a network 150. For unidirectional transmission of data, the first terminal 110 may code video data including a mesh at a local location for transmission to the other terminal 120 via the network 150. The second terminal 120 may receive the coded video data of the other terminal from the network 150, decode the coded data, and display the restored video data. Unidirectional data transmission may be common in media provision applications and the like.

[0022] 1 illustrates a second pair of terminals 130, 140 provided to support bidirectional transmission of coded video that may occur, for example, during a video conference. For the bidirectional transmission of data, each terminal 130, 140 may code video data captured at a local location for transmission to the other terminal over network 150. Each terminal 130, 140 may also receive coded video data transmitted by the other terminal, may decode the coded video data, and may display the recovered video data on a local display device.

[0023] In FIG. 1, the terminals 110-140 may be servers, personal computers, and smartphones, and / or any other type of terminal. For example, the terminals 110-140 may be laptop computers, tablet computers, media players, and / or dedicated videoconferencing devices. The network 150 represents any number of networks that convey coded video data between the terminals 110-140, including, for example, wired and / or wireless communication networks. The communication network 105 may exchange data over circuit-switched and / or packet-switched channels. Representative networks include telecommunications networks, local area networks, wide area networks, and / or the Internet. For purposes of this description, unless described below, the architecture and topology of the network 150 may not be important to the operation of the present invention.

[0024] 2 illustrates the arrangement of a video encoder and decoder in a streaming environment as an example of an application of the disclosed subject matter. The disclosed subject matter may be used with other video-enabled applications including, for example, video conferencing, digital TV, and storage of compressed video on digital media including CDs, DVDs, memory sticks, etc.

[0025] 2, the streaming system 200 may include a capture subsystem (213) that includes a video source 201 and an encoder 203. The streaming system 200 may further include at least one streaming server 205 and / or at least one streaming client 206.

[0026] The video source 201 may create a stream 202 including, for example, a 3D mesh and metadata associated with the 3D mesh. The video source 201 may include, for example, a 3D sensor (e.g., a depth sensor) or 3D imaging technology (e.g., digital camera(s)) and a computing device configured to generate a 3D mesh using data received from the 3D sensor or 3D imaging technology. The sample stream 202, which may have a high amount of data compared to an encoded video bitstream, may be processed by an encoder 203 coupled to the video source 201. The encoder 203 may include hardware, software, or a combination thereof to enable or implement aspects of the disclosed subject matter, as described in more detail below. The encoder 203 may also generate an encoded video bitstream 204. The encoded video bitstream 204, which may have a lower amount of data compared to the uncompressed stream 202, may be stored on a streaming server 205 for future use. One or more streaming clients 206 can access the streaming server 205 to retrieve a video bitstream 209, which may be a copy of the encoded video bitstream 204.

[0027] The streaming client 206 may include a video decoder 210 and a display 212. The video decoder 210 may, for example, decode a video bitstream 209, which is an input copy of the encoded video bitstream 204, and create an output video sample stream 211 that can be rendered on a display 212 or other rendering device (not shown). In some streaming systems, the video bitstreams 204, 209 may be encoded according to a particular video coding / compression standard.

[0028] FIG. 3 is an exemplary diagram of a framework 300 for dynamic mesh compression and mesh reconstruction using an encoder and a decoder. Each frame of an input mesh may be pre-processed by a series of operations, e.g., tracking, remeshing, parameterization, voxelization. These operations may be encoder only, and they may not be part of the decoding process. Then, a mesh with a 2D UV atlas may be obtained, and each vertex of the mesh has one or more associated UV coordinates on the 2D atlas. Then, the mesh may be converted into multiple maps, including an occupancy map, a geometry map, and an attribute map, by sampling on the 2D atlas. These 2D maps may then be coded by any video / image codec, such as HEVC, VVC, AV1, AVS3, etc. At the decoder side, the mesh may be reconstructed from the decoded 2D maps. Any post-processing and filtering may also be applied to the reconstructed mesh. Other metadata may be signaled to the decoder side for the purpose of 3D mesh reconstruction. The occupancy map may be inferred from the decoder side if the bounding vertices of each chart are signaled.

[0029] 3, framework 300 may include an encoder 301 and a decoder 351. Encoder 301 may include one or more input meshes 305, one or more meshes with UV atlas 310, occupancy map 315, geometry map 320, attribute map 325, and metadata 330. Decoder 351 may include a decoded occupancy map 335, a decoded geometry map 340, a decoded attribute map 345, decoded metadata 350, and a reconstructed mesh 360.

[0030] According to one aspect of the disclosure, the input mesh 305 may include one or more frames, each of which may be pre-processed by a series of operations and used to generate a mesh having a UV atlas 310. By way of example, the pre-processing operations may include, but are not limited to, tracking, parameterization, remeshing, voxelization, etc. In some embodiments, the pre-processing operations may be performed only on the encoder side and not on the decoder side.

[0031] The mesh with UV atlas 310 may be a 2D mesh. The 2D mesh with UV atlas may be a mesh where each vertex of the mesh may be associated with a UV coordinate on the 2D atlas. The mesh with UV atlas 310 may be processed and converted into multiple maps based on sampling. As an example, the UV atlas 310 may be processed and converted into an occupancy map, a geometry map, and an attribute map based on sampling of the 2D mesh with UV atlas. The generated occupancy map 335, geometry map 340, and attribute map 345 may be encoded using an appropriate codec (e.g., HVEC, VVC, AV1, etc.) and transmitted to the decoder. In some embodiments, metadata (e.g., connectivity information, etc.) may also be transmitted to the decoder.

[0032] According to one aspect, the decoder 351 may receive the encoded occupancy map, geometry map, and attribute map from the encoder. The decoder 351 may decode the occupancy map, geometry map, and attribute map using suitable techniques and methods in addition to the embodiments described herein. In one embodiment, the decoder 351 may generate a decoded occupancy map 335, a decoded geometry map 340, a decoded attribute map 345, and a decoded metadata 350. The input mesh 305 may be reconstructed into a reconstructed mesh 360 based on the decoded occupancy map 335, the decoded geometry map 340, the decoded attribute map 345, and the decoded metadata 350 using one or more reconstruction filters and techniques. In some embodiments, the metadata 330 may be sent directly to the decoder 351, and the decoder 351 may use the metadata to generate a reconstructed mesh 360 based on the decoded occupancy map 335, the decoded geometry map 340, and the decoded attribute map 345. Post-filtering techniques, including but not limited to remeshing, parameterization, tracking, voxelization, etc., may also be applied to the reconstructed mesh 360.

[0033] In some embodiments, a 3D mesh may be partitioned into several segments (or patches / charts). Each segment may include a set of connected vertices associated with their geometry, attributes, and connectivity information. As shown in FIG. 4, the UV parameterization process maps mesh segments onto 2D charts in a 2D UV atlas. Each vertex in a mesh segment is assigned a 2D UV coordinate in the 2D UV atlas. The vertices of the 2D charts form connected components as their 3D chart counterparts. The geometry, attributes, and connectivity information of each vertex may also be inherited from their 3D counterparts.

[0034] A 3D mesh segment may be mapped to multiple separate 2D charts. In this case, a vertex in 3D can correspond to multiple vertices in the 2D UV atlas. As shown in Figure 5, the same 3D mesh segment is mapped to two 2D charts in the 2D UV atlas instead of a single chart. The 3D vertices v1 and v4 each have two 2D correspondences.

[0035] A typical 2D UV atlas of a 3D mesh can consist of multiple charts such as those shown in Figure 6, where each chart may contain multiple (usually three or more) vertices associated with their 3D geometry, attributes, and connectivity information.

[0036] Boundary vertices are defined in 2D UV space. As shown in Figure 7, a filled vertex is a boundary vertex because it is on the boundary edge of a connected component (patch / chart). A boundary edge can be determined by checking if the edge appears only within one triangle. The following information of a boundary vertex is important and should be signaled in the bitstream: * Geometry information, i.e. 3D xyz coordinates. * 2D UV coordinates.

[0037] As shown in Figure 5, the mapping from 3D XYZ to 2D UV may be one-to-many if a bounding vertex in 3D corresponds to multiple vertices in the 2D UV atlas. Therefore, a UV-to-XYZ (or called UV2XYZ) index may be signaled to indicate the mapping function. UV2XYZ is a 1D array of indices that maps each 2Duv vertex to a 3D xyz vertex.

[0038] In some embodiments, the UV-to-XYZ index may be an index into a UV-to-XYZ index array, which may include multiple elements that indicate a mapping function from one or more 2D UV coordinates to one or more 3D YZ coordinates. For example, an element in the array may indicate an index into one or more unique XYZ coordinates that correspond to a particular UV coordinate.

[0039] In some embodiments, predictive coding is applied. The current value of UV2XYZ is predicted from previously coded values ​​in the UV2XYZ array. Let the current predicted value UV2XYZ[i] be UV2XYZ[i]. p It is expressed as [i].

[0040] In one embodiment, the current value of UV2XYZ[i] is predicted from previously coded values ​​in UV2XYZ, e.g., UV2XYZ[i] p [i]=UV2XYZ[i-1].

[0041] In another embodiment, if the current value of UV2XYZ[i] does not have a prediction, the predictor may be set as a constant value. For example, the first value of UV2XYZ in a chart may not have a good predictor, and therefore UV2XYZ[i] may be set as a constant value. p [0] can be set to 0.

[0042] In another embodiment, the current value of UV2XYZ[i] may have multiple predictors. In this case, a predictor candidate list may be established with an index signaled to indicate which predictor is to be used. In one example, the last two coded UV2XYZ values ​​may be used to form such a candidate list. A one-bit index is signaled to indicate which of the two predictors is used to predict the current value of UV2XYZ[i].

[0043] In another embodiment, the current value of UV2XYZ[i] may have multiple predictors, in which case some weighted average of these predictors may be used for prediction, for example the average of all predictors may be used.

[0044] The prediction residual between the original UV2XYZ and the predictor, i.e. UV2XYZ d [i]=UV2XYZ[i]-UV2XYZ p [i] can then be coded in a lossless manner by an entropy codec.

[0045] In one embodiment, the prediction residuals are coded by a fixed-length coding. The bit length can be coded in a high-level syntax table for all charts or coded differently for each chart.

[0046] In another embodiment, the prediction residuals are coded by unary coding.

[0047] In another embodiment, the prediction residuals are coded by Exponential-Golomb coding.

[0048] In other embodiments, the prediction residual may be coded by syntax elements as shown in Syntax Table 1 below. [Table 1]

[0049] In one or more examples, the variable prediction_residual_sign may specify a sign bit of the prediction residual. In one or more examples, the variable prediction_residual_abs_eq1 may specify whether the absolute value of the prediction residual is equal to 1. In one or more examples, the variable prediction_residual_abs_minus2 may specify the absolute value of the prediction residual minus 2.

[0050] According to one or more embodiments, at the decoder side, the UV2XYZ prediction residuals may be derived from the above syntax elements as follows:

number

[0051] Then the original UV2XYZ value is UV2XYZ[i]=UV2XYZ d [i]+UV2XYZ p It can be recovered by [i].

[0052] In another embodiment, the prediction residual may be coded by syntax elements as shown in Syntax Table 2 below. [Table 2]

[0053] In one or more examples, the variable prediction_residual_eq1 may specify whether the prediction residual is equal to 1. In one or more examples, the variable prediction_residual_eq_minus1 may specify whether the prediction residual is equal to -1. In one or more examples, the variable prediction_residual_sign may specify the sign bit of the prediction residual. In one or more examples, the variable prediction_residual_abs_minus2 may specify the absolute value of the prediction residual minus 2.

[0054] According to one or more embodiments, at the decoder side, the UV2XYZ prediction residuals may be derived from the above syntax elements as follows:

number

[0055] Then the original UV2XYZ is UV2XYZ[i]=UV2XYZ d [i]+UV2XYZ p It can be recovered by [i].

[0056] Due to the nature of vertex storage, when assigning the indices of adjacent vertices to the UV2XYZ array, adjacent UV2XYZ values ​​will generally have an index difference by 1. Often, over a range, they will show a monotonically increasing or decreasing trend. Therefore, the UV2XYZ array can be represented in the following form in a general way: (a,a+1,a+2,...,a+n a ,)(b,b-1,b-2,....,bn b )(c,c+1,c+2,....,c+n c ),... Here we can divide into several sub-sequences, each consisting of successive indices with steps of +1 or -1.

[0057] Thus, a UV2XYZ array can be represented and coded as a run-length oriented tuple: (a,n a ,1),(b,n b ,-1),(c,n c ,1),...

[0058] In one or more examples, a UV2XYZ array may be {100, 101, 102, 99, 98, 97, 96, 103, 104}. In the above format, this array can be equivalently written as (100, 2, 1), (99, 3, -1), (103, 1, 1).

[0059] According to one or more embodiments, a tuple of (RUN, LEN, DIR) may be defined as follows: The variable RUN may be the starting index in the run. The variable LEN may be the length of the run minus one. The variable DIR may be the direction of the run (e.g., 1 for increasing, -1 for decreasing). In one or more examples, the tuple may be coded differently. For example, the variable RUN may be coded with a fixed length, where the bit length is the number of unique xyz boundary vertices (e.g., [log2M]). In one or more examples, the variable LEN may be coded with a fixed length, where the bit length is determined by the number of uv boundary vertices currently in the chart (e.g., [log2N j ]), where N j j th is the number of uv-border vertices in the chart. In one or more examples, the variable DIR may be coded by 1-bit bypass coding. In another embodiment, DIR may be coded by arithmetic coding using a context.

[0060] Because UV2XYZ is a bounded loop, it happens that a run is split by the two ends of a linear array. For example, (a+2,a+3,a+4,a,a+1) should be a single tuple because the first and last elements are connected. However, the algorithm can think of it as having two runs: (a+2,2,1) and (a,1,1).

[0061] The encoder can then reorder the indices to ensure that UV2XYZ has no split runs, for example the above array can be reordered as (a, a+1, a+2, a+3, a+4), which can then be represented by a single tuple (a, 4, 1). Boundary UV and boundary XYZ should be reordered accordingly for this case.

[0062] 8 is a flowchart of an example process 800 for coding UV2XYZ indices of boundary vertices for efficient mesh compression. In some implementations, one or more process blocks of FIG. 8 may be performed by any of the elements described above.

[0063] As shown in FIG. 8, process 800 may include receiving a coded video bitstream at an encoder (block 810).

[0064] As further shown in FIG. 8, the process 800 may include extracting a dynamic mesh from the coded video bitstream (block 820).

[0065] As further shown in FIG. 8, the process 800 may include predicting the UV-to-XYZ index array from at least one previously coded value in the UV-to-XYZ index array (block 830).

[0066] As further shown in FIG. 8, the process 800 may include deriving a prediction residual associated with the UV-to-XYZ index array (block 840).

[0067] As further shown in FIG. 8, the process 800 may include reconstructing border UV coordinates based on the predicted UV-to-XYZ index array and the derived prediction residuals (Block 850).

[0068] Although Figure 8 illustrates example blocks of process 800, in some implementations, process 800 may include additional, fewer, different, or differently arranged blocks than those illustrated in Figure 8. Additionally or alternatively, two or more of the blocks of process 800 may be performed in parallel.

[0069] The techniques described above may be implemented as computer software using computer-readable instructions and physically stored on one or more computer-readable storage media. For example, FIG. 9 illustrates a computer system 900 suitable for implementing certain embodiments of the present disclosure.

[0070] The computer software may be coded using any suitable machine code or computer language that may be subjected to assembly, compilation, linking, or similar mechanisms to produce code containing instructions that may be executed by a computer central processing unit (CPU), graphics processing unit (GPU), etc., directly, or via interpretation, microcode execution, etc.

[0071] The instructions may be executed on various types of computers or components thereof, including, for example, personal computers, tablet computers, servers, smart phones, gaming devices, Internet of Things devices, etc.

[0072] 9 for computer system 900 are examples and are not intended to suggest any limitation as to the scope of use or functionality of the computer software implementing embodiments of the present disclosure, nor should the arrangement of components be interpreted as having any dependency or requirement regarding any one or combination of components illustrated in the non-limiting embodiment of computer system 900.

[0073] The computer system 900 may include certain human interface input devices. Such human interface input devices may be responsive to input by one or more human users, for example, via tactile input (e.g., keystrokes, swiping, data glove movements), audio input (e.g., voice, clapping), visual input (e.g., gestures), or olfactory input (not shown). Human interface devices may also be used to capture certain media not necessarily directly associated with conscious human input, such as audio (speech, music, ambient sounds, etc.), images (scanned images, photographic images obtained from a still image camera, etc.), and video (two-dimensional video, three-dimensional video including stereoscopic video, etc.).

[0074] The input human interface devices may include one or more of the following (only one of each is shown): keyboard 901, mouse 902, trackpad 903, touch screen 910, data glove, joystick 905, microphone 906, scanner 907, camera 908.

[0075] The computer system 900 may also include certain human interface output devices. Such human interface output devices may stimulate one or more of the human user's senses, for example, through haptic output, sound, light, and smell / taste. Such human interface output devices may include haptic output devices (e.g., haptic feedback via a touch screen 910, data gloves, or joystick 905, but may also be haptic feedback devices that do not function as input devices). For example, such devices may be audio output devices (e.g., speakers 909, headphones (not shown)), visual output devices (e.g., screens 910 including CRT screens, LCD screens, plasma screens, OLED screens, etc., with or without touch screen input capabilities, with or without haptic feedback capabilities, some of which may be capable of outputting two-dimensional visual output or three or more dimensional output, such as through means such as stereographic output: virtual reality glasses (not shown), holographic displays, and smoke tanks (not shown)), printers (not shown), etc.

[0076] The computer system 900 may also include human accessible storage devices and their accessible media, which may include, for example, optical media including CD / DVD ROM / RW 920 with CD / DVD or similar media 921, USB memory 922, removable hard drives or solid state drives 923, legacy magnetic media such as tape and floppy disks (not shown), dedicated ROM / ASIC / PLD based devices such as security dongles (not shown), and other related media.

[0077] Those skilled in the art will also understand that the term "computer-readable storage medium" as used in connection with the presently disclosed subject matter does not encompass transmission media, carrier waves, or other transitory signals.

[0078] The computer system 900 may also include interface devices to one or more communication networks. The networks may be, for example, wireless, wired, optical. The networks may further be local, wide area, metropolitan, vehicular and industrial, real-time, delay tolerant, etc. Examples of networks include Ethernet, wireless LAN, cellular networks including GSM, 3G, 4G, 5G, LTE, etc., cable TV, satellite TV, and terrestrial broadcast TV, industrial and vehicular including CANBus. Certain networks generally require an external network interface adapter that is attached to a particular general-purpose data port or peripheral bus 949 (e.g., a USB port of the computer system 900, etc.), while others are generally integrated into the core of the computer system 900 by attachment to the system bus, as described below (e.g., an Ethernet interface to a PC computer system or a cellular network interface to a smartphone computer system). Using any of these networks, the computer system 900 may communicate with other entities. Such communications may be one-way receive-only communications (e.g., broadcast television), one-way transmit-only communications (e.g., a CAN bus to a particular CAN bus device), or two-way communications, for example, to other computer systems using local or wide area digital networks. Such communications may include communications with cloud computing environments 955. Particular protocols and protocol stacks may be used in each of these networks and network interfaces, as described above.

[0079] The aforementioned human interface devices, human accessible storage devices, and network interface 954 can be connected to core 940 of computer system 900 .

[0080] The cores 940 may include one or more central processing units (CPUs) 941, graphics processing units (GPUs) 942, dedicated programmable processing devices in the form of field programmable gate areas (FPGAs) 943, hardware accelerators for particular tasks 944, etc. These devices may be connected via a system bus 948, along with read only memory (ROM) 945, random access memory 946, internal mass storage, e.g., an internal non-user accessible hard drive, SSD, etc. 947. In some computer systems, the system bus 948 is accessible in the form of one or more physical plugs to allow expansion with additional CPUs, GPUs, etc. Peripheral devices can be connected directly to the core's system bus 948 or via a peripheral bus 949. Peripheral bus architectures include PCI, USB, etc. A graphics adapter 950 can be included in the core 940.

[0081] The CPU 941, GPU 942, FPGA 943, and accelerator 944 may combine to execute certain instructions that may constitute the computer code described above. The computer code may be stored in ROM 945 or RAM 946. Transient data may also be stored in RAM 946, while permanent data may be stored in, for example, internal mass storage 947. A cache memory, which may be closely associated with one or more of the CPU 941, GPU 942, mass storage 947, ROM 945, RAM 946, etc., may be used to enable fast storage and retrieval in any of the memory devices.

[0082] The computer-readable storage media may have computer code thereon for performing various computer-implemented operations. The media and computer code may be those specially designed and constructed for the purposes of the present disclosure, or they may be of the kind well known and available to those having skill in the computer software arts.

[0083] By way of example and not limitation, a computer system having architecture 900, and specifically core 940, may provide functionality as a result of processor(s) (including CPU, GPU, FPGA, accelerator, etc.) executing software embodied in one or more tangible computer-readable storage media. Such computer-readable storage media may be user-accessible mass storage as introduced above, as well as media associated with specific storage of core 940 of a non-transitory nature, such as core internal mass storage 947 or ROM 945. Software implementing various embodiments of the present disclosure may be stored within such devices and executed by core 940. Computer-readable media may include one or more memory devices or chips, depending on specific needs. The software may cause core 940, and specifically processors therein (including CPU, GPU, FPGA, etc.) to perform certain processes or portions thereof described herein, including defining data structures stored in RAM 946 and modifying such data structures according to processes defined by the software. Additionally or alternatively, the computer system may provide functionality as a result of logic hardwired or otherwise embodied in circuitry (e.g., accelerator 944), which may operate in place of or in conjunction with software to perform particular processes or portions of particular processes described herein. Reference to software includes logic, and vice versa, where appropriate. Reference to a computer-readable medium may include circuitry (such as an integrated circuit (IC)) that stores software for execution, circuitry that embodies logic for execution, or both, as appropriate. The present disclosure encompasses any suitable combination of hardware and software.

[0084] While this disclosure has described several non-limiting embodiments, there are alterations, permutations, and various substitute equivalents that fall within the scope of this disclosure. Thus, it will be appreciated that those skilled in the art will be able to create numerous systems and methods that, although not explicitly shown or described herein, embody the principles of the invention and thus are within its concept and scope.

Claims

1. A method performed by at least one processor in a decoder, comprising: receiving a coded video bitstream from an encoder; extracting from the coded video bitstream a mesh comprising a plurality of polygons describing one or more surfaces of a volumetric object; predicting a current value of an index of a UV-to-XYZ index array from at least one previously coded value contained in another index in the UV-to-XYZ index array, the UV-to-XYZ index array including a plurality of indices that map each two-dimensional (2D) UV vertex associated with the mesh to a three-dimensional (3D) XYZ vertex associated with the mesh; deriving a prediction residual associated with the current value of the index of the UV-to-XYZ index array; and reconstructing boundary UV coordinates based on the predicted current value of the index of the UV-to-XYZ index array and the derived prediction residual. method.

2. The prediction residual is coded by fixed length coding. The method of claim 1.

3. The prediction residual is coded by Exponential-Golomb coding. The method of claim 1.

4. The prediction residual is coded by unary coding. The method of claim 1.

5. the prediction residual is coded by one or more syntax elements included in the coded video bitstream that specify a magnitude and a sign of the prediction residual. The method of claim 1.

6. The UV-to-XYZ index array is coded as a run-length oriented tuple. The method of claim 1.

7. the UV-to-XYZ index array is a bounded loop; The method of claim 1.

8. at least one memory configured to store program code; at least one processor configured to read the program code and to operate as instructed by the program code, The program code is configured to cause the at least one processor to execute a method according to any one of claims 1 to 7. Device.

9. A program comprising instructions which, when executed by at least one processor, cause the at least one processor to perform a method according to any one of claims 1 to 7. program.

Images