[Insight-users] VectorImage Orientation from NRRD

[Gordon Kindlmann]

Hello,

Can someone else on this list point out if there's online  
documentation (or older insight-users messages) about how ITK  
presumes 3D orientation information to be in LPS?  I have an old  
email from Bill Lorensen about this, but I see now that it wasn't on  
insight-users.

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?

I agree with you that this LPS enforcement has unexpected  
consequences.  If ITK had a way of specifying which space was being  
used for orientation representation, it would have been used here.   
The recent proposals by Michael Halle and Luis Ibanez to include a  
hierarchy of coordinate spaces may address this, but they can better  
address that.

In the mean time, would it help if the original "space" field was  
stored in the MetaDataDictionary?

Gordon

On Oct 15, 2008, at 6:41 AM, Daniel Betz wrote:

> Hello Gordon,
>
> VectorImage works in relation to OrientedImage the same as Image.
> Both, Image and VectorImage, inherit from ImageBase.
>
> To decree orientation to be LPS has for sure a lot of benefits
> for a format like DICOM.
>
> I read itkNrrdImageIO.cxx and you could be right, even though I
> never read about such an decree for itk::Image to be in LPS space.
>
> In opposite to make such an decree to a format like DICOM, I think
> it doesn't make sense for a class like itk::Image. The reason is
> is simply that there are also formats without prescribed orientation.
>
> In my case, I have some world coordinates which I need to process
> further in the itk::Image. Then itkNrrdImageIO.cxx flips some signes
> around and my point in world coordinates point to another place of
> the object.
>
> I can't even use the MetaDataDictionary to get the initial coordinate
> system. So I need to get the initial world coordinate system from
> outside and then must flip back the signes on origin, direction and
> measurement frame.
>
> itkNrrdImageIO.cxx does this "correction" only for RAS and LAS
> coordinates, because, quoting an comment from itkNrrdImageIO.cxx,
> only for that the conversion to LAS is well-defined. Whatever
> "well-defined" means.
>
> Is this intended to prevent wrong-side surgery?
> I think it does the opposite.
>
> Any clarification is really appreciated.
>
>> As for the spacing- I'd say its right: the spacings as far as ITK is
>> concerned are supposed to be (I think!) positive, and its the job of
>> the (unit-length) direction cosines to indicate how the samples are
>> arranged along the axes.
>
> Yes thats right. itk::OrientedImage has a transformation matrix named
> m_IndexToPhysicalPoint which contains direction * diag(spacing). Image
> and VectorImage ignore direction at the moment.
>
> Regards,
> Daniel Betz