Experiment with Orthanc
Look at Orthanc as an alternative DICOM store server.
0.8.0 docs need a robust set of instructions for the store server, and Conquest is proving to be more difficult to install than I had realised.
Comments (93)
-
reporter -
reporter @dplatten - I think Orthanc would be an easy enough install to Linux. The script I have written would need the temp location to be factored out and the logic regarding which objects to launch with which script and which ones to delete needs to be added, but it all looks very doable.
I see that the binaries for Windows require filling in a form and having the prospect of the commercial backer contacting you. Does that present an issue? Or is it fairly painless?
By the way, I tried using the path to the virtualenv python in that script and it works as I'd hoped.
There was an initial issue with my orthanc install, but it was due to an issue it had with the DCMTK private dictionary - I don't know yet if that was specific to my install or a more generic problem. I can work around it in the docs if necessary.
-
I haven't tried installing it yet. I have downloaded the Windows binaries, and that was painless enough.
Perhaps this should wait until the next release of OpenREM. Have you managed to iron out the issues with Conquest installation on Linux? I haven't tried the latest version of the Windows release yet.
-
reporter Not entirely. Part of the problem is that if you aren't using the Ubuntu 16.04 packaged version of Conquest, the install requires the software to be built from source and folders are created all over the place. It is generally automated, but prompts for sudo to give itself permissions which is bad practice for something downloaded off the internet! I don't like to encourage such activity! You then need to add some scripts to get it started automatically, which means more documentation to write.
I would really like to say 'yes', leave this to the next release. But we need docs that work for this release. So I need to either write them for Conquest, aware that it is messy and the current release is broken for linux so needs to be patched (or delay the release further to wait for the patch to be incorporated), or we offer basic instructions for Conquest or for Orthanc and let the user decide. Another problem I guess is that we haven't actually used Orthanc in anger.
-
reporter Now drops any non SR/CT/MG/CR/DX modality objects, and processes what's left against the appropriate import script. Doesn't cater for Toshiba CT. Refs
#635→ <<cset 6c2a0a996f95>>
-
reporter There is a lua plugin for PyCharm @dplatten: https://plugins.jetbrains.com/plugin/5055-lua (there are a couple actually, not sure what the difference is between them).
-
reporter Added stub for Toshiba, plus exiting function early if we won't be using it. Refs
#635→ <<cset 84d2571aafba>>
-
reporter Links for sorting out the Toshiba bit:
From this question: https://groups.google.com/forum/m/#!topic/orthanc-users/hUEt93SPUfM
This is a python script that I think is run manually against the Orthanc server to copy it's contents to disk: https://bitbucket.org/sjodogne/orthanc/src/default/Resources/Samples/Python/AutoClassify.py?fileviewer=file-view-default
And this is a lua function that does it when the series is stable: https://bitbucket.org/sjodogne/orthanc/src/b97aa579e85bc57652d5ac8a2e45ce77a1e203d7/Resources/Samples/Lua/WriteToDisk.lua?at=default&fileviewer=file-view-default
Problem with the second one is the platform specific call to make directory.
-
See here for some info on avoiding the platform-specific mkdir: https://stackoverflow.com/questions/1690913/how-to-create-a-directory-in-lua
-
@edmcdonagh, in your
openrem.lua
script, what folder shouldopenrem_exe_path
point to on my Windows system (running OpenREM in a virtualenv)? -
I've answered my own question: it's the folder that contains the import scripts. For me, this is the same folder that the virtualenv python.exe is in.
-
reporter Likewise for me. But I thought it wouldn't hurt to have both! And partly because I'd already decided to have the full path to python as a variable.
-
I've installed Orthanc on my Windows test system. I edited the
orthanc.json
file inC:\Program Files\Orthanc Server\Configuration\
to include theopenrem.lua
file that @edmcdonagh has created. Note the double backslashes:// List of paths to the custom Lua scripts that are to be loaded // into this instance of Orthanc "LuaScripts" : [ "D:\\David\\Documents\\Code\\Python\\OpenREM\\BitBucket\\openrem\\stuff\\openrem.lua" ],
I then created a temp folder on my hard drive (
D:\David\Temp\
) and edited theopenrem.lua
file to reflect my virtualenv and the new temp folder:local python_path = 'D:\\David\\Documents\\Code\\Python\\OpenREM\\testbed\\openrem_develop\\Scripts\\python.exe' local openrem_exe_path = 'D:\\David\\Documents\\Code\\Python\\OpenREM\\testbed\\openrem_develop\\Scripts\\' local temp_path = 'D:\\David\\Temp\\'
I then moved to the OpenREM folder that contains the test DICOM files and used the DCMTK
storescu
command to send some of the test files to Orthanc (which would hopefully use the Lua script to import them into OpenREM):storescu -aec ORTHANC localhost 4242 DX-Im-Carestream_DR7500-1.dcm storescu -aec ORTHANC localhost 4242 MG-Im-GE_Seno_1_ForPresentation.dcm storescu -aec ORTHANC localhost 4242 RF-RDSR-Siemens-Zee.dcm
This worked perfectly - the studies are now in OpenREM.
I don't have access to a Toshiba study to play about with importing that right now.
-
RE the mkdir platform-specific issue. I don't know if we can install additional Lua libraries to work with Orthanc. However, we could have an additional variable at the top of the
openrem.lua
script calledmkdir_cmd
that is platform-specific:-- Windows mkdir_cmd; creates directory trees by default -- mkdir_cmd = 'mkdir ' -- Linux mkdir_cmd; requires the -p switch to create directory trees -- mkdir_cmd = 'mkdir -p '
-
Updated file so that it should work for Toshiba CT studies. Tested with test for Tosh CT removed on simple Dx study and works. Not tested the actual Toshiba import or the bit that removes the instances from Orthanc [skip ci]. References issue
#635→ <<cset 63bdfbb55d5a>>
-
Putting the delete instanceID back in [skip ci]. References issue
#635→ <<cset 473b77729c98>>
-
The time for a study to be considered stable defaults to 60 s. This is set in the
StableAge
item in the configuration.It may be wise to increase this for the Toshiba CT extractor to work in case some images are slow to retrieve.
-
Corrected instance variable; made Philips import more explicit, as I think the Toshiba dose summary iamges are the same type [skip ci]. References issue 635
→ <<cset bf6ccf47b89c>>
-
reporter Renaming path to temp_fle_path and temp_files_path. Refs
#635. [skip ci]→ <<cset ca546aeee01a>>
-
reporter Missed one of the commented out references to path. Refs
#635. [skip ci]→ <<cset ce0282053f42>>
-
reporter Removing the duplication of python path and python bin path. Refs
#635. [skip ci]→ <<cset b470de5d0c42>>
-
reporter Initial draft doc of Orthanc config. Doesn't cover installation and initial setup (that will be in different doc). Refs
#635. [skip ci]→ <<cset c6b73f627495>>
-
reporter Correcting various errors and a few style changes. Refs
#635. [skip ci]→ <<cset 1b5b9d31de34>>
-
reporter Added stub to remind me to put something about permissions. Refs
#635. [skip ci]→ <<cset 8a90f6c430fb>>
-
reporter I have made some changes to the
openrem.lua
file whilst I have been writing up the process, which I haven't tested properly.Docs are here: http://docs.openrem.org/en/issue635orthancexperiment/netdicom-orthanc-config.html
-
Added restart instructions for Windows [skip ci]. References issue 635
→ <<cset 04ec59d7d5a4>>
-
Amended Toshiba CT section so that it now works. Not fully tested yet. I can also confirm that this imports DR/DX correctly. I have changed the user-defined local variables as on my live system python.exe is in a different folder to the python scripts [skip ci]. References issue
#635→ <<cset b0b623cb699c>>
-
Amended Toshiba CT section so that it creates a single folder rather than a nest of folders. This enables the Toshiba CT extractor to cleanly remove it once imported into OpenREM. I can confirm that this imports DR/DX, RDSR, Philips CT objects and older Toshiba CT data correctly. One of the issues I can see is that any non-Toshiba, non-Philips, non-RDSR CT data is currently deleted. Some of these can be imported with the Toshiba CT extractor [skip ci]. References issue
#635→ <<cset 0f68ea998e40>>
-
Amended Toshiba CT section so that it keeps physics studies. Also enabled Toshiba CT extractor for a range of CT systems that I know have worked with the extractor in the past. I think that the check for physics studies may fail if either the patient name or id are blank - need to check for nil in the script before using the values [skip ci]. References issue
#635→ <<cset c9c3d5198a98>>
-
Large changes to the file. The user can configure lists of manufacturer, model, station name, software version and serial numbers of systems to be ignored. This is useful to avoid importing things like computed radiography and specimen cabinet images into OpenREM. The user can now also configure a folder to keep physics test images in, and set a list of strings that are used in the patient name or id that indicate it is a physics test. There is also now a list of make/model pairs of CT scanners whose data can be successfully extracted with the Toshiba CT extractor [skip ci]. References issue
#635→ <<cset f1457193408c>>
-
Correcting typo and removing superfluous variable [skip ci]. References issue
#635→ <<cset 9be97e2f21d6>>
-
The Orthanc openrem.lua script is now working well on my live system.
- The modalities are imported
- The "ignore" lists are adhered to
- The "physics" list works, saving physics files to the specified folder in a sensible structure
I have set the
StableAge
inorthanc.json
to 600 s on my install because when I retrieve old studies there are sometimes delays in some images being sent from PACS.As an aside, the automatic export of physics images to a folder may become unnecessary if I can work out how to use the Orthanc ImageJ plugin functionality on a 64-bit Windows installation (https://www.orthanc-server.com/static.php?page=imagej). I've got it to work on Ubuntu 16.04, but my live system is 64-bit Windows - I think it requires the Orthanc plugin to be compiled from source.
-
reporter Thanks for all the work you've put in there.
Can we re-merge the python path and python executable variables?
-
reporter Regarding physics images, would you propose that the imageJ plugin would allow you to leave your Physics images in the orthanc database, then use the imageJ browser to find and analyse your QA images?
-
reporter Does having a scanner match in the Tosh section not mean it won't be imported via RDSR?
-
From my experience so far I think Orthanc is easier to use than Conquest.
I'll merge the
python_executable_path
andpython_executable
together into one variable.For my install I'm concerned that I don't have enough storage space to start collecting physics images; I may set up OpenREM's Orthanc to forward any physics images to another Orthanc install on a different computer. I'm not sure how useful the ImageJ plugin will be, but I think it would simplify things for our testing here.
On the Tosh question: you're right. My logic is flawed for the case where an RDSR arrives in Orthanc that matches the Toshiba CT criteria. In that case the RDSR is never imported in the usual way, and instead the Toshiba CT extractor will be run (I don't deal with any Toshiba RDSRs, so hadn't thought of this). I'll need to put the Toshiba extractor in a
if import_script == '' ... end
block, so it's only used if there's been no match earier.
-
I have now addressed these in commit 93d9471, but it's not showing against the issue for some reason.
-
reporter It was the Flash etc that caught my attention in the toshiba_extractor_systems...
-
I've had all manner of CT models pulled into OpenREM from PACS - even some systems from the Royal Marsden. The result from the Toshiba extractor is just the RDSR that pixelmed.jar creates. So I think the Toshiba extractor will work for any CT make / model that pixelmed.jar can produce an RDSR for (it just won't include all the detail that you'd get with an RDSR created by the CT scanner itself).
-
reporter That's the hazard of using QR to the PACS! My PACS team put 'imported' in the study description, which makes it relatively easy to filter out.
-
I've just updated my live system with the latest version of
openrem.lua
. -
reporter Initial attempt to revamp the docs for the current version of the Orthanc lua script. Refs
#635, [skip ci]→ <<cset 7ee590620449>>
-
reporter Experimenting with other layouts. Refs
#635, [skip ci]→ <<cset dbc10777af4e>>
-
reporter Corrected link to raw version. Cut out some of the more obvious bus now you can see the original with comments. Need to do more along those lines, and increase the explanations. Also need to remove some of the examples that aren't useful for @dplatten, but might be useful elsewhere (eg Afga). Refs
#635. [skip ci]→ <<cset 690129f269be>>
-
It's possible to obtain data from a Lua table in two ways:
local tags = {["AcquisitionDate"] = "20140620", ["AcquisitionTime"] = "105152"} -- Access using the name in quotes, surrounded by square brackets: print(tags['AcquisitionDate']) -- Access using .name (only works if no spaces in the name): print(tags.AcquisitionDate)
We're using the quotes inside square brackets method in the
openrem.lua
file at the moment. The dot method results in shorter code. I don't think that the DICOM elements we're accessing ever have spaces in the names.I think it's also worth noting that local variables in Lua have a scope that is restricted to the current block of code. If you declare a local variable inside an
if
statement then you can't access it outside that statement. This is new to me. -
reporter All DICOM tags have a no space version. And I noticed the scope issue because of how PyCharm highlighted them!
-
Changed syntax from
table['x']
totable.x
when accessing items in tables - I think it is tidier. I've also removed unused function parameters. These changes are untested. I wonder if we should enclose theOnStoredInstance
code in anif origin['RequestOrigin'] ~= 'Lua' then
block. This is used in an example to avoid infinite loops (http://book.orthanc-server.com/users/lua.html#important-remarks-about-auto-routing) [skip ci]. References issue#635→ <<cset f757275971d5>>
-
Missed a dot [skip ci]. References issue
#635→ <<cset a2e111be9b93>>
-
Added zipping of physics studies - tested and working as expected on Windows with 7zip [skip ci]. References issue
#635→ <<cset c799ebf54b04>>
-
Write details of any rejected DICOM instances to the Orthanc log file [skip ci]. References issue
#635→ <<cset 913e5e2126fa>>
-
Added some checks for nil Manufacturer and ManufacturerModelName tags; this has tripeed up my live Orthanc install (a Secondary Capture image of a contrast enhancement chart was the culprit) [skip ci]. References issue
#635→ <<cset 11dc4d2550a0>>
-
reporter What's the best way @dplatten of allowing a user to disable the
physics_to_keep
functionality and probably thetoshiba_extractor_systems
too, as installing the extra stuff is optional?Set the following?
local physics_to_keep_folder = '' local zip_executable = '' local rmdir_cmd = '' local physics_to_keep = {} local toshiba_extractor_systems = {}
-
reporter Added in the extra settings (not yet referenced), changed the format of the customisation guide agin. Refs
#635, [skip ci]→ <<cset 942559a16c20>>
-
Just the following will work:
local physics_to_keep = {} local toshiba_extractor_systems = {}
Commit to follow in a minute.
-
Corrected an earlier error (tried to delete instance rather than study). Physics images now only kept if element [1] of physics_to_keep is present. Toshiba CT extractor now only run if element [1][1] of toshiba_extractor_systems is present [skip ci]. References issue
#635→ <<cset 9a17bca62fa9>>
-
reporter Thanks. Which user does Orthanc on Windows use? Is there a permissions issue with the temp files location or the logs?
-
reporter Fixed syntax issue. Added nil value for physics and toshiba. Added link to toshiba resources. Refs
#635, [skip ci]→ <<cset ae172f276bc7>>
-
reporter Hopefully correcting link. Refs
#635, [skip ci]→ <<cset 96a14759b939>>
-
Orthanc required administrator rights to be installed on my Windows server. As part of the installation it installs itself as a service called
Orthanc
which runs under theLocal System
user. It is automatically started during install, and is set to autostart when the computer boots. There's been no issue with the Orthanc logs (they do require admin rights to delete); I created the temp files location as a normal user: there's been no issue with Orthanc being able to put images in it, or to delete them.All-in-all I feel the install and set up is much easier than Conquest, but that could just be me.
-
@edmcdonagh, I think we should perhaps have boolean
enable_toshiba_CT_extractor
andenable_physics_filtering
variables to control whether these two features are active. This would be clearer to the user. -
Added variables to enable/disable physics studies and Toshiba CT extractor sections. Changed a couple of variables to boolean where appropriate [skip ci]. References issue
#635→ <<cset 964d1bdfc2ae>>
-
Replaced the i and j key variables in several loops with a placeholder (_). Removes the final PyCharm criticisms of the code - I now have a green tick [skip ci]. References issue
#635→ <<cset f2c005ece3c3>>
-
Updated Windows service restart section, and included a Toshiba scanner in the tosh list. Documentation changes only [skip ci]. References issue
#635→ <<cset 6a2ffebc6dfc>>
-
reporter Spelling correction and additional comments to lua file. Updated docs. Refs
#635, [skip ci]→ <<cset 58ca6f1f7fd2>>
-
reporter Removing redundant {} instructions Updted permissions section. Refs
#635, [skip ci]→ <<cset 6fb110681254>>
-
reporter Small change to remove duplication of the word 'linux'. Refs
#635, [skip ci]→ <<cset d8c397d01831>>
-
reporter Promoted Orthanc in the DICOM Store section, added it to the installation prep doc. Refs
#635, [skip ci]→ <<cset 39cbf6e8c91b>>
-
reporter Added quickstart to install prep. Refs
#635, [skip ci]→ <<cset aded938653c6>>
-
reporter Addded installation of OpenREM and pynetdicom to quickinstall. Refs
#635, [skip ci]→ <<cset d7dda49df902>>
-
Added some checks for nil when writing reject message to log. This failed due to a missing software versions tag in some CT images [skip ci]. References issue
#635→ <<cset bdf5eaa94d65>>
-
Added further checks for nil before using tags. I think this covers all tag use in the script now [skip ci]. References issue
#635→ <<cset 67b3ffa04941>>
-
Missed a tag check [skip ci]. References issue
#635→ <<cset 28725c5e613a>>
-
reporter Added virtualenvfolder to virtualenv locations to make it slightly clearer hopefully. Doesn't really ref
#635, [skip ci]→ <<cset 703b08a6614f>>
-
Added to zip command comment to make it clear that any switches required to create an archive must be included here [skip ci]. References issue
#635→ <<cset 742e3390c4a7>>
-
Clarified some parts of the DICOM store documentation. Tried to add a link to the section. Documentation changes only [skip ci]. References issue
#635→ <<cset 4839e20acedf>>
-
reporter Added virtualenvfolder to virtualenv locations to make it slightly clearer hopefully. Doesn't really ref
#635, [skip ci]→ <<cset 5978c77c3964>>
-
reporter Removed Store/QR further instructions from the install doc as it doesn't add anything. Refs
#635, [skip ci]→ <<cset 13d78c566d09>>
-
reporter Replaced references to now defunct netdicom page. Deleted file. Refs
#635, [skip ci]→ <<cset 5cda3b0777b5>>
-
reporter Remove propmt for adding linux example for Conquest. Not going to bother now we've added instructions for Orthanc. Refs
#635, [skip ci]→ <<cset 4ae1eb2b7c88>>
-
reporter @dplatten - do you have something to drop into http://docs.openrem.org/en/issue635orthancexperiment/netdicom-store.html#import-scripts where there is a link for Windows batch file examples for use with non-lua conquest?
If not, I'll remove the link. Nearly there!
-
reporter Added bat file examples ffor Windoes with Conquest. Refs
#635, [skip ci]→ <<cset 3ddba24f37a8>>
-
reporter Changed the name of the orthanc lua file, experimenting with substituting the version number into the bitbucket URL. Refs
#635, [skip ci]→ <<cset 21c37b88f7b4>>
-
reporter Another attempt, this time using extlinks. Refs
#635, [skip ci]→ <<cset 2cea1322240c>>
-
reporter Didn't work. Try again with plain text. Refs
#635, [skip ci]→ <<cset 90ae561179af>>
-
reporter Moved extlinks to conf, inserted missing quotation mark. Refs
#635, [skip ci]→ <<cset f70db42f51f4>>
-
reporter Now doing the substitution in conf. Refs
#635, [skip ci]→ <<cset 708d090548cd>>
-
reporter Changed from version to release. Removed experiments. Refs
#635, [skip ci]→ <<cset 884788df8b2c>>
-
reporter Set link to docs_version rather than release. Refs
#635, [skip ci]→ <<cset 79003ba5d529>>
-
reporter - changed status to resolved
Merged in issue635OrthancExperiment (pull request #198)
Fixes
#630,#635DICOM and Orthanc.Approved-by: David Platten dplatten@gmail.com
→ <<cset 0dcdc304619d>>
-
reporter Correcting error of referring to docs latest instead of bitbucket develop. Refs
#635, [skip ci]→ <<cset 8116f091a286>>
-
reporter @dplatten - is this a suitable wording now we are recommending orthanc? Or do you have something better? Refs
#635, [skip ci]→ <<cset 090eeb9343ca>>
-
reporter Added refs
#630,#635to changes. Refs#635, [skip ci]→ <<cset e16e571687d9>>
-
reporter Added refs
#630,#635to changes. Refs#635, [skip ci]→ <<cset e16e571687d9>>
- Log in to comment
Basic working lua script for importing RDSR objects to OpenREM when sent to Orthanc. Refs
#635→ <<cset 9d68ba2055a7>>