[ENH, MRG] Add scanner RAS coordinate frame definition

[alexrockhill]

Related to comment in bids-standard/bids-specification#747

[alexrockhill]

Here's how it looks in the GitHub rendered markdown https://github.com/alexrockhill/website/blob/scanras/faq/how_are_the_different_head_and_mri_coordinate_systems_defined.md

[robertoostenveld]

with the axes reordered and flipped

Are the axes flipped, or is the order of the voxels in the volume flipped, or both?

Flipping both is demonstrated here. Flipping only the axis would keep the imagesc plot of Mr. Potatohead the same and only rotate/flip the green lines that are plotted on top of it. Flipping the voxels without the axes results in yet another configuration.

[robertoostenveld]

centered at the native scanner origin

Am I correct that here you mean the centre of the gradient coil?

Since the original bids-standard/bids-specification#747 mentions FreeSurfer, it might be relevant to point out that the FreeSurfer origin is different from the scanner origin.

Edit: I am not so sure any more about the correctness and clarity of my previous statement. When writing that, I was thinking about the 256x256x256 FreeSurfer files that have the origin in the center of the volume (in between voxel 128 and 129). But FreeSurfer will also have files that have not been padded yet to 256x256x256.

[alexrockhill]

with the axes reordered and flipped

Are the axes flipped, or is the order of the voxels in the volume flipped, or both?

Flipping both is demonstrated here. Flipping only the axis would keep the imagesc plot of Mr. Potatohead the same and only rotate/flip the green lines that are plotted on top of it. Flipping the voxels without the axes results in yet another configuration.

The axes are flipped but the voxels are left in their original configuration.

[alexrockhill]

centered at the native scanner origin

Am I correct that here you mean the centre of the gradient coil?

Since the original bids-standard/bids-specification#747 mentions FreeSurfer, it might be relevant to point out that the FreeSurfer origin is different from the scanner origin.

Edit: I am not so sure any more about the correctness and clarity of my previous statement. When writing that, I was thinking about the 256x256x256 FreeSurfer files that have the origin in the center of the volume (in between voxel 128 and 129). But FreeSurfer will also have files that have not been padded yet to 256x256x256.

Correct, I was following the convention to exclude detail on the second instance as in native for scaling.

I'm not aware of Freesurfer files that have not been padded to 256 x 256 x 256 yet with the exception of mri/001.mgz/mri/orig.mgz which are just copied versions of the original scan. To my knowledge, everything subsequent is in the standardized voxel size.

In general, yes, scanner RAS and surface RAS will not have the same origin.

[robertoostenveld]

I carefully reviewed https://dicom.innolitics.com/ciods/mr-image/image-plane/00200037 and https://www.sciencedirect.com/science/article/pii/S0165027016300073, see also fieldtrip/fieldtrip#1869.

For bipeds, the DICOM coordinate system has the origin at the center of the gradient coil (not specified as such), the x-axis is increasing to the left hand side of the patient. The y-axis is increasing to the posterior side of the patient. The z-axis is increasing toward the head of the patient.

This is now correctly represented in ft_read_mri with the dicom_old implementation that uses the dicom importing functions from the Mathworks image processing toolbox and https://github.com/fieldtrip/fieldtrip/blob/master/fileio/private/dicom2transform.m to convert the DICOM header in a 4x4 transformation. Note that this code is not specific to MRI scans of heads/brains but also applies to other body parts by sticking as closely as possible to the formal specification.

cd subjectRO/20030731/
mri = ft_read_mri('ERIVDBER_030731_R.OOSTERVELD.MR.PAUGAA_ANATOMICAL-3D.2.165.2003.7.31.11.19.16.203000.53832966.IMA', 'dataformat', 'dicom_old')
ft_determine_coordsys(mri, 'interactive', 0, 'fontsize', 18)

Comparing this to the FreeSurfer implementation of the DICOM reading functions, I see that FS rotates the coordinate system 180 degrees around the z-axis.

mri_fs = ft_read_mri('ERIVDBER_030731_R.OOSTERVELD.MR.PAUGAA_ANATOMICAL-3D.2.165.2003.7.31.11.19.16.203000.53832966.IMA', 'dataformat', 'dicom')
ft_determine_coordsys(mri_fs, 'interactive', 0, 'fontsize', 18)

[robertoostenveld]

figure 1 from https://doi.org/10.1016/j.jneumeth.2016.03.001 clarifies this

The dicom_old implementation reads it according to DICOM convention, the dicom implementation (using FreeSurfer code) according to NIfTI conversion.

That also means that the NIfTI coordinate system and the Scanner RAS (aka scanras) coordinate system on https://github.com/alexrockhill/website/blob/scanras/faq/how_are_the_different_head_and_mri_coordinate_systems_defined.md are identical. Agreed?

The original DICOM coordinate system could in principle be indicated as scanlps.

Edit: corrected that DICOM compares to scanlps, not to scanals.

[robertoostenveld]

Oh, and to complete the links to documentation elsewhere: on https://brainder.org/2012/09/23/the-nifti-file-format/ it states for NIfTI

The world coordinate system is assumed to be ras: +x is Right, +y is Anterior and +z is Superior, which is precisely different than the coordinate system used in analyze, which is las.

[robertoostenveld]

I have added some text to explain the relation between scanras, DICOM and NIfTI

The Scanner RAS coordinate system has the same origin as the DICOM coordinate system, but is rotated 180 degrees around the z-axis. The Scanner RAS coordinate system is identical to the NIfTI scanner coordinate system (qform). It is defined as

[alexrockhill]

Wow thanks so much for really digging into this, that is really good info, I really only knew what was going on in the code. Sorry to leave the PR stale--our baby arrived right after I opened it, thanks for finishing it @robertoostenveld!

[robertoostenveld]

congrats!

Now that we have established that scanras==nifti and dicom== scanlps and scanras==rot180z(scanlps), I will update https://github.com/fieldtrip/fieldtrip/blob/master/utilities/ft_convert_coordsys.m, https://github.com/fieldtrip/fieldtrip/blob/master/utilities/ft_determine_coordsys.m and https://github.com/fieldtrip/fieldtrip/blob/master/utilities/private/coordsys2label.m so that they also know about these (and where possible can convert to/from these).

Edit: corrected that DICOM compares to scanlps, not to scanals, and that the rotation is 180 degrees.

[robertoostenveld]

With fieldtrip/fieldtrip#1878 I have now also added support for these coordinate systems to the FieldTrip code.