?Bug in warpinit

1

Dear @jdtournier

There is a possible bug in the warpinit command (I don’t think it causes major problems … but it might)

In the message thread below, you state (see highlighted):

I’ve spent quite a bit of time making sure this issue with mismatched strides / transform in NIfTI images doesn’t happen - at least not routinely: NIfTI images produced by MRtrix3 should match the strides / transform of the input image, which should avoid these types of problems.

warpinit does not conform to this behaviour:

I ran this command:

warpinit OrigT1wImage.nii.gz no-warp-test.nii.gz

Note below that the strides for the original image are: [ -1 2 3 ]
While for the ‘no-warp’ image, they are: [ 1 2 3 4 ]

image

image

I have tested using this image for the to warp tracts to MNI space using fsl’s applywarp command:

warpinit OrigT1wImage.nii.gz no-warp-test.nii.gz
applywarp -i no-warp-test.nii.gz -r Native_T1w -w standard2acpc_dc.nii.gz -o warp.nii.gz
tcknormalise native_tract.tck warp.mif mni_tract.tck

It seems to work with no problems and the registration of the tracts to the MNI brain look very good:

image
image1726×1006 223 KB

However, since you mention (in the above post) that:

The only times you’ll need to worry about this is when interacting with other packages that may not handle these issues too well - or at least, handle them differently. One example is displaying an overlay on an image within FSLView

I thought I would bring up this issue.

Furthermore, I would like to also point to a thread on the FSL forum and a post by Mark Jenkinson that may answer some questions / explain why this was not actually causing a problem (though I suspect it will if someone simply loads the matrices into matlab or python and does not use real world coordinates):
image

source: JISCMail - FSL Archives

Interested to hear your thoughts on this matter.
Claude

2

Indeed. The input image in this case is only used as a template to get the voxel size and dimensions, and the strides are currently explicitly reset. As you saw, this doesn’t seem to have any adverse effect, but you’re right that it probably should be consistent. It’s a tiny fix, I’ll push that the repo in a minute, and it might be included in the next release (which shouldn’t be too far away now… ).

1 Like
3

Well, this is a fairly old post now, so this is not new behaviour. What are you referring to specifically?

4

Yes the post is very old, I agree. I suppose I just wanted to hear your comments since what you said in the above post seems to contradict what Mark is saying (at least when the different strides simply change the x orientation):

One example is displaying an overlay on an image within FSLView - if the strides differ between the images, the overlay will generally be all wrong (at least it was the last time the issue was raised…), whereas it would be just fine in MRView.

Once again the posts are old and thing most likely have changed but image orientation and flips are constant problems that keep popping up.

5

Ah, OK. I don’t think Mark’s post addresses the display issue specifically. This seems to address the issue of “neurological” versus “radiological”, which most likely refers to the handling of the NIfTI qfac entry (which turns a RHS coordinate system into a LHS coordinate system when the transformation information is provided via the qform) – at least that’s what Mark has meant by these terms in previous dealings with him. This is particularly relevant when handling orientation information (bvecs, vector maps, etc). I’m probably getting a touch too technical here, but basically I don’t interpret that as meaning that everything is therefore all entirely self-consistent, certainly with regards fslview.

Also, there’s a difference between ‘work correctly’ and ‘display identically’. The way fslview has handled these things in the past is by loading the images ignoring the strides (or rather, the NIfTI transform information), but using the correct orientation labels on the axes. So it’s correct as displayed for the main image, but I don’t think this necessarily means that overlays will be displayed appropriately – no idea whether this has been improved recently, maybe within fsleyes…? Maybe others will be able to comment on that – I don’t seem to be able to install the latest version of FSL on my Arch Linux system…

6

Thanks for this. I am just posting some tests as a follow-up. It seems to me that fslview (4.0.1) tries to display everything in radiological convention

The first image is of the first volume of no-warp-test.nii.gz (header and image below)
image

image
image.png960×1056 55.2 KB

Note that:

  1. the header shows strides = [ 1 2 3 4 ]
  2. the image is displayed in radiological convention (left on the right hand side of the viewer)

The next image is the first volume of no-warp-test-stride.nii.gz. This image has simply been produced by running this command:
mrconvert no-warp-test.nii.gz -stride -1,2,3,4 no-warp-test-stride.nii.gz

The header and image are below:

image

image
image.png960×1056 55.4 KB

Note that:

  1. the header shows strides = [ -1 2 3 4 ]
  2. the image is displayed in radiological convention (left on the right hand side of the viewer)
  3. the image is displayed identically to the image above despite having different strides.

Also, if I overlay the two images, they are overlaid correctly i.e. they are still identical images.

In summary, I suspect that fslview does use some of the information in the sform / qform, however, I suspect that it can only deal with left - right information / radiological - neurological and probably would not deal with any rotations… but I have not tested this.

In any case, I thought that readers of this post would be interested to know the above.

7

Interesting! I’d like to know whether this also holds true for rotated images (different strides), that would be a welcome development.