mrview and fslview vector compatibility

[neurolabusc]

I can create vectors with MRtrix

  dwi2tensor -mask mask.nii -fslgrad dwi.bvec dwi.bval dwi.nii dti.nii
  tensor2metric -vector dti_v1.nii dti.nii

and FSL

  dtifit --data=dwi.nii --out=fsl_dti --mask=mask.nii --bvecs=dwi.bvec --bvals=dwi.bval

and view the results with either FSLview or mrview. However, each viewer sees the other's output as reversed in the Y-dimension. This makes QA difficult, as one can not use one viewer for all outputs. Are we past the point of no return for a unified vector format, is this a peculiar attribute of my data? In theory, one could detect the format by reading the NIfTI header descrip field for MRtrix (MRtrix version: ad5154e3) or FSL (5.0.10). But every tool will need to know this.

[neurolabusc]

I did some research and this is a replication of this issue. Like that post, fsleyes initially shows the mrtrix vectors wrong, but it can be corrected if I check the "L/R orientation flip" checkbox. As in that post, changing strides does not fix things. Would be great if there was a uniform format.

[jdtournier]

Yes, I was going to mention this forum thread. As mentioned, MRtrix stores the vectors in world coordinates, as it does just about everything of that nature (tensors, fODFs, streamlines, fixels, ...). It's been that way since ~2006, it's very deeply ingrained in the design and backend, I don't see that changing any time soon...

In terms of correcting for this in the display, it's actually probably worse than just a matter of clicking the L/R switch. I'm guessing FSL will store the vectors relative to the image axes (same as the bvecs), so for strongly oblique scans, world and image coordinates still won't match no matter what you do with the L/R switch...

However, I do agree that this isn't great for interoperability. I'm not sure there's a way around this... Maybe the BIDS standard stipulates a common format for this?

[thijsdhollander]

Just quickly checked (here's the latest BIDS specification: http://bids.neuroimaging.io/bids_spec1.0.2.pdf), and it doesn't look like they defined anything for such data yet. The only "orientational" definition in there is about the bvecs and bvals, where they seem to adopt the FSL way of things (that would be relative to image space then).

This broader discussion is really about how to deal with data/models in a voxel itself, and if they have a relationship to the surrounding space in some way (be it orientation for vectors, tensors, etc... or even position for warps or things that otherwise point to coordinates). We're indeed very consistently working in world coordinates, which I personally heavily support as well. It really makes dealing with data across acquisitions, resolutions, slice angulations, etc... much more clean. There's only 1 world coordinate system (so that's pretty well defined) rather than dealing with many different image spaces, each with their own coordinate systems.

Maybe we should even provide this as feedback to the BIDS people, so they think this through as well before adopting any existing "standard"... Many people only realise this is not that trivial when they start interacting with different packages, and are confronted with the issues and challenges.

[neurolabusc]

I think this is should be defined for NIfTI, not BIDS. In particular, vector images should specify intent_code of 1007 - NIFTI_INTENT_VECTOR. The current documentation is vague regarding the spatial coding (see below). This could be made explicit, and in theory one could have different intent_codes - one for vectors specified in image space and another for world space. This simple change would allow both mrtrix and fsl to use their current format and provide an easy method for detection. That way a viewer could either correct for a foreign intent type or at least warn the user that it is an incompatible vector format. @pauldmccarthy or @afni-rickr may have thoughts on this. I agree, it is not trivial. I do think MRTrix has done a great job of supporting FSL tools and formats, and using them when they are the best of breed (e.g. dwipreproc provides elegant wrapper for TOPUP/Eddy) while providing numerous terrific independent tools (denoise, debiggs, viewer, etc). I think it is worth working out a good solution.

 /*! To signify that the vector value at each voxel is really a
     spatial coordinate (e.g., the vertices or nodes of a surface mesh):
       - dataset must have a 5th dimension
       - intent_code must be NIFTI_INTENT_POINTSET
       - dim[0] = 5
       - dim[1] = number of points
       - dim[2] = dim[3] = dim[4] = 1
       - dim[5] must be the dimensionality of space (e.g., 3 => 3D space).
       - intent_name may describe the object these points come from
         (e.g., "pial", "gray/white" , "EEG", "MEG").                   */

[jdtournier]

Yes, I was thinking that the NIfTI intents codes could be used here, but there's a few problems with that IMO. The main one is that they're rarely used and/or respected. MRtrix3 doesn't query them, and if we did there'd be a problem interoperating with other image formats where that information is not stored. Also, given that you can render MRtrix3-generated vectors in FSLview, I assume this means that FSL also does not use the intent codes for this purpose...? There's a lot of functionality in NIfTI that probably sounded like a great idea at the time (and still does, to be fair), but if they're not used and supported by all (or at least most) implementations, they're not a lot of use... Finally, it's going to be tricky to properly support this at all stages of the software - sure, we can store this information when generating the vectors in the first place, but what happens if we subsequently process these data with other generic tools, especially when different images with different intents codes might be combined...? I'm sure sensible behaviour can be guaranteed in most cases, but probably not all. In any case, I can envisage situations where it wouldn't be trivial to ensure consistency.

So I don't have a simple solution for this. We had similar problems back when we switched spherical harmonic basis, and going back further, the whole Analyze left/right fiasco. There was never a simple fool-proof way of handling these changes in interpretation / convention...

[Lestropie]

Nothing in BIDS yet, but work has started on a DWI extension (among others) to BIDS. So I've raised this issue in that context. Given BIDS is already tied to bvecs / bvals it wouldn't surprise me if the FSL convention is adopted there as well, but I'm trying to encourage use of the fixel directory format.

[pauldmccarthy]

Hey all, sorry for the delay - I was away from the office when this topic came up, and have been busy catching up since ... This issue likely stems from the FSL way of doing things, which is caused by copious amounts of ANALYZE-induced legacy in the FSL code base. There is a small troubleshooting section in the FSLeyes docs which tries to explain this a bit further.

Internally, many FSL tools work in a "scaled voxel" coordinate system (i.e. voxels scaled by pixdims), with an implicit L/R flip if the image has (or rather, appears to have) a neurological data storage order. FSL vector outputs (and, I think, bvecs as well) are defined in this coordinate system.

This coordinate system will be aligned with the voxel coordinate system if the image sform has a negative determinant, but will have its X axis inverted if the sform has a positive determinant.

I haven't been around long enough to be able to fully explain the reasoning behind this (MJ would be the best person for that), but I suppose that in the days before NIFTI this made sense, as it was a simple way to abstract away the data storage order (at least as long as it was LAS or RAS), and allow software to be written against a pseudo-world coordinate system.

As long as an analysis pipeline only uses FSL tools this is not a problem, as everything within FSL (FSLeyes included) is internally consistent. I'm sure that the same goes for mrtrix3, or any other package. But there will always be problems when working with data from different software packages which have different conventions.

I don't think there's an easy work-around to this involving NIFTI intent codes or otherwise. Both FSL and mrtrix3 have their own way of doing things, neither of which are likely to change any time soon. So, as I see it, the end user needs to be aware of this issue, and able to correct for it.

I asked the FMRIB diffusion people a while back to set the NIFTI intent codes for vector outputs. I think that the latest version of dtifit does this, but I'm not sure about bedpostx or the other more advanced tools. But dtifit still outputs vectors in 4D (X,Y,Z,3), rather than 5D (X,Y,Z,1,3). In my experience, many FSL tools don't enjoy working in > 4 dimensions. There is some internal work on a new image abstraction layer which has much better support N-dimensional images, but I am not sure when this will make it into the main code base.

Apologies for the length - I hope that at least some of this rant has been useful to somebody!

[jdtournier]

Thanks @pauldmccarthy, that makes a lot of sense - and matches exactly with the bvecs/bvals storage convention (although the x-inversion for positive determinant did catch us out big time). It's clearly historical, and it's obvious that there will be huge reluctance to change this in FSL. On the other hand, I think storing this type of information relative to world coordinates makes so much more sense, I'd consider any move away from that in MRtrix to be a major regression... So I agree that at present, the onus will be on users to watch out for this. Lucky them.

As to the use of NIfTI intent codes: I'm not against them, but I don't find they add a great deal of value... I'd rather let users feed in whatever data they feel is the correct input to whatever command they want to run, and that act alone is intent enough for me. If we were to start using intent codes and acting upon them, that would likely entail rejecting otherwise perfectly usable inputs simply because the intent field does not match expectation - something that I'd consider a needless obstruction, and a reduction in flexibility (I've sometimes been surprised to find users combining our commands in totally unexpected ways, but which weirdly work out as good solutions to their specific problem). On the other hand, if these intent codes are simply there to describe what the data are supposed to represent, with no other impact on the processing applied to them, then that's fine - but personally I think filenames are just as expressive (and more flexible)... Just my 2 cents though, no disrespect to the NIfTI working group... ✌️

[Lestropie]

Within the confines of operating with our own software, I would suggest that the scope of what we could possibly do at our end would be:

• Provide a command peakconvert that would convert from scanner to image convention and vice-versa.

• Add a header key-value entry specifying which coordinate system the peak directions are defined with respect to. While this would be more consistent with how we typically store such information in MRtrix3, this information would nevertheless be lost upon conversion to NIfTI.

[pauldmccarthy]

A hacky/heuristic-based method to determine whether a vector image was generated by FSL, and needs to be L/R flipped might be to test both the sform and descrip fields.

If the descrip field is equal to FSL4.0, FSL4.1, FSL5.0 or 5.0.10¹, then it is likely to have been generated by FSL². If this is the case, and the sform has a positive determinant, then you can be reasonably sure that the vectors need to be flipped.

¹ I don't know why the FSL prefix was removed in version 5.0.10 - I have asked for it to be added back for the next release.

² Of course this all falls apart if any other software clobbers descrip, or does something to the data without changing descrip.