Dear All,

I would like to usee DTIPrep, yet I am stucked ad the very first stage, namely at the conversion to Nrdd. I have tried it using GUI, but literally, nothing happened. I got no error message and of course no .nhdr file.

Furthermore, I would like to try it using command line. I download your manual "2014.01.14-quality_control_tutorial_for_DTI_MANUAL" but I cant make it further then step 2a. When I type "DWIConvert" into my terminal, not surprisingly I got an error message "command not found". Is there any software I need to install? So far I got only Slicer

Thank you in advance.

Best,
Jacek

Hi Jacek
thanks for pointing this out, we need to look at the conversion tab, which has not been updated in a while. The current version uses an older conversion tool that used to be disseminated with Slicer (DicomToNRRDConverter), but which is no longer part of Slicer, as it has been replaced with DWIConvert (the Slicer module is called DWIConverter).

Best, download the newest version of Slicer and use that module (DWIConverter) to convert your DICOM folder with the DWI/DTI data into a NRRD file, which you can then load into DTIPrep.

Best regards
Martin

What type of input data do you have?
Are you selecting the Slicer module DWIConverter?

Are you specifying the input/output data in the DWIConverter module? 

Best, 

Juan

Dear All,

Thanks for your tips. Yes I tried using Slicer DWIConverter, but the only difference in comparison to converter in DTIPrep is, that this time I got at least an error message.
I use "regular" .dcm files.

I dont quite understand what should I do with the fields: Input/Output DWI Volume, there is nothing I can select in here, so it remains "none".
I specified Input Dicom Data Directory, Output Directory and Gradient Vector File, but still all I got is an error message.


Cheers,
Jacek

Hi Jacek
You need to specify Input Dicom Data Directory and Output DWI Volume file. Use option DicomToNrrd. I am not sure you need Output Directory, but it should not hurt. 

Do not specify the NiftiFSL options such as the input bvec file.

Under advanced conversion parameters, try enabling the "Use BMatrix Gradient Directions"

Btw, what is the error message that you are getting (Check also the "error log" window)

Martin

Hi Martin,

I specified Input Dicom Data Directory and as a Output  DWI Volume file I just selected "DWI Volume file" . I can only choose between "none" or "Rename Currect Diffusion Weigted Image" or "Create new...", "Create new as..." or "Delete ..."

So I got an following errors:

Found CommandLine Module, target is /Applications/Slicer.app/Contents/lib/Slicer-4.5/cli-modules/DWIConvert
ModuleType: CommandLineModule
DWIConverter command line:

/Applications/Slicer.app/Contents/lib/Slicer-4.5/cli-modules/DWIConvert --conversionMode DicomToNrrd --outputVolume /var/folders/7q/y90nswcn65sfpj6wt7h47p3c0000gn/T/Slicer/JDJ_vtkMRMLDiffusionWeightedVolumeNodeB.nrrd --inputDicomDirectory /Users/Jacek/Desktop/Tracula/dti_jacekmanko --useBMatrixGradientDirections --outputDirectory /Users/Jacek/Desktop --gradientVectorFile / --smallGradientThreshold 0.2

and this one too

DWIConverter standard error:

W: DcmItem: Length of element (6423,726d) is odd
E: DcmElement: Unknown Tag & Data (6423,726d) larger (778269289) than remaining bytes in file
E: DcmElement: Unknown Tag & Data (2020,3020) larger (808464430) than remaining bytes in file
E: DcmElement: Unknown Tag & Data (2020,3020) larger (808464430) than remaining bytes in file
/Users/..../Medphys_Asperger_20100213_s0008_i0001.dcm has no non-zero diffusion vectors
libc++abi.dylib: terminating with uncaught exception of type std::ios_base::failure: basic_filebuf::underflow error reading the file
DWIConverter terminated with an unknown exception.

To make it more complicated - I have now used Slicer v 3.6.3 on Windows and I got the following feedback, but I got a output file in .nrrd format.

Dicom to Nrrd Converter standard output:

C:/Users/Jacek/.../data.nrrd
ORIGINAL\PRIMARY\M\ND\MOCO\DICO\MOSAIC
Image acquired using a Siemens scanner
Siemens Mosaic format
WARNING: Unknown transfer syntax, assuming little endian. This may cause strange results, such as bizarre b-values and directions



