[Bug] Viewing CT and SEG DICOM files in OHIF converted from nifti

[deepakri201]

Hi,

I have deployed my own viewer app using the https://github.com/ImagingDataCommons/Viewers master branch here. It has been working with no issues -- however now I have been working with a different set of files, and have encountered an issue.

I have a nifti CT file that I converted to a DICOM series using the slicer.modules.createdicomseries module. I then converted the associated label nifti file to a DICOM SEG file using dcmqi. When I load these converted DICOM files into Slicer, they load with no visible issues:

However, when I view the same DICOM files in OHIF, the following occurs:

video.mp4

Here are the DICOM CT and SEG files in dropbox.

Thank you,

Deepa

Steps to Reproduce

1. Deployed my own viewer app using the https://github.com/ImagingDataCommons/Viewers master branch
2. Converted the CT nifti file to DICOM series using slicer.modules.createdicomseries
3. Converted the label nifti file to DICOM using dcmqi
4. Added DICOM files to a dataset and DICOM datastore and accessed in the deployed viewer

The current behavior

Currently, both the CT and SEG do not load properly:

video.mp4

The expected behavior

It should look something like this:

OS

Windows 10

Node version

I'm not sure

Browser

Chrome 116.0.5845.188

[pieper]

I'm not sure exactly what's going on, but one clue could be that this data is tilted with respect to typical patient alignment (you can see this in the green / coronal view in Slicer, where the person is leaning to one side). You can see this with the non-identify ImagePostiionPatient tag in the dicoms. This is unusual for a CT, and maybe it interferes with some heuristics.

[deepakri201]

@pieper I thought this looked strange too. Just to check I loaded the original CT nifti and label nifti file (they are from TotalSegmentator training data), and they look like the DICOM files:

[pieper]

@deepakri201 where you able to try OHIF v3 on this data? It has a different approach and might not have this issue.

[fedorov]

@igoroctaviano has GCP store selection been integrated into v3? If yes, testing this should be trivial with our existing IDC v3 sandbox. If not, we should just wait until that feature is ready and revisit then.

[fedorov]

Related discussion in Slicer forum: https://discourse.slicer.org/t/convert-ct-nifti-file-to-dicom-using-slicer-modules-createdicomseries/31921

[sedghi]

Can you try OHIF v3 (latest master branch) and see if you still have this issue?

[igoroctaviano]

@sedghi this is how it looks using /local:

[sedghi]

At least it shows something in v3 (compared to v2 :D)
Is there anything specific regarding this SEG compared to other SEGs?

[igoroctaviano]

@sedghi It does load in v2 but the window level is messed up too.
@fedorov any updates about this seg?

[fedorov]

We reviewed this example with David Clunie, and he noticed that the slices have rather unusual for a typical DICOM resolution (since the original DICOM data was resampled and cropped prior to creating the source NIfTIs), resulting in an odd number of pixels in a frame, which may trigger a bug in OHIF v2. We will investigate this further with the OHIF team, and will try to make sure this is fixed for OHIF v3.

Deepa, can you try padding the original image to some typical matrix (ie 256x256 or 512x512) and see if that fixes the issue?

[deepakri201]

Still using OHIF v2 -- I tried padding the volume as @fedorov suggested, and now the CT/SEG load successfully in OHIF (as well as in Slicer).

TotalSegmentator_DICOM_OHIF_video.mp4

[fedorov]

Thank you, this confirms the source of the problem I think. For our purposes, it makes sense to pad those images to standard matrix size.

In general, for OHIF maintainers, I think it is important to be aware of this bug in OHIF, but fixing it is most definitely not a priority for IDC.

[sedghi]

Deepa, can you try padding the original image to some typical matrix (ie 256x256 or 512x512) and see if that fixes the issue?

@fedorov so what was the problem? the labelmap was not the same exact size of the reference?

[fedorov]

My current understanding is that he problem is that when the Rows*Columns of the image result in a number that is odd, or maybe not divisible by 8 resulting in lack of byte boundary alignment of bit-packed SEG content, or something like that (I have not debugged, so I do not know for sure) - bad things will happen with SEG in OHIF. If someone would like to debug this further, the sample provided by @deepakri201 in the initial post should be a good start.

[sedghi]

Great explanation thanks