PDF wont load orthanc with ohif setup

[holakunle]

Describe the Bug

Hello everyone. Pdf is not loading on Orthanc + ohif v3 docker setup . It says No PDF viewer is installed. This was working properly with version 2. Any help will be appreciated. Thank you

Steps to Reproduce

1. See https://github.com/orthanc-server/orthanc-setup-samples/tree/master/docker/ohif-test.
2. See https://discourse.orthanc-server.org/t/ohif-plugin-is-displaying-mri-images-but-not-pdf-or-sr/4315

The current behavior

No online Pdf viewer installed

The expected behavior

PDF loads

OS

Ubuntu server

Node version

18

Browser

Edge 125.0.2535.96

[amazy]

FYI, I have updated the sample setup to latest OHIF beta + latest Orthanc version. Still the same issue.

I'm attaching the sample PDF file that I use. Study With PDF.zip

Once you have launched the setup and uploaded the file in Orthanc, OHIF v2 shows the PDF: http://localhost:3002/viewer/1.2.276.0.7230010.3.1.2.2344313775.14992.1458058363.6979 OHIF v3 does not show the PDF: http://localhost:3003/viewer?StudyInstanceUIDs=1.2.276.0.7230010.3.1.2.2344313775.14992.1458058363.6979

[wayfarer3130]

The wrong BulkDataURI is being returned by the server - if you are going to use absolute URIs, you have to have the right absolute URI.
Also, when I manually adjusted the URL to be correct, then there are a couple of settings which aren't correct in the data source. I've attached my working datasource to this issue. Sorry, that won't paste, adding a copy of it:

window.config = {
  routerBasename: '/',
  extensions: [],
  modes: [],
  showStudyList: true,
  dataSources: [
    {
      friendlyName: 'Orthanc local',
      namespace: '@ohif/extension-default.dataSourcesModule.dicomweb',
      sourceName: 'orthanc',
      configuration: {
        name: 'orthanc',

        wadoUriRoot: '/orthanc/dicom-web',
        qidoRoot: '/orthanc/dicom-web',
        wadoRoot: '/orthanc/dicom-web',

        qidoSupportsIncludeField: false,
        supportsReject: false,
        imageRendering: 'wadors',
        thumbnailRendering: 'wadors',
        enableStudyLazyLoad: true,
        supportsFuzzyMatching: false,
        supportsWildcard: true,
        staticWado: true,
        // Note orthanc does not have a singlepart retrieve for pdf or video, so exclude those two.
        singlepart: 'bulkdata',
        // The separate retrieve/decoding of bulkdata URIs to internal blobs which are URL accessible is addressed with this configuration:
        bulkDataURI: {
          enabled: true,
          relativeResolution: 'studies',
          // This is an example config that could potentially be used to fix the retrieve URL
          startsWith: 'http://localhost/',
          prefixWith: '/orthanc/',
        },
        acceptHeader: ['multipart/related; type=application/octet-stream; transfer-syntax=*']
      },
    }],
  defaultDataSourceName: 'orthanc',
};

[wayfarer3130]

I added a small PR with a working sample configuration file, and a small change to allow fixing the broken orthanc URLs.

https://github.com/OHIF/Viewers/pull/4262

[wayfarer3130]

The response that docker is returning is for the metadata for the PDF is below, when requesting on port 3003 eg on http://localhost:3003/orthanc/dicom-web/studies/..../series/..../metadata one gets "00420011" : { "BulkDataURI" : "http://localhost/dicom-web/studies/1.2.276.0.7230010.3.1.2.2344313775.14992.1458058363.6979/series/1.2.276.0.7230010.3.1.3.1901948703.36080.1484835349.617/instances/1.2.276.0.7230010.3.1.4.1901948703.36080.1484835349.618/bulk/00420011", "vr" : "OB" },

However, there is no server running on http://localhost port 80. For the server running on port 3003, the path would be: http://localhost:3003/orthanc/dicom-web/studies/1.2.276.0.7230010.3.1.2.2344313775.14992.1458058363.6979/series/1.2.276.0.7230010.3.1.3.1901948703.36080.1484835349.617/instances/1.2.276.0.7230010.3.1.4.1901948703.36080.1484835349.618/bulk/00420011

Note the /orthanc/ as well as the port number.

Other acceptable URLs would be: instances/1.2.276.0.7230010.3.1.4.1901948703.36080.1484835349.618/bulk/00420011

or the relative URL: /orthanc/dicom-web/studies/1.2.276.0.7230010.3.1.2.2344313775.14992.1458058363.6979/series/1.2.276.0.7230010.3.1.3.1901948703.36080.1484835349.617/instances/1.2.276.0.7230010.3.1.4.1901948703.36080.1484835349.618/bulk/00420011