My another question is, I gues we all have more than one subject, is there a way to automatize this conversion using command line?

Hi Jacek
Does the nrrd file look okay when loaded in Slicer or DTIPrep? If so, then at least you have found a workaround. Which is surprising as DicomToNrrdConverter is basically the same as DWIConvert (DWIConvert is a newer version of DicomToNrrdConverter).

Re calling this on the command line: Yes, most Slicer modules have a command line interface. Not sure about how to do that in Windows (this is really a question for the Slicer user-list), but in Linux you can find all built-in modules in the folder /lib/Slicer-/cli-modules . You can also call (again in Linux) Slicer --launch e.g. Slicer --launch DicomToNrrdConverter

Martin

Dear Martin,

Thank you for your help! I have already conducted my quality assurance analysis the way I wanted!

I'd like yet another question that does not belong to this topic but nevertheless I dare myself to ask it. You see, in 30% of my data, the report indicates "Too many bad gradient directions found" after that, as defined in my protocol, analysis stops. Does it mean that all of these subjects are to be excluded?

Hi Jacek

Well, it should, but there is a bug (that we have not yet looked into) that can (quite often) lead to an incorrect printout of that line. 

By default, DTIPrep will not write out a final QC'ed image if there were indeed too many gradients excluded (as defined by the "QC_badGradientPercentTolerance" parameter). So, if DTIPrep generated the QC'ed DWI image, then you are all fine.

If no QC'ed DWI image as generated, then indeed there were too many bad gradients. Please, be aware that the default threshold for that is set a bit stringent, i.e. it's perfectly fine to relax it a bit, e.g. to 0.3 (30%), or even higher depending on the number of starting gradients.

Martin

DWIConverter standard error:

W: DcmItem: Length of element (7453,6475) is odd
E: DcmElement: Unknown Tag & Data (7453,6475) larger (1936607609) than remaining bytes in file

I am getting this error message when trying to convert dcm to nrrd in slicer 4.5. The window says the conversion is 100% complete; but not .nnrd file is output into folder.

thank you

marie

Hello all,

I have for the first time acquired data with two b-values and when converting these from DICOM to nrrd, the second b-value is nor correctly identified. I originally have files with b=0 (10), b=700 (30 directions), and b=2850 (60 directions), however after converting them using DWIConvert from the command line, the bval file contains b=0, b=1412, and b=2850. When I do an intermediate conversion from DICOM to FSL and then from FSL to nrrd, they are all correct. Any idea what this may be caused by? Also, do I need to make changes to the default settings in DTIPrep?

Thanks in advance, Maike

Hi Maike
That sounds like a bug in DWIConvert. Can you file a bug with them (DWIConvert is not part of DTIPrep, but rather an external tool that is used by DTIPrep). 
here is the github page to DWIConvert: https://github.com/BRAINSia/BRAINSTools/tree/master/DWIConvert

Best
Martin

Thanks, Martin for the quick reply. Do you have any thoughts on using DTIPrep when acquiring DWIs with 2 b-values. In a test run, a lot of gradients were excluded and I wonder whether this is because of the different b-values? Or should it work just fine and that subject was particularly bad?

Thanks in advance, Maike

Hi Maike
DTIprep has a built-in support for multiple b-values in that it adjusts the checking parameters for the different b-values. So that should be fine.

But the default values by DTIPrep for high b-values are too strict and thus many high b-value DWIs are rejected if you use the default parameters. Best adapt them to be less strict. Double check your output, either the text report or the xml result, to see which step kicks out your DWIs (assuming they look good if you visually inspect them either with DTIPrep, Slicer or fslview), then go to the parameters for that step and increase the thresholds/sigmas.

Of course, that particular dataset may be quite bad, but you should be able to also visually see that. DTIPrep does not necessarily detect things that cannot be seen by the pure eye, but rather it standardizes & automizes the QC process (i.e. you could also visually check all your DWIs for all your datasets, which is though less stable/reliable and significantly more time consuming).

Martin

Hey Martin,

