Issue with dicom-web calls for scans with some private tags

General
1

Greetings everyone,

We just started using orthancteam/orthanc:26.8.0. We noticed that few of the scans could not be opened through the viewer. Our viewer is dicom-web based and the initial metadata call is failing for these scans. Earlier versions of Orthanc were handling it fine.

Summary:
Since upgrading to Orthanc 1.13.0 (orthancteam/orthanc:26.8.0), Fujifilm CR/MG instances containing FDMS 1.0 private tags stored with VR=UN fail DICOMweb metadata retrieval:
GET /dicom-web/studies/{study}/series/{series}/metadata
Response: HTTP 400 “The series metadata json does not contain an array.”

Orthanc logs
PluginsManager.cpp:202] Exception while invoking plugin service 4018: Bad file format
dicom-web: Internal error: Cannot convert DICOM to DICOMweb

The files themselves are valid and store fine in Orthanc. The failure occurs only during DICOM to DICOMweb JSON conversion.
Earlier versions (Orthanc 1.12.11) is handling this fine.
After some bisection of the dicom tags we discovered that a combination FujiFilm private tags were the culprit.

Steps to Reproduce:

  1. Take any Explicit VR Little Endian instance where the dcmtk dictionary-defined private tag (dictionary VR = OB/OW) is written with VR=UN — e.g., a Fujifilm “FDMS 1.0” CR image; (0009,1005) is written as UN in-file while DCMTK’s builtin private dictionary declares it OW.
  2. Upload to Orthanc.
  3. Open the OHIF viewr or make a call to GET http://localhost:8042/dicom-web/studies/{StudyUID}/series/{SeriesUID}/metadata . It will return a HTTP 400 error and/or the viewer does not load the scan.
  4. Rewrite those elements’ VR from UN to OW, upload again and metadata call returns 200.

Cause

  1. During DICOMweb JSON encoding, both versions (1.12 and 1.13) correctly resolve the FujiFilm “UN” vr and treat the tag as OW.
  2. 1.12.11: after this resolution, anything resolving to OB/OW/UN was routed through one generic binary block. The word-array read fails harmlessly and falls back to “tag not supported” and a graceful skip with no error.
  3. 1.13.0: the new typed-VR handling routes dictionary-resolved OW into the new strict OW path, which requires reading the value as a uint16 array. The underlying DCMTK accessor refuses because the element’s recorded VR is still UN,
    the reader flags itself invalid, and the code throws ErrorCode_BadFileFormat — aborting the whole dataset traversal instead of skipping the element.
    File: orthanc: a3923ae96abd OrthancFramework/Sources/DicomParsing/FromDcmtkBridge.cpp
    line 3916 onwards, “case EVR_OW: // other word - binary array of 16-bit unsigned integers (new in Orthanc 1.13.0)”

Affected Versions

  • Fails: Orthanc 1.13.x (orthancteam/orthanc:26.8.0 and orthancteam/orthanc:26.8.1)

  • Any scan which stores known (OB/OW) private tags as UN is potentially affected. Fujifilm FDMS our concrete case.

  • Works on 1.12.11

    Have attached the link to the scans with issue when trying to view from ohif viewer

    scan_with_issue - Google Drive

Kindly help us resolve this problem at the earliest