dcm2niix v1.0.20220720 - Philips scanner: slice thicknesses and Philips R3.2.2 bug

[greydongilmore]

Describe the bug

When running dcm2niix on MRI data aquired with a Philips Achieva 3.0T scanner it does not execute to completion. dcm2niix first warns about slice thicknesses then reports the DICOM files are not large enough to store imaging data.

To reproduce

Steps to reproduce the behavior:

1. Run the command dcm2niix, no flags, only the path to DICOM directory

Please check slice thicknesses: Philips R3.2.2 bug can disrupt estimation (1 positions reported for 0 slices)
FileSize < (ImageSize+HeaderSize): 158716 < (9437184+27644) 
Warning: File not large enough to store image data: ./MR_sAX___B1000_2022-02-11_11-16-56/a586dc4c9700b0ffd6cd3b9922c34dff.dcm
FileSize < (ImageSize+HeaderSize): 158768 < (9437184+27696) 
Warning: File not large enough to store image data: ./MR_eReg_-_AX_DTI_POST_PROCESSED_2022-02-11_11-16-56/ddca14f571596e2fda6a03d59b7b723e.dcm
FileSize < (ImageSize+HeaderSize): 551376 < (16777216+27088) 
Warning: File not large enough to store image data: ./MR_COR_SSh_T2_SURVEY_2022-02-11_11-16-56/8bda8f4144f96f34311a08d178b0f796.dcm
FileSize < (ImageSize+HeaderSize): 347074 < (17920000+27074) 
Warning: File not large enough to store image data: ./MR_COR_FLAIR_TEMPO_2022-02-11_11-16-56/748ebe81a3b15e49c81c804957d3e6f2.dcm
FileSize < (ImageSize+HeaderSize): 487864 < (25804800+27064) 
Warning: File not large enough to store image data: ./MR_COR_T2_TSE_TEMPO_2022-02-11_11-16-56/25b4b050f9708a1883de6d4ebf8043a6.dcm
Slices not stacked: orientation varies (vNav or localizer?) [0.989297 0.0736408 -0.125973 -0.12585 -0.00631873 -0.992029] != [-0.0738498 0.997265 0.00301661 -0.12585 -0.00631873 -0.992029]
FileSize < (ImageSize+HeaderSize): 400234 < (746496+26986) 
Warning: File not large enough to store image data: ./MR_MPR_-_AX_3D_T1-TFE_2022-02-11_11-16-56/4b1cd6e6b946d90863d3b4f981e27884.dcm
FileSize < (ImageSize+HeaderSize): 400234 < (746496+26986) 

Version

Please report the complete version string: v1.0.20220720 running on Pop!_OS 22.04 LTS Jammy x86_64

Troubleshooting

I first attempted the development branch but I still experienced the same error.

[neurolabusc]

Is this issue specific to dcm2niix - does dicm2nii show the same behavior. I do not have access to Philips hardware, but dcm2niix works fine with Philips validation from 2.5.3..5.1.1 and 5.7.1. I can not provide more insight without seeing a sample - can you share data with my institutional email?

[neurolabusc]

@greydongilmore your DICOM images have been corrupted. This is a limitation of your images, not dcm2niix. A tag with VR IS (Integer String) should have an even length of 2..12 bytes, but your DICOMs emptied the tag (length of zero bytes) without omitting the tag.

You can see the issue by running dcmdump or gdcmdump on one of the DICOMs:

(0028,0008) IS (no value)  # 0,1 Number of Frames

I have added a patch to the development branch of dcm2niix to handle this specific issue, but other tools that assume valid DICOMs will likely have issues with these images. You can try to restore your images to DICOM conformance with dcmodify:

dcmodify -ea "(0028,0008)" *.dcm

or use gdcmanon

gdcmanon --dumb --remove 0028,0008 bad.dcm good.dcm

You probably want to check the provenance of these images to see which PACS or tool is corrupting these images. While it is easy to add a kludge in dcm2niix, no DICOM in this form can be considered archival quality. I suspect an anonymization tool or a tool that converted enhanced DICOM to classic DICOM is to blame. While the last PACS to touch these is the well regarded DCMTK, I note the images were touched by a GEIIS system. Those historically have a bad reputation (though they may have been patched to improve their behavior).

[neurolabusc]

My latest commit dcm2niix will simply ignore empty tags, as the standard does say it is legal for unknown Type 2 tags to provide a zero length value., with the case of IS VRs discussed here. I still think your DICOMs are invalid, as NumberOfFrames (0028,0008) is a Type 1 tag, so it should either specify a value or be omitted. However, I do think my commit will make dcm2niix more resilient to these sorts of issues.

To validate, on can empty the IS VR of the Type 2 EchoTrainLength (0018,0091) as follows:

gdcmanon --dumb --empty 0018,0091 good.dcm bad.dcm

[greydongilmore]

Thank you @neurolabusc for such a quick response. I will contact our PACS team and see if I can get uncorrupted instances of these DICOMS.

Worthwhile to note, I am using 3D Slicer v4.11.20210226 to pull from our hospital PACS system. I will also try other methods of querying and report results here.