[Insight-users] Fwd: DICOM reader

Fri Apr 24 07:46:16 EDT 2009

Correction: I meant the DICOM matrix has the basis vectors in the rows.

Begin forwarded message:

> From: Andreas Schuh <andreas.schuh.84 at googlemail.com>
> Date: April 24, 2009 1:41:48 PM GMT+02:00
> To: Delphine Ribes <delphine.ribes at epfl.ch>
> Subject: Re: [Insight-users] DICOM reader
>

> Hi Delphine,
>
> I assume the following. As the DICOM orientation matrix has the  
> basis vectors of the DICOM space in the columns, it transforms  
> column vectors from world space coordinates to DICOM space  
> coordinates. The orientation matrix of an itk::Image is used to  
> transform from image space (corresponds to DICOM space) to world  
> space. So we need the inverse transform. Not considering the  
> translation of the origin of the coordinate systems, the inverse  
> transform is the inverse of the DICOM orientation matrix. Because of  
> the orthogonality (orientation matrices are just rotation matrices),  
> the inverse is just the transpose (however,I guess you now this  
> already).
>
> --
> regards
> Andreas
>
> On Apr 24, 2009, at 12:22 PM, Delphine Ribes  
> <delphine.ribes at epfl.ch> wrote:
>
>> Hi Andreas,
>>
>> Thanks for the explanation.
>> What I don't get is why the vector is transposed?
>> Is there any particular reason?
>>
>> Best Regards,
>> Delphine
>>
>> Selon Andreas Schuh <andreas.schuh.84 at googlemail.com>:
>>
>>> Hi Delphine,
>>>
>>> the image direction matrix of an itk::Image is just the transpose
>>> (inversion) of the DICOM direction. The conversion from one into
>>> another is done by the writers/readers (for instance,
>>> itk::ImageFileReader, itk::ImageFileWriter).
>>>
>>> --
>>> regards
>>> Andreas
>>>
>>> On Apr 21, 2009, at 3:01 PM, Delphine Ribes <delphine.ribes at epfl.ch>
>>> wrote:
>>>
>>>> Hi Mathieu,
>>>>
>>>> Thanks a lot for your answer and the explanations for the first  
>>>> part
>>>> (1 to 160
>>>> and 160 to 1).
>>>>
>>>> Concerning the Image Direction, in the DICOM header there is:
>>>> (0020,0037) DS |0\1\0\0\0\-1|    #   12, Image Orientation  
>>>> (Patient)
>>>>
>>>> I directly read it and put it into a
>>>> ImageType::DirectionType ImDiritk;
>>>> After cross product :
>>>> ImDiritk[0][0]  0
>>>> ImDiritk[0][1]  1
>>>> ImDiritk[0][2]  0
>>>>
>>>> ImDiritk[1][0]  0
>>>> ImDiritk[1][1]  0
>>>> ImDiritk[1][2]  -1
>>>>
>>>> ImDiritk[2][0]  -1
>>>> ImDiritk[2][1]  0
>>>> ImDiritk[2][2]  0
>>>>
>>>> For itk Dicom Read :
>>>> ImDiritk[0][0]  0
>>>> ImDiritk[0][1]  0
>>>> ImDiritk[0][2]  -1
>>>>
>>>> ImDiritk[1][0]  1
>>>> ImDiritk[1][1]  0
>>>> ImDiritk[1][2]  0
>>>>
>>>> ImDiritk[2][0]  0
>>>> ImDiritk[2][1]  -1
>>>> ImDiritk[2][2]  0
>>>>
>>>>
>>>> and once I wrote it using itk writer:
>>>>
>>>> Me DICOM reader (header .mhd): The Tag : TransformMatrix is = to  
>>>> 0 0
>>>> -1 1 0 0 0
>>>> -1 0
>>>> itk DICOM reader (header .mhd): TransformMatrix = 0 1 0 0 0 -1 -1  
>>>> 0 0
>>>>
>>>> Apparently there is a conversion. Could you explain me?
>>>>
>>>> Thanks a lot,
>>>> Delphine
>>>>
>>>> Selon Mathieu Malaterre <mathieu.malaterre at gmail.com>:
>>>>
>>>>> Salut Delphine,
>>>>>
>>>>> On Tue, Apr 21, 2009 at 10:52 AM, Delphine Ribes <delphine.ribes at epfl.ch
>>>>>>
>>>>> wrote:
>>>>>> Dear itk users,
>>>>>>
>>>>>> I've implemented a DICOM reader and I wanted to compare it with
>>>>>> itk DICOM
>>>>>> reader.
>>>>>> The output of the DICOM reader I've implemented is an itk Image.
>>>>>>
>>>>>> I have some MPRAGE saggital data. First I've realized that I  
>>>>>> was not
>>>>> reading my
>>>>>> data the same direction as itk.
>>>>>> Me from 1 to 160
>>>>>> itk from 160 to 1
>>>>>> Is it a convention?
>>>>>
>>>>> What is '1' ? what is '160' ? My cristal ball is telling me you  
>>>>> are
>>>>> refering to Instance Number, right ? Since this is a DICOM Type 3,
>>>>> this cannot be used to order the individual DICOM slice. Instead  
>>>>> the
>>>>> only other information you can use reliably in cross-sectional
>>>>> aquisition (CT, MR...) is the pair Image Orientation (Patient)  
>>>>> (IOP)
>>>>> and Image Positon (Patient) (IPP). Then the ordering is defined  
>>>>> along
>>>>> this normal, with a positive spacing.
>>>>>
>>>>> It is described as 'jolinda' algorithm in gdcm. I could find this
>>>>> old ref:
>>>>> http://www.itk.org/pipermail/insight-users/2003-September/004762.html
>>>>>
>>>>>> In addition, when I write for example a .mhd file, and I read
>>>>>> directly the
>>>>>> header.
>>>>>> The Tag : TransformMatrix is = to 0 0 -1 1 0 0 0 -1 0
>>>>>> or it should be = to TransformMatrix = 0 1 0 0 0 -1 -1 0 0 as for
>>>>>> the itk
>>>>> DICOM
>>>>>> reader.
>>>>>>
>>>>>> In "My" DICOM reader, I get the direction from the DICOM header
>>>>>> tag :
>>>>>> 0x0020,0x0037
>>>>>> For direction 0 and 1 and then I do a cross product to get
>>>>>> direction 2.
>>>>>> I suppose there is something I miss understood concerning the  
>>>>>> image
>>>>> direction in
>>>>>> itk.
>>>>>> I should obtain the same as the itk dicom reader as output !
>>>>>
>>>>> I believe we are doing the same. could there be an issue in  
>>>>> inverting
>>>>> columns and rows ?
>>>>>
>>>>> HTH
>>>>> --
>>>>> Mathieu
>>>>>
>>>>
>>>>
>>>> Delphine Ribes
>>>> Advanced Clinical Imaging Technology, Siemens Medical Solutions- 
>>>> CIBM
>>>> Laboratory of functional and metabolic imaging,
>>>> Ã‰cole Polytechnique FÃ©dÃ©rale de Lausanne,
>>>> BÃ¢timent CH, Station 6
>>>> CH-1015 Lausanne
>>>> _____________________________________
>>>> 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
>>>
>>
>>
>> Delphine Ribes
>> Advanced Clinical Imaging Technology, Siemens Medical Solutions-CIBM
>> Laboratory of functional and metabolic imaging,
>> École Polytechnique Fédérale de Lausanne,
>> Bâtiment CH, Station 6
>> CH-1015 Lausanne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090424/2c0de60c/attachment-0001.htm>