FR 2888962 A1 20070126 FR 0313380 A 20031114 La présente invention concerne d'une manière générale les animations, par exemple construites selon la technique appelée Flash développée par la société Macromedia. Cette technique permet de fabriquer un fichier contenant une animation qui peut être jouée sur un ordinateur. Il est possible d'inclure une ou des image(s) au format JPEG2000 dans cette animation. Une description de ce format est disponible à l'adresse internet: http:llwww.jpeg.org. On s'intéresse plus particulièrement à la création d'une telle animation. La qualité d'affichage de l'animation dépend directement du nombre d'images clés. En effet, plus il y a d'images clés, moins le nombre d'interpolation est grand et par conséquent plus la qualité visuelle de l'animation est grande. Cependant, plus il y a d'images clés à transmettre et plus le débit de transmission est grand et plus le coût calculatoire pour traiter les images clés est grand. Il faut donc trouver un compromis entre la qualité de l'animation d'une part et les capacités de calcul et la bande passante du réseau d'autre part. Dans le document US 6 081 278, deux versions d'une animation sont mémorisées sur un serveur. L'une des versions comporte un plus grand 30 nombre d'images clés que l'autre. Lorsqu'un terminal client demande l'animation, il envoie ses caractéristiques au serveur qui détermine quelle version est la mieux adaptée avant d'envoyer cette version. Si beaucoup de terminaux clients demandent une animation simultanément, la charge de calcul liée à la recherche de la version adaptée à chaque terminal client peut devenir trop importante pour le serveur. Le document US 6 442 603 traite du cas d'un document contenant plusieurs types de contenu tels que texte, audio, image, vidéo. Comme dans le document précédent, lorsqu'un terminal client demande l'animation, il envoie ses caractéristiques au serveur. Ce dernier détermine quels sont les types de données qui sont compatibles avec le terminal client. Ce système présente le même inconvénient que celui du document précédent. En outre, il ne permet pas de moduler la qualité dans un même type de données. Le document intitulé Low complexity video coding for receiverdriven layered multicast , de S. Mc Canne, Jacobson et M. Vetterli, paru dans IEEE Journal of selected areas in communications, Vol. 15, N 6, août 1997, pages 983-1001, propose un système dans lequel le serveur n'a aucun rôle actif dans le choix du niveau de qualité des données envoyées à un terminal client. Dans ce système, le serveur envoie plusieurs niveaux de hiérarchie d'un flux vidéo sur des adresses multipoints séparées. Un terminal client est abonné à un certain nombre de niveaux. Il commence par s'abonner au niveau de hiérarchie le plus bas puis tente de s'abonner aux niveaux plus élevés tant qu'il ne constate pas de perte. Il n'y a pas de surcharge du serveur. En revanche, le trafic lié à la gestion des arbres multipoints est élevé. En outre, il est nécessaire que des routeurs compatibles avec le multipoint existent dans les réseaux de transmission. A l'heure actuelle, très peu de ces routeurs existent sur l'Internet. Enfin, le temps de convergence vers le niveau de qualité optimal est élevé, ce qui est peu compatible avec des animations de type Flash. Le document US 6 185 625 propose une méthode selon laquelle l'utilisateur du terminal client fixe les paramètres de qualité qui seront utilisés pour jouer l'animation. Ces informations sont transmises au serveur, et l'animation est 5 codée de manière spécifique en fonction des paramètres fixés par l'utilisateur. L'animation codée est ensuite transmise au terminal client. Cette méthode implique donc un codage spécifique de l'animation avant sa transmission. Cela peut retarder la transmission. En outre, l'utilisateur du terminal client doit posséder des 10 connaissances techniques pour fixer les paramètres de qualité de manière appropriée. Dans le document US 6 442 658, une animation est considérée comme un ensemble de segments. Les segments sont classés selon leur probabilité d'être joués après le segment courant et également selon un coût 15 de transmission estimé. Ainsi, un pré chargement est réalisé en fonction de la probabilité et du coût. La mémoire disponible des terminaux clients peut en outre être prise en compte. Le temps de transmission de l'animation est réduit. Cependant, ce document ne propose pas de compromis entre la qualité de l'animation d'une part et les capacités de calcul et la bande passante du réseau d'autre part. Le guide utilisateur de Flash MX intitulé Flash MX , aux éditions Dunod, décrit le langage ActionScript qui permet à un utilisateur d'interagir dynamiquement avec une animation. Le contrôle qui est ainsi possible est indépendant des capacités des terminaux clients ou de la bande passante. La présente invention vise à remédier aux inconvénients de la technique antérieure, en fournissant un procédé et un dispositif de création d'animation qui permettent un compromis entre la qualité de l'animation d'une part et/ou les capacités de calcul d'un terminal client et la bande passante du réseau de transmission d'autre part. A cette fin, l'invention propose un procédé de création d'une animation comportant des images clés, caractérisé en ce qu'il comporte les étapes de: - détermination d'une pluralité de versions de l'animation en fonction d'au moins un critère correspondant à au moins une caractéristique du client susceptible de télécharger l'animation, - création d'un fichier comportant une description des différentes versions déterminées et leur critère associé. L'invention permet une adaptation fine de l'animation aux capacités du terminal client et de la bande passante disponible. La charge de calcul du coté du serveur est réduite, puisque c'est le terminal client qui détermine automatiquement la version qui lui est adaptée. Ainsi, il n'y a pas de temps de latence important lors du téléchargement d'une animation. En effet, même s'il y a beaucoup de terminaux clients qui demandent l'animation simultanément, les calculs sont répartis sur les terminaux clients. Selon un premier mode de réalisation, l'étape de détermination comporte les étapes de: - affectation d'un niveau de priorité à chaque image clé, calcul d'un coût de décodage global des images clés de chaque niveau de priorité. Dans ce cas, le coût de décodage est adapté aux capacités calculatoires du terminal client qui télécharge l'animation. Selon une caractéristique préférée, une version de l'animation comporte des images clés auxquelles un même niveau de priorité a été affecté. Ainsi, le nombre d'images clés à télécharger varie en fonction du 30 niveau de priorité. Selon un second mode de réalisation, l'étape de détermination comporte les étapes de: - détermination de plusieurs classes de terminaux clients en fonction de leur bande passante, - détermination d'une version de chaque image clé pour chaque classe de terminaux clients. Dans ce cas, c'est la bande passante qui est prise en compte. Le temps de téléchargement de l'animation est ainsi limité. Ben entendu, il est possible de tenir compte à la fois des capacités calculatoire des terminaux clients et de la bande passante. Selon une caractéristique préférée, l'étape de création comporte la 10 détermination de requêtes pour chaque image clé, destinées à obtenir chaque image clé depuis un terminal distant. Selon une caractéristique préférée, les requêtes sont de type JPIP. Les requêtes JPIP sont établies selon un protocole en cours de normalisation, dont une description peut être trouvée à l'adresse Internet: 15 http:llwww.jpeg.org. L'invention a également trait à un procédé de téléchargement d'une animation depuis un serveur vers un terminal client, l'animation ayant été créée par le procédé de création présenté ci-dessus, caractérisé en ce qu'il comporte les étapes de: - réception de la description des différentes versions de l'animation, - sélection d'une version de l'animation en fonction d'au moins une caractéristique du terminal client, - émission de requêtes en fonction de la version sélectionnée. Selon le premier mode de réalisation, l'étape de sélection comporte les étapes de: - détermination d'un niveau de priorité de l'animation en fonction du coût de décodage global des images clés de chaque niveau de priorité et des capacités de traitement du terminal client, - sélection des images clés appartenant au niveau de priorité déterminé. Selon le second mode de réalisation, l'étape de sélection comporte les étapes de: - détermination de la bande passante effective du terminal client, - identification de la classe du terminal client en fonction de sa bande 5 passante effective, - sélection des versions des images clés correspondant à la classe du terminal client. Corrélativement, l'invention concerne un dispositif de création d'une animation comportant des images clés, caractérisé en ce qu'il comporte: des moyens de détermination d'une pluralité de versions de l'animation en fonction d'au moins un critère correspondant à au moins une caractéristique du client susceptible de télécharger l'animation, - des moyens de création d'un fichier comportant une description 15 des différentes versions déterminées et leur critère associé. L'invention concerne aussi un dispositif de téléchargement d'une animation depuis un serveur vers un terminal client, l'animation ayant été créée par le dispositif de création précédent, caractérisé en ce qu'il comporte: des moyens de réception de la description des différentes versions de l'animation, - des moyens de sélection d'une version de l'animation en fonction d'une caractéristique du terminal client, - des moyens d'émission de requêtes en fonction de la version 25 sélectionnée. Les dispositifs selon l'invention comportent des moyens de mise en oeuvre des caractéristiques précédemment exposées. Le dispositif de création, le procédé et le dispositif de 30 téléchargement présentent des avantages analogues à ceux précédemment présentés. L'invention concerne aussi un fichier comportant les données de codage d'une animation créée par le procédé de création précédemment présenté, caractérisé en ce qu'il comporte une indexation, une suite de requêtes, une priorité et un instant d'affichage, pour chaque image clé, et en outre le coût calculatoire de chaque niveau de priorité. L'invention concerne aussi un fichier comportant les données de codage d'une animation créée par le procédé de création précédemment présenté, caractérisé en ce qu'il comporte une indexation, une suite de requêtes classées en fonction des classes de terminaux clients et un instant d'affichage, pour chaque image clé, et en outre la définition des classes. L'invention concerne aussi un appareil numérique incluant le dispositif selon l'invention ou des moyens de mise en oeuvre du procédé selon l'invention. Cet appareil numérique est par exemple un appareil photographique numérique, un caméscope numérique, un scanner, une imprimante, un photocopieur, un télécopieur. Les avantages du dispositif et de l'appareil numérique sont identiques à ceux précédemment exposés. Un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non au dispositif, éventuellement amovible, mémorise un programme mettant en oeuvre le procédé selon l'invention. Un programme d'ordinateur lisible par un microprocesseur et comportant une ou plusieurs séquence d'instructions est apte à mettre en oeuvre les procédés selon l'invention. Les caractéristiques et avantages de la présente invention 25 apparaîtront plus clairement à la lecture d'un mode préféré de réalisation illustré par les dessins ci-joints, dans lesquels: - la figure 1 est un mode de réalisation d'un dispositif mettant en oeuvre l'invention, - la figure 2 représente un dispositif selon l'invention, - la figure 3 représente un premier mode de réalisation de procédé de création d'animation selon l'invention, - la figure 4 représente une interface graphique utilisée dans le procédé de la figure 3, - la figure 5 représente un fichier contenant une animation selon l'invention, - la figure 6 représente un mode de réalisation de calcul d'un coût calculatoire inclus dans le procédé de la figure 3, - la figure 7 représente un premier mode de réalisation de procédé de téléchargement d'animation selon l'invention, la figure 8 représente un mode de réalisation de détermination 10 niveaux de priorité, incluse dans le procédé de la figure 7, - la figure 9 représente un second mode de réalisation de procédé de création d'animation selon l'invention, - la figure 10 représente un fichier contenant une animation selon l'invention, - la figure 11 représente un mode de réalisation de détection d'images posant un problème de transmission, incluse dans le procédé de la figure 9, - la figure 12 représente une structure de liste d'images, - la figure 13 représente un mode de réalisation de détermination de 20 différentes versions d'une image respectant une bande passante prédéterminée, - la figure 14 représente un second mode de réalisation de procédé de téléchargement d'animation selon l'invention. Selon le mode de réalisation choisi et représenté à la figure 1, un serveur 1 est relié à des terminaux clients 2, dont un seul est représenté, par l'intermédiaire d'un réseau de communication 3. Le serveur 1 et le terminal client 2 sont des ordinateurs dont un exemple d'architecture est décrit dans la suite. La connexion entre les deux dispositifs est classique et ne sera pas décrite ici. Elle est par exemple de type http. On suppose que la transmission de données est effectuée sans perte. Le serveur 1 comporte une unité 10 de réception de requêtes provenant du terminal client 2. II comporte également une unité 11 d'émission de données numériques à destination du terminal client 2. L'unité 10 de réception de requêtes transmet les requêtes reçues à l'unité 12 de traitement. Le traitement comporte l'identification des données requises, leur formatage et leur transmission par l'intermédiaire de l'unité 11. Le serveur 1 comporte également une mémoire 13 dans laquelle sont mémorisées des données. Une unité de commande 14 contrôle le fonctionnement des unités du serveur 1. Selon l'invention, le serveur 1 comporte une unité 15 de création d'une animation, qui comporte: - des moyens de détermination d'une pluralité de versions de l'animation en fonction d'au moins un critère correspondant à au moins une caractéristique du client susceptible de télécharger l'animation, - des moyens de création d'un fichier comportant une description des différentes versions déterminées et leur critère associé. Le terminal client 2 comporte une unité 20 d'envoi de requêtes vers le serveur 1. II comporte également une unité 21 de réception de données numériques provenant du serveur 1. L'unité 21 transmet les données reçues à l'unité 22 de traitement. Le traitement, objet de la présente invention, est détaillé dans la suite à l'aide d'algorithmes. Selon l'invention, l'unité 21 reçoit la description des différentes versions de l'animation. L'unité 22 sélectionne une version de l'animation en fonction d'au moins une caractéristique du terminal client. Enfin l'unité 20 émet des requêtes en fonction de la version sélectionnée. Le terminal client 2 comporte également une mémoire 23 dans laquelle sont mémorisées des données. Une unité de commande 24 contrôle le fonctionnement des unités du terminal client 2. Selon le mode de réalisation choisi et représenté à la figure 2, un dispositif mettant en oeuvre l'invention est par exemple un microordinateur 10 connecté à différents périphériques, par exemple une caméra numérique 107 (ou un scanner, ou tout moyen d'acquisition ou de stockage d'image) reliée à une carte graphique et fournissant des informations à traiter selon l'invention. Le dispositif 10 comporte une interface de communication 112 reliée à un réseau 113 apte à transmettre des données numériques à traiter ou inversement à transmettre des données traitées par le dispositif. Le dispositif 10 comporte également un moyen de stockage 108 tel que par exemple un disque dur. II comporte aussi un lecteur 109 de disque 110. Ce disque 110 peut être une disquette, un CD-ROM ou un DVD-ROM, par exemple. Le disque 110 comme le disque 108 peuvent contenir des données traitées selon l'invention ainsi que le ou les programmes mettant en oeuvre l'invention qui, une fois lu par le dispositif 10, sera stocké dans le disque dur 108. Selon une variante, le programme permettant au dispositif de mettre en oeuvre l'invention, pourra être stocké en mémoire morte 102 (appelée ROM sur le dessin). En seconde variante, le programme pourra être reçu pour être stocké de façon identique à celle décrite précédemment par l'intermédiaire du réseau de communication 113. Le dispositif 10 est relié à un microphone 111. Les données à traiter selon l'invention seront dans ce cas du signal audio. Ce même dispositif possède un écran 104 permettant de visualiser les données à traiter ou de servir d'interface avec l'utilisateur qui peut ainsi paramétrer certains modes de traitement, à l'aide du clavier 114 ou de tout autre moyen (souris par exemple). L'unité centrale 100 (appelée CPU sur le dessin) exécute les instructions relatives à la mise en oeuvre de l'invention, instructions stockées dans la mémoire morte 102 ou dans les autres éléments de stockage. Lors de la mise sous tension, les programmes de traitement stockés dans une mémoire non volatile, par exemple la ROM 102, sont transférés dans la mémoire vive RAM 103 qui contiendra alors le code exécutable de l'invention ainsi que des registres pour mémoriser les variables nécessaires à la mise en oeuvre de l'invention. De manière plus générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non au dispositif, éventuellement amovible, mémorise un programme mettant en oeuvre le procédé selon l'invention. Le bus de communication 101 permet la communication entre les différents éléments inclus dans le micro-ordinateur 10 ou reliés à lui. La représentation du bus 101 n'est pas limitative et notamment l'unité centrale 100 est susceptible de communiquer des instructions à tout élément du micro-ordinateur 10 directement ou par l'intermédiaire d'un autre élément du micro- ordinateur 10. La figure 3 représente un premier mode de réalisation de procédé de création d'une animation, selon l'invention. Ce procédé est mis en oeuvre dans le dispositif de création et comporte des étapes El à E8. Le procédé est réalisé sous la forme d'un algorithme qui peut être mémorisé en totalité ou en partie dans tout moyen de stockage d'information capable de coopérer avec le microprocesseur. Ce moyen de stockage est lisible par un ordinateur ou par un microprocesseur. Ce moyen de stockage est intégré ou non au dispositif, et peut être amovible. Par exemple, il peut comporter une bande magnétique, une disquette ou un CD-ROM (disque compact à mémoire figée). L'étape El est la sélection d'une image IM pour servir de base à l'animation. L'image est codée selon la norme JPEG 2000 qui permet un accès rapide et facile à différentes résolutions, qualités et régions d'intérêt de l'image. L'animation est créée à partir de cette seule image. En variante, l'animation est créée à partir de plusieurs images. L'étape suivante E2 est la définition des images clés IMn de l'animation, avec n un entier variant entre 1 et un entier N. Pour cela, l'utilisateur utilise une interface graphique. Cette interface est par exemple générée en utilisant la bibliothèque C++ de conception d'interface graphique QT proposée par la société TrollTech, disponible à l'adresse internet: http:l/www.trolltech.coml. Cette interface comporte plusieurs fenêtres. Comme représenté à la figure 4, la fenêtre A affiche la taille originale de l'image. La fenêtre B affiche la taille de l'image après modification. Les fenêtres C et D permettent de modifier la taille de l'image. Une nouvelle taille exprimée en pixels peut être définie dans la fenêtre C ou une nouvelle taille exprimée en pourcentage de la taille de l'image initiale peut être définie dans la fenêtre D. Il est à noter que dans le mode préféré de l'invention, seules des tailles correspondant aux résolutions définies dans l'image originale peuvent être choisies. La fenêtre E permet de choisir la qualité de l'image. Par exemple, les images possèdent neuf niveaux de qualité. La fenêtre F permet d'indiquer qu'une zone rectangulaire H de l'image IM va être sélectionnée. La fenêtre J permet de fixer l'instant d'affichage de l'image. L'étape suivante E3 est la définition d'un niveau de priorité Pn pour chaque image clé IMn. Le niveau de priorité d'une image clé dépend de son importance. Une image qui peut être approximée par interpolation entre deux autres images reçoit un niveau de priorité faible. Une image qui serait dégradée par une approximation par interpolation reçoit une priorité plus élevée. Une image qui ne peut pas être interpolée reçoit une priorité encore plus élevée. Huit niveaux de priorité PI à P8 sont par exemple disponibles. Le niveau 1 est le niveau de priorité le plus élevé. Les priorités sont décroissantes jusqu'au niveau 8. L'utilisateur définit le niveau de priorité de l'image grâce à la fenêtre G (figure 4). L'étape suivante E4 est le calcul pour chaque image clé IMn de requêtes Rn1, Rn2, ... selon le protocole JPIP. Le protocole JPIP de transmission de données codées selon la norme JPEG2000 permet à un terminal distant de rapatrier une image. Une liste de requêtes JPIP est ainsi formée et mémorisée dans un fichier destiné à être téléchargé, interprété puis joué sur un terminal client. Ce fichier, ou script d'animation, est par exemple au format SWF. Les requêtes JPIP sont établies selon un protocole en cours de normalisation, dont une description peut être trouvée à l'adresse internet: http:llwww. jpeg.org. Pour chaque image clé, des informations relatives à la taille, la résolution, la qualité, la zone sélectionnée, qui ont été définies à l'étape E2 sont insérées dans les requêtes JPIP. L'étape suivante E5 est la définition, à l'aide de la fenêtre J, d'un instant d'affichage Tn pour chaque image clé IM,. Un instant d'affichage est un temps en secondes, déterminé à partir du début de l'animation. Lors de l'exécution ultérieure de l'animation, chaque image est affichée à l'instant défini. L'étape suivante E6 est le calcul du coût de décodage global cck de chaque niveau de priorité Pk avec k un entier variant entre 1 et 8. Le coût de décodage global cck d'un niveau de priorité Pk est le coût de décodage des images clé du niveau de priorité donné, et d'interpolation des autres images à partir de ces images clés. Pour cela, un outil informatique d'analyse de programme, tel que celui nommé Quantify de la société Rational Software Corporation, décrit à l'adresse Internet http:l/www.rational.comlproductslquantify ntl, détermine le nombre d'opérations élémentaires effectuées lors de l'exécution du programme et le temps d'exécution du programme. Le nombre d'opérations élémentaires effectuées par seconde est alors calculé en divisant le premier résultat par le second. En variante, la commande Time dans les systèmes d'exploitation Unix et Linux permet de déterminer le coût calculatoire d'un programme. Un mode de réalisation de l'étape E6 est détaillé dans la suite. L'étape suivante E7 est la mémorisation des données relatives à l'animation dans un fichier FIM représenté à la figure 5. Ce fichier comporte, pour chaque image clé IM,, l'indexation n, la suite de requêtes JPIP la priorité Pr, et l'instant d'affichage Tn. Il comporte en outre le coût calculatoire cck de chaque niveau de priorité. L'étape suivante E8 est la mémorisation du fichier précédent sur le serveur. L'étape E6 de détermination d'un coût calculatoire pour chaque niveau de priorité d'une animation est maintenant détaillée en référence à la figure 6, sous la forme d'un algorithme comportant des étapes E60 à E64. L'étape E60 est une initialisation à laquelle une variable k est initialisé à la valeur un. La variable k représente le niveau de priorité courant. L'étape suivante E61 est un test pour déterminer si la variable k est inférieure ou égale au nombre de niveaux de priorité. Si la réponse est positive, Cette étape est suivie de l'étape E62 à laquelle le coût calculatoire Ck de décodage de l'animation en ne considérant que les niveaux de priorité de 1 à k est calculé. Comme précédemment exposé, ce coût est calculé avec un outil d'analyse de programme connu en soit. L'étape suivante E63 est le calcul du coût calculatoire cck du niveau courant. Pour cela, le coût calculatoire Ck calculé à l'étape précédente est diminué du coût calculatoire Ck-1 calculé lors de l'itération précédente. Bien entendu, lors du premier passage par cette étape (k=1), la quantité Ck_1 est nulle. A l'étape suivante E64, la variable k est incrémentée de une unité. Cette étape est suivie de l'étape E61 précédemment décrite. Lorsque la réponse est négative à l'étape E61, les coûts calculatoire de tous les niveaux de priorité de l'animation ont été déterminés. La figure 7 représente un premier mode de réalisation de procédé de téléchargement d'une animation, selon l'invention. Ce procédé est mis en oeuvre dans le terminal client 2 et comporte des étapes E10 à E19. Le procédé est réalisé sous la forme d'un algorithme qui peut être mémorisé en totalité ou en partie dans tout moyen de stockage d'information capable de coopérer avec le microprocesseur. Ce moyen de stockage est lisible par un ordinateur ou par un microprocesseur. Ce moyen de stockage est intégré ou non au dispositif, et peut être amovible. Par exemple, il peut comporter une bande magnétique, une disquette ou un CD-ROM (disque compact à mémoire figée). L'étape El0 est l'envoi d'une requête au serveur pour obtenir le fichier de description de l'animation. L'étape suivante El 1 est la réception du fichier de description. L'étape suivante E12 est la recherche du niveau de priorité le plus élevé possible en fonction du coût de décodage de chaque niveau de priorité et des capacités de traitement du terminal client. Cette étape est détaillée dans la suite. L'étape suivante E13 est un test de compatibilité de l'animation avec le terminal client. Si aucun niveau de priorité n'est compatible avec le terminal client, une variable logique COMP est mise à la valeur faux . Sinon, cette variable est mise à la valeur vrai . L'étape suivante E14 est un test sur la valeur de la variable logique 15 COMP. Si elle indique une incompatibilité, cette étape est suivie de l'étape El 5 qui est l'affichage d'un message d'erreur. S'il y a compatibilité à l'étape E14, cette étape est suivie de l'étape E16 qui est l'émission des requêtes JPIP correspondant au niveau de priorité 20 précédemment déterminé. L'étape suivante E17 est la réception et le décodage des données reçues en réponse aux requêtes émises. L'étape suivante E18 est une interpolation entre les images clés reçues, si elle est nécessaire pour pouvoir jouer l'animation à 25 images par seconde. L'interpolation est classique. Elle est pondérée en fonction de la distance entre l'image interpolée et les images clés utilisée pour l'interpolation. L'étape suivante E19 est l'affichage de l'animation à une fréquence de 25 images par seconde sur le terminal client. L'étape E12 de recherche du niveau de priorité le plus élevé possible en fonction du coût de décodage de chaque niveau de priorité et des capacités de traitement du terminal client est maintenant détaillée en référence à la figure 8, sous la forme d'un algorithme comportant des étapes E120 à E126. L'étape E120 est une initialisation à laquelle le nombre K de niveaux de priorités définis dans l'animation est lu. Une variable k est initialisée à un. La variable k représente un niveau de priorité courant. Une variable C est aussi initialisée à la valeur zéro. La variable C représente le cumul des coûts calculatoires des différents niveaux. La capacité de calcul CPU du terminal client exprimée en nombre d'opérations élémentaires par secondes est lue dans la mémoire 112. L'étape suivante E121 est un test pour déterminer s'il reste au moins un niveau de priorité à considérer. Si la réponse est positive, cette étape est suivie de l'étape E122 à laquelle le cumul C des coûts calculatoires est augmenté du coût calculatoire du niveau de priorité courant. L'étape suivante E123 est un test pour déterminer si le coût calculatoire C est inférieur à la capacité de calcul CPU du terminal client. Si la réponse est positive, cela signifie que le terminal client a une capacité supérieure au coût calculatoire déterminé. Cette étape est alors suivie de l'étape E124 à laquelle la variable k est incrémentée de une unité pour considérer un niveau de priorité suivant. L'étape E124 est suivie de l'étape E121 précédemment décrite. Lorsque la réponse est négative à l'étape E123, cela signifie que la capacité de calcul du terminal client est inférieure au coût calculatoire déterminé. Dans ce cas, l'étape E123 est suivie de l'étape E125, à laquelle les requêtes JPIP correspondant aux niveaux de priorité de rangs inférieurs à celui du niveau courant Pk sont transmises à l'interface de communication du terminal client. Lorsque la réponse est négative à l'étape E121 cela signifie que la capacité de calcul du terminal client est supérieure au coût calculatoire de tous les niveaux de priorités de l'animation. Dans ce cas, l'étape E121 est suivie de l'étape E126, à laquelle les requêtes JPIP correspondant à tous les niveaux de priorité de l'animation sont transmises à l'interface de communication du terminal client. La figure 9 représente un second mode de réalisation de procédé de création d'une animation, selon l'invention. Ce procédé est mis en oeuvre dans le dispositif de création et comporte des étapes E20 à E28. Le procédé est réalisé sous la forme d'un algorithme qui peut être mémorisé en totalité ou en partie dans tout moyen de stockage d'information capable de coopérer avec le microprocesseur. Ce moyen de stockage est lisible par un ordinateur ou par un microprocesseur. Ce moyen de stockage est intégré ou non au dispositif, et peut être amovible. Par exemple, il peut comporter une bande magnétique, une disquette ou un CD-ROM (disque compact à mémoire figée). L'étape E20 est la définition de plusieurs classes de terminaux clients. L'utilisateur dispose d'une interface graphique pour sélectionner différentes valeurs de bandes passantes représentant le débit effectif entre le serveur et un terminal client. Par exemple, trois classes CL1, CL2 et CL3 sont créées. L'étape suivante E21 est la mémorisation des seuils de bande passante définissant les classes de terminaux clients. L'étape suivante E22 est la sélection et la définition des images clés IMn de l'animation. Une ou plusieurs images codées selon la norme JPEG2000 sont sélectionnées, et des images clés sont formées. La construction des images clés peut être faite avec une interface graphique du type de celle présentée dans le premier mode de réalisation. En variante, la construction des images clés peut être faite grâce à un outil de création de contenu tel que le logiciel Flash MX de création de contenu au format flash de la société Macromedia. Cet outil est disponible via Internet à l'adresse: http://www.macromedia. com/software/flash/. Le livre intitulé Flash MX de Guylaine Monnier, aux éditions Dunod, Paris, 2002, décrit ce logiciel. Un instant d'affichage Tn pour chaque image clé est déterminé. Un instant d'affichage est un temps en secondes, déterminé à partir du début de l'animation. L'étape suivante E23 est le calcul du coût de transmission de chaque image clé 1Mn. Le coût de transmission d'une image clé IMn est le débit Dn nécessaire à la transmission. Le débit Dn est égal à FxSn, où F est la résolution temporelle de l'animation, exprimée en s"' et Sn est la taille de l'image clé considérée, exprimée en bits. Les coûts de transmission sont mémorisés à cette étape. L'étape suivante E24 est une détection des éventuelles images clés posant un problème de transmission. Pour chaque classe de clients, correspondant à une bande passante maximale, on recherche s'il existe des images qui dépassent la bande passante maximale de sorte que le temps de transmission entre le serveur et un terminal client soit incompatible avec un affichage de bonne qualité de l'animation sur le terminal client. Cette étape est détaillée dans la suite. Elle a pour résultat une liste L 15 d'images non compatibles avec les bandes passantes maximales des différentes classes. L'étape suivante E25 est le calcul, pour chaque image de la liste L, d'un ensemble de couples (débit, distorsion) pour chaque version (résolution, qualité) de l'image. Cette étape est détaillée dans la suite. L'étape suivante E26 est le calcul des requêtes JPIP de chaque image clé IMn, qui permettront à chaque classe CL1 à CL3 de clients d'obtenir la version de l'image clé adaptée à la bande passante dont il dispose. Pour une image clé donnée, il faut récupérer les informations relatives à la taille, la résolution, la qualité, et la zone éventuellement sélectionnée dans l'image clé. II faut ensuite vérifier si cette image clé appartient à la liste L des images clés posant un problème de transmission. Si l'image clé courante n'appartient pas à la liste L, les informations précédentes sont insérées dans les champs de données des requêtes JPIP. Si l'image clé courante appartient à la liste L, alors les requêtes JPIP associées portent sur une version dégradée de l'image clé, et non sur l'image clé initiale. On considère les classes les unes après les autres. Pour une classe donnée correspondant à une bande passante donnée, et pour une image clé donnée, on considère la version (résolution et qualité) de cette image dont le débit est compatible avec la bande passante et dont la distorsion est minimale. Cette version est obtenue en résultat de l'étape précédente E25. La requête JPIP de cette version est formée et mémorisée dans le fichier de description. L'étape suivante E27 est la mémorisation des données relatives à l'animation dans un fichier FF représenté à la figure 10. Ce fichier comporte, pour chaque image clé IMn, l'indexation n, la suite de requêtes JPIP Rn1, Rn2,... classées en fonction des classes de terminaux clients et l'instant d'affichage Tn. Il comporte en outre la définition des classes CL1 à CL3. L'étape suivante E28 est la mémorisation du fichier FF sur le serveur. Un mode de réalisation de l'étape E24 de détermination des images qui ne respectent pas la bande passante est décrit en référence à la figure 11, sous la forme d'un algorithme comportant des étapes E240 à E250. L'étape E240 est la lecture de la valeur de la fréquence F d'affichage des images de l'animation. L'étape suivante E241 est la création d'une liste L vide. La liste L est associée à un tableau T illustré à la figure 12, contenant des données sur chaque image dépassant l'une des bandes passantes maximales des classes de clients. Pour chaque image de la liste L, les données suivantes sont mémorisées dans le tableau T: - l'indice temporel de l'image, - l'indice de la classe de client de bande passante la plus faible possible pour laquelle l'image ne pose pas de problème, - sa taille en octets, - la taille à laquelle le créateur de l'animation souhaite afficher l'image dans l'animation, 2888962 20 - le niveau de qualité Qumax fixé par le créateur. Une variable i est initialisée à la valeur un. La variable i représente l'indice de la classe de clients courante CL;. On considère tout d'abord la classe correspondant à la bande passante la plus faible, puis les classes par bande passante croissante. L'étape suivante E242 est la lecture de la valeur de la bande passante maximale BPmax associée à la classe courante CL;. En outre, une bande passante disponible LBP est due au faible coût de transmission des paramètres d'interpolation entre deux images clés. La bande passante disponible ABP dépend de la bande passante maximale BPmax courante, du nombre d'images interpolées entre deux images clés, du nombre de bits nécessaire pour représenter les paramètres d'interpolation et de la fréquence de l'animation. L'étape suivante E243 est une initialisation à laquelle un paramètre m est initialisé pour considérer la première image clé IMm posant un problème de transmission pour la classe traitée à l'itération précédente. Lors du premier passage par cette étape, on considère la première image clé de l'animation. L'étape suivante E244 est la lecture de la taille Dm en octets de l'image courante. L'étape suivante E245 est un test pour déterminer si l'image courante respecte la bande passante BPmax. Il s'agit de vérifier si l'image peut être transmise en un temps inférieur à 11F. Pour cela, on vérifie si l'inégalité : F.Dm Si la réponse est négative, cela signifie que l'image courante IMm ne respecte pas la bande passante. Dans ce cas, l'étape E245 est suivie de l'étape E246 à laquelle l'image courante IMm est inscrite dans la liste L, avec les données énoncées précédemment. Si la réponse est positive à l'étape E245, cela signifie que l'image courante IMm respecte la bande passante. Dans ce cas, l'étape E245 est suivie 30 de l'étape E247 qui est un test pour vérifier s'il reste au moins une image clé de l'animation à traiter. Si la réponse est positive, alors cette étape est suivie de l'étape E248 pour considérer l'image clé suivante. L'étape E248 est suivie de l'étape E244 précédemment décrite. Si la réponse est négative à l'étape E247, alors cette étape est suivie 5 de l'étape E249 qui est un test pour déterminer si la liste L est vide pour la classe courante et s'il reste au moins une classe à traiter. Tant que la réponse est négative à ces deux tests, l'étape E249 est suivie de l'étape E250 pour considérer la classe suivante. L'étape E250 est suivie de l'étape E242 précédemment décrite. Lorsque la réponse est positive à au moins l'un des deux tests de l'étape E249, le traitement est terminé. Un mode de réalisation de l'étape E25 d'estimation de la qualité de différentes versions d'une image de la liste L est décrit en référence à la figure 15 13, sous la forme d'un algorithme comportant des étapes E300 à E315. On considère ici une image de la liste L. L'étape E300 est la lecture de l'indice temporel de cette image. L'étape suivante E301 est la lecture de l'image codée. Un décodeur JPEG2000 récupère alors des informations haut niveau relatives à cette image. Ces informations sont: - la résolution spatiale maximale de l'image HxW, où H et W sont la hauteur et la largeur de l'image exprimées en nombre de pixels. - le nombre de niveau de résolution Rmax utilisés pour représenter l'image. L'étape suivante E302 est le calcul de la taille de l'image et du nombre de niveaux de résolution qui sont utilisés dans le traitement suivant. La taille est fournie par les formules: h = min(H, hu) w = min(W, wu) où hu et wu sont la hauteur et la largeur de l'image exprimées en nombre de pixels, fixées par le créateur de l'animation. Le nombre de niveaux de résolution est fourni par les formules: Rumax = min(R(h, w), Rmax), Où R(h, w) est le niveau de résolution pour lequel l'image a une hauteur et une largeur respectivement inférieure ou égale à la hauteur h et à la 5 largeur w. L'étape suivante E303 est le décodage de l'image à la résolution Rumax et au niveau de qualité Qumax. L'étape suivante E304 est la mémorisation de l'image ainsi décodée et reconstruite Iv(Rumax, Qumax) pour servir d'image de référence. L'étape suivante E305 est une initialisation à laquelle deux variables R et Q sont initialisées à la valeur zéro. La variable R représente le niveau de résolution courant et la variable Q représente le niveau de qualité courant. La valeur zéro pour ces deux variables correspond aux niveaux de résolution et de qualité les plus bas. L'étape suivante E306 est l'obtention de l'image Iv(R, Q) correspondant au niveau de résolution courant R et au niveau de qualité courant Q. L'image Iv(R, Q) est obtenue par une requête JPIP. L'étape suivante E307 est la mémorisation de données 20 correspondant à l'image Iv(R, Q) dans le tableau T associé à la liste L (figure 12). Ces données sont: - la taille D(Iv(R, Q)) de l'image Iv(R, Q), exprimée en octets, - le niveau de résolution courant R, - le niveau de qualité courant Q. L'étape suivante E308 est le décodage de l'image courante Iv(R, Q). L'étape suivante E309 est un agrandissement de l'image courante décodée pour former une image agrandie Iv(Rumax, Q) à la résolution Rumax. Bien entendu, si les résolutions R et Rumax sont égales, il n'y a pas d'agrandissement. L'étape suivante E310 est une comparaison de l'image agrandie Iv(Rumax, Q) avec l'image de référence Iv(Rumax, Qumax). Ainsi, la dégradation de qualité de l'animation est estimée, dans le cas du remplacement de l'image de référence par l'image agrandie Iv(Rumax, Q). Cette estimation est par exemple l'écart quadratique moyen entre les deux images. A l'étape E311, le résultat Dist(Iv(R, Q)) de l'estimation est mémorisé dans le tableau T associé à la liste L (figure 12). L'étape suivante E312 est un test pour déterminer si la qualité courante Q est strictement inférieure à la valeur Qumax. Si la réponse est positive, alors cette étape est suivie de l'étape E313 à laquelle la qualité Q est incrémentée de une unité. L'étape E313 est suivie de l'étape E306 précédemment décrite. Si la réponse est négative à l'étape E312, alors cette étape est suivie de l'étape E314, qui est un test pour déterminer si la résolution courante R est strictement inférieure à la valeur Rumax. Si la réponse est positive, alors cette étape est suivie de l'étape E315 à laquelle la résolution R est incrémentée de une unité et la qualité courante Q est mise à la valeur zéro. L'étape E315 est suivie de l'étape E306 précédemment décrite. Si la réponse est négative à l'étape E314, alors toutes les versions possibles de l'image considérée de la liste L ont été déterminées. Ce traitement est répété pour toutes les images de la liste L. 20 La figure 14 représente un second mode de réalisation de procédé de téléchargement d'une animation, selon l'invention. Ce procédé est mis en oeuvre dans le terminal client 2 et comporte des étapes E500 à E510. Le procédé est réalisé sous la forme d'un algorithme qui peut être mémorisé en totalité ou en partie dans tout moyen de stockage d'information capable de coopérer avec le microprocesseur. Ce moyen de stockage est lisible par un ordinateur ou par un microprocesseur. Ce moyen de stockage est intégré ou non au dispositif, et peut être amovible. Par exemple, il peut comporter une bande magnétique, une disquette ou un CD-ROM (disque compact à mémoire figée). L'étape E500 est l'envoi d'une requête au serveur pour obtenir le fichier de description de l'animation. L'étape suivante E501 est la réception du fichier de description. L'étape suivante E502 est la récupération de la bande passante effective du terminal client 2. Cette opération est effectuée soit à partir d'un fichier de configuration, soit par demande à l'utilisateur au moyen d'une interface graphique. L'étape suivante E503 est une identification de la classe du terminal client à partir de la description de l'animation et en fonction de sa bande passante. Les versions des images clés correspondant à la classe du terminal client sont sélectionnées. L'étape suivante E504 est un test de compatibilité de l'animation avec le terminal client. Si le terminal client ne dispose pas d'une bande passante suffisante pour l'animation, une variable logique COMP est mise à la valeur faux . Sinon, cette variable est mise à la valeur vrai . L'étape suivante E505 est un test sur la valeur de la variable logique 15 COMP. Si elle indique une incompatibilité, cette étape est suivie de l'étape E506 qui est l'affichage d'un message d'erreur. S'il y a compatibilité à l'étape E505, cette étape est suivie de l'étape E507 qui est l'émission des requêtes JPIP correspondant à la classe 20 précédemment déterminée. L'étape suivante E508 est la réception et le décodage des données reçues en réponse aux requêtes émises. L'étape suivante E509 est une interpolation entre les images clés reçues, si elle est nécessaire pour pouvoir jouer l'animation à 25 images par 25 seconde. L'étape suivante E510 est l'affichage de l'animation à une fréquence de 25 images par seconde sur le terminal client. Bien entendu, la présente invention n'est nullement limitée aux 30 modes de réalisation décrits et représentés, mais englobe, bien au contraire, toute variante à la portée de l'homme du métier. En particulier, les deux modes de réalisation sont combinables. On tient compte lors de la création de l'animation de la bande passante des terminaux clients puis on affecte un niveau de priorité à chaque image clé. REVENDICATIONS 1. Procédé de création d'une animation comportant des images clés, caractérisé en ce qu'il comporte les étapes de: - détermination (E3, E4, E6) d'une pluralité de versions de l'animation en fonction d'au moins un critère correspondant à au moins une caractéristique du client susceptible de télécharger l'animation, - création (E7) d'un fichier comportant une description des différentes versions déterminées et leur critère associé. 2. Procédé de création d'une animation selon la revendication 1, caractérisé en ce que l'étape de détermination comporte les étapes de: affectation (E3) d'un niveau de priorité à chaque image clé, - calcul (E6) d'un coût de décodage global des images clés de chaque niveau de priorité. 3. Procédé de création d'une animation selon la revendication 2, 20 caractérisé en ce qu'une version de l'animation comporte des images clés auxquelles un même niveau de priorité a été affecté. 4. Procédé de création d'une animation selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'étape de détermination comporte 25 les étapes de: - détermination (E20) de plusieurs classes de terminaux clients en fonction de leur bande passante, - détermination (E24, E25) d'une version de chaque image clé pour chaque classe de terminaux clients. 5. Procédé de création d'une animation selon l'une quelconque des revendications 1 à 4, caractérisé en ce que l'étape de création (E4, E26) comporte la détermination de requêtes pour chaque image clé, destinées à obtenir chaque image clé depuis un terminal distant. 6. Procédé selon la revendication 5, caractérisé en ce que les 5 requêtes sont de type JPIP. 7. Procédé de téléchargement d'une animation depuis un serveur vers un terminal client, l'animation ayant été créée par le procédé de création selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comporte les étapes de: - réception (E11, E501) de la description des différentes versions de l'animation, - sélection (E12, E503) d'une version de l'animation en fonction d'au moins une caractéristique du terminal client, - émission ((E16, E507) de requêtes en fonction de la version sélectionnée. 8. Procédé de téléchargement selon la revendication 7, caractérisé en ce que l'étape de sélection (E12) comporte les étapes de: -détermination d'un niveau de priorité de l'animation en fonction du coût de décodage global des images clés de chaque niveau de priorité et des capacités de traitement du terminal client, - sélection des images clés appartenant au niveau de priorité déterminé. 9. Procédé de téléchargement selon la revendication 7 ou 8, caractérisé en ce que l'étape de sélection comporte les étapes de: -détermination (E502) de la bande passante effective du terminal client, -identification (E503) de la classe du terminal client en fonction de sa bande passante effective, - sélection (E503) des versions des images clés correspondant à la classe du terminal client. 10. Dispositif de création d'une animation comportant des images 5 clés, caractérisé en ce qu'il comporte: - des moyens (15) de détermination d'une pluralité de versions de l'animation en fonction d'au moins un critère correspondant à au moins une caractéristique du client susceptible de télécharger l'animation, - des moyens (15) de création d'un fichier comportant une 10 description des différentes versions déterminées et leur critère associé. 11. Dispositif de création d'une animation selon la revendication 10, caractérisé en ce que les moyens de détermination comportent: - des moyens d'affectation d'un niveau de priorité à chaque image 15 clé, - des moyens de calcul d'un coût de décodage global des images clés de chaque niveau de priorité. 12. Dispositif de création d'une animation selon la revendication 11, 20 caractérisé en ce que les moyens de détermination sont adaptés à former une version de l'animation comportant des images clés auxquelles un même niveau de priorité a été affecté. 13. Dispositif de création d'une animation selon l'une quelconque 25 des revendications 10 à 12, caractérisé en ce que les moyens de détermination comportent: - des moyens de détermination de plusieurs classes de terminaux clients en fonction de leur bande passante, - des moyens de détermination d'une version de chaque image clé 30 pour chaque classe de terminaux clients. 14. Dispositif de création d'une animation selon l'une quelconque des revendications 10 à 13, caractérisé en ce que les moyens de création comportent des moyens de détermination de requêtes pour chaque image clé, destinées à obtenir chaque image clé depuis un terminal distant. 15. Dispositif selon la revendication 14, caractérisé en ce que les moyens de détermination de requêtes sont adaptés à former des requêtes de type JPIP. 16. Dispositif de téléchargement d'une animation depuis un serveur vers un terminal client, l'animation ayant été créée par le dispositif de création selon l'une quelconque des revendications 10 à 15, caractérisé en ce qu'il comporte: - des moyens (21) de réception de la description des différentes 15 versions de l'animation, - des moyens (22) de sélection d'une version de l'animation en fonction d'au moins une caractéristique du terminal client, - des moyens (20) d'émission de requêtes en fonction de la version sélectionnée. 17. Dispositif de téléchargement selon la revendication 16, caractérisé en ce que les moyens (22) de sélection comportent: - des moyens de détermination d'un niveau de priorité de l'animation en fonction du coût de décodage global des images clés de chaque niveau de 25 priorité et des capacités de traitement du terminal client, - des moyens de sélection des images clés appartenant au niveau de priorité déterminé. 18. Dispositif de téléchargement selon la revendication 16 ou 17, 30 caractérisé en ce que les moyens (22) de sélection comportent: - des moyens de détermination de la bande passante effective du terminal client, - des moyens d'identification de la classe du terminal client en fonction de sa bande passante effective, - des moyens de sélection des versions des images clés correspondant à la classe du terminal client. 19. Dispositif de création d'une animation selon l'une quelconque des revendications 10 à 15, caractérisé en ce que les moyens de détermination et création sont incorporés dans: - un microprocesseur (100), - une mémoire morte (102) comportant un programme pour traiter les données, et une mémoire vive (103) comportant des registres adaptés à enregistrer des variables modifiées au cours de l'exécution dudit programme. 20. Dispositif de téléchargement, selon l'une quelconque des revendications 16 à 18, caractérisé en ce que les moyens de réception, sélection et émission sont incorporés dans: - un microprocesseur (100), une mémoire morte (102) comportant un programme pour traiter 20 les données, et - une mémoire vive (103) comportant des registres adaptés à enregistrer des variables modifiées au cours de l'exécution dudit programme. 21. Appareil de traitement (10) de données numériques, caractérisé 25 en ce qu'il comporte des moyens adaptés à mettre en oeuvre le procédé selon l'une quelconque des revendications 1 à 9. 22. Appareil de traitement (10) de données numériques, caractérisé en ce qu'il comporte le dispositif selon l'une quelconque des revendications 10 30 à 20. 23. Fichier comportant les données de codage d'une animation créée par le procédé de création selon la revendication 2 ou 3, caractérisé en ce qu'il comporte une indexation (n), une suite de requêtes (Rn1, Ri2), une priorité (Pn) et un instant d'affichage (Tn), pour chaque image clé (IMn), et en outre le coût calculatoire (cck) de chaque niveau de priorité. 24. Fichier comportant les données de codage d'une animation créée par le procédé de création selon la revendication 4, caractérisé en ce qu'il comporte une indexation (n), une suite de requêtes (Rn1, Rn2) classées en fonction des classes de terminaux clients et un instant d'affichage (Tn), pour chaque image clé Mn), et en outre la définition des classes (CL, à CL3).