I was wondering how is your experience with mrdegibbs in partial Fourier data.
In original paper https://www.ncbi.nlm.nih.gov/pubmed/26745823 they use partial Fourier 6/8 to demonstrate that degibbs in this type of acquisition produces spurious ringing after correction.
I have also 6/8 partial Fourier data (AP phase encoding direction) and actually mrdegibbs seems to me to work very well. The ringing is removed very well and I do not see any new spurious ringing in AP direction after correction. See mean diffusivity data after denoising, before mrdegibbs:
Actually, I do not know what they mean by new ringing after correction with partial Fourier data showed in fig. 6 in the original paper. I see in the figure some hypointensities around ventricles in the partial Fourier data, but they seem to be present also in their original data before correction. I see similar hypointensities around ventricles in my data (see cursor), but they are present also in the data before mrdegibbs, so it is no new ringing.
Before mrdegibbs:
Secondly, do you think that it is possible to implement mrdegibbs to perform unringing only in the direction with full k-space coverage (in my case LR)?
We had the exact same experience â and I also donât think there was any.evidence in the original paper of the method introducing artefacts that werenât already there. So I asked Elias Kellner about this a while back, and he also thinks itâs perfectly fine to use. Here are selected parts of his thoughts on the issue (I hope he doesnât mind me sharing them hereâŚ):
The unringer does not introduce or amplify additional artifacts. If there is âtrueâ ringing, it removes it; to the rest, only a slight smoothing is introduced (but it does never âoversmoothâ)
So in general, we fully support the statement that it is safe to apply it to any MR image as a black box.
But again, I think that additional smoothing in PF direction is not too strong (as you also observed), and for now, I would suggest to write in the help something like:
Note that this method is designed to work on images acquired with full k-space coverage. Running this method on partial Fourier (âhalf-scanâ) data will not fully remove the artifact, and you will observe residuals of the original artifact in the partial-fourier direction, but it is safe and worthwhile to apply it also in this case.
I guess itâs about time we updated the help text as suggestedâŚ
Secondly, do you think that it is possible to implement mrdegibbs to perform unringing only in the direction with full k-space coverage (in my case LR)?
If there were sufficient justification to do so, it would certainly be possible: core code for such functionality is already there within the command, it would only require altering the main executing function to permit 1D operation only when the input to the -axes option has one value only. But given itâs generally advocated to run in 2D mode regardless, it might be hard to justify putting the time into it.
Nothing beyond the guidelines for contributing, no. But the process is basically the same as described in these guidelines (see also GitHubâs help page on the process). The changes that need to be made to modify the docs for a specific command are essentially:
update the usage() section of the corresponding command .cpp file (in the cmd/ folder) â e.g. this section for mrdegibbs.
check it all builds as before and run any relevant tests for that command just to make sure, e.g.:
./build
./run_tests mrdegibbs
update the autogenerated online docs to match:
./docs/generate_user_docs.sh
commit your changes to the command cpp and the docs, e.g.:
git add cmd/mrdegibbs.cpp
git add docs/reference/commands/mrdegibbs.rst
git commit -m "mrdegibbs: update documentation for case of partial Fourier"
push and create your pull request as per the guidelines.
The only thing I would add for changes to the documentation specifically, is to open an issue on the main MRtrix3 repo detailing exactly the changes youâre thinking of making, so that we can discuss, amend, fix typos, etc. as necessary. This is because itâs actually quite difficult for us to make changes to your pull request, and every change we push triggers another round of automated testing (which takes at least 45 minutes) â this makes the whole process pretty painful. Much easier if all changes have been pre-approved via an issue, at which point the pull request ought to be accepted first time around.
Good point, Iâll make a note of that. Just to confirm, weâre only talking about a change to the help page, right? Weâre not planning any changes to the code as suchâŚ
