Methods, devices, and computer program for optimizing compressed representation of volumetric data

Abstract

A method for encoding volumetric data into a video-based dynamic mesh coding (V-DMC) compliant bitstream, the bitstream comprising attribute bitstreams, comprising: encoding, in the bitstream’s descri

Description

FIELD OF THE INVENTION The present disclosure relates to the technical field of compression of volumetric data, e.g. of visual volumetric data, such as defined through the V-DMC standard format. BACKGROUND OF THE INVENTION The Part-5 of the international standard for Coded representation of immersive media (MPEG-I), called “Visual volumetric video-based coding (V3C) and video-based point cloud compression (V-PCC)” specifies a generic mechanism for visual volumetric video coding, i.e. visual volumetric video-based coding. In short Part-5 defines V3C bitstreams. A V3C bitstream (visual volumetric video-based coding bitstream) is a sequence of bits that forms the representation of coded volumetric frames and associated data forming one or more Coded V3C Sequences (CVSs). The generic mechanism may be used by applications targeting volumetric content, such as point clouds, immersive video with depth, mesh representations of visual volumetric frames, etc. A first specific part, dedicated to point clouds, is also defined in MPEG-I Part-5 and is called V-PCC for Video-based Point Cloud Compression. A second part, Part-12, consists in volumetric media encoded as MPEG Immersive Video (MIV) that can also be described within the generic V3C bitstream structure. Another part (Part-29, under definition) of the international standard for Coded representation of immersive media (MPEG-I), called “Video-based dynamic mesh coding (V-DMC)” specifies syntax, semantics, and decoding for video based dynamic mesh coding (V-DMC) methods. Furthermore, this Part-29 specifies processes that may be needed for reconstruction of visual volumetric media and may also include additional processes such as post decoding, pre-reconstruction, post reconstruction, and adaptation. In short Part-29 defines V-DMC bitstreams. The syntax and semantics for the Part-29 are specified as an extension of Part-5. While a V3C bitstream was already mixing several kinds of bitstreams or subbitstreams separated by appropriate syntax elements, for example, mixing atlas bitstream with video bitstreams (for geometry, attributes and occupancy), a video bitstream being a bitstream conforming to a video specification, such as e.g. HEVC or VVC, V-DMC is adding additional types of bitstreams or sub-bitstreams mixed in a V-DMC bitstream, thus requiring modifications in the V3C bitstreams description and additional parameters (also denoted syntax elements) to expose for media players and decoders. The amount of V-DMC bitstreams description and parameters is thus increased compared to the legacy V3C bitstream. There is thus a need for reducing the amount of bitstreams description and parameters in V-DMC bitstreams. SUMMARY OF THE INVENTION The present disclosure has been devised to address one or more of the foregoing concerns. According to a first aspect of the disclosure, there is provided a method for encoding volumetric data into a V-DMC compliant bitstream, in a processing device, the bitstream comprising attribute bitstreams. Such method comprises: encoding, in the bitstreams description of the bitstream, a second flag, the second flag having a value indicative whether tiling is consistent or not across the different attribute bitstreams; and encoding, in the bitstreams description, a piece of information representative of at least one tiling structure used for the attribute bitstreams, the piece of information depending on the value of the second flag. Thus, the present disclosure proposes a new and inventive solution for reducing the amount of bitstreams description and parameters in V-DMC bitstreams. More particularly, the implementation of the second flag in the bitstreams description allows a decoder to know whether the same tiling applies to all the attribute video bitstreams or not. In case a same tiling applies, looping on all attributes is not necessary. Only one (i.e. a single) tiling information needs to be encoded in the bitstreams description and reused for all attributes, thus reducing the amount of information to be encoded in the bitstreams description. According to some embodiments, the method for encoding volumetric data comprises: checking if a consistent tiling applies onto attributes that are encoded as different attribute bitstreams; and if a consistent tiling does apply onto the different attribute bitstreams: the second flag is encoded with a value indicative that tiling is consistent across the different attribute bitstreams during said encoding the second flag; and the piece of information encoded during said encoding a piece of information is representative of the tiling structure used across the different attribute bitstreams. According to some embodiments, when the piece of information encoded during said encoding a piece of information is representative of the tiling structure used across the different attribute bitstreams, the piece of information comprises: a single attribute tile information common to the different attribute bitstreams; or a single configuration comprising at least partitions, tile positions and sizes common to the different attribute bitstreams. According to some embodiments, the method for encoding volumetric data comprises: checking if a consistent tiling applies onto attributes that are encoded as different attribute bitstreams; and if the consistent tiling does not apply onto different attribute bitstreams: the second flag is encoded with a value indicative that tiling is not consistent across the different attribute bitstreams during said encoding the second flag; and the piece of information encoded during said encoding a piece of information is representative of different attribute tile information for each attribute bitstreams. According to some embodiments, the method for encoding volumetric data comprises: checking if tiling applies to the compression of the volumetric data; and, if tiling does apply to the compression of the volumetric data: encoding in the bitstreams description a first flag, the first flag having a value indicative that tiling information is available for attribute bitstreams in the bitstreams description, executing said checking if a consistent tiling applies onto attributes that are encoded as different attribute bitstreams. According to some embodiments, the method for encoding volumetric data comprises: checking if tiling applies to the compression of the volumetric data; and, if tiling does not apply to the compression of the volumetric data: encoding in the bitstreams description the first flag, the first flag having a value indicative that no tiling information is available for attribute bitstreams in the bitstreams description, the checking if a consistent tiling applies onto attributes that are encoded as different attribute bitstreams being not executed. According to a second aspect of the disclosure, there is provided a method for decoding a V-DMC compliant bitstream into volumetric data in a processing device, the bitstream comprising attribute bitstreams. Such method comprises: determining a second flag from a bitstreams description of the bitstream, a value of the second flag being indicative whether tiling is consistent or not across the different attribute bitstreams; determining, depending on the second flag and from the bitstreams description, a piece of information representative of at least one tiling structure used for the attribute bitstreams. According to some embodiments, the value of the second flag is indicative that tiling is consistent across the different attribute bitstreams. The decoded piece of information is representative of the tiling structure used across the different attribute bitstreams. According to some embodiments, the piece of information comprises: a single attribute tile information common to the different attribute bitstreams; or a single configuration comprising at least partitions, tile positions and sizes common to the different attribute bitstreams. According to some embodiments, the method for decoding a V-DMC compliant bitstream comprises: checking if tiling applies to the compression of the volumetric data, wherein it is decided that tiling applies to the compression of the volumetric data if a value of a first flag present in the bitstreams description of the bitstream is indicative that there is tile information encoded in the bitstream or if the first flag is not present in the bitstreams description of the bitstream. The determining a second flag is executed if tiling does apply to the compression of the volumetric data. According to some embodiments, the method for decoding a V-DMC compliant bitstream comprises: checking if tiling applies to the compression of the volumetric data, wherein it is decided that tiling does not apply to the compression of the volumetric data if the value of the first flag present in the bitstreams description of the bitstream is indicative that there is not tile information encoded in the bitstreams description. The determining a second flag is not executed if tiling does not apply to the compression of the volumetric data. According to some embodiments, the bitstream further comprises a geometry bitstream, the attribute bitstreams having a tiling structure different from the geometry bitstream. According to some embodiments, the first flag is encoded in the V-DMC extension of the atlas frame parameter set of the bitstreams description. According to some embodiments, the second flag is encoded in the V-DMC extension of the Atlas frame parameter set or in the V-DMC atlas frame attribute tile information comprised in atlas frame parameter set of the bitstreams description. According to some embodiments, the second flag is encoded in a Volumetric Usability Information of the bitstreams description. According to some embodiments, the second flag is encoded in a syntax structure specifically dedicated to a V-DMC codec in the Volumetric Usability Information. According to some embodiments, the second flag is encoded in a syntax structure specifically dedicated to a V-DMC codec of an Atlas Sequence Parameter Set of the bitstreams description. According to some embodiments, the second flag is encoded in a codecspecific part of an Atlas Sequence Parameter Set of the bitstreams description. According to other aspects of the disclosure, there is provided a processing device comprising a processing unit configured for carrying out each step of the methods described above. The other aspects of the present disclosure have optional features and advantages similar to the first and second above-mentioned aspects. At least parts of the methods according to some embodiments of the disclosure may be computer implemented. Accordingly, some embodiments of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", a "module", or a "system". Furthermore, some embodiments of the present disclosure may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium. Since some embodiments of the present disclosure can be implemented in software, some embodiments of the present disclosure can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid state memory device, and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g., a microwave or RF signal. BRIEF DESCRIPTION OF THE DRAWINGS Other features and advantages of the disclosure will become apparent from the following description of non-limiting exemplary embodiments, with reference to the appended drawings, in which: Figure 1 schematically illustrates encoding and decoding of volumetric data, according to one embodiment of the disclosure; Figure 2 illustrates partition and tiles for an atlas frame according to known V3C specifications; Figure 3 illustrates the attribute tile information for V-DMC bitstreams according to known V-DMC specifications; Figure 4 illustrates syntax structures describing the attribute tile information for V-DMC bitstreams according to known V-DMC specifications; Figure 5a illustrates modified syntaxes for describing the attribute tile information for V-DMC bitstreams according to a first embodiment of the present disclosure; Figure 5b illustrates modified syntaxes for describing the attribute tile information for V-DMC bitstreams according to a second embodiment of the present disclosure; Figure 5c illustrates modified syntaxes for describing the attribute tile information for V-DMC bitstreams according to a variant of a first embodiment of the present disclosure. Figure 6 illustrates the steps of a method for encoding volumetric data into a V-DMC compliant compressed bitstream according to one embodiment of the present disclosure; Figure 6a illustrates a configuration of tile partitions for attributes that may be considered as consistent; Figure 6b illustrates another configuration of tile partitions for attributes that may be considered as consistent; Figure 6c illustrates another configuration of tile partitions for attributes that may be considered as consistent; Figure 7 illustrates the steps of a method for decoding a V-DMC compliant compressed bitstream into volumetric data according to one embodiment of the present disclosure; Figure 8 illustrates modified VUI syntaxes for describing the attribute tile information for V-DMC bitstreams according to an embodiment of the present disclosure; Figure 9 schematically illustrates a processing device configured to implement at least one embodiment of the present disclosure. DETAILED DESCRIPTION OF EMBODIMENTS OF THE DISCLOSURE Figure 1 illustrates an overview of encoding and decoding volumetric data (e.g. visual volumetric data, video based volumetric data, media content, etc.) according to some embodiments of the present disclosure. The data to be encoded (or compressed), referenced 105, can be 3D content, possibly mixed with 2D content for augmented (AR), extended (XR) or virtual reality (VR) applications. The data 105 to encode may come as a mesh representation, texture information and possibly other attributes describing properties of the volumetric data. The volumetric data may also be mixed with other data like audio, subtitles... However, in order to reduce the amount of bits that forms the coded representation of the data, the encoder module 110 generates encoded data 115 by execution of the encoding method described in reference to Figure 6 (according to any of the embodiments disclosed below in relation with Figure 6). This encoded (or compressed) content 115 is handled by an encoder that may be a meshbased encoder here 110, for example compliant with MPEG-I Part-29. The encoded data 115 may come as a bitstream 125, compliant for example with MPEG-I Part-29, forming a V-DMC bitstream. The V-DMC bitstream comprises coded data corresponding to one or more bitstreams or sub-bitstreams, bitstreams description and parameters. Bitstreams description and parameters are syntax elements present in the V-DMC bitstream or subbitstreams. An encapsulation step, performed by the encapsulation module 120, may follow the encoding step to produce a data file 125 from encoded data 115, for example according to MPEG-I Part-10 specification or another specification dedicated to the carriage of V-DMC bitstreams. The produced bitstream or data file 125 may be stored on recording device, in a production studio or may be exchanged over a network 130 for storage in the storage means 140 (e.g. in a cloud facility) or for delivery and consumption by clients connected to a service offering 3D or volumetric streaming. The delivery and consumption by clients may be live or on-demand, using popular streaming protocols like MPEG DASH or HTTP Live Streaming. One example can be the delivery of virtual world represented as mesh content for a user to be immersed in a virtual world. Another example of delivery or consumption may consist in 3D objects that are inserted in a real world, for example players on a field to create new views of specific actions during a match. An example of client is a media player on a PC, head-mounted display, tablet, TV or smartphone. Server or writer 100 processes data 105 may prepare data for streaming or for storage but the disclosure here focuses on the encoder module 110 to produce a compact and interoperable representation of data 105. The so-produced data file or bitstream 125 may be available as encoded (or compressed) data 125, possibly according to different encoded versions. The encoding may be live encoding or may encode the data once it has been produced and made available as raw capture data. Client or reader or player 150 is used for processing data received from communication network 130, or read from a (local or remote) storage device, for example for processing data file or bitstream 125. The data may be streamed to the client, thus involving a streaming module (not represented) in charge of parsing a streaming manifest, of determining requests to fetch the data streams, and of adapting the transmission, according to indication in the manifest and client parameters like for example available bandwidth, CPU, application needs, or user preference. The received data may be de-encapsulated in de-encapsulation module 160 (also known as a ISOBMFF parser, ISOBMFF reader, or simply parser or reader). The received data or the de-encapsulated data (or parsed data) may be decoded by a decoding module 170 for storage, display or for output to an application or to user(s). The decoder module 170 (possibly one or more per media type) may be part of the client, may be an external module. It may be implemented as a software program or may be a dedicated hardware. The de-encapsulated data output by de-encapsulation module 160 may correspond to encoded data 165 (e.g. V3C or V-DMC bitstream or sub-bitstream, video bitstream, audio bitstream, etc.) or may be a subpart of it. Indeed, it may be a subpart if the client interacts with the server to obtain only data relevant to a viewing direction or viewport. For example, the whole encoded data may correspond to a football or rugby field but at some time, the client may be interested to look at a particular aera on the field to follow a specific action. This is called spatial access into the encoded or compressed data. The decoder module 170 (or de-encapsulation module 160) offers this spatial access feature. This requires ability for the decoder to inspect the data file or bitstream 125 to determine which part of the data should be obtained and decoded. From encoding point of view this requires indications in the bitstream to allow such selection. This is the purpose of the tile-based organisation and syntax structures like parameter sets of the encoded or compressed data, for example as described in MPEG-I Part-5 or Part-29. For instance, MPEG-I parts 5 or 29 provide high-level description of the characteristics and the operations needed for the decoding of V3C or V-DMC bitstreams and optional post-decoding processes needed by applications, which may include nominal format conversion, pre-reconstruction, reconstruction, post-reconstruction, and adaptation. The high level description of the characteristics of V3C or V-DMC bitstreams and sub-bitstreams may be called, as a shortcut in this description, “high level syntax” or “bitstreams description”. Such high level description comprises syntax structures (e.g. parameter sets) containing syntax elements that characterize the V3C or V-DMC bitstream and sub-bitstreams. Back to Figure 1, the decoding method executed by the decoding module 170 is further described according to Figure 7 (according to any of the embodiments disclosed below in relation with Figure 7). Client or server may be user devices but may also be network nodes acting on the data files being transmitted or stored. Server or client may only contain, respectively, the encoding and decoding parts. It is noted that data file 125 may be communicated to client or reader 150 in different ways. In particular, server or writer (or packager) or encoder 100 may generate data file 125 with a description (e.g. a media description according to DASH MPD) and communicate (or stream) it directly to client 150 upon receiving a request from client 150. Data file 125 may also be downloaded, at once or progressively, by and stored in client 150. By execution of the encoding method described in reference to Figure 6 (according to any of the embodiments disclosed below in relation with Figure 6) and the execution of the decoding method described in reference to Figure 7 (according to any of the embodiments disclosed below in relation with Figure 7), the amount of bitstreams description and parameters is reduced in the bitstream 125 (The description of a bitstream may also be called “High-Level Syntax” or HLS as a shortcut). More particularly, a syntax structure for tile information already exists in V3C to describe atlas tiles. This syntax structure, named atlas_tile_information, contains different syntax elements, mainly for description of atlas tile partitions, mapping of atlas tiles onto these atlas tile partitions and optionally atlas tile identifiers, as illustrated on Figure 2. More particularly, in Figure 2, an atlas frame 200 is partitioned into tile partitions. The atlas tile 201 (Tile 0, illustrated by the hatched area) covers 4 atlas tile partitions TP1, TP2, TP3 and TP4 (211, 212, 213, 214). The coded data for an atlas frame are provided on a tile basis in V3C and this approach remains the one chosen for V-DMC (at least in Working Draft 5, dated Nov. 2023). In V3C, an atlas consists of multiple elements, named as patches. Each patch identifies a region in all available 2D components and contains information necessary to perform the appropriate inverse projection of this region back to the 3D space. In V-DMC, the atlas component is also composed of patches and provides information to a V3C decoding and / or rendering system on how to perform inverse reconstruction. For example, how to perform the subdivision of base mesh and how to apply the displacement vectors to the subdivided mesh vertices and how to apply attributes to the reconstructed mesh. However, among the bitstreams description and parameters of a V-DMC bitstream or sub-bitstream, the tile for the geometry component may not need to be the same as the tile for the attribute component, therefore requiring additional signalling for these attribute tiles compared to V3C. To signal the tile information for attribute video bitstreams, V-DMC introduces a syntax structure called “atlas frame parameter set” as an extension to a V3C syntax structure. More particularly, Figure 3 illustrates an overview of attribute tile information in V-DMC bitstreams. The V-DMC bitstream comprises several sub-bitstreams also denoted bitstreams. For instance, the V-DMC bitstream comprises one or more geometry bitstreams 330, one or more attribute video bitstreams 325 and an atlas bitstream 320. The geometry bitstream(s) 330 may comprise a base mesh bitstream and possibly displacement bitstream(s). The attribute tile information is represented as 340. The atlas bitstream 320 is organized into atlas tiles, e.g. 321 to 324 and attribute tile information provides a mapping of atlas tiles onto video tiles. The video tiles like 325-1 are codec dependent (it is the choice of video encoder to partition into one or more tiles). The mapping of an atlas tile like 324 is described in the attribute tile information 340 (e.g. the data structure atlas_frame_attribute_tile_information(attrldx) in MPEG-I Part 29). There may be as many attribute tile information 340 as there are attribute video bitstreams 325. In the attribute tile information 340, a first information consists in describing tile partitions and to describe how an atlas tile 324 for one or more atlas frames is mapped to attribute video tiles like 325-1. First the partitioning of attribute video frames is described and a tile position and sizes is encoded in the bitstream to locate tile onto an attribute video bitstream like e.g. tile 340-1. Optionally, the attribute video tiles have identifiers that are also indicated into the syntax structure for attribute tile information. The syntax for attribute tile information and its use in atlas frame parameter set is described on Figure 4. Figure 4 illustrates syntax structures describing the attribute tile information for V-DMC bitstreams. More particularly, an Atlas frame parameter set comprises a V-DMC extension 410 (afps_vdmc_extension() data structure). The V-DMC extension 410 contains a systematic loop 410-1 on each video-coded attribute and the attribute tile information is described in the V-DMC bitstream for each attribute. More particularly, the syntax structure 410-2 lists the syntax elements describing the tile partitioning 340 as syntax elements 421, the tile positions and sizes with respect to these partitions (like e.g. tile 340-1) as syntax elements 422 and optionally some tile identifiers as syntax elements 423. Conversely, according to the present disclosure, the indication of the attribute tile information is no more systematic and takes into account one or more (or a combination) of parameters like: whether the tiling structure (or parts of) is consistent across attribute video bitstreams or not; whether it is consistent for one or more subsets of attribute video bitstreams or not; whether usability or configuration information indicates some static tiling indication for attribute video bitstreams or subsets of attribute video bitstreams. By considering this information, a V-DMC encoder may avoid repeating attribute tile information in the V-DMC bitstream and then reduce its size, in terms of bytes. For instance, the syntax structure for attribute tile information can be organized as discussed below in relation with Figure 5a, 5b or 5c. More particularly, according to the embodiment of Figure 5a, a first flag 511 (named afve_tiling_for_attribute_video_present_flag in Figure 5a) is added (or written or recorded) in the Atlas frame parameter set V-DMC extension 410 of the Atlas frame parameter set (afps_vdmc_extension() data structure) of the bitstreams description to indicate whether tiling information is available for attribute video bitstream(s) or not. If the first flag 511 indicates that tiling information is not available for attribute video bitstream(s) (e.g. the first flag 511 is set to “false”), there is no need to declare attribute tile information. In this case, decoders should assume that there is only one tile corresponding to the whole picture and that there are no tile identifiers defined. In a variant, decoders should assume that tiling partitioning for attribute video bitstream is the same as the tiling partitioning for the atlas bitstream with a one-to-one mapping. Conversely, if the first flag 511 indicates that tiling information is available for attribute bitstreams (e.g. the first flag 511 is set to “true”), then a second flag 512 (named for example afve_consistent_tiling_across_attribute_video_flag in Figure 5a) is added (or written or recorded) to the bitstreams description in the Atlas frame parameter set V-DMC extension of the Atlas frame parameter set. If the second flag 512 indicates that tiling is consistent across attribute video bitstreams (e.g. the second flag 512 is set to “true”), this means that, for decoders, looping on all attributes is not necessary. One (i.e. a single) tiling information 513 can thus be encoded once in the bitstreams description for one attribute and reused for other attributes. Alternatively, if the second flag 512 indicates that tiling is not consistent across attribute video bitstreams (e.g. the second flag 512 is set to “false”), attribute tile information is encoded in the bitstreams description for each attribute video bitstream. Then, the semantics for these new flags can be defined as follows (the name of the flags are just examples): afve_tiling_for_attribute_video_present_flag (i.e. the first flag 511) equal to 1 specifies that atlas_frame_attribute_tile_information is present. If afve_tiling_for_attribute_video_present_flag is equal to 0, it indicates that no atlas_frame_attribute_tile_information is present. When no atlas_frame_attribute_tile_information is present, the values for tile partitions, tile positions and sizes are the same as when the afati_single_tile_in_atlas_frame_flag is set to 1 (in atlas frame attribute tile information syntax) and no tile ID are specified. It should then be assumed that there is a single tile that corresponds to the whole frame. It should also be assumed that the identifier for this single tile is the tile index and is equal toO. In a variant, when no atlas_frame_attribute_tile_information is present, the values for tile partitions, tile positions, sizes and tile IDs are the same as defined in atlas_frame_tile_information in the atlas frame parameter set. afve_consistent_tiling_across_attribute_video_flag (i.e. the second flag 512) equal to 1 specifies that the atlas_frame_attnbute_tile_information is indicated only for one attribute and the tiling information for other attributes (or attribute video bitstreams) are duplicated from tiling information of this attribute. In such case, tiling information may correspond to tiling information for the first attribute or anyone of the other attributes. If afve_consistent_tiling_across_attribute_video_flag is equal to 0, atlas_frame_attribute_tile_information is indicated for each attribute (or attribute video bitstream). In some alternative embodiments, the first flag 511 is not implemented and the presence or not of the second flag 512 alone may be interpreted as informing that tiling information is available for attributes (or attribute videos or attribute video bitstreams) or not. For instance, if the first flag 511 is not implemented and if the second flag 512 is not present, the decoder may conclude or be informed that no tiling information is available for attributes. Conversely, if the first flag 511 is not implemented and if the second flag 512 is present, as represented on Figure 5c, the decoder may be informed that tiling information is available for attributes. Thus, the use of the second flag 512 without having the first flag 511 implemented already allows improving the situation compared to the existing syntax detailed above in relation with Figure 4 wherein looping on all attributes is systematically present. As a variant to the proposed syntax element for attribute tile consistency (e.g. the second flag 512 indicating all attribute videos are consistent or none), there may be one or more syntax elements, each syntax element indicating which part of the attribute tile information is consistent across attributes (or attribute videos or attribute video bitstreams). For example, there may be a syntax element indicating that the partitioning 421 is consistent, a syntax element indicating that the mapping of tile to the partitions 422 is consistent, or a syntax element indicating the both 421 and 422 are consistent, a syntax element indicating that tile identifiers 423 are consistent. As a variant to the proposed syntax element for attribute tile consistency (e.g. the second flag 512 indicating all attribute videos are consistent or not), there may be cases where subsets of attributes (or attribute video bitstreams) share the same tiling configuration. These cases may also lead to repetition of attribute tile information. To avoid this and save bits in the V-DMC high level syntax, these subsets may be described in the atlas frame parameter set for V-DMC extension. For instance, one attribute_tile_information for a respective given subset may be indicated in the V-DMC bitstream, this attribute tile information applying to all attributes (or attribute video bitstreams) in this subset. An encoder may pre-generate a subset-based description and a complete loop on all attributes and finally select the lighter description. Indeed subsetbased approach may be interesting only if the number of subsets is reduced or if subsets contain a significant number of attributes compared to the number of attributes indicated by the syntax element asve_num_attribute_video. A subset-based approach requires an indication of a number of subsets and for each subset, the list of attributes contained in this subset (one attribute being in only one subset or outside the subsets). Then, the attribute tile information, instead of being declared for every attribute is declared for each subset and for attributes that are outside the subsets (their indexes can be deduced as indexes between 0 and asve_num_attribute_videothat are not included in any subset. It is to be noted that this subset-based variant can also combine with the variant where one or more flags are used to describe consistency in a more granular manner (for example one flag for partitioning 421, one for tile mapping 422 (or one for combination of both partitioning and mapping), one for identifiers 423). Alternatively, in the embodiment of Figure 5b, the first flag 511 present in the Atlas frame parameter set V-DMC extension 410 of the Atlas frame parameter set of the bitstreams description still indicates whether tiling information is available for attributes (or attribute video bitstreams) or not. However, contrary to the embodiment of Figure 5a, in the present embodiment the second flag 512 is implemented in the atlas frame attribute tile information 522 (named atlas_frame_attribute_tile_information in Figure 5b) of the bitstreams description. The second flag 512 indicates whether the tiling structure is consistent across attributes (or attribute video bitstreams) or not. If the second flag 512 indicates the tiling structure is not consistent across attribute video bitstreams, a loop (indicated through label 524 in Figure 5b) on attributes provides the descriptions for partitions, tiles position and sizes and optionally tile identifiers as in syntax elements 421, 422 and 423. Alternatively, when the second flag 512 indicates that the tiling structure is consistent across attributes (or attribute video bitstreams), only one (i.e. a single) common configuration 525 of partitions, tile positions and sizes and possibly tile identifiers is written in the bitstreams description. In some alternative embodiments, as discussed above, the first flag 511 is not implemented and the presence or not of the second flag 512 may already allow improving the situation compared to the existing syntax detailed above in relation with Figure 4 wherein looping on all attributes is systematically present. As well, the syntax elements for tile identifiers or indexes like 423 may not be present and the ones defined for atlas tiles are used instead. Encoding of volumetric data according to some embodiments of the present disclosure Figure 6 illustrates the steps of an encoding method according to one embodiment of the present disclosure. For the sake of illustration, such steps may be executed by the encoder module 110. More particularly, during step 600, volumetric data to be compressed are obtained. For instance, the volumetric data are visual volumetric data and may be acquired, e.g. from a capturing device like a 3D camera. Alternatively, the volumetric data may be generated by a computer e.g. as a mesh representation, texture information and possibly other attributes describing properties of the volumetric data. Back to Figure 6, during step 601, the encoder module 110 checks if tiling (i.e., partitioning of a frame into tiles) has to be applied for the compression of the volumetric data. For instance, the encoder module 110 is configured with pre-defined settings regarding organisation of the compressed volumetric data into tiles. The settings configure the encoder module 110 such that the encoder offers spatial access or not, or whether it looks for maximal compression or not or a trade-off between both compression and spatial access. When tiling is not activated during the step 601, the encoder module 110 is configured for implementing no tiling. Such information is indicated in the bitstream. For example, using the first flag 511 the encoder module 110 indicates that there is not tile information encoded in the bitstream for attribute video bitstreams (e.g. the first flag 511 is set to “false”) as discussed above in relation with Figure 5a and Figure 5b. Then the attribute tile information can be omitted from the bitstream, thus saving bytes. Conversely, when tiling is activated during the step 601, the value of the first flag 511 encoded (or equivalently “recorded”) into the bitstreams description indicates that tiling information is available for attributes (or attribute video bitstreams) (e.g. the first flag 511 is set to “true”). In some alternative embodiments, as discussed above in relation with Figure 5a and Figure 5b, the first flag 511 is not implemented and the presence or not of the second flag 512 may allow informing the decoder that tiling information is available for attributes (or attribute video bitstreams) or not respectively. Back to Figure 6, when tiling is activated during the step 601, the encoder module 110 executes a step 610 wherein the encoder module 110 checks, e.g. based on the settings, whether a consistent tiling or not is applied onto attributes that are encoded as different attribute video bitstreams. Examples of attribute tile partitions that may be determined as consistent are illustrated and described below as reference to Figures 6a, 6b or 6c. If during step 610 it is checked that a consistent tiling is applied onto attributes that are encoded as different attribute video bitstreams, such information is encoded in the bitstreams description during step 611. This is done e.g. using the second flag 512 that is set to a value indicating that the tiling structure is consistent across different attribute video bitstreams (e.g. the second flag 512 is set to “true”). During step 612, a piece of information representative of the tiling structure used across the different attribute video bitstreams is recorded in the bitstreams description. For instance, one (i.e. a single) attribute tile information 513 is recorded once in the bitstreams description or one (i.e. a single) common configuration 525 of partitions, tile positions and sizes and possibly tile identifiers is recorded once in the bitstreams description as discussed above in relation with Figure 5a and Figure 5b respectively. In other words, a single attribute tile information 513 or a single configuration 525 comprising at least partitions, tile positions and sizes common to the different attribute video bitstreams is recorded in the bitstreams description. Back to Figure 6, if during step 610 it is checked that no consistent tiling has to be applied across different attribute video bitstreams, such information is recorded in the bitstreams description during step 621. This is done e.g. using the second flag 512 that is set to a value indicating that the tiling structure is not consistent across attributes (or attribute video bitstreams) (e.g. the second flag 512 is set to “false”). During step 622, the attribute tile information is encoded in the bitstreams description for each attribute that is encoded as a bitstream or sub-bitstream as known in the V-DMC legacy standard specification. In other words, a piece of information is representative of attribute tile information for each attribute bitstreams. Conversely, when tiling is not activated during the step 601, such information is indicated in the bitstreams description during step 602. This is done e.g. by using the first flag 511 that is set to a value indicating that there is no tile information encoded in the bitstream for attribute video bitstreams (e.g. the first flag 511 is set to “false”). In this case, the second flag 512 is not recorded in the bitstreams description. Alternatively, during step 602 both the first flag 511 and the second flag 512 are not recorded in the bitstreams description. In this case, the absence of the first flag 511 and the second flag 512 in the bitstreams description may indeed indicate that tiling is not activated by default. In another alternative, at step 602, only the flag 512 is recorded in the bitstream, this to save bits by avoiding repeating an atlas_frame_attribute_tile_information for each attribute. In this case, only one tile would be indicated in the bitstream and the afati_single_tile_in_atlas_frame_flag set to 1 would indicate that the whole frame would correspond to this single tile. The attribute tile information would then be set to the default configuration (one tile, one partition and tile identifier corresponding to tile index set to 0). During step 604, the encoder module 110 compresses the volumetric data based on the settings regarding organisation of the compressed volumetric data into tiles. Such compression implements e.g. any known compression algorithm compliant with the V-DMC standard (e.g. compliant with MPEG-I Part-29). Step 604 delivers compressed bitstreams, e.g. in the V-DMC format. When information was recorded in the bitstreams description, e.g. the first flag 511 or the second flag 512, during step 605 the encoder module 110 append the description in the compressed bitstream. Step 605 delivers the bitstream for the compressed volumetric data. In some embodiments, the first flag 511 is recorded in the Atlas frame parameter set V-DMC extension 410 of the Atlas frame parameter set (also denoted V-DMC extension atlas frame parameter set) of the bitstreams description. In some embodiments, the second flag 512 is recorded in the Atlas frame parameter set V-DMC extension 410 of the Atlas frame parameter set or in the V-DMC atlas frame attribute tile information 522 of the Atlas frame parameter set V-DMC extension 410 of the Atlas frame parameter set of the bitstreams description. In some embodiments discussed below, the second flag 512 is recorded in the Volumetric Usability Information, e.g. vui_parameters syntax structure, 800 of the bitstreams description. In some embodiments discussed below (e.g. in relation with Figure 8), the second flag 512 is recorded in a syntax structure 823 dedicated to a specific codec, for example V-DMC codec, in the vui_parameters syntax structure 800. In some embodiments discussed below, the second flag 512 is recorded in a syntax structure specifically dedicated to a V-DMC codec of the Atlas Sequence Parameter Set of the bitstreams description. In some embodiments discussed below, the second flag 512 is recorded in the codec-specific parts of the Atlas Sequence Parameter Set of the bitstreams description. Figures 6a, 6b and 6c illustrate examples of attribute tile partitions that may be considered as consistent during encoding step 610. An encoder may implement different consistency check that may be more or less strict. Indeed, as will be described below, consistent attribute tile partitioning does not necessarily imply the same size of the video attributes (in other words, in some cases described hereafter, the consistency flag may be set for a set of attributes even when they have different values for their asve_attribute_frame_width or asve_attribute_frame_height). Figure 6a illustrates the mapping of the fourth atlas tile 324 from an atlas frame 320 contained in an atlas sub-bitstream to different attribute frames in different attribute video sub-bitstreams, a first attribute frame 620 for an attribute with attribute index “i” and a second attribute frame 630 for another attribute with attribute index “j”, j being different than “i”. Both “i” and “j” have values in the range [0, asve_num_attribute_video[ (in other words [0, asve_num_attribute_video - 1]). These attribute frames are part of attribute sub-bitstreams that are encoded as video subbitstreams. The configuration depicted on Figure 6a corresponds to what may be called a “strict” consistency mode for which the consistency check 610 returns true, meaning that the attribute frames 620 and 630 have the same number of tile partitions in both horizontal and vertical dimensions and a given tile partition with index “tp” like 621 in attribute “i” has the same number of pixels as the corresponding tile partition 631 in attribute “j”. This leads to the same mapping of the atlas tile 324 onto attribute frames 620 and 630 as depicted by 622 and 632 respectively. It may be noted that for the specific case of last column and last row in the attribute frames, the number of pixels may vary between the attribute frames 620 and 630. In such case, the consistency check 610 may also return true. Another example where the consistency check 610 may also return true and the consistency flag 512 may be set to true is when each attribute has the afati_single_tile_in_atlas_frame_flag that is set to true (or encoder setting specifies a single tile per attribute frame), even if the sizes of the attribute video differ. As well, when afati_uniform_partition_spacing_flag is equal to 1, the video attributes may have different sizes but should be such that their widths and heights lead to the same number of tile partition columns and rows respectively. In other words, the ratio asve_attribute_frame_width[ attrldx ] I widthPartition and the ratio asve_attribute_frame_height[ attrldx ] I heightpartition are constant for any value of attrldx. For the latter case, a same tile partitioning means that widthPartition and heightpartition are constant and equal to (afati_partition_cols_width_minus1[ 0 ] + 1 ) * 64 and (afati_partition_rows_height_minus1[ 0 ] + 1) * 64 respectively, where afati_partition_cols_width_minus1 and afati_partition_rows_height_minus1 may correspond to encoder settings to specify the width and the height respectively of the attribute tile partition columns and rows of an attribute, excluding the right-most attribute tile partition column of the attribute atlas frame in units of 64 samples (64 being one example of unit, other values may be used depending on the tile partition granularity that is desired). Figure 6b illustrates the mapping of the fourth atlas tile 324 from an atlas frame 320 contained in an atlas sub-bitstream to different attribute frames in different attribute video sub-bitstreams, a first attribute frame 620-b for an attribute with attribute index “i” and a second attribute frame 630-b for another attribute with attribute index “j”, j being different than “i”. Both “i” and “j” have values in the range [0, asve_num_attribute_video[ (in other words, [0, asve_num_attribute_video - 1]). These attribute frames are part of attribute sub-bitstreams that are encoded as video subbitstreams. The configuration depicted on Figure 6b corresponds to what may be called a “proportional” consistency mode, meaning that the attribute frames 620-b and 630-b have the same number of tile partitions in both horizontal and vertical dimensions but a given tile partition with index “tp” like 621-b in attribute “i” has a different number of pixels than the corresponding tile partition 631-b in attribute “j”. Indeed, possibly the tile partitions in attribute with index “i” have different sizes in pixels than tile partitions in attribute “j” but the width ratio between the tile partitions at a same tile partition index “tp” in attribute “i” and attribute “j” is constant (equal to wj divided by wi) and the height ratio between the tile partitions at a same tile partition index ‘tp’ in attribute “i” and attribute “j” is also constant (hj divided by hi), except possibly for the rightmost column and bottom row. This configuration leads to the same mapping of the atlas tile 324 onto attribute frames 620-b and 630-b as depicted by 622-b and 632-b respectively and the encoder can return true in the consistency check 610 and set the consistency flag 512 to true. Figure 6c illustrates the mapping of the fourth atlas tile 324 from an atlas frame 320 contained in an atlas sub-bitstream to different attribute frames in different attribute video sub-bitstreams, a first attribute frame 620-c (or 620-d) for an attribute with attribute index “i” and a second attribute frame 630-c (or 630-d) for another attribute with attribute index “j”, j being different than “i”. Both “i” and “j” have values in the range [0, asve_num_attribute_video[. These attribute frames are part of attribute sub-bitstreams that are encoded as video sub-bitstreams. The configuration depicted on Figure 6c corresponds to what may be called a “lax” consistency mode or “partial” consistency mode in opposition to “strict” or “proportional” mode, because here the number of tile partitions across attributes is not necessarily the same. As can be seen on Figure 6c, attribute frame 620-c contains 9 tile partitions whereas attribute frame 630-c contains 16 tile partitions. As well, comparing tile partition 621-c and 631-c shows that tile partitions do not have the same size and that a constant ratio between corresponding tile partitions cannot be applied. A point to note here is that despite the different tile partitions, the mapping of the atlas tile 324 corresponds to the same areas in attribute frames 620-c (or 620-d) and 630-c (or 630-d). When detecting such configuration, an encoder may return true for the consistency check 610 and set the consistency flag to true. However, the syntax to indicate the mapping of atlas tiles to attribute tiles does not rely anymore on tile partitions and their index, but rather on indicating the top-left and bottom right positions as, for example, a percentage of a reference attribute frame. For example, on Figure 6c, the mapping of the atlas tile 324 would be described as having top-left position at (x=2 / 3, y=1 / 4) and bottom right position at (1,1) in the attribute frames 620-c and 630c because they have same width and height. For the case of attribute frames with different sizes, as in 620-d or 630-d, the mapping of atlas tile could be indicated still as top-left position at (x=2 / 3, y=1 / 4) and bottom right position at (1,1) in a reference attribute frame for example 620-d or 630-d, preferably the one with lowest dimensions (for example 620-d), to avoid rounding issues and keep integer ratio. Then the mapping of atlas tile in other attribute frames than the reference attribute frame would be inferred from the values indicated for this reference attribute frame, for example by applying the ratio of their width (wj divided by wi) and height (hj divided by hi) to the width and height of the area covered (corresponding to the atlas tile) in the reference attribute frame. Using a reference attribute frame may require a syntax element, for example before the syntax element 513 on Figure 5a or 5c or as a syntax element in 525 on Figure 5b or in volumetric usability information and a modified syntax for 513 and 524 (based on top-left and bottom-right positions indicated as ratio in a reference attribute frame). Alternatively, to this additional syntax element, the reference attribute frame may be implicitly determined as the one with the smallest dimensions, for example the one that has the minimum width and height or the minimum value for (width*height). It is recalled that these attribute frame width and height may be indicated in the asps_vdmc_extension syntax structure. Alternatively, when a reference attribute frame is in use the same syntax element are used for 513 or 524 but the inference process is different, computing pixel position instead of tile partition in the other (non-reference) attribute frames. It is to be noted that for conciseness, the examples of Figure 6a, 6b and 6c illustrates only 2 attributes but the principle remains whatever the number of attributes. The consistency mode used for test 610 may be indicated as an additional syntax element, for example before syntax element 513 on Figure 5a or 5c or as a syntax element in 525 on Figure 6b or in volumetric usability information (not represented) to inform decoders or entities processing the V-DMC bitstream of possible inference mode of other attribute tile information when the consistency flag is set. These different inference modes are described as reference to Figure 7 hereafter. Decoding of compressed volumetric data according to some embodiments of the present disclosure Figure 7 illustrates the steps of a decoding method according to one embodiment of the present disclosure. For the sake of illustration, such steps may be executed by the decoding module 170. More particularly, during step 700, the decoding module 170 obtains the bitstream for the compressed volumetric data, e.g. in a V-DMC compliant format. For instance, the compressed volumetric data is received from the de-encapsulation module 160. During step 701, the decoding module 170 decodes the bitstreams description delivering the set of parameters or syntax elements describing the attribute video bitstreams that compose the bitstream for the compressed volumetric data. More particularly, the set of parameters comprises the first flag 511 and / or the second flag 512 depending on the implementation as discussed above e.g. in relation with Figure 6. Back to Figure 7, during step 702, the decoding module 170 checks if tiling applies to the compression of the volumetric data, e.g. if spatial access is allowed in the compressed volumetric data by looking at the first flag 511 and / or the second flag 512 in the set of parameters. For instance, when the first flag 511 is not present in the set of parameters, or when the first flag 511 is indicative that there is not tile information encoded in the bitstream (e.g. the first flag 511 is set to “false”), the decoding module 170 is configured for implementing no tiling. In such case, during a step 710, the decoding module 170 infers tile partitions, offsets and sizes, e.g. based on default values. Conversely, when the first flag 511 is indicative that there is tile information encoded in the bitstream (e.g. the first flag 511 is set to “true”) or when the first flag 511 is not present but the second flag 512 is present, the decoding module 170 is configured for implementing tiling. In such case, during a step 703, the decoding module 170 checks whether a consistent tiling or not is applied onto attributes that are encoded as different attribute video bitstreams, e.g. based on the value of the second flag 512. For instance, when the second flag 512 is set to a value indicating that tiling is consistent across attribute video bitstreams (e.g. the second flag 512 is set to “true”). During step 720, a piece of information representative of the tiling structure used across the different attribute video bitstreams is decoded from the bitstreams description. For instance, the piece of information is one (i.e. a single) attribute tile information 513 decoded once from the bitstreams description. Alternatively, the piece of information is one (i.e. a single) common configuration 525 of partitions, tile positions and sizes and possibly tile identifiers decoded once from the bitstreams description as discussed above in relation with Figure 5a and Figure 5b respectively. Back to Figure 6, the tiling information 513 or the common configuration 525 of partitions is inferred during a step 740 for other attribute video bitstreams from the decoded piece of information. Conversely, when the second flag 512 is set to a value indicating that tiling is not consistent across attribute video bitstreams (e.g. the second flag 512 is set to “false”). During steps 730 and 731, the attribute tile information is decoded in the bitstreams description for each attribute video bitstream, e.g. sequentially or in parallel. In other words, a piece of information representative of attribute tile information for each attribute bitstreams is decoded during steps 730 and 731. Once the piece of information is decoded and inferred for all attribute video bitstreams, the compressed volumetric data is decoded, based on the piece of information, during step 705 delivering decoded volumetric data. Such decoded volumetric data is e.g. provided to a rendering device (e.g. a TV) for rendering, or to a storage device for storage, etc. In some embodiments, the first flag 511 is recorded (or equivalently “encoded”) in the Atlas frame parameter set V-DMC extension 410 of the Atlas frame parameter set (also denoted V-DMC extension atlas frame parameter set) of the bitstreams description. In some embodiments, the second flag 512 is recorded in the Atlas frame parameter set V-DMC extension 410 or in the V-DMC atlas frame attribute tile information 522 of the Atlas frame parameter set V-DMC extension 410 of the Atlas frame parameter set of the bitstreams description. In some embodiments discussed below, the second flag 512 is recorded in the Volumetric Usability Information, vui_parameters syntax structure 800 of the bitstreams description. In some embodiments discussed below (e.g. in relation with Figure 8), the second flag 512 is recorded in a syntax structure 823 dedicated to a specific codec, for example a V-DMC codec, in the vui_parameters syntax structure 800. In some embodiments discussed below, the second flag 512 is recorded in a syntax structure specifically dedicated to a V-DMC codec of the Atlas Sequence Parameter Set of the bitstreams description. In some embodiments discussed below, the second flag 512 is recorded in the codec-specific parts of the Atlas Sequence Parameter Set of the bitstreams description. Back to the inference process in step 740, it may depend on the consistency mode used by an encoder. When there may be several consistency modes, an indication may be set as an additional syntax element as described in reference to Figure 6a, 6b or 6c. This additional syntax element could be read by a decoder or any entity processing the V-DMC bitstream, for example at step 703 (or from volumetric usability information). If there is no indication of the consistency mode, the attribute tile information may be decoded (730 or 720) and inferred (740) as follows: In the case the atlas frame size for an attribute component is different from the atlas frame size of geometry component, the partitioning of the atlas frame can be extended as follows. When afve_consistent_tiling_across_attribute_video_flag is equal to 1, specifying tiling is consistent across attributes , only the width and height of the first attribute tile partition is indicated in the atlas frame attribute tile information syntax structure. The attribute frame, for attribute with index attrldx=0, is partitioned into NumPartitionColumnsAtt[ 0 ] * NumPartitionRowsAtt[ 0 ] number of attribute tile partitions, where NumPartitionColumnsAtt[ 0 ] and NumPartitionRowsAtt[ 0 ] are derived as explained below in “Attribute tile partition scanning processes” applied to attrldx=0. The attribute frame, for attribute with index attrldx >0, is partitioned into NumPartitionColumnsAtt[ attrldx ] * NumPartitionRowsAtt[ attrldx ] number of attribute tile partitions, where NumPartitionColumnsAtt[ attrldx ] and NumPartitionRowsAtt[ attrldx ] are derived as explained below in “Attribute tile partition inference process”. When afve_consistent_tiling_across_attribute_video_flag is equal to 0, specifying tiling is not consistent across attributes, the width and height of each attribute tile partition is indicated in the atlas frame attribute tile information syntax structure. The attribute frame, for attribute with index attrldx >=0, is first partitioned into NumPartitionColumnsAtt[ attrldx ]* NumPartitionRowsAtt[ attrldx ] number of attribute tile partitions, where NumPartitionColumnsAtt[ attrldx] and NumPartitionRowsAtt[ attrldx ] are derived as explained below in “Attribute tile partition scanning processes”. One or more attribute tile partitions are then combined into attribute tiles by indicating the locations of the attribute tile partitions that correspond to the top-left and bottom-right corners of the attribute tile, as indicated in syntax structure for attribute_tile_information like 422. All attribute tile partitions within these two attribute tile partitions collectively form an attribute tile, which is essentially a rectangular region of the attribute video frame. When afve_consistent_tiling_across_attribute_video_flag is equal to 0, the locations of the attribute tile partitions are derived as explained below in “Attribute tile partition scanning processes”. When afve consistent tiling across attribute video flag is equal to 1, the locations of the attribute tile partitions for the first attribute is derived as explained below in “Attribute tile partition scanning processes" and the locations of the attribute tile partitions for the remaining attributes are derived as explained below in “Attribute tile partition inference process". Attribute tile partition scanning processes For attribute with index attrldx, the list PartitionWidthAtt[ attrldx ][ i ], for i ranging from 0 to NumPartitionColumnsAtt[ attrldx] - 1, inclusive, specifying the width of the i-th attribute tile partition column in units of 64 samples, is derived, and the value of NumPartitionColumnsAtt[ attrldx ] for an attribute with index attrldx, is inferred, as follows: if ( afati^uniform_partition_spacing_flag[ attrldx ] ) { widthPartition = ( afati_partition_cols_width_minusl[ attrldx ] + 1 ) * 64 NumPartitionColumnsAtt[ attrldx ] = asve attribute frame width[ attrldx ] / widthPartition PartitionPosXAtt[ attrldx ][ 0 ] = 0 PartitionWidthAtt[ attrldx ][ 0 ] = widthPartition for ( i = 1; i <NumPartitionColumnsAtt[ attrldx ] 1; i++ ) { PartitionPosXAtt[ attrldx ][ i ] = PartitionPosXAtt[ attrldx ] [ i - 1 ] + PartitionWidthAtt[ attrldx ][ i - 1 ] PartitionWidthAtt[ attrldx ][ i ] = widthPartition } } else { NumPartitionColumnsAtt[ attrldx ] = afati_num_partition_columns_minusl[ attrldx ] + 1 PartitionPosXAtt[ attrldx ][ 0 ] = 0 PartitionWidthAtt[ attrldx ] [ 0 ] = ( afati partition column width minusl[ attrldx ][ 0 ] + 1 ) * 64 ” _ _ _ for ( i = 1; i <NumPartitionColumnsAtt[ attrldx ] - 1; i++ ) { PartitionPosXAtt[ attrldx ] [ i ] = PartitionPosXAtt[ attrldx ] [ i - 1 ] + PartitionWidthAtt[ attrldx ][ i - 1 ] PartitionWidthAtt[ attrldx ][ i ] = ( afati partition column width minusl[ attrldx ][ i ] + 1 ) * 64 } } if ( NumPartitionColumnsAtt[ attrldx ] >1 ) { lastindex = NumPartitionColumnsAtt[ attrldx ] - 1 PartitionPosXAtt[ attrldx ][ lastindex ] = PartitionPosXAtt[ attrldx ][ lastindex - 1 ] + PartitionWidthAtt[ attrldx ][ lastindex - 1 ] PartitionAttributeWidth[ attrldx ][ lastindex ] = asve^attribute^frame_width[ attrldx ] PartitionPosXAtt[ attrldx ][ lastindex ] } For attribute with index attrldx, the list PartitionHeightAtt[ attrldx ][ j ] for j ranging from 0 to NumPartitionRowsAtt[ attrldx] -1, inclusive, specifying the height of the j-th attribute tile partition row in units of 64 samples, is derived, and the value of NumPartitionRowsAtt[ attrldx ] is inferred, as follows: if ( afati_uniform_partition_spacing_flag[ attrldx ] ) { heightpartition = (afati partition rows height minusl[ attrldx ] + 1) * 64 NumPartitionRowsAtt[ attrldx ] = asve attribute frame height [ attrldx ] / heightpartition PartitionPosXAtt[ attrldx ][ 0 ] = 0 PartitionHeightAtt[ attrldx ][ 0 ] = heightpartition for ( j = 1; j <NumPartitionRowsAtt[ attrldx ] 1; j++ ) { PartitionPosXAtt[ attrldx ][ j ] = PartitionPosXAtt[ attrldx ] [ j - 1 ] + PartitionHeightAtt[ attrldx ][ j - 1 ] PartitionHeightAtt[ attrldx ][ j ] = heightpartition } } else { NumPartitionRowsAtt[ attrldx ] = afati_num_partition_rows_min usl[ attrldx ] + 1 PartitionPosXAtt[ attrldx ][ 0 ] = 0 PartitionHeightAtt[ attrldx ][ 0 ] = ( afati partition row height minusl[ attrldx ][ 0 ] + 1 ) * 6 4 for ( j = 1; j <NumPartitionRowsAtt[ attrldx ] 1; j++ ) { PartitionPosXAtt[ attrldx ][ j ] = PartitionPosXAtt[ attrldx ] [ j - 1 ] + PartitionHeightAtt[ attrldx ] [ j - 1 ] PartitionHeightAtt[ attrldx ] [ j ] = ( afati partition row height minusl[ attrldx ][ j ] + 1 ) * 6 4 } } if ( NumPartitionRowsAtt[ attrldx ] >1 ) { lastindex = NumPartitionRowsAtt[ attrldx ] - 1 PartitionPosYAtt[ attrldx ][ lastindex ] = PartitionPosYAtt[ attrldx ][ lastindex - 1 ] + PartitionHeightAtt[ attrldx ][ lastindex 1 ] PartitionHeightAtt[ attrldx ][ lastindex ] = asve attribute frame height[ attrldx ] -PartitionPosYAtt[ attrldx ][ NumPartitionRowsAtt[ attrldx ] -1 ] } It is a requirement of bitstream conformance that the values of PartitionWidthAtt[ attrldx ][ i ] for i ranging from 0 to NumPartitionColumnsAtt[ attrldx ] — 1, inclusive, and PartitionHeightAtt! attrldx ][ j ] for j ranging from 0 to NumPartitionRowsAtt! attrldx ] -1, inclusive, are greater than or equal to 64 and are multiples of PatchPackingBlockSize. The variables topLeftColumnAtt[ attrldx ][ i ], topLeftRowAtt[ attrldx ][ i ], bottomRightColumnAtt! attrldx ][ i ], and bottomRightRowAtt[ attrldx]! i ], which specify the corresponding tile column and row positions for the top left and bottom right attribute tiles in an attribute tile for the attribute signalled in the Attribute Video Data unit with index attrldx are computed as follows: topLeftColumnAtt[ attrldx ] [ i ] = afati top left partition idx[ attrldx ][ i ] % NumPartitionCo lumnsAtt[ attrldx ] topLeftRowAtt[ attrldx ] [ i ] = afati top left partition idx[ attrldx ][ i ] / NumPartitionCo lumnsAtt[ attrldx ] bottomRightColumnAtt[ attrldx ][ i ] = topLeftColumnAtt[ attr Idx ][ i ] + afati bottom right partition column offset [ attrldx ] [ i ] bottomRightRowAtt[ attrldx ][ i ] = topLeftRowAtt[ attrldx ][ i ] + afati_bottom_right_partition_row_offset[ attrldx ][ i ] It is a requirement of bitstream conformance that the values of bottomRightColumnAtt[ attrldx ][ i ] and bottomRightRowAtt[ attrldx ][ i ] shall be smaller or equal to (asve_attribute_frame_width[ attrldx ] + 63) / 64 - 1 and ( asve_attribute_frame_height[ attrldx ] + 63) / 64 - 1, respectively. It is also a requirement of bitstream conformance that there shall not be a value of j, where j != i, that satisfies either one of these properties: topLeftColumnAtt[ attrldx ][ i ] <= topLeftColumnAtt[ attrldx ][ j J <= bottomRightColumnAtt [ attrldx ][ i ] topLeftRowAtt[ attrldx ][ i ] <= topLeftRowAtt[ attrldx ][ j ] <= bottomRightRowAtt[ attr Idx ][ i ] Attribute tile partition inference process This subclause only applies when afve_consistent_tiling_across_attribute_video_flag is equal to 1 to initialize, for each attribute with index greater than 0, the attribute tile partitions from the values decoded for the attribute with index 0. A first inference process may be used for strict consistency mode for ( attrldx = 1; attrldx <asve num attribute video; attrldx++ ) { NumPartitionColumnsAtt[ attrldx ] = NumPartitionColumnsAtt[ 0 NumPartitionRowsAtt[ attrldx ] = NumPartitionRowsAtt[ 0 ] for ( i = 0; i <NumPartitionColumnsAtt[ attrldx ] - 1; i++ ) { PartitionPosXAtt[ attrldx ][ i ] = PartitionPosXAtt[ 0 Hi] PartitionWidthAtt[ attrldx ][ i ] = PartitionWidthAtt[ 0 J [ i 1 } for ( i = 0; i <NumPartitionRowsAtt[ attrldx ] 1; i++ ) { PartitionPosXAtt[ attrldx ] [ i ] = PartitionPosXAtt[ 0 ] [ i ] PartitionHeighthAtt[ attrldx ][ i ] = PartitionHeightAtt[ 0 ] [ i ] H A second inference process may be used for strict or proportional modes: for ( attrldx = 1; attrldx <asve_num_attribute_video; attrldx++ ) { if ( afati uniform partition spacing flag[ 0 ] ) { / / uniform spacing NumPartitionColumnsAtt[ attrldx ] = NumPartitionColumnsAtt[ 0 ] widthPartition = asve attribute frame width [attrldx ] / NumPartitionColumnsAtt[ 0 ] PartitionPosXAtt[ attrldx ][ 0 ] = 0 PartitionWidthAtt[ attrldx ][ 0 ] = widthPartition for ( i = 1; i <NumPartitionColumnsAtt[ 0 ] - 1; i++ ) { PartitionPosXAtt[ attrldx ][ i ] = PartitionPosXAtt[ attrld x ] [ i - 1 ] + PartitionWidthAtt[ attrldx ][ i - 1 ] PartitionWidthAtt[ attrldx ] [ i ] = widthPartition } } else { / / non uniform spacing widthRatio = asve attribute frame width[ attrldx ] / asve attribute frame width[ 0 ] NumPartitionColumnsAtt[ attrldx ] = NumPartitionColumnsAtt[ 0 ] PartitionPosXAtt[ attrldx ][ 0 ] = 0 PartitionWidthAtt[ attrldx ][ 0 ] = PartitionWidthAtt[ 0 ][ 0 ] * widthRatio for ( i = 1; i <NumPartitionColumnsAtt[ 0 ] 1; i++ ) { PartitionPosXAtt[ attrldx ][ i ] = PartitionPosXAtt[ attrld x ] [ i - 1 ] + PartitionWidthAtt[ attrldx ][ i - 1 ] PartitionWidthAtt[ attrldx ] [ i ] = PartitionWidthAtt[ 0 ][ i ] * widthRatio } } if ( NumPartitionColumnsAtt[ 0 ] >1 ) { lastindex = NumPartitionColumnsAtt[ 0 ] - 1 PartitionPosXAtt[ attrldx ][ lastindex ] = PartitionPosXAtt[ attrldx ][ lastindex - 1 ] + PartitionWidthAtt[ attrldx ][ lastindex - 1 ] PartitionWidthAtt[ attrldx ][ lastindex ] = asve attribute frame width[ attrldx ] -PartitionPosXAtt[ attrldx ][ lastindex ] } / / Compute vertical positions and heights for the tile partitions if ( afati uniform partition spacing flag[ 0 ] ) { / / uniform spacing NumPartitionRowsAtt[ attrldx ] = NumPartitionRowsAtt[ 0 ] heightpartition = asve^attribute^frame^height [attrldx ] / NumPartitionRowsAtt[ 0 ] PartitionPosXAtt[ attrldx ][ 0 ] = 0 PartitionHeightAtt[ attrldx ][ 0 ] = heightpartition for ( j = 1; j <NumPartitionRowsAtt[ 0 ] - 1; j++ ) { PartitionPosYAtt[ attrldx ][ j J = PartitionPosYAtt[ attrld x ] [ j - 1 ] + PartitionHeightAtt[ attrldx ][ j — 1 ] PartitionHeightAtt[ attrldx ][ j ] = partitionHeightAtt[ 0 ][ j ] * heightpartition } } else { non uniform spacing heightRatio = asve attribute frame height[ attrldx ] / asve attribute frame height [ 0 ] NumPartitionRowsAtt[ attrldx ] = NumPartitionRowsAtt[ 0 ] PartitionPosYAtt[ attrldx ][ 0 ] = 0 PartitionHeightAtt[ attrldx ][ 0 ] = PartitionHeightAtt[ 0 ][ 0 ] * heightRatio for ( j = 1; j <NumPartitionRowsAtt[ 0 ] - 1; j++ ) { PartitionPosYAtt[ attrldx ][ j J = PartitionPosYAtt[ attrld x ] [ j - 1 ] + PartitionHeightAtt[ attrldx ][ j - 1 ] PartitionHeightAtt[ attrldx ] [ j ] = PartitionHeightAtt[ 0 ][ j ] * heightRatio } } if ( NumPartitionRowsAtt[ 0 ] >1 ) { lastindex = NumPartitionRowsAtt[ 0 ] - 1 PartitionPosYAtt[ attrldx ][ lastindex ] = PartitionPosYAtt[ attrldx ][ lastindex - 1 ] + PartitionHeightAtt[ attrldx ] [ lastindex 1 ] PartitionHeightAtt[ attrldx ][ lastindex ] = asve_attribute_frame_height[ attrldx ] PartitionPosYAtt[ attrldx ][ NumPartitionRowsAtt[ attrldx ] - 1 ] } } Whatever the consistency mode, the locations of the attribute tile partitions for attributes with index greater than 0 are derived from the locations of the attribute tile partitions of the attribute with index 0, as follows: for ( attrldx = 1; attrldx <asve num attribute video; attrldx++ ) { for ( i = 0; i < afati num tiles in atlas frame minusl[ 0 ] + 1; i++ J { topLeftColumnAttf attrldx ][ i ] = topLeftColumnAtt [ 0 ][ i ] topLeftRowAtt[ attrldx ][ i ] = topLeftRowAtt [ 0 ][ i ] bottomRightColumnAtt[ attrldx ][ i ] = bottomRightColumnAtt[ 0 ][ i ] bottomRightRowAtt[ attrldx ][ i ] = bottomRightRowAtt[ 0 ][ i ] } } The requirements of bitstream conformance as defined in section "Attribute tile partition scanning processes” also apply for inferred tile partitions. The computations of and operations using width Ratio and heightRatio may use floating point arithmetic for fine precision. Generally speaking, a V3C bitstream is structured into V3C units (i.e. a syntax structure containing a header and a payload), each V3C unit having a type indicated in its header part. There are V3C units that can be considered as rather descriptive. These correspond, for example to what is called parameter sets (e.g. Video parameter set (VPS), Sequence Parameter Set (SPS) or Frame Parameter Set (FPS)), volumetric usability information (VUI) or supplemental enhancement information (SEIs), this list being non exhaustive. There are other V3C unit types that can be considered as V3C units dedicated to compressed volumetric data, for example for atlas data, occupancy data, geometry data or attribute data. V-DMC defines additional V3C unit types dedicated to V-DMC bitstream, e.g. for base mesh data. The description of a V3C bitstream starts with a V3C unit having a type V3C_VPS, and one or more parameter sets (e.g. SPS, FPS...) for component bitstreams. Some parameter sets defined in V3C have an extension mechanism to add in the bitstream syntax elements that are codecspecific (e.g. V-PCC or MIV or V-DMC...). Fixing inconsistency on tile information in V3C bitstreams An atlas sequence parameter set may contain a syntax element called vui_parameters. The VUI (Volumetric Usability Information) defines, in the vui_parameters syntax structure, some syntax elements as flags providing information about static or dynamic tile information along a coded volumetric sequence. For example, the syntax elements can be present in vui_parameters: vui_fixed_atlas_tile_structure_flag, vui_fixed_video_tile_structure_flag and vui_constrained_tiles_across_v3c_components_idc to respectively indicate whether all the atlas frames of the current atlas shall have the same tiling structure, whether each video bitstream or sub-bitstream associated with the current atlas has all of its frames having the same tiling structure or not and whether any constraints apply to the sizes of tiles in the atlas sub-bitstream and the video tiles in the video sub-bitstreams respectively. V3C syntax defines atlas_tile_information in atlas frame parameters set whatever the value of the vui_fixed_atlas_tile_structure_flag. This requires indicating a flag in a syntax structure for atlas tile information (e.g. atlas_tile_information) in every atlas frame parameter set even if the tile structure is fixed for all frames of a sequence. When encoder 110 has the knowledge that the tile structure is fixed for all frames of a sequence, it can write syntax structure for this tile information at the atlas sequence parameter set level instead of frame parameter set level. This would avoid repeating the tile information as soon as one parameter of an atlas frame parameter set changes and would save bits for the V3C high level syntax. This also applies to attribute tile information in atlas SPS or FPS extension for V-DMC to save bits for V-DMC high level syntax. In order to indicate where tiling information is indicated in a V3C high level syntax, the atlas SPS may be extended with a syntax element indicating that the atlas SPS contains the tiling information. As well for V-DMC, the attribute tile information can be declared once for the whole sequence in the Atlas SPS for V-DMC extension. This may also be an indication to decoders 170 that this tiling information is stable for a whole sequence. When the atlas tile information (or attribute tile information for V-DMC bitstream) is not stable along time, then the syntax element in the Atlas SPS (or Atlas SPS for V-DMC extension, not represented) is set to a value that indicates decoders that tile information is described at frame parameter set level. In order to avoid possible declaration conflicts at SPS or FPS level, a syntax element may also be defined in the Atlas FPS (or ATLAS FPS for V-DMC extension, not represented), as follows: atlas_sequence_parameter_set_rbsp() { Descriptor ... (existing syntax elements).. aspsvuiparanictcrsp^ u(l) if( aspsvupp ) vui j>arameters() aspstileinformationpresentflag u(l) if (aspstileinformationpresentflag) atlas_tile_information() ... (remaining existing syntax elements).. atlas franic jarameter_set_rbsp() { Descriptor afpsatlasframeparametersetid ue(v) afpsatlassequenceparametersetid ue(v) afpstileinformationpresentflag u(l) if (afps tile information present flag) atlas_frame_tile_information() ... (remaining existing syntax elements).. With the following semantics: asps_tile_information_present_flag when equal to 1 indicates that the atlas tile information is declared at atlas sequence parameter set level (and not at atlas frame parameter set level). This means that the atlas tiling structure is fixed for the frames of the sequence. When it is equal to 0, it indicates that the atlas tile information may be declared at atlas frame parameter set level (and not at atlas sequence parameter set level). This means that the atlas tiling structure may vary between frames of the sequence. afps_tile_information_present_flag when equal to 1 indicates that the atlas tile information is declared at atlas frame parameter set level (and not at atlas sequence parameter set level). This means that the atlas tiling structure may vary between frames of the sequence. When it is equal to 0, it indicates that the atlas tile information is declared at atlas sequence parameter set level (and not at atlas frame parameter set level). This means that the atlas tiling structure is fixed for all frames of the sequence. To avoid any conflict for atlas tile information, preferably these two syntax elements are mutually exclusive. atlas_tile_information is a syntax structure containing the same syntax elements as defined in the atlas_frame_tile_information in MPEG-I Part-5. In a variant, the syntax element in the Atlas SPS may be replaced by the value of the VUI parameter called vui_fixed_atlas_tile_structure_flag. When set to 1, the atlas tile information is declared in the Atlas SPS. When set to 0, the atlas tile information is declared in the Atlas FPS. Similarly for attribute tile information in V-DMC bitstream, a similar variant can be used considering the VUI extension described hereafter. The test in the above modified syntax for atlas SPS could then be changed as: if (asps_vui_parameters_present_flag ==1 AND vui_parameters::vui_fixed_atlas_tile_structure_flag==1) Or may consider both the new syntax element and the VUI parameter: if(asps_tile_information_present_flag==1 OR (asps_vui_parameters_present_flag AND vui_parameters:: vui_fixed_atlas_tile_structure_flag==1)). While we have one syntax element for the (atlas or attribute) tile information, the variants for more flags, can also be used, for example to declare tile partitioning or to declare tile mapping (or both partitioning and mapping) or to declare tile identifiers in SPS or FPS. Preferably, each of these one or more flags in the SPS is mutually exclusive to the same one or more flags in the FPS, this to avoid any conflict in the tile information. Alternatively, the declaration in (atlas or atlas extension for V-DMC) SPS may be considered as a default value that can be temporally overridden by a definition in a FPS (atlas or atlas extension for V-DMC). Extending Volumetric Usability Information (VUD for V-DMC bitstreams To handle attribute tile information in volumetric usability information, it is proposed to extend the syntax of the Volumetric Usability Information (VUI) with additional syntax elements, as follows. In a first variant, the VUI syntax is directly extended with one or more additional flags, for example after the existing flags indicating constraints on tiles. The second flag 512 may be recorded to indicate whether atlas tiles and attribute tiles are consistent across the different attribute video bitstreams. In a variant, providing finer description, several other flags may be defined, for example one per type of information indicated in the tile information: a flag to indicate whether partitioning is consistent, a flag to indicate whether mapping of tiles onto these tile partitions is consistent across bitstreams (this one may be present only if the flag for partitioning is set to a value indicating that the tile partitions is consistent across attribute video bitstreams, e.g. if the second flag 512 is set to “1”) and possibly another flag indicating whether tile identifiers are indicated or not in the tiling information. Another syntax element, for example comprising the second flag 512, can be defined to indicate that tile information is consistent across attribute video bitstreams or sub-bitstreams, for example as follows: vui_parameters() { Descriptor ... (existing VUIparameters) ... vui_tile_restrictions_present_flag u(l) if( vuijile ^restrictions jresent^flag ) { vui_fixed_atlas_tile_structure_flag u(l) vui fixed video tile structure flag ll(l) vui_constrained_tiles_across_v3c_components_idc ue(v) vui_max_num_tiles_per_atlas_minusl ue(v) vui consistent attribute video tiles flag u(l) } ... (remaining existing VUIparameters) ... } Where vui_consistent_attribute_video_tiles_flag represents the second flag 512. For instance, vui_consistent_attribute_video_tiles_flag equal to 1 specifies that tiling information for attributes (or attribute video bitstreams) is consistent across attributes and one instance of atlas_frame_attribute_tile_information is present for a given atlas frame parameter set for V-DMC extension or in the syntax for atlas sequence parameter set V-DMC extension. If vui_consistent_attribute_video_tiles_flag is equal to 0, it indicates that atlas_frame_attribute_tile_information is present for each attribute in an atlas frame parameter set for V-DMC extension or in the syntax for atlas sequence parameter set V-DMC extension. As for embodiments modifying the syntax elements for attribute tile information, finer description can be defined in the VUI to indicate which part(s) of the attribute tile information is consistent across attribute video bitstreams or sub-bitstreams (among 421, 422 or 423). Indeed, while the VUI allows indicating when atlas tiles and video tiles are consistent, it does not offer the possibility to indicate that tiling is consistent across all attribute video bitstreams or sub-bitstreams (and not necessarily with atlas bitstream or sub-bitstream). The first set of flags (for both atlas and attribute consistency) may be indicated only if this set of flags indicates first that parts or whole attribute tile information is consistent across attribute video bitstreams or sub-bitstreams. These flags can be alternative to the syntax elements controlling the presence of tile information in dedicated V3C units, for example the flags in the atlas frame parameter set. However, since VUI is not required for decoding, it may be preferable to keep both, at least when tiling information is declared at frame parameter set level. When declared at sequence parameter set level, (which would be consistent with other flags about tiling in the VUI) they may be omitted and decoder may rely on VUI flags instead. In a second variant (Figure 8), an extension mechanism is introduced as additional syntax elements 820 in the vui_parameters syntax structure 800. This allows inserting additional bitstream characteristics in the bitstreams description that are specific to a volumetric codec (e.g. V-PCC, MIV, V-DMC or other codec...). The vui_parameters syntax structure 800 then contains, preferably at the end (but could be anywhere in the syntax) a flag 821 indicating the presence or not of extension information, as illustrated on Figure 8. When this flag is set to a predetermined value (e.g. a true value), there may be one or more syntax elements indicating whether some codec-specific parameters are present or not (like the example flag 822). Then, when flag 822 is e.g. true, codec-specific VUI parameters is indicated like as represented by the syntax element 823. For example, when codec is V-DMC, the codec-specific VUI may describe constraints on tiling information for attribute video bitstreams or subbitstreams, e.g. the syntax element 823 may comprise the second flag 512 indicating that tiling is consistent across attribute video bitstreams or not. The advantage of this variant is that all VUI remains in the same syntax structure. In a variant, when the flag 822 is e.g. true, the vui_parameters VUI syntax structure 800 further comprises one or more syntax elements for indicating the codec to which codec-specific VUI parameters 823 correspond. The one or more syntax elements allows a bitstream parser determining the syntax of codec-specific VUI parameters 823. The one or more syntax elements may be e.g. a type of the codec, or at least one flag, each flag corresponding to a possible type of codecs. In a third variant, an extension syntax structure for codec-specific VUI is provided outside the VUI syntax. For a given codec, any codec-specific VUI syntax element is indicated in the codec-specific extension of the Atlas Sequence Parameter Set. For example, when considering V-DMC, the codec-specific VUI syntax elements are declared in the atlas sequence parameter set V-DMC extension syntax. As well, for V-PCC (or any other codec), any codec-specific VUI information syntax element may be indicated in the syntax of the Atlas Sequence Parameter Set extension for this given codec. The codec-specific extension of the Atlas Sequence Parameter Set is then updated with a syntax element, for example a flag indicating whether codec-specific VUI syntax elements are present or not. When this flag is set, the codec-specific VUI syntax elements are provided. When not set, it means that no codec-specific VUI syntax elements are available or indicated. For example, in the V-DMC extension for atlas sequence parameter set, a new syntax element is added, for example as a flag called “asve_vui_parameters_present_flag”. Then, depending on the value of this flag, additional VUI syntax elements specific to V-DMC may be indicated: asps vdmc_extension() { Descriptor ... (existingsyntax elements) asvevuiparameterspresentflag u(l) if( asve_vui_parameters_present_flag ) vui vdmc_parameters() ... (existingsyntax elements) An example of V-DMC specific VUI syntax elements (i.e. part of the 5 “vui_vdmc_parameters()” structure) may be the indication on attribute tile constraints (e.g. the second flag 512 indicating that tiling is consistent across attribute video bitstreams or not), or any parameter helping the processes related to decoding, display or other purposes. This variant has the advantage that there is no need to check the codec in use before obtaining the codec-specific VUI syntax elements since they are 10 indicated in a codec-specific syntax structure. In a fourth variant, the codec-specific VUI syntax elements are indicated in the Atlas Sequence Parameter Set, in the codec-specific parts, as illustrated below: atlas_sequence_parameter_set_rbsp() { Descriptor ... (existing syntax elements) if( asps_vui_parameters_present_flag ) vui_parameters() aspsextensionpresent flag u(l) if( asps^extension jresent^flag) { aspsvpccextensionpresentflag ll(I) aspsmivextensionpresentflag u(l) asps_extension_6bits u(6) } if( asps_vpcc_extension_present_flag ) { asps_vpcc_extension() / * Specified in Annex H * / if( aspsvuiparameterspresentflag) vui_vpcc_parameters_() } if( asps_miv_extension_present_flag ) asps_miv_extension() / * Specified in ISO / IEC 23090-12 * / if( asps vui parameters present flag) vui_miv_parameters_() } if( aspsvdnic^^ ) asps_vdmc_extension() / * Specified in ISO / IEC 23090-29 * / if( asps vui parameters present flag) vui_vdmc_parameters_() } ... (existing syntax elements) This has the advantage of parsing all VUI syntax elements when processing the Atlas Sequence Parameter Set and checking the codec in use only once (compared to the second variant). An example of V-DMC specific VUI syntax elements in vui_vdmc_parameters may be the indication on attribute tile constraints (e.g. the second flag 512 indicating that tiling is consistent across attribute video bitstreams or not), or any parameter helping the processes related to decoding, display or other purposes. Advantageously, the vui_parameters, when present in the Atlas SPS, could be declared after the syntax elements for atlas SPS extension. By doing so, the codectype in use would be known and the interpretation of the VUI flags could be based on this specific codec. For example, tiling constraints like vui_constrained_tiles_across_v3c_components_idc could be interpreted as tile constraints between atlas bitstream an attribute video bitstreams (without geometry bistream(s)) when the SPS contains the V-DMC extension and as atlas and all other video bitstreams or sub-bitstream when the V-DMC extension is not present. In the 2nd variant above, it could even replace the explicit indication of the syntax elements 821 or 822 and related tests on their value and could directly provide the type of the codec in use for the interpretation of the syntax elements indicated in the vui_codec_specific_parameters 823. Another possible improvement of V3C bitstream, especially the Atlas SPS, considering that VUI may provide optional or informative parameters, consists in replacing the asps_vui_parameters_present_flag by an indication of the length of the payload of the vui_parameters syntax structure. By doing so, a size equal to 0 is equivalent to asps_vui_parameters_present_flag equals 0 and a non null size indicates the number of bytes (if vui_parameters is byte aligned) or in bits (if vui_parameters is not byte aligned) of the vui_parameters. With this information, a decoder not processing the VUI could easily skip it and save processing time. Example of hardware to carry out steps of the encoding method and / or the decoding method Figure 9 is a schematic block diagram of a computing device 1100 for implementation of one or more embodiments of the present disclosure. The computing device 1100 may be a device such as a micro-computer, a workstation, or a light portable device. The computing device 1100 comprises a communication bus 1102 connected to: - a central processing unit (CPU) 1104, such as a microprocessor; - a random access memory (RAM) 1108 for storing the executable code of the method of embodiments of the present disclosure as well as the registers adapted to record variables and parameters necessary for implementing the method for encapsulating, indexing, de-encapsulating, and / or accessing data, the memory capacity thereof can be expanded by an optional RAM connected to an expansion port for example; - a read only memory (ROM) 1106 for storing computer programs for implementing embodiments of the present disclosure; - a network interface 1112 that is, in turn, typically connected to a communication network 1114 over which digital data to be processed are transmitted or received. The network interface 1112 can be a single network interface, or composed of a set of different network interfaces (for instance wired and wireless interfaces, or different kinds of wired or wireless interfaces). Data are written to the network interface for transmission or are read from the network interface for reception under the control of the software application running in the CPU 1104; - a user interface (UI) 1116 for receiving inputs from a user or to display information to a user; - a hard disk (HD) 1110; and / or - an I / O module 1118 for receiving / sending data from / to external devices such as a video source or display. The executable code may be stored either in read only memory 1106, on the hard disk 1110 or on a removable digital medium for example such as a disk. According to a variant, the executable code of the programs can be received by means of a communication network, via the network interface 1112, in order to be stored in one of the storage means of the communication device 1100, such as the hard disk 1110, before being executed. The central processing unit 1104 is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to embodiments of the present disclosure, which instructions are stored in one of the aforementioned storage means. After powering on, the CPU 1104 is capable of executing instructions from main RAM memory 1108 relating to a software application after those instructions have been loaded from the program ROM 1106 or the hard-disc (HD) 1110 for example. Such a software application, when executed by the CPU 1104, causes the steps of the flowcharts shown in the previous figures to be performed. In this embodiment, the apparatus is a programmable apparatus which uses software to implement the methods according to the present disclosure. However, alternatively, the present methods may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). In some embodiments, such computing device 1100 is implemented in the encoder module 110. In some embodiments, such computing device 1100 is implemented in the decoding module 170. Although the present invention has been described hereinabove with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications will be apparent to a person skilled in the art which lie within the scope of the present invention. Many further modifications and variations will suggest themselves to those versed in the art upon making reference to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention, that being determined solely by the appended claims. In particular the different features from different embodiments may be interchanged, where appropriate. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Claims

1. A method for encoding volumetric data into a V-DMC compliant bitstream, in a processing device, the bitstream comprising attribute bitstreams, the method comprising:encoding, in the bitstreams description of the bitstream, a second flag, the second flag having a value indicative whether tiling is consistent or not across the different attribute bitstreams; andencoding, in the bitstreams description, a piece of information representative of at least one tiling structure used for the attribute bitstreams, the piece of information depending on the value of the second flag.

2. The method of claim 1, comprising:checking if a consistent tiling applies onto attributes that are encoded as different attribute bitstreams; and if a consistent tiling does apply onto the different attribute bitstreams:the second flag is encoded with a value indicative that tiling is consistent across the different attribute bitstreams during said encoding the second flag; andthe piece of information encoded during said encoding a piece of information is representative of the tiling structure used across the different attribute bitstreams.

3. The method of claim 1 or 2, wherein, when the piece of information encoded during said encoding a piece of information is representative of the tiling structure used across the different attribute bitstreams, the piece of information comprises:a single attribute tile information common to the different attribute bitstreams; or a single configuration comprising at least partitions, tile positions and sizes common to the different attribute bitstreams.

4. The method of any of the claims 1 to 3, comprising:checking if a consistent tiling applies onto attributes that are encoded as different attribute bitstreams; and if the consistent tiling does not apply onto different attribute bitstreams:the second flag is encoded with a value indicative that tiling is not consistent across the different attribute bitstreams during said encoding the second flag; andthe piece of information encoded during said encoding a piece of information is representative of different attribute tile information for each attribute bitstreams.

5. The method of any of the claims 2 to 4, comprising:checking if tiling applies to the compression of the volumetric data; and, if tiling does apply to the compression of the volumetric data:encoding in the bitstreams description a first flag, the first flag having a value indicative that tiling information is available for attribute bitstreams in the bitstreams description,executing said checking if a consistent tiling applies onto attributes that are encoded as different attribute bitstreams.

6. The method of any of the claims 2 to 5, comprising:checking if tiling applies to the compression of the volumetric data; and, if tiling does not apply to the compression of the volumetric data:encoding in the bitstreams description the first flag, the first flag having a value indicative that no tiling information is available for attribute bitstreams in the bitstreams description,said checking if a consistent tiling applies onto attributes that are encoded as different attribute bitstreams being not executed.

7. A method for decoding a V-DMC compliant bitstream into volumetric data in a processing device, the bitstream comprising attribute bitstreams, the method comprising:determining a second flag from a bitstreams description of the bitstream, a value of the second flag being indicative whether tiling is consistent or not across the different attribute bitstreams;determining, depending on the second flag and from the bitstreams description, a piece of information representative of at least one tiling structure used for the attribute bitstreams.

8. The method of claim 7, wherein the value of the second flag is indicative that tiling is consistent across the different attribute bitstreams,wherein the decoded piece of information is representative of the tiling structure used across the different attribute bitstreams.

9. The method of claim 8, wherein the piece of information comprises:a single attribute tile information common to the different attribute bitstreams; or a single configuration comprising at least partitions, tile positions and sizes common to the different attribute bitstreams.

10. The method of any of the claims 7 to 9, comprising:checking if tiling applies to the compression of the volumetric data, wherein it is decided that tiling applies to the compression of the volumetric data if a value of a first flag present in the bitstreams description of the bitstream is indicative that there is tile information encoded in the bitstream or if the first flag is not present in the bitstreams description of the bitstream,wherein said determining a second flag is executed if tiling does apply to the compression of the volumetric data.

11. The method of any of the claims 7 to 10, comprising:checking if tiling applies to the compression of the volumetric data, wherein it is decided that tiling does not apply to the compression of the volumetric data if the value of the first flag present in the bitstreams description of the bitstream is indicative that there is not tile information encoded in the bitstreams description, and wherein said determining a second flag is not executed if tiling does not apply to the compression of the volumetric data.

12. The method of any of the claims 1 to 11, wherein the bitstream further comprises a geometry bitstream, the attribute bitstreams having a tiling structure different from the geometry bitstream.

13. The method of claim 5 or 6, or of claim 10 or 11, wherein the first flag is encoded in the V-DMC extension of the atlas frame parameter set of the bitstreams description.

14. The method of any of the claims 1 to 13, wherein the second flag is encoded in the V-DMC extension of the Atlas frame parameter set or in the V-DMC atlas frame attribute tile information comprised in atlas frame parameter set of the bitstreams description.

15. The method of any of the claims 1 to 14, wherein the second flag is encoded in a Volumetric Usability Information of the bitstreams description.

16. The method of any of the claims 1 to 14, wherein the second flag is encoded in a syntax structure specifically dedicated to a V-DMC codec in the Volumetric Usability Information.

17. The method of any of the claims 1 to 14, wherein the second flag is encoded in a syntax structure specifically dedicated to a V-DMC codec of an Atlas Sequence Parameter Set of the bitstreams description.

18. The method of any of the claims 1 to 14, wherein the second flag is encoded in a codec-specific part of an Atlas Sequence Parameter Set of the bitstreams description.

19. A computer program product for a programmable apparatus, the computer program product comprising instructions for carrying out the steps of the method according to any one of claims 1 to 18 when the program is loaded and executed by a programmable apparatus.

20. A non-transitory computer-readable storage medium storing instructions of a computer program for implementing the steps of the method according to any one of claims 1 to 18.

21. A processing device comprising a processing unit configured for carrying out the steps of the method according to any one of claims 1 to 18.

Images