[Insight-developers] Analyze IO

[Hans J. Johnson]

Stephan,

The problem with this is that it introduces the very real possiblility of
getting right/left swaps in your images.  The ITK implementation was written
to meet the file format definition as specified by the original developers
(i.e. Mayo clinic as part of the Analyze program).   The bug fixes occurred
close to the time when the switch from metadata orientation to direction
cosines was done.  This is mostly because that is when the bug was
discovered, isolated, and a fix was made.  The original buggy meta-data code
was written prior to images having a well defined definition concept of
orientation, and during the implementation of the orientation code (via
direction cosines) this definition became clear and well defined across all
file format readers.

The behavior did change, but it was a bug fix.

I have very strong feelings on this because analyze files that are written
to disk with ambiguity have cost me weeks of time tracking down problems.
Because of this dangerous situation, I believe quite strongly that any file
format that claims to respect orientation should do so consistently across
all file formats.

You proposal below would map the following 3 direction cosign inputs to the
analyze file filter correctly:

itk::SpatialOrientationAdapter<3>::DirectionType SAGdir=
SpatialOrientationAdapter<3>().ToDirectionCosines(itk::SpatialOrientation::I
TK_COORDINATE_ORIENTATION_PIR);
SAGITTAL 133124
0 0 1
-1 0 0
0 1 0

itk::SpatialOrientationAdapter<3>::DirectionType CORdir=
itk::SpatialOrientationAdapter<3>().ToDirectionCosines(itk::SpatialOrientati
on::ITK_COORDINATE_ORIENTATION_RIP);
CORONAL 264194
1 0 0
0 0 -1
0 1 0 

itk::SpatialOrientationAdapter<3>::DirectionType AXIdir=
SpatialOrientationAdapter<3>().ToDirectionCosines(itk::SpatialOrientation::I
TK_COORDINATE_ORIENTATION_RPI);
AXIAL 525314
1 0 0
0 -1 0
0 0 1

===============================
But the other 45 possible orientations of a 3D dataset would also map to the
RPI definition.  This means that I could only trust SAGITTAL and CORONAL
image definitions, and would be forced to assume all other definitions are
"best guesses"

###############################
###############################
###############################
Another acceptable solution would be to reorient the image data for those
other 45 possibilities to the RPI orientation prior to writing.  I assume
that the main problem is that the default direction cosign of
1 0 0
0 1 0
0 0 1

Is not a legal tag for analyze file formats.

###############################
###############################
###############################
Finally, there is a bit of a compromise.  I was originally advised not to
use analyze orient codes of "3,4,5,6" because they are so often mis-used by
improper 3rd party analyze image implementors:

typedef enum _analyze75_orient_code
  {
    a75_transverse_unflipped = 0,
    a75_coronal_unflipped = 1,
    a75_sagittal_unflipped = 2,
    a75_transverse_flipped = 3,
    a75_coronal_flipped = 4,
    a75_sagittal_flipped = 5,
    a75_orient_unknown = 6
  } 
  analyze_75_orient_code;

Conversations with the Analyze folks indicated that to respect the original
intent of the file format, that orient codes of "3,4,5,6" were only to be
used internal to the Analyze program for display purposes, and were never
supposed to be written to disk.

I would be quite comfortable with having this implementation put into place.
I would like to put a prohibition on reading or writing orientaiton codes
with the unknown orientation flag.  Again force re-orientation of the image
to a valid (preferably code 0,1,2) orientation before writing.

Sorry to be so draconian about this, but I have been very embarrassed
because I depended on ITK getting these orientation done correctly.  When
using ITK to convert dicom images to both nifti and analyze images, about 5%
of the 500 images were right left swapped when the nifti and analyze images
were loaded with ITK tools.  I confirmed the problem by using a simple image
difference program, and the dicom-nifti always gave 0, but 5% of the
nifti-analyze showed the right left swap.

I'm leaving town tomorrow, so won't be able to put this into place, but
perhaps I can get some help? If this is something that needs to be done
quickly, Kent Williams should have time during the middle to end of this
week to work on the changes and tests.  There should be a test to ensure
that only valid accepted codes can be read and written to disk.  If the
difference between reading and writing analyze or nifti (or any other
sufficiently tagged format Meta/Dicom) should be un-ambiguous.

Ok...enough ranting ;)

Regards,
Hans



On 2/24/07 10:49 AM, "Stephen R. Aylward" <Stephen.Aylward at Kitware.com>
wrote:

> Hi,
> 
> The behavior of the Analyze writer has changed.   Now if the orientation
> of the image isn't known, an exception is thrown.
> 
> The changes are related to the switch from metadata orientation usage to
> oriented image usage.
> 
> I suggest that if the orientation is unknown/undefined, then we throw a
> warning, but continue under the assumption of RPI (the default used in
> other cases).   Only if the orientation is explicit and not a supported
> type should we throw an exception.
> 
> I've make the changes in my local version and can forward them to anyone
> with cvs access.
> 
> Stephen