⚠️ Ceci est un site de traduction non officiel, sans lien avec DCMTK / OFFIS. Pour des informations faisant autorité, consultez la page originale (https://support.dcmtk.org/docs/dcmencap.html).

dcmencap: encapsuler un document au format DICOM

SYNOPSIS

dcmencap [options] docfile-in dcmfile-out

DESCRIPTION

L'utilitaire dcmencap lit un fichier document dans l'un des formats de fichier pris en charge, le convertit en instance SOP de la classe SOP DICOM Encapsulated Storage correspondante et enregistre les données converties dans un fichier de sortie (dcmfile-out).

PARAMÈTRES

docfile-in   input filename to be converted

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 étendus
-q --quiet
mode silencieux, n'affiche ni avertissement ni erreur
-v --verbose
mode détaillé, affiche le détail 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

+fa --filetype-auto
détermine automatiquement le type de fichier (par défaut)
+fp --filetype-pdf
attend un fichier PDF
+fc --filetype-cda
attend un fichier CDA
+fs --filetype-stl
attend un fichier STL
+fm --filetype-mtl
attend un fichier MTL
+fo --filetype-obj
attend un fichier OBJ

options du document DICOM

+t --title [t]itle: string (default: empty)
titre du document
+cn --concept-name [CSD] [CV] [CM]: string (default: empty)
représentation codée du titre du document définie par le coding scheme designator CSD, la code value CV et la code meaning CM patient data:
+pn --patient-name [n]ame: string
nom du patient au format DICOM PN
+pi --patient-id [i]d: string
identifiant du patient
+pb --patient-birthdate [d]ate: string (YYYYMMDD)
date de naissance du patient
+ps --patient-sex [s]ex: string (M, F or O)
sexe du patient device data:
+mn --manufacturer [n]ame: string
nom du fabricant
+mm --manufacturer-model [n]ame: string
nom du modèle du fabricant
+ds --device-serial [n]umber: string
numéro de série de l'appareil
+sv --software-versions [v]ersions: string
versions du logiciel manufacturing 3d model data (STL/MTL/OBJ only):
+mu --measurement-units [CSD] [CV] [CM]: string
unités de mesure avec coding scheme designator CSD, code value CV et code meaning CM (par défaut : UCUM, um, um) study and series:
+sg --generate
génère de nouveaux UID de study et de series (par défaut)
+st --study-from [f]ilename: string
lit les données patient/study depuis un fichier DICOM
+se --series-from [f]ilename: string
lit les données patient/study/series depuis un fichier DICOM instance number:
+i1 --instance-one
utilise le numéro d'instance 1 (par défaut, incompatible avec +se)
+ii --instance-inc
incrémente le numéro d'instance (uniquement avec +se)
+is --instance-set [i]nstance number: integer
utilise le numéro d'instance i burned-in annotation:
+an --annotation-yes
le document contient des données identifiant le patient (par défaut)
-an --annotation-no
le document ne contient pas de données identifiant le patient

options de traitement

-ov --no-override
les données patient et document de la CDA doivent correspondre aux informations de study, de series ou saisies manuellement (par défaut)
+ov --override
les données de la CDA seront écrasées par les informations de study, de series ou saisies manuellement other processing options:
-k --key [k]ey: gggg,eeee="str", path or dictionary name="str"
ajoute un attribut supplémentaire

options de sortie

+te --write-xfer-little
écrit en explicit VR little endian (par défaut)
+tb --write-xfer-big
écrit en explicit VR big endian TS
+ti --write-xfer-implicit
écrit en implicit VR little endian TS group length encoding:
-g --group-length-remove
écrit sans éléments group length (par défaut)
+g --group-length-create
écrit avec des éléments group length length encoding in sequences and items:
+e --length-explicit
écrit avec des longueurs explicites (par défaut)
-e --length-undefined
écrit avec des longueurs indéfinies data set trailing padding (not with --write-dataset):
-p --padding-off
pas de remplissage (implicite si --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

L'application peut recevoir des informations supplémentaires pour renseigner les attributs obligatoires (et optionnels) du nouveau fichier DICOM, comme les informations de patient, de study et de series :

  • L'option –key permet d'ajouter des attributs supplémentaires au fichier DICOM de sortie.
  • Il est également possible de spécifier des sequences, des items et des attributs imbriqués à l'aide de l'option –key. Dans ce cas, une notation « chemin » spéciale doit être utilisée. Les détails de cette notation 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 fait que l'attribut est défini avec une longueur nulle.
  • Notez 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'est effectuée.

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).

CODES DE SORTIE

L'utilitaire dcmencap utilise les codes de sortie suivants à sa terminaison. Cela permet à l'utilisateur de vérifier la raison de la fin de l'application.

général

EXITCODE_NO_ERROR                 0

erreurs de fichier d'entrée

EXITCODE_INVALID_INPUT_FILE       22

erreurs de fichier de sortie

EXITCODE_CANNOT_WRITE_OUTPUT_FILE 40

ENVIRONNEMENT

L'utilitaire dcmencap tentera de charger les dictionnaires de données DICOM indiqué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é, sauf si le dictionnaire est intégré à l'application (comportement 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é.

Copyright (C) 2018-2025 by OFFIS e.V., Escherweg 2, 26121 Oldenburg, Germany.