img2dcm: convertir des formats d'image standard au format DICOM

SYNOPSIS

img2dcm [options] imgfile-in... dcmfile-out

DESCRIPTION

img2dcm est un outil de conversion d'un format d'image standard tel que JPEG (y compris JPEG-LS) ou BMP vers DICOM. Différentes SOP Class de sortie peuvent être sélectionnées. Les informations complémentaires (concernant le patient, la série, etc.) stockées dans le fichier DICOM de sortie peuvent être extraites d'autres fichiers DICOM servant de « modèle » pour l'objet DICOM résultant. img2dcm peut également être configuré pour inventer les attributs DICOM de type 1 et de type 2 manquants, afin de fonctionner même sans aucun jeu de données modèle.

PARAMÈTRES

imgfile-in   image 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

-i --input-format [i]nput file format: string: formats pris en charge : JPEG (par défaut), BMP
-df --dataset-from [f]ilename: string: utilise le jeu de données du fichier DICOM f
-dx --dataset-from-xml [f]ilename: string: utilise le jeu de données du fichier XML f
-stf --study-from [f]ilename: string: lit le patient/l'étude à partir du fichier DICOM f
-sef --series-from [f]ilename: string: lit le patient/l'étude/la série à partir du fichier DICOM f
-ii --instance-inc: augmente le numéro d'instance lu depuis le fichier DICOM JPEG format:
-dp --disable-progr: désactive la prise en charge du JPEG progressif
-de --disable-ext: désactive la prise en charge du JPEG séquentiel étendu
-jf --insist-on-jfif: exige la présence d'un en-tête JFIF
-ka --keep-appn: conserve les sections APPn (sauf JFIF)
-rc --remove-com: supprime le segment COM XML validation:
+Vd --validate-document: valide le document XML par rapport à la DTD
+Vn --check-namespace: vérifie l'espace de noms XML dans la racine du document

options de traitement

--do-checks: active la vérification de validité des attributs (par défaut)
--no-checks: désactive la vérification de validité des attributs
+i2 --insert-type2: insère les attributs de type 2 manquants (par défaut) (only with --do-checks)
-i2 --no-type2-insert: n'insère pas les attributs de type 2 manquants (only with --do-checks)
+i1 --invent-type1: invente les attributs de type 1 manquants (par défaut) (only with --do-checks)
-i1 --no-type1-invent: n'invente pas les attributs de type 1 manquants (only with --do-checks) character set conversion of study/series file:
-Ct --transliterate: tente d'approcher les caractères non représentables par des caractères d'apparence similaire
-Cd --discard-illegal: élimine les caractères non représentables dans le jeu de caractères de destination other processing options:
-k --key [k]ey: gggg,eeee="str", path or dictionary name="str": ajoute un attribut supplémentaire

options de sortie

-sc --sec-capture: écrit la SOP class Secondary Capture (par défaut)
-nsc --new-sc: écrit les nouvelles SOP class Secondary Capture
-vlp --vl-photo: écrit la SOP class Visible Light Photographic
-oph --oph-photo: écrit les SOP class Ophthalmic Photography output file format:
+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 group length encoding:
+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 length encoding in sequences and items:
+e --length-explicit: écrit avec des longueurs explicites (par défaut)
-e --length-undefined: écrit avec des longueurs non définies data set trailing padding (not with --write-dataset):
-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

NOTES

Sources des attributs

Pour la conversion d'un format d'image général au format DICOM, l'application img2dcm peut recevoir des informations supplémentaires pour remplir les attributs obligatoires (et facultatifs) du nouveau fichier DICOM, comme les données de patient, d'étude et de série. Ces informations peuvent être rassemblées selon différentes approches, qui peuvent être combinées et sont appliquées au fichier résultant dans l'ordre suivant :

