search

SyneRBI / SIRF

Main repository for the CCP SynerBI software
http://www.ccpsynerbi.ac.uk
Other
59 stars 29 forks source link

orientations of NiftyReg output are in RAS #721

Open KrisThielemans opened 4 years ago

KrisThielemans commented 4 years ago

deformation/displacement vector fields (DVF) encode deformations in RAS. Also, the info for rigid transformations is in RAS, see https://github.com/SyneRBI/SIRF-Exercises/issues/44#issuecomment-640483754 This is because that's how NiftyReg's internal coordinate system works.

Note that some registration packages might output DVFs in voxel-units, so it's not just a matter of orientation.

This is confusing as the rest of SIRF is in LPS. Solutions:

  1. reorient deformation fields whenever we do as_array() or fill() (seems very inefficient)
  2. leave as-is and a. document that orientation of DVFs is not what they expect, and will depend on the "engine" b. add another "geometric matrix" to the DVF (i.e. one for the "voxels", one for the "vectors")

My preference is for the 2nd solution. (It's a bit similar to the question asked by @rijobro in https://github.com/SyneRBI/SIRF-Exercises/issues/44 if as_array() should return voxels in a standard order, and I feel it shouldn't (as it's going to slow us down).

We could still return affine transformation info in LPS though. Efficiency there doesn't matter, and it seems rather logical for a user to expect that they can multiply our geometric info matrices and affine transformation matrices (but right now we cannot as they're in different coordinate systems).

opinions?

I guess SPM does the same.

DANAJK commented 4 years ago

There are other coordinate systems that might be used, for example the physical gradients or the read-phase-slice. So I would favour option 2 - being very clear about what the code expects/is doing and maybe providing the user with the means to transform between systems.

KrisThielemans commented 4 years ago

I suppose this question would also apply to diffusion tensor imaging in MR. could have same solution.

DANAJK commented 4 years ago

The gradients in diffusion tensor MRI inherently come from coils fixed to the machine and are thus fundamentally in a 'fixed' frame rather than the patient frame. However, they are sometimes specified in terms of the imaging planes (read-phase-slice) and the scanner will internally do the transformation. For many of the more simple analyses that return a scalar (diffusion coefficient, fractional anisotropy), it doesn't matter. Getting it all understood is important if you want to do tractography as this generates directions that need to correspond correctly to directions within the patient.

KrisThielemans commented 4 years ago

ok. I think documenting this and adding a method that returns the geometric info (which in the NiftyReg case would presumably just be diag(-1,-1,1,1)) would be quite easy. Implementing conversions won't be, but we can easily postpone that.

@rijobro, any opinion?

rijobro commented 4 years ago

Could we have optional second parameter that converts to e.g., LPS, but by default leaves as is for backwards compatibility? Along the lines of:

registration.get_TM(order="RAS")
KrisThielemans commented 4 years ago

not sure about that solution. The default would then be very non-SIRF-like, and confusing once we get to ITK rigid registrations for instance. I'd rather then provide get_TM_in_LPS or something (and set I guess). We could then document that get_TM is in whatever native coordinate system is used by the "engine". (I'd recommend not to use it).