json2dcm: conversion d'un document JSON en fichier ou jeu de données DICOM

SYNOPSIS

json2dcm [options] jsonfile-in dcmfile-out

DESCRIPTION

json2dcm est un utilitaire qui convertit le contenu d'un document JSON (JavaScript Object Notation) en fichier ou jeu de données DICOM binaire. Le document JSON est censé être conforme au "DICOM JSON Model" tel que défini dans DICOM Part 18 Section F. De tels fichiers JSON peuvent être créés, par exemple, à l'aide de l'outil dcm2json.

PARAMÈTRES

jsonfile-in  JSON 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 pas d'avertissements ni d'erreurs
-v --verbose: mode détaillé, affiche les détails du traitement
-d --debug: mode de 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 métadonnées si présentes (par défaut)
-f --ignore-meta-info: ignore les métadonnées de fichier

options de traitement

+Ug --generate-new-uids: génère de nouveaux UID Study/Series/SOP Instance
-Uo --dont-overwrite-uids: n'écrase pas les UID existants (par défaut)
+Uo --overwrite-uids: écrase les UID existants. Gestion des URI de données volumineuses :
+Bu --parse-bulkdata-uri: analyse les URI de données volumineuses (par défaut)
-Bu --ignore-bulkdata-uri: ignore les URI de données volumineuses
+Bd --add-bulkdata-dir [d]irectory: string: ajoute d à la liste des sources de données volumineuses autorisées. Gestion des tableaux contenant plusieurs jeux de données :
-ar --array-reject: rejette plusieurs jeux de données (par défaut)
+as --array-select [n]umber: integer: sélectionne le jeu de données n dans le tableau
+ar --array-sequence: stocke tous les jeux de données dans une séquence privée

options de sortie

+F --write-file: écrit au format de fichier (par défaut)
-F --write-dataset: écrit le jeu de données sans les métadonnées de fichier
+Fu --update-meta-info: met à jour certaines métadonnées de fichier. Syntaxe de transfert en sortie :
+t= --write-xfer-same: écrit avec la même TS qu'en entrée (par défaut)
+te --write-xfer-little: écrit avec la TS 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 deflated explicit VR little endian. Gestion des erreurs :
-E --stop-on-error: n'écrit pas si le document n'est pas valide (par défaut)
+E --ignore-errors: tente d'écrire même si le document n'est pas valide. Représentations de valeur (VR) postérieures à 1993 :
+u --enable-new-vr: active la prise en charge des nouveaux VR (UN/UT) (par défaut)
-u --disable-new-vr: désactive la prise en charge des nouveaux VR, convertit en OB. Encodage de la longueur dans les séquences et éléments :
+e --length-explicit: écrit avec des longueurs explicites (par défaut)
-e --length-undefined: écrit avec des longueurs indéfinies. Gestion du jeu de caractères :
+c --charset-accept: écrit avec le jeu de caractères indiqué dans le JSON (par défaut)
-c --charset-replace: remplace le jeu de caractères indiqué dans le JSON par de l'UTF-8. 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=compression maximale

NOTES

La structure de base du JSON en entrée attendu se présente comme suit (voir DICOM Part 18 Section F pour plus de détails) :

{
    "00080005": {
        "vr": "CS",
        "Value": [
            "ISO_IR 192"
        ]
    },
    "00080020": {
        "vr": "DT",
        "Value": [
            "20130409"
        ]
    },
    "00080030": {
        "vr": "TM",
        "Value": [
            "131600.0000"
        ]
    },
    "00080050": {
        "vr": "SH",
        "Value": [
            "11235813"
        ]
    },
    "00080056": {
        "vr": "CS",
        "Value": [
            "ONLINE"
        ]
    },
    "00080061": {
        "vr": "CS",
        "Value": [
            "CT",
            "PET"
        ]
    },
    "00080090": {
        "vr": "PN",
        "Value": [
          {
            "Alphabetic": "^Bob^^Dr."
          }
        ]
    },
    "00081190": {
        "vr": "UR",
        "Value": [
            "http://wado.nema.org/studies/
            1.2.392.200036.9116.2.2.2.1762893313.1029997326.945873"
        ]
    },
    "00090010": {
        "vr": "LO",
        "Value": [
            "Vendor A"
        ]
    },
    "00091002": {
        "vr": "UN",
        "InlineBinary": "z0x9c8v7"
    },
    "00100010": {
        "vr": "PN",
        "Value": [
          {
            "Alphabetic": "Wang^XiaoDong"
          }
        ]
    },
    "00100020": {
        "vr": "LO",
        "Value": [
            "12345"
        ]
    },
    "00100021": {
        "vr": "LO",
        "Value": [
            "Hospital A"
        ]
    },
    "00100030": {
        "vr": "DA",
        "Value": [
            "19670701"
        ]
    },
    "00100040": {
        "vr": "CS",
        "Value": [
            "M"
        ]
    },
    "00101002": {
        "vr": "SQ",
        "Value": [
            {
                "00100020": {
                    "vr": "LO",
                    "Value": [
                        "54321"
                    ]
                },
                "00100021": {
                    "vr": "LO",
                    "Value": [
                        "Hospital B"
                    ]
                }
            },
            {
                "00100020": {
                    "vr": "LO",
                    "Value": [
                        "24680"
                    ]
                },
                "00100021": {
                    "vr": "LO",
                    "Value": [
                        "Hospital C"
                    ]
                }
            }
        ]
    },
    "0020000D": {
        "vr": "UI",
        "Value": [
            "1.2.392.200036.9116.2.2.2.1762893313.1029997326.945873"
        ]
    },
    "00200010": {
        "vr": "SH",
        "Value": [
            "11235813"
        ]
    },
    "00201206": {
        "vr": "IS",
        "Value": [
            4
        ]
    },
    "00201208": {
        "vr": "IS",
        "Value": [
            942
        ]
    }
}

