⚠️ Este é um site de tradução não oficial, sem relação com o DCMTK / OFFIS. Para informações oficiais, consulte a página original (https://support.dcmtk.org/docs/json2dcm.html).

json2dcm: converte um documento JSON em arquivo ou conjunto de dados DICOM

SINOPSE

json2dcm [options] jsonfile-in dcmfile-out

DESCRIÇÃO

O utilitário json2dcm converte o conteúdo de um documento JSON (JavaScript Object Notation) em um arquivo ou conjunto de dados DICOM binário. Espera-se que o documento JSON esteja em conformidade com o "DICOM JSON Model", conforme definido em DICOM Part 18 Section F. Esses arquivos JSON podem ser criados, por exemplo, usando a ferramenta dcm2json.

PARÂMETROS

jsonfile-in  JSON input filename to be converted ("-" for stdin)

dcmfile-out  DICOM output filename ("-" for stdout)

OPÇÕES

opções gerais

-h --help
exibe este texto de ajuda e sai
--version
exibe as informações de versão e sai
--arguments
exibe os argumentos de linha de comando expandidos
-q --quiet
modo silencioso, não exibe avisos nem erros
-v --verbose
modo detalhado, exibe os detalhes do processamento
-d --debug
modo de depuração, exibe informações de depuração
-ll --log-level [l]evel: string constant
(fatal, error, warn, info, debug, trace) usa o nível l para o logger
-lc --log-config [f]ilename: string
usa o arquivo de configuração f para o logger

opções de entrada

+f --read-meta-info
lê as informações de meta se presentes (padrão)
-f --ignore-meta-info
ignora as informações de meta do arquivo

opções de processamento

+Ug --generate-new-uids
gera um novo Study/Series/SOP Instance UID
-Uo --dont-overwrite-uids
não sobrescreve os UIDs existentes (padrão)
+Uo --overwrite-uids
sobrescreve os UIDs existentes. Tratamento de URIs de bulkdata:
+Bu --parse-bulkdata-uri
analisa as URIs de Bulkdata (padrão)
-Bu --ignore-bulkdata-uri
ignora as URIs de Bulkdata
+Bd --add-bulkdata-dir [d]irectory: string
adiciona d à lista de fontes de bulk data permitidas. Tratamento de arrays com múltiplos conjuntos de dados:
-ar --array-reject
rejeita múltiplos conjuntos de dados (padrão)
+as --array-select [n]umber: integer
seleciona o conjunto de dados n do array
+ar --array-sequence
armazena todos os conjuntos de dados em sequência privada

opções de saída

+F --write-file
grava no formato de arquivo (padrão)
-F --write-dataset
grava o conjunto de dados sem as informações de meta do arquivo
+Fu --update-meta-info
atualiza determinadas informações de meta do arquivo. sintaxe de transferência de saída:
+t= --write-xfer-same
grava com a mesma TS da entrada (padrão)
+te --write-xfer-little
grava com a TS explicit VR little endian
+tb --write-xfer-big
grava com a TS explicit VR big endian
+ti --write-xfer-implicit
grava com a TS implicit VR little endian
+td --write-xfer-deflated
grava com TS de VR explícita little endian deflate. tratamento de erros:
-E --stop-on-error
não grava se o documento for inválido (padrão)
+E --ignore-errors
tenta gravar mesmo que o documento seja inválido. Representações de valor (VR) posteriores a 1993:
+u --enable-new-vr
habilita o suporte a novos VRs (UN/UT) (padrão)
-u --disable-new-vr
desabilita suporte a novos VRs, converte para OB. Codificação de comprimento em sequências e itens:
+e --length-explicit
grava com comprimentos explícitos (padrão)
-e --length-undefined
grava com comprimentos indefinidos. Tratamento de charset:
+c --charset-accept
grava com o charset informado no JSON (padrão)
-c --charset-replace
substitui o charset informado no JSON por UTF-8. Nível de compressão deflate (somente com --write-xfer-deflated):
+cl --compression-level [l]evel: integer (default: 6)
0=sem compressão, 1=mais rápido, 9=melhor compressão

NOTAS

A estrutura básica esperada da entrada JSON é a seguinte (veja DICOM Part 18 Section F para detalhes):

{
    "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
        ]
    }
}

Codificação de caracteres

O formato JSON só oferece suporte à codificação UTF-8. Portanto, o arquivo DICOM gerado também conterá codificação UTF-8. Se o arquivo JSON não contiver um conjunto de caracteres específico, ou um conjunto de caracteres específico diferente de "ISO_IR 192", um aviso será emitido.

Dados binários, bulk data e dados de pixel

O DICOM JSON Model usa "InlineBinary" para armazenar valores de atributos de representações de valor (VR) binárias, como "OB", "OW", "OD", "OF", "OL", "OV" etc., em formato codificado em Base64. O json2dcm oferece suporte a isso para todos os atributos binários, incluindo dados de pixel não encapsulados.

O DICOM JSON Model também permite que os valores de atributos sejam armazenados separadamente do conjunto de dados JSON e referenciados por meio de uma BulkDataURI. Há suporte a isso para URIs de arquivo que referenciam arquivos no sistema de arquivos local. A ferramenta json2dcm também oferece suporte à extensão não oficial do esquema de URI de arquivo gerada pelo DCM4CHE, na qual parâmetros chamados "offset" e "length" são anexados à URI de arquivo para se referirem a uma parte específica de um arquivo. URIs HTTP, bem como URIs que identificam outra parte em uma estrutura MIME multipart/related, ainda não têm suporte no json2dcm. Se a opção de linha de comando –ignore-bulkdata-uri for especificada, todas as URIs de bulk data serão ignoradas e os atributos com bulk data serão gravados com valor vazio.

