questions > Volume split when converted from dicom to nii
Showing 1-2 of 2 posts
Results per page:
Feb 25, 2019  03:02 PM | Rita Chen
Volume split when converted from dicom to nii
I have an MRI study with a single patient and series as dicom images but for some reason when I convert to Nifti with dmc2niix it gets split into 2 volumes. I tried opening it with MRIcroGL to check and it looks like it's been split into the lower and upper half of the head. (this is still just a single .nii file with two volumes, not that it was output as two separate .nii files).

I'm not sure it's the conversion, but I checked the metadata for the dicom and it should be one single volume. Does anyone know how to keep it as one volume during conversion? Or just simply merge the two volumes together to get one? As it is now, loading it into a program that doesn't allow you to choose which volume to view defaults to the lower half of the head (I assume since it's the first one in the array) but I need the entire head.
Attachment: volumesplit.png
Mar 10, 2019  02:03 PM | Chris Rorden
RE: Volume split when converted from dicom to nii
The problem is not with dcm2niix, but your images. One set does not have the transfer syntax set - this is a Type 1 property, so these are not longer valid DICOMs. The second case has been corrupted with variable slice instance UIDs. In both cases, I think you can fix this by working out the providence of these images and getting copies prior to corruption.

For the second case, dcm2niix clearly warns you:

slices not stacked: series instance UID varies (duplicates all other properties)

You could try to salvage your data with this the "-m y":
dcm2niix -m y -f %t_%s_%p ~/tst/NITRC
But you will need to make sure that you only process one exam at a time.

Your DICOMs have been corrupted: each slice from a single 2D series has been assigned a different StudyInstanceUID, e.g.
(0020,000d) UI [] # 42, 1 StudyInstanceUID
I suggest you check the providence of your images and see where they were corrupted. While I have never heard of "MultiTech msiCOM", this would be my prime suspect.
(0002,0013) SH [MultiTech msiCOM] # 16, 1 ImplementationVersionName