FR2820528A1 - Procede de transfert d'objet avec adaptation de format - Google Patents

Abstract

L'invention a pour but de proposer un procédé de transfert d'objet (par exemple un objet multimedia tel qu'une image, de l'audio ou de la vidéo) d'une entité source (par exemple un serveur) vers un entité destinataire (par exemple un client), avec adaptation du format de l'objet au niveau de l'entité source, avant son transfert, en fonction du profile de l'entité destinataire (écran, capacité de calcul, de stockage... ). Conformément à l'invention, une version de base de l'objet est décrite dans un document écrit dans langage de balisage (par exemple XML), et appelé document de base. Une ou plusieurs transformations sont définies (par exemple au format XSL). L'application d'une transformation au document de base permet de générer un document transformé. Une version adaptée de l'objet est générée à partir de ce document transformé.Application : téléchargement d'objets multimedia via Internet par exemple.

Description

<Desc/Clms Page number 1>

Domaine de l'invention

La présente invention concerne un procédé de transfert d'un objet d'une entité source à une entité destination. Elle concerne aussi un procédé de génération d'un fichier contenant un tel objet et ayant un format prédéterminé. Elle concerne aussi un procédé de génération d'un document écrit dans un langage de balisage, qui est notamment utilisable pour générer un tel fichier.

L'invention concerne également un équipement apte à la mise en oeuvre d'un procédé de génération de fichiers et/ou de documents. Elle concerne aussi un système de transmission comportant une entité source et une entité destination, et qui est apte à la mise en oeuvre d'un tel procédé de transfert d'objet.

L'invention concerne également des programmes d'ordinateurs pour la mise en oeuvre de tels procédés.

Elle concerne enfin un document écrit dans un langage de balisage, et un fichier binaire formaté en boîtes.

L'invention a d'importantes applications notamment dans le domaine de tinternet. De plus en plus d'équipements ont un accès au réseau Internet. C'est le cas par exemple des ordinateurs personnels, des téléphones mobiles, des assistants numériques personnels, des ordinateurs portables, des ordinateurs de poche... Ces équipements ont des ressources plus ou moins limitées (écran, capacité de calcul, capacité de stockage...), et se connectent au réseau Internet par des liaisons offrant des débits variés (liaisons radio, filaires, optiques...). Il est nécessaire d'adapter les objets à transférer en fonction du profile du destinataire. Cela permet notamment d'éviter de transmettre inutilement des données qui ne pourront pas être utilisées par le destinataire, et donc d'économiser de la bande passante.

Arrière plan technologique de l'invention
La demande de brevet international WO 99/41734 publiée le 19 août 1999 décrit un fichier graphique organisé en sections progressives et une méthode de transfert sélectif d'un tel fichier. Cette méthode consiste pour le destinataire à indiquer les sections dont il a besoin dans le fichier progressif.

Cette méthode implique donc que le destinataire connaisse la structure du fichier graphique, et qu'il sache déterminer les sections à récupérer en fonction de la résolution ou de la qualité qu'il souhaite obtenir.

Résumé de l'invention
L'invention a notamment pour but de proposer une méthode de transfert d'objet d'une entité source à une entité destination qui ne nécessite aucune intelligence spécifique au niveau de l'utilisateur.

<Desc/Clms Page number 2>

Pour cela, l'invention propose un procédé de transfert d'un objet d'une entité source vers une entité destinataire, ladite entité source comportant une mémoire de stockage d'un document de base écrit dans un langage de balisage et décrivant un fichier progressif de base contenant ledit objet, ledit procédé comportant : - une phase de sélection d'une transformation prédéfinie en fonction d'un format à obtenir, - une phase de transformation qui consiste à appliquer la transformation sélectionnée audit document de base, pour générer un document transformé, - une phase de génération d'un fichier ayant ledit format à partir dudit document transformé, - une phase de transfert du fichier généré.

Ainsi, l'adaptation de format se fait au niveau de l'entité source, ce qui fait qu'aucune intelligence particulière n'est nécessaire au niveau des entités destinataires.

Conformément à l'invention, l'entité source dispose d'un document de base, dans un langage de balisage, qui décrit le fichier progressif de base contenant l'objet à transférer. Elle dispose aussi d'une ou plusieurs transformations prédéfinies destinées à être appliquées à ce document de base pour obtenir un ou plusieurs documents transformés. Le fichier à transférer est généré à partir du document transformé obtenu. Il contient l'objet à transférer, mais dans un format différent de celui du fichier progressif de base.

L'invention consiste notamment à décrire les objets dans un langage de balisage, et à appliquer les transformations sur les descriptions obtenues. Dans la suite, ces descriptions sont appelées documents. Un tel langage de balisage permet de décrire la structure du fichier progressif de base. Cela signifie que, dans les documents obtenus, la structure du fichier progressif de base est directement apparente. Il est donc possible de définir des transformations qui s'appliquent à ces documents. Ces transformations s'expriment de façon simple, et leur mise en oeuvre nécessite peu de calculs.

