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

**URL:** <https://discourse.orthanc-server.org/t/issue-with-dicom-web-calls-for-scans-with-some-private-tags/6474>\
**Category:** General\
**Created:** [August 26, 2026, 4:43pm UTC](https://discourse.orthanc-server.org/t/issue-with-dicom-web-calls-for-scans-with-some-private-tags/6474 "2026-08-26T16:43:18Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![adhithya](https://discourse.orthanc-server.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@adhithya](https://discourse.orthanc-server.org/u/adhithya)\
**Post date:** [August 26, 2026, 4:43pm UTC](https://discourse.orthanc-server.org/t/issue-with-dicom-web-calls-for-scans-with-some-private-tags/6474/1 "2026-08-26T16:43:18Z")

</div>

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](http://localhost:8042/dicom-web/studies/%7BStudyUID%7D/series/%7BSeriesUID%7D/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](https://orthanc.uclouvain.be/hg/orthanc/file/tip/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

Kindly help us resolve this problem at the earliest

---

<div class="post-metadata">

**Author:** ![adhithya](https://discourse.orthanc-server.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@adhithya](https://discourse.orthanc-server.org/u/adhithya)\
**Post date:** [August 31, 2026, 4:29am UTC](https://discourse.orthanc-server.org/t/issue-with-dicom-web-calls-for-scans-with-some-private-tags/6474/2 "2026-08-31T04:29:07Z")

</div>

Hi @alainmazy and Hi @jodogne

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

Sincerely,  
Adhithya

---

<div class="post-metadata">

**Author:** ![alainmazy](https://discourse.orthanc-server.org/user_avatar/discourse.orthanc-server.org/alainmazy/32/1576_2.png) [@alainmazy](https://discourse.orthanc-server.org/u/alainmazy)\
**Post date:** [August 31, 2026, 7:00am UTC](https://discourse.orthanc-server.org/t/issue-with-dicom-web-calls-for-scans-with-some-private-tags/6474/3 "2026-08-31T07:00:12Z")

</div>

Hi,

> [@adhithya](#):
>
> Kindly let us know if you had a chance to look at the issue.

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/](https://orthanc.team/)

Alain

---

<div class="post-metadata">

**Author:** ![jodogne](https://discourse.orthanc-server.org/user_avatar/discourse.orthanc-server.org/jodogne/32/1511_2.png) [@jodogne](https://discourse.orthanc-server.org/u/jodogne)\
**Post date:** [August 31, 2026, 7:00am UTC](https://discourse.orthanc-server.org/t/issue-with-dicom-web-calls-for-scans-with-some-private-tags/6474/4 "2026-08-31T07:00:22Z")

</div>

Good morning,

> [@adhithya](#):
>
> Kindly let us know if you had a chance to look at the issue.

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](https://orthanc.team/).

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](https://discourse.orthanc-server.org/uploads/short-url/zHLeQDsuUOlEEEHdfZh2VGl4ceT.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](https://orthanc.uclouvain.be/hg/orthanc/rev/9fc5589b40bc).

Regards,  
Sébastien-

---

<div class="post-metadata">

**Author:** ![adhithya](https://discourse.orthanc-server.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@adhithya](https://discourse.orthanc-server.org/u/adhithya)\
**Post date:** [September 2, 2026, 7:33pm UTC](https://discourse.orthanc-server.org/t/issue-with-dicom-web-calls-for-scans-with-some-private-tags/6474/5 "2026-09-02T19:33:55Z")

</div>

Thank you @jodogne. Its working now.