I’d like to ask for your help. Have you ever developed a plugin for Orthanc or felt your project could benefit from such an extension? Would you mind sharing a short description of it?
What is jOrthanc? It’s a way for more teams to extend Orthanc so it better suits their needs, potentially broadening Orthanc’s adoption. On the technical side, it’s a Java API for accessing the contents of an Orthanc server from an embedded JVM.
At 16:30 on December 14th, I’ll be presenting jOrthanc during OrthancCon 2019. I have a couple of real world use cases that’ll be presented in both its C++ form and its Java counterpart. With your help, the presentation will be much richer for I’ll try and code a few more real world use cases.
I have a simple one, I ran Orthanc in serverside internally of a PHP server.
Orthanc is used as a DICOM database service for PHP.
In the PHP app, there is a feature to make download of DICOM, so PHP tells orthanc to produce the zip of the dicom using /archive API of Orthanc.
The problem I have hit is that during ZIP production, Orthanc itself put a temporary file in the OS before reading it and output it through RestAPI.
And then my PHP app do exactly the same work again, recieve the RestAPI stream, stream it to the filesystem and then read it again to start the download in the client's browser.
This lead to uneeded disk I/O.
So it would be very helpfull if we can add a RestAPI that will directly write the ZIP to a destination in the hard disk, for example in a POST parameter specify where the ZIP file will be written and not stream it's content, just write once.
Then it will be PHP work to directly consume it from there.
It could be a nice API for those who want use orthanc to massively export DICOM after multiple retrieve in a dicom network.
Sebastien told me that this kind of plugin would be dead easy to write in C++.
I have coding skills in Java but not in C++
So maybe it could help for you to make a proof of concept ?
Anyway I will follow your talk and projet, I think that a good idea to be able to code on higher level language for Orthanc plugins, I just hope that performances will still good (I expect that you embeed a JVM in orthanc distribution ?)
I understand in your case there are two disk I/O’s: one performed by Orthanc, the other one by PHP. That most certainly degrades performance, which can be undesired.
The plugin you describe is certainly doable. Given a study ID (in Orthanc lingo), download its archive without writing to disk. It’s really just a case of pulling Orthanc’s JSONs for the study, its series and the associated instances. Once you have that, generate the ZIP in memory. Then deliver it.
Given Orthanc also provides us with the sizes of instances, you could have a limiter. For instance, if the total uncompressed size exceeds 200MB (for instance), then just call Orthanc’s default /archive URL.
I have a slightly different use-case that I solved with just the rest API. In my use-case the users choose which series will be part of the archive, so I hit /series/ OrthancID to get all the instances and then /instances/OrthancID/file for each instance.
If your db is decently fast hitting studies/OrthancID/instances from the PHP app and iterating over /instances/OrthancID/file for each instance should be faster than reading the archive from rest api and passing it along.
Another approach is to just have more memory in the server and perhaps create a memory mount for temporary files for both Orthanc and the PHP application.
Actually I didn’t though about letting the zip in memory.
So if I understand correctly you can make a plugin that will get the zip contenct in memory and then output it through rest API directly from it’s RAM storage without writing a temporary file ?
That could have some interest to reduce disk I/O but as you said is has to be limited somehow as RAM as much less capacity than HDD.
This will have 2 interest, in cloud providers all disk IO operations are billed so it could reduce cost for those who are running orthanc on the cloud. The second one is to win time in the export, we will avoid write and read on the hard disk.
For my specific main need, actually I still need to write on the hard disk, especially because the export can be huge and won’t fit in RAM.
Just by able to define the destination of the export file is enough, I will still have to read the file with PHP to stream it to the client but I least there is only one disk writing as orthanc will export the data directly to the target point (and not through restAPI that need to be streamed to another temporary file).
However maybe we can design it as an export plugin that will extend orthanc capabilities doing both way.
make an additional key in the orthanc.json to set the maximum size allowed to be exported in memory of check at export that it will have enough free RAM.
in the post parameters, include JSON key like “InMemory” (with Boolean value) and if the chosen value is false than “PathDestination” should be defined to choose to destination the export will be written.
I guess if the plug-in can operate with orthanc content it wouldn’t be a huge difference to put the content either in memory or write it to the hard disk.
It will just a simple example, then I hope I will understand how to develop by looking at your C++ / Java code and contribute to make a real valuable plug-in to extend orthanc capabilities in the export features.
Oh yeah I didn’t though about building my zip myself.
I already have the php code that dig from the patient level to instance level.
I didn’t thought about getting instances manually.
However its convenient to have orthanc managing zip export with the correct hierarchical or dicomdir format.
My php/Js code is already 32 000 lines of code, everything orthanc can handle itself help me to keep my code maintainable…
Regarding the possibility of controlling the resources that are included in a ZIP archive or media (DICOMDIR), are you aware of the fact that the “/tools/create-archive” and “/tools/create-media” URIs allow a fine-grained selection of the patients/studies/series/instances that will be included in the ZIP?