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

[Simon Warfield]

Andrew Li wrote:
> Hi, Frank:
>
> Thank you very much for spending your time on this issue.
>
> Half of our data is near coronal neurology MRI data. Typical image
> dimension (size) is (256,256,160) and pixel size is about (1,1,1.6) mm.
> Data is usually acquired with image data center close to the magnet
> center. Data is stored as DICOM series with Img-ori-pat tag (0020|0037)
> close to 1\0\0\0\0\-1 and Img-pos-pat tags varying from about (-128,
> -126, 128) to about (-128, 126, 128). When data is loaded from Anterior
> to Posterior, the norm will be close to 0\1\0. 
>
> When we use itkImage and itkGDCMImageIO to load images,
> In ITK 2.4.0, the origin is like:
> 	imgOrigin=-128.982467,-128.983739,-126.400000
> while in ITK 2.6.0, the origin is like:
> 	imgOrigin=-128.982467,-126.400000,128.983739
> The difference is a rotation that is applied to the origin in ITK 2.4.0.
>   

My understanding is the following:
  In a DICOM file, the origin is specified with respect to the patient 
coordinate system (LPS). This is not changed by the particular 
orientation of the slices of the data.
  The origin is the coordinates of the center of the first voxel in the 
DICOM data stream.

  The origin that ITK was using in 2.4.0 was under-specified, in that 
there was an ambiguity as to exactly what coordinate system the origin 
was in.  The intention was that the origin would provide the coordinates 
of the first voxel in the world coordinate system.  The code that was 
taking a DICOM origin (image position patient tag) and permuting it 
according to the direction cosines is certainly wrong, because the 
origin in a DICOM file was already in the LPS system.  For an origin 
from a different file format it may or may not be right to change the 
origin, depending on exactly what is the world coordinate system.  An 
itkImage does not explicitly represent orientation information, and so 
the world coordinate system is somehow implicit. If the world coordinate 
system is simply a scaled version of the voxel indices, then an origin 
in an LPS system such as comes from a DICOM file, might need to be 
changed to be compatible with the ordering of the axes in the data (it 
doesn't need to be changed if the axis ordering is LPS). This seems to 
be what you have encountered.

  For the 2.6.0 release, a convention was chosen that the origin in any 
ITK image, would be stored in the LPS system. This is compatible with 
what DICOM does. Other file formats may require a change in the origin 
in order to be compatible with this.

  The introduction of the orientation information has lead to some 
ambiguities being uncovered that haven't been resolved. For example, 
exactly what a gradient vector should be is unclear.
Another example, it is quite easy to register to oriented images, and 
then resample the aligned data into a particular rectangular lattice 
that contains none of the aligned data, because neither the source nor 
target image when represented in physical space needs to have an extent 
compatible with the rectangular lattice of the source or target images.

--
Simon

> As an example, since now the value of the origin in slice direction of
> about whole FOV off, any code assumes the coordinate system center is
> near image data center will break.
>   


> Since itkImage is a very basic class of our package, we hesitate to
> change it to itkOrientedImage right now, especially before the ITK SW
> guide is updated.
>
> In the mean time, we added back the rotation to the origin. Hope it will
> work for us right now and near future.
>
> Thanks again for your help!
>
> -Andrew
>
> -----Original Message-----
> From: Frank Miller [mailto:frankmiller at jhmi.edu] 
> Sent: Monday, April 17, 2006 9:21 AM
> To: Andrew Li
> Cc: insight-users at itk.org
> Subject: Re: [Insight-users] RE: RE: 3D Image Volume Origin
>
> 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
>  
> --------------------------------------------------------
>
> 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
>   


-- 
Simon K. Warfield, Ph.D.        warfield at crl.med.harvard.edu
Phone: 617-732-7090                      FAX:   617-582-6033
Associate Professor of Radiology,     Harvard Medical School
Director, Computational Radiology Laboratory
Departments of Radiology at Children's Hospital and
Brigham and Women's Hospital,
Thorn 329, Dept Radiology,  Brigham and Women's Hospital
75 Francis St, Boston, MA, 02115
MA 280, Dept Radiology, Children's Hospital Phone: 617-355-4566