WO2021160955A1 - Procédé et dispositif de traitement de données de vidéo multi-vues - Google Patents

Procédé et dispositif de traitement de données de vidéo multi-vues Download PDF

Info

Publication number
WO2021160955A1
WO2021160955A1 PCT/FR2021/050207 FR2021050207W WO2021160955A1 WO 2021160955 A1 WO2021160955 A1 WO 2021160955A1 FR 2021050207 W FR2021050207 W FR 2021050207W WO 2021160955 A1 WO2021160955 A1 WO 2021160955A1
Authority
WO
WIPO (PCT)
Prior art keywords
obtaining
data
mode
item
view
Prior art date
Application number
PCT/FR2021/050207
Other languages
English (en)
Inventor
Joël JUNG
Pavel Nikitin
Patrick GARUS
Original Assignee
Orange
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 filed Critical Orange
Priority to US17/799,101 priority Critical patent/US20230065861A1/en
Priority to CN202180014543.7A priority patent/CN115104312A/zh
Priority to EP21707767.6A priority patent/EP4104446A1/fr
Publication of WO2021160955A1 publication Critical patent/WO2021160955A1/fr

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
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/161—Encoding, multiplexing or demultiplexing different image signal components
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00—Image coding
    • G06T9/001—Model-based coding, e.g. wire frame
    • 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/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H04N19/39—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability involving multiple description coding [MDC], i.e. with separate layers being structured as independently decodable descriptions of input picture data

