storescu native encoding

[jhr]

Hi.

I would like to transfer dicom files using storescu in their native encoding.

When I use storescu without any parameter it proposes only little endian and thus fails on other encoding.

I tried to use several -x parameters to proposes multiple encoding but only the last -x parameter seems to be used.

Since there is no -xa parameter (to propose every supported encoding) how am I suppose to tell storescu to transfer the files in their native encoding ?

Thanks.

[J. Riesmeier]

I would recommend to use dcmsend, which is a more intelligent version of an Storage SCU. Also see the following blog posting from last year.

[omarelgazzar]

Hello,

In the storescu tool, you can define the flag ON_THE_FLY_COMPRESSION to let the tool support converting the compressed transfer syntax to uncompressed in case that the compressed transfer syntax is not accepted by the store SCP. Alternatively, there is a new tool called "dcmsend" in the latest DCMTK snapshot that can manage association negotiation itsefl with options for on the fly decompression.

Best Regards,
Omar

[J. Riesmeier]

Regarding the "native encoding" aspect in your question: This is not always possible, because DICOM is no ftp. Therefore, dcmsend has the following options for transfer syntax conversion:

Code: Select all

  -dn   --decompress-never
          never decompress compressed data sets

  +dls  --decompress-lossless
          only decompress lossless compression (default)

  +dly  --decompress-lossy
          decompress both lossy and lossless compression

And another one in the "other processing options" section:

Code: Select all

  -nip  --no-illegal-proposal
          do not propose any presentation context that does
          not contain the default transfer syntax (if needed)

For details, read the section on DICOM Conformance in dcmsend's man page (documentation).

[jhr]

Thanks for your replies.

Unfortunately dcmsend is unavailable for me at this time, I would need the windows binary, I might wait for the release or try to compile the current snapshot tho.

My goal is to try to transfer the DICOM files with their current encoding if supported by remote SCP and if not then uncompress/convert them to whatever the SCP prefer.

Do I understand correctly the process:

Without -dn parameter, dcmsend will try to send using the native encoding if accepted by remote SCP, and if not uncompress or convert.

With the -dn parameter, dmcsend will try to send using the native encoding if accepted by remote SCP, and if not fails.

With the -nip parameter, dmcsend will only offer the native encoding, if not accepted by remote SCP fails.

Am I correct ?

Is dmcsend capable of decompressing JP2K ?

[J. Riesmeier]

Unfortunately dcmsend is unavailable for me at this time, I would need the windows binary, I might wait for the release or try to compile the current snapshot tho.

This is pretty easy, you only need CMake and some VisualStudio Express (C++) version. Details can be found in the INSTALL file.

Without -dn parameter, dcmsend will try to send using the native encoding if accepted by remote SCP, and if not uncompress or convert.

No, +dls is the default, which means that only lossless compressed images are decompressed (if requested by the SCP). This is because the DICOM standard requires an SCU to also prospose the default transfer syntax (which is Implicit VR Little Endian) for all DICOM objects that are not compressed in a lossy manner.

With the -dn parameter, dmcsend will try to send using the native encoding if accepted by remote SCP, and if not fails.

Right, and this is strictly speaking not DICOM-compliant (see above). Therefore, dcmsend will report a warning in such a case.

With the -nip parameter, dmcsend will only offer the native encoding, if not accepted by remote SCP fails.

No. With this option no illegal presentation contexts will be proposed, e.g. by not proposing the default transfer syntax.

Is dmcsend capable of decompressing JP2K ?

No, since support for JPEG2000 is not part of the freely available DCMTK. However, support for this compression scheme can be added quite easily when you have access to the DCMJP2K module. The list of supported transfer syntaxes is shown with dcmsend's option --list-decoders.

Btw, all this is also explained in the "DICOM Conformance" section of the man page I referenced in my last posting. As always, details on the association negotiation can be found in the DICOM standard. We expect users of the DCMTK to have some basic understanding of the underlying standard(s).