[Insight-users] RE: RE: 3D Image Volume Origin

[Andrew Li]

Hi, Peter, Frank:
 
I added the section deleted from 2.4.0 version back into 2.6.0 and it
seems work for us. Or in another word, it seems that only fix made for
itkOrientedImage in 2.6.0 is the section deleted from
IO/itkGDCMImageIO.cxx
 
Could we do the following?
 
1) Have the member m_Origin specified as following:
for itkImage, m_Origin is the image data origin derived based on image
orientation m_Direction. And
for itkOrientedImage, m_Origin is the image data origin derived based on
patient orientation;
 
2) Leave itkGDCMImageIO.cxx as 2.4.0 for itkImage DICOM IO and create a
new class itkGDCMOrientedImageIO.cxx (same as itkGDCMImageIO.cxx 2.6.0
today) for itkOrientedImage DICOM IO?
 
It will give us sometime to migrate from itkImage to itkOrientedImage.
Thanks.
 
-Andrew
 
________________________________

From: Andrew Li 
Sent: Friday, April 14, 2006 12:13 PM
To: 'insight-users at itk.org'
Subject: RE: RE: 3D Image Volume Origin
 
Hi, Peter, Frank:
 
Thank you very much for your detailed explanations.
 
This is the summary about what I understand now. Please let me know if I
made any mistake. Thank you very much!
 
There are three basic image classes that track image volume spatial
information in stack:
      itkImagebase
            |
      itkImage
            | 
      itkOrientedImage
            |     
 
They share the same class members:  
protected:
  /** Origin and spacing of physical coordinates. This variables are
   * protected for efficiency.  They are referenced frequently by
   * inner loop calculations. */
  SpacingType  m_Spacing;
  PointType   m_Origin;
  DirectionType m_Direction;
 
In 2.6.0, itkImage only works with images that m_Direction = identity.
And, thus, it shall be used only for DICOM series with Img-ori-pat tag
(0020|0037): 1\0\0\0\1\0, provided that it shall be loaded into stack
from F to H.
For all other cases, itkOrientedImage shall be used.
 
It seems very different from ITK SW Guide 2.4, particularly
itkOrientedImage class is not mentioned in the guide. 
 
-Andrew 
 
-----Original Message-----


Message: 5
Date: Fri, 14 Apr 2006 02:57:34 +0200
From: Peter Cech <pcech at vision.ee.ethz.ch>
Subject: Re: [Insight-users] 3D Image Volume Origin
To: insight-users at itk.org
Message-ID: <20060414005734.GA25526 at ee.ethz.ch>
Content-Type: text/plain; charset=us-ascii
 
On Thu, Apr 13, 2006 at 11:57:01 -0700, Andrew Li wrote:
> Hi, ITK users:
> 
> We are moving up ITK package from 2.4.0 to 2.6.0.
> There are some problems after ITK library is switched.
> 
> Those problems seem related to the center of the 3D volume, which is
> related to Origin and Direction of the 3D volume.
> 
> We just start to investigate the problems and we noticed that there
are
> some changes made in IO/itkGDCMImageIO.cxx
> 
>   In ITK 2.4.0 version: Date:      $Date: 2005/11/29 21:58:28 $
>   // DICOM specifies its origin in LPS coordinate, regardless of how
>   // the data is acquired. itk's origin must be in the same
>   // coordinate system as the data. This code transforms the DICOM
>   // origin into the itk origin. The itk origin is computed by
>   // multiplying the inverse(transpose) of the direction cosine times
>   // the dicom origin.
>   vnl_vector<double> itkOrigin(3), dicomOrigin(3);
>   vnl_matrix<double> dicomDirection(3,3);
>   dicomOrigin[0] = header.GetXOrigin();
>   dicomOrigin[1] = header.GetYOrigin();
>   dicomOrigin[2] = header.GetZOrigin();
>   for (unsigned int ii = 0; ii < 3; ii++)
>     {
>     dicomDirection[0][ii] = rowDirection[ii];
>     dicomDirection[1][ii] = columnDirection[ii];
>     dicomDirection[2][ii] = sliceDirection[ii];
>     }
>   itkOrigin = dicomDirection * dicomOrigin;
>   m_Origin[0] = itkOrigin[0];
>   m_Origin[1] = itkOrigin[1];
>   m_Origin[2] = itkOrigin[2];
> 
>   While in ITK 2.6.0 version: Date:      $Date: 2006/03/08 18:28:57 $
>   // Dicom's origin is always in LPS
>   m_Origin[0] = header.GetXOrigin();
>   m_Origin[1] = header.GetYOrigin();
>   m_Origin[2] = header.GetZOrigin();
> 
> Could anyone tell us the reason of the changes and impact of the
> changes?
 
The problem is due to inconsistency between itkImage and
itkOrientedImage. itkImage is the original image type and assumes that
Origin is in the same coordinate system as the image. In the ITK 2.2 new
image type itkOrientedImage
(http://www.itk.org/Wiki/Proposals:Orientation)
was introduced and physical coordinate system was set to match that of
DICOM. Unlike itkImage, itkOrientedImage correctly computes physical
coordinates also with not axis-aligned volumes. I'm not completely sure
whether the physical coordinate system before this change was
unspecified or it was just assumed that all images were correctly
reoriented by user.
 
The code in ITK 2.4 permuted the origin to match image orientation. This
broke physical coordinates computation in itkOrientedImage and was
subsequently fixed. Unfortunately, now the itkImage won't give you
expected physical coordinates unless it is LPS oriented.
 
For your current situation, I would suggest you switch from itkImage to
itkOrientedImage. It will solve your problem and as a bonus your
application will be able to correctly deal with non axis aligned
volumes.
 
Regards,
Peter Cech
 
**********************************
 
--------------------------------------------------------

This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information.Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator.
--------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20060414/a8ecad03/attachment.htm