[Insight-users] Analyze Image IO broken?

[Kent Williams]

First problem: You kind of have the solution in your question -- the way 
the ImageIO facility works, is that the ImageFileReader calls 
CanReadFile with each registered ImageIO class, until it finds one that 
returns true, indicating that it can read the file.  So it looks like 
GDCM is trying to read the file and getting confused.  It shouldn't 
abort, though -- it should just percolate up a return value of false to 
the Image File reader, so this is a bug.

Second problem:  ITK supports the notion of Image Orientation, which is 
most relevant when dealing with medical imaging.  The orientation is 
represented as one of 48 orderings of dimensions, which are denoted by 3 
letter codes: L or R (left or right) I or S (inferior or superior) and  
A or P (anterior or posterior). 

The Analyze file format only supports 3 orientations in files -- 
transverse-unflipped, coronal-unflipped, and sagittal-unflipped. These 
correspond to RPI, RIP, and PIR orientations.  Before a few months ago, 
if the AnalyzeImageIO received an image to write in one of the other 45 
possible orientations, it marked it as RIP (Coronal), and wrote it 
out.   I recently changed this to throw an exception if a non-supported 
orientation is detected.

I suspect you may be ignoring image orientation entirely in your 
application, which leaves all images created with the default 'identity' 
Direction Cosines, which corresponds to the orientation code RAI.  You 
would need to use SetDirection() on your images to set them to a 
supported orientation in order to write out an analyze file.

In our research over the past couple of year, we've started to regard 
Analyze format files as a 'read-only' format, and when possible 
converting them immediately to NIfTI images.  NIfTI is based on Analyze 
format but has consistent support for image orientations, and 
additionally supports an extension definition that lets an application 
save application-specific data with the image.

The only reason to continue writing Analyze files is to support an 
application that _only_ reads Analyze files.  And if you want to do that 
you either need to re-orient your images into one of the 3 supported 
orientations, or if you don't care about orientation, use 
itk::Image::SetDirection() to set the direction cosines to a supported 
orientation.




Robert Tamburo wrote:
> I just noticed some strange behavior with the Analyze IO after 
> updating my ITK version to the CVS version of ITK. Two things:
>
> -----------
> 1. A program that takes as argument the name of a 3D input image with 
> the extension .img results in the following error:
>
> terminate called after throwing an instance of 'gdcm::FormatError'
>   what():  N4gdcm11FormatErrorE
> Abort trap
>
> If I use .hdr as the extension, it gets read in correctly. This same 
> program is able to take as arguments filenames with the .img extension 
> and write the files correctly.
>
> Isn't gdcm a dicom format? Why would the image factories be trying to 
> using the dicom IO?
>
> 2. Another program internally writes out a couple of Analyze images. 
> Using either the .img or .hdr extension on the filename results in 
> this error:
>
> terminate called after throwing an instance of 'itk::ExceptionObject'
>   what():  /Users/robert/code/Insight/Code/IO/itkAnalyzeImageIO.cxx:1180:
> itk::ERROR: AnalyzeImageIO(0x2814200): ERROR: Analyze 7.5 File Format 
> Only Allows RPI, PIR, and RIP Orientation
> Abort trap
>
> This code has worked for a long time. I use the same method of file 
> writing in both programs and yet one results in an error and the other 
> doesn't.
> -----------
>
> Incidentally, I just noticed these errors after testing code that I 
> recently submitted to the Insight Journal 
> (http://insight-journal.org/dspace/handle/1926/322).
>
> Thanks for any help,
> Robert
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>