Just so you know, on the Venetian blinds, we have tried excluding the first volume of the reference images from the field map estimate, but found that this is not the source of the artifact that we brought to your attention initially.

sorry, I didn’t suggest it was. There are other reasons for not wanting to use the volumes with the venetian blinds. Inside topup there is a rigid body-movement model, in addition to the model for an off-resonance field. This is important in case the subject has moved a little between the two acquisitions with different PE-directions. Otherwise the movement induced difference would be interpreted as off-resonance distortions, and the estimated field would be wrong.

If the input contains venetian blind artefacts, that will make it harder to correctly detect any “out of plane” movement. Imagine if you want to register two zebras. Chances are you will align them along their stripes, rather than along the contour as you had intended.

Jesper

We will take your advice about the echo spacing parameter. Thanks.

Let me know if you need any additional data to try to debug this.

Thanks,

Bob

On Fri, Feb 17, 2017, 10:05 AM Jesper Andersson <[log in to unmask]uk> wrote:

Dear Aaron and Robert,

I have had a look at your data, and I see what you mean. The combined field/corrected_image output I get when I use your oblique acqparams.txt file is very strange. The corrected images look “almost right” and yet the estimated fields look like no field I have ever seen. This must be a bug in topup for oblique PE-directions that you have found. I’ll see if I can fix that.

Having said that, I think that the non-oblique acqparams is the right one to use. I assume that the reason to prescribe an oblique slice in-plane is because the subject isn’t straight in the scanner (i.e. he/she has the head rotated as if looking to the side a little). I also assume that what the scanner then does is to use bits of both the x- and the y-gradient for both the phase- and frequency-encode gradients (i.e. both the gradients are oblique). The reconstruction will still be a 2D ifft, i.e. go along the oblique phase- and frequency-encode directions. If the images are then stored like that it will have the effect to “straighten the subject up”, and the true PE-direction will be purely in the x-direction. If they had been rotated back and stored differently it would not have had the desired effect of “straightening the subject”.

Hence, I think that the

1 0 0 1.0

-1 0 0 1.0

is the one you want.

Just two more comments.

1. Be a little careful with using an obviously nonsense readout time (1.0) _if_ you want to use the estimated field as an input to eddy. My advice would be to always use 0.05 when one does not know the true value.

2. You have quite severe venetian blind effects in your first volume. It indicates to me that there is quite a lot of overlap between your slices (i.e. that your slice profiles have quite fat tails). You might want to look into tightening these up a little. If that is not an option you should only use the second (or an even later) volume as input to topup. I.e., don’t use the one with the venetian blind.

Jesper

On 16 Feb 2017, at 19:49, Robert Bussell <[log in to unmask]> wrote:

Hi Jesper,

That would be great if you took a look. I uploaded some files.

Thanks,

Bob

On Thu, Jan 26, 2017 at 10:54 AM, Jesper Andersson <[log in to unmask]uk> wrote:

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

https://oxfile.ox.ac.uk/oxfile/work/extBox?id=72139C7E463068D5F

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!

--

Robert Bussell

Senior Development Engineer
UCSD Center for Functional Magnetic Resonance Imaging

9500 Gilman Drive

La Jolla CA 92093

858 822-0519

[log in to unmask]

[log in to unmask]