[Insight-users] is DICOM volume origin calculation correct?

[Bill Lorensen]

I should appear in the same position in Slicer I think. perhaps there is a
bug in the DicomSeriesReadImageWrite2.cxx example.

Bill



On Fri, Aug 9, 2013 at 4:00 AM, Mariana Bustamante <marianabb at gmail.com>wrote:

> Hi Bill,
>
> Thanks for the answer.
>
> Maybe that makes sense when reading the image with ITK, but the problem
> remains when I write the volume to another file, since ITK modifies the IPP
> tag of the DICOM file to be the last slice. As a result, if I open this new
> file with Slicer for example, the new origin is the last slice and the
> image is in the incorrect position.
>
> Shouldn't ITK use the DICOM standard when writing a DICOM file and use the
> first slice origin as the IPP?
>
> Regards,
> --
> Mariana
>
>
> On Thu, Aug 8, 2013 at 10:11 PM, Bill Lorensen <bill.lorensen at gmail.com>wrote:
>
>> ITK uses a right handed coordinate system. That is why in this case, the
>> last slice is the origin slice. At last that's what I recall.
>>
>>
>>
>>  On Thu, Aug 8, 2013 at 1:10 PM, marianabb <marianabb at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I am using ITK-4.3.2 to create a volume from a stack of DICOM
>>> single-frame
>>> images of the heart.
>>>
>>> Most of the code is taken from the example
>>> DicomSeriesReadImageWrite2.cxx,
>>> and the basics work, but I'm confused about whether the volume origin
>>> produced is correct.
>>>
>>> The volume is composed of 14 slices, with spacing [1.0, 1.0, 8.0], the
>>> first
>>> and last slices have the following origins (Image Position Patient, DICOM
>>> tag 0020,0032):
>>> - First slice: 42.021, -174.562, 159.592
>>> - Last slice: -27.608, -102.908, 188.461
>>>
>>> The resulting file created with ITK has the last slice IPP as the image
>>> origin, but if I open the original DICOM files with Slicer or Matlab the
>>> resulting image has the first slice IPP as the origin.
>>>
>>> I thought that maybe ITK was just using the IPP of the last file it read,
>>> but if I read the slices in the opposite order (last slice as first as so
>>> on) the resulting origin is still the same as before.
>>>
>>> I understand also that Slicer and DICOM files use the top-left voxel as
>>> the
>>> origin, while ITK uses the bottom-left voxel, but this still doesn't
>>> explain
>>> using the last slice IPP.
>>>
>>> Any thoughts on this matter would be of great help.
>>>
>>> Thanks!
>>> --
>>> Mariana
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://itk-insight-users.2283740.n2.nabble.com/is-DICOM-volume-origin-calculation-correct-tp7583709.html
>>> Sent from the ITK Insight Users mailing list archive at Nabble.com.
>>> _____________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://www.kitware.com/products/protraining.php
>>>
>>> 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
>>>
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com
>>
>
>


-- 
Unpaid intern in BillsBasement at noware dot com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20130809/9fd08ae1/attachment.htm>