En effectuant les transformations sur un document dans lequel la structure du fichier progressif de base est apparente, on évite d'avoir à décoder les fichiers progressifs de base pour les ré-encoder dans un autre format. On limite ainsi considérablement la charge de calculs.

De plus, conformément à l'invention, il suffit de stocker, au niveau de l'entité source, le document de base et, dans certains modes de réalisation, le fichier progressif de base dont il est issu, ainsi que les transformations prédéfinies. Les fichiers à transférer sont générés au coup par coup à partir du document de base en appliquant une transformation adaptée. Il n'est donc pas nécessaire de les stocker dans la mémoire de l'entité source. On limite ainsi considérablement la quantité d'informations à stocker au niveau de l'entité source.

Dans un mode de réalisation préférentiel de l'invention, le document de base contient un ou plusieurs éléments délimités par des balises et susceptibles de contenir un ou plusieurs attributs et du contenu, et ladite transformation consiste à supprimer un ou plusieurs éléments, et à modifier la valeur d'un ou plusieurs attributs.

<Desc/Clms Page number 3>

De façon avantageuse, la transformation prédéfinie est écrite dans un langage de transformation qui permet de définir des règles de transformation d'un document écrit dans ledit langage de balisage à un autre document écrit dans ledit tangage de balisage.

A titre d'exemple, le langage de balisage est un langage de type XML (eXtensible Markup Language en anglais), et ledit langage de transformation est un langage du type XSL (Extensible StyleSheet Language en anglais) tous deux définis par le consortium W3C.

Un autre but de l'invention est de proposer un document écrit dans un langage de balisage, utilisant un ensemble de caractères déterminés, et décrivant un fichier binaire contenant des données, ainsi qu'un procédé de génération d'un tel document.

Dans un premier mode de réalisation, une partie au moins du contenu dudit document correspond aux données dudit fichier binaire, converties en caractères dudit ensemble.

Dans ce premier mode de réalisation, le document est indépendant du fichier binaire puisqu'il contient lui-même les données du fichier binaire. Toutefois, la conversion des données binaires en caractères implique une certaine expansion de ces données.

Dans un second mode de réalisation, une partie au moins du contenu dudit document correspond à un ou plusieurs pointeur (s) vers lesdites données dans ledit fichier binaire.

Dans ce second mode de réalisation, le document ne contient pas directement les données du fichier binaire, mais renvoie au fichier pour avoir accès aux données. Pour être utilisable le document doit donc être accompagné du fichier binaire qu'il décrit. Mais dans ce cas, les données binaires ne sont pas converties en caractères, et il n'y a donc pas d'expansion des données.

De tels documents sont avantageusement utilisés pour constituer un document de base pour la mise en oeuvre d'un procédé de transfert d'objet selon l'invention. Dans ce cas, le fichier binaire de base contenant des données organisées en segments et des paramètres relatifs aux données utiles, ledit document de base contient avantageusement un ou plusieurs éléments délimités par des balises, susceptibles de contenir un ou plusieurs attributs et du contenu, un élément dudit document correspondant à un segment dudit fichier, et les attributs d'un élément dudit document correspondant aux paramètres relatifs aux données dudit segment.

Un autre but de l'invention est de proposer un fichier binaire particulier, avantageusement utilisé pour la mise en oeuvre d'un procédé de transfert d'objet selon l'invention.

Un tel fichier binaire est formaté en boîtes, et comporte au moins : - une boîte principale comportant un fichier progressif de base, - et au moins une boîte annexe qui contient un document écrit dans un langage de balisage décrivant ledit fichier progressif de base.

De façon avantageuse, la boîte annexe contient une ou plusieurs transformations destinées à être appliquées audit document.

Ainsi, toutes les informations relatives à un objet sont regroupées dans un seul fichier, ce qui est avantageux du point de vue de la gestion des fichiers.

<Desc/Clms Page number 4>

-----------------------
Un tel fichier est par exemple un fichier JPEG 2000. Dans ce cas, la boîte annexe est par exemple constituée par la boîte optionnelle XML définie dans la norme JPEG 2000. Elle peut aussi être constituée par une nouvelle boîte dédiée.

Brève description des dessins la figure 1 est un schéma en blocs explicitant les différentes étapes d'un procédé de transfert d'objet selon l'invention, ta figure 2 représente un exemple de système de transmission selon l'invention, ta figure 3 donne une représentation schématique d'un flux de code JPEG 2000, ta figure 4 donne une représentation schématique d'un exemple de fichier binaire selon l'invention.

Description d'un mode de réalisation préférentiel
L'invention concerne notamment un procédé de transfert d'objet d'une entité source vers une entité destination. Ce procédé de transfert comporte une étape d'adaptation de format. Cette adaptation se fait à partir d'un document de base, qui est écrit dans un langage de balisage, et qui décrit un fichier progressif de base contenant une version dudit objet. Elle permet de générer un document transformé. Finalement ce document transformé est utilisé pour générer un fichier contenant une autre version de l'objet.

