WADO-URI with JPEG Transfer Syntaxes

[Jack Pipes]

Hello,

I’m trying to retrieve image data in various transfer syntaxes using the WADO-URI service but I face some issues. 

When I request the following URLs :

http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/wado?requestType=WADO&studyUID=[...]&seriesUID=[...]&objectUID=[...]&contentType=application/dicom&transferSyntax=1.2.840.10008.1.2.4.70

I receive a 406 HTTP response with error : Supported Transfer Syntaxes for UncompressedMultiFrameImage not acceptable

And I have this same kind of error with other JPEG-based transfer syntaxes I tried (1.2.840.10008.1.2.4.90, 1.2.840.10008.1.2.4.91, 1.2.840.10008.1.2.4.50, 1.2.840.10008.1.2.5)

Changing the contentType for « image/jpeg » do not works either as I receive the following error :

[anonymize, transferSyntax] shall only be present if contentType is application/dicom

It obviously works well with standard TS.

This does not make sense to me, as it is supposed to be supported if I understand the conforment statement properly, but maybe I’m wrong ? 

https://dcm4chee-arc-cs.readthedocs.io/en/latest/networking/specs/wado-uri.html

I tested it on several freshly installed dcm4chee-arc-light instances of dockerized version 5.22.2 and higher and I observe the same behaviour.

The only place where I find related settings is in dcm4chee-arc > AE > Transfer Capabilities and everything seems to be configured properly for the SOP Classes I’m concerned by.

I noticed the introduction of Available Transfers Syntax UID (0008,3002) in recent versions, which is permanently filled with 1.2.840.10008.1.2.1 at instance level. Is that related ? If yes, how can I configure that ?

Best regards,

JP

[gunterze]

The WADO URI Service of the archive does not support compression of uncompressed stored images on retrieve. It only supports decompression of compressed stored images. You may use  transferSyntax=*, to retrieve the image in the same Transfer Syntax as it is stored at the archive.

[Jack Pipes]

Thank you for the quick reply. 

Is WADO-RS an alternative to these limitations ? I mean, with WADO-RS, can I retrieve image data in various TS ?

[gunterze]

No. All retrieve services, including by DICOM DUL C-MOVE/C-GET, share that limitation.
In our installations we compress images on receive to a lossless Transfer Syntax which most of retrieve destinations in that installation supports.
Trans-coding images on retrieve does not scale because of caused CPU load.

[Jack Pipes]

Ok I got it, this has to be anticipated when storing the image then.

What are my options if I want to store and distribute both uncompressed DICOM and compressed images ? 

Can I store them concurrently ? Using a separated filesystem ? Or using a separated archive ?

[Dr Suresh Viswanathan]

Compressed images can always be retrieved as uncompressed but not vice versa. Choose your preferred compression syntax and you can have both. 

Suresh. 

On 22-Jan-2021, at 20:06, Jack Pipes <nark...@free.fr> wrote:

Ok I got it, this has to be anticipated when storing the image then.

--
You received this message because you are subscribed to the Google Groups "dcm4che" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dcm4che+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dcm4che/b12357a4-20c7-4f9d-a1e2-0686f76e0962n%40googlegroups.com.

[Jack Pipes]

Ok, understood, many thx for clarification.

When you say « choose your preferred compression syntax », I assume you speak about the Preferred Transfer Syntax of the Network AE Extension.

What is the purpose of Compression rules in Archive attributes ? Only to overload the compression params ?

[Jack Pipes]

Sorry to bother on this topic, but one question remains : 

Can the archive distributes multiple compressed transfer syntaxes ? Or only the one chosen for storage ?

My archive currently stores images in 1.2.840.10008.1.2.4.70

So over WADO-URI I can retrieve my images as 1.2.840.10008.1.2.4.70, 1.2.840.10008.1.2 and 1.2.840.10008.1.2.1 as intended using the transferSyntax parameter.

Any options to also support distribution as JPEG 2000 Lossless (1.2.840.10008.1.2.4.90) ?

Best regards,

JP

[Gunter Zeilinger]

... only the one chosen for storage.

[Jack Pipes]

Thank you ;)