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

*deprecated command with version 3.0.0 in favour of dwifslpreproc

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.

1 Like
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.

10

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

11

–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.

Rob

12

Hi, @rsmith I am sorry for asking like that, but what does " it only triggers explicit recombination of image volumes with equal diffusion sensitisation but opposing phase encoding after eddy has completed" exactly mean?

Thanks for your answer.

13

Finally, found :blush:

14

Dear @rsmith,

I’ve got data in this order:
AP (.nii): 1 volume b0, 30 volumes b700, 30 volumes b1000, 30 volumes b2300, 9 volumes b0
PA (.nii): 1 volume b0, 30 volumes b700, 30 volumes b1000, 30 volumes b2300, 9 volumes b0

If I am right, since I’ve got my bval and bvec files in right order, it IS NOT necessary to re-order data (so all of my b0s would be in the beggining of the nifty file).

So my preprocessing pipeline will be:

mrconvert both files with -fslgrad option
dwidenoise both
mrdegibbs both
mrcat them
dwipreproc AP_PA.mif AP_PA_preproc.mif -pe_dir AP -rpe_all -eddy_options " --slm=linear --repool "
dwibiascorrect -ants…

Thanks for answer and for your time. I really appreciate it since I am new user. :slight_smile:

EDIT: Just find out, that I can do it, but it is time consuming like hell. Little help to topup with -se_epi option in dwipreproc is not such a bad idea :smiley: .

15

Finally, found

Yep, that’s the one. Note that this is different to the “least-squares reconstruction” that is described in the Andersson 2003 manuscript, and is provided with eddy. When I first wrote what was the precursor to dwipreproc, that capability was disabled in the public version of eddy, so I implemented this instead; I’ve never since gotten around to mucking around with LSR, I read somewhere it can have ringing artifacts in the results but I’m not aware of a genuine comparison between the two approaches.

If I am right, since I’ve got my bval and bvec files in right order, it IS NOT necessary to re-order data (so all of my b0s would be in the beginning of the nifti file).

If you are using the -rpe_all option, then it’s not only not necessary, but would be erroneous. The -rpe_all option has to make an assumption regarding how the input data were acquired, since you’re not providing any metadata over and above just specifying that option; so the assumption it makes is that the second half of the volumes have the opposite phase encoding direction to the first half. If you were to move the b=0 images from your second phase encoding direction to near the start of the 4D image series, that assumption would be broken.

If you were instead using the -rpe_header option, and the phase encoding information was tracked in the image headers throughout pre-processing, then dwipreproc would just figure out what to do based on that table, regardless of how you reordered them. But that’s not possible for data from certain vendors.

Just find out, that I can do it, but it is time consuming like hell. Little help to topup with -se_epi option in dwipreproc is not such a bad idea

Yes, the runtime of topup scales with the number of input volumes, and the command is purely single-threaded, so it can take a long time. I’m hoping that Jesper will improve this at some point at the FSL end. I’ve been hesitant to do anything to address this automatically in dwipreproc, since you can have rigid motion in between b=0 volumes and so explicitly merging them first or discarding some may not be ideal.

16

Thanks for perfect explanation.

Thanks. Just one question to make sure I’ve got it. Merging my AP’s b0s and PA’s b0s to one 4D file and put it into -se_epi option is not a good idea, because of the motion possible between my b0s in this experiment (b0s at the beginning and at the end of both of my sequences)?

But If I would have situation like this:
AP (.nii): 10 volume b0, 30 volumes b700, 30 volumes b1000, 30 volumes b2300
PA (.nii): 10 volume b0, 30 volumes b700, 30 volumes b1000, 30 volumes b2300

can I use it, or because there is still a chance of motion in between AP’s b0s and PA’s b0s, it is better to run it without -se_epi option, no matter how much time topup can consume?

I’m trying to go through discussions here and through documentary, that contains -se_epi describtion, but I am still a little bit confused about it. Thanks for your time!

17

Merging my AP’s b0s and PA’s b0s to one 4D file and put it into -se_epi option is not a good idea

No no, that’s fine; as long as the script has a way to figure out the phase encoding of the individual volumes within that image. If your original images have phase encoding information in the header, then using mrconvert to extract specific volumes will also modify the phase encoding information in the output image to suit. This is required for the -rpe_all and -rpe_header option usages. The benefit of this approach compared to using -rpe_all and omitting -se_epi is potentially providing a subset of b=0 volumes to topup to make it run faster. My prior comment:

I’ve been hesitant to do anything to address this automatically in dwipreproc , since you can have rigid motion in between b =0 volumes and so explicitly merging them first or discarding some may not be ideal.

was specifically in reference to doing something like calculating the mean b=0 AP image and the mean b=0 PA image and then providing those two volumes to topup, which wouldn’t be ideal if there were motion between the acquired volumes.

Doing something like grabbing the first and last AP b=0 volumes, and the first and last PA b=0 volumes, wouuld probably be reasonable if your aim is to reduce the topup runtime. But I’m hesitant to do something like this automatically within the dwipreproc code since there are instances where doing so could case problems.

, because of the motion possible between my b0s in this experiment (b0s at the beginning and at the end of both of my sequences)?

can I use it, or because there is still a chance of motion in between AP’s b0s and PA’s b0s, it is better to run it without -se_epi option, no matter how much time topup can consume?

To be clear: if you are using -rpe_all, topup will always be run, and it will always estimate motion in between the image volumes provided to it. The only difference introduced by specifying or not specifying the -se_epi option is whether or not all b=0 volumes will be extracted from the input DWIs and provided to topup, or whether you manually specify yourself via the -se_epi option the image volumes to be provided to topup.

18

Been a while since this thread has been active, but it’s worth a shot. While I’m sure this varies drastically between computers and # number of volumes…how long did topup take to run for either of you? I have 62 volumes.

19

@Andre_Zamani: The run time of topup will depend on the number of b=0 volumes rather than the total number of DWIs, as these are the only data on which it operates. It will also depend on your spatial resolution. If I had to guess I’d say that ~ 5 minutes x number_of_b=0's would be a reasonable guess for typical resolutions? So it can blow out quite a bit if you have a lot of b=0’s.