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

2

Hi @alainmazy and Hi @jodogne

Kindly let us know if you had a chance to look at the issue. Thanks in advance.

Sincerely,
Adhithya

3

Hi,

Not yet.

If you are using Orthanc in the scope of a commercial project and if you expect quick reactions/fixes, feel free to purchase a support contract at https://orthanc.team/

Alain

4

Good morning,

Please remember that we provide Orthanc freely, without any guarantee or commitment to support. If you need fast, professional support, please purchase a support pack from the Orthanc Team company.

That being said, I had a look at your file, and the root cause is within the default DICOM dictionary of private tags from DCMTK, which defines vendor-specific DICOM tags for Fujifilm. It looks like DCMTK cannot handle some private Fuji tags defined as having the OW value representation, so the issue is not specific to Orthanc. Applying the attached patch to the source code of DCMTK prevents the issue with Orthanc 1.13.0.

fujifilm.patch.txt (1.0 KB)

The workaround for Orthanc 1.13.0 is simply to disable the loading of private tags, by setting configuration option LoadPrivateDictionary to false. This will enable the default behavior of DCMTK command-line tools (i.e., private Fuji tags considered as having the UN unknown value representation).

For the future, I have added some tolerance so that Orthanc gracefully handles incorrect OW definitions in the DICOM dictionary. Here is the related changeset.

Regards,
Sébastien-

5

Thank you @jodogne. Its working now.