This is my first time trying to run a full DWI preprocessing in MRTRIX from DICOMS, but I am running to some difficulties. I have collected some multi-shell DWI data (1.75mm, 98 dir, b300, b1000 and b2000) in both AP and PA directions.
First, I had to use dcmdjpeg on the DICOM folders, otherwise mrcat did not work.
If the first b=0 volume is indeed empty (all zero), then you want to check at which point in the pipeline the zeros are introduced. Probably best to check the raw data are OK in the first place, by looking at your *AP* input data (same commands as above). If you find a zero-mean b=0 right at the start, then I’d be taking a closer look at what dcmdjpeg is doing.
If the issue isn’t that the b=0 volumes are empty, then it might be related to a failure of the masking. Try running your dwifslpreproc command with the -nocleanup option, so you can inspect the contents of the temporary folder that script sets up and check all the intermediate images generated. You’ll find the command log in there as well, so you can check exactly what was run and at which point it all fell apart. Hopefully that’ll give you some insight into what’s going on.
On a separate note: if you’re merging data acquired from separate series, it’s probably better to use the dwicat command to do this rather than mrcat, since that should take care of any differences in intensity scaling, which can easily happen due to the scanner re-running various calibrations between scans.
dwifslpreproc: [ERROR] Unable to determine matching reversed phase-encode direction volume for DWI volume 0
This originates from:
By using -rpe_all, the code assumes that if the input DWI series is split in two right down the middle, the first half corresponds to the specified phase encoding direction, the second half to the opposite direction. But it doesn’t actually assume that the order of the diffusion sensitisation gradients is exactly equivalent between the two. It instead tries to figure out how to “pair up” volumes between the two halves based on the b-values and sensitisation directions being equivalent; but it throws an error if it’s unable to “pair up” all volumes (since then it wouldn’t be able to generate one volume for each diffusion sensitisation based on the input pair with opposing phase encoding directions). The fact that your data are clearly intended to satisfy this requirement, but the code reports that they do not, means that you need to look at your diffusion gradient table closely and try to figure out why the code thinks it’s anything other than the same 104 entries duplicated twice.
Next, I tried the -rpe_header option, and got a bit further:
This got further because the explicit volume recombination is a defining attribute of -rpe_all, but is not a prerequisite for use of -rpe_header. You would nevertheless find that if processing had completed, your output image would still have 208 volumes rather than the intended 104.
eddy::: ecscanmanager::mean_of_first_b0: zero mean
Can’t know for sure, but it’s possible that this is a consequence of the mask being empty, rather than the latter being a happenstance observation. If that is indeed the case you’d want to look into why dwi2mask is yielding an empty mask, and maybe consider using some other process to derive a brain mask and then provide that to dwifslpreproc using the -eddy_mask option.
Thanks for the really in-depth explanation! Really appreciate it. Yes, there are 208 volumes instead of 104 in the final output.
The fact that your data are clearly intended to satisfy this requirement, but the code reports that they do not, means that you need to look at your diffusion gradient table closely and try to figure out why the code thinks it’s anything other than the same 104 entries duplicated twice.>
Indeed, the bvals do not seem to be matching. The bvals of the AP and PA are shown in the top and bottom rows respectively. The b0 volumes do not have the same bvals in AP and PA. What would be the recommendation moving forward? I will ask our MRI team why this is happening too.
The magnitude of that difference in b-value should be inconsequential. In both cases, the first two volumes should be assigned to the same b-value shell via mrinfo -shell_indices.
Looking at the code, I think what’s happened is that in my latest batch of changes in this area of the script (GitHub), I’ve failed to disable the comparison between gradient vector directions between volumes when the b-value shell is classified as b=0 in all possible cases. So I think that this proposed change should fix it; if you’re able to access that code and give it a try it’d be much appreciated.
Apologies if this question has an obvious answer or doesn’t fit here question. I’m going to use -rpe_all in dwifslpreproc after using mrcat to produce a “merged” image from AP and PA DWI. Example code from tutorial:
Daan gave a good response to this question in another thread. The original question there does not cover the prospect of having an adequate number of DWIs in multiple phase encoding directions independently, but the point regarding EPI distortions making the spatial distribution of noise not quite equivalent between phase encoding directions holds here. Personally I’ve historically just concatenated everything together then denoised, but I trust Daan’s judgement here moreso than my own. It’s also a common source of uncertainty, so might be worth turning into a Wiki page.