Definitions

  • the invention relates to so-called immersive videos, representative of a scene captured by one or more cameras, including videos for virtual reality and free navigation. More particularly, the invention relates to the processing (coding, decoding, synthesis of intermediate views) of data from such videos.
  • Immersive video allows a viewer to watch a scene from any point of view, even from a point of view that was not captured by a camera.
  • a typical acquisition system is a set of cameras, which captures a scene with multiple cameras located outside the scene or with divergent cameras built on a spherical platform.
  • the videos are usually displayed through virtual reality headsets (also known as HMD for Head Mounted Device in English), but can also be displayed on 2D screens with an additional system to interact with the user.
  • Free navigation in a scene requires proper management of every movement of the user in order to avoid motion sickness.
  • the movement is generally correctly captured by the display device (an HMD headset for example).
  • delivering the correct pixels to the display regardless of the user's movement (rotational or translational), is currently a problem.
  • This requires multiple captured views and the ability to generate additional virtual (synthesized) views, calculated from the decoded captured views and associated depths.
  • the number of views to be transmitted varies depending on the use case. However, the number of views to be transmitted and the amount of associated data is often large. Therefore, view transmission is an essential aspect of immersive video applications. It is therefore necessary to reduce as much as possible the bit rate of the information to be transmitted without compromising the quality of the synthesis of the intermediate views.
  • the views are either physically captured or computer generated.
  • depths are also captured with dedicated sensors.
  • the quality of this depth information is generally poor and prevents an effective synthesis of intermediate points of view.
  • Depth maps can also be calculated from the texture images of the captured videos. Many depth estimation algorithms exist and are used in the state of the art.
  • FIG. 1 shows an immersive video processing diagram comprising for example two captured views having respectively the texture information T x o y o and T xiy0 .
  • Depth information Dxoyo and Dxi y0 associated with each view T x o y o and T xi y o are estimated by an estimation module FE.
  • the depth information D x0y o and D xiy0 are obtained by a depth estimation software (DERS for Depth Estimation Reference Software), the views Txoyo and T xi y o and the depth information obtained D x0y o and D xiy0 are then encoded (CODEC), for example using an MV-HEVC encoder.
  • CODEC depth estimation software
  • the views T * x0 yo and T * xi yo and the associated depths of each view D * x0y o and D * xiy0 are decoded and used by a synthesis algorithm (SYNTHESIS) to calculate intermediate views, for example example here of the intermediate views S x0y o and S xiy0 .
  • SYNTHESIS synthesis algorithm
  • VSRS View Synthesis Reference
  • VSRS View Synthesis Reference
  • full depth maps are generated and sent, while on the client side, not all parts of all depth maps are useful. This is because the views can have redundant information, which makes certain parts of depth maps unnecessary. Additionally, in some cases, viewers may request only specific points of view. Without a return channel between the client and the server providing the encoded immersive video, the depth estimator on the server side ignores knowledge of these specific viewpoints.
  • the calculation of the depth information on the server side avoids any interaction between the depth estimator and the synthesis algorithm. For example, if a depth estimator wishes to inform the synthesis algorithm that it cannot correctly find the depth of a specific area, it must pass that information in the bitstream, most likely in the form of a binary map.
  • the configuration of the encoder to encode the depth maps in order to obtain the best compromise between the quality of the synthesis and the coding cost for the transmission of the depth maps is not obvious.
  • the number of pixels to be processed by a decoder is high when the textures and the depth maps are encoded, transmitted and decoded. This can, for example, slow down the deployment of immersive video processing schemes on smartphone-type terminals (for smart phones in French).
  • the invention improves the state of the art. To this end, it relates to a method for processing data from a multi-view video, comprising:
  • the invention makes it possible to take advantage of different modes of obtaining synthesis data in a flexible manner by allowing the selection of a mode of obtaining each summary data which is optimal, for example in terms of coding cost / quality. synthesis data or depending on the tools available on the decoder side and / or on the encoder side. This selection is flexible since it can advantageously be carried out at block, image, view or video level. The level of granularity of the mode of obtaining the summary data can therefore be adapted according to the content of the multi-view video, for example, or the tools available on the client / decoder side.
  • the synthetic data item is determined on the encoder side, encoded and transmitted to a decoder in a data stream.
  • the quality of the summary data can be privileged since it is determined from original images, not coded for example.
  • the synthetic data does not suffer during its estimation of the coding artifacts of the decoded textures.
  • the synthetic data item is determined on the decoder side.
  • the data necessary for the synthesis of intermediate views are obtained from the decoded and reconstructed views which have been transmitted to the decoder.
  • Such synthesis data can be obtained at the level of the decoder, or else by a module independent of the decoder taking as input the views decoded and reconstructed by the decoder.
  • This second method of obtaining makes it possible to reduce the cost of encoding the data of the multi-view video and the decoding of the multi-view video is simplified, since the decoder no longer has to decode the data used for the synthesis of views. intermediaries.
  • the invention also improves the quality of the synthesis of intermediate views.
  • summary data estimated at the decoder may be more suitable for the synthesis of views than coded summary data, for example when different estimators are available on the client side and on the server side.
  • the determination of the synthesis data at the encoder may be more suitable, for example when the decoded textures show compression artefacts or when the textures do not include enough redundant information to estimate the synthesis data on the side. customer.
  • said at least one summary data item corresponds to at least part of a depth map.
  • said at least one item of information indicating a mode of obtaining the summary data item is obtained by decoding a syntax element.
  • the information is encoded in the data stream.
  • said at least one item of information indicating a method of obtaining the synthesis data item is obtained from at least one data item coded for the reconstructed coded image.
  • the information is not directly encoded in the data stream, it is derived from the data encoded for an image in the data stream.
  • the process for deriving the synthetic data is here identical to the encoder and to the decoder.
  • the obtaining mode is selected from among the first obtaining mode and the second obtaining mode as a function of a value of a quantization parameter used to encode at least said block.
  • the method further comprises, when said at least one item of information indicates that the summary data item is obtained according to the second mode of obtaining:
  • This particular embodiment of the invention makes it possible to control the method for obtaining the summary data item, for example it may be a question of controlling the functionalities of a depth estimator such as the size of the search window or the precision.
  • the control parameter can also indicate which depth estimator to use, and / or the parameters of this estimator, or a depth map to initialize the estimator.
  • the invention also relates to a device for processing multi-view video data, comprising a processor configured for:
  • the multi-view video data processing device is included in a terminal.
  • the invention also relates to a method for encoding multi-view video data, comprising:
  • the determination for at least one block of an image of a view in an encoded data stream representative of the multi-view video, of at least one item of information indicating a mode for obtaining at least one synthetic datum, from among a first obtaining mode and a second obtaining mode, said at least one synthetic datum being used to synthesize at least one image of an intermediate view of the video multi-view, said intermediate view not being encoded in said encoded data stream, said first mode of obtaining corresponding to a decoding of at least one item of information representative of the at least one summary data item from the data stream encoded, said second mode of obtaining corresponding to obtaining the at least one synthetic data item from at least said reconstructed coded image,
  • the encoding method comprises the encoding in the data stream of a syntax element associated with said information indicating a mode of obtaining the summary data.
  • the coding method further comprises, when the information indicates that the summary data item is obtained according to the second mode of obtaining:
  • the invention also relates to a device for encoding multi-view video data, comprising a processor and a memory configured for:
  • the multi-view video data processing method according to the invention can be implemented in various ways, in particular in wired form or in software form.
  • the multi-view video data processing method is implemented by a computer program.
  • the invention also relates to a computer program comprising instructions for implementing the multi-view video data processing 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 shape.
  • 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 medium 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 medium 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 medium 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 illustrates a diagram for processing multi-view video data according to the prior art.
  • FIG. 2 illustrates a multi-view video data processing diagram according to a particular embodiment of the invention.
  • FIG. 3A illustrates steps of a multi-view video data processing method according to a particular embodiment of the invention.
  • FIG. 3B illustrates steps of a multi-view video data processing method according to another particular embodiment of the invention.
  • FIG. 4A illustrates steps of a multi-view video coding method according to particular embodiments of the invention.
  • FIG. 4B illustrates steps of a method for encoding multi-view video according to particular embodiments of the invention.
  • FIG. 5 illustrates an example of a multi-view video data processing diagram according to a particular embodiment of the invention.
  • FIG. 6A illustrates a texture matrix of a multi-view video according to a particular embodiment of the invention.
  • FIG. 6B illustrates steps of the depth encoding method for a current block according to a particular embodiment of the invention.
  • FIG. 7A illustrates an example of a data flow according to a particular embodiment of the invention.
  • FIG. 7B illustrates an example of a data flow according to another particular embodiment of the invention.
  • FIG. 8 illustrates a multi-view video coding device according to a particular embodiment of the invention.
  • FIG. 9 illustrates a device for processing multi-view video data according to a particular embodiment of the invention.
  • FIG. 1, described above, illustrates a diagram of processing of multi-view video data according to the prior art.
  • the depth information is determined, encoded and transmitted in a data stream to the decoder which decodes it.
  • FIG. 2 illustrates a multi-view video data processing diagram according to a particular embodiment of the invention.
  • the depth information is not encoded in the data stream, but determined on the client side, from the reconstructed images of the multi-view video.
  • the texture images T x o y o and T xiy o from captured views are encoded (CODEC), for example using an MV-HEVC encoder, and sent to a display device d 'a user, for example.
  • CODEC CODEC
  • the T * x0y o and T * xiy0 textures of the views are decoded and used to estimate the depth information D ' x0y o and D' xiy0 associated with each view T x0y o and T xiy0 , by an estimation module FE.
  • the depth information D ' x0y o and D' xiy0 are obtained by depth estimation software (DERS).
  • the decoded views T * x0y o and T * xiy0 and the associated depths of each view D ' x0y o and D' xiy0 are used by a synthesis algorithm (SYNTHESIS) to calculate intermediate views, for example here intermediate views S ' x0y o and S ' xiy0 .
  • the aforementioned VSRS software can be used as a view synthesis algorithm.
  • the complexity of the client terminal is greater than when the depth information is transmitted to the decoder. This may involve using simpler encoder depth estimation algorithms, which may then fail in complex scenes.
  • the texture information does not include enough redundancy to perform the estimation of the depth or of the data useful for the synthesis, for example because of the encoding of the texture information on the server side during which information texture may not be encoded.
  • the invention proposes a method making it possible to select a mode of obtaining synthesis data from among a first mode of obtaining (M1) according to which the synthesis data are encoded and transmitted to the decoder and a second mode of obtaining (M2) according to which summary data is estimated on the client side.
  • M1 first mode of obtaining
  • M2 second mode of obtaining
  • the best path to obtain one or more summary data is selected for each image, or each block or for any other granularity.
  • FIG. 3A illustrates steps of a method for processing multi-view video data according to a particular embodiment of the invention.
  • the selected mode of obtaining is encoded and transmitted to the decoder.
  • a data stream BS comprising in particular texture information from one or more views of a multi-view video is transmitted to the decoder. It is considered, for example, that two views have been coded in the data stream BS.
  • the data stream BS also includes at least one syntax element representative of an item of information indicating a mode of obtaining at least one summary data item, from among a first mode of obtaining M1 and a second mode of obtaining M2.
  • the decoder decodes the texture information of the data stream to obtain the textures T * 0 and T * i.
  • the element of syntax representative of the information indicating a mode of obtaining is decoded from the data stream.
  • This syntax element is encoded in the data stream for at least one block of the texture image of a view. Its value can therefore change for each texture block in a view.
  • the syntax element is coded once for all the blocks of the texture image of a view T 0 or Ti. The information indicating a mode of obtaining synthesis data is therefore the same for all the blocks of the texture image T 0 or Ti.
  • the syntax element is coded once and for all the texture images of the same view or the syntax element is coded once for all the views.
  • step 31 information on the obtaining mode do is then obtained associated with the decoded texture image T * 0 and an information item on the obtaining mode di associated with the decoded texture image T * i.
  • a step 32 it is checked for each item of information d 0 and di indicating a mode of obtaining the synthesis data associated respectively with the decoded texture images T * 0 and T * i if the mode of obtaining corresponds to the first M1 obtaining mode or the second M2 obtaining mode.
  • the synthesis data D * 0 respectively D * i, associated with the decoded texture image T * o, respectively T * i, are decoded from the data stream BS.
  • the synthesis data D + 0 , respectively D + i, associated with the decoded texture image T * 0 , respectively T * i are estimated from the reconstructed texture images of the multi-view video.
  • the estimation can use the decoded texture T * 0 , respectively T * i, and possibly other previously reconstructed texture images.
  • the decoded textures T * 0 and T * i and the decoded (D * 0 , D * i) or estimated (D + 0 , D + i) synthesis information are used to synthesize an image d 'an intermediate view S0.5.
  • FIG. 3B illustrates steps of a multi-view video data processing method according to another particular embodiment of the invention.
  • the selected mode of obtaining is not transmitted to the decoder. This derives the mode of obtaining from the previously decoded texture data.
  • a data stream BS comprising in particular texture information from one or more views of a multi-view video is transmitted to the decoder. It is considered, for example, that two views have been coded in the data stream BS.
  • the decoder decodes the texture information of the data stream to obtain the textures T * 0 and T * i.
  • the decoder obtains information indicating a mode of obtaining from among a first obtaining M1 and a second mode of obtaining M2, at least one data item of synthesis to be used to synthesize an image of an intermediate view.
  • this information can be obtained for each block of the texture image of a view.
  • the obtaining mode can therefore change for each texture block in a view.
  • this information is obtained once for all the blocks of the texture image of a view T * 0 or T * i.
  • the information indicating a mode of obtaining synthesis data is therefore the same for all the blocks of the texture image T * 0 or T * i.
  • the information is obtained once for all the texture images of the same view or the information is obtained once for all the views.
  • step 32 ′ the information is obtained for each texture image of a view.
  • the obtaining mode information is here obtained by applying the same determination process which was applied to the encoder. An example of a determination process is described below in relation to FIG. 4.
  • step 34' if the information do, respectively di, indicates the first mode of obtaining M1, during a step 34', the synthesis data D * 0 , respectively D * i, associated with l
  • the decoded texture image T * 0 , respectively T * i, are decoded from the data stream BS.
  • the synthesis data D + 0 , respectively D + i, associated with the decoded texture image T * 0 , respectively T * i are estimated from the reconstructed texture images of the multi-view video.
  • the estimation can use the decoded texture T * 0 , respectively T * i, and possibly other previously reconstructed texture images.
  • the decoded textures T * 0 and T * i and the decoded (D * 0 , D * i) or estimated (D + 0 , D + i) synthesis information are used to synthesize an image from an intermediate view S0.5.
  • the multi-view video data processing method described here according to particular embodiments of the invention is particularly applicable in the case where the summary data correspond to depth information.
  • the data processing method applies to all types of summary data, such as an object segmentation map.
  • a given view at a given instant of the video can apply the method described above to several types of summary data.
  • these two types of synthesis data can be partially transmitted to the decoder, the other part being derived by the decoder or the synthesis.
  • part of the texture can be estimated, for example by interpolation. The view corresponding to such a texture estimated at the decoder is considered in this case as summary data.
  • the examples described here include two texture views, respectively producing two depth maps, but other combinations are of course possible, including the processing of a depth map at a given time, associated with one or more texture views.
  • FIG. 4A illustrates steps of a multi-view video coding method according to a particular embodiment of the invention.
  • the coding method is described here in the case of two views comprising the textures T 0 and Ti respectively.
  • each texture T 0 and Ti is coded and decoded to provide the decoded textures T * 0 and T * i.
  • the textures can here correspond to an image of a view, or a block of an image of a view or to any other type of granularity relating to the texture information of a multi-view video. .
  • synthesis data for example depth maps D + 0 and D + i are estimated from the decoded textures T * 0 and T * i, using a depth estimator.
  • the synthesis data D 0 and Di are estimated from the uncoded textures To and Ti, for example using a depth estimator.
  • the obtained synthesis data D 0 and Di are then encoded, then decoded to provide reconstructed synthesis data D * 0 and D * i. This is the first method of obtaining M1 summary data.
  • a step 44 it is determined an obtaining mode to be used at the decoder to obtain the synthesis data among the first obtaining mode M1 and the second obtaining mode M2.
  • a syntax element is encoded in the data stream to indicate the selected mode of obtaining.
  • J Di R, where R corresponds to the bit rate, D corresponds to the distortion and l the Lagrangian used for optimization.
  • a first variant is based on the synthesis of an intermediate view or of a block of an intermediate view, in the case where the mode of obtaining is coded for each block, and of evaluating the quality of the synthesized view, in considering the two methods of obtaining summary data.
  • a first version of the intermediate view is therefore synthesized for the obtaining mode M2 from the decoded textures T * 0 and T * i and from the estimated synthesis data D + 0 and D + i from the decoded textures T * 0 and T * i.
  • the flow then corresponds to the cost of encoding of textures T * 0 and T * i and at the cost of encoding the syntax element indicating the selected mode of obtaining.
  • This bit rate can be calculated precisely by using, for example, an entropy coder (for example an arithmetic binary coding, a variable length coding, with or without adaptation of the context).
  • a second version of the intermediate view is also synthesized for the obtaining mode M1 from the decoded textures T * 0 and T * i and from the decoded synthesis data D * 0 and DY
  • the bit rate then corresponds to the cost of coding the textures T * 0 and T * i and summary data D * 0 and D * i to which is added the cost of coding the syntax element indicating the mode of obtaining selected. This rate can be calculated as indicated above.
  • the distortion can be calculated by a metric comparing the image or the block of the synthesized view with the image or the uncoded block of the synthesized view from the non-coded textures T 0 and Ti and the data. synthesis not coded D 0 and Di.
  • the obtaining mode providing the lowest bit rate / distortion cost J is selected.
  • the distortion by applying a metric without reference to the image or the synthesized block to avoid using the original uncompressed texture.
  • a non-reference metric can for example measure in the image or the synthesized block, the amount of noise, blur, block effect, the sharpness of the contours, etc.
  • the selection of the mode is obtained for example by comparing the synthesis data D 0 and Di estimated from the uncompressed textures and the synthesis data D + 0 and D + i estimated from the coded-decoded textures. If the summary data is close enough, according to a determined criterion, the estimation of the summary data on the client side will be more efficient than the encoding and transmission of the summary data. According to this variant, the synthesis of an image or of a block of an intermediate view is avoided.
  • the selection of an obtaining mode may depend on the characteristics of the depth information. For example, computer-generated depth information or high-quality captured depth is more likely to be suitable for M1 obtaining mode.
  • the depth maps can also be estimated from the textures decoded as described above and put into competition with the depth maps generated by computer or captured in high quality. The depth maps generated by computer or captured in high quality then replace the depth maps estimated from the uncompressed textures in the method described above.
  • the quality of the depth can be used to determine a mode of obtaining the summary data.
  • the quality of the depth which can be measured by an appropriate objective metric, can include relevant information. For example, when the quality of the depth is low, or when the temporal coherence of the depth is low, it is probable that the obtaining mode M2 is the most suitable for obtaining the depth information.
  • a syntax element d representative of the mode of obtaining selected is encoded in the data stream .
  • the selected and coded mode corresponds to the first mode of obtaining M1
  • the synthesis data D 0 and Di are also coded in the data stream, for the block or the image considered.
  • additional information can also be coded in the data stream.
  • additional information may correspond to one or more control parameters to be applied to the decoder or by a synthesis module when obtaining said summary data according to the second mode of obtaining. These can be parameters for controlling a summary data estimator, or a depth estimator for example.
  • control parameters can control the functionality of a depth estimator, such as increasing or decreasing the search interval, or increasing or decreasing precision.
  • the control parameters can indicate how a summary data is to be estimated on the decoder side.
  • the control parameters indicate which depth estimator to use.
  • the encoder can test several depth estimators and select the estimator providing the best bitrate / distortion compromise among: a pixel-based depth estimator, an estimator of depth based on triangle-warping, a fast depth estimator, a monocular neural network depth estimator, a neural network depth estimator using multiple references.
  • the encoder informs the decoder or the synthesis module to use a similar synthesis data estimator.
  • control parameters can comprise parameters of a depth estimator such as the disparity interval, the precision, the neural network model, the optimization method or aggregation, energy function smoothing factors, cost functions (color-based, correlation-based, frequency-based), a simple depth map that can be used as an initialization for the client-side depth estimator, etc.
  • FIG. 4B illustrates steps of a multi-view video coding method according to another particular embodiment of the invention.
  • the method of obtaining the summary data is not coded in the data stream, but deduced from the coded information which will be available to the decoder.
  • the coding method is described here in the case of two views comprising the textures To and Ti respectively.
  • each texture T 0 and Ti is coded and decoded to provide the decoded textures T * 0 and T * i.
  • the textures can here correspond to an image of a view, or a block of an image of a view or to any other type of granularity relating to the texture information of a multi-view video. .
  • an obtaining mode is determined to be used at the decoder to obtain the synthesis data from among the first obtaining mode M1 and the second obtaining mode M2.
  • the encoder can use any information that will be available to the decoder, to decide on the obtaining mode which must be applied to the block or to the image considered.
  • the selection of an obtaining mode can be based on a quantization parameter, for example, a QP (for Quantization Parameter) used to encode an image or a texture block. For example, when the quantization parameter is greater than a determined threshold, the second obtaining mode is selected, otherwise the first obtaining mode is selected.
  • a quantization parameter for example, a QP (for Quantization Parameter) used to encode an image or a texture block.
  • QP Quantization Parameter
  • the synthesis data D 0 and Di can be generated by computer or captured in high quality.
  • This type of summary data is more suited to the method of obtaining M1.
  • the mode of obtaining the selected summary data will then be the mode of obtaining M1.
  • metadata must be transmitted to the decoder to indicate the origin of the depth (computer generated, captured in high quality). This information can be transmitted at the view sequence level.
  • the synthesis data D 0 and Di are estimated from the uncoded textures T 0 and Ti , for example using a depth estimator. This estimation is of course not carried out in the case where the summary data come from a computer generation or from a capture in high quality.
  • synthesis data obtained D 0 and Di are then encoded in the data stream.
  • additional information can be obtained. also be encoded in the data stream, during a step 46 '.
  • information can correspond to one or more control parameters to be applied to the decoder or by a synthesis module when obtaining said synthesis data according to the second mode of obtaining.
  • control parameters are similar to those described in relation to FIG. 4A.
  • FIG. 5 illustrates an example of a multi-view video data processing diagram according to a particular embodiment of the invention.
  • a scene is captured by a CAPT video capture system.
  • the view capture system comprises one or more cameras capturing the scene.
  • the scene is captured by two converging cameras, located outside the scene and looking towards the scene from two separate locations.
  • the cameras are therefore at different distances from the scene and have different angles / orientations.
  • Each camera provides a sequence of uncompressed images.
  • the image sequences respectively comprise a sequence of images of texture T 0 and Ti.
  • the texture images T 0 and Ti resulting from the sequences of images respectively supplied by the two cameras are encoded by a COD encoder, for example an MV-HEVC encoder which is a multi-view video encoder.
  • the coder COD supplies a data stream BS which is transmitted to a decoder DEC, for example via a data network.
  • the depth maps D 0 and Di are estimated from the uncompressed textures T 0 and Ti and the depth maps D + 0 and D + i are estimated from the decoded textures T * 0 and T * i using a depth estimator, for example the DERS estimator.
  • a first view T'o located at a position captured by one of the cameras is synthesized, for example here position 0, using the depth map D 0 and a second view T ” 0 located at the same position is synthesized using the depth map D + 0 .
  • the quality of the two synthesized views is compared, for example by calculating the PSNR (for Peak Signal to Noise Ratio) between each of the synthesized views T'o, T ”o and the captured view T 0 located at the same position.
  • the comparison makes it possible to select a mode of obtaining for the depth map D 0 from among a first mode of obtaining according to which the map of depth D 0 is coded and transmitted to the decoder and a second mode of obtaining according to which the map of depth D 0 is encoded and transmitted to the decoder.
  • depth D + 0 is estimated at the decoder.
  • the same process is iterated for the depth map Di associated with the captured texture Ti
  • FIG. 7A illustrates an example of part of a data stream BS according to this particular embodiment of the invention.
  • the data stream BS comprises the coded textures T 0 and Ti and the syntax elements d 0 and di indicating respectively for each of the textures T 0 and Ti the mode of obtaining the depth maps D 0 and Di. If it is decided to code and transmit the depth map D 0 , respectively Di, the value of the syntax element d 0 , respectively di is for example 0, the data stream BS then includes the depth map D 0 , respectively Di, encoded.
  • the data stream BS then does not include the depth map D 0 respectively Di. It may optionally comprise, according to the variant embodiments, one or more PAR control parameters to be applied when obtaining the depth map D + 0 , respectively D + i, by the decoder or by the synthesis module.
  • the encoded data stream BS is then decoded by the decoder DEC.
  • the DEC decoder is included in a smartphone (for smart phone in French) equipped with decoding functions for free navigation.
  • a user looks at the scene from the point of view provided by the first camera. The user then slides their point of view slowly to the left to the other camera. During this process, the smartphone displays intermediate views of the scene that were not captured by the cameras.
  • the data stream BS is scanned and decoded by an MV-HEVC decoder for example, to provide two decoded textures T * 0 and T * i
  • the depth map D + k is estimated at the decoder or by a synthesis module from the decoded textures T * 0 and T * i.
  • a SYNTH synthesis module for example based on a VVS synthesis algorithm (for Versatile View Synthesizer in English), synthesizes intermediate views with the decoded textures T * 0 and T * i and the decoded depth maps D * 0 and D * i or estimated D + 0 and D + i as the case may be to synthesize intermediate views between the views corresponding to textures T 0 and Ti.
  • VVS synthesis algorithm for Versatile View Synthesizer in English
  • the multi-view video data processing scheme described in Fig. 5 is not limited to the embodiment described above.
  • the scene is captured by six omnidirectional cameras located in the scene, from six different locations.
  • Each camera provides a sequence of 2D images in an equi-rectangular projection format (ERP for Equi-Rectangular Projection).
  • the six textures coming from the cameras are encoded using a 3D-HEVC encoder which is a multi-view encoder, providing a data stream BS which is for example transmitted via a data network.
  • a 2x3 matrix of source textures T (textures originating from the cameras) is supplied at the input of the encoder.
  • a source depth map matrix D is estimated from the uncompressed textures using a depth estimator based on a neural network.
  • the texture matrix T is encoded and decoded using the 3D-HEVC encoder providing the decoded texture matrix T * .
  • the T * decoded texture matrix is used to estimate the D + depth map matrix using the neural network based depth estimator.
  • the selection of a mode of obtaining for the depth map associated with a texture is carried out for each block or coding unit (also known under the name of CTU for Coding Tree Unit in English, in the HEVC encoder).
  • FIG. 6B illustrates the steps of the depth encoding method for a current block D x0y o (x, y, t) to be encoded, where x, y corresponds to the position of the upper left corner of the block in the image and t the temporal instant of the image.
  • the depth encoding for the current block D x0y o (0,0,0) is first evaluated by determining an optimal encoding mode among different tools for encoding the depth of a block available to the encoder.
  • Such coding tools can include any type of depth coding tools available in a multi-view coder.
  • the depth D x0y o (0,0,0) of the current block is encoded using a first encoding tool providing a coded-decoded depth D * x0y o (0,0, 0) for the current block.
  • a view at a position of one of the cameras is synthesized using the VVS synthesis software for example. For example, a view at position x1 yO is synthesized using the views decoded at positions xOyO, x2y0, and x1y1 of the T texture matrix.
  • the depth for all blocks in the multi-video views that have not yet been processed comes from the estimated source depth D.
  • the depth for all blocks of the multi-view video for which the depth has already been encoded comes from the encoded-decoded or estimated depth from the textures decoded according to the obtaining mode which was selected for each block.
  • the depth of the current block used for the synthesis of the view at position x1y0 is the coded-decoded depth D * x0y o (0,0,0) according to the coding tool being evaluated.
  • the quality of the synthesized view is evaluated using an error metric, for example a quadratic error, between the synthesized view at position x1y0 and the source view T xiy o, and the coding cost the depth of the current block according to the tool under test is calculated.
  • step 63 it is checked whether all the depth encoding tools have been tested for the current block, and if this is not the case, the steps 60 to 62 are iterated for the encoding tool. next, if not, the method goes to step 64.
  • step 65 another view at the same position as during step 61 is synthesized using the textures decoded at positions xOyO, x2y0 and x1y1 with the VVS software and the estimated current block depth D + x0y o (0,0,0).
  • a step 66 the distortion between the view synthesized at position x1y0 and the source view T xiy0 is calculated and the cost of coding the depth is set to 0, since according to this method of obtaining, the depth n 'is not encoded but estimated at the decoder.
  • a step 67 it is decided according to the bit rate / distortion cost of each mode of obtaining the depth the optimal mode of obtaining.
  • the mode of obtaining the depth minimizing the bit rate / distortion criterion is selected from the encoding of the depth with the optimal encoding tool selected in step 64 and the estimation of the depth at the decoder.
  • a syntax element is encoded in the data stream indicating the obtaining mode selected for the current block. If the obtaining mode selected matches the encoding of the depth, the depth is encoded in the data stream according to the optimal encoding tool selected previously.
  • Steps 60 to 68 are iterated by considering the next block to be processed D x0y o (64,0,0) for example if the first block has a size of 64x64. All the blocks of the depth map associated with the texture of the view at position xOyO are processed correspondingly by taking into account the coded-decoded or estimated depths of the blocks previously processed during view synthesis.
  • the depth maps of the other views are also treated in a similar way.
  • the coded data stream comprises different information for each block. If it has been decided to encode and transmit depth for a given block, the data stream includes for that block, the encoded texture of the block, a block of encoded depth data, and the syntax element indicating the mode of operation. obtaining depth for the block. If it has been decided not to encode the depth for the block, the data stream includes for the block, the encoded texture of the block, a depth information block including a same gray level value, and the syntax element indicating how to get the depth for the block.
  • the data stream may include the textures encoded consecutively for all the blocks, then the depth data and the syntax elements of the blocks.
  • the decoding can for example be carried out via a virtual reality headset equipped with free navigation functionalities, and worn by a user.
  • the user looks at the scene from a point of view provided by one of the six cameras.
  • the user looks around and slowly begins to move around the scene.
  • the headset tracks the user's movement and displays corresponding views of the scene that were not captured by the cameras.
  • the decoder DEC decodes the texture matrix T * from the coded data stream.
  • the syntax elements for each block are also decoded from the encoded data stream.
  • the depth of each block is obtained by decoding the block of depth data encoded for the block or by estimating the depth data from the decoded textures according to the value of the decoded syntax element for the block.
  • An intermediate view is synthesized using the decoded texture matrix T * and the reconstructed depth matrix comprising for each block the depth data obtained as a function of the obtaining mode indicated by the decoded syntax element for the block.
  • the multi-view video data processing diagram described in FIG. 5 also applies in the case where the syntax element is not coded at block level or at the block level. image level.
  • the COD encoder can apply an image level decision mechanism to decide whether the depth should be transmitted to the decoder or estimated after decoding.
  • the encoder which operates in variable bit rate mode, allocates, in a known manner, quantization parameters (QPs) to the blocks of the texture images so as to reach a target overall bit rate.
  • QPs quantization parameters
  • An average of the QPs allocated to each block of a texture image is calculated, optionally using a weighting between blocks. This provides an average PQ for the texture image, representative of an importance level of the image.
  • the encoder decides to calculate the depth map for this image of texture from the uncompressed textures of the multiview video, encode the calculated depth map and pass it into the data stream.
  • the target speed is high speed.
  • the encoder does not calculate the depth for this texture image and proceeds to the next texture image. No depth is encoded for this image, nor any indicator is transmitted to the decoder.
  • FIG. 7B illustrates an example of a part of a data stream encoded according to this particular embodiment of the invention.
  • the encoded data stream includes in particular the encoded textures for each image, here To and Ti.
  • the encoded data stream also includes information making it possible to obtain the average QP of each image. For example, this can be coded at the image level, or else conventionally obtained from the QPs coded for each block in the data stream.
  • the coded data stream also comprises the calculated and coded depth data D 0 and / or Di according to the decision taken by the coder. It is noted here that the syntax elements d 0 and di are not encoded in the data stream.
  • the data stream may include PAR parameters to be applied when estimating the depth. These parameters have already been described above.
  • the decoder DEC runs through the encoded data stream and decodes the texture images T * 0 and T * i.
  • the decoder applies the same decision mechanism as the encoder, by calculating the average QP of each texture image.
  • the decoder then deduces therefrom, using the determined threshold, which can be transmitted in the data stream or well known to the decoder, whether the depth for a given texture image must be decoded or else estimated.
  • the decoder then operates in a manner similar to what has been described in relation to the first embodiment of FIG. 5.
  • FIG. 8 presents 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 described above, in particular in relation to FIGS. 2, 4A and 4B.
  • the COD encoder may for example correspond to the COD encoder described in relation to FIG. 5.
  • 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 memory MEM.
  • the computer program PG comprises instructions for implementing the steps of the coding 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 memory 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. 9 shows the simplified structure of a DTV multi-view video data processing device suitable for implementing the multi-view data processing method according to any one of the particular embodiments of the invention described. previously, in particular in relation to FIGS. 2, 3A, and 3B.
  • the DTV multi-view video data processing device may for example correspond to the SYNTH synthesis module described in relation to FIG. 5 or to a device comprising the SYNTH synthesis module and the decoder DEC of FIG. 5.
  • the DTV multi-view video data processing device has the conventional architecture of a computer and in particular comprises a MEMO memory, a UTO processing unit, equipped for example with a PROCO processor, and controlled by the computer program PGO stored in MEMO memory.
  • the computer program PGO includes instructions for implementing the steps of the multi-view video data processing method as described above, when the program is executed by the PROCO processor.
  • the code instructions of the computer program PGO are for example loaded into a memory before being executed by the processor PROCO.
  • the processor PROCO of the processing unit UTO notably implements the steps of the multi-view video data processing method described above, according to the instructions of the computer program PGO.
  • the DTV multi-view video data processing device comprises a decoder DEC suitable for decoding one or more coded data streams representative of a multi-view video.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

