[Insight-developers] [GDCM] ITK Origin and coordinate system

[Gordon Kindlmann]

hello,

For defining the third column vector in the Index-to-Physical  
transform (both its direction and scaling), I think looking at "Image  
Position (Patient)" of two adjacent slices is the right thing to do  
because of gantry tilt, wherein the slice direction is not  
perpendicular to the row and column direction.  Mathieu should  
correct me here, but as far as Simon's concern about not being able  
to know acquisition order, I don't think it matters: acquisition  
order isn't the same as physical ordering if the acquisition order  
was interleaved with respect to the slice axis (e.g. 0, 2, 4, 6, ...  
1, 3, 5, 7, ....).  As long as the slices can be put in some physical  
ordering, you have the means of looking at the difference of "Image  
Position (Patient)" of two adjacent slices.

But my primary concern was GDCM's handling of the origin.  This all  
started because Vince Magnotta noticed that the output of a simple  
GDCM-based DICOM-to-NRRD program reported a different origin than the  
one I determined (via David Clunie's "dcdump") to manually create a  
NRRD header.  Based on David's last meessage, it seems that the basis  
vectors for measuring the coordinates of "Image Position (Patient)"  
are indeed LPS (towards Left, towards Posterior, and towards  
Superior), in exactly that order, and *not* the vectors aligned with  
rows, columns, and slices.

Doesn't this mean that "Image Position (Patient)" of the first slice  
in a volume exactly fills the role of "Origin" in Luis's "Point = M *  
S * Index + Origin", and so this Origin value should not be subjected  
to any further transform?

Doesn't this also mean that the "Offset" field of a Meta header, or  
the "space origin" field of a NRRD header, which both serve to record  
"Origin", should be exactly the same as the "Image Position  
(Patient)" value in the first slice of a DICOM series?

Gordon

On Jan 18, 2006, at 8:27 AM, Peter Cech wrote:

> On Tue, Jan 17, 2006 at 19:40:51 -0700, Gordon Kindlmann wrote:
>> So, can someone tell me why the following is not the case with DICOM
>> in ITK:
>>
>> * The (0x0020,0x0037) "Image Orientation (Patient)" tag gives you two
>> unit-length vectors which you put in the first two columns of your
>> "M" matrix.
>>
>> * The (0x0028,0x0030) "Pixel Spacing" tag gives you two scalars that
>> you put in the first two diagonal entries of "S".
>>
>> * You take the difference between the (0x0020,0x0032) "Image Position
>> (Patient)" tags of any two successive slices, call this vector D.
>> Put D/|D| (normalized) in the third column of "M", and put |D| in the
>> third and final diagonal entry of "S".
>
> Current implementation differs from your description. The third column
> is a cross product of first and second column. In my opinion,  
> algorithm
> for third column you described is the correct one and current ITK
> implementation may give wrong direction matrix in two cases:
>
> 1. Third base vector of the volume is not perpendicular to other two.
>    Technically feasible, but might not be in wide use.
>
> 2. Third base vector should point in opposite direction.
>
>> * The (0x0020,0x0032) "Image Position (Patient)" tag of the very
>> first image (of the series) gives you "Origin".
>
> Regards,
> Peter
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers