dcm2xml - En ligne dans le Cloud

PROGRAMME:

Nom

dcm2xml - Convertir le fichier DICOM et l'ensemble de données en XML

SYNOPSIS

dcm2xml [options] dcmfile-in [xmlfile-out]

DESCRIPTION

Les dcm2xml l'utilitaire convertit le contenu d'un fichier DICOM (format de fichier ou ensemble de données brutes) en
XML (langage de balisage extensible). Il existe deux formats de sortie. Le premier est spécifique
à DCMTK avec sa DTD (Document Type Definition) décrite dans le fichier dcm2xml.dtdL’
le second fait référence au « modèle DICOM natif » qui est spécifié pour l'application DICOM
Service d'hébergement trouvé dans DICOM partie 19.

If dcm2xml lit un ensemble de données brutes (données DICOM sans méta-en-tête de format de fichier)
essayez de deviner la syntaxe du transfert en examinant les premiers octets du fichier. Il est
pas toujours possible de deviner correctement la syntaxe de transfert et il vaut mieux convertir un
dans la mesure du possible dans un format de fichier (en utilisant le dcmconv utilitaire). C'est aussi
possible d'utiliser le -f ainsi que le -t[ieb] possibilité de forcer dcm2xml lire un ensemble de données avec un
syntaxe de transfert particulière.

PARAMETRES

dcmfile-in nom du fichier d'entrée DICOM à convertir

xmlfile-out Nom du fichier de sortie XML (par défaut : stdout)

OPTIONS

général Options
-h --aide
imprimer ce texte d'aide et quitter

--version
imprimer les informations sur la version et quitter

--arguments
imprimer les arguments de ligne de commande étendus

-q --silencieux
mode silencieux, n'imprime aucun avertissement ni erreur

-v --verbeux
mode verbeux, détails de traitement d'impression

-d --débogage
mode de débogage, imprimer les informations de débogage

-ll --log-level [l] niveau : chaîne constante
(fatal, erreur, avertissement, info, débogage, trace)
utiliser le niveau l pour l'enregistreur

-lc --log-config [fichier] nom de fichier : chaîne
utiliser le fichier de configuration f pour l'enregistreur

contribution Options
format de fichier d'entrée :

+f --read-fichier
lire le format de fichier ou l'ensemble de données (par défaut)

+fo --read-file-only
lire le format de fichier uniquement

-f --read-ensemble de données
lire l'ensemble de données sans les méta-informations du fichier

syntaxe de transfert d'entrée :

-t= --read-xfer-auto
utiliser la reconnaissance TS (par défaut)

-td --read-xfer-detect
ignorer le TS spécifié dans l'en-tête méta du fichier

-te --read-xfer-petit
lire avec VR explicite little endian TS

-tb --read-xfer-big
lire avec VR explicite big endian TS

-ti --read-xfer-implicite
lire avec VR implicite TS little endian

valeurs des balises longues :

+M --charger-tout
charger des valeurs de balises très longues (par exemple des données de pixels)

-M --load-short
ne charge pas de valeurs très longues (par défaut)

+R --max-read-length [k]octets : entier (4..4194302, par défaut : 4)
définir le seuil pour les valeurs longues à k ko

traitement Options
jeu de caractères spécifique :

+Cr --charset-require
exiger la déclaration du jeu de caractères étendu (par défaut)

+Ca --charset-assume [c]harset: chaîne
assumer le jeu de caractères c si aucun jeu de caractères étendu n'est déclaré

+Cc --charset-check-all
vérifier tous les éléments de données avec des valeurs de chaîne
(par défaut : uniquement PN, LO, LT, SH, ST et UT)

# cette option n'est utilisée que pour le mappage vers un
# Encodage de caractères XML, mais pas pour la conversion en UTF-8

+U8 --convertir-en-utf8
convertir toutes les valeurs d'élément qui sont affectées
par jeu de caractères spécifiques (0008,0005) à UTF-8

# nécessite le support de la boîte à outils libiconv

sortie Options
format XML général :

-dtk --dcmtk-format
sortie au format spécifique à DCMTK (par défaut)

-nat --format-natif
sortie au format Native DICOM Model (partie 19)

+Xn --use-xml-espace de noms
ajouter une déclaration d'espace de noms XML à l'élément racine

Format spécifique à DCMTK (pas avec --native-format) :

+Xd --add-dtd-référence
ajouter une référence à la définition de type de document (DTD)

+Xe --embed-dtd-content
incorporer la définition du type de document dans un document XML

+Xf --use-dtd-file [fichier] nom de fichier : chaîne
utiliser le fichier DTD spécifié (uniquement avec +Xe)
(par défaut : /usr/local/share/dcmtk/dcm2xml.dtd)

+Wn --écrire-nom-élément
écrire le nom des éléments de données DICOM (par défaut)

-Wn --no-element-name
ne pas écrire le nom des éléments de données DICOM

+Wb --write-binary-data
écrire les données binaires des éléments OB et OW
(par défaut : off, soyez prudent avec --load-all)

encodage de données binaires :

+Eh --encode-hex
coder les données binaires sous forme de nombres hexadécimaux
(par défaut pour le format spécifique à DCMTK)

+Eu --encode-uuid
encoder des données binaires en tant que référence UUID
(par défaut pour le modèle DICOM natif)

+Eb --encode-base64
coder les données binaires en Base64 (RFC 2045, MIME)

DCMTK Format

La structure de base de la sortie XML spécifique à DCMTK créée à partir d'un fichier DICOM ressemble à
ce qui suit:



<format de fichier xmlns="http://dicom.offis.de/dcmtk">

<element tag="0002,0000" vr="UL" vm="1" len="4"
name="MetaElementGroupLength">
166


<element tag="0002,0013" vr="SH" vm="1" len="16"
name="ImplementationVersionName">
OFFIS_DCMTK_353



<element tag="0008,0005" vr="CS" vm="1" len="10"
name="SpecificCharacterSet">
ISO_IR100




<element tag="0028,3002" vr="xs" vm="3" len="6"
name="LUTDescriptor">
256 \ 0 \ 8






<element tag="7fe0,0010" vr="OW" vm="1" len="262144"
name="PixelData" chargé="no" binary="hidden">




Les balises 'file-format' et 'meta-header' sont absentes pour les ensembles de données DICOM.

XML Codage
Les attributs avec des champs de valeur très volumineux (par exemple des données de pixels) ne sont pas chargés par défaut. Ils
peut être identifié par l'attribut supplémentaire 'loaded' avec une valeur de 'no' (voir exemple
dessus). L'option de ligne de commande --charger-tout oblige à charger tous les champs de valeur, y compris le
très longs.

De plus, les informations binaires des attributs OB et OW ne sont pas écrites dans la sortie XML
fichier par défaut. Ces éléments peuvent être identifiés par l'attribut supplémentaire 'binary'
avec une valeur de 'hidden' (la valeur par défaut est 'no'). L'option de ligne de commande --write-binary-data
provoque également l'impression des champs de valeur binaire (la valeur de l'attribut est 'yes' ou 'base64'). Mais,
soyez prudent lorsque vous utilisez cette option avec --charger-tout en raison des grandes quantités de
données de pixels qui pourraient être imprimées sur la sortie. Veuillez noter que dans cet élément de contexte
les valeurs avec un VR de OD ou OF ne sont pas considérées comme des « informations binaires ».

Plusieurs valeurs (c'est-à-dire où la multiplicité de la valeur DICOM est supérieure à 1) sont séparées
par une barre oblique inverse '\' (sauf pour les données encodées en Base64). L'attribut 'len' indique le
nombre d'octets pour le champ de valeur particulier tel qu'il est stocké dans l'ensemble de données DICOM, c'est-à-dire qu'il
peut s'écarter de la longueur de la valeur encodée XML, par exemple en raison d'un remplissage non significatif
qui a été supprimé. Si cet attribut est manquant dans les balises de début 'sequence' ou 'item',
l'élément DICOM correspondant a été stocké avec une longueur indéfinie.

Originaire DICOM Modèle Format

La description du format du modèle DICOM natif se trouve dans la norme DICOM, partie
19 (« Hébergement d'applications »).

Gros Volume Données
Données binaires, c'est-à-dire valeurs d'élément DICOM avec représentations de valeur (VR) d'OB ou d'OW, comme
ainsi que les valeurs OD, OF et UN ne sont pas écrites par défaut dans la sortie XML en raison de leur
Taille. Au lieu de cela, pour chaque élément, un nouvel identifiant unique universel (UUID) est en train d'être
généré et écrit comme un attribut d'un élément XML. Jusqu'à présent, il n'y a pas
possibilité d'écrire un fichier supplémentaire pour contenir les données binaires pour chacun des binaires
morceaux de données. Ceci n'est pas requis par la norme, cependant, cela peut être utile pour
la mise en place d'une interface d'hébergement d'applications ; cette fonctionnalité peut donc être disponible dans
futures versions de dcm2xml.

De plus, le supplément 163 (Store Over the Web by Representational State Transfer
Services) introduit un nouveau Élément XML qui permet d'encoder des données binaires
comme Base64. Actuellement, l'option de ligne de commande --encode-base64 permet cet encodage pour
les VR suivants : OB, OD, OF, OW et UN.

Connu Questions
En plus de ce qui est écrit dans la section ci-dessus sur les « données en vrac », il existe d'autres
problèmes connus avec l'implémentation actuelle du format de modèle DICOM natif. Pour
exemple, les grandes valeurs d'élément avec un VR autre que OB, OD, OF, OW ou UN sont actuellement
jamais écrit sous forme de données en vrac, bien que cela puisse être utile, par exemple pour des éléments de texte très longs
(surtout UT) ou des champs numériques très longs (de divers VR).

NOTES

Personnage Codage
L'encodage XML est déterminé automatiquement à partir de l'attribut DICOM (0008,0005)
« Jeu de caractères spécifiques » en utilisant le mappage suivant :

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"
Cyrillique "ISO_IR 144" => "ISO-8859-5"
Arabe "ISO_IR 127" => "ISO-8859-6"
Grec "ISO_IR 126" => "ISO-8859-7"
Hébreu "ISO_IR 138" => "ISO-8859-8"

Si cet attribut DICOM est manquant dans le fichier d'entrée, bien que nécessaire, l'option --jeu de caractères-
assumer peut être utilisé pour spécifier manuellement un jeu de caractères approprié (à l'aide de l'un des
termes définis par DICOM).

Les jeux de caractères multiples utilisant des techniques d'extension de code ne sont pas pris en charge. Si besoin,
option --convertir-en-utf8 peut être utilisé pour convertir le fichier DICOM ou l'ensemble de données en UTF-8
avant la conversion au format XML. Ceci est également utile pour les fichiers DICOMDIR
où chaque enregistrement de répertoire peut avoir un jeu de caractères différent.

Journalisation

Le niveau de sortie de journalisation des divers outils de ligne de commande et des bibliothèques sous-jacentes peut
être spécifié par l'utilisateur. Par défaut, seuls les erreurs et les avertissements sont écrits dans la norme
flux d'erreurs. Utilisation de l'option --verbeux également des messages d'information comme les détails du traitement
sont rapportés. Option --déboguer peut être utilisé pour obtenir plus de détails sur l'activité interne,
par exemple à des fins de débogage. D'autres niveaux de journalisation peuvent être sélectionnés à l'aide de l'option --Journal-
niveau. En --silencieux mode seules les erreurs fatales sont signalées. Dans des événements d'erreur aussi graves,
l'application se terminera généralement. Pour plus de détails sur les différents niveaux de journalisation,
voir la documentation du module 'oflog'.

Dans le cas où la sortie de journalisation doit être écrite dans un fichier (éventuellement avec rotation du fichier journal),
vers syslog (Unix) ou l'option du journal des événements (Windows) --log-config peut être utilisé. Cette
le fichier de configuration permet également de diriger uniquement certains messages vers une sortie particulière
flux et pour filtrer certains messages en fonction du module ou de l'application où ils
Sont générés. Un exemple de fichier de configuration est fourni dans /logger.cfg.

COMMAND LINE

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

Les options de ligne de commande se distinguent des paramètres par un signe '+' ou '-' en tête,
respectivement. Habituellement, l'ordre et la position des options de ligne de commande sont arbitraires (c'est-à-dire qu'ils
peut apparaître n'importe où). Cependant, si les options s'excluent mutuellement, l'apparence la plus à droite
est utilisé. 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 pour
le nom du fichier (par exemple @commande.txt). Un tel argument de commande est remplacé par le contenu de
le fichier texte correspondant (les espaces blancs multiples sont traités comme un seul séparateur sauf si
ils apparaissent entre deux guillemets) avant toute évaluation ultérieure. Veuillez noter que
un fichier de commandes ne peut pas contenir un autre fichier de commandes. Cette approche simple mais efficace
permet de résumer les combinaisons courantes d'options/paramètres et évite les
lignes de commande confuses (un exemple est fourni dans le fichier /dumppat.txt).

ENVIRONNEMENT

Les dcm2xml L'utilitaire tentera de charger les dictionnaires de données DICOM spécifiés dans le
Dcmdictpath variable d'environnement. Par défaut, c'est-à-dire si le Dcmdictpath variable d'environnement
n'est pas défini, le fichier /dicom.dic sera chargé à moins que le dictionnaire ne soit construit
dans l'application (par défaut pour Windows).

Le comportement par défaut doit être préféré et le Dcmdictpath variable d'environnement uniquement
utilisé lorsque des dictionnaires de données alternatifs sont nécessaires. Les Dcmdictpath variable d'environnement
a le même format que le shell Unix PATH variable en ce qu'un deux-points (':') sépare
entrées. Sur les systèmes Windows, un point-virgule (';') est utilisé comme séparateur. Le dictionnaire de données
le code tentera de charger chaque fichier spécifié dans le Dcmdictpath variable d'environnement. Ce
est une erreur si aucun dictionnaire de données ne peut être chargé.

Utilisez dcm2xml en ligne à l'aide des services onworks.net