EP4140136A1 - Procédés et dispositifs de codage et de décodage d'une séquence vidéo multi-vues - Google Patents

Procédés et dispositifs de codage et de décodage d'une séquence vidéo multi-vues

Info

Publication number
EP4140136A1
EP4140136A1 EP21721150.7A EP21721150A EP4140136A1 EP 4140136 A1 EP4140136 A1 EP 4140136A1 EP 21721150 A EP21721150 A EP 21721150A EP 4140136 A1 EP4140136 A1 EP 4140136A1
Authority
EP
European Patent Office
Prior art keywords
patch
transformation
atlas
data stream
decoded
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP21721150.7A
Other languages
German (de)
English (en)
Inventor
Félix Henry
Joël JUNG
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP4140136A1 publication Critical patent/EP4140136A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/59—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial sub-sampling or interpolation, e.g. alteration of picture size or resolution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/85—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression

Definitions

  • the invention relates to so-called immersive videos, representative of a scene captured by one or more cameras. More particularly, the invention relates to the encoding and decoding of such videos.
  • the scene is conventionally captured by a set of cameras, as illustrated in figure 1.
  • These cameras can be of 2D type (cameras Ci, C 2 , C 3 , C 4 in FIG. 1), or type 360, ie capturing the entire scene at 360 degrees around the camera (camera C5 in FIG. 1).
  • one or more views are calculated from the decoded views.
  • FIG. 2 illustrates an example of a coding-decoding system using such a selection of data from the multi-view video making it possible to synthesize intermediate views on the decoder side.
  • one or more basic views are encoded by a 2D encoder, for example an HEVC type encoder, or by a multi-view encoder.
  • the other views (T s , D s ) undergo a processing which makes it possible to extract certain zones from each of these views.
  • the extracted areas also called patches hereafter, are gathered in images called atlases.
  • the atlases are coded for example by a conventional 2D video coder, for example a HEVC coder.
  • the atlases are decoded, providing the decoded patches to the view synthesis algorithm to produce intermediate views from the base views and decoded patches.
  • the patches make it possible to transmit the same area seen from another point of view.
  • the patches make it possible to transmit the occlusions, that is to say the parts of the scene which are not visible from a given view.
  • the MIV system (MPEG-I part 12) in its reference implementation (TMIV for “Test Model for Immersive Video”) generates atlases formed from a set of patches.
  • Figure 3 illustrates an example of extracting patches (Patch2, Patch5, Patch8, Patch3, Patch7) from views (V 0 , Vi, V) and the creation of associated atlases, for example two atlases A 0 and Ai .
  • These atlases A 0 and Ai each comprise an image of texture T 0 , Ti and a corresponding depth map D 0, Di.
  • the atlas A 0 comprises a texture T 0 and a depth D 0
  • the atlas comprises a texture Ti and a depth Di.
  • the patches are gathered in images and coded by a conventional 2D video coder.
  • it is necessary to have an optimal arrangement of the patches in the atlases.
  • it is necessary not only to reduce the cost of compressing such patches, but also the number of pixels. to be processed for the decoder.
  • the devices for rendering such videos have more limited resources than the devices for encoding such videos.
  • the invention improves the state of the art. For this purpose, it relates to a method of decoding a coded data stream representative of a multi-view video, said coded data stream comprising coded data representative of at least one atlas, said at least one atlas corresponding to an image comprising at least one patch, said at least one patch corresponding to a set of pixels extracted from at least one component of a view of the multi-view video, said view not being encoded in said encoded data stream .
  • the decoding process includes:
  • the invention also relates to a method of encoding a data stream representative of a multi-view video, the encoding method comprises:
  • the invention also makes it possible to apply transformations to the patches of an atlas which are different from one patch to another, or which possibly have different parameters.
  • the arrangement of patches in an atlas is thus optimized for compression.
  • the transformations used for the patches of the atlas make it possible, on the one hand, to optimize the occupation rate of the pixels of the atlas, by using transformations such as rotation, subsampling in coding so as to arrange the patches within the atlas image.
  • the transformations make it possible to optimize the cost of compressing the patches, in particular by modifying the pixel values of these patches, for example by reducing the dynamics of the pixels, by sub-sampling, which leads to coding fewer pixels, or even by using an optimal arrangement of the patches in the atlas image making it possible to have as few pixels as possible to code.
  • the reduction in the occupation rate of the pixels of the atlas also makes it possible to reduce the rate of pixels to be processed by the decoder, and therefore to reduce the complexity of the decoding.
  • it is determined whether a transformation must be applied to said at least one patch decoded from at least one syntax element decoded from said coded data stream for said at least one patch .
  • a syntax element is explicitly coded in the data stream to indicate whether a transformation must be applied to the decoded patch and which transformation to apply.
  • said at least one decoded syntax element comprises at least one indicator indicating whether a transformation must be applied to said at least one patch and whether the indicator indicates that a transformation must be applied said at least one patch, said at least one syntax element optionally comprises at least one parameter of said transformation.
  • the transformation to be applied to the patch is coded in the form of an indicator indicating whether a transformation must be applied to the patch or not, and in the positive case, optionally the parameter (s) of the transformation to apply.
  • a binary flag can indicate whether a transformation should be applied to the patch, and if so, a code indicating which transformation is used, and possibly one or more parameters of the transformation, such as scale factor, function of modification of the dynamics of the pixels, angle of rotation, etc ...
  • the transformation parameters can be defined by default at the encoder.
  • said at least one parameter of said transformation to be applied to said patch has a value which is encoded by prediction with respect to a prediction value.
  • the prediction value is encoded in a header of a view, or of a component of the atlas or of the atlas.
  • the prediction value corresponds to the value of a parameter of a transformation applied to a patch belonging to the group comprising:
  • the determination, for said at least one decoded patch, whether a transformation must be applied to said at least one decoded patch is carried out if a syntax element decoded from a header of the data stream indicates an activation of the application of transformations to the patches encoded in the data stream, said syntax element being encoded in a header of a view or of a component of a view or of said atlas.
  • a high level syntax element is encoded in the data stream to indicate the use of transformations to be applied to the patches of the multi-view video.
  • a transformation must be applied to said at least one decoded patch if a characteristic of said decoded patch meets a criterion.
  • the indication of the use of a transformation to be applied to the patch is not coded explicitly in the data stream. Such an indication is inferred from a characteristic of the decoded patch. This particular embodiment of the invention allows the use of patch transformations without incurring additional coding cost to signal the use of transformations.
  • the characteristic corresponds to an energy E calculated from the value of the pixels of said at least one decoded patch, the transformation to be applied to said at least one patch corresponding to a multiplication of the value of said pixels by a determined factor, when the energy E is less than a threshold.
  • an order in which said transformations must be applied is predefined. According to this particular embodiment of the invention, no signaling is necessary to indicate the order in which the transformations are applied. This order is defined at the encoder and at the decoder and remains the same for all the patches to which these transformations apply.
  • the invention also relates to a device for decoding an encoded data stream representative of a multi-view video, said encoded data stream comprising encoded data representative of at least one atlas, said at least one atlas corresponding to an atlas. image comprising at least one patch, said at least one patch corresponding to a set of pixels extracted from at least one component of a view of the multi-view video, said view not being encoded in said encoded data stream, the decoding device comprising a processor and a memory configured for:
  • such a device is included in a terminal.
  • the invention also relates to a device for encoding a data stream representative of a multi-view video, comprising a processor and a memory configured for:
  • such a device is included in a terminal.
  • the coding method, and respectively the decoding method according to the invention can be implemented in various ways, in particular in wired form or in software form.
  • the coding method, respectively the decoding method is implemented by a computer program.
  • the invention also relates to a computer program comprising instructions for implementing the coding method or the decoding method according to any one of the particular embodiments described above, when said program is executed by a processor.
  • Such a program can use any programming language. It can be downloaded from a communications network and / or recorded on a computer readable medium.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other. desirable form.
  • the invention also relates to a recording medium or information medium readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the aforementioned recording media can be any entity or device capable of storing the program.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, a USB key, or else a magnetic recording means, for example a hard disk.
  • the recording media can correspond to a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can in particular be downloaded from an Internet type network.
  • the recording media can correspond to an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • FIG. 1 schematically illustrates an example of a system for capturing a multi-view of a scene.
  • FIG. 2 schematically illustrates an example of a multi-view coder based on the coding of patches.
  • Figure 3 illustrates an example of patch extraction and atlas creation.
  • FIG. 4 illustrates steps of a coding method according to a particular embodiment of the invention.
  • FIG. 5 illustrates steps of a decoding method according to a particular embodiment of the invention.
  • FIG. 6 illustrates an example of data flow according to a particular embodiment of the invention.
  • FIG. 7 illustrates an example of the architecture of a coding device according to a particular embodiment of the invention.
  • FIG. 8 illustrates an example of the architecture of a decoding device according to a particular embodiment of the invention.
  • FIG. 4 illustrates the steps of a method for encoding a multi-view video in at least one encoded data stream according to a particular embodiment of the invention.
  • the multi-view video is encoded according to an encoding scheme as presented in relation to FIG. 2 in which one or more so-called basic views are encoded in the data stream and in which sub-images or Patches comprising texture and depth data are also encoded in the data stream. These patches come from additional views which are not fully encoded in the data stream. Such patches and one or more basic views allow the decoder to synthesize other views of the scene, also called virtual views, or synthesized views or even intermediate views thereafter. These summary views were not encoded in the data stream. The steps of such a coding scheme relating to a particular embodiment of the invention are described below.
  • the scene is captured by a set of cameras Ci, C 2 , ..., C N as in FIG. 1.
  • Each camera generates a view, comprising at least one so-called texture component which varies during time.
  • the texture component of a view is a sequence of 2D images corresponding to the images captured by the camera placed at the viewpoint of the view.
  • Each view also includes a depth component, called the depth map, which is determined for each image in the view.
  • the depth map can be generated in a known manner by estimating the depth using the texture, or by capturing volumetric data of the scene using devices using Lidar technology for "Light detection and Ranging". in English.
  • view will be used to indicate a sequence of texture images and depth maps representative of the scene captured from a point of view.
  • view can also correspond to a texture image and a depth map of a view at a given time.
  • the encoder then proceeds to the steps which are described below, for example according to the encoding scheme defined in Base I Salahieh, Bart Kroon, Joe I Jung, Marek Domanski, Test Model 4 for Immersive Video, ISO / IEC JTC 1 / SC 29 / WG 11 N19002, Brussels, BE - January 2020.
  • one or more so-called base views are selected from the captured views of the multi-view video.
  • the base views are selected from the set of captured views of the multi-view video by known means. For example, spatial subsampling can be done to select every other view. In another example, the content of the views can be used to determine which views are to be kept as base views. In yet another example, the camera settings (position, orientation, focal length) can be used to determine which views to select as base views. At the end of step E40, a number of views are selected to be base views.
  • a “pruning” method is applied to the additional views to identify for each additional view one or more patches to be transmitted to the decoder.
  • This step makes it possible to determine the patches to be transmitted by extracting from the images of additional views the areas necessary for the synthesis of intermediate views. For example, such zones correspond to occlusion zones not visible in the basic views, or else to visible zones having undergone a change in illumination, or even having a lower quality in the basic views.
  • the extracted areas are of arbitrary size and shape.
  • a group of pixels connected to their neighbors is carried out to create from zones extracted from the same view one or more rectangular patches easier to code and to arrange.
  • the encoder determines one or more transformation (s) which will be applied to the patch when it is arranged in an atlas.
  • the patches can be patches comprising a texture component and / or a depth component.
  • the patches are arranged in the atlases so as to minimize the cost of coding the atlases and / or reduce the number of pixels to be processed by the decoder.
  • the patches can undergo transformations, among which:
  • the encoder then goes through each patch and determines one or more transformations to apply to the patch.
  • an “identity” transformation in other words no transformations, can also be included in the list of transformations to be tested for the patch.
  • the selection of a transformation among the possible transformations can be made by evaluating a rate-distortion criterion calculated on the reconstructed signal using the rate necessary to encode the transformed patch and the distortion calculated between the original patch. and the transformed patch coded then reconstructed. The selection can also be made based on the evaluation of the quality of the additional view synthesized using the patch being processed.
  • the factors Nv, Nh, and Ne can be tested.
  • the factors Nv, Nh, and Ne are equal to 2. In other embodiments, other values are possible, such as 4, 8 or 16.
  • mapping The transformation corresponding to a modification of the values of the pixels is also called a “mapping” in English.
  • Such a mapping transformation can for example consist in dividing all the values of the pixels of the patch by a given value Dv.
  • Dv is 2.
  • other values are possible, such as 4, 8, or 16.
  • the parameter P of the transformation is then a list of triples (x1, a, b) for each linear part of the mapping.
  • the mapping can also be a LUT (“LookUp Table”) which is an array associating a value y with an input x.
  • LUT LookUp Table
  • the determination of a transformation associated with a patch can also take into account the number of atlases available to encode the multi-view video and simulate the arrangement of the patches in the atlases in order to optimize the bit rate / coding distortion cost of the atlases. atlas or the quality of the synthesis of intermediate views in a global way.
  • step E42 a list of transformed patches is available. Each patch is associated with the transformation (s) determined for this patch and the associated parameters.
  • the patches are arranged in one or more atlases.
  • the number of atlases depends for example on parameters defined on input to the encoder which are in particular the size of an atlas (length and height) and the maximum number M of pixels for the texture and depth of all the atlases per image or instant given. This maximum number M corresponds to the number of pixels to be processed for the decoder for an instant of the multi-view video.
  • each base view is encoded in an atlas comprising a patch comprising a texture component and a depth component of the base view at a given instant. According to this particular mode, there are then as many atlases as there are base views and as many atlases as necessary to transport all the patches extracted from the additional views.
  • an atlas may include a base view and patches, or a base view may be clipped and represented on multiple atlases if the view size is larger than the size of an atlas.
  • a patch of an atlas can then correspond to an entire image of a base view or to a part of a base view or to an area extracted from an additional view.
  • the texture pixels of the patches are arranged in the texture component of an atlas and the depth pixels of the patches are arranged in the depth component of an atlas.
  • An atlas may only have a single texture or depth component, or it may include a texture component and a depth component.
  • an atlas can also include other types of component including information useful for the synthesis of intermediate views.
  • other types of components may include information such as a reflectance index, to indicate how transparent the corresponding area is, or even confidence information about the depth value at that location.
  • the coder goes through all the patches in the patch list. For each patch, the encoder determines in which atlas this patch will be encoded. This list includes processed patches and unprocessed patches. Untransformed patches are either patches comprising areas extracted from additional views that have not undergone any transformation or identity transformation, or patches comprising base view images. It is considered here that when the patch must undergo a transformation, it has already been transformed.
  • An atlas is a set of spatially rearranged patches in an image. This image is intended to be encoded. This arrangement is intended to occupy the space in the atlas images to be encoded as well as possible. Indeed, one of the objectives of video coding is to minimize the number of pixels to be decoded before being able to synthesize a view. For this, the patches are arranged in the atlases so as to maximize the number of patches in an atlas. Such a method is described in Base I Salahieh, Bart Kroon, Jo ⁇ l Jung, Marek Domanski, Test Model 4 for Immersive Video, ISO / IEC JTC 1 / SC 29 / WG 11 N 19002, Brussels, BE - January 2020.
  • step E43 a list of patches for each atlas is generated. It should be noted that this arrangement also determines the number of atlases to be coded for a given moment.
  • each atlas which includes a texture component and / or a depth component in the form of a 2D image is encoded using a conventional video encoder such as HEVC, VVC, MV- HEVC, 3D-HEVC, etc.
  • a conventional video encoder such as HEVC, VVC, MV- HEVC, 3D-HEVC, etc.
  • the base views are considered here as patches.
  • the coding of atlases therefore involves the coding of the basic views.
  • the information associated with each atlas is encoded in the data stream.
  • This information is conventionally encoded by an entropy encoder.
  • the patch list includes the following, for each patch in the list:
  • step E45 for at least several patches of the atlas, information relating to the transformations to be applied to the patch during decoding is encoded in the data stream.
  • the transformations to be applied to the patch during decoding correspond to the inverse transformations applied to the patch when arranging the patch in the atlas and determined above.
  • each patch information indicating the transformation to be applied is transmitted.
  • the transformation to be applied to the decoding which is indicated and not the transformation applied to the encoding (corresponding to the inverse transformation of the decoding).
  • the information transmitted on the transformation to be applied may correspond to information indicating the transformation applied to the coding, the decoder then deducing the transformation to be applied from this information.
  • the information indicating the transformation to be applied can be an index indicating the transformation to be applied in a list of possible transformations.
  • a list can further include an identity transformation.
  • an index indicating the identity transformation can thus be encoded.
  • a binary indicator can be coded to indicate whether the patch is transformed or not, and if the binary indicator indicates that the patch has been transformed, an index indicating the transformation to be applied in the list of possible transformations is coded. .
  • only the binary indicator can be coded to indicate whether the patch is transformed or not.
  • the list of possible transformations can be known to the decoder and therefore does not need to be transmitted in the data stream. In other embodiments, the list of possible transformations can be coded in the data stream, for example in a header of a view or of the multi-view video.
  • the parameters associated with the transformations to be applied can also be defined by default and known to the decoder.
  • the parameters associated with a transformation applied to the patch are encoded in the data stream for each patch.
  • the parameter associated with the transformation can correspond to a value of an interpolation to be applied for all the dimensions or a value of an interpolation to apply for each of the dimensions.
  • the parameters of this transformation correspond to the characteristics of the mapping to be applied: parameters of a linear function, piecewise linear , Look-up Table (LUT), ....
  • LUT Look-up Table
  • the possible LUT (s) can be known to the decoder.
  • the parameter corresponds to the angle of rotation selected from among the possible rotations.
  • the parameters associated with a transformation can be encoded as they are or else by prediction with respect to a prediction value.
  • a prediction value can be defined and encoded in the data stream in a header of a view, or of a component, or of an image of a view. , or an atlas including the current patch.
  • the P value of a parameter will be predicted by a Ppred value encoded at the level of the atlas.
  • the difference between Ppred and P is then coded for each patch in the atlas.
  • the prediction value Ppred can correspond to the value of the parameter used for a patch previously processed.
  • it can be the previous patch in the patch processing order, or the previous patch belonging to the same view as the current patch.
  • the prediction value of the parameter can also be obtained by a mechanism similar to the “Merge” mode (merged in French) of an HEVC type encoder.
  • For each patch a list of candidate patches is defined and an index pointing to one of these candidate patches is coded for the patch.
  • it is not necessary to transmit an index a criterion being able to be used to identify the patch among the list of candidate patches.
  • the information indicating whether the patch must undergo a transformation can be decomposed into a part which indicates the use of the transformation (for example a binary flag) and a part which indicates the parameters of the transformation. , if usage is enabled.
  • This signaling mechanism can be used independently for each possible transformation for the patch.
  • a binary indicator can be coded at the level of a header of an atlas, or of a view or of a component, to activate the use of a determined transformation for the patches of this atlas, of this view or of this component.
  • the application of the transformation determined for a patch then depends on the value of this binary indicator.
  • two binary indicators U and I B associated respectively with the activation of a transformation A and with the activation of a transformation B are encoded in a header of an atlas.
  • the value of the binary indicator indicates that the use of transformation A is possible, while the value of the binary indicator I B indicates that the use of transformation B is not possible.
  • a binary indicator will indicate whether transformation A is applied to the patch, and possibly the associated parameters. It is not necessary in this example to code for each patch a binary indicator to indicate whether the transformation B is applied to the patch.
  • an atlas can comprise a patch for which a determined transformation can be applied as a function of the indicator coded for this patch and a patch for which the same transformation cannot be applied.
  • no indicator for this transformation is encoded in the patch information.
  • no information indicating a transformation is coded at the patch level. This is deduced at the decoder from a characteristic of the patch. The transformation is then applied to the patch as soon as it meets a certain criterion. This particular mode will be described in more detail below in relation to the decoding method.
  • FIG. 5 illustrates the steps of a method for decoding an encoded data stream representative of a multi-view video according to a particular embodiment of the invention.
  • the encoded data stream was generated by the encoding method described in relation to FIG. 4.
  • the atlas information is decoded. This information is conventionally decoded by a suitable entropy decoder.
  • this information can be an index indicating a transformation among a list of possible transformations, or else for each possible transformation, an indicator indicating whether the transformation must be applied to the patch.
  • the information may correspond to a binary indicator indicating the use of the transformation or a value of an interpolation to be applied for all dimensions.
  • the information may correspond to a binary indicator indicating the use of the transformation or for each of the dimensions a value of an interpolation to apply.
  • the information may include information indicating the use of the mapping, and possibly information representative of the characteristics of the mapping to be applied. (parameters of a linear function, piecewise linear, Look-up Table, ).
  • the parameter will indicate which rotation has been selected among the possible rotations.
  • the information transmitted making it possible to identify a transformation to be applied to the patch is decoded in a manner suited to the coding applied. Thus, it can be decoded as is (direct decoding) or in a predictive manner, in a manner similar to the encoder.
  • the information making it possible to identify a transformation to be applied to the patch can comprise a part which indicates the use of the transformation (binary indicator) and a part which indicates the parameters of the transformation. , if usage is enabled.
  • the decoding for a given patch of information identifying a transformation to be applied to the patch may depend on a binary activation indicator encoded at the header of the atlas, sight or component to which the patch belongs.
  • the information identifying a transformation to be applied to the patch is not encoded with the information of the patch, but derived from the characteristics of the decoded patch.
  • Dv a determined factor for modifying the patch values.
  • the patch is interpolated by a determined factor, for example a factor of 2 in the vertical dimension.
  • the patch dimensions considered here are the patch dimensions decoded from information from the atlas in which the patch was encoded. These are therefore the dimensions of the patch before transformation at the decoder (and therefore after transformation at the encoder).
  • This variant makes it possible to mix in the same atlas "long” patches for which it is not interesting to do a sub-sampling and "long” patches for which one sub-samples without signaling, which makes them respect the criterion. which allows them to interpolate to the decoder.
  • Other threshold values can be used, for example more restrictive values like 0.9 ⁇ H / W ⁇ 1.1.
  • each atlas which includes a 2D texture component and / or a 2D depth component, is decoded using a conventional video decoder such as AVC or HEVC, VVC, MV-HEVC, 3D-HEVC, etc.
  • the decoded patches are reconstructed by applying the transformation identified during step E50 to the texture component and / or to the depth component of each patch in its atlas depending on whether the transformation applies to texture, depth or both components.
  • this step consists of individually modifying each patch by applying the transformation identified for this patch. This can be done in different ways, for example: by modifying the pixels of the patch in the atlas that contains it, by copying the modified patch in a buffer memory area, or by copying the transformed patch in the view associated with it. .
  • each patch to be reconstructed can have one of the following transformations applied:
  • the transmitted mapping parameters can be either the encoder mapping parameters (and then the decoder will have to apply the inverse mapping function), or the decoder mapping parameters (and then the encoder will have to apply the inverse mapping function).
  • the encoder it is possible to apply to the encoder several transformations to a patch. These transformations are signaled in the stream in the information encoded for the patch or else deduced from the characteristics of the decoded patch. For example, it is possible to apply to the encoder a downsampling by a factor of 2 in each dimension of the patch, followed by a mapping of the pixel values of the patch, then a rotation.
  • the order of the transformations to be applied is predefined and known to the encoder and to the decoder. For example, the encoder order is as follows: rotation, then downsampling, then mapping.
  • step E52 a set of reconstructed patches is available.
  • At least one intermediate view is synthesized using at least one basic view and at least one patch reconstructed previously.
  • the chosen virtual view synthesis algorithm is applied to the decoded and reconstructed data from the multi-view video that has been transmitted to the decoder. As explained previously, this algorithm relies on the pixels of the components of the base views and patches to produce a view from a point of view between the cameras.
  • the synthesis algorithm uses at least two textures and two depth maps, taken from base views and / or additional views to generate an intermediate view.
  • Synthesizers are known and belong, for example, to the DIBR (“Depth Image Based Rendering”) category.
  • DIBR Depth Image Based Rendering
  • algorithms frequently used by standards organizations are:
  • the RVS for "Reference View Synthesizer” in English, initiated by the University of Brussels and improved by Philips begins by projecting the reference views using a calculated disparity.
  • the references are partitioned into triangles, and distorted. Then the deformed views of each reference are mixed (“blending” in English), then a basic “inpainting” type filling is applied to fill the dis-occlusions;
  • VVS VVS for “Versatile View Synthesizer” in English, developed by Orange, sorts the references, applies a deformation of certain information from the depth maps, then a conditional fusion of these depths. Then a backward warping of the textures is applied, then a fusion different textures and different depths. Finally, a spatio-temporal “inpainting” type filling is applied, before spatial filtering of the intermediate image.
  • FIG. 6 illustrates an example of a data stream according to a particular embodiment of the invention and in particular the atlas information encoded in the stream and making it possible to identify one or more transformations to be applied to the patches of the atlas.
  • the data stream was generated according to the encoding method according to any one of the particular embodiments described in relation to FIG. 4, and it is suitable for being decoded by the decoding method according to any one. particular embodiments described in relation to FIG. 5.
  • such a flow comprises in particular:
  • the patch information and in particular a Trf indicator indicating whether or not the transformation is used for the patch,
  • a Par parameter of the transformation for example in the form of a residue obtained with respect to the prediction value Ppred, when the latter is encoded.
  • FIG. 7 shows the simplified structure of a COD coding device suitable for implementing the coding method according to any one of the particular embodiments of the invention.
  • the steps of the coding method are implemented by computer program instructions.
  • the coding device COD has the conventional architecture of a computer and comprises in particular a memory MEM, a processing unit UT, equipped for example with a processor PROC, and controlled by the computer program PG stored in MEM memory.
  • the PG computer program comprises instructions for implementing the steps of the encoding method as described above, when the program is executed by the processor PROC.
  • the code instructions of the computer program PG are for example loaded into a RAM memory (not shown) before being executed by the processor PROC.
  • the processor PROC of the processing unit UT notably implements the steps of the coding method described above, according to the instructions of the computer program PG.
  • FIG. 8 shows the simplified structure of a decoding device DEC suitable for implementing the decoding method according to any one of the particular embodiments of the invention.
  • the decoding device DEC has the conventional architecture of a computer and notably comprises a MEMO memory, a UTO processing unit, equipped for example with a PROCO processor, and controlled by the PGO computer program stored in MEMO memory.
  • the computer program PGO comprises instructions for implementing the steps of the decoding method as described above, when the program is executed by the processor PROCO.
  • the code instructions of the computer program PGO are for example loaded into a RAM memory (not shown) before being executed by the processor PROCO.
  • the processor PROCO of the processing unit UTO notably implements the steps of the decoding method described above, according to the instructions of the computer program PGO.

