xml2dcm: Convertir un document XML en fichier DICOM ou en jeu de données

SYNOPSIS

xml2dcm [options] xmlfile-in dcmfile-out

DESCRIPTION

xml2dcm est un utilitaire qui convertit le contenu d'un document XML (Extensible Markup Language) en fichier DICOM ou en jeu de données. Le document XML est censé être conforme à la DTD (Document Type Definition) décrite dans le fichier dcm2xml.dtd. Un fichier XML approprié peut être créé à l'aide de l'outil dcm2xml (l'option +Wb est recommandée pour inclure les données binaires).

PARAMÈTRES

xmlfile-in   XML input filename to be converted ("-" for stdin)

dcmfile-out  DICOM output filename ("-" for stdout)

OPTIONS

options générales

-h --help: affiche cette aide et quitte
--version: affiche les informations de version et quitte
--arguments: affiche les arguments de ligne de commande développés
-q --quiet: mode silencieux, n'affiche ni avertissements ni erreurs
-v --verbose: mode détaillé, affiche les détails du traitement
-d --debug: mode débogage, affiche les informations de débogage
-ll --log-level [l]evel: string constant: (fatal, error, warn, info, debug, trace) utilise le niveau l pour la journalisation
-lc --log-config [f]ilename: string: utilise le fichier de configuration f pour le journal

options d'entrée

+f --read-meta-info: lit les informations de méta-fichier si présentes (par défaut)
-f --ignore-meta-info: ignore les informations de méta-fichier

options de traitement

+Vd --validate-document: valide le document XML par rapport à la DTD
+Vn --check-namespace: vérifie l'espace de noms XML de la racine du document identifiants uniques :
+Ug --generate-new-uids: génère un nouveau Study/Series/SOP Instance UID
-Uo --dont-overwrite-uids: n'écrase pas les UID existants (par défaut)
+Uo --overwrite-uids: écrase les UID existants

options de sortie

