DCMQRSCP and ON THE FLY COMPRESSION

[fanying]

Hello, I am posting on behalf my organization whom serves a number of cardiologist. We have a problem with dcmqrscp sending mixed compression and uncompressed studies to Osirix reading stations.

Our current system setup consists of:

DCMTK server running on CentOS 5.7 x86_64 which is the central dicom repository
GE CTSCAN modality
GE AW Reading station for CTSCAN
GE Vivid Echo modality
GE Echo Reading station for ECHOs
Siemens (don't remember model) modality
Siemens Syngo Reading station for ECHOs
Osirix Reading station (Macintosh)

Our objective is to replace three separate types of Reading stations with a single Macintosh platform running Osirix such that Osirix can retrieve studies from either iMacs, Macbooks, or iPads. This will be of greater convenience to our cardiologists but also reduces licensing cost for three separate reading stations.

Our dcmqrscp server configured to prefer and propose jpeg lossy as the ECHO commercial system do support this compression.

The problem we are having is that the Siemens modalities send a study with a combination of compress and uncompress images. The transfer from Siemens modalities to dcmqrscp works without any issues. However when Osirix attempts to retrieve that same study from dcmqrscp, dcmqrscp fails to send either the compressed or uncompressed dicom files depending on how the Osirix listener is configured. Furthermore, the same study from the Siemens modality successfully transfers all files to the Osirix direct. As for the GE, all transfers in both direction works successfully.

Here is a sample of the logs with the transfer syntax error.

Code: Select all

 # Dicom-Data-Set
 # Used TransferSyntax: Little Endian Explicit
 (0008,0052) CS [STUDY]                                  #   6, 1 QueryRetrieveLevel
 (0020,000d) UI [1.2.840.113619.2.55.3.380371476.920.1314213754.848] #  50, 1 StudyInstanceUID
 
 Requesting Sub-Association
 Store SCU RQ: MsgID 1, (US)
 DIMSE Warning: (ECHOPACS,OSIRIX): sendMessage: unable to convert DICOM file '/pacs/ECHOPACS/US_4ed3e832ebaed50d.dcm' from  transfer syntax 'JPEG Baseline' to 'Little Endian Explicit'
 Move SCP: storeSCU: Store Request Failed: 0006:020e DIMSE Failed to send message
 moveSCP: Move Sub-Op Failed: 0006:020e DIMSE Failed to send message
 Move SCP Response 1 [status: Pending]
 Releasing Sub-Association
 Move SCP Response 2 [status: Refused: OutOfResourcesSubOperations]
 Association Release
 Cleaned up after child (25950) Mon Nov 28 15:37:11 2011

I did a little research and determined from the person Michael Onken from this forum post

viewtopic.php?p=5347sid=5c88893a196ca67 ... bef676a3e5

that dcmqrscp does not support ON_THE_FLY_COMPRESSION and advises to use movescu. That macro is currently only available in storscu describe by omarelgazzar from this forum post

viewtopic.php?t=3193&sid=0e7da968f8a680 ... d65ad38ab8

neither of which is not useful to us in our scenario.

Another blog post by J. Riesmeier describes using dcmsend as opposed to storscu to perform "on the fly compression".

http://blog.jriesmeier.com/2011/10/send ... re-easily/

We tested this experimental feature using both storescu and dcmsend and determined that a study with jpeg8 compressed and little endian uncompress both transfer successfully. We also tried movescu as well but we did not get it work. Even if movescu work, neither movescu, dcmsend, nor storescu are effective solutions as the cardiologists prefer to query and retrieve a study at their request. What we are looking for is the ability for dcmqrscp to perform ON THE FLY COMPRESSION just like storscu and dcmsend so that our commercial modality can ultimately be viewable on the cardiologist's personal Macintosh anywhere in the world (provide there is sufficient network bandwidth).

We appreciate for your replies to this post.

[J. Riesmeier]

Another blog post by J. Riesmeier describes using dcmsend as opposed to storscu to perform "on the fly compression".

No, "dcmsend" does not support on-the-fly compression of DICOM datasets but on-the-fly _de_compression, because this makes more sense in this context.

With regard to "dcmqrscp": This tool was previously called "imagectn" and was one of the first two implementations of the DICOM Q/R service back in 1993. It has been developed for a public demonstration at the RSNA, so its main purpose is to be rather a feasibility study than a real "image archive". We are currently thinking about redeveloping the Q/R SCP with an SQL database backend and more practically relevant configuration options. However, if nobody sponsors this work, there's no guarantee that it will be done (soon).

[omarelgazzar]

A workaround to solve this problem is to use the option --propose-jpeg8 in dcmqrscp and let movescu prefer it using the option --prefer-jpeg8 which will avoid the need to convert the file on the fly from the actual transfer syntax to accepted transfer syntax. This will let you send the study with compressed and uncompressed images on the same association as the option --propose-jpeg8 will add presentation contexts for the compressed and uncompressed transfer syntaxes.

[fanying]

To omarelgazzar

We are attempting to use movescu but still have not succeeded yet but we are trying and will inform you of our progress.

To J. Riesmeier

I never said this in the original post but we did in fact implement SQL with dcmqrscp and have successfully used it since 2006 using dcmtk version 3.5.4. I would like to discuss this further in a separate post as it is not related to ON_THE_FLY_COMPRESSION.

Here is the link to the DCMQRSCP with SQL forum post

viewtopic.php?p=12747#12747

[fanying]

To omarelgazzar, J. Riesmeier and DCMTK developers

We did get movescu to transfer files with different transfer syntaxes. However based on how our users want to use Osirix, movescu would not be a feasible solution.

What our people want is to query and retrieve a patient study on demand and there is no way for Osirix to run movescu on a Linux dcmtk server. Maybe we are wrong but that is what we see. The same is try with storescu and dcmsend. None of them can work for an on demand request. They can work though as an automated batch send process via cron jobs.

In addition, I did further research and discovered on another forum relating with another open source PACS software called dcm4che that a user is asking about ON_THE_FLY_COMPRESSION.

The link to that forum is:

http://forums.dcm4che.org/jiveforums/th ... geID=17982

We are wonder if the Osirix and DCMQRSCP can only support one compression format at a time and all files must be in that compression format. If that is a rule in DICOM, we wonder if the problem we are experience is simply a case of commercial vendors breaking the DICOM rules regardless of technical or economical reasons, what can we do enable all studies generated by commercial modalities to be distributed via DCMQRSCP to our users running Osirix while minimizing disk and bandwidth usage?

[J. Riesmeier]

The support for compressed DICOM objects has been added to "dcmqrscp" with the flag "experimental", and I agree that it is probably not an appropriate solution for your use case.
During the DICOM network association negotiation, the SCU proposes what SOP classes and transfer syntaxes are to be used, but the SCP decides in the end (from the proposal list).
There is also a rule in the DICOM standard that the Default Transfer Syntax always has to be proposed by the SCU and that it has to be supported by the SCP ...

As I wrote before: dcmqrscp (or "imagectn" as is was called previously) has been developed for a public demonstration back in 1993, so it is more a feasibility study than a tool for daily practice.