I'm not convinced that changing the 'AnatomicalOrientation' of an MHA file has the same meaning as changing the 'space' of a nrrd file.

For a nrrd file, the meaning of things like 'space directions' is always referenced to the space tag:

http://teem.sourceforge.net/nrrd/format.html#space

But as nearly as I can tell the itkMetaImageIO.cxx uses the TransformMatrix field to set the Direction cosines and this is what defines the mapping from IJK to RAS for slicer (and I think in general all programs that rely on ITK's IndexToPhysical infrastructure would also ignore the AnatomicalOrientation flag in favor of the TransformMatrix).

I'm going to mark this as will not fix -- if there is a use case for changing the MHA header in this way then feel free to re-open the bug and add info on the scenario.

'AnatomicalOrientation' of an MHA file has the same meaning as changing the 'space' of a nrrd file. See http://www.itk.org/Wiki/ITK/MetaIO/Documentation:

AnatomicalOrientation
MET_STRING
Specify anatomic ordering of the axis. Use only [R|L] | [A|P] | [S|I] per axis. For example, if the three letter code for (column index, row index, slice index is) ILP, then the origin is at the superior, right, anterior corner of the volume, and therefore the axes run from superior to inferior, from right to left, from anterior to posterior.

Yes, I agree that is what the documentation implies - I don't see anywhere in the ITK code where that is taken into account. Are you certain that other uses of the metaIO format interpret this field?

If you look at the reader code it ignores this field (although it is probably passed as a typeless string in the metadata dictionary)

https://github.com/Kitware/ITK/blob/master/Modules/IO/Meta/src/itkMetaImageIO.cxx#L79

The problem is that it is not taken into account. I don't know where the axis orienting is done for other file formats, such as NRRD, but it should be probably implemented similarly for meta.

The orienting to LPS could be (should have been) implemented in ITK and in Slicer we would further orient the axes to RAS; or all the orienting could be done in one step in Slicer.

As the reorienting is not implemented in ITK I assume that all the applications that rely on ITK ignore this field.

Probably we should consult ITK / MetaIO people to hear their opinion.

I agree that this an issue for the ITK/MetaIO community should be able to help us with. As far as I know slicer treats all formats identically in the sense that it delegates to ITK the process or reading pixels, spacing, orientation, and directions. From there slicer creates a uniform representation in the mrml volume node.

I don't see that there's anything fixable on the slicer side - we might consider generating a geometry warning when trying to read meta files if we think there's a realistic possibility that people will run into this issue in practice.

Yes, I would guess that all applications that use ITK to read meta files would behave the same way slicer does unless they probe the metadata dictionary explicitly. I would also guess that most applications do not do that. And I would guess that most applications that use meta use it via ITK. Therefore I don't see this as a bug we can deal with inside slicer's code, but something we can pass over to the ITK community.

MetaIO works using direction cosines to represent how data is stored. The anatomic information is not mathematically interpreted - they are meant to help applications interpret how the data should be labeled when displayed. If you change it, the direction cosines are not recomputed.

For example, when an application inverts direction cosines, the application is responsible for updating the anatomic labels. MetaIO is a file format - it writes out what you tell it and it reports what it reads.

ITK usually converts the image axes orientation to LPS. So, after the medical image is loaded into ITK, in the resulting image the +x direction always corresponds to L direction, etc.

It is achieved by reordering/inverting the components of the direction cosines matrix, according to the patient orientation.

For NRRD file format the reordering/inverting is implemented in ITKv3\Code\IO\itkNrrdImageIO.cxx.

For MetaIO the orientation ignored (just stored), but not used to compute the correct direction cosines, see ITKv3\Code\IO\itkMetaImageIO.cxx.

To be consistent, ITK should either always ignore the orientation (and let the application level code to perform this), or always perform the orientation normalization (preferred option; this way all applications would be simpler).

Since this is an issue in ITK itself, there is nothing we can do in slicer to fix it. A topic should be opened on the ITK tracker pointing to this issue for background.

Did this ever make it to upstream?

I've looked at the MetaIO documentation and it contains a clarification of the anatomical orientation: http://www.itk.org/Wiki/Proposals:Orientation#Some_notes_on_the_DICOM_convention_and_current_ITK_usage

In summary, RAI in a MetaIO image means DICOM LPS. Therefore the header information in saved files are correct.

ITK ignores anatomical orientation information and just always assumes DICOM LPS. As the assumption is true for files are saved by ITK or Slicer, I would consider treating anatomical orientation management in MetaIO in ITK and enhancement request.