Orthanc exporting

576 views
Skip to first unread message

Mark Hodge

unread,
Jun 14, 2016, 1:41:16 AM6/14/16
to Orthanc Users
Hi folks.

I'm looking at using Orthanc as a destination for a Siemens 3T Skyra that is in the process of being installed (in case it turns out the scanner cannot export DICOMs to network shares for our research groups*).

Initially I was planning to use it to be our repository of data as well, not being familiar with Orthanc and therefore not knowing security and multi tenancy were not part of it's feature set.

Since I confirmed that was the case I have looked at using Orthanc as a target to receive the scans and then export them as DICOM's from Orthanc onto a share for researchers to access.

Initially our operations team would manually download DICOM directories as they came in, and we would scope and put together scheduled tasks to use Orthanc's API's to automate the DICOM exporting to appropriate folders on a file share based on DICOM tags or another unique identifier.

I hope this all makes sense - the PACS/DICOM sphere is all new territory for me and the team here.

I've run into an unexpected obstacle however.

If I upload an example DICOM scan from a group with the same scanner model it uploads as expected into Orthanc, but if I then export it as a DICOMDIR, delete the patient from Orthanc, and re-import the exported DICOMDIR, the number of instances is less in the original - one with 410 instances only shows 361 for example.

Is this expected - is it possible I am not understanding something here or doing something wrong??

Cheers,
Mark


* If anyone has a Siemens 3T Skyra and can confirm it is able to export DICOMs to a share that would also be great to know as we are not the owners (we will be leasing time on it) and don't have much in the way of information about what it can do in regards to exporting of data.

Mark Hodge

unread,
Jun 17, 2016, 1:44:31 AM6/17/16
to Orthanc Users
Okay, I'm now at the stage of successfully automatically exporting a DICOM to specific folders on a share based on the StudyDescription tag using a modified AutoClassify.py, but each instance takes about 5 seconds to export so my small (1662 instance) example patient record takes almost 2.5 hours to write.

Is there a faster way to export DICOM's from Orthanc?

Cheers,
Mark

Alain Mazy

unread,
Jun 17, 2016, 3:10:39 AM6/17/16
to Mark Hodge, Orthanc Users
This should not take that long for sure.

I know this might looks like a weird suggestion but on some systems (I have seen it with python scripts running on Windows), addressing 'http://localhost' sometimes takes 1 second while 'http://127.0.0.1' is immediate.  Could you give it a try ?


--

Alain Mazy / CTO 
a...@osimis.io / +32 494 31 67 27

Osimis

OSIMIS S.A. 
Rue bois Saint-Jean 15/1BE-4102 Seraing 
www.osimis.io

Twitter LinkedIn


Mark Hodge

unread,
Jun 17, 2016, 3:28:06 AM6/17/16
to Alain Mazy, Orthanc Users
Thanks Alain, I will give that a try on Monday (Friday evening here now in New Zealand :-)).

Cheers,
Mark
-- 
________________________________________________________________________________

NextGen Games, 357 North Road, Dunedin         Phone: +64 3 473 0391/021 614 134
http://nextgengames.twilightparadox.com/            Email: markh...@gmail.com
________________________________________________________________________________
View our sleeveguide at http://nextgengames.twilightparadox.com/sleeveguide.html 
    Check out http://www.mightyape.co.nz/?r=1649874 for everything else.

Sébastien Jodogne

unread,
Jun 18, 2016, 9:07:09 AM6/18/16
to Orthanc Users
Hello,

Regarding this speed problem, if you use Windows, please make sure to disable IPv6 support, as it might slow down HTTP requests. This is discussed in the FAQ:

If you use Linux and you experience slow DICOM transfers, please read the following bug report:

The problem vanishes if asking Orthanc to statically link against DCMTK by using the "-DUSE_SYSTEM_DCMTK=OFF" flag when invoking CMake.

HTH,
Sébastien-

Sébastien Jodogne

unread,
Jun 19, 2016, 8:17:56 AM6/19/16
to Orthanc Users
Back to your original question:
 
