Our data is as follows: single-shot EPI at 3T, high resolution imaging (1 x 1 x 1 mm3) of the human hippocampus, a slab of twenty 1 mm slices oriented along the long axis of the hippocampus, and low b value of 500 s/mm2 to overcome the low SNR of a 1 x 1 x 1 mm3 acquisition.
Our problem is as follows: there are no issues with dwidenoise or dwibiascorrect, however, dwipreproc with ‘-rpe_none -pe_dir AP’ options will cut off portions of the first (1&2) and last (19&20) couple of slices in the slab. Not only are these slices incomplete (anywhere from 10-100% is missing), but they also appear to have much more remaining noise and distortion relative to the slices in the middle.
I imagine that it may be some kind of registration error caused by an expectation of whole-brain data input.
I am curious if there are any avenues to deal with this problem.
Thank you,
Kevin
PhD Student
University of Alberta
dwidenoise will not perform denoising of the bottom two and top two slices. This will contribute to your observation of increased noise there. This is something that we can hopefully overcome in the future.
When correcting for geometric distortions in a command like eddy, the goal of the command is to determine, for each voxel in the output image, the location in the input image from which the image intensity should be sampled. However it is pretty much unavoidable that for some voxels near the edges of the image, due to the correction of said geometric distortions, the location in the input image from which the intensity must be sampled lies outside the image FoV. When this occurs, it is impossible to fill the output image with sensible data, and so you get a masking effect.
This effect can be enhanced in the context of eddy, because it is dealing with a large number of volumes. Consider for example a case where there is substantial motion between individual DWI volumes. Each volume will have a certain subset of the output image FoV that cannot be filled with data from the input image; this subset will also vary between volumes. What eddy ends up doing is only filling in image data in output image voxels for which image data can be properly accessed from the input image for all volumes. This can result in an accentuation of the masking effect. Data with a very small number of slices would be one such circumstance, since it’s a larger fraction of the total image volume that resides within a couple of voxels from the image FoV edge compared to a whole-brain image.
This effect is intrinsic to eddy, which is an FSL command, and is simply reflected in the output of dwipreproc. So while it’s theoretically possible that this effect could be reduced (by engaging eddy's outlier replacement in voxels where the fraction of volumes where input image data cannot be accessed is small), it’s not something that is within the control of MRtrix3 developers.
Thank you for the comprehensive explanations regarding the two effects that I am observing in my data.
I am trying the eddy’s replacement outlier option, --repol, but without much luck.
My command line is as follows, and I have tried putting the options in different positions (and with both the space following the option or the equal sign preceding, as directed in a prior post) all with the same error that reads out after the eddy command. My input:
dwipreproc dwi_in.mif dwi_prepro_out.mif -rpe_none -pe_dir AP -eddy_options="--repol"
The error:
Command: eddy --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --repol --out=dwi_post_eddy
Traceback (most recent call last):
File "/home/KGS/mrtrix3/bin/dwipreproc", line 518, in <module>
run.command(eddy_cmd + ' --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals' + eddy_in_topup_option + eddy_manual_options + ' --out=dwi_post_eddy')
File "/home/KGS/mrtrix3/lib/mrtrix3/run.py", line 183, in command
stderr_text = tempfiles[index][1].read().decode('utf-8')
File "/usr/lib/python2.7/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xa0 in position 80: invalid start byte
So it is successfully reading the eddy option in to the eddy command line, but seems to crash after that. I am still relatively new to this type of software and am unsure how to approach this error.
While I think it’s technically possible that eddy's outlier replacement technique could be used to prevent the aggressive masking of output images based on input volume motion, this isn’t something that eddy is currently capable of (I was trying to send a subtle hint through the grapevine to Jesper over at Oxford ).
Nevertheless, on your new reported issue: Do you happen to be located in a region that uses non-breaking spaces when displaying numbers over 1000? If eddy honours locale settings when generating text data to display on the terminal, this could trigger such an issue. What you could try is changing the problematic line (lib/mrtrix3/run.py:183):
).