[Insight-developers] itkAnalyze Valid Orientations and 3D - 2D conversions

[Luis Ibanez]

Hi Kent,

Thanks for clarifying the status of the bug 8650.

---

Regarding the new Read/Write 3D/2D tests, here
what I  have found so far:


    A) Opening a 3D Analyze image (.hdr+.img) with
       a ImageFileReader that has been instantiated
       for 2D, crashes in line:  itkAnalyzeImageIO.cxx:729.

       It appears that the gzip functions get confused
       if we attempt to make a partial read of the 3D
       file.


    B) Opening the same file with an ImageFileReader
       that has been instantiated for 3D, works fine.


What the case in (A) supposed to work ?
That is,
shouldn't I be able to read a 3D analyze image with a 2D reader ?
In most ImageIOs that will result in reading only the first slice
of the 3D image.


    Thanks for any hint,


       Luis


------------------------
kent williams wrote:
> This bug: http://www.vtk.org/Bug/view.php?id=8650 isn't related to the
> question Luiz brought up, it is about having the Analyze and NIfTI readers
> handle images that (incorrectly) specify 0 as the number of dimensions in
> the dime.dim field.
> 
> As for the actual questions:
> 
> On 4/2/09 12:07 PM, "Luis Ibanez" <luis.ibanez at kitware.com> wrote:
> 
>>
>>When starting to test the 3D and 2D combinations, the following
>>questions arise:
>>
>>
>>1) When instantiating a 2D image (that we plan to write out).
>>
>>    What are the orientations that
>>    Analyze is supposed to support ?
>>
> 
> I assume you've done some Googling for information; the most helpful links
> are
> 
> http://www.grahamwideman.com/gw/brain/analyze/formatdoc.htm
> http://eeg.sourceforge.net/ANALYZE75.pdf
> 
> Neither are particularly helpful when it comes to 2D.  As you wrote, only 3
> orientations are supported in Analyze7.5 files; and the orientation field is
> not well-defined anywhere for 2D.
> 
> You run into the same problem we've discussed elsewhere -- 2D Direction
> Cosines don't contain sufficient information to make ANY statement about
> their orientation. I'd go so far as to say 2D direction cosines are
> completely useless in defining anything about orientation.
> 
> As this applies specifically to the Analyze 7.5 format, you could fill in
> the hist.orient on write with your best guess, but who knows what other
> applications will make of this.
> 
> Even if you look at the NIfTI format, you still have issues, because NIfTI
> only has 3D Orientation in the header. At least it is well defined, but in
> the case of 2D Images, it still expects a 3D orientation.  Or nD for n > 3,
> still 3D orientation.
> 
> 
>>2) When reading a 3D image in any of the orientations listed
>>    above (RPI, RIP, PIR), we are assuming that the resulting
>>    2D image will simply have an 2D orientation matrix with
>>    an identity matrix. Given that there is no way to represent
>>    its original 3D orientation by using a 2D matrix.
>>
> 
> 
> That's what we ended up deciding to do as a complete punt.
> 
> I'd go so far as to say that there's no point in even WRITING an Analyze
> file of a 2D image, unless you know the orientation assumptions of the
> program you expect to read the image.  If you know those assumptions, you
> can write the 2D analyze image in the proper raw pixel arrangement, and
> figure the hist.orient field doesn't matter.
> 
> 
> 
> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
> 
>