Stone viewer can't find images with custom Advanced Storage NamingScheme

General
1

First, I am no kind of DICOM expert, so I apologize in advance.

We’re using the Linux Standard Base binaries and libraries, upgraded to the most recent versions as of a few days ago. We’ve been running Orthanc for six or so months, and we’ve imported a fair amount of data from other PACS using scripted REST calls.

I’ll mention that we configured the Advanced Storage plugin with a custom NamingScheme:

"NamingScheme": "{split(StudyDate)}/{AccessionNumber}/{UUID}{.ext}"

which I’m not sure is significant, but I don’t know.

We have recently added the StoneViewer, DICOMWeb and VolView plugins. When we try to use either of the viewer plugins on a study, it doesn’t display anything. Looking in the logs, I see:

HTTP-4 advanced-storage:/Plugin.cpp:191] Advanced Storage - Reading range of attachment “40c2762f-f85d-4fce-af84-acb2974c0162” of type 1 (path = /rdmf/pacs/40/c2/40c2762f-f85d-4fce-af84-acb2974c0162)

HTTP-4 advanced-storage:/Plugin.cpp:195] The path does not point to a regular file: “/rdmf/pacs/40/c2/40c2762f-f85d-4fce-af84-acb2974c0162”

HTTP-4 PluginsManager.cpp:202] Exception while invoking plugin service 3016: Inexistent file

A file named with that UUID exists on disk, although in a location consistent with the Advanced Storage NamingScheme (accession number hidden):

/rdmf/pacs/2011/01/25/xxxxxxxxx/40c2762f-f85d-4fce-af84-acb2974c0162.dcm

But that has a .dcm extension, which is different from what appears in the logs. After some web searching, I found something that suggested the ExtraMainDicomTags option was significant to DICOMWeb working correctly, and that option was commented out in the template Orthanc configuration I had copied. I uncommented that option:

“ExtraMainDicomTags” : {
“Instance” : [
“Rows”,
“Columns”,
“ImageType”,
“SOPClassUID”,
“ContentDate”,
“ContentTime”,
“FrameOfReferenceUID”,
“PixelSpacing”,
“SpecificCharacterSet”,
“BitsAllocated”
],
“Series” : [ ],
“Study”: [ ],
“Patient”: [ ]
}

and added these also, again based on information found on the web:

“SeriesMetadata”: “MainDicomTags”,
“StudiesMetadata”: “MainDicomTags”

This did not change the viewer behavior. However, after making those changes, we imported an additional study, and now the viewer works, only on that study. In the logs, I see:

HTTP-27 advanced-storage:/Plugin.cpp:191] Advanced Storage - Reading range of attachment “289ce8ea-8b01-4955-ab99-e4dbda4d74e3” of type 0 (path = /rdmf/pacs/28/9c/289ce8ea-8b01-4955-ab99-e4dbda4d74e3)

…..

HTTP-27 advanced-storage:/Plugin.cpp:191] Advanced Storage - Reading range of attachment “eccb0a91-40dc-4ed3-8a2e-72199a551f50” of type 1 (path = /rdmf/pacs/2003/10/06/1/eccb0a91-40dc-4ed3-8a2e-72199a551f50.dcm)

The first log is similar to the log above, in that it references a file in a location that seems at odds with the AdvancedStorage configuration, but through a mechanism I don’t understand, the file exists. The second log shows it successfully finding the first instance of the study.

Again, consulting the web, I see a suggestion that I may need to reconstruct metadata and/or indicies through the REST API. For the first study, I’ve tried the reconstruct route at the study, series and instance level, and in each case, I get the same complaint about the missing file. I am reluctant to try /tools/reconstruct out of concern for 1) how long it may take, and 2) not knowing what it may do to my database or TBs of existing studies.

Any advice would be welcome.

John

2

Hi @johnburian

Could you share your full configuration file to understand which DB plugin you are using ? And the exact version numbers of each plugin (as shown in http://localhost:8042/ui/app/#/settings)

This is relevant since it seems that the 40c2762f-f85d-4fce-af84-acb2974c0162 file was first saved with the advanced storage plugin enabled and then, in your first log, it seems it can not be found at the right place. You have probably been playing around the configuration; enabling/disabling the plugin but it should still work.

This is not relevant. BTW, you should use the “Full” modes as advised from v 1.15 of the DICOMweb plugin.

Reconstructing won’t work as long as Orthanc is not finding the files…

Hope this helps,

Alain.

3

Alain,

Thanks for your response. Installed versions:

  • orthanc 1.12.10
  • advanced-storage 0.2.3
  • dicom-web 1.22
  • orthanc-explorer-2 1.10.2
  • postgresql-index 10.0
  • stone-webviewer 3.0
  • volview 1.3

Interestingly, when I when to check those, dicom-web was struck through, as misconfigured? I copied the whole dicom-web default config from the dicom-web documentation page and added that to my config, now dicom-web looks okay. Stone Viewer is still having the same problem.

Full config is attached. Note that I have the config broken in to multiple JSON files, but they are attached here concatenated in a semi-arbitrary order, so there will be some extra open/close braces.

orthanc.json (50.8 KB)

Thanks,

John

4

The configuration looks good and I can’t reproduce any issue with this kind of setup.

When looking at this:

HTTP-4 advanced-storage:/Plugin.cpp:191] Advanced Storage - Reading range of attachment “40c2762f-f85d-4fce-af84-acb2974c0162” of type 1 (path = /rdmf/pacs/40/c2/40c2762f-f85d-4fce-af84-acb2974c0162)

HTTP-4 advanced-storage:/Plugin.cpp:195] The path does not point to a regular file: “/rdmf/pacs/40/c2/40c2762f-f85d-4fce-af84-acb2974c0162”

HTTP-4 PluginsManager.cpp:202] Exception while invoking plugin service 3016: Inexistent file

while the file /rdmf/pacs/2011/01/25/xxxxxxxxx/40c2762f-f85d-4fce-af84-acb2974c0162.dcm exists

I actually really can not think of any way to end up in this situation … besides deleting the content of the CustomData column in the AttachedFiles table in the SQL database or, at some point, did you run the AdvancedStorage plugin with an older version of the PostgreSQL plugin that did not support CustomData (like a PostgreSQL plugin prior to 8.0).

Do you still have the logs when the 40c2762f-f85d-4fce-af84-acb2974c0162 attachment was created ?

5

Alain,

We originally installed Orthanc with the following versions:

  • orthanc: 1.12.8
  • advanced_storage: "mainline” - but installed at the same time as the rest, so probably 0.1.x
  • orthanc explorer2: 1.8.5
  • postgresql index: 7.2

We got it “working,” and then we had to focus on importing a bunch of data before the PACS it lived on was decommissioned. Only just recently did we get a request for the viewer plugins, and I upgraded everything to the versions I posted up above.

If the problem is the old Postgres Index plugin was missing some feature critical to correct operation of Stone Viewer, is there something we can do to recover at this point?

Thanks,
John