"data received too short" error when sending image

[jarek_w]

Hi All,
This forum is the last instance I can ask my question. Maybe someone has encountered something similar. I have some Ultrasound dicom files that I am trying to send using foDicom to a third party PACS. The remote Store SCP aborts the process. After some debugging I was able to tell that it happens when Pixel Data part starts to be sent. There is no reason given in response nor additional info. Just hard abort.  On the other side, the log just says "data received too short" so it seems like it expects more data than it gets but I have no idea why. Is there anything I can do on my side to sort it out? I tested it with dcmtk offis storescp and sending goes ok. I am sending lots of files and only with these US exams I have the issue.

Best regards
Jarek

[Anders Gustafsson Cureos AB]

Hi Jarek,

I recommend that you switch on logging to get more information of what is going on in the Send operation:

var client = new DicomClient();

client.Logger = <some logger instance>

client.Options = new DicomServiceOptions { LogDataPDUs = true, LogDimseDatasets = true };

Regards,

Anders @ Cureos

[jarek_w]

Hi Anders
Thanks for your reply. I set up extended  logging as you said. The last lines look like that below (I did not paste the whole log but I can do that if necessary):
[..cut..]
(0028,0103) US 0                                                #     2, PixelRepresentation
(6301,0010) LO [XXXXX_PRIVATE]                                  #    14, PrivateCreator
(6301,1001:XXXXX_PRIVATE) IS [0]                                #     2, Unknown
(6301,1002:XXXXX_PRIVATE) IS [0]                                #     2, Unknown
(7fe0,0010) OW <skipping large element>                         #2173275, PixelData

--------------------------------------------------------------------------------

09:04:22  PACSSTORAGE -> P-DATA-TF [Length: 16384] PDV [PCID: 1; Length: 148; Command: True; Last: True] PDV [PCID: 1; Length: 16218; Command: False; Last: False]
09:04:22  PACSSTORAGE -> P-DATA-TF [Length: 16384] PDV [PCID: 1; Length: 16372; Command: False; Last: False]
............. [ a lot of lines like the one above come here...]
09:04:22  PACSSTORAGE -> P-DATA-TF [Length: 13389] PDV [PCID: 1; Length: 13377; Command: False; Last: True]
09:04:22  PACSSTORAGE <- Abort: Unknown - NotSpecified
09:04:22  Connection closed

Is there any conclusion you could draw out of that?
Thanks and regards
Jarek

[Anders Gustafsson Cureos AB]

Jarek,

Which fo-dicom version are you using? Can you also please post the code you are using to make the Send call?

Regards,

Anders

[jarek_w]

Hello Anders,
I am using 1.0.38. My code I use for testing now is:

                [...]

                var client = new DicomClient();

                client.Options = new DicomServiceOptions { LogDataPDUs = true, LogDimseDatasets = true };

                var rq = new DicomCStoreRequest(@"e:\test\sendout\test.dcm");
                rq.OnResponseReceived += delegate(DicomCStoreRequest req, DicomCStoreResponse response)
                {
                    var status = response.Status;
                };
                client.AddRequest(rq);
                client.Send("127.0.0.1", 104,false, "MyTestAET", "PACSSTORAGE");
                [...]

[Anders Gustafsson Cureos AB]

Please update to the latest version (2.0.2) and try again. There have been numerous changes lately that are likely to have an impact on your issue.

Regards,
Anders

[jarek_w]

OK. Will update and come back with results. Thanks a lot so far.
Best regards
Jarek

[jarek_w]

Hi Anders,
I tested with 2.0.2 - the same story. Maybe the problem is located on the other side. I will try to get in hold of the other toolkit makers... Just wanted to make sure there is nothing obvious I can do on my side before I call them.
Peace and best...
Jarek

[jarek_w]

Hello Anders,
I have another question, possibly related to the above problem:
When receiving an image, fo-dicom always re-encodes it to LEI. Is there a way to prevent it and keep the encoding as is (in this case JPEG.70)? Am I missing some setting?

Best ragards

Jarek

[Anders Gustafsson Cureos AB]

Hi again Jarek,

are you using the C-Store SCP example for receiving DICOM files? Have you modified it in any way?

Regards,

Anders

[jarek_w]

Hello Anders,
When setting AcceptedImageTransferSyntaxes in OnReceiveAssociationRequest event, I set the scpPriority to true, and now it seems to work ok.

regards
Jarek

[Anders Gustafsson Cureos AB]

Jarek,

Good to hear that you have managed to work things out. It is not entirely obvious to me right now why the solution you chose worked, but I'll look into that when time permits. Thanks for reporting!

Regards,

Anders

[jarek_w]

Hi Anders,
Correct me if I am wrong, Could it be that the SCU somehow proposed LEI as top-priority TS in the handshake? I  know it is strange, because it should be the image TS that comes first... So when I forced fo-dicom to use its own TS priority, it took the right (image) TS and the SCU did not have to re-encode. I will examine dicom logs to verify that. Thanks for your time anyway and best regards.

Jarek

[Anders Gustafsson Cureos AB]

Correct me if I am wrong, Could it be that the SCU somehow proposed LEI as top-priority TS in the handshake?

Maybe? I'll keep that in mind when examining later on. Thanks!

Anders

[jarek_w]

Hello Again,
Is there a way to have fo-dicom propose Presentation Contexts in a form :
PresentationContext1
Abstract Syntax1 - Transfer Syntax1
PresentationContext2
Abstract Syntax1 - Transfer Syntax2
...
instead of
PresentationContext1
Abstract Syntax1
    Transfer Syntax1
    Transfer Syntax2
..
this would sometimes save re-encoding.
?

Kind thanks for any answer on that.

Jarek

[jarek_w]

I found the answer myself: yes, it can be achieved adding an AS with single TS to AdditionalPresentationContexts list property within DicomClient.

Thanks Jarek

[jarek_w]

Hello Anders,
I have some next debug info that hopefully will help in diagnosing the problem with aborted send. Now it happens for an SC image. I used different SCP, and its log says there is a fragment with an odd length sent. The message is like this: DIMSE Failure (aborting assoc): 0006:020d DIMSE: Odd Fragment Length.It looks that the odd fragment of pixel data is not null-padded when being sent.from foDicom.
Thanks
Jarek

[Anders Gustafsson Cureos AB]

Thanks for reporting, Jarek!

Sounds like something we need to look closer into. Could you please create a Github issue where you describe the problem in detail and add an anonymized copy of the file you are having problems with?

Thanks in advance!

Anders