Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PDF wont load orthanc with ohif setup #4256

Open
holakunle opened this issue Jun 23, 2024 · 8 comments
Open

PDF wont load orthanc with ohif setup #4256

holakunle opened this issue Jun 23, 2024 · 8 comments
Assignees
Labels
fixed-in-dev-await-release This issue is fixed in master (viewer-dev) but we are pending testing for release (viewer.ohif.org)

Comments

@holakunle
Copy link

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

@holakunle holakunle added the Awaiting Reproduction Can we reproduce the reported bug? label Jun 23, 2024
@amazy
Copy link

amazy commented Jun 25, 2024

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

image

@wayfarer3130
Copy link
Contributor

wayfarer3130 commented Jun 25, 2024

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
Copy link
Contributor

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

#4262

@wayfarer3130
Copy link
Contributor

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
Copy link

amazy commented Jun 26, 2024

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

@sedghi sedghi added fixed-in-dev-await-release This issue is fixed in master (viewer-dev) but we are pending testing for release (viewer.ohif.org) and removed Awaiting Reproduction Can we reproduce the reported bug? labels Jun 28, 2024
@amazy
Copy link

amazy commented Jul 2, 2024

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:

Thanks for your help !

Alain

@holakunle
Copy link
Author

holakunle commented Jul 31, 2024

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fixed-in-dev-await-release This issue is fixed in master (viewer-dev) but we are pending testing for release (viewer.ohif.org)
Projects
None yet
Development

No branches or pull requests

4 participants