Sur la figure 1, on a représenté un schéma en blocs résumant le fonctionnement d'un procédé de transfert d'objet selon l'invention. Le bloc Bl représente un fichier progressif de base F (O) correspondant à un certain format d'un objet O. Le bloc B2 représente un document de base DOC (O) écrit dans un langage de balisage et décrivant le fichier progressif de base. Les blocs B3-1 à B3-N représentent des transformations TRi (O) destinées à être appliquées au document de base DOC (O) pour générer un document transformé. Une étape de sélection S permet de sélectionner un format pour l'objet 0, ainsi qu'une transformation à appliquer qui est fonction du format sélectionné. Le bloc
B4-i représente un document transformé DOCi (O) généré en appliquant la transformation TRi (O) au document de base DOC (O). Enfin, le bloc B5-i représente un fichier Fi (O) généré à partir du document transformé DOCi (O), et qui contient l'objet 0 dans un autre format.

Ce procédé de transfert d'objet tire partie du caractère progressif du fichier de base. Il consiste à décrire la syntaxe de ce fichier progressif de base dans un document, afin de pouvoir la manipuler pour générer des versions adaptées de l'objet.

Un tel procédé est avantageusement utilisé dans un système de transmission selon l'invention.

Un exemple d'un tel système est représenté à la figure 2. Ce système comporte un serveur 1 et une pluralité de clients 2. Le serveur 1 et les clients 2 sont chacun dotés d'un accès 4 au réseau Internet
5. Le serveur 1 contient de la mémoire 10 et des moyens de calcul 12 pour la mise en oeuvre d'une méthode de transfert d'objet selon l'invention. La mémoire 10 contient notamment un fichier progressif de base F (O), un document de base DOC (O) qui décrit ce fichier progressif de base, et au moins une transformation TRi (O) destinée à être appliquée au fichier progressif de base. A titre

<Desc/Clms Page number 5>

r d'exemple, une telle méthode de transfert est avantageusement utilisée dans les situations suivantes : Lorsqu'un client envoie une requête en vue de télécharger un objet, une phase de négociation permet au serveur 1 de connaître le profile du client 2 et de choisir la transformation à appliquer au document de base pour générer un fichier adéquate.

Il est courant que les pages Web contiennent un objet (souvent une image) de faible résolution sur lequel le client peut cliquer pour télécharger une résolution complète du même objet. Le serveur applique alors une transformation spécifique pour générer un fichier qui ne contiendra que les données complémentaires de celles dont le client dispose déjà.

Il est également courant que sur un même site Web, une image soit proposée plusieurs fois (par exemple sur des pages différentes) dans des formats différents. Lorsque le client navigue parmi les pages, le serveur est alors amené à transmettre successivement différentes versions d'une même image. A chaque fois, il applique la transformation adéquate pour générer le format voulu, de sorte qu'il n'a pas à stocker en mémoire les différentes versions susceptibles d'être transmises. Dans cet exemple d'application, le choix du format se fait sans aucune intervention du client.

L'invention s'applique par exemple à des objets multimedia, c'est-à-dire une image fixe, de l'audio ou de la video.

Les fichiers qui contiennent une version de ce type d'objets sont par exemple des fichiers au format JPEG2000, au format GIF ou au format MPEG4. Dans la suite de la description, ils sont qualifiés de fichiers binaires parce que physiquement ils se présentent comme une suite quelconque de bits.

Un fichier progressif est un fichier qui est organisé de telle sorte qu'en récupérant une partie seulement du fichier on obtient une version dégradée de l'objet. Il existe différents types de progressivité : récupérer plus de données peut par exemple permettre d'améliorer la qualité du signal, d'obtenir des tailles d'images supérieures, d'obtenir une image couleurs au lieu d'une image à niveaux de gris, d'augmenter la fréquence trame d'une vidéo...

D'une façon générale, on entend par langage de balisage un langage qui utilise des balises et définit des règles d'utilisation de ces balises pour décrire la syntaxe d'un ensemble de données. Un tel langage permet donc de structurer un ensemble de données, et de séparer la structure de l'ensemble de données de son contenu.

XML est un exemple typique d'un tel langage de balisage. XML présente l'avantage d'être largement utilisé dans le monde Internet. Un autre avantage de XML est d'offrir un certain nombre d'outils, notamment un outil appelé XSL, qui permet de définir des transformations applicables à des documents XML. La définition d'une transformation se fait par l'intermédiaire d'une feuille de style XSL. Dans une transformation XSL, un processeur XSL lit un document XML et une feuille de style XSL pour générer un autre document, par exemple un document XML. XML et XSL se prêtent donc particulièrement bien à la mise en oeuvre de l'invention.

Dans la suite de la description, et afin de donner des exemples concrets, on utilise le langage XML pour générer des documents qui décrivent des fichiers au format JPEG2000. Ceci n'est pas