Abstract

L'invention concerne un procédé de codage et un procédé de décodage d'un flux de données codées représentatif d'une vidéo multi-vues. Le flux de données codées comprend des données codées représentatives d'au moins un atlas, ledit au moins un atlas correspondant à une image comprenant au moins un patch, ledit au moins un patch correspondant à un ensemble de pixels extraits d'au moins une composante d'une vue de la vidéo multi-vues, ladite vue n'étant pas codée dans ledit flux de données codées. Le procédé de décodage comprend notamment le décodage, à partir dudit flux de données codées, dudit au moins un atlas, comprenant le décodage dudit au moins un patch, la détermination, pour ledit au moins un patch décodé, si une transformation doit être appliquée audit au moins un patch décodé, et quelle transformation, ladite transformation appartenant au groupe de transformations comprenant au moins un sur-échantillonnage du patch ou une modification des valeurs de pixels du patch, et l'application de la transformation déterminée audit patch décodé.

Description

DESCRIPTION
Titre: Procédés et dispositifs de codage et de décodage d'une séquence vidéo multi- vues
1. Domaine de l'invention
L'invention concerne les vidéos dites immersives, représentatives d'une scène capturée par une ou plusieurs caméras. Plus particulièrement, l'invention concerne le codage et le décodage de telles vidéos.
2. Art Antérieur
Dans un contexte de vidéo immersive, c’est à dire où le spectateur a la sensation d’être immergé dans la scène, la scène est classiquement capturée par un ensemble de caméras, telle qu'illustrée en figure 1. Ces caméras peuvent être de type 2D (caméras Ci, C2, C3, C4 de la figure 1), ou de type 360, c’est à dire capturant toute la scène à 360 degrés autour de la caméra (caméra C5 de la figure 1 ).
L’ensemble de ces vues capturées sont traditionnellement codées, puis décodées par un terminal du spectateur. Néanmoins, afin de fournir une qualité d’expérience suffisante, et donc une qualité visuelle et une bonne immersion dans la scène affichée au spectateur, afficher seulement les vues capturées est insuffisant.
Afin d'améliorer la sensation d'immersion dans la scène, en général, une ou plusieurs vues, dites vues intermédiaires, sont calculées à partir des vues décodées.
Le calcul de ces vues intermédiaires peut être réalisé par un algorithme dit « de synthèse » de vue (« view synthesis algorithm » en anglais).
Classiquement, par exemple dans le système MIV (pour « Metadata for Immersive Video » en anglais) en cours de normalisation, toutes les vues originales, i.e. capturées par des caméras, ne sont pas transmises au décodeur. Une sélection, aussi appelée « pruning » en anglais, des données d’au moins certaines des vues originales, susceptibles d’être utilisées pour synthétiser un point de vue intermédiaire, est réalisée.
La figure 2 illustre un exemple de système de codage-décodage utilisant une telle sélection de données de la vidéo multi-vues permettant de synthétiser des vues intermédiaires côté décodeur.
Selon cette méthode, une ou plusieurs vues de base (T , Dbsur la figure 2) sont codées par un codeur 2D, par exemple un codeur de type HEVC, ou par un codeur multi-vues.
Les autres vues (Ts, Ds) subissent un traitement qui permet d’extraire certaines zones de chacune de ces vues. Les zones extraites, aussi appelées patchs par la suite sont rassemblées dans des images appelées atlas. Les atlas sont codés par exemple par un codeur vidéo classique 2D, par exemple un codeur HEVC. Côté décodeur, les atlas sont décodés, fournissant les patchs décodés à l'algorithme de synthèse de vue pour produire des vues intermédiaires à partir des vues de base et des patchs décodés. Globalement, les patchs permettent de transmettre la même zone vue d’un autre point de vue. En particulier, les patchs permettent de transmettre les occlusions, c’est-à-dire les parties de la scène qui ne sont pas visibles depuis une vue donnée.
Le système MIV (MPEG-I part 12) dans son implémentation de référence (TMIV pour « Test Model for Immersive Video » en anglais) génère des atlas formés d’un ensemble de patchs. La figure 3 illustre un exemple d’extraction de patchs (Patch2, Patch5, Patch8, Patch3, Patch7) à partir de vues (V0, Vi, V ) et la création d’atlas associés, par exemple deux atlas A0 et Ai. Ces atlas A0 et Ai comprennent chacun une image de texture T0, Ti et une carte de profondeur D0, Di correspondante. L’atlas A0 comprend une texture T0 et une profondeur D0, et l’atlas comprend une texture Ti et une profondeur Di.
Comme expliqué avec la figure 2, les patchs sont rassemblés dans des images et codés par un codeur vidéo 2D classique. Afin d’éviter les surcoûts de signalisation et de codage des patchs extraits, il est nécessaire d’avoir un arrangement optimal des patchs dans les atlas. De plus, au vu de la grande quantité d’informations à traiter par le décodeur pour reconstruire des vues d’une vidéo multi-vues, il est nécessaire non seulement de réduire le coût de compression de tels patchs, mais également le nombre de pixels à traiter pour le décodeur. En effet, dans la plupart des applications, les appareils de restitution de telles vidéos ont des ressources plus limitées que les dispositifs de codage de telles vidéos.
Il existe donc un besoin d'améliorer l'état de la technique.
3. Exposé de l'invention
L'invention vient améliorer l'état de la technique. Elle concerne à cet effet, un procédé de décodage d’un flux de données codées représentatif d'une vidéo multi-vues, ledit flux de données codées comprenant des données codées représentatives d'au moins un atlas, ledit au moins un atlas correspondant à une image comprenant au moins un patch, ledit au moins un patch correspondant à un ensemble de pixels extraits d’au moins une composante d’une vue de la vidéo multi-vues, ladite vue n’étant pas codée dans ledit flux de données codées. Le procédé de décodage comprend :
- le décodage, à partir dudit flux de données codées, dudit au moins un atlas, comprenant le décodage dudit au moins un patch,
- la détermination, pour ledit au moins un patch décodé, si une transformation doit être appliquée audit au moins un patch décodé, et quelle transformation, ladite transformation appartenant au groupe de transformations comprenant au moins un sur-échantillonnage du patch ou une modification des valeurs de pixels du patch,
- l’application de la transformation déterminée audit patch décodé.
Corrélativement, l’invention concerne aussi un procédé de codage d’un flux de données représentatif d'une vidéo multi-vues, le procédé de codage comprend :
- l’extraction à partir d’au moins une composante d’une vue de la vidéo multi- vues non codée dans ledit flux de données, d’au moins un patch correspondant à un ensemble de pixels de ladite composante,
- la détermination pour ledit au moins un patch extrait, si une transformation doit être appliquée audit au moins un patch, et quelle transformation, ladite transformation appartenant au groupe de transformations comprenant au moins un sous-échantillonnage du patch ou une modification des valeurs de pixels du patch,
- l’application audit au moins un patch, de la transformation déterminée,
- le codage d’au moins un atlas dans ledit flux de données, ledit au moins un atlas correspondant à une image comprenant au moins ledit au moins un patch.
Grâce à l’invention, il est ainsi possible d’identifier quels patchs d’un atlas décodé doivent subir une transformation, lors de leur reconstruction. Une telle transformation correspond à la transformation inverse de celle appliquée lors du codage de l’atlas.
L’invention permet également d’appliquer des transformations aux patchs d’un atlas qui sont différentes d’un patch à l’autre, ou qui ont éventuellement des paramètres différents. L’arrangement des patchs dans un atlas est ainsi optimisé pour la compression. En effet, les transformations utilisées pour les patchs de l’atlas permettent d’une part d’optimiser le taux d’occupation des pixels de l’atlas, en utilisant des transformations telles que rotation, sous- échantillonnage au codage de sorte à arranger les patchs au sein de l’image de l’atlas. D’autre part, les transformations permettent d’optimiser le coût de compression des patchs, notamment par la modification des valeurs de pixels de ces patchs, par exemple en diminuant la dynamique des pixels, par le sous-échantillonnage, ce qui conduit à coder moins de pixels, ou encore en utilisant un arrangement optimal des patchs dans l’image de l’atlas permettant d’avoir le moins de pixels à coder possible. La réduction du taux d’occupation des pixels de l’atlas permet également de réduire le taux de pixels à traiter par le décodeur, et donc de réduire la complexité du décodage. Selon un mode particulier de réalisation de l’invention, il est déterminé si une transformation doit être appliquée audit au moins un patch décodé à partir d’au moins un élément de syntaxe décodé à partir dudit flux de données codées pour ledit au moins un patch. Selon ce mode particulier de réalisation de l’invention, un élément de syntaxe est explicitement codé dans le flux de données pour indiquer si une transformation doit être appliquée au patch décodé et quelle transformation appliquer.
Selon un autre mode particulier de réalisation de l’invention, ledit au moins un élément de syntaxe décodé comprend au moins un indicateur indiquant si une transformation doit être appliquée audit au moins un patch et si l’indicateur indique qu’une transformation doit être appliquée audit au moins un patch, ledit au moins un élément de syntaxe comprend éventuellement au moins un paramètre de ladite transformation. Selon ce mode particulier de réalisation de l’invention, la transformation à appliquer au patch est codée sous la forme d’un indicateur indiquant si une transformation doit être appliquée au patch ou non, et dans le cas positif, éventuellement le ou les paramètres de la transformation à appliquer. Par exemple, un indicateur binaire peut indiquer si une transformation doit être appliquée au patch, et si c’est le cas, un code indiquant quelle transformation est utilisée, et éventuellement un ou des paramètres de la transformation, tels que facteur d’échelle, fonction de modification de la dynamique des pixels, angle de rotation, etc...
Dans d’autres exemples, les paramètres de la transformation peuvent être définis par défaut au codeur.
Selon un autre mode particulier de réalisation de l’invention, ledit au moins un paramètre de ladite transformation à appliquer audit patch a une valeur qui est codée par prédiction par rapport à une valeur de prédiction. Ce mode particulier de réalisation de l’invention permet ainsi de gagner en coût de signalisation des paramètres de la transformation.
Selon un autre mode particulier de réalisation de l’invention, la valeur de prédiction est codée dans un entête d’une vue, ou d’une composante de l’atlas ou de l’atlas.
Selon un autre mode particulier de réalisation de l’invention, la valeur de prédiction correspond à la valeur d’un paramètre d’une transformation appliquée à un patch appartenant au groupe comprenant :
- un patch précédemment traité selon un ordre de traitement des patchs de l’atlas,
- un patch précédemment traité extrait de la même composante d’une vue de la vidéo multi- vues que celle à laquelle ledit au moins un patch appartient, - un patch sélectionné parmi un ensemble de patchs candidats à l’aide d’un index codé dans ledit flux de données,
- un patch sélectionné parmi un ensemble de patchs candidats à l’aide d’un critère.
Selon un autre mode particulier de réalisation de l’invention, la détermination, pour ledit au moins un patch décodé, si une transformation doit être appliquée audit au moins un patch décodé, est réalisée si un élément de syntaxe décodé à partir d’un entête du flux de données indique une activation de l’application de transformations aux patchs codés dans le flux de données, ledit élément de syntaxe étant codé dans un entête d’une vue ou d’une composante d’une vue ou dudit atlas. Selon ce mode particulier de réalisation de l’invention, un élément de syntaxe haut niveau est codé dans le flux de données pour signaler l’utilisation de transformations à appliquer aux patchs de la vidéo multi-vues. Ainsi, le surcoût engendré par le codage des paramètres des transformations au niveau patch est évité lorsque ces transformations ne sont pas utilisées. De plus, ce mode particulier de réalisation de l’invention permet de limiter la complexité au décodage lorsque ces transformations ne sont pas utilisées.
Selon un autre mode particulier de réalisation de l’invention, il est déterminé qu’une transformation doit être appliquée audit au moins un patch décodé si une caractéristique dudit patch décodé respecte un critère. Selon ce mode particulier de réalisation de l’invention, l’indication de l’utilisation d’une transformation à appliquer au patch n’est pas codée explicitement dans le flux de données. Une telle indication est inférée à partir d’une caractéristique du patch décodé. Ce mode particulier de réalisation de l’invention permet d’utiliser des transformations de patchs sans impliquer de coût de codage supplémentaire pour signaler l’utilisation de transformations.
Selon un autre mode particulier de réalisation de l’invention, la caractéristique correspond à un ratio R=H/W où H correspond à une hauteur et W correspond à une largeur dudit au moins un patch décodé, la transformation à appliquer audit au moins un patch correspondant à un sur-échantillonnage vertical d’un facteur prédéterminé lorsque ledit ratio est compris dans un intervalle déterminé. Selon ce mode particulier de réalisation de l’invention, il est ainsi possible de mélanger dans un même atlas des patchs « longs » pour lesquels il n’est pas intéressant de faire un sous-échantillonnage et des patchs « longs » pour lesquels un sous-échantillonnage est réalisé sans avoir besoin de le signaler.
Selon un autre mode particulier de réalisation de l’invention, la caractéristique correspond à une énergie E calculée à partir de la valeur des pixels dudit au moins un patch décodé, la transformation à appliquer audit au moins un patch correspondant à une multiplication de la valeur desdits pixels par un facteur déterminé, lorsque l’énergie E est inférieure à un seuil.
Selon un autre mode particulier de réalisation de l’invention, lorsque plusieurs transformations doivent être appliquées à un même patch, un ordre dans lequel lesdites transformations doivent être appliquées est prédéfini. Selon ce mode particulier de réalisation de l’invention, aucune signalisation n’est nécessaire pour signaler l’ordre dans lequel les transformations sont appliquées. Cet ordre est défini au codeur et au décodeur et reste le même pour tous les patchs auxquels ces transformations s’appliquent.
L’invention concerne aussi un dispositif de décodage d’un flux de données codées représentatif d'une vidéo multi-vues, ledit flux de données codées comprenant des données codées représentatives d'au moins un atlas, ledit au moins un atlas correspondant à une image comprenant au moins un patch, ledit au moins un patch correspondant à un ensemble de pixels extraits d’au moins une composante d’une vue de la vidéo multi-vues, ladite vue n’étant pas codée dans ledit flux de données codées, le dispositif de décodage comprenant un processeur et une mémoire configurés pour :
- décoder, à partir dudit flux de données codées, ledit au moins un atlas, comprenant le décodage dudit au moins un patch,
- déterminer, pour ledit au moins un patch décodé, si une transformation doit être appliquée audit au moins un patch décodé et quelle transformation, ladite transformation appartenant au groupe comprenant au moins un sur échantillonnage du patch ou une modification des valeurs de pixels du patch,
- appliquer la transformation déterminée audit patch décodé.
Selon un mode particulier de réalisation de l'invention, un tel dispositif est compris dans un terminal.
L’invention concerne également un dispositif de codage d’un flux de données représentatif d'une vidéo multi-vues, comprenant un processeur et une mémoire configurés pour :
- extraire à partir d’au moins une composante d’une vue de la vidéo multi-vues non codée dans ledit flux de données, au moins un patch correspondant à un ensemble de pixels de ladite composante,
- déterminer pour ledit au moins un patch extrait, si une transformation doit être appliquée audit au moins un patch, et quelle transformation, ladite transformation appartenant au groupe de transformations comprenant au moins un sous-échantillonnage du patch ou une modification des valeurs de pixels du patch, - appliquer audit au moins un patch, ladite transformation déterminée,
- coder au moins un atlas dans ledit flux de données, ledit au moins un atlas correspondant à une image comprenant au moins ledit au moins un patch.
Selon un mode particulier de réalisation de l'invention, un tel dispositif est compris dans un terminal.
Le procédé de codage, et respectivement le procédé de décodage selon l'invention peuvent être mis en oeuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle. Selon un mode particulier de réalisation de l'invention, le procédé de codage, respectivement le procédé de décodage, est mis en oeuvre par un programme d'ordinateur. L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé de codage ou du procédé de décodage selon l'un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur. Un tel programme peut utiliser n’importe quel langage de programmation. Il peut être téléchargé depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'enregistrement ou support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci- dessus. Les supports d'enregistrement mentionnés ci-avant peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, une clé USB, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, les supports d'enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
4. Liste des figures D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
[Fig. 1] La figure 1 illustre schématiquement un exemple d'un système de capture multi-vues d'une scène.
[Fig. 2] La figure 2 illustre schématiquement un exemple d'un codeur multi-vues basé sur le codage de patchs.
[Fig. 3] La figure 3 illustre un exemple d’extraction de patchs et la création d’atlas.
[Fig. 4] La figure 4 illustre des étapes d'un procédé de codage selon un mode particulier de réalisation de l'invention.
[Fig. 5] La figure 5 illustre des étapes d'un procédé de décodage selon un mode particulier de réalisation de l'invention.
[Fig. 6] La figure 6 illustre un exemple de flux de données selon un mode particulier de réalisation de l'invention.
[Fig. 7] La figure 7 illustre un exemple d'architecture d'un dispositif de codage selon un mode particulier de réalisation de l'invention.
[Fig. 8] La figure 8 illustre un exemple d'architecture d'un dispositif de décodage selon un mode particulier de réalisation de l'invention.
5. Description d'un mode de réalisation de l'invention
La figure 4 illustre des étapes d'un procédé de codage d’une vidéo multi-vues dans au moins un flux de données codées selon un mode particulier de réalisation de l'invention.
Selon l'invention, la vidéo multi-vues est codée selon un schéma de codage tel que présenté en relation avec la figure 2 dans lequel une ou des vues dites de base sont codées dans le flux de données et dans lequel des sous-images ou patchs comprenant des données de texture et de profondeur sont également codées dans le flux de données. Ces patchs proviennent de vues additionnelles qui ne sont pas codées en entier dans le flux de données. De tels patchs et une ou plusieurs vues de base permettent au décodeur de synthétiser d'autres vues de la scène, aussi appelées vues virtuelles, ou vues synthétisées ou encore vues intermédiaires par la suite. Ces vues synthétisées n'ont pas été codées dans le flux de données. On décrit ci-après les étapes d'un tel schéma de codage relatives à un mode particulier de réalisation de l'invention.
On considère ici par exemple que la scène est capturée par un ensemble de caméra Ci, C2, ..., CN comme sur la figure 1. Chaque caméra génère une vue, comprenant au moins une composante dite de texture qui varie au cours du temps. Autrement dit, la composante de texture d’une vue est une séquence d’images 2D correspondant aux images capturées par la caméra placée au point de vue de la vue. Chaque vue comprend également une composante de profondeur, dite carte de profondeur, qui est déterminée pour chaque image de la vue.
La carte de profondeur peut être générée de façon connue par une estimation de la profondeur à l’aide de la texture, ou par capture de données volumétriques de la scène à l’aide de dispositifs utilisant une technologie Lidar pour « Light détection and Ranging » en anglais.
Par la suite, le terme « vue » sera utilisé pour indiquer une séquence d’images de texture et cartes de profondeur représentatives de la scène capturée depuis un point de vue. Par abus de langage, le terme « vue » peut également correspondre à une image de texture et une carte de profondeur d’une vue à un instant donné.
Lorsque les vues de la vidéo multi-vues sont capturées, le codeur procède ensuite aux étapes qui sont décrites ci-après, par exemple selon le schéma de codage défini dans Base I Salahieh, Bart Kroon, Joe I Jung, Marek Domanski, Test Model 4 for Immersive Video, ISO/IEC JTC 1 /SC 29/WG 11 N19002, Brussels, BE - Janvier 2020.
Lors d’une étape E40, une ou des vues dites de base sont sélectionnées parmi les vues capturées de la vidéo multi-vues.
Les vues de base sont sélectionnées parmi l’ensemble des vues capturées de la vidéo multi- vues selon des moyens connus. Par exemple, un sous-échantillonnage spatial peut être fait pour sélectionner une vue sur deux. Selon un autre exemple, le contenu des vues peut être utilisé pour déterminer quelles vues sont à conserver en tant que vues de base. Selon encore un autre exemple, les paramètres des caméras (position, orientation, focale) peuvent être utilisés pour déterminer les vues qu’il convient de sélectionner comme vues de base. A l’issue de l’étape E40, un certain nombre de vues sont sélectionnées pour être des vues de base.
Les autres vues, non sélectionnées comme des vues de base, sont appelées « vues additionnelles ».
Lors d’une étape E41 , une méthode de « pruning » est appliquée aux vues additionnelles pour identifier pour chaque vue additionnelle un ou plusieurs patchs à transmettre au décodeur. Cette étape permet de déterminer les patchs à transmettre en extrayant à partir des images de vues additionnelles les zones nécessaires à la synthèse de vues intermédiaires. Par exemple, de telles zones correspondent à des zones d’occlusion non visibles dans les vues de base, ou bien à des zones visibles ayant subi un changement d’illumination, ou encore ayant une qualité moindre dans les vues de base. Les zones extraites sont de taille et de forme arbitraire. Un regroupement de pixels connectés à leurs voisins (clustering en anglais) est réalisé pour créer à partir des zones extraites d’une même vue un ou des patchs rectangulaires plus faciles à coder et à arranger.
Lors d’une étape E42, pour chaque patch, le codeur détermine une ou plusieurs transformation(s) qui sera(ont) appliquée(s) au patch lors de son arrangement dans un atlas.
Il est rappelé que les patchs peuvent être des patchs comprenant une composante de texture et/ou une composante de profondeur.
Les patchs sont arrangés dans les atlas de sorte à minimiser le coût de codage des atlas et/ou réduire le nombre de pixels à traiter par le décodeur. Pour cela, les patchs peuvent subir des transformations, parmi lesquelles :
• Sous-échantillonnage d’un facteur Nv dans la dimension verticale
• Sous-échantillonnage d’un facteur Nh dans la dimension horizontale
• Sous échantillonnage d’un facteur Ne dans chaque dimension
• Modification des valeurs des pixels contenues dans le patch
• Rotation du patch d’un angle i*90° où i=0, 1 , 2 ou3.
Le codeur parcourt alors chaque patch et détermine une ou plusieurs transformations à appliquer au patch.
Dans une variante, une transformation « identité », autrement dit pas de transformations, peut également être comprise dans la liste des transformations à tester pour le patch.
La sélection d’une transformation parmi les transformations possibles peut être faite par l’évaluation d’un critère débit-distorsion calculé sur le signal reconstruit à l’aide du débit nécessaire pour coder le patch transformé et de la distorsion calculée entre le patch original et le patch transformé codé puis reconstruit. La sélection peut aussi être faite en fonction de l’évaluation de la qualité de la vue additionnelle synthétisée en utilisant le patch en cours de traitement.
Pour chaque transformation, un ou plusieurs paramètres peuvent être testés.
Par exemple, dans le cas d’un sous-échantillonnage, différents facteurs Nv, Nh et Ne peuvent être testés. Dans un mode de réalisation préféré, les facteurs Nv, Nh et Ne sont égaux à 2. Dans d’autres modes de réalisation, d’autres valeurs sont possibles, comme 4, 8 ou 16.
La transformation correspondant à une modification des valeurs des pixels est aussi appelée un « mapping » en anglais. Une telle transformation de mapping peut par exemple consister à diviser toutes les valeurs des pixels du patch par une valeur donnée Dv. Par exemple, Dv est égale à 2. Toutefois, d’autres valeurs sont possibles, comme 4, 8 ou 16.
Selon un autre exemple, le mapping peut aussi consister à transformer les valeurs x des pixels en nouvelles valeurs y à l’aide d’une fonction paramétrée fp(x) = y. Une telle fonction est par exemple une fonction linéaire par morceaux, chaque morceau étant paramétré par son abscisse de début x1 , et les paramètres a et b de la fonction linéaire y=ax+b. Le paramètre P de la transformation est alors une liste de triplet (x1 , a, b) pour chaque partie linéaire du mapping.
Selon un autre exemple, le mapping peut également être une LUT (« LookUp Table » en anglais) qui est un tableau associant une valeur y à une entrée x.
Pour la transformation de rotation, il peut s’agir d’une rotation verticale de 180°, aussi connue sous le nom anglais de « flip » vertical. D’autres valeurs de paramètres de rotation peuvent aussi être testées, par exemple les valeurs d’angles définies par i*90° où i=0, 1 , 2 ou 3.
La détermination d’une transformation associée à un patch peut également prendre en compte le nombre d’atlas disponibles pour coder la vidéo multi-vues et simuler l’arrangement des patchs dans les atlas afin d’optimiser le coût débit/distorsion de codage des atlas ou la qualité de la synthèse de vues intermédiaires de manière globale.
A l’issue de l’étape E42, une liste de patchs transformés est disponible. A chaque patch est associé, la ou les transformations déterminée(s) pour ce patch et les paramètres associés.
Lors d’une étape E43, les patchs sont arrangés dans un atlas ou plusieurs atlas. Le nombre d’atlas dépend par exemple de paramètres définis en entrée au codeur qui sont notamment la taille d’un atlas (longueur et hauteur) et le nombre maximal M de pixels pour la texture et la profondeur de tous les atlas par image ou instant donné. Ce nombre maximal M correspond au nombre de pixels à traiter pour le décodeur pour un instant de la vidéo multi- vues.
Dans le mode particulier de réalisation décrit ici, on considère que chaque vue de base est codée dans un atlas comportant un patch comprenant une composante de texture et une composante de profondeur de la vue de base à un instant donné. Selon ce mode particulier, il y a alors autant d’atlas que de vues de base et autant d’atlas que nécessaire pour transporter tous les patchs extraits des vues additionnelles.
En fonction de la taille des atlas donnée en entrée, il se peut qu’un atlas comprenne une vue de base et des patchs, ou bien une vue de base peut être découpée et représentée sur plusieurs atlas si la taille de la vue est supérieure à la taille d’un atlas.
Selon le mode particulier de réalisation décrit ici, un patch d’un atlas peut alors correspondre à une image entière d’une vue de base ou à une partie d’une vue de base ou encore à une zone extraite d’une vue additionnelle. Les pixels de texture des patchs sont arrangés dans la composante de texture d’un atlas et les pixels de profondeur des patchs sont arrangés dans la composante de profondeur d’un atlas.
Un atlas peut ne comprendre qu’une seule composante de texture ou de profondeur, ou bien comprendre une composante de texture et une composante de profondeur. Dans d’autres exemples, un atlas peut aussi comprendre d’autres types de composante comprenant des informations utiles à la synthèse de vues intermédiaires. Par exemple, d’autres types de composantes peuvent comprendre des informations telles qu’un indice de réflectance, pour indiquer à quel point la zone correspondante est transparente, ou encore une information de confiance sur la valeur de la profondeur à cette localisation.
Au cours de l’étape E43, le codeur parcourt tous les patchs de la liste de patchs. Pour chaque patch, le codeur détermine dans quel atlas ce patch sera codé. Cette liste comprend des patchs transformés et des patchs non transformés. Les patchs non transformés sont soit des patchs comprenant des zones extraites de vues additionnelles qui n’ont subi aucune transformation ou une transformation identité, soit des patchs comprenant des images de vues de base. On considère ici que lorsque le patch doit subir une transformation, il a déjà été transformé.
Un atlas est un ensemble de patchs réarrangés spatialement dans une image. Cette image est destinée à être codée. Cet arrangement a pour but d’occuper au mieux l’espace dans les images d’atlas à coder. En effet, un des objectifs du codage vidéo est de minimiser le nombre de pixels à décoder avant de pouvoir synthétiser une vue. Pour cela, les patchs sont disposés dans les atlas de façon à maximiser le nombre de patchs dans un atlas. Un tel procédé est décrit dans Base I Salahieh, Bart Kroon, Joël Jung, Marek Domanski, Test Model 4 for Immersive Video, ISO/IEC JTC 1 /SC 29/WG 11 N 19002, Brussels, BE - January 2020.
Suite à l’étape E43, une liste de patchs pour chaque atlas est générée. Il est à noter que cet arrangement détermine également le nombre d’atlas à coder pour un instant donné.
Lors d’une étape E44, les atlas sont codés dans le flux de données. Au cours de cette étape, chaque atlas, qui comprend une composante de texture et/ou une composante de profondeur sous la forme d’une image 2D est codé à l’aide d’un codeur vidéo classique tel que HEVC, VVC, MV-HEVC, 3D-HEVC, etc. Comme expliqué ci-dessus, les vues de base sont ici considérées comme des patchs. Le codage des atlas implique donc le codage des vues de base.
Lors d’une étape E45, les informations associées à chaque atlas sont codées dans le flux de données. Ces informations sont classiquement codées par un codeur entropique. Pour chaque atlas, la liste de patchs comprend les éléments suivants, pour chaque patch de la liste :
• La localisation du patch dans l’atlas sous forme de coordonnées 2D, par exemple la position du coin en haut à gauche du rectangle représentant le patch,
• La localisation du patch dans sa vue originelle, sous forme de coordonnées 2D, i.e. sa position dans l’image de la vue à partir de laquelle il a été extrait, par exemple la position dans l’image du coin en haut à gauche du rectangle représentant le patch,
• Les dimensions du patch (longueur et hauteur),
• Un identifiant de la vue originelle du patch,
• Une information sur la transformation appliquée au patch.
Au cours de l’étape E45, pour au moins plusieurs patchs de l’atlas, une information relative aux transformations à appliquer au patch lors du décodage est codée dans le flux de données. Les transformations à appliquer au patch lors du décodage correspondent aux transformations inverses appliquées au patch lors de l’arrangement du patch dans l’atlas et déterminées plus haut.
Selon un mode particulier de réalisation de l’invention, pour chaque patch, une information indiquant la transformation à appliquer est transmise.
Dans le mode particulier de réalisation décrit ici, on considère que c’est la transformation à appliquer au décodage qui est indiquée et non la transformation appliquée au codage (correspondant à la transformation inverse du décodage). Par exemple, lorsqu’un sous- échantillonnage est appliqué lors du codage, un sur-échantillonnage est appliqué lors du décodage. On comprend bien que dans d’autres modes particuliers de réalisation de l’invention, l’information transmise sur la transformation à appliquer peut correspondre à une information indiquant la transformation appliquée au codage, le décodeur déduisant alors la transformation à appliquer à partir de cette information.
Par exemple, l’information indiquant la transformation à appliquer peut être un index indiquant la transformation à appliquer dans une liste des transformations possibles. Une telle liste peut comprend en outre une transformation identité. Dans le cas où aucune transformation n’est appliquée au patch, un index indiquant la transformation identité peut ainsi être codé.
Selon une autre variante, un indicateur binaire peut être codé pour indiquer si le patch est transformé ou non, et si l’indicateur binaire indique que le patch a été transformé, un index indiquant la transformation à appliquer dans la liste des transformations possibles est codé. Dans une variante selon laquelle une seule transformation à appliquer est possible, seul l’indicateur binaire peut être codé pour indiquer si le patch est transformé ou non. La liste des transformations possibles peut être connue du décodeur et n’a donc pas besoin d’être transmise dans le flux de données. Dans d’autres modes de réalisation, la liste des transformations possibles peut être codée dans le flux de données, par exemple dans un entête d’une vue ou de la vidéo multi-vues.
Les paramètres associés aux transformations à appliquer peuvent également être définis par défaut et connus du décodeur. Dans un autre mode particulier de réalisation de l’invention, les paramètres associés à une transformation appliquée au patch sont codés dans le flux de données pour chaque patch.
Lorsque la transformation correspond à un sur-échantillonnage dans une dimension ou les deux (équivalent à un sous-échantillonnage identique lors du codage), le paramètre associé à la transformation peut correspondre à une valeur d’une interpolation à appliquer pour toutes les dimensions ou une valeur d’une interpolation à appliquer pour chacune des dimensions.
Lorsque la transformation correspond à une modification des valeurs de pixels du patch à coder, par mapping à l’aide d’un paramètre, les paramètres de cette transformation correspondent aux caractéristiques du mapping à appliquer : paramètres d’une fonction linéaire, linéaire par morceaux, Look-up Table (LUT),.... Notamment, la ou les LUT possibles peuvent être connues du décodeur.
Lorsque la transformation correspond à une rotation, le paramètre correspond à l’angle de rotation sélectionné parmi les rotations possibles.
Les paramètres associés à une transformation peuvent être codés tels quels ou bien par prédiction par rapport à une valeur de prédiction.
Selon une variante, pour prédire la valeur d’un paramètre, une valeur de prédiction peut être définie et codée dans le flux de données dans un entête d’une vue, ou d’une composante, ou d’une image d’une vue, ou encore d’un atlas comprenant le patch courant.
Ainsi, pour un atlas donné, la valeur P d’un paramètre sera prédite par une valeur Ppred codée au niveau de l’atlas. La différence entre Ppred et P est ensuite codée pour chaque patch de l’atlas.
Selon une autre variante, pour prédire la valeur du paramètre, la valeur de prédiction Ppred peut correspondre à la valeur du paramètre utilisé pour un patch précédemment traité. Par exemple, il peut s’agir du patch précédent dans l’ordre de traitement des patchs, ou encore du patch précédent appartenant à la même vue que le patch courant.
La valeur de prédiction du paramètre peut aussi être obtenue par un mécanisme semblable au mode « Merge » (fusionné en français) d’un codeur de type HEVC. Pour chaque patch, une liste de patchs candidats est définie et un index pointant sur l’un de ces patchs candidats est codé pour le patch. Dans un autre mode de réalisation, il n’est pas nécessaire de transmettre un index, un critère pouvant être utilisé pour identifier le patch parmi la liste de patchs candidats. Ainsi, on pourra par exemple choisir le patch qui maximise une mesure de ressemblance avec le patch courant, ou encore choisir le patch dont les dimensions sont les plus proches du patch courant.
Dans d’autres variantes de réalisation, l’information indiquant si le patch doit subir une transformation peut être décomposée en une partie qui indique l’usage de la transformation (par exemple un indicateur binaire) et une partie qui indique les paramètres de la transformation, si l’usage est activé. Ce mécanisme de signalisation peut être utilisé indépendamment pour chaque transformation possible pour le patch.
Dans un mode particulier de réalisation de l’invention, un indicateur binaire peut être codé au niveau d’un entête d’un atlas, ou d’une vue ou d’une composante, pour activer l’usage d’une transformation déterminée pour les patchs de cet atlas, de cette vue ou de cette composante. L’application de la transformation déterminée pour un patch dépend alors de la valeur de cet indicateur binaire.
Par exemple, deux indicateurs binaires U et IB associés respectivement à l’activation d’une transformation A et à l’activation d’une transformation B sont codés dans un entête d’un atlas. La valeur de l’indicateur binaire indique que l’usage de la transformation A est possible, alors que la valeur de l’indicateur binaire IB indique que l’usage de la transformation B n’est pas possible. Dans cet exemple, pour chaque patch, un indicateur binaire indiquera si la transformation A est appliquée au patch, et éventuellement les paramètres associés. Il n'est pas nécessaire dans cet exemple de coder pour chaque patch un indicateur binaire pour indiquer si la transformation B est appliquée au patch.
Le mode particulier de réalisation activant au niveau patch ou à un plus haut niveau l’utilisation d’une transformation permet notamment de gagner en coût de signalisation, lorsqu’aucun patch n’utilise cette transformation.
Si cet indicateur binaire d’activation est codé au niveau d’une vue ou d’une composante, sa valeur s’applique alors à tous les patchs appartenant à la vue ou à la composante quel que soit l’atlas dans lequel le patch est codé. Ainsi, un atlas peut comprendre un patch pour lequel une transformation déterminée est susceptible d’être appliquée en fonction de l’indicateur codé pour ce patch et un patch pour lequel la même transformation ne peut pas être appliquée. Pour ce dernier patch, aucun indicateur pour cette transformation n’est codé dans les informations du patch. Dans un autre mode particulier de réalisation de l’invention, aucune information indiquant une transformation n’est codée au niveau patch. Celle-ci est déduite au décodeur à partir d’une caractéristique du patch. La transformation est alors appliquée au patch dès que celui- ci respecte un certain critère. Ce mode particulier sera décrit plus en détail ci-dessous en relation avec le procédé de décodage.
La figure 5 illustre des étapes d'un procédé de décodage d’un flux de données codées représentatif d’une vidéo multi-vues selon un mode particulier de réalisation de l'invention. Par exemple, le flux de données codées a été généré par le procédé de codage décrit en relation avec la figure 4.
Lors d’une étape E50, les informations d’atlas sont décodées. Ces informations sont classiquement décodées par un décodeur entropique adéquat.
Elles comprennent notamment une liste de patchs, et pour chaque patch, les éléments suivants :
- La localisation du patch dans l’atlas sous forme de coordonnées,
- La localisation du patch dans sa vue originelle, sous forme de coordonnées,
- Les dimensions du patch,
- Un identifiant de la vue originelle du patch,
- Une information indiquant si une transformation doit être appliquée au patch.
Comme dans le procédé de codage, cette information peut être un index indiquant une transformation parmi une liste de transformations possibles, ou bien pour chaque transformation possible, un indicateur indiquant si la transformation doit être appliquée au patch.
Pour une transformation correspondant à un sur-échantillonnage identique dans les deux dimensions, l’information peut correspondre à un indicateur binaire indiquant l’usage de la transformation ou une valeur d’une interpolation à appliquer pour toutes les dimensions.
Pour une transformation correspondant à un sur-échantillonnage distinct dans les deux dimensions, l’information peut correspondre à un indicateur binaire indiquant l’usage de la transformation ou pour chacune des dimensions une valeur d’une interpolation à appliquer. Pour une transformation correspondant à une modification des pixels du patch à décoder, par mapping à l’aide d’un paramètre, l’information peut comprendre une information indiquant l’usage du mapping, et éventuellement une information représentative des caractéristiques du mapping à appliquer (paramètres d’une fonction linéaire, linéaire par morceaux, Look-up Table,...).
Pour une transformation correspondant à une rotation, le paramètre indiquera quelle rotation a été sélectionnée parmi les rotations possibles. L’information transmise permettant d’identifier une transformation à appliquer au patch est décodée de façon adaptée au codage appliqué. Ainsi, elle peut être décodée telle quelle (décodage direct) ou de façon prédictive, de façon similaire à l’encodeur.
Selon un mode particulier de réalisation de l’invention, l’information permettant d’identifier une transformation à appliquer au patch peut comprendre une partie qui indique l’usage de la transformation (indicateur binaire) et une partie qui indique les paramètres de la transformation, si l’usage est activé.
Comme pour le procédé de codage, selon un mode particulier de réalisation de l’invention, le décodage pour un patch donné, d’une information identifiant une transformation à appliquer au patch peut dépendre d’un indicateur binaire d’activation codé en entête de l’atlas, de la vue ou de la composante à laquelle le patch appartient.
Selon un autre mode particulier de réalisation de l’invention, l’information identifiant une transformation à appliquer au patch n’est pas codée avec les informations du patch, mais dérivée des caractéristiques du patch décodé.
Par exemple, selon une variante, l’énergie des pixels décodés contenus dans le patch est mesurée, en calculant l’erreur quadratique moyenne du patch. Si cette énergie est inférieure à un seuil donné, par exemple, une erreur quadratique moyenne inférieure à 100, les valeurs de pixel du patch sont transformées en multipliant toutes les valeurs du patch par un facteur Dv déterminé. Par exemple Dv= 2. D’autres valeurs de seuils sont possibles, ainsi que d’autres facteurs de modification des valeurs du patch.
Selon une autre variante, si le rapport des dimensions décodées H/W du patch, avec H étant la hauteur du patch et W la longueur du patch, est compris dans un intervalle déterminé, par exemple 0.75<H/W<1.5, alors le patch est interpolé d’un facteur déterminé, par exemple un facteur 2 dans la dimension verticale. Les dimensions du patch considérées ici sont les dimensions du patch décodées à partir des informations de l’atlas dans lequel le patch a été codé. Il s’agit donc des dimensions du patch avant transformation au décodeur (et après transformation au codeur donc). Lorsqu’il est déterminé que le ratio H/W est compris dans l’intervalle déterminé, le patch est sur-échantillonné et ses dimensions recalculées en conséquence.
Cette variante permet de mélanger dans un même atlas des patchs « longs » pour lesquels il n’est pas intéressant de faire un sous-échantillonnage et des patchs « longs » pour lesquels on sous-échantillonne sans signaler, ce qui leur fait respecter le critère qui permet de les interpoler au décodeur. D’autres valeurs de seuils peuvent être utilisées, par exemple des valeurs plus restrictives comme 0.9<H/W<1.1 .
Lors d’une étape E51 , les composantes des atlas sont décodées. Chaque atlas, qui comprend une composante 2D de texture et/ou une composante 2D de profondeur, est décodé à l’aide d’un décodeur vidéo classique tel que AVC ou HEVC, VVC, MV-HEVC, 3D- HEVC, etc.
Lors d’une étape E52, les patchs décodés sont reconstruits en appliquant la transformation identifiée lors de l’étape E50 à la composante de texture et/ou à la composante de profondeur de chaque patch dans son atlas selon que la transformation s’applique à la texture, à la profondeur ou aux deux composantes.
Pour les vues additionnelles, cette étape consiste à modifier individuellement chaque patch en appliquant la transformation identifiée pour ce patch. Ceci peut être réalisé de différentes façons, par exemple : en modifiant les pixels du patch dans l’atlas qui le contient, en copiant le patch modifié dans une zone mémoire tampon, ou encore en copiant le patch transformé dans la vue qui lui est associée.
En fonction des informations décodées précédemment, chaque patch à reconstruire peut se voir appliquer l’une des transformations suivantes :
Sur-échantillonnage d’un facteur Nv dans la dimension verticale,
Sur-échantillonnage d’un facteur Nh dans la dimension horizontale, Sur-échantillonnage d’un facteur Ne dans chaque dimension,
Modification des valeurs des pixels contenus dans le patch,
Rotation du patch.
La modification des valeurs des pixels est similaire à l’encodage et au décodage. On notera que les paramètres de mapping transmis peuvent être soit les paramètres du mapping encodeur (et alors le décodeur devra appliquer la fonction inverse du mapping), soit les paramètres du mapping décodeur (et alors l’encodeur devra appliquer la fonction inverse du mapping).
Selon un mode particulier de réalisation de l’invention, il est possible d’appliquer à l’encodeur plusieurs transformations à un patch. Ces transformations sont signalées dans le flux dans les informations codées pour le patch ou bien déduites des caractéristiques du patch décodé. Par exemple, il est possible d’appliquer à l’encodeur un sous-échantillonnage d’un facteur 2 dans chaque dimension du patch, suivi par un mapping des valeurs de pixels du patch, puis une rotation. Selon ce mode particulier de réalisation de l’invention, l’ordre des transformations à appliquer est prédéfini et connu de l’encodeur et du décodeur. Par exemple, l’ordre est le suivant au codeur : rotation, puis sous-échantillonnage, puis mapping.
Lors de la reconstruction du patch au décodeur, lorsque plusieurs transformations doivent être appliquées au patch, l’ordre inverse est appliqué au patch (mapping, sur échantillonnage, puis rotation). Ainsi, le décodeur et le codeur savent tous deux dans quel ordre appliquer les transformations afin de produire le même résultat.
A l’issue de l’étape E52, un ensemble de patchs reconstruits est disponible.
Lors d’une étape E53, au moins une vue intermédiaire est synthétisée à l’aide d’au moins une vue de base et d’au moins un patch reconstruit précédemment. L’algorithme de synthèse de vues virtuelles choisi est appliqué aux données décodées et reconstruites de la vidéo multi-vues qui ont été transmises au décodeur. Comme expliqué précédemment, cet algorithme s’appuie sur les pixels des composantes des vues de base et des patchs pour produire une vue depuis un point de vue situé entre les caméras.
Par exemple, l’algorithme de synthèse utilise au moins deux textures et deux cartes de profondeurs, issues de vues de base et/ou de vues additionnelles pour générer une vue intermédiaire. Les synthétiseurs sont connus et appartiennent par exemple à la catégorie DIBR (« Depth Image Based Rendering » en anglais). Par exemple, des algorithmes fréquemment utilisés par les organismes de normalisation sont :
- le VSRS pour « View Synthesis Reference Software » en anglais, initié par l’Université de Nagoya et amélioré par MPEG, applique des projections avant (« forward projection » en anglais) des cartes de profondeur en utilisant une homographie entre les vues de référence et les vues intermédiaires, puis une étape de remplissage pour supprimer les artefacts liés à la déformation avant (« forward warping » en anglais) ; le RVS pour « Reference View Synthesizer » en anglais, initié par l’Université de Bruxelles et amélioré par Philips, commence par projeter les vues de référence à l’aide d’une disparité calculée. Les références sont partitionnées en triangles, et déformées. Ensuite les vues déformées de chaque référence sont mixées (« blending » en anglais), puis un remplissage de type « inpainting » basique est appliqué pour remplir les dis-occlusions ;
- le VVS pour « Versatile View Synthesizer » en anglais, développé par Orange, trie les références, applique une déformation de certaines informations des cartes de profondeur, puis une fusion conditionnelle de ces profondeurs. Ensuite une projection arrière (« backward warping » en anglais) des textures est appliquée, puis une fusion des différentes textures et des différentes profondeurs. Enfin, un remplissage de type « inpainting » spatio-temporel est appliqué, avant filtrage spatial de l’image intermédiaire.
La figure 6 illustre un exemple de flux de données selon un mode particulier de réalisation de l'invention et notamment les informations d’atlas codées dans le flux et permettant d’identifier une ou des transformations à appliquer aux patchs de l’atlas. Par exemple, le flux de données a été généré selon le procédé de codage selon l’un quelconque des modes particuliers de réalisation décrits en relation avec la figure 4, et il est apte à être décodé par le procédé de décodage selon l’un quelconque des modes particuliers de réalisation décrits en relation avec la figure 5.
Selon ce mode particulier de réalisation de l’invention, un tel flux comprend notamment :
- un indicateur Act™ codé en entête de l’atlas pour indiquer l’activation ou non de la transformation donnée,
- une valeur de prédiction Ppred pour servir de valeur de prédiction à la valeur du paramètre de la transformation,
- un nombre Np de patchs codés dans l’atlas,
- pour chaque patch de l’atlas, les informations du patch et notamment un indicateur Trf indiquant l’usage ou non de la transformation pour le patch,
- lorsque l’indicateur Trf indique l’usage de la transformation pour le patch, un paramètre Par de la transformation, par exemple sous la forme d’un résidu obtenu par rapport à la valeur de prédiction Ppred, lorsque celle-ci est codée.
Comme expliqué en relation avec les procédés de codage et de décodage décrits ci-dessus, d’autres modes particuliers de réalisation de l’invention sont possibles au niveau des informations relatives à la transformation qui sont codées pour les patchs.
La figure 7 présente la structure simplifiée d’un dispositif de codage COD adapté pour mettre en oeuvre le procédé de codage selon l'un quelconque des modes particuliers de réalisation de l'invention.
Selon un mode particulier de réalisation de l'invention, les étapes du procédé de codage sont mises en oeuvre par des instructions de programme d'ordinateur. Pour cela, le dispositif de codage COD a l'architecture classique d'un ordinateur et comprend notamment une mémoire MEM, une unité de traitement UT, équipée par exemple d'un processeur PROC, et pilotée par le programme d'ordinateur PG stocké en mémoire MEM. Le programme d'ordinateur PG comprend des instructions pour mettre en œuvre les étapes du procédé de codage tel que décrit ci-dessus, lorsque le programme est exécuté par le processeur PROC.
A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire RAM (non représentée) avant d'être exécutées par le processeur PROC. Le processeur PROC de l'unité de traitement UT met notamment en œuvre les étapes du procédé de codage décrit ci-dessus, selon les instructions du programme d'ordinateur PG.
La figure 8 présente la structure simplifiée d’un dispositif de décodage DEC adapté pour mettre en œuvre le procédé de décodage selon l'un quelconque des modes particuliers de réalisation de l'invention.
Selon un mode particulier de réalisation de l'invention, le dispositif de décodage DEC a l'architecture classique d'un ordinateur et comprend notamment une mémoire MEMO, une unité de traitement UTO, équipée par exemple d'un processeur PROCO, et pilotée par le programme d'ordinateur PGO stocké en mémoire MEMO. Le programme d'ordinateur PGO comprend des instructions pour mettre en œuvre les étapes du procédé de décodage tel que décrit ci-dessus, lorsque le programme est exécuté par le processeur PROCO.
A l'initialisation, les instructions de code du programme d'ordinateur PGO sont par exemple chargées dans une mémoire RAM (non représentée) avant d'être exécutées par le processeur PROCO. Le processeur PROCO de l'unité de traitement UTO met notamment en œuvre les étapes du procédé de décodage décrit ci-dessus, selon les instructions du programme d'ordinateur PGO.

