Issue with Displaying PR (Presentation State) DICOM Studies via Orthanc DICOMweb and OHIF Viewer

General
1

Hello Orthanc Community,

We are currently integrating Orthanc with the OHIF Viewer for our PACS solution. While most DICOM studies display correctly, we are facing issues when trying to view Presentation State (PR) objects through the OHIF Viewer using Orthanc’s DICOMweb plugin.

Problem:

  • PR studies loaded via OHIF Viewer result in HTTP 400 or 500 errors.
  • This appears related to incomplete support for the /rendered and /frames/{frame} endpoints in Orthanc’s DICOMweb plugin.
  • PR overlays or annotations are critical for our clinical workflows, and the lack of support is a major blocker.

What we know:

  • The Orthanc DICOMweb plugin implements a reference/basic level of WADO-RS but lacks full support for PR modalities.
  • Other backends like DCM4CHEE reportedly handle PR objects properly with OHIF Viewer.
  • Orthanc’s native web viewer can display these studies, but it does not integrate with OHIF’s features.

Our questions:

  1. Are there any plans to enhance Orthanc’s DICOMweb plugin to support full PR modality rendering?
  2. Is there a recommended workaround or plugin to improve PR handling via DICOMweb in Orthanc?
  3. Would you recommend custom development on Orthanc or switching to another backend for full OHIF compatibility?
  4. Any community experience with successfully integrating OHIF Viewer and Orthanc for overlays and PR?

We appreciate any insights, advice, or pointers to ongoing efforts or plugins addressing this issue.

2

Hi @jemitsanghvi

Could you share some sample images. We don’t have any available for testing.

thanks,

Alain.

3

Hi @alainmazy

You can download it from here :- https://drive.google.com/file/d/18I7X0dVICKHgIIBE29n4VNVWrdK8wOj5/view?usp=drive_link

4

What is it supposed to look like in OHIF ?

In my understanding, PRs are referencing images (and you have not shared any images).

Also note that you should anonymize your images before sharing them and make sure the PRs are still referencing the right images.

5

Dear Alain,

I have checked the above message. Attached is the required ZIP file containing the anonymized study with PR and PT modality images:
Drive Link : https://drive.google.com/file/d/1AMTNTYVnGnmHXTW7owYq5dr8MdVQQFud/view?usp=sharing

6

What is it supposed to look like once opened in OHIF with DCM4CHEE as a backend ?
What url do you use to open OHIF ?

7

We open the OHIF Viewer in your browser using a URL like:
https://domain:8001/viewer?StudyInstanceUIDs=1.2.276.0.7230010.3.1.2.0.1896390.1749060355.672467

OHIF will load and display the study from DICOMweb (Orthanc Plugin /usr/share/orthanc/plugins/libOrthancDicomWeb.so → Version 1.10 )
Implementation of DICOMweb (QIDO-RS, STOW-RS and WADO-RS) and WADO-URI. (QIDO-RS, WADO-RS) services

OHIF will load its web viewer interface.
It will list all series/images in that study UID.
DICOM images will load in the viewport for viewing.

8

What URL do you use to open OHIF?
https://domain:8001/viewer?StudyInstanceUIDs=1.2.276.0.7230010.3.1.2.0.1896390.1749060355.672467

OHIF viewer URL is /viewer
StudyInstanceUIDs is passed as a query param
domain is our server
Port 8001 is what we have exposed via nginx

Nginx server configuration

server {
listen 8001 ssl;
server_name myviewer;
client_max_body_size 1024M;

  ssl_certificate /etc/ssl/certs/selfsigned.crt;
  ssl_certificate_key /etc/ssl/private/selfsigned.key;

  location / {
      root /var/www/html/myviewer;
      index index.html index.htm;
      try_files $uri /index.html;
  }

  location /dicom-web {
      proxy_pass 'http://localhost:8042/dicom-web';
      add_header 'Access-Control-Allow-Origin' '*';
  }

}

OHIF default.js config: OHIF config (default.js) references the reverse-proxied /dicom-web path:

dataSources: [
{
namespace: ‘@ohif/extension-default.dataSourcesModule.dicomweb’,
sourceName: ‘live’,
configuration: {
name: ‘Dcm4chee’,
wadoUriRoot: ‘https://domain:8001/dicom-web’,
wadoRoot: ‘same as above’, (Not sending link, as it does now allow more than 2 links),
qidoRoot: ‘same as above’, (Not sending link, as it does now allow more than 2 links)
imageRendering: ‘wadors’,
thumbnailRendering: ‘wadors’,
enableStudyLazyLoad: true,
dicomUploadEnabled: true,
supportsReject: false,
qidoSupportsIncludeField: true,
supportsFuzzyMatching: false,
supportsWildcard: true,
omitQuotationForMultipartRequest: false,
acceptHeader: [‘multipart/related; type=application/octet-stream; transfer-syntax=*’],
bulkDataURI: {
enabled: true,
},
},
},
]

