[Insight-users] RE: RE: 3D Image Volume Origin
Frank Miller
frankmiller at jhmi.edu
Mon Apr 17 12:20:45 EDT 2006
Andrew,
Personally, I dont understand why the origin is handled the way it is in
the 2.4 code. It seemed like a bug to me. I would be interested to know
more details about why the 2.6 code is causing you problems.
I would expect most people would agree that something should be done to
maintain compatibility with itkImage as the library moves toward
itkOrientedImage but I dont know enough about ITK (and medical images in
general) to judge the merit of your suggestion.
Frank
Andrew Li wrote:
> 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.
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
More information about the Insight-users
mailing list