+F --write-file: écrit au format de fichier (par défaut)
-F --write-dataset: écrit le jeu de données sans informations de méta-fichier
+Fu --update-meta-info: met à jour certaines informations de méta-fichier syntaxe de transfert de sortie :
+t= --write-xfer-same: écrit avec la même TS que l'entrée (par défaut)
+te --write-xfer-little: écrit avec la TS explicit VR little endian
+tb --write-xfer-big: écrit avec la TS explicit VR big endian
+ti --write-xfer-implicit: écrit avec la TS implicit VR little endian
+td --write-xfer-deflated: écrit avec la TS explicit VR little endian deflate gestion des erreurs :
-E --stop-on-error: n'écrit pas si le document n'est pas valide (par défaut)
+E --ignore-errors: tente d'écrire même si le document n'est pas valide représentations de valeur postérieures à 1993 :
+u --enable-new-vr: active la prise en charge des nouvelles VR (UN/UT) (par défaut)
-u --disable-new-vr: désactive la prise en charge des nouvelles VR, convertit en OB encodage de longueur de groupe :
+g= --group-length-recalc: recalcule les longueurs de groupe si elles sont présentes (par défaut)
+g --group-length-create: écrit toujours avec les éléments de longueur de groupe
-g --group-length-remove: écrit toujours sans les éléments de longueur de groupe encodage de longueur dans les séquences et les items :
+e --length-explicit: écrit avec des longueurs explicites (par défaut)
-e --length-undefined: écrit avec des longueurs non définies remplissage final du jeu de données (pas avec --write-dataset) :
-p= --padding-retain: ne modifie pas le remplissage (par défaut si --write-dataset n'est pas utilisé)
-p --padding-off: aucun remplissage (implicite avec --write-dataset)
+p --padding-create [f]ile-pad [i]tem-pad: integer: aligne le fichier sur un multiple de f octets et les items sur un multiple de i octets niveau de compression deflate (seulement avec --write-xfer-deflated) :
+cl --compression-level [l]evel: integer (default: 6): 0=non compressé, 1=le plus rapide, 9=meilleure compression

NOTES

La structure de base de l'entrée XML attendue se présente comme suit :

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE file-format SYSTEM "dcm2xml.dtd">
<file-format xmlns="http://dicom.offis.de/dcmtk">
  <meta-header xfer="1.2.840.10008.1.2.1" name="Little Endian Explicit">
    <element tag="0002,0000" vr="UL" vm="1" len="4"
             name="MetaElementGroupLength">
      166
    </element>
    ...
    <element tag="0002,0013" vr="SH" vm="1" len="16"
             name="ImplementationVersionName">
      OFFIS_DCMTK_353
    </element>
  </meta-header>
  <data-set xfer="1.2.840.10008.1.2" name="Little Endian Implicit">
    <element tag="0008,0005" vr="CS" vm="1" len="10"
             name="SpecificCharacterSet">
      ISO_IR 100
    </element>
    ...
    <sequence tag="0028,3010" vr="SQ" card="2" name="VOILUTSequence">
      <item card="3">
        <element tag="0028,3002" vr="xs" vm="3" len="6"
                 name="LUTDescriptor">
          256\0\8
        </element>
        ...
      </item>
      ...
    </sequence>
    ...
    <element tag="7fe0,0010" vr="OW" vm="1" len="262144"
             name="PixelData" loaded="no" binary="hidden">
    </element>
  </data-set>
</file-format>

Les balises "file-format" et "meta-header" peuvent être absentes pour les jeux de données DICOM.

Encodage des caractères

L'encodage de caractères DICOM est déterminé automatiquement à partir de l'élément portant le tag "0008,0005" (Specific Character Set), s'il est présent. Les jeux de caractères suivants sont actuellement pris en charge (nécessite que libxml inclue la prise en charge d'iconv, voir la sortie de l'option –version) :

ASCII         (ISO_IR 6)    (UTF-8)
UTF-8         "ISO_IR 192"  (UTF-8)
ISO Latin 1   "ISO_IR 100"  (ISO-8859-1)
ISO Latin 2   "ISO_IR 101"  (ISO-8859-2)
ISO Latin 3   "ISO_IR 109"  (ISO-8859-3)
ISO Latin 4   "ISO_IR 110"  (ISO-8859-4)
ISO Latin 5   "ISO_IR 148"  (ISO-8859-9)
ISO Latin 9   "ISO_IR 203"  (ISO-8859-15)
Cyrillic      "ISO_IR 144"  (ISO-8859-5)
Arabic        "ISO_IR 127"  (ISO-8859-6)
Greek         "ISO_IR 126"  (ISO-8859-7)
Hebrew        "ISO_IR 138"  (ISO-8859-8)

Plusieurs jeux de caractères ne sont pas pris en charge (en cas de multiplicité de valeur, seule la première valeur de "Specific Character Set" est utilisée pour l'encodage de caractères).

Pour plus de détails sur la structure XML, consultez la documentation de dcm2xml.

Données binaires

Les données binaires (*) peuvent être encodées soit sous la forme d'une suite de nombres hexadécimaux séparés par une barre oblique inverse "\", soit au format Base64 (binary="base64"). Il est également possible de lire les données binaires depuis un fichier (binary="file"). Dans ce cas, le nom de fichier doit être spécifié comme valeur de l'élément, par exemple :

<element tag="7fe0,0010" vr="OW" ... binary="file">subdir/pixeldata.raw</element>

Notez que le contenu du fichier est lu tel quel. Les données OW sont supposées être ordonnées en little endian et leurs octets seront permutés si nécessaire. Aucune vérification n'est effectuée pour s'assurer que la quantité de données est raisonnable au regard d'autres attributs tels que Rows ou Columns.

(*) Notez qu'actuellement seules les données OB et OW sont prises en charge, c'est-à-dire que les valeurs d'éléments avec un VR de OD, OF, OL et OV ne sont pas considérées comme des "données binaires" et sont traitées comme tous les autres VR.

Compression

Si libxml est compilé avec la prise en charge de zlib, le fichier d'entrée (xmlfile-in) peut également être compressé au format ZIP, ce qui permet généralement d'obtenir des fichiers nettement plus petits. Consultez la sortie de l'option –version pour vérifier si la prise en charge de zlib est disponible.

Limitations

Selon la version de libxml, la longueur maximale autorisée pour une valeur d'élément XML peut varier. Il convient donc d'éviter d'utiliser des valeurs d'éléments très longues (par exemple pour les données de pixels).

Notez que xml2dcm ne prend actuellement pas entièrement en charge les fichiers DICOMDIR. Plus précisément, la valeur des différents éléments de données de décalage n'est pas mise à jour automatiquement par cet outil.

JOURNALISATION

Le niveau de détail de la journalisation des différents outils en ligne de commande et des bibliothèques sous-jacentes peut être spécifié par l'utilisateur. Par défaut, seules les erreurs et les avertissements sont écrits dans le flux d'erreur standard. L'option –verbose permet également de signaler des messages d'information tels que les détails du traitement. L'option –debug permet d'obtenir plus de détails sur l'activité interne, par exemple à des fins de débogage. L'option –log-level permet de sélectionner d'autres niveaux de journalisation. En mode –quiet, seules les erreurs fatales sont signalées. Dans de tels cas d'erreur très graves, l'application se termine généralement. Pour plus de détails sur les différents niveaux de journalisation, consultez la documentation du module "oflog".

Si la sortie de la journalisation doit être écrite dans un fichier (éventuellement avec rotation des fichiers journaux), vers syslog (Unix) ou le journal des événements (Windows), l'option –log-config peut être utilisée. Ce fichier de configuration permet également de diriger uniquement certains messages vers un flux de sortie particulier et de filtrer certains messages en fonction du module ou de l'application qui les génère. Un exemple de fichier de configuration est fourni dans < etcdir>/logger.cfg.

LIGNE DE COMMANDE

Tous les outils en ligne de commande utilisent la notation suivante pour les paramètres : les crochets entourent les valeurs facultatives (0-1), trois points de suspension à la fin indiquent que plusieurs valeurs sont autorisées (1-n), et la combinaison des deux signifie de 0 à n valeurs.

Les options de la ligne de commande se distinguent des paramètres par un signe '+' ou '-' en tête. En général, l'ordre et la position des options de la ligne de commande sont arbitraires (c'est-à-dire qu'elles peuvent apparaître n'importe où). Toutefois, si des options s'excluent mutuellement, c'est la dernière occurrence, la plus à droite, qui est utilisée. Ce comportement est conforme aux règles d'évaluation standard des shells Unix courants.

De plus, un ou plusieurs fichiers de commandes peuvent être spécifiés en utilisant un signe '@' comme préfixe du nom de fichier (par exemple @command.txt). Un tel argument de commande est remplacé par le contenu du fichier texte correspondant (les espaces multiples sont traités comme un séparateur unique, sauf s'ils apparaissent entre deux guillemets) avant toute évaluation ultérieure. Notez qu'un fichier de commandes ne peut pas contenir un autre fichier de commandes. Cette approche simple mais efficace permet de regrouper des combinaisons courantes d'options/paramètres et évite des lignes de commande longues et peu lisibles (un exemple est fourni dans le fichier < datadir>/dumppat.txt).

ENVIRONNEMENT

L'utilitaire xml2dcm tentera de charger les dictionnaires de données DICOM spécifiés dans la variable d'environnement DCMDICTPATH. Par défaut, c'est-à-dire si la variable d'environnement DCMDICTPATH n'est pas définie, le fichier < datadir>/dicom.dic sera chargé, à moins que le dictionnaire ne soit intégré à l'application (par défaut sous Windows).

Il est préférable de conserver le comportement par défaut et de n'utiliser la variable d'environnement DCMDICTPATH que lorsque des dictionnaires de données alternatifs sont nécessaires. La variable d'environnement DCMDICTPATH a le même format que la variable PATH des shells Unix, en ce sens que les deux-points (":") séparent les entrées. Sur les systèmes Windows, le point-virgule (";") est utilisé comme séparateur. Le code du dictionnaire de données tente de charger chaque fichier spécifié dans la variable d'environnement DCMDICTPATH. C'est une erreur si aucun dictionnaire de données ne peut être chargé.