9

Attached is the screenshot (Ignore the study which is in displayed, its blurred from our end and also when we try to LOAD PR study, we have displayed the error we see in the Console.

image
image1920×961 171 KB

10

This error does not appear with the files you have shared (there is only 2 PR and 1 PT instances) and there are no 500 errors in the logs.

11

But we are seeing this issue. Can you throw some light where can the issue be ?

Also, can we get details about what configurations and versions of orthanc or ohif viewer or other viewer (and its details) which you have used to test this out ?

Can we get a temporary access to test it out, play around and understand ?

12

No since I don’t have the issue.

No. It’s a stupid default installation.

No

I already told you twice that you did only share a tiny subset of the data which does not allow us to reproduce anything.

13

Hello,

Following up on the earlier discussion, we are still facing issues with PR (Presentation State) objects when using Orthanc’s DICOMweb plugin with OHIF.

For reference, i can share anonymized study where the problem can be reproduced. Please guide me how can i share the study over, as currently links are restricted in our replies.

Observations

  • Series count is consistent across viewers (19).

  • In OHIF, unsupported SR series (#10002) throws an error instead of being ignored.

  • For some CT series (e.g., S 201: 93 3.0 x 3.0 Soft Tissue WO), clicking/dragging results in “Internal Server Error – Not implemented yet”.

  • Orthanc’s native viewer displays PR correctly, but OHIF fails via DICOMweb (400/500 errors).

Questions

  1. Is full PR rendering support planned for the DICOMweb plugin?

  2. Are there known workarounds or plugins to handle PR overlays with Orthanc + OHIF?

    Any guidance or clarification would be very helpful.

Thanks !

14

Hi all,

As a follow-up to my recent post about [summarize original issue], I realized I should also clarify one additional detail.

The issue also relates to KO (Key Object) studies/images. Does Orthanc natively handle KO objects as part of its DICOM support, or is there any recommended plugin/extension required for managing and interpreting these?

Looking forward to your input on this point as well.

15

Hello,

Alain already wrote:

As long as you don’t post on this forum a full minimal working example that is independent of OHIF (i.e., sample DICOM files, DICOMweb request using the curl command-line tool, expected DICOMweb answer and why the answer returned by Orthanc is wrong), the Orthanc community will not be able to provide further support.

Regards,
Sébastien-

16

Thank you for clarifying what’s needed. Here is the structured minimal working example:

1. Sample DICOM files
A ZIP archive containing a Studies file and its referenced DICOM image:
drive [dot] google [dot] com/drive/folders/1mylPPDHCpHMI1rjph83eAtRKqAhXzwQW?usp=sharing

2. Environment & Config

  • OS: Ubuntu 22.04.5

  • Orthanc version: 1.11.2

  • DICOMweb plugin version: 1.10

  • Other relevant plugins:

    • postgresql-storage (4.0)

    • worklists (1.11.2)

    • gdcm (1.5, GDCM 3.0.10)

    • serve-folders (1.11.2)

    • postgresql-index (4.0)

    • transfers (mainline)

  • OHIF viewer: 3.10.1

  • Commit hash: aaba8bf1b04be6c00a88f1f5f29cb24133b0c39e

  • Browser/OS: Chrome 140.0.0, Linux x86_64

Orthanc server configuration files:
drive [dot] google [dot] com/drive/folders/1eKceAUoAoqZTc7fN3lgEcCsyBBUaH-4C?usp=sharing

3. cURL reproduction
For the study:
drive [dot] google [dot] com/file/d/1uF64B2RNgAB76XW1N0hff5gz9CAFHAot/view?usp=sharing

Example request on CT series (e.g., S 201: 93 3.0 x 3.0 Soft Tissue WO):

:cross_mark: Not working cURL:

curl 'https://myserver:8001/dicom-web/studies/1.2.276.0.7230010.3.1.2.0.734909.1755942810.543820/series/1.2.276.0.7230010.3.1.3.0.734909.1755942810.543821/instances/1.2.276.0.7230010.3.1.4.0.734909.1755942810.543822/frames/1' \
  -H 'accept: multipart/related; type=application/octet-stream; transfer-syntax=*' \
  ...

Response (HTTP 500):

{
  "HttpError": "Internal Server Error",
  "HttpStatus": 500,
  "Message": "Not implemented yet",
  "Method": "GET",
  "OrthancError": "Not implemented yet",
  "OrthancStatus": 2,
  "Uri": "/dicom-web/studies/.../frames/1"
}

Expected behavior:
HTTP 200 with headers such as:

Content-Location: https://myserver:8001/dicom-web/studies/.../frames/1
Content-Type: application/octet-stream; transfer-syntax=1.2.840.10008.1.2.1
Content-Length: 524288
MIME-Version: 1.0

:white_check_mark: Working cURL:

curl 'https://myserver:8001/dicom-web/studies/1.2.276.0.7230010.3.1.2.0.734909.1755942810.543820/series/1.2.276.0.7230010.3.1.3.0.734909.1755943132.548037/instances/1.2.276.0.7230010.3.1.4.0.734909.1755943132.548038/frames/1' \
  -H 'Accept: multipart/related; type=application/octet-stream; transfer-syntax=*' \
  ...

Response (HTTP 200):

--4b76895e...
Content-Location: https://myserver:8001/dicom-web/studies/.../frames/1
Content-Type: application/octet-stream; transfer-syntax=1.2.840.10008.1.2.1
Content-Length: 524288
MIME-Version: 1.0

Expected behavior: OK

4. Verbose logs

W0905 15:00:25.733715 ServerContext.cpp:2443] W001: Accessing Dicom tags from storage when accessing series : 0008,0201;0040,0244;0040,0245;0040,0275
E0905 15:00:25.773931 PluginsManager.cpp:153] Unsupported return MIME type: application/dicom+json, multipart/related; type=application/octet-stream; transfer-syntax=*, will return DICOM+JSON
...
E0905 15:00:56.552269 PluginsErrorDictionary.cpp:100] Exception inside the plugin engine: Not implemented yet

