# Processing of volumes prior to dwipreproc
**URL:** https://community.mrtrix.org/t/processing-of-volumes-prior-to-dwipreproc/2112
**Category:** Uncategorized
**Tags:** preprocessing
**Created:** [December 7, 2018, 6:04am UTC](https://community.mrtrix.org/t/processing-of-volumes-prior-to-dwipreproc/2112 "2018-12-07T06:04:09Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@archithrajan1](https://community.mrtrix.org/u/archithrajan1)
#### Post date: [December 7, 2018, 6:04am UTC](https://community.mrtrix.org/t/processing-of-volumes-prior-to-dwipreproc/2112/1 "2018-12-07T06:04:09Z")
Hi,
Thank you very much for the tutorial. I had a single doubt regarding the AP and PA volumes for dwipreproc. Since the AP images extracted from the DWIs have already undergone a series of preprocessing steps(dwidenoise and mrdegibbs namely), should the PA images go through the same steps as well before they are concatenated for use with dwipreproc?
Regards,
Archith
---
### Author:  [@rsmith](https://community.mrtrix.org/u/rsmith)
#### Post date: [December 9, 2018, 6:30am UTC](https://community.mrtrix.org/t/processing-of-volumes-prior-to-dwipreproc/2112/2 "2018-12-09T06:30:47Z")
_(Moved to new topic since question is not specific to the title of the thread in which it was posted)_
If they are being used together, then ideally yes. Gibbs ringing removal is easy; the hard part is denoising, which you cannot perform on one or a small number of _b_=0 volumes in isolation:
- If you are explicitly yourself combining copies of one or more of the AP _b_=0 volumes from the DWIs with one or more PA _b_=0 volumes, then you can omit the denoising step from processing of just that set of volumes.
- Personally I expect the spatial distribution of noise level to be more-or-less equivalent across image volumes regardless of phase encoding direction, and therefore concatenate all volumes in order to perform denoising and then separate the volumes out into “DWIs to be corrected” and “spin-echo EPIs to be used to estimate the inhomogeneity field”. However if you have a scanner that may grossly adjust image intensities in between protocols, this may be problematic.
Realistically though, I’m not sure exactly what type of ‘bias’ may be introduced by having a greater level of noise in volumes with one phase encoding direction than those with the opposing direction…
---
### Author:  [@archithrajan1](https://community.mrtrix.org/u/archithrajan1)
#### Post date: [December 10, 2018, 5:39am UTC](https://community.mrtrix.org/t/processing-of-volumes-prior-to-dwipreproc/2112/3 "2018-12-10T05:39:19Z")
Thanks for the clarification. I would like to carry on with the two approaches
1.
> [@rsmith](#):
>
> explicitly yourself combining copies of one or more of the AP _b_ =0 volumes from the DWIs with one or more PA _b_ =0 volumes
Explicitly combine AP and PA b0s after mrdegibbs on each ; Pass them to the dwipreproc step with input as the mrdegibbs and dwidenoised data and the undenoised AP-PA concatenated data as the -rpe\_pair -se\_epi option
1.
> [@rsmith](#):
>
> concatenate all volumes in order to perform denoising and then separate the volumes out into “DWIs to be corrected” and “spin-echo EPIs to be used to estimate the inhomogeneity field”
After checking the mean intensities of AP and PA b0 volumes.
> [@rsmith](#):
>
> what type of ‘bias’ may be introduced by having a greater level of noise in volumes with one phase encoding direction than those with the opposing direction
Would any differences between 1 and 2 hint something about this? What would you suggest?
Thanks and Regards,
Archith
---
### Author:  [@rsmith](https://community.mrtrix.org/u/rsmith)
#### Post date: [December 16, 2018, 10:43am UTC](https://community.mrtrix.org/t/processing-of-volumes-prior-to-dwipreproc/2112/4 "2018-12-16T10:43:38Z")
> … as the mrdegibbs and dwidenoised data …
Just confirming that `dwidenoise` _cannot_ be applied _after_ `mrdegibbs` (or basically any other process).
> After checking the mean intensities of AP and PA b0 volumes.
I believe that `topup` estimates a global scaling factor between image volumes. Don’t quote me on this though.
> Would any differences between 1 and 2 hint something about this?
No, the difference between 1 and 2 would be due to estimating the inhomogeneity field from denoised or not-denoised data. What I was referring to specifically in that comment was what might happen if the AP volume(s) is/are denoised but the AP volume(s) is/are not. It would certainly have _an_ effect, I’m just not sure if there would be a ‘bias’ strictly.
---
### Author:  [@archithrajan1](https://community.mrtrix.org/u/archithrajan1)
#### Post date: [December 18, 2018, 12:08pm UTC](https://community.mrtrix.org/t/processing-of-volumes-prior-to-dwipreproc/2112/5 "2018-12-18T12:08:49Z")
Thank you very much for the clarification.I’m sorry I messed up with the order of denoise and mrdegibbs earlier… meant the other way round.
Regards,
Archith
---
### Author:  [@mkv](https://community.mrtrix.org/u/mkv)
#### Post date: [June 15, 2020, 11:19pm UTC](https://community.mrtrix.org/t/processing-of-volumes-prior-to-dwipreproc/2112/6 "2020-06-15T23:19:15Z")
I’m following the steps in the [FSL page](https://fsl.fmrib.ox.ac.uk/fslcourse/lectures/practicals/fdt1/index.html#pipeline), and manually merged one PA and one AP b0 image (`AP_PA_b0.nii.gz`). So I have two b0 volumes in the `AP_PA_b0` file.
Could you please clarify what you meant with
> omit the denoising step from processing of just that set of volumes
What set of volumes are you referring to here?
Currently I’m running `dwdenoise` and `mrdegibbs` on the dwi dataset, but not on the opposite PE-direction image. Afterwards I merge the two b0 images (`AP_PA_b0.nii.gz`) and use that in the topup command. Are you suggesting I should skip `dwidenoise` entirely, or just not apply it to the `AP_PA_b0` image?
---
### Author:  [@rsmith](https://community.mrtrix.org/u/rsmith)
#### Post date: [June 28, 2020, 1:44am UTC](https://community.mrtrix.org/t/processing-of-volumes-prior-to-dwipreproc/2112/7 "2020-06-28T01:44:13Z")
> > omit the denoising step from processing of just that set of volumes
> What set of volumes are you referring to here?
This is in reference to whatever set of images are to be provided to FSL `topup` via the `-se_epi` option. But the wording is maybe clumsy; that’s me trying to avoid writing an essay in every thread :-/
Let’s suppose the situation is (as it sounds applies to your case), that you have:
1. Phase encoding AP: 1 _b_=0, 60 _b_=3000 volumes;
2. Phase encoding PA: 1 _b_=0.
, and the tools you have at your disposal are:
- `dwidenoise`;
- `mrdegibbs`;
- `dwifslpreproc`;
- All other _MRtrix3_ utilities.
The question is: What data do you provide to each command, and in what order?
1. If you run all the phase encoding AP data through `dwidenoise` and `mrdegibbs`, then extract the solitary _b_=0 volume and concatenate it with the PA _b_=0 volume, then you have a situation where `topup` is estimating an inhomogeneity field where one volume has a different noise level than the other, and one has had Gibbs ringing removed whereas the other has not. This may cause issues, it may not.
(You could also run the PA _b_=0 image through `mrdegibbs` here)
2. If you concatenate the PA _b_=0 image with the AP volumes, then run the whole lot through `dwidenoise | mrdebiggs`, you have the advantage that the same processing has been applied to both volumes that `topup` will be utilising; the disadvantage is that noise level estimation may not be quite right for the PA volume if spatial distortions are large, and AFAIK nobody has pursued quantifying just how deleterious this may be.
3. Extract the AP _b_=0 image _as the first step_, concatenate it with the PA _b_=0 image, and call it _X_; you then feed all AP data through `dwidenoise | mrdegibbs`, that forms the input image to `dwifslpreproc`; you could then feed _X_ through `mrdegibbs` if you wished, but you can’t run `dwidenoise` on it as there are too few volumes, that’s then provided via the `-se_epi` option to `dwifslpreproc`. The input volumes to `topup` have now had identical processing applied to them, so there’s no known bias to speak of; but the level of noise in those images is higher than it may otherwise be.
I would say there is not currently a consensus on which of these options is preferable. Personally I’m moving away from acquisitions like this so it’s less of a concern… But for retrospective data the question has been raised a few times and I don’t think any evidence was presented for one approach over the others.
Rob
---
### Author:  [@archithrajan1](https://community.mrtrix.org/u/archithrajan1)
#### Post date: [June 30, 2020, 5:00am UTC](https://community.mrtrix.org/t/processing-of-volumes-prior-to-dwipreproc/2112/8 "2020-06-30T05:00:49Z")
Dear Dr.Smith,
> [@rsmith](#):
>
> Personally I’m moving away from acquisitions like this
I would like to know what other acquisition strategies are available that can well mitigate susceptibility distortions. Kindly request to elaborate.
Regards,
Archith
---
### Author:  [@rsmith](https://community.mrtrix.org/u/rsmith)
#### Post date: [July 14, 2020, 6:12am UTC](https://community.mrtrix.org/t/processing-of-volumes-prior-to-dwipreproc/2112/9 "2020-07-14T06:12:45Z")
> I would like to know what other acquisition strategies are available that can well mitigate susceptibility distortions. Kindly request to elaborate.
Rather than acquiring all DWIs with one phase encoding direction and then one or a small number of _b_=0 images with the reversed phase encoding direction, what I’ve been doing is splitting the gradient table in half, acquiring the first half with one phase encoding direction and the other half with the reversed phase encoding direction. You can extract the _b_=0 images from each series for susceptibility field estimation (`dwifslpreproc` can do this automatically). It means that in regions of the brain where the susceptibility distortions lead to the signal being compressed, and therefore you can’t recover the spatial contrast when you spread that signal back out over the source area, you at least have the other half of the DWIs that are instead expanded by the susceptibility distortions in that area, and so you have some chance of recovering some spatial contrast in the corrected images. At some point I’ll hopefully do a tailored reconstruction in `dwifslpreproc` for this style of acquisition.
Acquiring the entire gradient table in two phase encoding directions is already supported (see `dwifslpreproc -rpe_all`), but that requires a doubling of the acquisition time. The style above tries to get the benefits of this style of acquisition but without the increase in scan time.
---
### Author:  [@archithrajan1](https://community.mrtrix.org/u/archithrajan1)
#### Post date: [July 16, 2020, 8:59am UTC](https://community.mrtrix.org/t/processing-of-volumes-prior-to-dwipreproc/2112/10 "2020-07-16T08:59:04Z")
Dr.Smith,
Thank you very much for the detailed description.
Regards,
---
### Author:  [@mkv](https://community.mrtrix.org/u/mkv)
#### Post date: [March 9, 2021, 1:45am UTC](https://community.mrtrix.org/t/processing-of-volumes-prior-to-dwipreproc/2112/11 "2021-03-09T01:45:38Z")
Thank you @rsmith, that was really very helpful!
Regarding step 3, can I leave the AP b=0 in the dataset when I feed all AP data through `dwidenoise | mrdegibbs`? Or will that cause problems?
Also, you wrote
> you could then feed X through mrdegibbs if you wished, but you can’t run dwidenoise on it as there are too few volumes, that’s then provided via the -se\_epi option to dwifslpreproc
Is `X` the image that is usually fed to `--imain` parameter in FSL’s `topup` command (ie `topup --imain=X`)?
---
### Author:  [@rsmith](https://community.mrtrix.org/u/rsmith)
#### Post date: [March 16, 2021, 5:56am UTC](https://community.mrtrix.org/t/processing-of-volumes-prior-to-dwipreproc/2112/12 "2021-03-16T05:56:57Z")
Hi @mkv,
The denoising algorithm is not directly dependent on the _b_-values of individual volumes; the only assumption is that the _noise level_ is the same across volumes (and in a local spatial neighbourhood). So the algorithm itself can utilise the _b_=0 data, and will perform some denoising of those data. In terms of whether or not that will “cause problems”, the only _potential_ issue is that if those data are fed to `topup`, then the _b_=0 volume(s) with one phase encoding direction will have better SNR than the volume(s) with the opposite phase encoding direction if no denoising was applied to the latter. But I’m not convinced that this is actually “problematic” in any way. Until someone actually experiments with these different options, it’s merely an observation of fact. And as shown in my prior reply, there is not an alternative strategy that is wholly devoid of caveat / disadvantage.
> Is `X` the image that is usually fed to `--imain` parameter in FSL’s `topup` command (ie `topup --imain=X` )?
Correct:
> … that’s then provided via the `-se_epi` option to `dwifslpreproc`.
Admittedly not the ideal sentence structure back there… but yes, the purpose of the `-se_epi` option is to provide images to `topup` for inhomogeneity field estimation, but that will _not_ be provided to `eddy` and hence will not be included in the `dwifslpreproc` output.