<Desc/Clms Page number 6>

r restrictif. On peut utiliser un autre type de langage de balisage et d'autres formats progressifs de fichiers.

La norme JPEG 2000 est décrite dans le document ISO/IEC FCD15444-1 intitulé JPEG 2000 Final Draft International Standard .

Les principales étapes du codage JPEG 2000 sont les suivantes : a) une étape optionnelle de transformation de l'image d'entrée pour obtenir une représentation de l'image dans l'espace Y-Cr-Cb, où Y est la composante de luminance, Cr la composante de chrominance Rouge et Cb la composante de chrominance bleue ;

b) une étape de transformation en odelettes des composantes de l'image c) une étape de quantification des coefficients obtenus ; d) une étape de codage ; e) une étape d'insertion des données obtenues dans un flux binaire ( bit stream en anglais) selon un certain schéma de progressivité.

Lorsque l'image à coder est très grande, une étape préliminaire permet de la diviser en plusieurs tuiles qui sont codées indépendamment les unes des autres. Dans la suite de la description, pour la simplicité de l'exposé, on se limitera au cas où l'image se compose d'une seule tuile. Ceci n'est pas restrictif.

JPEG 2000 prévoit l'utilisation de quatre schémas élémentaires de progressivité : par résolution, par qualité, par localisation spatiale et par composante. JPEG2000 propose aussi cinq combinaisons de ces schémas élémentaires. Chaque schéma de progressivité correspond à une manière spécifique d'ordonner les données dans le flux binaire.

Le flux binaire comporte des entêtes de paquets et des paquets qui contiennent les données utiles résultant du codage. Chaque paquet de données utiles correspond à une composante (i), une couche CD, un niveau de résolution (k), et une localisation de partition (m). Le flux binaire est construit en utilisant quatre boucles. L'ordre des boucles détermine le schéma de progressivité utilisé.

Pour un flux binaire ayant une progressivité par composantes, l'ordre des quatre boucles est par exemple le suivant : pour chaque composante, pour chaque résolution, pour chaque couche, pour chaque localisation de partition, écriture du paquet dans le flux binaire.

Dans la suite de la description on se limitera au cas d'une progressivité par composantes, mais l'invention est applicable à tout type de progressivité.

Conformément à la terminologie JPEG2000, toutes les informations relatives à une image sont regroupées dans un flux de code (ou codestream en anglais). Le flux de code comporte un entête principal, un ou plusieurs entêtes de tuiles suivis chacun d'un flux binaire, et il se termine par un marqueur de fin. L'entête principal et les entêtes de tuiles sont organisés en marqueurs et segments de marqueurs. Finalement, le flux de code est lui même contenu dans un fichier binaire.

<Desc/Clms Page number 7>

Sur la figure 3, on a représenté la structure d'un exemple de flux de code JPEG 2000. Ce flux de code CS commence par un entête principal 100 qui contient un marqueur SOC (de l'anglais Start Of Codestream ), suivi des segments de marqueur SIZ (de l'anglais image and tile SIZe ), COD (de l'anglais COding style Default ) et QCD (de l'anglais Quantization Default ). Il comporte ensuite un entête de tuile 110 qui contient un segment de marqueur SOT (de l'anglais Start Of Tile part ), suivi d'un marqueur SOD (de l'anglais Start Of Data ). Il comporte enfin un flux binaire 120 composé de plusieurs paquets optionnellement précédés de marqueurs SOP (de l'anglais Start Of Packet ) servant à marquer le début des paquets. Et il se termine par un marqueur de fin EOC (de l'anglais End Of Codestream ). Les dénominations utilisées ici sont celles de la recommandation JPEG 2000. D'autres marqueurs optionnels sont définis dans la recommandation JPEG 2000.

On va maintenant exposer les bases du langage XML. Ce langage est décrit dans la recommandation du consortium W3C intitulée REC-xml-19980210 publiée le 10 février 1998.

D'un point de vue physique, un document XML peut comporter des entités analysables et des entités non analysables. Une entité analysable contient du texte, c'est-à-dire une suite de caractères appartenant à un ensemble de caractères prédéfini, qui représentent du balisage ou des données textuelles. Une entité non analysable peut contenir autre chose que du texte, ou un texte qui n'est pas un texte XML.

D'un point de vue logique, un document XML contient un ou plusieurs éléments dont les limites sont marquées par une balise ouvrante et une balise fermante. Des éléments peuvent s'imbriquer les uns dans les autres. Chaque élément est identifié par un nom. Il est possible de lui associer un jeu de spécifications d'attributs. Chaque spécification d'attribut comprend un nom et une valeur. Aucun nom d'attribut ne peut apparaître plusieurs fois dans la même balise de début.

On va maintenant décrire une méthode pour structurer un flux de code JPEG 2000 avec le langage XML.