Avec l'option –dataset-from, img2dcm est contraint d'importer les attributs d'un fichier DICOM existant. Le fichier DICOM indiqué est importé intégralement et sert de base à toutes les opérations d'export ultérieures. Par exception, le SOP Instance UID n'est pas copié par cette option. De même, les données liées à l'image comme Rows, Columns, etc. sont remplacées lors de la conversion. Notez que img2dcm ne vérifie la validité d'aucun autre attribut, par exemple il ne consulte pas l'intérieur des séquences pour adapter certains attributs au nouvel objet (images référencées, etc.). Il est donc recommandé d'utiliser les modèles du répertoire data pour les anciens objets SC et VLP. Voir aussi la section « Modèles d'entrée ». En alternative à l'option –dataset-from, l'option mutuellement exclusive –dataset-from-xml peut être utilisée. Dans ce cas, cependant, le fichier doit contenir des données XML au format produit par dcm2xml.
Les options –study-from et –series-from permettent d'importer les informations de patient, d'étude et de série depuis un fichier DICOM existant. Si –series-from est spécifiée, le fichier DICOM indiqué est ouvert par img2dcm et toutes les informations obligatoires jusqu'au niveau série sont importées. Notez que cela inclut les informations de patient, d'étude et de série. Dans le cas de –study-from, les informations de série sont exclues. Il est tout à fait pertinent d'utiliser –study-from et –series-from en même temps. Si les deux options sont fournies sur la ligne de commande, l'option la plus à droite l'emporte. Les attributs suivants sont repris :
```
Patient Level:
        Patient's Name
        Patient ID
        Patient's Sex
        Patient's Birth Date
        Specific Character Set

      Study Level:
        Study Instance UID
        Study Date
        Study Time
        Referring Physician's Name
        Study ID
        Accession Number

      Series Level (only in case of option --series-from):
        Series Instance UID
        Series Number
        Manufacturer
```
Avec les options –insert-type2 et –invent-type1 (toutes deux activées par défaut), les attributs manquants (attributs de type 2) et/ou les valeurs d'attribut manquantes (pour les attributs de type 1) sont automatiquement ajoutés et inventés par img2dcm. Notez que ces options ne sont évaluées que si l'option –do-checks est activée (par défaut). Si l'option –no-checks est activée, aucune insertion automatique d'attribut n'a lieu.
L'option –key permet d'ajouter des attributs supplémentaires au fichier DICOM de sortie. Il est également possible de spécifier des séquences, des items et des attributs imbriqués avec l'option –key. Dans ces cas, une notation de « chemin » spéciale doit être utilisée. Les détails de cette notation de chemin figurent dans la documentation de dcmodify. L'option –key peut être présente plusieurs fois. La partie valeur (après le '=') peut être absente, ce qui règle alors l'attribut avec une longueur nulle. Sachez que l'option –key est appliquée tout à la fin, juste avant l'enregistrement du fichier DICOM, si bien qu'aucune vérification de valeur n'a lieu.

UID

De nouveaux Study Instance UID et Series Instance UID sont générés si nécessaire après application des options –study-from et –series-from. Si le Study Instance UID ou le Series Instance UID sont absents à l'issue de ces étapes, ils sont générés à nouveau, indépendamment l'un de l'autre.

Un comportement contraire est retenu pour le SOP Instance UID, dont on pourrait s'attendre à ce qu'il soit repris avec l'option –dataset-from ou –dataset-from-xml. Ce n'est pas le cas, le SOP Instance UID n'est pas copié dans le nouvel objet. Cela devrait être le comportement souhaitable dans la plupart des cas d'usage. Cependant, si un SOP Instance UID particulier doit être inséré dans le nouvel objet, l'option –key doit être utilisée.

Modèles d'entrée

Pour faciliter la conversion vers DICOM, img2dcm est fourni avec quelques modèles prédéfinis utilisables avec l'option –dataset-from (voir les fichiers d'exemple SC.dump et VLP.dump). Ces modèles doivent être remplis avec les valeurs souhaitées, puis convertis (dump) en fichier DICOM avant d'être réellement utilisés avec img2dcm. Utilisez dump2dcm pour convertir le dump en DICOM. Exemple :

  dump2dcm SC.dump SC.dcm

