Hello all,
I’ve been trying to use the dwifslpreproc function to preprocess my data but I’m not too sure if I’m using the correct arguments.
I have 2 runs which have been collected in sequence.
1 b0 volume and 30 b1000 volumes both in AP and PA phase encoding directions.
I’ve concatenated the 4 series of images together using mrcat.
mrcat AP_run1.mif AP_run2.mif PA_run1.mif PA_run2.mif -axis 3 allRuns.mif
Then called dwifslpreproc on my allRuns.mif file with the following flags: -rpe_all -pe_dir AP
While this command runs without errors, it does not produce a good result and there are large distortions in the frontal region.
Reading the documentation on dwifslpreproc I realized maybe I don’t fit into the category that I thought as it states " two acquisition protocols are concatenated into a single DWI series containing all acquired volumes. " and I have 4 acquisitions.
Any advise would be greatly appreciated! Thank you in advance for your help!
Firstly, you state that there were “2 runs collected in sequence”, then “in both AP and PA phase encoding directions”. Based on your exemplar mrcat call, am I correct in interpreting that the acquisition was as follows:
1 b=0, 30 b=1000, AP phase encoding
1 b=0, 30 b=1000, AP phase encoding
1 b=0, 30 b=1000, PA phase encoding
1 b=0, 30 b=1000, PA phase encoding
, and specifically that the 30 b=1000 diffusion sensitisation directions are identical between the four series?
I’m not sure whether or not the mechanisms underlying -rpe_all will handle this situation correctly; it tries to determine the corresponding “pairs” of volumes with equal diffusion sensitisation direction but opposing phase encoding direction, and it’s possible that that may fail if there are duplicate diffusion sensitisation directions. You should be able to tell based on the output image whether this has worked correctly: ideally the output DWIs should contain 62 volumes rather than 124.
there are large distortions in the frontal region.
It’s possible, though not definite, that this problem is wholly independent of the details above. What would help here is to run the dwifslpreprc script again with the -nocleanup option. There will be files within the scratch directory that may assist in figuring out where the problem arises. In particular look at the image and text data that are provided as input to the FSL topup command, and the outputs that it generates. If its estimated corrected b=0 volumes are still distorted, then obviously eddy is going to also produce distorted volumes. You can show us here screenshots of anything that looks suspicious, as well as the topup inputs if you are not sufficiently familiar with its operation to know whether or not those data are correct.
Hello Rob,
Thank you so much for your reply!
I’ve take a look through the data.
This is correct!
I’ve checked this, the output DWI does contain 62 volumes.
I’ve done this and looked through the log.txt file to see what arguments were given to the topup and applytopup commands.
Here’s what I’ve found:
There is one topup call and 2 applytopup calls.
The input image to the topup call is the 124 volume image.
The input image to the first call of applytopup uses a 62 volume image exclusively in the AP direction and the second call uses a 62 volume image exclusively in the PA direction. Both use --topup=field. Both these output images look good, distortions have been corrected.
The input to eddy is the 124 volume image (distortions not corrected. This looks most similar to the original 124 volume image). It also has an argument for topup --topup=field. I also took a look at the image that was provided as a mask, and it looks good and most closely resembles the output images from the applytopup calls.
Thank you again for your help. Please let me know if I can provide anymore information!
The input image to the topup call is the 124 volume image.
The input to topup should be only 4 volumes, being the solitary b=0 volume extracted from each of the four series. Suspect this is just a typo.
The input image to the first call of applytopup uses a 62 volume image exclusively in the AP direction and the second call uses a 62 volume image exclusively in the PA direction. Both use --topup=field. Both these output images look good, distortions have been corrected.
Okay, so if the applytopup results look good, but the output of eddy does not, then somehow the field estimate is being mistranslated.
First thought is to quote here your MRtrix3 version: it’s possible that you’re using an older version that still possesses an issue relating to image strides and how these are manipulated for compatibility with other software packages (which is a persistent gremlin). If however your software is up to date, then I would probably need access to the data in order to poke and prod around.