Dans cet exemple, on a choisit de créer un élément XML pour chaque segment de marqueur du fichier JPEG 2000, en appliquant les règles suivantes : - l'élément est nommé d'après le code en trois lettres du marqueur, ta longueur du marqueur et les autres paramètres contenus dans le marqueur sont définis comme des attributs de l'élément, - lorsqu'un paramètre ou un groupe de paramètres est répété, on crée un sous-élément au lieu de créer un attribut, parce que le langage XML ne permet pas d'avoir plusieurs attributs ayant le même nom dans une même balise de début (c'est le cas par exemple du segment de marqueur SIZ qui se termine par un groupe de trois paramètres Ssiz, XRsiz, et YRsiz répétés pour chacune des composantes de l'image).

Par ailleurs, le flux binaire étant composé de données purement binaires, il n'est pas possible de l'inclure directement dans un document XML (qui ne tolère que certains caractères bien définis).

Dans un premier mode de réalisation, le flux binaire est converti en caractères. Pour cela, on utilise avantageusement, une méthode de codage connue sous le nom de base 64 et décrite au paragraphe 6.8 du document RFC 2045 publié par l'lm. Cette méthode consiste à découper le flux

<Desc/Clms Page number 8>

r binaire en groupes de 6 bits, et à associer à chaque groupe de 6 bits un caractère d'un alphabet de caractères. Cette méthode présente donc l'inconvénient d'entraîner une expansion des données de 33%.

Dans un deuxième mode de réalisation, au lieu de convertir le flux binaire en caractères pour t'insérer dans le document XML, on introduit dans le document XML des pointeurs vers les zones du fichier binaire qui contiennent les données binaires. Dans ce mode de réalisation, le document XML devient dépendant du fichier de base.

On donne en annexe 1, à titre d'exemple non limitatif, un document XML qui décrit le flux de code JPEG 2000 représenté à la figure 3, pour un schéma de progressivité par composantes. Dans cet exemple, le contenu des paquets a été tronqué de façon à ce qu'il n'occupe qu'une seule ligne.

On va maintenant décrire un exemple de transformation susceptible d'être appliquée à un document XML pour générer un document XML transformé qui décrit une version allégée de l'image.

Dans le cas où l'image est codée avec une progressivité par composantes, cette version allégée est une version dans laquelle les composantes de chrominance sont supprimées. Lorsqu'une image JPEG 2000 est codée avec une progressivité par composantes, les premiers paquets du flux binaires correspondent aux paquets de luminance, et les paquets de chrominance viennent après. Il suffit donc de supprimer les derniers paquets du flux binaire pour passer d'une image couleur à une image à niveaux de gris.

D'une façon générale, la transformation consiste à supprimer certains les éléments du document XML de base, et à modifier la valeur de certains attributs afin de maintenir la cohérence de l'ensemble du flux de code.

Dans le cas d'un codage avec une proximité par composantes, il faut - supprimer les éléments SOP correspondant aux paquets de chrominance, - supprimer les éléments qui contiennent les attributs Ssiz, XRsiz et YRsiz relatifs aux composantes de chrominance, modifier l'attribut Csiz de l'élément SIZ qui indique le nombre de composantes (ancienne valeur 3 = > nouvelle valeur 1), - modifier l'attribut MarkSegLen de l'élément SIZ qui indique la taille du segment de marker SIZ (ancienne valeur 38+3.3=47 = > nouvelle valeur 38+3.1=41).

Une telle transformation est avantageusement définie dans une feuille de style XSL. On donne en annexe 2, à titre d'exemple non limitatif une feuille de style XSL destinée à être appliquée au document XML décrit à l'annexe 1.

Sur la figure 4, on a représenté un exemple de fichier binaire au format JPEG2000, conforme à l'invention. D'après la figure 4, un fichier binaire FF au format JPEG2000 comporte une boîte principale BX1 qui contient un flux de code CS qui constitue un fichier progressif de base au sens de la présente invention. Il contient aussi une boîte annexe BX2 qui contient un document XML référencé DOC. Le document DOC décrit le flux de code CS. La boîte annexe B2 peut également une transformation XSL référencé TR destiné à être appliqué au document DOC.

<Desc/Clms Page number 9>

r 1 ANNEXE 1 page 1 1

