Orthanc exporting
951 views
Skip to first unread message
Mark Hodge
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.
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
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
Is there a faster way to export DICOM's from Orthanc?
Cheers,
Mark
Alain Mazy
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 S.A.
|
Mark Hodge
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
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
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
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
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
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
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