This example reproduces the issue consistently. Please let me know if you’d like me to provide any further logs, traces, or a simplified dataset.

Thank you!

17

Hi,

This particular instance is a DICOM SR so, calling /frames/1 makes no real sense. BTW, the latest OHIF version does not try to download it.

Anyway, I have made this change to the code so Orthanc won’t generate a 500 error but a 400 stating that it is unable to extract a frame from a DICOM file that does not have pixel data.

Best,

Alain

18

Dear Alain

Thank you for the clarification, that makes sense. I had not realized that the instance I was testing against was a DICOM SR, so calling `/frames/1` is indeed invalid since SRs don’t contain pixel data.

It’s good to know that Orthanc will soon return a 400 Bad Request instead of a 500 error, that will make the behavior much clearer for integrators.

We have also tested on regular CT instances, and as shown in my working cURL example above, those frame requests work correctly. So the issue we were observing was specifically due to PR/SR cases being requested as frames.

Thanks again for the explanation and the code fix!

We do have a couple of follow-up questions:

  1. Regarding the fix you committed here: https://orthanc.uclouvain.be/hg/orthanc/rev/72f74eba36fb

    • How can we apply this patch to my current Orthanc setup?
    • Should we directly rebuild Orthanc from the source with this changeset, or is there another recommended way to update?

  2. We are running Orthanc on both “Linux” and “Windows” environments.

    • Should we update the entire Orthanc installation to the latest release to include this fix, or can we just patch as given above.
    • If upgrading to the latest release is the better approach, are there specific steps or precautions we should take (e.g., database migrations, config compatibility, plugin versions)?

Since we are not very familiar with Orthanc build/upgrade processes, a bit of guidance on the recommended path would really help or any reference where we can get answers to our queries, would be appreciated as well.

Thanks again for your support!

19

This should help:

20

Thank you for providing guidance on the mainline version of Orthanc.

We have updated our server to the mainline version and tested it with OHIF Viewer 3.10.1. Setup steps included:

  • Complete removal of the old Orthanc version on Ubuntu.

  • Downloaded mainline version from the Orthanc Mainline Download Page (downloaded 25th Sep 2025).

  • Installed and configured Orthanc with DICOM settings.

  • Configured NGINX as a reverse proxy.

Working URLs:

  • OHIF Viewer: http://localhost/

  • Orthanc Server: http://localhost:8042 or http://localhost/orthanc/

Issue:
When loading specific PT/PR study instances, we encounter:

With Mainline Version:

HttpError: Bad Request
HttpStatus: 400
Message: Bad request
Uri: /dicom-web/studies/.../frames/1

With Old Version 1.11.2:

HttpError: Internal Server Error
HttpStatus: 500
Message: Not implemented yet
Uri: /dicom-web/studies/.../frames/1

Screenshots attached for both Mainline and Old versions

Could you advise whether this error is due to a limitation in Orthanc’s DICOMweb implementation, or if it should be handled in the OHIF Viewer? We would appreciate guidance on next steps.

Thank you for your support.

Orthanc _1.11.2
Orthanc _1.11.21920×961 142 KB