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