If I upload an example DICOM scan from a group with the same scanner model it uploads as expected into Orthanc, but if I then export it as a DICOMDIR, delete the patient from Orthanc, and re-import the exported DICOMDIR, the number of instances is less in the original - one with 410 instances only shows 361 for example.
Is this expected - is it possible I am not understanding something here or doing something wrong??

This is obviously not expected. I suspect that your original DICOMDIR gathers instances from several, different patients (which is permitted by the DICOM standard). If you export only one single patient from Orthanc, you will of course obtain fewer instances. This is just an hypothesis that would explain your problem, please double check.

If the problem persists, please post sample a sample DICOMDIR archive in this forum so that we can reproduce your issue.

HTH,
Sébastien-

Mark Hodge

unread,
Jun 20, 2016, 7:14:39 PM6/20/16
to Alain Mazy, Mark Hodge, Orthanc Users, s.jo...@gmail.com
Thank you Alain - that made a massive difference.

Sébastien, would it be worthwhile changing the example AutoClassify.py python script to use this value?

ie.,
parser.add_argument('--host', default = '127.0.0.1',
rather than
parser.add_argument('--host', default = 'localhost',

Unless there is a reason for it to be this way that is platform related? In which case a commented section to say use 127.0.0.1 in place of localhost if someone is using Windows Server and finds the export script taking seconds per instance might be useful.

I also see that the original scan I am using contains all files in a single directory with file names in the form:

MR.1.3.12.2.1107.5.2.19.45016.2015052514122417050291576
but the export has them within sub directories and has names omitting the MR at the front (and adding dcm at the end as a file extension) as below:
1.3.12.2.1107.5.2.19.45016.2015052514122417050291576.dcm

Is the lack of MR of any significance whatsoever? The dcm seems reasonable in that some software may expect .dcm extensions (speaking as someone who is new to DICOM and Orthanc).

Cheers,
Mark
-- 
______________________________________________________________________________
Mark Hodge BSc,DipLang,MCSA,MCSE,CTM,CL                  Systems Services Team
Systems Engineer                               Infrastructure and Applications
Phone: +64 3 479 8598/021 614 134              Information Technology Services
Fax:   +64 3 479 5080                                      University of Otago
Email: mark....@otago.ac.nz                  PO Box 56, Dunedin, New Zealand
______________________________________________________________________________
 Things turn out best for those that make the best of the way things turn out

Sébastien Jodogne

unread,
Jun 21, 2016, 3:52:14 AM6/21/16
to Orthanc Users, a...@osimis.io, markh...@gmail.com, s.jo...@gmail.com, mark....@otago.ac.nz
Dear all,


On Tuesday, June 21, 2016 at 1:14:39 AM UTC+2, Mark Hodge wrote:
Thank you Alain - that made a massive difference.
Sébastien, would it be worthwhile changing the example AutoClassify.py python script to use this value?

Thanks for the feedback!

As suggested, I have just adapted the samples from the source distribution:

I have also reported this information in the FAQ of the Orthanc Book:


 
I also see that the original scan I am using contains all files in a single directory with file names in the form:
MR.1.3.12.2.1107.5.2.19.45016.2015052514122417050291576
but the export has them within sub directories and has names omitting the MR at the front (and adding dcm at the end as a file extension) as below:
1.3.12.2.1107.5.2.19.45016.2015052514122417050291576.dcm
Is the lack of MR of any significance whatsoever? The dcm seems reasonable in that some software may expect .dcm extensions (speaking as someone who is new to DICOM and Orthanc).

The DICOM standard is inherently thought as a way to exchange information between medical imaging applications: It does not say much things when leaving DICOM networking. It notably does not impose anything about how DICOM files should be named outside a DICOMDIR archive (in a DICOMDIR, filenames must basically be DOS paths with less than 8 characters, without an extension [1]).

As a consequence, when exporting outside of a DICOMDIR media, the prefix "MR.", the extension ".dcm" or even the filename ("1.3.12.2.1107.5.2.19.45016.2015052514122417050291576") can be freely chosen by the application. Orthanc uses the ".dcm" extension, as it is a widespread convention (e.g. in ImageJ).

HTH,
Sébastien-



Reply all
Reply to author
Forward
0 new messages