ashgillman
commented
3 years ago 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
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 https://github.com/UCL/pet-rd-tools/blob/605984ae55c8bc0ea7a13765962e26666c189e6c/lib/nmtools/MRAC.hpp#L129-L130
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).