Por fim, os dados de pixel encapsulados (em particular, comprimidos) não têm suporte no json2dcm, pois a sintaxe do DICOM JSON Model para esse caso específico ainda não está definida no padrão DICOM.

Arrays de conjuntos de dados

O DICOM JSON Model usa uma estrutura de array JSON para retornar múltiplos conjuntos de dados em serviços DICOMweb como WADO-RS ou QIDO-RS. Arrays JSON contendo um único conjunto de dados DICOM são automaticamente reconhecidos pelo json2dcm e tratados como um conjunto de dados sem a estrutura de array ao redor. Arrays JSON contendo múltiplos conjuntos de dados são rejeitados por padrão. Alternativamente, a opção –array-select pode ser usada para selecionar um conjunto de dados do array a ser convertido. A opção –array-sequence faz com que todos os conjuntos de dados sejam gravados como itens de sequência em uma única sequência privada com a tag de atributo (0009,1000). Esses arquivos, destinados principalmente a fins de depuração, podem ser reconhecidos pelo elemento private creator (0009,0010), que tem o valor "JSON2DCM_LIST_OF_DATASETS".

Vírgulas finais

Vírgulas finais não são permitidas em JSON, mas o json2dcm ainda assim aceita esses conjuntos de dados JSON sem avisos ou mensagens de erro, pois são tratadas de forma tolerante pelo analisador JSON subjacente. Os usuários não devem, portanto, presumir que um conjunto de dados JSON é válido apenas porque o json2dcm o aceitou. Esta ferramenta não foi projetada como um validador para JSON ou para o DICOM JSON Model.

REGISTRO DE LOG

O nível de detalhamento do log das diversas ferramentas de linha de comando e das bibliotecas subjacentes pode ser especificado pelo usuário. Por padrão, apenas erros e avisos são gravados no fluxo de erro padrão. Ao usar a opção –verbose, mensagens informativas, como detalhes do processamento, também são relatadas. A opção –debug pode ser usada para obter mais detalhes sobre a atividade interna, por exemplo, para fins de depuração. Outros níveis de log podem ser selecionados com a opção –log-level. No modo –quiet, apenas erros fatais são relatados. Nesses casos de erro muito graves, o aplicativo normalmente é encerrado. Para mais detalhes sobre os diferentes níveis de log, consulte a documentação do módulo "oflog".

Caso a saída do log deva ser gravada em arquivo (opcionalmente com rotação de arquivo de log), no syslog (Unix) ou no log de eventos (Windows), pode-se usar a opção –log-config. Esse arquivo de configuração também permite direcionar apenas determinadas mensagens para um fluxo de saída específico e filtrar certas mensagens com base no módulo ou aplicativo em que são geradas. Um arquivo de configuração de exemplo é fornecido em < etcdir>/logger.cfg.

LINHA DE COMANDO

Todas as ferramentas de linha de comando usam a seguinte notação para os parâmetros: colchetes delimitam valores opcionais (0-1), reticências no final indicam que múltiplos valores são permitidos (1-n), e a combinação dos dois significa de 0 a n valores.

As opções de linha de comando se distinguem dos parâmetros por um sinal '+' ou '-' à frente. Normalmente, a ordem e a posição das opções de linha de comando são arbitrárias (ou seja, podem aparecer em qualquer lugar). No entanto, se as opções forem mutuamente exclusivas, é usada a ocorrência mais à direita. Esse comportamento está em conformidade com as regras de avaliação padrão dos shells Unix comuns.

Além disso, um ou mais arquivos de comando podem ser especificados usando um sinal '@' como prefixo do nome do arquivo (por exemplo, @command.txt). Esse argumento de comando é substituído pelo conteúdo do arquivo de texto correspondente (múltiplos espaços em branco são tratados como um único separador, a menos que apareçam entre duas aspas) antes de qualquer avaliação posterior. Observe que um arquivo de comando não pode conter outro arquivo de comando. Essa abordagem simples, mas eficaz, permite agrupar combinações comuns de opções/parâmetros e evita linhas de comando longas e confusas (um exemplo é fornecido no arquivo < datadir>/dumppat.txt).

CÓDIGOS DE SAÍDA

O utilitário dcm2json usa os seguintes códigos de saída ao ser encerrado. Isso permite ao usuário verificar o motivo pelo qual o aplicativo foi encerrado.

geral

EXITCODE_NO_ERROR                               0
EXITCODE_COMMANDLINE_SYNTAX_ERROR               1

erros de arquivo de entrada

EXITCODE_CANNOT_READ_INPUT_FILE                 20

erros de arquivo de saída

EXITCODE_CANNOT_WRITE_OUTPUT_FILE               40

erros de processamento

EXITCODE_INVALID_JSON_CONTENT                   65
EXITCODE_BULKDATA_URI_NOT_SUPPORTED             66

AMBIENTE

O utilitário json2dcm tentará carregar os dicionários de dados DICOM especificados na variável de ambiente DCMDICTPATH. Por padrão, ou seja, se a variável de ambiente DCMDICTPATH não estiver definida, o arquivo < datadir>/dicom.dic será carregado, a menos que o dicionário esteja embutido no aplicativo (padrão para Windows).

É preferível manter o comportamento padrão e usar a variável de ambiente DCMDICTPATH apenas quando dicionários de dados alternativos forem necessários. A variável de ambiente DCMDICTPATH tem o mesmo formato da variável PATH dos shells Unix, em que dois-pontos (":") separam as entradas. Em sistemas Windows, um ponto e vírgula (";") é usado como separador. O código do dicionário de dados tenta carregar cada arquivo especificado na variável de ambiente DCMDICTPATH. Ocorre um erro se nenhum dicionário de dados puder ser carregado.

VEJA TAMBÉM

dcm2json(1) dump2dcm(2)

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