Hi,
is there a way to change dynamicaly the store directory, according to individual instance tag (StudyDate, StationName, Modality, …) or metadata (RemoteAET, …) ?
Maybe this can be done in the LUA ReceivedInstanceFilter function ?
I use a cloud instance to host my orthanc server, and I can plug new virtual drives to increase disk space when needed.
New drives are mounted on new directories, and I’d like to store new incoming instances in these new directories while keeping old instances in old directories.
This could be possible if Orthanc can make find queries in multiple directories at once.
Thanks
Marc
Hello,
It is possible to replace the way the DICOM images are stored by Orthanc with plugins. Have a look at the “OrthancPluginRegisterStorageArea()” function of the plugin SDK (in the file “OrthancCPlugin.h”).
You can find a full working example in the PostgreSQL plugin (in the file “StoragePlugin/Plugin.cpp”):
https://bitbucket.org/sjodogne/orthanc-postgresql/src
HTH,
Sébastien-
Unfortunately, I’m not a C++ developer !
I just wondered if it is possible to dynamicaly change the StorageDirectory config option in LUA scripts just for the current instance before it is stored, the same way you can dynamicaly change the various TransferSyntax options with appropriate functions.
Maybe I could add this in the wishlist for future releases 
Marc
As far as I can understand the OrthancStorage plugin example in C++, the storage methods (create, read, remove) take instance uuid and file content as parameters.
What I want to do is to have different storage directory for each different remote AET, and this information is not available in the dicom content.
Maybe an external script can move the stored instanced as a cron job, and then update the instance data in the db with the new store path.
In this case, will the server find the data stored when requested with C-FIND ?
Where is the store path registered in the database ?
Sorry, but this feature is way too application-specific to be implemented within Orthanc.
I would suggest you to use Orthanc as such, storing all the DICOM files it receives within its private database, and to implement a Lua callback “OnStoredInstance()” that would copy the various DICOM to a second place (e.g. a network drive) depending on their remote AET.
This could be done by a combination of the two following samples:
https://code.google.com/p/orthanc/source/browse/Resources/Samples/Lua/AutoroutingConditional.lua (this is triggered whenever a DICOM file is received and provides the AET)
https://code.google.com/p/orthanc/source/browse/Resources/Samples/Lua/WriteToDisk.lua (have a look at the inner loop to know how to retrieve the DICOM content and to write it to the disk)
Pay attention to the fact that the second sample only works on the mainline code of Orthanc (it will be part of Orthanc 0.9.2). If you need a solution working with Orthanc <= 0.9.1, then you will have to implement the same behavior as a C++ plugin (cf. “OrthancPluginRegisterStorageArea()” in the plugin SDK).
Of course, this solution will double the storage requirements (the same files will be stored firstly in the private database, secondly in the network drives). But C-FIND will work fine.
HTH,
Sébastien-
Thanks for these precisions.
In fact, if I move completely the instance dicom file from orthanc storage to another local path with an external script, the instance is still registered in orthanc index db. What if I query the instance with C-FIND ?
Can I change the file path in the db for orthanc to retrieve and send the dicom file when requested ?
The point is to free disk space by archiving old instances on additional virtual drives, while keeping the capacity of querying them.
Marc
I am not sure to understand your wishes.
If you just want to keep the index of all the DICOM resources that have been previously received, but you do not want to store the full DICOM files, set the option “StoreDicom” to “false” in the configuration file.
In this case, third-party PACS will be able to run queries against Orthanc. Of course, the “retrieve” part of DICOM Q/R will not be possible (as the DICOM file is not stored).
In fact, I want to store the dicom file, but not in the orthanc default storage, and keep the retrieve capacity.
My problem is that I want to store instances coming from multiple places, and I can’t really anticipate the disk space that will be necessary.
My orthanc is hosted on a cloud VM with limited disk capacity, but with the possibility to mount as many virtual drives as needed, and I would like to distribute the orthanc storage among these drives to obtain potentially illimited capacity.
In this case, you will necessarily have to develop a C/C++ plugin using “OrthancPluginRegisterStorageArea()”.
There is no other solution to preserve the Q/R ability while changing the storage scheme.
Sébastien-