# Running a full MRTRIX processing pipeline from AP and PA DICOMS **URL:** \ **Category:** Uncategorized\ **Created:** [November 27, 2020, 12:33pm UTC](https://community.mrtrix.org/t/running-a-full-mrtrix-processing-pipeline-from-ap-and-pa-dicoms/4327 "2020-11-27T12:33:29Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Elijah](https://community.mrtrix.org/user_avatar/community.mrtrix.org/elijah/32/3081_2.png) [@Elijah](https://community.mrtrix.org/u/Elijah)\ **Post date:** [November 27, 2020, 12:33pm UTC](https://community.mrtrix.org/t/running-a-full-mrtrix-processing-pipeline-from-ap-and-pa-dicoms/4327/1 "2020-11-27T12:33:29Z")
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: ```auto 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. ```auto 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: ```auto 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: ![mrinfo](https://community.mrtrix.org/uploads/default/original/2X/b/bdd2441ef418bca37c02e517e209aa2423ec1037.png) Thanks very much, ---
**Author:** ![Elijah](https://community.mrtrix.org/user_avatar/community.mrtrix.org/elijah/32/3081_2.png) [@Elijah](https://community.mrtrix.org/u/Elijah)\ **Post date:** [December 4, 2020, 8:47am UTC](https://community.mrtrix.org/t/running-a-full-mrtrix-processing-pipeline-from-ap-and-pa-dicoms/4327/2 "2020-12-04T08:47:16Z")
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. ---
**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\ **Post date:** [December 4, 2020, 9:19am UTC](https://community.mrtrix.org/t/running-a-full-mrtrix-processing-pipeline-from-ap-and-pa-dicoms/4327/3 "2020-12-04T09:19:12Z")
I’m not sure what’s going on, but given eddy’s error message: ```auto eddy::: ecscanmanager::mean_of_first_b0: zero mean ``` The first thing to do is to verify whether this is true, e.g. ```auto dwiextract ${denoised_degibbs_dwi} -bzero - | mrstats - ``` or ```auto 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. ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [December 10, 2020, 12:36pm UTC](https://community.mrtrix.org/t/running-a-full-mrtrix-processing-pipeline-from-ap-and-pa-dicoms/4327/4 "2020-12-10T12:36:02Z")
> `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. ---
**Author:** ![Elijah](https://community.mrtrix.org/user_avatar/community.mrtrix.org/elijah/32/3081_2.png) [@Elijah](https://community.mrtrix.org/u/Elijah)\ **Post date:** [December 10, 2020, 12:57pm UTC](https://community.mrtrix.org/t/running-a-full-mrtrix-processing-pipeline-from-ap-and-pa-dicoms/4327/5 "2020-12-10T12:57:44Z")
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. ```auto 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 ``` ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [January 20, 2021, 1:02am UTC](https://community.mrtrix.org/t/running-a-full-mrtrix-processing-pipeline-from-ap-and-pa-dicoms/4327/6 "2021-01-20T01:02:06Z")
> [@Elijah](#): > > The b0 volumes do not have the same bvals in AP and PA. 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`](https://github.com/MRtrix3/mrtrix3/blob/3.0.2/bin/dwifslpreproc#L321). Looking at the code, I _think_ what’s happened is that in my latest batch of changes in this area of the script ([GitHub](https://github.com/MRtrix3/mrtrix3/pull/1887)), 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](https://github.com/MRtrix3/mrtrix3/pull/2262/files) should fix it; if you’re able to access that code and give it a try it’d be much appreciated. Thanks Rob ---
**Author:** ![mlm144](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/m/b782af/32.png) [@mlm144](https://community.mrtrix.org/u/mlm144)\ **Post date:** [February 21, 2022, 7:10pm UTC](https://community.mrtrix.org/t/running-a-full-mrtrix-processing-pipeline-from-ap-and-pa-dicoms/4327/7 "2022-02-21T19:10:54Z")
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 ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [February 21, 2022, 11:45pm UTC](https://community.mrtrix.org/t/running-a-full-mrtrix-processing-pipeline-from-ap-and-pa-dicoms/4327/8 "2022-02-21T23:45:00Z")
Hi Mags, Daan gave [a good response to this question in another thread](https://community.mrtrix.org/t/preferred-dwi-denoising-pipeline/5556/2). 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 ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [November 18, 2025, 1:34am UTC](https://community.mrtrix.org/t/running-a-full-mrtrix-processing-pipeline-from-ap-and-pa-dicoms/4327/9 "2025-11-18T01:34:49Z")
A post was split to a new topic: [Zero-filled volumes after applytopup within dwifslpreproc](https://community.mrtrix.org/t/zero-filled-volumes-after-applytopup-within-dwifslpreproc/8612)