[Insight-users] 3D Image Volume Origin

[Peter Cech]

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