Running a full MRTRIX processing pipeline from AP and PA DICOMS

Hi All,

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.

The next steps:

mrcat *AP* *PA* all_DWI.mif -axis 3
dwidenoise ${raw_dwi} ${denoised_dwi}
mrdegibbs ${denoised_dwi} ${denoised_degibbs_dwi}

I ran into a few roadblocks during the dwifslpreproc stage.

dwifslpreproc ${denoised_degibbs_dwi} ${denoised_degibbs_preproc_dwi} -rpe_all -pe_dir ap -eddyqc_all eddyqc -eddy_options '  --repol --data_is_shelled --slm=linear'
dwifslpreproc: [ERROR] Unable to determine matching reversed phase-encode direction volume for DWI volume 0

I thought that was strange since all the information should have been contained in the MIF. Next, I tried the -rpe_header option, and got a bit further:

dwifslpreproc ${denoised_degibbs_dwi} ${denoised_degibbs_preproc_dwi} -rpe_header -eddyqc_all eddyqc -eddy_options '  --repol --data_is_shelled --slm=linear
mrtrix eddy::: ecscanmanager::mean_of_first_b0: zero mean

The brain mask was empty too. Is there something obvious that I might be missing?

I have pasted the MRINFO here:

Thanks very much,

Hello!

Will anyone be able to provide some clues as to what might be happening? I hope I am not doing missing something super obvious.

Thanks in advance.

I’m not sure what’s going on, but given eddy’s error message:

eddy::: ecscanmanager::mean_of_first_b0: zero mean

The first thing to do is to verify whether this is true, e.g.

dwiextract ${denoised_degibbs_dwi} -bzero - | mrstats - 

or

dwiextract ${denoised_degibbs_dwi} -bzero - | mrview -

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.

4.18194	4.18194	296.589	297.181	298.411	300.675	300.547	305.016	305.8	303.914	4.18194	999.15	996.766	997.551	1007.14	994.238	990.417	1001.58	990.431	997.84	1009.82	999.05	991.112	1008.63	991.602	1010.52	4.18194	1006.86	993.048	992.832	997.483	1006.94	995.941	1003.94	997.776	1001.84	992.416	1003.56	1006.22	1001.38	1007.43	994.888	4.18194	2000.02	2004.06	1985.62	1985.82	2005.32	2012.45	2003.78	2011.81	1993.24	1996	2008.35	1988.33	1994.43	2014.29	2007.43	2012.48	1996.6	2001.65	1986.26	1994.51	1991.7	2006.54	1993.93	2005.41	2006.49	2001.6	1998.7	1992.14	1990.15	1993.82	4.18194	2011.78	2012.01	2009.02	1989.37	2005.37	1990.66	2014.05	1999.18	2002.17	1994.42	2001.78	2002.11	2009.05	1988.97	1999.69	2011.5	1993.2	1989.18	2000.9	1987.55	1990.88	2015.29	1986.66	2003.05	2011.66	2001.67	1995.88	1997.37	2008.43	2009.65
4.56155	4.56155	296.589	297.181	298.411	300.675	300.547	305.016	305.8	303.914	4.56155	999.15	996.766	997.551	1007.14	994.238	990.417	1001.58	990.431	997.84	1009.82	999.05	991.112	1008.63	991.602	1010.52	4.56155	1006.86	993.048	992.832	997.483	1006.94	995.941	1003.94	997.776	1001.84	992.416	1003.56	1006.22	1001.38	1007.43	994.888	4.56155	2000.02	2004.06	1985.62	1985.82	2005.32	2012.45	2003.78	2011.81	1993.24	1996	2008.35	1988.33	1994.43	2014.29	2007.43	2012.48	1996.6	2001.65	1986.26	1994.51	1991.7	2006.54	1993.93	2005.41	2006.49	2001.6	1998.7	1992.14	1990.15	1993.82	4.56155	2011.78	2012.01	2009.02	1989.37	2005.37	1990.66	2014.05	1999.18	2002.17	1994.42	2001.78	2002.11	2009.05	1988.97	1999.69	2011.5	1993.2	1989.18	2000.9	1987.55	1990.88	2015.29	1986.66	2003.05	2011.66	2001.67	1995.88	1997.37	2008.43	2009.65

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.

Thanks
Rob

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:

$ mrcat 002_-DWI_64dir_phaseLR/ 003-_DWI_64dir_phaseRL/ all_DWIs.mif -axis 3

$ dwipreproc all_DWIs.mif dwi_preprocessed.mif -pe_dir LR -rpe_all [ -readout_time 0.1 ]

Should I denoise each scan (AP and PA) separately before feeding them into this or should I run the mrcat command and then denoise? What (if any) differences would I see between these two strategies?

Thanks!
Mags

Hi Mags,

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.

Cheers
Rob