dump2dcm: convertir un dump ASCII en fichier DICOM

SYNOPSIS

dump2dcm [options] dumpfile-in dcmfile-out

DESCRIPTION

dump2dcm est un utilitaire qui convertit un fichier de dump ASCII en fichier DICOM. Le fichier de dump a le même format que la sortie de dcmdump. Il est ainsi possible de capturer la sortie de dcmdump dans un fichier, de modifier certains attributs et de créer un nouveau fichier DICOM.

PARAMÈTRES

dumpfile-in  dump input filename

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 la journalisation

options d'entrée

+f --read-meta-info: lit les informations méta si présentes (par défaut)
-f --ignore-meta-info: ignore les informations méta du fichier. ordre des octets du contenu du fichier :
+rl --read-file-little: lit les données OW en little endian (par défaut)
+rb --read-file-big: lit les données OW du fichier en big endian. autres options d'entrée :
+l --line [m]ax-length: integer: longueur de ligne maximale m (par défaut : 4096)

options de traitement

+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 le format de fichier (par défaut)
-F --write-dataset: écrit le jeu de données sans les informations méta du fichier
+Fu --update-meta-info: met à jour certaines informations méta du 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 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 dump est endommagé (par défaut)
+E --ignore-errors: tente d'écrire même si le dump est endommagé. 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 la 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 la 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 de fin de jeu de données (absent 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 (uniquement avec --write-xfer-deflated) :
+cl --compression-level [l]evel: integer (default: 6): 0=non compressé, 1=le plus rapide, 9=meilleure compression

NOTES

Description du fichier de dump

Le fichier d'entrée peut être une sortie de dcmdump (uniquement au format indenté par défaut). Un élément (tag, VR, valeur) doit être écrit sur une seule ligne, ses parties étant séparées par un nombre quelconque d'espaces ou de tabulations. Un '#' commence un commentaire qui se termine à la fin de la ligne. Les lignes vides sont autorisées.

Les différentes parties d'une ligne suivent la syntaxe suivante :

Tag:   (gggg,eeee)
       with gggg and eeee are 4 character hexadecimal values
       representing group and element tag.  Spaces and tabs can be
       anywhere in a tag specification.
VR:    Value Representation must be written as 2 characters as in
       Part 6 of the DICOM standard.  No spaces or tabs are allowed
       between the two characters.  If the VR can be determined from
       the tag, this part of a line is optional.
Value: There are several rules for writing values:
       1. US, SS, UL, SL, UV, SV, FD, FL, OD, OF, OL and OV are written
          as decimal strings that can be read by scanf().
       2. AT is written as '(gggg,eeee)' with additional spaces
          stripped off automatically and gggg and eeee being decimal
          strings that can be read by scanf().
       3. OB and OW values are written as byte or word hexadecimal
          values separated by '\' character.  Alternatively, OB or OW
          values can be read from a separate file by writing the
          filename prefixed by a '=' character (e.g. '=largepix.dat').
          The contents of the file will be read as is.  By default, OW
          data is expected to be little endian ordered and will be
          swapped if necessary.  No checks will be made to ensure that
          the amount of data is reasonable in terms of other attributes
          such as Rows or Columns.
          In case of compressed pixel data, the line should start with
          '(7fe0,0010) OB (PixelSequence' in order to distinguish from
          uncompressed pixel data.
       4. UI is written as '=Name' in data dictionary or as unique
          identifier string (see 6.), e.g. '[1.2.840.....]'.
       5. Strings without () <> [] spaces, tabs and # can be written
          directly.
       6. Other strings must be surrounded by '[' and ']'.  No bracket
          structure is passed.  The value ends at the last ']' in the
          line.  Anything after the ']' is interpreted as comment.
       7. '(' and '<' are interpreted special and may not be used when
          writing an input file by hand as beginning characters of a
          string.  Multiple Value are separated by '\'.  The lines
          need not be sorted into ascending tag order.  References in
          DICOM Directories are not supported.  Semantic errors are
          not detected.

Exemples

Les lignes suivantes montrent des exemples valides de la syntaxe décrite ci-dessus :

 (0008,0020) DA [19921012]            #  8, 1 StudyDate
 (0008,0016) UI =MRImageStorage       # 26, 1 SOPClassUID
 (0002,0012) UI [1.2.276.0.7230010.100.1.1]
 (0020,0032) DS [0.0\0.0]             #  8, 2 ImagePositionPatient
 (0028,0009) AT (3004,000c)           #  4, 1 FrameIncrementPointer
 (0028,0010) US 256                   #  4, 1 Rows
 (0002,0001) OB 01\00

Limitations

Notez qu'à ce jour, dump2dcm ne prend pas encore totalement 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 dump2dcm tente 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 est chargé, sauf si le dictionnaire est 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é.

VOIR AUSSI

dcmdump(1)