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.
storescu native encoding
Moderator: Moderator Team
-
- DCMTK Developer
- Posts: 2512
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: storescu native encoding
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.
-
- Posts: 101
- Joined: Wed, 2009-07-08, 16:06
- Location: Oldenburg, Germany
Re: storescu native encoding
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
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
-
- DCMTK Developer
- Posts: 2512
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: storescu native encoding
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:
And another one in the "other processing options" section:
For details, read the section on DICOM Conformance in dcmsend's man page (documentation).
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
Code: Select all
-nip --no-illegal-proposal
do not propose any presentation context that does
not contain the default transfer syntax (if needed)
Re: storescu native encoding
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 ?
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 ?
-
- DCMTK Developer
- Posts: 2512
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: storescu native encoding
This is pretty easy, you only need CMake and some VisualStudio Express (C++) version. Details can be found in the INSTALL file.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.
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.Without -dn parameter, dcmsend will try to send using the native encoding if accepted by remote SCP, and if not uncompress or convert.
Right, and this is strictly speaking not DICOM-compliant (see above). Therefore, dcmsend will report a warning in such a case.With the -dn parameter, dmcsend will try to send using the native encoding if accepted by remote SCP, and if not fails.
No. With this option no illegal presentation contexts will be proposed, e.g. by not proposing the default transfer syntax.With the -nip parameter, dmcsend will only offer the native encoding, if not accepted by remote SCP fails.
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.Is dmcsend capable of decompressing JP2K ?
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).
Who is online
Users browsing this forum: Bing [Bot] and 1 guest