Claims

Revendications
1. Procédé de décodage d’un flux de données codées représentatif d'une vidéo multi-vues, ledit flux de données codées comprenant des données codées représentatives d'au moins un atlas, ledit au moins un atlas correspondant à une image comprenant au moins un patch, ledit au moins un patch correspondant à un ensemble de pixels extraits d’au moins une composante d’une vue de la vidéo multi-vues, ladite vue n’étant pas codée dans ledit flux de données codées, le procédé de décodage comprend :
- le décodage, à partir dudit flux de données codées, dudit au moins un atlas, comprenant le décodage dudit au moins un patch,
- la détermination, pour ledit au moins un patch décodé, si une transformation doit être appliquée audit au moins un patch décodé, et quelle transformation, ladite transformation appartenant au groupe de transformations comprenant au moins un sur-échantillonnage du patch ou une modification des valeurs de pixels du patch,
- l’application de la transformation déterminée audit patch décodé.
2. Procédé selon la revendication 1 , dans lequel il est déterminé si une transformation doit être appliquée audit au moins un patch décodé à partir d’au moins un élément de syntaxe décodé à partir dudit flux de données codées pour ledit au moins un patch.
3. Procédé selon la revendication 2, dans lequel ledit au moins un élément de syntaxe décodé comprend au moins un indicateur indiquant si une transformation doit être appliquée audit au moins un patch et si l’indicateur indique qu’une transformation doit être appliquée audit au moins un patch, ledit au moins un élément de syntaxe comprend éventuellement au moins un paramètre de ladite transformation.
4. Procédé selon la revendication 3, dans lequel ledit au moins un paramètre de ladite transformation à appliquer audit patch a une valeur qui est codée par prédiction par rapport à une valeur de prédiction.
5. Procédé selon la revendication 4, dans lequel la valeur de prédiction est codée dans un entête d’une vue, ou d’une composante de l’atlas ou de l’atlas.
6. Procédé selon la revendication 4, dans lequel la valeur de prédiction correspond à la valeur d’un paramètre d’une transformation appliquée à un patch appartenant au groupe comprenant :
- un patch précédemment traité selon un ordre de traitement des patchs de l’atlas,
- un patch précédemment traité extrait de la même composante d’une vue de la vidéo multi- vues que celle à laquelle ledit au moins un patch appartient,
- un patch sélectionné parmi un ensemble de patchs candidats à l’aide d’un index codé dans ledit flux de données,
- un patch sélectionné parmi un ensemble de patchs candidats à l’aide d’un critère de sélection.
7. Procédé selon la revendication 1 , dans lequel la détermination, pour ledit au moins un patch décodé, si une transformation doit être appliquée audit au moins un patch décodé, est réalisée si un élément de syntaxe décodé à partir d’un entête du flux de données indique une activation de l’application de transformations aux patchs codés dans le flux de données, ledit élément de syntaxe étant codé dans un entête d’une vue ou d’une composante d’une vue ou dudit atlas.
8. Procédé selon la revendication 1 , dans lequel il est déterminé qu’une transformation doit être appliquée audit au moins un patch décodé si une caractéristique dudit patch décodé respecte un critère.
9. Procédé selon la revendication 8, dans lequel la caractéristique correspond à un ratio R=H/W où H correspond à une hauteur et W correspond à une largeur dudit au moins un patch décodé, la transformation à appliquer audit au moins un patch correspondant à un sur échantillonnage vertical d’un facteur prédéterminé lorsque ledit ratio est compris dans un intervalle déterminé.
10. Procédé selon la revendication 8, dans lequel la caractéristique correspond à une énergie E calculée à partir de la valeur des pixels dudit au moins un patch décodé, la transformation à appliquer audit au moins un patch correspondant à une multiplication de la valeur desdits pixels par un facteur déterminé, lorsque l’énergie E est inférieure à un seuil.
11. Procédé de codage d’un flux de données représentatif d'une vidéo multi-vues, le procédé de codage comprend :
- l’extraction à partir d’au moins une composante d’une vue de la vidéo multi-vues non codée dans ledit flux de données, d’au moins un patch correspondant à un ensemble de pixels de ladite composante, - la détermination pour ledit au moins un patch extrait, si une transformation doit être appliquée audit au moins un patch, et quelle transformation, ladite transformation appartenant au groupe de transformations comprenant au moins un sous-échantillonnage du patch ou une modification des valeurs de pixels du patch,
- l’application audit au moins un patch, de la transformation déterminée,
- le codage d’au moins un atlas dans ledit flux de données, ledit au moins un atlas correspondant à une image comprenant au moins ledit au moins un patch.
12. Procédé selon la revendication 1 ou 11 , dans lequel, lorsque plusieurs transformations doivent être appliquées à un même patch, un ordre dans lequel lesdites transformations doivent être appliquées est prédéfini.
13. Dispositif de décodage d’un flux de données codées représentatif d'une vidéo multi-vues, ledit flux de données codées comprenant des données codées représentatives d'au moins un atlas, ledit au moins un atlas correspondant à une image comprenant au moins un patch, ledit au moins un patch correspondant à un ensemble de pixels extraits d’au moins une composante d’une vue de la vidéo multi-vues, ladite vue n’étant pas codée dans ledit flux de données codées, le dispositif de décodage comprend un processeur et une mémoire configurés pour :
- décoder, à partir dudit flux de données codées, ledit au moins un atlas, comprenant le décodage dudit au moins un patch,
- déterminer, pour ledit au moins un patch décodé, si une transformation doit être appliquée audit au moins un patch décodé et quelle transformation, ladite transformation appartenant au groupe comprenant au moins un sur-échantillonnage du patch ou une modification des valeurs de pixels du patch,
- appliquer la transformation déterminée audit patch décodé.
14. Dispositif de codage d’un flux de données représentatif d'une vidéo multi-vues, comprenant un processeur et une mémoire configurés pour :
- extraire à partir d’au moins une composante d’une vue de la vidéo multi-vues non codée dans ledit flux de données, au moins un patch correspondant à un ensemble de pixels de ladite composante,
- déterminer pour ledit au moins un patch extrait, si une transformation doit être appliquée audit au moins un patch, et quelle transformation, ladite transformation appartenant au groupe de transformations comprenant au moins un sous-échantillonnage du patch ou une modification des valeurs de pixels du patch,
- appliquer audit au moins un patch, ladite transformation déterminée, - coder au moins un atlas dans ledit flux de données, ledit au moins un atlas correspondant à une image comprenant au moins ledit au moins un patch.
15. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de décodage selon l’une quelconque des revendications 1 à 10 ou 12 et/ou des instructions pour la mise en œuvre du procédé de codage selon l’une quelconque des revendications 11 ou 12, lorsque ledit programme est exécuté par un processeur.
EP21721150.7A 2020-04-22 2021-03-29 Procédés et dispositifs de codage et de décodage d'une séquence vidéo multi-vues Pending EP4140136A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2003994A FR3109685A1 (fr) 2020-04-22 2020-04-22 Procédés et dispositifs de codage et de décodage d'une séquence vidéo multi-vues
PCT/FR2021/050551 WO2021214395A1 (fr) 2020-04-22 2021-03-29 Procédés et dispositifs de codage et de décodage d'une séquence vidéo multi-vues

