⚠️ 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/dcmdjpeg.html).

dcmdjpeg: Decodificar arquivo DICOM comprimido em JPEG

SINOPSE

dcmdjpeg [options] dcmfile-in dcmfile-out

DESCRIÇÃO

O aplicativo dcmdjpeg lê uma imagem DICOM comprimida em JPEG (dcmfile-in), descomprime os dados JPEG (ou seja, converte para uma sintaxe de transferência DICOM nativa) e grava a imagem convertida em um arquivo de saída (dcmfile-out).

PARÂMETROS

dcmfile-in   DICOM 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-file
lê o formato de arquivo ou o conjunto de dados (padrão)
+fo --read-file-only
lê apenas o formato de arquivo
-f --read-dataset
lê um conjunto de dados sem metainformações de arquivo # Esta opção permite descomprimir objetos DICOM comprimidos em JPEG que foram armazenados como conjunto de dados sem meta-cabeçalho. Isso não deveria existir, já que a sintaxe de transferência não pode ser determinada de forma confiável sem o meta-cabeçalho, mas infelizmente isso ocorre.

opções de processamento

+cp --conv-photometric
converte se a interpretação fotométrica for YCbCr (padrão) # Se a imagem comprimida usar a interpretação fotométrica YBR_FULL ou YBR_FULL_422, converte para RGB durante a descompressão.
+cl --conv-lossy
converte YCbCr para RGB se JPEG com perdas # Se a imagem comprimida for codificada em JPEG com perdas, assume o modelo de cor YCbCr e converte para RGB.
+cg --conv-guess
converte para RGB se a biblioteca deduzir YCbCr # Se a biblioteca JPEG subjacente "deduzir" que o espaço de cores da imagem comprimida é YCbCr, converte para RGB.
+cgl --conv-guess-lossy
converte para RGB se for JPEG com perdas e a biblioteca JPEG subjacente deduzir YCbCr # Se a imagem comprimida for codificada em JPEG com perdas e a biblioteca JPEG subjacente "deduzir" que o espaço de cores é YCbCr, converte para RGB.
+ca --conv-always
converte sempre YCbCr para RGB # Se a imagem comprimida for uma imagem colorida, assume o modelo de cor YCbCr e converte para RGB. Aviso: isso resultará em uma imagem decodificada incorretamente se o espaço de cores for, na verdade, RGB. Imagens comprimidas com JPEG sem perdas quase nunca são codificadas em YCbCr; portanto, esta opção deve ser usada com cautela nessas imagens.
+cn --conv-never
nunca converte YCbCr para RGB # Nunca converte o espaço de cores de YCbCr para RGB durante a descompressão. Observe que uma conversão de YBR_FULL_422 para YBR_FULL ainda ocorrerá se a imagem de origem tiver sido comprimida com subamostragem. planar configuration:
+pa --planar-auto
determina automaticamente a planar configuration a partir da classe SOP e do espaço de cores (padrão) # Se a imagem comprimida for uma imagem colorida, armazena em planar configuration color-by-plane quando exigido pela classe SOP e pela interpretação fotométrica. As imagens Hardcopy Color são sempre armazenadas em color-by-plane, e os objetos de imagem Ultrasound revisados são armazenados em color-by-plane quando o modelo de cor é YBR_FULL. Todo o restante é armazenado em color-by-pixel.
+px --color-by-pixel
sempre armazena em color-by-pixel # Se a imagem comprimida for uma imagem colorida, armazena em planar configuration color-by-pixel.
+pl --color-by-plane
sempre armazena em color-by-plane # Se a imagem comprimida for uma imagem colorida, armazena em planar configuration color-by-plane. bits stored:
+bs --bits-stored-fix
corrige um valor bits stored inconsistente (padrão) # Se o valor de BitsStored no bitstream comprimido for menor que o valor no conjunto de dados DICOM, atualiza o valor no conjunto de dados.
-bs --bits-stored-keep
preserva um valor bits stored inconsistente # Mantém o valor de BitsStored mesmo que esteja inconsistente com o bitstream comprimido. Isso pode ajudar a decodificar corretamente algumas imagens defeituosas. SOP Instance UID:
+ud --uid-default
mantém o mesmo SOP Instance UID (padrão) # Nunca atribui um novo SOP instance UID.
+ua --uid-always
sempre atribui um novo UID # Sempre atribui um novo SOP instance UID. opções de solução alternativa para codificações JPEG incorretas:
+w6 --workaround-pred6
ativa a solução alternativa para imagens JPEG sem perdas com estouro no preditor 6 # Foram observadas "na prática" imagens DICOM com 16 bits/pixel # que são comprimidas com JPEG sem perdas e exigem tratamento # especial, porque o encoder gerou um estouro de inteiro de 16 bits # no preditor 6, que precisa ser compensado (reproduzido) durante a # descompressão. Essa flag permite a descompressão correta dessas # imagens defeituosas, mas ao mesmo tempo causará uma descompressão # incorreta de imagens corretamente comprimidas. Use com cuidado.
+wi --workaround-incpl
habilita a solução alternativa para dados JPEG incompletos # Esta opção faz com que o dcmjpeg ignore dados JPEG incompletos no final de um fragmento comprimido e comece a descomprimir o próximo quadro a partir do próximo fragmento (se houver). Isso permite decodificar imagens com dados JPEG incompletos.
+wc --workaround-cornell
habilita a solução alternativa para imagens Cornell JPEG sem perdas de 16 bits com estouro da tabela de Huffman # Uma das primeiras implementações de código aberto da compressão JPEG sem perdas, a biblioteca "Cornell", tem um bug conhecido que causa valores inválidos na tabela de Huffman quando imagens com 16 bits/amostra são comprimidas. Este sinalizador habilita uma solução alternativa que permite decodificar corretamente essas imagens.

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 meta do arquivo. sintaxe de transferência de saída:
+te --write-xfer-little
grava em explicit VR little endian (padrão)
+tb --write-xfer-big
grava com a TS explicit VR big endian
+ti --write-xfer-implicit
grava em implicit VR little endian TS representações de valor pós-1993:
+u --enable-new-vr
habilita o suporte a novos VRs (UN/UT) (padrão)
-u --disable-new-vr
desabilita o suporte a novos VRs, converte para OB. codificação do comprimento de grupo:
+g= --group-length-recalc
recalcula os comprimentos de grupo, se presentes (padrão)
+g --group-length-create
sempre grava com elementos de comprimento de grupo
-g --group-length-remove
sempre grava sem elementos de comprimento de grupo. 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 preenchimento final do conjunto de dados (não com --write-dataset):
-p= --padding-retain
não altera o preenchimento (padrão se --write-dataset não for usado)
-p --padding-off
sem preenchimento (implícito com --write-dataset)
+p --padding-create [f]ile-pad [i]tem-pad: integer
alinha o arquivo em um múltiplo de f bytes e os itens em um múltiplo de i bytes

SINTAXES DE TRANSFERÊNCIA

dcmdjpeg oferece suporte às seguintes sintaxes de transferência para a entrada (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

(*) se compilado com suporte a zlib habilitado

dcmdjpeg oferece suporte às seguintes sintaxes de transferência para a saída (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

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

AMBIENTE

O aplicativo dcmdjpeg 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

dcmcjpeg(1)

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