dcmdjpeg: Décoder un fichier DICOM compressé en JPEG

SYNOPSIS

dcmdjpeg [options] dcmfile-in dcmfile-out

DESCRIPTION

dcmdjpeg est un utilitaire qui lit une image DICOM compressée en JPEG (dcmfile-in), décompresse les données JPEG (c'est-à-dire effectue une conversion vers une syntaxe de transfert DICOM native) et écrit l'image convertie dans un fichier de sortie (dcmfile-out).

PARAMÈTRES

dcmfile-in   DICOM 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-file: lit le format de fichier ou le jeu de données (par défaut)
+fo --read-file-only: lit uniquement le format de fichier
-f --read-dataset: lit un jeu de données sans informations de méta-fichier # Cette option permet de décompresser des objets DICOM compressés en JPEG qui ont été stockés comme jeu de données sans méta-en-tête. Une telle chose ne devrait pas exister puisque la syntaxe de transfert ne peut pas être déterminée de façon fiable sans méta-en-tête, mais malheureusement c'est le cas.

options de traitement

+cp --conv-photometric: convertit si interprétation photométrique YCbCr (par défaut) # Si l'image compressée utilise l'interprétation photométrique YBR_FULL ou YBR_FULL_422, convertit en RGB pendant la décompression.
+cl --conv-lossy: convertit YCbCr en RGB si JPEG avec perte # Si l'image compressée est encodée en JPEG avec perte, suppose le modèle colorimétrique YCbCr et convertit en RGB.
+cg --conv-guess: convertit en RGB si la bibliothèque devine YCbCr # Si la bibliothèque JPEG sous-jacente "devine" que l'espace colorimétrique de l'image compressée est YCbCr, convertit en RGB.
+cgl --conv-guess-lossy: convertit en RGB si JPEG avec perte et si la bibliothèque JPEG sous-jacente devine YCbCr # Si l'image compressée est encodée en JPEG avec perte et que la bibliothèque JPEG sous-jacente "devine" que l'espace colorimétrique est YCbCr, convertit en RGB.
+ca --conv-always: convertit toujours YCbCr en RGB # Si l'image compressée est une image couleur, suppose le modèle colorimétrique YCbCr et convertit en RGB. Avertissement : ceci produira une image décodée de façon incorrecte si l'espace colorimétrique est en réalité RGB. Les images compressées en JPEG sans perte ne sont presque jamais encodées en YCbCr, cette option devrait donc être utilisée avec précaution sur de telles images.
+cn --conv-never: ne convertit jamais YCbCr en RGB # Ne convertit jamais l'espace colorimétrique de YCbCr vers RGB pendant la décompression. Notez qu'une conversion de YBR_FULL_422 vers YBR_FULL aura tout de même lieu si l'image source a été compressée avec sous-échantillonnage. planar configuration :
+pa --planar-auto: détermine automatiquement la planar configuration à partir de la classe SOP et de l'espace colorimétrique (par défaut) # Si l'image compressée est une image couleur, stocke en planar configuration color-by-plane si la classe SOP et l'interprétation photométrique l'exigent. Les images Hardcopy Color sont toujours stockées en color-by-plane, et les objets image Ultrasound révisés sont stockés en color-by-plane si le modèle colorimétrique est YBR_FULL. Tout le reste est stocké en color-by-pixel.
+px --color-by-pixel: stocke toujours en color-by-pixel # Si l'image compressée est une image couleur, stocke en planar configuration color-by-pixel.
+pl --color-by-plane: stocke toujours en color-by-plane # Si l'image compressée est une image couleur, stocke en planar configuration color-by-plane. bits stored :
+bs --bits-stored-fix: corrige une valeur bits stored incohérente (par défaut) # Si la valeur de BitsStored dans le bitstream compressé est inférieure à la valeur dans le jeu de données DICOM, met à jour la valeur dans le jeu de données.
-bs --bits-stored-keep: conserve une valeur bits stored incohérente # Conserve la valeur de BitsStored même si elle est incohérente avec le bitstream compressé. Ceci peut aider à décoder correctement certaines images défectueuses. SOP Instance UID :
+ud --uid-default: conserve le même SOP Instance UID (par défaut) # N'attribue jamais de nouveau SOP instance UID.
+ua --uid-always: attribue toujours un nouvel UID # Attribue toujours un nouveau SOP instance UID. options de contournement pour les encodages JPEG incorrects :
+w6 --workaround-pred6: active le contournement pour les images JPEG sans perte présentant un débordement dans le prédicteur 6 # Des images DICOM à 16 bits/pixel ont été observées "dans la nature", compressées en JPEG sans perte, pour lesquelles l'encoder a produit un dépassement d'entier sur 16 bits dans le prédicteur 6, ce qui nécessite un traitement particulier pour être compensé (reproduit) pendant la décompression. Cet indicateur permet une décompression correcte de ces images défectueuses, mais provoquera en même temps une décompression incorrecte des images correctement compressées. À utiliser avec précaution.
+wi --workaround-incpl: active le contournement pour les données JPEG incomplètes # Cette option amène dcmjpeg à ignorer les données JPEG incomplètes en fin de fragment compressé et à commencer la décompression de l'image suivante à partir du fragment suivant (s'il existe). Ceci permet de décoder des images contenant des données JPEG incomplètes.
+wc --workaround-cornell: active le contournement pour les images Cornell JPEG sans perte 16 bits présentant un débordement de la table de Huffman # L'une des premières implémentations open source de la compression JPEG sans perte, la bibliothèque "Cornell", comporte un bogue bien connu qui produit des valeurs invalides dans la table de Huffman lorsque des images à 16 bits/échantillon sont compressées. Cet indicateur active un contournement permettant de décoder correctement de telles images.

options de sortie

+F --write-file: écrit au format fichier (par défaut)
-F --write-dataset: écrit un jeu de données sans informations de méta-fichier syntaxe de transfert 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 représentations de valeur post-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 codage 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 codage 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 indéfinies remplissage de fin de jeu de données (pas avec --write-dataset) :
-p= --padding-retain: ne modifie pas le remplissage (par défaut si pas --write-dataset)
-p --padding-off: aucun 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

SYNTAXES DE TRANSFERT

dcmdjpeg prend en charge les syntaxes de transfert suivantes pour l'entrée (dcmfile-in) :

LittleEndianImplicitTransferSyntax             1.2.840.10008.1.2
LittleEndianExplicitTransferSyntax             1.2.840.10008.1.2.1
DeflatedExplicitVRLittleEndianTransferSyntax   1.2.840.10008.1.2.1.99 (*)
BigEndianExplicitTransferSyntax                1.2.840.10008.1.2.2
JPEGProcess1TransferSyntax                     1.2.840.10008.1.2.4.50
JPEGProcess2_4TransferSyntax                   1.2.840.10008.1.2.4.51
JPEGProcess6_8TransferSyntax                   1.2.840.10008.1.2.4.53
JPEGProcess10_12TransferSyntax                 1.2.840.10008.1.2.4.55
JPEGProcess14TransferSyntax                    1.2.840.10008.1.2.4.57
JPEGProcess14SV1TransferSyntax                 1.2.840.10008.1.2.4.70

(*) si compilé avec la prise en charge de zlib activée

dcmdjpeg prend en charge les syntaxes de transfert suivantes pour la sortie (dcmfile-out) :

LittleEndianImplicitTransferSyntax             1.2.840.10008.1.2
LittleEndianExplicitTransferSyntax             1.2.840.10008.1.2.1
BigEndianExplicitTransferSyntax                1.2.840.10008.1.2.2

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

VOIR AUSSI

dcmcjpeg(1)