Pour les images Ophthalmic Photography, des modèles XML sont fournis (voir les fichiers d'exemple OP_template_utf_8.xml et OP_template_latin_1.xml).

Il est possible d'utiliser n'importe quel fichier DICOM comme modèle. Notez que le jeu de données DICOM complet est importé ; il convient donc de s'assurer que seuls les attributs devant faire partie de l'objet DICOM construit sont présents. Le SOP Class UID et les attributs Pixel Data (y compris des attributs comme Rows, Columns, etc.) ne sont pas copiés mais remplacés par img2dcm lors de la conversion.

Images multiframe

Il est possible de convertir plusieurs fichiers d'entrée en une seule image DICOM multiframe si la SOP class DICOM choisie prend en charge le multiframe. En particulier, les Multi-frame Secondary Capture SOP Class prennent en charge cette fonctionnalité. Elles sont sélectionnées via l'option de ligne de commande –new-sc.

Jeux de caractères

Lorsqu'un modèle d'entrée est chargé avec –dataset-from ou –dataset-from-xml, le specific character set de ce modèle est utilisé pour le fichier DICOM généré. Si les options –study-from ou –series-from sont également utilisées, img2dcm tentera de convertir le jeu de caractères de ces attributs vers celui du modèle, et signalera une erreur si cela n'est pas possible.

Si les options –study-from ou –series-from sont utilisées sans modèle, le specific character set de cette source est utilisé pour le fichier DICOM généré. Toute clé spécifiée sur la ligne de commande avec l'option –key est traitée comme des octets bruts et remplace tout attribut déjà présent en raison d'un modèle ou d'un fichier study/series. Il convient donc de veiller à ne pas spécifier de specific character set sur la ligne de commande si un tel attribut risque d'être chargé depuis un autre fichier. Il incombe également à l'utilisateur de s'assurer que les valeurs d'attribut spécifiées sur la ligne de commande utilisent le bon encodage, car aucune conversion n'a lieu avant que les valeurs ne soient stockées dans le fichier DICOM.

Plugins d'entrée

L'application img2dcm prend actuellement en charge les formats d'image JPEG, JPEG-LS et BMP en entrée.

Plugin d'entrée JPEG

Pour JPEG, le flux JPEG d'origine du fichier source n'est pas décodé mais extrait et légèrement transformé (par exemple l'en-tête JFIF est retiré), ce qui permet une conversion rapide même des gros fichiers JPEG sans avoir besoin de décoder puis de réencoder. Le plugin JPEG choisit automatiquement la transfer syntax de sortie nécessaire en fonction de l'encodage réel des données à l'intérieur du fichier JPEG. Les transfer syntax suivantes (et les encodages JPEG correspondants) sont donc utilisées par le plugin JPEG :

JPEG Coding Process 1
Baseline, Lossy, Non-Hierarchical, Sequential, DCT, Huffman, 8 Bit
Transfer Syntax UID = 1.2.840.10008.1.2.4.50
JPEG Coding Process 2 (8-bit) and 4 (12-bit)
Extended, Lossy, Non-Hierarchical, Sequential, DCT, Huffman, 8/12 Bit
Transfer Syntax UID = 1.2.840.10008.1.2.4.51
JPEG Coding Process 10 (8-bit) and 12 (12-bit)
Full Progression, lossy, Non-Hierarch., Progressive, DCT, Huffman, 8/12 Bit
Transfer Syntax UID = 1.2.840.10008.1.2.4.55

Les images couleur et en niveaux de gris sont prises en charge.

La prise en charge de la Extended JPEG Transfer Syntax peut être désactivée (option –disable-ext), tout comme celle de la Progressive JPEG Transfer Syntax (retirée) (option –disable-progr).

L'encodage JPEG sans perte, ainsi que tout mode d'encodage JPEG arithmétique ou hiérarchique, ne sont pas pris en charge par le plugin.

Les informations JFIF (JPEG File Interchange Format) exploitent les marqueurs APPn optionnels d'un fichier JPEG. De nombreux appareils photo numériques n'intègrent pas ces informations JFIF dans le flux JPEG qu'ils produisent. Par exemple, JFIF contient des informations sur le rapport d'aspect des pixels de l'image compressée. Si vous souhaitez que l'application img2dcm exige un en-tête JFIF dans le flux JPEG, vous pouvez utiliser l'option –insist-on-jfif, qui interrompra le traitement si aucune information JFIF n'est trouvée. Par défaut, l'absence d'information JFIF est ignorée.

Pour DICOM, l'intégration des données JFIF (ou de tout autre APPn) dans le flux JPEG interne de l'objet DICOM relève d'une sorte de « zone grise ». Cependant, l'approche la plus fiable consiste à retirer ces marqueurs et leurs informations du flux JPEG. C'est également l'approche retenue par l'application img2dcm. Par défaut, tous les marqueurs APPn sont retirés du flux JPEG d'origine. Cependant, si vous souhaitez conserver d'autres marqueurs APPn que JFIF (par exemple les informations EXIF) dans le flux DICOM, l'option –keep-appn fait l'affaire. Elle devrait également être légèrement plus rapide que le retrait des informations APPn, car il n'est pas nécessaire de parcourir tout le flux JPEG à la recherche de telles données. Comme indiqué précédemment, les informations JFIF sont toujours supprimées par img2dcm. Cependant, avec cette option, le marqueur APP2 est conservé, mais img2dcm ne crée pas d'attribut ICC Profile (0028,2000) équivalent.

Plugin d'entrée JPEG-LS

Le plugin JPEG-LS a été intégré directement au plugin JPEG principal. L'utilisateur n'a pas besoin d'indiquer explicitement à l'avance si l'entrée est du JPEG ou du JPEG-LS.

Pour JPEG-LS, le flux JPEG-LS d'origine du fichier source n'est pas décodé mais extrait et légèrement transformé (par exemple le marqueur APP8 est retiré), ce qui permet une conversion rapide même des gros fichiers JPEG-LS sans avoir besoin de décoder puis de réencoder.

Le plugin JPEG-LS choisit automatiquement la transfer syntax de sortie nécessaire en fonction de l'encodage réel des données à l'intérieur du fichier JPEG-LS. Les transfer syntax suivantes (et les encodages JPEG-LS correspondants) sont donc utilisées par le plugin JPEG-LS :

JPEG-LS Lossless Image Compression
Transfer Syntax UID = 1.2.840.10008.1.2.4.80
JPEG-LS Lossy (Near-Lossless) Image Compression
Transfer Syntax UID = 1.2.840.10008.1.2.4.81

Les images couleur et en niveaux de gris sont prises en charge. La CP-1843 impose que la valeur de Planar Configuration (0028,0006) soit sans importance, car la manière d'encoder les composants (entrelacement par composant, par ligne ou par échantillon) est spécifiée dans le bitstream JPEG-LS ; elle doit donc être réglée sur 0. Aucune transformation colorimétrique spécifique à JPEG-LS n'étant actuellement définie dans DICOM, le flux JPEG-LS est supposé être encodé dans l'espace colorimétrique RGB.

Pour DICOM, il est clair que l'en-tête SPIFF ne doit pas être présent dans le flux JPEG-LS interne de l'objet DICOM. Le plugin rejette simplement tout fichier JPEG-LS d'entrée contenant un en-tête SPIFF au marqueur APP8.

Par défaut, tous les marqueurs APPn sont retirés du flux JPEG-LS d'origine. Cependant, si vous souhaitez conserver des marqueurs APPn (par exemple les informations de transformation colorimétrique APP8/HP, dites « mrfx ») dans le flux DICOM, l'option –keep-appn fait l'affaire. Notez que le plugin vérifie la transformation colorimétrique réelle spécifiée dans le marqueur APP8/HP. DICOM n'autorisant aucune transformation colorimétrique spécifiée dans le marqueur APP8, seule la valeur 0 (aucune transformation colorimétrique) est acceptée.

Plugin d'entrée BMP

img2dcm prend en charge le format BMP en entrée. Cependant, seules les images BMP les plus courantes sont prises en charge à ce jour. En particulier, les images BMP utilisant des champs de bits ou un encodage par plages (run length encoding) sont rejetées. De telles images sont rares. Les images d'entrée sont converties soit en une image DICOM avec un modèle colorimétrique RGB et une profondeur de 24 bits, soit en une image avec un modèle colorimétrique MONOCHROME2 à 8 bits par pixel. Il n'existe pas d'options spécifiques pour affiner la conversion du format BMP.

Plugins de sortie

La SOP class de sortie souhaitée peut être sélectionnée sur la ligne de commande. Actuellement, des plugins d'export sont disponibles pour la Secondary Capture Image SOP Class (par défaut, option -sc), les Multi-frame Secondary Capture Image SOP Class (option -nsc), la Visible Light Photographic Image SOP Class (option -vl) et les Ophthalmic Photography Image SOP Class (option -oph). Notez que la première est obsolète selon la norme DICOM, mais qu'elle est retenue par défaut car largement prise en charge. Les futures versions de img2dcm pourraient fournir d'autres plugins d'export pour d'autres SOP Class.

Pour les nouvelles Secondary Capture SOP Class, il n'est pas possible de spécifier la SOP Class précise à utiliser en sortie. En effet, ces nouvelles SOP class se distinguent les unes des autres par la profondeur de couleur (1/8/16) et le fait que l'image soit en noir et blanc ou en couleur. C'est pourquoi img2dcm décide, lors de la conversion, quelle SOP Class de sortie convient à une image source donnée.

EXEMPLES

Voici quelques exemples illustrant l'utilisation de l'application img2dcm.

img2dcm image.jpg out.dcm
Lit le fichier JPEG "image.jpg", le convertit vers l'ancienne Secondary Capture SOP Class et enregistre le résultat dans le fichier DICOM "out.dcm". C'est la façon la plus simple d'utiliser img2dcm. Tous les attributs de type 1 et de type 2 requis pour écrire des objets valides de cette SOP Class sont insérés automatiquement.
img2dcm -i BMP image.bmp out.dcm
Identique à ci-dessus, mais indique à img2dcm de lire un fichier BMP au lieu d'un JPEG.
img2dcm image.jpg out.dcm -vlp -k "PatientName=Bond^James"
Identique au premier exemple, mais écrit un objet Visible Light Photographic Image dans "out.dcm" et règle PatientName à "Bond^James", qui resterait vide autrement.
img2dcm image.jpg out.dcm –series-from template.dcm -k "PatientName=Bond^James"
Identique à 1), mais importe les informations de patient/étude/série du fichier DICOM "template.dcm". Notez que l'attribut PatientName contiendra finalement "Bond^James" : toute valeur venant de "template.dcm" sera écrasée. C'est parce que l'option -k est appliquée tout à la fin du pipeline de conversion (voir ci-dessus).
img2dcm image.jpg out.dcm –no-checks
Identique à 1), mais n'effectue aucune vérification d'attribut ni aucune insertion d'attribut de type 1 et de type 2 ! Dans ce cas, un objet DICOM invalide serait donc généré. Cela peut être utile si le fichier de sortie n'est pas destiné à être complet mais va subir des transformations supplémentaires, par exemple l'ajout d'attributs avec dcmodify. N'utilisez l'option –no-checks que si vous savez ce que vous faites !
img2dcm image.jpg out.dcm –no-type1-invent
Identique à 1), mais n'insère pas les attributs de type 1 manquants ni leurs valeurs. Les attributs de type 2 seront insérés. Notez que dans ce cas, il faut s'assurer que tous les attributs de type 1 sont fournis par un autre moyen, c'est-à-dire en les ajoutant avec l'option –key. Sinon, img2dcm signalera une erreur et arrêtera la conversion.
img2dcm image.jpg out.dcm –keep-appn –insist-on-jfif
Identique à 1), mais reprend les informations APPn telles que EXIF dans le flux JPEG résultant de l'objet DICOM. De plus, –insist-on-jfif forcera img2dcm à s'interrompre si aucune information JFIF n'existe dans le fichier source.
img2dcm image1.jpg image2.jpg out.dcm –new-sc
Lit les fichiers JPEG "image1.jpg" et "image2.jpg", les convertit en une image multiframe de la Multi-frame Secondary Capture SOP Class appropriée, et enregistre le résultat dans le fichier DICOM "out.dcm".

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 img2dcm 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é.

FICHIERS

< datadir>/SC.dump - Exemple de fichier dump pour les images Secondary Capture
< datadir>/VLP.dump - Exemple de fichier dump pour les images Visible Light Photographic
< datadir>/OP_template.xml - Exemple de modèle XML pour les images Ophthalmic Photography

VOIR AUSSI

dcm2pnm(1), dcmj2pnm(1), dump2dcm(1), dcmconv(1), dcmodify(1), dcm2xml(1)