It is possible that last URL will double up on the /orthanc/dicom-web/ port - if so, this URL should work (but should be fixed as this isn't actually standards compliant - the two above ARE standards compliant) /studies/1.2.276.0.7230010.3.1.2.2344313775.14992.1458058363.6979/series/1.2.276.0.7230010.3.1.3.1901948703.36080.1484835349.617/instances/1.2.276.0.7230010.3.1.4.1901948703.36080.1484835349.618/bulk/00420011

I would suggest the instances version of it.

[amazy]

I confirm I was able to update our test setup with the latest build and it works. Thanks !

[amazy]

Hi @sedghi and @wayfarer3130

I'm not sure we are 100% done with this issue :-(

As mentioned in my previous comment, one of our test-setup works fine with v3.9.0-beta-56. Note that, in this setup, I'm using the standard Docker image from OHIF and therefore serving OHIF on a dedicated nginx server on http://localhost:3003 with a reverse-proxy forwarding /orthanc to http://orthanc:8042. This orthanc does not know that it is served at /orthanc and that's the reason why we need this new bulkDataURI.startsWith and bulkDataURI.prefixWith to fix the Orthanc bulkdDataURIs. Everything works fine in this setup !

However, when we deploy OHIF and Orthanc together (e.g in this setup), we usually have our own nginx in front of both OHIF and Orthanc. OHIF is reversed proxied at /ohif and Orthanc at /orthanc.
For this, we build our own version of OHIF with this Dockerfile - the only relevant difference with your build process is the PUBLIC_URL=/ohif/ option. In this setup, Orthanc is aware that it is served at /orthanc and thanks to this configuration: ORTHANC__DICOM_WEB__PUBLIC_ROOT: "/orthanc-container/dicom-web/" the bulkDataURIs are correct. However, in this setup, PDFs are not showing.

Steps to reproduce:

• clone this repo and cd into docker/ohif
• docker compose up --build
• upload the sample with PDF study in http://localhost/orthanc-container/ui/app/
• open the ohif viewer through http://localhost/ohif/viewer?StudyInstanceUIDs=1.2.276.0.7230010.3.1.2.2344313775.14992.1458058363.6979. It seems it's not even trying to load the embedded PDF
• by manually downloading the content of the BulkDataUri, curl http://localhost/orthanc-container/dicom-web/studies/1.2.276.0.7230010.3.1.2.2344313775.14992.1458058363.6979/series/1.2.276.0.7230010.3.1.3.1901948703.36080.1484835349.617/instances/1.2.276.0.7230010.3.1.4.1901948703.36080.1484835349.618/bulk/00420011 > /tmp/test.pdf we get a valid PDF file

Thanks for your help !

Alain

[holakunle]

Hello, @sedghi and @wayfarer3130, are there any updates on the above. @amazy updated the issues that are yet to be resolved. Please help look into this

[holakunle]

Again @sedghi and @wayfarer3130, are there any updates on the above. @amazy updated the issues that are yet to be resolved. Please help look into this. Please thanks

[dscarmo]

I have similar issues when using orthanc with ohif plugin behind an nginx proxy. Things that I found in the web such as changing configs singlepart, acceptheader, datasources in ohif configuration file did not help.

[wayfarer3130]

It isn't an OHIF issue - the problem is that the path being returned by Orthanc isn't the right path any longer. There are configuration options now which can be used to deal with that, but without knowing your exact setup and examples of what the path coming back is in the metadata, and what the path should be, I can suggest how to fix it on YOUR end. Alternatively, orthanc could use relative paths, which do work correctly as long as OHIF is configured to allow that (should probalby make this a default config.)

If you give me the absolute path for a metadata file AND the snipped of metadata file containing the bulkdata URI, and the actual path that actually works on your system, then I can provide a configuration that works for that setup. It won't work in general because you can configure a reverse proxy however you want and that doesn't rewrite metadata URLs.

[wayfarer3130]

I will also add documentation at https://docs.ohif.org/configuration/dataSources/dicom-web exactly how to configure the BulkDataURI setting for fixing incorrect relative paths. The bits you probably need are from the original PR to allow changing the prefix path with:

 bulkDataURI: {
          enabled: true,
          relativeResolution: 'studies',
          // This is an example config that could potentially be used to fix the retrieve URL
          **startsWith: 'http://localhost/',**
          **prefixWith: '/orthanc/',**
        },

You need to remove bits of the path of startsWith and add the correct value for your back end with prefixWith.

[holakunle]

It isn't an OHIF issue - the problem is that the path being returned by Orthanc isn't the right path any longer. There are configuration options now which can be used to deal with that, but without knowing your exact setup and examples of what the path coming back is in the metadata, and what the path should be, I can suggest how to fix it on YOUR end. Alternatively, orthanc could use relative paths, which do work correctly as long as OHIF is configured to allow that (should probalby make this a default config.)

If you give me the absolute path for a metadata file AND the snipped of metadata file containing the bulkdata URI, and the actual path that actually works on your system, then I can provide a configuration that works for that setup. It won't work in general because you can configure a reverse proxy however you want and that doesn't rewrite metadata URLs.

@amazy is this something we can work with. And can we try what @wayfarer3130 suggested?

[amazy]

@wayfarer3130 I just gave it a try again. tl;dr: you may go to the last section directly

First, with the working test setup where OHIF is served as a standalone server on localhost:3003 and Orthanc is running on localhost but is exposed on localhost:3003/orthanc for the OHIF server. In this scenario, Orthanc is not aware that it is being served on localhost:3003/orthanc so OHIF must correct the bulkdDataURI.

The PDF is loaded correctly: .

Here is the OHIF configuration:

    dataSources: [
        {
          friendlyName: 'Orthanc local',
          namespace: '@ohif/extension-default.dataSourcesModule.dicomweb',
          sourceName: 'dicomweb',
          configuration: {
            name: 'orthanc',
    
            wadoUriRoot: '/orthanc/dicom-web',
            qidoRoot: '/orthanc/dicom-web',
            wadoRoot: '/orthanc/dicom-web',
        ...    
            singlepart: 'bulkdata',
            acceptHeader: [ 'multipart/related; type=application/octet-stream; transfer-syntax=*'],
            bulkDataURI: {
              enabled: true,
              relativeResolution: 'studies',
              // In this scenario, Orthanc is not aware that is being served at http://localhost/orthanc/ so we must tell OHIF to fix
              // the bulkDataURI
              startsWith: 'http://localhost/',
              prefixWith: '/orthanc/',
            },
          },
        }],

---

Then, the second setup where OHIF and Orthanc are both behind the same reverse-proxy and are served at localhost/ohif and localhost/orthanc-container. This time, Orthanc is aware that it is being served at localhost/orthanc-container. You'll notice that Orthanc returns the correct BulkDataURI but, this time, OHIF does not even try to load the BulkData:

There, we assume we do not have to provide a specific OHIF configuration to correct Orthanc URIs since they are correct directly:

  dataSources: [
    {
      friendlyName: 'Orthanc local',
      namespace: '@ohif/extension-default.dataSourcesModule.dicomweb',
      sourceName: 'dicomweb',
      configuration: {
        name: 'orthanc',

        wadoUriRoot: '/orthanc-container/dicom-web',
        qidoRoot: '/orthanc-container/dicom-web',
        wadoRoot: '/orthanc-container/dicom-web',
    ...
        staticWado: true,
        singlepart: 'bulkdata',
        acceptHeader: [ 'multipart/related; type=application/octet-stream; transfer-syntax=*']
      },
    }],

---

Then, this time, I went one step further and provided OHIF with a bulkDataUri configuration:

        singlepart: 'bulkdata',
        acceptHeader: [ 'multipart/related; type=application/octet-stream; transfer-syntax=*'],
        bulkDataURI: {
          enabled: true
        },

And, there, the PDF is displaying fine. So, to summarize, it seems that we were not just aware that we needed to enable bulkDataURI in all configurations. I thought this configuration was only required to correct wrong bulkDataURIs from Orthanc.

So, if you confirm that this last remark is correct, we can close this issue and I will update all our samples.

[wayfarer3130]

Thank you for the testing on that - yes, the configuration is required to enable the bulkDataURI fetching at all from the metadata responses. That is probably a change that should be made, plus the documentation of how to configure the startsWith/prefix settings and the relative resolution settings. You can leave the issue open until I've done that and I will have it closed against the PR to address those parts of the concern - I might ask you to retest not needing the bulkDataURI configuration at all.

Message ID: @.***>

[wayfarer3130]

@amazy - could you try without the bulkdDataURI configuraiton on the branch from this PR: https://github.com/OHIF/Viewers/pull/4607

Also please make any comments on the updated docs

[amazy]

@wayfarer3130 I confirm it works without the bulkDataUri config now !

The doc looks good to me too !

Thanks to all of you !

[kabaluyot]

Hello.

In our case we supposedly need to use transform because it is a completely different url (using different service and proxied) but it seems to be not working. The workaround I did is to override here and pdf was successfully rendered.