Organizing data for dwipreproc


#1

hello
what is the directory order/file organization before doing dwipreproc?

I have blip up and down data with corresponding bvals and bvecs.

Thanks
A


#2

Hi @ameoded1,

I’m aware that the documentation for dwipreproc really needs examples with images… I just haven’t gotten around to it yet.

In your case the best approach is:

  1. Convert each of the two series independently to .mif using the -fslgrad option to import the gradient tables into the image headers.

  2. Concatenate the two series using mrcat. This will additionally automatically concatenate the two gradient tables.

  3. Provide this image as the input to dwipreproc, either using:

  • -rpe_all to specify that the second half of volumes have precisely the opposite phase encoding to the first but the same gradient directions, as well as -pe_dir to provide the phase encoding direction of the first half of volumes;

  • -rpe_header if the image headers contain the requisite phase encoding information (only if the data are from Siemens and you can convert directly from DICOM).

In either case dwipreproc will automatically extract the b=0 volumes from the input data and provide these to topup, so you don’t need to use the -se_epi option.

Rob


#3

ok
im my case
blip up folder: blip_up.miff, bvecs, bvals
blip_dn folder: blip_dn.mif, bvecs, bvals

do I need to rename bvecs and bvals differently? do you save all files in one new folder and concatenate ?

Thanks

A


#4

You only need the .mif files – no need for the bvecs/bvals, as long as they’ve been included in the header of the corresponding .mif files. I recommend you go through how we handle DW gradients, you’ll probably find most of your questions answered there.


#5

ok thanks

can we go back to .nii after dwipreproc?? can I convert to nifiti my files to be able to work with other programs?

Than you


#6

yes you can convert back to nifti, this will imply than every mrtrix command that need to read the gradient information will be call with the -grad or -fslgrad option. One of the advantage of the .mif format is that the gradient information is stored in the header.
for intance with mrcat with .mif file you do not need to concatenate yourself the bvec and bvals file …


#7

Just to add to that:

To convert to NIfTI and output the corresponding bvecs/bvals at the same time, use the -export_grad_fsl option on the relevant commands.


#8

Hi @jdtournier @rsmith
I have two runs data(a.mif and b.mif) scanning with the same parameters, but different in their transform field(the origin of the image). Now, I want to combine them together to do the analysis. I have two options.
1, I concatenate them together first, and then do subsequent analysis including dwidenoise, dwipreproc and so on.
2, I first align them, and then concatenate them for the follow-up analysis.

Do you think which option is better?
Thanks,
Zonglei


#9

Okay, the recommendation here requires just a bit more information:

If the two runs almost have the same transform, but it’s not precisely identical, and the voxel size / number of voxels along each axis is identical, then concatenating them before any other steps are performed should be fine. There will be an assumption within dwidenoise that the noise level in each voxel in the image is approximately equivalent between the two runs; if this is not the case, either due to spatial mis-alignment or due toe.g. the scanner gain significantly changing between runs, then this approach should not be used. dwipreproc will deal with any residual mis-alignment between image volumes.

If the requirements above are not met, then you’ll be forced to run dwidenoise separately for each of the two runs. The challenge then comes with the dwipreproc step.

If you can put the two series on the same image grid, without requiring interpolation, without the volumes being > 45 degrees out of alignment, and either not using slice-to-volume correction or using it and the two series having precisely the same slice timing, then concatenation of the series prior to motion correction would be preferable, since eddy should deal with any volume misalignments and only introduce one interpolation step.

If you can’t satisfy the above, then you’re stuck with running dwipreproc / eddy separately for the two series, and doing a subsequent registration / transformation / re-gridding to finally get the two series onto the same grid.