[Insight-users] VectorImage Orientation from NRRD

[Daniel Betz]

Hello

> Daniel, Are you saying (at the end of your message) that because  
> you're using VectorImage, you don't have access to the direction  
> cosine and m_IndexToPhysicalPoint?

No. I ever have access to direction; in itk::Image, itk::VectorImage
and itk::OrientedImage. That is because all of them inherit from
itk::ImageBase and there is the field m_Direction declared (and also
m_Origin and m_Spacing). I can access them with the appropriate
Get/Set methodes.
You said "its the job of the (unit-length) direction cosines to
indicate how the samples are arranged along the axes" and I just
wanted to point out that its true for the itk::OrientedImage. There
does the SetDirection methode the following:
<octave>
o>> m_IndexToPhysicalPoint = m_Direction * diag(m_Spacing)
</octave>
So the TransformIndexToPhysicalPoint Methode of itk::OrientedImage
can do 
<octave>
o>> point = m_Origin + sum( [
o>             m_IndexToPhysicalPoint(1,:) * index(1) ;
o>             m_IndexToPhysicalPoint(2,:) * index(2) ;
o>             m_IndexToPhysicalPoint(3,:) * index(3) ] )
</octave>
And for my data I would get
<octave>
o>> m_Origin = [125 124.1 79.3];
o>> m_Direction = diag([-1 -1 -1]);
o>> m_Spacing = [0.9375 0.9375 3];
o>> m_IndexToPhysicalPoint = m_Direction * diag(m_Spacing);
o>> index = [ 134 112 11 ];
o>> point = m_Origin + sum( [
o>             m_IndexToPhysicalPoint(1,:) * index(1) ;
o>             m_IndexToPhysicalPoint(2,:) * index(2) ;
o>             m_IndexToPhysicalPoint(3,:) * index(3) ] )
point =

   -0.62500   19.10000   46.30000
</octave>
My desired RAS coordinates for IJK:(134 112 11).

Enough dreaming; today the implementation of TransformIndexToPhysicalPoint()
in itk::Image and itk::VectorImage will simply ignore direction and it will
need some time until they has the same capabilities like itk::OrientedImage.

In the mean time ITK should load the NRRD files like the user would
expect it. Correctly. Any switch around of the signes should be removed.

If it is really desired to restrict the unoriented itk::Image to LPS
the only consequent solution would be to load only LPS oriented files
and to reject the rest.

To store the original "space" field in the MetaDataDictionary would make
it possible to go back into the right space, but it still would result
in ugly code.

Regards
Daniel Betz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://www.itk.org/pipermail/insight-users/attachments/20081016/8a7c4399/attachment.pgp>