< ? xml version="1. 0" ? > < Codestream > 1 < MainHeader > < SOC markSegLen="-l"markerCodeStr="ff4f" > < /SOC > < SIZ Csiz="3"RsizStr="JPEG 2000-Part I"XOsiz="0"XTOsiz="0"XTsiz="515" Xsiz="515"YOsiz="O"YTOsiz="0"YTsiz="512"Ysiz="512"markSegLen="47" markerCodeStr="ff51" > < Compsiz Ssiz="7"XRsiz="l"YRsiz="1" > < /Compsiz > < Compsiz Ssiz="7"XRsiz="1"YRsiz="1" > < /Compsiz > < Comp~siz Ssiz="7"XRsiz="1"YRsiz="1" > 1 < /Comp siz > < /SIZ > < COD codeBlockHeightExp="4" codeBlockWidthExp="4"ephUsed="false" markSegLen="12"markerCodeStr="ff52"mct="l"nDecompLevel="5" numLayers="l"optByPass="false"optErTerm="false" optRegTerm="false" optResetMQ="false"optSegMarkers="false"optVertStrCausal="false" precinctPartitionIsUsed="false"progType="4"progTypeStr="Component" sopUsed="true"wavTrans="0"wavTransStr="9-7" > < /COD > < QCD Sqcd="2"markSegLen="35"markerCodeStr="ff5c" nGuardBits="2" > < SPqcd spqcdval="28440" > < /SPqcd > < SPqcd spqc~dval="28394" > < /SPqcd > < SPqcd spqcd~val="28394" > < /SPqcd > < SPqcd spqcd~val="28348" > < /SPqcd > < SPqcd spqcd~val="26368" > < /SPqcd > < SPqcd spqcd~val="26368" > < /SPqcd > < SPqcd spqcd~val="26338" > < /SPqcd > < SPqcd spqcd~val="24396" > < /SPqcd > < SPqcd spqcdval="24396" > < /SPqcd > < SPqcd spqcd~val="24420" > < /SPqcd > < SPqcd spqcd~val="18435" > < /SPqcd > < SPqcd spqcd~val="18435" > < /SPqcd > < SPqcd spqcdval="18501" > < /SPqcd > < SPqcd spqcd~val="20434" > < /SPqcd > < SPqcd spqcd~val="20434" > < /SPqcd > < SPqcd spqcdyal="20321" > < /SPqcd >

< /QCD > < /QCD > < /MainHeader >

<Desc/Clms Page number 10>

--------------------------ANNEXE 1 page < TilePartHeader > SOT Isot="0"Psot="32722"TNsot="l"TPsot="0" markSegLen="10" markerCodeStr="ff90" > < /SOT > < SOD markSegLen="-l" markerCodeStr="ff93" > < /SOD > < SOP Lsop="0"Nsop="0"markSegLen="4"markerCodeStr="ff91" > z okxf j Aav/0 eNhO KCgQ= < /SOP > < SOP Lsop="0"Nsop="l"markSegLen="4"markerCodeStr="ff91" > vih3XvSqAxdN7qp7Aubt : +hlA5Iai7DNKpOQYslJGcF+kax9m < /SOP > < SOP Lsop="0"Nsop="2"markSegLen="4"markerCodeStr="ff91" > ion5YDUL4HqwaIzDAg== < /SOP > < SOP Lsop="0"Nsop="3"markSegLen="4"markerCodeStr="ff91" > v5HtMkNwzwEIhKL7bEcpU5ZrplIfzrl8kZkNLcmlCw== < /SOP > < SOP Lsop="0"Nsop="4"markSegLen="4"markerCodeStr="ff91" > o3a7iCvOmlV/xPkZz6Ks7HXbJYUyLNnyi 8JhjOOeYgvi < /SOP > < SOP Lsop="0"Nsop="5"markSegLen="4"markerCodeStr="ff91" > 4opHeHv9L+qiu/UplNkyVlPIWoc8umfkl4Z6eDIzKNGtEvbkCMaknWAcYYxjmf < /SOP > < SOP Lsop="0"Nsop="6"markSegLen="4"markerCodeStr="ff91" > EnEF62yGwcRtY2ehQYEpuQ== < /SOP > < SOP Lsop="0"Nsop="7"markSegLen="4"markerCodeStr="ff91" > ldWatY7LLQ== < /SOP > < SOP Lsop="0"Nsop="8"markSegLen="4"markerCodeStr="ff91" > b3qu8Ev6TqqoK4IItml9ClfijOSVY2qqIMswd7eSOQhyp5bIStPlwMOsB6i2b/jSJMo80vg= < /SOP > < SOP Lsop="0"Nsop="9"markSegLen="4"markerCodeStr="ff91" > 83mg5+Jv95wRIRM61swWYBHw7eAeb2BNrmBsClXrTjvzGFL5rYlBCyAn8CS < /SOP > < SOP Ijsop="0"Nsop="10"markSegLen="4"markerCodeStr="ff91" > 7psE6fJW2/G3ohpvNaT+ovEFscTFj++9sdVipOXwnPn25oWq2yZYNh+DWr3T7H+V < /SOP > SOP Lsop="0"Nsop="ll"markSegLen="4"markerCodeStr="ff91" > XaILyXsuXvRI+C4p < /SOP > < SOP Lsop="0"Nsop="12"markSegLen="4"markerCodeStr="ff91" > W6qLBsuVSFjQRnGVfO27J97dmNDaUYjLttBepCvUXQu71TWIWBzRRROmPgpPBg== < /SOP > SOP Lsop="0"Nsop="13"markSegLen="4"markerCodeStr="ff91" > 3s+ECWT/ZjkqNaHDcQ== < /SOP > < SOP Lsop="0"Nsop="14"markSegLen="4" markerCodeStr="ff91" > +eQE2EkO4vydGK++tx9kkpjZL6TeiR2nc4crNQ4zHDurQg== < /SOP > < SOP Lsop="0"Nsop="15"markSegLen="4"markerCodeStr="ff91" > lcQa40/p/tH7FOjYOfjYefzcUtdrynh7RRVhBftsTuOF6Y5qXhD ! D4G2uBd/a7 uw49QaaPKt : fJb8XiaVpXVqBW9LwoqQ== < /SOP > SOP Lsop="0"Nsop="16"markSegLen="4"markerCodeStr="ff91" > ZjJalwvkxOSiIQUOsc/RkjO4wqeX6qg3miqkFQ== < /SOP > < SOP Lsop="0"Nsop="17"markSegLen="4"markerCodeStr="ff91" > gA== < /SOP > < /TilePartHeader > 1 < EOC markSegLen="-l"markerCodeStr="ffd9" > < /EOC > < /Codestream >