Encodage des caractères

Le format JSON ne prend en charge que l'encodage UTF-8. Le fichier DICOM généré contiendra donc également un encodage UTF-8. Si le fichier JSON ne contient pas de jeu de caractères spécifique, ou un jeu de caractères spécifique autre que "ISO_IR 192", un avertissement est émis.

Données binaires, données volumineuses et données de pixels

Le DICOM JSON Model utilise "InlineBinary" pour stocker les valeurs d'attributs des représentations de valeur (VR) binaires telles que "OB", "OW", "OD", "OF", "OL", "OV", etc., sous forme encodée en Base64. Cela est pris en charge par json2dcm pour tous les attributs binaires, y compris les données de pixels non encapsulées.

Le DICOM JSON Model permet également que les valeurs d'attributs soient stockées séparément du jeu de données JSON et référencées via une BulkDataURI. Cela est pris en charge pour les URI de fichier qui référencent des fichiers du système de fichiers local. L'outil json2dcm prend également en charge l'extension non officielle du schéma d'URI de fichier générée par DCM4CHE, dans laquelle des paramètres nommés "offset" et "length" sont ajoutés à l'URI de fichier afin de désigner une partie spécifique d'un fichier. Les URI HTTP, ainsi que les URI identifiant une autre partie dans une structure MIME multipart/related, ne sont pas encore prises en charge par json2dcm. Si l'option de ligne de commande –ignore-bulkdata-uri est spécifiée, toutes les URI de données volumineuses sont ignorées et les attributs contenant des données volumineuses sont écrits avec une valeur vide.

Enfin, les données de pixels encapsulées (en particulier compressées) ne sont pas prises en charge par json2dcm, car la syntaxe du DICOM JSON Model pour ce cas particulier n'est pas encore définie dans la norme DICOM.

Tableaux de jeux de données

Le DICOM JSON Model utilise une structure de tableau JSON pour renvoyer plusieurs jeux de données dans des services DICOMweb tels que WADO-RS ou QIDO-RS. Les tableaux JSON contenant un seul jeu de données DICOM sont automatiquement reconnus par json2dcm et traités comme un jeu de données sans la structure de tableau qui l'entoure. Les tableaux JSON contenant plusieurs jeux de données sont rejetés par défaut. L'option –array-select permet de sélectionner, dans le tableau, un jeu de données à convertir. L'option –array-sequence fait en sorte que tous les jeux de données soient écrits sous forme d'éléments de séquence dans une seule séquence privée portant le tag d'attribut (0009,1000). Ces fichiers, principalement destinés au débogage, peuvent être reconnus par l'élément private creator (0009,0010), dont la valeur est "JSON2DCM_LIST_OF_DATASETS".

Virgules finales

Les virgules finales ne sont pas autorisées en JSON, mais json2dcm accepte malgré tout de tels jeux de données JSON, sans avertissement ni message d'erreur, car elles sont traitées avec souplesse par l'analyseur JSON sous-jacent. Les utilisateurs ne doivent donc pas supposer qu'un jeu de données JSON est valide simplement parce que json2dcm l'accepte. Cet outil n'est pas conçu comme un validateur pour JSON ou pour le DICOM JSON Model.

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 dcm2json utilise les codes de sortie suivants lorsqu'il se termine. Cela permet à l'utilisateur de vérifier la raison pour laquelle l'application s'est terminée.

général

EXITCODE_NO_ERROR                               0
EXITCODE_COMMANDLINE_SYNTAX_ERROR               1

erreurs de fichier d'entrée

EXITCODE_CANNOT_READ_INPUT_FILE                 20

erreurs de fichier de sortie

EXITCODE_CANNOT_WRITE_OUTPUT_FILE               40

erreurs de traitement

EXITCODE_INVALID_JSON_CONTENT                   65
EXITCODE_BULKDATA_URI_NOT_SUPPORTED             66

ENVIRONNEMENT

L'utilitaire json2dcm 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 (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é.

VOIR AUSSI

dcm2json(1) dump2dcm(2)