Dear Robert,
>
> My question is about using fsltopup with oblique reference volumes. I don't see the oblique case covered in the topup users guide explicity, so I cannot find an answer there. On a practical level, it boils down to which coordinate system the --datain input should be expressed in.
>
> For non-oblique images, the topup tutorial specifies a --datain input file of this form:
>
> 0 1 0 x
> 0 -1 0 x
>
> Now, if I tilt this image by a small angle, defined by the vector (0.2188, -.975766) written in scanner coordinates, would I then give the following input to --datain?
>
> 0.2188 -.975766 0 1.0
> -0.2188 .975766 0 1.0
it depends. If you prescribe slices that are slightly tilted in the xy-plane (though I must admit I have never come across this case), then I would assume that you would still acquire a k-space where the phase-encode is one of the principal directions and the frequency encode is the other. After reconstruction these images would come out as “a little tilted” compared to how the object was oriented along the scanner coordinate frame. Then the images would still have one of the axes as the PE-direction and I would think that the first option would be correct.
But, if the scanner performs a rotation of the images back into the coordinate frame of the scanner as part of the reconstruction, then the PE-direction would not coincide with one of the principal aces of the image and the second option would be correct.
I have tested a little with angled acquisitions when doing some tests with propeller data, and that has worked.
>
> We observed that the first way (0, 1) produces a high spatial frequency (zipper like) artifact in the field map, while the second way does not. So, it looks "better," but is it correct?
I am surprised that you see an artefact like that. I would have thought that the field would just be “a bit wrong” if your true PE-direction didn’t coincide with what you tell topup.
I hope this helped a bit.
Jesper
>
> Thanks,
>
> Bob
|