C-Strore for SM big files

Google Groups archive
1

I have Orthank server under linux

/usr/sbin/Orthanc 1.5.6
Copyright (C) 2012-2016 Sebastien Jodogne, Medical Physics Department, University Hospital of Liege (Belgium)
Copyright (C) 2017-2019 Osimis S.A. (Belgium)
Licensing GPLv3+: GNU GPL version 3 or later <http://[gnu.org/licenses/gpl.html](http://gnu.org/licenses/gpl.html)>, with OpenSSL exception.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Sebastien Jodogne <s.jodogne@orthanc-labs.com>

C-Store does not works with SM modality for big files (>800Mb). Smaller files with the same format works without any problems. From Dicom side - no errors, no aborts, everything is OK. But really image does not appears in the storage.

Log file with --verbode

I0508 10:27:25.007579 CommandDispatcher.cpp:511] Association Received from AET HLS001 on IP 127.0.0.1 I0508 10:27:25.007975 main.cpp:195] Incoming connection from AET HLS001 on IP 127.0.0.1, calling AET TESTARCH I0508 10:27:25.008065 CommandDispatcher.cpp:714] Association Acknowledged (Max Send PDV: 16366) I0508 10:27:25.111568 main.cpp:215] Incoming Store request from AET HLS001 on IP 127.0.0.1, calling AET TESTARCH

Says nothing.

2

Please provide a sample (possibly anonymized) DICOM file, and instructions for us to reproduce this issue (e.g. using storescu from DCMTK).

The issue may reside in your DICOM client.

3

Here is a sample file.

https://drive.google.com/file/d/1iDXirAPjkShJfAvfDJpskUhvL-3umbkA/view?usp=sharing

Case 1 - upload from http UI - fails.
Case 2 - upload from java - fails.
Case 3 - upload the same file but resampled (smaller) from http UI - success.
Case 4 - upload the same file but resampled (smaller) from java - success.

4

Hello

What I can already see is that dciodvfy.exe sees many errors in your dicom file (https://www.dclunie.com/dicom3tools/dciodvfy.html)

Furthermore, the RadiAnt dicom viewer is unable to open it.

(strangely, the file begins with 128 null bytes)

Could you maybe check with your modality or pacs vendor?

Also, I am wondering how you managed to open this file to resample it (what tool did you use).

Thanks

5

File contains custom tag (0x0011,0x0001) with explicit VR syntax OB.

It sounds strange, but dicom3tools replaces this VR to LO. That’s why you see errors.

See details on https://github.com/malaterre/dicom3tools/blob/master/CHANGES

070121: libsrc/src/dctool/attrmxrd.cc: make private creator LO under all circumstances, even if explicit VR is not LO, so as to recognize subsequent private tags (000194)

dicom3tools is not objective because we use legal range for custom tag, explicit VR, and 100% legal syntax and format.

I’ll try this test again but without this custom tags.

6

Here is a file

https://drive.google.com/file/d/1LvW60XQP4SGrDnFuG2IOA4u8g5pPgbjg/view?usp=sharing

Without validation errors and with the same problems.

7

Hello

I managed to import your original file without problems using Orthanc 1.5.6 64 bits under Windows

It looks like a resource problem to me. How much available ram do you have? Are you able to give it a try with more usable memory?

(It could be that Orthanc requires twice the dicom file size upon import (I seem to recall that a memory buffer copy was difficult to avoid)

If the memory limit is the culprit, being able to reproduce your issue without having to remove ram modules could be nice. Do you happen to know how we can emulate this constrain under Linux (maybe with Docker) ?)

Tia

8

Hello,

I confirm that I can successfully send your DICOM SM file to Orthanc, both using the REST API and the “storescu” command-line tool.

Let’s start Orthanc using Docker:

$ sudo docker run -p 4242:4242 -p 8042:8042 --rm jodogne/orthanc:1.5.6

In another terminal, here is how I import using the REST API:

$ curl -u orthanc:orthanc http://localhost:8042/instances --data-binary @2019-05-24-AnananaKukukuku-LargeSM.dcm
{
“ID” : “7f3a8b45-79e41d29-69d6aead-5c18d6fb-7bdfd5d0”,
“ParentPatient” : “5ef8c4fe-fd7a14e0-79a09e98-75f08d0f-207577cb”,
“ParentSeries” : “78a8fc85-e242893e-18ed60b6-724471b6-0cec29a0”,
“ParentStudy” : “721b6a72-8ca334d7-c4ce1e1c-ea848f8a-be0b5d74”,
“Path” : “/instances/7f3a8b45-79e41d29-69d6aead-5c18d6fb-7bdfd5d0”,
“Status” : “Success”
}

And here is how I import using the “storescu” command line:

$ storescu -v -xf ./UnknownSopClassUid.cfg Default localhost 4242 ~/2019-05-24-AnananaKukukuku-LargeSM.dcm
I: checking input files …
I: Requesting Association
I: Association Accepted (Max Send PDV: 16372)
I: Sending file: /home/jodogne/2019-05-24-AnananaKukukuku-LargeSM.dcm
I: Converting transfer syntax: Little Endian Explicit → Little Endian Explicit
I: Sending Store Request (MsgID 1, VLw)
XMIT: …

I: Received Store Response (Success)
I: Releasing Association

You can find the file “UnknownSopClassUid.cfg” used above in our integration tests:
https://bitbucket.org/sjodogne/orthanc-tests/src/default/Database/UnknownSopClassUid.cfg

So, as explained by Benjamin, the problem is most probably insufficient resources on your computer. Are you using a 64bit version of Orthanc?

Sébastien-

9

I confirm that I can send my DICOM SM file to Orthanc after increase RAM to 4Gb.

BTW Orthanc responds success in case when RAM is not enough for complete operation. I think it’s wrong.

10

Thanks for the feedback.

Regarding your question about “Orthanc responds success in case when RAM is not enough for complete operation”, please could you provide a full scenario for us to reproduce the issue?