thanks for the quick replay again. I now checked again another subject, and this one looks indeed better. However, the resulting bval file only includes one b-value (apart from the first b=0), even though volumes from the other bval are still included. Are they somehow transformed to the same bval? Or what is happening here? I attached a bval file with the first 100 lines displaying the original and thereafter the qced version as example.

Thanks again, Maike

Hi Maike
Not sure what's happening. The DWI's should not be transformed to a single b-value (not even sure that's possible). Thus, this is likely a bug in DWIConvert. I am though not an expert of the DWIConvert code etc. Can you send this isseu to the DWIConvert githubpage: https://github.com/BRAINSia/BRAINSTools/tree/master/DWIConvert

Martin

Okay. And would there be a way to check that they are still correct in the qced.nrrd file?

Thanks, Maike

If they are correct in the input nrrd file to DTIPrep, then they should be correct in the qced.nrrd file (as there is no conversion happening as part of DTIPrep).

Best
Martin

Hi all, I figured I'd ask my question here rather than creating a new thread, as my issue pertains specifically to the DWIConvert tool.

In brief summary, I've converted my NIFTIs to NRRDs so that I can use DTIPrep's denoising and artifact checking tools, after which I've converted the QCed NRRDs back to NIFTI so that I can use FSL's FDT tools for further preprocessing (i.e., fsl eddy). 

Eddy outputs a file called data.nii.gz.eddy_restricted_movement_rms in which there are estimates for movement (1) relative to the first volume (the b0) and (2) between each consecutive volumes. I use this movement estimation file to identify subjects with excess movement in the scanner to remove them from analysis.

Here is the puzzling output that I get, where the first column indicates type-(1) values and the second column indicates type-(2) values: 

0 0
0.0004349732621 0.0004349732621
0.1293237744 0.1290371457
0.0770145743 0.0787793649
0.1380966347 0.1334343518
0.120617891 0.0671182883
0.2690339005 0.164081166
0.3256238628 0.07334808195
0.1346585371 0.1988556541
0.1346585371 0
0.1346585371 0
0.1346585371 0
0.1346585371 0
0.1364517787 0.06969197052
0.2810317103 0.1871601272
0.2053992891 0.1139292096
0.1838997283 0.04258127975
0.1850058225 0.03042424084
0.1640395851 0.04978561965
0.1441797516 0.03871081352
0.1411901608 0.08651112032
0.05642180761 0.09891716264
0.1132709746 0.1019541404
0.198486599 0.2614182835
0.2152392961 0.02585408788
0.2636229757 0.05646168819
0.2057839289 0.111750168
0.2018872141 0.06196124255
0.3124672885 0.1476290345
0.3520931575 0.07196218901
0.2838850662 0.09389126276
0.3076169748 0.04724860972
0.3053632287 0.0193159719


According to this, there is absolutely zero movement between a consecutive 4 volumes, which seems unlikely, if not impossible. I get similar strange looking output for many other subjects processed using DTIPrep tools and then FSL eddy. Importantly, I get normal-looking movement estimation when I do not use DWIConvert or DTIPrep's tools.

To identify the problem, I've tried only using DWIConvert from NIFTI to NRRD and then again from NRRD to NIFTI without using any of DTIPrep's preprocessing tools. In theory, there should be no change in the NIFTI after converting to and from NRRD. However, after running FSL eddy again on this back-and-forth-converted dataset, I still get strange eddy movement estimation in that it indicates absolutely zero movement between certain volumes.

Does anyone have any insight into what may be causing the problem? Converting from NIFTI to NRRD back to NIFTI using DWIConvert seems to change the alignment of volumes. But I'm not quite sure.

Thank you very much in advance.

Hi Ryan

Not sure what's happening. It seems this behavior stems from DWIConvert (which we do not maintain, but rather is a Slicer module).

Alternatively it may be FSL who does not play well with DWIConvert (FSL is known for having its own info in the nifti header that can provide conflict information to elsewhere in the header, thus as long as you stay within FSL everything is fine, but when converting to the outside bad/confusing things can happen when the conversion program is not using the FSL specific info but the "correct" Nitfi info).

Did you compare the bval and bvec files when you ran NiftiToNrrd and then again NrrdToNifti on the same data? Do they look the same? If you run fslinfo on the nifti before and afte conversion, do you get the same output?

Best regards
Martin

Hi Martin, thank you for the response!

Here's the raw dwi.nii.gz before DWIConverting:
$ fslinfo raw_dwi.nii.gz
data_type FLOAT32
dim1 128
dim2 128
dim3 70
dim4 33
datatype 16
pixdim1 1.875000
pixdim2 1.875000
pixdim3 2.000000
pixdim4 8.844934
cal_max 0.0000
cal_min 0.0000
file_type NIFTI-1+

Here it is after DWIConverting to NRRD, running DTIPrep, and DWIConverting back to NIFTI:
$ fslinfo raw_dwi_QCed.nii
data_type INT16
dim1 128
dim2 128
dim3 70
dim4 33
datatype 4
pixdim1 1.875000
pixdim2 1.875000
pixdim3 2.000000
pixdim4 1.000000
cal_max 0.0000
cal_min 0.0000
file_type NIFTI-1+


It looks like there is change in the data_type and pixdim4. Do you think this would be an issue? And my bval and bvec files are the same before and after conversion.

It could very well be that the issue is the data type. Not sure what DWIConvert does with float data (it probably casts it to short/Int16), as it expects short data. A possibility is that the nifti header says one thing and some FSL tag in the header says another thing (i.e. the data is actually not float, as the nifti header info is wrong).

Did you get the raw dwi data directly from the DICOM conversion? The acquired raw data should be in short, not float. Also pixdim4 should be 1 or 0 (the 4th dimension is the DWI volumes, in this case you have 33 DWIs, which have, according to fslinfo, a spacing of 8.8, which is really non-sensical as DWIs don't really have a spatial spacing), though i don't think that this is what causes DWIConvert to do something incorrect.

What conversion tool did you use (we use dcm2niix to go to nifti data from DICOM), maybe that's the issue? Alternatively you could go from DICOM to NRRD with DWIConvert, apply DTIPrep and then convert to Nifti for further processing in FSL. 

Martin

I see, that all makes sense. I used dcm2niix to go from PAR/REC to NIFTI (this data is from a Phillips scanner). 

I entered "more *PAR" into my command line and found this, which might be helpful:

# slice number (integer)
# echo number (integer)
# dynamic scan number (integer)
# cardiac phase number (integer)
# image_type_mr (integer)
# scanning sequence (integer)
# index in REC file (in images) (integer)
# image pixel size (in bits) (integer)
# scan percentage (integer)
# recon resolution (x y) (2*integer)
# rescale intercept (float)
# rescale slope (float)
# scale slope (float)
# window center (integer)
# window width (integer)
# image angulation (ap,fh,rl in degrees ) (3*float)
# image offcentre (ap,fh,rl in mm ) (3*float)
# slice thickness (in mm ) (float)
# slice gap (in mm ) (float)
# image_display_orientation (integer)
# slice orientation ( TRA/SAG/COR ) (integer)
# fmri_status_indication (integer)
# image_type_ed_es (end diast/end syst) (integer)
# pixel spacing (x,y) (in mm) (2*float)
# echo_time (float)
# dyn_scan_begin_time (float)
# trigger_time (float)
# diffusion_b_factor (float)
# number of averages (integer)
# image_flip_angle (in degrees) (float)
# cardiac frequency (bpm) (integer)
# minimum RR-interval (in ms) (integer)
# maximum RR-interval (in ms) (integer)
# TURBO factor <0=no turbo> (integer)
# Inversion delay (in ms) (float)
# diffusion b value number (imagekey!) (integer)
# gradient orientation number (imagekey!) (integer)
# contrast type (string)
# diffusion anisotropy type (string)
# diffusion (ap, fh, rl) (3*float)
# label type (ASL) (imagekey!) (integer)

I think the types listed in your email is the type of the entry in the PAR header, e.g. 
slice number (integer) => the slice number is an integer, and not the datatype of the data.


But, given that you indeed directly converted these with dcm2niix, this could indicate an issue with that conversion (as mentioned before it should be type short)?

If you do the conversion from nifti to nrrd and look at the nrrd header (e.g. via "more" as it's the header entries are in ASCII, or you could use "unu head ", unu is part of the Slicer distribution), is the datatype float or short? 

Martin