One data format which is widely used for storing and sharing MRI data is the so-called “Analyze 7.5” (or simply “Analyze”) format. This is a format originated by Mayo Clinic, for use by their Analyze software. You can see how it fits into the present Mayo scheme here — ie: from their point of view it has been superseded.

Analyze format’s apparent simplicity has attracted broad adoption or support by other software authors. Unfortunately it lacked some features that developers and researchers needed, which has invited a number of alternative interpretations. It now so lacks consensus on its meaning that there is no reliable way to know how to completely interpret Analyze files, in the absence of actually looking at the contents by eye. Right-left orientation is a particularly pernicious problem.

This set of pages examines this issue, describing the dimensions of the problem (as I currently understand it) and an approach to retaining some sanity while dealing with it: by applying judicious use of  tools, sample data and so on. A proposed format (NIfTI) offers some hope for improvement in the future.

The Problem

An Analyze data set consists of one file (something.img) containing a blob of binary data representing a stream of voxel intensities, and a “header” file (something.hdr) containing a description of the dataset, and description of the structure of the data found in the img file. This general scheme is a common one, so no surprises yet.

Given such a scheme, one might expect support for (or at least a philosophy regarding):

  • Different quantities of voxels along each dimension
  • Storing voxels in different orders (“orientations”)
  • Choice regarding the number-type used for voxel intensities (byte, 16-bit integer, 32-bit integer, float).
  • Choice regarding byte-ordering (Little-endian Intel ordering or Big-Endian ordering).

The header would need to inform us reliably about these particulars, and software would need to honor them.

Unfortunately, Analyze format’s approach to orientation has not satisfied the needs of users and developers, with the result that there is widespread use of procedures and software that reorient data using different schemes to record the change, or no scheme at all.

Consequently, it can be said with confidence that if you don’t know the processing history of some Analyze-format data set, you definitely don’t know the orientation of the data unless you inspect it visually.  Even then you will only know the orientation if you can see recognizable landmarks, which will generally be difficult when trying to determine Left vs Right, or when looking at data sets whose shapes aren’t necessarily suggestive of structure (such as blobs of functional activation).

Format Details

If you are interested in the details of Analyze format, there’s a compilation of technical info here: Mayo/SPM “Analyze” Format Spec Compilation.  Notably, there is a strictly correct way to use Analyze format, though the complete documentation needed to do so has in the past been hard to come by. That said, the format as specified lacked some useful flexibility which developers have tried to achieve in other ways. The Spec Compilation page records some of the variants.

If you are more interested in the general subjects of orientation and voxel-order, here is an effort to capture the sometimes conflicting terminology: Orientation and Voxel-Order Terminology: RAS, LAS, LPI, RPI, XYZ and All That

Treating the Problem: Viewing Orientation

The most painful collision with the orientation ambiguity problem occurs as you are trying to do some ad-hoc processing, or trying to establish some new chain of processing that you’ve never tried before. Once you have established the processing steps using some test data, and know what each program does to the data orientation, then you will be able to reuse that series of steps later with a little better confidence that the process is under control.

So it’s the ad hoc and initial testing of Analyze-format-using programs which needs careful treatment.

The main challenge here is to be able to ascertain unambiguously the orientation of Analyze data sets at the input and output of the one or more programs that you’d like to employ, and then to use that information to adjust command parameters or dialog settings until you get something desirable to happen.

That means you need to be able to view the data in a way that unambiguously shows you the orientation of the raw data.

Unfortunately, most viewers are not clear about the relationship between the raw data and the view that you see on screen. Understandably, each viewer tries to be at least somewhat intelligent in interpreting the header file, orienting the view to be pleasant to the eye. But since you don’t know what the software did to create that view, you can’t use that view to reliably determine the order of the raw data.

Survival Improvement Ideas

The following ideas seem like some bare essentials for addressing the Analyze orientation ambiguity.

  • To reduce the proliferation of orientations that software may or may not automatically understand, it would be a very good idea to keep Analyze data in either the “strict” RPI data order, or possibly LPI data order (as in SPM99), and not use any other order. Between RPI and LPI, there are rationales to use either one, but it would seem essential to maintain some independent record of the voxel order as the format itself doesn’t reliably help with this. (There are potentially some speed arguments in favor of other orientations — painstaking recordkeeping required!.)
  • Obtain at least one viewing tool that you can trust to show you unambiguously the order of data in an Analyze file. In case you don’t have one, you may be interested in the viewer available here: GWORC: GW Orientation Reality Check Viewer.
  • You may want to inspect an Analyze header (hdr) file. There are a number of command-line tools to do this, or you might like this one here: GWAnalyzeHeader
  • To be able to see before-and-after orientation changes, you’ll need data that has sufficiently distinct right and left sides, while still being brain-like enough to be digestible by your processing step(s). I don’t really have advice on this, except that there are some such floating around (see the example on the Orientation and Voxel-Order page).  Also, it’s probably not that hard to find volumes with distinctive features (and worth keeping a good one handy).
  • You may need to perform an orientation change and set header information manually. Probably there are a variety of tools to do this — MRIcro and AFNI are two. MRIcro’s “Save as rotated” function with preview allows you to reorient interactively, which may help to get things right more quickly.
  • Chris Rorden also mentioned his standard practice of attaching an MRI-visible marker (vitamin E gel capsule) to the left cheek of every subject. A marker that actually looks like an “L” would reassure that it was actually attached to the left side.

Hope for Future Improvement

Brought to my attention by several correspondents is the NIfTI initiative to define a new descendant of the Analyze format which would fix some of the shortcomings of the existing situation, notably providing a proper orientation attribute.  Given that the group includes participants from a number of the more active Analyze-format-supporting software development groups, this holds promise that a format spec might result that will be more consistently adhered to.

Although that won’t magically fix existing Analyze format datasets, the NIfTI standard would provide a replacement format that old data could be easily copied to. In fact it might be as simple as minor editing of the header.  A lab could then undertake a one-time process to go through previously-collected data, carefully setting the orientation attribute from other records to reflect actual orientation.

Thus the new format would not just serve future data, but it would also allow improving the reliability and usability of the legacy data.

In addition, for scenarios where the Analyze format is used only for temporary files for intermediate steps in a processing chain, broad support for NIfTI format would do away with the necessity to laboriously determine which processing steps pay attention to what orientation information.