L'invention concerne un procédé de traitement de données d'une vidéo multi-vues selon lequel, pour au moins un bloc d'une image d'une vue codée dans un flux de données codées représentatif de la vidéo multi-vues, au moins une information est obtenue. Cette information indique un mode d'obtention d'au moins une donnée de synthèse, parmi un premier mode d'obtention et un deuxième mode d'obtention, la donnée de synthèse étant utilisée pour synthétiser au moins une image d'une vue intermédiaire de la vidéo multi-vues, ladite vue intermédiaire n'étant pas codée dans ledit flux de données codées. Le premier mode d'obtention correspond à un décodage d'au moins une information représentative de la au moins une donnée de synthèse à partir du flux de données codées, le deuxième mode d'obtention correspond à une obtention de la au moins une donnée de synthèse à partir d'au moins ladite image codée reconstruite. Au moins une partie d'une image de la vue intermédiaire est synthétisée à partir d'au moins ladite image codée reconstruite et ladite au moins une donnée de synthèse obtenue selon le mode d'obtention indiqué.

Description

DESCRIPTION
Procédé et dispositif de traitement de données de 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, incluant les vidéos pour la réalité virtuelle et la navigation libre. Plus particulièrement, l'invention concerne le traitement (codage, décodage, synthèse de vues intermédiaires) de données de telles vidéos.
2. Art Antérieur
Une vidéo immersive permet à un spectateur de regarder une scène de n'importe quel point de vue, même d'un point de vue qui n'a pas été capturé par une caméra. Un système d'acquisition typique est un ensemble de caméras, qui capture une scène avec plusieurs caméras situées en dehors de la scène ou avec des caméras divergentes construites sur une plate-forme sphérique. Les vidéos sont généralement affichées via des casques de réalité virtuelle (aussi connu sous le nom HMD pour Head Mounted Device en anglais), mais peuvent également être affichées sur des écrans 2D dotés d'un système supplémentaire pour interagir avec l'utilisateur.
La navigation libre dans une scène nécessite de gérer correctement chaque mouvement de l'utilisateur afin d'éviter le mal des transports. Le mouvement est généralement correctement capturé par le dispositif d'affichage (un casque HMD par exemple). Cependant, fournir les pixels corrects à l'affichage, quel que soit le mouvement de l'utilisateur (rotationnel ou en translation), est actuellement un problème. Cela nécessite plusieurs vues capturées et la possibilité de générer des vues virtuelles (synthétisées) supplémentaires, calculées à partir des vues capturées décodées et des profondeurs associées. Le nombre de vues à transmettre varie selon les cas d'utilisation. Toutefois, le nombre de vues à transmettre et la quantité de données associées est souvent volumineuse. Par conséquent, la transmission des vues est un aspect essentiel des applications de vidéos immersives. Il est donc nécessaire de réduire autant que possible le débit binaire des informations à transmettre sans compromettre la qualité de la synthèse des vues intermédiaires.
Dans un schéma de traitement de vidéo immersive typique, les vues sont capturées physiquement ou générées par ordinateur. Dans certains cas, les profondeurs sont également capturées avec des capteurs dédiés. Cependant, la qualité de ces informations de profondeurs est généralement mauvaise et empêche de synthétiser efficacement des points de vue intermédiaires. Des cartes de profondeur peuvent également être calculées à partir des images de texture des vidéos capturées. De nombreux algorithmes d'estimation de profondeurs existent et sont utilisés dans l'état de la technique.
Les images de texture et les informations de profondeur estimées sont codées et envoyées à un dispositif d'affichage d'un utilisateur, comme illustré en figure 1 . La figure 1 montre un schéma de traitement de vidéo immersive comprenant par exemple deux vues capturées ayant respectivement les informations de texture Txoyo et Txiy0. Des informations de profondeur Dxoyo et Dxiy0 associées à chaque vue Txoyo et Txi yo sont estimées par un module d’estimation FE. Par exemple, les informations de profondeur Dx0yo et Dxiy0 sont obtenues par un logiciel d'estimation de profondeur (DERS pour Depth Estimation Reference Software en anglais), les vues Txoyo et Txi yo et les informations de profondeur obtenues Dx0yo et Dxiy0 sont ensuite codées (CODEC), par exemple en utilisant un codeur MV-HEVC. Du côté du client, les vues T*x0yo et T* xi yo et les profondeurs associées de chaque vue D*x0yo et D* xiy0 sont décodées et utilisées par un algorithme de synthèse (SYNTHESIS) pour calculer des vues intermédiaires, par exemple ici des vues intermédiaires Sx0yo et Sxiy0. Par exemple, le logiciel VSRS (pour View Synthesis Reference en anglais) peut être utilisé comme algorithme de synthèse de vue. Lorsque les cartes de profondeur sont calculées avant le codage et la transmission des données codées d'une vidéo immersive, différents problèmes sont rencontrés. Notamment, le débit associé à la transmission des différentes vues est important. En particulier, bien que les cartes de profondeur coûtent généralement moins que la texture, elles restent une proportion importante du train de bits (entre 15% et 30% du total).
De plus, des cartes de profondeurs complètes sont générées et envoyées, alors que côté client, toutes les parties de toutes les cartes de profondeurs ne sont pas forcément utiles. En effet, les vues peuvent avoir des informations redondantes, ce qui rend certaines parties de cartes de profondeurs inutiles. De plus, dans certains cas, les spectateurs peuvent demander uniquement des points de vue spécifiques. Sans canal de retour entre le client et le serveur fournissant la vidéo immersive codée, l'estimateur de profondeur situé côté serveur ignore la connaissance de ces points de vue spécifiques.
Le calcul des informations de profondeur côté serveur évite toute interaction entre l'estimateur de profondeur et l'algorithme de synthèse. Par exemple, si un estimateur de profondeur souhaite informer l'algorithme de synthèse du fait qu'il ne peut pas trouver correctement la profondeur d'une zone spécifique, il doit transmettre cette information dans le flux binaire, très probablement sous la forme d'une carte binaire.
De plus, la configuration du codeur pour coder les cartes de profondeur afin d’obtenir le meilleur compromis entre la qualité de la synthèse et le coût de codage pour la transmission des cartes de profondeur n'est pas évidente. Enfin, le nombre de pixels à traiter par un décodeur est élevé lorsque les textures et les cartes de profondeur sont codées, transmises et décodées. Cela peut par exemple ralentir le déploiement des schémas de traitement de vidéos immersives sur des terminaux de type smartphone (pour téléphone intelligent en français).
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 traitement de données d’une vidéo multi-vues, comprenant :
- l'obtention, pour au moins un bloc d’une image d’une vue codée dans un flux de données codées représentatif de la vidéo multi-vues, d’au moins une information indiquant un mode d’obtention d’au moins une donnée de synthèse, parmi un premier mode d’obtention et un deuxième mode d’obtention, ladite au moins une donnée de synthèse étant utilisée pour synthétiser au moins une image d’une vue intermédiaire de la vidéo multi-vues, ladite vue intermédiaire n’étant pas codée dans ledit flux de données codées, ledit premier mode d’obtention correspondant à un décodage d’au moins une information représentative de la au moins une donnée de synthèse à partir du flux de données codées, ledit deuxième mode d’obtention correspondant à une obtention de la au moins une donnée de synthèse à partir d’au moins ladite image codée reconstruite,
- l’obtention de la au moins une donnée de synthèse selon le mode d’obtention indiqué par ladite au moins une information,
- la synthèse d'au moins une partie d’une image de ladite vue intermédiaire à partir d'au moins ladite image codée reconstruite et ladite au moins une donnée de synthèse obtenue. L’invention permet de tirer parti de différents modes d’obtention de données de synthèse de manière flexible en permettant la sélection d’un mode d’obtention de chaque donnée de synthèse qui soit optimal, par exemple en termes de coût de codage/qualité de la donnée de synthèse ou bien en fonction des outils disponibles côté décodeur et/ou côté codeur. Cette sélection est flexible puisqu’elle peut avantageusement être réalisée au niveau bloc, image, vue ou vidéo. Le niveau de granularité du mode d’obtention des données de synthèse peut donc être adapté en fonction du contenu de la vidéo multi-vues par exemple ou bien des outils disponibles côté client/décodeur.
Selon un premier mode d’obtention, la donnée de synthèse est déterminée côté codeur, codée et transmise à un décodeur dans un flux de données. Selon ce premier mode d’obtention, la qualité de la donnée de synthèse peut être privilégiée puisqu’elle est déterminée à partir d’images originales, non codées par exemple. La donnée de synthèse ne souffre pas lors de son estimation des artefacts de codage des textures décodées.
Selon un deuxième mode d’obtention, la donnée de synthèse est déterminée côté décodeur. Selon ce deuxième mode d’obtention, les données nécessaires à la synthèse de vues intermédiaires sont obtenues à partir des vues décodées et reconstruites qui ont été transmises au décodeur. L'obtention de telles données de synthèse peut être réalisée au niveau du décodeur, ou bien par un module indépendant du décodeur prenant en entrée les vues décodées et reconstruites par le décodeur. Ce deuxième mode d’obtention permet de réduire le coût de codage des données de la vidéo multi-vues et le décodage de la vidéo multi- vues est simplifié, puisque le décodeur n'a plus à décoder les données utilisées pour la synthèse de vues intermédiaires.
L’invention permet également d’améliorer la qualité de la synthèse des vues intermédiaires. En effet dans certains cas, une donnée de synthèse estimée au décodeur peut être plus adaptée pour la synthèse de vues qu’une donnée de synthèse codée, par exemple lorsque des estimateurs différents sont disponibles côté client et côté serveur. Dans d’autres cas, la détermination de la donnée de synthèse au codeur peut être plus adaptée, par exemple lorsque les textures décodées présentent des artefacts de compression ou lorsque les textures ne comprennent pas suffisamment d’informations redondantes pour estimer les données de synthèse côté client.
Selon un mode particulier de réalisation de l’invention, ladite au moins une donnée de synthèse correspond à au moins une partie d'une carte de profondeur.
Selon un autre mode particulier de réalisation de l’invention, ladite au moins une information indiquant un mode d’obtention de la donnée de synthèse est obtenue par le décodage d’un élément de syntaxe. Selon ce mode particulier de réalisation de l’invention, l’information est codée dans le flux de données.
Selon un autre mode particulier de réalisation de l’invention, ladite au moins une information indiquant un mode d’obtention de la donnée de synthèse est obtenue à partir d’au moins une donnée codée pour l’image codée reconstruite. Selon ce mode particulier de réalisation de l’invention, l’information n’est pas directement codée dans le flux de données, elle est dérivée des données codées pour une image dans le flux de données. Le processus de dérivation de la donnée de synthèse est ici identique au codeur et au décodeur.
Selon un autre mode particulier de réalisation de l’invention, le mode d’obtention est sélectionné parmi le premier mode d’obtention et le deuxième mode d’obtention en fonction d’une valeur d’un paramètre de quantification utilisé pour coder au moins ledit bloc. Selon un autre mode particulier de réalisation de l’invention, le procédé comprend en outre, lorsque ladite au moins une information indique que la donnée de synthèse est obtenue selon le deuxième mode d’obtention :
- le décodage à partir d'un flux de données codées, d'au moins un paramètre de contrôle,
- l'application dudit paramètre de contrôle lors de l'obtention de ladite donnée de synthèse selon le deuxième mode d’obtention.
Ce mode particulier de réalisation de l'invention permet de contrôler le procédé d'obtention de la donnée de synthèse, par exemple il peut s’agir de contrôler les fonctionnalités d’un estimateur de profondeur telles la taille de la fenêtre de recherche ou la précision. Le paramètre de contrôle peut aussi indiquer quel estimateur de profondeur utiliser, et/ou les paramètres de cet estimateur, ou encore une carte de profondeur pour initialiser l’estimateur.
L’invention concerne également un dispositif de traitement de données de vidéo multi-vues, comprenant un processeur configuré pour :
- obtenir, pour au moins un bloc d’une image d’une vue codée dans un flux de données codées représentatif de la vidéo multi-vues, au moins une information indiquant un mode d’obtention d’au moins une donnée de synthèse, parmi un premier mode d’obtention et un deuxième mode d’obtention, ladite au moins une donnée de synthèse étant utilisée pour synthétiser au moins une image d’une vue intermédiaire de la vidéo multi-vues, ladite vue intermédiaire n’étant pas codée dans ledit flux de données codées, ledit premier mode d’obtention correspondant à un décodage d’au moins une information représentative de la au moins une donnée de synthèse à partir du flux de données codées, ledit deuxième mode d’obtention correspondant à une obtention de la au moins une donnée de synthèse à partir d’au moins ladite image codée reconstruite,
- obtenir la au moins donnée de synthèse selon le mode d’obtention indiqué par ladite au moins une information,
- synthétiser au moins une partie d’une image de ladite vue intermédiaire à partir d'au moins ladite image codée reconstruite et ladite au moins une donnée de synthèse obtenue.
Selon un mode particulier de réalisation de l’invention, le dispositif de traitement de données de vidéo multi-vues est compris dans un terminal.
L’invention concerne aussi un procédé de codage de données de vidéo multi-vues, comprenant :
- la détermination, pour au moins un bloc d’une image d’une vue dans un flux de données codées représentatif de la vidéo multi-vues, d’au moins une information indiquant un mode d’obtention d’au moins une donnée de synthèse, parmi un premier mode d’obtention et un deuxième mode d’obtention, ladite au moins une donnée de synthèse étant utilisée pour synthétiser au moins une image d’une vue intermédiaire de la vidéo multi-vues, ladite vue intermédiaire n’étant pas codée dans ledit flux de données codées, ledit premier mode d’obtention correspondant à un décodage d’au moins une information représentative de la au moins une donnée de synthèse à partir du flux de données codées, ledit deuxième mode d’obtention correspondant à une obtention de la au moins une donnée de synthèse à partir d’au moins ladite image codée reconstruite,
- le codage de ladite image dans le flux de données codées.
Selon un mode particulier de réalisation de l’invention, le procédé de codage comprend le codage dans le flux de données d’un élément de syntaxe associé à ladite information indiquant un mode d’obtention de la donnée de synthèse.
Selon un mode particulier de réalisation de l’invention, le procédé de codage comprend en outre, lorsque l’information indique que la donnée de synthèse est obtenue selon le deuxième mode d’obtention :
- le codage dans un flux de données codées, d'au moins un paramètre de contrôle à appliquer lors de l'obtention de ladite donnée de synthèse selon le deuxième mode d’obtention.
L’invention concerne aussi un dispositif de codage de données de vidéo multi-vues, comprenant un processeur et une mémoire configurés pour :
- déterminer, pour au moins un bloc d’une image d’une vue dans un flux de données codées représentatif de la vidéo multi-vues, au moins une information indiquant un mode d’obtention d’au moins une donnée de synthèse, parmi un premier mode d’obtention et un deuxième mode d’obtention, ladite au moins une donnée de synthèse étant utilisée pour synthétiser au moins une image d’une vue intermédiaire de la vidéo multi-vues, ladite vue intermédiaire n’étant pas codée dans ledit flux de données codées, ledit premier mode d’obtention correspondant à un décodage d’au moins une information représentative de la au moins une donnée de synthèse à partir du flux de données codées, ledit deuxième mode d’obtention correspondant à une obtention de la au moins une donnée de synthèse à partir d’au moins ladite image codée reconstruite,
- coder ladite image dans le flux de données codées.
Le procédé de traitement de données vidéo multi-vues selon l'invention peut ê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 traitement de données vidéo multi-vues est mis en œuvre par un programme d'ordinateur. L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de traitement de données vidéo multi-vues 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. Le support d'enregistrement mentionné ci-avant peut ê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, le support d'enregistrement peut 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, le support d'enregistrement peut 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 un schéma de traitement de données de vidéo multi-vues selon l'art antérieur.
[FIG. 2] La figure 2 illustre un schéma de traitement de données de vidéo multi-vues selon un mode particulier de réalisation de l’invention.
[FIG. 3A] La figure 3A illustre des étapes d'un procédé de traitement de données de vidéo multi-vues selon un mode particulier de réalisation de l'invention.
[FIG. 3B] La figure 3B illustre des étapes d'un procédé de traitement de données de vidéo multi-vues selon un autre mode particulier de réalisation de l'invention.
[FIG. 4A] La figure 4A illustre des étapes d'un procédé de codage de vidéo multi-vues selon des modes particuliers de réalisation de l'invention. [FIG. 4B] La figure 4B illustre des étapes d'un procédé de codage de vidéo multi-vues selon des modes particuliers de réalisation de l'invention.
[FIG. 5] La figure 5 illustre un exemple d’un schéma de traitement de données de vidéo multi- vues selon un mode particulier de réalisation de l’invention.
[FIG. 6A] La figure 6A illustre une matrice de texture d’une vidéo multi-vues selon un mode particulier de réalisation de l’invention.
[FIG. 6B] La figure 6B illustre des étapes du procédé de codage de la profondeur pour un bloc courant selon un mode particulier de réalisation de l’invention.
[FIG. 7A] La figure 7A illustre un exemple d’un flux de données selon un mode particulier de réalisation de l'invention.
[FIG. 7B] La figure 7B illustre un exemple d’un flux de données selon un autre mode particulier de réalisation de l'invention.
[FIG. 8] La figure 8 illustre un dispositif de codage de vidéo multi-vues selon un mode particulier de réalisation de l'invention.
[FIG. 9] La figure 9 illustre un dispositif de traitement de données de vidéo multi-vues selon un mode particulier de réalisation de l'invention.
5. Description d'un mode de réalisation de l'invention
La figure 1 , décrite ci-dessus, illustre un schéma de traitement de données de vidéo multi- vues selon l'art antérieur. Selon ce mode de réalisation, les informations de profondeur sont déterminées, codées et transmises dans un flux de données au décodeur qui les décode.
La figure 2 illustre un schéma de traitement de données de vidéo multi-vues selon un mode particulier de réalisation de l’invention. Selon ce mode particulier de réalisation de l’invention, les informations de profondeur ne sont pas codées dans le flux de données, mais déterminée côté client, à partir des images reconstruites de la vidéo multi-vues.
Selon le schéma illustré en figure 2, les images de texture Txoyo et Txiyo issues de vues capturées sont codées (CODEC), par exemple en utilisant un codeur MV-HEVC, et envoyées à un dispositif d'affichage d'un utilisateur, par exemple. Côté client, les textures T* x0yo et T* xiy0 des vues sont décodées et utilisées pour estimer les informations de profondeurs D’x0yo et D’xiy0 associées à chaque vue Tx0yo et Txiy0, par un module d’estimation FE. Par exemple, les informations de profondeur D’x0yo et D’xiy0 sont obtenues par un logiciel d'estimation de profondeur (DERS).
Les vues décodées T* x0yo et T* xiy0 et les profondeurs associées de chaque vue D’x0yo et D’xiy0 sont utilisées par un algorithme de synthèse (SYNTHESIS) pour calculer des vues intermédiaires, par exemple ici des vues intermédiaires S’x0yo et S’xiy0. Par exemple, le logiciel VSRS précité peut être utilisé comme algorithme de synthèse de vue. Lorsque les informations de profondeur sont estimées après transmission des données codées de la vidéo multi-vues, les problèmes suivants peuvent être rencontrés. A cause des artefacts de compression, par exemple les effets de bloc, ou le bruit de quantification, présents dans les textures décodées et utilisées pour estimer les informations de profondeur, particulièrement à bas débit, des valeurs de profondeur erronées peuvent être obtenues.
De plus, la complexité du terminal client est plus grande que lorsque les informations de profondeur sont transmises au décodeur. Ce qui peut impliquer d’utiliser des algorithmes d’estimation de profondeur plus simple au codeur, qui peuvent alors être mis en défaut dans les scènes complexes.
Côté client, il peut arriver que les informations de texture ne comprennent pas suffisamment de redondance pour réaliser l’estimation de la profondeur ou des données utiles à la synthèse, par exemple à cause du codage des informations de texture côté serveur au cours duquel des informations de texture peuvent ne pas être codées.
L’invention propose une méthode permettant de sélectionner un mode d’obtention des données de synthèse parmi un premier mode d’obtention (M1 ) selon lequel les données de synthèse sont codées et transmises au décodeur et un deuxième mode d’obtention (M2) selon lequel les données de synthèse sont estimées côté client. Cette méthode permet de tirer avantage des deux approches de manière flexible.
Pour cela, le meilleur chemin pour obtenir une ou des données de synthèse est sélectionné pour chaque image, ou chaque bloc ou pour toute autre granularité.
La figure 3A illustre des étapes d'un procédé de traitement de données de vidéo multi-vues selon un mode particulier de réalisation de l'invention. Selon ce mode particulier de réalisation de l’invention, le mode d’obtention sélectionné est codé et transmis au décodeur.
Un flux de données BS comprenant notamment des informations de texture d’une ou plusieurs vues d’une vidéo multi-vues est transmis au décodeur. On considère, par exemple, que deux vues ont été codées dans le flux de données BS.
Le flux de données BS comprend également au moins un élément de syntaxe représentatif d’une information indiquant un mode d’obtention d’au moins une donnée de synthèse, parmi un premier mode d’obtention M1 et un deuxième mode d’obtention M2.
Lors d’une étape 30, le décodeur décode les informations de texture du flux de données pour obtenir les textures T* 0 et T*i.
Lors d’une étape 31 , l’élément de syntaxe représentatif de l’information indiquant un mode d’obtention est décodé à partir du flux de données. Cet élément de syntaxe est codé dans le flux de données pour au moins un bloc de l’image de texture d’une vue. Sa valeur peut donc changer à chaque bloc de texture d’une vue. Selon une autre variante, l’élément de syntaxe est codé une fois pour tous les blocs de l’image de texture d’une vue T0 ou Ti. L’information indiquant un mode d’obtention d’une donnée de synthèse est donc la même pour tous les blocs de l’image de texture T0 ou Ti.
Selon encore une autre variante, l’élément de syntaxe est codé une fois pour toutes les images de texture d’une même vue ou bien l’élément de syntaxe est codé une fois pour toutes les vues.
On considère, ici, la variante selon laquelle l’élément de syntaxe est codé pour chaque image de texture d’une vue. Suite à l’étape 31 , on obtient alors une information de mode d’obtention do associée à l’image de texture décodée T* 0 et une information de mode d’obtention di associée à l’image de texture décodée T*i.
Lors d’une étape 32, il est vérifié pour chaque information d0 et di indiquant un mode d’obtention des données de synthèse associées respectivement aux images de texture décodées T* 0 et T*i si le mode d’obtention correspond au premier mode d’obtention M1 ou au deuxième mode d’obtention M2.
Si l’information do, respectivement di, indique le premier mode d’obtention M1 , lors d’une étape 34, les données de synthèse D* 0, respectivement D*i, associées à l’image de texture décodée T*o, respectivement T*i, sont décodées à partir du flux de données BS.
Si l’information do, respectivement di, indique le deuxième mode d’obtention M2, lors d’une étape 33, les données de synthèse D+ 0, respectivement D+i, associées à l’image de texture décodée T* 0, respectivement T*i, sont estimées à partir des images de texture reconstruites de la vidéo multi-vues. Pour cela, l’estimation peut utiliser la texture décodée T* 0, respectivement T*i , et éventuellement d’autres images de texture préalablement reconstruites. Lors d’une étape 35, les textures décodées T* 0 et T*i et les informations de synthèse décodées (D* 0, D*i) ou estimées (D+ 0, D+i) sont utilisées pour synthétiser une image d’une vue intermédiaire S0.5.
La figure 3B illustre des étapes d'un procédé de traitement de données de vidéo multi-vues selon un autre mode particulier de réalisation de l'invention. Selon cet autre mode particulier de réalisation de l’invention, le mode d’obtention sélectionné n’est pas transmis au décodeur. Celui-ci dérive le mode d’obtention à partir des données de texture préalablement décodées. Un flux de données BS comprenant notamment des informations de texture d’une ou plusieurs vues d’une vidéo multi-vues est transmis au décodeur. On considère, par exemple, que deux vues ont été codées dans le flux de données BS.
Lors d’une étape 30’, le décodeur décode les informations de texture du flux de données pour obtenir les textures T* 0 et T*i.
Lors d’une étape 32’, le décodeur obtient une information indiquant un mode d’obtention parmi un premier d’obtention M1 et un deuxième mode d’obtention M2, d’au moins une donnée de synthèse à utiliser pour synthétiser une image d’une vue intermédiaire. Selon une variante, cette information peut être obtenue pour chaque bloc de l’image de texture d’une vue. Le mode d’obtention peut donc changer à chaque bloc de texture d’une vue.
Selon une autre variante, cette information est obtenue une fois pour tous les blocs de l’image de texture d’une vue T* 0 ou T*i. L’information indiquant un mode d’obtention d’une donnée de synthèse est donc la même pour tous les blocs de l’image de texture T* 0 ou T*i.
Selon encore une autre variante, l’information est obtenue une fois pour toutes les images de texture d’une même vue ou bien l’information est obtenue une fois pour toutes les vues.
On considère, ici, la variante selon laquelle l’information est obtenue pour chaque image de texture d’une vue. Suite à l’étape 32’, on obtient alors une information de mode d’obtention d0 associée à l’image de texture décodée T* 0et une information de mode d’obtention di associée à l’image de texture décodée T*i. L’information de mode d’obtention est ici obtenue en appliquant le même processus de détermination qui a été appliqué au codeur. Un exemple de processus de détermination est décrit plus loin en relation avec la figure 4.
Suite à l’étape 32’, si l’information do, respectivement di, indique le premier mode d’obtention M1 , lors d’une étape 34’, les données de synthèse D* 0, respectivement D*i, associées à l’image de texture décodée T* 0, respectivement T*i , sont décodées à partir du flux de données BS.
Si l’information do, respectivement di, indique le deuxième mode d’obtention M2, lors d’une étape 33’, les données de synthèse D+ 0, respectivement D+i, associées à l’image de texture décodée T* 0, respectivement T*i, sont estimées à partir des images de texture reconstruites de la vidéo multi-vues. Pour cela, l’estimation peut utiliser la texture décodée T* 0, respectivement T*i , et éventuellement d’autres images de texture préalablement reconstruites. Lors d’une étape 35’, les textures décodées T* 0 et T*i et les informations de synthèse décodées (D* 0, D*i) ou estimées (D+ 0, D+i) sont utilisées pour synthétiser une image d’une vue intermédiaire S0.5.
Le procédé de traitement de données de vidéo multi-vues décrit ici selon des modes particuliers de réalisation de l’invention s’applique notamment dans le cas où les données de synthèse correspondent à des informations de profondeur. Toutefois, le procédé de traitement de données s’applique à tous types de données de synthèse, tel qu’une carte de segmentation en objets.
Il est possible pour une vue donnée à un instant donné de la vidéo d’appliquer le procédé décrit ci-dessus à plusieurs types de données de synthèse. Par exemple, si le module de synthèse est aidé par une carte de profondeur et une carte de segmentation en objets, ces deux types de données de synthèse peuvent être partiellement transmis au décodeur, l’autre partie étant dérivée par le décodeur ou le module de synthèse. Il est à noter également qu’une partie de la texture peut être estimée, par exemple par interpolation. La vue correspondant à une telle texture estimée au décodeur est considérée dans ce cas comme une donnée de synthèse.
Les exemples décrits ici comprennent deux vues de texture, produisant respectivement deux cartes de profondeur, mais d’autres combinaisons sont bien sûr possibles, incluant le traitement d’une carte de profondeur à un instant donné, associée à une ou plusieurs vues de textures.
La figure 4A illustre des étapes d'un procédé de codage de vidéo multi-vues selon un mode particulier de réalisation de l'invention. Le procédé de codage est décrit ici dans le cas de deux vues comprenant respectivement les textures T0 et Ti.
Lors d’une étape 40, chaque texture T0 et Ti est codée et décodée pour fournir les textures décodées T* 0 et T*i . Il est à noter que les textures peuvent ici correspondre à une image d’une vue, ou bien un bloc d’une image d’une vue ou à tout autre type de granularité relative à des informations de texture d’une vidéo multi-vues.
Lors d’une étape 41 , des données de synthèse, par exemple des cartes de profondeur D+ 0 et D+i sont estimées à partir des textures décodées T* 0 et T*i, en utilisant un estimateur de profondeur. Il s’agit ici du deuxième mode d’obtention M2 des données de synthèse.
Lors d’une étape 42, les données de synthèse D0 et Di sont estimées à partir des textures non codées To et Ti, par exemple en utilisant un estimateur de profondeur. Lors d’une étape 43, les données de synthèse obtenues D0 et Di sont ensuite codées, puis décodées pour fournir des données de synthèse reconstruites D* 0 et D*i. Il s’agit ici du premier mode d’obtention M1 des données de synthèse.
Lors d’une étape 44, il est déterminé un mode d’obtention à utiliser au décodeur pour obtenir les données de synthèse parmi le premier mode d’obtention M1 et le deuxième mode d’obtention M2.
Selon un mode particulier de réalisation de l’invention, un élément de syntaxe est codé dans le flux de données pour indiquer le mode d’obtention sélectionné. Selon ce mode particulier de réalisation de l’invention, différentes variantes sont possibles en fonction de la manière dont le débit et la distorsion sont évalués selon le critère à minimiser J=D-i R, où R correspond au débit, D correspond à la distorsion et l le lagrangien utilisé pour l’optimisation.
Une première variante repose sur la synthèse d’une vue intermédiaire ou d’un bloc d’une vue intermédiaire, dans le cas où le mode d’obtention est codé pour chaque bloc, et d’évaluer la qualité de la vue synthétisée, en considérant les deux modes d’obtention des données de synthèse. Une première version de la vue intermédiaire est donc synthétisée pour le mode d’obtention M2 à partir des textures décodées T* 0 et T*i et des données de synthèses estimées D+ 0 et D+i à partir des textures décodées T* 0 et T*i. Le débit correspond alors au coût de codage des textures T* 0 et T*i et au coût de codage de l’élément de syntaxe indiquant le mode d’obtention sélectionné. Ce débit peut être calculé de manière précise par l’utilisation par exemple d’un codeur entropique (par exemple un codage binaire arithmétique, un codage à longueur variable, avec ou sans adaptation du contexte).
Une deuxième version de la vue intermédiaire est également synthétisée pour le mode d’obtention M1 à partir des textures décodées T* 0 et T*i et des données de synthèse décodées D* 0 et DY Le débit correspond alors au coût de codage des textures T* 0 et T*i et des données de synthèse D* 0 et D*i auquel s’ajoute le coût de codage de l’élément de syntaxe indiquant le mode d’obtention sélectionné. Ce débit peut être calculé comme indiqué ci-dessus.
Dans les deux cas, la distorsion peut être calculée par une métrique comparant l’image ou le bloc de la vue synthétisée avec l’image ou le bloc non codé de la vue synthétisée à partir des textures non codées T0 et Ti et des données de synthèse non codées D0 et Di.
Le mode d’obtention fournissant le coût débit/distorsion J le plus faible est sélectionné.
Selon une autre variante, il est possible de déterminer la distorsion en appliquant une métrique sans référence sur l’image ou le bloc synthétisé pour éviter d’utiliser la texture originale non compressée. Une telle métrique sans référence peut par exemple mesurer dans l’image ou le bloc synthétisé, la quantité de bruit, de flou, d’effet de bloc, la netteté des contours, etc... Selon une autre variante, la sélection du mode d’obtention est faite par exemple en comparant les données de synthèse D0 et Di estimées à partir des textures non compressées et les données de synthèse D+ 0 et D+i estimées à partir des textures codées-décodées. Si les données de synthèse sont assez proches, selon un critère déterminé, l’estimation des données de synthèse côté client sera plus efficace que le codage et la transmission des données de synthèse. Selon cette variante, on évite la synthèse d’une image ou d’un bloc d’une vue intermédiaire.
D’autres variantes sont également possibles pour déterminer un mode d’obtention des données de synthèse, lorsque celles-ci correspondent à des cartes de profondeur. La sélection d’un mode d’obtention peut par exemple dépendre des caractéristiques de l’information de profondeur. Par exemple, une information de profondeur générée par ordinateur ou une profondeur capturée de haute qualité sont plus susceptibles d’être adaptées au mode d’obtention M1. Selon cette variante, les cartes de profondeur peuvent également être estimées à partir des textures décodées comme décrit ci-dessus et mises en compétition avec les cartes de profondeur générées par ordinateur ou capturées en haute qualité. Les cartes de profondeur générées par ordinateur ou capturées en haute qualité remplacent alors les cartes de profondeur estimées à partir des textures non compressées dans le procédé décrit ci-dessus.
Selon une autre variante, la qualité de la profondeur peut être utilisée pour déterminer un mode d’obtention des données de synthèse. La qualité de la profondeur, qui peut être mesurée par une métrique objective appropriée, peut comprendre des informations pertinentes. Par exemple, lorsque la qualité de la profondeur est faible, ou lorsque la cohérence temporelle de la profondeur est faible, il est probable que le mode d’obtention M2 soit le plus adapté pour obtenir les informations de profondeur.
Une fois que le mode d’obtention des données de synthèse est sélectionné à l’issu de l’étape 44, lors d’une étape 45, un élément de syntaxe d représentatif du mode d’obtention sélectionné est codé dans le flux de données. Lorsque le mode sélectionné et codé correspond au premier mode d’obtention M1 , les données de synthèse D0 et Di sont également codées dans le flux de données, pour le bloc ou l’image considérée.
Selon un mode particulier de réalisation de l’invention, lorsque le mode sélectionné et codé correspond au deuxième mode d’obtention M2, lors d’une étape 46, des informations supplémentaires peuvent également être codées dans le flux de données. Par exemple, de telles informations peuvent correspondre à un ou des paramètres de contrôle à appliquer au décodeur ou par un module de synthèse lors de l'obtention de ladite donnée de synthèse selon le deuxième mode d’obtention. Il peut s’agit de paramètres permettant de contrôler un estimateur de données de synthèse, ou de profondeur par exemple.
Par exemple, les paramètres de contrôle peuvent contrôler les fonctionnalités d’un estimateur de profondeur, tel qu’augmenter ou diminuer l’intervalle de recherche, ou augmenter ou diminuer la précision.
Les paramètres de contrôle peuvent indiquer comment une donnée de synthèse doit être estimée côté décodeur. Par exemple, les paramètres de contrôle indiquent quel estimateur de profondeur utiliser. Par exemple, lors de l’étape 41 d’estimation des cartes de profondeur, l’encodeur peut tester plusieurs estimateurs de profondeur et sélectionner l’estimateur fournissant le meilleur compromis débit/distorsion parmi : un estimateur de profondeur basé pixel, un estimateur de profondeur basé sur des déformations triangulaires (triangle-warping en anglais), un estimateur de profondeur rapide, un estimateur de profondeur à réseaux de neurones monoculaires, un estimateur de profondeur à réseaux de neurones utilisant de multiples références. Selon cette variante, le codeur informe le décodeur ou le module de synthèse d’utiliser un estimateur de données de synthèse similaire.
Selon une autre variante ou en complément de la variante précédente, les paramètres de contrôle peuvent comprendre des paramètres d’un estimateur de profondeur tels que l’intervalle de disparité, la précision, le modèle de réseau de neurones, la méthode d’optimisation ou d’agrégation, les facteurs de lissage des fonctions d’énergie, les fonctions de coût (basée couleur, basée corrélation, basée fréquence), une carte de profondeur simple pouvant servir d’initialisation à l’estimateur de profondeur côté client, etc.... La figure 4B illustre des étapes d'un procédé de codage de vidéo multi-vues selon un autre mode particulier de réalisation de l'invention. Selon le mode particulier de réalisation décrit ici, le mode d’obtention des données de synthèse n’est pas codé dans le flux de données, mais déduit à partir des informations codées qui seront disponibles au décodeur.
Le procédé de codage est décrit ici dans le cas de deux vues comprenant respectivement les textures To et Ti.
Lors d’une étape 40’, chaque texture T0 et Ti est codée et décodée pour fournir les textures décodées T* 0 et T*i . Il est à noter que les textures peuvent ici correspondre à une image d’une vue, ou bien un bloc d’une image d’une vue ou à tout autre type de granularité relative à des informations de texture d’une vidéo multi-vues.
Lors d’une étape 44’, il est déterminé un mode d’obtention à utiliser au décodeur pour obtenir les données de synthèse parmi le premier mode d’obtention M1 et le deuxième mode d’obtention M2.
Selon le mode particulier de réalisation décrit ici, le codeur peut utiliser toute d’information qui sera disponible au décodeur, pour décider du mode d’obtention qui doit être appliqué au bloc ou à l’image considérée.
Selon une variante, la sélection d’un mode d’obtention peut être basée sur un paramètre de quantification, par exemple, un QP (pour Quantization Parameter en anglais) utilisé pour coder une image ou un bloc de texture. Par exemple, lorsque le paramètre de quantification est supérieur à un seuil déterminé, le deuxième mode d’obtention est sélectionné, sinon le premier mode d’obtention est sélectionné.
Selon une autre variante, lorsque les données de synthèse correspondent à des informations de profondeur, les données de synthèse D0 et Di peuvent être générées par ordinateur ou capturées en haute qualité. Ce type de données de synthèse est plus adapté au mode d’obtention M1. Ainsi, lorsque c’est le cas, le mode d’obtention des données de synthèse sélectionné sera alors le mode d’obtention M1 . Selon cette variante, une métadonnée doit être transmise au décodeur pour indiquer l’origine de la profondeur (générée par ordinateur, capturée en haute qualité). Cette information peut être transmise au niveau séquence de vues. A l’issue de l’étape 44’, si le premier mode d’obtention M1 est sélectionné, lors d’une étape 42’, les données de synthèse D0 et Di sont estimées à partir des textures non codées T0 et Ti , par exemple en utilisant un estimateur de profondeur. Cette estimation n’est bien sûr pas réalisée dans le cas où les données de synthèse sont issues d’une génération par ordinateur ou d’une capture en haute qualité.
Lors d’une étape 47’, les données de synthèse obtenues D0 et Di sont ensuite codées dans le flux de données.
Lorsque le mode d’obtention sélectionné correspond au deuxième mode d’obtention M2, selon un mode particulier de réalisation de l’invention, des informations supplémentaires peuvent également être codées dans le flux de données, lors d’une étape 46’. Par exemple, de telles informations peuvent correspondre à un ou des paramètres de contrôle à appliquer au décodeur ou par un module de synthèse lors de l'obtention de ladite donnée de synthèse selon le deuxième mode d’obtention. De tels paramètres de contrôle sont similaires à ceux décrits en relation avec la figure 4A.
La figure 5 illustre un exemple d’un schéma de traitement de données de vidéo multi-vues selon un mode particulier de réalisation de l’invention.
Selon un mode particulier de réalisation de l’invention, une scène est capturée par un système de capture de vidéo CAPT. Par exemple, le système de capture de vues comprend une ou plusieurs caméras capturant la scène.
Selon l’exemple décrit ici, la scène est capturée par deux caméras convergentes, localisées en-dehors de la scène et regardant vers la scène depuis deux emplacements distincts. Les caméras sont donc à des distances différentes de la scène et ont des angles/orientations différents. Chaque caméra fournit une séquence d’images non compressées. Les séquences d’images comprennent respectivement une séquence d’images de texture T0 et Ti.
Les images de texture T0 et Ti issues des séquences d’images fournies respectivement par les deux caméras sont codées par un codeur COD, par exemple un codeur MV-HEVC qui est un codeur vidéo multi-vues. Le codeur COD fournit un flux de données BS qui est transmis à un décodeur DEC, par exemple via un réseau de données.
Lors du codage, les cartes de profondeur D0 et Di sont estimées à partir des textures non compressées T0 et Ti et les cartes de profondeur D+ 0 et D+i sont estimées à partir des textures décodées T* 0 et T*i en utilisant un estimateur de profondeur, par exemple l’estimateur DERS. Une première vue T’o localisée à une position capturée par une des caméras est synthétisée, par exemple ici la position 0, en utilisant la carte de profondeur D0 et une deuxième vue T”0 localisée à la même position est synthétisée en utilisant la carte de profondeur D+ 0. La qualité des deux vues synthétisées est comparée, en calculant par exemple le PSNR (pour Peak Signal to Noise Ratio en anglais) entre chacune des vues synthétisées T’o, T”o et la vue capturée T0 localisée à la même position. La comparaison permet de sélectionner un mode d’obtention pour la carte de profondeur D0 parmi un premier mode d’obtention selon lequel la carte de profondeur D0 est codée et transmise au décodeur et un deuxième mode d’obtention selon lequel la carte de profondeur D+ 0 est estimée au décodeur. Le même procédé est itéré pour la carte de profondeur Di associée à la texture capturée Ti
La figure 7A illustre un exemple d’une partie d’un flux de données BS selon ce mode particulier de réalisation de l’invention. Le flux de données BS comprend les textures T0 et Ti codées et les éléments de syntaxe d0 et di indiquant respectivement pour chacune des textures T0 et Ti le mode d’obtention des cartes de profondeur D0 et Di. S’il est décidé de coder et transmettre la carte de profondeur D0, respectivement Di, la valeur de l’élément de syntaxe d0, respectivement di est par exemple 0, le flux de données BS comprend alors la carte de profondeur D0, respectivement Di, codée.
S’il est décidé de ne pas coder la carte de profondeur D0, respectivement Di, la valeur de l’élément de syntaxe d0, respectivement di est par exemple 1 , le flux de données BS ne comprend alors pas la carte de profondeur D0 respectivement Di. Il peut éventuellement comprendre, selon les variantes de réalisation, un ou des paramètres de contrôle PAR à appliquer lors de l’obtention la carte de profondeur D+ 0, respectivement D+i, par le décodeur ou par le module de synthèse.
Le flux de données codées BS est ensuite décodé par le décodeur DEC. Par exemple, le décodeur DEC est compris dans un smartphone (pour téléphone intelligent en français) équipé de fonctionnalités de décodage de navigation libre. Selon cet exemple, un utilisateur regarde la scène du point de vue fourni par la première caméra. Puis, l’utilisateur fait glisser son point de vue lentement vers la gauche jusqu’à l’autre caméra. Pendant ce processus, le smartphone affiche des vues intermédiaires de la scène qui n’ont pas été capturées par les caméras.
Pour cela, le flux de données BS est parcouru et décodé par un décodeur MV-HEVC par exemple, pour fournir deux textures décodées T* 0 et T*i L’élément de syntaxe dk, avec k=0 ou 1 , associé à chaque texture est décodé. Si la valeur de l’élément de syntaxe dk est 0, le décodeur décode alors la carte de profondeur D* k à partir du flux de données BS.
Si la valeur de l’élément de syntaxe dk est 1 , la carte de profondeur D+ k est estimée au décodeur ou par un module de synthèse à partir des textures décodées T* 0 et T*i.
Un module de synthèse SYNTH, par exemple basé sur un algorithme de synthèse VVS (pour Versatile View Synthesizer en anglais), synthétise des vues intermédiaires avec les textures décodées T* 0 et T*i et les cartes de profondeur décodées D* 0 et D*i ou estimées D+ 0 et D+i selon le cas pour synthétiser des vues intermédiaires comprises entre les vues correspondant aux textures T0 et Ti.
Le schéma de traitement de données de vidéo multi-vues décrit en figure 5 n’est pas limité au mode de réalisation décrit ci-dessus.
Selon un autre mode particulier de réalisation de l’invention, la scène est capturée par six caméras omnidirectionnelles localisées dans la scène, à partir de six localisations différentes. Chaque caméra fournit une séquence d’images 2D selon un format de projection equi- rectangulaire (ERP pour Equi-Rectangular Projection en anglais). Les six textures issues des caméras sont codées à l’aide d’un codeur 3D-HEVC qui est un codeur multi-vues, fournissant un flux de données BS qui est par exemple transmis via un réseau de données. Lors du codage de la séquence multi-vues, une matrice 2x3 de textures source T (textures issues des caméras) est fournie en entrée du codeur. La figure 6A illustre une telle matrice de texture comprenant les textures TXiyj avec i =0, 1 ou 2 et j= 0, 1 ou 2.
Selon le mode de réalisation décrit ici, une matrice de cartes de profondeur source D est estimée à partir des textures non compressées en utilisant un estimateur de profondeur basé sur un réseau de neurones. La matrice de texture T est codée et décodée en utilisant le codeur 3D-HEVC fournissant la matrice de textures décodées T*. La matrice de textures décodées T* est utilisée pour estimer la matrice de cartes de profondeur D+ en utilisant l’estimateur de profondeur basé sur le réseau de neurones.
Selon le mode particulier de réalisation de l’invention décrit ici, la sélection d’un mode d’obtention pour la carte de profondeur associée à une texture est réalisée pour chaque bloc ou unité de codage (aussi connu sous le nom de CTU pour Coding Tree Unit en anglais, dans le codeur HEVC).
La figure 6B illustre les étapes du procédé de codage de la profondeur pour un bloc courant Dx0yo(x,y,t) à coder, où x,y correspond à la position du coin supérieur gauche du bloc dans l’image et t l’instant temporel de l’image.
On considère le premier bloc de la première carte de profondeur à coder à l’instant t=0 de la séquence vidéo, identifié par Dx0yo(0,0,0) par la suite. Lors du codage de ce premier bloc Dx0yo(0,0,0), on considère que la profondeur pour tous les autres blocs qui n’ont pas encore été traités provient de la profondeur source estimée D. Les autres blocs qui n’ont pas encore été traités appartiennent aussi bien à la vue courante xOyO qu’aux autres vues voisines.
Le codage de la profondeur pour le bloc courant Dx0yo(0,0,0) est d’abord évalué en déterminant un mode de codage optimal parmi différents outils de codage de la profondeur d’un bloc disponible au codeur. De tels outils de codage peuvent comprendre tout type d’outils de codage de profondeur disponibles dans un codeur multi-vues.
Lors d’une étape 60, la profondeur Dx0yo(0,0,0) du bloc courant est codée à l’aide d’un premier outil de codage fournissant une profondeur codée-décodée D* x0yo(0,0,0) pour le bloc courant. Lors d’une étape 61 , une vue à une position d’une des caméras est synthétisée à l’aide du logiciel de synthèse VVS par exemple. Par exemple, une vue à la position x1 yO est synthétisée en utilisant les vues décodées aux positions xOyO, x2y0 et x1y1 de la matrice de textures T. Lors de la synthèse de la vue, la profondeur pour tous les blocs de la vidéo multi-vues qui n’ont pas encore été traités provient de la profondeur source estimée D. La profondeur pour tous les blocs de la vidéo multi-vues pour lesquels la profondeur a déjà été codée, provient de la profondeur codé-décodée ou estimée à partir des textures décodées selon le mode d’obtention qui a été sélectionné pour chaque bloc. La profondeur du bloc courant utilisée pour la synthèse de la vue à la position x1y0 est la profondeur codée-décodée D* x0yo(0,0,0) selon l’outil de codage en cours d’évaluation. Lors de l’étape 62, la qualité de la vue synthétisée est évaluée en utilisant une métrique d’erreur, par exemple une erreur quadratique, entre la vue synthétisée à la position x1y0 et la vue source Txiyo, et le coût de codage de la profondeur du bloc courant selon l’outil testé est calculé.
Lors d’une étape 63, il est vérifié si tous les outils de codage de la profondeur ont été testés pour le bloc courant, et si ce n’est pas le cas, les étapes 60 à 62 sont itérées pour l’outil de codage suivant, sinon, le procédé passe à l’étape 64.
Lors de l’étape 64, l’outil de codage de la profondeur fournissant le meilleur compromis débit/distorsion est sélectionné, par exemple celui qui minimise le critère débit/distorsion J=D+XR.
Lors d’une étape 65, une autre vue à la même position que lors de l’étape 61 est synthétisée en utilisant les textures décodées aux positions xOyO, x2y0 et x1y1 avec le logiciel VVS et la profondeur du bloc courant estimée D+ x0yo(0,0,0).
Lors d’une étape 66, la distorsion entre la vue synthétisée à la position x1y0 et la vue source Txiy0, est calculée et le coût de codage de la profondeur est mis à 0, puisque selon ce mode d’obtention, la profondeur n’est pas codée mais estimée au décodeur.
Lors d’une étape 67, il est décidé en fonction du coût débit/distorsion de chaque mode d’obtention de la profondeur le mode d’obtention optimal. Autrement dit, le mode d’obtention de la profondeur minimisant le critère débit/distorsion est sélectionné parmi le codage de la profondeur avec l’outil de codage optimal sélectionné lors de l’étape 64 et l’estimation de la profondeur au décodeur.
Lors d’une étape 68, un élément de syntaxe est codé dans le flux de données indiquant le mode d’obtention sélectionné pour le bloc courant. Si le mode d’obtention sélectionné correspond au codage de la profondeur, la profondeur est codée dans le flux de données selon l’outil de codage optimal sélectionné précédemment.
Les étapes 60 à 68 sont itérées en considérant le bloc suivant à traiter Dx0yo(64,0,0) par exemple si le premier bloc à une taille 64x64. T ous les blocs de la carte de profondeur associée à la texture de la vue à la position xOyO sont traités de manière correspondante en prenant en compte les profondeurs codées-décodées ou estimées des blocs précédemment traités lors de la synthèse de vue.
Les cartes de profondeur des autres vues sont également traitées de manière similaire.
Selon ce mode particulier de réalisation de l’invention, le flux de données codées comprend différentes informations pour chaque bloc. S’il a été décidé de coder et transmettre la profondeur pour un bloc donné, le flux de données comprend pour ce bloc, la texture codée du bloc, un bloc de données de profondeur codées et l’élément de syntaxe indiquant le mode d’obtention de la profondeur pour le bloc. S’il a été décidé de ne pas coder la profondeur pour le bloc, le flux de données comprend pour le bloc, la texture codée du bloc, un bloc d’information de profondeur comprenant une même valeur de niveau de gris, et l’élément de syntaxe indiquant le mode d’obtention de la profondeur pour le bloc.
Il est à noter que dans certains cas, le flux de données peut comprendre les textures codées de manières consécutives pour tous les blocs, puis les données de profondeur et les éléments de syntaxe des blocs.
Le décodage peut par exemple être réalisé via un casque de réalité virtuelle équipé de fonctionnalités de navigation libre, et porté par un utilisateur. L’utilisateur regarde la scène d’un point de vue fourni par une des six caméras. L’utilisateur regarde autour et commence lentement à se déplacer à l’intérieur de la scène. Le casque suit le mouvement de l’utilisateur et affiche des vues correspondantes de la scène qui n’ont pas été capturées par les caméras. Pour cela, le décodeur DEC décode la matrice de texture T* à partir du flux de données codées. Les éléments de syntaxe pour chaque bloc sont également décodés à partir du flux de données codées. La profondeur de chaque bloc est obtenue par le décodage du bloc de données de profondeur codées pour le bloc ou par l’estimation des données de profondeur à partir des textures décodées selon la valeur de l’élément de syntaxe décodé pour le bloc.
Une vue intermédiaire est synthétisée en utilisant la matrice de texture décodée T* et la matrice de profondeur reconstruite comprenant pour chaque bloc les données de profondeur obtenues en fonction du mode d’obtention indiqué par l’élément de syntaxe décodé pour le bloc.
Selon un autre mode particulier de réalisation de l’invention, le schéma de traitement de données de vidéo multi-vues décrit en figure 5 s’applique également dans le cas où l’élément de syntaxe n’est pas codé au niveau bloc ou au niveau image.
Par exemple, le codeur COD peut appliquer un mécanisme de décision au niveau image pour décider si la profondeur doit être transmise au décodeur ou estimée après le décodage.
Pour cela, le codeur, qui fonctionne en mode débit variable, alloue, de manière connue, des paramètres de quantification (QPs) aux blocs des images de texture de sorte à atteindre un débit global cible.
Une moyenne des QPs alloués à chaque bloc d’une image de texture est calculée, en utilisant éventuellement une pondération entre blocs. Ceci fournit un QP moyen pour l’image de texture, représentatif d’un niveau d’importance de l’image.
Si le QP moyen obtenu est au-dessus d’un seuil déterminé, cela signifie que le débit visé est un bas débit. Le codeur décide alors de calculer la carte de profondeur pour cette image de texture à partir des textures non compressées de la vidéo multi-vues, de coder la carte de profondeur calculée et de la transmettre dans le flux de données.
Si le QP moyen est au-dessous ou égal au seuil déterminé, le débit visé est un haut débit. Le codeur ne calcule pas la profondeur pour cette image de texture et passe à l’image de texture suivante. Aucune profondeur n’est codée pour cette image, ni aucun indicateur n’est transmis au décodeur.
La figure 7B illustre un exemple d’une partie de flux de données codées selon ce mode particulier de réalisation de l'invention.
Le flux de données codées comprend notamment les textures codées pour chaque image, ici To et Ti Le flux de données codées comprend également des informations permettant d’obtenir le QP moyen de chaque image. Par exemple celui-ci peut être codé au niveau image, ou bien classiquement obtenu à partir des QPs codés pour chaque bloc dans le flux de données.
Pour chaque image de texture T0 et T 1 , le flux de données codées comprend également les données de profondeur calculées et codées D0 et/ou Di selon la décision prise au codeur. On remarque ici que les éléments de syntaxe d0 et di ne sont pas codés dans le flux de données. Lorsqu’il a été décidé d’estimer la profondeur pour une image de texture au décodeur, le flux de données peut comprendre des paramètres PAR à appliquer lors de l’estimation de la profondeur. Ces paramètres ont déjà été décrits plus haut.
Le décodeur DEC parcourt le flux de données codées et décode les images de textures T* 0 et T*i Le décodeur applique le même mécanisme de décision que le codeur, en calculant le QP moyen de chaque image de texture. Le décodeur en déduit ensuite, à l’aide du seuil déterminé, qui peut être transmis dans le flux de données ou bien connu du décodeur, si la profondeur pour une image de texture donnée doit être décodée ou bien estimée.
Le décodeur fonctionne ensuite de manière similaire à ce qui a été décrit en relation avec le premier mode de réalisation de la figure 5.
La figure 8 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 décrit précédemment, notamment en relation avec les figures 2, 4A et 4B. Le codeur COD peut par exemple correspondre au codeur COD décrit en relation avec la figure 5.
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 oeuvre 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 avant d'être exécutées par le processeur PROC. Le processeur PROC de l'unité de traitement UT met notamment en oeuvre les étapes du procédé de codage décrit ci-dessus, selon les instructions du programme d'ordinateur PG.
La figure 9 présente la structure simplifiée d’un dispositif de traitement de données de vidéo multi-vues DTV adapté pour mettre en oeuvre le procédé de traitement de données multi-vues selon l'un quelconque des modes particuliers de réalisation de l'invention décrit précédemment, notamment en relation avec les figures 2, 3A, et 3B. Le dispositif de traitement de données de vidéo multi-vues DTV peut par exemple correspondre au module de synthèse SYNTH décrit en relation avec la figure 5 ou à un dispositif comprenant le module de synthèse SYNTH et le décodeur DEC de la figure 5.
Selon un mode particulier de réalisation de l'invention, le dispositif de traitement de données de vidéo multi-vues DTV 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 oeuvre les étapes du procédé de traitement de données de vidéo multi-vues 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 avant d'être exécutées par le processeur PROCO. Le processeur PROCO de l'unité de traitement UTO met notamment en oeuvre les étapes du procédé de traitement de données de vidéo multi-vues décrit ci-dessus, selon les instructions du programme d'ordinateur PGO.
Selon un mode particulier de réalisation de l'invention, le dispositif de traitement de données de vidéo multi-vues DTV comprend un décodeur DEC adapté pour décoder un ou des flux de données codées représentatif d'une vidéo multi-vues.

