Organizing data for dwipreproc

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

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


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.


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 ?



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.

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

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 …

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.

1 Like

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?

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.

Hi. I am new to the forum, so I’m not sure this is the best way to post my question - but it would seem to be best related to this topic.

We have collected single shell data, 32 direction data (first acquisition is b=0, plus three additional b~= 0 interspersed within the b=1000 scans - they can’t be exactly zero, that’s a Philips limitation) with PA and AP data collected for all directions (separate scans on a Philips 3T Elition). My processing stream is as follows:

mrconvert each scan
dwidenoise each scan
mrcat the two scans
dwipreproc as follows:
dwipreproc DTI_combined.mif DTI_combined_EddyCorrected.mif -rpe_all -pe_dir PA -readout_time 0.0528 -eddy_options " --repol --acqp=AcqParameters_1acq.txt --index=indexFile.txt -export grad fsl --s2v_niter=5 --s2v_lambda=1 --s2v_interp=trilinear --mporder=6 --slspec=SliceOrder_MB3.txt"

where the file AcqParameters_1acq.txt has two lines for positive and negative PE, as follows:
0 1 0 0.0528
0 -1 0 0.0528,

and indexFile.txt is a string of 36 1’s and then 36 2’s.

What I don’t understand is that it seems to be running topup on the b=0 images only (topup_in.nii has 8 volumes), even though we have specified -rpe_all.

One thing I noticed is that the first b=0 image has been placed at the very end. I am pretty sure this is a Philips convention, but I am wondering if this is somehow overriding the rpe_all option.

Any thoughts/advice about this would be most appreciated! Thanks.

Mark Wagshul

–acqp=AcqParameters_1acq.txt --index=indexFile.txt

I should probably modify dwipreproc to catch these fields being passed via -eddy_options and return an error…

One of the principle aims of dwipreproc is to prevent users from having to construct such data, by providing the -rpe_* / -pe_dir command-line options, and constructing such data for topup / eddy itself. If you’re accustomed to such data, and to the underlying FSL commands, you could of course run those manually. But I would be surprised if eddy doesn’t return an error in this instance, since when invoking it, dwipreproc will provide it with the --acqp and --index command-line options twice: once with the data it has generated itself, and once with the text you have passed through via -eddy_options.

What I don’t understand is that it seems to be running topup on the b=0 images only (topup_in.nii has 8 volumes), even though we have specified -rpe_all.

topup is designed to operate on b=0 data only. Even if you have reversed phase-encode data for all DWI volumes, this does not influence the estimation of the inhomogeneity field; it only triggers explicit recombination of image volumes with equal diffusion sensitisation but opposing phase encoding after eddy has completed.

One thing I noticed is that the first b=0 image has been placed at the very end. I am pretty sure this is a Philips convention, but I am wondering if this is somehow overriding the rpe_all option.

I can’t say I’ve ever actually come across such, but I don’t think that this should cause an issue: all b=0 volumes are extracted in order to run topup, and dwipreproc ensures that the first b=0 volume provided to topup is also the first volume of the input image provided to eddy, to guarantee appropriate co-localisation of the estimated inhomogeneity field with the input DWI data in eddy.