MRAC Interfile output should depend on patient orientation

[KrisThielemans]

Interfile is normally a "gantry-based" coordinate system (although it isn't really well defined in the very old Interfile standard, but that's how STIR interprets it.) ITK uses a patient-based coordinate system. That means that the reorientation should depend on patient orientation, but it currently doesn't.
We currently default to RAI

pet-rd-tools/lib/nmtools/MRAC.hpp

Lines 129 to 130 in 605984a

	itk::SpatialOrientation::ValidCoordinateOrientationFlags _outputOrientation
	= itk::SpatialOrientation::ITK_COORDINATE_ORIENTATION_RAI;

A somewhat related problem is that this choice is inconsistent with STIR's implementation by @ashgillman, which uses RAS for HFS. Indeed, @ashgillman noted in #18 that he has to use RAS for his (presumably HFS) data. @bathomas replied he choose RAI to fit e7tools "Interfile-like" images. This might imply that Siemens uses different coordinate axis (i.e. axially oriented in the other direction) for its Interfile than STIR. I have no idea what e7tools does for different patient orientations.

This is all a bit of a mess of course.

I'm reluctant to duplicate @ashgillman careful STIR code on patient orientation here, especially if the Interfile output isn't suitable for STIR anyway. My current inclination is to "abandon" the MRAC code here, and move/copy relevant bits into STIR. (essentially we need the rescaling and resampling).

[ashgillman]

Sorry a little late to the party..

I tend to agree that it might be better to wrap that functionality into STIR. Alternatives would include

• depending on STIR and using its I/O;
• avoiding doing interfile conversion here and saving back out as DICOM then having the user read that in STIR;
• reimplementing here