Claims

Revendications
1. Procédé de traitement de données d’une vidéo multi-vues, le procédé de traitement comprend:
- l'obtention, pour au moins un bloc d’une image d’une vue codée dans un flux de données codées représentatif de la vidéo multi-vues, d’au moins une information indiquant un mode d’obtention d’au moins une donnée de synthèse, parmi un premier mode d’obtention et un deuxième mode d’obtention, ladite au moins une donnée de synthèse étant utilisée pour synthétiser au moins une image d’une vue intermédiaire de la vidéo multi-vues, ladite vue intermédiaire n’étant pas codée dans ledit flux de données codées, ledit premier mode d’obtention correspondant à un décodage d’au moins une information représentative de la au moins une donnée de synthèse à partir du flux de données codées, ledit deuxième mode d’obtention correspondant à une obtention de la au moins une donnée de synthèse à partir d’au moins ladite image codée reconstruite,
- l’obtention de la au moins une donnée de synthèse selon le mode d’obtention indiqué par ladite au moins une information,
- la synthèse d'au moins une partie d’une image de ladite vue intermédiaire à partir d'au moins ladite image codée reconstruite et ladite au moins une donnée de synthèse obtenue.
2. Procédé de traitement de données de vidéo multi-vues selon la revendication 1 , dans lequel ladite au moins une donnée de synthèse correspond à au moins une partie d'une carte de profondeur.
3. Procédé de traitement de données de vidéo multi-vues selon la revendication 1 ou la revendication 2, dans lequel ladite au moins une information indiquant un mode d’obtention de la donnée de synthèse est obtenue par le décodage d’un élément de syntaxe.
4. Procédé de traitement de données de vidéo multi-vues selon la revendication 1 ou la revendication 2, dans lequel ladite au moins une information indiquant un mode d’obtention de la donnée de synthèse est obtenue à partir d’au moins une donnée codée pour l’image codée reconstruite.
5. Procédé de traitement de données de vidéo multi-vues selon la revendication 4, dans lequel le mode d’obtention est sélectionné parmi le premier mode d’obtention et le deuxième mode d’obtention en fonction d’une valeur d’un paramètre de quantification utilisé pour coder au moins ledit bloc.
6. Procédé de traitement de données de vidéo multi-vues selon l'une quelconque des revendications 1 à 5, comprenant en outre, lorsque ladite au moins une information indique que la donnée de synthèse est obtenue selon le deuxième mode d’obtention :
- le décodage à partir d'un flux de données codées, d'au moins un paramètre de contrôle,
- l'application dudit paramètre de contrôle lors de l'obtention de ladite donnée de synthèse selon le deuxième mode d’obtention.
7. Dispositif de traitement de données de vidéo multi-vues, comprenant un processeur configuré pour :
- obtenir, pour au moins un bloc d’une image d’une vue codée dans un flux de données codées représentatif de la vidéo multi-vues, au moins une information indiquant un mode d’obtention d’au moins une donnée de synthèse, parmi un premier mode d’obtention et un deuxième mode d’obtention, ladite au moins une donnée de synthèse étant utilisée pour synthétiser au moins une image d’une vue intermédiaire de la vidéo multi-vues, ladite vue intermédiaire n’étant pas codée dans ledit flux de données codées, ledit premier mode d’obtention correspondant à un décodage d’au moins une information représentative de la au moins une donnée de synthèse à partir du flux de données codées, ledit deuxième mode d’obtention correspondant à une obtention de la au moins une donnée de synthèse à partir d’au moins ladite image codée reconstruite,
- obtenir la au moins donnée de synthèse selon le mode d’obtention indiqué par ladite au moins une information,
- synthétiser au moins une partie d’une image de ladite vue intermédiaire à partir d'au moins ladite image codée reconstruite et ladite au moins une donnée de synthèse obtenue.
8. Terminal comprenant un dispositif selon la revendication 7.
9. Procédé de codage de données de vidéo multi-vues, le procédé de codage comprend :
- la détermination, pour au moins un bloc d’une image d’une vue dans un flux de données codées représentatif de la vidéo multi-vues, d’au moins une information indiquant un mode d’obtention d’au moins une donnée de synthèse, parmi un premier mode d’obtention et un deuxième mode d’obtention, ladite au moins une donnée de synthèse étant utilisée pour synthétiser au moins une image d’une vue intermédiaire de la vidéo multi-vues, ladite vue intermédiaire n’étant pas codée dans ledit flux de données codées, ledit premier mode d’obtention correspondant à un décodage d’au moins une information représentative de la au moins une donnée de synthèse à partir du flux de données codées, ledit deuxième mode d’obtention correspondant à une obtention de la au moins une donnée de synthèse à partir d’au moins ladite image codée reconstruite,
- le codage de ladite image dans le flux de données codées.
10. Procédé de codage de données de vidéo multi-vues selon la revendication 9, comprenant le codage dans le flux de données d’un élément de syntaxe associé à ladite information indiquant un mode d’obtention de la donnée de synthèse.
11. Procédé de codage de données de vidéo multi-vues selon l'une quelconque des revendications 9 à 10 comprenant en outre, lorsque l’information indique que la donnée de synthèse est obtenue selon le deuxième mode d’obtention :
- le codage dans un flux de données codées, d'au moins un paramètre de contrôle à appliquer lors de l'obtention de ladite donnée de synthèse selon le deuxième mode d’obtention.
12. Dispositif de codage de données de vidéo multi-vues, comprenant un processeur et une mémoire configurés pour :
- déterminer, pour au moins un bloc d’une image d’une vue dans un flux de données codées représentatif de la vidéo multi-vues, au moins une information indiquant un mode d’obtention d’au moins une donnée de synthèse, parmi un premier mode d’obtention et un deuxième mode d’obtention, ladite au moins une donnée de synthèse étant utilisée pour synthétiser au moins une image d’une vue intermédiaire de la vidéo multi-vues, ladite vue intermédiaire n’étant pas codée dans ledit flux de données codées, ledit premier mode d’obtention correspondant à un décodage d’au moins une information représentative de la au moins une donnée de synthèse à partir du flux de données codées, ledit deuxième mode d’obtention correspondant à une obtention de la au moins une donnée de synthèse à partir d’au moins ladite image codée reconstruite,
- coder ladite image dans le flux de données codées.
13. Programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé de traitement de données de vidéo multi-vues selon l'une quelconque des revendications 1 à 6, ou pour la mise en oeuvre du procédé de codage de données de vidéo multi-vues selon l’une quelconque des revendications 9 à 11 , lorsque le programme est exécuté par un processeur.
14. Support d'enregistrement lisible par ordinateur, et comportant des instructions d'un programme d'ordinateur selon la revendication 13.
PCT/FR2021/050207 2020-02-14 2021-02-04 Procédé et dispositif de traitement de données de vidéo multi-vues WO2021160955A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US17/799,101 US20230065861A1 (en) 2020-02-14 2021-02-04 Method and device for processing multi-view video data
CN202180014543.7A CN115104312A (zh) 2020-02-14 2021-02-04 用于处理多视图视频数据的方法和设备
EP21707767.6A EP4104446A1 (fr) 2020-02-14 2021-02-04 Procédé et dispositif de traitement de données de vidéo multi-vues

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2001464 2020-02-14
FR2001464A FR3107383A1 (fr) 2020-02-14 2020-02-14 Procédé et dispositif de traitement de données de vidéo multi-vues

