FR 3118379 A1 20220624 FR 2013513 A 20201217 Procédé (300) de compression d’un flux (172) vidéo volumétrique comprenant une pluralité de trames associées chacune à un maillage et une texture et définit des groupes de trames comprenant chacun une trame-clef et des inter-trames dont les maillages sont définis par rapport au maillage de la trame-clef correspondante, le procédé comprenant une étape de compression des informations représentatives des textures qui comprend, pour chaque groupe de trames, les étapes de compresser (302) par bloc les informations représentatives des textures de chacune des trames, définissant ainsi des blocs de pixels ; déterminer (304) des premiers blocs aptes à former une texture composite de la trame-clef et des deuxièmes blocs aptes à modifier par remplacements itératifs cette texture composite de manière à former des textures approchées des inter-trames ; et encoder (310) les textures des inter-trames sur la base de la texture composite de la trame-clef et des deuxièmes blocs. Fig. 3A Procédé et dispositif de compression de données représentatives d'une scène tridimensionnelle volumétrique en vue d’une décompression en temps réel pour un visionnage en ligne. L’invention concerne un procédé et un dispositif de compression de données représentatives d'une scène tridimensionnelle volumétrique en vue d’un décodage en temps réel pour un visionnage en ligne d’une vidéo volumétrique par un utilisateur final. L’invention a pour but de compresser des données volumétriques, qui sont représentatives de scènes tridimensionnelles, en vue d’un visionnage “en ligne” par un utilisateur final. Un procédé visant cet objectif est décrit dans l’article ”High-quality streamable free-viewpoint video”, ACM Trans. Graphics (SIGGRAPH), 34(4), 2015. Selon ce procédé, les données volumétriques sont obtenues à partir de la capture d’une scène tridimensionnelle par photogrammétrie, c’est-à-dire au moyen d’un ensemble de caméras, constitué de 106 caméras dans ce cas, capturant chacune une image de la scène sous un angle particulier à une fréquence de l’ordre de 30 à 60 images prises par seconde. Ces images sont utilisées pour recréer l’action de la scène par calcul d’un nuage de points pour chaque instant de capture de la scène, ou trame. Ces nuages de points sont représentatifs des surfaces, vues par les caméras, des éléments de la scène, et servent de base à la modélisation de la scène par un maillage de triangles reliés continûment les uns aux autres, sur lesquels une texture est plaquée, indépendamment pour chaque trame dans un premier temps. A cette étape, le nombre de triangles employés et leurs connectivités sont différentes pour chaque trame. Dans un deuxième temps, afin de favoriser la compression des données résultantes, un tracking géométrique du maillage est opéré dans le temps, consistant à approcher des maillages constitutifs des trames par déformation d’un maillage de référence appartenant à une trame dite « trame-clef » ou « keyframe », de sorte que les maillages des trames suivantes ont le même nombre de triangles et les mêmes connectivités que ce maillage de référence. Lorsqu’il n’est pas possible d’approcher de façon acceptable un maillage par déformation du maillage de la trame de référence, un nouveau maillage est défini pour une nouvelle trame de référence, et l’opération est répétée jusqu’à avoir traité les maillages de l’ensemble des trames. Les trames dont le maillage est défini sur la base du maillage d’une trame-clef, situées entre deux trames-clefs, sont dites « inter-trames » ou « interframes ». La compression des données concernant le maillage bénéficie des redondances temporelles entre les trames voisines dont le maillage est basé sur celui d’une même trame-clef. Un maillage d’une trame-clef est encodé entièrement, alors que seules les variations de maillage sont encodées pour les inter-trames, ce qui est plus économique en termes de volume de données résultantes et d’intensité de calcul pour leurs décodages que l’encodage et le décodage complets des maillages de chaque trame. Cependant, l’encodage des données de maillage peut encore être amélioré. En ce qui concerne les textures plaquées sur les maillages, à chaque trame correspond un atlas complet de textures qui devra être encodé puis décodé entièrement lors de la compression et la décompression, respectivement, selon le principe des normes de compression MPEG et H.264. Le traitement et la transmission des données de ces atlas de textures représentent un coût de calcul et en bande passante importants, qu’il est souhaitable de réduire. En outre, les méthodes employées ont été à l’origine développées dans le but de créer des vidéos avec des images « classiques » telles que celles d’un film, et non avec des textures qui sont des images composées de patches sur un fond uni. Une méthode plus appropriée pour compresser des atlas de textures est requise. L’invention a pour objectif d’améliorer d’une part la compression des informations portant sur les maillages des trames d’un flux vidéo volumétrique, et d’autre part sur les informations portant sur les textures associées à ces mêmes trames. L’invention porte plus particulièrement sur un procédé de compression d’un flux vidéo volumétrique d’une scène d’action tridimensionnelle représentée par une pluralité de trames, le procédé étant mis en œuvre par ordinateur, et selon lequel on génère un maillage et une texture pour chaque trame de la scène et on définit des groupes de trames comprenant chacun une trame-clef et des inter-trames dont les maillages sont définis par rapport au maillage de la trame-clef correspondante, le procédé comprenant une étape de compression des informations représentatives des textures, l’étape de compression de texture comprenant, pour chaque groupe de trames, les étapes de compresser les informations représentatives des textures de chacune des trames du groupe selon une méthode de compression par blocs, définissant ainsi des blocs de pixels ; déterminer, à partir de blocs associés à la trame-clef et de blocs associés aux inter-trames, d’une part des premiers blocs aptes à former une texture composite de la trame-clef, et d’autre part des deuxièmes blocs aptes à modifier par remplacements itératifs la texture composite de la trame-clef de manière à former des textures approchées des inter-trames ; former une texture composite de la trame-clef du groupe de trames à partir de premiers blocs associés à la trame-clef et de premiers blocs associés aux inter-trames, et encoder cette texture composite ; et encoder les textures des inter-trames sur la base de la texture composite de la trame-clef et des deuxièmes blocs. La compression des informations représentatives des textures selon l’invention met en particulier à profit la correspondance temporelle qui existe entre les textures des trames successives formant un flux vidéo volumétrique, évitant le codage, la transmission, puis le décodage d’informations redondantes. La décompression du flux vidéo encodé au moyen de procédé de compression selon l’invention a un faible coût en calcul et le niveau de compression peut être aisément choisi au moyen d’un simple paramètre, permettant d’adapter le compromis entre le niveau de compression et la facilité à décompresser aux besoins de l’usager et donc d’obtenir un flux vidéo volumétrique particulièrement apte à une lecture en ligne en temps réel. Le procédé de compression d’un flux vidéo volumétrique selon l’invention peut présenter les caractéristiques suivantes : - les étapes d’encodage des textures composites des trames-clefs et des textures des inter-trames peuvent comprendre une compression par codage entropique ; - l’étape de détermination des premiers blocs et des deuxièmes blocs peut comprendre une étape d’évaluation des différences graphiques des blocs d’un groupe de trame d’une position donnée les uns par rapport aux autres ; - l’étape de détermination des premiers blocs et des deuxièmes blocs peut comprendre en outre une étape de construire un graphe comprenant des nœuds interconnectés selon des lignes et des colonnes, les différences graphiques étant affectées à un coût de déplacement selon une ligne entre deux nœuds et un coût étant affecté aux déplacements selon une colonne ; et une étape de déterminer d’un chemin de coût le plus bas dans ce graphe, chaque début de chemin au niveau d’une colonne étant associé à l’un des premiers blocs et chaque déplacement selon une colonne étant associé à l’un des deuxièmes blocs ; - l’étape de détermination d’un chemin peut mettre en œuvre un algorithme de Dijkstra ; - le procédé peut comprendre en outre une étape de compression des informations représentatives des maillages comprenant les étapes de compresser les informations représentatives des maillages par quantification ; compresser les informations représentatives des maillages quantifiées selon une méthode de compression qui comprend les étapes de compresser des informations représentatives de triangles des maillages des trames-clefs selon l’algorithme Edgebreaker ; compresser des informations représentatives de points des maillages des trames-clefs selon un algorithme de prédiction ; compresser des informations représentatives de coordonnées de texture des trames-clefs selon un algorithme de prédiction sélective linéaire ; et compresser des informations représentatives de points des maillages des inter-trames par codage différentiel ; et compresser, au moyen d’un algorithme de calcul d’entropie, les informations compressées représentatives desdits points des maillages, desdits triangles et desdites coordonnées de texture des trames-clefs ainsi que les informations représentatives des points des maillages des inter-trames. L’invention peut s’étendre à : - un système de traitement de données comprenant des moyens de mettre en œuvre les étapes du procédé ; - un programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé ; et - un support lisible par ordinateur comprenant des instructions qui, lorsqu'elles sont exécutées par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé. La présente invention sera mieux comprise et d'autres avantages apparaîtront à la lecture de la description détaillée du mode de réalisation pris à titre d'exemple nullement limitatif et illustré par les dessins annexés, dans lesquels : - la illustre un studio de vidéogrammétrie comportant des caméras ; - la est un schéma du système de capture d’images et de traitement de données des caméras de la ; - la est un diagramme d’un procédé de productions de vidéos volumétriques d’une scène ; - la illustre un nuage de points tels que définis dans le procédé de la ; - la illustre un maillage correspondant au nuage de points de la ; - la illustre une succession de trames ; - la illustre une répartition des trames de la figures 2A en groupes ; - la illustre une texture ; - la illustre une texture complète pour une trame-clef (a) et une texture partielle pour une inter-trame (b), selon l’invention ; - la est un diagramme du procédé selon l’invention ; - la est un diagramme d’une étape particulière du procédé selon l’invention ; - la est un tableau de valeurs d’erreurs ; - la est un graphe construit à partir du tableau de la ; - la est un cas particulier du graphe de la après traitement selon l’invention ; - la est un tableau résumant les résultats de la ; - la illustre les textures non-compressées et compressées d’une succession de trames ; - la est un diagramme illustrant la décompression d’un flux de données vidéo volumétrique compressé selon l’invention. Description d’un mode particulier de réalisation du procédé selon l'invention Afin de reconstituer une scène d’action volumétrique, c’est-à-dire une scène se déroulant dans le temps et dans les trois directions de l’espace, la scène est jouée par des acteurs 105 dans un studio 100 de vidéogrammétrie doté d’un fond vert. Un tel studio est composée d’une structure 110 entourant un plateau 120 et qui a pour fonction de supporter un ensemble de caméras 130 observant la scène 125 selon une variété de points de vue. Les caméras 130 sont reliées à un système 140 de stockage et de traitement de données, ainsi qu’à une interface utilisateur 150. Un procédé de production d’une vidéo volumétrique à l’aide du studio 100 comprend les étapes suivantes du diagramme 155 de la . A une étape 160, les caméras capturent la scène de manière synchronisée, par exemple à une fréquence comprise entre 30 et 60 images par seconde, chacune selon son propre point de vue, ce qui permet de reconstruire la scène dans sa globalité. A une étape 162, les images capturées par les caméras sont optionnellement traitées pour calibration, pour corriger des biais ou autres erreurs, et pour en soustraire le fond, selon des méthodes conventionnelles. A une étape 164, ces images retraitées nourrissent un algorithme connu de l’homme du métier, mis en œuvre par le système 140 de traitement de données de manière à produire des nuages de points C tels qu’illustrés par la , représentatifs des objets constituant la scène, par établissement de cartes de profondeur des surfaces visibles de ces objets selon le principe de la stéréographie, par comparaison des images d’une même surface physique capturées par différentes caméras selon différents angles de vue. A une étape 166, on génère un maillage M tel qu’illustré par la à partir des nuages de points obtenus, et une texture destinée à être plaquée sur celui-ci, selon des méthodes conventionnelles, comme par reconstruction de surfaces de Poisson et utilisation du code source UVAtlas, copyright © Microsoft Corporation, respectivement pour chaque trame, indépendamment d’une trame à l’autre. A ce stade, la scène est représentée par une succession de trames F, chaque trame étant associée d’une part à des informations représentatives d’une texture T respective, et d’autre part à des informations représentatives d’un maillage M respectif, indépendamment d’une trame à l’autre. Ainsi, la illustre 5 trames F1 à F5 en succession, chacune associée respectivement à un maillage M1 à M5 et à une texture T1 à T5. Chaque maillage est constitué d’un ensemble de points reliés entre eux par des triangles, recréant la surface des objets de la scène, et chaque triangle est associé à des coordonnées de texture au moyen d’une table de coordonnées de textures afin de pouvoir plaquer correctement la texture sur les triangles. Les triangles sont employés en tant que surfaces élémentaires décomposant les surfaces des objets telles que vues par les caméras. Un autre type de surface élémentaire pourrait être employé, mais dans un souci de clarté des explications, nous continuerons d’employer un exemple de mise en œuvre de l’invention basé sur des triangles. Une étape 168 de tracking géométrique et photométrique est mise en œuvre afin de répartir les trames F en groupes de trames FGr comprenant chacun une trame-clef KF et une pluralité d’inter-trames IF. Ainsi, la illustre 18 trames F1 à F18 réparties en trois groupes de trames FGr1 à FGr3 comprenant chacun une trame-clef KF et des inter-trames IF en nombre variable selon les groupes, trames obtenues en un flux 172 en étape de sortie 170. Un maillage de référence est associé à chaque trame-clef, les maillages des inter-trames sont définis par déformation des maillages de référence, c’est-à-dire au moyen d’informations représentatives de déformations des maillages associés aux trames-clefs correspondantes, et une texture est associée à chaque trame. Chaque texture peut être représentée par une image comportant des patches sur un fond uniforme, comme illustrée par la . Les informations représentatives des maillages consistent, dans le cas des trames-clefs, en des informations représentatives des points du maillage, i.e. des données de localisation de ces points dans un espace tridimensionnel ; en des informations représentatives des triangles du maillage, i.e. des données de surfaces chacune comprises entre 3 des points du maillages ; et en des informations représentatives de textures associées à des triangles respectifs du maillage, i.e. des données de coordonnées de texture. Les étapes ci-dessus sont connues de l’homme du métier, exposées par exemple dans la publication ”High-quality streamable free-viewpoint video”, ACM Trans. Graphics (SIGGRAPH), 34(4), 2015. Les étapes suivantes amènent à une amélioration vis-à-vis des méthodes conventionnelles de compression vidéo volumétrique en ce qui concerne, d’une part, la compression des informations représentatives des textures et, d’autre part, la compression des informations représentatives des maillages, considération étant donnée à une étape ultérieure de décompression, comme détaillé ci-dessous à l’aide des diagrammes 300 et 304 de la et 3B, respectivement. Compression des textures A l’issue des étapes précédentes, chaque trame est associée à une texture qui lui est propre au sein d’un flux 172 de données vidéo comprenant des données T de textures et des données M de maillage, chaque texture étant une image numérique. A une étape 301 de test, on détermine si les données arrivantes sont des données M de maillage ou des données T de texture. A une étape 302, on applique une compression par bloc à chaque texture associée à une trame du flux de trames, les textures étant récupérées dans les données T de texture, de sorte que la texture de chaque trame est associée à un ensemble de blocs. La compression par bloc est une méthode conventionnelle de compression permettant de réduire la quantité de mémoire requise pour stocker des données de couleur, dans laquelle des blocs de pixels (tels que des carrés de 4 pixels par 4 pixels ou 8 pixels par 8 pixels) sont compressés en considérant que les variations à l’intérieur d’un même bloc sont très faibles, selon des algorithmes standards tels que DXT, ASTC ou PVRTC. Dans ce document, le terme « bloc » fait référence à des blocs obtenus par un algorithme du type de ceux mentionnés dans le paragraphe précédent et qui sont directement exploitables par une unité de traitement graphique conventionnelle, ou GPU, c’est-à-dire sans requérir une décompression ou un autre traitement. Ainsi, la compression par bloc selon l’invention aboutit à des données pouvant être décodées directement par les unités de traitement graphiques conventionnelles. Lors du décodage, il ne sera donc pas nécessaire pour l’unité centrale de calcul d’une unité de traitement de données, ou CPU, de décompresser les textures compressées par blocs avant de les envoyer à une unité de traitement graphique, ou GPU, ce qui permet de limiter les calculs à effectuer sur le CPU et de réduire fortement la quantité de données à envoyer au GPU. Dans le cadre d’une lecture en temps réel d’un flux vidéo volumétrique, cette caractéristique représente un avantage déterminant par réduction de la quantité de données à transférer et du coût en calcul de la décompression des données transférées. Il est à noter que les « blocs » tels que considérés dans l’ensemble ce document sont donc distincts des « blocs » utilisés dans d’autres méthodes de compression tels celles des codage JPEG et MPEG, menant à des formats qui ne sont usuellement pas considérés comme pouvant être traités directement par un GPU. Un avantage fort du procédé selon l’invention par rapport aux méthodes conventionnelles est ainsi de mettre à profit la capacité des GPU à effectuer des opérations de décompression au niveau des blocs pour faciliter le traitement des flux vidéos obtenus. En outre, la compression par blocs au sens de l’invention est particulièrement adaptée à la compression de textures, notamment de type atlas, et bien plus adéquate qu’une compression d’image telle qu’utilisée en codages JPEG et MPEG. Cependant les blocs directement interprétables par un GPU comme considérés dans cette invention présentent une difficulté dans leur compression de par le fait qu'il n'est pas possible de modifier un bloc par une différence. Les techniques classiques reposant sur une compression par différence ne sont donc pas applicables. Pour chaque groupe de trames, on applique au cours d’une étape 304 une méthode de réduction des textures, selon la méthode originale suivante dite de réduction par texture partielle. Dans cette étape, on choisit, parmi des blocs associés à la trame-clef et des blocs associés aux inter-trames d’un groupe de trames, d’une part un ensemble (210) de premiers blocs aptes à former une texture composite de la trame-clef, et d’autre part un ensemble (220) de deuxièmes blocs aptes à modifier par remplacements itératifs la texture composite de la trame-clef de manière à former des textures approchées des inter-trames. Ainsi, au lieu d’encoder en totalité l’ensemble des blocs de chaque texture associée à une trame, on encode en totalité uniquement les blocs d’une texture reconstituée de chaque trame-clef, mais en ce qui concerne les inter-trames, les seuls blocs encodés sont ceux qui apportent une information significativement nouvelle. Cette caractéristique permet une réduction considérable du volume de données de texture à encoder lors de la compression, puis à transmettre et à décoder lors d’un visionnage en ligne de la vidéo. Les blocs encodés pour les inter-trames sont utilisés pour modifier la texture composite de la trame clef par itération à chaque nouvelle trame, lorsque nécessaire pour maintenir une qualité visuelle acceptable. La illustre cette situation, avec une texture complète d’une trame-clef, texture complète formée par un ensemble 210 de 256 blocs, et un ensemble 220 de 92 blocs formant une texture partielle d’une inter-trame correspondant à cette trame-clef, les blocs manquant étant considérés comme suffisamment proche de ceux de la trame-clef pour ne pas avoir à être encodés à nouveau. A la place des blocs non encodés, on emploie des blocs déjà encodés qui sont graphiquement proches de ces blocs non encodés, tant que la dégradation en terme de qualité visuelle reste acceptable. Les blocs déjà encodés sont soit ceux de la trame-clef, soit des blocs d’une texture partielle déjà venus en remplacement de ceux de la trame clef, de sorte que l’on obtient des textures approchées des textures des inter-trames en modifiant la texture de la trame-clef par itérations successives. Ce principe peut être exploité selon le mode particulier de mise en œuvre détaillé ci-dessous à l’aide des figures 3B et 4A à 5C. Les données du flux de trames consistent en des groupes de trames, chaque groupe comprenant une trame-clef suivie d’inter-trames, en succession temporelle. Les textures associées aux trames d’un même groupe se ressemblent naturellement, conséquence de la définition même des groupes par tracking géométrique et photométrique, et ont donc un grand nombre de blocs en commun qu’il n’est pas nécessaire de ré-encoder à de multiples reprises, l’encodage initial d’une texture reconstituée pour la trame-clef et de certains blocs choisis pour inter-trames étant suffisants. L’enjeu de la réduction par texture partielle est de déterminer quels blocs sont à utiliser pour la texture de la trame-clef et quels blocs nécessitent une mise à jour au sein de chaque groupe de trames, et ce de manière à minimiser le nombre de blocs à encoder tout en maintenant acceptable la qualité visuelle de la vidéo finale. Pour une position de bloc donnée, on évalue au cours d’une sous-étape 304-1 les différences graphiques des blocs de chaque trame les uns par rapport aux autres. Si l’on considère un groupe d’un nombre Nf de trames, on a potentiellement Nf variantes possibles pour chaque position de bloc de pixels dans l’image de texture. En effet, Nf blocs différents B1 à BNf se succèdent à une même position respectivement au cours des trames F1 à FNf et peuvent être considérées comme les variantes temporelles d’un bloc donné au cours des Nf trames F1 à FNf considérées. Pour illustration, on se reportera à la représentant une groupe d’une séquence de Nf trames chacune associée à une texture non compressée Tnc et à une texture compressée Tc, les blocs B1 à BNf correspondant à une même position Pos dans les textures compressées respective Tc et à des images (ou ensembles de pixels) I1 à INf correspondant à cette même position dans les textures non compressées respectives Tnc. Les blocs B1 à BnF et les images I1 à INf sont constitués d’ensembles de pixels de même position, de même géométrie et de même dimension. Pour évaluer les variations graphiques des blocs entre eux, on utilise communément un PSNR pour Peak Signal to Noise Ratio, utilisé en imagerie numérique pour évaluer la qualité de reconstruction d’une image compressée par rapport à son image originale. D’autres méthodes d’évaluation des variations graphiques des blocs pourraient être employées, le PSNR ne représentant qu’une possibilité. Pour une position donnée de bloc des textures compressées Tc, on calcule un PSNR entre les blocs B1 à BNf des trames F1 à FNf respectives et les images I1 à INf de même position des textures non compressées des trames correspondantes du même groupe, ce qui nous donne Nf×Nf calculs de PSNR à effectuer. On prend ici pour référence les textures non compressées en vue d’assurer la fidélité de la vidéo encodée aux images originales, mais il serait également possible de calculer les PSNR entre chaque bloc d’une trame donnée et les blocs correspondant des textures compressées des autres trames. Les PSNR constituent une indication de la ressemblance entre deux images, ici une première image qui est celle d’un bloc défini lors de l’étape de compression par bloc et une deuxième image qui est celle constituée par un groupe de pixels correspondant au bloc dans une image non compressée. En outre, le PSNR s’exprime sur une échelle logarithmique et une grande valeur de PSNR est indicatrice d’une forte ressemblance entre deux images. Afin d’exprimer numériquement l’amplitude des différences entre blocs d’une trame à l’autre, donc au cours du temps, sur une échelle linéaire, on calcule au cours d’une étape 304-2 une valeur d’erreur ErrVal valant pour chacun des Nf×Nf PSNR calculés à l’étape 304-1. Un étape 304-3 consiste à construire, pour chaque position de bloc dans un groupe de Nf trames, un tableau 400 carré comportant Nf×Nf entrées, chacune constituée d’une des valeurs d’erreur ErrVal calculée à l’étape 304-2. Chaque ligne du tableau 400 est dédiée aux évaluations des variations temporelles d’un bloc de position donnée aux cours de Nf trames F1 à FNf, en se référant ici aux images I1 à INf correspondant aux blocs dans les textures non compressées correspondantes. Chaque colonne du tableau 400 est dédiée à une trame, les trames étant classées dans leur ordre d’apparition dans le flux vidéo volumétrique et étant identifiées F1 à FN. Les entrées du tableau sont remplies en y insérant les valeurs d’erreurs ErrVal calculées à l’étape 304-2 de la manière suivante. Une entrée de coordonnées (p;q) de la p-ième ligne et de la q-ième colonne du tableau 400 correspond à une valeur d’erreur ErrVal(Bp/Iq) calculée entre un p-ième bloc à une position donnée de texture compressé de la p-ième trame et une image Iq d’un ensemble de pixels à cette position donnée de la texture non compressée à la q-ième trame Fq, et traduit l’amplitude de différence graphique entre ce p-ième bloc et cet ensemble de pixels. Par exemple, la deuxième entrée de la première ligne du tableau correspond à une valeur d’erreur ErrVal(B1/I2) calculée entre le premier bloc B1 à la première trame F1 et l’ensemble de pixels I2 correspondant à ce bloc dans la texture non compressée à la deuxième trame F2 avant compression par bloc, et traduit l’amplitude de différence graphique entre ce premier bloc B1 et cet ensemble de pixels correspondant I2. Les entrées de la diagonale (B1;F1) à (BNf;FNf) du tableau traduisent l’amplitude de la différence graphique entre un bloc et le groupe de pixels correspondant de la texture non compressée d’une même trame, indiquant la dégradation de qualité d’image vidéo introduite par l’étape de compression par bloc. Une démarche possible définie par les inventeurs pour minimiser la quantité de données à encoder puis à décoder lors de la lecture d’un flux vidéo consiste à minimiser le nombre de blocs à encoder en effectuant un choix parmi les blocs au moyen du tableau 400 qui indique les erreurs introduites par la compression par bloc de l’étape 302, non seulement au sein d’une trame, mais également entre les trames d’un même groupe pour une position donnée de blocs. Le choix revient à déterminer au sein du tableau un chemin ayant un coût le plus bas possible pour aller d’une entrée quelconque de la première colonne à gauche du tableau correspondant à la première trame du groupe considéré à une entrée quelconque de la dernière colonne à droite correspondant à la dernière trame du groupe considéré, en se déplaçant soit vers la droite soit verticalement (vers le haut ou vers le bas), en introduisant un coût pour chaque déplacement horizontal, un coût pour chaque déplacement vertical, et en cherchant à minimiser le coût global induit par le chemin suivi. Lors d’un déplacement horizontal, on choisit comme bloc encodé le bloc situé au point de départ de déplacement à la trame correspondante dite trame antérieure et à conserver ce bloc jusqu’à la trame d’arrivée du déplacement dite trame postérieure à l’issue d’une succession de déplacements horizontaux unitaires, sans encoder les blocs intermédiaires dans le flux vidéo qui sera produit. Lorsqu’un bloc est utilisé pour encoder des images successives, la qualité visuelle des images encodées a tendance à se dégrader avec leur éloignement temporel de l’image ayant servi à générer ce bloc. Ainsi, la valeur d’erreur ErrVal tend à augmenter avec la longueur du déplacement horizontal. En conséquence, il est nécessaire de limiter les amplitudes des déplacements horizontaux en imposant des déplacement verticaux, correspondant à l’encodage d’un nouveau bloc plus adapté à l’encodage des images des nouvelles trames, ce qui est favorable du point de vue de la qualité visuelle, mais défavorable des points de vue du taux de compression des données, de leur transmission et de leur décompression lors de la visualisation du flux vidéo. Une manière d’optimiser le chemin est d’affecter un premier coût à la dégradation de la qualité visuelle induite par la réutilisation d’un même bloc pour encoder les images de plusieurs trames, un deuxième coût à l’intensité du calcul, correspondant à l’augmentation de la quantité de données à encoder, puis de déterminer le chemin minimisant le coût global représentant la somme du premier coût et du deuxième coût. Le chemin optimal peut être déterminé par des méthodes classiques de théorie des graphes, en passant par exemple par le graphe 450 de la construit à partir du tableau 400, ce graphe étant constitué de nœuds et de déplacements possibles entre ces nœuds, en déterminant le chemin en fonction de paramètres, ici les coûts mentionnés plus haut, définis par le praticien selon ses objectifs et ses priorités. Les nœuds centraux du graphe 450 sont identifiés par U p,q et correspondent aux entrées de la p-ième colonne et de la q-ième lignes du tableau 400. Un nœud U p,q du graphe correspond à l’utilisation d’un bloc de la position de bloc considérée dans la texture de la p ième trame pour encoder la texture de la q ième trame. Les nœuds sont disposés de la même manière que les entrées du tableau, en Nf lignes et Nf colonnes, un nœud fictif Ud de départ étant relié selon des lignes à chacun des nœuds correspondant aux entrées ErrVal(B1/I1) à ErrVal(BFn/I1) de la première colonne du tableau, avec dans cet exemple le nombre de trames Nf valant 4. Dans le graphe 450, chaque ellipse représente un nœud et chaque flèche représente un déplacement possible entre deux nœuds. Les déplacements possibles dans le graphe sont horizontaux, au sein d’une même ligne, ou verticaux, au sein d’une même colonne. Les déplacements horizontaux possibles se font d’un nœud donné au nœud immédiatement adjacent à sa droite, comme représenté par les flèches en traits pleins du graphe 400, pour un coût de dégradation visuelle considéré comme correspondant à la valeur ErrVal de l’entrée du tableau correspondant au nœud de fin du déplacement considéré. Les déplacements verticaux possibles se font entre deux nœuds situés l’un au-dessus de l’autre, immédiatement adjacent ou non, comme représenté par les flèches en traits pointillés, pour un coût en calcul Ccalc défini par l’utilisateur. Ici, le coût pour aller, par exemple, du nœud U 1,3 au nœud U 1,4 est ErrVal(B1/I4) et le coût pour aller du nœud U 1,3 au nœud U 3,3 ou au nœud U 3,4 est Ccalc. La forme du graphe et les règles de déplacement en son sein étant définies, le chemin optimal recherché peut être déterminé par, entre autres méthodes conventionnelles, mise en œuvre de l’algorithme de Dijkstra, généralement utilisé pour déterminer le chemin le plus court entre deux points d’un graphe constitué d’une pluralité de nœuds interconnectés, ce qui est le cas du graphe 450. Le chemin optimal, celui ayant le coût global le plus faible, est considéré comme celui permettant une minimisation du volume de données à encoder compatible avec une qualité vidéo acceptable. La qualité vidéo est déterminé par le praticien en choisissant le coût Ccalc selon des critères dépendant de ses priorités, un coût Ccalc élevé favorisant un taux de compression élevé, un coût Ccalc faible induisant une qualité visuelle élevée, un coût Ccalc intermédiaire amenant à un compromis entre le taux de compression et la qualité visuelle. Pour des opérations conventionnelles de compression, le coût Ccalc est de préférence de l’ordre de 0,0001, par exemple compris entre 0,00001 et 0,001, ou pourrait par exemple être initialisée à une valeur moyenne de la valeur d’erreur ErrVal. Par exemple, la illustre une application du graphe 450 au cas particulier d’un groupe de 5 trames pour une position donnée de bloc, avec un chemin optimal Popt passant par les nœuds U2,1, U2,3, U4,3 et U4,5, incluant donc un changement de lignes entre les nœuds U2,3 et U4,3. Pour la position donnée de bloc, le bloc B2 de la deuxième trame est encodé et utilisé pour les première et deuxième trames F1 et F2 lors du codage de la vidéo, c’est-à-dire pour la texture composite de la trame-clef et la première inter-trame. Ce bloc B2 n’a pas à être ré-encodé pour la deuxième trame puisqu’il l’a déjà été pour la première. Le bloc B4 de la quatrième trame est encodé et remplace le bloc B2 pour les trames 3 et suivantes F3, F4 et F5. Le bloc B4 n’est encodé qu’une seule fois mais est utilisé pour 3 trames. D’un point de vue pratique, le praticien peut s’attendre à devoir traiter des groupes de trames comportant jusqu’à plusieurs dizaines de trames. L’étape 304 telle que décrite ci-dessus ne s’applique qu’à une position de bloc donnée au sein des textures des inter-trames de chaque groupe de trame. Cette étape 304 est donc répétée pour être appliquée à chaque position de bloc afin de déterminer les blocs à utiliser pour encoder les textures dans leur ensemble, comme indiqué par la boucle L dans le diagramme 300. A une étape de test 306, on détermine si une trame est une trame-clef KF ou à une inter-trame IF. A une étape 308, on récupère l’ensemble des blocs nécessaires à l’encodage de la texture complète associée à une trame-clef et tels que déterminés à l’étape 304 pour chaque position de bloc, de manière à ce que l’on forme une texture composite pour cette trame-clef, et on applique à cette texture composite une méthode de compression conventionnelle, telle qu’une méthode de compression entropique, par exemple par codage de Huffman. Ainsi, pour chaque trame-clef, on encode une texture composite complète en utilisant des blocs de différentes textures associées à des trames respectives du groupe de trames de la trame-clef considérée, comme décrit ci-dessus. Ce point représente une première différence par rapport aux méthodes d’encodage conventionnelles des textures, dans lesquelles la texture associée à une trame-clef est encodée exclusivement avec les blocs provenant de sa compression par bloc, indépendamment des textures des trames voisines. A une étape 310, on récupère pour chaque inter-trame les blocs nouvellement encodés pour cette inter-trame tels que déterminés à l’étape 304. Ainsi, pour chaque inter-trame ne sera encodée qu’une texture partielle constituée des blocs devant être encodés pour cette trame et, éventuellement, pour les trames suivantes. De cette manière, une partie seulement des blocs de la texture de cette inter-trame est encodée, au lieu d’une texture complète comme pour une trame-clef. Il est en outre avantageux de compresser les blocs par une méthode de codage entropique conventionnelle avant de les transmettre, éventuellement en streaming au sein d’un flux vidéo. Ainsi, comme expliqué plus haut et illustré par la , on encode en totalité uniquement les blocs d’une texture reconstituée de chaque trame-clef, mais en ce qui concerne les inter-trames, les seuls blocs encodés sont ceux qui apportent une information significativement nouvelle. Ces caractéristiques résultent en une amélioration considérable du taux de compression et en une économie de calculs lors de la lecture de la vidéo puisque moins de blocs devront être encodés, puis transmis et décodés lors de la lecture du flux vidéo. Compression des maillages A l’issue des étapes précédentes, chaque trame est associée à un maillage qui lui est propre au sein d’un flux 172 de données vidéo volumétrique comprenant des données T de textures et des données M de maillage, avec un maillage de référence associé à chaque trame-clef et des informations relatives aux modifications du maillage de référence pour chaque inter-trame dans un groupe donné de trames. A une étape 301 de test, on détermine si les données arrivantes sont des données M de maillage ou des données T de Texture. A une étape 350, on applique une méthode conventionnelle de compression par quantification à chaque maillage récupéré dans les données M de maillage, consistant à discrétiser les coordonnés des points définissant le maillage ainsi que les coordonnées des textures associées à un sous-ensemble de valeurs, pour une réduction de la mémoire occupée. A une étape 352 de test, on détermine si un maillage donné quantifié est associé à une trame-clef ou à une inter-trame. A une étape 354, on applique une méthode de compression aux informations représentatives des maillages des trames-clefs, comprenant les sous-étapes 354-1, 354-2 et 354-3, chacune adaptée à un type particulier des données qui, considérées dans leur ensemble, définissent les maillages des trames-clefs. A l’étape 354-1, les informations représentatives des triangles des trames-clefs sont compressées en utilisant un algorithme dit « Edgebreaker », connu par exemple de J. Rossignac, « Edgebreaker : Connectivity compression for triangle meshes », IEEE Transactions on Visualization and Computer Graphics, Vol. 5, No.1, pp. 47-61. A l’étape 354-2, les informations représentatives des points, ou vertices, des trames clefs sont compressées en utilisant un algorithme de prédiction selon des méthodes connues, comme expliqué par exemple dans la référence C. Touma and C. Gotsman, Triangle Mesh Compression, Proceedings Graphics Interface 98, pp. 26-34,1998. A l’étape 354-3, les informations représentatives des coordonnées de texture des triangles des trames-clefs sont compressées par un algorithme de prédiction sélective linéaire, comme par exemple décrit par Isenburg, M. et Snoeyink, J. dans « Compressing texture coordinates with selective linear predictions », Proceedings of Computer Graphics International’2003. Cet algorithme dit de prédiction sélective linéaire code les coordonnées de textures par point (vertex) alors qu’elles sont d’ordinaire encodées par triangle, ce qui en réduit le nombre et permet une meilleure compression ainsi qu’une optimisation des calculs lors du décodage. A une étape 356, on applique une méthode de compression par codage différentiel aux informations représentatives des points, ou vertices, des inter-trames. Au sein d’un groupe de trames, les triangles et les coordonnées de textures des inter-trames sont les mêmes que ceux de la trame-clef correspondante, leurs différences sont donc nulles au sein de chaque groupe de trames, et ces informations n’ont pas à être ré-encodées. Seules les informations portant sur les positions des points, pouvant varier d’une trame à l’autre, devront être encodées, et seules les variations entre trames le seront, selon le principe du codage différentiel. Le codage différentiel, aussi appelée compression delta ou delta encoding, est une technique de compression de données sans perte consistant à transformer des données par la série des différences entre données successives, technique particulièrement efficace dans le cas présent. A une étape 358, les informations compressées au cours des étapes 354-1 à 354-3 et 356 sont à nouveau compressées, cette fois au moyen d’un algorithme de calcul d’entropie. Il est spécifiquement favorable d’opérer un calcul d’entropie par compression arithmétique, telle que FSE (Finite State Entropy), menant à un excellent taux de compression pour le type de données traitées. Il est à noter que même si les étapes 354-1 à 354-3, 356 et 358 sont, prises individuellement, déjà connues de l’homme du métier, leur combinaison telle que décrite ici est nouvelle et amène des résultats supérieurs aux combinaisons connues de méthodes conventionnelles dans l’optique d’obtenir un flux vidéo compressé apte à être visionné en ligne. En effet, les données vidéo concernant les maillages peuvent, lorsqu’elles sont compressées selon l’invention, aisément être décodées en temps réel par des systèmes de calculs classiques. Au cours d’une étape 360, les flux de données résultant des étapes 308, 310 et 358 sont combinés en un fichier vidéo apte à être décodé en streaming pour visualisation via un réseau informatique. Décodage Lors du visionnage en streaming d’une vidéo stocké sous la forme du fichier vidéo de l’étape 360, les informations représentatives des trames sont envoyées via un réseau informatique et décodés séquentiellement, au fur et à mesure de leur arrivée au système informatique de l’usager sous la forme d’un flux 602 de données compressées, selon le diagramme de la . Les données représentatives de chaque trame arrivent séquentiellement selon l’ordre de leurs trames respectives dans le flux vidéo et sont décodées dans cet ordre, les données T de textures et les données M de maillage étant séparées. Les trames comprennent les trames-clefs et les inter-trames identifiées respectivement par KF et IF dans la figure et représentent les pièces d’information à décoder, M et T pour les informations représentatives des maillages et des textures, respectivement. Au cours d’une étape de test 604, les données représentatives des maillages et des textures sont respectivement identifiées pour être décodées séparément par la suite. Au cours d’une étape 610, les données représentatives des textures T sont soumises à un décodage entropique. Au cours d’une étape de test 612, les données décodées de l’étape 610 et correspondant respectivement aux trames-clefs KF et aux inter-trames IF sont identifiées. Les données représentatives des textures des trames-clés KF ne nécessitent pas de traitement supplémentaire, car bien qu’étant toujours sous un format compressé, il s’agit de la compression par bloc de l’étape 302, dont les produits peuvent être directement traité par les unités de traitement graphiques conventionnelles. En revanche, au cours d’une étape 614, les données représentatives des textures des inter-trames IF, qui dépendent des données des autres trames, sont traitées de manière à reprendre les données de la trame précédente et de les modifier en y remplaçant ceux parmi les blocs pour lesquels un nouveau bloc a été encodé suite à l’étape 310 par le nouveau bloc correspondant. Il s’agit d’un point de vue calculatoire d’une opération triviale et très rapide. Au cours d’une étape 620, les données représentatives des maillages M sont soumises à d’abord un décodage de l’encodage entropique par FSE, qui est effectué selon des algorithmes classiques d’exécution très rapide. Au cours d’une étape de test 622, les données correspondant respectivement aux trames-clefs KF et aux inter-trames IF sont identifiées. Au cours d’une étape 624, les données M représentatives des maillages des trames-clefs KF obtenues à la suite des étapes 354-1, 354-2 et 354-3 sont décodées indépendamment des données des autres trames selon des méthodes conventionnelles, rapide eu égard aux types de compression utilisés (prédiction ou Edgebreaker) pour ces données. Au cours d’une étape 626, les données représentatives des maillages M des inter-trames IF obtenues à la suite de l’étape 354, et qui dépendent des données déjà décodées des trames-clefs KF dont elles dépendent respectivement, sont décodées selon des méthodes conventionnelles, très rapides puisqu’il ne s’agit que d’une compression delta sur les positions des vertices. Au cours d’une étape 628, on opère la dé-quantification des données de maillage issues des étapes 624 et 626, selon des méthodes conventionnelles. Finalement, les données obtenues à la suite des opérations 610, 614 et 628 sont traitées par une unité de traitement de données et/ou une unité de traitement graphique de manière conventionnelle afin de procéder à l’affichage 630 de la vidéo. Grâce aux méthodes spécifiques employées pour l’encodage des données vidéos, le poids des données ainsi que la vitesse de décodage ont été sensiblement améliorés, le décodage pouvant être mis en œuvre par des unités de calcul conventionnels. Il va de soi que la présente invention ne saurait être limitée aux modes de réalisation exposé plus haut, susceptible de subir des modifications sans pour autant sortir du cadre de l'invention. Procédé (300) de compression d’un flux (172) vidéo volumétrique d’une scène (125) d’action tridimensionnelle représentée par une pluralité de trames (F), le procédé étant mis en œuvre par ordinateur, et selon lequel on génère un maillage (M) et une texture (T) pour chaque trame de la scène (125) et on définit des groupes de trames (FGr1, FGr2, FGr3) comprenant chacun une trame-clef (KF) et des inter-trames (IF) dont les maillages sont définis par rapport au maillage de la trame-clef correspondante, le procédé comprenant une étape de compression des informations représentatives des textures et étant caractérisé en ce que l’étape de compression de texture comprend, pour chaque groupe de trames, les étapes de :- compresser (302) les informations représentatives des textures de chacune des trames du groupe selon une méthode de compression par blocs, définissant ainsi des blocs (B1, B2, B3, BNf) de pixels ; - déterminer (304), à partir de blocs associés à la trame-clef et de blocs associés aux inter-trames, d’une part des premiers blocs (210) aptes à former une texture composite de la trame-clef, et d’autre part des deuxièmes blocs (220) aptes à modifier par remplacements itératifs la texture composite de la trame-clef de manière à former des textures approchées des inter-trames ; - former (308) une texture composite de la trame-clef du groupe de trames à partir de premiers blocs associés à la trame-clef et de premiers blocs associés aux inter-trames, et encoder cette texture composite ; et - encoder (310) les textures des inter-trames sur la base de la texture composite de la trame-clef et des deuxièmes blocs. Procédé selon la revendication 1, dans lequel les étapes d’encodage des textures composites des trames-clefs et des textures des inter-trames comprennent une compression par codage entropique. Procédé selon les revendications 1 ou 2, dans lequel l’étape de détermination des premiers blocs et des deuxièmes blocs comprend une étape (304-1, 304-2) d’évaluation des différences graphiques des blocs d’un groupe de trame d’une position donnée les uns par rapport aux autres. Procédé selon la revendication 3, dans lequel l’étape de détermination des premiers blocs et des deuxièmes blocs comprend en outre des étapes de : - construire un graphe (450) comprenant des nœuds interconnectés selon des lignes et des colonnes, les différences graphiques étant affectées à un coût (ErrVal) de déplacement selon une ligne entre deux nœuds et un coût (Ccalc) étant affecté aux déplacements selon une colonne, et - déterminer un chemin (Popt) de coût le plus bas dans ce graphe, chaque début de chemin au niveau d’une colonne étant associé à l’un des premiers blocs (B2) et chaque déplacement selon une colonne étant associé à l’un des deuxièmes blocs (B4). Procédé selon la revendication 4, dans lequel l’étape de détermination d’un chemin met en œuvre un algorithme de Dijkstra. Procédé selon l’une quelconque des revendications précédentes, comprenant en outre une étape de compression des informations représentatives des maillages comprenant les étapes de : - compresser (350) les informations représentatives des maillages par quantification ; - compresser (354) les informations représentatives des maillages quantifiées selon une méthode de compression qui comprend les étapes de : - compresser (354-1) des informations représentatives de triangles des maillages des trames-clefs selon l’algorithme Edgebreaker ; - compresser (354-2) des informations représentatives de points des maillages des trames-clefs selon un algorithme de prédiction; - compresser (354-3) des informations représentatives de coordonnées de texture des trames-clefs selon un algorithme de prédiction sélective linéaire ; et - compresser (356) des informations représentatives de points des maillages des inter-trames par codage différentiel ; et - compresser (358), au moyen d’un algorithme de calcul d’entropie, les informations compressées représentatives desdits points des maillages, desdits triangles et desdites coordonnées de texture des trames-clefs ainsi que les informations représentatives des points des maillages des inter-trames. Système de traitement de données comprenant des moyens de mettre en œuvre les étapes du procédé selon l’une quelconque des revendications 1 à 6. Programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé selon l’une quelconque des revendications 1 à 6. Support lisible par ordinateur comprenant des instructions qui, lorsqu'elles sont exécutées par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé selon l’une quelconque des revendications 1 à 6.