Viewers: route bulk/6000300 ?

[salimkanoun]

Hi there,

I have a question about a possible bug.

I have one dataset of DICOM, stored in Orthanc that trigger a different route in OHIF than usual DICOMs.
Usually OHIF retrieve images using the instance/UID/frame/1.

In this particular study 2 strange things happen :

• OHIF call the API : instance/UID/bulk/6000300
• OHIF do not use my custom parameter to reach the orthanc dicom web api.

I have orthanc dicom web on a reverse proxy on the 8080 port, I add /orthanc/ in the route api to reach dicom web to trigger my reverse proxy by URL routing.
The called metadata API is correct:
http://localhost:8080/orthanc/dicom-web/studies/1.2.276.0.7230010.3.1.2.330040320.1.1585939403.785555/series/1.2.276.0.7230010.3.1.3.330040320.1.1585939406.786579/metadata

but the bulk api called by OHIF is :
https://localhost:8042/dicom-web/studies/1.2.276.0.7230010.3.1.2.330040320.1.1585939403.785555/series/1.2.276.0.7230010.3.1.3.330040320.1.1585939406.786579/instances/1.2.276.0.7230010.3.1.4.330040320.1.1585939409.787279/bulk/60003000

my integration is here : https://github.com/salimkanoun/GaelO/blob/master/src/ohif/index.php
This page in served by a PHP server on the localhost:8080

So two questions :

• What is the bulk/60003000 API ? what is the diffrence with /frame API? (just for my information)
• How could OHIF call the 8042 Orthanc port for this bulk/60003000 API while it correcty pass through my reverse proxy in the /metadata and /frame api ? I really doubt that OHIF can guess my Orthanc adress through my PHP reverse proxy, is there a hardcoded Orthanc URI somewhere in your code?

I'm running the latest build of OHIF with orthanc 1.5.8
If needed I can send the DICOM dataset that make OHIF triggering the bulk API,

Thanks for your help,

Salim

[swederik]

I think this is our attempt to fetch the OverlayPlane metadata. The URL is coming from here, I guess:

https://github.com/OHIF/Viewers/blob/404d52fe5c0442dd13e4d407bb0687d72fa5f32c/platform/core/src/utils/metadataProvider/fetchOverlayData.js#L60-L63

The 6000 tag is set here:
https://github.com/OHIF/Viewers/blob/404d52fe5c0442dd13e4d407bb0687d72fa5f32c/platform/core/src/utils/metadataProvider/fetchOverlayData.js#L15

I think if you inspect the metadata response you'll find that Orthanc is returning the BulkDataURI as an absolute URL, which is what is specified in the standard. The problem is that it's using localhost:8042 as its host. You'll need to find a way to set the hostname you want in Orthanc (or to edit it somehow in a proxy layer).

We could potentially add a setting to override BulkData URIs with a specific root URL, but I think you should investigate fixing this in Orthanc's configuration first, since that would be the best place to do it.

[salimkanoun]

Thank you so much @swederik , I would never firgured out without your explanations.

To solve it there are two way to tell orthanc to change the BulkDataURI, either with the DicomWeb options parameter (which is depreciated) or by passing a Host or Forwarded HTTP header to Orthanc (so adding this value during the reverse proxy http call).

It sounds that Orthanc as a problem in these settings, i put a question in Orthanc forum
https://groups.google.com/forum/#!topic/orthanc-users/DOp8mzaW18c

So the main problem is not on OHIF side.

However that's a bit currious that the other /frame API was passing.
It seems that you have some routes in where BulkDataURIs is overriden and some other not ?

[salimkanoun]

Hi,
Just to put a reference here because the other issue was closed,
It seems that this route did not benefit for the loading improvement of series metadata : https://github.com/OHIF/Viewers/issues/1536#issuecomment-610018474

Best regards,

Salim

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[salimkanoun]

just to say, I found why the series using "bulk/6000300" makes need time to show,
OHIF act this way => Query all instance metadata with /metadata , then query "bulk/6000300" instance by instance, then query the usuall instance/UID/frame
it seems that there is a promise.all for the bulk/6000300 retriving so this make longer to display the first instance dicom.

Most of dicom don't need to query for "bulk/6000300" so the second step dosen't exist, I don't know if there is some room for improvement for this (is there need to wait the 6000300 to be retrieved for all instances before getting the first frame ?).

And of course there is the other problem with the URI being taken account in this route and not with the instance/UID/frame

Best regards,

Salim

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.