Dear Aaron,
you are the second person reporting this. I assume you have looked at the reply that Mike Harms guided you too?
I am surprised by what you describe as a “zipper artefact”. If it is ok with you I would love to have a look at the data to see if I can understand what is going on. If your ok with that, can you please upload the --imain data to
together with the two different acqparams.txt files?
Best regards Jesper
On 25 Jan 2017, at 16:55, Aaron Jacobson <[log in to unmask]> wrote:
Recently I ran into some issues using fsl topup on several oblique EPI datasets. The topup corrected output had what looked like a zipper artifact throughout many of the slices. I found that if I used 3dWarp -deoblique prior to running the topup correction the artifact disappeared (most of the time) but I was not confident that this method did not affect my dataset in other ways. I found that if I used the REL image orientation info from the dicom header (a measure of obliquity in the dataset) in the my_acquisition_parameters file that is fed into the topup commands, the corrected data look great.
Example from dicom header:
REL Image Orientation (Patient)//1\-0\0\-0\0.975766\-0.21881
Example of my_acquisition_parameters file:
0.21881 -0.975766 0 1
0.21881 -0.975766 0 1
-0.21881 0.975766 0 1
-0.21881 0.975766 0 1
Is it appropriate (or necessary) to use measures of obliquity from the dicom header as input for the x and y columns in the my_acquisition_parameters file? Should topup be able to handle oblique datasets without setting the parameters in this way?
Any advice you can offer would be greatly appreciated.
Thanks!