I have a 1+ TB database in Radiant local store. I would like to add them to Orthanc to view them using webviewer on other computer.
Storing them again in Orthanc is not an option - the process of reimporting / updating database is too slow and I see no reason to have the files stored twice.
So I turned the StoreDicom option off.
After that, the webviewer will not see the images.
There was an old thread here from 2016, obviously you have to use some metadata to link to the location of the original file. But there was no real solution located in that thread and the link to the documentation on how to store the metadata does not work anymore.
No, I’m afraid there are still no solution to this question.
If you use Orthanc as the primary storage, you can certainly query-retrieve the images from Radiant when you want to visualize them in Radiant (I think that Radiant has a DICOM client that can perform C-FIND and C-MOVE).
If Radiant exposes a Dicom Server (which I don’t know), you could also retrieve only the data of interest in Orthanc in order to visualize them. By using the “MaximumStorageSize” configuration, you could store data in Orthanc only temporarily and avoid using too much storage.
This plugin would start a thread that continuously monitors the content of the Radiant storage folder. The thread would be started/stopped by listening to the “OrthancPluginChangeType_OrthancStarted” and “OrthancPluginChangeType_OrthancStopped” events using “OrthancPluginRegisterOnChangeCallback()”: https://sdk.orthanc-server.com/group__Callbacks.html#ga78140887a94f1afb067a15db5ee4099c
Depending on your operating system, different libraries can be used to monitor the content of a folder. Once a new DICOM file is found by the thread, the plugin would upload it to Orthanc by doing a POST call to “/instances” using “OrthancPluginRestApiPost()”: https://sdk.orthanc-server.com/group__Orthanc.html#ga03e733e9fb437f98700ba99881c37642
Furthermore, after POST-ing the new detected instance, the thread would store in an external database (e.g. SQLite or PostgreSQL), a row that maps the “SOPInstanceUID” DICOM tag and the Orthanc identifier to the path in the Radiant folder (in, say, “Table1”): https://book.orthanc-server.com/faq/orthanc-ids.html
Now, the part of the plugin that implements the custom storage area would behave as follows:
When a “OrthancPluginContentType_Dicom” content type is encountered:
The “OrthancPluginStorageCreate” callback would parse the DICOM content in order to extract the “SOPInstanceUID” DICOM tag, and stores in the external database the mapping from the UUID of the attachment to the “SOPInstanceUID” (in, say, “Table2”): https://book.orthanc-server.com/faq/orthanc-storage.html
The “OrthancPluginStorageReadWhole” callback would use the database to map the provided UUID of the attachment, to the “SOPInstanceUID” (using “Table2”), then to the path in the Radiant folder (using “Table1”). The content of the file from Radiant would be returned by the callback.
Optionally, the “OrthancPluginStorageReadRange” callback would use the same approach as “OrthancPluginStorageReadWhole”.
The “OrthancPluginStorageDelete” only remove the row in the database that corresponds to the UUID of the attachment (in “Table2”).
Other content types are handled as in the “StorageArea” sample plugin: https://hg.orthanc-server.com/orthanc/file/Orthanc-1.9.6/OrthancServer/Plugins/Samples/StorageArea
Optionally, your plugin could also monitor the removal of file in the Radiant storage area, and automatically call DELETE on “/instances/{id}” by using the external database (which would avoid orphaned entries in “Table1”).
Summarizing, this is definitely possible to use Orthanc as a proxy to another DICOM server, but this requires some programming. If you don’t feel comfortable with this, get in touch with a professional assistance to develop this plugin for you and release it as free and open-source software: https://book.orthanc-server.com/users/support.html#finding-professional-assistance