<Desc/Clms Page number 11>

ANNEXE 2 page 1 < ? xml version="1. 0" ? > < !--
Remove color components :
For this, this stylesheet performs the following transformation : - check that SOP markers are used - check progression type - check that multiple component transform is used - check that nCompOut < = Csiz -replace the Csiz attribute value by the wanted value (nCompOut) - delete Compsiz éléments accordingly -update markSegLen value accordingly

-delete SOP elements accordingly Input parameter : nCompOut, default value = 1 1 xsl : stylesheet xmlns : xsl="http ://www. w3. org/1999/XSL/Transform" version="1. 0" > < xsl : import href="tplCheckSOPUsed. xsl"/ > < xsl : output method="xml"indent="yes"/ > < !-- Parameter : number of output components-Default value =1-- > xsl : param name="nCompOut" > l < /xsl : param > < !-- Match all: default template-- > < xsl:template name="tplAll" match="@*|node ()" > < xsl : copy > < xsl : apply-templates select="@*) node ()"/ > < /xsl : copy > < /xsl : template >

< !-- Match COD/@sopUsed-Overrides tplAll-- > (xsl : template name="tplSopUsed"match="//COD/@sopUsed"priority="l" > < !-- Check /COD/sopUsed value-- > < xsl : call-template name="tplCheckSOPUsed"/ > < /xsl : template

< !-- Match COD-Overrides tplAll-- > < xsl : template name="tplCOD"match=="COD"priority="l" > < !--Check progType value-- > < xsl : if test="@progType ! =4" > < xsl : message terminate="yes" >
Error : progression type is < xsl : value-of select="@progType"/ >
Should be 4 (progression by color component) < /xsl : message > < /xsl : if > < ! -- Check mct value -- > < xsl : if test="@mct=0 and//SIZ/@Csiz=3" > < xsl : message >
Warning : no multi-component transf. was applied to input image.

If input was RGB, output will be the Red component.

< /xsl : message > < /xsl : if >

< !--Copy COD-- > < xsl : copy > < xsl : apply-templates select="@*"/ > < !-- Set met value to 0-- > < xsl : attribute name="mct" > 0 < /xsl : attribute > < /xsl : copy > < /xsl : template

<Desc/Clms Page number 12>

1 ANNEXE 2 oage 2 < !-- Match SIZ - Overrides tplAll -- > < xsl : template name="tplSIZ"match="SIZ"priority="l" > < !--Check nCompOut value : should be < = Csiz-- > < xsl : if test=" ( ($nCompOut & gt ; @Csiz) or ($nCompOut & lt ; 1))" > < xsl : message terminate="yes" >
Error : number of output color components should be & gt ; = 1 and & lt ; < xsl : value-of select="@Csiz"/ > . Exit...

< /xsl : message > < /xsl : if > < xsl : copy > < !-- Copy attributes-- > < xsl : apply-templates select="@*"/ > < !-- Update Csiz value-- > < xsl : attribute name="Csiz" > < xsl : value-of select="$nCompOut"/ > < /xsl : attribute >

< !--Update markSegLen value accordingly < xsl : attribute name="markSegLen" > < xsl : value-of select="38 + 3 * $nCompOut"/ > < /xsl : attribute >

c !--Copy only relevant Comp~siz elements-- > < xsl : apply-templates select="Compsiz [position () & lt ; = $nCompOut]"/ > < /xsl : copy > < /xsl : template >

< !-- Match TilePartHeader-Overrides tplAll-- > < xsl : template name="tplTilePartHeader"match="TilePartHeader"priority="l" > < !-- Calculate number of output packets < xsl : variable name="nSOPOut" > < xsl : value-of select= " (//COD/@nDecompLevel + 1) *//COD/@numLayers * $nCompOut"/ >

< /xsl : variable > < xsl : copy > < i--Copy attributes-- > < xsl : apply-templates select="*ISOTISOD"/ > < !-- Remove SOP packets accordingly < xsl : apply-templates select="SOP [position () & lt ; = $nSOPOut]"/ > < xsl : message >
Initial number of SOP : < xsl:value-of select="count (SOP)"/ >
Output number of SOP : < xsl:value-of select="$nSOPOut"/ > < /xsl : message > < /xsl : copy > < /xsl : template > < /xsl : stylesheet >

<Desc/Clms Page number 13>

ANNEXE 2 page 3 < ? xml version="1. 0" ? > < !--
This stylesheet performs the following transformation :

- check than"sopUsed"attribute of"COD"element is set to yes, otherwise, exit -- > < xsl : stylesheet xmlns : xsl="http ://www. w3. org/1999/XSL/Transform" version="1. 0" > < !-- Template tplCheckSOPUsed-- > < xsl : template name="tpICheckSOPUsed" > < xsl : variable name="sopUsed" > < xsl : value-of select="//COD/@sopUsed"/ > < /xsl : variable > < xsl : if test="$sopUsed ! ='true"' > < xsl : message terminate="yes" >
Error : SOP markers are not used in this codetsream.

Cannot process. Exit...

< /xsl : message > < /xsl : if > < xsl : copy/ > < /xsl : template > < /xsl : stylesheet >

Claims (10)

1. CS) qui contient ledit objet, ledit procédé comportant : - une phase de sélection d'une transformation (TRi (O)) prédéfinie en fonction d'un format à obtenir, - une phase de transformation qui consiste à appliquer la transformation sélectionnée audit document de base, pour générer un document transformé (DOCi (O)), - une phase de génération d'un fichier (Fi (O)) ayant ledit format à partir dudit document transformé, - une phase de transfert du fichier généré.

   r 1. Procédé de transfert d'un objet (0) d'une entité source (1) vers une entité destinataire (2), ladite entité source comportant une mémoire (10) de stockage d'un document de base (DOC (O)) écrit dans un langage de balisage et décrivant un fichier progressif de base (F (O),

   

   REVENDICATIONS