Publications (1)

Publication Number Publication Date
EP4140136A1 true EP4140136A1 (fr) 2023-03-01

Family

ID=71452477

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21721150.7A Pending EP4140136A1 (fr) 2020-04-22 2021-03-29 Procédés et dispositifs de codage et de décodage d'une séquence vidéo multi-vues

Country Status (8)

Country Link
US (1) US20230164352A1 (fr)
EP (1) EP4140136A1 (fr)
JP (1) JP2023522456A (fr)
KR (1) KR20230002802A (fr)
CN (1) CN115428456A (fr)
BR (1) BR112022020642A2 (fr)
FR (1) FR3109685A1 (fr)
WO (1) WO2021214395A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11457199B2 (en) * 2020-06-22 2022-09-27 Electronics And Telecommunications Research Institute Method for processing immersive video and method for producing immversive video

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005016827A1 (de) * 2005-04-12 2006-10-19 Siemens Ag Adaptive Interpolation bei der Bild- oder Videokodierung
JP5711098B2 (ja) * 2011-11-07 2015-04-30 日本電信電話株式会社 画像符号化方法，画像復号方法，画像符号化装置，画像復号装置およびそれらのプログラム
US10057574B2 (en) * 2015-02-11 2018-08-21 Qualcomm Incorporated Coding tree unit (CTU) level adaptive loop filter (ALF)
KR20200111643A (ko) * 2019-03-19 2020-09-29 한국전자통신연구원 이머시브 영상 처리 방법 및 이머시브 영상 합성 방법
WO2020232281A1 (fr) * 2019-05-14 2020-11-19 Intel Corporation Techniques de codage de vidéo immersive pour trois degrés de liberté plus/métadonnées pour une vidéo immersive (3dof+ /miv) et un codage de nuage de points de vidéo (v-pcc)
KR102292195B1 (ko) * 2019-07-04 2021-08-24 엘지전자 주식회사 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
CN115004230A (zh) * 2020-01-14 2022-09-02 华为技术有限公司 用于v-pcc的缩放参数

