Bien que cette technique réduise la quantité d’informations de structure (et de données) à coder, on peut s’apercevoir que la représentation résultante en XMT-A est toujours volumineuse pour au final signaler un polygone, une référence vers une apparence et une liste de points. De plus, du fait de la bijection entre XMT-A et le format binaire BIFS, la même remarque peut être faite sur le format binaire.
Nous avons donc utilisé une autre technique en faisant appel à la notion de Proto présentée également dans le chapitre 3. Deux prototypes ont été créés pour décrire de manière plus compacte les polygones et polylignes. L’interface de ces prototypes expose uniquement l’apparence du contour, sous la forme d’un nœud Appearance (la notion de palette est toujours utilisable), et la liste des points sous la forme d’un vecteur de points. De ce fait, on supprime l'utilisation et le codage des nœuds
IndexedLineSet2D ou IndexedFaceSet2D et Coordinate2D.
Nous expliquons ici le gain de codage obtenu. Les instances des prototypes remplacent un sous arbre de la scène qui nécessiterait 30 bits (données non comprises). La déclaration de chaque Proto coûte, elle, 81 bits. En effet, il faut coder l'interface du prototype en plus de son corps. Ensuite, l'utilisation de prototype implique de pouvoir les identifier dans la scène. Le coût de codage d'un prototype inclut également le nombre de bits nécessaire pour identifier les instances de Proto (protoIDbits). Le codage d’une instance de Proto coûte 14 bits auxquels s’ajoute l’identifiant du Proto, soit protoIDbits. L’utilisation des Protos s’avère gagnante quand la formule ci-dessous est validée, N étant le nombre de répétitions de la structure que remplace le Proto.
Dans les contenus auxquels nous nous intéressons, nous ne définissons que deux Protos (polygone, polyligne), protoIDbits est donc égal à 1. La représentation choisie permet donc de gagner en
Chapitre 6 – Méthodes pour la représentation efficace de scènes multimédia animées
compression si le nombre de structures redondantes N est supérieur à un nombre minimal Nmin égal à 6
et le gain est alors de 15 bits par répétition. Or, cette condition est largement satisfaite d'après les statistiques indiquées dans le Tableau 6.1.
Le gain est ainsi important puisque le coût de codage de la structure d'une instance redondante est divisé par deux. Sur l'ensemble de séquences sur lequel nous avons travaillé, il est évalué à 10 % en moyenne par séquence. Il est intéressant de noter que la technique utilisée est déclinable également avec les technologies, comme XBL, présentées au chapitre 3. Cependant, compte tenu des statistiques de nos séquences de test (densité d'information supérieure à 80%), le gain obtenu, même s’il est intéressant, n’est pas suffisant pour réduire significativement la taille totale des fichiers. Nous avons donc également étudié l’utilisation de techniques de codage des données. Ces travaux sont présentés dans la section 6.4.2.
6.4.1.2 Codage statistique de scènes
A la suite des travaux sur la compression de la structure présentés dans la section précédente, nous nous sommes également intéressés à l'efficacité de la consommation mémoire des mécanismes de codage de structure. Les travaux de normalisation autour du format MPEG-4 LASeR ont montré qu'un des inconvénients du codage BIFS était la taille de décodeur BIFS. Sur les terminaux à très faible capacité mémoire, cela peut être un inconvénient pour le déploiement d'application.
La taille des décodeurs BIFS est due à l'utilisation du codage contextuel. Comme nous l'avons décrit dans le chapitre 3, un décodeur doit stocker des tables d'association (type du nœud parent, type du nœud enfant, mot de code binaire). De même, pour chaque champ codé, des tables indiquent les associations (nœud, champ, mot de code binaire) dans différents contextes de codage (arbre de scène initial, mise à jour, route).
Nous avons donc étudié la possibilité d'utiliser un codage nécessitant moins de tables de codage. Pour cela, nous avons utilisé une approche statistique et un codage de Huffman. Nous avons effectué une étude statistique sur les séquences de conformité de la norme LASeR. Cette analyse produit, pour toutes les séquences, les statistiques d'occurrence des éléments et des attributs LASeR/SVG sous la forme suivante :
• la fréquence d'occurrence d'un élément;
• la fréquence d'occurrence d'un attribut par élément;
• et la fréquence d'occurrence d'un attribut.
La différence entre la seconde et la troisième donnée est pertinente car un même attribut peut être spécifié sur plusieurs éléments différents. A la suite de cette analyse, que nous avons contribuée au groupe MPEG, il apparaît clairement que certains éléments (polyline, polygon, g, path …) et
Descriptions de scènes multimédia : représentations et optimisations
- 124 -
certains attributs (stroke, points, fill, id …) sont très fréquents. A partir de ces résultats, nous avons donc généré les codes de Huffman correspondant aux fréquences d'occurrences obtenues. Nous avons ensuite proposé une syntaxe binaire simple permettant de coder des scènes SVG basées sur ces codes de Huffman. Cette syntaxe est décrite dans la Figure 6.3. Nous avons ensuite réalisé un encodeur/décodeur suivant cette syntaxe.
Figure 6.3 – Codage d'un élément XML utilisant des codes de Huffman
Après expérimentation, nous avons rejeté l'utilisation de codes de Huffman différents pour un même attribut pour des éléments différents pour deux raisons : d'une part, le stockage des tables par élément serait aussi coûteux en mémoire que le codage BIFS, et d'autre part, les gains obtenus n'étaient pas significatifs. Ceci s'explique par le fait que la majorité des attributs en SVG est spécifiable sur tous les éléments du langage.
Notre proposition consiste donc à utiliser un codage de Huffman avec deux tables : une table de codes pour les éléments et une table de codes pour les attributs. Le Tableau 6.2 indique, pour les séquences de conformité LASeR, le gain en compression obtenu avec la syntaxe décrite dans la Figure 6.3 par rapport au codage LASeR.
Gain Structure uniquement Structure et données
Moyenne 59,1% 23,1%
Moyenne pondérée 75,8% 16,2 %
Tableau 6.2 – Comparaison de l'encodage des séquences LASeR
Notre syntaxe apporte un gain de 75,8 % en moyenne, moyenne pondérée par la taille du flux compressé sans données. Ce gain s'élève à 16,2% en moyenne pondérée par la taille du flux compressé données comprises.
Ces résultats montrent que le codage statistique que nous proposons améliore significativement l'efficacité du codage de structure dans les documents LASeR, avec une limitation au niveau de l'extensibilité. En effet, il faudra un nombre de bits, pour coder un nouvel élément de la nouvelle version du langage, supérieur ou égal au nombre de bits nécessaire pour coder l'élément le moins fréquent de la version précédente du langage.
Code de l'élément Code de l'attribut 1 Code de l'attribut 2 …
…
Code de fin d'attributs
Codage du sous élément 1
… Codage du sous élément N
Chapitre 6 – Méthodes pour la représentation efficace de scènes multimédia animées
6.4.1.3 Synthèse sur la proposition du codage des structures de scènes
Notre proposition pour le codage efficace de la structure des descriptions de scènes, dont la représentation est décrite dans la section 6.3, se décompose donc en trois points :
• suppression du codage contextuel et utilisation d'une unique table de codage pour coder les éléments et les attributs afin de réduire la taille du décodeur;
• utilisation d'un codage statistique de type Huffman pour augmenter l'efficacité du codage. On peut éventuellement, si le langage est évolutif, réserver des mots de code pour les éléments définis dans de futures versions du langage;
• et utilisation de prototype de codage pour supprimer les structures redondantes de la scène. Cela modifie le codage précédent en ajoutant un ou plusieurs symboles fortement probables. Pour cela, nous proposons de réserver un ou plusieurs mots de code de Huffman permettant de coder ces prototypes. Nous proposons également la réservation des mots de codes pour le codage des attributs des prototypes.
6.4.2 Codage des données
La partie précédente s'est intéressée à l'amélioration du codage des structures des descriptions de scènes. Dans cette partie, nous présentons une analyse de l'efficacité des mécanismes de codage existants sur les données et plus précisément sur celles des contenus vectoriels animés, du type dessins animés. Nous présentons ensuite nos propositions d'améliorations en la matière.
Dans les scènes animées que nous avons traitées, mais cela s'applique également à d'autres contenus volumineux comme les contenus cartographiques, la majeure partie des données provient des objets graphiques vectoriels et ces données sont principalement des données de types :
• triplet de valeurs décimales représentant des couleurs, souvent dans l'espace colorimétrique RGB ou sRGB. Les valeurs sont souvent normalisées entre 0 et 1.
• valeur scalaire décimale représentant les épaisseurs de traits,
• et liste de paires de coordonnées décimales correspondant aux sommets des polygones et polylignes composant les dessins.
Le Tableau 6.3 indique les statistiques de ces données dans les séquences de dessins animés que nous avons étudiées.
Pour ces trois types de données, comme nous l'avons décrit dans le chapitre 3, la norme MPEG-4 propose des outils de codage, avec ou sans perte. Cependant, certains de ces outils ne sont optimaux que dans certaines situations. Nous présentons ici le résultat d'une étude que nous avons réalisée afin de déterminer la méthode de codage la plus appropriée.
Descriptions de scènes multimédia : représentations et optimisations - 126 - Séquence Nombre de triplets de valeurs décimales Nombre de valeurs scalaires Nombre de paire de coordonnées 1 6 522 5 921 219 192 1a 4 359 3 387 291 644 2 4 239 4 809 143 619 2a 9 646 2 507 363 222 3 2 617 2 937 135 739 3a 5 001 4 225 241 087 4 6 767 7 381 206 705 4a 13 526 2 106 258 286 5 6 328 6 788 191 800 5a 4 428 5 072 202 960 6 2 351 1 287 51 387 6a 3 133 2 097 196 915 7 3 843 2 098 80 835 7a 3 054 2 097 113 815 8 3 727 4 038 72 287 8a 1 866 703 113 688 9 2 751 3 128 139 392 9a 38 041 35 978 671 772 10 1 046 602 24 323 11 7 034 4 878 84 249 12 1 803 3 535 111 094 13 9 499 11 887 170 228 14 10 449 14 075 152 032 15 8 119 4 358 78 066 Total 160 149 135 894 4 314 337 Moyenne 6 673 5 662 179 764
Tableau 6.3 – Statistiques des données numériques dans les séquences de dessins animés
6.4.2.1 Utilisation du codage sans perte
Nous avons tout d'abord analysé l’efficacité de l'outil de codage sans perte "Efficient Float Coding" dans le cas des contenus de types dessin animés. Dans ces contenus, comme le décrit le Tableau 6.3, les points occupent la majeure partie des données. Ces points sont positionnés sur une grille de résolution de 2-N pixel, et leurs coordonnées sont comprises 0 et 2M-1. On les notera sous la forme suivante : k1+ k2.2-N. Le Tableau 6.4 indique la taille maximale occupée par une coordonnée décimale,
Chapitre 6 – Méthodes pour la représentation efficace de scènes multimédia animées M \ N 5 4 3 2 1 0 10 25 24 22 21 19 17 8 23 22 20 19 17 15 6 21 20 18 17 15 13 4 19 18 14 15 13 11 2 17 16 12 13 11 9
Tableau 6.4 – Nombre maximal de bits pour coder un nombre rationnel selon le procédé « Efficient Float Coding »
Par exemple, pour le codage des nombres décimaux compris entre 0 et 1023, dont la partie décimale est un multiple de 1/16, le tableau indique qu'on utilisera au maximum 24 bits. Par ailleurs, d'après l'Équation 3.1, on sait qu'il faudra au minimum 4 bits (notamment pour coder la valeur 0). Par les calculs, on montre que le nombre moyen de bits pour coder ces nombres est de 2 bits inférieur au nombre maximal de bits du Tableau 6.4. En prenant en compte le fait que le codage d’un nœud
QuantizationParameter, pour signaler l'utilisation de cette technique pour tout l'arbre, ne coûte que 16 bits, il résulte que l’utilisation de ce codage permet de réduire le nombre de bits nécessaires pour coder les nombres décimaux dans la scène.
Cette technique est donc intéressante pour réduire sans perte le nombre de bits nécessaires pour coder les points décrivant les objets vectoriels. Cependant, nous verrons dans la partie suivante, que les mécanismes de quantification permettent un codage plus efficace avec une dégradation en qualité maîtrisée.
6.4.2.2 Utilisation de mécanismes de quantification
Comme nous l’avons vu dans le chapitre 3, les langages existants BIFS, Flash et LASeR permettent l'utilisation de mécanismes de quantification pour coder certains types de données et dans certaines parties de l'arbre de scène. Cependant, comme nous l'avons décrit, ces mécanismes doivent être utilisés avec précaution pour le codage des scènes vectorielles car celles-ci étant susceptibles d’être visualisées avec différents zooms, des artefacts de codage peuvent apparaître si les paramètres de quantification sont mal choisis. La quantification d’un contenu graphique vectoriel suppose donc de déterminer la résolution à partir de laquelle on considère les dégradations acceptables.
Pour cela, il est intéressant de visualiser les artefacts de codage, décrits dans le chapitre 3, sur des contenus réels, afin de voir l’impact sur la qualité visuelle du contenu. Nous présentons sur un exemple les résultats obtenus par l'utilisation des mécanismes de quantification BIFS afin de souligner les problèmes rencontrés dans la recherche du meilleur compromis compression/qualité. Nous proposons ensuite des méthodes pour résoudre ces problèmes.
Descriptions de scènes multimédia : représentations et optimisations
- 128 -
6.4.2.2.1 Exemple de quantification d'un objet graphique vectoriel
La Figure 6.4 illustre un symbole issu d’un dessin animé vectoriel. Les coordonnées des points de ce dessin sont exprimées dans le repère dont l'origine est le coin supérieur gauche de l’image, dont l'axe des abscisses est orienté vers la droite et l’axe des ordonnées est orienté vers le bas. Elles sont comprises en abscisse entre 0.0 et 658.0 et en ordonnée entre 0.0 et 471.2. La précision des points est inférieure ou égale au 20ème de pixel. Il faudra donc théoriquement en moyenne 15 bits pour représenter le dessin sans dégradation visible.
Figure 6.4 – Exemple d'objet graphique vectoriel issu d'un contenu vectoriel animé
Le Tableau 6.5 donne le résultat du codage de ce symbole suivant la norme BIFS en fonction du nombre de bits N utilisé pour coder les coordonnées des points du dessin. La première colonne donne l'image résultante après quantification et échantillonnage au pixel près. La seconde colonne représente la différence entre les images produites avec et sans quantification. La troisième colonne indique le PSNR résultant de cette différence. L'utilisation de cet outil présente l’avantage de pouvoir comparer nos résultats avec des codages d'image naturelle. Les deux dernières colonnes du tableau indiquent la taille du contenu codé avec quantification et le facteur de compression par rapport au contenu codé, toujours en BIFS, mais sans quantification en utilisant 32 bits par coordonnée. Ces chiffres sont à comparer avec la taille totale du contenu codé sans quantification qui est de 9407 octets, dont 6680 octets sont utilisés pour coder 835 points, qui représentent 71% du contenu.
Il faut noter également que nous avons effectué le même travail sur une centaine d’objets graphiques issus de contenu Flash et que tous les résultats (compression ou PSNR) sont similaires à ceux présentés ci-dessous.
Chapitre 6 – Méthodes pour la représentation efficace de scènes multimédia animées
N Image résultante Différence PSNR Taille Compression
14 55,87 3450 63,33%
9 28,52 2406 74,42%
8 23,29 2198 76,63%
5 13,33 1571 83,30%
4 11,86 1363 85,51%
Descriptions de scènes multimédia : représentations et optimisations
- 130 -
Ce tableau indique qu’il y a peu de différence entre le contenu codé avec une valeur théorique de N égale à 14 bits et les contenus codés avec N compris entre 10 et 13. Le PSNR reste au dessus de 30 dB. Cela est dû à deux facteurs : tout d'abord, tous les points ne nécessitent pas le nombre de bits théorique de 15 pour être représentés sans perte, et ensuite, pour ces valeurs de N, la résolution varie entre 0,04 et 0,64 pixel. Or, l’échantillonnage des images pour le calcul du PSNR étant réalisé au pixel, le PSNR n’est que peu affecté.
Pour N égal à 9 bits, la résolution est égale à 1,28 et donc les dégradations commencent à être importantes mais l’anticrénelage limite encore les effets de la dégradation (sans anticrénelage, le PSNR pour la même valeur de N vaut 26.64 dB). Cette valeur de N semble donc la meilleure valeur pour coder ce dessin. A titre d'information, le nombre de bits nécessaires pour coder cette image selon le format JPEG, avec un facteur de qualité de 80%, est de 36 Ko, 15 fois supérieur à celui utilisant le codage vectoriel quantifié.
Par contre, pour des valeurs de N inférieures à 9, la qualité visuelle du dessin est altérée significativement par la quantification. Le PSNR chute en dessous de 30 dB. Une des conséquences de la quantification grossière est l’apparition de trou entre les différents contours. Cela est du au fait qu'un même point appartenant à deux contours différents peut être quantifié de manières différentes selon les paramètres choisis pour chaque contour.
6.4.2.2.1.1 Commentaires sur le PNSR
Il faut être prudent avec les chiffres de PSNR indiqués ci-dessus car ils correspondent à un échantillonnage de l’image avec une résolution au pixel près. Si on zoom sur l’image (en avant ou en arrière), puis si on régénère des images à partir des informations vectorielles et enfin si on calcule à nouveau ces PSNR, les résultats diffèrent. En effet, on remarque (Figure 6.5) que le PSNR gagne 2 à 3 dB quand la résolution de l’image double, à niveau de quantification constant, et ce, de manière constante avec le niveau de quantification, sauf quand la quantification produit une scène trop dégradée (N inférieur ou égal à 7). Cela s’explique par le fait que les erreurs de quantification affectent les contours, en les déplaçant, or plus l’image est grande moins les contours sont déplacés, donc plus l’erreur de codage est faible. Un autre facteur affectant le PSNR est la différence de couleur entre deux zones voisines. Si un contour est déplacé et si les couleurs, de part et d’autre du contour, sont proches, le PSNR ne sera pas beaucoup affecté.
Chapitre 6 – Méthodes pour la représentation efficace de scènes multimédia animées 0 10 20 30 40 50 60 70 0 2 4 6 8 10 12 14 16
PSNR (dB) résolution nominale PSNR (dB) résolution double PSNR (dB) résolution moitié
Figure 6.5 – PSNR (dB) de la Figure 6.4 en fonction paramètre de quantification et de la résolution
6.4.2.2.2 Propositions d'améliorations
Nous proposons ici une méthode qui consiste à modifier l'organisation des données pour éviter les artefacts de quantification. En VRML, tout comme en BIFS, il est possible de représenter un contour par une liste d'entiers correspondant aux index des points dans une liste de points préalablement définie. Pour cela, on définit un nœud Coordinate2D qui est réutilisé (via la primitive USE) par plusieurs nœuds IndexedLineSet2D et IndexedFaceSet2D. Le champ coordIndex de ces nœuds est utilisé pour spécifier les index dans la liste de points du nœud Coordinate2D.
Dans les objets graphiques qui nous intéressent, qui sont formés de nombreux contours (fermés ou ouverts), c'est-à-dire de nombreux nœuds IndexedLineSet2D et IndexedFaceSet2D, la plupart des points sont réutilisés dans des portions de contours que partagent deux formes voisines, comme nous l'avons décrit dans le chapitre 1. Or pour être réutilisables, les points de deux contours voisins doivent être dans une même liste, dans un nœud Coordinate2D. De proche en proche, on se rend compte que pratiquement tous les points d’un objet comme celui de la Figure 6.4 doivent être contenus dans une même liste, dans un même nœud Coordinate2D, pour être réutilisables dans tous les contours de l'objet, c'est-à-dire dans tous les nœuds IndexedLineSet2D et
Descriptions de scènes multimédia : représentations et optimisations
- 132 -
Cette représentation présente un intérêt de codage quand, en moyenne, le codage d'un point et de ses réutilisations, sous forme d'index sur cette liste globale de points, est plus efficace que le codage répété du point, ce qui est notre cas d'après les statistiques du Tableau 3.1.
Cette représentation présente également un second avantage. En effet, si tous les points d'un même objet graphique appartiennent à une même liste, on ne peut que les quantifier selon les mêmes paramètres. De ce fait, un point qui appartient à deux contours différents ne sera quantifié qu'une seule fois. On évite ainsi l'apparition de trous entre les contours.
6.4.2.2.3 Granularité de la signalisation
La quantification BIFS nécessite un nœud QuantizationParameter qui est codé dans le flux binaire en utilisant entre 100 et 200 bits. Il est donc impossible de placer un tel nœud devant chaque primitive graphique, et inefficace d'en placer un seul pour toutes les primitives graphiques qui forment l'objet composite. Il faut trouver le bon compromis. Nous avons montré par le calcul dans la revue T-