Re: Recompressing to other Transfer Syntax as accepted by SCP does not work.

We implemented functionality implements C-MOVE

We use loadtools StoreScu component for sending the image back to the client
As it is done in Leadtool examples (Leadtool high level demo client)

when we set compression to lossless and use (http://dicom.offis.de/dcmtk) for test then we get leadtools error:

Abstract Syntax Not Supported: 1.2.840.10008.5.1.4.1.1.6.1 Processing failure: Incorrect parameter.
for framework version 16.5

and error Exception
Incorrect parameter.
for version 1.7


The SCP does accept the involved SOP Class.

As we see Store method of StoreScu component makes its own association
for sending the image.
I believe the negotiation between SCU and SCP (the asked client is SCP now)
will make according to DICOM standard. Should we expect (when compression enabled)
the StoreScu to change transfer syntax accordingly to accepted TS by client automatically?
If not how can we make it to send the right(supported by clien) image.

I would suggest to try communicating with the SCP with our High-level Demo and see if this works.

If so, then you should check your code and compare it with the Demo to see what is different. 

If our High-Level Demo gives the same error, please provide the logging information from the Demo and from the Server you're attempting to Move from.

When associating our StoreScu class will change the transfer syntax to match the agreed upon transfer syntax before sending. 

Hi Travis,

Currently the Store SCU component offers a long list of Transfer syntaxes for the image to be stored.
Each TS offered is a new presentation context.

I noticed that the high level store client demo app has an option to select either single or multiple presentation contexts for the c-store request.

Is this option also available in the store scu code?

I believe you are comparing the Low Level Store Demo to the High Level Store Demo.

The High Level Demo is using our StoreSCU object.  This object does not have the option to send all the Transfer Syntax in on Presentation Context.  If you like, I can add a request to add this feature.

If so, please send an email to support@leadtools.com referencing this forum post (using the URL) and I will link you to the request to contact you once it is added.

Is it very common to use one Presentation context for each transfer syntax, or is sending one presentation context with multiple transfer syntaxes more common?

Hi Travis,

A bit more information why i've asked for this information.

We have implemented the store of images (as part of DICOM QR). When we peform the c-move request to the SCP, we noticed that leadtools offers around 10 transfer syntaxes for each SOP Class.

This of course looks nice, but also means that leadtools should be able to recompress the image into any of the other offered Transfer syntaxes if the SCP accepts that TS only.

What we would have actually is:
1. Have controll over the Transfer syntax(es) we offer for an image (for example TS of image, and one other mandatory TS for DICOM). This way we limit recompression requirements.

2. Offer all transfer syntaxes (as currently) but also be able to recompress in all these TS's. Currently recompression into some TS's work.

Thanks in advance.

Using the StoreSCU class:

1) If you'd like to remove any TS from the association, you can handle the BeforeAssociateRequest event.  We give you access to the association class where you can enumerate all the Presentation Context and remove any you do not wish to offer to the server.
2) LEADTOOLS should be able to change the transfer syntax of all the TS is offers.  If you're finding this is not the case, please let know the conditions to reproduce this issue.

Hi Travis,

It looks indeed like we can controll the offered TS's, however we are unable to detect which of the offered TS's are accepted by the SCP. (we are currently using framework storescu component)

At this point, I would suggest taking a look at the documentation for this object as you would be able to tell from all the events we issue for this object that the AfterAssociateRequest will provide you with this information:

http://www.leadtools.com/help/leadtools/v175/dh/scu/leadtools.dicom.scu~leadtools.dicom.scu.storescu_members.html