Hello everyone,
I am writing because I have a problem in
I am using Orthanc with the OHIF visualization software to build a custom DICOM viewer. OHIF interfaces with Orthanc
https://github.com/OHIF/Viewers
When I call the 3D rendering functionalities of OHIF (in a custom file attached here that is inserted in extension/vtk/src), there is a function (createStudyImageIds) of the dicomweb-client library that performs this call:
http://IPADDRESS:8041/dicom-web/studies/STUDY_UID/metadata
The problem that I have is that, when the study contains only DICOM images, everything works fine, but if the study contains pre-![]()
saved annotations (stored in a DICOM structure report) I get a CORS error, like the following one.
Access to XMLHttpRequest at ‘http://144.91.105.56:8041/dicom-web/studies/1.3.46.670589.33.1.63738460900964818300001.4626932103669225842/metadata’ from origin ‘http://localhost:9000’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
I have no idea why this happens (I only know that the error manifest at line 206) and I was hoping that someone could give me some hint to solve the problem.
Feel free to contact me if I missed some important details.
Best,
Marco Bologna
Render3D.txt (14.6 KB)
HI Marco,
CORS errors like this typically mask the true cause, often an http error response from the server. In order to track that down, I would recommend checking your Orthanc logs and try copying the request from your browser developer tools as a cURL request and replaying it either in the console or with a tool like Postman. This will allow you to see the raw http response and often error details without being masked by the CORS error.
Hope that helps.
James
Marco,
I concur,
I was getting errors like that with series that were of type “PR”. The errors that I actually got were 400 Errors. Alain, I believe added something in a recently release for the Stone Viewer that sort of deals with that, but I doubt that there is a backend fix to go along with that. For Stone, there is a setting for: “SkipSeriesFromModalities”: [“SR”, “SEG”, “PR”].
The “SR” type I think is structured reports.
I still get a 400 / Bad Request with a URL like:
/dicom-web/studies/1.3.6.1.4.1.56016.1.1.1.143.1632094883/series/1.2.276.0.7230010.3.1.3.413927680.1.1638235299.95652/rendered?viewport=128,128
Where the series is actually of type “OT” and consists of embedded PDF. Orthanc ungracefully handles some request like that when it cannot process the request. It usually just throws a 400 / Bad Request, or a 500 / Server Error.
I’m not sure that I ever saw an error with a URL like the one you provided. The only one I see on a regular basis now is the one for an instance that is an embedded PDF.
/sds
I just tried one of my test studies that had some “PR” series, presentation states using a URL like the one provided by Marco, except for my study.
That does indeed throw a 400 / Bad Request error when the “PR” series are in the study, but when I remove / delete them I do not get an error.
The Orthanc log shows something like below. I suspect that Marco’s error is something similar. The exception looks like it might be thrown in WadoRs.cpp.
I1130 19:35:38.641865 OrthancPlugins.cpp:2099] (plugins) Delegating HTTP request to plugin for URI: /dicom-web/studies/1.3.6.1.4.1.56016.1.1.1.420.1631032140/metadata
E1130 19:35:38.642998 PluginsManager.cpp:164] Bad request: This WADO-RS plugin cannot generate the following content type: image/jpeg
E1130 19:35:38.643634 PluginsErrorDictionary.cpp:111] Exception inside the plugin engine: Bad request
Dear James and Sthepen,
I have tried to access the Orthanc logs and this is what I get when I try to 3D render a study containing annotation in DICOM SR form:
W1201 10:58:35.671504 OrthancPlugins.cpp:2867] LookupResource(): Multiple resources match the query (instead of 0 or 1), which indicates your DICOM database breaks the DICOM model of the real world
E1201 10:58:35.671628 PluginsManager.cpp:164] Accessing an inexistent item: Accessing an inexistent study with WADO-RS: 1.3.46.670589.33.1.63738460900964818300001.4626932103669225842
E1201 10:58:35.671689 PluginsErrorDictionary.cpp:111] Exception inside the plugin engine: Accessing an inexistent item
While the call performed using postman returns this
{
“Details” : “Accessing an inexistent study with WADO-RS: 1.3.46.670589.33.1.63738460900964818300001.4626932103669225842”,
“HttpError” : “Not Found”,
“HttpStatus” : 404,
“Message” : “Accessing an inexistent item”,
“Method” : “GET”,
“OrthancError” : “Accessing an inexistent item”,
“OrthancStatus” : 7,
“Uri” : “/dicom-web/studies/1.3.46.670589.33.1.63738460900964818300001.4626932103669225842/metadata”
}
It seems that there are two studies with the same StudyUID, which, by looking at the orthanc explorer is actually true (see attached image). I though that that was simply referring to the fact that both the dicom files and the dicom SR were referred to the same study, but apparently there is a problem in how the IDs are assigned when saving the measurements. I have to investigate a little bit better on this. Do you experience similar situations with your annotated images?
Meanwhile, thank you for your help. I really appreciated.
Marco
Marco,
Nice to see you found part of the problem. I have experienced something similar mostly on a development server where a study somehow gets split into two or more pieces. In those cases, where necessary, we usually just merge the orphan series into the parent study. See: https://book.orthanc-server.com/users/anonymization.html#split-merge-of-dicom-studies. It sounds like you have some sort of issue with the way that the “SR”'s are created ? Not sure how to do that, but maybe you are not specifying the Parent Study/Series to attach the SR to, which is why it creates a new study.
An interesting thing about the Stone viewer is that I think it breaks when you have duplicate StudyInstanceUID’s on the server (it uses DICOMWEB), whereas the legacy Osimis viewer does not break (it uses the Orthanc ID).
/sds
Hi Stephen,
I will try checking the functions of OHIF related to the creation of the dicom SR to understand where the problem arise.
Best,
Marco
Dear all,
I did not manage to modify the understand how to modify the Dicomweb-client.storeInstances() method to avoid the double study issue. However, I added pieces of code to identify the Orthanc IDs for the “duplicated” studies and to merge them into one. I did this via the Orthanc API, directly called inside OHIF. I used the following APIs:
-tools/find
-studies/{id}/merge
https://book.orthanc-server.com/users/rest-cheatsheet.html
Best,
Marco Bologna