Publications (1)

Publication Number Publication Date
WO2021160955A1 true WO2021160955A1 (fr) 2021-08-19

Family

ID=70804716

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2021/050207 WO2021160955A1 (fr) 2020-02-14 2021-02-04 Procédé et dispositif de traitement de données de vidéo multi-vues

Country Status (5)

Country Link
US (1) US20230065861A1 (fr)
EP (1) EP4104446A1 (fr)
CN (1) CN115104312A (fr)
FR (1) FR3107383A1 (fr)
WO (1) WO2021160955A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013159330A1 (fr) * 2012-04-27 2013-10-31 Nokia Corporation Appareil, et procédé et programme d'ordinateur pour codage et décodage vidéo
EP2898689A1 (fr) * 2012-09-21 2015-07-29 Nokia Technologies OY Procédé et appareil de codage vidéo

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014056150A1 (fr) * 2012-10-09 2014-04-17 Nokia Corporation Procédé et appareil de codage vidéo
US9930363B2 (en) * 2013-04-12 2018-03-27 Nokia Technologies Oy Harmonized inter-view and view synthesis prediction for 3D video coding

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013159330A1 (fr) * 2012-04-27 2013-10-31 Nokia Corporation Appareil, et procédé et programme d'ordinateur pour codage et décodage vidéo
EP2898689A1 (fr) * 2012-09-21 2015-07-29 Nokia Technologies OY Procédé et appareil de codage vidéo

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Workshop on Coding Technologies for Immersive Audio/Visual Experiences", no. n18559, 28 July 2019 (2019-07-28), XP030221843, Retrieved from the Internet <URL:http://phenix.int-evry.fr/mpeg/doc_end_user/documents/127_Gothenburg/wg11/w18559.zip 6. Workshop MPEG-July2019 - JJung.pdf> [retrieved on 20190728] *
GARUS P ET AL: "[MPEG-I Visual] A 37% MV-HEVC+VVS anchor improvement with 50% pixel rate reduction", no. m49153, 3 July 2019 (2019-07-03), XP030207362, Retrieved from the Internet <URL:http://phenix.int-evry.fr/mpeg/doc_end_user/documents/127_Gothenburg/wg11/m49153-v1-m49153.zip m49153.docx> [retrieved on 20190703] *

