FR2860935A1 - Procede et dispositif de traitement de donnees numeriques - Google Patents
Procede et dispositif de traitement de donnees numeriques Download PDFInfo
- Publication number
- FR2860935A1 FR2860935A1 FR0311832A FR0311832A FR2860935A1 FR 2860935 A1 FR2860935 A1 FR 2860935A1 FR 0311832 A FR0311832 A FR 0311832A FR 0311832 A FR0311832 A FR 0311832A FR 2860935 A1 FR2860935 A1 FR 2860935A1
- Authority
- FR
- France
- Prior art keywords
- signal
- exploitable
- data
- stored
- image
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/50—Information retrieval; Database structures therefor; File system structures therefor of still image data
- G06F16/51—Indexing; Data structures therefor; Storage structures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
- H04N19/63—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding using sub-band based transform, e.g. wavelets
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
Abstract
L'invention concerne un procédé de traitement de données numériques constitutives d'un signal dans un réseau de communication distribué comportant plusieurs appareils de communication, le signal étant identifié par un identifiant unique (ID), caractérisé en ce que le procédé comporte les étapes suivantes :- mémorisation, à au moins une adresse donnée d'un emplacement mémoire et dans un format lisible par une application, d'une ou de plusieurs parties du signal, appelées parties exploitables du signal,- association de l'identifiant unique du signal à chaque partie exploitable du signal,- mémorisation dans au moins un appareil de communication d'une structure de données établissant un lien entre chaque partie exploitable du signal et l'identifiant unique de ce signal.
Description
L'invention concerne un procédé et un dispositif de traitement de données
numériques constitutives d'un signal dans un réseau de communication distribué comportant plusieurs appareils de communication.
Dans un réseau de communication de type distribué, appelé aussi "terminal à terminal" (connu en terminologie anglosaxonne sous le terme "peer-topeer"), il est prévu de partager entre plusieurs appareils de communication connectés au réseau des données numériques telles que, par exemple, des fichiers audio qui sont, par exemple, au format MP3.
On connaît de tels systèmes de communication au sein d'un réseau distribué, notamment par la demande internationale WO 02/15035 au nom de Napster Inc. et intitulée "System and method for searching peer-to-peer computer network".
Il convient de noter que, dans un réseau distribué tel que l'Internet, les appareils de communication connectés qui sont, par exemple, des ordinateurs, peuvent être considérés soit comme des clients, et ils reçoivent donc des données, soit comme des serveurs, et ils fournissent alors des données à d'autres appareils du réseau.
Cependant, dans un tel réseau, les appareils ne sont pas nécessairement connectés de façon permanente au réseau, ce qui signifie que les requêtes émanant d'appareils en vue d'obtenir des données d'autres appareils sont traitées en mode asynchrone et que toutes les données ne sont pas accessibles à tout moment.
Ainsi, en fonction de l'instant auquel un client se connecte au réseau via un appareil de communication, le client peut faire appel à la source des données si l'appareil source détenteur de ces données est toujours connecté au réseau, ou bien faire appel à d'autres appareils qui ont pu stocker ces données.
Dans certains réseaux de communication distribués où un signal d'image est transmis, lors d'une première connexion, par un appareil source détenteur de ce signal, certains des appareils ont reçu ce que l'on appelle une "imagette" (connue en terminologie anglosaxonne sous le terme de "thumb nail").
Ultérieurement, lorsque ces appareils visualisent l'imagette et sont intéressés par l'obtention de données supplémentaires, il n'est pas aisé pour l'utilisateur de rechercher ces données manquantes.
On connaît, d'après le document WO 02/08945 au nom de Digimarc Corporation, un système d'échange de fichiers terminal à terminal, qui peut être centralisé comme le réseau Napster décrit dans le document WO 01/84799, ou distribué comme dans le réseau Gnutella tel que décrit dans le document intitulé "File sharing protocols: a tutorial on Gnutella" de V. Berk and G. Cybenko, Technical report, Institute for Security Technology Studies, Darmouth College Hanover, March 2001.
Dans le document WO 02/08945 mentionné ci-dessus, les fichiers échangés sont marqués avec un identificateur qui permet d'en contrôler le partage, à savoir gérer les droits d'accès, les droits de partage d'un fichier ainsi que les droits de transfert de ce fichier.
Une base de données centralisée permet, pour chaque fichier dont une copie a été fournie à un terminal, de conserver des informations comme, par exemple, les droits communiqués avec la copie du fichier, l'éventuel achat des données constitutives de ce fichier et un éventuel lien sur un site associé.
Cependant, un tel système d'échange de fichiers n'est pas satisfaisant dans la mesure où il ne permet pas de retrouver facilement des données d'un signal qui ont été manipulées par un utilisateur et stockées dans un emplacement mémoire d'un appareil client, éventuellement dans un autre format.
A cet effet, la présente invention a pour objet un procédé de traitement de données numériques constitutives d'un signal dans un réseau de communication distribué comportant plusieurs appareils de communication, le signal étant identifié par un identifiant unique ID, caractérisé en ce que le procédé comporte les étapes suivantes: - mémorisation, à au moins une adresse donnée d'un emplacement mémoire et dans un format lisible par une application, d'une ou de plusieurs parties du signal, appelées parties exploitables du signal, - association de l'identifiant unique du signal à chaque partie exploitable du signal, mémorisation dans au moins un appareil de communication d'une structure de données établissant un lien entre chaque partie exploitable du signal et l'identifiant unique de ce signal.
Corrélativement, l'invention a également pour objet un dispositif de traitement de données numériques constitutives d'un signal dans un réseau de communication distribué comportant plusieurs appareils de communication, le signal étant identifié par un identifiant unique ID, caractérisé en ce que le dispositif comporte: - des moyens de mémorisation, à au moins une adresse donnée d'un emplacement mémoire et dans un format lisible par une application, d'une ou de plusieurs parties du signal, appelées parties exploitables du signal, - des moyens d'association de l'identifiant unique du signal à chaque partie exploitable du signal, - des moyens de mémorisation dans au moins un appareil de communication d'une structure de données établissant un lien entre chaque partie exploitable du signal et l'identifiant unique de ce signal.
L'utilisateur peut ainsi sélectionner l'emplacement en mémoire où sera sauvegardée chaque partie exploitable du signal, ce qui lui permettra d'utiliser cette partie avec d'autres outils s'il le souhaite.
En liant une ou plusieurs parties exploitables du signal au moyen d'un identifiant unique et en mémorisant dans un ou plusieurs appareils de communication du réseau une structure de données qui permet d'établir ce lien entre chaque partie exploitable du signal et cet identifiant, on peut aisément retrouver à partir d'une partie exploitable du signal une ou plusieurs autres parties exploitables qui y sont liées. La ou les parties recherchées peuvent se trouver dans l'appareil où est mémorisée la structure de données, voire dans un appareil distant.
L'utilisation de ce lien permet de déterminer aisément les données disponibles dans un appareil, voire dans le réseau, et celles qui sont manquantes.
Au contraire, dans l'art antérieur, dès lors qu'un utilisateur a manipulé au niveau d'un appareil client un signal numérique qu'il a reçu, ou une partie de celui- ci, il n'est alors plus possible pour d'autres appareils du réseau de le retrouver. Ce signal ou cette partie de ce signal ne sont donc plus exploitables pour le réseau.
On notera qu'une partie exploitable du signal est considérée par un utilisateur comme une partie "cohérente" du signal. Ceci signifie que les données qui constituent la partie du signal sont directement utilisables par un utilisateur et ont donc une signification propre comme, par exemple, une "imagette" pour un signal d'image Selon une caractéristique, la structure de données prend la forme d'une table de localisation de toutes les parties exploitables du signal comportant le même identifiant unique du signal.
Ceci permet un accès rapide à la liste des parties exploitables du signal lorsque l'on connaît son identifiant qui est la clé de recherche.
Selon une caractéristique, la structure de données établit un lien entre l'identifiant unique du signal et les adresses en mémoire des différentes parties exploitables du signal.
Cela permet d'obtenir rapidement à partir d'un identifiant la liste des parties disponibles localement.
Selon une caractéristique, la structure de données établit également un lien entre chaque partie exploitable du signal et un index représentatif des données présentes dans la partie considérée.
Cette caractéristique permet de choisir la partie du signal la plus adaptée à ce que recherche l'utilisateur ou ce que demande une requête réseau sans avoir besoin d'analyser le contenu de chaque partie.
Selon une caractéristique, l'index décrit, pour chaque partie exploitable du signal, des sous-parties de données constitutives de la partie considérée.
Cette caractéristique permet, lorsque l'on recherche une sous-partie de données, d'obtenir rapidement une partie qui contient cette sous-partie.
Selon une caractéristique, la structure de données établit un lien entre l'identifiant unique du signal et les adresses en mémoire des index des différentes parties exploitables du signal.
Cette caractéristique permet d'accéder plus rapidement à l'index de chaque partie du signal à partir de l'identifiant de l'image. L'ajout et la suppression d'une partie sont également facilités par rapport à une solution où les index des parties seraient stockés dans une seule table.
Selon une caractéristique, chaque index propre à une partie exploitable du signal donnée correspond à une structure de données en forme de table comportant l'identification des données présentes dans la partie considérée et leur adresse en mémoire pour les retrouver dans ladite partie mémorisée.
Cette caractéristique permet d'accéder rapidement à la sous-partie recherchée dans la partie, sans avoir à analyser la structure de cette partie.
Selon une caractéristique, le procédé comporte les étapes suivantes effectuées par le ou les appareils de communication dans lesquels sont mémorisées une ou plusieurs parties exploitables du signal: - réception préalable d'au moins certaines données constitutives du signal, - gestion d'emplacements en mémoire adaptée au fait que les données reçues qui ne sont pas contenues dans la ou les parties du signal mémorisées respectivement dans un ou plusieurs emplacements mémoire sont conservées en mémoire dans un emplacement mémoire distinct de ceux-ci, tandis que les données reçues qui sont contenues dans la ou les parties du signal mémorisées ne sont pas conservées en mémoire dans l'emplacement mémoire distinct.
Ainsi, on évite de dupliquer les mêmes données dans deux emplacements mémoire différents, ce qui permet d'optimiser la gestion des ressources mémoire du ou des appareils.
Selon une caractéristique, le procédé comporte une étape de sélection 25 d'au moins un format dans lequel chaque partie exploitable du signal est mémorisée.
L'utilisateur peut ainsi choisir le format le mieux adapté en fonction des outils qu'il veut utiliser pour visualiser ou éditer la partie du signal lorsqu'il s'agit d'un signal d'image.
Selon une caractéristique, le procédé comporte une étape de transfert dans le réseau de sous-parties de données constitutives d'au moins une partie exploitable du signal.
Selon une caractéristique, l'étape d'association de l'identifiant unique du signal à une partie exploitable du signal est effectuée par le ou les appareils de communication recevant tout ou partie des données constituant cette partie.
La partie exploitable du signal peut être reçue du réseau par l'appareil récepteur et marquée localement.
Par ailleurs, la partie exploitable peut être créée sur l'appareil récepteur à partir de sous parties reçues et contenues ou non dans d'autres parties locales.
Selon une caractéristique, l'étape d'association de l'identifiant unique du signal correspond à une étape d'insertion de cet identifiant dans une partie exploitable du signal.
On peut ainsi retrouver facilement l'identifiant de l'image partagée à partir de la partie exploitable du signal.
Cette solution est plus efficace qu'une variante possible consistant à calculer une signature de la partie et d'accéder à une table associant la signature de la partie à l'identifiant du signal.
Selon une caractéristique, l'étape de mémorisation de la structure de données est effectuée par le ou les appareils de communication recevant tout ou partie des données constituant une partie exploitable du signal.
L'appareil de communication pourra ainsi utiliser la structure de 20 données pour rechercher les parties locales même si sa connection avec le réseau est interrompue.
Selon une caractéristique, le procédé comporte une étape d'obtention, par au moins un appareil de communication recevant tout ou partie des données constituant une partie exploitable du signal, d'au moins un descripteur de données représentatif des données présentes dans un ou plusieurs autres appareils de communication du réseau.
Cette caractéristique permet à l'appareil de communication de savoir rapidement à qui adresser une demande lorsqu'il recherche certaines données.
Selon une caractéristique, le procédé comporte une étape, effectuée au niveau d'un appareil de communication dans lequel sont mémorisées une ou plusieurs parties exploitables du signal, de visualisation de tout ou partie de chaque partie exploitable du signal mémorisée.
L'utilisateur peut ainsi manipuler toute partie exploitable mémorisée comme n'importe quel autre fichier classique.
Selon une caractéristique, le procédé comporte une étape, effectuée au niveau d'un appareil de communication dans lequel sont mémorisées une ou plusieurs parties exploitables du signal, de visualisation d'informations propres à chaque partie mémorisée et destinées à informer un utilisateur de l'état de la partie considérée.
L'utilisateur peut ainsi être informé de façon simple de l'état de chacune des parties du signal qui sont mémorisées.
Selon une caractéristique, l'état de la partie de signal exploitable considérée est représentatif de la disponibilité d'autres données constitutives du signal.
L'utilisateur sait ainsi de manière simple s'il peut avoir accès à d'autres parties du signal en dehors de celle qu'il est en train devisualiser.
Selon une caractéristique, l'état de la partie de signal exploitable considérée est représentatif de la possibilité de partager cette partie avec un ou plusieurs autres appareils de communication.
L'utilisateur sait ainsi facilement si l'image qu'il visualise peut être servie à d'autres utilisateurs.
Selon une caractéristique, les informations propres à chaque partie mémorisée sont notamment obtenues à partir de la structure de données mémorisée.
Les informations sont ainsi rapidement disponibles et peuvent donc être affichées très vite, ce qui est indispensable si l'on veut pouvoir les afficher pour plusieurs parties de signal simultanément.
Selon une caractéristique, le procédé comporte une étape, effectuée au niveau d'un appareil de communication dans lequel sont mémorisées une ou plusieurs parties exploitables du signal, de visualisation de commandes permettant à un utilisateur, à partir d'une partie exploitable du signal mémorisée, d'effectuer différentes opérations spécifiques au partage de la partie considérée avec un ou plusieurs autres appareils de communication, à savoir notamment, compléter la partie considérée avec des données supplémentaires et/ou partager la partie considérée avec un ou plusieurs autres appareils de communication.
L'utilisation de ces commandes permet ainsi à l'utilisateur de manipuler une partie de façon très simple et rapide.
Selon une caractéristique, le procédé comporte une étape préalable de génération de l'identifiant unique du signal.
L'identifiant unique du signal est utilisé ensuite à la fois pour retrouver facilement le signal dans le réseau et sur une machine pour retrouver rapidement toutes les parties exploitables de ce signal.
Selon une caractéristique, l'étape de génération de l'identifiant unique du signal est effectuée par l'appareil de communication transférant tout ou partie des données constituant une partie exploitable du signal à un ou plusieurs autres appareils de communication.
Le même identifiant est ainsi utilisé par tous les appareils du réseau,ce qui simplifie les recherches.
Selon une caractéristique, le signal numérique est un signal d'image. L'invention concerne également un appareil de communication comportant un dispositif tel que brièvement exposé ci-dessus.
Selon un autre aspect, l'invention vise aussi: - un moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution des étapes du procédé selon l'invention tel que celui exposé brièvement ci-dessus, et - un moyen de stockage d'informations amovible partiellement ou 25 totalement, lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution des étapes du procédé selon l'invention tel que celui brièvement exposé ci- dessus.
Selon encore un autre aspect, l'invention vise un programme d'ordinateur chargeable dans un appareil programmable, comportant des 30 séquences d'instructions ou portions de code logiciel pour mettre en oeuvre des étapes du procédé selon l'invention tel que brièvement exposé ci-dessus, lorsque ledit programme d'ordinateur est chargé et exécuté sur l'appareil programmable.
Les caractéristiques et avantages relatifs au dispositif selon l'invention, à l'appareil de communication comportant un tel dispositif, aux moyens de stockage d'information et au programme d'ordinateur étant les mêmes que ceux exposés ci-dessus concernant le procédé selon l'invention, ils ne seront pas rappelés ici.
D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description qui va suivre, faite en 10 référence aux dessins annexés, sur lesquels: - la figure 1 représente de manière schématique un réseau de communication de type distribué ; - la figure 2 illustre la représentation d'une image décomposée en sous- bandes de fréquence et partitionnée en quatre tuiles; - la figure 3 illustre de façon schématique la formation d'un train binaire compressé conforme au standard JPEG2000; - la figure 4 illustre le format d'image JPEG; - la figure 5 illustre le partage d'un signal d'image dans un réseau distribué selon l'invention; - la figure 6 illustre la mémorisation de plusieurs vues reçues par un appareil client; - la figure 7 illustre la répartition, dans un signal d'image décomposé en sous-bandes, des différentes données reçues et mémorisées par un appareil client; - la figure 8 représente des structures de données permettant de retrouver des données d'un signal d'image auxquelles souhaite accéder un utilisateur; - la figure 9 représente un algorithme de recherche de vues dans un appareil client; - la figure 10 représente une table de description d'une image partagée entre plusieurs appareils du réseau distribué ; - la figure 11 est un algorithme de traitement des requêtes formulées par un utilisateur en vue d'accéder à une image partagée dans un réseau distribué ; - la figure 12 est un algorithme de traitement d'une requête dans un appareil serveur d'un réseau distribué ; - la figure 13 est un algorithme de recherche d'un paquet de données mis en oeuvre dans un appareil client d'un réseau distribué la figure 14 est une représentation schématique d'une interface utilisateur; - la figure 15 représente de manière schématique un appareil programmable mettant en oeuvre l'invention.
Comme représenté à la figure 1 et désigné par la référence générale notée 10, un réseau de communication de type distribué tel que, par exemple, l'Internet relie entre eux plusieurs appareils de communication 12, 14, 16, 18, ainsi qu'éventuellement un appareil de communication 20 qui joue le rôle d'un serveur central.
Ce dernier est connecté en permanence au réseau 10 et stocke un ensemble de données à partir des échanges qui ont lieu entre les appareils de communication sous la forme de requêtes et de réponses.
II convient de noter que l'on parle dans ce contexte d'échanges terminal à terminal ou d'égal à égal (connu en terminologie anglo-saxonne sous le terme de "peer-to-peer").
L'ensemble de données stockées dans le serveur central 20 contient, par exemple, les informations de présence de chacun des appareils de communication identifiés comme faisant partie du réseau, des informations sur les contenus qui se trouvent stockés localement dans chaque appareil de communication....
Il est également possible que le serveur central dispose de certaines données que l'on peut trouver par ailleurs dans un ou plusieurs des appareils 30 de communication connectés au réseau.
Les appareils de communication reliés au réseau disposent de moyens de communication connus.
Chacun des appareils de communication peut, par exemple, prendre la forme de l'appareil représenté à la figure 15 et dont la description sera faite ultérieurement.
On notera que chaque appareil de communication peut, soit comporter un dispositif selon l'invention, soit correspondre à un dispositif selon l'invention.
L'appareil de communication 12 comporte une mémoire de stockage volatile (mémoire cache) 22, un serveur de fichier 24 et une interface utilisateur 26 permettant à l'utilisateur de formuler des requêtes qui seront transmises via le réseau 10 à d'autres appareils de communication.
Selon l'invention, les appareils de communication 12 à 18 communiquent directement entre eux par l'intermédiaire du réseau d'échange de données 10.
Toutefois, selon une variante de l'invention, le serveur central 20 peut également participer à la communication entre les différents appareils de communication 12 à 18.
Les appareils de communication 14, 16 et 18 comportent également une mémoire de stockage volatile, un serveur de fichiers et une interface utilisateur qui sont respectivement référencés 28, 30 et 32 pour l'appareil 14, 34, 36 et 38 pour l'appareil 16 et 40, 42 et 44 pour l'appareil 18.
On notera que l'invention s'applique à la transmission de données multimédia à travers le réseau de communication distribué 10 représenté sur la figure 1.
Les données multimédia concernées sont, dans l'exemple de réalisation, constitutives d'un signal d'image présentant plusieurs niveaux de résolution (format multirésolution), c'est-à-dire que plusieurs résolutions spatiales d'une même image sont contenues dans un même fichier.
Les données peuvent être compressées ou non sans que cela n'affecte le principe de l'invention.
Plus particulièrement, on utilisera dans la description qui va suivre notamment le format de compression utilisé dans le standard JPEG2000 mais d'autres formats multirésolution peuvent bien entendu être envisagés.
De manière générale, l'invention s'applique également à la transmission de données multimédia au sein du réseau de la figure 1, où les données peuvent être constitutives d'un signal vidéo ou bien encore d'un signal audio.
Comme représenté de manière schématique sur la figure 2, une image I est partitionnée spatialement, suivant le standard JPEG2000, en zones appelées tuiles qui sont chacune traitées de façon indépendante pour l'opération de compression des données.
L'image de la figure 2 est partitionnée en quatre tuiles qui sont chacune décomposées en sous-bandes de fréquence spatio-fréquentielles, mais seule la tuile positionnée en haut et à gauche de l'image illustre cette décomposition.
Une telle décomposition en plusieurs niveaux de résolution (r = 0,1 et 2) résulte, par exemple, d'une transformation en ondelettes discrète et est bien connue de l'homme de l'art.
De façon connue également, les sous-bandes de fréquence de même taille sur la représentation faite à la figure 2 correspondent toutes à un même niveau de résolution pour des orientations spatio-fréquentielles différentes.
L'opération de compression des données de l'image est basée sur la division des sous-bandes de fréquence en unités de données plus petites, appelées unités élémentaires, qui sont des blocs de données (connus en terminologie anglo-saxonne sous le terme de "code-blocks").
Ces blocs de données sont des sous-ensembles rectangulaires de 25 coefficients résultant de la transformation en sous-bandes de fréquence qui sont définis à l'intérieur de chaque sous-bande.
Lorsque l'on forme le train binaire compressé, il est possible de regrouper les blocs de données des sous-bandes de fréquence qui correspondent à une même position ou localisation spatiale (connue en terminologie anglo-saxonne sous le terme de "precinct") à l'intérieur d'un même niveau de résolution.
La figure 3 illustre de façon très schématique la formation d'un train binaire compressé conforme au standard JPEG2000.
Une image initiale I subit tout d'abord une opération facultative de partitionnement spatial en zones d'image ou tuiles 50, puis une opération 52 de transformation spatio-fréquentielle en sous-bandes de fréquence (par exemple, par une transformation en ondelettes discrète).
Suite à l'opération de transformation 52, on obtient des coefficients représentatifs de chaque tuile dans le domaine spatio-fréquentiel et qui sont ensuite, au cours d'une opération 54, partitionnés en blocs de données comme illustré par la figure 2.
Une opération suivante 56 prévoit d'appliquer à l'image un algorithme d'optimisation débit-distorsion pour chaque couche de qualité de chaque bloc de données, ce qui permet d'obtenir la meilleure contribution de chaque bloc de données, en terme de débit, à chaque couche de qualité.
L'opération finale 58 consiste à former le train binaire de l'image conformément à la syntaxe de description prévue dans le standard JPEG2000, comme décrit dans le document "JPEG2000 image coding system ISOIIEC 15 444-1. 2000".
Comme représenté sur la figure 3, le train binaire du signal d'image compressé et conforme au standard JPEG2000 comprend tout d'abord un préambule 60 optionnel contenant des méta-données telles que l'identifiant de l'image, l'auteur de l'image... et un ensemble de données compressées (connu en terminologie anglo-saxonne sous le terme "codestream") comportant des données d'en-tête principal 62 notées MHD (connues en terminologie anglo- saxonne sous le terme de "main header") et au moins une tuile.
Sur la figure 3 deux tuiles ont été représentées.
Chaque tuile se compose de données d'en-tête de tuile 64 et 66 et d'un ensemble de données d'images compressées 68 et 70 (connus en terminologie anglo-saxonne sous le terme de "tile-part bitstream").
Chaque ensemble de données d'images compressées comporte une séquence de paquets de données contenant chacun un en-tête de paquet ("packet header" en terminologie anglo-saxonne) et un corps de paquet ("packet body" en terminologie anglo-saxonne).
Le corps de chaque paquet comporte les blocs de données mentionnés plus haut et qui sont compressés chacun suivant plusieurs niveaux ou couches de qualité incrémentaux: une couche de base et des couches de raffinement.
On notera que l'en-tête de chaque paquet contient, d'une part, la liste des blocs de données contenus dans le paquet considéré et, d'autre part, les paramètres de compression relatifs à chaque bloc de données.
Chaque niveau ou couche de qualité d'un bloc de données est contenu dans un paquet distinct.
Ainsi, un paquet de données contient un ensemble de blocs de données correspondant à une tuile, une composante, un niveau de résolution, un niveau de qualité et une position ou localisation spatiale ("precinct") donnés.
Dans le cadre du mode de réalisation de l'invention présenté ici et appliqué aux signaux d'images conformes au standard JPEG2000, les données minimales transmises entre les appareils de communication de la figure 1 à travers le réseau distribué sont les paquets de données décrits cidessus.
La figure 4 illustre l'utilisation possible d'un format d'image différentdu format JPEG2000 présenté ci-dessus. Dans le format JPEG, une image I peut être découpée spatialement en tuiles. Chaque tuile est compressée de façon indépendante et l'on peut donc y accéder isolément.
La même image peut être compressée sur plusieurs niveaux de résolution (résolutions basse, moyenne et haute) et former ainsi plusieurs images JPEG indépendantes. L'unité de base que l'on peut décoder est dans ce cas un paquet de données au format JPEG correspondant à un niveau de résolution, une tuile et une composante.
Pour stocker les résolutions différentes, il est possible d'utiliser plusieurs fichiers JPEG ou un format de fichier tel que "FlashPix" (format propriétaire de la société Kodak) qui stocke plusieurs résolutions dans le même fichier. Bien que ces solutions soient moins efficaces qu'avec le format JPEG2000 (la place utilisée est environ 33% plus grande), elles sont néanmoins intéressantes en raison de la diffusion plus large du format JPEG. En effet, avec ce dernier format, les vues utilisables pour stocker des données en complément du fichier cache (mémoire cache) peuvent être au format JPEG, le fichier cache lui- même contenant un ensemble de paquets au format JPEG.
La figure 5 qui suit illustre la transmission de données constitutives d'un signal d'image à plusieurs niveaux de résolution entre plusieurs appareils de communication dont un appareil dit source, noté S, au niveau duquel est stocké un signal d'image I et plusieurs appareils de communication appelés appareils clients et notés Cl, C2, C3 et C4.
Ces appareils de communication possèdent la structure de ceux représentés sur les figures 1 et 15 et comportent chacun un dispositif selon l'invention.
Cette figure illustre ainsi les échanges de données dans le cas de partage d'un signal d'image multirésolution dans un réseau distribué.
On notera que l'image I est celle qui était décrite en référence à la figure 2 et qui possède donc trois niveaux de résolution.
Dans l'exemple de réalisation décrit on considère que, lorsque tous les appareils Cl, C2, C3 et C4 sont connectés à l'appareil source S à travers le réseau distribué, ils reçoivent tous de ce dernier une partie exploitable du signal d'image I qui correspond à la sous-bande de fréquence basse de ce signal, constituant ainsi le minimum d'informations partagé par tous les appareils de communication.
Une telle partie d'un signal est un exemple d'une partie de signal qualifiée de partie exploitable du signal, ce qui signifie que les données qui constituent cette partie ont une signification propre qui leur permet d'être exploitées par un utilisateur. Ainsi, pour un signal d'image, une partie exploitable de ce signal est une partie du signal que l'utilisateur peut visualiser et, pour un signal audio, il s'agit d'une partie du signal que l'utilisateur peut écouter.
On notera qu'une partie exploitable du signal est une partie du signal qui est sauvegardée dans un format lisible par une application.
On appelle aussi les appareils Cl, C2, C3 et C4 des appareils destinataires.
La partie du signal de très basse résolution évoquée ci-dessus est appelée "imagette" (connue en terminologie anglo-saxonne sous le terme de "thumbnail").
Chacun des appareils de communication destinataire ou client Cl, C2, C3 et C4 peut visualiser la partie du signal d'image ainsi reçue et ensuite prendre une décision quant à savoir si des données supplémentaires (autres parties du signal d'image) sont nécessaires à l'appareil concerné.
Plus particulièrement, chaque appareil a la possibilité d'augmenter la résolution de la partie du signal d'image déjà reçue, par exemple, en requérant les sous-bandes de haute fréquence de chaque niveau de résolution et/ou en demandant davantage de détails sur la partie du signal d'image reçue.
Par ailleurs, l'utilisateur peut extraire une zone spatiale du signal d'image à une résolution et/ou à un niveau de qualité donnés.
II convient de noter que le signal d'image I n'a pas nécessairement un format multirésolution et la partie du signal reçue par les appareils Cl à C4 peut, par exemple, correspondre à une zone spatiale de l'image.
Un ou plusieurs appareils peuvent ainsi ultérieurement souhaiter 20 recevoir une autre zone spatiale de l'image ou bien un complément de zone par rapport à la première zone reçue.
Sur la figure 5, on a représenté, par des zones hachurées au niveau de chacun des appareils destinataires ou clients Cl, C2, C3 et C4, les données du signal d'image I qui sont présentes localement dans l'appareil concerné.
Les données constitutives de parties cohérentes du signal d'image et qui sont présentes localement dans les appareils Cl à C4 peuvent être stockées dans un ou plusieurs fichiers locaux.
Ainsi, la représentation de la figure 5 suppose que chacun des appareils destinataires ou clients a reçu l'imagette précitée de l'appareil source et a ensuite pris une décision sur la base de cette imagette pour émettre une requête destinée à l'appareil source S en vue d'obtenir des données supplémentaires.
Toutefois, dans l'exemple considéré, le client destinataire C4 n'a pas émis de requête pour obtenir des données supplémentaires lorsque le partage du signal d'image a été effectué par l'appareil source S et il a juste reçu l'imagette.
Par ailleurs, dans le cas où l'appareil C4 n'était pas connecté au moment où l'appareil source a transmis l'imagette à tous les appareils destinataires qui étaient connectés, alors l'appareil C4 peut, ultérieurement, récupérer cette imagette auprès de l'appareil 20 de la figure 1 connecté en permanence et qui fait office de serveur central.
Dans l'exemple illustré, l'appareil destinataire Cl a reçu deux niveaux de résolution complets sur trois des niveaux de résolution du signal d'image, tandis que l'appareil destinataire C2 a reçu uniquement le premier niveau de résolution.
L'appareil destinataire C3, quant à lui, a reçu le signal d'image en entier.
Lorsque l'appareil C4 est connecté, alors l'appareil source S est déconnecté et l'appareil C4 doit donc s'adresser aux appareils destinataires Cl, C2 ou C3 pour récupérer les données supplémentaires qui lui manquent par rapport aux données constitutives de la partie de signal qu'il a déjà reçue, afin de compléter la visualisation de l'image partagée.
Pour ce faire, l'appareil destinataire C4 a besoin d'informations sur le signal d'image I partagé ainsi que sur les parties de signal présentes localement dans les appareils de communication destinataires Cl, C2 et C3 qui constituent des serveurs potentiels.
II est ainsi prévu de faire appel à un descripteur de l'image partagée et à un descripteur de données locales qui décrit au niveau de chaque appareil de communication Cl, C2, C3 les données qui sont présentes localement dans cet appareil.
Par ailleurs, le descripteur local peut également fournir la position ou l'adresse, dans une mémoire locale de l'appareil concerné, des données qui sont présentes localement dans cet appareil. Le descripteur local correspond à la table décrite en référence à la figure 8.
La construction du descripteur d'image partagée à partir du descripteur local sera décrite en référence à la figure 10. Le descripteur d'image partagée décrit l'ensemble des données présentes localement sur l'appareil client.
On notera que, selon une approche particulière, l'invention prévoit de disposer dans l'appareil source S d'un descripteur de signal d'image partagée qui est représentatif de la présence locale dans cet appareil de toutes les données constitutives du signal d'image.
Le descripteur de signal d'image partagée dans l'appareil source S est transmis aux différents appareils de communication Cl, C2, C3 et C4 lors de la transmission de l'imagette ou bien uniquement aux appareils Cl, C2 et C3 lorsque ceux-ci requièrent des données supplémentaires en complément de l'imagette préalablement reçue.
Chaque appareil destinataire recevant le descripteur de signal d'image partagée de l'appareil source crée un autre descripteur de données, appelé descripteur local, qu'il met à jour de manière à ce que ce dernier soit représentatif de la présence locale de tout ou partie des données constitutives du signal qui ont été reçues par cet appareil.
La table 930 correspondant au fichier index du cache fait office de descripteur local.
La figure 6 illustre de façon schématique, à l'étape notée 1, la sauvegarde des données reçues par un appareil client et provenant d'un appareil serveur. Au fur et mesure de la phase interactive de consultation décrite en référence à la figure 5, l'utilisateur peut à tout moment mémoriser les données du signal d'image téléchargées.
Comme représenté sur la figure 6, toutes les données reçues sont d'abord mémorisées à un emplacement mémoire, par exemple, d'un disque dur de l'appareil dans un fichier appelé fichier cache.
L'utilisateur peut ensuite sauvegarder les données dans un format connu comme, par exemple, JPEG ou JPEG2000 à un ou plusieurs emplacements mémoire distincts de celui du fichier cache. L'image sauvegardée est une partie exploitable (qualifiée également de partie cohérente) de l'image d'origine correspondant à un ensemble de tuiles et à une résolution pour le format JPEG, ou à une position spatiale, une résolution et une qualité pour le format JPEG2000.
Il convient de noter que l'utilisateur peut sélectionner un format dans lequel une partie d'image va être mémorisée.
La partie exploitable de signal qui a été mémorisée est appelée une "vue" sur l'image d'origine. Un cas particulier est le cas où la vue est complète dans la mesure où elle contient l'ensemble des données de l'image d'origine.
Comme représenté sur la figure 6, à l'étape 2 l'utilisateur sauvegarde une basse résolution (Res 0) de l'image dans un premier fichier au format JPEG2000 et qui est appelée vuel. Il sauvegarde ensuite, à l'étape 3, une zone spatiale de l'image avec la résolution maximale dans un deuxième fichier JPEG2000 (vue2). A l'étape 4, il crée une troisième vue dans un fichier au format JPEG (vue3).
Chaque vue ainsi formée est sauvegardée à un emplacement en mémoire choisi par l'utilisateur pour pouvoir être utilisée par n'importe quel logiciel dont l'utilisateur dispose en fonction du format choisi pour la vue.
On notera que les données précédemment stockées dans le fichier cache et qui sont contenues dans au moins l'une des vues créées sont supprimées du fichier cache afin de diminuer la taille de ce dernier et donc d'optimiser la gestion des ressources mémoire de l'appareil.
Les données peuvent être supprimées dans la mesure où elles sont stockées dans le même format dans le fichier cache et dans une vue.
Toutefois, si les données sont stockées à deux emplacements mémoire distincts et sous deux formats différents, alors il est malgré tout possible de supprimer les données du fichier cache dans la mesure où l'on peut passer d'un format à l'autre sans perte d'informations.
Chaque image partagée dans le réseau distribué est identifiée de manière unique par un identifiant. Cet identifiant peut être obtenu, par exemple, en déterminant une signature sur l'image initiale (par exemple, une signature de type MD5) ou bien en générant une valeur aléatoire ayant une forte probabilité d'être unique. La génération d'une telle valeur aléatoire est effectuée selon des techniques classiques connues de l'homme du métier, par exemple, en utilisant la fonction "CoCreateGuid" sous Windows.
Selon l'invention, à chaque vue ou partie exploitable du signal est associé l'identifiant ID de l'image d'origine I, même si la vue ne contient qu'une partie de l'image I. Cet identifiant peut être inséré dans un en-tête du format d'image choisi par l'utilisateur ou dans un tatouage de l'image ("watermark" en terminologie anglosaxonne) qui peut être obtenu, par exemple, par une méthode de tatouage robuste connue de l'homme du métier.
Cet identifiant permet à toute application connaissant le système d'échange d'image d'établir un lien entre la vue mémorisée et l'image partagée et donc de fournir des fonctions spécifiques liées à l'échange d'image. Plusieurs fonctions seront décrites ultérieurement en référence à la figure 14. L'une des fonctions principales est de permettre à l'utilisateur, en partant de la vue mémorisée, de revenir à l'image d'origine et donc de pouvoir visualiser également les zones spatiales de l'image et les résolutions qui ne se trouvent pas dans la vue mais dans la mémoire cache ou dans d'autres vues. L'utilisateur peut même accéder aux données disponibles dans d'autres appareils du réseau distribué.
On peut envisager que la génération de l'identifiant soit effectuée dans un appareil serveur, tandis que l'association est effectuée dans l'appareil client.
On peut également envisager que ces étapes de génération et d'association soient effectuées dans un appareil serveur qui transmet ces parties de signal à un appareil client.
Cependant, dans le cas où certaines vues seraient dans le même format que le format des paquets échangés, il est possible de diminuer la taille du fichier cache en supprimant les paquets qui peuvent être retrouvés dans les vues comme décrit ci-dessous en référence à la figure 7.
La figure 7 illustre la répartition, dans le signal d'image décomposé en sous-bandes, des données d'image reçues et mémorisées, suivant l'exemple de la figure 6 et en utilisant le format JPEG2000 comme format d'échange d'image.
La vue 1 correspond à la basse résolution de l'image dont l'ensemble des blocs de données LL (zone 810) est sauvegardé dans le fichier correspondant. Si l'un de ces blocs doit être fourni à un client du réseau, il peut être retrouvé dans le fichier de la vue 1 puisqu'il est au format JPEG2000. II est cependant nécessaire de disposer d'une structure de données telle que celle représentée à la figure 8 car les numérotations des blocs ne sont pas forcément les mêmes dans la vue 1 et dans l'image d'origine.
La vue 2 correspond à une zone spatiale de l'image à la résolution maximale et les blocs de données correspondant à cette zone sont répartis dans toutes les résolutions de l'image (820, 821, 822).
Dans l'exemple fourni, l'utilisateur a visualisé l'ensemble de la résolution 1 (zone 801) et une partie de la résolution 2 (zone 802).
Seuls les blocs qui ne sont pas déjà sauvegardés dans un fichier contenant une vue ont besoin d'être sauvegardés dans le fichier cache.
Si une nouvelle vue est créée par la suite, on peut alors supprimer du fichier cache les blocs sauvegardés dans cette vue.
Dans un cas extrême où une vue contient l'ensemble des données de l'image, alors le fichier cache peut être supprimé.
Dans l'exemple de la figure 6, une troisième vue au format JPEG est sauvegardée. Cependant, comme le format d'échange utilisé dans l'exemple est JPEG2000, les données de la vue 3 ne sont pas utilisables pour recréer des informations du fichier cache et aucun bloc de données ne peut donc être supprimé.
De même, on peut sauvegarder une vue sur un support amovible tel qu'un graveur de CD ou une disquette, mais il convient dans ce cas de ne pas supprimer les données du fichier cache.
Dans le cas où l'on utiliserait le format JPEG comme format d'échange, seules les vues au format JPEG pourraient être utilisées pour sauvegarder des données du fichier cache. Le principe est cependant le même que pour le format JPEG2000: les données correspondant à une résolution ou à une tuile peuvent être supprimées du fichier cache si elles sont présentes dans une vue.
On peut également, si on le souhaite, supprimer les informations correspondant à une résolution si toute la résolution supérieure est déjà présente: la basse résolution peut en effet être recalculée à partir de la plus haute résolution.
Comme les vues contiennent des données qui sont utilisées pour reconstruire l'image complète et que les fichiers contenant ces vues sont accessibles à l'utilisateur, il est nécessaire de les protéger ou au moins de vérifier leur intégrité. En effet, l'utilisateur peut, volontairement ou non, modifier le contenu de l'image et rendre invalides toutes les données d'une partie cohérente du signal d'image qui y sont contenues.
Il est donc nécessaire d'essayer de protéger ou d'avertir l'utilisateur que le fichier ne doit pas être modifié.
Cela peut se faire en plaçant le fichier en mode "lecture seulement" à l'aide des fonctions du système d'exploitation du système informatique.
Un utilisateur mal intentionné peut cependant contourner ces protections.
Il est ainsi proposé d'ajouter une signature permettant de vérifier l'intégrité des données contenues dans la vue.
Cela peut se faire par des techniques connues de l'homme du métier telles que celles consistant à obtenir une signature MD5 sur l'ensemble des données contenues dans l'image.
Cette signature peut avantageusement n'être obtenue que sur la partie données de l'image et l'utilisateur peut ainsi modifier les en-têtes de l'image (pour ajouter, par exemple, des méta-données comme des mots clés) sans rendre le fichier inutilisable.
Une alternative possible est d'appliquer un tatouage fragile sur les données de l'image. L'avantage de cette alternative est de pouvoir détecter une éventuelle modification des données après que le marquage fragile ait été inséré, et ce, sans avoir à stocker une information supplémentaire telle que la signature. La vérification du marquage fragile permet de détecter, voire de localiser, les modifications qui sont répercutées sur les coefficients représentatifs de l'image, que le mode de stockage soit au format JPEG ou JPEG2000. En particulier, on pourrait utiliser les méthodes proposées dans la demande de brevet FR 99 13836 au nom de Canon Kabushiki Kaisha, ayant pour titre "Procédé d'insertion d'une marque secrète et d'authentification d'un signal numérique", pour le format JPEG et dans la demande FR 00 13989 au même nom, ayant pour titre "Insertion d'information supplémentaire dans des données numériques", pour le format JPEG2000.
Un autre cas particulier est celui de l'image d'origine qui peut être considérée comme une vue particulière et marquée avec l'identificateur unique de l'image comme une vue normale. Cela permet d'éviter de régénérer un autre identificateur si l'image est repartagée ultérieurement.
Par ailleurs, comme pour une vue, on conserve un lien entre l'image d'origine et les données partagées (pour afficher un état, par exemple), cela permet, lorsque des données doivent être retrouvées, de les récupérer en utilisant directement l'image d'origine.
Comme mentionné ci-dessus, l'ensemble des données constituant un signal d'image peut se trouver réparti entre plusieurs fichiers contenant chacun une ou plusieurs parties exploitables du signal: le fichier cache et les fichiers de vues.
La figure 8 illustre des structures de données mémorisées dans un appareil client et permettant de retrouver facilement et rapidement tout ou partie des données constituant le signal d'image d'origine.
Parmi ces structures, la table 910 représente la table de localisation des vues qui permet de retrouver rapidement tous les fichiers associés à une image.
Pour chaque fichier mémorisé, on dispose des informations suivantes: É l'identifiant de l'image référencé 912 qui est l'identifiant unique de l'image d'origine; la table est indexée suivant cet identifiant pour permettre un accès rapide à toutes les vues d'une image donnée; cette structure de données établit ainsi un lien entre chaque partie exploitable du signal et l'identifiant unique; É le chemin du fichier référencé 914 dans le système de fichier local; le fichier cache se trouve dans un emplacement mémoire géré par l'application, mais les vues peuvent se trouver dans n'importe quel répertoire suivant les choix de l'utilisateur; plus particulièrement, la structure de données établit un lien entre l'identifiant unique et les adresses des emplacements en mémoire où sont mémorisées les parties exploitables de signal; É le type de fichier référencé 916 qui permet de savoir si le fichier contient des données directement utilisables ou non; dans l'exemple fourni, on indique le format de codage de l'image pour chaque vue (JPEG2000 ou JPEG) et un type particulier pour le fichier cache; É l'indication de taille référencée 918 qui peut être utile pour retrouver plus rapidement des informations recherchées; il peut, par exemple, s'agir de la résolution maximale stockée dans le fichier ou une taille de fichier; É la date de modification référencée 920 qui permet de vérifier rapidement qu'un fichier n'a pas été modifié et donc contient des données correctes; É le chemin du fichier index référencé 922 tel que celui dénommé chemin index im1 et qui est associé à un fichier contenant des informations exploitables (vue dans un format compatible ou fichier cache) et qui est dénommé C:Imes imageslviewl.jp2; le fichier index est représentatif des données présentes dans la partie du signal contenue dans le fichier précité et décrit, pour cette partie, des sous-parties de données qui sont ici des paquets de données.
Une structure de données telle qu'une table 930 constitue le fichier index précité et une carte descriptive des données locales (descripteur de données) d'une vue ou du fichier cache.
A titre de variante, la table 910 peut aussi contenir la signature du fichier référencé 914. Cette signature peut ainsi être utilisée dans l'étape S4 de l'algorithme de la figure 9 pour retrouver l'identifiant de l'image La structure de données 910 établit un lien entre chaque partie exploitable du signal, l'identifiant unique et un fichier index associé 930 et, notamment, son adresse en mémoire.
Comme illustré par la figure 8, il est possible de représenter un 25 descripteur de données locales dans lequel les données sont organisées linéairement selon un ordre prédéterminé.
II convient de noter que cet ordre prédéterminé peut correspondre à l'ordre initial des paquets dans le train binaire du signal d'image initial conforme au standard JPEG2000, ou bien les paquets peuvent être réorganisés en fonction de critères d'efficacité d'accès aux données.
Ainsi, par exemple, lorsque l'image a été découpée en plusieurs zones spatiales ou tuiles, il est utile de regrouper ensemble les paquets P1, P2, P3...Pn de données concernant chaque résolution de chaque tuile et, par exemple, d'y mettre à la suite l'un de l'autre tous les paquets de données correspondant à la plus basse résolution de chaque tuile.
Ceci permet de reconstituer facilement la version basse résolution 5 d'une image et donc de répondre facilement à une requête en vue de l'obtention de cette partie de signal.
Dans l'exemple illustré à la figure 8, les paquets sont ordonnés dans l'ordre de progression tuile-composante-résolution-couche de qualitéposition spatiale dans un premier champ 932.
Le descripteur de données locales comporte un deuxième champ 934 qui indique si le paquet considéré a été complètement reçu ou non.
Dans un champ suivant noté 936 on indique la longueur du paquet complet.
Il convient de noter que cette information de longueur peut être reçue au moment de l'initialisation du descripteur de données, ou au moment où la première requête concernant un paquet de données est transmise, ou bien encore cette information peut accompagner le paquet auquel elle se rapporte.
Le descripteur de données locales comporte un dernier champ 938 qui fournit l'adresse en mémoire dans le fichier 940 (C:1mes images\viewl.jp2) associé au fichier index 930 du paquet (exemple: P1) identifié dans le premier champ 932.
Ainsi, chaque fichier index identifie les sous-parties de données présentes dans la partie de signal considérée et leur adresse en mémoire pour 25 les retrouver.
II convient de noter que pendant une session de communication les paquets de données sont stockés de façon séquentielle dans une mémoire temporaire dans leur ordre d'arrivée: P1, P2, P3....
Cependant, en fin de session de communication, il est possible 30 d'agencer les paquets dans un ordre de stockage prédéterminé différent dans le fichier 940.
Les tables précitées 910 et 930 pourraient être organisées de manière différente, par exemple, en indexant d'abord par paquet puis, pour chaque paquet, en indiquant les fichiers qui contiennent ce paquet. Une telle structure permettrait un accès plus rapide à un paquet recherché. Cependant, la structure illustrée à la figure 8 présente l'avantage de pouvoir réaliser facilement un changement de nom, ainsi que l'ajout ou la suppression de vues.
Les tables présentées ici peuvent prendre la forme de tables dans une base de données. Elles peuvent également être sauvegardées sous la forme de plusieurs fichiers que l'on peut retrouver à partir des identificateurs d'image (par exemple, le nom du fichier peut être basé sur l'identificateur de l'image).
La figure 9 représente un algorithme comportant différentes instructions ou portions de code et qui peut être utilisé pour mettre à jour la table de localisation 910 de la figure 8. Un programme informatique noté "Prog 1", basé sur cet algorithme et stocké dans l'appareil de la figure 15, peut être exécuté régulièrement, par exemple, chaque jour, ou lorsque l'application de partage démarre, ou bien lorsque des fichiers de vues ont disparu.
Les fichiers contenant des parties exploitables de signal (vues) peuvent être recherchés en explorant à l'étape SI de l'algorithme un ensemble de répertoires que l'utilisateur a indiqués comme susceptibles de contenir des fichiers partagés.
Lorsque tous les répertoires en mémoire ont été explorés, alors il est mis fin à l'algorithme (étape S2).
L'algorithme prévoit pour chaque répertoire susceptible de contenir des fichiers partagés d'explorer les fichiers d'image de type connu à l'étape S3.
Pour chaque fichier d'image de type connu, il est prévu, au cours de l'étape suivante S4, de vérifier si le fichier d'image concerné contient l'identificateur unique d'une image partagée. L'identificateur peut être contenu dans l'image.
A titre de variante, il peut être déduit du contenu de l'image en utilisant la table 910: la signature de l'image est calculée et l'on recherche dans la table 910 la ligne avec la signature. Cette ligne permet d'obtenir l'identifiant de l'image.
Dans la négative, l'étape S4 est suivie de l'étape S3 décrite précédemment afin de traiter un autre fichier.
Dans l'affirmative, le fichier d'image concerné contenant l'identificateur d'une image partagée, alors l'étape suivante S5 prévoit de vérifier si le fichier considéré est déjà connu et donc répertorié dans la table de localisation 910 de la figure 8 (nom de fichier 914).
Dans le cas où le fichier associé à un identificateur unique d'image est répertorié dans la table 910 de la figure 8, alors l'étape S5 est suivie de l'étape S3 qui prévoit de traiter un autre fichier.
Si le fichier considéré n'est pas répertorié dans la table 910, alors on prévoit au cours de l'étape suivante S6 de vérifier la signature de ce dernier.
Au cours de cette étape, on détermine si le fichier considéré possède un contenu identique à celui d'une vue déjà répertoriée localement au travers de la signature. En effet, le fichier peut avoir été déplacé et renommé sans modification
de son contenu.
Dans l'hypothèse où la signature est incorrecte, le fichier ne peut plus être utilisé, alors il est nécessaire d'enlever les informations contenues dans ce fichier, telles que l'identificateur d'image partagée et la signature (étape S7).
L'étape S7 est ensuite suivie de l'étape S3 déjà décrite ci-dessus.
Lorsque la signature du fichier s'avère correcte, il est alors nécessaire de répertorier ce fichier dans la table de localisation 910 de la figure 8 afin d'établir un lien entre la partie exploitable du signal concernée et l'identification unique de ce signal, de même qu'avec le fichier index 922 de la table 910.
Le fichier d'image concerné peut être un nouveau fichier par rapport à des fichiers d'image partagée précédemment reçus pour la même image et déjà répertoriés dans une table de localisation 910 comme celle de la figure 8.
Toutefois, dans un cas plus général le fichier d'image concerné ne peut être relié à une entrée de la table de localisation via l'identificateur unique, par exemple, dans le cas où l'utilisateur a reçu directement un fichier sans utiliser l'application de partage (en cas de réception par email par exemple).
Au cours de l'étape S8, il est prévu d'analyser le contenu de ce fichier d'image afin de déterminer notamment le type de fichier et sa taille.
Ces informations peuvent être complétées éventuellement par d'autres informations qui sont sauvegardées dans les en-têtes du fichier image et qui précisent les caractéristiques de la partie du signal (vue) concernée par rapport au signal d'image initial (par exemple, résolution et position spatiale).
Lors de cette étape, le fichier index associé 922 est également créé à partir de l'analyse du contenu du fichier image et notamment des informations trouvées sur les paquets de données reçus, telles que celles fournies par les champs référencés 932, 934, 936 et 938. Le fichier index associé Chemin index iml 930 peut ainsi être créé sous la forme d'une table 930.
L'étape S9 est ensuite exécutée afin de créer une ligne dans la table de localisation 910 précédemment créée.
Lorsque l'étape S9 est achevée, alors l'étape suivante S3 est de nouveau exécutée pour traiter un nouveau fichier.
Pour pouvoir échanger les données d'une image dans un réseau distribué, il a été mentionné en référence à la figure 5 qu'il est nécessaire d'échanger des descripteurs de données indiquant pour chaque appareil de communication du réseau les données qui sont présentes localement.
Le descripteur relatif à un appareil contient la liste des paquets disponibles localement et cette liste peut être simplement construite à partir des fichiers index 922 de chaque vue et du fichier cache pour une image donnée.
Dans l'exemple illustré à la figure 10, la liste des paquets présents localement dans un appareil est établie en rassemblant des listes de paquets complets présents dans les fichiers index 922 des vues 1 et 2 (les deux vues dans un format compatible telles que les vues 1 et 2 de la figure 6) et dans le fichier index du cache. Cette liste peut alors être transférée sur le réseau à tout appareil client demandant des informations sur l'image.
Sur la figure 10, on considère que l'appareil (serveur local) est le client C4 qui reçoit de cette manière les descripteurs décrivant les données disponibles pour l'image recherchée sur les serveurs disponibles dans le réseau, à savoir les appareils Cl, C2, C3. Ces données sont alors stockées dans une mémoire temporaire, tant que des opérations sont effectuées sur l'image concernée.
La table 950 représentée à la figure 10 répertorie ainsi, pour l'appareil C4, les descripteurs de données relatifs à chaque appareil Cl, C2, C3, de même que le propre descripteur de l'appareil C4.
La figure 11 représente un algorithme comportant différentes instructions ou portions de code et qui décrit les étapes effectuées lorsqu'un utilisateur accède à une image partagée dans le réseau distribué.
Un programme informatique noté "Prog 2" et basé sur cet algorithme est stocké dans l'appareil de la figure 15.
L'algorithme comporte une première étape S20 qui consiste à retrouver l'identifiant de l'image dans le réseau. Cet identifiant peut être retrouvé, par exemple, dans une vue de l'image, dans un email (ou une autre forme de message) envoyé par un autre utilisateur (qui peut être celui qui a introduit l'image dans le réseau), ou sur une page au format html et qui est disponible sur Internet.
A partir de cet identifiant, l'utilisateur va pouvoir établir plusieurs types de requêtes par l'intermédiaire de commandes disponibles à travers une interface graphique.
L'étape suivante S21 consiste donc à attendre et décoder les requêtes de l'utilisateur.
Une des requêtes qui peut être formulée consiste à visualiser une partie exploitable de l'image à une certaine résolution: il s'agit d'une requête pour accéder à une vue (étape S22). La manière normale d'accéder à l'image est de commencer par accéder à une imagette, puis ensuite d'augmenter progressivement la résolution sur tout ou partie de l'image. Connaissant les caractéristiques de la vue demandée (partie exploitable du signal), on peut alors déterminer les paquets de données nécessaires à la visualisation de cette vue.
En utilisant la table 950 de la figure 10, on peut, à l'étape S23, déterminer les paquets qui sont disponibles localement.
A l'étape suivante S24, ces paquets peuvent alors être retrouvés dans la mémoire cache ou les vues en utilisant la structure de donnée de la figure 8 et l'algorithme de la figure 13 qui sera décrit ultérieurement.
Cependant, dans le cas où l'utilisateur a modifié ou détruit certaines vues, l'algorithme de la figure 11 doit relancer une recherche dans le réseau distribué, de la même manière que si le paquet n'avait jamais été téléchargé dans l'appareil client concerné et l'étape S24 est alors suivie de l'étape S25.
La recherche dans le réseau qui a également lieu lorsque le paquet n'est pas disponible localement (étape S23) est effectuée en utilisant la table de la figure 10 pour trouver un appareil serveur qui dispose du paquet recherché.
Si aucun appareil serveur enregistré dans la table ne dispose du paquet, il est possible d'étendre la recherche, c'est-à-dire de rechercher d'autres appareils serveurs dans le réseau qui disposent de l'image (cela se fait en utilisant des techniques connues comme, par exemple, une recherche de type "Gnutella").
Ensuite, chaque nouvel appareil serveur trouvé est interrogé afin de récupérer son descripteur de données pour l'image recherchée.
L'appareil serveur et son descripteur sont alors ajoutés à la table de la figure 10.
Les appareils déjà enregistrés peuvent également être à nouveau 15 interrogés afin de déterminer si un descripteur n'a pas été enrichi par l'ajout d'un paquet depuis la dernière mise à jour.
Si aucun appareil présent dans le réseau ne dispose du paquet recherché, alors la requête ne peut pas être complétée et l'utilisateur est prévenu de l'échec (étape S26).
Si un appareil serveur possède dans son descripteur le paquet recherché, alors une requête lui est transmise pour demander le transfert du paquet.
L'algorithme de la figure 12 qui sera décrit ultérieurement est utilisé par l'appareil serveur distant pour traiter la requête concernant le paquet demandé.
La même procédure est appliquée pour tous les paquets recherchés à l'aide du test effectué à l'étape S27.
Dans le cas où tous les paquets nécessaires à la visualisation de la partie du signal considérée (vue) sont retrouvés localement ou en faisant appel à un appareil serveur distant du réseau qui transfère avec succès le ou les paquets manquants, alors la vue peut être reconstruite et affichée (étape S28).
* On notera que dans l'algorithme de la figure 11 les paquets reçus sont mémorisés mais pas dans le fichier cache contrairement à ce qui est illustré sur la figure 6.
Lorsque l'utilisateur a affiché une vue sur une image partagée, il peut à nouveau formuler différentes requêtes (étape S21). L'utilisateur peut vouloir afficher une autre vue et sa requête sera alors traitée comme décrit précédemment.
Toutefois, il peut également demander à sauvegarder la vue qu'il vient de visualiser dans un fichier en sélectionnant un emplacement en mémoire pour y mémoriser la partie cohérente du signal qui est concernée (étape S29).
Lorsque l'utilisateur a choisi le nom et l'emplacement en mémoire du fichier, la vue est sauvegardée au format demandé (étape S30). L'identifiant de l'image est inséré dans la vue soit sous la forme d'un en-tête, soit sous la forme d'un tatouage. Il peut également être associé dans une table à la signature de l'image. L'identifiant inséré est l'identifiant de l'image dans le réseau. De même, la signature de la vue est calculée et est introduite dans le fichier de la vue à l'étape S30.
Lorsque la vue est dans un format utilisable pour retrouver des paquets de données, un fichier index associé 930 est également créé et la table de localisation 910, ainsi que la liste des paquets présents localement (descripteur de la table 950 de la figure 10) sont mis à jour (étape S31).
A l'étape suivante S32, les paquets qui ont été mémorisés dans la vue peuvent être supprimés du fichier cache s'ils y étaient présents, ce qui évite une duplication inutile de l'information.
L'utilisateur peut également requérir, à l'étape S33, la fin de la visualisation de l'image, soit pour visualiser une autre image, soit pour mettre fin à l'application en cours.
Dans ce cas, il faut sauvegarder les paquets reçus si ceux-ci n'ont pas déjà été mémorisés dans les fichiers de vues et ces paquets sont alors placés dans le fichier cache de l'image à l'étape S34.
Le fichier index 930 du fichier cache est également mis à jour et la table de localisation 910, ainsi que la liste des paquets présents localement (descripteur de la table 950 de la figure 10) sont mis à jour (étape S35).
Il est ensuite mis fin à l'algorithme à l'étape S36.
Lorsqu'un appareil serveur distant reçoit une requête concernant un paquet P d'une image identifiée par son identifiant unique ID, l'algorithme de la figure 12 est mis en oeuvre dans cet appareil pour retrouver le paquet.
L'algorithme comporte une première étape S40 de réception de la requête.
Au cours de l'étape suivante S41, un test est effectué afin de déterminer si le paquet est disponible localement. Cette recherche est effectuée avec l'algorithme de la figure 13 qui va être décrit ci-après.
Si le paquet est disponible localement, alors il est servi, c'est-à-dire qu'il est transféré à l'appareil client dont émane la requête, à l'étape S42.
Si le paquet n'est pas disponible, contrairement à l'algorithme de la figure 11, aucune autre recherche n'est effectuée et un message d'erreur est transféré à l'appareil client à l'origine de la requête (étape S43).
La figure 13 représente un algorithme de recherche d'un paquet utilisant la structure de données décrite en référence à la figure 8.
Un programme informatique "Prog 3" basé sur cet algorithme est stocké dans l'appareil de la figure 15.
On fait appel à cet algorithme dans l'algorithme de la figure 11, pour accéder à une image, et dans celui de la figure 12, pour traiter une requête concernant un paquet.
Un paquet est recherché avec l'identifiant unique de l'image ID et les caractéristiques de ce paquet (par exemple: tuile, composante, résolution, couche de qualité, position spatiale dans le cas du format JPEG2000).
L'algorithme comporte une première étape S50 qui consiste à chercher dans la table de localisation 910 (figure 8) tous les fichiers associés à l'image ID.
Parmi ces fichiers images seuls sont retenus (étape S51) ceux qui ont un type 916 permettant de récupérer des paquets compatibles, à savoir, dans l'exemple considéré, les fichiers JPEG2000 et le cache.
Ces fichiers sont ensuite triés par taille décroissante (étape S52) afin d'explorer d'abord ceux qui contiennent le plus d'informations.
L'étape suivante S53 prend en compte le premier fichier de plus grande taille.
Pour ce fichier, l'algorithme prend ensuite en compte (étape S54) la table d'index 930 du fichier index associé 922 et effectue une recherche (étape S55) afin de déterminer si le paquet recherché est présent.
Si le paquet n'est pas trouvé, alors on passe à l'étape S53 pour effectuer une recherche dans le fichier suivant.
Si le paquet est présent il faut alors vérifier que le fichier n'a pas été modifié, c'est-à-dire détruit, déplacé ou si son contenu n'a pas été modifié.
On recherche pour cela (étape S56) le fichier de données contenant le paquet recherché.
Si le fichier est trouvé à l'adresse mémoire qu'il devrait occuper, alors l'étape suivante S57 prévoit de vérifier s'il a été modifié depuis la dernière vérification en examinant les éventuelles dates de modification 920 du fichier (figure 8).
Si le fichier n'a pas été modifié, alors le paquet est récupéré à l'étape S58.
Si le fichier a été modifié, il est prévu (étape S59) de vérifier la validité de la signature.
En cas de validité de la signature, alors la date de modification relevée à l'étape S57 est mise à jour (étape S60) et le paquet est récupéré (étape S58).
Si la signature est considérée comme incorrecte, alors le fichier ne peut plus être utilisé. Cela peut se produire si l'utilisateur a édité l'image, par exemple, en effectuant une rotation d'image, en enlevant les yeux rouges à un personnage ou en changeant la balance des couleurs.
L'étape suivante S61 prévoit alors de supprimer les identifications telles que l'identification d'image partagée et la signature et de supprimer le fichier index, ainsi que les informations présentes dans la ligne correspondante de la table de localisation 910 (étape S62).
Dans le cas où le fichier n'est pas trouvé à la place indiquée dans la table (étape S56), il a été détruit ou renommé et l'algorithme se contente alors de détruire la ligne correspondante dans la table de localisation 910, ainsi que le fichier index (étape S62). L'algorithme de la figure 9 déjà décrit se chargera, quant à lui, de retrouver le fichier s'il a été déplacé.
On notera que lorsque les étapes S50, S51, S53 ne trouvent pas de fichier, alors l'étape S63 prévoit d'alerter l'utilisateur par un message "pas trouvé".
La figure 14 représente de façon schématique une interface utilisateur qui peut avantageusement utiliser les informations disponibles dans les structures de données décrites aux figures 8 et 10, ainsi que celles qui sont contenues dans chaque ficher contenant une vue (partie cohérente du signal mémorisée), pour afficher des informations pertinentes pour l'utilisateur.
Ces informations sont, par exemple, propres à chaque partie cohérente de signal mémorisée et sont destinées à informer l'utilisateur de l'état de la partie considérée.
Des informations sur l'état de la partie du signal mémorisée renseignent plus particulièrement l'utilisateur sur la disponibilité des données constitutives de cette partie, que ce soit dans l'appareil client de l'utilisateur ou dans un ou plusieurs appareils distants du réseau.
Des informations sur l'état de la partie du signal mémorisée renseignent également l'utilisateur sur la possibilité de partager cette partie du signal avec un ou plusieurs autres appareils de communication.
Lorsque l'utilisateur visualise un ou plusieurs fichiers locaux sous la forme d'icône ou de prévisualisation, l'image affichée peut être modifiée pour rendre compte de l'état des données visualisées.
Dans l'exemple de la figure 14, plusieurs indicateurs se superposent aux icônes des imagettes 1 à 8 pour donner plusieurs informations: É Une flèche de réception référencée 960 apparaît sur les imagettes 1, 2, 4 et 7 et indique que l'image considérée qui a été mémorisée dans l'appareil est une vue sur une image partagée, les données ayant été reçues du réseau.
É Une flèche d'émission référencée 962 apparaît sur les imagettes 1, 4 et 5 et indique que les données de la vue sont utilisables pour partager l'image dans le réseau avec d'autres appareils. C'est le cas pour une vue qui se trouve dans un format compatible avec le format d'échange dans le réseau ou pour l'image d'origine.
É Plusieurs rectangles référencés 964, 966, 968 et 970 apparaissant sur les imagettes 4 et 7 indiquent que le fichier est une vue partielle d'une image, toutes les données constitutives de l'image d'origine n'étant pas dans la vue mémorisée dans l'appareil.
En combinant ces indicateurs, on peut en déduire facilement de nombreuses informations: É Une image n'est pas partagée (imagettes 3, 6 et 8).
É Une image est une image d'origine partagée (imagette 5).
É Une image est une vue partielle sur une image partagée (imagette 4).
É Une image est une vue partielle dans un format non utilisable pour le réseau (imagette 7).
É Une image est une vue complète (imagette 1).
É Une image est une vue complète dans un format non utilisable pour le réseau (imagette 2).
D'autres indicateurs, tels que des couleurs, pourraient être représentatifs d'autres informations utiles comme, par exemple, le fait que des données supplémentaires sont disponibles pour une vue partielle, ces données pouvant provenir du fichier caché local ou d'autres vues stockées localement, ou bien provenir du réseau distribué. Ces données supplémentaires sont, par exemple, extraites de la table de description de la figure 10.
L'interface utilisateur comporte également des commandes permettant à un utilisateur d'effectuer différentes opérations spécifiques au partage d'une vue.
Les commandes associées aux vues peuvent varier en fonction de l'état de la vue.
Ainsi, les commandes offertes à l'utilisateur permettent d'effectuer les opérations suivantes: É "Compléter" une image pour une vue partielle, ce qui peut correspondre à aller chercher une résolution supplémentaire pour une vue qui ne contient qu'une résolution inférieure de l'image; l'image plus complète peut être visualisée ou simplement être sauvegardée et remplacer le fichier choisi.
É "Partager" pour partager une image non partagée.
É "Arrêter le partage" pour une image déjà partagée.
É "Afficher plus d'informations" : trace des accès réseau, droits d'accès associés, état de l'image dans le réseau...
Par exemple, la barre verticale de commande 972 affichée pour l'imagette 4 permet à l'utilisateur de choisir entre les fonctions "Compléter" 974 et "Arrêter le partage" 976.
On notera que l'état ou le statut d'une vue peut être notamment dicté par le fait que: la vue a été modifiée, - le format de la vue l'empêche d'être partagée, - l'utilisateur ne veut pas partager la vue.
Un mode de réalisation particulier de l'invention peut prendre la forme d'un code ajouté ("plug-in" en terminologie anglosaxonne) dans une application existante, comme par exemple dans un explorateur de fichiers (ex: Microsoft Explorer). Le code ajouté peut ainsi modifier l'affichage des icônes et des imagettes lorsque l'utilisateur parcourt ses fichiers.
Les renommages de fichiers qui ont lieu dans l'application peuvent être ainsi détectés directement au moment où l'utilisateur fait l'opération, ce qui permet de mettre à jour la table de localisation directement au moment où un fichier est renommé, déplacé ou détruit, et ce, sans avoir besoin de l'algorithme de la figure 9. Cet algorithme doit cependant être mis en place car des opérations peuvent avoir lieu dans d'autres applications.
En référence à la figure 15 est décrit un exemple d'appareil de communication programmable mettant en oeuvre l'invention.
Chacun des appareils de communication des figures 1 et 5 est, par exemple, identique à l'appareil de la figure 15.
En effet, au sein d'un réseau distribué chaque appareil connecté est susceptible de mettre en oeuvre l'invention et possède donc les moyens qui le rendent apte à cette mise en oeuvre.
L'appareil de la figure 15 comprend le dispositif selon l'invention.
Selon le mode de réalisation choisi et représenté à la figure 15, un appareil mettant en oeuvre l'invention est par exemple un microordinateur 1200 ou une station de travail connecté à différents périphériques tels que, par exemple une caméra numérique 1201 (ou un scanner, ou tout moyen d'acquisition ou de stockage d'image) reliée à une carte graphique et fournissant à l'appareil des données multimédia.
L'appareil 1200 comporte un bus de communication 1202 auquel sont reliés: - une unité centrale de traitement 1203 (microprocesseur), - une mémoire morte 1204, pouvant comporter les programmes "Prog 1 ", "Prog2" et "Prog3", - une mémoire vive 1206, comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités, ainsi que les descripteurs de données et les paquets de données traités au cours de l'exécution de ces mêmes programmes, - un écran 1208 permettant de visualiser des données (parties exploitables de signal) et/ou de servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier 1210 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 1211 ou un crayon optique, - un disque dur 1212 pouvant comporter les programmes "Prog1 ", "Prog2" et "Prog3" précités, ainsi que le fichier cache et les fichiers de vues, - un lecteur de disquette 1214 adapté à recevoir une disquette 1216 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention, - une interface de communication 1218 reliée à un réseau de communication distribué 1220, par exemple le réseau Internet, l'interface étant apte à transmettre et à recevoir des données.
Dans le cas de données audio, l'appareil comprend en outre une carte d'entrée/sortie (non représentée) reliée à un microphone 1222.
Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le micro-ordinateur 1200 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du micro-ordinateur 1200 directement ou par l'intermédiaire d'un autre élément du micro-ordinateur 1200.
Le code exécutable de chaque programme permettant à l'appareil programmable de mettre en oeuvre les algorithmes des figures 9, 11, 12 et 13 selon l'invention, peut être stocké, par exemple, dans le disque dur 1212 ou en 10 mémoire morte 1204 comme représenté sur la figure 15.
Selon une variante, la disquette 1216, peut contenir des données ainsi que le code exécutable des programmes précités qui, une fois lu par l'appareil 1200, sera stocké dans le disque dur 1212.
En seconde variante, le code exécutable des programmes pourra être reçu par l'intermédiaire du réseau de communication 1220, via l'interface 1218, pour être stocké de façon identique à celle décrite précédemment.
Les disquettes peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) ou une carte mémoire. De manière générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non à l'appareil, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention.
De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage de l'appareil 1200 avant d'être exécutés.
L'unité centrale 1203 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 1212 ou dans la mémoire morte 204 ou bien dans les autres éléments de stockage précités.
Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 1212 ou la mémoire morte 1204, sont transférés dans la mémoire vive 1206 (RAM) qui contiendra alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention.
Il convient de noter que l'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé.
Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique (ASIC).
Claims (45)
1. Procédé de traitement de données numériques constitutives d'un signal dans un réseau de communication distribué comportant plusieurs appareils de communication, le signal étant identifié par un identifiant unique (ID) , caractérisé en ce que le procédé comporte les étapes suivantes: mémorisation, à au moins une adresse donnée d'un emplacement mémoire et dans un format lisible par une application, d'une ou de plusieurs parties du signal, appelées parties exploitables du signal, - association de l'identifiant unique du signal à chaque partie exploitable du signal, mémorisation dans au moins un appareil de communication d'une structure de données établissant un lien entre chaque partie exploitable du signal et l'identifiant unique de ce signal.
2. Procédé selon la revendication 1, caractérisé en ce que la structure de données prend la forme d'une table de localisation de toutes les parties exploitables du signal comportant le même identifiant unique du signal.
3. Procédé selon la revendication 1 ou 2, caractérisé en ce que la structure de données établit un lien entre l'identifiant unique du signal et les adresses en mémoire des différentes parties exploitables du signal.
4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que la structure de données établit également un lien entre chaque partie exploitable du signal et un index représentatif des données présentes dans la partie considérée.
5. Procédé selon la revendication 4, caractérisé en ce que l'index décrit, pour chaque partie exploitable du signal, des sous-parties de données constitutives de la partie considérée.
6. Procédé selon la revendication 4 ou 5, caractérisé en ce que la structure de données établit un lien entre l'identifiant unique du signal et les adresses en mémoire des index des différentes parties exploitables du signal.
7. Procédé selon l'une des revendications 4 à 6, caractérisé en ce que chaque index propre à une partie exploitable du signal donnée correspond à une structure de données en forme de table comportant l'identification des données présentes dans la partie considérée et leur adresse en mémoire pour les retrouver dans ladite partie mémorisée.
8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce qu'il comporte les étapes suivantes effectuées par le ou les appareils de communication dans lesquels sont mémorisées une ou plusieurs parties exploitables du signal: - réception préalable d'au moins certaines données constitutives du signal, - gestion d'emplacements en mémoire adaptée au fait que les données reçues qui ne sont pas contenues dans la ou les parties du signal mémorisées respectivement dans un ou plusieurs emplacements mémoire sont conservées en mémoire dans un emplacement mémoire distinct de ceux-ci, tandis que les données reçues qui sont contenues dans la ou les parties du signal mémorisées ne sont pas conservées en mémoire dans l'emplacement mémoire distinct.
9. Procédé selon l'une des revendications 1 à 8, caractérisé en ce qu'il comporte une étape de sélection d'au moins un format dans lequel chaque partie exploitable du signal est mémorisée.
10. Procédé selon l'une des revendications 1 à 9, caractérisé en ce qu'il comporte une étape de transfert dans le réseau de sous-parties de données constitutives d'au moins une partie exploitable du signal.
11. Procédé selon la revendication 10, caractérisé en ce que l'étape d'association de l'identifiant unique du signal à une partie exploitable du signal est effectuée par le ou les appareils de communication recevant tout ou partie des données constituant cette partie.
12. Procédé selon l'une des revendications 1 à 11, caractérisé en ce que l'étape d'association de l'identifiant unique du signal correspond à une étape d'insertion de cet identifiant dans une partie exploitable du signal.
13. Procédé selon l'une des revendications 1 à 12, caractérisé en ce que l'étape de mémorisation de la structure de données est effectuée par le ou les appareils de communication recevant tout ou partie des données constituant une partie exploitable du signal.
14. Procédé selon l'une des revendications 1 à 13, caractérisé en ce qu'il comporte une étape d'obtention par au moins un appareil de communication recevant tout ou partie des données constituant une partie exploitable du signal d'au moins un descripteur de données représentatif des données présentes dans un ou plusieurs autres appareils de communication du réseau.
15. Procédé selon l'une des revendications 1 à 14, caractérisé en ce qu'il comporte une étape, effectuée au niveau d'un appareil de communication dans lequel sont mémorisées une ou plusieurs parties exploitables du signal, de visualisation de tout ou partie de chaque partie exploitable du signal mémorisée.
16. Procédé selon l'une des revendications 1 à 15, caractérisé en ce qu'il comporte une étape, effectuée au niveau d'un appareil de communication dans lequel sont mémorisées une ou plusieurs parties exploitables du signal, de visualisation d'informations, propres à chaque partie mémorisée et destinées à informer un utilisateur de l'état de la partie considérée.
17. Procédé selon la revendication 16, caractérisé en ce que l'état de la partie de signal exploitable considérée est représentatif de la disponibilité d'autres données constitutives du signal.
18. Procédé selon la revendication 16, caractérisé en ce que l'état de la partie de signal exploitable considérée est représentatif de la possibilité de partager cette partie avec un ou plusieurs autres appareils de communication.
19. Procédé selon l'une des revendications 16 à 18, caractérisé en ce que les informations propres à chaque partie mémorisée sont notamment obtenues à partir de la structure de données mémorisée.
20. Procédé selon l'une des revendications 1 à 19, caractérisé en ce qu'il comporte une étape, effectuée au niveau d'un appareil de communication dans lequel sont mémorisées une ou plusieurs parties exploitables du signal, de visualisation de commandes permettant à un utilisateur, à partir d'une partie exploitable du signal mémorisée, d'effectuer différentes opérations spécifiques au partage de la partie considérée avec un ou plusieurs autres appareils de communication, à savoir notamment, compléter la partie considérée avec des données supplémentaires et/ou partager la partie considérée avec un ou plusieurs autres appareils de communication.
21. Procédé selon l'une des revendications 1 à 20, caractérisé en ce qu'il comporte une étape préalable de génération de l'identifiant unique du signal.
22. Procédé selon la revendication 21, caractérisé que ce que l'étape de génération de l'identifiant unique du signal est effectuée par l'appareil de communication transférant tout ou partie des données constituant une partie exploitable du signal à un ou plusieurs autres appareils de communication.
23. Procédé selon l'une des revendications 1 à 22, caractérisé en ce que le signal numérique est un signal d'image.
24. Dispositif de traitement de données numériques constitutives d'un signal dans un réseau de communication distribué comportant plusieurs appareils de communication, le signal étant identifié par un identifiant unique (ID), caractérisé en ce que le dispositif comporte: - des moyens de mémorisation, à au moins une adresse donnée d'un emplacement mémoire et dans un format lisible par une application, d'une ou de plusieurs parties du signal, appelées parties exploitables du signal.
- des moyens d'association de l'identifiant unique du signal à chaque partie exploitable du signal, - des moyens de mémorisation dans au moins un appareil de communication d'une structure de données établissant un lien entre chaque partie exploitable du signal et l'identifiant unique de ce signal.
25. Dispositif selon la revendication 24, caractérisé en ce que la structure de données prend la forme d'une table de localisation de toutes les parties exploitables du signal comportant le même identifiant unique du signal.
26. Dispositif selon la revendication 24 ou 25, caractérisé en ce que la structure de données établit un lien entre l'identifiant unique du signal et les adresses en mémoire des différentes parties exploitables du signal.
27. Dispositif selon l'une des revendications 24 à 26, caractérisé en ce que la structure de données établit également un lien entre chaque partie exploitable du signal et un index représentatif des données présentes dans la partie considérée.
28. Dispositif selon la revendication 27, caractérisé en ce que l'index décrit, pour chaque partie exploitable du signal, des sous-parties de données constitutives de la partie considérée.
29. Dispositif selon la revendication 27 ou 28, caractérisé en ce que la structure de données établit un lien entre l'identifiant unique du signal et les adresses en mémoire des index des différentes parties exploitables du signal.
30. Dispositif selon l'une des revendications 27 à 29, caractérisé en ce que chaque index propre à une partie exploitable du signal donnée correspond à une structure de données en forme de table comportant l'identification des données présentes dans la partie considérée et leur adresse en mémoire pour les retrouver dans ladite partie mémorisée.
31. Dispositif selon l'une des revendications 24 à 30, caractérisé en ce qu'il comporte dans le ou les appareils de communication dans lesquels sont mémorisées une ou plusieurs parties exploitables du signal: - des moyens de réception préalable d'au moins certaines données constitutives du signal, - des moyens de gestion d'emplacements en mémoire adaptés au fait que les données reçues qui ne sont pas contenues dans la ou les parties du signal mémorisées respectivement dans un ou plusieurs emplacements mémoire sont conservées en mémoire dans un emplacement mémoire distinct de ceux-ci, tandis que les données reçues qui sont contenues dans la ou les parties du signal mémorisées ne sont pas conservées en mémoire dans l'emplacement mémoire distinct.
32. Dispositif selon l'une des revendications 24 à 31, caractérisé en ce 25 qu'il comporte des moyens de sélection d'au moins un format dans lequel chaque partie exploitable du signal est mémorisée.
33. Dispositif selon l'une des revendications 24 à 32, caractérisé en ce qu'il comporte des moyens de transfert dans le réseau des sous-parties de données constitutives d'au moins une partie exploitable du signal.
34. Dispositif selon l'une des revendications 24 à 33, caractérisé en ce qu'il comporte des moyens d'obtention par au moins un appareil de communication recevant tout ou partie des données constituant une partie exploitable du signal d'au moins un descripteur de données représentatif des données présentes dans un ou plusieurs autres appareils de communication du réseau.
35. Dispositif selon l'une des revendications 24 à 34, caractérisé en ce qu'il comporte des moyens de visualisation de tout ou partie de chaque partie exploitable du signal mémorisée dans un appareil de communication, lesdits moyens faisant partie d'un appareil de communication dans lequel sont mémorisées une ou plusieurs parties exploitables du signal.
36. Dispositif selon l'une des revendications 24 à 35, caractérisé en ce qu'il comporte des moyens de visualisation d'informations propres à chaque partie mémorisée et destinées à informer un utilisateur de l'état de la partie considérée, lesdits moyens faisant partie d'un appareil de communication dans lequel sont mémorisées une ou plusieurs parties exploitables du signal.
37. Dispositif selon la revendication 36, caractérisé en ce que l'état de la partie de signal exploitable considérée est représentatif de la disponibilité d'autres données constitutives du signal.
38. Dispositif selon la revendication 36, caractérisé en ce que l'état de la partie de signal exploitable considérée est représentatif de la possibilité de partager cette partie avec un ou plusieurs autres appareils de communication.
39. Dispositif selon l'une des revendications 36 à 38, caractérisé en ce que les informations propres à chaque partie mémorisée sont notamment obtenues à partir de la structure de données mémorisée.
40. Dispositif selon l'une des revendications 24 à 39, caractérisé en ce qu'il comporte des moyens de visualisation de commandes permettant à un utilisateur, à partir d'une partie exploitable du signal mémorisée, d'effectuer différentes opérations spécifiques au partage de la partie considérée avec un ou plusieurs autres appareils de communication, à savoir notamment, compléter la partie considérée avec des données supplémentaires et/ou partager la partie considérée avec un ou plusieurs autres appareils de communication, lesdits moyens faisant partie d'un appareil de communication dans lequel sont mémorisées une ou plusieurs parties exploitables du signal.
41. Dispositif selon l'une des revendications 24 à 40, caractérisé en ce qu'il comporte des moyens de génération de l'identifiant unique du signal.
42. Appareil de communication comportant un dispositif selon l'une des revendications 24 à 41.
43. Moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution des étapes du procédé selon l'une des revendications 1 à 23.
44. Moyen de stockage d'informations amovible partiellement ou totalement, lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution des étapes
du procédé selon l'une des revendications 1 à 23.
45. Programme d'ordinateur chargeable dans un appareil programmable, comportant des séquences d'instructions ou portions de code logiciel pour mettre en oeuvre des étapes du procédé selon l'une des revendications 1 à 23, lorsque ledit programme d'ordinateur est chargé et exécuté sur l'appareil programmable.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR0311832A FR2860935B1 (fr) | 2003-10-09 | 2003-10-09 | Procede et dispositif de traitement de donnees numeriques |
US10/962,141 US8782116B2 (en) | 2003-10-09 | 2004-10-08 | Method and device for processing digital data with a unique identifier |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR0311832A FR2860935B1 (fr) | 2003-10-09 | 2003-10-09 | Procede et dispositif de traitement de donnees numeriques |
Publications (2)
Publication Number | Publication Date |
---|---|
FR2860935A1 true FR2860935A1 (fr) | 2005-04-15 |
FR2860935B1 FR2860935B1 (fr) | 2006-03-03 |
Family
ID=34355359
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
FR0311832A Expired - Fee Related FR2860935B1 (fr) | 2003-10-09 | 2003-10-09 | Procede et dispositif de traitement de donnees numeriques |
Country Status (2)
Country | Link |
---|---|
US (1) | US8782116B2 (fr) |
FR (1) | FR2860935B1 (fr) |
Families Citing this family (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7499935B2 (en) * | 2002-11-06 | 2009-03-03 | Lawrence Casey J | System and method for enabling access to a data source through a graphical interface |
EP1683326B1 (fr) * | 2003-11-14 | 2008-07-16 | Canon Kabushiki Kaisha | Systeme, procede et dispositifs permettant de consulter ou de partager un document numerique dans un reseau de communication point a point |
FR2863127A1 (fr) * | 2003-12-02 | 2005-06-03 | Canon Kk | Procedes et dispositifs pour la delivrance asynchrone de donnees numeriques |
FR2864407B1 (fr) | 2003-12-22 | 2006-03-10 | Canon Kk | Procede et dispositif de transmission continue d'une video dans un reseau de communication |
FR2870022B1 (fr) | 2004-05-07 | 2007-02-02 | Canon Kk | Procede et dispositif de distribution de donnees numeriques notamment pour reseau pair-a-pair |
FR2906950B1 (fr) * | 2006-10-05 | 2008-11-28 | Canon Kk | Procede et dispositifs pour adapter le debit de transmission d'un flux de donnees en presence d'interferences. |
FR2908576A1 (fr) | 2006-11-14 | 2008-05-16 | Canon Kk | Procede,dispositif et application logicielle d'ordonnancement d'une transmission de paquets d'un flux de donnees |
FR2909241B1 (fr) * | 2006-11-27 | 2009-06-05 | Canon Kk | Procedes et dispositifs de gestion dynamique des erreurs de transmission par des points d'interconnexion de reseaux. |
FR2916600B1 (fr) * | 2007-05-24 | 2013-11-22 | Canon Kk | Procede et dispositif de transmission de donnees |
US8291316B2 (en) * | 2007-05-30 | 2012-10-16 | Xerox Corporation | Production environment CRM information gathering system for VI applications |
FR2923124A1 (fr) * | 2007-10-26 | 2009-05-01 | Canon Kk | Procede et dispositif de determination de la valeur d'un delai a appliquer entre l'envoi d'un premier ensemble de donnees et l'envoi d'un second ensemble de donnees |
FR2923970B1 (fr) * | 2007-11-16 | 2013-01-04 | Canon Kk | Procede et dispositif de formation, de transfert et de reception de paquets de transport encapsulant des donnees representatives d'une sequence d'images |
FR2927749B1 (fr) * | 2008-02-14 | 2010-12-17 | Canon Kk | Procede et dispositif de transmission de donnees, notamment video. |
FR2935862B1 (fr) * | 2008-09-08 | 2014-09-05 | Canon Kk | Procede de prediction du taux d'erreurs de transmission dans un reseau de communication et serveur mettant en oeuvre un tel procede |
KR20100053186A (ko) * | 2008-11-12 | 2010-05-20 | 삼성전자주식회사 | 썸네일 생성 방법 및 화상형성장치 |
FR2942095A1 (fr) * | 2009-02-09 | 2010-08-13 | Canon Kk | Procede et dispositif d'identification de pertes de donnees video |
US20200342979A1 (en) * | 2010-06-07 | 2020-10-29 | Affectiva, Inc. | Distributed analysis for cognitive state metrics |
US9613119B1 (en) | 2013-03-14 | 2017-04-04 | Nutanix, Inc. | Unique identifiers for data replication, migration, failover operations and failback operations |
RU2634223C2 (ru) * | 2015-06-30 | 2017-10-24 | Общество С Ограниченной Ответственностью "Яндекс" | Способ (варианты) и система (варианты) управления данными, связанными с иерархической структурой |
US10635648B2 (en) | 2016-11-30 | 2020-04-28 | Nutanix, Inc. | Entity identifier generation in distributed computing systems |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6014671A (en) * | 1998-04-14 | 2000-01-11 | International Business Machines Corporation | Interactive retrieval and caching of multi-dimensional data using view elements |
US20010027479A1 (en) * | 1998-10-05 | 2001-10-04 | Backweb Technologies, Ltd. | Distributed client-based data caching system |
WO2002015011A2 (fr) * | 2000-08-15 | 2002-02-21 | Aware, Inc. | Systeme et procede de memoire cache de creation d'objets absents de la memoire cache a partir de composantes d'objets en memoire cache et stockees |
US20020087728A1 (en) * | 2000-11-10 | 2002-07-04 | Deshpande Sachin G. | Methods and systems for scalable streaming of images with client-side control |
EP1274247A2 (fr) * | 2001-06-27 | 2003-01-08 | Ricoh Company, Ltd. | JPEG 2000 pour une transmission efficace d'images dans un environnement serveur-client |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6400996B1 (en) * | 1999-02-01 | 2002-06-04 | Steven M. Hoffberg | Adaptive pattern recognition based control system and method |
US6272662B1 (en) * | 1998-08-04 | 2001-08-07 | International Business Machines Corporation | Distributed storage system using front-end and back-end locking |
US6199099B1 (en) * | 1999-03-05 | 2001-03-06 | Ac Properties B.V. | System, method and article of manufacture for a mobile communication network utilizing a distributed communication network |
US6742023B1 (en) | 2000-04-28 | 2004-05-25 | Roxio, Inc. | Use-sensitive distribution of data files between users |
US6859609B1 (en) * | 2000-02-11 | 2005-02-22 | Lsi Logic Corporation | Portable digital recorder |
JP2004505349A (ja) | 2000-07-20 | 2004-02-19 | ディジマーク コーポレイション | ファイル共有で組み込まれたデータの使用 |
US7089301B1 (en) | 2000-08-11 | 2006-08-08 | Napster, Inc. | System and method for searching peer-to-peer computer networks by selecting a computer based on at least a number of files shared by the computer |
US7206806B2 (en) * | 2001-05-30 | 2007-04-17 | Pineau Richard A | Method and system for remote utilizing a mobile device to share data objects |
US7440994B2 (en) * | 2001-07-06 | 2008-10-21 | Intel Corporation | Method and apparatus for peer-to-peer services to shift network traffic to allow for an efficient transfer of information between devices via prioritized list |
FR2846181B1 (fr) | 2002-10-16 | 2005-09-02 | Canon Kk | Procede et dispositif de selection de donnees dans un reseau de communication |
FR2851866B1 (fr) | 2003-02-27 | 2005-10-28 | Procede d'allocation par un premier pair d'un service a un second pair d'un reseau de communication | |
FR2855691B1 (fr) | 2003-06-02 | 2005-11-11 | Canon Kk | Securisation de la distribution de documents numeriques dans un reseau pair a pair |
FR2857763A1 (fr) | 2003-07-18 | 2005-01-21 | Canon Kk | Procede d'acces et de partage d'un document numerique dans un reseau de communication p2p |
-
2003
- 2003-10-09 FR FR0311832A patent/FR2860935B1/fr not_active Expired - Fee Related
-
2004
- 2004-10-08 US US10/962,141 patent/US8782116B2/en not_active Expired - Fee Related
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6014671A (en) * | 1998-04-14 | 2000-01-11 | International Business Machines Corporation | Interactive retrieval and caching of multi-dimensional data using view elements |
US20010027479A1 (en) * | 1998-10-05 | 2001-10-04 | Backweb Technologies, Ltd. | Distributed client-based data caching system |
WO2002015011A2 (fr) * | 2000-08-15 | 2002-02-21 | Aware, Inc. | Systeme et procede de memoire cache de creation d'objets absents de la memoire cache a partir de composantes d'objets en memoire cache et stockees |
US20020087728A1 (en) * | 2000-11-10 | 2002-07-04 | Deshpande Sachin G. | Methods and systems for scalable streaming of images with client-side control |
EP1274247A2 (fr) * | 2001-06-27 | 2003-01-08 | Ricoh Company, Ltd. | JPEG 2000 pour une transmission efficace d'images dans un environnement serveur-client |
Non-Patent Citations (2)
Title |
---|
JPIP REQUIREMENTS AND PROFILES, April 2002 (2002-04-01), pages 1 - 6, XP002293707, Retrieved from the Internet <URL:http://www.dmn.tzi.org/ietf/mmusic/54/id/draft-prandolini-mmusic-jpip-requirements-00.txt> [retrieved on 20040824] * |
TAUBMAN D: "Proposal and Implementation of JPIP (Jpeg2000 Internet Protocol) in Kakadu v3.3", 9 August 2002 (2002-08-09), XP002260543, Retrieved from the Internet <URL:http://www.kakadusoftware.com/jpip-kakadu-superceded.pdf> * |
Also Published As
Publication number | Publication date |
---|---|
FR2860935B1 (fr) | 2006-03-03 |
US20050114386A1 (en) | 2005-05-26 |
US8782116B2 (en) | 2014-07-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
FR2860935A1 (fr) | Procede et dispositif de traitement de donnees numeriques | |
US10484469B2 (en) | Personal digital server (PDS) | |
US9348918B2 (en) | Searching content in distributed computing networks | |
CN104813321B (zh) | 在分布式对象存储生态系统中的去耦合的内容以及元数据 | |
US8140474B2 (en) | Aggregation of file/directory structures | |
FR2886494A1 (fr) | Procede et dispositif d'echange de donnees entre des stations mobiles dans un reseau pair a pair | |
FR2842057A1 (fr) | Procede et dispositif de traitement de donnees dans un reseau de communication | |
WO2007051807A1 (fr) | Procede de gestion de polices de caracteres a l'interieur de scenes multimedia, programme d'ordinateur et terminal correspondants | |
FR2863127A1 (fr) | Procedes et dispositifs pour la delivrance asynchrone de donnees numeriques | |
FR2868896A1 (fr) | Procede et dispositif de controle d'acces a un document numerique partage dans un reseau de communication de type poste a poste | |
WO2008047015A1 (fr) | Architecture d'acces a un flux de donnees au moyen d'un terminal utilisateur | |
FR2870022A1 (fr) | Procede et dispositif de distribution de donnees numeriques notamment pour reseau pair-a-pair | |
US20110010387A1 (en) | Associated content system | |
EP1977365B1 (fr) | Procede de gestion de documents electroniques | |
EP2230612A1 (fr) | Génération de recommandations pour un serveur de contenus | |
FR2893470A1 (fr) | Procede et dispositif de creation d'une sequence video representative d'une sequence video numerique et procedes et dispositifs de transmission et reception de donnees video associes | |
WO2006016085A1 (fr) | Procede de sauvegarde distribuee sur des postes clients dans un reseau informatique | |
WO2005114469A1 (fr) | Procede et dispositif de recherche avec conservation personnalisee des resultats | |
FR2752351A1 (fr) | Procede d'indexation de donnees dans un systeme de transmission de television numerique | |
WO2002103980A2 (fr) | Procede et systeme de diffusion d'images numeriques | |
WO2009136030A1 (fr) | Procede de sauvegarde/restauration de fichiers dans un reseau pair a pair | |
EP2353076A1 (fr) | Procede et systeme de stockage virtualise d'un ensemble de donnees numeriques | |
CN117424696A (zh) | 一种基于区块链与ipfs的文件加密传输方法、介质以及设备 | |
CA2245746A1 (fr) | Procede d'exploitation d'un ordinateur gerant des echanges d'informations et procede d'etablissement de formulaires | |
FR3046688A1 (fr) | Dispositif d'aide au referencement de documents numeriques |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
ST | Notification of lapse |
Effective date: 20140630 |