Also Published As

Publication number Publication date
KR20230002802A (ko) 2023-01-05
US20230164352A1 (en) 2023-05-25
BR112022020642A2 (pt) 2022-11-29
WO2021214395A1 (fr) 2021-10-28
JP2023522456A (ja) 2023-05-30
CN115428456A (zh) 2022-12-02
FR3109685A1 (fr) 2021-10-29

Similar Documents

Publication Publication Date Title
EP3061246B1 (fr) Procédé de codage et de décodage d&#39;images, dispositif de codage et de décodage d&#39;images et programmes d&#39;ordinateur correspondants
WO2019211541A2 (fr) Procédé et dispositif de décodage d&#39;une vidéo multi-vue, et procédé et dispositif de traitement d&#39;images
FR3012004A1 (fr) Procede de codage et de decodage d&#39;images, dispositif de codage et de decodage d&#39;images et programmes d&#39;ordinateur correspondants
WO2010043809A1 (fr) Prediction d&#39;une image par compensation en mouvement en avant
FR2920632A1 (fr) Procede et dispositif de decodage de sequences video avec masquage d&#39;erreurs
EP4140136A1 (fr) Procédés et dispositifs de codage et de décodage d&#39;une séquence vidéo multi-vues
WO2019008254A1 (fr) Procédé de codage et décodage d&#39;images, dispositif de codage et décodage et programmes d&#39;ordinateur correspondants
FR3026261A1 (fr) Procede de codage et de decodage d&#39;images integrales, dispositif de codage et de decodage d&#39;images integrales et programmes d&#39;ordinateur correspondants
WO2020188172A1 (fr) Procédés et dispositifs de codage et de décodage d&#39;une séquence vidéo multi-vues
EP1714498B1 (fr) Procede de recherche de la directon de prediction en codage video intra-image
EP3158749B1 (fr) Procédé de codage et de décodage d&#39;images, dispositif de codage et de décodage d&#39;images et programmes d&#39;ordinateur correspondants
EP3529987A1 (fr) Procédé de codage et de décodage de paramètres d&#39;image, dispositif de codage et de décodage de paramètres d&#39;image et programmes d&#39;ordinateur correspondants
WO2020070409A1 (fr) Codage et décodage d&#39;une vidéo omnidirectionnelle
WO2019115899A1 (fr) Procédés et dispositifs de codage et de décodage d&#39;une séquence vidéo multi-vues représentative d&#39;une vidéo omnidirectionnelle
WO2019008253A1 (fr) Procédé de codage et décodage d&#39;images, dispositif de codage et décodage et programmes d&#39;ordinateur correspondants
EP4104446A1 (fr) Procédé et dispositif de traitement de données de vidéo multi-vues
WO2022069809A1 (fr) Codage et decodage d&#39;une video multi-vues
FR3106014A1 (fr) Synthèse itérative de vues à partir de données d’une vidéo multi-vues
WO2022269163A1 (fr) Procédé de construction d&#39;une image de profondeur d&#39;une vidéo multi-vues, procédé de décodage d&#39;un flux de données représentatif d&#39;une vidéo multi-vues, procédé de codage, dispositifs, système, équipement terminal, signal et programmes d&#39;ordinateur correspondants
WO2020260034A1 (fr) Procede et dispositif de traitement de donnees de video multi-vues
FR3064145A1 (fr) Procede de codage et decodage d&#39;images, dispositif de codage et decodage et programmes d&#39;ordinateur correspondants

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220929

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE