Filling nifti orientation with ismrmrd metadata

[aTrotier]

Issue

For now the nifti are created without any position/orientation. It will be an issue at some points if we want to perform registration with sequence not acquired at the same position.

Enhancement to do :

Filling nifti from ismrmrd metadata

I have already worked on that topic a little bit in matlab : https://github.com/aTrotier/ismrmrd_to_nifti It has to be implemented and adapted. For Bruker no official converter exists (maybe in PV360 ?) I guess we have to choose one to check if we get kind of the same results. (I am working with https://github.com/lamyj/dicomifier for example by @lamyj)

Filling nifti for 2dseq bruker

Another point is to handle the case of 2dseq that we would like to convert to nifti (data are flip and rotate by Bruker accordingly to the orientation)

[tknopp]

Absolutely! We are aware that our nifti / dicom story is far from great and this mostly because our focus is more on the reconstruction algorithms. This is something where it thus needs external contributions. Note that @Tokazama is the expert on NIfTI (and DICOM?) in Julia land and has for more insights into NIfTI.jl

[Tokazama]

Check out https://github.com/JuliaArrays/SpatioTemporalTraits.jl and https://github.com/JuliaArrays/ArrayInterface.jl. I'm just finishing up a PR for dimension names in the latter so I can update NIfTI.jl. The idea is that these are relatively small packages that provide generic methods for extracting dimension names, spatial/temporal units, etc. This approach is nice because the interface is common, even if a package implements their own types for the back end.

I'm not sure what the full story should be on orientation information because dimension names only gets us rigidly aligned with each plane. Once we bring translation and linear mapping into the situation we have some issues. Mainly, these are often not represented by simple matrices and require explicit types (quaternions, euler angles, etc.). There are multiple packages that address this and their different approaches may not compatible.

I'd love if there were a common approach to extracting this information, like (translation(img), linear_map(img), rotation(img)) but I'm not sure how to propagate those features between nested arrays without explicitly knowing what they would return (SubArray, ReinterpretArray, PermutedDimsArray). I spent some time trying create an abstract representation of coordinate systems but it's difficult to have something that abstract become clearly useful without just reimplementing all these different spatial transformations anew. If we had a solution to this part of the issue we'd have nearly a complete story for how to unify spatiotemporal data across Julia.

@timholy might have a suggestion.