[Insight-users] Nifti vs Dicom orientation
Mathieu Coursolle
mcoursolle at rogue-research.com
Mon Apr 6 16:39:24 EDT 2009
Hi,
Thanks, in fact I managed to clarify a few things today. ;)
In the end, my main issue is now that there doesn't seem
to have a way to retrieve the original s-form from the NIfTI file
right ?
MAthieu
On 6-Apr-09, at 4:34 PM, Bill Lorensen wrote:
> Mathieu,
>
> I believe that the Coursolle definition is the opposite of the ITK
> definition. The Coursolle definition is the same as the
> OrientImageFilter direction.
>
> In other words, ITK says that
> X increasing from Right to Left
> Y increasing from Anterior to Posterior
> Z increasing from Inferior to Superior
> is LPS.
>
> Dicom/ITK name the axes based on the positive name of the axis.
> OrientImageFilter (and Meta and nifti and Analyze) name the axes based
> on the negative name of the axis.
>
> So, if you tell OrientImageFilter that you want RAI, you will get an
> ITK direction of LPS.
>
> Confused??? See my recent e-mail.
>
> Bill
>
> On Mon, Apr 6, 2009 at 3:05 PM, Mathieu Coursolle
> <mcoursolle at rogue-research.com> wrote:
>> Hi,
>> Just to clarify...what I meant by RAI is:
>> X increasing from Right to Left
>> Y increasing from Anterior to Posterior
>> Z increasing from Inferior to Superior
>> So is ITK the opposite (LPS) ? Or do we mean the same ?
>> Thanks,
>> Mathieu
>> On 6-Apr-09, at 2:47 PM, Bill Lorensen wrote:
>>
>> I believe, that the OrientImageFilter defines its orientations the
>> reverse of dicom/itk. In other words, to achieve RAI in ITK's world,
>> you should specify LPS to OrientImageFilter. But, LPS is ITK's
>> coordinate system. So you should not need to use OrientImageFilter.
>>
>> Confused... I am,. See my recent e-mail regarding this.
>>
>> Bill
>>
>> On Mon, Apr 6, 2009 at 2:37 PM, Mathieu Coursolle
>> <mcoursolle at rogue-research.com> wrote:
>>
>> Hi,
>>
>> Thanks again.
>>
>> Maybe I did not understand the way ITK stores its direction and
>> origin
>>
>> then...
>>
>> My NIfTI file doesn't have a qform, but it has a sform that defines
>> the
>>
>> transform to MNI-152 space.
>>
>> Limited to the data size, this space is bound to :
>>
>> Left is -90 mm
>>
>> Right is +90 mm
>>
>> Posterior is -126 mm
>>
>> Anterior is 90 mm
>>
>> Inferior is -72 mm
>>
>> Superior is +108 mm
>>
>> What I am looking for is a 4 x 4 matrix I could use to multiply an
>> index in
>>
>> RAI
>>
>> to get the location in MNI-152 space.
>>
>> I though that the origin was the location of the first voxel in
>> space (in
>>
>> this case MNI-152).
>>
>> In this case, 126 is out of my space.
>>
>> I would expect an origin of (90, 90, -72), since this is the most
>> Right,
>>
>> Anterior, Inferior point of
>>
>> the data.
>>
>> I typically read the file using itkNIfTIImageIO, then convert it to
>> RAI
>>
>> using itkOrientImageFilter.
>>
>> I expect an origin of (90, 90, 72) mm at the ouput of
>> itkOrientImageFilter,
>>
>> but I instead get (-90, -90, -72).
>>
>> What could I do to get the expected result ? I guess I am missing a
>>
>> transformation somehow...
>>
>> Thanks,
>>
>> MAthieu
>>
>>
>>
>>
>>
>>
>> On 6-Apr-09, at 1:33 PM, Luke Bloy wrote:
>>
>> Hi Mathieu,
>>
>> So nothing happens to the data buffer, meaning that its ordering
>> isn't
>>
>> rearranged. the only thing that is changed is the way we relate the
>> i,j,k
>>
>> coordinates to 'world coordinates'.
>>
>> the 'origin' in both nifti and itk refers to the world coordinates
>> of the
>>
>> first voxel in the data buffer (0,0,0).
>>
>> so with a qform =
>>
>> [1, 0, 0, -90]
>>
>> [0, 1, 0, -126]
>>
>> [0, 0, 1, -72]
>>
>> [0, 0, 0, 1]
>>
>> you get an origin of (-90 mm, -126 mm, -72 mm), since nifti qforms
>> use RAS
>>
>> as the world frame this means that the (0,0,0) ijk voxel is located
>> 90mm to
>>
>> the left, 126 posterior and 72 mm inferior, to whatever is at 0mm,
>> 0mm,0mm
>>
>> (in MRI this usually the scanner isocenter). So in itk's LPS world
>> frame
>>
>> the origin should be set to (90,126,-72).
>>
>> This is unrelated to the itkOrientImageFilter, which does do actually
>>
>> flipping and transposing of the data buffer.
>>
>> -Luke
>>
>>
>> Mathieu Coursolle wrote:
>>
>> Hi,
>>
>> Thanks for your clarifications.
>>
>> However, I must admit that I am still a bit confused.
>>
>> Since NIfTI and ITK have different Left/Right and Anterior/Posterior
>>
>> directions,
>>
>> I admit that the direction matrix needs to be modified.
>>
>> Since my image dimension is 181 x 217 x 181, a flip in X means that
>> to
>>
>> change
>>
>> the direction, the new origin is -90 + (181 - 1) = 90.
>>
>> A flip in Y however means that the new origin should be -126 + (217
>> - 1) =
>>
>> 90.
>>
>> Should I then expect instead a GetDirection() and GetOrigin()
>> result of:
>>
>> [-1, 0, 0, 90]
>>
>> [0, -1, 0, 90]
>>
>> [0, 0, 1, -72]
>>
>> [0, 0, 0, 1]
>>
>> Just inverting the sign of the origin would then mean that the world
>>
>> coordinates
>>
>> are centered on (0, 0, 0)mm, which is not the always the case.
>>
>> Am I right ?
>>
>> Thanks!
>>
>> Mathieu
>>
>> On 6-Apr-09, at 12:13 PM, Luke Bloy wrote:
>>
>> Hi all,
>>
>> So this is my understanding of how orientations and ITK work.
>>
>> the GetDirection and GetOrigin methods in itk::Image return the
>> directional
>>
>> cosines in an LPS world frame. Thus an identity matrix returned by
>>
>> GetDirection() would mean the image is stored in LPS.
>>
>> The QForm and SForm matrices in the nifti file format are in the
>> RAS world
>>
>> coordinate frame. See
>>
>> http://nifti.nimh.nih.gov/nifti-1/documentation/nifti1fields/nifti1fields_pages/qsform.html
>>
>> So Mathieu, what you are reporting is the expected behavior.
>>
>> qform (shown by fslhd etc) of
>>
>> [1, 0, 0, -90]
>>
>> [0, 1, 0, -126]
>>
>> [0, 0, 1, -72]
>>
>> [0, 0, 0, 1]
>>
>> should yield a GetDirection() and GetOrigin of
>>
>> -1 0 0 90
>>
>> 0 -1 0 126
>>
>> 0 0 1 -72
>>
>> 0 0 0 1
>>
>>
>> Antoine,
>>
>> Your situation is more confusing, I'm not familiar with dcm2nii,
>> but it
>>
>> isn't unheard of to have dicom converters change the orientation of
>> the
>>
>> output image, to bring it into some consistent frame (LAS is a
>> favorite of
>>
>> labs that have lots of old code expecting analyze files). From what
>> you
>>
>> posted it seems that dcm2nii converted your image from an LPS
>> arranged dicom
>>
>> to an LAS arranged Nifti file. I would investigate the nifti file's
>> qform
>>
>> and sform matrics using either nifti_tool, fslhd or pynifti to
>> confirm this.
>>
>> Hope this helps,
>>
>> Luke
>>
>> Mathieu Coursolle wrote:
>>
>> Hi,
>>
>> I am having a similar issue, which may be related.
>>
>> I have a NIfTI file, which I load using itkNIfTIImageIO.
>>
>> By stepping into ITK, I can see that the s-form (sto_xyz) is:
>>
>> [1, 0, 0, -90]
>>
>> [0, 1, 0, -126]
>>
>> [0, 0, 1, -72]
>>
>> [0, 0, 0, 1]
>>
>> However, when it read the origin and orientation of the resulting
>> itkImage,
>>
>> I get:
>>
>> [-1, 0, 0, 90]
>>
>> [0, -1, 0, 126]
>>
>> [0, 0, 1, -72]
>>
>> [0, 0, 0, 1]
>>
>> This data is in the MNI-152 space. I know that the index (0, 0, 0)
>> should be
>>
>> (-90, -126, -72) mm in LPI coordinate system (NIfTI's default I
>> believe).
>>
>> Since I want my data in the RAI coordinate system, I then use the
>>
>> itkOrientImageFilter.
>>
>> Assuming it converts the image from LPI to RAI, I would expect the
>> ouput to
>>
>> be:
>>
>> [-1, 0, 0, 90]
>>
>> [0, -1, 0, 90]
>>
>> [0, 0, 1, -72]
>>
>> [0, 0, 0, 1]
>>
>> But I get:
>>
>> [1, 0, 0, -90]
>>
>> [0, 1, 0, -90]
>>
>> [0, 0, 1, -72]
>>
>> [0, 0, 0, 1]
>>
>> By the way, my image dimensions are 181 x 217 x 181.
>>
>> I know that index (0, 0, 0) is (90, 90, -72) mm in RAI.
>>
>> I am right that the matrix I get from ITK is not what is expected ?
>>
>> It looks to me that the itkNIfTIImageIO is doing some transform to
>>
>> the orientation matrix.
>>
>> What would be that transformation's purpose ?
>>
>> Thanks a lot!
>>
>> Mathieu
>>
>> ____________________ Mathieu Coursolle, M.Ing.
>>
>> Rogue Research Inc. www.rogue-research.com
>>
>> <http://www.rogue-research.com/>
>>
>>
>> On 6-Apr-09, at 10:46 AM, Antoine DUCHAMPS wrote:
>>
>> Hi all,
>>
>> I have a DWI sequence (brain) acquired with a Siemens scanner in
>> Dicom
>>
>> format. After converting it to NIfTI with dcm2nii
>>
>> (http://www.sph.sc.edu/comd/rorden/mricron/dcm2nii.html) I tried to
>> read
>>
>> it an recover the orientation by using ITK (I've copied the code
>> below).
>>
>> The matrix I obtain is the following:
>>
>> 0.9997 0.0000 0.0252
>>
>> 0.0002 -1.0000 -0.0072
>>
>> -0.0252 -0.0072 0.9997
>>
>> However, the transforation matrix in the Dicom header is
>>
>> 0.9997 0.0000 0.0252
>>
>> 0.0002 1.0000 -0.0072
>>
>> -0.0252 0.0072 0.9997
>>
>> If the Dicom image orientation is LPS, this means that the image
>>
>> orientation in NIfTI is LAS (And not RAS as I believed). Could
>> anybody
>>
>> clarify this please? Are there several possible orientations in
>> NIfTI?
>>
>> If so, how can I know the specific image orientation?
>>
>> Antoine.
>>
>> #include "itkImageFileReader.h"
>>
>> #include "itkOrientedImage.h"
>>
>> const unsigned int Dimension = 4;
>>
>> typedef short PixelType;
>>
>> typedef itk::OrientedImage<PixelType, Dimension> ImageType;
>>
>> typedef ImageType::Pointer ImagePointerType;
>>
>> typedef itk::ImageFileReader< ImageType > ReaderType;
>>
>>
>> int main(int argc, char* argv[])
>>
>> {
>>
>> ImageType::Pointer image = ImageType::New();
>>
>> ReaderType::Pointer reader = ReaderType::New();
>>
>> reader->SetFileName(argv[1]);
>>
>> reader->Update();
>>
>> image = reader -> GetOutput();
>>
>> std::cout << image->GetDirection() << std::endl; std::cout.flush();
>>
>> }
>>
>> _____________________________________
>>
>> Powered by www.kitware.com <http://www.kitware.com>
>>
>> Visit other Kitware open-source projects at
>>
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>>
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>>
>> http://www.itk.org/mailman/listinfo/insight-users
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _____________________________________
>>
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>>
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>>
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>>
>> http://www.itk.org/mailman/listinfo/insight-users
>>
>>
>>
>> ____________________ Mathieu Coursolle, M.Ing.
>>
>> Rogue Research Inc. www.rogue-research.com
>>
>> <http://www.rogue-research.com/>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ____________________
>>
>> Mathieu Coursolle, M.Ing.
>>
>> Rogue Research Inc.
>>
>> www.rogue-research.com
>>
>>
>>
>>
>>
>>
>>
>>
>> _____________________________________
>>
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>>
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>>
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>>
>> http://www.itk.org/mailman/listinfo/insight-users
>>
>>
>>
>>
>> ____________________
>> Mathieu Coursolle, M.Ing.
>> Rogue Research Inc.
>> www.rogue-research.com
>>
>>
>>
>>
>>
>>
>>
>>
>
____________________
Mathieu Coursolle, M.Ing.
Rogue Research Inc.
www.rogue-research.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090406/cff37adc/attachment-0001.htm>
More information about the Insight-users
mailing list