2. 2. Procédé de génération d'un fichier ayant un certain format, à partir d'un document de base écrit dans un langage de balisage et décrivant un fichier progressif de base, ledit procédé comportant une étape de transformation pour générer un document transformé en appliquant au document de base une transformation prédéfinie qui est fonction dudit format, le fichier audit format étant généré à partir du document transformé.
3. 3. Procédé de génération de fichier selon la revendication 2 caractérisé en ce que, ledit document de base contenant un ou plusieurs éléments délimités par des balises et susceptibles de contenir un ou plusieurs attributs et du contenu, ladite transformation consiste à supprimer un ou plusieurs éléments, et à modifier la valeur d'un ou plusieurs attributs.
4. 4. Procédé de génération de fichier selon la revendication 2, caractérisé en ce que la transformation prédéfinie est écrite dans un langage de transformation permettant de définir des règles de transformation d'un document écrit dans ledit langage de balisage à un autre document écrit dans ledit langage de balisage.
5. 5. Procédé de génération de fichier selon la revendication 2, caractérisé en ce que ledit langage de balisage est un langage de type XML, et ladite transformation est écrite dans un langage de type XSL.
6. 6. Equipement électronique doté d'une mémoire contenant un document écrit dans un langage de balisage et décrivant un fichier progressif de base, et d'un processeur pour la mise en oeuvre d'un procédé de transfert d'objet selon la revendication 1.

   <Desc/Clms Page number 15>

   r
7. 7. Système de transmission comportant au moins une entité source et une ou plusieurs entités destinataire, aptes à la mise en oeuvre d'un procédé de transfert d'objets selon la revendication 1.

   
8. 8. Document écrit dans un langage de balisage qui utilise un ensemble de caractères prédéterminés, ledit document étant destiné à être utilisé pour la mise en oeuvre d'un procédé de transfert d'objet selon la revendication 1, ledit document comprenant des éléments qui contiennent du contenu, et/ou un ou plusieurs attributs, et/ou un ou plusieurs sous-éléments, et ledit document décrivant un fichier binaire qui contient des données binaires, des marqueurs et des paramètres associés à un ou plusieurs marqueurs, caractérisé en ce que, dans ledit document, un élément est associé à chaque marqueur, les éventuels paramètres associés audit marqueur constituant un sous-élément ou un attribut dudit élément, le contenu d'un ou plusieurs éléments étant constitué par des caractères dudit ensemble liés aux dites données binaires.
9. 9. Document selon la revendication 8, caractérisé en ce qu'une partie au moins du contenu dudit document correspondant à des données binaires dudit fichier binaire, converties en caractères dudit ensemble.
10. 10. Document selon la revendication 8, caractérisé en ce qu'une partie au moins du contenu dudit document correspond à un ou plusieurs pointeur (s) vers lesdites données binaires dans ledit fichier binaire.