ft_write_mri should use mri.coordsys when writing data to nifti file

[robertoostenveld]

Where possible, the coordsys should be translated in an sform_code or qform_code (0, 1, 2, 3, 4) so that upon reading of the file (with ft_read_mri) the coordinate system can be properly interpreted.

The MEG and EEG coordinate systems (such as ctf, neuromag, bti, etc) are based on external anatomical landmarks (nasion, ears) and not supported in the nifti file format. See https://brainder.org/2012/09/23/the-nifti-file-format/ and this table copied from there:

NAME	CODE	DESCRIPTION
unknown	0	Arbitrary coordinates. Use Method 1.
scanner_anat	1	Scanner-based anatomical coordinates.
aligned_anat	2	Coordinates aligned to another file, or to the “truth” (with an arbitrary coordinate center).
talairach	3	Coordinates aligned to the Talairach space.
mni_152	4	Coordinates aligned to the mni space.

I think that it would be appropriate to write MRI data that is expressed in a known MEG coordinate system with the aligned_anat (2) code. Upon reading the nifti file with ft_read_mri, you would still not know whether it is ctf, neuromag, or something else, but it would be slightly more informative than it being unknown.

In case the FreeSurfer implementation is used underneath the present ft_write_mri code (the default for nifti), it is always written with scanner_anat (1).

In case the SPM12 implementation is used underneath the present ft_write_mri code, it seems that it is always written with aligned_anat (2).

These hard-coded assumptions in the SPM12 and FreeSurfer code are not consistent with the information that is available to the FieldTrip user, e.g. after ft_determine_coordsys.

[robertoostenveld]

I am currently making some improvements to ft_read_mri to interpret the 'sform_code' or 'qform_code'. However, the implementation in ft_write_mri does currently not consider mri.coordsys when writing to disk, hence the the sform_code/qform_code is likely incorrect or inconsistent with the operations that the user performed on the anatomical MRI (such as realigning). Upon reading it back in, the coordinate system is then also not consistent.

Therefore I will at this moment only implement some feedback on the coordinate system on screen, not assign it to mri.coordsys.