questions > DTI split.
Showing 1-5 of 5 posts
Display:
Results per page:
Dec 2, 2017  11:12 PM | Haakon Ramsland Hol - Arendal CNS
DTI split.
Hi I've encountered a problem with anonymous DTI images from a Siemens Aera 1.5 T. scanner. Version E11. DCM2NIIX splits the DTI sequences into pair of files. So from 66 images i get 33 nii volumes, with 2 directions pr nii volumes. And no bvac og .bvel files.

Any encountered this problem before? I've previoulsy used dcm2niix to "deidentify" the images, then everything worked as intended, but now it was a demand that we exported the images anonymously from the scanner.
And I cant remember if the old images were on an older software version of the scanner.

Kind regards
Haakon.
Compression will be faster with 'pigz' installed
Chris Rorden's dcm2niiX version v1.0.20171103 (OpenJPEG build) GCC5.3.1 (64-bit Linux)
Found 66 DICOM image(s)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#11_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#28_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#15_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#13_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#10_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#19_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#24_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#29_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 6 DICOM as ./___ep_b0_20171028164543_7b (110x110x50x6)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#17_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#8_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#2_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#25_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#20_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#26_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#4_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#1_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#6_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#3_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#30_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#27_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#18_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#12_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#9_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#7_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#5_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#23_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#22_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#16_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#21_20171028164543_7b (110x110x50x2)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
slices not stacked: protocol name varies
Convert 2 DICOM as ./___ep_b1000#14_20171028164543_7b (110x110x50x2)
Conversion required 0.159091 seconds (0.159028 for core code).
Dec 3, 2017  01:12 PM | Chris Rorden
RE: DTI split.
The output is pretty clear that it is unable to stack the files because they report a different protocol name. Without seeing your data, I would check the providence of these images - are they direct from the scanner or were they manipulated by some intermediate software that corrupted the protocol names? In particular, in my experience some anonymization tools can wreak havoc with DICOM images.

To see the reported Protocols name, insert it into the output filename with the "%p" option - for example "dcm2niix -f %p_%s /dir/with/dicom" - this might give you a clue.

As noted in the output, you can recompile your own copy of dcm2niix that will stack images even if the protocol name varies. You would simply edit the line in nii_dicom_batch.cpp from 
  if ((strcmp(d1.protocolName, d2.protocolName) != 0)) {
to read
 if (false) {
and recompile. Just be warned that this may have unintended consequences. Often a change in protocol name is something we want to detect.
Dec 4, 2017  10:12 AM | Haakon Ramsland Hol - Arendal CNS
RE: DTI split.
Thanks for the reply.

The images were directly from the scanner. No interference.

If I recompile dcm2niix to accept the images as one stack, will it still give me the .bvec and bval?


Kind regards
H.
Dec 4, 2017  02:12 PM | Chris Rorden
RE: DTI split.
If you recompile the latest code from Github you will get version v1.0.20171204. This will convert your files. You can see the changes to the code here. The issue is that your DICOM images omit the Protocol Name (0018,1030). This is exceptionally uncommon, but technically this is an optional element. Historically, in this situation I have used the 'sequence name' (0018,0024) as a surrogate for protocol name when the latter is missing. This provides a useful description for the data. However, in your case the sequence name actually varies between volumes *ep_b0 *ep_b1000#1, *ep_b1000#2, etc. To handle your data I now keep the protocol name empty if the data comes from a Siemens scanner. A necessary consequence of this change is that Siemens data without a protocol name may be harder to discriminate after conversion. For example, if you wanted the NIfTI data to be named based on the protocol name and the sequence number ("-f %p_%s"), the new version will create files with names like "_3.nii". In general, I would recommend setting up your scanner to include meaningful protocol names.
Dec 4, 2017  02:12 PM | Haakon Ramsland Hol - Arendal CNS
RE: DTI split.
Thank you for the swift reply and solution. I will try it at once. 
The strange thing is that is does have a name, it seems to dissapear when doing the anonymous export from the MRI machine. I looked though a test set of myself which was done on the same software for 2 months ago, and it's seems it only dissapears when doing the anonymous export. This does only happen on the DTI and SWI sequences, on the T1 and T2, the protocol name remains. I don't undestand why this is. 

Anyhow. Thanks again for you invaluable help. 

Kind regards
Haakon