Last edit: 05-08-29 Graham Wideman
|
Last edit: 05-08-29 Graham Wideman |
Analyze Format |
| Mayo/SPM "Analyze" MRI Format Article created: 2003-06-22 |
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.
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).
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
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.
The following ideas seem like some bare essentials for addressing the Analyze orientation ambiguity.
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.
Go to: