Hi Gordon,
Thanks for pointing out about the cell/node centered issue.
That's not the problem we are concerned about at this point,
although it is something important to keep in mind.
The issue we are discussing is that the transformation between
index and physical coordinates is in principle:
Point = M * S * Index + Origin
Where:
- Point and Origin are in the same physical coordinate system.
- M is the NxN matrix of direction cosines that represent
the orientation of the sampling grid axis.
- S is a diagonal matrix with the inter-slice spacing
along every direction.
- Index is the set of integer coordinates used for locating
a pixel in the image sampling grid.
An clearer way of interpreting this transformation is
Point - Origin = M * S * Index
where (Point-Origin) give us the vector that indicates the position
(with respect to the Origin) of the pixed identified by Index.
This vector is defined in the physical coordinate system .
Luis
------------------------
Gordon Kindlmann wrote:
> hello,
>
> 1) Is this a problem due to confusion between node-centered and cell-
> centered samples? DICOM uses a cell-centered notion of image origin.
> If the origin is the nominal location of the first sample, you could
> imagine a situation where a difference between node- centered and
> cell-centered understandings of the image position, in combination with
> a transform, could result in the origin moving.
>
> 2) As of the latest release, ITK adopted left-posterior-superior (LPS)
> as the one and only world coordinates system in which image orientation
> is defined. My understanding was that this was motivated by
> consistency with DICOM. What is the basis for the definition of image
> origin in ITK?
>
> 3) Working with the principle of least surprise, you probably want the
> origin recorded in NRRD or Meta output from ITK to coincide with the
> "Image Position (Patient)" tag of the first image of a series. Right
> now they are different.
>
> Gordon
>
> On Jan 17, 2006, at 11:58 AM, Luis Ibanez wrote:
>
>>
>> Hi Leila,
>>
>>
>> This is somehow a matter of "definition".
>>
>>
>> If the "origin" is defined as the physical
>> coordinates of the first pixel in the image,
>>
>>
>> then
>>
>>
>> The direction cosines should not be applied to the
>> origin, because this point is already in the physical
>> coordinates of space. e.g. the reference frame of
>> a scanner.
>>
>>
>>
>> The direction cosines are describing the orientation
>> of the axis defining the grid used for sampling the
>> image. In this context, the direction cosines only
>> affect the transformation between "index" and "physical
>> points", and they are useful for computing the position
>> of a pixel *with respect to the origin*.
>>
>>
>>
>> At this point, we may have to go back and reconsider
>> if that definition of "origin" is the one that holds
>> for DICOM, and whether this is the one that we want
>> to keep for ITK or not.
>>
>>
>>
>> Luis
>>
>>
>>
>> ---------------------
>> Leila baghdadi wrote:
>>
>>> Hey petit frere,
>>> I think you are right about the origin being a fixed point, i.e, for
>>> the
>>> header information,
>>> but once you apply the direction cosines to the image (i.e, right
>>> before
>>> visualization), shouldn't the origin be resampled as well?
>>> Leila
>>> On Tue, 2006-01-17 at 13:08 -0500, Mathieu Malaterre wrote:
>>>
>>>> Bill,
>>>>
>>>> We are having a discussion with Gordon about a problem
>>>> regarding the Origin of an itkImage read from a DICOM file. A while
>>>> ago you put this code into itkGDCMImageIO(*). After discussion with
>>>> Luis we came to the conclusion that the Origin is a fixed point.
>>>> If you want to compute a point then yes you need to use the
>>>> direction cosine and refer to the origin. But the origin should not
>>>> change, right ?
>>>>
>>>> Comments welcome,
>>>> Mathieu
>>>>
>>>>
>>>> (*)
>>>> // 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];
>>>> _______________________________________________
>>>> Insight-developers mailing list
>>>> Insight-developers at itk.org
>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>>
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>
>