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

[Luis Ibanez]

Andrew,

You may find useful to read the discussion about
Image orientation proposal:


  http://www.itk.org/Wiki/Proposals:Orientation


The current consensus is that the orientation
information of the DICOM header should *not* be
applied to the image Origin.


Regards,


    Luis


--------------------
Simon Warfield wrote:
> 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
>>   
> 
> 
>