Inquiry on DICOM to NIfTi

[mikaelhaji]

The Bug

I am working on a project that involves converting personal CT data to .nii. However, I came across a couple of challenges that I was hoping to get help on!

Situation Overview

1. I am converting DICOM files obtained from CT scans into NIfTI format. These files are stored in a directory named "Wes' CT Data" on Windows 10 system.
2. The conversion process is initiated with the following command: dcm2niix.exe -f "%f%p%t_%s" -p y -z n -o "C:\Users\mikae\Desktop\converted-nifti" "C:\Users\mikae\Desktop\Wes' CT Data"

Expected behavior

1. Slice Thickness Determination: The tool reports being "Unable to determine slice thickness: please check voxel size." This raises concerns about the accuracy of the spatial information in the converted NIfTI files.
2. Image Decompression Warning: A warning indicating "Image Decompression is new: please validate conversions" appears, suggesting potential issues with the integrity of the decompressed images.

Despite these warnings, the tool successfully converts the DICOM files, producing NIfTI files with varying dimensions, however, the files are all of different sizes and seem to have gone down in resolution and squishified into itself when visualizing in Matlab (screenshot provided).

Output log

Matlab Visualization

I tried visualizing the other NII files and it seems to show other parts of the CT scan:

CT Files

[neurolabusc]

1. You will get the Unable to determine slice thickness: please check voxel size error if both Spacing Between Slices (0018,008) and Slice Thickness (0018,0050) are not populated. These are required DICOM tags, so you should check the provenance of your images to see if they got removed by an over-zealous anonymization stage. Computing the slice thickness is tricky. Since NIfTI only stores the distance between voxel centers (slice thickness + slice gap), the NIfTI file may be able to resolve the distance by comparing the Image Position Patient (0020,0032) between two neighboring slices. I would use dcmdump and fslhd to check your input DICOMs and output NIfTI images carefully.
2. Your visualizations look very squashed in the slice direction, suggesting your images are anisotropic. Do they look squashed with MRIcroGL (suggesting an issue with your DICOMs) or only in Matlab (suggesting the Matlab code assumes isotropic data).
3. By visual inspection, it looks like your images decompressed nicely.

[mikaelhaji]

Thank you so much for the prompt response!

1. re. This makes a lot of sense! I checked the Report that came with the CT data and I see a variable for Nominal Single Collimation Width: 0.70 mm. Would it make sense to manually populate both Spacing Between Slices (0018,008) and Slice Thickness (0018,0050) with this number (0.7mm).
2. re. I think Matlab seems to be assuming isotropic data! The function I am using is the isosurface function. Is there a normalization/preprocessing step I should be going through to ensure that the CT data accounts for its anisotropy? I put the DICOM files into Slicer, and it seems to not be squashed so the latter definitely seems more likely?

Slicer - Is it Squished?

3. re. If you refer to the slicer video above, you will notice that it's a little fuzzier compared to the built-in visualization that came on the Disc of the CT scan. Would love your thoughts if that is a worry.

Data that came with the CT Scan

Side Question: Would love to hear your thoughts on the file formatting, specifically interested in why several NII files get created during conversion!

Thank you so much for all your help once again.

[mikaelhaji]

Updates [still inquiring about the messages above!] ->

2 (more info). The issue seems to arise as there is about 512 slices (with 5 [not sure the units] spacing) for two axes and then 37 (with 0.5 [not sure the units] spacing) for the other slice causing the squish. I updated the Matlab code to effectively make up for this in the actual grid spacing, as well as in the aspect ratio of the grid, but it seems to be blowing up. Not sure if there's a better way to go about doing this (ie normalizing the skull to become isotropic?) as this is what my CT scan looks like right now:

im also not quite sure if this large difference in number of slices is normal

Side Question: Would love to hear your thoughts on the file formatting, specifically interested in why several NII files get created during conversion! I realize these are simply just different views/sessions - with "2" being the standard slice of interest I believe.

Really appreciate the help in advance!

[neurolabusc]

1. With MRIcroGL click the 'Options' button on the 'Layer' Panel and select 'Show Header', this will show both the dimensions, spacing and units (e.g. mm) of your image.
2. MRIcroGL has a Import/Tools/Resize menu item that could allow you to reslice your data to make it isotropic. However, you will necessarily get aliasing artifacts and the file size (and therefore rendering resources) will explode. With MRIcroGL, if you choose Display/Render you will see that it transforms isotropic images on the fly.
3. Anisotropic data viewed with Slicer3D and MRIcroGL will appear crisper or fuzzier depending on the interpolation method used. Try toggling the 'Smooth' button in the '2D Slice Selection' panel of MRIcroGL when the 'Display' menu is set to multiplanar. Note that nearest neighbor interpolation looks jagged, while trilinear interpolation looks fuzzy.
4. Classic DICOM saves each 2D slice as a separate file, a single imaging session is typically composed of several series: the first series is used to position the subsequent scans, with subsequent scans using different positioning, parameters and contrast agents to optimize different types of signal. For most series, dcm2niix and MRIcroGL will save each DICOM series as a separate 3D or 4D file. Therefore, a DICOM session with multiple series will yield multiple NIfTI files.
5. Your DICOM images seem to be missing several of the crucial fields required by the DICOM standard. The opportunity for unintended consequences seems high. I would recommend you work with a valid set of DICOM images. If you can not get these locally, there are large public datasets including the TCIA.