OHIF Viewer - area measurements in px2 for Enhanced CT scans

[James]

Hi all,

We have been seeing area measurements reported in px2 instead of mm2 for
Enhanced CT scans (SOP class 1.2.840.10008.5.1.4.1.1.2.1) in the XNAT OHIF
Viewer. Classic CT scans in the same sessions measure correctly in mm2. The
affected scans are from a Toshiba Aquilion ONE.

We found a related thread from January 2025 about 3D MPR mode being
unavailable for multi-frame datasets
(https://groups.google.com/g/xnat_discussion/c/b2wdd5Tha68/m/I9ZKLidODQAJ),
where it was noted that work on multi-frame support was in progress. Has
there been any update on that since January 2025?

The specific cause we found: the DICOM standard stores pixel spacing in
different locations depending on the image type. For Classic CT it is stored
at the root level of the file (tag 0028,0030). For Enhanced CT it is stored
within the Pixel Measures Macro (PS 3.3 C.7.6.16.2.1,
https://dicom.nema.org/medical/dicom/current/output/html/part03.html#sect_C.7.6.16.2.1)
inside either SharedFunctionalGroupsSequence or PerFrameFunctionalGroupsSequence,
both part of the Multi-frame Functional Groups Module (PS 3.3 C.7.6.16,
https://dicom.nema.org/medical/dicom/current/output/html/part03.html#sect_C.7.6.16),
with no root-level tag. This is by design, because Enhanced CT supports
different pixel spacings per frame.

The OHIF viewer only checks the root-level tag. Finding nothing there for
Enhanced CT files, it falls back to px2.

We confirmed this with a pair of minimal repro files (attached), identical
64x64 images at 0.5mm spacing, one as Classic CT and one as Enhanced CT. The
Classic CT measures in mm2, the Enhanced CT measures in px2.

Our workaround is to copy the pixel spacing value from SharedFunctionalGroupsSequence
into the root-level tag using pydicom. This works when spacing is uniform
across all frames but is not a long-term solution.

We are running XNAT 1.9.3.2 with OHIF-XNAT Viewer 3.7.2.

Attaching classic_ct.dcm, enhanced_ct.dcm

Does anyone know if this is being actively worked on, or if there is a tracking issue we can follow?

Thanks,

James

[Simon Doran]

Dear James,

  Thanks very much for bringing this to our attention and for such a useful bit of detective work.

  Enhanced DICOM has been around for many years now, and one would have thought that adoption would have been quicker more generally by the community. However, this type of issue highlights why there are ongoing problems. The XNAT viewer team put in a lot of work with the move to 3.7.2 to modify the "vanilla" OHIF product to handle multiframe DICOM better. This led, for example, to the facility to view 4-D files (e.g., multiple b-value diffusion-weighted MRI or multiple time-point images) in a much more flexible fashion.

  However, the number of issues that can arise out of possibilities created by the multiframe format is very large. Since the team is small, we don't have time to go through the standard and predict all possible scenarios that might arise. We are also limited by the number of variations that we see "in the wild". Instead, our strategy is to wait for groups to raise issues with us and we then try to correct them as soon as we can. I can't guarantee when this will happen for this case, but we will try to get to it as soon as possible.

  Best wishes and thanks again for reporting the issue.

Simon