Abstract

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):

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.

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.