Also Published As

Publication number Publication date
CN115104312A (zh) 2022-09-23
EP4104446A1 (fr) 2022-12-21
FR3107383A1 (fr) 2021-08-20
US20230065861A1 (en) 2023-03-02

Similar Documents

Publication Publication Date Title
EP3788789A2 (fr) Procede et dispositif de traitement d&#39;images et procede et dispositif de decodage d&#39;une video multi-vue adaptés
FR2959636A1 (fr) Procede d&#39;acces a une partie spatio-temporelle d&#39;une sequence video d&#39;images
EP3198876B1 (fr) Génération et codage d&#39;images intégrales résiduelles
FR2768003A1 (fr) Procede de codage d&#39;un signal de forme binaire
WO2021160955A1 (fr) Procédé et dispositif de traitement de données de vidéo multi-vues
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
WO2021214395A1 (fr) Procédés et dispositifs de codage et de décodage d&#39;une séquence vidéo multi-vues
EP1596607B1 (fr) Procédé et dispositif de génération de vecteurs candidats pour les systèmes d&#39;interpolation d&#39;images par estimation et compensation de mouvement
EP3939304A1 (fr) Procédés et dispositifs de codage et de décodage d&#39;une séquence vidéo multi-vues
FR2934453A1 (fr) Procede et dispositif de masquage d&#39;erreurs
EP2227908B1 (fr) Procede de decodage a complexite variable d&#39;un signal d&#39;images, terminal de decodage, procede de codage, dispositif de codage, signal et programmes d&#39;ordinateur correspondants
WO2020070409A1 (fr) Codage et décodage d&#39;une vidéo omnidirectionnelle
EP3725080A1 (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
WO2020260034A1 (fr) Procede et dispositif de traitement de donnees de video multi-vues
WO2019008253A1 (fr) Procédé de codage et décodage d&#39;images, dispositif de codage et décodage et programmes d&#39;ordinateur correspondants
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
WO2022069809A1 (fr) Codage et decodage d&#39;une video multi-vues
WO2021136895A1 (fr) Synthese iterative de vues a partir de donnees d&#39;une video multi-vues
CN117043820A (zh) 沉浸式视频上下文中的深度估计方法
CN117426098A (zh) 用于传输和渲染包括非漫射对象的多个视图的方法、服务器和设备
WO2014131975A2 (fr) Dérivation de vecteur de mouvement de disparité, codage et décodage vidéo 3d utilisant une telle dérivation
FR2938146A1 (fr) Procede et dispositif d&#39;optimisation du debit d&#39;encodage d&#39;une image video en mode entrelace.
WO2006056720A1 (fr) Compression video par modification de quantification par zones d&#39;images

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21707767

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021707767

Country of ref document: EP

Effective date: 20220914